Groupe de travail Réseau	E. Oki, University of Electro-Communications
Request for Comments: 5521	T. Takeda, NTT
Catégorie : Sur la voie de la normalisation	A. Farrel, Old Dog Consulting
Traduction Claude Brière de L'Isle	avril 2009

Extensions au protocole de communication d'élément de calcul de chemin (PCEP) pour les exclusions de chemin

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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é
L'élément de calcul de chemin (PCE, Path Computation Element) fournit des fonctions de calcul de chemin pour la prise en charge de l'ingénierie du trafic (TE, traffic engineering) dans les réseaux de commutation d'étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) et de MPLS généralisé (GMPLS, Generalized MPLS).

Quand un client de calcul de chemin (PCC, Path Computation Client) demande un chemin à un PCE, il peut être utile que le PCC spécifie, comme contraintes du calcul de chemin, des nœuds abstraits, des ressources, et des groupes de liaisons à risques partagés (SRLG, Shared Risk Link Group) qui sont à exclure explicitement du chemin calculé . De telles contraintes sont appelées des "exclusions de chemin".

Le protocole de communication de PCE (PCEP, PCE Communication Protocol) est conçu comme un protocole de communication entre les PCC et les PCE. Le présent document présente les extensions à PCEP pour les exclusions de chemin.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans ce document	2
2. Procédures et extensions du protocole	2
2.1 Objet Exclude Route (XRO)	3
2.2 Exclusion explicite de chemin	6
3. Exclusion de chemin avec confidentialité	7
3.1 Objet Exclude Route (XRO) portant Path-Key	7
4. Considérations relatives à l'IANA	7
4.1 Objets PCEP	7
4.2 Nouveau sous objet pour l'objet Include Route	8
4.3 Valeurs de champ d'objet Erreur	8
4.4 Fanions Exclude Route	8
5. Considérations de gestion	8
6. Considérations sur la sécurité	9
7. Références	9
7.1 Références normatives	9
7.2 Références pour information	9
Remerciements	10
Adresse des auteurs	10

 	1.	Introduction

L'élément de calcul de chemin (PCE, Path Computation Element) défini dans la [RFC4655] est une entité qui est capable de calculer un chemin dans le réseau ou un chemin fondé sur un graphe de réseau, et en appliquant des contraintes de calcul. Un client de calcul de chemin (PCC, Path Computation Client) peut faire des demandes à un PCE pour que des chemins soient calculés.

Quand un PCC demande un chemin à un PCE, il peut être utile que le PCC spécifie des nœuds abstraits, des ressources, et des groupes de liaisons à risques partagés (SLRG, Shared Risk Link Group) qui vont être explicitement exclus du chemin.

Par exemple, des chemins disjoints pour des chemins de commutation d'étiquette (LSP, Label Switched Path) inter-domaines peuvent être calculés en coopération entre des PCE, chacun calculant des segments des chemins à travers un domaine. Afin de réaliser le calcul de chemin pour un chemin secondaire (de secours) un PCE peut agir comme PCC pour demander à un autre PCE un chemin qui doit être de nœud/liaison/SRLG disjoint du chemim principal (actif). Un autre exemple est quand un opérateur de réseau veut un chemin pour éviter des nœuds spécifiés pour des raisons administratives, peut-être parce que les nœuds spécifiés vont être hors service dans un futur proche.

La [RFC4657] spécifie des exigences génériques pour un protocole de communication entre les PCC et les PCE. Les contraintes génériques décrites dans la [RFC4657] incluent des exclusions de chemin pour des liaisons, des nœuds, et des SRLG. C'est-à-dire, l'exigence de prise en charge des exclusions de chemin au sein du protocole de communication PCC-PCE est déjà établie.

Le protocole de communication de PCE (PCEP) est conçu comme protocole de communication entre les PCC et PCE et est défini dans la [RFC5440]. Le présent document présente des extensions à PCEP pour satisfaire les exigences d'exclusions de chemin décrites aux paragraphes 5.1.4 et 5.1.16 de la [RFC4657].

