contrôle de trafic dans les réseaux atm

8/9/2019 Contrle de trafic dans les rseaux ATM

1/10

21

C h a p i t r e 3

Contrle de trafic dans les rseaux ATM

Rsum

Ce chapitre dcrit lessentiel de la normalisation des rseaux ATM en dtaillant laspect contrle de trafic et con-

trle de congestion. Aprs avoir introduit les rseaux ATM, le RNIS large bande et la couche dadaptation, une

prsentation du contrle de congestion permet de distinguer deux types de contrle de trafic : le contrle prven-

tif et le contrle ractif. Les principes du contrle prventif sont ensuite dtaills en termes de contrle dadmis-

sion, contrat de trafic, gestion de ressources et capacits de transfert. Enfin, une conclusion permet de placer

cette thse dans le cadre de la capacit de transfert SBR/VBR-rt.

3.1 Prsentation gnrale des rseaux ATM

Le rseau numrique intgration de services large bande (RNIS-LB) se prsente comme la phase ultime de

dveloppement des rseaux de tlcommunication depuis lre de la tlphonie analogique. Il fut cr parlinstance internationale de normalisation des tlcommunication, le CCITT, et poursuivi par lITU-T, sous forme

dune srie de recommandations qui dfinissent tous les aspects, allant du vocabulaire la signalisation en passant

par le plan dadressage (les recommandations de base sont cites dans [56 67]). Une tape importante de la nor-

malisation fut ladoption du mode de transfert asynchrone (ATM) comme technologie de base pour le RNIS-LB.

Lautre acteur dterminant dans lvolution des rseaux ATM est lATM-Forum. Cre en novembre 1991

par un consortium de quelques industriels, il comprend lheure actuelle plus que 600 industriels intresss par

cette technologie. Les spcifications de lATM-Forum qui concernent linterface entre lutilisateur et le rseau

sont dcrites dans le documentATM User-Network Interface Version 4 souvent rfrence dans cette thse [25].


2/10

Contrle de trafic ATM pour sources vido dbit variable

22

Vu le nombre important de publications, thses 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 rpte en

cela les ouvrages de G. PUJOLLE, P. ROLIN..., nous ne dcrivons dans la suite de ce chapitre et dune manire

concise, que les concepts qui sont utiles dans le contexte du contrle de trafic et de vido dbit variable.

3.1.1 Le mode de transfert asynchrone

Le mode de transfert asynchrone, se base sur lutilisation de cellules de donnes de taille fixe gale 53

octets dont 5 pour lentte ATM. Le transport de ces cellules dans le rseau nest pas synchronis au rythme de

lmetteur (ou terminal ATM) do laspect asynchrone de lATM. Le transfert des donnes sur ATM se fait en

mode connect. Le modle de rfrence de la couche ATM se trouve dans I.361 [63].

Les supports physiques utiliss dans les rseaux ATM sont la hirarchie digitale synchrone (SDH) et la

hirarchie digitale pleisiochrone (PDH). Des commutateurs ATM existent dj sur le march et des maquettes de

rseaux nationaux sont dj oprationnelles dans plusieurs pays. Outre les rseaux publics, la technologie ATM

trouve largement sa place dans le monde des rseaux locaux. Lavantage tant linterconnexion facile via la

RNIS-LB. Cet aspect LAN de lATM intresse plus lATM-Forum que lITU-T. Par exemple, le groupe de travailAF-LANE (ATM-Forum LAN Emulation) travaille sur lmulation, sur les rseaux locaux ATM, des services

rseaux classiques tel que la rsolution dadresse ou la diffusion.

3.1.2 La couche dadaptation

Comme le stipule le document [62] de description fonctionnelle de la couche dadaptation de lATM (note

AAL), celle-ci permet damliorer les services offerts par la couche ATM pour les fonctions requises par la

couche immdiatement suprieure. LAAL supporte des protocoles multiples pour rpondre aux besoins des dif-

frents usagers de cette couche. LAAL dpend donc du service offert.

Afin de rduire le nombre dAAL, une classification des services a t dfinie par lITU-T [62] et permet de

