Signalisation des liaisons non numérotées dans le protocole de réservation de ressource – 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.

Notice de Copyright

Copyright (C) The Internet Society (2003). Tous droits réservés.

Résumé

La signalisation actuelle utilisée par l’ingénierie du trafic de commutation d’étiquettes multi protocoles (MPLS-TE, Multi-Protocol Label Switching Traffic Engineering) ne fournit pas la prise en charge des liaisons non numérotées. Le présent document définit les procédures et extensions au protocole de réservation de ressources (RSVP, Resource ReSerVation Protocol) pour les tunnels de chemin d’étiquette commutée (LSP, Label Switched Path) de RSVP-TE, un des protocoles de signalisation de MPLS-TE, qui sont nécessaires à la prise en charge des liaisons non numérisées.

Spécification des exigences

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

1. Généralités

La prise en charge de MPLS-TE sur des liaisons non numérotées (c’est-à-dire, des liaisons qui n’ont pas d’adresse IP) implique deux composants : (a) la capacité à porter (TE) des informations sur les liaisons non numérotées dans les extensions IGP TE (ISIS ou OSPF) et (b) la capacité de spécifier les liaisons non numérotées dans la signalisation MPLS-TE. La première est couverte par les [RFC4202] et [RFC4203]. Le présent document se concentre sur la dernière.

La signalisation actuelle utilisée par MPLS-TE ne fournit pas la prise en charge des liaisons non numérotés parce qu’elle ne fournit pas de moyen d’indiquer une liaison non numérotée dans ses objets EXPLICIT_ROUTE et RECORD_ROUTE. Le présent document propose des procédures simples et des extensions qui permettent à la signalisation RSVP-TE [RFC3473] d’être utilisée avec des liaisons non numérotées.

2. Identifiants de liaison

Une liaison non numérotée doit être une liaison point à point. Un LSR à chaque extrémité d’une liaison non numérotée alloue un identifiant à cette liaison. Cet identifiant est un nombre de 32 bits différent de zéro qui est unique au sein de la portée du LSR qui l’alloue. Si on utilise OSPF ou ISIS comme IGP pour la prise en charge de l’ingénierie du trafic, alors les modules IS-IS et/ou OSPF et RSVP sur un LSR doivent se mettre d’accord sur les identifiants.

Il n’y a pas de relation a priori entre les identifiants alloués à une liaison par les LSR de chaque extrémité de cette liaison.

Les LSR aux deux points d’extrémité d’une liaison non numérotée échangent entre eux les identifiants qu’ils allouent à la liaison. L’échange des identifiants peut être réalisé par configuration, au moyen d’un protocole tel que LMP [RFC4204], au moyen de RSVP/CR-LDP (en particulier dans le cas où une liaison est une adjacence de transmission, voir ci-dessous) ou au moyen des extensions IS-IS [RFC4202] ou OSPF [RFC4203].

Considérons une liaison (non numérotée) entre les LSR A et B. Le LSR A choisit un identifiant pour cette liaison. Le LSR B en fait autant. Du point de vue de A, on se réfère à l’identifiant que A a alloué à la liaison comme étant "l’identifiant local de liaison" (ou juste "identifiant local") et à l’identifiant que B a alloué à la liaison comme étant "l’identifiant distant de liaison" (ou juste "identifiant distant"). De même, du point de vue de B, l’identifiant que B a alloué à la liaison est l’identifiant local, et l’identifiant que A a alloué à la liaison est l’identifiant distant.

Dans le contexte du présent document, le terme "identifiant de routeur" signifie une adresse IP stable d’un LSR qui est toujours accessible si il y a la connexité avec le LSR. Cela est normalement mis en œuvre comme une "adresse de retour de boucle" ; l’attribut clé est que l’adresse ne devienne pas inutilisable si une interface est morte sur le LSR. Dans certains cas, cette valeur devra être configurée. Si on utilise l’OSPF ou l’IS-IS comme IGP pour la prise en charge de l’ingénierie du trafic, il est alors RECOMMANDÉ que l’identifiant de routeur soit réglé à "l’adresse de routeur" comme défini dans la [RFC3630], ou à "l’identifiant de routeur d’ingénierie du trafic" comme défini dans la [RFC3784].

Cette section est également applicable au cas de liaisons composantes non numérotées (voir la [RFC4201]).

3. Adjacences de transmission non numérotées

Si un LSR qui est à l’origine d’un LSP annonce ce LSP comme adjacence de transmission non numérotée en IS-IS ou en OSPF (voir la [RFC4206]) ou si le LSR utilise l’adjacence de transmission formée par ce LSP comme une liaison composante non numérotée d’un faisceau de liaisons (voir la [RFC4201]) le LSR DOIT allouer un identifiant à cette adjacence de transmission (tout comme pour toute autre liaison non numérotée). De plus, le message Path utilisé pour établir le LSP qui forme l’adjacence de transmission DOIT contenir l’objet LSP_TUNNEL_INTERFACE_ID (décrit ci-dessous) avec l’identifiant de routeur du LSR réglé à l’ID de routeur de l’extrémité de tête, et l’identifiant d’interface réglé à l’identifiant que le LSR a alloué à l’adjacence de transmission.

