RFC2381 page - 26 - Garrett & Borden

Groupe de travail Réseau

M. Garrett, Bellcore

Request for Comments : 2381

M. Borden, Bay Networks

Catégorie : En cours de normalisation

août 1998

Traduction Claude Brière de L'Isle




Interopération du service à charge contrôlée et du service garanti avec ATM


Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de Copyright

Copyright (C) The Internet Society (1998). Tous droits réservés.


Résumé

Le présent document donne des lignes directrices pour la transposition des classes de service, des caractéristiques et paramètres de gestion du trafic entre les technologies Internet et ATM. Les transpositions de service sont utiles pour fournir une interopération efficace et la qualité de service de bout en bout pour les réseaux IP à intégration de services qui contiennent des sous-réseaux ATM.


L'exposé et les spécifications données ici prennent en charge les protocoles d'intégration de services IP pour le service garanti (GS, Guaranteed Service) le service de contrôle de charge (CLS, Controlled-Load Service) et la spécification UNI de l'ATM Forum, versions 3.0, 3.1 et 4.0. Est aussi incluse une discussion du service IP au mieux sur ATM.


Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS, "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119 [1]. (Noter que dans de nombreux cas, l'utilisation de "DOIT" ou "EXIGE" reflète notre interprétation des exigences d'une norme en rapport avec celle-ci, par exemple, ATM Forum UNI 4.0, rsvp, etc.)


Table des matières

1. Introduction 2

1.1 Architecture générale du système 3

1.2 Documents voisins 4

2. Caractéristiques de protocole majeures pour la gestion du trafic et de la QS 5

2.1 Catégorie de service et capacités du support 5

2.2 Bit de priorité de perte de cellule, étiquetage et définitions de conformité 7

2.3 Couche d'adaptation ATM 8

2.4 Informations de couche basse haut débit 8

2.5 Descripteurs de trafic 8

2.6 Classes et paramètres de QS 11

2.7 Paramètres supplémentaires – Mode d'abandon de trame 13

3. Caractéristiques supplémentaires du protocole d'intégration de services IP 13

3.1 Paramètres de caractérisation de chemin pour services intégrés IP avec ATM 13

3.2 Traitement du trafic excédentaire 14

3.3 Utilisation des paramètres Adspec et Terme de surlongueur du service garanti 15

4. Éléments divers 15

4.1 Conversion d'unités 15

5. Résumé des paramètres d'établissement de VC ATM pour le service garanti 16

5.1 Codage de GS en utilisant le VBR en temps réel (ATM Forum TM/UNI 4.0) 16

5.2 Codage de GS en CBR (ATM Forum TM/UNI 4.0) 17

5.3 Codage de GS en VBR en différé (ATM Forum TM/UNI 4.0) 18

5.4 Codage de GS avec ABR (ATM Forum TM/UNI 4.0) 18

5.5 Codage de GS avec UBR (ATM Forum TM/UNI 4.0) 18

5.6 Codage de GS avec les spécification de ATM Forum UNI 3.0/3.1 18

6. Résumé des paramètres d'établissement de VC ATM pour le service de charge contrôlée 19

6.1 Codage de CLS avec un VBR en différé (ATM Forum TM/UNI 4.0) 19

6.2 Codage de CLS avec ABR (ATM Forum TM/UNI 4.0) 20

6.3 Codage de CLS avec CBR (ATM Forum TM/UNI 4.0) 21

6.4 Codage de CLS avec VBR en temps réel (ATM Forum TM/UNI 4.0) 21

6.5 Codage de CLS avec UBR (ATM Forum TM/UNI 4.0) 21

6.6 Codage de CLS avec les spécifications UNI 3.0/3.1 de l'ATM Forum 21

7. Résumé des paramètres d'établissement de VC ATM pour le service au mieux 22

7.1 Codage du service au mieux avec UBR (ATM Forum TM/UNI 4.0) 22

8. Considérations pour la sécurité 23

9. Remerciements 24

Appendice 1 Abréviations 24

Références 25

Déclaration complète de droits de reproduction 26


1. Introduction


Le problème examiné est celui de la fourniture de services intégrés IP [2] sur un sous-réseau ATM. Le présent document est destiné à être en cohérence avec le protocole RSVP [3] pour les réservations de ressources de niveau IP, bien qu'il s'applique aussi dans le cas général où les services GS et CLS sont pris en charge par d'autres mécanismes. Dans le réseau ATM, on prend en compte la signalisation UNI de l'ATM Forum, versions 3.0, 3.1 et 4.0 [4], [5], [6]. Cette dernière utilise le modèle de service plus complet de la spécification TM 4.0 de l'ATM [7], [8].


C'est un problème complexe qui présente de nombreuses facettes. Dans le présent document, on se concentre sur les types de service, les paramètres et les éléments de signalisation nécessaires pour l'interopération des services. Les transpositions de service résultantes peuvent être utilisées pour fournir une qualité de service (QS) effective de bout en bout pour le trafic IP qui traverse les réseaux ATM.


Les services IP considérés sont le service garanti (GS, Guaranteed Service) [9] et le service à charge contrôlée (CLS, Controlled Load Service) [10]. On expose aussi en parallèle avec eux le service par défaut au mieux (BE, Best Effort Service). Nos recommandations pour BE sont destinées à être cohérentes avec la RFC1755 [11], et [12], qui définit comment les circuits virtuels ATM peuvent être utilisés pour la prise en charge du service IP normal au mieux. Les services ATM qui nous examinons sont :


CBR (Constant Bit Rate) débit binaire constant

rtVBR (Real-time Variable Bit Rate) débit binaire variable en temps réel

nrtVBR (Non-real-time Variable Bit Rate) débit binaire variable en différé

UBR (Unspecified Bit Rate) débit binaire non spécifié

ABR (Available Bit Rate) débit binaire disponible


Dans le cas de la signalisation UNI 3.x, où ces services ne sont pas tous clairement distingués, on identifie les services disponibles appropriés.


On recommande les transpositions de service suivantes, car elles découlent très naturellement des définitions de service :


Service garanti - -> CBR ou rtVBR

Charge contrôlée - -> nrtVBR ou ABR (avec un débit de cellules minimum)

Au mieux - -> UBR ou ABR


Pour être cependant complet, on fournit une transposition détaillée pour toutes les combinaisons de service dans les sections 5, 6, et 7, et on identifie comment chacun satisfait ou manque à satisfaire aux exigences des services IP de niveau supérieur. La raison pour laquelle on ne restreint pas les transpositions aux plus évidentes ou les plus naturelles est qu'on ne peut pas prédire dans quelle mesure ces services seront disponibles avec l'évolution du déploiement de l'ATM. Un certain nombre de différences dans les définitions de service, comme le traitement des paquets excédentaires du descripteur du trafic du flux, rendent la transposition de service un exercice relativement compliqué.


Le reste de la présente introduction fait un exposé général de la configuration du système et des autres hypothèses. La section 2 considère les éléments pertinents du protocole ATM et les caractéristiques correspondantes des services garanti, à charge contrôlée et au mieux (ce dernier étant le "service" par défaut). La section 3 expose un certain nombre d'autres caractéristiques des services IP et la façon dont elles peuvent être traitées sur un sous-réseau ATM. La section 4 traite de la conversion des descripteurs de trafic pour tenir compte des redondances de la couche ATM. La section 5 donne les paramètres détaillés de l'établissement des paramètres du circuit virtuel (VC) pour le service garanti, et considère l'effet de l'utilisation de chaque catégorie de service ATM. La section 6 donne un traitement similaire pour le service à charge contrôlée. La section 7 considère le service au mieux.


Le présent document ne constitue qu'une partie de la solution totale de la fourniture de l'interfonctionnement des services intégrés avec les sous-réseaux ATM. L'importante question de la gestion des VC, y compris les agrégations de flux, est considérée dans [13], [14], [15]. On n'examine pas comment l'acheminement, sensible ou non à la QS, interagit avec l'utilisation des VC ATM. On pense qu'il existera une forte latitude de mise en œuvre, même à l'intérieur des lignes directrices présentées ici. De nombreux aspects de l'interfonctionnement entre IP et ATM vont dépendre de facteurs économiques, et ne seront pas soumis à la normalisation.


1.1 Architecture générale du système

On suppose que le lecteur a des connaissances générales sur les protocoles IP, RSVP et ATM. L'architecture de réseau qu'on prend en compte est illustrée à la Figure 1. Un hôte rattaché à IP peut envoyer des datagrammes en envoi individuel à un autre hôte, ou peut utiliser une adresse IP de diffusion groupée pour envoyer des paquets à tous les hôtes qui se sont "joints à l'arborescence de diffusion groupée". Dans l'un ou l'autre cas, un hôte de destination peut alors utiliser RSVP pour établir une réservation de ressource dans les routeurs le long du chemin Internet pour le flux de données.


Un réseau ATM se tient dans le chemin (choisi par l'acheminement IP) et consiste en un ou plusieurs commutateurs ATM. Il utilise des circuits virtuels commutés (SVC) pour fournir à la fois les ressources et la QS au sein du nuage ATM. Ces connexions sont établies, ajoutées (dans le cas d'arborescences multipoint), supprimées, et contrôlées par les appareils de bordure, qui agissent à la fois comme routeurs IP et interfaces ATM, capables d'initier et de gérer les VC à travers l'interface usager/réseau (UNI, user-to-network interface) ATM. Les appareils de bordure sont supposés être pleinement fonctionnels à la fois dans les protocoles IP int-serv/RSVP et dans les protocoles UNI ATM, ainsi que dans les traductions entre eux.


Nuage ATM

-----------------

H ----\ ( ) /------- H

H ---- R -- R -- E-( X -- X -- X )-E -- R -- R -- H

H ----/ | ( ) \

| ----------------- \------ H

H ----------R


Figure 1 : Architecture de réseau avec hôtes (H), routeurs (R), appareils de bordure (E) et commutateurs ATM (X)


Lorsque on considère les appareils de bordure du point de vue de l'écoulement du trafic de la source vers la destination, l'appareil de bordure amont est appelé le point "d'entrée" et l'appareil aval le point de "sortie". Les appareils de bordure peuvent être considérés comme faisant partie le l'internet IP ou du nuage ATM, ou des deux. Ils traitent les messages RSVP, réservent les ressources, et conservent l'état conditionnel (dans le chemin de contrôle) et classent et programment les paquets (dans le chemin des données). Ils initient aussi les connexions ATM en signalant, et en acceptant ou refusant les connexions qui leur sont signalées. Ils régulent et programment les cellules qui vont dans le nuage ATM. La fonction de transposition de service survient lorsque une réservation de niveau IP (un message RESV) déclanche la traduction par l'appareil de bordure des exigences de service RSVP en sémantique de circuit virtuel ATM (UNI).


Une gamme de politiques de gestion de circuits virtuels est possible, qui détermine si un flux initie un nouveau VC ou se joint à un VC existant. Les VC sont gérés selon une combinaison de normes et de règles de politique locales, qui sont spécifiques de la mise en œuvre (l'équipement) ou de l'opérateur (fournisseur de service réseau). Les connexions en point à multipoint au sein du nuage ATM peuvent être utilisées pour prendre en charge des flux de diffusion groupée IP généraux. Dans ATM, une connexion en point à multipoint peut être contrôlée par le nœud source (ou racine) ou bien on peut utiliser un dispositif de jonction à l'initiative de l'extrémité (LIJ, leaf initiated join) dans ATM. Le sujet de la gestion des circuits virtuels est examiné en détails dans d'autres documents ISSLL [13], [14], [15].


La Figure 2 montre les fonctions d'un appareil de bordure, résumant abstraitement le travail qui ne fait pas partie de IP ou ATM par une fonction d'interfonctionnement (IWF, InterWorking Function) et en traitant à part le contrôle et le plan des données.


IP ATM

____________________

| IWF |

| |

Contrôle <--> |transpos. de service| <--> signalisation et

d'admission et | gestion de VC | contrôle d'admission

de politique |résolution d'adresse| ATM

|....................|

| |

classification, |Couche d'adaptation |

régulation et <--> | ATM : segmentation | <--> programmation/formatage

programmation | mémoire tampon de | de cellule

| réassemblage |

____________________


Figure 2 : Fonctions d'appareil de bordure montrant l'IWF


Dans la vue logique de la Figure 2, certaines fonctions, comme la programmation, sont montrées séparément, car ces fonctions sont présentes sur les deux côtés, IP et ATM. Il est cependant possible de combiner ces fonctions dans une mise en œuvre intégrée.


Les fonctions de transposition de service et de gestion de VC peuvent être très interdépendantes. Par exemple : (i) plusieurs flux à intégration de services peuvent être agrégés pour utiliser un VC en point à multipoint. Dans ce cas, on suppose que les flux IP sont du même type de service et que leurs paramètres ont été fusionnés de façon appropriée. (ii) La fonction de gestion de VC peut choisir d'allouer des ressources supplémentaires en anticipation d'autres réservations ou sur la base d'un changement empirique des TSpec. (iii) Il DOIT exister un chemin pour les flux au mieux et pour envoyer les messages de contrôle rsvp. La façon dont cela interagit avec l'établissement des VC pour le trafic de QS peut altérer les caractéristiques désirées pour ces VC. Voir dans [13], [14], [15] les détails de la gestion des VC.


Donc, en exposant le problème de la transposition de service, on suppose que la fonction de gestion de VC de la IWF peut toujours exprimer ses résultats en termes de service de niveau IP avec de la QS et des TSpec. L'algorithme de transposition de service identifie alors les paramètres de VC appropriés comme si un nouveau VC devait être créé pour ce service. La fonction de gestion de VC peut alors utiliser ces informations en cohérence avec sa propre politique, qui détermine si l'action qui résulte utilise les VC nouveaux ou existants.


1.2 Documents voisins

Les premiers documents de l'ATM Forum combinaient la signalisation, la gestion du trafic et d'autres domaines en un seul document, par exemple, UNI 3.0 [4] et UNI 3.1 [5]. La livraison 3.1 était utilisée pour corriger les erreurs et régler l'alignement avec l'UIT. Alors que UNI 3.0 et 3.1 sont incompatibles en termes de codets réels; la sémantique est généralement la même. Nous nous référons donc souvent à UNI 3.x pour parler de l'une ou l'autre version du protocole ATM.


Après 3.1, le Forum ATM a publié des documents séparés pour chaque groupe de travail technique. Les documents de signalisation UNI 4.0 [6] et de gestion du trafic 4.0 [7] représentent un protocole ATM global cohérent, et on se réfèrera parfois à cette combinaison sous le nom de TM/UNI 4.0.


Au sein de l'IETF, le matériel concerné inclut le travail des groupes de travail RSVP [3], INT-SERV [2], |9], |10], [16], [17] et ION [11], [12]. RSVP définit le protocole de réservation de ressources (qui est analogue à la signalisation dans ATM). INT-SERV définit le comportement et la sémantique de services particuliers (analogues au groupe de travail Gestion de trafic de l'ATM Forum). ION définit l'interfonctionnement de IP et d'ATM pour le service traditionnel au mieux et couvre de façon générale les questions qui se rapportent à l'acheminement et l'adressage IP/ATM.


