RFC 3473 page - 24 - Berger


Groupe de travail Réseau

L. Berger, éditeur

Request for Comments : 3473

Movaz Networks

Catégorie : En cours de normalisation

janvier 2003

Traduction Claude Brière de L'Isle




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)



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 de l’ingénierie de trafic du protocole de réservation de ressource (RSVP-TE, Resource ReserVation Protocol - Traffic Engineering) de commutation d’étiquette multi protocole (MPLS, Multi-Protocol Label Switching) nécessaire 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, de réseau optique synchrone et de hiérarchie numérique synchrone (SONET/SDH, Synchronous Optical Network/Synchronous Digital Hierarchy)) la longueur d’onde (lambdas optiques) et la commutation spatiale (par exemple, de l’accès ou la fibre entrant à l’accès ou la fibre sortant). Le présent document présente une description spécifique de RSVP-TE des extensions. Une description fonctionnelle générique se trouve dans des documents distincts.


Table des matières

1. Introduction 2

2. Formats en rapport avec les étiquettes 2

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

2.2 Codage de la bande passante 3

2.3 Objet Étiquette généralisée 3

2.4 Objet Commutation de gamme d’ondes 4

2.5 Objet Étiquette_suggérée 4

2.6 Objet Ensemble_d’étiquettes 4

3 LSP bidirectionnels 6

3.1 Procédures 6

3.2 Résolution de conflit 6

4. Notification 6

4.1 Objet Ensemble_d’étiquettes_acceptable 6

4.2 Objet Demande_de_notifier 7

4.3 Message Notifier 8

4.4 Retrait d’état avec un message PathErr 8

5. Contrôle explicite d’étiquette 9

5.1. Sous-objet Étiquette ERO 9

5.2 Sous-objet Étiquette RRO 10

6. Objet Protection 10

6.1 Procédures 11

7. Informations d’état administratif 11

7.1. Objet État_administratif 11

7.2 Procédures des messages Path et Resv 11

7.3 Procédures du message Notifier 12

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

8.1 Identification d'interface 13

8.2 Identification d’interface erronée 14

9. Traitement des fautes 15

9.1 Objet Restart_Cap 15

9.2 Traitement de l’objet Restart_Cap 15

9.3 Modification au traitement de Hello pour la prise en charge de la récupération d’état 16

9.4 Fautes du canal de contrôle 16

9.5 Fautes nodales 16

10. Formats et traitements des messages RSVP 18

10.1 Formats de message RSVP 18

10.2 Adressage des messages Path, PathTear et ResvConf 19

11. Remerciements 19

12. Considérations pour la sécurité 19

13. Considérations relatives à l'IANA 20

13.1 Allocations de l'IANA 20

14. Considérations de propriété intellectuelle 21

15. Références 22

15.1 Références normatives 22

15.2 Références pour information 22

16. Contributeurs 22

17. Adresse de l'éditeur 23

18. Déclaration de droits de reproduction 23


1. Introduction

MPLS généralisé étend MPLS de la prise en charge des interfaces et commutation de paquet (PSC) pour y inclure la prise en charge de trois nouvelles classes d’interfaces et de commutation : le multiplexage à répartition dans le temps (TDM, Time-Division Multiplex), la commutation Lambda (LSC, Lambda Switch) et la commutation par fibre (FSC, Fiber-Switch). Une description fonctionnelle des extensions à la signalisation MPLS nécessaires pour prendre en charge les 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 RSVP-TE qui sont nécessaires pour la prise en charge des quatre classes d’interfaces.

La [RFC3471] devrait être vue comme un document d’accompagnement du présent document. Le format de ce document est parallèle à celui de la [RFC3471]. En plus des autres caractéristiques de MPLS généralisé, le présent document définit aussi les caractéristiques spécifiques de RSVP-TE pour la prise en charge de la notification rapide de défaillance, voir aux paragraphes 4.2 et 4.3.

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 pour une demande d’étiquette généralisée, pour une étiquette généralisée, pour la prise en charge de la commutation de gamme d’ondes, pour les étiquettes et ensembles d’étiquettes suggérés.


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

Un message Chemin DEVRAIT contenir un type de codage de chemin de commutation d’étiquette (LSP, Label Switched Path) aussi spécifique que possible pour permettre la souplesse maximum dans la commutation par les LSR de transit. Un objet 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’un objet 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

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

| Longueur | Class-Num (19)| C-Type (4) |

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

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

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


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


2.1.1 Procédures

Un nœud qui traite un message Path contenant une demande d’étiquette généralisée doit vérifier que les paramètres demandés peuvent être satisfaits par l’interface sur laquelle l’étiquette entrante va être allouée, par le nœud lui-même, et pat l’interface sur laquelle le trafic sera transmis. Le nœud peut prendre directement en charge le LSP ou il peut utiliser un tunnel (FA), c’est-à-dire, une autre classe de commutation. Dans l’un et l’autre cas, chaque paramètre doit être vérifié.


Noter que la politique du nœud local dicte quand les tunnels peuvent être utilisés et quand ils peuvent être créés. La politique locale peut permettre l’établissement dynamique des tunnels ou peut être seulement contrôlée administrativement. Pour plus d’informations sur les tunnels et le traitement des bonds ER lors de l’utilisation des 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ée, que l’interface ou le tunnel sur lequel le trafic va être transmis, peuvent prendre en charge le type de codage de LSP demandé. Si le codage ne peut pas être pris en charge, le nœud DOIT générer un message PathErr, avec une indication de "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 pris en charge sur l’interface entrante correspondante. Si le type ne peut pas être accepté, le nœud DOIT générer un message PathErr avec l’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 pas être pris en charge, la sortie DOIT alors générer un message PathErr, avec l’indication "Problème d’acheminement/L3PID non accepté". Dans le cas de PSC et lorsque le saut de l’avant dernier bond (PHP) est demandé, l’avant dernier bond examine aussi le G-PID (mémorisé) durant le traitement du message Resv. Dans ce cas, si le G-PID n’est pas pris en charge, alors l’avant dernier bond DOIT générer un message ResvErr avec l’indication "Problème d’acheminement/Valeur d’étiquette inacceptable". Le message ResvErr généré PEUT inclure un ensemble d’étiquettes acceptable, voir au paragraphe 4.1.


Lorsque un message d’erreur n’est pas généré, le traitement normal survient. Dans le cas de transit, cela va normalement résulter en la propagation d’un message Path. Dans le cas de sortie et dans le cas particulier de PHP, cela va normalement résulter en la génération d’un message Resv.


2.2 Codage de la bande passante

Les codages de bande passante sont portés dans les objets SENDER_TSPEC et FLOWSPEC. Voir dans la [RFC3471] la définition des valeurs à utiliser pour les types de signaux spécifiques. Ces valeurs sont réglées dans le champ Taux de données de crête des objets Int-Serv, voir la [RFC2210]. Les autres paramètres en rapport avec la bande passante/service dans l’objet sont ignorés et portés de façon transparente.


2.3 Objet Étiquette généralisée

Le format de l’objet É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

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

| Longueur | Class-Num (16)| C-Type (2) |

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

| Étiquette |

| ... |

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


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


2.3.1 Procédures

L’étiquette généralisée voyage dans la direction de l’amont dans les messages Resv.


La présence des deux objets Étiquette généralisée et normale dans un message Resv est une erreur de protocole et devrait être traité comme un message mal formé par le receveur.


Le receveur d’un message Resv contenant 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 ResvErr avec une indication "Problème d’acheminement/Échec d’allocation d’étiquette MPLS".


2.4 Objet Commutation de gamme d’ondes

La commutation de gamme d’ondes utilise le même format que l’étiquette généralisée, voir au paragraphe 2.2. L’étiquette de gamme d’ondes utilise le C-Type (3),


Dans le contexte de la commutation de gamme d’ondes, 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

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

| Longueur | Class-Num (16)| C-Type (3) |

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

| Identifiant de gamme d’ondes |

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

| Étiquette de début |

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

| Étiquette de fin |

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


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


2.4.1 Procédures

Les procédures définies au paragraphe 2.3.1 s’appliquent à la commutation de gamme d’ondes. Cela inclut de générer un message ResvErr 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’ondes 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 autour d’une fréquence centrale. Lorsque ce type de commutation est employé, l’étiquette de début et de fin dans l’objet Étiquette de gamme d’ondes DOIT être retournée avant de transmettre l’objet Étiquette avec le nouvel identifiant de gamme d’ondes. De cette manière, un LSR d’entrée/sortie qui reçoit une étiquette de gamme d’onde qui a ces valeurs inversées, sait qu’il doit aussi inverser son association de sortie pour avoir les longueurs d’onde appropriées.


Cette opération DOIT être effectuée dans les deux directions lors de l’établissement d’un tunnel de gamme d’ondes bidirectionnel.


2.5 Objet Étiquette_suggérée

