Extensions à OSPF pour avertir
des capacités optionnelles de routeur

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est soumise à aucune restriction.

Déclaration de copyright

Copyright (C) The IETF Trust (2007).

Résumé

Il est utile aux routeurs dans un domaine d’acheminement OSPFv2 ou OSPFv3 de connaître les capacités de leurs voisins et des autres routeurs dans le domaine d’acheminement. Le présent document propose des extensions à OSPFv2 et OSPFv3 pour avertir des capacités optionnelles des routeurs. Un nouvel avis d’état de liaison (LSA, Link State Advertisement) d’information de routeur (RI, Router Information) est proposé à cette fin. Dans OSPFv2, le LSA de RI sera mis en œuvre avec un nouvel ID opaque de type de LSA. Dans OSPFv3, le LSA de RI sera mis en œuvre avec un nouveau code de fonction de type de LSA. Dans les deux protocoles, le LSA de RI peut être publié à tout moment des portées de diffusion définies (liaison, zone, ou système autonome (AS, autonomous system)).

Table des matières

1. Introduction
1.1 Notation des exigences
2. LSA OSPF d’information de routeur (RI)
2.1 LSA opaque OSPFv2 d’information de routeur (RI)
2.2 LSA opaque d’information de routeur (RI) OSPFv3
2.3 TLV de capacité d’information de routeur OSPF
2.4 Allocation des bits de capacité d’information de routeur OSPF
2.5 Portée de diffusion du LSA d’information de routeur
3. Usage et applicabilité de LSA opaque d’information de routeur
4. Considérations pour la sécurité
5. Considérations relatives à l’IANA
6. Références
6.1 Références normatives
6.2. Références informatives
Appendice A. Remerciements

1. Introduction

Il est utile aux routeurs dans un domaine d’acheminement OSPFv2 [OSPF] ou OSPFv3 [OSPFV3] de connaître les capacités des routeurs voisins et des autres routeurs dans le domaine d’acheminement. Cela peut être utile à la fois pour l’annonce et la découverte des capacités OSPFv2 et OSPFv3. Tout au long du présent document, OSPF sera utilisé lorsque la spécification s’applique à la fois à OSPFv2 et OSPFv3. De même, OSPFv2 ou OSPFv3 seront utilisés lorsque le texte est spécifique d’un protocole.

OSPF utilise le champ Options dans les LSA et les paquets hello pour avertir des capacités facultatives de routeur. Dans le cas de OSPFv2, tous les bits dans ce champ ont été alloués de sorte que de nouvelles capacités facultatives ne peuvent être publiées. Le présent document propose des extensions à OSPF pour avertir de ces capacités facultatives via des LSA opaques dans OSPFv2 et de nouveaux LSA dans OSPFv3. Pour les capacités OSPF existantes, les questions de rétrocompatibilité imposent que cet avis soit principalement utilisé pour des besoins d’information. Pour les caractéristiques OSPF futures, cet avis PEUT être utilisé comme mécanisme unique pour l’annonce et la découverte.

1.1 Notation des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans [RFC-KEYWORDS].

2. LSA OSPF d’information de routeur (RI)

Les routeurs OSPF PEUVENT facultativement avertir de leurs capacités facultatives dans un LSA de portée de liaison, de portée de zone, ou de portée d’AS. Pour les capacités OSPF existantes, cet avis sera principalement utilisé pour des besoins d’information. Les caractéristiques OSPF futures pourront utiliser le LSA de RI comme seul mécanisme d’annonce et de découverte. Le LSA de RI sera généré initialement lorsqu’une instance de routeur OSPF est créée et chaque fois qu’une des capacités annoncées est configurée ou changée.

2.1 LSA opaque d’information de routeur (RI) OSPFv2

Les routeurs OSPFv2 vont annoncer un LSA opaque de portée liaison, de portée zone, ou de portée AS [OPAQUE]. Le LSA OSPFv2 Information de routeur a un type Opaque de 4 et un identifiant Opaque de 0.

