Vous êtes sur la page 1sur 106

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

MEMOIRE

at
io

le DIPLOME dINGENIEUR CNAM

Prsent en vue dobtenir

SPECIALITE : Informatique

Ev
a

Par

lu

OPTION : Rseaux, Systmes et Multimdia

Nicolas GARNIER

PD
F

Encadr par Xavier JEANNIN - RENATER

tude, conception et dploiement des technologies dingnierie

Ex

pe

rt

de trafic sur linfrastructure de production MPLS de RENATER

JURY
PRESIDENT
MEMBRES

Soutenu le 26 fvrier 2013

Jean Pierre Arnaud


Franoise Sailhan
Nicolas Pioch

rt

pe

Ex
PD
F

at
io

lu

Ev
a

Remerciements
Je souhaite remercier tout particulirement Xavier Jeannin, mon tuteur de stage, qui de
par son exprience, ses connaissances, sa curiosit et sa bonne humeur ma permis de
mener terme ce projet. Je le remercie galement davoir partag avec moi son bureau
et ses bonzas pendant 9 mois.
Je tiens remercier les membres des quipes de RENATER - Frdric Loui, Lionel David,
Thierry Bono, Simon Muyal, Anthony Fisson ; de BT - Florence Picard et Dahlia Gokana ;

at
io

et de Cisco - Jrme Durand et Vincent Makowski, qui mont transmis leurs savoir-faire.

lu

Je remercie galement Patrick Donath, directeur du GIP RENATER, et Laurent Gyd,

Ev
a

directeur technique, pour mavoir permis dintgrer RENATER et de financer ce projet,


notamment les dplacements aux Etats-Unis pour le CPOC, qui a t une formidable

PD
F

exprience pour un futur ingnieur rseaux.

Je remercie mes professeurs du CNAM, Jean Pierre Arnaud, responsable de la chaire

rt

rseaux et mon tuteur pdagogique pour ce mmoire, et Nicolas Pioch, pour leurs

Ex

pe

enseignements des rseaux, vivant et de qualit.

Enfin, je remercie ma compagne, Clia Pasquetti, pour son soutien et son aide
inconditionnelle durant ces quatre annes de cours du soir au CNAM.

rt

pe

Ex
PD
F

at
io

lu

Ev
a

Glossaire
AS
BGP
BT
CERN
CC-IN2P3

at
io

CoS
CR-LDP
CSPF

Ev
a

lu

DSCP
DWDM
ECMP

rt
pe

Ex

IOS

PD
F

FRR
GRIF
GTR
HNO
IGP
IETF

IP
IS-IS
ISR
L2VPN
L2VPN-PW
L3VPN

Autonomous System : ensemble de rseaux informatiques IP


intgrs Internet et dont la politique de routage est cohrente.
Border Gateway Protocol : Protocole dchange de routes entre
diffrents systme autonomes AS.
British Telecom Global Services, le prestataire qui assure la
maintenance, la configuration et la supervision de RENATER
Organisation Europenne pour la Recherche Nuclaire
(originellement Conseil Europen pour la Recherche Nuclaire).
Centre de Calcul de lInstitut National de Physique Nuclaire et de
Physique des Particules.
Classes of Services : Classes de services.
Constraint Routing LDP : Extension de LDP pour ltablissement de
tunnels MPLS-TE.
Constraint Shortest Path First : Algorithme de calcul du chemin le
plus court dans un graphe contraint.
Differentiated Services Code Point : Code de diffrenciation de
services dans un paquet IP.
Dense Wavelength Division Multiplexing : Multiplexage optique
dense de longueur donde.
Equal-cost multi-path routing : Partage de charge cots de liens
gaux.
Fast ReRoute : Mcanisme de rsilience MPLS qui procure une
convergence rapide en cas de panne dun nud ou dun lien.
Grille de Recherche dIle de France.
Garanties de Temps de Rtablissement.
Heures Non Ouvres
Interior Gateway Protocol : Protocole de routage interne.
Internet Engineering Task Force : Littralement Dtachement
d'ingnierie d'Internet . Groupe informel, international, qui
produit la plupart des nouveaux standards d'Internet (RFC).
Internetwork Operating System : Le Systme d'exploitation pour
la connexion des rseaux produit par Cisco pour ses quipements
rseaux.
Internet Protocol : Protocole dadressage, en versions v4 et v6.
Intermediate System to Intermediate System : Protocole de
routage interne multi-protocoles tats de lien.
Service RENATER Infrastructures pour les Services Rseaux
Layer 2 Virtual Private Network : Interconnexion de rseaux privs
sur la couche 2 liaison .
Layer 2 Virtual Private Network Pseudo Wire : Emulation dune
interconnexion directe Ethernet via un L2VPN.
Layer 3 Virtual Private Network : Interconnexion de rseaux privs
sur la couche 3 rseau .

LDP
LHC

LHCONE
LHCOPN
LSP-TE

MPLS

NHOP et NNHOP

lu

NOC

Ev
a

NR
NREN

PD
F

OSPF
QoS

Ex

RFC

pe

RSVP-TE

rt

RENATER

TE
T0/1/2/3
VRF

at
io

MPLS-TE

Label Distribution Protocol : Protocole standardis pour l'change


d'information sur les tiquettes (labels) entre routeurs MPLS.
Large Hardon Collider : Littralement Grand collisionneur de
hadrons . Acclrateur de particule situ entre la France et la
Suisse au CERN.
Large Hardon Collider Open Network Environnement : Rseau
distribu de transfert des donnes des expriences LHC.
Large Hardon Collider Optical Private Network : Rseau
hirarchique de transfert des donnes des expriences LHC.
Label Switched Path Traffic Engineering : Connexion point point
unidirectionnelle, dans un contexte MPLS, laquelle est associ un
ensemble de paramtres TE.
Multi Protocol Label Switching : Protocole de commutation de
labels. pouvant tre utilis pour transporter tout type de trafic.
Multi-Protocol Label Switching Traffic Engineering : Extension
dingnierie de trafic pour MPLS.
Next HOP / NextNext HOP : Noeud joindre dans le mcanisme
FRR.
Network Operations Center : Service ou prestataire charg du
contrle et de la maintenance dun rseau.
Nud RENATER : Point de prsence dun ou plusieurs quipements
de cur de rseau RENATER.
National Research and Education Network : Rseau National pour
la Recherche et Leducation.
Open Shortest Path First : Protocole de routage interne IP tat
de liens .
Quality of Services : Ensemble de mcanismes et de conventions
qui dtermine le niveau de qualit vis sur un accs rseau.
Rseau National de tlcommunications pour la Technologie
l'Enseignement et la Recherche. NREN franais.
Resource Reservation Protocol Traffic Engineering : Protocole de
rservation de ressources Extension pour le TE.
Requests For Comments : Littralement demande de
commentaires . Srie numrote de documents publis par lIETF
dcrivant les aspects techniques dInternet.
Traffic Engineering : Ingnierie de trafic.
Tier 0/1/2/3 : Hirarchie de centres de calculs au sein des projets
LHCOPN et LHCONE
Virtual Routing and Forwarding : Routage et Transfert Virtuel.
Mcanisme qui permet dinstancier plusieurs routeurs virtuels dans
un mme routeur physique.

Table des matires


1

Introduction .................................................................................................................. 1

MPLS et Ingnierie de trafic ......................................................................................... 7

2.2

MPLS-TE ................................................................................................................. 8

2.3

Signalisation des LSP-TE ...................................................................................... 18

2.4

Conclusion partielle ............................................................................................. 23

at
io

tude du besoin .......................................................................................................... 24


Optimisation des liens de backup et contrle du trafic ...................................... 24

3.2

Projet LHCONE..................................................................................................... 24

3.3

Analyse du primtre rseau RENATER-5 ........................................................... 30

Ev
a

lu

3.1

Choix des solutions et faisabilit ................................................................................ 36


Protocole de tests ............................................................................................... 36

4.2

tablissement de tunnels MPLS-TE ..................................................................... 39

4.3

Utilisation des tunnels MPLS-TE.......................................................................... 50

4.4

Types de trafic supports par les tunnels MPLS-TE ............................................ 61

4.5

Gestion centralise de MPLS-TE.......................................................................... 64

rt

PD
F

4.1

pe

Enjeux et principes ................................................................................................ 7

Gnralisation et Dploiement .................................................................................. 65

Ex

2.1

5.1

Fonctionnalits MPLS-TE dans le primtre rseau R-5 ..................................... 65

5.2

Choix de mise en uvre du projet LHCONE ....................................................... 66

5.3

Validation sur lensemble du primtre ............................................................. 71

5.4

Dploiement ........................................................................................................ 82

5.5

Exploitation ......................................................................................................... 83

Rsultats et discussion................................................................................................ 84
6.1

Rsultats du projet .............................................................................................. 84

6.3

Perspective .......................................................................................................... 87

6.4

Bilan personnel.................................................................................................... 88

Appendices ................................................................................................................. 89
7.1

Table des illustrations ......................................................................................... 89

7.2

Rfrences ........................................................................................................... 90

Annexes ...................................................................................................................... 91
Etude de mtrologie RENATER............................................................................ 91

8.2

CPOC RENATER-5 TE ............................................................................................ 91

8.3

Supervision du tunnel MPLS-TE de test sur RENATER ........................................ 91

8.4

Base dexploitation des tunnels TE ..................................................................... 92

8.5

Etat du rseau aprs le dploiement de MPLS-TE .............................................. 93

rt

PD
F

Ev
a

lu

at
io

8.1

pe

Retour sur exprience ......................................................................................... 87

Ex

6.2

1 Introduction
Les expriences menes en Suisse et en France par le CERN sur le collisionneur de
particules Large Hardon Collider (LHC) gnrent une trs grande quantit de
donnes. Celles-ci sont distribues des centres de calculs internationaux, classs par
importance en Tier (T) 0, 1, 2 et 3.
Le T0 correspond au CERN, les T1 sont de grands centres de calculs mondiaux. En France
par exemple le CC-IN2P3 Lyon et le GRIF en Ile de France. Le T0 et les T1 sont relis au

rseau Large Hardon Collider Optical Private Network (LHCOPN). Les centres de

at
io

calcul dimportance moindre, T2 et T3, sont relis au T1 le plus proche via leurs
rseaux nationaux pour la recherche et lducation (NREN) respectifs.

lu

La distribution des donnes suit le schma darchitecture Monarch [1], o toutes les

Ev
a

donnes demandes par les T2 et T3 sont dabord rpliques sur le T1 de rattachement.


Ce schma nest pas optimal car il ncessite dimportants espaces de stockages de

Ex

pe

rt

PD
F

donnes sur les T1 et gnre beaucoup de trafic sur les liaisons T0-T1 et T1-T1.

Figure 1 - Distribution des donnes LHC dans le schma "Monarch"

Le Large Hardon Collider Open Network Environnement (LHCONE) est une phase
complmentaire au LHCOPN, qui vise crer un rseau dinterconnexion entre les T1, T2
et T3 des diffrents pays participant, afin damliorer les changes et transferts de
donnes.
RENATER,

le

Rseau

National

de

tlcommunications pour

la

Technologie

l'Enseignement et la Recherche, a la charge du projet LHCONE pour sa partie franaise.


1

Introduction
Le LHCONE France est compos dune architecture optique ddie et de circuits de
type Layer 2 Virtual Private Network (L2VPN). Ces derniers utilisent larchitecture de
production IP/MPLS de RENATER.
La bande passante utilise par les circuits transports dans ces L2VPN tant importante,
il est ncessaire de contrler leur influence globale sur le rseau et sur les
interconnexions vers le LHCONE international , Paris et Genve. Dans ce but, et afin
de ne pas augmenter court terme la capacit de ses liens et interconnexions, RENATER
a choisi dutiliser des mcanismes dingnierie de trafic (Traffic Engineering TE).

Ces dernires devront permettre :


Didentifier le chemin utilis par les circuits L2VPN du projet LHCONE.

De choisir un chemin utiliser.

Doptimiser lutilisation de linfrastructure rseau de RENATER, et donc

lu

at
io

Ev
a

de retarder de couteux investissements.

Les mcanismes dingnierie de trafic mis en uvre devront galement pouvoir tre

PD
F

rutiliss dans dautres projets, rendant le rseau RENATER TE compatible .

Ce mmoire prsente en premier lieu, dun point de vue thorique, les enjeux et
principes de lingnierie de trafic, ainsi que les standards dfinis par lindustrie pour

rt

MPLS. Nous ne dcrirons pas ici le mode de fonctionnement gnral de MPLS, mais

pe

seulement celui de ses extensions pour lingnierie de trafic.

Ex

Il aborde ensuite, du point de vue oprationnel, les besoins de RENATER en ingnierie de


trafic, les choix technologiques possibles, puis ltude de faisabilit et le dploiement de
la solution retenue. Les rsultats et conclusions sont enfin proposs.

Prsentation de RENATER
Le Groupement dIntrt Public RENATER a t constitu en janvier 1993 pour fdrer
les infrastructures de tlcommunication pour la recherche et lducation.
Les organismes membres du GIP RENATER sont de grands organismes de recherche :
CNRS, CPU, CEA, INRIA, CNES, INRA, INSERM, ONERA, CIRAD, IRSTEA, IRD, BRGM, ainsi

que le Ministre de lEnseignement suprieur et de la Recherche et le Ministre de


lducation Nationale.
Plus de 1300 sites sont raccords via les rseaux de collectes rgionaux au rseau
national RENATER, dont une centaine dj en IPv6. Ce rseau fournit une connectivit
nationale et internationale, il volue rgulirement en fonction de lvolution des
technologies et des capacits des infrastructures disponibles.
Le rseau RENATER, aujourdhui dans sa version 5bis, est compos dune infrastructure
mtropolitaine trs haut dbit, et de liaisons internationales haut dbit. RENATER est

aussi prsent dans les dpartements et territoires dOutre-Mer.

at
io

Le GIP RENATER est galement matre douvrage du SFINX, point dchanges entre
oprateurs cr en 1995.

Ev
a

lu

Le rseau RENATER fournit un service de connectivit IPv4 et IPv6 :

En complment de lunicast, RENATER propose un service multicast, disponible en mode


natif pour les deux versions du protocole IP (IPv4 et IPv6). Une offre de circuits ddis

PD
F

est disponible sur RENATER. Cette offre repose sur des technologies diverses (MPLS,
DWDM, etc).

Deux catgories de circuits sont disponibles :


Des circuits point--point qui permettent un service dinterconnexion prive

rt

pe

entre 2 tablissements.
Des circuits multipoints multipoints qui permettent dinterconnecter au sein

Ex

dun mme rseau priv plusieurs tablissements RENATER.

RENATER propose galement des services applicatifs tel que :

Une solution anti-spam et anti-virus.

Un service de Fdration dIdentits ducation Recherche.

Le service de mobilit rseau Eduroam.

Une plateforme de certification, pour les serveurs et les personnes.

Un service dinterconnexion dIPBXs pour les tablissements ayant dploy de la


ToIP.

Ex

pe

rt

PD
F

Ev
a

lu

at
io

Introduction

Figure 2 - Architecture rseau de RENATER

n
at
io
lu
Ev
a
Ex

pe

rt

PD
F

Figure 3 - Architecture de RENATER en Ile de France

Figure 4 - Organismes membres de RENATER

Plus dinformations peuvent tre trouves sur le site web de RENATER


http://www.renater.fr/.

Introduction

Ex

pe

rt

PD
F

Ev
a

lu

at
io

Lorganisation interne de RENATER est la suivante :

Figure 5 - Organigramme interne de RENATER

Ce projet sest droul, entre octobre 2011 et juin 2012, au sein de lquipe
Infrastructure pour les Services Rseaux (ISR) dont le rle est de piloter et de planifier
les volutions du cur de rseau RENATER.

2 MPLS et Ingnierie de trafic


2.1 Enjeux et principes
Les rseaux doprateurs sont aujourdhui confronts de nouveaux enjeux. La
croissance des dbits daccs, la convergence des services dits triple play (Internet,
voix/visioconfrence, tlvision/vido la demande), ou comme dans le cas prsent
dans cette tude, des projets scientifiques aux besoins et exigences particulires.
Ces volutions entranent une augmentation considrable des volumes de trafic et de
nouvelles contraintes en termes de qualit de service (QoS) et de disponibilit du

rseau. Des mcanismes supplmentaires dingnierie de trafic, de QoS et de

at
io

scurisation deviennent alors ncessaires.

lu

Lingnierie de trafic regroupe lensemble des mthodes et mcanismes de contrle du

Ev
a

routage permettant doptimiser lutilisation des ressources, tout en garantissant la QoS


(bande passante, dlais...). Lobjectif de ces mcanismes est de maximiser la quantit de
trafic pouvant transiter dans un rseau afin de retarder linvestissement dans de

PD
F

nouvelles infrastructures.

Des solutions dingnierie de trafic ont t proposes chaque volution des


technologies rseau. Nous allons nous concentrer ici sur celles qui sappliquent aux

rt

technologies IP [2] et MPLS [3], qui sont aujourdhui utiliss dans un nombre de rseaux

pe

doprateurs, dont RENATER.

Ex

Limitations du routage IP en termes dingnierie de trafic


Avec des rseaux IP, on dispose de peu doutils pour effectuer la fois du partage de
charge en plusieurs chemins, router explicitement du trafic en fonction de ses qualits et
ventuellement rserver des ressources.
Pour assurer ces fonctions, il est ncessaire de combiner des mcanismes de niveau 3,
comme les classes de services, le partage de charge, la manipulation de mtrique, et des
mcanismes de niveau 2, comme la configuration des circuits virtuels qui permet de
crer une topologie logique correspondant aux besoins. Ces combinaisons apportent de
la complexit, influent gnralement sur tout le trafic, et ont donc leurs limites.

MPLS et Ingnierie de trafic


Enfin le routage explicite propos par IPv4, IP source routing [RFC791], est inefficient
parce quil suppose que chaque paquet contienne la description du chemin emprunt
dans le rseau. Cela prsente plusieurs dfauts majeurs : des risques lis la scurit,
une surcharge importante des paquets, un traitement complexe dans les routeurs
internes du rseau pour chaque paquet. Ce mode na jamais vraiment t implment
et utilis, il est toutefois repris dans IPv6.

2.2 MPLS-TE
2.2.1 Prsentation

at
io

(Multi Protocol Label Switching - Traffic Engineering) [RFC2702].

Lingnierie de trafic applique aux rseaux MPLS est normalise sous le nom MPLS-TE

MPLS-TE permet ltablissement de LSP-TE (Label Switched Path Traffic Engineering),

lu

routs explicitement ou dynamiquement, en fonction de contraintes relative une

Ev
a

topologie TE. Ces LSP-TE peuvent tre assimils des connexions point--point, un
mode circuit est alors cr dans les rseaux IP/MPLS, sappuyant sur le routage
interne, mais fonctionnant en parallle.

PD
F

La technologie MPLS-TE permet galement de rpondre des exigences de haute


disponibilit et de scurisation des services notamment temps rels via le mcanisme
MPLS-TE Fast-Reroute.

pe

rt

Fonctionnalits notables proposes par MPLS-TE :


Cration de LSP-TE MPLS unidirectionnels, indpendants du routage IGP et

Ex

contraints par des critres de mtrique, de bande passante requise (fixe ou


adaptative), de dlai, etc.

Qualit de service, grce aux critres de bande passante, priorits


dtablissement et de maintien des tunnels et aux chemins prfrs (couleurs
administratives et affinits).

Reprise rapide sur incident, scurisation des LSP-TE (Fast-Reroute).

Prise en compte des diffrentes Classes de services (CoS).

Partage de charge entre plusieurs LSP-TE.

2.2.2 Architecture MPLS-TE


La partie suivante est une synthse des lments prsents dans le document MPLS :
applications lingnierie de trafic et la scurisation par J.L. Le Roux [4].

Routage par contrainte MPLS-TE

lu

at
io

Le routage MPLS-TE, dit par contrainte , peut tre dcompos suivant ces six tapes :

Ev
a

Figure 6 - Routage par contraintes MPLS-TE

En (1) et (2), se constitue une topologie TE, ou base de donnes TE (TEDB). Il sagit dun
graphe de rseau tendu dont les liens et les nuds possdent un ensemble de

PD
F

paramtres dingnierie de trafic. Ces derniers sont dtaills dans la partie 2.2.4.
Cette topologie TE est distribue et mise jour priodiquement dans lensemble du

rt

rseau par les protocoles de routage tats des liens classiques. Par exemple, OSPF ou

pe

ISIS ont t tendus pour TE en OSPF-TE [RFC3630] et ISIS-TE [RFC5305].

Ex

