Groupe de travail Réseau	R. Aggarwal, éd., Juniper Networks	
Request for Comments : 4719	M. Townsley, éd.	
Catégorie : Sur la voie de la normalisation	M. Dos Santos, éd., Cisco Systems	
Traduction Claude Brière de L'Isle	novembre 2006	

Transport de trames Ethernet sur la version 3 du protocole de tunnelage de couche 2 (L2TPv3)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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 (2006). Tous droits réservés.

Résumé
Le présent document décrit le transport de trames Ethernet sur la version 3 du protocole de tunnelage de couche 2 (L2TPv3, Layer 2 Tunneling Protocol, Version 3). Cela inclut le transport de trames Ethernet d'accès à accès ainsi que le transport de trames de VLAN Ethernet. Le mécanisme décrit dans le présent document peut être utilisé à la création de pseudo filaires pour le transport des trames Ethernet sur un réseau IP.
Table des matières
1. Introduction	1
1.1 Spécification des exigences	2
1.2 Abréviations	2
1.3 Types de message de contrôle L2TPv3	2
1.4 Exigences	2
2. Établissement de pseudo filaire	3
2.1 Établissement de connexion de contrôle CCE-LCCE	3
2.2 Établissement de session PW	3
2.3 Surveillance de session de pseudo filaire	4
3. Traitement de paquet	4
3.1. Encapsulation	4
3.2 Séquençage	5
3.3 Traitement de la MTU	5
4. Déclaration d'applicabilité	5
5. Contrôle d'encombrement	6
6. Considérations sur la sécurité	6
7. Considérations relatives à l'IANA	6
8. Contributeurs	7
9. Remerciements	7
10. Références	7
10.1 Références normatives	7
10.2 Références pour information	7
Adresse des auteurs	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction

La version 3 du protocole de tunnelage de couche 2 (L2TPv3, Layer 2 Tunneling Protocol, Version 3) peut être utilisée comme protocole de contrôle et pour l'encapsulation de données pour établir des pseudo filaires (PW, Pseudowire) pour transporter des unités de données de paquets de couche 2 à travers un réseau IP [RFC3931]. Le présent document décrit le transport de trames Ethernet sur L2TPv3 incluant l'établissement de PW et l'encapsulation de données.

Le terme "Ethernet" dans le présent document est utilisé dans l'intention d'inclure tous les protocoles de ce genre qui sont raisonnablement similaires dans leur format de paquet à IEEE 802.3 [802.3], incluant les variantes ou extensions qui peuvent ou non nécessairement être sanctionnées par l'IEEE (incluant des trames comme les jumbo trames, etc.). Le terme "VLAN" dans le présent document est utilisé dans l'intention d'inclure tous les protocole d'étiquetage de LANl virtuel comme [802.1Q], [802.1ad], etc.

 	1.1	Spécification des exigences
Dans le présent document, plusieurs mots sont utilisés pour signifier les exigences de la spécification. Ces mots sont souvent en majuscules. Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119]

 	1.2	Abréviations
AC (Attachment Circuit) circuit de rattachement (voir la [RFC3985])
CE  (Customer Edge) côté consommateur (normalement aussi le système L2TPv3 distant)
LCCE (L2TP Control Connection Endpoint) point d'extrémité de connexion de contrôle L2TP (voir la [RFC3931])
NSP (Native Service Processing) traitement de service natif (voir la [RFC3985])
PE (Provider Edge) côté fournisseur (normalement aussi le LCCE) (voir la [RFC3985])
PSN (Packet Switched Network) réseau à commutation de paquets (voir la [RFC3985])
PW (Pseudowire) pseudo filaire (voir la [RFC3985])
PWE3 (Pseudowire Emulation Edge to Edge Working Group) groupe de travail Émulation de pseudo filaire de bord à bord

 	1.3	Types de message de contrôle L2TPv3
