Groupe de travail Réseau	L. Martini, Cisco Systems	
Request for Comments : 4448	E. Rosen, Cisco Systems	
Catégorie : Sur la voie de la normalisation	N. El-Aawar, Level 3 Communications	
	G. Heron, Tellabs	
Traduction Claude Brière de L'Isle	avril 2006	

Méthodes d'encapsulation pour le transport d'Ethernet sur des réseaux MPLS

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "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).

Résumé
Un pseudo-filaire (PW, pseudo-filaire) Ethernet est utilisé pour porter des unités de données de protocole (PDU, Protocol Data Unit) Ethernet/802.3 sur un réseau MPLS. Cela permet aux fournisseurs de services d'offrir des services Ethernet "émulés" sur des réseaux MPLS existants. Le présent document spécifie l'encapsulation de PDU Ethernet/802.3 dans un pseudo-filaire. Il spécifie aussi les procédures pour utiliser un PW pour fournir un service "Ethernet point à point".
Table des matières
1. Introduction	1
2. Spécification des exigences	4
3. Déclaration d'applicabilité	4
4. Détails spécifiques de services émulés particuliers	4
4.1 Mode Ethernet étiqueté	4
4.2. Mode Ethernet brut	5
4.3 Sous TLV LDP Paramètre d'interface spécifique d'Ethernet	5
4.4 Procédures génériques	5
4.4.2 Gestion de la MTU sur les liaisons PE/CE	6
4.5 Gestion	7
4.6 Mot de contrôle	7
4.7 Considérations de qualité de service	7
5. Considérations sur la sécurité	8
6. Exigences de MTU du PSN	8
7. Références normatives	8
8. Références pour information	9
9. Contributeurs significatifs	9
Appendice A. Lignes directrices pour l'interopérabilité	10
A.1 Options de configuration	10
A.2 Considérations sur le contrôle de flux IEEE 802.3x	11
Appendice B. Détails sur la qualité de service	11
B.1 Adaptation de classe de service 802.1Q à la classe de service de PSN	11
B.2 Préséance d'abandon	11
Adresse des auteurs	12
Déclaration complète de droits de reproduction	12

 	1.	Introduction

Un pseudo-filaire Ethernet (PW) permet de transporter des unités de données de protocole Ethernet/802.3 [802.3] sur un réseau de commutation d'étiquettes multi protocoles (MPLS, Multi-Protocol Label Switched) [RFC3031]. En traitant les problèmes associés au transport d'une PDU Ethernet sur un réseau de commutation de paquets (PSN, packet switched network) le présent document suppose qu'un pseudo-filaire (PW) a été établi en utilisant un protocole de contrôle tel que celui décrit dans la [RFC4447]. La conception de pseudo-filaire Ethernet décrite dans ce document se conforme à l'architecture de pseudo-filaire décrite dans la [RFC3985]. On suppose aussi dans la suite de ce document que le lecteur est familiarisé avec la terminologie de la RFC 3985.

La PDU Ethernet d'émulation de pseudo-filaire de bord à bord (PWE3, Pseudowire Emulation Edge-to-Edge) consiste en les champs Adresse de destination, Adresse de source , Longueur/Type, MAC de données de client, et Bourrage, extraits d'une trame MAC comme une séquence d'octets enchaînés dans leur ordre d'origine [PDU].

En plus du format de PDU Ethernet utilisé dans le pseudo-filaire, le présent document discute :
-	des procédures pour utiliser un PW afin de fournir à une paire de routeurs de bord utilisateur (CE, Customer Edge) une émulation de service Ethernet (en point à point) incluant les procédures de traitement des PDU Ethernet liées au côté fournisseur (PE, Provider Edge) et liées au CE [RFC3985]
-	des considérations de qualité de service (QS) et de sécurité spécifiques d'Ethernet,
-	des considérations de transport inter domaines pour les PW Ethernet.

Les deux figures suivantes décrivent les modèles de référence qui sont déduits de la [RFC3985] pour prendre en charge les services d'émulation de PW Ethernet.

            |<-------------- Service émulé ------------------->|
            |          |<----- Pseudo-filaire ----->|          |
            |          |    |<-- Tunnel PSN -->|    |          |
            | Service  V    V                  V    V  Service |
            V final PW +----+                  +----+ final PW V
      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |  Côté fournisseur 1     Côté fournisseur 2 |  |
      Côté     |                                            | Côté
utilisateur 1  |                                            | utilisateur 2
               |                                            |
     Circuit de rattachement(AC)                Circuit de rattachement(AC)
     au service natif Ethernet                   au service natif Ethernet

Figure 1 : Configuration de référence d'interface PWE3 Ethernet/VLAN

