Chapitre 3

Contrôle de trafic dans les réseaux ATM

Résumé
Ce chapitre décrit l’essentiel de la normalisation des réseaux ATM en détaillant l’aspect contrôle de trafic et con-
trôle de congestion. Après avoir introduit les réseaux ATM, le RNIS large bande et la couche d’adaptation, une
présentation du contrôle de congestion permet de distinguer deux types de contrôle de trafic : le contrôle préven-
tif et le contrôle réactif. Les principes du contrôle préventif sont ensuite détaillés en termes de contrôle d’admis-
sion, contrat de trafic, gestion de ressources et capacités de transfert. Enfin, une conclusion permet de placer
cette thèse dans le cadre de la capacité de transfert SBR/VBR-rt.

3.1 Présentation générale des réseaux ATM

Le réseau numérique à intégration de services large bande (RNIS-LB) se présente comme la phase ultime de
développement des réseaux de télécommunication depuis l’ère de la téléphonie analogique. Il fut créé par
l’instance internationale de normalisation des télécommunication, le CCITT, et poursuivi par l’ITU-T, sous forme
d’une série de recommandations qui définissent tous les aspects, allant du vocabulaire à la signalisation en passant
par le plan d’adressage (les recommandations de base sont citées dans [56 à 67]). Une étape importante de la nor-
malisation fut l’adoption du mode de transfert asynchrone (ATM) comme technologie de base pour le RNIS-LB.
L’autre acteur déterminant dans l’évolution des réseaux ATM est l’ATM-Forum. Crée en novembre 1991
par un consortium de quelques industriels, il comprend à l’heure actuelle plus que 600 industriels intéressés par
cette technologie. Les spécifications de l’ATM-Forum qui concernent l’interface entre l’utilisateur et le réseau
sont décrites dans le document ATM User-Network Interface Version 4 souvent référencée dans cette thèse [25].

21
Contrôle de trafic ATM pour sources vidéo à débit variable

Vu le nombre important de publications, thèses et autres documents disponibles sur les divers aspects du
RNIS-LB et ATM, et pour éviter que ce document ne se transforme en un support de cours sur ATM et répète en
cela les ouvrages de G. PUJOLLE, P. ROLIN..., nous ne décrivons dans la suite de ce chapitre et d’une manière
concise, que les concepts qui sont utiles dans le contexte du contrôle de trafic et de vidéo à débit variable.

3.1.1 Le mode de transfert asynchrone

Le mode de transfert asynchrone, se base sur l’utilisation de cellules de données de taille fixe égale à 53
octets dont 5 pour l’entête ATM. Le transport de ces cellules dans le réseau n’est pas synchronisé au rythme de
l’émetteur (ou terminal ATM) d’où l’aspect asynchrone de l’ATM. Le transfert des données sur ATM se fait en
mode connecté. Le modèle de référence de la couche ATM se trouve dans I.361 [63].

Les supports physiques utilisés dans les réseaux ATM sont la hiérarchie digitale synchrone (SDH) et la
hiérarchie digitale pleisiochrone (PDH). Des commutateurs ATM existent déjà sur le marché et des maquettes de
réseaux nationaux sont déjà opérationnelles dans plusieurs pays. Outre les réseaux publics, la technologie ATM
trouve largement sa place dans le monde des réseaux locaux. L’avantage étant l’interconnexion facile via la
RNIS-LB. Cet aspect LAN de l’ATM intéresse plus l’ATM-Forum que l’ITU-T. Par exemple, le groupe de travail
AF-LANE (ATM-Forum LAN Emulation) travaille sur l’émulation, sur les réseaux locaux ATM, des services
réseaux classiques tel que la résolution d’adresse ou la diffusion.

3.1.2 La couche d’adaptation

Comme le stipule le document [62] de description fonctionnelle de la couche d’adaptation de l’ATM (notée
AAL), celle-ci “permet d’améliorer les services offerts par la couche ATM pour les fonctions requises par la
couche immédiatement supérieure”. L’AAL supporte des protocoles multiples pour répondre aux besoins des dif-
férents usagers de cette couche. L’AAL dépend donc du service offert.

Afin de réduire le nombre d’AAL, une classification des services a été définie par l’ITU-T [62] et permet de
distinguer quatre classes de services décrites dans le tableau 2. Les AAL actuellement suggérées [64] sont :
• AAL-1 : pour classe de service A,
• AAL-2 : pour classe de service B,
• AAL-3/4 : pour classes de service C et D, utilisée en particulier pour la signalisation,
• AAL-5 : pour classes de service C et D, proposée par l’ATM-Forum.

Classe A Classe B Classe C Classe D

Synchronisation Requise Non requise

Débit binaire Constant Variable

Mode de connexion Connecté Non connecté

