Groupe de travail Réseau

C. Brown, Consultant

Request for Comments : 2427

A. Malis, Ascend Communications, Inc.

STD : 55

septembre 1998

RFC rendues obsolètes : 1490, 1294

 

Catégorie : Norme

Traduction Claude Brière de L’Isle

Interconnexion multi protocole sur relais de trame

 

Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussion 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 mémoire décrit une méthode d’encapsulation pour porter le trafic d’interconnexion de réseau sur un réseau dorsal en relais de trame. Il couvre à la fois les aspects de pontage et d’acheminement.

Les systèmes qui ont la capacité de transférer à la fois la méthode d’encapsulation décrite dans le présent document et d’autres doivent avoir une connaissance a priori des circuits virtuels qui portent avec une méthode d’encapsulation et cette encapsulation ne doit être utilisée que sur les circuits virtuels qui ont été explicitement configurés pour cet usage.

 

Remerciements

Le présent document n’aurait pu être achevé sans le soutien de Terry Bradley de Avici Systems, Inc.. Des commentaires et contributions provenant de nombreuses sources, en particulier deux de Ray Samora de Proteon, Ken Rehbehn de Visual Networks, Fred Baker et Charles Carvalho de Cisco Systems, et Mostafa Sherif de AT&T ont été incorporés dans ce document. Des remerciements particuliers à Dory Leifer de l’Université du Michigan pour sa contributions à la résolution des questions de fragmentation bien qu’elle ait été supprimée de la version finale) et à Floyd Backes et Laura Bridge de 3Com pour leur contributions aux descriptions du pontage. Le présent document n’aurait pu être mené à bien sans l’expertise des groupes de travail de l’IETF de IP sur les grands réseaux publics de données et de IP sur NBMA.

 

1. Conventions et acronymes

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans [16].

Toutes les figures de ce document sont dessinées avec le bit le plus à gauche comme bit de plus fort poids pour la transmission. Par exemple, les figures peuvent être représentées sous la forme :

 

0

1

2

3

4

5

6

7 bits

 

fanion (7E hexadécimal)

 

Adresse Q.922*

 

 

 

Les dessins qui seraient trop grands pour tenir sur une page si chaque octet était présenté sur une seule ligne sont dessinés avec deux octets par ligne. Ils sont aussi dessinés avec le bit le plus à gauche comme bit de plus fort poids pour la transmission. Il y aura un "+" pour distinguer les octets comme dans l’exemple suivant.

 

--- octet un ---

octet deux

 

0

1

2

3

4

5

6

7

0

1

2

3

4

5

6

7

 

Identifiant unique

 

d’organisation

Identifiant de

 

protocole

Les acronymes suivants sont utilisés tout au long du document.
BECN (Backward Explicit Congestion Notification) : notification d’encombrement explicite vers l’arrière
BPDU (Bridge Protocol Data Unit) : unité de données de protocole de pont
C/R (Command/Response bit) : bit de commande/réponse
DCE (Data Communication Equipment) : équipement de communication de données
DE (Discard Eligibility bit) : bit de priorité de rejet
DTE (Data Terminal Equipment) : terminal de données
FECN (Forward Explicit Congestion Notification) : notification d’encombrement explicite vers l’avant
PDU (Protocol Data Unit) : unité de données de protocole
PTT (Postal Telephone & Telegraph) : Postes, téléphone et télégraphe
SNAP (Subnetwork Access Protocol) : protocole d’accès de sous-réseau

 

2. Introduction

La discussion suivante s’applique aux appareils qui servent de stations terminales (DTE) sur un réseau public ou privé de relais de trame (par exemple, fourni par un transporteur commun ou les PTT. Le présent document n’expose pas le comportement de ces stations qui sont considérées comme faisant partie du réseau à relais de trame (DCE) autrement que pour expliquer les situations dans lesquelles le DTE doit réagir.

Le réseau à relais de trame fournit un certain nombre de circuits virtuels qui forment la base des connexions entre les stations rattachées au même réseau à relais de trame. L’ensemble résultant d’appareils interconnectés forme un groupe privé de relais de trame qui peut être pleinement interconnecté avec un "mélange" complet des circuits virtuels, ou seulement partiellement interconnecté. Dans les deux cas, chaque circuit virtuel est identifié de façon univoque à chaque interface de relais de trame par un identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier). Dans la plupart des circonstances, les DLCI ont une signification strictement locale à chaque interface de relais de trame.

Les spécifications du présent document sont destinées à s’appliquer à la fois aux circuits virtuels commutés et permanents.

 

3. Format de trame

Tous les protocoles doivent encapsuler leurs paquets au sein d’une trame de l’annexe A de la Recommandation UIT-T Q.922 [1]. De plus, les trames devront contenir les informations nécessaires pour identifier le protocole porté au sein de l’unité de données de protocole (PDU), permettant ainsi que le receveur traite correctement le paquet entrant. Le format devra être le suivant :

 

fanion (7E hexadécimal)

 

Adresse Q.922*

 

 

Contrôle (UI = 0x03)

 

Bourrage (lorsque nécessaire) (0x00)

 

NLPID

 

~
~
Données
~
~

 

Séquence de vérification de trame

(deux octets)

 

 

fanion (7E hexadécimal)

*Les adresses Q.922, comme définies actuellement, sont de deux octets et contiennent un DLCI de 10 bits. Dans certains réseaux Q.922 les adresses peuvent facultativement être augmentées à trois ou quatre octets.

Le champ contrôle est le champ de contrôle de Q.922. La valeur UI (0x03) est utilisée sauf négociation contraire. L’utilisation de XID (0xAF ou 0xBF) est permise et est exposée plus loin.

Le champ bourrage (pad) est utilisé pour aligner la portion données (au-delà de l’en-tête d’encapsulation) de la trame sur une frontière de deux octets. S’il est présent, le bourrage est un seul octet et doit avoir une valeur de zéro. Des directives explicites sur le moment où utiliser le champ bourrage sont exposées plus loin dans ce document.

