Groupe de travail Réseau	Y. Lee, Huawei	
Request for Comments : 5557	JL. Le Roux, France Telecom	
Catégorie : Sur la voie de la normalisation	D. King, Old Dog Consulting	
	E. Oki, University of Electro Communications	
Traduction Claude Brière de L'Isle	juillet 2009	

Exigences du protocole de communication d'élément de calcul de chemin (PCEP) et extensions du protocole pour la prise en charge de l'optimisation concurrente globale

Résumé
Le protocole de communication d'élément de calcul de chemin (PCEP, Path Computation Element Communication Protocol) permet aux clients de calcul de chemin (PCC, Path Computation Clients) de demander des calculs de chemin aux éléments de calcul de chemin (PCE, Path Computation Element) et de laisser les PCE retourner les réponses. Quand on calcule ou réoptimise les chemins d'un ensemble de chemins de commutation d'étiquettes à ingénierie de trafic (TE LSP, Traffic Engineering Label Switched Path) à travers un réseau, il peut être avantageux d'effectuer des calculs de chemin en vrac afin d'éviter des problèmes de blocage et pour réaliser des solutions plus optimales au niveau du réseau. Une telle optimisation en vrac est appelée optimisation concurrente globale (CGO, Global Concurrent Optimization). Une GCO est capable de considérer simultanément la topologie entière du réseau et l'ensemble complet des LSP TE existants, et leurs contraintes respectives, et de chercher à optimiser ou réoptimiser le réseau entier pour satisfaire toutes les contraintes pour tous les LSP TE. Une GCO peut aussi être appliquée à un sous ensemble des TE LSP TE dans un réseau. L'application de GCO est principalement une solution de système de gestion de réseau (NMS, Network Management System).

Le présent document donne les exigences spécifiques d'application et les extensions à PCEP à l'appui des applications de GCO.

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.
Table des matières
1. Introduction	2
2. Terminologie	3
3. Applicabilité de l'optimisation concurrente globale (GCO)	4
3.1 Application de l'architecture de PCE	4
3.2 Optimisation de terrain vierge	4
3.3 Réoptimisation de réseaux existants	5
4. Exigences de PCECP	6
5. Extensions du protocole pour la prise en charge de l'optimisation concurrente globale	7
5.1 Spécification de la fonction objective globale (GOF)	8
5.2 Indication des demandes d'optimisation concurrente globale	8
5.3 Demande pour l'ordre de LSP TE	8
5.4 Réponse Ordre	8
5.5 Objet GLOBAL CONSTRAINTS (GC)	9
5.6 Indicateur d'erreur	10
5.7 Indicateur NO-PATH 	10
6. Considérations de gestion	11
6.1 Contrôle de fonction et de politique	11
6.2 Modèles d'information et de données (e.g., module de MIB)	11
6.3 Détection et surveillance de vie	11
6.4 Vérification du fonctionnement correct	11
6.5 Exigences sur d'autres protocoles et composants fonctionnels	11
6.6 Impact sur le fonctionnement du réseau	11
7. Considérations sur la sécurité	11
8. Considérations relatives à l'IANA	12
8.1 Fanions de bit de paramètre de demande	12
8.2 Nouveau TLV PCEP	12
8.3 Nouveau fanion dans le sous TLV PCE-CAP-FLAGS dans PCED	12
8.4 Nouvel objet PCEP	12
8.5 Nouveaux codes d'erreur PCEP	12
8.6 Nouvelles raisons No-Path	13
9. Références	14
9.1 Références normatives	14
9.2 Références pour information	14
10. Remerciements	14
Appendice A. Fragments de code RBNF	15
Adresse des auteurs	15

 	1.	Introduction

La [RFC4655] définit l'architecture fondée sur l'élément de calcul de chemin (PCE, Path Computation Element) et explique comment un PCE peut calculer des chemins de commutation d'étiquettes (LSP, Label Switched Path) dans les réseaux d'ingénierie de trafic de commutation d'étiquettes multi protocoles (MPLS-TE, Multiprotocol Label Switching Traffic Engineering) et de MPLS généralisé (GMPLS, Generalized MPLS) à la demande des clients de calcul de chemin (PCC, Path Computation Client). Un PCC est montré comme étant tout composant de réseau qui fait de telles demandes et peut être, par exemple, un routeur de commutation d'étiquettes (LSR, Label Switching Router) ou un système de gestion de réseau (NMS, Network Management System). Le PCE lui-même est montré comme situé n'importe où dans le réseau, et il peut être au sein d'un LSR, d'un NMS ou d'un système de support d’exploitation (OSS, Operational Support System) ou peut être un serveur réseau indépendant.

Le protocole de communication de PCE (PCEP, PCE Communication Protocol) est le protocole de communication utilisé entre PCC et PCE, et il peut aussi être utilisé entre des PCE qui coopèrent. La [RFC4657] établit les exigences génériques de protocole pour PCEP. Des exigences supplémentaires spécifiques d'application pour PCEP sont définies dans des documents séparés.

Le présent document fournit un ensemble d'exigences et d'extensions à PCEP pour la prise en charge d'applications de calcul de chemin concurrent. Un calcul de chemin concurrent est une application de calcul de chemin où un ensemble de chemins TE sont calculés concurremment afin d'utiliser efficacement les ressources du réseau. La méthode de calcul impliquée par un calcul de chemin concurrent est appelée une "optimisation concurrente globale" dans le présent document. Les algorithmes de calcul appropriés pour effectuer ce type d'optimisation sortent du domaine d'application du présent document.

L'application d'optimisation globale concurrente (GCO, Global Concurrent Optimization) est principalement une solution de NMS ou fondée sur un serveur de PCE. Du fait de la complexité des problèmes de synchronisation associés aux applications de GCO, l'architecture de PCE fondée sur la gestion définie au paragraphe 5.5 de la [RFC4655] est considérée comme l'usage le plus convenable pour prendre en charge l'application de CGO. Cela n'empêche pas d'autres solutions architecturales de prendre en charge l'application de GCO, mais elles sont NON RECOMMANDÉES. Par exemple, GCO pourrait être activé par des LSR répartis à travers des mécanismes de synchronisation complexes. Cependant, cette approche pourrait souffrir de frais généraux de synchronisation significatifs entre le PCE et chacun des PCC. Cela affecterait probablement la stabilité du réseau et donc diminuerait significativement les avantages du déploiement des PCE.

