Groupe de travail Réseau	B. Decraene, France Telecom
Request for Comments : 5283	JL. Le Roux, France Telecom
Catégorie : Sur la voie de la normalisation	I. Minei, Juniper Networks, Inc.
Traduction Claude Brière de L'Isle	juillet 2008

Extension LDP pour chemins d’étiquettes commutés (LSP) inter-zones

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é
Pour faciliter l’établissement de chemins de commutation d’étiquettes (LSP, Label Switched Path) qui pourraient s’étendre sur plusieurs zones IGP dans un système autonome (AS, Autonomous System) donné, le présent document décrit une nouvelle procédure facultative de transposition d’étiquette de plus longue correspondance pour le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol).

Cette procédure permet l’utilisation d’une étiquette si l’élément Classe d’équivalence de transmission (FEC, Forwarding Equivalence Class) correspond à une entrée dans la base d’informations d’acheminement (RIB, Routing Information Base). La correspondance est définie par une recherche de plus longue correspondance IP et ne rend pas obligatoire une correspondance exacte.
Table des matières
1. Introduction	1
2. Conventions utilisées dans ce document	2
3. Terminologie	2
4. Position du problème	2
5. Procédure de transposition d’étiquette de plus longue correspondance	3
6. Exemples d’application	4
6.1 LSP inter-zones	4
6.2 Utilisation de chemins statiques	5
7. Avertissements pour le déploiement	5
7.1 Considérations de déploiement 	5
7.2 Considérations sur le temps de convergence d’acheminement 	6
8. Considérations sur la sécurité	6
9. Références	7
9.1 Références normatives	7
9.2 Références pour information	7
10. Remerciements	7
Adresse des auteurs	7
Déclaration complète de droits de reproduction	8

 	1.	Introduction

Les protocoles de passerelle intérieure (IGP, Interior Gateway Protocol) d’état de liaison tels que OSPF [RFC2328] et IS-IS [RFC1195] permettent la partition d’un système autonome en zones ou en niveaux afin d’accroître l’adaptabilité de l’acheminement au sein d’un domaine d’acheminement.

Cependant, la [RFC5036] recommande que l’adresse IP de l’élément FEC devrait correspondre *exactement* à une entrée dans la base de données d’informations d’acheminement (RIB, Routing Information Base) IP. En accord  avec la [RFC5036], paragraphe 3.5.7.1 ("Procédures des messages de transposition d’étiquettes") :

Un routeur de commutation d’étiquettes (LSR, Label Switching Router) qui reçoit un message de transposition d’étiquette d’un LSR en aval pour un préfixe NE DEVRAIT PAS utiliser l’étiquette pour transmettre sauf si son tableau d’acheminement contient une entrée qui correspond exactement à l’élément FEC.

Donc, les LSP MPLS entre les routeurs d’étiquette de bordure (LER, Label Edge Router) dans les différentes zones/niveaux ne sont pas établis sauf si les adresses spécifiques de retour (par exemple, /32 pour IPv4) de tous les LER sont redistribuées à travers toutes les zones.

La position du problème est discutée à la section 4. Ensuite, la section 5 étend la procédure de transposition d’étiquette définie dans la [RFC5036] afin de prendre en charge l’établissement de LSP inter-zones contigus tout en conservant l’agrégation de préfixes IP sur les ABR. Cela consiste à permettre la transposition d’étiquette fondée sur la plus longue correspondance.

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

 	3.	Terminologie

Zone IGP : zone OSPF ou niveau IS-IS.

ABR (Area Border Router) : routeur de bordure de zone OSPF ou routeur IS-IS de couche 1/2.

LSP (Label Switched Path) : chemin de commutation d’étiquettes.

LSP intra-zone : LSP qui ne traverse aucune frontière de zone IGP.

LSP inter-zones : LSP qui traverse au moins une frontière de zone IGP.

 	4.	Position du problème

