MPLS și analiza conceptului de inginerie a traficului [611844]

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

Bucure ști
2017

MPLS și analiza conceptului de inginerie a traficului

Р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ță Rețele și Software de Telecomunicații

Соnduсătоr ștііnțіfіс Αbѕоlvеnt
Prof. Dr. Ing. Roxana ZOICAN Dan Cristian GOLEA

2

3

4

5

6

7
С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 capaci tate ………………………….. ………………………. 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 ………………………….. ………………………….. ………………………… 26
2. Rețele de tip MPLS ………………………….. ………………………….. ………………………….. …………. 27
2.1. Noțiuni generale ………………………….. ………………………….. ………………………….. …………… 27
2.2. Operarea MPLS ………………………….. ………………………….. ………………………….. …………… 28
2.2.1. Definiții și terminologie MPLS ………………………….. ………………………….. ……………….. 28
2.2.2. Elemente MPLS ………………………….. ………………………….. ………………………….. ………… 31
2.2.3. Arhitectura unui nod MPLS ………………………….. ………………………….. ………………….. 34
2.3. Funcționarea MPLS ………………………….. ………………………….. ………………………….. ……… 41
2.3.1. Faza de control ………………………….. ………………………….. ………………………….. …………. 41
2.3.2. Dirijarea pachetelor ………………………….. ………………………….. ………………………….. ….. 41
2.3.3. Operația LSR Packet – based ………………………….. ………………………….. ………………… 42
2.3.4. Penultimate Hop Popping ………………………….. ………………………….. ………………………. 43
2.4. Protocoale MPLS ………………………….. ………………………….. ………………………….. …………. 44
3. Ingineria traficului în rețelele MPLS ………………………….. ………………………….. ……………. 55
3.1. Ingineria de trafic ………………………….. ………………………….. ………………………….. ………… 55
3.1.1. Necesitate ………………………….. ………………………….. ………………………….. ………………….. 55
3.1.2. Mod de lucru ………………………….. ………………………….. ………………………….. …………….. 57
3.2. Protocolul IGP ………………………….. ………………………….. ………………………….. ……………… 59
3.3. Extensii OSPF ………………………….. ………………………….. ………………………….. ………………. 60
3.4. Calcularea și stabilirea căii ………………………….. ………………………….. ……………………….. 61
3.4.1. Funcționalitate SPF ………………………….. ………………………….. ………………………….. …… 61
3.4.2. Funcționalitate CSPF ………………………….. ………………………….. ………………………….. … 66

8
3.5. Protocolul de rezervare al resurselor RSVP ………………………….. ………………………….. . 70
3.5.1. Bazele RSVP ………………………….. ………………………….. ………………………….. …………….. 71
3.5.2. Semnalizarea și op erațiunile RSVP -TE ………………………….. ………………………….. ….. 72
3.5.3. Setarea și menținerea căii ………………………….. ………………………….. ………………………. 75
3.5.4. Pachete RSVP ………………………….. ………………………….. ………………………….. …………… 77
3.5.5. Operații RSVP ………………………….. ………………………….. ………………………….. ………….. 81
3.6. Administrarea TE în MPLS ………………………….. ………………………….. ………………………. 86
4. Calitatea serviciilor în rețelele MPLS ………………………….. ………………………….. …………… 95
4.1. Noțiuni generale ………………………….. ………………………….. ………………………….. …………… 95
4.2. Implementarea QoS ………………………….. ………………………….. ………………………….. ……… 96
4.2.1. Modelele utili zate………………………….. ………………………….. ………………………….. ………. 96
4.2.2. Implementarea QoS prin MPLS ………………………….. ………………………….. …………… 102
4.3. Detectarea de erori MPLS ………………………….. ………………………….. ……………………….. 103
4.4. Protecția și recuperarea MPLS ………………………….. ………………………….. ……………….. 106
4.5. Mentenanța serviciilor de tip punct -la-punct și multipunct ………………………….. …… 107
5. Simularea practică folo sind GNS3 ………………………….. ………………………….. ……………… 109
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …. 121
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. 123
Anexa 1. Codul Surs ă ………………………….. ………………………….. ………………………….. …………… 127

9
Liѕtа fіgurіlоr

Figura 1.1. Corespondența nivel OSI – protocoale de rețea [1] ………………………….. ……………….. 20
Figura 2. 1. Stiva de protocoale [4] ………………………….. ………………………….. ………………………….. 27
Figura 2.2. Arhitectura unei rețele MPLS [35] ………………………….. ………………………….. …………. 30
Figura 2.3. LSP – Label Switched Path ………………………….. ………………………….. ……………………. 31
Figura 2.4. Domeniul MPLS [36] ………………………….. ………………………….. ………………………….. . 32
Figura 2.5 Arhitectura Edge LSR [38] ………………………….. ………………………….. …………………….. 33
Figura 2.6. Antet MPLS [4] ………………………….. ………………………….. ………………………….. ………. 35
Figura 2.7. Packet -Based LSR Operation with a Single Level Stack [37] ………………………….. … 42
Figura 2.8. Operația LSR Packet -Based cu o stivă de etichete multinivel [37] ………………………. 43
Figura 2.9. Penultimate Hop Popping [37] ………………………….. ………………………….. ………………. 44
Figura 2.10. Descoperirea vecinilor [15] ………………………….. ………………………….. …………………. 48
Figura 2.11. Diagrama de stări și tranziții a LDP [15] ………………………….. ………………………….. .. 49
Figura 2.12. Modelul rutării bazate pe constrângeri [15] ………………………….. ………………………. 51
Figura 3.1. Dirijarea în rețele IP [10] ………………………….. ………………………….. ………………………. 55
Figura 3.2. Dirijarea cu ingineria traficului [10]………………………….. ………………………….. ……….. 56
Figura 3.3. O topologie simplă pentru a demonstra algoritmul SPF [10] ………………………….. ….. 62
Figura 3.4. Rețeaua vazută de Routerul A dupa rularea a lgoritmului SPF [10] ……………………… 65
Figura 3.5. O topologie simplă ce demonstrează algoritmul CSPF [10] ………………………….. …… 67
Figura 3.6. O rețea simplă în ca re sunt necesare criterii de diferențiere pentru CSPF [10] …….. 69
Figura 3.7. Mesajele RSVP Path și Reservation [23] ………………………….. ………………………….. … 73
Figura 3.8. Mesajele de eroare RSVP [23] ………………………….. ………………………….. ………………. 73
Figura 3.9. Mesajul RSVP: PATH și RESV in timpul setarii căii LSP [23] ………………………….. 76
Figura 3.10. Formatul antetului RSVP [23] ………………………….. ………………………….. ……………… 78
Figura 3.11. Formatul obiectului RSVP [23] ………………………….. ………………………….. ……………. 79
Figura 3.12. Nevoia de Make -Before -Break [5] ………………………….. ………………………….. ……….. 82
Figura 3.13. Mesajele Path și Resv sunt trimise independent [5] ………………………….. …………….. 84
Figura 3.14. Protecția căii [35] ………………………….. ………………………….. ………………………….. ….. 87
Figura 3.15. Elementele p rotecției locale [35] ………………………….. ………………………….. ………….. 88
Figura 3.16. Protecția Link -ului [35] ………………………….. ………………………….. ………………………. 89
Figura 3.17. Detecția eșecului folosind RSVP Hellos [35] ………………………….. …………………….. 90
Figura 3.18. PathErr fară protecție locală [35] ………………………….. ………………………….. …………. 91
Figura 3.19. PathErr cu protecție locală [35] ………………………….. ………………………….. …………… 92
Figura 3.20. PathTear în absența FRR [35] ………………………….. ………………………….. ……………… 93
Figura 4.1. Funcționarea MPLS QoS [4] ………………………….. ………………………….. ……………….. 102
Figura 4.2. Scenarii de defectare LSP ………………………….. ………………………….. ……………………. 106
Figura 5.1. Topologia simulării ………………………….. ………………………….. ………………………….. .. 109
Figura 5.2. Zona OSPF ………………………….. ………………………….. ………………………….. …………… 110
Figura 5.3. Zona BGP ………………………….. ………………………….. ………………………….. …………….. 111
Figura 5.4. Rutarea PE – CE………………………….. ………………………….. ………………………….. …….. 111

10
Figura 5.5. Afișarea tunelelor MPLS -TE ………………………….. ………………………….. ……………….. 113
Figura 5.5. Afisarea detaliata a PE1_t2 ………………………….. ………………………….. …………………. 114
Figura 5.6. Afișarea tunelelor cu destinația 10.0.1.2 ………………………….. ………………………….. .. 115
Figura 5.7. Afișarea atributelor rutelor configurate pentru ingineria traficului pe PE1 …………. 116
Figura 5.8. Afișarea vecinilor IGP ………………………….. ………………………….. ……………………….. 116
Figura 5.9. Afișarea scurtă a stărilor TE si LSP ………………………….. ………………………….. ……… 117

11
Lіѕtа tabelelor

Tabelul 1.1 Comp arație tipuri de protocoale IP ………………………….. ………………………….. ………… 26
Tabelul 2.1. Valori de etichetă rezervate ………………………….. ………………………….. …………………. 35
Tabelul 2.2 Etichete LDP [15] ………………………….. ………………………….. ………………………….. …… 47
Tabelul 3.1. Resursele sub -TLVs ………………………….. ………………………….. ………………………….. .. 60
Tabelul 3.2. Potrivirea claselor de planificare ………………………….. ………………………….. ………….. 62
Tabelul 3.3. Lista PATH și TENTE pentru Routerul A ………………………….. ………………………… 63
Tabelul 3.4. Listele PATH și TENTE pentru Routerul A după pasul 2 ………………………….. ……. 63
Tabe lul 3.5. Listele PATH și TENTE pentru Router A după pasul 3 ………………………….. ……… 63
Tabelul 3.6. Listele PATH și TENTE pentru Routerul A după pasul 4 ………………………….. …… 64
Tabelul 3.7. Listele PATH și TENTE pentru Routerul A după pasul 5 ………………………….. …… 64
Tabelul 3.8. Listele PATH și TENTE pentru Routerul A după pasul 6 ………………………….. …… 64
Tabelul 3.9 Listele PATH și TENTE pentru Routerul A după pasul 7: Lista TENTE este goală 65
Tabelul 3.10. Tabel de rutare a Routerului A ………………………….. ………………………….. …………… 65
Tabelul 3.11. Listele PATH și TENTE după pasul 1 ………………………….. ………………………….. … 67
Tabelul 3.12. Listele PATH și TENTE pentru Routerul A după pasul 2 ………………………….. ….. 68
Tabelul 3.13. Listele PATH și TENTE pentru Routerul A după pasul 3 ………………………….. ….. 68
Tabelul 3.14. Listele PATH și TENTE pentru Routerul A după pasul 4 ………………………….. ….. 68
Tabelul 3.15. Listele PATH și TENTE pentru routerul A după pasul 5 ………………………….. ……. 69
Tabelul 3.16. Atributele celor cinci căi posibile de la RtrA la Rtr Z ………………………….. ………… 70
Tabelul 3.17. Tipul mesajelor RSVP ………………………….. ………………………….. ………………………. 71
Tabelul 3.18. Definirea extensiilor RSVP ………………………….. ………………………….. ……………….. 75
Tabelul 3.19. Câmpurile din header -ul RSVP. ………………………….. ………………………….. …………. 78
Tabelul 3.20. Formatul obiectului RSVP ………………………….. ………………………….. …………………. 79
Tabelul 3.21. Clasele obiectului R SVP [23] ………………………….. ………………………….. …………….. 80
Tabelul 3.22. Obiectul RSVP C -Types [23] ………………………….. ………………………….. …………….. 81
Tabelul 3.23. Pasii în Make -Before -Break ………………………….. ………………………….. ………………. 82
Tabelul 3.24 Tipul mesajelor RSVP ………………………….. ………………………….. ……………………….. 85
Tabelul 3.25. Terminologia folosită în protecția locală ………………………….. ………………………….. 88
Tabelul 4.1. Clase de trafic folosite în Diffserv ………………………….. ………………………….. ………. 100
Tabelul 4.2. Y. 1711 versus funcționalitatea ping/trace MPLS ………………………….. ………………. 104

12

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

AF – Assured Forwarding
AS – Autonomous System
ATM – Asynchronous transfer mode
BA – Behavior aggregate
BGP – Border Gateway 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

14
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)

15
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

16

17
Introducere

De la apariția primelor informații legate de omul modern putem observa o
nevoie de comunicare alimentată de dorința de cunoaștere. Începând cu timpuri
străvechi unde principalele metode de transmitere a in formațiilor erau de la scrisori
trimise prin porumbei călători până la curieri care aveau că scop livrarea
informațiilor și protejarea acestora cu prețul vieții, până în timpuri moderne unde
omenirea a asistat la evoluții uriașe în ultimi o sută cincizeci de ani, trecând prin
mai multe dispozitive ce aveau că scop reducerea inconvenientului numit distanță.
În zilele noastre, tehnologia este punctul cheie care asigură evoluția umană.
De aceea, în fiecare zi apar tehnologii noi menite să le înlocuiască pe cele vechi,
fiecare dintre acestea aducând un plus față de predecesorul ei.
Rețelele moderne permit comunicarea prin o multitudine de tehnologii cum
ar fi telefonia, radioul, televiziunea și cel mai important, rețelele de calculatoare și
internet. Rețelele moderne pot fi de mai multe tipuri: de date – exemplu fiind
rețelele oferit e de furnizorii de internet, de voce – rețelele companiilor tradiționale
de telecomunicații, sau rețele care combină cele două tehnologii creând un tot
unitar.
Pe parc ursul aceste lucrări vom avea c a principal scop anal izarea unei astfel
de rețele și analiză performanțelor acesteia pentru diferite tipuri de implementări.
Vor fi folosite multiple implementări ale tehnologiei MPLS și vor fi studiate
fiecare dintre rețelele posibile.

18

19
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 tehnolo gii 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 o bține performanțe și randamente ridicate.
Arhitecturile actuale țin seama de necesitățile de integrare 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 ma i multe nivel e.

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: S ONET,
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 îndeplini 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 access (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 caracteristici 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 core se face transport
etc.).
 Management centralizat.
 Ingineria traficului (stabili rea căilor de rutare) care se face prin managementul
centralizat.

20
 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 perfect integrate în rețea.
 Scalabilitate, performanță, disponibilitate totală (99%). [2]

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) care are ca scop adresare a,
respectiv controlul informației ce permite pachetelor d e 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 multiplexare de protocol. Este protocolul pe baza căruia s –
au construit cele lalte protocoale IP, așa – numita suită de protocoale TCP/IP. (TCP, UDP, ICMP,
ARP, RARP, etc.).
În Figura 1.1. este reprezentată corespondența diferitelor protocoale și nivelul OSI:

Figura 1.1. Corespondența nivel OSI – protocoale de rețea [1]

21
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.). Rutarea se face
după o tabelă de rutare care specifică interfețel e ș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 ce 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 info rmaț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 cumulativă 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 con vergență. Prin urmare, este

