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
Avant propos
Ce
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.
Je
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.
Je tiens exprimer mes respects tout le personnel du CERT pour my avoir

accueillie et mavoir permise de travailler dans de bonnes conditions.
Merci 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.
Merci 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
ii
Notre vie vaut ce quelle nous a cot defforts

Franois Mauriac
iii
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
iv
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
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
vi
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
vii
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
viii
Acronymes
A
AAL5 ABR AF ATM ATM Adaptation Layer5 Available Bit Rate Assured forwarding Asynchronous Transmission Mode Batch Markovian Arrival Process Bottom Stacking Capital Expenditure Constraint Routing-Label Distribution Protocol Currently Unused Data Link Connection Identifier DiffServ DiffServ Code Point Expedited forwarding Forwarding Equivalent Class Frame Relay High Data Link Control HyperText Transfer Protocol Integrated Development Environment Internet Engineering Task Force Internet Protocol ISDN User Part Local Area Network Label Edge Router Location Server Label Switching Path Label Switching Router ix
B
BMAP BS
C
CAPEX CR-LDP CU
D
DLCI DS DSCP
E
EF
F
FEC FR
H
HDLC HTTP
I
IDE IETF IP ISUP
L
LAN LER LS LSP LSR
M
MCU NGN MP MPLS Multipoint Controller Unit Next Generation Network Multipoint Processor MultiProtocol Label Switching Operational Expenditure Personal Computer Pulse Code Modulation Per Hop Behavior Point to Point Protocol Proxy Server Permanent Virtual Channel Quality of Service Request For Comment ReGistrar Rseau Numrique Intgration de Service Redirect Server Ressource Reservation Protocol Real Time Control Protocol Real Time Protocol Session Announcement Protocol Service Level Agreement Simple Network Management Protocol Transmission Control Protocol Traffic Engineering- Ressource Reservation Protocol Type Of Service Time To Live User Datagram Protocol Union Internationale de Tlcom Virtual Channel Identifier Voice Over IP Virtual Path Identifier Wavelength Division Multiplexing
O
OPEX
P
PC PCM PHB PPP PS PVC
Q
QoS
R
RFC RG RNIS RS RSVP RTCP RTP
S
SAP SLA SNMP
T
TCP TE-RSVP TOS TTL
U
UDP UIT-T
V
VCI VoIP VPI
W
WDM
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
La configuration PC to phone ou phone to PC : Si lappelant est un microordinateur, 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 4 7 *
2 5 8 8
3 6 9 #
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 4 7 *
2 5 8 8
3 6 9 # 1 2 4 5 7 8 * 8 3 6 9 #
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 D = DE + D N + DR Avec :
DE = Dcod + Dcomp + D paq D N = D prop + Dcomm + D file DR = Dbuf + Ddpaq + Ddcom + Ddcom
(1.1)
(1.2) (1.3) (1.4)

DE : le dlai de lmetteur
Dcod : le temps ncessaire au codage
Dcomp : le temps de compression D paq : le temps de mise en paquet.
D N : le dlai du rseau
D prop : le temps de propagation
Dcomm : le temps de commutation

D file : le temps de mise en file dattente.
DR : le dlai du rcepteur
Dbuf : le temps de sauvegarde dans le buffer de gigue Ddepaq : le temps de dpaqutisation
Ddecom : le temps de dcompression Ddecod : 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
Dlai de transit Gigue de phase Perte de donnes D<150 ms G<20 ms P<1%
Moyen
150 ms<D< 400 ms 20 ms <G< 50ms 1% <P<3%
Mauvais
D> 400 ms G>50ms P>3%
Tableau 1-1 : recommandation G.114 de lUIT-T
III.1.2 La gigue La gigue est la variation du dlai de transmission due une charge ponctuelle dans le rseau ou une variation des dlais de transmission. Pour rsoudre le problme de gigue, on peut utiliser le buffer de gigue. Mais lutilisation du buffer peut se traduire par un dlai et une perte de paquets supplmentaires si le paquet arrive aprs le dlai maximum autoris par le buffer. La figure 1.4 montre le principe du buffer de gigue. Le dlai de bufferisation est donn par lquation suivante. Dbuff = Dapp
Dbuff : dlai de bufferisation Drel
(1.5)

