Groupe de travail Réseau	L. Andersson, Acreo AB
Request for Comments : 5462	R. Asati, Cisco Systems
RFC mises à jour : 3032, 3270, 3272, 3443, 3469, 	février 2009
3564, 3985, 4182, 4364, 4379, 4448, 4761, 5129
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Entrée de pile d'étiquettes de commutation d'étiquettes multiprotocoles (MPLS) : le champ "EXP" est renommé champ "Traffic Class"

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Les premiers documents sur la commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) définissaient la forme de l'entrée de la pile d'étiquettes MPLS. Cela inclut un champ de trois bits appelé le "champ EXP". L'utilisation exacte de ce champ n'était pas définie par ces documents, sauf pour déclarer qu'il devait être "réservé pour une utilisation expérimentale".

Bien que l'utilisation prévue du champ EXP ait été d'un champ de "Classe de service" (CoS) il n'était pas appelé champ CoS par ces premiers documents parce que l'utilisation d'un tel champ CoS n'était pas considérée comme étant suffisamment définie. Aujourd'hui, un certain nombre de documents définissent son usage comme champ de CoS.

Pour éviter des incompréhensions sur la façon d'utiliser ce champ, il est devenu tout à fait nécessaire de renommer ce champ. Le présent document change le nom du champ en "champ de classe de trafic" ("champ TC"). Faisant cela, il met aussi à jour les documents qui définissent l'utilisation actuelle du champ EXP.
Table des matières
1. Introduction	1
2. Détails des changements	2
2.1 RFC 3032	2
2.2 RFC 3270	3
2.3 RFC 5129	4
2.4 Portée de ces changements	5
3. Utilisation du champ TC	5
4. Considérations sur la sécurité	5
5. Remerciements	5
6. Références	5
6.1 Références normatives	5
6.2 Références pour information	6
Adresse des auteurs	6

 	1.	Introduction

Le format d'une entrée de pile d'étiquettes MPLS est défini par la [RFC3032] comme incluant un champ de trois bits appelé "champ EXP". L'utilisation exacte de ce champ n'est pas définie par la RFC 3032, sauf à déclarer qu'il est "réservé pour utilisation expérimentale".

Le champ EXP était depuis le début destiné à porter des informations de "classe de service" (CoS). Le champ était en fait appelé champ "Classe de service" dans les premières versions du document du groupe de travail qui a ensuite été publié comme RFC 3032. Cependant, au moment de la publication de la RFC 3032, l'usage exact de ce champ "Classe de service" ne faisait pas l'objet d'un accord et le champ a été désigné comme "d'utilisation expérimentale" ; donc, le nom a été depuis lors de champ "EXP".

La désignation "pour utilisation expérimentale" a conduit d'autres organisations de normalisation et mises en œuvre à supposer qu'il était possible d'utiliser le champ pour d'autres objets. Le présent document change le nom du champ pour indiquer clairement son utilisation comme champ de classification du trafic.

D'abord, on discute l'utilisation du champ "CoS" original comme nom du champ, mais il a été souligné que ce nom ne couvre pas les changements suivants qui se sont produits à l'égard de son usage depuis la publication de la RFC 3032.

1.	L'utilisation du champ EXP a d'abord été définie dans la [RFC3270], où une méthode pour définir une variante des chemins commutés par étiquettes (LSP, Label Switched Path) de Diffserv, appelée "classe de programmation de comportement par bond fondée sur EXP de chemin commuté par étiquettes" (E-LSP, EXP-Inferred-PSC LSP) était spécifiée. PSC est un acronyme à deux étages qui se développe comme "classe de programmation de comportement par bond" ((PHB, Per Hop Behavior) (SC, Scheduling Class)).

2.	L'utilisation du champ EXP telle que définie dans la RFC 3270 a été étendue dans la [RFC5129], où sont définies des méthodes pour le marquage explicite d'encombrement dans MPLS.

Le présent document utilise donc le nom de champ "Classe de trafic" (TC, Traffic Class) qui couvre mieux l'usage potentiel. Le champ TC MPLS se rapporte à un paquet encapsulé dans MPLS de la même façon que le champ TC IPv6 se rapporte à un paquet encapsulé dans IPv6 ou que le champ Préséance IPv4 se rapporte à un paquet encapsulé dans IPv4.

