Groupe de travail Réseau	J. Ash, éditeur, AT&T	
Request for Comments : 4657	J.L. Le Roux, éditeur, France Telecom	
Catégorie : Information	septembre 2006	
Traduction Claude Brière de L'Isle		

Exigences génériques du protocole de communication par élément de calcul de chemin (PCE)

Statut de ce mémoire
Le présent mémoire fournit des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2006).

Résumé
Le modèle PCE est décrit dans le document "Architecture PCE" et facilite les demandes de calcul de chemin provenant des clients de calcul de chemin (PCC, Path Computation Client) aux éléments de calcul de chemin (PCE, Path Computation Element). Le présent document spécifie les exigences génériques pour un protocole de communication entre les PCC et les PCE, et aussi entre les PCE lorsque la coopération entre PCE est désirable. Des documents ultérieurs spécifieront les exigences spécifiques des applications pour le protocole de communication de PCE.
Table des matières
1. Introduction	1
2. Conventions utilisées dans le présent document	2
3. Terminologie	2
4. Vue d'ensemble du protocole de communication de PCE (PCECP)	2
5. Exigences génériques du protocole de communication de PCE	3
5.1. Exigences de base du protocole	3
5.2. Exigences de prise en charge de déploiement	8
5.3 Détection de vivacité et exigence de récupération	8
6. Considérations sur la sécurité	9
7. Considérations de gestion	9
8. Contributeurs	10
9. Remerciements	10
10. Références	10
10.1 Références normatives	10
10.2 Références pour information	10
Adresse des auteurs	11
Déclaration complète de droits de reproduction	11

 	1.	Introduction

Un élément de calcul de chemin (PCE, Path Computation Element) [RFC4655] prend en charge les demandes de calcul de chemin produites par un client de calcul de chemin (PCC, Path Computation Client) qui peut être "composite" (co-localisé) ou "externe" (distant) d'un PCE. Quand le PCC est externe au PCE, un protocole de communication de demande/réponse est nécessaire pour porter la demande de calcul de chemin et retourner la réponse. Afin que le PCC et le PCE communiquent, le PCC doit connaître la locatisation du PCE ; la découverte de PCE est décrite dans la [RFC4674].

Le PCE opère sur un graphe de réseau afin de calculer les chemins sur la base de la ou des demandes de calcul de chemin produites par le ou les PCC. La demande de calcul de chemin va inclure la source et la destination des chemins à calculer et un ensemble de contraintes à appliquer durant le calcul, et elle peut aussi inclure une fonction d'objectifs. La réponse de PCE inclut les chemins calculés ou la raison de l'échec de leur calcul.

Le présent document fait la liste d'un ensemble d'exigences génériques pour le protocole de communication de PCE (PCECP, PCE Communication Protocol). Les exigences spécifiques d'application sortent du domaine d'application du présent document, et seront traitées dans des documents distincts. Par exemple, les exigences de protocole de communication spécifiques de l'application sont traitées dans les [RFC4927] et [RFC6457] pour les applications de PCE respectivement inter-zone et inter-couche.

 	2.	Conventions utilisées dans le présent document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119].

 	3.	Terminologie

Domaine : toute collection d'éléments de réseau au sein d'une sphère commune de gestion d'adresses ou de responsabilité de calcul de chemin. Des exemples de domaines incluent les zones du protocole de passerelle intérieure (IGP, Interior Gateway Protocol), les systèmes autonomes (AS, Autonomous System), plusieurs AS au sein du réseau d'un fournisseur de services, ou plusieurs AS à travers plusieurs réseaux de fournisseur de services.

GMPLS (Generalized Multi-Protocol Label Switching) : commutation d'étiquettes multi protocoles généralisée

LSP (Label Switched Path) : chemin de commutation d'étiquettes MPLS/GMPLS

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

MPLS (Multi-Protocol Label Switching) : commutation d'étiquettes multi protocoles

PCC (Path Computation Client) : client de calcul de chemin, toute application de client qui demande qu'un calcul de chemin soit effectué par le PCE.

PCE (Path Computation Element) : élément de calcul de chemin ; entité (composant, application ou nœud de réseau) qui est capable de calculer un chemin de réseau ou une route sur la base d'un graphe de réseau et d'appliquer les contraintes de calcul (voir la description complète dans la [RFC4655]).

TED (Traffic Engineering Database) : base de données d'ingénierie de trafic, qui contient les informations de topologie et de ressources du réseau ou segment de réseau utilisé par un PCE.

TE LSP (Traffic Engineering (G)MPLS Label Switched Path) : chemin à commutation d'étiquette (G)MPLS à ingénierie de trafic.

Voir dans la [RFC4655] d'autres définitions de termes.

 	4.	Vue d'ensemble du protocole de communication de PCE (PCECP)

