Groupe de travail Réseau	JL. Le Roux, France Telecom
Request for Comments: 5541	JP. Vasseur, Cisco System Inc.
Catégorie : Sur la voie de la normalisation	Y. Lee, Huawei
Traduction Claude Brière de L'Isle	juin 2009

Codage des fonctions objectives dans le protocole de communication d'élément de calcul de chemin (PCEP)

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

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

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

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

Résumé
Le calcul d'un ou d'un ensemble de chemins de commutation d'étiquettes d'ingénierie du trafic (TE LSP, Traffic Engineering Label Switched Path) dans les réseaux de commutation d'étiquettes multi protocoles (MPLS, MultiProtocol Label Switching ) et MPLS généralisé (GMPLS, Generalized MPLS ) est soumis à un ensemble d'un ou plusieurs critères d'optimisation spécifiques, appelés des fonctions objectives (par exemple, chemin de coût minimum, plus grand chemin, etc.).

Dans l'architecture d'élément de calcul de chemin (PCE, Path Computation Element) un client de calcul de chemin (PCC, Path Computation Client) peut vouloir qu'un chemin soit calculé pour un ou plusieurs LSP TE conformément à une fonction objective spécifique. Donc, le PCC a besoin d'ordonner au PCE d'utiliser la fonction objective correcte. De plus, il est possible que tous les PCE ne prennent pas en charge le même ensemble de fonctions objectives ; donc, il est utile que le PCC soit capable de découvrir automatiquement l'ensemble de fonctions objectives prises en charge par chaque PCE.

Le présent document définit des extensions au protocole de communication de PCE (PCEP, PCE communication Protocol) pour permettre à un PCE d'indiquer l'ensemble de fonctions objectives qu'il prend en charge. Les extensions sont aussi définies de façon qu'un PCC puisse indiquer dans une demande de calcul de chemin la fonction objective requise, et qu'un PCE puisse rapporter dans une réponse de calcul de chemin la fonction objective qui a été utilisée pour le calcul de chemin.

Le présent document définit les types de code de fonction objective pour six fonctions objectives précédemment mentionnées dans le document sur les exigences pour PCE, et donne les définitions de quatre nouveaux types de métriques qui s'appliquent à un ensemble de demandes synchronisées.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans le document	3
1.2 Terminologie	3
1.3 Formats de message	3
2. Découverte des fonctions objectives de PCE	3
2.1 TLV OF-List	3
2.2 Éléments de procédure	4
3. Fonction objective dans les messages PCEP Demande et Réponse de calcul de chemin	4
3.1 Objet OF	4
3.2 Portage de l'objet OF dans un message PCEP	5
3.3 Nouveau fanion Objet RP	7
4. Définition des fonctions objectives	8
5. Nouveaux types de métriques	9
6. Considérations relatives à l'IANA	9
6.1 Sous registre de fonction objective PCE	9
6.2 Codets PCEP	10
7. Considérations sur la sécurité	11
8. Considérations sur la gestion	11
8.1 Contrôle de fonction et de politique	11
8.2 Modèles d'information et de données	11
8.3 Détection et surveillance de vie	11
8.4 Vérification de fonctionnement correct	11
8.5 Exigences sur les autres protocoles	11
9. Remerciements	11
10. Références	12
10.1 Références normatives	12
10.2 Références pour information	12
Appendice A. Fragments de code RBNF	12
Adresse des auteurs	14

 	1.	Introduction

L'architecture de réseau fondée sur l'élément de calcul de chemin [RFC4655] définit un élément de calcul de chemin (PCE, Path Computation Element) comme une entité capable de calculer les chemins de commutation d'étiquette avec ingénierie du trafic (TE LSP, Traffic Engineered Label Switched Path) sur la base d'un graphe de réseau et de l'application de contraintes de calcul. Un service de PCE demande des calculs de chemin qui sont envoyés par les clients de calcul de chemin (PCC, Path Computation Client).

Le protocole de  communication de PCE (PCEP, PCE communication Protocol) défini dans la [RFC5440], permet la communication entre un PCC et un PCE ou entre deux PCE, conformément aux exigences et lignes directrices établies dans la [RFC4657]. De telles interactions incluent des demandes et des réponses de calcul de chemin.