Emulation de cir- Vidéo/Audio à Transfert de don- Transfert de don-

Exemples de cuit, Vidéo à débit variable nées en mode nées en mode dat-
services débit constant connecté agramme
Tableau 2 : Classification des services pour l’AAL

La couche AAL est divisée en deux sous-couches, la sous-couche de segmentation et ré-assemblage SAR
(pour Segmentation and Reassembly) et la sous-couche de convergence CS (pour Convergence Sublayer). Cette
dernière sous-couche est dépendante du service offert et est elle même sub-divisées en deux parties : la partie
commune ou CPCS (pour Common Part Convergence Sublayer) et la partie spécifique au service ou (SSCS pour
Service Specific Convergence Sublayer). Les spécifications de CPCS sont prévues dans la recommandation I.363.

22
 Contrôle de trafic dans les réseaux ATM

Au sein de la couche SSCS, le protocole SSCOP (pour Service Specific Connection Oriented Peer-to-Peer Proto-
col) a été défini [Q.SAAL1] pour la signalisation. Le service SSCOP est utilisé par une fonction de coordination
(faisant partie de SSCS) qui s’appelle SSCF (pour Service Specific Coordination Function) spécifiée dans
[Q.SAAL2].

3.1.3 Contrôle de congestion

Dans le RNIS-LB, la notion de congestion dans la couche ATM, est définie comme un état des éléments du
réseau où les performances du réseau se dégradent en deçà des valeurs négociées lors de l’établissement des con-
nexions. Le contrôle de trafic désigne alors l’ensemble des actions du réseau qui permettent d’éviter les conges-
tions. De même, le contrôle de congestion désigne l’ensemble des actions du réseau qui permettent de minimiser
l’intensité et les effets d’un éventuel état de congestion.

Introduisons d’abord les quatre classes de QoS qui ont été définies par l’ATM-Forum et qui correspondent
respectivement aux besoins des quatre classes de service du tableau 2. L’ATM-Forum a aussi défini les classes de
QoS non spécifiées qui correspondent aux services de type Best Effort où l’application ne demande aucune garan-
tie sur la QoS.
Le contrôle de trafic et le contrôle de congestion doivent alors supporter un ensemble de classes de QoS cor-
respondant aux besoins des services actuels ainsi que les services futurs envisagés pour le RNIS-LB, et ceci sans
faire appel à des améliorations de performances dans la couche AAL ou dans des couches supérieures. Un deux-
ième objectif implicite est de maximiser le rendement (ou facteur d’utilisation) du réseau.

Deux types de contrôles de trafic peuvent être envisagés : contrôle préventif et contrôle réactif. Comme son
nom le suggère, le contrôle préventif consiste à prendre des mesures a priori, i.e. avant l’occurrence d’une éven-
tuelle congestion, pour minimiser les chances de son apparition. Par exemple, les réservations de bande passante
ou de mémoires dans le réseau font partie du contrôle préventif. Le fait que la connexion déclare le débit d’émis-
sion est aussi utilisé pour des actions préventives (e.g. les réservations). La philosophie du contrôle préventif est
de protéger le réseau contre les rafales de données émises, et ce afin de pouvoir assurer une qualité de service sat-
isfaisante.

Contrairement au contrôle préventif, le contrôle réactif agit en fonction de l’évolution de l’état de réseau, il
réagit à la congestion. Dans ce cas, le réseau accepte toutes les connexions et tant qu’il n’y a pas de congestion
celles ci peuvent émettre le débit qui leur convient. La mesure de congestion peut se faire de plusieurs manières
(e.g.: en mesurant les pertes, les délais, le remplissage des buffers...) par le réseau ou par les équipements ter-
minaux. Si une congestion se déclare les connexions diminuent leur débit. Un exemple bien connu de contrôle
réactif est le mécanisme de fenêtre de congestion du protocole TCP/IP défini par Van Jacobson [68] et utilisé dans
l’actuel Internet. La philosophie du contrôle réactif est de pouvoir partager les ressources par le maximum de con-
nexions pour optimiser l’utilisation du réseau. De ce fait, ce type de contrôle peut être approprié aux connexions
de données qui peuvent s’adapter aux conditions du réseau. Cependant, il n’est pas adapté aux connexions qui
nécessitent une garantie de qualité de service (comme c’est le cas des services vidéo temps réel).
Initialement, l’ITU-T avait choisi une politique complètement préventive de contrôle du trafic [55]. A
l’heure actuelle, sous l’impulsion de l’ATM-Forum, le contrôle réactif revient à l’ordre du jour avec la capacité de
transfert ABR définie plus loin dans ce chapitre.