Noter que les extensions de signalisation à MPLS-TE et GMPLS pour communiquer les exclusions de chemin entre nœuds de réseau pour des chemins de commutation d'étiquettes (LSP) spécifiques sont décrites dans la [RFC4874]. Les exclusions de chemin peuvent être spécifiées durant les demandes de provisionnement pour des LSP spécifiques en réglant l'objet mplsTunnelHopInclude de la MIB MPLS-TE-STD défini dans la [RFC3812] à faux (2).

 	1.1	Conventions utilisées dans ce 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.	Procédures et extensions du protocole

Cette section décrit les procédures adoptées par un PCE qui traite une demande de calcul de chemin avec exclusions de chemin reçue d'un PCC, et définit comment ces exclusions sont codées.

Il y a deux types d'exclusion de chemin décrits dans la [RFC4874].

1.	Exclusion de certains nœuds abstraits ou ressources du chemin entier. Cet ensemble de nœuds abstraits est appelé la "liste des chemins exclus".

2.	Exclusion de certains nœuds abstraits ou ressources entre une paire spécifique de nœuds abstraits présents dans un chemin explicite. De telles exclusions spécifiques sont appelées une "exclusion explicite de chemin".

Le présent document définit des extensions au protocole pour permettre à un PCC de spécifier les deux types d'exclusions de chemin à un PCE sur une demande de calcul de chemin.

Un nouvel objet PCEP, l'objet Chemin exclu (XRO, Exclude Route Object) est défini pour porter la liste des chemins exclus. L'objet Chemin à inclure (IRO, Include Route Object) existant dans PCEP [RFC5440] est modifié par l'introduction d'un nouveau sous objet IRO, le sous objet Exclusion explicite de chemin (EXRS, Explicit Exclusion Route) pour porter les exclusions explicites de chemin.

 	2.1	Objet Exclude Route (XRO)
 	2.1.1	Définition
Le XRO est FACULTATIF et PEUT être porté dans les messages Demande de calcul de chemin (PCReq, Path Computation Request) et Réponse de calcul de chemin (PCRep, Path Computation Reply).

Quand il est présent dans un message PCReq, le XRO donne une liste de ressources du réseau qu'il est demandé au PCE d'exclure du chemin qu'il calcule. Les fanions associés à chaque membre de la liste disent au PCE si les ressources du réseau doivent être exclues du chemin calculé, ou si le PCE devrait faire des efforts pour exclure les ressources du chemin calculé.

Le XRO PEUT être utilisé dans un message PCRep qui porte l'objet NO-PATH (c'est-à-dire, qui rapporte un échec du calcul de chemin) pour indiquer l'ensemble d'éléments du XRO original qui ont empêché le PCE de trouver un chemin.

Le XRO PEUT aussi être utilisé dans un message PCRep pour un calcul de chemin réussi quand le PCE souhaite fournir un ensemble d'exclusions à signaler durant l'établissement du LSP en utilisant les extensions au protocole de réservation de ressources avec ingénierie du trafic (RSVP-TE, Resource Reservation Protocol-TE) [RFC4874].

La classe d'objet XRO est 17.

Le type d'objet XRO est 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Réservé                |   Fanions                   |F|
+---------------+---------------+---------------+-------------+-+
|                                                               |
//                        (Sous objets)                         //
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 1 : Format de corps XRO

Réservé : 16 bits - DOIT être réglé à zéro à l'émission et DEVRAIT être ignoré à réception.

Fanions: 16 bits - Le fanion suivant est actuellement défini :

F (Fail) : échec. 1 bit : quand il est établi, le PCC demandeur exige le calcul d'un nouveau chemin pour un LSP TE existant qui a échoué. Si le bit F est établi, le chemin du LSP TE existant DOIT être fourni dans le message PCReq au moyen d'un objet Record Route (RRO, Record Route Object) défini dans la [RFC5440]. Cela permet au calcul de chemin de tenir compte du chemin précédent et des ressources réservées pour éviter une double réservation de bande passante si la base de données d'ingénierie du trafic (TED, Traffic Engineering Database) n'a pas encore été mise à jour ou si les ressource correspondantes n'ont pas encore été libérées. Cela va généralement être utilisé en conjonction avec l'exclusion du calcul de chemin de la ressource défaillante qui a causé l'échec du LSP.

Sous objets : le XRO est constitué d'un ou plusieurs sous objets. Un XRO sans sous objets NE DOIT PAS être envoyé et DEVRAIT être ignoré à réception.

