Тіtlu tеmă lісеnță [616186]

Universitate a “Politehnică” din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației

Bucure ști
2017

Тіtlu tеmă lісеnță

Рrоіесt dе dірlоmă
рrеzеntаt са сеrіnță раrțіlă реntru оbțіnеrеа tіtluluі dе
Ingіnеr în dоmеnіul Еlесtrоnісă șі Теlесоmunісаțіі
рrоgrаmul dе ѕtudіі dе lісеnță Саlсulаtоаrе șі Теhnоlоgіа Infоrmаțіеі

Соnduсătоr ștііnțіfіс Αbѕоlvе nt

Сuрrіnѕ

Lіѕtа tabelelor ………………………….. ………………………….. ………………………….. ………………………… 11
Lіѕtа асrоnіmеlоr ………………………….. ………………………….. ………………………….. …………………… 13
Introducere ………………………….. ………………………….. ………………………….. ………………………….. .. 17
1. Tehnologii folosite în rețelele de mare capacitate ………………………….. ………………………. 19
1.1. Evoluția rețelelor de mare capacitate ………………………….. ………………………….. …… 19
1.2. Tehnologia IP ………………………….. ………………………….. ………………………….. …………. 20
1.3. Rutarea în rețelele IP ………………………….. ………………………….. ………………………….. 21
1.3.1. Protocoalele de rutare IP ………………………….. ………………………….. ………………. 23
1.3.2. Limitările tehnologiei IP ………………………….. ………………………….. ……………….. 28
2. Rețele de tip MPLS ………………………….. ………………………….. ………………………….. …………. 29
2.1. Noțiuni generale ………………………….. ………………………….. ………………………….. …….. 29
2.2. Operarea MPLS ………………………….. ………………………….. ………………………….. …….. 30
2.2.1. Definiții și terminologie MPLS ………………………….. ………………………….. ………. 30
2.2.2. Elemente MPLS ………………………….. ………………………….. ………………………….. .. 33
2.2.3. Arhitectura unui nod MPLS ………………………….. ………………………….. …………. 36
2.3. Funcționarea MPLS ………………………….. ………………………….. ………………………….. .. 43
2.3.1. Faza de control ………………………….. ………………………….. ………………………….. … 43
2.3.2. Dirijarea pachetelor ………………………….. ………………………….. ……………………… 43
2.3.3. Operația LSR Packet – based ………………………….. ………………………….. ………… 44
2.3.4. Penultimate Hop Popping ………………………….. ………………………….. ……………… 45
2.4. Protocoale MPLS ………………………….. ………………………….. ………………………….. …… 46
3. Ingineria traficului în rețelele MPLS ………………………….. ………………………….. ……………. 57
3.1. Ingineria de trafic ………………………….. ………………………….. ………………………….. ….. 57
3.1.1. Necesitate ………………………….. ………………………….. ………………………….. …………. 57
3.1.2. Mod de lucru ………………………….. ………………………….. ………………………….. ……. 60
3.2. Protocolul IGP ………………………….. ………………………….. ………………………….. ……….. 61
3.3. Extensii OSPF ………………………….. ………………………….. ………………………….. ………… 62
3.4. Calcularea și stabilirea căii ………………………….. ………………………….. …………………. 63
3.4.1. Funcționalitate SPF ………………………….. ………………………….. ………………………. 63
3.4.2. Funcționalitate CSPF ………………………….. ………………………….. ……………………. 68

3.5. Protocolul de rezervare al resurselor RSVP ………………………….. ……………………… 73
3.5.1. Bazele RSVP ………………………….. ………………………….. ………………………….. ……. 73
3.5.2. Semnalizarea și operațiunile RSVP -TE ………………………….. ……………………… 74
3.5.3. Setarea și menținerea căii ………………………….. ………………………….. ……………… 78
3.5.4. Pachete RSVP ………………………….. ………………………….. ………………………….. ….. 80
3.5.5. Operații RSVP ………………………….. ………………………….. ………………………….. …. 83
3.6. Administrarea TE în MPLS ………………………….. ………………………….. ………………… 88
4. Calitatea serviciilor în rețelele MPLS ………………………….. ………………………….. …………… 97
4.1. Noțiuni generale ………………………….. ………………………….. ………………………….. …….. 97
4.2. Implementarea QoS ………………………….. ………………………….. ………………………….. .. 98
4.2.1. Modelele utilizate ………………………….. ………………………….. ………………………….. 98
4.2.2. Implementarea QoS prin MPLS ………………………….. ………………………….. ….. 104
4.3. Detectarea de erori MPLS ………………………….. ………………………….. …………………. 106
4.4. Protecția și recuperarea MPLS ………………………….. ………………………….. …………. 109
4.5. Mentenanța serviciilor de tip punct -la-punct și multipunct …………………………. 109
5. Simularea practică fol osind GNS3 ………………………….. ………………………….. ……………… 111
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …. 123
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. 125
Anexa 1. Codul Sur să ………………………….. ………………………….. ………………………….. …………… 127

Liѕtа fіgurіlоr

Figura 1. Arhitectura unei rețele complexe de comunicații actuale. ………………………….. …………. 19
Figura 2. Corespondența nivel OSI – protocoale de rețea ………………………….. ……………………….. 21
Figura 3. Protocoalele de rutare IGP și BGP într -o rețea largă ………………………….. ……………….. 24
Figur a 4. Topologia OSPF ………………………….. ………………………….. ………………………….. ………… 26
Figura 5. Stiva de protocoale ………………………….. ………………………….. ………………………….. …….. 30
Figura 6. Arhitectura unei rețele MPLS ………………………….. ………………………….. …………………… 32
Figura 7. LSP – Label Switched Path ………………………….. ………………………….. ………………………. 33
Figura 8. Domeniul MPLS ………………………….. ………………………….. ………………………….. ………… 34
Figura 9. Arhitectura Edge L SR ………………………….. ………………………….. ………………………….. … 35
Figura 10. Antet MPLS ………………………….. ………………………….. ………………………….. …………….. 37
Figura 11. Packet -Based LSR Operation with a Single Level Stack ………………………….. ………… 44
Figura 12. Operația LSR Packet -Based cu o stivă de etichete multinivel ………………………….. …. 45
Figura 13. Penultimate Hop Popping ………………………….. ………………………….. ………………………. 46
Figura 14. Descoperirea vecinilor ………………………….. ………………………….. ………………………….. . 50
Figura 15. Diagrama de stări și tranziții a LDP ………………………….. ………………………….. ………… 51
Figura 16. Modelul rut ării bazate pe constrângeri ………………………….. ………………………….. …….. 53
Figura 17. Dirijarea în rețele IP ………………………….. ………………………….. ………………………….. …. 58
Figura 18. Dirijarea cu ingineria traficului ………………………….. ………………………….. ………………. 59
Figura 19. O topologie simplă pentru a demonstra algoritmul SPF ………………………….. …………. 64
Figura 20. Rețeaua vazută de Routerul A dupa rularea algoritmului SPF ………………………….. …. 68
Figura 21. O topologie simplă ce demonstrează algoritmul CSPF ………………………….. …………… 69
Figura 22. O rețea simplă în care sunt necesare criterii de di ferențiere pentru CSPF …………….. 72
Figura 23. Mesajele RSVP Path și Reservation ………………………….. ………………………….. ………… 75
Figura 24. Mesajele de eroare RSVP ………………………….. ………………………….. ………………………. 76
Figura 25. Mesajul RSVP: PATH și RESV in timpul setarii căii LSP ………………………….. ……… 78
Figura 26. Formatul antetului RSVP ………………………….. ………………………….. ………………………. 80
Figura 27. Formatul obiectului RSVP ………………………….. ………………………….. …………………….. 81
Figura 28. Nevoia de Make -Before -Break ………………………….. ………………………….. ……………….. 84
Figura 29. Mesajele P ath și Resv sunt trimise independent ………………………….. …………………….. 86
Figura 30. Protecția căii ………………………….. ………………………….. ………………………….. ……………. 89
Figura 31. Elementele protecției locale ………………………….. ………………………….. …………………… 90
Figura 32. Protecția Link -ului ………………………….. ………………………….. ………………………….. ……. 91
Figura 33. Detecția eșecului folosind RSVP Hellos ………………………….. ………………………….. ….. 92
Figura 34. PathErr fară protecție locală ………………………….. ………………………….. …………………… 93
Figura 35. PathErr cu protecție locală ………………………….. ………………………….. …………………….. 94
Figura 36. PathTear în absența FRR ………………………….. ………………………….. ……………………….. 95
Figura 37. Arhitectura DiffServ ………………………….. ………………………….. ………………………….. .. 101
Figura 38. Funcționarea MPLS QoS ………………………….. ………………………….. ……………………… 105
Figura 39. ………………………….. ………………………….. ………………………….. ………………………….. …. 109

Figura 40. 10 Routere model C3600 ………………………….. ………………………….. ……………………… 111
Figura 41. ………………………….. ………………………….. ………………………….. ………………………….. …. 112
Figura 42. ………………………….. ………………………….. ………………………….. ………………………….. …. 113
Figura 43. ………………………….. ………………………….. ………………………….. ………………………….. …. 113
Figura 44. ………………………….. ………………………….. ………………………….. ………………………….. …. 115
Figura 45. ………………………….. ………………………….. ………………………….. ………………………….. …. 116
Figura 46. ………………………….. ………………………….. ………………………….. ………………………….. …. 117
Figura 47. ………………………….. ………………………….. ………………………….. ………………………….. …. 118
Figura 48. ………………………….. ………………………….. ………………………….. ………………………….. …. 118
Figura 49. ………………………….. ………………………….. ………………………….. ………………………….. …. 119

Lіѕtа tabelelor

Tabelul 1. Comparație tipuri de protocoale IP ………………………….. ………………………….. ………….. 27
Tabelul 2. Valori de etichetă rezervate ………………………….. ………………………….. ……………………. 37
Tabelul 3. ………………………….. ………………………….. ………………………….. ………………………….. …… 49
Tabelul 4. ………………………….. ………………………….. ………………………….. ………………………….. …… 63
Tabelul 5. Potrivirea claselor de planificare ………………………….. ………………………….. …………….. 64
Tabelul 6. Lista PATH și TENTE pentru Routerul A ………………………….. ………………………….. . 65
Tabelul 7. Listele PATH și TENTE pentru Routerul A după pasul 2 ………………………….. ………. 65
Tabelul 8. Listele PATH și TENTE pentru Router A după pasul 3 ………………………….. ………… 66
Tabelul 9. Listele PATH și TENTE pentru Routerul A după pasul 4 ………………………….. ……… 66
Tabelul 10 Listele PATH și TENTE pentru Routerul A după pasul 5 ………………………….. …….. 66
Tabelul 11. Listele PATH și TENTE pentru Routerul A după pasul 6 ………………………….. ……. 67
Tabelul 12 Listele PATH și TENTE pentru Routerul A după pasul 7: Lista TENTE este goală . 67
Tabelul 13. Tabel de rutare a Routerului A ………………………….. ………………………….. ……………… 67
Tabelul 14 Listele PATH și TENTE după pasul 1 ………………………….. ………………………….. ……. 70
Tabelul 15. Listele PATH și TENTE pentru Routerul A după pasul 2 ………………………….. …….. 70
Tabelul 16. Listele PATH și TENTE pentru Routerul A după pasul 3 ………………………….. …….. 70
Tabelul 17. Listele PATH și TENTE pentru Routerul A după pasul 4 ………………………….. …….. 71
Tabelul 18 Listele PATH și TENTE pentru routerul A după pasul 5 ………………………….. ……….. 71
Tabelul 19 Atributele celor cinci căi posibile de la RtrA la Rtr Z ………………………….. ……………. 72
Tabelul 20. Tipul mesajelor RSVP ………………………….. ………………………….. …………………………. 74
Tabelul 21. ………………………….. ………………………….. ………………………….. ………………………….. …. 77
Tabelul 22. Câmpurile din header -ul RSVP. ………………………….. ………………………….. ……………. 81
Tabelul 23. Formatul obiectului RSVP ………………………….. ………………………….. ……………………. 82
Tabelul 24. Clasele obiectului RSVP ………………………….. ………………………….. ………………………. 83
Tabelul 25. Obiectul RSVP C -Types ………………………….. ………………………….. ………………………. 83
Tabelul 26. Pasii în Make -Before -Break ………………………….. ………………………….. …………………. 85
Tabelul 27 Tipul mesajelor RSVP ………………………….. ………………………….. ………………………….. 88
Tabelul 28. Terminologia folosită în protecția locală ………………………….. ………………………….. … 90
Tabelul 29. Clase de trafic folosite în Diffserv ………………………….. ………………………….. ……….. 103
Tabelul 30. Y.1711 versus funcționalitatea ping/trace MPLS ………………………….. ……………….. 107

Lіѕtа асrоnіmеlоr

AF – Assured Forwarding
AS – Autonomous System
ATM – Asynchronous transfer mode
BA – Behavior aggregate
BGP – Border Ga teway Protocol
CoS – Class of Service
CR-LDP – Constraint Based Routing LDP
CS – Class Selector
CSPF – Constrained Shortest Path First
DiffServ – Differentiated Services
DSCP – Differentiated Services Code Point
EBGP – External BGP
ECMP – Equal Cost Multipath Protocol
EF – Expedited Forwarding
EIGRP – Enhanced Interior Gateway Routing Protocol
E-LSP – EXP -inferred -class LSP
FEC – Clasă de echivalență (Forwarding Equivalence Class)
FIB – Forwarding Information Base
FRR – Fast Reroute
IBGP – Interior BGP
IGP – Interior Gateway Protocol
IntServ – Integrated Services
IP – Internet Protocol
IPv4 – Internet Protocol version 4
Ipv6 – Internet Protocol version 6

IS-IS – Intermediate system to intermediate system
LDP – Label Distribution Protocol
LFIB – Label Forwarding Information Base
LIFO – Last Input First Output
L-LSP – Label -inferred -class LSP
LSP – Cale cu comutație de etichete (Label Switched Path)
LSR – Ruter comutator de etichete (Label Switch Router)
MF – Clasificator multicâmp
MP – Merge point
MPLS – Multiprotocol Label Switching
NHOP – Next Hop
NNHOP – Next -Next -Hop
OA – Ordered aggregate
OAM – Funcție de Operație, Administrare și Mentenanță
OSPF – Open Shortest Path First
PHB – Per Hop Behaviour
PHP – Penultimate Hop Popping
PIM – Protocol -Independent Multicast
PLR – Punct de reparație locală
QoS – Calitatea Servici ilor (Quality of Service)
RFC – Request for Comment
RIP – Routing Information Protocol
RSVP – Resource Reservation Protocol
RSVP -TE – Resource Reservati on Protocol -Traffic Engineering
SLA – Service Level Agreement
SLRG – Shared -Risk Link Groups
SPF – Shortest Path First
TCP – Transmission Control Protocol

TE – Ingineria traficului (Traffic Engineering)
TLV – Type -Length -Value
ToS – Type of Service
UDP – User Datagram Protocol
VoIP – Voice over IP
VPN – Virtual Private Network (R ețea virtuală privată)
WAN – Wide Area Network

Introducere

1. Tehnologii folosite în rețelele de mare capacitate

1.1. Evoluția rețelelor de mare capacitate

Noile rețele de date trebuie să asigure, pe lângă viteza de transmisie ridicată, banda largă,
managementul resurselor, scalabilitate și integrarea diverselor tehnologii de access (LAN,
HDSL, ADSL, TDM etc.). De aceea au apărut noi cerințe de performanță și de funcționalitate
pentru rețelele de date actuale.
Datorită faptului că resursele rețelelor de date sunt limitate, acestea trebuie gestionate cu
grijă pentru a obține performanțe și randamente ridicate.
Arhitecturile actuale țin seama de necesitățile de i ntegrare a diferitelor tehnologii de
access și de interoperabilitatea cu alte rețele de date. Arhitectura unei rețea de date de mare
viteză este structurată pe mai multe nivel e. Modelul actual al rețelelor este reprezentat în Figura
1.

CORE-ul
Retelei
„
` ` Nivelul Core
Nivelul de Distributie
Nivelul de AccesNivelul Optic
INTERNET

Figura 1 . Arhitectura unei rețele complexe de comunicații actuale.
După cum se observă, arhitectura rețelei este împărțită în patru nivele:

 Optic – este partea de rețea ce se situează la nivelul fizic al nivelului OSI. Acesta este
implementat prin diferite tehnologii de transmisie pe fibra optică, cum ar fi: SONET,
SDH, WDM, DWDM etc.
 Core (Nucleu) – se mai numește și backbone, reprezentând partea de rețea care se ocupă
în principal cu transmisia de date de mare viteză, fără a înde plini alte funcții de rețea
(access, agregare etc.).

 Distribuție – este partea de rețea în care se face agregarea (concentrarea) de trafic.
 Acces – acest nivel cuprinde echipamentele de rețea care se ocupă cu partea de acces a
diferitelor tehnologii de acc ess (HDSL, ADSL, TDM, ATM, IP, etc.).

Această împărțire pe nivele face mai ușoară gestionarea și proiectarea arhitecturilor
rețelelor de date, precum și migrarea către noi tehnologii prin etape de integrare pe nivele
funcționale.
Principalele caracteristi ci arhitecturale și de funcționalitate ale unei rețele moderne sunt:
 Structurare pe nivele arhitecturale.
 Funcționalități împărțite pe nivele structurale ( ex. în punctul de access se face
autorizarea, stabilire QoS, în distribution se face agregare, în co re se face transport
etc.).
 Management centralizat.
 Ingineria traficului (stabilirea căilor de rutare) care se face prin managementul
centralizat.
 Integrarea a cât mai multe tehnologii de access.
 Conexiune cu rețeaua PSTN (Public Switched Telephone Network ).
 Migrarea către o rețea de date universale (Date, voce, video, video -on-demand
etc.).
 Migrarea traficului de voce către rețelele NGN (Next Generation Networks) ,
centralele digitale actuale sunt înlocuite cu echipamente de date hardware și
software perfe ct integrate în rețea.
 Scalabilitate, performanță, disponibilitate totală (99%).

1.2. Tehnologia IP

Tehnologia IP este tehnologia cea mai răspândită la ora actuală în rețelele LAN. Ea este o
tehnologie de Layer 3 bazată pe protocolul IP (Internet Protocol) ca re are ca scop adresare a,
respectiv controlul informației ce permite pachetelor de date să fie rutate. Protocolul IP este un
protocol bazat pe transmisia de pachete între diferite calculatoare din rețea. Protocolul suportă
adresare, fragmentare , reasamblare și multiplex are de protocol. Este protocolul pe baza căruia s –
au construit celelalte protocoale IP, așa – numita suită de protocoale TCP/IP. (TCP, UDP, ICMP,
ARP, RARP, etc.).
În Figura 2. este reprezentată corespondența diferitelor protocoale și nivelul OSI:

Figura 2. Corespondența nivel OSI – protocoale de rețea

1.3. Rutarea în rețelele IP

Rutarea poate fi statică sau dinamică. Aceasta implică determinarea căii de rutare, care se
poate face după anumite valori metrice (întâr zieri, costuri, utilizarea căii etc.). Rutar ea se face
după o tabelă de rutare care specifică interfețele și adresele către care trebuie trimise pachetele.
Router -ele sunt echipamente ce lucrează la nivelul al treilea OSI. Acestea sunt folosite
pentru schimbul de informație dintr -un grup de rețele c e aparțin aceleiași autorită ți de control și
administrative , cât și pentru schimbul de informație între AS -uri.
Regula generală de trimitere a pachetelor este alegerea rutei care se potrivește cât mai
exact.
De exemplu:
Destinație Masc ă Ruter de ieșire
10. 1. 4. 0 255.255.255. 0 R2
10. 1. 0. 0 255.255. 0. 0 R3
Destinația 10.1.4.30 s e potrivește în ambele cazuri, insă gateway -ul R2 are mască de rețea
mai restrictivă, deci va fi aleasă această cale.

A. Rutarea cu vectori -distanță

Rutarea se poate baza pe algoritmi cu vectori -distanță (numiți și algoritmi Bellman -Ford),
care fac ca ruterele să paseze periodic copii ale tabelelor de rutare vecinilor cei mai apropiați din
rețea. Fiecare destinatar adaugă la tabelă un vector -distanță (propria "valoare" distanță) și o
expediază vecinilor săi cei mai apropiați. Acest proces se desfășoară în toate direcțiile în tre
routerele aflate în imediata vecinătate.