Dans le cadre de cette thèse, nous considérons que les services à contraintes de temps nécessitent un contrôle
de trafic préventif ; c’est pourquoi nous le retenons dans le contexte de l’étude des services vidéo à débit variable
dans les réseaux ATM. Dans le paragraphe suivant, nous exposons les principes du contrôle de trafic préventif, tel
que spécifiés dans les documents de normalisation.

23
Contrôle de trafic ATM pour sources vidéo à débit variable

3.2 Contrôle préventif de trafic

Les documents de base décrivant le contrôle de trafic ATM dans le RNIS-LB sont la recommandation I.371
de l’ITU-T [55] et le ATM-Forum UNI Specification V3.1 [25]. Dans la suite, le contrôle préventif de trafic sera
désigné par le terme contrôle de trafic tout court. En cas d’ambiguïté, l’adjectif réactif ou préventif sera utilisé
pour plus de précision.
Le contrôle de trafic dans la couche ATM se base sur la déclaration de paramètres de trafic et le contrôle par
le réseau de la conformité du trafic à ces paramètres. En effet, lors de la demande d’établissement de la connex-
ion, l’utilisateur (ou le terminal ATM) déclare un certain nombre de paramètres décrivant son trafic. Ces
paramètres sont utilisés par le réseau pour prendre des mesures préventives pour éviter les congestions. L’ensem-
ble de ces paramètres s’appelle descripteur du trafic de la source ou STD (pour Source Traffic Descriptor). Outre
les paramètres de trafic, l’utilisateur spécifie les valeurs désirées des attributs de qualité de service (QoS) requises
par la connexion. Par exemple, le délai et le taux de perte sont des attributs de la qualité de service. Le réseau
décide alors d’accepter ou de refuser la connexion selon qu’il estime pouvoir, ou non, satisfaire les contraintes de
QoS spécifiées. La procédure qui lui permet de décider s’appelle procédure de contrôle d’admission ou CAC
(pour Connection Admission Control). Si la connexion est acceptée, le réseau contrôle le trafic effectivement émis
par la source durant toute la connexion pour vérifier sa conformité aux paramètres de trafic (STD) déclarés. Le
contrôle est fait à la volée et en temps réel, et les cellules non conformes peuvent être rejetés ou admises, selon la
politique de l’opérateur. Le réseau définit une politique d’allocation et de partage de ses ressources entre les con-
nexions dont le but est de respecter la qualité de service négociée tout en maximisant l’utilisation des ressources
du réseau.

Dans le suite de cette section, nous présentons les principes du contrôle d’admission, des paramètres de trafic
et la gestion des ressources dans les réseaux ATM.

3.2.1 Contrôle d’admission

C’est l’algorithme déroulé par le réseau pour décider l’acceptation ou le rejet d’une demande d’établissement
d’une connexion. Le principe de la CAC consiste à prédire si, en acceptant le nouveau trafic, le réseau pourra
garantir la QoS de la nouvelle connexion ainsi que celles des connexions déjà en cours. Comme c’est une décision
a priori, la connaissance du nouveau trafic se limite aux paramètres déclarés par l’utilisateur. L’efficacité de
l’algorithme de la CAC est alors largement dépendante des paramètres de trafic utilisés.
Il est possible de développer des algorithmes de CAC en se basant sur des hypothèses de trafic. Par exemple,
si on suppose que les trafics sont poissonniens, l’étude de la file M/D/1/K permet d’indiquer le montant de ressou-
rces nécessaires pour accepter la connexion. De même, en supposant que le trafic soit de type ON/OFF (rafales
suivies de silences de longueurs exponentiellement distribuées) il est possible de développer la CAC correspon-
dante. Ainsi, plusieurs travaux ont été publiés et se basent sur des paramètres plus ou moins sophistiqués du trafic.
Le bande passante nécessaire à une connexion, appelé débit équivalent, est très utilisée pour définir des algo-
rithmes de contrôle d’admission [22, 37, 71]. Dans les réseaux publics, la procédure CAC fait partie du plan ges-
tion du réseau et ne dépend que du choix de l’opérateur, elle ne fait pas l’objet de normalisation. Les
performances d’une procédure CAC dépendent des hypothèses de trafic. Dans le cadre des réseaux ATM, pour
qu’une procédure CAC soit significative, il faut qu’elle soit basée sur les paramètres de trafic définis pour les con-
nexions ATM.

24
 Contrôle de trafic dans les réseaux ATM

3.2.2 Contrat de trafic et contrôle des paramètres

Le contrat de trafic entre l’utilisateur (ou le terminal) et le réseau ATM consiste à déclarer les paramètres
standards de trafic (STD) ainsi que les paramètres de QoS désirés [55]. En acceptant la connexion, le réseau
s’engage à garantir la QoS et l’utilisateur s’engage à respecter les paramètres STD. Pour être significatif, les
paramètres STD doivent vérifier les propriétés suivantes :
• être simple pour l’utilisateur (pour qu’il puisse les déclarer),
• être contrôlable en temps réel par le réseau,
• être significatif pour la CAC et l’allocation des ressources.

