Optimisation Des Architectures IPMPLS de Treansport Mutualisé

UFR ESSTIN
cole Doctorale IAEM Lorraine

DFD Automatique
Thse
prsente pour lobtention du
Doctorat de lUniversit Henri Poincar, Nancy 1
par
olivier ferveur
Optimisation des architectures
IP/MPLS de transport mutualis
Composition du jury
Rapporteurs : Pr. Didier Georges, INP Grenoble
Pr. Zoubir Mammeri, IRIT
Examinateurs : Pr. Hugues Mounier, IEF
Mr. Ren Kopp, tuteur en entreprise, TDF
Pr. Francis Lepage, directeur de thse, CRAN
Mr. Eric Gnaedinger, MCF, encadrant de thse, CRAN
Pr. Gilles Millerioux, CRAN
Thse effectue en partenariat avec :
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Olivier Ferveur : Optimisation des architectures IP/MPLS de transport
mutualis, November 2009
supervisors :
Francis Lepage
Eric Gnaedinger
Ren Kopp
location :
Nancy
time frame :
November 2009
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
ABSTRACT
The IP technology was classicly used only in Internets context.
But since few years ago, this standard was re-use for new need like
telephony and TV broadcast. This multi-use has as a consequence to
screate a need of mutualised the core network. Today, the functionality
provided by MPLS allow virtualisalisation of network infrastructure on
a single IP core, leading to more complex resource management. In this
thesis, we study the possibility of current management of the shared
network and we propose the addition of a management mechanism
called TDCN. We will demonstrate the many possibilities offered by
this new system to provide an optimized core network use.
RSUM
La technologie IP autrefois utilise uniquement dans le cadre dIn-
ternet est de nos jours le support de nombreuses autres applications
d-corrles telle que la tlphonie ou encore la tlvision. Cette multi-
utilisation du standard a entran une volont de mutualisation au
sein du coeur de rseau. Aujourdhui, les fonctionnalits apportes
par MPLS permettent une virtualisalisation des infrastructures de r-
seau IP sur un unique coeur , entranant une complexication de la
gestion de la ressource. Dans cette thse, nous tudierons les possibili-
ts actuelles de gestion de ce rseau mutualis et nous proposerons
ladjonction dun mcanisme de gestion appel TDCN. Nous dmon-
trerons les nombreuses possibilits offertes par ce nouveau systme
pour ainsi optimiser lutilisation du rseau.
iii
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
La facult de citer est un substitut commode lintelligence
Sommerset Maugham
REMERCI EMENTS
Tous dabord, je remercie tout particulirement Eric Gnaedinger qui
ma incit raliser cette thse et pour avoir encadr mon travail ds
le D.E.A et mavoir soutenu pendant toutes ces annes.
Je tiens ensuite remercier Ren Kopp, responsable du service ARC
pour mavoir propos ce sujet dans le cadre dune collaboration entre
le CRAN et TDF. Je lui suis redevable de mavoir accueilli dans son
quipe o jai pu travailler sur cette thse et sur bien dautres sujets
passionnants.
Je remercie galement pour ses conseils aviss le Professeur Francis
Lepage qui ma fait lhonneur dtre mon directeur de thse. Je conser-
verai dexcellents souvenirs de notre prsentation au comit dexpert
rseaux du CNRS.
Je suis galement trs reconnaissant mon collgue Sbastien Lour-
dez pour son travail de relecture et plus gnralement lensemble de
lquipe TDF de Metz qui ma support tout au long de ces annes.
Je remercie particulirement le Professeur Gilles Millerioux pour ses
suggestions dtudes dans le domaine les diagrammes de phases sans
lesquelles je naurais pu aboutir.
Je suis trs reconnaissant aux Professeurs Didier Georges et Zoubir
Mammeri pour avoir accept dtre les rapporteurs de mes travaux
ainsi quau Professeur Hugues Mounier pour sa participation au jury
en qualit dexaminateur.
Merci enn toute ma famille, en particulier Caroline, de mavoir
support et aid.
v
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
TABLE DES MATI RES
1 prface 1
2 introduction 7
i le contexte de ltude 9
3 prsentation du projet tms 11
3.1 Descriptif gnral 11
3.2 Objectifs 11
3.3 Une architecture Nationale 12
3.4 Larchitecture protocolaire 12
3.4.1 La technologie MPLS dans TMS 13
3.5 Les services TMS 14
3.5.1 La diffusion de la TNT vers les metteurs 15
3.5.2 Le transport scuris de multiplex audio-visuel 15
3.5.3 Le transport dagrgats de trac Wimax 15
3.5.4 Linterconnexion mtier 15
3.6 Les problmatiques de TMS 16
4 le transport mutualis 19
4.1 Les oprateurs de Wholesale 19
4.2 Exemple doprateur de wholesale : COLT 20
4.3 Hypothses et bornes de ltude 21
ii etude de lexistant 23
5 provisioning rseaux 25
5.1 Principe Gnral 25
5.2 La matrice de trac 26
5.3 Optimisation des routes 26
5.4 Apport de MPLS dans loptimisation 26
5.5 Admission Control 27
5.6 Notion de rsilience 27
5.7 Rserve sur le provisioning 28
6 evolutions des systmes de rgulation 29
6.1 Les mcanismes de la rgulation de trac 29
6.2 Lapproche Systme Service Allocation 30
6.3 Lapproche Systme ECN 31
6.4 eXplicit Control Protocol (XCP) 32
6.5 Evaluation dans le cadre des rseaux de transport mu-
tualis 33
vii
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
iii proposition de nouvelles approches 35
7 considrations sur le nouveau systme 37
7.1 La base du rseau de transport mutualis : le service
37
7.2 Une approche diffrenciant les tunnels 37
8 formalisation du systme tdcn-ecn 39
8.1 Dtection de la congestion 39
8.2 Transport de linformation de la congestion sur les tun-
nels 40
8.3 Fonctionnement des rgulateurs daccs DAR 41
8.4 Respect du critre dquit 42
8.5 Critre de stabilit du systme 43
8.6 Dtection de bande libre optimise 44
8.7 Rsum du systme 45
iv etude thorique des performances du systme tdcn
47
9 modlisation du systme tdcn 49
9.1 Le rgulateur fractionnel 49
9.1.1 Evolution du rgulateur en congestion 49
9.1.2 Evolution du rgulateur en non-congestion 50
9.2 Mise en quations 52
9.2.1 Modlisation dun DAR 52
9.3 Etude dun systme DAR fractionnel 54
9.3.1 Etude de la priode de congestion 55
9.3.2 Etude de la priode dquilibrage 56
9.3.3 Etude de la priode dquit 57
9.4 Etude dune application base sur le TDCN 58
9.4.1 Lapproche par mtaux prcieux 58
9.4.2 La conguration du systme TDCN 59
9.5 Conclusion du chapitre 60
10 etude par diagramme de phase de liaison tdcn en
congestion 63
10.1 Etude dun systme simple deux rgulateurs 63
10.1.1 Dnition du systme 63
10.1.2 Diagramme de phase 63
10.1.3 Test dindpendance aux conditions initiales 64
10.2 Gnralisation aux systmes N rgulateurs 65
10.2.1 Cas du systme 3 rgulateurs 65
10.2.2 Observation sur les systmes de dimension sup-
rieure 66
viii
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
10.3 Analyse de liaison sur les Systmes TDCN 68
10.3.1 Etude des effets des paramtres A et B 68
10.3.2 Effet du nombre de rgulateurs 69
10.3.3 Etude de la dispersion des CLAs 71
v etude exprimentale du systme tdcn 73
11 prsentation de la plate-forme de tests 75
11.1 La plate-forme de tests 75
11.2 Cration de lenvironnement de tests 76
11.2.1 le gnrateur dagrgats 76
11.2.2 Lmulateur WAN 77
11.3 Implmentation du systme TDCN 77
11.3.1 Les routeurs 77
11.3.2 Description de larchitecture VPN 78
11.3.3 Lemulateur TDCN 79
11.3.4 Dfaut de lexternalisation du code 80
11.4 Mtrologie de la plate-forme de tests 81
11.4.1 Mtrique du routeur 81
11.4.2 Le gnrateur de dbit 82
12 testbed du systme tdcn 85
12.1 Comparaison entre les rsultats de la maquette et de la
modlisation 85
12.2 tude des ux 86
12.2.1 Fonctionnement en rgime tabli 86
12.2.2 Etude en phase dquilibrage 88
12.3 tude des performances globales 90
12.3.1 Evaluation des performances par client 90
12.3.2 Mesures des performances globales du systme 92
12.4 Etude de la qualit de service 93
12.4.1 tude de lvolution des buffers 94
12.4.2 Effet du systme sur les tracs UDP 95
vi conclusion 99
13 conclusion 101
vii annexe 103
a annexe 105
a.1 Code Scilab de la modlisation TDCN 106
ix
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
bibliographie 115
x
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
TABLE DES FI GURES
Figure 1 Rpartition du chiffre daffaire 2005 par activit 3
Figure 2 Principe du rseau TMS 12
Figure 3 Exemple de trac de diffusion Vido 14
Figure 4 Exemple de ux Internet Agrger 16
Figure 5 Exemple de transport sporadique 17
Figure 6 Positionnement dun rseau de wholesale 19
Figure 7 Rseau europen de la socit COLT 20
Figure 8 Principe du trac engineering 25
Figure 9 Principe du Systme Service Allocation 30
Figure 10 Principe du systme ECN 32
Figure 11 Principe de lapproche XCP 33
Figure 12 Mise en commun des buffeurs de sortie des routeurs de
coeur 40
Figure 13 Algorithme du rgulateur 41
Figure 14 Principe du TDCN 45
Figure 15 Valeur du dcrement (A :15b/s) 50
Figure 16 Evolution au cours du temps de la CLA en congestion(A=100) 51
Figure 17 Valeur de lincrment (A :15b/s) 51
Figure 18 Evolution au cours du temps du CLA en non-congestion
(B=400) 52
Figure 19 Systme simple base de DAR fractionnels 55
Figure 20 Evolution de lincrment dun systme compos de 3 rgu-
lateurs 56
Figure 21 Evolution de la CLA dun systme descente constante(en
% de la HLA) 60
Figure 22 Evolution de la CLA dun systme descente variable(en
% de la HLA) 60
Figure 23 Diagrammes de phases dun systme 2 rgulateurs 64
Figure 24 Diagrammes de phases dun systme 2 rgulateurs
diffrentes condition initial 65
Figure 25 Diagramme de phase de systmes 3 rgulateurs avec
diffrentes conditions initiales 66
Figure 26 Evolution de la distance de convergence dun systme
67
Figure 27 Evolution de la distance fentre dun systme 68
xi
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Figure 28 Evolution du systme en fonction des paramtres A et
B 69
Figure 29 Comparaison de systme quivalent de degr N 70
Figure 30 Effet de la dispersion des CLA 72
Figure 31 Schma du testbed 75
Figure 32 Gnrateur de session NetworkTester 76
Figure 33 Routeur 7450 ESS1 77
Figure 34 Architecture Gnrique dun VPN 78
Figure 35 Variation du temps entre les passes algorithmiques 80
Figure 36 Commande show pool sur un routeur ESS1 81
Figure 37 Evolution dun buffeur egress sur un port en coeur dun
routeur disposant dune liaison congestionne 82
Figure 38 Gnrateur de dbit N2X 83
Figure 39 Comparaison entre les rsultats sur la maquette et dans la
modlisation 85
Figure 40 Evolution du trac client dans un rseau BE et TDCN 87
Figure 41 Evolution du rapport LLA/CLA des rgulateurs dans le
rseau TDCN 88
Figure 42 Evolution du trac client en phase transitoire 89
Figure 43 Evolution du CLA des clients en phase transitoire 89
Figure 44 Exemple de dlai pour rallouer la bande passante 93
Figure 45 Evolution du buffer dun rseau Best-effort en conges-
tion 94
Figure 46 Evolution of buffers in TDCN network 95
Figure 47 Evolution de la latence et des pertes de paquets des ux
UDP dans un rseau TDCN 96
Figure 48 Distribution de la latence pour les ux UDP dans un rseau
TDCN 97
LI STE DES TABLEAUX
Table 1 Performance par client pour 18 tlchargements
successifs 91
Table 2 Performance par client pour 200 tlchargements
successifs 91
xii
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Table 3 Estimation de la performance global du systme 93
ACRONYMS
DRY Dont Repeat Yourself
API Application Programming Interface
UML Unied Modeling Language
TDCN Tunnel Differentiation by Congestion Notication
ECN Explicit Congestion Notication
HLA High Level Autorisation
LLA Low Level Autorisation
CLA Courant Level Autorisation
RIO RED In-prole Out-prole
RED Random Early Detection
MPLS MultiProtocol Label Switching
LDP Label Distribution Protocol
RSVP ReSerVation Protocol
PPVPN Provider Provisioned Virtual Private Networks
SNMP Simple Network Management Protocol
TE Trafc Engineering
VPLS Virtual Private LAN Service
IGP Interior Gateway Protocol
TMS Transport Multi-Services
TNT Tlvision Numrique Terrestre
RTT Round Trip Time
DAR Dynamique Acces Regulator
xiii
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
1
PRFACE
Cette thse a t ralise dans le cadre dun partenariat entre le
centre dtude de TDF situ Metz et le laboratoire du CRAN (Centre
en Automatique de Nancy - UMR 7039), unit mixte de recherche
commune lUniversit Henri Poincar, Nancy 1, lInstitut National
Polytechnique de Lorraine et au CNRS.
le laboratoire du cran
Cette collaboration sinscrit dans la thmatique de recherche Sys-
tmes contrls en rseaux du CRAN, dont le but est de proposer des
modles et des mthodes permettant de concevoir des applications
industrielles distribues sur un rseau de communication.
tdf en bref
Partenaire des tlvisions, radios, oprateurs de tlcommunications
et collectivits locales, TDF est un oprateur et un prestataire de ser-
vices de rfrence dans les domaines de laudiovisuel, de la tlphonie
mobile et du haut dbit.
Tournage vido, diffusion analogique et numrique de la tlvision
et de la radio, dploiement, maintenance et gestion de rseaux de
tlcommunications ; les services de TDF sappuient sur une expertise
reconnue, un parc hertzien de plus de 7 500 sites, une proximit des
quipes et un service client de qualit.
Tourn vers lavenir, le Groupe safrme au plan europen comme
un acteur dynamique de la convergence entre audiovisuel et tl-
communications (DVB-H), mais aussi comme partenaire majeur de
lamnagement numrique des territoires (TNT, WiMAX). Depuis 2002,
TDF est une entreprise certie ISO 9001 version 2000 pour lensemble
de ses services.
1
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
2 prface
le groupe tdf
LEurope est depuis quelques annes la frontire naturelle du Groupe
TDF au travers dun positionnement doprateur historique en
France, Monaco (MCR), en Finlande (Digita) et Estonie (Levira), en
Allemagne (Media Broadcast) et Hongrie (Antena Hungaria), ainsi
quun positionnement de challenger en Espagne (Axion) et en
Pologne (PSN). La dynamique du Groupe sappuie sur le partage
dexprience de chacune des liales au bnce des autres en matire
dexpertise technologique, de savoir-faire mtier, dachats, de forma-
tion ainsi que doffres commerciales. TDF afrme ainsi sa vocation
europenne et reste attentif aux diffrentes opportunits de dvelop-
pement, tout en multipliant ses domaines de comptences, travers
des liales franaises comme :
Cognacq-Jay Image : liale de TDF Vido Service, elle offre aux
diteurs de programmes les prestations techniques de rgies de
diffusion et propose galement une gamme complte de presta-
tions pour la gestion de tous contenus audiovisuels : numrisation,
indexation, archivage et mise en ligne.
Espace Numrique : entreprise dingnierie en rception audio-
visuelle capable dassurer la responsabilit de missions cls en
mains pour le compte de gestionnaires de parcs immobiliers, dans
le domaine de la mise hauteur des antennes collectives de leur
parc pour la rception de la TNT.
Mediamobile : service de production et de diffusion en temps rel
dune information able et pertinente sur ltat du trac routier.
Sofratev : liale ingnierie de TDF, elle exerce dans les domaines
de laudiovisuel (expertise, ingnierie, assistance technique, for-
mation), des radiocommunications (ingnierie de sites, installation
de rseaux radiotlphonie) et du btiment (gnie climatique,
courants faibles).
TV-Radio.com : leader europen de la diffusion audiovisuelle
sur Internet mettant disposition les dernires technologies de
streaming et le savoir-faire de ses quipes pour une solution cls
en main.
Visual 102 : liale de TDF Vido Service, elle est spcialise dans
le tournage en vido mobile et en studios.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
3
Figure 1: Rpartition du chiffre daffaire 2005 par activit
Historique
LHistoire de TDF est riche de plus de 30 ans dexprience et dvolu-
tion, marque de certaines tapes majeures pour son dveloppement :
1975 : Cration de TDF (Tldiffusion de France)
1986 : Loi sur laudiovisuel supprimant le monopole de diffusion
1987 : TDF devient Socit Anonyme
1989 : Entre de Cogecom dans le capital de TDF hauteur de
49%
1990 : Transfert de 51% du capital de TDF France Tlcom
1991 : TDF devient liale 100% de France Tlcom
2000 : Adoption du projet de loi sur laudiovisuel par lAssemble
Nationale
2002 : Naissance du groupe TDF, volution du capital :
CDC, CDC Ixis Capital et Charterhouse : 63%
France Tlcom : 36%
Salaris : 1%
2005 : Nouvelle volution du capital
Charterhouse : 55%
Caisse des Dpts et Consignation : 30%
CDC Entreprises Equity Capital et aflis : 14%
Salaris : 1%
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
4 prface
Chiffres cls
954 millions deuros de chiffre daffaires en 2005 (dont 14%
linternational)
3 850 salaris (dont 2 700 TDF SA)
Plus de 7 500 sites (dont 970 ltranger)
14 000 frquences TV diffuses en France au bnce de 23 millions
de foyers
450 000 heures de programmes TV et radio diffuses par jour
4 200 frquences radio FM diffuses en France
4 500 km dautoroutes couvertes par les programmes FM en France
12 500 points de services tlcoms en France
99,96% de taux de continuit de service pour la tlvision et la
radio
Plus de 600 brevets et logiciels de porte internationale
prsentation du service architecture
Conception de rseau et de loffre technique :
Dnition de larchitecture (topologie, plans oprateurs et ser-
vices rseau, dimensionnement) et de lingnierie protocolaire,
contributions la conception de loffre technique (dnition des
services et SLA), rseau de desserte TMP, rseau TMS, rseau
IP Wimax :
SLA = Service Level Agreement : contrat de qualit de service
TMS, TMP et Wimax sont les dsignations de trois projets du
service
Validation technique (plates-formes dintgration, sites pilotes),
choix des quipements et systmes, ingnierie dtaille, sou-
tien llaboration des outils et mthodes dexploitation et de
tlgestion
Soutien technique et assistance lmergence et la ralisation de
nouvelles offres :
Participation aux groupes de rxions nationaux et internatio-
naux : consortium, forum, instances tatiques, projets europens.
Contributions aux plans daffaires et llaboration des offres
Anticiper :
Instruire les problmatiques techniques avances : handover
DVB-H, gain et supervision SFN, mtrologie DVB-H, DVB/E-
thernet, MPLS/Ethernet, QoS IP :
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
5
SFN = Single Frequency Network, rseau de transmetteur
diffusant la mme frquence sur une zone tendue, pour
parer aux interfrences
DVB = Digital Video Broadcasting, norme de tlvision nu-
mrique
DVB-H = DVB-Handled, norme pour la tlvision numrique
portable
Etablir des cadres de collaboration sur les nouvelles technolo-
gies, veille technologique : projets partenariaux (B21C, Daidalos,
Enthrone,... ), relations industriels et groupes de normalisation
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
2
I NTRODUCTI ON
Avec lacclration de lutilisation dInternet, on assiste une conver-
gence des secteurs de la tlphonie xe, mobile, des donnes et du
monde audiovisuel. Les rseaux supportant ces services sont histori-
quement spars et leurs interactions sont possibles par lintermdiaire
de passerelles centrales. Cependant, une mutualisation de linfrastruc-
ture physique est actuellement mise en oeuvre tout en conservant une
sparation protocolaire. Ce nouveau modle entrane une complexica-
tion de la gestion des coeurs de rseaux. En effet, ceux-ci sont soumis
des contraintes quasi contradictoires de disponibilit, de qualit ou
de exibilit.
La problmatique rside alors dans loptimisation des architectures.
Ce problme peut ainsi tre trait la fois par une gestion des topolo-
gies adosse une gestion protocolaire spcique aux divers besoins.
Les travaux de recherche se focalisant sur ltude de la topologie
tendent amliorer la disponibilit, contrario les tudes protoco-
laires sont axes sur la qualit de service. Cependant, ces approches
ne prennent pas vraiment en considration la exibilit, eu gard
la diversit des ux transports (Audio/visuel, Internet, Tlphonie,
Donnes prives).
Dans ce mmoire de thse, nous nous proposons de rconcilier ces
besoins contradictoires et en complment des approches classiques,
nous dvelopperons un nouveau mcanisme de rgulation protocolaire
offrant de nouvelles capacits de exibilit.
Le premier chapitre dcrit plus prcisment le contexte de notre
tude. Aprs une description de larchitecture du rseau mutualis
(TMS : Transport Multi-Services), nous prsenterons la problmatique
de la gestion interne du "Core Network".
Le chapitre suivant dresse un tat de lart des diffrents mcanismes
de la rgulation de trac. Nous sparerons les approches orientes
topologies(Provisioning), des approches protocolaires (ECN,XCP,...).
Le chapitre trois analyse ces diverses propositions et met en vidence
leurs manques dans le cadre dinfrastructures mutualises. Cette tude
nous amnera ainsi dnir une approche novatrice fournissant les
mcanismes manquant une rgulation optimale.
7
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
8 introduction
Le chapitre quatre sattache valider notre dmarche. Pour ce faire
nous avons effectu une modlisation formelle de cette approche.
Lintrt de cette proposition est dmontr dans le cadre dune tude
pratique, complte par une tude doptimisation du systme.
Le dernier chapitre repose sur la ralisation dune maquette. Celle-ci
nous a permis dune part de contrler les interactions protocolaires, et
dautre part de mesurer les performances de notre nouveau systme
de rgulation.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Premire partie
LE CONTEXTE DE L TUDE
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
3
PRSENTATI ON DU PROJ ET TMS
An de raliser mes travaux de recherche, jai t intgr lquipe
de conception du projet TMS (Transport Multi-Service). Ce projet
dbut en 2006 a pour objectif de raliser un rseau de transport
national pour lensemble des applications mtiers de lentreprise. Ce
chapitre sattarde la prsentation du projet TMS qui est le support
principal de mes recherches.
3.1 descriptif gnral
TDF met en place un nouveau rseau de transport IP/ Ethernet
utilisant la technologie "Multiprotocol Label Switching"(MPLS) orient
audiovisuel. Les orientations techniques de ce rseau reposent sur une
architecture moderne et rsistante, tirant partie des dveloppements
technologiques du monde des tlcommunications :
une transmission en numrique, haut dbit ;
un coeur de rseau en bres optiques, avec une architecture en
boucles ;
un rseau daccs aux extrmits en faisceaux hertziens num-
riques haut dbit.
un systme de routage permettant la souplesse de conguration
et lintroduction de nouveaux services.
3.2 objectifs
Aujourdhui, chaque demande de transport ou de raccordement est
traite au cas par cas, au moyen de liaisons individuelles achetes pour
la plupart loprateur FT ou sa liale Globecast. Les offres ne per-
mettent pas de faire bncier nos clients dun effet de mutualisation
des moyens.
TMS permettra de partager techniquement et commercialement un
rseau de tlcommunication intgr et opr par TDF entre les diff-
rents clients, tout en prservant une condentialit absolue entre les
ux de ses clients.
Cette mutualisation se traduira par des offres commercialement plus
11
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12 prsentation du projet tms
attractives, plus souples pour les clients de TDF .
Par lutilisation de ce rseau numrique, les clients pourront demander
de nouveaux services, que TDF ne peut offrir actuellement.
3.3 une architecture nationale
Le rseau est compos dun ensemble de boucles optiques tendues
sur le territoire franais. En plus de ces boucles, sont rajouts des
pendulaires en faisceaux hertziens. Au total, on dnombre environ 50
sites relis en optique et plus de 150 en hertzien.
Figure 2: Principe du rseau TMS
3.4 larchitecture protocolaire
Larchitecture protocolaire du rseau est conue pour satisfaire des
critres de rsilience, de scurit et de qualit. Tout dabord, son
architecture en boucles permet de supporter la dfaillance dune liaison
WAN.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
3.4 larchitecture protocolaire 13
Lensemble du rseau utilise un adressage inclus dans une aire
OSPF. Cette conguration facilite la cration de tunnels MPLS. En effet,
les protocoles de signalisation LDP utilisent les SPF pour la cration
automatique de tunnels.
An dassurer le cloisonnement du rseau, aucun peering BGP nest
effectu avec un autre oprateur. Le coeur de rseau IP est uniquement
utilis pour faire transiter des ux de contrle et de mtrologie.
Lensemble des inter-connexions et services apports aux entreprises
est encapsul dans des messages MPLS de telle manire assurer
lintgrit du coeur et lindpendance entre les divers services.
3.4.1 La technologie MPLS dans TMS
MPLS est un mcanisme de transport de donnes, oprant sur la
couche liaison, en dessous de protocoles comme IP. Il a t conu pour
fournir un service uni de transport de donnes pour les clients sur
la base de commutation de paquets ou commutation de circuits. MPLS
peut tre utilis pour transporter diffrents types de trac, par exemple
de la voix ou des paquets IP.
MPLS fonctionne par commutation de labels. De faon manuelle ou
automatique, ladministrateur du rseau MPLS tablit un ou plusieurs
chemins. On fait la diffrence en MPLS entre les routeurs dentre, de
transit, et de sortie. Un chemin MPLS tant toujours unidirectionnel,
le routeur dentre diffre du routeur de sortie.
Le routeur dentre a pour rle dencapsuler pour la premire fois le
trac reu sur ses interfaces clients . Il applique un label au paquet
reu et lenvoie vers une de ses interfaces sortantes.
La technologie MPLS possde un avantage de taille dans un rseau
multiservices, elle permet de raliser de lingnierie de trac, cest-
-dire de garantir la qualit de service et doptimiser les ressources
rseau. En effet, le chemin rseau pouvant tre explicitement dni,
MPLS possde les atouts pour raliser une ingnierie de trac ne.
De plus, aucune information des paquets clients nest ncessaire
pour effectuer ce routage. On peut donc transporter des ux non IP
ou dautres technologies. Il est ainsi possible de transporter des ux
ATM par exemple.
On peut galement adjoindre un vritable rseau en overlay en
mulant les fonctionnements de switchs, de routeurs ou de mca-
nismes divers (MC-LAG[7], Pseudo-wire redundancy[1],...) reli par
lintermdiaire des liens MPLS.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Transport d'un Flux SP TS
Transport d'un Flux MP TS
Figure 3: Exemple de trac de diffusion Vido
MPLS garantit galement une trs grande disponibilit avec des
protocoles tels que le Fast Reroute, qui permet de rtablir un lien
rompu en moins de cinquante millisecondes.
3.5 les services tms
TMS a pour vocation le transport de divers services. Tous ces services
sont raliss laide de PPVPN [3]. La topologie et les protocoles
mis en place sont choisis sur mesure en fonction du service et de ses
contraintes. Ainsi, un premier choix est effectu entre une virtualisation
de niveau 2 (type VPLS [23]) ou niveau 3 (VPRN [16]), puis des
complments sont ajouts pour respecter des contraintes de transport
(H-VPLS [2],...).
Voici une srie de services types pouvant circuler sur le rseau
TMS. Cette liste est non-exhaustive et permet simplement de se rendre
compte de la diversit des ux et des contraintes.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
3.5 les services tms 15
3.5.1 La diffusion de la TNT vers les metteurs
Du transport de la tte de rseau vers lensemble des metteurs,
ce service demande une contrainte de qualit forte qui sexprime par
un faible taux de perte paquets et une gigue minimale. Ce service se
traduit par une diffusion multicast fort dbit. Le transport concerne
des metteurs possdant une forte densit de population. Les ventuels
re-routages se doivent dtre raliss dans des dlais infrieurs la
seconde.
3.5.2 Le transport scuris de multiplex audio-visuel
Ce service a pour mission le transport de ux audio-visuel en temps
rel. La principale contrainte technique est limpossibilit de linter-
rompre nimporte quel moment de la journe. Ce type de transport
est notamment utilis pour le transport vers les stations montantes sa-
tellites de diffusion vido. On retrouve les mme contraintes que dans
les services prcdents avec des dbits encore plus importants puisque
transportant des bouquets complets de chanes tlvisuelles(Fig. 3). On
peut galement retrouver des encodeurs dans la chane si le transport
concerne des chanes analogiques.
3.5.3 Le transport dagrgats de trac Wimax
Le rseau TMS est galement le support de transport national pour
des ux Internet, TDF ayant sa charge un certain nombre de plaques
rgionales Wimax. Lensemble des ux est agrg avant dtre trans-
port de manire globale vers les diffrentes plate-formes des fournis-
seurs daccs Internet. On y retrouve les prols cycliques classiques
(Fig. 4)de lutilisation dInternet dus la diffrence dutilisation entre
le jour et la nuit, le week-end et la semaine.
3.5.4 Linterconnexion mtier
Un autre exemple remarquable concerne le service lentreprise. En
effet, le besoin dune grande quantit de bande passante sporadique
peut apparatre(Fig. 5). Le backup de bases de donnes ou le transport
de squences audio-visuelles en vue de montage sont des exemples de
ces cas dutilisation.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Figure 4: Exemple de ux Internet Agrger
3.6 les problmatiques de tms
Les nombreuses particularits de ce rseau face aux contraintes
habituellement exposes dans les rseaux IP nous amnent nous
interroger sur la pertinence des mthodes habituelles de gestion.
La mise en place dinfrastructures physiques, telles que les faisceaux
hertziens et les bres optiques, sont des postes de cots importants
pour le rseau. Aussi, une utilisation maximale de la bande passante est
souhaite et une gestion ne de lingnierie de trac se doit dtre mise
en place. A contrario, les besoins sporadiques de bandes passantes
leves des clients sont en complte contradiction par rapport une
utilisation maximale du coeur de rseau. Les politiques classiques
utilises par les oprateurs traditionnels ne peuvent pas convenir sur
ce rseau particulier du fait des hypothses gnralement formules.
En effet, on peut constater de nombreuses diffrences :
Le rseau TMS dispose dune majorit de ux RTP/UDP audio-
visuels fort dbit.
Etant donn sa position doprateur de gros, TMS ne dispose pas
dune base de clients "Best Effort faible dbit". La consquence
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
3.6 les problmatiques de tms 17
Figure 5: Exemple de transport sporadique
immdiate est quun provisionning statistique bas sur la thorie
des grands nombres nest pas adapt au systme.
Chaque client dispose de prols de tracs trs diffrents voire
changeants, ce qui, associs leurs tracs levs, remet galement
en cause une gestion de provisionning classique.
Finalement, on peut constater quune approche classique nous
amne refuser en accs de nombreux paquets qui nalement pour-
raient traverser sans encombre le rseau. Ce refus acceptable dans un
rseau classique est plus problmatique dans TMS.
En effet, de nombreux sites sont accessibles uniquement par fais-
ceaux hertziens et il est alors beaucoup plus compliqu daugmenter
la bande passante. Un partage et une mise en concurrence des clients
deviennent alors une quasi obligation.
La ncessit de ce partage est en plus renforce par les volutions
des technologies des faisceaux. Les constructeurs conscients de ces
limites tendent raliser un codage dynamique entranant des bandes
passantes qui varient dans le temps [18](en fonction de la mto
notamment).
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
4
LE TRANSPORT MUTUALI S
Le chapitre prcdent a mis en vidence un certain nombre de
questionnements propres au rseau TMS. On peut nalement constater
que ces interrogations sont propres une famille de rseaux qui
recherchent la fonction de transport mutualis.
4.1 les oprateurs de wholesale
Service de
tlphonie
xe
Service de
tlphonie
mobile
Internet
Diffusion
tlvisuelle
C
o
e
u
r