Acest proces pas -cu-pas face ca fiecare router s ă afle informații despre celelalte routere și
să-și dezvolte o perspectivă cumulativă asupra "distanțelor" rețelei. De exemplu, un protocol
timpuriu de rutare este Routing Information Protocol (protocol de ru tare a informațiilor), sau
RIP. Acesta utilizează două unități de măsură pentru distanțe ca să determine cea mai bună cale
următoare pentru orice pachet. Aceste unități de măsură pentru distanță, tacturile și hopurile, sunt
dependente de timp.
Tabela cumu lativă este apoi utilizată pentru actualizarea tabelelor de rutare ale fiecărui
router. La finalul procesului, fiecare router a aflat niste informații vagi despre distanțele până la
resursele din rețea. El nu a aflat nimic specific despre alte routere sau despre topologia reală a
rețelei.
Această abordare poate, în anumite circumstanțe, să creeze probleme de rutare pentru
protocoalele bazate pe vectori -distanță. De exemplu, în urma unei căderi în rețea este necesar
ceva timp pentru ca routerele să convearg ă spre o nouă înțelegere a topologiei rețelei. În timpul
acestui proces, rețeaua ar putea fi vulnerabilă la rutări contradictorii și chiar la bucle infinite.
Anumite măsuri de siguranță ar putea să micșoreze aceste riscuri, dar rămâne faptul că
performanț a rețelei 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.

B. Rutarea cu starea legăturilor

Algoritmii de rutare folosi nd starea legăturilor (link -state routing algorithm), cunoscuți
colectiv ca protocoale cu preferarea drumului minim (SPF), mențin o bază de date complexă a
topologiei rețelei. Spre deosebire de protocoalele cu vectori -distanță, cele folosind starea
legătur ilor dezvoltă și întrețin o cunoaștere completă a routerelor de rețea, ca și a felului cum
sunt interconectate acestea.
Această cunoaștere este realizată prin schimbarea de pachete cu starea legăturilor (LSP)
cu alte routere conectate direct. Fiecare route r care a schimbat LSP -uri constru iește apoi o bază
de date logică utiliz ând toate LSP -urile primite. Este utilizat apoi un algoritm "cu preferarea
drumului liber", pentru a calcula cât de accesibile sunt destinațiile legate de rețea. Această
informație est e utilizată pentru a actualiza tabela de rutare. Acest proces este capabil să
descopere modificările topologiei rețelei, care ar putea fi cauzate de căderea unei componente
sau de mărirea rețelei. De fapt, schimbul de LSP -uri este declanșat de un eveniment din rețea, nu
este realizat periodic.
Rutarea cu starea legăturilor are două zone parțiale de risc. Mai întâi, în timpul procesului
inițial de descoperire, rutarea cu starea legăturilor poate acapara mediile de transmisie ale rețelei,
reducând astfel în m od semnificativ capacitatea rețelei de a transporta date. Această degradare a
performanței este temporară, dar foarte evidentă.
A doua problemă potențială este că rutarea cu starea legăturilor solicită intens memoria și
procesorul. Din această cauză, rout erele configurate pentru rutare cu starea legătulilor sunt în
general mai scumpe.

C. Rutarea hibridă

Ultima formă de rutare dinamică este hibridizarea. Deși există protocoale hibride
deschise, echilibrate, această formă este asociată aproape exclusiv crea ției brevetate a unei
singure companii, Cisco Systems Inc. Acest protocol, EIGRP, a fost proiectat combinând cele
mai bune aspecte ale protocoalelor cu vectori -distanță și cu starea legăturilor, fără limitările de
performanță sau dezavantajele lor.
Protoc oalele de rutare hibride echilibrate, utilizează unități de măsură vectori -ditanță, dar
realizează măsurători mult mai precise decât protocoalele cu vectori -distanță convenționale. De
asemenea, ele converg mult mai rapid decât acestea din urmă, dar evită s uprasarcinile și
actualizările cu starea legăturilor. Hibrizii echilibrați nu sunt periodici, ci conduși de evenimente,
conservând astfel lărgimea de bandă pentru aplicații reale.

1.3.1. Protocoalele de rutare IP

Algoritmii de rutare pot fi împărțiți în două g rupe:
 Interior Gateway Protocol (IGP) – folosit la rutarea în interiorul unei
organizații. Din această categorie fac parte următoarele protocoale de rutare: RIP
(Routing Information Protocol) – folosit în special în rețelele mici, OSPF (Open
Shortest Path First) – cel mai des folosit protocol în rețelele 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
organizații sau Sisteme Autonome (AS).
În Figura 3. este reprezentată situarea celor două tipuri de protocoa le de rutare într -o rețea
largă.

AS 1
AS 2AS 3
BGPBGP
IGPIGP
IGP
Figura 3. Protocoalele de rutare IGP și BGP înt r-o rețea largă

A. Protocolul RIP (Routing Information Protocol)

RIP este un protocol de rutare intra -domeniu bazat pe distanța vectorială dintre hopuri.
Este folosit în toate router -ele actuale. Folosește trei tipuri de temporizări în alcătuirea tabelei de
rutare:
 Actualizarea rutelor (se face automat la un interval de 30 de secunde )
 Expirarea validității rutei
 Curățirea tabelei de rutare

RIP versiunea 1
Specificația originală de RIP a fost definit ă în RFC 1058 (Iunie 1988) și utiliza rutarea pe
baza adresăr ii "classfull". Prin urmare, actualizările periodice, nu includeau și informația de
subrețea specifice VLSM, astfel era necesar ca subrețelele existente sa fie toate de aceeași
dimensiune. Totodată nu exista suport pentru autentificarea routerelor făcându -l vulnerabil
atacurilor asupra rețelei.

RIP versiunea 2
Problemele specifice RIPv2 au fost corectate în RFC 1388 (1993) ulterior fiind
standardizate sub denumirea RIPv2 (STD56). Astfel, este posibila transmiterea și a informației
de subrețea suportând ast fel adresarea CIDR (Classless InterDomain Routing). Limita maxima
de 15 rute a fost menținuta în ideea păstrării compatibilității cu versiunea anterioara. Pentru a
evita încărcarea inutila a gazdelor ce nu sunt implicate în procesul de rutare, routerele ce au

implementat protocolul RIPv2 vor transmite tabela de rutare doar routerelor adiacente utilizând o
adresa de tip multicast, 224.0.0.9, spre deosebire de RIPv1 ce utiliza o adresare de
tip broadcast (adresate tuturor nodurilor din rețea).
RIP are urmatoa rele caracteristici de baza:
 RIP este un protocol al vectorului de distanta
 RIP foloseste hop count ca unica metrica pentru selectarea caii
 Routerele cunoscute cu hop count mai mare de 15 inaccesibile
 Mesajele suntr trimise prin broadcast la fiecare 30 de secunde
Principalele probleme ale protocolului RIP sunt:
 limitarea numărului maxim de hopuri la 15
 propagarea informației în rețelele mari este lenta
 traficul RIP crește rapid odată cu mărirea rețelei

Protocolul RIP poate opera în 3 moduri:
 Activ – trimite și recepționează informații de rutare
 Silent – doar asc ultă și primește informații de rutare (nu trimite nimic)
 Deaf – doar trimite informații de rutare (nu primește).

B. Protocolul OSFP (Open Shortest Path First)

OSPF este un protocol bazat pe verificarea stării link -urilor, ruterele trimit informații
despre s tarea link -ului în locul informațiilor despre propriile tabele de rutare. Acest protocol
împarte rețeaua în zone pentru a putea lucra în rețele mari.
AS 2
IGP
Aria 1 Aria 2 Aria 0
(backbone area)
Aria 1
OSPF este folosit in interiorul sistemelor autonomeAS 1OSPF
OSPFBGPAria 0
(backbone area)
Routere de
backbone
Routere
interioareRouter border
(de arie)

Figura 4. Topologia OSPF
Router -ele interne trebuie să știe doar rutele cătr e rețelele din aria lor și către aria de
backbone. Ele schimbă între ele informații despre starea link -urilor. Fiecare router cunoaște
topologia și costul pentru comunicația cu rețelele din aria lui.[18]
Border Router -ele de arie schimbă informații 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ă informații cu alte
routere de backbone din aria „0" și calculează ultimul cost al rutei dintre arii sau alt sistem
autonom.
Protocolul OSPF folosește cinci tipuri de mesaje:
 Hello – folosit pentru a descoperi vecinii și pentru a delega un router dedicat
precum și pentru a v erifica starea link -ului
 Database Description – descrie baza de date a topologiei link -ului
 Link State Request – cerere de părți din topologia routerelor adiacente
 Link State Update – trimite date despre starea link -urilor către routerele vecine
 Link State ACK – confirmarea recepționării 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 ac eeași 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 obține informații identice despre topologie. Fiecar e
revizuire de informație în legătură cu starea link -urilor are un număr de ordine pentru a se putea
determina dacă revizuirea este nouă.
În OSPF routerele pot schimba între ele pe lângă informația despre starea link -urilor și
informații despre:

 Întârzier e
 banda disponibilă
 siguranța link -ului

Aceste informații sunt folosite de routere în momentul în care trimit pachete cu câmpul
ToS setat la o anumită valoare.

C. Protocolul EIGRP (Enhanced Interior Gateway Routing Protocol)

EIGRP a fost dezvoltat de căt re Cisco (eliberat în 1988) cu scopul de a îmbunătăți
protocolul RIP pe vremea cînd IETF încă lucra la dezvoltarea OSPF -ului. EIGRP este un

protocol brevetat. Acest protocol elimină unele dintre defectele protocolului RIP și are
îmbunătățiri ca folosirea de metrici compuse, rutarea pe căi multiple și mînuirea rutelor
implicite.
Evoluția protocolului EIGRP furnizează compatibilitate și operații precise cu rutere
EIGRP . Capacități cheie care disting EIGRP de alte protocoale de rutare includ convergența
rapidă, suport pentru mască de subrețea variable -length , suport pentru update, și suport pentru
multiple network layer protocols.
EIGRP are toate avantajele flexibilității și ale configurării simple în timp ce
îmbunătățește viteza și consumarea resurselor. De altfel, este capabil a fi un protocol unic atît
pentru IP cît și pentru protocoale non -IP , eliminînd nevoia de a folosi multiple protocoale de
rutare într -o rețea multi -protocol.
Acest protocol de rutare este unul dintre cele mai diversificate și robu ste protocoale de
rutare. Combinația sa unica de caracteristici îmbină cele mai bune atribute ale protocoalelor de
vector -distanță cu cele mai bune atribute ale protocoalelor cu starea legăturilor. Rezulatul este un
protocol de rutare hibrid care sfidează împărțirea pe categorii a protocoalelor convenționale.
Poate fi folosit împreunpă cu IPv4, AppleTalk, și IPX. Mai im portant, arhitectura sa
modulară va permite ca Cisco să adauge suport pentru alte protocoale de rutare importante care
vor apărea în vi itor. 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,
folosește un mecanism de descoperire/recuperare pentru a se asigura că vecinii su nt conștienți de
accesibilatea fiecaruia in parte.

Tabelul 1. Comparație tipuri de protocoale IP

D. Protocolul BGP (Border Gateway Protocol)

BGP – ul este singurul protocol de rutare între Sisteme Auton ome, în principal este
folosit în ruterele de backbone pentru a schimba informația între AS -uri, dar poate fi folosit și în
interiorul AS -ului pentru a schimba informație de rutare ( IBGP). A fost proiectat să detecteze
buclele și să folosească informația metrică pentru a lua decizii de rutare inteligente. Protocol RIP OSPF IGRP EIGRP
Tipul Vectori
distan ță Starea
legăturilor Vectori distan ță Vectori distan ță
Timpul de
convergen ță Încet Rapid Încet Rapid
VLSM Nu Da Nu Da
Consum de
bandă Ridicat Scăzut Ridicat Scăzut
Suport cai
multiple Nu Da Da Da
Scalabilitate Nu Da Da Da
Protocol Non -IP Nu Nu Nu Da

Traficul dintr -un AS trebuie să treacă printr -un gateway router, AS selectează care router
va îndeplini această funcție.

1.3.2. Limitările tehnologiei IP

Principalele limitări ale tehnologiei IP sunt:
 Nu asig ură un QoS pur deoarece este o tehnologie bazată pe principiul de împărțire a
mediului fizic „media sharing", aplicându -se conceptul „Best Effort" în politica de trafic.
 Mecanismul de rutare este un mecanism care se bazează pe conceptul „cea mai mare
potri vire" și acest lucru duce la întârzieri în mecanismul de rutare și trimitere de pachete.
 Putere mare de calcul, lucru care duce la limitări în puterea de procesare a backbone –
urilor
 Header -ul pachetului IP este mare și complex, ceea ce duce la o proastă ut ilizare 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.

2. Rețele de tip MPLS

2.1. Noțiuni generale

MPLS reprezintă o metodă îmbunătățită de îndrumare a pachetelor printr -o rețea folosind
informația conținută în etichetele atașate antetului MPLS., care este inserat între antetul de nivel
3 și antetul de nivel 2 în cazul utilizarii tehnologiei MPLS
MPLS c ombină tehnologii de comutare de nivel 2 cu tehnologii de rutare de nivel 3.
Principalul obiectiv al MPLS este să creeze o rețea flexibilă care să asigure performanță si
stabilitate sporite. Aceasta include funcționalități ca ingineria traficului și VPN, c are oferă
calitatea serviciilor (QoS) cu clase de servicii multiple (CoS).
Termenul multiprotocol indică faptul că tehnicile MPLS sunt aplicabile pentru diverse
protocoale utilizate la nivel 2.
MPLS este o tehnologie de comutație de pachete orientată pe c onexiune, adecvată
implementării mecanismului DiffServ. De asemenea MPLS permite realizarea de căi numite
LSP care permit realizarea rutării explicite. Acesta folosește comutația de etichete pentru a seta
circuite virtuale în rețelele bazate pe IP. MPLS p ermite o rutare bazată pe destinație, dar poate fi
folosit și un mecanism de rutare explicită și de setare trunchiurilor pe baza obiectivelor
ingineriei traficului (TE).
Tehnica folosită de MPLS este comutația de etichete. O etichetă de lungime fixă este
codată într -un antet MPLS și este folosită pentru îndrumarea pachetelor. Când un LSR (Label
Switch Router) recepționează un pachet etichetat, el folosește eticheta ca index la un tabel de
rutare din care citește adresa următorului hop și eticheta care se v a atașa pachetului transmis de
router, necesară următorului hop. Calea prin care vor fi rutate pachetele este setată anterior
transmiterii fluxurilor și este folosită pentru îndrumare prin comutarea etichetelor
Încă de la existența ARPANET, predecesorul In ternetului actual, arhitectura Internetului
a fost în permanentă schimbare. A evoluat pe măsură ce a evoluat și tehnologia, și au apărut noi
servicii. Cea mai recentă schimbare a arhitecturii Internet este adăugarea MPLS.
MPLS este plasat între nivelele 2 (Link) și 3 (Network) ale arhitecturii stivei de
protocoale.

Figura 5. Stiva de protocoale
MPLS a influențat atît mecanismul de dirijare al Internetului cît și determinarea căii
(calea pe care ar trebui să o urmeze pachetele ). Aceasta a dus la o nouă arhitectură a
internetului.
MPLS poate simplifica utilizarea IPv6 pentru că algoritmii de dirijare folosiți de MPLS
pentru IPv4 pot fi aplicați și pentru IPv6 folosind protocoale de rutare care suportă adrese IPv6.
MPLS este utilizat pentru că are un bene ficiu imediat și major asupra Internetului.
Un beneficiu MPLS din punctul de vedere al rețelei backbone a unui furnizor de servicii
de internet este abilitatea de a realiza ingineria traficului. Ingineria traficului permite
furnizorului de servicii să eli bereze linkurile congestionate și să împartă traficul pe linkuri
subutilizate. Aceasta implică un grad mai mare de utilizare a resurselor care se traduce în
eficiență și salvări de costuri.
Într-o rețea MPLS, la intrare pachetelor le este asignată o etiche tă de către un Ruter de
graniță cu comutatie de etichete (Edge Label -Switched Router). Pachetele sunt îndrumate de -a-
lungul unei căi cu comutație de etichete LSP (Label -Switched Path) în care fiecare LSR ia
decizii de îndrumare numai pe baza etichetei. La fiecare hop , LSR comută eticheta existentă cu
una nouă, pe baza căreia următorul hop îndrumează pachetul. Eticheta este înlăturată de către
LSR de graniță, iar pachetul este îndrumat către destinație.

2.2. Operarea MPLS

2.2.1. Definiții și terminologie MPLS

• Dom eniul MPLS („MPLS domain”) – portiune dintr -o retea în care dirijarea
pachetelor se face prin MPLS si care este inclus într -un singur sistem administrativ (AS) sau de
rutare
• Flux de date („flow”) – o instantiere unica a secventei de pachete de date dintr e doua
aplicatii; uzual, un flux se poate identifica la nivelul patru prin multipletul { ( adresa_port, adresa
IP)src, ( adresa_port, adresa IP)dst, protocol de transport }
• Clasa de echivalenta din punct de vedere al dirijarii (FEC – “Forwarding
Equivale nce Class”) – clasa asociata unui un grup de pachete IP care sunt dirijate de -a lungul
aceleiasi rute (si impun aceeasi tratare din punct de vedere al calitatii serviciului)
• Eticheta MPLS (“MPLS Label”)
 identificator cu lungime fixa (32 biti) amplasat în aintea antetului IP
 are semnificație locala pe un link între două comutatoare MPLS
 codifică un FEC
• Comutatie de etichete (“label swap”) – operatie de baza în MPLS, reprezentând
modificarea etichetei la traversarea unui comutator MPLS
• Nod MPLS („MPLS node”) – un nod ce ru leaza MPLS, adica :

 cunoaste protocoalele de control MPLS pentru distributia etichetelor
 ruleaza unul sau mai multe tipuri de protocoale de rutare
 capabil sa dirijeze pachete pe baza de eticheta MPLS (dar poate optional dirija si
pachete clasice I P)
• Nod MPLS de frontiera (“MPLS edge node”) – leaga un domeniu MPLS cu un
domeniu non -MPLS sau cu un alt domeniu MPLS. Pot fi de doua tipuri : de i ntrare („ingress”) si
de iesire („egress”)
• Ruter comutator de etichete (LSR – “Label Switched Router”) – nod MPLS de nivel
3 capabil sa comute etichete dar si sa dirijeze pachete folosind un mecanism traditional de nivel
L3
• Cale cu comutatie de etichete (LSP – “Label Switched Path”) – canal virtual ce
traverseaza mai multe LSR, pe un anumit nivel în ierar hia de etichete MPLS; pachetele ce
apartin unui FECi urmeaza prin retea aceeasi LSP
• Stiva de etichete (“label stack”) – structura de date de tip stiva (LIFO – Last Input
FirstOutput ) folosita pentru atunci când se lucreaza cu mai multe nivele de etichete în dirijarea
MPLS ierarhizata (domenii MPLS incluse unele în altele)
• Protocol de distributie a etichetelor (LDP – Label Distribution Protocol) – protocol
de comunicare si distributie a etichetelor si a semnificatiilor acestora între LSR (lucreaza în
colaborare cu protocoalele de rutare: RIP, OSPF, BGP, IS -IS, EIGRP).

Rețelele MPLS folosesc etichete pentru a îndruma pachetele. Nodul MPLS de intrare
asignează o singură dată un pachet unei Clase de echivalență (FEC) , atunci când pachetul intră
în rețea.
FEC reprezintă un set de pachete de nivel 3 care sunt îndrumate în a celași mod , pe
aceeași cale cu aceleași tratamente de îndrumare. Pentru a atribui un pachet unui FEC , routerul
poate ține cont de antetul IP și alte informații cum ar fi interfața pe care a fost primit pachetul.
FEC poate asigura o granularitate sporit ă a îndrumării pe baza cantității de informație folosită
pentru stabilirea echivalenței.
FEC-ul căruia îi este atribuit pachetul este codificat ca o valoare scurtă fixă cunoscută ca
etichetă. Pachetele sunt etichetate înainte de a fi trimise mai departe. L a nodurile următoare, nu
mai este nevoie de o analiză a antetului de nivel rețea al pachetului. Eticheta este folosită ca un
index într -o tabelă, care specifică nodul următor, și o nouă etichetă. Vechea etichetă este
înlocuită cu o nouă etichetă , și pach etul este trimis către următorul nod.
In rețelele MPLS, dirijarea pachetelor este făcută pe baza etichetelor. Aceasta implică o
serie de avantaje față de îndrumarea tradițională bazată pe nivelul rețea:
 Dirijarea MPLS poate fi realizată de comutatoare care pot analiza etichetele dar nu
