Équipe d’ingénierie de l’Internet (IETF)	JP. Vasseur, éd. Cisco Systems, Inc		
Request for Comments : 5441	R. Zhang, BT Infonet		
Catégorie : Sur la voie de la normalisation	N. Bitar, Verizon		
ISSN: 2070-1721	JL. Le Roux, France Télécom		
Traduction Claude Brière de L’Isle	avril 2009		

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

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.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à :  https://www.rfc-editor.org/info/rfc5441.

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. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

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é
La capacité de calculer le plus court chemin de commutation d'étiquettes d'ingénierie du trafic contraint (LSP TE, Traffic Engineering Label Switched Path) dans les réseaux de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) et MPLS généralisé (GMPLS) à travers plusieurs domaines a été identifiée comme une exigence clé. Dans ce contexte, un domaine est une collection d'éléments de réseau au sein d'une sphère commune de gestion d'adresse ou de responsabilité de calcul de chemin telle qu'une zone IGP ou un système autonome. Le présent document spécifie une procédure s'appuyant sur l'utilisation de plusieurs éléments de calcul de chemin (PCE, Path Computation Element) pour calculer ces chemins les plus courts contraints inter domaines à travers une séquence prédéterminée de domaines, en utilisant une technique de calcul de chemin rétro récursive. Cette technique préserve la confidentialité à travers les domaines, ce qui est parfois nécessaire lorsque les domaines sont gérés par des fournisseurs de service différents.
Table des matières
1. Introduction	2
1.1 Langage des exigences	3
2. Terminologie	3
3. Hypothèses générales	3
4. Procédure de BRPC	4
4.1 Choix du chemin de domaine	4
4.2 Mode de fonctionnement	4
5. Extensions du protocole PCEP	6
6. Codage  de la VSPT	6
7. Liaisons TE inter-AS	6
8. Utilisation en conjonction avec le calcul de chemin par domaine	7
9. Échec de l'achèvement de la procédure de BRPC	7
10. Applicabilité	7
10.1 Calcul de chemins divers de bout en bout	7
10.2 Optimalité du chemin	8
11. Réoptimisation d'un LSP TE inter-domaines	8
12. Échec du calcul du chemin	8
13. Normalisation métrique	8
14. Considérations relatives à la facilité de gestion	8
14.1 Contrôle de fonction et de politique	9
14.2 Modèles d'information et de données	9
14.3 Détection et surveillance de vie	9
14.4 Vérification du bon fonctionnement	9
14.5 Exigences relatives aux autres protocoles et composants fonctionnels	9
14.6 Impact sur le fonctionnement du réseau	9
14.7. Surveillance de la chaîne de calcul de chemin	9
15. Considérations relatives à l'IANA	9
15.1 Nouveau fanion de l'objet RP	9
15.2 Nouveau type d'erreur et nouvelle valeur d'erreur	10
15.3 Nouveau fanion du TLV NO-PATH-VECTOR	10
16. Considérations relatives à la sécurité	10
17. Remerciements	10
18. Références	10
18.1 Références normatives	10
18.2 Références informatives	11
Adresse des auteurs	11
1.	Introduction

Les exigences relatives à l'ingénierie du trafic (TE, Traffic Engineering) MPLS inter-zones et inter-AS ont été développées par le groupe de travail Ingénierie du trafic (TE WG) et ont été énoncées respectivement dans les [RFC4105] et [RFC4216].

Le cadre de l'ingénierie du trafic de la commutation par étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) inter-domaines (TE) a été fournie dans la [RFC4726].

La [RFC5152] définit une technique permettant d'établir une ingénierie du trafic de chemin de commutation d'étiquettes (LSP) MPLS généralisé (GMPLS) inter domaines par laquelle le chemin est calculé pendant le processus de signalisation domaine par domaine par le nœud frontière d'entrée de chaque domaine (chaque nœud responsable du déclenchement du calcul d'une section d'un chemin de LSP TE inter domaines est toujours sur le chemin d'un tel LSP TE). Cette technique de calcul de chemin répond à certaines des exigences énoncées dans les [RFC4105] et [RFC4216] mais pas à toutes. En particulier, elle ne peut pas garantir de trouver un chemin inter domaines contraint optimal (le plus court). De plus, elle ne peut pas être utilisée efficacement pour calculer un ensemble de LSP TE inter domaines à acheminement diversifié.

L'architecture d'élément de calcul de chemin (PCE, Path Computation Element) est définie dans la [RFC4655]. L'objectif de ce document est de décrire la procédure de calcul de chemin fondée sur le PCE pour calculer les LSP TE (G)MPLS contraints inter domaines optimaux.

