Groupe de travail Réseau	A. Farrel, Ed., Old Dog Consulting	
Request for Comments : 5420	D. Papadimitriou, Alcatel	
RFC rendue obsolète : 4420	JP. Vasseur, Cisco Systems, Inc.	
RFC mises à jour : 3209, 3473	A. Ayyangar, Juniper Networks	
Catégorie : Sur la voie de la normalisation	février 2009	
Traduction Claude Brière de L'Isle		

Codage des attributs pour l'établissement de LSP MPLS avec le protocole de réservation de ressource à ingénierie du trafic (RSVP-TE)

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 chemins de commutation d'étiquettes (LSP, Label Switched Path) de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) peuvent être établis en utilisant les extensions au protocole de réservation de ressources avec ingénierie du trafic (RSVP-TE, Resource Reservation Protocol Traffic Engineering). Ce protocole inclut un objet (l'objet SESSION_ATTRIBUTE) qui porte un champ Fanions utilisé pour indiquer les options et attributs du LSP. Ce champ Fanions a huit bits, permettant d'établir huit options. De récentes propositions dans de nombreux documents qui étendent RSVP-TE ont suggéré des utilisations pour chacun des bits précédemment non utilisés.

Le présent document définit un nouvel objet pour les messages RSVP-TE, qui permet de signaler plus de bits d'attributs et aussi de porter des paramètres d'attribut arbitraires pour rendre RSVP-TE facilement extensible pour prendre en charge de nouvelles exigences. De plus, le présent document définit une façon d'enregistrer les attributs appliqués au LSP bond par bond.

Les mécanismes d'objet définis dans le présent document sont également applicables aux LSP à capacité de commutation de paquet (PSC, Packet Switch Capable) MPLS généralisée (GMPLS, Generalized MPLS) et aux LSP GMPLS non PSC.

Le présent document remplace et rend obsolète la précédente version de ce travail, publiée comme RFC 4420. Le seul changement est dans le codage de la structure de données de Type-Longueur-Valeur (TLV).
Table des matières
1. Introduction et position du problème	2
1.1 Applicabilité à MPLS généralisé	3
1.2 Solution de remplacement rejetée	3
2. Terminologie	3
3. TLV d'attributs	3
3.1 TLV Fanions d'attribut	4
4. Objet LSP_ATTRIBUTES	4
4.1 Format	5
4.2 Règles générique de traitement des messages Path	5
4.3 Règles générique de traitement des messages Resv	5
5. Objet LSP_REQUIRED_ATTRIBUTES	6
5.1 Format	6
5.2 Règles génériques de traitement	6
6. Règles d'héritage	7
7. Enregistrement des attributs par LSP	7
7.1 Exigences	7
7.2 Sous objet Attributs RRO	7
7.3 Procédures	8
8. Résumé de l'allocation du bit d'attribut	8
9. Formats de message	9
10. Lignes directrices sur les scénarios clés d'application	9
10.1 Communication aux LSR de sortie	9
10.2 Communication aux LSR de transit clés	10
10.3 Communication à tous les LSR	10
11. Considérations relatives à l'IANA	10
11.1 Nouveaux C-Nums et C-Types RSVP	10
11.2 Nouvel espace de TLV	10
11.3 Fanions d'attributs	11
11.4 Nouveaux codes d'erreur	11
11.5 Nouvel identifiant de sous objet Record Route	11
12. Considérations sur la sécurité	12
13. Remerciements	12
14. Changements de la RFC 4420 à la RFC 5420	12
15. Références normatives	12
16. Références pour information	12
Adresse des auteurs	13

 	1.	Introduction et position du problème

Le présent document remplace et rend obsolète la précédente version de ce travail, publiée comme [RFC4420]. Le seul changement est dans le codage des structures de données Type-Longueur-Valeur (TLV) présentées à la Section 3. Voir à la Section 14 un résumé des changements.

Les chemins de commutation d'étiquettes (LSP, Label Switched Path) de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) [RFC3031] peuvent être établis en utilisant le message Path du protocole de signalisation de réservation de ressources avec ingénierie du trafic (RSVP-TE, Resource Reservation Protocol Traffic Engineering) [RFC3209]. Le message Path inclut l'objet SESSION_ATTRIBUTE, qui porte un champ Fanions utilisé pour indiquer les options et attributs désirés du LSP.

Le champ Fanions dans l'objet SESSION_ATTRIBUTE a huit bits. Seuls trois d'entre eux sont alloués dans la [RFC3209].  Deux bits de plus sont alloués dans la [RFC4090] pour la fonctionnalité de réacheminement rapide, laissant seulement trois bits disponibles. Plusieurs propositions et projets Internet récents ont montré qu'il y a une forte demande pour l'utilisation des trois autres bits. Certaines, sinon toutes, ces propositions vont probablement devenir des RFC, résultant en l'occupation totale ou presque totale du champ Fanions et en la difficulé qui va en résulter pour signaler de nouvelles options et attributs qui pourraient être développés à l'avenir.

Le présent document définit un nouvel objet pour les messages RSVP-TE qui permet de signaler plus de bits d'attributs. Le nouvel objet est construit à partir de TLV, et une nouvelle TLV est définie pour porter un nombre variable de bits d'attributs.

Le nouvel objet de message RSVP-TE est assez souple, du fait de l'utilisation du format de TLV et permet :
- une future spécification de bits fanions,
- des paramètres d'options et d'attributs supplémentaires portés dans un format de TLV.

