Groupe de travail Réseau L. Martini, éd.,Cisco Systems	L. Martini, éd., Cisco Systems	
Request for Comments : 4618	E. Rosen, Cisco Systems	
Catégorie : Sur la voie de la normalisation	A. Malis, éd., Tellabs	
Traduction Claude Brière de L'Isle	G. Heron, Tellabs	
	septembre 2006	

Méthodes d'encapsulation pour le transport de PPP/HDLC 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 (PW, pseudowire) peut être utilisé pour porter des unités de données de protocole (PDU, Protocol Data Unit) du protocole point à point (PPP, Point to Point Protocol) ou de contrôle de liaison de données de niveau supérieur (HDLC, High-Level Data Link Control) sur un réseau de commutation d'étiquettes multi-protocoles (MPLS, Multiprotocol Label Switching) sans terminer le protocole PPP/HDLC. Cela permet aux fournisseurs de service d'offrir des services de liaisons "émulées" HDLC ou PPP sur des réseaux MPLS existants. Le présent document spécifie l'encapsulation des PDU PPP/HDLC dans un pseudo-filaire.
Table des matières
1. Introduction	1
2. Spécification des exigences	2
3. Déclaration d'applicabilité	3
4. Méthode générale d'encapsulation	4
4.1 Mot de contrôle	4
4.2 Exigences de MTU	5
5. Détails spécifiques du protocole	5
5.1 HDLC	5
5.2 Mode d'accès de relais de trame	6
5.3 PPP	6
6. Utilisation d'une étiquette MPLS comme champ de démultiplexeur	7
6.1 Valeurs de bit EXP factice MPLS	7
6.2 Valeur de bit S factice MPLS	7
7. Contrôle d'encombrement	7
8. Considérations relatives à l'IANA	7
9. Considérations sur la sécurité	8
10. Références normatives	8
11. Références pour information	8
Informations sur les auteurs contributeurs	8
Adresse des auteurs	9
Déclaration complète de droits de reproduction	9

 	1.	Introduction

Un pseud-filaire PPP/HDLC permet à des unités de données de protocole PPP/HDLC d'être portées sur un réseau MPLS. En traitant les problèmes associés au transport d'une PDU PPP/HDLC sur un réseau MPLS, le présent document suppose qu'un PW a été établi par des moyens qui sortent du domaine d'application de ce document. Cela peut être via configuration manuelle, ou en utilisant un protocole de signalisation comme celui défini dans la [RFC4447].

La figure suivante décrit les modèles de référence qui sont déduits de la [RFC3985] pour prendre en charge les services de PW émulé HDLC/PPP. Le lecteur est aussi supposé être familiarisé avec le contenu de la [RFC3985].

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

          |<-------------- Service émulé ------------------->|
          |                                                  |
          |          |<----- Pseudo-filaire ----->|          |
          |          |                            |          |
          |          |    |<-- Tunnel PSN -->|    |          |
          |          V    V                  V    V          |
          V   AC     +----+                  +----+    AC    V
    +-----+    |     | PE1|==================| PE2|     |    +-----+
    |     |----------|............PW1.............|----------|     |
    | CE1 |    |     |    |                  |    |     |    | CE2 |
    |     |----------|............PW2.............|----------|     |
    +-----+  ^ |     |    |==================|    |     | ^  +-----+
          ^  |       +----+                  +----+     | |  ^
          |  |  Bord fournisseur 1    Bord fournisseur 2  |  |
          |  |                                            |  |
    Bord     |                                            | Bord client 2
   client 1  |                                            |
             |                                            |
             |                                            |
       service natif HDLC/PPP                   service natif HDLC/PPP

Figure 1. Configuration de référence d'interface PWE3 HDLC/PPP

Le présent document spécifie l'encapsulation de PW émulé pour PPP et HDLC ; cependant, les questions relatives à la qualité de service ne sont pas discutées dans ce document. Pour les besoins de l'exposé de ce document, PE1 est défini comme le routeur d'entrée et PE2 comme le routeur de sortie. Une PDU de couche 2 va être reçue à PE1, encapsulée à PE1, transportée sur le réseau, désencapsulée à PE2, et transmise sur un circuit de rattachement à PE2.

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|  |     |  |PW ter|  |      |  |P|
        |   |<==|h|<=| NSP |<=|minais|<=|Tunnel|<=|h|<== du PSN
        |   |   |y|  |     |  |on    |  |  PSN |  |y|
        | C |   +-+  +-----+  +------+  +------+  +-+
        | E |   |                                   |
        |   |   +-+  +-----+  +------+  +------+  +-+
        |   |   |P|  |     |  |PW ter|  |      |  |P|
        |   |==>|h|=>| NSP |=>|minais|=>|Tunnel|=>|h|==> vers le PSN
        |   |   |y|  |     |  |on    |  |  PSN |  |y|
        +---+   +-+  +-----+  +------+  +------+  +-+
                |                                   |
                +-----------------------------------+
                        ^        ^          ^
                        |        |          |
                        A        B          C