Le champ Identifiant de protocole de niveau réseau (NLPID, Network Level Protocol ID) est administré par l’ISO et l’UIT. Il contient des valeurs pour de nombreux protocoles différents y compris IP, CLNP, et le protocole d’accès de sous-réseau (SNAP, Subnetwork Access Protocol) [10] de l’IEEE. Ce champ dit au receveur quelle encapsulation ou quel protocole suivre. Les valeurs pour ce champ sont définies dans ISO/CEI TR 9577 [3]. Une valeur de NLPID de 0x00 est définie dans ISO/CEI TR 9577 comme couche de réseau nulle ou ensemble inactif. Comme il ne peut pas être distingué d’un champ de bourrage et comme il n’a pas de signification dans le contexte de ce schéma d’encapsulation, une valeur de NLPID de 0x00 est invalide dans l’encapsulation de relais de trame. L’appendice A contient une liste de quelque unes des valeurs de NLPID les plus utilisées.

Il n’y a pas de taille minimum maximum de trame couramment mise en œuvre pour le relais de trame. Un réseau doit, cependant, prendre au moins en charge un maximum de 262 octets. Généralement, le maximum sera supérieur ou égal à 1600 octets, mais chaque fournisseur de relais de trame spécifiera une valeur appropriée pour son réseau. Un DTE de relais de trame doit donc permettre que soit configurable la taille de trame maximum acceptable.

La taille de trame minimum permise pour le relais de trame est de cinq octets entre les fanions d’ouverture et de fermeture en supposant un champ d’adresse Q.922 de deux octets. Ce minimum passe à six octets pour une adresse Q.922 de trois octets et à sept octets pour le format d’adresse Q.922 à quatre octets.

 

4. Questions d’interconnexion

Il y a deux types de base de paquets de données qui voyagent au sein du réseau de relais de trame : les paquets acheminés et les paquets pontés. Ces paquets ont des formats distincts et doivent donc contenir un indicateur que la destination peut utiliser pour interpréter correctement le contenu de la trame. Cet indicateur est incorporé dans le NLPID et les informations d’en-tête SNAP.

Pour les protocoles qui n’ont pas encore d’allocation de NLPID, il est nécessaire de fournir un mécanisme pour permettre une identification facile du protocole. Il y a une valeur de NLPID définie qui indique la présence d’un en-tête SNAP.

Un en-tête SNAP est de la forme :

 

Identifiant unique

 

d’organisation

Identifiant de

 

protocole

L’identifiant unique d’organisation (OUI, Organizationally Unique Identifier) de trois octets identifie une organisation qui administre la signification de l’identifiant de protocole (PID, Protocol Identifier) qui suit. Ensemble, ils identifient un protocole distinct. Noter que le OUI 0x00-00-00 spécifie que le PID qui suit est un Ethertype.

4.1 Trames acheminées

Certains protocoles ont un NLPID alloué, mais parce que l’espace de numérotation NLPID est limité, tous les protocoles n’ont pas de valeurs NLPID spécifiques allouées. Lorsque des paquets de tels protocoles sont acheminés sur des réseaux en relais de trame, ils sont envoyés en utilisant le NLPID 0x80 (qui indique la présence d’un en-tête SNAP) suivi par SNAP. Si le protocole a un Ethertype alloué, le OUI est 0x00-00-00 (qui indique qu’un Ethertype suit), et le PID est l’Ethertype du protocole utilisé.

Lorsque un en-tête SNAP est présent comme décrit ci-dessus, un bourrage d’un octet est utilisé pour aligner les données de protocole sur une frontière de deux octets comme le montre la figure ci-dessous.

Format des trames acheminées avec un en-tête SNAP

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

Identifiant unique

 

d’organisation (OUI)

 

Identifiant de protocole (PID)

 

 

Données de protocole

 

 

FCS

Dans les quelques cas où un protocole a un NLPID alloué (voir l’Appendice A), 48 bits peuvent être épargnés en utilisant le format ci-dessous :

Format d’acheminement du protocole NLPID

 

Adresse Q.922

 

Contrôle 0x03

NLPID

 

 

Données de protocole

 

 

FCS

 

Lorsque on utilise le format d’encapsulation NLPID décrit ci-dessus, on n’utilise pas l’octet de bourrage.

