RFC3472 page - 14 - Ashwood-Smith & Berger

Groupe de travail Réseau

P. Ashwood-Smith, éditeur, Nortel Networks

Request for Comments : 3472

L. Berger, éditeur, Movaz Networks

Catégorie : En cours de normalisation


Traduction Claude Brière de L’Isle

janvier 2003



Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : extensions au protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)


Statut du présent 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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 (2003). Tous droits réservés.


Résumé

Le présent document décrit les extensions à la signalisation du protocole de distribution d’étiquettes acheminées sur la base de la contrainte (CR-LDP, Constraint-based Routed Label Distribution Protocol) de commutation d’étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) exigées pour la prise en charge de MPLS généralisé. MPLS généralisé étend le plan de contrôle MPLS pour englober la division dans le temps (par exemple, réseau optique synchrone et hiérarchie numérique synchrone, SONET/SDH) la longueur d’onde (lambdas optiques) et la commutation spatiale (par exemple, d’accès ou fibre optique entrant à accès ou fibre optique sortant). Le présent document présente une description des extensions spécifique de CR-LDP. Une description fonctionnelle spécifique peut être trouvée dans des documents distincts.


Table des matières

1. Introduction 2

2. Formats en rapport avec les étiquettes 2

2.1 Demande d’étiquette généralisée 2

2.2 Étiquette généralisée 3

2.3 Commutation de gamme d’ondes 4

2.4 Étiquette suggérée 4

2.5 Ensemble d’étiquettes 4

3. LSP bidirectionnels 6

3.1 Procédures 6

4. Notification d’erreur d’étiquette 6

5. Contrôle explicite d’étiquette 6

5.1 Procédures 7

6. TLV Protection 7

6.1 Procédures 7

7. Informations d’état administratif 8

7.1 TLV État administratif 8

7.2 Procédures des messages Demande et Transposition 8

7.3 Procédures du message Notification 9

8. Séparation du canal de contrôle 9

8.1 Identification d’interface 9

8.2 Identification d’interface erronée 10

9. Traitement des fautes 11

10. Remerciements 11

11. Considérations pour la sécurité 11

12. Considérations relatives à l’IANA 11

13. Considérations de propriété intellectuelle 12

14. Références 12

14.1 Références normatives 12

14.2 Références pour information 12

15. Contributeurs 13

16. Adresse des éditeurs 13

17. Déclaration de droits de reproduction 13


1. Introduction


MPLS généralisé étend MPLS de la prise en charge des interfaces et de la commutation de paquet (PSC) pour inclure la prise en charge de trois nouvelles classes d’interfaces et de commutation : le multiplexage à division dans le temps (TDM, Time-Division Multiplex) la commutation lambda (LSC, Lambda Switch) et la commutation de fibre optique (FSC, Fiber-Switch). Une description fonctionnelle des extensions à la signalisation MPLS nécessaire pour la prise en charge des nouvelles classes d’interfaces et de commutation est fournie dans la [RFC3471]. Le présent document présente les formats et mécanismes spécifiques de CR-LDP nécessaires pour la prise en charge des quatre classes d’interfaces. Les extensions à RSVP-TE se trouvent dans la [RFC3473].


La [RFC3471] devrait être vue comme un document d’accompagnement du présent document. Le format du présent document est parallèle à celui de la [RFC3471]. On devrait noter que la version spécifique de RSVP-TE de MPLS généralisé inclut la prise en charge spécifique de RSVP pour une notification rapide des défaillances, voir la Section 4 de la [RFC3473]. Pour CR-LDP il n’y a pas actuellement de mécanisme similaire. Lorsque une défaillance est détectée, elle sera propagée avec des messages LIBÉRATION/RETRAIT tout autour du point de défaillance. Les ressources doivent être libérées dans cette phase et les informations sur les ressources réelles peuvent être renvoyées à la source en utilisant des mécanismes de rétroaction.


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, [RFC2119].


2. Formats en rapport avec les étiquettes


La présente section définit les formats d’une demande d’étiquette généralisée, une étiquette généralisée, la prise en charge de la commutation de gamme d’onde, l’étiquette suggérée et les ensembles d’étiquettes.


2.1 Demande d’étiquette généralisée


Un message Demande DEVRAIT contenir un type de codage de chemin de commutation d’étiquettes (LSP, Label Switched Path) aussi spécifique que possible pour permettre la souplesse maximale de commutation par les LSR de transit. Un Type, Longueur, Valeur (TLV) de demande d’étiquette généralisée est établi par le nœud d’entrée, passé de façon transparente par les nœuds de transit, et utilisé par le nœud de sortie. Le champ Type de commutation peut aussi être mis à jour bond par bond.


Le format d’une demande d’étiquette généralisée est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0824) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Type code LSP |Type de commut.| G-PID |