Dans le modèle de PCE, les demandes de calcul de chemin qui sont produites d'un PCC à un PCE peuvent être composites (co-localisées) ou externes (distantes). Si le PCC et le PCE ne sont pas colocalisés, un protocole de communication de demande/réponse est nécessaire pour porter la demande et retourner la réponse. Si le PCC et le PCE sont colocalisés, un protocole de communication n'est pas nécessaire, mais les mises en œuvre peuvent choisir d'utiliser un protocole pour les échanges entre les composants.

Afin qu'un PCC et un PCE communiquent, le PCC doit connaître la localisation du PCE. Cela peut être configuré ou découvert. Le mécanisme de découverte de PCE sort du domaine d'application du présent document, mais les exigences sont décrites dans la [RFC4674].

Le PCE opère sur un graphe de réseau construit à partir de la TED afin de calculer les chemins. Le mécanisme par lequel est constituée la TED sort du domaine d'application de PCECP.

Une demande de calcul de chemin produite par le PCC inclut une spécification du ou des chemins nécessaires. Les informations fournies incluent, au minimum, la source et la destination des chemins, mais peuvent aussi inclure un ensemble d'autres exigences (connues comme des contraintes) comme décrit à la Section 5.

La réponse du PCE peut être positive et dans ce cas elle va inclure les chemins calculés. Si le calcul échoue ou ne peut pas être effectué, une réponse négative est nécessaire avec une indication du type de défaillance.

Un protocole de demande/réponse est aussi nécesaire pour qu'un PCE communique les demandes de calcul de chemin à un autre PCE et pour que ce PCE retourne la réponse du calcul de chemin. Comme décrit dans la [RFC4655], il n'y a pas de raison de supposer que deux protocoles différents sont nécessaires, et le présent document suppose qu'un seul protocole va satisfaire toutes les exigences pour la communication de PCC à PCE et de PCE à PCE.

La [RFC4655] décrit quatre modèles de PCE : composite, externe, calcul de chemin de multiples PCE, et calcul de chemin de multiples PCE avec communication inter-PCE. Dans tous les cas sauf celui du modèle de PCE composite, un PCECP est exigé. Les exigences définies dans le présent document sont applicables à tous les modèles décrits dans la [RFC4655].

 	5.	Exigences génériques du protocole de communication de PCE
 	5.1.	Exigences de base du protocole
 	5.1.1	Généralités de la communication de PCC à PCE et de PCE à PCE
Un seul protocole DOIT être défini pour la communication de PCC à PCE et de PCE à PCE. Un PCE qui demande un chemin à un autre PCE peut être considéré comme un PCC, et dans la suite de ce document on se réfère à toutes les communications comme de PCC à PCE sans considération de si elles sont de PCC à PCE ou de PCE à PCE.

 	5.1.2	Communication client-serveur
La communication de PCC à PCE est par nature client-serveur. Le PCECP DOIT permettre à un PCC d'envoyer un message de demande à un PCE pour demander un calcul de chemin, et à un PCE de répliquer par un message de réponse au PCC demandeur une fois que le chemin a été calculé.

En plus de ce mode demande-réponse, il y a des cas où il y a une communication non sollicitée du PCE au PCC (voir le paragraphe 5.1.11).

 	5.1.3	Transport
Le PCECP DEVRAIT utiliser un protocole de transport existant qui prend en charge le contrôle d'encombrement. Ce protocole de transport peut aussi être utilisé pour satisfaire des exigences d'autres sections de ce document, comme la fiabilité. Le PCECP DEVRAIT être défini pour un seul protocole de transport afin d'assurer l'interopérabilité. Le protocole de transport NE DOIT PAS limiter la taille du message utilisé par le PCECP.

 	5.1.4	Demandes de calcul de chemin