Le besoin d'un calcul de chemin concurrent global peut aussi se faire jour quand les opérateurs de réseau ont besoin d'établir un ensemble de LSP TE dans leur processus de planification du réseau. Il est aussi envisagé que les opérateurs de réseau pourraient exiger le calcul de chemin concurrent global dans le cas de défaillance catastrophique du réseau, où un ensemble de LSP TE devraient être réacheminés de façon optimale. La nature de ce travail promeut l'utilisation de tels systèmes pour un traitement hors ligne. L'application en ligne de ce travail devrait seulement être envisagée avec une validation empirique prouvée.

Lorsque de nouveaux LSP TE sont ajoutés ou supprimés du réseau au fil du temps, les ressources globales du réseau deviennent fragmentées et le placement existant des LSP TE au sein du réseau ne fournit plus une utilisation optimale de la capacité disponible. Un calcul de chemin concurrent global est capable de prendre en compte simultanément la topologie entière du réseau et l'ensemble complet des LSP TE existants et leurs contraintes respectives, et est capable de chercher à réoptimiser le réseau entier pour satisfaire toutes les contraintes pour tous les LSP TE. Autrement, l'application peut considérer un sous ensemble des LSP TE et/ou un sous ensemble de la topologie du réseau. Noter qu'une autre préemption peut aussi aider à réduire les questions de fragmentation.

Bien que GCO soit applicable à toute demande simultanée de plusieurs LSP TE (par exemple, une demande de protection de bout en bout) il est NON RECOMMANDÉ qu'une réoptimisation concurrente globale soit appliquée dans un réseau (comme un réseau MPLS-TE) qui contient un très grand nombre de LSP TE à très faible bande passante ou à bande passante zéro car la grande portée du problème et le faible bénéfice de la réoptimisation concurrente par rapport à la réoptimisation d'un seul TE LSP a peu de chances de rendre le processus rentable. De plus, appliquer la réoptimisation concurrente globale dans un réseau avec un fort taux de changement des LSP TE (barattage) est NON RECOMMANDÉ à cause de la probabilité que des LSP TE changent avant qu'ils pourraient être réoptimisés globalement. La réoptimisation globale est plus applicable aux réseaux stables comme les réseaux de transport ou ceux avec des tunnels TE LSP à long terme.

Le principal objectif du présent document est de souligner les besoins de communication de PCC à PCE à l'appui d'une application de calcul de chemins concurrents et de définir les extensions du protocole pour satisfaire ces besoins.

Les exigences de PCC-PCE traitées ici sont spécifiques du contexte où le PCE est spécialisé comme capable d'effectuer les calculs à l'appui de la GCO. La découverte de telles capacités pourrait être désirable et pourrait être réalisée par des extensions aux mécanismes de découverte de PCE des [RFC4674], [RFC5088], [RFC5089] ; mais, ceci sort du domaine d'application du présent document.

On notera que le calcul de chemin rétro récurrent (BRPC, Backward Recursive Path Computation) [RFC5441] est une technique de calcul de chemin multi PCE utilisée pour calculer le plus court chemin inter domaines avec contraintes, tandis celui-ci spécifie une technique où un ensemble de demandes de calcul de chemin sont groupées et envoyées à un PCE avec l'objectif "d'optimiser" l'ensemble de chemins calculé.

 	2.	Terminologie

La terminologie utilisée dans le présent document est expliquée pour la plus grande part dans la [RFC4655]. Quelques termes clés sont répétés ici pour que ce soit clair.

PCC (Path Computation Client) : client de calcul de chemin. Toute application cliente 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 sur la base d'un graphe de réseau et d'appliquer des contraintes de calcul.

TED (Traffic Engineering Database) : base de données d'ingénierie de trafic. La TED contient la topologie et les informations de ressources du domaine. La TED peut être alimentée par des extensions d'IGP ou potentiellement par d'autres moyens.

PCECP (PCE Communication Protocol) : protocole de communication de PCE. PCECP est l'idée abstraite générique d'un protocole utilisé pour communiquer les demandes de calcul de chemin d'un PCC à un PCE et de retourner les chemins calculés du PCE au PCC. Le PCECP peut aussi être utilisé entre des PCE coopérants.

PCEP (PCE Protocol) : protocole d'élément de calcul de chemin. PCEP est le protocole réel qui met en œuvre l'idée de PCECP.

GCO (Global Concurrent Optimization) : optimisation concurrente globale. Application de calcul de chemins concurrents où un ensemble de chemins de TE sont calculés concurremment afin d'optimiser les ressources du réseau. Un calcul de chemin GCO est capable de considérer simultanément la topologie entière du réseau et l'ensemble complet des LSP TE existants, et leurs contraintes respectives, et cherche à optimiser ou réoptimiser le réseau entier pour satisfaire toutes les contraintes pour tous les LSP TE. Un calcul de chemin GCO peut aussi fournir une façon optimale de migrer d'un ensemble existant de LSP TE à un ensemble réoptimisé (problème de la forme).

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]. Ces termes sont utilisés pour spécifier les exigences du présent document.

 	3.	Applicabilité de l'optimisation concurrente globale (GCO)

Cette Section discute de l'architecture de PCE à laquelle la GCO est appliquée. Elle discute aussi divers scénarios d'application pour lesquels le calcul de chemins concurrents global peut être appliqué.

 	3.1	Application de l'architecture de PCE
La Figure 1 montre l'architecture de réseau fondée sur le PCE définie dans la [RFC4655] à laquelle l'application de GCO est appliquée. On doit observer que le PCC n'est pas nécessairement un LSR [RFC4655]. L'application de GCO est principalement une solution fondée sur NMS dans laquelle un NMS tient la fonction de PCC. Bien que la Figure 1 montre le PCE comme distant du NMS, il pourrait être co-localisé avec le NMS. Noter que dans le cas de co-localisation, il n'est pas besoin d'un protocole de communication standard ; cela peut s'appuyer sur des API internes.

                   Demande               -----------
                d'application           |   -----   |
                       |                |  | TED |  |
                       |                |   -----   |
                       v                |     |     |
                 ------------- Demande/ |     v     |
                |     PCC     | réponse |   -----   |
                |(NMS/serveur)|<--------+> | PCE |  |
                |             |         |   -----   |
                 -------------           -----------
               Demande |
            de service |
                       v
           -----------------  Protocole       -----------
           |Nœud d'extrémité| de signalisation|   Nœud   |
           |  de tête       |<--------------->| adjacent |
           ------ ----------                  -----------