En (3), la cration de LSP-TE ou tunnels MPLS-TE. Il sagit de LSP MPLS routs de faon
explicite ou dynamique dans la topologie TE. Ils sont caractriss par un ensemble de
contraintes TE incluant la bande passante, le dlai maximum, le nombre de sauts
maximum, les lments (liens, nuds) inclure/exclure, la priorit, etc. Les paramtres
associs aux LSP-TE sont dtaills dans la partie 2.2.5.
Les tapes (4) et (5) dcrivent les calculs relatifs ltablissement ou la modification des
LSP-TE. On parle de mode distribu (Online) lorsque tous les calculs de LSP-TE sont
raliss localement sur les nuds de tte. A grande chelle, ce mode nest pas optimal.
Les nuds de tte risquent une surcharge et des inters blocages peuvent apparatre.

MPLS et Ingnierie de trafic


Il est aussi possible de dporter lensemble des traitements sur un serveur externe, qui
aura une vision complte de toute la topologie TE et de toutes les contraintes. Les
solutions adoptes pour le placement des LSP-TE seront alors optimales. On parle dans
ce cas de mode centralis (Offline).

Signalisation des LSP-TE


La mise en place dans le rseau des LSP-TE calculs en tapes (4) et (5) est ralise, dans
ltape (6), par les protocoles de signalisation TE, tels que CR-LDP [RFC3468] ou RSVP-TE
[RFC3209]. Ces protocoles ont galement la charge de remonter les informations et
alertes TE aux quipements de tte de LSP-TE. Leurs fonctionnements sont dcrits dans

at
io

la partie 2.3.

La performance de ces protocoles de signalisation permet aujourdhui MPLS-TE de

lu

rpondre des exigences de haute disponibilit et de scurisation des services temps

Ev
a

rels, via des mcanismes dadaptation et de protection avancs.

2.2.3 Types darchitecture et passage lchelle

PD
F

Nous allons dtailler ici les diffrentes darchitectures qui peuvent tre construites
autour de LSP-TE. On peut diffrencier deux types de LSP-TE, les primaires dont le rle
est de faire circuler du trafic, et les secondaires dont le rle est de protger les

rt

primaires.

pe

Architecture de LSP-TE primaires

Ex

Le premier mode darchitecture de LSP-TE primaires est appel TE stratgique. Il


sorganise autour dun maillage complet de LSP-TE entre les routeurs (full mesh en
anglais). Cette architecture est construite pour servir de base de commutation globale
dans le rseau.
Habituellement cette architecture est ralise entre les routeurs de cur de rseau
PP. Mais elle peut aussi tre mise en uvre entre les routeurs de bordure PEPE.
Pour N routeurs, le nombre de LSP-TE initi par chaque routeur est N(N-1). Il faut
ajouter ce nombre les LSP-TE en transit entre deux autres routeurs. Ce dernier
paramtre est dpendant de larchitecture physique du rseau (nombre de routeurs,

10

nombre de sauts, etc.), et est dautant plus important pour les routeurs de curs
fortement maills.
Au-del dun certain nombre de LSP, le mode de calcul des LSP centraliss (Offline)

at
io

devient indispensable pour le bon fonctionnement du rseau.

Ex

pe

rt

PD
F

Ev
a

lu

Figure 7 - Exemple de topologie TE stratgique : topologie physique

Figure 8 - Exemple de topologie TE stratgique : topologie logique

Les capacits de traitement et de mmoire des quipements donnes par les


quipementiers sont : pour Cisco en 2003, jusqu' 600 LSP-TE terminant sur un nud et
10.000 en transit, et pour Juniper, en Fvrier 2012, 10.000 LSP-TE terminaux et 64.000
en transit. Les matriels voluent donc dans le sens dune utilisation de plus en plus
importante de LSP-TE.

11

MPLS et Ingnierie de trafic


Le second mode darchitecture de LSP-TE primaire est dit TE tactique. On utilise ici des
LSP-TE pour des besoins ponctuels. Le nombre de LSP-TE est alors dtermin par les

at
io

pilotes du rseau.

lu

Figure 9 - Tunnels TE tactique : Exemple de rpartition entre les routeurs A et C

Ev
a

Complexit

La complexit du contrle, par les machines mais surtout pour les humains, croit en

Ex

pe

rt

PD
F

fonction du mode darchitecture TE et du nombre de nuds prsents dans le rseau.

Figure 10 - Complexit du contrle des architectures MPLS-TE

Architecture de tunnels de protection


Les LSP-TE peuvent tre utiliss en protection des liens dune architecture standard ou
dune architecture TE. On parle alors de Protection de la connectivit. Les routeurs
calculent des LSP-TE de protection, complets ou de re-routage rapide ( Fast-ReRoute
FRR). Seule la connectivit est prserve, pas forcment la bande passante. Il est donc
prfrable dutiliser galement des mcanismes de classification de trafic pour viter la
congestion dans un rseau dgrad.

12

Si les LSP-TE de protection rservent galement de la bande passante, on parle alors de


Protection de la bande passante.
Cette architecture est plus complexe mettre en uvre et maintenir. Il faut conjuguer
MPLS-TE et des mcanismes de QoS. Aussi, une bande passante disponible plus
importante, globalement dans le rseau, est requise.
Toutefois, cette architecture permet de garantir des accords de qualit de service
(Service Level Agreement) dfinis entre un oprateur et son client, et ce mme durant
des incidents sur le rseau.

at
io

2.2.4 Topologie TE

Lensemble des paramtres TE suivants sont associs aux liens dune topologie TE dans
la TEDB. Les liens tant unidirectionnels, chacun de leurs sens peut avoir des paramtres

La bande passante maximale pouvant tre utilise, qui correspond en gnral

Ev
a

lu

TE de valeurs diffrentes.

la bande passante physique du lien.

La bande passante maximale rservable est disponible pour un ensemble de

PD
F

LSP-TE sur le lien. Elle peut tre suprieure la bande passante maximale du lien,
pour prendre en compte le fait que tous les LSP-TE ne sont pas chargs
simultanment, on parle de surrservation . Elle peut tre infrieure la

rt

bande passante maximale du lien, lorsque lon ne veut ddier quune partie dun

La bande passante disponible du lien. Cest la bande passante rsiduelle

Ex

pe

lien pour les tunnels TE. On parle alors de sous-rservation .

rservable par des LSP-TE sur le lien. Elle est modifie dynamiquement lors de la
cration ou de la suppression dun LSP-TE. Huit valeurs de bande passante,
appeles pools de bande passante , sont associes ce paramtre. Il sagit de
la bande passante rservable pour chaque niveau de priorit et de premption
des LSP-TE.

Les groupes administratifs du lien, ou couleurs est un paramtre utilis comme


contrainte pour inclure ou exclure certains liens dun chemin. Cela permet
dautoriser ou dinterdire certains liens aux LSP-TE. On associe souvent ces
groupes administratifs des couleurs.

13

MPLS et Ingnierie de trafic

La mtrique TE vient complter la mtrique IGP. Elle permet dutiliser une


topologie avec des poids de liens diffrents de la topologie IP. Elle peut tre
utilise par exemple pour reprsenter le dlai du lien, il devient alors possible de
calculer le plus court chemin avec dlai contraint, la mtrique IGP reprsentant
le critre optimiser et la mtrique TE le dlai.

2.2.5 LSP-TE
Un LSP MPLS-TE est une connexion point point unidirectionnelle laquelle est associe
un ensemble de paramtres TE :

Ladresse du routeur destination est lidentifiant TE du routeur distant. Ce

at
io

dernier est une adresse interne logique (Loopback) annonce dans les extensions
TE des IGP.

Le chemin, explicite ou dynamique :

lu

o Le chemin explicite est une succession dadresses de liens ou de nuds

Ev
a

que le LSP-TE doit emprunter ou exclure. Il peut sagir dun chemin


explicite complet, ou dun chemin explicite partiel, indiquant une suite

PD
F

non continue de liens et/ou de nuds emprunter.


Lorsque le chemin est explicite partiel ou quil nest pas spcifi, on parle
de chemin dynamique. Le chemin dynamique est alors calcul, soit par le
routeur de tte soit par un serveur central, laide dun algorithme de

pe

rt

calcul de chemin contraint (Constraint Shortest Path First, CSPF). Le calcul


des chemins dynamique par les routeurs de tte pose toutefois un

Ex

problme doptimisation de lusage de la topologie TE. En effet, chaque


routeur de tte ne connait ltat que de ses propres LSP-TE. Des
phnomnes dinter blocages peuvent donc apparatre.

Plusieurs paramtres existent pour amliorer cette problmatique :

Une roptimisation priodique des chemins, initie par une


temporisation paramtrable.

Des priorits de premption dtablissement et de maintien des


tunnels.

14

Le calcul des chemins peut tre dport des routeurs dentre vers un
serveur central. Loptimisation de lensemble de la topologie TE est
alors assure.

Le fonctionnement du calcul CSPF est dtaill en page 18.

Les affinits sont utilises conjointement avec les groupes administratifs des
liens, et permettent de dfinir les liens inclure, prfrer et exclure du
chemin.

Les priorits de premption sont un mcanisme permettant de dfinir des


niveaux de priorit pour les LSP-TE. En cas de pnurie de bande passante, un LSP-

TE prioritaire peut prempter un LSP-TE moins prioritaire pour rcuprer la

at
io

bande passante alloue. Les priorits de premption sont codes sur 3 bits de 0
7, 0 tant la plus forte priorit. Un tunnel possde deux priorits de premption :
La priorit de maintien (hold, ph) correspond la capacit dun LSP-TE

Ev
a

rsister la premption.

lu

La priorit dtablissement (setup, ps) correspond la capacit dun LSPTE prempter un autre LSP-TE.

PD
F

Ces deux paramtres crent une situation dhystrsis et permettent donc


dviter les phnomnes de changement dtat intempestifs.

La bande passante rserver. Elle peut tre absolue ou sadapter

rt

dynamiquement la charge relle du LSP-TE. Dans le second cas, un phnomne

pe

de retard dadaptation peut apparatre si les intervalles de mesure ne sont pas


adapts au type du trafic. Des seuils dannonce de lutilisation de la bande

Ex

passante sont galement paramtrables, pour valuer une charge croissante ou


dcroissante des LSP-TE.

Le mode dannonce des LSP-TE dans les tables de routage. Trois modes existent :
o Aucune annonce : le LSP-TE nest pas annonc dans la table de routage du
routeur. Il faut spcifier statiquement les routes qui emprunteront le LSPTE.
o IGP Shortcut , ou autoroute : le LSP-TE est inclus dans la table de
routage du routeur de tte. La mtrique du LSP-TE est utilise pour le
calcul CSPF.

15

MPLS et Ingnierie de trafic


o IGP Shortcut Forwarding Adjacancy : le LSP-TE est annonc comme
une interface physique tous les routeurs de lIGP. Dans ce mode, le LSPTE doit tre bidirectionnel et comporter une mtrique IGP (IS-IS ou OSPF)

La mtrique utiliser pour le LSP-TE : ce paramtre, utilis dans le mode IGP


Shortcut, autoroute , indique la mtrique utiliser pour dterminer le plus
court chemin contraint. Il sagit de la mtrique TE ou de la mtrique IGP. La
mtrique TE peut tre absolue ou relative la mtrique IGP.

Le partage de charge entre plusieurs LSP-TE : Ce paramtre permet plusieurs


LSP-TE de partager une mme destination suivant des chemins diffrents

(explicites ou dynamiques), avec une pondration du partage de la charge de

at
io

trafic utilise dans chaque LSP-TE.

Des LSP-TE de secours : Pour pallier les ventuelles dfaillances dun LSP-TE, il

lu

est possible de paramtrer pour chaque LSP-TE des chemins de secours

Ev
a

explicites. Ces chemins de secours peuvent prendre la forme dun LSP-TE global
prtabli dans la topologie TE, ou de LSP-TE de protection locale de lien ou de
nud (Fast Reroute). Si aucun LSP-TE de secours nest configur, le trafic suivra

PD
F

le chemin de lIGP.

De la qualit de service : MPLS-TE peut tre considr comme un mcanisme de


signalisation de chemin contraint. Sil ne rserve pas physiquement la bande

rt

passante sur les liens mais des ressources dans la topologie TE, MPLS-TE est

pe

toutefois capable de prendre en compte les divers mcanismes qualit et classes

Ex

de service dun rseau.

Si les LSP-TE sont en concurrence pour les ressources dclares dans TEDB, MPLS-TE ne
procde en aucun cas de la rservation de bande passante physique. Pour garantir de
la bande passante aux flux des LSP-TE, il faudra associer des mcanismes classiques de
classes de services (cf 8 Diffserv Aware TE ).

16

Algorithme CSPF, ralis en 3 phases :


Dans lexemple ci-dessous, le routeur P1 est lorigine du LSP-TE tel que :
LSP-TE 1

Origine : P1

Destination : P6

BP ncessaire : 8M

20M
50

10M
50

10M

5M

50

50

10M

PD
F

50

P1

lu

10M
50

20M
50

20M
50

rt

10M
100

pe

Phase 3

Ex

P1

P6

Ev
a

10M
50

10M
100

20M
50

at
io

20M
50

Phase 2

P6

P1

10M
50

10M
50

10M
100

Phase 1

Affinit : Liens noirs

10M
50

P6

10M
50

20M
50

10M
50

10M : Bande passante TE disponible


100 : Mtrique TE

Figure 11 Algorithme de slection du chemin dynamique CSPF en trois phases.

(1)

Configuration du LSP-TE sur le routeur de tte : dfinition des objectifs et


contraintes.

(2)

Elimination des liens qui ne valident pas les critres TE du LSP-TE.

(3)

Calcul du plus court chemin (SPF) sur la topologie contrainte rsultante.

17

MPLS et Ingnierie de trafic

2.3 Signalisation des LSP-TE


Dans la partie 2.2.2, nous avons voqus deux protocoles de signalisation de LSP-TE
dans un rseau, CR-LDP et RSVP-TE.
Lide de CR-LDP (Constraint-based Routing over Label Distribution Protocol) est
dajouter au protocole de distribution de labels LDP des fonctions dingnierie de trafic.
Malgr certains avantages, comme lutilisation actuelle de LDP dans les rseaux MPLS, et
une bonne rsistance au passage lchelle, lindustrie lui a prfr RSVP-TE, pour des
raisons de maturit, de stabilit et de compatibilit inter-quipements.

La norme IETF de CR-LDP [RFC3468] est aujourdhui en status informationnal , ce qui

at
io

signifie quelle ne devrait plus tre utilise et implmente dans les quipements. Cest
pourquoi nous ne dtaillerons pas son fonctionnement dans ce document.

lu

2.3.1 RSVP-TE

Ev
a

RSVP est un protocole de signalisation destin lorigine pour IntServ [RFC1633], un


modle QoS. RSVP a par la suite t adapt pour devenir un protocole de signalisation

PD
F

qui supporte les extensions ncessaires MPLS-TE.

Le protocole RSVP-TE effectue trois fonctions principales dans le but de signaler le LSPTE le long du chemin pralablement dfini :

Il effectue un contrle dadmission local, pour sassurer que les contraintes sont

rt

pe

bien respectes (bande passante, groupes administratifs). Ce contrle

Ex

dadmission local est ncessaire pour prendre en compte les cas derreur de
calcul de route, par exemple lorsque les informations dans la TEDB ne sont plus
jour.

Il rserve la bande passante. La bande passante rsiduelle du lien est


dcrmente de la valeur de bande passante du LSP-TE (pour tous les pools de
priorit infrieure ou gale la priorit ph du LSP-TE). Il est important de noter
que cette rservation de ressources est purement logique et ne se traduit pas
par une rservation physique de bande passante.

Il distribue les labels et entrane une mise jour des tables MPLS en transit et IP
en tte de LSP-TE.

18

RSVP TE est un soft-state protocol . Cela veut dire quil a besoin de rafrachir
priodiquement ses rservations dans le rseau.

Messages et objets RSVP-TE


Le protocole RSVP-TE tourne entre routeurs adjacents. Il repose sur un ensemble de
messages constitus dun en-tte RSVP commun suivi dun ensemble dobjets RSVP-TE.
Ces messages sont transports directement sur IP ou sur UDP. Par dfaut, le
rafrachissement priodique des messages permet de prendre en compte les ventuelles
pertes de paquets. Il existe galement un mcanisme optionnel dacquittement et de
retransmission permettant de traiter directement les ventuelles pertes de message. Les

at
io

principaux messages RSVP-TE sont les suivants :

Path : Etablit et maintient le LSP-TE dans le sens descendant.

Resv : Etablit et maintient le LSP-TE dans le sens montant.

PathTear : Supprime le LSP-TE dans le sens descendant.

ResvTear : Supprime le LSP-TE dans le sens montant.

PathErr : Indique une erreur dans le sens montant.

ResvErr : Indique une erreur dans le sens descendant.

ResvConf : Confirme ltablissement dun tunnel dans le sens descendant.

Srefresh : Rafrachit un ensemble de sessions RSVP-TE.

Hello : Maintient ladjacence entre deux voisins RSVP-TE, permet de dtecter la

rt

PD
F

Ev
a

lu

pe

perte dun voisin. Cette procdure est optionnelle.

Ex

Distinction entre tunnel TE et LSP-TE


RSVP-TE fait la distinction entre la notion de tunnel TE et de LSP-TE :
Un tunnel TE correspond une entit de routage point point unidirectionnelle, avec
des contraintes TE. Il est instanci par deux LSP-TE qui peuvent varier. Chaque LSP-TE
correspondant un chemin particulier du tunnel TE.
Ainsi, RSVP-TE permet aux instances de tunnel TE de supporter divers vnements. Par
exemple un changement de route suite une roptimisation, un reroutage sur panne,
etc. Ce changement de LSP-TE seffectue sans perte de trafic, grce la procdure de
cration du nouveau LSP-TE, bascule du trafic puis suppression de lancien LSP-TE
19

MPLS et Ingnierie de trafic


( create before break ). Aussi, les ressources ncessaires ne sont pas rserves
plusieurs fois dans les TEDB des routeurs traverss.

tablissement des LSP-TE


Ltablissement dun LSP-TE par RSVP-TE est effectu en deux temps. Tout dabord, un
message Path est envoy de la source vers la destination, de proche en proche, le long
de la route explicite. Ce message Path contient les informations suivantes :
Ladresse de la source et de la destination du LSP.

Les numros de tunnel et de LSP.

La bande passante du LSP.

Les groupes administratifs inclure et ceux exclure.

Un ensemble de paramtres de classe de service et de scurisation.

La route explicite du LSP, code dans lobjet ERO (Explicite Route Object).

lu

at
io

Ev
a

la rception du message Path, chaque routeur de transit instancie un nouvel tat


RSVP-TE, enregistre les informations reues dans le message et ralise un contrle

PD
F

dadmission local pour vrifier que le prochain lien valide les contraintes TE du LSP-TE.
En rponse, le routeur de destination renvoie un message Resv de proche en proche
vers lorigine du tunnel. Ce message Resv rserve la bande passante et distribue les

pe

tte du tunnel TE.

rt

labels. Cela entrane une mise jour des tables MPLS en transit et de la table IP sur la

Ex

Le message Resv contient les informations suivantes :

Ladresse de la source et de la destination du LSP.

Les numros de tunnel et de LSP.

La bande passante du LSP.

Le label allou localement pour le LSP.

Lorsque le message Resv est arriv sur la tte et que la table de routage IP est mise
jour, le tunnel TE peut tre utilis pour aiguiller du trafic le long du LSP-TE.

20

La figure ci-dessous dtaille les tapes du processus dtablissement dun LSP-TE avec
RSVP-TE,

en

donnant

lexemple

dune

rservation

le

long

du

chemin

Ev
a

lu

at
io

R1R2R3R5R6R7.

Figure 12 Exemple dtablissement de LSP-TE par RSVP-TE

(1)

R1 est tte du tunnel TE (head-end), il envoie un Path message R2. Celui-ci

PD
F

vrifie le format du message et la disponibilit des ressources TE demandes.


Si les ressources ne sont pas disponibles, R2 renvoie un message PathErr
R1, la squence dtablissement est alors annule.
R2 envoie un Path message R3. R3 fait les mmes vrifications quen (1).

(3)

R3 envoie un Path message R5. Mmes vrifications.

(4)

R5 envoie un Path message R6. Mmes vrifications.

(5)

R6 envoie un Path message R7. Mmes vrifications.

(6)

R7 est la queue de tunnel TE (tail-end). Il envoie un Resv message R6. Ce

Ex

pe

rt

(2)

message contient le label de commutation MPLS employer pour le tunnel


TE par R6. Dans ce cas le label=implicit-null.
(7)

R6 envoie un Resv message R5 et indique un incoming label=42.

(8)

R5 envoie un Resv message R3 et indique un incoming label=10921.

(9)

R3 envoie un Resv message R2 et indique un incoming label=21.

(10)

R2 envoie un Resv message R1 et indique un incoming label=18.


Ltablissement du LSP-TE est alors finalis.

21

MPLS et Ingnierie de trafic

Maintien des LSP-TE, tats RSVP-TE