distinguer quatre classes de services dcrites dans le tableau 2. Les AAL actuellement suggres [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, utilise en particulier pour la signalisation,

AAL-5 : pour classes de service C et D, propose par lATM-Forum.

La couche AAL est divise 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

dernire sous-couche est dpendante du service offert et est elle mme sub-divises en deux parties : la partie

commune ou CPCS (pour Common Part Convergence Sublayer) et la partie spcifique au service ou (SSCS pour

Service Specific Convergence Sublayer). Les spcifications de CPCS sont prvues dans la recommandation I.363.

Classe A Classe B Classe C Classe D

Synchronisation Requise Non requise

Dbit binaire Constant Variable

Mode de connexion Connect Non connect

Exemples de

services

Emulation de cir-

cuit, Vido

dbit constant

Vido/Audio

dbit variable

Transfert de don-

nes en mode

connect

Transfert de don-

nes en mode dat-

agramme

Tableau 2 : Classification des services pour lAAL


3/10

23


Au sein de la couche SSCS, le protocole SSCOP (pour Service Specific Connection Oriented Peer-to-Peer Proto-

col) a t dfini [Q.SAAL1] pour la signalisation. Le service SSCOP est utilis par une fonction de coordination

(faisant partie de SSCS) qui sappelle SSCF (pour Service Specific Coordination Function) spcifie dans

[Q.SAAL2].

3.1.3 Contrle de congestion

Dans le RNIS-LB, la notion de congestion dans la couche ATM, est dfinie comme un tat des lments du

rseau o les performances du rseau se dgradent en de des valeurs ngocies lors de ltablissement des con-

nexions. Le contrle de trafic dsigne alors lensemble des actions du rseau qui permettent dviter les conges-

tions. De mme, le contrle de congestion dsigne lensemble des actions du rseau qui permettent de minimiser

lintensit et les effets dun ventuel tat de congestion.

Introduisons dabord les quatre classes de QoS qui ont t dfinies par lATM-Forum et qui correspondent

respectivement aux besoins des quatre classes de service du tableau 2. LATM-Forum a aussi dfini les classes de

QoS non spcifies qui correspondent aux services de typeBest Efforto lapplication ne demande aucune garan-

tie sur la QoS.

Le contrle de trafic et le contrle de congestion doivent alors supporter un ensemble de classes de QoS cor-

respondant aux besoins des services actuels ainsi que les services futurs envisags pour le RNIS-LB, et ceci sans

faire appel des amliorations de performances dans la couche AAL ou dans des couches suprieures. Un deux-

ime objectif implicite est de maximiser le rendement (ou facteur dutilisation) du rseau.

Deux types de contrles de trafic peuvent tre envisags : contrle prventif et contrle ractif. Comme son

nom le suggre, le contrle prventif consiste prendre des mesures a priori, i.e. avant loccurrence dune ven-

tuelle congestion, pour minimiser les chances de son apparition. Par exemple, les rservations de bande passante

ou de mmoires dans le rseau font partie du contrle prventif. Le fait que la connexion dclare le dbit dmis-

sion est aussi utilis pour des actions prventives (e.g. les rservations). La philosophie du contrle prventif est

de protger le rseau contre les rafales de donnes mises, et ce afin de pouvoir assurer une qualit de service sat-

isfaisante.

Contrairement au contrle prventif, le contrle ractif agit en fonction de lvolution de ltat de rseau, il

ragit la congestion. Dans ce cas, le rseau accepte toutes les connexions et tant quil ny a pas de congestion

celles ci peuvent mettre le dbit qui leur convient. La mesure de congestion peut se faire de plusieurs manires

(e.g.: en mesurant les pertes, les dlais, le remplissage des buffers...) par le rseau ou par les quipements ter-

minaux. Si une congestion se dclare les connexions diminuent leur dbit. Un exemple bien connu de contrle

ractif est le mcanisme de fentre de congestion du protocole TCP/IP dfini par Van Jacobson [68] et utilis dans

lactuel Internet. La philosophie du contrle ractif est de pouvoir partager les ressources par le maximum de con-

nexions pour optimiser lutilisation du rseau. De ce fait, ce type de contrle peut tre appropri aux connexions

de donnes qui peuvent sadapter aux conditions du rseau. Cependant, il nest pas adapt aux connexions qui

ncessitent une garantie de qualit de service (comme cest le cas des services vido temps rel).

Initialement, lITU-T avait choisi une politique compltement prventive de contrle du trafic [55]. Alheure actuelle, sous limpulsion de lATM-Forum, le contrle ractif revient lordre du jour avec la capacit de

transfert ABR dfinie plus loin dans ce chapitre.

Dans le cadre de cette thse, nous considrons que les services contraintes de temps ncessitent un contrle

de trafic prventif ; cest pourquoi nous le retenons dans le contexte de ltude des services vido dbit variable

dans les rseaux ATM. Dans le paragraphe suivant, nous exposons les principes du contrle de trafic prventif, tel

que spcifis dans les documents de normalisation.


4/10


24

3.2 Contrle prventif de trafic

Les documents de base dcrivant le contrle de trafic ATM dans le RNIS-LB sont la recommandation I.371

de lITU-T [55] et le ATM-Forum UNI Specification V3.1 [25]. Dans la suite, le contrle prventif de trafic seradsign par le terme contrle de trafic tout court. En cas dambigut, ladjectifractifouprventifsera utilis

pour plus de prcision.

Le contrle de trafic dans la couche ATM se base sur la dclaration de paramtres de trafic et le contrle par

le rseau de la conformit du trafic ces paramtres. En effet, lors de la demande dtablissement de la connex-

ion, lutilisateur (ou le terminal ATM) dclare un certain nombre de paramtres dcrivant son trafic. Ces

paramtres sont utiliss par le rseau pour prendre des mesures prventives pour viter les congestions. Lensem-

ble de ces paramtres sappelle descripteur du trafic de la source ou STD (pour Source Traffic Descriptor). Outre

les paramtres de trafic, lutilisateur spcifie les valeurs dsires des attributs de qualit de service (QoS) requises

par la connexion. Par exemple, le dlai et le taux de perte sont des attributs de la qualit de service. Le rseau

dcide alors daccepter ou de refuser la connexion selon quil estime pouvoir, ou non, satisfaire les contraintes de

QoS spcifies. La procdure qui lui permet de dcider sappelle procdure de contrle dadmission ou CAC

(pour Connection Admission Control). Si la connexion est accepte, le rseau contrle le trafic effectivement mis

par la source durant toute la connexion pour vrifier sa conformit aux paramtres de trafic (STD) dclars. Le

contrle est fait la vole et en temps rel, et les cellules non conformes peuvent tre rejets ou admises, selon la

politique de loprateur. Le rseau dfinit une politique dallocation et de partage de ses ressources entre les con-

nexions dont le but est de respecter la qualit de service ngocie tout en maximisant lutilisation des ressources

du rseau.

Dans le suite de cette section, nous prsentons les principes du contrle dadmission, des paramtres de trafic

et la gestion des ressources dans les rseaux ATM.

3.2.1 Contrle dadmission

Cest lalgorithme droul par le rseau pour dcider lacceptation ou le rejet dune demande dtablissementdune connexion. Le principe de la CAC consiste prdire si, en acceptant le nouveau trafic, le rseau pourra

garantir la QoS de la nouvelle connexion ainsi que celles des connexions dj en cours. Comme cest une dcision

a priori, la connaissance du nouveau trafic se limite aux paramtres dclars par lutilisateur. Lefficacit de

lalgorithme de la CAC est alors largement dpendante des paramtres de trafic utiliss.

Il est possible de dvelopper des algorithmes de CAC en se basant sur des hypothses de trafic. Par exemple,

si on suppose que les trafics sont poissonniens, ltude de la file M/D/1/K permet dindiquer le montant de ressou-

rces ncessaires pour accepter la connexion. De mme, en supposant que le trafic soit de type ON/OFF (rafales

suivies de silences de longueurs exponentiellement distribues) il est possible de dvelopper la CAC correspon-

dante. Ainsi, plusieurs travaux ont t publis et se basent sur des paramtres plus ou moins sophistiqus du trafic.

Le bande passante ncessaire une connexion, appel dbit quivalent, est trs utilise pour dfinir des algo-

rithmes de contrle dadmission [22, 37, 71]. Dans les rseaux publics, la procdure CAC fait partie du plan ges-

tion du rseau et ne dpend que du choix de loprateur, elle ne fait pas lobjet de normalisation. Les

performances dune procdure CAC dpendent des hypothses de trafic. Dans le cadre des rseaux ATM, pour

quune procdure CAC soit significative, il faut quelle soit base sur les paramtres de trafic dfinis pour les con-

nexions ATM.


5/10

25


3.2.2 Contrat de trafic et contrle des paramtres

Le contrat de trafic entre lutilisateur (ou le terminal) et le rseau ATM consiste dclarer les paramtres

standards de trafic (STD) ainsi que les paramtres de QoS dsirs [55]. En acceptant la connexion, le rseausengage garantir la QoS et lutilisateur sengage respecter les paramtres STD. Pour tre significatif, les

paramtres STD doivent vrifier les proprits suivantes :

tre simple pour lutilisateur (pour quil puisse les dclarer),

tre contrlable en temps rel par le rseau,

tre significatif pour la CAC et lallocation des ressources.

La fonction qui permet de contrler la conformit aux paramtres de trafic sappelle fonction de police ou

UPC (pour Usage Parameter Control). LUPCest situe dans les interfaces utilisateur-rseaux ou UNI (pour

User-to-Network Interface). Une fonction semblable, la NPC (Network Parameter Control) se situe dans linter-

face rseaux-rseaux ouNNI(pourNetwork-to-Network Interface). Dans le contexte de lITU-T, la recommanda-

tion I.371 dfinit les paramtres de trafic suivants :

le dbit crte ou PCR (pour Peak Cell Rate). La gigue cellule ou CDVT(pour Cell Delay Variation Tolerance)

est aussi un paramtre associ la dfinition du dbit crte. Le dbit crte signifie le dbit maximal auquel lasource est autorise mettre. Comme le trafic dune source est multiplex dune manire asynchrone avec

celui des autres sources, le flux original de la source se trouve modifi son arrive linterface : cest la

gigue du multiplexage asynchrone. Le paramtre CDVTsert justement tenir compte de cette gigue. Il dfinit

la gigue maximale qui peut affecter une cellule. Ces deux paramtres, PCR et CDVT, permettent par exemple

de caractriser un trafic dbit constant PCR dont la gigue introduite par le multiplexage asynchrone est

dcrite par CDVT. Lalgorithme permettant de vrifier la conformit dun flux de cellules ces deux

paramtres sappelle GCRA (pour Generic Cell Rate Algorithm)1 et est prsent plus loin dans ce paragraphe.

le dbit soutenu ou SCR (pour Sustainable Cell Rate) et la tolrance de rafale ouIBT(pourIntrinsic Burst Tol-

erance). Le paramtre SCR reprsente une estimation du dbit long terme de la source, ou plus prcisment,

une borne suprieure du dbit moyen. Le paramtreIBTpermet de limiter lcart cumul entre le dbit instan-

tan et SCR. Il contrle la variabilit du trafic. En dautres termes,IBTpeut tre mise en relation directe avec

la taille maximale du buffer ncessaire pour accommoder le trafic en question dans un canal dbit constantgal SCR. PlusIBTest faible et plus le trafic tend tre constant. Les paramtres SCR,IBT, PCR et CDVT,

servent caractriser un trafic dbit variable. Lalgorithme GCRA permettant de contrler la conformit

dun flux aux deux paramtres retM, ces derniers sont en relation directe avec SCR etIBT. Ainsi, lUPC qui

contrle les paramtres dun trafic variable consiste en deux modules GCRA qui sexcutent simultanment,

le premier contrlant les paramtres PCR et CDVTet le deuxime, les paramtres SCR etIBT. Une cellule est

conforme si elle est dclare comme tel par les deux modules.

Lalgorithme GCRA a t normalis par lITU-T en 1992. Il peut tre dcrit de plusieurs manires plus ou

moins faciles comprendre. Une manire simple est de le dfinir par rapport au modle du seau perc ou leaky

bucket[99, 114]. Le leaky bucketest dfinit par deux paramtres : le dbit de fuiteR (leak rate) et la taille du

buffer virtuelM(virtuel buffer size ou token pool size). Chaque cellule admise dans le rseau incrmente la taille

du buffer virtuel qui est continment vid au dbitR. Si la taille du buffer atteintM, la cellule entrante est dclare

non conforme. Le GCRA est alors quivalent un leaky bucketdont les paramtres PCR et CDVTconcidentrespectivement avec R et M. Autrement dit, un cellule rejet du leaky bucketest dclare non conforme par le

GCRA. Lalgorithme du GCRA nest autre que limplmentation du leaky bucketsous forme dun compteur qui

dcrit le remplissage du seau.

Dune manire gnrale, si on appelleN(s,t) le nombre de bits gnrs par une source entre les instants s et t,

la conformit un modle de leaky bucketde paramtresR etMscrit :

1. Il est aussi appel Contineous State Leaky Bucketou encore Virtual Scheduling Algorithm.

s t,( ) N s t ,( ) R t s( ) M+,


6/10


26

Le trafic dune source peut tre dcrit de plusieurs manires selon lchelle de temps sur laquelle on le dfinit :

lchelle paquet, le trafic est une suite de paquets de taille variable. Cest le cas par exemple dune source IP

ou dun trafic vido dfini par la taille de ses images.

lchelle cellulaire, le trafic est une suite de cellules ATM, de taille fixe, etN(s,t) dsigne le nombre de cel-

lules mises entre les instants s et t. Dans ce casR est exprim en cellules par seconde etMen cellules.

lchelle fluide, le trafic est considr comme un fluide dont lintensit en bits/s, notons laR(t), est une fonc-

tion continue du temps. Dans ce casN(s,t) est gale lintgrale deR(t) entre s et t.

Le leaky bucketpeut tre dfini pour toutes ces manires de description du trafic. Dans le chapitre 5 par

exemple, on dcrit un leaky bucketoprant lchelle du GoP.

Une autre manire de dfinir le leaky bucketconsiste dire que la conformit dune source aux paramtres r

etMest quivalente la condition de non-rejet dune file dattente G/D/1/K alimente par la mme source et dont

le dbit de service est gal ret la taille du buffer est gal M. Une illustration de cette analogie se trouve dans

[38].

Deux niveaux de priorits sont dfinis pour les cellules ATM grce au bit CLP (pour Cell Loss Priority) de

lentte de la cellule qui est mis zero pour indiquer les cellules prioritaires. Les cellules non conformes au con-trat de trafic peuvent tre soit rejetes soit admises en classe non prioritaire. La dfinition du bit CLP a en fait t

une source dambigut pour le processus de normalisation. Par exemple, la recommandation I.371 a envisag

autorise la dclaration des paramtres de trafic du flux prioritaire (not flux CLP=0) en plus des paramtres de la

totalit du trafic (not CLP=0+1). LATM-Forum lui, semble autoriser la dclaration des paramtres SCR etIBT,

sparment pour chacun des flux CLP=0 et CLP=1.

Finalement, le rseau peut aussi exploiter des proprits prdictibles de certains trafics, quon peut aussi

appelerparamtres implicites. Cest le rle du champs Service Type dfini par la recommandation I.371. Cest

la cas, par exemple, des conversations tlphoniques compresses (e.g. le codage TASI pour Time Assigned

Speech Interpolation) utilis par les oprateurs tlphoniques pour doubler la capacit des liens trans-continen-

taux [84].

3.2.3 Gestion des ressources

La gestion des ressources est lensemble des actions menes par le rseau lors de lacceptation dune nou-

velle connexion (e.g. rservation de ressources) ainsi que le contrle de ces ressources tout au long de la connex-

ion (e.g. priorits et ordonnancement).

Pour garantir la QoS dune connexion, il est en gnral ncessaire de rserver de la mmoire et/ou de la

bande passante dans les commutateurs et autres lments du rseau. La quantit des ressource rserves est dter-

mine en fonction des paramtres du trafic, de la QoS demande et de ltat du rseau. La disponibilit de ces res-

sources est contrle par lalgorithme de la CAC. Par exemple, si le montant des ressources disponibles est

infrieur au dbit quivalent de la connexion rentrante, celle-ci est rejete.

Dans certains cas, la rservation des ressources ne suffit pas garantir la QoS. En effet, si les flux sonthtrognes, les rafales de certaines connexions (comme les connexions de donnes) peuvent perturber les cel-

lules des connexions temps rel. Lutilisation de disciplines de services dans les commutateurs, autres que FIFO

devient alors ncessaire [13]. Lide dintroduire des mcanismes dordonnancement plus ou moins sophistiqus

dans les commutateurs est de plus en plus rpandue malgr la complexit des implmentations matrielle oprant

trs haut dbit [36, 105]. Parmi ces mcanismes, le fait de pouvoir affecter des priorits aux connexions permet

den protger les plus prioritaires des perturbations de trafic des moins prioritaires. Cependant, le fait daffecter

des priorits aux connexions nest pas suffisant pour les rseaux intgration de services [13].

Un mcanisme dordonnancement de paquets particulirement intressant pour les rseaux intgration de

services est le Partage Gnralis du Processeur ou GPS (pour Generalized Processor Sharing) [92]. Dautres

versions sont aussi connues sous le nom de Weighted Fair Queueing (WFQ) [21], Virtual-Clock[110] ou Self-


7/10

27


clocked WFQ [36]. Le principe du GPS consiste partager tout instant le dbit du canal, not C, entre les con-

nexions proportionnellement un poids affect chacune delle. Si lon considre un modle fluide de trafic,

chaque instant t, la fraction de dbit ci(t) allou la ime connexion de poids i est donne par :

o dsigne lensemble des connexions actives linstant t.

Un avantage majeur de ce mcanisme est quil fournit des garanties de QoS quand il est utilis conjointement

avec un contrle de trafic du type leaky bucket. En effet, si chaque connexion i est conforme un leaky bucket

correspondant aux paramtresRi etMi, les actions suivantes :

rserver un buffer de tailleMi pour la connexion i,

utiliser un ordonnancement GPS avec

utiliser un algorithme CACqui vrifie que

permettent de garantir chaque connexion i un dlai dattente infrieur ou gal Mi/Ri et un taux de perte nul.

Une version du GPS spcifique lenvironnement ATM, appele Virtual Spacing, a t dveloppe par James

Roberts au CNET [105]. Les dtails et les proprits de ces ordonnancement existent dans [18, 19, 21, 36, 92,

105, 120].

3.3 Les capacits de transfert ATM

Comme le RNIS-LB est un rseau multi-services, une architecture des services a t dfini par les organis-

mes de standardisation i.e. lITU-Tet lATM-Forum. Bien que les terminologies utilises soient diffrents pour

les deux organismes, nous essayons de rsumer dans ce paragraphe les capacits de transfert (en anglais, ATMTraffic Handling Capabilities) actuellement dfinis ou en cours de dfinition, le type dapplications qui les uti-

lisent et les mcanismes de contrle de trafic correspondants. Les articles [7, 39, 106] donnent une vision plus

globale et des discussions intressantes sur les diffrentes capacits de transfert ATM.

3.3.1 Deterministic Bit Rate (DBR)

Appele aussi Constant Bit Rate (CBR) dans lATM-Forum, cette capacit de transfert est conue pour les

applications temps rel ayant des contraintes strictes sur le dlai et la variation de dlai ainsi que sur les pertes. La

voix et la vido dbit constant sont des exemples typiques de ces applications. La couche adaptationAAL-1 t

conue pour tre utilise au dessus de connexionsDBR offrant un service dmulation de circuits.

Le trafic est caractris par son dbit crte qui est contrl linterface du rseaux. Les paramtres de con-

trle sont donc PCR et CDVT. Les paramtres de QoS spcifis sont le dlai de transfert maximum (not

max_CTD pour maximum Cell Transfer Delay), la gigue ou variation du dlai (note Peak-to-Peak CDV) et le

taux de perte de cellules (CLR).

La gestion des ressources du rseaux pour cette classe de service est relativement simple et consiste en une

lgre sur-allocation de la bande passante du circuit virtuel (ou du chemin virtuel). Un buffer peut tre utilis

lentre du rseau pour lespacement des cellules la manire du contrleur-espaceur dvelopp au CNET [38].

ci t( ) Ci

jj t( )

---------------------=

t( )

i

Ri

C-----=

i 1


8/10


28

Selon lutilisation ou non despacement lentre du rseau, diffrents modles peuvent tre utiliss pour

lallocation des ressources e.g. lanalyse du systme nD/D/1 utilisant un modle 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 grer les trafics dbit variable ayant des contraintes de QoS. Elle correspond aux

catgories de services VBR-rt(comme real-time) et VBR-nrt(comme non-real-time) de lATM-Forum. En princ-

ipe, cette classe doit permettre de raliser un gain statistique de multiplexage. Aussi, la classe SBR doit permettre

de grer le trafic vido et audio dbit variable pour les applications contraintes de QoS.

Dans cette capacit de transfert, le descripteur de trafic comprend le dbit crte PCR, la tolrance de gigue

CDVT, le dbit soutenu SCR et la tolrance de rafaleIBT. LITU-Tdfinit trois types de classes SBR selon lusage

du bit CLP et lutilisation du marquage de cellules. La QoS spcifie par la source comprend le taux de perte de

cellules CLR. En ce qui concerne le dlai, les paramtres CDVet CTD sont spcifis pour VBR-rt( linstar de la

classeDBR). Pour VBR-nrt, le dlai est spcifi par sa valeur moyenne (note Mean CTD) au lieu de la valeurmaximale et la gigue.

Les spcifications de lITU-Tne distinguent pas le caractre temps rel ou non temps rel des connexions.

Cependant, cette distinction se retrouve dans le choix dune classe de qualit de service. En particulier, les ser-

vices contraintes de temps requirent une QoS quivalente celle du DBR. Cette thse sintresse prcisment

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 difficults inhrents cette

classe proviennent des garanties requises sur les pertes et les dlais qui sont en compromis direct avec le multi-

plexage statistique. En effet, plus on charge le rseau et plus le contrle des files dattente devient difficile [38].

Quelques solutions bases sur la notion de dbit quivalent (Equivalent Bandwidth) [22, 37, 71] ont t pro-

poses. La limitation de ces mcanismes provient de la modlisation du trafic qui est souvent base sur desparamtres statistiques non contrlable par le rseau et ne peuvent donc pas sinscrire dans le cadre du contrle

prventif du RNIS-LB. Le chapitre 4 prsente une discussion sur les modles de trafic et leurs adquation au con-

trle de trafic prventif ainsi que quelques solutions pour lallocation de ressources dans la classe SBR.

Il convient ici de soulever le problme de conformit de la source au contrat de trafic ngoci. Si la source

met des cellules excdant le contrat de trafic, celles-ci sont dtectes par le GCRA et sont rejetes linterface

rseau. Ceci induit alors un taux de perte initial qui peut tre trs lev et qui ne dpend que du comportement de

la source de trafic. Quand il sagit de contrat de trafic, il est ncessaire pour la source de pouvoir contrler son

dbit pour le forcer tre conforme au contrat de trafic. Ainsi, les seules pertes considrer sont celles qui ont

lieu lintrieur du rseau.

3.3.3 ATM Bloc Transfer (ABT)

La classe de gestion de traficABTest tablie par lITU-Tet na pas de correspondant lATM-Forum. Base

sur les protocoles rservation rapide (FRP) dvelopps au CNET [8] permettant lallocation dynamique des res-

sources, le traficABTconsiste en une succession de blocs de cellules de dure arbitraire transmises un dbit con-

stant durant tout le bloc. Le dbit varie dun bloc lautre. Au dbut de chaque bloc la source sollicite un nouveau

dbit. Les blocs de cellules sont dlimits par des cellules de gestion (cellulesRM). Deux variantes possibles sont

spcifies :ABT/DT(pourDelayed Transmission) o une ngociation -par changes de cellules RM- du nouveau

dbit entre la source et le rseau prcde la transmission du bloc, etABT/IT(pourImmediate Transmission) o le

bloc de cellules est transmis immdiatement aprs la celluleRMindiquant le dbit requis. Les paramtres de trafic

et de QoS pour un bloc, si celui-ci est accept dans le rseau, sont les mme que pour DBR. On parle de contrle

dadmission au niveau rafale (i.e. bloc).


9/10

29


En ce qui concerne les performances de la capacitABT, la qualit de service vue par les cellules dun bloc

accept est quivalente celle de la classeDBR, i.e., taux de perte ngligeable et dlai trs faible. Lindice de per-

formance qui devient significatif pourABTest le taux de blocage de rafale (refus par le rseau de la rservation du

dbit requis pour un bloc) qui se peut aussi se traduire en dlai dacceptation du bloc pourABT/DT(du la rpti-

tion de la requte jusqu acceptation) et en taux de perte de blocs pour ABT/IT. Les performances en termes de

taux de blocage de la rafale dpendent des caractristiques du trafic et du dbit du multiplex (ou du chemin virtuel

supportant lABT). Pour pouvoir offrir une guarantie de QoS pour les application au dessus de ABT, il faudrait

dvelopper des mcanismes CAC permettant de matriser la probabilit de blocage lchelle de la rafale.

3.3.4 Available Bit Rate (ABR)

La capacitABR, introduite par lATM-Forum, fait galement lobjet de normalisationITU-T. Elle sadresse

aux applications qui peuvent adapter leur dbit dmission ltat de congestion du rseau. Contrairement DBR

et SBR,ABR utilise un principe de contrle ractif du trafic o les sources reoivent des signaux du rseau pr-

cisant les variations du dbit disponible. Ces signaux sont bass sur des cellules de gestion (cellules RM)

changes entre la source et le rseau. Deux mcanismes de contrle ractif ont t proposs et longuement dbat-

tus lATM-Forum : contrle par le crdit et contrle par le dbit. A ltat actuel, la choix a t fait en faveur du

contrle par le dbit o, selon les implantations, la source adapte son dbit soit des notifications explicites de

congestions (aussi appel mode binaire) ou des indications explicites du dbit disponible (Explicit Rate Indica-

tion). La classeABR est particulirement adapte aux applications de donnes pour lesquelles le dlai rseau est

sensiblement moins contraignant que les pertes de donnes.

Dans la version de juillet 1995 de la recommandation I.371 de lITU-T, les paramtres de trafic dune con-

nexionABR spcifient le dbit crte (PCR) et le dbit minimal (MCR). La conformit du dbit de la source aux

valeurs indiques par le rseau est contrle par un GCRA dont les paramtres varient dynamiquement avec le

dbit autoris par le rseau.

En ce qui concerne la qualit de service, le principe de lABR est quune source qui se conforme aux signaux

du rseau observe un taux de perte ngligeable et a la garantie de pouvoir toujours mettre un dbit suprieur ou

gal MCR. Aucune garantie nexiste quand au dlai. Dautres proprits qualitatives sont aussi envisages tel

que lquit (Fairness) entre les sources ou le fait que les dlais nexcdent pas les limites doprabilit des

couches suprieures.

3.3.5 Unspecified Bit Rate (UBR)

Cette capacit est dfinie uniquement par lATM-Forum. Son principe, bas sur la philosophieBest Effortde

lactuel Internet, consiste en labsence de contrat de trafic pour lutilisateur et labsence dengagements du rseau

sur la qualit de service. Le dbit crte en terme de PCR et CDVTpeut cependant tre spcifi mais ne sera pas

ncessairement contrl lUPC. Les performances du service UBR peuvent tre dsastreuses en prsence dun

taux de perte de cellules lev. En effet, une cellule perdue engendre la perte de tout le paquetAAL-5 dont elle fait

partie. Limplantation des commutateurs avec service UBR est donc souvent enrichie de mcanismes de pertes

cohrentes des cellules dun mme paquet comme les mcanismesEPD (Early Packet Discard) ou PPD (Partial

Packet Discard) [108].

3.4 Conclusion

Lvolution des spcifications des capacits de transfert ATM reflte le degr de maturit des rseauxATM

publics par rapport aux objectifs ambitieux que se sont fixes les premires recommandations du RNIS-LB. En

effet, la dfinition de la classeDBR, de la coucheAAL-1, du GCRA etc... permet de construire un service quiva-

lent celui des rseaux synchrones (SDH, RNIS bande troite). De mme, un service AAL-5 associ ABR ou

UBR sera quivalent aux rseaux de commutation de paquets comme X25, Frame Relay etc... Cependant, ceci ne


10/10


30

suffit peut-tre pas justifier la viabilit conomique long terme dun RNIS-LB car lapport substantiellement

nouveau prconis par les rseaux ATM, en termes dintgration des services, reste celui de pouvoir grer les

dbits variables tout en offrant une qualit de service comparable celle des rseaux 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 coucheATM(qui d-synchronise les donnes) etAAL-1 (qui les re-synchronise),

UBR offre un service au mieux quivalent un rseau de paquets rapide et de typeBest Effort,

ABR, moyennant des mcanismes relativement complexes, offre un service du type transfert de donnes,

ABTrequiert encore la matrise du taux de blocage au niveau de la rafale

SBR, spcifiquement VBR-rt, constitue un dfi fondamentalement nouveau pour lingnierie de trafic (ce qui

explique le retard dans le dveloppement de mcanismes de gestion de ressources associs) et se prsente par

la mme occasion comme le challenge du RNIS-LB face aux rseaux publics mono-service.

La capacit SBR reste donc la plus difficile grer. Dun point de vue ingnierie de trafic, toutes les autres

capacits constituent des cas particuliers de SBR. Le problme fondamental tant la dfinition de paramtres de

trafic qui soient la fois dclarables par lutilisateur, contrlable par lUPCet suffisamment descriptifs du trafic

en question pour la gestion des ressources. Par exemple, si le trafic dune source donne peut tre dcrit suffisam-ment prcisment par un processus alatoire (e.g. chane de markov) dfini par des paramtres statistique tel que

moyenne, variance, coefficient dauto-corrlation, un algorithme CACefficace peut tre dfini en utilisant ces

paramtres. Cependant, le problme qui se pose est la signification pour un utilisateur de ces paramtres (dclara-

bilit) dune part, et leur contrle en temps rel dautre part. Cest pour cela que lITU-Ta dfini des paramtres

algorithmiques parfaitement contrlables par le rseau mme si leur smantique pour lutilisateur ainsi que leur

reprsentativit du trafic nest pas encore trs claire. Ainsi, la caractrisation dune source en terme de SCR,IBT,

PCR et CDVTou le dveloppement dun contrle dadmission bas sur ces paramtres restent largement lordre

du jour de la recherche dans le domaine. Le but de cette thse est de contribuer la gestion de la capacit SBR,

dans le cas particulier du trafic vido dbit variable.

contrôle de trafic dans les réseaux atm

Documents