Le format de l’objet Étiquette_suggérée est identique à celui d’une étiquette généralisée. Il est utilisé dans les messages Path. Un objet Étiquette_suggérée utilise le numéro de classe 129 (de forme 10bbbbbb) et le C-Type de l’étiquette suggérée.


Les erreurs dans les objets Étiquette_suggérée reçus 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 ou générer un message ResvErr 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 en utilisant une étiquette suggérée tant que le nœud aval n’a pas passé en amont une étiquette correspondante.


2.6 Objet Ensemble_d’étiquettes

L’objet Ensemble_d’étiquettes utilise le numéro de classe 36 (de forme 0bbbbbbb) et le C-Type de 1. Il est utilisé dans les messages Path.


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

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

| Longueur | Class-Num (36)| C-Type (1) |

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

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

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

| Sous-canal 1 |

| ... |

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

: : :

: : :

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

| Sous-canal N |

| ... |

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


Type d’étiquette : 14 bits

Indique le type et le format de l’étiquettes portée dans l’objet. Les valeurs correspondent au C-Type de l’objet RSVP_LABEL approprié. Seuls les 8 bits de moindre poids sont utilisés dans ce champ.


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


2.6.1 Procédures

Un ensemble d’étiquettes est défini via un ou plusieurs objets Ensemble_d’étiquettes. Des étiquettes/sous-canaux spécifiques peuvent être ajoutés ou exclus d’un ensemble d’étiquettes via les objets 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 via les objets Action respectivement deux (2) et trois (3). Lorsque les objets Ensemble_d’étiquettes n’énumèrent que des étiquettes/sous-canaux à exclure, ceci implique que toutes les autres étiquettes sont acceptables.


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


À réception d’un message Path, le nœud receveur va restreindre son choix d’étiquettes à une de celles qui sont dans l’ensemble d’étiquettes. Les nœuds capable d’effectuer la conversion d’étiquettes peuvent aussi retirer l’ensemble d’étiquettes avant de transmettre le message Path. 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 d’analyse des objets Ensemble_d’étiquettes, la demande se termine alors et un message PathErr avec une indication "Problème d’acheminement/Ensemble d’étiquettes" DOIT être généré. Savoir si l’ensemble d’étiquettes est mémorisé pour un choix ultérieur sur le message Resv ou si le choix est fait immédiatement pour propagation dans le Resv est une affaire locale.


À réception d’un message Path, l’ensemble d’étiquettes représenté dans le message est comparé à l’ensemble des étiquettes disponible sur l’interface aval et l’intersection d’ensemble d’étiquettes résultante est transmise dans un message Path. Lorsque l’ensemble d’étiquettes résultant est vide, le message Path doit être terminé, et un message PathErr, et une indication "Problème d’acheminement/Ensemble d’étiquettes" DOIVENT être générés. Noter que comme 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 est de la responsabilité du nœud de transposer ces valeurs de telle sorte qu’elles aient une signification physique cohérente, ou d’abandonner les valeurs particulières de l’ensemble si il n’existe aucune valeur convenable d’étiquette logique.


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


Noter qu’à réception d’un message Resv 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 (gamme/longueur d’onde) que reçue dans le message Resv. Dans ce cas, l’utilisation et la propagation d’un ensemble d’étiquettes va significativement réduire les chances d’échec de cette allocation.


3 LSP bidirectionnels


L’établissement d’un LSP bidirectionnel est indiqué par la présence d’une étiquette amont dans le message Path. Un objet Étiquette_amont a le même format que l’étiquette généralisée, voir au paragraphe 2.3. L’objet Étiquette_amont utilise le numéro de classe 35 (de forme 0bbbbbbb) et le C-Type de l’étiquette utilisée.


3.1 Procédures

Le processus d’établissement d’un LSP bidirectionnel suit l’établissement d’un LSP unidirectionnel avec quelques ajouts. Pour prendre en charge les LSP bidirectionnels, un objet Étiquette amont est ajouté au message Path. L’objet Étiquette_amont DOIT indiquer une étiquette valide pour la transmission au moment de l’envoi du message Path.


Lorsque un message Path contenant un objet Étiquette_amont est reçu, 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 PathErr avec une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". Le message PathErr généré PEUT inclure un ensemble d’étiquettes acceptable, voir au paragraphe 4.1.


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 Path. Si un nœud intermédiaire n’est pas capable d’allouer une étiquette ou des ressources internes, il DOIT alors produire un message PathErr avec une indication "Problème d’acheminement/Échec d’allocation d’étiquette MPLS".


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


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


3.2 Résolution de conflit

Il y a deux considérations supplémentaires de résolution de conflit qui s’y rapportent lors du contrôle de l’établissement de LSP bidirectionnels via RSVP-TE. La première est que pour les besoins de la résolution de conflit dans RSVP, l’identifiant du nœud est l’adresse IP utilisée dans l’objet RSVP_HOP. La seconde est qu’un identifiant de nœud voisin peut n’être pas connu lors de l’établissement d’un message Path initial. Lorsque ce cas survient, un nœud devrait suggérer une étiquette choisie au hasard à partir de l’espace d’étiquettes disponible.


4. Notification


La présente section couvre plusieurs extensions en rapport avec la notification. La première extension définit l’objet Ensemble_d’étiquettes_acceptable pour prendre en charge la notification sur erreur d’étiquette, conformément à la [RFC3471]. Les seconde et troisième extensions permettent l’expédition de notifications d’échec et autres événements aux nœuds chargés de restaurer les LSP défaillants. (La seconde extension, l’objet Demande de notification, identifie quand les notifications d’événements sont à envoyer. La troisième extension, le message Notifier, permet une notification d’événement général.) La dernière extension en rapport avec la notification permet le retrait de l’état Chemin pendant le traitement des messages PathErr.

4.1 Objet Ensemble_d’étiquettes_acceptable

Les objets Ensemble_d’étiquettes_acceptable utilisent le numéro de classe 130 (de forme 10bbbbbb). Le contenu restant de l’objet, y compris le C-Type, ont un format identique à celui de l’objet Ensemble_d’étiquettes, voir au paragraphe 2.6.


Les objets Ensemble_d’étiquettes_acceptable peuvent être portés dans les messages PathErr et ResvErr. Les procédures de définition d’un ensemble d’étiquettes acceptable suivent celles de la définition d’un ensemble d’étiquettes, voir au paragraphe 2.6.1. Précisément, un ensemble d’étiquettes acceptable est défini via un ou plusieurs objets Ensemble d’étiquettes acceptable. Des étiquettes/sous-canaux spécifiques peuvent être ajoutés ou exclus d’un ensemble d’étiquettes acceptable via les objets Action respectivement zéro (0) et un (1). Des gammes d’étiquettes/sous-canaux peuvent être ajoutés ou exclus d’un ensemble d’étiquettes acceptable via les objets Action respectivement deux (2) et trois (3). Lorsque les objets Ensemble_d’étiquettes_acceptable énumèrent seulement des étiquettes/sous-canaux à exclure, ceci implique que toutes les autres étiquettes sont acceptables.


L’inclusion des objets Ensemble_d’étiquettes_acceptable est facultative. Si il est inclus, le message PathErr ou ResvErr DEVRAIT contenir une indication "Problème d’acheminement/Valeur d’étiquette inacceptable". L’absence des objets Ensemble_d’étiquettes_acceptable n’a aucune signification spécifique.


4.2 Objet Demande_de_notifier

Des notifications peuvent être envoyées via le message Notifier défini ci-dessous. L’objet Demande_de_notifier est utilisé pour demander la génération de notifications. Les Notifications, c’est-à-dire, l’envoi d’un message Notifier, peuvent être demandées dans les directions aussi bien amont qu’aval.


4.2.1 Informations requises

L’objet Demande_de_notifier peut être porté dans les messages Path ou Resv, voir à la section 7. Le numéro de classe de Demande_de_notifier est 195 (de forme 11bbbbbb). Le format d’une demande de notifier est :


o Objet IPv4 Demande-de-notifier


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

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

| Longueur | Class-Num (1) | C-Type (1) |

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

| Adresse IPv4 du nœud notifié |

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


Adresse IPv4 du nœud notifié : 32 bits

C’est l’adresse IP du nœud qui devrait être notifié lors de la génération d’un message d’erreur.


o Objet IPv6 Demande_de_notifier


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

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

| Longueur | Class-Num (2) | C-Type (2) |

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

| |

| Adresse IPv6 du nœud notifié |

| |

| |

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


Adresse IPv6 du nœud notifié : 16 octets

C’est l’adresse IP du nœud qui devrait être notifié lors de la génération d’un message d’erreur.


Si un message contient plusieurs objets Demande_de_notifier, seul le premier objet est significatif. Les objets Demande_de_notifier suivants PEUVENT être ignorés et NE DEVRAIENT PAS être propagés.


4.2.2 Procédures