Les types de message de contrôle L2TPv3 pertinents (voir la [RFC3931]) sont mentionnés pour référence.
SCCRQ (Start-Control-Connection-Request) Demande de début de connexion de contrôle
SCCRP (Start-Control-Connection-Reply) Réponse de début de connexion de contrôle
SCCCN (Start-Control-Connection-Connected) Début de connexion de contrôle connectée
StopCCN (Stop-Control-Connection-Notification) Notification d'arrêt de connexion de contrôle
ICRQ (Incoming-Call-Request) Demande d'appel entrant
ICRP (Incoming-Call-Reply) Réponse d'appel entrant
ICCN (Incoming-Call-Connected) Appel entrant connecté
OCRQ (Outgoing-Call-Request) Demande d'appel sortant
OCRP (Outgoing-Call-Reply) Réponse d'appel sortant
OCCN (Outgoing-Call-Connected) Appel sortant connecté
CDN (Call-Disconnect-Notify) Notification d'appel déconnecté
SLI (Set-Link-Info) Informations d'établissement de liaison

 	1.4	Exigences
Un PW Ethernet émule une seule liaison Ethernet entre exactement deux points d'extrémité. La figure qui suit décrit la terminaison de PW par rapport au NSP et au tunnel PSN au sein d'un LCCE [RFC3985]. L'interface Ethernet peut être connectée à un ou plusieurs systèmes distants (un système distant L2TPv3 est appelé un côté consommateur (CE, Customer Edge) dans ce document et les documents PWE3 associés). Le LCCE peut ou non être un PE.

                 +---------------------------------------+
                 |                 LCCE                  |
                 +-+   +-----+   +------+   +------+   +-+
                 |P|   |     |   |Termin|   |Tunnel|   |P|
   Interface <==>|h|<=>| NSP |<=>|aison |<=>| PSN  |<=>|h|<==> PSN
    Ethernet     |y|   |     |   |de PW |   |      |   |y|
                 +-+   +-----+   +------+   +------+   +-+
                 |                                       |
                 +---------------------------------------+
Figure 1 : termination de pseudo filaire

Le point de terminaison de PW reçoit des trames Ethernet non étiquetées (aussi appelées "brutes") ou étiquetées et les livre sans altération au point de terminaison de PW sur le LCCE distant. Donc, il peut fournir un service d'émulation de liaison Ethernet étiqueté ou non étiqueté.

La fonction "NSP" inclut le traitement de paquet nécessaire pour traduire les trames Ethernet qui arrivent à l'interface CE-LCCE de/vers les trames Ethernet qui sont appliquées au point de terminaison de PW. Ces fonctions peuvent inclure de supprimer, écraser, ou ajouter des étiquettes de VLAN. La fonction de NSP peut être utilisée en conjonction avec le provisionnement local pour fournir de services hétérogènes où les encapsulations CE-LCCE au deux extrémités peuvent être différentes.

La couche physique entre CE et LCCE, et toutes les fonctions d'adaptation (NSP) entre elle et la terminaisonde PW, sortent du domaine d'application de PWE3 et ne sont pas définies ici.

 	2.	Établissement de pseudo filaire

Avec L2TPv3 comme protocole de tunnelage, les PW Ethernet sont des sessions L2TPv3. Une connexion de contrôle L2TP doit être établie d'abord entre les deux LCCE. Des PW individuels peuvent alors être établis comme des sessions L2TP.

 	2.1	Établissement de connexion de contrôle CCE-LCCE
Les deux LCCE qui souhaitent établir des PW Ethernet DOIVENT établir d'abord une connexion de contrôle L2TP comme décrit dans la [RFC3931]. Donc, un type de PW Ethernet doit être inclus dans la liste de capacités de pseudo filaire comme défini dans la [RFC3931]. Le type de PW peut être"Accès Ethernet" ou "VLAN Ethernet". Cela indique que la connexion de contrôle peut prendre en charge l'établissement des PW Ethernet. Noter qu'il y a deux types de PW Ethernet requis. Pour connecter un accès Ethernet à un autre accès Ethernet, le type de PW DOIT être "Accès Ethernet" ; pour connecter un VLAN Ethernet à un autre VLAN Ethernet, le type de PW DOIT être "VLAN Ethernet".

 	2.2	Établissement de session PW