Les réseaux de commutation d’étiquettes multi-protocoles (MPLS, Multiprotocol Label Switching) fondés sur le fournisseur s’étendent avec le succès des réseaux privés virtuels de couche 3 [RFC4364] et les nouveaux déploiements de VPN de couche 2 ([RFC4761], [RFC4762]). Les cœurs de réseau MPLS des fournisseurs de services connaissent une croissance significative à la fois en termes de densité avec l’ajout des routeurs côté fournisseur (PE, Provider Edge) pour connecter de nouveaux consommateurs et en termes d’empreinte lorsque les réseaux traditionnels d’agrégation de couche 2 peuvent être remplacés par des réseaux IP/MPLS. Par conséquent, de nombreux fournisseurs doivent introduire des zones IGP. Des LSP inter-zones (c’est-à-dire, des LSP qui traversent au moins deux zones IGP) sont nécessaires pour assurer la connexité MPLS entre les PE situés dans des zones IGP distinctes.

Pour établir les LSP MPLS requis entre les PE dans les différentes zones IGP, les fournisseurs de service ont actuellement deux solutions : 1) LDP avec échappement de chemin IGP, 2) BGP [RFC3107] sur LDP avec hiérarchie MPLS, et 3) protocole de réservation de ressources avec ingénierie du trafic (RSVP-TE, Resource Reservation Protocol-Traffic Engineering) [RFC5151] inter-zones.

L’échappement de chemin IGP consiste en la redistribution de toutes les adresses de retour spécifiques de PE à travers les frontières de zone. Par suite, LDP trouve dans la RIB une correspondance exacte pour sa FEC et établit le LSP. Par conséquent, l’avantage potentiel qu’un domaine multi-zones peut donner est significativement diminué parce que beaucoup d’adresses doivent être redistribuées par les ABR, et le nombre des entrées IP dans la base de données d’état de liaison (LSDB, Link State Database) IGP, RIB, et la base de données d’informations de transmission (FIB, Forwarding Information Base) conservées par chaque LSR du domaine (quel que soit la zone/niveau auquel elles appartiennent) ne peut pas être minimisé.

Les fournisseurs de service peuvent aussi établir des LSP inter-zones en utilisant la hiérarchie MPLS avec BGP [RFC3107] comme protocole de distribution d’étiquettes entre les zones. Le prochain bond BGP va normalement être les ABR, et les LSP créés par BGP vont être incorporés dans les LSP intra-zone établis par LDP entre les PE et les ABR et entre les ABR.

Cette solution n’est pas adéquate pour les fournisseurs de service qui ne veulent pas faire fonctionner BGP sur leurs routeurs parce qu’elle exige BGP sur tous les ABR. De plus, la hiérarchie MPLS ne permet pas de protéger localement le LSP contre les défaillances d’ABR (réacheminement rapide IP/LDP) et donc d’assurer une récupération de moins de 50  ms en cas de défaillance d’ABR. Le temps de convergence résultant peut n’être pas acceptable pour les accords de niveau de service (SLA, Service Level Agreement) stricts exigés pour les applications vocales ou de mission critique. Finalement, cette solution exige un effort de migration significatif pour les fournisseurs de service qui ont commencé avec LDP et un échappement d’acheminement IGP pour établir rapidement les premiers LSP inter-zones.

Les fournisseurs de service peuvent aussi établir ces LSP inter-zones en utilisant RSVP-TE [RFC5151] inter-zones. C’est une solution pertinente quand RSVP-TE est déjà utilisé pour établir des LSP intra-zone, et que des caractéristiques d’ingénierie du trafic inter-zones sont nécessaires. Cependant, ce n’est pas une solution désirable quand LDP est déjà utilisé pour établir des LSP intra-zone, et que des caractéristiques d’ingénierie du trafic inter-zones ne sont pas exigées.

Pour éviter ces inconvénients, il est besoin d’une solution fondée sur LDP qui permette d’établir des LSP inter-zones contigus tout en évitant la fuite d’adresses de retour spécifiques de PE à travers les frontières de zone, conservant ainsi les bénéfices de la hiérarchie BGP.

