Groupe de travail Réseau	S. Sivabalan, éditeur, Cisco Systems, Inc.
Request for Comments : 5455	J. Parker, Cisco Systems, Inc.
Catégorie : Sur la voie de la normalisation	S. Boutros, Cisco Systems, Inc.
	K. Kumaki, KDDI R&D Laboratories, Inc.
Traduction Claude Brière de L'Isle	mars 2009

Objet Classe-Type à capacité Diffserv pour le protocole de communication d'élément de calcul de chemin

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.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document spécifie un objet CLASSTYPE pour prendre en charge l'ingénierie de trafic à capacité Diffserv (DS-TE, Diffserv-Aware Traffic Engineering) où le calcul de chemin est effectué à l'aide d'un élément de calcul de chemin (PCE, Path Computation Element).
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans le document	2
2. Terminologie	2
3. Objet CLASSTYPE	2
3.1 Définition d'objet	3
3.2 Message de demande de calcul de chemin avec l'objet CLASSTYPE	3
3.3 Traitement de l'objet CLASSTYPE	3
3.4 Détermination de la classe d'ingénierie du trafic (TE-Class)	4
3.5 Signification de Class-Type et de TE-Class	4
3.6 Codes d'erreur pour l'objet CLASSTYPE	4
4. Considérations sur la sécurité	4
5. Considérations relatives à l’IANA	5
6. Remerciements	5
7. Références	5
7.1 Références normatives	5
7.2 Références pour information	5
Adresse des auteurs	6

 	1.	Introduction

La [RFC5440] spécifie le protocole de communication d'élément de calcul de chemin (PCEP, Path Computation Element Communication Protocol) pour les communications entre un client de calcul de chemin (PCC, Path Computation Client) et un élément de calcul de chemin (PCE, Path Computation Element) ou entre deux PCE, conformément à la [RFC4657].

L'ingénierie du trafic MPLS à capacité Diffserv (DS-TE, Diffserv-aware MPLS Traffic Engineering) vise les exigences fondamentales pour être capable d'appliquer des contraintes de bande passante différentes pour différentes classes de trafic.  Elle décrit les mécanismes pour réaliser une ingénierie du trafic par classe, plutôt que sur une base agrégée à travers toutes les classes en appliquant des contraintes de bande passante (BC, Bandwidth Constraint) sur les différentes classes. Les exigences pour DS-TE et les extensions de protocole associées sont spécifiées respectivement dans les [RFC3564] et [RFC4124].

Selon la [RFC4657], PCEP doit prendre en charge le type de classe de trafic comme une contrainte spécifique de MPLS-TE. Cependant, sous sa forme présente, PCEP [RFC5440] n'a pas la capacité de spécifier le type de classe dans la demande de calcul de chemin.

Dans le présent document, on définit un nouvel objet PCEP appelé CLASSTYPE, qui porte le type de classe du LSP TE dans la demande de calcul de chemin. Durant le calcul de chemin, un PCE utilise le type de classe pour identifier la contrainte de bande passante du LSP TE.

 	1.1	Conventions utilisées dans le document
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.	Terminologie

CT (Class-Type) type de classe : ensemble de circuits de trafic gouvernés par un ensemble de contraintes de bande passante.  Utilisé pour les besoins de l'allocation de la bande passante de la liaison, l'acheminement fondé sur la contrainte et le contrôle d'admission. Un circuit de trafic donné appartient au même CT sur toutes les liaisons.

DS-TE (Diffserv-Aware Traffic Engineering) : ingénierie du trafic à capacité Diffserv.

LSR (Label Switching Router) : routeur de commutation d'étiquettes.

LSP (Label Switched Path) : chemin commuté par étiquettes.

PCC (Path Computation Client) : client de calcul de chemin ; tout client d'application qui demande qu'un calcul de chemin soit effectué par un élément de calcul de chemin.

PCE (Path Computation Element) : élément de calcul de chemin, entité (composant, application, ou nœud de réseau) qui est capable de calculer un chemin de réseau ou route fondé sur un graphe de réseau et d'appliquer des contraintes de calcul.

