Memoire IRSM Nicolas Garnier

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.

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

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

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

( 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)
(5)
(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)
(9)
(10)

Ltablissement du LSP-TE est alors finalis.
21
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
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
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

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

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
Hop 2: 10.0.38.2
Hop 3: 10.0.38.1
Hop 4: 10.0.23.2
Hop 5: 10.0.23.1
Hop 6: 10.2.0.1
o Query Parameters : paramtres demands.
Ex
o Query Results : Chemins rsultants qui rpondent aux contraintes.
43
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
load-interval 30
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

Name: P4_t2
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
bw-based
auto-bw: disabled
State: dynamic path option 1 is active
[]
RSVP Path Info:
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:
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
Hop 2: 10.0.58.2
Hop 3: 10.0.58.1
Hop 4: 10.0.15.2
Hop 5: 10.0.15.1
Hop 6: 10.0.12.1
Hop 7: 10.0.12.2
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

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

Name: P4_t1
Status:
Admin: up
Oper: up
Path: valid
Config Parameters:
Bandwidth: 0
bw-based
auto-bw: (300/248) 0 Bandwidth Requested: 979
Samples Missed 0: Samples Collected 0
InLabel : OutLabel : GigabitEthernet2/0, 34
RSVP Path Info:
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
RSVP Resv Info:
Record
Route:
NONE
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

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
at
io
lu
Ev
a
interface Tunnel 3
interface Tunnel2
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

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.

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/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

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
53
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

Name: P4_t1
Status:
Admin: up
Oper: up
Path: valid
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

Name: P4_t1
Status:
Admin: up
Oper: up
Path: valid
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_t1
LSP Head, Tunnel1, Admin: up, Oper: up
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

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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

(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
tunnel destination 10.3.0.1 | 10.2.0.1
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
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_t1
LSP Head, Tunnel1, Admin: up, Oper: up
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
FRR intf/label
LSP midpoint frr information:

LSP identifier
FRR intf/label
10.4.0.1 1 [14]
34
Gi2/0:33
active
Status
Status
Tu100:33
59

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 :
Name: P4_t1
Status:
Admin: up
Oper: up
Path: valid
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

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

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
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
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
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
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
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
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
!
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
!
explicit-path name 12000-8CRS-2
!
description TUNNEL TE108112000-87600-1
load-interval 30
path-option 10 explicit name 12000-87600-1
!
description TUNNEL TE108212000-8CRS-2
load-interval 30
path-option 10 explicit name 12000-8CRS-2
!
Ex
pe
rt
PD
F
! Pour 7600-1
!
load-interval 30
tunnel mpls traffic-eng path-option 10 explicit name 7600-112000-8
!
load-interval 30
!
ip explicit-path name 7600-112000-8 enable
index 10 next-address 10.3.2.1
!
!
! Pour 6500-4
!
load-interval 30
78

!
!
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
path option 10, type explicit 7600-1-12000-8 (Basis for Setup, path weight
25)
Ev
a
lu
Config Parameters:
Bandwidth: 100
Metric Type: TE (default)
AutoRoute announce: disabled LockDown: disabled Loadshare: 100
bw-based
auto-bw: disabled
Ex
pe
rt
PD
F
InLabel : OutLabel : TenGigabitEthernet1/4, 16037

Next Hop : 10.0.12.2
RSVP Path Info:
Explicit Route: 10.0.12.2 10.0.23.2 10.0.38.2 10.3.8.1
Record
Route:
NONE
RSVP Resv Info:
Record
Route:
NONE
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
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
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
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
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
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
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
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)
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 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
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:
Periodic FRR Promotion:
Not Running
Periodic auto-bw collection:
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
path option 10, type explicit EP-NANTES-RTR-021=>PARIS1-RTR-021-PRIMARY (Basis for
Setup, path weight 83)
Config Parameters:
Bandwidth: 0
AutoRoute announce: disabled LockDown: disabled Loadshare: 0
bw-based
auto-bw: disabled
InLabel : OutLabel : TenGigabitEthernet1/2, 332
Next Hop : 193.51.189.57
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
RSVP Resv Info:
Record
Route:
NONE
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
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.

Langue

Memoire IRSM Nicolas Garnier

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Memoire IRSM Nicolas Garnier

Transféré par

Description :

Droits d'auteur :

Formats disponibles

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

le DIPLOME dINGENIEUR CNAM

Prsent en vue dobtenir

OPTION : Rseaux, Systmes et Multimdia

Encadr par Xavier JEANNIN - RENATER

tude, conception et dploiement des technologies dingnierie

de trafic sur linfrastructure de production MPLS de RENATER

Soutenu le 26 fvrier 2013

Jean Pierre Arnaud

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

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

exprience pour un futur ingnieur rseaux.

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

enseignements des rseaux, vivant et de qualit.

Autonomous System : ensemble de rseaux informatiques IP

Label Distribution Protocol : Protocole standardis pour l'change

Table des matires

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ces dernires devront permettre :

De choisir un chemin utiliser.

Doptimiser lutilisation de linfrastructure rseau de RENATER, et donc

de retarder de couteux investissements.

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

seulement celui de ses extensions pour lingnierie de trafic.

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

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

aussi prsent dans les dpartements et territoires dOutre-Mer.

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

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

Deux catgories de circuits sont disponibles :

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.