Groupe de travail Réseau	A. Farrel, Old Dog Consulting	
Request for Comments : 4655	J.-P. Vasseur, Cisco Systems, Inc.	
Catégorie : Information	J. Ash, AT&T	
Traduction Claude Brière de L'Isle	août 2006	

Architecture fondée sur l'élément de calcul de chemin (PCE)

Statut de ce mémoire
Le présent mémoire donne des informations destinées à 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 calcul de chemin sur des bases obligées est un bloc de construction fondamental pour les systèmes d'ingénierie du trafic tels que les réseaux à commutation en environnement multi protocoles avec étiquetage des flux (MPLS, Multiprotocol Label Switching) et à commutation multi protocoles avec étiquetage des flux généralisée (GMPLS, Generalized Multiprotocol Label Switching). Le calcul de chemin dans les grands réseaux, multi-domaines, multi-régions, ou multi-couches est complexe et peut exiger des composants de calcul particuliers et la coopération des différents domaines du réseau.

Le présent document spécifie l'architecture d'un modèle fondé sur un élément de calcul de chemin (PCE, Path Computation Element) pour traiter cet espace de problème. Le présent document ne cherche pas à fournir une description détaillée de tous les composants architecturaux, mais il décrit plutôt un ensemble de blocs de construction pour l'architecture de PCE à partir duquel des solutions peuvent être construites.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Définitions	3
4. Motifs d'une architecture fondée sur le PCE	4
4.1 Calcul de chemin coûteux en CPU	4
4.2 Visibilité partielle	4
4.3 Absence de la TED ou utilisation d'ICP sans capacité TE	5
4.4 Nœud en dehors du domaine d'acheminement	5
4.5 Élément de réseau sans capacité de plan de contrôle ou d'acheminement	5
4.6 Calcul de chemin de sauvegarde pour la protection de la bande passante	5
4.7 Réseaux multi couches	5
4.8 Politique de choix de chemin	6
4.9 Non motivations	6
5 Vue d'ensemble de l'architecture fondée sur le PCE	6
5.1 Nœud PCE composite	7
5.2 PCE externe	7
5.3 Calcul de chemin à plusieurs PCE	8
5.4 Calcul de chemin à plusieurs PCE avec communication inter PCE	8
5.5 Usage de PCE fondé sur la gestion	9
5.6 Secteurs à normaliser	9
6. Considérations sur l'architecture de PCE	9
6.1 Modèle de calcul centralisé	10
6.2 Modèle de calcul réparti	10
6.3 Synchronisation	10
6.4 Découverte de PCE et équilibrage de charge	11
6.5 Détection de PCE en vie	12
6.6 Communication PCC-PCE et PCE-PCE 	12
6.7 Synchronisation entre PCE et TED	13
6.8 PCE à états pleins ou sans état	13
6.9 Surveillance	14
6.10 Confidentialité	14
6.11 Politique	15
6.12 Interactions indésirables	17
6.13 Relations avec le retour de manivelle (Crankback)	17
7. Point de vue du client de calcul de chemin	17
8. Métriques d'évaluation	18
9. Considérations sur la gestion	19
9.1 Contrôle de fonction et politique	19
9.2 Modèles d'informations et de données	19
9.3 Détection et surveillance de vivacité	20
9.4 Vérification de fonctionnement correct	20
9.5 Exigences sur les autres protocoles et composants fonctionnels	20
9.6 Impact sur le fonctionnement du réseau	20
9.7 Autres considérations	21
10. Considérations pour la sécurité	21
11. Remerciements	21
12. Références pour information	21
Adresse des auteurs	22
Déclaration complète de droits de reproduction	22
 	1.	Introduction

Le calcul de chemin fondé sur la contrainte est un des blocs de construction fondamentaux de l'ingénierie du trafic dans les réseaux MPLS [RFC3209] et GMPLS [RFC3473]. La [RFC2702] décrit les exigences pour l'ingénierie du trafic dans les réseaux MPLS, tandis que les [RFC4105] et [RFC4216] décrivent respectivement les exigences d'ingénierie du trafic dans les environnements d'inter zone et d'inter AS.

Le calcul de chemin dans les grands réseaux multi domaines est complexe et peut exiger des composants de calcul spéciaux et la coopération entre les éléments de différents domaines. Le présent document spécifie l'architecture pour qu'un modèle fondé sur l'élément de calcul de chemin (PCE, Path Computation Element) traite cet espace de problème.

Le présent document décrit un ensemble de blocs de construction pour l'architecture de PCE à partir duquel des solutions peuvent être élaborées. Par exemple, il discute des mises en œuvre fondées sur le PCE qui incluent des calculs de chemin de PCE composites, externes, et multiples. De plus, il discute les considérations architecturales qui incluent le calcul centralisé, le calcul réparti, la synchronisation, la découverte de PCE et l'équilibrage de charge, la détection de la vivacité de PCE, la communication entre les clients de calcul de chemin (PCC, Path Computation Client) et le PCE (communication de PCC à PCE) et la communication de PCE à PCE, la synchronisation des bases de données d'ingénierie du trafic (TED, Traffic Engineering Database) les PCE à états pleins et sans état, la surveillance, la politique et la confidentialité, et les métriques d'évaluation.

Le modèle de l'Internet est de répartir la fonction de réseau (par exemple, l'acheminement) au sein du réseau. La fonction de PCE n'est pas destinée à contredire ce modèle et peut être utilisée pour correspondre exactement au modèle, par exemple, quand la fonction de PCE coexiste avec chaque routeur de commutation d'étiquettes (LSR, Label Switching Router) dans le réseau. Le PCE est aussi capable d'augmenter la fonctionnalité dans le réseau lorsque le modèle de l'Internet ne peut pas fournir de solutions adéquates, par exemple, lorsque des informations d'ingénierie du trafic ne sont pas échangées entre les domaines du réseau.

 	2.	Terminologie

CSPF (Constraint-based Shortest Path First) :  chemin le plus court en premier obligé

LER (Label Edge Router) :  routeur périphérique d’étiquettes

LSDB (Link State Database) : base de données d’état de liaison

LSP (Label Switched Path) : chemin commuté par étiquettes

LSP TE (Traffic Engineering MPLS Label Switched Path) : chemin commuté par étiquettes entre protocoles multiples avec ingénierie du trafic

LSR (Label Switching Router) : routeur à commutation d’étiquettes

PCC (Path Computation Client) : client de calcul de chemin. Toute application cliente qui demande qu'un calcul de chemin soit effectué par l'é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 ou route de réseau sur la base d'un graphe de réseau et d'appliquer des contraintes de calcul (voir la description plus détaillée de la Section 3).

TED (Traffic Engineering Database) base de données d'ingénierie du trafic, qui contient les informations de topologie et de  ressources du domaine. La TED peut être alimentée par des extensions au protocole de routeur intérieur (IGP, Interior Gateway Protocol) ou potentiellement par d'autres moyens.

 	3.	Définitions

Un élément de calcul de chemin (PCE) est une entité qui est capable de calculer un chemin ou route du réseau sur la base d'un graphe de réseau, et d'appliquer des contraintes de calcul durant ce calcul. L'entité PCE est une application qui peut être localisée au sein d'un nœud de réseau ou composant, sur un serveur hors du réseau, etc. Par exemple, un PCE pourrait être capable de calculer le chemin d'un LSP TE en opérant sur la TED et en prenant en considération la bande passante et autres contraintes applicables à la demande de service de LSP TE.

Un domaine est toute collection d'éléments de réseau au sein d'une sphère commune de responsabilité de gestion d'adresses ou de calcul de chemin. Des exemples de domaines incluent des zones d'IGP, des systèmes autonomes (AS, Autonomous System), et plusieurs AS au sein du réseau d'un fournisseur d'accès. Les domaines de responsabilité de calcul de chemin peuvent aussi exister comme des sous domaines de zones ou d'AS.

Afin de pleinement caractériser un PCE et préciser ces définitions, les importantes considérations suivantes doivent aussi être examinées :

1)	Le calcul de chemin est applicable dans des contextes intra domaine, inter domaines, et inter couches.

a.	Le calcul de chemin inter domaines peut impliquer l'association d'informations de topologie, d'acheminement, et de politique provenant de multiples domaines à partir desquels des relations peuvent être déduites afin d'aider à effectuer le calcul de chemin.

b.	Le calcul de chemin inter couches se réfère à l'utilisation de PCE lorsque plusieurs couches sont impliquées et quand l'objectif est d'effectuer le calcul de chemin à une ou plusieurs couches tout en tenant compte des informations de topologie et de ressource à ces couches.

Les chevauchements de domaines sortent du domaine d'application de ce document. Dans le cas inter domaines, les domaines peuvent appartenir à un seul ou à plusieurs fournisseurs de service.

2)	a. Dans un "calcul de chemin par un seul PCE", un seul PCE est utilisé pour calculer un certain chemin dans un domaine. Il peut y avoir plusieurs PCE dans un domaine, mais seulement un PCE par domaine est impliqué dans tout calcul de chemin.

b. Dans un "calcul de chemin de multiples PCE", plusieurs PCE sont utilisés pour calculer un certain chemin dans un domaine.

3)	Un. "modèle de calcul centralisé" se réfère à un modèle dans lequel tous les chemins dans un domaine sont calculés par un seul PCE centralisé.

b.	À l'inverse, "modèle de calcul réparti" se réfère au calcul de chemin qui est partagé entre plusieurs PCE dans un domaine.

Les chemins qui s'étendent sur plusieurs domaines peuvent être calculés en utilisant le modèle réparti avec un ou plusieurs PCE chargés de chaque domaine, ou le modèle centralisé en définissant un domaine qui englobe les autres domaines.

À partir de ces définitions, un modèle de calcul centralisé utilise par nature un seul PCE de calcul de chemin. Cependant, un modèle de calcul réparti pourrait utiliser soit  un seul PCE de calcul de chemin, soit plusieurs PCE de calcul de chemin. Il ne peut pas y avoir un modèle centralisé qui utiliserait plusieurs PCE.

4)	Le PCE peut être ou non localisé à la tête du chemin. Par exemple, une solution conventionnelle intra domaine est d'avoir le calcul de chemin effectué au LSR de tête d'un LSP TE MPLS ; dans ce cas, le LSR de tête contient un PCE. Mais il existe aussi des solutions où d'autres nœuds sur le chemin doivent contribuer au calcul de chemin (par exemple, des bonds lâches) qui en font des PCE de plein droit. En même temps, le calcul de chemin peut être fait par d'autres PCE physiquement distincts du chemin calculé.