Figure 1 : Architecture fondée sur le PCE pour l'optimisation concurrente globale

À réception d'une demande d'application (par exemple, une matrice de demande de trafic est fournie au NMS par les procédures de planification de réseau de l'opérateur) le NMS demande un calcul de chemins concurrents global au PCE. Le PCE calcule alors les chemins concurrents demandés en appliquant certains algorithmes. Divers algorithmes et techniques de calcul ont été proposés pour effectuer cette fonction. La spécification de ces algorithmes ou techniques sort du domaine d'application du présent document.

Quand le calcul de chemin demandé est achevé, le PCE renvoie les chemins résultants au NMS. Le NMS fournit alors aux LSR d'extrémité de tête un chemin explicite pleinement calculé pour chaque LSP TE qui doit être établi.

 	3.2	Optimisation de terrain vierge
L'optimisation de teraain vierge est un cas particulier d'application de GCO quand il n'y a pas de LSP TE déjà établi dans le réseau. Le besoin d'optimisation de terrain vierge apparaît quand le planificateur de réseau veut utiliser un serveur de calcul pour planifier des LSP TE qui vont être provisionnés dans le réseau. Noter que l'opération de terrain vierge est une optimisation en une seule fois. Quand les conditions du réseau changent à cause d'une défaillance ou d'autres changements, le mode de fonctionnement de réoptimisation va entrer en jeu.

Quand un nouveau réseau TE doit être provisionné dans une perspective de terrain vierge, un ensemble de LSP TE doit être créé sur la base de la demande de trafic, de la topologie du réseau, des contraintes de service, et des ressources du réseau. Dans ce scénario, la capacité d'effectuer un calcul concurrent est désirable, ou exigée, pour utiliser les ressources du réseau d'ue manière optimale et éviter des blocages.
 	3.2.1	Ingénierie du trafic sur une seule couche
L'optimisation de terrain vierge peut être appliquée quand des LSP TE spécifiques de couche doivent être créés du point de vue de terrain vierge. Par exemple, un réseau MPLS-TE peut être planifié sur la base de demandes de trafic spécifiques de couche 3, de la topologie de réseau, et des ressources disponibles du réseau. L'optimisation de terrain vierge pour l'ingénierie du trafic d'une seule couche peut être appliquée aux réseaux de transport optique comme les réseaux en hiérarchie numérique synchrone/optiques synchrones (SDH/SONET, Synchronous Digital Hierarchy/Synchronous Optical Network) le transport Ethernet, le multiplexage par division de longueur d'onde (WDM, Wavelength Division Multiplexing) etc.

 	3.2.2	Ingénierie du trafic multi-couches
L'optimisation de terrain vierge n'est pas limitée à l'ingénierie du trafic sur une seule couche. Elle peut aussi être appliquée à de l'ingénierie du trafic multi couches [RFC5623]. Les ressources et la topologie du réseau (des deux couches client et serveur) peuvent être considérées simultanément en établissant un ensemble de LSP TE qui traversent la frontière de couche.

 	3.3	Réoptimisation de réseaux existants
Le besoin de calcul de chemins concurrents global peut apparaître dans les réseaux existants. Quand un réseau TE LSP existant subit une utilisation sous optimale de ses ressources, le besoin de réoptimisation ou de reconfiguration peut apparaître. La portée de réoptimisation et reconfiguration peut varier selon les situations particulières. La portée de réoptimisation peut être limitée à une modification de bande passante à un LSP TE existant. Cependant, il se pourrait bien qu'un ensemble de LSP TE aient besoin d'être réoptimisés concurremment. Dans un cas extrême, les LSP TE peuvent devoir être globalement réoptimisés.

Dans les réseaux chargés, avec des LSP TE de grande taille, une réoptimisation séquentielle ne peut pas produire d'améliorations substantielles en termes d'optimisation globale du réseau. La réoptimisation séquentielle se réfère à une méthode de calcul de chemin qui calcule le chemin réoptimisé d'un LSP TE à la fois sans tenir compte des autres LSP TE qui ont besoin d'être réoptimisés dans le réseau. Le potentiel de gains à l'échelle du réseau de réoptimisation séquentielle des LSP TE dépend de l'usage du réseau et de la taille des LSP TE à optimiser. Cependant, le point clé reste que de calculer le chemin réoptimisé d'un LSP TE à la fois sans tenir compte des autres LSP TE dans le réseau pourrait résulter en une utilisation sous optimale des ressources du réseau. Cela peut être beaucoup plus visible dans un réseau optique avec un faible ratio de LSP TE potentiels par liaison, et beaucoup moins visible dans les réseaux de paquets avec des micro-flux de LSP TE.

À l'égard de l'applicabilité de GCO en cas de défaillances catastrophiques, il peut y avoir un avantage réel à calculer les chemins des LSP TE comme un ensemble plutôt que de calculer de nouveaux chemins à partir des LSR d'extrémité de tête de façon distribuée. La gigue distribuée est une technique qui pourrait empêcher une condition de compétition (c'est-à-dire, coucourrir pour la même ressource à partir de différents LSR d'extrémité de tête) avec un calcul réparti. GCO fournit un moyen de remplacement qui pourrait aussi empêcher une condition de compétition de manière centralisée. Cependant, un système centralisé va normalement souffrir de temps de réponse plus longs qu'un système réparti.

 	3.3.1	Reconfiguration de topologie de réseau virtuel (VNT)
La reconfiguration de la topologie de réseau virtuel [RFC5212], [RFC5623] est un scénario d'application typique où le calcul de chemins concurrents global peut être applicable. Les déclencheurs pour la reconfiguration de VNT, comme des changements de demande de trafic, des défaillances de réseau, et des changements de configuration topologique peuvent exiger qu'un ensemble de LSP TE existants soient recalculés.

 	3.3.2	Migration de trafic
Quand il migre d'un ensemble de LSP TE à un ensemble réoptimisé de LSP TE, il est important que le trafic soit déplacé sans causer de perturbation. Diverses techniques existent dans MPLS et GMPLS, comme faire avant de couper [RFC3209], pour établir les nouveaux LSP TE avant de suppprimer les anciens LSP TE. Quand plusieurs chemins de LSP TE sont changés en accord avec les résultats calculés, certains des LSP TE peuvent être pertuubés du fait de contraintes de ressources. En d'autres termes, il peut se révéler impossible d'effectuer une migration directe des anciens LSP TE aux nouveaux LSP TE optimaux sans perturber le trafic parce que il y a des ressources réseau insuffisantes pour prendre en charge les deux ensembles de LSP TE quand faire avant de couper est utilisé. Cependant, un PCE peut être capable de déterminer une séquence de remplacements de faire avant de couper individuels des LSP TE ou de petits ensembles de LSP TE afin que tout l'ensemble de LSP TE puisse migrer sans aucune perturbation. Ce scénario suppose que la bande passante du LSP TE existant soit conservée durant la migration, ce qui est exigé dans les réseaux optiques. Dans les réseaux de paquets, cette hypothèse peut être relâchée car la bande passante des LSP TE temporaires durant la migration peut être réduite à zéro.

Il peut se trouver que la réoptimisation soit radicale. Cela pourrait signifier qu'il n'est pas possible d'appliquer le faire avant de couper dans tout ordre pour migrer des anciens LSP TE aux nouveaux LSP TE. Dans ce cas, une stratégie de migration est requise qui peut nécessiter que les LSP TE soient réacheminés en utilisant le faire avant de couper sur les chemins temporaires afin de faire de la place pour la réoptimisation complète. Un PCE pourrait indiquer l'ordre dans lequel les LSP TE réoptimisés doivent être établis et prendre la place des anciens LSP TE, et il peut indiquer une série de chemins temporaires différents qui doivent être utilisés. Autrement, le PCE pourrait effectuer la réoptimisation globale comme une série de sous réoptimisations en réoptimisant des sous ensembles de l'ensemble total de LSP TE.

L'avantage de ce réacheminement multi-étapes inclut de minimiser la perturbation du trafic et un gain d'optimisation. Cependant, cette approche peut impliquer un déséquençage de certains paquets transitoires, de la gigue, ainsi qu'une tension sur le plan de contrôle.

Noter aussi que durant la réoptimisation, une perturbation du trafic peut être admise pour certains des LSP TE portant des services de faible priorité (par exemple, du trafic Internet) et non admise pour certains des LSP TE portant des services de mission critique (par exemple, du trafic vocal).

 	4.	Exigences de PCECP

Cette Section donne les exigences de PCECP pour la prise en charge des applications de calcul de chemins concurrents global. Les exigences spécifiées ici devraient être considérées comme des exigences spécifiques d'application et sont justifiables sur la base de la clause d'extensibilité du paragraphe 6.1.14 de la [RFC4657] : "Le PCECP DOIT prendre en charge les exigences spécifiées dans les documents d'exigences spécifiques de l'application. Le PCECP DOIT aussi permetttre des extensions lorsque plus d'applications PCE vont être introduites à l'avenir."

On notera aussi que certaines des exigences discutées dans cette section ont déjà été discutées dans le document des exigences pour PCECP [RFC4657]. Par exemple, le paragraphe 5.1.16 de la [RFC4657] donne une liste de contraintes génériques tandis que le paragraphe 5.1.17 de la [RFC4657] donne une liste de fonctions d'objectifs génériques qui DOIVENT être prises en charge par le PCECP. Bien qu'on utilise de telles exigences génériques comme base, cette section donne des exigences spécifiques d'application dans le contexte du calcul de chemins concurrents global et à un niveau plus détaillé que les exigences génériques.

Le PCEP DEVRAIT prendre en charge les capacités suivantes via la création de nouveaux objets et/ou la modification d'objets existants lorsque applicable.

o	Un indicateur pour porter que la demande est pour un calcul de chemins concurrents global. Cet indicateur est nécessaire pour assurer la cohérence de l'application des objectifs et contraintes globaux dans tous les calculs de chemins. Noter que cette exigence est couverte par le "calcul de chemin synchronisé" dans les [RFC4655] et [RFC4657]. Cependant, un indicateur explicite pour demander une optimisation globale concurrente est une nouvelle exigence.

o	Un champ Fonction objective globale (GOF, Global Objective Function) dans lequel spécifier la fonction objective globale. La fonction objective globale est la fonction objective supérieure à laquelle toutes les demandes individuelles de calcul de chemin sont soumises afin de trouver une solution globalement optimale. Noter que cette exigence est couverte par les "fonctions objectives synchronisées" du paragraphe 5.1.7 de la [RFC4657] et que la [RFC5541] définit trois fonstions objectives globales comme suit : une liste de fonctions objectives globales disponibles DEVRAIT inclure les fonctions objectives suivantes au minimum et DEVRAIT être extensible à de futurs ajouts :
*	Minimiser la consommation aggrégée de bande passante (MBC)
*	Minimiser la charge de la liaison la plus chargée (MLL)
*	Minimiser le coût cumulatif d'un ensemble de chemins (MCC)

o	Un champ Contraintes globales (GC, Global Constraints) dans lequel spécifier la liste de contraintes globales auxquelles tous les calculs de chemins demandés devraient être soumis. Cette liste DEVRAIT inclure les contraintes suivantes au minimum et DEVRAIT être extensible pour de futurs ajouts :
*	Valeur maximum d'utilisation de liaison -- cette valeur indique le plus fort pourcentage possible d'utilisation de liaison réglé pour chaque liaison. (Note : pour éviter des nombres à virgule flottante, les valeurs devraient être des entiers.)
*	Valeur minimum d'utilisation de liaison -- cette valeur indique le plus faible pourcentage possible d'utilisation de liaison réglé pour chaque liaison. (Note : même chose que ci-dessus.)
*	Facteur de sur réservation -- le facteur de sur réservation permet que la bande passante réservée soit sur réservée sur chaque liaison au delà de sa limite de capacité physique.
*	Nombre maximum de bonds pour tous les LSP TE -- c'est le plus grand nombre de bonds que tout LSP TE peut avoir. Noter que cette contrainte peut aussi être fournie par LSP TE (comme demandé dans la [RFC4657] et défini dans la [RFC5440]).
*	Exclusion des liaisons/nœuds dans tout calcul de chemin de LSP TE (c'est-à-dire, tous les LSP TE devraient ne pas inclure les liaisons/nœuds spécifiés dans leurs chemins). Noter que cette contrainte peut aussi être fournie par LSP TE (comme demandé dans la [RFC4657] et défini dans la [RFC5440]).
*	Une indication devrait être disponible dans une réponse de calcul de chemin que plus de réoptimisation peut seulement devenir disponible une fois que le trafic existant aura été déplacé sur les nouveaux LSP TE.

o	Un champ Vecteur concurrent global (GCV, Global Concurrent Vector) dans lequel spécifier toutes les demandes individuelles de calcul de chemin qui sont soumises au calcul de chemins concurrents et soumises à la fonction objective globale et toutes les contraintes globales. Noter que cette exigence est entièrement satisfaite par l'objet SVEC dans la spécification PCEP [RFC5440]. Comme l'objet SVEC tel que défini dans la [RFC5440] permet d'identifier un ensemble de demandes de chemins concurrents, le SVEC peut être réutilisé pour spécifier toutes les demandes de chemin concurrent individuelles pour une optimisation globale concurrente.

o	Un champ Indicateur dans lequel indiquer le résultat de la demande. Quand le PCE ne peut pas trouver une solution faisable avec la demande initiale, la raison de l'échec DEVRAIT être indiquée. Cette exigence est partiellement couverte par la [RFC4657], mais pas à ce niveau de détail. Les indicateurs suivants DEVRAIENT être pris en charge au minimum :
*	Pas de solution faisable trouvée. Noter que c'est déjà couvert dans la [RFC5440].
*	Débordement de mémoire.
*	PCE trop occupé. Noter que c'est déjà couvert dans la [RFC5440].
*	PCE incapable de réoptimisation concurrente.
*	Pas de chemin de migration disponible.
*	Les privilèges administratifs ne permettent pas la réoptimisation globale.

o	Afin de minimiser les perturbations associées au provisionnement de chemin en vrac, les exigences suivantes DOIVENT être prises en charge :
*	Le message de demande DOIT permettre de demander au PCE de fournir l'ordre dans lequel les LSP TE devraient être réoptimisés (c'est-à-dire, le chemin de migration) afin de minimiser les perturbations du trafic durant la migration. C'est-à-dire, le message de demande DOIT permettre d'indiquer au PCE que l'ensemble de chemins qui va être fourni dans le message de réponse (PCRep) doit être ordonné.
*	En réponse à la demande "d'ordre" du PCC, le PCE DOIT être capable d'indiquer dans le message de réponse (PCRep) l'ordre dans lequel les LSP TE devraient être réoptimisés afin de minimiser la perturbation du trafic. Il devrait indiquer pour chaque demande l'ordre dans lequel l'ancien LSP TE devrait être supprimé et l'ordre dans lequel le nouveau LSP TE devrait être établi. Si l'ordre de suppression est inférieur à l'ordre d'établissement, cela signifie que le "faire avant de couper" ne peut pas être fait pour cette demande. Il PEUT aussi être désirable d'avoir le PCE indiquer si l'ordre est en fait exigé ou non.
*	Durant une migration, il ne peut pas être possible de faire avant de couper pour tous les LSP TE existants. Le message de demande DOIT permettre d'indiquer pour chaque demande si le faire avant de couper est exigé (par exemple, trafic vocal) ou acceptable (par exemple, trafic Internet). Le message de réponse doit permettre d'indiquer les LSP TE pour lesquels la réoptimisation "faire avant de couper" n'est pas possible (cela va être déduit des ordres d'établissement et de suppression du LSP TE).

 	5.	Extensions du protocole pour la prise en charge de l'optimisation concurrente globale