Le provisionnement d'un accès Ethernet ou d'un VLAN Ethernet et son association à un PW déclenche l'établissement d'une session L2TP via la prise de contact standard d'appel entrant en trois phases décrite au paragaphe 3.4.1 de la [RFC3931].

Noter qu'un appel sortant L2TP est essentiellement une méthode de contrôle du point d'origine d'un circuit virtuel commuté (SVC, Switched Virtual Circuit) lui permettant d'être établi à partir de tout appareil à capacité L2TP accessible capable d'effectuer des appels sortants. Le modèle d'appel sortant et ses messages de contrôle OCRQ, OCRP, et OCCN correspondants est principalement utilisé aujourd'hui dans le domaine de la numérotation avec L2TPv2 et ne s'est pas encore trouvé applicable pour les applications de PW.

Les éléments de signalisation suivants sont nécessaires pour l'établissement de PW Ethernet :

a)	Type de pseudo filaire : il peut être soit "Accès Ethernet" soit "VLAN Ethernet". Chaque LCCE signale son type de pseudo filaire dans l'AVP Type de pseudo filaire [RFC3931]. Les valeurs allouées pour les types de pseudo filaire "Accès Ethernet" et "VLAN Ethernet" sont notées dans les "Considérations relatives à l'IANA" de ce document. L'AVP Type de pseudo filaiire DOIT être présente dans la ICRQ.

b)	Identifiant de pseudo filaire : chaque PW est associé à un identifiant de pseudo filaire. Les deux LCCE d'un PW ont le même Identifiant de pseudo filaire pour lui. L'AVP Identifiant d'extrémité distante [RFC3931] est utilisée pour porter l'identifiant de pseudo filaire. L'AVP Identifiant d'extrémité distante DOIT être présente dans la ICRQ afin que le LCCE distant détermine le PW à associer à la session L2TP. Une mise en œuvre DOIT prendre en charge un identifiant d'extrémité distante de quatre octets connu des deux LCCE soit par configuration manuelle, soit par d'autres moyens. Les formats supplémentaires d'identifiant d'extrémité distante qui PEUVENT être pris en charge sortent du domaine d'application du présent document.

c)	L'AVP État de circuit [RFC3931] DOIT être incluse dans ICRQ et ICRP pour indiquer l'état du circuit de l'accès Ethernet ou VLAN Ethernet. Pour ICRQ et ICRP, l'AVP État de circuit DOIT indiquer que l'état du circuit est pour un nouveau circuit (se réfèrer au bit N du paragraphe 2.3.3). Une mise en œuvre PEUT envoyer un ICRQ ou ICRP avant qu'une interface Ethernet soit ACTIVE, pour autant que l'AVP État de circuit (se réfèrer au bit A du paragraphe 2.3.3) dans la ICRQ ou ICRP reflète l'état correct de l'accès Ethernet ou de la liaison VLAN Ethernet. Un changement ultérieur de l'état du circuit de l'accès ou VLAN Ethernet DOIT être porté dans l'AVP État de circuit dans les messages de contrôle ICCN ou SLI. Pour ICCN et SLI (voir au paragraphe 2.3.2) l'AVP État de circuit DOIT indiquer que l'état du circuit est pour un circuit existant (se référer au bit N du paragraphe 2.3.3) et reflète l'état actuel de la liaison (se réfère au bit A du paragraphe 2.3.3).

 	2.3	Surveillance de session de pseudo filaire
 	2.3.1	Maintien en vie de connexion de contrôle
L'état de fonctionnement d'un PW est reflété par l'état de la session L2TPv3. Si la session L2TPv3 correspondante est défaillante, le PW qui lui est associé DOIT être fermé. Le mécanisme de maintien en vie de connexion de contrôle de L2TPv3 peut servir de mécanisme de surveillance d'état de liaison pour l'ensemble de PW associé à une connexion de contrôle.

 	2.3.2	Message SLI