Dans les définitions de sous objet suivantes, un ensemble de champs a la signification suivante :

X : le bit X indique si l'exclusion est obligatoire ou désirée. 0 indique que la ressource spécifiée DOIT être exclue du chemin calculé par le PCE. 1 indique que la ressource spécifiée DEVRAIT être exclue du chemin calculé par le PCE, mais PEUT être incluse selon la politique du PCE et en l'absence d'un chemin viable qui satisfasse les autres contraintes et exclue la ressource.

Type : le type du sous objet. Les types de sous objet suivants sont définis.

Type	Sous objet
  1	préfixe IPv4 
  2	préfixe IPv6
  4	identifiant d'interface non numérotée
32	numéro de système autonome
34	SRLG

Longueur : longueur du sous objet incluant les champs Type et Longueur.

Longueur de préfixe : lorsque présent, ce champ peut être utilisé pour indiquer un ensemble d'adresses correspondant à un préfixe. Si le sous objet indique une seule adresse, la longueur de préfixe DOIT être réglée à la longueur totale de l'adresse.

Attribut : le champ Attribut indique comment le sous objet d'exclusion est à interpréter.

0 Interface : le sous objet est à interpréter comme une interface ou ensemble d'interfaces. Toutes les interfaces identifiées par le sous objet sont à exclure du chemin calculé en accord avec le réglage du bit X. Cette valeur est valide seulement pour les types de sous objet 1, 2, et 3.

1 Nœud : le sous objet est à interpréter comme un nœud ou ensemble de nœuds. Tous les nœuds identifiés par le sous objet sont à exclure du chemin calculé en accord avec le réglage du bit X. Cette valeur n'est valide que pour les types de sous objet 1, 2, 3, et 4.

2 SRLG : le sous objet identifie explicitement un SRLG ou indique tous les SRLG associés à la ou les ressources identifiées par le sous objet. Les ressources qui partagent un SRLG avec celles identifiées sont à exclure du chemin calculé conformément au réglage du bit X. Cette valeur est valide pour tous les sous objets.

Réservé : les champs réservés dans des sous objets DOIVENT être transmis à zéro et DEVRAIENT être ignorés à réception.

Les sous objets sont codés comme suit :

Sous objet Préfixe IPv4 

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type = 1   |    Longueur   | Adresse IPv4 (4 octets)       |
+-+-------------+---------------+---------------+---------------+
|   Adresse IPv4 (suite)        | Long. préfixe |   Attribut    |
+---------------+---------------+---------------+---------------+

Sous objet Préfixe IPv6

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type = 2   |     Longueur    | Adresse IPv6 (16 octets)    |
+-+-------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)          | Long. préfixe |   Attribut    |
+---------------+---------------+---------------+---------------+

Sous objet Identifiant d'interface non numérotée

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type = 3   |   Longueur    |    Réservé    |  Attribut     |
+-+-------------+---------------+---------------+---------------+
|                     Identifiant de routeur TE                 |
+---------------+---------------+---------------+---------------+
|                     Identifiant d'interface                   |
+---------------+---------------+---------------+---------------+

Les champs Identifiant de routeur TE et Identifiant d'interface sont définis dans la [RFC3477].

Sous objet Numéro de système autonome

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type = 4   |    Longueur   |  Numéro d'AS (2 octets)       |
+-+-------------+---------------+---------------+---------------+

Noter que comme dans les autres objets PCEP [RFC5440] et RSVP-TE [RFC3209], aucune prise en charge des numéros de système autonome à 4 octets n'est fournie. Il est prévu que lorsque des numéros d'AS à 4 octets deviendront plus courants, PCEP et RSVP-TE seront mis à jour de façon cohérente pour ajouter cette prise en charge.

Sous objet SRLG

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|  Type = 5   |    Longueur   | Identifiant de SRLG (4 octets)|
+-+-------------+---------------+---------------+---------------+
|  Identifiant de SRLG (suite)  |    Réservé    |  Attribut     |
+---------------+---------------+---------------+------------L--+

L'attribut DEVRAIT être réglé à deux (2) et DEVRAIT être ignoré à réception.

 	2.1.2	Règles de traitement
