UNIVERSITATEA POLITEHNICA BUCURETI

FACULTATEA DE ELECTRONIC, TELECOMUNICAII I TEHNOLOGIA INFORMAIEI CATEDRA DE TELECOMUNICAII APROBAT Responsabil Program RITc: Prof. dr. ing. VICTOR CROITORU

TEMA LUCRRII DE DIZERTAIE A MASTERANDULUI Titlul temei: Managementul resurselor in reele MPLS 1. Date iniiale pentru proiectare: Sinteza tehnologiilor IP si MPLS Ingineria traficului n reele MPLS Soluii pentru optimizarea alocrii resurselor n reele MPLS 2. Coninutul memoriului:

Evolutia retelelor de mare capacitate Tehnologia IP Tehnologia MPLS Protocoale de distribuie a etichetelor Ingineria traficului n reele MPLS Soluii pentru gestionarea resurselor n reele MPLS Simulare folosind un simulator de reea(OPNET, OMNET)

3. Material grafic obligatoriu:

Scheme bloc Diagrame logice Grafice rezultate n urma simulrii 4. Realizare practic: Implementarea unei soluii de administrare a resurselor folosind un program de tip simulator de reea. 5. Locul de desfurare al activitii de proiectare i execuie; UPB, Facultatea de Electronic, Telecomunicaii i Tehnologia Informaiei, Catedra de Telecomunicaii, Laborator A326, Complex Leu. 6. Lucrarea servete pentru: Scop didactic 7. Mijloacele materiale sunt puse la dispoziie de: Facultatea de Electronic, Telecomunicaii i Tehnologia Informaiei, UPB. 8. Realizarea practic rmne n proprietatea: UPB 9. Data elaborrii temei: 12.02.2010

Conductorul lucrrii de dizertaie,

Am primit tema

Cuprins Lista de acronime ..........................................................................................................................5 Cap.1. Tehnologii folosite n reelele de mare capacitate actuale....................................................6 1.1. Evolutia acestor retele de mare capacitate.............................................................................6 1.2. Tehnologiile folosite n reelele actuale.................................................................................7 1.2.1 Tehnologia IP...................................................................................................................7
1.2.1.1. Rutarea n reelele IP...........................................................................8 1.2.1.2 Protocoale de rutare IP.........................................................................9 1.2.1.2.a.Protocolul RIP (Routing Information Protocol)...............................10 1.2.1.2.b. OSPF (Open Shortest Path First)..................................................10 1.2.1.2.c. EIGRP(Enhanced Interior Gateway Routing Protocol)..................12 1.2.1.2.d.Protocolul BGP (Border Gateway Protocol)....................................12 1.2.1.3. Limitrile tehnologiei IP......................................................................12

Cap.2. Tehnologia MPLS..............................................................................................................14 2.1 Ce este MPLS ?....................................................................................................................14 2.2. Cum funcioneaz MPLS....................................................................................................18 2.2.1 Etichetele MPLS............................................................................................................21
2.2.1.1 Frame mode........................................................................................21 2.2.1.2 Cell mode(modul celula).....................................................................24

2.3 Arhitectura MPLS................................................................................................................25 2.3.1 Planul de control............................................................................................................25 2.3.2 Planul de date.................................................................................................................26 2.4 Elementele MPLS.................................................................................................................27 2.4.1 Comutator de Etichete (Label Switch Router) - LSR ...................................................28 2.4.2 Cale cu comutaie de etichete (Label Switched Path)- LSP...........................................29 2.4.3 Protocoale de distributie a etichetelor............................................................................30
2.4.3.1 2.4.3.2 2.4.3.3 2.4.3.4 LDP(Label Distribution Protocol).........................................................30 CR-LDP(Constraint Route Label Distribution Protocol)........................33 RSVP-TE(Resource Reservation Protocol)............................................33 BGP( Border Gateway Protocol ).........................................................33

2.5 Avantaje si dezavantaje ale tehnologiei MPLS....................................................................33 Cap.3. Ingineria Traficului n reele MPLS...................................................................................36 3.1 Necesitatea Ingineriei de Trafic n MPLS...........................................................................36 3.2 Modul de lucru al ingineriei traficului n MPLS..................................................................38 3.3 Extensii OSPF pentru Ingineria Traficului .........................................................................................................................................40 3.3.1 Operarea i Dirijarea pe Baz de Constrangeri n MPLS TE (Constraint-Based Routing CBR) .................................................................................................................................................41 3.4 Calcularea si stabilirea caii...................................................................................................42 3.4.1 Cum functioneaza SPF...................................................................................................42 3.4.2 Cum functioneaza CSPF................................................................................................45 3.5 Protocolul de rezervare a resurselor -Resource Reservation Protocol (RSVP)....................50 3.5.1 Bazele RSVP(RSVP Basics)..........................................................................................50 3.5.2 Semnalizarea RSVP-TE.................................................................................................51 3.5.3 Operaiunile RSVP n MPLS TE ..................................................................................52 3.5.4 Setarea caii si mentinerea ei...........................................................................................54
3.5.4.1 Setarea caii.........................................................................................54 3.5.4.2 Mentinerea caii...................................................................................55

3.5.5 Pachetele RSVP.............................................................................................................56 3.5.6 Operatiile RSVP.............................................................................................................58

3.5.6.1 Ce este Make-Before-Break?...............................................................58 3.5.6.2 Cum lucreaza mecanismul de actualizare(refresh)?...........................59

3.6 Administrarea TE in MPLS..................................................................................................62 3.6.1 Protectie si restaurare.....................................................................................................62 Cap.4. Calitatea serviciilor in retele MPLS...................................................................................70 4.1 Introducere............................................................................................................................70 4.2 Modelele utilizate pentru implementarea QoS.....................................................................71 4.2.1 Modelul Serviciilor Integrate.........................................................................................71 4.2.2 Modelul Serviciilor Diferentiate....................................................................................72 4.3 Implementarea QoS prin MPLS...........................................................................................76 5. Modelarea unei retele MPLS-DIFFSERV.................................................................................78 5.1 Obiective..............................................................................................................................78 5.2 OPNET.................................................................................................................................78 5.3 Construirea reelei.................................................................................................................79 5.4 Configurarea reelei..............................................................................................................81 5.4.1 Application Configuration.............................................................................................81 5.4.2 Profile configuration......................................................................................................81 5.4.3 MPLS Configuration.....................................................................................................82 5.4.4 Configurarea clienilor..................................................................................................83 5.4.5 Configurarea nodurilor de grani i intermediare........................................................84 5.5 Statistici i rezultate..............................................................................................................86 5.5.1 Cantitatea de trafic transmis.........................................................................................86 5.5.2 Timpul de upload...........................................................................................................86 5.5.3 ntrzierea produs de cozi.............................................................................................87 .................................................................................................................................................88 5.5.4 Utilizarea bufferelor cozilor...........................................................................................88 ....................................................................................................................................................89 5.6 Concluzii ..............................................................................................................................89 Bibliografie....................................................................................................................................90

Lista de acronime AF - Assured Forwarding AS - Autonomous System ATM - Asyncronous Transfer Mode BA -Behavior Aggregate BGP - Border Gateway Protocol CR-LDP -Constraint-based Routing Label Distribution Protocol DSCP -Differentiated Services Code Point EF - Expedited Forwarding E-LSP EXP -inferred-PSC LSP EXP -Experimental bits EIGRP - Enhanced Interior Gateway Routing Protocol IETF -Internet Engineering Task Force ILM -Incoming Label Map FEC - Forwarding Equivalence Class FR - Frame Relay IP - Internet Protocol IS-IS - Intermediate System -to-Intermediate System IGRP - Interior Gateway Routing Protocol LAN - Local Area Network LSR - Label Sitched Router L-LSP Label-only-inferred-PSC LSP LDP - Label Distribution Protocol LSP - Label Switched Path MAC - Media Access Control MPLS - Multi-Protocol Label Switching NHLFE -Next Hop Label Forwarding Entry OSPF - Open Shortest Path First OSI - Open System Interconection QoS - Quality of Service RFC - Request for comments PPP - Point to Point Protocol PE - Provider Edge PHB -Per-Hop Behavior PHP -Penultimate Hop Popping RIP - Routing Information Protocol QoS -Quality of Service RSVP -Reservation Protocol SDH - Synchronous Digital Hierarchy TE -Traffic Engineering TLV -Type-Length-Value TTL - Time to Live VCI - Virtual Channel Identifier VPI - Virtual Path Identifier VPN - Virtual Private Network WFQ - Weighted fair queuing

Cap.1. Tehnologii folosite n reelele de mare capacitate actuale

1.1. Evolutia acestor retele de mare capacitate Noile reele de date trebuie s asigure, pe lng viteza de transmisie ridicat, banda larg, managementul resurselor, scalabilitate i integrarea diverselor tehnologii de access (LAN, HDSL, ADSL, TDM etc.). De aceea au aprut noi cerine de performan i de funcionalitate pentru reelele de date actuale. Datorit faptului c resursele reelelor de date sunt limitate, acestea trebuie gestionate cu grij pentru a obine performane i randamente ridicate. Arhitecturile actuale in seama de necesitile de integrare a diferitelor tehnologii de access i de interoperabilitatea cu alte reele de date. Arhitectura unei reea de date de mare vitez este structurat pe mai multe niveluri.Modelul actual al reelelor este reprezentat n figura de mai jos :
N e lOt iv lu pic

C R -u OE l Rt le ee i

IN E N T TRE

N e lCr iv lu oe

N e l d D t ib t iv lu e isr uie

N e l d Ac s iv lu e c e
` `

Figura 1.1. Arhitectura unei reele complexe de comunicaii actuale. Dup cum se observ, arhitectura reelei este mprit pe patru nivele: Optic - este partea de reea ce se situeaz la nivelul fizic al nivelului OSI. Acest nivel este implementat prin diferite tehnologii de transmisie pe fibra optic, cum ar fi: SONET, SDH, WDM, DWDM etc. Core (Nucleu) - se mai numete i backbone i este partea de reea care se ocup n principal cu transmisia de date de mare vitez, fr a ndeplini alte funcii de reea (access, agregare etc.). Distribuie - este partea de reea n care se face agregarea (concentrarea) de trafic. Acces - acest nivel cuprinde echipamentele de reea care se ocup cu partea de acces a diferitelor tehnologii de access (HDSL, ADSL, TDM, ATM, IP, etc.). Aceast mprire pe nivele face mai uoar gestionarea i proiectarea arhitecturilor reelelor de date, precum i migrarea ctre noi tehnologii prin etape de integrare pe nivele funcionale. Principalele caracteristici arhitecturale i de funcionalitate ale unei reele moderne sunt: 6

Structurare pe nivele arhitecturale. Funcionaliti mprite pe nivele structurale ( ex. n punctul de access se face autorizarea, stabilire QoS, n distribution se face agregare, n core se face transport etc.). Management centralizat. Ingineria traficului (stabilirea cilor de rutare) care se face prin managementul centralizat. Integrarea a ct mai multe tehnologii de access. Conexiune cu reeaua PSTN (Public Switched Telephone Network). Migrarea ctre o reea de date universale (Date, voce, video, video-on-demand etc.). Migrarea traficului de voce ctre reelele NGN (Next Generation Networks) , centralele digitale actuale sunt nlocuite cu echipamente de date hardware i software perfect integrate n reea. Scalabilitate, performan, disponibilitate total (99%).

1.2. Tehnologiile folosite n reelele actuale n reelele de date actuale sunt folosite ca principale tehnologia IP, tehnologia ATM i, mai nou, tehnologia MPLS: 1.2.1 Tehnologia IP Tehnologia IP este tehnologia cea mai rspndit la ora actual n reelele LAN. Ea este o tehnologie de Layer 3 bazat pe protocolul IP (Internet Protocol) care face adresare i controlul informaiei ce permite pachetelor de date s fie rutate. Protocolul IP este un protocol bazat pe transmisia de pachete ntre diferite calculatoare din reea. Protocolul suport adresare, fragmentarea, reasamblarea i multiplexarea de protocol. Este protocolul pe baza cruia s-au construit celelalte protocoale IP, aa- numita suit de protocoale TCP/IP. (TCP, UDP, ICMP, ARP, RARP, etc.). n desenul urmtor este reprezentat corespondena diferitelor protocoale i nivelul OSI: tehnologii de transport:

Figura 1.2.1. Corespondena nivel OSI protocoale de reea 7

1.2.1.1. Rutarea n reelele IP . Rutarea poate fi static sau dinamic. Ea implic determinarea cii de rutare, care se poate face dup anumite valori metrice (ntrzieri, costuri, utilizarea cii, etc.).Rutarea se face dup o tabel de rutare care specific interfeele i adresele ctre care trebuie trimise pachetele. Router-ele sunt echipamente ce lucreaz la nivelul 3 OSI. Ele sunt folosite pentru schimbul de informaie dintr-ul grup de reele ce aparin aceleiai autoriti de control i administrative. (AS - Autonomous Systems), ct i pentru schimbul de informaie ntre AS-uri Regula general de trimitere a pachetelor este alegerea rutei care se potrivete ct mai exact. De exemplu: Destinaie 10. 1. 4. 0 10. 1. 0. 0 Masca 255.255.255. 0 255.255. 0. 0 Ruter de ieire R2 R3

Destinaia 10.1.4.30 se potrivete n ambele cazuri, dar gateway-ul R2 are masc de reea mai restrictiv, deci va fi aleas aceast cale. Rutarea cu vectori-distan Rutarea se poate baza pe algoritmi cu vectori-distan (numii i algoritmi Bellman-Ford), care fac ca ruterele s paseze periodic copii ale tabelelor de rutare vecinilor cei mai apropiai din reea. Fiecare destinatar adaug la tabel un vector-distan (propria "valoare" distan) i o expediaz vecinilor si cei mai apropiai. Acest proces se desfoar n toate direciile ntre routerele aflate n imediat vecintate. Acest proces pas-cu-pas face ca fiecare router sa afle informaii despre celelalte routere i si dezvolte o perspectiv cumulativ asupra "distanelor" reelei. De exemplu, un protocol timpuriu de rutare este Routing Information Protocol (protocol de rutare a informaiilor), sau RIP . Acesta utilizeaz dou uniti de msur pentru distane ca s determine cea mai bun cale urmtoare pentru orice pachet. Aceste uniti de msur pentru distan, tacturile i hopurile, sunt dependente de timp. Tabela cumulativ este apoi utilizat pentru actualizarea tabelelor de rutare ale fiecrui router. La finalul procesului, fiecare router a aflat niste informaii vagi despre distanele pn la resursele din reea. El nu a aflat nimic specific despre alte routere sau despre topologia real a reelei. Aceast abordare poate, n anumite circumstane, s creeze probleme de rutare pentru protocoalele bazate pe vectori-distan. De exemplu, n urma unei cderi n reea este necesar ceva timp pentru ca routerele s convearg spre o nou nelegere a topologiei reelei. n timpul acestui proces, reeaua ar putea fi vulnerabil la rutri contradictorii i chiar la bucle infinite. Anumite msuri de siguran ar putea s micoreze aceste riscuri, dar rmne faptul c performana reelei este expus riscurilor n timpul procesului de convergen. Prin urmare, este posibil ca protocoalele mai vechi care converg lent s nu fie potrivite pentru WAN-urile extinse, complexe. Rutarea cu starea legturilor Algoritmii de rutare folosind starea legturilor (link-state routing algorithm), cunoscui colectiv ca protocoale cu preferarea drumului minim (SPF), menin o baz de date complex a topologiei reelei. Spre deosebire de protocoalele cu vectori-distan, cele folosind starea legturilor dezvolt i ntrein o cunoatere complet a routerelor de reea, ca i a felului cum sunt interconectate acestea. 8

Aceast cunoatere este realizat prin schimbarea de pachete cu starea legturilor (LSP) cu alte routere conectate direct. Fiecare router care a schimbat LSP-uri construiete apoi o baz de date logica utilizand toate LSP-urile primite. Este utilizat apoi un algoritm "cu preferarea drumului liber", pentru a calcula ct de accesibile sunt destinaiile legate de reea. Aceast informaie este utilizat pentru a actualiza tabela de rutare. Acest proces este capabil s descopere modificrile topologiei reelei, care ar putea fi cauzate de cderea unei componente sau de mrirea reelei. De fapt, schimbul de LSP-uri este declanat de un eveniment din reea, nu este realizat periodic. Rutarea cu starea legturilor are dou zone pariale de risc. Mai nti, n timpul procesului iniial de descoperire, rutarea cu starea legturilor poate acapara mediile de transmisie ale reelei, reducnd astfel n mod semnificativ capacitatea reelei de a transporta date. Aceast degradare a performanei este temporar, dar foarte evident. A doua problem potenial este c rutarea cu starea legturilor solicit intens memoria i procesorul. Din aceast cauz, routerele configurate pentru rutare cu starea legtulilor sunt n general mai scumpe. Rutarea hibrid Ultima form de rutare dinamic este hibridizarea. Dei exist protocoale hibride deschise, echilibrate, aceast form este asociat aproape exclusiv creaiei brevetate a unei singure companii, Cisco Systems Inc. Acest protocol, EIGRP, a fost proiectat combinnd cele mai bune aspecte ale protocoalelor cu vectori-distan i cu starea legturilor, fr limitrile de performan sau dezavantajele lor. Protocoalele de rutare hibride echilibrate, utilizeaz uniti de msur vectori-ditan, dar realizeaz msurtori mult mai precise dect protocoalele cu vectori-distan convenionale. De asemenea, ele converg mult mai rapid dect acestea din urm, dar evit suprasarcinile i actualizrile cu starea legturilor. Hibrizii echilibrai nu sunt periodici, ci condui de evenimente, conservnd astfel lrgimea de band pentru aplicaii reale. 1.2.1.2 Protocoale de rutare IP Algoritmii de rutare pot fi mprii n dou grupe: Interior Gateway Protocol (IGP) - folosit la rutarea n interiorul unei organizaii. Din aceast categorie fac parte urmtoarele protocoale de rutare: RIP (Routing Information Protocol) - folosit n special n reelele mici, OSPF (Open Shortest Path First) cel mai des folosit protocol n reelele mari, EIGRP (Enhanced Interior Gateway Routing Protocol), IGRP (Interior Gateway Routing Protocol) protocoale proprietare CISCO, folosite numai pentru echipamente CISCO. Border Gateway Protocols (BGP) - este folosit la rutarea ntre diferite organizaii sau Sisteme Autonome (AS). n figura urmtoare este reprezentat situarea celor dou tipuri de protocoale de rutare ntr-o reea larg:

AS 3
IGP BGP

AS 1
BGP IGP IGP

AS 2

Figura 1.2.1.2. Protocoalele de rutare IGP i BGP ntr-o reea larg

1.2.1.2.a.Protocolul RIP (Routing Information Protocol) RIP este un protocol de rutare intra-domeniu bazat pe distana vectorial dintre hopuri. Este folosit n toate router-ele actuale. Folosete trei tipuri de temporizri n alctuirea tabelei de rutare: Actualizarea rutelor (se face automat la un interval de 30 de secunde ) Expirarea validitii rutei Curirea tabelei de rutare Exist doua versiuni ale protocolului RIP: RIPvl si RIPv2. Principalele probleme ale protocolului RIP sunt: limitarea numrului maxim de hopuri la 15 propagarea informaiei n reelele mari este lenta traficul RIP crete rapid odat cu mrirea reelei Protocolul RIP poate opera n 3 moduri: Activ - trimite i recepioneaz informaii de rutare Silent - doar ascult i primete informaii de rutare (nu trimite nimic) Deaf - doar trimite informaii de rutare (nu primete).

1.2.1.2.b. OSPF (Open Shortest Path First) OSPF este un protocol bazat pe verificarea strii link-urilor, ruterele trimit informaii despre starea link-ului n locul informaiilor despre propriile tabele de rutare. Acest protocol mparte reeaua n zone pentru a putea lucra n reele mari. 10

Aria 0 (backbone area)

BGP

Aria 0 (backbone area)

AS 1

OSPF OSPF IGP

Routere de backbone Router border (de arie)

AS 2

Aria 1

Aria 1

Aria 2

Routere interioare

OSPF este folosit in interiorul sistemelor autonome

Figura 1.2.1.2.b. Topologia OSPF Router-ele interne trebuie s tie doar rutele ctre reelele din aria lor i ctre aria de backbone. Ele schimb ntre ele informaii despre starea link-urilor. Fiecare router cunoate topologia i costul pentru comunicaia cu reelele din aria lui.[18] Border Router-ele de arie schimb informaii despre starea link-urilor cu toate routerele din aria cu care sunt conectate. Routerele de backbone se afl n aria 0" i pot fi routere interioare, border routere sau routere de grani pentru sisteme autonome. Routerele de backbone schimb informaii cu alte routere de backbone din aria 0" i calculeaz ultimul cost al rutei dintre arii sau alt sistem autonom. Protocolul OSPF folosete cinci tipuri de mesaje: Hello - folosit pentru a descoperi vecinii i pentru a delega un router dedicat precum i pentru a verifica starea link-ului Database Description - descrie baza de date a topologiei link-ului Link State Request - cerere de pri din topologia routerelor adiacente Link State Update - trimite date despre starea link-urilor ctre routerele vecine Link State ACK - confirmarea recepionrii update-ului Folosind mesajele Hello" un router principal i un router de backup principal sunt alese pentru fiecare arie. Routerele principale de arie calculeaz o matrice a routerelor din ntreaga arie (care nu este aceeai cu matricea de routere vecine). Fiecare router schimb date despre starea link-urilor doar cu router-ele adiacente, ceea ce limiteaz traficul generat de OSPF. n cele din urm toate router-ele vor obine informaii identice despre topologie. Fiecare revizuire de informaie n legtur cu starea link-urilor are un numr de ordine pentru a se putea determina dac revizuirea este nou. n OSPF routerele pot schimba ntre ele pe lng informaia despre starea linkurilor i informaii despre: ntrziere 11

 banda disponibil sigurana link-ului Aceste informaii sunt folosite de routere n momentul n care trimit pachete cu cmpul ToS setat la o anumit valoare.[18] 1.2.1.2.c. EIGRP(Enhanced Interior Gateway Routing Protocol) EIGRP a fost dezvoltat de ctre Cisco (eliberat n 1988) cu scopul de a mbunti protocolul RIP pe vremea cnd IETF nc lucra la dezvoltarea OSPF -ului. EIGRP este un protocol brevetat. Acest protocol elimin unele dintre defectele protocolului RIP i are mbuntiri ca folosirea de metrici compuse, rutarea pe ci multiple i mnuirea rutelor implicite. Evoluia protocolului EIGRP furnizeaz compatibilitate i operaii precise cu rutere EIGRP . Capaciti cheie care disting EIGRP de alte protocoale de rutare includ convergena rapid, suport pentru masc de subreea variable-length , suport pentru update, i suport pentru multiple network layer protocols. EIGRP are toate avantajele flexibilitii i ale configurrii simple n timp ce mbuntete viteza i consumarea resurselor. De altfel, este capabil a fi un protocol unic att pentru IP ct i pentru protocoale non-IP , eliminnd nevoia de a folosi multiple protocoale de rutare ntr-o reea multi-protocol. Acest protocol de rutare este unul dintre cele mai diversificate i robuste protocoale de rutare. Combinaia sa unica de caracteristici mbin cele mai bune atribute ale protocoalelor de vectordistan cu cele mai bune atribute ale protocoalelor cu starea legturilor. Rezulatul este un protocol de rutare hibrid care sfideaz mprirea pe categorii a protocoalelor convenionale. Poate fi folosit mpreunp cu IPv4, AppleTalk, i IPX. Mai important, arhitectura sa modulara va permite ca Cisco s adauge suport pentru alte protocoale de rutare importante care vor aprea n viitor. Spre deosebire de alte protocoale de rutare bazate pe vectori-distanta, EIGRP nu mandateaz o revizuire periodic al tabelelor de rutare ntre rutere vecine. n schimb, folosete un mecanism de descoperire/recuperare pentru a se asigura c vecinii sunt contieni de accesibilatea fiecaruia in parte. 1.2.1.2.d.Protocolul BGP (Border Gateway Protocol) BGP ul este singurul protocol de rutare ntre Sisteme Autonome, n principal este folosit n ruterele de backbone pentru a schimba informaia ntre AS-uri, dar poate fi folosit i n interiorul AS-ului pentru a schimba informaie de rutare ( IBGP). A fost proiectat s detecteze buclele i s foloseasc informaia metric pentru a lua decizii de rutare inteligente. Traficul dintr-un AS trebuie s treac printr-un gateway router, AS selecteaz care router va ndeplini aceast funcie.[18] 1.2.1.3. Limitrile tehnologiei IP Principalele limitri ale tehnologiei IP sunt: Nu asigur un QoS pur deoarece este o tehnologie bazat pe principiul de mprire a mediului fizic media sharing", aplicndu-se conceptul Best Effort" n politica de trafic. 12

 Mecanismul de rutare este un mecanism care se bazeaz pe conceptul cea mai mare potrivire" i acest lucru duce la ntrzieri n mecanismul de rutare i trimitere de pachete. Lungimea pachetelor este variabil ceea ce duce la echipament hardware complex cu mare putere de calcul. Acest lucru duce la limitri n puterea de procesare a backbone-urilor Header-ul pachetului IP este mare i complex, ceea ce duce la o proast utilizare a benzii de date disponibile Datorit mecanismului de adresare apar foarte multe adrese care sunt greu de gestionat de rutere care posed tabele de rutare mari implicit hardware complex.

