Groupe de travail Réseau	CY. Lee
Request for Comments : 4874	S. De Cnodder, Alcatel-Lucent
RFC mises à jour : 3209, 3473	A. Farrel, Old Dog Consulting
Catégorie : Sur la voie de la normalisation	avril 2007
Traduction Claude Brière de L'Isle	

Exclusion de chemins - Extension au protocole de réservation de ressource avec ingénierie du trafic (RSVP-TE)

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.
(La présente traduction incorpore l'errata 3572.)

Notice de Copyright
Copyright (C) The IETF Trust (2007).

Résumé
Le présent document spécifie des façons de communiquer des exclusions de chemin durant l'établissement de chemin en utilisant le protocole de réservation de ressources avec ingénierie du trafic (RSVP-TE, Resource ReserVation Protocol-Traffic Engineering).

La spécification RSVP-TE, "RSVP-TE : extensions à RSVP pour les tunnels de LSP" (RFC 3209) et les extensions GMPLS à RSVP-TE, "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)" (RFC 3473) permettent que des nœuds et ressources abstraits soient explicitement inclus dans un établissement de chemin, mais pas d'être explicitement exclus.

Dans certains réseaux où des chemins explicites précis ne sont pas calculés à l'extrémité de tête, il peut être utile de spécifier et signaler des nœuds et ressources abstraits qui sont à exclure explicitement des chemins. Ces exclusions peuvent s'appliquer à tout le chemin, ou à des parties d'un chemin entre deux nœuds abstraits spécifiés dans un chemin explicite. Comment des groupes de liaisons à risques partagés (SRLG, Shared Risk Link Group) peuvent être exclus est aussi spécifé dans ce document.
Table des matières
1. Introduction	2
1.1 Notation des exigences	3
1.2 Portée de Exclusion de chemins	3
1.3. Relations avec la MIB MPLS TE	4
2. Groupes de liaisons à risques partagés	4
2.1 Sous objet SRLG	4
3. Liste de chemin exclus	4
3.1 Objet EXCLUDE_ROUTE (XRO)	4
3.1.4 Sous objet Numéro de système autonome	6
3.2 Règles de traitement pour l'objet EXCLUDE_ROUTE (XRO)	7
4. Exclusion explicite de chemin	8
4.1 Sous objet Exclusion explicite de chemin (EXRS)	8
4.2 Règles de traitement pour le sous objet Explicit Exclusion Route (EXRS)	9
5. Traitement de XRO avec EXRS	9
6. Conformité minimum	10
7. Considérations sur la sécurité	10
8. Considérations relatives à l'IANA	10
8.1 Nouveau type de sous objet ERO	10
8.2 Nouveaux numéros de classe RSVP-TE	11
8.3 Nouveaux codes d'erreur	11
9. Remerciements	11
10. Références	12
10.1 Références normatives	12
10.2 Références pour information	12
Appendice A. Applications	12
A.1 Protection de LSP inter zones	12
A.2 Protection de LSP inter AS	13
A.3 Protection dans le modèle de recouvrement GMPLS	14
A.4 Protection de LSP l'intérieur d'une seule zone	14
Adresse des auteurs	15
Déclaration complète de droits de reproduction	15
 	1.	Introduction

La spécification RSVP-TE [RFC3209] et les extensions à GMPLS [RFC3473] permettent que des nœuds et ressources abstraits soient explicitement inclus dans un établissement de chemin, en utilisant l'objet Chemin explicite (ERO, Explicit Route Object).

Dans certains systèmes, il peut être utile de spécifier et signaler des nœuds et ressources abstraits qui sont à exclure explicitement des chemins. Cela peut être parce que des bonds lâches ou des nœuds abstraits ont besoin d'être empêchés de choisir un chemin à travers une ressource spécifique. C'est un cas particulier du calcul de chemun réparti dans le réseau.

Par exemple, l'exclusion de chemin pourrait être utilisée dans le cas où deux chemins de commutation d'étiquettes (LSP, Label Switched Path) sans chevauchement sont exigés. Dans ce cas, une option pourrait être d'établir un chemin et de collecter sa route en utilisant l'enregistrement de route et ensuite d'exclure les routeurs sur ce premier chemin de l'établissement du second chemin. Une autre option pourrait être d'établir deux cœurs de réseau parallèles, de faire un double rattachement des routeurs côté fournisseur (PE, Provider Edge) aux deux cœurs de réseau, et ensuite d'exclure le routeur local sur le cœur de réseau A la première fois qu'un LSP est établi (pour un PE distant particulier) et d'exclure le routeur local sur le cœur de réseau B la seconde fois qu'un LSP est établi.

Deux types d'exclusions sont requis :

1.	Exclusion de certains nœuds ou ressources abstraits sur le chemin entier. Cet ensemble de nœuds abstraits est appelée la liste des chemins exclus.

2.	Exclusion de certains nœuds ou ressources abstraits entre une paire spécifique de nœuds abstraits présents dans un ERO. Des telles exclusions spécifiques sont appelées une exclusion de chemin explicite.

Pour porter ces constructions dans le protocole de signalisation, un nouvel objet RSVP et un nouveau sous objet ERO sont respectivement introduits.

-	Un nouvel objet RSVP-TE est introduit pour porter la liste des chemins exclus. Cet object est EXCLUDE_ROUTE (XRO).

-	Le second type d'exclusion est réalisé par une modification de l'ERO existant. Un nouveau type de sous objet ERO, le sous objet Exclusion de chemin explicite (EXRS, Explicit Exclusion Route Subobject) est introduit pour indiquer une exclusion entre une paire de nœuds abstraits inclus.

La connaissance des SRLG, comme définis dans la [RFC4216], peut être utilisée pour calculer les divers chemins qui peuvent être utilisés pour la protection. Dans les systèmes où il est utile de signaler les exclusions, il peut être utile de signaler les SRLG pour indiquer les groupes de ressources qui devraient être exclus sur le chemin entier ou entre deux nœuds abstraits spécifiés dans un chemin explicite.

Le présent document introduit un sous objet pour indiquer un SRLG à signaler dans l'une ou l'autre des deux méthodes d'exclusion décrites ci-dessus. Le présent document ne suppose ou n'empêche aucun autre usage pour ce sous objet. Ce sous objet pourrait aussi être approprié pour l'usage dans un objet de chemin explicite (ERO) ou un objet d'enregistrement de chemin (RRO) mais cela sort du domaine d'application du présent document.

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

 	1.2	Portée de Exclusion de chemins
Le présent document n'empêche pas une exclusion de chemin de faire la liste de nœuds ou éléments de réseau arbitraires à éviter. L'intention est, cependant, d'indiquer seulement le nombre minimal de sous objets à éviter explicitement. Par exemple, il peut être nécessaire de signaler seulement les groupes de liaisons à risques partagés (SRLG, Shared Risk Link Group) à éviter. C'est-à-dire, l'exclusion de chemins n'est pas destinée à définir le chemin réel en faisant la liste de tous les choix à exclure à chaque bond, mais plutôt de contraindre le processus normal de choix de chemin où des bonds lâches ou des nœuds abstraits sont à étendre en faisant la liste de certains éléments à éviter.

Il est considéré que la plupart des sous objets d'inclusion conventionnelle sont spécifiés dans le ERO signalé seulement pour la zone où ils sont pertinents. Le nombre de sous objets à éviter, spécifié dans le XRO signalé, peut être constant à travers tout l'établissement de chemin, ou les sous objets à éviter peuvent être supprimés du XRO lorsque ils ne sont plus pertinents dans les bonds suivants de l'établissement de chemin.

Par exemple, considérons un LSP qui traverse plusieurs domaines de calcul. Un domaine de calcul peut être une zone au sens administratif ou IGP, ou peut être une division arbitraire du réseau pour la gestion active et les besoins du calcul de chemin. Disons que le chemin principal est (Entrée, A1, A2, AB1, B1, B2, BC1, C1, C2, Sortie) où :
- Xn note un nœud dans le domaine X, et
- XYn note un nœud à la bordure du domaine X et du domaine Y.

Noter que Entrée est un nœud du domaine A, et Sortie est un nœud du domaine C. C'est ce qui est montré dans la Figure 1 où les domaines correspondent aux zones.

           zone A               zone B              sone C
    <-------------------> <----------------> <------------------>
 Entrée-----A1----A2----AB1----B1----B2----BC1----C1----C2----Sortie
   ^  \                / | \              / | \                /
   |   \              /  |  \            /  |  \              /
   |    A3----------A4--AB2--B3--------B4--BC2--C3----------C4
   |                     ^                  ^
   |                     |                  |
   |                     |                  |
   |                     |             ERO : (C3-strict, C4-strict, Sortie-strict)
   |                     |             XRO : pas nécessaire
   |                     |
   |               ERO : (B3-strict, B4-strict, BC2-strict, Sortie-lâche)
   |               XRO : (BC1, C1, C2)
   |
  ERO : (A3-strict, A4-strict, AB2-strict, Sortie-lâche)
  XRO : (AB1, B1, B2, BC1, C1, C2)

Figure 1 : Domaines correspondants aux zones IGP

Considérons l'établissement d'un chemin de protection à dérivation de nœuds dans l'exemple ci-dessus. Le chemin de protection doit éviter tous les nœuds sur le chemin primaire. Les exclusions pour la zone A sont traitées durant le calcul de chemin le plus court en premier obligé (CSPF, Constrained Shortest Path First) à Entrée, de sorte que le ERO et XRO signalés à Entrée pourraient être, respectivement (A3-strict, A4-strict, AB2-strict, Sortie-lâche) et (AB1, B1, B2, BC1, C1, C2). En AB2, le ERO et XRO pourraient être, respectivement (B3-strict, B4-strict, BC2-strict, Sortie-lâche) et (BC1, C1, C2). En BC2, le ERO pourrait être (C3-strict, C4-strict, Sortie-strict) et un XRO n'est pas nécessaire à partir de BC2.

En général, on DEVRAIT prendre en considération (comme avec un chemin explicite) la taille des données signalées et l'impact sur le protocole de signalisation.

 	1.3.	Relations avec la MIB MPLS TE
La [RFC3812] définit les objets gérés pour gérer et modéliser l'ingénierie du trafic fondée sur MPLS. La [RFC3812] inclut un moyen pour configurer les chemins explicites à utiliser sur des LSP spécifiques. Cette configuration permet l'exclusion de certaines ressources.

Dans les systèmes où le chemin explicite complet n'est pas calculé à l'entrée (ou à un site de calcul de chemin à utiliser à l'entrée) il peut être nécessaire de signaler ces exclusions. Le présent document offre un moyen de faire cette signalisation.

 	2.	Groupes de liaisons à risques partagés

L'identifiant d'un SRLG est défini comme une quantité de 32 bits dans la [RFC4202]. Un sous objet SRLG est introduit afin qu'il puisse être utilisé dans les méthodes d'exclusion décrites dans les paragraphes qui suivent. Le présent document ne suppose ni m'empêche aucun autre usage de ce sous objet. Ce sous objet pourrait aussi être d'un usage approprié dans les objets Chemin explicite (ERO) ou Chemin enregistré (RRO, Record Route Object) mais ceci sort du domaine d'application du présent document.

 	2.1	Sous objet SRLG
Le nouveau sous objet SRLG est défini par le présent document comme suit. Son format est modelé sur les sous objets ERO définis dans la [RFC3209].

 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    | Identifiant de SRLG (4 octets)|
+-+-------------+---------------+---------------+---------------+
|       ID de SRLG (suite)      |           Réservé             |
+---------------+---------------+---------------+---------------+

L : le bit L est un attribut du sous objet. Il est établi si le sous objet représente un bond lâche dans le chemin explicite. Si le bit est à zéro, le sous objet représente un bond strict dans le chemin explicite. Pour les exclusions (comme utilisé par XRO et EXRS défini dans le présent document) le bit L DEVRAIT être réglé à zéro et ignoré.

Type : type du sous objet (34)

Longueur : contient la longueur totale du sous objet en octets, incluant les champs Type et Longueur. La longueur est toujours 8.

Identifiant de SRLG : identifiant de 32 bits du SRLG.

Réservé : ce champ est réservé. Il DEVRAIT être réglé à zéro à l'émission et DOIT être ignoré à réception.

 	3.	Liste de chemin exclus

Le chemin exclu identifie une liste de nœuds abstraits qui ne devraient pas être traversés le long du chemin du LSP à établir. Il est RECOMMANDÉ que la taille de la liste des chemins exclus soit limitée à une valeur locale pour le nœud qui est à l'origine de la liste des chemins exclus.

 	3.1	Objet EXCLUDE_ROUTE (XRO)
Les nœuds abstraits à exclure du chemin sont spécifiés via l'objet EXCLUDE_ROUTE (XRO).

Acutellement, un C_Type est défini, type 1 EXCLUDE_ROUTE. L'objet EXCLUDE_ROUTE a le format suivant :

Classe = 232, C_Type = 1

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                        (sous objets)                        //
|                                                               |
+---------------+---------------+---------------+---------------+

Le contenu d'un objet EXCLUDE_ROUTE est une série d'éléments de données de longueur variable appelés des sous objets. La présente spécification adapte les sous objets ERO définis dans les [RFC3209], [RFC3473], et [RFC3477] pour les utiliser dans les exclusions de chemin. Le sous objet SRLG défini à la Section 2 du présent document n'a pas été défini auparavant. Le sous objet SRLG est défini ici pour son usage avec les exclusions de chemin.

Les types de sous objets suivants sont pris en charge.

Type	Sous objet
     1              Préfixe IPv4
     2              Préfixe IPv6
     4              Identifiant d'interface non numérotée
    32             Numéro de système autonome
    34             SRLG

Les valeurs définies pour les types ci-dessus sont spécfiées dans la [RFC3209] et dans le présent document.

Le concept de bond lâche ou strict n'a pas de signification dans l'exclusion de chemin. Le bit L, défini pour les sous objets ERO dans la [RFC3209], est réutilisé ici pour indiquer qu'un nœud abstrait DOIT être exclu (valeur 0) ou DEVRAIT être évité (valeur 1). La distinction est que le chemin d'un LSP ne doit pas traverser un nœud abstrait figurant sur la liste du XRO avec le bit L à zéro, mais peut en traverser un qui a le bit L établi. Un nœud chargé d'acheminert un LSP (par exemple, pour étendre un bond lâche) devrait tenter de minimiser le nombre de nœuds abstraits mentionnés dans le XRO avec le bit L établi qui sont traversés par le LSP en accord avec la politique locale. Un nœud qui génère des sous objets XRO avec le bit L établi doit être prêt à accepter un LSP qui traverse un, quelques, ou tous les nœuds abstraits correspondants.

Les sous objets 1, 2, et 4 se réfèrent à une interface ou un ensemble d'interfaces.
Un octet Attribut est introduit dans ces sous objets pour indiquer l'attribut (par exemple, interface, nœud, SRLG) associé aux interfaces qui devraient être exclus du chemin. Par exemple, l'attribut nœud permet qu'un nœud entier soit exclu du chemin en spécifiant une interface de ce nœud dans le sous objet XRO, à la différence de l'attribut interface, qui permet à une interface spécifique (ou plusieurs interfaces) d'être exclue du chemin sans exclure le nœud entier. L'attribut SRLG permet que tous les SRLG associés à une interface soient exclus du chemin.

 	3.1.1	Sous objet Préfixe IPv4
 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   | Adresse IPv4 (4 octets)       |
+-+-------------+---------------+---------------+---------------+
|    Adresse IPv4 (suite)       | Long. préfixe |   Attribut    |
+---------------+---------------+---------------+---------------+

L : 0 indique que l'attribut spécifié DOIT être exclu. 1 indique que l'attribut spécifié DEVRAIT être évité.

Attribut : 
valeurs d'attribut d'interface : 0 indique que l'interface ou ensemble d'interfaces associé au préfixe IPv4 devrait être exclu ou évité.
valeurs d'attribut de nœud : 1 indique que le nœud ou ensemble de nœuds associé au préfixe IPv4 devrait être exclu ou évité.
valeurs d'attribut de SRLG : 2 indique que tous les SRLG associés au préfixe IPv4 devraient être exclus ou évités.

Le reste des champs est comme défini dans la [RFC3209].

 	3.1.2	Sous objet Préfixe IPv6
 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    | Adresse IPv6 (16 octets)      |
+-+-------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)                                          |
+---------------+---------------+---------------+---------------+
| Adresse IPv6 (suite)          | Long. préfixe |   Attribut    |
+---------------+---------------+---------------+---------------+

L : 0 indique que l'attribut spécifié DOIT être exclu. 1 indique que l'attribut spécifié DEVRAIT être évité.

Attribut : 
valeurs d'attribut d'interface : 0 indique que l'interface ou ensemble d'interfaces associé au préfixe IPv6 devrait être exclu ou évité.
valeurs de l'attribut de nœud : 1 indique que le nœud ou ensemble de nœuds associé au préfixe IPv6 devrait être exclu ou évité.
valeurs de l'attribut de SRLG : 2 indique que tous les SRLG associés au préfixe IPv6 devraient être exclus ou évités.

Le reste des champs est comme défini dans la [RFC3209].

 	3.1.3	Sous objet Identifiant d'interface non numérotée
 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   |    Réservé    |   Attribut    |
+-+-------------+---------------+---------------+---------------+
|                  Identifiant de routeur TE                    |
+---------------+---------------+---------------+---------------+
|                Identifiant d'interface ID (32 bits)           |
+---------------+---------------+---------------+---------------+

L : 0 indique que l'attribut spécifié DOIT être exclu. 1 indique que l'attribut spécifié DEVRAIT être évité.

Attribut :
Valeur d'attribut d'interface : 0 indique que l'identifiant d'interface spécifié devrait être exclu ou évité.
Valeur d'attribut de nœud : 1 indique que le nœud avec cet identifiant de routeur devrait être exclu ou évité (ceci peut fait aussi en utilisant un sous objet IPv4/v6, mais est inclus ici parce qu'il peut être pratique d'utiliser des informations provenant des sous objets d'un RRO, comme défini dans la [RFC3477], en spécifiant les exclusions).
Valeur d'attribut de SRLG : 2 indique que tous les SRLG associés à l'interface devraient être exclus ou évités.