d
'
i
n
t
e
r
c
o
n
n
e
x
i
o
n
Rseau Physique
Accs
fIxe
Accs
mobile Accs
Internet accs
tlvision
Accs
fIxe
Accs
mobile Accs
Internet accs
tlvision
Accs
fIxe
Accs
mobile Accs
Internet accs
tlvision
Interconnection
Logique
Interconnection
Physique
Figure 6: Positionnement dun rseau de wholesale
La convergence des rseaux et services engendre une mutualisation
des infrastructures. Les diffrents services ports le plus souvent par
des acteurs spars regroupent leur infrastructure, soit en effectuant
un rapprochement, soit en faisant appel un oprateur mutualisant les
ressources. Le dit oprateur est alors appel "Oprateur de Wholesale".
On retrouve alors les deux objectifs antagonistes prsents dans le cadre
de TMS :
Loprateur de "Wholesale" veut maximiser lutilisation de son
coeur pour proter au mieux des bnces conomiques apports
par la mutualisation.
19
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
20 le transport mutualis
Loprateur "virtuel" souhaite disposer dun maximum de qualit,
de resilience et de exibilit. Pour dune part se diffrencier de la
concurrence et dautre part fournir le meilleur et le plus attractif
des services.
Dans ce cadre, la politique de qualit de service cible doit permettre
de grer les congestions dans le coeur du rseau, tout en minimisant
les effets induits sur les extrmits. Ces oprateurs utilisent alors des
technologies de qualit de service et des mthodes de gestion de bande
passante ("Trac ingenierie") pour effectuer ces optimisations.
4.2 exemple doprateur de wholesale : colt
Un exemple bien connu des rseaux de transport mutualis est le
rseau de la socit COLT. Cette entreprise propose la mise dispo-
sition de VPN pour les PME et les grandes entreprises europennes.
Le rseau est compos principalement de liaisons optiques loues
diffrents oprateurs nationaux. Bien que positionn une chelle
gographique diffrente du rseau TMS, la problmatique reste simi-
laire du fait du choix de la clientle cible. On retrouve la ncessit de
pouvoir cloisonner les divers clients tout en recherchant la meilleure
optimisation pour le coeur de rseau.
Figure 7: Rseau europen de la socit COLT
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
4.3 hypothses et bornes de ltude 21
4.3 hypothses et bornes de ltude
Dans ce contexte, nous nous focaliserons sur ces mthodes de gestion.
Nous concentrerons donc nos travaux aux contextes de "wholesale".
Nous conserverons donc un certain nombres dhypothses :
tous les ux des oprateurs virtuels seront encapsuls dans des
PPVPN,
lensemble des PPVPN sera ralis laide la technologie MPLS,
toutes nos modications seront effectues dans le rseau la
charge de loprateur de Wholesale.
Nous tudierons les mthodes que nous qualierons de "macrosco-
pique" utilises par les oprateurs pour dimensionner le dbit des
liaisons de manire globale.
Puis, nous tudierons les approches qualies de "microscopique"
rgulant la bande passante lors de congestion. Ces tudes nous permet-
trons de comprendre comment optimiser ces approches et adjoindre
de nouveaux mcanismes apportant une plus grande exibilit aux
oprateurs.
Derrire le concept de exibilit, nous positionnerons principalement
la capacit de pouvoir fournir de la bande passante opportuniste un
client (mutualisation de la bande passante).
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Deuxime partie
ETUDE DE L EXI STANT
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
5
PROVI SI ONI NG RSEAUX
An de concevoir les mcanismes qui optimiseront au mieux le
coeur de rseau, il faut comprendre comment est effectu le dimen-
sionnement des liaisons et comment on gre cette problmatique au
jour le jour.
5.1 principe gnral
Rseaux
Mtrologie
Dynamique
Route
Metric
Dynamique
Ressource
Allocation
Dimensionnement
Rseau
Trac
Forecast
Demande
Clients
trac engineering
Figure 8: Principe du trac engineering
Le principe du provisionning rseau repose sur une tude des tracs
existants. Il existe de nombreuses mthodes systmatiques de traite-
ment pour cette problmatique ([36] et [12]). De manire gnrale,
on retrouve un certain nombre de concepts caractristiques an de
rpondre une question simple : "Quel dbit pour quelle liaison?".
Ces concepts et les diverses propositions seront dtaills dans les
paragraphes suivants.
25
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
26 provisioning rseaux
5.2 la matrice de trafic
Il sagit le plus souvent de la base des calculs. Cette matrice tente de
dterminer quels routeurs communiquent avec quels autres routeurs
et quels dbits. Dans un rseau IP standard (sans mcanisme de type
MPLS), tous les tracs dune source allant vers une destination passent
par le mme chemin un moment donn.
A partir de ce constat et de la matrice, on peut ainsi prdire les lieux
sous dimensionns, et prvoir des reroutages, ou encore laccroisse-
ment de certaines liaisons.
La dtermination de la matrice de trac est un travail en soit. En
effet, le trac de chaque noeud voluant au cours de la journe et
pouvant varier galement plus long terme, la dtermination dune
valeur reprsentative nest pas aise. La valeur utilise rsulte le plus
souvent dune tude statistique des tracs observs sur le rseau [31].
Cette dtermination se base sur une mtrologie SNMP (Simple
Network Management Protocol) interrogeant les quipements toutes
les 5 minutes. Les phnomnes de faible dure peuvent tre ignors
[30]. Ainsi, des micro-congestions peuvent apparatre et tre totalement
ignores dans ltablissement du provisioning.
Les travaux de C. Fraleigh[15] sont un exemple de dtermination
de cette matrice. A noter que le choix de cette matrice peut fortement
impacter les rsultats. Ainsi, C. Fraleigh tente de minimiser ces micro-
congestions par le biais dune estimation des prols clients.
5.3 optimisation des routes
Une fois la matrice de trac dtermine, plusieurs actions sont
possibles. Les chemins rseaux utiliss pour aller dun point A au point
B sont dpendants uniquement de lIGP (Interior Gateway Protocol).
Celui-ci va favoriser une route en fonction de ses mtriques. On peut
alors calculer ces mtriques pour optimiser la rpartition. Dans la
majorit des cas, on recherche un partitionnement le plus homogne
possible. P. Sousa[34] va jusqu proposer une automatisation de ce
processus.
5.4 apport de mpls dans loptimisation
MPLS est, dans le cadre de ces calculs de routes optimales, un nou-
vel atout. En effet, lhypothse dnie prcdemment "tout trac allant
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
5.5 admission control 27
dun point A vers un point B passe un instant t par un chemin
unique" peut ainsi tre supprime. En effet, chaque tunnel MPLS peut
mme, si ses extrmits sont communes, utiliser des chemins diffrents.
M. Banner[5] dmontre de faon thorique les apports de cette capa-
cit utiliser plusieurs chemins. De son ct, S. Kohler[21] sattache
montrer lefcacit dune approche mixte "Trafc engineering" et
optimisation de lIGP.
5.5 admission control
On retrouve aussi des approches par "Admission Control" [8] qui
proposent que chaque routeur dextrmit value dynamiquement la
bande passante disponible pour aller vers les autres routeurs dextr-
mit. Cette capacit est estime laide des fonctions TE des protocoles
de routage. A chaque nouvelle requte client, le routeur dextrmit
vrie la bande passante disponible et tablit le chemin grce un
algorithme "Constraint Based Routing"[38]. Ces approches permettent
darriver pas pas un rseau le plus charg possible sans congestion.
5.6 notion de rsilience
Cependant, dautres contraintes sont prendre en compte. En effet,
le rseau nest pas exempt de pannes (qualies par A. Markopoulou
[28]). La panne dune liaison entrane un dlestage vers les autres
chemins. Si une optimisation est effectue au plus juste, la simple
panne dune liaison peut compromettre une partie entire du rseau.
Pour viter ce type de problme, la prise en compte des effets des
pannes a t ajoute pour considrer le dbit prsent sur les liaisons
et le plus souvent, en utilisant la capacit de MPLS signaler le dbit
utilis (dbit estim au sens dni par la matrice de trac) sur chacune
des liaisons. De mme, on rserve priori la bande passante sur un
chemin de backup disjoint de telle manire assurer la rsilience
une panne. Cet ajout entrane une sur-valuation importante de la
bande passante utilise. M. Kodialam[20] propose une mutualisation
de chemins de backup issus de tunnels diffrents an de limiter cette
sur-valuation.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
28 provisioning rseaux
5.7 rserve sur le provisioning
Des limites apparaissent quant lutilisation de ces mthodes de
provisioning. En effet, on observe une sur-estimation de la bande
passante ncessaire par liaison ("Over-provisioning"), dune part
cause des marges prises lors de ltablissement de la matrice de trac,
et dautre part cause de la gestion de la panne. Lensemble de ces
mesures oblige provisionner de la bande passante qui ne sera quasi
jamais utilise.
De plus, mme si les approches par "Admission Control" vont per-
mettre une meilleure utilisation du coeur, elles ne peuvent rpondre
aux changements brutaux de bande passante qui se produisent dans
nos exemples de wholesaling. Elles ne pourront pas non plus rpondre
aux capacits de liaisons changeantes [18].
Finalement, les amliorations apportes par le provisioning rseau
ne permettent pas dutiliser le maximum des capacits du rseau. Ces
solutions maintiennent continuellement une partie de la bande pas-
sante non utilise. Par la suite, nous nous focaliserons sur une mthode
pour pouvoir utiliser cette bande passante laisse pour compte.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
6
EVOLUTI ONS DES SYSTMES DE RGULATI ON
Dans la plupart des rseaux, le point de congestion des ux las-
tiques se trouve en accs de celui-ci. Ceci peut sexpliquer historique-
ment par la rupture technologie entre les liaisons daccs et de coeur
(Digital Subscriber Line DSL / Wavelength Division Multiplexing
WDM). Dans le cas des rseaux de transport mutualis, cette rupture
nexiste pas et la limitation est donc faite par policing. Ce qui entrane
la prsence dun point de congestion logique (par conguration) en
accs du rseau.
Utiliser la bande passante rsiduelle au provisioning revient donc
lever ces limitations logiques de policing en accs. Ce qui nous
ramne devoir grer les congestions au coeur du rseau et plus
particulirement tudier le partage de la bande passante pendant
cette congestion.
De nombreuses tudes sur lquit ont t menes dans le cadre du
rseau Internet. Nous allons tout dabord revenir sur ces approches
pour comprendre leurs apports et leurs limitations an de rechercher
une solution approprie.
6.1 les mcanismes de la rgulation de trafic
Historiquement, la rgulation de la bande passante dans les rseaux
IP est reporte aux extrmits. Dans la pratique, seules les connexions
TCP prsentes sur les extrmits vont sauto-limiter pour permettre
lensemble du rseau de bien se comporter. Pour optimiser cette
approche, de nombreuses modications sont rgulirement apportes
cette auto-rgulation.
Des mcanismes de coeur peuvent venir complter cette rgulation.
Par exemple, le mcanisme RED [9] (Ramdom Early Detection) sup-
prime des paquets alatoirement dans la le dattente dun noeud si
celle-ci dpasse un seuil de remplissage dtermin. En rejetant des
paquets TCP, il force la rgulation des connexions la baisse.
Dautres mcanismes agissent plus subtilement, la conguration
dun buffer dans le coeur peut entraner une augmentation de la
latence et par consquent, une augmentation du RTT pour TCP; ce
qui l encore impacte le dbit des connexions.
29
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
30 evolutions des systmes de rgulation
Lapproche Diffserv [6] est un mcanisme connu qui permet de
modier la gestion de la bande passante. Cette approche agit indirec-
tement sur la rgulation produite par TCP. En effet, la mise en place
dune gestion de priorit entrane ncessairement un allongement des
dlais de transit dans les noeuds modiant ainsi le RTT de TCP.
On retrouve plusieurs motivations lajout de ces mcanismes.
La premire repose sur lamlioration qualitative de la congestion.
Lobjectif tant alors, soit de minimiser les pertes, soit de diminuer les
dlais de transit.
La seconde motivation rside alors dans ltablissement dun par-
tage quitable entre les sessions [27]. Lquit pouvant tre dnie
de diffrentes manires. P. Marbach propose par exemple un partage
reposant sur lutilisation dune pondration pour favoriser certains
ux.
6.2 lapproche systme service allocation
Routeur en congestion
Figure 9: Principe du Systme Service Allocation
Une des volutions les plus intressantes rside probablement dans
le systme Service Allocation [13]. Il repose sur des colorieurs situs
en accs du rseau qui sparent le trac TCP en 3 couleurs (vert, jaune,
rouge). Les paquets de couleur rouge ne sont gnralement pas admis
dans le rseau et ceux de couleurs verte et jaune sont transmis dans
le coeur avec des marqueurs de qualit de services diffrents. Les
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
6.3 lapproche systme ecn 31
diffrents ux sont transports dans les routeurs de coeur de rseau
par le biais dun seul et mme buffer. Cependant, la bufferisation
est soumise plusieurs systmes RED. Chaque RED associ une
couleur dispose dun paramtrage diffrent xant son propre seuil
de drop. Compar aux systmes plusieurs buffers, chacun affect
une qualit, lintrt de ce systme rside dans le fait quil nentrane
aucun dsordonnancement.
Le but recherch est de fournir un ux de donnes une qualit
paramtrable par lintermdiaire du colorieur daccs. Toutefois de
nombreuses tudes [14], [33],[25] ont dmontr que ce systme ne
permet pas de garantir le respect dune quit souhaite. En effet, il
est impossible de garantir un minimum de bande passante chaque
utilisateur. Si la premire couleur est en saturation le systme ne peut
pas garantir ce minimum (ncessit dun provisioning adapt).
Cette approche engendre galement des difcults dans le dimen-
sionnement des buffers. Le remplissage du buffer dmission dune
liaison en congestion est dpendant dune part de la conguration du
mcanisme RED et dautre part du nombre de connexions TCP[35].
Cependant le nombre de connexions TCP pouvant varier fortement, les
congestions apparaissant le plus souvent suite des pannes de liaisons,
il est impossible de prdire la nouvelle distribution de ces connexions
dautant plus que ce nombre reste li au besoin de chaque client. On
se retrouve alors avec un algorithme RED dont le paramtrage nest
plus adapt entranant une baisse de la qualit de la liaison en terme
de latence et de pertes.
En conclusion ce systme reste difcilement applicable. Cependant,
son concept apporte une vision intressante car il ne propose pas de
nouveaux mcanismes de coeur pour la gestion de la bande passante
mais repose sur un assemblage de plusieurs mcanismes existants
(RED + Marqueur + Colorieur).
6.3 lapproche systme ecn
Lapproche ECN [32] va plus loin dans linteraction des routeurs de
coeur et des algorithmes daccs. Cette approche, issue de mcanismes
mise en oeuvre dans les technologies ATM puis Frame Relay, consiste
modier le comportement de TCP par le biais du transport dune
information supplmentaire de congestion. Lors dune congestion, les
routeurs du coeur de rseau modient la vole le champs CE des
paquets TCP. Le rcepteur prend alors en compte cette information et
la renvoie par lintermdiaire de paquets ACK avec un champ ECN-
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Paquets ACK avec ECN-ECHO
Paquets TCP avec
CE bit modi
Figure 10: Principe du systme ECN
ECHO. Lmetteur peut alors adapter son dbit pour supprimer cette
congestion sans perte de paquets.
Cette approche a donc conceptuellement un intrt majeur : elle
rapproche explicitement les mcanismes de rgulation de coeur et
daccs.
Par contre, Cette modication a plusieurs consquences :
Elle oblige le routeur de coeur modier la vole tous les
paquets TCP, ce qui engendre des traitements supplmentaires du
routeur pour grer les paquets.
la modication du paquet na dintrt que si les deux quipe-
ments dextrmits utilisent cette information et modient leurs
comportements en consquence. An dobtenir lquit recherche
lensemble des quipements terminaux doivent agir de manire
homogne.
6.4 explicit control protocol (xcp)
Cette approche, propose dans [19], est une gnralisation de lap-
proche ECN. En effet, selon lapproche ECN, un feedback est rendu
lmetteur par lintermdiaire dune information binaire : la prsence
ou non dune congestion.
Dans le cadre du XCP, lchange dinformation est plus important.
Les paquets mis informent sur ltat de la connexion (dbit, RTT).
Les routeurs de coeur doivent agrger ces informations pour dcider
daugmenter ou pas pas les dbits de ces ux. Pour ce faire, la mme
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
6.5 evaluation dans le cadre des rseaux de transport mutualis 33
Router in congestion
Packets ACK with Feedbabk
Packets XCP with
Delta_throughput
modify
Figure 11: Principe de lapproche XCP
mthode que lECN est adopte, savoir la modication dun champ
du ux mis, retransmis par un champ de feedback sur les messages
dacquittements.
Lapproche XCP apporte un certain nombre davantages face au
protocole ECN :
La ralisation dune quit plus rapide.
La possibilit de fournir des qualits diffrentes en jouant sur la
valeur du Delta_throughput renvoye dans le feedback.
6.5 evaluation dans le cadre des rseaux de transport
mutualis
Nous avons prcdement tudi plusieurs approches ralisant une
gestion lchelle "microscopique" de la congestion. Nous avons mis
en vidence un certain nombre de points communs qui ressortent de
lensemble de ces travaux :
Tout dabord, tous ces travaux sont bass sur ltude du rseau
Internet. Laspect mutualisation nest trait uniquement que dans
le cadre de nouveaux services linternaute (IpTV, VoIP), mais
jamais abord dans le cadre dun rel rseau de transport mutua-
lis.
Ensuite, ces approches dclarent la bande passante partage "qui-
tablement" quand chaque session protocoloraire utilise la mme
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
fraction du dbit. Cette notion est fortement critiquable car elle ne
prend pas en compte les aspects conomiques du rseau. En effet,
une session TCP na aucun rapport avec les entits conomiques
utilisant le rseau [10].
Enn, les contraintes industrielles ne sont que partiellement prises
en compte par ces solutions. Lassociation entre les mcanismes
de coeur de rseau et les algorithmes dextrmits ne rpond pas
aux contraintes scuritaires. Dautre part, la politique de gestion
des congestions occulte en partie la problmatique du dimension-
nement.
Ainsi une approche de type RIO peut tre mise en oeuvre dans
une architecture de transport mutualis, mais sa gestion partielle de
lquit par session la rend dune utilisation hasardeuse.
Quant elles, les approches ECN et XCP ne correspondent pas aux
contraintes dun rseau de transport mutualis. La rgulation tant
effectue par un mcanisme distribu sur chaque metteur, loprateur
est contraint de faire conance aux implmentations se trouvant chez
ses clients. Ce qui nest pas sans consquence sur le plan scuritaire.
Dans [29], P. Mosebekk met en vidence les difcults de mise en
oeuvre du protocole XCP dans un rseau. Dans [37], C. Wilson prouve
les possibilits de dtournement du protocole pouvant entraner des
problmes dquit importants.
De plus la modication dun champs de TCP est en complte contra-
diction avec le fonctionnement de MPLS qui ignore la couche 4 des
paquets.
Finalement, ltude de ces mthodes de gestion de la bande pas-
sante nous a permis de constater limpossibilit dutiliser simplement
ces approches "microscopiques" pour raliser une gestion plus ne
de la bande passante rsiduelle du coeur. En effet, deux difcults
apparaissent dune part la mise en oeuvre de ces approches rclame
une modication de la chane complte du transport de lmetteur au
rcepteur en passant par les noeuds intermdiaire, dautre part les
ux en mode non-connct (type UDP) sont totalement ignors par
le mcanisme de partage. En conclusion, seul un systme reliant les
fonctionnalits dun provisioning rseau, la gestion des phases de
congestions devrait permettre de rpondre cette problmatique.
Le chapitre suivant sattachera tudier, laide de ces enseigne-
ments, un nouveau systme de rgulation ddi cette double gestion.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Troisime partie
PROPOSI TI ON DE NOUVELLES
APPROCHES
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
7
CONSI DRATI ONS SUR LE NOUVEAU SYSTME
Nous avons vu prcdemment la ncessit dans les rseaux de
transport mutualis de faire coexister et cooprer les approches "ma-
croscopiques" de provisioning avec les approches "microscopiques" de
gestion de la bande passante. Nous allons identier dans un premier
temps les lments caractristiques des rseaux de transport mutualis
qui nont pas t pris en considration dans les approches historiques.
7.1 la base du rseau de transport mutualis : le service
Dans une architecture de rseau de transport mutualis, le service
est positionn sur une virtualisation de linfrastructure. Chaque service
dun client repose sur un rseau virtuel. Cette sparation est unique-
ment protocolaire, la bande passante globale de linfrastructure reste
commune tous. Un service se rsume nalement un PPVPN lui-
mme compos dune part dun certain nombre de tunnels MPLS qui
sont la base de la connectivit du service et dautre part de noeuds
virtuels qui mulent le comportement dun quipement rseau rel.
A chaque service, on associe galement des politiques de gestion des
accs qui effectueront les oprations de policing, shaping et marking
sur les ux clients.
7.2 une approche diffrenciant les tunnels
La principale difcult des prcdentes approches tudies au cha-
pitre 6 rside dans leurs implmentations au niveau de la couche 4
du modle OSI. En effet, la couche transport gre une connexion de
bout en bout et ne permet pas de raliser une optimisation locale un
secteur du rseau.
Ces observations nous amnent la conclusion quil est ncessaire
dlargir les prrogatives des tunnels MPLS pour intgrer la notion de
gestion de la bande passante au niveau du tunnel. Cela implique la
possibilit de dimposer les bandes passantes des rseaux virtuels. La
rservation de bande passante effectue par RSVP pour ces tunnels est
37
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
38 considrations sur le nouveau systme
un premier pas vers cette vision. Cependant, ce mode dallocation de
ressource ne permet pas une gestion dynamique de la bande passante.
Il convient alors dintgrer dans notre systme la facult de mutua-
lisation de la ressource. Un tunnel peut tre trait face au rseau de
transport mutualis de la mme manire quune connexion TCP est
traite face au rseau internet.
On retrouve dailleurs des proprits similaires entre une connexion
TCP et le dbit prsent dans un tunnel. En effet, le ux dun tunnel
nest quun agrgat de connexions. Les proprits comme llasticit
sont alors transmises au ux agrg. Dans le systme propos, nous
utiliserons cette proprit limage des mthodes utilises dans les
approches microsopiques .
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
8
FORMALI SATI ON DU SYSTME TDCN- ECN
Au regard des observations prcdentes, nous proposons dans ce
chapitre une nouvelle approche. Pour ce faire nous considrerons le
tunnel comme llment de base du rseau.
Les tudes prcdentes sur les approches de niveau 4 nous ont
permis dtudier un certain nombre de techniques probantes pour
rpondre la problmatique du partage quitable. Dans notre sys-
tme, nous proposerons dutiliser un retour dinformation binaire
limage du principe du protocole ECN. Lors de lanalyse des besoins
de notre systme, nous avons identi un certain nombre de conditions
prendre en considrations :
La rpartition du partage de la bande passante dune liaison
sera ralise au prorata dun contrat tabli pour chaque tunnel,
la signalisation permettant ce partage restera borne au domaine
de conance de loprateur pour faciliter la phase dindustriali-
sation,
lobjectif consistera ne pas modier les couches sessions an
de ne pas imposer aux clients le choix de ses protocoles.
8.1 dtection de la congestion
An de raliser une boucle de rgulation efcace, il convient de
dtecter les priodes o une limitation est souhaite. Pour ce faire,
le systme ECN effectue une dtection de la congestion par le biais
dun marquage des paquets sur une bufferisation. Notre systme tant
destin intervenir sur une congestion entre divers tunnels, il est
essentiel que les ux associs aux tunnels reposent sur un mme et
unique buffer avant mission. La proposition suivante devra donc tre
respecte :
Rgle TDCN 1 Au sein des routeurs intermdiaires, lensemble des pa-
quets des tunnels grs par TDCN doivent transiter par un buffer unique
avant la transmission sur le rseau.
Un rseau best-effort peut rpondre cette proposition. De la mme
manire, un rseau mettant en oeuvre Diffserv [11] permet galement
39
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
40 formalisation du systme tdcn-ecn
Buffeur de sortie du routeur
Figure 12: Mise en commun des buffeurs de sortie des routeurs de coeur
lutilisation du TDCN si on se satisfait de son usage sur une seule
classe de service. Ce qui autorisera une intgration plus aise au sein
des rseaux existants.
Le nouveau systme se basera sur un remplissage partiel de ce buffer
pour reprer une congestion. En effet, le principal indicateur dune
congestion vient des applications lastiques qui en essayant de crotre
entranent une bufferisation sur le lien congestionn [4].
8.2 transport de linformation de la congestion sur les
tunnels
La technique retenue repose sur une limitation en accs lors des
priodes de congestions. Ces congestions pouvant intervenir dans
le coeur de rseau, il est ncessaire de rapatrier linformation de
congestion sur le chemin du tunnel MPLS. Ces lments nous amnent
tablir la proposition suivante :
Rgle TDCN 2 Tout tunnel doit disposer dun mcanisme permettant de
connatre ltat de congestion du dit tunnel. Le tunnel est considr conges-
tionn si au moins une liaison du chemin du tunnel est congestionne.
La rutilisation des protocoles de signalisation des labels MPLS
semble toute indique pour mettre en oeuvre ce mcanisme. En effet,
le protocole RSVP-TE par exemple offre la possibilit de rajouter des
paramtres [22]. Le maintien de sessions permet de conserver un
rafrachissement de ltat des paramtres pouvant descendre jusqu
300 ms.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
8.3 fonctionnement des rgulateurs daccs dar 41
8.3 fonctionnement des rgulateurs daccs dar
DEBUT
NON
OUI
Congestion?
PIR=CIR?
Reduction du
PIR
PIR=PIR_Max?
NON
Augmentation
du PIR
OUI
OUI
Figure 13: Algorithme du rgulateur
A partir des deux rgles dnies prcdemment, le systme est
capable de connatre sur le routeur daccs du rseau ltat des tun-
nels en aval. Grce cette information, chaque tunnel sera capable
de rguler son dbit en fonction de ltat du rseau. Pour ce faire,
nous disposerons alors en amont de chaque tunnel dun limitateur
de dbit que nous appellerons DAR (Dynamic Acces Regulator). Il
convient donc de dnir la proposition suivante correspondant au
fonctionnement du rgulateur :
Rgle TDCN 3 Tout tunnel TDCN doit possder en entre un rgulateur
ddi prenant en compte linformation de congestion fournie par un protocole
(rgle 2). Ce rgulateur dispose dun paramtre dnissant la limite maxi-
male dautorisation dentre dans le rseau (High Level Autorisation :HLA)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
et dun paramtre dnissant la limite minimale (Low Level Autorisation :
LLA). La limite courante un instant donn est appele CLA() (Courant
Level Autorisation).
En complment de la rgle prcdente, il faut pouvoir garantir la
convergence du rgulateur en priode de congestion. Ce qui signie
qu il doit durcir sa politique dautorisation dentre dans le rseau
an de ne pas participer la congestion du coeur, mais au contraire
de lattnuer pour nalement la dcaler lentre du rseau. Ce fonc-
tionnement peut tre rsum dans la proposition suivante :
Rgle TDCN 4 Lors de la dtection dune congestion dun tunnel, le r-
gulateur doit diminuer sa CLA tout en respectant les quations suivantes :
lim
t
congestion
+
CLA() = LLA (8.1)
min(CLA()) LLA, (8.2)
De la mme faon, si aucune dtection de congestion nest effec-
tue sur le trajet dun tunnel, la limitation doit tre assouplie an de
permettre un maximum dutilisation de la bande passante.
Rgle TDCN 5 Lors de la dtection dune non-congestion dun tunnel,
le rgulateur doit augmenter sa CLA tout en respectant les quations sui-
vantes :
lim
t
congestion
+
CLA() = HLA (8.3)
max(CLA()) HLA, (8.4)
8.4 respect du critre dquit
Le fonctionnement dcrit prcdemment revient tablir une nou-
velle rgulation qui vient alors sajouter la rgulation standard ef-
fectue par les couches suprieures (TCP).La rgulation effectue au
niveau de chaque tunnel aura un comportement dpendant unique-
ment des congurations du tunnel et non de la nature des ux le
composant.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
8.5 critre de stabilit du systme 43
La mise en place de ces rgulateurs va alors utiliser la proprit
dlasticit du ux agrg mais restera indpendante de lagressivit
de ces ux. Il sera alors impossible pour un client dinuer sur le
partage en modiant par exemple son nombre de connexions TCP.
On pourra alors chercher tablir une quit indpendante de la
nature des ux mais relevant de la nature des contrats commerciaux
tablis avec tel ou tel client.
La mthode pressentie pour obtenir cette quit contractuelle consiste
agir de manire proportionnellement aux contrats. Ainsi lors dune
priode de congestion, un DAR disposant dun haut contrat LLA,
modiera son CLA dans une moindre mesure quun rgulateur dispo-
sant dun plus faible contrat LLA. Inversement lors dune priode de
non-congestion le tunnel disposant du meilleur contrat augmentera
plus vite sa limite CLA.
On peut donc imaginer un critre dquit dpendant par exemple
du rapport LLA/CLA et ainsi effectuer la proposition suivante :
Proposition TDCN 6 An de respecter le critre dquit, un rgulateur
doit respecter :
_
CLA
+
CLA
_
congestion
= f
_
LLA
CLA
_
(8.5)
et :
_
CLA
+
CLA
_
congestion
= g
_
CLA
LLA
_
(8.6)
avec :
:le temps discrtis la frquence de dtection des congestions,
f,g : des fonctions monotones croissantes positives.
Dautres propositions sont galement envisageables et permettraient
une convergence vers dautres critres dquit. Cependant, nous mon-
trerons par la suite quun certain nombre de contraintes seront
respecter notamment sur les fonctions drives an de ne pas rendre
le systme instable.
8.5 critre de stabilit du systme
Nous avons vu prcdemment que le systme va rduire ses limites
daccs lors dune congestion jusqu la suppression de celle-ci. Une
fois la congestion termine, le systme va pouvoir de nouveau largir
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
ses limites. Si la caractristique des ux na pas volu entre temps,
la congestion rapparatra. Cela signie que, dans le cas de prols de
ux entranant une priode de congestion longue, le systme oscillera
entre congestion et non congestion au niveau du coeur de rseau. Il
convient donc pour que lamplitude doscillation du systme soit faible
de respecter la rgle :
Rgle TDCN 7 La loi dvolution doit respecter linquation suivante :
lim
t
congestion
0
CLA
+
CLA
< (8.7)
avec : : terme en octets sufsament petit face au dbit des liaisons.
8.6 dtection de bande libre optimise
Lun des possibles effets sous optimal du systme repose sur son
temps de raction qui peut tre relativement lent notamment lors-
quun prol de dbit anciennement agressif devient passif. Lexemple
classique est un transfert fort dbit nissant pour un client qui pos-
sde un fort LLA. Le transfert une fois termin libre une part non
ngligeable de la bande passante de la liaison; les autres clients ne
peuvent alors lutiliser du fait des limitations dautorisations prsentes
sur leurs accs.
An dattnuer le phnomne, il convient dacclrer cette libration.
Une longue priode de non congestion devra se traduire par une sup-
pression des anciennes limites en accs. Pour tre efcace, le systme
devra respecter la proposition suivante :
Proposition TDCN 8 Pour tre efcace, le systme devra respecter :
lim
t
congestion
+
CLA
+
CLA
= + (8.8)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
8.7 rsum du systme 45
8.7 rsum du systme
Tunnels LSP
Notications de congestion sur
le tunnel
Rgulateur dynamique d'acces
Rseau des oprateurs virtuels
S
e
n
s