13

Cap.2. Tehnologia MPLS 2.1 Ce este MPLS ? Multiprotocol Label Switching (MPLS) este o tehnologie bazata pe comutatia de etichete ce si propune sa simplifice rutarea IP n retelele core . Arhitectura MPLS a fost gndita sa poata oferi un serviciu de transport de date unificat pentru multe tipuri de trafic, cum ar fi pachete IP, celule ATM, cadre SDH sau Ethernet. Din punct de vedere arhitectural MPLS se afla ntre nivelul 2 OSI (Legatura de Date) si nivelul 3 (Retea), fiind considerata de multi o tehnologie de nivel 2,5. Ideea de baza a acestei tehnologii este sa clasifice fluxurile de intrare ntr-o retea MPLS n clase de echivalenta care sa fie tratate la fel de catre nodurile retelei. O clasa de echivalenta intra n corespondenta cu un set de etichete de lungime fixa ce vor fi comutate n nodurile retelei, pna la destinatie. Nodurile de intrare vor face clasificarea fluxurilor, iar nodurile intermediare au de facut mai putine prelucrari, deoarece este suficient sa comute etichete.[Wiki-MPLS] Multi-Protocol Label Switching (MPLS) definete un mecanism pentru ndrumarea pachetelor n ruterele (nodurile) reelei. Iniial a fost dezvoltat pentru a realiza o ndrumare mai rapid a pachetelor dect n rutarea IP tradiional, dei imbuntirile ce in de partea hardware a ruterelor au rezolvat problema vitezei n cadrul rutrii. Comutarea etichetei este realizata indiferent de protocolul de rutare Layer 3. - MPLS scade dirijarea incarcata in routerele core. - MPLS suport multiple aplicaii utile, cum ar fi cele enumerate mai jos: -Unicast si Multicast in rutarea IP; -VPN(Retea Privata Virtuala); -TE(Ingineria Traficului); -QoS(Calitatea Serviciului); -ATM(Orice transport peste MPLS). - MPLS suporta dirijarea protocoalelor non-IP, deoarece tehnologiile MPLS sunt aplicabile in orice protocol al nivelului retea. MultiProtocol Label Switching (MPLS) d posibilitatea firmelor i furnizorilor de servicii Internet (ISP =Internet Service Provider) s construiasc reele inteligente de ultim generaie care s ofere o gam larg de servicii avansate, cu valoare adugat, peste o infrastuctur unic. Abonaii cu linii de acces diferite pot fi grupai MPLS far a li se schimba mediul curent, deoarece MPLS este independent de tehnologiile de acces. Reelele IP tradiionale sunt fr conexiune: atunci cnd este primit un pachet, ruterul determin urmtorul nod de parcurs, folosind adresa IP destinaie mpreun cu informaia din propriul su tabel de rutare. Tabelul de rutare din ruter conine informaie despre topologia reelei. Se folosesc protocoale IP de rutare, ca OSPF, IS-IS, BGP, RIP sau configurare static, pentru a menine sincronizat informaia din aceste tabele cu schimbrile ce au loc n reea. Integrarea componentelor aplicaiei MPLS, incluznd VPN de nivel 2, VPN de nivel 3, Traffic Engineering, QoS, GMPLS sau IPv6, dau posibilitatea dezvoltrii unor reele sigure i foarte eficiente, ce garanteaz SLA (Service Level Agreements). MPLS ofer servicii IP cap-la-cap, cu un nalt grad de scalabilitate i de difereniere, cu configurare i management foarte simple, att pentru furnizori ct i pentru abonai. Aceast soluie este suportat de o gam foarte larg de platforme, lucru esenial nu numai pentru furnizorii de servicii, dar i pentru reelele private. MPLS folosete de asemenea adrese IP, versiunea 4 sau versiunea 6, pentru a identifica punctele terminale ale reelei sau switch-urile ori ruterele intermediare. Aceasta face ca reelele MPLS s fie compatibile IP i uor integrabile cu reele IP tradiionale. n orice caz, spre deosebire de IP14

ul tradiional, fluxurile MPLS sunt orientate spre conexiune (connection-oriented = CO) i pachetele sunt rutate pe ci preconfigurate, numite LSP (Label Switched Paths). 2 .1 Terminologie MPLS: MPLS (Multiprotocol Label Switching) reprezinta o noua tehnologie de comutatie, numita comutatia de etichete multiprotocol. Planul de control(Control plane) acolo unde controlul informatiei ,cum ar fi rutarea si etichetarea informatiei, este schimbata. Planul de date/planul de dirijare acolo unde dirijarea este efectuata.Aceasta se poate realiza numai dupa ce planul de control este stabilit. CEF (Cisco Express Forwarding) o tehnologie foarte avansata de comutatie de nivel 3 dezvoltata de Cisco pentru a optimiza performantele retelelor cu parametri de trafic foarte dinamici. Eticheta(label) o eticheta de lungime fixa pe care dirijarea MPLS se bazeaza.Termenul eticheta(label) poate fi folosit in doua contexte.Un termen se refera la eticheta de 20-biti.Celalalt termen se refera la eticheta antet, care are o lungime de 32 biti. Asocierea etichetei(label binding) asocierea unui FEC(prefix) la o eticheta.O eticheta distribuita de la sine nu are nici un context, prin urmare nu este foarte folositoare. Destinatarul stie sa aplice o eticheta specifica la un pachet de date care intra datorita asocierii la un FEC. Adaugarea etichetei(label imposition) procesul de adaugare a etichetei la un pachet de date intr-o retea MPLS. Inlaturarea etichetei(label disposition) procesul de inlaturare a etichetei de la un pachet de date. Comutarea etichetei(label swapping) schimbarea valorii etichetei in antetul MPLS in timpul dirijarii MPLS. LSR (Label Switching Router) reprezinta un router care suporta tehnologia MPLS, mai precis, are capacitatea de a comuta pachete pe baza etichetei atasate acestuia. Label Edge Router(LER) Este un LSR care accepta pachete neetichetate(pachete IP) si le adauga etichete in partea de intrare.LER de asemenea inlatura etichetele la marginea (granita) retelei MPLS si trimite pachetele neetichetate in reteaua IP in partea de iesire. Forwarding Equivalence Class(FEC) Orice set de proprietati care traseaza pachetele de intrare aceleiasi eticheta de iesire.In general un FEC este echivalent cu o ruta(toate pachetele destinate clasei 10.0.0.0/8 corespund aceluiasi FEC), dar definitia unui FEC se poate schimba cand pachetele sunt rutate dupa alte criterii decat destinatia adresei IP. Label Switched Path (LSP) reprezinta o succesiune de noduri (R0-Rn) n cadrul carora un pachet este comutat de la R0 pna la Rn prin intermediul mecanismelor de 15

comutatie de etichete. O astfel de cale de comutatie de etichete poate fi stabilita dinamic, prin mecanisme de rutare normale, sau static, prin configurare explicita. Stiva de etichete(label stack) separat de schimbarea etichetelor dintre LSRs si vecinii lor, pentru aplicatii cum ar fi MPLS-VPN, o eticheta capat-la-capat este schimbta.Ca rezultat, este folosita o stiva de etichete in schimbul unei singure etichete MPLS.Un important concept de retinut este ca dirijarea in retelele core(centrale) se bazeaza doar pe eticheta din varful stivei.In contextul MPLS TE , stiva de etichete este ceruta cand un pachet etichetat intra intr-un tunel MPLS TE. PE Router (Provider Edge Router) reprezinta un router aflat sub administrarea furnizorului de servicii, care se interfateaza cu unul sau mai multe echipamente ale clientului. CE Router (Customer Edge Router) n mod similar cu PE Router, acesta reprezinta un echipament aflat sub administrarea clientului, si care se interfateaza cu unul sau mai multe PE-Routers. P Router (Provider Router) reprezinta un echipament din Core-ul retelei furnizorului de servicii, care nu are contact cu nici un echipament al clientului. Acest tip de router este utilizat strict pentru a comuta pachetele cu etichete ntre routerul PE de intrare (ingress) si cel de iesire (egress). Ingress Router reprezinta routerul PE prin intermediul caruia pachetele intra n reteaua MPLS. Egress Router reprezinta routerul PE prin intermediul caruia pachetele parasesc reteaua MPLS. BGP (Border Gateway Protocol) protocol de rutare intra-domeniu prin intermediul caruia routerele schimba informatie de rutare cu alte echipamente pe care ruleaza un soft BGP. CoS (Class of Service) o caracteristica ce ofera servicii diferentiate prin intermediul unei retele de infrastructura MPLS. GRE (Generif Router Encapsulation) reprezinta un protocol de tunelare dezvoltat de catre Cisco, protocol care poate ncapsula o larga varietate de tipuri de pachete n cadrul unor tunele IP crend astfel o legatura punct-la-punct virtuala ntre routerele Cisco distante prin intermediul unei infrastructuri IP. Prin conectarea a mai multor subretele cu protocoale diferite de rutare, n cadrul unei infrastructuri IP, se creeaza un mediu de back-bone ce utilizeaza un singur protocol. IGP (Interior Gateway Protocol) reprezinta un protocol Internet utilizat pentru a schimba informatie de rutare n cadrul aceluiasi sistem autonom (Autonomous System). Exemple de astfel de protocoale sunt: IGRP, OSFP, RIP, iBGP. IS-IS (Intermediate System-to-Intermediate System) reprezinta un protocol linkstate prin intermediul caruia, sistemele intermediare (routerele) schimba informatie de rutare pe baza unei singure metrice cu scopul de a determina topologia retelei. 16

LSP Tunnel o conexiune configurata ntre doua routere, n cadrul careia, pentru transmiterea pachetelor ntre cele doua routere, se utilizeaza tehnologia MPLS. LSA (Link-state Advertisment) reprezinta un pachet broadcast utilizat de protocoalele link-state. LSA contine informatii despre routerele vecine si costul caii pna la acestea si este utilizat de catre routerul destinatar pentru a mentine o tabela de rutare. Printre atributele rutei se numara: urmatorul nod BGP, adresa gateway, si altele. RD (Route Distinguisher) reprezinta o valoare de dimensiune 8 octeti (64 biti) care se concateneaza cu prefixul IPv4 pentru a crea un prefix unic la nivel global VPN-IPv4. Datorita acestuia, la VPN-uri se pot utiliza adrese private care trebuie sa fie unice numai pentru fiecare VPN n parte, nu la nivel global. RIP (Routing Information Protocol) un protocol IGP utilizat pentru schimbul de informatii de rutare n cadrul unui sistem autonom. RIP este un protocol simplu care utilizeaza ca metrica de rutare numarul de noduri. Router Aval (Downstream Router) reprezinta routerul catre care circula pachetele n cadrul unei conexiuni. El este acela care, de obicei, aloca etichetele necesare transmiterii de pachete prin intermediul tehnologiei MPLS. Router Amonte (Upstream Router) reprezinta routerul dinspre care cicrula pachetele n cadrul unei anumite conexiuni. El primeste o anumita eticheta pentru o destinatie data, de la routerul aval si o ataseaza pachetelor pe care trimite catre destinatia respectiva. Traffic Engineering (TE) reprezinta o serie de tehnici si proceduri utilizate pentru a directiona traficul rutat pe o anumita cale, alta dect cea care ar fi fost aleasa de catre protocoalele de rutare standard pentru a obtine n acest fel anumite avantaje. Traffic Engineering Tunnel (TE Tunnel) reprezinta un LSP utilizat pentru implementarea unei politici de TE. Este stabilit prin alte metode dect rutarea de nivel 3 clasica si este utilizat pentru directionarea traficului pe o alta ruta dect cea care ar fi fost utilizata prin rutarea standard. Tunelare este o arhitectura care furnizeaza serviciile necesare pentru implementarea oricarei strategii de ncapsulare punct-la-punct. VPN (Virtual Private Network) O retea securizata IP care partajeaza resursele n cel putin una din retelele sale fizice. Un VPN contine locatii fizice distante care pot sa comunice n siguranta folosind un back-bone partajat. VRF (VPN Routing and Forwarding Instance) Un VRF consta n urmatoarele: o tabela de rutare IP, o tabela derivata de forwardare, un set de interfete care vor utiliza tabela de forwardare, un set de reguli si protocoale care vor determina ce anume nregistrari vor fi inserate n tabela de forwardare. n general, un VRF contine informatia de rutare care defineste o locatie VPN a unui client, care este atasata unui router PE.

17

2.2. Cum funcioneaz MPLS MPLS lucreaz prin etichetarea pachetelor cu un identificator (etichet) pentru a fi identificat o cale numit LSP (Label Switching Path). Atunci cnd este primit un pachet, ruterul folosete aceast etichet pentru a identifica un LSP. Dup aceasta el va cuta n propriul tabel de ndrumare pentru a determina calea prin care s ndrume pachetul i eticheta care va fi folosit n cadrul urmtorului nod. Vechea etichet este nlocuit cu cea nou i pachetul este trimis ctre urmtoarea destinaie. n reelele MPLS etichetele fac regulile de trimitere a pachetelor Se folosete o etichet diferit pentru fiecare nod, i aceast etichet este aleas de ctre ruterul sau switch-ul care realizeaz operaia de ndrumare a pachetului. Acest lucru ne permite s folosim motoare de rutare foarte simple i rapide, deoarece ruterul poate selecta eticheta astfel nct s minimizeze procesarea. Ruterele de intrare (marginale) ale reelei MPLS folosesc adresa de destinaie a pachetelor pentru a determina care va fi LSP-ul folosit. n interiorul reelei, ruterele MPLS folosesc numai etichetele LSP pentru a ndruma pachetele ctre ruterul de ieire.

Figura 2.2.1 Dirijarea pachetelor n interiorul unui domeniu MPLS ER (Edge Router) -ruter de frontiera al domeniului MPLS LSR (Label Switch Router) - comutator de etichete/ruter intern domeniului MPLS LSP - Label Switched Path)- cale cu comutatie de etichete MPLS Exist astfel o serie de avantaje fa de mecanismele din reelele obinuite: Trimiterea pachetelor poate fi executat de switch, care face verificarea etichetei i nlocuirea ei, dar nu face analiza pachetelor pe nivele OSI superioare. Switch-urile ATM fac funcii asemntoare prin comutarea de celule bazate pe

18

valorile VCI/VPI gsite n header-ele celulelor ATM. Dac valoarea VCI/VPI este nlocuit cu etichete, atunci switch-urile ATM pot trimite celule n reeaua ATM folosindu-se de valoarea etichetelor. Switch-ul ATM trebuie s fie controlat de un element de control bazat pe tehnologia IP, numit LSC (Label Switch Controller) i care este elementul principal n integrarea tehnologiei IP cu tehnologia ATM folosind tehnologia MPLS. Asignarea pachet-etichet se face la intrarea pachetului n reeaua MPLS. Router-ul de intrare poate folosi orice informaie pe care o are despre pachet, cum ar fi portul sau interfaa de intrare, chiar dac informaia nu poate fi obinut din header-ul care descrie nivelul reea. Acelai pachet este marcat diferit dac el intr n reea prin routere diferite. Astfel deciziile de trimitere a pachetelor care depind de routerul de intrare se fac mai uor. Acest lucru nu poate fi fcut n reelele obinuite deoarece informaia care descrie routerul care a trimis pachetul nu este cuprins n pachet. Pachetele care sosesc pe interfee diferite vor avea etichete diferite. Acest mecanism de etichetare st la baza funcionalitii reelelor MPLS. Reelele cu control de trafic foreaz pachetele s urmeze o anumit cale, alegandu-se calea cea mai liber. De obicei aceast cale este prestabilit cnd pachetele intra n reea, i mai rar aceste ci sunt stabilite de algoritmi de rutare dinamici. In tehnologia MPLS etichetele pot fi folosite ca reprezentri pentru diferite route, astfel nu este nevoie de informaie de rutare suplimentar n pachet. Clasa de servicii pentru un pachet este determinat de nodul MPLS prin care intr pachetul. Astfel acest nod poate aplica pachetelor diferite politici de prioritizare a pachetelor. Nodurile urmtoare pot aplica pachetelor diferite politici specifice nodului respectiv numite PHBs (per-hop behaviors).[12] Noduri in retelele MPLS n retelele MPLS exista 3 tipuri de noduri: -Noduri de intrare (Ingress Label Edge Router) au rolul de a clasifica fiecare pachet n clase de echivalenta (FEC). Pentru fiecare clasa de echivalenta se face o asociere catre un NHLFE. Acest NHLFE contine informatii despre ce trebuie facut cu aceste pachete, care este eticheta de iesire, si care este urmatorul nod. Corespondenta ntre FEC si NHLFE se numeste FTN (FEC to NHLFE). - Noduri intermediare (Label Switch Router) Au de facut comutatia etichetelor. Pentru o eticheta de intrare se consulta tabelul ILM si se afla ce NHLFE trebuie folosit. Se consulta apoi NHLFE-ul indicat si se obtine urmatoarea eticheta si urmatorul nod din cale - Noduri de iesire (Egress Label Edge Router) Elimina eticheta din vrful stivei si dirijeaza pachetul conform informatiilor ramase (de regula conform tabelului de rutare IP). Si acest nod contine un LIB, dar mai contine si o tabela de rutare IP valida.[RFC3031] Prelucrarile facute n aceste noduri sunt prezentate n figura urmatoare.

19

Fig. 2.2.2 Stiva de protocoale si tabelele folosite n nodurile MPLS Nodurile MPLS, pe lang comutarea de pachete bazate pe etichete, mai pot realiza i rutare Layer 3 sau switch-ing Layer 2. n figura urmtoare este reprezentat arhitectura unui nod MPLS din punctul de vedere al celor dou plane:

Fig 2.2.3. Arhitecura unui nod MPLS Planul de trimitere pachete Planul de trimitere de pachete (Forwarding Plane) este responsabil de trimiterea de pachete bazat pe informaia din etichetele ataate pachetelor. Acest plan folosete 20

LFIB (Label Forwarding Information Base), o baz de date folosit pentru trimiterea pachetelor. Algoritmul folosit de comutarea de pachete folosete informaia coninut n LFIB, precum i informaia coninut n eticheta.Fiecare nod MPLS are dou tabele importante: LIB ( Label Information Base) i LFIB. LIB conine toate etichetele asignate de nodul MPLS local i legtura acestor etichete cu etichetele recepionate de la nodurile MPLS vecine. LFIB folosete un subset de etichete din LIB pentru trimiterea pachetelor.

2.2.1 Etichetele MPLS Etichetele sunt o parte integrala a Multiprotocol Label Switching. Eticheta permite decuplarea rutarii de dirijare, permitand astfel sa se realizeze abil unele lucruri. MPLS poate opera in doua moduri: -Frame mode(modul cadru) -Cell mode(modul celula) 2.2.1.1 Frame mode Frame mode este termenul folosit atunci cand se dirijeaza un pachet cu o eticheta atasata pachetului in fata antetului de Layer 3(de exemplu: antetul IP) O eticheta este valoarea atasata pachetului care spune retelei unde pachetul ar trebui sa ajunga. Eticheta are 20 biti, ceea ce inseamna ca pot fi 2 posibile valori a etichetei. Un pachet poate avea multiple etichete,carate in ceea ce se numeste:stiva de etichete.O stiva de etichete este un set de una sau mai multe etichete per pachet. La fiecare hop intr-o retea , este luata in considerare numai cea mai de sus eticheta. Eticheta pe care un LSR o foloseste pentru a dirija pachetul in planul de date este eticheta asignata si distribuita in planul de control. Cand etichetele sunt plasate intr-un pachet,valoarea etichetei insasi de 20 de biti este codata cu niste elemente aditionale de informatie care asista in dirijarea pachetului etichetat prin(in) retea. n continuare este prezentata structura acestui antet, precum si cmpurile sale.

21

Figura 2.2.4 Structura antetului MPLS ETICHETA=20 biti EXP=Experimental,3 biti S=Baza stivei(Bottom of stack),1 bit TTL=Timpul de viata(Time to live),8 biti Eticheta MPLS si cu antetul acesteia este ilustrata mai sus, n Figura 2.2.4. Ea este formata din urmatoarele cmpuri: _ Eticheta propriu-zisa, care are dimensiunea de 20 biti. _ Cmpul EXP (Experimental) se foloseste pentru a indica Clasa de Servicii (CoS) si are dimensiunea de 3 biti. Aceasta nseamna ca se pot folosi simultan maxim 2 = 8 clase de servicii. _ Cmpul S (baza stivei de etichete) are dimensiunea de 1 bit si este folosit pentru a indica daca eticheta curenta este ultima, prin eliminare rezultnd un pachet nativ IP, sau dimpotriva, sub eticheta curenta se mai gasesc alte etichete. _ Cmpul TTL (Time to Live, Timp de Viata) are dimensiunea de 8 biti si se foloseste pentru evitarea aparitiei buclelor. Eticheta Stiva Bitul de stiv implementeaz stiva de etichete MPLS, n cazul n care unui pachet IP i se ataeaz mai mult de o etichet. Bitul de stiv este setat la "1" pentru a indica stiva goala i la "0" pentru celelalte situaii. n eticheta MPLS, vrful stivei apare chiar dup header-ul nivelului Legtura de date, iar sfritul stivei chiar nainte de header-ul nivelului Reea. Trimiterea de pachete este fcut innd seama de eticheta din vrful stivei. Rutarea IP unicast nu folosete etichete stivuite, dar MPLS VPN (Virtual Private Network) i controlul i managementul traficului folosesc etichetele stivuite. TTL n rutarea IP tradiional, fiecare pachet poart cu el o valoare numit timp de via n antetul su. De fiecare dat cnd un pachet trece printr-un ruter, valoarea sa TTL este decrementat cu o 22