En plus du mécanisme de maintien en vie de connexion de contrôle de L2TPv3, le PW Ethernet sur L2TP utilise le message de contrôle Informations d'établissement de liaison (SLI, Set-Link-Info) défini dans la [RFC3931]. Le message SLI est utilisé pour signaler les notifications d'état de liaison Ethernet entre les LCCE. Cela peut être utile pour indiquer les changements d'état d'interface Ethernet sans détruire la session L2TP. Noter qu'un changement de l'état de l'interface Ethernet va déclencher un message SLI pour chaque PW associé à cette interface Ethernet. Ce peut être un PW d'accès Ethernet ou plus d'un PW de VLAN Ethernet. Le message SLI DOIT être envoyé chaque fois qu'il y a un changement d'état d'une valeur identifiée dans l'AVP État de circuit. Les seules exceptions à cela sont les messages initiaux ICRQ, ICRP, et CDN qui établissent et suppriment la session L2TP elle-même. Le message SLI peut être envoyé de l'un ou l'autre LCCE à tout moment après l'envoi du premier ICRQ (et peut-être avant qu'une ICRP soit reçue, exigeant que l'homologue effectue une recherhe inverse d'identifiant de session).

 	2.3.3	Utilisation de l'AVP État de circuit pour Ethernet
Les PW Ethernet rapportent l'état de circuit avec l'AVP État de circuit définie dans la [RFC3931]. Pour référence, cette AVP est montrée ci-dessous :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Réservé         |N|A|
+---------------+-----------+-+-+

La valeur est un gabarit de 16 bits avec les deux bits de moindre poids définis et le reste des bits réservés pour une utilisation future. Les bits réservés DOIVENT être réglés à 0 à l'envoi et ignorés à réception.

Le bit A (Actif) indique si l'interface Ethernet est ACTIVE (1) ou INACTIVE (0).

Le bit N (Nouveau) indique si l'état de circuit est pour un nouveau (1) circuit Ethernet ou un circuit Ethernet existant (0).

 	3.	Traitement de paquet
 	3.1.	Encapsulation
L'encapsulation décrite dans cette Section se réfère à la fonction effectuée par le point de terminaison de PW décrit à la Figure 1, sauf mention contraire.

La trame Ethernet entière, sans le préambule ni la séquence de vérification de trame (FCS, Frame Check Sequence) est encapsulée dans L2TPv3 et est envoyée comme un seul paquet par le LCCE d'entrée. Ceci est fait sans considération de si une étiquette de VLAN est ou non présente dans la trame Ethernet. Pour le mode Ethernet d'accès à accès, le LCCE distant désencapsule simplement la charge utile L2TP et l'envoie sur l'interface appropriée sans modifier l'en-tête Ethernet. Pour le mode Ethernet de VLAN à VLAN, le LCCE distant PEUT réécrire l'étiquette de VLAN. Comme décrit à la Section 1, la modification d'étiquette de VLAN est une fonction de NSP.

Le PW Ethernet sur L2TP est homogène par rapport à l'encapsulation de paquet, c'est-à-dire, les deux extrémités du PW sont soit non étiquetées, soit étiquetées. Le PW Ethernet peut quand même être utilisé pour fournir des services hétérogènes en utilisant la fonction de NSP au LCCE d'entrée et/ou de sortie. La définition de cette fonction de NSP sort du domaine d'application du présent document.

La longueur maximum de la trame Ethernet portée comme charge utile de PW n'est pas pertinente en ce qui concerne le PW. Cette valeur ne serait pertinente que quand on quantifie la régularité de l'émulation.

 	3.2	Séquençage
Le séquençage de paquet de données PEUT être activé pour les PW Ethernet. Les mécanismes de séquençage décrits dans la [RFC3931] DOIVENT être utilisés pour la prise en charge du séquençage de la signalisation.

 	3.3	Traitement de la MTU
Avec L2TPv3 comme protocole de tunnelage, le paquet IP résultant de l'encapsulation est de M + N octets plus long que la trame Ethernet sans le préambule ou la FCS. Ici, M est la longueur de l'en-tête IP avec ses en-têtes d'options et d'extension associés, et la valeur de N dépend des champs suivants :

En-tête de session L2TP :
Fanions, Version, Réservé  - 4 octets (L2TPv3 sur UDP seulement)
Identifiant de session - 4 octets
Taille de mouchard - 0, 4, ou 8 octets
Sous couche spécifique de L2 - 0 ou 4 octets (c'est-à-dire, en utilisant le séquençage)

Donc la gamme pour N en octets est :
N = 4-16, pour les messages de données L2TPv3 sur IP ;
N = 16-28, pour les messages de données L2TPv3 sur UDP ;
(N n'inclut pas l'en-tête IP).

La fragmentation dans le PSN peut survenir quand on utilise Ethernet sur L2TP, sauf si une configuration et une gestion appropriée des tailles de MTU sont en place entre le routeur côté consommateur (CE) et le routeur côté fournisseur (PE) et à travers le PSN. Ceci n'est pas spécifique seulement de Ethernet sur L2TPv3, et la spécification de base L2TPv3 [RFC3931] donne des recommandations générales sur la fragmentation et le réassemblage au paragraphe 4.1.4. "Fragmentation et réassemblage PWE3" [RFC4623] développe ce sujet, incluant un mécanisme de fragmentation et réassemblage au sein de L2TP lui-même dans le cas où aucune autre option n'est disponible. Les mises en œuvre DOIVENT suivre ces lignes directrices sur la fragmentation et le réassemblage.

 	4.	Déclaration d'applicabilité

L'émulation de PW Ethernet permet à un fournisseur de services d'offrir un service Ethernet "d'accès à accès" dans un réseau IP de commutation de paquets (PSN) tandis que l'émulation de PW de VLAN Ethernet permet un service Ethernet de "VLAN à VLAN" à travers un réseau IP de commutation de paquets (PSN).

L'émulation de PW Ethernet ou de VLAN Ethernet a les caractéristiques suivantes en relation avec les services natifs respectifs :

o	Un PW Ethernet connecte deux AC d'accès Ethernet, et un PW de VLAN Ethernet connecte deux AC de VLAN Ethernet, qui prennent tous deux en charge le transport bidirectionnel de trames Ethernet de longueur variable. Le LCCE d'entrée supprime le préambule et la FCS de la trame Ethernet et transporte la trame dans sa totalité à travers le PW. Ceci est fait sans considération de la présence d'étiquette de VLAN dans la trame. Le LCCE de sortie reçoit la trame Ethernet du PW et régénère le préambule et la FCS avant de transmettre la trame au système distant rattaché (voir le paragraphe 3.1). Comme la FCS n'est pas transportée à travers les PW Ethernet ou VLAN Ethernet, la transparence de l'intégrité de la charge utile peut être perdue. Pour réaliser la transparence de l'intégrité de la charge utile sur les PW Ethernet ou VLAN Ethernet en utilisant L2TP sur IP ou L2TP sur UDP/IP, la session L2TPv3 peut utiliser IPsec comme spécifé dans au paragraphe 4.1.3 de la [RFC3931].

o	Bien que du point de vue de l'architecture [RFC3985] cela sorte du domaine d'application du PW L2TPv3 lui-même, si des étiquettes de VLAN sont présentes, le NSP peut réécrire les étiquettes de VLAN en entrée ou sortie du PW (voir le paragraphe 3.1).

o	Le PW Ethernet ou VLAN Ethernet prend seulement en charge le type de trame Ethernet homogène à travers le PW ; les deux extrémités du PW doivent être étiquetées ou non étiquetées. La prise en charge du type de trame hétérogène réalisé avec la fonction de NSP sort du domaine d'application du présent document (voir le paragraphe 3.1).

o	La notification d'état d'accès Ethernet ou de VLAN Ethernet est fournie en utilisant l'AVP État de circuit dans le message SLI (paragraphes 2.3.2 et 2.3.3). La perte de connexité entre les LCCE peut être détectée par le mécanisme de maintien en vie de L2TPv3 (paragraphe 2.3.1 de ce document et paragraphe 4.4 de la [RFC3931]). Le LCCE peut porter ces indications en retour au système distant rattaché.

o	La taille maximum de trame qui peut être supportée est limitée par la MTU du PSN moins la taille de l'en-tête L2TPv3, sauf si la fragmentation et réassemblage est utilisée (paragraphe 3.3 de ce document et paragraphe 4.1.4 de la [RFC3931]).

o	Le réseau à commutation de paquets peut réordonner, dupliquer, ou éliminer en silence les paquets. Le séquençage peut être activé dans le PW Ethernet ou VLAN Ethernet pour certains ou tous les paquets pour détecter la perte, la duplication, ou le déclassement des paquets sur la base de la session (paragraphe 3.2).

o	La fiabilité d'un PW Ethernet ou VLAN Ethernet peut être augmentée en jouant sur les caractéristiques de qualité de service des LCCE et du PSN sous-jacent. Par exemple, pour le transport de VLAN Ethernet 802.1Q [802.1Q], le LCCE d'entrée PEUT considérer le champ Priorité d'utiisateur (c'est-à-dire, 802.1p) de l'étiquette de VLAN pour la classification du trafic et le traitement de la qualité de service, comme de déterminer le champ Services différenciés (DS) [RFC2474] de l'en-tête IP encapsulant. De même, le LCCE de sortie PEUT considérer le champ DS de l'en-tête IP encapsulant quand il réécrit le champ Priorité d'utilisateur de l'étiquette de VLAN ou qu'il met en file d'attente la trame Ethernet avant de la transmettre au système distant. La transposition entre le champ Priorité d'utilisateur et le champ DS de l'en-tête IP ainsi que le modèle de qualité de service déployé sont spécifiques de l'application et sortent du domaine d'application du présent document.

 	5.	Contrôle d'encombrement

Comme expliqué dans la [RFC3985], le PSN qui porte le PW peut être sujet à l'encombrement, avec des caractéristiques d'encombrement qui dépendent du type de PSN, de l'architecture du réseau, de la configuration, et de la charge. Durant l'encombrement, le PSN peut subir des pertes de paquet qui vont impacter le service porté par le PW Ethernet ou VLAN Ethernet. De plus, comme les PW Ethernet ou VLAN Ethernet portent des services divers à travers le PSN, incluant mais pas limités à TCP/IP, ils peuvent ou non se comporter de la façon favorable à TCP prescrite par la [RFC2914] et donc consommer plus que leur part équitable.

Chaque fois qne possible, les PW Ethernet ou VLAN Ethernet devraient fonctionner sur des PSN à ingénierie du trafic fournissant des mécanismes d'allocation de bande passante et de contrôle d'admission. Les domaines à capacité IntServ fournissant le service garanti (GS, Guaranteed Service) ou les domaines à capacité DiffServ qui utilisent la transmission expédiée (EF, expedited forwarding) sont des exemples de PSN à ingénierie du trafic. De tels PSN vont minimiser les pertes et les délais tout en fournissant un certain degré d'isolement des effets sur les PW Ethernet ou VLAN Ethernet des flux du voisinage.

Les LCCE DEVRAIENT surveiller l'encombrement (en utilisant la notification explicite d'encombrement ou en mesurant les pertes de paquets) afin de s'assurer que le service utilisant le PW Ethernet ou VLAN Ethernet peut être maintenu. Quand un encombrement sévère est détecté (par exemple, quand on active le séquençage et qu'on détecte que les pertes de paquets sont supérieures à un certain seuil) le PW Ethernet ou VLAN Ethernet DEVRAIT être arrêté en supprimant la session L2TP via un message CDN. Le PW peut être redémarré par une intervention manuelle ou par des moyens automatiques après un temps d'attente approprié. Noter que les seuils et les périodes de fermeture et de possible récupération automatique doivent être configurés avec soin. Ceci est nécessaire pour éviter des pertes de service dues à un encombrement temporaire et pour empêcher une oscillation entre les états d'encombrement et d'arrêt.

