Dimensionnement d Un Backbone IP-MPLS -WALHA_Nada 2005

RAPPORT DE PROJET DE FIN DETUDES

Filire

Ingnieurs en Tlcommunications

Option

Ingnierie de rseaux

Dveloppement dun outil daide au dimensionnement dun backbone

IP/MPLS pour le rseau NGN

Elabor par :

Nada Walha

Encadr par :

M. Mounir Frikha

M. Fakhreddine Khelifa

Anne universitaire : 2004/2005

DEDICACES

A mon pre

Sans ton soutien et tes encouragements je ne serais rien devenu.

A ma mre

Sans tes sacrifices, tes affections et ta tendresse je ne pourrais pas

arriver au bout.

A toute la famille de mon oncle

Elle que jaime et qui je dois beaucoup.

A mes frres et ma sur

Merci infiniment

Nada

Projet fin dtudes 2004/2005 ii

Avant propos

CCCCe travail a t effectu dans le cadre dun projet fin dtudes du cycle de formation dingnieurs diplms en tlcommunications de lcole suprieure de

tlcommunication de Tunis (SUPCOM). Il a t ralis en collaboration avec le

centre de recherches et dtudes des tlcommunications (CERT).

A ce titre, je tiens remercier M. Mounir Frikha pour ces encouragements et

son aide tout au long du projet.

JJJJe remercie chaleureusement M.Fakhreddine Khelifa, ingnieur principal au sein de la direction de recherche et de veille technologique du CERT pour son

encadrement, pour sa patience et pour ses conseils tout au long de la ralisation de

ce travail.

JJJJe tiens exprimer mes respects tout le personnel du CERT pour my avoir accueillie et mavoir permise de travailler dans de bonnes conditions.

MMMMerci galement au corps administratif et tout le cadre enseignant de lcole pour ne pas avoir pargn le moindre effort pour minformer et me documenter sur

le plan thorique et pratique durant les trois annes de ma formation SUPCOM.

MMMMerci enfin, tous ceux que je ne cite pas ici mais qui se reconnatront quand je dis qu'ils ont t indispensables eux aussi l'aboutissement de ce travail.

Projet fin dtudes 2004/2005 iii

Notre vie vaut ce quelle nous a cot defforts

Franois Mauriac

Projet fin dtudes 2004/2005 iv

Table des matires

Introduction gnrale............................................................................................ 1

Chapitre 1: La voix sur IP.................................................................................... 3 Introduction .................................................................................................................................3

I. Les apports de la voix sur IP ..................................................................................................3

II. Les architectures VoIP ..........................................................................................................4

III. La voix et la qualit de service.............................................................................................5

III.1 La qualit de service ...................................................................................................5

III.2 Contraintes stratgiques ............................................................................................8

IV. Les standards de la VoIP .....................................................................................................8

IV.1 La norme H.323 ..........................................................................................................8

IV.2 Le protocole SIP........................................................................................................14

IV.2.1 Architecture SIP ....................................................................................................15

IV.3 le protocole SIP-T .....................................................................................................15

Conclusion..................................................................................................................................17

Chapitre 2: Les rseaux multi-services ............................................................. 18 Introduction ...............................................................................................................................18

I. Nouvelles orientations du protocole IP................................................................................18

II. Les solutions possibles pour dimensionner un rseau multi-services..............................19

II.1 Le surdimensionnement du rseau...........................................................................19

II.2 La rservation de ressources .....................................................................................20

II.3 La diffrenciation de services....................................................................................22

II. 4 Le protocole MPLS : rservation de capacit et traitement diffrenci ..............25

Conclusion..................................................................................................................................27

Chapitre 3: Dimensionnement des artres du backbone MPLS .................... 28 Introduction ...............................................................................................................................28

I. Dimensionnement dun rseau offrant le service de la voix..........................................28

I.1 Dimensionnement du rseau daccs .........................................................................29

Projet fin dtudes 2004/2005 v

I.2 rseau dorsal IP/MPLS ..............................................................................................35

II. Dimensionnement pour un rseau offrant le service data................................................42

II.1 Etude dun cas particulier.........................................................................................42

II.2 Principe de distribution de charge ...........................................................................43

II.3 Capacit des liens .......................................................................................................43

II.4 Capacit des liens supportant le trafic voix et data ................................................44

Conclusion..................................................................................................................................44

Chapitre 4: Dveloppement dun outil de dimensionnement ......................... 46 Introduction ...............................................................................................................................46

I. Lenvironnement de dveloppement ...............................................................................46

II. Organigramme de dimensionnement ..............................................................................46

III. Description de loutil.........................................................................................................47

III.2 Calcul de la bande passante au niveau de chaque site ..........................................48

III.3 Calcul de la capacit du lien ....................................................................................49

III.3.1 Calcul de la capacit du lien pour le trafic voix..................................................49

IV. Influence de certains paramtres sur les rsultats de calcul .........................................52

V. Simulation ..........................................................................................................................54

V.1 Topologie simuler ....................................................................................................54

V.2 Scnario .......................................................................................................................55

Conclusion..................................................................................................................................56

Conclusion gnrale ............................................................................................ 57

Bibliographie........................................................................................................ 59

Projet fin dtudes 2004/2005 vi

Liste des figures

Figure 1-1: la configuration PC to PC...........................................................................................4

Figure 1-2 : la configuration PC- phone........................................................................................4

Figure 1-3 : la configuration Phone to Phone ...............................................................................5

Figure 1-4 : principe du buffer de gigue .......................................................................................7

Figure 1-5 : architecture dune zone H.323...................................................................................9

Figure 1-6 : architecture protocolaire de H.323 ..........................................................................11

Figure 1-7 : architecture protocolaire de la norme SIP ...............................................................14

Figure 1-8 : architecture SIP .......................................................................................................15

Figure 2-1: principe du RSVP.....................................................................................................22

Figure 2-2 : classification, marquage et conditionnement du trafic dans le domaine DiffServ ..23

Figure 2-3 : insertion du champ DSCP .......................................................................................24

Figure 2-4: Architecture MPLS...................................................................................................25

Figure 2-5: format dun message LDP........................................................................................26

Figure 2-6: format de lentte LDP-PDU....................................................................................26

Figure 3-1: topologie choisie pour un service de voix ...............................................................29

Figure 3-2 : encapsulation RTP/UDP/IP.....................................................................................31

Figure 3-3: format de lentte RTP .............................................................................................31

Figure 3-4: format de lentte UDP.............................................................................................32

Figure 3-5 : format de lentte IP ................................................................................................32

Figure 3-6: format de trame Ethernet ..........................................................................................32

Figure 3-7 : format de trame HDLC............................................................................................33

Figure 3-8: format de trame Frame Relay..................................................................................33

Figure 3-9: format de trame PPP.................................................................................................33

Figure 3-10: format de trame ATM.............................................................................................33

Figure 3-11 : lalgorithme dErlang inverse................................................................................34

Figure 3-12 : topologie choisie du backbone MPLS...................................................................35

Projet fin dtudes 2004/2005 vii

Figure 3-13: format de lentte MPLS ........................................................................................36

Figure 3-14 : encapsulation du paquet labellis sur la couche ATM ..........................................36

Figure 3-15: encapsulation de lentte MPLS dans les protocoles lEthernet, PPP et HDLC...37

Figure 3-16 : format du message Label Request ...................................................................39

Figure 3-17: format du message Label Mapping ..................................................................40

Figure 3-18 : format du message Label Withdraw ................................................................40

Figure 3-19 : format du message Label Release ...................................................................41

Figure 3-20: modification de la topologie pour un trafic data ...................................................43

Figure 4-1: organigramme de dimensionnement ........................................................................47

Figure 4-2 : la boite de dialogue principale.................................................................................47

Figure 4-3 : saisie des informations sur site................................................................................48

Figure 4-4 : calcul de la bande passante par site .........................................................................49

Figure 4-5 : calcul de la capacit du lien pour le trafic voix.......................................................50

Figure 4-6: capacit totale pour la voix (ajout de la signalisation) ............................................50

Figure 4-7 : calcul de la capacit totale.......................................................................................51

Figure 4-8 : Influence du trafic ...................................................................................................52

Figure 4-9: Influence du CODEC ...............................................................................................53

Figure 4-10: Influence du cycle de transmission ........................................................................53

Figure 4-11: Influence du protocole de la couche liaison ...........................................................54

Figure 4-12: Topologie simuler................................................................................................54

Figure 4-13: scnario simul .......................................................................................................55

Figure 4-14: le taux de perte de paquets en fonction du temps...................................................56

Projet fin dtudes 2004/2005 viii

Liste des tableaux

Tableau 1-1 : recommandation G.114 de lUIT-T ........................................................................6

