Groupe de travail Réseau	T. Li, Redback Networks, Inc.	
Request for Comments : 5305	H. Smit	
Rend obsolète la RFC 3784	octobre 2008	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Extensions à IS-IS pour l'ingénierie du trafic

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 décrit des extensions au protocole de système intermédiaire à système intermédiaire (IS-IS) pour prendre en charge l'ingénierie du trafic (TE, Traffic Engineering). Le présent document étend le protocole IS-IS en spécifiant de nouvelles informations qu'un système intermédiaire (routeur) peut placer dans les unités de données de protocole d'état de liaison (LSP, Link State Protocol). Ces informations décrivent des détails supplémentaires concernant l'état du réseau qui sont utiles pour les calculs d'ingénierie du trafic.
Table des matières
1. Introduction	1
1.1 Langage des exigences	2
2. Introduction de sous TLV	2
3. TLV Accessibilité IS étendue	2
3.1 Sous TLV 3 : Groupe administratif (couleur, classe de ressource)	3
3.2 Sous TLV 6 : Adresse d'interface IPv4	3
3.3 Sous TLV 8 : Adresse IPv4 de voisin	4
3.4 Sous TLV 9 : Bande passante maximum de liaison	4
3.5 Sous TLV 10 : Bande passante de liaison maximum réservable	4
3.6 Sous TLV 11 : Bande passante non réservée	4
3.7 Sous TLV 18 : Métrique par défaut d'ingénierie du trafic	4
4. TLV Accessibilité IP étendue	5
4.1 Bit activé/désactivé	5
4.2 Expansion du TLV Accessibilité IP étendue avec des sous TLV	6
4.3 TLV Identifiant de routeur d'ingénierie du trafic	6
5. Considérations relatives à l'IANA	6
5.1 Allocations  de codets de TLV	6
5.2 Nouveaux registres	7
6. Considérations sur la sécurité	7
7. Remerciements	7
8. Références	8
8.1 Références normatives	8
8.2 Références pour information	8
Adresse des auteurs	8
Déclaration complète de droits de reproduction	9

 	1.	Introduction

Le protocole IS-IS est spécifié dans la norme [ISO-10589], avec les extensions pour la prise en charge de IPv4 spécifiées dans la [RFC1195]. Chaque système intermédiaire (IS) (routeur) annonce une ou plusieurs unités de données de protocole d'état de liaison (LSP) IS-IS avec des informations d'acheminement. Chaque LSP est composé d'un en-tête fixe et d'un certain nombre de triplets, chacun consistant en un Type, une Longueur, et une Valeur. Ces triplets sont couramment appelés des TLV, et sont un bon moyen de coder les informations dans un format souple et extensible.

Le présent document contient le dessin de nouveaux TLV pour remplacer les TLV existants Voisin IS et Accessibilité IP, et inclure des informations supplémentaires sur les caractéristiques d'une liaison particulière d'un LSP IS-IS. Les caractéristiques décrites dans le présent document sont nécessaires pour l'ingénierie du trafic [RFC2702]. Des objectifs secondaires incluent de diminuer la gamme dynamique de la métrique IS-IS et d'améliorer le codage des préfixes IP.

L'identifiant de routeur est utile pour les besoins de l'ingénierie du trafic parce que il décrit une seule adresse qui peut toujours être utilisée pour référencer un routeur particulier.

Les mécanismes et procédures pour migrer sur les nouveaux TLV ne sont pas discutés dans le présent document.

Une version antérieure de ce document a été publiée comme [RFC3784] avec le statut d'information. La présente version est sur la voie de la normalisation.

 	1.1	Langage 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].

 	2.	Introduction de sous TLV

Le présent document introduit une nouvelle façon de coder les informations d'acheminement dans IS-IS. Le nouvel objet est appelé un sous TLV. Les sous TLV sont similaires aux TLV réguliers. Ils utilisent les mêmes concepts que les TLV réguliers. La différence est que les TLV existent dans les paquets IS-IS, tandis que les sous TLV existent à l'intérieur des TLV. Les TLV sont utilisés pour ajouter des informations aux paquets IS-IS. Les sous TLV sont utilisés pour ajouter des informations à des TLV particuliers. Chaque sous TLV consiste en trois champs, un champ de Type de un octet, un champ Longueur de un octet, et une Valeur de zéro, un ou plusieurs octets. Le champ Type indique le type des éléments dans le champ Valeur. Le champ Longueur indique la longueur du champ Valeur en octets. Chaque sous TLV peut contenir plusieurs éléments. Le nombre d'éléments dans un sous TLV peut être calculé à partir de la longueur totale du sous TLV, quand la longueur de chaque élément est connue. Les sous TLV inconnus sont à ignorer et à sauter à réception.