Dapp : dlai apparant sur le rseau : cest un dlai choisi et fix comme temps de
transmission sur le rseau. Drel : 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.
10
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 hertz G.711 PCM 300-3400 hertz 8000 Kbit/s 64 basse trs bonne qualit de restitution de la voix au dtriment dune consommation de bande passante leve pour lInternet, mais
frquence dchantillonnage
vitesse
complexit
commentaire
11

acceptable dans le cadre dun rseau local. G.722 SB-MICDA 300-3400 16000 48 56 64 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 G.729 LD-CELP CS-ACELP 300-3400 300-3400 8000 8000 16 8 13 basse 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 moyenne
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
12

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

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
14

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
15

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 Spcification : organisme, date Modle dorigine Applications vises Service de tlphonie Protocoles de transfert : donnes, multimdia Implmentation Extensibilit Interoprabilit entre constructeur Maturit SIP IETF, 1999 Internet, www VoIP, multimdia Encore limit RTP/RTCP Simple (ASCII, protocoles IP : http, DNS, adresse URL) Oui Elev Faible (service, produits) H.323 UIT, 1996 Tlphonie : RNIS VoIP, vido streaming Elabor RTP/RTCP Plus complexe Faible (complexe, forte augmentation du volume de code) Limit Bonne (produits)
Tableau 1-3 : comparaison entre les protocoles SIP et H.323
16
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.
17
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
18

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 multiservices

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

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
20

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 .
21
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.
22

II.3.1 Principe du service diffrenci Le modle de diffrenciation de services semble tre plus adquat pour les rseaux multiservices 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).
Traffic Descriptor (Traffic Volume)+treatment
Class 3 DSCP Class 3 DSCP Class 2 Class 1 Edge LAN DSCP Class 1
Class 2
Video
Rseau IP
Edge WAN
Flots lastiques
1 4 7 *
2 3 5 6 8 9 8 #
Voix
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
23

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

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
25

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
26

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
Gestion dtat Mes messages dtablissement et de libration de LSP Architecture de base
CR-LDP Hard state Request , Mapping
RSVP Soft state Path, Resv, RESV Comf
Bas sur LDP dvelopp Bas sur RSVP mais ncessite des pour MPLS 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.
27
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.
28

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] : Pk (t ) = : 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
( t) k e k!
(3.1)
La deuxime proprit essentielle du processus de Poisson relie le processus darrive poissonien aux variables alatoires mesurant le temps dinter-arrive (exponentielles). Cette
29

proprit sinterprte de la faon suivante : des arrives poissoniennes signifie que les interarrives 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
An p n = n n! i = E 1 ( A , n ) A i! 0
(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 :
30

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

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
33

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 :
Dbit apl = [( Dbitcodec cycletrans ) + entteRTP / UDP / IP + entte protocoleliaison + enqueue protocoleliaison ] 8 / cycletrans (3.3)
o o o o o
Dbit apl : dbit par appel en Kbit/s
Dbit codec : dbit gnr par le codec en Kbit/s cycletrans : le cycle de transmission de paquet en ms entte RTP / UDP / IP : la taille lentte RTP/UDP/IP ajouter en octets
entte protocoleliaison : la taille de lentte du protocole de couche liaison en
octets o
enqueue protocoleliaison : 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].
n=A oui E(A,n)=<p
non
n++
n--
non oui
E(A,n)=<p
E(A,n)>=p non oui
n Figure 3-11 : lalgorithme dErlang inverse
n++
34

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.
bande = Dbit
apl
nb 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.
35

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.
36
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 A21 Ttraffic A31 A41 A51 A12 0 A32 A42 A52 A 13 A23 0 A43 A53 A14 A24 A34 0 A57 A15 A25 A35 A45 0
Aij : le trafic gnr entre les nuds dextrmit i et j
Cest une matrice diagonale nulle puisquon ne tient pas compte de la communication intrasite. 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 N3=150 utilisateurs N5=120 utilisateurs suivantes pour le nombre dutilisateurs au niveau des sites : N2=400 utilisateurs N4=230 utilisateurs S2 : 44% T1 S3 : 16% T1 S4 : 25% T1 S5 : 15% T1
Dans ce cas le trafic T1 destins respectivement aux sites S2, S3, S4 et S5 sont les suivants :
37

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.
n 1 n ijv
C kv =
C
kv
i =1 j = i + 1
T ijv
(3.5)
: la capacit du lien individuel pour le trafic voix

Tijv = Ti
j
Tijv : le trafic entre les sites i et j