Noter que les attributs de LSP définis dans  ce document ont une portée spécifique de LSP. Ils peuvent être réglés différemment sur des LSP séparés avec le même identifiant de tunnel entre la même source et destination (c'est-à-dire, au sein de la même session).

Il est noté que certaines options et attributs n'ont pas besoin d'être utilisés par tous les routeurs de commutation d'étiquettes (LSR, Label Switched Router) le long du chemin du LSP. En particulier, ces options et attributs peuvent ne s'appliquer qu'aux LSR clés sur le chemin, comme le LSR d'entrée et le LSR de sortie. Des LSR de transit spéciaux, comme des routeurs frontières de zone (ABR, Area Border Router) ou routeurs frontières de système autonome (ASBR, Autonomous System Boundary Router) peuvent aussi entrer dans cette catégorie. Cela signifie que les nouvelles options et attributs devraient être signalés de façon transparente, et seulement examinés aux points qui ont besoin d'agir sur eux.

Par ailleurs, d'autres options et attributs peuvent exiger une action à tous les LSR de transit le long du chemin du LSP. L'incapacité de prendre en charge les attributs requis par un de ces LSR de transit peut obliger le LSR à refuser l'établissement du LSP.

Ces considérations sont particulièrement importantes dans le contexte de la rétro compatibilité. En général, il devrait être possible de fournir de nouveaux services MPLS à travers un réseau traditionnel sans mettre à niveau les LSR qui n'ont pas besoin de participer activement aux nouveaux services. De plus, certaines caractéristiques exigent juste une action sur des bonds intermédiaires spécifiques, et pas sur chaque LSR visité.

Noter que les options déjà spécifiées pour l'objet SESSION_ATTRIBUTE dans les RFC pré existantes ne sont pas importées dans les nouveaux mécanismes décrits dans le présent document.

RSVP inclut une façon pour que les objets non reconnus soient transmis de façon transparente par les nœuds de transit sans leur refuser les messages de protocole entrants et sans que les objets soient supprimés du message de protocole sortant (voir le paragraphe 3.10 de la [RFC2205]). Cette capacité s'étend à RSVP-TE et donne un bon moyen pour assurer que seuls les LSR qui comprennent un objet particulier l'examinent.

Le présent document distingue entre les options et attributs qui sont seulment exigés aux LSR clés le long du chemin du LSP, et ceux sur lesquels doit agir chaque LSR le long du LSP. Deux objets Attributs de LSP sont définis dans ce document, en utilisant les règles de définition C-Num héritées de la [RFC2205] ; le premier est passé de façon transparente par les LSR qui ne le reconnaisent pas, et le second cause l'échec de l'établissement du LSP avec la génération d'un message PathErr avec un code l'erreur approprié si un LSR ne le reconnaît pas.

 	1.1	Applicabilité à MPLS généralisé
Le protocole de signalisation RSVP-TE forme aussi la base d'un protocole de signalisation pour MPLS généralisé (GMPLS) comme décrit dans les [RFC3471] et [RFC3473]. Les extensions décrites dans le présent document sont également applicables à MPLS et GMPLS.

 	1.2	Solution de remplacement rejetée
Une autre solution rejetée était de définir un nouveau C-Type pour l'objet SESSION_ATTRIBUTE existant. Ce nouveau C-Type aurait pu permettre un plus grand champ Fanions et régler le problème immédiat.
Cette solution a été rejetée parce que :
-	Un nouveau C-Type n'est pas rétro compatible avec les mises en œuvre déployées qui s'attendent à voir un C-Type de 1 ou 7. Il est important que toute solution soit capable de porter de nouveaux attributs de façon transparente à travers les LSR traditionnels si ces LSR ne sont pas obligés d'agir sur les attributs.
-	La prise en charge de paramètres d'attributs arbitraires par des TLV aurait entraîné un changement significatif de la substance de l'objet existant.

 	2.	Terminologie

Le présent document utilise la terminologie de l'architecture MPLS [RFC3031] et de la spécification du protocole RSVP-TE [RFC3209], qui hérite de la spécification de RSVP [RFC2205]. Il utilise aussi la terminologie de RSVP-TE MPLS généralisé introduite dans les [RFC3471] et [RFC3473].

Les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

 	3.	TLV d'attributs

Les attributs portés dans les nouveaux objets définis dans ce document sont codés avec des TLV. Une ou plusieurs TLV peuvent être présentes dans chaque objet. Il n'y a pas de règle d'ordre pour les TLV, et aucune interprétation ne devrait être tirée de l'ordre dans lequel les TLV sont reçues.

Chaque TLV est codée 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |         Longueur              |
+---------------+---------------+---------------+---------------+
|                                                               |
//                            Valeur                            //
|                                                               |
+---------------+---------------+---------------+---------------+

Type : identifiant de la TLV.

Longueur : indique la longueur totale de la TLV en octets. C'est-à-dire, la longueur combinée des champs Type, Longueur, et Valeur, soit quatre plus la longueur du champ Valeur en octets. La TLV entière DOIT être bourrée avec entre zéro et trois zéros en queue pour l'aligner sur quatre octets. Le champ Longueur ne contient pas de bourrage.

Valeur : les données portées dans la TLV.

 	3.1	TLV Fanions d'attribut
Le présent document définit seulement une valeur de type de TLV. Le type 1 indique la TLV Fanions d'attribut. D'autres types de TLV pourront être définis à l'avenir avec des valeurs de type allouées par l'IANA (voir le paragraphe 11.2).

La TLV Fanions d'attribut peut être présente dans un objet LSP_ATTRIBUTES et/ou un objet LSP_REQUIRED_ATTRIBUTES, définis aux Sections 4 et 5. Les bits dans la TLV représentent les mêmes attributs sans considération de quel objet porte la TLV. Les documents qui définissent des bits individuels DOIVENT spécifier si le bit peut être établi dans un objet, l'autre, ou les deux. Il n'est pas prévu qu'un bit soit établi dans les deux objets sur un seul message Path en même temps, mais ce n'est pas interdit par le présent document.

Le champ Valeur de la TLV Fanions d'attribut est un dispositif d'unités de 32 fanions numérotés du bit de plus fort poids jusqu'au bit zéro. Le champ Longueur pour cette TLV est donc toujours un multiple de quatre octets, sans considération du nombre de bits portés, et aucun bourrage n'est requis.

Les bits non alloués sont considérés comme réservés et DOIVENT être réglés à zéro à l'émission par le générateur de l'objet. Les bits non contenus dans la TLV DOIVENT être supposés réglés à zéro. Si la TLV est absente soit parce que elle n'est pas contenue dans l'objet LSP_ATTRIBUTES ou LSP_REQUIRED_ATTRIBUTES, soit parce que ces objets sont eux-mêmes absents, tout le traitement DOIT être effectué comme si les bits étaient présents et réglés à zéro. C'est-à-dire que les bits alloués qui ne sont pas présents soit parce que la TLV est délibérément omise, soit parce que la TLV n'est pas incluse DOIVENT être traités comme si ils étaient présents et réglés à zéro.

Aucun bit n'est défini dans le présent document. Les allocations de bits sont gérées par l'IANA (voir le paragraphe 11.3).

 	4.	Objet LSP_ATTRIBUTES

L'objet LSP_ATTRIBUTES est utilisé pour signaler les attributs nécessaires pour prendre en charge un LSP, ou pour indiquer la nature ou l'utilisation d'un LSP où cette information n'est pas exigée pour une action par tous les LSR de transit. Précisément, si un LSR ne prend pas en charge l'objet, il le transmet sans examen et inchangé. Cela facilite l'échange des attributs à travers les réseaux traditionnels qui ne prennent pas en charge de nouvel objet.

Ces objet étend effectivement le champ Fanions dans l'objet SESSION_ATTRIBUTE et permet l'inclusion future d'objets plus complexes par des TLV.

Noter que certaines fonctions peuvent exiger qu'un LSR inspecte les deux objets SESSION_ATTRIBUTE et LSP_ATTRIBUTES ou LSP_REQUIRED_ATTRIBUTES.

L'objet LSP_ATTRIBUTES peut aussi être utilisé pour rapporter l'état de fonctionnement d'un LSP on un message RESV même quand aucun objet LSP_ATTRIBUTES ou LSP_REQUIRED_ATTRIBUTES n'est porté dans le message Path correspondant. L'objet est ajouté ou mis à jour par les LSR qui prennent en charge l'objet. Les LSR qui ne comprennent pas l'objet ou n'ont rien à rapporter n'ajoutent pas l'objet et le transmettent inchangé sur les messages Resv qu'ils génèrent.

La classe de l'objet LSP_ATTRIBUTES est 197 de la forme 11bbbbbb. Cette valeur de C-Num (voir le paragraphe 3.10 de la [RFC2205]) assure que les LSR qui ne reconnaissent pas l'objet le passent de façon transparente.

Le C-Type = 1 est défini pour les attributs de LSP.

Cet objet est facultatif et peut être placé dans les messages Path pour porter des informations supplémentaires sur les attributs désirés du LSP, et dans les messages Resv pour rapporter l'état de fonctionnement.

 	4.1	Format
LSP_ATTRIBUTES : classe = 197, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                       TLV d'attributs                        //
|                                                               |
+---------------+---------------+---------------+---------------+

Les TLV Attributs sont codées comme décrit à la Section 3.

 	4.2	Règles générique de traitement des messages Path
Un LSR qui ne prend pas en charge cet objet est obligé de le passer sans altération, comme indiqué par le C-Num et les règles définies dans la [RFC2205].

Un LSR qui ne prend pas en charge cet objet mais ne reconnaît pas le code de type de TLV porté dans cet objet DOIT passer la TLV sans altération dans l'objet LSP_ATTRIBUTES placé dans le message Path qu'il envoie vers l'aval.

Un LSR qui prend en charge cet objet et reconnaît une TLV mais ne prend pas en charge l'attribut défini par la TLV DOIT agir comme spécifié dans le document qui définit la TLV.

Un LSR qui prend en charge la TLV Fanions d'attribut mais ne reconnaît pas le bit établi dans la TLV Fanions d'attribut DOIT transmettre la TLV inchangée.

Un LSR qui prend en charge la TLV Fanions d'attribut et reconnaît un bit qui est établi mais ne prend pas en charge l'attribut indiqué DOIT agir comme spécifié dans le document qui définit le bit.

 	4.3	Règles générique de traitement des messages Resv
Un LSR qui souhaite rapporter l'état de fonctionnement d'un LSP peut inclure cet objet dans un message RESV, ou mettre à jour l'objet qui est déjà porté dans un message RESV.

Noter que cet usage rapporte l'état du LSP entier et non l'état du LSP à un LSR individuel. Cette dernière fonction est réalisée en utilisant le sous objet Attributs de LSP de l'objet RECORD_ROUTE (RRO) décrit à la Section 7.

Les bits dans la TLV Attributs peuvent être utilisés pour rapporter l'état de fonctionnement pour le LSP entier. Par exemple, un LSR de sortie peut rapporter un état particulier en établissant un bit. Les LSR dans le réseau qui déterminent que cet état n'a pas été réalisé peuvent mettre le bit à zéro quand ils transmettent le message RESV.

On observe que les LSR qui ne prennent pas en charge l'objet ou ne prennent pas en charge la fonction caractérisée par un bit particulier dans la TLV Attributs ne vont pas mettre le bit à zéro quand ils transmettent le Resv. Donc, il faut faire attention quand on définit l'usage de cet objet dans un message Resv. L'usage d'un bit individuel dans la TLV Attributs de l'objet LSP_ATTRIBUTES sur un message Resv doit être complètement défini dans le document qui définit le bit.

Des TLV supplémentaires peuvent aussi être définies pour être portées dans cet objet sur un message Resv.

Un LSR qui ne prend pas en charge cet objet va le passer sans altération à cause du C-Num.

 	5.	Objet LSP_REQUIRED_ATTRIBUTES

L'objet LSP_REQUIRED_ATTRIBUTES est utilisé pour signaler les attributs exigés pour la prise en charge d'un LSP, ou pour indiquer la nature ou l'utilisation d'un LSP lorsque cette information DOIT être inspectée à chaque LSR de transit. Précisément, chaque LSR de transit DOIT examiner les attributs dans l'objet LSP_REQUIRED_ATTRIBUTES et NE DOIT PAS transmettre l'objet sans agir sur son contenu.

Cet objet étend effectivement le champ Fanions dans l'objet SESSION_ATTRIBUTE et permet la future inclusion d'objets plus complexes par des TLV. Il complète l'objet LSP_ATTRIBUTES.

La classe de l'objet LSP_REQUIRED_ATTRIBUTES est 67 de la forme 0bbbbbbb. Cette valeur de C-Num assure que les LSR qui ne reconnaissent pas l'objet rejettent l'établissement du LSP, en disant effectivement qu'ils ne prennent pas en charge les attributs demandés. Cela signifie que cet objet DEVRAIT seulement être utilisé pour les attributs qui exigent la prise en charge à des LSP de transit et exigent donc un examen à tous les LSR de transit. Voir à la Section 4 comment sont signalés les attributs de bout en bout et sélectifs.

Un C-Type est défini, le C-Type = 1 pour les attributs exigés pour le LSP.

Cet objet est facultatif et peut être placé dans les messages Path pour porter des informations supplémentaires sur les attributs désirés pour le LSP.

 	5.1	Format
LSP_REQUIRED_ATTRIBUTES : classe = 67, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                      TLV Attributs                           //
|                                                               |
+---------------+---------------+---------------+---------------+

Les TLV Attributs sont codées comme décrit à la Section 3.

 	5.2	Règles génériques de traitement
Un LSR qui ne prend pas en charge cet objet va utiliser une PathErr pour rejeter le message Path sur la base du C-Num en utilisant le code d'erreur "Classe d'objet inconnue".

Un LSR qui ne reconnaît pas un code de type de TLV porté dans cet objet DOIT rejeter le message Path en utilisant un PathErr avec le code d'erreur "TLV Attributs inconnue" et la valeur d'erreur réglée à la valeur du code de type de TLV inconnu.

Un LSR qui ne reconnaît pas un bit établi dans la TLV Fanions d'attributs DOIT rejeter le message Path en utilisant une PathErr avec le code d'erreur "Bit d'attributs inconnu" et la valeur d'erreur réglée au numéro de bit du bit inconnu dans les fanions d'attribut.

Un LSR qui reconnaît un attribut (cependant codé) mais ne prend pas en charge cet attribut DOIT agir conformément au comportement spécifié dans le document qui défini cet attribut spécifique.

Noter que cet objet n'est pas utilisé sur une Resv. Afin de rapporter l'état d'un LSP, l'objet LSP_ATTRIBUTES sur une Resv ou le sous objet Attributs dans l'objet Record Route (Section 7) doit être utilisé.

 	6.	Règles d'héritage

Dans certaines circonstances, quand on atteint une limite de région de LSP, un LSP d'adjacence de transmission (FA-LSP; voir la [RFC4206]) est initialement établi pour permettre l'établissement du LSP qui porte les objets LSP_ATTRIBUTES et/ou LSP_REQUIRED_ATTRIBUTES. Dans ce cas, quand le LSR frontière prend en charge le traitement de LSP_ATTRIBUTES et de LSP_REQUIRED_ATTRIBUTES, le FA-LSP PEUT, selon la politique locale, hériter d'un sous ensemble de TLV Attributs, en particulier quand le FA-LSP appartient à la même classe de capacités de commutation que le LSP déclencheur.

Quand ces conditions sont satisfaites, les objets LSP_ATTRIBUTES et/ou LSP_REQUIRED_ATTRIBUTES sont simplement copiés avec les TLV Attributs héritées dans le message Path utilisé pour établir le FA-LSP. Par défaut (et afin de simplifier le déploiement) aucune des TLV Attributs de LSP entrant n'est considérée comme héritable. Noter que quand l'établissement du FA-LSP lui-même exige une ou plusieurs TLV Attributs, une opération "OU" est effectuée avec l'ensemble de valeurs héritées.

Les documents qui définissent les bits individuels pour la TLV Fanions d'attribut de LSP DOIVENT spécifier si ces bits PEUVENT ou non être hérités (incluant la condition à satisfaire afin que cet héritage se produise). La même chose s'applique à toutes les autres TLV qui vont être définies suivant les règles spécifiées à la Section 3.

 	7.	Enregistrement des attributs par LSP
 	7.1	Exigences
Dans certaines circonstances, il est utile de déterminer quels attributs de LSP demandés ont été appliqués à quels LSR sur le chemin du LSP. Par exemple, un attribut peut être demandé dans l'objet LSP_ATTRIBUTES tel que les LSR qui ne prennent pas en charge l'objet ne soient pas obligés de prendre en charge l'attribut ou de fournir la fonction demandée. Dans ce cas, il peut être utile que le LSR d'entrée sache quels LSR ont agi sur la demande et quels sont ceux qui l'ont ignorée.

De plus, il peut y avoit d'autres qualités qui doivent être rapportées bond par bond. Elles sont généralement indiquées dans le champ Fanions des sous objets RRO. Comme il n'y a que huit bits disponibles dans ce champ, et comme certains sont déjà alloués et qu'il y aura aussi probablement une augmentation des allocations dans de nouveaux documents, il est nécessaire d'avoir une autre méthode pour rapporter les attributs bond par bond.

 	7.2	Sous objet Attributs RRO
Le sous objet Attributs RRO peut être porté dans l'objet RECORD_ROUTE si il est présent. Le sous objet utilise le format standard de sous objet RRO.

La longueur est variable, comme pour la TLV Fanions d'attribut. Le contenu est le même que celui de la TLV Fanions d'attribut -- c'est-à-dire, c'est une série de fanions binaires.

Il y a une correspondance biunivoque entre les bits de la TLV Fanions d'attribut et le sous objet Attributs RRO. Si un bit est seulement exigé dans un des deux endroits, il est réservé dans l'autre. Voir les paragraphes de procédures ci-dessous pour plus d'informations.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Longueur    |           Réservé             |
+---------------+---------------+---------------+---------------+
|                                                               |
//                     Fanions d'aAttributs                     //
|                                                               |
+---------------+---------------+---------------+---------------+

Type : 0x05

Longueur : le champ Longueur contient la longueur totale du sous objet en octets, incluant les champs Type et Longueur. Cette longueur doit être un multiple de quatre et doit être d'au moins huit.

Fanions d'attributs : fanions d'attributs enregistrés pour le bond spécifié.

 	7.3	Procédures
 	7.3.1	Règles de présence de sous objet
Comme précisé dans la [RFC3209], l'objet RECORD_ROUTE est géré comme une "pile", chaque LSR ajoutant des sous objets au début de l'objet. Le sous objet Attributs est poussé sur l'objet RECORD_ROUTE immédiatement avant de pousser l'adresse IP ou l'identifiant de liaison du nœud. Donc, si l'enregistrement d'étiquettes est utilisé, le sous objet Attributs DEVRAIT être poussé sur l'objet RECORD_ROUTE après le ou les sous objets Record Label.

Un nœud NE DOIT PAS pousser un sous objet Attributs sur l'objet RECORD_ROUTE sans aussi pousser un sous objet Identifiant d'interface IPv4, IPv6, ou non numérotée.

Cela signifie qu'un sous objet Attributs est lié au LSR identifié par le sous objet trouvé dans le RRO immédiatement avant le sous objet Attributs.

Si le nouveau sous objet fait que le RRO est trop gros pour tenir dans un message Path (ou Resv) le traitement DOIT être comme décrit au paragraphe 4.4.3 de la [RFC3209].

Si plus d'un sous objet Attributs se trouve entre une paire de sous objets qui identifient des LSR, seul le premier trouvé (c'est-à-dire, le plus proche du sommet de la pile) DEVRA avoir une signification dans le contexte du présent document. Tous les sous objets DOIVENT être transmis sans modification par les LSR de transit.

 	7.3.2	Rapport de conformité aux attributs de LSP