Réservé : ce champ est réservé. Il DEVRAIT être rempli de zéros à l'émission et DOIT être ignoré à récepiont.

Le reste des champs est comme défini dans la [RFC3209].

 	3.1.4	Sous objet Numéro de système autonome
La signification du bit L est :
 0 indique que le nœud abstrait spécifié DOIT être exclu.
 1 indique que le nœud abstrait spécifié DEVRAIT être évité.

Le reste des champs est comme défini dans la [RFC3209]. Aucun octet d'attribut d'octet n'est défini.

 	3.1.5	Sous objet SRLG
La signification du bit L bit est :
 0 indique que le SRLG spécifié DOIT être exclu
1 indique que le SRLG spécifié DEVRAIT être évité

L'octet Attribut n'est pas présent. Le reste des champs est comme défini au paragraphe 2.1 "Sous objet SRLG".

 	3.2	Règles de traitement pour l'objet EXCLUDE_ROUTE (XRO)
La liste des chemins exclus est codée comme une série de sous objets contenus dans un objet EXCLUDE_ROUTE. Chaque sous objet identifie un nœud abstrait dans la liste des chemins exclus.

Chaque nœud abstrait peut être une adresse IP précisément spécifiée appartenant à un nœud, ou une adresse IP avec un préfixe identifiant des interfaces d'un groupe de nœuds, un système autonome, ou un SRLG.