Figure 2. Diagramme de référence de PW

Le PW se termine sur un accès logique au sein du PE, défini au point B du diagramme. Cet accès donne une fonction de traitement de service natif HDLC qui va livrer chaque paquet PPP/HDLC reçu au point A, non altéré, 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 paquet qui est exigé pour les paquets PPP/HDLC qui sont transmis au point de terminaison de PW. De telles fonctions peuvent inclure le bourrage de bits, le pontage de PW à PW, l'encapsulation de couche 2, le formatage, et la régulation. Ces fonctions sont spécifiques de la technologie native de paquet et peuvent n'être pas requises pour le service d'émulation de PW.

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

"Terminaison de PW", entre A et B, représente les opérations pour établir et maintenir le PW, et pour encapsuler et désencapsuler les paquets PPP/HDLC comme nécessaire pour les transmettre à travers le réseau MPLS.

 	3.	Déclaration d'applicabilité

Le tansport de PPP/HDLC sur le service de PW n'est pas destiné à émuler parfaitement le service traditionnel PPP ou HDLC, mais il peut être utilisé pour certaines applications qui requièrent le service de transport PPP ou HDLC.

Les déclarations d'applicabilité de la [RFC4619] s'appliquent aussi au PW en mode accès de relais de trame décrit dans ce document.

Les différences notables entre le service traditionnel PPP/HDLC et le protocole décrit dans le présent document sont :

-	L'ordre des paquets peut être préservé en utilisant le champ Séquence facultatif 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 les liaisons PPP/HDLC traditionelles peut être émulé, mais cela sort du domaine d'application de ce document.

-	Un PW en mode accès de relais de trame, ou PW HDLC, ne traite aucun message d'état de relais de trame ni d'alarmes comme décrit dans [Q.922] [Q.933].

-	Les fanions HDLC sont traités en local par le PE connecté au circuit de rattachement.

Le mode HDLC convient pour le transport d'accès à accès de trafic d'interface réseau d'utilisateur (UNI, User Network Interface) ou d'interface de nœud de réseau (NNI, Network Node Interface) de relais de trame. Comme tous les paquets sont passés de manière largement transparente sur le PW HDLC, tout protocole qui a un tramage de style HDLC peut utiliser le mode PW HDLC, incluant PPP, le relais de trame, et X.25. Les exceptions incluent des cas où l'accès direct à l'interface HDLC est requis, ou les modes qui opèrent sur les fanions, la séquence de vérification de trame (FCS, Frame Check Sequence) ou le débourrage de bit/octet qui est effectué avant d'envoyer la PDU HDLC sur le PW. Un exemple de cela est la négociation PPP de transposition de caractère de contrôle asynchrone (ACCM, Asynchronous-Control-Character-Map).

Pour PPP, comme le tramage spécifique du support n'est pas transporté, les options suivantes ne vont pas fonctionner correctement si les homologues PPP tentent de les négocier :
- Solutions de remplacement à la séquence de vérification de trame (FCS)
- Compression d'adresse et de champ de contrôle (ACFC, Address-and-Control-Field-Compression)
- Transposition de caractère de contrôle asynchrone (ACCM, Asynchronous-Control-Character-Map)

Noter aussi que la négociation de MTU d'interface de LSP de PW, comme elle est spécifiée dans la [RFC4447], n'est pas affectée par l'annonce d'unité de réception maximum (MRU, Maximum Receive Unit) de PPP. Donc, si un homologue PPP envoie une PDU d'une longueur qui excède celle négociée pour le tunnel de PW, cette PDU va être éliminée par le routeur d'entrée

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

Cette section décrit le format général d'encapsulation pour les paquets PPP et HDLC sur des pseudo-filaires MPLS.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            En-tête de transport de PSN (comme nécessaire)     |
+---------------+---------------+---------------+---------------+
|                  En-tête de pseudo-filaire                    |
+---------------+---------------+---------------+---------------+
|                  Mot de contrôle                              |
+---------------+---------------+---------------+---------------+
|               Charge utile de service PPP/HDLC                |
+---------------+---------------+---------------+---------------+