Qualifier un chemin d'optimal nécessite quelques précisions. En effet, un placement globalement optimal de LSP TE fait généralement référence à un ensemble de LSP TE dont le placement optimise les ressources du réseau par rapport à une fonction objective spécifiée (par exemple, un placement qui réduise la charge réseau maximale ou moyenne tout en satisfaisant les contraintes du LSP TE). Dans ce document, un LSP TE contraint inter domaines optimal est défini comme le chemin le plus court satisfaisant l'ensemble des contraintes exigées qui serait obtenu en l'absence de domaines multiples (en d'autres termes, dans un réseau IGP totalement plat entre la source et la destination du LSP TE). Noter que cela nécessite l'utilisation de schémas de métrique cohérents dans chaque domaine (voir la Section 13).

1.1	Langage des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2.	Terminologie

ABR (Area Border Router) : routeur de frontière de zone. Routeurs utilisés pour connecter deux zones IGP (zones dans OSPF ou niveaux dans IS-IS).

ASBR (Autonomous System Border Router) : routeur de bordure de système autonome. Routeur utilisé pour connecter des AS du même ou de différents fournisseurs de services via une ou plusieurs liaisons inter-AS.

BN (Boundary Node) : nœud de frontière. C'est soit un ABR dans le contexte d'ingénierie du trafic inter-zones soit un ASBR dans le contexte d'ingénierie du trafic inter-AS.

BN d'entrée du domaine (n) : un BN reliant le domaine (n-1) au domaine (n) le long une séquence déterminée de domaines.

BN de sortie du domaine (n) : un BN reliant le domaine (n) au domaine (n+1) le long une séquence déterminée de domaines.

LSP TE inter-zone  : un TE LSP qui traverse une limite de zone IGP.

LSP TE inter-AS : un TE LSP qui traverse une limite AS.

LSP (Label Switched Path) chemin commuté par étiquette.

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

PCC (Path Computation Client) client de calcul de chemin. Toute application cliente demandant un calcul de chemin à effectuer par un élément de calcul de chemin.

PCE (Path Computation Element) élément de calcul de chemin. Une entité (composant, application ou nœud de réseau) capable de calculer un chemin ou une route du réseau sur la base d'un graphe de réseau et en appliquant des contraintes de calcul.

PCE(i) est un PCE avec la portée du domaine(i).

TED (Traffic Engineering Database) : base de données d'ingénierie du trafic.

VSPT (Virtual Shortest Path Tree) : arborescence virtuelle de chemin le plus court.

La notion de LSP TE contigus, attachés et incorporés est définie dans la [RFC4726] et ne sera pas répétée ici.

3.	Hypothèses générales

Dans le reste de ce document, on fait l'ensemble suivant d'hypothèses communes aux MPLS TE inter-zones et inter-AS :

o	Chaque zone IGP ou système autonome (AS) est supposé être capable d'ingénierie du trafic.

o	Aucune information de topologie ou de ressource n'est distribuée entre les domaines (comme exigé par les [RFC4105] et [RFC4216]) ce qui est essentiel pour préserver l'adaptabilité et la confidentialité de IGP/BGP.

o	Bien que certaines contraintes telles que la bande passante puissent être utilisées à travers différents domaines, d'autres contraintes de TE (telles que l'affinité, la couleur, la métrique, etc. des ressources [RFC2702]) pourraient être traduites aux limites du domaine. Si nécessaire, on suppose que, aux nœuds de frontière du domaine , il va exister une sorte de transposition locale fondée sur un accord de politique, afin de traduire ces contraintes à travers limites de domaine pendant le processus de communication inter-PCE.

o	Chaque AS peut être constitué de plusieurs zones IGP. La procédure de calcul de chemin décrite dans ce document s'applique au cas d'un seul AS composé de plusieurs zones IGP, de plusieurs AS composés d'une zone IGP unique, ou de toute combinaison des éléments ci-dessus. Pour simplifier, chaque AS sera considéré comme étant constitué d'une seule zone dans ce document. Le cas d'un LSP TE inter-AS couvrant plusieurs AS, dont certains sont eux-mêmes constitués de plusieurs zones IGP, peut être facilement déduit de ce cas en appliquant récursivement la procédure de BRPC décrite dans ce document.

