Signalisation des liaisons non numérotées dans le protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)

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 de prise en charge des liaisons non numérotées. Le présent document définit les procédures et extensions pour le protocole de distribution d’étiquettes fondée sur la contrainte (CR-LDP, Constraint-Routing Label Distribution Protocol) un des protocoles de signalisation de MPLS TE qui sont nécessaires afin de prendre en charge les liaisons non numérotées.

Spécification des exigences

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" 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é de porter des informations (TE) sur les liaisons non numérotées dans les extensions IGP TE (ISIS ou OSPF) et (b) la capacité de spécifier des liaisons non numérotées dans la signalisation MPLS TE. Le premier est traité dans les [RFC4203] et [RFC4205]. Le présent document se concentre sur le second.

La signalisation actuelle utilisée par MPLS TE ne fournit pas la prise en charge des liaisons non numérotées parce que elle ne fournit pas de moyen d’indiquer une liaison non numérotée dans ses objets Chemin explicite. Le présent document propose des procédures simples et des extensions qui permettent que la signalisation CR-LDP de la [RFC3212] soit utilisée avec des liaisons non numérotées.

2. Identifiants de liaisons

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 IS-IS comme IGP à l’appui de l’ingénierie du trafic, le IS-IS et/ou OSPF et le module CR-LDP sur un LSR doivent alors être d’accord sur les identifiants.

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