Si le message Path contient l’objet LSP_TUNNEL_INTERFACE_ID, alors le LSR de l’extrémité de queue DOIT allouer un identifiant à cette adjacence de transmission (tout comme pour toute autre liaison non numérotée). De plus, le message Resv pour le LSP DOIT contenir un objet LSP_TUNNEL_INTERFACE_ID, avec l’identifiant de routeur du LSR réglé à l’ID de routeur de l’extrémité de queue, et l’identifiant d’interface réglé à l’identifiant alloué par le LSR d’extrémité de queue.

Pour les besoins du traitement des objets ERO et IF_ID RSVP_HOP, une adjacence de transmission non numérotée est traitée comme une liaison non numérotée (TE) ou une liaison composante non numérotée comme suit. Le LSR qui est à l’origine de l’adjacence règle l’identifiant local de la liaison pour cette liaison à la valeur que le LSR alloue à cette adjacence de transmission, et l’identifiant distant de liaison à la valeur portée dans le champ Identifiant d’interface de l’objet Identifiant d’interface inverse. Le LSR qui est l’extrémité de queue de cette adjacence de transmission règle l’identifiant local de liaison pour cette liaison à la valeur que le LSR alloue à cette adjacence de transmission, et l’identifiant distant de liaison à la valeur portée dans le champ Identifiant d’interface de l’objet Identifiant d’interface de transmission.

3.1 Objet LSP_TUNNEL_INTERFACE_ID

L’objet LSP_TUNNEL_INTERFACE_ID a 193 comme numéro de classe, 1 comme C-Type et une longueur de 12. Le format est donné ci-dessous.

Figure 1 : Objet LSP_TUNNEL_INTERFACE_ID

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 routeur du LSR |

+---------------+---------------+---------------+---------------+

| Identifiant d’interface (32 bits) |

+---------------+---------------+---------------+---------------+

Cet objet peut facultativement apparaître dans un message Path ou dans un message Resv. Dans le premier cas, on l’appelle "Identifiant d’interface de transmission" pour ce LSP ; dans le second cas, on l’appelle "Identifiant d’interface inverse" pour le LSP.

4. Signalisation des liaisons non numérotées dans les ERO

Un nouveau sous objet de l’objet EXPLICIT_ROUTE (ERO) est utilisé pour spécifier les liaisons non numérotées. Ce sous objet a le format suivant :

Figure 2 : Sous objet ID 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é (DOIT être zéro) |

+-+-------------+---------------+---------------+---------------+

| Identifiant de routeur |

+---------------+---------------+---------------+---------------+

| Identifiant d’interface (32 bits) |

+---------------+---------------+---------------+---------------+

Le type est 4 (ID d’interface non numérotée). La longueur est 12.

L’identifiant d’interface est l’identifiant alloué à la liaison par le LSR spécifié par l’identifiant de routeur.

4.1 Traitement de l’objet IF_ID RSVP_HOP

Lorsque un LSR reçoit un message Path qui contient l’objet IF_ID RSVP_HOP (voir les [RFC3471] et [RFC3473]) avec le TLV IF_INDEX, le LSR traite ce TLV comme suit. Le LSR doit avoir des informations sur les identifiants alloués par ses voisins aux liaisons non numérotées entre les voisins et le LSR. Le LSR utilise ces informations pour trouver une liaison avec un tuplet <ID de routeur, identifiant local> correspondant au tuplet <Adresse IP, ID d’interface> porté dans le TLV IF_INDEX. Si il trouve le tuplet correspondant, la correspondance identifie la liaison pour laquelle le LSR doit effectuer l’allocation d’étiquette.

Autrement, le LSR DEVRAIT retourner une erreur en utilisant l’objet IF_ID ERROR_SPEC (voir les [RFC3473] et [RFC3471]). Le code d’erreur dans l’objet est réglé à 24. La valeur d’erreur dans l’objet est réglée à 16.

4.2 Traitement de ERO

Le sous objet Identifiant d’interface non numérotée est défini comme faisant partie d’un nœud abstrait particulier si ce nœud a l’identifiant de routeur qui est égal au champ Identifiant de routeur dans le sous objet, et si le nœud a une liaison (non numérotée) ou une adjacence de transmission (non numérotée) dont l’identifiant local (du point de vue de ce nœud) est égal à la valeur portée dans le champ Identifiant d’interface du sous objet.