5)	Le chemin calculé par le PCE peut être un "chemin explicite" (c'est-à-dire, le chemin explicite complet du début à la destination, fait d'une liste de bonds stricts) sur un chemin "strict/lâche" (c'est-à-dire, un mélange de bonds stricts et lâches comprenant au moins un bond lâche représentant la destination) où un bond peut être un nœud abstrait comme un AS.

6)	Un modèle de calcul de chemin fondé sur le PCE ne signifie pas qu'il est exclusif et peut être utilisé en conjonction avec d'autres modèles de calcul de chemin. Par exemple, le chemin d'un LSP TE inter AS peut être calculé en utilisant un modèle de calcul de chemin fondé sur le PCE dans certains AS, tandis que l'ensemble des AS traversés peut être spécifié par d'autre moyens (non déterminés par un PCE). De plus, différents modèles de calcul de chemin peuvent être utilisés pour différents LSP TE.

7)	Le présent document ne fait aucune hypothèse sur la nature ou la mise en œuvre d'un PCE. Un PCE pourrait être mis en œuvre sur un routeur, un LSR, un serveur de réseau dédié, etc. De plus, la fonction de PCE est orthogonale à la capacité de transmission du nœud sur laquelle elle est mise en œuvre.

 	4.	Motifs d'une architecture fondée sur le PCE

Plusieurs motifs pour une architecture fondée sur le PCE (décrit à la Section 5) sont mentionnés ci-dessous. Cette liste n'est pas conçue comme exhaustive et est fournie à des fins d'illustration.

Il devrait être souligné que le but de cette section est de fournir des exemples d'applications pour lesquelles un chemin fondé sur le PCE peut être convenable : on déclare aussi clairement qu'un tel modèle ne vise pas à remplacer les modèles de calcul de chemin existants mais va s'appliquer à des situations spécifiques, existantes ou futures.

Comme on peut le voir dans ces exemples, un PCE ne remplace pas le modèle existant de l'Internet où l'intelligence est distribuée dans le réseau. À la place, on s'appuie sur ce modèle et on utilise des centres d'informations répartis ou une capacité de calcul. Le PCE ne devrait donc pas nécessairement être vu comme un "oracle qui voit tout dans le ciel" centralisé, mais comme le fonctionnement coopératif de fonctions réparties utilisées pour répondre à des défis spécifiques comme le calcul du plus court chemin à contraintes inter domaines.

 	4.1	Calcul de chemin coûteux en CPU
Il y a de nombreuses situations où le calcul d'un chemin peut être gros consommateur de CPU ; des exemples de calcul de chemin à grosse consommation de CPU incluent la résolution de problèmes comme :
-	Placer un ensemble de LSP TE au sein d'un domaine de façon à optimiser une fonction objective (par exemple, minimisation de l'utilisation maximum de liaison)
-	Calcul de chemin multi critères (par exemple, délai et utilisation de liaison, inclusion de capacités de commutation, caractéristiques d'adaptation, types de codage et contraintes optiques au sein d'un réseau optique GMPLS)
-	Calcul d'arborescences de coût minimal en point à multipoint (arborescences de Steiner)

Dans ces situations, il peut n'être pas possible ou désirable pour certains routeurs d'effectuer le calcul de chemin à cause des contraintes sur leurs CPU, et dans ce cas les calculs de chemin peuvent être déchargés sur d'autres PCE qui peuvent, eux-mêmes, être des routeurs ou peuvent être des serveurs PCE dédiés.

 	4.2	Visibilité partielle
Il y a plusieurs scénarios où le nœud chargé du calcul de chemin a une visibilité limitée de la topologie du réseau vers la destination. Cette limitation peut survenir, par exemple, quand un routeur d'entrée tente d'établir un LSP TE avec une destination qui se trouve dans un domaine séparé, dans la mesure où les informations de TE ne sont pas échangées à travers des frontières de domaines. Dans un tel cas, il est possible d'utiliser des routes lâches pour établir le LSP TE, s'appuyant sur les routeurs à la frontière de domaine pour établir le prochain élément de chemin. Cependant, il n'est pas possible de garantir que le chemin optimal (le plus court) va être utilisé, ou même qu'un chemin viable va être découvert, sauf éventuellement, par des essais et erreurs répétés en utilisant le retour de manivelle (crankback) ou d'autres extensions de signalisation.

Ce problème de calcul de chemin inter domaines peut très probablement être traité par un calcul distribué avec la coopération entre PCE au sein de chacun des domaines, et potentiellement en utilisant le retour de manivelle entre les domaines pour résoudre dynamiquement les questions de provisionnement. Autrement, un PCE central "voyant tout" qui a accès à l'ensemble complet des informations de topologie peut être utilisé, mais dans ce cas il y a des problèmes d'adaptabilité (à la fois la taille de la TED et la responsivité d'un seul PCE traitant des demandes pour de nombreux domaines) et de préservation de confidentialité quand les domaines appartiennent à des fournisseurs de service différents.

Noter que les problèmes décrits ici peuvent être développés plus en détails dans le contexte de la réoptimisation de LSP TE, ou par l'établissement de plusieurs LSP TE divers pour la protection ou le partage de charge.

 	4.3	Absence de la TED ou utilisation d'ICP sans capacité TE
La base de données d'ingénierie du trafic (TED) peut puiser largement sur les ressources d'un nœud de réseau (comme un routeur bordure ou LER). La maintenance de la TED peut exiger une grosse quantité de mémoire et peut exiger une activité de CPU non négligeable. L'utilisation d'un PCE distinct peut être appropriée dans de telles circonstances, et un nœud séparé peut être utilisé pour établir et maintenir la TED, et la rendre disponible pour le calcul de chemin.

Les IGP qui fonctionnent au sein de certains réseaux ne sont pas suffisants pour construire une TED complète. Par exemple, un réseau peut faire fonctionner OSPF/IS-IS sans les extensions OSPF-TE/ISIS-TE, ou certains routeurs dans le réseau peuvent ne pas prendre en charge les extensions TE. Dans ces cas, afin de réussir à calculer les chemins à travers le réseau, la TED doit être construite ou complétée par une action de configuration et mise à jour lorsque les ressources du réseau sont réservées ou libérées. Une telle TED pourrait être répartie entre les routeurs qui ont besoin d'effectuer le calcul de chemin, ou tenue centralement (sur un nœud distinct qui prend en charge le PCE) pour un calcul centralisé.

 	4.4	Nœud en dehors du domaine d'acheminement
Un LER peut ne pas faire partie du domaine d'acheminement pour des raisons administratives (par exemple, un routeur du côté consommateur (CE, customer-edge) connecté au routeur côté fournisseur (PE, provider-edge) dans le contexte d'un VPN MPLS [RFC4364] et pour lequel on désire fournir un chemin LSP TE de CE à CE).

Ce scénario suggère une solution qui n'implique pas de faire de calcul sur le routeur d'entrée (extrémité de tête de LSP TE, CE) et qui ne repose pas sur la configuration de bonds lâches statiques. Dans ce cas, les chemins optimaux les plus courts ne peuvent pas être garantis. Une solution à laquelle un PCE inter domaines distinct peut aider ici. Noter que dans ce cas, le PCE peut lui-même fournir un chemin qui inclut des bonds lâches.

 	4.5	Élément de réseau sans capacité de plan de contrôle ou d'acheminement
Il est courant dans les réseaux optiques traditionnels que les éléments de réseau n'aient pas de plan de contrôle ou de capacité d'acheminement. De tels éléments de réseau ont seulement un plan de données et un plan de gestion, et toutes les inter connexions sont faites à partir du plan de gestion. Il est désirable dans ce cas de faire le calcul de chemin sur le PCE, et d'envoyer les commandes d'inter connexion à chaque nœud sur le chemin calculé. C'est-à-dire que le PCC va être un élément du plan de gestion, résidant peut-être dans le système de gestion du réseau (NMS, Network Management System) ou dans le système de prise en charge des opérations (OSS, Operations Support System).

Ce scénario est important pour les réseaux optiques à commutation automatique (ASON, Automatically Switched Optical Network) et peut aussi être utilisé pour l'inter fonctionnement entre les réseaux à capacité GMPLS et ceux qui ne le sont pas.

 	4.6	Calcul de chemin de sauvegarde pour la protection de la bande passante
Un PCE peut être utilisé pour calculer les chemins de sauvegarde dans le contexte d'une protection de réacheminement rapide des LSP TE. Dans ce modèle, tous les LSP TE de sauvegarde qui protègent une certaine facilité sont calculés de façon coordonnée par un PCE. Cela permet un partage complet de bande passante entre les tunnels de sauvegarde qui protègent les éléments indépendants, tout en évitant toute extension de la signalisation de LSP TE. Les deux modèles centralisé et réparti de calcul sont applicables. Dans le cas réparti, chaque LSR peut être un PCE pour calculer les chemins des tunnels de sauvegarde pour protéger contre la défaillance des liaisons ou nœuds de réseau adjacent.

 	4.7	Réseaux multi couches
