Encapsulation multi-protocole sur la couche d'adaptation 5 d'ATM

Statut de ce mémo

Ce mémo procure une norme de protocole à la communauté internet et admet discussions et suggestions pour son amélioration. Consultez l'édition courante des « Normes officielles de protocoles internet » (N.D.T. RFC 2800) pour connaitre l'état de standardisation  et le statut de ce protocole. La distribution de ce mémo est libre.

Copyright

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

Notes de traduction

Le texte original est traduit aussi fidèlement que possible, Les acronymes issus de mots anglais sont conservés tel quels mais généralement explicités à leur première occurrence. Des notes de traduction (N.D.T.) peuvent préciser des concepts qui se décrivent en anglais avec un seul mot ainsi que des caractéristiques ou exceptions françaises.

Généralités

Ce mémo remplace la RFC 1483. Il décrit deux méthodes d'encapsulation pour interconnecter des réseaux sur AAL5 (Couche d'adaptation 5) d' ATM (Réseau de transport asynchrone). La première méthode permet de multiplexer plusieurs protocoles sur un unique circuit virtuel ATM tandis que dans la seconde méthode chaque protocole est transporté sur un circuit virtuel ATM séparé.

Application

Cette spécification est fournie pour les implémenteurs qui utilisent des réseaux ATM pour véhiculer un trafic multi-protocole entre des serveurs, des routeurs et des ponts qui sont aux extrémités du système ATM.

Table des matières

1. Introduction
2. Conventions
3. Choix de la méthode de multiplexage
4. Format des PDUs AAL5
5. L'encapsulation LLC
5.1 Encapsulation LLC pour protocoles routés
5.2 Encapsulation LLC pour protocoles routés
6. Multiplexage par circuit virtuel
6.1 Multiplexage par circuit virtuel des protocoles routés
6.2 Multiplexage par circuit virtuel des protocoles pontés
7. Pontage dans un réseau ATM
8. Identification des réseaux virtuels privés
8.1 En-tête de l'encapsulation VPN
8.2 PDUs routés ou pontés à encapsulation LLC dans un VPN
8.3 PDUs routés ou pontés à multiplexage par circuit virtuel dans un VPN
9. Considérations de sécurité
10. Remerciements
11. Références
12. Annexe A
13. Annexe B
14. Annexe C
15. Annexe D
16. Annexe E
17. Adresses des auteurs
18. Copyright intégral

1. Introduction

De grands réseaux ATM, sur des campus ou dans des réseaux locaux, sont utilisés pour transporter des datagrammes IP et d'autres trafics en mode non-connecté entre serveurs, routeurs, ponts et autres périphériques de réseau. Ce mémo décrit deux méthodes pour véhiculer sur un réseau ATM les PDUs (Unités de données) de protocoles en  mode non-connecté, routés ou pontés. La méthode "Encapsulation LLC" permet de multiplexer plusieurs protocoles sur un unique circuit virtuel ATM. Le type de protocole de chaque PDU est identifié par un en-tête LLC (Lien logique de contrôle) comportant un préfixe IEEE 802.2. Dans la méthode "multiplexage par circuit virtuel", chaque circuit virtuel ATM transporte les PDUs d'un seul type de protocole. Si plusieurs protocoles doivent être transportés, il y a un circuit virtuel pour chacun d'entre eux.
L'unité de transport ATM est la "cellule", d'une longueur fixe de 53 octets. La cellule est formée d'un en-tête de 5 octets et d'une charge utile de 48 octets. Des PDUs de longueur variable, dont ceux décrits dans ce mémo, doivent être fractionnés par l'émetteur pour rentrer dans les 48 octets de la charge utile de la cellule ATM ; puis réassemblés par le récepteur. Ce mémo spécifie l'utilisation d'AAL5 tel que la recommandation I.363.5 [2] de l'ITU-T le défini pour cet usage. Les PDUs de longueur variable sont transportés dans le champ "charge utile" de la CPCS (Sous-couche de convergence - Partie commune) d'AAL5.
Ce mémo ne décrit que la manière dont les PDUs routés et pontés sont transportés directement sur la CPCS d'AAL5, c'est à dire quand la SSCS (Sous-couche de convergence - Services spécifiques) est absente d'AAL5. Si la SSCS "Relais de trames", telle que définie par la recommandation I.365.1 [3] de l'ITU-T, est utilisée, les PDUs routés et pontés sont transportés en utilisant la méthode de multiplexage NLPID décrite dans la RFC 2427 [4]. L'encapsulation décrite dans la RFC 2427 DOIT être utilisée dans le cas particulier de l'utilisation d'un réseau à relais de trames ou d'un service en mode transparent [9], mais N'EST PAS RECOMMANDE pour d'autres applications. L'annexe A (Qui n'est là qu'à titre d'information) montre le format des FR-SSCS-PDU ainsi que la manière dont les PDUs IP et CLNP sont encapsulés sur FR-SSCS selon la RFC 2427.
Ce mémo inclus aussi une encapsulation optionnelle à utiliser sur des réseaux virtuels privés opérant sur un sous-réseau ATM.
Si vous souhaitez utiliser les facilitées du protocole PPP (Protocole Point à Point), et qu'il existe une relation point à point entre les systèmes d'extrémités; la RFC 2364 s'applique plutôt que celle-ci.