Dans le cas des protocoles ISO, le NLPID est considéré comme étant le premier octet des données de protocole. Il n’est pas nécessaire de répéter le NLPID dans ce cas. L’octet unique sert à la fois de valeur de démultiplexage et comme partie des données de protocole (se reporter à "Autres protocoles sur relais de trame pour des précisions). D’autres protocoles, tels que IP, ont un NLPID défini (0xCC), mais il ne fait pas partie du protocole lui-même.

Format d’acheminement des datagrammes IP

 

Adresse Q.922

 

Contrôle 0x03

NLPID 0xCC

 

Datagramme IP

 

FCS

 

4.2 Trames pontées

Le second type de trafic de relais de trame est celui des paquets pontés. Ces paquets sont encapsulés en utilisant la valeur de NLPID de 0x80 qui indique SNAP. Comme avec les autres protocoles SNAP encapsulés, il y aura un octet de bourrage pour aligner la portion de données de la trame encapsulée. L’en-tête SNAP qui suit le NLPID identifie le format du paquet ponté. La valeur du OUI utilisée pour cette encapsulation est le code d’organisation 802.1 de 0x00-80-C2. La portion PID de l’en-tête SNAP (les deux octets qui suivent immédiatement le OUI) spécifie la forme de l’en-tête MAC, qui suit immédiatement l’en-tête SNAP. De plus, le PID indique si la FCS d’origine est préservée au sein de la trame pontée.

Suite au précédent de la RFC 1638 [4], les adresses de destination MAC non canoniques sont utilisées pour les trames IEEE 802.5 et FDDI encapsulées, et les adresses de destination MAC canoniques sont utilisées pour le reste des encapsulations définies dans la présente section.

L’organisation de la norme IEEE 802.1 a réservé les valeurs suivantes pour le relais de trame :

Valeurs de PID pour le OUI 0x00-80-C2

avec FCS préservé

sans FCS préservé

support

0x00-01

0x00-07

802.3/Ethernet

0x00-02

0x00-08

802.4

0x00-03

0x00-09

802.5

0x00-04

0x00-0A

FDDI

 

0x00-0B

802.6

De plus, la valeur de PID de 0x00-0E, lorsqu’elle est utilisée avec le OUI 0x00-80-C2, identifie les unités de données protocolaires de pont (BPDU, Bridge Protocol Data Unit) telles que définies par la norme IEEE 802.1(d) ou 802.1(g) [12], et la valeur de PID de 0x00-0F identifie les BPDU d’acheminement de source.

Un paquet ponté sur relais de trame a donc un des formats suivants :

Format de trame Ethernet/802.3 pontée

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

OUI 0x00

 

OUI 0x80-C2

 

PID 0x00-01 ou 0x00-07

 

 

Adresse de destination MAC

 

 

(reste de la trame MAC)

 

 

FCS de LAN (si le PID est 0x00-01)

 

FCS

Format de trame 802.4 pontée

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

OUI 0x00

 

OUI 0x80-C2

 

PID 0x00-02 ou 0x00-08

 

 

Adresse de destination MAC

 

 

(reste de la trame MAC)

 

 

FCS de LAN (si le PID est 0x00-02)

 

FCS

Format de trame 802.5 pontée

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

OUI 0x00

 

OUI 0x80-C2

 

PID 0x00-03 ou 0x00-09

 

bourrage 0x00

Contrôle de trame

 

 

Adresse de destination MAC

 

 

(reste de la trame MAC)

 

 

FCS de LAN (si le PID est 0x00-03)

 

FCS

Format de trame FDDI pontée

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

OUI 0x00

 

OUI 0x80-C2

 

PID 0x00-04 ou 0x00-0A2

 

bourrage 0x00

Contrôle de trame

 

 

Adresse de destination MAC

 

 

(reste de la trame MAC)

 

 

FCS de LAN (si le PID est 0x00-04)

 

FCS

Format de trame 802.6 pontée

 

Adresse Q.922

 

Contrôle 0x03

bourrage 0x00

 

NLPID 0x80

OUI 0x00

 

OUI 0x80-C2

 

PID 0x00-0B

 

Réservé

BEtag

En-tête de PDU commune

 

BAsize

 

 

Adresse de destination MAC

 

 

(reste de la trame MAC)

 

 

En-queue de PDU commune

 

FCS

Noter que dans les PDU 802.6 pontés, il n’y a qu’un choix pour la valeur de PID, car la présence d’un CRC-32 est indiquée par le bit CIB dans l’en-tête de la trame MAC.

L’en-tête et l’en-queue d’ unités de données de protocole communes (CPDU, Common Protocol Data Unit ) sont convoyés pour permettre le tunnelage au pont de sortie d’un sous-réseau 802.6. Précisément, l’en-tête CPDU contient le champ BAsize, qui contient la longueur du PDU. Si ce champ n’est pas disponible au pont 802.6 de sortie, le pont ne peut alors pas commencer à transmettre la PDU segmentée jusqu’à ce qu’il ait reçu la PDU entière, calculé la longueur, et inséré la longueur dans le champ BAsize. Si le champ est disponible, le pont 802.6 de sortie peut extraire la longueur du champ BAsize de l’en-tête de PDU commune, l’insérer dans le champ correspondant du premier segment, et transmettre immédiatement le segment sur le sous-réseau 802.6. Et donc, le pont peut commencer à transmettre la PDU 802.6 avant qu’il ait reçu la PDU complète.

On devrait noter que l’en-tête et l’en-queue d’ unités de données de protocole communes de la trame encapsulée ne devraient pas être simplement copiés sur le sous-réseau 802.6 sortant parce que la valeur BEtag encapsulée peut entrer en conflit avec la valeur BEtag précédente transmise par ce pont.

Format de trame BPDU

 

Adresse Q.922

 

Contrôle 0x03

 

PAD 0x00

 

NLPID 0x80

 

OUI 0x00-80-C2

 

PID 0x00-0E

 

 

BPDU comme définie par 802.1(d) ou 802.1(g)[12]

 

 

 

FCS

Format de trame BPDU d’acheminement de source

 

Adresse Q.922

 

Contrôle 0x03

 

PAD 0x00

 

NLPID 0x80

 

OUI 0x00-80-C2

 

PID 0x00-0F

 

 

BPDU d’acheminement de source

 

 

 

FCS

 

5. Négociation des paramètres de la couche de liaison des données

Les stations de relais de trame peuvent choisir de prendre en charge l’identification d’échange (XID, Exchange Identification) spécifié dans l’Appendice III de la Recommandation UIT-T Q.922 [1]. Cet échange XID permet de négocier les paramètres suivants à l’initialisation d’un circuit de relais de trame : taille maximum de trame N201, temporisation T200 de retransmission, et nombre maximum de trames K d’informations (I) en instance.

Une station peut indiquer qu’elle n’est pas d’accord pour prendre en charge le fonctionnement en trame multiple en mode acquitté en spécifiant une valeur de zéro pour la taille maximum de fenêtre, K.

Si cet échange n’est pas utilisé, ces valeurs doivent être configurées de façon statique par accord mutuel des points d’extrémité de connexion de liaison de données (DLC, Data Link Connection), ou doivent être par défaut aux valeurs spécifiées au paragraphe 5.9 de la Recommandation UIT-T Q.922 :

N201 : 260 octets
K : 3 pour une liaison à 16 kbit/s,
7 pour une liaison à 64 kbit/s,
32 pour une liaison à 384 kbit/s,
40 pour une liaison à 1,536 Mbit/s ou au-dessus
T200 : 1,5 s [voir Q.922 pour des précisions]

Si une station qui accepte XID reçoit une trame XID, elle doit répondre avec une réponse XID. En traitant une XID, si la taille maximum de trame distante est inférieure au maximum local, le système local doit réduire la taille maximum qu’il utilise sur cette DLC à la valeur spécifiée distante. Noter que ceci doit être fait avant de générer une réponse de XID.

Le diagramme suivant décrit l’utilisation de XID pour spécifier la non utilisation du fonctionnement en trame multiple en mode acquitté.

Non utilisation du fonctionnement en trame multiple en mode acquitté

 

Adresse

(2,3 ou 4 octets)

 

Contrôle 0xAF

 

 

format 0x82

 

 

ID de groupe 0x80

 

 

Longueur de groupe

(2 octets)

 

0x00-0 E

 

 

0x05

PI = Taille de trame (émission)

 

0x02

PL = 2

 

Taille maximum de trame

(2 octets)

 

0x06

PI = Taille de trame (réception)

 

0x02

PL = 2

 

Taille maximum de trame

(2 octets)

 

0x07

PI = Taille de fenêtre

 

0x01

PL = 1

 

0x00

 

 

0x09

PI = Temporisateur de retransmission

 

0x01

PL = 1

 

0x00

 

 

FCS

(2 octets)

6. Résolution d’adresse pour les PVC

Le présent document ne décrit que la résolution d’adresse appliquée aux PVC (Permanant virtual circuit, circuit virtuel permanent). Le fonctionnement en SVC (circuit virtuel commuté) sera exposé dans des documents futurs.

Il y a des situations dans lesquelles une station de relais de trame peut souhaiter résoudre de façon dynamique une adresse de protocole sur les PVC. Cela peut se faire en utilisant le protocole de résolution d’adresse (ARP, Address Resolution Protocol) [6] standard encapsulé au sein d’un paquet de relais de trame codé en SNAP comme suit :

 

Adresse Q.922

 

Contrôle (UI) 0x03

bourrage 0x00

 

NLPID 0x80

 

OUI 0x00-00-00

En-tête SNAP indiquant ARP

 

 

 

 

PID 0x0806

 

 

Paquet ARP
~
~
~

Où le paquet ARP a le format et les valeurs suivantes :

Données :
ar$hrd 16 bits Type de matériel
ar$pro 16 bits Type de protocole
ar$hln 8 bits Longueur en octets de l’adresse du matériel (n)
ar$pln 8 bits Longueur en octets de l’adresse du protocole (m)
ar$op 16 bits Code d’opération (demande ou réponse)
ar$sha noctets Adresse du matériel de source
ar$spa moctets Adresse du protocole de source
ar$tha noctets Adresse du matériel cible
ar$tpa moctets Adresse du protocole cible

ar$hrd - alloué au relais de trame est 15 en décimal (0x000F) [7].
ar$pro - voir les numéros alloués au numéro d’identifiant de protocole pour le protocole utilisant ARP. (0x0800 pour IP).
ar$hln - longueur en octets du champ d’adresse (2, 3, ou 4)
ar$pln - la longueur d’adresse de protocole dépend du protocole (ar$pro) (pour IP ar$pln est 4).
ar$op - 1 pour la demande et 2 pour la réponse.
ar$sha - adresse de matériel source Q.922, avec C/R, FECN, BECN, et DE mis à zéro.
ar$tha - adresse de matériel cible Q.922, avec C/R, FECN, BECN, et DE mis à zéro.

Parce que les DLCI au sein de la plupart des réseaux en relais de trame ont seulement une signification locale, une station d’extrémité n’aura pas de DLCI spécifique alloué en propre. Donc, une telle station n’a pas d’adresse à mettre dans la demande ou réponse ARP. Heureusement, le réseau de relais de trame fournit bien une méthode pour obtenir les DLCI corrects. La solution proposée pour le réseau en relais de trame à adressage local ci-dessous fonctionnera aussi bien pour un réseau où les DLCI ont une signification globale.

Le DLCI porté au sein de l’en-tête de relais de trame est modifié lorsque il traverse le réseau. Lorsque le paquet arrive à sa destination, le DLCI a été réglé à la valeur qui, du point de vue de la station réceptrice, correspond à la station émettrice. Par exemple, dans la figure 1 ci-dessous, si la station A devait envoyer un message à la station B, elle placerait DLCI 50 dans l’en-tête de relais de trame. Cependant, lorsque la station B recevra ce message, le DLCI aura été modifié par le réseau et apparaîtra à B comme DLCI 70.

 

Figure 1

Les lignes entre les stations représentent les connexions de liaison de données (DLC). Les numéros indiquent le DLCI local associé à chaque connexion.

Tableau de DLCI à adresse Q.922 pour la Figure 1

DLCI (décimal)

adresse Q.922 (hex)

50

0x0C21

60

0x0CC1

70

0x1061

80

0x1401

Pour une description autorisée de la corrélation entre les adresses DLCI et Q.922 [1], le lecteur est invité à consulter cette spécification. Un résumé de la corrélation est inclus ici pour plus de facilité. La traduction d’adresse DLCI en Q.922 se fonde sur une longueur d’adresse de deux octets utilisant le format de codage Q.922. Le format est :

 

8

7

6

5

4

3

2

1

 

DLCI (plus fort poids)

C/R

EA

 

DLCI (moindre poids)

FECN

BECN

DE

EA

Pour ARP et ses variantes, les bits FECN, BECN, C/R et DE sont supposés être à 0.

Lorsqu’un message ARP atteint sa destination, toutes les adresses de matériel seront invalides. L’adresse trouvée dans l’en-tête de la trame sera cependant correcte. Bien qu’elle viole effectivement la pureté de la mise en couches, le relais de trame peut utiliser d’adresse de l’en-tête comme adresse de matériel de l’envoyeur. On devrait aussi noter que l’adresse de matériel cible, aussi bien dans la demande ARP que dans la réponse, sera aussi invalide. Cela ne devrait pas causer de problèmes car ARP ne s’appuie pas sur ces champs et en fait, une mise en œuvre peut remplir de zéros ou ignorer entièrement le champ d’adresse de matériel cible.

À titre d’exemple dont ce schéma de remplacement d’adresse peut fonctionner, se référer à la figure 1. Si la station A (adresse de protocole pA) souhaite résoudre l’adresse de la station B (adresse de protocole pB), elle devrait formater une de mande ARP avec les valeurs suivantes :

demande ARP provenant de A
ar$op 1 (demande)
ar$sha inconnu
ar$spa pA
ar$tha indéfini
ar$tpa pB

Parce que la station A n’aura pas d’adresse de source associée, le champ d’adresse de matériel de source n’est pas valide. Donc, lorsque le paquet ARP est reçu, il doit extraire l’adresse correcte de l’en-tête de relais de trame et le placer dans le champ d’adresse de matériel de source. De cette façon, la demande ARP provenant de A va devenir :

Demande ARP provenant de A telle que modifiée par B
ar$op 1 (demande)
ar$sha 0x1061 (DLCI 70) provenant de l’en-tête de relais de trame
ar$spa pA
ar$tha indéfini
ar$tpa pB

L’ARP de la station B sera alors capable de mémoriser correctement l’association de l’adresse de protocole de la station A et l’adresse Q.922. Ensuite, la station B va former un message de réponse. De nombreuses mises en œuvre placent simplement les adresses de source provenant de la demande ARP dans les adresses cibles puis remplissent ensuite les adresses de source avec ces adresses. Dans ce cas, la réponse ARP serait :

Réponse ARP provenant de B
ar$op 2 (réponse)
ar$sha inconnu
ar$spa pB
ar$tha 0x1061 (DLCI 70)
ar$tpa pA

Cette fois encore, l’adresse de matériel de source est inconnue et lorsque la réponse est reçue, la station A va extraire l’adresse de l’en-tête de relais de trame et la placer dans le champ d’adresse de matériel de source. Donc, la réponse va devenir :

Réponse ARP provenant de B telle que modifiée par A
ar$op (réponse)
ar$sha x0C21 (DLCI 50)
ar$spa B
ar$tha x1061 (DLCI 70)
ar$tpa A

La station A va maintenant reconnaître correctement la station B comme ayant l’adresse de protocole pB associée à l’adresse Q.922 0x0C21 (DLCI 50).

L’ARP inverse (RARP) [8] fonctionne exactement de la même façon. Toujours en utilisant la figure 1, si nous supposons que la station C est un serveur d’adresse, les échanges RARP suivant vont avoir lieu :

Demande RARP de A

Demande RARP telle que modifiée par C

ar$op : 3 (demande RARP)

ar$op : 3 (demande RARP)

ar$sha : inconnu

ar$sha : 0x1401 (DLCI 80)

ar$spa : indéfini

ar$spa ; indéfini

ar$tha : 0x0CC1 (DLCI 60)

ar$tha : 0x0CC1 (DLCI 60)

ar$tpa ; pC

ar$tpa : pC

La station C va alors rechercher l’adresse de protocole correspondant à l’adresse Q.922 0x1401 (DLCI 80) et envoyer la réponse RARP.

Réponse RARP de C

Réponse RARP telle que modifiée par A

ar$op : 4 (réponse RARP)

ar$op : 4 (réponse RARP)

ar$sha : inconnu

ar$sha : 0x0CC1 (DLCI 60)

ar$spa : pC

ar$spa : pC

ar$tha : 0x1401 (DLCI 80)

ar$tha : 0x1401 (DLCI 80)

ar$tpa : pA

ar$tpa : pA

Cela signifie que l’interface de relais de trame ne doit intervenir que dans le traitement des paquets entrants.

En l’absence de diffusion groupée convenable, ARP peut encore être mis en œuvre. Pour ce faire, la station d’extrémité envoie simplement une copie de la demande ARP à travers chaque DLC pertinent, simulant ainsi une diffusion.

L’utilisation d’adresses de diffusion groupée dans un environnement de relais de trame, comme spécifié par [19], est actuellement examiné par les fournisseurs de relais de trame. À l’avenir, l’adressage en diffusion groupée peut devenir utile pour l’envoi des demandes ARP et des autres messages de "diffusion".

À cause de l’inefficacité des émulations de diffusion dans un environnement de relais de trame, une nouvelle variante de résolution d’adresse a été développée. On l’appelle ARP inverse [11] et il décrit une méthode de résolution d’adresse de protocole lorsque l’adresse de matériel est déjà connue. Dans le cas du relais de trame, l’adresse de matériel connue est le DLCI. La prise en charge de l’ARP inverse n’est pas exigée pour mettre en œuvre la présente spécification, mais elle s’est révélée utile pour l’auto configuration de l’interface de relais de trame. Voir sa description en [11] ainsi qu’un exemple de son utilisation avec le relais de trame.

Les stations doivent être capables de transpose plus d’une adresse IP dans le même sous-réseau IP (préfixe d’adresse CIDR) en un DLCI particulier sur une interface de relais de trame. Cette exigence vient d’applications telles que l’accès distant, où les serveurs doivent agir comme mandataires ARP pour de nombreux clients à accès commuté, chacun ayant une adresse IP unique allouée tout en partageant la bande passante sur le même DLC. La nature dynamique de telles applications résulte en changements fréquents d’association d’adresses sans affecter l’état du DLC, ce qui est rapporté par la signalisation d’état PVC de relais de trame.

Comme avec toute autre interface qui utilise ARP, les stations peuvent apprendre les associations entre les adresses IP et les DLCI en traitant les demandes ARP non sollicitées ("gratuites") qui arrivent sur le DLC. Si une station (peut-être un serveur de terminal ou un serveur d’accès distant) souhaite informer les stations homologues à l’autre extrémité d’un DLC en relais de trame d’une nouvelle association entre une adresse IP et ce PVC, elle devrait envoyer une demande ARP non sollicitée avec l’adresse IP de source égale à l’adresse IP de destination, et toutes deux réglées à la nouvelle adresse IP qui est utilisée sur le DLC. Cela permet à une station d’"annoncer" de nouvelles connexions client sur un DLCI particulier. La station réceptrice doit mémoriser la nouvelle association, et retirer toute ancienne association existante, si nécessaire, provenant de tout autre DLCI sur l’interface.

 

7. IP sur relais de trame

Les datagrammes du protocole Internet [9] (IP) envoyés sur un réseau en relais de trame se conforment à l’encapsulation décrite ci-dessus. Dans ce contexte, IP peut être encapsulé de deux façons différentes.

 

1. Valeur de NLPID indiquant IP

Adresse Q.922

Contrôle (UI) 0x03

NLPID 0xCC

Paquet IP
~
~

 

2. Valeur de NLPID indiquant SNAP

Adresse Q.922

 

Contrôle (UI) 0x03

bourrage 0x00

 

NLPID 0x80

OUI = 0x00-00-00

En-tête SNAP

 

indiquant IP

PID 0x0800

 

Paquet IP
~
~

 

Bien que ces deux encapsulations soient prises en charge sous les définitions données, il est avantageux de choisir une seule méthode comme le mécanisme approprié pour encapsuler les données IP. Donc les données IP doivent être encapsulées en utilisant la valeur de NLPID de 0xCC qui indique IP comme le montre l’option 1 ci-dessus. Ceci (l’option 1) est plus efficace en transmission (48 bits de moins) et est cohérent avec l’encapsulation de IP en X.25.

 

8. Autres protocoles sur relais de trame

Comme avec l’encapsulation IP, il y a des moyens de remplacement pour transmettre divers protocoles dans le cadre de cette définition. Pour éliminer les conflits, l’encapsulation SNAP est seule utilisée si aucune valeur de NLPID n’est définie pour le protocole en question.

Comme exemple de la façon dont cela fonctionne, le CLNP de l’ISO a un NLPID défini de (0x81). Donc, le champ NLPID va indique le CLNP ISO et le paquet de données va immédiatement suivre. La trame serait la suivante :

Adresse Q.922

Contrôle (UI) 0x03

NLPID 0x81 (CLNP)

reste du paquet CLNP

~

~

Dans cet exemple, le NLPID est utilisé pour identifier le paquet de données comme CLNP. Il est aussi considéré comme faisant partie du paquet CLNP, et comme tel, le NLPID ne devrait pas être retiré avant l’envoi pour traitement aux couches supérieures. Le NLPID n’est pas dupliqué.

D’autres protocoles, tels que IPX, n’ont pas de valeur définie de NLPID. Comme mentionné ci-dessus, IPX serait encapsulé en utilisant l’en-tête SNAP. Da ns ce cas, la trame serait la suivante :

Adresse Q.922

Contrôle (UI) 0x03

bourrage 0x00

NLPID 0x80 (SNAP)

OUI - 0x00 00 00

 

PID 0x8137

paquet IPX

 

9. Modèle de pontage pour relais de trame

Le modèle de pontage d’un réseau en relais de trame est identique au modèle de pontage à distance décrit dans le standard IEEE P802.1g "Pontage MAC distant" [13] et prend en charge le concept de "accès virtuels". Les ponts distants avec des accès de LAN reçoivent et émettent des trames MAC de et vers les LAN auxquels il sont rattachés. Ils peuvent aussi recevoir et transmettre des trames MAC à travers des accès virtuels de et vers d’autres ponts distants. Un accès virtuel peut représenter un point d’accès abstrait de pont distant vers un , deux ou plus autres ponts distants.

Les ponts distants sont configurés de façon statique comme membres d’un groupe de pont distant par la gestion. Tous les membres d’un groupe de pont distant sont connectés par un ou plusieurs accès virtuels. L’ensemble des pont MAC distants dans un groupe de pont distant donne l’interconnexion réelle ou *potentielle* de couche MAC entre un ensemble de LAN et d’autres groupes de pont distant que rattachent les ponts distants.

Dans un réseau en relais de trame, il doit y avoir un maillage complet de circuits virtuels en relais de trame entre les ponts d’un groupe de pont distant. Si le réseau en relais de trame n’est pas un maillage complet, le réseau ponté doit alors être divisé en plusieurs groupes de ponts distants.

Les circuits virtuels en relais de trame qui interconnectent les ponts d’un groupe de ponts distants peuvent être combinés ou utilisés individuellement pour former un ou plusieurs accès de pont virtuel. Cela donne de la souplesse au traitement de l’interface de relais de trame soit comme un seul accès de pont virtuel, avec tous les circuits virtuels dans un groupe, soit comme une collection d’accès de ponts ( circuits virtuels individuels ou groupés).

Lorsque un seul accès de pont virtuel fournit l’interconnectivité pour tous les ponts d’un groupe de pont distant donné (c’est-à-dire que tous les circuits virtuels sont combinés en un seul accès virtuel), l’algorithme standard d’arbre d’expansion peut être utilisé pour déterminer l’état de l’accès virtuel. Lorsque plus d’un accès virtuel est configuré au sein d’un groupe de pont distant donné, un algorithme d’arbre d’expansion "étendu" est alors nécessaire. Un tel algorithme étendu est défini dans la norme IEEE 802.1g [13]. Le fonctionnement de cet algorithme est tel qu’un accès virtuel n’est mis en sauvegarde que si il y a une boucle dans le réseau externe au groupe de pont distant.

La plus simple configuration de pont pour un réseau en relais de trame est celle de LAN où tous les circuits virtuels sont combinés en un seul accès virtuel. Les trames, telles que les BPDU, qui seraient en diffusion sur un LAN, doivent être écoulées sur chaque circuit virtuel (ou en diffusion groupée si le service est développé pour les services de relais de trame). L’écoulement est réalisé en envoyant le paquet à chaque DLC pertinent associé à l’interface de relais de trame. Dans cet environnement, les circuits virtuels sont généralement invisibles pour le pont. C’est-à-dire que le pont envoie une trame moyée dans l’interface de relais de trame et ne "voit" pas que cette trame est transmise individuellement à chaque circuit virtuel. Si tous les ponts participants sont pleinement connectés (maillage complet) l’algorithme standard d’arbre d’expansion suffira dans cette configuration.

Normalement les ponts de LAN apprennent sur quelle interface une station d’extrémité particulière peut être atteinte en associant une adresse MAC à un accès de pont. Dans un réseau en relais de trame configuré pour l’accès de pont unique de type LAN (ou tout ensemble de circuits virtuels groupés pour former un seul accès de pont), cependant, le pont ne doit pas seulement associer une adresse MAC à un accès de pont, mais aussi l’associer à un identifiant de connexion. Pour les réseaux en relais de trame, cet identifiant de connexion est un DLCI. Il serait déraisonnable et peut-être impossible d’exiger des ponts qu’ils configurent de façon statique une association de toutes les adresses MAC de destination possibles avec un DLC. Donc, les ponts en relais de trame modélisés comme des LAN doivent fournir un mécanisme permettant à l’accès de pont en relais de trame d’apprendre les associations de façon dynamique. Pour réaliser cet apprentissage dynamique, un paquet ponté doit se conformer à l’encapsulation décrite au paragraphe 4.2. De cette façon, l’interface de relais de trame receveuse saura chercher dans le paquet ponté pour rassembler les informations appropriées.

Une seconde approche du pontage en relais de trame, en point à point, traite chaque circuit virtuel en relais de trame comme un accès de pont distinct. L’écoulement et la transmission des paquets sont significativement moins compliqués en utilisant l’approche point à point parce que chaque accès de pont a seulement une destination. Il n’est pas besoin d’effectuer un écoulement artificiel ou d’associer les DLCI aux adresses MAC de destination. Selon l’interconnexion des circuits virtuels, un algorithme d’arbre d’expansion étendu peut être nécessaire pour permettre que tous les accès virtuels restent actifs tant qu’il n’y a pas de vraie boucles dans la topologie externe au groupe de pont distant.

Il est aussi possible de combiner les vues de LAN et de point à point sur une seule interface de relais de trame. Pour ce faire, certains circuits virtuels sont combinés de façon à former un seul accès de pont virtuel alors que d’autres circuits virtuels sont des accès de pont indépendants.

Le dessin suivant illustre les différentes configurations de pont possibles. Les lignes en pointillé entre les boîtes représentent les circuits virtuels.

Comme il y a moins qu’un maillage complet de circuits virtuels entre les ponts dans cet exemple, le réseau doit être divisé en plus d’un groupe de pont distant. Une configuration raisonnable est d’avoir les ponts A, B, et C dans un groupe, de d’avoir les ponts A et D dans un second groupe.

La configuration du premier groupe de ponts combine l’interconnexion des circuits virtuels des trois ponts (A, B, et C) en un seul accès virtuel. C’est un exemple de la configuration de type LAN. Le second groupe serait aussi un seul accès virtuel qui connecte simplement les ponts A et D. Dans cette configuration l’algorithme standard d’arbre d’expansion est suffisant pour détecter les boucles.

Un autre configuration de remplacement a trois accès virtuels individuels dans le premier groupe correspondant aux circuits virtuels interconnectant les ponts A, B et C. Comme l’application de l’algorithme standard d’arbre d’expansion à cette configuration détecterait une boucle dans la topologie, un algorithme d’arbre d’expansion étendu devrait être utilisé afin que tous les accès virtuels soient gardés actifs. Noter que le second groupe consisterait encore en un seul accès virtuel et que l’algorithme standard d’arbre d’expansion pourrait être utilisé dans ce groupe.0

En utilisant le même dessin, on pourrait construire un scénario de pont distant avec trois groupes de ponts. Cela serait un exemple du cas point à point. Ici, le circuit virtuel connectant A et B, le circuit virtuel qui connecte A et C, et celui qui connecte A et D sont tous des groupes de ponts avec un seul accès virtuel.

 

10. Considérations pour la sécurité

Le présent document définit des mécanismes pour identifier l’encapsulation multi protocoles de datagrammes en relais de trame. Il y a évidemment un élément de confiance dans tout protocole d’encapsulation - un receveur doit faire confiance à l’envoyeur sur le fait qu’il a correctement identifié le protocole encapsulé. En général, il n’y a aucun moyen pour un receveur d’essayer d’avoir la certitude que l’envoyeur a bien utilisé l’identification de protocole appropriée ni que c’est bien la fonctionnalité souhaitée.

Il spécifie aussi l’utilisation de ARP et RARP avec le relais de trame, et est soumis aux mêmes contraintes de sécurité que celles qui affectent ARP et les protocoles de résolution d’adresse similaires. Parce que l’authentification ne fait pas partie d’ARP, il y a des problèmes de sécurité connus relatifs à son utilisation (par exemple, usurpation d’identité de l’hôte). Aucun mécanismes de sécurité supplémentaire n’a été ajouté à ARP ou à RARP pour être utilisé avec les réseaux en relais de trame.

11. Appendice A – Les NLPID et les PID

Liste des NLPID couramment utilisés.

0x00

Couche réseau nulle ou ensemble inactif (non utilisé avec le relais de trame)

0x08

Q.933 [2]

0x80

SNAP

0x81

ISO CLNP

0x82

ISO ESIS

0x83

ISO ISIS

0x8E

IPv6

0xB0

Compression de données FRF.9 [14]

0xB1

Fragmentation FRF.12 [18]

0xCC

IPv4

0xCF

PPP en relais de trame [17]

 

Liste des PID de OUI 00-80-C2

avec FCS préservé

sans FCS préservé

Support

0x00-01

0x00-07

802.3/Ethernet

0x00-02

0x00-08

802.4

0x00-03

0x00-09

802.5

0x00-04

0x00-0A

FDDI

 

0x00-0B

802.6

 

0x00-0D

Fragments

 

0x00-0E

BPDU comme définis par 802.1(d) ou 802.1(g)[12].

 

0x00-0F

BPDU d’acheminement de source

 

12. Appendice B – Procédures orientées connexion

Le présent Appendice contient des informations et instructions supplémentaires pour utiliser la Recommandation UIT-T Q.933 [2] et les autres normes de l’UIT pour l’encapsulation de données en relais de trame. Les informations contenues ici sont similaires (et dans certains cas identiques) à celles qui se trouvent dans l’Annexe E de la Recommandation UIT-T Q.933. La source qui fait autorité pour ces informations est cette Annexe E et elle ne sont répétées ici que titre de facilité pour le lecteur.

Le champ Identifiant de protocole de niveau réseau (NLPID, Network Level Protocol ID) est administré par l’ISO et l’UIT. Il contient des valeurs pour de nombreux protocoles différents , y compris IP, CLNP (ISO 8473), UIT-T Q.933, et ISO 8208. Une figure résumant la technique générique d’encapsulation sur les réseaux en relais de trame est donnée ci-dessous. La souplesse du schéma consiste en l’identification de plusieurs alternatives pour identifier les différents protocoles utilisés par des systèmes de bout en bout, - bride et routeurs de LAN à LAN, ou une combinaison des deux sur des réseaux en relais de trame.

Pour les protocoles qui n’ont pas de NLPID alloué ou qui n’ont pas d’encapsulation SNAP, on devrait utiliser la valeur de NLPID de 0x08, qui indique la Recommandation UIT-T Q.933. Les quatre octets qui suivent le NLPID incluent à la fois l’identification de protocole de couche 2 et de couche 3. Les codets pour la plupart des protocoles sont actuellement définis dans la Recommandation UIT-T Q.933 Élément d’information de compatibilité de couche basse. Les codets pour "Utilisateur spécifié" sont décrits dans FRF.3.1 [15] du Forum de relais de trame. Il y a aussi une solution de secours pour définir les protocoles non standard.

 

Format des autres protocoles qui utilisent le NLPID de Q.933

 

Adresse Q.922

 

Contrôle 0x03

NLPID 0x80

 

ID de protocole de couche 2

 

octet 1

octet2

 

ID de protocole de couche 3

 

octet 1

octet2

 

Données de protocole

 

FCS

ISO 8802/2 avec couche 3 d'utilisateur spécifié

 

Adresse Q.922

 

Contrôle 0x03

NLPID 0x80

 

802/2 0x4C

0x80

 

Utilisateur spécifié 0x70

Note 1

 

DSAP

SSAP

 

Contrôle (Note 2)

 

Reste de la PDU

 

FCS

Note 1 : Indique le codet pour le protocole de couche 3 d’utilisateur spécifié.

Note 2 : Le champ contrôle est de deux octets pour les trames de format I et de format S (voir 88002/2)

Encapsulations utilisant une trame I (couche 2)

La trame I de la Recommandation UIT-T Q.922 I sert à la prise en charge des protocoles de couche 3 qui exigent un accusé de réception de la couche de liaison des données (par exemple, ISO 8208). Le bit C/R sera utilisé pour les indications de commande et de réponse.

Format of ISO 8208 frame Modulo 8

 

Adresse Q.922

 

....Trame

de contrôle I

 

Paquet 8208 (modulo 8) Note 3

 

FCS

Note 3 : Le premier octet du paquet 8208 identifie aussi le NLPID qui est "..01....".

Format of ISO 8208 frame Modulo 128

 

Adresse Q.922

 

....Trame

de contrôle I

 

Paquet 8208 (modulo 128) Note 4

 

FCS

Note 4 : Le premier octet du paquet 8208 identifie aussi le NLPID qui est "..10....".

 

13. Appendice C - Modifications depuis la RFC 1490

La RFC 1490 a été largement mise en œuvre et utilisée, et a été adoptée par le Forum relais de trame dans FRF.3.1 [15] et par l’UIT-T dans la Recommandation Q.933 [2]. La présente section décrit les mises à jour de la RFC 1490 qui ont été faites par suite de cette mise en œuvre et de l’expérience d’interopérabilité, et qui reflètent les pratiques courantes de la mise en œuvre.

Certains changements de langage ont été nécessaires pour préciser la RFC 1490. Aucun de des changements n’a d’impact sur les aspects techniques du présent document, mais étaient exigés pour conserver la cohérence et la spécificité des diagrammes et du langage. Les particularités de ces changements ne sont pas énumérées ici. Ci-dessous figure la liste des changements significatifs.

a) L’exigence que les stations acceptent les protocoles SNAP encapsulés pour lesquels un NLPID est disponible, a été supprimée. La RFC 1490 indiquait que, si un protocole, tel que IP, a une valeur de NLPID désignée, elle doit être utilisée. Plus loin, le document exigeait que stations acceptent une version SNAP encapsulée du même protocole. Ceci est clairement incohérent. Une station conforme doit envoyer et accepter la version encapsulée du NLPID d’un tel protocole. Elle PEUT accepter l’encapsulation SNAP mais ne devrait pas être obligée de le faire si ces trames ne sont pas conformes.