unitate; dac TTL ajunge la 0 nainte ca pachetul s ajung la destinaie, pachetul va fi eliminat. Acest lucru asigur un anumit nivel de protecie mpotriva buclelor de rutare care pot exista datorit configurrilor greite, sau datorit erorilor sau convergenei slabe a algoritmilor de rutare. TTL este cteodat folosit pentru alte funcii, cum ar fi comanda traceroute sau multicast scoping. Acest lucru implic faptul c avem dou probleme legate de TTL: 1. TTL ca o modalitate de a suprima buclele; 2. TTL ca modalitate de a realiza alte funcii, cum ar fi limitarea utilizrii unui pachet. Cnd un pachet traverseaz un LSP, el ar trebui s ias din acesta cu aceeiai valoare TTL pe care ar fi avut-o dac ar fi traversat aceeiai secven de rutere, ns ruterele s nu fi fost comutatoare de etichete. Dac pachetul traverseaz o ierarhie de LSP-uri, numrul total de LSRuri traversate va fi reflectat n valoarea TTL atunci cnd pachetul va iei din aceast ierarhie de LSP-uri. LFIB (Label Forwarding Information Base) Aceast baz de date coninut n nodul MPLS const ntr-o secvena de intrri, aa cum este ilustrat n figura de mai jos.

Figura 2.2.5 Structura LFIB Aa cum se observ n figur, fiecare intrare este alctuita dintr-o etichet de intrare i una sau mai multe subintrri. LFIB este indexat de valoarea coninut n eticheta de intrare. Fiecare subintrare este alctuit din o etichet de ieire, o interfaa de ieire, i adresa nodului urmtor. Trimiterea de pachete multicast necesit subintrri cu multiple etichete de ieire, deoarece un pachet ce intr pe o interfaa trebuie s ias pe mai multe interfee de ieire. Pe lang eticheta de ieire, interfaa de ieire, i informaia despre nodul urmtor, o intrare n tabela de trimitere a pachetelor poate cuprinde informaii referitoare la resursele ce pot fi folosite de pachet, cum ar fi coada de ieire n care ar trebui plasat pachetul. Un nod MPLS poate avea o singura tabel de trimitere a pachetelor, o tabel pe fiecare interfaa, sau o combinaie dintre cele doua.[12]

23

2.2.1.2 Cell mode(modul celula) Cell mode este un termen folosit atunci cand reteaua contine ATM LSRs care foloseste MPLS in planul de control pentru a schimba informatia din campul VPI/VCI, in locul semnalarii ATM. In cell mode, eticheta este codata in campul celulei VPI/VCI(Figura 2.2.6).Dupa ce schimbul etichetei este realizat in planul de control, in planul de date(dirijare),router-ul de intrare segmenteaza pachetul in celule ATM, aplica valoarea VPI/VCI corespunzatoare care a fost schimbata in planul de control si transmite celulele. In mijlocul retelei MPLS, ATM LSR se comporta ca niste comutatoare ATM normale. La iesirea din reteaua MPLS, router-ul de iesire reasambleaza celulele intr-un pachet. Cell mode se mai numeste Label-Controlled ATM(LC-ATM).MPLS TE nu este suportat in cell mode pe routerele Cisco. Denumirea de Comutatie de Etichete Multiprotocol provine din faptul ca aceasta tehnologie poate fi folosita n conjunctie cu mai multe protocoale, precum ATM, SONET, SDH, etc. Pentru a putea functiona la fel cu fiecare din aceste protocoale, a fost necesar sa se stabileasca n ce mod va fi ncapsulata eticheta MPLS n cadrele cu o structura deja stabilita. Aceasta ncapsulare se realizeaza ca n Figura 2.2.6.

Figura 2.2.6 Aezarea etichetei n celula ATM i n pachetul Ethernet Dupa cte se poate observa din figura, n cazul ATM, eticheta nlocuieste perechea VPI-VCI. n cazul n care se foloseste PPP (SONET sau SDH) eticheta se interpune ntre antetul PPP si antetul nivelului retea. n mod similar la antetul LAN MAC, eticheta se interpune ntre antetul MAC si antetul nivelului retea, acest lucru se numeste adaugarea antetului.Cand operam in frame-mode(modul cadru) MPLS vom avea intotdeauna adaugarea de antet. Acest lucru este aplicabil si cand se conecteaza routere peste ATM PVCs si se realizeaza MPLS in mediul clasic IP-peste-ATM.

24

2.3 Arhitectura MPLS MPLS este alcatuit din doua mari componente: -planul de control -planul de date 2.3.1 Planul de control Planul de control MPLS este responsabil de popularea i meninerea informaiei din LFIB. Toate nodurile MPLS trebuie s ruleze un protocol de rutare IP pentru a schimba informaie IP de rutare cu toate celelalte noduri MPLS din reea. Nodurile ATM ce pot trimite pachete MPLS lucreaz cu un LSC (Label Switch Controller) pentru a putea participa la acest schimb de informaie. Protocoalele de rutare OSPF (Open Shortest Path First) sau IS-IS ( Intermediate System to Intermediate System), pot fi o alegere pentru protocoale de distribuire. n routerele convenionale, tabela de rutare IP este folosit pentru a construi FSC (Fast Switching Cache) sau FIB (Forwarding Information Base). n reelele MPLS, tabele de rutare IP furnizeaz infomaie n reeaua destinaie pentru atribuirea etichetelor. Informaia despre distribuirea etichetelor poate fi transportat n reea folosind protocolul LDP (Label Distribution Protocol). Protocolul de rutare OSPF inund cu informaie rutere care nu sunt neaprat adiacente, n timp ce distribuirea de etichete cu ajutorul protocolului LDP se face doar la routerele adiacente. Acest lucru face evident alegerea unui protocol special de distribuie a informaiilor despre etichete. Planul de control construieste o tabela de rutare(RIB-Baza de rutare a informatiei) pe baza protocoalelor de rutare. Planul de control foloseste un protocol de schimbare a etichetei pentru a crea si mentine etichetele interne, si pentru a schimba aceste etichete cu alte echipamente. Protocoalele de schimbare a etichetei includ MPLS LDP sau TDP, BGP(folosit de MPLS VPN) si RSVP(folosit de MPLS TE pentru a realiza schimbul de etichete). Planul de control construieste de asemenea doua tabele de dirijare: FIB de la informatiile din RIB, si LFIB(Label Forwarding Information Base) ce se bazeaza pe protocolul de schimbare a etichetei si RIB. Tabela LFIB include valoarea etichetelor si asocierea cu interfetele de iesire pentru fiecare prefix a retelei. Etichetele schimbate cu nodurile MPLS adiacente sunt folosite la construirea LFIB. MPLS folosete o metoda de trimitere a pachetelor bazat pe schimbarea etichetelor care poate fi combinat cu o serie de diferite module de control. Fiecare modul de control este responsabil pentru distribuirea i asignarea de etichete, precum i de meninerea altor informaii.[12] Module de control MPLS Modulele de control MPLS includ: Modulul de rutare Unicast Modulul de rutare Multicast Modulul de control al traficului Modulul de VPN (Virtual Private Network) 25

Modulul de QoS (Quality of Service) Modulul de rutare Unicast Acest modul construiete tabela FEC folosind IGP (Interior Gateway Protocol). Tabela de rutare IP este folosit pentru a schimba informaia despre etichete cu nodurile adiacente. Aceasta schimbare de informaie se face cu ajutorul protocolului LDP. Modulul de rutare Multicast Acest modul construiete tabela FEC folosind un protocol de rutare numit PIM (Protocol Independent Multicast). Tabela de rutare multicast este folosit pentru a schimba informaii despre etichete cu nodurile alturate pentru subreelele din tabela de rutare multicast. Modulul de control al traficului Modulul de control al traficului las explicit ca anumite LSP (Label Switched Path) s fie create n reea din motive de control al traficului. Folosete definiia de tunel MPLS i folosete o extensie a protocolului de rutare OSPF pentru a construi tabela FEC. Schimbul de etichete este fcut cu ajutorul protocolului RSVP (Resource Reservation Protocol) sau CR-LDP(Constraint-based Routing LDP) care este o extensie a protocolului LDP. Modului VPN (Virtual Private Network) Acest modul este folosit pentru tabelele VPN de rutare si pentru asocierile FEC, in cazul VPN-urilor implementate prin etichete stivuite. Modulul de QoS Acest modul construiete tabela FEC folosing protocoale de rutare IGP cum ar fi: OSPF, IS-IS, etc. Tabela de rutare IP este folosit pentru schimbul de etichete ntre nodurile MPLS adiacente.

2.3.2 Planul de date Planul de date este o simpla masina de dirijare ce este independenta de protocolul de rutare sau protocolul pentru schimbarea etichetei folosit. Planul de date dirijeaza pachetele pe interfata corespunzatoare pe baza informatiilor din tabelele LFIB si FIB.

26

Figura 2.3 Baza de informatie Algoritmul de trimitere a etichetelor Switch-urile de etichete folosesc un algoritm de trimitere bazat pe nlocuirea de etichete. Nodurile MPLS care folosesc tabele LFIB, extrag valorile etichetei din cmpul de eticheta al pachetelor care au sosit i folosesc aceasta valoare ca index n LFIB. Dup ce a gsit o intrare n tabel nodul MPLS nlocuiete eticheta din pachet cu eticheta de ieire din subintrarea corespunztoare, trimite pachetul prin interfaa specificata ctre nodul urmtor specificat n subintrare. Dac subintrarea specific i o coad de ieire, atunci nodul MPLS plaseaz pachetul n coada specificat. Dac nodul MPLS folosete multiple tabele LFIB pentru fiecare interfaa a sa, el va folosi interfaa pe care vine pachetul pentru a selecta un LFIB care va fi folosit pentru trimiterea pachetului mai departe. n reelele convenionale pentru trimiterea pachetelor se folosesc mai multe tipuri de algoritmi n funcie de tipul pachetelor, unicast, multicast i pachete unicast cu biii de Type of Service(ToS) setai. n tehnologia MPLS se folosete o singura metod de trimitere a pachetelor, i anume cea bazat pe nlocuirea de etichete. Un nod MPLS poate obine toat informaia de care are nevoie pentru a trimite un pachet precum i rezervarea de resurse necesare pentru el folosind o singur memorie de acces. Acest lucru duce la o mrirea vitezei de trimitere a pachetelor. MPLS poate de asemenea s transporte alte protocoale de nivel 3, cum ar fi: Ipv6, IPX sau AppleTalk. 2.4 Elementele MPLS Principalele elemente MPLS sunt: Comutator de Etichete (Label Switched Router ) LSR Cale cu comutaie de etichete (Label Switched Path ) LSP Protocol pentru distribuia etichetelor (Label Distribution Protocol) LDP,CRLDP,RSVP,BGP. 27

2.4.1 Comutator de Etichete (Label Switch Router) - LSR LSR este un echipament care implementeaz componentele de trimitere i control MPLS. LSR-ul trimite un pachet bazndu-se pe valoarea unei etichete ncapsulate n pachet. De asemenea, LSR-ul poate trimite pachete de Layer 3. LSR-urile sunt routere ce pot prelucra pachete MPLS sau switch-uri ATM care folosesc etichete pentru a trimite trafic. LSR-urile bazate pe pachete, pot fi uor construite prin ncrcarea unui modul software ntr-un router obinuit. LSR-urile ATM/MPLS sunt construite folosind switchurile ATM, cu software MPLS integrat sau prin adugarea facilitaii MPLS folosind un LSC (Label Switch Controler) extern. Un pas important n comutarea de etichete, este comunicarea ntre LSR-uri pentru stabilirea etichetelor pe care le vor folosi pentru a trimite pachete. Ele cad de acord folosind protocolul Label Distribution Protocol (LDP) sau extensii ale lui cum ar fi: PIM, BGP, RSVP, sau CR-LDP. LSR-urile de nod de reea MPLS, sunt localizate n locaiile de prezenta POP (Point of Presence) sau la grania reelei MPLS i aplic etichete sau stive de etichete pachetelor. Atribuirea de pachete sau pregtirea etichetelor pentru pachete este denumit aciune push". LSR-urile de nod de asemenea fac nlturarea etichetelor n punctele de ieire din reeaua MPLS, aciune care se mai numete aciune pop". LSR-urile de nod de reea pot de asemenea trimite pachete IP normale. Aciunile care pot fi ntreprinse de un LSR sunt enumerate n continuare. Aciunea asupra etichetelor Pop Descriere nltura eticheta din vrful stivei si trimite cmpul de da date rmas ca un pachet IP neetichetat

eti

Push Swap

nlocuiete eticheta din vrful stivei cu un set de etichete nlocuiete eticheta din vrful stivei cu alta valoare Tabelul 1. Actiunile care pot fi intreprinse de un LSR

Operaiile LSR bazate pe pachete MPLS folosete noiunea de trimitere de pachete bazate pe etichete pentru a transporta pachete de Layer 3 peste o reea bazat pe rutare.Operaiile de baza ale unui LSR sunt figurate n desenul urmtor:

28

LSR 3 R2 R1
0

LSR 1
1 0

LSR 2 1 LSR 4
2

In I/F 0 ...

In Address Lab Prefix 171.68/16 ...

Out Out I/F Lab 1 7 ...

In I/F 0 ...

In Address Lab Prefix 7 171.68/16 ...

Out Out I/F Lab 2 8 ...

R3

Next-Hop Next... ...

Next-Hop Next... ...

171.68.0.1/16

Figura 2.4.1 Operatii de baza LSR LSR1 funcioneaz ca un router LSR de nod de reea. El aplic etichete iniiale pachetului dup ce face o verificare convenional a header-ului IP i determin FEC-ul pentru acel pachet. Parametrii cum ar fi: interfaa de intrare, n cazul unei VPN (Virtual Private Network) sau o cale predeterminat de trimitere a pachetului, pot de asemenea determina alegerea unui anume FEC. Aceast alegere a FEC-ului este realizat o singur dat la intrarea n reeaua MPLS. Dup ce pachetul este etichetat, LSR-ul urmtor trimite pachetul folosind doar eticheta. LSR-urile, de regul, nlocuiesc eticheta unui pachet venit cu o nou valoare pe care o trimit mai departe. La ieirea din reea, LSR4 face o cutare n tabela lui intern, extrage eticheta, i face o cutare de Layer 3 pentru a gsi urmtoarea destinaie trimind pachetul ctre aceasta. [19] 2.4.2 Cale cu comutaie de etichete (Label Switched Path)- LSP LSP-ul este o conexiune configurat ntre dou LSR-uri n care tehnica de comutare de etichete este folosit pentru a trimite pachetele. Un LSP este o cale specific de trafic printr-o reea MPLS. LSP-urile sunt furnizate folosind LDP-ul, RSVP-TE (Resource Reservation Protocol with Traffic Engineering), CR-LDP (Constraint-Based Routed LDP) sau extensii ale protocoalelor de rutare cum ar fi BGP. RSVP-TE ruleaz peste protocolul UDP, i CR-LDP ruleaz peste protocolul TCP. ntre cele dou protocoale nu exist mare diferen, totui protocolul RSVP-TE este mai indicat pentru interoperabilitatea cu reelele IP. LSP-ul poate fi considerat ca o cale printre mai multe LSR-uri n care pachetele aparin unui anumit FEC. Este posibil ca ntr-o reea MPLS s avem diferite LSP-uri la diferite nivele ale etichetelor pentru un pachet care i atinge destinaia. LSP-urile sunt unidirecionale. Aceasta nseamna c un pachet se poate ntoarce pe ci diferite. n figura urmtoare, LSR1 i LSR6 sunt LSR-uri de nod, i LSR2, LSR3, LSR4 i LSR5 sunt LSR-uri de backbone. Pentru a putea trimite etichetele, LSR1 i LSR6 lucreaz la nivel de border gateway" i LSR2, LSR3, LSR4 i LSR5 lucreaz la nivel de interior gateway". Acest desen figureaz dou LSP-uri: un LSP de nivel 1 capt la capt de la LSR1 la LSR6, i un LSP de nivel 2 ntre LSR4 i LSR5. Pentru a putea construi un LSP, LSR-ul folosete protocoale de rutare i rutele nvate de la aceste protocoale.

29

Figura 2.4.2 Stabilirea unui LSP Un LSP se poate stabili prin una din cele dou posibiliti: Controlul independent Controlul ordonat Controlul ordonat i controlul independent pentru stabilirea uni LSP, pot coexista n aceeai reea fr nici un fel de problem din punct de vedere al arhitecturii sau interoperabilitii. Metoda independent furnizeaz o convergent i stabilire a LSP-ului mai rapida, deoarece, LSR-ul poate stabili i trimite etichete oricnd, fr ntrziere sau ateptare pentru mesajele ce urmeaz a fi propagate dintr-o parte a reelei n alta. Stabilirea LSP-ului depinde foarte mult de protocolul de rutare. n metoda controlului ordonat, legturile sunt propagate de-a lungul reelei nainte ca LSP-ul s fie stabilit. Aceast metod furnizeaz o mai bun prevenire i evitare a buclelor. [12] 2.4.3 Protocoale de distributie a etichetelor 2.4.3.1 LDP(Label Distribution Protocol) Label Distribution Protocol este un protocol definit n RFC 3036. n acest document sunt specificate mesajele comunicate ntre noduri, precum si formatul acestor mesaje. O sesiune LDP ncepe prin descoperirea vecinilor. Astfel toate nodurile trimit pachete de tip Hello la o adresa multicast. Doar vecinii directi vor raspunde si astfel se va stabili o sesiune TCP ntre 2 vecini. Prin intermediul acestei sesiuni, cei doi vecini si comunica parametrii doriti. Dupa initierea sesiunii, partenerii trimit un mesaj de tip Initialization prin care stabilesc modul de functionare (cum ar fi daca se foloseste detectia buclelor, sau distributia etichetelor nesolicitata). Daca parametrii sunt acceptati ncepe distributia etichetelor prin mesaje care fac o corespondenta de genul: pentru a ajunge la destinatia X foloseste eticheta 30

Y. Nodurile si comunica pe rnd destinatiile cunoscute si etichetele ce vor trebui folosite pentru a ajunge la destinatie. Daca o eticheta propusa nu este acceptata (cel mai probabil deoarece este deja folosita si nodul nu suporta modul de lucru cu spatiu de etichete pe interfata), se raspunde cu un mesaj Notification. Astfel, cei doi vecini negociaza ce etichete vor folosi pentru anumite destinatii si la finalul negocierii si completeaza tabela de dirijare.

Fig 2.4.3(1) Stabilirea sesiunilor LDP ntre vecini Conexiunea TCP ntre cei 2 vecini este mentinuta permanent si periodic se trimit mesaje de tipul KeepAlive. Mesajele initiale de tip Hello sunt trimise prin UDP si au un rol similar cu mesajele KeepAlive. Diferenta este ca mesajele Hello indica faptul ca un link ntre vecini este activ, pe cnd mesajele KeepAlive indica faptul ca un vecin este activ. Acest lucru este evident cnd exista mai multe linkuri ntre 2 vecini; astfel se vor primi mai multe pachete Hello, dar un singur KeepAlive. Solutia aceasta ajuta LDP sa fie mai scalabil n retelele mari. [RIBL][RFC3036][MPLS-TE] Distributia etichetelor se poate face n doua moduri: -Downstream on Demand. -Downstream Unsolicited. Modul Downstream on Demand presupune construirea caii LSP cnd apare necesitatea de a trimite trafic prin acel LSP. Nodul de intrare n reteaua MPLS primeste trafic corespunzator unui FEC nou. Entitatea LDP va cere o eticheta nodului din aval. 31

Nodul din aval face si el o cerere de eticheta urmatorului nod si nu trimite nimic napoi nodului de intrare pna nu primeste un raspuns. Procesul continua pna cnd penultimul nod cere o eticheta nodului de iesire. Dupa ce se ntmpla acest lucru, etichetele sunt alocate ncepnd de la nodul de iesire pna la nodul de intrare, de unde si numele downstream-on-demand .

Fig 2.4.3.(2) Modul de lucru Downstream on Demand n modul de lucru Downstream Unsolicited un ruter propune etichete pentru toate prefixele IP cunoscute, catre toti vecinii, fie ca au cerut etichete, fie ca nu. Deoarece etichetele propuse nu sunt folosite efectiv n dirijarea pachetelor n mod implicit, nu este gresit sa se trimita etichete tuturor vecinilor, chiar daca acei vecini nu folosesc acest ruter ca urmatorul nod. LDP nu este un protocol de rutare; el depinde de un protocol de rutare pentru a elimina buclele (desi are si mecanisme de detectie si prevenire a buclelor, folosibile n retele ATM). Modul de lucru Downstream Unsolicited presupune faptul ca un nod poate primi etichete de care nu are nevoie. Se pune problema daca nodul va stoca acele etichete n cazul n care va fi nevoie de ele, sau daca le va ignora. Modul de lucru conservator implica ca ruterul va arunca etichetele de care nu are nevoie, ceea ce duce la eliberarea de spatiu n tabela de dirijare, dar n acelasi timp duce la stabilirea mai lenta a cailor. Modul liberal implica stocarea tuturor etichetelor primite si introducerea lor n tabela de dirijare, lucru care mareste spatiul ocupat, dar reduce timpul de stabilire a cailor. Alocarea etichetelor nu este singurul lucru pe care l face LDP. n anumite cazuri etichetele sunt retrase (daca se defecteaza un link catre o destinatie), astfel nct trebuie sa existe mesaje pentru a face acest lucru. Ca o particularitate LDP preia o parte din functiile MPLS n anumite cazuri. De exemplu, n retelele ATM, celulele MPLS nu au cmpul TTL. La intrarea n domeniul MPLSATM nodul de intrare decrementeaza TTL-ul pachetelor cu mai multe unitati conform cu numarul de noduri pe care trebuie sa le traverseze. Semnalizarea legata de numarul de 32

noduri se face prin pachete LDP. De asemenea, pentru evitarea buclelor n retelele ATM se folosesc cmpuri speciale din pachetele LDP pentru a stoca lista de noduri traversate. Daca un nod apare de doua ori, nseamna ca exista o bucla pe acea cale.[RFC3036] [MPLS-TE] 2.4.3.2 CR-LDP(Constraint Route Label Distribution Protocol) Constraint-based Routing Label Distribution Protocol este o extensie a LDP si introduce capabilitati de constructie a cailor comutate bazndu-se si pe alte informatii dect pe informatiile oferite de protocolul de rutare. Astfel se pot construi cai cu constrngeri explicite ale rutei (de exemplu se impune ca ruta sa treaca prin anumite noduri) sau cu constrngeri de calitate a serviciilor. De regula, CR-LDP afla informatiile necesare despre capabilitatiile linkurilor (banda disponibila, delay, jitter, etc) de la un protocol de rutare cu astfel de capabilitati. Un exemplu de astfel de protocol este OSPF-TE. CR-LDP a fost gndit sa fie utilizat n Traffic Engineering, dar poate fi folosit si n construirea VPN-urilor bazate pe MPLS.[RFC3213] 2.4.3.3 RSVP-TE(Resource Reservation Protocol) RSVP-TE reprezinta o propunere de a adauga functionalitate unui protocol deja consacrat, care sa-i permita sa distribuie si etichete. Ideea a apartinut companiei Cisco si astfel protocolul RSVP-TE a adoptat conceptele de QoS din IP n detrimentul conceptelor QoS din ATM. Aceasta alegere a avut ca scop principal interconectarea mai usoara ntre provideri. Desi initial RSVP nu a fost folosit n retelele core deoarece nu era scalabil, folosirea sa mpreuna cu MPLS i creste considerabil scalabilitatea. n acest scenariu clasele de echivalenta MPLS nu mai sunt la fel de rigide ca fluxurile RSVP, iar garantiile oferite nu mai sunt capat la capat. RSVP-TE este folosit pentru a stabili cai cu garantii numai n interiorul domeniului MPLS. n mod curent exista o concurenta ntre RSVP-TE si CR-LDP, dar se pare ca RSVP-TE este mai larg raspndit, deoarece a fost implementat timpuriu n echipamentele Cisco. [RFC3210] 2.4.3.4 BGP( Border Gateway Protocol ) Distributia de etichete MPLS prin BGP implica o extensie a protocolului BGP. Dorinta a fost sa se poata interconecta domenii autonome MPLS, fara a fi nevoie sa se ajunga la IP. n plus, BGP este larg raspndit n domeniile ce ofera VPN-uri, avnd un rol important n realizarea VPN-urilor MPLS. Totusi, ntre nodurile vorbitoare de BGP trebuie sa se stabileasca cai MPLS folosind alt protocol de distributie de etichete. 2.5 Avantaje si dezavantaje ale tehnologiei MPLS Tehnologia MPLS a fost definitivata n 2001, cnd specificatiile sale au fost ridicate la rangul de standard. Totusi, de atunci implementarile MPLS nu au crescut n ritmul asteptat. Acest lucru s-a datorat mai multor factori, cum ar fi recesiunea economica din 2001, care a dus la scaderea volumului de afaceri purtate prin Internet. n ultimii ani, retelele MPLS au nceput sa se dezvolte, n principal prin beneficiile pe care le aduc furnizorilor de servicii. 33

