Groupe de travail Réseau	J. Wu, Tsinghua University	
Request for Comments : 5565	Y. Cui, Tsinghua University	
Catégorie : Sur la voie de la normalisation 	C. Metz, Cisco Systems, Inc.	
	E. Rosen, Cisco Systems, Inc.	
Traduction Claude Brière de L'Isle	juin 2009	

Cadre de maillage de passage logiciel

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.

Résumé
L'Internet a besoin d'être capable de traiter les paquets IPv4 et IPv6. Cependant, il est supposé que certains des réseaux constitutifs de l'Internet vont être des réseaux à "un seul protocole". Une sorte de réseau à un seul protocole peut analyser seulement les paquets IPv4 et peut traiter seulement les informations d'acheminement IPv4 ; une autre sorte peut analyser seulement les paquets IPv6 et peut traiter seulement les informations d'acheminement IPv6. Il est néanmoins exigé que les deux sortes de réseaux à un seul protocole soient capables de fournir le service de transit pour "l'autre" protocole. Ceci est fait en passant "l'autre sorte" d'informations d'acheminement provenant d'une extrémité du réseau à un seul protocole à l'autre, et en tunnelant le paquet de données "d'autre sorte" d'une extrémité à l'autre. Les tunnels sont appelés des "passages logiciels" (softwires). Le présent document cadre explique comment les informations d'acheminement et les paquets de données d'un protocole sont passés à travers un réseau d'un seul protocole à l'autre protocole. Le document prend soin de spécifier quand cela peut être fait avec la technologie existante et quand cela exige le développement d'une technologie nouvelle ou modifiée.

Table des matières
1. Introduction	2
2. Spécification des exigences	4
3. Scénarios intéressants	4
3.1 Scénario IPv6 sur IPv4	4
3.2 Scénario IPv4 sur IPv6	5
4. Principes généraux de la solution	6
4.1 E-IP et I-IP	6
4.2 Acheminement	6
4.3 Transmission tunnelée	7
5. Distribution des informations d'acheminement inter AFBR	7
6. Signalisation de passage logiciel	8
7. Choix de transmettre à travers un passage logiciel	9
8. Choix d'une technologie de tunnelage	9
9. Choix du passage logiciel pour un paquet donné	10
10. OAM et MIB de passage logiciel	10
10.1 Fonctionnement et maintenance (OAM)	10
10.2 MIB	11
11 Diffusion groupée de passage logiciel	11
11.1 Transpositions biunivoques	11
11.2 Schémas de style MVPN	13
12. Considérations inter AS	13
13. Considérations sr la sécurité	14
13.1 Analyse du problème	14
13.2 Techniques non cryptographiques	15
13.3 Techniques cryptographiques	15
14. Références	16
14.1 Références normatives	16
14.2 Références pour information 	17
15. Contributeurs	18
16. Remerciements	18
Adresse des auteurs	18
 	1.	Introduction

Les informations d'acheminement dans tout réseau de cœur IP peuvent être vues comme étant d'une des deux catégories : "informations d'acheminement internes" ou "informations d'acheminement externes". Les informations d'acheminement internes consistent en chemins pour les nœuds qui appartiennent au cœur, et aux interfaces de ces nœuds. Les informations d'acheminement externes consistent en chemins pour des destinations au delà du cœur, en particulier les destinations auxquelles le cœur n'est pas directement rattaché. En général, BGP [RFC4271] est utilisé pour distribuer les informations d'acheminement externes, et un protocole de passerelle intérieure (IGP, Interior Gateway Protocol) comme OSPF [RFC2328] ou IS-IS [RFC1195] est utilisé pour distribuer les informations d'acheminement internes.

Souvent un cœur IP va fournir des services d'acheminement de transit pour les paquets dont l'origine est en dehors du cœur et dont les destinations sont en dehors du cœur. Ces paquets entrent dans le cœur à un de ses "routeurs de bordure". Ils sont acheminés à travers le cœur à un autre routeur de bordure, après lequel ils quittent le cœur et continuent leur chemin. Les nœuds de bordure du cœur sont souvent appelés des routeurs de "bord fournisseur" (PE, Provider Edge). Le terme de "entrée" (ou "PE d'entrée") se réfère au routeur où un paquet entre dans le cœur, et le terme de "sortie" (ou "PE de sortie") se réfère au routeur où il quitte le cœur. Les nœuds intérieurs sont souvent appelés des "routeurs P". Les routeurs qui sont en dehors du cœur mais qui lui sont directement rattachés sont appelés des routeurs de "bord consommateur" (CE, Customer Edge). (Cette terminologie est tirée de la [RFC4364].)

Quand la destination du paquet est en-dehors du cœur, les informations d'acheminement nécessaires au sein du cœur afin d'acheminer le paquet à la sortie appropriée sont, par définition, des informations d'acheminement externes.

Traditionnellement, les informations d'acheminement externes ont été distribuées par BGP à tous les routeurs dans le cœur, pas juste aux routeurs de bordure (c'est-à-dire, pas juste aux points d'entrée et de sortie). Chacun des nœuds intérieurs était supposé chercher l'adresse de destination du paquet et l'acheminer vers le point de sortie. Ceci est appelé la "transmission native" : les nœuds intérieurs regardent dans l'en-tête de chaque paquet afin de faire correspondre les informations dans l'en-tête avec les informations d'acheminement externes.

Il est cependant possible de fournir des services de transit sans exiger que tous les routeurs du cœur aient les informations d'acheminement externes. Les informations d'acheminement que BGP distribue à chaque routeur d'entrée spécifient le routeur de sortie pour chaque chemin. Le routeur d'entrée peut donc "tunneler" le paquet directement au routeur de sortie.  "Tunneler le paquet" signifie de mettre une certaine sorte d'en-tête d'encapsulation qui va forcer les routeurs intérieurs à transmettre le paquet au routeur de sortie. Le paquet original est appelé la "charge utile d'encapsulation". Les routeurs P ne regardent pas l'en-tête du paquet de charge utile mais seulement l'en-tête d'encapsulation. Comme le chemin pour le routeur de sortie fait partie des informations d'acheminement internes du cœur, les routeurs intérieurs n'ont alors pas besoin de connaître les informations d'acheminement externes. Ceci est appelé la "transmission tunnelée". Bien sûr, avant que le paquet puisse quitter la sortie, il doit être désencapsulé.

Le scénario où les routeurs P n'ont pas de chemin externe est parfois appelé un "cœur sans BGP". Cette dénomination est cependant un peu trompeuse, car l'aspect crucial de ce scénario n'est pas que les nœuds intérieur ne fonctionnent pas avec BGP, mais qu'ils ne conservent pas les informations d'acheminement externes.

Ces dernières années, on a vu ce scénario déployé à l'appui de services de VPN, comme spécifié dans la [RFC4364]. Un routeur de bordure maintient plusieurs espaces indépendants d'acheminement/adressage, un pour chaque VPN auquel il s'interface. Cependant, les informations d'acheminement pour les VPN ne sont pas maintenues par les routeurs intérieurs. Dans la plupart de ces scénarios, MPLS est utilisé comme mécanisme d'encapsulation pour envoyer les paquets de l'entrée à la sortie. Il y a des déploiements dans lesquels une encapsulation fondée sur IP, comme L2TPv3 (protocole de transport de couche 2) [RFC3931] ou l'encapsulation générique d'acheminement (GRE, Generic Routing Encapsulation) [RFC2784] est utilisée.

Cette même technique peut aussi être utile quand les informations d'acheminement externes consistent non en chemins de VPN, mais en chemins "ordinaires" de l'Internet. Elle peut être utilisée chaque fois qu'on désire garder les informations d'acheminement externes hors des nœuds intérieurs d'un cœur, ou en fait chaque fois qu'on désire pour une raison quelconque éviter la transmission native d'une certaine sorte de paquets.

Ce cadre se concentre sur deux de ces scénarios.

1.	Dans ce scénario, les nœuds intérieur du cœur supportent seulement IPv6. Il ne tiennent pas du tout les chemins IPv4, et ne sont pas supposés analyser les en-têtes de paquet IPv4. Cependant, on désire utiliser un tel cœur pour fournir des services de transit pour les paquets IPv4. Donc, la transmission tunnelée des paquets IPv4 est requise. Bien sûr, les nœuds de bordure doivent avoir les chemins IPv4, mais l'entrée doit effectuer une encapsulation afin qu'un paquet IPv4 soit transmis à la sortie.

2.	Ce scénario est l'inverse du scénario 1, c'est-à-dire, les nœuds intérieur du cœur supportent seulement IPv4, mais on désire utiliser le cœur pour le transit IPv6.

Dans ces scénarios, un cœur dont les nœuds intérieurs supportent seulement une des deux familles d'adresses est obligé de fournir des services de transit pour l'autre famille d'adresses. Les routeurs de bordure du cœur doivent, bien sûr, prendre en charge les deux familles d'adresses. On utilise le terme de "routeur de bordure de famille d'adresses" (AFBR, Address Family Border Router) pour se référer à ces routeurs PE. Les tunnels qui sont utilisés pour la transmission sont appelés des "passages logiciels" (softwires).