Tableau 1-2 : les codec audio.....................................................................................................12

Tableau 1-3 : comparaison entre les protocoles SIP et H.323 ....................................................16

Tableau 2-1: comparaison CR-LDP TE-RSVP...........................................................................27

Tableau 4-1 : paramtres dentre et paramtres de sortie de la fentre Rseau daccs ...........48

Tableau 4-2 : paramtres dentre et de sortie pour la boite de dialogue capacit totale............51

Projet fin dtudes 2004/2005 ix

Acronymes

AAAL5 ATM Adaptation Layer5 ABR Available Bit Rate AF Assured forwarding ATM Asynchronous Transmission Mode

BBMAP Batch Markovian Arrival Process BS Bottom Stacking

CCAPEX Capital Expenditure CR-LDP Constraint Routing-Label Distribution Protocol CU Currently Unused

DDLCI Data Link Connection Identifier DS DiffServ DSCP DiffServ Code Point

EEF Expedited forwarding

FFEC Forwarding Equivalent Class FR Frame Relay

HHDLC High Data Link Control HTTP HyperText Transfer Protocol

IIDE Integrated Development Environment IETF Internet Engineering Task Force IP Internet Protocol ISUP ISDN User Part

LLAN Local Area Network LER Label Edge Router LS Location Server LSP Label Switching Path LSR Label Switching Router

Projet fin dtudes 2004/2005 x

MMCU Multipoint Controller Unit NGN Next Generation Network MP Multipoint Processor MPLS MultiProtocol Label Switching

OOPEX Operational Expenditure

PPC Personal Computer PCM Pulse Code Modulation PHB Per Hop Behavior PPP Point to Point Protocol PS Proxy Server PVC Permanent Virtual Channel

QQoS Quality of Service

RRFC Request For Comment RG ReGistrar RNIS Rseau Numrique Intgration de Service RS Redirect Server RSVP Ressource Reservation Protocol RTCP Real Time Control Protocol RTP Real Time Protocol

SSAP Session Announcement Protocol SLA Service Level Agreement SNMP Simple Network Management Protocol

TTCP Transmission Control Protocol TE-RSVP Traffic Engineering- Ressource Reservation Protocol TOS Type Of Service TTL Time To Live

UUDP User Datagram Protocol UIT-T Union Internationale de Tlcom

VVCI Virtual Channel Identifier VoIP Voice Over IP VPI Virtual Path Identifier

WWDM Wavelength Division Multiplexing

Projet fin dtudes 2004/2005 1

Introduction gnrale

Le monde des tlcommunications est aujourdhui en pleine volution vers des services et

des rseaux de nouvelles gnrations (NGN). Le march des communications sapprte vivre

des volutions fortes en terme de services proposs. Afin de sadapter aux grandes tendances

qui sont la recherche de souplesse dvolution de rseau, la distribution de lintelligence dans le

rseau et louverture des services tiers, les NGN sont bass sur une volution progressive

vers le tout IP .

La Voix sur IP (VoIP) est un nouveau service parmi dautres qui a dynamis le march des

NGN. On a pass alors dune commutation de circuits (tlphonie classique) une

commutation de paquets. Transporter la voix sur un rseau IP, nous amne penser la

convergence vers un rseau multi-services o on assiste une intgration de deux types de

trafic savoir : un trafic lastique (data) et un trafic temps rel (multimdia et voix). Ces deux

types de trafics diffrent considrablement en terme de besoin en qualit de services (QoS). Le

dfi de la VoIP tait comment assurer un dlai, une bande passante, une gigue et un taux de

perte faibles des paquets de la voix avec un protocole IP dvelopp lorigine pour supporter

un trafic data.

Pour dimensionner un rseau supportant ces deux types de trafic classiques, plusieurs

approches ont t adoptes telles que le surdimensionnement du rseau, la rservation de

ressources (MPLS) et la diffrenciation de services (DiffServ), sans oublier que ces deux

derniers mcanismes peuvent tre intgrs (Diffserv et MPLS).

Dans le cadre de ce projet, on a essay daborder le problme de dimensionnement des

capacits des artres dans un backbone MPLS en partant dun rseau qui offre uniquement le

service de la voix puis en intgrant le trafic data.

Ce rapport est compos de quatre chapitres : le premier chapitre a pour fin de donner une ide

globale sur le service VoIP : son principe, ses protocoles et ses exigences en terme de qualit de

service. Le deuxime chapitre dtaille les diffrents modles adopts pour grer des rseaux

multiservices intgrant des services temps rel et lastiques. Le troisime chapitre a t

consacr pour prsenter la mthode utilise pour dimensionner les artres dans un backbone


MPLS. Enfin le quatrime chapitre a t rserv pour prsenter loutil dvelopp pour

dimensionner les liens au niveau du rseau dorsal MPLS et tester le taux de rejet au niveau

dun routeur daccs au backbone MPLS.

Chapitre1 : La voix sur IP


Chapitre 1: La voix sur IP

Introduction

Actuellement, les oprateurs de tlcommunications ont tendance dvelopper les

technologies permettant le transport de plusieurs types dinformations sur le mme mdia. La

tendance dvelopper ces technologies est explique par une souplesse dutilisation, de

maintenance et dadministration ainsi quune rduction des cots. Dans ce contexte, le march

de la tlphonie est entrain dvoluer vers une convergence voix/donnes autour dun protocole

unique : IP.

Le principe de la VoIP consiste numriser le signal vocal par la source, le compresser pour

rduire le dbit et le transporter par la suite sur le rseau. La destination effectue les oprations

inverses pour restituer linformation.

Lobjectif de ce chapitre est de donner une vision globale dun service qui est en cours

dmergence savoir la voix sur IP. Ce type de service mrite dtre valuer de point de vue

apports et contraintes techniques et stratgiques lies son dploiement.

I. Les apports de la voix sur IP

Le protocole IP est destin transporter les donnes. Mais aujourdhui, on cherche

exploiter ce protocole, qui est en pleine volution, pour transmettre la voix alors quon est

capable de la transporter sur des rseaux tlphoniques classiques.

Grce la VoIP, on peut agir sur certains cots qui sont lis la maintenance et

ladministration puisque les services voix et donnes deviennent intgres au sein dun mme

rseau. Les utilisateurs bnficiant du service VoIP sont gnralement des entreprises. Ce

service permet un tarif de tlcommunication rduit. En particulier, plus les interlocuteurs sont

loigns, plus la diffrence de prix est intressante. Les dpenses en capital (CAPEX) et les

frais dexploitation (OPEX) sont galement rduits grce la gestion dune architecture de

rseau unique (conomies de cblage et de communications inter-sites)



