Groupe de travail Réseau	S. Bryant, Cisco Systems	
Request for Comments : 4385	G. Swallow, Cisco Systems	
Catégorie : Sur la voie de la normalisation	L. Martini, Cisco Systems	
	D. McPherson, Arbor Networks	
Traduction Claude Brière de L'Isle	février 2006	

Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN 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é
Le présent document décrit la conception préférée pour l'utilisation d'un mot de contrôle d'émulation bord à bord de pseudo-filaire (PWE3, Pseudowire Emulation Edge-to-Edge) sur un réseau à commutation de paquets MPLS, et l'en-tête de canal de contrôle de pseudo-filaire associé. La conception de ces champs a été choisie de telle sorte qu'un routeur de commutation d'étiquettes MPLS qui effectue une inspection de charge utile MPLS ne confonde pas une charge utile PWE3 avec une charge utile IP.
Table des matières
1. Introduction	1
1.1 Terminologie	2
2. Éviter ECMP	2
3. Mot de contrôle générique de PW MPLS	2
4. Séquençage	3
4.1 Réglage du numéro de séquence	3
4.2 Traitement du numéro de séquence	3
5. Canal associé au PW	4
6 Considérations relatives à l'IANA	4
7. Considérations sur la sécurité	5
8. Remerciements	5
9. Références normatives	5
10. Références pour information	5
Appendice. Traitement du numéro de séquence	6
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

Les encapsulations standard MPLS n'ont pas d'identifiant explicite de protocole. Pour qu'un pseudo filaire (PW) [RFC3985] fonctionne correctement sur un réseau à commutation de paquet (PSN, packet switched network) MPLS qui effectue l'inspection de charge utile MPLS, un paquet de PW ne doit pas apparaître à un routeur de commutation d'étiquettes (LSR, label switching router) comme si il était un paquet IP [RFC4928]. Un exemple de LSR qui effectue l'inspection de charge utile MPLS est celui qui effectue un équilibrage de charge multi chemins de coût égal (ECMP, equal-cost multiple-path) [RFC2992]. Si ECMP a été effectué sur des paquets de PW, les paquets dans le PW peuvent ne pas suivre tous le même chemin à travers le PSN. Il peut en résulter une livraison désordonnée des paquets au PE de sortie. L'incapacité d'assurer que tous les paquets appartenant à un PW suivent le même chemin peut aussi empêcher les mécanismes d'opération et gestion (OAM, Operations and Management) [RFC5085] du PW de surveiller correctement le PW.

Le présent document spécifie comment le mot de contrôle de PW est utilisé pour distinguer une charge utile de PW d'une charge utile IP portée sur un PSN MPLS. Il décrit ensuite la conception préférée de mot de contrôle de PW à utiliser sur un PSN MPLS, et l'en-tête de canal associé de pseudo filaire.

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

 	2.	Éviter ECMP

Un PW porté sur un PSN MPLS qui utilise le contenu de la charge utile MPLS pour choisir le chemin ECMP peut subir un mauvais ordre des paquets [RFC4928]. Dans les cas où l'application qui utilise le PW est sensible au désordre des paquets, ou lorsque le désordre des paquets va perturber le fonctionnement du PW, il est nécessaire d'empêcher le PW d'être soumis à ECMP.

Tous les paquets IP [RFC0791], [RFC2460] commencent pas un numéro de version qui est vérifié par les LSR qui effectuent l'inspection de charge utile MPLS. Pour empêcher le traitement incorrect des paquets portés dans un PW, les paquets de PW portés sur un PSN MPLS NE DOIVENT PAS commencer par la valeur 4 (IPv4) ou la valeur 6 (IPv6) dans le premier quartet [RFC4928], car ils sont supposés porter des charges utiles IP normales.

Le présent document définit un en-tête de PW et deux formats généraux de cet en-tête. Ces deux formats sont le mot de contrôle de PW (PWMCW, PW MPLS Control Word) MPLS, qui est utilisé pour les données qui passent à travers le PW, et un en-tête de canal associé de PW (PWACH, PW Associated Channel Header) qui peut être utilisé pour des fonctions comme l'OAM.