Un PCC construit un XRO pour coder toutes les ressources qu'il souhaite que le PCE exclue du chemin qu'il lui demande de calculer. Pour chaque exclusion, le PCC met à zéro le bit X pour indiquer qu'il est exigé que le PCE exclue les ressources, ou établit le bit X pour indiquer que le PCC désire simplement que les ressources soient exclues. Pour chaque exclusion, le PCC établit aussi le champ Attribut pour indiquer comment le PCE devrait interpréter le contenu du sous objet Exclusion.

Quand un PCE reçoit un message PCReq, il cherche un XRO pour voir si des exclusions sont demandées. Si le PCE trouve plus d'un XRO, il DOIT utiliser le premier du message et DOIT ignorer les instances suivantes.

Si le PCE ne reconnaît pas le XRO, il DOIT retourner un message PCErr avec le type d'erreur "Objet inconnu" comme  décrit dans la [RFC5440].

Si le PCE ne veut pas ou est incapable de traiter le XRO, il DOIT retourner un message PCErr avec le type d'erreur "Objet non pris en charge" et suivre les procédures pertinentes décrites dans la [RFC5440].

Si le PCE traite le XRO et tente de calculer un chemin, il DOIT respecter les exclusions demandées comme exprimées dans le XRO. C'est-à-dire, le chemin retourné NE DOIT PAS inclure de ressources codées avec le bit X à zéro, et NE DEVRAIT PAS inclure de ressources avec le bit X établi sauf si des chemins de remplacement qui satisfont les autres contraintes exprimées dans la PCReq sont indisponibles.

Quand un PCE retourne un chemin dans une PCRep, il PEUT aussi fournir un XRO. Un XRO dans un message PCRep avec l'objet NO-PATH indique que l'ensemble d'éléments du XRO original a empêché le PCE de trouver un chemin. Par ailleurs, si un XRO est présent dans un message PCRep sans un objet NO-PATH, le PCC DEVRAIT applique le contenu en utilisant les mêmes règles que dans la [RFC4874] et le PCC ou un LSR correspondant DEVRAIT signaler un XRO RSVP-TE pour indiquer les exclusions que les LSR en aval devraient appliquer. Cela peut être particulièrement utile dans les scénarios dc calcul de chemin par domaine [RFC5152].

 	2.2	Exclusion explicite de chemin
 	2.2.1	Définition
L'exclusion explicite de chemin définit les éléments de réseau qui ne doivent ou ne devraient pas être utilisés sur le chemin entre deux nœuds abstraits ou ressources indiqués explicitement dans l'objet Chemins à inclure (IRO, Include Route Object) [RFC5440]. Cette information est codée en définissant un nouveau sous objet pour le IRO.

Le nouveau sous objet IRO, le sous objet Exclusion explicite de chemin (EXRS) a le type 33 (voir la Section 4). Le EXRS contient un ou plusieurs sous objets qui lui sont propres. Un EXRS NE DOIT PAS être envoyé sans sous objets, et si il est reçu sans sous objets, il DOIT être ignoré.

Le format de l'EXRS est le 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|    Type     |    Longueur   |           Réservé             |
+-+-------------+---------------+---------------+---------------+
|                                                               |
//                Un ou plusieurs sous objets EXRS              //
|                                                               |
+---------------+---------------+---------------+---------------+

L : DOIT être réglé à zéro à l'émission et DOIT être ignoré à réception.

Réservé  : DOIT être réglé à zéro à l'émission et DEVRAIT être ignoré à réception.

Le sous objet EXRS peut porter tout sous objet défini pour l'inclusion dans le XRO par le présent document ou des documents futurs. La signification des champs des sous objets XRO est inchangée quand les sous objets sont inclus dans un EXRS, sauf que la portée de l'exclusion est limitée au seul bond entre l'élément précédent et les éléments suivants dans l'IRO.

 	2.2.2	Règles de traitement
Un PCC qui fournit un chemin explicite partiel à un PCE dans un IRO PEUT aussi spécifier des exclusions explicites en incluant un ou plusieurs EXRS dans le IRO.

Si un PCE qui ne prend pas en charge l'utilisation de EXRS reçoit un IRO dans un message PCReq qui contient un EXRS, il va répondre conformément aux règles pour un objet mal formé, comme décrit dans la [RFC5440]. Le PCE PEUT aussi inclure le IRO dans la réponse PCErr pour indiquer dans quel cas le IRO DEVRAIT être terminé immédiatement après le EXRS non reconnu.