Figure 3. Format général pour encapsulation PPP/HDLC sur des PSN

L'en-tête de transport de PSN dépend de la technologie particulière de tunnelage utilisée. Cet en-tête est utilisé pour transporter les informations PPP/HDLC encapsulées à travers le cœur de commutation de paquets.

L'en-tête de pseudo-filaire identifie un service particulier de PPP/HDLC sur un tunnel. Dans le cas de MPLS, l'en-tête de pseudo-filaire est l'étiquette MPLS au bas de la pile d'étiquettes MPLS.

Le mot de contrôle est inséré avant la charge utile de service PPP/HDLC. Il peut contenir une longueur et un numéro de séquence.

 	4.1	Mot de contrôle
Quatre exigences peuvent devoir être satisfaites lors du transport de protocoles de couche 2 sur un PSN MPLS :
i.	La séquencialité peut devoir être préservée.
ii.	Les petits paquets peuvent devoir être bourrés afin d'être transmis sur un support où l'unité de ttransport minimum est supérieure à la taille réelle du paquet.
iii.Les bits de contrôle portés dans l'en-tête du paquet de couche 2 peuvent devoir être transportés.
iv.	La création d'un canal associé dans la bande pour les communications d'opération et maintenance.

Le mot de contrôle défini dans cette section 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 paquets individuels sur le PW et d'éviter l'équilibrage de charge de chemins multiple de coût égal (ECMP, equal-cost multiple-path load-balancing) [RFC2992] et permet des mécanismes d'opération et de gestion (OAM, Operations and Management) incluant [VCCV].

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 contenu du paquet étiqueté est IP. Donc, si le numéro de protocole PPP d'un paquet PPP porté sur le PW sans la présence d'un mot de contrôle commence par 0x4 ou 0x6, il pourrait être pris 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 désordre des paquets sur un certain PW ou faire que les paquets OAM suivent un chemin différent de celui du trafic réel.

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

Dans tous les cas, le PE de 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 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|0 0 0 0|FRG| Longueur  |   Numéro de séquence          |
+-------+-------+---+-----------+---------------+---------------+

Figure 4. Mot de contrôle de PWE3 MPLS

Dans le diagramme ci-dessus, les quatre premiers bits sont réglés à 0 pour indiquer un mot de contrôle (CW, Control Word)  [RFC4385].

Les quatre 4 bits suivants donnent un espace pour porter des fanions spécifiques du protocole. Ils ne sont pas utilisés pour HDLC/PPP, et ils DOIVENT être réglés à 0 à l'émission et DOIVENT être ignorés à réception.

Les 2 bits suivants sont définis dans la [RFC4623].