d
e

l
a

c
o
n
g
e
s
t
i
o
n
Figure 14: Principe du TDCN
Finalement, le systme propos repose sur lassociation dune signa-
lisation de coeur et dune rgulation daccs (gure 14). La complexit
du systme est principalement situe dans les mcanismes du DAR
et dans leurs interactions. Jusqu prsent un certain nombre de cri-
tres ont t retenus en premire approche mais non-dmontrs. Dans
le chapitre suivant nous nous focaliserons sur le fonctionnement du
systme et nous dmontrerons lintrt de celui-ci.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Quatrime partie
ETUDE THORI QUE DES PERFORMANCES
DU SYSTME TDCN
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9
MODLI SATI ON DU SYSTME TDCN
Le chapitre prcdent nous a permis de dnir une proposition
de mcanisme de rgulation. Nous allons maintenant nous attacher
raliser une modlisation de ce systme. Dans un premier temps
nous dtaillerons le fonctionnement dun rgulateur et nous propose-
rons une modlisation. Puis nous focaliserons notre attention sur les
interactions entre rgulateurs.
9.1 le rgulateur fractionnel
Ce rgulateur repose sur les principes dactions proportionnelles.
Cest dire que laction du rgulateur est dpendante des deux para-
mtres CLA et LLA. Par rapport TCP, la variation TDCN est une
chelle temporelle suprieure ( ?50 ms pour TCP, ?1sec pour TDCN)
et ainsi intervient en complment de celui-ci. Son action, dpendante
de la valeur des contrats, va progressivement permettre dtablir une
quit qui ne pourrait exister avec TCP seul. Lors dune phase de
congestion un rgulateur modulera son action proportionnellement
sa CLA courante, mais galement de manire inversement propor-
tionnelle sa LLA contractualise pour avantager ainsi les contrats les
plus forts.
Lors dune phase de non congestion le raisonnement inverse est
appliqu.
Dans la pratique, le dcrment en congestion est proportionnel au
rapport
CLA
LLA
et lincrment en non-congestion est proportionnel au
rapport
LLA
CLA
.
9.1.1 Evolution du rgulateur en congestion
En congestion, la valeur D du dcrment sera calcule grce la
formule D = A
CLA
LLA
o A est une constante exprime en bits par
secondes.
Pour le moment la valeur de la constante A est attribue arbitraire-
ment. Nous verrons par la suite que la valeur de cette constante peut
tre optimise. La gure 15 reprsente lvolution de la valeur de ce
49
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
50 modlisation du systme tdcn
CLA (Mb/s)
LLA (Mb/s)
Dcrment (b/s)
1000
0
500
80
20
10
40
Figure 15: Valeur du dcrement (A :15b/s)
dcrment en fonction des CLA et LLA. On observe ainsi dans le dia-
gramme en 3D qu CLA constant le plus faible contrats dcrmentera
plus vite et que pour un mme contrat le rgulateur la limite la plus
forte dcrmentera plus rapidement.
Durant une priode de congestion, on pourra dterminer lvolution
dun rgulateur grce la rgle rcursive suivante, comme le montre
la gure 16 :
CLA
+
= CLA