2. Conventions

Les mots clés « DOIT », « NE DOIT PAS », « NECESSAIRE », « RECOMMANDE », « PEUT » et « OPTIONNEL », lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit en dans la RFC 2119

3. Choix de la méthode de multiplexage

La décision d'utiliser l'encapsulation LLC ou le multiplexage par circuit virtuel dépend de l'implémentation et des contraintes du système. En général, l'encapsulation LLC tend à utiliser moins de circuits virtuels dans un environnement multi-protocole. Le multiplexage par circuit virtuel tend à réduire la surcharge dûe à la fragmentation (C.A.D. qu'un datagramme IPv4 contenant un paquet de contrôle TCP sans option IP ou TCP tient exactemement dans une cellule unique.).
Quand deux systèmes terminaux ATM souhaitent échanger des PDUs  en mode non-connecté à travers un PVC (Circuit virtuel permanent) ATM, le choix de la méthode de multiplexage est fait par configuration. La signalisation des procédures de contrôle ATM est utilisée pour négotier la méthode d'encapsulation lors de l'utilisation d'un SVC (Circuit virtuel commuté). [5] et [8] précisent comment se déroule cette négociation.

4. Format des PDUs AAL5

Avec les deux méthodes de multiplexage, les PDUs, routés ou pontés, DOIVENT être encapsulés dans le champ "Charge utile" d'un PDU CPCS-AAL5.
La recommandation I.363.5 [2] de l'ITU-T fournit la définition complète du format d'un PDU AAL5 et les procédures à l'émission ainsi qu'à la réception. Le message AAL5 "Mode de service", en mode de fonctionnement "Sans assurance", DOIT être utilisé. L'option "Distribution corrompue" NE DOIT PAS être utilisée. Une temporisation de réassemblage PEUT être utilisée. La description suivante est fournie pour information.
Le format du PDU CPCS-AAL5 est le suivant :

Le champ « charge utile » contient les données de l'utilisateur à concurrence de 2 ^ 16 - 1 octets.
Le champ « PAD » remplit le CPCS-PDU pour le faire correspondre exactement aux cellules ATM de manière à ce que la dernière cellule de 48 octets créée par la sous-couche SAR (Segmentation et Réassemblage) ait le suffixe du CPCS-PDU justifié à droite dans la cellule.
Le champ CPCS-UU (Information utilisateur) est utilisé pour transférer de manière transparente des informations d'utilisateur à utilisateur. Ce champ n'a pas de fonction dans l'encapsulation multi-protocole ATM décrite dans ce mémo et peut contenir n'importe quelle valeur.
Le champ CPI (Indicateur partie commune) aligne le suffixe du CPCS-PDU sur 64 bits. Ce champ doit contenir 0x00.
Le champ « Longueur » indique la longueur, en octets, du champ « charge utile ». La valeur maximale pour le champ « longueur » est de 65535 octets. Un champ « longueur » positionné à 0x00 est utilisé pour la fonction d'abandon.
Le champ CRC est utilisé pour détecter les erreurs dans le CPCS-PDU excepté le champ CRC lui-même.

5. L'encapsulation LLC

L'encapsulation LLC est requise quand plus d'un protocole peut être transporté sur un même circuit virtuel. Afin que le récepteur traite correctement les CPCS-PDU entrants, le champ "Charge utile" contient l'information nécessaire à l'identification du protocole du PDU routé ou ponté. Dans l'encapsulation LLC, cette information DOIT être codée dans l'en-tête LLC placé devant le PDU transporté.
Bien que ce mémo ne traite que des protocoles qui fonctionnent en LLC Type 1 (Mode sans connection ni acquittement), le même principe d'encapsulation s'applique aussi aux protocoles qui fonctionnent en LLC Type 2 (Mode connecté). Dans ce dernier cas, le format et le contenu de l'en-tête LLC est décrit dans IEEE 802.1 et IEEE 802.2.

5.1 Encapsulation LLC pour protocoles routés

Dans l'encapsulation LLC, le type de protocole des PDUs routés DOIT être indiqué en préfixant chaque PDU par un en-tête LLC IEEE 802.2. Dans certains cas, l'en-tête LLC DOIT être suivi par un en-tête SNAP (Point de rattachement de sous-réseau) IEEE 802.1a. En fonctionnement LLC Type 1, l'en-tête LLC DOIT se composer de trois champs d'un octet chacun.

Dans l'encapsulation LLC pour protocoles routés, le champ "Contrôle" doit contenir 0x03, indiquant un PDU non numérique.
La valeur d'en-tête LLC : 0xFE-FE-03 DOIT être utilisée pour identifier un PDU routé au format ISO NLPID (Identificateur ISO de la couche de protocole) (Voir [6] et annexe B). Pour les PDUs routés au format NLPID, le contenu du champ "Charge utile" du PDU CPCS-AAL5 DOIT être le suivant :

Le protocole routé DOIT être identifié par le champ de un octet NLPID (Identificateur de la couche de protocole) qui fait partie des données du protocole. Les valeurs de NLPID sont gérées par l'ISO et l'ITU-T. Elles sont définies dans ISO/IEC TR 9577 [6] et certaines valeurs actuelles sont données en annexe C.
La valeur 0x00 du NLPID est définie par l'ISO/IEC TR 9577 comme couche nulle ou inactive. Puisqu'elle n'a pas de signification dans le contexte de l'encapsulation, une valeur de 0x00 pour le NLPID NE DOIT PAS être utilisée.
Bien qu'il y ait une valeur de NLPID (0xCC) pour indiquer le protocole IP, le format NLPID NE DOIT PAS être utilisé avec IP. Les datagrammes IP DOIVENT plutôt être identifiés par un en-tête SNAP, tel que défini ci dessous.
La présence d'un en-tête SNAP IEEE 802.la est indiquée par un en-tête LLC de valeur 0xAA-AA-03. Un en-tête SNAP est de la forme :

L'en-tête SNAP consiste en un OUI (Identificatiant unique d'organisme) de 3 octets et un PID (Identificateur de protocole) de 2 octets. L'OUI est géré par l'IEEE et identifie l'organisme qui gére les valeurs qui peuvent être assignées au PID. Ainsi l'en-tête SNAP identifie de manière univoque le protocole routé ou ponté. La valeur 0x00-00-00 de l'OUI indique que le PID est un "EtherType".
Pour les PDUs routés, non formatté NLPID, le contenu du champ "Charge utile" du PDU CPCS-AAL5 DOIT être le suivant : 