pot însă analiza antetele de nivel rețea
 Un pachet este asignat unui FEC atunci când intră în rețea. Routerul de intrare
poate folosi orice informație are despre pachet , cum ar fi portul de intrare sau interfața, chiar
dacă această informație nu este obținută din antetul de nivel rețea. Un pachet care intră în rețea
printr -un anume router poate fi etichetat diferit față de același pachet în cazul în care ar intra în

rețea printr -un alt router. În consecință, deciziile de în drumare care depind de routerul de intrare
pot fi luate cu ușurință. Acest lucru nu poate fi realizat în dirijarea IP tradițipnală deoarece
identitatea routerului de intrare a pachetului nu călătorește cu pachetul.
 În rețelele cu ingineria traficului, pach etele sunt forțate să urmeze o anumită rută ,
cum ar fi o rută subutilizată. Această rută este aleasă atunci când sau înainte ca pachetul să intre
în rețea , și nu este selectată pe baza algoritmilor dinamici de rutare pe măsură ce pachetul
traversează reț eaua. În MPLS eticheta poate constitui o rută, deci identitatea rutei explicite
trebuie să fie purtată de pachet. Această functionalitate constituie baza ingineriei traficului în
MPLS
 Clasa de servicii a unui pachet poate fi determinată de nodul MPLS de in trare. Un
nod MPLS de intrare poate aplica apoi diferite praguri de aruncare și mecanisme de planificare
pentru a aplica politici pe diferite pachete. Nodurile următoare pot forța respectarea acestor
politici prin folosirea unui set de comportamente per n od (PHB -Per Hop Behaviours). MPLS
permite (dar nu cere) ca precedența sau clasa de servicii să fie parțial sau total deduse din
etichetă. În acest caz eticheta reprezintă o combinație între FEC și o precedență sau clasă de
servicii. Această funcționalitate reprezintă baza MPLS QoS.

Figura 6. Arhitectura unei rețele MPLS

În Figura 6. este prezentată o rețea MPLS care conține noduri de graniță (Edge: R 1, R4) și
rutere core (R 2, R3).

2.2.2. Elemente MPLS

A. LSP (Label Switched Path) – cale cu comutație de etichet e

În rețelele MPLS , o cale cu comutație de etichete este o cale prin rețeaua MPLS, setată
prin intermediul unui protocol de semnalizare cum ar fi LDP, RSVP -TE, BGP sau CR-LDP .
Calea este stabilită pe baza criteriulu i din FEC.

Figura 7. LSP – Label Switched Path
O cale LSP este unidirecțională, nodul care transmite pachete este numit upstream (ex.
LSR A), iar nodul care receptioneaza pachetul este numit downstream (ex. LSR B este
downstream pentru LSR A).
Calea înc epe la un Edge Label Switching Router , care decide ce etichetă să aplice
pachetului, apoi acesta trimite pachetul către următorul ruter din cale care înlocuiește etiche ta
pachetului cu o altă etichetă de ieșire și transmite pachetul mai departe următorului ruter. Ultimul
ruter din cale înlătură eticheta și dirijează pachetul pe baza antetului nivelului următor, de
exemplu IPv4. Datorită faptului că dirijarea pachetelor p rintr-un tunel LSP este opacă pentru
celelalte nivele superioare , o cale LSP poate fi numită și tunel MPLS.
Ruterul care adaugă prima etichetă pachetului se unmește ingress router, ultimul ruter ,
cel care înlătură eticheta se numește egress ruter, iar ce lelalte rutere care doar comută etichetele
se numesc rutere de tranzit sau Label Switching Router (LSRs).
Atunci când este necesară protejarea căilor, LSP -urile pot fi :
 Primare (cele folosite working)
 Secundare (de rezervă backup)
 Terțiare

B. LSR – Ruter comutator de etichete

LSR este un dispozitiv care în primul rând dirijează pachetele pe baza etichetei.

Figura 8. Domeniu l MPLS
LSR este un dispozit iv care implementează componentele MPLS de control și de dirijare.
LSR dirijează pachetele pe baza valorii unui etichete încapsulate în pachet, LSR poate de
asemenea să dirijeze pachete native de nivel 3.
LSR de graniță(edge) este un dispozitiv a cărui f uncționalitate principală este asignarea
sau înlăturarea etichetelor pachetelor, acestea sunt localizate la granița unei rețele MPLS.
Adăugarea etichetelor unui pachet se numește acțiune de push, iar înlăturarea unei etichete se
numește pop.
Acțiunile pe c are le poate efectua un LSR sunt:
 Agregare – înlătură eticheta din vârful stivei și realizează căutarea după adresa de nivel
3
 Pop – înlătură eticheta din vârful stivei și transmite restul pachteului fie ca pe un
pachet etichetat fie unul neetichetat
 Push – înlocuiește eticheta din vârful stivei cu un set de etichete
 Swap – înlocuiește eticheta din vârful stivei cu altă valoare
 Untag – înlătură eticheta și dirijează pachetul IP către următorul hop IP specificat.

Figura 9. Arhitectura Edge LSR
Următoarele combinații sunt posibile :
 Un pachet IP recepționat este este dirijat pe baza adresei IP destinație și transmis ca
un pachet IP
 Un pachet IP este dirijat pe baza adresei IP destinație și transmis ca un pachet
etichetat
 Un pachet etichetat recepționat este dirijat pe baza etichetei ; ethicheta este schimbată
și pachetul este transmis
LSR și Edge LSR sunt de obicei capabile să realizeze atât comutație de etichete cât și
rutare IP. Numele lor se bazează pe poziția acestora în domeniul MPLS. Ruterele configurat e
pentru a folosi MPLS sunt numite LSR pentru că ele dirijează în principiu pachete etichetate.
Orice tip de LSR trebuie să realizeze următoarele funcțiuni:
 Să schimbe informații de rutare de nivel 3
 Să schimbe etichete(control plane)
 Să dirijeze pachete s au celule (data plane)
 MPLS frame -mode dirijează pachete pe baza etichetei de 32 de biți
 MPLS cell -mode etichetează pachetele pe baza etichetele codificate în câmpurile
VCI/VPI din antetul ATM
Planul de date realizează următoarele funcțiuni :
 Schimbă infor mații de rutare indiferent de tipul LSR
 Schimbă etichete în concordanță cu tipul MPLS (cell -mode sau frame -mode)

Edge LSR
Acestea pot fi de intrare (ingress) sau de ieșire(egress) din rețeaua MPLS .
La intrarea într -un domeniu MPLS , ruterele ingres s acceptă pachete neetichetate și
crează un antet MPLS prin introducerea (pushing) unuia sau mai multor câmpuri de etichete în
antetul MPLS.
La ieșirea din domeniul MPLS , egress LSR termină o cale LSP prin extragerea
elementului din vârful stivei (poppin g) de etichete și îndrumarea pe baza regulilor de îndrumare
clasică.

C. LDP – Label Distribution Protocol

Pachetele clienților sunt transmise prin calea LSP, care trebuie setată anterior pornirii
transmisiei datelor.
Un protocol de distribuție de etichete e ste un set de proceduri prin care două LSR
schimbă informații de mapare etichete și capabilități MPLS.
LDP setează starea LSPs din rețea. LDP mai este numit și protocol de semnalizare pentru
rețelele MPLS.

2.2.3. Arhitectura unui nod MPLS

Nodurile MPLS au două planuri arhitecturale: Planul MPLS de date și Planul MPLS de
control. Nodurile MPLS pot efectua rutare de nivel 3 si comutare de nivel 2 pe lângă comutarea
pachetelor etichetate .În figura 1.6. este prezentată arhitectura de bază a unui nod MPLS .

A. Planul de Date

Planul MPLS de date se ocupă cu dirijarea pachetelor pe baza valorilor conținute de
etichetele atașate. Planul de dirijare folosește o bază de informații de dirijare a etichetelor(LFIB –
Label Forwarding Information Base) menținută de nodurile MPLS pentru a dirija pachetele
etichetate. Algoritmul folosit de componenta de dirijare și comutare a etichetelor folosește atât
informația conținută în LFIB cât și informația conținută de etichetă.
Fiecare nod MPLS menține 2 tabele relevante pentru dirijare a MPLS : baza de informații
despre etichete (LIB -Label Information Base) și LFIB. LIB conține toate etichetele atribuite de
către nodul MPLS local și relaționarea acestora cu etichetele primite de la vecinii săi MPLS.
LFIB folosește un subset din etichetel e conținute în LIB pentru îndrumarea propriu -zisă a
pachetelor.

B. Eticheta MPLS

O etichetă este un identificator de lungime fixă de 32 de biți care este folosit pentru a
identifica un FEC, de obicei de importanță locală. Eticheta, care este atașată unui anume pachet,
reprezintă FEC -ul căreia i -a fost atrbuit pachetul.
Tehnologiile de nivel 2 cu m ar fi Ethernet, Inel cu jeton, FDDI și legăturile capăt la capăt
nu pot folosi câmpurile adreselor sale de nivel 2 pentru a purta etichete. Aceste tehnologii poar tă
etichetele în antete shim (inserție). Antetul etichetei shim este inserat între nivelul legătură de
date și nivelul rețea. Utilizarea antetului etichetei shim permite MPLS să suporte majoritatea
tehnologiilor de nivel 2.

Figura 10. Antet MPLS
Pentru a suporta antete shim trebuie ca routerul emițător să aibă o modalitate de a indica
routerului receptor existența unui antet shim în cadru.
Eticheta MPLS conține următoarele câmpuri :
Câmpul Label= etichetei (20 biți) – conține valoarea propriu -zisă a etic hetei MPLS.

Label(etichetă) Descriere
0,2 Această etichetă este permisă numai la baza stivei. Indică faptul că eticheta
trebuie să fie extrasă din stivă (pop), și că decizia de dirijare trebuie să se facă
pe baza adresei IPv4, respectiv IPv6
1 În acest caz decizia de dirijare se ia pe baza etichetei
3 Această etichetă poate fi folosită de un nod MPLS dar nu apare niciodată în
încapsulare.Aceasta este folosită la extragerea etichetei de către penultimul
hop.
4-15 Rezervate pentru utilizări ulterioare
Tabelul 2. Valori de etichetă rezervate
Eticheta MPLS conține următoarele câmpuri :
 Câmpul Label= etichetei (20 biți) – conține valoarea propriu -zisă a etichetei MPLS.
 Câmpul EXP folosit pentru CoS (Class of Service) (3 biți) – influențează algoritmii de
aranjare în coadă și de aruncare a pachetului pe măsură ce traversează rețeaua.
 Câmpul stivei (1 bit) – suportă o stivă ierarhică de etichete.

 Câmpul TTL (time -to-live) (8 biți) – oferă funcționalitatea IP TTL tradițională.

În rutarea IP tradițională, orice pa chet poartă în antetul său o valoarea TTL, de fiecare
dată când un pachet traversează un nod al rețelei, valoarea TTL este decrementată cu o unitate;
dacă TTL ajunge la valoarea 0 înainte ca pachetul să ajungă la destinație, acesta este eliminat.
Astfel se asigură un mecanism de protecție împotriva buclelor de îndrumare. Acest mecanism de
control este folosit și în MPLS.

C. Stiva de etichete

Bitul stivă implementează stiva de etichete MPLS, în care mai mult de un antet de
etichetă este atașat unui singur pac het IP.Bitul l stivă este setat 1 pentru a indica ultimul element
al stivei.
Un pachet poate avea mai multe etichete organizate ca o listă LIFO(Last Input First
Output), care este o stivă de etichete de tipul „ultimul intrat -primul ieșit”.
Deși MPLS -ul sup ortă o ierarhizare, procesarea unui pachet etichetat este complet
independentă de nivelul ierarhic al stivei. Procesarea va fi întotdeauna bazată pe eticheta din
capătul stivei, fără a se ține cont de celelalte etichete din stivă.
Stiva de etichete se folo sește pentru a suporta formarea de tunele incluse în alte tunele
(nested tunnels).
O cale LSP poate avea o altă cale nested și poate adăuga o nouă etichetă la stiva de
etichete. Îndrumarea se va face pe baza etichetei din vârful stivei. Când pachetul iese din tunelul
interior, atunci eticheta din vârful stivei este îndepărtată iar îndrumarea se va face pe baza
etichetei din stivă din nivelul imediat inferior.
Un pachet neetichetat poate fi considerat un pachet a cărui stivă este goală (de adâncime
0). Dacă stiva de etichete a unui pachet este de adâncime M , ne referim la eticheta din partea cea
mai de jos a stivei ca fiind eticheta de nivel 1, cea de deasupra ei este etichetată de nivel 2 și
eticheta din vârful stivei va fi eticheta de nivel M.
Stiva de et ichete este reprezentată printr -o secvență de elemente în antetul MPLS. Fiecare
element este reprezentat prin 4 octeți (32 biți). Elementele stivei apar după anetul nivelului
legătură de date , dar înainte de antetul nivelului rețea. Vârful stivei de etich ete apare primul, iar
baza apare ultima. Antetul nivelului rețea urmează imediat după elementul care are setat bitul S.
Eticheta de la nivelul superior al stivei permite identificarea următorului nod la care va fi
îndrumat pachetul.
Operațiile care pot fi aplicate stivei de etichete sunt următoarele:
 Înlocuirea etichetei din vârful stivei cu o nouă etichetă;
 Scoaterea din stivă a ultimei etichete (pop)
 Înlocuirea etichetei din vârful stivei cu o nouă etichetă specificată și apoi
adăugarea uneia sau mai mul tor etichete în stiva pachetului (push).
Într-un nod al rețelei MPLS se poate realiza comutația agregatelor pe baza etichetelor de
la nivel superior și se ignoră nivelele inferioare din stivă

Când fluxul ajunge la un nod al rețelei capabil să controleze e ntitățile de nivel inferior,
atunci comutatorul elimină eticheta din vârful stivei și examinează nivelul imediat inferior din
stivă.

D. Utilizarea în comun a etichetelor (Label Merging)

O cale de reducere a cantității de spațiu consumat pentru etichete în i nteriorul unei rețele
MPLS implică utilizarea în comun a etichetelor, ceea ce implică utilizarea uneia sau mai multor
etichete de intrare mapate la o singură etichetă downstream către un LSR. Traficul care aparține
aceleiași clase FEC, dar are originea pe LSR ingress diferite va merge pe o cale comună LSP în
interiorul rețelei. Două sau mai multe LSPs converg într -un punct al rețelei într -un singur LSP
către același „EgressLSR” pentru pentru o clasă FEC.

E. Bază a informațiilor de dirijare bazată pe etichete (Label Forwarding
Information Base)

LFIB întreținută de un nod MPLS are o serie de înregistrări. Fiecare înregistrare constă
dintr -o etichetă de intrare și una sau mai multe subînregistrări. LFIB este indexată pe baza valorii
conținută de eticheta de int rare.
Fiecare su bînregistrare este formată din : o etichetă de ieșire, o interfață de ieșire și
adresa următorului nod. Subînregistrările din cadrul unei înregistrări pot avea sau nu aceeași
etichetă de ieșire. Dirijarea multicast necesită subînregistrăr i cu etichete de ieșire multiple,
deoarece un pachet care intră pe o anumită interfață trebuie să fie transmis p e mai multe interfețe
de ieșire .
Pe lângă informaț iile despre eticheta de ieșire , interfața de ieșire și următorul nod, o
înregistrare în tabe la de dirijare mai poate include și informații despre resursele pe care le poate
utiliza u n pachet , cum ar fi coada de ieșire în care ar trebui să fie plasat pachetul.
Un nod MPLS poate avea o singură tabelă de dirijare, sau o tabelă de dirijare pentru
fiecare interfață, sau o combinație a acestora. În cazul existenței a mai multor tabele de dirijare ,
dirijarea pachetelor este realizată atât pe baza valorii etichetei de intrare cât și pe baza interfeței
de intrare pe care pachetul este primit.

F. Algoritm ul de dirijare a etichetelor

Comutatoarele de etichete utilizează un algoritm de dirijare bazat pe comutarea
etichetelor. Nodul MPLS care are o singură LFIB extrage valorile etichetei din câmpul etichetei
găsite în pachetul primit și folosește această va loare ca o referință în LFIB.
Dacă eticheta de intrare este găsită în LFIB , nodul MPLS comută eticheta din pachet cu
eticheta de ieșire din subînregistrare și trimite pachetul pe interfața de ieșire specificată către

următorul nod găsit de asemenea în LFIB. Dacă subînregistrarea specifică și o coadă de ieșire
atunci nodul MPLS plasează pachetul în coada specificată.
Dacă nodul MPLS are câte o LFIB pentru fiecare interfață atunci acesta utilizează
interfața fizică pe care a fost primit pachetul pentru a selecta o LFIB în vederea dirijării
pachetului.
Algoritmii de dirijare tradiționali utilizează multipli algoritmi pentru a dirija pachetele
unicast, multicast și de difuzare cu biții ToS (Type of Service) setați. MPLS utilizează un singur
algoritm de diri jare bazat pe înlocuirea etichetei (swapping).
Un nod MPLS poate obține toate informațiile necesare atât pentru îndrumarea
pachetului cât și pentru rezervarea resurselor necesare unui pachet printr -un singur acces la
memorie. Această abilitate foarte ra pidă de căutare și dirijare face comutația de etichete o
tehnologie de comutație cu performanțe ridicate. MPLS poate fi utilizat cu IPv4, dar și cu alte
protocoale de nivel 3 cum ar fi IPv6, IPX, sau AppleTalk.

G. Tunele

Un router sursă Rs trebuie să îndr ume un pachet la destinația Rd, deși Rs și Rd nu sunt
rutere consecutive în calea nod -cu-nod a pachetului și Rd nu este nodul destinație finală al
pachetului.
Se va crea un tunel între RS și Rd realizat prin folosirea routers R1, R2, R3 .. Rn. Acest
lucru poate fi făcut prin încapsularea pachetului în interiorul unui pachet de nivel rețea a cărui
adresă destinație este adresa lui Rd. Se crează astfel un „tunel” de la Rs la Rd. Pachetele astfel
manipulate se numesc „pachete tunelate”.
Dacă un pachet tunelat urmează o cale nod cu nod de la Rs la Rd , se spune că este într -un
tunel în care rutarea este realizată prin nodurile tunelului (nod cu nod).Tunelul are „capătul de
transmisie” Rs și „capătul de recepție” Rd.

a)Tunel rutat explicit
Dacă un pachet este transmis de la Rs la Rd pe altă cale decât cea nod cu nod , se spune
că este într -un „tunel explicit ” ,care are „capătul de transmisie” Rs și „capătul de recepție” Rd.

b)Tunele LSP
Este posibilă implementarea unui tunel ca o cale cu comutație de etic hete și folosirea
etichetei pentru rutarea pachetului prin tunel. Tunelul este o cale LSP < R1, R2,…, Rn >, unde R1
va fi capătul de transmisie al tunelului iar Rn va fi capătul de recepție. Un astfel de tunel se
numește Tunel LSP.
Setul de pachete ce ur mează a fi transmise prin tunelul LSP este asociat unei clase FEC ,
și fiecare LSR din tunel trebuie să asigneze o etichetă acelei clase FEC. Criteriul de asociere a
unui pachet unui tunel LSP este o problemă locală la capătul de transmisie al tunelului.

H. Planul de Control