La fonction qui permet de contrôler la conformité aux paramètres de trafic s’appelle fonction de police ou
UPC (pour Usage Parameter Control). L’UPC est située dans les interfaces utilisateur-réseaux ou UNI (pour
User-to-Network Interface). Une fonction semblable, la NPC (Network Parameter Control) se situe dans l’inter-
face réseaux-réseaux ou NNI (pour Network-to-Network Interface). Dans le contexte de l’ITU-T, la recommanda-
tion I.371 définit les paramètres de trafic suivants :
• le débit crête ou PCR (pour Peak Cell Rate). La gigue cellule ou CDVT (pour Cell Delay Variation Tolerance)
est aussi un paramètre associé à la définition du débit crête. Le débit crête signifie le débit maximal auquel la
source est autorisée à émettre. Comme le trafic d’une source est multiplexé d’une manière asynchrone avec
celui des autres sources, le flux original de la source se trouve modifié à son arrivée à l’interface : c’est la
gigue du multiplexage asynchrone. Le paramètre CDVT sert justement à tenir compte de cette gigue. Il définit
la gigue maximale qui peut affecter une cellule. Ces deux paramètres, PCR et CDVT, permettent par exemple
de caractériser un trafic à débit constant PCR dont la gigue introduite par le multiplexage asynchrone est
décrite par CDVT. L’algorithme permettant de vérifier la conformité d’un flux de cellules à ces deux
paramètres s’appelle GCRA (pour Generic Cell Rate Algorithm)1 et est présenté plus loin dans ce paragraphe.
• le débit soutenu ou SCR (pour Sustainable Cell Rate) et la tolérance de rafale ou IBT (pour Intrinsic Burst Tol-
erance). Le paramètre SCR représente une estimation du débit à long terme de la source, ou plus précisément,
une borne supérieure du débit moyen. Le paramètre IBT permet de limiter l’écart cumulé entre le débit instan-
tané et SCR. Il contrôle la variabilité du trafic. En d’autres termes, IBT peut être mise en relation directe avec
la taille maximale du buffer nécessaire pour accommoder le trafic en question dans un canal à débit constant
égal à SCR. Plus IBT est faible et plus le trafic tend à être constant. Les paramètres SCR, IBT, PCR et CDVT,
servent à caractériser un trafic à débit variable. L’algorithme GCRA permettant de contrôler la conformité
d’un flux aux deux paramètres r et M, ces derniers sont en relation directe avec SCR et IBT. Ainsi, l’UPC qui
contrôle les paramètres d’un trafic variable consiste en deux modules GCRA qui s’exécutent simultanément,
le premier contrôlant les paramètres PCR et CDVT et le deuxième, les paramètres SCR et IBT. Une cellule est
conforme si elle est déclarée comme tel par les deux modules.
L’algorithme GCRA a été normalisé par l’ITU-T en 1992. Il peut être décrit de plusieurs manières plus ou
moins faciles à comprendre. Une manière simple est de le définir par rapport au modèle du seau percé ou leaky
bucket [99, 114]. Le leaky bucket est définit par deux paramètres : le débit de fuite R (leak rate) et la taille du
buffer virtuel M (virtuel buffer size ou token pool size). Chaque cellule admise dans le réseau incrémente la taille
du buffer virtuel qui est continûment vidé au débit R. Si la taille du buffer atteint M, la cellule entrante est déclarée
non conforme. Le GCRA est alors équivalent à un leaky bucket dont les paramètres PCR et CDVT coïncident
respectivement avec R et M. Autrement dit, un cellule rejeté du leaky bucket est déclarée non conforme par le
GCRA. L’algorithme du GCRA n’est autre que l’implémentation du leaky bucket sous forme d’un compteur qui
décrit le remplissage du seau.
D’une manière générale, si on appelle N(s,t) le nombre de bits générés par une source entre les instants s et t,
la conformité à un modèle de leaky bucket de paramètres R et M s’écrit :
∀( s, t ), N ( s, t ) ≤ R × ( t – s ) + M

1. Il est aussi appelé Contineous State Leaky Bucket ou encore Virtual Scheduling Algorithm.

25
Contrôle de trafic ATM pour sources vidéo à débit variable

Le trafic d’une source peut être décrit de plusieurs manières selon l’échelle de temps sur laquelle on le définit :
• à l’échelle paquet, le trafic est une suite de paquets de taille variable. C’est le cas par exemple d’une source IP
ou d’un trafic vidéo défini par la taille de ses images.
• à l’échelle cellulaire, le trafic est une suite de cellules ATM, de taille fixe, et N(s,t) désigne le nombre de cel-
lules émises entre les instants s et t. Dans ce cas R est exprimé en cellules par seconde et M en cellules.
• à l’échelle fluide, le trafic est considéré comme un fluide dont l’intensité en bits/s, notons la R(t), est une fonc-
tion continue du temps. Dans ce cas N(s,t) est égale à l’intégrale de R(t) entre s et t.

