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 Identifiants de liaison locale/distante

1.2 Type de protection de liaison

1.3 Groupe de liaisons à risques partagés

1.4 Descripteur de capacité de commutation d'interface

2. Implications sur le redémarrage en douceur

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

4. Contributeurs

5. Remerciements

6. Considérations sur la sécurité

7. Considérations relatives à l'IANA

8. Références

Adresse des auteurs

Déclaration complète de droits de reproduction


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.