Un grand nombre de détails de la signalisation ATM sont traités dans la RFC1755 [10] ; par exemple, les différences entre UNI 3.0 et UNI 3.1, l'encapsulation, l'interfonctionnement avec le relais de trame, etc. Ces considérations s'étendent aussi à IP sur ATM avec QS. La description donnée du service IP au mieux (c'est à dire, le comportement par défaut) sur ATM donnée dans le présent document est destinée à être en cohérence avec la RFC1755 et son extension pour UNI 4.0 [11], et ces documents sont à considérer comme définitifs. Pour les services qui ne sont pas au mieux, certaines caractéristiques IP/ATM vont présenter des divergences avec la RFC1755. Nous avons tenté de noter explicitement des différences. (Par exemple, les VC au mieux peuvent être supprimés en fin de temporisation par l'appareil de bordure, alors que les VC à qualité de service ne sont supprimés que par l'appareil bordure amont lorsque la réservation RSVP correspondante est supprimée.)


Un autre document en rapport est la RFC1821 [17], qui représente une ancienne discussion des problèmes découlant de l'inter opération des protocoles IP et ATM pour les services intégrés et la QS.


2. Caractéristiques de protocole majeures pour la gestion du trafic et de la QS


L'établissement d'appel ATM est envoyé par l'appareil bordure d'entrée au réseau ATM pour établir le service ATM de bout en bout. Cet établissement contient les informations suivantes.


Catégorie de service/capacité de support haut débit

Paramètres d'AAL

Informations de couche basse à haut débit

Informations d'adressage de la partie appelante et appelée

Descripteurs de trafic

Classe et/ou paramètres de QS

Paramètres supplémentaires de TM/UNI 4.0


Dans cette section, on expose chacun de ces thèmes dans la mesure où ils se rapportent à la création de VC ATM convenables pour les services GS, CLS et BE. On ne parle pas du tout d'acheminement ni d'adressage, car ils sont (au moins pour l'instant) indépendants de la QS. À la suite de la section sur les catégories de service, on expose les définitions d'étiquetage et de conformité pour IP et ATM. Elles n'apparaissent pas explicitement comme des paramètres d'établissement dans la liste ci-dessus, car elles sont impliquées par la méthode de régulation utilisée.


2.1 Catégorie de service et capacités du support

Le plus haut niveau d'abstraction pour distinguer les caractéristiques des VC ATM est la catégorie de service ou la capacité du support. Les catégories de service ont été introduites dans TM/UNI 4.0 ; précédemment, la capacité du support été utilisée pour discriminer à ce niveau.


Ces éléments indiquent les propriétés générales d'un VC : si il y a une contrainte de délai de temps réel, si le trafic est constant ou à taux variable, le trafic applicable et les paramètres de description de la QS et (implicitement) la complexité de certains mécanismes de commutation en support (par exemple, ABR).


Pour UNI 3.0 et UNI 3.1, il n'y a que deux options distinctes pour les capacités du support (dans notre contexte) :

BCOB-A : taux constant, temporisation requise, envoi individuel/multipoint ;

BCOB-C : taux variable, temporisation non requise, envoi individuel/multipoint.


Une troisième capacité, BCOB-X, peut être utilisée comme substitut des deux capacités ci-dessus, avec ses paramètres dépendants (type de trafic et exigences de temporisation) réglés de façon appropriée. La distinction entre la formulation BCOB-X et la construction "équivalente" (pour notre objet) BCOB-A et BCOB-C est si le réseau ATM doit fournir un pur service de relais de cellules ou interfonctionner avec d'autres technologies (avec une signalisation interopérable) comme un RNIS à bande étroite. Lorsque cette distinction est applicable, le code approprié DEVRAIT être utilisé (voir [5] et les spécifications en rapport de l'UIT, par exemple, I.371).


Dans TM/UNI 4.0 les catégories de service sont :

Débit binaire constant (CBR, Constant Bit Rate)

Débit binaire variable en temps réel (rtVBR, Real-time Variable Bit Rate)

Débit binaire variable en différé (nrtVBR, Non-real-time Variable Bit Rate)

Débit binaire non spécifié (UBR, Unspecified Bit Rate)

Débit binaire disponible (ABR, Available Bit Rate)


Les deux premières sont des services en temps réel, de sorte que rtVBR est nouveau pour TM/UNI 4.0. Le service ABR est aussi nouveau pour TM/UNI 4.0. UBR existe dans toutes les spécifications, bien qu'il soit appelé "au mieux" dans UNI 3.x. Dans l'un et l'autre cas il est indiqué par le fanion d'indication "au mieux" (et la classe de QS est réglée à 0).


La catégorie de service dans TM/UNI 4.0 est codée dans le même élément d'information (IE, Information Element) signalé que la capacité du support dans UNI 3.x, pour les besoins de la rétrocompatibilité. Donc, nous utilisons la convention de se référer à la catégorie de service (CBR, rtVBR, nrtVBR, UBR, ABR) pour TM/UNI 4.0 (où la capacité du support est implicite). Lorsque on se réfère explicitement à la capacité du support (BCOB-A, BCOB-C, BCOB-X) c'est pour décrire un message de signalisation UNI 3.x.


En principe, il est possible de prendre en charge tous les services avec l'utilisation de BCOB-A/CBR. Cela parce que le service CBR est équivalent à avoir un "tuyau" d'une bande passante spécifiée. Cependant, il peut être significativement plus efficace d'utilise les autres services ATM lorsqu'ils sont applicables et disponibles [17].


2.1.1 Catégorie de service pour le service garanti

Il y a deux transpositions possibles pour GS :

CBR (BCOB-A)

rtVBR


La prise en charge du temps réel est EXIGÉE pour GS. Donc dans UNI 3.x, la classe du support BCOB-A (ou une formulation BCOB-X équivalente) DOIT être utilisée. Dans TM/UNI 4.0, CBR ou rtVBR est appropriée. L'utilisation de rtVBR peut encourager la récupération de la bande passante allouée inutilisée par une source. Elle fournit aussi aux sources plus saccadées un plus gros baquet de jetons de paramètre de salve, et permet l'usage de l'étiquetage du trafic en excédent (voir au paragraphe 2.2).


Ni la classe de support BCOB-C, ni nrtVBR, UBR, ABR ne sont de bonnes correspondances pour le service GS. Elles ne fournissent pas d'estimations de délai et ne peuvent pas garantir de façon consistante de faibles délais pour chaque paquet.


Pour BCOB-A ou CBR, la spécification d'un taux de crête de cellule (PCR, Peak Cell Rate) est EXIGÉE par les normes ATM. Dans ces cas, PCR est le taux nominal de libération avec une tolérance de gigue nominale (taille de baquet) CDVT.


Lorsque rtVBR est spécifiée, deux taux, PCR et SCR sont EXIGÉS (par les normes ATM). Cela modèle le trafic saccadé avec des taux de crête et soutenus spécifiés. Les valeurs correspondantes de profondeur de baquet de jetons ATM sont, respectivement, CDVT et CDVT+BT.


2.1.2 Catégorie de service pour la charge contrôlée

Il y a trois bonnes transpositions possibles pour CLS :

CBR (BCOB-A)

nrtVBR (BCOB-C)

ABR


Noter que sous UNI 3.x, il y a des services équivalents à CBR et nrtVBR, mais pas à ABR. Le premier, avec une connexion CBR/BCOB-A, fournit un plus haut niveau de QS qu'il n'est nécessaire, mais cela peut convenir pour allouer simplement un "tuyau" à débit fixé, que nous pensons être partout pris en charge dans les réseaux ATM. Cependant, sauf si c'est le seul choix disponible, ce serait probablement un gaspillage des ressources du réseau.


La catégorie nrtVBR/BCOB-C est peut-être la meilleure correspondance car elle procure une allocation de bande passante et des mémoires tampon avec une indication supplémentaire de taux de crête, similaire à la TSpec CLS. Le trafic excédentaire peut être traité par l'étiquetage du bit CLP avec VBR.


La catégorie ABR avec un débit de cellule minimum (MCR, Minimum Cell Rate) positif est en ligne avec l'idée de CLS de service "au mieux avec un plancher". Le réseau ATM est d'accord pour transmettre des cellules avec un taux d'au moins MCR, qui DOIT être directement converti à partir du taux de baquet de jetons de la TSpec du receveur. Le paramètre taille de baquet mesure approximativement la quantité de mémoire tampon nécessaire à l'IWF. Cette mémoire tampon sert à absorber les salves permises par le baquet de jetons, car elles ne peuvent pas être passées directement à un VC ABR.


La catégorie rtVBR peut être utilisée, bien que l'appareil de bordure DOIVE alors déterminer les valeurs pour CTD et CDV. Comme il n'y a pas de paramètre de niveau IP correspondant, le réglage de leurs valeurs est une affaire de politique locale.


La catégorie UBR ne donne pas assez de capacités pour le service à charge contrôlée. L'idée de CLS est de permettre une allocation de ressources. Cela est facilité par le descripteur de trafic de baquet de jetons, qui est indisponible avec UBR.


2.1.3 Catégorie de service au mieux