Un objet Demande_de_notifier peut être inséré dans les messages Path ou Resv pour indiquer l’adresse d’un nœud qui devrait être notifié d’une défaillance de LSP. Comme on l’a mentionné précédemment, les notifications peuvent être demandées dans les deux directions amont et aval. La notification vers l’amont est indiquée via l’inclusion d’un objet Demande_de_notifier dans le message Path correspondant. La notification vers l’aval est indiquée via l’inclusion d’un objet Demande_de_notifier dans le message Resv correspondant.


Un nœud qui reçoit un message contenant un objet Demande_de_notifier DEVRAIT mémoriser l’adresse du nœud notifié dans le bloc d’état correspondant. Si le nœud est de transit, il DEVRAIT aussi inclure un objet Demande_de_notifier dans le message Path ou Resv sortant. L’adresse du nœud notifié sortant PEUT être mise à jour sur la base de la politique locale.


Noter que l’inclusion d’un objet Demande_de_notifier ne garantit pas qu’un message Notifier sera généré.


4.3 Message Notifier

Le message Notifier fournit un mécanisme pour informer des nœuds non adjacents des événements qui se rapportent au LSP. Les messages Notifier sont normalement générés seulement après la réception d’un objet Demande_de_Notifier. Le message Notifier diffère des messages d’erreur actuellement définis (c’est-à-dire, les messages PathErr et ResvErr) en ce qu’il peut être "ciblé" sur un nœud autre que le voisin immédiat vers l’amont ou vers l’aval et qu’il est un mécanisme de notification généralisé. Le message Notifier ne remplace pas les messages d’erreur existants. Le message Notifier peut être envoyé soit (a) normalement, lorsque des nœuds non cibles transmettent juste le message Notifier au nœud cible, selon un traitement similaire à celui de ResvConf dans la [RFC2205], ou (b) encapsulé dans un nouvel en-tête IP dont la destination est égale à l’adresse IP cible. Sans considération du mécanisme de transmission, les nœuds qui reçoivent un message Notifier qui ne leur est pas destiné transmettent le message, non modifié, vers la cible.


Pour prendre en charge la livraison fiable des messages Notifier, un message Ack [RFC2961] est utilisé pour accuser réception d’un message Notifier. Voir dans la [RFC2961] les détails sur la livraison fiable des messages RSVP.


4.3.1 Informations requises

Le message Notifier est un message de notification généralisé. L’adresse IP de destination est réglée à l’adresse IP du receveur prévu. Le message Notifier est envoyé sans l’option Alerte du routeur. Un seul message Notifier peut contenir des notifications à envoyer, par rapport à chaque session énumérée, aussi bien vers l’amont que vers l’aval.


Le message Notifier a le type de message 21. Le format du message Notifier est le suivant :


<message Notifier> ::= <en-tête commun> [<INTÉGRITÉ>] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ <MESSAGE_ID> ] <ERREUR_SPEC> <liste session notifiée>

<liste session notifiée>> ::= [ <liste session notifiée>> ] <session notifiée amont> | <session notifiée aval>

<session notifiée amont> ::= <SESSION> [ <ADMIN_STATUS> ] [<POLICY_DATA>...] <descripteur de l’envoyeur>

<session notifiée aval> ::= <SESSION> [<DONNÉES_DE_POLITIQUE>...] <liste de descripteurs de flux>


L’objet ERREUR_SPEC spécifie l’erreur et comporte l’adresse IP soit du nœud qui a détecté l’erreur soit de la liaison qui est défaillante. Voir la définition de ERREUR_SPEC dans la [RFC2205]. Le MESSAGE_ID et les objets en rapport sont définis dans la [RFC2961] et sont utilisés quand la [RFC2961] est prise en charge.


4.3.2 Procédures

Les messages Notifier sont le plus couramment générés aux nœuds qui détectent une erreur qui va déclancher la génération d’un message PathErr ou ResvErr. Si un message PathErr doit être généré et si un objet Demande_de_Notifier a été reçu dans le message Path correspondant, alors un message Notifier destiné au nœud enregistré DEVRAIT être généré. Si un message ResvErr doit être généré et si un objet Demande_de_Notifier a été reçu dans le message Resv correspondant, alors un message Notifier destiné au nœud enregistré DEVRAIT être généré. Comme mentionné précédemment, une seule erreur peut générer un message Notifier dans les deux directions amont et aval. Noter qu’un message Notifier NE DOIT PAS être généré tant qu’un objet Demande_de_Notifier approprié n’a pas été reçu.


En générant des messages Notifier, un nœud DEVRAIT tenter de combiner les notifications à envoyer sur le même nœud notifié et qui partagent la même ERREUR_SPEC en un seul message Notifier. Les moyens par lesquels un nœud détermine quelles informations peuvent être combinées dépendent de la mise en œuvre. Les mises en œuvre peuvent utiliser des approches fondées sur l’événement, sur un temporisateur, ou autres. Dans le cas d’une approche fondée sur l’utilisation d’un temporisateur, la mise en œuvre DEVRAIT permettre à l’usager de configurer l’intervalle sur lequel les notifications sont combinées. Dans une approche fondée sur un temporisateur, un "intervalle de notification " par défaut de 1 ms DEVRAIT être utilisé. Les messages Notifier DEVRAIENT être livrés en utilisant les mécanismes de livraison fiable de message définis dans la [RFC2961].


À réception d’un message Notifier, le nœud notifié DEVRAIT envoyer un message d’accusé de réception correspondant.


4.4 Retrait d’état avec un message PathErr

Le message PathErr tel que défini dans la [RFC2205] est envoyé bond par bond à la source du message Path associé. Les nœuds intermédiaires peuvent inspecter ce message, mais pas effectuer d’action sur lui. Dans un environnement où les messages Path sont acheminés conformément à un IGP et où ce chemin peut changer de façon dynamique, ce comportement est un choix de conception fin.


Cependant, lorsque RSVP est utilisé avec des chemins explicites, il est souvent le cas que les erreurs ne puissent être corrigées qu’au nœud source ou à quelque autre nœud plus en amont. Afin de nettoyer les ressources, la source doit recevoir le PathErr et ensuite envoyer un PathTear (ou attendre que les messages arrivent en fin de temporisation). Ceci est cause que des ressources inactives sont détenues plus longtemps que nécessaire et augmente la charge en messages de contrôle. Dans une situation où le plan de contrôle tente de récupérer d’une panne sévère, la charge de messages et le délai de libération des ressources amoindrissent la capacité à reconverger rapidement.


La situation peut être grandement améliorée en permettant que l’état soit retiré par les nœuds intermédiaires dans certaines conditions d’erreur. Pour faciliter cela, un nouveau fanion est défini dans l’objet ERREUR_SPEC. Les deux objets ERREUR_SPEC actuellement définis (les objets erreur spec IPv4 et IPv6) contiennent chacun un champ fanion d’un octet. Au sein de ce champ, deux fanions sont définis. La présente spécification définit un troisième fanion, 0x04, État_de_chemin_retiré.


La sémantique du fanion État_de_chemin_retiré est simplement que le nœud qui transmet le message d’erreur a retiré l’état de chemin associé au PathErr. Par défaut, le fanion État_de_chemin_retiré est toujours réglé à zéro quand est généré ou transmis un message PathErr. Un nœud qui rencontre une erreur PEUT établir ce fanion si l’erreur résulte en l’élimination de l’état de chemin associé. Si le nœud qui établit le fanion n’est pas le point de terminaison de la session, le nœud DEVRAIT générer un PathTear correspondant. Un nœud qui reçoit un message PathErr contenant un objet ERREUR_SPEC avec le fanion État_de_chemin_retiré établi PEUT aussi retirer l’état de chemin associé. Si l’état du chemin est retiré, le fanion État_de_chemin_retiré DEVRAIT être établi dans le message PathErr sortant. Un nœud qui ne retire pas l’état de chemin associé NE DOIT PAS établir le fanion État_de_chemin_retiré. Un nœud qui reçoit une erreur avec le fanion État_de_chemin_retiré réglé à zéro NE DOIT PAS établir ce fanion sauf si il génère aussi un message PathTear correspondant.


Noter que l’utilisation de ce fanion ne résulte en aucune incompatibilité d’interopérabilité.


5. Contrôle explicite d’étiquette


Les sous-objets Étiquette ERO (objet Chemin explicite) et RRO (objet Chemin enregistré) sont définis pour prendre en charge le contrôle explicite d’étiquette. Noter que le sous-objet Étiquette RRO a été défini dans la [RFC3209] et qu’il est étendu pour la prise en charge des LSP bidirectionnels.


5.1. Sous-objet Étiquette ERO


Le sous-objet Étiquette ERO 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

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

|L| Type | Longueur |U| Réservé | C-Type |

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

| Étiquette |

| ... |

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


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


Type : 3 Étiquette


Longueur

Longueur contient la longueur totale du sous-objet en octets, y compris les champs Type et Longueur. La longueur est toujours divisible par 4.


C-Type

C’est le C-Type de l’objet Étiquette inclus, copié de l’objet Étiquette.


5.1.1 Procédures

