VPLS : Virtual Private LAN Service

Jean-Marc Uz
Juniper Networks Espace 21 - 31 Place Ronde - 92986 Paris la Dfense - France juze@juniper.net 14 Octobre 2003

Rsum
VPLS signifie Virtual Private LAN Service. VPLS est un service Ethernet multipoint--multipoint (MP2MP) et utilise IP ainsi quun mcanisme de tunnel (gnralement MPLS) pour apporter une connectivit entre plusieurs sites travers un nuage IP, comme si ces sites taient relis par un mme LAN Ethernet. Lorganisme connect obtient un simple service Ethernet de la part de loprateur (MAN, backbone national) dont le rseau apparat comme un large domaine de broadcast, et le client ne voit pas les dtails de lmulation du LAN. VPLS permet loprateur de service de dlivrer un service dinterconnexion de LAN entre plusieurs sites au niveau dun rseau mtropolitain ou travers un rseau longue distance (ventuellement reliant des rseaux mtropolitains distants) en exploitant la capacit de dploiement de IP/MPLS grande chelle. Le trafic du client est commut sur la base de ladresse MAC des paquets Ethernet, et le service VPLS peut transporter IPv4 et IPv6 ainsi que des protocoles exprimentaux, ou loppos des protocoles hrits dautres technologies comme IPX et DECnet. Cet article prsente la technologie VPLS dveloppe dans le cadre de lIETF (Internet Engineering Task Force). Une attention particulire est porte sur les aspects service de bout en bout traversant plusieurs domaines IP, comme cest gnralement le cas pour les rseaux de Recherche & Enseignement.

Mots clefs
VPLS, Ethernet, multipoint--multipoint, IP, BGP, MPLS, Inter-domaine

Introduction

LEthernet est la technologie LAN (Local Area Network) la plus largement dploye dans les rseaux actuels. Ces dernires annes les standards Ethernet ont volu de manire trs significative, dune part en ce qui concerne le dbit gr par cette technologie, avec une croissance impressionnante de 10 Mb/s 10 Gb/s, et dautre part par les amliorations du protocole pour tendre lusage de lEthernet au contexte de rseau longue distance (WAN : Wide Area Network), appel souvent Mtro Ethernet. Les oprateurs qui proposent ce type de service offrent gnralement des connexions Ethernet point--point entre les diffrents sites du client sur une zone mtropolitaine. Cependant, le but ultime du Mtro Ethernet est de proposer une solution permettant daller au-del pour finalement offrir une connectivit multipoint--multipoint sur une zone mtropolitaine ou entre plusieurs zones mtropolitaines travers un rseau longue distance. En dautres mots cela consiste pouvoir offrir un service un ensemble de sites (par exemple des universits ou ventuellement un sous-ensemble comme un laboratoire de chaque campus universitaire) de sorte que tous ces sites apparaissent comme tant sur le mme LAN Ethernet, indpendamment du fait quils soient sur la mme zone mtropolitaine ou sur des zones distantes. Une des solutions les plus largement dfendues pour apporter ces services est connue sous le nom de Virtual Private LAN Service (VPLS), qui propose une connectivit Ethernet multipoint--multipoint intra ou inter-zone mtropolitaine au-dessus dun service IP/MPLS.

Offres actuelles de service Ethernet