Pour rapporter la conformité à un attribut demandé dans la TLV Fanions d'attribut, un LSR PEUT établir le bit correspondant (Section 8) dans le sous objet Attributs. Pour rapporter la non conformité, un LSR PEUT mettre à zéro le bit correspondant dans le sous objet Attributs.

L'exigence de rapporter la conformité DOIT être spécifiée dans le document qui définit l'usage du bit. Cela va se réduire à une déclaration de si un accusé de réception bond par bond est exigé.

 	7.3.3	Rapport des attributs par bond
Pour rapporter un attribut par bond, un LSR établit le bit approprié dans le sous objet Attributs.

L'exigence de rapporter un attribut par bond DOIT être spécifiée dans le document qui définit l'usage du bit.

 	7.3.4.	Comportement par défaut
Par défaut, tous les bits dans un sous objet Attributs DEVRAIENT être réglés à zéro.

Si un sous objet Attributs reçu n'est pas assez long pour inclure un bit numéroté spécifique, ce bit DOIT être traité comme si il était présent et réglé à zéro.

Si le sous objet RRO n'est pas présent pour un bond dans le LSP, tous les bits DOIVENT être supposés réglés à zéro.

 	8.	Résumé de l'allocation du bit d'attribut

Le présent document définit deux utilisations des champs de bit de fanion d'attribut par LSP. La numérotation des bits dans la TLV Fanions d'attribut et le sous objet Attributs RRO est identique. C'est-à-dire que le même attribut est indiqué par le même bit dans les deux endroits. Cela signifie qu'un seul registre des bits est tenu.