Ces deux scénarios sont appelés le "problème du maillage de passage logiciel" [RFC4925], et le cadre spécifié dans le présent document est donc appelé le "cadre de maillage de passage logiciel". Dans ce cadre, seuls les AFBR ont besoin de prendre en charge les deux familles d'adresses. Les routeurs CE prennent seulement en charge une seule famille d'adresses, et les routeurs P prennent seulement en charge l'autre famille d'adresses.

Il est possible de traiter ces scénarios via une large variété de technologies de tunnelage. Ce cadre ne rend obligatoire l'utilisation d'aucune technologie de tunnelage particulière. Dans tout déploiement, le choix de la technologie de tunnelage est affaire de politique. Le cadre s'accommode d'au moins l'utilisation de MPLS ([RFC3031], [RFC3032]) -- fondé sur le protocole de distribution d'étiquettes (LDP, Label Distribution Protocol) [RFC5036]) et sur le protocole de réservation de ressource avec ingénierie du trafic (RSVP-TE, Resource Reservation Protocol - Traffic Engineering) [RFC3209] -- L2TPv3 [RFC3931], GRE [RFC2784], et IP dans IP [RFC2003]. Le cadre va aussi s'accommoder de l'utilisation du tunnelage IPsec, quand c'est nécessaire afin de satisfaire les exigences de sécurité.

On s'attend à ce que dans de nombreux déploiements, le choix de la technologie de tunnelage soit fait par une simple expression de politique, comme "toujours utiliser des tunnels IP-IP", ou "toujours utiliser MPLS fondé sur LDP", ou "toujours utiliser L2TPv3".

Cependant, d'autres déploiements peuvent avoir un mélange de routeurs, dont certains vont prendre en charge, par exemple, à la fois GRE et L2TPv3, mais d'autres qui prennent en charge seulement une de ces techniques. Il est donc désirable de permettre à l'administration de réseau de créer un petit ensemble de classes, et de configurer chaque AFBR à être membre d'une ou plusieurs de ces classes. Ensuite les routeurs peuvent annoncer les classes dont ils sont membres à chacun des autres, et les politiques d'encapsulation peuvent être exprimées, par exemple, comme "utiliser L2TPv3 pour tunneler aux routeurs de classe X ; utiliser GRE pour tunneler aux routeurs de classe Y". Pour prendre en charge de telles politiques, il est nécessaire que les AFBR soient capables d'annoncer les classes dont ils sont membres ; une façon standard de faire cela doit être développée.

La politique peut aussi exiger qu'une certaine classe de trafic reçoive une certaine qualité de service, et cela peut impacter le choix du tunnel et/ou la technologie de tunnelage utilisée pour les paquets de cette classe. Cela doit être traité par le cadre de maillage de passage logiciel.

L'utilisation de la transmission tunnelée exige souvent qu'une certaine sorte de protocole de signalisation soit utilisée pour établir et/ou maintenir les tunnels. Beaucoup des technologies de tunnelage traitées par le présent cadre ont déjà leur propre protocole de signalisation. Cependant, certains n'en ont pas, et dans certains cas le protocole de signalisation standard pour une technologie de tunnelage particulière ne peut pas être approprié (pour une ou l'autre raison) dans les scénarios intéressants. Dans ces cas (et dans ces cas seulement) de nouvelles méthodologies de signalisation doivent être définies et normalisées.

Dans ce cadre, les passages logiciels ne forment pas une topologie superposée qui est visible à l'acheminement ; les adjacences d'acheminement ne sont pas conservées sur les passages logiciels, et les paquets de contrôle d'acheminement ne sont pas envoyés à travers les passages logiciels. Les adjacences d'acheminement parmi les nœuds de cœur (y compris les nœuds de bordure) sont maintenues via la technologie native du cœur.

Il y a déjà une méthode d'acheminement standard pour distribuer les informations d'acheminement externes parmi les AFBR, à savoir BGP. Cependant, dans les scénarios qui nous intéressent, on peut utiliser des sessions BGP fondées sur IPv6 pour passer les informations d'acheminement IPv4, et on peut utiliser des sessions BGP fondées sur IPv4 pour passer les informations d'acheminement IPv6. De plus, quand le trafic IPv4 est à tunneler sur un cœur IPv6, il est nécessaire de coder le "prochain bond BGP" pour un chemin IPv4 comme une adresse IPv6, et vice versa. La méthode pour coder une adresse IPv4 comme prochain bond pour un chemin IPv6 est spécifiée dans la [RFC4798] ; la méthode pour coder une adresse IPv6 comme prochain bond pour un chemin IPv4 est spécifiée dans la [RFC5549].

 	2.	Spécification 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.	Scénarios intéressants
 	3.1	Scénario IPv6 sur IPv4
Dans ce scénario, les réseaux clients fonctionnent avec IPv6 mais le réseau cœur fonctionne avec IPv4. Ceci est illustré à la Figure 1.

                          +--------+   +--------+
                          | Réseau |   | Réseau |
                          | client |   | Client |
                          |  IPv6  |     IPv6  |
                          +--------+   +--------+
                              |   \     /   |
                              |    \   /    |
                              |     \ /     |
                              |      X      |
                              |     / \     |
                              |    /   \    |
                              |   /     \   |
                          +--------+   +--------+
                          |  AFBR  |   |  AFBR  |
                       +--| IPv4/6 |---| IPv4/6 |--+
                       |  +--------+   +--------+  |
       +--------+      |                           |       +--------+
       | Réseau |      |                           |       | Réseau |
       | client |      |                           |       | client |
       |  IPv4  |------|            IPv4           |-------|  IPv4  |
       +--------+      |          seulement        |       +--------+
                       |                           |
                       |  +--------+   +--------+  |
                       +--|  AFBR  |---|  AFBR  |--+
                          | IPv4/6 |   | IPv4/6 |
                          +--------+   +--------+
                            |   \     /   |
                            |    \   /    |
                            |     \ /     |
                            |      X      |
                            |     / \     |
                            |    /   \    |
                            |   /     \   |
                         +--------+   +--------+
                         | Réseau |   | Réseau |
                         | client |   | Client |
                         |  IPv6  |   |  IPv6  |
                         +--------+   +--------+

Figure 1 : Scénario IPv6 sur IPv4

Le cœur de transit IPv4 peut ou non faire fonctionner MPLS. Si il le fait, MPLS peut être utilisé au titre de la solution.
Bien que la Figure 1 ne montre pas de connexion de "porte de derrière" parmi les réseaux clients, le présent cadre suppose qu'il va y avoir de telles connexions. C'est-à-dire, on ne suppose pas que le seul chemin entre deux réseaux clients est via le réseau de cœur de transit représenté. Donc, la solution d'acheminement doit être robuste dans toutes les sortes de topologies.

De nombreux mécanismes pour fournir la connexité IPv6 à travers les réseaux IPv4 ont été envisagés ces dix dernières années. Un certain nombre de mécanismes de tunnelage différents ont été utilisés, certains provisionnés manuellement, et d'autres fondés sur un adressage particulier. Plus récemment, les  techniques de réseau privé virtuel de couche 3 (L3VPN, Layer 3 Virtual Private Network) de la [RFC4364] ont été étendues pour fournir la connexité IPv6, en utilisant MPLS dans les AFBR et, facultativement, dans le réseau cœur [RFC4798]. La solution décrite dans le présent cadre peut être vue comme un sur ensemble de la [RFC4798], avec un schéma plus généralisé pour choisir la technologie de tunnelage (passage logiciel). Dans ce cadre, MPLS est permis -- mais pas exigé -- même aux AFBR. Comme dans la [RFC4798], il n'y a pas de provisionnement manuel des tunnels, et aucun adressage spécial n'est requis.

 	3.2	Scénario IPv4 sur IPv6
Dans ce scénario, les réseaux clients fonctionnent sur IPv4 mais le réseau de cœur fonctionne sur IPv6. Ceci est illustré à la Figure 2.

                          +--------+   +--------+
                          | Réseau |   | Réseau |
                          | client |   | client |
                          |  IPv4  |   |  IPv4  |
                          +--------+   +--------+
                              |   \     /   |
                              |    \   /    |
                              |     \ /     |
                              |      X      |
                              |     / \     |
                              |    /   \    |
                              |   /     \   |
                          +--------+   +--------+
                          |  AFBR  |   |  AFBR  |
                       +--| IPv4/6 |---| IPv4/6 |--+
                       |  +--------+   +--------+  |
       +--------+      |                           |       +--------+
       | Réseau |      |                           |       | Réseau |
       | client |      |                           |       | client |
       |  IPv6  |------|            IPv6           |-------|  IPv6  |
       +--------+      |         seulement         |       +--------+
                       |                           |
                       |  +--------+   +--------+  |
                       +--|  AFBR  |---|  AFBR  |--+
                          | IPv4/6 |   | IPv4/6 |
                          +--------+   +--------+
                            |   \     /   |
                            |    \   /    |
                            |     \ /     |
                            |      X      |
                            |     / \     |
                            |    /   \    |
                            |   /     \   |
                         +--------+   +--------+
                         | Réseau |   | Réseau |
                         | client |   | client |
                         |  IPv4  |   |  IPv4  |
                         +--------+   +--------+