Dans le cas particulier d'un PDU IPv4 (Protocole Internet version 4), la valeur EtherType est 0x08-00 et le format de la charge utile DOIT être :

Ce format est cohérent avec ce que définit la RFC 1042 [7].

5.2 Encapsulation LLC pour protocoles pontés

Dans l'encapsulation LLC, les PDUs pontés sont encapsulés par identification du type de média ponté dans l'en-tête SNAP.  La présence de l'en-tête SNAP DOIT être indiquée par un en-tête LLC de valeur 0xAA-AA-03. La valeur OUI de l'en-tête SNAP DOIT être le code de l'organisation 802.1 : 0x00-80-C2. Le type de média ponté DOIT être indiqué par les deux octest du PID. Le PID DOIT aussi indiquer si le FCS (Vérificateur de séquence des trames) d'origine est conservé avec le PDU ponté. L'annexe B fournit une liste de valeur pour le type de média (PID) qui peuvent être utilisé dans l'encapsulation ATM.
Le champ "charge utile" d'un PDU CPCS-AAL5 transportant un PDU ponté DOIT avoir l'un des formats suivants. Le nombre d'octets de remplissage nécessaire DOIT être ajouté après le PID afin d'aligner le champ "Ethernet 802.3, données LLC", "802.4, unité de données", "802.5, info.", "Info. FDDI" ou "802.6, info." du PDU ponté sur une limite de quatre octets. L'ordre des bits de l'adresse MAC DOIT être le même que sur un LAN ou un MAN (C'est à dire de forme canonique pour les PDUs pontés Ethernet/IEEE 802.3, mais au format 802.5/FDDI pour les PDUs pontés 802.5).

Format de la charge utile des PDUs pour pontage Ethernet/802.3

La couche physique Ethernet/802.3 requière une taille minimum de trame.Un pont qui utilise le format d'encapsulation ponté Ethernet/802.3 avec le LAN-FCS DOIT inclure le remplissage. Un pont qui utilise le format d'encapsulation pour pontage Ethernet/802.3 sans conserver le LAN-FCS PEUT inclure ou non le remplissage. Quand un pont reçois une trame de ce format sans le LAN-FCS, il DOIT être capable d'insérer le remplissage nécessaire (S'il n'existe pas déjà) avant de retransmettre vers un sous-réseau Ethernet/802.3.

Format de la charge utile des PDUs pour pontage Ethernet/802.4

Format de la charge utile des PDUs pour pontage Ethernet/802.5

Du fait qu'en 802.5, le champ AC (Contrôle d'accès) n'a pas de signification hors d'un sous-réseau 802.5, il est traité par cette encapsulation comme le dernier octet du champ de 3 octets PAD. Il PEUT être initialisé à n'importe quelle valeur par le pont expéditeur et DOIT être ignoré par le pont récepteur.