n continuare sunt argumentate cteva idei ce sustin folosirea MPLS n retelele core , dar si cteva idei care neaga importanta acestuia: Avantaje -Ruterele care nu au circuite specializate pentru procesul de rutare, sau alte metode pentru cautari rapide vor beneficia de o crestere de viteza n cazul folosirii unei implementari software MPLS - Este flexibil deoarece se poate baza pe informatiile de rutare furnizate de protocoalele de rutare traditionale folosite si de IP - Este usor de integrat treptat n retele mari bazate pe IP, deoarece ruterele MPLS pot comunica cu ruterele traditionale IP -Permite realizarea de retele virtuale private (VPN) cu un overhead mai mic dect n cazul IP-ului -Permite realizarea mai usor a unor functii de Traffic Engineering. -MPLS se poate integra usor n spectrul de servicii IP QoS Dezavantaje/Critici -MPLS are o dinamicitate mai mica fata de IP, deoarece lucreaza cu conexiune, si stabileste cai nainte de a transmite datele. Daca o cale se ntrerupe, protocolul de distributie de etichete va sesiza acest lucru dupa protocolul de rutare si va construi o noua cale nainte de a trimite trafic pe ea. -Comutatia MPLS nu este mai rapida dect rutarea IP. Ruterele noi folosesc memorii cache n care stocheaza rutele cele mai des folosite. Astfel cautarea n tabelul de rutare se reduce considerabil. ntr-un domeniu MPLS, ruterul de intrare si cel de iesire trebuie sa aiba si functionare IP. Prin faptul ca au de facut si prelucrari specifice MPLS, timpul lor de prelucrare e mai mare dect pentru un ruter IP. --Celelalte rutere au, ntr-adevar un timp de prelucrare mai mic, dar aceasta performanta se vede doar pentru cai cu mai mult de 5 noduri; daca sunt mai putine noduri, performanta ruterelor IP e mai buna. n plus, ruterele MPLS pot consuma mai multa memorie dect ruterele IP (deoarece trebuie sa tina si un tabel de rutare si tabel de dirijare). -MPLS nu are suport nativ pentru QoS acest lucru a fost adaugat ulterior prin folosirea bitilor EXP. n anumite situatii clasele de servicii diferentiabile prin 3 biti pot sa fie insuficiente pentru anumite retele. De asemenea, pot aparea probleme la implementari diferite; unii constructori pot sa nu tina cont de bitii EXP. [MPLS-Myths] [RIBL] [L3vsL2]

34

35

Cap.3. Ingineria Traficului n reele MPLS 3.1 Necesitatea Ingineriei de Trafic n MPLS Rolul ingineriei traficului (Traffic Engeneering TE) este de a transmite traficul de la o margine la alt ntr-o reea, n cel mai optim mod. Aceast tehnic este ntlnit nc din timpul reelelor Frame Relay sau ATM, unde se foloseau circuite virtuale pentru a planifica i transmite traficul. Cum n zilele actuale reele se bazeaz n principal pe o solutie IP, este nevoie de o soluie de inginerie a traficului n aceste reele. Acest lucru nu este posibil ntr-o reea pur IP, dar se poate implementa ntr-o reea IP-MPLS. Rutarea n reelele IP este reglementat de necesitatea de a transmite traficul din ntreaga reea ct mai rapid posibil. Acesta este motivul pentru care rutarea IP este bazata pe principiul celui mai mic cost de dirijare. Fiecare protocol IP de dirijare are un cost asociat cu legturile n reele. Acumularea de costuri ale fiecarui link pentru o cale, este folosita pentru a calcula cel mai mic cost al caii. Acest cost reprezint o metric ce este atribuit unui link (de exemplu, Open Short Path First [OSPF] i Intermediate System to Intermediate System [IS-IS]), o metric compus (de exemplu, Interior Gateway Routing Protocol [IGRP] i Enhanced Interior Gateway Routing Protocol [EIGRP]), sau pur i simplu un numr de hopuri (de exemplu, Routing Information Protocol [RIP] i RIP versiunea 2). Dirijarea IP nu ine seam de capacitatea disponibil de lime de band de pe un link, care ar putea diferi semnificativ de costul care este atribuit pe link. Prin urmare, un router poate pstra dirijarea de trafic pe o legtur, chiar dac acest link este deja plin i produce pierdere de pachete.

Figura 3.1 Dirijarea in retele IP De exemplu, in Figura 3.1, dac fiecare link din acest eantion de reea are acelai cost, costul cel mai mic pentru calea de la routerul R1 la routerul R5 este pe calea R1-R2-R5. n mod evident, tot traficul de la R1 la R5 va utiliza calea R1-R2-R5, i calea R1-R3-R4-R5 nu va avea nici un trafic. Putei distribui sarcina uniform schimband costul pe link-uri pentru un anumit protocol de dirijare. Asta ar putea distribui traficul mai uniform, dar niciodat nu poi distribui sarcina perfect, deoarece, n reelele reale, link-urile nu au, aproape niciodat, aceeai lime de band. n reeaua din figura 3.1, avei posibilitatea s va asigurati c cele dou ci sunt egale facand suma costurilor de link-uri n calea R1-R2-R5 i calea R1-R3-R4-R5 egala. Rezultatul va fi echilibrarea ncrcrii de trafic ntre R1 i R5 pe cele dou drumuri. Aceasta va fi bine pentru traficul ntre R1 i R5, dar va fi tot neechilibrat de exemplu traficul care intr n reea de pe R2 catre R4, i aa mai departe. Avem iar aceeasi problema, pentru c exist dou ci de la R2 la R4, putei avea aceeai problem ntre routere R3 i R5 sau la oricare dintre celelalte. De 36

asemenea in orice zi se poate lua decizia cresterii capacitatii unui link, in acest caz fiind inutil calculul facut mai devreme si va trebui sa refacem costurile. MPLS TE este o solutie pentru ca: - ajuta la rspndirea eficienta a traficului n ntreaga reea, evitnd neutilizarea i suprautilizarea link-urilor; - ine seama de configuratiile (statice) de latime de banda ale legturilor; - ia n considerare atributele legaturilor, precum: intarziere, jitter,etc; - se adapteaz automat la schimbarea de ltime de band pe un link; - se poate trimite traficul in retea dupa adresa sursa a pachetelor, nu neaparat dupa cea destinatie. MPLS TE permite ingineria traficului pentru un sistem n cazul n care routerul de la capul unei LSP (headend) poate calcula cea mai eficient cale prin intermediul reelei spre routerul de la coada LSP (tailend). Routerul de la capul LSP poate face acest lucru n cazul n care acesta cunoaste topologia de reea. n plus, routerul headend trebuie s tie restul de lime de band pentru toate link-urile din reea. n fine, este nevoie s fie permis MPLS pe routere astfel nct s se poat stabili LSP-uri cap la cap. Faptul c schimbarea de etichete este utilizata i nu comutarea dupa IP, calea poate fi definita in functie de adresa surs IP n loc de destinaie. Asta se datoreaz faptului c MPLS transmite in planul de date potrivind eticheta de sosire din tabela LFIB si o schimba cu o eticheta de expediere.[30] Prin urmare, routerul de la capul LSP, headend, este cel care poate determina dirijarea de pachete etichetate, dup ce toate LSR-uri cad de acord ce etichete s foloseasca pentru care LSP. Figura de mai jos arat un exemplu de dirijare pe baza de sursa, capacitate a MPLS TE.

Figura 3.2 Dirijarea cu ingineria traficului In figura 3.2, R6 doreste sa trimita traficul pe calea R6-R1-R2-R5, iar R7 vrea sa transmita traficul de-a lungul caii R7-R1-R3-R4-R5, acest lucru este imposibil s se realizeze ntr-o reea IP clasica. n cazul n care se foloseste o reea MPLS, putei configura aceste dou ci ca dou LSP-uri diferite, astfel nct etichete diferite sunt folosite. La router R1, valoarea diferita a etichetei de sosire indic dac pachetul aparine de LSP-ul cu routerul R6 ca si cap sau de LSP cu R7. R1 apoi nainteaza pachetele pe una dintre cele dou LSP-uri, dar nu dupa propriile sale dorinte cum era cazul cu simpla forwardare IP. Exist posibilitatea s se implementeze MPLS TE n orice reea care are LSR-uri. Cu toate acestea, deoarece limea de band i alte atribute de link-uri trebuie s fie cunoscute de ctre LSR-ul de la capul LSP-ului, protocolul de dirijare folosit ntre capetele MPLS TE (LSR-ul cap si LSR-ul coada) trebuie s fie un protocol de dirijare link-state. Cu un astfel de protocol, fiecare router construiete o tabela cu starile link-urilor, care este apoi inundata la toate celelalte rutere n aceeai zon. Aceasta nseamn c, toate routere din domeniu au o topologie cu toate informaiile din zona respectiv. LSR-ul de la cap isi poate da astfel seama cum s stabileasc LSP-ul cu ingineria traficului stabilita. Acest LSP se numete un tunel MPLS TE. Un tunel este 37

unidirecional, pentru c o cale LSP este unidirecionala, i are configuraia tunelului TE numai la capul de la nceputul LSR-ului, i nu la LSR-ul de la coada LSP-ului. Dac ingineria traficului este activat n reea exist posibilitatea de a crea tunele MPLS TE ntre orice pereche de LSR-uri din reea. Ca atare, exist posibilitatea s se orienteze tot traficul din reea, evitand congestionarea n ea, i s se dea tot traficul in functie de caracteristici (de latime de banda, ntrziere, bruiaj i aa mai departe) de care este nevoie. Acest lucru este esenial pentru miezul retelei (CORE backbone) al providerilor de servicii. 3.2 Modul de lucru al ingineriei traficului n MPLS MPLS este o integrare a tehnologiilor Layer 2 i Layer 3. Prin aducerea caracteristici tradiionale Layer 2 disponibile la Layer 3, MPLS permite ingineria de trafic. Astfel, se poate oferi n cadrul unei reele de un singur nivel ce se putea realiza numai prin suprapunerea unei reele Layer 3 peste o reea Layer 2. MPLS TE stabilete automat i menine tunele n ntreaga reea core, utiliznd RSVP. Calea utilizat de ctre un anumit tunel n orice moment este determinat pe baza resurselor necesare ale tunelului i resursele reelei, cum ar fi lime de band. Traseele tunelelor sunt calculate la capul tunelului pe baza resurselor necesare i resurselor disponibile. IGP-ul automat ruteaz acest trafic n aceste tuneluri. De obicei, pachetele ce trec o reea cu MPLS TE n backbone circul pe un singur tunel, care conecteaz punctul de ptrundere la cel de ieire. Ingineria de trafic in MPLS este construit pe urmtoarele mecanisme: Constrngerile legaturilor : ct de mult trafic fiecare link poate sprijini i ct poate utiliza tunelul TE; Distribuia informaiilor de inginerie a traficului de catre protocolul link-state de dirijare cu MPLS TE-activat; Un algoritm (de calcul al caii path calculation [PCALC]) pentru a calcula cea mai bun cale de la LSR-ul cap la LSR-ul coada; Un protocol de semnalizare Protocolul de rezervare a resurselor - Resource Reservation Protocol [RSVP]) pentru a semnalala tunelul TE n ntreaga reea; O modalitate de a transmite trafic pe tunelul TE. Primul nume folosit de Cisco pentru MPLS TE a fost de dirijare cu resurse de rezervare (Routing with Resource Reservation), de asemenea, cunoscut ca RRR sau R3 (a se citi ca R cub). Acest nume ne indic faptul c un motiv important pentru a avea MPLS TE este de a dirija traficul sau a direciona n funcie de resurse sau constrngeri. Aceste resurse sunt limea de band a link-urilor i cteva atribute de link-uri pe care operatorul le specific. Aceste atribute sunt configurate pe link-uri si sunt anunate de protocolul link-state (OSPF sau IS-IS). n loc de a crea un nou protocol pentru a transporta aceast informaie i de a le anuna la toate LSR-urile, OSPF i IS-IS au fost extinse pentru a transporta aceast informaie. Cnd se configureaz un tunel TE pe un LSR, acesta devine capul (headend LSR) din acel tunel TE sau TE-LSP. Apoi se specific destinaia LSR de pe tunelul TE si constrangerile la care trebuie sa se supun. De exemplu, se poate s se specifice cerina de lime de band pe tunel. n interiorul IOS-ului Cisco, o baz de date este construit cu informaii de inginerie a traficului pe care protocolul link-state le trimite. Acesta baz conine toate link-uri care sunt activate pentru MPLS TE i caracteristicile acestora sau atributele. De la aceast baz de date, PCALC sau SPF-ul constrns (constrained SPF- CSPF) calculeaz cel mai scurt traseu, care nc mai ader la toate constrngerile (cel mai important, lime de band), de la capul LSR la coad LSR. PCALC sau CSPF sunt algoritmi ce aleg drumul cel mai scurt (SPF) modificati pentru MPLS TE, astfel nct constrngerile pot fi luate n considerare. Ele au la baz teorema CBR 38

(Constraint Based Routing) care are la baz posibilitatea de a obine ci multiple ntre o surs specific i o destinaie ntr-o reea. LSR-urile intermediare pe LSP trebuie s tie care sunt etichetele de intrare i de ieire pentru acel LSP particular pentru acel tunel TE. LSR-urile intermediare pot afla etichetele doar n cazul n care LSR-ul cap i LSR-urile intermediare semnalizeaz etichetele cu un protocol de semnalizare. n trecut, dou protocoale de semnalizare au fost propuse: RSVP cu extensii pentru TE (RSVP-TE) i LDP bazat pe constrngeri (constraint-based LDP sau CR-LDP). Mult mai folosit este RSVP-TE, n care extensii au fost fcute la RSVP pentru a permite acesteia s poarte etichet MPLS de informare i de alte date specifice TE, cum ar fi traseul explicit sau traseul nregistrat. n esena, RSVP ncearc s semnalizeze tunelul TE de-a lungul caii, de la cap la coad - care este rezultatul calculului bazat pe baza de date a ingineriei de trafic de la LSR-ul cap. RSVP trebuie s-l semnalizeze pentru ca informaiile despre etichete s ajung la fiecare LSR. [30] Distribuia informaiilor de inginerie a traficului Un protocol de dirijare link-state trebuie s inunde constrngerile de pe link-uri n reea pentru toate routere pe care se execut ingineria traficului. n acest capitol, putei vedea ce fel de informaii trebuie s fie transmise i cum OSPF au fost extinse pentru a transporta aceste informaii de TE. 3.2.1 Cerine pentru IGP Protocolul de rutare interior reelei (IGP) trebuie s fie capabil s transmit toate informaiile de topologie (starea de legturi) la toate routere n zon n care ingineria de trafic a fost activat. Numai un protocol link-state poate efectua aceast activitate, pentru c starea tuturor link-urile este inundat de un router la toate routerele dintr-un domeniu. Prin urmare, fiecare ruter n zon tie toate cile alternative, pentru a ajunge la destinaie. Un protocol de rutare distance-vector nu poate efectua aceast activitate. El este conceput doar pentru a transmite cel mai bun traseu (traseu n tabela de rutare), de aceea, informaiile cu privire la cile alternative sunt pierdute. Routerul de la capul tunelui cu TE (headend) trebuie s dispun de toate informaiile de topologie pentru a vedea toate cile posibile, dar acesta trebuie s aib, de asemenea, toate informaiile legate de constrngerile de pe link-urile pe care le are la dispoziie. Protocolul de rutare de tip link-state trebuie s fie extins pentru a obine aceast resursa de informaii suplimentare. Resursele de inginerie a traficului de pe un link sunt: metrica TE latimea de banda maxim limea de band maxim rezervabil latimea de band nerezervabil grup administrativ Metrica TE este un parametru care se poate utiliza pentru a construi o topologie cu TE diferit de topologia IP. Ca atare, metrica TE de pe un link poate fi diferit de costul OSPF sau metrica IS-IS de pe link. Limea de band maxim este limea de band total de pe un link. Limea de band maxim rezervabila este, evident, limea de band la dispoziia TE pe link; cea nerezervabila este data de limea total minus limea deja rezervat.

39

Grupul administrativ este un cmp de 32 de bii. Operatorul de reea pot stabili individual, fiecare bit din acest domeniu pe 32 de bii i poate avea un sens ales de el. De exemplu, un bit ar putea s nsemne c link-ul este o legtur cu o vitez de 48kbps, sau un link care este intercontinental, sau un link care are o ntrziere mai mic de 100 ms. Link-ul poate avea mai multe resurse asociate cu aceast, cu un maxim de 32. Aceste resurse sunt inundate n ntreag zon, atunci cnd acestea se schimb n valoare sau la intervale regulate. 3.3 Extensii OSPF pentru Ingineria Traficului RFC 2370 descrie o extensie a protocolului OSPF prin care cele trei noi anunuri link-stat (LSA-uri) sunt definite i sunt numite LSA-uri opace. Aceste trei noi LSA-uri dau OPSF-ului un mecanism generalizat de a extinde OSPF. Acestea pot duce informaii pentru a fi utilizate de ctre OSPF sau direct de ctre orice aplicaie. Aceste LSA-uri sunt exact ceea ce MPLS TE are nevoie pentru a pune n OSPF. OSPF poate apoi inunda aceast informaie n ntreag reea. Trei tipuri de LSA-uri exist, difer doar n domeniul de aplicare a inundaiilor. LSA de tipul 9 aplicat numai pe link-local; de tip 10 are un domeniu de aplicare a inundaiilor care este de zon larg, i opac 11 are un tip de inundaii, domeniul de aplicare, care este autonom, la nivel de sistem. Asta nseamn c, LSA-urile de tip 9 sunt trimise numai pe link, dar niciodat transmise dincolo; cele de tip 10 sunt oprite de ctre routerul de la zona de frontier (gateway), i de tip 11 sunt inundate n intreg domeniul OSPF, la fel ca i cele de tip 5. Un bit nou, bitul O, a fost definit pentru a fi folosit n cmpul opiuni al OSPF. Acest bit poate indica dac este un router capabil de trimitere i primire de LSA-uri opace. Cmpul opiuni este prezent n mesajele OSPF Hello, pachetele ce descriu baza de date (database description), precum i n toate LSA-urile.

Figura 3.3 Campul optiuni OSPF Figura 3.4 arat formatul opac al LSA-ului. LSA-urile de tip 9, 10, sau 11, unde campul cu valoare normal a ID-ul a fost nlocuit cu Opaque Type and Opaque ID.

Figura 3.4 Formatul LSA opac

40

LSA-ul TE de tip 10 opac poart una sau mai multe Valori ale Tipului de Lungime ( Type Length Value - TLV). Un TLV permite OSPF sa transporte date ntr-un mod flexibil. Figura de mai jos arat formatul TLV.

Figura 3.5 Formatul TLV Acest TLV transport date specifice MPLS TE. O adresa TLV a routerului i un link TLV exist. Adresa TLV tine ID-ul routerului in TE. Link-ul TLV exercit un set de sub-TLV-uri care descriu un singur link pentru MPLS TE. Tabelul urmator ofer o imagine general de pe link-ul de sub-TLVs. Putei vedea c resursele de pe link-dup cum s-a menionat n seciunea anterioar, sunt prezente. Nume Link type (tipul legaturii) ID-ul legaturii Adresa IP de pe interfaa local Adresa IP de pe staia distant Metrica TE Banda maxim Banda maxim ce poate fi rezervat Banda nerezervat Grupul Administrativ Valoare in octeti 1 4 4 4 4 4 4 32 (4 octei pentru fiecare nivel de prioritate de la 0 la 7) 4

3.3.1 Operarea i Dirijarea pe Baz de Constrangeri n MPLS TE (Constraint-Based Routing CBR) Cea mai important cerina a TE este aceea a caracteristicilor, precum i a disponibilitii resurselor, pe link-urile din reea (n plus fa de limea de band care ar putea fi folosita pentru calculul costului) se propag n ntreaga reea pentru a permite alegerea pe ct de eficient posibil a cailor LSP cu TE. n protocoalele de dirijare link-state calea preferata, nc predominant, ia n considerare limea de band pe link-ul dintre dou routere pentru a calcula costul sau metrica asociat cu aceast cale. Activarea utilizrii eficiente a protocoalelor link-state de a culege n mod eficient informaii referitoare la disponibilitatea resurselor n mesajele de rutare este efectuat de ctre extensiile suplimentare la funcionarea real a protocolului de rutare. Mecanica de funcionare implic inundaii la actualizrile n reea, la schimbarea statusului unui link, schimbarea metricii sau a bandei disponibile. Resursele atribute sunt inundate de routere n reea pentru a le face disponibile de routerul headend n tunelul TE n timpul calcului LSP-ului (tunele dinamice). Mesajele link-state transporta informaii cum ar fi listele cu routerele de vecini, reeaua de resurse, precum i alte informaii relevante legate de disponibilitatea resurselor reale ce ar putea fi necesare mai trziu pentru a efectua un calcul SPF pe baz de constrngeri. OSPF i IS-IS au fost furnizate cu extensii pentru a permite utilizarea lor ntr-un mediu MPLS TE pentru a propaga informaii legate de disponibilitatea resurselor. 41

3.4 Calcularea si stabilirea caii 3.4.1 Cum functioneaza SPF n mod normal n procesul de calcul SPF, un router se plaseaz pe sine, la cap de arbore cu cele mai scurte ci calculate pentru fiecare dintre destinaii, doar inndu-se cont de traseul cu cea mai mic metric sau cost pn la locul de destinaie. Intr-un protocol de rutare link-state, fiecare router stie despre toate celelalte routere din retea si link-urile care conecteaza aceste routere. In OSPF aceasta informatie este codata in LSA(LinkState Advertisments); in IS-IS aceasta informatie este LSP(Link-State Packets),pentru a nu se confunda cu Label-Switched Path le vom numi LSA. Imediat dupa ce routerul cunoaste toate celelalte routere si link-uri, ruleaza algoritmul Dijkstra Shortest Path First pentru a determina cea mai scurta cale dintre routerul care calculeaza si toate celelalte reoutere din retea. Deoarece toate routerele ruleaza acelasi calcul pe aceleasi date, toate routerele au aceasi imagine despre retea, si pachetele sunt consecvent rutate la fiecare hop.