La définition de l'utilisation du champ EXP est parfaitement claire dans les RFC 3270 et RFC 5129. Cependant, ces RFC ne déclarent pas explicitement qu'elles mettent à jour la RFC 3032, et ce fait n'a pas été capté dans le répertoire des RFC jusqu'après qu'ait commencé le travail sur le présent document.

Le présent document met à jour les RFC 3032, RFC 3270, et RFC 5129 pour préciser l'usage prévu du champ TC. Les changements à ces RFC exigent des changements au texte actuel de ces documents ; la Section 2 explique les changements.

Le présent document met aussi à jour plusieurs autres RFC ; voir au paragraphe 2.4. Pour ces documents, le changement se limite à changer le nom du champ d'entrée de la pile d'étiquettes.

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.	Détails des changements

Le trois RFC 3032, 3270, et 5129 sont maintenant mises à jour conformément à ce qui suit.

 	2.1	RFC 3032
La RFC 3032 déclare en page 4 :

3 : Utilisation expérimentale. Ce champ de trois bits est réservé pour une utilisation expérimentale.

Ce paragraphe est maintenant changé en :

3 : champ Classe de trafic (TC, Traffic Class). Ce champ de trois bits est utilisé pour porter les informations de classe de trafic, et le changement de nom est applicable à tous les endroits où il se trouve dans les RFC de l'IETF et dans les autres documents de l'IETF.

Les RFC 3270 et RFC 5129 mettent à jour la définition du champ TC et décrivent comment utiliser le champ.

La Figure 1 de la page 3 de la RFC 3032, spécifie le format d'une entrée de pile d'étiquettes comme :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entrée
|            Étiquette                  | Exp |S|       TTL     | de pile
+---------------+---------------+-------+-----+-+---------------+ d'étiquettes

Étiquette : valeur d'étiquette, 20 bits
Exp : utilisation expérimentale, 3 bits
S : base de la pile, 1 bit
TTL : durée de vie, 8 bits

Figure 1

La Figure 1 de la RFC 3032 est maintenant changée pour correspondre au changement de nom du champ TC :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entrée
|            Étiquette                  | TC  |S|       TTL     | de pile
+---------------+---------------+-------+-----+-+---------------+ d'étiquettes

Étiquette : valeur d'étiquette, 20 bits
TC : champ Classe de trafic, 3 bits
S : base de la pile, 1 bit
TTL : durée de vie, 8 bits

Figure 1 (nouvelle)

Note : la désignation de la figure ci-dessus comme "Figure 1 (nouvelle)" est introduite comme moyen de distinguer les figures dans le présent document. Ce sera toujours la "Figure 1" dans la RFC 3032.

 	2.2	RFC 3270
La RFC 3270 dit à la page 4 :

1.2	LSP à PSC déduite par EXP (E-LSP)
Un seul LSP peut être utilisé pour prendre en charge un ou plusieurs agrégats ordonnés (OA, Ordered Aggregate). De tels LSP peuvent prendre en charge jusqu’à huit agrégats de comportement (BA, Behavior Aggregate) d’une certaine classe d'équivalence de transmission (FEC, Forwarding Equivalence Class) sans considération du nombre d’OA sur lesquels s’étendent ces BA. Avec de tels LSP, le champ EXP de l’en-tête d'ajustement MPLS est utilisé par le LSR pour déterminer le PHB à appliquer au paquet. Cela inclut aussi bien le PSC que la préférence d’abandon.

On appelle de tels LSP des "LSP à PSC déduite par EXP" (E-LSP) car le PSC d’un paquet transporté sur ce LSP dépend de la valeur du champ EXP pour ce paquet.

La transposition du champ EXP en PHB (c’est-à-dire, en PSC et préséance d’abandon) pour un tel LSP, est signalée explicitement à l’établissement de l’étiquette ou s’appuie sur une transposition pré-configurée.

Le fonctionnement détaillé des E-LSP est spécifié à la section 3.

La RFC 3270 est maintenant mise à jour comme ceci :

a.	Un nouveau paragraphe est ajouté à la fin de la Section 1 "Introduction" :

Le champ EXP a été renommé champ TC, et donc toutes les références dans la RFC 3270 au champ EXP se réfèrent maintenant au champ TC.

b.	un nouveau terme est ajouté au paragraphe 1.1 "Terminologie":

TC (Traffic Class) : classe de trafic (remplace le terme EXP)

c.	Au paragraphe 1.1 "Terminologie", l'acronyme E-LSP est maintenant compris comme signifiant :