Cette Section donne les extensions du protocole pour la prise en charge de l'optimisation concurrente globale. Les extensions de protocole discutées dans cette section sont construites sur la [RFC5440].

Le format d'un message PCReq après l'incorporation des nouvelles exigences pour la prise en charge de l'optimisation concurrente globale est comme suit. Le format de message utilise le format Backus-Naur réduit comme défini dans la [RFC5511]. Voir à l'Appendice A un ensemble complet de fragments de RBNF défini dans le présent document et la licence de code nécessaire.

<Message PCReq> ::= <En-tête commun> [<svec-list>] <request-list>

Le <svec-list> est changé comme suit :

<svec-list> ::= <SVEC> [<OF>] [<GC>] [<XRO>] [<svec-list>]

Noter que trois objets facultatifs sont ajoutés, à la suite de l'objet SVEC :  l'objet Fonction objective (OF, Objective Function) qui est défini dans la [RFC5541], l'objet Contraintes globales (GC, Global Constraints) qui est défini dans le présent document (paragraphe 5.5) ainsi que l'objet Chemin exclu (XRO, eXclude Route Object) qui est défini dans la [RFC5521]. Le placement de l'objet OF (dans lequel est spécifiée la fonction objective globale) dans la liste de SVEC est défini dans la [RFC5541]. Les détails de ce changement vont être discutés dans les paragraphes qui suivent.