CLA
LLA
A (9.1)
9.1.2 Evolution du rgulateur en non-congestion
En non-congestion, la valeur I de lincrment sera calcule avec
la formule I = B
LLA
CLA
o B est une constante exprime en bits par
seconde. L encore, nous tudierons plus tard loptimisation de cette
constante. La gure 17 reprsente la valeur de cette incrment en
fonction du CLA et du LLA.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.1 le rgulateur fractionnel 51
Figure 16: Evolution au cours du temps de la CLA en congestion(A=100)
CLA (Mb/s)
LLA (Mb/s)
Incrment (b/s)
400
0
200
80
20
10
40
Figure 17: Valeur de lincrment (A :15b/s)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Durant cette priode, on pourra galement dterminer lvolution
du rgulateur grce la formule suivante, comme le montre la gure
18 :
CLA
+
= CLA
+
LLA
CLA
B (9.2)
Figure 18: Evolution au cours du temps du CLA en non-congestion (B=400)
9.2 mise en quations
9.2.1 Modlisation dun DAR
Lors dune priode de congestion un rgulateur agit comme une
suite. En effet, son fonctionnement rcursif justie ce type de modlisa-
tion. Le rgulateur rpond lquation 9.3 en congestion et lquation
9.4 en non-congestion.
CLA(t +1) = max(CLA(t) f(CLA(t)), LLA) (9.3)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.2 mise en quations 53
CLA(t +1) = min(CLA(t) +g(CLA(t)) , HLA) (9.4)
En temps normal la somme des CLA peut dpasser la capacit des
liaisons. En effet, la CLA reprsente la limite du dbit dun client mais
nest pas forcment atteinte.
Lorsquune liaison est congestionne, la somme des dbits clients
sera gale la capacit de la liaison. Le systme TDCN diminuera
lensemble des CLA, jusqu lobtention dune limitation des dbits.
On obtient alors une valeur E gale la somme des CLA.
Dans ces conditions, la congestion de coeur va perdurer tant que la
somme des CLA des tunnels est suprieure la valeur E. Ds quelle
passera en dessous, les ux ne pourront plus maintenir la congestion.
On remarquera toutefois que la valeur E peut tre gale la bande
passante dans le cas particulier o tous les clients utilisent des ux
lastiques susceptibles de prendre toute la bande passante.
Par consquent, pour une liaison de Dbit E compose de n tunnels,
on aura une congestion lorsque lquation 9.5 est respecte et une
non-congestion lorsque lquation 9.6 est respecte.
n
k=0
CLA
k
> E (9.5)
n
k=0
CLA
k
< E (9.6)
Lensemble des observations prcdentes repose sur un certain
nombre dhypothses :
le temps de transport de linformation de congestion est ngli-
geable face au dlai entre deux dcrments,
les rgulateurs agissent tous au mme rythme et leffet de leurs
dsynchronisations est ngligeable,
les ux lastiques agrgs occupent instantanment la bande pas-
sante disponible.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
On peut ainsi poser le systme suivant driv des conclusions de la
section :
CLA
k
t+1
= max
_
CLA
k
t
+f(CLA
k
t
, LLA
k
, HLA
k
), LLA
k
_
k et si :
m
k=0
CLA
k
t
E
CLA
k
t+1
= min
_
CLA
k
t
+g(CLA
k
t
, LLA
k
, HLA
k
), HLA
k
_
k et si :
m
k=0
CLA
k
t
> E
(9.7)
9.3 etude dun systme dar fractionnel
A partir du modle propos prcdemment, nous allons effectuer
une simulation mettant en vidence les diffrentes phases dune
congestion TDCN.
Nous considrons une liaison congestionne regroupant 3 tunnels
MPLS manags avec notre nouveau systme TDCN. La liaison possde
une capacit de 1 Gb/s. Les congurations TDCN sont identiques
pour chacun des tunnels (HLA=1 Gb/s LLA= 100 Mb/s). Grce la
modlisation que nous venons de raliser, nous pouvons prdire le
fonctionnement du systme lorsque lensemble des clients va essayer
de consommer les 1 Gb/s de donnes de la HLA.
La gure 19 est un exemple de lvolution de la CLA suite lappa-
rition de cette congestion. Chaque systme dispose de courbes propres
en fonction dune part du paramtrage des rgulateurs mais galement
en fonction des conditions initiales. Nous tudierons leurs impacts
respectifs dans un chapitre ultrieure. Cependant, dune manire g-
nrale, on retrouve trois phases distinctes suite lapparition dune
congestion dans un systme TDCN :
La zone de congestion : Cette zone apparat au dbut de la conges-
tion de coeur. Pendant cette priode, tous les rgulateurs dur-
cissent pas pas leurs politiques daccs an de supprimer cette
congestion. Une fois la congestion stoppe, le systme rentre dans
son deuxime tat.
La zone dquilibrage : Pendant cette priode, le systme oscille
entre un tat de congestion et un tat de non congestion. A lissue
de la phase prcdente, la CLA des rgulateurs sest positionne
dans un tat intermdiaire dpendant des congurations mais
galement des conditions initiales. Par la suite les rgulateurs
vont modier leur CLA en faisant varier leurs incrments et dcr-
ments pour nalement atteindre un tat stable indpendant des
conditions initiales.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.3 etude dun systme dar fractionnel 55
Z
o
n
e