Toutes les catégories de service ont la capacité de porter le service au mieux, mais la catégorie de service naturelle est UBR (ou, dans UNI 3.x, BCOB-C ou BCOB-X, avec l'indication de "au mieux" établie). Les classes CBR ou rtVBR pourraient évidemment être utilisées, et comme le service n'est pas en temps réel, une connexion nrtVBR pourrait aussi être utilisée. Dans ces cas, le paramètre de taux utilisé reflète une allocation de bande passante en support de la connexité au mieux de l'appareil bordure d'entrée au routeur bordure de sortie. Il serait normal pour du trafic provenant de nombreuses paires de source/destination d'être agrégées sur cette connexion ; bien sûr, comme au mieux est le comportement IP par défaut, les flux individuels ne sont normalement pas identifiés ou décomptés. CBR peut être la solution préférée dans le cas où le trafic au mieux est suffisamment agrégé pour qu'un simple tuyau à taux fixe soit efficace. CBR et nrt-VBR fournissent tous deux une allocation explicite de bande passante qui peut être utile pour les besoins de la facturation. Dans le cas de UBR, l'opérateur du réseau DEVRAIT allouer la bande passante pour le service global à travers la fonction de contrôle d'admission, bien qu'une telle allocation ne soit pas explicitement faite par VC.


Une connexion ABR pourrait de même être utilisée pour prendre en charge le trafic au mieux. Bien sûr, la prise en charge de protocoles de communications de données tels que TCP/IP est l'objet explicite pour lequel ABR a été conçu. Il est concevable qu'une connexion ABR distincte soit faite pour chaque flux IP, bien que le cas normal serait probablement d'avoir tout le trafic IP au mieux avec un routeur de sortie commun qui partage une seule connexion ABR.


La catégorie de service rt-VBR peut être considérée comme moins convenable, simplement parce que les contraintes de délai de temps réel et l'utilisation de SCR/BT ajoutent une complexité inutile.


Voir les spécifications du groupe de travail ION de l'IETF [10], [11] sur le travail en rapport avec la prise en charge du service au mieux sur ATM.


2.2 Bit de priorité de perte de cellule, étiquetage et définitions de conformité

Chaque en-tête de cellule ATM porte un bit Priorité de perte de cellule (CLP, Cell Loss Priority). Les cellules avec CLP=1 sont dites "étiquetées" ou "marquées" et ont une priorité inférieure. Cet étiquetage peut être fait par la source, pour indiquer une priorité relative au sein du VC, ou par un commutateur, pour indiquer du trafic en violation des paramètres de régulation. Les options qui impliquent l'utilisation de l'étiquetage sont décidées au moment de l'établissement de l'appel.

Une définition de conformité est une règle qui détermine si une cellule est conforme au descripteur de trafic du VC. La définition de conformité est donnée en termes d'algorithme générique de débit de cellules (GCRA, Generic Cell Rate Algorithm) aussi appelé un algorithme de "baquet à fuite", pour les services CBR et VBR. La définition de conformité spécifie aussi les règles pour l'étiquetage du trafic en excès par rapport au descripteur de trafic du GCRA {SCR, MBS}. (Noter que le terme "conformité" est utilisé dans ATM pour décrire le comportement d'une connexion, à la différence de la "conformité" qui s'applique à une seule cellule.)

Le réseau peut étiqueter des cellules qui sont non conformes, plutôt que de les abandonner si l'établissement du VC exige l'étiquetage et si le réseau prend en charge l'option d'étiquetage. Lorsque l'étiquetage est utilisé et que survient de l'encombrement, un commutateur DOIT tenter d'éliminer de préférence des cellules étiquetées plutôt que d'éliminer des cellules de CLP=0. Cependant, le mécanisme pour faire cela est complètement spécifique de la mise en œuvre. Le comportement qui satisfait le mieux aux exigences des services intégrés IP est lorsque les cellules étiquetées sont traitées comme "au mieux" dans le sens où elles sont transportées lorsque de la bande passante est disponible, mises en file d'attente lorsque des mémoires tampon sont disponibles, et abandonnées lorsque les ressources sont totalement engagées. Les normes ATM ne spécifient cependant pas explicitement le traitement du trafic étiqueté. Les fournisseurs de service GS et CLS avec des sous-réseaux ATM DEVRAIENT s'assurer du comportement réel des mises en œuvre ATM à l'égard des cellules étiquetées.

Comme les services GS et CLS EXIGENT que le trafic en excès soit traité comme au mieux, l'option d'étiquetage DEVRAIT toujours être choisie (si elle est prise en charge) dans l'établissement de VC comme moyen de "dégrader" les cellules comportant des paquets non conformes. Le terme "au mieux" peut être interprété de deux façons. La première est une classe de service qui, par exemple, peut être mise en œuvre comme une file d'attente séparée. L'autre sens est plus générique, signifiant que le réseau fait de son mieux pour transporter le trafic. Une interprétation raisonnable est qu'un réseau sans compétition entre les trafics pourrait transporter le paquet, alors qu'un réseau très encombré va abandonner le paquet. Un mécanisme qui étiquette les paquets au mieux avec la plus basse classe de priorité de perte (comme avec le bit CLP d'ATM) va abandonner certains de ces paquets, mais ne va pas réarranger ceux qui restent par rapport à la portion conforme du flux. Le mécanisme "au mieux" pour le trafic en excès n'a pas nécessairement à être le même que le "service" au mieux, tant qu'il rentre dans ce sens générique de "au mieux".


Il y a à considérer trois définitions de conformité du service VBR (aussi bien rtVBR que nrtVBR). Dans VBR, seule la définition de conformité VBR.3 accepte l'étiquetage et s'applique au GCRA avec le PCR aux cellules CLP=0+1 agrégées, et un autre GCRA avec le SCR aux cellules CLP=0. Cette définition de conformité DEVRAIT toujours être utilisée avec un service VBR prenant en charge les service intégrés IP. Pour le service UBR, la définition de conformité UBR.2 accepte l'usage de l'étiquetage, mais une cellule CLP=1 n'implique pas la non conformité ; elle peut plutôt être utilisée par le réseau pour indiquer l'encombrement.


Dans TM/UNI 4.0, l'étiquetage n'est pas une caractéristique des définitions de conformité pour les catégories de service CBR ou ABR. (Comme les définitions de conformité sont généralement spécifiques du réseau, certaines mises en œuvre de CBR ou ABR peuvent, en fait, utiliser l'étiquetage d'une certaine façon.) Chaque fois qu'un réseau ATM accepte bien l'étiquetage, dans le sens de transporter les cellules CLP=1 sur la base "au mieux", il est un mécanisme utile et préférable pour le traitement du trafic en excédent.


Il est toujours meilleur pour la IWF d'étiqueter les cellules lorsque elle peut prévoir que le réseau ATM le ferait. Cela parce que la IWF connaît les limites du paquet IP et peut étiqueter toutes les cellules qui correspondent à un paquet. Si cette tâche est laissé à l'UPC de couche ATM, le réseau va inévitablement abandonner certaines des cellules d'un paquet et en transporter d'autres, qui seront alors abandonnées par le receveur. Donc, la IWF, connaissant les paramètres GCRA du VC, DEVRAIT toujours anticiper les cellules qui seront étiquetées par l'UPC ATM, et étiqueter toutes les cellules de façon uniforme à travers chaque paquet affecté. Voir au paragraphe 3.2 un exposé plus complet sur le trafic en excédent.


2.3 Couche d'adaptation ATM

Le codage AAL de type 5 DEVRAIT être utilisé, comme spécifié dans la RFC1483 et la RFC1755. Pour AAL-5, la spécification de la taille maximum de SDU dans les deux directions de transmission et de sens inverse est EXIGÉE. GS et CLS spécifient tous deux une taille maximum de paquet, M, au titre de la TSpec et cette valeur DEVRAIT être utilisée (corrigée pour les en-têtes AAL) comme SDU maximum dans chaque direction pour les connexions en envoi individuel, et pour les connexions unidirectionnelles en point à multipoint. Lorsque plusieurs flux sont agrégés en un seul VC, les paramètres M des TSpec du receveur sont fusionnées conformément aux règles données dans les spécifications de GS et CLS.


2.4 Informations de couche basse haut débit

L'élément d'information B-LLI (Informations de couche inférieure haut débit) est transféré de façon transparente par le réseau ATM entre les appareils de bordure et est utilisé pour spécifier la méthode d'encapsulation. Plusieurs éléments d'information B-LLI peuvent être envoyés au titre de la négociation. L'encapsulation LLC/SNAP [18] DEVRAIT être prise en charge par défaut, mais "nul" ou "encapsulation de VC" PEUT aussi être admis. Les mises en œuvre DEVRAIENT suivre la RFC1577 [19] et la RFC1755 [10] pour l'utilisation de B-LLI.


2.5 Descripteurs de trafic

Le descripteur de trafic ATM contient toujours un débit cellulaire de crête (PCR, peak cell rate) (pour chaque direction). Pour les services VBR, il contient aussi un débit cellulaire soutenable (SCR, sustainable cell rate) et une taille de salve maximum (MBS, maximum burst size). Le SCR et la MBS forment une paire de baquet à fuite (débit, profondeur) alors que le paramètre de profondeur de baquet pour PCR est CDVT. Noter que CDVT n'est pas signalé explicitement, mais est déterminé par l'opérateur du réseau, et peut être vu comme une mesure de la gigue imposée par le réseau.

Comme CDVT est généralement supposé petit (équivalent à une profondeur de baquet de jetons de quelques cellules) et ne peut pas être réglé indépendamment pour chaque connexion, il ne peut pas être utilisé pour mesurer la sporadicité permise par le b de la TSpec de couche IP. Une mise en mémoire tampon supplémentaire peut être nécessaire à la IWF pour tenir compte de la profondeur du baquet de jetons.

