3.1 Présentation générale des réseaux ATM. Chapitre 3 Contrôle de trafic dans les réseaux ATM. Résumé

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 contrô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éventif et le contrôle réactif. Les principes du contrôle préventif sont ensuite détaillés en termes de contrôle d admission, 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 normalisation 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 diffé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é Exemples de services Emulation de circuit, Vidéo à débit constant Vidéo/Audio à débit variable Transfert de données en mode connecté Transfert de données en mode datagramme 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 Protocol) 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 connexions. Le contrôle de trafic désigne alors l ensemble des actions du réseau qui permettent d éviter les congestions. 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 tableau2. 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 garantie sur la QoS. Le contrôle de trafic et le contrôle de congestion doivent alors supporter un ensemble de classes de QoS correspondant 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 deuxiè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 éventuelle 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 émission 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 satisfaisante. 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 terminaux. 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 connexions 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 connexion, 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 ensemble 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 connexions 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 apriori, 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 ressources 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 correspondante. 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 algorithmes de contrôle d admission [22,37,71]. Dans les réseaux publics, la procédure CAC fait partie du plan gestion 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 connexions 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 interface réseaux-réseaux ou NNI (pour Network-to-Network Interface). Dans le contexte de l ITU-T, la recommandation 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 Tolerance). 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 instantané 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 ), Nst (, ) 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 cellules é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 fonction 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 contrat 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-continentaux [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 nouvelle connexion (e.g. réservation de ressources) ainsi que le contrôle de ces ressources tout au long de la connexion (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éterminée en fonction des paramètres du trafic, de la QoS demandée et de l état du réseau. La disponibilité de ces ressources 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 cellules 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 connexions 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 c i (t) alloué à la i ème connexion de poids α i est donnée par: 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 R i et M i, les actions suivantes: réserver un buffer de taille M i 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 à M i /R i 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 α i αj c i () t = C -------------------- j Ω() t Comme le RNIS-LB est un réseau multi-services, une architecture des services a été défini par les organismes 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 utilisent 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 contrô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 Traffic) 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 principe, 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 services à 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 multiplexage 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é proposé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 contrô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 ressources, le trafic ABT consiste en une succession de blocs de cellules de durée arbitraire transmises à un débit constant 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 performance 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étition 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ébattus à 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 Indication). 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 connexion 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 équivalent à 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 rendement 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 suffisamment 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éclarabilité) 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