Le sous-objet Étiquette suit un sous-objet qui contient l’adresse IP, ou l’identifiant d’interface [RFC3477], associé à la liaison sur laquelle il doit être utilisé. Jusqu’à deux sous-objets Étiquette peuvent être présents, un pour l’étiquette aval, et un pour l’étiquette amont. Ce qui sui DEVRAIT résulter en une erreur "Mauvais objet CHEMIN_EXPLICITE" :

o Si le premier objet étiquette n’est pas précédé d’un sous-objet contenant une adresse IP, ou un identifiant d’interface [RFC3477], associé à une liaison de sortie.

o Si un sous-objet Étiquette suit un sous-objet qui a le bit L établi.

o À l’établissement d’un LSP unidirectionnel, si il y a un sous-objet Étiquette avec le bit U établi.

o Si il y a deux sous-objets Étiquette avec la même valeur de bit U.


Pour prendre en charge le sous-objet Étiquette, un nœud doit vérifier si le sous-objet qui suit son adresse/interface associé est un sous-objet Étiquette. Si il l’est, un sous-objet est examiné pour les LSP unidirectionnels et deux sous-objets pour les LSP bidirectionnels. Si le bit U du sous-objet examiné n’est pas établi (est à 0) alors la valeur de l’étiquette est copiée dans un nouvel objet Ensemble_d’étiquettes. Cet objet Ensemble_d’étiquette DOIT être inclus dans le message Path sortant correspondant.


Si le bit U du sous-objet examiné est établi (à 1) alors la valeur de l’étiquette est l’étiquette à utiliser pour le trafic amont associé au LSP bidirectionnel. Si cette étiquette n’est pas acceptable, une erreur "Mauvais objet CHEMIN_EXPLICITE" DEVRAIT être générée. Si l’étiquette est acceptable, l’étiquette est copiée dans un nouvel objet Étiquette_amont. Cet objet Étiquette_amont DOIT être inclus dans le message Path sortant correspondant.


Après traitement, le sous-objet Étiquette est retiré de l’ERO.


Noter qu’une implication des procédures ci-dessus est que le sous-objet Étiquette ne devrait jamais être le premier sous-objet d’un nouveau message reçu. Si le sous-objet Étiquette est le premier sous-objet d’un ERO 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 le sous-objet Étiquette sortent du domaine d’application du présent document.


5.2 Sous-objet Étiquette RRO


Le sous-objet Étiquette RRO 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

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

| Type | Longueur |U| Fanions | C-Type |

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

| Étiquette |

| ... |

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


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


Type : 3 Étiquette


Longueur : voir la [RFC3209].


Fanions ; voir la [RFC3209].


C-Type

C’est le C-Type de l’objet Étiquette inclus, copié de l’objet Étiquette.


5.2.1 Procédures

Les sous-objets Étiquette RRO sont inclus dans des RRO comme décrit dans la [RFC3209]. La seule modification d’usage et de traitement par rapport à la [RFC3209] est que lorsque des étiquettes sont enregistrées pour des LSP¨bidirectionnels, les sous-objets Étiquette ERO pour les étiquettes aval et amont DOIVENT être incluses.


6. Objet Protection


L’utilisation de l’objet Protection est facultative. L’objet est inclus pour indiquer des attributs spécifiques de protection d’un LSP. L’objet Protection utilise le numéro de classe 37 (de forme 0bbbbbbb).


Le format de l’objet 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

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

| Longueur | Class-Num (37)| C-Type (1) |

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

|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 Path contenant un objet Protection DOIVENT vérifier que la protection demandée peut être satisfaite par l’interface ou tunnel sortant (FA). Si elle ne le peut pas, le nœud DOIT générer un message PathErr, 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 l’objet État_admin. L’objet fournit des informations sur l’état administratif d’un certain LSP. Les informations sont utilisées de deux façons. Dans la première, l’objet est porté dans des messages Path et Resv pour indiquer l’état administratif d’un LSP. Dans la seconde, l’objet est porté dans un message Notification pour demander que le nœud d’entrée change l’état administratif d’un LSP.


7.1. Objet État_administratif

L’utilisation de l’objet État_administratif est facultative. Il utilise le numéro de classe 196 (de forme 11bbbbbb).


Le format de l’objet État_administratif 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

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

| Longueur | Class-Num(196)| C-Type (1) |

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

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

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


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


7.2 Procédures des messages Path et Resv

L’objet État_administratif est utilisé pour notifier à chaque nœud le long du chemin l’état du LSP. Les informations d’état sont traitées par chaque nœud sur la base de la politique locale et ensuite sont propagées dans les messages sortants correspondants. L’objet peut être inséré dans les messages Path ou Resv à la discrétion du nœud d’entrée (pour les messages Path) ou de sortie (pour les messages Resv). L’absence de l’objet est équivalente à la réception d’un objet contenant des valeurs toutes réglées à zéro (0).


Les nœuds de transit qui reçoivent un message Path ou Resv non rafraîchi contenant un objet État_administratif mettent à jour leur état local, prennent toute action locale appropriée sur la base de l’état indiqué et propagent ensuite l’objet État_administratif reçu dans le message Path ou Resv sortant correspondant. Si les valeurs d’un objet État_administratif reçu dans un message Resv diffèrent des valeurs reçues dans un message Path, alors sauf une exception, aucune action locale ne devrait être entreprise, mais les valeurs devraient quand même être propagées. Le seul cas où les valeurs reçues dans le message Resv devraient résulter en une action locale est lorsque les bits R et D reçus sont tous deux établis, c’est-à-dire, sont à un (1).


Les nœuds bordures qui reçoivent un message Path ou Resv non rafraîchi contenant un objet État_administratif, mettent aussi à jour leur état local et prennent toute action locale appropriée sur la base de l’état indiqué. Lorsque un objet É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 sortant correspondant. Précisément, si un nœud de sortie reçoit un message avec le bit R de l’objet État_administratif reçu établi, et si le nœud a précédemment produit un message Resv correspondant au message Path, le nœud DEVRAIT envoyer un message Resv mis à jour contenant un objet État_administratif avec les mêmes valeurs réglées, à l’exception du bit R, comme reçues dans le message Path correspondant. De plus, le nœud de sortie DEVRAIT aussi s’assurer que les messages Resv suivants envoyés par le nœud contiennent le même objet État_administratif.


De plus, si un nœud d’entrée reçoit un message Resv avec le bit R de l’objet État_administratif établi, le nœud DEVRAIT envoyer un message Path mis à jour et contenant un objet État_administratif avec les mêmes valeurs réglées, à l’exception du bit R, comme elles ont été reçues dans le message Resv correspondant. De plus, le nœud d’entrée DEVRAIT aussi s’assurer que les messages Path suivants envoyés par le nœud contiennent le même objet État_administratif.


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, la procédure suivante DEVRAIT être respectée lors de la suppression d’un LSP à partir de l’entrée :

1. Le nœud d’entrée fait précéder une suppression de LSP de l’insertion d’un objet État_administratif dans un message Path et du réglage des bits Reflet (R) et Supprimer (D).

2. Les nœuds de transit et de sortie traitent l’objet État_administratif comme décrit ci-dessus. (Autrement, la sortie PEUT répondre avec une indication de message PathErr avec le fanion État_de_chemin_retiré établi, voir au paragraphe 4.4.)

3. À réception de l’objet État_administratif avec le bit Supprimer (D) établi dans le message Resv, le nœud d’entrée envoie un message PathTear vers l’aval pour retirer le LSP et le traitement RSVP normal se poursuit.


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

1. Le nœud de sortie indique son désir de suppression en insérant un objet État_administratif dans un message Resv et en établissant les bits Reflet (R) et Supprimer (D).

2. Les nœuds de transit traitent l’objet État_administratif comme décrit ci-dessus.

3. À réception d’un objet État_administratif avec le bit Supprimer (D) établi dans le message Resv, le nœud d’entrée envoie un message PathTear vers l’aval pour retirer le LSP et le traitement RSVP normal se poursuit.


7.2.2 Compatibilité et procédures d’erreur

Il est possible que certains nœuds le long d’un LSP ne prennent pas en charge l’objet État_administratif. Dans le cas d’un nœud de transit qui ne le prend pas en charge, l’objet va passer à travers le nœud non modifié et le traitement normal peut continuer. Dans le cas d’un nœud de sortie qui ne le prend pas en charge, l’objet État_administratif ne sera pas reflété dans le message Resv. Pour supporter le cas d’un nœud de sortie non participant, l’entrée DEVRAIT seulement attendre pendant une durée configurable l’objet État_administratif mis à jour dans un message Resv. Une fois le délai écoulé, le nœud d’entrée envoie un message PathTear. Par défaut, le délai DEVRAIT être de 30 secondes.


7.3 Procédures du message Notifier