Le leaky bucket peut être défini pour toutes ces manières de description du trafic. Dans le chapitre 5 par
exemple, on décrit un leaky bucket opérant à l’échelle du GoP.

Une autre manière de définir le leaky bucket consiste à dire que la conformité d’une source aux paramètres r
et M est équivalente à la condition de non-rejet d’une file d’attente G/D/1/K alimentée par la même source et dont
le débit de service est égal à r et la taille du buffer est égal à M. Une illustration de cette analogie se trouve dans
[38].

Deux niveaux de priorités sont définis pour les cellules ATM grâce au bit CLP (pour Cell Loss Priority) de
l’entête de la cellule qui est mis à zero pour indiquer les cellules prioritaires. Les cellules non conformes au con-
trat de trafic peuvent être soit rejetées soit admises en classe non prioritaire. La définition du bit CLP a en fait été
une source d’ambiguïté pour le processus de normalisation. Par exemple, la recommandation I.371 a envisagé
autorise la déclaration des paramètres de trafic du flux prioritaire (noté flux CLP=0) en plus des paramètres de la
totalité du trafic (noté CLP=0+1). L’ATM-Forum lui, semble autoriser la déclaration des paramètres SCR et IBT,
séparément pour chacun des flux CLP=0 et CLP=1.

Finalement, le réseau peut aussi exploiter des propriétés prédictibles de certains trafics, qu’on peut aussi
appeler paramètres implicites. C’est le rôle du champs “Service Type” défini par la recommandation I.371. C’est
la cas, par exemple, des conversations téléphoniques compressées (e.g. le codage TASI pour Time Assigned
Speech Interpolation) utilisé par les opérateurs téléphoniques pour doubler la capacité des liens trans-continen-
taux [84].

3.2.3 Gestion des ressources

La gestion des ressources est l’ensemble des actions menées par le réseau lors de l’acceptation d’une nou-
velle connexion (e.g. réservation de ressources) ainsi que le contrôle de ces ressources tout au long de la connex-
ion (e.g. priorités et ordonnancement).
Pour garantir la QoS d’une connexion, il est en général nécessaire de réserver de la mémoire et/ou de la
bande passante dans les commutateurs et autres éléments du réseau. La quantité des ressource réservées est déter-
minée en fonction des paramètres du trafic, de la QoS demandée et de l’état du réseau. La disponibilité de ces res-
sources est contrôlée par l’algorithme de la CAC. Par exemple, si le montant des ressources disponibles est
inférieur au débit équivalent de la connexion rentrante, celle-ci est rejetée.

Dans certains cas, la réservation des ressources ne suffit pas à garantir la QoS. En effet, si les flux sont
hétérogènes, les rafales de certaines connexions (comme les connexions de données) peuvent perturber les cel-
lules des connexions temps réel. L’utilisation de disciplines de services dans les commutateurs, autres que FIFO
devient alors nécessaire [13]. L’idée d’introduire des mécanismes d’ordonnancement plus ou moins sophistiqués
dans les commutateurs est de plus en plus répandue malgré la complexité des implémentations matérielle opérant
à très haut débit [36, 105]. Parmi ces mécanismes, le fait de pouvoir affecter des priorités aux connexions permet
d’en protéger les plus prioritaires des perturbations de trafic des moins prioritaires. Cependant, le fait d’affecter
des priorités aux connexions n’est pas suffisant pour les réseaux à intégration de services [13].

Un mécanisme d’ordonnancement de paquets particulièrement intéressant pour les réseaux à intégration de

services est le Partage Généralisé du Processeur ou GPS (pour Generalized Processor Sharing) [92]. D’autres
versions sont aussi connues sous le nom de Weighted Fair Queueing (WFQ) [21], Virtual-Clock [110] ou Self-

26
 Contrôle de trafic dans les réseaux ATM

clocked WFQ [36]. Le principe du GPS consiste à partager à tout instant le débit du canal, noté C, entre les con-
nexions proportionnellement à un poids affecté à chacune d’elle. Si l’on considère un modèle fluide de trafic, à
chaque instant t, la fraction de débit ci(t) alloué à la ième connexion de poids αi est donnée par :
αi
c i ( t ) = C --------------------
-
∑ αj
j ∈ Ω(t)
où Ω( t ) désigne l’ensemble des connexions actives à l’instant t.