Les offres actuelles de services Ethernet sont de manire gnrale assez limites. De nombreux oprateurs de service supportent simplement des connexions point--point apportant des accs Internet ddis ou des interconnexions prives entre sites dune mme zone mtropolitaine. Certains oprateurs supportant peu de clients ont dploy des services LAN Ethernet multipoint-a-multipoint au sein dune zone mtropolitaine ; ainsi plusieurs sites dune mme zone mtropolitaine sont connects comme si ils taient sur un LAN unique, utilisant les VLAN IDs pour une sparation logique du trafic. Cependant, tant donn que la plupart de ces oprateurs dlivrant des services Ethernet mtropolitain ont construit leur infrastructure sur la base de commutateurs Ethernet, un certain nombre de problmes inhrents ce type de solution apparaissent aujourdhui sur de larges rseaux mtropolitains. Dune part ces rseaux sont limits en nombre de clients pouvant tre supports : ils ne peuvent en effet supporter que 4096 VLAN IDs. Un VLAN ID est requis par client, et comme les VLAN IDs ont une signification globale, ils doivent tre uniques au sein du rseau de loprateur. Il est vident quil nest pas possible denvisager dapporter ce service de LAN travers plusieurs rseaux mtropolitains distants avec ce type darchitecture, car cela ncessiterait de construire un rseau de niveau 2 Ethernet encore plus large. Il existe une approche consistant encapsuler des VLANs dans dautres VLANs, mais le manque de standardisation dans ce domaine oblige un dploiement mono-constructeur. Dautre part ces rseaux base de commutateurs offrent gnralement des solutions de QoS trs limites, voire pas de possibilit de diffrencier les paquets. Enfin loprateur de service dpend du protocole de Spanning Tree (STP) pour traiter la rsilience des liens (ou plus exactement les problmes de boucle dans le rseau), ce qui savre peu optimum en termes de partage de charge et de temps de convergence. Cest pourquoi le dploiement de services Ethernet multipoint--multipoint traversant plusieurs rseaux mtropolitains ventuellement relis par des rseaux nationaux et europens nest pas raliste aujourdhui avec cette approche. Intressons-nous un moment au cas des entreprises : tant donn que de nombreuses entreprises multi-sites sont limites par des connexions point--point travers plusieurs zones mtropolitaines, elles optent gnralement pour une topologie rseau hub and spoke au niveau de la connectivit longue distance. Pour une entreprise traditionnelle, les sites distants sont relis aux sites centraux (typiquement le sige), eux-mmes relis aux ressources stratgiques tels que les centres de calculs ou de stockage des donnes. Daprs une tude rcente ralise par Infonetics Research, User Plans for WAN and Internet Access, US/Canada 2002 , il apparat quune entreprise moyenne dispose de 20 sites, ceci incluant le sige, les centres de donnes, et les bureaux distants. Cela veut dire que le besoin en liaisons pour une entreprise moyenne correspond 20 liaisons primaires et 20 liaisons de secours pour son rseau en architecture hub and spoke . Il y a un certain nombre dinconvnients ce type darchitecture : Larchitecture surcharge loprateur du service avec la gestion de nombreuses liaisons point--point, ncessitant des ressources en personnel et des cots oprationnels. Chaque fois quun site distant est ajout, il est ncessaire de configurer la fois lquipement CPE1 du nouveau site et lquipement CPE du site central Une panne au niveau du hub implique une panne totale du rseau de lentreprise (une entreprise peut contourner ce problme en dployant plusieurs hubs, ce qui renforce les deux premiers inconvnients cits ci-dessus) Le trafic site site ncessite frquemment de traverser deux fois le rseau de loprateur de liaisons, en passant par le site hub, ce qui implique un besoin toujours croissant en bande passante pour les connexions du hub. Des dlais de transaction peuvent apparatre ds lors que des congestions se manifestent au niveau du hub lorsque plusieurs sites distants accdent aux ressources centrales via le rseau et excdent la limite en bande passante du hub. Lutilisation du protocole de Spanning Tree (STP) pour grer la fois la fonction de dtection des boucles ainsi que la fonction de convergence rapide peut causer des difficults. En effet, bien que STP soit efficace pour dtecter des boucles Ethernet dans le rseau, il savre limit en terme de convergence en cas de rupture de lien.

Dans un contexte de rseaux de Recherche et Enseignement, les mme problmes peuvent se poser pour le raccordement de communauts particulires, par exemple des sites administratifs dun organisme, ou des laboratoires distants travaillant sur un projet commun de recherche et ncessitant une infrastructure rseau fdratrice (virtuellement) ddie. Dautre part il peut sagir dune infrastructure rseau mtropolitaine et collective supportant des communauts trs distinctes (Recherche & Enseignement, Sant, Culture, ppinires dentreprises, mairies et collectivits locales, etc).

Customer Premises Equipment

VPLS : Virtual Private LAN Service

VPLS dlivre un service Ethernet multipoint--multipoint pouvant tre indiffremment dlivr au niveau dune infrastructure mtropolitaine ou sur des rseaux longue distance, et apporte une connectivit entre plusieurs sites comme si ces sites taient relis par un mme LAN Ethernet. Contrastant avec loffre de service Ethernet multipoint--multipoint apports par une infrastructure doprateur base sur des commutateurs Ethernet, VPLS utilise une infrastructure IP/MPLS. Du point de vue de loprateur, lutilisation des protocoles de routage IP/MPLS au lieu dune technologie Ethernet base sur le Spanning Tree Protocol, ainsi que lutilisation des labels (tiquettes) MPLS au lieu des identits VLAN, apportent linfrastructure de loprateur une souplesse et une capacit de dploiement de services Mtro Ethernet grande chelle. Ce nouveau service permet aux rseaux de Recherche et Enseignement denvisager une approche innovante pour rapprocher les chercheurs et enseignants souvent disperss sur des sites distants, parfois lchelle europenne. Le rseau peut devenir un outil tendant les capacits du LAN traditionnel Ethernet, en saffranchissant de la distance et du nombre de rseaux intermdiaires (domaines IP). Ainsi il apporte une synergie supplmentaire favorisant le partage et lchange des ressources et connaissances au niveau rgional, national, europen et au-del.

Organisme A Site 2

Organisme A Site 3

Organisme A Site 4 Organisme A Site 1 10/100 VLAN A PE 1 Gbps VLAN A PE Projet X Site 1 1 Gbps VLAN B 1 Gbps VLAN B 10/100 VLAN A PE PE PE 10/100 VLAN A 10/100 VLAN A 10/100 VLAN B Organisme A Site 5

Projet X Site 3