Figure 2 : Scénario IPv4 sur IPv6

Le réseau cœur de transit IPv6 peut ou non fonctionner sur MPLS. Si il le fait, MPLS peut être utilisé au titre de la solution.

Bien que la Figure 2 ne montre pas de connexion de "porte de derrière" parmi les réseaux clients, le présent cadre suppose qu'il va y avoir de telles connexions. C'est-à-dire, on ne suppose pas que le seul chemin entre deux réseaux clients est via le réseau de cœur de transit représenté. Donc, la solution d'acheminement doit être robuste dans toutes les sortes de topologies.

Bien que le problème de IPv6 sur IPv4 ait reçu une attention considérable dans le passé, le scénario de IPv4 sur IPv6 n'en a pas eu. Cependant, c'est une exigence émergente significative, car un certain nombre de fournisseurs de services construisent des réseaux de cœur IPv6 et ne souhaitent pas fournir une prise en charge native de IPv4 dans leurs routeurs de cœur. Ces fournisseurs de services ont un large corps de réseaux IPv4 et d'applications qui ont besoin de fonctionner à travers leurs cœurs IPv6. Les solutions pour cela n'existent pas encore parce que on a toujours supposé que les réseaux de cœur seraient double piles pour l'avenir prévisible.

 	4.	Principes généraux de la solution

Cette Section donne une très brève vue d'ensemble des procédures. Les sections suivantes donnent plus de détails.

 	4.1	E-IP et I-IP
Dans les paragraphes qui suivent, on utilise le terme de "I-IP" (IP interne) pour se référer à la forme de IP (c'est-à-dire, IPv4 ou IPv6) qui est prise en charge par le réseau de transit. On utilise le terme de "E-IP" (IP externe) pour se référer à la forme de IP qui est prise en charge par les réseaux clients. Dans les scénarios qui nous intéressent, E-IP est IPv4 si et seulement si I-IP est IPv6, et E-IP est IPv6 si et seulement si I-IP est IPv4.

On suppose que les routeurs P prennent seulement en charge I-IP. C'est-à-dire, ils sont supposés avoir seulement les informations d'acheminement I-IP, et ils ne sont pas supposés être capables d'analyser les en-têtes E-IP. On suppose de même que les routeurs CE prennent seulement en charge E-IP.

Les AFBR traitent I-IP et E-IP. Cependant, seul I-IP est utilisé sur les "interfaces face au cœur" d'AFBR, et E-IP est seulement utilisé sur ses interfaces côté client.

 	4.2	Acheminement
Les routeurs P et les AFBR du réseau de transit participent à un IGP pour les besoins de la distribution des informations d'acheminement I-IP.

Les AFBR utilisent BGP interne (IBGP) pour échanger les informations d'acheminement E-IP les uns les autres. Soit il y a un maillage complet de connexions IBGP parmi les AFBR, soit autrement certains ou tous les AFBR sont clients d'un réflecteur de chemin BGP. Bien que ces connexions IBGP soient utilisées pour passer les informations d'acheminement E-IP (c'est-à-dire, les informations d'accessibilité de la couche réseau (NLRI, Network Layer Reachability Information) des mises à jour BGP sont dans la famille d'adresses E-IP) les connexions IBGP fonctionnent sur I-IP, et le prochain bond BGP pour chaque NLRI E-IP est dans la famille d'adresses I-IP.

 	4.3	Transmission tunnelée
Quand un AFBR d'entrée reçoit un paquet E-IP d'une interface côté client, il regarde l'adresse de destination IP du paquet. Dans les scénarios qui nous intéressent, la meilleure correspondance pour cette adresse va être un chemin distribué par  BGP dont le prochain bond est l'adresse I-IP d'un autre AFBR, l'AFBR de sortie.