La conséquence est une meilleure clarté de mise en œuvre et d'enregistrement.

Noter cependant, qu'il n'est pas toujours vrai qu'un bit va être utilisé à la fois dans la TLV Fanions d'attribut et le sous objet Attributs RRO. Par exemple, un attribut peut être demandé en utilisant la TLV Fanions d'attribut, mais il n'est pas exigé de rapporter le traitement de l'attribut bond par bond. À l'inverse, il peut être exigé de rapporter les attributs d'un LSP bond par bond, mais il n'y a pas d'attribut de demande correspondant.

Dans ces cas, un seul numéro de bit est quand même alloué pour les deux TLV Fanions d'attribut et sous objet Attributs RRO, même si le bit peut n'être pas pertinent dans les fanions d'attribut ou le sous objet Attributs RRO. Le document qui définit l'usage du nouveau bit DOIT déclarer à quels endroits il est utilisé et DOIT traiter un réglage par défaut de zéro.

 	9.	Formats de message

Les objets LSP_ATTRIBUTES et LSP_REQUIRED_ATTRIBUTES PEUVENT être portés dans un message Path. L'objet LSP_ATTRIBUTES PEUT être porté dans un message RESV.

L'ordre des objets dans les messages RSVP-TE est recommandé, mais les mises en œuvre doivent être capables de recevoir des objets dans tout ordre significatif.