Un avantage majeur de ce mécanisme est qu’il fournit des garanties de QoS quand il est utilisé conjointement
avec un contrôle de trafic du type leaky bucket. En effet, si chaque connexion i est conforme à un leaky bucket
correspondant aux paramètres Ri et Mi, les actions suivantes :
• réserver un buffer de taille Mi pour la connexion i,
R
• utiliser un ordonnancement GPS avec α i = -----i
C
• utiliser un algorithme CAC qui vérifie que ∑ α i ≤ 1

permettent de garantir à chaque connexion i un délai d’attente inférieur ou égal à Mi/Ri et un taux de perte nul.
Une version du GPS spécifique à l’environnement ATM, appelée Virtual Spacing, a été développée par James
Roberts au CNET [105]. Les détails et les propriétés de ces ordonnancement existent dans [18, 19, 21, 36, 92,
105, 120].

3.3 Les capacités de transfert ATM

Comme le RNIS-LB est un réseau multi-services, une architecture des services a été défini par les organis-
mes de standardisation i.e. l’ITU-T et l’ATM-Forum. Bien que les terminologies utilisées soient différents pour
les deux organismes, nous essayons de résumer dans ce paragraphe les capacités de transfert (en anglais, ATM
Traffic Handling Capabilities) actuellement définis ou en cours de définition, le type d’applications qui les uti-
lisent et les mécanismes de contrôle de trafic correspondants. Les articles [7, 39, 106] donnent une vision plus
globale et des discussions intéressantes sur les différentes capacités de transfert ATM.

3.3.1 Deterministic Bit Rate (DBR)

Appelée aussi Constant Bit Rate (CBR) dans l’ATM-Forum, cette capacité de transfert est conçue pour les
applications temps réel ayant des contraintes strictes sur le délai et la variation de délai ainsi que sur les pertes. La
voix et la vidéo à débit constant sont des exemples typiques de ces applications. La couche adaptation AAL-1 à été
conçue pour être utilisée au dessus de connexions DBR offrant un service d’émulation de circuits.

Le trafic est caractérisé par son débit crête qui est contrôlé à l’interface du réseaux. Les paramètres de con-
trôle sont donc PCR et CDVT. Les paramètres de QoS spécifiés sont le délai de transfert maximum (noté
max_CTD pour maximum Cell Transfer Delay), la gigue ou variation du délai (notée Peak-to-Peak CDV) et le
taux de perte de cellules (CLR).
La gestion des ressources du réseaux pour cette classe de service est relativement simple et consiste en une
légère sur-allocation de la bande passante du circuit virtuel (ou du chemin virtuel). Un buffer peut être utilisé à
l’entrée du réseau pour l’espacement des cellules à la manière du contrôleur-espaceur développé au CNET [38].

27
Contrôle de trafic ATM pour sources vidéo à débit variable

Selon l’utilisation ou non d’espacement à l’entrée du réseau, différents modèles peuvent être utilisés pour
l’allocation des ressources e.g. l’analyse du système nD/D/1 utilisant un modèle de trafic WCT (Worst Case Traf-
fic) peut être utilisé dans le cas de trafic non espacé alors que M/D/1 ou M+D/D/1 est plus approprié pour un trafic
espacé [7].

3.3.2 Statistical Bit Rate (SBR)

Cette capacité permet de gérer les trafics à débit variable ayant des contraintes de QoS. Elle correspond aux
catégories de services VBR-rt (comme real-time) et VBR-nrt (comme non-real-time) de l’ATM-Forum. En princ-
ipe, cette classe doit permettre de réaliser un gain statistique de multiplexage. Aussi, la classe SBR doit permettre
de gérer le trafic vidéo et audio à débit variable pour les applications à contraintes de QoS.

Dans cette capacité de transfert, le descripteur de trafic comprend le débit crête PCR, la tolérance de gigue
CDVT, le débit soutenu SCR et la tolérance de rafale IBT. L’ITU-T définit trois types de classes SBR selon l’usage
du bit CLP et l’utilisation du marquage de cellules. La QoS spécifiée par la source comprend le taux de perte de
cellules CLR. En ce qui concerne le délai, les paramètres CDV et CTD sont spécifiés pour VBR-rt (à l’instar de la
classe DBR). Pour VBR-nrt, le délai est spécifié par sa valeur moyenne (notée Mean CTD) au lieu de la valeur
maximale et la gigue.

Les spécifications de l’ITU-T ne distinguent pas le caractère temps réel ou non temps réel des connexions.
Cependant, cette distinction se retrouve dans le choix d’une classe de qualité de service. En particulier, les ser-
vices à contraintes de temps requièrent une QoS équivalente à celle du DBR. Cette thèse s’intéresse précisément
aux services à contraintes de temps dans le cadre de la capacité SBR.