L'espace de type de sous TLV est géré par le groupe de travail IS-IS de l'IETF [ISIS-WG]. Les valeurs des nouveaux types sont allouées après revue sur la liste de diffusion du groupe de travail IETF IS-IS. Cela va normalement exiger la publication d'une documentation supplémentaire décrivant comment le nouveau type est utilisé. Au cas où le groupe de travail IS-IS serait dissout, la revue devra être effectuée par un expert désigné par le Directeur de zone responsable.

 	3.	TLV Accessibilité d'IS étendue

Le type du TLV Accessibilité d'IS étendue est 22.

L'accessibilité IS existante (TLV type 2, défini dans [ISO-10589]) contient les informations sur une série d'IS voisins. Pour chaque voisin, il y a une structure qui contient la métrique par défaut, le délai, le coût monétaire, la fiabilité, et l'identifiant de 7 octets du voisin adjacent. De ces informations, la métrique par défaut est couramment utilisée. La métrique par défaut est actuellement d'un octet, avec un bit utilisé pour indiquer si la métrique est interne ou externe, et un bit qui était à l'origine inutilisé, mais qui a ensuite été défini par la [RFC5302] pour être le bit Activé/Désactivé. Les 6 bits restants sont utilisés pour mémoriser la métrique réelle, résultant en une gamme possible de métriques de 0 à 63. Cette limitation est une des restrictions qu'on souhaite supprimer.

Les trois métriques restantes (délai, coût monétaire, et fiabilité) ne sont pas mises en œuvre de façon courante et reflètent des frais généraux non utilisés dans le TLV. Le voisin est identifié par son identifiant de système, normalement de 6 octets, plus un octet indiquant le numéro de pseudo nœud. Donc, le TLV existant consomme 11 octets par voisin, avec 4 octets pour la métrique et 7 octets pour l'identification de voisin. Pour indiquer plusieurs adjacences, cette structure est répétée dans le TLV Accessibilité d'IS. Parce que le TLV est limité à un contenu de 255 octets, un seul TLV peut décrite jusqu'à 23 voisins. Le TLV Accessibilité d'IS peut être répété dans les fragments de LSP pour décrire plus de voisins.

Le TLV proposé Accessibilité d'IS étendue contient une nouvelle structure de données, consistant en :
7 octets d'identifiant de système et de numéro de pseudo nœud
3 octets de métrique par défaut
1 octet de longueur des sous TLV
0 à 244 octets de sous TLV, où chaque sous TLV consiste en une séquence de
1 octet de sous type
1 octet de longueur du champ Valeur du sous TLV
0 à 242 octets de valeur.

Donc, si aucun sous TLV n'est utilisé, le nouveau codage exige 11 octets et peut contenir jusqu'à 23 voisins. Noter que alors que le codage permet 255 octets de sous TLV, la valeur maximum ne peut pas tenir dans le TLV Accessibilité d'IS global. Le maximum pratique est 255 octets moins les 11 octets décrits ci-dessus, soit 244 octets. Il n'y a pas de mécanisme défini pour étendre l'espace de sous TLV. Donc, il est déconseillé de gaspiller l'espace de sous TLV.

Les octets de métrique sont codés comme des entiers non signés de 24 bits. Noter que le champ Métrique dans le nouveau TLV Accessibilité IP étendue est codé comme un entier non signé de 32 bits. Ces tailles différentes ont été choisies pour qu'il soit très improbable que le coût d'un chemin intra zone soit étêté pour tenir dans le champ Métrique d'un chemin inter zones.

Pour empêcher un débordement dans une mise en œuvre de plus court chemin en premier (SPF, Shortest Path First) d'ingénierie du trafic, toutes les métriques supérieures ou égales à MAX_PATH_METRIC DEVRONT être considérées avoir une métrique de MAX_PATH_METRIC. Il est plus facile de choisir MAX_PATH_METRIC tel que MAX_PATH_METRIC plus une seule métrique de liaison ne déborde pas le nombre de bits pour le calcul de métrique interne. On suppose que c'est 32 bits. Donc, on a choisi MAX_PATH_METRIC comme étant 4  261  412  864 (0xFE000000, 2^32 - 2^25).