Le "service émulé" montré à la Figure 1 est, strictement parlant, un LAN ponté ; les PE ont des interfaces MAC, consomment des trames de contrôle MAC, etc. Cependant, les procédures spécifiées ici ne prennent en charge que le cas où il y a deux CE sur le "LAN émulé". Donc, on appelle ce service une "émulation d'Ethernet point à point". La spécification des procédures pour utiliser des pseudo-filaires pour émuler des LAN avec plus de deux CE sort du domaine d'application du présent document.

   +---------------+                                +---------------+
   |   Services    |                                |   Services    |
   |   Ethernet    |                                |   Ethernet    |
   |(incluant VLAN)|         Service émulé          |(incluant VLAN)|
   |  émulés       |<==============================>|    émulés     |
   +---------------+        Pseudo-filaire          +---------------+
   |Démultiplexeur |<==============================>|Démultiplexeur |
   +---------------+                                +---------------+
   |   PSN MPLS    |           Tunnel PSN           |    PSN MPLS   |
   |               |<==============================>|               |
   +---------------+                                +---------------+
   |   Physique    |                                |   Physique    |
   +------+--------+                                +-------+-------+

Figure 2 : Modèle de référence de pile de protocole PWE3 Ethernet

Pour les besoins du présent document, PE1 va être défini comme routeur d'entrée, et PE2 comme routeur de sortie. Une PDU de couche 2 va être reçue à PE1, encapsulée à PE1, transportée, désencapsulée à PE2, et transmise sur le circuit de rattachement de PE2.

Un PW Ethernet émule une seule liaison Ethernet entre exactement deux points d'extrémité. Les mécanismes décrits dans le présent document sont ignorants de ce qui est en dessous du niveau "pseudo-filaire" dans la Figure 2, n'étant concerné que par la portion "Service émulé" de la pile.

Le modèle de référence suivant décrit le point de terminaison de chaque extrémité du PW au sein du PE :

           +-----------------------------------+
           |                PE                 |
   +---+   +-+  +-----+  +------+  +------+  +-+
   |   |   |P|  |     |  |termin|  |      |  |P|
   |   |<==|h|<=| NSP |<=|aison |<=|Tunnel|<=|h|<== provenant du PSN
   |   |   |y|  |     |  |de PW |  |  PSN |  |y|
   | C |   +-+  +-----+  +------+  +------+  +-+
   | E |   |                                   |
   |   |   +-+  +-----+  +------+  +------+  +-+
   |   |   |P|  |     |  |termin|  |      |  |P|
   |   |==>|h|=>| NSP |=>|aison |=>|Tunnel|=>|h|==> vers le PSN
   |   |   |y|  |     |  |de PW |  |  PSN |  |y|
   +---+   +-+  +-----+  +------+  +------+  +-+
           |                                   |
           +-----------------------------------+
                       ^         ^         ^
                       |         |         |
                       A         B         C

Figure 3 : Diagramme de référence de PW

Le PW se termine à un accès logique au sein du PE, défini comme point B dans le diagramme ci-dessus. Cet accès fournit un service MAC Ethernet qui va livrer chaque trame Ethernet reçue au point A, sans changement, au point A dans le PE correspondant à l'autre extrémité du PW.

La fonction de traitement de service natif (NSP, Native Service Processing) inclut le traitement de trame qui est nécessaire pour les trames Ethernet qui sont transmises au point de terminaison de PW. De telles fonctions peuvent inclure de supprimer, écraser ou ajouter des étiquettes de VLAN, de multiplexer et démultiplexer un accès physique, un pontage de PW à PW, l'encapsulation de couche 2, la mise en forme, la régulation, etc. Ces fonctions sont spécifiques de la technologie Ethernet, et peuvent n'être pas requises pour le service d'émulation de PW.

Les points à gauche de A, incluant la couche physique entre le CE et le PE, et toutes les fonctions d'adaptation (NSP) entre lui et les terminaisons de PE, sortent du domaine d'application de PWE3 et ne sont pas définies ici.

La "Terminaison de PW", entre A et B, représente les opérations d'établissement et de maintien du PW, et pour encapsuler et désencapsuler les trames Ethernet comme nécessaire pour les transmettre à travers le réseau MPLS.

Un PW Ethernet opère dans un des modes : "mode brut" ou "mode étiqueté". En mode étiqueté, chaque trame DOIT contenir au moins une étiquette de VLAN 802.1Q [802.1Q], et la valeur d'étiquette a une signification pour les NSP aux deux points de terminaison de PW. C'est-à-dire que deux points de terminaison de PW doivent avoir un accord (signalé ou configuré manuellement) sur la façon de traiter l'étiquette. En mode brut de PW, une trame PEUT contenir une étiquette de VLAN 802.1Q, mais si c'est le cas, l'étiquette n'a pas de signification pour les NSP, et passe de façon transparente à travers elles.

La terminologie supplémentaire relevant des pseudo-filaires et des réseaux virtuels privés de couche 2 se trouve dans la [RFC4026].

 	2.	Spécification des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Déclaration d'applicabilité

L'émulation de PW Ethernet permet à un fournisseur de services d'offrir un service "d'accès à accès" fondé sur l'Ethernet à travers un réseau de commutation de paquets (PSN, packet switched network) MPLS alors que l'émulation de PW de VLAN Ethernet permet un service fondé sur un "Ethernet de VLAN à VLAN" à travers un PSN MPLS.

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