+---------------+---------------+---------------+---------------+


Voir la [RFC3471] pour la description des paramètres.


2.1.1 Procédures

Un nœud qui traite un message Demande qui contient une demande d’étiquette généralisée doit vérifier que les paramètres demandés peuvent être satisfaits par l’interface entrante, le nœud et l’interface sortante. Le nœud peut prendre en charge le LSP directement ou il peut utiliser un tunnel (FA), c’est-à-dire, une autre classe de commutateurs. Dans l’un et l’autre cas, chaque paramètre doit être vérifié.


Noter que la politique du nœud local dicte le moment où les tunnels peuvent être utilisés et quand ils peuvent être créés. La politique locale peut permettre que les tunnels soient établis de façon dynamique ou qu’ils soient seulement contrôlés de façon administrative. Pour plus d’informations sur les tunnels et le traitement des bonds de chemin explicite (ER, Explicit Route) lors de l’utilisation de tunnels, voir la [RFC4206].


Les nœuds de transit et de sortie DOIVENT vérifier que le nœud lui-même et, lorsque approprié, que l’interface ou tunnel sortant, peut supporter le type de codage de LSP demandé. Si le codage n’est pas accepté, le nœud DOIT générer un message Notification, avec une indication "Problème d’acheminement/Codage non accepté".


Les nœuds DOIVENT vérifier que le type indiqué dans le paramètre Type de commutation est accepté sur l’interface entrante correspondante. Si le type ne peut pas être accepté, le nœud DOIT générer un message Notification avec une indication "Problème d’acheminement/Type de commutation".


Le paramètre G-PID n'est normalement examiné qu’à la sortie. Si le G-PID indiqué ne peut être accepté, la sortie DOIT alors générer un message Notification avec une indication "Problème d’acheminement/G-PID non accepté". Dans le cas de PSC et lorsque le saut de l’avant dernier bond (PHP, penultimate hop popping) est demandé, l’avant dernier bond examine aussi le G-PID (mémorisé) durant le traitement du message Transposition. Dans ce cas, si le G-PID n’est pas accepté, l’avant dernier bond DOIT alors générer un message Notification avec une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". Le message Notification généré PEUT inclure un ensemble d’étiquettes acceptable, voir la Section 4.


Lorsque un message d’erreur n’est pas généré, c’est le traitement normal qui a lieu. Dans le cas de transit, cela va normalement résulter en la propagation d’un message Demande. Dans le cas de sortie et dans le cas particulier de PHP, il va normalement en résulter la génération d’un message Transposition.


2.1.2 Codage de bande passante

Les codages de bande passante sont portés dans le TLV Paramètres de trafic CR-LDP. Voir dans la [RFC3471] la définition des valeurs à utiliser pour les différents types de signal. Ces valeurs sont réglées dans les champs Taux de crête et Taux obligé du TLV Paramètres de trafic. Les autres paramètres relatifs à la bande passante/service dans le TLV sont ignorés et transportés de façon transparente.


2.2 Étiquette généralisée


Le format d’une étiquette généralisée est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0825) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Étiquette |

| ... |

+---------------+---------------+---------------+---------------+


Voir dans la [RFC3471] la description des paramètres et du codage des étiquettes.


2.2.1 Procédures

L’étiquette généralisée voyage dans la direction vers l’amont des messages Transposition.


La présence à la fois de TLV d’étiquette généralisée et normale dans un message Transposition est une erreur de protocole et devrait être traitée comme un message malformé par le receveur.


Le receveur d’un message Transposition qui contient une étiquette généralisée vérifie que les valeurs passées sont acceptables. Si l’étiquette est inacceptable, le receveur DOIT alors générer un message Notification avec une indication "Problème d’acheminement/Défaillance d’allocation d’étiquette MPLS". Le message Notification généré PEUT inclure un ensemble d’étiquettes acceptable, voir la Section 4.


2.3 Commutation de gamme d’ondes


La commutation de gamme d’onde utilise le même format que l’étiquette généralisée, voir au paragraphe 2.2. Le type 0x0828 est alloué à l’étiquette Gamme d’onde.


Dans le contexte de la commutation de gamme d’onde, l’étiquette généralisée a le format suivant :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0828) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Identifiant de gamme d’ondes |

+---------------+---------------+---------------+---------------+

| Étiquette de début |

+---------------+---------------+---------------+---------------+

| Étiquette de fin |

+---------------+---------------+---------------+---------------+


Voir dans la [RFC3471] la description des paramètres.


2.3.1 Procédures

Les procédures définies au paragraphe 2.2.1 s’appliquent à la commutation de gamme d’onde. Cela inclut de générer un message Notification avec une indication "Problème d’acheminement/Échec d’allocation d’étiquette MPLS" si un des champs de l’étiquette est non reconnu ou inacceptable.


