Extensions IS-IS 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 (2008).

Résumé

Le présent document spécifie le codage des extensions au protocole d'acheminement IS-IS pour la prise en charge de la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching).

1. Introduction

Le présent document spécifie des extensions au protocole d'acheminement IS-IS pour la prise en charge du transport des informations d'état de liaison pour la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). L'ensemble des améliorations requises pour IS-IS est mentionné dans la [RFC4202]. La prise en charge des interfaces non numérotées suppose la prise en charge du type d'option IS-IS "Adjacence point à point en trois étapes" [RFC5303].

Dans cette section, on définit les améliorations aux propriétés d'ingénierie de trafic (TE, Traffic Engineering) des liaisons GMPLS TE qui peuvent être annoncées dans les unités de données du protocole d'état de liaison IS-IS.

Dans le présent document, on améliore les sous TLV pour le TLV Accessibilité IS étendue (voir la [RFC5305]) à l'appui de GMPLS. Précisément, on ajoute les sous TLV suivants :

On ajoute de plus un nouveau TLV aux TLV TE :

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

Un identifiant d'interface de liaison locale est un sous TLV du TLV Accessibilité IS étendue. Le type de ce sous TLV est 4, et sa longueur est de 8 octets. Le champ Valeur de ce sous TLV contient 4 octets d'identifiant de liaison locale suivis par 4 octets d'identifiant de liaison distante (voir au paragraphe 2.1, "Prise en charge des liaisons non numérotés", de la [RFC4202]). Si l'identifiant de la liaison distante est inconnu, il est réglé à 0.

Voici le codage du champ Valeur des sous TLV d'identifiant de liaison locale/distante.

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 |

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

Les sous TLV d'identifiant de liaison locale/distante NE DOIVENT PAS se produire plus d'une fois au sein du TLV Accessibilité IS étendue. Si le sous TLV Identifiant de liaison locale/distante se produit plus d'une fois dans le TLV Accessibilité IS étendue, le receveur DEVRAIT ignorer tous ces sous TLV.

1.2 Type de protection de liaison

Le type de protection de liaison est un sous TLV (de type 20) du TLV Accessibilité IS étendue, d'une longueur de 2 octets.

Voici une illustration du codage du champ Valeur du sous TLV Type de protection de liaison.

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

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

|Cap Protection | Réservé |

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

Le premier octet est un vecteur binaire qui décrit les capacités de protection de la liaison (voir au paragraphe 2.2, "Type de protection de liaison", de la [RFC4202]). Ce sont :

0x01 : extra trafic

0x02 : non protégée

0x04 : partagée

0x08 : dédiée 1:1

0x10 : dédiée 1+1

0x20 : améliorée

0x40 : réservé

0x80 : réservé

Le second octet DEVRAIT être réglé à zéro par l'envoyeur, et DEVRAIT être ignoré par le receveur.

Le sous TLV Type de protection de liaison NE DOIT PAS se produire plus d'une fois au sein du TLV Accessibilité IS étendue. Si le sous TLV Type de protection de liaison se produit plus d'une fois dans le TLV Accessibilité IS étendue, le receveur DEVRAIT ignorer tous ces sous TLV.

1.3 Descripteur de capacités de commutation d'interface

Le descripteur de capacités de commutation d'interface est un sous TLV (de type 21) du TLV Accessibilité IS étendue. Sa longueur est la longueur du champ Valeur en octets. Voici illustré le codage du champ Valeur du sous TLV Descripteur de capacités de commutation d'interface.

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 :

Le champ Codage contient une des valeurs spécifiées au paragraphe 3.1.1 de la [RFC3471].

La bande passante maximum d'unité de données de protocole d'état de liaison (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 et la MTU d'interface.

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 |

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

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, et porte la valeur de MTU en unités d'octets.

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 et l'indication que l'interface prend en charge le SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) standard ou arbitraire.

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 |

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

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.

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 Accessibilité IS étendue.

1.4 TLV Groupe de liaison à risques partagés

Le TLV Groupe de liaison à risques partagés (SRLG, Shared Risk Link Group) (de type 138) contient une structure de données qui consiste en :

6 octets d'identifiant de système,

1 octet de numéro de pseudo nœud,

1 octet de fanion

4 octets d'adresse IPv4 d'interface ou 4 octets d'un identifiant de liaison locale,