Les nœuds intermédiaires et de sortie peuvent déclancher le réglage de l’état administratif via l’utilisation de messages Notifier. Pour réaliser cela, un nœud intermédiaire ou de sortie génère un message Notifier avec les informations de session correspondantes vers l’amont. L’objet État_administratif DOIT être inclus dans les informations de session, avec le ou les bits appropriés établis. Le bit Reflet (R) NE DOIT PAS être établi. Le message Notifier peut, mais n’y est pas obligé, être encapsulé, voir au paragraphe 4.3.


Un nœud d’entrée qui reçoit un message Notifier contenant un objet État_administratif avec le bit Supprimer (D) établi, DEVRAIT initier la procédure de suppression décrite à la section précédente. Les autres bits DEVRAIENT être propagés dans un message Path sortant comme normalement.


7.3.1 Compatibilité et procédures d’erreur

Un certain traitement particulier est nécessaire afin de couvrir le cas des nœuds qui ne prennent pas en charge l’objet État_administratif et d’autres conditions d’erreur. Précisément, un nœud qui envoie un message Notifier contenant un objet État_administratif avec le bit Mort (D) établi DOIT vérifier qu’il reçoit un message Path correspondant avec le bit Mort (D) établi dans un délai configurable. Par défaut, ce délai DEVRAIT être 30 secondes. Si le nœud ne reçoit pas un tel message Path, il DEVRAIT envoyer un message PathTear vers l’aval et un message ResvTear ou un message PathErr avec le fanion État_de_chemin_retiré établi 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 de l’interface de données à utiliser est toujours fait par l’envoyeur du message Path. Le choix de l’interface de données est indiqué par l’envoyeur du message Path par l’inclusion dans le message de l’identifiant d’interface du canal de données en utilisant un nouveau sous-type d’objet RSVP_HOP. Pour les LSP bidirectionnels, l’envoyeur choisit l’interface de données dans chaque direction. Dans tous les cas sauf celui de faisceau, l’interface amont est impliquée par l’interface aval. Pour les faisceaux, l’envoyeur du chemin identifie explicitement l’interface composante utilisée dans chaque direction. Le nouvel objet RSVP_HOP est utilisé dans un message Resv pour indiquer l’usage par le nœud aval de la ou des interfaces indiquées.


8.1.1 Objets IF_ID RSVP_HOP

Le format de l’objet IPv4 IF_ID RSVP_HOP 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

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

| Longueur | Class-Num (3) | C-Type (3) |

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

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

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

| Bride d’interface logique |

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

| |

~ TLV ~

| |

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


Le format de l’objet IPv6 IF_ID RSVP_HOP 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

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

| Longueur | Class-Num (3) | C-Type (4) |

+---------------+---------------+---------------+---------------+ | |

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

| |

| |

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

| Bride d’interface logique |

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

| |

~ TLV ~

| |

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


Voir dans la [RFC2205] la description des champs Adresse de bond et Bride d’interface.

Voir dans la [RFC3471] la description des TLV de paramètres et codages.


8.1.2 Procédures

Un objet IF_ID RSVP_HOP est utilisé à la place des objets RSVP_HOP précédemment définis. Il est utilisé sur les liaisons sur lesquelles il n’y a pas une association bijective entre un canal de contrôle et un canal de données, voir la [RFC3471]. Les champs Adresse de bond et Bride d’interface logique sont utilisés selon la norme RSVP [RFC2205].


Les TLV sont utilisés pour identifier le ou les canaux de données associés avec un LSP. Pour un LSP unidirectionnel, un canal de données vers l’aval DOIT être indiqué. Pour les LSP bidirectionnels, un canal de données commun vers l’aval et vers l’amont est normalement indiqué. Dans le cas particulier d’un LSP bidirectionnel qui traverse un faisceau de liaisons, 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 du message Path. L’objet IF_ID RSVP_HOP NE DEVRAIT PAS être utilisé lorsque aucun TLV n’est nécessaire.


Un nœud qui reçoit un ou plusieurs TLV dans un message Path sauvegarde leurs valeurs et les retourne dans les objets HOP des messages Resv suivants envoyés au nœud qui a généré les TLV.


Noter que le nœud qui génère un objet IF_ID DOIT s’assurer que l’interface sortante choisie, comme spécifié dans l’objet IF_ID, est cohérente avec un ERO. Un nœud qui reçoit un objet IF_ID DEVRAIT vérifier si les informations portées dans cet objet 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 PathErr avec le code d’erreur "Erreur d’acheminement" et la valeur d’erreur de "Mauvais objet Chemin 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, les objets IF_ID ERROR_SPEC sont définis.


8.2.1 Objets IF_ID ERROR_SPEC

Le format de l’objet IPv4 IF_ID ERROR_SPEC 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

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

| Longueur | Class-Num (6) | C-Type (3) |

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

| Adresse IPv4 du nœud erroné |

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

| Fanions | Code d’erreur | Valeur d’erreur |

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

| |

~ TLV ~

| |

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


Le format de l’objet IPv6 IF_ID ERROR_SPEC 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

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

| Longueur | Class-Num (6) | C-Type (4) |

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

| |

| Adresse IPv6 du nœud erroné |

| |

| |

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

| Fanions | Code d’erreur | Valeur d’erreur |

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

| |

~ TLV ~

| |

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


Voir dans la [RFC2205] la description des champs Adresse, Fanions, Code d’erreur et Valeur d’erreur. Voir dans la [RFC3471] la description des paramètres et codages des TLV.


8.2.2 Procédures

Les nœuds qui souhaitent indiquer qu’une erreur se rapporte à une interface spécifique DEVRAIENT utiliser l’objet IF_ID ERROR_SPEC approprié dans le message PathErr ou ResvErr correspondant. Les objets IF_ID ERROR_SPEC DEVRAIENT être générés et traités comme tout autre objet ERROR_SPEC, voir la [RFC2205].


9. Traitement des fautes


Le traitement des deux types de fautes de communication de contrôle est décrit dans la présente section. Le premier, qu’on appelle des fautes nodales, se rapporte au cas où un nœud perd son état de contrôle (par exemple après un redémarrage) mais ne perd pas son état de transmission des données. Le second, qu’on appelle des fautes de canal de contrôle, se rapporte au cas où la communication de contrôle est perdue entre deux nœuds. Le traitement des deux fautes est pris en charge par l’objet Restart_Cap défini ci-après et exige l’utilisation de messages Hello.


Noter que l’objet Restart_Cap NE DOIT PAS être envoyé lorsque il n’y a pas de mécanisme pour détecter les défaillances de canal de données indépendantes des défaillances du canal de contrôle.


Prière de noter que la présente section est tirée de la [RFC4090].


9.1 Objet Restart_Cap

L’objet Restart_Cap est porté dans les messages Hello.


Le format de l’objet Restart_Cap 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

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

| Longueur | Class-Num(131)| C-Type (1) |

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

| Délai de redémarrage |

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

| Délai de récupération |

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


Délai de redémarrage : 32 bits

Le délai de redémarrage est mesurée en millisecondes. Le délai de redémarrage DEVRAIT être réglé comme étant la somme du temps qu’il faut à l’envoyeur de l’objet pour redémarrer son composant RSVP-TE (jusqu’au moment où il pourra échanger des Hello RSVP avec ses voisins) et le canal de communication qui est utilisé pour la communication RSVP. Une valeur de 0xffffffff indique que le redémarrage du plan de contrôle de l’envoyeur peut survenir dans un délai indéterminé et que le fonctionnement de son plan de données n’est pas affecté par les défaillances du plan de contrôle. La méthode utilisée pour s’assurer de la poursuite du fonctionnement du plan de données sort du domaine d’application du présent document.


Délai de récupération : 32 bits

C’est le délai, en millisecondes, dans lequel l’envoyeur désire que le receveur resynchronise RSVP et l’état de transmission MPLS avec l’envoyeur après le rétablissement de la synchronisation de Hello. Une valeur de zéro (0) indique que l’état de transmission MPLS n’a pas été préservé à travers un réamorçage particulier.


9.2 Traitement de l’objet Restart_Cap

Les nœuds qui prennent en charge la récupération d’état annoncent cette capacité en portant l’objet Restart_Cap dans les messages Hello. De tels nœuds DOIVENT inclure l’objet Restart_Cap dans tous les messages Hello. (Noter que cela inclut les messages Hello qui contiennent des objets ACK.) L’usage du cas particulier des valeurs d’heure de récupération est décrit plus en détail ci après


Lorsque un nœud reçoit un message Hello avec l’objet Restart_Cap, il DEVRAIT enregistrer les valeurs des paramètres reçus.


9.3 Modification au traitement de Hello pour la prise en charge de la récupération d’état

Lorsque un nœud détermine que la communication RSVP avec un voisin a été perdue, et que le nœud avait appris précédemment que le voisin prend en charge la récupération d’état, le nœud DEVRAIT attendre au moins pendant la durée indiquée par l’heure de redémarrage indiquée par le voisin avant d’invoquer les procédures qui se rapportent à la perte de communication. Un nœud PEUT attendre pendant une durée différente sur la base de la politique locale ou des informations de configuration.