IP/MPLS
PE PE

1 Gbps VLAN A

Projet X Site 2

Organisme A Site 1

Figure 1 VPLS dlivre un service Ethernet multipoint--multipoint qui peut stendre plus dune zone mtropolitaine

Le rseau de loprateur de services IP/MPLS est constitu dun point de vue fonctionnel de routeurs de priphrie PE (Provider Edge) et de routeurs de cur P (Provider). Dans la pratique, il est vident que des routeurs peuvent avoir la fois le rle dun PE et dun P, en particulier dans les rseaux de Recherche et Enseignement qui sont rarement hirarchiss. Avant de dtailler les spcificits de VPLS, il est important de noter que chaque PE a un tunnel tabli vers chacun des autres PE. Ce tunnel peut tre de type MPLS, gnr de manire dynamique avec LDP2 ou RSVP-TE3, ou de manire statique dans certains cas particuliers. Mais ces tunnels peuvent aussi tre de type GRE ou IPSec, ce qui permet de ne pas imposer lusage de MPLS pour la commutation dans le cur du rseau. Le point fondamental est que dans cette architecture, toute lintelligence (la connaissance des VPNs) se trouve uniquement en priphrie, et les routeurs de cur nont aucune information sur les VPNs ou les routes IP extrieures au rseau de loprateur. Ce modle assure une distribution de lintelligence dans les PE (un PE naura connaissance dun VPN que si il en a besoin, cest dire si il connecte directement des clients ce VPN), et la commutation dans le cur est assure par les routeurs P traverss par des tunnels (MPLS ou GRE ou IPSec) reliant les routeurs PE. Ce modle sert de base aux VPNs MPLS de niveau 2 ou 3, et donc aussi VPLS que nous allons dcrire dans la suite de cet article. Nous considrons comme point de dpart que la configuration dcrite cidessus est dploye. Chaque routeur PE (Provide Edge) en priphrie du rseau IP/MPLS de loprateur intgre les fonctionnalits VPLS. Chaque domaine VPLS est constitu dun certain nombre de PE (les PE connectant un ou plusieurs sites de ce domaine VPLS), chacun activant une instance VPLS pour ce domaine. Un maillage complet de Label Switched Paths (LSPs) doit tre construit entre toutes les instances VPLS sur chacun des PE pour un domaine VPLS donn. En fonction de limplmentation VPLS utilise, lorsquun PE ou une instance VPLS est ajout, leffort ncessaire pour tablir un maillage de LSP peut varier considrablement. Une fois le maillage construit, linstance VPLS dun PE est prte recevoir des trames Ethernet dun site client, et peut commuter ces trames sur le LSP appropri en fonction de ladresse MAC destination. Cela est possible car VPLS permet au routeur PE dagir comme un commutateur Ethernet avec une table dadresses MAC par instance VPLS. En dautres termes, linstance VPLS sur le routeur PE dispose dune table MAC alimente par apprentissage des adresses MAC sources lorsque les trames Ethernet entrent par des ports physiques ou logiques ddis, exactement de la mme faon quavec un commutateur Ethernet traditionnel. Une fois que la trame Ethernet arrive sur un port dentre connectant le client, ladresse MAC destination est recherche dans la table MAC et la trame est transmise sans altration (si, bien sur, ladresse MAC correspondante se trouve dans la table MAC) lintrieur du LSP qui va la dlivrer au PE adquat connectant le site distant vis. Si ladresse MAC nest pas dans la table dadresses MAC, la trame Ethernet est rplique et transmise tous les ports logiques associs cette instance VPLS (ports locaux ou LSPs vers les autres PE du domaine VPLS), except le port dentre par lequel la trame est arrive. Il est aussi important de noter que les PEs traitant les paquets en sortie (cest dire venant du cur du backbone et destins sortir vers les sites clients) ne transmettent jamais des trames Ethernet en retour vers le cur pour viter toute boucle Ethernet dans le rseau. Le PE de sortie inspecte ladresse MAC source et lajoute sa table MAC avec le PE dentre du rseau identifi par le label utilis par la trame Ethernet. La trame Ethernet est ainsi dlivre au site client, puis arrive destination. Les adresses MAC nayant pas t utilises aprs un certain temps sont automatiquement limines de la table, exactement comme sur un commutateur Ethernet. Du point de vue du client, le service apport par loprateur correspond lquivalent dune connexion de chaque site sur un commutateur Ethernet ddi, mais sans limitation de distance entre les sites.

2 3

Label Distribution Protocol (Protocole de distribution des tiquettes MPLS) Reservation Protocol for Traffic Engineering

Implmentations VPLS