Sur un message Path, il est RECOMMANDÉ que l'objet LSP_ATTRIBUTES et les objets LSP_REQUIRED_ATTRIBUTES soient placés immédiatement après l'objet SESSION_ATTRIBUTE si il est présent, ou autrement, immédiatement après l'objet LABEL_REQUEST.

Si les deux objets LSP_ATTRIBUTES et LSP_REQUIRED_ATTRIBUTES sont présents, il est RECOMMANDÉ que l'objet LSP_REQUIRED_ATTRIBUTES soit placé en premier.

Les LSR DOIVENT être prêts à recevoir ces objets dans n'importe quel ordre dans toute position au sein d'un message Path. Les instances suivantes de ces objets dans un message Path DEVRAIENT être ignorées et DOIVENT être transmises inchangées.

Sur un message RESV, l'objet LSP_ATTRIBUTES est placé dans le descripteur de flux et est associé à l'objet FILTER_SPEC qui le précède. Il est RECOMMANDÉ que l'objet LSP_ATTRIBUTES soit placé immédiatement après l'objet LABEL.

Les LSR DOIVENT être prêts à recevoir cet objet dans n'importe quel ordre dans toute position au sein d'un message RESV, sous réserve de la note précédente. Une seule instance de l'objet LSP_ATTRIBUTES est significative dans le contexte d'un objet FILTER_SPEC. Les instances suivantes de l'objet DEVRAIENT être ignorées et DOIVENT être transmises inchangées.

 	10.	Lignes directrices sur les scénarios clés d'application

