Groupe de travail Réseau	K. Kompella & Y. Rekhter, Juniper Networks	
Request for Comments : 4202	octobre 2005	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Extensions d'acheminement pour la commutation d'étiquettes 
multi protocoles généralisée (GMPLS)

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

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

Résumé
Le présent document spécifie des extensions d'acheminement pour la prise en charge du transport des informations d'état de liaison pour la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). Le présent document améliore les extensions d'acheminement requises pour la prise en charge de l'ingénierie de trafic (TE, Traffic Engineering) de MPLS.
Table des Matières
1. Introduction	2
1.1 Exigences pour les attributs TE spécifiques de couche	3
1.2 Exclusion du trafic de données des canaux de contrôle	3
2. Améliorations de l'acheminement GMPLS	4
2.1 Prise en charge des liaisons non numérotées	4
2.2 Type de protection de liaison	4
2.3 Informations de risque partagé pour un groupe de liaisons	5
2.4 Descripteur de capacités de commutation d'interface	5
2.5 Codage de la bande passante	9
3. Exemples de descripteur de capacité de commutation d'interface	9
3.1 Interface POS STM-16 sur un LSR	9
3.2 Interface paquet GigE sur un LSR	9
3.3 Interface SDH STM-64 sur interconnexion numérique avec SDH standard	9
3.4 Interface SDH STM-64 sur interconnexion numérique avec deux types de hiérarchie de multiplexage SDH	9
3.5. Interface sur un OXC opaque (SDH tramée) avec prise en charge d'un lambda par accès/interface	10
3.6 Interface sur un OXC transparent (PXC) avec DWDM externe comprenant le tramage SDH	10
3.7 Interface sur un OXC transparent (PXC) avec DWDM externe qui comprend le débit et le tramage	10
3.8 Interface sur un PXC sans DWDM externe	11
3.9 Interface sur un OXC avec DWDM interne qui comprend le tramage SDH	11
3.10 Interface sur un OXC avec DWDM internet transparent au débit binaire et au tramage	12
4. Exemple d'interfaces qui supportent plusieurs capacités de commutation	12
4.1 Interface sur un appareil PXC+TDM avec DWDM externe	12
4.2 Interface sur un appareil OXC+TDM opaque avec DWDM externe	13
4.3 Interface sur un appareil PXC+LSR avec DWDM externe	13
4.4 Interface sur un appareil TDM+LSR	13
5. Remerciements	13
6. Considérations sur la sécurité	14
7. Références	14
7.1 Références normatives	14
7.2 Référence pour information	14
8. Contributeurs	14
Adresse des auteurs	15
Déclaration complète de droits de reproduction	15

1.	Introduction

Le présent document spécifie les extensions d'acheminement pour la prise en charge du transport des informations d'état de liaison pour la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). Le présent document améliore les extensions d'acheminement des [RFC3784], [RFC3630] requises pour la prise en charge de l'ingénierie de trafic (TE, Traffic Engineering) MPLS .

Traditionnellement, une liaison TE est annoncée comme adjonction à une liaison "régulière", c'est-à-dire, une adjacence d'acheminement est établie sur la liaison, et lorsque la liaison est en service, les deux propriétés de la liaison sont utilisées pour les calculs de plus court chemin en premier (SPF, Shortest Path First) (essentiellement la métrique SPF) et les propriétés de TE de la liaison sont alors annoncées.

GMPLS met en question cette notion de trois façons. D'abord, les liaisons qui ne sont pas capables d'envoyer et recevoir paquet par paquet peuvent avoir déjà les propriétés de TE ; cependant, une adjacence d'acheminement ne peut pas être établie sur de telles liaisons. Ensuite, un chemin de commutation d'étiquettes (LSP, Label Switched Path) peut être annoncé comme liaison TE point à point (voir la [RFC4206]) ; donc, une liaison TE annoncée peut être entre une paire de nœuds qui n'ont pas d'adjacence d'acheminement l'un avec l'autre. Finalement, un certain nombre de liaisons peuvent être annoncées comme une seule liaison TE (peut-être pour améliorer l'adaptabilité) et là encore, il n'y a plus d'association bijective d'une adjacence d'acheminement régulière et d'une liaison TE.

On a donc une notion plus générale d'une liaison TE. Une liaison TE est une liaison "logique" qui a des propriétés TE. La liaison est logique en ce sens qu'elle représente une façon de grouper/transposer les informations sur certaines ressources physiques (et leurs propriétés) en informations qui sont utilisées par des SPF contraints pour les besoins du calcul de chemin, et par la signalisation GMPLS. Ce groupement/transposition doit être cohérent aux deux extrémités de la liaison. Le protocole de gestion de liaison (LMP, Link Management Protocol) [RFC4204] pourrait être utilisé pour vérifier cette cohérence.

Selon la nature des ressources qui forment une liaison TE particulière, pour les besoins de la signalisation GMPLS, dans certains cas, la combinaison <identifiant de liaison TE, étiquette> est suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un LSP. Dans d'autres cas, la combinaison de <identifiant de liaison TE, étiquette> n'est pas suffisante ; ces cas sont traités en utilisant la construction de faisceau de liaisons [RFC4201] qui permet d'identifier la ressource par <identifiant de liaison TE, identifiant de liaison composante, étiquette>.

Certaines des propriétés d'une liaison TE peuvent être configurées sur le routeur de commutation d'étiquettes (LSR, Label Switching Router) qui annonce, d'autres peuvent être obtenues d'autres LSR au moyen d'un certain protocole, et d'autres encore peuvent être déduites des composants de la liaison TE.

Une liaison TE entre une paire de LSR n'implique pas l'existence d'une adjacence d'acheminement (par exemple, une adjacence IGP) entre ces LSR. Comme mentionné ci-dessus, dans certains cas, une liaison TE entre une paire de LSR pourrait être annoncée même si il n'y a pas d'adjacence d'acheminement du tout entre les LSR (par exemple, lorsque la liaison TE est une adjacence de transmission (voir la [RFC4206])).

Une liaison TE doit avoir des moyens pour permettre au LSR qui annonce de connaître qu'elle existe (ces moyens peuvent être des hellos d'acheminement, mais ne s'y limitent pas). Lorsque un LSR sait qu'une liaison TE est en service, et qu'il peut déterminer les propriétés TE de la liaison TE, il peut alors annoncer cette liaison à ses voisins (réguliers).