chaque LSP-TE signal sur un nud est associ un tat RSVP-TE. Celui-ci regroupe
lensemble des informations du LSP-TE savoir :
Adresse source et destination.

Numros de tunnel-TE et de LSP-TE.

Bande passante.

Nud prcdent, nud suivant.

Route explicite.

Labels entrant et sortant.

at
io

Cet tat permet le maintien du LSP-TE, il est dcompos en deux sous-tats :

Le sous-tat PSB (Path State Block) : cr par le message Path, il maintient les

Le sous-tat RSB (Resv State Block) : cr par le message Resv, il maintient les

Ev
a

lu

informations contenues dans les messages Path reus et retransmis.

informations contenues dans les messages Resv reus et retransmis.

PD
F

Si un sous-tat RSVP-TE nest pas rafrachi au-del dune priode dexpiration dtat, il
expire et le LSP est dtruit. Il sagit dune proprit de RSVP que RSVP-TE hrite. Elle
prsente certains avantages comme le support des pertes de messages, des reroutages

rt

et des pertes de connectivit ainsi que la suppression des tats en cas disolement dun

pe

nud. Elle prsente galement certains inconvnients, en particulier une lourdeur de


traitement et un impact sur la CPU des routeurs. chaque sous-tat RSVP-TE (PSB, RSB)

Ex

sont associs deux timers : le timer de rafrachissement R, 30s par dfaut, et le timer
dexpiration L. Par dfaut, on a L = 4 R, cest--dire quun tat expire sur non-rception
de quatre messages de rafrachissement successifs.
Le rafrachissement est une procdure locale entre deux routeurs qui utilise les
messages Hello. Toutefois, comme indiqu plus haut, la procdure de rafrachissement
des tats RSVP est trs consommatrice de ressources, notamment les CPU des routeurs,
et pose des problmes de passage lchelle. Un mcanisme de rduction des
rafrachissements (Refresh Reduction, RR) a alors t dfini dans la [RFC2961]. Ce

22

mcanisme consiste transmettre des messages Srefresh contenant la liste des tats
rafraichir.
Cette procdure dacquittement et de rduction des rafrachissements permet de
diminuer considrablement la quantit dinformations RSVP-TE traiter pour le
maintien des tats tout en conservant les proprits soft state de RSVP.

Suppression dun LSP


La suppression explicite dun LSP-TE peut tre initie par la tte de tunnel TE, via un
message PathTear envoy de la source la destination. Ce message entraine la

destruction des tats RSB et PSB.

at
io

La suppression dun LSP-TE peut tre initie par la queue de tunnel via un message
ResvTear, de la destination vers la source. Ce message dtruit les tats RSB. Il attend

lu

ensuite la rponse de la tte de tunnel (message PathTear) pour entraner une

dexpiration des tats RSVP.

PD
F

2.4 Conclusion partielle

Ev
a

destruction totale du LSP. La suppression dun LSP peut galement tre implicite, en cas

Au terme de ce chapitre, nous avons termin la prsentation et ltude thorique de la


technologie dingnierie de trafic pour MPLS, MPLS-TE.

rt

MPLS-TE est un ensemble doutils et de mcanismes, qui viennent tendre MPLS. Il

pe

fonctionne au-dessus et grce MPLS, sans en perturber le fonctionnement normal.

Ex

Deux modes darchitectures pour MPLS-TE existent. Une utilisation globale, o


uniquement MPLS-TE est utilis pour lacheminement du trafic. Cette approche est
puissante mais complexe. Une utilisation ponctuelle, o lon peut bnficier des
avantages de MPLS-TE sans avoir modifier toute larchitecture rseau.
Enfin, la seule mthode de signalisation disponible pour MPLS-TE est aujourdhui RSVPTE, qui est le choix des principaux quipementiers rseaux (Cisco, Juniper, etc.). CR-LDP
est devenue obsolte.

23

tude du besoin

3 tude du besoin
Dans cette partie, nous allons tout dabord prsenter les besoins fonctionnels en
ingnierie de trafic de RENATER, pour le projet LHCONE.
Nous dtaillerons ensuite les quipements, protocoles et mcanismes mis en place
actuellement sur RENATER-5. Nous pourrons ainsi choisir les fonctions et
implmentations de MPLS-TE compatibles avec lexistant, et dfinir un plan de mise en
uvre.

3.1 Optimisation des liens de backup et contrle du trafic

at
io

Larchitecture rseau de RENATER est fiabilise par la prsence de nombreux liens de


secours. A part quelque cas de point de prsence RENATER pendulaire, chaque nud

lu

RENATER (NR) est interconnect au minimum avec deux autres NR. En dehors des

Ev
a

incidents ces liens restent inexploits, ce qui reprsente une perte de capacit et une
perte conomique.

Ces incidents ayant une dure limite et une occurrence faible, il est envisageable

PD
F

dutiliser ces liens de secours pour quelques projets scientifiques compatibles avec un
partage ponctuel de la bande passante.

rt

Pour raliser cet usage, il faut tre capable de saffranchir du routage interne (IGP) et de

pe

contrler le chemin emprunt par des trafics de type circuit L2 ou L3 VPN.

Ex

Le projet LHCONE est une illustration de cet usage, nous allons dcrire ses besoins dans
la partie suivante.

3.2 Projet LHCONE


3.2.1 Contexte
Dans le cadre du projet de recherche international LHC, le LHCOPN (figure 13) est un
rseau ddi qui interconnecte les laboratoires du CERN T0 et des centres de calcul T1
rpartis dans le monde entier. Les changes de donnes entre T0, T1 et T2 suivent le
schma monarch, prsent en introduction. Le rseau LHCONE (figure 14) est une

24

phase complmentaire au LHCOPN. Cest un rseau dinterconnexion qui vise


distribuer les changes de donnes avec et entre les T1, T2 et T3.

Tier 3

Ev
a

Tier 3

lu

at
io

Tier 3

Tier 3

Ex

pe

rt

PD
F

Figure 13 LHCOPN, changes hirarchiques des donnes avec les T2.

Tier 3

Figure 14 LHCONE, changes distribus des donnes entre les T2.

25

tude du besoin
La partie franaise du rseau LHCONE, adopte deux stratgies darchitecture pour le
raccordement des sites :

Un rseau ddi, qui sappuie sur larchitecture optique de RENATER, et qui est
indpendant de sa politique de routage (VLANs et longueurs dondes optiques
sont rserves dans larchitecture DWDM). Les sites T1 et les principaux T2 font
partie de ce rseau ddi ou y sont directement connects. Le rseau LHCONE
France est connect au rseau LHCONE gnral via deux interconnexions,
Paris et Genve.

Des interconnexions de type point--point, des autres T2 et T3 au rseau

LHCONE France. Ces connexions, de type L2VPN-PseudoWire (L2VPN-PW)

at
io

sappuieront sur larchitecture physique et logique du rseau RENATER.


Deux interconnexions entre le LHCONE France et le LHCONE international sont

Ex

pe

rt

PD
F

Ev
a

lu

prsentes Paris et Genve.

Figure 15 Infrastructure RENATER ddie LHCONE France.

26

Figure 16 Tiers 1, 2 et 3 du rseau LHCONE sur RENATER

at
io

3.2.2 Besoins en ingnierie de trafic

Les connexions L2VPN-PW depuis les T2 et T3 devront aboutir sur les routeurs de Paris1,

Ev
a

France.

rediriges dans le rseau ddi LHCONE

lu

Lyon1 ou Orsay (figure 15) afin dtre

Plusieurs points sont souligner quant ces connexions :

Le projet LHC est susceptible de consommer une grande quantit de ressources

PD
F

en bande passante. En effet, le projet dans son ensemble gnre et transmet au


moins 1 Hexabit de donnes par an. La consommation moyenne par site Tiers 2
est estime plus d1Gbit/s.

La cohabitation du trafic de ce projet avec les autres utilisateurs de RENATER est

rt

pe

possible sur le rseau de production. Cependant, le risque de saturation, de

Ex

manque de disponibilit du rseau caus par les liaisons L2VPN LHCONE


France nest pas ngligeable.

Du point de vue du rseau RENATER :

Pour des questions de fiabilit, tous les NR sont au moins 2-connects aux autres
NR. Dans la plupart des cas, on peut parler dune liaison principale, et dune
liaison de secours. Cependant, une tude de la matrice des trafics est raliser
car pour un mme NR certains prfixes IP peuvent tres routs via lune ou
lautre des deux liaisons.

Les liaisons de secours sont peu utilises par la politique de routage actuelle.

Les liaisons de secours sont gnralement performantes (10Gb/s).


27

tude du besoin

La liaison entre Lyon1 - Genve est laccs nominal pour linterconnexion vers le
LHCONE international de Genve. Cette liaison est dj charge par le trafic
de production habituel de RENATER.

Lutilisation de mcanismes dingnierie de trafic pour orienter les liaisons L2VPNPW vers le LHCONE France, au travers de ces liaisons de secours, apporterait les
avantages suivants :
Utilisation/rentabilisation des liaisons de secours.

Allgement, non saturation des liaisons principales du rseau RENATER.

Gestion/Routage de flux sur le rseau avec allocation de ressources rseaux.

Lusage des CoS de service permettrait de garantir quen cas de congestion de

at
io

laccs secours (cas de panne de laccs primaire par exemple), le trafic plus

lu

prioritaire pourrait tre coul sans dgradation de performance.

Ev
a

Dans lexemple ci-dessous, une connexion L2VPN entre un Tiers 2 Strasbourg et le


rseau LHCONE France Paris 1 pourrait emprunter deux chemins physiques :
Strasbourg-Nancy-Paris1, qui est le lien principal.

Strasbourg-Nancy-Reims-Paris2-Paris1, le lien se secours.

Ex

pe

rt

PD
F

Figure 17 - Exemple de L2VPN-PW orient par de lingnierie de trafic

Les besoins fonctionnels en termes dingnierie de trafic sont :

Cration de tunnels TE conditionns par des critres de bande passante


ncessaire et/ou de couleurs administratives et affinits.

28

Capacit slectionner le trafic en transit dans ces tunnels TE.

Scurisation des tunnels TE : Tunnels TE de secours prtablis ou pr-calculs.

Convergence rapide, roptimisation des tunnels TE en cas dune coupure des


liens principaux ou de secours du rseau RENATER.

Des fonctions supplmentaires peuvent galement tre intressantes :

Partage de charge des tunnels entre plusieurs liens physiques.

Supervision de ces liens, mtrologie.

Ce projet tant un pilote de lutilisation dingnierie de trafic sur RENATER, les choix
fonctionnels devront permettre un dploiement et une valuation rapide au sein du
rseau RENATER.

Les changements apporter aux infrastructures et protocoles mis en place devront tre

Ex

pe

rt

PD
F

Ev
a

lu

at
io

les plus lgers possibles.

29

tude du besoin

3.3 Analyse du primtre rseau RENATER-5


3.3.1 RENATER-5, environnement matriel
Le rseau RENATER-5 mtropolitain est compos dune soixantaine de nuds (NR), et

Ex

pe

rt

PD
F

Ev
a

lu

at
io

denvirons 75 routeurs. Tous ces routeurs sont de marque Cisco.

Figure 18 Topologie mtropolitaine de RENATER

Cinq modles sont prsents, leurs types et versions logicielle sont numres ci-dessous.
Type de routeur
Cisco 7609
Cisco 720X
Cisco 6509-E
Cisco 12410
Cisco CRS-1

30

Version logicielle
Version 12.2(33) SRE3
Version 12.4(24) T6
Version 12.2(33) SXJ et 12.2(18) SXF12a
Cisco IOS XR Software, Version 3.9.1
Cisco IOS XR Software, Version 4.0.1

Code RENATER
RTR-021
RTR-031
SWI-001
RTR-011
RTR-001

Les routeurs de type CRS-1 sont les organes de cur du rseau, leurs capacits de
routage, de commutation sont les plus importantes. Trois routeurs de ce type sont
prsents dans les NR de Paris 1, Paris 2 et Lyon 1.
Les routeurs de type 7609 sont utiliss dans la majeure partie des NR, complts par
quelques routeurs de type 12410. Enfin, les commutateurs routeur de type 6509 sont
prsents sur les sites de Lyon 1 et Orsay, ils sont ddis des projets spcifiques, type
LHCONE.
Les routeurs de type 720X ne participent pas au routage des projets de type LHCONE. Ils

at
io

type de routeur ne sera donc pas pris en compte dans ltude.

sont utiliss pour le trafic Ipv6, le multicast et pour les liaisons vers les DOM-TOM. Ce

Aussi, le Rseau Acadmique Parisien (RAP), qui est en cours dintgration dans

lu

RENATER, est compos de routeurs JUNIPER. Ltude de la compatibilit de ces

Ev
a

quipements avec MPLS-TE sera effectue dans ltude de lintgration de RAP dans
RENATER (prvue au 3me et 4me trimestre 2012).

PD
F

RENATER est interconnect Internet via des oprateurs de transit IP et galement via
le rseau GEANT (Gigabit European Advanced Network Technology). Au dbut de ce
projet, deux accs GEANT existent, 1 primaire Paris 1 et 1 secours Paris 2.

rt

La socit British Telecom Global Services (BT) est le prestataire qui assure la

pe

configuration, la supervision du rseau RENATER et la maintenance des quipements qui

Ex

le composent.

3.3.2 RENATER-5, architecture de routage


Les lments principaux de larchitecture et du routage de RENATER-5 sont les suivants :

Des liaisons point--point Ethernet entre les NR. Certaines de ces liaisons sont
doubles ou triples. Le routage est alors effectu en partage de charge Equal
Cost Multiple Path ECMP.

Le protocole de routage interne prsent dans RENATER-5 est Intermediate


System to Intermediate System (ISIS). Cest un protocole tat des liens. Les
tables de routage Ipv4 et Ipv6 sont spares (mode ISIS multi-topology, dit
dual-stack ).
31

tude du besoin

Le protocole de dtection de coupure rseau Bidirectionnal Forwarding


Detection (BFD) est prsent sur toutes les interfaces de cur de rseau. Les
rglages de BFD permettent de dtecter une coupure en 150ms ou 250ms en
fonction des capacits physiques des routeurs.

Le protocole de routage externe est BGP4. Il permet galement de recevoir et de


propager les prfixes externes, cest--dire des tablissements raccords
RENATER et de tous les peers (Gigabit European Advanced Network Technology,
GEANT, transit, point dchange IX). 2 route-reflectors (RR) sont dploys sur
Paris1 et Lyon1, simplifiant la configuration BGP en vitant davoir configurer

un maillage complet BGP.

at
io

MPLS

Les points importants de la politique de routage MPLS de RENATER-5 sont les suivants :
MPLS est utilis pour encapsuler le trafic Ipv4 unicast ainsi que les services

lu

Ev
a

L2VPN et L3VPN. Les trafics Ipv4 multicast et Ipv6 nutilisent pas MPLS.
MPLS fonctionne en mode frame : Un en-tte est ajout devant le paquet IP.

MPLS est activ sur toutes les interfaces du cur de rseau, pas sur les interfaces

PD
F

vers les sites utilisateurs de RENATER.

Lallocation de label ne sapplique que pour les routes internes apprises par lIGP.

MPLS utilise une adresse de Loopback (lo2) des routeurs pour les dsigner

LDP [RFC5036] a t choisi comme protocole de distribution de label. Il repose

pe

rt

sur les tables construites par IS-IS. En cas de convergence de lIGP, celle de LDP

Ex

est immdiate.

32

3.3.3 Services de circuits dans RENATER-5


Les services VPN sont aussi dploys au-dessus de ce cur MPLS.
RENATER propose des solutions dinterconnexion prive de niveau 2, L2VPN Ethernet [5]
et de niveau 3 (L3VPN), reposant sur MPLS.

Les L2VPN reposent sur la technologie Virtual Private Wire Service (VPWS),
ou Pseudo-Wire (L2VPN-PW) qui construit un circuit Ethernet point point
partir du cur MPLS.

Les L3VPN reposent sur la technologie MPLS-VPN. Le mode utilis est any-toany , chaque site connect au L3VPN peut dialoguer directement avec un autre

lu

L2VPN PseudoWire

at
io

propages via BGP aux routeurs dextrmit.

site, sans devoir passer par un site central. Les informations de routage sont

Ev
a

Deux types de L2VPN PW peuvent tre configurs, des L2VPN VLAN--VLAN et des

pe

rt

PD
F

L2VPN port--port.

Ex

Figure 19 Les diffrents types de L2VPN-PW dans RENATER

Dans le cas dun L2VPN VLAN--VLAN, il est possible dactiver plusieurs services sur le
mme port. Dans celui L2VPN port--port, il est ncessaire quune interface physique
soit intgralement ddie sur ses deux extrmits. Il faudra alors disposer dune autre
interface physique pour les autres types de services.

33

tude du besoin
Un L2VPN-PW est cr dans une architecture MPLS via les mcanismes suivants :

Les interfaces de connexion des sites utilisateurs (CE) sont tagus avec un VLAN.

Les interfaces de cur de rseau (PE) tablissent une correspondance entre ce


VLAN et un circuit virtuel (VC). Le VC est achemin vers la sortie du L2VPN-PW
par MPLS.
En sortie, le VC est retraduit en VLAN (pas forcment identique).

Mapping VLAN ID vers VC ID

Vlan 2000

VC 222

PE 1

VC 222

Nuage MPLS

Pseudo Wire

PE 2

Vlan 2000

CE 2

at
io

CE 1

Mapping VC ID vers VLAN ID

Figure 20 L2VPN-PW dans une architecture MPLS

lu

Dans le cas dun L2VPN VLAN--VLAN ou les 2 sites interconnects souhaitent

Ev
a

communiquer sur plusieurs VLAN, on utilisera la solution du QinQ (IEEE 802.1ad) qui
permet de dissocier les VLAN clients du VLAN de transport.

PD
F

La figure ci-dessous prsente les diffrentes encapsulations dune trame Ethernet dans
un L2VPN-PW. Dans le premier cas, le VLAN de transport (Tag Service Delimiting) nest

Ex

pe

rt

pas transmis aux CE. Dans le second cas, il est supprim, conserv ou chang.

Figure 21 Encapsulation dune trame Ethernet tague 802.1Q

34

L3VPN MPLS
La solution L3VPN MPLS prsente sur RENATER-5 repose sur lexploitation de len-tte
MPLS, o lon dfinit des VPN discrimins par un label supplmentaire (en plus du label
de commutation). Chaque VPN possde sa propre table de routage IP dans le concept de
Routage et Transfert Virtuel Virtual Routing and Forwarding (VRF) impliquant une
notion de Route Distinguisher et Route target (RD et RT). [RFC2547].

Le protocole de routage utilis est BGP. Celui-ci change les routes annonces dans le
VPN via son extention Multi-Protocol BGP (MPBGP). Comme pour le fonctionnement

traditionnel de BGP, il est possible dutiliser ou non un route reflector (RR). Cest le cas

at
io

dans larchitecture de RENATER.

lu

Dans lexemple ci-dessous, 3 routeurs clients (CE) sont interconnects via un L3VPN sur

Ev
a

la VRF VERTE . Le RR a la charge de distribuer toutes les routes annoncs vers les
routeurs dextrmit (PE) appartenant la VRF.

rt

PD
F

CE 2

pe
Ex

PE2

RR

Nuage MPLS
Peering
iBGP

PE 1

CE 1

Peering
eBGP

PE 3

CE 3

Figure 22 L3VPN sur VRF VERTE - Peering eBGP et iBGP sur Route Reflector

Du point de vue des sites interconnects, le L3VPN se comporte comme un unique


routeur dinterconnexion. Seul lusage des services Ipv4 unicast est permis dans un
L3VPN sur RENATER.

35

Choix des solutions et faisabilit

4 Choix des solutions et faisabilit


Cette section met en vidence le fonctionnement et le rle des fonctionnalits de MPLSTE dans son implmentation propose par Cisco. Nous pourrons alors choisir les
fonctionnalits qui rpondent le mieux aux besoins du projet.

4.1 Protocole de tests


Afin de valider la configuration et lusage des paramtres dune topologie et des tunnels
MPLS-TE, nous avions besoin de procder une phase de maquettage. Pour cela,
RENATER dispose habituellement dun banc de test compos de 3 routeurs. Jai

at
io

plutt propos dutiliser une maquette de rseau virtuelle via le logiciel de simulation
Dynamips/GNS3.

Ce logiciel est capable dmuler des plateformes de routeurs Cisco 7200 et toutes leurs

Ev
a

loccurrence lIOS Version 12.2(33) SRE3.

lu

fonctions logicielles. Nous pouvons y injecter le systme IOS de notre choix, en

Lintrt dutiliser un logiciel de simulation est de pouvoir, moindre frais et sans


aucuns risques, recrer une topologie rseau dont le but est de reprsenter le plus

PD
F

fidlement les diffrents aspects du rseau RENATER-5.


Le choix des logiciels Dynamips/GNS3 a t port par mes prcdentes expriences
professionnelles, ou jai pu notamment simuler et prparer des configurations de

