Groupe de travail Réseau	D. McPherson, éd., Arbor Networks	
Request for Comments : 5311	L. Ginsberg, Cisco Systems	
Rend obsolète la RFC3786	S. Previdi, Cisco Systems	
Catégorie : Sur la voie de la normalisation	M. Shand, Cisco Systems	
Traduction Claude Brière de L'Isle	février 2009	

Extension simplifiée de l'espace de PDU d'état de liaison pour IS-IS

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 droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Le présent document décrit une méthode simplifiée pour étendre l'espace de PDU d'état de liaison (LSP, Link State PDU) au delà de la limite de 256 LSP. Cette méthode est destinée à être un remplacement préféré à la méthode définie dans la RFC 3786.
Table des matières
1. Généralités	1
2. Spécification des exigences	2
3. Définition des termes couramment utilisés	2
4. Utilisation d'identifiants de système supplémentaires	2
4.1 Informations supplémentaires dans les LSP étendus	3
4.2 Restrictions aux LSP étendus	3
4.3 Exigences de LSP d'origine	4
4.4 TLV Identifiant d'alias d'IS (IS Alias ID)	4
4.5 Nouveaux TLV pour la prise en charge des attributs d'IS voisin	4
5. Comparaison avec la solution de la RFC 3786	5
6. Considérations de déploiement	5
6.1 Annonce de nouveaux TLV dans les LSP étendus	5
6.2 Péremption de TLV Accessibilité et non SPF	5
6.3 État OL normal de LSP et utilisation des LSP étendus	5
6.4 Déplacement des LSP INFO d'attribut de voisin	5
6.5 Annonce des LSP INFO étendues d'extrémité	6
7. Considérations sur la sécurité	6
8. Considérations relatives à l'IANA	6
9. Références	6
9.1 Références normatives	6
9.2 Références pour information	7
Adresse des auteurs	7

 	1.	Généralités

La norme [ISO10589] définit l'ensemble de LSP qui peut être généré par un système à chaque niveau. Cet ensemble est limité à 256 LSP. [ISO10589] définit aussi une valeur maximum pour un LSP (originatingLxLSPBufferSize) comme étant de 1492 octets. La capacité de portage d'un ensemble de LSP, bien que limitée, a jusqu'à présent été suffisante pour les annonces associées à une zone/domaine dans les scénarios de déploiement existants. Cependant, la définition d'informations supplémentaires à inclure dans les LSP (par exemple, la prise en charge de multiples topologies, d'informations d'ingénierie de trafic, de capacités de routeur, etc.) pourrait excéder potentiellement la capacité de portage d'un ensemble de LSP.

Ce problème a éveillé l'intérêt pour la première fois quand des extensions d'ingénierie de trafic ont été introduites. Cet intérêt a résulté en la solution définie dans la [RFC3786]. Cependant, cette solution souffre des restrictions requises pour maintenir l'interopérabilité avec les systèmes qui ne prennent pas en charge les extensions.

Le présent document définit des extensions qui permettent à un système d'excéder la limite de 256 LSP et il le fait d'une manière qui ne pose pas de problèmes d'interopérabilité avec les systèmes qui ne prennent pas en charge l'extension. Il est vu comme une solution plus simple, et donc préférée au problème.

 	2.	Spécification des exigences
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].

 	3.	Définition des termes couramment utilisés

Cette Section donne des définitions des termes qui sont utilisés dans ce texte. La terminologie est conforme à celle utilisée dans la RFC 3786.

Système d'origine : IS physique qui fonctionne avec le protocole IS-IS. Comme le présent document décrit une méthode qui permet qu'un seul IS physique génère des LSP au nom de plusieurs IS virtuels, le système d'origine représente le seul IS physique.

Identifiant de système normal : identifiant de système d'un système d'origine comme défini par [ISO10589].

Identifiant de système supplémentaire : identifiant de système autre que le "Identifiant de système normal" qui est alloué par l'administrateur de réseau à un système d'origine afin de permettre la génération de LSP étendus. L'identifiant de système supplémentaire, comme l'identifiant de système normal, doit être unique dans toute la zone d'acheminement (niveau 1) ou tout le domaine (niveau 2).

LSP d'origine : LSP qui utilise l'identifiant de système normal dans son identifiant de LSP.

LSP étendu : LSP qui utilise un identifiant de système supplémentaire dans son identifiant de LSP.