Un réseau de couche serveur d'une capacité de commutation peut prendre en charge plusieurs réseaux d'une autre capacité de commutation (d'une plus grande granularité). Par exemple, un réseau à multiplexage à division dans le temps (TDM, Time-Division Multiplexing) peut fournir la connexité pour des réseaux de couche client comme IP, MPLS, ou de couche 2 [RFC5212].

Le réseau de couche serveur ne va probablement pas fournir le même paradigme de connexité que les réseaux de clients, de sorte que la granularité de la bande passante dans le réseau de couche serveur peut être beaucoup plus grossière que dans le réseau de couche client. De même, il est probable qu’il y a une séparation de gestion entre les deux réseaux fournissant des espaces d'adresses indépendants. De plus, lorsque plusieurs réseaux de couche client font usage du même réseau de couche serveur, ces réseaux de couche client peut avoir des politiques, des paramètres de commande, des espaces d'adresses, et des préférences d'acheminement, indépendantes

Les différents réseaux de couche client et serveur peuvent être considérés comme des régions distinctes de calcul de chemin au sein d'un domaine de PCE, de sorte que l'architecture de PCE est utile pour permettre le calcul de chemin d'une région de réseau de couche client, à travers le réseau de couche serveur, à une autre région de réseau de couche client.

Dans ce cas, les PCE sont chargés de résoudre les questions d'espace d'adresses, de traiter les différences de politique et de paramètres de contrôle, et de coordonner les ressources entre les réseaux. Noter que, à cause des différences de granularité de bande passante, la connexité à travers la couche serveur peut être fournie par des liaisons TE virtuelles ou des adjacences de transmission : le PCE peut offrir un point de contrôle responsable de la décision de fournir une nouvelle liaison TE ou une adjacence de transmission à travers le réseau de couche serveur.

 	4.8	Politique de choix de chemin
Un PCE peut avoir une politique locale qui impacte le calcul et le choix de chemin en réponse à une demande de calcul de chemin. Une telle politique peut agir sur les informations fournies par le PCC demandeur. Le résultat de l'application d'une telle politique inclut, par exemple, le rejet d'une demande de calcul de chemin, ou la fourniture d'un chemin qui ne satisfait pas à toutes les contraintes demandées. De plus, la politique peut prendre en charge des chemins configurés administrativement, ou choisir parmi les fournisseurs de transit. L'inclusion d'une politique au sein d'un PCE peut simplifier l'application de la politique au sein du processus de calcul/choix de chemin.

De même, un PCC peut appliquer une politique locale au choix d'un PCE pour calculer un chemin spécifique, et pour les contraintes demandées.

Dans un contexte de PCE, la politique peut être sensible au type du chemin calculé. Par exemple, un jeu différent de politiques peut être appliqué pour un chemin intra-zone ou d'une seule couche que celui fourni pour un chemin inter zones ou multi couches.

Noter que la synchronisation de politique entre des PCE ou entre des PCC et des PCE peut être nécessaire. De telles questions sortent du domaine de l'architecture de PCE, mais sont décrites dans le cadre et l'application de la politique de PCE dans un document séparé.

 	4.9	Non motivations
 	4.9.1	Internet global
Le PCE n'est pas considéré comme étant une solution applicable à l'Internet entier. C'est-à-dire que l'applicabilité du PCE est limitée à un ensemble de domaines qui ont des relations connues. La portée de cette limitation est similaire aux relations d'échange de trafic entre fournisseurs de service.

 	4.9.2	Établissement de LSP TE garanti
Lorsque deux chemins ou plus pour des LSP TE sont calculés sur le même ensemble d'informations d'état de liaison TE, il est possible que les chemins résultants soient en compétition pour les ressources limitées au sein du réseau. Il peut en résuler un succès seulement pour le premier LSP TE signalé, ou cela peut même signifier qu'aucun LSP TE ne peut être établi.

Le traitement par lots des demandes de calcul, des temps de retard, le calcul de chemins de remplacement, et le retour de manivelle peuvent atténuer cette sorte de problèmes, et le PCE peut aussi améliorer les chances de succès de l'établissement de LSP TE. Cependant, un seul PCE centralisé n'est pas vu comme une solution qui peut garantir l'établissement de LSP TE car il existe encore un potentiel de défaillances de réseau ou de contention des ressources lorsque la TED centralisée ne peut pas pleinement refléter l'état actuel (c'est-à-dire, en temps réel) du réseau.

 	5	Vue d'ensemble de l'architecture fondée sur le PCE

Cette Section donne une vue d'ensemble de l'architecture du modèle de PCE. Elle doit être vue en conjonction avec les détails fournis à la section suivante pour avoir une vue complète de la souplesse du modèle.

 	5.1	Nœud PCE composite
La Figure 1 ci-dessous montre les composants d'un nœud PCE composite typique (c'est-à-dire, un routeur qui met aussi en œuvre la fonction de PCE) qui utilise le calcul de chemin. Le protocole d'acheminement est utilisé pour échanger les informations de TE à partir desquelles la TED est construite. Les demandes de service pour provisionner les LSP TE sont reçues par le nœud et converties en demandes de signalisation, mais cette conversion peut exiger un calcul de chemin qui est demandé à partir d'un PCE. Le PCE opère sur la TED sous réserve de la politique locale afin de répondre avec le chemin demandé.

                 ---------------
                |   ---------   | Protocole ----------
                |  |         |  |d'achemin.|          |
                |  |   TED   |<-+----------+->        |
                |   ---------   |          |          |
                |      |        |          |          |
                |      | Entrée |          |  Nœud    |
                |      v        |          | adjacent |
                |   ---------   |          |          |
                |  |   PCE   |  |          |          |
                |   ---------   |          |          |
                |      ^        |          |          |
                |      |Réponse |          |          |
                |      |à la demande       |          |
                |      v        |          |          |
                |   ---------   |          |          |
       Demande  |  |  Moteur |  | Protocole|          |
    de service  |  |de signal|  |signalisation        |
          ------+->|isation  |<-+----------+->        |
                |   ---------   |           ----------
                 ---------------

Figure 1. Nœud PCE composite

Noter que l'adjacence d'acheminement entre le nœud PCE composite et tout autre routeur peut être effectuée au moyen de la connexité directe ou de tout mécanisme de tunnelage.

 	5.2	PCE externe
La Figure 2 montre un PCE externe à l'élément de réseau demandeur. Une demande de service est reçue par le nœud d'extrémité de tête, et avant qu'il puisse initier la signalisation pour établir le service, il fait une demande de calcul de chemin au PCE externe. Le PCE utilise la TED sous réserve de la politique locale comme entrée au calcul et retourne une réponse.

               ----------
              |  -----   |
              | | TED |<-+----------->
              |  -----   |  Mécanisme de synchronisation de TED
              |    |     |  (par exemple, protocole d'acheminement)
              |    v     |
              |  -----   |
              | | PCE |  |
              |  -----   |
               ----------
                   ^
                   | Demande/réponse
                   v
     Demande   ----------  Protocole de ----------
  de service  | Nœud de  |signalisation|  Nœud    |
         ---->|  tête    |<----------->| adjacent |
               ----------               ----------

Figure 2. Nœud PCE externe

Noter que dans ce cas, le nœud qui prend en charge la fonction de PCE peut aussi être un LSR ou routeur qui effectue la transmission de son plein droit (c'est-à-dire, il peut être un nœud PCE composite) mais ces fonctions sont purement orthogonales au fonctionnement dans l'instance considérée ici.

 	5.3	Calcul de chemin à plusieurs PCE
La Figure 3 illustre comment plusieurs calculs de chemin de PCE peuvent être effectués le long du chemin d'un service signalé. Comme dans l'exemple précédent, le PCC d'extrémité de tête fait une demande à un PCE externe, mais le chemin qui est retourné est tel que le prochain élément de réseau estime nécessaire d'effectuer des calculs complémentaires. Ce peut être le cas quand le chemin retourné est un chemin partiel qui n'arrive pas jusqu'à la destination prévue ou quand le chemin calculé est lâche. L'élément de réseau en aval consulte un autre PCE pour établir le ou les prochains bonds dans le chemin. Dans ce cas, toutes les décisions de politique sont prises indépendamment à chaque PCE sur la base des informations passées du PCC.

Noter que l'un ou l'autre PCE ou les deux pourraient dans ce cas être des nœuds PCE composites, comme au paragraphe 5.1.

            ----------           ----------
           |          |         |          |
           |   PCE    |         |   PCE    |
           |   -----  |         |   -----  |
           |  | TED | |         |  | TED | |
           |   -----  |         |   -----  |
            ----------           ----------
                ^                     ^
                | demande/réponse     | demande/réponse
                v                     v
 Demande de -------- Protocole de  ------------  Protocole de  -------------
  service  | Nœud de|signalisation|    Nœud     |signalisation|    Nœud     |
      ---->|  tête  |<----------->|intermédiaire|<----------->|intermédiaire|
            --------               ------------                -------------

Figure 3. Calcul de chemin à plusieurs PCE

 	5.4	Calcul de chemin à plusieurs PCE avec communication inter PCE
Le PCE du paragraphe 5.3 n'était pas capable de fournir un chemin complet pour le service demandé, et par suite, le nœud adjacent doit faire sa propre demande de calcul. Comme l'illustre la Figure 4, le même problème peut être résolu par l'introduction d'une communication inter PCE, et d'une coopération entre les PCE afin que le PCE consulté par le nœud de réseau d'extrémité de tête fasse une demande à un autre PCE pour l'aider au calcul.

             ----------                                      ----------
            |          |   demande/réponse inter PCE       |          |
            |   PCE    |<--------------------------------->|   PCE    |
            |   -----  |                                   |   -----  |
            |  | TED | |                                   |  | TED | |
            |   -----  |                                   |   -----  |
             ----------                                     ----------
                 ^
                 | demande/réponse
                 v
 Demande de -------- Protocole de  --------  Protocole de  ---------
  service  | Nœud de|signalisation|  Nœud  |signalisation|   Nœud   |
      ---->|  tête  |<----------->|adjacent|<----------->| adjacent |
            --------               --------               ----------

Figure 4. Calcul de chemin à plusieurs PCE avec communication inter PCE

Plusieurs calculs de chemin de PCE avec communication inter PCE impliquent la coordination entre des PCE distincts de telle sorte que le résultat du calcul effectué par un PCE dépend des informations de fragment de chemin fournies par les autres PCE. Ce modèle ne donne pas un algorithme de calcul réparti, mais il permet que des PCE distincts soient responsables du calcul de parties (segments) du chemin.

La communication de PCE à PCE est discutée plus en détails au paragraphe 6.6.

Noter qu'un PCC peut ne pas voir la différence entre un calcul de chemin centralisé et plusieurs calculs de chemin de PCE avec communication inter PCE. C'est-à-dire que le nœud de réseau ou composant de PCC qui demande le calcul fait une seule demande et reçoit en réponse un chemin partiel ou complet, mais la réponse est en fait réalisée par les efforts coordonnés et coopératifs de plus d'un PCE.

Dans ce modèle, toutes les décisions de politique peuvent être prises indépendamment à chaque PCE sur la base des informations de calcul passées du PCE précédent. Autrement, il peut y avoir une communication explicite des informations de politique entre les PCE.

 	5.5	Usage de PCE fondé sur la gestion
Il doit être observé que le PCC n'est pas nécessairement un LSR. Par exemple, dans la Figure 5 le système de gestion du réseau (NMS) fournit au LSR d'extrémité de tête un chemin explicite entièrement calculé pour le LSP TE qu'il va établir par la signalisation. Le NMS utilise un mécanisme de plan de gestion pour envoyer cette demande et code les données en utilisant une représentation comme celle du module de MIB TE [RFC3812].

Le NMS construit le chemin explicite qu'il fournit au LSR d'extrémité de tête en utilisant les informations fournies par l'opérateur. Il consulte le PCE, qui retourne un chemin pour qu'il soit utilisé par le NMS.

Bien que la Figure 5 montre le PCE comme distant du NMS, il pourrait bien sûr, être co-localisé au NMS.

                                 -----------
                                |   -----   |
       Demande de service             |  | TED |<-+----------->
               |                |   -----   |  mécanisme de synchronisation
               |                |     |     |  de TED (par exemple, protocole
               v                |     |     |  d'acheminement)
         ------------- demande/ |     v     |
        |             | réponse |   -----   |
        |     NMS     |<--------+> | PCE |  |
        |             |         |   -----   |
         -------------           -----------
    Demande de |
       service |
               v
          ---------  Protocole de   ----------
         |  Nœud   | signalisation |  Nœud    |
         | de tête |<------------->| adjacent |
          ---------                 ----------

Figure 5. Usage de PCE fondé sur la gestion

 	5.6	Secteurs à normaliser
Les secteurs suivants exigent une normalisation au sein de l'architecture de PCE.
-	la communication entre PCC et PCE, et entre PCE coopérants, incluant la communication d'informations de politique  ;
-	les exigences pour étendre les protocoles existants d'acheminement et de signalisation à l'appui de la découverte de PCE et de la signalisation des chemins inter domaines  ;
-	la définition de métriques d'évaluation de la qualité, de l'adaptabilité, de la responsivité, de la robustesse du chemin, et de la prise en charge par la politique des modèles de calcul de chemin  ;
-	les modules de MIB relatifs aux protocoles de communication, aux extensions d'acheminement et de signalisation, les métriques, et les informations de surveillance de PCE.

 	6.	Considérations sur l'architecture de PCE

Cette Section donne une liste de composants de l'architecture de PCE. Les détails spécifiques de réalisations et de mise en œuvre (automates à états ou algorithmes, etc.) des solutions fondées sur le PCE sortent du domaine d'application du présent document.

Noter aussi que le calcul de chemin fondé sur le PCE n'affecte en aucune façon l'utilisation des chemins calculés. Par exemple, l'utilisation de PCE ne change pas la façon dont sont signalés, maintenus et supprimés, les LSP à ingénierie du trafic, mais il se rapporte strictement aux aspects de calcul de chemin de tels LSP TE.

Cette Section présente une vue architecturale du PCE. C'est-à-dire qu'elle décrit les composants qui existent et comment ils interagissent. Noter que le modèle architectural, et en particulier le modèle fonctionnel, peut être perçu différemment par les divers composants du système de PCE. Par exemple, le PCC ne va pas savoir si un PCE consulte d'autres PCE. L'architecture de PCE vue du PCE est discutée à la Section 7.

 	6.1	Modèle de calcul centralisé
Un "modèle de calcul centralisé" considère que tous les calculs de chemin pour un certain domaine vont être effectués par un seul PCE centralisé. Ce peut être un serveur dédié (par exemple, un nœud PCE externe) ou un routeur désigné (par exemple, un nœud PCE composite) dans le réseau. Dans ce modèle, tous les PCC dans le domaine vont envoyer leurs demandes de calcul de chemin au PCE central. Bien qu'un domaine dans ce contexte puisse être une zone d'IGP ou un AS, il pourrait aussi être un sous groupe de nœuds de réseau qui est défini par sa dépendance au PCE.

Ce modèle a un seul point de faiblesse : le PCE. Afin d'éviter ce problème, le modèle de calcul centralisé peut désigner un PCE de sauvegarde qui peut prendre la responsabilité du calcul d'une manière contrôlée dans l'éventualité d'une défaillance du PCE principal. Toutes les politiques présentes sur le PCE principal devraient aussi être présentes sur le PCE de sauvegarde, bien que les politiques principales puissent elles-mêmes être soumises à une politique dictant comment elles sont mises en œuvre sur le PCE de sauvegarde. Noter qu'à chaque instant, un seul PCE est actif dans tout domaine.

 	6.2	Modèle de calcul réparti
Un "modèle de calcul réparti" se réfère à un domaine ou réseau qui peut inclure de multiples PCE, et où le calcul des chemins est partagé entre les PCE. Un certain chemin peut à son tour être calculé par un seul PCE ("calcul de chemin à un seul PCE") ou plusieurs PCE ("calcul de chemin à plusieurs PCE"). Un PCC peut être relié à un PCE particulier ou peut être capable de choisir librement parmi plusieurs PCE ; la méthode de choix entre les PCE sort du domaine d'application du présent document, mais voir au paragraphe 6.4 la discussion de la découverte de PCE qui affecte ce choix. La mise en œuvre de politique devrait être cohérente sur l'ensemble des PCE disponibles.

Souvent, le calcul d'un chemin individuel est effectué entièrement pas un seul PCE. Par exemple, c'est généralement le cas dans MPLS TE au sein d'une seule zone d'IGP où le LSR d'entrée/nœud PCE composite est chargé de calculer le chemin ou de contacter un PCE externe. À l'inverse, un calcul de chemin à plusieurs PCE implique que plus d'un PCE est impliqué dans le calcul d'un seul chemin. Un exemple de ceci est lorsque une expansion de bond lâche est effectuée par les LSR de transit/nœuds PCE composites sur un LSP TE MPLS. Un autre exemple est l'utilisation de plusieurs PCE coopérants pour calculer le chemin d'un seul LSP TE à travers plusieurs domaines.

 	6.3	Synchronisation
Souvent, plusieurs chemins doivent être calculés pour prendre en charge un seul service (par exemple, pour la protection ou le partage de charge). Un PCC qui détermine qu'il a besoin que plus d'un chemin soit calculé peut envoyer une série de demandes individuelles au PCE. Dans le cas de demandes non synchronisées de calcul de chemin, le PCE peut faire plusieurs calculs individuels de chemin pour générer les chemins, et le PCC peut envoyer ses demandes individuelles à des PCE différents.

Autrement, le PCC peut envoyer une seule demande à un PCE demandant le calcul d'en ensemble de chemins, mais spécifiant qu'un calcul de chemin non synchronisé est acceptable. Le PCE peut calculer chaque chemin tour à tour exactement comme il aurait fait si le PCC avait fait des demandes multiples, et le PCE peut sous traiter certains calculs à d'autres PCE si c'est son choix. Par ailleurs, il n'est pas interdit au PCE d'effectuer ensemble tous les calculs de manière synchronisée, comme on le décrit ci-dessous.

Le PCC peut aussi produire au PCE une seule demande que tous les chemins soient calculés de manière synchronisée. Le PCE va alors effectuer le calcul simultané de l'ensemble de chemins demandés. Un tel calcul synchronisé peut souvent donner de meilleurs résultats.

L'implication de plus d'un PCE dans le calcul d'une série de chemins est par nature non synchronisée. Cependant, un ensemble de PCE coopératifs peut être synchronisé sous le contrôle d'un seul PCE. Par exemple, un PCC peut envoyer une demande à un PCE invoquant des calculs spécifiques de domaines faits par d'autres PCE avant de fournir un résultat au PCC.

Il est désirable d'ajouter un paramètre au protocole PCC-PCE pour demander que le PCE fournisse un ensemble de chemins de remplacement à utiliser par le PCC, si l'établissement du LSP TE utilisant le chemin principal venait à échouer. Bien que les chemins de remplacement ne puissent pas toujours être des succès si le premier chemin échoue, inclure des chemins de remplacement dans une réponse de PCE pourrait générer moins de frais généraux que d'avoir le PCC qui effectue des demandes séparées pour les calculs de chemin suivants quand leur besoin apparaît. Cette technique est utilisée dans certaines mises en œuvre existantes de CSPF.

 	6.4	Découverte de PCE et équilibrage de charge
Afin qu'un PCC puisse communiquer efficacement avec un PCE, il doit connaître la localisation du PCE. C'est-à-dire, c'est une décision architecturale qui est faite ici que les demandes au PCC soient ciblées sur un PCE spécifique, et non diffusées au réseau pour que n'importe quel PCE réponde. Cette décision signifie que seul le PCE choisi va opérer sur toute demande, et cela économise les ressources du réseau durant la propagation de la demande et les ressources de traitement chez les PCE qui ne sont pas obligés de répondre.

La connaissance de la localisation d'un PCE peut être réalisée par la configuration locale du PCC ou peut s'appuyer sur un mécanisme de découverte fondé sur le protocole qui peut être gouverné par la politique.

Lorsque plus d'un PCE est connu comme PCC, le PCC doit avoir des informations suffisantes pour choisir un PCE approprié pour ses besoins, sous le contrôle de la politique. Une telle procédure de choix permet un partage de charge entre les PCE et prend en charge des PCE avec des capacités de calcul différentes incluant des portées de visibilité différentes. Donc, les informations disponibles au PCC doivent inclure des détails sur les capacités du PCE, qui peuvent être fixes ou peuvent varier dynamiquement dans le temps.

Le PCC peut apprendre les capacités du PCE par une configuration statique, ou il peut découvrir les informations de façon dynamique. Noter que même quand la localisation du PCE est configurée au PCC, le PCC peut quand même découvrir les capacités du PCE de façon dynamique. Les capacités dynamiques de PCE ne peuvent pas être configurées et peuvent seulement être découvertes.

Une annonce de PCE mandataire par laquelle l'existence d'un PCE est annoncée via un PCE mandataire est une solution de remplacement viable, si le PCE devait être incapable d'une telle annonce de lui-même. Dans ce cas, il est exigé que le mandataire annonce de façon adéquate l'état du PCE et ses capacités en temps utile et de façon synchronisée.

Dans le cas où plusieurs PCE sont disponibles pour servir une demande particulière de calcul de chemin, le PCC doit choisir un PCE pour satisfaire la demande. Les détails d'un tel choix (par exemple, pour partager efficacement la charge du calcul entre plusieurs PCE ou pour demander des calculs secondaires après des calculs partiels ou échoués) sont un problème local du PCC, peut-être fondés sur la politique, et sortent du domaine d'application du présent document.

Les capacités de PCE qui peuvent être annoncées ou configurées pourraient inclure (et ne sont pas être limitées à) :
-	un ensemble de contraintes dont il peut tenir compte (diversité, groupes de liaisons à risques partagés (SRLG, shared risk link group), appariements optiques, continuité de longueur d'onde, etc.)
-	capacité de calcul (par exemple, le nombre de calculs qu'il peut effectuer par seconde)
-	le nombre de couches de capacité de commutation (et lesquelles)
-	le nombre de critères de choix de chemin (et lesquels)
-	si il est un PCE sans état ou si il peut envoyer des mises à jour sur les meilleurs chemins qui pourraient être disponibles à l'avenir
-	si il peut calculer des arborescences de point à multi points (et de quels types)
-	si il peut assurer le partage de ressources entre des tunnels de sauvegarde.

Ces informations vont aider un PCC à décider quel PCE utiliser.

Les exigences pour les annonces de PCE vont être documentées séparément. Noter qu'il n'y a pas de restriction au sein de l'architecture sur la façon dont la localisation et les capacités sont annoncées, et les deux éléments devraient être considérés comme fonctionnellement distincts.

Un PCC peut aussi demander à un PCE d'effectuer un type particulier de service sans connaître les capacités du PCE et recevoir une réponse qui dit que le PCE est incapable d'efectuer le service. La réponse pourrait spécifier les capacités du PCE et pourrait aussi suggérer un autre PCE qui a les capacités demandées.

 	6.5	Détection de PCE en vie
La capacité à détecter la vivacité d'un PCE est une partie obligatoire de l'architecture globale et pourrait être réalisée par plusieurs moyens. Si une forme d'annonce régulière (comme par les extensions à IGP) est utilisée pour la découverte de PCE, on s'attendra à ce que la vivacité du PCE soit déterminée au moyen d'annonces d'état (par exemple, des LSA/LSP IGP).

L'incapacité d'un PCE à servir une demande (peut-être à cause d'une charge excessive) peut être rapportée au PCC par un message d'échec, mais l'échec d'un PCE ou du mécanisme de communications lors du traitement d'une demande ne peut pas être rapporté de cette façon. De plus, dans le cas de charge excessive, le PCE peut n'avoir pas les ressources suffisantes pour envoyer un message d'échec. Donc, le PCC devrait employer d'autres mécanismes, comme des temporisateurs du protocole, pour déterminer la vivacité du PCE. Ceci est particulièrement important dans le cas de calcul de chemin inter domaines où la vivacité du PCE peut n'être pas détectée par les moyens de l'IGP qui fonctionne dans le domaine du PCC.

 	6.6	Communication PCC-PCE et PCE-PCE 
Une fois que le PCC a choisi un PCE, et pourvu que ce PCE ne soit pas local pour le PCC, un protocole de demande/réponse est nécessaire pour que le PCC communique les demandes de calcul de chemin au PCE et pour que le PCE retourne la réponse de calcul de chemin. La discussion des exigences et implications de sécurité pour ce protocole est fournie à la Section 10 du présent document.

La demande de calcul de chemin peut inclure un ensemble significatif d'exigences, incluant les suivantes :
- la source et la destination du chemin
- la bande passante et autres paramètres de qualité de service (QS) désirés
- les ressources, affinités de ressources, et les groupes de liaison à risques partagés (SRLG) à utiliser/éviter
- le nombre de chemins disjoints requis et si des chemins presque disjoints sont acceptables
- le niveaux de résilience, fiabilité, et robustesse des ressources du chemin
- les informations relatives à la politique.

Le niveau de robustesse des ressources du chemin couvre une affirmation qualitative de la vulnérabilité des ressources qui peuvent être utilisées. Par exemple, on peut classer les ressources sur la base d'une évidence empirique (temps moyen entre les défaillances) sur les risques connus (un travail en cours majeur est mené sur ce sujet), ou sur des préjugés (le logiciel du fabricant X se plante toujours). Un PCC pourrait demander que seules des ressources robustes soient utilisées, ou il pourrait permettre toutes les ressources.

Dans le cas d'une réponse positive de la part du PCE, un ou plusieurs chemins vont être retournés au nœud demandeur. En cas d'échec du calcul du ou des chemins désirés, une erreur est retournée avec autant d'informations que possible sur les raisons de l'échec, et potentiellement avec un avis sur quelles contraintes peuvent être relâchées afin qu'un résultat positif soit plus probable dans une future demande.

Noter que le ou les chemins résultants peuvent être constitués d'un ensemble de bonds stricts ou lâches, ou de toute combinaison de bonds stricts et lâches. De plus, un bond peut avoir la forme d'un nœud abstrait non explicite.

Un protocole de demande/réponse est aussi nécessaire pour qu'un PCE communique les demandes de calcul de chemin à un autre PCE et pour que le PCE retourne les réponses de calcul de chemin. La demande de calcul de chemin peut inclure un ensemble significatif d'exigences incluant celles définies ci-dessus. Dans le cas d'une réponse positive de la part du PCE, un ou plusieurs chemins vont être retournés au PCE demandeur. Dans le cas d'un échec du calcul des chemins désirés, une erreur est retournée avec autant d'informations que possible sur les raisons de l'échec, et potentiellement un avis sur les contraintes qui pourraient être relâchées afin qu'un résultat positif soit plus probable. Noter que le ou les chemins résultants peuvent être constitués d'un ensemble de bonds stricts ou lâches, ou de toute combinaison de bonds stricts et lâches. De plus, un bond peut avoir la forme d'un nœud abstrait non explicite.

Une caractéristique importante des PCE qui coopèrent pour calculer un chemin est qu'ils appliquent des algorithmes compatibles ou identiques de calcul et des politiques coordonnées. Cela peut exiger la coordination à travers la communication entre les PCE.

Noter que quand plusieurs PCE coopèrent pour calculer un chemin, il est important qu'ils aient une vue coordonnée de la signification des contraintes comme les coûts, les affinités de ressources, et la classe de service. Ceci est particulièrement significatif lorsque les PCE sont chargés de différents domaines. On suppose que ceci est une affaire de politique entre domaines et entre PCE.

Aucune hypothèse n'est faite dans cette architecture sur l'éventuelle identité des protocoles de communication de PCC à PCE et de PCE à PCE.

 	6.7	Synchronisation entre PCE et TED
Comme décrit précédemment, le PCE opère sur une TED. Les informations sur l'état du réseau pour construire la TED peuvent être fournies dans le domaine par des moyens variés :

1)	La participation à la distribution par IGP des informations de TE. La méthode standard de distribution des informations de TE au sein d'une zone IGP est par l'utilisation d'extensions à l'IGP [RFC3630], [RFC3784]. Ce mécanisme permet aux nœuds participants de construire une TED, et c'est la technique standard, par exemple, au sein d'une seule zone de réseau MPLS ou GMPLS. Un nœud qui héberge la fonction de PCE peut collecter des informations de TE de cette façon en maintenant au moins une adjacence d'acheminement avec un routeur dans le domaine. Le nœud PCE peut être adjacent ou non adjacent (via des techniques de tunnelage) au routeur. Une telle technique fournit un mécanisme pour s'assurer que la TED est synchronisée efficacement avec l'état du réseau et c'est le cas normal, par exemple, quand le PCE est co-résident avec les LSR dans un réseau MPLS ou GMPLS.

2)	La synchronisation hors bande de la TED. Il peut n'être pas pratique ou possible à un PCE de participer aux IGP d'un ou plusieurs domaines (par exemple, quand il y a de très nombreux domaines, quand la participation à l'IGP n'est pas désirée, ou quand certains domaines ont des IGP sans capacité de TE). Dans ce cas, un mécanisme peut devoir être défini pour permettre au nœud PCE de restituer la TED de chaque domaine. Un tel mécanisme pourrait être incrémentaire (comme l'IGP dans le cas précédent) ou il pourrait impliquer un transfert en vrac de la TED complète. Le premier pourrait significativement limiter la capacité d'assurer la synchronisation de la TED, ce qui peut résulter en une augmentation du taux d'échec des chemins calculés, ou en le calcul de chemins sous optimaux. On devrait aussi prendre en compte l'impact de la répartition de la TED sur le réseau et sur le nœud de réseau au sein du domaine auquel il est demandé de distribuer la base de données. Ceci est particulièrement vrai dans le cas de fréquents changements de l'état du réseau.

3)	Les informations de la TED peuvent inclure des informations obtenues de sources autres que l'IGP. Par exemple, des informations sur les politiques d'usage des liaisons peuvent être configurées par l'opérateur. Le calcul de chemin peut aussi agir comme un ensemble d'informations bien plus large qui inclut des données sur les LSP TE provisionnés au sein du réseau. Ces informations peuvent inclure les routes LSP TE, la bande passante réservée, et le volume de trafic mesuré qui passe par le LSP TE.

De telles informations de LSP TE peuvent améliorer l'optimisation des LSP TE pour fournir une optimisation de "tout le réseau" et peut permettre de prendre en compte les fluctuations du trafic. Les informations détaillées de LSP TE peuvent aussi faciliter la reconfiguration de la topologie de réseau virtuel [RFC5212], dans laquelle des LSP TE de couche inférieure, comme des chemins optiques, fournissent des liaisons TE à l'usage de la couche supérieure, car cette reconfiguration est aussi un problème de "tout le réseau".

Noter que les techniques de synchronisation peuvent s'appliquer aux TED intra et inter domaines. De plus, les techniques peuvent être mêlées pour l’usage dans des domaines différents. Le degré de synchronisation entre le PCE et le réseau est soumis à la mise en œuvre et/ou la politique. Cependant, une meilleure synchronisation conduit généralement à une plus forte probabilité de réussite des chemins.

Noter aussi que le PCE peut seulement avoir accès à une TED partielle : par exemple, dans le cas de calcul de chemin inter domaine où un tel domaine peut être géré par différentes entités. Dans ce cas, chaque PCE peut avoir accès à une TED partielle, et des techniques coopératives entre les PCE peuvent être utilisées pour réaliser le calcul de chemin de bout en bout sans exiger qu'un PCE traite la TED complète relative à l'ensemble des domaines traversés par le LSP TE en question.

 	6.8	PCE à états pleins ou sans état
Un PCE peut être à états pleins ou sans états. Dans le premier cas, il y a une stricte synchronisation entre le PCE et non seulement les états du réseau (en termes d'informations de topologie et de ressource) mais aussi l'ensemble des chemins calculés et des ressources réservées utilisées dans le réseau. En d'autres termes, le PCE utilise les informations provenant de la TED ainsi que des informations sur les chemins existants (par exemple, les LSP TE) dans le réseau quand il traite les nouvelles demandes. Noter que bien que cela permette un calcul de chemin optimal et augmente le taux de succès du calcul de chemin, les PCE à états pleins exigent des mécanismes de synchronisation d'état fiables, avec des frais généraux potentiellement significatifs de plan de contrôle et la maintenance de grandes quantités de données/états (par exemple, maillage complet des LSP TE).

Par exemple, si il y a seulement un PCE dans le domaine, tout le calcul de LSP TE est fait par ce PCE, qui peut alors tracer tous les LSP TE existants et rester synchronisé (chaque changement d'état de LSP TE doit être tracé par le PCE). Cependant, ce modèle pourrait exiger de substantielles ressources de plan de contrôle. Si il y a plusieurs PCE dans le réseau, le calcul et les informations de LSP TE sont répartis entre les PCE de sorte que les ressources requises pour effectuer les calculs sont aussi réparties. Cependant, les questions de synchronisation qui sont discutées au paragraphe 6.7 entrent aussi en jeu.

La maintenance d'une base de données à états pleins peut être non triviale. Cependant, dans un environnement d'un seul PCE centralisé, un PCE à états pleins revient presque simplement à se souvenir de tous les LSP TE que le PCE a calculé, que les LSP TE ont été en fait établis (si cela peut être connu) et quand ils ont été supprimés. Une synchronisation de TED hors bande peut aussi être complexe, avec plusieurs établissements de PCE dans un modèle de calcul de PCE répartis, et pourrait être enclin à des conditions de concurrence, des problèmes d'adaptabilité, etc. Même si le PCE a des informations détaillées sur tous les chemins, les priorités, et les couches, prendre toutes ces informations en compte pour le calcul de chemin pourrait être très complexe. Les PCE peuvent synchroniser l'état en communiquant les uns avec les autres, mais quand des LSP TE sont établis en utilisant des calculs répartis effectués par plusieurs PCE, les problèmes de synchronisation et d'évitement de condition de concurrence deviennent plus importants et plus complexes.

Il y a des avantages à connaître quels LSP TE  existent, et leur acheminement, pour prendre en charge de telles applications en plaçant un LSP TE de haute priorité dans un réseau encombré afin qu'il préempte aussi peu d'autres LSP TE que possible (aussi appelé le problème de la "perturbation minimale"). Noter que préempter sur la base du nombre minimum de liaisons peut ne pas résulter en le plus petit nombre de LSP TE perturbés. Une autre application concerne la construction et la maintenance d'une topologie de réseau virtuelle [RFC5212]. Il est aussi utile de comprendre quels autres LSP TE existent dans le réseau afin de décider comment gérer les adjacences de transmission qui existent ou ont besoin d'être établies. L'analyse des coûts et avantages du calcul de PCE à états pleins va être utile pour déterminer si l'avantage du calcul de chemin est suffisant pour compenser la pression supplémentaire sur le réseau et les ressources de calcul.

À l'inverse, les PCE sans état n'ont pas à se souvenir d'un chemin calculé et chaque ensemble de demandes est traité indépendamment de tous les autres. Par exemple, les PCE sans état peuvent calculer les chemins sur la base des informations de TED courantes, qui pourraient être non synchronisées avec l'état réel du réseau étant donnés d'autres changements récents de chemins calculés de PCE. Noter qu'un PCC peut inclure un ensemble de chemins calculés antérieurement dans sa demande, afin de les prendre en compte, par exemple, pour éviter une double prise en compte de la bande passante ou pour essayer de minimiser les changements (problème de la perturbation minimum).

Noter que le PCE sans état opère sur les informations sur l'état du réseau. La TED contient des informations d'état de liaison et de disponibilité de bande passante qui sont distribuées par les IGP ou collectées par d'autres moyens. Ces informations pourraient être encore améliorées pour augmenter leur granularité et donner plus de détails pour couvrir, par exemple, l'utilisation actuelle de bande passante sur certaines liaisons en accord avec les affinités de ressources ou les classes d'équivalence de transmission. De telles informations ne sont cependant pas des informations d'état de PCE et donc un modèle qui les utilisent est quand même décrit comme sans état dans le contexte de PCE.

Une forme limitée d'état plein pourrait être appliquée au sein d'un PCE par ailleurs sans état. Le PCE peut conserver un peu du contexte des chemins qu'il a récemment calculés afin d'éviter de suggérer l'utilisation des mêmes ressources pour d'autres LSP TE.

 	6.9	Surveillance
La surveillance de PCE est sans aucun doute de la plus haute importance dans toute architecture de PCE. Ceci doit inclure la collection des variables relatives à l'état et au fonctionnement du PCE. Par exemple, il va être nécessaire de comprendre la façon dont la TED reste synchronisée, le taux d'arrivée des nouvelles demandes et les temps de calcul, la gamme des PCC qui utilisent le PCE, et le fonctionnement de tout protocole de PCC à PCE.

 	6.10	Confidentialité
Comme le déclare la [RFC4216], le cas du calcul de LSP TE inter fournisseurs exige la capacité de calculer un chemin tout en préservant la confidentialité à travers les réseaux de plusieurs fournisseurs de services. C'est-à-dire que un fournisseur de service ne doit pas être obligé de divulguer d'informations sur ses ressources ou sa topologie afin de prendre en charge le calcul de chemin de LSP TE inter fournisseurs. Donc, toute solution d'architecture de PCE doit prendre en charge la capacité de retourner des chemins partiels au moyen de bonds lâches (par exemple, où chaque bond lâche pourrait, par exemple, identifier un LSR frontière). Cette exigence n'est pas un problème de sécurité, mais se rapporte à la politique du fournisseur de service. La confidentialité, l'intégrité, et l'authentification des messages de PCC à PCE et de PCE à PCE doivent aussi être assurées et sont décrites à la Section 10.

La capacité de calculer un chemin à la demande du PCC d'extrémité de tête, mais de fournir le chemin en segments aux PCC de frontières du domaine, peut aussi être désirable.

 	6.11	Politique
La politique impacte de multiples aspects de l'architecture de PCE. Deux applications de politique sont à considérer :
- l'application de politique au sein d'une entité architecturale (PCC ou PCE)
- l'application de politique aux communications relatives aux PCE.

Comme elle est directement applicable aux LSP TE, la politique fait partie du mécanisme de signalisation pour l'établissement des LSP TE et n'est pas décrite ici. Il est envisagé que la politique soit largement appliquée comme une affaire locale au sein de chaque PCC et PCE. Cependant, le présent document doit définir des modèles de politique qui puissent être pris en charge au sein de l'architecture de PCE et par les communications relatives au PCE.

Des exemples de politique incluent :
- le choix d'un PCE par un PCC,
- le rejet d'une demande par le PCE sur la base de l'identité du PCC demandeur,
- le choix par le PCE d'un chemin ou l'application de contraintes supplémentaires à un calcul fondé sur le PCC, la cible du calcul, l'heure du jour, etc.

 	6.11.1	Architecture de politique de PCE
Deux exemples de l'utilisation de composants de politique au sein de l'architecture de PCE sont illustrés par les Figures 6 et 7. Les composants de politique pourraient également être appliqués aux autres configurations de PCE montrées à la Section 5. Dans chaque configuration, la politique peut être consultée avant qu'une réponse soit fournie par un PCE et peut aussi être consultée par le PCC/PCE qui reçoit la réponse.

Un PCE peut avoir une politique locale qui impacte les chemins choisis pour satisfaire une demande de PCE particulière. Une politique peut être appliquée sur la base de toute information fournie par un PCC.

À la Figure 6, le composant de politique qui est montré fournit des entrées au composant de PCE. Ce composant de politique peut consulter une base de données de politique externe, mais ceci sort du domaine du présent document.

              ------------------------------
             |                  ---------   |Protocole  ----------
             |                 |         |  |d'achemin.|          |
             |                 |   TED   |<-+----------+->        |
             |                  ---------   |          |          |
             |                     | Entrée |          |          |
             |                     v        |          |          |
             |   ---------      ---------   |          |  Nœud    |
             |  |Composant|    |         |  |          | adjacent |
             |  |politique|--->|   PCE   |  |          |          |
             |   ---------      ---------   |          |          |
             |                     ^        |          |          |
             |                     |Demande |          |          |
             |                     |Réponse |          |          |
             |                     v        |          |          |
             |                  ---------   |          |          |
    Demande  |                 | Moteur  |  |Protocole |          |
 de service  |                 |signalisa|  |signalisation        |
       ------+---------------->| tion    |<-+----------+->        |
             |                  ---------   |           ----------
              ------------------------------

Figure 6. Composant de politique dans le nœud PCE composite

Noter que les informations de politique peuvent être convoyées sur les interfaces internes, et sur les interfaces de protocole externes.

La Figure 7 montre le cas d'une fonction de PCE distincte par l'exemple de plusieurs PCE avec un exemple de communication inter PCE (comparer avec la Figure 4). Chaque PCE prend des entrées de la politique locale au titre du processus de calcul /détermination du routeur. Les composants de politique locale peuvent consulter des composants de politique externe ou des bases de données, mais cela sort du domaine d'application du présent document.

Noter que les informations de politique peuvent être convoyées sur les interfaces de protocole externes, incluant l'interface inter PCE.

      ---------------------                             ---------------------
     |                     | Demande/réponse inter PCE |                     |
     |          PCE        |<------------------------->|       PCE           |
     |                     |                           |                     |
     |  ---------   -----  |                           |  ---------   -----  |
     | |Politique| | TED | |                           | |Politique| | TED | |
     |  ---------   -----  |                           |  ---------   -----  |
      ------------------                                ---------------------
                ^
                | Demande/réponse
                | 
                v
   Demande ---------- Protocole de  ---------- Protocole de  ----------
de service|  Nœud de |signalisation|  Nœud    |signalisation|   Nœud   |
     ---->|  tête    |<----------->| adjacent |<----------->| adjacent |
           ----------               ----------               ----------

Figure 7. Composants de politique dans plusieurs PCE

 	6.11.2	Réalisation de politique
Il y a plusieurs options pour coordonner les informations de politique.

-	Les décisions de politique peuvent être prises par les PCC avant de consulter les PCE. Ce type de décision inclut le choix du PCE, l'application des contraintes, et l'interprétation des demandes de service.

-	Les décisions de politique peuvent être prises indépendamment à un PCE, ou à chaque PCE coopérant. C'est-à-dire que le ou les PCE peuvent prendre des décisions de politique indépendamment des autres décisions de politique prises aux PCC ou aux autres PCE.

-	Il peut aussi y avoir une communication explicite des informations de politique entre PCC et PCE, ou entre les PCE pour réaliser un certain niveau de coordination de politique entre les entités. Le type d'informations portées pour la prise en charge de la politique a d'importantes implications sur quelles politiques peuvent être appliquées à chaque PCE, et les exigences pour l'échange des informations de politique informent du choix ou de la mise en œuvre des protocoles de communication incluant de PCC à PCE, de PCE à PCE, et les protocoles de découverte.

 	6.11.3	Type de politiques
Dans le contexte du PCE, on identifie plusieurs types de politiques :

o	Les politiques spécifiques de l'utilisateur opèrent sur les informations qui sont spécifiques de l'utilisateur d'un service ou du service lui-même, c'est-à-dire, du service pour lequel le chemin est calculé, non le service de calcul. Des exemples de telles informations incluent le contenu des objets d'un message de signalisation ou de provisionnement, l'identifiant d'accès sur lequel le message a été reçu, un identifiant de VPN, un type de point de référence, ou l'identité de l'utilisateur qui initie la demande. Les politiques spécifiques de l’utilisateur pourraient être appliquées par un PCC lors de la construction d'une demande de calcul de chemin, ou par un PCE lors du traitement de la demande pourvu que des informations suffisantes soient fournies par le PCC au PCE.

o	Les politiques spécifiques de la demande opèrent sur les informations qui sont spécifiques d'une demande de calcul de chemin et sont portées dans la demande. Des exemples de telles informations incluent les contraintes, les particularités, les stratégies de relaxation de contraintes et de particularités, et les fonctions d'optimisation. Les politiques spécifiques de la demande affectent directement le processus de choix du chemin parce que elles spécifient les liaisons, les nœuds, les segments de chemin, et/ou les chemins qui ne sont pas acceptables ou, au contraire, peuvent être désirables dans les chemins résultants.

o	Les politiques spécifiques du domaine opèrent sur l'identité du domaine dans lequel existe le PCC demandeur, et sur les identités des domaines à travers lesquels les chemins résultants sont acheminés. Ces politiques ont le même effet que les politiques spécifiques de l'utilisateur, à la différence près qu'elles peuvent être appliquées à un groupe d'utilisateurs plutôt qu'à un utilisateur individuel. Un exemple de politique spécifique de domaine est une restriction sur les informations que publie un PCE au sein d'un certain domaine. Dans un tel cas, les PCE dans certains domaines peuvent annoncer juste leur présence, tandis que d'autres peuvent annoncer des détails concernant leurs capacités, le processus d’authentification du client, et la disponibilité des ressources de calcul.

 	6.11.4	Relations à la signalisation
Quand un chemin pour un LSP inter domaines est calculé, il n'est pas obligatoire de considérer la politique du plan de signalisation. Cependant, manquer à le faire peut résulter en l'échec de l'établissement du LSP TE, ou à ce que moins de ressources soient allouées que prévu, résultant en un service dégradé. Donc, lorsque un PCE invoqué par un LSR d'extrémité de tête a de la visibilité sur d'autres domaines, il devrait être capable d'appliquer des considérations de politique au calcul et il devrait avoir connaissance des accords de politique inter domaines. Lorsque le calcul de chemin est le résultat d'une coopération entre des PCE, dont chacun est responsable d'un domaine particulier, les questions de politique devraient, lorsque possible, être résolues au moment du calcul afin que le LSP TE ait plus de chances d'être signalé avec succès. Dans ce contexte, une violation de la politique durant le calcul de LSP TE inter domaines peut conduire à une interruption du calcul de chemin, qui devrait être notifiée avec sa cause au demandeur.

 	6.12	Interactions indésirables
Il se peut que les communications de PCC à PCE (voir au paragraphe 6.6) soient utilement étendues au delà d'une simple interaction demande/réponse. Par exemple, le PCE et le PCC pourraient échanger leurs capacités en utilisant ce protocole. De plus, le protocole pourrait être utilisé pour collecter et rapporter des informations à l'appui d'un PCE à états pleins.

De plus, il peut arriver qu'un PCE soit capable de mettre à jour un chemin qu'il a calculé antérieurement (peut-être en réaction à un changement dans le réseau ou dans la politique) et dans ce cas la communication de PCE à PCC pourrait prendre en charge un message de calcul de chemin "non sollicité" pour fournir ce nouveau chemin au PCC. Noter cependant que cette fonction exigerait que le PCE conserve un enregistrement des calculs précédents et ait un déclenchement clair pour effectuer les nouveaux calculs. Le PCC devrait aussi être capable d'identifier le nouveau chemin avec l'ancien et de déterminer si il devrait agir sur le nouveau chemin. De plus, le PCC devrait être capable de rapporter le résultat de tels changements de chemin au PCE demandeur. Noter que l'interaction PCE-PCC n'est pas une interaction de gestion et que le PCC n'est pas obligé d'utiliser de chemin supplémentaire fourni par le PCE.

Ces fonctions tiennent aisément au sein de l'architecture décrite ici mais sont laissées pour être discutées plus en détails dans des documents d'exigences distincts.

 	6.13	Relations avec le retour de manivelle (Crankback)
L'acheminement par retour de manivelle (Crankback) est un mécanisme par lequel l'échec d'établissement d'un chemin ou l'échec d'un chemin existant peut être corrigé par un nouveau calcul de chemin et une nouvelle signalisation. L'acheminement par retour de manivelle s'appuie sur la distribution des informations de retour de manivelle avec la notification de l'échec, de sorte que le nouveau calcul peut être effectué en évitant le point d'échec ou de blocage.

Dans le contexte du PCE, les informations de retour de manivelle peuvent être passées à l’extrémité de tête où le processus de calcul et de signalisation peut être répété en utilisant la ressource en échec comme une exclusion dans le processus de calcul. Mais le retour de manivelle peut être utilisé pour tenter de corriger le problème à des points intermédiaires le long du chemin. De tels nœuds de recalcul de retour de manivelle vont très probablement être des frontières de domaine où le PCC a déjà invoqué un PCE. Donc, une défaillance au sein d'un domaine est rapportée à la frontière d'entrée du domaine, qui va tenter de calculer un autre chemin à travers le domaine. Faute de cela, le problème peut être rapporté au domaine précédent et communiqué à la frontière d'entrée de ce domaine, qui peut tenter de choisir un chemin qui a plus de chances de succès, soit en choisissant un point d'entrée différent dans le prochain domaine, soit en choisissant une route à travers un ensemble différent de domaines.

 	7.	Point de vue du client de calcul de chemin

La vue de l'architecture de PCE, et particulièrement du modèle fonctionnel, présente des différences avec la perspective du PCC. C'est en partie parce que le PCC a une connaissance limitée de la façon dont les PCE coopèrent pour répondre aux demandes, mais dépend plus du fait que le PCC est concerné par des questions différentes.

Le PCC s'intéresse à ce qui suit :

-	Choisir un PCE qui soit capable de fournir promptement un chemin calculé qui satisfasse aux contraintes fournies.

-	Combien de demandes de calcul le PCC devra t-il envoyer ? Le chemin désiré sera t-il calculé par le premier PCE contacté (éventuellement en coopération avec d'autres PCE) ou le PCC devra t-il consulter d'autres PCE pour remplir les trous du chemin ?

-	Combien d'autres calculs de chemin devront être produits du sein du réseau afin d'établir le LSP TE ?

Cette dernière question peut être considérée comme sortant du domaine d'application du LSR d'extrémité de tête, mais une importante contrainte que le PCC peut souhaiter appliquer est que le chemin devrait être calculé dans sa totalité et fourni sans bonds lâches ou nœuds abstraits non simples.

Donc, avec cette perspective limitée, le PCC va voir le calcul de chemin à plusieurs PCE (paragraphe 5.3) comme important et va distinguer deux sous cas. Le premier est montré à la Figure 3 avec des demandes de calcul suivantes faites par les autres PCC le long du chemin du LSP TE. Dans le second, plusieurs demandes de calcul sont produites par le LSR d'extrémité de tête. Par ailleurs, le PCC ne va pas savoir qu'il y a un calcul de chemin à plusieurs PCE avec une communication inter PCE (paragraphe 5.4) qu'il va percevoir comme non différent du cas du nœud PCE externe simple (paragraphe 5.2).

Le PCC va donc être très conscient qu'un modèle de PCE centralisé (paragraphe 6.1) peut encore exiger des calculs de chemin à plusieurs PCE avec les PCC d'extrémité de tête ou suivants obligés de produire d'autres demandes au PCE central. À l'inverse, le PCC peut être protégé contre le modèle de PCE réparti (paragraphe 6.2) parce que le premier PCE qu'il consulte utilise la communication inter PCE pour réaliser un résultat de calcul complet de sorte qu'aucune autre demande de calcul n'est requise.

Ces distinctions peuvent être complètement classées en déterminant si la réponse de calcul inclut tous les chemins nécessaires, et si ces chemins sont tout à fait explicites (c'est-à-dire, contiennent seulement des bonds stricts entre les nœuds abstraits simples).

 	8.	Métriques d'évaluation

La liste des métriques d'évaluation qui peuvent être utilisées pour évaluer l'efficacité et l'applicabilité de toute solution fondée sur le PCE figure ci-dessous. Noter que ces métriques ne sont pas utilisées pour déterminer les chemins, mais pour évaluer les solutions potentielles de l'architecture de PCE.

-	Optimalité : c'est la capacité à maximiser l'utilisation du réseau et à minimiser les coûts, en prenant en compte les objectifs de qualité de service, les multiples régions, et les couches du réseau. Noter que les modèles qui exigent l'implication à la suite de plusieurs PCE (par exemple, le modèle à plusieurs PCE décrit au paragraphe 5.3) peuvent créer des chemins en boucle si une politique attentive n'est pas appliquée.

-	Adaptabilité : ce sont les implications de l'acheminement, de la signalisation de LSP TE, et des frais généraux de communication de PCE, comme le nombre de messages et la taille des messages (incluant les LSA, les informations de retour de manivelle, les interrogations, les mécanismes de distribution, etc.).

-	Partage de charge : c'est la capacité de permettre que plusieurs PCE étalent la charge du calcul de chemin en permettant que plusieurs PCE prennent chacun la responsabilité d'un sous ensemble du total des demandes de calcul de chemin.

-	Multi-calcul de chemin : la capacité de calculer plusieurs chemins potentiellement divers pour satisfaire les besoins de partage de charge et de protection/restauration du trafic incluant la diversité et la protection de bout en bout au sein des domaines individuels.

-	Ré optimisation : la capacité d'effectuer la ré optimisation du chemin du LSP TE. Cela inclut aussi la capacité d'effectuer la corrélation inter couches quand on considère la ré optimisation à une couche spécifique.

-	Temps de calcul de chemin : le temps pour calculer les chemins individuels et plusieurs chemins divers et pour satisfaire les demandes de calcul de chemin en gros. (Noter que cette métrique ne peut être appliquée qu'aux problèmes qui ne sont pas NP complets.)

-	Stabilité du réseau : capacité de minimiser toute perturbation sur un état TE existant résultant du calcul et de l'établissement de nouveaux chemins TE.

-	Capacité à maintenir une synchronisation précise entre la TED et les états de la topologie et des ressources du réseau.

-	Vitesse de réalisation de la synchronisation de la TED.

-	Impact du processus de synchronisation sur les flux de données dans le réseau.

-	Capacité à traiter les situations où le PCE ne trouve pas de chemin satisfaisant un ensemble exigé de contraintes.

-	Politique : l'application d'une politique aux communications de PCC à PCE et de PCE à PCE ainsi qu'au calcul des chemins qui respectent les politiques d'établissement de LSP TE inter domaines.

Noter que d'autres métriques peuvent aussi être considérées. De telles métriques devraient être utilisées pour l'évaluation d'une architecture fondée sur le PCE particulière. Les compromis potentiels de l'optimisation de telles métriques devraient être évalués (par exemple, l'augmentation de l'optimalité du chemin va probablement avoir des conséquences sur le temps de calcul).

 	9.	Considérations sur la gestion

L'architecture de PCE introduit plusieurs éléments qui se prêtent à la gestion. Le PCE lui-même doit être géré, comme doivent l'être ses communications avec les PCC et les autres PCE. Le mécanisme par lequel les PCE et les PCC se découvrent les uns les autres est aussi un objet de gestion.

Beaucoup des questions de gestion sont déjà traitées dans les autres sections du document.

 	9.1	Contrôle de fonction et politique
Il doit être possible d'activer et désactiver la fonction de PCE à un PCE, et cela va conduire à ce que le PCE accepte, rejette, ou simplement ne reçoive pas les demandes provenant des PCC. La fermeture en douceur de la fonction de PCE devrait aussi être considérée afin que dans des circonstances contrôlées (comme la mise à niveau d'un logiciel) un PCE ne “disparaisse” pas d'un coup mais avertisse ses PCC et traite en douceur toutes les demandes de calcul en attente (peut être en les achevant, en les transmettant à un autre PCE, ou en les rejetant).

De même, il doit être possible de contrôler l'application de la politique au PCE par la configuration. Ce contrôle peut inclure de restreindre certaines fonctions ou algorithmes, la configuration des droits d'accès et priorités pour les PCC, et les relations avec les autres PCE à l'intérieur et à l'extérieur du domaine.

L'interface de configuration de la politique reste encore à déterminer. L'interface peut être une affaire purement locale, ou elle peut être prise en charge via une interface normalisée (comme un module de MIB).

 	9.2	Modèles d'informations et de données
Il est prévu que les opérations des PCE et des PCC vont être modélisées et contrôlées par les modules de MIB appropriés. Les tableaux des nouveaux modules de MIB devront refléter les relations entre les entités et contrôler et faire rapport sur les options configurables.

La collecte de statistiques va former une partie importante des opérations des PCE. L'opérateur doit être capable de déterminer l'historique des interactions d'un PCC avec ses PCE, les performances vues, et le taux de succès de ses demandes. De même, il est important qu'un opérateur soit capable d'inspecter un PCE et de déterminer sa charge et si un PCC individuel PCC est responsable d'une quantité disproportionnée de la charge. Il va aussi être important d'être capable d'enregistrer et inspecter les statistiques sur les communications entre PCC et PCE, incluant des questions comme les messages mal formés, les messages non autorisés, et les messages éliminés à cause d'encombrement. À cet égard, il y a un chevauchement clair entre gestion et sécurité.

Les statistiques pour l'architecture de PCE peuvent être rendues disponibles sur les tableaux appropriés dans les nouveaux modules de MIB.

Les nouveaux modules de MIB devraient aussi être utilisés pour fournir des notifications quand les seuils de clés sont franchis ou quand des événements importants se produisent. Un grand soin doit être apporté à s'assurer que le réseau n'est pas inondé par des notifications du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Donc, il peut être inapproprié de produire une notification chaque fois qu'un PCE reçoit une demande de calcul de chemin. En tous cas, un plein contrôle doit être fourni pour permettre de désactiver les notifications en utilisant, par exemple, les mécanismes définis dans le module de MIB SNMP-NOTIFICATION-MIB de la [RFC3413].

 	9.3	Détection et surveillance de vivacité
Le paragraphe 6.5 discute de l'importance qu'un PCC soit capable de détecter la vivacité d'un PCE. Les techniques de communications de PCE à PCC doit permettre à un PCC de déterminer la vivacité d'un PCE avant qu'il envoie une demande et dans la période entre l'envoi d'une demande et la réception d'une réponse.

Il est moins important pour un PCE de connaître la vivacité des PCC, et au sein du modèle simple de demande/réponse, ceci est seulement utile pour avoir une vue prévisionnelle de la charge probable d'un PCE à l'avenir, ou de permettre à un PCE d'abandonner le traitement d'une demande reçue.

 	9.4	Vérification de fonctionnement correct
Le fonctionnement correct de l'architecture de PCE peut être classé comme déterminant la connexité correcte de point à point entre les PCC et les PCE, et comme attestant la validité des chemins calculés. Le premier est un problème de sécurité qui peut être amélioré par l’authentification et surveillé par l'inscription des événements et leur enregistrement comme décrit au paragraphe 9.1. Ce peut aussi être un problème d'acheminement de s'assurer que la connexité PCC-PCE est possible.

Vérifier les chemins calculés est plus complexe. Les informations pour effectuer cette fonction peuvent cependant être rendues disponibles à l'opérateur par les tableaux de MIB, pourvu que soient conservés tous les enregistrements des contraintes passées sur la demande, le chemin calculé et fourni dans la réponse, et toutes les informations supplémentaires fournies par le PCE comme les politiques de relâchement de contraintes appliquées.

 	9.5	Exigences sur les autres protocoles et composants fonctionnels
Au stade de l'architecture, il est impossible de faire des déclarations définitives sur l'impact sur les autres protocoles et les composants fonctionnels car le travail de résolution n'a pas encore été achevé. Cependant, il est possible de faire quelques observations.

- Dépendance aux protocoles de transport sous-jacents
Les communications de PCE à PCC peuvent choisir d'utiliser les protocoles sous-jacents pour fournir des mécanismes de transport. Dans ce cas, certaines des considérations de gestion décrites dans les paragraphes précédents peuvent être appliquées à ces protocoles.

- Réutilisation des protocoles existants pour la découverte
Sans préjudice des exigences et solutions pour la découverte de PCE (voir au paragraphe 6.4) il est possible d'utiliser les protocoles existants pour faciliter cette fonction. Dans ce cas, certaines des considérations de gestion décrites dans les paragraphes précédents peuvent être appliquées à ces protocoles.

- Impact sur les LSR et la signalisation de LSP TE
Le principal exemple d'un PCC identifié dans cette architecture est un LSR MPLS ou GMPLS. Il faut donc prendre en considération la capacité de gérer les LSR et les contraintes supplémentaires de gestion applicables aux protocoles de signalisation de LSP TE.
En plus de permettre la gestion de PCC décrite dans les paragraphes précédents, un LSR doit être configurable à déterminer si il va utiliser un PCE distant, les options à utiliser dans l'acheminement bond par bond, ou si il fournit la fonction de PCE elle-même. Il va probablement être important d'être capable de distinguer au sein d'un LSR si la route utilisée pour un LSP TE a été fournie dans un message de signalisation provenant d'un autre LSR, par un opérateur, ou par un PCE, et, dans le cas où elle a été fournie dans un message de signalisation, si elle a été améliorée ou étendue par un PCE.

- Ré utilisation de modèles et mécanismes existants de politique
Comme les mécanismes de prise en charge de la politique peuvent être assez étendus, il vaut la peine de vérifier dans quelle mesure ce travail antérieur peut être appliqué au PCE. Ce désir de réutiliser des travaux antérieurs ne devrait pas être interprété comme l’exigence d'utiliser une solution ou protocole particulier.

 	9.6	Impact sur le fonctionnement du réseau
Cette architecture peut avoir deux impacts sur le fonctionnement d'un réseau. Elle augmente les temps d'établissement des LSP TE lorsque les demandes sont envoyées et traitées par un PCE distant, et elle peut causer de l'encombrement au sein du réseau si un nombre significatif de demandes de calcul sont produites sur une courte période. Ces questions sont les plus sévères dans les réseaux encombrés et après des défaillances de réseau, bien que l'effet puisse être atténué si les chemins de protection sont pré calculés ou si la charge du calcul de chemin est répartie entre un ensemble de PCE.

Les questions d'encombrement potentiel durant la récupération de défaillances peuvent être atténuées par l'utilisation de schémas de protection pré établis comme le réacheminement rapide.

Il est important que l'encombrement du réseau soit géré de façon pro active parce que il peut être impossible à gérer de façon réactive une fois que le réseau est encombré. Il devrait être possible à un opérateur de limiter le taux d'envoi des demandes qu'un PCC envoie à un PCE, et un PCE devrait être capable de rapporter la survenance d'encombrement (selon un seuil configuré) à la fois à l'opérateur et à ses PCC.

 	9.7	Autres considérations
Aucune autre considération de gestion n'a été identifiée.

 	10.	Considérations pour la sécurité

L'impact de l'utilisation d'une architecture fondée sur le PCE doit être considéré à la lumière de l'impact qu'elle a sur la sécurité des protocoles et techniques existants d'acheminement et de signalisation en usage au sein du réseau. L'impact a moins de chances d'être un problème dans le cas de l'usage intra domaine de PCE, mais une augmentation des flux d'informations en inter domaines et la facilitation de l'établissement de chemin inter domaines peut accroître la vulnérabilité à des attaques contre la sécurité.

D'une pertinence particulière sont les implications sur la confidentialité inhérentes à une architecture fondée sur le PCE pour les réseaux multi domaines. Il n'est pas nécessairement le cas qu'une solution de PCE multi domaines compromette la sécurité, mais les solutions DOIVENT examiner leurs effets dans ce domaine.

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

Noter que l'utilisation d'un PCE non local (c'est-à-dire, non co-résident avec le PCC) introduit des problèmes de sécurité supplémentaires. Les plus notables d'entre eux sont :
- l'interception des demandes ou réponses de PCE ;
- l'usurpation d'identité du PCE ou PCC ;
- la falsification des informations de TE, des informations de politique, ou des capacités du PCE ;
- les attaques de déni de service sur les PCE ou les mécanismes de communication de PCE.

On s'attend à ce que les solutions de PCE traitent ces problèmes en détail en utilisant les techniques d'authentification et de sécurité.

 	11.	Remerciements

Les auteurs tiennent à exprimer leurs chaleureux remerciements à (par ordre alphabétique) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, et Raymond Zhang pour leur relecture et leurs suggestions. Lou Berger a fourni des contributions précieuses et détaillées à la discussion de la politique dans le présent document.

Merci aussi à Pekka Savola, Russ Housley et Dave Kessens pour leur relecture et les discussions constructives durant les étapes finales de la publication.

 	12.	Références pour information

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

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

[RFC3413]	D. Levi, P. Meyer et B. Stewart, "Applications du protocole simple de gestion de réseau (SNMP)", STD  62, décembre  2002.

[RFC3473]	L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151, 6780))

[RFC3630]	D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 2003.

[RFC3784]	H. Smit, T. Li, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l'ingénierie du trafic (TE)", juin  2004. (Obsolète, voir RFC5305) (MàJ par RFC4205) (Information)

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

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

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

[RFC4364]	E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)

[RFC5212]	K. Shiomoto et autres, "Exigences pour les réseaux multi régions et multi couches (MRN/MLN) fondés sur GMPLS", juillet  2008. (Information)

 	Adresse des auteurs

Adrian Farrel	Jean-Philippe Vasseur	Jerry Ash	
Old Dog Consulting	1414 Massachussetts Avenue	AT&T	
mél : adrian@olddog.co.uk 	Boxborough, MA 01719	Room MT D5-2A01	
	USA	200 Laurel Avenue	
	mél : jpv@cisco.com 	Middletown, NJ 07748,	
		USA	
		téléphone : (732)-420-4578	
		Fax :   (732)-368-8659	

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