d
e

C
o
n
g
e
s
t
i
o
n
Z
o
n
e

d
'
q
u
i
l
i
b
r
a
g
e
Z
o
n
e

d
'
q
u
i
t
temps en secondes (Echelle log)

C
L
A

e
n

b
/
s
Figure 19: Systme simple base de DAR fractionnels
La zone dquit : Il sagit du point de fonctionnement stable du
systme. Nous montrerons par la suite que cet tat correspond
lquit de partage de la bande passante entre les diffrents
tunnels. Cet tat se maintiendra tant que les ux lastiques lin-
trieur des tunnels rclameront de la bande passante. Au niveau
du lien prcdemment congestionn, celui-ci oscille maintenant
entre un tat de congestion de coeur et de non congestion. Nous
appellerons dans la suite cet tat : ltat de pseudo-congestion.
9.3.1 Etude de la priode de congestion
La dure de cette priode dpend de deux facteurs : le premier est
la "distance" entre les conditions initiales et le point dquilibre et le
second est le paramtre A du DAR.
Dautre part, plus la somme des HLA des rgulateurs dpassera la
bande passante des liaisons, plus les dlais pour couper une congestion
seront importants. Ainsi on dnira un taux dover-provisioning dune
liaison comme tant le rapport entre la somme des HLA des tunnels
et la bande passante de la liaison.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Dans tout les cas, il est intressant de noter quil est possible de
prdire le temps maximal que mettra le systme pour supprimer cette
congestion. En effet, pendant cette priode les performances rseaux
sont altres ; on observe un taux de drops important et une forte
augmentation de la latence.
Pour diminuer ce dlai, il faut augmenter la vitesse de dcrmen-
tation des DARs en augmentant le paramtre A (equa.9.1.1). Or nous
verrons par la suite que laugmentation de cette valeur peut entraner
des effets nfastes. Un compromis devra alors tre trouv.
Par contre, cette zone est caractrise par une succession de dcr-
ments. On peut ainsi amliorer la vitesse de convergence en conservant
en mmoire le nombre de dcrments successifs et en appliquant une
pnalit supplmentaire au dcrment et ainsi passer plus rapidement
ltape suivante dquilibrage.
9.3.2 Etude de la priode dquilibrage
Figure 20: Evolution de lincrment dun systme compos de 3 rgulateurs
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.3 etude dun systme dar fractionnel 57
Pendant cette priode, les rgulateurs basculent alternativement des
modes de congestion aux modes de non-congestion. Les diffrences
entre les incrments et les dcrments de chaque rgulateur vont
modier la manire dont seffectue le partage.
Lors de la phase prcdente, les rgulateurs vont diminuer leurs CLA
jusqu une valeur dpendante des conditions initiales. La pondration
tant fonction des CLA courantes, les dcalages vont se modier pour
tendre vers une valeur de dcalage unique et commune tous les
rgulateurs.
La gure 20 montre lvolution des incrments dun systme trois
rgulateurs. Le rsultat est lobtention dun point quilibre unique o
chaque rgulateur voluera selon le mme incrment et dcrment.
A noter que la valeur de lincrment et du dcrment nest pas
forcement identique. Dans le cas dune asymtrie, le systme restera
durant plusieurs pas conscutifs dans le mme tat avant de faire
une bascule. Ce phnomne est trs intressant car il permet ainsi
de conserver le systme en tat de non-congestion plus longtemps
entranant ainsi de meilleurs performances rseaux.
9.3.3 Etude de la priode dquit
La section prcdente nous permet de constater que tous les DARs
nissent par avoir un incrment moyen identique, ainsi quun dcr-
ment moyen identique. Ce rsultat va nous permettre de prvoir le
partage qui sera effectu entre les rgulateurs.
En effet, on peut poser les quations suivantes pour le ime rgula-
teur :
A
CLA
i
LLA
i
= D B
LLA
i
CLA
i
= I
CLA
i
=
DLLA
i
A
CLA
i
=
BLLA
i
I
(9.8)
Or nous savons galement que la somme des CLAs lors de de lquit
est gale la bande passante de la liaison congestionne (Bp) par
consquent on a :
n
i=0
CLA
i
= Bp
n
i=0
LLA
i
D
A
= Bp
n
i=0
LLA
i
B
I
= Bp
D
A
=
Bp
n
i=0
LLA
i
B
I
=
Bp
n
i=0
LLA
i
(9.9)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
On a alors pour chaque rgulateur le respect de lquation suivante :
CLA
i
= Bp
LLA
i
n
i=0
LLA
i
(9.10)
On peut en conclure que le partage en mode congestionn de la bande
passante est un partage barycentrique o la LLA fait ofce de poids.
La modlisation ralise dans ce chapitre, nous a permis de prdire
le fonctionnement du systme lors de lapparition dune congestion.
Jusqu prsent celle-ci nous a servi identier les trois phases symp-
tomatiques du systme.
Par la suite, nous utiliserons cette modlisation et les rsultats obte-
nus pour tablir et tester un systme exploitable dans un cas rel.
9.4 etude dune application base sur le tdcn
Le framework TDCN a de multiples faons dtre utilis et congur.
Le choix retenu dpendra notamment du modle commercial mais
galement des choix industriels et des paramtres que lon souhaitera
optimiser.
Dans ce chapitre, nous allons proposer une manire spcique de
congurer ce framework et nous montrerons toutes les garanties qui
en dcoulent.
9.4.1 Lapproche par mtaux prcieux
An de simplier les possibilits, nous proposerons dans ce chapitre
trois types de contrats standards proposs par les oprateurs : Gold,
Silver et Bronze. Contrairement aux offres actuelles, nous verrons que
les garanties fournies ne reposent pas sur des approches statistiques
mais sont bases sur le fonctionnement intrinsque du systme.
Exemple illustratif
An dillustrer ce cas pratique, nous allons nous focaliser sur une
liaison 1 Gb/s dans laquelle on situe :
10 contrats gold 10Mb/s,
60 contrats silver 10Mb/s,
100 contrats bronze 10Mb/s,
1 contrat gold 100Mb/s,
1 contrat silver 100Mb/s,
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.4 etude dune application base sur le tdcn 59
1 contrat gold 100Mb/s.
Le dbit des contrats se traduit directement dans le systme par la
valeur HLA des rgulateurs. On remarquera dans le cas prsent que la
somme des HLA est suprieure la capacit de la liaison. On a donc
un taux dunder-provisioning de 2. Dans cette situation, on considre
que nos clients nutilisent pas simultanment lensemble de leur bande
passante. Le contrat ne garantit de toute manire quune partie de
cette bande passante.
9.4.2 La conguration du systme TDCN
Conguration du LLA
Pour raliser la diffrentiation entre les diffrents types de contrats,
nous fournissons un LLA au prorata (not ) du contrat HLA. Ainsi,
les clients Gold auront 70% de leur trac garanti, les Silver 50 % et les
Bronze 20%.
Ainsi dans notre exemple illustratif, lensemble du dbit garanti
slve 710Mb/s. Ce qui correspond une liaison disposant pour le
trac garanti un taux dover-provisioning de 40%. On aura donc ici la
certitude de pouvoir fournir les dbits contractuels.
Dans cette approche, on dmontre dune part que mme le contrat
le plus bas dispose dune garantie, et dautre part que la valeur du
contrat reste modulable en fonction des besoins de chaque client.
Congurations des paramtres A et B
An de choisir la mthode de conguration des paramtres A et B,
nous tudions lvolution des CLA lors de lapparition dune conges-
tion dans notre exemple illustratif (section 9.4.1) avec des valeurs de
A et B gales 100 (g. 21). La gure 21 met en vidence que chaque
type de contrat dispose dune bande passante au prorata de sa HLA
et ce quelque soit la valeur de la HLA. Par contre, nous pouvons
observer que lquit est plus longue obtenir pour les contrats de
100Mb/s. An de palier cela, nous proposerons une valeur de A et B
au prorata (not ) du contrat HLA. Ainsi, une conguration de A et
B au 1/100 de la HLA donne le fonctionnement suivant (g. 22). Cette
modication permet lensemble des comportements des rgulateurs
dagir proportionnellement leurs propres HLA.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Figure 21: Evolution de la CLA dun systme descente constante(en % de la HLA)
Figure 22: Evolution de la CLA dun systme descente variable(en % de la HLA)
9.5 conclusion du chapitre
Les travaux effectus sur un cas pratique, nous ont permis de mettre
en vidence un certain nombre davantages du systme. Cependant,
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
9.5 conclusion du chapitre 61
cette tude temporelle ne permet pas dacter les choix optimaux des
constantes ou de certier son bon fonctionnement systmique.
Nous pouvons observer que le systme fournit tout moment un
CLA suprieur au contrat minimum mme lors de la phase de conges-
tion.
Dans le chapitre suivant, nous proposerons une tude par dia-
gramme de phase. Celle-ci nous permettra de proposer et valider
des mthodes de choix pour les diverses constantes du systme.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
10
ETUDE PAR DI AGRAMME DE PHASE DE LI AI SON
TDCN EN CONGESTI ON
Ltude temporelle du systme nous a permis prcdemment diden-
tier diffrentes phases de fonctionnement. Dans ce chapitre, nous
allons approfondir ltude de lvolution de ltat du systme en g-
nrant des indicateurs. Ceux-ci serviront par la suite de base de com-
paraison pour tudier limpact de paramtres tels que ltablissement
des constantes, les conditions initiales, le nombre de rgulateurs, la
varit des contrats,...
10.1 etude dun systme simple deux rgulateurs
10.1.1 Dnition du systme
Dans un premier temps, nous considrons un systme ne compre-
nant que deux rgulateurs. Nous gnraliserons ensuite la mthode
pour des systmes comprenant plus de rgulateurs. Ltude que nous
nous proposons de faire se base sur la cration de diagramme de phase.
Dans un premier temps nous dnissons le vecteur dtat. Celui-ci sera
logiquement le vecteur de dimension 2 compos des valeurs des deux
CLA de chaque rgulateur. On notera de faon gnrale le vecteur
dtat

C. Nous tendrons, par la suite, la notation vectorielle en notant
le vecteur

L le vecteur des LLAs et les vecteurs

A et

B seront les para-
mtres des rgulateurs (nous considrons les rgulateurs fractionnels
dcrits dans le chapitre 9.1). On a donc :
C
_
CLA
0
CLA
1
_
,

L
_
LLA
0
LLA
1
_
,

A
_
A
0
A
1
_
,

B
_
B
0
B
1
_
(10.1)
10.1.2 Diagramme de phase
A laide de la modlisation ralise dans le chapitre prcdent, on
peut raliser le diagramme de phase du systme. La gure 23 est un
exemple de ces diagrammes.
Lvolution du systme met en vidence les trois phases observes
lors de ltude temporelle savoir :
63
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
64 etude par diagramme de phase de liaison tdcn en congestion
CLA2 en Kb/s
C
L
A
1

e
n

K
b
/
s

C0 =
60 Mb s
60 Mb s

, L =
10 Mb s
20 Mb s

, A =
100Kb s
100Kb s

, B =
1Mb s
1Mb s

, D= 80Mb/ s
Figure 23: Diagrammes de phases dun systme 2 rgulateurs
La premire phase (appele prcdemment phase de congestion)
caractrise par une chute de lensemble des valeurs des CLAs,
une seconde phase (dit dquilibrage) o les valeurs CLA varient
fortement mais o la somme des CLA oscille autour dune valeur
E (Valeur de coupure de la congestion cf. 9.2.1) ,
une dernire phase (dite quilibre) o lensemble des CLA converge
autour dun point xe. Celui tant dtermin en fonction du vec-
teur

L et de la valeur E (Dmontr dans 9.3.3 ).
10.1.3 Test dindpendance aux conditions initiales
La reprsentation en diagramme de phase nous a permis dobserver
les trois phases de la convergence. Cependant, celui-ci a t ralis pour
une condition initiale particulire. On peut dor et dj sinterroger sur
limpact de ces conditions.
An de contrler le fonctionnement du systme, nous ralisons
le diagramme de phase de systmes identiques mais possdant des
conditions initiales sur le CLA diffrentes.
Le rsultat de ce test (Figure 24) met en vidence dune part que
le point dquilibre est invariant et dautre part on remarque que la
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
10.2 gnralisation aux systmes n rgulateurs 65
CLA2 (Kb/s)
C
L
A
1

(
K
b
/
s
)
Figure 24: Diagrammes de phases dun systme 2 rgulateurs diffrentes condi-
tion initial
phase dquilibrage de tous les systmes se trouve tre une oscillation
autour dune droite unique ayant pour quation 10.2 :
C(0) +C(1) = E (10.2)
10.2 gnralisation aux systmes n rgulateurs
10.2.1 Cas du systme 3 rgulateurs
An dtendre les observations effectues dans le systme deux
rgulateurs, nous allons poursuivre ltude par un systme de degr
trois. Celui-ci est dni par les vecteurs de lquation 10.3 :
C
_
_
_
CLA
0
CLA
1
CLA
2
_
_
_
,

L
_
_
_
LLA
0
LLA
1
LLA
2
_
_
_
,

A
_
_
_
A
0
A
1
A
2
_
_
_
,

B
_
_
_
B
0
B
1
B
2
_
_
_
(10.3)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9

C
1

C
2

C
3

C
i = D
Figure 25: Diagramme de phase de systmes 3 rgulateurs avec diffrentes condi-
tions initiales
Dans ce cas de gure (gure 25), on peut encore observer les trois
phases. De plus, on peut gnraliser lquation prcdente (equa. 10.2) :
n
i=0
CLA
i
= E
De la mme faon on peut vrier une nouvelle fois la vracit du
partage barycentrique ltat dquilibre.
10.2.2 Observation sur les systmes de dimension suprieure
Etude de la Notion de "distance"
Lobservation des diagrammes de phase ne peut tre effectue sur
les systmes de degrs suprieurs. Cependant, si nous connaissons la
valeur E, nous pouvons pr-calculer le point de convergence grce
lquation 9.10. A partir de l, nous pouvons dnir une fonction de
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
10.2 gnralisation aux systmes n rgulateurs 67

C
0
100Mb/ s
100Mb/ s
100Mb/ s

, L
10Mb/ s
20Mb/ s
30Mb/ s

, A
100b/ s
100b/ s
100b/ s

, B
100b/ s
100b/ s
100b/ s

, D= 80Mb/ s
Temps en secondes
D
i
s
t
a
n
c
e

e
n

K
b
/
s
Figure 26: Evolution de la distance de convergence dun systme
"distance" entre le point de fonctionnement observ au temps t et le
point de convergence. Cette fonction est dnie par lquation 10.4.
Distance(t) =
_
n
i=1
(C(t)
i
C
conv
i
)
2
(10.4)
Distance(t) =
_
n
i=1
(C
i
(t) E
LLA
i
n
i=1
LLA
i
)
2
(10.5)
Lintrt de cette fonction repose sur la possibilit de raliser un
graphique dvolution au cours du temps de tout systme quelque soit
sa dimension. Pour une reprsentation plus visuelle, nous effectuerons
un afchage logarithmique plus propice mettre en vidence les trois
phases du systme (gure 26).
traitement numrique et diagramme de synthse
An de faciliter les traitements numriques et la comprhension du
fonctionnement du systme tudi, nous effectuerons un lissage de la
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Dlai de convergence
Erreur de convergence

C
0
100Mb/ s
100Mb/ s
100Mb/ s

, L
10Mb/ s
20Mb/ s
30Mb/ s

, A
100b/ s
100b/ s
100b/ s

, B
100b/ s
100b/ s
100b/ s

, D= 80Mb/ s
Temps en seconde
D
i
s
t
a
n
c
e

e
n

k
b
/
s
Figure 27: Evolution de la distance fentre dun systme
courbe en ralisant une moyenne mobile. La courbe obtenue est alors
reprsentative dun systme dni par les paramtres L,A et B face
lvnement apparition dune congestion ayant pour dbit dquilibre
E avec comme condition initiale le vecteur tat instantan C
0
. Cette
courbe (gure 27) possde nalement deux caractristiques essentielles
pour notre systme :
Lerreur de convergence : reprsente par la distance entre laxe
et le minimum de la courbe.
Dlai de convergence : reprsent par le temps que le systme a
mis pour arriver 10% de son erreur de convergence minimale.
Par la suite, nous utiliserons ces indicateurs pour comparer lefca-
cit sur des systmes congurs diffremment.
10.3 analyse de liaison sur les systmes tdcn
10.3.1 Etude des effets des paramtres A et B
Lors de ltablissement dexemples, nous avons jusqu prsent
choisi les paramtres A et B de manire empirique. Grce aux rsultats
du chapitre prcdent, nous pouvons comparer lefcacit sur des
systmes congurs diffremment.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
10.3 analyse de liaison sur les systmes tdcn 69
A=100
A=500
A=1000
B=5
B=500
B=25
B=2500
B=50
B=5000
T
e
m
p
s

d
e

c
o
n
v
e
r
g
e
n
c
e

e
n