Comme décrit dans l'introduction de ce document, il se peut que les attributs de LSP demandés ne doivent faire l'objet d'une action que par le LSR de sortie du LSP, par certains points de transit clés (comme les ABR et ASBR) ou par tous les LSR le long du LSP. Cette Section décrit brièvement comment chacun de ces scénarios est traité. Cette Section est pour information et ne définit pas de nouvelles procédures.

 	10.1	Communication aux LSR de sortie
Quand on communique des attributs de LSP sur lesquels seul le LSR de sortie du LSP doit agir, les attributs devraient être communiqués dans l'objet LSP_ATTRIBUTES. À cause de son C-Num, cet objet peut être ignoré (passé en aval sans modification) par les LSR de tansit qui ne le comprennent pas. Cela signifie que le message Path ne va pas être rejeté par les LSR qui ne comprennent pas l'objet. De cette façon, il est garanti que les attributs de LSP demandés vont atteindre le LSR de sortie.

Les attributs sont établis dans l'objet LSP_ATTRIBUTES selon quels attributs de LSP sont requis. Chaque attribut est défini dans une RFC et est accompagné d'une déclaration du comportement attendu. Ce comportement va inclure si l'attribut doit être traité par tout LSR qui le reconnaît, ou spécifiquement par le LSR de sortie. Donc, tout attribut qui doit être traité seulement par un LSR de sortie va être défini de cette façon – tout LSR de transit qui voit cet attribut soit en comprend la sémantique et l'ignore (le transmettant inchangé) soit ne comprend pas l'attribut et l'ignore (le transmettant inchangé) conformément aux règles de l'objet LSP_ATTRIBUTES.

La question restante est comment le LSR d'entrée peut savoir si le LSR de sortie a bien traité correctement l'attribut de LSP requis. Une autre partie de la définition de l'attribut (dans la RFC qui le définit) est si le rapport est exigé. Si le rapport est exigé, le LSR de sortie doit utiliser le sous objet Attributs RRO pour rapporter si il a traité l'attribut reçu.