Si un PCE qui prend en charge le EXRS dans un IRO analyse un IRO et rencontre un EXRS qui contient un sous objet qu'il ne prend pas en charge ou ne reconnaît pas, il DOIT agir conformément au réglage du bit X dans le sous objet. Si le bit X est à zéro, le PCE DOIT répondre avec une PCErr de type d'erreur "Sous objet EXRS non reconnu" et régler la valeur d'erreur au code de type du sous objet EXRS (voir la Section 4). Si le bit X est établi, le PCE PEUT répondre avec une PCErr comme déjà indiqué ou PEUT ignorer le sous objet EXRS : ce choix est une décision de politique locale.

Si un PCE analyse un IRO et rencontre un sous objet EXRS qu'il reconnaît, il DOIT agir conformément aux exigences exprimées dans le sous objet. C'est-à-dire, si le bit X est à zéro, le PCE NE DOIT PAS produire un chemin qui inclut des ressources identifiées par le sous objet EXRS dans le chemin entre le nœud abstrait précédent dans le IRO et le prochain nœud abstrait dans le IRO. Si le bit X est établi, le PCE NE DEVRAIT PAS produire un chemin qui inclut des ressources identifiées par le sous objet EXRS dans le chemin entre le nœud abstrait précédent dans le IRO et le prochain nœud abstrait dans le IRO sauf si il n'est pas possible de construire un chemin qui évite cette ressource tout en se conformant aux autres contraintes exprimées dans le message PCReq.

Un calcul de chemin réussi rapporté dans un message PCRep DOIT inclure un ERO pour spécifier le chemin qui a été calculé comme spécifié dans la [RFC5440]. Cet ERO PEUT contenir des exclusions de chemin spécifiques en utilisant le EXRS comme spécifié dans la [RFC4874].

Si le calcul de chemin échoue et qu'une PCErr est retournée sans un objet NO-PATH, le PCE PEUT inclure un IRO pour faire rapport des bonds qui ne pourraient pas être satisfaits, comme décrit dans la [RFC5440], et cet IRO PEUT inclure des EXRS.

 	3.	Exclusion de chemin avec confidentialité
 	3.1	Objet Exclude Route (XRO) portant Path-Key
 	3.1.1	Définition
Dans le calcul de chemins inter-domaines divers fondé sur le PCE, un XRO peut être utilisé pour trouver un chemin de secours (secondaire). Une approche de calcul de chemin séquentielle peut être appliquée à cette fin, où un chemin actif (principal) est calculé en premier et un chemin de secours qui doit être un chemin de nœud/liaison/SRLG disjoint du chemin actif est ensuite calculé [RFC5298]. Le calcul de chemin rétro récurrent (BRPC, Backward Recursive Path Computation) peut être utilisé pour le calcul de chemin inter-domaines [RFC5441].

Dans certains cas de calcul inter-domaines (par exemple, lorsque les domaines sont administrés par des fournisseurs de service différents) la confidentialité doit être conservée. Pour le calcul de chemin principal, pour préserver la confidentialité, au lieu d'exprimer explicitement le chemin calculé, des sous objets Path-Key (PKS, Path-Key Subobject) [RFC5520] sont portés dans l'objet Chemin explicite (ERO) dans le message PCRep.

Donc, durant le calcul de chemins inter-domaines divers, il peut être nécessaire de demander la diversité d'un chemin qui n'est pas entièrement connu et où un segment du chemin est représenté par un PKS. Cela signifie que un PKS peut être présent comme un sous objet du XRO sur un message PCReq.

Le format et la définition du PKS quand il apparaît comme sous objet XRO sont définis dans la [RFC5520], excepté pour la définition du bit L. Le bit L du sous objet PKS dans le XRO DOIT être ignoré.

 	3.1.2	Règles de traitement
On considère que BRPC est appliqué pour les deux calculs de chemin actif et de secours de manière séquentielle. D'abord, le PCC demande au PCE le calcul d'un chemin actif. Après l'achèvement du traitement de BRPC, le PCC reçoit le résultat du calcul de chemin actif exprimé dans un ERO dans un message PCRep. L'ERO peut inclure des PKS si certains segments du chemin sont à garder confidentiels.