Les frais dadministration sont galement rduits (administration d'un rseau unique, un seul

fournisseur d'accs)

Le protocole IP intgre non seulement la voix sur les rseaux IP mais il intgre galement des

services vido tels que la vido confrence, e-learning Il permet galement le dveloppement

et lvolution des applications utilisant voix et donnes telles que la messagerie unifie.

II. Les architectures VoIP

On distingue 3 types de configurations :

o La configuration PC to PC : La configuration PC to PC ncessite que les deux correspondants disposent de microphones, de haut-parleurs ainsi quun logiciel VoIP. Les

deux correspondants doivent se donner rendez-vous sur Internet ou tre connect en

permanence.

Modem Bank

FAI : Fournisseur dAccs Internet

RTC : Rseau Tlphonique Commut

Figure 1-1: la configuration PC to PC

o La configuration PC to phone ou phone to PC : Si lappelant est un micro-

ordinateur, lappelant doit demander un service son fournisseur daccs Internet. La

passerelle se chargera de la signalisation et de ltablissement dappel. Si lappelant est

un poste tlphonique, alors la passerelle prendra la charge dtablir la communication

avec le rseau Internet.

Modem Bank

1 2 3

4 5 67 8 9

* 8 #

Figure 1-2 : la configuration PC- phone



o La configuration Phone to Phone : Dans ce cas de figure, on utilise soit des passerelles soit des adaptateurs des deux cts. Le schma de la figure 1-3 montre le

cas de passerelle.

1 2 34 5 67 8 9

* 8 #

1 2 34 5 67 8 9

* 8 #

Figure 1-3 : la configuration Phone to Phone

III. La voix et la qualit de service

III.1 La qualit de service

Lun des obstacles qui a retard ladoption de la VoIP par certaines entreprises est le

problme de la qualit de service. La qualit de la voix transporte sur les rseaux IP est

infrieure celle donne par la tlphonie classique. En effet, la voix est un service temps rel

qui trouve ses besoins dans les rseaux commutation de circuits comme le RTC (Rseau

Tlphonique Commut) puisque chaque communication on alloue une bande passante

ncessaire. Mais si on transporte la voix sur des rseaux commutation de paquets comme le

rseau IP, les paquets de la voix suivront des chemins variables, souvent longs, sans garantir la

bande passante ncessaire.

Etant donn que la voix exige des contraintes temps rel, il est ncessaire dagir sur un certain

nombre de paramtres quantitatifs.

III.1.1 Le dlai de transmission

Le dlai de transmission dun paquet peut scrire sous cette quation

RNE DDDD ++= (1.1)

Avec :

paqcompcodE DDDD ++= (1.2)

filecommpropN DDDD ++= (1.3)

dcomdcomdpaqbufR DDDDD +++= (1.4)



ED : le dlai de lmetteur

codD : le temps ncessaire au codage

compD : le temps de compression

paqD : le temps de mise en paquet.

ND : le dlai du rseau

propD : le temps de propagation

commD : le temps de commutation

fileD : le temps de mise en file dattente.

RD : le dlai du rcepteur

bufD : le temps de sauvegarde dans le buffer de gigue

depaqD : le temps de dpaqutisation

decomD : le temps de dcompression

decodD : temps de dcodage.

Selon la recommandation G.114 de UIT-T, le dlai de transmission doit tre infrieur 150 ms

pour une meilleure interactivit (voir tableau 1-1).

Bon Moyen Mauvais

Dlai de transit D



appD : dlai apparant sur le rseau : cest un dlai choisi et fix comme temps de

transmission sur le rseau.

relD : dlai rel pass par le paquet pour arriver sa destination.

Figure 1-4 : principe du buffer de gigue

III.1.3 La perte de paquets

La perte de paquets est un paramtre important pour certaines applications temps rel. Il est d

une surcharge du rseau ou une dfaillance matrielle (exemple dans le routeur) ou

logicielle. Mais tant donn que les applications audio et vido utilisent le protocole UDP, il

ny a pas de garantie darrive des paquets leur destination et en cas derreurs, il ny a pas de

retransmission.

III.1.4 La bande passante

La voix ncessite un dbit de 64 Kbit/s sans compression. Sur les rseaux IP la voix peut tre

compresse jusqu 5 Kbit/s. Mais ceci peut entraner une dgradation de la qualit et une

augmentation du temps de latence.

III.1.5 Lcho

Lcho est d une variation dimpdance. Sil est faible, il ne va tre perceptible. Mais sil

dpasse les 50 ms comme temps daller retour par rapport au sidetone, il va causer un problme

la personne qui coute [1]. Le sidetone est un phnomne de rflexion du signal vocal mais

cette rflexion est utile pour la personne qui coute pour des raisons physiologiques.

III.1.6 La scurit

La tlphonie sur IP utilise le rseau Internet comme rseau de transmission. Ce rseau est

connu par sa vulnrabilit. Dans ce contexte, lIPSec est un protocole utilis pour

lauthentification et la confidentialit de linformation sur Internet.



III.2 Contraintes stratgiques

Certains obstacles stratgiques empchent le dploiement de la VoIP. En effet, ce service

peut menacer les flux des recettes des oprateurs historiques. Dautre part, la voix sur IP offre

des tarifs internationaux rduits. Or les oprateurs monopoles ne sont guerre pousss baisser

leur prix en faisant le dploiement de la VoIP.

IV. Les standards de la VoIP

IV.1 La norme H.323

La norme H.323 est un standard de lIUT-T qui a t propos en premire version en 1996.

Ce protocole traite le transport de la voix et de la vido en temps rel sur les rseaux IP. Ce

protocole est utilis essentiellement en visioconfrence. Il sinspire de la norme H.320 qui

proposait une solution pour la visioconfrence sur un rseau numrique intgration de service

(RNIS). Le H.323 est une adaptation de H.320 pour les rseaux IP.

IV.1.1 Les apports du H.323

Des codecs standards : H.323 dfinit des normes de compression pour les flux audio

et vido.

Indpendance vis--vis du rseau : H.323 se situe au-dessus des couches rseaux. Il

bnficiera donc des futures avances technologiques de ces dernires.

Indpendance logicielle : comme standard H.323 peut tre implment sur tout

systme dexploitation. Dans ce cas, tous les logiciels conformes au standard sont

compatibles entre eux.

Interoprabilit : les utilisateurs nont pas se soucier de la compatibilit de leurs

quipements avec ceux de leurs correspondants puisque le H.323 dfinit des

protocoles de signalisation pour cet effet.

Support de la communication multipoints : bien quoptionnelles, les MCU (Multipoint

Control Unit) donnent une flexibilit et une robustesse aux systmes de

visioconfrence en mode multipoints.

Gestion de la bande passante : le standard H.323 permet ladministrateur rseau de

limiter le nombre de connexions H.323 simultanes vitant un encombrement du

rseau.



IV.1.2 Les quipements H.323

Le protocole H.323 dfinit plusieurs quipements rseaux. La passerelle (gateway) : cest un quipement qui permet linterconnexion du rseau

Internet avec le rseau RTCP. Il permet aussi linterconnexion de diffrents types de

rseau multimdia (exemple passerelle H.323/H.320). Elle assure galement le

codage/dcodage de la voix selon les spcifications de la norme H.323.

Le (gatekeeper) : cest un lment optionnel mais cest le compagnon logiciel de la

passerelle. Il permet le contrle dadmission, le contrle de flux et la rsolution

dadresses. Il est responsable de la scurit, du routage et de la gestion des passerelles.

Le contrleur multipoint (MCU) : cest un lment logiciel. Il gre les flux multicast en

se basant sur les adresses de groupes. Il a une capacit limite en nombre dutilisateurs.

Il est constitu dun MC (Multipoint Controller) qui est un point central travers lequel

les points de terminaisons peuvent changer des informations sur leurs capacits. Il est

form galement dun plusieurs MP (Multipoint Processor). Le MP reoit les flux

audio, vido et/ou de donnes, traite ces flux et les renvoie aux points dextrmit

participant une confrence multipoints [1]. Il permet galement de faire le mixage de

la voix.

Figure 1-5 : architecture dune zone H.323



IV.1.3 Architecture protocolaire de H.323

La norme H.323 est une pile de protocole de signalisation, de communication et de donnes :

Les protocoles de signalisation

o RAS (port UDP 1719) : cest une interface de dialogue avec le gatekeeper. Il sert tablir avec le Gatekeeper :

le relais de messages Q931,

les instructions d'admission / autorisation d'appels,

les instructions de gestion de la bande passante

o Q.931 : cest un protocole dtablissement dappels o H245 (port TCP dynamique) : ce protocole permet

ltablissement du canal de transmission,

la ngociation des prfrences : type de codeur audio etc.

le contrle de flux...

Les protocoles de donnes

T120 : ce protocole permet le transfert des fichiers, le partage des applications, et

l'envoi des messages chat . Ce protocole est trs connu par son implmentation

par Microsoft.

Les protocoles de communications

o RTP ( Real Time Transfert Protocol). Cest un protocole du niveau transport. Il indique le type de codage de linformation transport et permet dassurer le bon

squencement des trames (grce au champs dentte Sequence Number). Il

ajoute galement des marqueurs de temps (timestamping). Il supporte des

sessions multicast. Mais, il ne garantit pas le bon acheminement des paquets

puisquil est utilis avec le protocole UDP.

o RTCP (Real Time Transfert Control Protocol). Ce protocole se charge du contrle des communications (congestion du rseau, tat de rception,..). Pour

cela, il transmet priodiquement des informations de contrle entre les

participants une session comme des statistiques de rception et dmission,

pour fournir des informations indicatives de la qualit de service.



Figure 1-6 : architecture protocolaire de H.323

IV.1.4 Les codecs

Les terminaux H.323 sont capables de recevoir des donnes vido et audio. Mais ces donnes

doivent tre compresses avant demprunter des chemins variables sur le rseau. Pour cela, on

utilise des codecs ayant des caractristiques variables qui vont tre expliques dans les deux

paragraphes suivants.

Les codecs audio

La voix ncessite dtre code avant dtre achemine sur le rseau. La norme H.323 spcifie

pour cela une varit de codecs audio qui peuvent tre rsums dans le tableau suivant :

codec codage bande

passante du

signal

frquence

dchantillonnage

vitesse complexit commentaire

hertz hertz Kbit/s

G.711 PCM 300-3400 8000 64 basse trs bonne qualit

de restitution de la

voix au dtriment

dune

consommation de

bande passante

leve pour

lInternet, mais



acceptable dans le

cadre dun rseau

local.

G.722 SB-MICDA 300-3400 16000 48

56

64

moyenne

G.723.

1

ACELP

MP-MLQ

300-3400 8000 5.3

6.4

haute Taux de

compression lev

fournissant une

restitution

mdiocre bien

quintelligible. Ce

codec est utilis

lorsquon bnficie

dune faible bande

passante, en cas

dengorgement du

rseau par

exemple.

G.728 LD-CELP 300-3400 8000 16 basse

G.729 CS-ACELP 300-3400 8000 8

13

haute Taux de

compression

moyen. Qualit de

restitution de la

voix de qualit

moyenne. Trs bien

adapt lusage de

la voix sur IP sur

lInternet public

dans un cadre de

charge normale du

rseau

Tableau 1-2 : les codec audio

G.711 : le codec PCM (Pulse Code Modulation) est la technique de compression de

base et correspond un codage sur 8 bits pour un dbit de 64Kbits/s. Ce codec permet



de fournir une trs bonne qualit de restitution de la voix au dtriment dune

consommation de bande passante leve.

G.723.1 : encode et compresse le signal vocal en 5.3 et 6.3 Kbit/s. Le taux de

compression est lev pour ce codec mais il fournit une restitution mdiocre bien

quintelligible. Ce codec est utilis lorsquon bnficie dune faible bande passante, en

cas dengorgement du rseau par exemple.

G.729 : encode et compresse le signal vocal en 8 Kbit/s. cest un taux de compression

moyen. La qualit de restitution de la voix est donc de qualit moyenne.

G.722 : le son est trait suivant lchantillonnage 50 7000 Hz, fournissant un dbit de

64, 56 ou 48 Kbit/s avec une frquence dchantillonnage de 16000 Hz.

Lchantillonnage une frquence gale au double de celle des codecs prcdents

codecs apporte une qualit suprieure.

G.728 : la bande de frquence utilise dans ce cas est la bande 300-3400 Hz. Le codage

donne un dbit de 16 Kbit/s avec une frquence dchantillonnage 8000 Hz.

Lavantage est le dlai, nettement plus faible que CELP, qui est de lordre de 2 ms.

Les codecs vido

H.261 : cette recommandation a t dpose en mars 1993 pour permettre une

interoprabilit des services audiovisuels. Elle a t prvue lorigine pour fonctionner

sur les lignes RNIS. Elle supporte deux rsolutions : CIF qui donne un dbit de 15

images / secondes avec une taille de trame de 288 lignes X 352 pixels et la rsolution

QCIF qui donne un dbit de 30 images/seconde avec une taille de trame de 144 lignes X

176 pixels.

H.263 : il a t conu, au dpart, pour assurer des dbits infrieurs 64 kbit/s,

maintenant il permet des dbits suprieurs. Il supporte cinq rsolutions : sub-QCIF de

taille de trame 128X 92, QCIF de taille de trame 176X144, CIF (288 lignes X 352),

4CIF (702 X 576), 16CIF (1408 X 1152).

MPEG-4 : ce codec est un successeur des formats MPEG-1 et MPEG-2. Il permet de

compresser des fichiers audio et vido volumineux. Il permet de rduire la taille des

fichiers de 33% 50 % avec plus de puissance processeur.



IV.2 Le protocole SIP

Cest un protocole de signalisation au niveau de la couche application. Il fonctionne

indpendamment des protocoles des couches basses (UDP/TCP, AAL5, X25). Il a t

propos comme alternative H323 par lIETF dans le RFC 2543 en Mars 1999. Il permet la

cration, la modification et la libration des sessions entre deux ou plusieurs participants. Ces

sessions correspondent des appels tlphoniques via Internet, des confrences multimdia

[2]

IV.2.1 Architecture protocolaire de SIP

Le standard SIP se base sur un ensemble de protocoles tels que :

RSVP (Ressource Reservation Protocol): cest un protocole utilis pour rserver les

ressources rseaux sur IP.

RTP (Real-time Transport Protocol) est un protocole utilis pour transporter des

informations en temps rel avec une excellente qualit de services.

RTCP (Real-Time streaming Control Protocol) : il est utilis pour assurer le contrle de

flux des donnes multimdia.

SAP (Session Announcement Protocol) : ce protocole permet de prciser si les sessions

multimdia ouvertes le sont en multicast.

Le schma de la figure 1-7 montre larchitecture protocolaire de SIP.

Figure 1-7 : architecture protocolaire de la norme SIP



IV.2.1 Architecture SIP

La norme SIP est base sur un ensemble dquipements qui peuvent communiquer entre eux.

Le User Agent : cet agent peut tre soit un client qui initialise des requtes soit un

serveur qui excute des requtes.

Le ReGistrar (RG) : cest un quipement qui permet denregistrer les localisations des

User Agents. En fait, chaque PS ou RS est gnralement reli un Registrar.)