Planul de control MPLS este responsabil cu popularea și menținerea LFIB. Toate
nodurile MPLS trebuie să ruleze un protocul de rutare IP pentru a schimba informații de rutare IP
cu toate nodurile MPLS din rețea.
Protocoalele de rutare l ink-state ca OSPF și IS -IS sunt protocoalele preferate deoarece
acestea asigură nodurilor MPLS topologia întregii rețele. În ruterele tradiționale tabela de rutare
IP este folosită pentru a construi cache -ul pentru comutare rapidă sau Tabela de informați i de
dirijare (FIB). În MPLS tabela de rutare IP oferă informații despre rețeaua destinație și prefixele
subrețelelor utilizate pentru asocierea (binding) etichetelor.
Asocierea etichetelor poate fi distribuită prin intermediul protocolului LDP (Label
Distribution Protocol) sau prin piggybacking informația de asocierea a etichetelor deasupra
protocoalelor de rutare modificate.
Protocoalele de rutare link -state ca OSPF (Open Shortest Path First) inundă informație de
rutare unor rutere care nu sunt neapărat adiacente, însă informația de asociere a ruterelor este
distribuită doar ruterelor adiacente. Din această cauză protocoalele de rutare nu pot fi folosite ca
protocoale de distribuție a asocierilor.
Totuși extensii ale protocoalelor de rutare cum ar fi PIM (Protocol -Independent
Multicast) și BGP (Border Gateway Protocol) pot fi folosite pentru distribuirea informației de
asociere a etichetelor. Acest lucru face distribuția informației despre asocierea etichetelor
consistentă cu distribuirea informației de r utare și astfel se evită situația care survine rar când un
nod MPLS poate primi informații despre asocierea etichetelor dar nu are informația de rutare
adecvată. De asemenea simplifică întreaga operație a sistemului deoarece elimină necesitatea
existenței unui protocol special folosit pentru distribuirea informației de asociere a etichetelor.
Etichetele schimbate cu nodurile adiacente MPLS sunt folosite pentru a construi LFIB.
MPLS utilizează un context de dirijare bazat pe comutarea etichetelor care poate fi
combinat cu o serie de module de control. Fiecare modul de control este responsabil atât cu
atribuirea și distribuirea unui set de etichete cât și cu stabilirea unor alte informații de control.
Protocoalele de rutare interioare sunt folosite pentru a a sigura conectivitatea, asocierea și
maparea între FEC și adresa următorului nod.
Modulele de control MPLS sunt:
 Modulul de rutare unicast
 Modulul de rutare multicast
 Modulul de inginerie a traficului
 Modulul pentru rețele virtuale private

 Modulul pentru ca litatea serviciilor

Modulul de rutare unicast
Acest modul construiește tabela FEC utilizând protocoalele tradiționale de rutare
interioară cum ar fi OSPF, IS -IS și altele. Tabela de rutare IP este folosită pentru a schimba
informații despre asocierea e tichetelor cu nodurile MPLS adiacente pentru subrețele conținute în
tabela de rutare IP.Schimbul de informații despre asocierea etichetelor se face utilizând LDP.
Modulul de rutare multicast
Acest modul construiește tabela FEC folosind un protocol de rut are multicast cum ar fi
Protocol -Independent Multicast (PIM). Tabela de rutare multicast este folosită pentru a schimba
asocierile de etichete cu ruterele vecine pentru subneturi conținute în tabela de rutare multicast.
.Schimbul de informații despre asoci erea etichetelor se face utilizând protocolul PIM v2 cu
extensii MPLS.
Modulul de inginerie a traficului
Acest modul permite setarea unor căi de dirijare cu comutație a etichetelor printr -o rețea
cu respectarea unor obiective de inginerie a traficului. Uti lizează definiția tunelelor MPLS și
extensii ale protocoalelor IS -IS sau ale OSPF pentru a construi tabela FEC. Schimbul de
informații despre asocierea etichetelor se realizează cu ajutorul protocolului RSVP sau al
protocolului Constraint Based Routing Ldp (CR-LDP) care constă dintr -un set de extensii ale
protocolului LDP cu ajutorul căruia rutarea în rețelele MPLS se poate face pe baza
constrângerilor.
Modulul de rețea virtuală privată (VPN)
Acest modul utilizează tabele de rutare per VPN pentru tabelele FEC, aceste tabele sunt
construite prin existența unor protocoale de rutare între ruterele CPE și nodurile MPLS de graniță
furnizoare de servicii. Schimbul de informații de asociere a etichetelor pentru tabelele de ruatare
specifice VPN se realizează folo sind Multiprotocolul extins BGP în interiorul rețelei
furnizorului de servicii.
Modulul de calitate a serviciilor
Acest modul construiește tabela FEC utilizând protocoalele tradiționale de rutare
interioară cum ar fi OSPF, IS -IS și altele. Tabela de rut are IP este folosită pentru a schimba
informații despre asocierea etichetelor cu nodurile MPLS adiacente pentru subrețele conținute în
tabela de rutare IP.Schimbul de informații despre asocierea etichetelor se face utilizând LDP.
După cum am văzut în cad rul planului de control informația de rutare și alte informații de
control cum ar fi, asocierea etichetelor, sunt schimbate între LSR -uri. MPLS este o tehnologie

condusă de planul de control, adică schimbul de informații de control trebuie să se facă în ainte
ca primul pachet de date să fie dirijat. Dirijarea pachetelor de date are loc în planul de date.

2.3. Funcționarea MPLS

Astfel , având în vedere cele două blocuri funcționale ale unui nod MPLS , etapele de
functionare ale MPLS sunt următoarele :
2.3.1. Faza de c ontrol

a) Potocoalele de ruta re interioare (RIP, OSPF, IS -IS etc.) calculează rutele pentru toate
destinaț iile accesibile. (ex.: OSPF, fiecare nod (ruter) determina graful retelei prin mesaje “link
state” de la vecini calculeaza drumurile cele mai scurte de la el catre diferite destinatii/retele
aplicând un criteriu de cost minim) si se completeaza tabelul de dirijare.
b) Spatiul total de dirijare se împarte în FEC -uri. (Pachetele care vor urma acelasi drum vor
apartine aceleiasi FEC – se face “legarea eti chetelor” – “label binding”, prin care se atribuie câte
o eticheta pentru fiecare FEC. Label scope = un link între doua rutere MPLS.
c) LDP – distribuie etichetele între noduri, contribuind la alocarea în fiecare nod a unei
etichete pentru o anumita clasa FEC (“map labels to each FEC în every hop”). Astfel se stabilesc
caile LSP (unidirectionale) prin domeniul MPLS .

2.3.2. Dirijarea pachetelor

Fiecare pachet IP sosit pe un port de intrare într -un ruter de frontiera MPLS suferă
următoarele acțiuni :
a) Se examinea za ruta la nivel L3
 clasificarea pachetului – se aloca o eticheta corespunzatoare clasei FEC alese
 se eticheteaza pachetul IP cu antet MPLS
 pachetul este dirijat pe baza acesteia prin comutatie de etichete în fiecare nod.
La examinarea antetului de nivel 3 pot fi considerare si alte informatii auxiliare ( ex. de
QoS, TE etc.). Corespunzator acestor informatii ruterul de frontiera E -LSR poate decide alocarea
clasei FEC si a etichetei corespunzatoare ce va fi aplicata antetului.
b) Fiecare LSR comuta etiche tele (label swapping) folosind eticheta de intrare ca index în
tabelul de dirijare. Pachetul este dirijat pe portul de iesire spre nodul urmator. Comutatia
realizata este : (Port -in, Etichetă -in) -> (Port -out, Etichetă -out).
c) Nodul de iesire din domeniul MPLS elimina eticheta si dirijeaza pachetul mai departe,
în stil IP (eventual spre un alt domeniu) pe baza analizei de antet L3.

Optional PHP (Penultimate Hop Popping): penultimul ruter din domeniul MPLS, dupa
determinarea portului de iesire catre ultimul nod MPLS, elimina deja eticheta deoarece ruterul de
iesire, oricum nu o va mai folosi.

2.3.3. Operația LSR Packet – based

Operația Packet -based LSR folosește o paradigmă de dirijare pe baza etichetelor pentru a
transporta pachetele de nivel 3 într -o rețea cu rutere. Packet -based LSR MPLS este de asemenea
numit frame mode MPLS.
Operația de bază a frame mode MPLS pentru a realiza rutarea unicast cu un singur nivel
al stivei de etichete este ilustrată în figura de mai jos. LSR1 realizează funcțiile unui LSR de
graniță. Acesta aplică prima etichetă pachetului după ce realizează căutarea celei mai lung i
potriviri cu headerul IP pentru a determina FEC -ul pachetului. Parametrii ca interfața de intrare
pot de asemenea să determine selecția FEC -ului. Această operațiune este realizată o singură
dată, la intarea în rețea.

Figura 11. Packet -Based LSR Opera tion with a Single Level Stack
După ce pachetul este etichetat, urmatoarele noduri LSR dirijează pachetul folosind
numai eticheta. LSR -urile de obicei înlocuiesc eticheta unui pachet pe care îl primesc cu o
nouă valoare si îl transmit mai departe. La ieșir e, LSR4 realizează o analizare a etichetei,
înlătură eticheta , realizează o analiză de nivel 3 , și trimite pachetul către ruterul următor
extern .
Operația LSR Packet -Based cu o stivă de etichete multinivel
Figura 1.10 ilustrează operația LSR packet -based având o stivă de etichete cu mai
multe nivele. LSR1 realizează funcțiunile de ruter de graniță. Acesta aplică un set de etichete
pachetului după ce realizează căutarea celei mai lungi potriviri cu headerul IP pentru a
determina FEC -ul pachetului. Nodul LSR2 intermediar elimină eticheta cu valoarea 7 și o
înlocuiește cu eticheta cu valoarea 8. La ieșire , LSR4 realizează o analiză a etichetei,
elimină eticheta, realizează o analiză de nivel 3 , și transmite pachetul către routerul următor
extern.

Figura 12. Operația LSR Packet -Based cu o stivă de etichete multinivel
2.3.4. Penultimate Hop Popping

Operația LSR packet -based descrisă anterior are anumite dezavantaje asociate cu dubla
analiză efectuată de nodul de ieșire LSR4. LSR4 ar trebui să examineze stiva de etichete și să
caute eticheta în LFIB , doar pentru a constata că trebuie să o elimine. Apoi ar trebui să efectueze
o analiză de nivel 3 în tabela sa de rutare globală pentru a dirija corect pachetul către următorul
ruter exter. Dubla analiză realizată de LSR4 poate cauza atât degradarea performanței cât și
complexitatea implementării MPLS.
Pentru a implementa penultimate hop popping , LSR de graniță , LSR 4(în cazul figurii
de mai jos) cere o operație de eliminare a etichetei de la vecinii săi upstream, LSR2 , via LDP
folosind o etichetă specială implicit -null. Această etichetă are valoarea 3 pentru LDP.

Figura 13. Penultimate Hop Popping

LSR2 elimină eticheta înainte de a trimite pachetul IP lui LSR4. LSR4 realizează apoi o
analiză de nivel3 pe baz a adresei destinație conținută de pachet și dirijează pachetul către o
subrețea locală sau un router următor extern.
Penultimate hop popping este necesară numai pentru subneturile direct conectate sau rutele
agregate, pentru că interfața de ieșire de nive l 3 poate fi dedusă din înregistrarea etichetei
căutate în LFIB.

2.4. Protocoale MPLS

MPLS definește doar mecanismul de dirijare; el folosește alte mecanisme pentru
stabilirea LSP -urilor. Două protocoale separate sunt necesare pentru a realiza această operaț ie:
 Un protocol de rutare
 Un protocol de semnalizare.
Protocoale MPLS de rutare
Protocolul de rutare distribuie informații despre topologia rețelei în rețea, astfel încât să
poată fi calculate căile LSP. De obicei este folosit un protocol de rutare de tip OSPF sau IS –
IS,deoarece rețelele MPLS acoperă în mod obișnuit un singur domeniu administrativ,
Aceste protocoale de rutare distribuie informații despre topologia rețelei. Atunci când este
necesară ingineria traficului pentru a stabili LSP -urile cu carecte ristici garantate de calitate a

serviciului (QoS), sunt folosite extensii TE ale acestor protocoale. Aceste extensii distribuie
informațiile legate de QoS și grupuri de linkuri către fiecare link din rețea. Aceste informții
permit calcularea rutelor prin r ețea cu parametrii QoS și grupuri de linkuri către fiecare link din
rețea. Aceste informații permit calcularea rutelor prin rețea cu parametrii QoS garantați și a
rutelor de rezervă (backup LSP).
MPLS permite transportul pachtelor care au etichete multipl e sau stive de etichete. Stiva
de etichete permite nodurilor MPLS să facă diferența între tipurile de fluxuri de date și să seteze
și să distribuie LSP -urile în mod corespunzător.
Protocoale MPLS de semnalizare
Protocolul de semnalizare informează nodurile de pe o anumită cale ce etichete și linkuri
să folosească pentru fiecare LSP. Este folosit unul dintre protocoalele următoare, în funcție de
cerințele aplicației:
 LDP este folosit pentru
o Transport MPLS acolo unde nu este necesară ingineria traficului
o Anumite servicii MPLS
 RSVP -TE este folosit pentru:
o Transport MPLS unde este necesară ingineria traficului
o Transport GMPLS
 BGP este folosit ca protocol de semnalizare pentru anumite servicii MPLS, de exemplu
BGP/MPLS VPN de nivel 3
 CR-LDP este folosit pen tru:
o Stabilirea căii de rutare folosind informația de etichete
o Alegerea unor căi explicite de rutare folosind informațiile furnizate de TE

A. Protocolul BGP
BGP este un protocol de rutare folosit pentru realizarea schimbului de informații între
ruterele une i rețele. Informația de ruatare BGP cuprinde rutele complete către fiecare destinație.
BGP folosește această informație pentru a crea o bază de date a informațiilor privind
posibilitățile de a ajunge la diferite noduri ale rețelei , informații pe care le s chimbă apoi cu alte
sisteme BGP. Aceste informații sunt folosite pentru a construi un graf al rețelei cu noduri
consecutive, permițând astfel BGP să elimine buclele și să impună politici la nivelul nodurilor.

Aceste politici de rutare pot fi folosite pentr u a alege între mai multe rute către aceeași
destinație și pentru a controla redistribuirea informației de rutare.
BGP folosește TCP -ul , folosind portul 179 pentru stabilirea conexiunilor.
Un sistem autonom reprezinta un set de rutere care aparțin unei si ngure adiministrații
tehnice și care folosesc aceleași tehnici de rutare și propagare a informației de rutare între rutere.
Un sistem autonom va apare unui alt sistem autonom drept un plan de rutare singular care
prezintă o imagine completă a destinațiilor care pot fi atinse prin intermediul lui.
BGP poate fi:
 EBGP dacă este folosit intre două sisteme autonome AS
 IBGP atunci când este folosit în interiorul unui sistem autonom.
BGP schimbă informații de rutare cu un sistem BGP adiacent , numit și vecin sau
pereche.
O rută BGP către destinație definește :
 Calea AS, care este formată dintr -o listă a sistemlor autonome parcurse până la destinație
 Atributele de cale , care conțin informații adiționale despre sistemele autonome de pe rută
și care sunt folosite pen tru politici de rutare.
Perechile BGP își comunică rutele unul celuilalt prin mesaje de actualizare. BGP își
stochează rutele într -o tabelă software de rutare. Tabela păstrează următoarele informații despre
o rută:
 Informații de rutare „învățate ” prin mes ajele de actualizare primite
 Informații de rutare locale pe care sistemul BGP le transmite perechilor lui prin mesajele
de actualizare pe care le trimite.
Pentru fiecare prefix din tabela de rutare , procesul protocolului de rutare detecteză o
singură rută „cea mai avantajoasă”, numită ruta activă.
Datele inițiale sunt folosite de BGP pentru setarea tabelei de rutare. Mesajele de
actualizare sunt apoi schimbate pe măsură ce tabelele de rutare se modifică. BGP nu necesită o
actualizare a tabelei completate d e rutare la intervale periodice. De aceea un sistem BGP trebuie
să mențină versiunea curentă a întregii tabele de rutare către vecinii săi pe toată durata
conexiunii.
Versiunea BGPv4 a acestui protocol prevede posibilitatea adaptării lui pentru a permite ș i
a distribui etichetele într -o rețea MPLS. Informația de etichetare a rutei este conținută în același
mesaj de actualizare folosit pentru distribuția unei rute. Etichetele sunt conținute în câmpul de
atribute suplimentare ale căii din cadrul mesajului de actualizare BGP.

Etichetele specificate pentru o anumită rută sunt atribuite de către LSR -ul identificat ca
„nod următor” al rutei.
Un ruter BGP poate menține (și anunța vecinilor săi) mai multe rute către aceeași
destinație, atât timp cât fiecare rută are propria etichetă (sau etichete).

B. Protocolul LDP (Label Distribution Protocol)
Un protocol de distribuție a etichetelor este un protocol care permite nodurilor MPLS să
comunice între ele legăturile dintre etichete și clasele FEC asociate unei căi LSP. Reț eaua MPLS
trebuie să definească LSP -uri între ingress LSR și egress LSR. De -a lungul fiecărei căi LSP sunt
folosite pentru rutare numai etichetele care definesc calea LSP.
LDP oferă un mecanism de descoperire care permite identificarea LSR -urilor și realiz area
semnalizărilor în vederea distribuirii și controlului etichetelor de îndrumare.

Tabelul 3.

Există 4 tipuri de mesaje folosite de LDP:

 mesaje de descoperire, folosite pentru a anunța prezența în rețea a unui element de rețea
 mesajele sesiunii fo losite pentru a stabili, menține și termina sesiunile între perechile
LDP
 mesaje de avertisment folosite pentru a creea, modifica și șterge map ări de etichete (sau
conexiuni)
 mesaje de notificare folosite pentru a furniza informații de avizare sau indic are eroare

LDP a fost conceput să fie ușor de extins, folosind mesaje specificate ca o colecție de
obiecte TLV (Type, Length, Value). Codarea TLV înseamnă că fiecare obiect conține un câmp
Type care permite identificarea tipului obiectului, un câmp length ca re specifică lungimea
obiectului, și un câmp Value care definește valoarea obiectului.

Descoperirea vecinilor

LDP permite descoperirea vecinilor. Un LSR trimite periodic un mesaj HELLO multicast
pe un port UDP dedicat (LDP Discovery Port). Mesajul LDP HELLO conține un identificator
LSP pentru spațiul de etichetă al LSR care intenționează să folosească interfața.
Toate LSR -urile așteaptă și ascultă pe acest port recepția de mesaje HELLO. Astfel, la
un moment dat un LSR poate primi informația despre cel elalalte LSR -URI cu care are conexiuni
directe. La recepția unui mesaj HELLO se va răspunde cu un semnal de același tip (HELLO),
care va include identitatea nodului transmițător .

Figura 14. Descoperirea vecinilor

Un mecanism adițional de descoperire , p ermite LSR -urilor să se descopere unul pe
celălalt , chiar și atunci când nu sunt direct conectate la o subrețea comună. În acest caz , un
LSR trimite periodic mesaj Target HELLO unicast pe un port UDP dedicat către o anumită
adresă IP.
La recepția mesaj ului Keep_Alive , LSR activ va trece în starea Operațional.
În starea Operațional , un LSR poate recepționa și procesa un mesaj LDP sau în absența
acestora. La expirarea temporizării setată după recepția unui mesaj Keep_Alive , va transmite un
mesaj Keep_A live pentru menținerea conexiunii.

Eliberarea conexiunii stabilită prin LSP se va realiza în urma recepției unuia dintre
mesajele Disconnect sau ShutDown.

Figura 15. Diagrama de stări și tranziții a LDP

Schimbul de mesaje care are loc între două LSR ( LSR1 și LSR2) pune în evidență
ordinea în timp în care pot fi transmise următoarele mesaje:
 Initialization – inițializarea legăturii TCP și negocierea parametrilor
 Keep_Alive – menținerea legăturii
 mesaje LDP de distribuție etichete:
o LABEL MAPPING
o LABEL W ITHDRAWAL
o LABEL RELEASE
o LABEL REQUEST
o LABEL REQUEST ABORT
 ShutDown – cerere de închidere a conexiunii TCP
 Disconnect – eliberarea conexiunii TCP

Pentru stabilirea unei conexiuni , partea chemătoare transmite mesajul LDP Label
Request , care conține parametr ii de apel și de conexiune. Mesajul este îndrumat către partea
chemată, care va răspunde cu mesajul LDP Label Mapping.
Mesajele Label Mapping asigură distribuirea etichetelor în vederea stabilirii conexiunii.
Mesajul LDP Notification este transmis de parte a chemătoare pentru a confirma setarea
conexiunii.
Eliberarea apelului cu LDP

