Documente Academic
Documente Profesional
Documente Cultură
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 :
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.
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
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.
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
iii
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
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
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.
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 #
1 4 7 *
2 5 8 8
3 6 9 # 1 2 4 5 7 8 * 8 3 6 9 #
(1.1)
D N : le dlai du rseau
D prop : le temps de propagation
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%
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)
transmission sur le rseau. Drel : dlai rel pass par le paquet pour arriver sa destination.
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.
10
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
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
13
14
15
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
18
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
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
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
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).
22
Class 2
Video
Rseau IP
Edge WAN
Flots lastiques
1 4 7 *
2 3 5 6 8 9 8 #
Voix
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
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.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
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 :
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
Catgorie
Gestion dtat Mes messages dtablissement et de libration de LSP Architecture de base
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
28
( 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
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 diffrents champs de chaque protocole sont prsents comme le montre les figures 3-3, 3-4 et 3-5.
31
Les 20 octets du protocole IP quon a considr ne tiennent pas compte des champs Options et Padding.
32
Frame Relay (FR): ce protocole est utilis dans les rseaux maills. Il assure ltablissement de circuit virtuel entre deux usagers.
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.
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.
33
o o o o o
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
n++
34
nb circuit
(3.4)
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
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.
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
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)
+ 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
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
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.
40
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)
Si
= N apl i
D sig i
(3.8)
41
N apl i
(3.9)
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.
42
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)
43
C kd =
T ijd
(3.12)
Tijd = Ti
+ Tj
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
45
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].
46
Trafic Data Dbit dans le rseau daccs Trafic dans le backbone MPLS
Capacit de lartre
47
-Probabilit de blocage -taux darrive -temps de service -codec -cycle de transmission -protocole de couche liaison
nombre de circuits
Bande passante
48
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
49
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.
50
Capacit totale
51
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
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.
53
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.
54
55
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