Cela étant dit, le traitement de ERO en présence du sous objet Identifiant d’interface non numérotée suit les règles spécifiées au paragraphe 4.3.4.1 de la [RFC3209].

Au titre du traitement de l’ERO, ou pour être plus précis, au titre du choix du prochain bond, si la liaison sortante est non numérotée, le message Path que le nœud envoie au prochain bond DOIT inclure l’objet IF_ID RSVP_HOP, avec le champ Adresse IP de cet objet réglé à l’identifiant de routeur du nœud, et le champ Identifiant d’interface de cet objet réglé à l’identifiant alloué à la liaison par le nœud.

5. Objet RECORD_ROUTE

Un nouveau sous objet de l’objet RECORD_ROUTE (RRO) est utilisé pour enregistrer que le LSP a traversé une liaison non numérotée. Ce sous objet a le format suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Longueur | Fanions | Réservé (MBZ) |

+---------------+---------------+---------------+---------------+

| Identifiant de routeur |

+---------------+---------------+---------------+---------------+

| Identifiant d’interface ID (32 bits) |

+---------------+---------------+---------------+---------------+

Le type est 4 (Identifiant d’interface non numérotée) ; la longueur est 12. Les fanions sont définis ci-dessous.

0x01 : protection locale disponible

Indique que la liaison vers l’aval de ce nœud est protégée via un mécanisme local de réparation. Ce fanion ne peut être établi que si le fanion Protection locale était établi dans l’objet SESSION_ATTRIBUTE du message Path correspondant.

0x02 : protection locale utilisée

Indique qu’un mécanisme local de réparation est utilisé pour entretenir ce tunnel (normalement en présence d’une panne de la liaison sur laquelle il était précédemment acheminé).

5.1 Traitement de RRO

Si à un nœud intermédiaire (ou à l’extrémité de tête) le sous objet ERO qui a été utilisé pour déterminer le prochain bond est du type Identifiant d’interface non numérotée, et si un objet RRO a été reçu dans le message Path (ou si il était désiré dans le message Path original) un sous objet RRO de type Identifiant d’interface non numérotée DOIT être ajouté au RRO reçu lors de l’envoi d’un message Path vers l’aval.

Si le sous objet ERO qui a été utilisé pour déterminer le prochain bond est d’un autre type, les procédures de traitement de la [RFC3209] s’appliquent. De même, si l’enregistrement d’étiquette est désiré, les procédures de la [RFC3209] s’appliquent.

6. Considérations pour la sécurité

Les présent document fait une petite extension à la [RFC3209] pour préciser et expliquer l’utilisation des liaisons non numérotées. À ce titre, il ne pose pas de nouveau problème de sécurité. En fait, on peut avancer que l’utilisation de l’identité d’interface supplémentaire pourrait rendre plus difficile la falsification d’un message RSVP.

7. Considérations relatives à l’IANA

L’IANA alloue les valeurs des paramètres du protocole RSVP. Le présent document définit un nouveau sous objet pour l’objet EXPLICIT_ROUTE et pour l’objet ROUTE_RECORD. Les règles pour l’allocation des numéros de sous objet ont été définies dans la [RFC3209], en utilisant la terminologie du BCP 26, RFC2434, "Lignes directrices pour la rédaction d’une section Considérations relatives à l’IANA dans les RFC". Ces règles s’appliquent à l’allocation des numéros de sous objet pour le nouveau sous objet de l’objet EXPLICIT_ROUTE et de l’objet ROUTE_RECORD.

De plus, la même autorité Internet devra allouer un numéro de classe à l’objet LSP_TUNNEL_INTERFACE_ID. Cela devra être fait sous la forme 11bbbbbb (c’est-à-dire, RSVP ignore en silence cet objet inconnu mais le transmet).

8. Considérations de 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 faits 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.

9. Remerciements

Merci à Lou Berger et à Markus Jork pour avoir fait remarquer que le RRO devrait être étendu de la même façon que le ERO. Merci aussi à Rahul Aggarwal et à Alan Kullberg pour leurs commentaires sur le texte. Et enfin, merci à Bora Akyol, Vach Kompella, et George Swallow.

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.

[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan et G. Swallow, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (MàJ par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420,RFC5711)

[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, 6002, 6003, 6205) (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)

10.2 Références non normatives

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

[RFC4201] K. Kompella et autres, "Faisceaux de liaisons dans l'ingénierie du trafic MPLS", octobre 2005. (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.)

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

[RFC4204] J. Lang, éd., "Protocole de gestion de liaison (LMP)", octobre 2005. (P.S.)

[RFC4206] K. Kompella, Y. Rekhter, "Hiérarchie de chemins commutés par étiquettes (LSP) avec l'ingénierie de trafic (TE) de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (P.S.)

11. Adresse des auteurs

12. Déclaration de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soieninclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l’Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

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