pe

rt

commutateurs et de routeurs, et par lutilisation pdagogique qui en est faite au CNAM.

Ex

Cette maquette est constitue de 8 routeurs de curs (P1 P8, P6 not RR) et de deux
routeurs clients (CE1 et CE2). Deux machines virtuelles linux QEMU sont galement
prsentes, elles permettront de simuler un change entre deux sites.
Les protocoles utiliss sont ceux prsents sur R-5, savoir :

Le protocole de routage interne est IS-IS. Les mtriques sont prcises sur la
figure 25. Par souci de simplicit, elles sont gales dans les deux sens dun lien.

Les mtriques IS-IS sont par dfaut de 10. Elles ont t fixes 100 sur les liens
P4-P8, P8-P3, P3-P2, pour simuler un lien de secours.

36

Les changes dans le cur de rseau sont effectus par MPLS.

Les routeurs clients (CE) annoncent leurs prfixes IP au cur de rseau via BGP4.

Le protocole de tests suivi est :

Deux phases de configuration de MPLS-TE :


o Configuration de la topologie TE et tablissement de tunnels TE.
o Utilisation de ces tunnels TE dans le rseau.

Pour chaque fonction et paramtre, prsentation des commandes de


configuration, des traces de consoles avec leurs explication, pour des routeurs de
type Cisco.

Les trafics de type ipv4 unicast, L2VPN et L3VPN seront insrs dans les tunnels
MPLS-TE.
Deux machines virtuelles QEMU client/serveur iperf permettront de simuler

at
io

une charge de trafic dans le rseau.

Quantification de linfluence des fonctionnalits MPLS-TE sur lutilisation CPU et

lu

mmoire des routeurs, mais aussi sur le bon fonctionnement des autres

Ev
a

protocoles. Il est possible que ces deux aspects se rvlent non reprsentatifs sur
loutil de simulation Dynamips/GNS3.

PD
F

Toutes les notions voques dans les sections suivantes sont dtailles en 2.2.

La liste des commandes ncessaire la programmation des routeurs est disponible sur le

rt

site de Cisco1. Ces commandes sont valables pour le systme dexploitation IOS Cisco.

Ex

12000).

pe

Elles sont transcrire pour les quipements qui fonctionnent avec IOSXR (Cisco CRS-1 et

Cf. rfrences en 7.2

37

Choix des solutions et faisabilit

10.2.0.1

10.6.0.1

.26.0

100

.12.0

.36.0
.23.0

10.3.0.1

.13.0

10.5.0.1

pe

Adresse de
loopback

.48.0

.47.0

Ex

100

10.8.0.1

.78.0

rt

10.7.0.1

.38.0

.58.0

PD
F

.57.0

Ev
a

.17.0

.35.0

lu

.15.0

at
io

10.1.0.1

100
10.4.0.1

Sous-rseau
dun lien en
10.0.x.x
Mtriques IGP

Figure 23 Architecture de test mise en place via Dynamips/GNS3

38

4.2 tablissement de tunnels MPLS-TE


Dans cette section, nous verrons les diffrentes phases lies ltablissement de tunnels
MPLS-TE, ainsi que leur mise en concurrence pour les ressources de la topologie TE. Les
points suivants sont abords :
Configuration de la topologie TE.

tablissement dun tunnel TE chemin explicite.

tablissement dun tunnel TE chemin dynamique.

Configuration du critre de bande passante TE des tunnels.

Critres de premption des tunnels.

R optimisation priodique des chemins des tunnels

Annonce des ressources disponibles dans la topologie TE.

at
io

lu

4.2.1 Topologie TE

Ev
a

La premire tape dans la ralisation dune architecture MPLS-TE est de crer une
topologie TE. Cela consiste dclarer pour toutes les interfaces du rseau les

PD
F

paramtres suivants :

Bande passante physique du lien.

Bande passante rservable par le TE.

Groupe administratif.

Mtrique TE.

pe

rt

Ex

Exemple de configuration dune interface :


interface GigabitEthernet1/0
bandwidth 1000
ip rsvp bandwidth 1000 1000
mpls traffic-eng attribute-flags 0xABCD
mpls traffic-eng administrative-weight 5

o Bandwidth [1-10000000] : Bande passante en kbps de linterface. Reprsente


normalement la bande passante physique du lien.
o ip rsvp bandwidth A B :

A : Bande passante rservable par des tunnels MPLS-TE. [1-10000000]


kbps ou pourcentage de la bande passante de linterface.

B : Bande passante rservable par flux dans des tunnels MPLS-TE. [1-

39

Choix des solutions et faisabilit


10000000] kbps
o attribute-flag (32 bit, en hexadcimal) : groupe administratif du lien. Il sera
compar au champ affinity des tunnels lors de la phase dtablissement des
tunnels.
o mpls traffic-eng administrative-weight : Mtrique TE du lien (absolue ou
relative). Si un lien ne comporte pas de mtrique TE, la mtrique IGP est utilise.
Sur chaque routeur, IS-IS-TE a la charge de propager les informations de topologie TE.
Visualisation de la topologie TE :

PD
F

Ev
a

lu

at
io

P4#sh mpls traffic-eng topology


[]
link[1]: Broadcast, DR: 0000.0000.0001.01, nbr_node_id:14, gen:31
frag_id 0, Intf Address:10.0.15.1
TE metric:10, IGP metric:10, attribute flags:0x0
SRLGs: None
physical_bw: 1000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool
Total Allocated
Reservable
Reservable
BW (kbps)
BW (kbps)
BW (kbps)
---------------------------------bw[0]:
0
1000
0
bw[1]:
0
1000
0
bw[2]:
0
1000
0
bw[3]:
0
1000
0
bw[4]:
0
1000
0
bw[5]:
0
1000
0
bw[6]:
0
1000
0
bw[7]:
100
900
0
[]

On observe les paramtres TE qui schangent via IS-IS-TE dans les TEDB. Le

rt

rafraichissement de ces informations est initi priodiquement par IS-IS, mais galement

Ex

pe

chaque modification, ou rservation dune ressource.

Les tunnels TE seront mis en concurrence pour lobtention et la rservation des


ressources TE. En cas de manque de ressources, les tunnels ne pourront stablir
directement, les mcanismes de premptions (cf 4.2.5) seront alors mis en uvre.

40

4.2.2 Etablissement dun tunnel TE chemin explicite


Nous allons configurer un tunnel MPLS-TE bidirectionnel entre P4 et P2 suivant le
chemin explicite P4 P8 P3 P2. La configuration dtaille ci-dessous est celle du
tunnel unidirectionnel P4-P2 cr sur P4, la tte de tunnel.
10.2.0.1

.26.0

.12.0

.36.0

.15.0

Tunnel MPLS TE
bidirectionnel
P4-P2

.57.0

.58.0

.78.0

10.8.0.1

PD
F

10.7.0.1

lu

10.5.0.1

Ev
a

.17.0

.35.0

10.3.0.1

.13.0

at
io

10.1.0.1

10.6.0.1

.47.0

10.4.0.1

Adresse de
loopback
Sous-rseau
dun lien en
10.0.x.x

rt

Figure 24 Tunnel MPLS-TE chemin explicite

pe

Nous crons tout dabord le dtail du chemin explicite. Cest une liste ordonne des

Ex

routeurs inclure, ou exclure :


ip explicit-path name Tunnel_1_pri enable
next-address 10.8.0.1
next-address 10.3.0.1
exclude-address 10.5.0.1

Un tunnel MPLS-TE est vu comme une interface par le routeur.


Configuration dun tunnel MPLS-TE chemin explicite (paramtres de base, sur P4) :
interface Tunnel1
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 800
tunnel mpls traffic-eng path-option 1 explicit name Tunnel_1_pri

41

Choix des solutions et faisabilit


o tunnel destination : adresse de Loopback du routeur cible de sortie du tunnel.
o tunnel mpls traffic-eng priority : Priorits dtablissement et de maintien du
tunnel.
o tunnel mpls traffic-eng bandwidth : Bande passante TE requise pour
ltablissement du tunnel.
o tunnel mpls traffic-eng path-option 1 explicit : Chemin explicite associ au
tunnel.

Statut et informations sur le tunnel :

at
io

P4#sh mpls traffic-eng tunnels tunnel 1


Name: P4_t1
(Tunnel1) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15)

Ev
a

lu

Config Parameters:
Bandwidth: 800
kbps (Global) Priority: 7 7
Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 800
bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

Ex

pe

rt

PD
F

InLabel : OutLabel : GigabitEthernet2/0, 34


RSVP Signalling Info:
Src 10.4.0.1, Dst 10.2.0.1, Tun_Id 1, Tun_Instance 18
RSVP Path Info:
My Address: 10.0.48.1
Explicit Route: 10.0.48.2 10.0.38.2 10.0.38.1 10.0.23.2
10.0.23.1 10.2.0.1
Record
Route:
NONE
Tspec: ave rate=800 kbits, burst=1000 bytes, peak rate=800 kbits
RSVP Resv Info:
Record
Route:
NONE
Fspec: ave rate=800 kbits, burst=1000 bytes, peak rate=800 kbits
Shortest Unconstrained Path Info:
Path Weight: 8 (TE)
Explicit Route: 10.0.48.1 10.0.48.2 10.0.58.2 10.0.58.1
10.0.15.2 10.0.15.1 10.0.12.1 10.0.12.2 10.2.0.1
History:
Tunnel:
Time since created: 12 minutes, 22 seconds
Time since path change: 1 minutes, 32 seconds
Number of LSP IDs (Tun_Instances) used: 18
Current LSP:
Uptime: 1 minutes, 32 seconds
Prior LSP:
ID: path option 1 [14]
Removal Trigger: configuration changed

o Status : signale ltat administratif et oprationnel du tunnel TE.


o Path option : Chemin slectionn pour le tunnel et son poids.
o Config Parameters : paramtres gnraux du tunnel.

42

o OutLabel : Label de commutation MPLS associ au Tunnel.


o RSVP Signalling Info : informations sur la signalisation RSVP du chemin du tunnel.
o Shortest Unconstrained Path Info : informations sur le plus court chemin existant
dans la topologie TE (le tunnel nest pas forcment ligible au meilleur chemin).
o History : Historique de cration/modification du tunnel.
Plusieurs chemins explicites peuvent tre dclars pour chaque tunnel. Ceux-ci sont
dfinis par un niveau de priorit. Ces chemins secondaires seront slectionns
squentiellement si le chemin de plus forte priorit ne peut pas stablir. On parle alors
de tunnel secondaire non tablis.

at
io

Tunnel mpls traffic-eng path-option 2[+] explicit name autre chemin explicite

Enfin, cette commande nous permet de vrifier manuellement les capacits daccueil de
la topologie TE avant ltablissement dun tunnel TE chemin explicite :

pe

rt

PD
F

Ev
a

lu

P4#sh mpls traffic-eng topology path destination 10.2.0.1 [paramtres]


Query Parameters:
Destination: 10.2.0.1
Bandwidth: 0
Priorities: 0 (setup), 0 (hold)
Affinity: 0x0 (value), 0xFFFFFFFF (mask)
Query Results:
Min Bandwidth Along Path: 1000 (kbps)
Max Bandwidth Along Path: 5000 (kbps)
Hop 0: 10.0.48.1
: affinity 00000000, bandwidth 5000 (kbps)
Hop 1: 10.0.48.2
: affinity 00000000, bandwidth 1000 (kbps)
Hop 2: 10.0.38.2
: affinity 00000000, bandwidth 1000 (kbps)
Hop 3: 10.0.38.1
: affinity 00000000, bandwidth 1000 (kbps)
Hop 4: 10.0.23.2
: affinity 00000000, bandwidth 1000 (kbps)
Hop 5: 10.0.23.1
: affinity 00000000, bandwidth 1000 (kbps)
Hop 6: 10.2.0.1

o Query Parameters : paramtres demands.

Ex

o Query Results : Chemins rsultants qui rpondent aux contraintes.

43

Choix des solutions et faisabilit

4.2.3 Etablissent dun tunnel TE chemin dynamique


La cration de chemins dynamiques utilise un algorithme de recherche du chemin le plus
court selon des contraintes, CSPF (dtaill en 2.2.4).
Configuration dun tunnel chemin dynamique :
interface Tunnel1
ip unnumbered Loopback1
load-interval 30
tunnel destination 10.2.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng path-selection metric te

o path-option 1 dynamic : Le chemin utilise lalgorithme CSPF pour stablir.

Statut dtablissement du tunnel chemin dynamique :

at
io

o path-selection metric te : type de mtrique prise en compte dans le calcul CSPF.

Ev
a

lu

P4#sh mpls traffic-eng tunnels tunnel 2


Name: P4_t2
(Tunnel2) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling:
connected
path option 1, type dynamic (Basis for Setup, path weight 8)

Ex

pe

rt

PD
F

Config Parameters:
Bandwidth: 100
kbps (Global) Priority: 5 4
Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 100
bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
[]
RSVP Signalling Info:
Src 10.4.0.1, Dst 10.2.0.1, Tun_Id 2, Tun_Instance 1
RSVP Path Info:
My Address: 10.0.48.1
Explicit Route: 10.0.48.2 10.0.58.2 10.0.58.1 10.0.15.2
10.0.15.1 10.0.12.1 10.0.12.2 10.2.0.1

On retrouve ici les mmes informations que dans le status du tunnel TE chemin
explicite. On peut toutefois observer des diffrences :
State : dynamic path option 1 is active : indique que le tunnel TE est bien en
mode CSPF.
Explicit Route : dtail de la route choisie par le CSPF et signale pour ce tunnel
TE.
Statuts gnraux du tunnel :
P4#sh mpls traffic-eng tunnels tunnel 2 brief
Signalling Summary:
LSP Tunnels Process:
running
Passive LSP Listener:
running
RSVP Process:
running

44

Forwarding:
enabled
Periodic 45epartition45on:
every 3600 seconds, next in 3222 seconds
Periodic FRR Promotion:
Not Running
Periodic auto-bw collection:
every 300 seconds, next in 222 seconds
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
P4_t2
10.2.0.1
Gi2/0
up/up

o Periodic reoptimization : le calcul CSPF est relanc priodiquement pour chaque


tunnel (voir 4.2.5).

at
io

P4#sh mpls traffic-eng topology path tunnel 2


Query Parameters:
Destination: 10.2.0.1
Bandwidth: 100
Priorities: 5 (setup), 4 (hold)
Affinity: 0x0 (value), 0xFFFF (mask)
Query Results:
Min Bandwidth Along Path: 800 (kbps)
Max Bandwidth Along Path: 4800 (kbps)
Hop 0: 10.0.48.1
: affinity 00000000,
Hop 1: 10.0.48.2
: affinity 00000000,
Hop 2: 10.0.58.2
: affinity 00000000,
Hop 3: 10.0.58.1
: affinity 00000000,
Hop 4: 10.0.15.2
: affinity 00000000,
Hop 5: 10.0.15.1
: affinity 00000000,
Hop 6: 10.0.12.1
: affinity 00000000,
Hop 7: 10.0.12.2
: affinity 00000000,
Hop 8: 10.2.0.1

Informations sur la topologie TE le long du chemin dynamique slectionn :

Ev
a

lu

bandwidth
bandwidth
bandwidth
bandwidth
bandwidth
bandwidth
bandwidth
bandwidth

4800 (kbps)
1000 (kbps)
900 (kbps)
1000 (kbps)
800 (kbps)
1000 (kbps)
800 (kbps)
1000 (kbps)

PD
F

Nous avons ici une vue gnrale de la topologie TE traverse par le tunnel, des affinits,
des disponibilits et rservations en bande passante TE.
La comparaison daffinit entre les tunnels et la topologie TE permet de restreindre les

rt

chemins des tunnels un type, ou un groupe de liens :

pe

interface gi 1/0
mpls traffic-eng attribute-flags 0xABCD

Ex

interface tunnel 2
tunnel mpls traffic-eng affinity 0xA000 mask 0x1000

o Attribute-flags : affinit de linterface dans la topologie TE, en hexadcimal.


o Affinity [valeur] [masque] : lors du calcul CSPF, laffinit du tunnel est compar
lattribute-flags des interfaces. Si les deux valeurs correspondent, linterface est
ligible la suite de lalgorithme CSPF. Le masque daffinit se comporte de la
sorte : un bit 1 dans le masque signifie ne pas tenir compte de ce bit de
lattribute-flag pour la comparaison avec laffinit du tunnel .

45

Choix des solutions et faisabilit


Le temps ncessaire la signalisation et ltablissement des tunnels dans les modes
explicites et dynamiques na pu tre quantifi sur la maquette. Les documentations
annoncent un temps de lordre de 100ms

4.2.4 Bande passante des tunnels


La bande passante TE dclare pour les tunnels sert de contrainte pour leur
tablissement dans la topologie TE.

Mode statique
Ce mode convient lorsque lon a la connaissance de la matrice des flux du rseau, et que

le trafic est liss sur les liens.

at
io

Commande pour les tunnels TE :

interface Tunnel1
tunnel mpls traffic-eng bandwidth [global-pool|sub-pool] 800

lu

Spcifie la bande passante du tunnel MPLS-TE et son type dallocation (global|sub-pool).

Ev
a

Dans le cas o la bande passante disponible dans la topologie TE est infrieure celle
demande par le tunnel, celui-ci ne peut stablir, lerreur path error PCALC est
retourne par le calcul CSPF :

Mode automatique

PD
F

Path Option 1:
Last Error: PCALC:: No addresses to connect 10.4.0.1 to 0.0.0.0

pe

rt

Ce second mode permet au tunnel dadapter sa contrainte de bande passante au trafic


rellement coul pendant un espace de temps.

Ex

Exemple de configuration :

interface Tunnel1
load-interval 30
tunnel mpls traffic-eng auto-bw frequency 300 max-bw 1000 min-bw 100

o load-interval [30-600] : Intervalle de temps utilis pour le calcul de la bande


passante moyenne utilise.
o frequency [300-604800] : Frquence de mise jour de la bande passante, en
secondes.
o max-bw 1000 min-bw 100 : Bande passante minimale et maximale autorise

46

Rsultat dans la table de routage :


P4#sh mpls traffic-eng tunnels tunnel 1 accounting
Tunnel1 (Destination 10.2.0.1; Name P4_t1)
30 second output rate 1043 kbits/sec, 104 packets/sec

Ev
a

lu

at
io

P4#sh mpls traffic-eng tunnels tunnel 1


Name: P4_t1
(Tunnel1) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15)
Config Parameters:
Bandwidth: 0
kbps (Global) Priority: 6 5
Affinity: 0x0/0xFFFF
Metric Type: TE (interface)
AutoRoute: disabled LockDown: disabled Loadshare: 979
bw-based
auto-bw: (300/248) 0 Bandwidth Requested: 979
Samples Missed 0: Samples Collected 0
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : OutLabel : GigabitEthernet2/0, 34
RSVP Signalling Info:
Src 10.4.0.1, Dst 10.2.0.1, Tun_Id 1, Tun_Instance 20
RSVP Path Info:
My Address: 10.0.48.1
Explicit Route: 10.0.48.2 10.0.38.2 10.0.38.1 10.0.23.2 10.0.23.1 10.2.0.1
Record
Route:
NONE
Tspec: ave rate=979 kbits, burst=1000 bytes, peak rate=979 kbits
RSVP Resv Info:
Record
Route:
NONE
Fspec: ave rate=979 kbits, burst=1000 bytes, peak rate=979 kbits

PD
F

On observe ici le trafic coul pendant les 30 dernires secondes sur une interface de
type tunnel TE.
Le champ auto-bw : (300/248) 0 Bandwidth Requested : 979 indique que la valeur
demande par le tunnel TE est bien mise jour.

rt

Rsultat dans la topologie TE : la bande passante dans la topologie est rserve par

pe

niveau de priorits :

Ex

link[0]: Broadcast, DR: 0000.0000.0004.02, nbr_node_id:19, gen:48


frag_id 0, Intf Address:10.0.48.1
TE metric:5, IGP metric:100, attribute flags:0x0
SRLGs: None
physical_bw: 1000 (kbps), max_reservable_bw_global: 5000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool
Sub Pool
Total Allocated
Reservable
Reservable
BW (kbps)
BW (kbps)
BW (kbps)
---------------------------------bw[0]:
0
5000
0
bw[1]:
0
5000
0
bw[2]:
0
5000
0
bw[3]:
0
5000
0
bw[4]:
0
5000
0
bw[5]:
979
4021
0
bw[6]:
0
4021
0
bw[7]:
0
4021
0

47

Choix des solutions et faisabilit


4.2.5 Fonctions dadaptation

Premption
Pour mettre en vidence le fonctionnement des niveaux de priorits de premption des
tunnels, nous avons cr trois tunnels chemin dynamique avec les paramtres
suivants :
interface Tunnel1
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 800
tunnel mpls traffic-eng priority 6 5

at
io
lu

Ev
a

