Groupe de travail Réseau	J.L. Le Roux, éditeur	
Request for Comments : 4674	France Telecom	
Catégorie : Information	octobre 2006	
Traduction Claude Brière de L'Isle		

Exigences pour la découverte d'élément de calcul de chemin (PCE)

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

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

Résumé
Ce document présente un ensemble d'exigences du mécanisme de découverte d'élément de calcul de chemin (PCE, Path Computation Element) qui permettrait à un client de calcul de chemin (PCC, Path Computation Client) de découvrir de façon dynamique et automatique un ensemble de PCE ainsi que certaines informations pertinentes pour le choix de PCE. Il est prévu que les solutions qui spécifient les procédures et les protocoles ou extensions aux protocoles existants pour une telle découverte de PCE satisfassent à ces exigences.

Table des Matières
1.	Introduction
1.1	Conventions utilisées dans le présent document
1.2	Terminologie
2.	Position du problème et généralités sur les exigences
2.1	Position du problème
2.2	Généralités sur les exigences
3.	Exemple de scénario d'application
4.	Exigences détaillées
4.1	Informations de PCE à divulguer
4.1.1	Informations générales de PCE (prise en charge obligatoire)
4.1.2	Informations détaillées de PCE (prise en charge facultative)
4.2	Portée de la découverte de PCE
4.2.1	Exigences spécifiques inter-AS
4.3	Synchronisation des informations de PCE
4.4	Découverte de la désactivation de PCE
4.5	Politiques de prise en charge
4.6	Exigences pour la sécurité
4.7	Extensibilité
4.8.	Adaptabilité
4.9	Ordres de grandeur pour la gestion
4.10	Considérations pour la gestion
4.10.1	Configuration des paramètres de découverte de PCE
4.10.2	Modules de MIB de découverte de PCE
4.10.3	Surveillance du fonctionnement du protocole
4.10.4	Impact sur le fonctionnement du réseau
5.	Considérations pour la sécurité
6.	Remerciements
7.	Contributeurs
8.	Références

1.	Introduction

L'architecture de réseau fondée sur PCE [RFC4655] définit un élément de calcul de chemin (PCE, Path Computation Element) comme une entité capable de calculer les chemins TE-LSP sur la base d'un graphe de réseau, et en appliquant des contraintes de calcul. Un PCE sert les demandes de calcul de chemin envoyées par des clients de calcul de chemin (PCC, Path Computation Clients).

Un PCC est une application client qui demande qu'un calcul de chemin soit effectué par un PCE. Cela peut être, par exemple, un LSR qui demande un chemin pour un TE-LSP pour lequel il est la tête d'extrémité, ou un PCE qui demande un calcul de chemin avec un autre PCE (communication inter-PCE). La communication entre un PCC et un PCE exige un protocole client-serveur dont les exigences génériques sont énumérées dans la [RFC4657].

L'architecture fondée sur PCE exige qu'un PCC soit averti de la localisation d'un ou plusieurs PCE dans son domaine, et aussi potentiellement de quelques PCE dans d'autres domaines, par exemple, en cas de calcul de chemin inter domaine.

Dans ce contexte, il serait très souhaitable de définir un mécanisme de découverte automatique et dynamique de PCE, qui permettrait aux PCC de découvrir automatiquement un ensemble de PCE, de déterminer les informations supplémentaires nécessaires au choix du PCE, et de détecter de façon dynamique les nouveaux PCE ou toute modification des informations des PCE. Cela comporte la découverte par un PCC d'un ensemble d'un ou plusieurs PCE dans son domaine, et potentiellement dans d'autres domaines. Cette dernière est une fonction utile par exemple dans le cas d'un calcul de chemin inter domaine.

Le présent document fait la liste d'un ensemble d'exigences fonctionnelles pour un tel mécanisme de découverte automatique et dynamique de PCE. La Section 2 établit la position du problème. La Section 3 illustre un scénario d'application. Enfin la Section 4 traite des exigences détaillées.

Il est prévu que les solutions qui spécifient les procédures et protocoles ou extensions de protocole pour la découverte de PCE satisfassent à ces exigences. Il n'est pas prévu de spécifier des exigences spécifiques d'une solution ou de faire d'hypothèses sur les protocoles qui pourraient être utilisés pour la découverte.

Noter que les exigences énumérées dans le présent document s'appliquent également aux PCE qui sont capables de calculer des chemins dans les réseaux à capacité MPLS-TE et aux PCE qui sont capables de calculer des chemins dans des réseaux à capacité GMPLS (et les PCE capables des deux).