-	Un PW Ethernet connecte deux AC Ethernet tandis qu'un PW de VLAN Ethernet connecte deux AC de VLAN Ethernet, prenant en charge le transport bidirectionnel de trames Ethernet de longueur variable. La fonction de traitement de service natif (NSP, Native Service Processing) d'entrée supprime le préambule et la séquence de vérification de trame (FCS, frame check sequence) de la trame Ethernet et transporte la trame dans sa totalité à travers le PW. Ceci se fait sans considération de la présence de l'étiquette 802.1Q dans la trame. La fonction NSP de sortie reçoit la trame Ethernet du PW et régénère le préambule ou la FCS avant de transmettre la trame au circuit de rattachement. 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. La méthode FACULTATIVE décrite dans la [RFC4720] peut être utilisée pour réaliser la transparence de l'intégrité de la charge utile sur les PW Ethernet ou de VLAN Ethernet.

-	Pour un PW de VLAN Ethernet, la réécriture d'étiquette de VLAN peut être réalisée par le NSP au PE de sortie, ce qui sort du domaine d'application de ce document.

-	Le PW Ethernet ou de 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 soit étiquetées, soit non étiquetées. Le type de trame hétérogène réalisé avec la fonction de NSP sort du domaine d'application de ce document.

-	La notification d'état d'accès Ethernet ou de VLAN Ethernet est fournie en utilisant la TLV État de PW dans le message de notification d'état du protocole de distribution d'étiquettes (LDP, Label Distribution Protocol). La perte de connexité entre les PE peut être détectée par la fermeture de la session LDP, ou en utilisant les mécanismes de la [RFC5085]. Le PE peut renvoyer ces indications à son système de rattachement distant.

-	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 MPLS, sauf si la fragmentation et le réassemblage sont utilisés [RFC4623].

-	Le réseau de 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 de VLAN Ethernet pour détecter la perte, duplication, ou désordre des paquets sur la base du PW.

-	La fiabilité d'un PW Ethernet ou VLAN Ethernet peut être augmentée en déployant les caractéristiques de qualité de service des PE et du PSN sous-jacent. (voir au paragraphe 4.7, "Considérations de qualité de service".)

 	4.	Détails spécifiques de services émulés particuliers
 	4.1	Mode Ethernet étiqueté
La trame Ethernet va être encapsulée en accord avec les procédures définies plus loin dans ce document pour le mode étiqueté. On notera que si l'identifiant de VLAN est modifié par le PE de sortie, le protocole d'arborescence Ethernet peut échouer à fonctionner correctement. Si ce problème est significatif, l'identifiant de VLAN DOIT être choisi d'une façon telle qu'il corresponde aux circuits de rattachement aux deux extrémités du PW.

Si le PE détecte une défaillance sur l'accès physique Ethernet, ou si l'accès est administrativement désactivé, il DOIT envoyer un message de notification d'état de PW pour tous les PW associés à l'accès.

Ce mode utilise les étiquettes de délimitation de service pour transposer les trames Ethernet d'entrées en les PW respectifs et correspondre au type de PW 0x0004 "Mode Ethernet étiqueté" [RFC4446].

 	4.2.	Mode Ethernet brut
La trame Ethernet va être encapsulée en accord avec les procédures définies plus loin dans ce document pour le mode brut. Si le PE détecte une défaillance sur l'accès d'entrée Ethernet, ou si l'accès est désactivé administrativement, le PE DOIT envoyer un message de notification État de PW approprié au PE distant correspondant.

Dans ce mode, toutes les trames Ethernet reçues sur le circuit de rattachement de PE1 vont être transmises à PE2 sur un seul PW. Ce service correspond au type de PW 0x0005 "Ethernet" [RFC4446].

 	4.3	Sous TLV LDP Paramètre d'interface spécifique d'Ethernet
Ce sous type LDP Longueur Valeur [RFC3036] spécifie des paramètres spécifiques de l'interface. Quand il est applicable, il DOIT être utilisé pour valider que les PE, et les accès d'entrée et sortie aux bordures du circuit, ont les capacités nécessaires pour interopérer. La TLV Paramètres d'interface est définie dans la [RFC4447], le registre IANA des valeurs initiales pour les types de sous TLV Paramètres d'interface est défini dans la [RFC4446], mais les paramètres d'interface spécifiques de Ethernet sont spécifiés comme suit :

0x06 Sous TLV Identifiant de VLAN demandé : valeur facultative de 16 bits qui indique l'identifiant de VLAN demandé. Ce paramètre DOIT être utilisé par un PE qui est incapable de réécrire l'étiquette de VLAN 802.1Q Ethernet en sortie. Si le PE d'entrée reçoit cette demande, il DOIT réécrire l'identifiant de VLAN contenu dans l'étiquette de VLAN à l'entrée pour correspondre à l'identifiant de VLAN demandé. Si ce n'est pas possible, et si l'identifiant de VLAN ne correspond pas déjà à l'identifiant de VLAN d'entrée configuré, le PW NE DOIT PAS être activé. Ce paramètre n'est applicable qu'au type de PW 0x0004.

 	4.4	Procédures génériques