Cererea de eliberare a conexiunii este realizată cu mesajul LDP Call Release. Nodurile
rețelei notifică această cerere cu mesajul LDP Notification.
Eliberarea conexiunii se fa ce ca urmare a cererii de retragere a etichetei de îndrumare
realizată cu mesajul LDP Label Withdraw, iar confirmarea eliberării este semnalizată cu
mesajele LDP Label Release și Label Withdraw. Eliberarea conexiunii este semnalizată părților
chemătoare și chemate prin mesajul LDP Notification.

C. Protocolul CR LDP (Constraint Routing Label Distribution Protocol)

CR-LDP este un protocol de distribuție de etichete bazat pe constrângeri utlizat pentru
stabilirea căii de rutare folosită de MPLS pentru rutarea p achetelor utilizatorului pe baza
comutației de etichete.
O cale LSP poate fi instanțiată pe baza constrângerilor explicite de rutare, pe baza
constrângerilor QoS sau a altor constrângeri. Rutarea bazată pe constrângeri este un mecanism
folosit pentru a sat isface cerințele de inginerie de trafic. Aceste cerințe pot fi satisfăcute prin
extensia LDP pentru a suporta căile cu comutație de etichete definite explicit.
Un model de rutare bazat pe constrângeri folosește ca intrări următoarele informații:
 Atributele asociate trunchiurilor de trafic
 Atributele asociate resurselor
 Alte informații legate de topologia rețelelor
Bazându -se pe aceste informații, un proces de rutare bazată pe constrângeri calculează
pentru fiecare nod, rutele explicite pentru fiecare trunc hi de trafic care își are originea în acel
nod. În acest caz o rută explicită pentru fiecare tunchi de trafic este o specificare a căii comutate
ce satisface cerințele exprimate în atributele trunchiului de trafic respectiv, subiect al
constrângerilor impu se de existența resurelor , politici administrative și alte informații
topologice.
Rutarea bazată pe constrângeri este rutarea care ia în considerare disponibilitatea
resurselor. Ea trebuie să coexiste cu protocoalele de rutare clasică care folosesc princi piul „hop
by hop” și sunt influențate de topologia rețelei.
Inginerul de trafic, un operator sau chiar un automat, va specifica capetele unui trunchi de
trafic și vor desemna un set de atribute ale trunchiului care să încapsuleze așteptările de

performanță și caracteristicile comportamentale ale trunchiului. Modelul de rutare bazată pe
constrângeri are ca scop găsirea de căi capabile să satisfacă aceste așteptări. Dacă este necesar ,
inginerul de trafic sau un sistem de inginerie de trafic pot folosi la mom entul respectiv rute
explicite pentru a realiza optimizarea utilizării rețelei.

Implementarea rutării bazate pe constrângeri se realizează prin folosire de mecanisme
privind:
 Schimbul de informații legate de topologie (informații despre valabilitatea sau existența
resurselor, informații despre starea linkurilor sau informații legate de atributele resurselor) între
procesele rutării bazate pe constrângeri
 Managementul informațiilor legate de topologia rețelei
 Interacțiunea între procesele de rutare bazate pe constrângeri și procesele convenționale
IGP
 Mecanisme de adaptare la cerințele (atributele) trunchiurilor de trafic

Figura 1 6. Modelul rutării bazate pe constrângeri

Rutarea bazată pe constrângeri ajută la optimizarea performanțelor operaționale , p rin
căutarea automată a căilor posibile care satisfac un set de constrângeri pentru trunchiurile de
trafic.
CR-LDP este o extensie a protocolului LDP care utilizează următoarele caracteristici ale
acestuia:
– Folosirea unor mecanisme de descoperire a rețelei de bază și/sau a unor
mecanisme extinse
– Folosirea mesajelor de cerere de etichetă în mod controlat
– Folosirea mesajelor de mapare a etichetelor
– Folosirea mesajelor de notificare

– Folosirea mesajelor de retragere și a mesajelor de eliberare
– Folosirea mecanis melor de detectare a buclelor.

CR-LDP furnizează mecanisme pentru stabilirea LSP -urilor rutate explicit. Aceste
mecanisme sunt definite prin extensii ale LDP. Deoarece LDP este un protocol „peer -to-peer”,
care se bazează pe stabilirea și menținerea sesiun ilor TCP, există în mod natural următoarele
avantaje :
 Mesajele CR -LDP sunt transmise în mod eficient prin intermediul TCP și informația de
stare asociată cu căile LSP rutate explicit nu necesită o reîmprospătare periodică.
 Mesajele CR -LDP sunt controlate din punct de vedere al fluxului prin intermediul TCP.
 CR-LDP are ca obiectiv stabilirea și menținerea priorităților.
 CR-LDP permite de asemenea ca acești parametri să fie modificați în mod dinamic, fără
întreruperi ale LSP -urilor operaționale.
 CR-LDP permi te specificarea unui set de parametri care să fie semnalizați o dată cu
cererea de stabilire a LSP. Mai mult, rețeaua poate fi prevăzută cu un set de funcții de
condiționare a traficului marginal (care include marcarea, măsurarea sau modelarea). Acest set
de parametri împreună cu specificarea funcțiilor de condiționare marginale , pot fi adecvate și
destul de puternice pentru a descrie, caracteriza și parametriza o largă varietate de scenarii și
servicii QoS inclusiv serviciile diferențiate IP, serviciile integrate, clasele de servicii ATM și
Frame Relay.
CR-LDP adaugă următoarele noi elemente:
Mesajul de cerere de etichetă folosit pentru instanțierea CR -LSP-urilor include unul sau
mai multe obiecte TLV. De exemplu mesajul pentru cererea de etichetă poate s ă includă TLV -ul
de rută explicită, TLV -ul de parametrii de trafic, etc
Pot fi folosite semnalizări pentru cererea de modificare sau stabilire a unei căi cu
constrângeri de ruatare (CR -LSP)
Mesajele folosite de CR -LDP sunt:
 Label Request
Mesajul de cerere de etichetă include informații care indică cererea de rută explicită (ER –
TLV) informații care definesc explicit ruta prin precizarea hop -urilor prin care trece ruta (ER –
TLV1… ER -TLVn), parametri de trafic, identitatea LSP (SLPID), clasa de resure, clasa de
îndrumare (FEC CE -SLP)
Parametrii de trafic pot influența alegerea rutei bazată pe constrângeri. Parametrii care
definesc caracteristicile traficului sunt:
 PDR (Peak Data Rate)
 PBS (Peak Burst Size)
 CDR (Comitted Data Rate)
 CBS (Comitted Burst Size)
 EBS (Excess Burst Size)

 Label Mapping
Mesajul de mapare a etichetei este transmis de către un LSP down stream către un LSR
upstream în una din situațiile următoare:
LSR-ul este capătul de ieșire al CR -LSP-ului și a fost cerută o mapare upstream.
LSR-ul a primit o maparede la nodul său următor LSR pentru un CR -LSP pentru care
încă se așteaptă o decizie la o cerere upstream.
Mesjaul de mapare a etichetei trebuie să definească o singură etichetă (Label TLV).
Acest mesaj conține următoarele elemente TLV : FE C, TLV, Label TLV, Label Request
Message ID TLV, LSPID TLV, Traffic TLV.
 Notification
Stabilirea unui CR -LSP poate să eșueze din cauza unei varietăți de motive. Toate aceste
erori sunt considerate și ele sunt semnalizate de către mesajele de notificare, ca re conțin un TLV
de stare.
Mesajul de notificare poate transporta identitatea căii CR -LSP. Acest mesaj trebuie
îndrumat către LSR -ul de la care provine cererea de etichetă.
 Label Release
 Label Withdraw
 Label Abort Request Messages

3. Ingineria traficului în rețelele MPLS

3.1. Ingineria de t rafic

3.1.1. Necesitate

Rolul ingineriei traficului (Traffic Engeneering – TE) este de a transmite traficul de la o
margine la altă într -o rețea, în cel mai optim mod. Această tehnică este întâlnită încă din timpul
rețelelor Frame Relay sau ATM, unde se foloseau circuite virtuale pentru a planifica și transmite
traficul. Cum în zilele actuale rețele se bazează în principal pe o solutie IP, este nevoie de o
soluție d e inginerie a traficului în aceste rețele. Acest lucru nu este posibil într -o rețea pur IP, dar
se poate implementa într -o rețea IP -MPLS.
Rutarea în rețelele IP este reglementată de necesitatea de a transmite traficul din întreaga
rețea cât mai rapid posi bil. 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 legăturile în
rețele. Acumularea de costuri ale fiecarui link pentru o cale, este folosita pent ru 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 Pro tocol [IGRP] și Enhanced Interior Gateway
Routing Protocol [EIGRP]), sau pur și simplu un număr de hopuri (de exemplu, Routing
Information Protocol [RIP] și RIP versiunea 2).
Dirijarea IP nu ține seamă de capacitatea disponibilă de lățime de bandă de pe u n link,
care ar putea diferi semnificativ de costul care este atribuit pe link. Prin urmare, un router poate
păstra dirijarea de trafic pe o legătură, chiar dacă acest link este deja plin și produce pierdere de
pachete.

Figura 17. Dirijarea în reț ele IP

De exemplu, in Figura 16, dacă fiecare link din acest eșantion de rețea are același 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 ca lea R1 -R3-R4-R5 nu va avea
nici un trafic.
Puteți distribui sarcina uniform schimband costul pe link -uri pentru un anumit protocol de
dirijare. Asta ar putea distribui traficul mai uniform, dar niciodată nu poți distribui sarcina
perfect, deoarece, în rețe lele reale, link -urile nu au, aproape niciodată, aceeași lățime de bandă.
În rețeaua din figura 3.1, aveți posibilitatea să va asigurati că cele două căi sunt egale facand
suma costurilor de link -uri în calea R1 -R2-R5 și calea R1 -R3-R4-R5 egala. Rezultatu l va fi
echilibrarea încărcării 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 rețea de pe R2
catre R4, și așa mai departe. Avem iar aceeasi pro blema, pentru că există două căi de la R2 la
R4, puteți avea aceeași problemă între routere R3 și R5 sau la oricare dintre celelalte. De
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 răspândirea eficienta a traficului în întreaga rețea, evitând neutilizarea și
suprautilizarea link -urilor
 ține seama de configuratiile (statice) de latime de banda ale l egăturilor
 ia în considerare atributele legaturilor, precum: intarziere, jitter etc.
 se adaptează automat la schimbare a de lătime 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 rețelei spre
routerul de la coada LSP (tailend). Routerul de la capul LSP poate face acest lucru î n cazul în
care acesta cunoaste topologia de rețea. În plus, routerul headend trebuie să știe restul de lățime
de bandă pentru toate link -urile din rețea.

În fine, este nevoie să fie permis MPLS pe routere astfel încât să se poată stabili LSP -uri
cap la c ap. 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 destinație. 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 j os arată un exemplu de dirijare pe baza de sursa, capacitate a MPLS TE.

Figura 18. Dirijarea cu ingineria traficului
In figura 17, 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, ace st lucru este imposibil să se realizeze
într-o rețea IP clasica. În cazul în care se foloseste o rețea MPLS, puteți configura aceste două
căi ca
două LSP -uri diferite, astfel încât etichete diferite sunt folosite. La router R1, valoarea diferita a
etichet ei de sosire indică dacă pachetul aparține 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 rețea care are LSR -uri. Cu
toate acestea, deoarece lățimea de bandă și alte atribute de link -uri trebuie să fie cunoscute de
către 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 construiește o tabela cu starile link -urilor, care
este apoi inundata la toate celelalte rutere în aceeași zonă. Aceasta înseamnă că, toate rou tere din
domeniu au o topologie cu toate informațiile 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 numește un
tunel MPLS TE. Un tunel este unidirecțional, pentru c ă o cale LSP este unidirecționala, și are
configurația 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 rețea există posibilitatea de a crea tunele MPLS
TE între orice p ereche de LSR -uri din rețea. Ca atare, există posibilitatea să se orienteze tot
traficul din rețea, evitand congestionarea în ea, și să se dea tot traficul in functie de caracteristici
(de latime de banda, întârziere, bruiaj și așa mai departe) de care est e nevoie. Acest lucru este
esențial pentru miezul retelei (CORE – backbone) al providerilor de servicii.

3.1.2. Mod de lucru

MPLS este o integrare a tehnologiilor Layer 2 și Layer 3. Prin aducerea caracteristici
tradiționale Layer 2 disponibile la Layer 3, MPL S permite ingineria de trafic. Astfel, se poate
oferi în cadrul unei rețele de un singur nivel ce se putea realiza numai prin suprapunerea unei
rețele Layer 3 peste o rețea Layer 2.
MPLS TE stabilește automat și menține tunele în întreaga rețea core, u tilizând RSVP.
Calea utilizată de către un anumit tunel în orice moment este determinată pe baza resurselor
necesare ale tunelului și resursele rețelei, cum ar fi lățime de bandă.
Traseele tunelelor sunt calculate la capul tunelului pe baza resurselor ne cesare și
resurselor disponibile. IGP -ul automat rutează acest trafic în aceste tuneluri. De obicei, pachetele
ce trec o rețea cu MPLS TE în backbone circulă pe un singur tunel, care conectează punctul de
pătrundere la cel de ieșire.
Ingineria de trafic in MPLS este construită pe următoarele mecanisme:

 Constrângerile legaturilor : cât de mult trafic fiecare link poate sprijini și cât poate
utiliza tunelul TE
 Distribuția informațiilor 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]) pe ntru a semnalala tunelul TE în întreaga rețea
 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 direcționa în funcție de resurse sau constrângeri. Aceste resurse sunt lățimea de
bandă a link -urilor și câteva atribute de link -uri pe care operatorul le specifică. Aceste atribute
sunt configurate pe link -uri si sunt anunțate de protocolul link -state (OSPF sau IS -IS).
În loc de a crea un nou protocol pentru a transporta această informație și de a le anunța la
toate LSR -urile, OSPF și IS -IS au fost extinse pentru a transporta această informație. Când se
configurează un tunel TE pe un LSR, acesta devine capul (headend LSR) din acel tunel TE sau
TE-LSP. Apoi se specifică destinația LSR de pe tunelul TE si constrangerile la care trebui e sa se
supună. De exemplu, se poate să se specifice cerința de lățime de bandă pe tunel.
În interiorul IOS -ului Cisco, o bază de date este construită cu informații de inginerie a
traficului pe care protocolul link -state le trimite. Acesta bază conține toa te link -uri care sunt
activate pentru MPLS TE și caracteristicile acestora sau atributele. De la această bază de date,