Le Location Server (LS) : ce serveur fournit la position courante des utilisateurs dont les

communications traversent les RS et les PS)

Le Proxy Server (PS) : il a pour fonction de relayer les requtes. Chaque terminal est

reli au PS le plus proche et peut changer de PS. Le PS agit la fois comme client et

serveur. Il peut interprter et modifier les messages quil reoit avant de les

retransmettre.

Le Redirect Server (RS) : il fournit une adresse alternative laquelle lappel peut tre

joint.

Figure 1-8 : architecture SIP

IV.3 Le protocole SIP-T

Ce nest pas un nouveau protocole. Cest un tablissement de mcanismes pour interfacer la

signalisation tlphonique traditionnelle avec SIP. Lobjectif de SIP-T est dassurer la

transparence travers les points dinterconnexion RTCP-SIP. Il y a trois scnarios dutilisation

du protocole SIP-T.

IV.3.1 Source RTCP- destination RTCP

Dans ce cas la passerelle dorigine reoit lISUP partir du rseau RTCP et prserve

linformation (via lencapsulation et la translation) dans les messages SIP qui vont tre transmis



la passerelle de terminaison. Le terminal extrait le contenu ISUP partir du message SIP reu

et rutilise cette information pour envoyer la signalisation au RTCP.

La translation englobe tous les aspects de conversion des protocoles de signalisation entre le

SIP et lISUP.

IV.3.2 Source RTCP-destination IP

Pour ce cas de figure, la passerelle dorigine reoit lISUP partir du rseau RTCP et prserve

linformation dans les messages SIP quil dirige au SIP User Agent. Le terminal na pas besoin

de lISUP encapsul et lignore.

IV.3.3 Source IP- terminaison RTCP

Dans ce cas, un tlphone SIP gnre un appel VoIP qui va tre rout par un ou plusieurs

serveurs proxy la passerelle terminale approprie. Cette passerelle convertit les signaux ISUP

et dirige lappel linterface RTCP approprie bas sur linformation contenu dans lentte SIP

reue. [3]

IV.3.4 Comparaison entre le protocole H.323 et le protocole SIP

Les protocoles SIP et H.323 diffrent dans pas mal daspects. Ce tableau permet de distinguer

les principales diffrences entre ces deux standards.

Comparaison de deux protocoles de contrle

dappels candidats

SIP H.323

Spcification : organisme, date

IETF, 1999 UIT, 1996

Modle dorigine Internet, www Tlphonie : RNIS Applications vises VoIP, multimdia VoIP, vido streaming Service de tlphonie Encore limit Elabor Protocoles de transfert : donnes, multimdia

RTP/RTCP RTP/RTCP

Implmentation Simple (ASCII, protocoles IP : http, DNS, adresse URL)

Plus complexe

Extensibilit Oui Faible (complexe, forte augmentation du volume de code)

Interoprabilit entre constructeur

Elev Limit

Maturit Faible (service, produits) Bonne (produits) Tableau 1-3 : comparaison entre les protocoles SIP et H.323



Conclusion

La tlphonie sur IP ouvre la voie de la convergence voix/donnes et celle de lexplosion de

nouveaux services. De plus, maintenant que la normalisation a atteint une certaine maturit, il

nest plus dangereux de miser sur le standard H.323 qui a t accept par lensemble de la

communaut ou le standard SIP qui est maintenant en pleine volution. La tlphonie IP est

donc une bonne solution en matire dintgration, de fiabilit, dvolutivit et de cot.

Chapitre2 : Les rseaux multi-services


Chapitre 2: Les rseaux multi-services

Introduction

Le protocole IP est devenu aujourdhui le protocole le plus utilis dans les rseaux

commutation par paquet. Cet tat o on assiste un avnement de nouvelles applications exige

une qualit de service adapte. Ceci rend ncessaire lamlioration de la capacit de lInternet

supporter de nouveaux services et amliorer sa croissance dans le futur [4].

Les services supports par le protocole IP varient en terme de type de trafic apport et en

terme de sensibilit aux diffrents paramtres de qualit de services. En effet, il existe deux

types de trafic sur tout rseau IP : un trafic lastique et un trafic temps rel. Le trafic lastique