Dans ce contexte, le présent document définit une nouvelle procédure de transposition d’étiquette LDP afin de prendre en charge l’établissement de LSP inter-zones contigus tout en conservant l’agrégation de préfixe IP sur les ABR. Cette procédure est similaire à celle définie dans la [RFC5036] mais effectue une plus longue correspondance IP lors de la recherche de l’élément FEC dans la RIB.

 	5.	Procédure de transposition d’étiquette de plus longue correspondance

Le présent document définit une nouvelle procédure de transposition d’étiquette pour la [RFC5036]. Elle est applicable aux éléments FEC de préfixe IPv4 et IPv6 (familles d’adresses 1 et 2 selon le registre "Numéros de famille d’adresses" sur le site de l’IANA). Il DEVRAIT être possible d’activer/désactiver cette procédure par configuration, et elle DEVRAIT être désactivée par défaut. Il PEUT être possible de l’activer par préfixe.

Avec cette nouvelle procédure de transposition d'étiquette de plus longue correspondance, un LSR recevant un message Transposition d’étiquette d’un LSR voisin pour un élément FEC de préfixe d’adresse FEC1 DEVRAIT utiliser l’étiquette pour la transmission MPLS si son tableau d’acheminement contient une entrée correspondant à l’élément de FEC FEC1 et si le LSR annonceur est un prochain bond pour atteindre FEC1. Si il en est ainsi, il DEVRAIT annoncer l’élément de FEC FEC1 reçu et une étiquette à ses homologues LDP.

Par "élément de FEC correspondant", on doit comprendre une plus longue correspondance IP. C’est-à-dire, soit l’élément de FEC LDP correspond exactement à une entrée dans la RIB IP, soit l’élément FEC est un sous ensemble d’une entrée de RIB IP. Il n’y a pas de correspondance dans les autres cas (c’est-à-dire, si l’élément de FEC est un sur-ensemble d’une entrée de RIB, il n’est pas considéré correspondre).

Noter que LDP ré-annonce à ses homologues l’élément de FEC spécifique FEC1, et non le préfixe agrégé trouvé dans la RIB IP durant la recherche de plus longue correspondance.

Noter qu’avec cette procédure de transposition d'étiquette de plus longue correspondance, chaque LSP établi par LDP suit quand même strictement le ou les plus courts chemins définis par l’IGP.

Les FEC choisies par cette procédure de transposition d'étiquette de plus longue correspondance sont distribuées de façon ordonnée. En cas de défaillance de LER, la suppression de l’accessibilité à la FEC se fait en utilisant les procédures ordonnées par LDP du mode de distribution d’étiquettes. Comme défini dans la [RFC5036] au paragraphe A.1.5, la FEC va être supprimée de façon ordonnée par la propagation de messages Suppression d’étiquette. L’utilisation de ces informations d’inaccessibilité par les couches d’application en utilisant ce LSP MPLS (par exemple, la [RFC4760]) sort du domaine d’application du présent document.

Selon la [RFC5036], LDP a déjà des interactions avec la RIB. En particulier, il doit avoir connaissance des événements suivants :
- augmenter le préfixe quand un nouveau préfixe IP apparaît dans la RIB,
- diminuer le préfixe quand un préfixe IP existant disparaît,
- changement de prochain bond quand un préfixe IP existant a un nouveau prochain bond suite à un changement d’acheminement.

Avec cette procédure de message de transposition d’étiquette de plus longue correspondance, plusieurs FEC peuvent être concernées par un seul changement de préfixe de RIB. Le LSR DOIT vérifier toutes les FEC qui sont un sous ensemble de ce préfixe de RIB. Ainsi, certaines réactions de LDP suite à un événement de RIB sont changées :

-	Quand un nouveau préfixe apparaît dans la RIB, le LSR DOIT vérifier si ce préfixe est une meilleure correspondance pour certaines FEC existantes. Par exemple, les éléments de FEC 192.0.2.1/32 et 192.0.2.2/32 utilisés dans l’entrée de RIB IP 192.0.2.0/24, et une nouvelle entrée de RIB IP plus spécifique 192.0.2.0/26 apparaît. Il peut en résulter un changement du LSR utilisé comme prochain bond et donc de l’entrée de transmission d’étiquette de prochain bond (NHLFE, Next Hop Label Forwarding Entry) pour cette FEC.