ijv
+ Tj
(3.6)
: 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.
38

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
39

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
40

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
N
Ti
j
apl i
Ti D
j apl i
(3.7)
: le trafic du site i au site j
Dapl i : 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.
Si
= N apl i
D sig i
(3.8)
41

D sig
i
: le dbit de signalisation par appel au niveau du noeud i
N apl i
: le nombre dappels du noeud i au noeud j

Dsig i = Tsig t apl
(3.9)
Tsig : taille de la signalisation par appel t apl : dure dun appel de i j
Etant donn que les liaisons sont de type full-duplex, on doit tenir compte de la signalisation dans les deux sens.
Sij = Si
+ Sj
Concernant la dtermination de la capacit des liens pour la signalisation, on suit le mme principe que pour le trafic voix.
II. Dimensionnement pour un rseau offrant le service data

Jusqu aujourdhui, le service data est le service dominant sur le rseau IP bien quon cherche intgrer dautres services temps rel. Mais, ce service est moins prioritaire puisquil na pas de contraintes de temps de transmission. Un consensus gnral existe sur le fait que le trafic data sur IP nest pas poissonien. Cependant les recherches ne sont pas daccord sur lapproche quon peut adopter pour modliser le trafic sur Internet. Le modle BMAP (Batch Markovian Arrival Process) a t exploit pour modliser le trafic IP. Ce modle est conforme au trafic data o le besoin en dbit des utilisateurs est alatoire. En effet, les flux arrivent parfois en lots, parfois lactivit des utilisateurs est nulle. Il est trs difficile destimer le trafic data gnr par les utilisateurs. Pour le Web par exemple, la mesure du trafic se base sur lobservation des traces des fichiers Log du cot client et du cot serveur (respectivement Upload et Download).
II.1 Etude dun cas particulier

En se basant sur les contrats SLA (Service Level Agreement) entre les oprateurs et les abonns et en partant dun cas particulier de deux types de contrats quon a nomm respectivement SLA1 et SLA2 : SLA1 : garantissant un dbit montant de 64 Kbit/s et un dbit descendant de 128 Kbit/s SLA2 : garantissant un dbit montant de 128 Kbit/s et un dbit descendant de 256 Kbit/s
42

Etape pour ltude du trafic Data Chaque site possde un nombre dabonns bien particulier. Pour chaque site, il y a un certain pourcentage dutilisateurs qui demandent un service de type SLA1 alors que les autres demandent un service de type SLA 2. Chaque trafic va transiter travers un backbone IP/MPLS pour atteindre le rseau Internet qui est reli un parmi les Edge nodes du rseau dorsal. Dans cette topologie le rseau Internet est accessible partir du LER 4 comme le montre la figure 3-20.
Figure 3-20: modification de la topologie pour un trafic data
II.2 Principe de distribution de charge

On a adopt la mme topologie que dans le cas de la voix sauf quon a ajout au niveau du site 4 une connexion un rseau Internet. Par la suite, on va procder comme suit : Calculer le dbit du lien montant au niveau de chaque site selon les diffrents types de contrats tablis entre loprateur et les clients suivant un accs ADSL.
Dup i = N 1i * 64 + N 2i *128
N 1i : reprsente le nombre dabonns du site i ayant un contrat SLA1 N 2i : reprsente le nombre dabonns du site j ayant un contrat SLA2
(3.10)
Calculer le dbit des liens descendants selon les conditions imposes par les contrats.
Ddown i = N 1i *128 + N 2i * 256
(3.11)
II.3 Capacit des liens

La dtermination des capacits suivra le mme principe que pour la voix.
43

II.3.1 Capacit du plus court chemin pour le trafic data Le trafic dans les deux sens (montant et descendant) va suivre le plus court chemin. Ce dernier va tre dimensionn de telle faon quil supporte la totalit du trafic afin dassurer certaines exigences en terme de qualit de service telles que: un dlai faible et un cot minimal. Il est essentiel de prvoir dautres chemins alternatifs qui vont partager respectivement les trafics upload et download. Cette distribution de charge se fait selon des coefficients de pondration et elle est utile surtout en cas de surcharge au niveau du plus court chemin ou lorsque ce chemin nest pas fonctionnel. II.3.2 Capacit des liens individuels pour le trafic data Dans ce cas, on a suivi le mme principe que pour le trafic voix. De faon gnrale, on suppose que laccs Internet est possible partir dun noeud i
n j =1 i j ijd
C kd =
T ijd
(3.12)
Tijd = Ti
+ Tj
C kd : capacit du lien individuel k