22
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 folosind starea legăturilor (link -state routing algorithm), cunosc uț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ăturilor 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 router care a schimbat LSP -uri constru iește apoi o bază
de date l ogică 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 este utilizată pentru a actualiza tabela de rutare. Acest proce s 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 mod semnificativ capacitatea rețelei de a transporta date. Ac eastă 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ă, routerele 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. A cest 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.
Protocoalele 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ă suprasarcinile și
actualizările cu starea legăturilor. Hibriz ii echilibrați nu sunt periodici, ci conduși de evenimente,
conservând astfel lărgimea de bandă pentru aplicații reale. [1],[3],[4]

23
1.3.1. Protocoalele de rutare IP

Algoritmii de rutare pot fi împărțiți în două grupe:
 Interior Gateway Protocol (IGP) – folosit l a 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).

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 p e
baza adresării "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 route relor 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 posibilă transmiterea și a informației
de subrețea suportând astfel adresarea CIDR (Classless InterDomain Routing). Limita maximă
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 urmatoarele caracteristici de baza:

24
 RIP este un protocol al vectorului de distanță
 RIP folosește hop count ca unica metrică pentru selectarea căii
 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 o pera în 3 moduri:
 Activ – trimite și recepționează informații de rutare
 Silent – doar ascultă și primește informații de rutare (nu trimite nimic)
 Deaf – doar trimite informații de rutare (nu primește). [37]

B. Protocolul OSFP (Open Shortest Path First)

OSPF este un protocol bazat pe verificarea stării link -urilor, ruterele trimit informații
despre starea 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.
Router -ele interne trebuie să știe doar rutele către 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 Route r-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 verifica 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 routere lor din întreaga
arie (care nu este aceeași cu matricea de routere vecine).

25
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 infor mații identice despre topologie. Fiecare
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ârziere
 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. [38]

C. Protocolul EIGRP (Enhanced Interior Gateway Routi ng Protocol)

EIGRP a fost dezvoltat de către 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 protoco lului 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
îmbu nă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 robuste 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 viitor. Spre deosebire de alte protocoale de rutare bazate pe vectori -distanta,
EIGRP nu mandatează o revizuire periodică al tabelelor de rutare între rutere vecine. În schimb,
folosește un mecanism de descoperire/r ecuperare pentru a se asigura că vecinii sunt conștienți de
accesibilatea fiecaruia in parte. [39]

26
Tabelul 1. 1 Comparație tipuri de protocoale IP

D. Protocolul BGP (Border Gateway Protocol)

BGP – ul este singurul protocol de rutare între Sisteme Autonome, în principal este
folosit în ruterele de backbone pentru a schimba 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.
Traficul dintr -un AS trebuie să treacă printr -un gateway router, AS selectează care router
va îndeplini această funcție. [40]

1.3.2. Limitările tehnologiei IP

Principalele limitări ale tehnologiei IP sunt:
 Nu asigură 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 mecan ism care se bazează pe conceptul „cea mai mare
potrivire" ș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 I P este mare și complex, ceea ce duce la o proastă utilizare a
benzii de date disponibile
 Datorită mecanismului de adresare apar foarte multe adrese care sunt greu de gestionat
de rutere care posedă tabele de rutare mari implicit hardware complex. 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

27
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 util izarii tehnologiei MPLS
MPLS combină 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, care 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 comut ație de pachete orientată pe conexiune, 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 permite 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ător ului hop și eticheta care se va 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 exis tența ARPANET, predecesorul Internetului 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.
MPL S este plasat între nivelele 2 (Link) și 3 (Network) ale arhitecturii stivei de
protocoale.

Figura 2.1. Stiva de protocoale [4]

28
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 pa chetele ). 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 e ste utilizat pentru că are un beneficiu 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 permi te
furnizorului de servicii să elibereze 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 pa chetelor le este asignată o etichetă 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 înd rumare 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

• Domeniul 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 dintre 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 dir ijarii (FEC – “Forwarding
Equivalence 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 înaintea 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 c omutator MPLS
• Nod MPLS („MPLS node”) – un nod ce ruleaza MPLS, adica :
 cunoaste protocoalele de control MPLS pentru distributia etichetelor
 ruleaza unul sau mai multe tipuri de protocoale de rutare

29
 capabil sa dirijeze pachete pe baza de eticheta MPLS (d ar poate optional dirija si
pachete clasice IP)
• 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 ierarhia 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 a tunci 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). [6]

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.

30
 Î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 2.2. Arhitectura unei rețele MPLS [35]

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

31
2.2.2. Elemente MPLS

A. LSP (Label Switched Path) – cale cu co mutație de etichete

Î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 criteriului din FEC.

Figura 2.3. LSP – Label Switched Path
O cale LSP este unidirecțională, nodul care transmite pachete este numit upstream (ex.
LSR A), iar nodul care recepționează pachetul este numit downstream (ex. LSR B este
downstream pent ru LSR A).
Calea începe la un Edge Label Switching Router , care decide ce etichetă să aplice
pachetului, apoi acesta trimite pachetul către următorul ruter din cale car e înlocuiește eticheta
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ă di rijarea pachetelor printr -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 celelalte rutere care doar comută etichetele
se numesc rutere de tranzit sau Label Switching Router (LSRs).
Atunci când este necesară protej area căilor, LSP -urile pot fi :
 Primare (cele folosite working)
 Secundare (de rezervă backup)
 Terțiare

32
B. LSR – Ruter comutator de etichete

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

Figura 2.4. Domeniu l MPLS [36]
LSR este un dispozitiv 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) es te un dispozitiv a cărui funcț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 care 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.

33

Figura 2.5 Arhit ectura Edge LSR [38]
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 p achet 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 d omeniul MPLS. Ruterele configurate
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(con trol plane)
 Să dirijeze pachete sau 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ă informații de rutare indiferent de tipul LSR
 Schimbă etichete în concordanță cu tipul MPLS (cell -mode sau frame -mode)

34
Edge LSR
Acestea pot fi de intrare (ingress) sau de ieșire(egress) din rețeaua MPLS .
La intrarea într -un domeniu MPLS , ruterele ingress 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
elem entului din vârful stivei (popping) 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 prot ocol de distribuție de etichete este 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], [7], [26]

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 .

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 dirijarea 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 etichetele conținute în LIB pentru îndrumarea propriu -zisă a
pachetelor. [12]

35
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ă. E ticheta, 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 poartă
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 2.6. Antet MPLS [4]
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 etichetei 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 adre sei 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 .1. 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 ă.

36
În rutarea IP tradițională, orice pachet 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 dest inaț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. [12], [21]

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 pachet 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 „ultimu l intrat -primul ieșit”.
Deși MPLS -ul suportă 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 etich ete din stivă.
Stiva de etichete se foloseș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 etichete i 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 stive i va fi eticheta de nivel M.
Stiva de etichete 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 etichete 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ă specifi cată și apoi
adăugarea uneia sau mai multor 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ă

37
Când fluxul ajunge la u n nod al rețelei capabil să controleze entitățile de nivel inferior,
atunci comutatorul elimină eticheta din vârful stivei și examinează nivelul imediat inferior din
stivă. [12], [32]

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

O cale de reducere a cantității de spațiu consumat pentru etichete în interiorul 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 infor maț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 b aza valorii
conținută de eticheta de intrare.
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. Dir ijarea multicast necesită subînregistrări 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 tabela 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 diri jare, 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. Algoritmul 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ă valoare 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

38
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. MP LS utilizează un singur
algoritm de dirijare 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 rapidă 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. [12]

G. Tunele

Un router sursă Rs trebuie să îndrume 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 folosire a 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 „pa chete 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 u nui tunel ca o cale cu comutație de etichete ș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 urmează 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. [6]

39
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 MP LS din rețea.
Protocoalele de rutare link -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 c omutare rapidă sau Tabela de informații 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 i ntermediul 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
consis tentă cu distribuirea informației de rutare ș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 de oarece 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 baz at 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 ruta re interioare sunt folosite pentru a asigura 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 calitatea serviciilor

40
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 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.
Modulul de rutare multicast
Acest modul construiește t abela FEC folosind un protocol de rutare 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 asocierea 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 ob iective de inginerie a traficului. Utilizează 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ă tab ele 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 rua tare
specifice VPN se realizează folosind 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 rutare 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 u tilizând LDP.
După cum am văzut în cadrul 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 infor mații de control trebuie să se facă înainte
ca primul pachet de date să fie dirijat. Dirijarea pachetelor de date are loc în planul de date. [14],
[26], [30]

41
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
apartin e aceleiasi FEC – se face “legarea etichetelor” – “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 sufe ră
următoarele acțiuni :
a) Se examineaza 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 n od.
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 a ntetului.
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. [12], [26]

42
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 2.7. Packet -Based LSR Oper ation with a Single Level Stack [37]
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șire, 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. No dul 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.
[7], [30]

43

Figura 2.8. Operația LSR Packet -Based cu o stivă de etichete multinivel [37]
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ă examinez e 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ă re alizată de LSR4 poate cauza atât degradarea performanței cât și
complexitatea implementării MPLS.
Pentru a imp lementa 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 up stream, LSR2 , via LDP
folosind o etichetă specială implicit -null. Această etichetă are valoarea 3 pentru LDP.

44

Figura 2.9. Penultimate Hop Popping [37]

LSR2 elimină eticheta înainte de a trimite pachetul IP lui LSR4. LSR4 realizează apoi o
analiză de n ivel3 pe baza 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 nivel 3 poate fi dedusă din înregistrarea etichetei
căutate în LFIB. [37]

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 ac eastă 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 r utare 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 carecteristici garantate de calitate a

45
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 ru telor prin reț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 etic hete multiple 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 informe ază 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 t raficului
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 pentru:
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 unei 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 p e care le schimbă 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.

46
Aceste politici de rutare pot fi fol osite pentru 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 singure 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 de stinaț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 f olosite pentru 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 mesajele 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 co mpletate de 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 mes ajului de actualizare BGP.

47

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 fiecar e rută are propria etichetă (sau etichete). [40], [12]

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 realizarea
semnalizărilor în vederea distribuirii și controlului etichetelor de îndrumare.

Tabelul 2.2 Etichete LDP [15]

Există 4 tipuri de mesaje folosite de LDP:

 mesaje de descoperire, folosite pentru a anunța prezența în rețea a unui element d e rețea
 mesajele sesiunii folosite 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 inform aț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 o biectului, un câmp length care specifică lungimea
obiectului și un câmp Value care definește valoarea obiectului. [7], [15]

48

Descoperirea vecinilor

LDP permite descoperirea vecinilor. Un LSR trimite periodic un mesaj HELLO multicast
pe un port UDP dedicat (LDP Disco very 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 prim i informația despre celelalalte 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 2.10. Descoperirea vecinilor [15]

Un mecanis m adițional de descoperire , permite 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 mesajului 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_Alive pentru menținerea conexiunii.
Eliberarea conexiunii stabilită prin LSP se va realiza în urma recepției unuia dintre
mesajele Disconnect sau ShutDown.

49

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

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 distri buție etichete:
o LABEL MAPPING
o LABEL WITHDRAWAL
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 L abel
Request , care conține parametrii 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.

50
Mesajul LDP Notification este transmis de partea 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 Notifi cation.
Eliberarea conexiunii se face 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. [15], [32]

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 rutar e folosită de MPLS pentru rutarea pachetelor 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 es te un mecanism
folosit pentru a satisface 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, ru tele explicite pentru fiecare trunchi 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 respect iv, subiect al
constrângerilo r impuse 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 r utare clasică care folosesc principiul „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ă înca psuleze 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 ing inerie de trafic pot folosi la momentul respectiv rute
explicite pentru a realiza optimizarea utilizării rețelei.

51
Implementarea rutării bazate pe constrângeri se realizează prin folosire de mecanisme
privind:
 Schimbul de informații legate de topologie (inf ormaț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 2.12. Modelul rutării bazate pe constrângeri [15]

Rutarea bazată pe constrângeri ajută la opt imizare a performanțelor operaționale , prin
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 m esajelor de eliberare
– Folosirea mecan ismelor 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”,

52
care se baze ază pe stabilirea și menținerea sesiunilor 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 period ică.
 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 permite 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 ser viciile 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 mesaju l 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 su nt:
 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 D ata 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 fo st cerută o mapare upstream.

53
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 c onține următoarele elemente TLV : FEC, 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, care 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 Requ est Messages [8], [15], [26]

54

55
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 de 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 întrea ga
rețea cât mai rapid posibil. Acesta este motivul pentru care rutarea IP este bazata pe principiul
celui mai mic cost de dirijare. Fiecare protocol IP de dirijare are un cost asociat cu legăturile în
rețele. Acumularea de costuri ale fiecarui link pentru o cale, este folosita pentru a calcula cel mai
mic cost al caii. Acest cost reprezintă o metrică ce este atribuită unui link (de exemplu, Open
Short Path First [OSPF] și Intermediate System to Intermediate System [IS -IS]), o metrică
compusă (de exemplu, I nterior Gateway Routing Protocol [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 un 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 3.1. Dirijarea în reț ele IP [10]

De exemplu, in Figura 3.1, 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 calea R1 -R3-R4-R5 nu va avea
nici un trafic.

56
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 s arcina
perfect, deoarece, în rețelele 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 c alea R1 -R3-R4-R5 egala. Rezultatul 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 din nou aceeași problemă , 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 aces t caz fiind inutil
calculul facut mai devreme si va trebui sa refacem costurile.
MPLS TE este o soluție pentru ca:
 ajuta la răspândirea eficienta a traficului în întreaga rețea, evitând neutilizarea și
suprautilizarea link -urilor
 ține seama de configuratii le (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 cap. Faptul că schimbarea de etichete este utilizata și nu comutarea dupa IP, calea poate fi
definita in functie de adresa sursă IP în loc de destinație. Asta se datorează faptului că MPLS
transmite in planul de date pot rivind eticheta de sosire din tabela LFIB și o schimbă 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ă folose asca pentru care LSP.
Figura de mai jos arată un exemplu de dirijare pe baza de sursa, capacitate a MPLS TE.

Figura 3.2. Dirijarea cu ingineria traficului [10]

57
In figura 3.2, R6 dorește sa trimită traficul pe calea R6 -R1-R2-R5, iar R7 vrea sa
transmita tr aficul de -a lungul caii R7 -R1-R3-R4-R5, acest 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 diferită a
etichetei 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 sim pla 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 dirija re 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 tabelă cu stările link-urilor, care
este apoi inundată la toate celelalte rutere în a ceeași zonă. Aceasta înseamnă că, toate routere din
domeniu au o topologie cu toate informațiile din zona respectivă. LSR -ul de la cap își 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ă posibilit atea de a crea tunele MPLS
TE între orice pereche 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ârzi ere, bruiaj și așa mai departe) de care este nevoie. Acest lucru este
esențial pentru miezul retelei (CORE – backbone) al providerilor de servicii. [7], [16], [22]

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, MPLS 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, utilizâ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 calcula te la capul tunelului pe baza resurselor necesare și
resurselor disponibile. IGP -ul automat rutează acest trafic în aceste tuneluri. De obicei, pachetele
ce trec o rețea cu MPLS TE în backbone circulă pe un singur tunel, care conectează punctul de
pătrunde re la cel de ieșire.

58
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 traficulu i 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 resurselo r – Resource
Reservation Protocol [RSVP]) pentru 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 Reserv ation), 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ți e ș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 trebuie 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 li nk-state le trimite. Acesta bază conține toate 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 Routing) 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
pentr u 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 propu se: 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țiile despre etichete să ajungă
la fiecare LSR.

59
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 c apitol, puteți vedea ce fel de
informații trebuie să fie transmise și cum OSPF au fost extinse pentru a transporta aceste
informații de TE. [5], [21], [22]

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 zonă ș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 ta bela de rutare), de aceea, informațiile cu privire 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 a semenea, 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 topol ogia 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 d e 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 max im de 32. Aceste resurse sunt inundate în întreagă
zonă, atunci când acestea se schimbă în valoare sau la intervale regulate. [8], [30], [33]