La tolérance de salve (BT, Burst Tolerance) ATM est équivalente au MBS (voir dans TM 4.0 [6] l'équation exacte). Toutes deux sont l'expression du paramètre de profondeur de baquet associé au SCR. L'unité de la BT est le temps alors que l'unité du MBS est la cellule. Comme SCR et MBS sont tous deux signalés, ils peuvent être calculés directement à partir de la description de trafic de couche IP. La manière spécifique dont les ressources sont allouées à partir de la description de trafic est spécifique de la mise en œuvre. Noter que lors de la traduction des paramètres de trafic, la redondance de segmentation et l'unité de régulation minimum doivent être prises en compte (voir le paragraphe 4.1 ci-dessous).

Dans la signalisation 4.0 UNI d'ATM, il y a les notions de descripteurs de trafic de remplacement et de descripteurs de trafic minimal. Les descripteurs de trafic de remplacement énumèrent les autres choix acceptables pour les descripteurs de trafic et ne sont pas pris en compte ici. Les descripteurs de trafic minimal sont utilisés dans la "négociation", qui se réfère à la façon spécifique dont une connexion ATM est établie. Pour illustrer cela, en gros, en prenant PCR comme exemple, un PCR minimal et un PCR demandé sont signalés, le PCR demandé étant l'élément usuel signalé, et le PCR minimal étant le minimum absolu que l'appareil bordure de source va accepter. Lorsque les paramètres minimal et demandé sont tous deux présents, les commutateurs intermédiaires le long du chemin peuvent réduire le PCR demandé jusqu'à un niveau "confortable". Ce choix fait partie du contrôle d'admission et est donc spécifique de la mise en œuvre. Si à un point quelconque, le PCR demandé tombe en dessous du PCR minimal, l'appel est alors libéré. Les descripteurs de trafic minimal peuvent être utilisés pour présenter une gamme acceptable pour les paramètres et assurer une plus forte probabilité d'admission de l'appel. En général, notre discussion des paramètres de connexion suppose que les valeurs résultent d'un établissement de connexion réussi.

L'indicateur au mieux (utilisé seulement avec UBR) et les indicateurs d'étiquetage (voir au paragraphe 2.2) font aussi partie de l'élément d'information (IE, information element) signalé qui contient le descripteur de trafic. Dans l'IE de descripteur de trafic de UNI 4.0 il y a un paramètre supplémentaire, l'indicateur d'élimination de trame, qui est décrit ci-dessous au paragraphe 2.7.


2.5.1 Traduction de descripteurs de trafic pour le service garanti

Pour le service garanti, la TSpec de source contient les paramètres de débit de crête, de taux et de profondeur de baquet , p_s, r_s, b_s. La TSpec du receveur contient les paramètres correspondants p_r, r_r, b_r. La RSpec (du receveur) a aussi un taux, R. Les deux taux différents des TSpec sont destinés à prendre en charge l'hétérogénéité des receveurs, au sens où les receveurs peuvent accepter différents taux représentant différents sous-ensembles du trafic de l'envoyeur. Chaque fois que les taux provenant des différents receveurs diffèrent, les valeurs DOIVENT toujours être fusionnées de façon appropriée avant d'être transposées en paramètres ATM.


Noter que lorsque les taux des TSpec d'envoyeur et de receveur r_s, r_r diffèrent, il n'y a pas de mécanisme spécifié (ni dans les spécifications RSVP ni dans celles de Int-Serv) pour indiquer quel sous-ensemble du trafic est à transporter. La mise en œuvre de cette caractéristique est donc complètement spécifique du réseau. Les mécanismes de régulation et de programmation peuvent simplement être paramétrés avec le taux du receveur (plus faible) d'où résulte une perte aléatoire de trafic suffisante pour combler la différence des taux.


Le taux de la TSpec du receveur décrit le trafic pour lequel des ressources sont à réserver, et peut être utilisé pour réguler, alors que le taux de la RSpec (qui ne peut pas être inférieur) est utilisé (peut-être de façon spécifique de la mise en œuvre) pour modifier la bande passante allouée au service afin de réduire le délai.


Lors de la transposition du service garanti sur un VC rtVBR, les paramètres de descripteur de trafic ATM (PCR, SCR, MBS) peuvent être réglés canoniquement comme :

PCR = p_r

SCR = R

MBS = b_r.


Il y a un certain nombre de conditions qui peuvent conduire à des choix différents. L’exposé qui suit n’est pas destiné à fixer des exigences fermes, mais à fournir une interprétation et des lignes directrices sur les limites des transpositions possibles de paramètres. L’appareil bordure d’entrée comporte généralement une mémoire tampon qui précède l’interface réseau ATM. Cette mémoire tampon peut être utilisée pour absorber les salves qui tombent dans la TSpec de niveau IP, mais pas dans le descripteur de trafic ATM. L’exigence minimale pour le service garanti est que le délai dans cette mémoire tampon NE DOIT PAS excéder b/R, et le délai au sein du réseau ATM DOIT être précisément pris en compte pour les valeurs des paramètres Adspec C et D annoncés par le routeur d’entrée (voir au paragraphe 3.3 ci-dessous).


Si il existe une mémoire tampon d’appareil bordure de taille b_r ou si le paramètre de taille maximale de salve (MBS, maximum burst size) ATM est d’au moins b_r, les divers paramètres de taux vont alors généralement afficher les relations suivantes :


r_r ≤ SCR ≤ R ≤ PCR ≤ APB ≤ taux de ligne

r_r ≤ p_r ≤ APB


APB se réfère au paramètre de caractérisation générale, AVAILABLE_PATH_BANDWIDTH (bande passante de chemin disponible) qui est négocié dans la portion Adspec du message PATH. APB reflète le plus étroit goulet d’étranglement du taux le long du chemin, et est donc toujours pas plus grand que le taux de la ligne locale. Le receveur DEVRAIT choisir un taux de crête qui ne soit pas supérieur à l’APB pour que la réservation soit acceptée, bien que le taux de crête de source, p_s, puisse être supérieur, car la source ne connaît pas la valeur de l’APB. Il n’y a bien sûr pas d’avantage à allouer un taux supérieur à l’APB, de sorte que c’est une limite supérieure pour tous les autres paramètres.


On peut normalement s’attendre à trouver R ≤ p_r, comme il serait nécessaire pour la simple transposition de PCR = p_r, SCR = R donnée ci-dessus. Cependant, un receveur est libre de choisir R > p_r pour diminuer le délai de GS [8]. Dans ce cas, PCR ne peut pas être réglé en dessous de R, parce qu’une salve de taille b qui arrive dans la mémoire tampon DOIT être libérée au taux R pour garder le délai du premier composant de GS au niveau de b/R. Donc ici nous allons avoir PCR = R. Il peut sembler que PCR = p_r serait suffisant pour éviter un débordement de la mémoire tampon, car les données sont générées à la source à un taux bordé par p_r. Cependant, régler PCR < R, peut résulter en ce que la limite de délai annoncée par C et D ne soit pas tenue. Aussi, le trafic est toujours soumis à la gigue du réseau, et le taux d’arrivée à un élément de réseau peut excéder p_r pour de courtes périodes.


Dans le cas où R ≤ p_r, on peut toujours choisir PCR de telle sorte que R ≤ PCR < p_r. La mémoire tampon de l’appareil bordure est alors nécessaire (et suffisante) pour absorber les salves (limitées à la taille b_r + ∑C + R ∑D) qui arrivent plus vite qu’elles ne partent. Par exemple, il peut arriver que le coût du VC ATM dépende du PCR, alors que le coût de la réservation de service Internet ne dépend pas fortement du taux de crête de niveau IP. L’usager peut alors avoir une incitation à régler p_r à APB, alors que l’opérateur du routeur bordure IP/ATM est incité à réduire PCR autant que possible. Cela peut être un souci réaliste, car les modèles de tarification de IP et d’ATM sont historiquement aussi différents que la sensibilité à l’utilisation, et la valeur de p_r, si elle est fixée proche de APB, pourrait être un multiple élevé du taux nominal de GS alloué de R. Donc, on peut régler PCR à R, avec une mémoire tampon de taille b_r + ∑C + R ∑D, sans perte de trafic, et sans violation de la limite de délai de GS.


Un cas plus subtil, et peut-être plus controversé est celui où on règle SCR à une valeur en-dessous de R. La caractéristique majeure du service GS est de permettre à un receveur de spécifier le taux alloué R comme supérieur au taux r_r suffisant pour transporter le trafic, afin de diminuer le délai de mise en file d’attente (en gros) de b/r + C_TOT/r + D_TOT à b/R + C_TOT/R + D_TOT. Pour allouer effectivement la bande passante R au flux, on règle SCR de façon à correspondre à R. (Noter qu’il est inutile dans tous les cas de régler SCR au dessus de R, de sorte que la relation, SCR ≤ R, est encore vraie.) Il est possible de régler SCR à une valeur aussi faible que r_r, sans violer les limites de délai ou sans débordement de la mémoire tampon de l’appareil de bordure. Avec PCR = R, une salve de taille b sera mise en mémoire tampon et envoyée au réseau ATM au taux R, de sorte que le dernier octet subira seulement un délai de b/R. Tout trafic supplémentaire sera limité au taux r_r, qui est le SCR, et donc avec les taux d’arrivée et de départ qui correspondent, son délai ne sera pas non plus supérieur à b/R.


Bien que ce scénario satisfasse aux exigences du service GS, la pénalité pour l'allocation de SCR = r_r plutôt que R est que le délai dans le réseau ATM aura une composante de MBS/SCR, qui sera b/r plutôt que b/R, contenue dans le terme D annoncé pour le sous-réseau ATM (voir des explications complémentaires au paragraphe 3.3 ci-dessous). Il est vrai aussi que l'allocation de r au lieu de R dans une portion du chemin va plutôt à l'encontre de l'esprit de GS. Comme mentionné ci-dessus, cette transposition peut cependant être utile en pratique dans le cas où la tarification dans le réseau ATM conduit à des incitations différentes dans le compromis entre délai et bande passante que celles de l'utilisateur qui achète des services IP intégrés.


Un autre point de vue sur la transposition de paramètre suggère que SCR peut simplement refléter la description du trafic, donc SCR = r_r, alors que l'exigence de service est exprimée dans le paramètre de QS par CDV = b/R. Donc, le réseau ATM peut allouer en interne la bande passante R, mais il est libre d'utiliser aussi d'autres méthodes pour atteindre la contrainte de délai. Des mécanismes tels que l'agrégation statistique de flux/connexion peuvent être mis en œuvre dans le réseau ATM et cachés à l'usager (ou dans le module de transposition de paramètre dans le routeur de bordure) qui ne voit que l'interface mise en œuvre dans les paramètres signalés.


Noter que cet exposé considère une taille de mémoire tampon d'appareil de bordure de b_r. En pratique, il peut être nécessaire que le module AAL/segmentation mette en mémoire tampon M octets pour la conversion de paquets en cellules. Une quantité supplémentaire de mémoire tampon égale à ∑C + R ∑D est aussi généralement nécessaire pour absorber la gigue imposée par le réseau amont [8].


Avec ATM, il est possible de n'avoir que peu ou pas du tout de mémoire tampon dans le routeur de bordure, parce que le VC ATM peut être réglé de façon à accepter des salves au taux de crête. Cela peut être inhabituel, car le routeur bordure a normalement assez de mémoire tampon pour absorber les salves conformément aux paramètres du baquet de jetons de la TSpec. On considère deux cas. D'abord, si PCR ≥ p_r, alors la MBS peut être réglée à b_r et aucune mise en mémoire tampon n'est nécessaire pour absorber les salves non excessives. La mise en mémoire tampon supplémentaire nécessaire pour absorber la gigue peut aussi être transférée à la MBS. Cela déplace effectivement la mise en mémoire tampon à travers l'UNI dans le réseau ATM.


Pour être complet, on considère un routeur bordure sans mémoire tampon d'absorption de salves et d'un paramètre de MBS d'approximativement zéro. Dans ce cas, il est suffisant de régler les paramètres de taux à PCR = SCR = max (R, p_r). Cela revient à allouer la bande passante au niveau du taux de crête, ce qui n'est pas habituellement très économique. Ce cas peut être pertinent lorsque les routeurs IP et les commutateurs ATM diffèrent de façon substantielle dans l'économie de leurs mémoires tampons. Les usagers de niveau IP peuvent normalement spécifier des paramètres de salve beaucoup plus grands que ce qui peut être traité dans le sous-réseau ATM. L'allocation de bande passante au taux de crête donne un moyen pour contourner ce problème. Il est aussi vrai que des compromis intermédiaires peuvent être formulés, dans lesquels la mémoire tampon d'absorption des salves est de moins de b octets, et où SCR est réglé au dessus de R et en dessous de p_r. Noter que les mémoires tampon d'absorption de gigue (∑C + R ∑D) ne peuvent pas être évitées, généralement, en augmentant les taux ATM, sauf si SCR est réglé de façon à dépasser le taux de ligne physique dans l'appareil bordure pour le flux.


Pour GS sur CBR, la valeur de PCR peut être transposée en taux R de la RSpec, si l'appareil bordure a une mémoire tampon de taille b_r + ∑C + R ∑D. Avec peu ou pas du tout de mémoire tampon de salve, les exigences ressemblent à celles du cas de mémoire tampon de zéro ci-dessus, et nous avons PCR = max (R, p_r). Des mémoires tampons supplémentaires suffisantes pour absorber la gigue du réseau, données par ∑C, ∑D, DOIVENT toujours être fournies dans le routeur bordure, ou dans le réseau ATM via la MBS.


2.5.2 Traduction de descripteurs de trafic pour le service à charge contrôlée

La TSpec du service à charge contrôlée a un taux de crête, p, un taux de "baquet de jetons", r, et un paramètre correspondant de profondeur de baquet de jetons, b. Les valeurs de Spec du receveur sont utilisées pour déterminer l'allocation des ressources et une transposition simple pour la catégorie de service nrtVBR est donnée par :


PCR = p_r

SCR = r_r

MBS = b_r.


L'exposé du paragraphe précédant sur l'utilisation des mémoires tampons des appareils bordure pour réduire le PCR et/ou la MBS s'appliquent généralement aussi au cas de CLS sur nrtVBR. De la mémoire tampon supplémentaire pour s'accommoder de la gigue accumulée (au delà de la taille de salve b_r allouée à la source) DOIT être fournie. Pour CLS, il n'y a pas de paramètres C et D d'Adspec, de sorte que le dimensionnement de telles mémoires tampons est un problème qui relève de la conception des mises en œuvre.


Pour les VC ABR, le taux de la TSpec r_r est utilisé pour régler le paramètre taux de cellule minimum (MCR, minimum cell rate). Comme il n'y a pas de paramètre de profondeur de baquet signalé correspondant, l'appareil de bordure DEVRAIT avoir une mémoire tampon d'au moins b_r octets, plus la mémoire tampon supplémentaire pour absorber la gigue. Avec ABR, le réseau ATM peut rapidement réduire le taux de transfert réel jusqu'au MCR, de sorte qu'une source qui transmettrait au dessus de ce taux pourrait subir des pertes élevées à l'appareil bordure d'entrée lorsque le réseau ATM devient encombré.


Pour CBR, le taux de la TSpec r_r établit une limite inférieure au PCR, et là encore, la mémoire tampon disponible dans l'appareil bordure DEVRAIT être adéquate pour s'accommoder de possibles salves de b_r.


L'EXIGENCE pour CLS que les délais du réseau approximent le service "au mieux dans des conditions sans encombrement" est interprétée ici comme signifiant qu'il serait suffisant d'allouer les ressources de bande passante de telle sorte que le dernier octet d'une salve de taille b_r subisse un délai d'approximativement b_r/r_r. Par exemple, un élément de réseau sans traversée de trafic, un programmeur à conservation du travail, et un taux de liaison de sortie de r_L, peuvent donner des délais dans la gamme de M/r_L à b_r/r_L, qui sont bien inférieurs à b_r/r_r. Alors que l'accès à la pleine bande passante de la liaison (r_L), comme le reflète cet exemple, est une interprétation plus littérale du délai "dans des conditions non chargées" pour une liaison partagée, un VC ATM peut n'avoir seulement accès qu'à la bande passante égale à son allocation nominale (une fonction spécifique de la mise en œuvre du SCR et du PCR).


2.5.3 Traduction de descripteurs de trafic pour le service au mieux

Pour le service au mieux, il n'y a pas de description de trafic. La catégorie de service UBR permet la négociation du PCR simplement pour permettre à la source de découvrir le plus petit goulet d'étranglement physique sur le chemin. Le routeur bordure d'entrée peut régler le PCR au taux de ligne ATM, puis, lorsque l'établissement du VC est terminé, la valeur retournée indique une limite supérieure pour le débit. Pour le service UBR, les ressources peuvent être allouées pour le service global (c'est-à-dire, pas par VC) en utilisant les caractéristiques de contrôle d'admission (spécifiques de la mise en œuvre) des commutateurs ATM.


Un fournisseur de service va souvent donner une configuration statique aux grands circuits virtuels avec une certaine allocation de bande passante pour traiter tout le trafic au mieux entre deux routeurs bordures. Les VC ABR, CBR ou nrtVBR sont appropriés pour ce concept, avec des paramètres de trafic réglés de façon à accommoder de façon confortable la charge de trafic attendue. Voir les spécifications ION de l'IETF pour la signalisation IP sur ATM [10], [11].


2.6 Classes et paramètres de QS

Dans UNI 3.x la qualité de service est indiquée par un seul paramètre appelé "Classe de QS" qui est essentiellement un indice dans un tableau de valeurs spécifiques d'un réseau pour les paramètres de QS réels. Dans TM/UNI 4.0 trois paramètres de QS peuvent être signalés individuellement, et les valeurs signalées outrepassent celles impliquées par la classe de QS, qui sont encore présentes. Ces paramètres sont le taux de perte de cellules (CLR, Cell Loss Ratio), le délai de transfert de cellules (CTD, Cell Transfer Delay), et la variation du temps de propagation de cellule (CDV, Cell Delay Variation) [6].


Un fournisseur de réseau peut choisir d'associer d'autres paramètres, tels qu'un taux de bloc de cellules sévèrement erronées, à une définition de classe de QS, mais ceux-ci ne peuvent pas être signalés individuellement. Les spécifications UNI 3.0, 3.1 et TM 4.0 de l'ATM Forum, à la suite de spécifications antérieures de l'UIT, donnent de vagues définitions qualitatives pour les classes de QS de 1 à 4. (La classe de QS 0 est bien définie comme "pas de paramètre de QS défini".) Comme notre transposition se fonde sur ces spécifications, on suit généralement ces lignes directrices en réglant la valeur de la classe de QS à 0 pour UBR et ABR (comme EXIGÉ), à 1 pour CBR et rtVBR, et à 3 pour nrtVBR. Noter que la classe de QS suit la catégorie de service ATM, et non le service IP, pour éviter des combinaisons qui ne seraient vraisemblablement pas prises en charge. Par exemple, si seul nrtVBR est disponible pour GS, le choix de la classe 1 de QS résulterait probablement en un échec de la connexion. La classe de QS NE DOIT PAS être interprétée comme un moyen d'ajouter un comportement de temps réel à un service par nature en différé.


L'UIT a inclus un ensemble standard de valeurs de paramètres pour un (petit) nombre de classes de QS dans la dernière version de la Recommandation I.356 [21]. Les opérateurs peuvent choisir de définir d'autres classes de QS spécifiques de leur réseau en plus de celles-là. Noter que les définitions de classes de QS dans la nouvelle version de I.356 pourraient n'être pas en ligne avec le modèle que nous suivons à partir des spécifications UNI de l'ATM Forum. À part ces définitions, il n'y a en pratique pas d'accord ferme des opérateurs sur les définitions de classe de service.


Les paramètres de QS ATM n'ont pas de contrepartie explicite de couche IP signalée. Les valeurs qui sont signalées dans le réseau ATM sont déterminées par les définitions de service IP et la connaissance des caractéristiques du réseau ATM sous-jacent, comme expliqué ci-dessous.


Le routeur bordure d'entrée DEVRAIT tenir un tableau des informations de QS pour l'ensemble des routeurs d'entrée avec lesquels il peut établir des circuits virtuels. Ce tableau peut être simplifié en utilisant des valeurs par défaut, mais il serait probablement de bonne pratique de conserver un tableau des données en cours pour les points d'entrée les plus utilisés. Un appareil bordure qui initie un établissement de VC a généralement besoin d'avoir un moyen de proposer les valeurs initiales pour CDV et CTD, même si elles sont changées par négociation ; en proposant un tel tableau, on ne crée pas une nouvelle charge conceptuelle. Les informations en antémémoire peuvent être mises à jour lorsque les VC sont bien établis, et dans la mesure où les réservations de couche IP peuvent attendre que les circuits virtuels soient achevés, les valeurs peuvent être précisées par une négociation itérative.


GS et CLS EXIGENT tous deux que les pertes de paquets dues à l'encombrement soient minimisées, de sorte que le taux de perte soit approximativement le même que pour un réseau sans encombrement. Le comportement de perte caractéristique du support physique non dû à l'encombrement (par exemple, les erreurs binaires ou l'affaiblissement sur les canaux sans fil) déterminent l'ordre du taux de perte de paquets permis. L'appareil bordure d'entrée DOIT choisir une valeur de CLR qui fournisse le taux de perte de paquet de niveau IP approprié. La valeur de CLR peut être uniforme sur tous les points d'entrée dans le réseau ATM, ou peut être différente, par exemple, lorsque des liaisons ATM sans fil ou par satellite se trouvent sur certains chemins. La détermination du CLR DOIT tenir compte des effets de la distribution des tailles de paquets et du mode d'élimination de trame ATM (qui peut changer le taux effectif de perte de paquet de plusieurs ordres de grandeur [22]).


Le routeur d'entrée va aussi faire un tableau des valeurs de la latence minimum de chemin (MPL, Minimum Path Latency) et des délais estimés de mise en file d'attente (D_ATM) pour chaque point d'entrée. Ces derniers seront utilisés au titre du paramètre "D" de l'Adspec pour GS, mais leur utilisation s'applique ici aussi bien à CLS (lorsque l'établissement du VC comporte des paramètres de délai). La MPL représente tous les délais constants (sans rapport avec l'encombrement) y compris le délai de propagation. D_ATM tient compte du composant variable des délais dans le réseau ATM. (Il peut dépendre de paramètres non signalés tels que le CDVT.) Étant données ces quantités, un nouveau VC peut être établi avec des paramètres de QS en rapport avec le délai donnés par :


CDV = D_ATM

CTD = D_ATM + MPL.


(CDV et CTD peuvent être ajustés (augmentés) par le terme de surlongueur (slack term) dans GS, voir le paragraphe 3.3 ci-dessous.)


Il est intéressant (et peut-être regrettable) de noter que dans un service GS/rtVBR normal, la limite de délai annoncée peut contenir deux composants de b/R au lieu d'un. Considérons le cas simple où SCR = R est le taux alloué au flux aux routeurs IP et aux commutateurs ATM le long du chemin, et où l'allocation de mémoire tampon est MBS = b. La théorie de Parekh [23], qui est la base de la formule du délai de GS [8] déclare que le terme de délai b/R ne survient qu'une seule fois, parce qu'une fois qu'une salve de taille b a été servie par un nœud encombré au taux R, les paquets ne vont pas arriver au nœud suivant comme une seule salve. Cependant, on ne peut pas dire à priori si cet étranglement va survenir dans le réseau ATM ou ailleurs dans le réseau IP, de sorte que la déclaration du CDV DEVRAIT en tenir compte (c'est-à-dire, CDV ≥ b/R). Une fois que le CDV est établi, le réseau ATM peut imposer ce délai, que le trafic arrive ou non en salve. Comme le délai b/R peut aussi arriver ailleurs, il ne peut pas être retiré du premier terme de la formule de délai de GS. Le composant b/R de délai ATM apparaît dans le troisième terme de la formule du délai de GS, D_tot. Voir au paragraphe 3.3 ci-dessous des précisions sur les paramètres d'Adspec dans GS. Cet effet peut être atténué lorsque le réseau ATM emploie des schémas d'allocation de ressource statistique plus efficaces.


2.7 Paramètres supplémentaires – Mode d'abandon de trame

TM/UNI 4.0 permet à l'usager de choisir un mode dans lequel le réseau ATM est capable, pour les besoins de la gestion d'encombrement, de PDU plus grandes que la cellule ATM (c'est-à-dire que les PDU d'AAL correspondent dans notre contexte aux paquets IP). Cela facilite la mise en œuvre d'algorithmes comme l'élimination partielle de paquet, où une cellule abandonnée cause aussi l'abandon des cellules suivantes dans la même PDU AAL-5. Plusieurs autres schémas applicables de gestion de mémoire tampon ont été proposés [22], [24].


L'élimination de trame peut améliorer l'efficacité et les performances de protocoles de bout en bout tels que TCP, car les cellules restantes d'une PDU endommagée sont généralement inutilisables par le receveur. Pour IP sur ATM, l'élimination de trame DOIT toujours être indiquée, si elle est disponible.


3. Caractéristiques supplémentaires du protocole d'intégration de services IP

3.1 Paramètres de caractérisation de chemin pour services intégrés IP avec ATM

La présente section expose l'établissement des paramètres de caractérisation générale (GCP, General Characterization Parameter) dans un routeur bordure de sortie ATM. Les GCP sont signalés des source IP aux destinations IP, et modifiés par les nœuds intermédiaires en utilisant la portion Adspec des messages PATH dans RSVP. Les paramètres d'Adspec spécifiques de GS sont exposés ci-dessous au paragraphe 3.3. Ces paramètres sont notés par <x,y> où x est le service et y est le numéro de paramètre. Le service numéro 1 indique les valeurs de paramètre par défaut ou générales. Prière de se référer à [25] pour les définitions et les détails.


Les mises en œuvre qui suivent les présentes lignes directrices NE DOIVENT, bien sûr, PAS toucher au bit IS <1,2> (car elle sont supposées avoir la capacité IS). De même, le routeur DOIT toujours incrémenter IS_HOPS <1,4>. Les bits de coupure spécifiques des services respectivement GS et CLS, <2,2> et <5,2>, DOIVENT être établis si la prise en charge du service est inadéquate. En général GS est pris en charge de façon adéquate par les catégories de service CBR (BCOB-A) et rtVBR, et non pris en charge de façon adéquate par UBR, ABR et nrtVBR parce que les délais ne sont pas contrôlés. CLS peut être pris en charge de façon adéquate par toutes les catégories de service sauf UBR (ou au mieux dans UNI 3.x). Voir un exposé plus détaillé aux sections 5 et 6.


Pour GS, le réseau ATM DOIT satisfaire aux performances de délai annoncées par les paramètres de l'Adspec, MPL, C, et D. Si il ne peut pas de façon prévisible satisfaire à ces exigences, le bit de coupure GS DOIT être établi. De même, les deux bits de coupure DOIVENT être établis si les réservations sont honorées, mais qu'en pratique des ressources suffisantes pour éviter des pertes dues à l'encombrement ne sont pas allouées. Si les bits de coupure de service ne sont pas établis, les compteurs de bonds du service correspondant, <2,4>, <5,4>, DOIVENT être incrémentés.


Les paramètres de bande passante de chemin disponible (APB, Available Path Bandwidth) <x,6> indiquent le taux minimum du goulot d'étranglement physique le long du chemin. Cela peut être découvert dans un réseau ATM par la valeur du PCR négocié pour chaque VC UBR le long de ce même chemin. Cette valeur DOIT être corrigée pour les en-têtes AAL, ATM et de couche physique, en tant que nécessaire, pour refléter la bande passante effective des datagrammes IP. Avec ATM, il est possible qu'il y ait des limitations de politique à la valeur du PCR, en plus du goulot d'étranglement physique de la liaison. Dans ce cas, la valeur d'APB annoncée (en général, et pour chaque service si les valeurs d'APB signalées sont spécifiques du service) DOIT refléter cette limite, car le trafic qui excède ce taux sera abandonné. (Noter qu'il n'y a pas d'étiquetage du trafic excédentaire de PCR pour TM/UNI 4.0.) Ces valeurs DEVRAIENT généralement être mises en antémémoire par le routeur d'entrée pour l'ensemble des routeurs de sortie avec lesquels il est normalement nécessaire d'établir des circuits virtuels. Les paramètres d'APB sont seulement ajustés à la baisse, pour refléter le minimum qui est la valeur composée.


Dans le cas d'un circuit virtuel multipoint, plusieurs paramètres peuvent être différents pour chaque point de sortie, par exemple, parce que les caractéristiques des liaisons physiques des branches de circuit virtuel diffèrent. Lorsque cela survient, la IWF des routeurs de sortie DOIT corriger ces valeurs dans les messages PATH lors de leur sortie du réseau ATM. (On utilise le mot "corriger" parce que le routeur d'entrée DEVRAIT établir les paramètres à une valeur appropriée pour le plus grand nombre de branches, ou une valeur qui serait la moins dommageable si les routeurs de sortie échouaient à corriger de tels paramètres pour chaque branche.) C'est le seul cas où le routeur de sortie a besoin de travailler sur les messages de contrôle RSVP. (Une correction similaire DOIT être mise en œuvre pour tout mécanisme d'établissement non RSVP). Les paramètres pour lesquels de telles corrections sont EXIGÉES sont la bande passante de chemin disponible (APB), la latence minimum de chemin (MPL), la MTU de chemin (bien que pour ATM/AAL-5 elle puisse normalement être constante) et les composants spécifiques d'ATM des paramètres de l'Adspec GS C_ATM et D_ATM.