Quand le NSP/transmetteur passe une trame à la fonction de terminaison de PW :
-	Le préambule (si il en est) et la FCS sont supprimés.
-	Le mot de contrôle, comme défini au paragraphe 4.6 est, si nécessaire, ajouté devant la trame résultante. Les conditions dans lesquelles le mot de contrôle est ou non utilisé sont spécifiées ci-dessous.
-	Le démultiplexeur (étiquette de PW) de pseudo-filaire approprié est ajouté devant le paquet résultant.
-	L'encapsulation de tunnel appropriée est ajoutée devant le paquet résultant..
- 	Le paquet est transmis.

La façon de choisir l'encapsulation de tunnel et le démultiplexeur de pseudo-filaire appropriés dépend des procédures qui ont été utilisées pour établir le pseudo-filaire.

L'encapsulation de tunnel dépend de la façon dont le PSN MPLS est établi. Cela peut de ne pas inclure d’étiquette, d'inclere une étiquette, ou plusieurs étiquettes. Le démultiplexeur de pseudo-filaire approprié est une étiquette MPLS dont la valeur est déterminée par les protocoles d'établissement et de maintenance du PW.

Quand un paquet arrive sur un PW, l'encapsulation de tunnel et le démultiplexeur de PW sont supprimés. Si le mot de contrôle est présent, il est traité et supprimé. La trame résultante est alors passée au transmetteur/NSP. La régénération de la FCS est considérée comme étant de la responsabilité du NSP.

 	4.4.1	Mode brut contre mode étiqueté
Quand le PE reçoit une trame Ethernet, et que la trame a une étiquette de VLAN, on peut distinguer deux cas :

1.	L'étiquette est un délimiteur de service. Cela signifie que l'étiquette a été placée sur la trame par un équipement  agissant pour le fournisseur de service, et l'étiquette est utilisée par le fournisseur de service pour distinguer le trafic. Par exemple, les LAN provenant de consommateurs différents pourraient être rattachés au même commutateur de fournisseur de service, qui applique des étiquettes de VLAN pour distinguer le trafic d'un consommateur de celui d''un autre, et ensuite transmet les trames au PE.

2.	L'étiquette n'est pas un délimiteur de service. Cela signifie que l'étiquette a été placée dans la trame par un élément d'équipement de consommateur, et n'a pas de signification pour le PE.

La configuration locale du PE détermine si l'étiquette est ou non un délimiteur de service.

Si un PW Ethernet fonctionne en mode brut, les étiquettes de délimitation de service ne sont JAMAIS envoyées sur le PW.  Si une étiquette de délimitation de service est présente quand la trame est reçue du circuit de rattachement par le PE, elle DOIT être supprimée (par le NSP) de la trame avant son envoi au PW.

Si un PW Ethernet fonctionne en mode étiqueté, chaque trame envoyée sur le PW DOIT avoir une étiquette de délimitation de service de VLAN. Si la trame telle que reçue par le PE du circuit de rattachement n'a pas d'étiquette de délimitation de service de VLAN, le PE doit ajouter devant la trame une étiquette de VLAN factice avant d'envoyer la trame sur le PW. C'est le mode de fonctionnement par défaut. C'est le seul mode EXIGÉ.

Dans les deux modes, les étiquettes non délimitrices de service sont passées de façon transparente à travers le PW au titre de la charge utile. On notera qu'un seul paquet Ethernet peut contenir plus d'une étiquette. Au plus, une de ces étiquettes peut être délimitrice de service. Dans tous les cas, la fonction de NSP peut seulement inspecter l'étiquette la plus externe pour les besoins de l'adaptation de la trame Ethernet au pseudo-filaire.

Dans les deux modes, les valeurs d'étiquettes délimitrices de service ont seulement une signification locale, c'est-à-dire, ne sont significatives que à une interface PE-CE particulière. Quand le mode étiqueté est utilisé, le PE qui reçoit une trame du PW peut réécrite la valeur de l'étiquette, ou peut supprimer entièrement l'étiquette, ou peut laisser l'étiquette inchangée, selon sa configuration. Quand le mode brut est utilisé, le PE qui reçoit une trame peut ou non avoir besoin d'ajouter une étiquette délimitrice de service avant de transmettre la trame sur le circuit de rattachement ; cependant, il NE DOIT PAS réécrire ou supprimer d'étiquettes déjà présentes.

Le tableau suivant illustre les opérations qui peuvent être effectuées à l'entrée du circuit de rattachement :

+----------------+------------------------------------------+--------------------------------+
| Étiquette->    |   délimiteur de service                     | non délimiteur de service  |
|-----------------+------------------------------------------+--------------------------------|
|  Mode brut    | 1ère étiquette de VLAN supprimée | aucune opération effectuée|
|-----------------+------------------------------------------+--------------------------------|
|Mode étiqueté | NO OP ou étiquette ajoutée            |  Étiquette ajoutée              |
+----------------+-------------------------------------------+-------------------------------+

 	4.4.2	Gestion de la MTU sur les liaisons PE/CE