Noter aussi que quand le XRO est global pour un SVEC, et que le bit F est établi, il DEVRAIT être permis de spécifier plusieurs objets Record Route dans le message PCReq.

 	5.1	Spécification de la fonction objective globale (GOF)
La fonction objective globale peut être spécifiée dans l'objet Fonction objective (OF, Objective Function) PCEP, défini dans la [RFC5541]. L'objet OF inclut un identifiant de 16 bits de fonction objective. Comme discuté dans la [RFC5541], les codets d'identifiant de fonction objective sont gérés par l'IANA.

Trois fonctions objectives globales définies dans la [RFC5541] sont utilisées dans le contexte de GCO.

Code de fonction	Description
4	minimiser la consommation de bande passante agrégée (MBC)
5	minimiser la charge de la liaison la plus chargéé (MLL)*
6	minimiser le coût cumulé d'un ensemble de chemins (MCC)

* Note : ceci peut être réalisé par la fonction objective suivante : minimiser le maximum sur toutes les liaisons {A(i)/C(i)} où C(i) est la capacité de la liaison pour la liaison i, et A(i) est la bande passante totale allouée sur la liaison i.

 	5.2	Indication des demandes d'optimisation concurrente globale
Toutes les demandes de chemin dans cette application devraient être indiquées pour que la fonction objective globale et toutes les contraintes globales soient appliquées à chaque calcul de chemin demandé. Cela peut être indiqué implicitement en plaçant les objets relatifs à la GCO (OF, GC, ou XRO) après l'objet SVEC. C'est-à-dire, si un de ces objets suit l'objet SVEC dans le message PCReq, tous les calculs de chemin demandés spécifiés dans l'objet SVEC sont soumis à OF, GC, ou XRO.

 	5.3	Demande pour l'ordre de TE LSP