ij
: coefficient de pondration attribu au chemin supportant le trafic data entre le noeud i et j
II.4 Capacit des liens supportant le trafic voix et data

Pour les liens qui vont supporter le trafic data et le trafic voix, la capacit du lien doit tre capable de supporter les deux trafics en mme temps. La capacit totale doit tre gale la somme des deux capacits. Cette capacit a t rpartie suivant des coefficients entre le trafic temps rel (voix) et le trafic lastique. Pour le trafic data, on na pas besoin de calculer le dbit de la signalisation pour connatre la capacit des liens. On fait le dbit dfinit dans le contrat et que loprateur doit garantir tient compte de la signalisation. On peut tenir compte de lvolution du rseau. Pour cela, on peut ajouter un certain pourcentage la capacit du rseau.
Conclusion
Lun des moyens pour dimensionner un rseau est de dterminer les capacits des diffrents liens au niveau de ce rseau. La dtermination de ces capacits doit tenir compte de certains lments tel que : le trafic gnr par appels, le nombre dappels et surtout la manire avec
44

laquelle sont rparties les diffrents trafics entre les diffrents sites. Le passage dun service voix un service data, permet de modifier le comportement du rseau et la distribution de charge.
45
Chapitre 4 : dveloppement dun outil de dimensionnement
Chapitre 4: Dveloppement dun outil de dimensionnement

Introduction
Dans le chapitre prcdent, nous avons prsent la mthode utilise pour le dimensionnement dans les rseaux multiservices. Nous nous sommes intresss particulirement au dimensionnement des capacits des artres. Dans ce chapitre, on se propose dlaborer un outil logiciel de dimensionnement de ces capacits en intgrant la mthode dj prsente dans le chapitre prcdent. La prsentation des diffrentes fonctionnalits de loutil sera faite travers la description de ses interfaces.
I. Lenvironnement de dveloppement
Lenvironnement de dveloppement choisi pour raliser ce travail est le VC++. Son principal intrt est son approche objet. Un programme n'est plus vu comme une suite de fonctions appeles les unes aprs les autres mais comme une manipulation plus ou moins complexe d'objet : c'est--dire de types cres par l'utilisateur. Ces classes (ou objets) articulent le programme [13]. Par son approche objet, le C++ permet de grer d'normes projets (normes en termes de taille) tout en restant adaptable au besoin et maintenable mais au prix d'une lgre lourdeur syntaxique. Un autre avantage du VC++ est quil permet doffrir lutilisateur une interface graphique sous forme de boite de dialogue. Le Visual C++ intgre lenvironnement de dveloppement IDE (Integrated Development Environment) environnement autonome qui permet de crer, de compiler et de tester des programmes Windows [14].
II. Organigramme de dimensionnement

Lorganigramme suivant rsume les diffrentes tapes suivies pour le dimensionnement des capacits des artres dans le backbone MPLS.
46

Nombre dabonns du site
Dbit par appel
Trafic Data Dbit dans le rseau daccs Trafic dans le backbone MPLS
Entte MPLS Signalisation
Capacit de lartre
Figure 4-1: organigramme de dimensionnement
III. Description de loutil

Cette partie est consacre la description fonctionnelle de loutil. Cet outil est nomm DIMIP . Comme il a t dj mentionn, son rle est de prsenter une interface conviviale pour aider au dimensionnement des artres dun backbone MPLS. Dans ce paragraphe, nous allons dcrire le fonctionnement de loutil ralis. Lutilisation de loutil commence par laccs la fentre principale qui est prsente par la figure ci-dessous :
Figure 4-2 : la boite de dialogue principale
III.1 Lentre des informations sur le site

Lutilisateur peut saisir les informations sur le site choisi grce la boite de dialogue Information Site. Le choix du site nous permet dafficher le nombre dutilisateurs et de faire
47

entrer la probabilit de blocage et le pourcentage dutilisateurs ayant respectivement des contrats SLA 1 et SLA 2. Capacit Voix : ce bouton permet daccder la boite de dialogue Rseau daccs Capacit data : ce bouton permet daccder la boite de dialogue Data La figure 4-3 montre linterface qui permet dentrer les diffrents paramtres cits si dessus.
Figure 4-3 : saisie des informations sur site
III.2 Calcul de la bande pasante au niveau de chaque site