Le message de demande de calcul de chemin DOIT inclure au moins la source et la destination. Noter que la demande de calcul de chemin est pour un LSP ou segment de LSP, et la source et destination fournies sont le début et la fin du calcul demandé (c'est-à-dire, du segment de LSP).

Le message de demande de calcul de chemin DOIT prendre en charge l'inclusion d'un ensemble d'une ou plusieurs contraintes de chemin, incluant sans s'y limiter la bande passante demandée ou les ressources (bonds, affinités, etc.) à inclure/exclure. Par exemple, un PCC peut demander au PCE d'exclure des points de défaillance dans le calcul d'un nouveau chemin si l'établissement d'un LSP échoue. L'inclusion réelle de contraintes est un choix du PCC qui produit la demande. Une liste des contraintes centrales à prendre en charge par le PCECP est fournie au paragraphe 5.1.16. La spécification des contraintes DOIT être durable dans le temps, comme décrit au paragraphe 5.1.14.

Le demandeur DOIT pourvoir choisir dans une liste annoncée ou préférée ou dans un sous ensemble minimal de fonctions objectives standard et d'options fonctionnelles. Une fonction objective est utilisée par le PCE pour traiter les contraintes d'une demande de calcul de chemin quand il calcule un chemin afin de choisir le "meilleur" chemin candidat (par exemple, le chemin minimum du bond) et correspond aux critères d'optimisation utilisés pour le calcul d'un chemin, ou le calcul synchronisé d'un ensemble de chemins. Dans le cas d'un calcul de chemin non synchronisé, ceci peut être, par exemple, le coût du chemin ou la bande passante résiduelle sur la liaison la plus chargée du chemin. Dans le cas de calcul de chemin synchronisé, ce peut être, par exemple, la consommation globale de bande passante ou la bande passante résiduelle de la liaison la plus chargée du chemin.

Une liste des fonctions objectives centrales qui DOIVENT être prises en charge par le PCECP est donnée au paragraphe  5.1.17. La spécification des fonctions objectives DOIT être durable dans le temps, comme décrit au paragraphe 5.1.14.

Le demandeur DEVRAIT aussi être capable de choisir une fonction objective ou option fonctionnelle spécifique de fabricant ou expérimentale. De plus, il DOIT être permis au demandeur de personnaliser les fonctions/options utilisées. C'est-à-dire que les fonctions objectives individuelles vont souvent avoir des paramètres à établir dans la demande de PCC à PCE. La prise en charge de la spécification des fonctions objectives et des paramètres objectifs est exigée dans l'extensibilité de protocole spécifiée au paragraphe 5.1.14.

Un message de demande PEUT inclure les paramètres d'ingénierie du trafic (TE) portés par le protocole de signalisation d'établissement dc LSP MPLS/GMPLS. Aussi, il DOIT être possible au PCE d'appliquer des fonctions objectives supplémentaires. Cela pourrait inclure un calcul de chemin fondé sur la politique d'acheminement pour l'équilibrage de charge gouverné par le plan de gestion.

Le choix du plus court chemin peut s'appuyer soit sur la métrique de TE, soit sur la métrique IGP [RFC3785]. Donc, le message de demande PCECP DOIT permettre au PCC d'indiquer le type de métrique (IGP ou TE) à utiliser pour le choix du plus court chemin. Noter que d'autres types de métriques pourront être spécifiés à l'avenir.

Il peut y avoir des cas où un seul chemin ne peut pas tenir dans une certaine demande de bande passante, alors qu'un ensemble de chemins pourrait être combiné pour faire tenir la demande. Une telle combinaison de chemins pour servir une certaine demande est appelée équilibrage de charge. Le message de demande DOIT permettre au PCC d'indiquer si l'équilibrage de charge est permis. Il DOIT aussi inclure le nombre maximum de chemins dans un groupe de chemins d'équilibrage de charge, et la bande passante minimum de chemin dans un groupe de chemin d'équilibrage de charge. Le message de demande DOIT permettre la spécification du degré de disjonction des membres du groupe d'équilibrage de charge.

 	5.1.5	Réponses de calcul de chemin
Le message de réponse de calcul de chemin DOIT permettre au PCE de retourner divers éléments incluant, au moins, le ou les chemins calculés.

Le protocole DOIT être capable de retourner tout chemin explicite dont l'utilisation serait acceptable pour les LSP MPLS et GMPLS une fois convertis en objet de chemin explicite à utiliser par la signalisation RSVP-TE. De plus, tout ce qui peut être exprimé comme objet de chemin explicite DOIT être capable de retourner sur le chemin calculé. Noter que le ou les chemins résultants peuvent être constitués d'un ensemble strict ou lâche de bonds, ou de toute combinaison de bonds stricts et lâches. De plus, un bond peut avoir la forme d'un nœud abstrait non simple. Voir dans la [RFC3209] les définitions de bond strict, bond lâche, et nœud abstrait.

Une réponse positive de la part du PCE DOIT inclure les chemins qui ont été calculés. Une réponse positive de calcul de PCECP DOIT prendre en charge l'inclusion d'un ensemble d'attributs du chemin calculé, comme les coûts du chemin (par exemple, les métriques TE cumulatives de liaison et les métriques IGP cumulatives de liaison) et la bande passante calculée. Cette dernière est utile quand un seul chemin ne peut pas servir la bande passante demandée et que l'équilibrage de charge est appliqué.

Quand un chemin satisfaisant les contraintes ne peut être trouvé, ou si le calcul échoue ou ne peut être effectué, une réponse negative DOIT être envoyée. Cette réponse PEUT inclure plus de détails sur la ou les raisons de la défaillance et PEUT inclure un avis sur les contraintes qui pourraient être relâchées pour améliorer la probabilité d'un résultat positif.

Le message de réponse PCECP DOIT prendre en charge l'inclusion de l'ensemble de chemins calculés d'un groupe de chemins d'équilibrage de charge, ainsi que leur bande passante respective.

 	5.1.6	Annulation des demandes en instance
Un PCC DOIT être capable d'annuler une demande en instance en utilisant un message approprié. Un PCC qui a envoyé une demande à un PCE et n'a plus besoin d'une réponse, par exemple, parce qu'il ne veut plus établir le service associé, DOIT être capable de notifier au PCE qu'il peut supprimer la demande (c'est-à-dire, arrêter le calcul si il est déjà commencé, et libérer le contexte). Le PCE peut aussi souhaiter annuler une demande en instance à cause d'un état d'encombrement.

 	5.1.7	Plusieurs demandes et réponses
