Traduction Claude Brière de L’Isle

Extensions du protocole d’acheminement IGP pour la découverte des capacités d’ingénierie du trafic d’un nœud

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Résumé

Il est très souhaitable dans certains cas, de tenir compte des capacités d’ingénierie du trafic (TE, Traffic Engineering) d’un nœud durant la sélection de chemin commuté à étiquette avec ingénierie de trafic en commutation d’étiquette multi protocole (MPLS) et MPLS généralisé (GMPLS), comme par exemple, la capacité à agir comme routeur de commutation d’étiquette (LSR, Label Switching Router) de branche d’un LSP point à multipoint (PàMP). Cela requiert de publier ces capacités au moyen du protocole de passerelle intérieure (IGP). À cette fin, le présent document spécifie les extensions d’ingénierie du trafic de plus court chemin ouvert en premier (OSPF, Open Shortest Path First) et de système intermédiaire à système intermédiaire (IS-IS, Intermediate System-Intermediate System) pour la publication des capacités d’ingénierie de trafic de plan de contrôle et de plan de données d’un nœud.

Table des matières

1 Introduction
2. Terminologie
3. Descripteur de capacité TE d’un nœud
3.1 Description
3.2 Informations requises
4 Formats de TLV de descripteur de capacité TE de nœud
4.1 Format de TLV de descripteur de capacité TE d’OSPF
4.2 Format de sous TLV de descripteur de capacité TE d’IS-IS de nœud
5 Éléments de procédure
5.1 OSPF
5.2 IS-IS
6 Rétro-compatibilité
7 Considérations pour la sécurité
8 Considérations relatives à l’IANA
8.1 TLV OSPF
8.2 Sous TLV IS-IS
8.3 Registre des capacités
9 Remerciements
10 Références
10.1 Références normatives
10.2 Références informatives

1 Introduction

L’acheminement en commutation multiprotocole avec étiquetage des flux et ingénierie du trafic (MPLS-TE, Multi Protocol Label Switching-Traffic Engineering ) ([RFC3784], [RFC3630], [OSPFv3-TE]) s’appuie sur des extensions aux protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) d’état de liaison ([IS-IS], [RFC1195], [RFC2328], [RFC2740]) afin de publier les informations d’ingénierie du trafic (TE, Traffic Engineering) de la liaison pour les acheminement à contrainte. D’autres extensions d’acheminement en rapport avec MPLS généralisé (GMPLS) sont définies dans les [RFC4205] et [RFC4203].

Il a été souhaité compléter ces extensions d’acheminement afin de publier les capacités TE du nœud, en plus des informations TE de liaison. Ces capacités TE du nœud seront prises en compte comme contrainte durant le choix de chemin.

Bien sûr, il est utile de publier les capacités TE de plan de données du nœud, telles que la capacité pour un routeur de commutation d’étiquettes (LSR, Label Switching Router) d’être un LSR de branche ou un LSR bourgeon d’un chemin commuté à étiquettes (LSP) en point à multipoint (PàMP). Ces capacités peuvent être prises en compte comme contraintes lors du calcul de l’acheminement des LSP de TE.

Il est aussi utile de publier les capacités d’ingénierie du trafic de plan de contrôle du nœud telles que la capacité à prendre en charge la signalisation GMPLS pour un LSR par paquet, ou la capacité à prendre en charge la signalisation LSP de TE en point à multipoint. Cela permet le choix d’un chemin qui évite les nœuds qui ne prennent pas en charge une caractéristique données de plan de contrôle, ou de déclancher un mécanisme pour prendre en charge de tels nœuds sur un chemin. Et donc, cela facilite la rétro-compatibilité.

À cette fin, le présent document spécifie les extensions IGP (OSPF et IS-IS) afin de publier les capacités de plan de données et de plan de contrôle d’un nœud.

Un nouveau TLV est défini pour OSPF, le TLV de descripteur de capacité TE de nœud, porté au sein de l’avis d’état de liaison (LSA, Link State Advertisement) d’informations sur les routeurs ([RFC4970]). Un nouveau sous-TLV est défini pour IS-IS, le sous TLV de descripteur de capacité TE de nœud, porté au sein du TLV de capacité IS-IS ([RFC4971]).