Homologue PCEP : élément impliqué dans une session PCEP (c'est-à-dire, un PCC ou le PCE).

Classe TE : paire consistant en un type de classe et une priorité de préemption permise pour ce type de classe. Un LSP qui transporte un circuit de trafic de ce type de classe peut utiliser cette priorité de préemption comme priorité d'établissement, comme priorité de garde, ou les deux.

LSP TE (Traffic Engineering Label Switched Path) : chemin commuté par étiquettes d'ingénierie du trafic.

Circuit de trafic : agrégation de flux de trafic de la même classe (c'est-à-dire, traités de façon équivalente du point de vue du DS-TE) qui est placé dans un LSP TE.

 	3.	Objet CLASSTYPE

L'objet CLASSTYPE est facultatif et est utilisé pour spécifier le type de classe d'un LSP TE. Cet objet n'est significatif que dans la demande de calcul de chemin, et est ignoré dans le message de réponse de chemin. Si le LSP TE pour lequel le chemin à calculer appartient à la classe 0, la demande de calcul de chemin NE DOIT PAS contenir d'objet CLASSTYPE. Cela permet la rétro compatibilité avec un PCE qui ne prend pas en charge l'objet CLASSTYPE.

 	3.1	Définition d'objet
L'objet CLASSTYPE contient un en-tête d'objet commun PCEP de 32 bits défini dans la [RFC5440] suivi par un autre corps d'objet de mot de 32 bits comme le montre 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  En-tête PCEP commun                          |
+---------------+---------------+---------------+---------------+
|            Réservé                                      | CT  |
+---------------+---------------+---------------+---------+-----+

Figure 1 : Format d'objet CLASSTYPE

Les champs dans l'en-tête d'objet commun sont traités comme spécifié dans la [RFC5440]. Les valeurs de classe d'objet et de type d'objet sont respectivement 22 et 1. Si il est inclus, l'objet CLASSTYPE doit être pris en compte par le PCE. À ce titre, le fanion P DOIT être établi. Le fanion I est ignoré.

Le corps de l'objet CLASSTYPE contient les champs suivants :

CT : champ de 3 bits qui indique le type de classe. Les valeurs permises sont 1, 2, ... , 7. La valeur de 0 est réservée.

Réservé : champ de 29 bits réservés. Il DOIT être réglé à zéro à l'émission et DOIT être ignoré à réception.

 	3.2	Message de demande de calcul de chemin avec l'objet CLASSTYPE
La [RFC5440] spécifie l'ordre d'insertion des objets dans les messages PCEP. Le présent document spécifie que l'objet CLASSTYPE doit être inséré après les objets END-POINT comme montré ci-dessous :

Le format d'un message de demande de calcul de chemin (PCReq, Path Computation Request) est le suivant :

<Message PCReq>::= <En-tête commun> [<liste de SVEC>] <liste de demandes>

où :
<liste de svec>::=<SVEC>[<liste de svec>]
<liste de demandes>::=<demande>[<liste de demandes>]
<demande>::= <RP>
                      <END-POINTS>
                      [<CLASSTYPE>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<liste de métriques>]
                      [<RRO>]
                      [<IRO>]
                      [<LOAD-BALANCING>]

où :
<liste de métriques>::=<METRIC>[<liste de métriques>]

Noter qu'une mise en œuvre DOIT former les messages PCEP en utilisant les règles d'ordre d'objets spécifiées en utilisant le format Backus-Naur. Voir les détails dans la [RFC5511].

 	3.3	Traitement de l'objet CLASSTYPE
Si le LSP est associé au type de classe N (1 ≤ N ≤ 7) le PCC qui génère la PCReq DOIT inclure l'objet CLASSTYPE dans le message PCReq avec le champ Class-Type (CT) réglé à N.

Si une demande de calcul de chemin contient plusieurs objets CLASSTYPE, seul le premier est significatif ; les objets CLASSTYPE suivants DOIVENT être ignorés et NE DOIVENT PAS être transmis.
.
Si l'objet CLASSTYPE n'est pas présent dans le message de demande de calcul de chemin, le LSR DOIT associer le type de classe 0 au LSP.

Un message de réponse de calcul de chemin NE DOIT PAS inclure d'objet CLASSTYPE. Si un PCE a besoin de transmettre une demande de calcul de chemin contenant l'objet CLASSTYPE à un autre PCE, il DOIT mémoriser le Class-Type du LSP TE afin d'achever le calcul de chemin quand la réponse de calcul de chemin arrive.

Un PCE qui ne reconnaît pas l'objet CLASSTYPE DOIT rejeter le message PCEP entier et DOIT envoyer un message d'erreur PCE avec le type d'erreur "Objet inconnu" ou "Objet non pris en charge", défini dans la [RFC5440].

Un PCE qui reconnaît l'objet CLASSTYPE, mais trouve que le fanion P n'est pas établi dans l'objet CLASSTYPE, DOIT envoyer un message d'erreur PCE à l'envoyeur avec le type d'erreur et la valeur d'erreur spécifiés dans la [RFC5440].

Un PCE qui reconnaît l'objet CLASSTYPE, mais ne prend pas en charge le type de classe particulier, DOIT envoyer un message d'erreur PCE à l'envoyeur avec le type d'erreur "Erreur TE à capacité Diffserv" et la valeur d'erreur de "Type de classe non pris en charge" (valeur d'erreur 1).

Un PCE qui reconnaît l'objet CLASSTYPE, mais détermine que la valeur de type de classe n'est pas valide (c'est-à-dire, valeur de Class-Type 0) DOIT envoyer une erreur PCE à l'envoyeur avec le type d'erreur "Erreur TE à capacité Diffserv" et une valeur d'erreur de "Type de classe invalide" (valeur d'erreur 2).

 	3.4	Détermination de la classe d'ingénierie du trafic (TE-Class)
Comme spécifié dans la RFC 4124, un CT et une priorité de préemption se transposent en une classe d'ingénierie de trafic (TE-class, Traffic Engineering Class) et il peut y avoir jusqu'à 8 classes TE. La valeur de TE-class est utilisée pour déterminer la bande passante non réservée sur les liaisons durant le calcul de chemin. Dans le cas d'un PCE, la valeur de CT portée dans l'objet CLASSTYPE et la priorité d'établissement dans l'objet Attribut  de LSP (LSPA) sont utilisées pour déterminer la classe de TE correspondant à la demande de calcul de chemin. Si l'objet LSPA est absent, la priorité d'établissement est supposée être 0.

 	3.5	Signification de Class-Type et de TE-Class
Pour assurer un fonctionnement cohérent de DS-TE, un PCE et un PCC devraient avoir une compréhension commune d'un type de classe et classe TE DS-TE particuliers. Si une demande de calcul de chemin traverse une frontière de système autonome (AS, Autonomous System) ils devraient avoir une signification globale dans tous les domaines. L'application de cette signification globale sort du domaine d'application de ce document.

 	3.6	Codes d'erreur pour l'objet CLASSTYPE
Le présent document définit les types et valeurs d'erreur suivants :

Type d'erreur	Signification
         12  	Erreur TE à capacité Diffserv
                    valeur d'erreur=1 : Class-Type non pris en charge
                    valeur d'erreur=2 : Class-Type invalide
                    valeur d'erreur=3 : Class-Type et priorité d'établissement ne forment pas une classe TE configurée

 	4.	Considérations sur la sécurité

Le présent document n'introduit pas de nouveau problème de sécurité. Les considérations sur la sécurité de PCEP [RFC5440] restent pertinentes.

 	5.	Considérations relatives à l’IANA

L'IANA tient un registre des paramètres de PCEP. Il contient un sous-registre pour les objets PCEP. L'IANA a fait les allocations suivantes dans ce registre :

Classe d'objet	Nom	Référence
          22	CLASSTYPE	RFC 5455
	Object-Type
	1 : Class-Type	RFC 5455

L'IANA a alloué les types et valeurs d'erreur suivantes :

Type d'erreur	Signification	Référence
          12	Erreur TE à capacité Diffserv	RFC 5455
valeur d'erreur = 1 : Type de classe non pris en charge	RFC 5455
valeur d'erreur = 2 : Type de classe invalide	RFC 5455
valeur d'erreur = 3 : Class-Type et priorité d'établissement ne forment pas une classe TE configurée	RFC 5455

 	6.	Remerciements

Les auteurs tiennent à remercier Jean Philippe Vasseur, Adrian Farrel, et Zafar Ali de leurs précieux commentaires.

 	7.	Références
 	7.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)

[RFC4124]	F. Le Faucheur, éd., "Extensions de protocole pour la prise en charge de l'ingénierie de trafic MPLS avec capacité Diffserv", juin 2005. (P.S.)

[RFC5440]	JP. Vasseur et autres, "Protocole de communication d'élément de calcul de chemin (PCEP)", mars 2009. (P. S. ; MàJ par RFC7896, RFC8253, RFC8356, 9488)

 	7.2	Références pour 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)

[RFC4657]	J. Ash. et J.L. Le Roux, éditeurs, "Exigences génériques du protocole de communication par élément de calcul de chemin (PCE)", septembre 2006.

[RFC5511]	A. Farrel, "Forme Backus-Naur d'acheminement (RBNF) : syntaxe utilisée pour former les règles de codage dans diverses spécifications de protocole d'acheminement", avril 2009. (P.S.)

 	Adresse des auteurs

Siva Sivabalan	Jon Parker	Sami Boutros	Kenji Kumaki	
Cisco Systems, Inc.	Cisco Systems, Inc.	Cisco Systems, Inc.	KDDI R&D Laboratories, Inc.	
2000 Innovation Drive	2000 Innovation Drive	3750 Cisco Way	2-1-15 Ohara Fujimino	
Kanata, Ontario, K2K 3E8	Kanata, Ontario, K2K 3E8	San Jose, California 95134	Saitama 356-8502,	
Canada	Canada	USA	 APAN	
mél : msiva@cisco.com	mél : jdparker@cisco.com	mél : sboutros@cisco.com	mél : ke-kumaki@kddi.com