Dans le présent document, on appelle les interfaces sur lesquelles les adjacences d'acheminement régulières sont établies des "canaux de contrôle".

Les [RFC3784] et [RFC3630] définissent les propriétés TE canoniques, et disent comment associer les propriétés TE aux liaisons régulières (par commutation de paquets). Le présent document étend l'ensemble des propriétés TE, et dit aussi comment associer les propriétés TE à des liaisons qui ne sont pas de commutation de paquets comme les liaisons entre brasseurs optiques (OXC, Optical Cross-Connect). La [RFC4206] dit comment associer les propriétés TE aux liaisons formées par des chemins de commutation d'étiquettes.

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

1.1	Exigences pour les attributs TE spécifiques de couche
En généralisant les liaisons TE pour inclure les facilités de transport traditionnelles, il y a des facteurs supplémentaires qui influencent quelles informations sont nécessaires sur la liaison TE. Elles proviennent de l'architecture de couche transport existante (par exemple, les Recommandations UIT-T G.805 et G.806) et les services de couches associées. Certains de ces facteurs sont :

1.	Le besoin de LSP à une adaptation spécifique, pas juste une bande passante particulière. Les clients de réseaux optiques obtiennent des services de connexion pour des adaptations spécifiques, par exemple, un circuit VC-3. Cela n'implique pas seulement une bande passante particulière, mais aussi comment la charge utile est structurée. Donc le client VC-3 ne va pas se satisfaire d'un LSP qui offre autre chose que 48,384 Mbit/s et la structure attendue. Le corollaire est que le calcul devrait être capable de trouver un chemin qui va donner une connexion à une adaptation spécifique.

2.	Distinguer une adaptation variable. Une ressource entre deux OXC (précisément une piste G.805) peut parfois prendre en charge différentes adaptations en même temps. Un exemple en est décrit au paragraphe 2.4.8. Dans cette situation, le fait que deux adaptations soient prises en charge sur la même piste est important parce que les deux couches sont inter dépendantes, et il est important d'être capable de refléter cette relation de couches dans l'acheminement, en particulier compte tenu du relatif manque de souplesse des couches de transport comparées aux couches de paquets.

3.	Attributs héritables. Lorsque toute une hiérarchie de multiplexage est prise en charge par une liaison TE, un attribut de couche inférieure peut être applicable aux couches supérieures. Les attributs de protection en sont un bon exemple. Si une liaison OC-192 est protégée 1+1 (un OC-192 dupliqué existe pour la protection) un STS-3c au sein de cet OC-192 (une couche supérieure) va alors hériter de la même propriété de protection.

4.	Extensibilité des couches. En plus des couches de transport définies existantes, de nouvelles couches et relations d'adaptation pourraient voir le jour à l'avenir.

5.	Des réseaux hétérogènes dont les OXC ne prennent pas tous en charge le même ensemble de couches. Dans un réseau GMPLS, tous les éléments de réseau de couche de transport ne sont pas supposés prendre en charge les mêmes couches. Par exemple, il peut y avoir des commutateurs capables seulement de VC-11, VC-12, et VC-3, et il peut y en avoir d'autres qui ne prennent en charge que VC-3 et VC-4. Même si un élément de réseau ne peut pas prendre en charge une couche spécifique, il devrait être capable de savoir si un élément de réseau ailleurs dans le réseau peut prendre en charge une adaptation qui permettrait que la couche non prise en charge soit utilisée. Par exemple, un commutateur VC-11 pourrait utiliser un commutateur à capacité VC-3 si il sait qu'un chemin VC-11 pourrait être construit sur une connexion de liaison VC-3.

D'après les facteurs présentés ci-dessus, le développement de documents d'acheminement GMPLS spécifiques de couches devrait utiliser les principes suivants pour les attributs de liaison TE.

1.	Séparation des attributs. Les attributs dans une couche donnée sont séparés des attributs dans une autre couche.

2.	Prise en charge d'attributs inter couches (par exemple, relations d'adaptation). Entre couches client et serveur, un mécanisme général pour décrire les relations de couche existe. Par exemple, "4 liaisons client de type X peuvent être prises en charge par cette liaison de couche serveur". Un autre exemple est d'être capable d'identifier quand deux couches partagent une couche serveur commune.

3.	Prise en charge d'attributs héritables. Les attributs qui peuvent être hérités devraient être identifiés.

4.	Extensibilité de couche. Les attributs devraient être représentés dans l'acheminement afin que des couches futures puissent être accommodées. C'est un peu comme la notion d'étiquette généralisée.

5.	Portée explicite d'attribut. Par exemple, il devrait être clair qu'un certain attribut s'applique ou non à un ensemble de liaisons à la même couche.

Le présent document rassemble les attributs généraux qui s'appliquent à un réseau à une seule couche, mais ne traite pas des relations inter couches des attributs. Ce travail fera l'objet d'un autre document.

1.2	Exclusion du trafic de données des canaux de contrôle
Les canaux de contrôle entre nœuds dans un réseau GMPLS, comme des OXC, des brasseurs et/ou routeurs SDH, sont généralement destinés au trafic de contrôle et administratif. Ces canaux de contrôle sont annoncés dans l'acheminement comme des liaisons normales comme mentionné au paragraphe précédent ; cela permet l'acheminement de messages RSVP (par exemple) et des sessions telnet. Cependant, si les routeurs sur la bordure du domaine optique tentent de transmettre du trafic de données sur ces canaux, la capacité du canal sera rapidement épuisée.

Afin d'empêcher que ces canaux de contrôle soient annoncés dans le plan de données d'utilisateur, diverses techniques peuvent être utilisées.

Si on suppose que le trafic de données est envoyé aux destinations BGP, et que le trafic de contrôle est envoyé aux destinations IGP, on peut alors exclure le trafic de données du plan de contrôle en interdisant la résolution du prochain bon BGP. (On suppose que les OXC ne parlent pas BGP.) Supposons qu'un routeur R tente d'installer un chemin pour une destination BGP D. R cherche le prochain bond BGP pour D dans son tableau d'acheminement d'IGP. Disons que R trouve que le chemin pour le prochain bond est sur l'interface I. R vérifie alors si il a une entrée dans sa base de données d'état de liaison associée à l'interface I. Si il y en a une, et si la liaison n'a pas la capacité de commutation par paquets (voir la [RFC4206]) R installe un chemin d'élimination pour la destination D. Autrement, R installe (normalement) un chemin pour la destination D avec le prochain bond I. Noter que R a seulement besoin de faire cette vérification si il a des liaisons incapables de commutation par paquets ; si toutes ses liaisons ont cette capacité, cette vérification est clairement redondante.

