Groupe de travail Réseau	F. Le Faucheur & R. Uppili, Cisco Systems, Inc.	
Request for Comments : 3785	A. Vedrenne é  P. Merckx, Equant	
BCP : 87	T. Telkamp, Global Crossing	
Catégorie : Bonnes pratiques actuelles	mai 2004 	
Traduction Claude Brière de  L'Isle		

Utilisation de la métrique du protocole de passerelle intérieure (IGP) comme seconde métrique de l'ingénierie du trafic MPLS

Statut de ce mémoire
Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2004).

Résumé
Le présent document décrit la pratique courante de la façon dont la métrique existante des protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) peut être utilisée comme métrique de remplacement de la métrique d'ingénierie du trafic (TE, Traffic Engineering) pour l'acheminement fondé sur la contrainte des tunnels de l'ingénierie de trafic en commutation d'étiquettes multi protocoles (MPLS, MultiProtocol Label Switching). Il en résulte une capacité efficace d'effectuer l'acheminement fondé sur la contrainte avec l'optimisation d'une métrique (par exemple, la bande passante de la liaison) pour certains tunnels d'ingénierie du trafic (par exemple, des circuits de données) tout en optimisant une autre métrique (par exemple, le délai de propagation) pour certains autres tunnels avec des exigences différentes (par exemple, des circuits vocaux). Aucune extension ni modification de protocole n'est exigée. Le présent texte documente les pratiques actuelles de mise en œuvre et de déploiement de routeurs.

1.	Introduction
Les protocoles d'acheminement (OSPF et IS-IS) du protocole de passerelle intérieure (IGP, Interior Gateway Protocol) ainsi que les protocoles de signalisation (RSVP-TE et CR-LDP) de commutation d'étiquettes multi protocoles (MPLS, MultiProtocol Label Switching) ont été étendus (comme spécifié dans les [RFC3784], [RFC3630], [RFC3209] et [RFC3212]) afin de prendre en charge la fonctionnalité d'ingénierie du trafic (TE, Traffic Engineering) définie dans la [RFC2702].

Ces extensions de protocole d'acheminement IGP incluent actuellement des annonces d'une seule métrique supplémentaire de TE MPLS à utiliser pour l'acheminement fondé sur la contrainte des tunnels d'ingénierie du trafic.

Cependant, l'objectif de l'ingénierie du trafic est d'optimiser l'utilisation et les performances du réseau. Il semble donc pertinent que le placement de tunnel TE puisse être optimisé selon différents critères d'optimisation. Par exemple, certains fournisseurs de services veulent effectuer séparément l'ingénierie du trafic de différentes classes de service afin que chaque classe de service soit transportée sur un tunnel TE différent. Un exemple de motivation de ce comportement est d'appliquer des politiques différentes de restauration rapide aux différentes classes de service. Un autre exemple de motivation est de tirer parti d'un acheminement fondé sur la contrainte différent afin de satisfaire les différents objectifs de qualité de service (QS) de chaque classe de service. Selon les objectifs de QS, on peut exiger soit (a) l'application par l'acheminement fondé sur la contrainte de différentes contraintes de bande passante pour les différentes classes de service définies dans [DS-TE], soit (b) d'optimiser sur une métrique différente durant l'acheminement fondé sur la contrainte, soit (c) les deux. Le présent document expose comment l'optimisation sur une métrique différente peut être réalisée durant l'acheminement fondé sur la contrainte.

Le scénario le plus courant pour une métrique différente invoque l'optimisation d'une métrique qui reflète le délai (principalement le délai de propagation) lorsque des chemins commutés par étiquettes (LSP, Label Switched Path) d'ingénierie du trafic d'acheminement fondé sur la contrainte vont transporter de la voix, tout en optimisant avec une métrique plus usuelle (par exemple, reflétant la bande passante de liaison) pour des LSP de TE d'acheminement fondé sur la contrainte qui vont transporter des données.

Des extensions de protocole IGP supplémentaires pourraient être définies afin que plusieurs métriques de TE puissent être annoncées dans l'IGP (comme proposé, par exemple, dans [METRICS]) et seraient ainsi disponibles pour l'acheminement fondé sur la contrainte afin d'optimiser sur une métrique différente. Cependant, le présent document décrit comment optimiser sur une métrique différente peut être réalisé aujourd'hui par les mises en œuvre et déploiements existants sans aucune extension d'IGP supplémentaire au delà des [RFC3784] et [RFC3630], en utilisant effectivement la métrique IGP comme "seconde" métrique de TE.

2.	Pratiques actuelles

