Groupe de travail Réseau	B. Thomas, Cisco Systems, Inc.	
Request for Comments : 5561	K. Raza, Cisco Systems, Inc.	
RFC mise à jour : 5036	S. Aggarwal, Juniper Networks	
Catégorie : Sur la voie de la normalisation	R. Aggarwal, Juniper Networks	
	JL. Le Roux, France Telecom	
Traduction Claude Brière de L'Isle	juillet 2009	

Capacités de LDP

Résumé
Un certain nombre d'améliorations au protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) ont été proposées. Certaines ont été mises en œuvre, et certaines avancent sur la voie de la normalisation. Il est probable que des améliorations supplémentaires seront proposées à l'avenir. Le présent document définit un mécanisme pour annoncer les améliorations de LDP au moment de l'initialisation de la session, ainsi qu'un mécanisme pour activer et désactiver les améliorations après l'établissement de la session LDP.

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.

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. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Conventions utilisées dans ce document	2
2. Mécanisme de capacité LDP	2
2.1 Document de capacité	3
3. Spécification de capacités dans les messages LDP	3
3.1 TLV de rétro compatibilité	4
4. Message Capability	4
5. Note sur la terminologie	4
6. Procédures pour les paramètres de capacité dans les messages d'initialisation	5
7. Procédures pour les paramètres de capacité dans les messages de capacité	5
8. Extensions au traitement des erreurs	5
9. TLV Annonce dynamique de capacité	6
10. Rétro compatibilité	6
11. Considérations sur la sécurité	6
12. Considérations relatives à l'IANA	6
13. Remerciements	7
14. Références	7
14.1 Références normatives	7
14.2 Références pour information	7
Adresse des auteurs	7

 	1.	Introduction

Un certain nombre d'améliorations à LDP comme spécifié dans la [RFC5036] ont été proposées. Cela inclut le redémarrage en douceur de LDP [RFC3478], LDP tolérant aux fautes [RFC3479], les extensions de diffusion groupée [MLDP], la signalisation des circuits de couche 2 [RFC4447], une méthode pour apprendre les étiquettes annoncées par les routeurs de prochain prochain bond à l'appui de la protection de réacheminement rapide de nœud [NNHOP], l'allocation d'étiquette amont [RFC6389], et les extensions pour la signalisation des chemins de commutation d'étiquettes inter-zones [RFC5283]. Certaines ont été mises en œuvre, et certaines avancent sur la voie de la normalisation. Il est aussi probable que des améliorations supplémentaires seront mises en œuvre et déployées à l'avenir.

Le présent document propose et définit un mécanisme pour annoncer les améliorations de LDP au moment de l'initialisation de session. Il définit aussi un mécanisme pour activer et désactiver ces améliorations après l'établissement de session LDP.

L'annonce de capacité LDP donne le moyen à un locuteur LDP d'annoncer ce qu'il peut recevoir et traiter. Elle donne aussi  le moyen à un locuteur d'informer ses homologues de divergences par rapport au comportement spécifié dans la [RFC5036]. Un exemple d'une telle divergence est le redémarrage en douceur de LDP, où un locuteur conserve l'état de transmission MPLS pour les LSP signalés par LDP quand son plan de contrôle LDP est défaillant. Il est important de souligner que toutes les améliorations de LDP n'exigent pas l'annonce de capacité. Par exemple, l'allocation d'étiquette amont exige l'annonce de capacité, mais le filtrage d'étiquette entrante, où un locuteur installe l'état de transmission pour seulement certaines classes d'équivalence de transmission (FEC, Forwarding Equivalence Classe) ne l'exige pas.

 	1.1	Conventions utilisées dans ce document
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].

Le présent document utilise les termes "locuteur LDP" et "locuteur" de façon interchangeable.

 	2.	Mécanisme de capacité LDP

Les améliorations vont probablement être annoncées durant l'établissement de session LDP lorsque chaque locuteur LDP annonce les capacités correspondant aux améliorations qu'il désire.

Au delà de cela, les annonces de capacité peuvent être utilisées pour modifier dynamiquement les caractéristiques de la session qui suit le changement de conditions. Par exemple, un LSR capable d'une amélioration particulière à l'appui d'une "caractéristique" ne peut pas avoir annoncé la capacité correspondante à son homologue au moment de l'établissement de session parce que la caractéristique était désactivée à ce moment. Plus tard, un opérateur peut activer la caractéristique, et le LSR va alors réagir en annonçant la capacité correspondante à son homologue. De même, quand un opérateur désactive un caractéristique associée à une capacité, le LSR réagit en retirant l'annonce de capacité provenant de son homologue.