Il est aussi important de noter que la notion de PCC englobe celle d'un PCE qui agit comme PCC lorsqu'il demande un calcul de chemin à un autre PCE (communication inter-PCE). Et donc, le présent document ne fait aucune distinction entre la découverte de PCE par les PCC et la découverte de PCE par les PCE.

1.1	Conventions utilisées dans le présent document

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le .BCP 14, RFC 2119.

1.2	Terminologie

Terminologie utilisée dans le présent document :

LSR (Label Switch Router) :  routeur à commutation d'étiquette.

TE-LSP (Traffic Engineered Label Switched Path) : chemin à commutation d'étiquettes pour l'ingénierie de trafic

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 sur le réseau sur la base d'un graphe du réseau, et d'appliques des contraintes de calcul.

PCC (Path Computation Client) : client de calcul de chemin. Toute application cliente qui demande à un élément de calcul de chemin d'effectuer un calcul de chemin.

Zone IGP (de protocole de routeur intérieur) (IGP, Interior Gateway Protocol) : zone OSPF ou niveau/zone ISIS.

ABR (Area Border Router) IGP : protocole de routeur intérieur pour un routeur de zone frontière (routeur OSPF ABR ou ISIS L1L2).

AS (Autonomous System) : système autonome.

ASBR (AS Border Router) : routeur frontière de système autonome

TE-LSP intra-zone : un TE-LSP dont le chemin ne franchit pas les frontières de zone IGP.

TE-LSP interzone : un TE-LSP dont le chemin transite à travers deux zones IGP ou plus.

TE-LSP MPLS inter AS : TE-LSP en commutation multi protocolaire par étiquetage dont le chemin transite à travers deux ou plusieurs AS ou sous-AS (confédérations de BGP).

Domaine : Toute collection d'éléments de réseau au sein d'une sphère commune de gestion d'adresse ou de responsabilité de calcul de chemin. Comme exemples de domaine figurent les zones IGP et les systèmes autonomes.

2.	Position du problème et généralités sur les exigences
2.1	Position du problème

Un domaine d'acheminement peut, en pratique, contenir plusieurs PCE :

-	La charge du calcul du chemin peut être équilibrée entre un ensemble de PCE pour améliorer la modularité.
-	Pour les besoins de redondance, les PCE principaux et de sauvegarde peuvent être utilisés.
-	Les PCE peuvent avoir des capacités de calcul de chemin distinctes (calcul de chemin multi contraintes, calcul de chemin de secours, etc.).
-	Dans un contexte inter domaine, il peut y avoir plusieurs PCE avec des fonctions inter domaine distinctes (interzone, inter AS, inter-couche), chaque PCE étant chargé du calcul de chemin dans un ou plusieurs domaines.

Pour permettre un choix efficace de PCE par les PCC, c'est-à-dire, de choisir le PCE approprié sur la base des ses capacités et d'effectuer un équilibrage de charge efficace des demandes, un PCC a besoin de connaître la localisation des PCE dans son domaine, ainsi que des informations pertinentes pour les choix du PCE, et il a aussi éventuellement besoin de connaître la localisation de certains PCE dans d'autres domaines, pour les besoins du calcul des chemins inter domaines.

De telles informations de PCE pourraient être acquises par une configuration manuelle, sur chaque PCC, de l'ensemble des PCE avec leurs capacités. Une telle approche de configuration manuelle pourrait être suffisante, et même souhaitable dans certaines situations particulières (par exemple, de découverte de PCE inter AS, où la configuration manuelle des PCE voisins peut être préférée pour des raisons de sécurité), mais elle se heurte manifestement à plusieurs limitations :

-	Cela peut impliquer une surcharge de configuration substantielle.
-	Cela ne permettrait pas à un PCC de détecter de façon dynamique qu'un nouveau PCE est disponible, qu'un PCE existant n'est plus disponible, ou qu'il y a eu un changement des informations d'un PCE.

De plus, comme avec toute approche de configuration manuelle, il y a un risque d'erreur de configuration.
À titre d'exemple, dans un réseau multi zones constitué d'une zone cœur de réseau et de N zones périphériques, et où le calcul de chemin MPLS-TE inter zone s'appuie sur un calcul de chemin à plusieurs PCE avec des ABR qui agissent comme PCE, la zone cœur de réseau comprendrait au moins N PCE, et la configuration de PCC serait trop lourde (par exemple, dans les réseaux multi zones existants, N peut dépasser cinquante).

Et donc, un mécanisme automatique de découverte de PCE permettant à un PCC de découvrir de façon dynamique un ensemble de PCE est très souhaitable.

2.2	Généralités sur les exigences

Un mécanisme de découverte de PCE qui satisfait aux exigences du présent document DOIT permettre à un PCC de découvrir automatiquement la localisation d'un ou plusieurs PCE dans son domaine.