s
e
c
o
n
d
e
s
!
C
0
100Mb/ s
100Mb/ s
100Mb/ s
"
#
$
$
$
%
&
'
'
'
, L
10Mb/ s
20Mb/ s
30Mb/ s
"
#
$
$
$
%
&
'
'
'
, BW = 80Mb/ s
Figure 28: Evolution du systme en fonction des paramtres A et B
La gure 28 reprsente un systme identique avec des valeurs A et
B variantes. On peut constater que la prcision de la convergence est
directement corrle avec ces valeurs. Ainsi, plus A et B possdent
des valeur levs, plus le systme converge rapidement par contre
lerreur de convergence va galement crotre. On a donc un compromis
trouver pour la valeur du couple de paramtres A et B an dobtenir
une convergence satisfaisante dans un temps raisonnable.
10.3.2 Effet du nombre de rgulateurs
Un des questionnements que peut susciter notre systme est la
possibilit que possde une liaison de supporter un nombre variable
de rgulateurs. An dvaluer cette capacit, nous allons effectuer une
comparaison entre des liaisons de mme dbit mais possdant un
nombre N diffrent de rgulateurs. Pour pouvoir les comparer, nous
poserons les hypothses suivantes :
Dans un systme, tous les rgulateurs sont identiques (mme LLA,
mme HLA),
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Erreur
en Kb/s
Dlai
en sec
Degr du systme
Figure 29: Comparaison de systme quivalent de degr N
chaque systme dbutera la congestion avec son CLA gal son
HLA,
an de pouvoir comparer les systmes, la distance initiale entre le
point de convergence et le point de fonctionnement sera la mme
pour tous les systmes,
la somme des LLA sera la mme quelque soit le systme,
les valeurs de A et B seront proportionnelles au LLA,
la liaison considre aura un dbit identique quelque soit le sys-
tme.
De ces conditions on en dduit facilement les valeurs LLA, A, B en
fonction du nombre de rgulateurs N :
LLA
i
=
N
i=1
LLA
i
N
A
i
=
A
0
N
B
i
=
B
0
N
La valeur du CLA initiale peut galement tre dduite en fonction
de la distance initiale D
0
, de la bande passante W et de N :
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
D
2
0
=
N
_
CLAW
LLA
N
LLA
_
2
D
2
0
= N
_
CLA
W
N
_
2
CLA =
W
N
+
D
0
N
On peut alors comparer les performances de systmes degrs
diffrents. La gure 29 montre un exemple de la variation du nombre
de rgulateur sur une liaison de 1Gb/s avec une somme de LLA
500Mb/s et un facteur dunder-provisioning 1,1. On peut observer
que ce systme est capable de sadapter avec des performances compa-
rables indpendamment du nombre de rgulateurs (de 11 contrats
100Mb/s 550 contrats 2Mb/s).
10.3.3 Etude de la dispersion des CLAs
Lors de ltablissement des contrats, il est possible de provision-
ner une partie plus ou moins garantie de LLA. On peut se poser la
question limpact dune forte disparit entre les diffrents contrats.
An dvaluer les effets, une simulation est effectue sur une liaison
1Gb/s disposant de 50 contrats avec un taux dunder-provisioning
de 50% pour le non-garanti (2Gb/s non-garanti) et un facteur Over-
provisioning de 2 galement pour le garanti (500Mb/s garanti). An
de les comparer, nous tablissons laide dun gnrateur gaussien
diffrents CLA avec un cart-type dni. Nous avons simul ainsi
la congestion an dobserver le dlai de convergence. Nous avons
rpliqu ce test 50 fois an dobtenir le dlai moyen de convergence
en fonction de lcart-type. La gure 30 reprsente lvolution du dlai
de convergence en fonction de lcart-type des CLA des tunnels.
On remarque que plus il y a une dispersion importante du CLA plus
le systme met du temps converger. Cette observation nous conforte
dans le fait dutiliser des rapports HLA/LLA xe (chapitre 9.4.2).
Ce chapitre nous a permis de valider ltendu des systmes pos-
sibles. Nous avons pu montrer que pour un systme donn, les perfor-
mances attendues sont prdictibles et optimisables travers le choix
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Ecart-Type en b/s
D
l
a
i

e
n

s
e
c
o
n
d
e
s
Figure 30: Effet de la dispersion des CLA
des constantes. Les rsultats obtenus pourront tre utiliss pour dnir
des garanties contractuelles ainsi que des rgles de provisioning et de
topologies.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Cinquime partie
ETUDE EXPRI MENTALE DU SYSTME
TDCN
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11
PRSENTATI ON DE LA PLATE- FORME DE TESTS
Ltude thorique prcdente a mis en vidence de multiples intrts
mettre en oeuvre notre systme. Cependant, lensemble des rsultats
obtenus repose sur une modlisation thorique. Lors de ltablissement
du modle, nous avons d poser des hypothses et effectuer des
simplications. Dans le cadre de la validation du modle, nous avons
ralis une maquette an de vrier la pertinence des hypothses
prises. Dautre part son second objectif est dapporter des informations
sur la qualit de service qui na pas t modlise.
11.1 la plate-forme de tests
Gnrateurs de connexions TCP/
UDP
Client A Client B
Systme de Mtrologie/Asservissement
Rgulateurs
d'accs
Client C
Rgulateurs
d'accs
Figure 31: Schma du testbed
Lobjectif de la plate-forme est de retrouver lensemble minimal des
composants permettant la mise en oeuvre du systme TDCN. Lenvi-
ronnement dun WAN est mul an de retrouver les comportements
TDCN identique celui que lon aurait dans le cadre dun dploiement
de la technologie. On retrouvera galement les gnrateurs ncessaires
75
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
76 prsentation de la plate-forme de tests
ltablissement des ux reprsentatifs des agrgats rels. Enn la
maquette reposera galement sur la mise en place dun systme de
mtrologie le plus complet possible.
An dobserver le systme en phase de congestion, la maquette se
compose de trois routeurs : un point de congestion est alors cr sur
le routeur central an de simuler une saturation de coeur de rseau.
An de raliser cette congestion, nous effectuons une limitation du
dbit dmission sur linterface de sortie du routeur de coeur (limite
80Mb/s).
11.2 cration de lenvironnement de tests
11.2.1 le gnrateur dagrgats
Figure 32: Gnrateur de session NetworkTester
Le systme TDCN est conu pour tre dploy dans un rseau de
transport mutualis. An de retrouver les comportements de ux
clients et plus particulirement les proprits dlasticit des ux, nous
utilisons un gnrateur industriel de sessions TCP.
Lquipement utilis est un gnrateur NetworkTester de la socit
Agilent. Celui-ci permet dmuler des applications bases entre autre
sur TCP. Nous avons plus particulirement utilis ses capacits
muler des sessions clients/serveurs FTP. Notre but tait uniquement
de proter des capacits TCP et de contrler le nombre de connexions
TCP simultanes. Ce nombre de session tant lun des principaux
paramtres inuenant le partage de la bande passante, nous pouvons
ainsi tudier le comportement du systme TDCN dans diffrentes
conditions de rgimes.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11.3 implmentation du systme tdcn 77
11.2.2 Lmulateur WAN
Lenvironnement dun rseau transport mutualis est bien diffrent
de celui retrouv dans un laboratoire. An de reproduire les effets
de cet environnement, nous utilisons un mulateur. Celui-ci a pour
principal objectif de recrer une latence dans le rseau an que les
comportements des sessions TCP soient plus reprsentatifs de la ralit.
Nous avons donc utilis un serveur Windows ddi disposant du
programme NetDisturb edit par Omnicor an de rhausser la latence
du rseau. Nos tests ont t effectus avec un dlai rseau de 20ms.
11.3 implmentation du systme tdcn
11.3.1 Les routeurs
Figure 33: Routeur 7450 ESS1
La ralisation de notre maquette a t effectue avec des routeurs de
coeurs Alcatel-Lucent. Le choix sest port sur lutilisation de routeurs
industriel dont nous connaissions parfaitement le dimensionnement
de la capacit de commutation ainsi que celle de ses diffrentes cartes
porteuses. Ces routeurs disposent galement dune stack MPLS com-
plte incluant la gestion des VPN. Ils possdent galement la capacit
pour les ports daccs au VPN de grer prs de 16000 les dattentes
diffrentes et autant de QoS daccs. Ce qui le rend particulirement
intressant pour notre systme qui prvoit lutilisation de rgulateur
ddi chaque tunnel.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11.3.2 Description de larchitecture VPN
PPVPN
P
O
R
T
S
D
P
PPVPN
D
e
M
u
x
D
e
M
u
x
S
D
P
S
A
P
P
O
R
T
S
A
P
Police d'accs
Police d'accs
Figure 34: Architecture Gnrique dun VPN
Dans le cadre de leur utilisation normale, les routeurs cloisonnent
leur clients dans des services VPN diffrents. Chaque service VPN (g.
34) de ces routeurs est compos de plusieurs lments :
Service Access Point (SAP) : Entit rattache un port ou un
VLAN daccs. On peut lui appliquer une politique particulire
de qualit de service.
Service Distribution Point (SDP) :Entre du tunnel MPLS . Il a
pour charge dmettre les paquets dans le rseau. Il peut possder
des rgles de ltrage spcique en fonction de la nature des ux.
Demux : Il rcupre les paquets des tunnels MPLS. Traite les
informations MPLS et les retourne dans le service PPVPN en
correspondance.
Sap-ingress policy : Police daccs des SAP. Rserve un espace
mmoire pour le SAP. Gre la colorie par le biais dun TRTCM
[17]. Le mme mcanisme existe galement en sortie de SAP (Sap-
egress policy).
Notre Systme TDCN utilisera cette architecture, un service TDCN
sera un VPN point point disposant de polices daccs spciques.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11.3 implmentation du systme tdcn 79
11.3.3 Lemulateur TDCN
Etant donn que les routeurs ne supportent pas nativement notre
nouveau systme exprimental, nous avons t contraint dexternaliser
sur un serveur Linux les briques ncessaires la mise en oeuvre de
notre systme TDCN. Trois composants sont ajouts :
Des contrleurs de congestion dans les routeurs de coeur chargs
de dtecter une ventuelle congestion.
Un protocole de signalisation des congestions.
Des rgulateurs daccs dynamiques prenant en compte les infor-
mations transmises par le protocole de signalisation.
Pour ce faire, nous avons utilis des automates logiciels qui inter-
rogent et contrlent les routeurs sur un rseau de management ddi.
Ceux-ci rcuprent les informations et modient le comportement du
routeur par le biais du protocole SNMP. Ce fonctionnement entrane
toutefois une moins grande ractivit. Nous verrons par la suite quelle
peut tre limpact de cette mthode sur les rsultats.
Les contrleurs de congestion
Le contrleur de congestion est situ au niveau de chaque port
de coeur de rseau. Il contrle en permanence ltat des buffeurs. Il
retransmet ensuite linformation de cet tat toutes les secondes au
protocole de transport dinformation.
En thorie, il faut contrler ltat des buffeurs Egress de linterface
qui se rempliront dans le cadre de la congestion de la liaison mais
galement les buffeurs Ingress des interfaces qui eux se rempliront
lorsquune congestion du coeur de commutation apparat. Dans la
pratique, la capacit de commutation maximum de nos routeurs nest
pas sous dimensionne, et cette congestion ne peut pas apparatre.
Implmentation des DAR
An de raliser les DARs, nous avons utilis des TRTCMs [17] inclus
au niveau des Sap Ingress policy des routeurs. Nous avons ensuite
pilot via le protocole SNMP la valeur du PIR de celui-ci. Ainsi, le CLA
de notre systme correspond la valeur courante du PIR du TRTCM.
Le LLA est lui reprsent par le CIR du rgulateur.
En thorie, ces TRTCM devraient tre appliques au niveau de policy
appliqus sur les SDP. Cependant, cette conguration nest pas faisable
matriellement do sa mise en oeuvre sur le SAP. Cette modication
nentrane aucune consquence dans le cadre dun VPN point point.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Par contre, elle empcherait lutilisation de VPN multipoints. Dans le
cadre de lindustrialisation du procd, il conviendrait de disposer les
mcanismes sur le SDP.
Le protocole de transport dinformation
Lajout ou la modication dun protocole au niveau des routeurs
implique ncessairement un recodage de celui-ci. Aussi nous avons
choisi dmuler le comportement du protocole. Nous avons co-localis
les programmes des contrleurs de congestion et des DARs sur le
serveur GNU/Linux avec une transmission dinformations par le biais
de variables partages. Pour autant, les divers codes sont dsynchroni-
ss tout comme ils le seraient si leurs codes taient inclus dans leurs
routeurs respectifs.
11.3.4 Dfaut de lexternalisation du code
Figure 35: Variation du temps entre les passes algorithmiques
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11.4 mtrologie de la plate-forme de tests 81
Du fait de lutilisation dun OS non temps rel et galement
cause des dlais sur le rseau de management, les DAR nagissent pas
toutes les secondes prcisment. La gure 35 montrent un exemple de
variation de dlai entre 2 passes de lalgorithme. Ces courbes devraient
en thorie tre des droites constantes 1 seconde. Cette variation serait
largement attnue si le code tait inclu directement dans les routeurs.
11.4 mtrologie de la plate-forme de tests
11.4.1 Mtrique du routeur
Le routeur dispose pour chacun des ports des informations sui-
vantes : compteurs doctets, de paquets et de drops. Ces compteurs
sont rafrachis toutes les secondes. Mais, il est galement possible de
connatre ltat des buffeurs des ports daccs et de coeurs (g. 36)
pour chaque le dattente.
Port de coeur de rseau
Etat du buffeur egress de la
classe de service BE
Figure 36: Commande show pool sur un routeur ESS1
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
An de suivre lvolution de ces informations, des automates dinter-
rogations ont t raliss pour nous permettre de mesurer lvolution
de ces valeurs. Contrairement aux autres compteurs, linterrogation de
ltat des buffers prend entre 400 et 600ms et donne une information
sur un tat instantan.
La gure 37 est un exemple dvolution dun buffeur suite lappa-
rition dune congestion de coeur.
Figure 37: Evolution dun buffeur egress sur un port en coeur dun routeur dispo-
sant dune liaison congestionne
11.4.2 Le gnrateur de dbit
An de mesurer les performances des systmes mis en place, nous
avons utilis un gnrateur de trac N2X de la marque Agilent. Cet
quipement gnre des paquets IP auxquels il ajoute un timestamps
dhorloge dans la payload. A laide dun second port, il rcupre ces
paquets et peut ainsi mesurer la latence, la gigue, le taux de pertes, les
dsordonnancements, le tout avec une prcision de 7 picosecondes.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
11.4 mtrologie de la plate-forme de tests 83
Figure 38: Gnrateur de dbit N2X
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12
TESTBED DU SYSTME TDCN
Le chapitre prcdent nous a permis dexposer le fonctionnement
de la plate-forme de test mettant en oeuvre lapproche TDCN. Dans
ce chapitre nous allons utiliser cette plate-forme pour valider la mo-
dlisation effectue et mesurer les performances rseaux du nouveau
systme.
12.1 comparaison entre les rsultats de la maquette et
de la modlisation
Courbes thoriques Courbes pratiques
Figure 39: Comparaison entre les rsultats sur la maquette et dans la modlisation
Ltablissement de la modlisation des chapitres prcdents a t
ralise sur la base des principes thoriques issue des mcanismes
mis en oeuvre. La complexit des ux rels et les simplications que
85
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
86 testbed du systme tdcn
nous avons d oprer pour tablir le modle, nous amnent vrier
ladquation entre notre approche thorique et une mise en oeuvre
pratique.
Pour ce faire, nous avons tudi lvolution des CLA des rgula-
teurs du systme TDCN dans le cadre de notre plate-forme de test ;
puis nous allons comparer ces rsultats face lestimation de cette
volution via la modlisation. Dans une premire approche, nous ne
nous focaliserons pas sur les dbits rels prsents dans chaque VPN
mais uniquement sur lvolution des rgulateurs. Nous positionnerons
simplement sufsamment de connexions TCP en concurrence pour
initier une congestion.
La gure 39 compare les rsultats thoriques et pratiques dans le
cadre de deux systmes paramtrs diffremment. On constate sur le
graphique que les rsultats de la modlisation, bien que plus lisss
que ceux mesurs en pratique, donnent une bonne estimation de
lvolution relle des CLA.
Ce lissage sexplique facilement par le fait que la modlisation
considre tort une action simultane de tous les rgulateurs. Leffet
de la dsynchronisation se traduit par une variation plus importante
des CLA. Par contre, le dlai dquilibrage est lgrement survalu
dans le cadre de la modlisation.
12.2 tude des flux
12.2.1 Fonctionnement en rgime tabli
Nous avons prcdemment valid le bon comportement des rgu-
lateurs. Nous allons maintenant nous attacher vrier lvolution
des ux rels inclus dans ces tunnels. Nous utiliserons pour ce faire le
systme de mtrologie dni dans le chapitre prcdent pour tudier
lvolution des dbits clients.
Lexemple prsent dans la gure 40 a t ralis sur la base de trois
tunnels TDCN dans lesquels chaque client utilise des connexions TCP
simultanes. Dans lexemple retenu, le premier client a t congur
pour excuter 30 connexions TCP simultanes. Les deux autres clients
ont t congurs pour excuter chacun cinq connexions TCP.
Dans une premire tape, Nous avons mesur lutilisation de la
bande passante pour chaque client dans un rseau classique Best-effort
sans mis en place de notre systme. Dans un second temps, nous avons
ritr les mmes mesures avec notre rseau TDCN.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12.2 tude des flux 87
Client LLA: 8Mb/s
and 30 TCP connections
Client LLA: 16Mb/s
Client LLA: 8Mb/s
Best-effort Network TDCN Network
Figure 40: Evolution du trac client dans un rseau BE et TDCN
On peut remarquer que dans le rseau classique le partage est
effectu au prorata du nombre de connexions TCP. De nombreuses
tudes donnent aussi le mme type de rsultat [24], et dcrivent les
mcanismes de partage du rseau. Ils soulignent en particulier la
dpendance entre la notion de partage et la quantit de connexions
TCP.
Cette situation est particulirement gnante pour un oprateur,
puisque des clients disposant de contrats identiques ne pourront pas
revendiquer la mme bande passante. Un client dit "non-citoyen" pour-
rait dans certains cas de gure tre tent daugmenter virtuellement
son nombre de connexions TCP an de rcuprer plus de bande pas-
sante au dtriment des autres clients.
Le systme TDCN a justement t conu pour empcher la nature
des ux dinuer sur le partage de la bande passante. La gure 40 met
bien en vidence cette nouvelle indpendance aux ux. En outre, la
bande passante est partage proportionnellement au paramtrage des
LLA des rgulateurs. La gure 41 montre que tous les clients ont des
taux de LLA CLA identiques, ce qui signie que la bande passante
supplmentaire a t quitablement rpartie entre les diffrents clients,
indpendamment du nombre de connexions TCP.
Dans la pratique, les ux clients sont contraints individuellement
par les limitations donnes par les rgulateurs DAR. Il nexiste alors
aucune possibilit pour les clients de se substituer cette limite.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Client LLA:8Mb/s TCP : 30 connexions
Client LLA: 8Mb/s TCP : 5 connexions
Client LLA: 16Mb/s TCP : 5 connexions
Figure 41: Evolution du rapport LLA/CLA des rgulateurs dans le rseau TDCN
12.2.2 Etude en phase dquilibrage
Nous avons vu prcdemment par le biais de la modlisation que
notre systme possde une phase transitoire au niveau des rgulateurs.
Dans cette partie, nous focaliserons notre attention sur lvolution des
tracs clients durant cette priode. An de contrler lvolution lors de
cette phase, nous allons initier une congestion dans le coeur de rseau
en tablissant simultanment les tracs clients. La conguration mise
en oeuvre est reprise du test effectu dans le chapitre prcdent. Au
cours de lessai, nous avons tudi le dbit utilis pour chaque client
(gure 42). Dans le mme temps, lvolution des valeurs CLA a t
enregistre pour chaque rgulateur. (Figure 43).
A linitialisation de la congestion, nous observons que tous les
tracs se partagent la bande passante de la liaison. Ce partage de
bande passante est similaire celui qui aurait eu lieu dans un rseau
classique best-effort(voir gure 40).
Par la suite les rgulateurs vont agir face cette congestion en
durcissant leur politique daccs. Le trac, prcdemment le plus
favoris par le partage best-effort, sera le premier impact et devra
rduire son utilisation de la bande passante. Dans le mme temps,
la bande passante libre sera ralloue entre les autres clients qui
navaient pas atteint leurs limites.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12.2 tude des flux 89
Client with 30 TCP connections
and LLA: 8Mb/s
and LLA: 16Mb/s
and LLA: 8Mb/s
Figure 42: Evolution du trac client en phase transitoire
Regulator with LLA: 16Mb/s
Figure 43: Evolution du CLA des clients en phase transitoire
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
On constate galement que les ux TCP subissant le durcissement de
politique des DAR ne rompent pas leurs connexions et suivent la pente
donne par le rgulateur. Ce comportement est rendu possible car
lchelle de temps de la variation des rgulateurs est signicativement
suprieure celle des connexions TCP (facteur 100).
12.3 tude des performances globales
12.3.1 Evaluation des performances par client
Les rsultats prcdents ont mis en vidence la capacit de notre sys-
tme fournir une quit contractuelle lors dune priode de conges-
tion aprs une phase transitoire. Dans cette partie nous allons tudier
les performances qui dcoulent de ce fonctionnement dans un cas
extrme ou la garantie contractuelle est inversement proportionnelle
au nombre de connexions des ux clients.
Lexprimentation suivante se compose de sept tunnels TDCN mis
en concurrence, chaque client disposant dun nombre diffrent de
connexions TCP. Chaque connexion TCP effectue le tlchargement
dun chier de 5 Mo, une fois la connexion termine une nouvelle
connexion est rtablie (18 fois pour chaque connexion).
Nous mesurons le temps pour naliser lensemble des tlchar-
gements pour chaque client et nous calculons ainsi le dbit moyen
obtenu en pratique par client. Nous effectuons lexprience dans le
cadre dun rseau classique BE puis dans le cadre de notre proposition
darchitecture.
Les rsultats obtenus sont synthtiss dans le tableau 1. Ce test dure
quelques minutes. An dtudier lvolution plus long terme de
la performance, un deuxime test a t ralis, fond sur le mme
paramtrage except pour le nombre de tlchargements quon ritre
200 fois. Lexprience dure alors plus dune heure.
Nous pouvons observer dans le tableau 1, que tous les clients ne sont
pas en mesure de respecter le contrat minimum LLA. Ce phnomne
sexplique par le fait que pendant la phase de transition, le partage
de la bande-passante est effectu au pro-rata des connexions TCP. Il
sagit donc dun partage diamtralement oppos celui souhait dans
ce cas particulier. Toutefois, mme dans ce cas exagrment ngatif,
les rsultats sont bien meilleurs que pour le rseau Best-effort (le
client dispose dun dbit trois fois suprieur celui quil aurait eu en
Best-effort).
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12.3 tude des performances globales 91
Table 1: Performance par client pour 18 tlchargements successifs
Customers LLA Concurrent
TCP
connec-
tions
Duration
TDCN
Average
TDCN
rate
Average
BE rate
1 14Mb/s 1 101 s 7,1Mb/s 2,4Mb/s
2 12Mb/s 2 132 s 10,9Mb/s 4,7Mb/s
3 10Mb/s 3 170 s 12,7Mb/s 7,1Mb/s
4 8Mb/s 4 210 s 13,7Mb/s 9,4Mb/s
5 6Mb/s 5 250 s 14,4Mb/s 11,8Mb/s
6 4Mb/s 6 280 s 15,4Mb/s 14,2Mb/s
7 2Mb/s 7 345 s 14,6Mb/s 16,5Mb/s
Table 2: Performance par client pour 200 tlchargements successifs
Customers LLA Concurrent
TCP
connec-
tions
Duration
TDCN
Average
TDCN
rate
Average
BE rate
1 14Mb/s 1 555 s 14,4Mb/s 2,4Mb/s
2 12Mb/s 2 1025 s 15,6Mb/s 4,8Mb/s
3 10Mb/s 3 1485 s 16,2Mb/s 7,2Mb/s
4 8Mb/s 4 2005 s 16,0Mb/s 9,4Mb/s
5 6Mb/s 5 2480 s 16,1Mb/s 12,1Mb/s
6 4Mb/s 6 3185 s 15,1Mb/s 14,5Mb/s
7 2Mb/s 7 3485 s 16,1Mb/s 16,9Mb/s
On peut remarquer galement que, mme sans tenir compte des
contraintes lie au LLA, six des sept clients ont un dbit moyen su-
prieur celui quils auraient obtenu dans un rseau Best Effort. Ce
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
phnomne sexplique par le fait quune fois le tlchargement dun
client termin, la bande passante libre est redistribue aux clients
qui nont pas encore ni leurs tlchargements. Ainsi on peut consi-
drer que, si les demandes de bande passante dun client sont en
quantit nie, le systme nobre pas le rendement du rseau. Son
fonctionnement se traduit par un rordonnancement dans le temps
des demandes clientes.
Ce test met en avant un certain nombre davantages de notre sys-
tme :
Tout dabord, mme dans le cas le plus ngatif o le nombre de
connexions TCP est inversement proportionnel aux contrats du
client, le partage reste extrmement avantageux pour les contrats
les plus importants.
Si on considre que les demandes des clients ne sont pas innies,
les contrats les plus bas ne sont pas trop impacts.
12.3.2 Mesures des performances globales du systme
Nous allons utilis les rsultats des tests prcdents an dvaluer la
performance globale de notre rseau. En fait, un rseau parfait devrait
tre en mesure de transporter tous les tracs la bande passante du
goulot dtranglement. Le dlai le plus court pour effectuer lensemble
des tlchargements pourrait tre dtermin par la formule suivante :
Time
Perfect
=
18 (5MB/s 8) 28Connections
76Mb/s
= 265s (12.1)
Ainsi la performance globale du systme peut tre mesure par le
rapport entre le dlai pour terminer lensemble des tlchargements et
le dlai du systme parfait :
R
system
=
Time
Measure
Time
Perfect
(12.2)
Nous observons que le nouveau systme est moins efcace quun
rseau Best-effort principalement pour le premier jeu de donnes. La
cause principale de cette perte defcacit repose sur le dlai ncessaire
pour redistribuer la bande passante libre par un client. Le premier
test met en exergue ce phnomne. Nous pouvons voir un exemple
pratique de cet vnement sur la gure 44.
Dans cette exemple, les clients librent soudainement lensemble
de leur trac entranant ainsi une phase temporaire o lensemble
de la bande passante nest pas utilise dans le coeur du rseau. Ce
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12.4 etude de la qualit de service 93
Bandwidth not use
Bandwidth use by clients
Global Bandwidth Use
Figure 44: Exemple de dlai pour rallouer la bande passante
phnomne dans le cas de ux agrgs na que trs peu de chance de
ce produire. Notre systme est donc mieux conu dans le cadre de
partage entre ux agrgs.
12.4 etude de la qualit de service
Nos tudes ont mis en vidence les capacits en terme de gestion
de la bande passante du systme. Cependant il reste analyser les
Table 3: Estimation de la performance global du systme
System Productivity
Best-Effort rst set 87%
TDCN rst set 77%
Best-Effort second set 89%
TDCN second set 85%
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Figure 45: Evolution du buffer dun rseau Best-effort en congestion
performances qualitatives des ux transports, plus particulirement
pendant la phase de congestion. Ces performances sont alors directe-
ment lies lvolution des buffers des routeurs.
12.4.1 tude de lvolution des buffers
Dans un rseau Best Effort standard, la priode de congestion en-
trane une bufferisation au niveau du goulot dtranglement (gure
45). Le niveau dencombrement du buffer dpend alors de diffrents
paramtres dont le prol des ux clients (nombres de connexions TCP,
dbit UDP,...), mais galement de certains paramtres des routeurs par
exemple le mcanisme RED [4],[25].
Dans notre rseau TDCN on peut noter que le prol de bufferisation
(gure 46)est trs diffrent. Dans la phase transitoire, on retrouve un
prol analogue celui quon observerait sur un rseau Best Effort avec
toutefois une diffrence notoire : les ux les plus agressifs subissent
une deuxime bufferisation (moins importante) dans le buffer daccs
du rgulateur. Cette seconde bufferisation est une consquence directe
du durcissement de la limite CLA.
Par contre, une fois la priode dquilibrage atteinte, le prol de
bufferisation change compltement. Vu du ux TCP, la bufferisation
bascule constamment entre une prsence en coeur de rseau et une
prsence au niveau du rgulateur du routeur daccs. Il sagit dun
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
12.4 etude de la qualit de service 95
Figure 46: Evolution of buffers in TDCN network
attribut trs intressant parce que la congestion prsente au niveau
du buffer daccs est bien moins consquente quen coeur. En fait, la
congestion prsente en coeur est due laggressivit de lensemble des
ux TCP passant sur le lien en congestion, par contre en accs seules
les connexions TCP du client participent lvolution du buffer. Ce
phnomne se traduit directement sur la latence des ux clients qui
est infrieure celle quelle aurait eu dans un rseau Best-effort. Notre
systme transforme ainsi une congestion de K clients en K congestions
rparties sur lensemble du rseau.
12.4.2 Effet du systme sur les tracs UDP
Jusqu prsent nos tudes se sont focalises sur des ux TCP. Dans
cette partie, nous contrlerons limpact sur les tracs UDP. Lvolution
de la charge des buffers dans le cadre de notre systme, entrane
diffrents effets sur le trac UDP.
Nous avons ralis un test en injectant un trac UDP instrument
avec le gnrateur N2X. Ce test a t effectu avec un trac UDP en
Constante Bite Rate (3750 fps avec des paquets de 100 octets) inject
dans chaque tunnel client. La gure 47 montre lvolution de la latence
et des pertes de paquets de ces tracs. Le systme est compos de trois
clients :
le premier dispose de 30 connexions TCP,
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
les deux autres disposent de 5 connexions chacun.
C
o
n
g
e
s
t
i
o
n