La calcul d'un ou d'un ensemble de TE LSP est soumis à un ensemble d'un ou plusieurs critères d'optimisation, appelé une fonction objective. Une fonction objective est utilisée par le PCE quand il calcule un chemin ou un ensemble de chemins afin de choisir les "meilleurs" chemins candidats. Il y a diverses fonctions objectives : une fonction objective pourrait s'appliquer à un ensemble de demandes non synchronisées de calcul de chemin, ou à un ensemble de demandes de calcul de chemin synchronisées. Dans le premier cas, la fonction objective se réfère à une demande individuelle de calcul de chemin (par exemple, calcul du plus court chemin avec contraintes où la métrique est IGP, calcul du chemin contraint le moins chargé, etc.). À l'inverse, dans le dernier cas, la fonction objective se réfère à un ensemble de demandes de calcul de chemin dont le calcul est synchronisé (par exemple, minimiser la consommation de bande passante agrégée de tous les LSP, minimiser la somme des délais pour deux chemins divers, ou la différence entre ces délais, etc.). De plus, certaines fonctions objectives se rapportent à l'optimisation d'une seule métrique et d'autres à l'optimisation d'un ensemble de métriques (organisées de manière hiérarchique, en utilisant une fonction de pondération, etc.).

Comme mentionné dans la [RFC4674], il peut être utile pour un PCC de découvrir l'ensemble de fonctions objectives supportées par un PCE. De plus, la [RFC4657] exige la capacité pour un PCC d'indiquer dans une demande de calcul de chemin une fonction objective exigée/désirée, ainsi que des paramètres de fonction facultatifs.

À cette fin, le présent document étend le protocole de communication de PCE (PCEP). Il définit des extensions à PCEP qui permettent à un PCE d'annoncer une liste de fonctions objectives prises en charge, ainsi que des extensions pour porter la fonction objective dans les messages de demande et réponse PCEP. Il complète la spécification de base de PCEP [RFC5440].

Noter que les mécanismes de découverte de PCE fondées sur OSPF et IS-IS sont définis dans les [RFC5088] et [RFC5089].  Ces mécanismes sont dédiés à la découverte de quelques paramètres génériques, alors que des paramètres de PCE plus détaillés devraient être découverts en utilisant le protocole de communication de PCE. Les fonctions objectives sont dans cette seconde catégorie ; donc, la procédure de découverte de fonction objective est traitée par PCEP.

Un nouveau TLV PCEP, nommé TLV OF-List, est défini à la Section 2. Le TLV OF-List est porté dans l'objet PCEP OPEN et permet à un PCE de faire la liste, durant la phase d'établissement de session PCEP, des fonctions objectives qu'il prend en charge.

Un nouvel objet PCEP, l'objet OF, est défini à la Section 3. L'objet OF est porté dans un message de demande de calcul de chemin (PCReq, Path Computation Request) pour indiquer la fonction objective exigée/désirée à appliquer par un PCE, ou dans un message de réponse de calcul de chemin (PCRep, Path Computation Reply) pour indiquer la fonction objective qui a été utilisée pour le calcul de chemin.

Six fonctions objectives obligatoires qui doivent être prises en charge par PCEP sont mentionnées dans la [RFC4657]. Le présent document donne une définition de ces six fonctions objectives obligatoires. Des fonctions objectives supplémentaires peuvent être définies dans d'autres documents. Noter que les fonctions objectives supplémentaires sont définies pour l'application d'optimisation concurrente globale (GCO, Global Concurrent Optimization) de PCE, dans la [RFC5557].

Le présent document fournit aussi la définition de quatre nouveaux types de métrique qui s'appliquent à un ensemble de demandes synchronisées.

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

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

OF (Objective Function) : fonction objective. Ensemble d'un ou plusieurs critères d'optimisation utilisés pour le calcul d'un seul chemin (par exemple, minimisation du coût du chemin) ou pour le calcul synchronisé d'un ensemble de chemins (par exemple, minimisation de la consommation de bande passante agrégée, etc.).

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 du réseau) qui est capable de calculer un chemin du réseau ou un chemin fondé sur un graphe de réseau et d'appliquer des contraintes de calcul.

PCEP (Path Computation Element communication Protocol) : protocole de communication d'élément de calcul de chemin.

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

 	1.3	Formats de message
Les formats de message dans ce document sont exprimés en utilisant le BNF réduit utilisé dans la [RFC5440] et défini dans la [RFC5511].

 	2.	Découverte des fonctions objectives de PCE

Cette section définit des extensions à PCEP (voir la [RFC5440]) afin de prendre en charge l'annonce des fonctions objectives prises en charge par un PCE.