Si le premier quartet d'un paquet de PW porté sur un PSN MPLS a une valeur de 0, cela indique que le paquet commence par un PWMCW. Si le premier quartet d'un paquet porté sur un PSN MPLS a une valeur de 1, il commence par un PWACH. L'utilisation de toute autre valeur d'un premier quarte pour un paquet de PW porté sur un PSN MPLS est déconseillée.

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. Un mécanisme convenable est le PWMCW décrit à la Section 3 pour les données, et le PWACH décrit à la Section 5 pour le trafic de canal associé.

Le PWMCW ou le PWACH DOIT suivre immédiatement le bas de la pile d'étiquette MPLS.

 	3.	Mot de contrôle générique de PW MPLS

Le mot de contrôle générique de PW (PWMCW, PW MPLS Control Word) MPLS est montré à la Figure 1.

 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|          Spécifié par l'encapsulation de PW           |
+-------+-------+---------------+---------------+---------------+

Figure 1 : Mot de contrôle générique de PW MPLS

Le protocole d'établissement de PW ou le mécanisme de configuration détermine si un PW utilise un PWMCW. Les bits 0 à 3 diffèrent des quatre premiers bits d'un paquet IP [RFC4928] et donc assurent la discrimination nécessaire de charge utile MPLS.

Quand un PWMCW est utilisé, il DOIT respecter le format générique illustré à la Figure 1. Pour assurer la cohérence entre le dessin des différents types de PW, il DEVRAIT aussi utiliser le format préféré suivant :

 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|Fanions|FRG| Longueur  | Numéro de séquence            |
+-------+-------+---+-----------+---------------+---------------+

Figure 2 : Mot de contrôle préféré de PW MPLS

La signification des champs du mot de contrôle préféré de PW MPLS (Figure 2) est comme suit :

Fanions (bits 4 à 7) : ces bits PEUVENT être utilisés pour la signalisation par charge utile. Leur sémantique DOIT être définie dans la spécification du PW.

FRG (bits 8 et 9) : ces bits sont utilisés lors de la fragmentation d'une charge utile de PW. Leur utilisation est décrite dans la [RFC4623]. Quand le PW est d'un type qui ne va jamais avoir besoin de fragmenter la charge utile, ces bits peuvent être utilisés comme fanions d'utilisation générale.

Longueur (bits 10 à 15) : quand le chemin du PSN entre les PE inclut un segment Ethernet, le paquet de PW qui arrive au PE lié au CE en provenance du PSN peut inclure du bourrage ajouté par la couche de liaison de données Ethernet. Le PE lié au CE utilise le champ Longueur pour déterminer la taille du bourrage ajouté par le PSN, et donc extrait la charge utile du PW du paquet de PW.
Si la charge utile MPLS fait moins de 64 octets, le champ Longueur DOIT être réglé à la longueur de la charge utile du PW plus la longueur du PWMCW. Autrement, il DOIT être réglé à zéro.

Numéro de séquence (bits 16 à 31) : le numéro de séquence met en œuvre la fonction de séquençage [RFC3985]. L'utilisation de ce champ est décrite à la Section 4.

 	4.	Séquençage

Le mécanisme de numéro de séquence est spécifique du PW. La spécification d'encapsulation de PW PEUT définir un mécanisme de numéro de séquence à utiliser, ou elle peut indiquer que le mécanisme décrit ici sera utilisé. Une description en pseudo code de ce mécanisme est donné dans l'Appendice non normatif.

Le mécanisme de numéro de séquence décrit ici utilise un espace circulaire de numéros de 16 bits non signés qui exclut la valeur zéro.

 	4.1	Réglage du numéro de séquence
Pour un PW donné, et une paire de routeurs PE1 et PE2, si PE1 supporte le séquençage de paquet et si le séquençage de paquet est activé pour le PW, les procédures suivantes DOIVENT alors être utilisées :
o	Le paquet initial transmis sur le PW DOIT être envoyé avec le numéro de séquence un.
o	Les paquets suivants DOIVENT incrémenter le numéro de séquence de un pour chaque paquet.
o	Le numéro de séquence qui suit 65535 (numéro maximum de 16 bits non signé) est un.

Si le routeur transmetteur PE1 ne prend pas en charge le traitement de numéro de séquence, ou si le séquençage de paquets est désactivé, le champ Numéro de séquence dans le mot de contrôle DOIT alors être réglé à zéro pour tous les paquets transmis sur le PW.

 	4.2	Traitement du numéro de séquence
Si un routeur PE2 prend en charge le traitement du numéro de séquence reçu, et si le séquençage de paquets est activé pour ce PW, la procédure suivante est alors utilisée :