Le traitement de chemin explicite et de l'acheminement est inchangé par rapport à la description de la [RFC3209] avec les ajouts suivants :

1.	Quand un message Path est reçu à un nœud, le nœud DOIT vérifier qu'il n'est pas membre d'un des nœuds abstraits dans le XRO si il en est un présent dans le message Path. Si le nœud est membre d'un des nœuds abstraits dans le XRO avec le fanion L réglé à "exclure", il DEVRAIT retourner un message PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur de "Nœud local dans la liste des chemins exclus". Si il y a des SRLG dans le XRO, le nœud DEVRAIT vérifier que les ressources utilisées par le nœud ne font pas partie d'un SRLG avec le fanion L réglé à "exclure" spécifié dans le XRO. Si elles en font partie, il DEVRAIT retourner un message PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur de "Nœud local dans la liste des chemins exclus".

2.	Chaque sous objet DOIT être cohérent. Si un sous objet n'est pas cohérent, le nœud DEVRAIT alors retourner un message PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur "Sous objet incohérent". Un exemple de sous objet incohérent est un sous objet Préfixe IPv4 contenant l'adresse IP d'un nœud et où le champ Attribut est réglé à "interface" ou "SRLG".

3.	Les sous objets dans le ERO et XRO NE DEVRAIENT PAS se contredire les uns les autres. Si un message Path est reçu qui contient des sous objets ERO et XRO contradictoires, alors :
-	Les sous objets dans le XRO avec le fanion L à zéro DOIVENT avoir la préséance sur les sous objets dans le ERO – c'est-à-dire que une exclusion obligatoire exprimée dans le XRO DOIT être honorée et une mise en œuvre DOIT rejeter un tel message Path. Cela signifie qu'un PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur de "Chemin bloqué par exclusion de route" est retourné.
-	Les sous objets dans le XRO avec le fanion L établi n'ont pas la préséance sur les sous objets ERO – c'est-à-dire qu'une mise en œuvre PEUT choisir de rejeter un message Path à cause d'une telle contradiction, mais PEUT continuer et établir le LSP (en ignorant les sous objets XRO qui contredisent les sous objets ERO).