De plus, lorsque une gamme d’onde est commutée sur une autre gamme d’ondes, il est possible que les longueurs d’onde au sein de la gamme d’ondes soient reflétées par rapport à une fréquence centrale. Quand ce type de commutation est employé, les étiquettes de début et de fin du TLV de l’étiquette de gamme d’ondes DOIVENT être échangées avant de transmettre le TLV d’étiquette avec le nouvel identifiant de gamme d’ondes. De cette manière, un LSR de sortie/entrée qui reçoit une étiquette de gamme d’ondes qui a ces valeurs inversées sait qu’il doit aussi inverser son association de sortie pour collecter les longueurs d’onde appropriées. Sans ce mécanisme, et avec un nombre impair d’opérations de commutations reflétées, les LSR de sortie ne sauraient pas qu’une longueur d’onde d’entrée de, disons L1, va émerger du tunnel de gamme d’ondes comme L100.


Cette opération DOIT être effectuée dans les deux directions lorsque un tunnel de gamme d’ondes bidirectionnel est établi.


2.4 Étiquette suggérée


Le format d’une étiquette suggérée est identique à celui d’une étiquette généralisée. Il est utilisé dans les messages Demande. Les étiquettes suggérées utilisent le type = 0x904.


Les erreurs dans les étiquettes suggérées reçues DOIVENT être ignorées. Cela inclut toutes valeurs reçues incohérentes ou inacceptables.


Selon la [RFC3471], si un nœud aval passe une valeur d’étiquette qui diffère de l’étiquette suggérée par l’amont, le LSR amont DOIT soit se reconfigurer afin d’utiliser l’étiquette spécifiée par le nœud aval, soit générer un message Notification avec une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". De plus, un nœud d’entrée NE DEVRAIT PAS transmettre de trafic de données utilisant une étiquette suggérée tant que le nœud aval n’a pas passé l’étiquette correspondante vers l’amont.


2.5 Ensemble d’étiquettes


Le format d’un ensemble d’étiquettes est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0827) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Action | Réservé | Type d’étiquette |

+---------------+---------------+---------------+---------------+

| Sous-canal 1 |

| ... |

+---------------+---------------+---------------+---------------+

: : :

: : :

+---------------+---------------+---------------+---------------+

| Sous-canal N |

| ... |

+---------------+---------------+---------------+---------------+


Type d’étiquette : 14 bits

Indique le type et le format des étiquettes portées dans le TLV. Les valeurs correspondent au type de TLV du TLV Étiquette approprié.


Voir dans la [RFC3471] la description des autres paramètres.


2.5.1 Procédures

Un ensemble d’étiquettes est défini via un ou plusieurs TLV Ensemble d’étiquettes. Des étiquettes/sous-canaux spécifiques peuvent être ajoutés ou exclus d’un ensemble d’étiquettes via des TLV Action respectivement zéro (0) et un (1). Les gammes d’étiquettes/sous-canaux peuvent être ajoutés ou exclus d’un ensemble d’étiquettes via des TLV Action respectivement de deux (2) et trois (3). Lorsque les TLV Ensemble d’étiquettes n’énumèrent que les étiquettes/sous-canaux à exclure, cela implique que toutes les autres étiquettes sont acceptables.


L’absence de tout TLV Ensemble d’étiquettes implique que toutes les étiquettes sont acceptables. Un ensemble d’étiquettes est inclus lorsque un nœud souhaite recevoir la ou les étiquettes qui peuvent être utilisées vers l’aval.


À réception d’un message Demande, le nœud receveur va restreindre son choix d’étiquettes à une de celles qui se trouvent dans l’ensemble d’étiquettes. Les nœuds capables d’effectuer la conversion d’étiquettes peuvent aussi retirer l’ensemble d’étiquettes avant de transmettre le message Demande. Si le nœud n’est pas capable de prendre une étiquette dans l’ensemble d’étiquettes ou si il y a un problème pour analyser les TLV Ensemble d’étiquettes, la demande est alors terminée et un message Notification avec une indication "Problème d’acheminement/Ensemble d’étiquettes" DOIT être généré. C’est une affaire locale de décider si l’ensemble d’étiquettes est mémorisé pour un choix ultérieur sur le message Transposition ou si le choix est fait immédiatement pour être propagé dans le message Transposition.


À réception d’un message Demande, l’ensemble d’étiquettes représenté dans le message est comparé à l’ensemble des étiquettes disponibles à l’interface aval et l’ensemble résultant d’étiquettes qui se recoupent est transmis dans un message Demande. Lorsque l’ensemble d’étiquettes résultant est vide, la Demande doit être interrompue, et un message Notification DOIT être généré avec une indication "Problème d’acheminement/Ensemble d’étiquettes". Noter que l’intersection se fonde sur les étiquettes physiques (les valeurs réelles de longueur/gamme d’ondes) qui peuvent avoir des valeurs logiques différentes sur des liaisons différentes, il en résulte qu’il est de la responsabilité du nœud de transposer ces valeurs de façon à ce qu’elles aient une signification physique cohérente, ou d’abandonner les valeurs particulières de cet ensemble si aucune valeurs logique convenable n’existe.