Afin de minimiser la perturbation associée au provisionnement de chemin en vrac, le PCC peut indiquer au PCE que la réponse DOIT être ordonnée. C'est-à-tdire que le PCE doit inclure l'ordre dans lequel les LSP TE DOIVENT être déplacés afin de minimiser la perturbation du trafic. Pour prendre en charge cette indication, un nouveau fanion, le fanion D, est défini dans l'objet RP comme suit :

Bit D (orDer - 1 bit) : quand il est établi dans un message PCReq, le PCC demandeur exige que le PCE spécifie dans le message PCRep l'ordre dans lequel cette demande particulière de chemin doit être provisionnée par rapport aux autres demandes.

Pour prendre en charge la détermination de si l'optimisation faire avant de couper est exigée, un nouveau fanion, le fanion M, est défini dans l'objet RP comme suit :

Bit M (Make-before-break - 1 bit) : quand il est établi, cela indique qu'une réoptimisation faire avant de couper est exigée pour cette demande.

Quand le bit M n'est pas établi, cela implique qu'une réoptimisation faire avant de couper est permise pour cette demande. Noter que le bit M ne peut être établi que si le fanion R (Réoptimisation) est établi.

Deux nouveaux bits fanions sont définis pour être portés dans le champ Fanions dans l'objet RP :
Bit 21 (bit M) : quand établi, faire avant de couper est exigé.
Bit 22 (bit D) : quand établi, le rapport de l'ordre de demande est exigé.

 	5.4	Réponse Order
Le PCE DOIT spécifier le numéro d'ordre en réponse à la demande Order faite par le PCC dans le message PCReq si il l'a demandé par l'établissement du bit D dans l'objet RP dans le message PCReq. Pour prendre en charge une telle indication d'ordre, un nouveau TLV facultatif, le TLV Order, est défini dans l'objet RP.

Le TLV Order est un TLV facultatif dans l'objet RP, qui indique l'ordre dans lequel l'ancien LSP TE doit être supprimé et le nouveau LSP TE doit être établi durant une réoptimisation. Il est porté dans le message PCRep en réponse à une demande de réoptimisation.

Le TLV Order DOIT être inclus dans l'objet RP dans le message PCRep si le bit D est établi dans l'objet RP dans le message PCReq.

Le format du TLV Order est 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            |
+---------------+---------------+---------------+---------------+
|                          Ordre de suppression                 |
+---------------+---------------+---------------+---------------+
|                          Ordre d'établisssement               |
+---------------+---------------+---------------+---------------+

Figure 2 : TLV Order dans l'objet RP du message PCRep

Type : 5
Longueur : variable

Ordre de suppression : entier de 32 bits qui indique l'ordre dans lequel le vieux LSP TE devrait être supprimé.

Ordre d'établissement : entier de 32 bits qui indique l'ordre dans lequel le nouveau LSP TE devrait être établi.

L'ordre de suppression NE DEVRAIT PAS être égal à l'ordre d'établissement. Si l'ordre de suppression est supérieur à l'ordre d'établissement, cela signifie que la réoptimisation peut être faite de manière faire avant de couper ; autrement, elle ne le peut pas.

Pour un nouveau LSP TE, l'ordre de suppression n'est pas applicable. La valeur de 0 est destinée à spécifier ce cas. Quand la valeur de l'ordre de suppression est 0, cela implique que le LSP TE résultant est un nouveau LSP TE.

Pour illustrer cela, considérons un réseau avec deux LSP TE établis : R1 avec le chemin P1, et R2 avec le chemin P2. Durant une réoptimisation, le PCE peut fournir la réponse ordonnée suivante :

R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2

Cela indique que le NMS devrait effectuer la séquence de tâches suivante :
1 : supprimer le chemin P1
2 : établir le chemin P2'
3 : supprimer le chemin P2
4 : établir le chemin P1'

C'est-à-dire que R1 est réoptimisé de manière "couper avant de faire" et R2 de manière "faire avant de couper".

 	5.5	Objet Global constraints (GC)
L'objet Global constraints (GC) est utilisé dans un message PCReq pour spécifier les contraintes globales nécessaires qui devraient être appliquées à tout calcul individuel de chemin pour une demande d'optimisation de chemin concurrent global.

La classe d'objet de Global-constraints est 24.
Le type d'objet Global Constraints est 1.

Le format du corps d'objet GC qui inclut les contraintes globales est 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    MH         |    MU         |    mU         |    OB         |
+---------------+---------------+---------------+---------------+
|                                                               |
//                         TLV facultatifs                     //
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 3 : Format de corps d'objet GC

MH (Max Hop) 8 bits : entier de 8 bits qui indique le compte maximum de bonds pour tous les LSP TE.

MU (Max Utilization Percentage) 8 bits : entier de 8 bits qui indique la limite supérieure du pourcentage d'utilisation pour toutes les liaisons. Utilisation = (Capacité de liaison - Bande passante allouée sur la liaison)/ Capacité de liaison. MU est destiné à être un entier qui peut seulement être entre 0 et 100.

mU (minimum Utilization Percentage) 8 bits : entier de 8 bits qui indique la limite inférieure du pourcentage d'utilisation pour toutes les liaisons. mU est destiné à être un entier entre 0 et 100.

OB (Over Booking factor Percentage) 8 bits : entier de 8 bits qui indique le pourcentage de sur réservation qui permet que la bande passante réservée soit sur réservée sur chaque liaison au delà de sa limite de capacité physique. La valeur, par exemple, 10 % signifie que 110 Mbit/s peuvent être réservés sur une liaison à 100 Mbit/s.