concerne toutes les fonctionnalits traditionnelles offertes par les rseaux, tels les transferts de

donnes, qui ne sont pas sensibles au dlai. Bien que les utilisateurs prfrent que ce type de

transfert se fasse le plus rapidement possible, celui-ci aura lieu quelque soit le temps qu'il met.

Le trafic gnr par ce genre d'application est appel trafic lastique, parce qu'il peut s'adapter

n'importe quel dbit impos par le rseau. Le trafic lastique est aussi appel le "trafic dbit

accessible ou ABR (Available Bit Rate), car certaines applications peuvent acclrer ou ralentir

en fonction du dbit possible. Le trafic temps rel ne possde pas cette lasticit. En effet, des

donnes temps rel ne sont utiles que si elles arrivent temps. Pour ces raisons, des

mcanismes ont t mis en uvre dans les rseaux pour assurer la QoS (Quality of Service).

Dans ce chapitre on a essay de donner une ide sur les mcanismes qui doivent tre

implments au niveau des rseaux supportant le protocole IP afin dassurer la qualit de

services exige.

I. Nouvelles orientations du protocole IP

LInternet offre aujourdhui un service de type BE (Best Effort) dans lequel tous les trafics

IP sur les diffrents liens sont traits de faon similaire [5]. En dautres termes, aucun

mcanisme nest implment pour assurer la qualit de service lorsque les trafics instantans



dpassent les capacits des liaisons. Cependant, offrir un support multi-service pour certains

trafics temps rel tels que la voix sur un rseau IP exige un changement des stratgies adoptes

dans ce rseau pour satisfaire les besoins qui touchent laspect qualit de service.

Limplmentation de certains mcanismes au niveau du rseau pour supporter diffrents types

de trafic nest pas suffisante. Il est ncessaire dajouter des mcanismes pour utiliser les

ressources du rseau de faon adquate.

II. Les solutions possibles pour dimensionner un rseau multi-

services

Plusieurs mcanismes peuvent tre envisageables pour satisfaire les besoins de certaines

applications en terme de qualit de services tels que :

o le sur dimensionnement du rseau o la rservation de ressources o le traitement diffrenci

Les deux derniers mcanismes peuvent tre intgrs pour fournir une solution meilleure.

II.1 Le surdimensionnement du rseau Le surdimensionnement du rseau signifie concevoir le rseau de telle manire quil soit

capable de transmettre tout moment les volumes de trafic et de satisfaire leurs besoins en

terme de qualit de service. En gnral, le choix du mcanisme dpend du pourcentage du type

de trafic. Si tout le trafic est sensible au dlai et ncessite un traitement prioritaire, le

surdimensionnement est la seule alternative [5].

Pourquoi surdimensionner le rseau ?

o La dgradation des performances due au fait qu tout moment une liaison physique peut tomber en panne rend parfois le surdimensionnement du rseau une ncessit.

o Dans les rseaux IP transportant aussi bien le trafic data que le trafic multimdia, linfrastructure IP ncessite un surdimensionnement pour permettre le trafic temps rel.

o Le surdimensionnement peut tre une solution au problme de congestion. En effet, laisser une marge de ressources disponibles dans le rseau permet en cas de

transmissions en rafales dviter la congestion.



Les inconvnients du surdimensionnement

Imaginons un rseau qui transporte la VoIP ainsi quun trafic HTTP (HyperText Transfer

Protocol) et SNMP (Simple Mail Transfer Protocol), dans ce cas il semble ne pas tre une

solution conomique de dimensionner le rseau de telle faon quil fournit la plus large bande

passante.

Le problme avec le surdimensionnement est que les quipements mettre en place pour

assurer une bande passante suffisante sont coteux. En dautres termes, chaque augmentation

dans la bande passante entrane un investissement supplmentaire de point de vue quipements

matriels.

II.2 La rservation de ressources

La rservation de ressource est un autre moyen de dimensionner un rseau. Elle signifie

quune proportion de la capacit du rseau est alloue une classe de service. Cette ressource

est rserve le long de la route emprunte par un trafic donn. La rservation de capacit peut

tre prdfinie. Dans le dernier cas, des protocoles de signalisation assurent la rservation de

ressources.

La rservation de capacit peut tre :

o de type physique : dans ce cas une partie de la capacit au niveau de la couche physique est alloue un service donn. Par exemple dans les rseaux lien optique utilisant

WDM (Wavelength Division Multiplexing), une longueur donde peut tre rserve

pour les appels tlphoniques dans les rseaux commutation de circuit entre deux

centres de commutation.

o Signale semi permanente : la rservation permanente pour une classe de service peut tre tablie avec des protocoles de signalisation appropris. Cest le cas par exemple

des circuits virtuels permanent PVC (Permanent Virtual Channel) de lATM.

o Signale sur demande : la rservation est tablie sur demande. Cest le cas par exemple de la signalisation RSVP le long du chemin appliqu pour les flux individuels.

o Rservation statistique : la rservation est interprte en utilisant un terme statistique prdfini tel que la disponibilit durant 95% du temps.

II.2.1 Le modle IntServ

Lexploitation commerciale de nouvelles technologies telle que la voix sur IP ne pourra pas

dbuter avec un rseau Internet peu performant que si on lui implmente des mcanismes qui



lvent et garantissent le niveau de performance. Les trafics temps rel tels que la voix et la

vido peuvent utiliser une rservation de ressources pour tre sr de bnficier de la qualit

ncessaire. Le modle IntServ se base sur lallocation de ressources selon une demande de

lutilisateur. Les ressources restent alloues pendant toute la dure de transmission sans tre

affectes par un trafic IP Best Effort .

II.2.2 Le protocole RSVP

Le protocole RSVP est le protocole de rservation qui a t conu au dpart pour fonctionner

avec le modle IntServ. Le protocole RSVP permet par exemple dans le cas de la tlphonie

sur IP de rserver des ressources pour chaque communication. Mais dune faon gnrale, le

protocole RSVP est un protocole de signalisation qui permet dmettre une demande

dallocation de bande passante tous les nuds sur le chemin dun flot donn [6].

Les catgories de messages RSVP

Les messages RSVP sont de sept types :

o Les messages de rservation : Resv o Les messages de route : Path o Les messages de fin de rservation : Teardown o Les messages de fin de route : TearPath o Le message optionnel de confirmation de rservation : ResvConf o Et les messages derreurs : ResvErr et PathErr

Comment fonctionne RSVP ?

Les messages les plus importants sont :

Resv : le message Resv est envoy par le destinataire en direction de la source

tous les routeurs censs sur le chemin. Il indique quels flots bnficient de traitements

spciaux et quel niveau de QoS il convient de leur appliquer.

Path : la rception du message Resv la source met un message Path qui est

transmis de proche en proche jusquau destinataire. Le message Path contient pour

chaque routeur ladresse du nud amont et peut ventuellement contenir une

description du flot lintention du destinataire. La figure 2-1 illustre lacheminement

des messages Resv et Path .



Figure 2-1: principe du RSVP

Dune faon gnrale, RSVP possde les attributs suivants:

o RSVP est unidirectionnel (simplex), car il n'effectue les rservations que pour les flux de donnes unidirectionnels,

o RSVP est orient rcepteur, car le rcepteur d'un flux de donnes initie et maintient la rservation des ressources utilises pour ce flux,

Limitation de RSVP

Le protocole RSVP a besoin de maintenir l'tat d'un flot. Lorsque le nombre d'usagers

augmente, le trafic gnr pour les rafrachissements va de mme. Cela nuit aux performances

du systme dans son ensemble. Devant le niveau de complexit du mcanisme de rservation

de ressources, les gestionnaires de rseaux considrent souvent quil est plus rentable

daugmenter la capacit du rseau que de rserver des ressources.

Etant donn que la QoS devient de plus en plus une exigence, les acteurs sengagent dans une

nouvelle direction dont les architectures reposant sur ltiquetage de priorits dans les paquets

et la classification des services sont plus simples mettre en uvre [7]. Cest le cas des

services diffrencis (DiffServ).

II.3 La diffrenciation de services

Pour palier aux carences dj mentionnes dans les protocoles rservation de ressources de

faon gnrale, le modle de diffrenciation de services dfinit une des approches les plus

prometteuses pour la garantie de la qualit de service de bout en bout.



II.3.1 Principe du service diffrenci

Le modle de diffrenciation de services semble tre plus adquat pour les rseaux multi-

services tel que lInternet. Ce modle signifie en dautres termes donner la priorit une classe

de service au dpend dune autre classe au moment de congestion. Le modle DiffServ

(Differentiated Services) dfinit une approche totalement diffrente en comparaison avec le

modle IntServ (Integrated Services). Il ne ncessite ni une rservation de bout en bout ni