Il DOIT être possible d'envoyer plusieurs demandes de calcul de chemin au sein du même message de demande. De telles demandes peuvent être corrélées (par exemple, en demandant des chemins disjoints) ou non corrélés (en demandant des chemins pour des services sans relation). Il DOIT être possible de limiter par configuration des PCC et des PCE le nombre de demandes qui peuvent être portées dans un seul message.

De même, il DOIT être possible de retourner plusieurs chemins calculés au sein du même message de réponse, correspondant soit à la même demande (par exemple, chemins multi usages, chemins d'un groupe de chemins d'équilibrage de charge) soit à des demandes distinctes, corrélées ou non, du même message de demande ou de messages de demande distincts.

Il DOIT être possible de fournir une "continuation de corrélation" où toutes les demandes ou chemins calculés en rapport ne peuvent pas tenir dans un seul message et sont portés dans une séquence de messages correlés.

Le PCE DOIT informer le PCC de ses capacités. Les tailles maximum de message acceptables et le nombre maximum de demandes par message pris en charge par un PCE PEUT former une partie de l'annonce de capacités de PCE [RFC4674] ou PEUT être échangé par des messages d'information du PCE au titre du protocole qu'on décrit ici.

Il DOIT être possible à un PCC de spécifier, dans le message de demande, les tailles maximum de message de réponse acceptables et le nombre maximum de chemins calculés par message de réponse qu'il peut prendre en charge.

Il DOIT être possible de limiter la taille de message par configuration sur les PCC et les PCE.

 	5.1.8	Échange fiable de messages
Le PCECP DOIT prendre en charge la transmission fiable des paquets PCECP. Ceci peut faire partie du protocole lui-même ou peut être réalisé par le choix d'un protocole de transport convenable (voir au paragraphe 5.1.3).

En particulier, cela DOIT permettre que la détection et la récupération des messages perdus se fasse rapidement et n'entrave pas le fonctionnement du PCECP.

Dans certains cas (par exemple, après une défaillance de liaison) un grand nombre de PCC peut envoyer simultanément des demandes à un PCE, conduisant à une potentielle saturation des PCE. Le PCECP DOIT prendre en charge l'indication d'état d'encombrement et d'état de limitation de débit. Ceci devrait permettre, par exemple, à un PCE de limiter le taux d'entrée de messages de demande si le taux de demandes est trop élevé.

Le PCECP ou son protocole de transport DOIT fournir :
- la détection et le rapport des messages perdus ou corrompus,
- la tentative automatique de retransmission des messages perdus sans référence à l'application,
- le traitement des messages en désordre,
- le traitement des messages dupliqués,
- le contrôle de flux pour permettre de diminuer le taux de demandes et réponses,
- la communication rapide de la détection de défaillance de PCECP,
- la distinction entre défaillance du partenaire et la défaillance du canal de communication après la récupération de la communication de PCECP.

Si il est nécessaire d'ajouter des fonctions au PCECP pour surmonter les insuffisances des mécanismes de transport choisis, ces fonctions DEVRAIENT se fonder sur les techniques développées dans d'autres protocoles, et les réutiliser lorsque possible pour surmonter les mêmes insuffisances. Une fonctionnalité NE DOIT PAS être ajoutée au PCECP lorsque le protocole de transport choisi la fournit déjà.

 	5.1.9	Échange de messages sécurisé