-	Quand un préfixe disparaît dans la RIB, le LSR DOIT vérifier tous les éléments de FEC qui utilisent ce préfixe de RIB comme meilleure correspondance. Pour chaque FEC, si un autre préfixe de RIB est trouvé comme meilleure correspondance, LDP DOIT l’utiliser. Il peut en résulter le changement du LSR utilisé comme prochain bond et donc de la NHLFE pour cette FEC. Autrement, le LSR DOIT supprimer le lien de FEC et envoyer un message Suppression d’étiquette.

-	Quand le prochain bond d’un préfixe de RIB change, le LSR DOIT changer la NHLFE de tous les éléments de FEC qui utilisent ce préfixe.

Des travaux futurs pourraient définir de nouveaux objets de gestion pour les modules de MIB de LDP MPLS [RFC3815] pour activer/désactiver cette procédure de message de transposition d’étiquette de plus longue correspondance, éventuellement sur la base du préfixe.

 	6.	Exemples d’application
 	6.1	LSP inter-zones
Considérons l’exemple suivant d’un système autonome avec une zone de cœur et deux zones bordures :

                        Zone "B"
                 Niveau 2 / zone de cœur
              +--------------------------+
     Zone "A" |                          |  Zone "C"
              |                          |
     Niveau 1 |                          |  Niveau 1 / zone
              |        P1                |
   +----------+                          +-------------+
   |          |                 P2       |         PE1 | 192.0.2.1/32
   |          |                          |             |
   |PE4      ABR2                       ABR1       PE2 | 192.0.2.2/32
   |          |        P3                |             |
   |          |                          |         PE3 | 192.0.2.3/32
   +----------+                          +-------------+
              |                          |
              +--------------------------+

Figure 1 : Domaine IGP avec deux zones rattachées à la zone de cœur

Noter que cela s’applique également à IS-IS et OSPF. Un ABR se réfère ici à un ABR OSPF ou à un nœud IS-IS de couche  1/2.

Tous les routeurs sont à capacité MPLS, et la connexité MPLS (c’est-à-dire, un LSP) est exigé entre tous les routeurs PE.

Dans la zone de "sortie" "C", les enregistrements disponibles sont :

RIB IGP	Éléments de FEC LDP 
192.0.2.1/32	192.0.2.1/32
192.0.2.2/32	192.0.2.2/32
192.0.2.3/32	192.0.2.3/32

Le routeur de bordure de zone ABR1 annonce la zone de cœur :
- le préfixe IP agrégé 192.0.2.0/26 dans l’IGP
- tous les éléments spécifiques de FEC IP (/32) dans LDP

Dans la zone "cœur" "B", les enregistrements disponibles sont :

RIB IGP	Éléments de FEC LDP 
192.0.2.0/26	192.0.2.1/32
	192.0.2.2/32
	192.0.2.3/32

Le routeur de bordure de zone ABR2 annonce dans la zone "A" :
- un préfixe IP agrégé 192.0.2.0/24 dans l’IGP
- tous les éléments individuels de FEC IP (/32) dans LDP

Dans la zone "d’entrée" "A", les enregistrements disponibles sont :

RIB IGP	Éléments de FEC LDP 
192.0.2.0/24	192.0.2.1/32
	192.0.2.2/32
	192.0.2.3/32

Dans cette situation, un LSP est établi entre le PE4 d’entrée et chaque PE de sortie de la zone C tout en conservant l’agrégation de préfixe IP sur les ABR.

 	6.2	Utilisation de chemins statiques
Considérons l’exemple suivant où un LER est en connexion double avec deux LSR :

                              +--------LSR1----
                              |         |
                             LER        |
                              |         |
                              +--------LSR2----

Figure 2 : LER en connexion double avec deux LSR

Dans certaines situations, en particulier à la bordure du réseau, il est valide d’utiliser des chemins IP statiques entre le LER et les deux LSR. Si nécessaire, le protocole de détection de transmission bidirectionnelle [RFC5880] peut être utilisé pour détecter rapidement la perte de connexité.