60
3.3. Extensii OSPF

RFC 2370 descrie o extensie a protocolului OSPF prin care cele trei noi anunțuri link -stat
(LSA -uri) sunt defini te ș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 apl icare 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 frontieră (gateway), și
de tip 11 sunt inundate în intreg domeniul OSPF, la fel ca și cele de tip 5.
Un bit nou, bitul O, a fost definit pentru a fi folosit în câmpul opțiuni al OSPF. Acest bit
poate indica da că este un router capabil de trimitere și primire 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 mul te Valori ale Tipului de Lungime ( Type
Length Value – TLV). Un TLV permite OSPF să transporte date într -un mod flexibil.
Acest TLV transportă date specifice MPLS TE. O adresă 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 4.1. 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 fiec are nivel de
prioritate de la 0 la 7)
Grupul Administrativ 4
Tabelul 3 .1. Resursele sub -TLVs
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

61
a cailor LSP cu TE. În protoc oalele 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 statusului 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 transporta 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. [30], [35]

3.4. Calcularea și s tabilirea căii

3.4.1. Funcționalitate SPF

În mod normal în pro cesul de calcul SPF, un router 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.
Într-un protocol de rut are link -state, fiecare router știe despre toate celelalte routere din rețea și
link-urile care conectează aceste routere. În OSPF această informație este codată în LSA(Link –
State Advertisments); în IS -IS această informație este LSP(Link -State Packets),pen tru a nu se
confundă cu Label -Switched Path le vom numi LSA.
Imediat după ce routerul cunoaște toate celelalte routere și link -uri, rulează algoritmul Dijkstra
Shortest Path First pentru a determina cea mai scurtă cale dintre routerul care calculează și t oate
celelalte reoutere din rețea.
Deoarece toate routerele rulează același calcul pe aceleași date, toate routerele au aceași imagine
despre rețea, și pachetele sunt consecvent rutate la fiecare hop.

62

Figura 3.3. O topologie simpl ă pentru a demonstra al goritmul SPF [10]

Acest exemplu (Figura 3.3.) ne arată ce se întâmplă când routerul A rulează SPF
și își generează tabela să de rutare.
După ce fiecare router a anunțat(flooded) cu informațiile sale rețeaua, toate routerele știu
despre toate celelalte ro utere și link -urile dintre ele.

Tabelul 3.2. Potrivirea claselor de planificare
În calculul SPF, fi ecare router menține două liste :
 lista a nodurilor care sunt cunoscute a fi pe calea cea mai scurta spre
destinație . Aceasta lista este numita lista PATH.
 lista cu următoarele hopuri(next hops) care ar putea sau nu ar putea să fie pe
calea cea mai scurtă spre destinație. Această lista se numește lista TENT sau
TENTative.
Fiecare lista este o tabela de tripleți {router,distanță,next -hop} din perspectiva route rului
care calculează.
Algoritmul care calculează calea cea mai scurtă pentru fiecare nod este simplă. Fiecare
router urmează următorul algoritm:
Pune “self” in lista PATH cu distanță 0 și următorul hop (next -hop) el(“self”=root node)

63

Tabelul 3.3. Lista PATH și TENTE pentru Routerul A

Ia nodul abia pus in lista PATH, și îl numește nod PATH. Se uită in lista vecinilor
nodului respectiv. Adauga fiecare vecin din aceasta lista in lista TENTE cu nodul urmator (next –
hop) nodul PATH, în afară de cazul în car e vecinul este deja în lista TENTE sau lista PATH cu
un cost mai mic. Dacă nodul abia adăugat în lista TENTE deja există în lista, dar cu un cost mai
mare, înlocuiește nodul cu costul mai mare cu nodul curent.
In exemplul nostru, {B,5,B} si {C,10,C} sunt adăugate in lista TENTE ca in Tabelul 3.4.

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

Găsește vecinul in lista TENTE ce are costul cel mai mic, adauga acel vecin in lista
PATH si repeta pasul 2). Dacă lista TENT este goală se opre sta.
{B,5,B} este mutat in lista PATH, deoarece aceasta este calea cea mai scurtă catre B.
Deoarece {C,10,C} este singurul vecin rămas, și costul de a ajunge la C este mai mare
decât costul de a ajunge la B, este imposibil să avem o altă cale către B cu un cost mai mic decât
cel de până acum. Tabelul 3.5 reflectă listele PATH și TENTE la acest pas.

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

Se repeta pasul 2.
Vecinii routerului B sunt examinați . Routerul B are un link catre C cu u n cost de 3 si un
link catre D cu un cost de 8. Costul total de la A la C via B este 8 și următorul nod (next -hop) a
lui B este adăugat în lista TENTE; costul de la A la D via B este 13 și este următorul hop (next –

64
hop) a lui B. Deoarece calea catre C cu u n cost de 8 prin B este mai mică decât calea către C cu
un cost de 10 prin C, calea către C cu un cost de 10 este înlăturată din lista TENT. Tabelul 3.6
reflectă listele PATH și TENTE la acest punct.

Tabelul 3.6. Listele PATH și TENTE pentru Routerul A d upă pasul 4

Găsește calea din lista TENTE cu costul cel mai mic, adaugă calea în lista PATH și se
repetă pasul 2. Dacă lista TENTE este goală se oprește.
Calea către C prin {C,8,B} este mutată din lista TENTE în lista PATH este arătat în
Tabelul 3.7.

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

Ia calea abia adăugată în lista PATH și se uită în lista vecinilor nodului. Pentru fiecare
vecin din lista, adaugă calea către acel vecin în lista TENTE, doar dacă vecinul respectiv deja
există în lista TENTE sau PATH cu un cost mai mic. Dacă nodul abia adăugat în lista TENTE
deja există în lista dar cu un cost mai mare, este înlocuită calea cu cost mai mare cu calea
curentă.
Sub această regulă, calea de la D către B (B ->C->D) cu un cost d e 12 înlocuiește calea
către D prin B ->D cu un cost de 13, cum se vede în Tabelul 11.

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

Găsește vecinul în lista TENTE cu costul cel mai mic, adaugă acest vecin în lista PATH
și repetă pas ul 2. Dacă lista TENTE este goală se oprește.
Calea către D este mutată în lista D, așa cum se vede în Tabelul 3.9.

65

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

Găsește vecinul în lista TENTE cu costul cel m ai mic, adaugă acest vecin în lista PATH
și repetă pasul 2. Dacă lista TENTE este goală se oprește.
Lista TENTE este goală deoarece D nu mai are vecini care să nu fie deja în lista
PATH,algoritmul se oprește. În acest moment lista PATH devine tabela de ru tare a routerelui A,
care arată că în Tabelul 3.10.

Tabelul 3.10. Tabel de rutare a Routerului A

Figura 3.4. Rețeaua vazută de Routerul A dupa rularea algoritmului SPF [10]

66
În această topologie se observă două lucruri :
 traficul care trece link -ul B->D este traficul provenit de la routerul A
 link-ul de la routerul A la routerul C nu este folosit deloc, din cauza costului prea
mare(10).

3.4.2. Funcționalitate CSPF

Procesul care generează calea pe care o ia un tunel TE nu este foarte mult diferit de SPF.
Sunt două diferențe majore între SPF, realizat de protocoalele de rutare și CSPF, realizat de
MPLS TE.
Procesul de determinare a caii nu este proiectat să găsească cea mai bună ruta către toate
routerele – numai către capătul tunelului. Acest lucru face algo ritmul SPF oarecum diferit .
De asemenea acum este mai mult de o metrica pentru fiecare nod față de singurul cost per
link între vecini:
 lărgimea de banda
 atributele link -ului
 distanța administrativă

Tripletului folosit de SPF i se mai adaugă lărgimea de b andă, atributele link -ului și
distanța administrativă.Un alt detaliu pentru CSPF este : nu se face împărțirea sarcinii (load
sharing) deoarece se caută o singură cale către nodul capăt.
Dupa cum am precizat, cu CSPF, vom folosi mai mult decât costul pe lin k pentru a
identifica căile care pot fi utilizate pentru drumuri LSP cu ingineria traficului. Decizia este
efectuată la routerul headend după eliminarea tuturor link -urile care nu respectă un anumit
criteriu, cum ar fi 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ătorul 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 ca re să corespundă criteriilor. În plus, utilizatorul poate configura
static un tunel TE sau LSP pe routerul headend specificâ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ă cum se va vorbi în capitolul următor. RSVP, astfel, este utilizat
împreună cu rezultatele calculate de către CSPF sau de lista de hopu ri configurate de către
utilizator pentru LSP. De notat că LSP -ul format este unidirecțional.
În caz de egalitate a constrangerilor, 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 aleg e 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 efectu at de către IGP în continuare, fie OSPF sau IS -IS.
Pasul 2. După ce calea LSP este calculată pe baza procesului CSPF, rezultatul din
procesul CSPF, care este un set de adrese IP mapate pentru fiecare adrese de la hop -uri
urmatoare, este trecut la RSVP.

67
Pasul 3 . RSVP acum efectuează cereri cu rezervări de resurse și confirmare pe LSP, cum
sunt definite de procesul CSPF, pentru a determina dacă LSP îndeplinește cerințele specifice
resurselor solicitate in definirea tunelului.
Pasul 4. După ce procesul de R SVP primește un mesaj de rezervare, acesta semnaleaza
că LSP -ul este acum stabilit.
Pasul 5 . La acest punct, un tunel TE este disponibil pentru a fi folosit de IGP. În mod
implicit, informatiile legate de tunel nu se adaugă în tabela de rutare; cu toate acestea, routerul
poate fi configurat astfel încât interfața tunel sa fie adăugată în tabelul de rutare.

Figura 3.5. O topologie simpl ă ce demonstreaz ă algoritmul CSPF [10]

În această topologi e, Figura 3.8, s -au luat numai patru proprietăți ale link -ului:
{link,cost,next hop,si lățimea de bandă disponibilă }. Routerul A vrea sa construiasta un tunel
TE catre routerul D cu o lățime de banda de 60 Mbps. Fiecare link își listează metrică și lățimea
de bandă disponibilă.
Dacă nu am lua in calcul lățimea de banda , calea cea mai buna de la A la D este A ->B-
>C->D cu un cost total de 12. Dar cum calea A ->B->C->D nu are 60 Mbps disponibili, CSPF
trebuie să calculeze calea cea mai scurtă care are disponibili 60 Mbp s.
Algoritmul CSPF urmează următorii pași :

1. Pu ne “self” in lista PATH cu o distanță de 0 si urmatorul hop(next -hop) el însuși .
Setează lățimea de bandă la N/A. Rezultatul este arătat in Tabelul 3.11.

Tabelul 3.11. Listele PATH ș i TENTE dup ă pasul 1
2. Pune vecinul routerului A in lista TENTE. Rezult atul este arătat in Tabelul 3.10.

68

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

3. Îl mută pe B din lista TENTE în lista PATH, și pune vecinii lui B în lista TENTE.
Rezulta tul este arătat în Tabelul 3.13.

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

{C,8,B,50} nu este adăugat in lista TENTE deoarece nu îndeplinește cerință de a avea
minimul de lățime de bandă .
4. Pune vecinii lui B în lista TENTE și îl ia p e C din lista TENTE și îl pune în lista
PATH. Rezultatul este arătat in Tabelul 3.14.

Tabelul 3.14. Listele PATH și TENTE pentru Routerul 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. Îl ia pe D din lista TENTE. În acest punct, cea mai bună posibilă cale către D este în
lista PATH și algoritmul se încheie.Rezultatul este arătat in Tabelul 3.15.

69

Tabelul 3.15. Listele PATH și TENTE pentru routerul A dup ă pasul 5
CSPF trebuie să țină urma tuturor nodurilor din cale, nu numai a urmatorului hop.
În cazul în care nodul care trebuie pus in lista TENTE există deja și are același cost este
nevoie să se facă o diferențiere între aceste cai.

Criterii de diferențiere a cailor in ordine(tiebreakers):
1 Se ia calea cu cea mai mare largime de bandă minim disponibilă .
2 Dacă mai există un obstacol, se ia calea cu numărul cel mai mic de hopuri( numărul de
routere din care este formata calea)
3 Dacă mai există un obstacol, se ia o cale aleator

Aceste criterii sunt aplicate când un nod este adăugat în lista TENTE. In orice moment,
un nod dat ar trebui sa fie adăugat numai o dată in lista TENTE. Aceasta este diferența față de un
IGP SPF, unde se poate sa ai mai mul te rute către un nod dat și se po ate face împărțirea sarcinii
(load share) între ele.

Figura 3.6. O rețea simpl ă în care sunt necesare criterii de diferen țiere pentru CSPF [10]

70
În această topologie sunt cinci cai posibile de la A la Z,de la P1 la P5.În Tabelul 3.16 sunt
listate atributele cailor .

Tabelul 3.16. 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 folosită deoarece costul căii este mai mare decât celelalte căi
-P2 nu este folosit deoarece lărgimea să de bandă minimă este 80 Mbps, valoare care este
mai mică decât minimul lărgimii de bandă pentru alte căi
-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 influențează CSPF:
– Lărgimea de bandă (bandwidth) : o cale nu este considerată acceptabilă de a fi folosită
pentru un tunel MPLS TE dacă nu are lărgimea de bandă cerută .
-Atributele link -ului(link attributes): daca bîțîi 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
– Distanță administrativă (administrative weight): este difuzată de IGP când sunt
anunțate(flooded) informații TE. Inițial, numai distanță administrativă este folosită pentru a
calcula calea tunelului .

3.5. Protocolul de rezervare al resurselor RSVP

După ce o cale este calculată cu CSPF, această cale trebuie să fie semnalată de -a lung ul
rețelei din două motive :
-Pentru a stabili un lant hop -by-hop de etichete care reprezintă calea
-Sa consume orice resursă (lărgime de bandă) consumabilă de -a lungul căii respective
Aceasta semnalare este îndeplinită folosind RSVP, impreuna cu extensiile RSVP pentru
MPLS TE. [5]

71
3.5.1. Bazele RSVP