Dans d'autres instances il peut être désirable de garder tout l'espace d'adresses d'un plan d'acheminement GMPLS disjoint des adresses de point d'extrémité dans une autre portion du réseau GMPLS. Par exemple, les adresses d'un réseau transporteur où le transporteur utilise GMPLS mais ne souhaite pas exposer les détails internes de l'adressage ou de la topologie. Dans un tel réseau, les canaux de contrôle ne sont jamais annoncés dans le réseaux de données d'extrémité. Dans ce cas, des mécanismes indépendants sont utilisés pour annoncer les adresses des données sur le réseau transporteur.

D'autres techniques pour exclure le trafic de données des canaux de contrôle peuvent aussi être nécessaires.

2.	Améliorations de l'acheminement GMPLS

Dans cette section, on définit les améliorations des propriétés TE des liaisons TE GMPLS. Le codage de ces informations dans IS-IS est spécifié dans la [RFC4205]. Le codage de ces informations dans OSPF est spécifié dans la [RFC4203].

2.1	Prise en charge des liaisons non numérotées
Une liaison non numérotée doit être une liaison point à point. Un LSR à chaque extrémité d'une liaison non numérotée alloue un identifiant à cette liaison. Cet identifiant est un nombre de 32 bits, différent de zéro, qui est unique dans la gamme allouée par le LSR.

Considérons une liaison (non numérotée) entre les LSR A et B. Le LSR A choisit un identifiant pour cette liaison. Le LSR B en fait autant. Du point de vue de A, on appelle l'identifiant alloué par A à la liaison "l'identifiant de liaison local" (ou juste "identifiant local") et l'identifiant que B a alloué à la liaison "l'identifiant de liaison distant" (ou juste "identifiant distant"). De même, du point de vue de B, l'identifiant que B alloue à la liaison est l'identifiant local, et l'identifiant que A alloue à la liaison est l'identifiant distant.

La prise en charge de liaisons non numérotées dans l'acheminement inclut de transporter des informations sur les identifiants de cette liaison. Précisément, lorsque un LSR annonce une liaison TE non numérotée, l'annonce porte les deux identifiants, local et distant, de la liaison. Si le LSR ne connaît pas l'identifiant distant de cette liaison, le LSR devrait utiliser une valeur de 0 comme identifiant distant.

2.2	Type de protection de liaison
Le type de protection de liaison représente la capacité de protection qui existe pour une liaison. Il est désirable de porter cette information afin qu'elle puisse être utilisée par l'algorithme de calcul de chemin pour établir les LSP avec les caractéristiques de protection appropriées. Ces informations sont organisées dans une hiérarchie où normalement la protection minimum acceptable est spécifiée à l'instanciation du chemin et une technique de choix de chemin est utilisée pour trouver un chemin qui satisfasse au moins la protection minimum acceptable. Les schémas de protection sont présentés dans l'ordre de la plus faible protection à la plus forte.

Le présent document définit les capacités de protection suivantes :

Extra Traffic : Si la liaison est du type Extra Traffic, cela signifie que la liaison protège une ou des autres liaisons. Les LSP sur une liaison de ce type seront perdus si une des liaisons qu'elle protège a une défaillance.

Unprotected : Si la liaison est du type Unprotected, cela signifie qu'il n'y a pas d'autre liaison qui protège cette liaison. Les LSP sur une liaison de ce type seront perdus si la liaison a une défaillance.

Shared : Si la liaison est du type Shared, cela signifie qu'il y a une ou plusieurs autres liaisons disjointes de type Extra Traffic qui protègent cette liaison. Ces liaisons Extra Traffic sont partagées entre une ou plusieurs autres liaisons de type Shared.

Dedicated 1:1 : Si la liaison est du type Dedicated 1:1, cela signifie qu'il y a une liaison dédiée disjointe de type Extra Traffic qui protège cette liaison.

Dedicated 1+1 : Si la liaison est du type Dedicated 1+1, cela signifie q'une liaison dédiée disjointe protège cette liaison. Cependant, la liaison protectrice n'est pas annoncée dans la base de données d'état de la liaison et n'est donc pas disponible pour l'acheminement des LSP.

Enhanced : Si la liaison est du type Enhanced, cela signifie qu'un schéma de protection qui est plus fiable que Dedicated 1+1, par exemple, 4 fibres BLSR/MS-SPRING, est utilisé pour protéger cette liaison.

Le type de protection de liaison est facultatif, et si une annonce d'état de liaison ne porte pas cette information, le type de protection de liaison est inconnu.

2.3	Informations de risque partagé pour un groupe de liaisons
Un ensemble de liaisons peut constituer un "groupe de liaisons à risques partagés" (SRLG, shared risk liaison group) si elles partagent une ressource dont la défaillance peut affecter toutes les liaisons de l'ensemble. Par exemple, deux fibres dans le même conduit seraient dans le même SRLG. Une liaison peut appartenir à plusieurs SRLG. Donc les informations de SLRG décrivent une liste de SRLG auxquels appartient la liaison. Un SRLG est identifié par un numéro de 32 bits qui est unique au sein d'un domaine IGP. Les informations de SLRG sont une liste non ordonnée de SRLG auxquels appartient la liaison.

Le SRLG d'un LSP est l'union des SRLG des liaisons dans le LSP. Le SRLG d'une liaison en faisceau est l'union des SRLG de toutes les liaisons composantes.

Si un LSR est obligé d'avoir plusieurs LSP d'acheminement divers avec un autre LSR, le calcul de chemin devrait tenter d'acheminer les chemins de telle façon qu'ils n'aient aucune liaison en commun, et tels que les SRLG de chemin soient disjoints.

Les informations de SRLG peuvent commencer par une valeur non configurée, qui dans ce cas restera constante dans le temps, sauf si elle est reconfigurée.

Les informations de SRLG sont facultatives et si une annonce d'état de liaison ne porte pas les informations de SRLG, cela signifie alors que le SRLG de cette liaison est inconnu.