Dans les déploiements actuels de TE MPLS, les administrateurs de réseau veulent souvent qu'un acheminement fondé sur la contrainte des LSP TE qui portent du trafic de données soit fondé sur la même métrique que celle utilisée pour l'acheminement de plus court chemin. Lorsque c'est le cas, cette pratique permet que l'algorithme d'acheminement fondé sur la contrainte qui fonctionne sur le LSR d'extrémité de tête utilise la métrique IGP annoncée dans l'IGP pour calculer les chemins pour les LSP TE de données au lieu de la métrique de TE annoncée. La métrique de TE peut alors être utilisée pour porter une autre métrique (par exemple, une métrique fondée sur le retard) qui peut être utilisée par l'algorithme d'acheminement fondé sur la contrainte sur le LSR d'extrémité de tête pour calculer le chemin pour les LSP TE avec des exigences différentes (par exemple, un LSP TE vocal).

Dans certains réseaux, les administrateurs configurent la métrique d'IGP à une valeur qui met en facteurs le délai de propagation de la liaison. Dans ce cas, cette pratique permet à l'algorithme d'acheminement fondé sur la contrainte qui fonctionne sur le LSR d'extrémité de tête d'utiliser la métrique d'IGP annoncée dans l'IGP pour calculer les chemins pour les LSP de TE sensibles au retard (par exemple, les LSP TE vocaux) au lieu de la métrique de TE annoncée. La métrique de TE peut alors être utilisée pour porter une autre métrique (par exemple, une métrique fondée sur la bande passante) qui peut être utilisée par l'algorithme d'acheminement fondé sur la contrainte pour calculer les chemins pour les LSP TE de données.

Plus généralement, la métrique de TE peut être utilisée pour porter toute métrique arbitraire qui peut être utile pour l'acheminement fondé sur la contrainte de l'ensemble de LSP qui a besoin d'optimisation sur une autre métrique que celle d'IGP.

2.1	Pratique de mise en œuvre de LSR d'extrémité de tête
Un LSR d'extrémité de tête met en œuvre la pratique courante en :
(i)	permettant la configuration, pour chaque LSP TE à acheminer, de si la métrique IGP ou la métrique de TE est à utiliser par l'algorithme d'acheminement fondé sur la contrainte ;
(ii)permettant que l'algorithme d'acheminement fondé sur la contrainte utilise la métrique de TE ou la métrique d'IGP, selon la configuration ci-dessus pour le LSP TE considéré.

2.2	Pratique de déploiement de réseau
Un fournisseur de service déploie cette pratique en :
(i)	configurant, sur chaque liaison pertinente, la métrique de TE pour refléter la métrique appropriée (par exemple, métrique fondée sur le retard) pour l'acheminement fondé sur la contrainte de certains LSP comme métrique de remplacement de la métrique d'IGP ;
(ii)	configurant, pour chaque LSP TE, si ce LSP est à acheminer sur la base de la contrainte selon la métrique de TE ou selon la métrique d'IGP

2.3	Contraintes
La pratique décrite dans le présent document a les contraintes suivantes :

(i)	elle permet seulement que les). Des extensions (par exemple comme celles proposées dans [METRICS]) pourraient être définies à l'avenir si nécessaire pour relâcher cette contrainte, mais ceci sort du domaine d'application du présent document.

(ii)	elle ne peut être utilisée que lorsque la métrique IGP est appropriée comme une des deux métriques à utiliser pour l'acheminement fondé sur la contrainte (c'est-à-dire, elle ne peut pas permettre que les tunnels TE soient acheminés sur une des deux métriques tout en permettant que SPF IGP se fonde sur une troisième métrique). Des extensions (par exemple telles que celles proposées dans [METRICS]) pourraient être définies à l'avenir si nécessaire pour relâcher ces contraintes, mais ceci sort du domaine d'application du présent document.

(iii)	elle peut seulement être utilisée sur des liaisons qui prennent en charge une adjacence IGP afin qu'une métrique IGP soit bien annoncée pour la liaison. Par exemple, cette pratique ne peut pas être utilisée sur les adjacences de transmission (voir la [RFC4206]).

Noter que, comme avec [METRICS], cette pratique ne recommande pas que la métrique de TE et la métrique IGP soient utilisées simultanément durant le calcul de chemin pour un certain LSP. Ceci est connu comme étant un problème complet de NP.

2.4	Interopérabilité
Lorsque le calcul de chemin est entièrement effectué par l'extrémité de tête (par exemple, opérations intra zone avec calcul de chemin sur l'extrémité de tête) cette pratique ne soulève pas de problème d'interopérabilité entre les LSR car l'utilisation d'une métrique ou de l'autre est une affaire purement locale pour le LSR d'extrémité de tête.

Lorsque le calcul de chemin implique un autre composant que l'extrémité de tête (par exemple, avec des opérations inter zones où le calcul de chemin est partagé entre l'extrémité de tête et les routeurs de bordure de zone ou un serveur de calcul de chemin) cette pratique exige que la métrique sur laquelle s'optimiser soit signalée avec les autres contraintes (bande passante, affinité) pour le LSP. Voir dans la [RFC5152] un exemple proposé sur la façon de signaler sur quelle métrique optimiser, pour un autre composant impliqué dans le calcul de chemin lorsque RSVP-TE est utilisé comme protocole pour signaler les informations de calcul de chemin.

3.	Considérations de migration