RSVP este un mecanism de semnalizare folosit pentru a rezervă resursele peste tot în
rețea.Are tipul sau de protocol (46), deși este posibil să încapsulezi RSVP în UDP. MPLS TE nu
încapsulează niciodată RSVP în UDP .
RSV P nu este un protocol de rutare. Orice decizie de rutare este luată de IGP(inclusiv
extensiile TE) și CSPF. Funcția RSVP -ului este de a semnala și menține rezervarea resurselor
din rețea. În MPLS TE RSVP rezervă lățimea de bandă la nivelul planului de cont rol (control –
plane) .
RSVP are trei funcții de baza:
-setarea căii și menținerea ei
– ruperea căii (path teardown)
-semnalarea erorii
RSVP este un protocol soft -state. Asta înseamnă că are nevoie să împrospăteze periodic
rezervările din rețea prin resem nalizarea lor. Acest lucru este diferit față de un protocol hard –
state a cărui semnalări sunt cerute o dată după care se presupune că acea cerere este up până este
explicit pusă down . [5]
In Tabelul 3.17 sunt listate noua tipuri de mesaje diferite ce definesc RSVP.
Tipul mesajului Descrierea
Path Folosit să seteze și să mențină rezervările
Resv( scurtătură
pentru
Reservation) Trimis că răspuns la mesajele Path pentru a seta și a menține
rezervările
PathTear Analog cu mesajele Path, dar sunt folosite să înlăt ure rezervările din
rețea
ResvTear Analog cu mesajele Resv, dar sunt folosite să înlăture rezervările din
rețea
PathErr Trimis de primitorul mesajului Path care detectează o eroare în
mesaj
ResvErr Trimis de primitorul mesajului Resv care detectează o e roare în
mesaj
ResvConf Opțional trimite înapoi la expeditorul mesajului Resv, pentru a
confirmă că rezervarea dată s -a realizat
ResvTearConf Este un mesaj prioritar Cisco analogul mesajului ResvConf. Folosit
să confirme că o anumită rezervare a fost înl ăturată din rețea
Hello O extensie definită in RFC 3290 care permite link -urilor locale
keepalives între doi vecini RSVP direct conectați
Tabelul 3.17. Tipul mesajelor RSVP

72
3.5.2. Semnalizarea și operațiunile RSVP -TE

A. Semnalizarea

RSVP rezervă o lățime de ban dă 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 folosite la punerea în aplicare a RSVP pentru TE sunt
mesajul de cale RSVP (RSVP PATH) , mesajul de rezervare (RSVP RESERVATION), mesaje
de eroare și mesaje de încheiere.

RSVP PATH – este generat de headend și este transmis prin intermediul rețelei pe cale
de-a lungul unui viitor LSP cu TE. La fiecare hop, mesajul verifică disponibilitatea resurselor
solic itate ș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 headend și care se propagă în aval (pe
downstream).
Mesajele RSVP PATH sunt rutate prin intermediul rețelei cu E xplicit 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 cal e 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 t ransmite 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 dom eniul 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 . [23]

73

Figura 3.7. Mesajele RSVP Path și Reservation [23]

Mesajele de erore RSVP: PATHERR sau RESVERR – în caz de lipsa a resurselor
solicitate, routerul cu RSVP generează mesaje de eroare și le trimite la un router de la care
cererea a fost primită.

Figura 3.8. Mesajele de eroare RSVP [23]

Mesaje de incheiere (tear down) – RSVP creează două tipuri de mesaje de incheiere, și
anume, mesaj de incheiere de cale și mesaj de incheiere de rezervare. Odată ce mesajele de
incheiere au fost trimise, se perm ite 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 mesaj de
incheiere de rezervare la headend. [5], [23]

74

B. Operațiunile

Așa cum am menționat mai devreme, rezulta tul 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 TE sau LSP. Această listă de routere este calculată și este cunoscută doar de
routerul headend care est e 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 semnalizare RSVP pentru a solicita și a confirma
disponibilitatea resurselor pentru tunel. RSVP cu extens ii 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 LAB EL_REQUEST, EXPLICIT_ROUTE, RECORD_ROUTE
SESSION și SESSION_ATTRIBUTE sunt aplicate de routerul headend într -un mesaj de cale și
acest mesaj este trimis la 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 mesajului de cale RSVP . În cazul în care bitul L este setat, routerul nu
este direct conectat la următorul h op î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 hop, cum sunt definit în obiectul
EXPLICIT_ROUTE. În plus, acest router va adăuga interfața de ieșire s pre 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 tailend, el determină crearea
de un mesaj de rezervare. Conceptul cheie de remarcat este că etichetarea în cepe 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. Mesajul 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 traficului setată,
învățata prin RSVP -TE față de calea LSP normală. [23], [31]

Extensiile RSVP pentru a permite semnali zarea într -un mediu în care se pune in aplicare
MPLS TE sunt definite si prezentate in tabelul de mai jos:

75
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; genera t de routerul headend într-un mesaj de tip cale.
LABEL
(eticheata) RESERVATION Folosit pentru a aloca mapări de etichete la tunelul cu TE sau
LSP; generat 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 ca re
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 identifica te prin
adrese IP ale adreselor loopback corespunzătoare interfețelor
de pe headend și tailend .
Tabelul 3.18. Definirea extensiilor RSVP

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

A. Setarea căii

După ce începutul tunelului(tunnel headent) termină calculul CSPF pentru un tunel
particular, are nevoie să semnaleze această cerere în rețea. Capătul tunelului (headend) face acest
lucru prin trimiterea mesajelor Path următorului nod împreună cu calculul caii spre destinație.
Routerul care trimite mesajul Path se numește route r amonte și routerul care primește mesajul se
numește router aval. Routerul amonte se mai numește uneori hopul anterior(phop).
După ce routerul din aval primește mesajul Path , face următoarele lucruri: verifică
formatul mesajului pentru a se asigura că to tul este în ordine, după care verifică cantitatea de
lărgime de bandă cerută de mesajul Path primit. Acest proces se numește controlul admisiei.
Dacă controlul admisiei este reușit și mesajului Path i se permite să rezerve lărgimea de
bandă pe care o dore ște, routerul din aval crează un nou mesaj Path și îl trimite la următorul hop
din Explicit Route Object(ERO). Mesajele Path urmează acest lanț până când ajung la ultimul
nod din ERO – coadă tunelului MPLS TE.
Capătul tunelului realizează controlul admisie i pentru mesajul Path, că orice alt router din
aval. Când capătul tunelului realizează că este destinația mesajului Path, va răspunde cu un mesaj
Resv. Mesajul Resv nu conține numai confirmarea(acknowledgment) că rezervarea s -a realizat
pe tot drumul spre capătul tunelului, ci conține și eticheta care intră(incoming) pe care routerul
din amonte ar trebui să o folosească în trimiterea pachetelor pe TE LSP către capăt. Figura 3. 9
arată schimbul de mesaje RSVP: path și resv în timpul stabilirii LSP.

76

Figura 3.9. Mesajul RSVP: PATH ș i RESV in timpul setarii c ăii LSP [23]

Presupunând că R1 a realizat deja CSPF și deja știe ce lărgime de bandă vrea să rezerve
dea lungul căii R1->R2->R3->R5->R6->R7:
1. R1 trimite mesajul Path la R2. R2 primește mesajul Path, veri fică dacă mesajul are
sintaxa corectă, verifică cu TE Link Manager pentru a se asigura că lărgimea de bandă cerută de
R1 chiar este disponibilă. Dacă ceva este greșit R2 trimite un mesaj de eroare înapoi la R1.
Presupunând că totul este în ordine se trece la pasul 2.
2. R2 trimite un mesaj Path la R3. R3 face aceleași verificări pe care le -a făcut și R2 .
3. R3 trimite un mesaj Path la R5; aceleași verificări
4. R5 trimite un mesaj Path la R6; aceleași verificări
5. R6 trimite un mesaj Path la R7; aceleași v erificări
6. R7, fiind capătul tunelului, trimite un mesaj Resv lui R6. Acest mesaj Resv indică
eticheta pe care R7 dorește să o vadă în pachetul pe acest tunel; deoarece R7 este capătul, trimite
și implicit -null
7. R6 trimite un mesaj Resv lui R5 și indic ă că vrea să vadă că eticheta de intrare 42,
pentru acest tunel. Acest lucru înseamnă că atunci când R6 primește eticheta 42, scoate această
eticheta(din cauza implicit -null) și trimite pachetul către R7 .
8. R5 trimite un mesaj Resv către R3, semnalând eti cheta 10921. Când R5 primește un
pachet cu eticheta 10921, schimbă această eticheta cu eticheta 42 și trimite pachetul la R6
9. R3 trimite un mesaj Resv lui R2, semnalând eticheta 21
10. R2 trimite un mesaj Resv lui R1, semnalând eticheta 18.
In acest mome nt tunelul catre R7 este up, si se cunosc care sunt etichetele de ieșire .

77
A. Menținerea căii

La fiecare 30 secunde, capătul tunelului (headend) trimite un mesaj Path per -tunel la
vecinii din aval. Dacă un router trimite un mesaj Path și nu prim ește la timp mesajul resv,
consideră că rezervarea nu mai este și trimite la routerul din amonte un mesaj ce indică lipsa
rezervarii. Mesajele Path și Resv sunt ambele independente și asincrone de la un vecin la altul .

B. Ruperea căii

Dacă un nod (în genera l capătul tunelului) decide că o rezervare nu mai este necesară în
rețea, trimit un mesaj PathTear pe aceași cale urmată de mesajele Path și se primesc mesajele
ResvTear pe aceași cale că mesajele Resv.
Mesajele PathTear sunt în general văzute când capătu l tunelului (headend) decide că nu
mai dorește o rezervare în rețea(ex:când un tunel este down). Mesajele ResvTear sunt trimise în
răspuns la mesajele PathTear pentru a semnala că capătul tunelului a îndepărtat rezervările din
rețea.
PathTear și ResvTear pot fi deasemenea trimise în răspuns la o eroare în rețea .

C. Semnalarea erorii

Ocazional pot există erori în semnalarea RSVP. Aceste erori sunt semnalate prin mesajele
PathErr sau ResvErr. O eroare detectată în mesajul Path i se răspunde cu mesajul PathErr , și o
eroare detectată în mesajul Resv i se răspunde cu mesajul ResvErr. Mesajele de eroare sunt
transmise către routerul din amonte , el fiind sursă erorii; Patherr este trimis către nodul din
amonte de nodul din aval și ResvErr este trimis către nodul d in 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. Numărul de obiecte din mesaj depinde de ceea ce vrea mesajul să îndeplinească .

78

Figura 3.10. Formatul antetului RSVP [23]

Campul Descrierea
Version Versiunea protocolului RSVP.
Flags Nu este definit deocamdată 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 Lungimea mesajului RSVP in bytes, inclusiv
header -ul comun.RSVP Lenght este
intotdeauna cel putin 8.
Tabelul 3.19. Câmpurile din header -ul RSVP.

79

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

Figura 3.11. Formatul obiectului R SVP [23]

În Tabelul 3.20 sunt descrise câmpurile din formatul obiectului de baza RSVP .

Camp Descriere
Object Lenght Lungimea obiectului RSVP, inclusiv obiectul
header.Trebuie să fie multiplu de 4.
Class -Num Clasa obiectului.
C-Type C-Type este un număr unic din clasă .
Object Contents Obiectul însuși .
Tabelul 3.20. Formatul obiectului RSVP

Sunt definite 23 de clase obiect(object classes) diferite. Nu toate sunt folosite in
semnalizarile RSVP pentru MPLS T E; acestea sunt listate in Tabelul 3.21.

80

Tabelul 3.21. Clasele obiectului RSVP [23]

Un mesaj RSVP conține unul sau mai multe obiecte. Nu toate mesajele conțin toate
obiectele. Obiectele pe care le conține un mesaj depind de caracterizarea mesajului .
În Tabelul 3.20 sunt listate clasele și C -Type folosite în implementarea Cisco a RSVP –
TE.

81

Tabelul 3.22. Obiectul RSVP C -Types [23]

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, lărgimea de bandă și calea pe care o ia un tunel) fără
rezervarea de două ori a lărgimii de bandă și efectiv fără pierderi de date .
RSVP are o facilitate numita Shared Explicit(SE) ce este un stil de a rezervă ce permite
un LSP existent să împartă lărgimea de bandă cu el în suși astel încât să nu se mai întâmple
rezervarea de două ori .
Rezervarea SE are două componente:
 cererea stilului de rezervare SE de la rețea
 capabilitatea de a identifica că o anumită rezervare este aceeași cu o rezervare deja
existența, astel încât lărg imea de bandă să fie împărțită .

82
Stilul rezervat SE este cerut de capătul tunelului (headend) folosind un flag din obiectul
SESSION_ATTRIBUTE.
Toate rezervările RSVP sunt unic identificate cu un grup de cinci(five -tuple) : {Sender
Address, LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}.
Dacă două mesaje Path au aceste grupuri la fel, atunci acestea sunt considerate
reprezentanții aceleiași rezervări.
Sender Address este RÎD -ul capătului tunelului. Endpoint Address este RÎD -ul cozii
tunelului. Ex tended Tunnel ID este ori numai 0 ori adresa IP a routerului. Tunnel ID este
numărul interfeței tunelului din capăt. LSP ID este o “instanța de numărare”; de câte ori un tunel
își schimbă cerințele de lărgime de bandă sau calea pe care o ia, LSP ID se incr ementează. [5]

Figura 3.12. Nevoia de Make -Before -Break [5]
Presupunând că în Figura 3.12 R1 : RÎD=1.1.1.1 și R5: RÎD=5.5.5.5, Tabelul 3.22
arată ce trimite R1 și ce face R4 cu informația primită .
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
rezervare Res2 Examineaza rezervarea si realizeaza ca aceasta
este identica cu rezervarea anterioara cu
exceptia ID -ul tunelului. Permite noii rezervari
sa refoloseasca largimea de banda rezervata si
aloca acestui tunel 80 -35=45Mbps mai multa
largime de banda pe link -ul R2 ->R5. Link -ul
R2->R5 este marcat cu 80Mbps rezervati si
20Mbps nerezervati.
Tabelul 3.23. Pasii în Make -Before -Break

83
În acest fel, atât Res1 cât și Res2 li se permite să coexiste până când Res1 este
înlăturat din rețea. După ce Res2 începe să împartă rezervarea cu Res1, Res1 în scurt timp nu
va mai fi activ și nu va mai încerca nici o dată să concurez e cu Res2 pentru lărgime de bandă .

B. Modul de lucru al mecanismului de actualizare

RSVP este un protocol soft -state: rezervările sunt actualizate periodic. Rezervările sunt
trimise folosind mesajele Path și Resv. Nu există diferența între mesajele Path ș i Resv folosite
pentru setarea LSP inițială și cele folosite pentru actualizarea caii; formatul pachetului este la fel.
Felul în care un router spune o nouă cale setată după actualizare este pentru a vedea dacă există
deja o rezervare cu un grup de cinci(f ive-tuple) care se potrivește cu mesajele Path și Resv în
cauza .
Mecanismul de actualizare cuprinde două puncte majore:
 timpii de actualizare (refresh) cu jitter
 mesajele Path si Resv sunt trimise independent între doua routere.