2.4	Descripteur de capacités de commutation d'interface
Dans le contexte du présent document, on dit qu'une liaison est connectée à un nœud par une interface. Dans le contexte de GMPLS les interfaces peuvent avoir des capacités de commutation différentes. Par exemple, une interface qui connecte une certaine liaison à un nœud peut n'être pas capable de commuter des paquets individuels, mais peut être capable de commuter des canaux au sein d'une charge utile SDH. Les interfaces à chaque extrémité d'une liaison n'ont pas besoin d'avoir les mêmes capacités de commutation. Les interfaces sur le même nœud n'ont pas besoin d'avoir les mêmes capacités de commutation.

Le descripteur de capacités de commutation d'interface décrit les capacités de commutation d'une interface. Pour les liaisons bidirectionnelles, les capacités de commutation d'une interface sont définies comme étant les mêmes dans les deux directions, c'est-à-dire pour les données qui entrent dans le nœud par cette interface et pour les données qui quittent le nœud à travers cette interface.

Une annonce d'état de liaison d'une liaison porte les descripteurs de capacité de commutation d'interface de la seule extrémité proche (l'extrémité qui incombe au LSR qui a généré l'annonce).

Un LSR qui effectue un calcul de chemin utilise la base de données d'état de liaison pour déterminer si une liaison est unidirectionnelle ou bidirectionnelle.

Pour une liaison bidirectionnelle, le LSR utilise sa base de données d'état de liaison pour déterminer le ou les descripteurs de capacité de commutation d'interface de l'extrémité distante de la liaison, car des liaisons bidirectionnelles avec des capacités de commutation d'interface différentes à leurs deux extrémités sont permises.

Pour une liaison unidirectionnelle, on suppose que le descripteur de capacités de commutation d'interface à l'extrémité distante est le même que celui de l'extrémité proche. Donc, une liaison unidirectionnelle est obligée d'avoir les mêmes capacités de commutation d'interface aux deux extrémités. Cela semble une hypothèse raisonnable étant donné que les liaisons unidirectionnelles ne se produisent qu'avec des adjacences de transmission de paquets et pour elles, les deux extrémités appartiennent au même niveau de la hiérarchie de capacité de commutation de paquet (PSC, Packet-Switch Capable).

Le présent document définit les capacités de commutation d'interface suivantes :
Packet-Switch Capable-1 (PSC-1) : capacité 1 de commutation de paquet
Packet-Switch Capable-2 (PSC-2) : capacité 2 de commutation de paquet
Packet-Switch Capable-3 (PSC-3) : capacité 3 de commutation de paquet
Packet-Switch Capable-4 (PSC-4) : capacité 4 de commutation de paquet
Layer-2 Switch Capable (L2SC) : capacité de commutation de couche 2
Time-Division-Multiplex Capable (TDM) : capacité de multiplexage à division temporelle
Lambda-Switch Capable (LSC) : capacité de commutation lambda
Fiber-Switch Capable (FSC) : capacité de commutation optique

Si il n'y a pas de descripteur de capacités de commutation d'interface pour une interface, l'interface est supposée être à capacité de commutation de paquet (PSC-1).

Les descripteurs de capacités de commutation d'interface présentent une nouvelle contrainte pour le calcul de chemin de LSP.

Sans considération des capacités de commutation d'interface particulière, le descripteur de capacités de commutation d'interface inclut toujours des informations sur le codage pris en charge par une interface. Les codages définis sont les mêmes que les codages de LSP définis dans la [RFC3471].

Une interface peut avoir plus d'un descripteur de capacités de commutation d'interface. C'est utilisé pour traiter les interfaces qui prennent en charge plusieurs capacités de commutation, pour des interfaces qui ont des valeurs de bande passante maximum de LSP qui diffèrent par le niveau de priorité, et pour des interfaces qui prennent en charge des bandes passantes discontinues.

Selon la capacité de commutation d'interface particulière, le descripteur de capacités de commutation d'interface peut inclure des informations supplémentaires, comme spécifié ci-dessous.

2.4.1	Capacité de commutation de couche 2
Si une interface est de type L2SC, cela signifie que le nœud qui reçoit des données sur cette interface peut commuter les trames reçues sur la base de l'adresse de couche 2. Par exemple, une interface associée à une liaison qui se termine sur un commutateur ATM sera considérée comme L2SC.

2.4.2	Capacité de commutation de paquet
Si une interface est de type PSC-1 à PSC-4, cela signifie que le nœud qui reçoit les données sur cette interface peut commuter les données reçues paquet par paquet, sur la base de l'étiquette portée dans l'en-tête "shim" [RFC3032]. Les divers niveaux de PSC établissent une hiérarchie de LSP tunnelés dans les LSP.

Pour les interfaces à capacité de commutation de paquet, les informations supplémentaires incluent la bande passante maximum de LSP, la bande passante minimum de LSP, et la MTU d'interface.

Pour une simple liaison (non en faisceau) la bande passante maximum de LSP à la priorité p est définie comme étant le plus petit de la bande passante non réservée à la priorité p et un paramètre "Taille maximum de LSP" qui est configuré en local sur la liaison, et dont la valeur par défaut est égale à la bande passante maximum de liaison. La bande passante maximum de LSP pour une liaison en faisceau est définie dans la [RFC4201].

La largeur de bande maximum de LSP prend la place de la largeur de bande maximum de liaison ([RFC3784], [RFC3630]). Cependant, alors que la largeur de bande maximum de liaison est une seule valeur fixée (généralement simplement la capacité de la liaison) la largeur de bande maximum de LSP est portée par priorité, et peut varier avec l'établissement et la suppression des LSP.

Bien que la largeur de bande maximum de liaison soit déconseillée, pour la rétro compatibilité, on PEUT régler la largeur de bande maximum de liaison à la largeur de bande maximum de LSP à la priorité 7.

La largeur de bande minimum de LSP spécifie la bande passante minimum qu'un LSP peut réserver.

Les valeurs typiques pour la largeur de bande minimum de LSP et pour la largeur de bande maximum de LSP sont énumérées dans la [RFC3471].

Sur une interface de PSC qui accepte le codage SDH standard, un LSP à la priorité p pourrait réserver toute bande passante admise par la branche de la hiérarchie SDH, avec la feuille et la racine de la branche définies par la largeur de bande minimum de LSP et la largeur de bande maximum de LSP à la priorité p.