Figura 3.6 O topologie simpla pentru a demonstra algoritmul SPF Acest exemplu(Figura 3.6) ne arata ce se intampla cand routerul A ruleaza SPF si isi genereaza tabela sa de rutare. Dupa ce fiecare router a anuntat(flooded) cu informatiile sale reteaua, toate routerele stiu despre toate celelalte routere si link-urile dintre ele. Baza de date link-state pe fiecare router arata ca in Tabelul 3.1.

Tabelul 3.1 Potrivirea claselor de planificare

42

In calculul SPF, fiecare router mentine doua liste: - O lista a nodurilor care sunt cunoscute a fi pe calea cea mai scurta spre destinatie. Aceasta lista este numita lista PATH. - O lista cu urmatoarele hopuri(next hops) care ar putea sau nu ar putea sa fie pe calea cea mai scurta spre destinatie. Aceasta lista se nuleste lista TENT sau TENTative. Fiecare lista este o tabela de tripleti {router,distanta,next-hop} din perspectiva routerului care calculeaza. Algoritmul care calculeaza calea cea mai scurta pentru fiecare nod este simpla. Fiecare router urmeaza urmatorul algoritm: 1. Pune self in lista PATH cu distanta 0 si urmatorul hop(next-hop) el(self=root node) Tabelul 3.2

Tabelul 3.2 Lista PATH si TENTE pentru Routerul A 2. Ia nodul abia pus in lista PATH, si il numeste nod PATH. Se uita in lista vecinilor nodului respectiv. Adauga fiecare vecin din aceasta lista in lista TENTE cu nodul urmator (nexthop) nodul PATH, in afara de cazul in care vecinul este deja in lista TENTE sau lista PATH cu un cost mai mic. Daca nodul abia adaugat in lista TENTE deja exista in lista, dar cu un cost mai mare, inlocuieste nodul cu costul mai mare cu nodul curent. In exemplul nostru, {B,5,B} si {C,10,C} sunt adaugate in lista TENTE ca in Tabelul 3.3.

Tabelul 3.3 Listele PATH si TENTE pentru Routerul A dupa pasul 2 3. Gaseste vecinul in lista TENTE ce are costul cel mai mic, adauga acel vecin in lista PATH si repeta pasul 2). Daca lista TENT este goala se opresta. {B,5,B} este mutat in lista PATH, deoarece aceasta este calea cea mai scurta catre B. Deoarece {C,10,C} este singurul vecin ramas,si costul de a ajunge la C este mai mare decat costul de a ajunge la B, este imposibil sa avem o alta cale catre B cu un cost mai mic decat cel de pana acum. Tabelul 3.4 reflecta listele PATH si TENTE la acest pas.

Tabelul 3.4 Listele PATH si TENTE pentru Router A dupa pasul 3 4. Se repeta pasul 2. Vecinii routerului B sunt examinati. Routerul B are un link catre C cu un cost de 3 si un link catre D cu un cost de 8. Costul total de la A la C via B este 8 si urmatorul nod(next-hop) a lui B este adaugat in lista TENTE; costul de la A la D via B este 13 si este urmatorul hop(next-hop) a 43

lui B. Deoarece calea catre C cu un cost de 8 prin B este mai mica decat calea catre C cu un cost de 10 prin C, calea catre C cu un cost de 10 este inlaturata din lista TENT. Tabelul 3.5 reflecta listele PATH si TENTE la acest punct.

Tabelul 3.5 Listele PATH si TENTE pentru Routerul A dupa pasul 4 5. Gaseste calea din lista TENTE cu costul cel mai mic, adauga calea in lista PATH si se repeta pasul 2. Daca lista TENTE este goala se opreste. Calea catre C prin {C,8,B} este mutata din lista TENTE in lista PATH ; este aratat in Tabelul 3.6

Tabelul 3.6 Listele PATH si TENTE pentru Routerul A dupa pasul 5 6. I-a calea abia adaugata in lista PATH, si se uita in lista vecinilor nodului. Pentru fiecare vecin din lista, adauga calea catre acel vecin in lista TENTE, doar daca vecinul respectiv deja exista in lista TENTE sau PATH cu un cost mai mic. Daca nodul abia adaugat in lista TENTE deja exista in lista dar cu un cost mai mare, este inlocuita calea cu cost mai mare cu calea curenta. Sub aceasta regula, calea de la D catre B (B->C->D) cu un cost de 12 inlocuieste calea catre D prin B->D cu un cost de 13, cum se vede in Tabelul 3.7

Tabelul 3.7 Listele PATH si TENTE pentru Routerul A dupa pasul 6 7. Gaseste vecinul in lista TENTE cu costul cel mai mic, adauga acest vecin in lista PATH si repeta pasul 2. Daca lista TENTE este goala se opreste. Calea catre D este mutata in lista D, asa cum se vede in Tabelul 3.8.

44

Tabelul 3.8 Listele PATH si TENTE pentru Routerul A dupa pasul 7: Lista TENTE este goala 8. Gaseste vecinul in lista TENTE cu costul cel mai mic, adauga acest vecin in lista PATH si repeta pasul 2. Daca lista TENTE este goala se opreste. Lista TENTE este goala deoarece D nu mai are vecini care sa nu fie deja in lista PATH,algoritmul se opreste. In acest moment lista PATH devine tabela de rutare a routerelui A, care arata ca in Tabelul 3.9.

Tabelul 3.9 Tabel de rutare a Routerului A

Figura 3.7 Reteaua vazuta de Routerul A dupa rularea algoritmului SPF In aceasta topologie se observa doua lucruri: -traficul care trece link-ul B->D este traficul provenit de la routerul A -link-ul de la routerul A la routerul C nu este folosit deloc, din cauza costului prea mare(10). 3.4.2 Cum functioneaza CSPF Procesul care genereaza calea pe care o ia un tunel TE nu este foarte mult diferit de SPF. Sunt doua diferente majore intre SPF, realizat de protocoalele de rutare si CSPF, realizat de MPLS TE.

45

Procesul de determinare a caii nu este proiectat sa gaseasca cea mai buna ruta catre toate routerele numai catre capatul tunelului. Acest lucru face algoritmul SPF oarecum diferit. De asemenea acum este mai mult de o metrica pentru fiecare nod fata de singurul cost per link intre vecini: -largimea de banda -atributele link-ului -distanta administrativa Tripletului folosit de SPF i se mai adauga largimea de banda, atributele link-ului si distanta administrativa.Un alt detaliu pentru CSPF este : nu se face impartirea sarcinii (load sharing) deoarece se cauta o singura cale catre nodul capat. Dupa cum am precizat, cu CSPF, vom folosi mai mult dect costul pe link pentru a identifica cile care pot fi utilizate pentru drumuri LSP cu ingineria traficului. Decizia este efectuat la routerul headend dup eliminarea tuturor link-urile care nu respect un anumit criteriu, cum ar fi cerinele de lime de band n plus fa de costul pe link. Rezultatul calculului CSPF la routerul headend este un set ordonat de adrese IP cu mapari la urmtorul hop care formeaz LSP. Prin urmare, mai multe LSP-uri cu TE ar putea fi folosite de CSPF pentru a identific link-uri n reea care s corespund criteriilor. n plus, utilizatorul poate configura static un tunel TE sau LSP pe routerul headend specificndu-se calea i, prin urmare, se poate utiliza static LSP-ul definit ca LSP de rezerv n caz de inactivitate a link-ului principal. Rezultatul calcului CSPF este apoi trecut la calculul RSVP, pentru a ncepe procesul de solicitare i rezervare, dup cum se va vorbi n capitolul urmtor. RSVP, astfel, este utilizat mpreun cu rezultatele calculate de ctre CSPF sau de lista de hopuri configurate de ctre utilizator pentru LSP. De notat c LSP-ul format este unidirecional. n caz de egalitate a constrangerilor, calea cu cea mai mare lime de band are prioritate, urmat de cel mai mic numr de hopuri. Dac tot este egal, CSPF alege o cale, la ntmplare. Prin urmare, succesiunea de pai n crearea unui tunel MPLS TE n reea este, dup cum urmeaz: Pasul 1. Calculul CSPF se face la routerul headend pe baza constrngerilor definite n tunel i cerinelor. Acest calcul este efectuat de ctre IGP n continuare, fie OSPF sau IS-IS. Pasul 2. Dup ce calea LSP este calculat pe baza procesului CSPF, rezultatul din procesul CSPF, care este un set de adrese IP mapate pentru fiecare adrese de la hop-uri urmatoare, este trecut la RSVP. Pasul 3. RSVP acum efectueaz cereri cu rezervri de resurse i confirmare pe LSP, cum sunt definite de procesul CSPF, pentru a determina dac LSP ndeplinete cerinele specifice resurselor solicitate in definirea tunelului. Pasul 4. Dup ce procesul de RSVP primete un mesaj de rezervare, acesta semnaleaza c LSPul este acum stabilit. Pasul 5. La acest punct, un tunel TE este disponibil pentru a fi folosit de IGP. n mod implicit, informatiile legate de tunel nu se adaug n tabela de rutare; cu toate acestea, routerul poate fi configurat astfel nct interfaa tunel sa fie adaugata n tabelul de rutare.

46

Figura 3.8 O topologie simpla ce demonstreaza algoritmul CSPF In aceasta topologie, Figura 3.8, s-au luat numai patru proprietati ale link-ului: {link,cost,next hop,si latimea de banda disponibila}. Routerul A vrea sa construiasta un tunel TE catre routerul D cu o latime de banda de 60 Mbps. Fiecare link isi listeaza metrica si latimea de banda disponibila. Daca nu am lua in calcul latimea de banda , calea cea mai buna de la A la D este A->B->C->D cu un cost total de 12. Dar cum calea A->B->C->D nu are 60 Mbps disponibili, CSPF trebuie sa calculeze calea cea mai scurta care are disponibili 60 Mbps. Algoritmul CSPF urmeaza urmatorii pasi: 1) Pune self in lista PATH cu o distanta de 0 si urmatorul hop(next-hop) el insusi. Seteaza latimea de banda la N/A. Rezultatul este aratat in Tabelul 3.10.

Tabelul 3.10 Listele PATH si TENTE dupa pasul 1 2) Pune vecinul routerului A in lista TENTE. Rezultatul este aratat in Tabelul 3.11.

Tabelul 3.11 Listele PATH si TENTE pentru Routerul A dupa pasul 2 3) Il muta pe B din lista TENTE in lista PATH, si pune vecinii lui B in lista TENTE. Rezultatul este aratat in Tabelul 3.12.

Tabelul 3.12 Listele PATH si TENTE pentru Routerul A dupa pasul 3 {C,8,B,50} nu este adaugat in lista TENTE deoarece nu indeplineste cerinta de a avea minimul de latime de banda. 4) Pune vecinii lui B in lista TENTE si il ia pe C din lista TENTE si il pune in lista PATH. 47

Rezultatul este aratat in Tabelul 3.13.

Tabelul 3.13 Listele PATH si TENTE pentru Routerul A dupa pasul 4 {D,14,C,60} nu este pus in lista TENTE deoarece costul de a ajunge de la D la B este mai mic decat costul de a ajunge prin C. 5) Il ia pe D din lista TENTE. In acest punct, cea mai buna posibila cale catre D este in lista PATH si algoritmul se incheie.Rezultatul este aratat in Tabelul 3.14.

Tabelul 3.14 Listele PATH si TENTE pentru routerul A dupa pasul 5 CSPF trebuie sa tina urma tuturor nodurilor din cale, nu numai a urmatorului hop. In cazul in care nodul care trebuie pus in lista TENTE exista deja si are acelasi cost este nevoie sa se faca o diferentiere intre aceste cai. Criterii de diferentiere a cailor in ordine(tiebreakers): 1 Se ia calea cu cea mai mare largime de banda minim disponibila. 2 Daca mai exista un obstacol, se ia calea cu numarul cel mai mic de hopuri(numarul de routere din care este formata calea) 3 Daca mai exista un obstacol, se ia o cale random(aleator) Aceste criterii sunt aplicate cand un nod este adaugat in lista TENTE. In orice moment, un nod dat ar trebui sa fie adaugat numai o data in lista TENTE. Aceasta este diferenta fata de un IGP SPF, unde se poate sa ai mai multe rute catre un nod dat si se poate face impartirea sarcinii (load share) intre ele.

48

Figura 3.9 O retea simpla in care sunt necesare criterii de diferentiere pentru CSPF In aceasta topologie sunt cinci cai posibile de la A la Z,de la P1 la P5.In Tabelul 3.15 sunt listate atributele cailor.

Tabelul 3.15 Atributele celor cinci cai posibile de la RtrA la Rtr Z Procesul deciziilor prin care RtrA trece pentru a alege o cale din acestea cinci: -P1 nu este folosita deoarece costul caii este mai mare decat celelalte cai -P2 nu este folosit deoarece largimea sa de banda minima este 80 Mbps, valoare care este mai mica decat minimul largimii de banda pentru alte cai -P3 nu este folosit deoarece are 5 hopuri(noduri),celelalte cai avand 4 hopuri(noduri) -RtrA alege ori P4 ori P5 din capul listei TENTE. Alte lucruri care influenteaza CSPF: -Largimea de banda(bandwidth) : o cale nu este considerata acceptabila de a fi folosita pentru un tunel MPLS TE daca nu are largimea de banda ceruta. -Atributele link-ului(link attributes): daca bitii potrivit tunelului nu se potrivesc cu atributele configurate pe acel link, link-ul nu este considerat eligibil de a fi folosit de un tunel MPLS TE 49

-Distanta administrativa(administrative weight): este difuzata de IGP cand sunt anuntate(flooded) informatii TE. Initial, numai distanta administrativa este folosita pentru a calcula calea tunelului. 3.5 Protocolul de rezervare a resurselor -Resource Reservation Protocol (RSVP) Dupa ce o cale este calculata cu CSPF, aceasta cale trebuie sa fie semnalata de-a lungul retelei din doua motive: -Pentru a stabili un lant hop-by-hop de etichete care reprezinta calea -Sa consume orice resursa(largime de banda) consumabila de-a lungul caii respective Aceasta semnalare este indeplinita folosind RSVP, impreuna cu extensiile RSVP pentru MPLS TE. 3.5.1 Bazele RSVP(RSVP Basics) RSVP este un mecanism de semnalizare folosit pentru a rezerva resursele peste tot in retea.Are tipul sau de protocol (46), desi este posibil sa incapsulezi RSVP in UDP. MPLS TE nu incapsuleaza niciodata RSVP in UDP. RSVP nu este un protocol de rutare. Orice decizie de rutare este luata de IGP(inclusiv extensiile TE) si CSPF. Functia RSVP-ului este de a semnala si mentine rezervarea resurselor din retea. In MPLS TE RSVP rezerva latimea de banda la nivelul planului de control (controlplane). RSVP are trei functii de baza: -setarea caii si mentinerea ei - ruperea caii (path teardown) -semnalarea erorii RSVP este un protocol soft-state. Asta inseamna ca are nevoie sa improspateze periodic rezervarile din retea prin resemnalizarea lor. Acest lucru este diferit fata de un protocol hardstate a carui semnalari sunt cerute o data dupa care se presupune ca acea cerere este up pana este explicit pusa down. [RFC3210] In Tabelul 3.16 sunt listate noua tipuri de mesaje diferite ce definesc RSVP. Tipul mesajului Path Resv(scurtatura pentru Reservation) PathTear ResvTear PathErr ResvErr Descrierea Folosit sa seteze si sa mentina rezervarile Trimis ca raspuns la mesajele Path pentru a seta si a mentine rezervarile Analog cu mesajele Path, dar sunt folosite sa inlature rezervarile din retea Analog cu mesajele Resv, dar sunt folosite sa inlature rezervarile din retea Trimis de primitorul mesajului Path care detecteaza o eroare in acel mesaj Trimis de primitorul mesajului Resv care 50

ResvConf ResvTearConf

Hello

detecteaza o eroare in acel mesaj Optional trimite inapoi la expeditorul mesajului Resv, pentru a confirma ca rezervarea data s-a realizat Este un mesaj prioritar Cisco analogul mesajului ResvConf.Folosit sa confirme ca o anumita rezervare a fost inlaturata din retea O extensie definita in RFC 3290 care permite link-urilor locale keepalives intre doi vecini RSVP direct conectati Tabelul 3.16 Tipul mesajelor RSVP

3.5.2 Semnalizarea RSVP-TE RSVP rezerv o lime de band de-a lungul unui drum de la o anumit surs la destinaie. Mesajele RSVP sunt trimise de ctre routerul cap (headend) ntr-o reea pentru a identifica disponibilitatea resurselor pe drum. Routerul cap sau headend este ntotdeauna sursa tunelului MPLS TE i tailend router sau routerul coad, este un router care funcioneaz n calitate de final pentru tunelul cu TE. Cele patru mesaje principale folosite la punerea n aplicare a RSVP pentru TE sunt mesajul de cale RSVP (RSVP PATH) , mesajul de rezervare (RSVP RESERVATION), mesaje de eroare i mesaje de ncheiere. RSVP PATH este generat de headend i este transmis prin intermediul reelei pe cale de-a lungul unui viitor LSP cu TE. La fiecare hop, mesajul verific disponibilitatea resurselor solicitate i stocheaz aceste informaii. O alta functie a mesajului RSVP PATH este de a cere o etichet MPLS cu TE pe cale, cerere generata de la headend i care se propag n aval (pe downstream). Mesajele RSVP PATH sunt rutate prin intermediul reelei cu Explicit Route Object(ERO) ce specifica detaliile despre calea pe care mesajul RSVP PATH trebuie s o urmeze pentru a semnaliza tunelul cu TE. Seria de hopuri sau calea este rezultatul calcului facut pe routerul de la cap. La fiecare hop, acest mesaj de cale rezerv temporar limea de band i face o cerere de etichet. n cele din urm, mesajul de cale ajunge la coada, care returneaz un mesaj RESV ctre cap. Acest mesaj RESV apoi returneaz o etichet pe care planul de date MPLS o poate utiliza pentru a transmite pachete pe acest tunel MPLS cu TE de-a lungul LSP. De asemenea, mesajul RESV spune LSR-urilor intermediare sa rezerve resursele pe link-urile care se utilizeaza pe acest tunel cu TE. RSVP RESERVATION este creat de routerul tailend (coada) n domeniul MPLS TE i utilizat pentru a confirma rezervarea, mesajul de cale (PATH) care a fost trimis mai devreme. Practic este un mesaj de rspuns la mesajul PATH. Mesajul RSVP de REZERVARE ndeplinete funcia de atribuire a etichetei pentru un anumit tunel TE. Daca mesajul de cale este transmis in aval, mesajele de rezervare sunt generate de tailend sau egress Edge LSR apoi propagate n amonte. Acest proces se repet la fiecare hop in amonte pe un tunel TE i mesajele sunt propagate n amonte pn la headend. [RFC3210]

51

Figura 3.10 Mesajele RSVP Path si Reservation Mesajele de erore RSVP: PATHERR sau RESVERR - in caz de lipsa a resurselor solicitate, routerul cu RSVP genereaz mesaje de eroare i le trimite la un router de la care cererea a fost primit.

Figura 3.11 Mesajele de eroare RSVP Mesaje de incheiere (tear down) - RSVP creeaz dou tipuri de mesaje de incheiere, i anume, mesaj de incheiere de cale i mesaj de incheiere de rezervare. Odata ce mesajele de incheiere au fost trimise, se permite refolosirea resurselor de pe router pentru alte cereri. LSR-ul care nu a reuit rezervare de resurse pe link va genera o eroare de RSVP PATH i un mesaj de incheiere de rezervare la headend. 3.5.3 Operaiunile RSVP n MPLS TE Aa cum am menionat mai devreme, rezultatul unei CSPF sau calcul CBR pe routerul headend este o list ordonata de adrese IP care identific urmtorii pasi de-a lungul drumului ntr-un tunel cu TE sau LSP. Aceast list de routere este calculat i este cunoscut doar de routerul headend care este sursa de tunel. Alte routere n domeniu nu efectuaz un calcul CBR. Routerul headend ofer informaii despre routere din calea tunelului cu TE prin semnalizare RSVP pentru a solicita i a confirma disponibilitatea resurselor pentru tunel. RSVP cu extensii pentru TE rezerv resurse corespunztoare cu privire la fiecare LSR n calea definita de headend i atribuie etichete de Mapare a tunelului cu TE. Extensiile RSVP pentru a permite semnalizarea ntr-un mediu n care se pune in aplicare MPLS TE sunt definite si prezentate in tabelul de mai jos: Obiectul LABEL_REQUEST (cerere de eticheta) Mesaj de tipul PATH Functia Folosit pentru a cere o mapare de etichete la tunelul cu TE sau LSP; generat de routerul 52

Obiectul

Mesaj de tipul

Functia headend intr-un mesaj de tip cale.

LABEL (eticheata) EXPLICIT_ROUTE (cale explicita) RECORD_ROUTE (cale invatata)

RESERVATION

Folosit pentru a aloca mapri de etichete la tunelul cu TE sau LSP; generat de routerul tailend ntr-un mesaj de rezervare. Purtat ntr-un mesaj de cale si folosit pentru a cere sau a confirma o cale/ruta specific pentru un tunel. Este adaugat mesajelor de cale sau de rezervare pentru a notifica nodul de origine despre ruta/calea actual pe care tunelul cu TE o trece. Folosit pentru a defini atribute specifice sesiunii de tunel, cum ar fi cerinele de band necesare. Definete sursa si captul tunelului. De obicei identificate prin adrese IP ale adreselor loopback corespunztoare interfeelor de pe headend i tailend .

PATH

PATH, RESERVATION

SESSION_ATTRIBUTE PATH (atributele sesiunii) SESSION (sesiunea) PATH

Tabelul 3.17 Paii urmai de mesajele de tip cale (PATH) i de rezervare (RESV) sunt urmatorii: Pasul 1. Valorile LABEL_REQUEST, EXPLICIT_ROUTE, RECORD_ROUTE SESSION i SESSION_ATTRIBUTE sunt aplicate de routerul headend ntr-un mesaj de cale i acest mesaj este trimis la urmtorul hop de pe calea tunelului sau LSP. Pasul 2. Cnd urmatorul hop primete acest mesaj PATH, routerul verific obiectul EXPLICIT_ROUTE, pentru a vedea dac urmtorul hop este direct legat n reea. Acest lucru este verificat n bitul L al mesajului de cale RSVP . n cazul n care bitul L este setat, routerul nu este direct conectat la urmtorul hop n calea tunelui LSP. Prin urmare, routerul va efectua un calcul de SPF constrns (CSPF) pentru a stabili urmtorul/urmatoarele hop/hopuri n tunel. n cazul n care bitul L este unset, routerul lcoal tie c aceasta este direct legat de urmtorul hop n calea LSP al tunelului. Se indeparteaza apoi toate intrrile n EXPLICIT_ROUTE de mapare pentru routerul local i nainteaza mesajul PATH la urmtorul hop, cum sunt definit n obiectul EXPLICIT_ROUTE. n plus, acest router va aduga interfaa de ieire spre urmtorul hop n cmpul RECORD_ROUTE. Pasul 3. Procesul se repet la urmtoarele hopuri. Pasul 4. Cand mesajul RSVP PATH este primit de routerul tailend, el determin crearea de un mesaj de rezervare. Conceptul cheie de remarcat este c etichetarea ncepe de la routerul tailend (de la coad). Prin urmare, atunci cnd acesta genereaz un mesaj de rezervare, routerul atribuie o etichet la tunelul LSP. Mesajul de rezervare are acum obiectul RECORD_ROUTE care s indice ce interfa de ieire de pe router tailend duce spre headend router. Prin urmare, obiectul RECORD_ROUTE este reinitializat n mesajul RESERVATION. 53