La fentre Rseau daccs permet de calculer la bande passante en faisant des calculs intermdiaires qui consistent dans le calcul du o nombre de circuits o dbit par appel Le tableau 4-1 montre les relations entre les diffrentes variables affiches dans la boite de dialogue Rseau daccs.
Variables dentre Variables de sortie 1 Variables de sortie 2
-Probabilit de blocage -taux darrive -temps de service -codec -cycle de transmission -protocole de couche liaison
nombre de circuits
Bande passante
Dbit par appel
Tableau 4-1 : paramtres dentre et paramtres de sortie de la fentre Rseau daccs
48

La figure 4-4 montre un exemple de calcul pour dterminer la bande passante.
Figure 4-4 : calcul de la bande passante par site
o o o
Quitter : ce bouton permet de quitter linterface Calculer : permet de calculer le dbit par appel, le nombre de circuits et la bande passante Voir la rpartition : ce bouton permet dafficher la boite de dialogue Voix
III.3 Calcul de la capacit du lien

III.3.1 Calcul de la capacit du lien pour le trafic voix Cette opration peut tre ralise grce la boite de dialogue Voix. Le calcul de la capacit des liens ncessite de connatre tous les trafics possibles entre les diffrents nuds du backbone MPLS. Pour cela, on doit rpartir le trafic lentre de chaque nud du backbone MPLS. Rpartir le trafic entre les diffrents nuds se fait selon le nombre dutilisateurs dans chaque site. Le calcul de la capacit pour la voix est conforme la formule (3.5). Le bouton Ajout signalisation permet dafficher la boite permettant de calculer la capacit totale pour le trafic voix et la signalisation introduite le protocole CR-LDP.
49
Figure 4-5 : calcul de la capacit du lien pour le trafic voix
III.3.2 Calcul de la capacit du lien pour la voix et la signalisation Calculer la capacit du lien pour la voix et la signalisation ncessite de majorer la capacit du lien choisi au niveau de linterface de la figure 4-5 par un dbit engendr par la signalisation. La figure 4-6 permet dafficher le rsultat de ce calcul.
Figure 4-6: capacit totale pour la voix (ajout de la signalisation)
50

III.3.3 Calcul de la capacit totale du lien Le calcul de la capacit totale ncessite dajouter au rsultat du calcul prcdent les trafics data possibles sur chaque lien. Les paramtres dentrs et de sortie peuvent tre rsums dans le tableau 4-2 Paramtres dentre -Dbit upload -Dbit download -lien -trafic data avec le nud li au site Capacit du lien (data) daccs Internet -Capacit du lien (data) -Trafic voix -Dbit signalisation
Tableau 4-2 : paramtres dentre et de sortie pour la boite de dialogue capacit totale
Paramtre de sortie Dbit data au niveau du nud dentre
Capacit totale
La figure 4-7 montre le rsultat de calcul de la capacit totale.
Figure 4-7 : calcul de la capacit totale
51

o Capacit lien : ce bouton permet dafficher la capacit du lien choisi pour le trafic data uniquement. o Afficher capacit totale : ce bouton permet de calculer la capacit du lien choisi en tenant compte du trafic voix, de la signalisation ainsi que du trafic data.
IV. Influence de certains paramtres sur les rsultats de calcul

Dans la boite de dialogue Rseau daccs, certains rsultats peuvent tre influencs par la variation de la variable dentre. Les rsultats affichs sont : le nombres de circuits, le dbit par appel et la bande passante. Loprateur cherche diminuer le nombre de ressources mettre en uvre pour des raisons de cot. Pour lui, il est ncessaire aussi que le dbit soit le plus faible possible pour des raisons de surcharge de son rseau. Influence du trafic sur le nombre de circuits : la comparaison de la figure 4-8 avec la figure 4-4 montre que plus le trafic augment plus le nombre de circuits rserver augmente.
Figure 4-8 : Influence du trafic
Influence du codec sur le dbit par appel : le rsultat concernant le dbit par appel montre que plus le dbit du codec est faible plus le dbit par appel est faible (voir figure 4-8 et 4-9).
52
Figure 4-9: Influence du CODEC
Influence du cycle de transmission sur le dbit par appel : laugmentation du cycle de transmission permet de diminuer le dbit par appel comme le montre la comparaison entre la figure 4-9 et 4-10.
Figure 4-10: Influence du cycle de transmission
53