2. Terminologie

Le présent document utilise les terminologies définies dans les [RFC3031], [RFC3209], et [RFC4461].

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

3. Descripteur de capacité TE d’un nœud

3.1 Description

Les LSR dans un réseau peuvent avoir des capacités distinctes d’ingénierie du trafic de plan de contrôle et de plan des données. Les informations de descripteur de capacité TE de nœud définies dans le présent document décrivent les capacités de plan de données et de contrôle d’un LSR. De telles informations peuvent être utilisées durant le calcul du chemin de façon à éviter les nœuds qui ne prennent pas en charge une caractéristique donnée de TE dans le plan de contrôle ou le plan de données, ou pour déclancher des procédures pour traiter ces nœuds le long du chemin (par exemple, déclancher la prise en charge d’un LSR de transit ordinaire sur un LSP PàMP par la hiérarchie de LSP (voir la [RFC4875])).

3.2 Informations requises

Le descripteur de capacité TE de nœud contient un ensemble de longueur variable de bits fanions, où chaque bit correspond à une capacité TE de nœud donnée.

Cinq capacités TE de nœud sont définies dans le présent document :

- Bit B : lorsqu’il est mis (à 1), ce fanion indique que le LSR peut agir comme nœud de branche sur un LSP P2MP (voir la [RFC4461]) ;

- Bit E : lorsqu’il est mis, ce fanion indique que le LSR peut agir comme LSR bourgeon sur un LSP P2MP, c’est-à-dire, un LSR qui est à la fois de transit et de sortie (voir la [RFC4461]) ;

- Bit M : lorsqu’il est mis, ce fanion indique que le LSR prend en charge la signalisation MPLS-TE ([RFC3209]) ;

- Bit G : lorsqu’il est mis, ce fanion indique que le LSR prend en charge la signalisation GMPLS ([RFC3473]) ;

- Bit P : lorsqu’il est mis, ce fanion indique que le LSR prend en charge la signalisation PàMP MPLS-TE ([RFC4875]).

Noter que de nouveaux bits de capacité pourront être ajoutés en tant que de besoin à l’avenir.

4 Formats de TLV de descripteur de capacité TE de nœud

4.1 Format de TLV de descripteur de capacité TE d’OSPF

Le TLV de descripteur de capacité TE d’OSPF de nœud est un TLV de longueur variable qui contient une série de bits fanions, où chaque bit correspond à une capacité TE de nœud. Le champ binaire PEUT être étendu par des mots supplémentaires de 32 bits si il est nécessaire d’allouer plus de bits fanions. Tout bit fanion inconnu DEVRA être traité comme un bit réservé.

Le TLV de descripteur de capacité TE d’OSPF est porté au sein d’un LSA d’informations de routeur OSPF, qui est défini dans la [RFC4970].

Le format du TLV de descripteur de capacité de TE d’OSPF est le même que le format de TLV utilisé par les extensions d’ingénierie de trafic à OSPF [RFC3630]. C’est à dire que le TLV est composé de deux octets pour le type, de deux octets qui spécifient la longueur du champ de valeur, et d’un champ de valeur.

Le TLV de descripteur de capacité de TE d’OSPF a le format suivant :

TYPE : 5 (voir le paragraphe 8.1)
LONGUEUR : Variable (multiple de 4).
VALEUR : Collection d’unités de 32 fanions numérotés à partir du bit de plus fort poids comme bit zéro, où chaque bit représente une capacité TE de nœud.

Les bits suivants sont définis :

Les bits réservés DOIVENT être mis à zéro à la transmission, et DOIVENT être ignorés à réception. Si le champ de longueur est supérieur à 4, impliquant qu’il y a plus de 32 bits dans le champ de valeur, tous les bits supplémentaires (c’est à dire, non encore alloués) sont réservés.

4.2 Format de sous TLV de descripteur de capacité TE d’IS-IS de nœud

Le sous-TLV de descripteur de capacité TE de nœud en IS-IS est un sous-TLV de longueur variable qui contient une série de bits fanions, dont chaque bit correspond à une capacité TE de nœud. Le champ des bits PEUT être étendu par des octets supplémentaires si il faut allouer plus de bits fanions. Tout bit fanion inconnu DEVRA être traité comme bit réservé.