Timpii de actualizare cu ji tter.
Mesajele Path și Resv sunt trimise la fiecare 30 de secunde.De fapt aceste mesaje sunt
trimise la 30 de secunde cu o oscilație de 50 procente : o rezervare dată are mesajul Path (sau
Resv)trimis pentru actualizare la fiecare 15 -45 de secunde.
Ideea generală este că un vecin trimite intervalul sau de actualizare(R) la vecinii săi în
obiectul TIME_VALUE din mesajele sale Path și Resv. Fiecare router de asemenea știe câte
mesaje este dispus să le piardă înainte să declare rezervarea inactivă.(K).
Vecin ul calculează un holdtime L pentru mesaj cu formulă:
L>=(K+0.5)*1.5*R

În implementarea IOS curentă R=30 secunde, K=3: L este cel puțin 157.5 secunde.
Această înseamnă că un router poate aștepta până în 157.5 secunde fără nici o reactualizare
înainte de a rupe o legătură cu un vecin. Este suficient timp că un router să aibă trei intervale
consecutive cu toate pachetele pierdute în timpul de actualizare (45 secunde) înainte de a expiră
timpul(time out).
Acest lucru este perfect normal. Mesajele Path și Resv nu sunt trimise în manieră
ping/ACK ci sunt trimise independent una de cealaltă .

84

Figura 3.13. Mesajele Path ș i Resv sunt trimise independent [5]

Când, unde, și cui îi sunt trimise mesajele ?
Există nouă tipuri de mesaje RSVP(cum am menționat și mai de vreme). Tabelul 3.24
rezumă ce mesaje sunt timise, când și unde.
Tabelul are cinci coloane:
 Mesajul –tipul mesajului.
 Functia –pentru ce este folosit mesajul.
 Direcția –direcția în care este trimis mesajul. Aval înseamnă “către
sfârșitul(tail) tunelului, în direcția opusă de începutul(head) tunelului”.Amonte
înseamnă “către începutul tunelului, în direcția opusă de sfârșitul tunelului ”.
 Adresa destinație –Destinația adresei IP a pachetului .
 Alerta routerului ( Router Alert ) – unele mesaje RSVP cara optiunea R outer
Alert, altele nu. [5]

Strict vs Slab sub -obiect ERO

În obiectul EXPLICIT_ROUTE L bit poate fi setat pe un hop în ERO pentru a indică o
ruta slabă.
ERO este codată că o serie de sub -obiecte numite noduri abstracte(abstract nodes) . Un
nod abstract poa te fi o adresa IPv4, adresa IPv6 sau un sistem autonom. Fiecare sub -obiect poate
fi ori un hop precis, ori un hop slab. Când un router procesează un hop precis, adresa IPv4 din
sub-obiect trebuie să fie direct conectată de routerul care procesează, altfel va fi o eroare în ERO.

85
Dacă un router procesează un sub -obiect ERO cu un hop slab, routerul respectiv este
responsabil să genereze un set de hopuri precise pentru că mesajul Path să ajungă la destinație și
să înlocuiască acel hop slab cu noul set generat de hopuri precise.

Mesajul Functia Directia Adresa
Destinatie Router
Alert?
Path Semnalează o cerere de
resurse in rețea Aval Capat Da
Resv Răspunsul la un mesaj
Path reușit Amonte Urmatorul hop
(next -hop) nu
PathErr Trimis către capătul
tunelului dacă există o
eroare în mesajul Path Amonte Urmatorul hop
(next -hop) nu
ResvErr Trimis către sfârșitul
tunelului dacă există o
eroare în procesarea
mesajului Path Aval Urmatorul hop
(next -hop) nu
PathTear Trimis către sfârșitul
tunelului pentru a înlătura
o rezervare existența Aval Sfarsitul tunelului da
ResvTear Trimis către capătul
tunelului pentru a înlătura
o rezervare existența Amonte Urmatorul hop
(next -hop) nu
ResvConf Trimis că răspuns la Resv
sau ResvTear care a cerut
confirmarea mesajului Aval Sfarsitul tunelului da
ResvConfTear Trimis în răspuns la
ResvTear care include și
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 3.24 Tipul mesajelor RSVP

86
Implicit vs Explicit Null

Sfârșitul tunelului poate semnala două tipuri de etichete – implicit null și explicit null.
Explicit null este semnalat folosind valoarea 0 în câmpul Label(eticheta) din obiectul LABEL.
Implicit null este semna lat folosind valoarea 3 în câmpul Label(eticheta) din obiectul LABEL.
Inițial(default), nodul din sfârșitul(coadă) tunelului semnalizează explicit null în mesajele
Resv:

LABEL type 1 length 8 : 00000000

Dacă privim la penultimul hop, se observă că valo area explicit null este interpretată că
implicit null, atât de hopul de la sfârșitul tunelului, cât și de penultimul hop .

3.6. Administrarea TE în MPLS

A. Protecție ș i restaurare

Din perspectiva unui router sunt două tipuri de eșec : eșecul link -ului și eșecu l nodului.
Abilitatea MPLS TE este de a călăuzi traficul departe de IGP obținând ajutor pentru calea cea
mai scurtă și micsorand pierderea de pachete în asociere cu un eșec a unui link sau nod din rețea.
Această abilitate a MPLS TE este cunoscută că FRR(Fa st Reroute) sau mai simplu Protecție
MPLS TE .
Nevoia pentru FRR(Fast Reroute):
Sunt câteva lucruri pe care IGP nu le face prea bine când vine vorba de convergență(în
cazul unui eșec în rețea ):
 În rețelele mari, unui IGP îi poate lua câteva secunde să conv eargă; până când
întreagă rețea converge, există pierderi de pachete .
 Un eșec al link -ului poate conduce la o congestie în unele părți a rețelei în timp ce
în alte părți a rețelei nu este congestie .
 Configu rând un IGP să conveargă rapid poate duce la o sen sibilitate prea mare
pentru o pierdere mică de pachete, cauzând convergență IGP fără nici un motiv .
Presupunând că un IGP este un protocol link -state, SPF trebuie rulat atunci când un link
devine down și din nou când link -ul devine up. Această problema es te accentuată în MPLS TE:
dacă un link care face parte dintr -un LDP care devine down, LSP -ul devine down. După ce
capătul tunelului TE recalculează o nouă cale, SPF trebuie rulat din nou pentru rutarea prefixelor
peste tunel când este stabilită rutarea aut omată, această făcând timpul de convergență mai rău
decât în rețelele IP tradiționale.Astfel s -a dezvoltat mecanismul FRR pentru a dobândi cât mai
puține pierderi de pachete .

87
Ce este protecția ?
Protecția în contextul de FRR(fast restoration),este proced ura prin care, aplicată
resurselor selectate, asigura pierdere minimă a traficului în urmă unui eșec. Resursele protejate
pot fi atât resurse fizice(link -uri sau noduri) sau resurse logice(LSP -uri care traversează un link
sau un nod). Termenul protecție ar trebui asociat cu faptul că resursele back -up sunt pre -stabilite
și nu sunt semnalate în urmă unui eșec .[31]

Tipuri de protecție
Protectia poate fi împărțită în :
 protecția căii
 protecția locală :
o protecția linkului
o protecția nodului

Protecția căii

Protecția caii este esențială în stabilirea unui LSP adițional în paralel cu LSP -ul existent;
LSP-ul adițional este utilizat numai în cazul unui eșec. Acest LSP se mai numește backup,
secondary sau standby LSP.
LSP backup este construit pe lângă calea existe nța cât mai diferit posibil. Ambele LSP -uri
primary și backup sunt configurate pe capătul tunelului TE.
Această metodă, protecția caii, nu este scalabila: pentru orice LSP ce se dorește protejat
se construiește un alt LSP.

Figura 3.14. Protecț ia căii [35]

88
Protecția locală

Protecția locală este un termen folosit când tunelul backup(tunelul de protecție) este
construit să acopere numai un segment a LSP -ului primar. Protecția locală că și protecția caii,
cere că LSP backup să fie pre -semnalizat. În protec ția locală, LSP backup este rutat în jurul link –
ului căzut(în protecția link -ului) sau a nodului căzut(protecția nodului), iar LSP -ul primar care
trece prin link -ul(nodul) căzut este încapsulat în LSP backup.
Protecția locală are câteva avantaje în compar ație cu protecția caii:o recuperare asupra
eșecului mai rapidă,1:N scalabilitate, consumă mai puțin din starea rețelei .

Figura 3.15. Elementele protec ției locale [35]
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:12008c.
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 3.25. Terminologia folosită în protecț ia local ă

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

89
Protecția link-ului

Protecția link-ului poate fi divizată în patru secțiuni :
 configurația înaintea eșecului (prefailure)
o se configurează pe capătul tunelului TE pe interfață tunelului care se
dorește protejat
o pe PLR: activand FRR pe PLR implica doua lucruri:
 crearea unui t unel backup pe Nhop
 configurarea link -ului protejat să folosească tunelul backup după
eșec

Figura 3.16. Protecț ia Link -ului [35]

 detecția eșecului
o Mecanisme adăugate la detecția acestor eșecuri :
 mecanismul de detecție a eșecului specifice unui nivel fiz ic
particular(SO NET)
 pentru link -urile punct -la-punct, PPP sau HDLC keepalives
 extensiile RSVP hello


90

Figura 3.17. Detec ția eșecului folosind RSVP Hellos [35]

Detecția bazată pe RSVP hello este considerată suficientă pentru detecția eșecului
în protecț ia locală, și convergență este mai rapidă decât în IP sau MPLS TE fără FRR .

 restabilirea conectivității
o imediat ce este detectat un eșec, PLR este responsabil pentru comutarea
traficului pe tunelul backup. Procesarea internă realizată pe PLR implică
următ oarele :
o asigurarea că backup -ul LSP pre -semnalizat este stabilit. Această include
nouă eticheta prevăzută pentru noul vecin din aval .
o noua informație de adiacentă(încapsularea de nivel 2) este calculată pe
baza interfeței fizice de ieșire a tunelului back up.
o semnalizarea dupa eșec (post – failure)
o semnalizarea RSVP care se întâmplă după ce protecția FRR a avut loc se
poate împărți în următoarele :
 semnalizarea in amonte

91

Figura 3.18. PathErr far ă protec ție local ă [35]

Când capătul tunelului TE unui LSP pr imește eroarea:nici o ruta nu este disponibilă către
destinație, aduce interfață tunelului down și apoi încearcă să găsească o nouă cale pentru LSP.
Capătul tunelului TE ignoră faptul că protecția locală poate fi disponibilă în jurul link -ului căzut.
Că rezultat traficul de -a lungul LSP -ului este pierdut până când LSP -ul poate fi rerutat.
Acest lucru face LSP -ul de backup complet inutil. De aceea este nevoie de un mecanism pentru
12008a să -i comunice lui 7200a următoarele: link -ul din aval de -a lungul caii LSP este down,
rerutez traficul temporar. Calea folosită către destinație nu mai este cea optimă,
calculează(copute) o cale alternativă, dacă este una disponibilă. Lucru cunoscut că LSR 12008a
triggering reoptimization.
Pentru semnalizarea informației no ndestructive se folosește PathErr cu ERROR_SPEC
conținând codul de eroare 25, “Notification” și un subcod 3, “Tunnel locally repaired”.
Capătul tunelului TE care primește notificarea 25/3 încearcă să calculeze și să
semnalizeze o nouă cale pentru acel tun el. După ce primește mesajul de rezervare(RESV) pentru
această cale nouă, eticheta pentru calea veche este înlocuită cu eticheta pentru calea nouă. Numai
după aceea LSP -ul vechi devine down. Această realizează make -before -break și ajută la
minimizarea pier derii de pachete .

92

Figura 3.19. PathErr cu protec ție local ă [35]

Când un link protejat cade și este comutat pe tunelul de back -up, PLR -ul trimite de
asemenea mesaje Path pentru LSP -ul protejat pe tunelul de back -up.
Adițional sunt făcute niște schimbă ri în corpul mesajului Path. Tunelele LSP sunt
identificate de o combinație a obiectelor SESSION și SENDER_TEMPLATE în mesajele Path și
Resv. Obiectul SENDER_TEMPLATE este modificat de PLR pentru că expeditorul adresei IP
va conține acum adresa IP a PLR -ului și nu cea a capătului tunelului TE. În acest fel sfârșitul
tunelului va observă că mesajul Path vine de la un nou expeditor dar aparține aceluiași expeditor.
În acest punct, mesajele de actualizare(refresh) curg(flow) pe tunelul de back -up. Starea iniți ală ,
menținută de către sfârșitul tunelului pentru această sesiune, devine down în cele din urmă
datorită timeout -ului;dar mesajul Path modificat de către PLR este suficient de eficient pentru a
menține rezervarea lărgimii de bandă atât cât este necesar.
• notificarea IGP
În absența FRR, dacă capătul tunelului TE principal primește un link -down LSA pentru
un link care a făcut parte din LSP -ul principal, capătul tunelului TE rupe tunelul principal. După
această, capătul tunelului TE poate, dacă este confi gurat corect, să încerce să reruteze calea LSP.
Dacă tunelul principal este configurat pentru FRR, link -down LSA nu are nici un effect,
capătul tunelului TE rupe un LSP protejat numai pe baza mesajelor de eroare RSVP și le ignoră
mesajele IGP care raporte ază un link down de -a lungul caii LSP. Asta înseamnă că un link down
nu este în mod necesar un LSP căzut deoarece calea LSP poate fi protejată .

93
 semnalizarea in aval

Figura 3.20. PathTear în absen ța FRR [35]
Când link -ul dintre 12008a și 12008c devi ne down(când nici o protecție locală nu este
stabilită), 12008c trimite un mesaj PatnTear către 7200c.
Dacă calea LSP era protejată de FRR, acest tip de mesaj ar fi avut un efect advers. Ar fi
rezultat că LSP să devină down, chiar dacă LSP ar fi fost prot ejat local de PLR. Pentru a preveni
această, mesajul PathTear trebuie suprimat pentru LSP -ul primar care are flag -ul activat: “Loop
Protection Desired” . Cum routerul de la sfârșitul tunelului, 7200c nu știe dacă tunelul protejat a
eșuat, în afară de cazul în care se întâmplă unul din următoarele lucruri : primeste un update IGP
despre esecul link -ului
 primește un PathTear de la MD 12008c
 nu primește un mesaj de actualizare RSVP (Path) care ține sesiunea valabilă
pentru o anumită perioada de timp .
Dacă rout erul de la sfârșitul tunelului primește un update IGP despre eșecul unui link, nu
se ia nici o măsură din perspectiva MPLS TE.
Dacă semnalizarea RSVP este declarată expirată, calea LSP este declarată inactivă, și un
mesaj ResvTear este trimis către capătu l tunelului TE. Această înseamnă că , separat de
prevenirea PathTear să fie trimis de MP 12008c, trebuie cumva să se asigure că sfârșitul
tunelului continuă să primească mesaje de actualizare RSVP chiar dacă unul din link -urile care
alcătuia LSP -ul princip al este down. Acest lucru este realizat asigurându -ne că MP(12008c)
continuă să primească mesajele Path pentru LSP -ul primar pe tunelul backup.