Quand l'établissement d'un PW est initié, le "numéro de séquence attendu" qui lui est associé DOIT être initialisé à un.

Quand un paquet est reçu sur ce PW, le numéro de séquence DEVRAIT être traité comme suit :

o 	Si le numéro de séquence sur le paquet est zéro, l'intégrité de la séquence des paquets ne peut pas être déterminée. Dans ce cas, le paquet reçu est considéré comme étant dans l'ordre.

o	Autrement, si le numéro de séquence du paquet est égal au numéro de séquence attendu, le paquet est dans l'ordre.

o	Autrement, si le numéro de séquence du paquet est supérieur au numéro de séquence attendu, et si le numéro de séquence du paquet moins le numéro de séquence attendu est moins que 32768, le paquet est dans la fenêtre admise de numéro de séquence reçu. La mise en œuvre PEUT traiter le paquet comme dans l'ordre.

o	Autrement, si le numéro de séquence du paquet est inférieur au numéro de séquence attendu et si le numéro de séquence attendu moins le numéro de séquence du paquet est supérieur ou égal à 32768, le paquet est dans la fenêtre admise de numéro de séquence reçu. La mise en œuvre PEUT traiter le paquet comme dans l'ordre.

o	Autrement, le paquet n'est pas dans l'ordre. Si le paquet se trouve être dans l'ordre, il PEUT être livré immédiatement.

Si le numéro de séquence du paquet n'est pas zéro, alors le numéro de séquence attendu est réglé au numéro de séquence du paquet plus un. Le numéro de séquence attendu qui suit 65535 (numéro maximum de 16 bits non signé) est un.

Les paquets qui sont reçus hors ordre PEUVENT être soit éliminés soit réordonnés. Le choix entre l'élimination et la remise dans l'ordre des paquets hors séquence est à la discrétion du receveur.

Si un PE a négocié de ne pas utiliser le traitement du numéro de séquence reçu, et si il a reçu un numéro de séquence non zéro, il DEVRAIT alors envoyer un message d'état de PW indiquant une faute en réception, et désactiver le PW.

 	5.	Canal associé au PW

Pour certaines caractéristiques de PW, un canal associé est requis. Un canal associé est un canal qui est multiplexé dans le PW avec du trafic d'utilisateur, et suit donc le même chemin à travers le PSN que le trafic d'utilisateur. Noter que l'utilisation du terme "canal" n'est pas celle d'un "type de canal de PW" du paragraphe 5.1.2 de la [RFC3985].

Quand MPLS est utilisé comme PSN, le canal associé au PW (PWAC, PW Associated Channel) est identifié par l'en-tête suivant :

 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 1|Version|   Réservé     |        Type de canal          |
+-------+-------+---------------+---------------+---------------+

Figure 3 : En-tête de canal associé au PW

La signification des champs dans l'en-tête de canal associé au PW (PWACH, PW Associated Channel Header) (Figure 3) est :

Version : c'est le numéro de version du PWACH. La présente spécification définit la version 0.

Réservé : DOIT être envoyé à 0, et ignoré à réception.

Type de canal : le type de canal associé au PW est défini dans le registre IANA des types de canal associé au PW [RFC4446].

Les bits 0 à 3 DOIVENT être 0001. Cela permet que le paquet soit distingué d'un paquet IP [RFC4928] et d'un paquet de données de PW.

 	6	Considérations relatives à l'IANA

L'IANA a constitué un registre des "Types de canaux associés aux pseudo filaires". Ce sont des valeurs de 16 bits. Les entrées du registre sont allouées en utilisant la politique de "consensus de l'IETF" définie dans la [RFC2434]. La valeur 0x21 indique que le canal associé porte un paquet IPv4. La valeur 0x57 indique que le canal associé porte un paquet IPv6.

 	7.	Considérations sur la sécurité

Une application qui utilise un canal associé de PW doit savoir que le canal peut être mal utilisé. Toute application qui utilise le canal associé DOIT donc examiner attentivement les problèmes de sécurité qui en résultent, et fournir des mécanismes pour empêcher un attaquant de l'utiliser comme mécanisme pour perturber le fonctionnement du PW ou du PE, et arrêter l'utilisation de ce canal comme un conduit pour livrer les paquets ailleurs. Le choix d'un mécanisme de sécurité convenable pour une application qui utilise un canal associé de PW sort du domaine d'application de ce document.