Sur une interface de PSC qui accepte un codage SDH arbitraire, un LSP à la priorité p pourrait réserver toute bande passante entre la largeur de bande minimum de LSP et la largeur de bande maximum de LSP à la priorité p, pourvu que la bande passante réservée par le LSP soit un multiple de la largeur de bande minimum de LSP.

La MTU de l'interface est la taille maximum d'un paquet qui peut être transmise sur cette interface sans être fragmentée.

2.4.3	Capacité de multiplexage à division temporelle
Si une interface est du type TDM, cela signifie que le nœud qui reçoit les données sur cette interface peut multiplexer ou démultiplexer les canaux au sein d'une charge utile SDH.

Pour les interfaces à capacité de multiplexage à division temporelle, les informations supplémentaires incluent la largeur de bande maximum de LSP, les informations sur si l'interface prend en charge la SDH standard ou arbitraire, et la largeur de bande minimum de LSP.

Pour une simple liaison (non en faisceau) la largeur de bande maximum de LSP à la priorité p est définie comme la bande passante maximum qu'un LSP à la priorité p peut réserver. La largeur de bande maximum de LSP pour une liaison en faisceau est définie dans la [RFC4201].

La largeur de bande minimum de LSP spécifie la bande passante minimum qu'un LSP peut réserver.

Les valeurs typiques pour la largeur de bande minimum de LSP et pour la largeur de bande maximum de LSP sont énumérées dans la [RFC3471].

Sur une interface ayant un multiplexage SDH standard, un LSP à la priorité p peut réserver toute bande passante permise par la branche de la hiérarchie SDH, avec la feuille et la racine de la branche définies par la largeur de bande minimum de LSP et la largeur de bande maximum de LSP à la priorité p.

Sur une interface ayant un multiplexage SDH arbitraire, un LSP à la priorité p peut réserver toute bande passante entre la largeur de bande minimum de LSP et la largeur de bande maximum de LSP à la priorité p, pourvu que la bande passante réservée par le LSP soit un multiple de la largeur de bande minimum de LSP.

Le descripteur de capacité de commutation d'interface pour les interfaces qui prennent en charge le sous VC-3 peut inclure des informations supplémentaires. La nature et le codage de telles informations sort du domaine d'application du présent document.

Une façon de traiter le cas où une interface prend en charge plusieurs branches de la hiérarchie de multiplexage SDH, est que plusieurs descripteurs de capacité de commutation d'interface seront annoncés, un par branche. Par exemple, si une interface prend en charge VC-11 et VC-12 (qui ne font pas partie de la même branche de l'arborescence de multiplexage SDH) elle pourrait alors annoncer deux descripteurs, un pour chacune.

2.4.4	Capacité de commutation lambda
Si une interface est de type LSC, cela signifie que le nœud qui reçoit les données sur cette interface peut reconnaître et commuter des lambdas individuels au sein de l'interface. Une interface qui ne permet qu'un seul lambda par interface, et commute juste ce lambda est du type LSC.

Les informations supplémentaires incluent la bande passante réservable par priorité, spécifiant la bande passante d'un LSP qui pourrait être pris en charge par l'interface à un certain numéro de priorité.

Une façon de traiter le cas de plusieurs débits de données ou plusieurs codages au sein d'une seule liaison TE, plusieurs descripteurs de capacité de commutation d'interface seront annoncés, un par combinaison de débit de données pris en charge et de codage. Par exemple, une interface LSC pourrait prendre en charge l'établissement de LSP LSC aux deux débits de données STM-16 et STM-64.

2.4.5	Capacité de commutation de fibre
Si une interface est de type FSC, cela signifie que le nœud qui reçoit les données sur cette interface peut commuter la totalité du contenu sur une autre interface (sans distinguer lambdas, canaux ou paquets). C'est-à-dire qu'une interface de type FSC commute à la granularité d'une interface entière, et ne peut pas extraire les lambdas individuels au sein de l'interface. Une interface de type FSC ne peut pas se restreindre à juste un lambda.

2.4.6	Plusieurs capacités de commutation par interface
Une interface qui connecte une liaison à un LSR peut prendre en charge non seulement une, mais plusieurs capacités de commutation d'interface. Par exemple, considérons une liaison fibre qui porte des lambdas et se termine sur une interface LSR qui pourrait inter connecter un de ces lambdas à un autre canal optique sortant, ou pourrait terminer le lambda, et extraire (démultiplexer) des données de ce lambda en utilisant TDM, et ensuite inter connecter ces canaux TDM à des canaux TDM sortants. Pour prendre cela en charge, une annonce d'état de liaison peut porter une liste de descripteurs de capacités de commutation d'interface.

2.4.7	Capacités de commutation d'interface et étiquettes
Pour décrire une liaison TE comme un tuplet qui contient les capacités de commutation d'interface aux deux extrémités de la liaison, des exemples de liaisons pourraient être :
[PSC, PSC] - une liaison entre deux LSR de paquets
[TDM, TDM] - une liaison entre deux brasseurs numériques
[LSC, LSC] - une liaison entre deux OXC
[PSC, TDM] - une liaison entre un LSR de paquets et un brasseur numérique
[PSC, LSC] - une liaison entre un LSR de paquet et un OXC
[TDM, LSC] - une liaison entre un brasseur numérique et un OXC

Les deux extrémités d'une certaine liaison TE doivent utiliser la même façon de porter les informations d'étiquette sur cette liaison. Porter les informations d'étiquette sur une certaine liaison TE dépend de la capacité de commutation d'interface aux deux extrémités de la liaison, et est déterminé comme suit :
[PSC, PSC] – l'étiquette est portée dans l'en-tête "shim" [RFC3032]
[TDM, TDM] – l'étiquette représente un intervalle de temps TDM [RFC3946]
[LSC, LSC] – l'étiquette représente un lambda
[FSC, FSC] – l'étiquette représente un accès sur un OXC
[PSC, TDM] – l'étiquette représente un intervalle de temps TDM [RFC3946]
[PSC, LSC] – l'étiquette représente un lambda
[PSC, FSC] – l'étiquette représente un accès
[TDM, LSC] – l'étiquette représente un lambda
[TDM, FSC] – l'étiquette représente un accès
[LSC, FSC] – l'étiquette représente un accès