Durant cette période d’attente, tous les messages Hello DOIVENT être envoyés avec une valeur Dst_Instance réglée à zéro (0), et Src_Instance devrait rester inchangé. Pendant l’attente, le nœud DEVRAIT aussi préserver l’état de transmission RSVP et MPLS pour les LSP déjà établis qui traversent la ou les liaisons entre le nœud et le voisin. Dans un sens, par rapport aux LSP établis, le nœud se comporte comme si il continuait de recevoir des messages de rafraîchissement RSVP périodiques du voisin. Le nœud PEUT libérer RSVP et l’état de transmission pour les LSP qui sont dans le processus d’établissement lorsque leurs temporisateurs de rafraîchissement arrivent à expiration. Le rafraîchissement de Resv et de l’état de chemin DEVRAIT être supprimé durant cette période d’attente.


Durant cette période d’attente, le nœud PEUT informer les nœuds amont de la perte de communication via un message PathErr et/ou un message Notifier amont avec une indication "État dégradé du canal de contrôle". Si une telle notification a été envoyée, à la restauration du canal de contrôle, le nœud DOIT alors informer les autres nœuds de la restauration via un message PathErr et/ou un message Notifier amont avec une indication "État actif du canal de contrôle". (Des codes d’erreur spécifiques ont été alloués par l’IANA.)


Lorsque un nouveau message Hello est reçu du voisin, le nœud doit déterminer si la faute était limitée au canal de contrôle ou était une faute nodale. Cette détermination se fonde sur le Src_Instance reçu du voisin. Si sa valeur est différente de celle qui a été reçue du voisin avant la faute, le voisin devrait alors être traité comme si il avait redémarré. Autrement, la faute était limitée au canal de contrôle. Les procédures pour traiter chaque cas sont décrites ci-dessous.


9.4 Fautes du canal de contrôle

Dans le cas des fautes du canal de contrôle, le nœud DEVRAIT rafraîchir tous les états partagés avec le voisin. Des “Rafraîchissement sommaire” (Summary Refresh) [RFC2961] avec le fanion ACK_désiré établi DEVRAIENT être utilisés, si ils sont pris en charge. Noter que si un grand nombre de messages est nécessaire, une certaine régulation devrait être appliquée. Tout état DEVRAIT être rafraîchi pendant le délai de récupération annoncé par le voisin.


9.5 Fautes nodales

La récupération des fautes nodales utilise un nouvel objet et d’autres messages et objets de protocole existants.


9.5.1 Étiquette de récupération

L’objet Étiquette_de_récupération est utilisé durant le processus de récupération de faute. Le format d’un objet Étiquette_de_récupération est identique à celui d’une étiquette généralisée. Un objet Étiquette_de_récupération utilise le numéro de classe 34 (de forme 0bbbbbbb) et le C-Type de l’étiquette suggérée.


9.5.2 Procédures pour le nœud qui redémarre

Après qu’un nœud a redémarré son plan de contrôle, un nœud qui prend en charge la récupération d’état DEVRAIT vérifier si il a été capable de préserver son état de transmission MPLS. Si aucun état de transmission d’avant le redémarrage n’a été préservé, le nœud DOIT alors régler le Délai de récupération à 0 dans le message Hello que le nœud envoie à ses voisins.


Si l’état de transmission a été préservé, le nœud initie alors le processus de récupération d’état. La période durant laquelle un nœud est prêt à prendre en charge le processus de récupération est appelé "période de récupération". La durée totale de la période de récupération est annoncée par le nœud récupérateur dans le paramètre Délai de récupération de l’objet Restart_Cap. Le délai de récupération DOIT être réglé à la durée de la période de récupération dans tous les messages Hello envoyés durant la période de récupération. L’état qui n’est pas resynchronisé durant la période de récupération DEVRAIT être retiré à la fin de la période.


Noter que si durant la synchronisation de Hello le nœud qui redémarre détermine qu’un voisin ne prend pas en charge la récupération d’état, et si le nœud qui redémarre entretient l’état de transmission MPLS voisin par voisin, le nœud qui redémarre devrait immédiatement considérer que la période de récupération avec ce voisin est terminée. L’état de transmission peut être considéré comme entretenu voisin par voisin lorsque sont utilisées des étiquettes par interface sur des interfaces en point à point.


Lorsque un nœud reçoit un message Path durant la période de récupération, le nœud vérifie d’abord si il a un état RSVP associé au message. Si l’état est trouvé, alors le nœud traite ce message conformément aux procédures définies précédemment.


Si l’état RSVP n’est pas trouvé, et si le message ne porte pas d’objet Étiquette_de_récupération, le nœud traite cela comme l’établissement d’un nouveau LSP, et le traite conformément aux procédures définies précédemment.


Si l’état RSVP n’est pas trouvé, et si le message porte un objet Étiquette_de_récupération, le nœud cherche dans son tableau de transmission MPLS (celui qui a été préservé dans le redémarrage) une entrée dont l’interface entrante correspond au message Path et dont l’étiquette entrante est égale à l’étiquette portée dans l’objet Étiquette_de_récupération.


Si l’entrée du tableau de transmission MPLS n’est pas trouvée, le nœud traite cela comme l’établissement d’un nouveau LSP, et le traite conformément aux procédures définies précédemment.


Si l’entrée du tableau de transmission MPLS est trouvée, l’état RSVP approprié est créé, l’entrée est liée au LSP associé au message, et l’état de transmission qui s’y rapporte devrait être considéré comme valide et rafraîchi. Le traitement normal de message Path devrait aussi être effectué. Lors de l’envoi du message Path sortant correspondant, le nœud DEVRAIT inclure un objet Étiquette_suggérée avec une valeur d’étiquette qui correspond à l’étiquette sortante à partir de l’entrée de transmission maintenant restaurée. L’interface sortante DEVRAIT aussi être choisie sur la base de l’entrée de transmission. Dans le cas particulier où le nœud qui redémarre a aussi un voisin aval qui redémarre, un objet Étiquette_de_récupération devrait être utilisé à la place d’un objet Étiquette suggérée.


De plus, pour les LSP bidirectionnels, le nœud extrait l’étiquette de l’objet UPSTREAM_LABEL porté dans le message Path reçu, et cherche dans son tableau de transmission MPLS une entrée dont l’étiquette sortante est égale à l’étiquette portée dans l’objet (dans le cas de faisceau de liaisons, cela peut aussi impliquer d’identifier d’abord la liaison composante entrante appropriée).


Si l’entrée du tableau de transmission MPLS n’est pas trouvée, le nœud traite cela comme un établissement de nouveau LSP, et le traite conformément aux procédures définies précédemment.


Si l’entrée du tableau de transmission MPLS est trouvée, l’entrée est liée au LSP associé au message Path, et l’entrée devrait être considérée comme resynchronisée. De plus, si le nœud n’est pas l’extrémité de queue du LSP, les messages Path sortants correspondants sont envoyés avec l’étiquette entrante provenant de cette entrée portée dans l’objet Étiquette_amont.


Durant la période de récupération, les messages Resv sont traités normalement avec deux exceptions. Dans le cas où une entrée de transmission est récupérée, aucune nouvelle étiquette ou allocation de ressource n’est requise durant le traitement du message Resv. La seconde exception est que les messages ResvErr NE DEVRAIENT PAS être générés lorsque un message Resv est reçu sans état de chemin correspondant. Dans ce cas, le message Resv DEVRAIT juste être éliminé en silence.


9.5.3 Procédures pour le voisin d’un nœud qui redémarre

Les procédures qui s’appliquent lorsque le nœud rétablit la communication avec le plan de contrôle du voisin pendant le délai de redémarrage sont les suivantes : le nœud détermine (en utilisant les procédures définies à la Section 5 de la [RFC3209]) que le plan de contrôle du voisin a redémarré, et que le voisin a été capable de préserver son état de transmission à travers le redémarrage (comme indiqué par un délai de récupération différent de zéro porté dans l’objet Restart_Cap des messages RSVP Hello reçus du voisin). Noter qu’une valeur de délai de redémarrage de 0xffffffff indique un intervalle de délai de redémarrage infini.


Lorsque il détecte un redémarrage avec un voisin qui prend en charge la récupération d’état, un nœud DEVRAIT rafraîchir tous les états de chemin qu’il partage avec ce voisin. Les messages Path sortants DOIVENT inclure un objet Étiquette_de_récupération contenant une valeur d’étiquette correspondant à la valeur d’étiquette reçue dans le message Resv correspondant le plus récemment reçu. Tous les états de chemin DEVRAIENT être rafraîchis dans approximativement la moitié du délai de récupération annoncé par le voisin redémarré. Si il y a beaucoup de LSP qui passent à travers le nœud redémarré, le nœud voisin devrait éviter d’envoyer des messages Path dans un court intervalle de temps, pour éviter de faire subir une pression inutile au CPU du nœud qui redémarre. Il devrait plutôt étaler les messages sur la moitié de l’intervalle du délai de récupération.