Ensemble de LSP : tous les LSP d'un certain niveau qui ont le même identifiant de système et identifiant de pseudo nœud. (Le champ LSPID varie alors seulement dans l'octet Nombre de LSP.) Cela constitue l'ensemble complet d'informations d'état de liaison à un certain niveau généré en utilisant cet identifiant de système/identifiant de pseudo nœud. Ce terme est défini pour résoudre l'ambiguïté entre un LSP logique et une seule PDU d'état de liaison -- qui est parfois appelée un fragment de LSP. Cette dernière est l'unité d'information traitée par le processus de mise à jour.

Ensemble de LSP étendu : ensemble de LSP consistant en LSP qui utilisent un identifiant de système supplémentaire.

IS capable d'extension : IS qui met en œuvre les mécanismes décrits dans le présent document.

IS virtuel : système, identifié par un identifiant de système supplémentaire, annoncé comme générant les LSP étendus. Ces LSP spécifient l'identifiant de système supplémentaire dans leurs identifiants de LSP.

 	4.	Utilisation d'identifiants de système supplémentaires

Cette extension permet à un système d'origine de se voir allouer des identifiants de système supplémentaires qui peuvent être utilisés pour générer des ensembles de LSP supplémentaires. Les identifiants de système supplémentaires sont soumis aux mêmes restrictions que les identifiants de système normaux, c'est-à-dire, quand il est utilisé au niveau 1, l'identifiant de système supplémentaire DOIT être unique au sein de la zone de niveau 1. Quand utilisé au niveau 2, l'identifiant de système supplémentaire DOIT être unique au sein du domaine.

Les LSP étendus sont traités par le processus de mise à jour IS-IS de la même manière que les LSP normaux, c'est-à-dire, les mêmes règles de génération, arrosage, purge, etc. s'appliquent. En particulier, si le LSP étendu avec le numéro de LSP zéro et la durée de vie restante > 0 n'est pas présent pour un identifiant de système supplémentaire particulier, alors aucun des LSP étendus dans cet ensemble de LSP étendus ne devra être traité.

 	4.1	Informations supplémentaires dans les LSP étendus
Le LSP numéro zéro d'un ensemble de LSP étendus DOIT inclure le nouveau TLV Identifiant d'alias d'IS défini au paragraphe 4.4. Cela permet à l'ensemble de LSP étendus d'être associé au système d'origine qui a généré le ou les LSP.

 	4.2	Restrictions aux LSP étendus
Les restrictions suivantes sur les informations qui peuvent apparaître dans un LSP étendu sont définies afin d'éviter des problèmes d'interopérabilité avec les systèmes qui ne prennent pas en charge les extensions définies dans le présent document. Toutes les références de TLV se fondent sur les définitions actuelles du registre IANA des codets de TLV IS-IS.

 	4.2.1	TLV qui NE DOIVENT PAS apparaître
Les TLV suivants NE DOIVENT PAS apparaître dans le LSP étendu:

Nom du TLV (n°)
Voisins ES (3)
DIS part. (4)
Voisins de préfixe (5)

Si un des TLV mentionnés ci-dessus apparaît dans un LSP étendu, un IS capable de cette extension DOIT ignorer ces TLV à réception et DEVRAIT rapporter une erreur. Les autres TLV dans l'ensemble de LSP étendus DOIVENT être traités normalement.

 	4.2.2	Annonces d'extrémité dans les LSP étendus
L'annonce d'informations d'extrémité dans les LSP étendus est permise. L'inclusion de telles informations exige l'annonce d'un voisin entre le système d'origine et l'IS virtuel associé à l'ensemble de LSP étendus dans lequel apparaissent les annonces d'extrémité. Voir au paragraphe 4.2.3.

Quand des annonces d'extrémité pour plusieurs topologies (voir la [RFC5120]) sont incluse dans un ensemble de LSP étendus, le TLV Topologie multiple (229) DOIT inclure toutes les topologies pour lesquelles une annonce d'extrémité est incluse.

Les TLV suivants entrent dans cette catégorie :

Nom du TLV (n°)
Accessibilité IP interne (128)
Adresse IP externe (130)
Accessibilité IP étendue (135)
Accessibilité IP multi topologies (235)
Accessibilité IPv6 (236)
Accessibilité IPv6 multi topologies (237)

 	4.2.3	Restrictions d'annonce d'IS voisin