2.4.8	Autres questions
Il est possible que le descripteur de capacités de commutation d'interface change au fil du temps, reflétant l'allocation/désallocation des LSP. Par exemple, supposons que des LSP VC-3, VC-4, VC-4-4c, VC-4-16c et VC-4-64c puissent être établis sur une interface STM-64 dont le type de codage est SDH. Donc, initialement dans le descripteur de capacités de commutation d'interface, la largeur de bande minimum de LSP est réglée à VC-3, et la largeur de bande maximum de LSP est réglée à STM-64 pour toutes les priorités. Aussitôt qu'un LSP de taille VC-3 à la priorité 1 est établi sur l'interface, il n'a plus la capacité de VC-4-64c que pour les LSP à la priorité 0. Donc, le nœud annonce un descripteur de capacités de commutation d'interface modifié qui indique que la largeur de bande maximum de LSP n'est plus STM-64, mais STM-16 pour tout sauf la priorité 0 (à la priorité 0 la largeur de bande maximum de LSP est encore STM-64). Si ensuite il y a un autre LSP VC-3, il n'y aura pas de changement du descripteur de capacités de commutation d'interface. Le descripteur reste le même jusqu'à ce que le nœud ne puisse plus établir un LSP VC-4-16c sur l'interface (ce qui signifie qu'à ce point plus de 144 intervalles de temps sont pris par les LSP sur l'interface). Une fois que cela est arrivé, le descripteur est modifié à nouveau, et le descripteur modifié est annoncé aux autres nœuds.

2.5	Codage de la bande passante
Le codage en format de virgule flottante IEEE [IEEE] des valeurs discrètes qui pourraient être utilisées pour identifier la bande passante non réservée, la bande passante maximum de LSP et la bande passante minimum de LSP est décrit au paragraphe 3.1.2 de la [RFC3471].

3.	Exemples de descripteur de capacité de commutation d'interface
3.1	Interface POS STM-16 sur un LSR
Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = PSC-1
    Codage = SDH
    Bande passant maximum de LSP[p] = 2,5 Gbit/s, pour tout p

Si plusieurs liaisons avec de telles interfaces aux deux extrémités devaient être annoncées comme une liaison TE, les techniques de mise en faisceau de liaisons devraient être utilisées.

3.2	Interface paquet GigE sur un LSR
Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = PSC-1
    Codage = Ethernet 802.3
    Bande passant maximum de LSP[p] = 1,0 Gbit/s, pour tout p

Si plusieurs liaisons avec de telles interfaces aux deux extrémités devaient être annoncées comme une liaison TE, les techniques de mise en faisceau de liaisons devraient être utilisées.

3.3	Interface SDH STM-64 sur interconnexion numérique avec SDH standard
Considérons une branche de l'arborescence de multiplexage SDH : VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. Si il est possible d'établir toutes ces connexions sur une interface STM-64, le descripteur de capacités de commutation d'interface de cette interface peut être annoncé comme suit :

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = TDM [SDH standard]
    Codage = SDH
    Bande passant minimum de LSP = VC-3
    Bande passant maximum de LSP[p] = STM-64, pour tout p

Si plusieurs liaisons avec de telles interfaces aux deux extrémités devaient être annoncées comme une liaison TE, les techniques de mise en faisceau de liaisons devraient être utilisées.

3.4	Interface SDH STM-64 sur interconnexion numérique avec deux types de hiérarchie de multiplexage SDH
Descripteur de capacités de commutation d'interface 1 :
    Capacité de commutation d'interface = TDM [SDH standard]
    Codage = SDH
    Bande passant minimum de LSP = VC-3
    Bande passant maximum de LSP[p] = STM-64, pour tout p

Descripteur de capacités  de commutation d'interface 2 :
    Capacité de commutation d'interface = TDM [SDH arbitraire]
    Codage = SDH
    Bande passant minimum de LSP = VC-4
    Bande passant maximum de LSP[p] = STM-64, pour tout p

Si plusieurs liaisons avec de telles interfaces aux deux extrémités devaient être annoncées comme une liaison TE, les techniques de mise en faisceau de liaisons devraient être utilisées.

3.5.	Interface sur un OXC opaque (SDH tramée) avec prise en charge d'un lambda par accès/interface
Un "OXC opaque" est considéré du point de vue du fonctionnement comme un OXC, car le lambda entier (qui porte la ligne SDH) est commuté de façon transparente sans autre multiplexage/démultiplexage, et soit aucun des octets de la redondance SDH, soit seulement ceux qui sont importants, ne sont changés.

Une interface sur un OXC opaque traite une seule longueur d'onde, et ne peut pas commuter plusieurs longueurs d'onde comme un tout. Donc, une interface sur un OXC opaque est toujours LSC, et non FSC, sans considération de si il y a un multiplexage par répartition en longueur d’onde à haute densité (DWDM, Dense Wavelength Division Multiplexing) externe.

Noter que si il y a un DWDM externe, le tramage compris par le DWDM doit être le même que celui compris par l'OXC.

Une liaison TE est un groupe de une ou plusieurs interfaces sur un OXC. Toutes les interfaces sur un certain OXC sont obligées d'avoir des identifiants uniques pour cet OXC, et ces identifiants sont utilisés comme étiquettes (voir au paragraphe 3.2.1.1 de la [RFC3471]).

Voici un exemple d'un descripteur de capacités de commutation d'interface sur un OXC opaque tramé en SDH :

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = SDH
    Bande passante réservable = déterminée par le trameur SDH (disons STM-64)

3.6	Interface sur un OXC transparent (PXC) avec DWDM externe comprenant le tramage SDH
Cet exemple suppose que DWDM et PXC sont connectés de telle façon que chaque interface (accès) sur le PXC traite juste une seule longueur d'onde. Donc, même si en principe une interface sur le PXC pourrait commuter plusieurs longueurs d'onde comme un tout, dans ce cas particulier une interface sur le PXC est considérée comme LSC, et non FSC.

                     _______
                    |       |
               /|___|       |
              | |___|  PXC  |
      ========| |___|       |
              | |___|       |
               \|   |_______|
             DWDM
         (SDH tramée)

Une liaison TE est un groupe de une ou plusieurs interfaces sur le PXC. Toutes les interfaces sur un certain PXC sont obligées d'avoir des identifiants uniques pour ce PXC, et ces identifiants sont utilisés comme étiquettes (voir le paragraphe  3.2.1.1 de la [RFC3471]).