Après avoir détecté un redémarrage d’un voisin qui prend en charge la récupération d’état, tous les états Resv partagés avec le nœud qui redémarre NE DOIVENT PAS être rafraîchis jusqu’à ce qu’un message Path correspondant soit reçu. Cela exige la suppression du traitement normal de rafraîchissement de Resv et Rafraîchissement sommaire pour le voisin durant le délai de récupération annoncé par le voisin redémarré. Aussitôt qu’un message Path correspondant est reçu, un message Resv DEVRAIT être généré et le traitement normal d’état DEVRAIT être réactivé.


10. Formats et traitements des messages RSVP


La présente section résume les formats et traitements des messages RSVP tels que modifiés par GMPLS.


10.1 Formats de message RSVP

Ce paragraphe présente les formats de message RSVP qui sont modifiés par le présent document. Lorsque ils diffèrent, les formats des LSP unidirectionnels sont présentés séparément des LSP bidirectionnels. Les formats non modifiés ne sont pas présentés. Les objets MESSAGE_ID et ceux qui s’y rapportent sont définis dans la [RFC2961].


Le format d’un message Path est le suivant :

<Message Path> ::= <En-tête commun> [ <INTÉGRITÉ> ]

[ [<ACC_DE_MESSAGE_ID> | <NACC_DE_MESSAGE_ID>] ... ]

[ <MESSAGE_ID> ]

<SESSION> <RSVP_HOP>

<VALEURS_HORAIRES>

[ <CHEMIN_EXPLICITE> ]

<DEMANDE_D’ÉTIQUETTE>

[ <PROTECTION> ]

[ <ENSEMBLE_D’ÉTIQUETTE> ... ]

[ <ATTRIBUT_DE_SESSION> ]

[ <DEMANDE_DE_NOTIFIER ]

[ <ÉTAT_ADMINISTRATIF> ]

[ <DONNÉES_DE_POLITIQUE> ... ]

<descripteur de l’envoyeur>


Le format de la description de l’envoyeur pour les LSP unidirectionnels est :

<descripteur de l’envoyeur> ::= <GABARIT_D’ENVOYEUR> <TSPEC_D’ENVOYEUR>

[ <ADSPEC> ]

[ <CHEMIN_ENREGISTRÉ> ]

[ <ÉTIQUETTE_SUGGÉRÉE> ]

[ <ÉTIQUETTE_DE_RÉCUPÉRATION> ]


Le format de la description de l’envoyeur pour les LSP bidirectionnels est :

<descripteur de l’envoyeur> ::= <GABARIT_D’ENVOYEUR> <TSPEC_D’ENVOYEUR>

[ <ADSPEC> ]

[ <CHEMIN_ENREGISTRÉ> ]

[ <ÉTIQUETTE_SUGGÉRÉE> ]

[ <ÉTIQUETTE_DE_RÉCUPÉRATION> ]

<ÉTIQUETTE_AMONT>


Le format d’un message PathErr est le suivant :

<Message PathErr> ::= <En-tête commun> [ <INTÉGRITÉ> ]

[ [<ACC_DE_MESSAGE_ID> | <NACC_DE_MESSAGE_ID>] ... ]

[ <MESSAGE_ID> ]

<SESSION> <ERREUR_SPEC>

[ <ENSEMBLE_D’ÉTIQUETTES_ACCEPTABLE> ... ] [ <DONNÉES_DE_POLITIQUE> ... ]

<descripteur de l’envoyeur>


Le format d’un message Resv est le suivant :

<Message Resv> ::= <En-tête commun> [ <INTÉGRITÉ> ]

[ [<ACC_DE_MESSAGE_ID> | <NACC_DE_MESSAGE_ID>] ... ]

[ <MESSAGE_ID> ]

<SESSION> <BOND_RSVP>

<VALEURS_HORAIRES>

[ <RESV_CONFIRM> ] [ <PORTÉE> ]

[ <DEMANDE_DE_NOTIFIER> ] [ <ÉTAT_ADMINISTRATIF> ]

[ <DONNÉES_DE_POLITIQUE> ... ]

<STYLE> <liste des descripteurs de flux>


<liste des descripteurs de flux> n’est pas modifié par le présent document.


Le format d’un message ResvErr est le suivant :


<Message ResvErr> ::= <En-tête commun> [ <INTÉGRITÉ> ]

[ [<ACC_DE_MESSAGE_ID> | <NACC_DE_MESSAGE_ID>] ... ]

[ <MESSAGE_ID> ]

<SESSION> <BOND_RSVP>

<ERREUR_SPEC> [ <PORTÉE> ]

[ <ENSEMBLE_D’ÉTIQUETTES_ACCEPTABLE> ... ] [ <DONNÉES_DE_POLITIQUE> ... ]

<STYLE> <descripteur des flux erronés>


Le message Hello modifié a le format suivant :


<Message Hello> ::= <En-tête commun> [ <INTÉGRITÉ> ] <HELLO> [ <RESTART_CAP> ]

10.2 Adressage des messages Path, PathTear et ResvConf

RSVP a été conçu pour traiter des changements dynamiques (non explicites) de chemin et des bonds non RSVP le long du chemin. À cette fin, les messages Path, PathTear et ResvConf portent l’adresse de destination de la session dans l’en-tête IP. Dans la signalisation généralisée, les chemins sont habituellement explicitement signalés. De plus, les bonds qui ne peuvent pas allouer d’étiquette ne peuvent pas exister sur le chemin d’un LSP. Une autre différence avec le RSVP traditionnel est que parfois, un message RSVP peut voyager hors bande par rapport à un canal de données de LSP.


Lorsque un nœud envoie un message Path, PathTear ou ResvConf à un nœud qui est connu pour être adjacent au plan de données (c’est-à-dire, le long du chemin du LSP) il DEVRAIT adresser le message directement à une adresse associée au plan de contrôle du nœud adjacent. Dans ce cas, l’option d’alerte de routeur NE DEVRAIT PAS être incluse.


11. Remerciements


Le présent document est l'œuvre de nombreux auteurs et consiste en une compilation de documents antérieurs sur ce sujet.


Des commentaires et apports précieux ont été reçus d'un certain nombre de personnes, parmi lesquelles Igor Bryskin, Adrian Farrel et Dimitrios Pendarakis. Des portions de la Section 4 s'appuient sur des suggestions et un texte proposés par Adrian Farrel.


La section Considérations pour la sécurité se fonde sur un texte fourni par Steven Bellovin.


12. Considérations pour la sécurité


La sécurité du message RSVP est décrite dans la [RFC2747] et fournit l’intégrité de message et l’authentification du nœud. Pour les messages bond par bond, le présent document n’introduit pas d’autre nouvelle considération de sécurité.


Le présent document introduit la capacité d’envoyer un message Notifier de façon non bond par bond. Cela entrave le modèle d’intégrité et d’authentification bond par bond de RSVP. Dans le cas où RSVP génère des messages d’extrémité à extrémité et où le même niveau de sécurité que celui assuré par la [RFC2747] est désiré, on peut utiliser l’intégrité et l’authentification standard fondée sur IPsec. Autrement, l’envoi de messages Notifier non bond par bond peut être désactivé.


Lorsque on utilise IPsec pour fournir l’authentification de message, on applique ce qui suit :


Sélecteurs

Le sélecteur est identifié par les messages RSVP échangés entre une paire de nœuds non adjacents. Les nœuds sont identifiés par les adresses IP de source et de destination de l’en-tête IP interne utilisé sur les messages Notifier.


Mode

Dans cette application, le mode de transport est le choix approprié. Les informations communiquées ne sont généralement pas confidentielles, de sorte qu’il n’est pas nécessaire d’utiliser le chiffrement. AH [RFC2402] ou ESP [RFC2406] PEUT être utilisé ; si ESP est utilisé, l’adresse IP de l’envoyeur DOIT être confrontée à l’adresse IP affirmée dans l’échange de gestion de clé.


Gestion de clé

Pour permettre la détection de répétition, un système automatique de gestion de clé DEVRAIT être utilisé, IKE [RFC2409] étant le plus probable. Des clés configurées PEUVENT être utilisées.


Politique de sécurité

Les messages NE DOIVENT PAS être acceptés sauf de nœuds qui sont connus du receveur comme autorisés à faire de telles demandes.


Identification

Les mécanismes de partage de clés devraient être adéquats pour les déploiements initiaux et les plus petits réseaux. Pour les déploiements à plus grande échelle, IKE fondé sur des certificats devrait être pris en charge. Quel que soit le schéma utilisé, il doit s’appuyer d’une façon ou d’une autre sur une adresse IP de source.


Disponibilité

De nombreux routeurs et commutateurs prennent déjà en charge IPsec. Pour les cas où IPsec est indisponible et où la sécurité est exigée, les messages Notifier DOIVENT être envoyés bond par bond.


13. Considérations relatives à l'IANA