E-LSP (Explicitly TC-encoded-PSC LSP) : classe de programmation de comportement par bond fondée sur TC de chemin commuté par étiquettes

Le paragraphe 1.2 de la page 4 de la RFC 3270 est maintenant changé en :

1.2	LSP de classe de programmation de comportement par bond explicitement codée en TC (E-LSP)
Le champ EXP a été renommé champ TC, et donc toutes les références dans la RFC 3270 au champ EXP se réfèrent maintenant au champ TC. Cependant, on conserve l'acronyme E-LSP (LSP de PSC explicitement codé en TC) car l'acronyme est largement utilisé.

Un seul LSP peut être utilisé pour prendre en charge un ou plusieurs agrégats ordonnés (OA, Ordered Aggregate). De tels LSP peuvent prendre en charge jusqu'à huit agrégats de comportement (BA, Behavior Aggregate) de la FEC concernée, sans considération du nombre d'OA sur lesquels ces BA s'étendent. Avec de tels LSP, le champ TC de l'en-tête d'ajustement MPLS est utilisé par le LSR pour déterminer le PHB à appliquer au paquet. Cela inclut le PSC et la préférence d'abandon.

On se réfère à de tels LSP comme à des "LSP de PSC codée explicitement en TC" (E-LSP) car le PSC d'un paquet transporté sur ce LSP dépend de la valeur du champ TC (précédemment appelé champ EXP) pour ce paquet.

La transposition du champ TC en PHB (c'est-à-dire, en PSC et préséance d'abandon) pour un tel LSP est soit explicitement signalée à l'établissement de l'étiquette, soit s'appuie sur une transposition pré-configurée.

C'est une mise à jour de la [RFC3032], en ligne avec l'intention originale de la façon dont ce champ dans l'en-tête d'ajustement MPLS devrait être utilisé (comme champ de classe de trafic). La RFC 3270 a elle même été mise à jour par la [RFC5129].

Le fonctionnement détaillé des E-LSP est spécifié à la Section 3 de la RFC 3270.

 	2.3	RFC 5129
La RFC 5129 est maintenant mise à jour comme suit :

Un nouveau paragraphe est ajouté à la fin du paragraphe 1.1 "Fondements" :

Le champ EXP a été renommé champ TC, et donc toutes les références dans la RFC 5129 au champ EXP se réfèrent maintenant au champ TC.

La Section 2 (dernier alinéa) à la page 4 de la RFC 5129 dit :

o	Une troisième approche possible a été suggérée par [Shayman]. Dans ce schéma, les LSR intérieurs supposent que les points d'extrémité sont à capacité ECN, mais cette hypothèse est battue en brèche quant l'étiquette finale est sautée. Si un LSR intérieur a marqué l'ECN dans le champ EXP de l'en-tête d'ajustement, mais que l'en-tête IP dit que les points d'extrémité n'ont pas la capacité ECN, le routeur de bordure (ou l'avant dernier routeur, si on utilise le saut de l'avant dernier bond) élimine le paquet. On recommande ce schéma, qu'on appelle "vérification d'ECT par domaine", et on le définit plus précisément au paragraphe suivant. Son principal inconvénient est qu'il peut causer la transmission de paquets après avoir rencontré de l'encombrement seulement pour être éliminés à la sortie du domaine MPLS. La raison de cette décision est donnée au paragraphe 8.1.

La Section 2 (dernier alinéa) de la RFC 5129 est maintenant mise à jour comme suit :
o	Une troisième approche possible a été suggérée par [Shayman]. Dans ce schéma, les LSR intérieurs supposent que les points d'extrémité sont à capacité ECN, mais cette hypothèse est battue en brèche quant l'étiquette finale est sautée. Si un LSR intérieur a marqué l'ECN dans le champ TC de l'en-tête d'ajustement, mais que l'en-tête IP dit que les points d'extrémité n'ont pas la capacité ECN, le routeur de bordure (ou l'avant dernier routeur, si on utilise le saut de l'avant dernier bond) élimine le paquet. On recommande ce schéma, qu'on appelle "vérification d'ECT par domaine", et on le définit plus précisément au paragraphe suivant. Son principal inconvénient est qu'il peut causer la transmission de paquets après avoir rencontré de l'encombrement seulement pour être éliminés à la sortie du domaine MPLS. La raison de cette décision est donnée au paragraphe 8.1.
Ce schéma est une mise à jour de la [RFC3032] et de la [RFC3270].

 	2.4	Portée de ces changements