4.	Quand il choisit un prochain bond ou qu'il étend un chemin explicite pour inclure des sous objets suplémentaires, un nœud :
a.	NE DOIT PAS introduire un nœud explicite ou un nœud abstrait qui égale ou est membre d'un nœud abstrait spécifié dans l'objet EXCLUDE_ROUTE avec le fanion L réglé à "exclure". Le nombre de nœuds explicites introduits ou de nœuds abstraits avec le fanion L réglé à "éviter", qui indique que l'exclusion n'est pas obligatoire mais qu'il est moins préféré, DEVRAIT être minimisé dans le chemin calculé.
b.	NE DOIT PAS introduire de liaisons, nœuds, ou ressources identifiées par l'identifiant de SRLG spécifié dans le ou les sous objets SRLG. Le nombre de SRLG introduits avec le fanion L réglé à "éviter" DEVRAIT être minimisé.

Si ces règles empêchent la poursuite de la transmission du message Path, le nœud DEVRAIT retourner un PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur de "Chemin bloqué par exclusion de route".

Noter que les sous objets dans le XRO sont une liste non ordonnée de sous objets.

Un nœud recevant un message Path portant un XRO PEUT rejeter le message si le XRO est trop gros ou compliqué pour la mise en œuvre locale ou les règles de politique locale. Dans ce cas, le nœud DOIT envoyer un message PathErr avec le code d'erreur "Erreur d'acheminement" et la valeur d'erreur "XRO trop complexe". Un LSR d'entrée qui reçoit cette combinaison de code/valeur d'erreur PEUT réduire la complexité du XRO ou acheminer en contournant le nœud qui a rejeté le XRO.

Le numéro de classe (Class-Num) du XRO est de la forme 11bbbbbb de sorte que les nœuds qui ne prennent pas en charge le XRO le transmettent sans inspection et n'appliquent pas les extensions de traitement d'ERO décrites ci-dessus. Cette approche est choisie pour permettre que l'exclusion de chemin traverse des parties du réseau qui ne sont pas capables d'analyser ou de traiter la nouvelle fonction. Noter que l'enregistrement de chemin (Record Route) peut être utilisé pour permettre aux nœuds qui font les calculs d'observer les violations d'exclusion de chemin et de tenter de réacheminer le LSP en conséquence.

Si un nœud prend en charge XRO, mais pas un sous objet ou partie de ce sous objet particulier, alors ce sous objet est ignoré. Des exemples d'une partie d'un sous objet qui peuvent être prises en charge sont: (1) seulement le préfixe 32 du sous objet Préfixe IPv4 pourrait être pris en charge, ou (2) un sous objet particulier est pris en charge mais pas le champ d'attribut particulier.

Quand un nœud transmet un message Path, il peut faire les trois opérations suivantes relatives au XRO à côté des règles de traitement mentionnées ci-dessus :

1. Si aucun XRO n'était présent, un XRO peut être inclus.

2. Si un XRO était présent, il peut retirer le XRO si il est sûr que les prochains nœuds n'ont plus besoin de ces informations.  Un exemple est lorsque un nœud peut étendre le ERO à un chemin strict complet vers la destination. Voir la Figure 1 où BC2 retire le XRO du message Path.

3. Si un XRO était présent, le contenu du XRO peut être modifié. Des sous objets peuvent être ajoutés ou retirés. Voir à la Figure 1 un exemple où AB2 supprime certains sous objets.

