Implémentation d'un plan de contrôle unifié pour les réseaux multicouches IP/DWDM

(1)

IMPLÉMENTATION

D

'

UN

PLAN

DE CONTRÔLE UNIFIÉ POUR LES

RÉSEAUX

MULTICOUCHES

IP

/

DWDM

RAPPORT

DE PROJET

PRÉSENTÉ

COMME EXIGENCE PARTIELLE

DE LA

MAÎTRISE EN GÉNIE ÉLECTRIQUE

PAR

KARIM IDOUDI

(2)

Service des bibliothèques

Avertissement

L

a diffusion de ce mémoire se fait dans le respect des droits de son auteur

,

qui a signé

le

formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles

supérieurs (SDU-522- Rév

.

01-2006)

.

Cette autorisation stipule que

«conformément

à

l'

article 11 du Règlement no 8 des études de cycles supérieurs

,

[l

'

auteur] concède

à

l

'

Université du Québec

à

Montréal une licence non exclusive d

'

utilisation et de

p

ublication de la totalité ou d

'

une partie importante de [son] travail de recherche pour

des

fins pédagogiques et non commerciales

.

Plus précisément, [l'auteur] autorise

l'

Université du Québec à

Montréal à

reproduire

,

diffuser, prêter, distribuer ou vendre des

c

opies de [son]

travail

de recherche

à

des fins non commerciales sur quelque support

que ce soit

,

y compris l

'

Internet. Cette licence et cette autorisation n

'

entraînent pas une

renonciation de [la] part [de l'auteur]

à

[ses] droits moraux ni

à

[ses] droits de propriété

intellectuelle

.

Sauf entente contraire

,

[l

'

auteur] conserve la liberté de diffuser et de

commercialiser ou non ce travail dont [il] possède un exemplaire

.»

(3)

IMPLEMENTATION

OF A UNIFIED CONTROL PLANE FOR MULTILAYER NETWORKS

IP/

DWDM

MASTER THESIS

PRESENTED

AS A PARTIAL REQUIREMENT

FOR THE MASTER IN

ELECTRICAL ENGINEERING

BY

KARIM IDOUDI

(4)

Je

tiens à exprimer

ma

gratitude et

mes respects

les

plus

sincères à

mon

encadrante

,

Pro-fesseur Halima Elbi

aze,

pour l'aide qu'elle

a

bien

voulu

m

'acc

order

tout au

long des différentes

étapes

de mes

travaux

de r

ec

herche

,

moyennant

ses critiques constructives, ses suggestions

pertinentes, je m

'incline

par-devant

ses

qualités humaines

et

morales dont

j

'é

tais

touj

ours

im-pressionné

, sa

volonté permanente d

'ai

der

et ses

idées innovantes qui m

'

ont permis d

'

élaborer

m

es

travaux

de recherches

.

Son

attit

ude

rigoureuse m

'a

doté

d

'

une meilleure clairvoyance

quant

à mon avenir

professionnel.

Je

voudrais souligner

la qualité des moyens informatiques

et logistiques

mis

à

la

disposition

des

chercheurs

du

laboratoire

«

Üptical Transport

Network

Laboratory»

de l'UQAM et l'app

ui

financier du

CRSNG

mis

en œuvre

par Professeur I

-

Ialima Elbiaze

.

D

'

autre

part,

je voudr

ais exprimer

ma reconnaissance

à

tous

ceux

qui m

'

ont aidé durant

mes

travaux

de maîtrise

et

à

tous

les enseignants tout au long

de mon parcours

académique.

Je

remercie mes

parents

pour

leur

soutien tout

a

u long

de

mes

études

,

notamm

ent

ma

mère,

la grandiose

Baya pour

son amour et son engagement inconditionnel.

J

'es

père qu'elle

(5)

Actuellement,

l

es co

u

ches

IP

et optiques sont exploitées séparément

,

sans

in

teraction

dynamique;

ce

qui

entraîne

des

coûts

d'exploitation

é

l

evés

, une faible

efficacité

du

réseau,

et

une

l

o

n

g

u

e

latence du provisionnement des

c

h

emi

n

s

de bout

e

n

bo

ut

.

Cette séparat

i

on est

due

essentielle

m

ent aux

différences des

m

éca

ni

s

m

es

de

contrô

l

e

pour

ces

d

eux

domaines. Par

conséq

u

e

nt

,

l

'

un

des plus

grands

d

éfis

des

opérate

ur

s

réseaux

d

'a

ujourd

'

hui

est

l

a

r

éa

li

sat

ion

d'un

pl

a

n

de contrôle

unifi

é (UCP (Unified

Control Plane)) pour

gérer

l

es

d

etL"'<

réseaux

s

imult

a

n

éme

nt

.

Pour r

épond

r

e

à

ce

défi

, nous proposons dans

ce

projet

d

eux so

lution

s

pour impl

émente

r

un UCP qui permet d'assurer

un

e

in

teract

i

o

n

dynamique

e

n

tre

les réseaux optiques

multi-couches

IP

/

DWDM. La première

solut

i

on est

une

extension

du protocole OpenFlow,

l

'un

des

impl

émentations

SDN

(Software

Defined

etworking)

la

plus utilisée

a

uj

o

urd

'h

ui

.

Dans

ce

rapport, nous présentons les

diff

érentes

modifications

r

éal

is

ées et

l

es

modules implémentés

afi

n

que

ce

protocole réponde

à

no

s

besoins.

L

a

d

eux

i

è

m

e so

l

uti

o

n

est

basée sur l'utilisation

du

protocole GMPLS (Generalized Multi-Protocol

L

a

b

e

l

Switching)

dont l

'

impl

é

m

e

nt

at

ion

reste

co

mpl

exe

à

ca

u

se

du nombr

e

imp

ortant

d

es é

quip

e

m

e

nts r

ésea

u

qui

ne

sont pas

e

ncor

e

compatibles

avec ce

protocole. Ce rapport montre

l

'adaptat

ion d

e cette

technologie

avec

nos

éq

uip

ements

r

éseaux, s

itu

és

dans notr

e

l

a

bor

ato

ir

e

d

e

r

ec

h

e

rch

e.

D

'

un

e

part,

l

a

validation

et

la

faisabilité

d

es

d

e

ux

so

lution

s

impl

éme

nt

ées

ont

été éval

u

és

e

n u

ti

li

sant

notre banc d'

essai

.

D

'a

utr

e

part,

l

es

performances

d

es

deux solutions ont

été com

-parées quantitativement

e

n u

ti

lisant un

e s

imul

at

i

o

n

sur

deux topologies de réseaux

r

ée

ll

es.

(6)

Currently,

IP

and optical

layers

operate separately

without dynamic interaction

which

leads to high

operational cost

, low network efficiency, and

long processing latency for

end-to

end

path provisioning.

This

separation

is due primarily

to the

differences in

control

mecha-nisms for

these two

areas.

Therefore,

one of the biggest challenges facing network operators

today is the realization of a

unified

control plane (UCP) to

manage both networks

simulta-neously.

To meet this challenge,

we propose in

this

project

two solutions to

implement

a

UCP

which

ens

ures

a

dynamic interaction between multilayer optical

networks IP

/

DWDM. The

first

so

lution

is

an extension

of OpenFlow

protocol,

one of the

widely used SDN (Software

Defined

Networking)

implementations.

In this report, we present

the various changes

made

and

implemented modules so

that this protocol

meets our needs. The

second solution is

based

on the

use of GMPLS

(Generalized

Multi-Protocol Label Switching) protoco

l whose

implementation is

complex

due to the

large number of

network equipments that are not

yet

compat

ible with this

protocol. This report

explains the adaptation

of this technology with

our network

equipments

located in our research laboratory.

The validation and feasibility of two solutions implemented were evaluated using our

test-bed. On the other hand,

the performance of the two solutions were

compared quantitatively

using

a simulation on two real network

topologies.

(7)

RÉSUMÉ

ABSTRACT

TABLE DES FIGURES

LISTE DES TABLEAUX

NOMENCLATURE .

INTRODUCTION

CHAPITRE I

CADRE THÉORIQUE .

1.1 Introduction

..

.

..

.

1.2 Réseaux IP et

réseaux de transport .

1.2.1 Réseaux

IP

.

1.2.2 Réseaux de transport

1.3 OpenFlow

.

1.3.1 SDN

.

1.3.2 Concepts d

'OpenFlow

1.3.3 Distinction entre le

plan de contrôle et

le plan de données

1.3.4 Composants d

'un réseau OpenFlow.

1.3.5 Switch OpenFlow

. . .

.

. . . . .

1.3.5.1 Tables

OpenFlow.

1.3.5.2 Actions d'OpenFlow

1.3.5.3 Canal sécurisé

1.3 .6 Contrôleur OpenFlow

1.3.7 Protocole OpenFlow

.

1.3.7.1 Messages du protocole OpenFlow

.

1.3.7.2 Connexion entre le

contrôleur et la switch

.

1.4 GMPLS .

1.4.1 Origines

.

iv v

ix

xi

xii 1 5

5

7

10

11

12

13

14

15

18

19

20

(8)

1.

4 .2

Opération de

GMPLS

1.4.3 Routage GMPLS

1.4.3.1 OSPF

-T

E

.

1 .4.4 S

i

g

n

a

li

sat

i

o

n

GMPLS

.

1.4 .4.

1 RSVP-TE.

1.4.5 Conclusion

CHAPITRE II

20

21

22

22 PREMIÈRE SOLUTION:

EXTENSION DU PROTOCOLE OPENFLOW

23

2.1 In

t

rodu

ct

ion

23 2.2 État

d

e

l

'a

rt

23

2.3 Pourquoi Op

e

nFl

ow?

24

2.4 Op

e

nFlow

Optica

l

Agent

25

2 .

5 P

ath Computation Element (PCE)

25

2 .5.

1 Executor

.

. .

26

2 .

5.2 ONS Adapter

.

28 2.6 Expériences

. . .

.

28

2.6.1 Ca

dr

e emp

iriqu

e

28 2.6.2 Scénar

i

o A

: Établissement

d

'

un li

g

h

tpat

h

28 2.6.3 Scénario

B

: Restauration

du ligh

tpat

h

.

30 2.7 Concl

u

sion ..

CHAPITRE III

DEUXIÈME SOLUTION : GMPLS

3.1 Introdu

ct

ion

3.2 État de

l

'art

3.3 DRAGON

..

3.3.1 In

trod

u

ction

3.3.2 Composants du plan de

cont

r

ô

l

e

DRAGON

3.3.2.1 CSA

(Client System Agent)

.

3 .

3.2.2 VLSR

(Virtua

l

L

abe

l

Switch Ro

u

te

r)

3.3.2.3 NARB

(Netwo

rk

Aware Resource

Br

o

k

er)

3.4 Test du software DRAGON

avec

un

comm

u

tate

ur

Ethernet commerc

i

a

l

3

1

32

33

34

35

(9)

3.4.1 Scénario 1 : Infrastructure de base

35 3.4.2 Configuration

logicielle

requise

36 3.4.3 Installation

.

37

3.4.4 Configuration

.

37

3.4.5 Configuration du commutateur Cisco .

38

3.4 .

6 Test

.

. .

.

38 3.4.7 Signalisation GMPLS

40 3.5 Test du

software DRAGON

avec

deux

commutateurs Ethernet commerciaux.

41

3.5 .1 Scénario 2 : Infrastructure avancée (VLSR to VLSR)

.

41

3.5 .

2 Test . . .

. . . .

.

. .

42

3.5 .

3 Signalisation GMPLS

42

3.6 Adaptation du software DRAGON pour la switch

Cisco ONS

15454

43

3.6.1 Scenario 3 : Test du

software DRAGON

avec

une switch

Cisco

ONS

15454 .

44 3.6.2 Scenario 4 : Test du software DRAGON

avec de

ux sw

itches Cisco ONS

15454

45 3.7 Conclusion

..

CHAPITRE IV

COMPARAISON DES DEUX SOLUTIONS

4.1 Introduction

. . . .

4.2 Résulats expérimentaux

4.3 Simulation

.

4.3.1 Introduction

4.3.2 La Topologie NSF (National Science Fondation)

4.3.3 La

Topologie COST239

4.4 Conclusion

.

C

HAPITRE V

47

48

49

50

53

56 CONCLUSION . . .

.

. . . . .

.

. . . .

.

..

.

. . .

57 CHAPITRE VI

PUBLICATIONS

6.1 Article accepté dans la conférence

ICTON

.

6.2 Article

accepté dans la conférence

IEEE GLOBECOM

Appe

ndice A : Scé

nario 1

e

t 3

App

endice B

: Scénario 2 et 4

59

65

73

80

(10)

Figure

Page

1.1 Réseaux

IP

/

Transport .

6

1.2 Réseau

IP

(domaine intra)

8

1.3 Connectivité des routeurs

IP

dans un réseau de transport

9

1.

4 Réseau de transport et ses clients

. . . .

.

. . .

0 • • • • •

10 1.5 Architecture d

'un réseau traditionnel

vs

Architecture d'un réseau SDN

12 1.6 Réseau

Op

en

Flow.

.

14

1.7 Entrées du "Flow Table"

16

1 .8

Traitement des paquets dans un

r

ésea

u

OpenFlow

.

17

1.9 Entrées de "Group Table"

. . .

0 • • • • •

17 2.1 L'architecture

unifi

ée

d'un réseau de paquets-circuits

converge

nt

en

utilisant

OpenFlow

.

. .

. . .

.

. . .

25 2.2 Extension

du

protocole OpenFlow

26 2.3 Path Computation Element

(PCE)

27 2.4 Exemple de

co

lor

ation de graph

.

0

27 2.5 La config

ur

ation

du réseau et

l

es

messages échangés

pour

l

es scénarios

A et B

29 2.6 Capture Wireshark

:

Scénario A .

30 2.7 Capture Wireshark

: Scénario B

.

31 3.1 Test du

software

DRAGON

avec

un

comm

u

tateur

Ethernet commercia

l

36 3.2 Message d'installation réussie de VLSR .

37 3.3 LSP

en mode

«

Edit

» .

.

₃₉

3.4 LSP

en

mode

«

In

serv

i

ce »

40

3 .

5 Création de quatre

LSP

s

. .

40

(11)

3.7 Vue d'ensemble de l'infrastructure éte

ndue (Scénario

2)

.

42

3.8 SNMP

/

TLl

Gateway

. . . . .

.

. .

43 3.9 Messages

échangés

lors

de la création

d

'un LSP

44

3.10 Test du software DRAGON

avec

une

switch Cisco

ONS 15454

45

3.11 Test du software DRAGON avec

deux

switches Cisco

ONS

15454

46

4.1 L'algorithme exécuté au niveau du simulateur pour simuler le contrôleur

Open-Flow

. . . . .

.

. .

.

. .

.

. .

.

. . . .

.

. .

. . .

.

. . .

51

4.2 L'algorit

hme exécuté au niveau du simulateur pour

simuler

l'Agent

OpenFlow

52

4.3 La topologie

NSF . . . .

.

..

. . .

.

53

4.4 Topologie

NSF :

Temps

d

'établissement

du

lightpath (ms) vs

la charge

du

réseau

(Erlang) .

.

. .

.

. . .

.

. . . .

.

. . . .

53

4.5 Topologie NSF: Nombre de messages

de contrôle vs la charge du réseau (Erlang) 53

4.6 Topologie NSF

: Probabilité de

blocage vs

la charge du

réseau (Erlang)

.

. . .

54

4.7 Topologie NSF

: Nombre de

no

euds

par requête vs

la charge du r

éseau

(Erlang) 54

4.8 La topologie

COST239 . . .

.

. . .

.

. . .

.

. .

.

. . . .

.

54

4.9 Topologie COST239

: Temps

d

'établissement

du

lightpath (ms)

vs

la charge

du réseau

(Erlang) .

.

. . .

.

. .

.

. .

.

. .

.

. . . .

.

. . .

.

. . .

.

. .

55 4.10 Topologie

COST239 : Nombre

de

messages de contrôle vs

la charge

du réseau

(Erlang) .

.

. .

.

. . . . .

. .

.

. . . .

.

. .

.

. .

.

. .

.

55

4.11 Topologie COST239 : Probab

ilité de blocage vs

la charge du réseau

(Erlang) .

55

4.12 Topologie

COST239

: Nombre de noeuds

par

requête

vs

la charge

du

réseau

(12)

Table

1.1 Champs du matching

OpenFlow

.

. . . .

4.1 Temps expérimental d

'établissement des

liens

4.2 Protocoles

ut

ilisés

pour ch

aque solution

.

Page

15

49

(13)

API

AS

CLI

CTC

DRAGON

DWDM

E-BGP

GMPLS

GRE

1-BGP

IP

LDP

LSA

LER

LSP

LSR

MPLS

NAT

NSF

ONF

ONS

OSPF

OTN

Application Programming

Interface

Autonomous System

Command Line Interface

Cisco Transport Controller

Dynamic

Resource

Allocation

in

GMPLS

Optical Networks

Dense Wavelength Division

Multiplexing

External-Border Gateway Protocol

Generalized Multi-Protocol Label Switching

Generic Routing Encapsilation

Internal-Border Gateway

Protocol

Internet Protocol

Label Distribution Protocol

Link

State Advertisement

Label Edge Router

Label Switch

Path

Lab

el Switch

Router

Multi-Protocol Label Switching

Network

Programming Translation

National Science Foundation

Open Networking Foundation

Optical

Network Switch

Open

Shortest

Path First

Optical Transport Network

(14)

PCE

Pat

h

Computat

i

o

n

E

l

eme

n

t

QoS

Qua

l

ity

-

of-Serv

i

ce

RSVP

Reso

u

rce Reservation Protocol

ROADM

Reconfig

u

rable Op ti

cal

Add

-

Drop M

ul

t

i

plexe

r

SDN

Softwa

r

e

Defined

Network

i

ng

SLA

Service Leve

!

Agreement

SNMP

S

i

mple Network Management Protocol

SONET

Synchronous Opt

i

ca

l

NETwork

TCP

Transmission Contro

l

Protoco

l

TDM

T

ime

D

ev

i

sion M

ul

tip

l

exi

n

g

TE

Traffic E

n

gi

n

eer

i

ng

TED

Traffic Eng

i

neering

D

atabase

TLl

Tr

ansact

i

on

L

ang

u

age

1 TLV

Type

L

engt

h

Va

lu

e

TTL

T

ime

T

o L

i

ve

UCP

Unified Co

n

tro

l

P

l

ane

WAN

W

i

de A

r

ea Network

(15)

Motivations

Les

réseaux

à

grande

échelle

sont coûteux

à

exploiter et

les

fournisseurs de

services

sont

toujours

à

l

a

recherche des

moyens pour réduire

l

eur

capital et

l

es coûts opérationne

l

s.

Une

approche consiste

à

réduire

l

e

nombre de différents types

de

réseaux dont

ils sont

proprié-taires

. Ceci

peut être

accompli

en faisant

converger

l

es différents services

à

u

n

seul

réseau.

En

effet,

l

es

opérateurs

résea

u

x

d'aujourd

'hui

,

gérant

à

l

a

fois

l

es

domaines

I

P

et optiqu

es,

doivent

affronter p

lu

sieurs défis.

Les couches

I

P

et

optiques

sont exploitées séparément

par

deux équip

es d

i

stinctes, sans

in

teraction dynamique; ce qui

entraî

ne des

coûts d'exploitation

élevés

,

une

faible efficacité

du

réseau

, et

un

e

longue

latence

de traitement po

u

r achemi

-ner

des

donn

ées

(Li

u

et

a

l.

,

2012a). Cette

séparat

i

on

est

due

à

l

a

différence

au

niveau des

équipements

utilisés

par

chaque réseau, le

type de

commutation

et surtout le manque d

'un

mécanisme de contrô

l

e comm

un

qui permet de gérer

l

es deux techno

l

ogies d

'une façon

simple

et

unifiée.

Que

ll

es que soient

l

es

ra

isons,

une chose est

claire

-

l'exploitation de deux résea

ux

avec

deux mécanismes

tota

l

ement différents est

plus

coûteux et

in

effi

cace que

gérer

un

seul

réseau

convergent avec

un

plan de

contrôle

unifié

(UCP).

Ce

défi

énorme

no

u

s

interpelle, chercheurs

et

praticiens, et

nous

amène

à

nous poser

l

a

question

suivante :

comment pouvons-nous

implémenter un plan de contrô

l

e

unique,

dans

un

environnement

d'essa

i

rée

l

, pour la gestion simultanée des

réseaux opt

i

q

u

es

multicouches

IP

/

DWDM

?

Conte

x

te

e

t

contributions

du

mémoire

Les solutions

proposées

et

l

es

p

lu

s avancées

à

ce

jour pour

un

UCP

sont

ce

ll

es

utilisant

l

es protocoles GMPLS (Genera

li

zed Mu

l

ti-Protoco

l

Label

Switching)

et

OpenF

l

ow.

D

'un

e

part,

en

d

ép

i

t

d'énormes

progrès et

d'expérimentation

sur OpenF

l

ow,

il demeure

ef-ficace co

mme

plan de cont

rô

l

e

pour

les réseaux

convergents

IF-c

ir

cuits (Das

et a

l.

,

2010

;

Gud

l

a et

a

l.

, 20

10 ; Simeonido

u

et al.

,

2011).

Toutefois

, i

l

convient de

noter que ce

proto

co

l

e

est

mature

po

u

r

l

es

résea

u

x

de commutation de

paq

u

ets,

mais reste

à

un

stade de

départ

(16)

p

o

ur l

es

r

ésea

u

x

optiques. Pour

cela,

dans

ce

travail, nous proposons un

e extension

du

proto-cole

OpenFlow pour

supporter

l

es

réseaux

optiques. Cette extension contient trois é

l

éments

esse

nti

e

l

s.

Premièrement

,

nous développons

un

agent

que nous

appe

l

o

n

s

«

OpenFlow

Op-tical Agent

»

1

_a

_{fin d}

_'ass

_ur

_er

_l

_a

_{communication}

_e

_ntr

_e

_l

_{e co}

_ntrôl

_e

_ur

_OpenFlow

_et

_l

_es

_nœuds

optiques. La fonction primordiale de

cet agent est

de

transformer

les messages du protocole

OpenFlow

à

des

commandes

permettant de

configurer

l

es switches

optiques,

qui

sont

dans

notre

cas

les

comma

nd

es

TL1

(Transaction

L

ang

u

age

1) (Headquarters, 2003). Deuxièment,

nou

s ajo

u

to

n

s

un nouv

ea

u module

a

u

co

ntr

ô

l

e

ur

OpenFlow basé sur un

é

l

ément

de

calc

ul d

e

c

hemin

PCE

(

Path Computation Element).

Un PCE

est

un

e composante

fonctionnelle

du plan de

contrô

l

e,

capable d'effectuer un

calcu

l

de chemi

n

sur

un

graphique

représentant

un

réseau optique.

D'autre part malgré plus d'une décennie de développement

et

de

travaux

de

standardisatio

n

s

ur

GMPLS,

il demeure

efficace comme

technique de plan de

contrôle

pour les réseaux

o

p-tiques

se

ul

eme

nt

.

Mais

comme

UCP, il

est

trop complexe

à

mettre

en œ

uvr

e

dans l

es

réseaux

multicouches IP

/

DWDM

, en

raison de l

a

nature distribuée, du nombre de protocoles

et

les

in-teractions

ent

r

e

l

es

différentes

co

u

ches (Kumak

i

,

2008; Shiomoto, 2008). En plus, il

y' a encore

beaucoup d'

éq

uip

ements

réseaux qui ne

sont

pas

compat

ibl

es avec

GMPLS.

Par

conséq

u

e

nt,

il n

'y

a pas de d

é

ploi

e

m

e

nts

co

mm

e

rciaux d

e

bas

e

UCP-GMPLS

à

ce jour

, et

l

e

d

é

b

at

pour sa

praticabilité dans un vrai

scénario

opérationnel

croît en

intensité (Farrel, 2010).

DRAGON

(

Dyn

amic

Resource Allocation in GMPLS Optical Networks) (Lehman

et

al., 2006)

est

une

so

lution

software

open source permettent de

r

éso

udr

e

ce problème dans

l

es

réseaux Ethernet

en

utili

sant

l

e

protocol

e

SNMP (Simple Network Management Proto

co

l)

pour r

endre

l

es com

-mutateurs Ethernet capables

d

e

fonctionner

d

a

n

s

un réseau GMPLS. Notre

travai

l

consiste

d'abord

à

déployer

cette so

lu

t

ion

dans

no

tre

banc d'essai. Ensuite,

nou

s

implémentons

un

SNMP

/

TL1 Gateway

pour

adapter

l

a so

lu

t

ion

avec

nos

switches optiq

u

es.

Nous

testo

ns

également

les deux

sol

u

tions

proposées dans un banc d

'

essai

du

réseau

réel

et

nous

comparons

l

e

ur

s

performances

en

utili

sa

n

t

un

e sim

ul

at

ion

s

ur

deux

topo

l

ogies

de réseaux réelles.

Structure du mémoire

1. Une partie de l'agent OpenFlow a été dévelopée en co11aboration avec l'équipe de recherche de notre

(17)

Afin de

commun

iqu

er efficacement

l

e trava

il

accomp

li

ains

i

que les

cont

r

ib

u

t

i

o

ns

de

ce

m

é-moir

e,

nou

s avons

structuré

ce

docum

e

n

t comme s

uit

:

L

e c

h

apit

r

e

1 pr

ése

nt

e

un aperçu théorique

s

ur l

es

diff

é

r

e

nt

s

composants de notr

e

proj

et.

Ce c

h

ap

itr

e co

mm

e

n

ce

par donn

e

r un

e

vision

g

lob

a

l

e s

ur l

es

réseaux IP

et

d

e

transport,

e

n

c

i

tant

l

eurs caractér

i

stiq

u

es et en

pr

éc

i

sant

l

a

différence

entre ces

deux domaines

.

Ensuite,

nou

s

décrivons

l

es

prot

oco

l

es

Op

enF

lo

w et

GMPLS

,

l

es é

l

é

m

ents

de base de

nos

so

lu

tions.

-

L

e c

h

ap

i

tre

2 présente la première

sol

u

t

i

o

n impl

éme

nt

ée

(Extension du protocole Op

e

n-Flow

). No

u

s ex

pliquon

s

d'

a

b

or

d l'

avantage ap

port

é

par

Op

e

nFl

ow a

fin

de résoudre

n

ot

r

e

problème

.

Ensuite, nou

s

d

é

taillon

s

l

es

d

eux

modules

d

éve

lopp

és (

Op

e

nFlow

Op-tical Agent

et

P

CE).

Enfin

,

nous présentons

l

es scé

n

ar

ios

ex

p

é

rim

e

nt

aux

réalisés afin

d

e

valid

e

r

cette so

lu

tio

n. L

e

premier

scénar

i

o cons

i

ste

à

établ

ir un li

g

h

tpat

h

entre

d

eux

c

li

e

nt

s en

passant par l

es

deux

r

éseaux

IP

et

optiques.

L

e

deuxième

scé

n

ario

concerne

la

resta

ur

ation

du

li

e

n

l

ors

de la résiliation du pr

e

mier

li

g

h

tpat

h.

-

L

e c

h

ap

itr

e

3 décrit

notr

e

deuxième

so

lu

t

ion b

asée s

ur l

e

proto

co

l

e

GMPLS

.

D

a

ns la

pr

e

mi

è

r

e

partie d

e ce c

h

a

pitr

e,

nou

s

pr

ése

ntons l

e so

ftw

a

r

e

DRAGON que nous

avons

utili

sé

pour l

e

d

ép

loi

e

m

e

nt du GMPLS dans notr

e

infr

ast

ru

ct

ur

e

r

ésea

u. Nous d

étai

llons

l

es

différentes

étapes

d

'

in

stallat

ion

et

de configuration pour m

ettre en

plac

e

ce soft

w

a

r

e.

En plus

,

nou

s

présentons

d

eux cas

d

'ut

il

is

at

ion

s avec

un

e switch

Cisco

com

m

erc

ial

e.

Afin d

'

adapte

r l

e softwar

e

DRA

GON avec

nos

sw

i

tches opt

iqu

es, no

u

s

impl

émentons

un SNMP

/

TLl Gateway.

D

ans

l

a

deuxième par

t

i

e

d

e

ce

c

hapi

t

r

e,

nous d

éta

illons cette

implémentation, l

es

différ

e

nts modules

déve

l

oppés et

nou

s

présentons les

d

e

ux

scé

nario

s

r

éa

li

sés afi

n de valider no

tre

solution.

-

L

e c

h

a

pitr

e

4 co

n

ce

rn

e

l

a compara

i

so

n des performances d

es

d

eux so

lution

s

impl

é

m

e

n-tées

en

termes de temps d'établissement de li

ens

, l

e

trafic de

co

ntr

ô

l

e et

l

a

probabilité

de blocage. Pour

atte

indr

e cet

objectif, nous

p

r

ése

ntons

to

u

t

d'abord

l

es

résultats

ex

-périmentaux.

Ensuite,

n

o

u

s

d

éta

ill

ons

l

a s

imul

at

ion

que

nous

avons

r

éalisée sur

d

eux

to

pologi

es

de réseaux réelles.

L

es

résultats de

simu

l

at

ion

seront

di

sc

ut

és

à

la fin

d

e ce

chapitre.

L

e c

h

ap

itr

e 5 co

n

cl

ut

ce

mémoire

avec

un r

és

um

é

d

es

travaux

e

ffectués

a

in

s

i qu

e

l

es

(18)

-

Le chapitre 6 présente les deux a

rti

cles scientifiques

que nous avons publiés p

our décrire

notre travail

de recherche.

(19)

CADRE THÉORIQUE

1.1 Introduction

D

a

n

s ce c

h

a

pi

t

r

e,

nou

s

pr

ése

n

t

on

s

l

es as

p

ects t

h

é

oriqu

es

li

és à

no

t

r

e

proj

e

t

.

Nou

s c

omm

e

n-ç

on

s

p

ar

n

os

d

o

m

ai

n

es

d

'ét

ud

es;

l

es

r

ésea

ux IP

et

l

es

r

ésea

ux d

e t

r

a

n

s

por

ts.

Nou

s

d

étai

llon

s

l

es

di

ffé

r

e

nt

s é

l

é

m

e

n

ts

d

e c

h

a

qu

e

r

ésea

u, l

e

m

o

d

e

d

'

op

éra

b

i

lit

é et

d

e co

n

t

r

ô

l

e

,

et

l

a

di

ffé

r

e

n

ce

e

n

t

r

e ces

d

e

ux d

omai

n

es

.

En

s

ui

te,

n

o

u

s

in

t

roduison

s

l

es

d

e

ux pro

t

o

co

l

es

Op

e

nFl

o

w

et

GM-PLS qu

e

n

o

u

s a

v

o

n

s

utili

sés a

fin d

e

d

éfi

nir un pl

a

n d

e co

nt

rô

l

e

unifi

é

pour

l

es

d

e

ux d

o

m

a

in

es

é

tudi

és.

1.2 Réseaux IP

et

réseaux de transport

L

es

r

ésea

ux IP

s

on

t à co

mmut

a

tion d

e

p

a

qu

ets,

c

'est

-

à

-dir

e

qu

e

l

es

paqu

ets s

on

t co

mmu-t

é

s individu

e

ll

e

m

e

n

t

d

e

l

a

sou

rce

à

l

a

d

est

in

a

tion

e

n pass

a

nt par

l

es

diff

é

r

e

nts rout

e

urs

IP

.

C

e

p

e

nd

a

n

t,

l

es

p

a

qu

et

s

on

t

tr

a

n

s

por

tés

ph

ys

iqu

e

m

e

n

t e

ntr

e

l

es

rout

e

ur

s

d'un r

ésea

u b

asé

s

ur l

e

s fibr

es o

ptiqu

e

s

e

t

l

e

s

c

ommut

a

t

e

urs

d

e c

ir

c

uits

(

Fi

g

ur

e

1 .

1 )

.

C

e domain

e es

t

a

pp

e

l

é

r

ésea

u d

e

tr

a

n

s

port

.

Dan

s

l

e

s

sec

tion

s

suiv

a

n

tes,

nous d

étai

llons l

es

d

e

u

x

diff

é

r

e

nt

s

typ

e

s d

e

r

ésea

ux

.

1.2 .

1 Réseaux IP

L

'

int

e

rn

e

t

es

t

un

e

coll

e

c

t

ion d

e

r

ésea

ux IP in

te

r

c

onn

e

ct

és

. L

es

r

ésea

ux

c

on

s

titu

a

nts

l

'

in-t

e

rn

e

t on

t

d

e

s propri

é

tair

es e

t d

es é

quip

e

s d

e

maint

e

nanc

e e

t d

e

g

es

tion

ind

é

p

e

ndant

es.

Don

c,

(20)

Réseau LP

Réseau de transport 1

----

1 - - - - J 1

---1 1

....______

)

1

1 1 1

1

1 1

-

1

-

--1

l.r- _./

1 1 Lien physique 1 reliant le routeur : 1-- -- - IP à un réseau de

l

transport 1

l

__

-r--

Swltch TDM

<

Fibre optique

FIGURE

1.1: Réseaux IP

/

Transport

pour assurer

un

e connectivit

é

mondiale,

ces

réseaux

utilisent

le

proto

cole

E-BGP (External

Border Gateway

Protocol)

pour annoncer l'accessibi

lité des adresses IP

et choisir des

chemins

à

travers des

domaines de routage co

nnus par

les systèmes autonomes

(AS).

Dans

notre

tra-vail,

nous int

éressons à

l'architecture

des

réseaux

IP au sein d'un

AS dans

un

réseau étendu

WA

(Wide

Area Network).

Les caractéristiques

de ces

domaines

peuvent

êt

re

résumées

comme suit:

Les

réseaux

IP

ont des

mécanismes

de contrôle autom

atisés et entièrement dist

ribués.

Ces

mécanismes

impl

iquent

des

proto

coles

de routages

(I-BGP,

OSPF

etc.) et

d

ans

certains cas

des

protocoles

de signalisations (LDP,

RSVP, etc.) (F

igure 1.

2)

.

Dans

les

réseaux traditionnels

, un routeur IP est à la fois l'élément de contrôle, q

ui prend les

déci-sions de routage, ainsi que

l'élém

ent responsable de

la transmission des données. Après

la configuration d'un

ro

ute

ur

IP

(soit

manuellement, soit en utilisant des scripts),

il

détecte automatiquement ses

voisins et la topologie du

réseau, échange les

informations

de ro

utage et

transmet les

paqu

ets.

D'où l'aspect automatisé d

u contrôle au mveau des

(21)

résea

ux IP

.

L

es serv

i

ces

d

a

n

s

l

es

r

ésea

ux IP

o

n

t éga

l

e

m

e

n

t te

n

da

n

ce

à

avo

ir d

es

impl

é

m

e

n

tat

ion

s

r

é

p

art

i

es et

in

terag

i

sse

n

t

d

e faç

on

s

u

b

t

il

e avec

l

es

m

éca

ni

s

m

es

d

e co

n

trô

l

e e

n

t

i

ère

m

e

n

t

d

i

st

ribu

és (F

i

g

ur

e

1.2 ). Ces

in

te

r

act

i

o

n

s et

l

a

n

a

tur

e

di

st

ribu

ée

d

e

l

e

ur

s

impl

é

m

e

nt

at

i

o

n

s

r

e

nd

e

n

t ces se

rvi

ces

,

off

e

rt

s

p

a

r un rou

te

ur IP

,

n

o

n

s

t

a

nd

a

rd

(et

p

a

r

c

on

sé

qu

e

nt non

o

p

é

r

a

bl

es avec

d

'

a

utr

es

impl

é

m

e

nt

at

ion

s),

m

ê

m

e s

i l

es

m

éca

ni

s

m

es

d

e co

n

t

r

ô

l

e so

n

t

st

and

a

rdi

sés

.

À

t

i

t

r

e

d

'

exe

mpl

e

,

c

on

s

i

dé

ron

s

l

a

fon

c

tion d

'

in

gé

ni

e

ri

e

du tr

a

fi

c

qui

es

t

ass

ur

é a

uj

o

u

r

d

'

hu

i

p

a

r l

e

pr

otoco

l

e M

PL

S

-T

E (M

ul

t

iPr

otoco

l L

a

b

e

l S

w

it

c

hin

g

-

Tr

a

ffi

c

E

n

g

in

ee

rin

g)

.

E

ll

e

d

é

p

e

n

d

du

pl

a

n

de co

n

t

r

ô

l

e

IP

/

M

PL

S

qui

co

mp

re

nd

des

p

rot

o

co

l

es

n

o

rm

a

li

sés. Mais

l

a fo

n

ct

i

o

n

e

ll

e

-m

ê

m

e reste

n

o

n

sta

nd

a

rdi

sée.

L'in

gén

i

er

i

e d

u

trafic

s

ur

l

es

r

o

u

te

ur

s

Cisco

n

e

f

o

n

ct

i

o

nn

e

p

as s

u

r

l

es

rou

te

ur

s de

Juniper

o

u Huawei.

Et

do

n

c,

un

r

ésea

u IP

a

pp

a

r

t

i

e

n

t gé

n

é

r

a

l

e

m

e

n

t à

un m

ê

m

e

f

o

urn

isse

m.

L

es

f

o

n

c

ti

o

n

s

d

e gest

i

o

n d

es résea

ux

IP impliqu

e

n

t

l

a c

onfi

g

ur

at

i

o

n

(gé

n

é

r

a

l

e

m

e

n

t v

i

a

un

e

int

e

rf

ace

d

e

li

g

n

e

d

e c

omm

a

nd

e

(

C

LI

)

,

l

e s

ui

vi (gé

n

é

r

a

l

e

m

e

n

t v

i

a

S MP

) et

l'

e

n

-t

r

et

i

e

n

p

é

riodiqu

e.

L

es

r

ésea

ux IP

so

nt don

c

diffi

c

il

es à gé

r

e

r

.

Pour r

e

m

é

di

e

r

à

cec

i

, des

é

quip

es de

p

e

r

s

onn

e

l h

a

ut

e

m

e

nt qu

a

lifi

é gè

r

e

nt

e

t

modifi

e

nt manu

e

ll

e

m

e

nt

ces

r

ése

aux,

d

a

n

s

l

e

bu

t

d

e

p

a

rv

e

nir

à

un

é

quilibr

e e

ntr

e

l

es o

bj

ect

i

fs

l

oca

ux d

e c

h

a

qu

e

fourni

sse

m

et

l

e

m

a

inti

e

n d

e

l

a co

nn

ect

i

v

i

té

mondial

e.

Pour r

és

um

é,

1 '

in

te

rn

e

t

o

ffr

e a

ujourd

'

hui un

se

r

vice

d

e co

mmu

tat

i

o

n

d

e

p

a

qu

ets

« b

est eff

or

t

»

de

b

o

u

t e

n

bo

u

t. Ce

p

e

n

da

n

t

, il

est co

n

st

i

t

u

é d

'un

e

n

se

mbl

e de résea

ux IP in

t

r

a

d

o

m

a

in

e

, qui

s

on

t s

urpr

ov

i

s

ionn

és a

fin d

'

ass

m

e

r

un r

e

nd

e

m

e

n

t acce

p

ta

bl

e e

t

res

p

ecte

r l

es

di

ffé

r

e

n

tes

cl

asses

d

e se

r

v

i

ces;

il

s so

n

t a

u

to

m

at

i

sés,

il

s

ont

des

m

éca

ni

s

m

es

d

e co

ntr

ô

l

e e

nti

è

r

e

m

e

n

t

di

s

t

r

ibu

és,

il

s o

nt d

es se

rvi

ces

di

s

tribu

és, ce

qui

l

es

r

e

nd

gé

n

é

ral

e

m

e

nt d

es

r

ésea

ux monofourni

sse

ur

s e

t

diffi

c

il

e

à

gé

r

e

r

.

1.2.2

R

éseaux de transport

L'

o

bj

ect

if f

o

n

da

m

e

n

ta

l

d

'

un

r

ésea

u

d

e

tr

a

n

s

p

ort est

d

e fo

urn

i

r un

e

b

a

n

de

p

assa

nt

e

d

e

c

ommuni

cat

ion d

'

un

e

ndroit

géogra

phiqu

e

à

un

a

u

t

r

e.

P

a

r

exe

mpl

e

,

l

e

li

e

n

e

n

t

r

e

d

e

ux rou

-te

m

s da

n

s

un

r

ésea

u IP intr

a

dom

a

in

e é

t

e

ndu

est

l

og

iqu

e.

Il p

e

u

t êt

r

e éta

bli

avec

un

c

ir

c

ui

t

(d

i

v

i

s

i

o

n t

e

mpor

e

ll

e o

u lon

g

u

e

m

d'

ond

e

) d

ans

l

e

r

ése

au

d

e t

r

a

n

s

por

t (F

i

g

ur

e

1. 3)

. D

a

n

s ce

(22)

Services mis en œuvre de manière entièrement distribuée Routeurs IP d'un même fournisseur Mécanismes de contrôle entièrement distribués