Format de la charge utile des PDUs pour pontage FDDI

Format de la charge utile des PDUs pour pontage Ethernet/802.6

Dans les PDUs de pontage 802.6, la présence d'un CRC-32 est indiquée par le bit CIB dans l'en-tête de la trame MAC. Cependant la même valeur de PID est utilisée qu'il y ait présence ou absence du CRC-32 dans le PDU.
L'en-tête et la terminaison commune du PDU sont conçus pour abouter un sous-réseau 802.6 à la sortie du pont. Spécifiquement, l'en-tête commune du PDU contient le champ BAsize qui indique la longueur du PDU. Si ce champ n'est pas disponible à la sortie du pont 802.6, celui-ci ne peut pas commencer à transmettre le PDU segmenté avant de l'avoir reçu en entier, calculé sa longueur et inséré cette longueur dans le champ BAsize. Si ce champ est disponible, la sortie du pont 802.6 peut extraire la longueur du champ BAsize de l'en-tête commune du PDU, l'insérer dans le champ correspondant du premier segment et immédiatement transmettre ce segment sur le sous-réseau 802.6. Ainsi le pont peut commencer à transmettre le PDU 802.6 avant qu'il n'ait reçu le PDU en entier.
Noter que l'en-tête et la terminaison commune du PDU d'une trame encapsulée ne peuvent pas être simplement copiés vers le sous-réseau 802.6 de sortie parce que la valeur du champ BEtag encapsulé pourrait entrer en conflit avec la précédente valeur de BEtag transmise par ce pont.
Une sortie de pont 802.6 peut annuler un PDU AAL5-CPCS en mettant son champ longueur à zéro. Si la sortie du pont a déjà commençé à transmettre des segments du PDU sur un sous-réseau 802.6 et que le PDU AAL5-CPCS est annulé, elle doit immédiatement générer une cellule EOM qui provoque le rejet du PDU 802.6. Une telle cellule EOM peut, par exemple, contenir une valeur incorrecte dans le champ longueur de la terminaison commune du PDU.

Format de la charge utile pour des BPDUs

6. Multiplexage par circuit virtuel

Le multplexage par circuit virtuel crée un lien entre un circuit virtuel ATM et le type de protocole réseau porté par ce circuit virtuel. Donc il n'y a pas besoin que des informations d'identification du protocole soient transportées par la charge utile de chaque PDU AAL5-CPCS. Cela réduit leur surcharge et peut réduire les traitements. Le multiplexage par circuit virtuel peut augmenter son efficacité par réduction du nombre de cellules nécessaires pour transporter des PDUs de certaines longueurs.

6.1 Multiplexage par circuit virtuel des protocoles routés

Les PDUs de protocoles routés DOIVENT être transporté seul dans la charge utile des PDUs AAL5-CPCS. Le format des PDUs AAL5-CPCS est donc :

Format de la charge utile des PDUs routés

6.2 Multiplexage par circuit virtuel des protocoles pontés

 Les PDUs de protocoles pontés DOIVENT être transportés dans la charge utile des PDUs AAL5-CPCS exactement tel que décrit à la section 5.2, excepté que seul les champs suivants le PID DOIVENT être inclus. La charge utile du PDU AL5-CPCS transportant un PDU ponté DOIT cependant avoir l'un des formats suivants :

Format de la charge utile des PDUs pour pontage Ethernet/802.3

Format de la charge utile des PDUs pour pontage 802.4/802.5/FDDI