Les LSR aux deux points d’extrémité d’une liaison non numérotée s’échangent l’un l’autre les identifiants qu’ils allouent à la liaison. L’échange des identifiants peut se faire par configuration, au moyen d’un protocole tel que LMP ([RFC4204]), au moyen de 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 ou OSPF ([RFC4205], [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 "identifiant de liaison local" (ou juste "identifiant local") et à l’identifiant que B a alloué à la liaison comme "identifiant de liaison distant" (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 bouclage" ; l’attribut clé est que l’adresse ne devient pas inutilisable si une interface est morte sur le LSR. Dans certains cas, cette valeur devra être configurée. Si on utilise OSPF ou IS-IS comme IGP à l’appui de l’ingénierie du trafic, il est alors RECOMMANDÉ que l’identifiant de routeur soit réglé à "Adresse de routeur" comme défini dans la [RFC3630], ou "Identifiant de routeur d’ingénierie du trafic" comme défini dans la [RFC3784].

La présente section est également applicable au cas de liaison composante non numérotée (voir la [RFC4201]).

3. Adjacences de transmission non numérotées

Si un LSR qui génère un LSP annonce ce LSP comme adjacence de transmission non numérotée dans IS-IS ou OSPF (voir la [RFC4206]) ou si le LSR utilise l’adjacence de transmission formée par ce LSP comme liaison composante non numérotée d’un faisceau de liaisons (voir la [RFC4201]) le LSR DOIT allouer un identifiant à cette adjacence de transmission (comme pour toute autre liaison non numérotée). De plus, le message Demande utilisé pour établir le LSP qui forme l’adjacence de transmission DOIT contenir un TLV Identifiant d’interface de tunnel LSP (décrit plus loin) avec l’identifiant de routeur du LSR réglé à l’identifiant 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 Demande contient le TLV Identifiant d’interface de tunnel LSP, 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 Transposition pour le LSP DOIT contenir un TLV Identifiant d’interface de tunnel LSP, avec l’identifiant de routeur du LSR réglé à l’identifiant de routeur de l’extrémité de queue, et l’identifiant d’interface réglé à l’identifiant alloué par le LSR de l’extrémité de queue.

Pour les besoins du traitement du TLV Chemin explicite et du TLV Identifiant d’interface, 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 génère 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 du TLV Identifiant d’interface inverse (voir ci-dessous la définition de l’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 pour cette adjacence de transmission, et l’identifiant distant de liaison à la valeur portée dans le champ Identifiant d’interface du TLV Identifiant d’interface de transmission (voir ci-dessous la définition de Identifiant d’interface de transmission).

3.1 TLV Identifiant d’interface de tunnel LSP

Le TLV Identifiant d’interface de tunnel LSP a le type 0x0836 et la longueur 8. Son format est donné ci-dessous.

Figure 1 : TLV Identifiant d’interface de tunnel LSP

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

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

|0|0| Type | Longueur |

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

| Identifiant de routeur du LSR |

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

| Identifiant d’interface (32 bits) |

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

Ce TLV peut facultativement apparaître soit dans un message Demande, soit dans un message Transposition. 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 le TLV Chemin explicite

Un nouveau type de TLV Bond ER du TLV Chemin explicite est utilisé pour spécifier les liaisons non numérotées. Ce type est appelé Identifiant d’interface non numérotée, et a le format suivant :

Le type est 0x0837, et la longueur est 12. Le bit L est établi (à 1) pour indiquer un bond lâche, et est ôté (mis à 0) pour indiquer un bond strict.

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

Figure 2 : Identifiant 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

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

|0|0| Type | Longueur = 12 |

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

|L| Réservé |

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

| Identifiant de routeur |

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

| Identifiant d’interface (32 bits) |

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

4.1 Traitement du TLV IF_ID

Lorsque un LSR reçoit un message Demande qui contient le TLV IF_ID (Identifiant d’interface) (voir la [RFC3472]) 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 le doublet <Identifiant de routeur, identifiant local> correspondant au doublet <Adresse IP, Identifiant d’interface> porté dans le TLV IF_INDEX. Si le doublet correspondant est trouvé, la correspondance identifie la liaison pour laquelle le LSR a effectué une allocation d’étiquette.

Autrement, le LSR DEVRAIT retourner une erreur.

4.2 Traitement du TLV Bond ER d’identifiant d’interface non numérotée

Le bond de chemin explicite (ER) d’identifiant d’interface non numérotée est défini comme faisant partie d’un nœud abstrait particulier si ce nœud a son identifiant de routeur qui est égal au champ Identifiant de routeur dans le bond ER d’identifiant d’interface non numérotée, 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 bond ER d’identifiant d’interface non numérotée.

Visant cela, le traitement du TLV Chemin explicite en présence de bond ER d’identifiant d’interface non numérotée suit les règles spécifiées au paragraphe 4.8.1 de la [RFC3212].

Au titre du traitement du TLV Chemin explicite, ou pour être plus précis, au titre du choix du prochain bond, si la liaison sortante n’est pas numérotée, le message Demande que le nœud envoie au prochain bond DOIT comporter le TLV IF_ID avec le champ Adresse IP de ce TLV réglé à l’identifiant de routeur du nœud, et le champ Identifiant d’interface de ce TLV réglé à l’identifiant alloué à la liaison par le nœud.

5. Considérations relatives à l’IANA

La [RFC3036] définit l’espace de noms de TLV LDP. La [RFC3212] subdivise la gamme de cet espace de TLV pour les TLV associés au CR-LDP dans la gamme 0x0800 - 0x08FF, et définit les règles pour l’allocation des TLV au sein de cette gamme en utilisant la terminologie du BCP 26, RFC2434, "Lignes directrices pour la rédaction d’une section de considérations relatives à l’IANA dans les RFC". Ces règles s’appliquent à l’allocation des types de TLV pour les identifiants d’interface non numérotée et les TLV Identifiant d’interface de tunnel LSP définis dans le présent document.

6. Considérations pour la sécurité

Le présent document étend CR-LDP et ne soulève aucun nouveau problème de sécurité. CR-LDP hérite des mêmes mécanismes de sécurité que ceux décrits à la section 4 de la [RFC3076] pour protéger contre l’introduction de segments TCP falsifiés dans les flux de connexion de session LDP.

7. Remerciements

Merci à Rahul Aggarwal pour ses commentaires sur le texte. Merci aussi à Bora Akyol, Vach Kompella, et George Swallow.

8. Références

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

[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)

[RFC3212] B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (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) (P.S.)

[RFC3472] P. Ashwood-Smith et L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : extensions au protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)", janvier 2003. (MàJ par RFC3468, RFC4201) (P.S.)

8.2 Références pour information

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

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

[RFC4205] K. Kompella et Y. Rekhter, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (Obsolète, voir RFC5307) (MàJ RFC3784) (Information)

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

9. Adresse des auteurs

10. 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 soit inclus 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.