Le sous-TLV de descripteur de capacité TE de nœud en IS-IS est porté au sein d’un TLV IS-IS CAPABILITY TLV, qui est défini dans la [RFC4971].

Le format du sous-TLV de descripteur de capacité TE de nœud en IS-IS est le même que le format de sous-TLV utilisé par les extensions d’ingénierie de trafic en IS-IS [RFC3784]. C’est-à-dire que le sous-TLV est composé de un octet pour le type, un octet spécifiant la longueur du champ de valeur.

Le sous-TLV de descripteur de capacité TE de nœud en IS-IS a le format suivant :

TYPE : 1 (voir au paragraphe 8.2)
LONGUEUR : Variable
VALEUR : Collection d’unités de 8 fanions numérotés à partir du bit de plus fort poids comme bit zéro, où chaque bit représente une capacité TE de nœud.

Les bits suivants sont définis :

Les bits réservés DOIVENT être mis à zéro à la transmission, et DOIVENT être ignorés à réception. Si le champ de longueur est supérieur à 1, impliquant qu’il y a plus de 8 bits dans le champ de valeur, tous les bits supplémentaires (c’est à dire, non encore alloués) sont réservés.

5 Éléments de procédure

5.1 OSPF

Le TLV de descripteur de capacité TE de nœud est publié au sein d’un LSA d’information de routeur OSPFv2 (type opaque de 4 et identifiant opaque de 0) ou d’un LSA d’information de routeur OSPFv3 (code de fonction de 12), qui sont définis dans la [RFC4970]. Comme tels, les éléments de procédure sont hérité de ceux définis dans les [RFC2328], [RFC2740], et [RFC4970].

Le TLV de descripteur de capacité TE de nœud publie les capacités qui peuvent être prises en compte comme contraintes durant le choix du chemin. Et donc son domaine d’application est la zone locale, et il DOIT être porté au sein d’un LSA d’information de routeur OSPFv2 de type 10 (comme défini dans la [RFC2370]) ou un LSA d’information de routeur OSPFv3 avec le bit S1 mis (à 1) et le bit S2 ôté (à 0) (comme défini dans la [RFC2740]).

Un routeur DOIT générer un nouvel LSA d’information de routeur OSPF chaque fois que change le contenu du TLV de descripteur de capacité TE de nœud, ou chaque fois qu’exigé par la procédure OSPF normale (rafraîchissement de LSA (tous les LSRefreshTime)).

Le TLV de descripteur de capacité TE de nœud est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans un LSA d’information de routeur OSPF. Si un TLV de descripteur de capacité TE de nœud apparaît plus d’une fois dans un LSA d’information de routeur OSPF, seule la première occurrence DOIT être traitée et les autres DOIVENT être ignorées.

Lorsque un LSA d’information de routeur OSPF ne contient aucun TLV de descripteur de capacité TE de nœud, cela signifie que les capacités TE de nœud de ce LSR sont inconnues.

Noter qu’un changement d’une quelconque de ces capacités PEUT déclancher le calcul du chemin le plus court en premier obligé (CSPF), mais NE DOIT PAS déclancher le calcul normal du SPF.

Noter aussi que les capacités TE de nœud sont supposées être assez statiques. Elles peuvent changer par suite d’un changement de configuration ou de mise à jour de logiciel. On suppose que cela ne devrait pas se produire plus d’une fois par jour.

5.2 IS-IS

Le sous-TLV de capacité TE de nœud est porté au sein d’un TLV IS-IS CAPABILITY défini dans la [RFC4971]. Comme tels, les éléments de procédure sont hérités de ceux définis dans la [RFC4971].

Le sous-TLV de descripteur de capacité TE de nœud publie les capacités qui peuvent être prises en compte comme contraintes durant le choix du chemin. Et donc, son domaine de couverture est la zone locale, et il DOIT être porté au sein d’un TLV IS-IS CAPABILITY dont le fanion S est ôté (à 0).

Un routeur IS-IS DOIT générer un nouveau LSP IS-IS chaque fois que le contenu de tout sous-TLV de capacité TE de nœud change ou chaque fois que c’est exigé par la procédure IS-IS normale (rafraîchissement de LSP).