Si une liaison est annoncée avec la métrique de liaison maximum (2^24 - 1), cette liaison NE DOIT PAS être prise en compte durant le calcul normal de SPF. Cela va permettre l'annonce d'une liaison pour des besoins autres que de construire l'arborescence normale de plus court chemin. Un exemple est celui d'une liaison qui est disponible pour l'ingénierie du trafic, mais pas pour l'acheminement bond par bond.

Certains des sous TLV sont décrits ici :

Type de sous TLV	Longueur (octets)	Nom
  3	4	Groupe administratif (couleur)
  6	4	Adresse d'interface IPv4
  8	4	Adresse de voisin IPv4
  9	4	Bande passante maximum de liaison
10	4	Bande passante réservable maximum de liaison
11	32	Bande passante non réservée
18	3	Métrique TE par défaut
250-254		Réservé pour extensions spécifiques de Cisco
255		Réservé pour expansion future

Chacun de ces sous TLV est décrit ci-dessous. Sauf mention contraire, plusieurs occurrences des informations sont prises en charge par plusieurs inclusions du sous TLV.

 	3.1	Sous TLV 3 : Groupe administratif (couleur, classe de ressource)
Le sous TLV Groupe administratif contient un gabarit binaire de 4 octets alloué par l'administrateur de réseau. Chaque bit établi correspond à un groupe administratif alloué à l'interface.

Par convention, le bit de moindre poids est appelé le "groupe 0", et le bit de poids fort est appelé le "groupe 31".

Ce sous TLV est FACULTATIF. Ce sous TLV DEVRAIT apparaître une fois au plus dans chaque TLV Accessibilité d'IS étendue.

 	3.2	Sous TLV 6 : Adresse d'interface IPv4
Ce sous TLV contient une adresse IPv4 de 4 octets pour l'interface décrite par le TLV (principal). Ce sous TLV peut se produire plusieurs fois.

Les mises en œuvre NE DOIVENT PAS injecter un préfixe /32 pour l'adresse d'interface dans leur tableau d'acheminement ou de transmission parce que cela peut conduire à des boucles de transmission lors d'interactions avec des systèmes qui ne prennent pas en charge ce sous TLV.

Si un routeur met en œuvre les extensions de TLV de base du présent document, il PEUT ajouter ou omettre ce sous TLV dans la description d'une adjacence. Si un routeur met en œuvre l'ingénierie du trafic, il DOIT inclure ce sous TLV.

 	3.3	Sous TLV 8 : Adresse IPv4 de voisin
Ce sous TLV contient une seule adresse IPv4 pour un routeur du voisinage sur cette liaison. Ce sous TLV peut se produire plusieurs fois.

Les mises en œuvre NE DOIVENT PAS injecter un préfixe /32 pour l'adresse de voisin dans leur tableau d'acheminement ou de transmission parce que cela pourrait conduire à des boucles de transmission lors d'interactions avec des systèmes qui ne prennent pas en charge ce sous TLV.

Si un routeur met en œuvre les extensions de TLV de base du présent document, il PEUT ajouter ou omettre ce sous TLV dans la description d'une adjacence. Si un routeur met en œuvre l'ingénierie du trafic, il DOIT inclure ce sous TLV.

 	3.4	Sous TLV 9 : Bande passante maximum de liaison