Lorsque le calcul de chemin inter domaine est nécessaire et que la politique le permet, la méthode de découverte de PCE DOIT permettre à un PCC de découvrir automatiquement la localisation des PCE dans les autres domaines qui peuvent aider au calcul de chemin inter domaine.

Un mécanisme de découverte de PCE DOIT permettre à un PCC de découvrir l'ensemble de ou des domaines où un PCE a la visibilité de la topologie d'ingénierie du trafic et peut calculer les chemins. Il DOIT aussi permettre la découverte des fonctions éventuelles de calcul de chemin inter domaine d'un PCE (inter zone, inter AS, inter couche, etc.).

Un mécanisme de découverte de PCE DOIT permettre le contrôle de la portée de la découverte, c'est à dire l'ensemble du ou des domaines (zones, AS) où des informations se rapportant à un PCE donné doivent être découvertes.

Un mécanisme de découverte de PCE DOIT permettre aux PCC dans un périmètre de découverte donné de découvrir de façon dynamique qu'un nouveau PCE est apparu ou qu'il y a eu un changement des informations d'un PCE.

Un mécanisme de découverte de PCE DOIT permettre aux PCC de découvrir dynamiquement qu'un PCE n'est plus disponible.

Un mécanisme de découverte de PCE DOIT prendre en charge les procédures de sécurité. En particulier, une considération particulière DOIT apportée à la façon d'établir un modèle de confiance pour la découverte de PCE.

FACULTATIVEMENT, un mécanisme de découverte de PCE PEUT être utilisé de façon à divulguer un ensemble de capacités de PCE détaillées afin que le PCC puisse faire des choix élaborés et en connaissance de cause sur le PCE à utiliser.
3.	Exemple de scénario d'application

AS1

AS2

Zone 1

Zone 0

Zone 2

R1

R3

R5

R6

R9

R11

R13

R2

R4

R7

R8

R10

R12

R14

S1

Figure 1

La Figure 1 illustre un réseau multi zone/AS avec plusieurs PCE :
-	L'ABR R3 est un PCE qui peut prendre part au calcul de chemin inter zone. Il peut calculer des chemins dans la zone 1 et la zone 0.
-	L'ABR R6 est un PCE qui peut prendre part au calcul de chemin inter zone. Il peut calculer des chemins dans la zone 0 et la zone 2.
-	L'ASBR R9 est un PCE qui peut prendre part au calcul de chemin inter AS Il est chargé du calcul de chemin dans l'AS1 vers l'AS2.
-	L'ASBR R12 est un PCE qui peut prendre part au calcul de chemin inter AS Il est chargé du calcul de chemin dans l'AS2 vers l'AS1.
-	Le serveur S1 est un PCE qui peut être utilisé pour calculer divers chemins et chemins de secours dans la zone 1.

En satisfaisant les exigences établies dans le présent document, le mécanisme de découverte de PCE permettra :