L'AFBR d'entrée doit transmettre le paquet à travers un tunnel (c'est-à-dire, à travers un passage logiciel) à l'AFBR de sortie. C'est fait en encapsulant le paquet, en utilisant un en-tête d'encapsulation que les routeurs P peuvent traiter et qui va faire que les routeurs P vont envoyer le paquet à l'AFBR de sortie. L'AFBR de sortie extrait alors la charge utile, c'est-à-dire, le paquet E-IP original, et le transmet plus loin en regardant son adresse IP de destination.

Plusieurs sortes de technologies de tunnelage sont prises en charge. Certaines de ces technologies exigent une signalisation explicite d'AFBR à AFBR avant que le tunnel puisse être utilisé, d'autres ne l'exigent pas.

Transmettre un paquet à travers un passage logiciel exige toujours qu'un en-tête d'encapsulation soit ajouté au paquet original. Le paquet résultant est donc toujours plus long que la charge utile d'encapsulation. Au titre du fonctionnement, l'unité maximum de transmission (MTU, Maximum Transmission Unit) du chemin du passage logiciel DEVRAIT être assez grande pour que (a) aucun paquet n'ait besoin d'être fragmenté avant d'être encapsulé, et (b) aucun paquet encapsulé n'ait besoin d'être fragmenté lorsque il est transmis le long d'un passage logiciel. Une discussion générale des questions de MTU dans le contexte de la transmission tunnelée se trouve dans la [RFC4459].

 	5.	Distribution des informations d'acheminement inter AFBR

Les AFBR échangent du trafic avec les routeurs dans les réseaux clients pour échanger les informations d'acheminement pour la famille E-IP.

Les AFBR utilisent BGP pour distribuer les informations d'acheminement E-IP les uns aux autres. Cela peut être fait par un maillage AFBR-AFBR de sessions IBGP, mais plus probablement par un réflecteur de chemin BGP, c'est-à-dire, où chaque AFBR a une session IBGP avec un ou deux réflecteurs de chemin plutôt qu'à d'autres AFBR.

Les sessions BGP entre les AFBR, ou entre les AFBR et le réflecteur de chemin, vont fonctionner par dessus la famille d'adresses I-IP. C'est-à-dire, si le cœur de transit prend seulement en charge IPv6, les sessions IBGP utilisées pour distribuer les informations d'acheminement IPv4 provenant des réseaux clients vont fonctionner sur IPv6 ; si le cœur de transit prend seulement IPv4 en charge, les sessions IBGP utilisées pour distribuer les informations d'acheminement IPv6 provenant des réseaux clients vont fonctionner sur IPv4. Les sessions BGP utilisent donc la couche de réseautage native du cœur ; les messages BGP NE sont PAS tunnelés à travers les passages logiciels ou tout autre mécanisme.

Dans BGP, une mise à jour d'acheminement associe un préfixe d'adresse (ou plus généralement, des NLRI) avec l'adresse d'un prochain bond (NH, Next Hop) BGP. Les NLRI sont associées à une famille d'adresses particulière. L'adresse de NH est aussi associée à une famille d'adresses particulière, qui peut être la même ou différente que la famille d'adresses associée aux NLRI. Généralement, l'adresse de NH appartient à la famille d'adresses qui est utilisée pour communiquer avec le locuteur BGP à qui appartient l'adresse de NH.

Comme les mises à jour d'acheminement qui contiennent les informations sur les préfixes d'adresse E-IP sont portées sur des sessions BGP qui utilisent un transport I-IP, et comme les messages BGP ne sont pas tunnelés, une mise à jour BGP fournissant des informations sur un préfixe d'adresse E-IP va devoir spécifier une adresse de prochain bond dans la famille I-IP.

Du fait de diverses circonstances historiques, quand les NLRI et le NH dans une mise à jour BGP donnée sont de familles d'adresses différentes, comment le NH devrait être codé n'est pas toujours évident. Il y a une procédure de codage différente pour chaque paire de familles d'adresses.

Dans le cas où les NLRI sont dans la famille d'adresses IPv6, et où le NH est dans la famille d'adresses IPv4, la [RFC4798] explique comment coder le NH.

Dans le cas où les NLRI sont dans la famille d'adresses IPv4, et où le NH est dans la famille d'adresses IPv6, la [RFC5549] explique comment coder le NH.

Si un locuteur BGP envoie une mise à jour pour des NLRI dans la famille E-IP, et si la mise à jour est envoyée sur une session BGP qui fonctionne par dessus la couche réseau I-IP, et si le locuteur BGP s'annonce lui-même comme NH pour ces NLRI, alors le locuteur BGP DOIT, sauf explicitement outrepassé par sa politique, spécifier l'adresse de NH dans la famille I-IP. La famille d'adresses du NH NE DOIT PAS être changée par un réflecteur de chemin.

Dans certains cas (par exemple, quand la [RFC5549] est utilisée) on ne peut pas suivre cette règle sauf si les homologues BGP ont annoncé une capacité BGP particulière. Cela conduit à la restriction suivante au déploiement de passage logiciel : si une capacité BGP est définie pour le cas où des NLRI E-IP ont un NH I-IP, tous les AFBR dans un cœur de transit donné DOIVENT annoncer cette capacité.

Si un AFBR a plusieurs adresses IP, les administrateurs du réseau ont généralement une souplesse considérable pour choisir lequel des AFBR utiliser pour s'identifier lui-même comme prochain bond dans une mise à jour BGP. Cependant, si l'AFBR s'attend à recevoir des paquets à travers un passage logiciel d'une technologie de tunnelage particulière, et si l'AFBR est connu de cette technologie de tunnelage via une adresse IP spécifique, alors cette même adresse IP doit être utilisée pour identifier l'AFBR dans le champ Prochain bond de la mise à jour BGP. Par exemple, si le tunnelage L2TPv3 est utilisé, alors l'adresse IP que l'AFBR utilise quand il s'engage dans la signalisation L2TPv3 doit être la même que l'adresse IP qu'il utilise pour s'identifier dans le champ Prochain bond d'une mise à jour BGP.

Dans la [RFC4798], les informations d'acheminement IPv6 sont distribuées en utilisant la famille d'adresses IPv6 étiquetée. Cela permet à l'AFBR de sortie d'associer une étiquette MPLS à chaque préfixe d'adresse IPv6. Si un AFBR d'entrée transmet des paquets à travers un passage logiciel qui peut porter des paquets MPLS, chaque paquet de données peut porter l'étiquette MPLS correspondant au chemin IPv6 à laquelle elle correspond. Cela peut être utile à l'AFBR de sortie, pour démultiplexer et/ou améliorer les performances. Il est aussi possible de faire de même pour la famille d'adresses IPv4, c'est-à-dire, utiliser la famille d'adresses IPv4 étiquetée au lieu de la famille d'adresses IPv4. L'utilisation des familles d'adresses IP étiquetées de cette manière est FACULTATIVE.

 	6.	Signalisation de passage logiciel

Un maillage de passages logiciels inter AFBR s'étendant sur le cœur de transit doit être en place avant que les paquets puissent s'écouler entre réseaux clients. Étant donnés N AFBR double piles, cela exige N^2 tunnels "IP point à point" ou "chemins de commutation d'étiquettes" (LSP, label switched path). Bien qu'en théorie cela pourrait être configuré manuellement, il en résulterait un problème très indésirable de provisionnement de O(N^2). Donc, la configuration manuelle des tunnels en point à point n'est pas considérée comme faisant partie de ce cadre.

Parce que le cœur de transit fournit des services de transit de couche 3, les tunnels en point à point ne sont pas exigés par le présent cadre ; les tunnels en multipoints à point sont tout ce qui est nécessaire. Dans un tunnel en multipoints à point, quand un paquet émerge du tunnel, il n'y a aucun moyen de dire quel routeur a mis le paquet dans le tunnel. Cela modélise le paradigme de la transmission IP native, dans laquelle le routeur de sortie ne peut pas déterminer le routeur d'entrée d'un paquet donné. Bien sûr, les tunnels en point à point pourraient être exigés pour des raisons qui vont au delà des exigences de base décrites dans le présent document. Par exemple, des considérations de qualité de service (QS) ou de sécurité pourraient exiger l'utilisation de tunnels en point à point. Donc les tunnels en point à point sont permis, mais non exigés, par le présent cadre.

Si on désire utiliser une technologie de tunnelage particulière pour les passages logiciels, et si cette technologie a sa propre méthodologie "native" de signalisation, la présomption est que la signalisation native va être utilisée. Cela s'appliquerait certainement aux passages logiciels fondés sur MPLS, où LDP ou RSVP-TE serait utilisé. Un passage logiciel fondé sur IPsec utiliserait la signalisation standard de l'échange de clés Internet (IKEv2, Internet Key Exchange) [RFC4306] et de IPsec [RFC4301], comme nécessaire afin de garantir les propriétés de sécurité du passage logiciel.

Un passage logiciel fondé sur GRE pourrait ou non exiger la signalisation, selon que divers champs facultatifs d'en-tête GRE sont à utiliser. GRE n'a pas de signalisation "native", donc dans ce cas, une procédure de signalisation doit être développée pour prendre en charge les passages logiciels.

Une autre technologie de passage logiciel possible est L2TPv3. Bien que L2TPv3 n'ait pas sa propre signalisation native, cette signalisation établit les tunnels en point à point. Pour les besoins des passages logiciels, il vaut mieux utiliser L2TPv3 en mode multipoints à point, et cela exige une sorte de signalisation différente.

La signalisation à utiliser pour GRE et L2TPv3 pour couvrir ces scénarios est fondée sur BGP, et est décrite dans la [RFC5512].

Si le tunnelage IP-IP est utilisé, ou si le tunnelage GRE est utilisé sans options, aucune signalisation n'est exigée, car la seule information nécessaire à l'AFBR d'entrée pour créer l'en-tête d'encapsulation est l'adresse IP de l'AFBR de sortie, et elle est distribuée par BGP.

Quand l'en-tête d'encapsulation IP est construit, il peut y avoir des champs dans IP dont la valeur n'est déterminée ni par la signalisation qui a été faite, ni par les informations d'acheminement distribuées. Les valeurs de ces champs sont déterminées par la politique dans l'AFBR d'entrée. Des exemples de ces champs peuvent être la durée de vie (TTL, Time to Live), les bits de classe de service différencié (DSCP, Diffserv Service Classes), etc.

Il est souhaitable pour tous les passages logiciels nécessaires d'être pleinement établis avant l'arrivée de tout paquet qui a besoin de passer à travers les passages logiciels. C'est-à-dire, les passages logiciels devrait être "toujours ouverts". Du point de vue d'un AFBR particulier, les points d'extrémité de passage logiciel sont toujours les prochains bonds BGP des chemins que l'AFBR a installé. Cela suggère que toute signalisation de passage logiciel nécessaire devrait soit être faite au titre du démarrage normal du système (comme cela arriverait, par exemple, avec MPLS fondé sur LDP) soit autrement être déclenchée par la réception d'informations d'acheminement BGP (comme décrit dans la [RFC5512]) ; cela aide aussi si la distribution des informations d'acheminement qui servent de déclencheur est une priorité.

 	7.	Choix de transmettre à travers un passage logiciel

La décision de transmettre à travers un passage logiciel, au lieu de transmettre nativement, est prise par l'AFBR d'entrée. Cette décision est une affaire de politique.

Dans de nombreux cas, la politique va être très simple. Certaines politiques utiles sont :
-	Si l'acheminement dit qu'un paquet E-IP doit être envoyé d'une interface côté cœur à un cœur I-IP, alors envoyer le paquet à travers un passage logiciel.
-	Si l'acheminement dit qu'un paquet E-IP doit être envoyé d'une interface qui prend seulement en charge les paquets I-IP, alors envoyer le paquet E-IP à travers un passage logiciel.
-	Si l'acheminement dit que l'adresse du prochain bond BGP pour un paquet E-IP est une adresse I-IP, alors envoyer le paquet E-IP à travers un passage logiciel.
-	Si le chemin qui est la meilleure correspondance pour l'adresse de destination d'un paquet particulier est un chemin distribué par BGP, alors envoyer le paquet à travers un passage logiciel (c'est-à-dire, tunneler tous les paquets acheminés par BGP).

Des politiques plus compliquées sont aussi possibles, mais l'examen de ces politiques sort du domaine d'application du présent document.

 	8.	Choix d'une technologie de tunnelage

Le choix de la technologie de tunnelage est l'affaire d'une politique configurée à l'AFBR d'entrée.

Il est envisagé que, dans la plupart des cas, la politique va être très simple, et va être la même à tous les AFBR d'un cœur de transit -- par exemple, "toujours utiliser MPLS fondé sur LDP" ou "toujours utiliser L2TPv3".

Cependant, d'autres déploiements peuvent avoir un mélange de routeurs, dont certains prennent en charge, par exemple, GRE et L2TPv3, mais dont d'autres prennent en charge seulement une de ces techniques. Il est donc désirable de permettre à l'administration de réseau de créer un petit ensemble de classes et de configurer chaque AFBR à être un membre d'une ou plusieurs de ces classes. Les routeurs peuvent alors annoncer les classes dont ils sont membres à chaque autre routeur, et les politiques d'encapsulation peuvent être exprimées comme, par exemple, "utiliser L2TPv3 pour parler aux routeurs de classe X ; utiliser GRE pour parler aux routeurs de classe Y". Pour prendre en charge de telles politiques, il est nécessaire que les AFBR soient capables d'annoncer les classes dont ils sont membres. La [RFC5512] spécifie un moyen par lequel un AFBR peut annoncer, aux autres AFBR, diverses caractéristiques qui peuvent être pertinentes pour la politique (par exemple, "J'appartiens à la classe Y"). Dans de nombreux cas, ces caractéristiques peuvent être représentées par des communautés choisies arbitrairement ou des communautés étendues, et les politiques à l'entrée peuvent être exprimées dans les termes de ces classes (c'est-à-dire, des communautés).

La politique peut aussi exiger qu'une certaine classe de trafic reçoive une certaine qualité de service, et cela peut impacter le choix de tunnel et/ou la technologie de tunnelage utilisée pour les paquets dans cette classe. Le présent cadre permet que diverses technologies de tunnelage soient utilisées pour instancier les passages logiciels. Le choix de la technologie de tunnelage est l'affaire de la politique, comme discuté à la Section 1.

Bien que dans de nombreux cas, la politique soit inconditionnelle, par exemple, "toujours utiliser L2TPv3 pour les passages logiciels", dans d'autres cas, la politique peut spécifier que le choix est conditionné par les informations sur le point d'extrémité distant du passage logiciel, par exemple, "utiliser L2TPv3 pour parler aux routeurs de classe X ; utiliser GRE pour parler aux routeurs de classe Y". Il est donc désirable de permettre à l'administration de réseau de créer un petit ensemble de classes, et de configurer chaque AFBR à être membre d'une ou plusieurs de ces classes. Si chacune de ces classes est représentée comme une communauté ou communauté étendue, alors la [RFC5512] spécifie une méthode que les AFBR peuvent utiliser pour s'annoncer les uns les autres les classes dont ils sont membres.

Le présent cadre permet aussi des politiques de complexité arbitraire, qui peut dépendre des caractéristiques ou attributs des préfixes d'adresses individuels ainsi que de considérations de QS ou de sécurité. Cependant, la spécification de telles politiques sort du domaine d'application du présent document.

 	9.	Choix du passage logiciel pour un paquet donné

Supposons qu'il ait été décidé d'envoyer un certain paquet à travers un passage logiciel. L'acheminement fournit l'adresse, dans la famille d'adresses du réseau de transport, du prochain bond BGP. Le paquet DOIT être envoyé à travers un passage logiciel dont l'adresse du point d'extrémité distant est la même que l'adresse du prochain bond BGP.

Envoyer un paquet à travers un passage logiciel consiste d'abord à encapsuler le paquet avec un en-tête d'encapsulation qui peut être traité par le réseau de transit et ensuite transmis à l'adresse du point d'extrémité distant du passage logiciel.

Dans de nombreux cas, une fois qu'on connaît l'adresse du point d'extrémité distant, on a toutes les informations nécessaires pour former l'en-tête d'encapsulation. Cela va être le cas si la technologie de tunnel instanciant le passage logiciel est, par exemple, MPLS fondé sur LDP, IP dans IP, ou GRE sans champ d'en-tête facultatif.

Si la technologie de tunnel utilisée est L2TPv3 ou GRE avec champs d'en-tête facultatifs, des informations supplémentaires provenant du point d'extrémité distant sont nécessaires afin de former l'en-tête d'encapsulation. Les procédures pour envoyer et recevoir ces informations sont décrites dans la [RFC5512].

Si la technologie de tunnel utilisée est MPLS fondé sur RSVP-TE ou IPsec, les procédures de signalisation natives de ces technologies vont devoir être utilisées.

Si le paquet envoyé à travers le passage logiciel correspond à un chemin dans les familles d'adresses étiquetées IPv4 ou IPv6, il devrait être envoyé à travers le passage logiciel comme un paquet MPLS avec l'étiquette correspondante. Noter que la plupart des technologies de tunnelage mentionnées dans le présent document sont capables de porter des paquets MPLS, de sorte que ceci ne présuppose pas la prise en charge de MPLS dans les routeurs du cœur.

 	10.	OAM et MIB de passage logiciel
 	10.1	Fonctionnement et maintenance (OAM)
Les passages logiciels sont essentiellement des tunnels qui connectent des routeurs. Si ils disparaissent ou si leurs performances se dégradent, alors la connexité à travers ces tunnels va être impactée. Plusieurs techniques sont disponibles pour surveiller l'état des points d'extrémité de tunnel (AFBR) ainsi que les tunnels eux-mêmes. Ces techniques permettent des opérations comme le suivi de chemin de passage logiciel, le ping sur un point d'extrémité de passage logiciel distant, et la détection de défaillance de vie de point d'extrémité de passage logiciel distant.

Des exemples de techniques applicables à l'OAM de passage logiciel incluent :
o	des temporisations BGP/TCP entre les AFBR,
o	des demandes et réponses d'écho ICMP ou LSP adressées à un AFBR particulier,
o	un échange de paquet de détection de transmission bidirectionnelle (BFD, Bidirectional Forwarding Detection) [RFC5580] entre routeurs d'AFBR.

Une autre possibilité pour l'OAM de passage logiciel est de construire quelque chose de similaire à la [RFC4378] ou, en d'autres termes, de créer et générer des paquets de demande/réponse d'écho de passage logiciel. La demande d'écho est envoyée à un accès UDP bien connu et contient l'adresse IP de l'AFBR d'entrée et l'identifiant de passage logiciel comme charge utile (similaire à la classe d'équivalence de transmission de MPLS contenue dans la demande d'écho de LSP). Le paquet d'écho de passage logiciel va être encapsulé avec l'en-tête d'encapsulation et transmis à travers le même chemin (dans la bande) que celui du passage logiciel lui-même.

Ce mécanisme peut aussi être automatisé pour vérifier périodiquement l'accessibilité du point d'extrémité de passage logiciel distant, la perte d'accessibilité étant signalée à l'application de passage logiciel sur l'AFBR local, permettant donc que les actions convenables soient effectuées. On doit considérer les compromis entre l'adaptabilité de ces mécanismes et le temps requis pour la détection de la perte d'accessibilité du point d'extrémité pour de tels mécanismes automatisés.

En général, un cadre pour l'OAM de passage logiciel peut, dans une large mesure, être fondé sur le cadre de la [RFC4176].

 	10.2	MIB
Il existe des MIB spécifiques pour gérer les éléments du cadre de maillage de passage logiciel. Cependant, il va être nécessaire soit d'étendre ces MIB, soit d'en créer de nouvelles qui reflètent les éléments fonctionnels qui peuvent être gérés par SNMP au sein du réseau de passage logiciel.

 	11	Diffusion groupée de passage logiciel

Un ensemble de réseaux clients, fonctionnant avec E-IP, qui sont connectés au cœur de transit I-IP d'un fournisseur peut souhaiter faire fonctionner des applications de diffusion groupée IP. L'extension de la connexité de diffusion groupée IP à travers le cœur de transit peut être fait de différentes façons, chacune avec en ensemble différent de caractéristiques. La plupart (mais pas toutes) des possibilités sont de légères variantes des procédures définies pour les L3VPN dans la [RFC6513].

On va se concentrer sur qui prend en charge ces caractéristiques et protocoles de diffusion groupée qui sont normalement utilisés à travers des frontières inter-fournisseurs. La prise en charge est fournie pour le mode épars de diffusion groupée indépendante du protocole (PIM-SM, Protocol Independent Multicast - Sparse Mode) et le mode PIM spécifique de source (PIM-SSM, PIM Source-Specific Mode). La prise en charge de PIM bidirectionnel (BIDIR-PIM, Bidirectional PIM), du mécanisme de routeur d'amorçage pour PIM (BSR, Bootstrap Router Mechanism for PIM) et de la détermination automatique de point de rendez-vous (AutoRP, Automatic Rendezvous Point Determination) n'est pas fournie car ces caractéristiques ne sont normalement pas utilisées à travers les frontières inter-fournisseurs.

 	11.1	Transpositions biunivoques
Dans le schéma de "transposition biunivoque", chaque arborescence de client de diffusion groupée est étendue à travers le cœur de transit afin que pour chaque arborescence de client il y ait exactement une arborescence à travers le cœur.

Le schéma biunivoque n'est pas utilisé dans la [RFC6513] parce qu'il exige une quantité d'état dans les routeurs de cœur qui est proportionnelle au nombre d'arborescences de client de diffusion groupée passant à travers le cœur. Dans le contexte de VPN, ceci est considéré comme indésirable parce que la quantité d'état n'est pas limitée et hors du contrôle du fournisseur de service. Cependant, le schéma biunivoque modélise le scénario typique de "diffusion groupée Internet" où le réseau client et le cœur de transit sont tous deux IPv4 ou tous deux IPv6. Si il s'adapte de façon satisfaisante pour ce cas, il devrait aussi s'adapter de façon satisfaisante pour le cas où le réseau client et le cœur de transit prennent en charge des versions différentes de IP.

 	11.1.1	Utilisation de PIM dans le cœur
Quand un AFBR reçoit un message de contrôle PIM E-IP d'un de ses CE, il le traduit de E-IP en I-IP, et le transmet vers la source de l'arborescence. Comme les routeurs dans le cœur de transit ne vont généralement pas avoir de chemin pour la source de l'arborescence, l'AFBR doit inclure un "vecteur de transmission sur le chemin inverse" (RPF, Reverse Path Forwarding) [RFC5496] dans le message PIM.

Supposons qu'un AFBR A reçoive un message Join/Prune PIM E-IP d'un CE pour une arborescence (S,G) ou une arborescence (*,G). L'AFBR devrait "traduire" le message PIM en un message PIM I-IP. Il l'enverrait alors au voisin qui est le prochain bond le long du chemin à la racine de l'arborescence (S,G) ou (*,G). Dans le cas d'une arborescence (S,G) la racine de l'arborescence est S ; dans le cas d'une arborescence (*,G) la racine est le point de rendez-vous (RP, Rendezvous Point) pour le groupe G.

Noter que l'adresse de la racine de l'arborescence va être une adresse E-IP. Comme les routeurs au sein du cœur de transit (autres que les AFBR) n'ont pas de chemin pour les adresses E-IP, A doit mettre un vecteur RPF [RFC5496] dans le message Join/Prune PIM qu'il envoie à son voisin amont. Le vecteur RPF va identifier, comme une adresse I-IP, l'AFBR B qui est le point de sortie dans le réseau de transit le long du chemin de la racine de l'arborescence de diffusion groupée. L'AFBR B est le prochain bond BGP de l'AFBR A pour le chemin de la racine de l'arborescence. Le vecteur RPF permet aux routeurs de cœur de transmettre les messages Join/Prune PIM en amont vers la racine de l'arborescence, même si ils ne maintiennent pas de chemins E-IP.

Afin de traduire un message PIM E-IP en un message PIM I-IP, l'AFBR A doit traduire l'adresse de S (dans le cas d'un groupe (S,G)) ou l'adresse du RP de G de la famille d'adresses E-IP en la famille d'adresses I-IP, et l'AFBR B doit les retraduire.

Dans le cas où E-IP est IPv4 et I-IP est IPv6, il est possible de faire cette traduction algorithmiquement. A peut traduire le S IPv4 en l'adresse IPv6 transposée en IPv4 correspondante [RFC4291], et ensuite B peut la retraduire. Au moment de la rédaction du présent mémoire, il n'existe pas d'adresse de diffusion groupée IPv4 transposée en IPv6, mais si cela devait être normalisé, alors A pourrait aussi traduire le G IPv4 en IPv6, et B pourrait le retraduire. Les circonstances précises dans lesquelles ces traductions seraient faites seraient une affaire de politique.

Évidemment, cette procédure de traduction ne se généralise pas au cas où le client de diffusion groupée est IPv6 mais le cœur est IPv4. Pour traiter ce cas, on a besoin de signalisation supplémentaire entre les deux AFBR. Chaque AFBR en aval doit signaler à l'AFBR amont qu'il a besoin d'un tunnel de diffusion groupée pour (S,G). L'AFBR amont doit alors allouer une adresse de diffusion groupée G' au tunnel et informer l'aval de la valeur de P-G à utiliser. L'AFBR aval utilise alors PIM/IPv4 pour joindre l'arborescence (S',G') où S' est l'adresse IPv4 de l'ASBR (routeur bordure de système autonome) amont.

Les arborescences (S',G') devraient être des arborescences SSM.

Cette procédure peut être utilisée pour prendre en charge les clients de diffusion groupée pour IPv4 ou IPv6 sur un cœur de transit du protocole opposé. Cependant, cela fonctionne seulement quand les clients de diffusion groupée sont SSM, car cela ne fournit pas de méthode pour transposer une opération de client "élaguer une source de l'arborescence (*,G)" en une opération sur l'arborescence (S',G'). Cette méthode exige aussi une signalisation supplémentaire. La signalisation fondée sur BGP de la [RFC6514] est une méthode de signalisation qui pourrait être utilisée. D'autres méthodes de signalisation pourraient aussi être définies.

 	11.1.2	Utilisation de MPLS mLDP et de diffusion groupée dans le cœur
Les extensions à LDP pour les LSP en point à multipoints et en multipoints à multipoints sont spécifiées dans [MLDP] ; on utilise le terme "mLDP" pour se référer à ces extensions à LDP. Si le cœur de transit met en œuvre mLDP et prend en charge la diffusion groupée MPLS, alors des arborescences de diffusion groupée spécifique de source (SSM, Source-Specific Multicast) de client peuvent être transposées de façon bijective en LSP P2MP (point à multipoints).

Quand un AFBR A reçoit un message Join/Prune E-IP PIM pour (S,G) d'un de ses CE, où G est un groupe SSM, il va utiliser mLDP pour se joindre à un LSP P2MP. La racine du LSP P2MP serait l'AFBR B qui est le prochain bond BGP de A sur le chemin de S. Dans mLDP, un LSP P2MP est identifié de façon univoque par une combinaison de sa racine et d'un "identifiant de classe d'équivalence de transmission" (FEC, Forwarding Equivalence Class). Le (S,G) original peut être codé algorithmiquement dans l'identifiant de FEC afin que tous les AFBR qui ont besoin de se joindre au LSP P2MP pour (S,G) génèrent le même identifiant de FEC. Quand la racine du LSP P2MP (l'AFBR B) reçoit un tel message mLDP, il extrait le (S,G) original de l'identifiant de FEC, crée un message Join/Prune PIM E-IP "ordinaire", et l'envoie au CE qui est son prochain bond sur le chemin de S.

La méthode de codage de (S,G) dans l'identifiant de FEC doit être normalisée. Le codage doit être auto-identifiant afin qu'un nœud qui est la racine d'un LSP P2MP puisse déterminer si un identifiant de FEC est le résultat du codage d'un (S,G) PIM.

Le mécanisme d'état approprié doit être normalisé afin que les événements PIM aux AFBR résultent en les événements mLDP appropriés. Par exemple, si en un point un AFBR détermine (via les procédures de PIM) qu'il n'a plus de receveur en aval pour (S,G) il devrait invoquer les procédures mLDP appropriées pour s'élaguer lui-même du LSP P2MP correspondant.

Noter que cette méthode ne peut pas être utilisée quand le G est un groupe en mode épars. La raison pour laquelle cette méthode ne peut pas être utilisée est que mLDP n'a pas de fonction qui corresponde au "élaguer cette source de l'arborescence partagée" de PIM. Donc, si un LSP P2MP était transposé de façon bijective en LSP P2MP, du trafic dupliqué pourrait finir par traverser le cœur de transit (c'est-à-dire, du trafic provenant de S pourrait descendre sur les deux arborescences partagée et de source de S). Autrement, on pourrait concevoir un protocole d'AFBR à AFBR pour élaguer les sources de LSP P2MP à la racine du LSP. Il est cependant recommandé que les groupes de clients de diffusion groupée SM soient pris en charge par d'autres méthodes, comme celles discutées ci-dessous.

Les groupes de diffusion groupée bidirectionnelle côté client établis par PIM-bidir pourraient être transposés en utilisant la technique ci-dessus pour les LSP MP2MP (multipoints à multipoints) établis par mLDP [MLDP]. On n'examine pas plus cela, car les groupes inter-fournisseurs bidirectionnels ne sont utilisés nulle part.

 	11.2	Schémas de style MVPN
Les schémas de type VPN de diffusion groupée (MVPN, Multicast VPN) sont décrits dans la [RFC6513] et ses documents d'accompagnement (comme la [RFC6514]). Pour appliquer ces schémas à l'environnement de passage logiciel, il est nécessaire seulement de traiter tous les AFBR d'un cœur de transit donné comme si ils étaient tous, pour les besoins de la diffusion groupée, des routeurs PE rattachés au même VPN.

Les schémas de type MVPN n'exigent pas une transposition biunivoque entre les arborescences de client de diffusion groupée et les arborescences de cœur de transit de diffusion groupée. Dans l'environnement de MVPN, il est exigé que le nombre d'arborescences dans le cœur s'adapte moins que linéairement au nombre d'arborescences de client. Cette exigence ne peut pas tenir dans les scénarios de passage logiciel.

Les schémas de type MVPN peuvent prendre en charge des groupes SM, SSM, et Bidir. Ils fournissent un certain nombre d'options pour le plan de contrôle :

-	de style LAN : utilise un ensemble d'arborescences de diffusion groupée dans le cœur pour émuler un réseau de zone locale (LAN, Local Area Network) et faire fonctionner le protocole PIM côté client sur ce "LAN". Le "LAN" peut consister en une seule arborescence Bidir contenant tous les AFBR ou un ensemble d'arborescences SSM, dont une a sa racine à chaque AFBR et contenant tous les autres AFBR comme receveurs.

-	multi accès sans diffusion (NBMA, Non-Broadcast Multiple Access) utilisant BGP : la signalisation PIM côté client peut être traduite en signalisation fondée sur BGP, avec un réflecteur de chemin BGP pour relayer la signalisation.

Ces deux options de base admettent de nombreuses variantes ; la [RFC6513] en fait une discussion complète.

Pour le plan des données, il y a aussi un certain nombre d'options :

-	Toutes les données de diffusion groupée sont envoyées sur le LAN émulé. Cette option particulière n'est pas très intéressante pour les scénarios de passage logiciel, car chaque AFBR devrait recevoir tous les paquets de diffusion groupée de client.

-	Tout groupe de diffusion groupée transposé en une arborescence qui est considérée appropriée pour ce groupe, dans le sens de causer le trafic de ce groupe à aller à "trop" d'AFBR qui n'ont pas besoin de le recevoir.

Là encore la [RFC6513] fait une discussion complète de ces questions.

 	12.	Considérations inter AS
On a jusqu'à présent seulement considéré le cas où un "cœur de transit" consiste en un seul système autonome (AS, Autonomous System). Si le cœur de transit consiste en plusieurs AS, il peut alors être nécessaire d'utiliser des passages logiciels dont les points d'extrémité sont des AFBR rattachés aux différents systèmes autonomes. Dans ce cas, l'AFBR au point d'extrémité distant d'un passage logiciel n'est pas le prochain bond BGP pour les paquets qui doivent être envoyés sur le passage logiciel. Comme les procédures décrites ci-dessus exigent que l'adresse du point d'extrémité d'un passage logiciel distant soit la même que l'adresse du prochain bond BGP, ces procédures ne fonctionnent pas comme spécifié quand le cœur de transit consiste en plusieurs AS.

Il y a plusieurs façons de traiter cette situation.

1.	Ne pas le faire ; exige qu'il y ait des AFBR à la frontière de chaque AS afin que le cœur de transit ne s'étende pas sur plus d'un AS.

2.	Utiliser EBGP multi-bonds pour permettre aux AFBR d'envoyer des chemins BGP à chacun des autres, même si les ABFR ne sont pas dans les mêmes AS ou des AS voisins.

3.	S'assurer qu'un ASBR qui n'est pas un AFBR ne change pas le champ Prochain bond des chemins pour lesquels l'encapsulation est nécessaire.

Dans les deux derniers cas, on doit faire la résolution de prochain bond récurrente de BGP, et les encapsulations peuvent devoir être "mises en pile" (c'est-à-dire, plusieurs couches d'encapsulation peuvent devoir être utilisées).

Par exemple, si on considère un paquet P avec l'adresse de destination IP D. Supposons qu'il arrive à l'AFBR d'entrée A1 et que le chemin qui est la meilleure correspondance pour D ait le prochain bond BGP B1. A1 va encapsuler le paquet pour sa livraison à B1. Si B1 n'est pas dans l'AS de A1, A1 va devoir chercher le chemin pour B1 et trouver alors le prochain bond BGP, appelons le B2, de ce chemin. Si les routeurs intérieurs de l'AS de A1 n'ont pas de chemin pour B1, alors A1 doit encapsuler le paquet une seconde fois, pour la livraison à B2.

 	13.	Considérations sr la sécurité
 	13.1	Analyse du problème
Dans le cadre de maillage de passage logiciel, les paquets de données qui sont encapsulés sont des paquets de données E-IP qui voyagent à travers l'Internet. Ces paquets de données (la "charge utile" de passage logiciel) peuvent ou non avoir besoin de caractéristiques de sécurité comme l'authentification, la protection de l'intégrité, de la confidentialité, ou contre la répétition. Cependant, les besoins de sécurité des paquets de charge utile sont indépendants de si ces paquets traversent ou non des passages logiciels. Le fait qu'un paquet de charge utile particulier voyage à travers un passage logiciel n'affecte en rien ses besoins de sécurité.

Donc, les seules questions de sécurité qu'on doit examiner sont celles qui affectent les en-têtes d'encapsulation I-IP, plutôt que celles qui affectent la charge utile E-IP.

Comme les en-têtes d'encapsulation déterminent l'acheminement des paquets qui voyagent à travers les passages logiciels, ils doivent apparaître "en clair".

Dans le cadre de maillage de passage logiciel, pour chaque point d'extrémité receveur d'un tunnel, il y a un ou plusieurs points d'extrémité transmetteurs "valides", où les points d'extrémité transmetteurs valides sont ceux qui sont autorisés à tunneler les paquets au point d'extrémité receveur. Si l'en-tête d'encapsulation n'a pas de garantie d'authentification ou d'intégrité, il est alors possible d'avoir des attaques d'usurpation d'identité, dans lesquelles des nœuds non autorisés envoient des paquets encapsulés au point d'extrémité receveur, donnant au point d'extrémité receveur l'impression invalide que les paquets encapsulés ont réellement voyagé à travers le passage logiciel. Des attaques en répétition sont aussi possibles.

L'effet de telles attaques est cependant assez limité. Le point d'extrémité receveur d'un passage logiciel désencapsule la charge utile et fait l'acheminement suivant sur la base de l'adresse de destination IP de la charge utile. Comme les paquets de charge utile voyagent à travers l'Internet, ils ont des adresses provenant de l'espace d'adresses uniques au monde (plutôt que, par exemple, provenant d'une sorte d'espace d'adresses privé). Donc, ces attaques ne peuvent pas causer la livraison des paquets de charge utile à une adresse autre que celle qui apparaît dans le champ Adresse de destination IP du paquet de charge utile.

Cependant, des attaques de cette sorte peuvent résulter en violations de politique. Le ou les points d'extrémité transmetteurs autorisés d'un passage logiciel peuvent suivre une politique selon laquelle seulement certains paquets de charge utile sont envoyés à travers le passage logiciel. Si des nœuds non autorisés sont capables d'encapsuler des paquets de charge utile afin qu'ils arrivent au point d'extrémité receveur en paraissant arriver de nœuds autorisés, alors les politiques d'autorisation appropriée ont été contournées.

Les attaques du type examiné peuvent aussi être utilisées dans des attaques de déni de service sur les points d'extrémité receveurs de tunnel. Cependant, de telles attaques ne peuvent pas être empêchées par l'utilisation des techniques cryptographiques d'authentification/intégrité, car le besoin de faire un chiffrement sur des paquets usurpés rend seulement le problème du déni de service encore pire. (L'hypothèse est que les mécanismes de cryptographie vont probablement être plus coûteux que les mécanismes de désencapsulation/transmission. Donc si on essaye d'éliminer une attaque d'inondation sur les mécanismes de désencapsulation/transmission en éliminant les paquets qui ne passent pas une vérification d'intégrité cryptographique, on échange juste une sorte d'attaque contre une autre.)

Cette section est largement fondée sur la section des considérations sur la sécurité de la RFC 4023, qui traite aussi des encapsulations et des tunnels.

 	13.2	Techniques non cryptographiques
Si un tunnel se tient entièrement dans un seul domaine administratif, alors, dans une certaine mesure, il y a certaines techniques non cryptographiques qu'on peut utiliser pour empêcher des paquets usurpés d'atteindre le point d'extrémité receveur d'un tunnel. Par exemple, quand l'encapsulation de tunnel est fondée sur IP :

-	Les points d'extrémité receveurs des tunnels peuvent recevoir un ensemble distinct d'adresses, et ces adresses peuvent être portées à la connaissance des routeurs de bordure. Les routeurs de bordure peuvent alors filtrer les paquets, destinés à ces adresses, qui arrivent de l'extérieur du domaine.

-	Les points d'extrémité émetteurs des tunnels peuvent recevoir un ensemble distinct d'adresses, et ces adresses peuvent être portées à la connaissance des routeurs de bordure et des points d'extrémité receveurs des tunnels. Les routeurs de bordure peuvent filtrer tous les paquets qui arrivent de l'extérieur du domaine avec des adresses de source qui sont dans cet ensemble, et les points d'extrémité receveurs peuvent éliminer tous les paquets qui apparaissent faire partie d'un passage logiciel, mais dont les adresses de source ne sont pas dans cet ensemble.

Si une encapsulation fondée sur MPLS est utilisée, les routeurs de bordure peuvent refuser d'accepter des paquets MPLS provenant de l'extérieur du domaine, ou ils peuvent refuser d'accepter de tels paquets MPLS chaque fois que l'étiquette supérieure correspond à l'adresse d'un point d'extrémité receveur de tunnel.

Ces techniques supposent que, au sein d'un domaine, le réseau est assez sûr pour empêcher l'introduction de paquets usurpés provenant du domaine lui-même. Cela peut ne pas être toujours le cas. Aussi, ces techniques peuvent être difficiles ou impossibles à utiliser effectivement pour les tunnels qui ne sont pas dans le même domaine administratif.

Une technique différente est d'avoir l'en-tête d'encapsulation qui contient un mot de passe en clair. Le "mouchard" de 64 bits de L2TPv3 [RFC3931] est parfois utilisé de cette façon. Cela peut être utile au sein d'un domaine administratif si il est considéré qu'il est infaisable à un attaquant d'espionner les paquets originaires du domaine et qui ne quittent pas le domaine. Un attaquant ne serait alors pas capable de découvrir le mot de passe. Un attaquant pourrait, bien sûr, essayer de deviner le mot de passe, mais si c'est une séquence arbitraire de 64 bits, les attaques en force brute qui parcourent tous les mots de passe possibles vont être infaisables. Cette technique peut être plus facile à gérer que le filtrage d'entrée, et peut être tout aussi efficace si les hypothèses tiennent. Comme le filtrage d'entrée, il ne peut cependant pas être applicable pour les tunnels qui franchissent les frontières de domaines.

Donc, il est nécessaire de considérer aussi l'utilisation de techniques cryptographiques pour établir les tunnels et pour passer les données à travers eux.

 	13.3	Techniques cryptographiques
Si le chemin entre les deux points d'extrémité d'un tunnel n'est pas adéquatement sûr, alors :

-	Si un protocole de contrôle est utilisé pour établir les tunnels (par exemple, pour informer un point d'extrémité de tunnel de l'adresse IP de l'autre) le protocole de contrôle DOIT avoir un mécanisme d'authentification, et il DOIT être utilisé quand le tunnel est établi  Si le tunnel est établi automatiquement par suite, par exemple, d'informations distribuées par BGP, alors l'utilisation du mécanisme d'authentification fondé sur MD5 de BGP [RFC2385] est satisfaisant.

-	La transmission de données à travers le tunnel devrait être sécurisée avec IPsec. Dans le reste de ce paragraphe, on spécifie la façon dont IPsec peut être utilisé, et les exigences de mise en œuvre qu'on mentionne sont destinées à être applicables chaque fois que IPsec est utilisé.

On considère seulement le cas où IPsec est utilisé avec un mécanisme de tunnelage fondé sur IP. L'utilisation de IPsec avec un mécanisme de tunnelage fondé sur MPLS fera l'objet d'une étude ultérieure.

Si il est réputé nécessaire d'utiliser des tunnels qui sont protégés par IPsec, le type de tunnel DEVRAIT être négocié par les points d'extrémité du tunnel en utilisant les procédures spécifiées dans la [RFC5566]. Ce document permet l'utilisation de IPsec en mode tunnel mais permet aussi de traiter la tête de tunnel et la queue de tunnel comme les points d'extrémité d'une association de sécurité, et d'utiliser IPsec en mode transport.

Afin d'utiliser IPsec en mode transport, les paquets encapsulés devraient être vus comme générés à la tête de tunnel et comme destinés à la queue de tunnel. Une seule adresse IP de la tête de tunnel va être utilisée comme adresse IP de source, et une seule adresse IP de la queue de tunnel va être utilisée comme adresse IP de destination. Cette technique peut être utilisée pour porter des paquets MPLS à travers une association de sécurité IPsec, en encapsulant d'abord les paquets MPLS dans MPLS dans IP ou dans MPLS dans GRE [RFC4023] et ensuite en appliquant IPsec en mode transport.

Quand IPsec est utilisé pour sécuriser les passages logiciels, IPsec DOIT fournir l'authentification et la protection de l'intégrité. Donc, la mise en œuvre DOIT prendre en charge soit ESP (encapsulation de charge utile de sécurité) avec chiffrement nul [RFC4303] soit AH (en-tête d'authentification) [RFC4302]. ESP avec chiffrement PEUT être pris en charge. Si ESP est utilisé, la queue de tunnel DOIT vérifier que l'adresse IP de source de tout paquet reçu sur une SA (Security Association) IPsec donnée est celle attendue, comme spécifié au paragraphe 5.2, étape 4, de la [RFC4301].

Comme les passages logiciels sont établis dynamiquement comme sous produit du passage d'informations d'acheminement, la distribution de clés DOIT être faite automatiquement par IKEv2 [RFC4306]. Si une infrastructure de clé publique (PKI, Public Key Infrastructure) n'est pas disponible, le sous TLV Authentifiant de tunnel IPsec décrit dans la [RFC5566] DOIT être utilisé et validé avant d'établir une SA.

Les sélecteurs associés à la SA sont les adresses de source et destination de l'en-tête d'encapsulation, avec le numéro de protocole IP représentant le protocole d'encapsulation utilisé.

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

[RFC2003]	C. Perkins, "Encapsulation de IP dans IP", octobre 1996. (MàJ par RFC 3168, RFC 6864, Errata) (P.S.) 

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

[RFC2784]	D. Farinacci, T. Li, S. Hanks, D. Meyer et P. Traina, "Encapsulation d'acheminement générique (GRE)", DOI 10.17487/RFC2784, mars 2000.

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001. (Info. ; MàJ par 9017)

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

[RFC3931]	J. Lau et autres, "Protocole de tunnelage de couche deux - version 3 (L2TPv3)", DOI 10.17487/RFC3931, mars 2005. (P.S.)

[RFC4023]	T. Worster et autres, "Encapsulation de MPLS dans IP ou encapsulation d'acheminement générique (GRE)", mars 2005. (MàJ par RFC5332) (P.S.)

[RFC4798]	J. De Clercq et autres, "Connexion d'îlots IPv6 sur MPLS IPv4 avec des routeurs de bordure IPv6 de fournisseur (6PE)", février 2007. (P.S.)

[RFC5512]	P. Mohapatra, E. Rosen, "Identifiant de famille d'adresse suivante (SAFI) d'encapsulation BGP et attribut d'encapsulation de tunnel de BGP", avril 2009. (P. S.)

[RFC5549]	F. Le Faucheur, E. Rosen, "Annonce des informations d'accessibilité de couche réseau IPv4 avec un prochain bond IPv6", mai 2009. (P. S. ; remplacée par RFC8950)

[RFC5566]	L. Berger, R. White, E. Rosen, "Attribut d'encapsulation de tunnel IPsec pour BGP", juin 2009. (P. S.)

 	14.2	Références pour information 

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

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

[RFC2385]	A. Heffernan, "Protection des sessions de BGP via l'option de signature MD5 de TCP", août 1998. (P.S. ; MàJ par la RFC6691) ; remplacée par RFC5925)

[RFC4176]	Y. El Mghazli et autres, "Cadre du fonctionnement et de la gestion de la couche 3 des réseaux privés virtuels (L3VPN)", octobre 2005. (Information)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212, 9072)

[RFC4291]	R. Hinden, S. Deering, "Architecture d'adressage IP version 6", février 2006, DOI 10.17487/RFC4291. (MàJ par 5952 et 6052, 8064) (D.S.)

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", DOI 10.17487/RFC4301, décembre 2005. (P.S.) (Remplace la RFC2401)

[RFC4302]	S. Kent, "En-tête d'authentification IP", décembre 2005. (P.S.)

[RFC4303]	S. Kent, "Encapsulation de charge utile de sécurité dans IP (ESP)", décembre 2005. (Remplace RFC2406) (P.S.)

[RFC4306]	C. Kaufman, "Protocole d'échange de clés sur Internet (IKEv2)", décembre 2005. (Obsolète, voir la RFC5996)

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

[RFC4378]	D. Allan et T. Nadeau, éd., "Cadre pour le fonctionnement et la gestion de la commutation d'étiquettes multiprotocoles (MPLS)", février 2006. (Information)

[RFC4459]	P. Savola, "Questions de MTU et de fragmentation liées au tunnelage réseau", avril 2006. (Information)

[RFC4925]	X. Li et autres, "Position du problème du passage logiciel", juillet 2007. (Information)

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

[RFC5496]	IJ. Wijnands, A. Boers et E. Rosen, "TLV de vecteur de transmission de chemin inverse (RPF)", mars 2009. (D.S.)

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

[RFC6513]	E. Rosen, R. Aggarwal, "Diffusion groupée dans les réseaux privés virtuels IP MPLS/BGP", février 2012. (P.S. ; MàJ par RFC7900, RFC7988)

[RFC6514]	R. Aggarwal et autres, "Codages et procédures BGP pour la diffusion groupée dans les réseaux privés virtuels IP MPLS/BGP", février 2012. ((P.S.  ; MàJ par les RFC6515, 6625, 7441, 7582, 7899, 7900, 7902, 7988, 8504, 9573)

 	15.	Contributeurs

Xing Li
Tsinghua University
Department of Electronic Engineering
Beijing  100084
P.R. China
mél : xing@cernet.edu.cn

Simon Barber
Cisco Systems, Inc.
250 Longwater Avenue
Reading, RG2 6GB
United Kingdom
mél : sbarber@cisco.com

Pradosh Mohapatra
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA  95134
USA
mél : pmohapat@cisco.com

John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
USA
mél : jgs@juniper.net

 	16.	Remerciements

David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, Mingwei Xu, et Ke Xu ont fourni d'utiles apports au présent document.

 	Adresse des auteurs

Jianping Wu	Yong Cui	
Tsinghua University	Tsinghua University	
Department of Computer Science	Department of Computer Science	
Beijing  100084	Beijing  100084	
P.R. China	P.R. China	
téléphone : +86-10-6278-5983	téléphone : +86-10-6278-5822	
mél : jianping@cernet.edu.cn	mél : yong@csnet1.cs.tsinghua.edu.cn	

Chris Metz	Eric C. Rosen	
Cisco Systems, Inc.	Cisco Systems, Inc.	
3700 Cisco Way	1414 Massachusetts Avenue	
San Jose, CA  95134	Boxborough, MA  01719	
USA	USA	
mél : chmetz@cisco.com	mél : erosen@cisco.com