L'annonce d'accessibilité d'IS voisin dans un LSP étendu est restreinte à l'annonce de l'accessibilité de voisin au système d'origine. Un voisin du système d'origine DOIT être annoncé dans les LSP étendus. Si la capacité de multi topologies [RFC5120] est prise en charge, une annonce Voisin IS MT au système intermédiaire d'origine DOIT être incluse pour chaque topologie annoncée dans l'ensemble de LSP étendus. Les annonces de voisin au système d'origine dans un LSP étendu DOIVENT utiliser une métrique non zéro et DEVRAIENT utiliser une métrique de MaxLinkMetric-1.

Les restrictions définies ici s'appliquent à tous les TLV utilisés pour annoncer l'accessibilité de voisin. Cela inclut les TLV suivants :

Nom du TLV (n°)
Voisins IIS (2)
Accessibilité IS étendue (22)
ISN MT (222)

 	4.2.4	Adresses de zone
Le LSP numéro zéro d'un ensemble de LSP étendus DOIT inclure un TLV Adresse de zone. L'ensemble des adresses de zone annoncé DOIT être un sous ensemble de l'ensemble des adresses de zone annoncé dans le LSP normal de numéro zéro au niveau correspondant. De préférence, l'annonce DEVRAIT être syntaxiquement identique à celle incluse dans le LSP normal de numéro zéro au niveau correspondant.

 	4.2.5	Bits de surcharge, rattachement, réparation de partition
Les bits Surcharge (OL, Overload), Rattaché (ATT, Attached), et Réparation de partition (P, Partition Repair) DOIVENT être réglés à 0 dans tous les LSP étendus.

Noter que les IS qui NE prennent PAS en charge ces extensions vont interpréter ces bits normalement dans les LSP étendus qu'ils reçoivent. Si le bit ATT était établi dans le LSP étendu, cela pourrait indiquer que l'IS virtuel est rattaché à d'autres zones quand le système d'origine ne l'est pas. Cela pourrait causer l'utilisation par les systèmes traditionnels de l'IS virtuel comme point de sortie par défaut à partir de la zone.

 	4.3	Exigences de LSP d'origine
L'ensemble de LSP d'origine DOIT inclure un voisin à l'IS virtuel associé à chaque ensemble de LSP étendus généré. Si la capacité multi topologies de la [RFC5120] est prise en charge, une annonce Voisin IS MT à l'IS virtuel DOIT être incluse pour chaque topologie annoncée dans l'ensemble de LSP étendus. La ou les annonces de voisin dans le LSP d'origine DOIVENT spécifier une métrique de zéro. Cela garantit que la vérification de la connexité bidirectionnelle entre le système d'origine et l'IS virtuel va réussir et que le coût d'accès de l'IS virtuel est le même que le coût d'accès du système d'origine.

 	4.4	TLV Identifiant d'alias d'IS (IS Alias ID)
Le TLV Alias d'IS permet à un IS capable de l'extension de reconnaître le système d'origine d'un ensemble de LSP étendus.  Il identifie l'identifiant de système normal du système d'origine.

Type : 24
Longueur : nombre d'octets dans le champ Valeur (7 à 255)
Valeur :
	Nombre d'octets
+-------------------------------------+
| Identifiant de système normal   |     6
+-------------------------------------+
| Longueur des sous TLV            |     1
+-------------------------------------+
| Sous TLV (facultatifs)              |     0 à 248
+-------------------------------------+

Identifiant de système normal : identifiant de système normal du système d'origine.

Longueur des sous TLV : longueur totale de tous les sous TLV.

Sous TLV : aucun sous TLV n'est défini dans le présent document. Si de futures extensions définissent des sous TLV, ils DOIVENT être formatés comme décrit dans la [RFC5305].

 	4.5	Nouveaux TLV pour la prise en charge des attributs d'IS voisin
Une des sources majeures d'informations supplémentaires dans les LSP est l'information de sous TLV associée au TLV Accessibilité d'IS étendue (22) et au TLV MT-ISN (222). Cela inclut (mais n'y est pas limité) les informations requises dans la prise en charge de l'ingénierie du trafic (TE, Traffic Engineering) comme définies dans les [RFC5305] et [RFC5307]. Les restrictions définies dans le présent document interdisent la présence du TLV 22 et/ou du TLV 222 dans les LSP étendus sauf pour annoncer les relations de voisinage avec le système d'origine. Dans le cas où il y aurait un besoin d'annoncer dans les LSP étendus de telles informations associées aux voisins du système d'origine, il serait nécessaire de définir de nouveaux TLV pour porter les informations de sous TLV.