Le sous-TLV de descripteur de capacité TE de nœud est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans un TLV de capacité de routeur IS-IS.

Lorsque un LSP IS-IS ne contient aucun sous-TLV de descripteur de capacité TE de nœud, cela signifie que les capacités TE de nœud de ce LSR sont inconnues.

Noter qu’un changement d’une quelconque de ces capacités PEUT déclancher le calcul de CSPF, mais NE DOIT PAS déclancher le calcul SPF normal.

Noter aussi que les capacités TE de nœud sont supposées être assez statiques. Elles peuvent changer par suite d’un changement de configuration ou de mise à jour de logiciel. On suppose que cela ne devrait pas se produire plus d’une fois par jour.

6 Rétro-compatibilité

Les TLV de descripteur de capacité TE de nœud définies dans le présent document n’introduisent aucun problème d’interopérabilité. Pour OSPF, un routeur qui ne prend pas en charge le TLV de descripteur de capacité TE de nœud va seulement ignorer en silence le TLV, comme spécifié dans la [RFC4970]. Pour IS-IS, un routeur qui ne prend pas en charge le sous-TLV de descripteur de capacité TE de nœud va simplement ignorer en silence le sous-TLV, comme spécifié dans la [RFC4971].

Lorsque le TLV de descripteur de capacité TE de nœud est absent, cela signifie que les capacités TE de ce LSR sont inconnues.

L’absence d’un mot de fanion de capacités dans OSPF ou d’un octet de fanion de capacités dans IS-IS signifie que ces capacités sont inconnues.

7 Considérations pour la sécurité

Le présent document spécifie le contenu du TLV de descripteur de capacité TE de nœud dans IS-IS et OSPF à utiliser pour le calcul du chemin (G)MPLS-TE. Comme ce TLV n’est pas utilisé pour le calcul SPF ou pour l’acheminement normal, les extensions spécifiées ici n’ont pas d’effet direct sur l’acheminement IP. L’altération de ce TLV peut avoir un effet sur le calcul de l’ingénierie de trafic. Les mécanismes définis pour sécuriser les PDU d’état de liaison IS-IS [RFC3567], les LSA OSPF [RFC2154], et leurs TLV peuvent être utilisés pour sécuriser aussi ce TLV.

8 Considérations relatives à l’IANA

8.1 TLV OSPF

La [RFC4970] définit un nouveau registre des codets pour les TLV portés dans le LSA d’information de routeur défini dans la [RFC4970].

L’IANA a fait une nouvelle allocation de codet dans ce registre pour le TLV de descripteur de capacité TE de nœud défini dans le présent document et porté au sein du LSA d’information de routeur. Sa valeur est de 5. Voir le paragraphe 4.1 du présent document.

8.2 Sous TLV IS-IS

L’IANA a défini un registre pour les sous-TLV de TLV IS-IS CAPABILITY définis dans la [RFC4971].

L’IANA a fait une nouvelle allocation de codet dans ce registre pour le sous-TLV de descripteur de capacité TE de nœud défini dans le présent document et porté au sein du TLV IS-IS CAPABILITY. Sa valeur est de 1. Voir le paragraphe 4.2 du présent document.

8.3 Registre des capacités

L’IANA a créé un nouveau registre pour gérer l’espace de bits fanions de capacité portés au sein du descripteur de capacité TE OSPF et ISIS de nœud.

Un seul registre doit être défini pour les deux protocoles. Un nouveau registre de base a été créé pour couvrir les registres IGP-TE qui s’appliquent à la fois à OSPF et IS-IS, et le nouveau registre exigé par le présent document est un sous-registre de ce nouveau registre de base.

Dans ce nouveau registre, les bits devraient être numérotés selon la notation IETF usuelle, commençant par le bit de plus fort poids à zéro.

Les nouveaux numéros de bit ne peuvent être alloués que par une action de consensus IETF.

Chaque bit devrait être retracé avec les qualités suivantes :

- Numéro de bit
- RFC de définition
- Nom du bit

