Groupe de travail Réseau	JP. Vasseur, éditeur, Cisco Systems, Inc
Request for Comments : 5330	M. Meyer, BT
Catégorie : Sur la voie de la normalisation	K. Kumaki, KDDI R&D Labs
	A. Bonda, Telecom Italia
Traduction Claude Brière de L'Isle	octobre 2008

Sous TLV Type de liaison pour porter le nombre de chemins de commutation d'étiquettes à ingénierie du trafic signalés avec une réservation de bande passante de zéro à travers une liaison

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Résumé
Plusieurs sous TLV (Type-Longueur-Valeur) de type de liaison ont été définis pour les protocoles d’ouverture du plus court chemin en premier (OSPF, Open Shortest Path First) et de système intermédiaire à système intermédiaire (IS-IS, Intermediate System to Intermediate System) dans le contexte de l’ingénierie du trafic (TE, Traffic Engineering) de la commutation d’étiquette multi-protocoles (MPLS, Multiprotocol Label Switching) afin d’énoncer des caractéristiques de liaison telles que la bande passante disponible, la métrique d’ingénierie du trafic, le groupe administratif, et ainsi de suite. En faisant des hypothèses statistiques sur le trafic agrégé porté sur un ensemble de chemins de commutation d’étiquettes (LSP, Label Switched Path) TE signalés avec une bande passante de zéro (appelé un "LSP TE sans contrainte" dans ce document) des algorithmes peuvent être conçus pour équilibrer la charge des LSP TE sans contrainte (existants ou nouvellement configurés) à travers un ensemble de chemins de coût égal. Cela exige de connaître le nombre de LSP TE sans contrainte signalés sur une liaison. Le présent document spécifie un nouveau sous TLV Type de liaison d’ingénierie du trafic utilisé pour annoncer le nombre de LSP TE sans contrainte signalés sur une liaison.
Table des matières
1. Introduction	1
2. Terminologie	2
2.1 Langage des exigences	2
3. Extensions du protocole	2
3.1 IS-IS	3
3.2 OSPF	3
4. Éléments de procédure	3
5. Considérations relatives à l’IANA	3
6. Considérations sur la sécurité	3
7. Remerciements	4
8. Références	4
8.1 Références normatives	4
8.2 Références pour information	4
Adresse des auteurs	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Il n’est pas inhabituel de déployer l’ingénierie du trafic MPLS pour les besoins de récupération rapide, en s’appuyant sur un mécanisme de récupération de protection locale comme le réacheminement rapide MPLS TE (voir la [RFC4090]). Dans ce cas, un modèle de déploiement consiste à déployer un plein maillage de LSP TE signalés avec une bande passante de zéro (aussi appelé un LSP TE sans contrainte dans ce document) entre un ensemble de routeurs de commutation d’étiquettes (LSR, Label Switching Router) et en protégeant ces LSP TE contre les défaillances, de liaison, de groupe de liaisons à risque partagé (SRLG, Shared Risk Link Group) et/ou de nœud, avec des tunnels de sauvegarde préétablis. Le trafic acheminé sur de tels LSP TE sans contrainte suit simplement le plus court chemin IGP, mais est protégé par le réacheminement MPLS TE. C’est parce que le LSP TE calculé par l’algorithme de calcul de chemin (par exemple, CSPF) ne sera pas différent du plus court chemin du protocole de passerelle intérieure (IGP, Interior Gateway Protocol) si la métrique TE est égale à la métrique IGP.

Quand un processus de ré-optimisation est déclenché pour un LSP TE existant, la décision de ré-acheminer les LSP TE sur un chemin différent est gouvernée par la découverte d’un chemin de moindre coût qui satisfait les contraintes (d’autres métriques, comme le pourcentage de bande passante réservée ou le nombre de bonds, peuvent aussi être utilisées). Malheureusement, des métriques comme le coût du chemin ou le nombre de bonds peuvent être inefficaces dans diverses circonstances. Par exemple, dans le cas d’un réseau symétrique avec des chemins multiples de coût égal (ECMP, Equal Cost Multi-Paths) si l’opérateur du réseau utilise un LSP TE sans contrainte, cela peut conduire à un mauvais équilibrage de la charge du trafic  ; bien sûr, plusieurs chemins entre une source et une destination d’un LSP TE peuvent exister avec le même coût, et la quantité de bande passante réservable le long de chaque chemin ne peut pas être utilisée comme départage.