Le tableau du routeur d'entrée DEVRAIT mémoriser les valeurs pour le MPL <x,7> de réseau ATM pour les divers points de sortie. Les valeurs <x,8> composées sont formées par addition et transmises le long du chemin. Dans les cas où l'acheminement ATM choisit des chemins différents, selon la catégorie de service, pour les circuits virtuels pour un certain point de sortie, le tableau va généralement refléter des valeurs différentes pour chaque service. Si le réseau ATM est très grand et complexe, il peut devenir difficile de prédire les chemins que vont prendre les circuits virtuels une fois établis. Cela pourrait être une source significative de mauvaises configurations, résultant en discordances entre les annonces de délai de GS et les résultats réels. Le terme de surlongueur de la RSpec peut être utile pour atténuer ce problème.


AAL-5 va prendre en charge toutes les tailles de message jusqu'à 65 535 octets, de sorte que régler la SDU AAL à la valeur du paramètre M de la TSpec du receveur (plus 8 octets pour l'en-tête LLC/SNAP) ne va généralement pas être un problème. Dans l'Adspec PATH, cependant, le paramètre PATH_MTU <x,10> pour chaque service DEVRAIT être réglé à 9188 octets, qui est la MTU par défaut pour AAL-5 [19].


3.2 Traitement du trafic excédentaire

Pour les services intégrés IP, les éléments de réseau vont transporter le trafic en excès des paramètres de la TSpec chaque fois que des ressources physiques (bande passante, mémoires tampons et capacité de traitement) sont disponibles. (Dans le CLS un "élément de réseau DOIT essayer de transmettre au mieux le trafic en excès" sous certaines conditions ; et dans le GS un régulateur de trafic "DEVRAIT reléguer en au mieux les datagrammes non conformes".) Alors que le trafic en excès DEVRAIT être pris en charge au mieux, il NE DOIT PAS interférer avec la QS (délai et pertes) du trafic CLS et GS conforme, ni avec le service normal du trafic au mieux non réservé.