Si un LSR de sortie comprend un attribut reçu comme obligatoire pour un LSR de sortie mais ne souhaite pas satisfaire la demande, il va rejeter le message Path. Si un LSR de sortie comprend l'attribut mais estime qu'il est facultatif et ne souhaite pas satisfaire la demande, il va rapporter sa non conformité dans le sous objet Attributs RRO. Si le LSR de sortie ne comprend pas l'attribut reçu, il peut rapporter explicitement la non confomité dans le sous objet Attributs RRO, ou il peut omettre le sous objet Attributs RRO, impliquant qu'il n'a pas satisfait à la demande.

 	10.2	Communication aux LSR de transit clés
Le traitement par les LSR de transit clés (comme les ABR et les ASBR) suit exactement celui du LSR de sortie. La seule différence est que la définition de l'attribut de LSP dans la RFC de définition va déclarer que l'attribut doit être traité par ces LSR de transit.

 	10.3	Communication à tous les LSR
Afin de forcer tous les LSR à examiner les attributs du LSP, on utilise l'objet LSP_REQUIRED_ATTRIBUTES. Le C-Num de cet objet est tel que tout LSR qui ne reconnaît pas l'objet doit rejeter un message Path reçu qui contient l'objet.

Un LSR qui reconnaît l'objet LSP_REQUIRED_ATTRIBUTES mais ne reconnaît pas un attribut va rejeter le message Path.

Un LSR qui reconnaît un attribut mais ne souhaite pas prendre en charge l'attribut réagit en accord avec la définition de l'attribut dans la RFC de définition. Cela peut permettre au LSR d'ignorer l'attribut et de le transmettre inchangé, ou peut exiger qu'il fasse échouer l'établissement du LSP. Le LSR peut de plus être obligé de rapporter si il prend en charge l'attribut en utilisant le sous objet Attributs RRO.

 	11.	Considérations relatives à l'IANA

Les allocations de l'IANA faites pour la [RFC4420] s'appliquent au présent document et sont mentionnées ici pour être complet.

L'IANA a mis à jour les entrées de registre créées pour la RFC 4420 pour faire référence au présent document, qui est maintenant la référence normative pour ces entrées. Le présent document ne fait pas d'autre demande d'action de l'IANA.

 	11.1	Nouveaux C-Nums et C-Types RSVP
Deux nouveaux C-Nums RSVP sont définis dans ce document et ont été alloués par l'IANA.

Objet LSP_ATTRIBUTES : le C-Num (valeur 197) est de la forme 11bbbbbb de sorte que les LSR qui ne reconnaissent pas l'objet vont l'ignorer mais le transmettre, sans examen ni modification, dans tous les messages résultant de ce message. Un C-Type est défini pour cet objet et a été alloué par l'IANA.

TLV d'attributs de LSP : valeur de C-Type = 1.

Objet LSP_REQUIRED_ATTRIBUTES : le C-Num (valeur 67) est de forme 0bbbbbbb de sorte que les LSR qui ne reconnaissent pas l'objet vont rejeter le message qui le porte avec une erreur "Classe d'objet inconnue". Un C-Type est défini pour cet objet et a été alloué par l'IANA.

TLV Attributs de LSP exigés : valeur de C-Type = 1.

 	11.2	Nouvel espace de TLV
Les deux nouveaux objets référenés ci-dessus sont construits à partir de TLV. Chaque TLV inclut un identifiant de type de 16 bits (le champ T). Les mêmes valeur de champ T sont applicables aux deux objets.

L'IANA a créé un nouveau registre et va gérer les identifiants de type de TLV comme suit :
- type de TLV (valeur du champ T)
- nom de TLV
- si il est permis sur un objet LSP_ATTRIBUTES
- si il est permis sur un objet LSP_REQUIRED_ATTRIBUTES.

Le présent document définit un type de TLV comme suit :
- type de TLV = 1
- nom de TLV = TLV Fanions d'attribut
- permis sur l'objet LSP_ATTRIBUTES
- permis sur l'objet LSP_REQUIRED_ATTRIBUTES

Les valeurs de nouveau type de TLV peuvent être seulement allouées par une action de consensus de l'IETF.

 	11.3	Fanions d'attributs
Le présent document fournit de nouveaux fanions de bit d'attributs à utiliser dans d'autres documents qui spécifient de nouveaux attributs RSVP-TE. Ces fanions sont présents dans la TLV Fanions d'attribut référencée au paragraphe précédent.

L'IANA a créé un nouveau registre et va gérer l'espace des fanions de bit d'attributs, en les numérotant dans la notation usuelle de l'IETF : en commençant à zéro et en continuant au moins jusqu'à 31.

Les nouveaux numéros de bits peuvent être alloués seulement par une action de consensus de l'IETF. Chaque bit devrait être retracé avec les qualités suivantes :
- numéro de bit
- RFC de définition
- nom du bit
- si il est significatif dans la TLV Fanions d'attribut sur un message Path
- si il est significatif dans la TLV Fanions d'attribut sur un message Resv
- si il est significatif dans le sous objet Attributs RRO.

Noter que cela signifie que tous les bits dans la TLV Fanions d'attribut et le sous objet Attributs RRO utilisent le même numéro de bit, sans considération de si il est utilisé dans un ou dans les deux endroits. Donc, une seule liste de bits est à tenir. (Il n'y aurait pas de sens dans le contexte de ce document qu'un bit n'ait pas de signification dans la TLV Fanions d'attribut ou le sous objet Attributs RRO .)

 	11.4	Nouveaux codes d'erreur