Pasul 5. Obiectul LABEL(etichet) cu maprile pentru LSP este, de asemenea, generat. Pasul 6. Acest proces se repet din nou pe calea invers. Pasul 7. Cnd routerul cap primete mesajul de rezervare, acest va menine din RECORD_ROUTE noua rut cu cerinele date n SESIUNE, cu ingineria traficului setat, nvata prin RSVP-TE fa de calea LSP normal. 3.5.4 Setarea caii si mentinerea ei 3.5.4.1 Setarea caii Dupa ce inceputul tunelului(tunnel headent) termina calculul CSPF pentru un tunel particular, are nevoie sa semnaleze aceasta cerere in retea. Capatul tunelului (headend) face acest lucru prin trimiterea mesajelor Path urmatorului nod impreuna cu calculul caii spre destinatie. Routerul care trimite mesajul Path se numeste router amonte si routerul care primeste mesajul se numeste router aval. Routerul amonte se mai numeste uneori hopul anterior(phop). Dupa ce routerul din aval primeste mesajul Path , face urmatoarele lucruri: verifica formatul mesajului pentru a se asigura ca totul este in ordine, dupa care verifica cantitatea de largime de banda ceruta de mesajul Path primit. Acest proces se numeste controlul admisiei. Daca controlul admisiei este reusit si mesajului Path i se permite sa rezerve largimea de banda pe care o doreste, routerul din aval creaza un nou mesaj Path si il trimite la urmatorul hop din Explicit Route Object(ERO). Mesajele Path urmeaza acest lant pana cand ajung la ultimul nod din ERO- coada tunelului MPLS TE. Capatul tunelului realizeaza controlul admisiei pentru mesajul Path, ca orice alt router din aval. Cand capatul tunelului realizeaza ca este destinatia mesajului Path, va raspunde cu un mesaj Resv. Mesajul Resv nu contine numai confirmarea(acknowledgment) ca rezervarea s-a realizat pe tot drumul spre capatul tunelului, ci contine si eticheta care intra(incoming) pe care routerul din amonte ar trebui sa o foloseasca in trimiterea pachetelor pe TE LSP catre capat. Figura 3.12 arata schimbul de mesaje RSVP: path si resv in timpul stabilirii LSP.

Figura 3.12 Mesajul RSVP: PATH si RESV in timpul setarii caii LSP Presupunand ca R1 a realizat deja CSPF si deja stie ce largime de banda vrea sa rezerve dea lungul caii R1->R2->R3->R5->R6->R7:

54

1. R1 trimite mesajul Path la R2. R2 primeste mesajul Path, verifica daca mesajul are sintaxa corecta, verifica cu TE Link Manager pentru a se asigura ca largimea de banda ceruta de R1 chiar este disponibila. Daca ceva este gresit R2 trimite un mesaj de eroare inapoi la R1. Presupunand ca totul este in ordine se trece la pasul 2. 2. R2 trimite un mesaj Path la R3. R3 face aceleasi verificari pe care le-a facut si R2. 3. R3 trimite un mesaj Path la R5; aceleasi verificari 4. R5 trimite un mesaj Path la R6; aceleasi verificari 5. R6 trimite un mesaj Path la R7; aceleasi verificari 6. R7, fiind capatul tunelului, trimite un mesaj Resv lui R6. Acest mesaj Resv indica eticheta pe care R7 doreste sa o vada in pachetul pe acest tunel; deoarece R7 este capatul, trimite si implicitnull 7. R6 trimite un mesaj Resv lui R5 si indica ca vrea sa vada ca eticheta de intrare 42, pentru acest tunel. Acest lucru inseamna ca atunci cand R6 primeste eticheta 42, scoate aceasta eticheta(din cauza implicit-null) si trimite pachetul catre R7. 8. R5 trimite un mesaj Resv catre R3, semnaland eticheta 10921. Cand R5 primeste un pachet cu eticheta 10921, schimba aceasta eticheta cu eticheta 42 si trimite pachetul la R6 9. R3 trimite un mesaj Resv lui R2, semnaland eticheta 21 10. R2 trimite un mesaj Resv lui R1, semnaland eticheta 18. In acest moment tunelul catre R7 este up, si se cunosc care sunt etichetele de iesire. 3.5.4.2 Mentinerea caii La fiecare 30 secunde, capatul tunelului (headend) trimite un mesaj Path per-tunel la vecinii din aval. Daca un router trimite un mesaj Path si nu primeste la timp mesajul resv, considera ca rezervarea nu mai este si trimite la routerul din amonte un mesaj ce indica lipsa rezervarii. Mesajele Path si Resv sunt ambele independente si asincrone de la un vecin la altul. Ruperea caii (path teardown) Daca un nod (in general capatul tunelului) decide ca o rezervare nu mai este necesara in retea, trimite un masaj PathTear pe aceasi cale urmata de mesajele Path si se primesc mesajele ResvTear pe aceasi cale ca mesajele Resv. Mesajele PathTear sunt in general vazute cand capatul tunelului (headend) decide ca nu mai doreste o rezervare in retea(ex:cand un tunel este down). Mesajele ResvTear sunt trimise in raspuns la mesajele PathTear pentru a semnala ca capatul tunelului a indepartat rezervarile din retea. PathTear si ResvTear pot fi deasemenea trimise in raspuns la o eroare in retea. Semnalarea erorii: Ocazional pot exista erori in semnalarea RSVP. Aceste erori sunt semnalate prin mesajele PathErr sau ResvErr. O eroare detectata in mesajul Path i se raspunde cu mesajul PathErr, si o eroare detectata in mesajul Resv i se raspunde cu mesajul ResvErr. Mesajele de eroare sunt transmise catre routerul din amonte , el fiind sursa erorii; Patherr este trimis catre nodul din amonte de nodul din aval si ResvErr este trimis catre nodul din aval de nodul din amonte.

55

3.5.5 Pachetele RSVP Orice mesaj RSVP este compus dintr-un header comun, urmat de unul sau mai multe obiecte. Numarul de obiecte din mesaj depinde de ceea ce vrea mesajul sa indeplineasca. RSVP Common Header

Figura 3.13 Formatul antetului RSVP Campul Version Flags Message Type Descrierea Versiunea protocolului RSVP. Nu este definit deocamdata nici un flag. 1-mesajul Path 2-mesajul Resv 3-mesajul PathErr 4-mesajul ResvErr 5-mesajulPathTear 6-mesajul ResvTear 7-mesajul ResvConf 10-mesajul ResvTearConf 20-mesajul Hello RSVP Checksum Suma de verificarea a mesajului RSVP. Send TTL Valoarea TTL din pachetul IP a mesajului trimis. Reserved Nu este folosit. RSVP Lenght Lungimea mesajului RSVP in bytes, inclusiv header-ul comun.RSVP Lenght este intotdeauna cel putin 8. Tabelul 3.18 explica campurile din header-ul obisnuit RSVP. Formatul claselor de obiecte RSVP(RSVP Object Class Formats) Toate obiectele RSVP au acelasi format de baza, cum este ilustrat in Figura 3.14

Figura 3.14 Formatul obiectului RSVP 56

In Tabelul 3.19 sunt descrise campurile din formatul obiectului de baza RSVP. Camp Object Lenght Class-Num C-Type Object Contents Descriere Lungimea obiectului RSVP, inclusiv obiectul header.Trebuie sa fie multiplu de 4. Clasa obiectului. The objects class type.C-Type este un numar unic din clasa. Obiectul insusi. Tabelul 3.19 Formatul obiectului RSVP

Sunt definite 23 de clase obiect(object classes) diferite. Nu toate sunt folosite in semnalizarile RSVP pentru MPLS TE; acestea sunt listate in Table 3.20.

Tabelul 3.20 Clasele obiectului RSVP Un mesaj RSVP contine unul sau mai multe obiecte. Nu toate mesajele contin toate obiectele. Obiectele pe care le contine un mesaj depind de caracterizarea mesajului. 57

In Tabelul 3.21 sunt listate clasele si C-Type folosite in implementarea Cisco a RSVP-TE.

Tabelul 3.21 Obiectul RSVP C-Types 3.5.6 Operatiile RSVP 3.5.6.1 Ce este Make-Before-Break? Make-before-break este un mecanism RSVP-TE care permite schimbarea unor caracteristici a tunelului TE(numele, largimea de banda si calea pe care o ia un tunel) fara rezervarea de doua ori a largimii de banda si efectiv fara pierderi de date. RSVP are o facilitate numita Shared Explicit(SE) ce este un stil de a rezerva ce permite un LSP existent sa imparta largimea de banda cu el insusi astel incat sa nu se mai intample rezervarea de doua ori. Rezervarea SE are doua componente: -cererea stilului de rezervare SE de la retea -capabilitatea de a identifica ca o anumita rezervare este aceeasi cu o rezervare deja existenta, astel incat largimea de banda sa fie impartita. Stilul rezervat SE este cerut de capatul tunelului (headend) folosind un flag din obiectul SESSION_ATTRIBUTE. Toate rezervarile RSVP sunt unic identificate cu un grup de cinci(five-tuple) : {Sender Address, LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}. Daca doua mesaje Path au aceste grupuri la fel, atunci acestea sunt considerate reprezentantii aceleiasi rezervari. Sender Address este RID-ul capatului tunelului. Endpoint Address este RID-ul cozii tunelului. Extended Tunnel ID este ori numai 0 ori adresa IP a routerului. Tunnel ID este numarul interfetei 58

tunelului din capat. LSP ID este o instanta de numarare; de cate ori un tunel isi schimba cerintele de largime de banda sau calea pe care o ia, LSP ID se incrementeaza.

Figura 3.15 Nevoia de Make-Before-Break Presupunand ca in Figura 3.15 R1 : RID=1.1.1.1 si R5: RID=5.5.5.5, Tabelul 3.22 arata ce trimite R1 si ce face R4 cu informatia primita. Pas 1 Transmisia lui R1 Trimite o rezervare pentru {SA=1.1.1.1,LSP ID=1,EA=5.5.5.5,TID=8,XTID=0}, cerand 35Mb de-a lungul caii R1>R2->R5.Numim aceasta rezervare Res1. Trimite o rezervare pentru {SA=1.1.1.1,LSP ID=2,EA=5.5.5.5,TID=8} de-a lungul caii R1->R3->R4->R2->R5, cerand 80Mb largime de banda. Numim aceasta rezervare Res2 Actiunea lui R2 Dirijeaza rezervarea catre R5. Marcheaza interfata R2->R5 ca avand rezervat 35Mb pentru acest tunel si 65Mb rezervabili.

Examineaza rezervarea si realizeaza ca aceasta este identica cu rezervarea anterioara cu exceptia ID-ul tunelului. Permite noii rezervari sa refoloseasca largimea de banda rezervata si aloca acestui tunel 80-35=45Mbps mai multa largime de banda pe link-ul R2>R5. Link-ul R2->R5 este marcat cu 80Mbps rezervati si 20Mbps nerezervati. Tabelul 3.22 Pasii in Make-Before-Break

In acest fel, atat Res1 cat si Res2 li se permite sa coexiste pana cand Res1 este inlaturat din retea. Dupa ce Res2 incepe sa imparta rezervarea cu Res1, Res1 in scurt timp nu va mai fi activ si nu va mai incerca nici o data sa concureze cu Res2 pentru largime de banda. 3.5.6.2 Cum lucreaza mecanismul de actualizare(refresh)? RSVP este un protocol soft-state: rezervarile sunt actualizate periodic. Rezervarile sunt trimise folosind mesajele Path si Resv. Nu exista diferenta intre mesajele Path si Resv folosite 59

pentru setarea LSP initiala si cele folosite pentru actualizarea caii; formatul pachetului este la fel. Felul in care un router spune o noua cale setata dupa actualizare este pentru a vedea daca exista deja o rezervare cu un grup de cinci(five-tuple) care se potriveste cu mesajele Path si Resv in cauza. Mecanismul de actualizare cuprinde doua puncte majore: -timpii de actualizare(refresh) cu jitter -mesajele Path si Resv sunt trimise independent intre doua routere. Timpii de actualizare cu jitter. Mesajele Path si Resv sunt trimise la fiecare 30 de secunde.De fapt aceste mesaje sunt trimise la 30 de secunde cu o oscilatie de 50 procente : o rezervare data are mesajul Path (sau Resv)trimis pentru actualizare la fiecare 15-45 de secunde. Ideea generala este ca un vecin trimite intervalul sau de actualizare(R) la vecinii sai in obiectul TIME_VALUE din mesajele sale Path si Resv. Fiecare router de asemenea stie cate mesaje este dispus sa le piarda inainte sa declare rezervarea inactiva.(K). Vecinul calculeaza un holdtime L pentru mesaj cu formula: L>=(K+0.5)*1.5*R In implementarea IOS curenta R=30 secunde, K=3: L este cel putin 157.5 secunde. Aceasta inseamna ca un router poate astepta pana in 157.5 secunde fara nici o reactualizare inainte de a rupe o legatura cu un vecin. Este suficient timp ca un router sa aiba trei intervale consecutive cu toate pachetele pierdute in timpul de actualizare (45 secunde) inainte de a expira timpul(time out).

Figura 3.16 Mesajele Path si Resv sunt trimise independent Acest lucru este perfect normal. Mesajele Path si Resv nu sunt trimise in maniera ping/ACK ci sunt trimise independent una de cealalta.

60

Cand, unde, si cui ii sunt trimise mesajele? Exista noua tipuri de mesaje RSVP(cum am mentionat si mai devreme). Tabelul 3.23 rezuma ce mesaje sunt timise , cand si unde. Tabelul are cinci coloane: -Mesajul tipul mesajului. -Functia pentru ce este folosit mesajul. -Directia directia in care este trimis mesajul. Aval inseamna catre sfarsitul(tail) tunelului, in directia opusa de inceputul(head) tunelului.Amonte inseamna catre inceputul tunelului, in directia opusa de sfarsitul tunelului. -Adresa destinatie Destinatia adresei IP a pachetului. -Alerta routerului(Router Alert?) unele mesaje RSVP cara optiunea Router Alert, altele nu. Mesajul Path Resv PathErr Functia Semnaleaza o cerere de resurse in retea Raspunsul la un mesaj Path reusit Trimis catre capatul tunelului daca exista o eroare in mesajul Path Trimis catre sfarsitul tunelului daca exista o eroare in procesarea mesajului Path Trimis catre sfarsitul tunelului pentru a inlatura o rezervare existenta Trimis catre capatul tunelului pentru a inlatura o rezervare existenta Trimis ca raspuns la Resv sau ResvTear care a cerut confirmarea mesajului Directia Aval Amonte Amonte Adresa Destinatie Capat Urmatorul hop (next-hop) Urmatorul hop (next-hop) Router Alert? Da nu nu

ResvErr

Aval

Urmatorul hop (next-hop)

nu

PathTear

Aval

Sfarsitul tunelului

da

ResvTear

Amonte

Urmatorul hop (next-hop)

nu

ResvConf

Aval

Sfarsitul tunelului

da

61

ResvConfTear

Hello

Trimis in Aval Urmatorul hop raspuns la (next-hop) ResvTear care include si mesajul de confirmare Trimis la un Amonte/Aval Urmatorul hop vecin RSVP sau (next-hop) pe un link direct conectat Tabelul 3.23 Tipul mesajelor RSVP

nu

nu

Strict vs Slab sub-obiect ERO. In obiectul EXPLICIT_ROUTE L bit poate fi setat pe un hop in ERO pentru a indica o ruta slaba. ERO este codata ca o serie de sub-obiecte numite noduri abstracte(abstract nodes) . Un nod abstract poate fi o adresa IPv4, adresa IPv6 sau un sistem autonom. Fiecare sub-obiect poate fi ori un hop precis, ori un hop slab. Cand un router proceseaza un hop precis, adresa IPv4 din sub-obiect trebuie sa fie direct conectata de routerul care proceseaza, altfel va fi o eroare in ERO. Daca un router proceseaza un sub-obiect ERO cu un hop slab, routerul respectiv este responsabil sa genereze un set de hopuri precise pentru ca mesajul Path sa ajunga la destinatie si sa inlocuiasca acel hop slab cu noul set generat de hopuri precise. Implicit vs Explicit Null Sfarsitul tunelului poate semnala doua tipuri de etichete- implicit null si explicit null. Explicit null este semnalat folosind valoarea 0 in campul Label(eticheta) din obiectul LABEL. Implicit null este semnalat folosind valoarea 3 in campul Label(eticheta) din obiectul LABEL. Initial(default), nodul din sfarsitul(coada) tunelului semnalizeaza explicit null in mesajele Resv: LABEL type 1 length 8 : 00000000 Daca privim la penultimul hop, se observa ca valoarea explicit null este interpretata ca implicit null, atat de hopul de la sfarsitul tunelului, cat si de penultimul hop. 3.6 Administrarea TE in MPLS 3.6.1 Protectie si restaurare. Din perspectiva unui router sunt doua tipuri de esec : esecul link-ului si esecul nodului. Abilitatea MPLS TE este de a calauzi traficul departe de IGP obtinand ajutor pentru calea cea mai scurta si micsorand pierderea de pachete in asociere cu un esec a unui link sau nod din retea. Aceasta abilitate a MPLS TE este cunoscuta ca FRR(Fast Reroute) sau mai simplu Protectie MPLS TE. Nevoia pentru FRR(Fast Reroute): Sunt cateva lucruri pe care IGP nu le face prea bine cand vine vorba de convergenta(in cazul unui esec in retea): 62

-In retelele mari, unui IGP ii poate lua cateva secunde sa convearga; pana cand intreaga retea converge, exista pierderi de pachete. -Un esec al link-ului poate conduce la o congestie in unele parti a retelei in timp ce in alte parti a retelei nu este congestie. -Configurand un IGP sa convearga rapid poate duce la o sensibilitate prea mare pentru o pierdere mica de pachete, cauzand convergenta IGP fara nici un motiv. Presupunand ca un IGP este un protocol link-state, SPF trebuie rulat atunci cand un link devine down si din nou cand link-ul devine up. Aceasta problema este accentuata in MPLS TE: daca un link care face parte dintr-un LDP care devine down, LSP-ul devine down. Dupa ce capatul tunelului TE recalculeaza o noua cale, SPF trebuie rulat din nou pentru rutarea prefixelor peste tunel cand este stabilita rutarea automata, aceasta facand timpul de convergenta mai rau decat in retelele IP traditionale.Astfel s-a dezvoltat mecanismul FRR pentru a dobandi cat mai putine pierderi de pachete. Ce este protectia? Protectia in contextul de FRR(fast restoration),este procedura prin care, aplicata resurselor selectate, asigura pierdere minima a traficului in urma unui esec. Resursele protejate pot fi atat resurse fizice(link-uri sau noduri) sau resurse logice(LSP-uri care traverseaza un link sau un nod). Termenul protectie ar trebui asociat cu faptul ca resursele back-up sunt pre-stabilite si nu sunt semnalate in urma unui esec.[31] Tipuri de protectie Protectia poate fi impartita in : -protectia caii -protectie locala: -protectia linkului -protectia nodului Protectia caii: Protectia caii este esentiala in stabilirea unui LSP aditional in paralel cu LSP-ul existent; LSP-ul aditional este utilizat numai in cazul unui esec. Acest LSP se mai numeste backup, secondary sau standby LSP. LSP backup este construit pe langa calea existenta cat mai diferit posibil. Ambele LSP-uri primary si backup sunt configurate pe capatul tunelului TE. Aceasta metoda, protectia caii, nu este scalabila: pentru orice LSP ce se doreste protejat se construieste un alt LSP.

Figura 3.17 Protectia caii 63

Protectie locala: Protectia locala este un termen folosit cand tunelul backup(tunelul de protectie) este construit sa acopere numai un segment a LSP-ului primar. Protectia locala ca si protectia caii, cere ca LSP backup sa fie pre-semnalizat. In protectia locala, LSP backup este rutat in jurul linkului cazut(in protectia link-ului) sau a nodului cazut(protectia nodului), iar LSP-ul primar care trece prin link-ul(nodul) cazut este incapsulat in LSP backup. Protectia locala are cateva avantaje in comparatie cu protectia caii:o recuperare asupra esecului mai rapida,1:N scalabilitate, consuma mai putin din starea retelei.

Figura 3.18 Elementele protectiei locale Termen PLR MP NHop NNHop Definitie Point of Local Repair(Punctul local Reparat) capatul tunelului backup 12008a este un PLR. Merge Point(Punctul de unire)- punctul de unire este acolo unde tunelul backup se termina.EX :7200c. Next-hop router(Router next-hop) un router care este la o departare de un hop fata de PLR.Ex:12008c. Next-next-hop router(Routerul next-nexthop) un router care este la doua hopuri distanta de PLR. Ex:7200c este NNHop pentru PLR 12008a. Tabelul 3.24 Terminologia folosita in protectia locala

tunel backup=tunel de protectie=tunel FRR Protectia link-ului Protectia link-ului poate fi divizata in patru sectiuni : 64

-configuratia inaintea esecului (prefailure) -se configureaza pe capatul tunelului TE pe interfata tunelului care se doreste protejat -pe PLR: activand FRR pe PLR implica doua lucruri: -crearea unui tunel backup pe Nhop -configurarea link-ului protejat sa foloseasca tunelul backup dupa esec

Figura 3.19 Protectia Link-ului -detectia esecului Mecanisme adaugate la detectia acestor esecuri: -mecanismul de detectie a esecului specifice unui nivel fizic particular(SONET) -pentru link-urile punct-la-punct, PPP sau HDLC keepalives -extensiile RSVP hello

Figura 3.20 Detectia esecului folosind RSVP Hellos

65

Detectia bazata pe RSVP hello este considerata suficienta pentru detectia esecului in protectia locala, si convergenta este mai rapida decat in IP sau MPLS TE fara FRR. -restabilirea conectivitatii Imediat ce este detectat un esec, PLR este responsabil pentru comutarea traficului pe tunelul backup. Procesarea interna realizata pe PLR implica urmatoarele : -asigurarea ca backup-ul LSP pre-semnalizat este stabilit. Aceasta include noua eticheta prevazuta pentru noul vecin din aval. -noua informatie de adiacenta(incapsularea de nivel 2) este calculata pe baza interfetei fizice de iesire a tunelului backup. -semnalizarea dupa esec(post - failure) Semnalizarea RSVP care se intampla dupa ce protectia FRR a avut loc se poate imparti in urmatoarele: -semnalizarea in amonte

Figura 3.21 PathErr fara protectie locala Cand capatul tunelului TE unui LSP primeste eroarea:nici o ruta nu este disponibila catre destinatie, aduce interfata tunelului down si apoi incearca sa gaseasca o noua cale pentru LSP. Capatul tunelului TE ignora faptul ca protectia locala poate fi disponibila in jurul link-ului cazut. Ca rezultat traficul de-a lungul LSP-ului este pierdut pana cand LSP-ul poate fi rerutat. Acest lucru face LSP-ul de backup complet inutil. De aceea este nevoie de un mecanism pentru 12008a sa-i comunice lui 7200a urmatoarele: link-ul din aval de-a lungul caii LSP este down, rerutez traficul temporar. Calea folosita catre destinatie nu mai este cea optima, calculeaza(copute) o cale alternativa, daca este una disponibila. Lucru cunoscut ca LSR 12008a triggering reoptimization.[31] Pentru semnalizarea informatiei nondestructive se foloseste PathErr cu ERROR_SPEC continand codul de eroare 25, Notification si un subcod 3, Tunnel locally repaired. Capatul tunelului TE care primeste notificarea 25/3 incearca sa calculeze si sa semnalizeze o noua cale pentru acel tunel. Dupa ce primeste mesajul de rezervare(RESV) pentru aceasta cale noua, eticheta pentru calea veche este inlocuita cu eticheta pentru calea noua. Numai dupa aceea LSP-ul vechi devine down. Aceasta realizeaza make-before-break si ajuta la minimizarea pierderii de pachete.