p
e
r
i
o
d
S
t
a
b
i
l
i
z
a
t
i
o
n

p
e
r
i
o
d
C
A
B
Figure 47: Evolution de la latence et des pertes de paquets des ux UDP dans un
rseau TDCN
Nous observons sur la gure 47 trois phnomnes remarquables :
point A : Pendant la phase transitoire du systme, la latence des
ux UDP est la mme que celle qui aurait t obtenue dans un
rseau Best Effort. Dans notre exemple, cette latence est de 120
ms.
point B : Dans le mme temps, on observe des pertes sur les
paquets UDP. Ces pertes sont dues dune part au mcanisme
RED mis en place dans le coeur de rseau et dautre part au
durcissement de la politique daccs des rgulateurs DAR. A noter
que seuls les ux les plus agressifs subissent cette deuxime cause
(ici le client qui dispose de 30 connexions TCP).
point C : Durant la phase de stabilisation, du fait du passage tem-
poraire en congestion de coeur, la latence des ux UDP augmente
temporairement. On peut remarquer que cette augmentation de
latence se produit priodiquement et reste infrieure une buffe-
risation observe en congestion classique de coeur (25ms contre
120ms). Hors de cette priode, la latence est similaire celle dun
rseau non-congestionn.
Finalement, une fois la priode de stabilisation atteinte, notre sys-
tme dispose dune distribution de latence atypique car base sur deux
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Figure 48: Distribution de la latence pour les ux UDP dans un rseau TDCN
bufferisations successives. En effet, loscillation entre la congestion de
coeur et daccs entrane une variation de la latence des paquets. La
gure 48 montre cette distribution de la latence. On peut noter que
cette gigue nentrane aucun dsordonnancement des paquets. Il est
par ailleurs possible de modier cette distribution en jouant sur les
paramtres de monte et de descente des rgulateurs. Par exemple, si
le paramtre de monte est beaucoup plus lent que celui de descente,
le systme restera en congestion daccs plus longtemps quen conges-
tion de coeur et donc nous aurons une latence globale plus faible. et
en tout cas infrieur celle une congestion de coeur.
La plate-forme de test nous a permis de confronter les rsultats
thoriques avec les mesures pratiques. Les doutes sur dventuelles
interactions entre la rgulation effectue par TCP et la sur-rgulation
TDCN ont ainsi pu tre levs. De plus, nous avons mis en vidence
de nouvelles proprits intressantes de notre systme comme par
exemple, le nouvel tat de quasi-congestion cr par le mcanisme
TDCN qui apporte une utilisation presque maximale de la bande
passante tout en conservant une latence trs faible.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Sixime partie
CONCLUSI ON
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
13
CONCLUSI ON
Dans ce mmoire de thse, nous avons prsents nos travaux orients
sur la problmatique de mutualisation de ressources dans le cadre
de rseau doprateurs de transport mutualis. Cette problmatique
rsulte dune volont antagoniste de fournir dune part un maximum
de bande passante chaque client et dautre part de disposer dune
qualit et dune disponibilit maximales sur lensemble du rseau.
En effet, la demande de bande passante est en constante augmen-
tation. De plus lavnement des accs FTTH (Fiber To The Home)
pour lInternet, la 3G pour la tlphonie mobile, et de la vido haute
dnition entrane une pression supplmentaire sur les cots. Les
oprateurs cherchent alors en limiter les rpercutions sur les utili-
sateurs en optimisant leurs infrastructures. Les travaux de recherche
se focalisent alors sur loptimisation des coeurs de rseaux an den
limiter le surdimensionnement habituel.
Dans le cadre dune recherche de rponse cette problmatique,
nous avons tout dabord montr les possibilits offertes par les m-
thodes de provisioning. Celles-ci sattachent modier les chemins
des ux pour maximiser lutilisation du coeur de rseau. Malgr tout
ces approches reposent sur une vision macroscopique des ux. Dans
un second temps, nous avons tudi les approches historiques grant
le partage de la bande passante entre les session TCP. Celles-ci se
focalisent sur lobtention dune quit protocolaire entre les diverses
sessions. On peut parler dune vision microscopique des ux.
A partir de ces tudes, nous avons mis en vidence la ncessit de
transmettre la gestion de lquit des protocoles internes loprateur
de linfrastructure pour permettre une gestion plus approfondie du
provisioning rseau.
Nous avons ainsi tabli une nouvelle approche appele TDCN qui
permet de relier ces deux approches. Notre proposition a pour ob-
jectif de transmettre le partage de la bande passante au niveau des
paramtres des tunnels donnant ainsi le contrle de la congestion
loprateur de linfrastructure. Le design modulaire du systme per-
met de nombreux paramtrages en fonction de la politique de chaque
oprateur.
101
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
102 conclusion
Par le biais dune modlisation, nous avons dmontr le fonction-
nement du systme. Nous avons propos galement une mthode
permettant dvaluer lefcacit du mcanisme en fonction du para-
mtrage du systme. Nous avons tabli ainsi un sous-systme bas
sur la terminologie des contrats actuels doprateurs permettant une
industrialisation.
Une plate-forme de test a permis de valider notre modle en dmon-
trant le bon fonctionnement du systme propos dans un cadre rel
et en mettant en vidence les intrts majeurs en terme de qualit de
service.
Le systme a t tudi pour fournir une garantie de dbit pour un
service transitant au niveau dun AS. Des perspectives de recherche
apparaissent alors : il serait intressant dtudier la possibilit de four-
nir une qualit de service de bout en bout en protant des garanties
locales, limage des travaux qui furent raliss pour pouvoir fournir
une qualit Intserv en traversant des domaines Diffserv ([26]).
Dautre part, ltude par diagrammes dtats a mis en vidence une
phase dquilibrage caractristique. Il serait alors possible dacclrer
grandement celle-ci par le biais dune prdiction du point dquilibre.
On pourrait ainsi rajouter des informations de feed-back au niveau
protocolaire pour ainsi calculer une estimation de la prdiction du
point dquilibre.
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Septime partie
ANNEXE
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
105
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
106 annexe
A
ANNEXE
a.1 code scilab de la modlisation tdcn
Listing A.1: Modelisation Scilab