b) La fragmentation a été retirée. Aujourd’hui, il n’y a pas de mises en œuvre interopérables de l’algorithme de fragmentation présenté dans la RFC 1490. De plus, il a été suggéré à plusieurs reprises que les mécanismes proposés étaient insuffisants pour certaines applications de relais de trame. À cette fin, la fragmentation a été retirée de ce document, et a été remplacée par la fragmentation spécifiée dans FRF.12 [18].

c) La résolution d’adresse présentée dans la RFC 1490 se référait seulement aux environnements de PVC et elle est insuffisante pour les environnements SVC. Donc le titre de la section a été changé pour le refléter. Des travaux ultérieurs sur la résolution d’adresse en SVC seront menés par le groupe de travail ION.

d) L’encapsulation pour les BPDU d’acheminement de source ont été ajoutés, et les listes de l’Appendice A ont été augmentées.

e) L’utilisation d’adresses de destination MAC canoniques et non canoniques dans les encapsulations de pontage a été précisée.

f) La description de l’ARP inverse a été déplacée dans la spécification de l’ARP inverse [11].

g) Une nouvelle section sur la sécurité a été ajoutée.

 

14. Références

[1] Union Internationale des Télécommunications "Spécification de la couche de liaison des données RNIS pour les services support en mode trame", Recommandation UIT-T Q.922, 1992.