Le PW Ethernet NE DOIT PAS être activé si on ne sait pas si les MTU des liaisons CE-PE sont les mêmes aux deux extrémités du PW. Si un routeur de sortie reçoit une PDU encapsulée de couche 2 dont la longueur de charge utile (c'est-à-dire, la longueur de la PDU elle-même sans aucun des en-têtes d'encapsulation) excède la MTU de l’interface de couche 2 de destination, la PDU DOIT être éliminée.

 	4.4.3	Ordre des trames
En général, les applications qui fonctionnent sur Ethernet n'exigent pas un strict ordre de trames. Cependant, la définition de l'IEEE de [802.3] exige que les trames provenant de la même conversation dans le contexte de l'agrégation de liaison (clause 43) soient livrées en séquence. De plus, le PSN ne peut pas (en général) être supposé fournir ou garantir l'ordre des trames. Un PW Ethernet peut, en utilisant le mot de contrôle, fournir un ordre strict des trames. Si cette option est activée, toutes les trames qui sont reçues dans le désordre par le PSN vont être éliminées ou réordonnées par le point d'extrémité de PW receveur. Si l'ordre strict des trames est une exigence pour un PW particulier, cette option DOIT être activée.

 	4.4.4	Traitement d'erreur de trame
Une trame Ethernet encapsulée qui traverse un pseudo-filaire peut être éliminée, corrompue, ou livrée dans le désordre. Comme décrit dans la [RFC3916], la perte de trame, la corruption, et la livraison dans le désordre sont considérées être une "erreur binaire généralisée" du pseudo-filaire. Les trames de PW qui sont corrompues vont être détectées à la couche PSN et éliminées.

À l'entrée du PW, les mécanismes de traitement d'erreur de trame Ethernet native DOIVENT être activés. Donc, si un appareil de PE reçoit une trame Ethernet contenant des erreurs de contrôle de redondance cyclique (CRC, Cyclic Redundancy Check) de niveau matériel, des erreurs de tramages, ou une condition de trame trop courte, la trame DOIT être éliminée à l'entrée. Noter que la définition de ce traitement fait partie de la fonction de NSP et sort du domaine d'application de ce document.

 	4.4.5	Interfonctionnement du contrôle de flux IEEE 802.3x
Dans un réseau Ethernet standard, le mécanisme de contrôle de flux est facultatif et est normalement configuré entre les deux nœuds sur une liaison point à point (par exemple, entre le CE et le PE). Les trames PAUSE IEEE 802.3x NE DOIVENT PAS être portées à travers le PW. Voir à l'Appendice A les notes sur le contrôle de flux CE-PE.

 	4.5	Gestion
Le modèle de gestion de PW Ethernet suit le modèle général de gestion de PW défini dans les [RFC3985] et [RFC5601]. De nombreuses facilités de gestion de PW communes sont fournies ici, sans spécificité Ethernet supplémentaire nécessaire. Les paramètres spécifiques d'Ethernet sont définis dans un module de MIB supplémentaire [RFC5603].

 	4.6	Mot de contrôle
Le mot de contrôle défini dans ce paragraphe se fonde sur le mot de contrôle générique de PW MPLS comme défini dans la [RFC4385]. Il fournit la capacité de séquencer les trames individuelles sur le PW, l'évitement de l'équilibrage de charge de multi chemins de coût égal (ECMP, equal-cost multiple-path load-balancing) [RFC2992], et les mécanismes d'opération et gestion (OAM, Operations et Management) incluant la vérification de connexité de circuit virtuel [RFC5085].

La [RFC4385] déclare  : "Si un PW est sensible au désordre des paquets et si il est porté sur un PSN MPLS qui utilise le contenu de la charge utile MPLS pour choisir le chemin ECMP, il DOIT employer un mécanisme qui empêche le désordre des paquets." Ceci est nécessaire parce que les mises en œuvre de ECMP peuvent examiner le premier quartet après la pile d'étiquettes MPLS pour déterminer si le paquet étiqueté est IP ou non. Donc, si l'adresse MAC de source de la trame Ethernet portée sur le PW sans la présence d'un mot de contrôle commence par un 0x4 ou 0x6, elle pourrait être prise par erreur pour un paquet IPv4 ou IPv6. Cela pourrait, selon la configuration et la topologie du réseau MPLS, conduire à une situation où tous les paquets pour un certain PW ne suivent pas le même chemin. Cela peut augmenter le nombre de trames en désordre sur un certain PW, ou être cause que les paquets OAM suivent un chemin différent du trafic réel (voir au paragraphe 4.4.3, "Ordre des trames").

Les caractéristiques que fournit le mot de contrôle peuvent n'être pas nécessaires pour un certain PW Ethernet. Par exemple, ECMP peut n'être pas présent ou actif sur un certain réseau MPLS, le séquençage strict des trames peut n'être pas requis, etc. Si c'est le cas, le mot de contrôle apporte peu d'avantages et est donc facultatif. Les mises en œuvre précoces de PW Ethernet ont été déployées sans inclure de mot de contrôle ni la capacité de le traiter si il est de présent. Pour aider à la rétro compatibilité, les futures mises en œuvre DOIVENT être capables d'envoyer et recevoir des trames sans mot de contrôle.