66

Figura 3.22 PathErr cu protectie locala Cand un link protejat cade si este comutat pe tunelul de back-up, PLR-ul trimite de asemenea mesaje Path pentru LSP-ul protejat pe tunelul de back-up. Aditional sunt facute niste schimbari in corpul mesajului Path. Tunelele LSP sunt identificate de o combinatie a obiectelor SESSION si SENDER_TEMPLATE in mesajele Path si Resv. Obiectul SENDER_TEMPLATE este modificat de PLR pentru ca expeditorul adresei IP va contine acum adresa IP a PLR-ului si nu cea a capatului tunelului TE. In acest fel sfarsitul tunelului va observa ca mesajul Path vine de la un nou expeditor dar apartine aceluiasi expeditor. In acest punct, mesajele de actualizare(refresh) curg(flow) pe tunelul de back-up. Starea initiala , mentinuta de catre sfarsitul tunelului pentru aceasta sesiune, devine down in cele din urma datorita timeout-ului;dar mesajul Path modificat de catre PLR este suficient de eficient pentru a mentine rezervarea largimii de banda atat cat este necesar. [31] -notificarea IGP In absenta FRR, daca capatul tunelului TE principal primeste un link-down LSA pentru un link care a facut parte din LSP-ul principal, capatul tunelului TE rupe tunelul principal. Dupa aceasta, capatul tunelului TE poate, daca este configurat corect, sa incerce sa reruteze calea LSP. Daca tunelul principal este configurat pentru FRR, link-down LSA nu are nici un effect, capatul tunelului TE rupe un LSP protejat numai pe baza mesajelor de eroare RSVP si le ignora mesajele IGP care raporteaza un link down de-a lungul caii LSP. Asta inseamna ca un link down nu este in mod necesar un LSP cazut deoarece calea LSP poate fi protejata. -semnalizarea in aval

Figura 3.23 PathTear in absenta FRR 67

Cand link-ul dintre 12008a si 12008c devine down(cand nici o protectie locala nu este stabilita), 12008c trimite un mesaj PatnTear catre 7200c. Daca calea LSP era protejata de FRR, acest tip de mesaj ar fi avut un efect advers. Ar fi rezultat ca LSP sa devina down, chiar daca LSP ar fi fost protejat local de PLR. Pentru a preveni aceasta, mesajul PathTear trebuie suprimat pentru LSP-ul primar care are flag-ul activat: Loop Protection Desired Cum routerul de la sfarsitul tunelului, 7200c nu stie daca tunelul protejat a esuat, in afara de cazul in care se intampla unul din urmatoarele lucruri : -primeste un update IGP despre esecul link-ului -primeste un PathTear de la MD 12008c -nu primeste un mesaj de actualizare RSVP (Path) care tine sesiunea valabila pentru o anumita perioada de timp. Daca routerul de la sfarsitul tunelului primeste un update IGP despre esecul unui link, nu se ia nici o masura din perspectiva MPLS TE. Daca semnalizarea RSVP este declarata expirata, calea LSP este declarata inactiva, si un mesaj ResvTear este trimis catre capatul tunelului TE. Aceasta inseamna ca , separat de prevenirea PathTear sa fie trimis de MP 12008c, trebuie cumva sa se asigure ca sfarsitul tunelului continua sa primeasca mesaje de actualizare RSVP chiar daca unul din link-urile care alcatuia LSP-ul principal este down. Acest lucru este realizat asigurandu-ne ca MP(12008c) continua sa primeasca mesajele Path pentru LSP-ul primar pe tunelul backup.

68

69

Cap.4. Calitatea serviciilor in retele MPLS 4.1 Introducere QoS si MPLS sunt pe un anumit nivel politic similare. Totusi pe un nivel tehnic, QoS si MPLS sunt foarte diferite. Prin QoS se intelege caracteristicile de performanta a retelei, si cuprinde doua parti: -gasirea unei cai prin retea care poate oferi serviciul -obligarea indeplinirii serviciului Din punct de vedere al suportului pentru calitatea serviciilor (QoS), telul MPLS a fost sa ofere ceea ce ofera IP-ul, adica Servicii Diferentiate (Diffserv). Cnd au aparut primele drafturi despre MPLS, au fost rezervati 3 biti pentru a transporta informatii despre clasele de servicii. n final IETF a botezat acesti biti ca fiind Experimentali, desi majoritatea constructorilor i folosesc ca pe bitii Precedenta din IP. Bitii EXP sunt analogi (si cel mai adesea o copie) a bitilor Precedenta din IP. Arhitectura MPLS si-a dorit sa se integreze bine cu protocolul IP si sa fie ct mai independenta de protocolul de nivel 2. Astfel s-a ales sa se ofere suport pentru Diffserv, n detrimentul suportului QoS oferit de ATM. Aceasta decizie a dus la o simplificare majora a implementarii MPLS, obtinnd performante care sunt competitive desi sunt inferioare celor oferite de ATM. Calitatea serviciilor nseamna diverse lucruri pentru diverse persoane. La nivelul retea, QoS e compus din doua lucruri: -sa se gaseasca o cale prin retea care sa ndeplineasca cerintele impuse -sa se respecte restrictiile impuse Gasirea celei mai bune cai prin retea poate fi o actiune de genul alegerii caii cu cost minim furnizate de IGP. Respectarea restrictiilor impuse se poate rezolva prin dimensionarea retelei cu att de multa banda nct sa se elimine problema. Aceasta abordare mai este numita si cantitatea serviciilor, dar la baza este o solutie temporara pentru a asigura calitatea serviciilor. Totusi, lucrurile pot fi rezolvate si altfel. O cale disponibila prin retea poate fi construita printr-un LSP TE, similar cu un ATM PVC, fara a tine cont de metrica protocolului de rutare. Respectarea restrictiilor impuse se poate face folosind mecanismele Diffserv, cum ar fi policing, marcare, repartizare n cozi si aruncare. MPLS este doar o unealta care poate fi folosita mpreuna cu mecanismele Diffserv pentru a oferi calitatea serviciilor. Quality of Service sau QoS reprezinta pe scurt prioritizarea traficului in functie de protocol. Orice retea mare (cateva sute sau mii de calculatoare) sau orice retea care foloseste o singura iesire spre Internet implementeaza sau ar trebui sa implementeze QoS. Pentru o activitate eficienta traficul trebuie prioritizat in functie de protocolul respectiv. Astfel VoIP - VoiceOverIP, SSH, protocoalele de remote management sau video au nevoie de delay minim. Fiecare milisecunda in plus necesara unui pachet sa ajunga de la sursa la destinatie poate duce la imposibilitatea de folosirea a tehnologiei respective. Exista protocoale si servicii care nu necesita delay scazut. Ex: email, download-urile, P2P, chiar si Web-ul. Calitatea serviciului (QoS) le ofera furnizorilor de servicii posibilitati uriase de a furniza niveluri diferite de servicii (de exemplu, Gold, Silver sau Bronze), precum si avantajul unor scheme de pret diferentiate si a unei asistente adaptate clientului. QoS da posibilitatea retelei sa aloce resurse pentru aplicatiile esentiale anumitor obiective sau pentru cele puternic dependente de factorul timp. QoS asociat cu MPLS va rezolva trei cerinte esentiale pentru aplicatiile care functioneaza ntr-o retea VPN functionare previzibila, implementarea de politici si livrarea de 70

noi servicii. Avantajele inerente de cost si viteza n administrarea si instalarea de VPN MPLS ofera o pozitie de lider pe piata. n retelele MPLS, clasele de servicii distincte folosite, duc la clasificarea fluxurilor de trafic la nivelul 3 (retea). Acest lucru face ca implementarea sa fie mult mai simpla. Exista doua metode de a indica clasa de servicii n tehnologia MPLS: Prima metoda este copierea bitilor de Prioritizare IP (IP Precedence) din antetul pachetului IP, n cmpul EXP al antetului etichetei MPLS. Cmpul EXP are 3 biti, ceea ce nseamna ca se pot defini pna la 2 = 8 clase de servicii diferite. A doua metoda este utilizarea de etichete diferite pentru clase de servicii diferite. 4.2 Modelele utilizate pentru implementarea QoS Pentru utilizarea eficienta a tuturor capabilitatilor oferite de implementare QoS este foarte important sa se realizeze un plan elaborat. La construirea acestui plan trebuie sa se ia n considerare doua aspecte foarte importante: Ce tipuri de aplicatii se folosesc n retea. Care tehnici de QoS ar putea sa mbunatateasca performantele retelei. Daca se analizeaza corect primul aspect, si se gaseste solutia corecta relativ la cel de al doilea, atunci resursele retelei vor fi folosite cel mai eficient. Pentru implementarea QoS s-au elaborat doua modele: Modelul Serviciilor Integrate (Integrated Services Model) si Modelul Serviciilor Diferentiate (Differentiated Services Model). IntServ si propunea sa faca rezervari capat la capat pe fiecare flux, motiv pentru care nu este scalabil n Internet. Totusi, poate fi folosit cu succes n retele mici si medii, n cazul n care este suportat de echipamentele de retea. Semnalizarile IntServ folosesc protocolul RSVP pentru a comunica tuturor nodurilor din cale cerintele de trafic dorite de hosturi. Nodurile din retea creau stari si alocau resursele hosturilor care solicitau anumite garantii. n cazul n care negocierea au succes, garantiile oferite de IntServ sunt deterministe. Din celalalt punct de vedere, DiffServ a fost vazut ca o tehnologie scalabila, care nu mpovareaza nodurile din centrul retelei, obligndu-le sa faca multe prelucrari. El foloseste clasificarea pachetelor pe marginea domeniului si un sistem de cozi cu prioritati n centrul retelei. 4.2.1 Modelul Serviciilor Integrate Modelul Serviciilor Integrate consta n faptul ca serviciile QoS sunt cerute n mod explicit de catre aplicatia care le doreste, prin transmiterea prin retea a unei semnalizari adecvate. Semnalizarea cererilor de servicii QoS se realizeaza prin intermediul protocolului RSVP de rezervare a resurselor (Resource Reservation Protocol). Acest model are dezavantajul ca da nastere unui volum semnificativ de trafic de control, care duce la utilizarea ineficienta a benzii. Se foloseste o semnalizare capat la capat ntre entitatiile comunicante prin care se cere rezervarea resurselor necesare n nodurile din retea. Pentru a face acest lucru s-a folosit traditional protocolul RSVP pentru a transporta semnalizarile si pentru a instala starile de rezervare n noduri. Principalele dezavantaje ale RSVP sunt necesitatea acestuia de a rula capat la capat (astfel trecnd prin retele care pot sa nu suporte rezervarea de resurse) si nevoia de a folosi semnalizari per flux ntre doua entitati. Al doilea dezavantaj a avut un rol important n determinarea scalabilitatii solutiei, deoarece ntr-o retea mare pot exista zeci sau sute de mii de stari ntr-un nod, iar traficul periodic de mentinere a rezervarii poate ocupa o parte importanta din capacitatea linkului.

71

MPLS poate folosi RSVP pentru distributia de etichete, folosind anumite extensii ale acestuia. Diferenta fata de primul caz consta n rularea RSVP doar n reteaua core, avnd nodurile de granita ca si capete. Acest lucru reduce mult numarul de entitati comunicante, crescnd scalabilitatea solutiei. Al doilea avantaj consta n faptul ca rezervarea se face acum pe clase de echivalenta, si nu pe fluxuri individuale, reducnd mai mult numarul de semnalizari si stari ce trebuiesc folosite. n functie de ct de fine sunt clasele de echivalenta se poate extinde scalabilitatea protocolului. n cazul RSVP-TE odata cu cererile de eticheta se transmit si parametrii de trafic doriti n obiecte de tip TSpec si RSpec. Nodurile intermediare ajusteaza informatiile din TSpec n functie de ct pot rezerva n momentul respectiv. Nodul destinatie aloca eticheta, dar face si cererea de rezervare a resurselor. Calea este mentinuta atta timp ct se primesc periodic mesaje de tipul PATH. Daca se doreste cresterea sau scaderea resurselor folosite n mod curent pentru cale, se pot trimite noii parametrii n mesajele PATH. Astfel, calea ar primi o noua rezervare n timp ce este folosita. Totusi, daca din diverse motive, rezervarea nu se poate face, calea va fi stearsa si traficul de date va fi ntrerupt.Pentru a remedia aceasta problema posibila, mai exista un mod n care se pot cere resurse suplimentare. Calea initiala este mentinuta, dar n acelasi timp este realizata alta cale cu anumiti parametrii de trafic doriti. n momentul n care calea secundara este gata, traficul este dirijat prin ea si calea originala este stearsa. n acest caz, daca calea secundara nu poate fi construita, calea principala ramne n folosinta si nu apar ntreruperi n trafic. RSVP-TE nu este singurul protocol capabil sa faca alocari de banda. CR-LDP permite crearea de cai cu comutatie a etichetelor care sa aiba o anumita banda garantata. De asemenea, parametrii acestor cai pot fi modificati pe timpul functionarii caii, fara a fi nevoie sa se stearga calea principala. CR-LDP beneficiaza de avantajul de a fi un protocol de tip Hard State, astfel neavnd nevoie de semnalizari permanente pentru a mentine o cale, asa cum are nevoie RSVP-TE. Din acest motiv CR-LDP este preferat n retele MPLS foarte mari, unde RSVPTE poate sa nu fie foarte scalabil.

4.2.2 Modelul Serviciilor Diferentiate Arhitectura DiffServ este definita n RFC 2475 mpreuna cu modul de folosire al Diffserv Code Point (DSCP) si mecanismele QoS ce trebuiesc implementate ntr-o retea pentru a oferi diferite calitati ale serviciului. Diffserv are doua componente majore: -Conditionarea traficului Include elemente precum policing, colorare si shaping. Aceasta prelucrare e facuta doar la marginea domeniului -Comportamentul n fiecare nod (Per-hop behaviour) consta din mecanismele de repartizare n cozi, planificare si aruncare. Asa cum i spune si numele, actiunile sunt facute de fiecare nod din retea. Functiile suplimentare necesare pentru a implementa Diffserv includ clasificarea pachetelor si conditionarea traficului, cum ar fi masurarea, marcarea, formarea si aplicarea politicilor asupra traficului. Serviciul Diffserv este oferit doar n interiorul unui domeniu Diffserv, care consta dintr-un set continuu de noduri caracterizate de anumite tipuri de comportament (PHB) si pot aplica anumite reguli asupra traficului. Astfel, nodul de intrare din domeniul Diffserv verifica daca traficul de intrare respecta specificatiile tehnice mentionate n contract (SLA), altfel 72

va marca traficul ca fiind neconform. Tot nodul de intrare va asocia traficul ntr-un Agregat de Comportament (BA-Behaviour Aggregate) pe baza unuia sau mai multor cmpuri din antetul de nivel 3. Dupa aceasta actiune fiecare pachet este marcat cu un anumit cod DSCP. Nodurile de intrare vor face formatarea si conditionarea traficului pe baza clasificatorului. Nodurile din interiorul domeniului nu mai trebuie sa faca reclasificari, ci doar sa aplice un set de reguli traficului de intrare (Per Hop Behaviour). Acest PHB specifica cte resurse vor fi alocate pentru un BA. Traficul de tip Best-Effort este si el clasificat, si de regula are o banda minima specificata. [RTC] [OPALSOFT-DS]

Figura 4.1. Arhitectura DiffServ 73

Clasificarea pachetelor Primul lucru necesar pentru a aplica arhitectura DiffServ este abilitatea de a clasifica pachetele. Clasificarea este actiunea de a examina un pachet pentru a hotar ce fel de reguli trebuie sa urmeze, si ulterior, ce marcaj DSCP sau EXP trebuie sa primeasca. n mod uzual clasificarea se poate face dupa codul DSCP existent (n acest caz se foloseste clasificatorul Behaviour Aggregate) sau dupa mai multe cmpuri, folosindu-se un clasificator multicmp. Clasificarea pachetelor IP Pachetele IP pot fi clasificate usor. Se pot face comparatii dupa orice cmp IP, dar n general se foloseste adresa IP destinatie, adresa IP sursa sau valoarea DSCP. n plus se mai poate face si analiza de nivel 4, dupa tipul de protocol sau dupa portul folosit, pentru a se face o separare mai fina. Totusi o clasificare complexa implica un timp mai mare petrecut n nodul de intrare si astfel, o reducere a performantelor de calitate. [RTC] [OPALSOFT-DS] Clasificarea pachetelor MPLS Pachetele MPLS care intra ntr-un domeniu cu suport pentru Diffserv pot fi clasificate n principiu doar dupa valoarea bitilor EXP din eticheta din vrful stivei. Nodurile de intrare nu vor analiza celelalte etichete si nici informatiile de nivel 3 deoarece ar fi nevoie sa se elimine antetul de nivel 2 n prealabil. Acest lucru nu este dorit la granita care leaga domenii MPLS. Policing Functia de policing implica masurarea traficului utilizatorului si compararea masuratorii cu un contract de servicii ncheiat cu furnizorul. Ideea principala n Diffserv este ca nu se permite traficul excedentar sa intre n retea daca se depaseste capacitatea cozilor instalate. Acest lucru este facut prin policing, desi poate fi facut si prin mecanismul de shaping (formare). Functia de policing este facuta la granita retelei. Astfel, majoritatea pachetelor care vor intra n retea sunt de tip IP. Totusi, sunt cteva cazuri n care traficul de intrare poate fi MPLS. Un exemplu n acest caz este arhitectura Carrier Supporting Carrier, prin care reteaua furnizorului ofera servicii de transport pentru alt furnizor, care i este client. Cei doi furnizori se pot pune de acord sa foloseasca trafic MPLS pentru comunicarea ntre ei. Marcarea Regulile de marcare sunt adesea strns legate de regulile de policing. Astfel, traficul care iese din policer poate fi marcat ca fiind conform sau neconform. Ulterior aceste doua tipuri de trafic vor fi servite diferentiat. Totusi, nu e nevoie de un policer pentru a face marcarea. De exemplu se poate face un mapping ntre valoarea DSCP a pachetului IP si valoarea EXP pe care o va lua pachetul etichetat. Alta varianta este sa se marcheze traficul care intra pe o interfata, indiferent de rata acestuia. Acest lucru e util atunci cnd furnizorul taxeaza n plus unii clienti pentru QoS extra. Cnd nu se doreste un serviciu cu o anumita calitate, se pot seta bitii EXP la valoarea 0. Prin faptul ca marcarea se face n antetul de nivel 2,5 nodurile MPLS nu trebuie sa analizeze cmpul 74

Precedenta din IP pentru a hotar tipul de tratament ce trebuie aplicat pachetului. n plus, analiza de nivel 3 nu este dorita si din urmatorul motiv: operatorul retelei MPLS poate decide sa aloce pachetul ntr-o anumita clasa de servicii, fara a modifica clasa de servicii marcata initial n DSCP. Astfel, la iesirea din domeniul MPLS, pachetul clientului poate beneficia din nou de privilegiile cerute. Marcarea pachetelor IP Antetul IP a evoluat continuu de-a lungul timpului din punct de vedere al marcarii calitatii serviciilor. Initial exista un cmp Type of Service (ToS) compus din 3 biti de precedenta plus 4 biti ce marcau tipul de serviciu dorit. Bitii de precedenta erau folositi pentru a alege un tip de tratament ce i va fi aplicat pachetului. Valorile ntre 0 si 5 erau destinate datelor utilizatorului, iar valorile 6 si 7 marcau traficul de control din retea. Diffserv a redefinit cmpul ToS folosind 6 biti pentru marcarea tratamentului dorit pentru pachet, (acest lucru formnd cmpul DSCP) iar doi biti folositi ulterior pentru ECN. Desi Diffserv pune la dispozitie 64 de clase de trafic, numai 15 au fost definite si n practica, un furnizor poate implementa mai putine. Nume Best effort AF11 AF12 AF13 AF21 AF22 AF23 AF31 AF32 AF33 AF41 AF42 AF43 EF DSCP (zecimal) 0 10 12 14 18 20 22 26 28 30 34 36 38 46 DSCP (binar) 000000 001010 001100 001110 010010 010100 010110 011010 011100 011110 100010 100100 100110 101110

Tabelul 4.1 Clase de trafic folosite in Diffserv Au fost definite 12 valori AF, n formatul Af xy , unde x e numarul clasei, iar y este prioritatea de aruncare. Aceste patru clase (AF1x-AF4y) furnizeaza o metoda de a oferi o pierdere de pachete mica ntr-o anumita banda de trafic, dar face garantii minimale asupra ntrzierii. EF a fost definit pentru a servi trafic care cere o ntrziere minima, un jitter minim si o pierdere minima de pachete. Nu este nevoie de mai multe clase de tip EF deoarece acestea ar concura pentru aceleasi resurse. [RTC] [MPLS-TE] Marcarea pachetelor MPLS Problema care poate aparea atunci cnd se doreste stabilirea unei corespondente de la DSCP la EXP este faptul ca DSCP este stocat pe 6 biti, pe cnd EXP ocupa doar 3 biti. n retelele n care MPLS functioneaza n modul cadru (spre deosebire de retelele n care 75

functioneaza n modul celula peste linkuri ATM) se folosesc cei 3 biti EXP pentru codificare. Astfel, este nevoie ca mai multe coduri DSCP sa corespunda aceluiasi marcaj EXP. n practica acest lucru nu e o problema, deoarece putini furnizori ofera mai mult de 8 clase de serviciu.Totusi, se pot oferi mai multe clase de serviciu, daca este nevoie, n special pe linkurile ATM folosind bitii EXP n combinatie cu nsasi eticheta folosita. Acest mod de lucru se numeste L-LSP (Label Only Inferred LSP). [OPALSOFT-DS] Repartizarea n cozi Repartizarea n cozi si selectarea planificatorului care sa serveasca acele cozi pot fi diferite n functie de platforma. Aceleasi tehnici de planificare care sunt aplicate asupra traficului Diffserv IP pot fi aplicate si pentru traficul MPLS. Tipurile de cozi uzuale si planificatoarele asociate au la baza coada FIFO si planificatorul Weighted Fair Queueing. Coada FIFO poate fi mbunatatita cu un algoritm de tip Random Early Detection. Aruncarea pachetelor Mecanismul de aruncare al pachetelor nu este important doar pentru a tine sub control dimensiunea cozilor folosite, dar si pentru a reduce debitul surselor TCP. Astfel, cnd o sursa TCP pierde pachete, ea va reduce rata de transmisie. De aceea se doreste ca n caz de congestie cozile sa arunce din pachete, n loc sa le piarda pe cele care nu mai au loc sa intre. n acest scop se poate folosi Weighted Random Early Detection. 4.3 Implementarea QoS prin MPLS Tehnologia MPLS a fost dezvoltata astfel nct sa fie compatibila cu protocolul IP. De fapt scopul primar al acesteia este de a transporta eficient si rapid pachete IP. Ca urmare, la implementarea unei solutii QoS prin MPLS, scopul principal este ca aceasta solutie sa suporte modelele existente IP QoS. Altfel spus, scopul final este implementare QoS cap la cap (end to end).