LSA opaque d’information de routeur OSPFv2

Le format des TLV au sein du corps d’un LSA de RI est le même que le format utilisé par les extensions d’ingénierie du trafic d’OSPF [TE]. La charge utile du LSA consiste en un or plusieurs triplets incorporés de Type/Longueur/Valeur (TLV). Le format de chaque TLV est :

Format de TLV

Le champ Longueur définit la longueur de la portion valeur en octets (et donc, un TLV sans portion valeur aurait une longueur de 0). Le TLV est bourré sur un alignement de 4 octets ; le bourrage n’est pas inclus dans le champ de longueur (de sorte qu’une valeur de 3 octets aura une longueur de 3, mais la taille totale du TLV sera de 8 octets). Les TLV incorporés sont aussi alignés sur 32 bits. Par exemple, une valeur de 1 octet aura un champ de longueur réglé à 1, et 3 octets de bourrage seront ajoutés à la fin de la portion valeur du TLV. Les types non reconnus sont ignorés.

2.2 LSA opaque d’information de routeur (RI) OSPFv3

Le LSA Information de routeur d’OSPFv3 a un code de fonction de 12 alors que les bits S1/S2 dépendent de la portée de diffusion souhaitée pour le LSA. Le bit U sera réglé de façon à indiquer que le LSA RI OSPFv3 devrait être diffusé même si il n’est pas compris. La valeur d’identifiant d’état de liaison (LSID, Link State ID) pour ce LSA est 0. Ceci n’est pas équivoque car un routeur OSPFv3 va annoncer seulement un LSA de RI par instance de diffusion.

LSA d’information de routeur OSPFv3

Le format des TLV au sein du corps d’un LSA de RI est tel que défini au paragraphe 2.1

Lorsqu’un nouveau TLV de LSA d’information de routeur est défini, la spécification DOIT explicitement déclarer si le TLV est applicable à OSPFv2 seulement, à OSPFv3 seulement, ou aux deux OSPFv2 et OSPFv3.

2.3 TLV de capacité d’information de routeur OSPF

Le premier TLV défini dans le corps d’un LSA de RI est le TLV de capacité d’information de routeur. Un routeur qui annonce un LSA de RI PEUT inclure le TLV Capacités d’information de routeur. S’il est inclus, il DOIT être le premier TLV dans le LSA. De plus, le TLV DOIT refléter précisément les capacités du routeur OSPF dans le domaine d’annonce. Cependant, les capacités d’information annoncées n’ont pas d’impact sur le fonctionnement du protocole OSPF – elles ne sont annoncées que pour des besoins d’information.

Le format du TLV de capacité d’information de routeur est le suivant :

Type : un champ de 16 bits mis à 1.

Longueur : un champ de 16 bits qui indique la longueur de la portion valeur en octets sera un multiple de 4 octets selon le nombre de capacités annoncées. Au début, la longueur sera 4, notant 4 octets de bits de capacité d’information.

Valeur : séquence de longueur variable de bits de capacité, arrondie à un multiple de 4 octets, bourrée avec des bits non définis. Au début, il y a 4 octets de bits de capacité. Les bits sont numérotés de gauche à droite, en commençant par le bit de poids fort qui est le bit 0.

TLV de capacité d’information de routeur OSPF

Le TLV de capacité d’information de routeur PEUT être suivi de TLV facultatifs qui précisent une capacité.

2.4 Allocation des bits de capacité d’information de routeur OSPF

Les bits de capacité d’information suivants sont alloués :

Bits de capacité d’information de routeur OSPF

2.5 Portée de diffusion du LSA d’information de routeur