L'exclusion de la liste de nœuds/liaisons d'un calcul de chemin global peut être faite en incluant l'objet XRO à la suite de l'objet GC dans la nouvelle définition de SVEC-list.

Les TLV facultatifs peuvent être inclus dans le corps d'objet GC pour spécifier des contraintes globales supplémentaires. Le format et le traitement de TLV est cohérent avec le paragraphe 7.1 de la RFC 5440. Tous les TLV vont être alloués à partir du registre "Indicateurs de type de TLV PCEP". Noter qu'aucun TLV n'est défini dans le présent document.

 	5.6	Indicateur d'erreur
Pour indiquer les erreurs associées à la demande d'optimisation de chemin concurrent global, un nouveau type d'erreur (14) et les valeurs d'erreur suivantes sont définies comme suit pour être incluses dans l'objet PCEP-ERROR :

Un nouveau type d'erreur de (15) et les valeurs d'erreur suivantes sont définies comme suit :

Type d'erreur 15 ; valeur d'erreur =1 : si un PCE reçoit une demande d'optimisation de chemin concurrent global et si le PCE n'est pas capable de traiter la demande à cause d'une mémoire insuffisante, le PCE DOIT envoyer un message PCErr avec un objet PCEP-ERROR (Type d'erreur = 15) et une valeur d'erreur de 1). Le PCE cesse le traitement de la demande. La demande d'optimisation de chemin concurrent global correspondante DOIT être annulée au PCC.

Type d'erreur 15 ; valeur d'erreur =2 : si un PCE reçoit une demande d'optimisation de chemin concurrent global et si le PCE n'est pas capable d'optimisation concurrente globale, le PCE DOIT envoyer un message PCErr avec un objet PCEP-ERROR (Type d'erreur =15) et une valeur d'erreur =2). Le PCE cesse le traitement de la demande. La demande d'optimisation de chemin concurrent global correspondante DOIT être annulée au PCC.