function [CLA2]=tdcn(CLA,LLA,A,B,BW)
if sum(CLA)>=BW then
CLA2=CLA-A.
*
(CLA./LLA)
else
CLA2=CLA+B.
*
(LLA./CLA)
end
endfunction
function [POINT]=Calc
_
Convergence(LLA,D)
POINT=LLA/sum(LLA).
*
D;
endfunction
function [DIST]=distance(MATRICE,POINT)
Size=size(MATRICE);
MPTS=ones(Size(1),1)
*
POINT;
CARRE=(MATRICE-MPTS).^2;
DIST=sqrt(sum(CARRE, c ));
endfunction
function create
_
Trace(FILE
_
TRACE,M,N)
unix("rm "+ FILE
_
TRACE)
u=file( open,FILE
_
TRACE);
if M==0 then
write(u,CLA);
end
for i =1:N,
CLA=tdcn(CLA,LLA,A,B,BW);
if i>=M then
write(u,CLA);
end
end
file( close ,u);
endfunction

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
A.1 code scilab de la modlisation tdcn 107
Listing A.2: Fonction dafchage graphique

function Graph
_
Dist(MATRICE,DEBUT,POINT,COLOR)
xtitle("Distances au point de convergence a partir de t="+
string(DEBUT),"temps en seconde","Distance(en Kb/s ) ");
SIZE=size(MATRICE);
DISTANCES=distance(MATRICE(DEBUT:SIZE(1),:),POINT);
X=size(DISTANCES);
X=1:1:X(1);
plot2d (X,DISTANCES,style=COLOR);
endfunction
function Graph
_
Dist
_
log(MATRICE,DEBUT,POINT,COLOR)
SIZE=size(MATRICE)
X=size(DISTANCES);
X=1:1:X(1);
plot2d(X,DISTANCES,style=COLOR,logflag=" nl ");
endfunction
function [R]=fenetre(M,F);
Size=size(M);
for i =1:Size(1),
if i<F then
R(i)=sum(M(1:i))/i;
else
R(i)=sum(M((i-F+1):i))/F;
end
end
endfunction
function Graph
_
Dist
_
Moy
_
log(MATRICE,DEBUT,POINT,FEN,COLOR)
SIZE=size(MATRICE);
DIST
_
F=fenetre(DISTANCES,FEN);
X=size(DISTANCES);
X=1:1:X(1);
plot2d(X,DIST
_
F,style=COLOR,logflag=" nl ");
endfunction
function [REP]= normal
_
inv(DER,SUM,DEG)
MOY=SUM/DEG;
REP=grand(1,DEG-1, nor ,MOY,DER);
REP=[REP SUM-sum(REP)];
endfunction

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
108 annexe
Listing A.3: Fonction sur les diagrammes de phase

function Graph
_
phase(MATRICE,DEBUT,COLOR)
xtitle("Diagramme de phase a partir de t="+string(DEBUT),"CLA2
(en Kb/s ) ","CLA1(en Kb/s ) ");
plot2d(MATRICE(:,1),MATRICE(:,2),style=COLOR);
endfunction
function [R]=Espace
_
phase
_
G2(MATRICE,P,taille)
D=distance(MATRICE,P);
DF=fenetre(D,taille);
ERR=min(DF);
R=1.1
*
ERR;
i=1;
while DF(i)>R do i=i+1; end
TPS=i;
R =[ERR TPS];
endfunction
function [R]=Espace
_
phase
_
G(MATRICE,P)
D=distance(MATRICE,P);
ERR=min(D);
i=1;
while D(i)>ERR do i=i+1; end
TPS=i;
R =[ERR TPS];
endfunction

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Listing A.4: Diagramme de distance simple

CLA=[100000 100000 100000];
LLA=[30000 20000 10000];
A=[100 100 100];
B=[100 100 100];
BW=80000;
xbasc();
xtitle("Diagramme de Distance","Temps en sec","Distance en kb/s");
k=10;
n=1;
color=2;
WIN=20;
create
_
Trace( theorique . dat ,n,2500);
M=read( theorique . dat ,-1,3);
P=Calc
_
Convergence(LLA,BW);
Graph
_
Dist
_
log(M,n,P,color);
Graph
_
Dist
_
Moy
_
log(M,n,P,WIN,color+1);

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
110 annexe
Listing A.5: Etat du TDCN en fonction de A et B

CLA=[100000 100000 100000];
LLA=[10000 20000 30000];
BW=80000;
xbasc();
xtitle("Diagramme","Erreur de convergence en Kb/s","Delai de convergence
en seconde");
n=2;
Duree=2000;
for i = list(100,500,1000,2000),
m=1;
for j=i/20:i/10:5
*
i,
A=ones(1,3)
*
j;
B=ones(1,3)
*
i;
create
_
Trace( theorique . dat ,n,Duree);
M=read( theorique . dat ,-1,3);
P=Calc
_
D=Espace
_
phase
_
G2(M,P,100);
if D(2)< (Duree-200) then
if D(1)<4000 then
if m>2 then
C=[C;D];
else
C=D;
m=m+1;
end
end
end
end
plot2d(C(:,1),C(:,2),style=n)
n=n+1;
clear C;
end

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
Listing A.6: Etat du TDCN en fonction du degr

D0=100000;
C0=100000;
L0=500000;
A0=10000;
B0=10000;
BW=1000000;
xbasc();
n=1;
m=1;
h=1;
Duree=1100;
for i = 10:50:610,
m=m+1;
CLA=ones(1,i)
*
D0/sqrt(i)+BW/i;
LLA=ones(1,i)
*
L0/i;
A=ones(1,i)
*
A0/i;
B=ones(1,i)
*
B0/i;
create
_
Trace( theorique . dat ,n,Duree);
M=read( theorique . dat ,-1,i);
P=Calc
_
D=Espace
_
phase
_
G2(M,P,300);
if D(1)<4000 then
if h>1 then
C=[C;i,D];
else
C=[i,D];
h=h+1;
end
end
end
xtitle("Erreur de convergence en fonction du degre ","degre du systeme",
"Delai de convergence en seconde");
plot2d(C(:,1),C(:,2),style=3);

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
112 annexe
Listing A.7: Etat du TDCN en fonction de la dispersion des
CLA

degre=50;
BW=1000000;
somhla=2000000;
somlla=500000;
LLA=ones(1,degre)
*
somlla/degre;
m=1;
h=2;
xbasc();
xtitle("Delai en fonction de l ecarttype","Ecarttype des CLAs en Kb/
s","Delai de convergenceen seconde");
for ecart =2000:1000:15000,
m=m+1;
clear D;
nb=1;
for rep =1:1:20,
CLA=normal
_
inv(ecart,somhla-somlla,degre)+LLA;
A=ones(1,degre)
*
somlla/degre/100;
B=ones(1,degre)
*
somlla/degre/100;
create
_
Trace( theorique . dat ,1,3000);
M=read( theorique . dat ,-1,degre);
P=Calc
_
if isdef( D) then
E=Espace
_
phase
_
G2(M,P,100);
if E(1)<10000 then
D=(D.
*
nb+E)./(nb+1);
nb=nb+1;
end
else
E=Espace
_
phase
_
G2(M,P,100);
if E(1)<10000 then
D=E;
end
end
end
if h>2 then
C=[C;ecart,D];
else
C=[ecart,D];
h=h+1;
end
plot2d(C(:,1),C(:,3),style=3);

t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
PUBLI CATI ONS
Les travaux raliss pendant ma thse ont donn lieu aux publica-
tions suivantes :
olivier ferveur. procd de gestion dun rseau de transmission de
type mpls. brevet franais dpos linpi le 28 avril 2008 sous
le n08 02392.
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. proposi-
tion dune nouvelle rgulation daccs au coeur de rseau des oprateurs
dinfrastructure de communication. 5me confrence internationale
francophone dautomatique, cifa2008, roumanie (2008)
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. new sha-
ring access regulation for cores network. 11th ieee singapore inter-
national conference on communication systems, iccs 2008, guangz-
hou (2008).
olivier ferveur, e. gnaedinger, f. lepage and r. kopp. new qua-
lity of service policy for wholesale approach. in process. ieee/acm tran-
sactions on networking.
113
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
BI BLI OGRAPHI E
[1] Network Working Group Praveen Muley Internet Draft Mustapha Ais-
saoui Expires : August 2008 Matthew Bocci Pranjal Kumar Dutta,
2009. (Cited on page 13.)
[2] Network Working Group Y. Kamite, Ed. Internet-Draft Y. Wada Ex-
pires : September 7, 2006 NTT Communications Y. Serbest AT&T,
[3] L. Andersson and T. Madsen. Provider Provisioned Virtual Private
Network (VPN) Terminology. RFC 4026 (Informational), March
2005. URL http://www.ietf.org/rfc/rfc4026.txt. (Cited on
page 14.)
[4] Guido Appenzeller, Isaac Keslassy, and Nick McKeown. Sizing
router buffers. SIGCOMM Comput. Commun. Rev., 34(4) :281292,
2004. (Cited on pages 40 and 94.)
[5] Ron Banner and Ariel Orda. Multipath routing algorithms for
congestion minimization. IEEE/ACM Trans. Netw., 15(2) :413424,
2007. ISSN 1063-6692. doi : http://dx.doi.org/10.1109/TNET.
2007.892850. (Cited on page 27.)
[6] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
An Architecture for Differentiated Service. RFC 2475 (Informatio-
nal), December 1998. URL http://www.ietf.org/rfc/rfc2475.
txt. Updated by RFC 3260. (Cited on page 30.)
[7] M. Bocci, I. Cowburn, and J. Guillet. Network high availability
for ethernet services using IP/MPLS networks. Communications
Magazine, IEEE, 46(3) :9096, 2008. (Cited on page 13.)
[8] A. Bosco, R. Mameli, E. Manconi, and F. Ubaldi. Edge distributed
admission control in MPLS networks. Communications Letters,
IEEE, 7(2) :8890, 2003. (Cited on page 27.)
[9] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Es-
trin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson,
115
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
116 bibliographie
K. Ramakrishnan, S. Shenker, J. Wroclawski, and L. Zhang. Re-
commendations on Queue Management and Congestion Avoi-
dance in the Internet. RFC 2309 (Informational), April 1998. URL
http://www.ietf.org/rfc/rfc2309.txt. (Cited on page 29.)
[10] B. Briscoe. Flow rate fairness : dismantling a religion. ACM
SIGCOMM Computer Communication Review, 37(2) :6374, 2007.
(Cited on page 34.)
[11] K. Chan, R. Sahita, S. Hahn, and K. McCloghrie. Differentiated
Services Quality of Service Policy Information Base. RFC 3317
(Informational), March 2003. URL http://www.ietf.org/rfc/
rfc3317.txt. (Cited on page 39.)
[12] C.N. Chuah. A Scalable Framework for IP-network Resource Pro-
visioning Through Aggregation and Hierarchical Control. Compu-
ter Science Division, University of California, 2001. (Cited on
page 25.)
[13] Clark D. and Wroclawski J. An Approach to Service Allocation in the
Internet. IETF Draft Report, Massachusetts Institute of Technology,
July 1997. (Cited on page 30.)
[14] J. de Rezende. Assured service evaluation. In IEEE Globecomm99,
Rio de Janeiro, Brazil, December 1999. URL citeseer.ist.psu.
edu/derezende99assured.html. (Cited on page 31.)
[15] C. Fraleigh, F. Tobagi, and C. Diot. Provisioning IP backbone
networks to support latency sensitive trafc. In INFOCOM 2003.
Twenty-Second Annual Joint Conference of the IEEE Computer and
Communications Societies. IEEE, volume 1, 2003. (Cited on page 26.)
[16] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, and A. Malis. A
Framework for IP Based Virtual Private Networks. RFC 2764
(Informational), February 2000. URL http://www.ietf.org/rfc/
rfc2764.txt. (Cited on page 14.)
[17] J. Heinanen and R. Guerin. A Two Rate Three Color Marker. RFC
2698 (Informational), September 1999. URL http://www.ietf.
org/rfc/rfc2698.txt. (Cited on pages 78 and 79.)
[18] T. Ikeda, S. Sampei, and N. Morinaga. TDMA-based adaptive
modulation with dynamic channel assignment forhigh-capacity
communication systems. Vehicular Technology, IEEE Transactions
on, 49(2) :404412, 2000. (Cited on pages 17 and 28.)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
bibliographie 117
[19] Dina Katabi, Mark Handley, and Charlie Rohrs. Internet conges-
tion control for future high bandwidth-delay product environ-
ments. In SIGCOMM 02 : Proceedings of the 2002 conference on Ap-
plications, technologies, architectures, and protocols for computer com-
munications, pages 89102, New York, NY, USA, 2002. ACM. ISBN
1-58113-570-X. (Cited on page 32.)
[20] M. Kodialam and TV Lakshman. Dynamic routing of resto-
rable bandwidth-guaranteed tunnels using aggregated network
resource usage information. IEEE/ACM Transactions on Networ-
king (TON), 11(3) :399410, 2003. (Cited on page 27.)
[21] S. Khler and A. Binzenhfer. MPLS trafc engineering in OSPF
networks-a combined approach. In Proceedings of ITC, volume 18,
[22] K. Kompella and J. Lang. Procedures for Modifying the Resource
reSerVation Protocol (RSVP). RFC 3936 (Best Current Practice), Oc-
tober 2004. URL http://www.ietf.org/rfc/rfc3936.txt. (Cited
on page 40.)
[23] M. Lasserre and V. Kompella. Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling. RFC 4762
(Proposed Standard), January 2007. URL http://www.ietf.org/
rfc/rfc4762.txt. (Cited on page 14.)
[24] Wei Lin, Rong Zheng, and Jennifer C. Hou. How to make as-
sured service more assured. In ICNP 99 : Proceedings of the Se-
venth Annual International Conference on Network Protocols, page
182, Washington, DC, USA, 1999. IEEE Computer Society. ISBN
0-7695-0412-4. (Cited on page 87.)
[25] Liu Zhen Malouch Naceur. Rr-4469 - performance evaluation of
rio routers. Technical report, INRIA, Juin 2002. (Cited on pages 31
and 94.)
[26] Zoubir Mammeri. Framework for parameter mapping to
provide end-to-end qos guarantees in intserv/diffserv ar-
chitectures. Computer Communications, 28(9) :1074 1092,
2005. ISSN 0140-3664. doi : DOI:10.1016/j.comcom.2005.01.
008. URL http://www.sciencedirect.com/science/article/
B6TYP-4FC8SSS-1/2/f444e082b7a1cf66757715f9988fc099. (Ci-
ted on page 102.)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
118 bibliographie
[27] P. Marbach. Priority service and max-min fairness. In INFOCOM
2002. Twenty-First Annual Joint Conference of the IEEE Computer and
Communications Societies. Proceedings. IEEE, volume 1, 2002. (Cited
on page 30.)
[28] A. Markopoulou, G. Iannaccone, S. Bhattacharyya, C. Chuah, and
C Diot. Characterization of failures in an ip backbone. IEEE
INFOCOM, 2004. (Cited on page 27.)
[29] Petter Mosebekk. A linux implementation and analysis of the eXplicit
Control Protocol (XCP). PhD thesis, University of Oslo, May 2005.
(Cited on page 34.)
[30] K. Papagiannaki, R. Cruz, and C. Diot. Network performance
monitoring at small time scales. In Proceedings of the 3rd ACM SIG-
COMM conference on Internet measurement, pages 295300. ACM
New York, NY, USA, 2003. (Cited on page 26.)
[31] P. Pongpaibool. Characteristics of Internet Trafc in Thai-
land, 2006. URL http://internet.nectec.or.th/document/pdf/
20060329ECTI2006
_
panita.pdf. (Cited on page 26.)
[32] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit
Congestion Notication (ECN) to IP. RFC 3168 (Proposed Stan-
dard), September 2001. URL http://www.ietf.org/rfc/rfc3168.
txt. (Cited on page 31.)
[33] N. Seddigh, B. Nandy, and P. Pieda. Bandwidth Assurance Issues
for TCP Flows in a Differentiated Services Network. IEEE Globe-
comm99, Rio de Janeiro, Brazil, 1999. URL citeseer.ist.psu.
edu/seddigh99bandwidth.html. (Cited on page 31.)
[34] P. Sousa, M. Rocha, M. Rio, and P. Cortez. Au-
tomatic provisioning of QoS aware OSPF congurations,
2007. URL http://repositorium.sdum.uminho.pt/dspace/
bitstream/1822/6619/1/jnw02020110
_
pns.pdf. (Cited on
page 26.)
[35] P. Tinnakornsrisuphap and AM Makowski. Limit behavior of
ECN/RED gateways under a large number of TCP ows. In
INFOCOM 2003. Twenty-Second Annual Joint Conference of the IEEE
Computer and Communications Societies. IEEE, volume 2. (Cited on
page 31.)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9
bibliographie 119
[36] P. Trimintzios, I. Andrikopoulos, G. Pavlou, C. Cavalcanti, D. Go-
deris, Y. TJoens, P. Georgatsos, L. Georgiadis, D. Grifn, C. Jac-
quenet, et al. An Architectural Framework for Providing QoS in
IP Differentiated Services Networks. In 7th IFIP/IEEE Internatio-
nal Symposium on Integrated Network Management (IM 2001), 2001.
(Cited on page 25.)
[37] Christo Wilson, Chris Coakley, and Ben Y. Zhao. Fairness attacks
in the explicit control protocol. Quality of Service, 2007 Fifteenth
IEEE International Workshop on, pages 2128, June 2007. ISSN
1548-615X. (Cited on page 34.)
[38] O. Younis and S. Fahmy. Constraint-Based Routing in the Inter-
net : Basic Principles and Recent Research. IEEE Communications
Surveys and Tutorials, 5(1) :213, 2003. (Cited on page 27.)
t
e
l
-
0
0
4
1
8
0
2
6
,

v
e
r
s
i
o
n

1

-

1
7

S
e
p

2
0
0
9

Optimisation Des Architectures IPMPLS de Treansport Mutualisé

Transféré par

Informations du document

Titre original

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

Droits d'auteur :

Formats disponibles

Optimisation Des Architectures IPMPLS de Treansport Mutualisé

Transféré par

Droits d'auteur :

Formats disponibles

UFR ESSTIN

cole Doctorale IAEM Lorraine

temps en secondes (Echelle log)

Vous aimerez peut-être aussi