Si un PW a été configuré à fonctionner sans un CW, le mécanisme de type de canal associé de PW décrit dans ce document NE DOIT PAS être utilisé. C'est pour empêcher les charges utiles d'utilisateur d'être falsifiées d'une façon telle qu'elles imitent l'en-tête de canal associé de PW, et fournissent par là une méthode d'attaque de l'application qui utilise ce canal associé.

 	8.	Remerciements

Les auteurs remercient David Allan, Thomas Nadeau, Yaakov Stein, et Mark Townsley de leurs apports à ce travail.

 	9.	Références normatives

[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

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

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564   ; D.S ; Remplacée par RFC8200, STD 86)

 	10.	Références pour information

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

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

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

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

[RFC4928]	G. Swallow et autres, "Éviter le traitement de chemins multiples à coût égal dans les réseaux MPLS", juin 2007. (BCP0128)

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

 	Appendice.	Traitement du numéro de séquence

Cet Appendice n'est pas normatif.

Il fournit un pseudo code qui décrit le mécanisme de traitement du numéro de éequence exposé au paragraphe 4.2.

unsigned16 RECEIVED                            /* numéro de séquence de paquet
unsigned16 EXPECTED = 1                      /*numéro de séquence attendu initialisé à un
boolean sequencingDisabled
boolean dropOutOfOrder                           /* politique des paquets hors séquence dans la fenêtre

updateExpected()
début
    EXPECTED := RECEIVED + 1;
                                                 /* parce que EXPECTED est un unsigned16 il va revenir de 65535 à 0  ; zéro est sauté
    si (EXPECTED = 0)
        EXPECTED := 1;
    retourne ;
fin ;

À réception d'un paquet PW du PSN :
début
    si (RECEIVED = 0) alors commencer 
        processPacket();
        retourner ;
    fin ;

    si (sequencingDisabled) alors commencer 
                                                /* un paquet est reçu avec un numéro de séquence non zéro, mais le séquençage est désactivé
        indicateReceiveFault();
        disablePW();
        retourne ;
    fin ;

/* la séquence reçue est le numéro de séquence attendu
   si ((RECEIVED = EXPECTED) alors commencer 
/* le paquet est dans l'ordre
        processPacket();
        updateExpected();
        retourne ;
    fin ;

/* Vérification que le numéro de séquence reçu est supérieur au numéro de séquence attendu et est dans la fenêtre de numéro de séquence reçus permis
    si ((RECEIVED > EXPECTED) et
        ((RECEIVED - EXPECTED) < 32768) alors commencer
/* le paquet est dans le fenêtre, mais il y a des paquets en retard/manquants
        si (dropOutOfOrder) alors commencer
/* la politique est de recevoir immédiatement, en éliminant les paquets hors séquence
            processPacket();
            updateExpected();
            retourne ;
        fin autrement commencer                                                    /* la politique est d'attendre les paquets en retard
            processMissingPackets();
            retourner;
        fin ;
    fin ;

/* Vérification que le numéro de séquence reçu est inférieur au numéro de séquence attendu et est dans la fenêtre de numéro de séquence reçus permis
    si ((RECEIVED < EXPECTED) et
        ((EXPECTED - RECEIVED) >= 32768) alors commencer
/* le paquet est dans la fenêtre, mais il y a des paquets en retard/manquants
        si (dropOutOfOrder) alors commencer
/* la politique est de recevoir immédiatement, en éliminant les paquets hors séquence
            processPacket();
            updateExpected();
            retourner ;
        fin autrement commencer                                                    /* la politique est d'attendre les paquets en retard
            processMissingPackets();
            retourner ;
        fin ;
    fin ;

/* Le paquet reçu est en dehors de la fenêtre de numéro de séquence reçus permis
    processOutOfWindow();
fin ;

 	Adresse des auteurs

Stewart Bryant	George Swallow	Luca Martini	Danny McPherson	
Cisco Systems,	Cisco Systems, Inc.	Cisco Systems, Inc.	Arbor Networks, Inc.	
250, Longwater,	1414 Massachusetts Ave	9155 East Nichols Avenue	mél : danny@arbor.net 	
Green Park,	Boxborough, MA 01719	Englewood, CO, 80112		
Reading, RG2 6GB,	USA	USA		
United Kingdom.	mél :  swallow@cisco.com 	mél : lmartini@cisco.com 		
mél : stbryant@cisco.com 				

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à 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.