[2] Union Internationale des Télécommunications, "Spécifications de signalisation pour la surveillance d’état et le contrôle de connexion virtuelle permanente et commutée en mode trame", Recommandation UIT-T Q.933, 1995.

[3] Technologies de l’information – Échanges de télécommunications et d’informations entre systèmes - Identification de protocole dans la couche Réseau, ISO/CEI TR 9577: 1992.

[4] F. Baker et R. Bowen, "Protocole de contrôle de pontage PPP (BCP)", RFC 1638, juin 1994.

[5] Norme internationale, Système de traitement de l’information – Réseaux de zone locale – Contrôle de liaison logique, ISO 8802-2, ANSI/IEEE, deuxième édition, 30 décembre 1994.

[6] D. Plummer, "Protocole de résolution d’adresse Ethernet - ou – Conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur matériel Ethernet", STD 37, RFC 826, novembre 1982.

[7] J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1700, octobre 1994. Voir aussi : http://www.iana.org/numbers.html

[8] R. Finlayson, R. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d’adresse", STD 38, RFC 903, juin 1984.

[9] J. Postel et J. Reynolds, "Norme pour la transmission de datagrammes IP sur les réseaux IEEE 802", RFC 1042, février 1988.

[10] IEEE, "Norme IEEE pour les réseaux de zone locale et métropolitaine : Généralités et architecture", IEEE Standard 802-1990.