Les 6 bits suivants donnent un champ Longueur, qui est utilisé comme suit : si la longueur du paquet (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 du paquet. Autrement, le 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 tout bourrage qui aurait pu être ajouté par le réseau MPLS. Si le mot de contrôle est utilisé et si du bourrage a été ajouté au paquet dans le transit sur le réseau MPLS, alors quand le paquet atteint le PE de sortie, le bourrage DOIT être supprimé avant la transmission du paquet.

Les 16 bits suivants fournissent un numéro de séquence qui peut être utilisé pour garantir une livraison ordonnée des paquets. Le traitement du champ Numéro de séquence est FACULTATIF [RFC4385].

L'espace de numéro 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 un paquet sans numéro de séquence [RFC4385].

Les procédures décrites à la Section 4 de la [RFC4385] DOIVENT être suivies pour traiter le champ Numéro de séquence.

 	4.2	Exigences de MTU
Le réseau DOIT être configuré avec une MTU suffisante pour transporter les plus grands paquets encapsulés. Quand MPLS est utilisé comme protocole de tunnelage, par exemple, cela sera probablement supérieur de 12 octets ou plus que la plus grande taille de paquet. La méthodologie décrite dans la [RFC4623] PEUT être utilisée pour fragmenter les paquets encapsulés qui excèdent la MTU du PSN. Cependant, si la [RFC4623] n'est pas utilisée, alors si le routeur d'entrée détermine qu'une PDU encapsulée de couche 2 excède la MTU du tunnel de PSN à travers lequel elle doit être envoyée, la PDU DOIT être éliminée.

Si un paquet qui excède la valeur de la sous TLV MTU d'interface [RFC4447] est reçu sur le circuit de rattachement, il DOIT être éliminé. Il est aussi RECOMMANDÉ que les appareils PPP soient configurés à ne pas négocier de MRU PPP supérieures à la MTU du circuit de rattachement.

 	5.	Détails spécifiques du protocole
 	5.1	HDLC
Le mode HDLC fournit le transport d'accès à accès du trafic encapsulé dans HDLC. La PDU HDLC est transportée dans sa totalité, incluant les champs d'adresse et de contrôle HDLC, mais excluant les fanions HDLC et la FCS. Le bourrage de bit/octets est défait. Si le mot de contrôle FACULTATIF est utilisé, alors les bits de fanions dans le mot de contrôle ne sont pas utilisés et DOIVENT être réglés à 0 à l'émission et DOIVENT être ignorés à réception.

Quand le PE détecte un changement d'état dans l'état du circuit de rattachement, comme une défaillance de liaison physique du circuit de rattachement, ou si le AC est désactivé administrativement, le PE DOIT envoyer le message approprié de notification d'état de PW qui correspond à l'état d'AC HDLC. De façon similaire, l'état du PW local DOIT aussi être reflété dans un message de notification d'état de PW, comme décrit dans la [RFC4447].

Le PW de type 0x0006 "HDLC" sera utilisé pour transporter les paquets HDLC. Le registre d'allocation de l'IANA de "Type de pseudo-filaire" est défini dans le document d'allocations de l'IANA pour les PW [RFC4446] avec les valeurs initiales allouées.

 	5.2	Mode d'accès de relais de trame
La Figure 5 illustre le concept de mode d'accès de relais de trame ou de transposition de plusieurs à un, qui est une capacité FACULTATIVE.

La Figure 5a montre deux appareils de relais de trame physiquement connectés à une UNI ou NNI de relais de trame. Entre leurs deux accès, P1 et P2, n circuits virtuels (VC, Virtual Circuit) de relais de trame sont configurés.

La Figure 5b montre le remplacement de l'interface physique de relais de trame par une paire de PE et un PW entre eux. L'interface entre un appareil de relais de trame (FR, Frame Relay) et un PE est soit une UNI FR soit une NNI FR. Tous les VC FR portés sur l'interface sont transposés en un PW HDLC. Les procédures standard d'interface de gestion de liaison (LMI, Link Management Interface) de relais de trame se produisent directement entre les CE. Donc, avec le mode accès, on a une transposition de plusieurs à un entre les VC FR et un PW.

           +--------+                          +--------+
           |Appareil|                          |Appareil|
           |   FR   |         UNI/NNI FR       |  FR    |
           |     [P1]------------------------[P2]       |
           |        |     portant n VC FR      |        |
           +--------+                          +--------+
                 [Pn]: accès A

Figure 5a. Interface de FR entre deux appareils de FR

                      |<---------------------------->|
                      |                              |
                       +----+                  +----+
   +--------+          |    |     Un PW        |    |         +--------+
   |        |          |    |==================|    |         |        |
   |Appareil| UNI/NNI  | PE1| portant n VC FR  | PE2| UNI/NNI |Appareil|
   |  FR    |----------|    |                  |    |---------|  FR    |
   |  CE1   |   FR     |    |                  |    |   FR    |  CE2   |
   +--------+          +----+                  +----+         +--------+
           |                                                   |
           |<------------------------------------------------->|
                                   n FR VCs

Figure 5b. Pseudo-filaires remplaçant l'interface FR

Les VC FR ne sont pas visibles individuellement à un PE ; il n'y a pas de configuration de VC FR individuel dans un PE. Un PE traite l'ensemble des VC FR alloués à un accès comme un agrégat.

Le mode accès de FR fournit le transport entre deux PE d'une trame FR complète en utilisant la même encapsulation que décrit ci-dessus pour le mode HDLC.

Bien que le mode accès de relais de trame partage la même encapsulation que le mode HDLC, un type de PW différent est alloué dans la [RFC4446] : 0x000F Mode accès de relais de trame.

Tous les autres aspects de ce type de PW sont identiques à l'encapsulation de PW HDLC décrite précédemment.

 	5.3	PPP
Le mode PPP fournit un transport en point à point du trafic encapsulé PPP, comme spécifié dans la [RFC1661]. La PDU PPP est transportée dans sa totalité, incluant le champ Protocole (compressé ou non en utilisant la compression de champ de protocole) mais excluant toutes les informations de tramage spécifiques du support, comme les champs Adresse et contrôle HDLC ou FCS.

Si le mot de contrôle FACULTATIF est utilisé, alors les bits de fanions dans le mot de contrôle ne sont pas utilisés et DOIVENT être réglés à 0 à l'émission et DOIVENT être ignorés à réception.

Quand le PE détecte un changement d'état dans l'état du circuit de rattachement, comme une défaillance de liaison physique du circuit de rattachement, ou si le AC est désactivé administrativement, le PE DOIT envoyer le message approprié de notification d'état de PW qui correspond à l'état d'AC PPP. Noter que l'état de négociation PPP est transparent au PW et NE DOIT PAS être communiqué au PE MPLS distant. De façon similaire, l'état du PW local DOIT aussi être reflété dans un message de notification d'état de PW, comme décrit dans la [RFC4447].

Un PW de type 0x0007 "PPP" sera utilisé pour transporter des paquets PPP.

Le registre d'allocation de l'IANA de "Type de pseudo-filaire" est défini dans le document d'allocations de l'IANA pour les PW [RFC4446] avec les valeurs initiales allouées.

 	6.	Utilisation d'une étiquette MPLS comme champ de démultiplexeur

Pour utiliser une étiquette MPLS comme champ de démultiplexeur, une entrée de pile d'étiquettes de 32 bits [RFC3032] est simplement ajoutée devant l'encapsulation d'émulation de PW comme étiquette du bas de la pile d'étiquettes MPLS. Cette étiquette peut être appelée "étiquette de PW". L'émulation de PW particulière identifiée par une valeur particulière d'étiquette doit être acceptée par les LSR d'entrée et de sortie, soit par la signalisation (par exemple, via les méthodes de la [RFC4447]) soit par configuration. Les autres champs de l'entrée de pile d'étiquettes sont réglés comme décrit ci-dessous.

 	6.1	Valeurs de bit EXP factice MPLS
Si on désire porter des informations de qualité de service, les informations de qualité de service DEVRAIENT être représentées dans le champ EXP de l'étiquette de PW. Si plus d'une étiquette MPLS est imposée par le LSR d'entrée, le champ EXP de toutes les étiquettes qui sont plus haut dans la pile DOIT aussi porter la même valeur.

 	6.2	Valeur de bit S factice 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.	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 paquet qui vont impacter le service porté par le PW PPP/HLDC. De plus, comme le PW PPP/HLDC porte un type de service non spécifié à travers le PSN, il ne peut pas 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 PPP/HDLC vont donc consommer plus que leur juste part et ils DEVRAIENT être arrêtés.

Chaque fois que possible, les PW PPP/HDLC 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 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.

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 PPP/HDLC peut être conservé. Quand un encombrement significatif est détecté, le PW PPP/HDLC DEVRAIT être administrativement désactivé. 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é.

 	8.	Considérations relatives à l'IANA

Le présent document n'appelle pas à de nouvelles actions de l'IANA. Toutes les actions nécessaires de la part de l'IANA ont déjà été incluses dans la [RFC4446].

 	9.	Considérations sur la sécurité

Le type de pseudo-filaire PPP et HDLC est soumis aux considérations de sécurité générales discutées dans les [RFC3985][RFC4447]. Le présent document spécifie seulement les encapsulations, et non les protocoles qui peuvent être utilisés pour porter les paquets encapsulés à travers le réseau MPLS. Chacun de ces protocoles peut avoir son propre ensemble de problèmes de sécurité, mais ces problèmes ne sont pas affectés par les encapsulations spécifiées ici.

 	10.	Références normatives

[RFC1661]	W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)

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

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

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

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de pseudo filaire bord à bord (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)

[RFC4619]	L. Martini et autres, "Méthodes d'encapsulation pour le transport de relais de trames  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.)

 	11.	Références pour information

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

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

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

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

 	Informations sur les auteurs contributeurs

Yeongil Seo	Toby Smith	
463-1 KT Technology Lab	Laurel Networks, Inc.	
Jeonmin-dong Yusung-gu	Omega Corporate Center	
Daegeon, Korea	1300 Omega Drive	
mél : syi1@kt.co.kr 	Pittsburgh, PA 15205	
	mél : tob@laurelnetworks.com 	

 	Adresse des auteurs

Luca Martini	Eric C. Rosen	Andrew G. Malis	
Cisco Systems, Inc.	Cisco Systems, Inc.	Tellabs	
9155 East Nichols Avenue, Suite 400	1414 Massachusetts Avenue	1415 West Diehl Road	
Englewood, CO, 80112	Boxborough, MA 01719	Naperville, IL  60563	
mél : lmartini@cisco.com 	mél  : erosen@cisco.com 	mél : Andy.Malis@tellabs.com 	

Giles Heron
Tellabs
Abbey Place
24-28 Easton Street
High Wycombe
Bucks
HP11 1NT
UK
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.