L’IANA alloue des valeurs aux paramètres de protocole RSVP. Plusieurs objets sont définis dans le présent document. Chacun de ces objets contient un C-Type. La présente section définit les règles d’allocation de valeurs de C-Type qui s’y rapportent. La présente section utilise la terminologie du BCP 26 "Lignes directrices pour la rédaction d’une section de considérations relatives à l’IANA dans les RFC" [RFC2434].


Selon la [RFC2205], un C-Type est un nombre de 8 bits qui identifie la fonction d’un objet. Toutes les valeurs possibles sauf zéro sont disponibles pour allocation.


L’allocation des valeurs de C-Type des objets définis dans le présent document entre dans trois catégories. La première catégorie hérite des C-Type de l’objet Étiquette, c’est-à-dire, du numéro de classe d’objet 16 [RFC3209]. Il est demandé à l’IANA d’instituer une politique par laquelle toutes les valeurs de C-Type allouées pour l’objet Étiquette sont aussi allouées pour les objets suivants :

o Étiquette_suggérée (Class-Num 129)

o Étiquette_amont (Class-Num 35)

o Étiquette_de_récupération (Class-Num 34)


La seconde catégorie d’objets suit des politiques indépendantes. Précisément, suivant les politiques indiquées dans la [RFC2434], les valeurs de C-Type dans la gamme 0x00 - 0x3F sont allouées par action de consensus de l’IETF, les valeurs dans la gamme 00x40 - 0x5F sont allouées au premier qui les demande, et les valeurs dans la gamme 0x60 - 0x7F sont réservées pour utilisation privée. Cette politique s’applique aux objets suivants :

o Ensemble_d’étiquettes (Class-Num 36)

o Demande_de_Notifier (Class-Num 195)

o Protection (Class-Num 37)

o État_administratif (Class-Num 196)

o Restart_Cap (Class-Num 131)


L’allocation des valeurs de C-Type pour les objets restants, l’objet Ensemble_d’étiquettes_acceptable, l’objet Ensemble_d’étiquettes, suivent l’allocation de valeurs de C-Type de l’objet Ensemble_d’étiquettes. L’IANA instituera une politique par laquelle toutes les valeurs de C-Type allouées pour l’objet Ensemble_d’étiquettes sont aussi allouées pour l’objet Ensemble_d’étiquettes_acceptable.


13.1 Allocations de l'IANA

Ce paragraphe récapitule les valeurs utilisées dans le présent document qui ont été allouées par l’IANA.


---------------------------------------------------------------------

Types de message

o message Notifier (type de message = 21)

---------------------------------------------------------------------

Types de classe

o RSVP_HOP (C-Num 3)

- IPv4 IF_ID RSVP_HOP (C-type = 3)

- IPv6 IF_ID RSVP_HOP (C-type = 4)

o ERREUR_SPEC (C-Num 6)

- IPv4 IF_ID ERROR_SPEC (C-type = 3)

- IPv6 IF_ID ERROR_SPEC (C-type = 4)

o DEMANDE_D’ÉTIQUETTE (Class-Num 19)

- Demande_d’étiquette_généralisée (C-Type = 4)

o ÉTIQUETTE_RSVP (Class-Num = 16)

- Étiquette_généralisée (C-Type = 2)

- Étiquette_de_commutation_de_gamme_d’onde C-Type (C-Type = 3)

---------------------------------------------------------------------

Nouveaux numéros de classe, C-Types hérités d’objet Étiquette (les mêmes que CNum16)

o ÉTIQUETTE_DE_RÉCUPÉRATION Class-Num de forme 0bbbbbbb (= 34)

o ÉTIQUETTE_SUGGÉRÉE Class-Num de forme 10bbbbbb (= 129)

o ÉTIQUETTE_AMONT Class-Num de forme 0bbbbbbb (= 35)

---------------------------------------------------------------------

Nouveaux numéros de classe

o ENSEMBLE_D’ÉTIQUETTE Class-Num de forme 0bbbbbbb (= 36)

- Type 1 (C-Type = 1)

o ENSEMBLE_D’ÉTIQUETTE_ACCEPTABLE Class-Num de forme 10bbbbbb (= 130)

- Ensemble_d’étiquette_acceptable de type 1 (C-type provenant du cnum Ensemble_d’étiquette)

o DEMANDE_DE_NOTIFIER Class-Num de forme 11bbbbbb (= 195)

- Demande de notifier IPv4 (C-Type = 1)

- Demande de notifier IPv6 (C-Type = 2)

o PROTECTION Class-Num de forme 0bbbbbbb (= 37)

- Type 1 (C-Type = 1)

o ÉTAT_ADMINISTRATIF Class-Num de forme 11bbbbbb (= 196)

- Type 1 (C-Type = 1)

o RESTART_CAP Class-Num de forme 10bbbbbb (= 131)

- Type 1 (C-Type = 1)

---------------------------------------------------------------------

Types de sous-objets ERO/RRO

o Sous-objet Étiquette ERO

Type 3 - Étiquette

o Sous-objet Étiquette RRO

Type 3 - Étiquette

---------------------------------------------------------------------

Codes d’erreur

o "Problème d’acheminement/Ensemble d’étiquettes" (valeur = 11)

o "Problème d’acheminement/Type de commutation" (valeur = 12) (code 13 dupliqué abandonné)

o "Problème d’acheminement/Codage non accepté" (valeur = 14)

o "Problème d’acheminement/Protection de liaison non acceptée" (valeur = 15)

o "Erreur notifiée/État actif du canal de contrôle" (valeur = 4)

o "Erreur notifiée/État dégradé du canal de contrôle" (valeur = 5)

---------------------------------------------------------------------


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


15. Références

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


[RFC2205] R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495) (P.S.)


[RFC2210] J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997. (P.S.)


[RFC2402] S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)


[RFC2406] S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité IP (ESP)", novembre 1998. (Obsolète, voir RFC4303)


[RFC2409] D. Harkins et D. Carrel, "L'échange de clés Internet (IKE)", novembre 1998. (Obsolète, voir la RFC4306)


[RFC2747] F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ par RFC3097) (P.S.)


[RFC2961] L. Berger et autres, "Extensions de réduction de redondance de rafraîchissement pour RSVP", avril 2001. (MàJ par RFC5063) (P.S.)


[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan et G. Swallow, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (MàJ par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420,RFC5711)


[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, 6002, 6003, 6205) (P.S.)


[RFC3477] K. Kompella, Y. Rekhter, "Signalisation des liaisons non numérotées dans le protocole de réservation de ressource – ingénierie du trafic (RSVP-TE)", janvier 2003. (MàJ par RFC6107) (P.S.)


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


[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)


[RFC4090] P. Pan et autres, "Extensions de reroutage rapide à RSVP-TE pour les tunnels de LSP", mai 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.)





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

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

McLean VA, 22102

téléphone : +1 613 763 4534

mél : abanerjee@calient.net

tééphone : +1 703 847-1801

mél : petera@nortelnetworks.com


mél : lberger@movaz.com


John Drake

Yanhe Fan

Kireeti Kompella

Calient Networks

Axiowave Networks, Inc.

Juniper Networks, Inc.

5853 Rue Ferrari

200 Nickerson Road

1194 N. Mathilda Ave.

San Jose, CA 95138

Marlborough, MA 01752

Sunnyvale, CA 94089

tééphone : +1 408 972 3720

tééphone : + 1 774 348 4627

mél : kireeti@juniper.net

mél : jdrake@calient.net

mél : yfan@axiowave.com



Fong Liaw

Yakov Rekhter

Solas Research, LLC

Juniper Networks, Inc.

mél : fongliaw@yahoo.com

mél : yakov@juniper.net


Eric Mannie

Ping Pan

Vishal Sharma

Independent Consultant

Ciena

Metanoia, Inc.

2 Avenue de la Folle Chanson

10480 Ridgeview Court

1600 Villa Street, Unit 352

1050 Brussels

Cupertino, CA 95014

Mountain View, CA 94041-1174

Belgium

tééphone : 408-366-4700

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

mél : eric_mannie@hotmail.com

mél : ppan@ciena.com

mél : v.sharma@ieee.org


Bala Rajagopalan

George Swallow

Tellium, Inc.

Cisco Systems, Inc.

2 Crescent Place

250 Apollo Drive

P.O. Box 901

Chelmsford, MA 01824

Oceanport, NJ 07757-0901

tééphone : +1 978 244 8143

tééphone : +1 732 923 4237

mél : swallow@cisco.com

Fax: +1 732 923 9804


mél : braja@tellium.com



Debanjan Saha

Z. Bo Tang

Greg Bernstein

Jonathan P. Lang

mél : debanjan@acm.org

mél : botang01@yahoo.com

mél : gregb@grotto-networking.com

mél : jplang@ieee.org


17. Adresse de l'éditeur


Lou Berger

Movaz Networks, Inc.

7926 Jones Branch Drive

Suite 615

McLean VA, 22102

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

mél : lberger@movaz.com


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