Aujourdhui deux drafts principaux sont dbattus au niveau de lIETF et sont considrs par la majorit des constructeurs pour dvelopper leur solution. Le premier est http://www.ietf.org/internet-drafts/draft-kompella-ppvpn-vpls-02.txt, que nous appellerons draft Kompella , propos par Kireeti Kompella. Le second est http://www.ietf.org/internet-drafts/draft-ietfl2vpn-vpls-ldp-00.txt, que nous appellerons draft Lasserre-VKompella , propos par Marc Lasserre et Vach Kompella. Chacun de ces deux modles peut tre dcrit par deux caractristiques fondamentales : - Dcouverte automatique (Auto-Discovery) : quelle mthode est utilise par chacun des routeurs de priphrie (PE) pour participer un domaine VPLS et pour trouver les autres PEs partenaires ? - Signalisation : quel protocole est utilis pour tablir des tunnels MPLS et distribuer des labels (tiquettes) entre les PEs pour assurer le dmultiplexage ? Modle dimplmentation de VPLS Draft Kompella VPLS Draft Lasserre-VKompella VPLS Dcouverte Automatique BGP Non dfini Signalisation BGP LDP

4.1

Dcouverte Automatique

La dcouverte automatique est une composante essentielle pour aider loprateur dployer un service grande chelle tout en minimisant les cots oprationnels, car ce mcanisme permet la cration automatique dun maillage complet de LSP pour un domaine VPLS donn4. Afin de bien comprendre le mcanisme de dcouverte automatique, considrons quun nouveau routeur PE est ajout en priphrie du rseau de loprateur, et que le ncessaire ait t fait pour assurer sa connectivit avec les autres PEs par des tunnels (MPLS ou GRE ou IPSec). Selon lapproche BGP propose dans le draft Kompella, une simple session BGP (plus prcisment MP-iBGP) est tablie entre le PE et le Route Reflector5 (distributeur de routes BGP). Ensuite le nouveau PE va se joindre un domaine VPLS ds lors que linstance VPLS est configure sur ce routeur PE, et que un ou plusieurs ports connectant le client sur ce PE est associ cette instance VPLS. Chaque domaine VPLS est identifi par une Route Target (attribut de la communaut tendue de BGP) particulire, qui est spcifie dans la configuration de linstance VPLS. Une fois cette opration ralise, le PE informe via le Route Reflector de son appartenance ce domaine VPLS aux autres PEs faisant partie de ce domaine VPLS. En effet, lannonce BGP transporte la Route Target6 ( cible de la route) de la communaut BGP tendue) configure pour ce domaine VPLS, et cest prcisment cette communaut qui identifie lannonce dappartenance de nouveau PE au domaine VPLS. Par la suite tous les PEs ont pris connaissance du nouveau PE, et les PEs membres de ce domaine VPLS ont toutes les informations ncessaires pour tablir des LSPs avec ce nouveau PE de manire automatique. Etant donn que le draft Lasserre-VKompella ne spcifie pas de mthode de dcouverte automatique, loprateur de service doit informer le nouveau PE de manire explicite quels PEs font partie du mme domaine VPLS. Pour chaque instance VPLS prsente dans un PE, loprateur doit configurer ce PE avec les adresses de tous les PEs faisant partie du mme domaine VPLS. Cette information peut tre stocke de plusieurs manire : dans une base de donnes LDAP, un systme de configuration ou un simple cahier/fichier. Cependant toutes ces options requirent une intense activit oprationnelle et sont soumises dventuelles erreurs humaines. Diverses options ont t discutes pour ajouter une dcouverte automatique au draft Lasserre-VKompella :

4 En rappel, il ne sagit pas ici de la cration de tunnels pour la commutation (ou routage) de lensemble des paquets entre les PE (cela tant suppos tre dj tabli), mais de la cration de tunnels de second niveau, spcifiques un domaine VPLS donn, et permettant aux PEs de grer le plan de donnes (commutation) pour les sites connects ce domaine VPLS. 5 Le Route Reflector a pour fonction essentielle de distribuer les routes des PEs de manire centralise (par un routeur choisi) et ainsi augmenter le facteur dchelle dune architecture iBGP (internal BGP). Pour assurer une redondance, un PE peut tablir des sessions BGP avec dautres Route Reflectors. Bien sur, dans le cas ou loprateur nutilise pas de Route Reflector, nous aurons un maillage complet de sessions BGP entre les PEs, tels que dfini par les rgles dingnierie du protocole BGP. 6 La Route Target permet dajouter lannonce BGP une couleur indiquant lappartenance du PE un domaine VPLS donn. Les PEs qui reoivent lannonce ont une Routing Policy (rgle de routage) leur indiquant dimporter dans linstance VPLS (appartenant au domaine) les routes associes cette Route Target.

Utiliser le protocole BGP7 : cette option implique lusage de deux protocoles diffrents pour grer VPLS, lun pour la dcouverte automatique (BGP), lautre pour la signalisation (LDP), ce qui nous amnerait plus de complexit, plus de maintien dtats dans le rseau, et plus dinteractions inter-protocoles. Modifier LDP pour raliser la dcouverte automatique : cette solution impliquerait dajouter LDP les mcanismes quivalents BGP, savoir les communauts et Route Target, ce qui pose la question de la justification de dvelopper des mcanismes qui existent dj dans le protocole BGP. Dvelopper une solution base sur DNS ou une autre base de donnes centralise ventuellement propritaire : ce type de solution centralise devra tre attentivement analyse, en particulier concernant sa capacit dusage grande chelle.