Dans tous les cas, un nœud NE DOIT PAS introduire de nœud explicite ou abstrait dans le XRO (sans considération de la valeur du fanion L) qu'il a aussi introduit dans le ERO.

 	4.	Exclusion explicite de chemin

L'exclusion explicite de chemin définit des nœuds abstraits ou ressources (comme des liaisons, des interfaces non numérotées, ou des étiquettes) qui ne doivent pas ou ne devraient pas être utilisés sur le chemin entre deux nœuds abstraits ou ressources inclusifs dans le chemin explicite.

 	4.1	Sous objet Exclusion explicite de chemin (EXRS)
Un nouveau type de sous objet ERO est défini. Le sous objet Exclusion explicite de chemin (EXRS, Explicit Exclusion Route) a le type 33. Bien que le EXRS soit un sous objet ERO et que le XRO réutilise le sous objet ERO, un EXRS NE DOIT PAS être présent dans un XRO. Un EXRS est un sous objet ERO qui contient un ou plusieurs sous objets à lui, qui sont appelés des sous objets EXRS.

Le format de EXRS est 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   |           Réservé             |
+-+-------------+---------------+---------------+---------------+
|                                                               |
//                un ou plusieurs sous objets EXRS              //
|                                                               |
+---------------+---------------+---------------+---------------+

L : Il DOIT être réglé à zéro à l'émission et DOIT être ignoré à réception. (Note : le bit L dans un sous objet EXRS est comme défini pour les sous objets XRO.)

Type : type du sous objet (33).

Réservé : ce champ est réservé. Il DEVRAIT être réglé à zéro à l'émission et DOIT être ignoré à réception.

Sous objets EXRS : un sous objet EXRS indique le nœud abstrait ou ressource à exclure. Le format d'un sous objet EXRS est exactement le même que le format d'un sous objet dans le XRO. Un EXRS peut inclure tous les sous objets définis dans le présent document pour le XRO.

Donc, un EXRS pour un bond IP peut ressembler à :

 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   |           Réservé             |
+-+-------------+---------------+---------------+---------------+
|L|    Type     |    Longueur   | Adresse IPv4 (4 octets)       |
+-+-------------+---------------+---------------+---------------+
| Adresse IPv4 (suite)          | Long. préfixe |   Attribut    |
+---------------+---------------+---------------+---------------+

 	4.2	Règles de traitement pour le sous objet Explicit Exclusion Route (EXRS)
Chaque EXRS peut porter plusieurs exclusions. L'exclusion est codée exactement comme pour les sous objets XRO et est préfixée d'un Type et Longueur supplémentaires.

La portée de l'exclusion est l'étape entre le précédent sous objet ERO qui identifie un nœud abstrait, et le sous objet ERO suivant qui identifie un nœud abstrait. Les règles de traitement du EXRS sont les mêmes que celles du XRO dans cette portée. Plusieurs exclusions peuvent être présentes entre toute paire de nœuds abstraits.

Les exclusions peuvent indiquer des nœuds explicites, des nœuds abstraits, ou des systèmes autonomes qui ne doivent pas être traversés sur le chemin vers le prochain nœud abstrait indiqué dans le ERO.

Les exclusions peuvent aussi indiquer des ressources (comme des interfaces non numérotées, des identifiants de liaisons, et des étiquettes) qui ne doivent pas être utilisées sur le chemin pour le prochain nœud abstrait indiqué dans le ERO.

Des SRLG peuvent aussi être indiqués pour l'exclusion du chemin pour le prochain nœud abstrait dans l'ERO par l'inclusion d'un EXRS contenant un sous objet SRLG. Si le bit L dans le sous objet est à zéro, les ressources (nœuds, liaisons, etc.) identifiées par le SRLG NE DOIVENT PAS être utilisées sur le chemin pour le prochain nœud abstrait indiqué dans le ERO. Si le bit L est établi, les ressources identifiées par le SRLG DEVRAIT être évitées.

Si un nœud est invoqué pour traiter un EXRS et qu'il ne prend pas en charge le traitement des exclusions, il va se comporter comme décrit dans la [RFC3209] quand un sous objet ERO non reconnu est rencontré. Cela signifie que ce nœud va retourner un message PathErr avec le code d'erreur "Erreur d'acheminement" et la valeur d'erreur "Mauvais objet EXPLICIT_ROUTE" avec l'objet EXPLICIT_ROUTE inclus, tronqué (sur la gauche) au EXRS en cause.

Si la présence de EXRS empêche de tramettre plus loin le message Path, le nœud DEVRAIT retourner un PathErr avec le code d'erreur "Problème d'acheminement" et la valeur d'erreur "Chemin bloqué par exclusion de route".

Un nœud PEUT rejeter un message Path si le EXRS est trop gros ou trop compliqué pour la mise en œuvre locale ou comme décidé par la politique locale. Dans ce cas, le nœud DOIT envoyer un message PathErr avec le code d'erreur "Erreur d'acheminement" et la valeur d'erreur "EXRS trop complexe". Un LSR d'entrée qui reçoit cette combinaison de code/valeur d'erreur PEUT réduire la complexité de l'EXRS ou contourner le nœud qui a rejeté le EXRS.

 	5.	Traitement de XRO avec EXRS

Quand un LSR effectue l'expansion d'ERO et trouve à la fois le XRO dans le message Path et l'EXRS dans l'ERO, il DOIT exclure tous les SRLG, nœuds, liaisons, et ressources mentionnés dans les deux. Lorsque des éléments apparaissent dans les deux listes, ils DOIVENT être traités en accord avec la plus stricte demande d'exclusion. C'est-à-dire, si une liste dit qu'un SRLG, nœud, liaison, ou ressource doit être exclu, et l'autre dit seulement qu'il devrait être évité, l'élément DOIT être exclu.

 	6.	Conformité minimum

Une mise en œuvre DOIT être au moins conforme à ce qui suit :

1.	Le XRO DOIT être pris en charge avec les restrictions suivantes :
-	Le sous objet Préfixe IPv4 DOIT être pris en charge avec une longueur de préfixe de 32, et une valeur d'attribut de "interface" et "nœud". Les autres valeurs de préfixe et d'attribut PEUVENT être prises en charge.
-	Le sous objet Préfixe IPv6 DOIT être pris en charge avec une longueur de préfixe de 128, et une valeur d'attribut de "interface" et "nœud". Les autres valeurs de préfixe et d'attribut PEUVENT être prises en charge.