Le protocole de communication PCC-PCE DOIT inclure des dispositions pour assurer la sécurité des échanges entre les entités. En particulier, il DOIT prendre en charge des mécanismes pour empêcher l'usurpation d'identité (par exemple, l'authentification), l'espionnage (par exemple, la préservation de la confidentialité des informations par des techniques comme le chiffrement) et les attaques de déni de service (DoS) (par exemple, le filtrage de paquets, la limitation de débit, le blocage de l'écoute de promiscuité). Une fois qu'un PCC est identifié et authentifié, il a les mêmes privilèges que tous les autres PCC.

Pour assurer la confidentialité, le PCECP DEVRAIT permettre que la politique locale soit configurée sur le PCE à ne pas fournir de chemin explicite. Si un PCC demande un chemin explicite quand ce n'est pas permis, le PCE DOIT retourner un message d'erreur au PCC demandeur et la demande de calcul de chemin en cours DOIT être éliminée.

Les exigences d'autorisation de la [RFC3127] incluent la capacité de rejeter, la réautorisation à la demande, la prise en charge des règles et filtres d'accès, et la déconnexion non sollicitée.

Les adresses IP sont utilisées pour identifier les PCC et PCE. Lorsque la communication PCC-PCE a lieu entièrement dans un domaine limité, l'utilisation d'un espace d'adresses privé qui n'est pas disponible aux systèmes clients PEUT être utilisé pour aider à protéger l'échange d'informations, mais d'autres mécanismes DOIVENT aussi être disponibles.

Ces fonctions peuvent être fournies par le protocole de transport ou directement par le PCECP. Voir à la Section 6 la discussion sur les considérations de sécurité.

 	5.1.10	Priorité des demandes
Le PCECP DOIT permettre à un PCC de spécifier la priorité d'une demande de calcul.

La mise en œuvre d'une activité sur la base de sa priorité au sein d'un PCE est soumise à la politique de la mise en œuvre et locale. Ce traitement d'application sort du domaine d'application de PCECP.

 	5.1.11	Notifications non sollicitées
Le mode de fonctionnement normal est que le PCC fasse les demandes de calcul de chemin au PCE et que le PCE réponde.

Le PCECP DOIT prendre en charge les notifications non sollicitées du PCE au PCC, ou du PCC au PCE. Cette exigence facilite la communication non sollicitée des informations et alertes entre les PCC et les PCE. Comme spécifié au paragraphe 5.1.8, ces messages de notification doivent être pris en charge par un protocole de transmission fiable. Le PCECP PEUT aussi prendre en charge les messages de réponse aux messages de notification non sollicités.

 	5.1.12	Communication asynchrone
Le protocole PCC-PCE DOIT permettre une communication asynchrone. Un PCC NE DOIT PAS avoir à attendre une réponse à une demande avant de pouvoir faire une autre demande.

Il DOIT aussi être possible que l'ordre des réponses diffère de l'ordre des demandes correspondantes. Cela peut arriver, par exemple, quand les chemins des messages de demande ont des priorités différentes (voir l'exigence 5.1.10). Une exigence qui en découle est que les réponses de calcul de chemin DOIVENT inclure une corrélation directe à la demande associée.

 	5.1.13	Minimisation des frais généraux de communication
Les messages de demande et réponse DEVRAIENT être conçus de telle sorte que les frais généraux de communication soient minimisés. En particulier, les frais généraux par message DEVRAIT être minimisés, et le nombre d'octets échangés qui arrivent à une réponse de calcul DEVRAIT être minimisé. Les autres considérations sur la minimisation des frais généraux incluent ce qui suit :
-	le nombre de messages de fond utilisés par le protocole ou son protocole de transport pour garder en vie une session ou l'association entre le PCE et PCC,
-	le coût de traitement au PCE (ou PCC) associé aux messages de demande/réponse (distinct du traitement des demandes de calcul elles mêmes).

 	5.1.14	Extensibilité
Le PCECP DOIT fournir un moyen pour l'introduction de nouvelles contraintes de calcul de chemin, de divers types, de fonctions objectives, de méthodes et paramètres d'optimisation, et ainsi de suite, sans exiger de modifications majeures du protocole

Par exemple, le PCECP DOIT être extensible pour prendre en charge diverses applications fondées sur le PCE, comme :
- le calcul de chemin intra zone,
- le calcul de chemin inter zones [RFC4927],
- le calcul de chemin inter AS intra fournisseur et inter AS inter fournisseurs [RFC5376],
- le calcul de chemin inter couches [RFC6457].

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 permettre des extensions lorsque plus d'applications de PCE seront introduites à l'avenir.

Le PCECP DEVRAIT aussi être extensible pour prendre en charge de futures applications qui ne sont actuellement pas dans le mandat du groupe de travail PCE, comme par exemple, les calculs de chemins de point à multipoint, de pseudo-filaires multi bonds, etc.

Noter que les exigences spécifiques d'application sortent du domaine d'application de ce document et seront traitées dans des documents d'exigences distincts.

 	5.1.15	Adaptabilité
Le PCECP DOIT bien s'adapter, au moins aussi bien que de façon linéaire, à une augmentation de tout paramètre suivant. Les estimations d'ordre de grandeur minimum de ce que le PCECP devrait prendre en charge sont données entre parenthèses (noter que ce sont des exigences pour le PCECP, non pour le PCE) :
- nombre de PCC (1000/domaine)
- nombre de PCE (100/domaine)
- nombre de PCC communiquant avec un seul PCE (1000)
- nombre de PCE en communication avec un seul PCC (100)
- nombre de domaines (20)
- nombre de messages de demande de chemin (moyenne de 10/s/PCE)
- traitement de salves de demandes (salves de 100/s/PCE au sein d'un intervalle de 10 s).

Noter que les demandes de chemin peuvent être groupées dans des messages de demande de chemin, par exemple, 10 messages de demande de PCECP par seconde peuvent correspondre à 100 demandes de chemin par seconde.

Des salves de demandes peut se produire, par exemple, après une panne de réseau quand de nombreux recalculs sont demandés. Le PCECP DOIT traiter l'encombrement en douceur afin de ne pas impacter indûment le reste du réseau, et qu'il ne réduise pas la capacité du PCE à effectuer le calcul.

 	5.1.16	Contraintes
Ce paragraphe fait une liste des contraintes génériques qui DOIVENT être prises en charge par le PCECP. D'autres contraintes peuvent être ajoutées aux applications spécifiques de service identifiées par des documents distincts d'éxigences spécifiques d'application. Noter que les dispositions du paragraphe 5.1.14 signifient que de nouvelles contraintes peuvent être ajoutées à cette liste sans impacter le protocole à un niveau qui exige de changement majeur.

L'ensemble des contraintes génériques prises en charge DOIT inclure au moins :
o	contraintes génériques de MPLS-TE et GMPLS :
- bande passante
- inclusion/exclusion d'affinités
- inclusion/exclusion de liaison, nœud, groupe de liaisons à risque partagé (SRLG, Shared Risk Link Group)
- métrique IGP de bout en bout maximum
- compte de bonds maximum hop count
- métrique TE de bout en bout maximum
- degré de disjonction de chemins (liaison, nœud, SRLG)
o	contraintes spécifiques de MPLS-TE :
- type et classe
- protection locale
- protection de nœud
- protection de bande passante
o	contraintes spécifiques de GMPLS :
- type de commutation, type de codage
- type de protection de liaison

 	5.1.17	Fonctions objectives prises en charge
Ce paragraphe fait la liste des fonctions objectives génériques qui DOIVENT être prises en charge par le PCECP. D'autres fonctions objectives PEUVENT être ajoutées aux applications spécifiques de service identifiées par des documents séparés d'exigences spécifiques d'application. Noter que les dispositions du paragraphe 5.1.14 signifient que de nouvelles fonctions objectives PEUVENT être ajoutées à cette liste sans impacter le protocole.

Le PCECP DOIT prendre en charge au moins les fonctions "non synchronisées" suivantes :
- chemin de coût minimum par rapport à une métrique spécifiée (plus court chemin)
- chemin le moins chargé,
- chemin à la bande passante disponible maximum.

Aussi, le PCECP DOIT prendre en charge au moins les fonctions objectives "synchronisées" suivantes :
- minimiser la consommation de bande passante agrégée sur toutes les liaisons,
- maximiser la bande passante résiduelle sur les liaisons les plus chargées,
- minimiser le coût cumulatif d'un ensemble de chemins divers.

 	5.2.	Exigences de prise en charge de déploiement
 	5.2.1	Prise en charge de différents environnements de fournisseur de service
Le PCECP doit au moins prendre en charge les environnements suivants :
- réseaux MPLS-TE et GMPLS
- réseaux de paquets et non de paquets
- PCE centralisés et répartis
- PCE seul et PCE multiples.

Par exemple, PCECP est éventuellement applicable à des réseaux de paquets (par exemple, les réseaux IP) des réseaux non de paquets (par exemple, transport en multiplexage à répartition dans le temps (TDM)) et peut-être à des environnements de plan de contrôle GMPLS multi couches. Les définitions de PCE centralisé, réparti, seul, et multiples se trouvent dans la [RFC4655].

 	5.2.2	Prise en charge de politique
Le PCECP DOIT permettre l'utilisation de politiques qui acceptent/rejettent les demandes. Il DOIT inclure la capacité qu'un PCE fournissent des détails suffisants quand il rejette une demande pour des raisons de politique pour permettre au PCC de déterminer la raison du rejet ou de la défaillance. Par exemple, le filtrage pourrait être requis pour un PCE qui dessert un domaine (peut-être un AS) afin que toutes les demandes qui viennent d'un autre domaine (AS) soient rejetées. Cependant, les détails spécifiques de la politique sont du domaine des exigences de PCECP spécifiques d'application. Les politiques réelles, la configuration des politiques, et l'applicabilité des politiques sont hors domaine.

Noter que le groupe de travail PCE examine par ailleurs les modèles de prise en charge de politique et les exigences/implications correspondantes.

Les messages PCECP DOIVENT être capables de porter des informations de politique transparentes.

 	5.3	Détection de vivacité et exigence de récupération
 	5.3.1	Détection de vivacité
Le PCECP DOIT permettre à un PCC/PCE de
- vérifier la vivacité de la communication PCC-PCE,
- détecter rapidement la défaillance de communication PCC-PCE (défaillance de partenanire ou de connexité)
- distinguer les défaillances de nœud PCC/PCE des défaillances de connexité de PCC-PCE, après la récupération de la communication PCC-PCE.

Le mécanisme de détection de vivacité DOIT assurer une connaissance réciproque de la vivacité de PCE et de PCC.

 	5.3.2	Récupération du protocole
En cas de défaillance d'un envoyeur ou du canal de communication, le PCECP, à la récupération, DOIT prendre en charge la resynchronisation des informations (par exemple, état d'encombrement de PCE) et des demandes entre l'envoyeur et le receveur ; ceci DEVRAIT être arrangé de façon à minimiser les répétitions de transfert de données.

 	5.3.3	Réacheminement et réoptimisation de LSP
Si un LSP échoue à cause de la défaillance d'une liaison ou nœud qu'il traverse, une nouvelle demande de calcul peut être faite à un PCE afin de réparer le LSP. Comme le PCC ne peut pas savoir que la TED du PCE a été mise à jour pour refléter les informations de défaillance du réseau, il est utile d'inclure ces informations dans la nouvelle demande de calcul de chemin.

Aussi, afin de réutiliser les ressources utilisées par le vieux LSP, il peut être avantageux d'indiquer le chemin du vieux LSP au titre de la nouvelle demande de calcul de chemin.

Donc, le message de demande de calcul de chemin DOIT permettre l'indication de si le calcul est pour la restauration de LSP, et il DOIT prendre en charge l'inclusion du chemin calculé précédemment ainsi que l'identité de l'élément défaillant. Noter que le vieux chemin pourrait n'être utile que si le vieux LSP n'a pas été déjà supprimé. Le PCE PEUT choisir de prendre en compte les informations d'indication de défaillance portées dans une demande lors du traitement des demandes suivantes. Ceci devrait être gouverné par une décision de politique locale.

Noter qu'une défaillance du réseau peut impacter un grand nombre de LSP. Dans ce cas, un grand nombre potentiel de PCC vont envoyer simultanément des demandes au PCE. Le PCECP DOIT traiter correctement de telles situations de surcharge, comme par exemple, en réduisanr le débit des demandes comme indiqué au paragraphe 5.1.8.

Le message de demande de calcul de chemin DOIT prendre en charge la ré-optimisation de chemin de LSP TE et l'inclusion d'un chemin calculé précédemment. Cela va aider PCECP à assurer un acheminement optimal d'un chemin réoptimisé, car cela va permettre au PCE d'éviter une double prise en compte de la bande passante et aider à réduire les blocages.

 	6.	Considérations sur la sécurité

La gestion de clés DOIT être fournie par le PCECP pour assurer l'authenticité et l'intégrité des messages PCECP. Cela va permettre de protéger contre l'usurpation de PCE ou PCC et aussi contre la falsification du contenu de message.

L'impact de l'utilisation d'un PCECP DOIT être considéré à la lumière de l'impact qu'il a sur la sécurité des protocoles et techniques existants d'acheminement et de signalisation dans l'utilisation au sein du réseau. La sécurité intra-domaine est impactée car il y a une nouvelle interface, un nouveau protocole, et un nouvel élément dans le réseau. Tout hôte dans le réseau pourrait se faire passer pour un PCC et recevoir des informations détaillées sur les chemins du réseau. Tout hôte pourrait aussi se faire passer pour un PCE, collectant des informations sur le réseau avant de passer la demande à un PCE réel et capturant les réponses. Une certaine protection dépend ici de la sécurité du processus de découverte de PCE (voir la [RFC4674]). Un accroissement des flux d'informations inter-domaines peut augmenter la vulnérabilité aux attaques contre la sécurité, et faciliter les chemins inter-domaines peut augmenter l'impact de ces attaques.

Les implications sur la confidentialité inhérentes à un PCECP sont particulièrement sensibles pour les réseaux multi-domaines. Il n'est pas obligatoire qu'une solution de PCE multi-domaines compromette la sécurité, mais les solutions DOIVENT examiner leur impact dans ce domaine.

Les déclarations d'applicabilité pour des combinaisons particulières de techniques de signalisation, acheminement, et calcul de chemin sont supposées contenir des sections détaillées sur la sécurité.

Il devrait être observé que l'utilisation d'un PCE externe introduit des problèmes de sécurité supplémentaires. Les plus notables sont :
- l'interception de demandes ou réponses de PCE,
- l'usurpation d'identité de PCE ou PCC,
- les attaques de DoS sur les PCE ou PCC.

Le PCECP DOIT traiter ces questions en détail en utilisant les techniques d'authentification, de chiffrement, et de protection contre le déni de service. Voir aussi au paragraphe 5.1.9.

Il y a des implications pour la sécurité à permettre des fonctions objectives arbitraires, comme exposé au paragraphe 5.1.17, et le PCECP DOIT permettre d'atténuer le risque que, par exemple, un PCC utilise des objectifs complexes pour amener intentionnellement un PCE à épuiser ses ressources.

 	7.	Considérations de gestion

La gérabilité du PCECP DOIT viser les considérations suivantes :
-	Le besoin d'un module de MIB pour le contrôle et la surveillance du PCECP.
-	Le besoin d'un outil de diagnostic incorporé pour vérifier le fonctionnement du protocole (par exemple, détection de défaillance de partenaire, opérations d'administration et maintenance (OAM), etc.).
-	Les implications de configuration pour le protocole.

Les opérations de PCECP DOIVENT être modélisées et contrôlées par les modules de MIB appropriés. Il y a des différences assez spécifiques entre les PCC et les PCE pour qu'il soit besoin de définir des modules de MIB distincts. La collecte de statistiques va former une part importante des opérations du PCECP. Les modules de MIB DOIVENT fournir des informations qui permettent à un opérateur de déterminer l'historique des interactions de PCECP et le taux de succès des demandes. De même, il est important qu'un opérateur soit capable de déterminer la charge de PCECP et de PCE et si un PCC individuel est responsable d'une part disproportionnée de la charge. Il DOIT être possible, par l'usage des modules de MIB, d'enregistrer et inspecter les statistiques sur les communications de PCECP, incluant des problèmes comme des messages mal formés, des messages non autorisés, et des messages éliminés à cause d'encombrement.

Les nouveaux modules de MIB devraient aussi être utilisés pour fournir des notifications (traps) quand des seuils sont franchis ou quand des événements importants se produisent. Par exemple, le module de MIB peut prendre en charge l'indication du dépassement d'un seuil d'état d'encombrement ou d'état de limitation de débit.

Les techniques de PCECP doivent permettre à un PCC de déterminer la vivacité d'un PCE à la fois avant qu'il envoie une demande et dans la période entre l'envoi d'une demande et la réception de la réponse.

Il est aussi important qu'un PCE sache la vivacité des PCC pour avoir une vue prévisible de la charge à venir probable d'un PCE et de permettre à un PCE d'abandonner le traitement d'une demande reçue.

Le PCECP DOIT prendre en charge l'indication de l'état d'encombrement et de l'état de limitation de débit, et PEUT permettre à l'opérateur de contrôler une telle fonction.

 	8.	Contributeurs

Le présent document résulte des efforts conjoints de l'équipe de conception des exigences de PCECP du groupe de travail PCE. En plus des auteurs/éditeurs cités à la section "Adresse des auteurs", les membres de l'équipe de conception qui ont contribué au document sont :

Alia K. Atlas	Arthi Ayyangar	Nabil Bitar	
Google Inc.	Nuova Systems,	Verizon	
1600 Amphitheatre Parkway	2600 San Tomas Expressway	40 Sylvan Road	
Mountain View, CA  94043 USA	Santa Clara, CA 95051	Waltham, MA 02145 USA	
mél : akatlas@alum.mit.edu 	mél : arthi@nuovasystems.com 	mél : nabil.bitar@verizon.com 	

Igor Bryskin	Durga Gangisetti	Eiji Oki, NTT	
Independent Consultant	MCI	Midori-cho 3-9-11	
mél : i_bryskin@yahoo.com 	mél : durga.gangisetti@mci.com 	Musashino-shi, Tokyo 180-8585, JAPAN	
		mél : oki.eiji@lab.ntt.co.jp 	

Kenji Kumaki	Dean Cheng	Raymond Zhang	
KDDI Corporation	Cisco Systems, Inc.	BT INFONET Services Corporation	
Garden Air Tower	3700 Cisco Way	2160 E. Grand Ave.	
Iidabashi, Chiyoda-ku,	San Jose CA 95134 USA	El Segundo, CA 90245 USA	
Tokyo 102-8460, JAPAN	téléphone :  408 527 0677	mél : Raymond_zhang@bt.infonet.com 	
téléphone : 3-6678-3103	mél : dcheng@cisco.com 		
mél : ke-kumaki@kddi.com 			

 	9.	Remerciements

Les auteurs tiennent à témoigner de leur chaleureuse gratitude à (en ordre alphabétique) Lou Berger, Ross Callon, Adrian Farrel, Thomas Morin, Dimitri Papadimitriou, Robert Sparks, et J.P. Vasseur pour leur relecture et leurs suggestions.

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

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

 	10.2	Références pour information
[RFC3127]	D. Mitton et autres, "Authentification, autorisation et comptabilité : Évaluation de protocole", juin 2001. (Info.)

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

[RFC3785]	F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx et T. Telkamp, "Utilisation de la métrique du protocole de routeur intérieur (IGP) comme seconde métrique d'ingénierie du trafic MPLS", BCP 87, mai 2004.

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

[RFC4927]	J.-L. Le Roux, éd., "Exigences spécifiques du protocole de communication d'élément de calcul de chemin (PCECP) pour l'ingénierie du trafic inter zone MPLS et GMPLS", juin 2007. (Information)

[RFC5376]	N. Bitar et autres, "Exigences inter AS pour le protocole de communication d'élément de calcul de chemin (PCECP)", novembre 2008. (Information)

[RFC6457]	T. Takeda, A. Farrel, "Communication PCC-PCE et exigences de la découverte de PCE pour l’ingénierie du trafic inter couche", décembre 2011. (Information)

 	Adresse des auteurs

Jerry Ash (éditeur)	Jean-Louis Le Roux (éditeur)	
AT&T	France Telecom	
Room MT D5-2A01	2, avenue Pierre-Marzin	
200 Laurel Avenue	22307 Lannion Cedex,	
Middletown, NJ 07748, USA	FRANCE	
téléphone : (732)-420-4578	mél : jeanlouis.leroux@orange-ft.com 	
mél : gash@att.com 		

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

Remerciement
Le financement de la fonction d’édition des RFC est fourni par l’activité de soutien administratif (IASA) de l’IETF