Groupe de travail Réseau L. Martini, éd.,Cisco Systems	L. Martini, éd., Cisco Systems	
Request for Comments : 4619	C. Kawa, éd., OZ Communications	
Catégorie : Sur la voie de la normalisation	A. Malis, éd., Tellabs	
Traduction Claude Brière de L'Isle	septembre 2006	

Méthodes d'encapsulation pour le transport de relais de trame sur réseaux de commutation d'étiquettes multi protocoles (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 en relais de trame est un mécanisme qui existe entre des nœuds réseau de bordure d'un fournisseur et qui prend en charge aussi fiablement que possible des services de relais de trame sur un réseau de commutation de paquets (PSN, packet switched network) sur MPLS. Le présent document décrit l'encapsulation détaillée nécessaire pour transporter les paquets de relais de trame sur un réseau MPLS.
Table des matières
1. Introduction	1
2. Spécification des exigences	2
3. Co-auteurs	3
4. Acronymes et abréviations	3
5. Déclaration d'applicabilité	3
6. Méthode générale d'encapsulation	4
7. Relais de trame sur PSN MPLS pour le mode un à un	4
7.1 Tunnel et PW de PSN MPLS	4
7.2 Format de paquet sur PSN MPLS	5
7.3 Mot de contrôle	5
7.4 Mot de contrôle en mode Martini traditionnel	6
7.5 Traitement du paquet PW	6
7.6 Désencapsulation des paquets PW	7
7.7 Valeurs du bit EXP d'ajustement MPLS	8
7.8 Valeur du bit S d'ajustement MPLS	8
7.9 Détails du plan de contrôle pour le service de relais de trame	8
8. Mode d'accès de relais de trame	8
9.  Contrôle d'encombrement	8
10. Considérations sur la sécurité	9
11. Références normatives	9
12. Références pour information	9
Informations sur les auteurs contributeurs	10
Adresse des éditeurs	10
Déclaration complète de droits de reproduction	11

 	1.	Introduction

Dans un réseau MPLS ou IP, il est possible d'utiliser des protocoles de contrôle comme ceux spécifiés dans la [RFC4447] pour établir des "pseudo-filaires" (PW, pseudowire) qui portent les unités de données de protocole des protocole de couche 2 à travers le réseau. Un certain nombre de ces PW émulés peut être porté dans un seul tunnel. Les principales fonctions requises pour prendre en charge le PW de relais de trame par un côté fournisseur (PE, Provider Edge) incluent :
- l'encapsulation d'informations spécifiques de relais de trame dans un paquet de pseudo-filaire (PW) convenable ;
- le transfert d'un paquet de PW à travers un réseau MPLS pour livraison à un PE homologue ;
- l'extraction d'informations spécifiques de relais de trame d'un paquet de PW par l'homologue PE distant ;
- la régénération des trames natives de relais de trame pour leur transmission à travers un accès de sortie de l'homologue PE distant ; et
- l'exécution de toutes autres opérations nécessaires pour prendre en charge le service de relais de trame.

Le présent document spécifie l'encapsulation du VC de relais de trame émulé sur un PSN MPLS. Bien que des protocoles de couche 2 différents exigent que des informations différentes soient portées dans cette encapsulation, il a été tenté de rendre l'encapsulation aussi commune que possible pour tous les protocoles de couche 2. Les autres protocoles de couche 2 sont décrits dans des documents distincts  : [RFC4448] [RFC4618] [RFC4717].

La figure suivante décrit les modèles de référence qui sont dérivés de la [RFC3985] pour prendre en charge les services de PW émulés de relais de trame.

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

Figure 1. Configuration de référence d'interface PWE3 de PVC de relais de trame

Deux modes de transposition peuvent être définis entre les VC de relais de trame et les pseudo-filaires : le premier est appelé transposition "un à un", parce que il y a une correspondance biunivoque entre un VC de relais de trame et un pseudo-filaire. La seconde transposition est appelée transposition de "beaucoup à un" ou "mode accès" parce que plusieurs VC de relais de trame alloués à un accès sont transposés sur un pseudo-filaire. L'encapsulation en "mode accès" est identique à l'encapsulation de pseudo-filaire de contrôle de liaison de données de haut niveau (HDLC, High-Level Data Link Control) qui est décrite dans la [RFC4618].

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

Les définitions des termes utilisés tout au long de ce document figurent ci-dessous. Les définitions de PWE3 se trouvent dans les [RFC3916], [RFC3985]. Cette section définit les termes spécifiques du relais de trame.

- Direction  vers l'avant : c'est la direction prise par la trame transmise.

- Direction  vers l'arrière : en relais de trame, c'est la direction opposée de la direction prise par la trame transmise (voir aussi direction vers l'avant).

 	3.	Co-auteurs

Les co-auteurs de ce document sont :
Ravi Bhat                         Nokia
Nasser El-Aawar              Level 3 Communications, LLC
Giles Heron                      Tellabs
Thomas K. Johnson          Litchfield Communications
Kireeti Kompella              Juniper Networks, Inc.
Chris Liljenstolpe             Cable & Wireless
Prayson Pate                     Overture Networks, Inc
Eric C. Rosen                   Cisco Systems
Vinai Sirkay                     Reliance Infocomm
Dimitri Stratton Vlachos  Mazu Networks,Inc.
Daniel Tappan                  Cisco Systems
Nishit Vasavada               Nokia
Steve Vogelsang               Laurel Networks, Inc.

 	4.	Acronymes et abréviations

BECN (Backward Explicit Congestion Notification)  : notification d'encombrement explicite vers l'arrière
CE (Customer Edge)  : côté utilisateur
C/R  : commande/réponse
DE (Discard Eligibility)  : éligibilité à la suppression
DLCI (Data Link Connection Identifier)  : identifiant de connexion de liaison de données
FCS (Frame Check Sequence)  : séquence de vérification de trame
FECN (Forward Explicit Congestion Notification)  : notification d'encombrement explicite vers l'avant
FR (Frame Relay)  : relais de trame
LSP (Label Switched Path)  : chemin de commutation d'étiquettes
LSR (Label Switching Router)  : routeur de commutation d'étiquettes
MPLS (Multiprotocol Label Switching)  : commutation d'étiquettes multi protocoles
MTU (Maximum Transfer Unit)  : unité de transfert maximum
NNI (Network-Network Interface)  : interface réseau-réseau
PE (Provider Edge)  : côté fournisseur
PSN (Packet Switched Network)  : réseau de commutation de paquets
PW (Pseudowire)  : pseudo-filaire
PWE3 (Pseudowire Emulation Edge to Edge)  : émulation de pseudo-filaire bord à bord 
POS (Packet over SONET/SDH)  : paquet sur SONET/SDH
PVC (Permanent Virtual Circuit)  : circuit virtuel permanent
QS  : qualité de service
SVC (Switched Virtual Circuit)  : circuit virtuel commuté
UNI (User-Network Interface)  : interface usager-réseau
VC (Virtual Circuit)  : circuit virtuel

 	5.	Déclaration d'applicabilité

Le service de relais de trame sur PW n'est pas destiné à émuler parfaitement le service de relais de trame traditionnel, mais il peut être utilisé pour les applications qui ont besoin du service de transport en relais de trame.

Les différences notables entre le service traditionnel de relais de trame et le protocole décrit dans le présent document sont décrites ci-dessous :

-	L'ordre des trames peut être préservé en utilisant le champ FACULTATIF Séquence dans le mot de contrôle ; cependant, les mises en œuvre ne sont pas obligées de prendre en charge cette caractéristique.

-	Le modèle de qualité de service pour le relais de trame traditionnel peut être émulé ; cependant, ceci sort du domaine d'application du présent document.

-	Un PW en mode d'accès de relais de trame ne traite pas les messages d'état de relais de trame ni les alarmes comme décrit dans [Q.922] [Q.933].

-	Les bits BECN et FECN de relais de trame sont transparents au réseau MPLS et ne peuvent pas refléter l'état du réseau MPLS.

-	La prise en charge des SVC de relais de trame et des circuits virtuels commutés permanents (SPVC, Switched Permanent Virtual Circuit) sort du domaine d'application du présent document.

-	L'interface de gestion locale (LMI, Local Management Interface) de relais de trame est terminée en local dans le PE connecté au circuit de rattachement de relais de trame.

-	La prise en charge de la vérification d'intégrité de liaison PVC sort du domaine d'application du présent document.

 	6.	Méthode générale d'encapsulation

Le format général de paquet de pseudo-filaire en relais de trame pour porter les informations de relais de trame (information de charge utile d'utilisateur et informations de contrôle de relais de trame) entre deux PE est montré à la Figure 2.

              +-------------------------------+
              |                               |
              |   En-tête de transport MPLS   |
              |       (comme nécessaire)      |
              +-------------------------------+
              | En-tête de pseudo-filaire (PW)|
              +-------------------------------+
              |      Mot de contrôle          |
              +-------------------------------+
              |     Charge utile de service   |
              |       de relais de trame      |
              +-------------------------------+

Figure 2. Format général d'encapsulation de relais de trame sur PSN

Le paquet PW comporte les champs suivants : mot de contrôle et charge utile, précédés par l'en-tête de transport MPLS et l'en-tête de pseudo-filaire. La signification des différents champs est la suivante :

-	L'en-tête de transport MPLS est spécifique du réseau MPLS. Cet en-tête est utilisé pour commuter le paquet PW à travers le cœur MPLS.

-	L'en-tête de PW contient un identifiant pour multiplexer les PW au sein d'un tunnel MPLS.

-	Le mot de contrôle contient les informations de contrôle du protocole pour fournir un service de relais de trame. Sa structure est donnée dans les sections qui suivent.

-	Le contenu du champ Charge utile de service de relais de trame dépend du mode de transposition. En général, il contient la trame de couche 2 de relais de trame.

 	7.	Relais de trame sur PSN MPLS pour le mode un à un
 	7.1	Tunnel et PW de PSN MPLS
Les chemins de commutation d'étiquettes (LSP, Label Switched Path) MPLS appelés des "tunnels MPLS" sont utilisés entre les PE et sont utilisés au sein du réseau de cœur de MPLS pour transmettre les paquets PW. Un tunnel MPLS correspond au "tunnel PSN" de la Figure 1.

Plusieurs PW peuvent être incorporés dans un tunnel MPLS. Chaque PW porte le trafic d'un seul VC de relais de trame. Dans ce cas, l'en-tête de PW est une étiquette MPLS appelée l'étiquette de PW.

 	7.2	Format de paquet sur PSN MPLS
Pour le mode de transposition de un à un pour le relais de trame sur un réseau MPLS, le format du paquet PW est celui montré à la Figure 3.

    +-------------------------------+
    |  Étiquettes de tunnel MPLS    | n*4 octets (quatre octets par étiquette)
    +-------------------------------+
    |   Étiquette de PW             |  4 octets
    +-------------------------------+
    |    Mot de contrôle            |
    |      (voir la Figure 4)       | 4 octets
    +-------------------------------+
    |       Charge utile            |
    |      (champ Informations      |
    |  de trame de relais de trame) | n octets
    |                               |
    +-------------------------------+

Figure 3. Paquet de PSN en relais de trame sur MPLS pour la transposition de un à un

La signification des différents champs est la suivante :

-	Étiquettes de tunnel MPLS   : cela correspond à l'en-tête de transport MPLS de la Figure 2. La ou les étiquettes sont utilisées par les LSR MPLS pour transmettre un paquet PW d'un PE à l'autre.

-	Étiquette de PW : elle identifie un PW (c'est-à-dire, un LSP) alloué à un VC de relais de trame dans une direction. Elle correspond à l'en-tête de PW de la Figure 2. La ou les étiquettes de tunnel MPLS et l'étiquette de PW forment ensemble une pile d'étiquettes MPLS [RFC3032].

-	Mot de contrôle : il contient les informations de contrôle du protocole. Sa structure est donnée à la Figure 4.

-	Charge utile : le champ Charge utile correspond au champ Informations de trame de relais de trame de X.36/X.76 sans les composants suivants : bourrage de bit/octet, en-tête de relais de trame, et FCS. Il est RECOMMANDÉ de prendre en charge une taille d'au moins 1600 octets. La longueur maximum du champ de charge utile DOIT être acceptée par les deux PE. Cela peut être réalisé en utilisant le paramètre MTU d'interface quand le PW est établi [RFC4447].

 	7.3	Mot de contrôle
Le mot de contrôle défini ci-dessous est EXIGÉ pour le mode de relais de trame un à un. Le mot de contrôle porte certaines informations spécifiques du relais de trame qui sont nécessaires pour régénérer la trame de relais de trame sur le PE de sortie. De plus, le mot de contrôle porte aussi un numéro de séquence qui peut être utilisé pour préserver la séquence quand du relais de trame est porté sur un réseau MPLS. Sa structure est 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|F|B|D|C|FRG| Longueur  | Numéro de séquence            |
+-------+-+-+-+-+---+-----------+---------------+---------------+

Figure 4. Structure du mot de contrôle pour le mode de transposition un à un

La signification des champs du mot de contrôle (Figure 4) est comme suit (voir aussi dans [X.36] et [X.76] les bits de relais de trame) :

- Bits 0 à 3  : dans le diagramme ci-dessus, les 4 premiers bits DOIVENT être réglés à 0 pour indiquer des données de PW.

- Bit F (bit 4)  : bit de notification d'encombrement explicite vers l'avant (FR FECN).

- Bit B (bit 5)  : bit de notification d'encombrement explicite vers l'arrière (FR BECN).

- Bit D (bit 6)  : bit d'éligibilité à la suppression (FR DE).

- Bit C (bit 7)  : bit de trame FR C/R (commande/réponse).

- Bits FRG (bits 8 et 9) : ces bits sont définis dans la [RFC4623].

-	Longueur (bits 10 à 15)  : si le PW traverse une liaison de réseau qui exige une taille de trame minimum (un exemple notable est Ethernet) un bourrage est requis pour atteindre la taille minimum de trame. Si la longueur de trame (définie comme la longueur de la charge utile de couche 2 plus la longueur du mot de contrôle) fait moins de 64 octets, le champ Longueur DOIT être réglé à la longueur de la charge utile du PW. Autrement, la champ Longueur DOIT être réglé à zéro. La valeur du champ Longueur, si elle n'est pas zéro, est utilisée pour supprimer les caractères de bourrage par le PE de sortie.

-	Numéro de séquence (bits 16 à 31)  : les numéros de séquence fournissent un mécanisme possible pour s'assurer de la livraison dans l'ordre des paquets de PW. Le traitement du champ Numéro de séquence est FACULTATIF. L'espace de numéros de séquence est un espace circulaire de 16 bis non signés. La valeur du numéro de séquence 0 est utilisée pour indiquer que l'algorithme de vérification de numéro de séquence n'est pas utilisé.

 	7.4	Mot de contrôle en mode Martini traditionnel
Pour la rétro compatibilité avec les mises en œuvre existantes, la version suivante de mot de contrôle est définie comme le "CW en mode Martini" pour le relais de trame.

 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|B|F|D|C|FRG| Longueur  | Numéro de séquence            |
+-------+-+-+-+-+---+-----------+---------------+---------------+

Figure 5. Structure de mot de contrôle pour le mode Martini de relais de trame

Noter que les bits "B" et "F" sont inversés.

Ce format de mot de contrôle est utilisé pour le type de PW "DLCI de relais de trame (mode Martini)"

 	7.5	Traitement du paquet PW
 	7.5.1	Encapsulation des trames de relais de trame
Le processus d'encapsulation d'une trame de relais de trame est initié quand un PE reçoit une trame de relais de trame provenant d'une de ses interfaces UNI ou NNI de relais de trame [FRF1], [FRF2]. Le PE génère les champs suivants du mot de contrôle provenant des champs correspondants de la trame de relais de trame comme suit :

-	Bit Commande/réponse (C/R ou C) : le bit C est copié inchangé dans le mot de contrôle de PW.

-	Le bit DE de la trame de relais de trame est copié dans le champ du bit D. Cependant, si le bit D n'est pas déjà établi, il PEUT être réglé conformément à la politique de trame d'entrée. Si il n'est pas déjà établi par l'opération de copie, l'établissement de ce bit par un PE est FACULTATIF. Le PE NE DOIT PAS changer ce bit (le régler à 0 si il a été reçu avec la valeur de 1).

- 	Le bit FECN de la trame de relais de trame est copié dans le champ Bit F. Cependant, si le bit F n'est pas déjà établi, il PEUT être établi pour refléter une situation d'encombrement détectée par le PE. Si il n'est pas déjà établi par l'opération de copie, l'établissement de ce bit par un PE est FACULTATIF. Le PE NE DOIT PAS changer ce bit (le régler à 0 si il a été reçu avec la valeur de 1).

-	Le bit BECN de la trame de relais de trame est copié dans le champ Bit B. Cependant, si le bit B n'est pas déjà établi, il PEUT être établi pour refléter une situation d'encombrement détectée par le PE. Si il n'est pas déjà établi par l'opération de copie, l'établissement de ce bit par un PE est FACULTATIF. Le PE NE DOIT PAS changer ce bit (le régler à 0 si il a été reçu avec la valeur de 1).

-	Si la longueur de paquet PW (définie comme la longueur de la charge utile plus la longueur du mot de contrôle) est de moins de 64 octets, le champ Longueur DOIT être réglé à la longueur du paquet. Autrement, le champ Longueur DOIT être réglé à zéro.

-	Le champ Numéro de séquence est traité si le PW utilise des numéros de séquence [RFC4385].

-	La charge utile du paquet de PW est le contenu du champ Informations de trame de relais de trame des Recommandations UIT-T [X.36]/[X.76] d'où tout bourrage de bit ou octet a été supprimé.

 	7.5.2	Réglage du numéro de séquence
Pour un certain PW et une paire de routeurs PE1 et PE2, si PE1 prend en charge le séquençage de paquets, alors les procédures du paragraphe 4.1 de la [RFC4385] DOIVENT être appliquées.

 	7.6	Désencapsulation des paquets PW
Quand un PE reçoit un paquet de PW, il traite les différents champs du mot de contrôle afin de désencapsuler la trame de relais de trame pour sa transmission à un CE sur une UNI ou NNI de relais de trame. Le PE effectue les actions suivantes (pas nécessairement dans cet ordre) :

-	Il génère les champs d'en-tête de trame de relais de trame suivants provenant des champs correspondants du paquet de PW.

-	Le bit C/R DOIT être copié dans l'en-tête de relais de trame.

-	Le bit D DOIT être copié dans le bit DE de l'en-tête de relais de trame.

-	Le bit F DOIT être copié dans le bit FECN de l'en-tête de relais de trame. Si le bit F est réglé à zéro, le bit FECN peut être réglé à un, selon l'état d'encombrement de l'appareil de PE dans la direction vers l'avant. Changer l'état de ce bit par un PE est FACULTATIF.

-	Le bit B DOIT être copié dans le bit BECN de l'en-tête de relais de trame. Si le bit B est réglé à zéro, le bit BECN peut être réglé à un, selon l'état d'encombrement de l'appareil de PE dans la direction vers l'arrière. Changer l'état de ce bit par un PE est FACULTATIF.

-	Il traite les champs Longueur et Séquence, dont les détails sont dans les sous paragraphes suivants.

-	Il copie le champ Informations de relais de trame du contenu de la charge utile du paquet PW après avoir supprimé tout bourrage.

Une fois que les champs ci-dessus d'une trame FR ont été traités, les opérations standard HDLC sont effectuées sur la trame de relais de trame : l'en-tête HDLC est ajouté, tout bourrage de bit ou octet est jouté comme requis, et la FCS est aussi ajoutée à la trame. La trame FR est alors mise en file d'attente pour transmission sur l'interface UNI ou NNI de relais de trame choisie.

 	7.6.1	Traitement du numéro de séquence
Si un routeur PE2 prend en charge le traitement des numéros de séquence reçus, les procédures du paragraphe 4.2 de la [RFC4385] DOIVENT alors être utilisées.

 	7.6.2	Traitement du champ Longueur par le receveur
Tout octet de bourrage, si il en est de présent, dans le champ Charge utile d'un paquet de PW reçu DOIT être retiré avant de transmettre les données.

-	Si le champ Longueur est réglé à zéro, alors il n'y a pas d'octets de bourrage qui suivent le champ Charge utile.

-	Autrement, si la charge utile est plus longue, la longueur spécifiée dans les caractères de bourrage du mot de contrôle est retirée en accord avec le champ Longueur.

 	7.7	Valeurs du bit EXP d'ajustement MPLS
Si il est désiré porter des informations de qualité de service, les informations de qualité de service DEVRAIENT être représentées dans le champ Bits d'utilisation expérimentale (EXP) de l'étiquette MPLS du PW [RFC3032]. Si plus d'une étiquette MPLS est imposée par le LSR d'entrée, le champ EXP de toute étiquette plus haute dans la pile DEVRAIT aussi porter la même valeur.

 	7.8	Valeur du bit S d'ajustement MPLS
Le LSR d'entrée, PE1, DOIT régler le bit S de l'étiquette de PW à une valeur de 1 pour noter que l'étiquette de PW est au bas de la pile.

 	7.9	Détails du plan de contrôle pour le service de relais de trame
Le PE DOIT fournir au réseau de relais de trame la signalisation de l'état du PVC de relais de trame. Si le PE détecte une condition affectant le service pour un DLCI particulier, comme défini à l'annexe A.5 de [Q.933], situé dans IA FRF1.1, le PE DOIT communiquer au PE distant l'état du PW qui correspond à l'état DLCI du relais de trame. Le PE de sortie DEVRAIT générer les erreurs et alarmes correspondantes comme défini dans [Q.922]/[Q.933] sur le PVC de relais de trame de sortie.

Deux transpositions de fanions de relais de trame en bits de mot de contrôle sont décrites ci-dessous. Le schéma d'ordre des bits traditionnel va être utilisé pour un PW de type 0x0001, "DLCI de relais de trame (mode Martini)", et le nouveau schéma d'ordre des bits va être utilisé pour un PW de type 0x0019, "DLCI de relais de trame". Le registre d'allocation de l'IANA de "Type de pseudo-filaire" est défini dans la [RFC4446] avec les valeurs initiales allouées.

 	7.9.1	Sous TLV Paramètre d'interface spécifique de relais de trame
Un document séparé [RFC4447], décrit en détails le protocole de contrôle et maintenance de PW, incluant les sous TLV génériques de paramètres d'interface. Les informations de paramètres d'interface, quand applicables, DOIVENT être utilisées pour valider que les PE et les accès d'entrée et de sortie aux bords du circuit ont les capacités nécessaires pour interopérer les uns avec les autres. La TLV Paramètre d'interface est définie dans la [RFC4447], et le registre de l'IANA avec les valeurs initiales des types de sous TLV de paramètre d'interface est défini dans la [RFC4446], mais les types de sous TLV de paramètre d'interface spécifiques du relais de trame sont spécifiés comme suit :

- 0x08  : Sous TLV Longueur d'en-tête de relais de trame

Une valeur facultative de 16 bits indiquant la longueur de l'en-tête FR, exprimée en octets. Ce sous TLV FACULTATIF de paramètre d'interface peut avoir une valeur de 2, 3, ou 4, 2 par défaut. Si ce sous TLV n'est pas présent, la valeur par défaut de 2 est supposée.

 	8.	Mode d'accès de relais de trame

Le PW de relais de trame en mode accès partage la même encapsulation que le PW HDLC et est décrit dans la [RFC4618].

 	9. 	Contrôle d'encombrement

Comme expliqué dans la [RFC3985], le PSN qui porte le PW peut être soumis à l'encombrement, dont les caractéristiques dépendent du type de PSN, de l'architecture réseau, de la configuration, et de la charge. Durant l'encombrement, le PSN peut subir des pertes de paquets qui vont impacter le service porté par le PW de relais de trame. De plus, comme le PW de relais de trame porte divers services à travers le PSN, incluant mais sans s'y restreindre, TCP/IP, il peut ou non se comporter de la manière favorable à TCP prescrite par la [RFC2914]. En présence de services qui réduisent le taux de transmission, les PW de relais de trame peuvent donc consommer plus que leur juste part et dans ce cas, ils DEVRAIENT être arrêtés.

Chaque fois que possible, le PW de relais de trame devrait 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 qui fournissent le service garanti (GS) ou les domaines à capacité DiffServ qui utilisent la transmission assurée (EF, expedited forwarding) sont des exemples de PSN à ingénierie du trafic. De tels PSN vont minimiser la perte et le délai tout en fournissant un certain degré d'isolation des effets du PW de relais de trame sur les flux du voisinage.

Noter que quand ils transportent du relais de trame, les domaines à capacité DiffServ peuvent utiliser la transmission assurée (AF, Assured Forwarding) et/ou la transmission par défaut (DF, Default Forwarding) au lieu de EF, afin de faire peser une moindre charge sur le réseau et gagner un avantage de multiplexage statistique supplémentaire. En particulier, si le débit d'informations garanti (CIR, Committed Information Rate) d'un VC de relais de trame est zéro, il est alors équivalent à un flux UDP sur IP au mieux à l'égard de l'encombrement : le réseau est libre d'éliminer des trames comme nécessaire. Dans ce cas, le comportement par bond (PHB, Per Hop Behavior) "DF" va être approprié dans un domaine TE DiffServ. Autrement, si le CIR d'un VC de relais de trame est non zéro et si le bit DE est zéro dans l'en-tête FR, alors "AF31" va être approprié, et si le CIR d'un VC de relais de trame est non zéro mais si le bit DE est établi, alors "AF32" va être approprié [RFC3270].

Les PE DEVRAIENT surveiller l'encombrement (en utilisant la notification explicite d'encombrement, [RFC5085], ou en mesurant la perte de paquet) afin de s'assurer que le service utilisant le PW de relais de trame peut être conservé. Quand un PE détecte un encombrement significatif lorsque il reçoit les PDU de PW, les bits BECN de la trame de relais de trame transmis sur le même PW DEVRAIENT être réglés à notifier au PE distant et au commutateur de relais de trame distant la situation d'encombrement. De plus, les bits FECN DEVRAIENT être établis dans les trames FR envoyées sur le circuit de rattachement, pour donner au DTE FR une chance d'ajuster, si possible, sa fenêtre de couche transport annoncée.

Si le PW a été établi en utilisant le protocole défini dans la [RFC4447], alors les procédures spécifiées dans la [RFC4447] pour la notification d’état peuvent être utilisées pour désactiver la transmission de paquet sur le PE d'entrée à partir du PE de sortie. Le PW peut être redémarré par une intervention manuelle, ou par des moyens automatiques après un temps d'attente approprié.

 	10.	Considérations sur la sécurité

PWE3 ne fournit aucun moyen pour protéger les contenus ou la livraison des paquets de PW au nom du service natif. PWE3 peut, cependant, déployer les mécanismes de sécurité fournis par la couche Tunnel MPLS. Une discussion plus détaillée de la sécurité de PW est donnée dans les [RFC3985], [RFC4447], [RFC3916].

 	11.	Références normatives

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.

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

[RFC4618]	L. Martini et autres, "Méthodes d'encapsulation pour le transport du contrôle de liaisons de données en PPP/haut-niveau (HDLC) sur réseaux MPLS", septembre 2006. (P.S.)

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

 	12.	Références pour information

[FRF1]	FRF.1.2, "Frame relay PVC UNI Implementation Agreement", Frame Relay Forum, avril 2000.

[FRF2]	FRF.2.2, "Frame relay PVC UNI Implementation Agreement", Frame Relay Forum, avril 2002

[Q.922]	Recommandation UIT-T Q.922 "Spécification du contrôle d'appel de base en mode trame", Genève 1995

[Q.933]	Recommandation UIT-T Q.933 " Spécification du contrôle d'appel de base en mode trame", Genève 2003

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

[RFC3270]	F. Le Faucheur et autres, "Prise en charge des services différenciés par la commutation d'étiquettes multi-protocoles (MPLS)", mai 2002. (P.S.)

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

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

[RFC4448]	L. Martini et autres, "Méthodes d'encapsulation pour le transport d'Ethernet sur des réseaux MPLS", avril 2006. (P.S. ; MàJ par RFC8469)

[RFC4717]	L. Martini et autres, "Méthodes d'encapsulation pour le transport de mode de transfert asynchrone (ATM) sur réseaux MPLS", décembre 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) 

[X.36]	Recommandation UIT-T X.36, "Interface entre DTE et DCE pour réseaux publics de données fournissant des services de relais de trame", Genève, 2000.

[X.76]	Recommandation UIT-T X.76, "Interface de réseau à réseau entre réseaux publics de données fournissant des services de relais de trame", Genève, 2000

 	Informations sur les auteurs contributeurs

Kireeti Kompella	Giles Heron	Rao Cherukuri	Dimitri Stratton Vlachos	
Juniper Networks	Tellabs, Abbey Place	Juniper Networks	Mazu Networks, Inc.	
1194 N. Mathilda Ave	24-28 Easton Street	1194 N. Mathilda Ave	125 Cambridgepark Drive	
Sunnyvale, CA 94089	High Wycombe, Bucks, UK	Sunnyvale, CA 94089	Cambridge, MA 02140	
mél : kireeti@juniper.net 	mél : giles.heron@tellabs.com 		mél : d@mazunetworks.com 	

Chris Liljenstolpe	Nasser El-Aawar	Eric C. Rosen	
Alcatel	Level 3 Communications, LLC.	Cisco Systems, Inc.	
11600 Sallie Mae Dr.	1025 Eldorado Blvd.	1414 Massachusetts Avenue	
Reston, VA 20193	Broomfield, CO, 80021	Boxborough, MA 01719	
mél : chris.liljenstolpe@alcatel.com 	mél : nna@level3.net 	mél : erosen@cisco.com 	

Dan Tappan	Prayson Pate	Steve Vogelsang	
Cisco Systems, Inc.	Overture Networks, Inc.	ECI Telecom	
1414 Massachusetts Avenue	507 Airport Boulevard	1300 Omega Drive	
Boxborough, MA 01719	Morrisville, NC, USA 27560	Pittsburgh, PA 15205	
mél : tappan@cisco.com 	prayson.pate@overturenetworks.com 	mél : stephen.vogelsang@ecitele.com 	

Vinai Sirkay	David Sinicrope	Ravi Bhat	Nishit Vasavada	
Redback Networks	Ericsson IPI	Nokia	Nokia	
300 Holger Way,	david.sinicrope@ericsson.com 	mél : ravi.bhat@nokia.com 	nishit.vasavada@nokia.com 	
San Jose, CA 95134				
sirkay@technologist.com 				

 	Adresse des éditeurs

Luca Martini	Claude Kawa	Andrew G. Malis	
Cisco Systems, Inc.	OZ Communications	Tellabs	
9155 East Nichols Avenue, Suite 400	Windsor Station	1415 West Diehl Road	
Englewood, CO, 80112	1100, de la Gauchetière St West	Naperville, IL  60563	
mél : lmartini@cisco.com 	Montréal QC H3B 2S2 Canada	mél : Andy.Malis@tellabs.com 	
	mél : claude.kawa@oz.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.