signalisation. Il permet daffecter chaque paquet une classe de service. La complexit est

relgue dans les extrmits du rseau [8]. Les services diffrencis de l'architecture DiffServ

permettent de diminuer substantiellement les informations dtat que chaque nud du rseau

doit mmoriser.

Dans larchitecture DiffServ, le traitement diffrenci des paquets sappuie sur 3 oprations

fondamentales :

o La classification des flux en classes de services ; o Lintroduction de priorits au sein des classes (Scheduling) ; o La gestion du trafic dans une classe donne (Queue management).

Rseau IP

Class 3

Class 1

Class 2

Edge LAN

DSCP Class 2

DSCP Class 3

DSCP Class 1

1 2 3

4 5 67 8 9

* 8 #

Voix

Video

Flots lastiques

Traffic Descriptor (TrafficVolume)+treatment

Edge WAN

Figure 2-2 : classification, marquage et conditionnement du trafic dans le domaine DiffServ

Ainsi, il devient question de supporter un schma de classification en attribuant des priorits

des agrgats de trafic. De ce fait, les paquets sont classs grce un mcanisme de marquage

doctets dans len-tte des paquets IP. Les services qui sont octroys par les routeurs ces

paquets dpendent des classes dfinies. Ce marquage est effectu au niveau de ltiquette de

len-tte du paquet : le DSCP (DiffServ Code Point) qui se situe dans le champ DS de len-tte



IP rserv DiffServ. La figure 2-3 prsente lemplacement des champs CU et DSCP dans les

en-ttes IP. Grce ce marquage et lapproche diffrente de DiffServ par rapport IntServ,

les routeurs DiffServ gardent une certaine souplesse dutilisation du point de vue

acheminement par rapport ceux utiliss dans lIntServ.

Figure 2-3 : insertion du champ DSCP TOS: Type Of Service

DSCP: Differentiated Service Code Point (6bits)

CU : Currently Unused (2bits)

Pour la classe EF DSCP = 101110

Pour la classe AF DSCP = 12 codes

II.3.2 Les comportements PHB (Per Hop Behavior)

L'IETF a dfini deux services du modle DiffServ : EF (Expedited forwarding) dfinie par la

[RFC 2598] et AF (Assured forwarding) dfinie par la [RFC 2597].

L'objectif de EF est de fournir un service de transfert quivalent une ligne ddie, c'est--dire

avec un taux de perte, de dlai et de gigue faibles.

La spcification de AF dfinit 4 classes et 3 niveaux de priorit pour chaque classe. Chaque

classe peut tre vue comme une file d'attente spare utilisant une certaine proportion des

ressources du rseau. Actuellement les relations entre les classes ne sont pas encore

standardises. Pour chaque classe un algorithme de gestion de la file d'attente tenant compte de

la priorit l'cartement des paquets est utilis. En cas de congestion, cet algorithme permet

d'carter en priorit les paquets les moins importants. Pour les flux se servant du comportement

AF, le DSCP des paquets reflte la classe et la priorit l'cartement du paquet. Si les paquets

d'un mme flux doivent appartenir la mme classe pour viter leur dsordonnancement, ils

peuvent avoir des priorits diffrentes l'cartement. Il est ainsi possible d'utiliser ces priorits

pour diffrencier les flux entres eux ou pour diffrencier les diffrentes informations

l'intrieur d'un mme flux.



II. 4 Le protocole MPLS : rservation de capacit et traitement diffrenci Le protocole MPLS (MultiProtocol Label Switching) est utilis dans les rseaux IP pour

permettre de rserver des ressources et prdterminer des chemins. Il fournit des chemins

virtuels ou tunnels travers le rseau pour connecter les nuds qui se trouve la priphrie du

domaine MPLS [9]. Dans le mme concept que larchitecture DiffServ, MPLS permet de

rduire le cot des traitements associs au relayage des paquets en les reportant la priphrie

du rseau et en en rduisant la frquence[10]. Par consquent, le protocole MPLS permet de

rduire le dlai de transmission.

II.4.1 Le principe du MPLS

Le cur du domaine MPLS est constitu de routeurs appels LSR (Label Switching Router)

qui ont pour rle de commuter les flux suivant la valeur du label. Les routeurs de priphrie

sont appels LERs (Label Edge Router) qui ont pour fonction dattribuer ou de retirer les

labels. A lentre du rseau MPLS, les paquets IP sont classs dans des FEC (Forwarding

Equivalent Classes). Des paquets appartenant une mme FEC suivront le mme chemin et

auront la mme priorit et la mme mthode de forwarding . Lensemble des LSR utiliss

pour une FEC, constituant un chemin travers le rseau, est appel Label Switch Path (LSP). Il

existe un LSP pour chaque FEC et les LSP sont unidirectionnels. La figure 2-4 illustre le

principe de fonctionnement du protocole MPLS.

Figure 2-4: Architecture MPLS

II.4.2 Les protocoles de signalisation : RSVP et LDP

Le protocole MPLS utilise lun des deux protocoles de signalisation savoir RSVP

(Ressources Reservation Protocol) et LDP (Label Ditribution Protocol). Le protocole RSVP a



t utilis au dbut dans la modle IntServ puis, il a t adapt au modle MPLS, afin de

permettre la rservation de ressources le long dun LSP.

Afin de rserver les ressources et de grer les LSPs sur un rseau MPLS, il est ncessaire pour

le rseau de possder des moyens de signalisation au niveau du plan de contrle entre LER et

LSR.

Ltablissement dun chemin est bas sur un change de messages. Il y a 4 messages essentiels.

Les messages Label Request et Label Mapping sont utiliss pour ltablissement dun

LSP. Alors que les messages Label Release et Label Withdraw sont utiliss pour librer

un LSP. Dautres messages sont utiliss pour des raisons dinitialisation et de notification et ils

sont moins utiliss que les quatre messages dj mentionns. Tous les messages LDP ont le

format suivant :

Figure 2-5: format dun message LDP

Les messages LDP sont accomplis en envoyant des LDP (Protocol Data Unit) sur des

connexions TCP. Chaque LDP PDU peut transporter un ou plusieurs messages LDP. Par

exemple un PDU peut transporter un message Label Request pour un LSP, un message

Label Mapping dun autre LSP et un troisime message Requesting Label Release . Le

format dune entte LDP est prsente par la figure suivante :

Figure 2-6: format de lentte LDP-PDU

Les formats des diffrents messages ncessaires pour ltablissement et la libration des LSP

vont tre dtailles dans le prochain chapitre.

L IETF a propos deux protocoles de signalisation pour le protocole MPLS savoir CR-LDP

et TE-RSVP. Ces protocoles ont des buts diffrents mais ils peuvent tous les deux tre utiliss



pour la distribution de labels et la rservation de ressources dans un contexte de Traffic

Engineering. Ces deux protocoles sont respectivement les extensions de LDP et RSVP. Le

tableau suivant rsume la diffrence entre ces deux protocoles :

Catgorie CR-LDP RSVP

Gestion dtat Hard state Soft state

Mes messages

dtablissement et de

libration de LSP

Request , Mapping Path, Resv, RESV Comf

Architecture de base Bas sur LDP dvelopp

pour MPLS

Bas sur RSVP mais ncessite des

changements majeurs dans le

protocole de base pour amliorer

sa scalabilit.

Tableau 2-1: comparaison CR-LDP TE-RSVP

Conclusion

Lintgration des services temps rel tels que la voix et les applications multimdia au sein dun rseau Internet qui a t conu pour acheminer du trafic lastique, a multipli les efforts

dans le but de garantir la qualit de service exige par ces applications exigeantes en terme de

QoS. Ces efforts de recherche ont donn naissance des mcanismes de rservation de

ressources et de diffrentiation de services. La rservation de ressources permet de rserver de

la bande. Alors que la diffrenciation de services permet de donner la priorit ce type de

trafic par rapport certains types de trafic.

Chapitre3 : Dimensionnement des artres du backbone MPLS


Chapitre 3: Dimensionnement des artres du backbone MPLS

Introduction

Lamlioration des performances des rseaux est vue par les auteurs [RFC 3272] comme un

dfi doptimisation compos de deux parties : la gestion de capacit et la gestion du trafic.

Logiquement ces deux actions oprent diffrents ports et diffrentes chelles de temps. La

gestion de la capacit consiste faire la planification de la capacit, contrler le routage et

grer les ressources telles que : la capacit des liens et la capacit des buffers.

La planification de la capacit implique la planification des ressources ncessaires dans le

rseau savoir la capacit des liens. Par contre, la gestion du trafic consiste conditionner le

trafic et grer les files dattente.

Quand le rseau est construit pour la premire fois, il doit tenir compte de certaines donnes