Deux nouveaux TLV sont donc définis.

1) TLV Attribut d'IS voisin (23). Il est identique en format au TLV Accessibilité d'IS étendu (22).

2) TLV Attribut d'IS voisin MT (223). Il est identique en format au TLV MT-ISN (222).

Ces nouveaux TLV PEUVENT être inclus dans les LSP d'origine ou les LSP étendus. Sans considération du type de LSP dans lequel les TLV apparaissent, les informations relevent de la relation de voisinage entre le système d'origine et l'IS identifié dans le TLV.

Ces TLV NE DOIVENT PAS être utilisés pour déduire qu'une relation de voisinage existe en l'absence du TLV 22 ou du TLV 222 (quel que soit celui qui s'applique) dans l'ensemble de LSP d'origine pour le voisin spécifié. Cette restriction est nécessaire afin de conserver la compatibilité avec les systèmes qui ne prennent pas en charge ces extensions.

 	5.	Comparaison avec la solution de la RFC 3786

Le présent document utilise le même mécanisme de base (identifiants de système supplémentaires) que la RFC 3786 pour permettre à un système d'origine de générer plus de 256 LSP. Il diffère de la RFC 3786 en ce qu'il restreint le contenu des LSP étendus aux informations qui N'impactent PAS la construction d'une arborescence de plus court chemin (SPT, Shortest Path Tree).

Les mises en œuvre IS-IS traditionnelles qui ne prennent pas en charge les extensions définies dans le présent document voient les LSP étendus comme des informations associées à un système qui est seulement accessible via le système d'origine. Comme aucun autre système n'est accessible via les IS virtuels, le calcul de plus court chemin en premier (SPF, Shortest Path First ) dans les IS traditionnels est donc cohérent avec celui effectué par les IS capables de l'extension. Il n'est donc pas besoin des deux différents modes de fonctionnement définis dans la RFC 3786.

Il n'y a pas non plus besoin du traitement spécial de l'ensemble de LSP d'origine et du ou des ensembles de LSP étendus comme un seul LSP logique durant le SPF spécifié à la Section 5 de la RFC 3786.

 	6.	Considérations de déploiement

Un certain nombre de considérations de déploiement limitent l'utilité des LSP étendus sauf si tous les systèmes sont des IS à capacité d'extension.

 	6.1	Annonce de nouveaux TLV dans les LSP étendus
Comme les LSP étendus PEUVENT être utilisés pour annoncer les TLV associés à d'autres extensions de protocole (dont la définition sort du domaine d'application du présent document) et/ou aux extensions définies au paragraphe 4.4 du présent document, il est évident que l'utilisation des informations dans les LSP étendus par les mises en œuvre IS-IS traditionnelles va être limitée. Cela implique que lorsque les mises en œuvre sont révisées pour prendre en charge les extensions de protocole qui définissent de nouveaux TLV/sous TLV qui PEUVENT être annoncés dans les LSP étendus, la mise en œuvre DEVRAIT aussi être révisée pour prendre en charge les extensions définies dans le présent document afin qu'elle soit capable de traiter les nouvelles informations, qu'elles apparaissent dans les LSP normaux ou étendus.

 	6.2	Péremption de TLV Accessibilité et non SPF
Dans les cas où des informations non SPF sont annoncées dans des LSP, il est nécessaire de déterminer si le système qui a généré l'annonce est accessible afin de garantir qu'un IS receveur n'utilise pas ou ne laisse pas fuir des informations périmées. Tant que le bit OL N'est PAS établi par le système d'origine dans les LSP normaux, l'accessibilité à l'IS virtuel va être cohérente avec l'accessibilité au système d'origine. Donc, aucune règle particulière n'est exigée dans ce cas.

 	6.3	État OL normal de LSP et utilisation des LSP étendus
Si le système d'origine établit le bit OL dans un LSP normal, les systèmes traditionnels vont voir les IS virtuels associés au système d'origine comme inaccessibles et donc ne vont pas utiliser les informations dans les LSP étendus correspondants. Dans ces circonstances, les IS capables de l'extension DOIVENT aussi voir les IS virtuels comme inaccessibles. Cela évite de potentielles boucles d'acheminement dans les cas où des informations d'extrémité sont annoncées dans les LSP étendus.

 	6.4	Déplacement des LSP INFO d'attribut de voisin