interface Tunnel 3
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 200
tunnel mpls traffic-eng priority 7 7

interface Tunnel2
ip unnumbered Loopback1
tunnel destination 10.2.0.1
tunnel mpls traffic-eng bandwidth 1000
tunnel mpls traffic-eng priority 5 5

Dans ce cas, la bande passante disponible dans la topologie TE nest pas toujours

PD
F

suffisante, les tunnels qui peuvent stablir sur les liens TE seront alors ceux qui ont la
plus forte priorit dtablissement. Aussi, la priorit de maintien permet un tunnel dj
tabli de rsister une premption.

rt

Lordre dtablissement des tunnels TE et leurs paramtres de premption ont donc leur

pe

importance, des situations dinter blocage ou de sous-optimisation de la topologie TE


pouvant apparatre. Les phases de roptimisation dcrites dans la section suivante

Ex

permettent dans une certaine limite de rsoudre ces points.

Roptimisation

La roptimisation consiste relancer priodiquement ou sur vnement le calcul CSPF


pour chaque tunnel chemin dynamique :
mpls traffic-eng reoptimize events link-up
mpls traffic-eng reoptimize timers [delai] [frequence]

o events link-up : Initie la roptimisation du tunnel MPLS-TE lors de la rception


dun message de nouvelle adjacence IGP.
o timers [frequence] : Frquence de roptimisation priodique

48

o timers [delai] : Dlai avant la premire roptimisation suite ltablissement du


tunnel MPLS-TE.

Interface tunnel 1
tunnel mpls traffic-eng path-option 1 dynamic lockdown

Loption lockdown permet dempcher la roptimisation de ce tunnel chemin


dynamique.

La roptimisation priodique permet une meilleure utilisation de lensemble de la


topologie TE, de prendre en compte les ventuels changements de mtrique IGP, TE, de

at
io

bande passante TE disponible, etc.

Toutefois, le calcul dtablissement CSPF des tunnels TE est local chaque routeur, et
dans le cas dune topologie TE charge en tunnels TE dorigine et destination diverse, la

lu

seule roptimisation priodique ne sera pas suffisante. Il faudra alors centraliser le calcul

Ev
a

de tous les chemins dynamiques MPLS-TE sur un serveur externe.


4.2.6 Annonce de la bande passante TE disponible.

PD
F

Les interfaces de la topologie TE propagent rgulirement travers le rseau, via IS-ISTE, ltat de lutilisation de la bande passante TE.
Cette propagation est priodique, la frquence peut tre change en utilisant la

rt

commande suivante sur une interface :

pe

interface Gi 2/0
mpls traffic-eng link timers periodic-flooding [180s par dfaut]

Ex

Cette propagation peut galement tre dclenche sur franchissement croissant ou


dcroissant des seuils dutilisation de la bande passante. Par dfaut, les seuils suivant
sont prsent sur toutes les interfaces dune topologie TE :

Occupation BP dcroissante (%) : 100, 99, 98, 97, 96, 95, 90, 85, 80, 75, 60, 45,
30, 15.
Occupation BP croissante (%) : 15, 30, 45, 60, 75, 80, 85, 90, 95, 97, 98, 99, 100.

Il est possible de modifier ces seuils pour chaque interface afin de reprsenter au mieux
les contraintes physiques du rseau et de sadapter aux types de flux prsents dans les
tunnels MPLS-TE (donnes, VOIP).

49

Choix des solutions et faisabilit


Exemple de configuration :
interface Gi 2/0
mpls traffic-eng flooding thresholds up 15 30 50 60 70 71 72 73 74 80 100

4.3 Utilisation des tunnels MPLS-TE

Annonce des tunnels TE au reste du routage.

Protection des tunnels TE.

Partage de charge entre plusieurs tunnels TE.

Types de trafic supports par les tunnels TE.

at
io

4.3.1 Mode dannonce du tunnel dans le routage interne

Etude des diffrentes types dutilisation des tunnels MPLS-TE. A savoir :

Les tunnels MPLS-TE peuvent tre annoncs dans le routage interne dun rseau de

Aucune annonce dans lIGP

Ev
a

circuler du trafic dans ces tunnels (voir 2.2.5).

lu

diffrentes manires. Le choix du type dannonce va influer sur la manire de faire

Cest le comportement par dfaut des tunnels MPLS-TE. Ceux-ci ne sont pas annoncs

adresse ou un prfixe IP.


Exemple de configuration :

PD
F

dans lIGP, il faudra alors spcifier des routes statiques via le tunnel pour des une

pe

rt

P4(config)#ip route 192.168.0.0 255.255.255.0 tunnel 1

Rsultat dans la table de routage :


192.168.0.0/24 is directly connected, Tunnel1

Ex

50

Mode dannonce du tunnel IGP Shortcut, Autoroute


Ce mode annonce le tunnel TE dans la table de routage IGP du routeur de tte du tunnel
TE. La mtrique associe au tunnel est :

La mtrique cumule du chemin travers.

Ou

La mtrique autoroute TE , qui peut tre absolue ou relative (-10 ; +10) celle
du chemin travers.

Configuration dun tunnel MPLS-TE en mode IGP Shortcut, Autoroute :

interface Tunnel1
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric absolute 10

at
io

o tunnel mpls traffic-eng autoroute announce : annonce le tunnel dans la table de


routage IGP du routeur de tte du tunnel

lu

o tunnel mpls traffic-eng autoroute metric [absolute|relative] : valeur de la

Ev
a

mtrique associe au tunnel.

Aperu de la table de routage du routeur de tte du tunnel MPLS-TE configur en mode

is variably subnetted, 24 subnets, 2 masks


[115/10] via 10.2.0.1, Tunnel1
[115/30] via 10.0.47.2, GigabitEthernet1/0
[115/30] via 10.0.47.2, GigabitEthernet1/0
[115/20] via 10.0.47.2, GigabitEthernet1/0
[115/10] via 10.2.0.1, Tunnel1
[115/10] via 10.2.0.1, Tunnel1

pe

rt

P4#sh ip route
[]
10.0.0.0/8
I L1
10.0.12.0/24
I L1
10.0.13.0/24
I L1
10.0.15.0/24
I L1
10.0.17.0/24
I L1
10.0.23.0/24
I L1
10.0.26.0/24
[]

PD
F

IGP Shortcut, Autoroute :

Ex

On observe que le Tunnel TE bien pris sa place dans la table de routage Ipv4.

Mode dannonce du tunnel IGP Shortcut Forwarding Adjacancy


Le dernier mode dannonce des tunnels MPLS-TE est le mode IGP Shortcut Forwarding
Adjacancy . Celui-ci annonce le tunnel MPLS-TE comme un nouveau lien dans la
topologie de lIGP. Tous les routeurs en sont donc informs. Ce mode ncessite que le
tunnel soit bidirectionnel, et que les deux tunnels soient configurs de la faon
suivante :
interface Tunnel1
tunnel mpls traffic-eng forwarding-adjacency
isis metric 8 level-1

51

Choix des solutions et faisabilit


o tunnel mpls traffic-eng forwarding-adjacency : active le forwarding Adjacancy
pour le tunnel MPLS-TE
o isis metric 8 level-1 : spcifie la valeur de la mtrique IGP annonce pour le
tunnel (10 par dfaut).
Statut des tunnels annoncs en IGP Shortcut Forwarding Adjacancy :
P4#sh isis mpls traffic-eng tunnel
System Id
Tunnel Name
BW Metric
Forwarding-adjacencies
System Id
Tunnel Name
BW Metric
P2.00
Tunnel1
8
L1

Nexthop

Metric

Mode

Metric

Type
10.2.0.1

Nexthop
0

Rsultat dans les tables de routage : P4 est le routeur de tte du tunnel, P7 est un

at
io

routeur de la topologie IGP :

lu

P4#sh ip route
I L1
10.0.12.0/24 [115/18] via 10.2.0.1, Tunnel1
I L1
10.0.15.0/24 [115/28] via 10.2.0.1, Tunnel1
I L1
10.0.17.0/24 [115/20] via 10.0.47.2, GigabitEthernet1/0

Ev
a

P7#sh ip route
I L1
10.2.0.1/32 [115/18] via 10.0.47.1, GigabitEthernet4/0

Le tunnel est dclar dans la table de routage avec un poids ISIS gal 8. La table de
routage du routeur P7 bien pris en compte ce nouveau lien dans ses calculs de plus

PD
F

court chemin.

4.3.2 Protection des tunnels MPLS-TE


Pour fiabiliser un tunnel MPLS-TE, plusieurs modes de protection existent :

rt

Relance de la procdure dtablissement (4.2.2) :

pe

o Liste de chemins explicites non prtablis.

Ex

o Relance calcul CSPF.

La protection globale, o un tunnel de secours complet est prtabli.

La protection locale, appele Fast-Reroute , qui consiste trouver des


solutions locales de secours autour dune coupure de lien ou de nud et de
reprendre ensuite le chemin initial.

Ces deux derniers modes peuvent cohabiter, toutefois, certaines restrictions existent :

Un tunnel de protection globale ne peut tre lui-mme protg par de la


protection locale Fast-Reroute .

52

Les chemins des tunnels de protection globale doit tre explicite.

Le routeur de tte du tunnel ne peut pas utiliser les deux modes simultanment.

Dans ce test, nous avons tabli un tunnel MPLS-TE entre les routeurs P2 et P4 via P3 et
P8 et un tunnel de secours via P1 et P7. (cf. figure 25).

lu

at
io

Protection globale :

Tunnel MPLS TE
bidirectionnel
P4-P2

Ex

pe

rt

PD
F

Ev
a

Tunnel MPLS TE
Protection globale
bidirectionnel
P4-P2

Figure 25 Exemple de protection globale dun tunnel MPLS-TE

Sur le routeur de tte du tunnel MPLS-TE protger, il faut dabord configurer un


chemin explicite pour le tunnel de protection :
ip explicit-path name Tunnel_1_sec enable
next-address 10.7.0.1
next-address 10.1.0.1

53

Choix des solutions et faisabilit

Configuration dun tunnel de protection globale pour un tunnel MPLS-TE :


interface tunnel 1
tunnel mpls traffic-eng path-option protect 1 explicit name Tunnel_1_sec

o Protect 1 : Il est possible de dclarer jusqu 8 tunnels de protection globale,


identifis par niveau de priorit.
o Name Tunnel_1_sec : Chemin explicite du tunnel de protection globale.
En situation nominale, le tunnel MPLS-TE primaire est en service, celui de protection
globale est en attente. Il est galement signal et rserve des ressources dans la

topologie TE :

Ev
a

lu

at
io

P4#sh mpls traffic-eng tunnels tunnel 1


Name: P4_t1
(Tunnel1) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 15)
Path Protection: 0 Common Link(s), 0 Common Node(s)
path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)
[]

Sont indiqus ci-dessus :

o Le chemin de protection globale choisi et son poids.

PD
F

o Le nombre de liens et de nuds communs entre le chemin nominal et le chemin


de protection globale.

Ex

pe

rt

P4#sh mpls traffic-eng tunnels tunnel 1 protection


P4_t1 LSP Head, Tunnel1, Admin: up, Oper: up
Src 10.4.0.1, Dest 10.2.0.1, Instance 141
Fast Reroute Protection: None
Path Protection: 0 Common Link(s), 0 Common Node(s)
Primary lsp path:10.0.48.1 10.0.48.2
10.0.38.2 10.0.38.1
10.0.23.2 10.0.23.1 10.2.0.1
Protect lsp path:10.0.47.1 10.0.47.2
10.0.17.2 10.0.17.1
10.0.12.1 10.0.12.2 10.2.0.1
[]

Cette commande permet de visualiser ltat du tunnel de protection globale. Ces


derniers hritent des paramtres tunnel primaire (mtrique TE ou IGP, type dannonce
IGP, affinit).

54

Lors de la phase dtablissement, le tunnel de secours ne stabli quaprs le primaire.


On ne peut donc pas redmarrer le tunnel ou changer sa configuration lorsque celui-ci
est en mode dgrad.
Les vnements dclencheurs dune bascule sur le tunnel de protection globale sont les
suivants :

Erreur dtablissement du tunnel MPLS-TE primaire (via signalisation RSVP-TE).

Notification de perte dadjacence via lIGP, RSVP Hello, Bidirectional


Forwarding Detection (BFD).
Premption des ressources TE par un tunnel aux priorits plus importantes.

at
io

Lorsque le tunnel TE primaire est hors service, celui de protection globale devient actif :

Ev
a

lu

P4#sh mpls traffic-eng tunnels tunnel 1


Name: P4_t1
(Tunnel1) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)
path option 1, type explicit Tunnel_1_pri
Path Protection: Backup lsp in use.
Path protect option 1, type explicit Tunnel_1_sec (Basis for Protect, path
weight 21)

rt

PD
F

P4#sh mpls traffic-eng tunnels tunnel 1 protection


P4_t1
LSP Head, Tunnel1, Admin: up, Oper: up
Src 10.4.0.1, Dest 10.2.0.1, Instance 79
Fast Reroute Protection: None
Path Protection: Backup lsp in use.

pe

Mesure du temps de convergence du chemin de protection globale : Ci-dessous, test de


coupure de tunnel TE. Une trace de ping entre les deux machines QEMU dont le trafic

Ex

circule via le tunnel TE.

Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 8/76/304 ms

1% de pertes lors dune bascule Tunnel TE principal / Tunnel TE de secours. A la vue des
faibles performances du simulateur (latence en 8 et 304ms), il est impossible de
quantifier le temps de convergence.
Ci-dessous, le test inverse, o lon rtablit le trafic sur le tunnel principal :
Sending 100, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

55

Choix des solutions et faisabilit


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/37/172 ms

Aucune perte nest observe dans ce cas.


En cas de dfaut du tunnel MPLS-TE, le mode de protection globale fournit une
convergence plus rapide quun second chemin principal explicite ou dynamique.
Le temps de convergence est toutefois dpendant du nombre de sauts effectus par le
tunnel et des dlais de propagation jusquau routeur de tte. Le temps de convergence
reste toutefois trop important pour envisager la circulation de trafic contraintes fortes
de qualit de services tels que de la voix ou de la tlphonie sur IP.

at
io

Protection locale dun lien ou dun nud Fast Reroute (FRR) :


Le mode de protection Fast Reroute permet damliorer les lacunes des modes
prcdents en termes de temps de convergence.

lu

La protection locale dun lien ou dun nud seffectue sur le nud en amont, o est

pe

rt

PD
F

Next Next HOP (NNHOP).

Ev
a

cr un tunnel de protection locale unidirectionnel FRR de type Next HOP (NHOP) ou

Ex

Figure 26 Tunnel de protection Next Hop

Figure 27 Tunnel de protection Next Next Hop

56

Dans notre configuration les deux types de tunnels de Fast-Reroute sont tests :

Un tunnel NHOP qui protge le tunnel principal dune dfaillance du lien P8-P3.

Un tunnel NNHOP qui protge le tunnel principal dune dfaillance du nud P3.

Ces tunnels sont unidirectionnels, ils ne protgent le tunnel principal que dans le sens

at
io

P4-P2.

Ev
a

10.5.0.1

Tunnel MPLS TE
bidirectionnel
P4-P2

Ex

pe

rt

PD
F

Tunnel
Fast-Reroute
NNHOP
P8-P2

lu

Tunnel
Fast-Reroute
NHOP
P8-P3

Figure 28 Exemple de protection FRR dun tunnel MPLS-TE

La procdure de cration de tunnels de protection locale FRR est :


(1)

Activer le FRR dans la configuration du tunnel TE sur le routeur de tte :


interface tunnel 1
tunnel mpls traffic-eng fast-reroute

57

Choix des solutions et faisabilit


(2)

Cration du tunnel de protection de lien (NHOP) ou de nud (NNHOP) sur le


routeur P8 en amont du lien / nud protger :
interface Tunnel 100
ip unnumbered Loopback1
tunnel destination 10.3.0.1 | 10.2.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name Tunnel_100_frr

o tunnel destination : 10.3.0.1 pour du NHOP


o tunnel destination : 10.2.0.1 pour du NNHOP
Chemin explicite du tunnel de protection FRR :
ip explicit-path name Tunnel_100_frr enable
include-address chemin complet NHOP ou NNHOP
ou
exclude-address 10.0.38.2 ou 10.3.0.1

(3)

spcifier ladresse du lien ou nud protger.

at
io

Il est possible de spcifier le chemin complet du tunnel NHOP/NNHOP ou de

lu

o exclude-address 10.0.38.2 : Pour une protection de lien, spcifier

Ev
a

ladresse ip du lien exclure (adresse de linterface du routeur).


o exclude-address 10.3.0.1 : Pour une protection de nud, spcifier la

(4)

PD
F

loopback du nud protger.

Association du tunnel de FRR avec linterface protger (interface daccs au lien


ou nud protger) :

(5)

rt

interface gi 2/0
mpls traffic-eng backup-path tunnel 100

Paramtres spcifiques du tunnel de FRR :


backup-bw

[global-pool|sub-pool|any]

Ex

pe

interface tunnel 100


tunnel
mpls
traffic-eng
[valeur|Unlimited]

Spcifie la bande passante TE du tunnel de FRR et son type dallocation.


(6)

Cration dune session RSVP Hello entre le lien ou nud protger et le nud
en amont. Cette session permettra dtecter les dfaillances :
Configuration gnrale du routeur
ip rsvp signalling hello
interface gi 2/0
ip rsvp signalling hello

Initie la session RSVP Hello entre les routeurs, configurer globalement


(protection du nud) puis sur les interfaces protger (protection du lien).

58

Dtails dune session RSVP Hello entre P8 et P3 :


P8#sh ip rsvp hello client nbr detail
Hello Client Neighbors
Remote addr 10.0.38.1, Local addr 10.0.38.2
Nbr State: Normal
Type: Reroute
Nbr Hello State: Up
LSPs protecting: 2
I/F: Gi2/0

Les tunnels de FRR ne sont pas associs un tunnel MPLS-TE en particulier. Ils protgent
tous les LSP des tunnels MPLS-TE qui transitent par les liens/nuds protgs. Les
tunnels ligibles la protection seront slectionns en fonction des ressources
disponibles dans la topologie TE, des paramtres des tunnels de FRR et des paramtres

at
io

de bande passante et niveaux de premption des tunnels TE.

Dtails des tunnels MPLS-TE protgs par les tunnels de protection FRR :

lu

P8#sh mpls traffic-eng fast-reroute database


Headend frr information:
Protected tunnel
In-label Out intf/label

FRR intf/label

Ev
a

LSP midpoint frr information:


LSP identifier
In-label Out intf/label
FRR intf/label
10.4.0.1 1 [14]
34
Gi2/0:33
ready

Status
Status
Tu100:33

PD
F

On voit ci-dessus que le tunnel 1 de P4 est pris en compte par un tunnel de FRR.
On peut galement noter les labels MPLS en situation nominale et en situation de FRR.

pe

rt

P4#sh mpls traffic-eng tunnels tunnel 1 protection


P4_t1
LSP Head, Tunnel1, Admin: up, Oper: up
Src 10.4.0.1, Dest 10.2.0.1, Instance 14
Fast Reroute Protection: Requested
[]

Du point de vue de P4, la protection FRR est demande. Le tunnel sera ligible au FRR

Ex

dans la topologie.

En situation de dfaut du lien ou nud protg, la session RSVP Hello nest plus active,
le dfaut est alors dtect et le Fast Reroute activ :
P8#sh mpls traffic-eng fast-reroute database
Headend frr information:
Protected tunnel
In-label Out intf/label

FRR intf/label

LSP midpoint frr information:


LSP identifier
In-label Out intf/label
FRR intf/label
10.4.0.1 1 [14]
34
Gi2/0:33
active

Status
Status
Tu100:33

59

Choix des solutions et faisabilit


Du point de vue du routeur de tte du tunnel P4, linformation du FRR le long du chemin
est transmise sans que cela nimpacte ltat du tunnel :
P4#sh mpls traffic-eng tunnels tunnel 1
Name: P4_t1
(Tunnel1) Destination: 10.2.0.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 1, type explicit Tunnel_1_pri (Basis for Setup, path weight 5)
Change in required resources detected: reroute pending

Linformation de reroutage est transmise au routeur de tte du tunnel TE. Une


roptimisation pourra tre lance pour trouver un meilleur chemin.
La cration des tunnels de protection FRR dun lien ou dun nud peut galement tre

effectue automatiquement via la configuration suivante :

[mask

lu

at
io

Configuration gnrale du routeur :


mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel backup nhop-only
mpls traffic-eng auto-tunnel backup tunnel-num [min num] [max num]
mpls traffic-eng auto-tunnel backup timers removal unused sec
mpls traffic-eng auto-tunnel backup config affinity affinity-value
mask-value]

Ev
a

o auto-tunnel backup : Active la protection FRR automatique.


o auto-tunnel backup nhop-only : exclu la cration de tunnels FRR NNHOP.