Dans tous les cas, le PE sortie DOIT savoir si le PE d'entrée va envoyer un mot de contrôle sur un PW spécifique. Cela peut être réalisé par la configuration des PE, ou par la signalisation, comme défini dans la [RFC4447].

Le mot de contrôle est défini comme suit :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|   Réservé             |     Numéro de séquence        |
+-------+-------+---------------+---------------+---------------+

Dans le diagramme ci-dessus, les 4 premiers bits DOIVENT être réglés à 0 pour indiquer des données de PW. Le reste des 16 premiers bits est réservé pour utilisation future. Ils DOIVENT être réglés à 0 à l'émission, et ignorés à réception.

Les 16 bits suivants fournissent un numéro de séquence qui peut être utilisé pour garantir une livraison ordonnée des trames. Le traitement des champs Numéro de séquence est FACULTATIF.

L'espace de numéros de séquence est un espace circulaire de 16 bits, non signés. La valeur de numéro de séquence de 0 est utilisée pour indiquer que l'algorithme de vérification de numéro de séquence n'est pas utilisé. L'algorithme de traitement de numéro de séquence se trouve dans la [RFC4385].

 	4.7	Considérations de qualité de service
Le PE d'entrée PEUT considérer le champ Priorité d'utilisateur (PRI) [802.1Q] de l'en-tête d'étiquette de VLAN quand il détermine la valeur à placer dans un champ Qualité de service du protocole encapsulant (par exemple, les champs EXP de la pile d'étiquette MPLS). De façon similaire, le PE de sortie PEUT considérer le champ Qualité de service du protocole encapsulant (par exemple, les champs EXP de la pile d'étiquettes MPLS) quand il met la trame en file d'attente pour transmission au CE.

Un PE DOIT prendre en charge la capacité de porter le PW Ethernet comme service au mieux sur le PSN MPLS. Les bits PRI restent transparents entre les appareils de PE, sans considération de la prise en charge de la QS du PSN.

Su un champ VLAN 802.1Q est ajouté au PE, un réglage de PRI par défaut de zéro DOIT être accepté, une valeur configurée par défaut est recommandée, ou la valeur peut être transposée du champ Qualité de service du PSN, comme mentionné ci-dessus.

Un PE peut prendre en charge une qualité de service supplémentaire au moyen d'une ou plusieurs des méthodes suivantes :
i.	Une classe de service (CoS) par service d'extrémité de PW (PWES, PW End Service) transposée en une seule CoS de PW au PSN.
ii.	Plusieurs CoS par PWES transposées en un seul PW avec plusieurs CoS au PSN.
iii.	Plusieurs CoS par PWES transposées en plusieurs PW au PSN.

Des exemples de ces cas et les détails des considérations de transposition de service sont décrites à l'Appendice B.

Le débit garanti de PW au niveau du PSN MPLS relève de la politique du fournisseur de service de PW sur la base de l'accord avec l'utilisateur, et peut être différent du débit d'accès de l'Ethernet physique.

 	5.	Considérations sur la sécurité

Le type pseudo-filaire Ethernet est soumis à toutes les considérations générales de sécurité discutées dans les [RFC3985] et [RFC4447].

Le pseudo-filaire Ethernet est transporté sur un PSN MPLS ; donc, la sécurité du pseudo-filaire lui-même va être seulement aussi bonne que la sécurité du PSN MPLS. Le PSN MPLS peut être sécurisé par diverses méthodes, comme décrit dans la [RFC3031].

La sécurité réalisée par le contrôle d'accès des adresses MAC sort du domaine d'application de ce document. Les exigences de sécurité supplémentaires relatives à l'utilisation de PW dans un environnement commuté (pontage virtuel) ne sont pas discutées ici car elles sortent du domaine d'application de ce document.

 	6.	Exigences de MTU du PSN

Le PSN MPLS DOIT être configuré avec une MTU assez grande pour transporter une trame Ethernet de taille maximum qui a été encapsulée avec un mot de contrôle, un démultiplexeur pseudo-filaire, et une encapsulation de tunnel. Avec MPLS utilisé comme protocole de tunnelage, par exemple, cela va probablement être de 8 octets ou plus supérieur à la plus grande taille de trame. La méthodologie décrite dans la [RFC4623] PEUT être utilisée pour fragmenter les trames encapsulées qui excèdent la MTU du PSN. Cependant, si la [RFC4623] n'est pas utilisée et si le routeur d'entrée détermine que la PDU de couche 2 encapsulée excède la MTU du tunnel PSN à travers lequel elle doit être envoyée, la PDU DOIT être éliminée.

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

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

[RFC4385]	S. Bryant et autres, "Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN MPLS", février   2006. (P.S.)

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC4447]	L. Martini et autres, "Établissement et maintenance de pseudo filaires avec le protocole de distribution d'étiquettes", avril  2006. (MàJ par la RFC6723) (P.S. ; Remplacé par RFC8077 STD 84)