La présente spécification n'offre pas de contrôle d'encombrement et n'est pas favorable à TCP [RFC3448]. De futurs travaux sur le contrôle de l'encombrement de PW (étudiés par le groupe de travail PWE3) fourniront le contrôle d'encombrement pour tous les types de PW incluant des PW Ethernet et VLAN Ethernet.

 	6.	Considérations sur la sécurité

Ethernet sur L2TPv3 est soumis à toutes les considérations générales de sécurité mentionnées dans la [RFC3931].

 	7.	Considérations relatives à l'IANA

Les mécanismes de signalisation définis dans le présent document s'appuient sur les types de pseudo filaire Ethernet suivants (voir la liste des capacités de pseudo filaire définie au paragraphe 5.4.3 de la [RFC3931] et les types de pseudo filaire L2TPv3 au paragraphe 10.6 de la [RFC3931]) qui ont été alloués par l'IANA (l'espace de numéros créé au titre de la publication de la [RFC3931]) :

Types de pseudo filaire
0x0004 : VLAN Ethernet
0x0005 : Ethernet

 	8.	Contributeurs

Voici la liste complète des contributeurs à ce document :
Rahul Aggarwal, Juniper Networks
Xipeng Xiao, Riverstone Networks
W. Mark Townsley, Cisco Systems
Stewart Bryant, Cisco Systems
Maria Alice Dos Santos, Cisco Systems
Cheng-Yin Lee, Alcatel
Tissa Senevirathne, consultant
Mitsuru Higashiyama, Anritsu Corporation

 	9.	Remerciements

Cette RFC a évolué depuis le document, "Émulation de pseudo filaire Ethernet de bord à bord". Nous tenons à remercier ses auteurs, T.So, X.Xiao, L. Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig et G. Heron de leurs contributions. Nous remercions aussi S. Nanji, l'auteur de "Service Ethernet pour le protocole de tunnelage de couche 2", qui a écrit le premier document de Ethernet sur L2TP.

Merci à Carlos Pignataro qui a effectué une relecture très serrée et fourni des commentaires utiles.

 	10.	Références
 	10.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3931]	J. Lau et autres, "Protocole de tunnelage de couche deux - version 3 (L2TPv3)", mars 2005. (P.S.)