La gestion des ressources pour SBR est toujours au stade de la recherche. Les difficultés inhérents à cette
classe proviennent des garanties requises sur les pertes et les délais qui sont en compromis direct avec le multi-
plexage statistique. En effet, plus on charge le réseau et plus le contrôle des files d’attente devient difficile [38].

Quelques solutions basées sur la notion de débit équivalent (Equivalent Bandwidth) [22, 37, 71] ont été pro-
posées. La limitation de ces mécanismes provient de la modélisation du trafic qui est souvent basée sur des
paramètres statistiques non contrôlable par le réseau et ne peuvent donc pas s’inscrire dans le cadre du contrôle
préventif du RNIS-LB. Le chapitre 4 présente une discussion sur les modèles de trafic et leurs adéquation au con-
trôle de trafic préventif ainsi que quelques solutions pour l’allocation de ressources dans la classe SBR.

Il convient ici de soulever le problème de conformité de la source au contrat de trafic négocié. Si la source
émet des cellules excédant le contrat de trafic, celles-ci sont détectées par le GCRA et sont rejetées à l’interface
réseau. Ceci induit alors un taux de perte initial qui peut être très élevé et qui ne dépend que du comportement de
la source de trafic. Quand il s’agit de contrat de trafic, il est nécessaire pour la source de pouvoir contrôler son
débit pour le forcer à être conforme au contrat de trafic. Ainsi, les seules pertes à considérer sont celles qui ont
lieu à l’intérieur du réseau.

3.3.3 ATM Bloc Transfer (ABT)

La classe de gestion de trafic ABT est établie par l’ITU-T et n’a pas de correspondant à l’ATM-Forum. Basée
sur les protocoles à réservation rapide (FRP) développés au CNET [8] permettant l’allocation dynamique des res-
sources, le trafic ABT consiste en une succession de blocs de cellules de durée arbitraire transmises à un débit con-
stant durant tout le bloc. Le débit varie d’un bloc à l’autre. Au début de chaque bloc la source sollicite un nouveau
débit. Les blocs de cellules sont délimités par des cellules de gestion (cellules RM). Deux variantes possibles sont
spécifiées : ABT/DT (pour Delayed Transmission) où une négociation -par échanges de cellules RM- du nouveau
débit entre la source et le réseau précède la transmission du bloc, et ABT/IT (pour Immediate Transmission) où le
bloc de cellules est transmis immédiatement après la cellule RM indiquant le débit requis. Les paramètres de trafic
et de QoS pour un bloc, si celui-ci est accepté dans le réseau, sont les même que pour DBR. On parle de contrôle
d’admission au niveau rafale (i.e. bloc).

28
 Contrôle de trafic dans les réseaux ATM

En ce qui concerne les performances de la capacité ABT, la qualité de service vue par les cellules d’un bloc
accepté est équivalente à celle de la classe DBR, i.e., taux de perte négligeable et délai très faible. L’indice de per-
formance qui devient significatif pour ABT est le taux de blocage de rafale (refus par le réseau de la réservation du
débit requis pour un bloc) qui se peut aussi se traduire en délai d’acceptation du bloc pour ABT/DT (du à la répéti-
tion de la requête jusqu’à acceptation) et en taux de perte de blocs pour ABT/IT. Les performances en termes de
taux de blocage de la rafale dépendent des caractéristiques du trafic et du débit du multiplex (ou du chemin virtuel
supportant l’ABT). Pour pouvoir offrir une guarantie de QoS pour les application au dessus de ABT, il faudrait
développer des mécanismes CAC permettant de maîtriser la probabilité de blocage à l’échelle de la rafale.

3.3.4 Available Bit Rate (ABR)

La capacité ABR, introduite par l’ATM-Forum, fait également l’objet de normalisation ITU-T. Elle s’adresse
aux applications qui peuvent adapter leur débit d’émission à l’état de congestion du réseau. Contrairement à DBR
et SBR, ABR utilise un principe de contrôle réactif du trafic où les sources reçoivent des signaux du réseau pré-
cisant les variations du débit disponible. Ces signaux sont basés sur des cellules de gestion (cellules RM)
échangées entre la source et le réseau. Deux mécanismes de contrôle réactif ont été proposés et longuement débat-
tus à l’ATM-Forum : contrôle par le crédit et contrôle par le débit. A l’état actuel, la choix a été fait en faveur du
contrôle par le débit où, selon les implantations, la source adapte son débit soit à des notifications explicites de
congestions (aussi appelé mode binaire) ou à des indications explicites du débit disponible (Explicit Rate Indica-
tion). La classe ABR est particulièrement adaptée aux applications de données pour lesquelles le délai réseau est
sensiblement moins contraignant que les pertes de données.