Ce sous TLV contient la bande passante maximum qui peut être utilisée sur cette liaison dans cette direction (du système d'origine du LSP à ses voisins). C'est utile pour l'ingénierie du trafic.

La bande passante maximum de liaison est codée sur 32 bits en format de virgule flottante IEEE. Les unités sont des octets (pas des bits !) par seconde.

Ce sous TLV est facultatif. Ce sous TLV DEVRAIT apparaître au plus une fois dans chaque TLV Accessibilité d'IS étendue.

 	3.5	Sous TLV 10 : Bande passante de liaison maximum réservable
Ce sous TLV contient la quantité maximum de bande passante qui peut être réservée dans cette direction sur cette liaison. Noter que pour des besoins de sur-abonnement, cela peut être supérieur à la bande passante de la liaison.

La bande passante maximum réservable est codée sur 32 bits en format de virgule flottante IEEE. Les unités sont des octets (pas des bits !) par seconde.

Ce sous TLV est facultatif. Ce sous TLV DEVRAIT apparaître au plus une fois dans chaque TLV Accessibilité d'IS étendue.

 	3.6	Sous TLV 11 : Bande passante non réservée
Ce sous TLV contient la quantité de bande passante réservable dans cette direction sur cette liaison. Noter que pour des besoins de sur-abonnement, ceci peut être supérieur à la bande passante de la liaison.

À cause du besoin de priorité et de préemption, chaque extrémité de tête a besoin de connaître la quantité de bande passante réservée à chaque niveau de priorité. Donc, ce sous TLV contient huit nombres de 32 bits en virgule flottante IEEE. Les unités sont des octets (pas des bits !) par seconde. Les valeurs correspondent à la bande passante qui peut être réservée avec une priorité d'établissement de 0 à 7, arrangée en ordre croissant avec la priorité 0 au début du sous TLV, et la priorité 7 à la fin du sous TLV.

Pour des raisons de stabilité, des changements rapides des valeurs dans ce sous TLV NE DEVRAIENT PAS causer une génération rapide de LSP.

Ce sous TLV est facultatif. Il DEVRAIT apparaître au plus une fois dans chaque TLV Accessibilité d'IS étendue.

 	3.7	Sous TLV 18 : Métrique par défaut d'ingénierie du trafic
Ce sous TLV contient un entier non signé de 24 bits. Cette métrique est allouée administrativement et peut être utilisée pour présenter une topologie pondérée différemment aux calculs de SPF d'ingénierie du trafic.

Pour empêcher le débordement dans une mise en œuvre de SPF d'ingénierie du trafic, toutes les métriques supérieures ou égales à MAX_PATH_METRIC DEVRONT être considérées comme ayant une métrique de MAX_PATH_METRIC. Il est plus facile de choisir MAX_PATH_METRIC tel que MAX_PATH_METRIC plus une seule métrique de liaison ne dépasse pas le nombre de bits pour le calcul de métrique interne. On suppose que c'est 32 bits. Donc, on a choisi MAX_PATH_METRIC comme 4  261  412  864 (0xFE000000, 2^32 - 2^25).

Ce sous TLV est facultatif. Ce sous TLV DEVRAIT apparaître au plus une fois dans chaque TLV Accessibilité d'IS étendue. Si une liaison est annoncée sans ce sous TLV, les calculs de SPF d'ingénierie du trafic DOIVENT utiliser la métrique par défaut normale de cette liaison, qui est annoncée dans la partie fixe du TLV Accessibilité d'IS étendue.

 	4.	TLV Accessibilité IP étendue

Le type du TLV Accessibilité IP étendue est 135.

Les TLV d'accessibilité IP existants (TLV de type 128 et 130, définis dans la [RFC1195]) portent des préfixes IP dans un format qui est analogue au TLV IS voisin de la norme [ISO-10589]. Ils portent quatre métriques, dont seule la métrique par défaut est couramment utilisée. La métrique par défaut a une gamme possible de 0 à 63. On souhaite supprimer cette restriction.

De plus, la redistribution de chemins (autrement dit, la fuite de chemins) pose un problème clé qui n'a pas été complètement traité par les TLV existants d'accessibilité IP. La [RFC1195] permet à un routeur d'annoncer les préfixes qui sont plus hauts dans la hiérarchie des niveaux. Malheureusement, aucun mécanisme n'est défini pour annoncer les préfixes qui sont plus bas dans la hiérarchie des niveaux.

Pour régler ces deux problèmes, le TLV Accessibilité IP étendue proposé fournit une métrique de 32 bits et ajoute un bit pour indiquer qu'un préfixe a été redistribué "plus bas" dans la hiérarchie.

Le TLV Accessibilité IP étendue proposé contient une nouvelle structure de données, consistant en :
4 octets d'informations de métrique
1 octet d'informations de contrôle, consistant en
1 bit d'information Activé/Désactivé
1 bit indiquant la présence des sous TLV
6 bits de longueur de préfixe
0 à 4 octets de préfixe IPv4
0 à 250 octets des sous TLV facultatifs, si il en est de présent, consistant en :
1 octet de longueur des sous TLV
0 à 249 octets des sous TLV, où chaque sous TLV consiste en une séquence de
1 octet de sous type
1 octet de longueur du champ Valeur du sous TLV
0 à 247 octets de valeur.

Cette structure de données peut être répliquée dans le TLV, tant que la longueur maximum du TLV n'est pas dépassée.

Les 6 bits de longueur de préfixe peuvent avoir les valeurs de 0 à 32 et indiquent le nombre de bits significatifs dans le préfixe. Le préfixe est codé dans le nombre minimal d'octets pour le nombre donné de bits significatifs. Cela implique :

Bits significatifs	Octets
         0	0
    1 à 8	1
  9 à 16	2
17 à 24	3
25 à 32	4

Les bits restants du préfixe sont transmis à zéro et ignorés à réception.

Si un préfixe est annoncé avec une métrique supérieure à MAX_PATH_METRIC (0xFE000000, voir la Section 3) ce préfixe NE DOIT PAS être pris en compte dans le calcul normal de SPF. Cela permet l'annonce d'un préfixe pour des besoins autres que de construire le tableau normal d'acheminement IP.

 	4.1	Bit Activé/Désactivé
Si il était permis aux routeurs de redistribuer librement les préfixes IP dans les deux directions entre le niveau 1 et le niveau 2 sans aucun mécanisme supplémentaire, ces routeurs ne seraient pas capables de déterminer les boucles des informations d'acheminement. Un problème se produit quand un routeur apprend un préfixe via l'acheminement de niveau 2 et annonce ce préfixe dans une zone de niveau 1, où un autre routeur pourrait prendre ce chemin et ré annoncer le préfixe dans le cœur de réseau de niveau 2. Si la source d'origine retire le préfixe, ces deux routeurs pourraient finir par avoir une boucle d'acheminement entre eux, où une partie du chemin en boucle est via l'acheminement de niveau 1 et l'autre partie est via l'acheminement de niveau 2. La solution que propose la [RFC1195] est de ne permettre les annonces de préfixes que dans le sens ascendant de la hiérarchie des niveaux, et d'interdire l'annonce de préfixes en descendant la hiérarchie.

Pour empêcher ces boucles de préfixes entre niveaux, un nouveau bit d'information est défini dans le nouveau TLV Accessibilité IP étendue. Ce bit est appelé le bit Activé/Désactivé. Le bit Activé/Désactivé DEVRA être réglé à 0 quand un préfixe est injecté pour la première fois dans IS-IS. Si un préfixe est annoncé d'un niveau supérieur à un niveau inférieur (par exemple, de niveau 2 à niveau 1) le bit DOIT être réglé à 1, indiquant que le préfixe a voyagé en descendant la hiérarchie. Les préfixes qui ont le bit Activé/Désactivé réglé à 1 peuvent seulement être annoncés en descendant la hiérarchie, c'est-à-dire, à des niveaux inférieurs.

Cette sémantique s'applique même si IS-IS est étendu à l'avenir à avoir des niveaux supplémentaires. En s'assurant que les préfixes suivent seulement la hiérarchie IS-IS, on s'assure que les informations ne sont pas en boucle, s'assurant ainsi qu'il n'y a pas de boucle de transmission persistante.

Si un préfixe est annoncé d'une zone à une autre au même niveau, le bit Activé/Désactivé DEVRA alors être réglé à 1. Cette situation peut se produire quand un routeur met en œuvre plusieurs routeurs virtuels au même niveau, mais dans des zones différentes.

La sémantique du bit Activé/Désactivé dans le nouveau TLV Accessibilité IP étendue est identique à celle du bit Activé/Désactivé défini dans la [RFC5302].

 	4.2	Expansion du TLV Accessibilité IP étendue avec des sous TLV
Le TLV Accessibilité IP étendue peut contenir des sous TLV qui s'appliquent à un préfixe particulier. Cela facilite les futures extensions. Si il n'y a pas de sous TLV associé à un préfixe, le bit indiquant la présence des sous TLV DEVRA être réglé à 0. Si ce bit est réglé à 1, le premier octet après le préfixe va être interprété comme la longueur de tous les sous TLV associés à ce préfixe IPv4. Noter qu'alors que le codage permet 255 octets de sous TLV, la valeur maximum ne peut pas tenir dans le TLV Accessibilité IP étendue global. Le maximum pratique est 255 octets moins les 5 à 9 octets décrits ci-dessus, soit 250 octets.

Le présent document ne définit aucun sous TLV pour le TLV Accessibilité IP étendue.

 	4.3	TLV Identifiant de routeur d'ingénierie du trafic
Le type du TLV Identifiant de routeur d'ingénierie du trafic est 134.

Le TLV Identifiant de routeur contient l'identifiant de routeur de 4 octets du  routeur qui a généré le LSP. C'est utile à plusieurs égards :

Pour l'ingénierie du trafic, il garantit qu'on a une seule adresse stable qui peut toujours être référencée dans un chemin qui va être accessible à partir de plusieurs bonds au loin, sans considération de l'état des interfaces du nœud.

Si OSPF est aussi actif dans le domaine, l'ingénierie du trafic peut calculer la transposition entre les topologies OSPF et IS-IS .

Si un routeur ne met pas en œuvre l'ingénierie du trafic, il PEUT ajouter ou omettre le TLV Identifiant de routeur d'ingénierie du trafic. Si un routeur met en œuvre l'ingénierie du trafic, il DOIT inclure ce TLV dans son LSP. Ce TLV NE DEVRAIT PAS être inclus plus d'une fois dans un LSP.

Si un routeur annonce le TTLV Identifiant de routeur d'ingénierie du trafic dans son LSP, et si il annonce des préfixes via le protocole de routeur frontière (BGP, Border Gateway Protocol ) avec l'attribut de prochain bond BGP réglé à l'identifiant de routeur BGP, l'identifiant de routeur d'ingénierie du trafic DEVRAIT être le même que l'identifiant de routeur BGP.

Les mises en œuvre NE DOIVENT PAS injecter un préfixe /32 pour l'identifiant de routeur dans leur tableau de transmission parce que cela peut conduire à des boucles de transmission lors d'interactions avec des systèmes qui ne prennent pas en charge ce TLV.

 	5.	Considérations relatives à l'IANA

Des demandes antérieures à l'IANA sur ce sujet ont été couvertes au titre de la [RFC3784]. Le texte de ces demandes est reproduit ici pour être complet et cohérent.

 	5.1	Allocations de codets de TLV
Le présent document définit les nouveaux types de TLV IS-IS suivants, qui ont été reflétés dans le registre de codets de TLV IS-IS :

Type	Description	IIH	LSP	SNP
  22	TLV Accessibilité d'IS étendue	non	oui	non
134	TLV Identifiant de routeur d'ingénierie du trafic	non	oui	non
135	TLV Accessibilité IP étendue	non	oui	non

 	5.2	Nouveaux registres
IANA a créé les nouveaux registres suivants.

 	5.2.1	Sous TLV pour le TLV Accessibilité d'IS étendue
Ce registre contient les codets pour les sous TLV du TLV 22. La gamme des valeurs est 0 à 255. Les allocations dans le registre exigent la documentation de l'utilisation proposée de la valeur allouée et l'approbation de l'expert désigné alloué par l'IESG (voir la [RFC5226]).

En prenant en considération les allocations spécifiées dans le présent document, le registre a été initialisé comme suit :

Type	Description
0-2	non alloué
3	Groupe administratif (couleur)
4	Identifiants de liaison locale/distante
5	non alloué
6	Adresse d'interface IPv4
7	non alloué
8	Adresse de voisin IPv4
9	Bande passante maximum de liaison
10	Bande passante maximum de liaison réservable
11	Bande passante non réservée
12-17	non alloué
18	Métrique TE par défaut
19	Attributs de liaison
20	Type de protection de liaison
21	Descripteur de capacité de commutation d'interface
22	Contraintes de bande passante
23-249	non alloué
250-254	Réservé pour extensions spécifiques de Cisco
255	Réservé pour expansion future

 	5.2.2	Sous TLV pour le TLV Accessibilité IP étendue
Ce registre contient les codets pour les sous TLV du TLV 135. La gamme des valeurs est 0 à 255. Les allocations dans le registre exigent la documentation de l'utilisation proposée de la valeur allouée et l'approbation de l'expert désigné mandaté par l'IESG (voir la [RFC5226]). Aucun codet n'est défini dans ce document.

 	6.	Considérations sur la sécurité

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

 	7.	Remerciements

Les auteurs tiennent à remercier Yakov Rekhter et Dave Katz de leurs commentaires sur le présent document. Le présent travail a été financé en partie par Procket Networks et Juniper Networks.

 	8.	Références
 	8.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)

[RFC5302]	T. Li et autres, "Distribution de préfixe sur l'ensemble d'un domaine avec IS-IS à deux niveaux", octobre 2008. (Remplace RFC2966, MàJ RFC1195) (P.S.)

 	8.2	Références pour information
[ISIS-WG]	"IS-IS for IP Internets" <http://www.ietf.org/html.charters/isis-charter.html >

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

[RFC2702]	D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999. (Information)

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

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

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

 	Adresse des auteurs
Tony Li	Henk Smit	
Redback Networks, Inc.	mél : hhw.smit@xs4all.nl 	
300 Holger Way		
San Jose, CA  95134		
USA		
téléphone : +1 408 750 5160		
mél : tony.li@tony.li 		

 	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.