La portée de diffusion pour un LSA d’information de routeur est déterminée par le type de LSA. Pour OSPFv2, un LSA opaque de type 9 (portée de liaison), de type 10 (portée de zone), ou de type 11 (portée d’AS) peut être diffusé. Pour OSPFv3, les bits S1 et S2 bits du type de LSA déterminent la portée de la diffusion. Si la portée de diffusion sur l’ensemble de l’AS est choisie, le routeur générateur devrait aussi annoncer le ou les LSA à portée de zone dans toute zone rattachée « pas si en bout que cela » (NSSA, Not-So-Stubby Area). Un routeur OSPF PEUT annoncer des capacités différentes lorsque qu’il annonce à la fois un ou des LSA de zone NSSA et un LSA à portée d’AS. Cela permet de limiter la portée des capacités fonctionnelles. Par exemple, un routeur peut être un routeur de frontière de zone mais ne prendre en charge l’ingénierie du trafic (TE, traffic engineering) que dans un sous-ensemble de ses zones de rattachement.

Le choix de la portée de diffusion fait par le routeur annonceur est une affaire de politique locale. Le routeur générateur PEUT annoncer plusieurs LSA de RI pour autant que les portées de diffusion diffèrent. Les règles de portée de diffusion de TLV seront spécifiées TLV par TLV et DOIVENT être spécifiées dans les spécifications d’accompagnement pour les nouveaux TLV de LSA d’information de routeur.

3. Usage et applicabilité de LSA opaque d’information de routeur

L’objet du LSA d’information de routeur (RI) est d’annoncer les informations qui se rapportent au routeur OSPF en cause. Normalement, ceci pourrait se réduire à des TLV avec une seule valeur ou très peu de valeurs. Il n’est pas destiné à être un conteneur générique transportant n’importe quelles informations. L’intention est à la fois de limiter la taille du LSA de RI à un point tel qu’un routeur OSPF soit toujours capable de faite tenir les TLV dans un seul LSA tout gardant raisonnablement simple le rôle de détermination de ce qui change entre diverses instances de LSA. Et donc, il faudra appliquer discrétion et finesse du jugement sur l’ingénierie pour décider si une ou des nouvelles propositions de TLV pour la prise en charge de nouvelles applications sont annoncées dans le LSA de RI ou justifient la création d’un LSA spécifique de l’application.

4. Considérations pour la sécurité

Le présent document décrit à la fois un mécanisme générique pour annoncer les capacités d’un routeur et un TLV pour annoncer les bits de capacité d’information. Ce dernier TLV est moins critique que les informations de topologie actuellement annoncées par le protocole OSPF de base. Les considérations de sécurité pour le mécanisme générique dépendent de l’application future, et comme telles, devraient être décrites lorsque l’annonce de capacités additionnelles sera proposée. Les considérations sur la sécurité pour le protocole OSPF de base sont traitées dans [OSPF] et [OSPFV3].

5. Considérations relatives à l’IANA

L’allocation IANA suivante a été faite pour un registre existant :

Le LSA opaque OSPFv2 de type 4 a été réservé pour le LSA opaque de RI OSPFv2.

Les registres suivants ont été définis pour les besoins suivants :

1. Registre des codes de fonction de LSA pour OSPFv3 – Ce nouveau registre de niveau supérieur sera composé des champs Valeur, nom de code de fonction de LSA, et Référence de document. Le code de fonction de LSA d’OSPFv3 est défini au paragraphe A.4.2.1 de [OSPFV3]. Le code de fonction de LSA OSPFv3 de 12 a été réservé pour le LSA d’information de routeur (RI) OSPFv3.

Codes de fonction de LSA d’OSPFv3

* Les codes de fonction de LSA d’OSPFv3 dans la gamme de 256 à 8175 ne sont pas à allouer pour le moment. Avant qu’aucune allocation ne puisse être faite dans cette gamme, il DOIT y avoir une RFC en cours de normalisation qui spécifie les considérations relatives à l’IANA qui couvrent la gamme à allouer.