Pour indiquer une erreur associée à une violation de politique, une nouvelle valeur d'erreur "optimisation concurrente globale interdite" devrait être ajoutée à un code d'erreur existant pour la violation de politique (Type d'erreur =5) comme défini dans la [RFC5440].

Type d'erreur = 5 ; valeur d'erreur = 5 : si un PCE reçoit une demande d'optimisation de chemin concurrent global qui n'est pas conforme aux privilèges administratifs (c'est-à-dire, si la politique du PCE ne prend pas en charge l'optimisation concurrente globale) le PCE envoie un message PCErr avec un objet PCEP-ERROR (Type d'erreur = 5) et une valeur d'erreur = 5). Le PCE cesse le traitement de la demande. La demande d'optimisation de chemin concurrent global correspondante DOIT être annulée au PCC.

 	5.7	Indicateur NO-PATH 
Pour communiquer la ou les raisons de n'être pas capable de trouver le calcul de chemins concurrents global, l'objet NO-PATH peut être utilisé dans le message PCRep. Le format du corps de l'objet NO-PATH est défini dans la [RFC5440]. L'objet peut contenir un TLV NO-PATH-VECTOR pour fournir des informations supplémentaires sur la raison pour laquelle un calcul de chemin a échoué.

Deux nouveaux bits fanions sont définis pour être portés dans le champ Fanions dans le TLV NO-PATH-VECTOR porté dans l'objet NO-PATH.

Bit 6 : quand il est établi, le PCE indique qu'aucun chemin de migration n'a été trouvé.

Bit 7 : Quand il est établi, le PCE indique qu'aucune solution faisable n'a été trouvé qui satisfasse toutes les contraintes associées à l'optimisation de chemin concurrent global dans le message PCRep.

 	6.	Considérations de gestion

La gestion du calcul de chemins concurrents global avec des PCE doit traiter les considérations suivantes :

 	6.1	Contrôle de fonction et de politique
En plus des paramètres déjà mentionnés au paragraphe 8.1 de la [RFC5440], une mise en œuvre de PCEP DEVRAIT permettre de configurer les paramètres de session PCEP suivants sur un PCC :
o	Capacité d'envoyer une demande de GCO.

En plus des paramètres déjà mentionnés au paragraphe 8.1 de la [RFC5440], une mise en œuvre de PCEP DEVRAIT permettre de configurer les paramètres de session PCEP suivants sur un PCC :
o	Prise en charge de l'optimisation concurrente globale.
o	Nombre maximum de demandes de chemins synchronisés par message de demande.
o	Ensemble de politiques spécifiques de GCO (envoyeur autorisé, limiteur de taux de demande, etc.).

Ces paramètres peuvent être configurés comme des paramètres par défaut pour toute session PCEP à laquelle participe le locuteur PCEP, ou peuvent s'appliquer à une session spécifique avec un homologue PCEP donné ou un groupe spécifique de sessions avec un groupe spécifique d'homologues PCEP.

 	6.2	Modèles d'information et de données (par exemple, module de MIB)
Des extensions au module de MIB PCEP défini dans la [RFC7420] devraient être définies, afin de couvrir les informations de GCO introduites dans le présent document.

 	6.3	Détection et surveillance de vie
Les mécanismes définis dans le présent document n'impliquent aucune nouvelle exigence de détection et surveillance de vie en plus de celles déjà mentionnées au paragraphe 8.3 de la [RFC5440].

 	6.4	Vérification du fonctionnement correct
Les mécanismes définis dans le présent document n'impliquent aucune nouvelle exigence de vérification en plus de celles déjà mentionnées au paragraphe 8.4 de la [RFC5440]

 	6.5	Exigences sur d'autres protocoles et composants fonctionnels
Les mécanismes de découverte de PCE ([RFC5088] et [RFC5089]) peuvent être utilisés pour annoncer des capacités de calcul de chemins concurrents global aux PCC. Un nouveau fanion (valeur = 9) dans le sous TLV PCE-CAP-FLAGS a été alloué pour être capable d'indiquer la capacité de GCO.

 	6.6	Impact sur le fonctionnement du réseau
Les mécanismes définis dans le présent document n'impliquent aucune nouvelle exigence de fonctionnement du réseau en plus de celles déjà mentionnées au paragraphe 8.6 de la [RFC5440].

 	7.	Considérations sur la sécurité

Quand la réoptimisation globale est appliquée à un réseau actif, elle pourrait être extrêmement perturbante. Bien que les questions de sécurité et de politique réelles s'appliquent au NMS, si des résultats faux sont retournés au NMS, de mauvaises actions peuvent être effectuées dans le réseau. Donc, il est très important que l'opérateur qui produit les commandes ait une autorité suffisante et soit authentifié, et que la demande de calcul soit soumise à la politique appropriée.

Le mécanisme défini dans la [RFC5440] pour sécuriser une session PCEP peut être utilisé pour sécuriser les demandes/réponses de calcul de chemins concurrents global.

 	8.	Considérations relatives à l'IANA

L'IANA tient un registre des paramètres PCEP. L'IANA a fait des allocations à partir des sous registres comme décrit dans les paragraphes suivants.

 	8.1	Fanions de bit de paramètre de demande
Comme décrit au paragraphe 5.3, deux nouveaux bits fanions sont définis pour inclusion dans le champ Fanions de l'objet RP. L'IANA a fait les allocations suivantes dans le sous registre "Champ Fanions d'objet RP".

Bit	Description	Référence
21	Faire avant coupure (bit M-)	[RFC5557]
22	Rapport de l'ordre de demande (bit D)	[RFC5557]

 	8.2	Nouveau TLV PCEP
Comme décrit au paragraphe 5.4, un nouveau TLV PCEP est défini pour indiquer l'ordre d'établissement et de suppression des LSP TE dans une GCO. L'IANA a fait l'allocation suivante dans le sous registre "Indicateurs de type de TLV PCEP".

Type de TLV	Signification	Référence
	5	TLV Ordre	[RFC5557]

 	8.3	Nouveau fanion dans le sous TLV PCE-CAP-FLAGS dans PCED
Comme décrit au paragraphe 6.5, un nouveau sous TLV PCE-CAP-FLAGS est défini pour indiquer la capacité GCO. L'IANA a fait l'allocation suivante dans le sous registre"Fanions de capacité d'élément de calcul de chemin (PCE)", qui a été créé au paragaphe 7.2 de la RFC 5088. C'est un registre OSPF.

Fanion	Signification	Référence
      9	Optimisation concurrente globale (GCO)	[RFC5557]

 	8.4	Nouvel objet PCEP
Comme décrit au paragraphe 5.5, un nouvel objet PCEP est défini pour porter les contraintes globales. L'IANA a fait l'allocation suivante dans le registre "Objets PCEP".

Classe d'objet	Nom	Référence
24 	GLOBAL-CONSTRAINTS	[RFC5557]
	Type d'objet 1 : Contraintes globales	[RFC5557]

 	8.5	Nouveaux codes d'erreur PCEP
Comme décrit au paragraphe 5.6, de nouveaux codes d'erreur PCEP sont définis pour les erreurs de GCO. L'IANA a fait les allocations suivantes dans le sous registre "Types et valeurs d'erreur d'objet PCEP-ERROR" comme indiqué dans les paragraphes suivants.

 	8.5.1	Nouvelles valeurs d'erreur pour des types d'erreur existants
Type d'erreur	Signification	Référence
        5	Violation de politique
	Valeur d'erreur =5 : Optimisation concurrente globale interdite	[RFC5557]

 	8.5.2	Nouveaux types et valeurs d'erreur
Type d'erreur	Signification	Référence
      15	Erreur d'optimisation concurrente globale	[RFC5557]
	Valeur d'erreur = 1 : mémoire insuffisante	[RFC5557]
	Valeur d'erreur = 2 : Optimisation concurrente globale non prise en charge	[RFC5557]

 	8.6	Nouvelles raisons No-Path
L'IANA a fait les allocations suivantes dans le sous registre "Champ de fanion de TLV NO-PATH-VECTOR" pour les bits de fanion portés dans le TLV NO-PATH-VECTOR sans l'objet PCEP NO-PATH comme décrit au paragraphe 5.7.

Numéro de bit	Nom	Référence
     25	Pas de solution GCO trouvée	[RFC5557]
     26	Pas de chemin de migration GCO trouvé	[RFC5557]

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

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

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

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

[RFC5541]	JL. Le Roux, JP. Vasseur, Y. Lee, "Codage de fonctions objectives dans le protocole de communication d'élément de calcul de chemin (PCECP)", juin 2009. (P. S.)

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

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

[RFC4674]	J. Ash. et J.L. Le Roux, éditeurs, "Exigences pour la découverte d'élément de calcul de chemin (PCE)", octobre 2006. (Info.)

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

[RFC5521]	E. Oki, T. Takeda, A. Farrel, "Extensions au protocole de communication d'élément de calcul de chemin (PCEP) pour les exclusions de chemins", avril 2009. (P. S.)

[RFC5512]	P. Mohapatra, E. Rosen, "Identifiant de famille d'adresse suivante (SAFI) d'encapsulation BGP et attribut d'encapsulation de tunnel de BGP", avril 2009. (P. S.)

[RFC5623]	E. Oki, T. Takeda, JL. Le Roux, A. Farrel, "Cadre pour l'ingénierie de trafic MPLS et GMPLS inter couche fondée sur PCE", septembre 2009. (Information)

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

 	10.	Remerciements

Merci à Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So, Lucy Yong, et Fabien Verhaeghe de leurs utiles commentaires et suggestions.

 	Appendice A.	Fragments de code RBNF

Cet appendice contient l'ensemble complet de fragments de code définis dans ce document.

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

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

   <PCReq Message> ::= <Common Header>
                       [<svec-list>]
                       <request-list>

   <svec-list> ::= <SVEC>
                   [<OF>]
                   [<GC>]
                   [<XRO>]
                   [<svec-list>]

 	Adresse des auteurs

Young Lee	JL Le Roux	
Huawei	France Telecom	
1700 Alma Drive, Suite 100	2, Avenue Pierre-Marzin	
Plano, TX  75075	Lannion  22307	
US	FRANCE	
téléphone : +1 972 509 5599 x2240	mél : jeanlouis.leroux@orange-ftgroup.com	
mél : ylee@huawei.com		

Eiji Oki	Daniel King	
University of Electro-Communications	Old Dog Consulting	
1-5-1 Chofugaoka	United Kingdom	
Chofu, Tokyo  182-8585	mél : daniel@olddog.co.uk	
JAPAN		
mél : oki@ice.uec.ac.jp