[11] T. Bradley, C. Brown et A. Malis, "Protocole de résolution inverse d’adresse", RFC 2390, septembre 1998.

[12] IEEE, "Norme IEEE pour les réseaux de zone locale et métropolitaine : Ponts de commande d’accès au support (MAC)", IEEE Standard 802.1D-1990.

[13] ISO/CEI 15802-5 : 1998 (Norme IEEE 802.1G), Pontage de commande d’accès au support à distance, 12 mars 1997.

[14] Frame Relay Forum, "Compression de données sur accord de mise en œuvre de relais de trame", FRF.9, 22 janvier 1996.

[15] Frame Relay Forum, "Accord de mise en œuvre d’encapsulation multi protocole", FRF.3.1, 22 juin 1995.

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

[17] W. Simpson, "PPP en relais de trame", RFC 1973, juin 1996.

[18] Frame Relay Forum, "Accord de mise en œuvre de fragmentation de relais de trame", FRF.12, décembre 1997.

[19] Frame Relay Forum, "Accord de mise en œuvre de service et de protocole de diffusion groupée de PVC en relais de trame", FRF.7, 21 octobre 1994.

 

15. Adresse des auteurs

Caralyn Brown

Andrew Malis

Consultant

Ascend Communications, Inc.

mél : cbrown@juno.com

1 Robbins Road

 

Westford, MA 01886

 

téléphone : (978) 952-7414

 

mél : malis@ascend.com

 

16. 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 copyright ci-dessus et ce paragraphe soit 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 copyrights définis dans les processus de normes pour 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ÉCLINE 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 A UN OBJET PARTICULIER.