* Les codes de fonction de LSA d’OSPFv3 dans la gamme de 8176 à 8181 sont réservées à une utilisation expérimentale ; ils ne seront pas enregistrés auprès de l’IANA et NE DOIVENT PAS être mentionnés par les RFC.

* Les LSA OSPFv3 avec un code de fonction dans la gamme d’utilisation par des fabricants privés de 8184 à 8191 DOIVENT inclure le Code d’entreprise fabricante dans les quatre premiers octets suivant les 20 octets de l’en-tête de LSA.

* Si un nouveau code de fonction de LSA est documenté, la documentation DOIT inclure les combinaisons valides des bits U, S2, et S1 pour le LSA. Elle DEVRAIT aussi décrire comment l’identifiant d’état de liaison sera alloué.

2. Registre pour les TLV de RI d’OSPF – Ce registre de niveau supérieur sera composé des champs Valeur, Nom de TLV, et Référence de document. La valeur de 1 pour le TLV de capacités est défini ici.

TLV de RI OSPF

* Les types dans la gamme 32768 à 32777 sont pour des utilisations expérimentales ; ils ne seront pas enregistrés auprès de l’IANA et NE DOIVENT PAS être mentionnés par les RFC.

* Les types dans la gamme 32778 à 65535 sont réservés et ne sont pas à allouer pour le moment. Avant qu’aucune allocation ne puisse être faite dans cette gamme, il DOIT y avoir une RFC en cours de normalisation qui spécifie les considérations relatives à l’IANA qui couvrent la gamme à allouer.

3. Registre pour les bits de capacité d’information de routeur OSPF - Ce sous-registre du registre de TLV de RI d’OSPF sera composé des champs Numéro de bit, Nom de capacité et Référence de document. Les valeurs sont définies au paragraphe 2.4. Tous les ajouts de TLV de capacité d’information de routeur seront alloués par une action de normalisation.

6. Références

6.1 Références normatives

[OPAQUE] R. Coltun, "Option OSPF LSA opaque", RFC 2370, juillet 1998.

[OSPF] J. Moy, "OSPF version 2", STD 54, RFC 2328, avril 1998.

[OSPFV3] R. Coltun, D. Ferguson et J. Moy, "OSPF pour IPv6", RFC 2740, décembre 1999.

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

[TE] D. Katz, K. Kompella et D. Yeung, "Extensions d’ingénierie de trafic à OSPF", RFC 3630, septembre 2003.

6.2. Références informatives

[EXP-TE] P. Srisuresh et P. Joseph, "OSPF-xTE : Extension expérimentale à OSPF pour l’ingénierie du trafic", RFC 4973, juillet 2007.

[GRACE] J. Moy, P. Pillay-Esnault et A. Lindem, "Redémarrage OSPF sans heurt", RFC 3623, novembre 2003.

[P2PLAN] N. Shen et A. Zinin, "Fonctionnement en point à point sur un LAN dans les protocoles d’acheminement par état de liaison", Travail en cours, avril 2006.

[STUB] A. Retana, L. Nguyen, R. White, A. Zinin et D. McPherson, "Annonce de routeur de bout OSPF", RFC 3137, juin 2001.

Appendice A. Remerciements

L’idée de cet ouvrage est venue d’une conversation avec Andrew Partan et nous tenons à le remercier de sa contribution. Les auteurs souhaitent aussi remercier Peter Psenak de sa relecture et de ses précieux commentaires sur les premières versions du document.

Des commentaires de Abhay Roy, Vishwas Manral, Vivek Dubey, et Adrian Farrel ont été incorporés dans la dernière version.

Le texte de la RFC a été produit à l’aide de l’outil xml2rfc de Marshall Rose.

Adresse des auteurs

Scott Shaffer
BridgePort Networks
One Main Street, 7th Floor
Cambridge, MA 02142
USA
mèl : sshaffer@bridgeport-networks.com

Déclaration de copyright

Copyright (C) The IETF Trust (2007).

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