76

Figura 4.2 Functionarea MPLS QoS n Figura 4.2 este ilustrata exact functionarea unei politici QoS ntre o retea IP clasica, a clientului, si o retea MPLS, a furnizorului de servicii. Practic, n cazul routerelor MPLS care ruteaza pachete, nu e nici o problema de implementare. Pur si simplu se copiaza bitii IP Precedence n cmpul EXP al pachetului MPLS si se implementeaza apoi politica QoS n functie de acesta. La iesire, eticheta este extrasa, iar pachetul IP standard este acelasi care a fost primit la intrare, cu bitii IP Precedence nemodificati. Rezultatul este, implicit, QoS cap la cap pentru clienti. n afara de mecanismele de prioritizare a traficului, una din cerintele unei retele care are implementata o politica de QoS este si securizarea informatiilor. Comutatia de etichete izoleaza traficul pe rute virtuale (Label Switched Paths sau LSP) n functie de eticheta fiecarui pachet. Forta acestui mecanism consta n faptul ca se restrictioneaza accesul asupra configurarii. Altfel spus, numai furnizorul de servicii poate instala rutele virtuale si tot el determina cine le poate accesa. Nu exista nici o posibilitate pentru un utilizator care transmite mesaje pe conexiunea lui normala, sa reconfigureze ruta virtuala sau circuitul virtual pentru a se conecta la aceea a altui utilizator. Tocmai aceasta caracteristica a comutatiei de etichete permite furnizorilor de servicii sa ofere retele private virtuale prin intermediul unei infrastructuri MPLS partajate.Aceasta facilitate nu este nsa una standard care sa se regaseasca si ntr-o retea IP nativa, ci este specifica MPLS. Acesta este nivelul de securitate de baza oferit de reteaua MPLS care este comparabil cu cel disponibil prin intermediul retelelor de tip Frame Relay sau ATM. Cu toate acestea, anumite situatii pot sa necesite criptarea datelor atunci cnd ele sunt transmise de la o locatie distanta la alta. De exemplu, daca avem o transmisie prin satelit, criptarea este absolut necesara, deoarece conexiunea este disponibila oricui dispune de un receptor adecvat si se afla n raza de actiune a respectivului satelit. Implementarea functiilor QoS n cadrul infrastructurii unei retele MPLS ofera o serie de beneficii, att pentru furnizorii de servicii Internet, ct si pentru clienti. n ceea ce i priveste pe furnizorii de servicii, mbunatatirile legate de calitatea serviciilor pentru MPLS le permit acestora sa clasifice pachetele n functie de tipul lor, de interfata de intrare, sau de alti factori, prin marcarea fiecarui pachet fara a modifica structura pachetului clasic IP. De exemplu, furnizorii de servicii pot sa clasifice pachetele fara a tine cont de nivelul de prioritate pe care l are pachetul atunci cnd ajunge la primul router de transport. De asemenea, ei pot sa tina cont de aceasta prioritizare initiala si sa aplice una suplimentara. Beneficiile pe care le poate oferi implementarea functiilor QoS clientilor sunt evidente, ei putnd sa se bazeze pe anumite debite minime, pe o criptare adecvata, etc., si asta ntr-o conexiune cap la cap. DiffServ-Aware Traffic Engineering (DS-TE): DS-TE este numai un mecanism control-plane, ce obtine abilitatea de a rezerva randul pentru largimea de banda. Aceasta abilitate permite construirea TE-LSP care specifica rezervarea de subpool de largime de banda si transporta numai trafic LLC si ca efect construieste o a doua retea peste cea deja existenta: o retea a interfetelor fizice si pool-urilor globale si o retea a subpool-urilor. Implementarea curenta DS-TE permite anuntarea unui singur subpool.

77

5. Modelarea unei retele MPLS-DIFFSERV 5.1 Obiective Cu ajutorul simulatorului de reele OPNET Modeler, am construit o reea care folosete mecanismul MPLS pentru ndrumarea pachetelor n interiorul domeniului. Am utilizat mecanismul QoS Differentiated Services pentru a evidenia tratarea difereniat a dou fluxuri de trafic n scopul calitii serviciilor. Obiectivul primar al acestui exemplu este de a vedea cum doi clieni diferii transmit acelai tip de trafic (FTP) peste o traiectorie comun dar cu prioriti diferite. LSP-urile MPLS transport dou fluxuri de date i folosesc coduri DiffServ pentru a asigna nivele de QoS diferite pentru fiecare. Modelul de reea ales va fi configurat s asigure dou LSP-uri asociate porturilor de intrare aferente celor doi clieni. Fluxurile transmise pe aceste porturi includ pachete pentru aplicatii FTP, dar care au atribuite comportamente de ndrumare diferite: AF3x pentru High priority FTP (Site 3), respectiv AF1x pentru Low priority FTP (Site 4). Pentru analiza rezultatelor se va pune n eviden tratarea difereniat a pachetelor din clase FEC diferite i efectele acestor tratamente in conditii normale si de congestie in retea. 5.2 OPNET Simulrile software sunt foarte utilizate n industria din zilele noastre. Multe din produsele hardware dar i software sunt pretestate n aplicaii software. Avantajele folosirii programelor de simulare sunt evidente: Mai puin timp pentru dezvoltarea produselor hardware i software Abilitatea de a ncerca o mulime de scenarii diferite pentru prototipurile hardware i software fr dezavantajul costului sau al timpului pierdut Prezicerea potenialelor probleme nainte de uzul de zi cu zi OPNET Modeler este o unealt puternic de dezvoltare pentru industria IT. Ea a fost introdus n 1986 i permite designul i studiul comunicaiilor n reele, dispozitive, protocoale i ntre aplicaii. OPNET Modeler este utilizat de ctre unii dintre cei mai prestigioi dezvoltatori de tehnologie pentru accelerarea procesului de cercetare i dezvoltare. Modul de lucru al OPNET-ului este ilustrat n figura urmtoare: Construirea reelei dorite

Selecia statisticilor

Rularea simulrii

Afiarea i analiza rezultatelor Figura 5.1 Etapele de lucru cu OPNET Modelul orientat pe obiect pe care se bazeaz i interfaa grafic permit crearea relativ uoar de modele ale reelelor actuale. OPNET suport majoritatea tipurilor de reele i 78

tehnologii, permitnd astfel obinerea de rezultate concludente asemntoare cu cele utilizrii n viaa real a produselor testate. Ariile de aplicaie includ: Planificarea reelelor (att LAN ct i WAN) i analiza performanelor i problemelor posibile nainte de implementarea actual Scheme de comunicaii wireless i prin satelit i protocoale aferente Managementul reelelor prin fibra optic Dezvoltarea protocoalelor i managementul lor Evaluarea algoritmilor de rutare pentru rutere, comutatoare i alte dispozitive interconectate Cteva dintre caracteristicile care l fac o unealt extraordinar sunt: Posibilitatea vizualizrii ierarhizate a reelelor Modelarea orientat pe obiect Rularea i apoi compararea a mai multor scenarii Modele de trafic pot fi importate n cadrul programului de modelare Abilitatea de analiz prin intermediul graficelor Programul de simulare OPNET ofer posibilitatea modificrii parametrilor reelei i observarea efectelor imediat. Aceste simulri furnizeaz mijloacele de testare pentru diverse schimbri ce ar putea avea loc nainte de implementarea real, analiza fiabilitii componentelor i efectele defectrii uneia, planificarea scalabilitii i multe altele. Costurile asociate cu construirea i funcionarea unei reele fac din OPNET o soluie viabil n luarea deciziilor de planificare, modificare i analiza performanei unei reele. 5.3 Construirea reelei OPNET Modeler ofer o varietate foarte mare de echipamente i soluii cu care se pot crea elementele unei reele. Pentru crearea unui domeniu MPLS-DS este important de tiut care sunt nodurile obligatorii i atributele de configurat astfel nct s funcioneze conform dorinelor. Nodurile obligatorii sunt: 1. Staie de lucru: este responsabil de generarea traficului n interiorul reelei; 2. Server: este folosit n aplicaiile de tip client-server; se conecteaz cu o staie pentru schimb de date; 3. LER: reprezint nodul de intrare sau de ieire al unui LSP, ingress respectiv egress; este nodul la care se conecteaz staiile de lucru i serverele; are rol de clasificare i asociere a traficului la clasele de ndrumare folosite i realizeaz scriere sau scoatere de etichete n stiv; 4. LSR: reprezint nodurile intermediare; ele schimb etichete de-a lungul LSPurilor; 5. MPLS Config: este responsabil de configurarea specificaiilor claselor de ndrumare FEC i profilele de trafic (Traffic Trunk) asociate diferitelor fluxuri; 6. Application Config: aceste modul definete tipurile de aplicaii care pot fi utilizate pentru a simula traficul n reea. 7. Profile Config: acest modul creeaz unul sau mai multe profile care selecteaz aplicaiile ce vor fi folosite de ctre staiile de lucru cnd acestea vor ncepe transmiterea datelor. Atributele configurabile sunt: 1. Specificaii FEC: precizeaz clasele echivalente de ndrumare folosite n reea; acestea pot fi specificate dup: una sau mai multe combinaii ale cmpului ToS,

79

protocolul folosit(TCP, UDP, OSPF, ICMP etc), adresa surs sau destinaie, portul surs sau destinaie; 2. Profile Traffic Trunk: se specific diverse profile de trafic cu diferite rate de trafic maxime, medii, rafale de trafic, aciunea pentru pachetele care sunt n afara profilului. Fiecare Traffic Trunk este asociat unei clase DS; 3. Parametri MPLS: sunt parametrii MPLS folosii i trebuie configurai n fiecare LER i LSR; 4. Configuraii TE: se realizeaz n fiecare LER. Acestea sunt folosite pentru a efectua asocieri de trafic: diferite clase FEC i profile Traffic Trunk sunt legate pe diferite interfee i pot fi asignate diferitelor LSP-uri. Adugarea nodurilor la proiect se face cu ajutorul paletei de obiecte. Aceasta conine toate nodurile posibile, aranjate pe categorii dup tipul reelei, productor, tipul componentei, etc. Se deschide accesnd meniul Topology-Open Object Palette:

Figura 5.2 Paleta de obiecte Aici regsim nodurile obligatorii necesare n cadrul reelei. Cu drag-and-drop se selecteaz cte un obiect i se amplaseaz pe hart. n final reeaua va arata ca n figur:

Figura 5.3 Reeaua construit 80

Cu rou este desenat LSP-ul folosit n acest scenariu, este de tip static, adic s-au precizat toate nodurile prin care trece acesta. Link-urile folosite intre routerele din interiorul domeniului MPLS sunt DS0 cu o capacitate de 64Kbps, pentru a demonstra modul de prioritizare a pachetelor asociate fiecarui profil de traffic in conditii de congestive in retea. Staiile pe care le vom urmri n acest scenariu sunt Site 3 i Site 4 care vor efectua un transfer FTP ctre staia Site 14, un server. 5.4 Configurarea reelei 5.4.1 Application Configuration Acest nod este unul de management al reelei, mai exact al tipurilor de trafic care ar putea s existe n cadrul domeniului MPLS-DS. n cadrul lui se definesc diverse forme de trafic (email, ftp, http, servicii de voce, video, etc) cu diverse grade de ncrcare, distribuii n timp, codecuri i multe altele. Pentru acest scenariu am folosit o aplicaie de transfer de fiiere ctre un server (upload).

Figura 5.4 Configurarea aplicaiilor 5.4.2 Profile configuration A doua etap n configurarea reelei este crearea profilului ce va fi atribuit clienilor. Acest lucru se realizeaz n nodul Profile Config, alegnd unul din tipurile de trafic definite mai sus, respectiv File Transfer.

81

Figura 5.5 Configurarea profilului 5.4.3 MPLS Configuration MPLS Config este nodul n care se definesc tipurile de clase de ndrumare folosite de nodurile LSR din cadrul reelei, corespondenele realizate ntre cmpul EXP i comportamentul PHB sau dup caz ntre cmpul EXP i prioritatea de aruncare a pachetelor, precum i profilele de trafic. ntruct LSP-ul folosit la ndrumarea pachetelor este de tipul E-LSP, tratamentul aplicat pachetelor n fiecare nod va fi determinat de cmpul EXP i se va folosi corespondena standard. S-a creat o singur clas de ndrumare, FTP Traffic, care sorteaz pachetele dup portul destinaie al unui server FTP. Cei doi clieni din reea, pe care vom observa mecanismul DiffServ, au cerut prioriti diferite de tratare a pachetelor generate de ei, deci au profile de trafic diferite. Site-ul 3 va avea o prioritate mai mare la transmiterea pachetelor prin reea dect site-ul 4. Acest lucru este posibil datorit mecanismului DS care permite personalizarea traficului fiecrui client. Clientul cu prioritate mai mare va fi asociat cu un comportament AF3x, iar cel cu prioritate mai mic cu AF1x. Nu se vor lua msuri pentru cazurile n care pachetele sunt out-ofprofile. Pachetele sunt mapate la prioritatea de aruncare cea mai mic AFx1 (AF11, AF31).

82

Figura 5.6 Configurarea claselor de ndrumare 5.4.4 Configurarea clienilor Staiile de lucru sunt configurate cu acelai profil, Engineer 1, pentru a beneficia de traficul de FTP setat n cadrul Profile Config. Ambele staii vor transmite pachetele n acelai ritm, cu aceeai rat, aceeai mrime, n concluzie vor fi la egalitate la momentul transmisiunii.

Fi Figura 5.7 Configurarea clienilor

83

5.4.5 Configurarea nodurilor de grani i intermediare Aa cum tim, pachetele sosesc n ruterul LER ingress unde sunt verificate pentru a vedea dac se ncadreaz n profilul de trafic asociat clientului. Pentru aceasta, mai nti trebuie configurat modul n care se delimiteaz traficul primit de la clieni. n configuraia nodului de intrare LER 2 putem observa c profilele de trafic se mapeaz pe interfaa corespunztoare clienilor: 64Kbps AF3x pe interfaa 1 pentru clientul cu prioritate mare (Site 3), iar 64Kbps AF1x pe interfaa 2 pentru clientul cu prioritate mai mic (Site 4).

Figura 5.8 Maparea traficului de la clieni la clasele de ndrumare n nodul ingress

84

n nodurile intermediare, nu se mai face nici o alt clasificare a pachetelor, LSR-urile avnd rolul doar de a efectua schimbul de etichete i a respecta tratamentul pachetelor conform PHB-ului dedus din cmpul EXP al pachetului.

Figura 5.9 Configuraiile nodurilor intermediare LSP-ul creat conine nodurile de mai jos, unde sunt ilustrate i etichetele care definesc acest LSP. Lipseste nodul egress LER 5 deoarece funcioneaz modul de lucru Penultimate Hop Popping (PHP).

Figura 5.10 Etichetele atribuite LSP-ului LER2-LER5

85

5.5 Statistici i rezultate In continuare am analizat rezultatele obtinute numai in conditii de congestie in retea, deoarece furnizeaza date din care putem trage anumite concluzii. n scenariul pe care l-am creat vom urmri urmtorii parametri i pe baza lor vom analiza performanele modelului MPLS-DS: Timpul de upload ntrzierea produs de cozi Utilizarea bufferelor cozilor Cantitatea de trafic transmis 5.5.1 Cantitatea de trafic transmis n urma simulrilor se poate vedea c avem o cantitate de trafic egal, transmis de ambii clieni. Acest lucru este important deoarece putem face comparaiile viitoare n condiii aproape ideale i putem observa foarte clar diferenele.

Figura 5.11 Cantitatea de trafic transmis 5.5.2 Timpul de upload Timpul de upload este timpul scurs ntre momentul nceperii transmiterii unui pachet i momentul recepiei pachetului de confirmare; include i timpul de semnalizare pentru setarea conexiunii precum i cel de nchidere. Putem observa foarte clar c timpul de upload pentru Site 3 este semnificativ mai mic dect cel pentru Site 4. Aceast statistic arat c n cazul clientului cu trafic cu prioritate mai mare, pachetele acestuia ajung mai repede la server dect n cazul clientului cu prioritate mai mic. Acest lucru se datoreaz clasificrii DiffServ care permite traficului s primeasc tratament preferenial n nodurile LSP-ului n favoarea anumitor fluxuri, respectiv defavoarea altora.

86

Figura 5.12 Timpul de upload 5.5.3 ntrzierea produs de cozi Aa cum am menionat mai sus, fiecare flux primete un tratament individual conform clasificrii care se face n nodul ingress. Cu ct clasificarea este mai bun cu att tratamentul este mai bun. n nodul ingress dup ce s-a realizat msurarea, condiionarea i clasificarea traficului, acesta este distribuit n cozi de ateptare din care conform mecanismului de servire va fi trimis spre urmtorul hop. n acest scenariu ruterele LSR folosesc WFQ pentru rutina de servire a cozilor. Urmtorul grafic prezint ntrzierea pe care o au pachetele cnd ateapt s fie livrate ctre urmtorul hop n ruterul LER 2 ingress. Observm c exist dou cozi de ateptare Q0 i Q2, iar n Q2 timpul de ateptare este mult mai mic dect n Q0, ca dovad a mecanismului QoS. Prioritizarea mai bun a unui flux a fcut s scad timpul de ateptare n cozile de pe parcursul LSP-ului obinnd timpi de rspuns mult mai buni pentru clieni, necesari cerinelor acestora.

Figura 5.13 ntrzierea produs de cozi cu congestie in retea 87

Figura 5.14 ntrzierea produs de cozi fara congestie 5.5.4 Utilizarea bufferelor cozilor Precum la timpii de ateptare, cu ct un pachet ateapt mai mult ntr-o coad, cu att coada respectiv este ocupat mai mult timp. n graficele urmtoare putem observa acest lucru, corespunztor cu cozile de mai sus.

Figura 5.15 Utilizarea bufferelor cozilor cu congestive in retea

88

Figura 5.16 Utilizarea bufferelor cozilor fara cogestie in retea Dupa cum era de asteptat in cazul in care nu avem congestie in retea atat timpul de asteptare in cozi, cat si bufferele sunt foarte putin incarcate. In aceste situatii de folosire a unor prioritati de aruncare mici a pachetelor, mecanismul QoS nu este foarte bine scos in evidenta. 5.6 Concluzii Rezultatele arat c dou fluxuri similare ctre aceeai destinaie, dar cu profile de trafic diferite se comport diferit la tranzitul prin reea. Fluxul cu cod DiffServ mai mare are timp de upload mai mic, ntrziere mai mic i utilizare a bufferelor mai sczut. Clasificarea realizat n primul nod, LER 2, a avut scopul de a prioritiza fluxul de trafic de la site 3 fa de fluxul de trafic de la site 4. Asemenea clasificri se pot face pentru fiecare client n parte, pe baza SLAului, pe baza destinaiei, a tipurilor de trafic sau a altor parametri. Mecanismul DS este ideal pentru c ofer calitatea de care au nevoie clienii, iar suportul MPLS este cel mai bun pentru a realiza acest lucru deoarece este n avantajul furnizorilor de servicii. Granularitatea serviciilor oferite cu ajutorul DS este cel mai bine preluat de viteza de comutaie a etichetelor i cu o calitate a serviciilor foarte bun. Folosirea Serviciilor Difereniate permite crearea de noi nivele de calitate personalizate dup cerinele clienilor, n timp ce MPLS este legtura ntre vechea reea Best Effort i noua reea cu QoS garantat, putndu-se adapta la orice mediu fizic i cu costuri minime.

89

Bibliografie 1. M. Aissaoui et al. ATM/MPLS Mediation : A Basic Interworking Function 2. Grenville Armitage : MPLS: The Magic Behind the Myths 3. Banica Ion , Note de Curs : Comunicaii ntre Calculatoare 4. Eugen Borcoci , Note de Curs: Comunicaii de Band Larg, Reele de Telecomunicaii 5. Braden, Ed., et. Al., Resource Reservation Protocol (RSVP) 6. Cuchiara, J Sjostrand , H Luciani , J.V., Definitions of Managed Objects for the Multiprotocol Label Switching , Label Distribution Protocol 7. Davie, Bruce et al , Mpls using LDP and ATM VC switching 8. Willibald Doeringer, Giinter Karjoth, Mehdi Nassehi, Routing on longest matching prefixes 9. Hideaki Takagi, Queueing A Fondation of Performance Evaluation 10. George Swallow , MPLS Advantage for trafiic Engineering 11. ITU Telecomunication Standardization Sector, OAM and Survivability Functionality for MPLS Networks 12 . Request for Comments 3031 , Multiprotocol Label Switching Arhitecture 13. Request for Comments 2684 , Multiprotocol Encapsulation over ATM Adaptation Layer 5 14 . Request for Comments 2917, A Core MPLS IP VPN Arhitecture 15. Request for Comments 3035, MPLS using LDP and ATM VC Switching 16. Request for Comments 3063, MPLS Loop Prevention Mechanism 17 . Request for Comments 1932 , IP over ATM 18. Site-ul Academiei Cisco http://cisco.netacad.net 19. Site-ul companiei Cisco www.cisco.com 20. Site-ul companiei Juniper www.juniper.net 21. Site-ul www.wikipedia.org 22. [RFC3031] E. Rosen, A. Viswanathan, R. Callon - Multiprotocol Label Switching Architecture ,2001 http://rfc.net/rfc3031.html 23. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette - LDP Specification, 2001 http://rfc.net/rfc3036.html 24. [RFC3213] J. Ash, M. Girish, E. Gray - Applicability Statement for CR-LDP, 2002 http://www.rfc-archive.org/getrfc.php?rfc=3213 25. [RTC] Eugen Borcoci - Reele de Telecomunicaii, 2005 26. [OPALSOFT-DS] Leonardo Balliache - Differentiated Service on Linux HOWTO, 2003 http://opalsoft.net/qos/DS.htm 27. [OPALSOFT] Leonardo Balliache - MPLS related notes, 2006 http://opalsoft.net/qos/MPLS.htm[Martini-encap] Luca Martini, Daniel Tappan, Steve Vogelsang - Encapsulation Methods for Transport of Layer 2 Frames Over MPLS, http://www.ieee802.org/1/files/public/docs2001/draft-martini-l2circuit-encap-mpls-01.txt 28. [RFC3270] F. Le Faucheur, L. Wu, B. Davie, S. Davari - MPLS Support of Differentiated Services, 2002 http://rfc.net/rfc3270.html 29. [MPLS-Myths] Wikimedia - MPLS Myths, http://www.answers.com/topic/mplsmyths 30. Hlio Maurcio Barroso, MPLS TE 31. IAN GILROY, MPLS TE + FRR Tutorial 90

32. [Martini-encap] Luca Martini, Daniel Tappan, Steve Vogelsang - Encapsulation Methods for Transport of Layer 2 Frames Over MPLS, http://www.ieee802.org/1/files/public/docs2001/draft-martini-l2circuit-encap-mpls-01.txt 33. [Martini-trans] Luca Martini, Daniel Tappan, Steve Vogelsang - Transport of Layer 2 Frames Over MPLS, 2001 http://www.ieee802.org/1/files/public/docs2001/draftmartinil2circuit-trans-mpls-01.txt 34. Jeff Apcar, Cisco Advanced Services, Introduction to Traffic Engineering 35. [RFC2547bis] C. Semeria - BGP/MPLS VPN Fundamentals, http://www.juniper.net/solutions/literature/white_papers/200012.pdf

91