Notez que le champ "Contrôle d'accès" 802.5 n'a pas de signification en dehors du sous-réseau local 802.5. Il peut donc être considéré comme le dernier des trois octets du champ "PAD" qui, dasn le cas du 802.5, peut contenir n'importe quelle valeur (XX).

Format de la charge utile des PDUs pour pontage Ethernet/802.6

Format de la charge utile pour des BPDUs

Dans le cas des PDUs Ethernet 802.3, 802.4, 802.5 et FDDI, la présence ou l'absence de la terminaison "LAN-FCS" doit être implicitement identifié par le circuit virtuel du fait que le PID n'est pas inclus. Les PDUs avec terminaison "LAN-FCS" et ceux sans terminaison "LAN-FCS" sont donc considérés comme appartenant à des protocoles différents même si le type de support ponté est identique.

7. Pontage dans un réseau ATM

Un pont sur une interface ATM qui sert de lien entre un ou plusieurs autres ponts DOIT pouvoir diffuser, transmettre et filtrer les PDUs pontés.
La diffusion est réalisée par l'envoi du PDU vers toutes les destinations appropriées possibles. Dans un environement ATM, cela veut dire envoyer le PDU vers chaque circuit virtuel concerné. Cela peut être réalisé en le copiant explicitement vers chaque circuit virtuel ou en utilisant un circuit virtuel point-à-multipoint.
Pour transmettre un PDU, un pont DOIT pouvoir associer une adresse de destination MAC avec un circuit virtuel. Il n'est pas raisonnable, voire impossible, de demander aux ponts une configuration statique en associant chaque adresse de destination MAC possible à un circuit virtuel. Cependant les ponts ATM doivent fournir suffisament d'informations pour permettre à l'interface ATM d'apprendre dynamiquement les destinations situées au dela des stations ATM.
Pour réaliser cet apprentissage dynamique, un PDU ponté DOIT se conformer à l'encapsulation décrite en section 5. De cette manière l'interface de réception ATM saura chercher à l'intérieur du PDU ponté et pourra associer la destination étrangère à une station ATM.

8. Identification des réseaux virtuels privés

L'encapsulation définie dans cette section ne s'applique qu'au réseaux virtuels privés (VPN) qui opèrent sur un sous-réseau ATM.
Un mécanisme pour une identification globale unique des réseaux virtuels multiprotocoles privés est défini en [11]. Les 7 octets de l'identificateur de VPN consiste en un OUI (Identifiant unique d'organisme IEEE 802-1990) en relation avec le VPN, suivis par un index sur 4 octets qui est alloué par le propriétaire du OUI. Typiquement, la valeur du OUI en rapport avec le VPN est assignée à un fournisseur de service VPN qui alloue les valeurs d'index de VPN à ses clients.

8.1 En-tête de l'encapsulation VPN

Le format de l'en-tête de l'encapsulation VPN est le suivant :