Il y a plusieurs endroits dans ces RFC qui sont explicitement mis à jour par le présent document qui font référence au champ "Exp", parfois ils se réfèrent au champ comme à des "bits Exp", "bits EXP", ou "EXP". Dans toutes ces instances, cela doit maintenant être lu comme "champ TC".

Il y a aussi d'autres RFC (par exemple, les [RFC3272], [RFC3443], [RFC3469], [RFC3564], RFC3985], [RFC4182], [RFC4364], [RFC4379], [RFC4448], et [RFC4761]) qui font référence au champ "Exp" ; parfois elles se réfèrent au champ comme à des "bits Exp", "bits EXP", et "EXP". Pour toutes ces RFC, y compris, mais sans se limiter à celles mentionnées dans ce paragraphe, de telles références doivent être lues comme "champ TC".

 	3.	Utilisation du champ TC

Du fait du nombre limité de bits dans le champ TC, leur utilisation pour les fonctions de qualité de service (QS) et de notification explicite d'encombrement (ECN, Explicit Congestion Notification) est destinée à être souple. Ces fonctions peuvent réécrire tout ou partie des bits du champ TC.

Les mises en œuvre actuelles examinent le champ TC avec et sans contexte d'étiquette, et le champ TC peut être copié dans des entrées de la pile d'étiquettes qui sont poussées sur la pile d'étiquettes. Ceci est fait pour éviter que les entrées de la pile d'étiquettes soient poussées sur une pile d'étiquettes existante ayant des champs TC différents du reste des entrées de la pile d'étiquettes.

 	4.	Considérations sur la sécurité

Le présent document change seulement le nom d'un champ de l'en-tête d'ajustement MPLS, et n'introduit donc aucune nouvelle considérations de sécurité.

 	5.	Remerciements

Les auteurs tiennent à remercier Stewart Bryant, Bruce Davie, George Swallow, et Francois Le Faucheur de leurs apports et de leur relecture de ce document.

Les auteurs tiennent aussi à remercier George Swallow, Khatri Paresh, et Phil Bedard de leur aide à la grammaire et l'orthographe. Un merci particulier à Adrian Farrel pour sa relecture attentive et son aide pour naviguer dans l'océan des RFC à la recherche des références au champ EXP.

 	6.	Références
 	6.1	Références normatives

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

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001. (Info. ; MàJ par 9017)

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

[RFC3272]	D. Awduche et autres, "Généralités et principes de l'ingénierie du trafic de l'Internet", mai 2002. (Information)

[RFC3443]	P. Agarwal, B. Akyol, "Traitement de la durée de vie (TTL) dans les réseaux à commutation d'étiquettes multi-protocoles (MPLS)", janvier 2003. (P.S.)

[RFC3469]	V. Sharma et F. Hellstrand, éd., "Cadre pour la récupération fondée sur la commutation d'étiquettes multi-protocoles (MPLS)", février 2003. (Information)

[RFC3564]	F. Le Faucheur, W. Lai, "Exigences pour la prise en charge de l'ingénierie de trafic MPLS capable de services différenciés", juillet 2003. (Information)

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

[RFC4182]	E. Rosen, "Levée d'une restriction sur l'utilisation de NULL explicite dans MPLS", septembre 2005. (MàJ RFC3032) (P.S.)

[RFC4364]	E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)

[RFC4379]	K. Kompella et G. Swallow, "Détection des défaillances de plan des données en commutation d'étiquettes multi protocole (MPLS)", février 2006. (MàJ par la RFC6424  ; Rendue obsolète par RFC8029) (P.S.)

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

[RFC4761]	K. Kompella et Y. Rekhter, éditeurs "Service de LAN privé virtuel (VPLS) utilisant BGP pour l'auto découverte et la signalisation", janvier 2007. (P.S. ; MàJ par RFC8395)

[RFC5129]	B. Davie et autres, "Marquage d'encombrement explicite dans MPLS", janvier 2008. (P.S. ; MàJ RFC3032 ; MàJ par RFC5462)

 	6.2	Références pour information

[Shayman]	Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Within an MPLS Domain", Travail en cours, novembre 2000.

 	Adresse des auteurs

Loa Andersson	Rajiv Asati	
Acreo AB	Cisco Systems	
mél : loa@pi.nu	mél : rajiva@cisco.com