L’IANA a fait les allocations des cinq capacités TE de nœud définies dans le présent document (voir les paragraphes 8.1 et 8.2) en utilisant les valeurs suivantes :

9 Remerciements

Nous tenons à remercier Benoit Fondeviole, Adrian Farrel, Dimitri Papadimitriou, Acee Lindem, et David Ward pour leur utiles commentaires et suggestions.

Nous remercions aussi les auteurs des [RFC4420] et [RFC4970] dont s’inspire une partie du texte du présent document.

Adrian Farrel a préparé la version finale du présent document pour sa soumission à l’IESG.

10 Références

10.1 Références normatives

[RFC1195] R. Callon, "Utilisation de IS-IS OSI pour l’acheminement dans les environnements TCP/IP et duels", RFC 1195, décembre 1990.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les exigences de niveau", BCP 14, RFC 2119, mars 1997.

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

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

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

[RFC3031] E. Rosen, A. Viswanathan et R. Callon, "Architecture de commutation multiprotocole avec étiquetage des flux ", RFC 3031, janvier 2001.

[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan et G. Swallow, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", RFC 3209, décembre 2001.

[RFC3473] L. Berger, éd., "Extensions de commutation multiprotocole avec étiquetage des flux généralisée (GMPLS) au protocole de réservation de ressources avec extensions d’ingénierie de trafic (RSVP-TE)", RFC 3473, janvier 2003.

[RFC3630] D. Katz, K. Kompella et D. Yeung, "Extensions d’ingénierie du trafic (TE) à OSPF version 2", RFC 3630, septembre 2003.

[RFC3784] H. Smit et T. Li, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l’ingénierie du trafic (TE)", RFC 3784, juin 2004.

[IS-IS] "Protocole d’échange d’informations d’acheminement intra-domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole pour la fourniture du service réseau en mode sans connexion (ISO 8473)", ISO 10589.

[RFC4971] JP. Vasseur, éd., N. Shen, éd., et R. Aggarwal, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour les Informations de publication de routeur", RFC 4971, juillet 2007.

[RFC4970] A. Lindem, éd., N. Shen, J-P. Vasseur, R. Aggarwal et S. Shaffer, "Extensions à OSPF pour la publication des capac ités de routeur de remplacement", RFC 4970, juillet 2007.

[RFC4875] R. Aggarwal, éd., D. Papadimitriou, éd., et S. Yasukawa, éd., "Extensions au protocole de réservation de ressources – ingénierie du trafic (RSVP-TE) pour les chemins commutés à étiquettes en point à multipoint à ingénierie de trafic)", RFC 4875, mai 2007.

10.2 Références informatives

[RFC2154] S. Murphy, M. Badger et B. Wellington, "OSPF avec signatures numériques", RFC 2154, juin 1997.

[RFC3567] T. Li et R. Atkinson, "Authentification cryptographique de système intermédiaire à système intermédiaire (IS-IS)", RFC 3567, juillet 2003.

[RFC4203] K. Kompella, éd., et Y. Rekhter, éd., "Extensions OSPF pour la prise en charge de la commutation multiprotocole avec étiquetage des flux généralisée (GMPLS)", RFC 4203, octobre 2005.

[RFC4205] K. Kompella, éd., et Y. Rekhter, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation multiprotocole avec étiquetage des flux généralisée (GMPLS)", RFC 4205, octobre 2005.

[RFC4420] A. Farrel, éd., D. Papadimitriou, J-P. Vasseur et A. Ayyangar, "Codage des attributs pour l’établissement de chemin commuté à étiquette (LSP) de commutation d’étiquettes entre protocoles multiples (MPLS) utilisant le protocole de réservation de ressource/ingénierie du trafic (RSVP-TE)", RFC 4420, février 2006.

[RFC4461] S. Yasukawa, éd., "Exigences de signalisation pour les chemins commutés à étiquettes (LSP) de MPLS en point à multipoint à ingénierie de trafic", RFC 4461, avril 2006.

[OSPFv3-TE] K. Ishiguro, V. Manral, A. Davey et A. Lindem, "Extensions d’ingénierie du trafic à OSPF version 3", Travail en cours.

Adresse des contributeurs

Paul Mabbey
Comcast
USA

Adresse des éditeurs

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.