Le mécanisme LDP d'annonce de capacité fonctionne comme suit :

-	Chaque locuteur LDP est supposé mettre en œuvre un ensemble d'améliorations, dont chacune a une capacité associée. À tout moment, un locuteur peut avoir aucune, une, ou plusieurs de ces améliorations "activée". Quand une amélioration est activée, le locuteur annonce la capacité associée à ses homologues. En annonçant la capacité à un homologue, le locuteur affirme qu'il va effectuer les actions de protocole spécifiées pour l'amélioration associée. Par exemple, les actions peuvent exiger que le locuteur LDP reçoive et traite des messages spécifiques de l'amélioration provenant de son homologue. Si la capacité n'a pas été annoncée, le locuteur ne va pas effectuer les actions de protocole spécifiées pour l'amélioration correspondante.

-	Au moment de l'établissement de session, un locuteur LDP PEUT annoncer une capacité particulière en incluant un paramètre facultatif associé à la capacité dans son message Initialisation.

-	Il y a une capacité bien connue appelée "annonce dynamique de capacité" qu'un locuteur LDP PEUT annoncer dans son message Initialisation pour indiquer qu'il est capable de traiter les annonces de capacité suite à un établissement de session.

Si un homologue a annoncé la capacité d'annonce dynamique de capacité dans son message Initialisation, alors à tout moment suivant l'établissement de session, un locuteur LDP PEUT annoncer des changements dans ses capacités annoncées à cet homologue. Pour ce faire, le locuteur LDP envoie à l'homologue un message Capability qui spécifie les capacités annoncées ou supprimées.

 	2.1	Document de capacité