La spécification LDP définie dans la [RFC5036] exigerait sur le LER d’entrée la configuration et le maintien d’un chemin IP par LER de sortie et par interface sortante.

La procédure de transposition d'étiquette de plus longue correspondance décrite dans le présent document exige seulement un chemin IP par interface sortante.

 	7.	Avertissements pour le déploiement
 	7.1	Considérations de déploiement 
Les LSR conformes au présent document sont rétro-compatibles avec les LSR qui se conforment à la [RFC5036].

Pour la réussite de l’établissement de LSP MPLS de bout en bout dont les FEC sont agrégées dans la RIB, la présente spécification doit être mise en œuvre sur tous les LSR dans toutes les zones où l’agrégation IP est utilisée. Si un LSR sur le chemin ne prend pas en charge cette procédure, alors le LSP initié sur le LSR de sortie s’arrête à ce LSR non conforme. Cela n’a pas d’autre effet contraire.

Cette extension peut être déployée de façon incrémentaire :

-	Elle peut être déployée par zone ou par domaine d’acheminement et n’exige pas nécessairement un déploiement à l’échelle de l’AS. Par exemple, si tous les préfixes IP spécifiques sont passés dans la zone de cœur IGP et que seuls les zones de bout utilisent l’agrégation IP, les LSR dans la zone de cœur n’ont pas besoin d’être conformes au présent document.

-	Au sein de chaque zone d’acheminement, les LSR peuvent être mis à niveau indépendamment, à tout moment, dans n’importe quel ordre, et sans interruption de service. Durant le déploiement, si ces LSP sont déjà utilisés, on devrait seulement s’assurer que les ABR continuent d’annoncer les préfixes IP spécifiques dans l’IGP jusqu’à ce que tous les LSR de cette zone soient bien mis à niveau. Alors, les ABR peuvent annoncer seulement le préfixe agrégé et cesser d’annoncer les préfixes spécifiques.

Un fournisseur de service qui passe actuellement les adresses spécifique de retour dc LER dans l’IGP et envisage d’effectuer l’agrégation IP sur l’ABR devrait savoir qu’il peut en résulter un acheminement sous optimal comme discuté dans la [RFC2966].

 	7.2	Considérations sur le temps de convergence d’acheminement 
Le temps de restauration du trafic IP et MPLS se fonde sur deux facteurs : le calcul du plus court chemin en premier (SPF, Shortest Path First) dans le plan de contrôle et le temps de mise à jour de la base de données d’informations de transmission (FIB, Forwarding Information Base) / FIB d’étiquettes (LFIB, Label FIB) dans le plan de transmission. Le calcul de SPF donne O(N*Log(N)) où N est le nombre de nœuds. La mise à jour de FIB/LFIB donne O(P) où P est le nombre de préfixes modifiés. Actuellement, avec la plupart des mises en œuvre de routeurs, la mise à jour de FIB/LFIB est le composant dominant [IGP-CONV], et c’est donc le goulet d’étranglement qui devrait être traité en priorité. La solution documentée dans le présent document réduit la taille de la base de données d’état de liaison dans le plan de contrôle et le nombre d’entrées de FIB dans le plan de transmission. À ce titre elle résout l’adaptation des purs routeurs IP qui partagent l’IGP avec des routeurs MPLS. Cependant, elle ne diminue pas le nombre des entrées de LFIB de sorte qu’il n’est pas suffisant de résoudre l’adaptation des routeurs MPLS. Pour cela, un mécanisme supplémentaire est nécessaire (par exemple, d’introduire une hiérarchie MPLS dans LDP). Ceci sort du domaine d’application du présent document.

Par rapport à la [RFC5036], pour toutes les défaillances sauf celles de LER (c’est-à-dire, de liaisons, de routeurs de fournisseur, et d’ABR) la notification de la défaillance et de la convergence est inchangée. Pour la défaillance de LER, étant donné que l’IGP agrège les chemins IP sur les ABR et n’annonce plus les préfixes spécifiques, le plan de contrôle et plus précisément le comportement de convergence d’acheminement des protocoles (par exemple, de la [RFC4760]) ou des applications (par exemple, de la [RFC4364]) peut être changé en cas de défaillance du nœud LER de sortie. Pour les protocoles et applications qui ont besoin de tracer la disponibilité du LER de sortie, plusieurs solutions peuvent être utilisées, par exemple :