Lors du traitement d’un message Transposition à un nœud intermédiaire, l’étiquette propagée en amont DOIT tomber dans l’ensemble d’étiquettes.


Noter qu’à réception d’un message Transposition, un nœud qui est incapable d’effectuer la conversion d’étiquettes n’a pas d’autre choix que d’utiliser la même étiquette physique (longueur/gamme d’onde) que celle reçue dans le message Transposition. Dans ce cas, l’utilisation et la propagation d’un ensemble d’étiquettes va significativement réduire les chances que cette allocation échoue.


3. LSP bidirectionnels


L’établissement des LSP bidirectionnels est indiqué par la présence d’une étiquette amont dans le message Demande. Une étiquette amont a le même format qu’une étiquette généralisée, voir au paragraphe 2.2. Étiquette amont utilise le type = 0x0826.


3.1 Procédures

Le processus d’établissement d’un LSP bidirectionnel suit celui de l’établissement d’un LSP unidirectionnel avec quelques ajouts. Pour prendre en charge les LSP bidirectionnels, une étiquette amont est ajoutée au message Demande. Étiquette amont DOIT indiquer une étiquette valide à la transmission au moment où le message Demande est envoyé.


Lorsque est reçu un message Demande qui contient une étiquette amont, le receveur vérifie d’abord que l’étiquette amont est acceptable. Si l’étiquette n’est pas acceptable, le receveur DOIT produire un message Notification avec une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". Le message Notification généré PEUT inclure un Ensemble d’étiquettes acceptable (voir à la Section 4).


Un nœud intermédiaire doit aussi allouer une étiquette sur l’interface sortante et établir des chemins de données internes avant de remplir une étiquette amont sortante et de propager le message Demande. Si un nœud intermédiaire est incapable d’allouer une étiquette ou des ressources internes, il DOIT alors produire un message Notification avec une indication "Problème d’acheminement/Échec d’allocation d’étiquette".


Les nœuds de terminaison traitent les messages Demande comme d’habitude, à l’exception que l’étiquette amont peut être utilisée immédiatement pour transporter du trafic de données associées au LSP amont vers l’initiateur.


Lorsque un LSP bidirectionnel est retiré, les deux étiquettes amont et aval sont invalidées et il n’est plus valide d’envoyer des données en utilisant les étiquettes qui y sont associées.


4. Notification d’erreur d’étiquette

La présente section définit le TLV Ensemble d’étiquettes acceptable pour la prise en charge des notifications sur les erreurs d’étiquettes conformément à la [RFC3471]. Un TLV Ensemble d’étiquettes acceptable utilise une valeur de type de 0x082a. Le contenu restant du TLV a un format identique à celui du TLV Ensemble d’étiquette décrit au paragraphe 2.5.


Les TLV Ensemble d’étiquettes acceptable peuvent être portés dans un message Notification. Les procédures pour définir un ensemble d’étiquettes acceptable suivent celles utilisées pour définir un ensemble d’étiquettes décrites au paragraphe 2.5.1. Précisément, un ensemble d’étiquettes acceptable est défini via un ou plusieurs TLV Ensemble d’étiquettes acceptable . Des étiquettes/sous-canaux spécifiques peuvent être ajoutés ou exclus d’un ensemble d’étiquettes acceptable via des TLV Action respectivement de zéro (0) et un (1). Des gammes d’étiquettes/sous-canaux peuvent être ajoutées ou exclues d’un ensemble d’étiquettes acceptable via des TLV Action respectivement de deux (2) et trois (3). Lorsque les TLV Ensemble d’étiquettes acceptable sont seulement une liste d’étiquettes/sous-canaux à exclure, cela implique que toutes les autres étiquettes sont acceptables.


L’inclusion de TLV Ensemble d’étiquettes acceptable est facultative. S’il en est d’inclus, le message Notification DEVRAIT contenir une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". L’absence de TLV Ensemble d’étiquettes acceptable n’a aucune signification spécifique.


5. Contrôle explicite d’étiquette

Le TLV Étiquette bond ER est défini comme suit :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type (0x0829) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

|L|U| Réservé | Étiquette |

+-+-+-----------+---------------+---------------+---------------+

| Étiquette (suite) |

| ... |

+---------------+---------------+---------------+---------------+


Voir dans la [RFC3471] la description des paramètres L, U et Étiquette.


5.1 Procédures