Il est intressant de noter que cest le mme problme de dcouverte automatique qui a t rencontr plusieurs fois par le pass, et que la rponse dans la plupart des cas a finalement point vers BGP. Par exemple cela concernait les discussions pour les routeurs virtuels et les VPNs de niveau 3 dfinis dans la RFC 2547bis. Une raison souvent voque contre BGP et que cette solution est trop complexe . La ralit est que BGP est aussi simple utiliser par un oprateur de service quun autre protocole comme OSPF, mais peut tre plus complexe implmenter par les quipementiers, ce qui peut gnrer une certaine motivation anti-BGP.

4.2

Signalisation

Le modle VPLS support par le draft Kompella prconise lusage de BGP pour la signalisation, cest dire la distribution des labels (tiquettes) pour ltablissement des LSPs entre les PEs pour un domaine VPLS particulier. Par contre le modle dfini dans le draft Lasserre-VKompella est bas sur lusage de LDP comme mcanisme de signalisation. Pour chacun des modles, le principe consiste a changer des labels pour tablir les LSPs entre les PEs pour un domaine VPLS donn. De nombreuses discussions ont lieu sur les avantages et inconvnients de chaque solution. Concernant lusage de BGP comme protocole de signalisation, les arguments contre cette solution sont gnralement : - BGP est trop complexe utiliser, - BGP ncessite une pr-allocation de blocs de labels. On peut sinterroger sur le poids de cet argumentaire : dune part, de nombreux oprateurs (principalement des oprateurs commerciaux) ont aujourdhui deploy des VPNs de niveau 3 selon la RFC 2547 (et son extension draft 2547bis) base sur BGP. Dautre part, la prdfinition des blocs na pas dimpact direct sur les ressources jusqu' ce que les labels eux-mmes soient rellement allous et configurs. Et puis le principe de pr-allocation nest pas obligatoire, cest dire quil est toujours possible de ne pas pr-allouer de bloc, et dans ce cas cela fonctionne comme avec LDP, cest dire manuellement. Dun autre cot, il y a un certain nombre de limitations avec la signalisation LDP. Premirement, tant donn que le draft Laserre VKompella ne dfinit pas de mcanisme de dcouverte automatique, il est ncessaire chaque fois quun PE joint un domaine VPLS de manuellement (action de loprateur) rechercher les autres PEs faisant partie du mme domaine VPLS. Une fois cette information obtenue, il faut construire un maillage complet de sessions LDP entre ce PE et tous les autres PEs faisant partie de ce domaine VPLS. Ce grand nombre de LSPs (maillage facteur exponentiel) est ncessaire car LDP na pas lavantage de pouvoir bnficier dune architecture comme BGP et ses Route Reflectors. Pour les oprateurs offrant ce type de service peu de clients ayant peu de sites, la charge gnre par LDP nest probablement pas notable. Cependant cette charge augmente de manire trs significative avec la croissance du service.

en plus de LDP qui est la solution dfinie dans le draft Lasserre-VKompella pour la signalisation, voir chapitre 4.2

PE 1

PE 4

PE 2

PE 5

PE 3 PE 7

PE 6 Nouveau PE

Sessions LDP existances Sessions LDP nouvelles

Figure 2 lutilisation de LDP requiert un maillage complet de sessions LDP, qui doivent tre tablies chaque fois que lon ajoute un nouveau PE.