PCALC sau SPF -ul constrâns (constrained SPF – CSPF) calculează cel mai scurt traseu, care încă
mai aderă la toate constrângerile (cel mai important, lățime 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 încât constrângerile pot fi luate în considerare. Ele au la bază teorema CBR
(Constraint Based Rou ting) care are la bază posibilitatea de a obține căi multiple între o sursă
specifică și o destinație într -o rețea.
LSR-urile intermediare pe LSP trebuie să știe care sunt etichetele de intrare și de ieșire
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 constrângeri (constraint -based LDP sau CR -LDP).
Mult mai folosit este RSVP -TE, în care extensii au fost făcute 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 esența, 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 informați ile despre etichete să ajungă
la fiecare LSR.
Un protocol de dirijare link -state trebuie să inunde constrângerile de pe link -uri în rețea
pentru toate routere pe care se execută ingineria traficului. În acest capitol, puteți vedea ce fel de
informații tr ebuie să fie transmise și cum OSPF au fost extinse pentru a transporta aceste
informații de TE.

3.2. Protocolul IGP

Protocolul de rutare interior rețelei (IGP) trebuie să fie capabil să transmită toate
informațiile de topologie (starea de legături) 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 zo nă știe toate căile alternative, pentru a ajunge la destinație. 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, informațiile cu p rivire la căile
alternative sunt pierdute.
Routerul de la capul tunelui cu TE (headend) trebuie să dispună de toate informațiile de
topologie pentru a vedea toate căile posibile, dar acesta trebuie să aibă, de asemenea, toate
informațiile legate de constr ângerile de pe link -urile pe care le are la dispoziție. Protocolul de
rutare de tip link -state trebuie să fie extins pentru a obține această resursa de informații
suplimentare.
Resursele de inginerie a traficului de pe un link sunt:
 metrica TE
 latimea de banda maximă
 lățimea 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. Lățimea de bandă maximă este lățimea de bandă totală de pe un link.
Lățimea de bandă maximă rezervabila este, evident, lățimea de bandă la dispoziția TE pe link;
cea nerezervabila este data de lățimea totală minus lățimea deja rezervată.
Grupul administrativ este un câmp de 32 de biți. Operatorul de rețea pot stabili individual,
fiecare bit din acest domeniu pe 32 de biți și poate avea un sens ales de el. De exemplu, un bit ar
putea să însemne că link -ul este o legătură cu o viteză de 48kbps, sau un link care este
intercontinental, sau un link care are o întârziere 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 când acestea se schimbă în valoare sau la intervale regulate.

3.3. Extensii OSPF

RFC 2370 descrie o extensie a protocolului OSPF prin care cele trei noi anunțuri 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 informații pentru a fi utilizate de
către OSPF sau direct de către orice aplicație. Aceste LSA -uri sunt exact ceea ce MPLS TE are
nevoie pentru a pune în OSPF. OSPF poate apoi inunda această informație în întreagă rețea.
Trei tipuri de LSA -uri există, diferă doar în domeniul de aplicare a inundațiilor. LSA de
tipul 9 aplicat numai pe link -local; de tip 10 are un domeniu de aplicare a inundațiilor care este
de zonă largă, și opac 11 are un tip de inundații, 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 către routerul de la zona de f rontieră (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 câmpul opțiuni al OSPF. Acest bit
poate indica dacă este un router capabil de trimitere și pri mire de LSA -uri opace. Câmpul opțiuni
este prezent în mesajele OSPF Hello, pachetele ce descriu baza de date (database description),
precum și în toate LSA -urile.
LSA -ul TE de tip 10 opac poartă una sau mai multe Valori ale Tipului de Lungime ( Type
Lengt h Value – TLV). Un TLV permite OSPF sa transporte date într -un mod flexibil. Figura de
mai jos arată 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. Puteți vedea că resursele de pe link -după cum s -a menționat în secțiunea
anterioară, sunt prezente.
Nume Valoare in octeti
Link type (tipul legaturii) 1
ID-ul legaturii 4
Adresa IP de pe interfața locală 4

Adresa IP de pe stația distantă 4
Metrica TE 4
Banda maximă 4
Banda maximă ce poate fi rezervată 4
Banda nerezervată
„32 (4 octeți pentru fiecare ni vel de
prioritate de la 0 la 7)
Grupul Administrativ 4
Tabelul 4.
Operarea și Dirijarea pe B ază de Constrangeri în MPLS TE (Constraint -Based Routing –
CBR)

Cea mai importantă cerința a TE este aceea a caracteristicilor, precum și a disponibilității
resurselor, pe link -urile din rețea (în plus față de lățimea de bandă care ar putea fi folosita pentru
calculul costului) se propagă în întreaga rețea pentru a permite alegerea pe cât de eficient posibil
a cailor LSP cu TE. În protocoalele de dirijare link -state calea preferata, încă predominant, ia în
considerare lățimea de bandă pe link -ul dintre două routere pentru a calcula costul sau metrica
asociată cu această cale.
Activarea utilizării eficiente a protocoalelor link -state de a culege în mod eficient
informații referitoare la disponibilitatea resurselor în mesajele de rutare este efectuată de către
extensiile suplimentare la funcționarea reală a protocolului de rutare. Mecanica de funcționare
implică inundații la actualizările în rețea, la schimbarea sta tusului unui link, schimbarea metricii
sau a bandei disponibile. Resursele atribute sunt inundate de routere în rețea pentru a le face
disponibile de routerul headend în tunelul TE în timpul calcului LSP -ului (tunele dinamice).
Mesajele link -state transpo rta informații cum ar fi listele cu routerele de vecini, rețeaua de
resurse, precum și alte informații relevante legate de disponibilitatea resurselor reale ce ar putea
fi necesare mai târziu pentru a efectua un calcul SPF pe bază de constrângeri. OSPF și IS-IS au
fost furnizate cu extensii pentru a permite utilizarea lor într -un mediu MPLS TE pentru a
propaga informații legate de disponibilitatea resurselor.

3.4. Calcularea și s tabilirea căii

3.4.1. Funcționalitate SPF

În mod normal în procesul de calcul SPF, un ro uter se plasează pe sine, la cap de arbore
cu cele mai scurte căi calculate pentru fiecare dintre destinații, doar ținându -se cont de traseul cu
cea mai mică metrică sau cost până la locul de destinație.
Intr-un protocol de rutare link -state, fiecare ro uter stie despre toate celelalte routere din
retea si link -urile care conecteaza aceste routere. In OSPF aceasta informatie este codata in
LSA(Link -State Advertisments); in IS -IS aceasta informatie este LSP(Link -State Packets),pentru
a nu se confunda cu La bel-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 1 9. O topologie simpl ă pentru a demonstra algoritmul SPF

Acest exempl u (Figura 18.) 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.

Tabelul 5. Potrivirea claselor de planificare
In calculul SPF, fiecare router mentine doua liste:
 lista a nodurilor care sunt cunoscute a fi pe calea cea mai scurta spre destinatie.
Aceasta lista este numita lista PATH.
 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 numeste lista TENT sau TENTative.

Fiecare lista este o tabela de tripleti {router,distanta,next -hop} din perspectiva routerului
care calculeaza.
Algoritmu l care calculeaza calea cea mai scurta pentru fiecare nod este simpla. Fiecare
router urmeaza urmatorul algoritm:
Pune “self” in lista PATH cu distanta 0 si urmatorul hop(next -hop) el(“self”=root node)

Tabelul 6. Lista PATH și TENTE pentru Routerul A

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 (next –
hop) nodul PATH, in afara de cazul in care vecin ul 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 7.

Tabelul 7. Listele PATH ș i TENTE pentru Routerul A după pasul 2

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 e ste 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 8 reflecta l istele PATH si TENTE la acest pas.

Tabelul 8. Listele PATH ș i TENTE pentru Router A dup ă pasul 3

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 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 9
reflecta listele PATH si TENTE la acest punct.

Tabelul 9. Listele PATH și TENTE pentru Routerul A dup ă pasul 4

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 mutat a din lista TENTE in lista PATH este aratat in
Tabelul 10.

Tabelul 10 Listele PATH și TENTE pentru Routerul A dup ă pasul 5

Ia 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 11.

Tabelul 11. Listele PATH și TENTE pentru Routerul A dup ă pasul 6

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

Tabelul 12 Listele PATH și TENTE pentru Routerul A dup ă pasul 7: Lista TENTE este goal ă

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

Tabelul 13. Tabel de rutare a Routerului A

Figura 20. Rețeaua vazută 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 pre a
mare(10).

3.4.2. Funcționalitate 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.
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 in tre 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 decât costul pe link pentru a
identifica căile care pot fi utilizate pentru drumuri LSP cu ingineria traficului. Decizia este
efectuată la rou terul headend după eliminarea tuturor link -urile care nu respectă un anumit
criteriu, cum ar fi cerințele de lățime 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 următo rul hop care
formează LSP. Prin urmare, mai multe LSP -uri cu TE ar putea fi folosite de CSPF pentru a
identifică link -uri în rețea care să corespundă criteriilor. În plus, utilizatorul poate configura

static un tunel TE sau LSP pe routerul headend specifi cându -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ă c um se va vorbi în capitolul următor. RSVP, astfel, este utilizat
împreună cu rezultatele calculate de către CSPF sau de lista de hopuri configurate de către
utilizator pentru LSP. De notat că LSP -ul format este unidirecțional.
În caz de egalitate a const rangerilor, calea cu cea mai mare lățime de bandă are prioritate,
urmat de cel mai mic număr de hopuri. Dacă tot este egal, CSPF alege o cale, la întâmplare.
Prin urmare, succesiunea de pași în crearea unui tunel MPLS TE în rețea este, după cum
urmează:
Pasul 1. Calculul CSPF se face la routerul headend pe baza constrângerilor definite în
tunel și cerințelor. Acest calcul este efectuat de către IGP în continuare, fie OSPF sau IS -IS.
Pasul 2. După ce calea LSP este calculată pe baza procesului CSPF, rezu ltatul 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 rezervări de resurse și confirmare pe LSP, cum
sunt definite de procesul CSPF, pentr u a determina dacă LSP îndeplinește cerințele specifice
resurselor solicitate in definirea tunelului.
Pasul 4. După ce procesul de RSVP primește un mesaj de rezervare, acesta semnaleaza
că LSP -ul este acum stabilit.
Pasul 5 . La acest punct, un tunel TE e ste 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 încât interfața tunel sa fie adaugata în tabelul de rutare.

Figura 21. O topologie simpl ă ce demonstreaz ă 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 lati me 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 disponibi li, 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 14.

Tabelul 14 Listele PATH ș i TENTE dup ă pasul 1
2. Pune vecinul routerului A in lista TENTE. Rezultatul este aratat in Tabelul 15.

Tabelul 15. Listele PATH și TENTE pentru Routerul A dup ă 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 16.

Tabelul 16. Listele PATH și TENTE pentru Routerul A dup ă pasul 3

{C,8,B,50} nu este adaugat in lista T ENTE 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. Rezultatul este aratat in Tabelul 17.

Tabelul 17. Listele PATH și TENTE pentru Route rul A dup ă 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 algor itmul se incheie.Rezultatul este aratat in Tabelul 18.

Tabelul 18 Listele PATH și TENTE pentru routerul A dup ă 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 TEN TE 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 ca lea 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 treb ui 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.

Figura 22. O rețea simpl ă în care sunt necesare c riterii de diferen țiere pentru CSPF
In aceasta topologie sunt cinci cai posibile de la A la Z,de la P1 la P5.In Tabelul 19 sunt
listate atributele cailor.

Tabelul 19 Atributele celor cinci c ăi 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 band a 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 acce ptabila 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
-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 al resurselor 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) consumabi la de -a lungul caii respective
Aceasta semnalare este indeplinita folosind RSVP, impreuna cu extensiile RSVP pentru
MPLS TE.
3.5.1. Bazele RSVP

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 mentin e rezervarea resurselor
din retea. In MPLS TE RSVP rezerva latimea de banda la nivelul planului de control (control –
plane).
RSVP are trei functii de baza:
-setarea caii si mentinerea ei
– ruperea caii (path teardown)
-semnalarea erorii

RSVP este un prot ocol soft -state. Asta inseamna ca are nevoie sa improspateze periodic
rezervarile din retea prin resemnalizarea lor. Acest lucru este diferit fata de un protocol hard –
state a carui semnalari sunt cerute o data dupa care se presupune ca acea cerere este up pana este
explicit pusa down. [RFC3210]

In Tabelul 20 sunt listate noua tipuri de mesaje diferite ce definesc RSVP.

Tipul mesajului Descrierea

Path Folosit sa seteze si sa mentina rezervarile
Resv(scurtatura
pentru
Reservation) Trimis ca raspuns la mes ajele Path pentru a seta si a mentine
rezervarile
PathTear Analog cu mesajele Path, dar sunt folosite sa inlature rezervarile din
retea
ResvTear Analog cu mesajele Resv, dar sunt folosite sa inlature rezervarile din
retea
PathErr Trimis de primitorul me sajului Path care detecteaza o eroare in
mesaj
ResvErr Trimis de primitorul mesajului Resv care detecteaza o eroare in
mesaj
ResvConf Optional trimite inapoi la expeditorul mesajului Resv, pentru a
confirma ca rezervarea data s -a realizat
ResvTearConf Este un mesaj prioritar Cisco analogul mesajului ResvConf.Folosit
sa confirme ca o anumita rezervare a fost inlaturata din retea
Hello O extensie definita in RFC 3290 care permite link -urilor locale
keepalives intre doi vecini RSVP direct conectati
Tabel ul 20. Tipul mesajelor RSVP
3.5.2. Semnalizarea și operațiunile RSVP -TE

A. Semnalizarea

RSVP rezervă o lățime de bandă de -a lungul unui drum de la o anumită sursă la
destinație. Mesajele RSVP sunt trimise de către routerul cap (headend) într -o rețea 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 funcționează în
calitate de final pentru tunelul cu TE.
Cele patru mesaje principale f olosite 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 rețelei pe cale
de-a lungul unui viitor LSP cu TE. La fiecare hop, mesajul verifică disponibilitatea resurselor
solicitate și stochează aceste informații. O alta functie a mesajului RSVP PATH este de a cere o

etichetă MPLS cu TE pe cale, cerere generata de la head end și care se propagă în aval (pe
downstream).
Mesajele RSVP PATH sunt rutate prin intermediul rețelei 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 lățimea de bandă și face o cerere de
etichetă. În cele din urmă, mesajul de cale ajunge la coada, care returnează un mesaj RESV către
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 răspuns la mesajul PATH. Mesajul RSVP de REZERVARE îndeplinește
funcția 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 până la headend. [RFC3210]

Figura 23. Mesajele RSVP Path și 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 24. Mesajele de eroare RSVP

Mesaje de incheiere (tear down) – RSVP creează două tipuri de mesaje de incheiere, și
anume, mesaj de incheie re 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 reușit rezervare de resurse pe link va genera o eroare de RSVP PATH și un mes aj de
incheiere de rezervare la headend.

B. Operațiunile

Așa cum am menționat mai devreme, rezultatul unei CSPF sau calcul CBR pe routerul
headend este o listă ordonata de adrese IP care identifică următorii pasi de -a lungul drumului
într-un tunel cu T E 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ă informații
despre routere din calea tunelului cu TE prin sem nalizare RSVP pentru a solicita și a confirma
disponibilitatea resurselor pentru tunel. RSVP cu extensii pentru TE rezervă resurse
corespunzătoare cu privire la fiecare LSR în calea definita de headend și atribuie etichete de
mapare a tunelului cu TE.
Pașii urmați 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 l a următorul hop de pe calea tunelului sau LSP.
Pasul 2. Când urmatorul hop primește acest mesaj PATH, routerul verifică obiectul
EXPLICIT_ROUTE, pentru a vedea dacă următorul hop este direct legat în rețea. Acest lucru
este verificat în bitul L al mesajul ui de cale RSVP . În cazul în care bitul L este setat, routerul nu

este direct conectat la următorul hop în calea tunelui LSP. Prin urmare, routerul va efectua un
calcul de SPF constrâns (CSPF) pentru a stabili următorul/urmatoarele hop/hopuri în tunel. În
cazul în care bitul L este unset, routerul lcoal știe că aceasta este direct legat de următorul hop în
calea LSP al tunelului. Se indeparteaza apoi toate intrările în EXPLICIT_ROUTE de mapare
pentru routerul local și înainteaza mesajul PATH la următorul h op, cum sunt definit în obiectul
EXPLICIT_ROUTE. În plus, acest router va adăuga interfața de ieșire spre următorul hop în
câmpul RECORD_ROUTE.
Pasul 3 . Procesul se repetă la următoarele hopuri.
Pasul 4. Cand mesajul RSVP PATH este primit de routerul tail end, 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 când acesta generează un mesaj de rezervare, routerul
atribuie o etichetă la tunelul LSP. M esajul de rezervare are acum obiectul RECORD_ROUTE
care să indice ce interfață de ieșire de pe router tailend duce spre headend router. Prin urmare,
obiectul RECORD_ROUTE este reinitializat în mesajul RESERVATION.
Pasul 5. Obiectul LABEL(etichetă) cu mapă rile pentru LSP este, de asemenea, generat.
Pasul 6 . Acest proces se repetă din nou pe calea inversă.
Pasul 7. Când routerul cap primește mesajul de rezervare, acestă va menține din
RECORD_ROUTE noua rută cu cerințele date în SESIUNE, cu ingineria traficu lui setată,
învățata prin RSVP -TE față de calea LSP normală.

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 Mesaj de tipul Functia
LABEL_REQUEST
(cerere de eticheta) PATH Folosit pentru a cere o mapare de etichete la tunelul cu TE sau
LSP; generat de routerul headend intr -un mesaj de tip cale.
LABEL
(eticheata) RESERVATION Folosit pentru a aloca mapări de etichete la tunelul cu TE sau
LSP; genera t de routerul tailend într -un mesaj de rezervare.
EXPLICIT_ROUTE
(cale explicita) PATH Purtat într -un mesaj de cale si folosit pentru a cere sau a
confirma o cale/ruta specifică pentru un tunel.
RECORD_ROUTE
(cale invatata) PATH,
RESERVATION 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.
SESSION_ATTRIBUTE
(atributele sesiunii) PATH Folosit pentru a defini atribute specifice sesiunii de tunel, cum
ar fi cerințele de bandă necesare.
SESSION
(sesiunea) PATH Definește sursa si capătul tunelului. De obicei identificate prin
adrese IP ale adreselor loopback corespunzătoare interfețelor
de pe headend și tailend .
Tabelul 21.

3.5.3. Setarea și m enținerea căii

A. Setarea căii

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 ER O- 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 25. Mesajul RSVP: PATH ș i RESV in timpul setarii c ăii 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:

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 capat ul, trimite
si implicit -null
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 trimit e 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.

A. Menținerea căii

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.

B. Ruperea căii

Daca un nod (in general capatul tunelului) decide ca o rezervare nu mai este necesara in
retea, trimit un me saj PathTear pe aceasi cale urmata de mesajele Path si se primesc mesajele
ResvTear pe aceasi ca le 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 cap atul tunelului a indepartat rezervarile din
retea.
PathTear si ResvTear pot fi deasemenea trimise in raspuns la o eroare in retea.

C. Semnalarea erorii

Ocazional pot exista erori in semnalarea RSVP. Aceste erori sunt semnalate prin mesajele
PathErr sau Resv Err. 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.

3.5.4. Pachete 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.

Figura 26. Formatul antetului RSVP

Campul Descrierea
Version Versiunea protocolului RSVP.
Flags Nu este definit deocamdata nici un flag.
Message Type 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 Lungi mea mesajului RSVP in bytes, inclusiv
header -ul comun.RSVP Lenght este
intotdeauna cel putin 8.
Tabelul 22. Câmpurile din header -ul RSVP.

Formatul claselor de obiecte RSVP(RSVP Object Class Formats)
Toate obiectele RSVP au acelasi format de baza, cum est e ilustrat in Figura 26.

Figura 27. Formatul obiectului RSVP

In Tabelul 23 sunt descrise campurile din formatul obiectului de baza RSVP.

Camp Descriere
Object Lenght Lungimea obiectului RSVP, inclusiv obiectul

header.Trebuie sa fie multiplu de 4.
Class-Num Clasa obiectului.
C-Type The object’s class type.C -Type este un numar
unic din clasa.
Object Contents Obiectul insusi.
Tabelul 23. 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 24.

Tabelul 24. 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 caracte rizarea mesajului.
In Tabelul 23 sunt listate clasele si C -Type folosite in implementarea Cisco a RSVP -TE.

Tabelul 25. Obiectul RSVP C -Types

3.5.5. Operații RSVP

A. 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 permit e
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 d e 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 tunel ului. Endpoint Address este RID -ul cozii
tunelului. Extended Tunnel ID este ori numai 0 ori adresa IP a routerului. Tunnel ID este
numarul interfetei tunelului din capat. LSP ID este o “instanta de numarare”; de cate ori un tunel
isi schimba cerintele de l argime de banda sau calea pe care o ia, LSP ID se incrementeaza.

Figura 28. Nevoia de Make -Before -Break
Presupunand ca in Figura 27 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 Transmisia lui R1 Actiunea lui R2
1 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. Dirijeaza rezervarea catre R5. Marcheaza
interfata R2 ->R5 ca avand rezervat 35Mb
pentru acest tunel si 65Mb rezervabili.
2 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 Examineaza rezervarea si realizeaza ca aceasta
este ide ntica 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

rezervare Res2 largime de banda pe link -ul R2 ->R5. Link -ul
R2->R5 este marcat cu 80Mbps rezervati si
20Mbps nerezervati.
Tabelul 26. Pasii în 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.

B. Modul de lucru al mecanismului de actualizare

RSVP este un protocol soft -state: rezervarile sunt actualizate periodic. Rezervarile sunt
trimise folosind mesajele Path si Res v. Nu exista diferenta intre mesajele Path si Resv folosite
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 e xista
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 int re 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 actu alizare 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 secu nde 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).

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

Figura 29. Mesajele Path ș i Resv sunt trimise independent

Cand, unde, si cui ii sunt trimise mesajele?
Exista noua tipuri de me saje RSVP(cum am mentionat si mai devreme). Tabelul 27
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.

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 inlocuias ca acel hop slab cu noul set generat de hopuri precise.

Mesajul Functia Directia Adresa
Destinatie Router
Alert?
Path Semnaleaza o cerere de
resurse in retea Aval Capat Da
Resv Raspunsul la un mesaj
Path reusit Amonte Urmatorul hop
(next -hop) nu
PathEr r Trimis catre capatul
tunelului daca exista o
eroare in mesajul Path Amonte Urmatorul hop
(next -hop) nu
ResvErr Trimis catre sfarsitul
tunelului daca exista o
eroare in procesarea
mesajului Path Aval Urmatorul hop
(next -hop) nu
PathTear Trimis catre sfa rsitul
tunelului pentru a inlatura
o rezervare existenta Aval Sfarsitul tunelului da
ResvTear Trimis catre capatul
tunelului pentru a inlatura
o rezervare existenta Amonte Urmatorul hop
(next -hop) nu
ResvConf Trimis ca raspuns la Resv
sau ResvTear care a cerut
confirmarea mesajului Aval Sfarsitul tunelului da
ResvConfTear Trimis in raspuns la
ResvTear care include si
mesajul de confirmare Aval Urmatorul hop
(next -hop) nu
Hello Trimis la un vecin RSVP
sau pe un link direct
conectat Amonte/Aval Urmatorul hop
(next -hop) nu

Tabelul 27 Tipul mesajelor RSVP
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 pe nultimul 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 în MPLS

A. Protecție ș i 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):
 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 co nvearga 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 tun el 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 d e 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
 protectia locala:
o protectia linkului
o 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 es te 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 30. Protecț ia căii

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
link-ului 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 a re cateva avantaje in comparatie cu protectia caii:o recuperare asupra
esecului mai rapida,1:N scalabilitate, consuma mai putin din starea retelei.

Figura 31. Elementele protec ției locale
Termen Definitie
PLR Point of Local Repair(Punctul local Reparat) – capatul
tunelului backup 12008a este un PLR.
MP Merge Point(Punctul de unire) – punctul de unire este acolo
unde tunelul backup se termina.EX :7200c.
NHop Next -hop router(Router next -hop) – un router care este la o
departare de un hop fata de PLR.Ex:12 008c.
NNHop Next -next-hop router(Routerul next -next-hop) – un router care
este la doua hopuri distanta de PLR. Ex:7200c este NNHop
pentru PLR 12008a.
Tabelul 28. Terminologia folosită în protecț ia local ă

“tunel backup”=”tunel de protectie”=”tunel FRR”

Protectia link -ului

Protectia link -ului poate fi divizata in patru sectiuni :
 configuratia inaintea esecului (prefailure)
o se configureaza pe capatul tunelului TE pe interfata tunelului care se
doreste protejat
o pe PLR: activand FRR pe PLR implica doua lu cruri:
 crearea unui tunel backup pe Nhop
 configurarea link -ului protejat sa foloseasca tunelul backup dupa
esec

Figura 32. Protecț ia Link -ului

 detectia esecului
o 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 33. Detec ția eșecului folosind RSVP Hellos

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
o imediat ce este detectat un esec, PLR este responsabil pentru comutarea
traficului pe tunelul backup. Procesarea interna realizata pe PLR implic a
urmatoarele :
o asigurarea ca backup -ul LSP pre -semnalizat este stabilit. Aceasta include
noua eticheta prevazuta pentru noul vecin din aval.
o noua informatie de adiacenta(incapsularea de nivel 2) este calculata pe
baza interfetei fizice de ie sire a tunelului backup.
o emnalizarea dupa esec(post – failure)
o semnalizarea RSVP care se intampla dupa ce protectia FRR a avut loc se
poate imparti in urmatoarele:
 semnalizarea in amonte

Figura 34. PathErr far ă protec ție local ă

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.
Pentru semnalizarea info rmatiei 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
minimiz area pierderi i de pachete.

Figura 35. PathErr cu protec ție local ă

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 schim bari 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 ini tiala ,
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 .
 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 confi gurat 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 raportea za 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 36. PathTear în absen ța FRR