Le paragraphe 4.4 définit les nouveaux TLV qui PEUVENT être utilisés pour annoncer les informations d'attribut de voisin dans les LSP étendus. Dans les cas où des informations d'attribut de voisin associées au même contexte (par exemple, la même liaison) apparaissent à la fois dans un LSP d'origine et dans un ou plusieurs ensembles de LSP étendus, les règles suivantes s'appliquent pour chaque attribut :

o	Si les informations d'attribut ne sont pas en conflit, elles DOIVENT être considérées comme additives.

o	Si les informations d'attribut sont en conflit, alors les informations dans le LSP d'origine, si elles sont présentes, DOIVENT être utilisées. Si il n'y a aucune information dans le LSP d'origine, alors les information provenant du LSP étendu avec le plus faible identifiant de système DEVRONT être préférées.

o	Dans les cas où les informations sur le même voisin/liaison/attribut apparaissent dans les deux TLV 22 et TLV 23 (ou TLV 222 et TLV 223 pour le même MTID) alors les informations dans le TLV 22 (ou TLV 222) DOIVENT être utilisées et les informations dans le TLV 23 (ou TLV 223) DOIVENT être ignorées.

L'utilisation des nouveaux TLV pour les informations d'attribut de voisin vont procurer des avantages supplémentaires qui incluent :
o	l'élimination du besoin que des TLV IS voisin redondants soient traités au titre du calcul de SPF ;
o	une prise en charge plus facile d'un ensemble d'informations de TE associées à une seule liaison qui excède la limite de TLV de 255 octets en permettant l'interprétation de plusieurs TLV comme additifs plutôt que comme mutuellement exclusifs.

 	6.5	Annonce des LSP INFO étendues d'extrémité
Le besoin d'annoncer les informations d'extrémité dans les LSP étendus peut apparaître à cause de fuites extensives d'informations inter niveaux ou à cause de la prise en charge de topologies multiples comme décrit dans la [RFC5120]. Quand des informations d'extrémité sont annoncées dans des LSP étendus, ces LSP contiennent maintenant des informations qui DOIVENT être traitées afin de mettre correctement à jour le plan de transmission d'un IS. Cela peut augmenter la fréquence d'événements qui déclenchent des mises à jour du plan de transmission par les IS dans le réseau. Il est donc recommandé que, quand c'est possible, les informations d'extrémité soient restreintes à l'ensemble de LSP normaux.

 	7.	Considérations sur la sécurité

Le présent document ne soulève aucune nouvelle question de sécurité pour IS-IS. Pour les considérations générales de sécurité pour IS-IS, voir la [RFC5304].

 	8.	Considérations relatives à l'IANA

Le présent document définit les nouveaux TLV IS-IS suivants qui sont inscrits dans le registre des codets de TLV IS-IS :

Type	Description	IIH	LSP	SNP
 23	Attribut de voisin d'IS	non	oui	non
 24	Identifiant d'alias IS	non	oui	non
223	Attribut de voisin MT IS	non	oui	non

 	9.	Références
 	9.1	Références normatives

[ISO10589]	Norme internationale ISO 10589, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion(ISO8473)", seconde édition, 2002.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC5120]	T. Przygienda, N. Shen, N. Sheth, "M-ISIS : acheminement multi topologies (MT) de système intermédiaire à système intermédiaire (IS-IS)", février 2008. (P.S.)

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

[RFC5307]	K. Kompella et Y. Rekhter, éd., "Extensions IS-IS pour la prise en charge de la commutation multiprotocole avec étiquetage des flux généralisée (GMPLS)", octobre 2008. (MàJ RFC5305) (P.S.)

 	9.2	Références pour information

[RFC3786]	A. Hermelin, S. Previdi, M. Shand, "Extension du nombre de fragments de PDU d'état de liaison (LSP) de système intermédiaire à système intermédiaire (IS-IS) au-delà de la limite de 256", mai 2004. (Information)

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

 	Adresse des auteurs

Danny McPherson (editor)	Les Ginsberg	
Arbor Networks, Inc.	Cisco Systems	
mél :  danny@arbor.net 	mél : ginsberg@cisco.com 	

Stefano Previdi	Mike Shand	
Cisco Systems	Cisco Systems	
mél : sprevidi@cisco.com 	mél : mshand@cisco.com