Il y a plusieurs solutions avec ATM : la plus intéressante est d'utiliser une catégorie de service VBR (avec une définition de conformité appropriée) et d'étiqueter le trafic excédentaire comme de faible priorité en utilisant le bit CLP. Cela évite de réarranger le flux, mais nécessite une conception soigneuse du programmeur du routeur de sortie. Pour éviter de réarranger le trafic en excès, il peut être mis en file d'attente avec le trafic conforme. Un seuil DEVRAIT être utilisé pour assurer que le trafic conforme n'est pas retardé inutilement par l'excédentaire. Aussi, pour GS, le retard supplémentaire qui devrait être subi à cause du trafic excédentaire dans la file d'attente qui se trouve devant les paquets conformes devrait être précisément reflété dans l'annonce de délai. Noter que le routeur d'entrée DEVRAIT étiqueter toutes les cellules de chaque paquet non conforme, plutôt que de laisser le réseau ATM appliquer l'étiquetage dû à la non conformité de niveau ATM.


Il n'est pas exigé par les normes ATM que les cellules étiquetées, marquées par l'usager ou par la régulation, soient transportées si c'est possible. Donc, l'opérateur d'un routeur bordure qui prend en charge IP-IS DEVRAIT s'assurer du comportement réel de l'équipement ATM dans le chemin, qui peut s'étendre sur plusieurs domaines administratifs dans le réseau ATM. Si les cellules étiquetées sont simplement abandonnées à un certain point, sans considération de la charge, l'opérateur peut alors envisager d'établir le bit de coupure, au moins pour le service CLS.


Les autres solutions impliquent généralement un circuit virtuel distinct pour transporter l'excédent. Un VC distinct peut être établi pour chaque VC qui prend en charge un flux GS ou CLS, ou, si de nombreux flux sont agrégés dans un seul VC de QS, un autre VC peut alors contenir le trafic en excès pour cet ensemble de flux. Un VC peut être établi pour traiter tout le trafic en excès du routeur de sortie au point de sortie. Comme la QS du trafic en excès n'est pas particulièrement contrainte, la conception est assez souple. Cependant, utiliser un VC distinct peut causer le désordre des paquets au sein d'un flux.


La catégorie de service pour le VC du trafic excédentaire peut normalement être UBR ou ABR, bien qu'on puisse utiliser CBR ou nrtVBR si le trafic en excès était assez prévisible pour qu'on sache quel taux lui allouer. (On ne peut normalement pas s'y attendre pour du trafic excédentaire.)


La décision d'un VC séparé peut être influencée par la conception du programmateur de routeur. La spécification de CLS suggère deux mises en œuvre possibles : une où le trafic excédentaire partage l'allocation par le programmateur de la classe au mieux, mais à une priorité inférieure au reste du trafic au mieux, et l'autre où est faite une allocation distincte. La première permettrait au trafic en excès d'utiliser le même VC que le trafic normal au mieux, et la second suggèrerait un VC séparé.


TM/UNI 4.0. ne prend pas en charge l'étiquetage du trafic en excès de PCR. Bien que UNI 3.x n'ait pas un paramètre PCR distinct pour les seules cellules CLP = 0, on ne recommande pas d'utiliser ce dispositif pour des raisons d'interopérabilité avec les équipements TM/UNI 4.0. Cela contraint les VC CBR à utiliser des solutions autres que l'étiquetage. La valeur de PCR peut être réglée plus haut que nécessaire pour le trafic conforme, afin de prendre en charge le trafic en excédent sur le même VC. Dans certains cas, cela peut être une solution viable, comme lorsque le coût supplémentaire imposé par un PCR élevé est faible. Si le PCR peut être réglé aussi haut que l'APB, le trafic en excès est alors entièrement traité.


3.3 Utilisation des paramètres Adspec et Terme de surlongueur du service garanti

Adspec est utilisé par le service garanti pour permettre à un receveur de calculer le plus mauvais cas de délai associé à un flux GS. Trois quantités, C, D, et MPL, sont cumulées (par simple addition des composants correspondants à chaque élément de réseau) dans le message PATH de la source au receveur. Les valeurs de délai résultantes peuvent être différentes pour chaque receveur individuel. Le délai maximum est calculé par :


délai ≤ b_r/R + C_TOT/R + D_TOT + MPL


La latence minimum de chemin (MPL) inclut le délai de propagation, alors que b_r/R tient compte des salves dues à la source et C et D incluent les autres délais de mise en file d'attente, de programmation et de mise en série. (On néglige ici les effets de la taille maximum de paquet et du taux de crête ; voir dans la spécification du GS [8] une équation plus détaillée.) Le taux de service demandé par le receveur, R, peut être supérieur au taux de la TSpec, r_r, résultant en un délai inférieur. La taille de salve, b_r, est le paramètre de baquet à fuite de la TSpec du receveur.


Les valeurs de C et D qu'un routeur annonce dépendent à la fois du programmeur de paquet du routeur et des caractéristiques du sous-réseau rattaché au routeur. Chaque routeur (ou l'hôte de source) prend la responsabilité de son sous-réseau aval dans son annonce. Par exemple, si le sous-réseau est une simple liaison point à point, les parties de C et D spécifiques du sous-réseau doivent tenir compte du taux de transmission et de la MTU de la liaison. Un sous-réseau ATM est généralement plus complexe.


Pour cette discussion, on considère seulement les composants spécifiques du sous-réseau ATM, notés C_ATM et D_ATM. Le réseau ATM peut être représenté comme un élément de "pur délai", où le délai variable de mise en file d'attente donné par le CVD est capturé dans D_ATM et C_ATM est réglé à zéro. Il n'est possible d'utiliser C_ATM que lorsque le taux de service ATM est égal à R. Cela peut être le cas, par exemple avec un VC CBR avec PCR = R.


Il sera généralement plus simple de juste annoncer la variation du délai total (CDV) dans D_ATM.


Comme exposé au paragraphe 2.6, le routeur bordure conserve un tableau des valeurs de MPL et de D_ATM pour chaque routeur de sortie avec lequel il a besoin de partager des circuits virtuels. La valeur de D_ATM contribue au paramètre D annoncé par le routeur bordure, et DEVRAIT refléter précisément la CDV que le routeur va obtenir dans un VC lorsque il est établi. Les facteurs qui affectent la CDV, tels que le multiplexage statistique dans le réseau ATM, DEVRAIENT être pris en compte lors de la compilation des données pour le tableau du routeur. En cas d'incertitude, D_ATM peut être réglé à une limite supérieure. Lorsque un message RESV arrive, causant l'établissement d'un VC, les valeurs demandées pour CTD et CDV peuvent être assouplies en utilisant le terme de surlongueur dans la RSpec du receveur :


CTD = D_ATM + MPL + S_ATM

CDV = D_ATM + S_ATM.


Le terme S_ATM est la portion du terme de surlongueur appliquée à la portion ATM du chemin. On rappelle que le terme de surlongueur [8] est positif lorsque le receveur peut se permettre plus de délai que celui calculé à partir de l'Adspec. L'appareil bordure ATM peut prendre une partie (ou la totalité) du terme de surlongueur, S. La distribution de la relaxation du délai entre les nœuds et sous-réseaux est spécifique du réseau.


Noter qu'avec les circuits virtuels en multipoint, le routeur bordure de sortie peut avoir besoin de corriger les valeurs annoncées de C et de D. Voir l'exposé du paragraphe 3.1.


4. Éléments divers

4.1 Conversion d'unités

Tous les paramètres de taux et de profondeur de baquet de jetons qui sont transposés des paramètres de niveau IP en paramètres ATM DOIVENT être corrigés des effets de l'ajout des en-têtes et de la segmentation des paquets en cellules. À la couche IP, les profondeurs de baquet de jetons et les taux sont mesurés respectivement en octets et octets/s, tandis que pour ATM, ils sont mesurés en cellules et en cellules/s.


Chaque paquet IP est enveloppé dans une PDU AAL-5, avec un certain nombre d'octets d'en-tête supplémentaires (8 pour LLC/SNAP et peut-être d'autres, par exemple 12 pour MPOA, etc.) et un en-queue AAL-5 de huit octets. La PDU AAL-5 est alors segmentée en plusieurs cellules ATM, chacune ayant un en-tête de cellule de 5 octets suivi par une charge utile de cellule de 48 octets. Le nombre de cellules utilisé pour porter un paquet IP avec

B = nombre d'octets de paquet IP,

H = nombre d'octets d'en-tête AAL-5 (LLC/SNAP etc.)

C = nombre de cellules,

est en gros :


C = B/48,

et plus précisément :


C = plancher[(H + B + 8 + 47)/48]


où plancher[] est arrondi au plus proche entier inférieur. Le '8' tient compte de l'en-queue AAL-5 et le '47' tient compte de la dernière cellule qui peut n'être que partiellement remplie.


5. Résumé des paramètres d'établissement de VC ATM pour le service garanti


La présente section décrit comment créer des circuits virtuels ATM correspondant de façon appropriée au service garanti. Les points clés sont que le rythme du temps réel est EXIGÉ, que le flux de données peut avoir un taux variable, et que le déclassement du trafic non conforme en trafic au mieux est EXIGÉ pour être en accord avec la définition de GS. Pour cette raison, on préfère un service rtVBR dans lequel l'étiquetage est pris en charge. Une autre bonne correspondance est d'utiliser le CBR avec un traitement spécial de tout trafic non conforme, par exemple, par un autre VC, car un VC CBR ne va pas s'accommoder du trafic qui dépasse le PCR.


Note : ces codages supposent des connexions en point à multipoint, dans lesquelles le canal de retour n'est pas utilisé. Si la session IP est en envoi individuel seul, un circuit virtuel en point à point peut être utilisé et la IWF peut faire usage du canal de retour, avec les paramètres de QS réglés de façon appropriée pour le service fourni.


On donne une transposition pour toutes les combinaisons de catégories de service IP et de service ATM, et des commentaires qui indiquent si chaque combinaison satisfait ou non aux exigences du service IP-IS.


5.1 Codage de GS en utilisant le VBR en temps réel (ATM Forum TM/UNI 4.0)

RtVBR avec la définition de conformité de VBR.3 [6] satisfait aux exigences de GS.


AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

PCR CLP vers l'avant = 0 + 1 Note 1

PCR CLP vers l'arrière = 0 + 1 0

SCR CLP vers l'avant = 0 Note 1

MBS vers l'arrière = 0 0

MBS vers l'avant (CLP = 0) Note 1

MBS vers l'arrière (CLP = 0) 0

Indicateur au mieux NON inclus

Bit d'élimination de trame vers l'avant 1

Bit d'élimination de trame vers l'arrière 1

Bit d'étiquetage vers l'avant 1 (Étiquetage exigé)

Bit d'étiquetage vers l'arrière 1 (Étiquetage exigé)


Capacité de support haut débit

Classe de support 16 (BCOB-X) Note 2

Capacité de transfert ATM 9 (VBR en temps réel) Note 3

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Informations d'utilisateur de coucher 3

Protocole 11 (ISO/CEI TR 9577) Note 4

IPI ISO/CEI TR 9577 204


Classe de QS

Classe de QS vers l'avant 1 Note 5

Classe de QS vers l'arrière 1 Note 5


Paramètres de QS étendus Note 6

CDV acceptable vers l'avant

CLR acceptable vers l'avant

CTD maximal vers l'avant


Note 1 : Voir l'exposé du paragraphe 2.5.1.

Note 2 : La valeur 3 (BCOB-C) peut aussi être utilisée. Si la classe de support C est choisie, le champ ATC DOIT être absent.

Note 3 : La valeur ATC 19 n'est pas utilisée. Elle implique que l'objectif de CLR s'applique au flux agrégé CLP = 0+1 et cela ne donne pas un traitement souhaitable du trafic excédentaire.

Note 4 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, permettant que le VC soit partagé par plusieurs protocoles, suivant la RFC 1755.

Note 5 : Cf. la Rec. UIT-T I.356 [21] pour de nouvelles définitions de classe de QS.

Note 6 : Voir l'exposé au paragraphe 2.6.


5.2 Codage de GS en CBR (ATM Forum TM/UNI 4.0)

Un VC CBR satisfait aux exigences de GS. Le principal avantage en est que le CBR est largement pris en charge ; l'inconvénient est que les flux de données pourraient ne pas remplir le tuyau (perte d'utilisation) et qu'il n'y a pas d'option d'étiquetage disponible. Le trafic excédentaire DOIT être traité en utilisant un VC distinct.


AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

PCR CLP vers l'avant = 0+1 Note 1

PCR CLP vers l'arrière = 0+1 0

Indicateur au mieux NON inclus

Bit d'élimination de trame vers l'avant 1

Bit d'élimination de trame vers l'arrière 1

Bit d'étiquetage vers l'avant 0 (étiquetage non exigé)

Bit d'étiquetage vers l'arrière 0 (étiquetage non exigé)


Capacité de support haut débit

Classe de support 16 (BCOB-X) Note 2

Capacité de transfert ATM 5 (CBR) Note 3

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Informations d'utilisateur de couche 3