L’étiquette Bond ER suit un bond ER qui contient l’adresse IP, ou l’identifiant d’interface de la [RFC3480], associé à la liaison sur laquelle elle sera utilisée. Un maximum de deux étiquettes Bond ER peuvent être présentes, une pour l’étiquette aval et une pour l’étiquette amont. Ce qui suit DEVRAIT résulter en erreurs "Mauvais chemin explicite" :

o si la première étiquette Bond ER n’est pas précédée par un bond ER contenant une adresse IP, ou un identifiant d’interface de la [RFC3480], associé à une liaison de sortie,

o pour une étiquette Bond ER, de suivre un bond ER qui a le bit L établi,

o à l’établissement d’un LSP unidirectionnel, si il y a une étiquette Bond ER avec le bit U établi,

o si il y a deux étiquettes Bond ER avec la même valeur de bit U.


Pour prendre en charge l’étiquette Bond ER, un nœud doit vérifier si le bond ER qui suit son adresse/interface associée est une étiquette Bond ER. Si elle l’est, un bond ER est examiné à la recherche de LSP unidirectionnels et deux bonds ER pour des LSP bidirectionnels. Si le bit U du bond ER examiné est à zéro (0), alors la valeur de l’étiquette est copiée dans un nouveau TLV Ensemble d’étiquettes. Ce TLV Ensemble d’étiquettes DOIT être inclus dans le message Demande sortant correspondant.


Si le bit U du bond ER examiné est établi (1), alors la valeur de l’étiquette est à utiliser pour le trafic amont associé au LSP bidirectionnel. Si cette étiquette n’est pas acceptable, une erreur "Mauvais chemin explicite" DEVRAIT être générée. Si l’étiquette est acceptable, l’étiquette est copiée dans un nouveau TLV Étiquette amont. Ce TLV Étiquette amont DOIT être inclus dans le message Demande sortant correspondant.


Après traitement, les étiquettes Bond ER sont retirées du chemin explicite.


Noter qu’une implication des procédures ci-dessus est que l’étiquette Bond ER ne devrait jamais être le premier bond ER dans un message nouvellement reçu. Si l’étiquette Bond ER est le premier bond ER dans un chemin explicite reçu, il DEVRAIT alors être traité comme une erreur "Mauvais nœud strict".


Les procédures par lesquelles un LSR à l’extrémité de tête d’un LSP obtient les informations nécessaires pour construire l’étiquette Bond ER sortent du domaine d’application du présent document.


6. TLV Protection


L’utilisation du TLV Protection est facultative. Le TLV est inclus pour indiquer des attributs de protection spécifiques d’un LSP.


Le format du TLV Informations de protection est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0835) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

|S| Réservé |Fanions Lsn|

+-+-------------+---------------+---------------+---+-----------+


Voir dans la [RFC3471] la description des paramètres.


6.1 Procédures


Les nœuds de transit qui traitent un message Demande contenant un TLV Protection DOIVENT vérifier que la protection demandée peut être satisfaite par l’interface sortante ou le tunnel (FA). Si elle ne le peut pas, le nœud DOIT générer un message Notification, avec une indication "Problème d’acheminement/Protection de liaison non acceptée".


7. Informations d’état administratif


Les informations d’état administratif sont portées dans le TLV État administratif. Le TLV fournit des informations qui se rapportent à l’état administratif d’un LSP particulier. Les informations sont utilisées de deux façons. Dans la première, le TLV est porté dans les messages Demande et Transposition pour indiquer l’état administratif d’un LSP. Dans le second, le TLV est porté dans un message Notification pour demander un changement de l’état administratif d’un LSP.


7.1 TLV État administratif

L’utilisation du TLV État administratif est facultatif. Il utilise le type = 0x082b.


Le format du TLV État administratif dans les messages Demande, Transposition et Notification est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x082b) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

|R| Réservé |T|A|D|

+-+-------------+---------------+---------------+---------+-+-+-+


Voir dans la [RFC3471] la description des paramètres.


7.2 Procédures des messages Demande et Transposition

Le TLV État administratif est utilisé pour notifier à chaque nœud le long du chemin l’état du LSP. Chaque nœud traite les informations d’état sur la base de la politique locale et les propage ensuite dans les messages sortants correspondants. Le TLV est inséré dans les messages Demande à la discrétion du nœud d’entrée. L’absence du TLV est équivalente à recevoir un TLV contenant des valeurs toutes réglées à zéro.


Les nœuds de transit qui reçoivent un message Demande contenant un TLV État administratif mettent à jour leur état local, entreprennent toute action locale appropriée sur la base de l’état indiqué et ensuite propagent le TLV État administratif reçu dans le message Demande sortant.