physiques et commerciales ainsi que des besoins des utilisateurs court et moyen terme.

Le processus de planification doit rserver des ressources pour chaque type de service en tenant

compte du trafic gnr.

Dans ce chapitre, nous avons essay de dterminer la capacit des liens dans un rseau MPLS

sachant que ce rseau supporte un trafic temps rel comme la voix et un trafic lastique data

(FTP, Web). Dans ce contexte, le dimensionnement dun rseau offrant diffrentes classes de

services ne va tre ni une tache simple ni une tache facile.

I. Dimensionnement dun rseau offrant le service de la voix

Initialement, ltude dun rseau initial se fait en suivant des procdures successives et qui

peuvent tre rvises par la suite. Il y a toujours certains lments auxquels on doit faire

attention dans la conception dun rseau :

1. la planification du trafic : cette procdure consiste dterminer le nombre de clients aux

quels le service est destin ainsi que les diffrents types de services offerts par le rseau.



2. le choix de la topologie du rseau : emplacement des nuds, classification des nuds

(exemple : choix du nombre de nuds dentre et du nombre de nuds du cur dans un

rseau dorsal MPLS).

3. le calcul de la capacit des liens.

Partons dun scnario bien particulier form des hypothses initiales suivantes :

5 sites : S1, S2, S3, S4 et S5

Chaque site est form dun certain nombre dutilisateurs respectivement N1, N2, N3,

N4, N5

Figure 3-1: topologie choisie pour un service de voix

I.1 Dimensionnement du rseau daccs

I.1.1 Modle de trafic

On considre que la loi du trafic voix obit un processus de poisson. La probabilit

dobserver alors k arrives pendant un intervalle de temps t est donne par [11] :

tk