2.	Le EXRS PEUT être pris en charge. Si il est pris en charge, les mêmes restrictions que pour le XRO s'appliquent. Si il n'est pas pris en charge, un EXRS rencontré durant le traitement normal de ERO DOIT être rejeté comme sous objet ERO inconnu comme décrit au paragraphe 4.2. Noter qu'un nœud NE DEVRAIT PAS analyser plus loin dans un ERO, et si il le fait, il NE DOIT PAS rejeter l'ERO si il découvre un EXRS qui s'applique à un autre nœud.

3.	Si XRO ou EXRS sont pris en charge, la mise en œuvre DOIT être conforme aux règles de traitement des sous objets  pris en charge, non pris en charge, ou partiellement pris en charge comme spécifié dans le présent document.

 	7.	Considérations sur la sécurité

Les considérations sur la sécurité pour la signalisation MPLS-TE et GMPLS sont traitées dans les [RFC3209] et [RFC3473]. Le présent document n'introduit aucun nouveau message ou traitement substantiel, et donc ces considérations sur la sécurité continuent de s'appliquer.

Noter que tous les problèmes de sécurité qui existent avec les chemins explicites devraient être pris en compte à l'égard des exclusions de chemins. Par exemple, des limites administratives peuvent considérer que des chemins explicites sont des violations de la sécurité et peuvent supprimer les ERO des messages Path qu'elles traitent. Dans ce cas, la suppression du XRO du message Path devrait aussi être considérée.