[RFC4623]	A. Malis, M. Townsley, "Fragmentation et réassemblage d'émulation bord à bord pseudo filaire (PWE3)", août 2006. (P.S.)

 	10.2	Références pour information

[802.1ad]	Norme IEEE 802.1ad–2005, "Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", Amendement à IEEE Std 8021Q-2005)

[802.1Q]	Norme IEEE 802.1Q-2005, "Local and metropolitan area networks virtual Bridged Local Area Networks", (Incorpore IEEE Std 802.1Q-1998, IEEE Std 802.1u-2001, IEEE Std 802.1v-2001, et IEEE Std 802.1s-2002)

[802.3]	Norme IEEE 802.3-2005/Cor 1-2006, "Information Technology - Telecommuincations and Information Exchange Between Systems - Local and Metropolitan Area Networks", (Corrigendum à IEEE Std 802.3-2005)

[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (P.S. ; MàJ par RFC3168, RFC3260, RFC8436)

[RFC2914]	S. Floyd, "Principes du contrôle d'encombrement", BCP 41, septembre 2000.

[RFC3448]	M. Handley, S. Floyd, J. Padhye, J. Widmer, "Contrôle de débit convivial sur TCP (TFRC) : Spécification du protocole", janvier 2003. (Obsolète, voir RFC5348) (P.S.)

[RFC3985]	S. Bryant et autres, "Architecture d'émulation bord à bord pseudo-filaire (PWE3)", mars 2005. (Information)

 	Adresse des auteurs

Rahul Aggarwal	W. Mark Townsley	Maria Alice Dos Santos	
Juniper Networks	Cisco Systems	Cisco Systems	
1194 North Mathilda Avenue	PO Box 14987	170 W Tasman Dr	
Sunnyvale, CA 94089	Research Triangle Park, NC 27709	San Jose, CA 95134	
mél l: rahul@juniper.net 	mél : mark@townsley.net 	mél : mariados@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est actuellement fourni par la Internet Society.