Quand le mécanisme d'annonce de capacité est en place, une amélioration LDP exigeant une annonce de capacité LDP va être spécifiée par un document qui :
-	décrit le motif de l'amélioration ;
-	spécifie le comportement de LDP quand l'amélioration est activée. Cela inclut les procédures, paramètres, messages, et TLV requis par l'amélioration ;
-	inclut une section de considérations relatives à l'IANA qui demande à l'IANA l'allocation d'un codet (dans l'espace de noms de type de TLV) pour le paramètre facultatif de capacité correspondant à l'amélioration.

Le document de capacité DOIT aussi décrire l'interprétation et le traitement des données de capacité associées, si il en est.

 	3.	Spécification de capacités dans les messages LDP

Le présent document utilise le terme de"paramètre de capacité" pour se référer à un paramètre facultatif qui peut être inclus dans les messages Initialisation et Capacité pour annoncer une capacité.

Le format d'un TLV "Paramètre de capacité" est comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Codet de TLV              |          Longueur             |
+-+-+-----------+---------------+---------------+---------------+
|S| Réservé     |                                               |
+-+-------------+      Données de capacité                      |
|                                               +---------------+
|                                               |
+---------------+---------------+---------------+

où :

Bit U (bit de TLV inconnu) comme décrit dans la [RFC5036]. La valeur pourrait être 0 ou 1 comme spécifié dans le document de capacité associé à la capacité donnée.

Bit F (bit de TLV Transmission inconnue) comme décrit dans la [RFC5036]. La valeur de ce bit DOIT être 0 car un TLV Paramètre de capacité est envoyé seulement dans les messages Initialisation et Capacité, qui ne sont pas transmis.

Codet de TLV : type de TLV qui identifie une capacité spécifique. C'est un codet alloué par l'IANA (dans l'espace de noms de type de TLV) pour une capacité donnée comme demandé dans le document de capacité associé.

Bit S (bit État). Il indique si l'envoyeur annonce ou supprime la capacité correspondant au codet de TLV. La valeur du bit État est utilisée comme suit :
1 - le TLV annonce la capacité spécifiée par le codet de TLV.
0 - le TLV supprime la capacité spécifiée par le codet de TLV.

Données de capacité : informations, si il en est, sur la capacité en plus du codet de TLV, exigées pour spécifier pleinement la capacité. La méthode pour interpréter et traiter ces données est spécifique du codet de TLV et DOIT être décrite dans le document qui spécifie la capacité.

Un locuteur LDP NE DOIT PAS inclure plus d'une instance d'un paramètre de capacité (comme identifié par le même codet de TLV) dans un message Initialisation ou Capacité. Si un locuteur LDP reçoit plus d'une instance du même type de paramètre de capacité dans un message, il DEVRAIT envoyer un message Notification à l'homologue avant de terminer la session avec l'homologue. Le code d'état dans le TLV État du message Notification DOIT être la valeur "TLV mal formé", et le message DEVRAIT contenir le second TLV Paramètre de capacité du même type (codet) que reçu dans le message.

 	3.1	TLV de rétro compatibilité
Les extensions à LDP qui exigent l'annonce ou la négociation d'une certaine capacité au moment de l'établissement de la session utilisent normalement des TLV qui sont inclus dans un message Initialisation. Pour assurer la rétro compatibilité avec les mises en œuvre existantes, ces TLV continuent d'être pris en charge dans un message Initialisation et sont appelés dans le présent document des "TLV de rétro compatibilité". Un TLV de rétro compatibilité joue le rôle d'un TLV "paramètre de capacité" ; c'est-à-dire, la présence d'un TLV de rétro compatibilité a la même signification qu'un TLV "paramètre de capacité" avec le bit S établi pour la même capacité.

Un exemple de TLV de rétro compatibilité est le TLV "Session FT" qui est échangé dans un message Initialisation entre homologues pour annoncer la capacité de tolérance aux fautes de LDP [RFC3479].

 	4.	Message Capacité

Le message Capacité LDP est utilisé par un locuteur LDP pour annoncer des changements dans l'état de une ou plusieurs de ses capacités suite à l'établissement de session.

Le format du message Capacité est comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|      Capacité (0x0202)      |          Longueur             |
+-+-------------+---------------+---------------+---------------+
|                    Identifiant de message                     |
+---------------+---------------+---------------+---------------+
|                     TLV_1                                     |
+---------------+---------------+---------------+---------------+
|                     . . .                                     |
+---------------+---------------+---------------+---------------+
|                     TLV_N                                     |
+---------------+---------------+---------------+---------------+

où les TLV_1 à TLV_N sont les TLV de paramètre de capacité. Le bit S de chaque TLV spécifie le nouvel état pour la capacité correspondante.

Noter que les TLV de rétro compatibilité (voir le paragraphe 3.1) NE DOIVENT PAS être inclus dans les messages Capacité. Un locuteur LDP qui reçoit un message Capacité d'un homologue qui inclut des TLV de rétro compatibilité DEVRAIT les ignorer en silence et continuer de traiter le reste du message.

 	5.	Note sur la terminologie

Les sections qui suivent dans le présent document parlent de l'activation et de la désactivation de capacités. Les termes de "activer (ou désactiver) une capacité" sont une abréviation pour "annoncer (ou supprimer) une capacité associée à une amélioration". On se souvient que c'est une amélioration de LDP qui est activée ou désactivée, et que c'est la capacité correspondante qui est annoncée ou supprimée.

 	6.	Procédures pour les paramètres de capacité dans les messages d'initialisation

Le bit S d'un paramètre de capacité dans un message Initialisation DOIT être à 1 et DEVRAIT être ignoré à réception. Cela assure que tout paramètre de capacité dans un message Initialisation active la capacité correspondante.

Un locuteur LDP détermine les capacités d'un homologue en examinant l'ensemble de paramètres de capacité présents dans le message Initialisation reçu de l'homologue.

Un locuteur LDP PEUT utiliser une capacité particulière avec son homologue après que le locuteur a déterminé que l'homologue a activé cette capacité.

Ces procédures permettent au locuteur LDP S1, qui annonce une capacité LDP spécifique C, d'établir une session LDP avec le locuteur S2 qui n'annonce pas C. Dans cette situation, si la capacité C peut ou non être utilisée pour la session dépend de la signification de l'amélioration associée à C. Si elle n'exige pas que S1 et S2, s'annoncent tous deux C l'un à l'autre, alors S2 pourrait l'utiliser ; c'est-à-dire, l'annonce de C de S1 permet à S2 d'envoyer des messages à S1 qui utilisent l'amélioration.

Il est de la responsabilité du concepteur de la capacité de spécifier le comportement d'un locuteur LDP qui a activé une certaine amélioration, annoncé cette capacité et qui détermine que son homologue n'a pas annoncé la capacité correspondante. Le document qui spécifie les procédures pour la capacité DOIT décrire le comportement dans cette situation. Si la procédure spécifiée est de terminer la session, alors le locuteur LDP DEVRAIT envoyer un message Notification à l'homologue avant de terminer la session. Le code d'état dans le TLV État du message Notification DOIT être Capacité non prise en charge, et le message DEVRAIT contenir la capacité non prise en charge (voir les détails à la Section 8).

Un locuteur LDP qui prend en charge l'annonce de capacité et inclut un paramètre Capacité dans son message Initialisation DOIT régler le bit U du TLV à 0 ou 1, comme spécifié par le document de capacité. Le locuteur LDP devrait régler le bit U à 1 si le document de capacité lui permet de continuer avec un homologue qui ne comprend pas l'amélioration, et régler le bit U à 0 autrement. Si un locuteur reçoit un message contenant une capacité non prise en charge, il répond en accord avec le réglage du bit U dans le TLV. Si le bit U est à 1, le locuteur DOIT alors ignorer en silence le paramètre de capacité et permettre l'établissement de la session. Cependant, si le bit U est à 0, alors le locuteur DEVRAIT envoyer un message Notification à l'homologue avant de terminer la session. Le code d'état dans le TLV État du message Notification DOIT être Capacité non prise en charge, et le message DEVRAIT contenir la capacité non prise en charge (voir les détails à la Section 8).

 	7.	Procédures pour les paramètres de capacité dans les messages de capacité

Un locuteur LDP NE DOIT PAS envoyer un message Capacité à un homologue sauf si son homologue a annoncé la capacité d'annonce dynamique de capacité dans son message Initialisation de session. Un locuteur LDP PEUT envoyer un message Capacité à un homologue si son homologue a annoncé la capacité d'annonce dynamique de capacité dans son message Initialisation de session (voir la Section 9).

Un locuteur LDP détermine les capacités activées par un homologue en déterminant l'ensemble de capacités activées à l'initialisation de session (comme spécifié dans la Section 6) et en traquant les changements à cet ensemble faits par les messages Capacité provenant de l'homologue.

Un locuteur LDP qui a activé une capacité particulière PEUT utiliser l'amélioration correspondant à la capacité avec un homologue après que le locuteur a déterminé que l'homologue a activé la capacité.

 	8.	Extensions au traitement des erreurs

Le présent document définit un nouveau code d'état LDP nommé "Capacité non prise en charge". Le bit E du TLV "État" porté dans un message Notification qui inclut ce code d'état DOIT être réglé à 0.

De plus, le présent document définit un nouveau TLV LDP, nommé "TLV retournés", qui PEUT être porté dans un message Notification comme paramètre facultatif. Le réglage du bit U pour un TLV "TLV retournés" dans un message Notification DEVRAIT être 1, et le réglage du bit F DEVRAIT être 0.

Quand le code d'état dans un message Notification est "Capacité non prise en charge", le message DEVRAIT spécifier les capacités qui ne sont pas prises en charge. Quand le message Notification spécifie les capacités non prises en charge, il DOIT inclure un TLV "TLV retournés". Le TLV "TLV retournés" DOIT inclure seulement les paramètres de capacité pour les capacités non prises en charge, et le paramètre de capacité pour chacune de ces capacités DEVRAIT être codé comme reçu de l'homologue.

Quand le code d'état dans un message Notification est "TLV inconnu", le message DEVRAIT spécifier le TLV qui était inconnu. Quand le message Notification spécifie le TLV qui était inconnu, il DOIT inclure le TLV inconnu dans un TLV "TLV retournés".

 	9.	TLV Annonce dynamique de capacité

Le TLV Annonce dynamique de capacité est un paramètre de capacité défini par le présent document avec le format suivant :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Annonce DynCap (0x0506)   |          Longueur (1)         |
+-+-+-----------+---------------+---------------+---------------+
|1|  Réservé    |
+-+-------------+

La valeur du bit U pour le TLV "Paramètre d'annonce dynamique de capacité" DOIT être réglée à 1 afin qu'un receveur DOIVE l'ignorer en silence si il lui est inconnu, et continue de traiter le reste du message. Il n'y a pas de "données de capacité" associées à ce TLV et donc la longueur du TLV DOIT être réglée à 1.

Le paramètre d'annonce dynamique de capacité (DynCap) PEUT être inclus par un locuteur LDP dans un message Initialisation pour signaler à son homologue que le locuteur est capable de traiter les messages Capacité.

Un locuteur LDP NE DOIT PAS inclure le paramètre d'annonce dynamique de capacité dans les messages Capacité envoyés à ses homologues. Une fois activé durant l'initialisation de session, la capacité d'annonce dynamique de capacité ne peut pas être désactivée. Cela implique que le bit S est toujours à 1 pour l'annonce dynamique de capacité.

Un locuteur LDP qui reçoit un message Capacité d'un homologue qui inclut le paramètre Annonce dynamique de capacité DEVRAIT ignorer en silence le paramètre et traiter tous les autres paramètres de capacité dans le message.

 	10.	Rétro compatibilité

Du point de vue du mécanisme LDP d'annonce de capacité, un homologue conforme à la [RFC5036] a une distribution d'étiquettes pour IPv4 activée par défaut. Pour assurer la compatibilité avec un homologue conforme à la [RFC5036], les mises en œuvre de LDP qui prennent en charge l'annonce de capacité ont la distribution d'étiquettes pour IPv4 activée jusqu'à ce qu'elle soit explicitement désactivée et DOIVENT supposer qu'il en est de même pour leurs homologues.

Le paragraphe 3.1 introduit le concept de "TLV de rétro compatibilité" qui peuvent apparaître dans un message Initialisation dans le rôle d'un paramètre de capacité. Cela permet que les améliorations existantes de LDP qui utilisent un mécanisme ad hoc pour activer des capacités à l'initialisation de session continuent de le faire.

 	11.	Considérations sur la sécurité

La [RFC5920] décrit le cadre de sécurité pour les réseaux MPLS, tandis que la [RFC5036] décrit les considérations de sécurité qui s'appliquent à la spécification LDP de base. Le même cadre et considérations de sécurité s'appliquent au mécanisme de capacité décrit dans le présent document.

 	12.	Considérations relatives à l'IANA

Le présent document spécifie les codets suivants alloués par l'IANA :
-	codet message LDP pour le message Capacité (0x0202).
-	codet TLV LDP pour le TLV Annonce dynamique de capacité (0x0506).
-	codet TLV LDP pour le TLV "TLV retournés" (0x0304).
-	codet Code d'état LDP pour le code d'état "Capacité non prise en charge" (0x0000002E).

 	13.	Remerciements

Les auteurs tiennent à remercier Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, et Eric Rosen de leurs commentaires.

 	14.	Références
 	14.1	Références normatives

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

[RFC3479]	A. Farrel, éd., "Tolérance aux fautes dans le protocole de distribution d'étiquettes (LDP)", février 2003. (P.S.)

[RFC5036]	L. Andersson, I. Minei et B. Thomas, éditeurs, "Spécification de LDP", janvier 2001. (Remplace RFC3036) (MàJ par les RFC6720 , RFC6790, RFC7552,) (D.S)

 	14.2	Références pour information

[MLDP]	Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Travail en cours, avril 2009.

[NNHOP]	Shen, N., Chen, E., and A. Tian, "Discovery LDP Next-Nexthop Labels", Travail en cours, mai 2005.

[RFC3478]	M. Leelanivas, Y. Rekhter, R. Aggarwal, "Mécanisme de redémarrage en douceur pour le protocole de distribution d'étiquettes", février 2003. (P.S.)

[RFC4447]	L. Martini et autres, "Établissement et maintenance de pseudo filaires avec le protocole de distribution d'étiquettes", avril  2006. (MàJ par la RFC6723) (P.S. ; Remplacé par RFC8077 STD 84)

[RFC5283]	B. Decraene, JL. Le Roux, I. Minei, "Extension à LDP pour les chemins de commutation d'étiquette interzone (LSP)", juillet  2008. (P.S.)

[RFC6389]	R. Aggarwal, JL. Le Roux, "Allocation d’étiquette MPLS amont pour LDP", novembre 2011. (P.S.)

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

 	Adresse des auteurs

Bob Thomas	Shivani Aggarwal	Rahul Aggarwal	
Cisco Systems, Inc.	Juniper Networks	Juniper Networks	
1414 Massachusetts Ave.	1194 North Mathilda Ave.	1194 North Mathilda Ave.	
Boxborough, MA 01719	Sunnyvale, CA 94089	Sunnyvale, CA 94089	
mél : bobthomas@alum.mit.edu	mél : shivani@juniper.net	mél : rahul@juniper.net	

Jean-Louis Le Roux	Kamran Raza	
France Telecom	Cisco Systems, Inc.	
2, Avenue Pierre-Marzin	2000 Innovation Dr.	
22307 Lannion Cedex, France	Kanata, ON K2K 3E8, Canada	
mél : jeanlouis.leroux@orange-ftgroup.com	mél : skraza@cisco.com