Voici un exemple d'un descripteur de capacités de commutation d'interface sur un OXC transparent OXC (PXC) avec DWDM externe qui comprend le tramage SDH :

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = SDH (vient du DWDM)
    Bande passante réservable = déterminé par DWDM (disons STM-64)

3.7	Interface sur un OXC transparent (PXC) avec DWDM externe qui comprend le débit et le tramage
Cet exemple suppose que DWDM et PXC sont connectés de telle façon que chaque interface (accès) sur le PXC traite juste une seule longueur d'onde. Donc, même si en principe une interface sur le PXC pourrait commuter plusieurs longueurs d'onde à la fois, dans ce cas particulier, une interface sur le PXC est considérée comme LSC, et non FSC.

                        _______
                       |       |
                  /|___|       |
                 | |___|  PXC  |
         ========| |___|       |
                 | |___|       |
                  \|   |_______|
                DWDM (transparent au débit binaire et au tramage)

Une liaison TE est un groupe d'une ou plusieurs interfaces sur le PXC. Toutes les interfaces sur un certain PXC doivent avoir des identifiants uniques pour ce PXC, et ces identifiants sont utilisés comme étiquettes (voir le paragraphe 3.2.1.1 de la [RFC3471]).

Voici un exemple d'un descripteur de capacités de commutation d'interface sur un OXC (PXC) transparent avec DWDM externe qui est transparent au débit binaire et au tramage :

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = Lambda (photonique
    Bande passante réservable = déterminée par les limites de la technologie optique.

3.8	Interface sur un PXC sans DWDM externe
L'absence de DWDM entre deux PXC implique qu'une interface n'est pas limitée à une seule longueur d'onde. Donc, l'interface est annoncée comme FSC.

Une liaison TE est un groupe d'une ou plusieurs interfaces sur le PXC. Toutes les interfaces sur un certain PXC doivent avoir des identifiants uniques pour ce PXC, et ces identifiants sont utilisés comme étiquettes d'accès (voir le paragraphe 3.2.1.1 de la [RFC3471]).

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = FSC
    Codage = Lambda (photonique)
    Bande passante réservable = déterminée par les limites de la technologie optique.

Noter que cet exemple suppose que le PXC ne restreint pas chaque accès à porter seulement une longueur d'onde.

3.9	Interface sur un OXC avec DWDM interne qui comprend le tramage SDH
Cet exemple suppose que DWDM et OXC sont connectés de telle façon que chaque interface sur l'OXC traite plusieurs longueurs d'onde individuellement. Dans ce cas, une interface sur l'OXC est considérée comme LSC, et non FSC.

                  _______
                 |       |
               /||       ||\
              | ||  OXC  || |
      ========| ||       || |====
              | ||       || |
               \||_______||/
             DWDM
         (SDH tramée)

Une liaison TE est un groupe d'une ou plusieurs des interfaces sur l'OXC. Tous les lambdas associés à une certaine interface doivent avoir des identifiants uniques pour cette interface, et ces identifiants sont utilisés comme étiquettes (voir le paragraphe 3.2.1.1 de la [RFC3471]).

Voici un exemple de descripteur de capacités de commutation d'interface sur un OXC avec DWDM interne qui comprend le tramage SDH et accepte des bandes passantes discrètes:

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = SDH (vient du DWDM)
    Bande passant maximum de LSP = déterminée par le DWDM (disons STM-16)

    Capacité de commutation d'interface = LSC
    Codage = SDH (vient du DWDM)
    Bande passante maximum de LSP = Déterminée par le DWDM (disons STM-64)

3.10	Interface sur un OXC avec DWDM internet transparent au débit binaire et au tramage
Cet exemple suppose que le DWDM et l'OXC sont connectés de façon telle que chaque interface sur l'OXC traite plusieurs longueurs d'ondes individuellement. Dans ce cas, une interface sur l'OXC est considérée comme LSC, et non FSC.

                         _______
                        |       |
                      /||       ||\
                     | ||  OXC  || |
             ========| ||       || |====
                     | ||       || |
                      \||_______||/
                    DWDM (transparent au débit binaire et au tramage)

Une liaison TE est un groupe d'une ou plusieurs des interfaces de l'OXC. Tous les lambdas associés à une certaine interface doivent avoir des identifiants uniques pour cette interface, et ces identifiants sont utilisés comme étiquettes (voir le paragraphe 3.2.1.1 de la [RFC3471]).

Voici un exemple de descripteur de capacités de commutation d'interface sur un OXC avec DWDM interne qui est transparent au débit binaire et au tramage:

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = Lambda (photonique)
    Bande passant maximum de LSP = déterminée par les limites de la technologie optique.

4.	Exemple d'interfaces qui supportent plusieurs capacités de commutation

De nombreuses combinaisons sont possibles, dont quelques unes sont décrites ci-dessous.

4.1	Interface sur un appareil PXC+TDM avec DWDM externe
Comme exposé précédemment, la présence du DWDM externe limite à une seule longueur d'onde sur un accès du PXC. Sur un tel accès, l'appareil PXC+TDM rattaché peut faire une des choses suivantes. La longueur d'onde peut être inter connectée par l'élément de PXC à un autre canal optique hors liaison, ou la longueur d'onde peut être terminée comme une interface SDH et les canaux SDH commutés.

Du point de vue de GMPLS, la fonction PXC+TDM est traitée comme une seule interface. L'interface est décrite en utilisant deux descripteurs d'interface, un pour le LSC et un autre pour le TDM, avec les paramètres appropriés. Par exemple,

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = SDH (vient du DWDM)
    Bande passante réservable = STM-64

et

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = TDM [SDH standard]
    Codage = SDH
    Bande passante minimum de LSP = VC-3
    Bande passante maximum de LSP[p] = STM-64, pour tout p

4.2	Interface sur un appareil OXC+TDM opaque avec DWDM externe
Une interface sur un appareil "OXC+TDM opaque" serait aussi annoncée comme LSC+TDM à peu près de la même façon que dans le cas précédent.

4.3	Interface sur un appareil PXC+LSR avec DWDM externe
Comme exposé précédemment, la présence du DWDM externe limite à une seule longueur d'onde sur un accès du PXC. Sur un tel accès, l'appareil PXC+LSR rattaché peut faire une des choses suivantes. La longueur d'onde peut être inter connectée par l'élément PXC à un autre canal optique hors liaison, ou elle peut être terminée comme interface paquet et les paquets connectés.

Du point de vue de GMPLS la fonction PXC+LSR est traitée comme une seule interface. L'interface est décrite en utilisant deux descripteurs d'interface, un pour le LSC et un autre pour le PSC, avec les paramètres appropriés. Par exemple,

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = LSC
    Codage = SDH (vient du WDM)
    Bande passante réservable = STM-64

et

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = PSC-1
    Codage = SDH
    Bande passant maximum de LSP[p] = 10 Gbit/s, pour tout p

4.4	Interface sur un appareil TDM+LSR
Sur un appareil TDM+LSR qui offre une interface SDH en canal, ce qui suit est possible :
-	Un sous ensemble des canaux SDH peut être non engagé. C'est-à-dire qu'ils ne sont pas actuellement utilisés et sont donc disponibles pour allocation.
-	Un second sous ensemble des canaux peut être déjà engagé pour des besoins de transit. C'est-à-dire qu'ils sont déjà inter connectés par la fonction de brasseur SDH avec d'autres canaux hors liaison et ne sont donc pas immédiatement disponibles pour allocation.
-	Un autre sous ensemble de canaux pourrait être utilisé comme canaux terminaux. C'est-à-dire qu'ils sont déjà alloués comme terminaison d'une interface paquets et de paquets commutés.

Du point de vue de GMPLS la fonction TDM+PSC est traitée comme une seule interface. L'interface est décrite en utilisant deux descripteurs d'interface, un pour le TDM et un autre pour le PSC, avec les paramètres appropriés. Par exemple,

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = TDM [SDH standard]
    Codage = SDH
    Bande passante minimum de LSP = VC-3
    Bande passante maximum de LSP[p] = STM-64, pour tout p

et

Descripteur de capacités de commutation d'interface :
    Capacité de commutation d'interface = PSC-1
    Codage = SDH
    Bande passante maximum de LSP[p] = 10 Gbit/s, pour tout p
5.	Remerciements

Les auteurs tiennent à remercier Suresh Katukam, Jonathan Lang, Zhi-Wei Lin, et Quaizar Vohra de leurs commentaires et contributions à ce document. Merci aussi à Stephen Shew pour le texte sur la représentation des capacités de liaison TE.

6.	Considérations sur la sécurité

La mise en œuvre des extensions proposées ici pose un certain nombre de problèmes de sécurité, en particulier parce que ces extensions pourraient être utilisées pour contrôler l'infrastructure de transport sous-jacente. Il est vital qu'il y ait des moyens sûrs et/ou authentifiés de transférer ces informations parmi les entités qui requièrent leur usage.

Bien que le présent document propose les extensions, il ne déclare pas comment ces extensions sont mises en œuvre dans les protocoles d'acheminement comme OSPF ou IS-IS. Les documents qui précisent comment les protocoles d'acheminement mettent en œuvre ces extensions [RFC4203], [RFC4205] doivent aussi préciser comment sécuriser les informations.

7.	Références
7.1	Références normatives

[IEEE]	IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.

[RFC3471]	L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation", janvier 2003. (MàJ par RFC4201, RFC4328, RFC4872, RFC8359) (P.S.)

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

[RFC3946]	E. Mannie, D. Papadimitriou, "Extensions de commutation d'étiquettes multi-protocoles généralisée (GMPLS) pour le contrôle de réseau optique synchrone (SONET) et de hiérarchie numérique synchrone (SDH)", octobre 2004. (Obsolète, voir RFC4606) (P.S.)

[RFC4201]	K. Kompella et autres, "Faisceaux de liaisons dans l'ingénierie du trafic MPLS", octobre 2005. (P.S.)

[RFC4203]	K. Kompella et autres, "Extensions OSPF pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (MàJ RFC3630) (P.S.)

[RFC4204]	J. Lang, éd., "Protocole de gestion de liaison (LMP)", octobre 2005. (P.S.)

[RFC4206]	K. Kompella, Y. Rekhter, "Hiérarchie de chemins commutés par étiquettes (LSP) avec l'ingénierie de trafic (TE) de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (P.S.)

7.2	Référence pour information

[RFC4205]	K. Kompella et Y. Rekhter, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation généralisée d'étiquettes multiprotocoles (GMPLS)", octobre 2005. (Obsolète, voir RFC5307) (MàJ RFC3784) (Information)

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

8.	Contributeurs
Ayan Banerjee	John Drake	Greg Bernstein	
Calient Networks	Calient Networks	Ciena Corporation	
5853 Rue Ferrari	5853 Rue Ferrari	10480 Ridgeview Court	
San Jose, CA 95138	San Jose, CA 95138	Cupertino, CA 94014	
téléphone : +1.408.972.3645	téléphone : (408) 972-3720	téléphone : (408) 366-4713	
mél : abanerjee@calient.net 	mél : jdrake@calient.net 	mél : greg@ciena.com 	

Don Fedyk	Eric Mannie	Debanjan Saha	
Nortel Networks Corp.	Libre Exaministe	Tellium Optical Systems	
600 Technology Park Drive	mél : eric_mannie@hotmail.com 	2 Crescent Place	
Billerica, MA 01821		P.O. Box 901	
téléphone : +1-978-288-4506		Ocean Port, NJ 07757	
mél : dwfedyk@nortelnetworks.com 		mél : dsaha@tellium.com 	

Vishal Sharma	Debashis Basak	Lou Berger	
Metanoia, Inc.	AcceLight Networks,	Movaz Networks, Inc.	
335 Elan Village Lane, Unit 203	70 Abele Rd, Bldg 1200	7926 Jones Branch Drive	
San Jose, CA 95134-2539	Bridgeville PA 15017	Suite 615	
téléphone : +1 408-943-1794	mél : dbasak@accelight.com 	McLean VA, 22102	
mél : v.sharma@ieee.org 		mél : lberger@movaz.com	

Adresse des auteurs
Kireeti Kompella	Yakov Rekhter	
Juniper Networks, Inc.	Juniper Networks, Inc.	
1194 N. Mathilda Ave.	1194 N. Mathilda Ave.	
Sunnyvale, CA 94089	Sunnyvale, CA 94089	
mél : kireeti@juniper.net 	mél : yakov@juniper.net 	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 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 actuellement fourni par la Internet Society.