[802.3]	IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), "IEEE Standard for Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements -- Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 2005.

[802.1Q]	ANSI/IEEE Standard 802.1Q-2005, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 2005.

[PDU]	IEEE Std 802.3, 1998 Edition, "Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications" figure 3.1, 1998

 	8.	Références pour information

[RFC2992]	C. Hopps, "Analyse d'un algorithme multi-chemins de coût égaux", novembre 2000. (Information)

[RFC3036]	L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)

[RFC3916]	X. Xiao, D. McPherson et P. Pate, éd., "Exigences pour l'émulation bord à bord pseudo filaire (PWE3)", septembre  2004. (Information)

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

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

[RFC4026]	L Andersson et T. Madsen, "Terminologie des réseaux privés virtuels (VPN) approvisionnés par le fournisseur", mars  2005.

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

[RFC4720]	A. Malis et autres, "Rétention de séquence de vérification de trame d'émulation bord à bord pseudo filaire (PWE3)", novembre 2006. (P.S.)

[RFC5085]	T. Nadeau et C. Pignataro, éditeurs, "Vérification de connexité de circuit virtuel pseudo filaire (VCCV) : un canal de contrôle pour les pseudo filaires", décembre 2007. (MàJ par RFC5586) 

[RFC5601]	T. Nadeau, D. Zelig, "Base de données d'informations de gestion (MIB) de services pseudo filaires (PW)", juillet 2009. (P.S.)

[RFC5603]	D. Zelig, T. Nadeau, "Base de données d'informations de gestion (MIB) de services pseudo filaires (PW) sur  Ethernet", juillet 2009. (P. S.)

 	9.	Contributeurs significatifs

Andrew G. Malis	Dan Tappan	Steve Vogelsang	Vinai Sirkay	
Tellabs	Cisco Systems, Inc.	ECI Telecom	Reliance Infocomm	
90 Rio Robles Dr.	1414 Massachusetts Avenue	Omega Corporate Center	Dhirubai Ambani 	
San Jose, CA 95134	Boxborough, MA 01719	1300 Omega Drive	Navi Mumbai 400 709	
Andy.Malis@tellabs.com 	mél : tappan@cisco.com 	Pittsburgh, PA 15205	India	
		stephen.vogelsang@ecitele.com 	mél : vinai@sirkay.com 	

Vasile Radoaca	Chris Liljenstolpe	Kireeti Kompella	
Nortel Networks	Alcatel	Juniper Networks	
600 Technology Park	11600 Sallie Mae Dr.	1194 N. Mathilda Ave	
Billerica MA 01821	9th Floor	Sunnyvale, CA 94089	
mél : vasile@nortelnetworks.com 	Reston, VA 20193	mél : kireeti@juniper.net 	
	mél : chris.liljenstolpe@alcatel.com 		

Tricci So	XiPeng Xiao	Christopher O. Flores	
Nortel Networks 3500 Carling Ave.,	Riverstone Networks	T-Systems	
Nepean, Ontario,	5200 Great America Parkway	10700 Parkridge Boulevard	
Canada, K2H 8E9.	Santa Clara, CA 95054	Reston, VA 20191	
mél : tso@nortelnetworks.com 	mél : xxiao@riverstonenet.com 	mél : christopher.flores@usa.telekom.de 	

David Zelig	Raj Sharma	Nick Tingle	
Corrigent Systems	Luminous Networks, Inc.	TiMetra Networks	
126, Yigal Alon St.	10460 Bubb Road	274 Ferguson Drive	
Tel Aviv, ISRAEL	Cupertino, CA 95014	Mountain View, CA 94043	
mél : davidz@corrigent.com 	mél : raj@luminous.com 	mél : nick@timetra.com 	

Sunil Khandekar	Loa Andersson	
TiMetra Networks	TLA-group	
274 Ferguson Drive	mél : loa@pi.se 	
Mountain View, CA 94043		
mél : sunil@timetra.com 		

 	Appendice A.	Lignes directrices pour l'interopérabilité
 	A.1	Options de configuration
Liste des options de configuration pour un PW point à point Ethernet fondé sur les points de référence de la Figure  3:

Service et encapsulation
 sur A	Encapsulation sur C entrée/sortie	Opération à B	Remarques	
1) Brut	Brut - même que A			
2) Étiquette 1	Étiquette 2	Changement facultatif de la valeur de VLAN	Le VLAN peut être 0-4095. Changement permis dans les deux directions	
3) Pas d'étiquette	Étiquette	Ajout/suppressoin du champ Étiquette	Étiquette peut être 0-4095. (note i)	
4) Étiquette	Pas d'étiquette	Suppression/ajout du champ Étiquette	(note ii)	

Figure 4 : Options de configuration

Combinaions permises : Brut et autres services ne sont par permis sur le même accès NSP virtuel (A). Toutes les autres combinaisons sont permises, excepté les VLAN en conflit sur (A) ne sont pas permis. Noter que dans la plupart des applications de PW point à point, l'accès NSP virtuel est la même entité que l'accès physique.