Pour le calcul de chemin de secours, quand le PCC construit un message PCReq, il inclut le chemin actif entier dans le XRO afin que le chemin calculé soit disjoint de nœud/liaison du chemin actif. Le XRO peut aussi inclure des SRLG pour s'assurer de la diversité de SRLG avec le chemin actif. Si l'ERO du chemin actif inclut des sous objets PKS, ils sont aussi inclus dans le XRO pour permettre au PCE d'assurer la diversité.

Un ensemble de PCE pour le calcul de chemin de secours peut être le même que celui pour le calcul de chemin actif, ou il peut être différent.

-	PCE identiques : dans le cas où les mêmes PCE sont utilisés pour les deux calculs de chemin, le traitement est le suivant. Durant le traitement de BRPC pour le calcul de chemin de secours, un PCE peut rencontrer un PKS lorsque il traite le XRO quand il crée une arborescence de chemin virtuelle (VPT) dans son propre domaine. Le PCE restitue l'identifiant de PCE provenant du PKS, se reconnaît lui-même, et convertit le PKS en un ensemble de sous objets XRO qu'il utilise pour le calcul local pour créer le VPT. Les sous objets XRO créés de cette façon NE DOIVENT PAS être partagés avec d'autres PCE. Les autres opérations sont les mêmes que pour BRPC.

-	PCE différents : dans le cas où l'ensemble de PCE pour le calcul de chemin de secours est différent de celui utilisé pour le calcul de chemin actif, le traitement est le suivant. Si un PCE rencontre un PKS dans un XRO quand il crée une arborescence de chemin virtuelle dans son propre domaine, le PCE restitue l'identifiant de PCE du PKS et envoie un message PCReq au PCE identifié pour étendre le PKS. Le PCE qui calcule le VPT traite le segment de chemin dans la réponse comme un ensemble de sous objets XRO en effectuant son calcul de chemin. Les sous objets XRO déterminés de cette façon NE DOIVENT PAS être partagés avec les autres PCE.

 	4.	Considérations relatives à l'IANA
 	4.1	Objets PCEP
Le registre "Paramètres PCEP" contient un sous registre "Objets PCEP". L'IANA a fait les allocations suivantes dans ce registre.

Classe d'objet	Nom	Type d'objet	Référence
      17	XRO	1 : exclusion de chemin	[RFC5521]

Cet objet devrait être enregistré comme permis pour porter les sous objets suivants :

Type de sous objet	Référence
  1 : préfixe IPv4	[RFC3209]  
  2 : préfixe IPv6	[RFC3209]
  4 : ID d'interface non numérotée	[RFC3477]
32 : numéro de système autonome	[RFC3209]
34 : SRLG	[RFC4874]
64 : Path-Key avec ID PCE de 32 bits	[RFC5520]
65 : Path-Key avec ID PCE de 128 bits	[RFC5520]

 	4.2	Nouveau sous objet pour l'objet Include Route
Le registre "Paramètres PCEP" contient un sous registre "Objets PCEP" avec une entrée pour l'objet Chemins inclus (IRO).

L'IANA a ajouté un autre sous objet qui peut être porté dans le IRO comme suit :

Type de sous objet	Référence
33 : sous objet Exclusion explicite de chemin (EXRS)	[RFC4874]

 	4.3	Valeurs de champ d'objet Erreur
Le registre "Paramètres PCEP" contient un sous registre "Types et valeurs d'erreur". L'IANA a fait les allocations suivantes dans ce sous registre.

Type d'erreur	Signification	Référence
   11	sous objet EXRS non reconnu	[RFC5521]

 	4.4	Fanions Exclude Route
L'IANA a créé un sous registre des "Paramètres PCEP" pour les bits portés dans le champ Fanions de l'objet Exclude Route (XRO). Le sous registre est appelé "Champ de fanions XRO".

De nouveaux bits pourront être alloués seulement par consensus de l'IETF.

Le champ contient 16 bits numérotés du bit 0 au bit de plus fort poids.

Bit	Nom	Description	Référence
15	bit F	échec	[RFC5221]

 	5.	Considérations de gestion