Influence du protocole sur le dbit par appel : Plus la taille de lentte ajouter par le protocole est faible, plus le dbit est rduit. Ceci peut tre illustr par une comparaison entre les figures 4-10 et 4-11.
Figure 4-11: Influence du protocole de la couche liaison
V. Simulation
V.1 Topologie simuler
Cette topologie est semblable celle prsente dans la figure 3-13 concernant la topologie du backbone MPLS. Les nuds 0, 1, 2, 3, 4, 6, 7, 9, 11, 12, 13, 15 et 16 reprsentent les nuds sources de trafic. Les nuds 5, 8, 10, 14, et 17 reprsentent des nuds IP. Le reste des nuds reprsentent les nuds du backbone MPLS. Cette simulation a t ralise par le simulateur rseau NS-2.
Figure 4-12: Topologie simuler
54

V.2 Scnario
Lobjectif de la simulation est de prsenter le nombre de paquets perdus au niveau des routeurs daccs (LER) du backbone MPLS. On a alors les suppositions suivantes : La mesure du taux de perte se fait pour le service voix. La simulation se concentre sur la perte au niveau du nud MPLS n18. Tous les liens sont de type full-duplex. Chaque source est capable dmettre et de recevoir en mme temps. Ces communications sont supposes se drouler comme suit : o 0, 1, 2, 3 et 4 avec respectivement 11, 12, 13, 15 et 16 o 6 et 7 avec 9
Figure 4-13: scnario simul
V.3 Rsultat de la simulation

La figure 4-14 illustre le taux de rejet des paquets lentre du LER n18 en fonction du temps. Si la capacit des liens entre les nuds 18 et 25 dune part et 18 et 26 dautre part est suffisante pour supporter la totalit du trafic provenant des cinq sources lies au LER 18, alors, dans ce cas, la perte de paquets est nulle. Mais, si la capacit de lune des liaisons en terme de bande passante est infrieure la demande de transmission dune certaine valeur V, le taux de perte augmente rapidement dans le rseau en fonction du temps. Puis, il se stabilise un certain moment cette valeur V.
55
Figure 4-14: le taux de perte de paquets en fonction du temps
Conclusion
Dans ce chapitre, on a prsent les fonctionnalits de base de loutil dvelopp. Ce quon peut remarquer cest que la procdure de dimensionnement des capacits dans un rseau MPLS nest pas une tche assez simple. En effet, dans des rseaux IP multiservices le comportement des utilisateurs est alatoire essentiellement pour le trafic data. Le manque de donnes fournies par un oprateur rend la procdure encore plus complexe. On a essay de simplifier quelques dtails pour rendre lopration de dimensionnement faisable sans oublier que peu de recherches ont t faites sur le service VoIP. La simulation tait un moyen pour tester certains paramtres de la qualit de service essentiellement le taux de rejet des paquets au niveau du nud daccs au backbone MPLS.
56
Conclusion gnrale
Conclusion gnrale
Lvolution progressive du monde des tlcommunications vers des rseaux et des services de nouvelle gnration est aujourdhui une tendance forte qui suscite lintrt dune majorit dacteurs. Les rseaux de nouvelle gnration ou NGN prsentent un support dapplications multiples telles que les applications audio, vido et donnes. Les rseaux NGN sont caractriss par une volution du transport en mode paquet avec une convergence totale vers lIP. Ce projet sinscrit dans le cadre des rseaux de nouvelle gnration. Il a pour objectif de mettre en place un outil logiciel pour aider au dimensionnement du backbone NGN. Dans une premire phase, loutil permet le dimensionnement pour offrir le service de la voix sur IP. Par la suite, loutil ncessite dvoluer et permettre lintgration dautres types de trafic tels que le trafic data. Lobjectif principal de cet outil est de dimensionner les artres et de choisir une topologie adquate. A la fin, les rsultats obtenus ncessitent dtre valus par des simulations. Dans ce contexte, et vue limportance de la tche de dimensionnement dans les rseaux de nouvelle gnration, ce rapport prsente le fruit de notre travail effectu dans le but de dimensionner les capacits des liens au niveau dun backbone IP/MPLS. La dmarche suivie consiste alors faire le dimensionnement au dpart pour le trafic voix et intgrer par la suite le trafic data. On a termin notre travail par des simulations par le simulateur rseau NS-2. On a concentr notre intrt sur la mesure du taux de rejet au niveau dun des routeurs daccs prsent dans la topologie choisie du backbone MPLS. Lapplication de quelques rgles dingnierie est un lment essentiel dans le processus de dimensionnement. Mais, faute de donnes et de statistiques fournies par un oprateur, la tche de dimensionnement se trouve face quelques obstacles. Ces statistiques contribuent avec des modles mathmatiques donner un aspect plus raliste au processus de dimensionnement. On
57
Conclusion gnrale
peut penser intgrer des modles de trafic tels que le modle BMAP (Batch Markovian Arrival Process) dans notre processus de dimensionnement pour le trafic data et avoir une ide sur les performances du rseau. On peut galement chercher optimiser la bande passante en prenant la topologie choisie du backbone MPLS comme une topologie de rfrence. Le chantier reste encore ouvert dautres amliorations au niveau du travail effectu.
58
Bibliographie
Bibliographie
[1] [2] [3] walter J.Goralski, Matthew C.Kolon, IP Telephony , McGraw-Hill 1999 J.Rosenberg, H.Schulzrinne, SIP: Session Initiation Protocol , Request for Comments: 3261 June 2002 A. Vemuri Request, J. Peterson, G. Camarillo, A. Johnston, J. Peterson, R. SparksM. Handley, E. Schooler, Session Initiation Protocol for Telephones (SIP-T): Context and Architectures Request for Comments: RFC 3372, September 2002 [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] Lars Rasmusson, Network capacity sharing with QoS as a financial derivative pricing problem: algorithms and network design, Stockholm 2002 Vilho Rasanen, Implementing Service Quality in IP Networks, Edition 2003 Jean Franois Susbielle, Internet multimedia et temps rel, Eyrolles, Fvrier 2000 Nicolas Chambon, Rabii Kenny, Nicolas Morin, Les rseaux orients politiques PBN et le protocole COPS , 2004-2005 Ibrahima Niang, Dominique Seret, Dimensionnement de DiffServ bas sur des mtriques de performance Edward Bjarte Fjellskal & Stig Solberg, Evaluation of Voice over MPLS (VoMPLS) compared to Voice over IP (VoIP) , Grimstad, May 2002 Sylvain Francois, Anne-Lise Renard, Jrmy Rovaris, Etude du service DiffServ Mounir Frikha, Dimensionnement et planification de rseaux , SupCom, 2004/2005 B.Baynat Thorie des files dattente , HERMES Sciences, 2000 Benoit Regrain, Programmation C/C++ , 8 dcembre 2004 Ivor Horton, Visual C++ 6, Eyrolles, troisime Edition, tirage 2000
59