Les fournisseurs de services ont besoin de considérer comment migrer de la mise en œuvre actuelle à la nouvelle qui prend en charge cette pratique.

Bien que les routeurs d'extrémité de tête agissent indépendamment les uns des autres, certains scénarios de migration peuvent exiger que tous les routeurs d'extrémité de tête soient mis à niveau avec la nouvelle mise en œuvre pour éviter toute interruption des LSP TE existants avant que deux métriques puissent effectivement être utilisées par la TE. La raison en est que les routeurs qui ont la mise en œuvre actuelle sont supposés utiliser toujours la métrique de TE pour l'acheminement fondé sur la contrainte de tous les tunnels, de sorte que lorsque la métrique de TE est reconfigurée pour refléter la "seconde métrique" (disons pour une métrique fondée sur le retard) sur les liaisons du réseau, alors tous les LSP TE vont se trouver acheminés sur la base de la "seconde métrique", alors que l'intention peut être que seuls les LSP TE explicitement configurés ainsi devraient être acheminés sur la base de la "seconde métrique".

Un scénario de migration possible pourrait ressembler à ceci :

1)	mettre à niveau le logiciel sur tous les routeurs d'extrémité de tête dans le réseau pour prendre en charge cette pratique,

2)	change la configuration de LSP TE sur les routeurs d'extrémité de tête pour utiliser la métrique de IGP (par exemple, fondée sur la bande passante) pour l'acheminement fondé sur la contrainte plutôt que sur la métrique TE,

3)	configurer la métrique TE sur les liaisons pour refléter la "seconde métrique" (par exemple, fondée sur le retard),

4)	modifier la configuration de LSP du sous ensemble de LSP TE qui a besoin d'être acheminé sur la base de la contrainte en utilisant la "seconde métrique" (par exemple, fondée sur le retard) et/ou créer de nouveaux LSP TE avec une telle configuration.

Il est souhaitable que l'étape 2 soit non interruptive (c'est-à-dire, que l'acheminement d'un LSP ne soit affecté d'aucune façon, et que la transmission des données ne soit pas interrompue) par le changement de configuration du LSP à utiliser la "métrique IGP" pour autant que la valeur réelle de la "métrique IGP" et de la "métrique de TE" soient égales sur chaque liaison au moment de la reconfiguration de LSP (comme ce serait le cas à l'étape 2 dans le scénario de migration ci-dessus qui suppose que la métrique de TE était initialement égale à la métrique IGP).

4.	Considérations sur la sécurité

Les pratiques décrites dans le présent document ne soulèvent pas de problèmes de sécurité spécifiques au delà de ceux qui existent pour l'ingénierie du trafic. Ceux-ci sont discutés dans les sections sur la sécurité respectivement des [RFC2702], [RFC3209] et [RFC3212].

5.	Remerciements

Le présent document a bénéficié de discussions avec Jean-Philippe Vasseur.

6.	Références
6.1	Références normatives

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

[RFC3209]	D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

[RFC3660]	B. Foster, F. Andreasen, "Paquetages de base du protocole de contrôle de passerelle de support (MGCP)", décembre  2003. (MàJ RFC2705) (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)

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

6.2	Références pour information

[METRICS]	Fedyk, et al., "Multiple Metrics for Traffic Engineering with IS-IS and OSPF", Travail en cours, novembre  2000.

[RFC3564]	F. Le Faucheur, W. Lai, "Exigences pour la prise en charge de l'ingénierie de trafic MPLS capable de services différenciés", juillet 2003. (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.)

[RFC5152]	JP. Vasseur et autres, "Méthode de calcul de chemin par domaine pour établir des chemins de commutation d'étiquettes (LSP) à ingénierie du trafic inter domaine", février 2008. (P.S.)

7.	Adresse des auteurs

Francois Le Faucheur	Ramesh Uppili	Alain Vedrenne	
Cisco Systems, Inc.	Cisco Systems,	Equant	
Village d'Entreprise Green Side - Batiment T3	2000 Innovation Drive	Heraklion, 1041 route des Dolines, BP347	
400, Avenue de Roumanille	Kanata,	06906 Sophia Antipolis Cedex	
06410 Biot-Sophia Antipolis	ONTARIO,	France	
France	Canada - K2K 3E8	téléphone : +33 4 92 96 57 22	
téléphone : +33 4 97 23 26 19	téléphone : 01-613-254 4578	mél : alain.vedrenne@equant.com 	
mél : flefauch@cisco.com 	mél : ruppili@cisco.com 		

Pierre Merckx	Thomas Telkamp	
Equant	Global Crossing, Ltd.	
1041 route des Dolines - BP 347	Croeselaan 148	
06906 SOPHIA ANTIPOLIS Cedex	NL-3521CG Utrecht	
France	The Netherlands	
téléphone : +33 (0)492 96 6454	téléphone : +31 30 238 1250	
mél : pierre.merckx@equant.com 	mél : telkamp@gblx.net 	

8.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004).

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

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.