Il est possible qu'une séquence de complexité arbitraire de XRO ou EXRS puisse être introduite comme forme d'attaque de déni de service car sa présence va potentiellement causer un traitement supplémentaire à chaque nœud sur le chemin du LSP. On devrait noter qu'une telle attaque suppose qu'un LSR par ailleurs de confiance (c'est-à-dire, qui a été authentifié par ses voisins) se comporte mal. Un nœud qui reçoit une séquence de XRO ou EXRS qu'il considère comme trop complexe selon sa politique locale peut répondre avec un message PathErr portant le code d'erreur "Erreur d'acheminement" et la valeur d'erreur "XRO trop complexe" ou "EXRS trop complexe".

 	8.	Considérations relatives à l'IANA

On pourrait considérer qu'une autre approche serait d'allouer un des bits du champ Type de sous objet ERO (peut être le premier bit) pour identifier qu'un sous objet est destiné à être inclus plutôt qu'exclu. Cependant, la [RFC3209] déclare que le champ Type (sept bits) devrait être alloué comme 0 - 63 par action de consensus de l'IETF, 64 - 95 comme premier arrivé, premier servi, et 96 - 127 réservés pour utilisation privée. Il ne serait pas acceptable de perturber les mises en œuvre existantes, de sorte que la seule option serait de partager la gamme de consensus de l'IETF en laissant seulement 32 types de sous objets. Il est estimé que 32 serait un petit nombre inacceptable pour de futures expansions du protocole.

 	8.1	Nouveau type de sous objet ERO
Registre IANA : RSVP PARAMETERS, sous section : Noms, numéros, et types de classes.

Un nouveau sous objet a été ajouté à l'entrée existante pour :

   20  EXPLICIT_ROUTE

Le registre contient :  33  sous objet Exclusion explicite de chemin (EXRS)

Le sous objet Exclusion explicite de chemin (EXRS) est défini au paragraphe 4.1, "Sous objet Exclusion explicite de chemin (EXRS)". Ce sous objet peut être présent dans l'objet Chemin explicite, mais pas dans l'objet Enregistrement de chemin ou dans le nouvel objet EXCLUDE_ROUTE, et il ne devrait pas être mentionné dans les sous objets pour ces objects.

 	8.2	Nouveaux numéros de classe RSVP-TE
Registre IANA : RSVP PARAMETERS, sous section : Noms, numéros, et types de classes.

Un nouveau numéro de classe a été ajouté pour l'objet EXCLUDE_ROUTE (XRO) comme défini au paragraphe 3.1.

EXCLUDE_ROUTE
Type de numéro de classe 11bbbbbb
Valeur : 232
C-type défini : 1 (EXCLUDE_ROUTE)

Les sous objets 1, 2, 4, et 32 sont comme défini pour l'objet Chemin explicite. Un sous objet supplémentaire a été enregistré comme demandé au paragraphe 8.1, "Nouveau type de sous objet ERO". Le texte devrait apparaître comme :

Type de sous objet
      1   Adresse IPv4 	[RFC3209]
      2   Adresse IPv6	[RFC3209]
      4   Identifiant d'interface non numérotée	[RFC3477]
    32   Numéro de système autonome	[RFC3209]
    33   Sous objet Exclusion explicite de chemin (EXRS)	[RFC4874]
    34   SRLG	[RFC4874]

Le sous objet SRLG est défini au paragraphe 3.1.5, "Sous objet SRLG".
La valeur 34 lui a été alloué.

 	8.3	Nouveaux codes d'erreur
Registre IANA : RSVP PARAMETERS
Sous section : Codes d'erreur et sous codes de valeur d'erreur définis globalement

Les nouveaux sous codes de valeurs d'erreur ont été enregistrés pour le code d'erreur 'Problème d'acheminement' (24).
64 = Type de sous objet Chemin exclu non pris en charge
65 = Sous objet incohérent
66 = Nœud local dans le chemin exclu
67 = Chemin bloqué par exclusion de route
68 = XRO trop complexe
69 = EXRS trop complexe

 	9.	Remerciements

Le présent document réutilise le texte de la [RFC3209] pour la description de EXCLUDE_ROUTE.

Les auteurs expriment leurs remerciements à Lou Berger, Steffen Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, et Richard Rabbat pour leurs opinions prises en compte dans le présent document. Merci aussi à Yakov Rekhter qui nous a rappelé les SRLG !

Merci à Eric Gray qui a fournit la revue par GenArt et à Ross Callon pour ses commentaires.

 	10.	Références
 	10.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. (MàJ par RFC8174)

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

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

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

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

 	10.2	Références pour information

[RFC4920]	A. Farrel et autres, "Extensions de signalisation de retour en arrière pour RSVP-TE MPLS et GMPLS", juillet 2007. (P.S.)

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

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

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

[RFC4208]	G. Swallow et autres, "Interface usager-réseau (UNI) de commutation généralisée d'étiquettes multiprotocoles (GMPLS) : prise en charge du protocole de réservation de ressource - ingénierie du trafic (RSVP-TE) pour le modèle de recouvrement", octobre 2005. (P.S.)

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

 	Appendice A.	Applications

Cette section décrit quelques applications qui peuvent utiliser le XRO. L'intention est de montrer que le XRO n'est pas un objet spécifique d'application, mais qu'il peut être utilisé pour plusieurs objets. Dans quelques exemples, d'autres solutions seraient possibles pour ce cas particulier, mais l'intention est de montrer qu'un seul objet peut être utilisé pour tous les exemples, donc rendant le XRO un objet plutôt générique sans avoir à définir une solution et de nouveaux objets pour chaque nouvelle application.

 	A.1	Protection de LSP inter zones
Une méthode pour établir un LSP inter zones est quand le routeur d'entrée choisit un ABR, et qu'ensuite le routeur d'entrée calcule un chemin vers cet ABR choisi afin que les contraites configurées du LSP soient satisfaites. Dans l'exemple de la Figure A.1, un LSP doit être établi du nœud A dans la zone 1 au nœud C dans la zone 2. Si aucun bond lâche n'est configuré, alors le ERO calculé en A pourrait ressembler à : (A1-strict, A2-strict, ABR1-strict, C-lâche). Quand le message Path arrive à ABR1, l'ERO est alors (ABR1-strict, C-lâche) et il peut être étendu par ABR1 à (B1-strict, ABR3-strict, C-lâche). De même, en ABR3 l'ERO reçu est (ABR3-strict, C-lâche) et il peut être étendu à (C1-strict, C2-strict, C-strict). Si un LSP de sauvegarde a aussi à être établi, alors A prend un autre ABR (ABR2 dans ce cas) et calcule un chemin vers cet ABR qui satisfait les contraintes du LSP et qui est disjoint du chemin du LSP primaire. Le ERO généré par A ressemble à ce qui suit pour cet exemple : (A3-strict, A4-strict, ABR2-strict, C-lâche).

Afin de laisser ABR2 étendre le ERO, il a aussi besoin de connaître le chemin du LSP primaire afin que l'expansion de l'ERO soit disjointe du chemin du LSP primaire. Donc, A inclut aussi un XRO qui contient au moins (ABR1, B1, ABR3, C1, C2). Sur la base de ces contraintes, ABR2 peut étendre le ERO de façon à ce qu'il soit disjoint du LSP primaire. Dans cet exemple, le ERO calculé par ABR2 serait (B2-strict, ABR4-strict, C-lâche) et le XRO généré par B contiendrait au moins (ABR3, C1, C2). Ces dernières informations sont nécessaires pour que ABR4 étendre le ERO afin que le chemin soit disjoint du LSP primaire dans la zone 2.

            Zone 1           Zone 0          Zone 2
       <---------------><--------------><--------------->
       +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+
       |        |              |              |         |
       |        |              |              |         |
       A        |              |              |         C
       |        |              |              |         |
       |        |              |              |         |
       +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+

Figure A.1 : LSP inter zones

Dans cet exemple, un nœud effectuant le calcul de chemin commence par choisir un ABR et ensuite calcule un chemin strict vers cet ABR. Pour le LSP de sauvegarde, tous les nœuds du LSP primaire dans les prochaines zones doivent être mis dans le XRO (à l'exception du nœud de destination si une protection de nœud et pas de protection de liaison sont nécessaires). Quand un ABR calcule le prochain segment de chemin, c'est-à-dire, le chemin vers la prochaine zone, il peut supprimer les nœuds du XRO qui sont situés dans cette zone à l'exception de l'ABR où le LSP primaire sort de la zone. Cette dernière information est encore nécessaire parce que quand l'ABR choisi (ABR4 dans cet exemple) étend encore l'ERO, il doit exclure l'ABR sur lequel le LSP primaire entre dans cette zone (ABR3 dans cet exemple). Cela signifie que quand ABR2 génère un XRO, il peut supprimer les nœuds dans la zone 0 du XRO mais pas ABR3. Noter que ne pas faire cela ne causerait pas de dommages dans cet exemple parce que il n'y a pas de chemin de ABR4 à C via ABR3 dans la zone  2. Si il y avait une liaison entre ABR4-ABR3 et ABR3-C, alors il serait nécessaire d'avoir ABR3 dans le XRO généré par ABR2.

Discussion sur la longueur du XRO : quand la protection de la liaison ou du nœud est demandée, la longueur du XRO est limitée par la longueur du RRO du LSP primaire. Il peut être raccourci en supprimant les nœuds par le nœud d'entrée et les ABR. Dans l'exemple ci-dessus, le RRO du LSP primaire contient 8 sous objets, tandis que la longueur maximum de XRO peut être limitée à 6 sous objets (les nœuds A1 et A2 n'ont pas à être dans le XRO). Pour la protection de SRLG, le XRO doit faire la liste de tous les SRLG qui sont traversés par le LSP primaire.

 	A.2	Protection de LSP inter AS
Quand un LSP inter AS (qui doit être protégé par un LSP de sauvegarde pour fournir la protection de liaison ou de nœud) est établi, la même méthode que pour le cas du LSP inter zones peut être utilisée. La différence est quand le LSP de sauvegarde ne suit pas le même chemin d'AS que le LSP primaire parce que alors le XRO devrait toujours contenir le chemin complet du LSP primaire. Dans le cas où le LSP de sauvegarde suit le même chemin d'AS (mais avec des ASBR différents -- au moins en cas de protection du nœud) c'est similaire au cas inter zones : les ASBR qui étendent le ERO sur le prochain AS peuvent retirer les sous objets XRO situés dans cet AS. Noter que cela ne peut être fait que par un ASBR d'entrée (le ASBR où le LSP entre dans l'AS).

Discussion sur la longueur du XRO : le XRO est lié par la longueur du RRO du LSP primaire.
Supposons que la protection de SRLG soit requise, et que les AS traversés par le LSP primaire utilisent une façon cohérente d'allouer les identifiants de SRLG aux liaisons (c'est-à-dire, les AS utilisent un seul espace de SRLG). Dans ce cas, les identifiants de SRLG de chaque liaison utilisée par le LSP primaire peuvent être enregistrés au moyen du RRO ; les identifiants de SRLG sont alors utilisés par le XRO. Si les identifiants de SRLG sont seulement significatifs quand ils sont locaux pour l'AS, mettre les identifiants de SRLG dans le XRO qui traverse de nombreus AS n'a pas de sens. Pour fournir la protection de SRLG pour les LSP inter AS l'adresse IP de la liaison inter AS utilisée par le LSP primaire peut être mise dans le XRO du message Path du LSP de détournement ou du tunnel de contournement. Le ASBR où le LSP de détournement ou tunnel de contournement entre dans l'AS peut traduire cela dans la liste des identifiants de SRLG connus de l'AS local.

Discussion sur la longueur du XRO : le XRO contient seulement un sous objet, qui contient l'adresse IP de la liaison inter AS traversée par le LSP primaire (en supposant que le LSP primaire et le LSP de détournement ou tunnel de contournement quittent l'AS dans la même zone, et qu'ils entrent aussi dans le prochain AS dans la même zone).

 	A.3	Protection dans le modèle de recouvrement GMPLS
Quand un nœud de bordure veut établir un LSP vers un autre nœud de bordure sur un réseau de cœur optique comme décrit dans la [RFC4208] (voir la Figure A.2) le XRO peut être utilisé à plusieurs fins.

     Réseau                                                   Réseau
    superposé       +--------------------------------+        superposé
   +----------+     |                                |     +----------+
   |   +----+ |     |  +-----+   +-----+   +-----+   |     | +----+   |
   |   |    | |     |  |     |   |     |   |     |   |     | |    |   |
   | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
   |   |    | |  +--+--+     |   |     |   |     +---+--+  | |    |   |
   |   +----+ |  |  |  +--+--+   +--+--+   +--+--+   |  |  | +----+   |
   |          |  |  |     |         |         |      |  |  |          |
   +----------+  |  |     |         |         |      |  |  +----------+
                 |  |     |         |         |      |  |
   +----------+  |  |     |         |         |      |  |  +----------+
   |          |  |  |  +--+--+      |      +--+--+   |  |  |          |
   |   +----+ |  |  |  |     |      +------+     |   |  |  | +----+   |
   |   |    +-+--+  |  | CN4 +-------------+ CN5 |   |  +--+-+    |   |
   | --+ EN2+-+-----+--+     |             |     +---+-----+-+ EN4+-- |
   |   |    | |     |  +-----+             +-----+   |     | |    |   |
   |   +----+ |     |                                |     | +----+   |
   |          |     +--------------------------------+     |          |
   +----------+                Réseau cœur                 +----------+
       Réseau                                                  Réseauy
      superposé                                               superposé

Légende :
EN (Edge-Node) nœud de bordure
CN (Core-Node) nœud de cœur

Figure A.2

Une première application est quand un nœud de bordure veut établir plusieurs LSP vers le même nœud de bordure de destination, et que ces LSP ont besoin d'avoir peu ou pas de SRLG en commun. Dans ce cas, EN1 pourrait établir un LSP vers EN3, et ensuite il peut établir un second LSP faisant la liste de toutes les liaisons utilisées par le premier LSP avec l'indication d'éviter les SRLG de ces liaisons. Cette information peut être utilisée par CN1 pour calculer un chemin pour le second LSP. Si le cœur de réseau consiste en plusieurs zones, alors les identifiants de SRLG doivent être mentionnés dans le XRO. Le même exemple s'applique aux nœuds et aux liaisons.

Une autre application est lorsque le nœud de bordure veut établir un LSP de sauvegarde qui protège aussi les liaisons entre les nœuds de bordure et les nœuds de cœur. Par exemple, quand EN2 établit un LSP pour EN4, il envoie un message Path à CN4, qui calcule un chemin vers EN4 sur (par exemple) CN5. Quand EN2 reçoit en retour le RRO de ce LSP, il peut signaler un nouveau LSP à CN1 avec EN4 comme destination et le XRO calculé sur la base du RRO du premier LSP. Sur la base de ces informations, CN1 peut calculer un chemin qui a les propriétés de diversité demandées (par exemple, un chemin allant sur CN2 et CN3, et ensuite à EN4).

Il est clair que dans ces exemples, le nœud de cœur ne peut pas altérer le RRO dans un message Resv pour faire que son seul contenu soit les sous objets provenant du nœud de cœur de sortie jusqu'au nœud de bordure de sortie.

 	A.4	Protection de LSP l'intérieur d'une seule zone
Le XRO peut aussi être utilisé à l'intérieur d'une seule zone. Prenons par exemple un réseau où les extensions TE des IGP décrites dans les [RFC3630] et [RFC3784] ne sont pas utilisées. Donc, chaque nœud doit choisir un prochain bond et éventuellement le retour en arrière [RFC4920] doit être utilisé quand il n'y a pas de prochain bond viable. Dans ce cas, quand on signale un LSP de sauvegarde, le XRO peut être mis dans le message Path pour exclure les liaisons, nœuds, ou SRLG du LSP primaire. Un autre façon de fournir cette fonctionnalité serait d'indiquer ce qui suit dans le message Path du LSP de sauvegarde : le LSP primaire et le type de protection requis. Cette dernière solution fonctionnerait pour la protection de liaison et de nœud , mais pas pour la protection de SRLG.

Quand la protection de liaison ou de nœud est demandée, le XRO est de la même longueur que le RRO du LSP primaire. Pour la protection de SRLG, le XRO doit faire la liste de tous les SRLG qui sont traversés par le LSP primaire. Noter que pour la protection de SRLG, l'adresse IP de liaison pour référencer les SRLG de cette liaison ne peut pas être utilisée car les extensions TE des IGP ne sont pas utilisées dans cet exemple. Donc, un nœud ne peut pas traduire une adresse IP de liaison située dans cette zone à ses SRLG.

 	Adresse des auteurs

Cheng-Yin Lee	Adrian Farrel	Stefaan De Cnodder	
mél : c.yin.lee@gmail.com 	Old Dog Consulting	Alcatel-Lucent	
	téléphone : +44 (0) 1978 860944	Copernicuslaan 50	
	mél : adrian@olddog.co.uk 	B-2018 Antwerp Belgium	
		mél : stefaan.de_cnodder@alcatel-lucent.be 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur 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.

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