En faisant des hypothèses statistiques sur le trafic agrégé porté par un ensemble de LSP TE sans contrainte, des algorithmes peuvent être conçus pour équilibrer la charge (existante ou nouvellement configurée) des LSP TE sans contrainte à travers un ensemble de chemins de coût égal. Cela exige de savoir le nombre de LSP TE sans contrainte signalés sur chaque liaison.

Noter que la spécification d’algorithmes d’équilibrage de charge sort du domaine d’application du présent document et n’est mentionnée que pour illustrer les motifs de la collecte de telles informations.

De plus, la connaissance du nombre de LSP TE sans contrainte signalés sur chaque liaison peut être utilisée pour d’autres fins -- par exemple, pour évaluer le nombre de LSP TE sans contrainte affectés dans le cas de la défaillance d’une liaison.

Un ensemble de sous TLV de type Liaison a été défini pour OSPF et IS-IS (voir les [RFC3630] et [RFC5305]) dans le contexte de l’ingénierie du trafic MPLS afin d’annoncer diverses caractéristiques de liaison telles que la bande passante disponible, la métrique d’ingénierie du trafic, le groupe administratif, et ainsi de suite. Comme elles sont actuellement définies dans la [RFC3630] et la [RFC5305], les informations relatives au nombre de LSP TE sans contrainte ne sont pas disponibles. Le présent document spécifie un nouveau sous TLV Ingénierie du trafic de type Liaison utilisé pour indiquer le nombre de LSP TE sans contrainte signalés sur une liaison.

Les LSP TE sans contrainte qui sont configurés et provisionnés par un système de gestion PEUVENT être omis du compte rapporté.

 	2.	Terminologie

Terminologie utilisée dans ce document :
CSPF (Constrained Shortest Path First)  : plus court chemin contraint en premier
IGP (Interior Gateway Protocol)  : protocole de passerelle intérieure
LSA (Link State Advertisement)  : annonce d’état de liaison
LSP (Link State Packet)  : paquet d’état de liaison
MPLS (Multiprotocol Label Switching)  : commutation d’étiquettes entre protocoles multiples
LSR (Label Switching Router)  : routeur de commutation d’étiquettes
SRLG (Shared Risk Link Group)  : groupe de liaison à risques partagés
LSP TE (Traffic Engineering Label Switched Path)  : chemin de commutation d’étiquettes à ingénierie du trafic
LSP TE sans contrainte : LSP TE signalé avec une bande passante de 0.

 	2.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].

 	3.	Extensions du protocole

Deux sous TLV Compte de LSP TE sans contrainte sont définis pour spécifier le nombre de LSP TE signalés avec une bande passante de zéro sur une liaison.

 	3.1	IS-IS
Le sous TLV Compte de LSP TE sans contrainte IS-IS est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans le TLV Accessibilité IS étendue (type 22) spécifié dans la [RFC5305] ou le TLV Systèmes intermédiaires multi-topologies (MT) (type 222) spécifié dans la [RFC5120]. Si une seconde instance du sous TLV Compte de LSP TE sans contrainte est présente, le système receveur DOIT traiter seulement la première instance du sous TLV.

Le format du sous TLV Compte de LSP TE sans contrainte IS-IS est défini ci-dessous :
Type (1 octet) : 23
Longueur (1 octet) : 2
Valeur (2 octets) : nombre de LSP TE sans contrainte signalés sur la liaison.

 	3.2	OSPF
Le sous TLV Compte de LSP TE sans contrainte OSPF est FACULTATIF et NE DOIT PAS apparaître plus d’une fois dans le TLV Liaison (Type 2) qui est lui-même porté dans le LSA Ingénierie du trafic spécifié dans la [RFC3630] ou dans le LSA TE intra-zone OSPFv3 (code de fonction 10) défini dans la [RFC5329]. Si une seconde instance du sous TLV Compte de LSP TE sans contrainte OSPF est présente, le système receveur DOIT traiter seulement la première instance du sous TLV.