Cand link -ul dintre 12008a si 12008c devine down(c and 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 activ at: “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 l a 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 tunelulu i 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 do wn. Acest lucru este realizat asigurandu -ne ca MP(12008c)
continua sa primeasca mesajele Path pentru LSP -ul primar pe tunelul backup.

4. Calitatea serviciilor în rețelele MPLS

4.1. Noțiuni generale

QoS si MPLS sunt pe un anumit nivel politi c 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). Când au aparut primele drafturi
despre MPLS, au fost rezervati 3 biti pentru a transpo rta 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 ce l
mai adesea o copie) a bitilor Precedenta din IP. Arhitectura MPLS si -a dorit sa se integreze
bine cu protocolul IP si sa fie cât mai independenta de protocolul de nivel 2. Astfel s -a ales
sa se ofere suport pentru Diffserv, în detrimentul suportului QoS ofe rit de ATM.
Aceasta decizie a dus la o simplificare majora a implementarii MPLS, obtinând
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 fur nizate de IGP. Respectarea restrictiilor impuse se poate rezolva prin
dimensionarea retelei cu atât de multa banda încât 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 m etrica
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 mecani smele 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 spr e 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 c lientului. 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
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 distinct e 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 câmpul EXP al antetului etichetei MPLS. Câmpul EXP are 3 biti, ceea ce
înseamna ca se pot defini pâna la 2³ = 8 clase de servicii diferite.
• A doua metoda este utilizarea de etichete diferite pentru clase de servicii diferite.

4.2. Implementarea QoS

4.2.1. Modelele utilizate

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
consider are 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, a tunci 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 prop unea 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 host -uri. Nodurile din retea creau stari si alocau resursele hosturilor care solicitau anumite
garantii. În cazul în car e negocierea au succes, garantiile oferit e de IntServ sunt
deterministe.
Din celalalt punct de vedere, DiffServ a fost vazut ca o tehnologie scalabila, care
nu împovareaza nodurile din centrul retelei, obligându -le sa faca multe prelucrari .

El foloseste clasificarea pachetelor pe marginea domeniului si un sistem de cozi cu
prioritati în centrul retelei.

A. 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 de zavantajul 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 necesita tea acestuia
de a rula capat la capat (astfel trecând 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 sca labilitatii 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.
MPLS poate folosi RSVP pentru distrib utia de etichete, folosind anumite
extensii ale acestuia. Diferenta fata de primul caz consta în rularea RSVP doar în
reteaua core, având nodurile de granita ca si capete. Acest lucru reduce mult numarul de
entitati comunicante , crescând scalabilitatea solutiei. Al doilea avantaj consta în faptul ca
rezervarea se face acum pe clase de echivalenta, si nu pe fluxuri individuale, reducând mai mult
numarul de semnalizari si stari ce trebuiesc folosite. În functie de cât 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 intermedi are ajusteaza
informatiile din TSpec în functie de cât pot rezerva în momentul respectiv. Nodul
destinatie aloca eticheta, dar face si cererea de rezervare a resurselor. Calea este
mentinuta atâta timp cât se primesc peri odic 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 folosit a. 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, dac a calea secundara nu poate fi construita, calea principala ramâne î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 c are 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, as tfel neavând 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
RSVP -TE poate sa nu fie foarte scalabil.

B. Modelul Serviciilor Diferenț iate

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 compon ente 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 reparti zare î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
va marca traficul c a fiind neconform.
Tot nodul de intrare va asocia traficul într -un Agregat de Comportament (BA –
Behaviour Aggregate) pe baza unuia sau mai multor câmpuri din antetul de nivel 3.
Dupa aceasta actiune fiecare pachet este mar cat 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 (P er Hop Behaviour). Acest PHB specifica
câte 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 37. Arhitectura DiffServ
Clasificarea pachete lor

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 DSC P 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 câmpuri, folosindu -se
un clasificat or multicâmp.

Clasificarea pachetelor IP

Pachetele IP pot fi clasificate usor. Se pot face comparatii dupa orice câmp IP, dar în
general se foloseste adresa IP destinatie, adresa IP sursa sau valoarea DSCP. În plus se mai
poate face si analiza de niv el 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 vârful stivei.

Nodurile de intrare n u 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 r etea sunt de tip IP. Totusi, sunt câteva 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 fu rnizor, 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 strâns 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 va loarea 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 când furnizorul taxeaza în plus unii clienti
pentru Qo S extra. Când 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 câmpul Precedenta din IP pentru a hotarî tipul de trata ment 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 ved ere al
marcarii calitatii serviciilor. Initial exista un câmp 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 câmpul ToS folosind 6 biti pentru marcarea tratamentului
dorit pentru pachet, (ac est lucru formând câmpul 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 DSCP (zecimal) DSCP (binar)
Best effort 0 000000
AF11 10 001010
AF12 12 001100
AF13 14 001110
AF21 18 010010
AF22 20 010100
AF23 22 010110
AF31 26 011010
AF32 28 011100
AF33 30 011110
AF41 34 100010
AF42 36 100100
AF43 38 100110
EF 46 101110

Tabelul 29. Clase de trafic folosite în Diff serv

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 traf ic, dar face garantii minimale asupra
întârzierii.
EF a fost definit pentru a servi trafic care cere o întârziere minima, un jitter
minim si o pierdere minima de pachete. Nu este nevoie de mai multe clase de tip EF deoarece
acestea a r concura pentru aceleasi resurse. [RTC] [MPLS -TE]

Marcarea pachetelor MPLS

Problema care poate aparea atunci când se doreste stabilirea unei
corespondente de la DSCP la EXP este faptul ca DSCP este stocat pe 6 biti, pe când EXP ocup a
doar 3 biti. În retelele în care MPLS functioneaza în modul cadru (spre deosebire
de retelele în care functioneaza în modul celula – peste linkuri ATM) se folosesc cei 3 biti EXP
pentru codificare. Astfel, este nevoie ca mai mul te 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 f olosind 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 s i 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 cozi lor folosite, dar si pentru a reduce debitul surselor TCP. Astfel,
când 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 ca re nu mai au loc sa intre.
În acest scop se poate folosi Weighted Random Early Detection.

4.2.2. Implementarea QoS prin MPLS

Tehnologia MPLS a fost dezvoltata astfel încât sa fie compatibila cu protocolul IP. De
fapt scopul primar al acesteia este de a transpor ta 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).

Figura 38. Func ționarea MPLS QoS
În Figura 36 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 impl ementare. Pur si simplu se copiaza bitii IP
Precedence în câmpul 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 bi tii 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. Comutat ia 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 p oate 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 a ltui
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 ne cesite criptarea datelor atunci când 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 afl a în raza de actiune a
respectivului satelit.

Implementarea functiilor QoS în cadrul infrastructurii unei retele MPLS ofera o serie de
beneficii, atât pentru furnizorii de servicii Internet, cât si pentru clienti. În ceea ce îi priveste pe
furnizorii de s ervicii, î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 I P. De exemplu,
furnizorii de servicii pot sa clasifice pachetele fara a tine cont de nivelul de prioritate pe care îl
are pachetul atunci când ajunge la primul router de transport. De asemenea, ei pot sa tina cont de
aceasta prioritizare initiala si sa apl ice una suplimentara. Beneficiile pe care le poate oferi
implementarea functiilor QoS clientilor sunt evidente, ei putând sa se bazeze pe anumite debite
minime, pe o criptare adecvata, etc., si asta într -o conexiune cap la cap.

DiffServ -Aware Traffic Engi neering (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 trafi c 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.

4.3. Detectarea de erori MPLS

In cont inuare vom analiza procesul de detectie de erori si protocoale in retelele MPLS,
inclusive detectia unui LSP invalid, precum si recupararea LSP.

Separarea int re planul de control si de date

Separarea intre planul de control si de date este direct atribu ita formatului si
evolutiei unui pachet OAM. Formatul unei etichete de tip stiva, ce reprezinta header -ul pentru
pachetele MPLS, este format dintr -o eticheta valoare (20 biti), bitii EXP (3 biti), bit -ul S (1 bit),
si TTL (8 biti).
Pentru a face diferent a intre un pachet OAM si un pachet de tip date, se pot folosi diferite
metode. ITU -T Y.1711 foloseste o eticheta de tip stiva cu doua intrara. Prima eticheta are aceeasi
valoare ca eticheta de transport, asigurand ca in majoritatea cazurilor pachetele OAM pot fi
rutate pe aceeasi cale ca pachetul user. A doua eticheta are o valoare speciala rezervata, 14,
pentru a fi dirferentiata de pachetul user. Totusi, introducerea celei de -a doua etichete poate sa
nu fie complet compatibila cu algoritmul de echilibra re a sarcinilor deja existent, ca atare poate
sa nu functioneze corect in retelele ECMP deja existente. Mai mult, in retelele unde se foloseste
PHP, pot aparea mai multe limitari, acest lucru fiind subliniat in tabelul 30.

Y.1711 MPLS ping/traceroute
Hardware “Probabil” are nevoie de un
hardware now (scalabilitate,
manipulare TTSI,…) Foloseste hardware -ul existent
Aplicabilitate  In principal un
mechanism de detective
 Conexiune de tip punct –
la-punct LSP
 Detectie de LSP de tip
conexiune eronata,
brans a eronata  In principal o metoda de
depanare
 LDP, RSVP -TE, orice alta
metoda de semnalare
MPLS
 Detectarea consistentei
FEC
 Depanare: localizarea
problemei si depistarea
hop-by-hop
Favorabil ECMP NU, foloseste etichete rezervate,
poate afecta echilibrarea
sarcinilor daca ECMP apare in
timpul unui LSR DA, algoritmi ECMP ce vor
verifica toatea cele 127/8 adrese
Favorabil PHP Exista o limitare in functie de
tipul de PHP (16) DA
Scalabilitatea/Frecventa  Injectarea de pachete la
fiecare secunda
 Necesita adminis trarea
TTSI
 Calculari BIP 16
 Frecventa este impusa
de operator
 Foloseste informative
native
 Verificare ciclica a
redundantei IP
Acord privind nivelul serviciilor NU NU
Tabelul 30. Y.1711 versus func ționalitatea ping/trace MPLS

O alta optiune este de a separa pachetle OAM de pachetele data prin folosirea de sarcina
MPLS un pachet specific de IP destinat unui port deja cunoscut, precum in MPLS ping.
In acest caz eticheta de transport este acceasi ca in pachetul de date. Aceasta metoda,
totusi, presupune ca adresa destinatie sa fie o adresa non -rutabila, pentru a asigura ca pachetul IP
va fi procesat de routerul processor al router -ului de “iesiri” In acest caz se permita suportul PHP
si un ECMP limitat.

Alte metode de a separa planul de control de date s unt moduri hibride, unde un pachet
OAM poate fi identificat ca o eticfeta specifica sau prin folosirea unui camp specific din pachet
ce face posibila recunoasterea usoara. VCCV (Verificarea Conectivitatii Circuitelor Virtuale) se
bazeaza pe aceasta tehnica .

Detectia unei etichete LSP esuate

Esuarea unei etichete LSP necesita testarea de fluxuri de pachete, inafara de erori de
tip network, deoarece in multe instante fluxul de pachete poate fi intrerup fara a fi sesizata
reteaua (link -ul/nodul). Acest lucr u poate fi cauzat de probleme in tabela de routare, unei
legaturi de etichete eronate, aglomerarea retelei, sau alte cause.
Verificarea conectivitatii, precum si ping/traceroute unei functii OAM sunt sugerate
pentru acest tip de detectari de erori. Implem entarea acestor protocoale poate fi diferita,
depinzand de technologia pachetului.
Indiferent de tehnologia folosita, este important ca pachetele OAM sa foloseasca
aceeasi cale ca pachetele de date obisnuite.

Scenarii de defectare LSP

ITU-T Y.1711 a stan dardizat functia de verificarea conevtivitatii (CV), in timp ce
detectia de redirectionare bidirectionala (BFD) este studiata de IETF.
Figura 4.3.1.1 arata diferite scenario de defectare.
A’ si B’ sunt receptorul intentionat pentru A si B, respective.
Scenariile de defectare sunt:
a) Pierderea de conexiune
b) Conexiunea eronata
c) Conexiune schimbata
d) Fuzionarea gresita
e) Loop/ replicare neintentionata

Figura 3 9.

4.4. Protecția și recuperarea MPLS

Protectie si recuperarea pot fi de tip local sau global. Protecti a globala I se aplica unui
LSP de tip end -to-end, in timp ce protectia locala I se aplica unui link sau nod eronat. Protectia
locala in general da un timp de convergenta mai mic fiindca mesajul eronat este procesat de
notdul local (link protection) sau an nod imediat adiacent (node protection). Timpul de
convergenta este de circa 50 ms, fiind unul acceptabil. Protectia cailor necesita un timp de
convergenta mai mare, deoarece mesajele de eroare trebuie sa se propage catre capatul retelei,
ceea ce initiaza m ecanismul de protective.
Cea mai simpla metoda este 1+1 si 1:1 arhitectura de protectie de comutare specificat de
ITU-T Y.1720.
In arhitectura 1+1, traficul este copiat si trimis catre LSP -ul actual si cel de protective,
simultan. Astfel, LSP -ul de protect ive poate fi folosit pentru a transmite alt traffic cand nu este
folosit.
Bazat pe protocolul de semnalizare folosit, sunt posibile diferite optiuni. De exemplu, o
retea de tip LDP se poate baza pe o convergenta IGP rapida sip e o disponibilitate ridicata pentru
imbunatatirile de tip LDP. O retea de tip RSVP_TE permite folosirea de multiple cai explicite
cand semnalizeaza un LSP. Mai mult, RSP_TE a fost imbunatatit pentru a permite repararea
locala a unui tunel LSP prin realizarea unei “evitari” LSP ce oern ute un singur tunel de backup
pentru a proteja LSP -urile primare (modelul de portectie n:m).

4.5. Mentenanța serviciilor de tip punct -la-punct și
multipunct

Furnizorii de servicii de telecomunicatii au asigurat de mult timp servicii punct -la-punct,
cu cadrul OAM deja dezvoltat.
Tipic, interfetele utilizator -retea (UNI) sunt folosite pentru a caracteriza punctele de
atasament ale clientului/furnizorului. In cazul multipunct, N>2, este nevoie de UNI, fiecare UNI
avand un profil de trafic receptionat (traficul in jectat in serviciul furnizorului) si un profil de
trafic trimis (traficul de iese din reteaua furnizorului). Pentru un UNI dat, traficul receptionat
poate fi trimis catre toate celelalte UNI, catre unele UNI, sau catre oricare alt UNI, depinzand de
servici ul furnizat. Poate fi necesar ca QOS sa fie initializat, ceea ce implica definirea de pierdere
de pachete si de intarzieri garantate. Asemenea garantii poate sunt necesare sa fie puse pe fiecare
UNI, intrucat vitezele interfetelor diferitelor link -uri pot fi implicate.
Odata definite SLA -urile, problema consta in reservarea de resurse pentru a asigura
performanta obiectivelor din SLA0uri, si realizarea de ingineria traficului la serviciile
multipunct. In final, protectia necesara va fi adresata pentru servi ciile multipunct, din moment ce

metoda de protectie pe fiecare ruta folosita pentru serviciile punct -la-punct poate sa nu scaleze cu
serviciile multipunct, avand N*(N -1) rute implicate intr -un serviciu multipunct de N noduri, in
special daca QOS este impli cat.

5. Simularea practică folosind GNS3

Pentru aceasta simulare am folosit 10 routere model C3600, utilizand imaginea C3640 –
JK.BIN din figura 38.
Topologia propusa este urmatoarea:

Figura 40. 10 Routere model C3600

In ceea ce priveste configurarea OSPF am definit Aria 0 pentru toata topologia iar conexiunile
dintre routere sunt de tip punct la punct.

Figura 41.

Din punct de vedere al implementarii MPLS BGP ruterele P sunt reflectori de rute pentru
ruterele PE. În mod n ormal, un ruter iBGP menține sesiuni cu toate celelalte routere iBGP din
AS, formând o topologie logica full -mesh (fiecare cu fiecare). Acest lucru este necesar deoarece,
pentru a preveni formarea de cicluri de rutare, iBGP nu transmite rute învățate prin iBGP altor
vecini care rulează iBGP. Dacă se dorește ca ruterele iBGP să schimbe rute BGP între ele, este
necesară configurarea de reflectori de rute.
Liniile albastre reprezinta interconectarea iBGP standard intre P1 si P2 iar liniile negre
reprezinta int erconectarea iBGP in cazul reflectorilor de rute.

Figura 4 2.

Rutarea dintre ruterele PE si CE este exemplificata pe scurt in urmatoarea diagrama :

Figura 4 3.

Configurare MPLS -TE
1. Am configurat o interfata de loopback pentru asocierea cu tunelul M PLS-TE interface
Loopback0 ip address 10.0.1.1 255.255.255.255
2. In a doua etapa am pornit MPLS -TE la nivel global precum si la nivel de interfata. Dau
exemplu interfata seriala 1/0 ce face legatura cu ruterul P1

mpls traffic -eng tunnels

interface Seria l1/0
description Connected to P1 S1/0
ip address 10.1.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown

3. Dupa ce interfetele care participa in MPLS -TE au fost configurate, pr ecum si activarea
la nivel global a MPLS -TE, pasul urmator este configurarea interfetei tunelului. Configurarea
principala in acest caz consta in asocierea adresei IP a interfetei tunelului cu interfata de
loopback configurata anterior, modul de operare in cadrul tunelului precum si adresa de
destinatie pentru capatul tunelului care se va mapa pe adresa de loopback a routerului ce
reprezinta adresa de destinatie. Daca pentru drumul ales LSP se foloseste utilizand IGP sau
CSPF atunci optiunea folosita va fi „dynamic”. De asemenea in configuratia standard interfata
tunelului nu este anuntata in IGP pentru a fi folosita in tabela de rutare, din aceasta cauza am
configurat explicit ca ca interfata tunelului sa fie folosita ca next hop in tabela de rutare a IGP.
Ca exemplu evidentiez configurarea tunelului intre ruterele PE1 si PE2.

interface Tunnel2
ip unnumbered Loopback0
tunnel destination 10.0.1.2
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 2 dynamic
tunnel mpls traffic -eng au toroute announce

4. Ultimul pas in configurarea MPLS -TE este definirea pentru IGP, in cazul nostru OSPF
a suportului pentru Traffic engineering. Am ales configurarea pentru ruterul PE1 drept exemplu.

router ospf 65000
router -id 10.0.1.1
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.1.1 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0

network 10.1.2.2 0.0.0.0 area 0

Verificare configuratie efectuata

5. Cu ajutorul comenzii show mpls traffic -eng tunnels brief vom afisa to ate tunele MPLS –
TE create.

Figura 4 4.
6. Daca dorim sa detaliem informatiile despre un anumit tunel cu ajutorul comenzii show
mpls traffic -eng tunnels tunnel -name putem obtine aceste informatii. De exemplu am inserat
comanda pentru tunelul PE1_t2 care fa ce legatura intre ruterele PE1 si PE2 trecand prin
reflectorul de rute P2.

Figura 4 5.

7. De altfel daca dorim sa aflam tunele MPLS -TE care au ca destinatie de exemplu ruterul
PE2 cu IP -ul 10.0.1.2 cu ajutorul comenzii show mpls traffic -eng tunnels dest ination 10.0.1.2
putem afla aceste informatii.In urma rularii se poate observa din imaginea alaturata ca ruterul
PE2 este destinatie pentru doua tunele respectiv PE1_t2 si PE3_t2

Figura 4 6.

8. Daca dorim sa interogam atributele rutelor de tip MPLS -TE d efinite pe un ruter cu
ajutorul comenzii show mpls traffic -eng link -management interfaces putem realiza acest lucru. In
urmatoarea captura evidentiez atributele rutelor configurate pentru ingineria traficului pe ruterul
PE1

Figura 4 7.

9. Pentru a arata vecinii IGP precum si ID -ul rutei prin care pot fi ajunsi folosim comanda
show mpls traffic -eng link -management igp -neighbors care va genera urmatorul rezultat in urma
rularii pentru ruterul PE1

Figura 4 8.

10. Afisez rezultatul comenzii show mpls traf fic-eng tunnels summary care afiseaza
informatii referitoare la activarea TE, RSVP ca urmare evidenta a activarii TE si informatii
legate de semnalizarea LSP