Dans la version de juillet 1995 de la recommandation I.371 de l’ITU-T, les paramètres de trafic d’une con-
nexion ABR spécifient le débit crête (PCR) et le débit minimal (MCR). La conformité du débit de la source aux
valeurs indiquées par le réseau est contrôlée par un GCRA dont les paramètres varient dynamiquement avec le
débit autorisé par le réseau.

En ce qui concerne la qualité de service, le principe de l’ABR est qu’une source qui se conforme aux signaux
du réseau observe un taux de perte négligeable et a la garantie de pouvoir toujours émettre à un débit supérieur ou
égal à MCR. Aucune garantie n’existe quand au délai. D’autres propriétés qualitatives sont aussi envisagées tel
que l’équité (Fairness) entre les sources ou le fait que les délais n’excédent pas les limites d’opérabilité des
couches supérieures.

3.3.5 Unspecified Bit Rate (UBR)

Cette capacité est définie uniquement par l’ATM-Forum. Son principe, basé sur la philosophie Best Effort de
l’actuel Internet, consiste en l’absence de contrat de trafic pour l’utilisateur et l’absence d’engagements du réseau
sur la qualité de service. Le débit crête en terme de PCR et CDVT peut cependant être spécifié mais ne sera pas
nécessairement contrôlé à l’UPC. Les performances du service UBR peuvent être désastreuses en présence d’un
taux de perte de cellules élevé. En effet, une cellule perdue engendre la perte de tout le paquet AAL-5 dont elle fait
partie. L’implantation des commutateurs avec service UBR est donc souvent enrichie de mécanismes de pertes
cohérentes des cellules d’un même paquet comme les mécanismes EPD (Early Packet Discard) ou PPD (Partial
Packet Discard) [108].

3.4 Conclusion

L’évolution des spécifications des capacités de transfert ATM reflète le degré de maturité des réseaux ATM
publics par rapport aux objectifs ambitieux que se sont fixées les premières recommandations du RNIS-LB. En
effet, la définition de la classe DBR, de la couche AAL-1, du GCRA etc... permet de construire un service équiva-
lent à celui des réseaux synchrones (SDH, RNIS bande étroite). De même, un service AAL-5 associé à ABR ou
UBR sera équivalent aux réseaux de commutation de paquets comme X25, Frame Relay etc... Cependant, ceci ne

29
Contrôle de trafic ATM pour sources vidéo à débit variable

suffit peut-être pas à justifier la viabilité économique à long terme d’un RNIS-LB car l’apport substantiellement
nouveau préconisé par les réseaux ATM, en termes d’intégration des services, reste celui de pouvoir gérer les
débits variables tout en offrant une qualité de service comparable à celle des réseaux synchrones. Les raisons de
cette insuffisance sont les suivantes :
• DBR offre un service au mieux équivalent à la commutation de circuits avec cependant une diminution du ren-
dement due à la couche ATM (qui dé-synchronise les données) et AAL-1 (qui les re-synchronise),
• UBR offre un service au mieux équivalent à un réseau de paquets rapide et de type Best Effort,
• ABR, moyennant des mécanismes relativement complexes, offre un service du type transfert de données,
• ABT requiert encore la maîtrise du taux de blocage au niveau de la rafale
• SBR, spécifiquement VBR-rt, constitue un défi fondamentalement nouveau pour l’ingénierie de trafic (ce qui
explique le retard dans le développement de mécanismes de gestion de ressources associés) et se présente par
la même occasion comme le “challenge” du RNIS-LB face aux réseaux publics mono-service.
La capacité SBR reste donc la plus difficile à gérer. D’un point de vue ingénierie de trafic, toutes les autres
capacités constituent des cas particuliers de SBR. Le problème fondamental étant la définition de paramètres de
trafic qui soient à la fois déclarables par l’utilisateur, contrôlable par l’UPC et suffisamment descriptifs du trafic
en question pour la gestion des ressources. Par exemple, si le trafic d’une source donnée peut être décrit suffisam-
ment précisément par un processus aléatoire (e.g. chaîne de markov) défini par des paramètres statistique tel que
moyenne, variance, coefficient d’auto-corrélation, un algorithme CAC efficace peut être défini en utilisant ces
paramètres. Cependant, le problème qui se pose est la signification pour un utilisateur de ces paramètres (déclara-
bilité) d’une part, et leur contrôle en temps réel d’autre part. C’est pour cela que l’ITU-T a défini des paramètres
algorithmiques parfaitement contrôlables par le réseau même si leur sémantique pour l’utilisateur ainsi que leur
représentativité du trafic n’est pas encore très claire. Ainsi, la caractérisation d’une source en terme de SCR, IBT,
PCR et CDVT ou le développement d’un contrôle d’admission basé sur ces paramètres restent largement à l’ordre
du jour de la recherche dans le domaine. Le but de cette thèse est de contribuer à la gestion de la capacité SBR,
dans le cas particulier du trafic vidéo à débit variable.

30