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

Extensions OSPF pour la prise en charge de 
la commutation d'étiquettes multi protocoles généralisée (GMPLS)

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

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

Résumé
Le présent document spécifie le codage des extensions au protocole d'acheminement OSPF pour la prise en charge de la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching).
Table des Matières
1. Introduction	1
1.1 Identifiants de liaison locale/distante	2
1.2 Type de protection de liaison	2
1.3 Groupe de liaisons à risques partagés (SRLG, Shared Risk Link Group)	2
1.4 Descripteur de capacité de commutation d'interface	3
2. Implications sur le redémarrage en douceur	4
3. Échange d'informations de TE de liaison locale	5
4. Contributeurs	5
5. Remerciements	6
6. Considérations sur la sécurité	6
7. Considérations relatives à l'IANA	6
8. Références	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	7
1.	Introduction

Le présent document spécifie des extensions au protocole d'acheminement OSPF [RFC2328] pour la prise en charge du transport des informations d'état de liaison dans le cadre de la commutation d'étiquette multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). L'ensemble des améliorations requises pour OSPF est présenté dans la [RFC4202].

Dans cette section, on définit les améliorations aux propriétés d'ingénierie du trafic (TE, Traffic Engineering) des liaisons GMPLS TE qui peuvent être annoncées dans les annonces d’état de liaison (LSA, Link State Advertisement) TE OSPF. La LSA TE, qui est une LSA opaque avec une portée d'arrosage de zone [RFC3630], a seulement un triplet Type/Longueur/Valeur (TLV) de niveau supérieur et a un ou plusieurs sous TLV incorporés pour l'extensibilité. Le TLV de niveau supérieur peut prendre une des deux valeurs (1) Adresse de routeur ou (2) Liaison. Dans le présent document, on améliore les sous TLV pour le TLV liaison pour la prise en charge de GMPLS. Spécifiquement, on ajoute les sous TLV suivants au TLV Liaison : 

Type de sous TLV	Longueur	Nom	
11	8	Identifiants de liaison locale/distante	
14	4	Type de protection de liaison	
15	variable	Descripteur de capacité de commutation d'interface	
16	variable	Groupe de liaisons à risque partagé	

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

1.1	Identifiants de liaison locale/distante
Identifiants de liaison locale/distante est un sous TLV du TLV Liaison. Le type de ce sous TLV est 11, et sa longueur est de huit octets. Le champ Valeur de ce sous TLV contient quatre octets d'identifiant de liaison locale suivis par quatre octets d'identifiant de liaison distante (voir le paragraphe 2.1 "Prise en charge des liaisons non numérotées" de la [RFC4202]). Si l'identifiant de liaison distante est inconnu, il est réglé à 0.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  identifiant de liaison locale                |
+---------------+---------------+---------------+---------------+
|                  identifiant de liaison distante              |
+---------------+---------------+---------------+---------------+

Un nœud peut communiquer son identifiant de liaison locale à son voisin en utilisant une LSA opaque de liaison locale, comme décrit à la Section 3 "Échange des informations TE de liaison locale".

1.2	Type de protection de liaison
Le type de protection de liaison est un sous TLV du TLV Liaison. Le type de ce sous TLV est 14, et sa longueur est de quatre octets.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cap protection |                    Réservé                    |
+---------------+---------------+---------------+---------------+