des tunnels FRR.

PD
F

o auto-tunnel backup tunnel-num [min num] [max num] : identifiant mini et maxi

o auto-tunnel backup timers removal unused sec : temps avant quun tunnel FRR
automatique non utilis soit supprim.

rt

o auto-tunnel backup config affinity affinity-value [mask mask-value] : prcise

pe

laffinit des tunnels FRR automatiques.

Ex

Dans la maquette de test, nous navons pas pu voir de diffrence significative sur les
temps de convergence aprs dfaillance entre les modes de protection globale et de
protection locale FRR. Cependant, le nombre de sauts et la charge de notre maquette
est limite, et toutes les rfrences ce sujet concordent sur le fait que le mode de
protection Fast-Reroute fournit une convergence plus rapide que le mode de protection
globale. Notamment parce quil ne dpend pas des dlais de propagation dans le rseau.
Aussi, il est prconis dans le cas de trafics forte contraintes de QoS tels que de la voix
ou de la tlphonie sur IP.

60

4.3.3 Partage de charge entre plusieurs tunnels


Un partage de charge entre plusieurs tunnels (primaire ou de FRR) peut stablir si :

Les tunnels ont la mme origine/destination.

Les tunnels ont le mme poids (mtrique TE en statique et IGP Shortcut


autoroute , mtrique IGP en IGP Shortcut forwarding Adjacancy ).

Le partage de charge est effectu en fonction du rapport de bande passante TE des


tunnels ou en fonction des poids de rpartition attribus :
interface tunnel 1
tunnel mpls traffic-eng load-share [poids de 61epartition]

Daprs les spcifications fournies par Cisco, le partage de charge au moyen de tunnels

at
io

MPLS-TE conserve le squencement des datagrammes TCP. Ce dernier point, important


du point de vue des performances pour lutilisateur final, sera toutefois vrifier.

Ev
a

lu

4.4 Types de trafic supports par les tunnels MPLS-TE


Trafic Ipv4

Comme indiqu dans la partie 4.3.1, deux solutions existent pour router du trafic Ipv4

PD
F

dans un tunnel MPLS-TE :

Route statique dune adresse ou un prfixe via un tunnel MPLS-TE.

Dclarer le tunnel dans lIGP (mode IGP shortcut autoroute ou IGP shortcut

pe

rt

Forwarding adjancy).

Ex

L2VPN-PW

Les L2VPN-PW utilisent la table de commutation MPLS pour acheminer le trafic. Ce


dernier suit donc le routage dfini par lIGP dans le rseau.
Pour diriger explicitement le trafic dun L2VPN-PW, il est possible dassocier le L2VPNPW et son VC un tunnel MPLS-TE. Pour cela on utilise la fonction Preferred Path .

61

Choix des solutions et faisabilit


Pseudo-Wire
Dirig dans
tunnel TE

Tunnel
TE

Mapping VLAN ID vers VC ID

Vlan 2000

Mapping VC ID vers VLAN ID

VC 222

VC 222

Nuage MPLS-TE

PE 1

CE 1

Vlan 2000

CE 2

PE 2

Figure 29 L2VPN Pseudo-Wire dirig dans un tunnel MPLS-TE

at
io

pseudowire-class L2VPN
encapsulation mpls
preferred-path interface Tunnel1 [disable-fallback]

Exemple de configuration :

En cas de panne du tunnel TE, le L2VPN utilise le routage standard IGP. Loption *disable-

Ev
a

Dtail dune connexion L2VPN :

lu

fallback] permet de dsactiver le L2VPN si le tunnel nest pas oprationnel.

PD
F

P4#sh mpls l2transport vc detail


Local interface: Gi3/0.2000 up, line protocol up, Eth VLAN 2000 up
Destination address: 10.2.0.1, VC ID: 222, VC status: up
Output interface: Tu1, imposed label stack {33 16}
Preferred path: Tunnel1, active
Default path: ready [disable]
Next hop: point2point

o Output interface : le tunnel est slectionn comme route prfre.

rt

o Pile de labels MPLS {33 16} : 33 pour le label du L2VPN ; 16 pour le label de sortie

pe

du tunnel MPLS-TE.

Ex

o Default path :

62

*Ready+ si IGP utilis lorsque le tunnel nest pas oprationnel.

*disable+ si loption *disable-fallback] est utilise.

L3VPN
Les L3VPN MPLS utilisent la table de commutation MPLS pour acheminer le trafic dun
PE lautre. Dans le mode par dfaut, le trafic suivra donc le routage dfini par lIGP. On
peut toutefois dclarer des chemins explicites pour les VRF des L3VPN. Pour cela, il faut
dclarer une route dans VRF vers le PE de sortie Next Hop via un tunnel MPLS Traffic
Engineering.

Cette mthode peut sappliquer une route entre deux PE (Un seul Tunnel TE uni ou
bidirectionnel), comme lensemble du plan de routage spcifique la VRF (Cration

maintenir).

Ev
a

lu

CE 2

at
io

dun maillage complet entre les PE concerns par la VRF, N(N-1)/2 connexions crer et

Peering
eBGP

PD
F

PE2

RR

Ex

pe

rt

Tunnels
TE

PE 1

PE 3

CE 1

CE 3

Figure 30 Utilisation de tunnels TE avec des L3VPN MPLS

La procdure est de configuration est :


1. Crations une loopback L (non annonce dans lIGP).
2. Dclaration de cette loopback comme identifiant du routeur dans la vrf.
3. Sur les autres PE dans la vrf : Cration une route statique vers la loopback L via le
tunnel MPLS-TE.
63

Choix des solutions et faisabilit


Exemple de configuration :
Sur PE1

Sur PE3

interface Loopback2
ip address 10.2.1.1 255.255.255.255

interface Loopback2
ip address 10.4.1.1 255.255.255.255

ip vrf RED
rd 2200:2
route-target export 2200:2
route-target import 2200:2
bgp next-hop Loopback2

ip route
tunnel 1

10.4.1.1

255.255.255.255

ip
route
tunnel 1

10.2.1.1

255.255.255.255

Rsultat dans les tables de routage :


S
10.2.1.1/32 is directly connected,
Tunnel1

at
io

S
10.4.1.1/32 is directly connected,
Tunnel1

4.5 Gestion centralise de MPLS-TE

lu

La cration et la gestion manuelle de tunnels MPLS-TE est possible pour un besoin ou un

Ev
a

projet ponctuel, comme pour la gestion des flux LHCONE. Cependant, la gnralisation
de MPLS-TE, son utilisation comme un niveau dinfrastructure part entire ncessitera
dutiliser un outil de gestion centralis, et ce pour deux raisons :
Humaine, car la gestion manuelle dun grand nombre de tunnels MPLS-TE

PD
F

concurrents devient quasi-impossible partir dun certain point.

Technique, car le mode dcentralis, o les tunnels MPLS-TE sont connus et

pe

rt

crs localement, gnre une sous-optimisation de la topologie TE.

Ex

Les besoins de notre projet ne ncessitent pas le dploiement dune architecture


centralise, toutefois, il est intressant de connaitre les produits existants sur le march.
Nous avons recenss les outils de gestion centralise MPLS-TE suivants :

Cisco IP center.

WanDL IP/MPLSView.

WebNMS MPLS-TE.

Packet design TE Explorer.

Totem (Toolbox for Traffic Engineering Methods).

Il est toutefois difficile de sappuyer sur un outil de gestion automatique sans craindre
de bug.

64

5 Gnralisation et Dploiement
5.1 Fonctionnalits MPLS-TE dans le primtre rseau R-5
Pour rappel, les quatre types de routeurs concerns dans cette tude sont :
Type de routeur
Cisco 7609
Cisco 6509-E
Cisco 12410
Cisco CRS-1

Version logicielle
Version 12.2(33) SRE3
Version 12.2(33) SXJ et Version 12.2(18) SXF12a
Cisco IOS XR Software, Version 3.9.1
Cisco IOS XR Software, Version 4.0.1

Nous avons dress ci-dessous un inventaire de disponibilit, pour chaque plateforme et

version logicielle, des fonctions de MPLS-TE tudies dans la section prcdentes. Ce

at
io

tableau a t ralis grce aux documentations disponibles sur le site internet

650X v12.2(33)SXJ
650X v12.2(18)SXF12a

pe

CRS-1 IOS XR v4.0.1

Ev
a

rt

12000 IOS XR v3.9.1

MP
LS

7609 v12.2(33)SRE3

PD
F

IOS

Exte
n

Chassis

-Tra

sion

IS-I
S

TE

lu

ffic
Eng
Aut
in e
ob
erin
an d
g
wid
th
IGP
/ TE
me
tric
Fas
t Re
rou
te (
FRR
Pat
)
hP
rote
ctio
n
Aut
oro
ute
Ann
For
oun
war
ce
d in
gA
dja
P ar
cen
tag
cy
e de
cha
rge
Diff
-Ser
v-A
wa r
e (D
CoS
S-T
Tun
E)
nel
Sele
L2V
ctio
PN
n
: Tu
nne
l Se
lect
ion

www.cisco.com.

Fonctionnalits vrifies avec des IOS Advance Enterprise Services

Ex

Un seul routeur 6509-E (Orsay-swi-001), en version 12.2(18) SXF12a, nest pas


compatible avec toutes les fonctionnalits MPLS-TE. Il sera mis jour en 12.2(33) SXJ.
Aussi, les trafics spcifis comme compatibles avec MPLS-TE sont :

Ipv4 unicast.

Tout trafic encapsul dans MPLS.

A linverse, les incompatibilits sont :

Le trafic Ipv6 nest pas support. La cohabitation avec MPLS-TE ncessite une
sparation des tables de routage Ipv6 dans lIGP.

Le trafic multicast nest pas support mais nest normalement pas impact.
65

Gnralisation et Dploiement

5.2 Choix de mise en uvre du projet LHCONE


Larchitecture cible du projet LHCONE France est :

Chaque site Tier2 LHCONE est raccord via un L2VPN MPLS-TE (qui sont nomms
L2VPN-TE) au rseau LHCONE France en deux points : Paris 1 et Lyon 1, qui
sont les points de sortie vers le LHCONE sur GEANT.

Les sites tablissent deux sessions BGP, au travers de chacun de ces L2VPN-TE. Le
site choisit son point de sortie principal via une rgle en sortie de Local Pref .

La scurisation sera effectue grce ces deux sessions BGP. Les mcanismes de

Ex

pe

rt

PD
F

Ev
a

lu

at
io

scurisation des L2VPN-TE ne seront pas utiliss.

Figure 31 Architecture cible sites Tiers 2 / FR LHCONE

Afin de respecter les contraintes temporelles du projet, jai propos de nutiliser que des
fonctionnalits simples de MPLS-TE, pour raliser cette architecture, savoir :

66

Tunnel MPLS-TE chemin explicite. Aucune utilisation des autres contraintes TE.

Slection de chemin prfr via tunnel MPLS-TE pour L2VPN-PW.

En prvision dautres utilisations de MPLS-TE sur RENATER, le protocole ISIS-TE sera


dploy sur tous les routeurs compatibles.

Matrice des trafics RENATER et choix des chemins LHCONE L2VPN TE


Afin de determiner les chemins les moins chargs sur RENATER, et donc o il sera
souhaitable de diriger les L2VPN-PW du LHCONE France, la mtrologie des diffrents
chemins entre chaque sites Tiers 2 LHCONE et leurs points de sortie Paris 1 et Lyon 1
t tudie. (Cf Etude de la mtrologie LHCONE Tiers 2 : 9 Annexes)
Il apparat que :

La sortie prfre vers le LHCONE devra tre le plus possible vers Genve (donc

at
io

par Lyon 1) car une liaison LHCONE transcontinentale vers les USA est en cours
deploiement Genve (mise en service prvue pour lt 2012).

Malgr lutilisation de MPLS-TE, certaines interconnexion sont invitables et dj

lu

satures. Elles se comportent comme des goulets dtranglement. Cest le cas de

Ev
a

la liaison entre les routeurs de Lyon1 (rtr001) Lyon1 (rtr021). Un projet de


doublement de capacit (2x10G) est alors planifi.
Aussi, la capacit des liens Paris 1 Lyon 1 et Paris 2 Lyon 2 a t double, et une

PD
F

nouvelle liaison Marseille 2 Lyon 2 a t ajoute, entre le temps de cette tude et la


suite du projet.

rt

Cette tude des trafics dans le rseau RENATER est mettre en relation avec un autre

pe

projet de modification de linfrastrucutre RENATER.


Jusqu juillet 2012, la connexion avec le rseau GEANT, pour le trafic IP standard, se

Ex

situait sur le NR de Paris1. Cette liaison tait sature, et RENATER et GEANT ont t
forcs dutiliser provisoirement la liaison de secours depuis Paris2, ce qui nest pas
souhaitable. (cf figures 32 et 33).
Une tude dorigine et destination des flux demontr quune partie importante du
trafic tait destination et vers les utilisateurs RENATER raccords sur Lyon1. Un
nouveau raccordement RENATER/GEANT Genve a alors t planifi.
Hors, la liaison Lyon1 Genve, dj occupe par le trafic du LHCONE, ne pourrait pas
supporter ce nouveau cumul de trafic. Ce trafic passera donc dans un L2VPN-TE via le NR
de Grenoble (cf figure 31), la liaison Grenoble Genve tant alors inutilise (cf figure 35).

67

Gnralisation et Dploiement
Les graphes suivants reprsentent la quantit de trafic coule, en Gigabit par secondes,
sur la priode de Janvier mai 2012.

Ev
a

lu

at
io

Figure 32 Liaison primaire RENATER / GEANT sature

Ex

pe

rt

PD
F

Figure 33 Liaison de secours RENATER/GEANT utilise provisoirement

Figure 34 Liaison Lyon1 Genve, dj utilise par le LHCONE

Figure 35 Liaison Grenoble Genve inutilise

68

Ex

pe

rt

PD
F

Ev
a

lu

at
io

Les propositions de chemins principaux et secondaires sont les suivantes :

Figure 36 Chemins principaux LHCONE L2VPN TE

69

Ex

pe

rt

PD
F

Ev
a

lu

at
io

Gnralisation et Dploiement

Figure 37 Proposition de chemins secondaires LHCONE L2VPN TE

70

5.3 Validation sur lensemble du primtre


Dans la section 4, nous avons test et valu les fonctionnalits de MPLS-TE dans un
environnement de simulation. Toutefois, les rgles dingnierie et de dploiement sur
RENATER nous imposent de procder une phase de validation en environnement rel,
afin de sassurer de la non perturbation du dploiement sur les services en production.

Pour ce faire, nous avons tout dabord utilis le banc de test disponible dans les locaux
parisiens BT. Hors, ce banc de tests est rduit trois quipements (Cisco 7600, 12000 et
7200) et nous navons pas pu valider nos tests sur les plateformes 6500 et CRS-1,

at
io

essentiels au fonctionnement de RENATER (Cf. 3.3.1).

Nous avons alors planifi avec Cisco un programme de tests et validation, intitul Cisco

lu

Customer Proof Of Concept, CPOC (Etude de faisabilit de concept pour les clients

Ev
a

Cisco), o nous avons bnfici de tous les types dquipements rseaux prsents sur
RENATER. Ce CPOC, dune dure dune semaine, sest droul du 5 au 11 mai 2012, dans

PD
F

le centre de tests Cisco San Jos, en Californie aux Etats-Unis.

Bien que lusage initial de MPLS-TE sur RENATER soit restreint (Cf. 5.1), il a t dcid
de tester toutes les fonctionnalits tudies dans la section 4. Aussi, afin de profiter de

rt

lopportunit de ce CPOC, les tests de performance et dintgration dans RENATER de

pe

nouveauts Cisco ont t ajouts, tel que la plateforme routeur ASR9000 et les liaisons

Ex

Ethernet 100 Gigabit.

Afin de pallier aux difficults de reproduire dans un temps trs court le contexte exact
du rseau RENATER, avec tous ses services oprationnels et dans lobjectif de dployer
rapidement dans RENATER les mcanismes MPLS-TE valids, les prparatifs dcris dans
la section suivantes ont ts mis en uvre.

71

Gnralisation et Dploiement
5.3.1 CPOC : Planification et prparatifs
Afin de pouvoir valider, en un temps trs court, lensemble des tests dcrits dans la
section suivante, un cahier de tests a t rdig. Celui-ci dtaille prcisment la mise en
uvre du CPOC : la topologie rseau, les matriels ncessaire, les versions logicielles et
les configurations des routeurs, les scnarios de tests et leurs rsultats attendus. Ce
document a galement pour but de recueillir lensemble des observations et rsultats.
Le cahier de test CPOC est fourni dans sa version finale, allg des configurations des
routeurs, dans lannexe CPOC RENATER5-TE .

at
io

o RENATER : Frdric LOUI, responsable adjoint du ple ISR.

Les participants au CPOC ont t les suivants :

o RENATER : Xavier JEANNIN, ISR, en charge du projet LHCONE.

Ev
a

coordination du CPOC cot RENATER.

lu

o RENATER : Nicolas GARNIER, ISR, en charge du projet MPLS-TE, prparation et

o BT : Florence PICARD, responsable du compte RENATER.


o BT : Dahlia GOKANA, ingnieure rseau.

PD
F

En position dappui technique :

o Cisco : Vincent MAKOWSKI, correspondant ducation et recherche. Prparation


et coordination du CPOC cot Cisco.

pe

rt

o Cisco : Jrme DURAND, consultant routage et commutation.

Ex

La liste des tests et la topologie mise en place sont prsentes dans le tableau et la
figure suivante. La premire partie des tests vise recrer la configuration et les services
actuels prsents sur RENATER-5. La seconde partie traite des fonctionnalits MPLS-TE,
simples et avances. Enfin, la dernire partie est ddie aux tests dinteroprabilit et
de performance de la nouvelle plateforme Cisco ASR9000 et des interfaces 100 Gigabit
Ethernet (100GbE).

72

Planning
prvisionnel

Nom du test

Configuration initiale
Test 1. IPv4 and IPv6 configuration
Test 2. ECMP and LAG configuration
Test 3. ISIS configuration
Test 4. MPLS configuration
Test 5. Injectors capabilities overview (IXIA)
Test 6. BGP configuration
Test 7. Multicast configuration
Test 8. BFD for ISIS
Test 9. L2VPN VLAN Based
Test 10. L3VPN MPLS-VPN: Any to any VRF
Test 11. 6VPE

Valid

Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1
Jour 1

Jour 2
Jour 2
Jour 2
Jour 2
Jour 2
Jour 3
Jour 3
Jour 3
Jour 3
Jour 3
Jour 4
Jour 4
Jour 4
Semaine
Semaine

MPLS-TE Avancs
Test 27. Full mesh

Jour 5

Ex

pe

rt

PD
F

Ev
a

lu

at
io

MPLS-TE
Test 12. ISIS-TE configuration
Test 13. RSVP-TE Topology
Test 14. Explicit path
Test 15. Dynamic path
Test 16. Static route over MPLS-TE tunnels LAG & ECMP usage with TE
Test 17. Auto Bandwidth
Test 18. Autoroute announce
Test 19. Forwarding Adjancy
Test 20. L2VPN TE tunnel selection
Test 21. L3VPN TE tunnel selection
Test 22. Path protection
Test 23. Fast Reroute
Test 24. Load sharing
Test 25. SNMP alarms and statistics
Test 26. Operation Administration and Maintenance (OAM)

Jour 5

100GE tests
Test 28. 100GE performance & stress test between CRS-2 and CRS-6.
ASR-9000 intgration
Test 29. ASR-9000 integration (ISIS, BGP, LDP, RSVP-TE)

Semaine

73

Gnralisation et Dploiement

ASR 9000 9

Traffic
Injector - 1

7600 1

7600 5

Traffic Injector - 3
Full routing BGP

70 isis adjacency

CRS 2

Traffic injector

pe

Ex

12K

7600 7

rt

CRS1

7604S

LACP

PD
F

7600 3

Ev
a

LACP

lu

at
io

CRS 6

6500 4

12000 8

6504-E
ASR
9000

Ethernet 100Gb
Ethernet 10Gb
Ethernet 1Gb

Traffic
Injector - 2
Figure 38 Topologie du CPOC RENATER-5

Lobjectif de cette topologie est de permettre tous les tests ncessaires pendant le
CPOC. Puisque cette topologie est prpare lavance de la semaine de tests, celle-ci ne
pourra tre modifie et il a donc t important denvisager tous les cas de figure.

74

5.3.2 Protocole de test dfini


Le protocole gnral de test et de validation, pour tous les tests suit le cycle suivant :

1 - Test unitaire numro X

2 - Configuration de tout les


routeurs. validation des
fonctionnalits et
comportements

lu

at
io

4 - Le rapporteur des tests


consigne les rsultats et
archive les sauvegardes

Ev
a

3 - sauvegarde des
configurations des routeurs
et des traces de rsultats
dans Test_X_router_Y.zip

PD
F