Figura 4 9.
Pe langa configurarea de tunele MPLS_TE am introdus si conceptul de MPLS -VPN in
cadru l aceluiasi sistem autonom folosind ca protocol Ipv4 MPBGP cu distributie de etichete. Mai
jos voi descrie sumar pasii pe care i -am urmat in aceasta configurare.

11. Am definit doua VRF pe toate ruterele PE precum si RD (route distinguisher) pentru
acest ea. RD este utilizat pentru a distinge rutele VPN provenind de la mai multi clienti care se
conecteaza la ruterele de provider, in cazul nostru ruterele PE.Dau ca exemplu configurarea
efectuata pe ruterul PE1 celelalte rutere PE avand configurarea similara .Precizez ca valoarea
64512 provine de la sistemul autonon definit pentru BGP pe ruterele de clienti VRF.
ip vrf vrf1
rd 64512:1
route -target both 64512:1
!
ip vrf vrf2
rd 64512:2
route -target both 64512:2

12. Am asociat VRF interfetelor care fac le gatura cu ruterele de clienti VRF
interface Serial1/2
description Connected to VRF1 -CE1 S1/0
ip vrf forwarding vrf1
ip address 192.168.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/3
description Conne cted to VRF2 -CE1 S1/0
ip vrf forwarding vrf2
ip address 192.168.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown

13. In urmatorul pas voi exemplifica configurarea ca reflector de rute pentru ruterul P1,
pentru ruterul P2 confi guratia este identica.
address -family vpnv4 unicast
neighbor MPLS route -reflector -client
neighbor MPLS send -community extended
neighbor 10.0.1.1 peer -group MPLS
neighbor 10.0.1.1 activate
neighbor 10.0.1.2 peer -group MPLS
neighbor 10.0.1.2 activate
neighbor 10.0.1.3 peer -group MPLS
neighbor 10.0.1.3 activate
neighbor 10.0.1.4 peer -group MPLS
neighbor 10.0.1.4 activate
no auto -summary

14. Configurarea conectivitatii MPBGP intre ruterele PE si reflectorii de rute.Voi
exemplifica configuratia pen tru ruterul PE1 pe celelalte rutere PE configuratia fiind similara.

router bgp 65000
no synchronization
bgp router -id 10.0.1.1
timers bgp 12 36
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
neighbor MPLS send -community extended
no auto -summary
!
address -family vpnv4 unicast
neighbor 10.0.0.1 peer -group MPLS
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 peer -group MPLS
neighbor 10.0.0.2 activate

15. La ultimul pas am configurat BGP ca protocol d e rutare intre ruterele PE si ruterele
VRF

address -family ipv4 vrf vrf1
neighbor 192.168.1.1 remote -as 64512
neighbor 192.168.1.1 as -override
neighbor 192.168.1.1 activate
maximum -paths 2
no auto -summary
no synchronization

exit-address -family
!
address -family ipv4 vrf vrf2
neighbor 192.168.1.1 remote -as 64512
neighbor 192.168.1.1 as -override
neighbor 192.168.1.1 activate
maximum -paths 2
no auto -summary
no synchronization
exit-address -family

Optiunea as -override se refera la faptul ca prev enirea buclelor de rutare in BGP se face
prin verificarea numarului sistemului autonom AS in cadrul traseului sistemului autonom.Daca
ruterul care primeste vede propriul numar AS in atributul AS din cadrul pachetului BGP primit,
pachetul va fi dropat.Ruter ul care primeste presupune ca pachetul a originat din AS propriu si ca
a ajuns din acelasi loc din care a plecat, din cauza aceasta actionand in acest mod.Optiunea
descrisa face in asa fel incat numarul sistemului autonom a ruterului de la care provine pac hetul
va fi schimbat pe parcurs de catre rutere.

16. Pe ruterele VRF am configurat BGP redistribuind rutele conectate in BGP.
Configuratia exemplificata este pentru ruterul VRF1 -CE1

router bgp 64512
redistribute connected
timers bgp 12 36
neighbor 1 92.168.1.2 remote -as 65000
neighbor 192.168.1.6 remote -as 65000
no auto -summary
no synchronization

Am oprit sincronizarea deoarece toate ruterele din configuratie ruleaza BGP, iar
dezactivand aceasta optiune ofera posibilitatea de a duce mai putine rut e in IGP si de a reduce
timpul de convergenta al protocolului BGP

Concluzii

Bibliografie

Anexa 1. Codul Sursă

Configuratie ruter P1:

hostname P1
!
no ip domain -lookup
!
ip cef
!
mpls traffic -eng tunnels
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/0
description Connected to P2 Fa0/0
ip address 10.1.0.1 255.255.255.252
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface FastEthernet2/0
description Connected to P2 Fa2/0
ip address 10.1.0.5 255.255.255.252
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown !
interface Serial1/0
description Connected to PE1 S1/0
ip address 10.1.1.1 255.25 5.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/1
description Connected to PE2 S1/0
ip address 10.1.1.5 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/2
description Connected to PE3 S1/0
ip address 10.1.1.9 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point

no shutdown
!
interface Serial1/3
description Connected to PE4 S1/0
ip address 10.1.1.13 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
router ospf 65000
router -id 10.0.0.1
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.0.1 0.0.0.0 area 0
network 10.1.0.0 0.0.0.7 area 0
network 10.1.1.0 0.0.0.15 area 0
!
router bgp 65000
no synchronization
bgp router -id 10.0.0.1
timers b gp 12 36
neighbor 10.0.0.2 remote -as 65000
neighbor 10.0.0.2 update -source Loopback0
neighbor 10.0.0.2 send -community
extended
neighbor MPLS peer -group
neighbor MPLS remote -as 65000 neighbor MPLS update -source Loopback0
!
address -family vpnv4 unica st
neighbor MPLS route -reflector -client
neighbor MPLS send -community extended
neighbor 10.0.1.1 peer -group MPLS
neighbor 10.0.1.1 activate
neighbor 10.0.1.2 peer -group MPLS
neighbor 10.0.1.2 activate
neighbor 10.0.1.3 peer -group MPLS
neighbor 10.0. 1.3 activate
neighbor 10.0.1.4 peer -group MPLS
neighbor 10.0.1.4 activate
no auto -summary
!
ip classless
no ip http server
!
no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
end

Configuratie ruter P2:

hostname P2
!
no ip domain -lookup
!
ip cef
!
mpls traffic -eng tunnels
!
interface Loopback0
ip address 10.0.0.2 255.255.255.255
!
interface FastEthernet0/0
description Connected to P1 Fa0/0
ip address 10.1.0.2 255.255.255.252
mpls traffic -eng tunnels
ip ospf netw ork point -to-point
no shutdown
!
interface FastEthernet2/0
description Connected to P1 Fa2/0
ip address 10.1.0.6 255.255.255.252
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
! interface Serial1/0
description Connected to PE1 S 1/1
ip address 10.1.2.1 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/1
description Connected to PE2 S1/1
ip address 10.1.2.5 255.255.255.252
encaps ulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/2
description Connected to PE3 S1/1
ip address 10.1.2.9 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffi c-eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/3

description Connected to PE4 S1/1
ip address 10.1.2.13 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
router ospf 65000
router -id 10.0.0.2
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.0.2 0.0.0.0 area 0
network 10.1.0.0 0.0.0.7 area 0
network 10.1.2.0 0.0.0.15 area 0
!
router bgp 65000
no synchronization
bgp router -id 10.0.0.2
timers bgp 12 36
neighbor 10.0.0.1 remote -as 65000
neighbor 10.0.0.1 update -source Loopback0
neighbor 10.0.0.1 send -community
extended
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
!
address -family vpnv4 unicast neighbor MPLS route -reflector -client
neighbor MPLS send -community extended
neighbor 10.0.1.1 peer -group MPLS
neighbor 10.0.1.1 activate
neighbor 10.0.1.2 peer -group MPLS
neighbor 10.0.1.2 activate
neighbor 10.0.1.3 peer-group MPLS
neighbor 10.0.1.3 activate
neighbor 10.0.1.4 peer -group MPLS
neighbor 10.0.1.4 activate
no auto -summary
!
ip classless
no ip http server
!
no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End

Config uratie ruter PE1:

hostname PE1

!
no ip domain -lookup
!
ip vrf vrf1
rd 64512:1
route -target both 64512:1
!
ip vrf vrf2
rd 64512:2
route -target both 64512:2
!
ip cef
!
mpls traffic -eng tunnels
!
interface Loopback0
ip address 10.0.1.1 255.255.255.255
!
interface Tunnel2
ip unnumbered Loopback0
tunnel destination 10.0.1.2
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 2
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel3
ip unnumbered Loopback0
tunnel destinati on 10.0.1.3 tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 3
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel4
ip unnumbered Loopback0
tunnel destination 10.0.1.4
tunnel mode mpls traffic -eng
tunnel mpls traffi c-eng path -option 4
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Serial1/0
description Connected to P1 S1/0
ip address 10.1.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/1
description Connected to P2 S1/0
ip address 10.1.2.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point

no shutdown
!
interface Serial1/2
description Connected to VRF1 -CE1 S1/0
ip vrf forwarding vrf1
ip address 192.168.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!

interface Serial1/3
description Connected to VRF2 -CE1 S1/0
ip vrf forwarding vrf2
ip address 1 92.168.1.2 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router ospf 65000
router -id 10.0.1.1
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.1.1 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
network 10.1.2.2 0.0.0.0 area 0
!
router bgp 65000 no synchronization
bgp router -id 10.0.1.1
timers bgp 12 36
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
neighbor MPLS send -community extended
no auto -summary
!
address -family vpnv4 unicast
neighbor 10.0.0.1 peer -group MPLS
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 peer -group MPLS
neighbor 10.0.0.2 activate
!
address -family ipv4 vrf vrf1
neighbor 192.168.1.1 remote -as 64512
neighbor 192.168.1. 1 as-override
neighbor 192.168.1.1 activate
maximum -paths 2
no auto -summary
no synchronization
exit-address -family
!
address -family ipv4 vrf vrf2
neighbor 192.168.1.1 remote -as 64512
neighbor 192.168.1.1 as -override
neighbor 192.168.1.1 activate

maximum -paths 2
no auto -summary
no synchronization
exit-address -family
!
ip classless
no ip http server
!
no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
end

Configuratie ruter PE2:

hostname PE2
!
no ip domain -lookup
!
ip vrf vrf1
rd 64512:1
route -target both 64512:1
! ip vrf vrf2
rd 64512:2
route -target both 64512:2
!
ip cef
!
mpls traffic -eng tunnels
!
interface Loopback0
ip address 10.0.1.2 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 10.0.1.1
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 1
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel3
ip unnumbered Loopback0
tunnel destination 10.0.1.3
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 3
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel4
ip unnumbered Loopback0

tunnel destination 10.0.1.4
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 4
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Serial1/0
description Connected to P1 S1/1
ip address 10.1.1.6 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/1
description Connected to P2 S1/1
ip address 10.1.2.6 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/2
description Connected to VRF1 -CE1 S1/1
ip vrf forwa rding vrf1
ip address 192.168.1.6 255.255.255.252
encapsulation ppp no peer neighbor -route
no shutdown
!
interface Serial1/3
description Connected to VRF2 -CE1 S1/1
ip vrf forwarding vrf2
ip address 192.168.1.6 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router ospf 65000
router -id 10.0.1.2
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.1.2 0.0.0.0 area 0
network 10.1.1.6 0.0.0.0 area 0
network 10.1.2.6 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router -id 10.0.1.2
timers bgp 12 36
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
neighbor MPLS send -community extended
no auto -summary

!
address -family vpnv4 unicast
neighbor 1 0.0.0.1 peer -group MPLS
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 peer -group MPLS
neighbor 10.0.0.2 activate
!
address -family ipv4 vrf vrf1
neighbor 192.168.1.5 remote -as 64512
neighbor 192.168.1.5 as -override
neighbor 192.168.1.5 activate
maxi mum -paths 2
no auto -summary
no synchronization
exit-address -family
!
address -family ipv4 vrf vrf2
neighbor 192.168.1.5 remote -as 64512
neighbor 192.168.1.5 as -override
neighbor 192.168.1.5 activate
maximum -paths 2
no auto -summary
no synchronizat ion
exit-address -family
!
ip classless
no ip http server
! no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End

Configuratie ruter PE3:

hostname PE3
!
no ip domain -lookup
!
ip vrf vrf1
rd 64512:1
route -target both 64512:1
!
ip vrf vrf2
rd 64512:2
route -target both 64512:2
!
ip cef
!
mpls traffic -eng tunnels
!

interface Loopback0
ip address 10.0.1.3 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 10.0.1.1
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 1
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel2
ip unnumbered Loopback0
tunnel destination 10.0.1.2
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 2
dynamic
tunnel mp ls traffic -eng autoroute announce
!
interface Tunnel4
ip unnumbered Loopback0
tunnel destination 10.0.1.4
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 4
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Serial1/0
description Connected to P1 S1/2 ip address 10.1.1.10 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/1
description Connected to P2 S1/2
ip address 10.1.2. 10 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/2
description Connected to VRF1 -CE2 S1/0
ip vrf forwarding vrf1
ip address 192.168.1.10 255.255.255. 252
encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/3
description Connected to VRF2 -CE2 S1/0
ip vrf forwarding vrf2
ip address 192.168.1.10 255.255.255.252

encapsulation ppp
no peer neighbor -route
no shutdown
!
router ospf 65000
router -id 10.0.1.3
mpls traffic -eng area 0
mpls traffic -eng router -id Loopback0
network 10.0.1.3 0.0.0.0 area 0
network 10.1.1.10 0.0.0.0 area 0
network 10.1.2.10 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router -id 10.0.1.3
timers bgp 12 36
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
neighbor MPLS send -community extended
no auto -summary
!
address -family vpnv4 unicast
neighbor 10.0.0.1 peer -group MPLS
neighbor 10.0.0.1 a ctivate
neighbor 10.0.0.2 peer -group MPLS
neighbor 10.0.0.2 activate
! address -family ipv4 vrf vrf1
neighbor 192.168.1.9 remote -as 64512
neighbor 192.168.1.9 as -override
neighbor 192.168.1.9 activate
maximum -paths 2
no auto -summary
no synchroniza tion
exit-address -family
!
address -family ipv4 vrf vrf2
neighbor 192.168.1.9 remote -as 64512
neighbor 192.168.1.9 as -override
neighbor 192.168.1.9 activate
maximum -paths 2
no auto -summary
no synchronization
exit-address -family
!
ip classless
no ip http server
!
no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!

End

Configuratie ruter PE4:

hostname PE4
!
no ip domain -lookup
!
ip vrf vrf1
rd 64512:1
route -target both 64512:1
!
ip vrf vrf2
rd 64512:2
route -target both 64512:2
!
ip cef
!
mpls traffic -eng tunnels
!
interface Loopback0
ip address 10.0.1.4 255.255.255.255
!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 10.0.1.1
tunnel mode mpls traffic -eng tunnel mpls traffic -eng path -option 1
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Tunnel2
ip unnumbered Loopback0
tunnel destination 10.0.1.2
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 2
dynamic
tunnel mpls traffic -eng autoroute announce
!
interfac e Tunnel3
ip unnumbered Loopback0
tunnel destination 10.0.1.3
tunnel mode mpls traffic -eng
tunnel mpls traffic -eng path -option 3
dynamic
tunnel mpls traffic -eng autoroute announce
!
interface Serial1/0
description Connected to P1 S1/3
ip address 10. 1.1.14 255.255.255.252
encapsulation ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!

interface Serial1/1
description Connected to P2 S1/3
ip address 10.1.2.14 255.255.255.252
encapsulation ppp
no pe er neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point
no shutdown
!
interface Serial1/2
description Connected to VRF1 -CE2 S1/1
ip vrf forwarding vrf1
ip address 192.168.1.14 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/3
description Connected to VRF2 -CE2 S1/1
ip vrf forwarding vrf2
ip address 192.168.1.14 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router ospf 65000
router -id 10.0.1.4
mpls traffic -eng area 0 mpls traffic -eng router -id Loopback0
network 10.0.1.4 0.0.0.0 area 0
network 10.1.1.14 0.0.0.0 area 0
network 10.1.2.14 0.0.0.0 area 0
!
router bgp 65000
no synchronization
bgp router -id 10.0.1.4
timers bgp 12 36
neighbor MPLS peer -group
neighbor MPLS remote -as 65000
neighbor MPLS update -source Loopback0
neighbor MPLS send -community extended
no auto -summary
!
address -family vpnv4 unicast
neighbor 10.0.0.1 peer -group MPLS
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 peer -group MPLS
neighbor 10.0.0.2 activate
!
address -family ipv4 vrf vrf1
neighbor 192.168.1.13 remote -as 64512
neighbor 192.168.1.13 as -override
neighbor 192.168.1.13 activate
maximum -paths 2
no auto -summary
no synchronization

exit-address -family
!
address -family ipv4 vrf vrf2
neighbor 192.168.1.13 remote -as 64512
neighbor 192.168.1.13 as -override
neighbor 192.168.1.13 activate
maximum -paths 2
no auto -summary
no synchronization
exit-address -family
!
ip classless
no ip http server
!
no cdp run
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End

Configuratie ruter VRF1 -CE1:

hostname VRF1 -CE1
!
no ip domain -lookup !
ip cef
!
interface Loopback0
ip address 10.255.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.10 .1 255.255.255.0
no keepalive
! No keepalive with force the line protocol
up
no shutdown
!
interface Serial1/0
description Connected to PE1 S1/2
ip address 192.168.1.1 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/1
description Connected to PE2 S1/2
ip address 192.168.1.5 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router bgp 64512
redistribute connected

timers bgp 12 36
neighbor 192.168.1.2 remote -as 65000
neighbor 192.1 68.1.6 remote -as 65000
no auto -summary
no synchronization
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End

Configuratie ruter VRF1 -CE2:

hostname VRF1 -CE2
!
no ip domain -lookup
!
ip cef
!
interface Loopback0
ip address 10.255.0.2 255.255.255.255
!
interface FastEthernet0/0 ip address 10.10.20.1 255.255.255.0
no keepalive
! No keepalive with force the line protocol
up
no shutdown
!
interface Serial1/0
description Connected to PE3 S1/2
ip address 192.168.1.9 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/1
description Connected to PE4 S1/2
ip address 192.168.1.13 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router bgp 64512
redistribute connected
timers bgp 12 36
neighbor 192.168.1.10 remote -as 65000
neighbor 192.168.1.14 remote -as 65000
no auto -summary
no synchronization
!
ip classless

no ip http server
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End

Configuratie ruter VRF2 -CE1:
hostname VRF2 -CE1
!
no ip domain -lookup
!
ip cef
!
interface Loopback0
ip address 10.255.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
no keepalive
! No keepalive with force the line protocol
up
no shutdown
!
interface Serial1/0
description Connected to PE1 S1/3
ip address 192.168.1.1 255.255.255.252 encapsulation ppp
no peer neighbor -route
no shutdown
!
interface Serial1/1
description Connected to PE1 S1/3
ip address 192.168.1.5 255.255.255.252
encapsulation ppp
no peer neighbor -route
no shutdown
!
router bgp 64512
redistribute connected
timers bgp 12 36
neighbor 192.168.1.2 remote -as 65000
neighbor 192.168.1.6 remote -as 65000
no auto -summary
no sy nchronization
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
end
Configuratie ruter VRF2 -CE2:

hostname VRF2 -CE2
!
no ip domain -lookup
!
ip cef
!
interface Loopback0
ip address 10.255.0.2 255.255. 255.255
!
interface FastEthernet0/0
ip address 10.10.20.1 255.255.255.0
no keepalive
! No keepalive with force the line protocol
up
no shutdown
!
interface Serial1/0
description Connected to PE3 S1/3
ip address 192.168.1.9 255.255.255.252
encapsulat ion ppp
no peer neighbor -route
no shutdown
!
interface Serial1/1
description Connected to PE4 S1/3
ip address 192.168.1.13 255.255.255.252
encapsulation ppp
no peer neighbor -route no shutdown
!
router bgp 64512
redistribute connected
timers bgp 12 36
neighbor 192.168.1.10 remote -as 65000
neighbor 192.168.1.14 remote -as 65000
no auto -summary
no synchronization
!
ip classless
no ip http server
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
!
End