Quand l'en-tête d'encapsulation est utilisé, le reste du PDU DOIT être structuré en accord avec le format approprié tel que décrit en section 5 ou 6. (C'est à dire que l'en-tête d'encapsulation VPN est ajoutée au début du PDU AAL5-CPCS)

8.2 PDUs routés ou pontés à encapsulation LLC dans un VPN

Quant un PDU routé ou ponté à encapsulation LLC est envoyé dans un VPN utilisant ATM sur AAL5, un en-tête d'encapsulation VPN DOIT être ajouté devant le PDU de format approprié tel que défini respectivement en section 5.1 et 5.2.

8.3 PDUs routés ou pontés à multiplexage par circuit virtuel dans un VPN

Quant un PDU routé ou ponté est envoyé dans un VPN en utilisant un multiplexage par circuit virtuel, l'identifiant de VPN peut être spécifié soit à priori, en urilisant les signaux de contrôles de la connexion ATM ou des fonctions d'administration de l'interface ATM, soit par encapsulation avec un en-tête.
Si le VPN est identifié par les signaux de contrôles ATM, tous les PDUs transporté par le circuit virtuel ATM sont associés au même VPN. Dans ce cas, le format de charge utile des PDUs routés et pontés DOIT être celui défini respectivement dans les sections 6.1 et 6.2. Lorsqu'un PDU est reçu avec un en-tête d'encapsulation VPN alors que le VPN est déjà identifié par la signalisation ATM, le receveur PEUT le rejeter et/ou effectuer d'autres actions spécifiques à l'implémentation. Les caractéristiques de la signalisation de contrôle ATM pour l'identification des VPNs transportés est hors du champ de ce mémo.
Si un identifiant de VPN est assigné par administration à une interface ATM, tous les PDUs transportés par n'importe quel circuit virtuel ATM de cette interface seront associés à ce VPN. Dans ce cas, le format de charge utile des PDUs routés et pontés DOIT être celui défini respectivement dans les sections 6.1 et 6.2. Lorsqu'un PDU est reçu avec un en-tête d'encapsulation VPN alors que le VPN est déjà identifié par une assignation administrative, le receveur PEUT le rejeter et/ou effectuer d'autres actions spécifiques à l'implémentation. Les mécanismes (Tels que les MIBs) pour l'assignation d'identifiant VPN à une interface ATM est hors du champ de ce mémo.
Si l'identifiant de VPN doit être indiqué par encapsulation d'un en-tête, cet en-tête DOIT être ajouté devant le PDU routé ou ponté au format approprié tel que défini respectivement en 6.1 et 6.2.

9. Considérations de sécurité

Ce mémo définit les mécanismes pour une encapsulation multi-protocoles sur ATM. Il y a un élément de confiance dans n'importe quel protocole d'encapsulation : un récepteur doit espérer que l'expéditeur a correctement identifié le protocole qui est encapsulé. Il n'y a aucune manière de s'assurer que l'expéditeur a employé l'identification de protocole appropriée (Cette fonctionnalité ne serait pas souhaitable). Les mécanismes d'encapsulation décrits dans ce mémo sont censés ne pas avoir d'autre propriétés qui pourraient être exploitées par un attaquant. Cependant, les architectures et les protocoles fonctionnant au-dessus de la couche d'encapsulation peuvent être sujets à une variété d'attaques. En particulier, l'architecture pontée décrite dans la section 7 a les mêmes vulnérabilités que d'autres architectures pontés. La sécurité du système peut être affectée par les propriétés du réseau ATM sous-jacent. Le forum ATM a édité un cadre de sécurité [12] et des spécifications de sécurité [13] qui peuvent être appropriés.

10. Remerciements

Ce mémo remplace la RFC 1483 qui avait été développée par le groupe de travail "IP sur ATM" et éditée par Juha Heinanen (Alors chez Telecom Finland, maintenant chez Telia). La mise à jour a été développée par le groupe de travail "IP sur NBMA" (ION) et Dan Grossman (Motorola) était l'éditeur et également contributeur au travail de la RFC 1483.
Ce travail s'inspire des RFCs citées en [1] et [4] desquelles beaucoup de choses ont étés adoptées. Merci à leurs auteurs Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello, et C. Lawrence. Autres contributeurs à ce travail : Brian Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (alors chez Network Systems), Bob Hinden (Sun Microsystems, maintenant chez Nokia), et Gary Kessler (MAN Technology).
Le sujet concernant les VPNs a été développé par Barbara Fox (Lucent) et Bernhard Petri (Siemens).

11. Références

[1]  Piscitello, D. and C. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, Mars 1991.

[2]  ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification", Août 1996.

[3]  ITU-T Recommendation I.365.1, "Frame Relaying Service Specific Convergence Sublayer (SSCS), Novembre 1993.

[4]  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.

[5]  Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755, Février 1995.

[6]  Information technology - Telecommunications and Information Exchange Between Systems, "Protocol Identification in the Network Layer".  ISO/IEC TR 9577, Octobre 1990.

[7]  Postel, J. and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, Février 1988.

[8]  Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331, Avril 1998.

[9]  ITU-T Recommendation I.555, "Frame Relay Bearer Service Interworking", Septembre 1997.

[10] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Mars 1997.

[11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, Septembre 1999.

[12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-0096.000, Février 1998.

[13] The ATM Forum, "ATM Security Specification v1.0", af-sec-0100.001, Février 1999.

12. Annexe A. - Encapsulation multiprotocoles sur FR-SSCS

La recommandation I.365.1 de l'ITU-T définie, pour l'inter-opérabilité "Relais de trame/ATM", une sous-couche de convergence spécifique aux relais de trames (FR-SSCS) à utiliser sur la partie commune de la sous-couche de convergence (CPCS) de AAL5. Le service offert par la FR-SSCS correspond au service de base des relais de trame tel que décrit dans I.233.
Un PDU FR-SSCS consiste en un champ d'adresse Q.922 suivi par un champ d'information Q.922. Le drapeau Q.922 et le FCS sont omis du fait que les fonctions correspondantes sont fournies par AAL. La figure ci-dessous montre un PDU FR-SSCS encapsulé dans la charge utile d'un PDU CPCS-AAL5.

PDU FR-SSCS dans la charge utile d'un PDU CPCS-AAL5

Les PDUs routés et pontés sont encapsulés dans le PDU FR-SSCS tel que défini dans la RFC 2427. Le champ d'information Q.922 commence par un champ de contrôle Q.922 suivi par un octet de remplissage optionnel afin d'aligner le reste de la trame sur une limite commode pour l'expéditeur. Le protocole du PDU transporté est identifié en préfixant le PDU par un identificateur de protocole de couche réseau (NLPID) ISO/IEC TR 9577.
Dans le cas particulier d'un PDU IP, le NLPID est OxCC et le PDU FR-SSCS a le format suivant :

Format des PDUs FR-SSCS pour des PDUs IP routés

Notez que selon la RFC 2427, le champ adresse Q.922 DOIT être de 2 ou 4 octets, c'est à dire qu'un champ adresse de 3 octets de DOIT PAS être utilisé.
Dans le cas particulier d'un PDU CLNP, le NLPID est 0x81 et le PDU FR-SSCS a le format suivant :

Format des PDUs FR-SSCS pour des PDUs CLNP routés

Notez que dans le cas de protocoles ISO, le champ NLPID constitue le premier octet du PDU même et ne DOIT PAS être répété.
Les encapsulations ci-dessus ne s'appliquent qu'a des protocoles routés qui ont un NLPID assigné. Pour les autres protocoles routés (ainsi que pour les protocoles pontés), il est nécessaire de fournir un autre moyen permettant l'identification aisée du protocole. Cela peut être réalisé en utilisant une valeur de 0x80 pour le NLPID, indiquant qu'un en-tête de point de raccordement de sous-réseau IEE 802.1a (SNAP) suit.
Voir la RFC 2427 pour plus de détails sur les encapsulations multiprotocoles pour FRCS.

13. Annexe B. - Liste de valeurs PID assignées à l'OUI 00-80-C2

14. Annexe C. - Liste partielle des NLPIDs
0x00 Couche de réseau nulle ou inactive (Non utilisé avec ATM)
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC IP internet

15. Annexe D. - Applications de l'encapsulation multi-protocoles

L' encapsulation multi-protocole est nécessaire, mais générallement insuffisante, pour faire du routage ou du pontage sur des réseaux ATM. Depuis la publication de la RFC 1483 (Le mémo. prédecesseur de celui-ci), plusieurs spécifications systèmes ont étés développées par l'IETF et le forum ATM en direction des différents aspects et scénarios des protocoles pontés ou routés. Cette annexe récapitule ces applications.

1) Connexion point à point entre routeurs et ponts.
L'encapsulation multi-protocoles a été utilisée sur des PVCs (Circuits virtuels permanents) ATM pour fournir un simple lien point à point entre ponts et routeurs au travers au réseau ATM. Dans ces scénarios, une certaine quantité de configurations manuelles (C'est à dire au lieu de INARP) sont nécessaires.

2) IP classique sur ATM.
La RFC 2225 (Autrefois RFC 1577) fournit un environnement où le réseau ATM sert de sous-réseau logique IP (LIS). Les PVCs ATM sont supportés, avec une résolution d'adresse fournie par INARP. Pour les SVCs (Circuits virtuels commutés), une nouvelle forme de ARP, ATMARP, fonctionne sur le réseau ATM entre un hôte (ou routeur) et un serveur ATMARP. Là où des serveurs sont répliqués pour fournir une haute disponibilité ou de meilleures performances, un protocole de cache et de synchronisation de serveur (SCSP) tel que définit dans la RFC 2335 est utilisé. IP classique sur ATM utilise par défaut l'encapsulation LLC/SNAP.