k ekttP =!)()( (3.1)

: tant le taux darrive

On parle alors darrives poissoniennes

La proprit la plus importante du processus de Poisson, peut sinterprter de la faon

suivante : une arrive poissonienne signifie que la probabilit pour quun client arrive pendant

dt est peu prs gale dt

La deuxime proprit essentielle du processus de Poisson relie le processus darrive

poissonien aux variables alatoires mesurant le temps dinter-arrive (exponentielles). Cette



proprit sinterprte de la faon suivante : des arrives poissoniennes signifie que les inter-

arrives sont de type exponentielles.

Les lois dErlang qui sont utilises pour le dimensionnement des rseaux offrant le service de

la voix, se basent sur lhypothse que les services sont exponentiels et les arrives sont de type

poissoniennes.

I.1.2 Lois dErlang

Le choix des lois dErlang dans plusieurs projets est justifi par le fait quelles donnent

gnralement des rsultats raisonnables.

Les formules sont utilises dans les conditions suivantes :

le nombre de clients est suprieur au nombre de ressources disponibles pour les servir.

les demandes des clients sont indpendantes les unes des autres

Dans les rseaux tlphoniques classiques, la loi la plus utilise est celle dErlang B. Pour la

voix sur IP, les oprateurs conservent toujours cette formule dans leur procdure de

dimensionnement du rseau daccs. La loi dErlang B permet de calculer la probabilit quune

demande de ressource sera rejete raison de ressources non disponibles. La probabilit de

blocage sera alors gale

),(

!

!1

0

nAE

iA

nA

pn i

n

n ==

(3.2)

o

n : le nombre de ressources disponibles

A : le trafic offert

pn : la probabilit que les n ressources soient occupes

E1 : la premire formule dErlang qui est fonction de A et n

I.1.3 Dbit daccs

Pour chaque site, on peut calculer le dbit daccs en suivant les tapes suivantes :

Calculer le dbit par appel

Calculer le nombre de circuits

I.1.3.1 Dbit par appel

Le dbit daccs peut tre calcul en tenant compte des lments suivant :



les codecs audio utiliss au niveau de la couche application

les diffrentes encapsulations aux niveaux des diffrentes couches (transport, rseau)

les protocoles au niveau de la couche liaison.

a. Les codecs audio

Les codecs les plus utiliss pour la compression/dcompression de la voix sur IP sont : G.711 offrant un dbit de 64 Kbit/s

G.723 offrant un dbit de 6.3 et 5.3 Kbit/s

G.729 offrant un dbit de 8 Kbit/s

Selon le dbit gnr par le codec et en tenant compte des diffrentes possibilits des cycles de

transmission, on peut obtenir la taille des donnes audio (data voice). Ces donnes audio vont

subir des encapsulations au niveau des diffrentes couches commenant par la couche transport

jusqu arriver la couche liaison de donnes.

b. Les encapsulations au niveau transport et rseau

Les donnes audio de la couche application sont affectes au niveau de la couche transport

dune entte RTP ayant une taille minimale de 12 octets, puis dune entte UDP avec 8 octets

enfin la mise en paquet au niveau de la couche rseau ajoute 20 octets pour lentte IP. La

figure suivante illustre le principe de la mise en paquet.

Figure 3-2 : encapsulation RTP/UDP/IP

Les diffrents champs de chaque protocole sont prsents comme le montre les figures 3-3, 3-4

et 3-5.

Figure 3-3: format de lentte RTP



Figure 3-4: format de lentte UDP

Figure 3-5 : format de lentte IP

Les 20 octets du protocole IP quon a considr ne tiennent pas compte des champs Options et

Padding.

c. Les protocoles utiliss au niveau de la couche liaison

Lencapsulation doit tenir compte des diffrents protocoles en niveau de la couche liaison.

Ethernet

La technologie Ethernet est la technologie la plus rpondue dans les rseaux dentreprises

(LAN). La structure de la trame Ethernet est donne par la figure suivante :

Figure 3-6: format de trame Ethernet



High level Data Link Contro(HDLC): ce protocole permet une liaison point point ou point

multipoint et une transmission synchrone. Il se base galement sur le principe de fentre

coulissante. La taille des donnes dans la trame HDLC est variable. La structure de la

trame en HDLC est prsente par la figure 3-7

Figure 3-7 : format de trame HDLC

Frame Relay (FR): ce protocole est utilis dans les rseaux maills. Il assure ltablissement

de circuit virtuel entre deux usagers.

Figure 3-8: format de trame Frame Relay

Point to Point Protocol (PPP): ce protocole est utilis pour transporter des paquets entre

deux usagers travers des liens simples. Ces liens fournissent des transmissions

simultanes full-duplex.

Figure 3-9: format de trame PPP

Asynchronous Transmission Mode (ATM) : ce protocole se base sur la transmission de

cellules lintrieur dun circuit virtuel. Son principal intrt est quil permet la rservation

de ressources pour un CV (circuit virtuel). Le format de la trame ATM est prsent par la

figure 3-10.

Figure 3-10: format de trame ATM



La signification des diffrents champs nest pas aussi importante que la taille des donnes

quajoute chaque protocole. Le dbit gnr sur le support physique varie avec la variation des

diffrents paramtres cits ci-dessus.

Pour chaque site, on suppose quon a un choix uniforme entre les diffrents utilisateurs des

diffrents paramtres : codec, cycle de transmission, protocole de couche liaison.

La formule qui permet de calculer le dbit par appel est la suivante :

transiaisonprotocoleliaisonprotocolelIPUDPRTPtranscodecapl cycleenqueueentteenttecycleDbitDbit /8])[( // +++= (3.3)

o aplDbit : dbit par appel en Kbit/s

o codecDbit : dbit gnr par le codec en Kbit/s o transcycle : le cycle de transmission de paquet en ms o IPUDPRTPentte // : la taille lentte RTP/UDP/IP ajouter en octets o iaisonprotocolelentte : la taille de lentte du protocole de couche liaison en

octets

o iaisonprotocolelenqueue : la taille de lenqueue du protocole de couche liaison en octets

I.1.3.2 Calcul du nombre de circuits

Lalgorithme de la formule dErlang inverse permet de dterminer le nombre de circuits

mettre en oeuvre pour supporter un trafic donn avec une probabilit de blocage fixe [12].

Figure 3-11 : lalgorithme dErlang inverse

non

oui non

oui

non E(A,n)=



A : trafic offert

n : nombre de circuit

E : formule dErlang

p: probabilit de blocage fix par loprateur

On peut calculer la bande passante ncessaire partir du nombre de circuits et le dbit par

appel.

nbDbitbande apl = circuit (3.4)

La mme mthodologie sera applique pour les autres sites.

I.2 rseau dorsal IP/MPLS

Dans cette partie, on va dtailler le calcul des capacits pour les diffrentes artres.

I.2.1 Choix de la topologie

La topologie mettre en uvre est prsente par la figure 3.12.

Figure 3-12 : topologie choisie du backbone MPLS

Le rseau dorsal MPLS est form comme le montre la figure ci-dessus par 5 routeurs la

priphrie (LER) et quatre routeurs au coeur du rseau (LSR). Pour des raisons de

simplification, on suppose que les Edge Router neffectuent pas dopration de commutation

des paquets. En plus, les flux entrants au domaine MPLS par un Ingress LSR ayant pour

destination un Egress LSR qui lui est adjacent doivent passs obligatoirement par un LSR

appartenant au cur du backbone MPLS. Les numros en noir reprsentent les mtriques des

liens associs aux distances. Les Li reprsentent les numros des liens et ceci pour tout i de 1

13.



I.2.2 Le dbit la sortie du routeur daccs LER (Label Edge Router)

Supposons que chaque site est li un edge router et que le dbit daccs sera le trafic

lentre de chaque LER. MPLS est un protocole qui fonctionne entre la couche rseau et la

couche liaison. Le format de lentte MPLS est prsent par la figure 3-13.

Figure 3-13: format de lentte MPLS

label cod sur 20 bits : rfrence utilis pour router un paquet

Bits exprimentaux EXP sur 3 bits : pour identifier diffrentes classes de trafics pour

supporter les modles de QoS de Diffserv.

BS : Bottom Stacking sur 1 bit : un bottom stack est mis 1 pour indiquer la dernire

pile entre.

TTL : Time To Live sur 8 bits : il a la mme signification quen IP

a. Dbit pour le cas de lATM et du Frame Relay

Au dessus dATM, le label est insr dans les champs VPI/VCI.

Figure 3-14 : encapsulation du paquet labellis sur la couche ATM

Il est de mme pour le protocole FR puisque le label va tre insr dans le champ DLCI.

b. Dbit pour le cas de lEthernet, PPP et HDLC

Le dbit la sortie du LER dans ce cas sera diffrent de celui lentre puisque lajout dune

entte MPLS 4 octets va influer sur le dbit. La procdure de calcul de dbit sera semblable

celle de calcul du dbit par appel mais dans ce cas, on ajoute lentte MPLS entre les couches 2

et 3.



Figure 3-15: encapsulation de lentte MPLS dans les protocoles lEthernet, PPP et HDLC

c. Estimation du trafic entre les Edge Router

On peut de cette manire estimer le trafic entre les diffrents routeurs de la priphrie deux

deux pour construire une matrice de trafic. La distribution du trafic lentre de chaque Edge

router se fait selon

o le nombre dutilisateurs lis chaque site. o le plus court chemin entre deux edge routers.

La matrice de trafic aura alors la forme suivante entre les diffrents noeuds:

0 A12 A 13 A14 A15 A21 0 A23 A24 A25

Ttraffic A31 A32 0 A34 A35 Aij : le trafic gnr entre les nuds dextrmit i et j

A41 A42 A43 0 A45

A51 A52 A53 A57 0

Cest une matrice diagonale nulle puisquon ne tient pas compte de la communication intra-

site.

Exemple :

Le trafic T1 qui entre dans le domaine MPLS par le nud 1 va tre distribu selon le

pourcentage du nombre dutilisateurs dans les autres sites. Partons alors des hypothses

suivantes pour le nombre dutilisateurs au niveau des sites :

N2=400 utilisateurs N3=150 utilisateurs

N4=230 utilisateurs N5=120 utilisateurs

Dans ce cas le trafic T1 destins respectivement aux sites S2, S3, S4 et S5 sont les suivants :

S2 : 44% T1S3 : 16% T1S4 : 25% T1S5 : 15% T1



I.2.3 Calcul des capacits

I.2.3.1 Capacit du plus court chemin entre deux LERs

Supposons quon sintresse aux trafics A13 et A31 entre les nuds 1 et 3. Ces trafics suivront

le plus court chemin entre ces deux nuds. Les diffrentes mtriques possibles 31, 36, 23, 42,

35 et 50. Donc le plus court chemin sera celui qui passe par les routeurs internes 1-4-3

travers les liens L3, L13, L8 et L6. Cest ce chemin qui vhicule la totalit du trafic entre les

nuds 1 et 3. Ce chemin doit tre capable de supporter le maximum de la charge entre ces deux

nuds.

Dans tous les cas, le trafic suit le plus court chemin pour des raisons de cot et de qualit de

service (QoS) puisque le plus court chemin assure gnralement un dlai faible.

Le chemin le plus court doit supporter la somme des deux trafics tant donne que les artres

sont considres en full-duplex.

Dans le processus de dimensionnement on doit tenir compte dun autre facteur part la qualit

de service savoir la disponibilit du rseau. Pour cela, si le plus court chemin est incapable de

vhiculer le trafic entre deux sites donns, les chemins alternatifs doivent partags ce trafic

suivant des coefficients bass sur des mtriques de distances croissantes. En dautre terme, plus

le chemin alternatif est court, plus la portion de trafic quil supporte sera importante.

I.2.3.2 Capacit des liens individuels

Dans ce cas, on doit tenir compte des diffrents trafics achemins entre les diffrents sites. On

suppose pour cela quil existe des trafics entre les diffrents sites. Au pire des cas, chaque lien

doit tre dimensionn de telle faon quil supporte la totalit du trafic qui le traverse.

= +=

=1

1 1

n

i

n

ijijvijvkv TC (3.5)

kvC : la capacit du lien individuel pour le trafic voix

ijvT : le trafic entre les sites i et j ijjiijv TTT += (3.6)

ijv : un coefficient de pondration attribu au chemin supportant le trafic voix entre le site i et le site j.

Etant donn quil existe plusieurs chemins entre deux nuds i et j et tant donn que le plus court

chemin oit supporter la totalit du trafic, les autres chemins doivent partager le trafic entre eux selon des

coefficients de pondration.



I.2.4 Dbit gnr par la signalisation

La signalisation engendre un trafic qui peut charger le rseau et donc il est parfois ncessaire

de tenir compte de ce trafic lors du dimensionnement.

Deux protocoles de signalisation peuvent tre mis en uvre dans les domaines MPLS afin

dassurer la rservation des ressources et ltablissement des LSPs entre deux LER. Nous nous

somme intresss dans ce projet au trafic gnr par le protocole CR-LDP. Le choix du

protocole CR-LDP est justifi par le fait que ce protocole a t dvelopp pour fonctionner sur

MPLS alors le protocole RSVP a t adapt pour fonctionner dans un domaine MPLS. Durant

la phase de signalisation, on peut tenir compte uniquement du dbit engendr par:

o les messages daffectation de label Label Request et Label Mapping o les messages de libration de LSP Label Release et Label Withdraw o les figures 3-16, 3.17, 3.18 et 3.19 prsentent le format de ces quatre types de messages.

Le Label Request message est utilis par un Upstream LSR pour demander un

downstream LSR lallocation de Label. Dune faon gnrale, cest une requte

dtablissement de connexion.

Figure 3-16 : format du message Label Request

Le message Label Mapping est utilis par le downstream LSR pour annoncer la

construction dun label pour une adresse de destination. Il est envoy aprs la rservation de

ressources et ltablissement de connexion pour faire le mapping entre les incoming label et les



outgoing label. Il apporte le label assign la connexion partir du commutateur downstream

au commutateur upstream.

Figure 3-17: format du message Label Mapping

Le message Label Withdraw est utilis pour demander la libration dun LSP. Ce message

est envoy par un downstream LSR un upstream LSR parce que cest lui qui contribue

laffectation de label.

Figure 3-18 : format du message Label Withdraw



Le message Label Release est utilis par un upstream LSR pour confirmer la libration dun

LSP. Un upstream LSR peut envoyer un message Label Release sans recevoir un message

Label Withdraw partir dun downstream LS.

Figure 3-19 : format du message Label Release

Pour dterminer le trafic engendr par la signalisation, on a procd comme suit :

Dterminer le nombre dappels entre le noeud i et le nud j quelque soit i et j

iapl

jijiapl D

TN

= (3.7)

jiT : le trafic du site i au site j

iapl

D : le dbit par appel au niveau du site i

Calculer le dbit de la signalisation : tant donn que les signalisations ncessaires

ltablissement et la libration ne seffectuent pas en mme temps, on peut

dimensionner les liens de telle manire quil supporte la signalisation qui fournit plus de

dbit.

En examinant les formats des 4 messages de signalisation prsents dans les quatre dernires

figures, on constate que les messages dtablissement dun LSP fournissent le maximum de

dbit. La signalisation entre deux sites tient compte du nombre dappels et du dbit de

signalisation.

isigaplji DNS ji = (3.8)

Dimensionnement d Un Backbone IP-MPLS -WALHA_Nada 2005

Documents

Transcript of Dimensionnement d Un Backbone IP-MPLS -WALHA_Nada 2005