Les nœuds bordure qui reçoivent un message Demande contenant un TLV État administratif mettent aussi à jour leur état local et entreprennent toute action locale appropriée sur la base de l’état indiqué. Lorsque le TLV État administratif est reçu avec le bit R établi, le nœud bordure receveur devrait refléter les valeurs reçues dans un message Transposition correspondant. Précisément, si un nœud de sortie reçoit un message Demande avec le bit R du TLV État administratif établi, le nœud DEVRAIT envoyer un message Transposition contenant un TLV État administratif avec les mêmes réglages de valeurs, à l’exception de celle du bit R, comme elles ont été reçues dans le message Demande correspondant.


7.2.1 Procédure de suppression

Dans certaines circonstances, en particulier de réseaux optiques, il est utile de régler l’état administratif d’un LSP avant de le supprimer.


Dans de telles circonstances, cette procédure DEVRAIT être suivie lors de la suppression d’un LSP à partir de l’entrée :

o Le nœud d’entrée fait précéder la suppression d’un LSP de l’insertion d’un TLV État administratif dans un message Notification qui établit les bits Refléter (R) et Supprimer (D).

o Les nœuds de transit traitent le TLV État administratif en passant le message Notification. Le nœud de sortie PEUT répondre par un message Notification avec le TLV État administratif.

o À réception du TLV État administratif avec le bit Supprimer (D) établi dans le message Notification, le nœud de sortie DEVRAIT répondre par un message Retrait d’étiquette et le traitement CR-LDP normal s’ensuivre.


Dans de telles circonstances, cette procédure DEVRAIT être suivie lors de la suppression d’un LSP à partir de la sortie :

o Le nœud de sortie indique son désir de suppression en insérant un TLV État administratif dans un message Notification et en établissant le bit Supprimer (D).

o Les nœuds de transit traitent le TLV État administratif comme décrit ci-dessus.

o À réception du TLV État administratif avec le bit Supprimer (D) établi dans le message Notification, le nœud d’entrée envoie un message Libération d’étiquette vers l’aval pour retirer le LSP et le traitement CR-LDP normal s’ensuit.


7.3 Procédures du message Notification

Les échanges suivants de l’échange de messages sur l’état administratif peuvent être effectués par des messages Notification. L’entrée peut commencer la propagation d’un message Notification par un TLV État administratif. Chaque nœud suivant propage la Notification avec le TLV État administratif de l’entrée à la sortie et ensuite le nœud de sortie retourne les messages Notification vers l’amont et qui portent le TLV État administratif.


Les nœuds intermédiaires et de sortie peuvent déclancher le réglage de l’état administratif via l’utilisation de messages Notification. Pour accomplir cela, un nœud intermédiaire ou de sortie génère un message Notification avec les informations de session notifiées en amont correspondantes. Le TLV État administratif DOIT être inclus dans les informations de session, avec le ou les bits appropriés établis. Le bit Refléter (R) NE DOIT PAS être établi.


Un nœud d’entrée ou de sortie qui reçoit un message Notification contenant un TLV État administratif avec le bit Supprimer (D) établi DEVRAIT initier la procédure de suppression décrite au paragraphe précédent.


7.3.1 Procédures de compatibilité et d’erreur

Un traitement spécial est nécessaire pour couvrir le cas des nœuds qui ne prennent pas en charge le TLV État administratif et autres conditions d’erreur. Précisément, un nœud qui envoie un message Notification contenant un TLV État administratif avec le bit Mort (D) établi DOIT vérifier qu’il reçoit un message Libération d’étiquette correspondant dans un délai configurable. Par défaut, ce délai DEVRAIT être de 30 secondes. Si le nœud ne reçoit pas un tel message Libération d’étiquette, il DEVRAIT envoyer vers l’aval un message Libération d’étiquette et un message Suppression d’étiquette vers l’amont.


8. Séparation du canal de contrôle


La présente section donne les formats et procédures spécifiques du protocole pour la prise en charge exigée d’un canal de contrôle qui n’est pas dans la bande avec un canal de données.


8.1 Identification d’interface

Le choix d’une interface de données à utiliser est toujours fait par l’envoyeur du message Demande. Le choix de l’interface de données est indiqué par l’envoyeur du message Demande en incluant l’identifiant d’interface du canal de données dans le message en utilisant un nouveau type de TLV Interface. Pour les LSP bidirectionnels, l’envoyeur choisit l’interface de données dans chaque direction. Dans tous les cas sauf celui du faisceau, l’interface amont est impliquée par l’interface aval. Pour les faisceaux, l’envoyeur de la Demande identifie explicitement l’interface composante utilisée dans chaque direction.


8.1.1 TLV ID d’interface

Le format d’un TLV identifiant d’interface IPV4 dans les messages Demande, Transposition est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x082d) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Adresse IPv4 de prochain/précédent bond |

+---------------+---------------+---------------+---------------+