Figure 39 Protocole de rapport des tests CPOC

Objectifs : Description brve des objectifs fonctionnels du test et des rsultats

pe

rt

Chaque test est organis suivant les points :

attendus.

Conditions : Prrequis matriels, protocolaires. Description du droulement du

Ex

test.

Configuration : Configuration complte des routeurs pour le test.

Rsultats : Traces de routeurs, tests de performance.

Commentaires et recommandations.

75

Gnralisation et Dploiement
5.3.3 CPOC, exemple de test : Etablissement de tunnel TE chemin
explicite

Objectifs
Valider ltablissement dun tunnel MPLS-TE chemin explicite sur les plateformes
logicielles IOS et IOSXR.

Conditions
Dans le test suivant, tous les routeurs implmentent MPLS-TE. Les routeurs 7600-1,
1200-8, 6500-4 and CRS-2 seront les ttes (HEAD-END) de 3 tunnels aux chemins
suivants :
Tunnel 1018 : 7600-1 CRS-2 7600-3 12000-8

Tunnel 1014 : 7600-1 CRS-2 7600-7 6500-4

Tunnel 1028 : CRS-2 CRS-6 7600-3 7600-7 12000-8

lu

at
io

Ev
a

Le numro dinterface des tunnels est dclar sous la forme 10XY . 10 signifie que
cest un tunnel TE chemin explicite. X est le numro du routeur de tte, Y le numro du

PD
F

routeur de queue.

Tous les tunnels sont galement crs dans le sens inverse. Les paramtres par dfaut
sont appliqus aux tunnels, les contraintes comme la bande passante requise, les

rt

priorits etc. ne sont pas appliques ici.

Ex

pe

La topologie mise en uvre est dcrite dans la figure 40 page suivante.

76

ASR
9000 9
Traffic
Injector - 1

7600 1

7600 5

Traffic Injector - 3

Tunnel
1018/1081

Full routing BGP

Tunnel
CRS1 2
1014/1041

CRS1 6

Tunnel
1028/1082
LACP

at
io

LACP

7600 3

7600 7

PD
F

Ev
a

lu

&

12000 8

pe

rt

6500 4

Traffic
Injector - 2

Ex

Figure 40 Topologie de lexemple Etablissement de tunnel TE chemin explicite

Configurations
! Pour CRS-2
!
explicit-path name CRS-212000-8
index 10 next-address strict ipv4 unicast 10.3.6.1
index 20 next-address strict ipv4 unicast 10.3.3.1
index 30 next-address strict ipv4 unicast 10.3.7.1
!
interface tunnel-te 1028
description TUNNEL TE1028CRS-212000-8
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.8.1
path-option 10 explicit name CRS-212000-8
!

77

Ev
a

at
io

lu

! Pour 12000-8
!
explicit-path name 12000-87600-1
index 10 next-address strict ipv4 unicast 10.3.3.1
index 20 next-address strict ipv4 unicast 10.3.2.1
!
explicit-path name 12000-8CRS-2
index 10 next-address strict ipv4 unicast 10.3.7.1
index 20 next-address strict ipv4 unicast 10.3.3.1
index 30 next-address strict ipv4 unicast 10.3.6.1
!
interface tunnel-te 1081
description TUNNEL TE108112000-87600-1
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.1.1
path-option 10 explicit name 12000-87600-1
!
interface tunnel-te 1082
description TUNNEL TE108212000-8CRS-2
ipv4 unnumbered Loopback2
load-interval 30
destination 10.3.2.1
path-option 10 explicit name 12000-8CRS-2
!

Gnralisation et Dploiement

Ex

pe

rt

PD
F

! Pour 7600-1
!
interface Tunnel 1018
description TUNNEL TE10187600-112000-8
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.8.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 7600-112000-8
!
interface Tunnel 1014
description TUNNEL TE10147600-16500-4
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.4.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 7600-16500-4
!
ip explicit-path name 7600-112000-8 enable
index 10 next-address 10.3.2.1
index 20 next-address 10.3.3.1
!
ip explicit-path name 7600-16500-4 enable
index 10 next-address 10.3.2.1
index 20 next-address 10.3.7.1
!

! Pour 6500-4
!
interface Tunnel 1041
description TUNNEL TE10416500-47600-1
ip unnumbered Loopback2
load-interval 30
tunnel destination 10.3.1.1

78

tunnel mode mpls traffic-eng


tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 10 explicit name 6500-47600-1
!
ip explicit-path name 6500-47600-1 enable
index 10 next-address 10.3.7.1
index 20 next-address 10.3.2.1
!

Rsultats
Ces rsultat sont valables IOS & IOSXR : traces de console de routeur, tat dtaill des
tunnels MPLS-TE 1018 et 1028 sur 7600-1 et CRS-2.
7600-1#sh mpls traffic-eng tunnels tunnel 1018

at
io

Name : TUNNEL TE10187600-112000-8


(Tunnel1018) Destination : 10.3.8.1
Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 10, type explicit 7600-1-12000-8 (Basis for Setup, path weight
25)

Ev
a

lu

Config Parameters:
Bandwidth: 100
kbps (Global) Priority: 7 7
Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 100
bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

Ex

pe

rt

PD
F

InLabel : OutLabel : TenGigabitEthernet1/4, 16037


Next Hop : 10.0.12.2
RSVP Signalling Info:
Src 10.3.1.1, Dst 10.3.8.1, Tun_Id 1018, Tun_Instance 1
RSVP Path Info:
My Address: 10.0.12.1
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
Record
Route:
NONE
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
RSVP Resv Info:
Record
Route:
NONE
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
Shortest Unconstrained Path Info:
Path Weight: 25 (TE)
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
History:
Tunnel:
Time since created: 7 minutes, 41 seconds
Time since path change: 6 minutes, 55 seconds
Number of LSP IDs (Tun_Instances) used: 1
Current LSP : [ID : 1]
Uptime : 6 minutes, 55 seconds
RP/0/RP0/CPU0 :CRS-2#sh mpls traffic-eng tunnels 1028
Name : tunnel-te1028 Destination : 10.3.8.1
Status:
Admin:
up Oper:
up
Path: valid
Signalling: connected
path option 10, type explicit CRS-212000-8 (Basis for Setup, path weight
105)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Mon May 7 23:15:21 2012 (00:14:43 ago)
Config Parameters:

79

Gnralisation et Dploiement

at
io

Path info (IS-IS 2200 level-1):


Hop0: 10.0.26.6
Hop1: 10.0.36.1
Hop2: 10.0.37.2
Hop3: 10.0.78.2
Hop4: 10.3.8.1
Displayed 1 (of 1) heads, 0 (of 2) midpoints, 0 (of 1) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads

Bandwidth:
0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (default)
Hop-limit: disabled
AutoRoute: disabled LockDown: disabled
Policy class: not set
Forwarding-Adjacency: disabled
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
History:
Tunnel has been up for: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)
Current LSP:
Uptime: 00:14:43 (since Mon May 07 23:15:21 UTC 2012)

Ces rsultats ne sont valables que pour IOSXR : dtail du chemin explicite du tunnel TE

Ev
a

RP/0/RP0/CPU0:CRS-2#sh explicit-paths
Mon May 7 23:36:22.289 UTC
Path CRS-212000-8
status enabled
0xa: next-address strict 10.3.6.1
0x14: next-address strict 10.3.3.1
0x1e: next-address strict 10.3.7.1

lu

1028 sur CRS-2.

PD
F

Tests de traceroute entre les routeurs CRS-2 et 12000-8, pour les chemins fixs par
lIGP et par le tunnel TE 1028.

pe

rt

RP/0/RP0/CPU0:CRS-2#traceroute 10.3.8.1
Tracing the route to 10.3.8.1
1 10.0.26.2 [MPLS: Label 16031 Exp 0] 37 msec 20 msec 13 msec
2 10.0.67.2 [MPLS: Label 30 Exp 0] 15 msec 13 msec 5 msec
3 10.0.78.2 15 msec * 10 msec

Ex

RP/0/RP0/CPU0 :CRS-2#traceroute mpls traffic-eng tunnel-te 1028


Tracing MPLS-TE Label Switched Path on tunnel-te1028, timeout is 2 seconds
0 10.0.26.5 MRU 9180 [Labels : 16038 Exp : 0]
. 1 *
L 2 10.0.36.1 MRU 9214 [Labels : 118 Exp : 0] 192 ms
L 3 10.0.37.2 MRU 9204 [Labels: implicit-null Exp: 0] 202 ms
! 4 10.0.78.2 15 ms

Commentaires et recommandations
Aucun problme nest rencontr dans ltablissement des tunnels TE chemin explicite.
Linteroprabilit entre les plateformes et les versions logicielles et bonne. Toutes les
plateformes ont t testes en tant que tte et queue de tunnel TE.

80

5.3.4 Conclusions du CPOC


La plupart des tests planifis ont t valids avec succs. Ce CPOC a permis de vrifier
linteroprabilit de MPLS-TE sur les plateformes Cisco (CRS-1, 7600, 7200 et 12000) et
les versions logicielles (IOS et IOS-XR), dans un contexte de configuration et de services
prsents sur RENATER-5.
Toutefois, quelques comportements indsirables ont t observs et quelques
fonctionnalits importantes manquent :
1. A cause dune limite matrielle, les paramtres BFD sur les routeurs 12000 ne

peuvent pas tre rgls moins de 3x250ms. Cela pourra tre un inconvnient

at
io

pour les mcanismes de fast-reroute .

2. Lactivation dISIS-TE provoque des brves pertes de paquets sur les L2VPN. Cette

lu

activation devra donc tre prvue en heures non ouvres (HNO) sur RENATER-5.

Ev
a

3. Les rgles de configuration pour lutilisation de MPLS-TE avec les L3VPN ne sont
pas les mmes pour IOS et IOSXR. Cela pourra tre un problme dun point de
vue oprationnel.

PD
F

4. Le mode de protection globale chemin prtabli nest pas disponible pour les
IOSXR 4.1 prsent sur RENATER-5. Une mise jour en 4.2 est ncessaire.
5. Les temps de convergence avec Fast-Reroute sont trs satisfaisants.

rt

Cependant le FRR ne peut pas tre utilis sur le routeur de tte de tunnel TE.

pe

6. La rpartition de charge sur des tunnels TE est fonctionnelle mais est trop
approximativement contrle.

Ex

7. Les modes dauto configuration de maillage MPLS-TE (auto-tunnel mesh) ont t


tests mais leurs impacts sur les services de RENATER nont pas t vrifis.

8. Les interfaces 100GbE ont t configures avec succs entre les deux routeurs
CRS-2 et CRS-6, mais les tests de performance nont pas pu tre mens cause
dun dfaut dinterface sur les injecteurs de trafic.
Ces conclusions pourront tre utiles lors de futurs projets impliquant MPLS-TE sur
RENATER. Les fonctionnalits requises dans le projet LHCONE ont toutes ts valides.
La section suivante dcris les processus de dploiement et de mise en uvre.

81

Gnralisation et Dploiement

5.4 Dploiement
Le dploiement des fonctionnalits MPLS-TE choisies en 5.2, dans le rseau de
production de RENATER, a t dcompos dans les tapes suivantes :
Etape Description
T0
Etat actuel
T1
Activation dISIS-TE sur 1 routeur
de chaque type.
T2
Cration dun tunnel MPLS-TE de
test, sous surveillance pendant 2
semaines.

T7

T8

82

at
io

lu

Ev
a

PD
F

T6

rt

T5

pe

T4

Eventuelles pertes de paquets sur les


L2VPN, opration effectue en HNO.
Aucun effet ngatif observ sur le rseau.
Les figures 34 et 35 en annexe montrent
ltat de ce tunnel de test et son impact
sur le routeur de tte.
Rdaction de la procdure de Rgles
de
nomenclature
et
de
dploiement et dexploitation
numrotation, rgles de configurations,
procdure de dpannage.
Formation des quipes de BT ces Quatre formations de 3h.
procdures.
Activation dISIS-TE sur tous les Eventuelles pertes de paquets sur les
routeurs.
L2VPN, opration effectue en HNO, et
suivant un planning de migration
progressif.
2 3 routeurs/j. 20 jours de travail pour le
NOC RENATER.
Cration des tunnels TE pour le Aucun effet sur le trafic de production.
site LHCONE de Nantes suivant les
chemins dfinis en 5.2.
Bascule des L2VPN LHCONE dans Eventuelles pertes de paquets sur les
les tunnels MPLS-TE.
L2VPN. Opration effectu en journe et
en coordination avec les responsables des
sites concerns.
Cration des tunnels TE entre Sparation du trafic GEANT standard et
Lyon1 et Genve, puis bascule du LHCONE.
L2VPN-PW LHCONE.

Ex

T3

Effets sur le rseau / Remarques

5.5 Exploitation
La refonte du systme dinformations (SI) de RENATER tant ltude lors de ce projet,
toutes les donnes dexploitation des tunnels TE ont t rpertories dans un fichier de
type tableur Excel.
Ce fichier, fourni en annexe, a t conu dans lobjectif dintgrer les donnes dans le
futur SI. Chaque entre de tunnel TE possde donc une cl de rfrencement unique.
Une carte de supervision Weathermap a t cre spcialement pour le projet
LHCONE. Tous les sites raccords en L2VPN-TE, avec leurs information de chemin

Ex

pe

rt

PD
F

Ev
a

lu

at
io

primaire et secondaire apparaissent.

Figure 41 Weathermap dexploitation LHCONE

83

Rsultats et discussion

6 Rsultats et discussion
6.1 Rsultats du projet
Nous prsentons dans cette partie deux rsultats :

Le fonctionnement des L2VPN-TE entre le site LHCONE de NANTES / Paris 1 et


Lyon 1.

La nouvelle infrastructure dploye entre RENATER et GEANT Genve (cf 5.2),


et les bnfices de lutilisation de MPLS-TE.

La bascule des L2VPN du site LHCONE de Nantes dans des tunnels TE na pas eu dimpact

at
io

ngatif sur le trafic. Nous pouvons observer dans les deux graphes suivants que le trafic
emprunte bien le chemin TE vers Paris 1, suivant la rgle BGP exprime en 5.2. Sur le
L2VPN-TE Nantes-Lyon, on observe un trafic faible et rgulier qui correspond au

PD
F

Ev
a

lu

maintien de la session BGP.

Figure 42 Supervision du L2VPN-TE du site LHCONE de Nantes

pe

rt

Les traces fournies en annexe 8.5 fournissent les tats complets MPLS-TE (IS-IS-TE, RSVP-

Ex

TE, etc.) du routeur de Nantes.

Les traces de mtrologies suivantes illustrent les tapes du projet de nouveau


raccordement RENATER/GEANT Genve.

(1)

Le trafic Lyon1 LHCONE est


bascul dans un L2VPN-TE via
le site de Grenoble (semaine 26
jour 2). Cette liaison de secours
est dsormais mieux utilise.

84

(2)

La nouvelle interconnexion
RENATER / GEANT pour le
trafic IP standard est mise en
service (semaine 26 jour 4).

On observe sur la liaison

(3)

entre

lutilisation

par

at
io

Lyon1 Genve la bascule


le

La liaison RENATER / GEANT

rt

Paris 1 est toujours charge,

pe

cependant lutilisation de la
liaison de secours Paris 2 a

Ex

(4)

PD
F

jour semaine 26).

Ev
a