Le présent document définit les nouveaux codes d'erreurs et valeurs d'erreur suivantes. Les valeurs numériques ont été allouées par l'IANA.

Code d'erreur	Valeur d'erreur
   29	"TLV Attributs inconnue" : identifie le code de type de TLV inconnu.
   30	"Bit Attributs inconnu" : identifie le bit Attribut inconnu.

 	11.5	Nouvel identifiant de sous objet Record Route
Un nouveau sous objet est défini pour être inclus dans l'objet RECORD_ROUTE.

Le sous objet Attributs RRO est identifié par une valeur de type de 5.

 	12.	Considérations sur la sécurité

Le présent document ajoute deux nouveaux objets au message Path RSVP comme utilisé dans la signalisation MPLS et GMPLS, et un nouveau sous objet à l'objet RECORD_ROUTE porté dans de nombreux messages RSVP. Il n'introduit aucun nouveau problème de sécurité direct, et le lecteur est renvoyé aux considérations sur la sécurité exprimées dans les [RFC2205], [RFC3209], et [RFC3473].

Il est notable que toute demande de signalisation qui indique les préférences ou les attributs fonctionnels d'un LSP MPLS peut fournir à n'importe qui un accès non autorisé au contenu du message avec des informations sur le LSP qu'un administrateur pourrait souhaiter garder secrètes. Bien que le présent document ajoute de nouveaux objets pour signaler les attributs de LSP désirés, il ne contribue pas à ce problème, qui ne peut être traité de façon satisfaisante que par le chiffrement du contenu du message de signalisation.

De même, l'ajout des informations d'enregistrement d'attribut au RRO peut révéler des informations sur l'état du LSP et les capacités des LSR individuels que les opérateurs souhaitent garder secrètes. La même stratégie appliquée aux autres sous objets RRO s'applique aussi ici. Noter cependant qu'il y a une opposition entre notifier l'extrémité de tête de l'état du LSP aux LSR de transit, et cacher l'existence ou l'identite des LSR de transit.

 	13.	Remerciements

On doit créditer le groupe de travail OSPF de l'inspiration de la solution d'un problème similaire. Merci à Rahul Aggarwal de sa relecture attentive et de son soutien à ce travail. Merci aussi à Raymond Zhang, Kireeti Kompella, Philip Matthews, Jim Gibson, et Alan Kullberg de leurs apports. Comme souvent, merci à John Drake pour les utiles discussions hors ligne. Merci à Mike Shand pour sa relecture des directives d'acheminement et à Joel Halpern pour sa revue de la zone générale – tous deux ont relevé quelques imprécisions.

Merci à l'OIF qui a remarqué l'incohérence dans la RFC 4420 qui est corrigée dans le présent document. Alfred Hoenes a noté plusieurs erreurs typographiques.

 	14.	Changements de la RFC 4420 à la RFC 5420

Le présent document rend obsolète la [RFC4420]. Le seul changement est dans la Section 3. La Section 3 décrit la sémantique du champ Longueur de la TLV Attributes.

Avant le changement, le champ Longueur indiquait la longueur du seul champ Valeur. Après le changement, comme décrit à la Section 3, le champ Longueur indique la longueur de la TLV entière. Ce changement signifie que le présent document est cohérent avec le format de sous objet défini dans la [RFC3209] et avec le format de TLV défini dans la [RFC3471].

De plus, l'éditeur des RFC a fait de nombreux changements rédactionnels pour améliorer le texte et sa lisibilité. Ces changements peuvent être observés en comparant le texte du présent document avec celui de la [RFC4420].

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

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3471]	L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation", janvier 2003. (MàJ par RFC4201, RFC4328, RFC4872, RFC8359) (P.S.)

[RFC3473]	L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151,  8359)

 	16.	Références pour information

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

[RFC4090]	P. Pan et autres, "Extensions de reroutage rapide à RSVP-TE pour les tunnels de LSP", mai 2005. (P.S. ; MàJ par RFC8271, RFC8537, RFC8796)

[RFC4206]	K. Kompella, Y. Rekhter, "Hiérarchie de chemins commutés par étiquettes (LSP) avec l'ingénierie de trafic (TE) de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (P.S.)

[RFC4420]	A. Farrel et autres, "Codage des attributs pour l'établissement de chemin à commutation d'étiquettes (LSP) de la commutation d'étiquettes multiprotocoles (MPLS) en utilisant le protocole de réservation de ressources avec extensions d’ingénierie de trafic (RSVP-TE)", février 2006. (MàJ RFC3209, RFC3473 ; P.S.  ; Obsolète, voir RFC5420)

 	Adresse des auteurs
Adrian Farrel	Dimitri Papadimitriou	
Old Dog Consulting	Alcatel	
téléphone :  +44 (0) 1978 860944	Fr. Wellesplein 1,	
mél :  adrian@olddog.co.uk 	B-2018 Antwerpen, Belgium	
	téléphone :  +32 3 240-8491	
	mél :  dimitri.papadimitriou@alcatel.be 	

Jean Philippe Vasseur	Arthi Ayyangar	
Cisco Systems, Inc.	Juniper Networks, Inc.	
1414 Massachusetts Avenue	1194 N.Mathilda Ave	
Boxborough, MA - 01719	Sunnyvale, CA 94089	
USA	USA	
mél : jpv@cisco.com 	mél : arthi@juniper.net