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-0E		
	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.

A

B

C

Réseau en relais de trame

50

60

80

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. Dans 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.

A

B

C

D

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.

Contrôle Q.922

UI

Trame I

0x08

0x81

0xCC

0x80

...01....

...10....

Q.933

CLNP

IP

SNAP

ISO 8208 Modulo 8

ISO 8208 Modulo 128

OUI

802.3

802.6

ID L3
Utilisateur spécifié
0x70

0x51

7776

Q.922

0x4E

0x4C

Autres

802.2

0x50

Utilisateur spécifié

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.