-	S’appuyer sur le mode de contrôle de distribution d’étiquette ordonnée par LDP -- comme défini dans la [RFC5036] – pour connaître la disponibilité du LSP à l’égard du LER de sortie. Le temps de propagation de l’entrée à la sortie des informations d’inaccessibilité est supposé être comparable à l’IGP (mais cela peut dépendre de la mise en œuvre).

-	Annoncer l’accessibilité du LER dans l’IGP pour les besoins du plan de contrôle d’une façon qui ne crée pas d’entrées de FIB IP dans le plan de transmission.

 	8.	Considérations sur la sécurité

La procédure de transposition d’étiquette de plus longue correspondance décrite dans le présent document n’introduit aucun changement en ce qui concerne la section des considérations sur la sécurité de la [RFC5036].

 	9.	Références
 	9.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. (MàJ par RFC8174)

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

 	9.2	Références pour information

[IGP-CONV]	Francois, P., Filsfils, C., and Evans, J., "Achieving sub-second IGP convergence in large IP networks". ACM SIGCOMM Computer Communications Review, juillet 2005.

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

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

[RFC2966]	T. Li, T. Przygienda, H. Smit, "Distribution de préfixes sur un domaine avec IS-IS à deux niveaux", octobre 2000. (Obsolète, voir RFC5302) (Information)

[RFC3107]	Y. Rekhter et E. Rosen, "Portage des informations d'étiquette dans BGP-4", mai 2001. (MàJ par RFC6790, RFC8277)

[RFC3815]	J. Cucchiara, H. Sjostrand, J. Luciani, "Définitions des objets gérés pour le protocole de distribution d'étiquettes (LDP) de commutation d'étiquettes multiprotocoles (MPLS)", juin 2004. (P.S.)

[RFC4364]	E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)

[RFC4760]	T. Bates, R. Chandra, D. Katz et Y. Rekhter, "Extensions multi protocoles pour BGP-4", janvier 2007.

[RFC4761]	K. Kompella et Y. Rekhter, éditeurs "Service de LAN privé virtuel (VPLS) utilisant BGP pour l'auto découverte et la signalisation", janvier 2007. (P.S. ; MàJ par RFC8395)

[RFC4762]	M. Lasserre et V. Kompella, éditeurs, "Service de LAN privé virtuel (VPLS) utilisant la signalisation du protocole de distribution d'étiquette (LDP)", janvier 2007. (P.S.)

[RFC5151]	A. Farrel et autres, "MPLS inter-domaine et GMPLS à ingénierie du trafic – extensions du protocole de réservation de ressource à ingénierie du trafic (RSVP-TE)", février 2008. (MàJ RFC3209, RFC3473) (P.S.)

[RFC5880]	D. Katz, D. Ward, "Détection de transmission bidirectionnelle (BFD)", juin 2010. (P. S. ; MàJ par RFC7880)

 	10.	Remerciements

Les auteurs tiennent à remercier Yakov Rekhter, Stefano Previdi, Vach Kompella, Bob Thomas, Clarence Filsfils, Kireeti Kompella, Luca Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles Bourdon, et Christian Jacquenet des discussions utiles sur ce sujet, de leur relecture, et de leurs commentaires.

 	Adresse des auteurs

Bruno Decraene	Jean-Louis Le Roux	Ina Minei	
France Telecom	France Telecom	Juniper Networks	
38 rue du General Leclerc	2, avenue Pierre-Marzin	1194 N. Mathilda Ave.	
92794 Issy Moulineaux cedex 9	22307 Lannion Cedex	Sunnyvale, CA 94089	
France	France	USA	
mél : bruno.decraene@orange-ftgroup.com	mél : jeanlouis.leroux@orange-ftgroup.com	mél : ina@juniper.net	

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