Le premier octet est un vecteur binaire qui décrit les capacités de protection de la liaison (voir le paragraphe 202 "Type de protection de liaison" de la [RFC4202]). Ce sont :
0x01	Extra Traffic (trafic supplémentaire)
0x02	Unprotected (non protégé)
0x04	Shared( (partagé)
0x08	Dedicated 1:1 (dédié 1:1)
0x10	Dedicated 1+1 (dédié 1+1)
0x20	Enhanced (amélioré)
0x40	réservé
0x80	réservé
Les trois octets restants DEVRAIENT être réglés à zéro par l'envoyeur, et DEVRAIENT être ignorés par le receveur.
Le sous TLV Type de protection de liaison ne peut se produire qu'une seule fois au sein du TLV Liaison.

1.3	Groupe de liaisons à risques partagés (SRLG, Shared Risk Link Group)
Le groupe de liaisons à risques partagés (SRLG, Shared Risk Link Group) est un sous TLV (de type 16) du TLV Liaison. Sa longueur est la longueur de la liste en octets. La valeur est une liste non ordonnée de nombres de 32 bits qui sont les SRLG auxquels la liste appartient. Le format du champ Valeur est montré ci-dessous :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Valeur de groupe de liaisons à risques partagés  |
+---------------+---------------+---------------+---------------+
|                        ............                           |
+---------------+---------------+---------------+---------------+
|              Valeur de groupe de liaisons à risques partagés  |
+---------------+---------------+---------------+---------------+

Ce sous TLV porte les informations de groupe de liaisons à risques partagés (voir le paragraphe 2.3 "Informations de risque partagé pour un groupe de liaisons" de la [RFC4202]).

Le sous TLV SRLG ne peut se produire qu'une seule fois au sein du TLV Liaison.

1.4	Descripteur de capacité de commutation d'interface
Le descripteur de capacité de commutation d'interface est un sous TLV (de type 15) du TLV Liaison. Sa longueur est la longueur du champ Valeur en octets. Le format du champ Valeur est montré ci-dessous :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cap commutation|   Codage      |           Réservé             |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 0    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 1    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 2    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 3    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 4    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 5    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 6    |
+---------------+---------------+---------------+---------------+
|                  Bande passante max de LSP à la priorité 7    |
+---------------+---------------+---------------+---------------+
|        Informations spécifiques de la capacité de commutation |
|                  (variable)                                   |
+---------------+---------------+---------------+---------------+

Le champ Capacités de commutation (Cap commutation) contient une des valeurs suivantes :
1	(PSC-1, Packet-Switch Capable-1) : capacité 1 de commutation de paquet
2	(PSC-2, Packet-Switch Capable-2) : capacité 2 de commutation de paquet
3	(PSC-3, Packet-Switch Capable-3) : capacité 3 de commutation de paquet
4	(PSC-4, Packet-Switch Capable-4) : capacité 4 de commutation de paquet
51	(L2SC, Layer-2 Switch Capable) : capacité de commutation de couche 2
100	(TDM, Time-Division-Multiplex Capable) : capacité de multiplexage à division temporelle
150	(LSC, Lambda-Switch Capable) : capacité de commutation lambda
200	(FSC, Fiber-Switch Capable) : capacité de commutation optique

Le champ Codage contient une des valeurs spécifiées au paragraphe 3.1.1 de la [RFC3471].

La bande passante maximum de LSP est codée comme une liste de huit champs de 4 octets dans le format de virgule flottante IEEE [IEEE], avec la priorité 0 en premier et la priorité 7 en dernier. Les unités sont des octets (pas des bits !) par seconde.

Le contenu du champ Informations spécifiques de capacité de commutation dépend de la valeur du champ Capacités de commutation. Quand le champ Capacités de commutation est PSC-1, PSC-2, PSC-3, ou PSC-4, le champ Informations spécifiques de capacité de commutation inclut la bande passante minimum de LSP, la MTU d'interface, et un bourrage.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Bande passante minimum de LSP                   |
+---------------+---------------+---------------+---------------+
|         MTU d'interface       |          Bourrage             |
+---------------+---------------+---------------+---------------+

La bande passante minimum de LSP est codée dans un champ de 4 octets dans le format de virgule flottante IEEE. Les unités sont des octets (pas des bits !) par seconde. La MTU d'interface est codée comme un entier de 2 octets. Le bourrage fait 2 octets, et est utilisé pour aligner le sous TLV sur une limite de 32 bits. Il DEVRAIT être réglé à zéro par l'envoyeur et DEVRAIT être ignoré par le receveur.

Quand le champ Capacités de commutation est L2SC, aucun champ Informations spécifiques de capacités de commutation n'est présent.

Quand le champ Capacités de commutation est TDM, le champ Informations spécifiques de capacités de commutation  inclut la bande passante minimum de LSP, l'indication que l'interface prend en charge le SONET/SDH standard ou arbitraire, et le bourrage.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Bande passante minimum de LSP                   |
+---------------+---------------+---------------+---------------+
|   Indication  |               Bourrage                        |
+---------------+---------------+---------------+---------------+

La bande passante minimum de LSP est codée dans un champ de 4 octets dans le format de virgule flottante de l'IEEE. Les unités sont des octets (pas des bits !) par seconde. L'indication de si l'interface prend en charge le SONET/SDH standard ou arbitraire est codée sur 1 octet. La valeur de cet octet est 0 si l'interface prend en charge le SONET/SDH standard, et 1 si l'interface prend en charge le SONET/SDH arbitraire. Le bourrage fait 3 octets, et est utilisé pour aligner le sous TLV Descripteur de capacités de commutation d'interface sur la limite de 32 bits. Il DEVRAIT être réglé à zéro par l'envoyeur et DEVRAIT être ignoré par le receveur.

Quand le champ Capacités de commutation est LSC, aucun champ Informations spécifiques de capacités de commutation n'est présent.

Pour prendre en charge les interfaces qui ont plus d'un descripteur de capacités de commutation d'interface (voir le paragraphe 2.4 "Descripteur de capacités de commutation d'interface" de la [RFC4202]) le sous TLV Descripteur de capacités de commutation d'interface peut se produire plus d'une fois au sein du TLV Liaison.

2.	Implications sur le redémarrage en douceur

Le nœud qui redémarre devrait suivre les procédures de redémarrage OSPF [RFC3623], et les procédures de redémarrage RSVP-TE [RFC3473].

Lorsque un nœud qui redémarre va générer ses LSA TE, les LSA TE qui contiennent le TLV Liaison devraient être générés avec une bande passante non réservée de 0, la métrique d'ingénierie du trafic réglée à 0xffffffff, et si la liaison a LSC ou FSC comme capacité de commutation, alors aussi avec 0 comme bande passante maximum de LSP, jusqu'à ce que le nœud soit capable de déterminer la quantité de ressources non réservées en prenant en compte les ressources réservées par les LSP déjà établis qui ont été préservés à travers le redémarrage. Une fois que le nœud qui redémarre a déterminé la quantité de ressources non réservées, en prenant en compte les ressources réservées par les LSP déjà établis qui ont été préservés à travers le redémarrage, le nœud devrait annoncer ces ressources dans ses LSA TE.

De plus, dans le cas d'un redémarrage prévu avant de redémarrer; le nœud qui redémarre DEVRAIT générer les LSA TE contenant le TLV Liaison avec 0 comme bande passante non réservée, et si la liaison a LSC ou FSC comme capacité de commutation, alors aussi avec 0 comme bande passante maximum de LSP. Cela va décourager l'établissement de nouveaux LSP à travers le routeur de redémarrage.

Les voisins du nœud qui redémarre devraient continuer d'annoncer la bande passante non réservée réelle sur les liaisons TE des voisins à ce nœud.

Le redémarrage en douceur régulier ne devrait pas être interrompu si une LSA TE ou la topologie TE change. Le redémarrage TE en douceur n'a pas besoin d'être interrompu si une LSA TE ou la topologie TE change.

3.	Échange d'informations de TE de liaison locale

Il est souvent utile qu'un nœud communique des informations d'ingénierie de trafic pour une certaine interface à ses voisins sur cette interface. Un exemple est celui de l'identifiant de liaison locale. Si les nœuds X et Y sont connectés par une interface point à point non numérotée I, alors l'identifiant de liaison locale de X pour I est l'identifiant de liaison distante de Y pour I. X peut communiquer son identifiant de liaison locale pour I en échangeant avec Y une LSA TE de liaison locale opaque décrite ci-dessous. Noter que cette information a seulement besoin d'être échangée sur l'interface I, d'où l'utilisation de la LSA de liaison locale opaque.

Une LSA TE de liaison locale est une LSA opaque de type 9 (portée d'arrosage de liaison locale) avec le type1 Opaque (LSA TE) et un identifiant opaque de 0.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Age de LS           |    Options    |       9       |
+---------------+---------------+---------------+---------------+
|  Type Opaque  |            Identifiant opaque                 |
+---------------+---------------+---------------+---------------+
|                     Routeur annonceur                         |
+---------------+---------------+---------------+---------------+
|                  Numéro de séquence de LS                     |
+---------------+---------------+---------------+---------------+
|   Somme de contrôle de LS     |         Longueur              |
+---------------+---------------+---------------+---------------+
|                                                               |
+-                            TLV                              -+
|                             ...                               |

Le format des TLV qui constituent le corps de la LSA TE Liaison locale est le même que celui des TLV TE : un champ Type de 2 octets suivi par un champ Longueur de 2 octets qui indique la longueur du champ Valeur en octets. Le type de niveau supérieur pour le TLV Liaison locale est 4. Le champ Valeur est bourré de zéros jusqu'à la fin d'une limite de quatre octets.

Le seul TLV défini ici est le TLV Identifiant de liaison locale, avec le type 1, la longueur 4 et la valeur d'identifiant de liaison locale pour la liaison sur laquelle la LSA TE de liaison locale est échangée.

4.	Contributeurs

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

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

Vishal Sharma	
Metanoia, Inc.	
335 Elan Village Lane, Unit 203	
San Jose, CA 95134-2539	
téléphone : +1 408-943-1794	
mél : v.sharma@ieee.org 	

5.	Remerciements

Les auteurs tiennent à remercier Suresh Katukam, Jonathan Lang, Quaizar Vohra, et Alex Zinin de leurs commentaires sur ce document.

6.	Considérations sur la sécurité

Le présent document spécifie le contenu des LSA opaques dans OSPFv2. Comme les LSA opaques ne sont pas utilisées pour le calcul de SPF ou l'acheminement normal, les extensions spécifiées ici n'ont pas d'effet direct sur l'acheminement IP. L'altération des LSA GMPLS TE peut avoir un effet sur le réseau de transport sous-jacent (optique et/ou SONET-SDH). La [RFC3630] suggère des mécanismes tels que [RFC2154] pour protéger la transmission de ces informations, et ces mécanismes ou d'autres devraient être utilisés pour sécuriser et/ou authentifier les informations portées dans les LSA opaques.

7.	Considérations relatives à l'IANA

Le présent mémoire introduit quatre nouveaux sous TLV du TLV Liaison TE dans le LSA opaque TE pour OSPF v2 ; la [RFC3630] dit que les sous TLV du TLV Liaison TE dans la gamme 10 à 32767 doivent être alloués par revue d'expert, et doivent être enregistrés par l'IANA.

Le mémoire suggère quatre valeurs pour les quatre sous TLV du TLV Liaison TE ; il est fortement recommandé que les valeurs suggérées soient accordées, car il y a des mises en œuvre interopérables qui utilisent ces valeurs.

Finalement, un nouveau type de niveau supérieur pour les LSA OSPF TE pour le TLV Liaison locale a été alloué à partir de l'espace d'action de normalisation.

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

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

[RFC2154]	S. Murphy, M. Badger et B. Wellington, "OSPF avec des signatures numériques", juin 1997. (Expérimental)

[RFC2228]	M. Horowitz, S. Lunt, "Extensions de sécurité pour FTP", octobre 1997. (P.S.)

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

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

[RFC3623]	J. Moy, P. Pillay-Esnault, A. Lindem, "Redémarrage OSPF en mode dégradé", novembre 2003. (P.S.)

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

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

Adresse des auteurs

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

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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

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

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .
L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

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