trafic IP standard (trou dun

lu

LHCONE et lutilisation par le

pu tre arrte (semaine 27).

85

Rsultats et discussion
A partir de ces deux cas de dploiement, nous pouvons tablir que les objectifs suivants,
dfinis en dbut de projet, ont t remplis :

Choix des chemins emprunts par des trafics identifis et meilleure utilisation
des liens de secours. Cette opration, bien que manuelle et qui require une
tude et une surveillance de la matrice des trafics dans le rseau, a permis dans
le cas de lutilisation de la liaison Grenoble Genve dconomiser linstallation
dune nouvelle liaison Lyon Genve, soit environs 50K.

Dcongestion de certains axes et nuds. MPLS-TE nous a permis de dtourner


certains flux du routage normal et a permis la dcongestion planifie de certains

points critiques. Attention toutefois, les mcanismes MPLS-TE associs aux

at
io

classes de services nont pas t traits et seraient srement ncessaires en cas

lu

de panne sur le rseau.

Ev
a

Enfin, ce projet a mis en vidence que certains points et interconnexions se comportent


comme des goulets dtranglement invitables. Les mcanismes dingnierie de trafic
sont alors utiliser en complment, et non en substitut total, de la gestion et du suivi

Ex

pe

rt

PD
F

des capacits de larchitecture et de la topologie rseau.

86

6.2 Retour sur exprience


Nous avons t fortement contraints dans le choix de la solution technique qui nous a
permis de rpondre aux besoins de ce projet. Les technologies MPLS-TE et RSVP-TE sont
aujourdhui les solutions dingnierie de trafic proposes par les grands fabricants de
matriel rseaux.
La validation de MPLS-TE dans le contexte RENATER a t une partie trs importante du
projet, dont les temps auraient difficilement pu tre rduits. En effet, il tait impratif
de ne pas provoquer deffet de bord dans le rseau. La maitrise de limplmentation
Cisco apporte par tous les tests effectus et par le CPOC nous ont permis de dployer

at
io

rapidement la solution.

Enfin, on peut ajouter que les outils de simulation rseau qui ont t mis en uvre pour

lu

ce projet (Dynamips/GNS3 4) sont dsormais utiliss, dans la limite de leurs

Ev
a

possibilits, par les ingnieurs rseaux de RENATER pour des besoins de test et de
spcification.

PD
F

6.3 Perspective

En plus du dploiement des autres sites Tiers 2 LHCONE, dautres usages possibles de
MPLS-TE ont t rpertoris :

o Partage de charge sur laxe doubl Paris-Lyon-Marseille (PLM).

pe

rt

o Gestion des trafics sur laxe PLM via des Tunnels-TE.


o Utilisation de la topologie TE comme indicateur pour rpartir les besoins

Ex

prvisionnels en bande passante des projets scientifiques.

o Utilisation du Fast-Reroute pour fiabiliser le service de voix et tlphonie


sur IP RENATER.

Comme voqu dans la partie 6.1, ltude de lassociation Diffserv MPLS-TE est un
sujet dtudes qui deviendra ncessaire pour la gnralisation de lutilisation de MPLSTE dans RENATER.
De plus, lutilisation de tunnels-TE en inter domaine est aujourdhui un sujet de
recherche actif, notamment avec BGP-TE [6], ce valide le choix de cette technologie pour
une utilisation plus intense dans les rseaux doprateurs.

87

Rsultats et discussion
Dautres solutions et protocoles qui permettent dobtenir des rsultats similaires sont
galement ltude, comme les Software Defined Network dont OpenFlow [7] est un
exemple prometteur et soutenu par de nombreux acteurs de linformatique (IBM,
Google, etc.).
Comme pour MPLS-TE en mode dcentralis, OpenFlow dporte la partie routage dans
une intelligence centrale, appele Network OS , laissant seulement le rle de
commutation aux quipements rseaux. On pourra trouver un exemple dutilisation par
Google : http ://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/

6.4 Bilan personnel

at
io

Durant ces 9 mois, jai eu lopportunit de travailler sur diffrents aspects de la gestion
de projet. La rdaction de ltude des besoins, ltude de faisabilit, la validation de la

lu

solution choisie et la coordination du dploiement de tunnels MPLS-TE.

bien dun point de vue

Ev
a

Le travail ralis sest avr trs enrichissant pour mon exprience professionnelle, aussi
thorique et technique, quhumain. Travailler avec les

diffrentes entits de RENATER, son NOC et Cisco ma permis dapprhender le rle de

PD
F

chacun dans la mise en uvre et la gestion dune architecture rseau doprateur.


La phase prliminaire dtude thorique a fait appel et a enrichi mes mthodes de

rt

recherche et mes connaissances acquises lors de ma formation dingnieur au CNAM.

pe

Ltude de faisabilit et la validation de la solution technique lors du CPOC ont

Ex

grandement amlior mes comptences techniques sur les protocoles et quipements


rseaux de type oprateur, mais galement ma pratique et rdaction de lAnglais
technique. Jai galement anim et pilot lquipe dingnierie durant la semaine de
tests CPOC.
Enfin, la phase de dploiement a ncessit de travailler suivant les procdures internes
RENATER : rdaction des documents dexploitation, plan de dploiement, formation des
diffrentes quipes la gestion et lusage de ces nouveaux protocoles. Cette partie ma
permis de comprendre le travail dun ingnieur dtudes et projets dans une entit
comme RENATER.

88

7 Appendices
7.1 Table des illustrations

Ex

pe

rt

PD
F

Ev
a

lu

at
io

Figure 1 - Distribution des donnes LHC dans le schma "Monarch" ................................. 1


Figure 2 - Architecture rseau de RENATER ........................................................................ 4
Figure 3 - Architecture de RENATER en Ile de France.......................................................... 5
Figure 4 - Organismes membres de RENATER ..................................................................... 5
Figure 5 - Organigramme interne de RENATER ................................................................... 6
Figure 6 - Routage par contraintes MPLS-TE ....................................................................... 9
Figure 7 - Exemple de topologie TE stratgique : topologie physique .............................. 11
Figure 8 - Exemple de topologie TE stratgique : topologie logique................................. 11
Figure 9 - Tunnels TE tactique : Exemple de rpartition entre les routeurs A et C ........... 12
Figure 10 - Complexit du contrle des architectures MPLS-TE ....................................... 12
Figure 11 Algorithme de slection du chemin dynamique CSPF en trois phases. .......... 17
Figure 12 Exemple dtablissement de LSP-TE par RSVP-TE .......................................... 21
Figure 13 LHCOPN, changes hirarchiques des donnes avec les T2. .......................... 25
Figure 14 LHCONE, changes distribus des donnes entre les T2. ............................... 25
Figure 15 Infrastructure RENATER ddie LHCONE France. ...................................... 26
Figure 16 Tiers 1, 2 et 3 du rseau LHCONE sur RENATER ............................................. 27
Figure 17 - Exemple de L2VPN-PW orient par de lingnierie de trafic .......................... 28
Figure 18 Topologie mtropolitaine de RENATER .......................................................... 30
Figure 19 Les diffrents types de L2VPN-PW dans RENATER ......................................... 33
Figure 20 L2VPN-PW dans une architecture MPLS ......................................................... 34
Figure 21 Encapsulation dune trame Ethernet tague 802.1Q ..................................... 34
Figure 22 L3VPN sur VRF VERTE - Peering eBGP et iBGP sur Route Reflector.......... 35
Figure 23 Architecture de test mise en place via Dynamips/GNS3 ................................ 38
Figure 24 Tunnel MPLS-TE chemin explicite ................................................................ 41
Figure 25 Exemple de protection globale dun tunnel MPLS-TE .................................... 53
Figure 26 Tunnel de protection Next Hop ................................................................ 56
Figure 27 Tunnel de protection Next Next Hop ........................................................ 56
Figure 28 Exemple de protection FRR dun tunnel MPLS-TE .......................................... 57
Figure 29 L2VPN Pseudo-Wire dirig dans un tunnel MPLS-TE ...................................... 62
Figure 30 Utilisation de tunnels TE avec des L3VPN MPLS ............................................. 63
Figure 31 Architecture cible sites Tiers 2 / FR LHCONE .................................................. 66
Figure 32 Liaison primaire RENATER / GEANT sature ................................................... 68
Figure 33 Liaison de secours RENATER/GEANT utilise provisoirement ........................ 68
Figure 34 Liaison Lyon1 Genve, dj utilise par le LHCONE..................................... 68
Figure 35 Liaison Grenoble Genve inutilise.............................................................. 68
Figure 36 Chemins principaux LHCONE L2VPN TE .......................................................... 69
Figure 37 Proposition de chemins secondaires LHCONE L2VPN TE ............................... 70
Figure 38 Topologie du CPOC RENATER-5 ...................................................................... 74
Figure 39 Protocole de rapport des tests CPOC ............................................................. 75
Figure 40 Topologie de lexemple Etablissement de tunnel TE chemin explicite .. 77
Figure 41 Weathermap dexploitation LHCONE ............................................................. 83
Figure 42 Supervision du L2VPN-TE du site LHCONE de Nantes .................................... 84

89

Appendices

7.2 Rfrences
RFC
IS-IS
MPLS
LDP
L3VPN MPLS
CR-LDP
MPLS-TE
IS-IS-TE
OSPF-TE
RSVP-TE

[RFC1195]
[RFC3031]
[RFC5036]
[RFC2547]
[RFC3468] en status informationnal
[RFC2702]
[RFC5305]
[RFC3630]
[RFC3209]

[4]
[5]

at
io

lu

rt

[6]
[7]

Ev
a

[2]
[3]

https ://indico.cern.ch/getFile.py/access ?contribId=1&resId=1&materialId=slide


s&confId=151862
Jean-Louis Mlin, 2001. Qualit de service sur IP, Eyrolles.
J.M. Bonnin, ENST, 2003. MPLS, techniques de lingnieur, 18p.
Christophe
Fillot,
2001.
Implmentation
Mpls
avec
Cisco.
http://www.frameip.com/mpls-cisco/
J.L. Le Roux, France Tlcom R&D. MPLS : applications lingnierie de trafic et
la scurisation, techniques de lingnieur, 23p.
Frdric JOUNAY, Orange Labs. VPWS (Virtual Private Wire Service), Technologie
Pseudowire ou circuit virtuel, techniques de lingnieur, 24p.
http ://tools.ietf.org/html/draft-gredler-bgp-te-01
http ://www.openflow.org/

PD
F

[1]

Bibliographie

pe

Documentation Cisco

http ://www.cisco.com/en/US/docs/ios/12_0s/fea
ture/guide/TE_1208S.pdf
http ://www.cisco.com/en/US/docs/ios/12_2t/12_
2t4/feature/guide/ftbwadjm.pdf
http ://www.cisco.com/en/US/docs/ios/12_2s/fea
ture/guide/fsmetric.pdf
Protection locale FRR des tunnels TE avec http://www.cisco.com/en/US/docs/ios/mpls/confi
BFD.
guration/guide/mp_link_node_prot.pdf
Protection globale des tunnels TE.
http ://www.cisco.com/en/US/docs/ios/mpls/confi
guration/guide/mp_te_path_prot.pdf
Annonce des tunnels TE lensemble des http://www.cisco.com/en/US/docs/ios/mpls/confi
routeurs de lIGP.
guration/guide/mp_te_fwd_adjacency.pdf
Tunnels TE, primaire ou de secours http ://www.cisco.com/en/US/docs/ios/12_0s/fea
automatiques.
ture/guide/gsmeshgr.pdf
Diffserv Aware TE
http://www.cisco.com/en/US/docs/ios/12_2s/feat
ure/guide/fsdserv3.pdf

Ex

Tunnels TE chemin explicite et


dynamique.
Bande passante automatique des tunnels
TE.
Mtriques TE/IGP des tunnels MPLS-TE.

90

8 Annexes
8.1 Etude de mtrologie RENATER
Voir document ci-aprs.

8.2 CPOC RENATER-5 TE


Voir document ci-aprs.

8.3 Supervision du tunnel MPLS-TE de test sur RENATER


Les figures ci-dessous sont les rsultats de ltape T2 du dploiement des tunnels MPLS-

TE sur RENATER 5.4.

at
io

Sur la premire, on observe que le tunnel de test est oprationnel sur RENATER, et quil

PD
F

Ev
a

lu

est possible dy injecter du trafic.

Sur la seconde, on observe les performances matrielles du routeur de tte du tunnel

rt

TE. Le dploiement a eu lieu en semaine 21, les courbes dutilisation des ressources

Ex

pe

matrielles du routeur sont stables, il ny a pas eu deffet de bord.

91

Annexes

Ex

pe

rt

PD
F

Ev
a

lu

at
io

8.4 Base dexploitation des tunnels TE

92

Paramtres des Tunnels MPLS Traffic Engineering


type de
chemin

id tunnel

metrique
suivie

Priorit
tablissement

Priorit
maintient

Affinit

Masque

Annonce IGP

Partage de charge
(groupe)

Protection

Partage de charge
(poids)

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23122

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

13123

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23123

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

13125

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23125

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

13126

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23126

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

13127

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23127

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

13128

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

23128

Explicite

TE

0x0

0xffff

Aucune

Aucune

Aucun

at
io

13122

lu

8.5 Etat du rseau aprs le dploiement de MPLS-TE

Ev
a

=====================================================================================
SHOW ISIS-TE
=====================================================================================

Ex

pe

rt

PD
F

nantes-rtr-021# sh mpls traffic-eng topology brief | i ^IGP Id:


IGP Id: 0000.0000.0001.00, MPLS-TE Id:193.51.178.10 Router Node (isis level-1)
IGP Id: 0000.0000.0002.00, MPLS-TE Id:193.51.178.2 Router Node (isis level-1)
IGP Id: 0000.0000.0003.00, MPLS-TE Id:193.51.178.12 Router Node (isis level-1)
IGP Id: 0000.0000.0039.00, MPLS-TE Id:193.51.178.39 Router Node (isis level-1)
IGP Id: 0000.0000.0051.00, MPLS-TE Id:193.51.178.51 Router Node (isis level-1)
IGP Id: 0000.0000.0052.00, MPLS-TE Id:193.51.178.52 Router Node (isis level-1)
IGP Id: 0000.0000.0056.00, MPLS-TE Id:193.51.178.56 Router Node (isis level-1)
IGP Id: 0000.0000.0180.00, MPLS-TE Id:193.51.178.180 Router Node (isis level-1)
IGP Id: 0000.0000.0183.00, MPLS-TE Id:193.51.178.183 Router Node (isis level-1)
IGP Id: 0000.0000.0184.00, MPLS-TE Id:193.51.178.184 Router Node (isis level-1)
IGP Id: 0000.0000.0185.00, MPLS-TE Id:193.51.178.185 Router Node (isis level-1)
IGP Id: 0000.0000.0186.00, MPLS-TE Id:193.51.178.186 Router Node (isis level-1)
IGP Id: 0000.0000.0188.00, MPLS-TE Id:193.51.178.188 Router Node (isis level-1)
IGP Id: 0000.0000.0189.00, MPLS-TE Id:193.51.178.189 Router Node (isis level-1)
IGP Id: 0000.0000.0190.00, MPLS-TE Id:193.51.178.190 Router Node (isis level-1)
IGP Id: 0000.0000.0198.00, MPLS-TE Id:193.51.178.198 Router Node (isis level-1)
IGP Id: 0000.0000.0199.00, MPLS-TE Id:193.51.178.199 Router Node (isis level-1)
IGP Id: 0000.0000.0138.00, MPLS-TE Id:193.51.178.138 Router Node (isis level-1)
IGP Id: 0000.0000.0145.00, MPLS-TE Id:193.51.178.145 Router Node (isis level-1)
IGP Id: 0000.0000.0171.00, MPLS-TE Id:193.51.178.171 Router Node (isis level-1)
IGP Id: 0000.0000.0172.00, MPLS-TE Id:193.51.178.172 Router Node (isis level-1)
IGP Id: 0000.0000.0173.00, MPLS-TE Id:193.51.178.173 Router Node (isis level-1)
IGP Id: 0000.0000.0174.00, MPLS-TE Id:193.51.178.174 Router Node (isis level-1)
IGP Id: 0000.0000.0175.00, MPLS-TE Id:193.51.178.175 Router Node (isis level-1)
IGP Id: 0000.0000.0176.00, MPLS-TE Id:193.51.178.176 Router Node (isis level-1)
IGP Id: 0000.0000.0178.00, MPLS-TE Id:193.51.178.178 Router Node (isis level-1)
IGP Id: 0000.0000.0179.00, MPLS-TE Id:193.51.178.179 Router Node (isis level-1)
IGP Id: 0000.0000.0200.00, MPLS-TE Id:193.51.178.200 Router Node (isis level-1)
nantes-rtr-021#show mpls traffic-eng link-management igp-neighbors
"te1-2-bordeaux-rtr-021.noc.renater.fr"
Link ID:: Te1/1
Neighbor ID: 0000.0000.0171.00 (area: isis level-1, IP: 193.51.189.73)
up, Sources: IGP
"te1-2-rennes-rtr-021.noc.renater.fr"
Link ID:: Te1/2
Neighbor ID: 0000.0000.0188.00 (area: isis

level-1, IP: 193.51.189.57)

93

Annexes
up, Sources: IGP
"Aucun voisin ISIS-TE pour l'instant"
Link ID:: Te1/5
"te1-3-vannes-rtr-021.noc.renater.fr."
Link ID:: Te2/1
Neighbor ID: 0000.0000.0045.00 (area: isis
up, Sources: IGP

level-1, IP: 193.51.179.149)

flow max
7500M
7500M
7500M
7500M
7500M

sub max
0
0
0
0
0

Ev
a

lu

nantes-rtr-021#sh ip rsvp neighbor


Neighbor
Encapsulation Time since msg rcvd/sent
193.51.189.57
Raw IP
00:00:01
00:00:06
193.51.189.73
Raw IP
00:00:10
00:00:08

at
io

nantes-rtr-021#sh ip rsvp interface


interface
rsvp
allocated i/f max
Te1/1
ena
0
7500M
Te1/2
ena
0
7500M
Te1/5
ena
0
7500M
Te2/1
ena
0
7500M
Te2/2
ena
0
7500M

=====================================================================================
SHOW RSVP-Te
=====================================================================================
nantes-rtr-021#sh ip rsvp
RSVP: enabled (on 6 interface(s))
MPLS/TE signalling enabled

=====================================================================================
CONF PW et tunnnels
=====================================================================================

PD
F

pseudowire-class PW-NANTES-R021=>PARIS1-R021
encapsulation mpls
preferred-path interface Tunnel13122 disable-fallback
!
pseudowire-class PW-NANTES-R021=>LYON1-R021
encapsulation mpls
preferred-path interface Tunnel13123 disable-fallback
!

Ex

pe

rt

interface TenGigabitEthernet1/3.3122
description -s-- IN2P3-SUBATECH-NANTES / VPN-VPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1RTR-021 ---encapsulation dot1Q 3122
no cdp enable
xconnect 193.51.178.185 3122 pw-class PW-NANTES-R021=>PARIS1-R021
mtu 9180
!
interface TenGigabitEthernet1/3.3123
description -s-- IN2P3-SUBATECH-NANTES/ VPN-VPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR021 ---encapsulation dot1Q 3123
no cdp enable
xconnect 193.51.178.178 3123 pw-class PW-NANTES-R021=>LYON1-R021
mtu 9180
!
interface Tunnel13122
description -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 / LHCONE PW-3122 ---ip unnumbered Loopback2
tunnel mode mpls traffic-eng
tunnel destination 193.51.178.185
tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>PARIS1-RTR-021PRIMARY
!
interface Tunnel13123
description -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 / LHCONE PW-3123 ----

94

ip unnumbered Loopback2
tunnel mode mpls traffic-eng
tunnel destination 193.51.178.178
tunnel mpls traffic-eng path-option 10 explicit name EP-NANTES-RTR-021=>LYON1-RTR-021PRIMARY
!

=====================================================================================
SHOW PW et tunnels
=====================================================================================

at
io

nantes-rtr-021#sh int description


Interface
Status
Protocol Description
Te1/3.3122
up
up
-s-- IN2P3-SUBATECH-NANTES / VPNVPWS-TE13122-LHCONE-NANTES-RTR-021-PARIS1-RTR-021 ---Te1/3.3123
up
up
-s-- IN2P3-SUBATECH-NANTES/ VPNVPWS-TE13123-LHCONE-NANTES-RTR-021-LYON1-RTR-021 ---[...]
Tu13122
up
up
-TE- 13122-NANTES-RTR-021=>PARIS1RTR-021 / LHCONE PW-3122 ---Tu13123
up
up
-TE- 13123-NANTES-RTR-021=>LYON1RTR-021 / LHCONE PW-3123 ----

Ev
a

lu

nantes-rtr-021#sh mpls traffic-eng tunnels brief


Signalling Summary:
LSP Tunnels Process:
running
Passive LSP Listener:
running
RSVP Process:
running
Forwarding:
enabled
Periodic reoptimization:
every 3600 seconds, next in 2014 seconds
Periodic FRR Promotion:
Not Running
Periodic auto-bw collection:
every 300 seconds, next in 215 seconds
STATE/PROT
up/up
up/up
up/up
up/up

rt

PD
F

P2P TUNNELS/LSPs:
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
-TE- 13122-NANTES-RTR-021=>P... 193.51.178.185
Te1/2
-TE- 13123-NANTES-RTR-021=>L... 193.51.178.178
Te1/1
-TE- 23123-LYON1-RTR-021=>NA... 193.51.178.183
Te1/1
-TE- 23122-PARIS1-RTR-021=>N... 193.51.178.183
Te1/2
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 2 (of 2) tails

pe

=====================================================================================
nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122

Ex

Name: -TE- 13122-NANTES-RTR-021=>PARIS... (Tunnel13122) Destination: 193.51.178.185


Status:
Admin: up
Oper: up
Path: valid
Signalling: connected
path option 10, type explicit EP-NANTES-RTR-021=>PARIS1-RTR-021-PRIMARY (Basis for
Setup, path weight 83)
Config Parameters:
Bandwidth: 0
kbps (Global) Priority: 7 7
Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 0
bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : OutLabel : TenGigabitEthernet1/2, 332
Next Hop : 193.51.189.57
RSVP Signalling Info:
Src 193.51.178.183, Dst 193.51.178.185, Tun_Id 13122, Tun_Instance 146
RSVP Path Info:

95

Annexes
My Address: 193.51.189.58
Explicit Route: 193.51.189.57 193.51.189.54 193.51.189.46 193.51.189.49
193.51.189.38 193.51.178.185
Record
Route:
NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record
Route:
NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 83 (TE)
Explicit Route: 193.51.189.57 193.51.189.54 193.51.189.46 193.51.189.49
193.51.189.38 193.51.178.185
History:
Tunnel:
Time since created: 2 days, 20 hours, 52 minutes
Time since path change: 1 days, 1 hours, 2 minutes
Number of LSP IDs (Tun_Instances) used: 146
Current LSP: [ID: 146]
Uptime: 1 days, 1 hours, 2 minutes
Prior LSP: [ID: 124]
ID: path option unknown
Removal Trigger: path verification failed

at
io

=====================================================================================

Ev
a

lu

nantes-rtr-021#sh mpls l2transport vc 3122 detail


Local interface: Te1/3.3122 up, line protocol up, Eth VLAN 3122 up
Interworking type is Ethernet
Destination address: 193.51.178.185, VC ID: 3122, VC status: up
Output interface: Tu13122, imposed label stack {332 446}
Preferred path: Tunnel13122, active
Default path: disabled
Next hop: point2point

=====================================================================================

Ex

pe

rt

PD
F

nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13122 accounting


Tunnel13122 (Destination 193.51.178.185; Name -TE- 13122-NANTES-RTR-021=>PARIS1-RTR-021 /
LHCONE PW-3122 ----)
5 minute output rate 804391 kbits/sec, 77378 packets/sec
nantes-rtr-021#sh mpls traffic-eng tunnels tunnel 13123 accounting
Tunnel13123 (Destination 193.51.178.178; Name -TE- 13123-NANTES-RTR-021=>LYON1-RTR-021 /
LHCONE PW-3123 ----)
5 minute output rate 0 kbits/sec, 0 packets/sec

96

rt

pe

Ex
PD
F

at
io

lu

Ev
a

Annexes
tude, conception et dploiement des technologies dingnierie de trafic sur linfrastructure de
production MPLS de RENATER. Mmoire dingnieur EICNAM, Paris 2013, Nicolas GARNIER.

Rsum
Les expriences menes par le CERN sur le LHC sont gnratrices dune grande quantit de donnes,
qui sont distribues des centres de calculs via les rseaux LHCOPN et LHCONE. RENATER, qui a la
charge de ces rseaux en France, souhaite rpondre la forte demande en bande passante sans
augmenter court terme la capacit de ses liens. Pour cela, il a t choisi dutiliser des mcanismes
dingnierie de trafic.

at
io

chemins choisis, des connexions VPN entre les centres de calcul et le LHCONE.

Lobjectif de cette tude est de dfinir et dployer les moyens ncessaires lorientation, vers des

MPLS-TE sest rvl tre le mcanisme unanimement utilis et propos sur le march. Aprs avoir
dfini son utilisation dans larchitecture cible, nous lavons test et valid sur une maquette virtuelle,

Ev
a

lu

puis en situation relle chez lquipementier Cisco, avant de le mettre en production.


Ce dploiement a permis dutiliser les liaisons sous-exploites du rseau RENATER et douvrir de
nouvelles possibilits en termes de planification de linfrastructure.

PD
F

Abstract

Experiments by CERN on the LHC are generating a large amount of data, which are distributed to
data centers via networks LHCOPN and LHCONE. RENATER is in charge of these networks in France. In

rt

order to meet the high demand for bandwidth without increasing, in the short term, capacity of its

pe

links, RENATER chose to use mechanisms of traffic engineering.

Ex

The objective of this study is to define and deploy the necessary resources and protocols to guide,
into chosen paths, VPN connections between data centers and LHCONE.
MPLS-TE mechanism turned out to be unanimously used and available on the market. After having
defined its use in the target architecture, we have tested and validated it on a virtual model, then in a
real context in Cisco equipment manufacturer facilities, before putting it into production.
This project enabled to use RENATER network underused links and opened up new possibilities in
terms of infrastructure planning.
Mots cls / Keywords : Ingnierie de trafic / Traffic Engineering, MPLS-TE, IS-IS-TE, RSVP-TE.

Vous aimerez peut-être aussi