-	à chaque PCC dans les zones 1 et 0 de découvrir de façon dynamique R3, comme PCE pour un calcul de chemin inter zone, et que R3 peut calculer les chemins dans les zones 0 et 1.
-	chaque PCC dans les zones 0 et 2 de découvrir de façon dynamique R6, comme PCE pour un calcul de chemin inter zone, et que R6 peut calculer les chemins dans la zone 2 et la zone 0.
-	chaque PCC dans AS1 et un ou plusieurs PCC dans AS2 de découvrit de façon  dynamique R9 comme PCE pour le calcul de chemin inter AS dans AS1 vers AS2.
-	chaque PCC dans AS2 et un ou plusieurs PCC dans AS1 de découvrir de façon dynamique R12 comme PCE pour le calcul de chemin inter AS dans AS2 vers AS1.
-	chaque PCC dans la zone 1 de découvrir de façon dynamique S1, comme PCE pour le calcul de chemin intra zone ans la zone 1, et facultativement de découvrir ses capacités de calcul de chemin (calcul d'autre chemin et calcul de chemin de secours).

4.	Exigences détaillées
4.1	Informations de PCE à divulguer

On distingue deux niveaux d'informations de PCE à divulguer par un mécanisme de découverte de PCE:

-	Informations générales. La divulgation DOIT être prise en charge par le mécanisme de découverte de PCE.
-	Informations détaillées. La divulgation PEUT être prise en charge par le mécanisme de découverte de PCE.

Le mécanisme de découverte de PCE DOIT permettre la divulgation des informations générales de PCE qui vont permettre aux PCC de choisir les PCE appropriés. Cela comporte la découverte de la localisation de PCE, les domaines de PCE pris en charge par les PCE, et les fonctions inter domaine des PCE.

Le mécanisme de découverte de PCE PEUT aussi permettre la divulgation des informations détaillées de PCE. Cela comprend des informations ou toutes les informations sur les capacités de calcul de chemin du PCE et des PCE de remplacement. Ces informations ne font pas partie de la découverte de PCE ; ce sont des informations supplémentaires qui peuvent faciliter le choix d'un PCE par un PCC. La prise en charge de l'échange de ces informations est facultative dans le contexte du mécanisme de découverte de PCE lui-même. Cela ne signifie pas que la disponibilité de ces informations soit facultative dans l'architecture fondée sur le PCE, mais que de telles informations pourraient aussi être obtenues par d'autres mécanismes, tels que le protocole de communication de PCC à PCE.

4.1.1	Informations générales de PCE (prise en charge obligatoire)

4.1.1.1	Découverte de la localisation de PCE
Le mécanisme de découverte de PCE DOIT permettre la découverte, pour un PCE donné de l'adresse IPv4 et/ou IPv6 à utiliser pour atteindre le PCE. Cette adresse sera normalement une adresse qui est toujours joignable, si il y a une connexité avec le PCE.

Cette adresse sera utilisée par les PCC pour communiquer avec un PCE, à travers un protocole de communication de PCC à PCE.

4.1.1.2	Découverte des fonctions de domaine et inter domaine de PCE
Le calcul de chemin inter domaine est une application clé de l'architecture fondée sur le PCE. Elle peut s'appuyer sur un calcul de chemin à plusieurs PCE, où les PCE de chaque domaine calculent une partie du chemin de bout en bout et collaborent tous ensemble à trouver le chemin complet d'une extrémité à l'autre. Le calcul de chemin inter domaine peut aussi s'appuyer sur un calcul de chemin par un seul PCE dans lequel un PCE à la visibilité sur l'intérieur de plusieurs domaines et peut calculer un chemin d'extrémité à extrémité complet (c'est-à-dire, un chemin depuis l'extrémité de tête du TE-LSP inter domaine jusqu'à l'extrémité de fin du TE-LSP inter domaine).

Et donc, le mécanisme de découverte de PCE DOIT permettre la découverte de l'ensemble de un ou plusieurs domaines où un PCE a de la visibilité et peut calculer les chemins. Ces domaines pourraient être identifiés en utilisant un identifiant de domaine : par exemple, un zone IGP peut être identifiée par l'identifiant de zone (OSPF ou ISIS), et une AS peut être identifiée par le numéro d'AS.

Le mécanisme de découverte de PCE DOIT aussi permettre la découverte des fonctions inter domaine d'un PCE, c'est-à-dire, si un PCE peut être utilisé pour calculer ou prendre part au calcul des chemins de bout en bout à travers les frontières de domaine. Les fonctions inter domaine incluent de façon non exhaustive le calcul de chemin interzone, inter AS et inter couche. Noter que ces fonctions ne sont pas mutuellement exclusives.

Noter que les fonctions inter domaine ne sont pas nécessairement déduites de l'ensemble de domaines sur lequel un PCE a de la visibilité. Par exemple, un PCE peut avoir une visibilité limitée à un seul domaine, mais peut être capable de prendre part au calcul de chemins inter domaine en collaboration avec les PCE d'autres domaines. À l'inverse, une PCE peut avoir de la visibilité sur plusieurs domaines, mais l'opérateur ne veut pats que le PCE soit utilisé pour les calculs de chemins inter domaine.

Le mécanisme de découverte de PCE DOIT permettre aussi de découvrir l'ensemble d'un ou plusieurs domaines vers lesquels un PCE peut calculer des chemins. Par exemple, dans un contexte de calcule de chemin inter AS, il peut y avoir plusieurs PCE dans une AS, chacun étant chargé de prendre part au calcul des chemins inter AS vers un ensemble d'une ou plusieurs AS de destination, et un PCC peut avoir à découvrir les AS de destination dont chaque PCE est chargé.

4.1.2	Informations détaillées de PCE (prise en charge facultative)

4.1.2.1	Découverte des capacités de PCE
Dans le cas où il y a plusieurs PCE avec des capacités disponibles distinctes, un PCC a à choisir un ou plusieurs PCE appropriés.

À cette fin, le mécanisme de découverte de PCE PEUT prendre en charge la divulgations de certaines capacités détaillées de PCE.

Pour illustrer ce propos, cela pourrait inclure les capacités de PCE suivantes qui se rapportent au calcul de chemin :
-	Les contraintes de liaison prises en charge : par exemple, bande passante, affinités.
-	Les contraintes de chemin prises en charge : coût IGP/TE maximum, compte de bond maximum.
-	Les fonctions objectives prises en charge : par exemple, plus court chemin, chemin le plus large.
-	La capacité à calculer plusieurs chemins corrélés : par exemple, chemins divers, chemins à charge équilibrée.
-	La capacité à calculer des chemins bidirectionnels.
-	Les contraintes spécifiques de la technologie GLMPS prises en charge : par exemple, les capacités de commutation d'interface prises en charge, les types de codage.

Et cela pourrait aussi inclure certaines capacités spécifiques de PCE :
-	La capacité à traiter les priorités de demandes.
-	La taille maximum d'un message de demande.
-	Le nombre maximum de demandes de chemin dans un message de demande.
-	La puissance de calcul du PCE (paramètres statiques à utiliser pour l'équilibrage de charge pondéré des demandes).

De telles informations concernant les capacités de PCE pourraient alors être utilisées par un PCC pour choisir un PCE approprié sur une liste de PCE candidats.

Noter que la définition exacte et la description des capacités des PCE sortent du domaine d'application du présent document. Il est prévu que ce soit décrit dans un ou plusieurs documents distincts qui pourraient être spécifiques de l'application.

4.1.2.2	Découverte des PCE de remplacement
En cas de défaillance d'un PCE, un PCC doit en choisir un autre, s'il en est de disponible. Il peut être utile dans diverses situations qu'un PCE indique un ensemble de un ou plusieurs PCE de remplacement qui puissent être choisis en cas de défaillance du PCE en cause.

Et donc, le mécanisme de découverte de PCE PEUT permettre la découverte, pour un PCE donné, de la localisation d'un ou  plusieurs des PCE de remplacement alloués.

Le mécanisme de découverte de PCE PEUT aussi permettre la découverte, pour un PCE donné, de l'ensemble de un ou plusieurs PCE pour lesquels il agit comme PCE de remplacement.

4.2	Portée de la découverte de PCE

Le mécanisme de découverte de PCE DOIT permettre le contrôle de la portée de la divulgation des informations de PCE PCE par PCE. En d'autres termes, il DOIT permettre de contrôler à quel PCC ou groupe de PCC les informations se rapportant à un PCE peuvent être divulguées.

Le choix de la portée de la découverte d'un PCE donné DOIT inclure au moins les réglages suivants :
-	Tous les PCC dans une seule zone IGP.
-	Tous les PCC dans un ensemble de zones IGP adjacentes.
-	Tous les PCC dans une seule AS.
-	Tous les PCC dans un ensemble d'AS.
-	Un ensemble d'un ou plusieurs PCC dans un ensemble d'une ou plusieurs AS.

En particulier, cela implique aussi que le mécanisme de découverte de PCE DOIT permettre la découverte des informations de PCE à travers les zones IGP et à travers les frontières d'AS.

La portée de la découverte DOIT être configurable PCE par PCE.

Il DOIT être possible de désactiver la découverte de PCE PCE par PCE.

4.2.1	Exigences spécifiques inter AS
Lorsqu'on utilise une approche fondée sur le PCE pour le calcul de chemin inter AS, un PCC dans une AS peut avoir besoin d'acquérir des informations au sujet des PCE à capacité inter AS localisés dans d'autres AS. À cette fin, et comme souligné au paragraphe précédent, le mécanisme de découverte de PCE DOIT permettre la divulgation des informations qui se rapportent aux PCE à capacité inter AS à travers les frontières d'AS.

Une telle découverte de PCE inter AS doit être contrôlée avec soin. Pour des raisons de sécurité et de confidentialité, en particulier dans un contexte inter fournisseur, le mécanisme de découverte DOIT permettre de limiter la portée de la découverte à un ensemble d'AS et DOIT aussi fournir le contrôle des informations de PCE à divulguer à travers les AS. On le réalise en appliquent des politiques (voir aussi le paragraphe 4.4). Cela implique la capacité de contenir une annonce de PCE à un ensemble restreint d'une ou plusieurs AS, et de filtrer et traduire tout paramètre de PCE (domaines de PCE, fonctions inter domaine de PCE, capacités de PCE, etc.) dans les divulgations qui traversent les frontières d'une AS. Pour illustrer notre propos, il peut être utile de divulguer localement des informations détaillées de PCE (telles que les capacités détaillées) dans l'AS du PCE, mais seulement des informations générales (comme la localisation et les domaines pris en charge) dans les autres AS.

4.3	Synchronisation des informations de PCE

Le mécanisme de découverte de PCE DOIT permettre à un PCC de découvrir tout changement des informations qui se rapportent à un PCE qu'il découvert précédemment. Cela inclut les changements aussi bien aux informations générales (par exemple, un changement des domaines pris en charge par le PCE) qu'aux informations détaillées si elles sont couvertes (par exemple, une modification des capacités du PCE).

De plus, le mécanisme de découverte de PCE DOIT permettre la découverte dynamique de nouveaux PCE dans une portée de découverte donnée.

Noter qu'il n'est pas exigé une détection en temps réel de ces changements ; le mécanisme de découverte de PCE DEVRAIT plutôt permettre la découverte de ces changements dans un délai de 60 secondes, et l'opérateur devrait avoir la capacité de configurer le délai de découverte.

Noter que les informations de PCE sont relativement statiques et on s'attend à ce qu'elles soient relativement stables et ne changent pas fréquemment.

4.4	Découverte de la désactivation de PCE

Le mécanisme de découverte de PCE DOIT permettre à un PCC de découvrir quand un PCE qui a été découvert précédemment n'est plus en vie ou est désactivé. Cela peut aider à réduire ou éviter une interruption de service de calcul de chemin.

Noter qu'il n'est pas exigé que la détection d'une défaillance/désactivation de PCE se fasse en temps réel ; le mécanisme de découverte de PCE DEVRAIT plutôt permettre qu'une telle découverte survienne dans un délai de 60 secondes, et l'opérateur devrait avoir la capacité de configurer le délai de découverte.

4.5	Politiques de prise en charge

Le mécanisme de découverte de PCE DOIT permettre aux politiques de restreindre la portée de découverte à un ensemble de domaines autorisés, pour contrôler et restreindre le type et la nature des informations à divulguer, et aussi de filtrer et traduire certaines informations aux frontières des domaines. Il DOIT être possible d'appliquer ces politiques PCE par PCE.

Noter que les mécanismes de découverte DOIVENT permettre de divulguer les informations de politique de façon à contrôler les politiques de divulgation aux frontières de domaine.

Il DOIT aussi être possible d'appliquer des politiques différentes lors de la divulgation d'informations de PCE à des domaines différents.

4.6	Exigences pour la sécurité

Les cinq menaces majeures qui se rapportent aux mécanismes de découverte de PCE sont :
-	l'usurpation d'identité d'un PCE ;
-	l'interception des informations de découverte de PCE (reniflage) ;
-	falsification de découverte de PCE information ;
-	divulgation d'informations à des PCC non autorisés (mystification de PCC) ;
-	attaques de déni de service (DoS).

Noter que la sécurité des procédures de découverte de PCE est d'une importance particulière dans un contexte inter AS, où la découverte de PCE peut augmenter la vulnérabilité aux attaques et les conséquences de ces attaques.

Et donc, les mécanismes DOIVENT être définis pour assurer l'authenticité, l'intégrité, la confidentialité, et la maîtrise des informations de découverte de PCE :
-	Il DOIT y avoir un mécanisme pour authentifier les informations de découverte.
-	Il DOIT y avoir un mécanisme pour vérifier l'intégrité des informations de découverte.
-	Il DOIT y avoir un mécanisme de chiffrement des informations de découverte.
-	Il DOIT y avoir un mécanisme pour restreindre la portée de la découverte à un ensemble de PCC autorisés et pour filtrer les informations de PCE divulguées aux frontières de domaine (comme défini au paragraphe 4.5).

Un PCE et un PCC DOIVENT être identifiés par un identifiant unique au monde, qui peut, par exemple, être une combinaison de numéros d'AS et d'adresse IP.

Des mécanismes DOIVENT être définis afin de limiter l'impact d'une attaque de déni de service sur la procédure de découverte de PCE (par exemple, filtrer des changements excessifs d'informations de PCE et de PCE défaillants). Noter aussi que les attaques de DoS peuvent être accidentelles (causées par le mauvais comportement d'un système de PCE) ou intentionnelles. Comme exposé dans la [RFC4657], de tels mécanismes peuvent comporter le filtrage de paquets, la limitation du débit, pas d'écoute de proximité, et lorsque c'est possible, l'utilisation d'espaces d'adresses privés.

Une considération attentive DOIT aussi être apportée à la façon d'établir un modèle de confiance pour la découverte de PCE. Le mécanisme de découverte de PCE DOIT explicitement prendre en charge un ensemble spécifique d'un ou plusieurs modèles de confiance.

4.7	Extensibilité

Le mécanisme de découverte de PCE DOIT être souple et extensible de façon à permettre facilement l'inclusion d'informations de PCE supplémentaires qui pourraient être définies à l'avenir.

4.8.	Adaptabilité

Le mécanisme de découverte de PCE DOIT être conçu de façon à bien s'adapter à un accroissement de l'un des paramètres suivants :
-	Nombre des PCC qui découvrent un PCE donné.
-	Nombre des PCE à découvrir par u PCC donné.
-	Nombre de domaines dans la portée de découverte.

Le mécanisme de découverte de PCE NE DOIT PAS avoir un effet contraire sur les performances des autres protocoles (en particulier d'acheminement et de signalisation) qui fonctionnent déjà sur le réseau.

Noter qu'il n'y a pas d'exigence d'adaptabilité par rapport à la quantité des informations à échanger.

Les informations divulguées dans le mécanisme de découverte de PCE sont relativement statiques. Les changements des informations de PCE peuvent survenir par suite d'une mise à jour de configuration de PCE, de déploiement/activation de PCE, ou de désactivation/suppression de PCE, et ne devraient pas survenir par suite de l'activité du PCE lui-même. Et donc, ces informations sont assez stables et ne changeront pas fréquemment.

4.9	Ordres de grandeur pour la gestion

Ce paragraphe donne les estimations d'ordre de grandeur minimum de ce que le mécanisme de découverte de PCE devrait prendre en charge :
-	Nombre de PCC découvrant un PCE donné : 1000
-	Nombre de PCE à découvrir par un PCC donné : 100

4.10	Considérations pour la gestion

Il est EXIGÉ que les mécanismes gèrent les opérations de découverte de PCE. Cela inclut la configuration des fonctions et politiques de découverte de PCE, ainsi que la surveillance de l'activité du protocole de découverte.

4.10.1	Configuration des paramètres de découverte de PCE
Il DOIT être possible d'activer et de désactiver la fonction de découverte de PCE à un PCC et à un PCE.

Sur le PCC, il DOIT être possible à un opérateur d'activer/désactiver la découverte de PCE automatique. L'activation de la découverte automatique NE DOIT PAS empêcher la configuration statique des information de PCE qui peut compléter les informations découvertes.

Au PCE, il DOIT être possible à un opérateur de contrôler l'application des politiques de découverte par lesquelles le PCE spécifique est découvert. Comme décrit au paragraphe 4.5, ce contrôle DOIT inclure la capacité à
- restreindre la portée de découverte à un ensemble de domaines autorisés ;
- définir le type et la nature des informations divulguées ;
- spécifier le filtrage et la traduction à appliquer aux informations de PCE divulguées au frontières de domaine.

Ces options de configuration PEUVENT être prises en charge à travers une interface de configuration locale spécifique de la mise en œuvre, ou PEUVENT être prises en charge via une interface normalisée (telle qu'un module de MIB, comme ci-dessous).

4.10.2	Modules de MIB de découverte de PCE
Les modules de MIB de découverte de PCE DOIVENT être spécifiés pour le contrôle de la fonction sur les PCC et les PCE.

4.10.2.1	Module MIB de PCC
Le module de MIB qui fonctionnera sur les PCC DOIT comporter au moins ce qui suit :
-	Une commande pour désactiver la découverte automatique par le PCC,
-	L'ensemble des PCE connus,
-	Le nombre de PCE connus, et le nombre de PCE découverts.

Pour chaque PCE rapporté dans le module de MIB, les informations suivantes DOIVENT être disponibles :
-	Les informations annoncées par le PCE (c'est-à-dire, les informations découvertes),
-	les informations configurées localement au sujet du PCE,
-	Le temps écoulé depuis la découverte du PCE,
-	Le temps écoulé depuis le dernier changement des informations découvertes pour le PCE.

Noter que lorsque un PCE n'est plus en vie (voir au paragraphe 4.4), il NE DEVRAIT PLUS être rapporté dans le module de MIB du PCC.

Le module de MIB DEVRAIT aussi fournir les taux moyens et maximum d'arrivée, de départ et de modification de découverte de PCE pour permettre une analyse efficace du fonctionnement des protocoles. De plus, le,module de MIB DEVRAIT faire rapport sur le fonctionnement du protocole de découverte en comptant le nombre d'échanges d'informations inacceptables et incompréhensibles.

Le module de MIB de PCC DEVRAIT aussi être utilisé pour fournir des notifications lors du franchissement de seuils (par exemple, du taux de changements maximum , du nombre de messages inacceptables) ou lorsque surviennent des événements importants (par exemple, le nombre de PCE découverts descend à zéro).

4.10.2.2	Module MIB de PCE
Le module de MIB qui fonctionnera sur les PCE DOIT inclure au moins
-	une commande pour désactiver les annonces de découverte automatiques par le PCE ;
-	les informations à annoncer par le PCE, bien que ces informations PUISSENT être présentes en lecture seule ;
-	les politiques de découverte actives sur le PCE, bien que ces informations PUISSENT être présentes en lecture seule.

Le module de MIB DEVRAIT aussi inclure
-	le temps écoulé depuis le dernier changement des informations de PCE annoncées ;
-	le temps écoulé depuis le dernier changement des politiques d'annonce ;
-	le contrôle des interfaces sur lesquelles le PCE produit les annonces lorsque c'est applicable à la solution de protocole choisie.

Noter qu'un PCE PEUT aussi être configuré pour découvrir d'autres PCE. Dans ce cas, il DEVRAIT fonctionner avec le module de MIB décrit au paragraphe 4.10.2.1 aussi bien qu'avec le module décrit ici.

4.10.3	Surveillance du fonctionnement du protocole
Il DOIT être possible de surveiller le fonctionnement de tout protocole de découverte de PCE. Lorsque un protocole existant est utilisé pour prendre en charge la fonction de découverte de PCE, cette surveillance DEVRAIT être réalisée en utilisant les techniques déjà définies pour ce protocole, amélioré par les modules de MIB décrits ci-dessus. Lorsque ces techniques sont inadéquates, de nouvelles techniques DOIVENT être développées.

La surveillance du fonctionnement du protocole requiert la prise en charge d'au moins les fonctions suivantes :
-	Corrélation des informations annoncées avec les informations reçues.
-	Compte des éléments d'information abandonnées, corrompus, et rejetés.
-	Détection des réseaux 'segmentés', c'est-à-dire, la capacité à détecter et diagnostiquer la défaillance d'une annonce de PCE à atteindre un PCC.

4.10.4	Impact sur le fonctionnement du réseau
Des changements fréquents des information de PCE peuvent avoir un impact significatif sur les PCC qui reçoivent les annonces, peuvent déstabiliser le fonctionnement du réseau en amenant les PCC à échanger les PCE, et peut causer des dommages au réseau par un trafic d'annonces excessif. Et donc, il DOIT être possible d'appliquer au moins les contrôles suivants :
-	des limites configurables au débit des annonces de changement de paramètres d'un PCE,
-	le contrôle de l'impact sur les PCC comme par la limitation du taux des messages de découverte,
-	un contrôle configurable des déclencheurs qui cause le passage d'un PCC à un autre PCE.

5.	Considérations pour la sécurité

Le présent document est un document d'exigences qui ne soulève donc pas par lui-même de questions particulières concernant la sécurité.

Un ensemble d'exigences pour la sécurité qui DOIVENT être prises en considération lors de la conception et du développement d'un mécanisme de découverte de PCE  a été précisé au paragraphe 4.6.

6.	Remerciements

Nous tenons à remercier, dans l'ordre chronologique, Benoit Fondeviole, Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil Bitar, et Kenji Kumaki.

Merci aussi à Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley et Sam Hartman pour leur relecture et les discussions constructives durant les étapes finales de la publication.

7.	Contributeurs

Les personnes suivantes sont les auteurs qui ont contribué au présent document :

Jean-Louis Le Roux (France Telecom)
Paul Mabey (Qwest Communications)
Eiji Oki (NTT)
Richard Rabbat (Fujitsu)
Ting Wo Chung (Bell Canada)
Raymond Zhang (BT Infonet)

8.	Références

8.1	Références normatives
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.
[RFC4655]	A. Farrel, J.-P. Vasseur et J. Ash, "Architecture fondée sur l'élément de calcul de chemin (PCE)", RFC 4655, août 2006.

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

Adresse des contributeurs

Paul Mabey	Eiji Oki	Richard Rabbat	
Qwest Communications	NTT	Fujitsu Laboratories of America	
950 17th Street	Midori-cho 3-9-11	1240 East Arques Ave, MS 345	
Denver, CO 80202	Musashino-shi, Tokyo 180-8585	Sunnyvale, CA 94085	
USA	JAPAN	USA	
mél : pmabey@qwest.com	mél : oki.eiji@lab.ntt.co.jp	mél : richard@us.fujitsu.com	

Ting Wo Chung	Raymond Zhang	
Bell Canada	BT Infonet	
181 Bay Street, Suite 350	2160 E. Grand Ave.	
Toronto, Ontario, M5J 2T3	El Segundo, CA 90025	
CANADA	USA	
mél : ting_wo.chung@bell.ca	mél : raymond_zhang@infonet.com	

Adresse de l'éditeur

Jean-Louis Le Roux (éditeur)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
mél : jeanlouis.leroux@orange-ftgroup.com

Déclaration complète de copyright

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 y contenues sont fournies 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 pourrait ê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