Le format du sous TLV compte de LSP TE sans contrainte OSPF est défini ci-dessous :
Type (2 octets) : 23
Longueur (2 octets) : 4
Valeur (4 octets) : nombre de LSP TE sans contrainte signalés sur la liaison.

 	4.	Éléments de procédure

L’absence du sous TLV Compte de LSP TE sans contrainte DEVRAIT être interprétée comme une absence d’informations sur la liaison.

Comme pour les autres caractéristiques de liaison à ingénierie du trafic MPLS, la génération de LSA/LSP déclenche des mécanismes qui sortent du domaine d’application du présent document. Il faut veiller à ne pas déclencher l’arrosage systématique d’un nouveau LSP IS-IS ou LSA OSPF avec une granularité trop élevée en cas de changement du nombre de LSP TE sans contrainte.

 	5.	Considérations relatives à l’IANA

L’IANA a défini un sous registre pour les sous TLV portés dans le TLV IS-IS 22 et a alloué un nouveau codet de TLV pour le sous TLV Compte de LSP TE sans contrainte au sein du TLV 22.

Valeur	Nom de TLV	Référence
   23	sous TLV Compte de LSP TE sans contrainte	RFC 5330

L’IANA a défini un sous registre pour les sous TLV portés dans un TLV Liaison TE OSPF (type 2) et a alloué un nouveau codet de sous TLV pour le sous TLV Compte de LSP TE sans contrainte porté dans le TLV Liaison TE.

Valeur	Nom de TLV	Référence
   23	sous TLV Compte de LSP TE sans contrainte	RFC 5330

 	6.	Considérations sur la sécurité

La fonction décrite dans le présent document ne crée pas de nouveau problème de sécurité pour les protocoles OSPF et IS-IS. Les considérations sur la sécurité sont couvertes dans les [RFC2328] et [RFC5340] pour le protocole OSPF de base et dans les [RFC1195] et [RFC5304] pour IS-IS.

Un cadre de sécurité pour MPLS et MPLS généralisé se trouve dans la [RFC5920].

 	7.	Remerciements

Les auteurs tiennent à remercier Jean-Louis Le Roux, Adrian Farrel, Daniel King, Acee Lindem, Lou Berger, Attila Takacs, Pasi Eronen, Russ Housley, Tim Polk, et Loa Anderson de leurs utiles apports.

 	8.	Références
 	8.1	Références normatives

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

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

[RFC2328]	J. Moy, "OSPF version 2", STD 54, avril 1998. (MàJ par la RFC6549, RFC8042, 9355)

[RFC3630]	D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 2003.

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

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

[RFC5329]	K. Ishiguro et autres, "Extensions d'ingénierie du trafic à OSPF version 3", septembre 2008. (P.S.)

[RFC5340]	R. Coltun et autres, "OSPF pour IPv6", juillet 2008. (P.S. ; Remplace RFC2740  ; MàJ par RFC8362)

 	8.2	Références pour information

[RFC4090]	P. Pan et autres, "Extensions de réacheminement rapide à RSVP-TE pour les tunnels de LSP", mai 2005. (P.S. ; MàJ par RFC8271, RFC8537, RFC8796)

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

[RFC5920]	L. Fang, "Cadre de sécurité pour réseaux MPLS et GMPLS", juillet 2010. (Information)

 	Adresse des auteurs

JP Vasseur (éditeur)	Matthew R. Meyer	Kenji Kumaki	Alberto Tempia Bonda	
Cisco Systems, Inc	BT	KDDI R&D Laboratories	Telecom Italia	
1414 Massachusetts Av.	Boston, MA	2-1-15 Ohara Fujimino	via G. Reiss Romoli 274	
Boxborough, MA  01719	USA	Saitama 356-8502, 	Torino,  10148	
USA	mél : matthew.meyer@bt.com	JAPAN	ITALIA	
mél : jpv@cisco.com		mél : ke-kumaki@kddi.com	alberto.tempiabonda@telecomitalia.it	

 	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 sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis 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, le IETF TRUST 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 encloses ne viole 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 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 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 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.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).