94

95
4. Calitatea serviciilor în rețelele MPLS

4.1. Noțiuni generale

QoS și MPLS sunt pe un anumit nive l politic similare. Totuși pe un nivel tehnic, QoS și
MPLS sunt foarte diferite.
Prin QoS se înțelege caracteristicile de performanță a rețelei, și cuprinde două părți :
 găsirea unei cai prin rețea care poate oferi serviciul
 obligarea îndeplinirii serviciu lui
Din punct de vedere al suportului pentru calitatea serviciilor (QoS), țelul MPLS a fost să
ofere ceea ce oferă IP -ul, adică Servicii Diferențiate (Diffserv). Când au apărut primele drafturi
despre MPLS, au fost rezervați 3 biți pentru a transporta info rmații despre clasele de servicii. În
final IETF a botezat acești biți că fiind Experimentali, deși majoritatea constructorilor îi folosesc
că pe bîțîi Precedentă din IP. Bîțîi EXP sunt analogi (și cel mai adesea o copie) a biților
Precedentă din IP. Arhit ectură MPLS și -a dorit să se integreze bine cu protocolul IP și să fie cât
mai independența de protocolul de nivel 2. Astfel s -a ales să se ofere suport pentru Diffserv, în
detrimentul suportului QoS oferit de ATM. Această decizie a dus la o simplificare m ajoră a
implementării MPLS, obținând performanțe care sunt competitive deși sunt inferioare celor
oferite de ATM.
Calitatea serviciilor înseamnă diverse lucruri pentru diverse persoane. La nivelul rețea,
QoS e compus din două lucruri :
 să se găsească o cale prin rețea care să îndeplinească cerințele impuse
 să se respecte restricțiile impuse

Găsirea celei mai bune căi prin rețea poate fi o acțiune de genul alegerii caii cu cost
minim furnizate de IGP. Respectarea restricțiilor impuse se poate rezolva prin d imensionarea
rețelei cu atât de multă bandă încât să se elimine problema. Această abordare mai este numită și
“cantitatea serviciilor”, dar la baza este o soluție temporară pentru a asigura calitatea serviciilor.
Totuși, lucrurile pot fi rezolvate și altf el. O cale disponibilă prin rețea poate fi construită
printr -un LSP TE, similar cu un ATM PVC, fără a ține cont de metrică protocolului de rutare.
Respectarea restricțiilor impuse se poate face folosind mecanismele Diffserv, cum ar fi policing,
marcare, re partizare în cozi și aruncare. MPLS este doar o unealtă care poate fi folosită împreună
cu mecanismele Diffserv pentru a oferi calitatea serviciilor.
Quality of Service sau QoS reprezintă pe scurt prioritizarea traficului în funcție de
protocol. Orice reț ea mare (câteva sute sau mii de calculatoare) sau orice rețea care folosește o
singură ieșire spre Internet implementează sau ar trebui să implementeze QoS. Pentru o activitate
eficientă traficul trebuie prioritizat în funcție de protocolul respectiv. Astf el VoIP – VoiceOverIP,
SSH, protocoalele de remote management sau video au nevoie de delay minim. Fiecare
milisecunda în plus necesară unui pachet să ajungă de la sursă la destinație poate duce la

96
imposibilitatea de folosirea a tehnologiei respective. Exis tă protocoale și servicii care nu necesită
delay scăzut. Ex: email, download -urile, P2P, chiar și Web -ul.
Calitatea serviciului (QoS) le oferă furnizorilor de servicii posibilități uriașe de a furniza
niveluri diferite de servicii (de exemplu, Gold, Silve r sau Bronze), precum și avantajul unor
scheme de preț diferențiate și a unei asistente adaptate clientului. QoS da posibilitatea rețelei să
aloce resurse pentru aplicațiile esențiale anumitor obiective sau pentru cele puternic dependențe
de factorul timp. QoS asociat cu MPLS va rezolva trei cerințe esențiale pentru aplicațiile care
funcționează într -o rețea VPN – funcționare previzibilă, implementarea de politici și livrarea de
noi servicii. Avantajele inerente de cost și viteză în administrarea și instala rea de VPN MPLS
oferă o poziție de lider pe piață.
În rețelele MPLS, clasele de servicii distincte folosite, duc la clasificarea fluxurilor de
trafic la nivelul 3 (rețea). Acest lucru face că implementarea să fie mult mai simplă. Există două
metode de a i ndică clasa de servicii în tehnologia MPLS : [9], [16]
• Prima metodă este copierea biților de Prioritizare IP (IP Precedence) din antetul
pachetului IP, în câmpul EXP al antetului etichetei MPLS. Câmpul EXP are 3 biți, ceea ce
înseamnă că se pot defini până la 2³ = 8 clase de servicii diferite .
• A doua metodă este utilizarea de etichete diferite pentru clase de servicii diferite .

4.2. Implementarea QoS

4.2.1. Modelele utilizate

Pentru utilizarea eficientă a tuturor capabilităților oferite de implementare QoS este foarte
important să se realizeze un plan elaborat. La construirea acestui plan trebuie să se ia în
considerare două aspecte foarte importante :
• Ce tipuri de aplicații se folosesc în rețea .
• Care tehnici de QoS ar putea să îmbunătățească performanțele rețelei .
Dacă se analizează corect primul aspect, și se găsește soluția corectă relativ la cel de al
doilea, atunci resursele rețelei vor fi folosite cel mai eficient. Pentru implementarea QoS s -au
elaborat două modele: Modelul Serviciilor Integrate (Integrated Servic es Model) și Modelul
Serviciilor Diferențiate (Differentiated Services Model).
IntServ își propunea să facă rezervări capăt la capăt pe fiecare flux, motiv pentru care nu
este scalabil în Internet. Totuși, poate fi folosit cu succes în rețele mici și medi i, în cazul în care
este suportat de echipamentele de rețea. Semnalizările IntServ folosesc protocolul RSVP pentru a
comunica tuturor nodurilor din cale cerințele de trafic dorite de host -uri. Nodurile din rețea creau
stări și alocau resursele hosturilor c are solicitau anumite garanții. În cazul în care negocierea au
succes, garanțiile oferite de IntServ sunt deterministe.
Din celălalt punct de vedere, DiffServ a fost văzut că o tehnologie scalabila, care nu
împovărează nodurile din centrul rețelei, obligâ ndu-le să facă multe prelucrări.
El folosește clasificarea pachetelor pe marginea domeniului și un sistem de cozi cu
priorități în centrul rețelei.

97
A. Modelul Serviciilor Integrate

Modelul Serviciilor Integrate constă în faptul că serviciile QoS sunt cerut e în mod
explicit de către aplicația care le dorește, prin transmiterea prin rețea a unei semnalizări adecvate.
Semnalizarea cererilor de servicii QoS se realizează prin intermediul protocolului RSVP de
rezervare a resurselor (Resource Reservation Protocol ). Acest model are dezavantajul că da
naștere unui volum semnificativ de trafic de control, care duce la utilizarea ineficientă a benzii.
Se folosește o semnalizare capăt la capăt între entitatiile comunicante prin care se cere
rezervarea resurselor neces are în nodurile din rețea. Pentru a face acest lucru s -a folosit
tradițional protocolul RSVP pentru a transporta semnalizările și pentru a instala stările de
rezervare în noduri. Principalele dezavantaje ale RSVP sunt necesitatea acestuia de a rula capăt
la capăt (astfel trecând prin rețele care pot să nu suporte rezervarea de resurse) și nevoia de a
folosi semnalizări per flux între două entități. Al doilea dezavantaj a avut un rol important în
determinarea scalabilitatii soluției, deoarece într -o rețea ma re pot există zeci sau sute de mii de
stări într -un nod, iar traficul periodic de menținere a rezervarii poate ocupă o parte importantă
din capacitatea linkului.
MPLS poate folosi RSVP pentru distribuția de etichete, folosind anumite extensii ale
acestuia . Diferența față de primul caz constă în rularea RSVP doar în rețeaua core, având
nodurile de granița că și capete. Acest lucru reduce mult numărul de entități comunicante,
crescând scalabilitatea soluției. Al doilea avantaj constă în faptul că rezervarea se face acum pe
clase de echivalentă, și nu pe fluxuri individuale, reducând mai mult numărul de semnalizări și
stări ce trebuiesc folosite. În funcție de cât de fine sunt clasele de echivalentă se poate extinde
scalabilitatea protocolului.
În cazul RSVP -TE odată cu cererile de eticheta se transmit și parametrii de trafic doriți în
obiecte de tip TSpec și RSpec. Nodurile intermediare ajustează informațiile din TSpec în funcție
de cât pot rezervă în momentul respectiv. Nodul destinație alocă eticheta, dar f ace și cererea de
rezervare a resurselor. Calea este menținută atâta timp cât se primesc periodic mesaje de tipul
PATH.
Dacă se dorește creșterea sau scăderea resurselor folosite în mod curent pentru cale, se
pot trimite noii parametrii în mesajele PATH. Astfel, calea ar primi o nouă rezervare în timp ce
este folosită. Totuși, dacă din diverse motive, rezervarea nu se poate face, calea va fi ștearsă și
traficul de date va fi întrerupt.Pentru a remedia această problema posibilă, mai există un mod în
care se pot cere resurse suplimentare. Calea inițială este menținută, dar în același timp este
realizată altă cale cu anumiți parametrii de trafic doriți. În momentul în care calea secundară este
gata, traficul este dirijat prin ea și calea originală este ștearsă . În acest caz, dacă calea secundară
nu poate fi construită, calea principala rămâne în folosință și nu apar întreruperi în trafic.
RSVP -TE nu este singurul protocol capabil să facă alocări de bandă. CR -LDP permite
crearea de cai cu comutatie a etichetelo r care să aibă o anumită bandă garantată. De asemenea,
parametrii acestor cai pot fi modificați pe timpul funcționarii caii, fără a fi nevoie să se șteargă
calea principala. CR -LDP beneficiază de avantajul de a fi un protocol de tip Hard State, astfel
neav ând nevoie de semnalizări permanente pentru a menține o cale, așa cum are nevoie RSVP –
TE. Din acest motiv CR -LDP este preferat în rețele MPLS foarte mari, unde RSVP -TE poate să
nu fie foarte scalabil . [5], [26], [27]

98

B. Modelul Serviciilor Diferenț iate

Diffserv are două c omponente majore:
 Condiționarea traficului – Include elemente precum policing, colorare și shaping.
Această prelucrare e făcută doar la marginea domeniului
 Comportamentul în fiecare nod (Per -hop behaviour) – constă din mecanismele de
repartizare în cozi, planificare și aruncare. Așa cum îi spune și numele, acțiunile
sunt făcute de fiecare nod din rețea .
Funcțiile suplimentare necesare pentru a implementa Diffserv includ clasificarea
pachetelor și condiționarea traficului, cum ar fi măsurarea, marcarea, for marea și aplicarea
politicilor asupra traficului.
Serviciul Diffserv este oferit doar în interiorul unui domeniu Diffserv, care constă dintr –
un set continuu de noduri caracterizate de anumite tipuri de comportament (PHB) și pot aplică
anumite reguli asupr a traficului. Astfel, nodul de intrare din domeniul Diffserv verifică dacă
traficul de intrare respectă specificațiile tehnice menționate în contract (SLĂ), altfel va marca
traficul că fiind neconform.
Tot nodul de intrare va asocia traficul într -un Agreg at de Comportament (BA -Behaviour
Aggregate) pe baza unuia sau mai multor câmpuri din antetul de nivel 3. După această acțiune
fiecare pachet este marcat cu un anumit cod DSCP. Nodurile de intrare vor face formatarea și
condiționarea traficului pe baza clas ificatorului.
Nodurile din interiorul domeniului nu mai trebuie să facă reclasificări, ci doar să aplice
un set de reguli traficului de intrare (Per Hop Behaviour). Acest PHB specifică câte resurse vor fi
alocate pentru un BA. Traficul de tip Best -Effort este și el clasificat, și de regulă are o bandă
minimă specificată . [24] [25]

Clasificarea pachetelor

Primul lucru necesar pentru a aplică arhitectură DiffServ este abilitatea de a clasifică
pachetele. Clasificarea este acțiunea de a examina un pachet pe ntru a hotărî ce fel de reguli
trebuie să urmeze, și ulterior, ce marcaj DSCP sau EXP trebuie să primească. În mod uzual
clasificarea se poate face după codul DSCP existent (în acest caz se folosește clasificatorul
Behaviour Aggregate) sau după mai multe c âmpuri, folosindu -se un clasificator multicamp .

Clasificarea pachetelor IP

Pachetele IP pot fi clasificate ușor. Se pot face comparații după orice câmp IP, dar în general se
folosește adresa IP destinație, adresa IP sursă sau valoarea DSCP. În plus se ma i poate face și
analiză de nivel 4, după tipul de protocol sau după portul folosit, pentru a se face o separare mai

99
fină. Totuși o clasificare complexă implică un timp mai mare petrecut în nodul de intrare și
astfel, o reducere a performanțelor de calitate . [24] [25]

Clasificarea pachetelor MPLS

Pachetele MPLS care intră într -un domeniu cu suport pentru Diffserv pot fi clasificate în
principiu doar după valoarea biților EXP din eticheta din vârful stivei. Nodurile de intrare nu vor
analiză celelalte etich ete și nici informațiile de nivel 3 deoarece ar fi nevoie să se elimine antetul
de nivel 2 în prealabil. Acest lucru nu este dorit la granița care leagă domenii MPLS .

Policing

Funcția de policing implică măsurarea traficului utilizatorului și comparar ea măsurătorii
cu un contract de servicii încheiat cu furnizorul. Ideea principala în Diffserv este că nu se
permite traficul excedentar să între în rețea dacă se depășește capacitatea cozilor instalate. Acest
lucru este făcut prin policing, deși poate fi făcut și prin mecanismul de shaping (formare).
Funcția de policing este făcută la granița rețelei. Astfel, majoritatea pachetelor care vor
intră în rețea sunt de tip IP. Totuși, sunt câteva cazuri în care traficul de intrare poate fi MPLS.
Un exemplu în a cest caz este arhitectură Carrier Supporting Carrier, prin care rețeaua
furnizorului oferă servicii de transport pentru alt furnizor, care îi este client. Cei doi furnizori se
pot pune de acord să folosească trafic MPLS pentru comunicarea între ei.

Marca rea

Regulile de marcare sunt adesea strâns legate de regulile de policing. Astfel, traficul care
iese din policer poate fi marcat că fiind conform sau neconform. Ulterior aceste două tipuri de
trafic vor fi servite diferențiat.
Totuși, nu e nevoie de un policer pentru a face marcarea. De exemplu se poate face un
mapping între valoarea DSCP a pachetului IP și valoarea EXP pe care o va lua pachetul etichetat.
Altă varianta este să se marcheze traficul care intră pe o interfață, indiferent de rată acestuia.
Acest lucru e util atunci când furnizorul taxează în plus unii clienți pentru QoS extra. Când nu se
dorește un serviciu cu o anumită calitate, se pot seta bîțîi EXP la valoarea 0. Prin faptul că
marcarea se face în antetul de nivel 2,5 nodurile MPLS nu tre buie să analizeze câmpul
Precedentă din IP pentru a hotărî tipul de tratament ce trebuie aplicat pachetului. În plus, analiză
de nivel 3 nu este dorită și din următorul motiv: operatorul rețelei MPLS poate decide să aloce
pachetul într -o anumită clasa de s ervicii, fără a modifică clasa de servicii marcată inițial în
DSCP. Astfel, la ieșirea din domeniul MPLS, pachetul clientului poate beneficia din nou de
privilegiile cerute.