| Identifiant d’interface logique |

+---------------+---------------+---------------+---------------+

| TLV d’ID d’interface (voir la [RFC3471] |

+---------------+---------------+---------------+---------------+


Le format d’un TLV identifiant d’interface IPV6 dans les messages Demande, Transposition est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x082e) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Adresse IPv6 de prochain/précédent bond |

+---------------+---------------+---------------+---------------+

| Identifiant d’interface logique |

+---------------+---------------+---------------+---------------+

| TLV d’ID d’interface (voir la [RFC3471] |

+---------------+---------------+---------------+---------------+


Voir dans la [RFC3471] la description des paramètres.


Voir dans la [RFC3212] la description d’une adresse de signalisation. Voir dans la [RFC3471] la description des paramètres et codages des TLV.


8.1.2 Procédures

Un TLV IF_ID est utilisé sur des liaisons où il n’y a pas une association bijective d’un canal de contrôle à un canal de données (voir la [RFC3471]).


La session LDP utilise le TLV IF_ID pour identifier le ou les canaux de données associés au LSP. Pour un LSP unidirectionnel, un canal de données vers l’aval DOIT être indiqué. Pour les LSP bidirectionnels, un canal commun vers l’aval et vers l’amont est normalement indiqué. Dans le cas particulier où un LSP bidirectionnel qui traverse une liaison en faisceau, il est possible de spécifier un canal de données vers l’aval qui diffère du canal de données vers l’amont. Les canaux de données sont spécifiés du point de vue de l’envoyeur d’un message Demande. Le TLV IF_ID NE DEVRAIT PAS être utilisé lorsque un TLV n’est pas nécessaire.


Un nœud qui reçoit un ou plusieurs TLV IF_ID dans un message Demande sauvegarde leurs valeurs et les retourne dans le message Transposition suivant envoyé au nœud qui a généré les TLV.


Noter que le nœud qui a généré un TLV IF_ID DOIT s’assurer que l’interface sortante choisie, comme spécifié dans le TLV IF_ID, est cohérente avec un ERO. Un nœud qui reçoit un TLV IF_ID DEVRAIT vérifier si les informations portées dans ce TLV sont cohérentes avec les informations portées dans un ERO reçu, et si elles ne le sont pas, il DOIT envoyer un message Interruption d’étiquette avec le code d’erreur "Erreur d’acheminement" et la valeur d’erreur de "Erreur de mauvais TLV d’acheminement explicite" vers l’envoyeur. Cette vérification NE PEUT PAS être effectuée lorsque le sous-objet ERO initial n’est pas l’interface entrante.


8.2 Identification d’interface erronée

Il y a des cas où il est utile d’indiquer une interface spécifique associée à une erreur. Pour prendre en charge ces cas, le TLV État d’IF_ID est défini.


8.2.1 TLV d’état IF_ID

Le format du TLV État d’IF_ID IPv4 est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x082f) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| Adresse IPv4 de prochain/précédent bond |

+---------------+---------------+---------------+---------------+

| Code d’état |

+---------------+---------------+---------------+---------------+

| |

~ TLV ~

| |

+---------------+---------------+---------------+---------------+


Le format du TLV État d’IF_ID IPv6 est :


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|U|F| Type (0x0830) | Longueur |

+-+-+-----------+---------------+---------------+---------------+

| |

| Adresse IPv6 de nœud erroné |

| |

| |

+---------------+---------------+---------------+---------------+

| Code d’état |

+---------------+---------------+---------------+---------------+

| |

~ TLV ~

| |

+---------------+---------------+---------------+---------------+


Voir dans la [RFC3036] la description des champs de valeur de code d’état. Voir dans la [RFC3471] la description des paramètres et codage des TLV.


8.2.2 Procédures

Les nœuds qui souhaitent indiquer qu’une erreur se rapporte à une interface spécifique DEVRAIENT utiliser le TLV État d’IF_ID approprié dans le message Retrait d’étiquette ou Libération d’étiquette correspondant. Le TLV État d’IF_ID DEVRAIT être généré et traité comme tout autre TLV État, voir la [RFC3036].


9. Traitement des fautes


Dans les réseaux de transport optiques, les défaillances dans le plan de contrôle optique ou la communication de signalisation hors fibre ne devraient pas avoir d’impact de service sur les connexions optiques existantes. Dans de telles circonstances, un mécanisme DOIT exister pour détecter une défaillance de communication de signalisation et une procédure de restauration DEVRA garantir l’intégrité de la connexion aux deux extrémités du canal de signalisation.


Le document sur la tolérance de fautes dans LDP [RFC3479] spécifie les procédures de récupération des sessions LDP et CR-LDP en cas de défaillance. Prière de se référer à ces documents pour les procédures de récupération sur les connexions optiques. Actuellement, le document sur la tolérance de fautes couvre beaucoup des modes courants de défaillance pour des plans de données et de contrôle séparés.