3) Emulation LAN (Réseau local).
La spécification "Emulation LAN" du forum ATM fournie un environnement où le réseau ATM est étendu par un (des) serveur(s) d'émulation LAN pour se comporter comme un LAN ponté. Les stations obtiennent et enregistrent des informations de configuration auprès d'un serveur de configuration de l'émulation LAN; elles convertissent les adresses MAC en adresses ATM à l'aide des services d'un serveur d'émulation LAN; elles peuvent envoyer des trames de diffusion ainsi que des trames adressées pour lesquelles elles n'ont pas de circuit virtuel vers un serveur de diffusion. L'émulation LAN utilise le format d'encapsulation sur circuit virtuel multiplexé pour les ponts Ethernet 802.3 (Sans LAN FCS) ou les ponts 502.5 (Sans LAN FCS). Cependant le champ PAD initial, décrit dans ce mémo, est utilisé comme en-tête LE et ne doit pas rester à zéro.

4) NHRP.
Dans certains cas le fait que IP classique sur ATM ne déserve qu'un unique LIS limite les performances. NHRP, tel que définit dans la RFC 2332, étend IP classique pour permettre des raccourcis sur un réseau ATM qui supporte plusieurs LISs.

5) Multi-protocole sur ATM (MPOA).
Les spécifications du forum ATM multi-protocole intégrent LANE et NHRP pour fournir un environnement de pontage / routage générique.