100
Marcarea pachetelor IP

Antetul IP a evoluat continuu de -a lungul timpului din p unct de vedere al marcării
calității serviciilor. Inițial există un câmp Type of Service (ToS) compus din 3 biți de precedentă
plus 4 biți ce marcau tipul de serviciu dorit. Bîțîi de precedentă erau folosiți pentru a alege un tip
de tratament ce îi va fi a plicat pachetului. Valorile între 0 și 5 erau destinate datelor
utilizatorului, iar valorile 6 și 7 marcau traficul de control din rețea.
Diffserv a redefinit câmpul ToS folosind 6 biți pentru marcarea tratamentului dorit pentru
pachet, (acest lucru formâ nd câmpul DSCP) iar doi biți folosiți ulterior pentru ECN. Deși
Diffserv pune la dispoziție 64 de clase de trafic, numai 15 au fost definite și în practică, un
furnizor poate implementa mai puține.

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 4.1. Clase de trafic folosite în Diffserv

Au fost definite 12 valori AF , în formatul Af xy , unde x e numărul clasei, iar y este
prioritatea de aruncare. Aceste patru clase (AF1x -AF4y) furnizează o metodă de a oferi o

101
pierdere de pachete mică într -o anumită bandă de trafic, dar face garanții minimale asupra
întârzierii.
EF a fost definit pentru a servi trafic care cere o întârziere minimă, un jitter minim și o
pierdere minimă de pachete. Nu este nevoie de mai multe clase de tip EF deoarece acestea ar
concura pentru aceleași resurse . [24] [28]

Marcarea pachetelor MPLS

Prob lema care poate apărea atunci când se dorește stabilirea unei corespondențe de la
DSCP la EXP este faptul că DSCP este stocat pe 6 biți, pe când EXP ocupă doar 3 biți. În
rețelele în care MPLS funcționează în modul cadru (spre deosebire de rețelele în care
funcționează în modul celulă – peste linkuri ATM) se folosesc cei 3 biți EXP pentru codificare.
Astfel, este nevoie că mai multe coduri DSCP să corespundă aceluiași marcaj EXP. În practică
acest lucru nu e o problema, deoarece puțini furnizori oferă mai m ult de 8 clase de
serviciu.Totuși, se pot oferi mai multe clase de serviciu, dacă este nevoie, în special pe linkurile
ATM folosind bîțîi EXP în combinație cu însăși eticheta folosită. Acest mod de lucru se numește
L-LSP (Label Only Inferred LSP) . [25]

Repartizarea în cozi

Repartizarea în cozi și selectarea planificatorului care să servească acele cozi pot fi
diferite în funcție de platforma. Aceleași tehnici de planificare care sunt aplicate asupra traficului
Diffserv IP pot fi aplicate și pentru trafic ul MPLS. Tipurile de cozi uzuale și planificatoarele
asociate au la baza coadă FIFO și planificatorul Weighted Fair Queueing. Coadă FIFO poate fi
îmbunătățită cu un algoritm de tip Random Early Detection .

Aruncarea pachetelor

Mecanismul de aruncare al p achetelor nu este important doar pentru a ține sub control
dimensiunea cozilor folosite, dar și pentru a reduce debitul surselor TCP. Astfel, când o sursă
TCP pierde pachete, ea va reduce rată de transmisie. De aceea se dorește că în caz de congestie
cozil e să arunce din pachete, în loc să le piardă pe cele care nu mai au loc să între. În acest scop
se poate folosi Weighted Random Early Detection.

102
4.2.2. Implementarea QoS prin MPLS

Tehnologia MPLS a fost dezvoltată astfel încât să fie compatibilă cu protocolul IP. De
fapt scopul primar al acesteia este de a transporta eficient și rapid pachete IP. Că urmare, la
implementarea unei soluții QoS prin MPLS, scopul principal este că această soluție să suporte
modelele existente IP QoS. Altfel spus, scopul final este implementare QoS cap la cap (end to
end).

Figura 4.1. Func ționarea MPLS QoS [4]
În Figura 4.1 este ilustrată exact funcționarea unei politici QoS între o rețea IP clasică, a
clientului, și o rețea MPLS, a furnizorului de servicii. Practic, în cazul rou terelor MPLS care
ruteaza pachete, nu e nici o problema de implementare. Pur și simplu se copiază bîțîi IP
Precedence în câmpul EXP al pachetului MPLS și se implementează apoi politică QoS în funcție
de acesta. La ieșire, eticheta este extrasă, iar pachetu l IP standard este același care a fost primit la
intrare, cu bîțîi IP Precedence nemodificati. Rezultatul este, implicit, QoS cap la cap pentru
clienți.
În afară de mecanismele de prioritizare a traficului, una din cerințele unei rețele care are
implement ată o politică de QoS este și securizarea informațiilor. Comutatia de etichete izolează
traficul pe rute virtuale (Label Switched Paths sau LSP) în funcție de eticheta fiecărui pachet.
Forță acestui mecanism constă în faptul că se restricționează accesul a supra configurării. Altfel
spus, numai furnizorul de servicii poate instala rutele virtuale și tot el determina cine le poate
accesa. Nu există nici o posibilitate pentru un utilizator care transmite mesaje pe conexiunea lui
normală, să reconfigureze ruta virtuală sau circuitul virtual pentru a se conecta la aceea a altui
utilizator. Tocmai această caracteristică a comutației de etichete permite furnizorilor de servicii

103
să ofere rețele private virtuale prin intermediul unei infrastructuri MPLS partajate. Această
facilitate nu este însă una standard care să se regăsească și într -o rețea IP nativă, ci este specifică
MPLS.
Acesta este nivelul de securitate de baza oferit de rețeaua MPLS care este comparabil cu
cel disponibil prin intermediul rețelelor de tip F rame Relay sau ATM. Cu toate acestea, anumite
situații pot să necesite criptarea datelor atunci când ele sunt transmise de la o locație distanță la
altă. De exemplu, dacă avem o transmisie prin satelit, criptarea este absolut necesară, deoarece
conexiunea este disponibilă oricui dispune de un receptor adecvat și se află în rază de acțiune a
respectivului satelit.
Implementarea funcțiilor QoS în cadrul infrastructurii unei rețele MPLS oferă o serie de
beneficii, atât pentru furnizorii de servicii Internet, cât și pentru clienți. În ceea ce îi privește pe
furnizorii de servicii, îmbunătățirile legate de calitatea serviciilor pentru MPLS le permit
acestora să clasifice pachetele în funcție de tipul lor, de interfață de intrare, sau de alți factori,
prin marcar ea fiecărui pachet fără a modifică structura pachetului clasic IP. De exemplu,
furnizorii de servicii pot să clasifice pachetele fără a ține cont de nivelul de prioritate pe care îl
are pachetul atunci când ajunge la primul router de transport. De asemenea , ei pot să țină cont de
această prioritizare inițială și să aplice una suplimentară. Beneficiile pe care le poate oferi
implementarea funcțiilor QoS clienților sunt evidente, ei putând să se bazeze pe anumite debite
minime, pe o criptare adecvată, etc., ș i asta într -o conexiune cap la cap .

DiffServ -Aware Traffic Engineering (DS -TE)

DS-TE este numai un mecanism control -plane, ce obține abilitatea de a rezervă rândul
pentru lărgimea de bandă. Această abilitate permite construirea TE -LSP care specifică reze rvarea
de subpool de lărgime de bandă și transporta numai trafic LLC și că efect construiește o a două
rețea peste cea deja existența: o rețea a interfetelor fizice și pool -urilor globale și o rețea a
subpool -urilor. Implementarea curentă DS -TE permite anu nțarea unui singur subpool . [11], [25]

4.3. Detectarea de erori MPLS

În continuare vom analiză procesul de detecție de erori și protocoale în rețelele MPLS,
inclusive detecția unui LSP invalid, precum și recupararea LSP .

Separarea între planul de control și de date

Separarea între planul de control și de date este direct atribuită formatului și
evoluției unui pachet OAM. Formatul unei etichete de tip stivă, ce reprezintă header -ul pentru
pachetele MPLS, este format dintr -o eticheta valoare (20 biți), bîțîi EXP (3 bi ți), bit -ul S (1 bit),
și TTL (8 biți) .

104
Pentru a face diferența între un pachet OAM și un pachet de tip date, se pot folosi diferite
metode. ITU -T Y.1711 folosește o eticheta de tip stivă cu două intrară. Prima eticheta are aceeași
valoare că eticheta de transport, asigurând că în majoritatea cazurilor pachetele OAM pot fi
rutate pe aceeași cale că pachetul user. A două eticheta are o valoare specială rezervată, 14,
pentru a fi dirferentiata de pachetul user. Totuși, introducerea celei de -a două etichete poate să nu
fie complet compatibilă cu algoritmul de echilibrare a sarcinilor deja existent, că atare poate să
nu funcționeze corect în rețelele ECMP deja existente. Mai mult, în rețelele unde se folosește
PHP, pot apărea mai multe limitări, acest lucru fi ind subliniat în tabelul 4.2. [16], [32]

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,
bransa 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/Frecve nta  Injectarea de pachete la
fiecare secunda
 Necesita administrarea
TTSI
 Calculari BIP 16
 Frecventa este impusa
de operator
 Foloseste informative
native
 Verificare ciclica a
redundantei IP
Acord privind nivelul serviciilor NU NU
Tabelul 4.2. Y.1711 vers us func ționalitatea ping/trace MPLS

105

O altă opțiune este de a separă pachetle OAM de pachetele dată prin folosirea de sarcina
MPLS un pachet specific de IP destinat unui port deja cunoscut, precum în MPLS ping.
În acest caz eticheta de transport este acce ași că în pachetul de date. Această metodă,
totuși, presupune că adresa destinație să fie o adresa non -rutabila, pentru a asigura că pachetul IP
va fi procesat de routerul processor al router -ului de “ieșiri” În acest caz se permită suportul PHP
și un ECMP limitat.
Alte met ode de a separa planul de control de date sunt moduri hibride, unde un pachet
OAM poate fi identificat că o eticfeta specifică sau prin folosirea unui câmp specific din pachet
ce face posibilă recunoașterea ușoară. VCCV (Verificarea Cone ctivității Circuitelor Virtuale) se
bazează pe această tehnică .

Detecția unei etichete LSP eșuate

Eșuarea unei etichete LSP necesită testarea de fluxuri de pachete, înafara de erori de
tip network, deoarece în multe instanțe fluxul de pachete poate fi î ntrerup fără a fi sesizată
rețeaua (link -ul/nodul). Acest lucru poate fi cauzat de probleme în tabela de routare, unei
legături de etichete eronate, ag lomerarea rețelei, sau alte cauz e.
Verificarea conectivității, precum și ping/traceroute unei funcții OA M sunt sugerate
pentru acest tip de detectări de erori. Implementarea acestor protocoale poate fi diferită,
depinzând de technologia pachetului.
Indiferent de tehnologia folosită, este important că pachetele O AM să folosească
aceeași cale ca pachetele de date obișnuite . [7]

Scenarii de defectare LSP

ITU-T Y.1711 a standardizat funcția de verificarea conevtivitatii (CV), în timp ce
detecția de redirecționare bidirecțională (BFD) este studiată de IETF .
Figura 4.2 arată diferite scenarii 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

106

Figura 4.2. Scenarii de defectare LSP

4.4. Protecț ia și recuperarea MPLS

Protecție și recuperarea pot fi de tip local sau global. Protecția globală I se aplică unui
LSP de tip end -to-end, în timp ce protecția locală I se aplică unui link sau nod eronat. Protecția
locală în general da un timp de convergen ță mai mic fiindcă mesajul eronat este procesat de
notdul local (link protection) sau an nod imediat adiacent (node protection). Timpul de
convergență este de circa 50 ms, fiind unul acceptabil. Protecția cailor necesită un timp de
convergență mai mare, de oarece mesajele de eroare trebuie să se propage către capătul rețelei,
ceea ce inițiază mecanismul de protective.
Cea mai simplă metodă este 1+1 și 1:1 arhitectură de protecție de comutare specificat de
ITU-T Y.1720.
În arhitectură 1+1, traficul este cop iat și trimis către LSP -ul actual și cel de protective,
simultan. Astfel, LSP -ul de protective poate fi folosit pentru a transmite alt traffic când nu este
folosit.
Bazat pe protocolul de semnalizare folosit, sunt posibile diferite opțiuni. De exemplu, o
rețea de tip LDP se poate baza pe o convergență IGP rapidă șip e o disponibilitate ridicată pentru
îmbunătățirile de tip LDP. O rețea de tip RSVP_TE permite folosirea de multiple cai explicite
când semnalizează un LSP. Mai mult, RSP_TE a fost îmbunătățit p entru a permite repararea
locală a unui tunel LSP prin realizarea unei “evitări” LSP ce oernute un singur tunel de backup
pentru a proteja LSP -urile primare (modelul de portectie n:m ).

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

Furnizori i de servicii de telecomunicații au asigurat de mult timp servicii punct -la-punct,
cu cadrul OAM deja dezvoltat.
Tipic, interfetele utilizator -rețea (UNI) sunt folosite pentru a caracteriza punctele de
atașament ale clientului/furnizorului. În cazul multi punct, N>2, este nevoie de UNI, fiecare UNI
având un profil de trafic recepționat (traficul injectat în serviciul furnizorului) și un profil de
trafic trimis (traficul de iese din rețeaua furnizorului). Pentru un UNI dat, traficul recepționat
poate fi trim is către toate celelalte UNI, către unele UNI, sau către oricare alt UNI, depinzând de
serviciul furnizat. Poate fi necesar că QOS să fie initializat, ceea ce implică definirea de pierdere
de pachete și de întârzieri garantate. Asemenea garanții poate sunt necesare să fie puse pe fiecare
UNI, întrucât vitezele interfetelor diferitelor link -uri pot fi implicate.
Odată definite SL A-urile, problema constă în reservarea de resurse pentru a asigura
performanță obiectivelor din SL A-uri, și realizarea de ingineri a traficului la serviciile multipunct.
În final, protecția necesară va fi adresată pentru serviciile multipunct, din moment ce metodă de
protecție pe fiecare ruta folosită pentru serviciile punct -la-punct poate să nu scaleze cu serviciile
multipunct, având N*(N -1) rute implicate într -un serviciu multipunct de N noduri, în special
dacă QOS este implicat .

108

109
5. Simularea practică folosind GNS3

Pentru această simulare am folosit 10 routere model C3600, utilizând ima ginea C3640 –
JK.BIN din figura 5.1 .
Topologia propusă este următoarea :