Dimensionnement D Un Backbone IP-MPLS - WALHA - Nada 2005

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dimensionnement D Un Backbone IP-MPLS - WALHA - Nada 2005

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN DETUDES

M. Mounir Frikha M. Fakhreddine Khelifa

Anne universitaire : 2004/2005

A toute la famille de mon oncle

A mes frres et ma sur

remercie chaleureusement M.Fakhreddine Khelifa, ingnieur principal au

Je tiens exprimer mes respects tout le personnel du CERT pour my avoir

Merci galement au corps administratif et tout le cadre enseignant de lcole

Notre vie vaut ce quelle nous a cot defforts

Projet fin dtudes 2004/2005

Table des matires

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

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

Projet fin dtudes 2004/2005

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

Conclusion gnrale ............................................................................................ 57 Bibliographie........................................................................................................ 59

Projet fin dtudes 2004/2005

Liste des figures

Projet fin dtudes 2004/2005

Projet fin dtudes 2004/2005

Liste des tableaux

Projet fin dtudes 2004/2005

Projet fin dtudes 2004/2005

Projet fin dtudes 2004/2005

Projet fin dtudes 2004/2005

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Chapitre 1: La voix sur IP

I. Les apports de la voix sur IP

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

II. Les architectures VoIP

Figure 1-2 : la configuration PC- phone

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Figure 1-3 : la configuration Phone to Phone

III. La voix et la qualit de service

(1.2) (1.3) (1.4)

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Dcomm : le temps de commutation

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

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Figure 1-4 : principe du buffer de gigue

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

IV. Les standards de la VoIP

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Figure 1-5 : architecture dune zone H.323

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Figure 1-6 : architecture protocolaire de H.323

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Projet fin dtudes 2004/2005

Chapitre1 : La voix sur IP

Figure 1-7 : architecture protocolaire de la norme SIP