Deuximement, cet enjeu oprationnel consistant grer un nombre de sessions LDP dordre fonction de N puissance 2 devient encore plus significatif si loprateur prend la dcision dauthentifier les sessions de signalisation LDP avec MD5 pour renforcer la scurit de son rseau. Car dans un cas de maillage complet de sessions LDP, les clefs MD5 doivent tre configures chaque extrmit de toutes les sessions LDP. Troisimement, tant donn le risque li la transmission ventuelle des informations tous les routeurs en cas de mauvaise configuration du protocole, il est trs utile de pouvoir rapidement dtecter des erreurs et lorigine de ces erreurs. Le problme avec LDP est quune connexion PE1-PE2 pour un domaine VPLS donn peut avoir un diffrent numro ID que la connexion PE1-PE3 pour ce mme domaine. De plus, ce numro ID nest pas structur et donc rend assez difficile toute identification. Quatrimement, dans le cas o un domaine VPLS doit tre tendu plusieurs Autonomous System (Systme Autonome ou AS)8, la signification globale des 32 bits utiliss par le VCID de la signalisation LDP requiert une coordination manuelle intensive par les quipes oprationnelles des diffrents AS. En dautres termes, si un domaine VPLS stend sur 3 ASs, les trois oprateurs devront utiliser le mme VCID LDP pour ce VPLS. Enfin, si le draft Lasserre-VKompella prconise un jour lutilisation de BGP pour la dcouverte automatique, alors cela ncessitera une synchronisation entre BGP et LDP. Le draft Kompella qui base la signalisation sur le protocole BGP ne souffre pas des limitations dcrites ci-dessus. En effet, lorsquun PE est ajout, une seule session BGP entre lui et le Route Reflector est requise. Si la session ncessite dtre authentifie avec MD5, alors seuls les 2 quipements chaque extrmit de la session BGP requirent une configuration des clefs MD5. Lorsquune nouvelle instance VPLS est configure sur ce PE, il avertit alors sa disponibilit du service via le Route Reflector, qui redistribue linformation pour tous les PEs concerns. Ensuite, la signalisation BGP construit automatiquement le maillage de LSPs pour cette instance VPLS. Toutes les connexions vers un domaine VPLS donn sont identifies par un ID unique (le Route Target), et qui dispose dune structure offrant doffice un partitionnement hirarchique. Ce dernier point rend tout diagnostic de dysfonctionnement beaucoup plus simple pour lquipe oprationnelle. De plus, si le domaine VPLS doit stendre sur plusieurs Systmes Autonomes (ASs), pouvant tre chacun gr par un oprateur diffrent (ce qui est un cas trs courant dans les rseaux de Recherche et Enseignement), lutilisation dune Route Target identifiant un VPLS particulier simplifie grandement les aspect oprationnels, car chaque AS peut assigner une Route Target particulire pour ce VPLS selon ses propres rgles internes. Cela est possible car la Route Target (de la communaut tendue) intgre le numro de Systme Autonome et ce numro est globalement unique car allou par un organisme officiel (par exemple le RIPE en Europe).
8

La problmatique inter-domaine pour des services de bout en bout sera tudie dans le chapitre 5

Enfin, lutilisation de BGP a la fois pour la dcouverte automatique et la signalisation implique une synchronisation entre les actions de dcouverte et de signalisation, et les quipes techniques nont besoin de matriser et de grer quun seul protocole. Ce protocole BGP est par ailleurs dj utilis pour la dcouverte automatique et la signalisation des VPN de niveau 3 de type 2547bis, la solution de service VPN IP la plus dploye au monde ce jour.

PE RR PE 2

PE 4

PE 5

PE 3 PE 7

PE 6 Nouveau PE

Sessions BGP existantes Session BGP nouvelle

Figure 3 Une approche simplifie ou les sessions BGP doivent tre configures uniquement entre le nouveau PE et le Route Reflector (ou les RR en cas de redondance), de manire identique au dploiement dun service VPN de niveau 3 la 2547bis. De plus, le nombre de domaines VPLS nimpacte pas le nombre de sessions BGP.

Le bout en bout avec linter-domaine

Les rseaux de Recherche et Education ont pour vocation de pouvoir dlivrer des services rseaux servant la communaut distribue sur de nombreux domaines IP distincts, que ce soit au niveau mtropolitain, rgional, national ou Europen. Quel que soit le projet ou la communaut considre, il y a une probabilit non ngligeable que des sites (ou VLANs) soient connects via plusieurs domaines distincts. Nous entendons par domaine IP un Systme Autonome AS (au sens BGP), qui peut correspondre directement un domaine administratif (par exemple un rseau mtropolitain). Il se peut aussi quun rseau administratif contienne plusieurs ASs (pour les gros rseaux). Lapproche du draft Kompella tant bas sur BGP, il hrite toutes les capacits dextension des services VPN au del dun AS unique. En effet les solutions carriers carriers et Inter-AS/Inter-provider sont dcrites dans le draft 2547bis (extensions de la RFC 2547). Nous prsentons ici loption C du draft, qui est la plus adapte pour dployer des services VPLS grande chelle. Il est important de noter que la description technique qui suit nest pas spcifique au service VPLS. En effet, ces mcanismes sappliquent de manire identique pour les services de VPN IP, Layer 2 (draft Kompella Layer 2 VPN) et VPLS (draft Kompella VPLS). Prenons lexemple dun domaine VPLS que nous voulons tendre sur 3 domaines diffrents, tels que dcrit dans la figure 4.

MP-eBGP (pour le domaine VPLS)

(pour routes internes des oprateurs VPLS) (pour routes internes

MP-iBGP

I-BGP IGP + LDP (AS 1) PE_3

VFT

Direct E-BGP

des oprateurs VPLS)

Site 1

R_1

C E_ 1 (ASBR)

PE_1 (ASBR) VRF

Oprateur de transit IGP + LDP P