Figura 5.1. Topologia simulării

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

Figura 5.2. Zona OSPF

Din punct de vedere al implementării MPLS BGP ruterele P sunt reflectori de rute pentru
ruterele PE. În mod normal, un ruter iBGP menține sesiuni cu toate celelalte routere iBGP din
AȘ, formând o topologie logică 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 că ruterele iBGP să schimbe rute BGP între ele, este
necesară configurarea de ref lectori de rute.
Liniile albastre reprezintă interconectarea iBGP standard între P1 și P2 iar liniile negre
reprezintă interconectarea iBGP în cazul reflectorilor de rute .

111

Figura 5.3. Zona BGP

Rutarea dintre ruterele PE și CE este exemplificată pe scur t în următoarea diagramă :

Figura 5.4. Rutarea PE – CE

112
Configurare MPLS -TE
1. Am configurat o interfață de loopback pentru asocierea cu tunelul MPLS -TE interface
Loopback0 ip address 10.0.1.1 255.255.255.255
2. In a două etapă am pornit MPLS -TE la niv el global precum și la nivel de interfață. Dau
exemplu interfață serială 1/0 ce face legătură cu ruterul P1

mpls traffic -eng tunnels

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

3. După ce interfetele care participa în MPLS -TE au fost configurate, precum și activarea
la nivel global a MPLS -TE, pasul următor este configurarea interfeței tunelului. Configu rarea
principala în acest caz constă în asocierea adresei IP a interfeței tunelului cu interfață de
loopback configurată anterior, modul de operare în cadrul tunelului precum și adresa de
destinație pentru capătul tunelului care se va mapă pe adresa de loo pback a routerului ce
reprezintă adresa de destinație. Dacă pentru drumul ales LSP se folosește utilizând IGP sau
CSPF atunci opțiunea folosită va fi „dynamic”. De asemenea în configurația standard interfață
tunelului nu este anunțată în IGP pentru a fi fo losită în tabela de rutare, din această cauza am
configurat explicit că că interfață tunelului să fie folosită că next hop în tabela de rutare a IGP .
Ca exemplu evidențiez configurarea tunelului între ruterele PE1 si PE2.

interface Tunnel2
ip unnu mbered 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

4. Ultimul pas în configurarea MPLS -TE este definirea pentru IGP, în 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

113
network 10.1.2.2 0.0.0.0 area 0

Verificare configurație efectuată
5. Cu ajutorul comenzii show mpls traffic -eng tunnels brief vom afișa toate tunele MPLS –
TE create.

Figura 5.5. Afișarea tunelelor MPLS -TE
6. Dacă dorim să detaliem informațiile despre un anumit tunel cu ajutorul comenzii show
mpls traffic -eng tunnels tunnel -name putem obține aceste informații. De exemplu am inserat
comandă pentru tunelul PE1_t2 care face legătură între ruterele PE1 și PE2 trecând prin
reflectorul de rute P2 .

114

Figura 5.5. Afisarea detaliata a PE1_t2

7. De altfel dacă dorim să aflăm tunele MPLS -TE care au că destinație de exemplu ruterul
PE2 cu IP -ul 10.0.1.2 cu ajutorul comenzii show mpls traffic -eng tunnels destination 10.0.1.2
putem află aceste informații. În urma rulării se poate observă din imaginea alăturată că ruterul
PE2 este destinație pentru două tunele respectiv PE1_t2 și PE3_t2

115

Figura 5.6. Afișarea tunelelor cu destinația 10.0.1.2
8. Dacă dorim să interogăm atributele rutelor de tip MPLS -TE definite pe un ruter cu
ajutorul comenzii show mpls traffic -eng link -management interfaces putem realiza acest lucru. În
următoarea captura evidențiez atributele rutelor configurate pentru ingineria traficului pe ruterul
PE1

116

Figura 5.7. Afișarea atributelor rute lor configurate pentru ingineria traficului pe PE1

9. Pentru a arăta vecinii IGP precum și ID -ul rutei prin care pot fi ajunși folosim comandă
show mpls traffic -eng link -management igp -neighbors care va genera următorul rezultat în urmă
rulării pentru rut erul PE1

Figura 5.8. Afișarea vecinilor IGP

10. Afișez rezultatul comenzii show mpls traffic -eng tunnels summary care afișează
informații refe ritoare la activarea TE, RSVP ca urmare evidenț iază a activărea TE și informații
legate de semnalizarea LSP

117

Figura 5.9. Afișarea scurtă a stărilor TE si LSP
Pe lângă configurarea de tunele MPLS_TE am introdus și conceptul de MPLS -VPN în
cadrul aceluiași sistem autonom folosind că protocol Ipv4 MPBGP cu distribuție de etichete. Mai
jos voi descrie sumar pașii pe care i -am urmat în această configurare .

11. Am definit două VRF pe toate ruterele PE precum și RD (route distinguisher) pentru
acestea. RD este utilizat pentru a distinge rutele VPN provenind de la mai mulți clienți care se
conectează la ruterele de prov ider, în cazul nostru ruterele PE.Dau că exemplu configurarea
efectuată pe ruterul PE1 celelalte rutere PE având configurarea similară.Precizez că valoarea
64512 provine de la sistemul autonon definit pentru BGP pe ruterele de clienți 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 legătură cu ruterele de clienți 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 Connected 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

118
13. În următorul pas voi exemplifică configurarea c a reflector de rute pentru ruterul P1,
pentru ruterul P2 configurația este identică .
address -family vpnv4 unicast
neighbor MPLS route -reflector -client
neighbor MPLS send -community ext ended
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 activat e
no auto -summary

14. Configurarea conectivității MPBGP între ruterele PE și reflectorii de rute.Voi
exemplifică configurația pentru ruterul PE1 pe celelalte rutere PE configurația fiind similară .

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 c a protocol de rutare între ruterele PE și 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

119
!
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 ac tivate
maximum -paths 2
no auto -summary
no synchronization
exit-address -family

Opțiunea a s-override se referă la faptul că prevenirea buclelor de rutare în BGP se face
prin verificarea numărului sistemului autonom A S în cadrul traseului sistemului auto nom.Dacă
ruterul care primește vede propriul număr A S în atributul A S din cadrul pachetului BGP primit,
pachetul va fi dropat.Ruterul care primește presupu ne că pachetul a originat din A S propriu și că
a ajuns din același loc din care a plecat, din cauza a ceastă acționând în acest mod.Opțiunea
descrisă face în așa fel încât numărul sistemului autonom a ruterului de la care provine pachetul
va fi schimbat pe parcurs de către rutere.

16. Pe ruterele VRF am configurat BGP redistribuind rutele conectate în BGP .
Configurația exemplificată este pentru ruterul VRF1 -CE1

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 synchronization

Am oprit sincronizarea deoarece toate ruterele din configurație rulează BGP, iar
dezactivând această opțiune oferă posibilitatea de a duce mai puține rute în IGP și de a reduce
timpul de convergență al protocolului BGP

120

121
Concluzii

Pe parcursul realizării acestor simulări, am avut în vedere evidentiera
posibilităților de implementare a tehnologiilor din plaja MPLS și studierea
performanțelor acestora prin analiza unei simulări de rețele .
Datele rezultate din această analiză împreună cu un studiu amănunțit efectuat
asupra acestor tehnologii a adus după sine o serie de concluzii.
Multiprotocol Label Switching reprezintă o nouã arhitectură în care nodurile
terminale adaugă o eti cheta unui pachet IP ce identifica drumul spre destinație, iar
pachetele sunt direcționate pe baza etichetei, fără inspectarea header -ului inițial.
MPLS permite 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 .
Tehnică folosită de MPLS este comutarea de etichete. O eticheta de lungime
fixă este codată înt r-un antet MPLS și este folosită pentru îndrumarea pachetelor.
Când un 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 va atașa pachetul ui transmis de router, necesară următorului hop.

122

123
Bibliografie

[1] Octavian Catrina , Note de Curs : Arhitecturi și protocoale de comunicații
[2] Grenvi lle Armitage : MPLS: The Magic Behind the Myths
[3] Banica Ion, Note de Curs : Comunicații de Date
[4] Eugen Borcoci, Note de Curs: Rețele și servicii
[5] Braden, Ed., et. Al., Resource Reservation Protocol (RSVP)
[6] Cuchiara, J Sjostrand, H Luciani , J.V., Definit ions of Managed Objects for the Multiprotocol
Label Switching , Label Distribution Protocol
[7] Davie, Bruce et al , Mpls using LDP and ATM VC switching
[8] Willibald Doeringer, Giinter Karjoth, Mehdi Nassehi, Routing on longest
matching prefixes
[9] Hideaki Takagi, Queueing A Fondation of Performance Evaluation
[10] George Swallow , MPLS Advantage for trafiic Engineering
[11] ITU Telecomunication Standardization Sector, OAM and Survivability Functionalit y for
MPLS Networks
[12] Multiprotocol Label Switching Arhitecture, disponibil la: https://tools.ietf.org/html/rfc3031 ,
accesat la data 4.03.2017
[13] Multiprotocol Encapsulatio n over ATM Adaptation Layer 5, disponibil la:
https://www.hjp.at/doc/rfc/rfc2684.txt , accesat la data 4.03.2017
[14] A Core MPLS IP VPN Arhitecture , disponibil la: https://www.rfc –
editor.org/pdfrfc/rfc2917.txt.pdf , accesat la data 11.03.2017
[15] MPLS using LDP and ATM VC Switching , disponibil la: https://tools.ietf.org/html/rfc3035 ,
accesat la data 12.03.2017
[16] MPLS Loop Prevention Mechanism , disponibil la: https://tools.ietf.org/html/rfc3063 ,
accesat la data 20.03.2017
[17] Site-ul Academiei Cisco http://cisco.netaca d.net
[18] Site-ul companiei Cisco www.cisco.com
[19] Site-ul companiei Juniper www.juniper.net

124
[20] Site-ul www.wikipedia.org
[21] E. Rosen, A. Viswanathan, R. Callon – Multiprotoco l Label Switching Architecture , 2001,
disponibil la http://rfc.net/rfc3031.html , accesat la data 01.04.2017
[22] L. Andersson, P. Doolan, N. Feldman, A. Frede tte – LDP Specification , 2001, d isponibil la
http://rfc.net/rfc3036.html , accesat la data 01.04.2017
[23] J. Ash, M. Girish, E. Gray – Applicability Statement for CR -LDP , 2002, d isponibil la
http://www.rfc -archive.org/getrfc.php?rfc=3213 , accesat la data 02.04.2017
[24] Eugen Borcoci – Rețele de Telecomunicații , 2005
[25] Leonardo Balliache – Differentiate d Service on Linux HOWTO , 2003, d isponibil l a
http://opalsoft.net/qos/DS.html , accesat la data 04.04.2017
[26] Leonardo Balliache – MPLS related notes , 2006 , disponibil la
http://opalsoft.net/qos/MPLS.htm , accesat la data 05.04.2017
[27] F. Le Faucheu r, L. Wu, B. Davie, S. Davari – MPLS Support of Differentiated Services ,
2002 , disponibil la http://rfc.net/rfc3270.html , accesat la data 10.04.2017
[28] Wikimedia – MPLS Myths , disponibil la http://www.answers. com/topic/mpls -myths , accesat
la data 11.04.2017
[29] Hélio Maurício Barroso, MPLS TE
[30] IAN GILROY, MPLS TE + FRR Tutorial
[31] Luca Martini, Daniel Tappan, Steve Vogelsang – Encapsulation Methods for Transport of
Layer 2 Frames Over MPLS , disponibil la http://www.ieee802.org/1/files/public/docs2001/draft –
martini -l2circuit -encap -mpls -01.txt , accesat la data 17.04.2017
[32] Luca Martini, Daniel Tappan, Steve Vogelsang – Transport of Layer 2 Frames Over MPLS ,
2001, d isponibil la http://www.ieee802.org/1/files/public/docs2001/draft -martinil2circuit -trans –
mpls -01.txt , accesat la data 18.04.2017
[33] Jeff Apcar, Cisco Advanced Services, Introduction to Traffic Engineering
[34] C.Sem eria-BGP/MPLS VPN Fundamentals
[35] Umesh Lakshman, Lancy Lobo – MPLS Configuration on Cisco IOS Software
[36] Site-ul https://www.slideshare.net/eagermirza1/mpls -1, accesat la data 24.04.2017
[37] Site-ul https://en.wikipedia.org/wiki/Routing_In formation_Protocol , accesat la data
20.04.2017

125
[38] Site-ul https://en.wikipedia.org/wiki/Open_Shortest_Path_First , accesat la data 20.04.2017
[39] Site-ul https://en.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol ,
accesat la data 20.04.2017
[40] Site-ul https://en .wikipedia.org/wiki/Border_Gateway_Protocol , accesat la data 2 0.04.2017
[41] Luca Martini, Daniel Tappan, Steve Vogelsang – Encapsulation Methods for Transport of
Layer 2 Frames Over MPLS

126

127
Anexa 1. Codul Su rsă

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.2 52
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.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/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
encapsulatio n ppp
no peer neighbor -route
mpls traffic -eng tunnels
ip ospf network point -to-point

128
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 bgp 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 65 000 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 le vel 15
logging synchronous
!
end

129

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 network 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 S1/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
descr iption Connected to PE2 S1/1
ip address 10.1.2.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/1
ip address 10.1.2. 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

130
description Connected to PE4 S1/1
ip address 10.1.2.13 255.255.255.252
encapsulation ppp
no peer n eighbor -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

Configuratie ruter PE1:

hostname PE1

131
!
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 autorout e 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/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 tunnel s
ip ospf network point -to-point

132
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 192.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 Loopbac k0
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 u pdate -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

133
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 sy nchronous
!
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 Loo pback0
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

134
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 tunnel s
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 forwarding 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 forwar ding 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 -communi ty extended
no auto -summary

135
!
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.5 remote -as 645 12
neighbor 192.168.1.5 as -override
neighbor 192.168.1.5 activate
maximum -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
neighbo r 192.168.1.5 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 PE3:

hostnam e 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
!

136
interface Loopback0
ip address 10.0.1.3 255.255.255.255
!
interface Tunnel1
ip unn umbered 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 m pls traffic -eng
tunnel mpls traffic -eng path -option 2
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
dynami c
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 VR F1-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

137
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 activate
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
neighb or 192.168.1.9 activate
maximum -paths 2
no auto -summary
no synchronization
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
!

138
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 pat h-option 2
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 announc e
!
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
!

139
interface Serial1/1
description Connected t o P2 S1/3
ip address 10.1.2.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/2
description Connected to VRF1 -CE2 S1/1
ip vrf forwarding vrf1
ip addr ess 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 synchronizati on
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

140
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.25 5.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 connecte d

141
timers bgp 12 36
neighbor 192.168.1.2 remote -as 65000
neighbor 192.168.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

Configurati e 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

142
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 FastEther net0/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 remo te-as 65000
neighbor 192.168.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 VRF2 -CE2:

143

hostname VRF2 -CE2
!
no ip dom ain-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
encapsulation 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