Notes  :
i.	Le mode n° 3 PEUT être limité au seul ajout du VLAN NUL, car changer un VLAN ou une association en un VLAN spécifique peut être fait du côté lié au CE du PW.
ii.	Le mode n° 4 existe dans les commutateurs de couche 2, mais il n'est pas recommandé dans un fonctionnement avec un PW car il ne peut pas préserver les bits PRI d'utilisateur. Si il y a besoin de supprimer l'étiquette de VLAN (pour TLS à l'autre extrémité du PW) il est recommandé d'utiliser le mode n° 2 avec étiquette 2=0 (VLAN NUL) sur le PW et d'utiliser le mode n° 3 à l'autre extrémité du PW.

 	A.2	Considérations sur le contrôle de flux IEEE 802.3x
Si le nœud receveur devient encombré, il peut envoyer une trame spéciale, appelée une trame PAUSE, au nœud source à l'extrémité opposée de la connexion. La mise en œuvre DOIT fournir un mécanisme pour terminer les trames PAUSE en local (c'est-à-dire, au PE local). Cela DOIT opérer comme suit : les trames PAUSE reçue sur un accès Ethernet local DEVRAIENT être mises en mémoire tampon, ou éliminées par l'appareil de PE des trames Ethernet qui arrivent sur cet accès jusqu'à ce que la condition de PAUSE soit supprimée. Facultativement, le PE PEUT simplement éliminer les trames PAUSE.

Si l'appareil de PE souhaite faire une pause de la réception des données sur un accès Ethernet local (peut-être parce que ses propres mémoires tampon sont pleines ou parce que il a reçu des notifications d'encombrement dans le PSN) il PEUT alors produire une trame PAUSE sur l'accès local Ethernet, mais DOIT supprimer cette condition quand il veut recevoir plus de données.

 	Appendice B.	Détails sur la qualité de service

Le paragraphe 4.7, "Considérations de qualité de service", décrit divers modes de prise en charge de la QS de PW sur le PSN. Des exemples de cela pour un service de VLAN en point à point sont :
-	Le classement au PW est fondé sur le champ VLAN, mais les bits PRI d'utilisateur sont transposés en différentes marques de CoS (et comportement de réseau) au niveau du PW. Un exemple est celui d'un PW transposé en un E-LSP dans un réseau MPLS.
-	Le classement au PW est fondé sur le champ VLAN et les bits PRI, et les trames avec des bits PRI différents sont transposés à des PW différents. Un exemple est de transposer un PWES en différents L-LSP dans le PSN MPLS afin de prendre en charge plusieurs CoS sur un réseau à capacité L-LSP, ou de transposer un PWES en plusieurs sessions L2TPv3 [RFC3931].

La valeur spécifique à allouer au PSN pour les diverses CoS sort du domaine d'application de ce document.

 	B.1	Adaptation de classe de service 802.1Q à la classe de service de PSN
Il n'est pas exigé que le PSN ait la même définition de CoS que [802.1Q], et la transposition de CoS 802.1Q en CoS de PSN est spécifique de l'application et dépend de l'accord entre le client et le fournisseur de PW. Cependant, les principes suivants qui sont adoptés par 802.1Q, Tableau 8-2, DOIVENT être respectés pour appliquer l'ensemble de CoS de PSN fondés sur les bits de PRI d'utilisateur.

	Numéro des classes de service disponibles
Priorité d'utilisateur	| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
0 Au mieux (par défaut)	| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 |
1 De base 	| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2 De secours	| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
3 Excellent effort	| 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 |
4 Charge contrôlée	| 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 |
5 Multimédia interactif	| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 |
6 Vocal interactif	| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 |
7 Contrôle réseau	| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

Figure 5 : Transposition de classe de service IEEE 802.1Q

 	B.2	Préséance d'abandon
La norme 802.1P ne prend pas en charge la préséance d'abandon  ; donc, du point de vue du PW lié au PE, aucune transposition n'est nécessaire. Il est cependant possible de marquer des préséances d'abandon différentes pour différentes trames de PW sur la base de la politique de l’opérateur et du comportement de réseau requis. Cette fonction n'est pas discutée ici.

La prise en charge de la qualité de service du PSN et la signalisation de la QS sortent du domaine d'application de ce document.

 	Adresse des auteurs

Nasser El-Aawar	Giles Heron	Luca Martini	Eric C. Rosen	
Level 3 Communications	Tellabs	Cisco Systems, Inc.	Cisco Systems, Inc.	
1025 Eldorado Blvd.	Abbey Place	9155 East Nichols Avenue	1414 Massachusetts Avenue	
Broomfield, CO, 80021	24-28 Easton Street	Englewood, CO, 80112	Boxborough, MA 01719	
USA	High Wycombe, Bucks	USA	USA	
mél : nna@level3.net 	HP11 1NT   UK	mél : lmartini@cisco.com 	mél : erosen@cisco.com 	
	mél : giles.heron@tellabs.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 à www.rfc-editor.org, 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 fournis 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 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 pourrait ê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 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 fourni par l'activité de soutien administatif (IASA) de l'IETF.