Protocole 11 (ISO/CEI TR 9577) Note 4

IPI ISO/CEI TR 9577 204

Classe de QS

Classe QS vers l'avant 1 Note 5

Classe de QS vers l'arrière 1 Note 5


Paramètres de QS étendus Note 6

CDV acceptable vers l'avant

CLR acceptable vers l'avant

CTD maximum vers l'avant


Note 1 : Voir l'exposé au paragraphe 2.5.1.

Note 2 : La valeur 1 (BCOB-A) peut aussi être utilisée. Si la classe de support A est choisie, le champ ATC DOIT être absent.

Note 3 : La valeur ATC 7 n'est pas utilisée. Cette valeur implique que l'objectif de CLR s'applique au flux CLP = 0+1 agrégé et cela ne donne pas un traitement souhaitable pour le trafic excédentaire.

Note 4 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié ce qui permet au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.

Note 5 : Cf. la Rec. UIT-T I.356 [21] pour de nouvelles définitions de classe de QS.

Note 6 : Voir l'exposé au paragraphe 2.6.


5.3 Codage de GS en VBR en différé (ATM Forum TM/UNI 4.0)

NrtVBR ne fournit pas de garanties de délai et N'EST PAS RECOMMANDÉ pour GS. Si GS/nrtVBR est utilisé et si l'utilisation du réseau est faible, le délai peut être `raisonnable, mais ne sera pas contrôlé. Le codage de GS avec nrtVBR est le même que celui de CLS avec nrtVBR. Voir au paragraphe 6.1 ci-dessous.


5.4 Codage de GS avec ABR (ATM Forum TM/UNI 4.0)

GS utilisant ABR est une combinaison très peu probable, et NE SATISFAIT PAS les exigences de service de GS. L'objectif du service ABR est de fournir de "faibles" taux de pertes. Les objectifs de délai pour ABR DEVRAIENT être très lâches. Si ABR était utilisé pour GS, les paramètres de VC devraient suivre ceux de CLS sur ABR. Voir au paragraphe 6.2.


5.5 Codage de GS avec UBR (ATM Forum TM/UNI 4.0)

Le service UBR est le plus petit dénominateur commun des services. Il ne peut pas fournir de garanties de délai ou de perte, et donc, ne satisfait pas aux exigences de GS. Cependant, si il est utilisé pour GS, il sera codé de la même façon que le service au mieux sur UBR, à l'exception du PCR vers l'avant qui serait déterminé à partir du taux de crête de la TSpec du receveur. Voir au paragraphe 7.1.


5.6 Codage de GS avec les spécification de ATM Forum UNI 3.0/3.1

Il n'est pas recommandé d'assurer GS en utilisant le mode VBR de UNI 3.x parce que la classe BCOB-C de support ne représente pas un comportement de temps réel. Aussi, l'appendice F de la spécification UNI 3.1 empêche la spécification du type de trafic "VBR" avec l'exigence de synchronisation "Synchronisation de bout en bout exigée" en conjonction avec la classe de support X.


Un VC CBR satisfait aux exigences de GS. Le tableau qui suit spécifie le soutien de GS en utilisant CBR.


AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Mode 1 (Mode message) Note 1

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

PCR CLP vers l'avant = 0 Note 2

PCR CLP vers l'arrière = 0 0

PCR CLP vers l'avant = 0+1 Note 2

PCR CLP vers l'arrière =0+1 0

Indicateur au mieux NON inclus

Bit d'étiquetage vers l'avant 1 (Étiquetage exigé)

Bit d'étiquetage vers l'arrière 1 (Étiquetage exigé)


Capacité de support haut débit

Classe de support 16 (BCOB-X) Note 3

Type de trafic 001 (Débit binaire constant)

Exigences de synchronisation 01 (Synchronisation exigée)

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)



Informations de couche inférieure haut débit

Information d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Information d'utilisateur de couche 3

Protocole 11 (ISO/CEI TR 9577) Note 4

IPI ISO/CEI TR 9577 204


Classe de QS Note 5

Classe QS vers l'avant 1

Classe de QS vers l'arrière 1


Note 1 : N'est inclus que pour UNI 3.0.

Note 2 : Voir l'exposé au paragraphe 2.5.1. PCR CLP = 0 DEVRAIT être réglé identique à PCR CLP = 0+1. Bien que cela puisse éventuellement permettre à un VC CBR de porter le trafic excédentaire comme des cellules étiquetées, ce n'est pas recommandé car ce n'est pas accepté par UNI 4.0

Note 3 : La valeur 1 (BCOB-A) peut aussi être utilisée. Si BCOB-A est utilisé, les champs Type de trafic et Exigences de synchronisation ne sont pas inclus.

Note 4 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, ce qui permet au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.

Note 5 : Les paramètres de QS sont impliqués par la classe de QS.


6. Résumé des paramètres d'établissement de VC ATM pour le service de charge contrôlée


La présente section décrit comment créer des VC ATM correspondant de façon appropriée au service à charge contrôlée. Le trafic CLS est partiellement tolérant au délai et a un taux variable. NrtVBR et ABR (TM/UNI 4.0 seulement) sont les meilleurs choix pour la prise en charge de CLS.


Note : Ces codages supposent des connexions en point à multipoint dans lesquelles le canal de retour n'est pas utilisé. Si la session IP est seulement en envoi individuel, un VC en point à point peut être utilisé et la IWF peut faire usage du canal de retour, avec les paramètres de QS réglés de façon appropriée pour le service fourni.


On donne une transposition pour toutes les combinaisons de catégorie de service IP et ATM, et des commentaires indiquant si chaque combinaison satisfait ou non aux exigences du service IP-IS.


6.1 Codage de CLS avec un VBR en différé (ATM Forum TM/UNI 4.0)

NrtVBR SATISFAIT aux exigences pour CLS.


AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

PCR CLP vers l'avant = 0+1 Note 1

PCR CLP vers l'arrière =0+1 0

SCR CLP vers l'avant = 0 Note 1

MBS vers l'arrière = 0 0

MBS vers l'avant (CLP = 0) Note 1

MBS vers l'arrière (CLP = 0) 0

Indicateur au mieux NON inclus

Bit d'élimination de trame vers l'avant 1

Bit d'élimination de trame vers l'arrière 1

Bit d'étiquetage vers l'avant 1 (Étiquetage exigé)

Bit d'étiquetage vers l'arrière 1 (Étiquetage exigé)


Capacités de support haut débit

Classe de support 16 (BCOB-X) Note 2

Capacité de transfert ATM 10 (VBR en différé) Note 3

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Informations d'utilisateur de couche 3

Protocole 11 (ISO/CEI TR 9577) Note 4

IPI ISO/CEI TR 9577 204


Classe de QS

Classe de QS vers l'avant 3 Note 5

Classe de QS vers l'arrière 3 Note 5


Paramètres de QS étendus Note 6

CDV acceptable vers l'avant

CLR acceptable vers l'avant

CTD maximum vers l'avant

Note 1 : Voir l'exposé au paragraphe 2.5.2.

Note 2 : La valeur 3 (BCOB-C) peut aussi être utilisée. Si la classe de support C est utilisée, le champ ATC DOIT être absent.

Note 3 : La valeur ATC 11 n'est pas utilisée. Elle implique que l'objectif de CLR s'applique au flux CLP = 0+1 agrégé et cela ne donne pas un traitement souhaitable du trafic excédentaire.

Note 4 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, permettant au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.

Note 5 : Cf. la Rec. UIT-T I.356 [21] pour de nouvelles définitions de classe de QS.

Note 6 : Voir l'exposé au paragraphe 2.6.


6.2 Codage de CLS avec ABR (ATM Forum TM/UNI 4.0)

ABR SATISFAIT aux exigences pour CLS lorsque MCR est réglé au taux de la TSpec CLS.

AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

CLP PCR vers l'avant = 0+1 Note 1

CLP PCR vers l'arrière = 0+1 0

CLP MCR vers l'avant = 0+1 Note 1

CLP MCR vers l'arrière = 0+1 0

Indicateur au mieux NON inclus

Bit d'élimination de trame vers l'avant 1

Bit d'élimination de trame vers l'arrière 1

Bit d'étiquetage vers l'avant 0 (étiquetage non exigé)

Bit d'étiquetage vers l'arrière 0 (étiquetage non exigé)


Capacités de support haut débit

Classe de support 16 (BCOB-X) Note 2

Capacité de transfert ATM 12 (ABR)

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 00 (Point à point)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Informations d'utilisateur de couche 3

Protocole 11 (ISO/CEI TR 9577) Note 3

IPI ISO/CEI TR 9577 204


Classe de QS

Classe de QS vers l'avant 0 Note 4

Classe de QS vers l'arrière 0 Note 4


Paramètres de QS étendus Note 5

CDV acceptable vers l'avant

CLR acceptable vers l'avant

CTD maximum vers l'avant

Paramètres d'établissement d'ABR Note 6

Paramètres ABR supplémentaires Note 6


Note 1 : Voir l'exposé au paragraphe 2.5.2.

Note 2 : La valeur 3 (BCOB-C) peut aussi être utilisée. Si la classe de support C est choisie, le champ ATC DOIT être absent.

Note 3 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, permettant au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.

Note 4 : Cf. la Rec. UIT-T I.356 [21] pour les nouvelles définitions de classe de QS.

Note 5 : Voir l'exposé au paragraphe 2.6.

Note 6 : Les paramètres spécifiques de ABR sortent du domaine d'application du présent document. Ils dépendent en général de la mise en œuvre locale et non des valeurs transposées des paramètres de service de niveau IP (excepté le MCR). Voir des informations complémentaires dans [6], [11].


6.3 Codage de CLS avec CBR (ATM Forum TM/UNI 4.0)

Bien que CBR ne tienne pas explicitement compte du débit variable des données de source, il peut être pratique d'utiliser la connexité ATM entre des routeurs bordures pour fournir un simple service de "tuyau", comme remplacement d'une liaison louée. Comme l'option d'étiquetage n'est pas disponible avec CBR, le trafic excédentaire DOIT être traité avec un circuit virtuel séparé. Dans ces conditions, CBR SATISFAIT aux exigences de CLS.


Pour utiliser CBR pour CLS, le même codage sera utilisé que pour GS sur CBR (paragraphe 5.2). Voir l'exposé au paragraphe 2.5.2.


6.4 Codage de CLS avec VBR en temps réel (ATM Forum TM/UNI 4.0)

Le codage de CLS avec rtVBR implique une limite matérielle au délai de bout en bout dans le réseau ATM. Cela crée plus de complexité dans l'établissement du VC que ne l'exige le service CLS, et ce n'est donc pas une combinaison préférée, quoiqu'elle SATISFASSE bien aux exigences de CLS.


Si rtVBR est utilisé pour coder CLS, le codage est alors essentiellement le même que pour GS. Voir les discussions aux paragraphes 5.1 et 2.5.2.


6.5 Codage de CLS avec UBR (ATM Forum TM/UNI 4.0)

Ce codage ne donne pas de garanties de QS et NE SATISFAIT PAS aux exigences de CLS. Si il est utilisé, il est codé de la même façon que pour le service au mieux sur UBR (paragraphe 7.1) excepté que le PCR serait déterminé à partir du taux de crête de la TSpec du receveur.


6.6 Codage de CLS avec les spécifications UNI 3.0/3.1 de l'ATM Forum

Ce codage est équivalent à la catégorie de service nrtVBR. Il SATISFAIT aux exigences de CLS.


AAL

Type 5

Taille de CPCS-SDU vers l'avant paramètre M de la Tspec de receveur + 8 octets

Taille de CPCS-SDU vers l'arrière paramètre M de la Tspec de receveur + 8 octets

Mode 1 (Mode message) Note 1

Type de SSCS 0 (SSCS nul)

Descripteur de trafic

PCR CLP vers l'avant = 0+1 Note 2

PCR CLP vers l'arrière = 0+1 0

SCR CLP vers l'avant = 0 Note 2

MBS vers l'arrière = 0 0

MBS vers l'avant (CLP = 0) Note 2

MBS vers l'arrière (CLP = 0) 0

Indicateur au mieux NON inclus

Bit d'étiquetage vers l'avant 1 (Étiquetage exigé)

Bit d'étiquetage vers l'arrière 1 (Étiquetage exigé)


Capacités de support haut débit

Classe de support 16 (BCOB-X) Note 3

Type de trafic 010 (Débit binaire variable)

Exigences de synchronisation 00 (Pas d'indication)

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2)

Informations d'utilisateur de couche 3

Protocole 11 (ISO/CEI TR 9577) Note 4

IPI ISO/CEI TR 9577 204


Classe de QS

Classe de QS vers l'avant 3 Note 5

Classe de QS vers l'arrière 3 Note 5


Note 1 : Seulement inclus pour UNI 3.0.

Note 2 : Voir l'exposé au paragraphe 2.5.2.

Note 3 : La valeur 3 (BCOB-C) peut aussi être utilisée. Si BCOB-C est utilisé, les champs Type de trafic et Exigences de synchronisation ne sont pas inclus.

Note 4 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, permettant au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.

Note 5 : Cf. la Rec. UIT-T I.356 [21] pour de nouvelles définitions de classe de QS. Les paramètres de QS sont impliqués par la classe de QS.


7. Résumé des paramètres d'établissement de VC ATM pour le service au mieux


La présente section est fournie seulement dans un souci de complétude. Les documents du groupe de travail ION de l'IETF sur la prise en charge de la signalisation ATM pour IP sur ATM [10], [11], fournissent les spécifications définitives pour le service IP au mieux sur ATM.


La catégorie de service ATM la mieux assortie pour IP au mieux est UBR. On fournit ci-dessous les détails de l'établissement de ce cas. Le service au mieux implique une réservation de ressources. ABR et nrtVBR conviennent bien également au service au mieux. Voir l'exposé au paragraphe 2.1.3.


Note : Les VC qui prennent en charge le service au mieux sont généralement en point à point, plutôt qu'en point à multipoint, et les canaux de retour des VC sont utilisés. Dans les cas où les VC sont établis pour prendre en charge des sessions en diffusion groupée au mieux, des VC multipoint peuvent être utilisés et les canaux de retour n'auraient pas de ressources réservées. Les situations qui s'y rapportent incluent le transport du trafic excédentaire sur les session à QS de diffusion groupée IP, ou pour la prise en charge du sous-ensemble de systèmes d'extrémité d'une diffusion groupée qui n'a pas fait de réservations RSVP. Voir la discussion sur la gestion de VC dans [12].


7.1 Codage du service au mieux avec UBR (ATM Forum TM/UNI 4.0)

AAL

Type 5

Taille de CPCS-SDU vers l'avant 9188 octets (MTU par défaut for AAL-5)

Taille de CPCS-SDU vers l'arrière 9188 octets (MTU par défaut for AAL-5)

Type de SSCS 0 (SSCS nul)


Descripteur de trafic

PCR CLP vers l'avant = 0+1 Note 1

PCR CLP vers l'arrière = 0+1 0

Indicateur au mieux inclus

Bit d'élimination de trame vers l'avant 1

Bit d'élimination de trame vers l'arrière 1

Bit d'étiquetage vers l'avant 1 (Étiquetage exigé)

Bit d'étiquetage vers l'arrière 1 (Étiquetage exigé)


Capacités de support haut débit

Classe de support 16 (BCOB-X) Note 2

Capacité de transfert ATM 10 (VBR en différé)

Susceptible d'écrêtage 00 (Non susceptible)

Configuration de plan d'utilisateur 01 (Point à multipoint)


Informations de couche inférieure haut débit

Informations d'utilisateur de couche 2

Protocole 12 (ISO 8802/2) Note 3


Classe de QS

Classe de QS vers l'avant 0

Classe de QS vers l'arrière 0


Note 1 : Voir l'exposé au paragraphe 2.5.3.

Note 2 : La valeur 3 (BCOB-C) peut aussi être utilisée. Si la classe de support C est utilisée, le champ ATC DOIT être absent.

Note 3 : Pour les VC de QS qui prennent en charge GS ou CLS, le protocole de couche 3 DEVRAIT être spécifié. Pour les VC au mieux, il peut rester non spécifié, permettant au VC d'être partagé par plusieurs protocoles, suivant la RFC1755.


8. Considérations pour la sécurité


Les services intégrés IP (y compris RSVP) et ATM sont tous deux des protocoles complexes de réservation de ressources, et DEVRAIENT être considérés comme ayant des interactions de caractéristiques complexes.


Les différences de style de facturation dans IP et dans ATM pourraient causer des problèmes imprévus car les messages RESV peuvent établir des circuits virtuels. Par exemple, un utilisateur final qui paye un forfait pour le service Internet (sans fourniture de RSVP) peut envoyer un message RESV RSVP qui rencontre un réseau ATM (peut-être distant) avec un modèle de facturation à l'utilisation. Une authentification insuffisante pourrait résulter en services accidentellement facturés à un tiers innocent, en vol intentionnel de service, ou en attaques malveillantes de déni de service où de forts volumes de réservations consomment des ressources de transport ou de traitement sur les appareils de bordure.


La différence des styles de traitement du trafic en excédent pourrait résulter en attaques de déni de service où le réseau ATM utilise des ressources de transport (de la bande passante, des mémoires tampon) ou des ressources de traitement de connexion (cycles de processeur de commutation) en tentant de s'accommoder du trafic en excès qui a été admis par le service internet.


Les problèmes associés à la traduction des réservations de ressources aux appareils de bordure sont probablement plus complexes et susceptibles de détournements lorsque la bordure IP-ATM est aussi une frontière administrative entre des fournisseurs de services. Noter aussi que les frontières administratives peuvent exister au sein du nuage ATM, c'est-à-dire, les appareils de bordure d'entrée et de sortie sont gérés par des fournisseurs de service différents.


Noter que le groupe de travail Sécurité de l'ATM Forum travaille actuellement à la définition des caractéristiques de sécurité au niveau d'ATM, telles que le chiffrement des données et l'authentification de la signalisation. Voir aussi les questions de sécurité soulevées dans la spécification RSVP [3].


9. Remerciements


Les auteurs ont reçu de nombreux apports utiles de la part des membres du groupe de travail ISSLL. En particulier, nos remerciements à Drew Perkins et Jon Bennett de Fore Systems, à Roch Guerin d'IBM, à Susan Thomson et Sudha Ramesh de Bellcore.


Appendice 1 Abréviations


AAL (ATM Adaptation Layer) couche d'adaptation ATM

ABR (Available Bit Rate) débit binaire disponible

APB (Available Path Bandwidth) (int-serv GCP) bande passante disponible du chemin

ATC (Capacité de transfert ATM) capacité de transfert ATM

ATM (Asynchronous Transfer Mode) mode de transfert asynchrone

B-LLI (Informations de couche inférieure haut débit) informations de couche basse à haut débit

BCOB (Broadband Connection-Oriented Bearer Capability) service support orienté connexion à large bande

BCOB-{A,C,X} (Classe de support A, C, or X) service support orienté connexion à large bande - sous-catégorie A, C, ou X

BE (Best Effort) au mieux

BT (Burst Tolerance) tolérance de salve

CBR (Constant Bit Rate) débit binaire constant

CDV (Cell Delay Variation) variation de délai de cellule

CDVT (Cell Delay Variation Tolerance) tolérance de variation de délai de cellule

CLP (Cell Loss Priority (bit)) (bit de) priorité de perte de cellule

CLR (Cell Loss Ratio) taux de perte de cellule

CLS (Controlled Load Service) service à charge contrôlée

CPCS (Common Part Convergence Sublayer) partie commune de sous couche de convergence

CTD (Cell Transfer Delay) délai de transfert de cellule

EOM (End of Message) fin de message

GCP (General Characterization Parameter) paramètre de caractérisation générale

GCRA (Generic Cell Rate Algorithm) algorithme générique de débit de cellules

GS (Guaranteed Service) service garanti

IE (Information Element) élément d'information

IETF (Internet Engineering Task Force) équipe d'ingénierie de l'Internet

ION (IP Over Non-broadcast multiple access networks) IP sur réseau d'accès multiple sans diffusion

IP (Internet Protocol) protocole Internet

IPI (Initial Protocol Identifier) identifiant de protocole initial

IS (Integrated Services) services intégrés

ISSLL (Integrated Services over Specific Link Layers) services intégrés sur couches de liaison spécifiques

ITU (International Telecommunication Union) Union Internationale des Télécommunications (UIT)

IWF (Interworking Function) fonction d'interopération

LIJ (Leaf Initiated Join) adhésion à l'initiative de l'extrémité

LLC (Logical Link Control) contrôle de liaison logique

MBS (Maximum Burst Size) taille de salve maximum

MCR (Minimum Cell Rate) débit de cellule minimum

MPL (Minimum Path Latency) latence minimum de chemin

MTU (Maximum Transfer Unit) unité maximum de transfert

nrtVBR (Non-real-time VBR) débit binaire variable en différé

PCR (Peak Cell Rate) débit cellulaire de crête

PDU (Protocol Data Unit) unité de données de protocole

PVC (Permanent Virtual Connection) connexion virtuelle permanente

QoS (Quality of Service) qualité de service (QS)

RESV (Reservation Message (of rsvp protocol)) message de réservation (du protocole RSVP)

RFC (Request for Comments) demande de commentaires

RSVP (Resource Reservation Protocol) protocole de réservation de ressource

RSpec (Reservation Specification) spécification de réservation

rtVBR (Real-time VBR) débit binaire variable en temps réel

SCR (Sustainable Cell Rate) débit cellulaire soutenable

SDU (Service Data Unit) unité de données de service

SNAP (Subnetwork Attachment Point) point de rattachement de sous-réseau

SSCS (Service-Specific Convergence Sub-layer) sous couche de convergence spécifique du service

SVC (Switched Virtual Connection) connexion virtuelle commutée

TCP (Transport Control Protocol) protocole de contrôle du transport

TM (Traffic Management) gestion du trafic

TSpec (Traffic Specification) spécification du trafic

UBR (Unspecified Bit Rate) débit binaire non spécifié

UNI (User-Network Interface) interface usager-réseau

UPC (Usage Parameter Control) contrôle de paramètre d'usage (fonction de régulation du trafic ATM)

VBR (Variable Bit Rate) débit binaire variable

VC (Virtual Connection) connexion virtuelle (ATM)


Références


[1] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", RFC2119, BCP 14, mars 1997.


[2] R. Braden, D. Clark et S. Shenker, "Intégration de services dans l'architecture de l'Internet : généralités", RFC1633, juin 1994. (Info.)


[3] R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", RFC2205, septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495) (P.S.)


[4] The ATM Forum, "ATM User-Network Interface Specification, Version 3.0", Prentice Hall, Englewood Cliffs NJ, 1993.


[5] The ATM Forum, "ATM User-Network Interface Specification, Version 3.1", Prentice Hall, Upper Saddle River NJ, 1995.


[6] The ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification, Version 4.0", juillet 1996. Disponible à ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.ps.


[7] The ATM Forum, "ATM Traffic Management Specification, Version 4.0", avril 1996. Disponible à ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.ps.


[8] M. W. Garrett, "A Service Architecture for ATM: From Applications to Scheduling", IEEE Network Mag., Vol. 10, n° 3, pp. 6-14, mai 1996.


[9] S. Shenker, C. Partridge, R. Guerin, "Spécification de la qualité de service garantie", RFC2212, septembre 1997. (P.S.)


[10] J. Wroclawski, "Spécification du service d'élément de réseau à charge contrôlée", RFC2211, septembre 1997. (P.S.)


[11] M. Perez et autres, "Prise en charge de la signalisation ATM pour IP sur ATM", RFC1755, février 1995. (P.S.)


[12] M. Maher, "Prise en charge de la signalisation ATM pour IP sur ATM – Mise à jour de la signalisation UNI 4.0", RFC2331, avril 1998. (P.S.)


[13] E. Crawley et autres, "Cadre des services intégrés et de RSVP sur ATM", RFC2382, août 1998. (Information)


[14] L. Berger, "Exigences pour la mise en œuvre de RSVP sur ATM", RFC2380, août 1998. (P.S.)


[15] L. Berger, "Lignes directrices pour la mise en œuvre de RSVP sur ATM", RFC2379, août 1998. (BCP0024)


[16] S. Shenker, J. Wroclawski, "Modèle de spécification de services d'élément de réseau", RFC2216, septembre 1997. (Information)


[17] J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", RFC2210, septembre 1997. (P.S.)


[18] M. Borden, E. Crawley, B. Davie et S. Batsell, "Intégration de services en temps réel dans une architecture de réseau IP-ATM", RFC1821, août 1995.


[19] Juha Heinanen, "Encapsulation multiprotocole sur couche 5 d'adaptation ATM", RFC1483, juillet 1993. (Obsolète, voir la RFC 2684)


[20] M. Laubach, "IP classique et ARP sur ATM", RFC1577, janvier 1994.


[21] Recommandation UIT-T I.356, "Performances du RNIS-LB pour le transfert de cellules de couche ATM", Union Internationale des Télécommunications, Genève, octobre 1996.


[22] A. Romanow, S. Floyd, "Dynamics of TCP Traffic over ATM Networks", IEEE J. Sel. Areas in Commun., Vol. 13, n° 4, pp. 633-41, mai 1995.


[23] A. K. Parekh, R. G. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", IEEE/ACM Trans. Networking, Vol. 2, n° 2, pp. 137-150, avril 1994.


[24] S. Floyd, V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Trans. Networking, Vol. 3, n° 4, août 1995.


[25] S. Shenker, J. Wroclawski, "Paramètres généraux de caractérisation pour éléments de réseau à intégration de service", RFC2215, septembre 1997. (P.S.)


Adresse des auteurs


Mark W. Garrett

Marty Borden

Bellcore

Bay Networks

445 South Street

42 Nagog Park

Morristown, NJ 07960

Acton MA, 01720

USA

USA

téléphone : +1 201 829-4439

téléphone : +1 508 266-1011

mél : mwg@bellcore.com

mél : mborden@baynetworks.com


Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (1998). Tous droits réservés.


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes de l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation à un objet particulier.