o	Le chemin de domaines (l'ensemble des domaines traversés pour atteindre le domaine de destination) est soit prédéterminé administrativement, soit découvert par des moyens qui sortent du cadre de ce document.

4.	Procédure de BRPC

La procédure de BRPC est une technique de calcul de chemin multi PCE comme décrit dans la [RFC4655]. Un modèle possible consiste à héberger la fonction de PCE sur les nœuds de frontière (par exemple, ABR ou ASBR) mais ce n'est pas rendu obligatoire par la procédure de BRPC.

La procédure de BRPC repose sur la communication entre les PCE coopérants. En particulier, le PCC envoie une PCReq à un PCE dans son domaine. La demande est transmise entre les PCE, domaine par domaine, jusqu'à ce que le PCE responsable du domaine contenant la destination LSP soit atteint. Le PCE dans le domaine de destination crée une arborescence de chemins potentiels vers la destination (l'arborescence virtuelle de plus court chemin (VSPT, Virtual Shortest Path Tree) et passe cela en retour au PCE précédent dans une PCRep. Chaque PCE à son tour ajoute à la VSPT et la renvoie jusqu'à ce que le PCE dans le domaine de source utilise la VSPT pour sélectionner un chemin de bout en bout que le PCE envoie au PCC.

La procédure de BRPC ne fait aucune hypothèse concernant la nature du LSP TE inter-domaines qui pourrait être contigu, incorporé, ou rattaché.

De plus, aucune hypothèse n'est faite sur l'algorithme de calcul du chemin réel utilisé par un PCE (par exemple, il peut s'agir de n'importe quelle variante de plus court chemin obligé en premier (CSPF, Constrained Shortest Path First) ou un algorithme fondé sur la programmation linéaire pour résoudre des problèmes d'optimisation multi-contraintes).

4.1	Choix du chemin de domaine
La procédure de BRPC fondée sur PCE s'applique au calcul d'un LSP TE inter-domaines contraint optimal. La séquence de domaines à traverser est soit prédéterminé administrativement, soit découverte par certains moyens qui sortent du domaine d'application de ce document. Le PCC PEUT indiquer la séquence de domaines à traverser en utilisant l'objet Chemin à inclure (IRO, Include Route Object) défini dans la [RFC5440] afin qu'il soit disponible pour tous les PCE. Noter aussi qu'une séquence de PCE PEUT être imposée par la politique du PCC, et cette contrainte peut être portée dans la demande de calcul de chemin PCEP (comme défini dans la [RFC5886]).

La procédure de BRPC garantit de calculer le chemin optimal à travers une séquence spécifique de domaines traversés (ce qui constitue une contrainte supplémentaire). Dans le cas d'un ensemble arbitraire de domaines maillés, la procédure de BRPC peut être utilisée pour calculer le chemin optimal sur chaque ensemble de domaines afin d'obtenir le chemin contraint optimal entre la source et la destination du LSP TE. La procédure de BRPC peut également être utilisée sur un sous-ensemble de toutes les séquences de domaines, et le meilleur chemin parmi ces séquences peut alors être choisi.

4.2	Mode de fonctionnement
Définition de VSPT(i)

Dans chaque domaine i :

o	Il existe un ensemble de BN d'entrée X-en(i) noté BN-en(k,i) où BN-en(k,i) est le k-ième BN d'entrée du domaine(i).

o	Il existe un ensemble X-ex(i) de BN de sortie noté BN-ex(k,i) où BN-ex(k,i) est le k-ième BN de sortie du domaine(i).

VSPT(i)  : arborescence MP2P (multipoint à point) renvoyée par le PCE(i) au PCE(i-1) :

	Racine (LSP TE de destination)
	/ | \
	BN-en(1,i) BN-en(2,i) ... BN-en(j,i).

où [X-en(i)] est le nombre de BN d'entrée dans le domaine i et j ≤ [X-en(i)]

Figure 1 : Arborescence MP2P

Chaque lien de l'arborescence VSPT(i) représente le chemin contraint le plus court entre BN-en(j,i) et le LSP TE de destination qui satisfait l'ensemble des contraintes requises pour le LSP TE (bande passante, affinités, etc.). Ce sont des segments de chemin pour atteindre le LSP TE de destination à partir de BN-fr(j,i).

Noter que PCE(i) ne prend en compte que les BN d'entrée du domaine(i), c'est-à-dire, uniquement les BN qui fournissent la connexité à partir du domaine (i-1). En d'autres termes, l'ensemble BN-en(k,i) est uniquement composé des BN qui fournissent la connexité du domaine (i-1) au domaine (i). De plus, certains BN peuvent être exclus en fonction de contraintes de politiques (soit en raison de la politique locale soit de politiques signalées dans la demande de calcul de chemin).

Étape 1 :
D’abord, le PCC doit déterminer le PCE capable de servir sa demande de calcul de chemin (cela peut être fait avec la configuration locale ou via la découverte IGP (voir les [RFC5088] et [RFC5089])). La demande de calcul du chemin est ensuite relayée jusqu'à atteindre un PCE(n) tel que le LSP TE de destination réside dans le domaine(n). À chaque étape du processus, le prochain PCE peut être configuré de manière statique ou découvert de façon dynamique via les extensions IGP/BGP. Si aucun PCE suivant ne peut être trouvé ou si le PCE de bond suivant choisi n'est pas disponible, la procédure s'arrête et une erreur de calcul de chemin est retournée (voir la Section 9). Si le PCE(i-1) découvre plusieurs PCE pour le domaine adjacent (i), le PCE (i) peut sélectionner un sous-ensemble de ces PCE sur la base de certaines politiques ou heuristiques locales. Le processus de choix du PCE n’entre pas dans le cadre du présent document.

Étape 2 :
Le PCE(n) calcule la VSPT(n), l'arborescence constitué de la liste des plus courts chemins contraints entre chaque BN-en(j,n) et le LSP TE de destination en utilisant un algorithme de calcul de chemin approprié (par exemple, CSPF) et retourne la VSPT(n) calculée à PCE(n-1).

Étape i :
Pour i=n-1 à 2 : le PCE(i) calcule VSPT(i), l'arborescence constituée des chemins contraints les plus courts entre chaque BN-en(j,i) et le LSP TE de destination. Il le fait en prenant en compte sa propre TED et les informations de la VSPT(i+1).

Dans le cas d'un calcul de LSP TE inter-AS, cela exige aussi l'ajout les liaisons TE inter-AS qui relient le domaine (i) au domaine (i+1).

Étape n :
Enfin, le PCE(1) calcule le chemin contraint le plus court de bout en bout de la source à la destination et retourne le chemin correspondant au PCC demandeur sous la forme d'un message PCRep tel que défini dans la [RFC5440].

Chaque branche de l'arborescence VSPT (chemin) peut être retournée sous la forme d'un chemin explicite (dans ce cas, tous les bonds le long du segment de chemin sont répertoriés) ou un chemin lâche (dans ce cas, seul le BN est spécifié) afin de préserver la confidentialité ainsi que le coût correspondant. Dans ce dernier cas, diverses techniques peuvent être utilisées afin de récupérer les chemins explicites calculés sur la base du domaine pendant le processus de signalisation, grâce à l'utilisation de clés de chemin comme décrit dans la [RFC5520].

Un PCE qui peut calculer le chemin demandé pour plus d'un domaine consécutif sur le chemin DEVRAIT effectuer ce calcul pour tous ces domaines avant de transmettre le PCRep au PCE précédent dans la séquence.

BRPC garantit de trouver le LSP TE inter-domaines contraint optimal (le plus court) selon un ensemble de domaines définis à traverser. Noter que d’autres variantes de la procédure de BRPC s’appuyant sur les mêmes principes sont également possibles.

Noter aussi que dans le cas de chemins multi-chemins à coût égal (ECMP, Equal Cost Multi-Path) plus d'un chemin pourrait être retourné au PCC demandeur.

5.	Extensions du protocole PCEP

La procédure de BRPC nécessite la spécification d'un nouveau fanion de l'objet RP transporté dans le message PCReq (défini dans la [RFC5440]) pour spécifier que les chemins les plus courts satisfaisant les contraintes de la destination à l'ensemble des nœuds d'entrée frontière sont demandés (un tel ensemble des chemins forme la VSPT aval, comme spécifié au paragraphe 4.2).

Le nouveau fanion suivant de l'objet RP est défini  :

Fanion VSPT :
Numéro de bit	Nom du fanion
       25	VSPT

Lorsqu'il est établi, le fanion VSPT indique que le PCC demande le calcul d'un LSP TE inter-domaine en utilisant la procédure de BRPC définie dans le présent document.

Parce que les segments de chemin calculés par un PCE en aval dans le contexte de la procédure de BRPC DOIVENT être fournis avec leurs coûts de chemin respectifs, le fanion C de l'objet METRIC porté dans le message PCReq DOIT être établi. C'est le choix du demandeur de régler de manière appropriée le bit O de l'objet RP.

6.	Codage  de la VSPT

La VSPT est retournée dans un message PCRep. Le codage consiste en une liste non ordonnée d'objets de chemin explicite (ERO, Explicit Route Object) où chaque ERO représente un segment de chemin d'un BN à la destination spécifiée dans l'objet END-POINT du message PCReq correspondant.

Exemple :
   <---- zone 1 ----><---- zone 0 ----------><------ zone 2 ------>
                                       ABR1-AB-+
                                        | |
                                       ABR2-----D
                                        | |
                                       ABR3--C--+

Figure 2  : Exemple de codage de VSPT utilisant un ensemble d'ERO

Dans l’exemple simple illustré à la figure 2, si on fait l’hypothèse qu'un chemin contraint existe entre chaque ABR et la destination D, la VSPT calculée par un PCE desservant la zone 2 se compose de l'ensemble non ordonné d'ERO suivants :

o	ERO1 : ABR1 (ID du routeur TE)-A (adresse de l'interface IP)-B (adresse IP de l'interface)-D(ID du routeur TE)

o	ERO2  : ABR2 (ID de routeur TE)-D (ID de routeur TE)

o	ERO3  : ABR3  (ID du routeur TE)-C  (adresse IP de l'interface)-D  (ID du routeur TE)

Le message PCReq, le message PCRep, l'objet PCEP END-POINT et l'objet ERO sont définis dans la [RFC5440].

7.	Liaisons TE inter-AS

Dans le cas du calcul du chemin de LSP TE inter-AS, la procédure de BRPC exige la connaissance des attributs d'ingénierie du trafic des liaisons TE inter-AS. Le processus par lequel le PCE acquiert ces informations sort du champ d'application de la procédure de BRPC, qui est conforme à l'architecture PCE définie dans la [RFC4655].

Cela dit, une solution simple consiste à autoriser les ASBR à arroser les informations de TE relatives aux liaisons inter-ASBR bien que aucun IGP TE ne soit activé sur ces liaisons (il n'y a pas d'adjacence IGP sur les liaisons inter-ASBR). Cela permet au PCE d'un domaine d'obtenir la visibilité TE intégrale jusqu'à l'ensemble des ASBR d'entrée dans le domaine aval (voir les extensions IGP définies dans les [RFC5316] et [RFC5392]).

8.	Utilisation en conjonction avec le calcul de chemin par domaine

La procédure de BRPC peut être utilisée pour calculer des segments de chemin conjointement avec d'autres techniques de calcul de chemin (telles que la technique de calcul de chemin par domaine définie dans la [RFC5152]) pour calculer le chemin de bout en bout. Dans ce cas, l'optimalité du chemin de bout en bout ne peut plus être garantie.

9.	Échec de l'achèvement de la procédure de BRPC

Si la procédure BRPC ne peut pas être achevée parce qu'un PCE le long du domaine ne reconnaît pas la procédure (fanion VSPT de l'objet RP) comme indiqué dans la [RFC5440], le PCE envoie un message PCErr au PCE amont avec un type d'erreur = 4 (objet non pris en charge) valeur d'erreur = 4 (paramètre non pris en charge). Le PCE peut inclure l'objet parent (objet RP) jusqu'au et y compris (mais pas plus loin que) le paramètre inconnu ou non pris en charge. Dans ce cas, lorsque le paramètre inconnu ou non pris en charge est un fanion de bit (fanion VSPT) l'objet RP inclus devrait contenir l'intégralité du champ de bits fanions avec tous les bits après le paramètre posant problème réglés à zéro. La demande de calcul de chemin correspondante est alors annulée par le PCE sans autre notification.

Si la procédure de BRPC ne peut pas être achevée en raison d'un PCE le long du chemin du domaine qui reconnaît mais ne prend pas en charge la procédure, il DOIT renvoyer un message PCErr au PCE en amont avec un type d'erreur "échec d'achèvement de procédure de BRPC".

Le message PCErr DOIT être relayé au PCC demandeur.

Les objets PCEP-ERROR sont utilisés pour rapporter une erreur de protocole PCEP et sont caractérisés par un type d'erreur qui spécifie le type de l'erreur et une valeur d'erreur qui fournit des informations supplémentaires sur le type d'erreur. Le type d'erreur et la valeur d'erreur sont tous deux gérés par l'IANA.

Un nouveau type d’erreur est défini en rapport avec la procédure de BRPC.

Type d'erreur	Signification
      13 	Échec de la fin de la procédure BRPC
	Valeur d'erreur
	1  : La procédure BRPC n'est pas prise en charge par un ou plusieurs PCE sur le chemin du domaine

10.	Applicabilité

Comme indiqué dans la Section 3, les exigences d'ingénierie du trafic MPLS inter zones et inter AS ont été développées par le groupe de travail d'ingénierie du trafic (WG TE) et ont été énoncées respectivement dans les [RFC4105] et [RFC4216]. Parmi l'ensemble des exigences, les deux documents indiquent la nécessité d'une solution qui fournisse la capacité de calculer un LSP TE inter-domaines optimal (le plus court) contraint et de calculer un ensemble de LSP TE inter-domaines divers.

10.1	Calcul de chemins divers de bout en bout
PCEP (voir la [RFC5440]) permet à un PCC de demander le calcul d'un ensemble de LSP TE divers en réglant les fanions L, N ou S de l'objet SVEC à demander la diversité de respectivement liaison, nœud ou groupe de liaisons à risque partagé (SRLG, Shared Risk Link Group). De telles demandes DOIVENT être prises en compte par chaque PCE le long de la chaîne de calcul du chemin pendant le calcul de la VSPT. Dans le cadre de la procédure de BRPC, un ensemble de LSP TE acheminés de manière diversifiée entre deux LSR peut être calculé puisque les segments de chemin de la VSPT sont calculés simultanément par un PCE donné. La procédure de BRPC permet le calcul de divers chemins sous différents fonctions objectives (telles que la minimisation de la somme des coûts des N divers chemins, etc.).

En revanche, avec une approche en 2 étapes consistant à calculer le premier chemin suivi en calculant le deuxième chemin après avoir supprimé l'ensemble d'éléments de réseau traversés par le premier chemin (si cela ne viole pas la préservation de la confidentialité) on ne peut pas garantir qu'une solution sera trouvée même si une telle solution existe. De plus, même si une solution est trouvée, elle ne sera peut-être pas la plus optimale par rapport à une fonction objective telle que la minimisation de la somme des coûts de chemins, la limitation des délais des deux chemins, et ainsi de suite. Enfin, il faut noter qu'une telle approche de calcul de chemin en 2 étapes est généralement moins efficace en termes de retards de signalisation car elle nécessite l'établissement de deux LSP TE en série.

10.2	Optimalité du chemin
BRPC garantit que le chemin inter domaines contraint optimal (le plus court) sera toujours trouvé, sous réserve des contraintes de politique. Dans le cas où des techniques de calcul de chemin locales sont utilisées (comme de construire des LSP TE attachés ou incorporés) et dans le cas où un domaine a plus d'un BN-en ou plus d'un BN-ex, il est seulement possible de garantir l'optimalité après un changement de réseau au sein du domaine en ré-exécutant complètement la procédure de BRPC.

11.	Réoptimisation d'un LSP TE inter-domaines

La capacité de réoptimiser un chemin de LSP TE inter-domaines existant a été explicitement répertoriée comme une exigence dans les [RFC4105] et [RFC4216]. Dans le cas d'une demande de réoptimisation de LSP TE, la procédure de réoptimisation définie dans la [RFC5440] s'applique lorsque le chemin utilisé (si il est disponible sur l'extrémité de tête) est fourni au titre de la demande de calcul de chemin afin que les PCE impliqués dans la demande de réoptimisation puissent éviter la double prise en compte de la bande passante.

12.	Échec du calcul du chemin

Si un PCE exige de relayer une demande de calcul de chemin conformément à la procédure de BRPC définie dans ce document à un PCE en aval et si aucun PCE de ce type n'est disponible, le PCE DOIT envoyer une réponse de calcul de chemin négative au demandeur en utilisant un message PCReq comme spécifié dans la [RFC5440] qui contient un objet NO-PATH. Dans ce cas, l'objet NO-PATH DOIT contenir un TLV NO-PATH-VECTOR (défini dans la [RFC5440]) avec le bit nouvellement défini nommé "chaîne de calcul de chemin BRPC indisponible" établi.

Numéro de bit	Nom de fanion
     28	Chaîne de calcul de chemin BRPC indisponible.

13.	Normalisation métrique

Dans le cas de TE inter-zones, le même schéma métrique IGP/TE est généralement adopté pour toutes les zones IGP (par exemple, en fonction de la vitesse de liaison, du délai de propagation, ou d'une autre combinaison d’attributs de liaison). Donc, l'ensemble de mécanismes proposé calcule toujours le plus court chemin à travers plusieurs zones qui obéissent à l'ensemble de contraintes requises par rapport à une fonction objective spécifiée. À l'inverse, dans le cas de TE inter-AS, pour que ce calcul de chemin soit significatif, une normalisation métrique entre les AS peut être nécessaire. Une solution pour éviter la modification de la métrique IGP serait que les fournisseurs de service conviennent d'un schéma de normalisation des métriques TE et utilisent la métrique de TE pour le calcul du chemin du LSP TE (dans ce cas, l'utilisation de la métrique de TE doit être demandée dans la demande de calcul de chemin PCEP) en utilisant l'objet METRIC (défini dans la [RFC5440]).

14.	Considérations relatives à la facilité de gestion

Cette section suit les directives de la [RFC6123].

14.1	Contrôle de fonction et de politique
Le seul élément configurable est la prise en charge de la procédure de BRPC sur un PCE. La prise en charge de la procédure de BRPC par le PCE PEUT être contrôlée par un module de politique régissant les conditions dans lesquelles un PCE devrait participer à la procédure de BRPC (origine des demandes, nombre de demandes par seconde, etc.). Si le protocole BRPC n'est pas pris en charge/autorisé sur un PCE, il DOIT envoyer un message PCErr comme spécifié à la Section 9.

14.2	Modèles d'information et de données
Un module de MIB BRPC sera spécifié dans un document séparé.

14.3	Détection et surveillance de vie
La procédure de BRPC est une technique de calcul de chemin multi PCE et, à ce titre, un ensemble de PCE est impliqué dans la chaîne de calcul de chemin. Si la chaîne de calcul du chemin n'est pas opérationnelle soit parce que au moins un PCE ne prend pas en charge la procédure de BRPC ou parce que l'un des PCE qui doivent être impliqués dans la chaîne de calcul du chemin n'est pas disponible, des procédures sont définies pour rapporter de telles défaillances dans les Sections 9 et 12, respectivement. De plus, un outil de diagnostic intégré pour vérifier la disponibilité et les performances d'une chaîne de PCE est définie dans la [RFC5886].

14.4	Vérification du bon fonctionnement
La vérification du bon fonctionnement de BRPC peut être effectuée en surveillant un ensemble de paramètres. Une mise en œuvre de BRPC DEVRAIT fournir les paramètres suivants  :

o	Nombre de procédures BRPC achevées avec succès par homologue PCE.

o	Nombre d'échecs d'achèvement de procédure BRPC parce que le fanion VSPT n'a pas été reconnu (par homologue PCE)

o	Nombre d'échecs d'achèvement de procédure BRPC parce que la procédure de BRPC n'a pas été prise en charge (par homologue PCE)

14.5	Exigences relatives aux autres protocoles et composants fonctionnels
La procédure BRPC n’impose aucune nouvelle exigence aux autres protocoles. Cela dit, étant donné que la procédure BRPC repose sur le protocole PCEP, il existe une dépendance entre BRPC et PCEP ; par conséquent, la procédure BRPC utilise intrinsèquement les fonctions de gestion développées pour PCEP.

14.6	Impact sur le fonctionnement du réseau
La procédure BRPC n'a pas d'impact significatif sur le fonctionnement du réseau : en effet, BRPC est un schéma de calcul de chemin multi-PCE comme défini dans la [RFC4655] et ne diffère d'aucune autre demande de calcul de chemin.

14.7. Surveillance de la chaîne de calcul de chemin
La [RFC5886] spécifie un ensemble de mécanismes qui peuvent être utilisés pour collecter les métriques d'état de PCE. Étant donné que BRPC est une technique de calcul de chemin multi-PCE, de tels mécanismes pourraient être avantageusement utilisés dans le cadre de la procédure BRPC pour vérifier le maintien en vie de la chaîne de calcul de chemin, localiser un composant défectueux, surveiller les performances globales, etc.

15.	Considérations relatives à l'IANA
15.1	Nouveau fanion de l'objet RP
Un nouveau fanion de l'objet RP (spécifié dans la [RFC5440]) est défini dans ce document. L'IANA tient un registre des fanions d'objet RP dans le sous-registre "Champ Fanions de l'objet RP" du registre des "numéros du protocole d'élément de calcul de chemin (PCEP)".

L'IANA a attribué la valeur suivante  :

Bit	Description	Référence
25	VSPT	RFC 5441

15.2	Nouveau type d'erreur et nouvelle valeur d'erreur
L'IANA tient un registre des types d'erreurs et des valeurs d'erreurs à utiliser dans les messages PCEP. Ceci est conservé comme sous-registre "Types et valeurs d'erreur d'objet PCEP-ERROR" du registre des "numéros du protocole d'élément de calcul de chemin (PCEP)".

Une nouvelle valeur d'erreur est définie pour le type d'erreur "objet non pris en charge" (type 4).

Type d'erreur	Signification et valeurs d'erreur	Référence
       4	Objet non pris en charge
	Valeur d'erreur = 4 : paramètre non pris en charge	RFC 5441

Un nouveau type d'erreur est défini dans ce document comme suit  :

Type d'erreur	Signification	Référence
     13	Échec de la fin de la procédure BRPC	RFC 5441
	Valeur d'erreur  =  1  : la procédure BRPC n'est pas prise en charge par un ou plusieurs PCE sur le chemin du domaine

15.3	Nouveau fanion du TLV NO-PATH-VECTOR
Un nouveau fanion du TLV NO-PATH-VECTOR défini dans la [RFC5440]) est spécifié dans ce document.

L'IANA tient un registre de fanions pour le TLV NO-PATH-VECTOR dans le sous-registre "Champ Fanions du TLV NO-PATH-VECTOR" du registre des "numéros du protocole d'élément de calcul de chemin (PCEP)".

L'IANA a attribué la valeur d'allocation suivante  :

Numéro de bit	Signification	Référence
         4	Chaîne de calcul du chemin BRPC indisponible	RFC5441

16.	Considérations relatives à la sécurité

La procédure de BRPC repose sur l'utilisation du protocole PCEP et à ce titre est soumise aux attaques potentielles énumérées à la Section 10 de la [RFC5440]. En plus des mécanismes de sécurité décrits dans la [RFC5440] concernant l'usurpation d'identité, l'espionnage, la falsification et le déni de service, une mise en œuvre PEUT prendre en charge un module de politique régissant les conditions dans lesquelles un PCE devrait participer aux procédures de BRPC.

La procédure de BRPC n'augmente pas les informations échangées entre les AS et préserve la confidentialité de la topologie, conformément aux [RFC4105] et [RFC4216].

17.	Remerciements

Les auteurs tiennent à remercier Arthi Ayyangar, Dimitri Papadimitriou, Siva Sivabalan, Meral Shirazipour et Mach Chen pour leurs commentaires utiles. Un merci spécial à Adrian Farrel pour ses commentaires et suggestions utiles.

18.	Références
18.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

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

18.2	Références informatives

[RFC2702]	D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999. (Information)

[RFC4105]	J.-L. Le Roux, J.-P. Vasseur et J. Boyle, "Exigences pour l'ingénierie de trafic MPLS interzones", juin 2005.

[RFC4216]	R. Zhang et J.-P. Vasseur, "Exigences pour l'ingénierie de trafic MPLS entre systèmes autonomes (AS)", novembre  2005. (Information)

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

[RFC4726]	A. Farrel et autres, "Cadre pour l'ingénierie de trafic inter domaine de commutation d'étiquettes multi protocoles", novembre 2006. (Information)

[RFC5088]	JL. Le Roux et autres, "Extensions au protocole OSPF pour la découverte d'élément de calcul de chemin (PCE)", janvier  2008. (P.S. ; MàJ par 9353)

[RFC5089]	JL. Le Roux et autres, "Extensions au protocole IS-IS pour la découverte d'élément de calcul de chemin (PCE)", janvier  2008. (P.S. ; MàJ par 9353)

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

[RFC5316]	M. Chen, R. Zhang, X. Duan, "Extensions à ISIS à l'appui de l'ingénierie du trafic pour MPLS et GMPLS en inter systèmes autonomes", décembre 2008. (P.S. ; remplacée par 9346)

[RFC5392]	M. Chen, R. Zhang, X. Duan, "Extensions à OSPF pour la prise en charge de l'ingénierie de trafic MPLS et GMPLS entre systèmes autonomes (AS)", janvier 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.)

[RFC5886]	JP. Vasseur, JL. Le Roux, Y. Ikejiri, "Ensemble d'outils de surveillance pour architecture fondée sur l'élément de calcul de chemin (PCE)", juin 2010. (P. S.)

[RFC6123]	A. Farrel, "Inclusion de sections sur la gestion dans les projets du groupe de travail ﾉl駑ents de calcul de chemin (PCE)", f騅rier 2011. (Historique)

Adresse des auteurs

JP Vasseur (éditeur)	Raymond Zhang	Nabil Bitar	JL Le Roux	
Cisco Systems, Inc	BT Infonet	Verizon	France Télécom	
1414 Massachusetts Avenue	2160 E. Grand Ave.	117, rue West	2, Avenue Pierre Marzin	
Boxborough, MA 01719	El Segundo, Californie 90025	Waltham, MA 02451	Lannion, 22307	
USA	USA	USA	FRANCE	
mél : jpv@cisco.com	mél : raymond.zhang@bt.com	 nabil.n.bitar@verizon.com	 jeanlouis.leroux@orange-ftgroup.com