6) Multi-diffusion IP.
La RFC 2022 étend IP classique pour supporter la multi-diffusion IP. Un serveur de résolution d'adresse multiple (MARS) est utililisé, éventuellement avec un serveur de multi-diffusion, pour fournir le comportement de la multi-diffusion IP sur des connexions virtuelles ATM point à multi-point et / ou point à point.

7) PPP sur ATM.
La RFC 2364 étend le multi-protocole sur ATM au cas où le protocole encapsulé est le protocole PPP. Le multiplexage par circuits virtuels et l'encapsulation LLC/SNAP sont tous deux utilisés. Cette approche est utilisé quand le réseau ATM est utilisé comme un lien point à point et que les fonctionnalitées de PPP sont requises.

16. Annexe E. - Différences avec la RFC 1483

Cette note remplace la RFC 1483. Elle a pour buts d'enlever des anachronismes, fournir des clarifications au sujet d'ambiguïtés découvertes par des implémenteurs ou créées par des changements des standards de base, et faire avancer ce travail sur le processus de suivi des normes de l'IETF. Un certain nombre d'améliorations éditoriales ont été apportées, les conventions de la RFC 2119 [10] ont été appliquées. Les changements substantiels suivants ont été faits. Aucun d'eux ne rend obsolète les implémentations de la RFC 1483 :
* L'utilisation de l'encapsulation de NLPID est clarifiée selon les conventions de la RFC 2119.
* Une réréfence à la RFC 2364 est ajoutée pour couvrir le cas de PPP sur ATM.
* Les RFC 1755 et RFC 2331 sont référencées pour décrire comment des encapsulations sont négociées, plutôt qu'un long document obsolète du CCITT (Maintenant ITU-T) sur un travail en cours.
* L'utilisation d'AAL5 est maintenant une référence à ITU-T : I.363.5. Les options créées dans AAL5 depuis la publication de la RFC 1483 sont sélectionnées.
* Le formatage des PDUs routés au format NLPID (Qui s'appellent des "PDUs ISO routés" dans la RFC 1483) est clarifié.
* Un éclaircissement est fournie au sujet de l'utilisation du rembourrage adresse entre le PID et l'adresse MAC de destination des PDUs pontés ainsi qu'au sujet de l'ordre des bits de l'adresse MAC.
* Un éclaircissement est fournie au sujet de l'utilisation du rembourrage des trames Ethernet 802.3.
* Une nouvelle encapuslation pour les VPNs est ajoutée.
* Des considérations substantielles de sécurité ont été ajoutées.
* Une nouvelle annexe D fournit un sommaire des applications du "multi-protocoles sur ATM".

17. Adresses des auteurs.

Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland
émail: jh@telia.fi

18. Copyright intégral

Copyright © The Internet Society (1998). Tous Droits Réservés.

Le document anglais original et les traductions de celui-ci peuvent être copiés et fournis à d'autres, et les travaux dérivés qui le commente ou l'explique ou facilite son implémentation peuvent être préparés, copiés, publiés ou distribués, en totalité ou en partie, sans aucunes restrictions tant que les observations ci-dessus sur le copyright et ce paragraphe sont inclus dans tous ces types de copies ou de travaux dérivés. Cependant, le document anglais original lui-même ne peut être modifié de quelque façon que ce soit, comme par exemple en retirant les observations de copyright ou les références à la Internet Society ou aux autres organismes de l'Internet, excepté comme l'exige le but du développement des standards Internet où dans un tel cas les procédures pour les copyrights définis dans le processus des Standards Internet doivent être suivies, ou alors comme l'exige une traduction dans une langue autre que l'Anglais.

Les autorisations limitées accordées ci-dessus sont éternelles et ne pourrons être révoquées par la Internet Society, ses successeurs ou ses repreneurs.

Ce document et les informations contenues ici sont fournis de façon « TELS QUELS « et les traducteurs, la Internet Society et la Internet Engineering Task Force déclinent toute garantie, explicites ou implicites, y compris mais pas seulement toute garantie que l'utilisation des informations de ce document ne violera pas des réglementations ou des garanties implicites commerciales ou physiques pour une application particulière.