4 octets d'adresse IPv4 de voisin ou 4 octets d'un identifiant de liaison distante

une liste (variable) de valeurs de SRLG, où chaque élément de la liste a 4 octets.

Voici illustré le codage du champ Valeur du TLV SRLG :

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 système (début) |

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

| Identifiant de système (fin) |Num pseudo nœud| Fanions |

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

| Adresse d'interface IPv4/Identifiant de liaison locale |

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

| Adresse IPv4 de voisin/Identifiant de liaison distante |

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

| Valeur de groupe de liaison à risques partagés |

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

| ............ |

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

| Valeur de groupe de liaison à risques partagés |

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

Le voisin est identifié par son identifiant de système (6 octets), plus un octet pour indiquer le numéro de pseudo nœud si le voisin est sur une interface de LAN.

Le bit de moindre poids de l'octet Fanions indique si l'interface est numérotée (réglé à 1) ou non numérotée (réglé à 0). Tous les autres bits sont réservés et devraient être mis à 0.

La longueur de ce TLV est 16 + 4 * (nombre de valeurs de SRLG).

Ce TLV porte les informations de groupe de liaison à risques partagés (voir au paragraphe 2.3, "Informations de groupe de liaison à risques partagés", de la [RFC4202]).

Le TLV SRLG PEUT se produire plus d'une fois au sein de l'unité de données de protocole d'état de liaison IS-IS.

1.5 Identifiant de liaison pour interfaces non numérotées

Les identifiants de liaison sont échangés dans le champ Identifiant de circuit local étendu du type d'option IS-IS "Adjacence point à point en trois phases" [RFC5303].

2. Implications sur le redémarrage en douceur

Le nœud qui redémarre DEVRAIT suivre les procédures de redémarrage IS-IS [RFC5306], et les procédures de redémarrage RSVP-TE [RFC3473].

Lorsque le nœud qui redémarre va générer ses unités de données de protocole d'état de liaison IS-IS pour les liaisons TE, ces unités de données de protocole d'état de liaison DEVRAIENT être générées avec une bande passante non réservée de 0, la métrique d'ingénierie du trafic par défaut réglée à 0xffffffff. De plus, si la liaison a LSC ou FSC comme capacité de commutation, elle DEVRAIT alors aussi être générée 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 unités de données de protocole d'état de liaison.

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 unités de données de protocole d'état de liaison IS-IS pour les liaisons TE avec 0 comme bande passante non réservée. Aussi, si la liaison a LSC ou FSC comme capacité de commutation, elles DEVRAIENT alors aussi être générées 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.

3. Considérations sur la sécurité

Le présent document spécifie le contenu des TLV GMPLS TE dans IS-IS. Comme ces TLV ne sont pas utilisés pour le calcul du 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 TLV GMPLS TE peut avoir un effet sur le réseau de transport sous-jacent (optique et/ou SONET/SDH). Les mécanismes pour sécuriser les PDU d'état de liaison IS-IS et/ou les TLV TE [RFC5304] peuvent être utilisés pour sécuriser aussi les TLV GMPLS TE.

Pour une discussion des considérations générales sur la sécurité pour IS-IS, voir la [RFC5304].

4. Considérations relatives à l'IANA

Le présent document définit le nouveau type de TLV IS-IS suivant qui est reflété dans le registre des codets de TLV IS-IS :

Le présent document définit aussi les nouveaux types de sous TLV du TLV de niveau supérieur 22 qui ont été reflétés dans le registre de sous TLV IS-IS pour le TLV 22:

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

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

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

[RFC5303] D. Katz et autres, "Prise de contact à trois étapes pour adjacences IS-IS point à point", octobre 2008. (Remplace RFC3373) (P.S.)

[RFC5304] T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS, MàJ par RFC6233, RFC6232)

[RFC5305] T. Li, H. Smit, "Extensions IS-IS pour l'ingénierie du trafic", octobre 2008. (Remplace RFC3784, MàJ par RFC5307) (P.S.)

[RFC5306] M. Shand, L. Ginsberg, "Redémarrage de signalisation pour IS-IS", octobre 2008. (Remplace RFC3847) (P.S.)

5. Remerciements

Les auteurs tiennent à remercier Jim Gibson, Suresh Katukam, Jonathan Lang, and Quaizar Vohra de leurs commentaires sur ce document.

4. Contributeurs

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2008).

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.