Un module de MIB pour la gestion de PCEP est spécifié dans un document séparé [RFC7420]. Ce module de MIB permet l'examen des messages PCEP individuels, en particulier les demandes, les réponses, et les erreurs.

Le module de MIB DOIT être étendu pour inclure la capacité de voir les extensions d'exclusion de chemin définies dans le présent document.

Plusieurs décisions de politique locale devraient être prises au PCE. D'abord, le comportement exact à l'égard des exclusions désirées doit être disponible à l'examen d'un opérateur et peut être configurable. Ensuite, le comportement à réception d'un sous objet XRO ou EXRS non reconnu avec le bit X établi devrait être configurable et doit être disponible pour inspection. L'inspection et le contrôle de ces choix de politique locale peut faire partie du module de MIB PCEP.

 	6.	Considérations sur la sécurité

Les nouveaux mécanismes d'exclusion de chemin définis dans le présent document permettent un contrôle plus fin et plus spécifique du chemin calculé par un PCE. Un tel contrôle augmente le risque si un message PCEP est intercepté, modifié, ou usurpé parce que il permet à l'attaquant d'exercer son contrôle sur le chemin que le PCE va calculer ou de rendre le calcul de chemin impossible. Donc, les techniques de sécurité décrites dans la [RFC5440] sont considérées comme très importantes.

Noter, cependant, que les mécanismes d'exclusion de chemin fournissent aussi à l'opérateur la capacité d'acheminer en contournant les parties vulnérables du réseau et peut être utilisé pour augmenter la sécurité globale du réseau.

 	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)

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

[RFC5152]	JP. Vasseur et autres, "Méthode de calcul de chemin par domaine pour établir des chemins de commutation d'étiquettes (LSP) à ingénierie du trafic inter domaine", février 2008. (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)

[RFC5441]	JP. Vasseur, éd., R. Zhang, N. Bitar, JL. Le Roux "Procédure de calcul rétro récurrent fondée sur PCE (BRPC) pour calculer le plus court chemin obligé de commutation d'étiquette à ingénierie du trafic inter-domaine", avril 2009. (P. S.)

[RFC5520]	R. Bradford, éd., JP. Vasseur, A. Farrel, "Préservation de la confidentialité topologique dans le calcul de chemin inter-domaine en utilisant le mécanisme du chemin à clé", avril 2009. (P. S.)

 	7.2	Références pour information

[RFC3477]	K. Kompella, Y. Rekhter, "Signalisation des liaisons non numérotées dans le protocole de réservation de ressource – ingénierie du trafic (RSVP-TE)", janvier 2003. (P.S.)

[RFC3812]	C. Srinivasan, A. Viswanathan et T. Nadeau, "Base de données d'information de gestion (MIB) d'ingénierie de trafic (TE) de commutation d'étiquettes multiprotocoles (MPLS)", juin 2004.

[RFC4655]	A. Farrel, J.-P. Vasseur et J. Ash, "Architecture fondée sur l'élément de calcul de chemin (PCE)", août 2006.

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

[RFC4874]	CY. Lee et autres, "Exclusion de chemins - Extension au protocole de réservation de Ressource avec ingénierie du trafic (RSVP-TE)", avril   2007. (MàJ RFC3209, RFC3473) (P.S. ; MàJ par RFC8390)

[RFC5298]	T. Takeda et autres, "Analyse de la récupération de chemin commuté par étiquettes (LSP) inter domaine", août 2008. (Inf)

[RFC7420]	A. Koushik, et autres, "Module de MIB du protocole de communication d'élément de calcul de chemin (PCECP)", décembre 2014. (P.S.)

 	Remerciements

Les auteurs tiennent à remercier Fabien Verhaeghe de ses précieux commentaires sur les formats de sous objet. Merci à Magnus Westerlund, Dan Romascanu, Tim Polk, et Dave Ward de leurs commentaires durant la revue de l'IESG.

 	Adresse des auteurs

Eiji Oki
University of Electro-Communications
1-5-1 Chofugaoka
Chofu, Tokyo  182-8585
JAPAN
mél : oki@ice.uec.ac.jp

Tomonori Takeda
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585
Japan
mél : takeda.tomonori@lab.ntt.co.jp

Adrian Farrel
Old Dog Consulting
mél : adrian@olddog.co.uk