10. Remerciements


Le présent document est le résultat du travail de nombreux auteurs et consiste en l’agrégation d’un certain nombre de documents précédents sur ce domaine.


Des commentaires et apports précieux ont été reçus d’un certain nombre de gens, en particulier Adrian Farrel.


11. Considérations pour la sécurité


Le présent document n’introduit aucune nouvelle considération de sécurité par rapport à la [RFC3212].


12. Considérations relatives à l’IANA


Le présent document utilise les espaces de nom de LDP [RFC3036], voir à http://www.iana.org/assignments/ldp-namespaces, qui fait la liste des allocations pour les TLV suivants :

o Demande d’étiquette généralisée (TLV 0x0824)

o Étiquette généralisée (TLV 0x0825)

o Étiquette amont (TLV 0x0826)

o Ensemble d’étiquettes (TLV 0x0827)

o Étiquette de gamme d’ondes (TLV 0x0828)

o Bond ER (TLV 0x0829)

o Ensemble d’étiquettes acceptable (TLV 0x082a)

o État administratif (TLV 0x082b)

o Identifiant d’interface (TLV 0x082c)

o Identifiant d’interface IPV4 (TLV 0x082d)

o Identifiant d’interface IPV6 (TLV 0x082e)

o État d’IF_ID IPv4 (TLV 0x082f)

o Identifiant d’interface IPv6 (TLV 0x0830)

o Protection (TLV 0x0835)


13. Considérations de propriété intellectuelle


Ce paragraphe est tiré du paragraphe 10.4 de la [RFC2026].

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 le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.


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


14. Références

14.1 Références normatives


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


[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)


[RFC3212] B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (P.S.)


[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) (P.S.)


14.2 Références pour information


[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)


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


[RFC3479] A. Farrel, éd., "Tolérance aux fautes dans le protocole de distribution d'étiquettes (LDP)", février 2003. (P.S.)


[RFC3480] K. Kompella, Y. Rekhter, A. Kullberg, "Signalisation des liaisons non numérotées dans le protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)", février 2003. (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.)


15. Contributeurs


Peter Ashwood-Smith

Ayan Banerjee

Lou Berger

Nortel Networks Corp.

Calient Networks

Movaz Networks, Inc.

P.O. Box 3511 Station C,

5853 Rue Ferrari

7926 Jones Branch Drive

Ottawa, ON K1Y 4H7

San Jose, CA 95138

Suite 615

Canada

USA

McLean VA, 22102

téléphone : +1 613 763 4534

téléphone : +1 408 972-3645

téléphone : +1 703 847-1801

mél : petera@nortelnetworks.com

mél : abanerjee@calient.net

mél : lberger@movaz.com


Greg Bernstein

Jonathan P. Lang

Debanjan Saha

Z. Bo Tang

mél : gregb@grotto-networking.com

mél : jplang@ieee.org

mél : debanjan@acm.org

mél : botang01@yahoo.com


Yanhe Fan

Don Fedyk

Eric Mannie

Axiowave Networks, Inc.

Nortel Networks Corp.

Independent Consultant

200 Nickerson Road

600 Technology Park

2 Avenue de la Folle Chanson

Marlborough, MA 01752

Billerica MA 01821

1050 Brussels

USA

USA

Belgium

téléphone : + 1 774 348 4627

téléphone : +1 978 288 3041

mél : eric_mannie@hotmail.com

mél : yfan@axiowave.com

mél : dwfedyk@nortelnetworks.com



Bala Rajagopalan

Vishal Sharma

George Swallow

Tellium, Inc.

Metanoia, Inc.

Cisco Systems, Inc.

2 Crescent Place

1600 Villa Street, Unit 352

250 Apollo Drive

P.O. Box 901

Mountain View, CA 94041-1174

Chelmsford, MA 01824

Oceanport, NJ 07757-0901

USA

USA

téléphone : +1 732 923 4237

téléphone : +1 650-386-6723

téléphone : +1 978 244 8143

mél : braja@tellium.com

mél : v.sharma@ieee.org

mél : swallow@cisco.com


16. Adresse des éditeurs


Peter Ashwood-Smith

Lou Berger

Nortel Networks Corp.

Movaz Networks, Inc.

P.O. Box 3511 Station C,

7926 Jones Branch Drive

Ottawa, ON K1Y 4H7

Suite 615

Canada

McLean VA, 22102

téléphone : +1 613 763 4534

téléphone : +1 703 847-1801

mél : petera@nortelnetworks.com

mél : lberger@movaz.com


17. Déclaration de droits de reproduction


Copyright (C) The Internet Society (2003). Tous droits réservés.


Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l’Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.