(pour routes internes des oprateurs VPLS

Direct E-BGP

I-BGP IGP + LDP (AS 2) R_2 PE_4

VFT

PE_2 (ASBR) VRF

C E_ 2 (ASBR)

Site 2

VFT

VFT

Site 1
Commutation: PE_3 pousse trois labels

Site 2

push push push pop

swap push

push

pop

swap

pop push

pop

pop

Plan de commutation

Figure 4 VPN inter-domaine : option C de la 2547Bis

Pour tendre le modle de lAS unique plusieurs ASs, il faut pouvoir tablir des LSPs entre PEs qui ne sont pas dans le mme AS, afin dobtenir une commutation de bout en bout (sans routage) entre PE3 et PE4. Une solution consiste pour les oprateurs de service VPLS (AS 1 et AS 2) changer leurs adresses internes (adresse des PEs supportant des instances VPLS) sous forme de VPN de niveau 3 par loprateur de transit. Ces routes sont maintenues dans des tables VRF9 ddies. Les sessions BGP entre AS1 (ou AS2) et loprateur de transit se font en E-BGP et chaque route est change avec un label ce qui permet de construire le plan de commutation. Loprateur de transit gre ces routes sous forme de VPN de niveau 3 pour assurer une isolation avec le reste des routes (par exemple de lInternet). Des sessions iBGP entre PEs au sein de chaque AS permettent une distribution locale (intra-AS) des routes externes, cest dire appartenant lAS distant. Ces changes de routes avec iBGP se font aussi en y affectant des labels associs. Le rsultat de cette opration apporte une connectivit MPLS (LSP) de bout en bout entre PE3 et PE4. PE3 et PE4 contiennent les informations locales de chaque instance VPLS pour lesquelles des sites sont directement connects. A chaque instance VPLS correspond une VPLS Forwarding Table (VFT). Il est maintenant possible dtablir une session Multi-hop MP-eBGP entre PE3 et PE4 selon le draft Kompella, et ainsi assurer la dcouverte automatique et la signalisation requises pour activer le domaine VPLS de bout en bout. Pour cette partie, la seule diffrence par rapport au chapitre 4 est lactivation dune session Multi-hop MP-eBGP au lieu dune session iBGP. Au niveau du plan de commutation, PE3 recevant un paquet Ethernet par le site 1 du domaine VPLS bleu et destination du site 2, va encapsuler la trame avec 3 labels MPLS. Le premier (de lintrieur vers lextrieur) correspond au label identifiant linstance VPLS au niveau de PE4. Le deuxime label correspond au LSP permettant la commutation entre PE3 et PE4 au niveau de PE1, CE1, PE2 et CE2. Et le troisime label correspond au LSP permettant la commutation au sein de AS1 (routeur R1). Dans la figure 4, la fonction de push correspond lajout dun label MPLS, la fonction pop correspond la suppression dun label, et la fonction de swap correspond lchange de label10.

10

VPN Routing and Forwarding table le label nayant quune fonction locale, doit changer chaque saut de commutation

Il est intressant de noter que seul le premier label (label intrieur) est spcifique au service VPLS (plus prcisment linstance VPLS du PE de sortie). La solution peut en effet ne pas sappuyer sur un service MPLS gnralis pour grer le plan de commutation. Car il est possible dtablir un tunnel GRE (ou IPSEC) entre PE3 et PE4, et dutiliser uniquement le label en charge du service VPLS. La solution choisie dpendra de nombreux facteurs et sera fonction notamment de lchelle de dploiement recherche. Enfin lexemple ci-dessus est bas sur des connexions BGP directement entre PEs pour bien comprendre les mcanismes mis en jeu. Cependant, pour des besoins de dploiement grande chelle, le modle sappuiera fortement sur lusage de Route Reflector, ce qui limite fortement les charges oprationnelles. Dans ce cas, il ny a quune seule session BGP entre les deux Route Reflectors (AS1 et AS2). LAS intermdiaire na bien sr pas connaissance du service VPLS (que ce soit ltat MLPS par domaine VPLS ou les tables dadresses MAC par instance VPLS). La signalisation ralise entre les deux Route Reflectors est quivalente (mais plus efficace) quun maillage complet de sessions BGP entre les PEs de lAS1 et lAS2. Lorsque le PE 3 envoie du trafic en mode broadcast (cest dire avant davoir appris ladresse MAC et sa relle destination), tous les PEs de lAS1 et lAS2 faisant partie du domaine VPLS concern reoivent le paquet. La solution propose dans la Figure 4 est base sur un choix dingnierie, mais dautres solutions peuvent tre tudies. Par exemple : Loprateur de transit pourrait proposer un service IP/MPLS mais sans VPN de niveau 3. Dans ce cas les routes internes de chaque oprateur de service VPLS seront changes (avec des labels associs pour construire les LSPs) par la table de routage globale de loprateur de transit. Cette solution noffre pas de diffrence au niveau du plan de commutation mais a des incidences sur le plan de contrle. En effet, elle sous-entend que les oprateurs de service VPLS acceptent de voir partager leurs adresses de PE internes dans une table de routage globale de loprateur de transit, ventuellement avec des rgles de routage (policy routing) pour ne pas propager ces routes dautres domaines. Loprateur de transit pourrait proposer un service de connexion point point de niveau 2 (par exemple Layer 2 VPN) reliant CE1 et CE2. Dans ce cas, les deux oprateurs de service VPLS se retrouvent directement connects et peuvent changer avec eBGP leurs routes internes (avec labels associs) sans impliquer loprateur de transit au niveau 3. Il apparat travers ces exemples que plusieurs solutions (en ralit combinaisons de plusieurs services bass sur les mmes principes) sont envisageables. Lexemple de la Figure 5 permet dtendre le modle de la Figure 4 une situation plus complexe o des universits sont connectes via des rseaux mtropolitains ou rgionaux, nationaux et le backbone paneuropen.

MP-eBGP Routes internes des rseaux mtro/rgionaux

MP-eBGP VPLS Connection Table

MP-iBGP Routes internes des rseaux nationaux

IGP VFT
Mtro REN A (AS 1)

E-BGP VRF

E-BGP
National REN B (AS 2)

E-BGP

E-BGP
Mtro REN D (AS 5)

IGP VFT CE

CE

Pan VRF Europen VRF (AS 3)

National REN C VRF (AS 4)

Maintient linstance VPLS de luniversit

Maintient les routes internes de Metr. REN A + D

Maintient les Maintient les routes internes de routes internes de Nat. REN B + C Nat. REN B + C

Maintient les routes internes de Metr. REN A + D

Maintient linstance VPLS de luniversit

Figure 5 Exemple doprations Inter-domaine rcursives

Les mmes mcanismes prcdemment dcrits peuvent sappliquer dans ce cas de figure de manire rcursive, avec un usage prconis de Route Reflectors. Le sigle REN correspond Research & Education Networks (rseaux de Recherche et Enseignement). Le draft Lasserre-VKompella ne traite pas la problmatique inter-domaine et prcise que cela sera tudi dans une version future.

Conclusion

VPLS apporte un service Ethernet multipoint--multipoint sur une infrastructure IP/MPLS au niveau mtropolitain ou longue distance. Diffrentes approches sont tudies dans le cadre de lIETF et des implmentations oprationnelles sont aujourdhui proposes par les quipementiers. Les services Ethernet sont largement utiliss dans le cadre des rseaux Recherche et Enseignement, en particulier dans les rseaux mtropolitains. La technologie permet aujourdhui dtudier et envisager la dlivrance de services Ethernet innovants par et pour la communaut Recherche et Enseignement, non seulement au niveau local, mais aussi de manire plus globale dans un cadre multi-domaines. Il y a aujourdhui peu de solutions VPLS disponibles. Juniper Networks dlivre une solution VPLS base sur le draft Kompella depuis la version JUNOS 5.711 pour les routeurs de la srie M et T. Limplmentation VPLS de Juniper Networks est aujourdhui complte et destine aux rseaux de production. Cela veut dire que la solution intgre les mcanismes de dcouverte automatique, lchange des labels, lapprentissage des adresses MAC et fonction dinondation, et fonctionne aussi en environnement inter-domaine (inter-AS et inter-oprateur). Ce dernier point mriterait une rflexion plus approfondie de la part des rseaux et institutions de Recherche & Enseignement. En effet, comme nous lavons vu dans le chapitre 5, plusieurs options sont envisageables avec la technologie existante. Cette tude base sur une bonne coordination des entits intresses devrait la fois tudier les interfaces techniques entre les domaines (dfinir le service de transit, prciser les informations changes et la politique de routage) et les interfaces oprationnelles. Des changements importants ont t raliss avec BGP ces dernires annes (permettant entre autres lactivation interdomaine des services multicast et IPv6), et une nouvelle phase dmarre pour prolonger les services de VPNs plusieurs domaines, la fois pour des VPNs de niveau 3, de niveau 2 point a point, et Ethernet multipoint-a-multipoint (VPLS). Comme pour le Multicast ou IPv6, cela demanderait une rvision au niveau local ou global des interfaces dinterconnexion entre les rseaux de Recherche et Enseignement.

Rfrences
[1] Kompella K., et al, Virtual Private LAN Service, draft-kompella-ppvpn-vpls-02.txt, Mai 2003. [2] Lasserre M., Kompella V., et al, Virtual Private LAN Services over MPLS, draft-ietf-l2vpn-vpls-ldp-00.txt, Juin 2003. [3] Rosen E., Rekhter Y., BGP/MPLS VPNs, RFC2547, Mars 1999 [4] Rosen E., Rekhter Y., et. al., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Mai 2003. [5] Capuano M., VPLS : Scalable Transparent LAN Services (White Paper Juniper Networks), 2003 [6] Semeria Chuck, RFC 2547bis: BGP/MPLS VPN. Hierarchical and Recursive Applications (White Paper Juniper Networks), 2001

11

Tous les routeurs de la srie M et T de Juniper Networks utilisent le mme logiciel JUNOS (code binaire identique). Tous les paquets (IPv4, IPv6, MPLS, etc) sont routs/commuts (mais aussi filtrs, compts, limits, etc) en hardware par des ASICs spcifiques.