Un nouveau TLV PCEP OF-List (Liste de Fonctions Objectives) est défini. Le TLV PCEP OF-List est porté dans un objet OPEN. De cette façon, durant la phase d'établissement de session PCEP, un PCE peut annoncer à un homologue PCEP la liste des fonctions objectives qu'il prend en charge.

 	2.1	TLV OF-List
Le TLV PCEP OF-List est facultatif. Il PEUT être porté dans un objet OPEN envoyé par un PCE dans un message Open à un homologue PCEP afin d'indiquer la liste des fonctions objectives prises en charge.

Le format du TLV OF-List est conforme au format de TLV PCEP défini dans la [RFC5440]. C'est-à-dire, le TLV est composé de deux octets pour le type, deux octets qui spécifient la longueur du TLV, et un champ Valeur. Le champ Longueur définit la longueur de la portion Valeur en octets. Le TLV est bourré à un alignement sur une limite de quatre octets, et le bourrage n'est pas inclus dans le champ Longueur (par exemple, une valeur de trois octets aurait une longueur de trois, mais la taille totale du TLV serait de huit octets).

Le TLV PCEP OF-List a le format suivant :

Type : 4
Longueur : N * 2 (où N est le nombre de fonctions objectives)
Valeur : liste de codets de deux octets de fonction objective, identifiant les fonctions objectives prises en charge par l'envoyeur du message Open.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Code OF n° 1        |      Code OF n° 2             |
+---------------+---------------+---------------+---------------+
//                                                             //
+---------------+---------------+---------------+---------------+
|           Code OF n° N        |       bourrage                |
+---------------+---------------+---------------+---------------+

Code OF (2 octets) : identifiant de codet de fonction objective. L'IANA gère le registre des codets "Fonction objective de PCE" (voir la Section 6).

 	2.2	Éléments de procédure
Un PCE PEUT inclure un TLV OF-List dans un objet OPEN dans un message Open envoyé à un homologue PCEP afin d'annoncer un ensemble d'une ou plusieurs fonctions objectives. Le TLV OF-List NE DOIT PAS apparaître plus d'une fois dans un objet OPEN. Si il apparaît plus d'une fois, la session PCEP DOIT être rejetée avec le type d'erreur 1 et la valeur d'erreur 1 (défaillance d'établissement de session PCEP / réception d'un message Open invalide). L'absence du TLV OF-List dans un objet OPEN DOIT être interprétée comme une absence d'informations sur la liste des fonctions objectives prises en charge par le PCE.

Comme spécifié dans la [RFC5440], un homologue PCEP qui ne reconnaît pas le TLV OF-List va l'ignorer en silence.

 	3.	Fonction objective dans les messages PCEP Demande et Réponse de calcul de chemin

Cette section définit des extensions à PCEP [RFC5440] afin de prendre en charge la communication de fonctions objectives dans les messages de demande et de réponse de calcul de chemin de PCEP. Un nouvel objet PCEP OF (Objective Function) est défini, pour être porté dans un message PCReq afin que le PCC indique la fonction objective requise/désirée.

L'objet PCEP OF peut aussi être porté dans un message PCRep afin que le PCE indique la fonction objective qui a été utilisée par le PCE.

Un nouveau fanion est défini dans l'objet RP (Request Parameters, paramètres de la demande). Le fanion est utilisé dans un message PCReq pour indiquer que le PCE DOIT inclure un objet OF dans le message PCRep pour indiquer la fonction objective utilisée durant le calcul de chemin.

Aussi, de nouveaux types et valeurs d'erreur PCEP sont définis.

 	3.1	Objet OF
L'objet PCEP OF (fonction objective) est facultatif. Il PEUT être porté dans un message PCReq pour indiquer la fonction objective désirée/requise à appliquer par le PCE durant le calcul de chemin ou dans un message PCRep pour indiquer la fonction objective qui a été utilisée par le PCE durant le calcul de chemin.

Le format de l'objet OF est conforme au format d'objet PCEP défini dans la [RFC5440].
La classe de l'objet OF est 21.
Le type de l'objet OF est 1.
Le format du corps de l'objet OF est :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Code OF                      |      Réservé                  |
+---------------+---------------+---------------+---------------+
|                                                               |
//              TLV facultatifs                                //
|                                                               |
+---------------+---------------+---------------+---------------+

Code OF (2 octets) : identifiant de la fonction objective. L'IANA gère le registre des codets "Fonction objective de PCE" (voir la Section 6).

Réservé (2 octets) : ce champ DOIT être réglé à zéro à l'émission et DOIT être ignoré à réception.

Des TLV facultatifs peuvent êtres définis à l'avenir afin de coder des paramètres de fonction objective.

 	3.1.1	Éléments de procédure
Pour demander l'utilisation d'une fonction objective spécifique par le PCE, un PCC inclut un objet OF dans le message PCReq.

La [RFC5440] spécifie un bit fanion, appelé le bit P, porté dans l'en-tête commun d'objet PCEP. Le bit P est établi par un PCC pour obliger le PCE à prendre en compte les informations portées dans l'objet durant le calcul de chemin.

Si le bit P est établi dans l'objet OF, la fonction objective est obligatoire (fonction objective exigée) et le PCE DOIT utiliser la fonction objective durant le calcul de chemin. Si le bit P est à zéro dans l'objet OF, la fonction objective est facultative (fonction objective désirée) et le PCE DEVRAIT appliquer la fonction si elle est prise en charge mais PEUT choisir d'appliquer une fonction objective différente, selon les capacités et politiques locales.

À réception d'un message PCReq avec un objet OF, un PCE DOIT procéder comme suit :

-	Si l'objet OF est inconnu/non pris en charge, le PCE DOIT suivre les procédures définies dans la [RFC5440]. C'est-à-dire, si le bit P est établi, le PCE envoie un message PCErr avec le type d'erreur 3 ou 4 (objet inconnu/non pris en charge) et la valeur d'erreur 1 ou 2 (classe/type d'objet inconnu/non pris en charge) et la demande de calcul de chemin qui s'y rapporte DOIT être éliminée. Si le bit P est à zéro, le PCE est libre d'ignorer l'objet.

-	Si la fonction objective est inconnue/non prise en charge et si le bit P est établi, le PCE DOIT envoyer un message PCErr avec le type d'erreur 3 ou 4 (objet inconnu/non pris en charge) et la valeur d'erreur 4 (paramètre inconnu/non pris en charge) et la demande de calcul de chemin qui s'y rapporte DOIT être éliminée.

-	Si la fonction objective est inconnue/non prise en charge et si le bit P est cà zéro, le PCE DEVRAIT appliquer une autre fonction objective (par défaut).

-	Si la fonction objective est prise en charge mais si la politique ne permet pas de l'appliquer et si le bit P est établi, le PCE DOIT envoyer un message PCErr avec le type d'erreur PCEP "violation de politique" (type 5) et une nouvelle valeur d'erreur, "fonction objective interdite", qui est définie dans le présent document.

-	Si la fonction objective est prise en charge mais si la politique ne permet pas de l'appliquer et si le bit P est à zéro, le PCE DEVRAIT appliquer une autre fonction objective (par défaut).

-	Si la fonction objective est prise en charge et si la politique permet de l'appliquer et si le bit P est établi, le PCE DOIT appliquer la fonction objective demandée. Autrement, si le bit P est à zéro, le PCE est libre d'appliquer toute autre fonction objective.

La fonction objective par défaut peut être configurée en local.

 	3.2	Portage de l'objet OF dans un message PCEP
L'objet OF PEUT être porté dans un message PCReq. Si une fonction objective est à appliquer à un ensemble de demandes de calcul de chemin synchronisées, l'objet OF DOIT être porté juste après l'objet SVEC (Synchronization VECtor) correspondant et NE DOIT PAS être répété pour chaque demande élémentaire.

De même, si une métrique est à appliquer à un ensemble de demandes synchronisées, l'objet METRIC DOIT suivre l'objet SVEC et NE DOIT PAS être répété pour chaque demande élémentaire. Noter que les métriques appliquées à un ensemble de demandes synchronisées sont définies à la Section 5.

Un objet OF spécifiant une fonction objective qui s'applique à une demande individuelle de calcul de chemin (cas non synchronisé) DOIT suivre l'objet RP pour lequel il s'applique.

Le format du message PCReq est mis à jour comme suit. Voir à l'Appendice A un ensemble complet de fragments RBNF défini dans le présent document et la licence de code nécessaire.

<PCReq Message> ::= <En-tête commun> [<svec-list>] <request-list>
où :
   <svec-list> ::= <SVEC>
                        [<OF>]
                        [<metric-list>]
                        [<svec-list>]

   <request-list> ::= <request> [<request-list>]

   <request> ::= <RP>
                      <END-POINTS>
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<OF>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

et où :

<metric-list> ::= <METRIC>[<metric-list>]

L'objet OF PEUT être porté dans un message PCRep pour indiquer la fonction objective utilisée par le PCE durant le calcul de chemin.

Quand le PCE veut indiquer au PCC la fonction objective qui a été utilisée pour le calcul synchronisé d'un ensemble de chemins, le message PCRep DOIT inclure l'objet SVEC correspondant directement suivi de l'objet OF, qui NE DOIT PAS être répété pour chaque demande élémentaire. Si une métrique est applicable à l'ensemble de chemins, l'objet METRIC DOIT suivre directement l'objet SVEC et NE DOIT PAS être répété pour chaque demande élémentaire.

Un objet OF spécifiant une fonction objective utilisée pour un calcul de chemin individuel (cas non synchronisé) DOIT suivre l'objet RP pour lequel il s'applique.

Le format du message PCRep est mis à jour comme suit. Voir à l'Appendice A un ensemble complet de fragmens RBNF défini dans le présent document et la licence de code nécessaire.

<Message PCRep> ::= <En-tête commun> [<svec-list>] <response-list>

où :

    <svec-list> ::= <SVEC>
                         [<OF>]
                         [<metric-list>]
                         [<svec-list>]

   <response-list> ::= <response> [<response-list>]

   <response> ::= <RP>
                       [<NO-PATH>]
                       [<attribute-list>]
                       [<chemin-list>]

   <path-list> ::= <path> [<path-list>]

   <path> ::= <ERO> <attribute-list>

et où :

   <attribute-list> ::= [<OF>]
                            [<LSPA>]
                             [<BANDWIDTH>]
                             [<metric-list>]
                             [<IRO>]

   <metric-list> ::= <METRIC> [<metric-list>]

Note : L'objet OF PEUT être associé à une réponse négative, c'est-à-dire, une réponse avec un objet NO-PATH.

 	3.3	Nouveau fanion Objet RP
Dans certains cas, où aucune fonction objective n'est spécifiée dans la demande ou où une fonction objective facultative est désirée (fanion P à zéro dans l'en-tête commun de l'objet OF) mais où le PCE ne suit pas la demande, le PCC peut désirer connaître la fonction objective qui a été utilisée par le PCE durant le calcul de chemin. À cette fin, un nouveau fanion est défini dans l'objet RP, nommé fanion OF, qui permet à un PCC de demander l'inclusion dans la réponse de calcul de chemin de la fonction objective qui a été utilisée par le PCE durant le calcul de chemin.

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

Le fanion "Fournir OF en réponse" (numéro de bit 24). Quand il est établi dans un message PCReq, cela indique que le PCE DOIT fournir la fonction objective appliquée (si un chemin satisfaisant les contraintes a été trouvé) dans le message PCRep. Quand il est établi dans un message PCRep, cela indique que la fonction objective utilisée durant le calcul de chemin est incluse.

 	3.3.1	Éléments de procédure
Si le PCC veut connaître la fonction objective utilisée par le PCE durant le calcul de chemin pour une certaine demande, il établit le fanion OF dans l'objet RP.

À réception d'un message PCReq avec le fanion OF établi dans l'objet RP, le PCE procède comme suit :

-	Si la politique le permet, il DOIT inclure dans le message PCRep un objet OF indiquant la fonction objective utilisée durant le calcul de chemin.

-	Si la politique ne le permet pas, il DOIT envoyer un message PCErr avec le code d'erreur PCEP "violation de politique" (type 5) et une nouvelle valeur d'erreur, "indication de fonction objective interdite", qui est définie dans ce document.

Noter qu'un PCE traditionnel pourrait ne pas reconnaître le fanion OF dans l'objet RP. Conformément à la définition du champ Fanions pour l'objet RP (paragraphe 7.4.1 de la [RFC5440]) le PCE traditionnel va ignorer le fanion inconnu, ce qui va faire qu'il va envoyer une PCRep ne contenant pas d'objet OF. Dans ce cas, le comportement du PCC est un choix de la mise en œuvre. Le PCC pourrait :
-	Éliminer la PCRep parce que il voulait réellement que l'objet OF soit retourné.
-	Accepter la PCRep sans connaître la OF qui a été appliquée.

Noter aussi que ces procédures peuvent donner naissance à une situation où un PCC reçoit une PCRep qui contient un objet OF avec un identifiant de fonction objective que le PCC ne reconnaît pas. Dans cette situation, le comportement du PCC va dépendre de la mise en œuvre et de la configuration. Le PCC pourrait choisir une des actions suivantes (ou une autre) :
-	Ignorer l'objet OF et utiliser le chemin calculé.
-	Ajouter la fonction objective à sa vue du répertoire du PCE pour l'inclure dans de futures demandes de calcul.
-	Éliminer la PCRep (c'est-à-dire, le chemin calculé) et envoyer une PCReq à un autre PCE.
-	Éliminer la PCRep (c'est-à-dire, le chemin calculé) et envoyer une autre PCReq au même PCE demandant explicitement l'utilisation d'une autre fonction objective (c'est-à-dire, en établissant le bit P dans l'objet OF).

 	4.	Définition des fonctions objectives

Six fonctions objectives qui doivent être prises en charge par PCEP sont mentionnées dans la [RFC4657]. Les codes de fonction objective ont été alloués par l'IANA et sont décrits ci-dessous.

Les fonctions objectives sont formulées en utilisant la terminologie suivante :
-	Un réseau comporte un ensemble de N liaisons {Li, (i=1...N)}.
-	Un chemin P est une liste de K liaisons {Lpi,(i=1...K)}.
-	La métrique de la liaison L est notée M(L). Cela peut être la métrique IGP, la métrique TE, ou toute autre métrique.
-	Le coût d'un chemin P est noté C(P), où C(P) = somme de {M(Lpi), (i=1...K)}.
-	La bande passante résiduelle sur la liaison L est notée r(L).
-	La bande passante maximum réservable sur la liaison L est notée R(L).

Il y a trois fonctions objectives qui s'appliquent au calcul d'un seul chemin :

Code de fonction objective : 1
Nom : Minimum Cost Path (MCP) (chemin de coût minimum)
Description : trouve un chemin P tel que C(P) soit minimisé.

Code de fonction objective : 2
Nom : Minimum Load Path (MLP) (chemin de charge minimum)
Description : trouve un chemin P tel que ( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) soit minimisé.

Code de fonction objective : 3
Nom : Maximum residual Bandwidth Path (MBP) (chemin de bande passante résiduelle maximale)
Description : trouve un chemin P tel que ( Min { r(Lpi), i=1...K } ) soit maximisé.

Il y a trois fonctions objectives qui s'appliquent à un ensemble de demandes de calcul de chemin dont le calcul est synchronisé :

Code de fonction objective : 4
Nom : Minimize aggregate Bandwidth Consumption (MBC) (minimise la consommation de bande passante agrégée)
Description : trouve un ensemble de chemins tel que ( Somme de {R(Li) - r(Li), i=1...N} ) soit minimisée.

Code de fonction objective : 5
Nom : Minimize the Load of the most loaded Link (MLL) (minimise la charge sur la liaison la plus chargée)
Description : trouve un ensemble de chemins tel que ( Max { (R(Li) - r(Li)) / R(Li), i=1...N}) soit minimisé.

Code de fonction objective : 6
Nom : Minimize the Cumulative Cost of a set of paths (MCC) (minimise le coût cumilé sur un ensemble de chemins)
Description : trouve un ensemble de chemins {P1...Pm} tel que (Somme de { C(Pi), i=1...m}) soit minimisée.

D'autres fonctions objectives pourront être définies dans d'autres documents.

 	5.	Nouveaux types de métriques

Trois types de métrique sont définis dans PCEP pour l'objet METRIC : métrique TE, métrique IGP, et compte de bonds. Ces types de métrique s'appliquent à une demande individuelle. On définit ici quatre nouveaux types de métrique qui s'appliquent à un ensemble de demandes synchronisées :
Type 4 : consommation de bande passante agrégée.
Type 5 : charge de la liaison la plus chargée.
Type 6 : coût IGP cumulé.
Type 7 : coût TE cumulé.

Ces métriques peuvent être utilisées dans une PCReq pour indiquer une limite (bit B établi dans l'objet METRIC) ou pour demander le calcul d'une métrique (bit C établi dans l'objet METRIC) ou dans une PCRep pour indiquer une métrique calculée.

Un objet METRIC avec un de ces quatre types suit l'objet SVEC pour lequel il s'applique.

 	6.	Considérations relatives à l'IANA
 	6.1	Sous registre de fonction objective de PCE
Le présent document définit un identifiant de 16 bits de fonction objective de PCE à porter dans l'objet OF PCEP, et aussi définit le TLV PCEP OF-List.

L'IANA a créé et gère maintenant le registre des codets de 16 bits "Fonctions objective de PCE" en commençant à 1 et jusqu'à 32767, comme suit :
-	valeur de codet de fonction objective
-	nom de fonction objective
-	RFC de définition

Le même registre est applicable à l'objet OF et aux TLV OF-List qui sont défini dans ce document.
Les lignes directrices (en utilisant les termes définis dans la [RFC5226]) pour l'allocation des valeurs de codets de fonction objective sont les suivantes :
- La valeur du code de fonction 0 est réservée.
- Les valeurs de code de fonction dans la gamme de 1 à 32767 sont allouées comme suit :
o Les valeurs de code de fonction 1 à 1023 sont allouées par l'IANA suivant la politique de "revue de l'IETF".
o Les valeurs de code de fonction 1024 à 32767 sont allouées par l'IANA suivant la politique de "premier arrivé, premier servi".
o Les valeurs de code de fonction dans la gamme 32768 à 65535 sont pour "utilisation privée".

Six fonctions objectives sont définies à la Section 4 de ce document et ont été allouées par l'IANA:

Codet	Nom	Référence
1	MCP	RFC 5541
2	MLP	RFC 5541
3	MBP	RFC 5541
4	MBC	RFC 5541
5	MLL	RFC 5541
6	MCC	RFC 5541

 	6.2	Codets PCEP
 	6.2.1	Objet OF
L'IANA gère le registre des codets d'objet PCEP (voir la [RFC5440]). Ceci est tenu comme sous registre "Objets PCEP" du registre des "Numéros du protocole d'élément de calcul de chemin (PCEP)".

Le présent document définit un nouvel objet PCEP, l'objet OF, à porter dans les messages PCReq et PCRep. L'IANA a fait l'allocation suivante :

Classe d'objet	Nom	Type d'objet	Nom	Référence
       21	OF	1	Objective Function	RFC 5541

 	6.2.2	TLV OF-List
L'IANA gère le registre des codets de TLV PCEP (voir la [RFC5440]). Ceci est tenu comme sous registre des "Indicateurs de type de TLV PCEP" du registre des "Numéros du protocole d'élément de calcul de chemin (PCEP)".

Le présent document définit un nouveau TLV PCEP, le TLV OF-List, à porter dans l'objet OPEN. L'IANA a fait l'allocation suivante :

Type	Nom de TLV	Référence
    4	OF-List	RFC 5541

 	6.2.3	Valeurs d'erreur PCEP
L'IANA tient un registre des types d'erreur et des valeurs d'erreur à utiliser dans les messages PCEP. Ceci est tenu comme sous registre "Types et valeurs d'erreur d'objet PCEP-ERROR" du registre des "Numéros du protocole d'élément de calcul de chemin (PCEP)".

Deux nouvelles valeurs d'erreur sont définies pour le type d'erreur "violation de politique" (type 5) :

Type d'erreur	Signification de valeurs d'erreur	Référence
         5 	Violation de politique
	valeur d'erreur =3 : fonction objective interdite (demande rejetée)	RFC 5541
	valeur d'erreur =4 : bit OF de l'objet RP établi (demande rejetée) 	RFC 5541

 	6.2.4	Fanion Objet RP
Un nouveau fanion de l'objet RP (spécifié dans la [RFC5440]) est défini dans ce document. L'IANA tient un registre des fanion d'objet RP dans le sous registre "Champ de fanions d'objet RP" du registre des "Numéros du protocole d'élément de calcul de chemin (PCEP)".

L'IANA a fait l'allocation suivante :

Bit	Description	Référence
24	Fournir OF en réponse	RFC 5541

 	6.2.5	Types de métriques
Quatre nouveaux types de métrique sont définis dans ce document pour l'objet METRIC (spécifié dans la [RFC5440]).  L'IANA tient un registre des types de métrique dans le sous registre "Champ T d'objet METRIC" du registre des "Numéros du protocole d'élément de calcul de chemin (PCEP)".

L'IANA a fait les allocations suivantes :
- Type 4 : consommation de bande passante agrégée
- Type 5 : charge de la liaison la plus chargée
- Type 6 : coût IGP cumulé
- Type 7 : coût TE cumulé

 	7.	Considérations sur la sécurité

Les mécanismes de sécurité de PCEP sont décrits dans la [RFC5440] et sont utilisés pour sécuriser des messages PCEP entiers. Rien dans le présent document ne change les flux de messages ou n'introduit de nouveau message, donc les mécanismes de sécurité établis dans la [RFC5440] continuent d'être applicables.

Le présent document introduit un seul nouvel objet qui peut facultativement être porté dans les messages PCEP et va être automatiquement sécurisé en utilisant les mécanismes décrits dans la [RFC5440].

Si un message PCEP est vulnérable à des attaques (par exemple, parce que les mécanismes de sécurité ne sont pas utilisés) l'objet OF pourrait alors être utilisé au titre d'une attaque ; cependant, il est probable que d'autres objets vont fournir des moyens bien plus significatifs d'attaquer un PCE ou PCC dans ce cas.

 	8.	Considérations sur la gestion
 	8.1	Contrôle de fonction et de politique
Il DOIT être possible de configurer l'activation/désactivation de la découverte de fonction objective dans PCEP.

En plus des paramètres déjà cités au paragraphe 8.1 de la [RFC5440], une mise en œuvre de PCEP DEVRAIT permettre de configurer une liste des fonctions objectives autorisées sur un PCE. Cela peut s'appliquer à toute session à laquelle le locuteur PCEP participe, à une session spécifique avec un homologue PCEP donné, ou à un groupe spécifique de sessions avec un groupe spécifique d'homologues PCEP.

Noter qu'il n'est pas obligatoire qu'une mise en œuvre prenne en charge toutes les fonctions objectives définies à la Section  4.

Il DOIT être possible de configurer une fonction objective par défaut utilisée pour le calcul de chemin quand une demande de chemin est reçue qui demande d'utiliser une fonction objective facultative.

 	8.2	Modèles d'information et de données
Le module de MIB PCEP défini dans la [RFC7420] pourrait être étendu pour inclure les fonctions objectives.

 	8.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 de surveillance de vie en plus de celles déjà citées dans la [RFC5440].

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

 	8.5	Exigences sur les autres protocoles
Les mécanismes définis dans le présent document n'impliquent aucune exigence sur d'autres protocoles en plus de celles déjà citées dans la [RFC5440].

 	8.6	Impact sur le fonctionnement du réseau
Les mécanismes définis dans le présent document n'ont aucun impact sur le fonctionnement du réseau en plus de ceux déjà cités dans la [RFC5440].
 	9.	Remerciements

Les auteurs tiennent à remercier Jerry Ash, Fabien Verhaeghe, Robert Sparks, et Adrian Farrel de leurs utiles commentaires.

 	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. (MàJ par RFC8174)

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

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

 	10.2	Références pour information

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

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

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

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

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

[RFC5557]	Y. Lee, JL. Le Roux, D. King, E. Oki, "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", juillet 2009. (P.S.)

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

 	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>

   <PCRep Message> ::= <Common Header>
                       [<svec-list>]
                       <response-list>

       <svec-list> ::= <SVEC>
                       [<OF>]
                       [<metric-list>]
                       [<svec-list>]

       <request-list> ::= <request> [<request-list>]

       <request> ::= <RP>
                     <END-POINTS>
                     [<LSPA>]
                     [<BANDWIDTH>]
                     [<metric-list>]
                     [<OF>]
                     [<RRO>[<BANDWIDTH>]]
                     [<IRO>]
                     [<LOAD-BALANCING>]

       <metric-list> ::= <METRIC>[<metric-list>]

       <response-list> ::= <response> [<response-list>]

       <response> ::= <RP>
                      [<NO-PATH>]
                      [<attribute-list>]
                      [<path-list>]

       <path-list> ::= <path> [<path-list>]

       <path> ::= <ERO>
                  <attribute-list>

       <attribute-list> ::= [<OF>]
                            [<LSPA>]
                            [<BANDWIDTH>]
                            [<metric-list>]
                            [<IRO>]

 	Adresse des auteurs

JL Le Roux	Jean-Philippe Vasseur	Young Lee	
France Telecom	Cisco Systems, Inc	Huawei Technologies, LTD.	
2, Avenue Pierre-Marzin	11, Rue Camille Desmoulins	1700 Alma Drive, Suite 100	
Lannion  22307	L'Atlantis	Plano, TX  75075	
France	92782 Issy Les Moulineaux	USA	
mél : jeanlouis.leroux@orange-ftgroup.com	France	mél : ylee@huawei.com	
	mél : jpv@cisco.com