Proiect cercetare științifică [309891]
UNIVERSITATEA “POLITEHNICA” [anonimizat]:
S.I. Adrian F. Păun
Valentin Pușcașu
MSR II
2019
Cuprins
Listă de acronime 5
Cap.1. Tehnologiile utilizate în rețelele actuale de mare capacitate 6
1.1. Evoluția rețelelor de capacitate mare 6
1.2. Tehnologiile utilizate în rețelele actuale 7
1.2.1 Tehnologia IP 7
1.2.1.1. Rutarea în rețelele IP clasice 8
1.2.1.2 [anonimizat] 10
1.2.1.2.a.Protocolul Routing Information Protocol (RIP) 10
1.2.1.2.b. Protocolul Open Shortest Path First (OSPF) 11
1.2.1.2.c. Protocolul Enhanced Interior Gateway Routing Protocol (EIGRP) 12
1.2.1.2.d. Protocolul Border Gateway Protocol (BGP) 13
1.2.1.3. Limitări ale tehnologiei IP 13
Cap.2. Tehnologia Multiprotocol Label Switching 14
2.1 Ce este MPLS ? 14
2 .1 Terminologie MPLS 15
2.2. Cum funcționează MPLS 17
2.2.1 Etichetele MPLS 21
2.2.1.1 Frame mode 21
2.2.1.2 Cell mode(modul celula) 24
2.3 Arhitectura MPLS 25
2.3.1 Planul de control 25
2.3.2 Planul de date 26
2.4 Elementele MPLS 27
2.4.1 Comutator de Etichete (Label Switch Ruter) – LSR 28
2.4.2 Cale cu comutație de etichete (Label Switched Path)- LSP 29
2.4.3 Protocoale de distribuție a etichetelor 30
2.4.3.1 LDP(Label Distribution Protocol) 30
2.4.3.2 CR-LDP(Constraint Route Label Distribution Protocol) 33
2.4.3.3 RSVP-TE(Resource Reservation Protocol) 33
2.4.3.4 BGP( Border Gateway Protocol ) 33
2.5 Avantaje și dezavantaje ale tehnologiei MPLS 33
Cap.3. Ingineria Traficului în rețele MPLS 35
3.1 Necesitatea Ingineriei de Trafic în MPLS 35
3.2 Modul de lucru al ingineriei traficului în MPLS 37
3.2.1 Cerințe pentru IGP 38
3.3 Extensii OSPF pentru Ingineria Traficului 39
3.3.1 Operarea și Dirijarea pe Bază de Constrangeri în MPLS TE (Constraint-[anonimizat]) 40
3.4 Calcularea și stabilirea căii 41
3.4.1 Cum funcționează SPF 41
3.4.2 Cum funcționează CSPF 44
3.5 Protocolul de rezervare a resurselor -Resource Reservation Protocol (RSVP) 49
3.5.1 Bazele RSVP(RSVP Basics) 49
3.5.2 [anonimizat] 50
3.5.3 Operațiunile RSVP în MPLS TE 51
3.5.4 Setarea căii și menținerea ei 53
3.5.4.1 Setarea căii 53
3.5.4.2 Menținerea căii 54
3.5.5 Pachetele RSVP 55
3.5.6 Operațiile RSVP 57
3.5.6.1 [anonimizat]-Break? 57
3.5.6.2 Cum lucrează mecanismul de actualizare (refresh)? 58
3.6 Administrarea TE in MPLS 61
3.6.1 Protecție și restaurare. 61
Cap.4. Calitatea serviciilor in rețele MPLS 68
4.1 Introducere 68
4.2 Modelele utilizate pentru implementarea QoS 69
4.2.1 Modelul Serviciilor Integrate 69
4.2.2 Modelul Serviciilor Diferentiate 70
4.3 Implementarea QoS prin MPLS 74
Bibliografie 76
[anonimizat] – [anonimizat] -[anonimizat]-LDP -Constraint-[anonimizat] – Expedited Forwarding
E-[anonimizat]-[anonimizat] – [anonimizat] -[anonimizat] – [anonimizat]-IS – [anonimizat]-[anonimizat] – Local Area Network
LSR – Label Sitched Ruter
L-LSP – Label-only-inferred-PSC LSP
LDP – Label Distribution Protocol
LSP – Label Switched Path
MAC – Media Access Control
MPLS – Multi-Protocol Label Switching
NHLFE -Next Hop Label Forwarding Entry
OSPF – Open Shortest Path First
OSI – Open System Interconection
QoS – Quality of Service
RFC – Request for comments
PPP – Point to Point Protocol
PE – Provider Edge
PHB -Per-Hop Behavior
PHP -Penultimate Hop Popping
RIP – Routing Information Protocol
QoS -Quality of Service
RSVP -Reservation Protocol
SDH – Synchronous Digital Hierarchy
TE -Traffic Engineering
TLV -Type-Length-Value
TTL – Time to Live
VCI – Virtual Channel Identifier
VPI – Virtual Path Identifier
VPN – Virtual Private Network
WFQ – Weighted fair queuing
Cap.1. Tehnologiile utilizate în rețelele actuale de mare capacitate
1.1. Evoluția rețelelor de capacitate mare
Actualele rețele de date trebuie să asigure, în afară de viteza de transmisie ridicată, o bandă largă, managementul resurselor, dar și scalabilitatea și integrarea diverselor tehnologii de acces (LAN, HDSL, ADSL, TDM etc.). Datorită acestor necesități au apărut noi cerințe de performanță și de funcționalitate pentru rețelele de date actuale.
Având în vedere faptul că resursele rețelelor de date sunt limitate, este necesar ca acestea să fie gestionate cu grijă pentru a obține performanțe și randamente maxime.
Arhitecturile actuale țin cont de necesitățile de integrare a diferitelor tehnologii de acces existente și de interoperabilitatea cu alte rețele de date. Arhitectura unei rețea de date de mare viteză este structurată pe mai multe niveluri.
Modelul rețelelor folosit în prezent este reprezentat în figura de mai jos :
Fig. 1.1. Arhitectura unei rețele complexe de comunicații
Arhitectura rețelei este împărțită pe patru nivele:
Nivelul Optic – se situează la nivelul fizic OSI.
Acest nivel este implementat de către diferite tehnologii de transmisie pe fibră optică, cum ar fi: SONET, SDH, WDM, DWDM etc.
Nivelul Core (Nucleu) – numit și backbone, este partea de rețea responsabilă în principal cu transmisia de date de mare viteză, fără a îndeplini alte funcții de rețea.
Nivelul Distribuție – reprezintă partea de rețea în care se face agregarea traficului.
Nivelul Acces – cuprinde echipamentele de rețea responsabile cu partea de acces a diferitelor tehnologii de acces (TDM, ATM, HDSL, ADSL, IP, etc.).
Împărțirea pe nivele ușurează gestionarea și proiectarea arhitecturilor rețelelor de date, precum și migrarea către noi tehnologii prin implementarea unor etape de integrare pe nivele funcționale.
Principalele caracteristici arhitecturale și de funcționalitate ale unei rețele moderne sunt:
Funcționalități împărțite pe nivele structurale ( ex. în punctul de acces se face autorizarea, stabilire QoS, în distribution se face agregare, în core se face transport etc.).
Structurare pe nivele arhitecturale.
Ingineria traficului (stabilirea căilor de rutare) care se face prin managementul centralizat.
Management centralizat.
Conexiune cu rețeaua PSTN (Public Switched Telephone Network).
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.
Integrarea a cât mai multe tehnologii de acces.
Migrarea către o rețea de date universale (Date, voce, video, video-on-demand etc.).
Scalabilitate, performanță, disponibilitate totală (99%).
1.2. Tehnologiile utilizate în rețelele actuale
În rețelele de date actuale sunt utilizate ca principale tehnologii de transport:
tehnologia IP;
tehnologia ATM;
tehnologia MPLS.
1.2.1 Tehnologia IP
Tehnologia IP este cea mai răspândită tehnologie utilizată la ora actuală în rețelele LAN. Tehnologia IP este o tehnologie de Layer 3 bazată pe protocolul IP (Internet Protocol) care face adresarea și controlul informației ce permite pachetelor de date să fie rutate.
Protocolul IP este un protocol bazat pe transmisia pachetelor între diferite calculatoare conectate într-o rețea. Protocolul suportă fragmentarea, adresare, reasamblarea și multiplexarea de protocol. Este protocolul pe baza căruia s-au construit ulterioarele protocoale IP, așa numita suită de protocoale TCP/IP (UDP, TCP, ICMP, ARP, RARP, etc.).
În următorul desen este reprezentată corespondența diferitelor protocoale și nivelul OSI:
Figura 1.2.1. Corespondența între nivelul OSI și protocoalele de rețea
1.2.1.1. Rutarea în rețelele IP clasice
Rutarea poate fi de tipul statică sau dinamică. Ea implică determinarea căii care urmează a fi folosită în transmiterea unui pachet de date, care se poate face după anumite valori metrice (costuri, întârzieri, utilizarea căii, etc.).Rutarea se face folosind o tabelă de rutare care specifică interfețele și adresele care trebuie folosite pentru a trimite pachetele.
Ruter-ele sunt echipamente ce lucrează la nivelul 3 din stiva OSI. Ele sunt utilizate pentru schimbul de informații dintr-un grup de rețele ce aparțin aceleiași autorități de control (AS – Autonomous Systems), cât și pentru schimbul de informație între AS-uri diferite.
Regula generală de trimitere a pachetelor de date este alegerea unei rute care se potrivește cât mai exact.
De exemplu:
Destinație Masca Ruter de ieșire
10. 1. 6. 0 255.255.255. 0 R3
10. 1. 0. 0 255.255. 0. 0 R6
Destinația 10.1.6.30 se potrivește în ambele cazuri, dar gateway-ul R3 are mască de rețea mai restrictivă, deci ruterul R3 va fi ales pentru transmiterea datelor.
Rutarea cu vectori-distanta
Rutarea se poate face pe bază de algoritmi cu vectori-distanță (algoritmi Bellman-Ford), care fac ca ruterele să distribuie periodic copii ale tabelelor de rutare vecinilor săi cei mai apropiați din rețea. Fiecare destinatar adaugă la tabela respectivă 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 între ruterele aflate în imediată vecinătate.
Acest proces pas-cu-pas face ca fiecare ruter să afle informații despre celelalte rutere din jurul său și să-și dezvolte o perspectivă cumulativă asupra "distanțelor" rețelei.
De exemplu, un protocol timpuriu de rutare este Routing Information Protocol (RIP). Acesta utilizează două unități de măsură pentru calcularea distanțelor ca să determine cea mai bună cale următoare pentru orice pachet de date. 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 ruter conectat în rețea. La finalul procesului, fiecare ruter află niște informații vagi despre distanțele până la resursele din rețea. Ruterul nu află nimic specific despre alte rutere sau despre topologia reală a rețelei în care se află.
În anumite circumstanțe, această abordare poate 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 ruterele să conveargă spre o nouă înțelegere schimbărilor avute loc în topologiei rețelei. În timpul acestui proces, rețeaua ar putea deveni vulnerabilă la rutări contradictorii și chiar la bucle infinite în rețea.
Anumite măsuri de siguranță ar putea micșora aceste riscuri, însă rămâne amenințată performanța rețelei – este expusă riscurilor în timpul procesului de convergență. Prin urmare, este posibil ca protocoalele mai vechi care converg lent să nu fie preferate pentru WAN-urile extinse, complexe.
Rutarea utilizând starea legăturilor
Algoritmii de rutare care folosesc starea legăturilor (link-state routing algorithm), cunoscuți ca și protocoale care preferă drumul minim (SPF), mențin în permanență 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 ruterelor din rețea, și a felului cum acestea sunt interconectate.
Cunoaștere este realizată prin schimbarea de pachete cu starea legăturilor (LSP) cu ruterele conectate direct. Fiecare ruter care a schimbat LSP-uri, construiește apoi o bază de date logică utilizând toate LSP-urile primite. Este utilizat apoi un algoritm "cu preferarea drumului liber", pentru a calcula cât de accesibile sunt destinațiile din rețea. Această informație este folosită pentru a actualiza tabela de rutare. Proces utilizat este capabil să descopere modificările topologiei rețelei, care ar putea fi cauzate de căderea unei componente, legături sau de mărirea rețelei. De fapt, schimbul de LSP-uri este declanșat de un eveniment din rețea.
Rutarea cu starea legăturilor are două zone parțiale de risc.
Mai întâi, în timpul procesului de descoperire, rutarea cu starea legăturilor poate acapara mediile de transmisie ale rețelei, reducând astfel în mod semnificativ capacitatea de a transporta date a rețelei. Această degradare a performanței este temporară, dar este foarte evidentă.
O a doua problemă potențială este că solicită intens memoria și procesorul. Din această cauză, ruterele configurate pentru rutare cu starea legăturilor sunt în general cu specificații tehnice mai ridicate și mai scumpe.
Rutarea hibridă
Reprezintă tot o formă de rutare dinamică. Această formă de rutare este asociată aproape exclusiv creației brevetate a unei singure companii, Cisco Systems Inc. Acest protocol, EIGRP, a fost proiectat combinând avantajele protocoalelor cu vectori-distanță și cu starea legăturilor, fără limitările de performanță și dezavantajele acestora.
Utilizează unități de măsură vectori-distanță, dar realizează măsurători mult mai precise decât protocoalele cu vectori-distanță. Ele converg mult mai rapid decât acestea din urmă, dar evită suprasarcinile și actualizările cu starea legăturilor deoarece nu sunt periodici, ci conduși de evenimente, conservând astfel lărgimea de bandă pentru nevoile aplicațiilor reale.
1.2.1.2 Protocoale de rutare – IP
Algoritmii de rutare sunt împărțiți în două grupe:
Interior Gateway Protocol (IGP) – folosit la rutarea în interiorul unui sistem autonom (organizații).
Din această categorie (IGP) fac parte următoarele protocoale de rutare:
RIP (Routing Information Protocol) – folosit în special în rețelele de dimensiuni mici;
OSPF (Open Shortest Path First) – protocolul folosit cel mai des î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) – utilizat la rutarea între diferite organizații sau Sisteme Autonome (AS).
În figura următoare este reprezentată poziționarea celor două tipuri de protocoale de rutare într-o rețea largă:
Fig. 1.2.1.2. IGP și BGP într-o rețea largă
1.2.1.2.a.Protocolul Routing Information Protocol (RIP)
RIP este un protocol de rutare bazat pe distanța vectorială dintre hopuri. Este folosit în toate ruterele existente pe piață. Pentru alcătuirea tabelei de rutare folosește trei tipuri de temporizări:
Actualizarea rutelor (automat la un interval de 30 de secunde);
Expirarea validității rutei;
Curățirea tabelei de rutare.
Cele două versiuni existente ale protocolului RIP sunt: RIPvl și RIPv2.
Problemele principale ale protocolului RIP sunt:
numărul maxim de hopuri este limitat la 15;
propagarea informației în rețelele mari este lentă;
traficul RIP crește rapid odată cu mărirea rețelei.
Protocolul RIP poate opera în 3 moduri diferite:
Activ – trimite și recepționează informații de rutare;
Silent – doar ascultă și primește informații de rutare (nu transmite nimic);
Deaf – doar trimite informații de rutare (nu primește).
1.2.1.2.b. Protocolul Open Shortest Path First (OSPF)
OSPF este un protocol bazat pe verificarea stării link-urilor dintre echipamente, ruterele trimit informații despre starea link-ului în locul informațiilor despre propriile tabele de rutare. Acest protocol împarte rețeaua în zone diferite pentru a putea lucra în rețele mari.
Fig. 1.2.1.2.b. Topologia protocolului OSPF
Ruter-ele interne trebuie să știe doar rutele către rețelele din aria lor și către aria de backbone (Aria 0). Ruterele schimbă între ele informații despre starea link-urilor. Fiecare ruter cunoaște topologia și costul pentru comunicația cu rețelele din aria lui.[18]
Ruterele amplasate la graniță schimbă informații despre starea link-urilor cu toate ruterele din aria cu care sunt conectate.
Ruterele de backbone schimbă informații cu alte rutere de backbone din aria „0" și calculează ultimul cost al rutei dintre ariile interconectate sau alt sistem autonom.
Protocolul OSPF folosește cinci tipuri de mesaje:
Hello – folosit pentru a descoperi vecinii și pentru a delega un ruter dedicat și pentru a verifica starea link-urilor;
Database Description – descrie baza de date a topologiei link-ului;
Link State Request – cerere de părți din topologia ruterelor adiacente;
Link State Update – trimite date despre starea link-urilor către ruterele vecine;
Link State ACK – confirmarea recepționării update-ului.
Folosind mesajele „Hello" un ruter principal și un ruter de backup principal sunt alese pentru fiecare arie a rețelei. Ruterele principale de arie calculează o matrice a ruterelor din întreaga arie (care nu este aceeași cu matricea de rutere vecine).
Fiecare ruter schimbă date despre starea link-urilor doar cu ruter-ele adiacente, ceea ce limitează traficul generat de OSPF în rețea.
În cele din urmă toate ruter-ele vor obține informații identice despre topologia rețelei. 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ă sau retransmisă.
În OSPF ruterele 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 rutere în momentul în care trimit pachete cu câmpul ToS setat la o anumită valoare.[18]
1.2.1.2.c. Protocolul Enhanced Interior Gateway Routing Protocol (EIGRP)
EIGRP a fost dezvoltat de către compania Cisco (eliberat în 1988) cu scopul de a îmbunătăți protocolul RIP pe vremea când IETF încă lucra la dezvoltarea protocolului.
EIGRP este un protocol brevetat. Acest protocol elimină unele dintre defectele protocolului RIP și are îmbunătățiri ca folosirea de metrici compuse, rutarea pe căi multiple și mânuirea rutelor implicite.
Evoluția EIGRP furnizează compatibilitate și operații precise cu ruterele EIGRP. Capacități cheie care disting EIGRP de alte protocoale de rutare includ convergența rapidă, suport pentru mască de subrețea variable-length, suport pentru update și suport pentru multiple network layer protocols.
EIGRP are toate avantajele flexibilității și ale configurării simple în timp ce îmbunătățește viteza și utilizarea resurselor disponibile. 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 de tipul multi-protocol.
Acest protocol de rutare este unul dintre cele mai diversificate și robuste protocoale de rutare. Combinația sa unică de caracteristici îmbină cele mai bune atribute ale protocoalelor de vector-distanță cu cele mai bune atribute ale protocoalelor cu starea legăturilor. Rezultatul fiind un protocol de rutare hibrid care sfidează împărțirea pe categorii a protocoalelor convenționale.
Poate fi folosit împreună cu IPv4, AppleTalk, și IPX. Mai important, 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-distantă, EIGRP nu mandatează o revizuire periodică a tabelelor de rutare între rutere vecine. În schimb, folosește un mecanism de descoperire/recuperare pentru a se asigura că vecinii sunt conștienți de accesibilitatea fiecăruia in parte.
1.2.1.2.d. Protocolul Border Gateway Protocol (BGP)
BGP–ul este momentan 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 existente în rețea și să folosească informația metrică pentru a lua decizii de rutare inteligente.
Traficul dintr-un AS trebuie să treacă printr-un gateway ruter, AS selectează care ruter va îndeplini această funcție.[18]
1.2.1.3. Limitări ale tehnologiei IP
Principalele limitări ale tehnologiei IP sunt următoarele:
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 de „Best Effort" în politica de trafic;
Mecanismul de rutare este un mecanism care se bazează pe conceptul „cea mai mare potrivire" și acest lucru duce la întârzieri în mecanismul de rutare și trimitere de pachete;
Lungimea pachetelor este variabilă ceea ce duce la echipamente hardware complexe cu mare putere de calcul. Acest lucru duce la limitări în puterea de procesare a backbone-urilor;
Header-ul pachetului IP este mare și complex, ceea ce duce la o proastă utilizare a
benzii de date disponibile în rețea.
Datorită mecanismului de adresare apar foarte multe adrese care sunt greu de gestionat de către rutere care posedă tabele de rutare mari și hardware complex.
Cap.2. Tehnologia Multiprotocol Label Switching
2.1 Ce este MPLS?
Multiprotocol Label Switching (MPLS) este o tehnologie bazată pe comutația de pachete bazată pe etichete ce își propune să simplifice rutarea IP în rețelele core. Arhitectura MPLS a fost gândită să poată oferi un serviciu de transport de date unificat pentru diferite tipuri de trafic, cum ar fi pachete IP, cadre SDH, celule ATM sau Ethernet. Din punct de vedere arhitectural MPLS se află între nivelul 2 OSI (Legătura de Date) și nivelul 3 (Rețea), fiind considerată de mulți specialiști din domeniu o tehnologie de nivel 2,5.
Ideea de bază a acestei tehnologii este să clasifice fluxurile de intrare într-o rețea MPLS în clase de echivalență care să fie tratate la fel de către nodurile din rețea. O clasă de echivalență intră în corespondență cu un set de etichete de lungime fixă ce vor fi comutate în nodurile rețelei, până la destinație. Nodurile de intrare sunt responsabile cu clasificarea fluxurilor, iar nodurile intermediare au de făcut mult mai puține prelucrări, deoarece este suficient să comute etichete.[Wiki-MPLS]
MPLS a fost dezvoltat inițial pentru a realiza o îndrumare mai rapidă a pachetelor decât în rutarea IP clasică, deși îmbunătățirile ce țin de partea hardware a ruterelor au rezolvat problema vitezei în cadrul rutării. Comutarea etichetei este realizata indiferent de protocolul de rutare Layer 3.
MPLS suportă multiple aplicații utile, cum ar fi cele enumerate mai jos:
-Unicast și Multicast in rutarea IP;
-VPN(Retea Privata Virtuala);
-TE(Ingineria Traficului);
-QoS(Calitatea Serviciului);
-ATM(Orice transport peste MPLS).
MPLS oferă posibilitatea firmelor și furnizorilor de servicii Internet (ISP – Internet Service Provider) să construiască rețele inteligente de ultimă generație care să ofere o gamă largă de servicii avansate, cu valoare adăugată, peste o infrastructură unică. Abonații cu linii de acces diferite pot fi grupați MPLS fără a li se schimba mediul curent, deoarece MPLS este independent de tehnologiile de acces.
Rețelele IP tradiționale sunt fără conexiune: atunci când este primit un pachet, ruterul determină care va fi următorul nod de parcurs, folosind adresa IP destinație împreună cu informația din propriul său tabel de rutare. Tabelul de rutare conține informație despre topologia rețelei. Se folosesc protocoale IP de rutare, ca OSPF, BGP, RIP sau configurare statică, pentru a menține sincronizată informația din aceste tabele cu schimbările ce au loc în rețea.
Integrarea componentelor aplicației MPLS, incluzând VPN de nivel 2, VPN de nivel 3, QoS, GMPLS, Traffic Engineering, sau IPv6, dau posibilitatea dezvoltării unor rețele sigure și foarte eficiente, ce garantează SLA (Service Level Agreements).
MPLS oferă servicii IP end-to-end, cu un grad înalt de scalabilitate și de diferențiere, cu configurare și management simple, atât pentru furnizori cât și pentru abonații acestora. Această soluție este suportată de o gamă foarte largă de platforme, lucru esențial pentru furnizorii de servicii și pentru rețelele private.
Spre deosebire de IP-ul tradițional, fluxurile MPLS sunt orientate spre conexiune (CO = connection-oriented) și pachetele sunt rutate pe căi preconfigurate, numite LSP (Label Switched Paths).
2 .1 Terminologie MPLS
MPLS (Multiprotocol Label Switching) – o nouă tehnologie de comutație, numită comutația de etichete multiprotocol.
Planul de control (Control plane) – acolo unde controlul informației (cum ar fi rutarea și etichetarea informației) este schimbată.
Planul de date/planul de dirijare – acolo unde are loc dirijarea. Aceasta se poate realiza numai după ce planul de control a fost stabilit.
CEF (Cisco Express Forwarding) – o tehnologie foarte avansată de comutație de nivel 3 dezvoltata de compania Cisco pentru a optimiza performanțele rețelelor cu parametri de trafic foarte dinamici.
Etichetă (label) – o etichetă de lungime fixă pe care dirijarea serviciului MPLS se bazează. Termenul etichetă (label) poate fi folosit în două contexte diferite. Un termen se refera la eticheta de 20-biți. Celălalt termen se refera la eticheta antet, care are o lungime de 32 biți.
Asocierea etichetei (label binding) – asocierea unui FEC (prefix) la o etichetă. O etichetă distribuită de la sine nu este foarte folositoare. Destinatarul știe să aplice o etichetă specifică la un pachet de date care intră datorită asocierii la un FEC.
Adăugarea etichetei (label imposition) – procesul de adăugare a etichetei la un pachet de date într-o rețea de tipul MPLS.
Înlăturarea etichetei (label disposition) – procesul de înlăturare a unei etichete ce aparține unui pachet de date.
Comutarea etichetei (label swapping) – schimbarea valorii etichetei în antetul MPLS în timpul dirijării MPLS.
LSR (Label Switching Ruter) – reprezintă un ruter care suporta tehnologia MPLS – are capacitatea de a comuta pachete pe baza etichetei atașate acestuia.
Label Edge Ruter (LER) – Este un LSR care acceptă pachete neetichetate (pachete IP) și le adaugă etichete pentru rutarea în interiorul rețelei MPLS. LER de asemenea înlătura etichetele la marginea (granița) rețelei MPLS și trimite pachetele neetichetate în rețeaua IP.
Forwarding Equivalence Class (FEC) – Orice set de proprietăți care trasează pachetelor de intrare aceeași etichetă de ieșire. În general un FEC este echivalent cu o rută (toate pachetele destinate clasei 10.0.0.0/8 corespund aceluiași FEC), dar definiția unui FEC se poate schimba când pachetele sunt rutate după alte criterii decât destinația adresei IP.
Label Switched Path (LSP) – reprezintă o succesiune de noduri (R0…Rn) în cadrul cărora un pachet este comutat de la R0 până la Rn prin intermediul mecanismelor de comutație de etichete. O astfel de „cale de comutație de etichete” poate fi stabilită dinamic, prin mecanisme de rutare normale, sau static, prin configurare explicita.
Stiva de etichete (label stack) – diferit fată de schimbarea etichetelor dintre LSRs și vecinii lor, utilizat în aplicații cum ar fi MPLS-VPN, o etichetă capăt-la-capăt este schimbată. Ca rezultat, este utilizată o stivă de etichete în schimbul unei singure etichete MPLS. Un concept important de reținut este că dirijarea in rețelele core se bazează doar pe eticheta din vârful stivei de etichete . În contextul MPLS TE , stiva de etichete este solicitată când un pachet etichetat intră într-un tunel MPLS TE.
PE Ruter (Provider Edge Ruter) –ruter aflat sub administrarea furnizorului de servicii, conectat cu unul sau mai multe echipamente ale clientului.
CE Ruter (Customer Edge Ruter) – în mod similar cu PE Ruter, reprezintă un echipament aflat sub administrarea clientului, și care se conectează cu unul sau mai multe PE-Ruters.
P Ruter (Provider Ruter) – reprezintă un echipament din core-ul rețelei furnizorului de servicii, care nu se conectează direct cu niciun echipament al clientului. Acest tip de ruter este utilizat strict pentru a comuta pachetele cu etichete între ruterul PE de intrare (ingress) și cel de ieșire (egress).
Ingress Ruter – este ruterul PE prin intermediul căruia pachetele intră în rețeaua MPLS.
Egress Ruter – este ruterul PE prin intermediul căruia pachetele părăsesc rețeaua MPLS.
BGP (Border Gateway Protocol) – protocol de rutare intra-domeniu prin intermediul căruia ruterele schimba informație de rutare cu alte echipamente pe care rulează un soft BGP.
CoS (Class of Service) – o caracteristică ce oferă servicii diferențiate prin intermediul unei rețele MPLS.
GRE (Generif Ruter Encapsulation) – reprezintă un protocol de tunelare dezvoltat de către compania Cisco, care poate încapsula o largă varietate de tipuri de pachete în cadrul unor tunele IP creând astfel o legătura punct-la-punct virtuală între ruterele Cisco distante utilizând infrastructuri IP. Prin conectarea mai multor subrețele ce utilizează protocoale diferite de rutare, în cadrul unei infrastructuri IP, se creează un mediu de back-bone ce utilizează un protocol unitar.
IGP (Interior Gateway Protocol) – un protocol Internet utilizat pentru a schimba informație de rutare în cadrul aceluiași sistem autonom (Autonomous System). Exemple de astfel de protocoale sunt: OSFP, IGRP, RIP, iBGP.
IS-IS (Intermediate System-to-Intermediate System) – reprezintă un protocol de tipul link-state prin intermediul căruia, ruterele schimbă informație de rutare pe baza unei singure metrice cu scopul de a determina topologia rețelei.
LSP Tunnel – o conexiune configurată între două rutere, în cadrul căreia, pentru transmiterea pachetelor de date între cele două rutere, este utilizată tehnologia MPLS.
LSA (Link-state Advertisment) – reprezintă un pachet broadcast utilizat de protocoalele link-state. LSA conține informații despre toate ruterele vecine și costul căii până la acestea și este utilizat de către ruterul destinatar pentru a menține o tabelă de rutare.
Printre atributele rutei se numără: următorul nod BGP, adresă gateway și altele.
RD (Route Distinguisher) – reprezintă o valoare de dimensiune 8 octeti (64 biți) care se concatenează cu prefixul IPv4 pentru a realiza un prefix unic la nivel global VPN-IPv4. Datorită acestuia, la VPN-uri se pot utiliza adrese IP private care trebuie să fie unice numai pentru fiecare VPN în parte, nu și la nivel global.
RIP (Routing Information Protocol) – un protocol IGP utilizat pentru schimbul de informații de rutare în cadrul unui sistem autonom. RIP este un protocol simplu de implementat care utilizează ca metrica de rutare numărul de noduri.
Ruter Aval (Downstream Ruter) – reprezintă ruterul către care circulă pachetele de date în cadrul unei conexiuni. El ruterul care, de obicei, alocă etichetele necesare transmiterii de pachete prin intermediul tehnologiei MPLS.
Ruter Amonte (Upstream Ruter) – reprezintă ruterul dinspre care circulă pachetele în cadrul unei conexiuni. El primește o anumită etichetă pentru o destinație dată, de la ruterul aval și o atașează pachetelor pe care trimite către destinație.
Traffic Engineering (TE) – reprezintă o serie de tehnici și proceduri utilizate pentru a direcționa traficul rutat pe o anumită cale, alta decât cea care ar fi fost aleasă de către protocoalele de rutare standard pentru a obține în acest fel anumite avantaje.
Traffic Engineering Tunnel (TE Tunnel) – reprezintă un LSP utilizat pentru implementarea unei politici de TE. Este stabilit prin alte metode decât rutarea de nivel 3 clasică și este utilizat pentru direcționarea traficului pe o alta rută decât cea utilizată prin rutarea standard.
Tunelare – este o arhitectură care oferă serviciile necesare pentru implementarea oricărei strategii de încapsulare punct-la-punct.
VPN (Virtual Private Network) – O rețea securizată IP care partajează resursele în cel puțin una din rețelele sale fizice. Un VPN conține locații fizice distante care pot să comunice în siguranță folosind un back-bone partajat.
VRF (VPN Routing and Forwarding Instance) –constă în următoarele: o tabelă de rutare IP, o tabelă derivată de forwardare, un set de interfețe care vor utiliza tabela de forwardare, un set de reguli și protocoale care vor determina ce anume înregistrări vor fi inserate în tabela de forwardare. În general, un VRF conține informația de rutare care definește o locație VPN a unui client, care este atașată unui ruter PE.
2.2. Modul de funcționare a rețelelor MPLS
MPLS etichetează pachetele cu un identificator (etichetă) pentru a fi identificată o cale numită LSP (Label Switching Path). Atunci când un pachet este primit, ruterul folosește această etichetă pentru a identifica LSP-ul. Ulterior, el va căuta în propriul tabel de îndrumare pentru a determina calea de urmat pentru transmiterea pachetului și eticheta care va fi utilizată în cadrul următorului nod. Vechea etichetă este înlocuită cu una nouă și pachetul este trimis către următoarea destinație. În rețelele MPLS etichetele stabilesc regulile de trimitere a pachetelor. Se folosește o etichetă diferită pentru fiecare nod, și această etichetă este aleasă de către ruterul sau switch-ul care realizează operația de transmitere a pachetului. Ruterele de intrare ale rețelei MPLS folosesc adresa de destinație a pachetelor pentru a determina care va fi LSP-ul folosit. În interiorul rețelei, ruterele MPLS folosesc numai etichetele LSP pentru a îndruma pachetele către ruterul de ieșire.
Fig 2.2.1 Dirijarea pachetelor în interiorul unui domeniu MPLS
Există astfel o serie de avantaje față de mecanismele din rețelele clasice:
Transmiterea pachetelor poate fi efectuată de switch, care face verificarea etichetei și înlocuirea ei, dar nu face analiza pachetelor pe nivele OSI superioare.
Switch-urile ATM realizează funcții asemănătoare prin comutarea de celule bazate pe valorile VCI/VPI găsite în header-ele celulelor ATM. Dacă valoarea VCI/VPI este înlocuită cu etichete, atunci switch-urile ATM pot trimite celule în rețeaua ATM folosindu-se de valoarea etichetelor.
Switch-ul ATM trebuie să fie controlat de un element de control bazat pe tehnologia IP, numit LSC (Label Switch Controller) și care este elementul principal în integrarea tehnologiei IP cu tehnologia ATM folosind tehnologia MPLS.
Atribuirea pachet-etichetă se face la intrarea pachetului în rețeaua MPLS.
Ruter-ul de intrare poate folosi orice informație pe care o deține despre pachet, cum ar fi interfața de intrare sau portul, chiar dacă informația nu poate fi obținută din header-ul care descrie nivelul rețea. Același pachet are etichetă diferită dacă intră în rețea prin rutere diferite. Astfel deciziile de trimitere a pachetelor care depind de ruterul de intrare se realizează mai ușor.
Rețelele cu control de trafic obligă pachetele să urmeze o anumită cale, alegându-se calea cea mai liberă din punct de vederea al traficului. De obicei această cale este prestabilită când pachetele intră în rețea, și mai rar aceste căi sunt stabilite de algoritmi de rutare dinamici. În MPLS etichetele pot fi folosite ca reprezentări pentru diferite rute, astfel nu este nevoie de informații de rutare suplimentare în pachet.
Clasa de servicii pentru un pachet este determinată de către nodul MPLS prin care intermediul căruia intră pachetul. Acest nod poate aplica pachetelor diferite politici de prioritizare a pachetelor. Nodurile următoare pot aplica pachetelor diferite politici specifice nodului respectiv – numite PHBs (per-hop behaviors).[12]
Noduri in rețelele MPLS
În rețelele MPLS există 3 tipuri de noduri:
-Noduri de intrare (Ingress Label Edge Ruter) – au rolul de a clasifica fiecare pachet în clase de echivalență (FEC). Pentru fiecare clasă de echivalență se face o asociere către un NHLFE. Acest NHLFE conține informații despre ce trebuie făcut cu aceste pachete, care este eticheta de ieșire, și care este următorul nod. Corespondenta între FEC și NHLFE se numește FTN (FEC to NHLFE).
– Noduri intermediare (Label Switch Ruter) – realizează comutația etichetelor. Pentru o etichetă de intrare se consulta tabelul ILM și se afla ce NHLFE trebuie utilizat. Se consultă apoi NHLFE-ul indicat și se obține următoarea etichetă și următorul nod din cale.
– Noduri de ieșire (Egress Label Edge Ruter) – Elimină eticheta din vârful stivei și dirijează pachetul conform informațiilor rămase (de regulă conform tabelului de rutare IP). Și acest nod conține un LIB, dar mai conține și o tabela de rutare IP valida.[RFC3031]
Prelucrările făcute în aceste noduri sunt prezentate în figura următoare.
Fig. 2.2.2 Stiva de protocoale și tabelele folosite în nodurile MPLS
Nodurile MPLS, pe lângă comutarea de pachete bazate pe etichete, mai pot realiza și rutare Layer 3 sau switch-ing Layer 2.
În figura următoare este reprezentată arhitectura unui nod MPLS din punctul de vedere al celor două planuri:
Fig. 2.2.3. Arhitectura unui nod MPLS
Planul de trimitere pachete (Forwarding Plane)
Este responsabil de trimiterea de pachete bazată pe informația din etichetele atașate pachetelor. Acest plan folosește LFIB (Label Forwarding Information Base), o bază de date folosită pentru trimiterea pachetelor. Algoritmul utilizat de comutarea de pachete folosește informația conținută în LFIB, precum și informația conținută în etichetă. Fiecare nod MPLS are două tabele importante: LIB ( Label Information Base) și LFIB.
LIB conține toate etichetele asignate de nodul MPLS local și legătura acestor etichete cu etichetele recepționate de la nodurile MPLS vecine.
LFIB folosește un subset de etichete din LIB pentru transmiterea pachetelor.
2.2.1 Etichetele MPLS
Etichetele sunt o parte integrala a “Multiprotocol Label Switching”. Eticheta permite decuplarea rutării de dirijare, permițând astfel să se realizeze abil unele lucruri.
MPLS poate opera in două moduri:
-Frame mode (modul cadru)
-Cell mode (modul celula)
2.2.1.1 Frame mode
Frame mode este termenul folosit atunci când se dirijează un pachet cu o etichetă atașată pachetului în fata antetului de Layer 3 (de exemplu: antetul IP).
O etichetă este valoarea atașată pachetului de date care spune rețelei unde pachetul ar trebui să ajungă. Eticheta are 20 biți, ceea ce înseamnă ca exista 2²ș posibile valori a etichetei.
Un pachet poate avea multiple etichete, comasate în ceea ce se numește: stivă de etichete. O stivă de etichete este un set de una sau mai multe etichete per pachet. La fiecare hop într-o rețea, este luată în considerare numai eticheta cea mai de sus. Eticheta pe care un LSR o folosește pentru a dirija pachetul în planul de date este eticheta asignată și distribuită în planul de control.
Când etichetele sunt plasate într-un pachet, valoarea etichetei însăși de 20 de biți este codată cu niște elemente adiționale de informație care asistă în dirijarea pachetului etichetat prin (în) rețea.
În continuare este prezentată structura acestui antet, precum și câmpurile sale.
Fig. 2.2.4 Structura antetului MPLS
ETICHETA=20 biți
EXP=Experimental,3 biți
S=Baza stivei (Bottom of stack),1 bit
TTL=Timpul de viată (Time to live),8 biți
Eticheta MPLS și cu antetul acesteia este ilustrată mai sus, în Figura 2.2.4. Ea este formată din următoarele câmpuri:
Eticheta propriu-zisă, care are dimensiunea de 20 biți.
Câmpul EXP (Experimental) se folosește pentru a indica Clasă de Servicii (CoS) și are dimensiunea de 3 biți. Aceasta înseamnă ca se pot folosi simultan maxim 2³ = 8 clase de servicii.
Câmpul S (baza stivei de etichete) are dimensiunea de 1 bit și este folosit pentru a indica daca eticheta curenta este ultima, prin eliminare rezultând un pachet nativ IP, sau dimpotrivă, sub eticheta curenta se mai găsesc alte etichete.
Câmpul TTL (Time to Live, Timp de Viata) are dimensiunea de 8 biți și se folosește pentru evitarea apariției buclelor.
Eticheta Stivă
Bitul de stivă implementează stiva de etichete MPLS, în cazul în care unui pachet IP i se atașează mai mult de o singură etichetă. Bitul de stivă este setat la "1" pentru a indica stivă goală și la "0" pentru celelalte situații. În eticheta MPLS, vârful stivei apare chiar după header-ul nivelului Legătura de date, iar sfârșitul stivei chiar înainte de header-ul nivelului Rețea. Trimiterea de pachete este făcută ținând cont de eticheta din vârful stivei. Rutarea IP unicast nu folosește etichete stivuite, dar MPLS VPN (Virtual Private Network) și controlul și managementul traficului folosesc etichetele stivuite.
TTL
În rutarea IP tradițională, fiecare pachet de date poartă în antetul său o valoare numită “timp de viață”. De fiecare dată când un pachet trece printr-un ruter, valoarea să TTL este decrementată cu o unitate; dacă TTL ajunge la 0 înainte ca pachetul de date să ajungă la destinație, pachetul va fi eliminat. Acest lucru asigură un anumit nivel de protecție împotriva buclelor de rutare care pot exista datorită configurărilor greșite, sau datorită erorilor sau convergenței slabe a algoritmilor de rutare. TTL este câteodată folosit pentru alte funcții, cum ar fi comanda “traceroute” sau multicast scoping. Acest lucru implică faptul că avem două probleme legate de TTL:
TTL ca o modalitate de a suprima buclele;
TTL ca modalitate de a realiza alte funcții, cum ar fi limitarea utilizării unui pachet.
Când un pachet traversează un LSP, el ar trebui să iasă din acesta cu aceiași valoare TTL pe care ar fi avut-o dacă ar fi traversat aceiași secvență de rutere, însă ruterele să nu fi fost comutatoare de etichete. Dacă pachetul traversează o ierarhie de LSP-uri, numărul total de -uri traversate va fi reflectat în valoarea TTL atunci când pachetul va ieși din această ierarhie de LSP-uri.
LFIB (Label Forwarding Information Base)
Această bază de date conținută în nodul MPLS constă într-o secvență de intrări
Fig. 2.2.5 Structura LFIB
Fiecare intrare este alcătuita dintr-o etichetă de intrare și una sau mai multe subintrări. LFIB este indexat de valoarea conținută în eticheta de intrare.
Fiecare subintrare este alcătuită dintr-o etichetă de ieșire, o interfață de ieșire și adresă nodului următor. Trimiterea de pachete multicast necesită subintrări cu multiple etichete de ieșire, deoarece un pachet ce intră pe o interfață trebuie să iasă pe una sau mai multe interfețe de ieșire. Pe lângă eticheta de ieșire, interfața de ieșire, și informația despre nodul următor, o intrare în tabela de trimitere a pachetelor poate cuprinde informații referitoare la resursele ce pot fi folosite de către pachet, cum ar fi coada de ieșire în care ar trebui plasat pachetul respectiv.
Un nod MPLS poate avea o singura tabelă de trimitere a pachetelor, o tabelă pe fiecare interfață, sau o combinație dintre cele doua.[12]
2.2.1.2 Cell mode (modul celulă)
Un termen folosit atunci când rețeaua conține ATM LSRs care utilizează MPLS în planul de control pentru a schimba informația din câmpul VPI/VCI, în locul semnalării ATM.
În cell mode, in câmpul celulei VPI/VCI (Figura 2.2.6) eticheta este codată. După ce, în planul de control schimbul etichetei este realizat, în planul de date, ruterul de intrare segmentează pachetul în celule ATM, aplică valoarea corespunzătoare VPI/VCI care a fost schimbată în planul de control și transmite celulele. În mijlocul rețelei MPLS, ATM LSR se comportă asemănător comutatoarelor ATM normale. La ieșirea din rețeaua MPLS, ruterul de ieșire reasamblează celulele într-un pachet de date.
Cell mode se mai numește și Label-Controlled ATM(LC-ATM). MPLS TE nu este suportat in cell mode pe ruterele Cisco.
Denumirea de Comutație de Etichete Multiprotocol provine de la faptul că aceasta tehnologie poate fi folosita în conjuncție cu mai multe protocoale, precum ATM, SONET, SDH, etc. Pentru a putea funcționa la fel cu fiecare dintre aceste protocoale, a fost necesar să se stabilească în ce mod eticheta MPLS va fi încapsulată în cadrele cu o structura deja stabilită.
Aceasta încapsulare se realizează ca în Figura 2.2.6.
Fig 2.2.6 Așezarea etichetei în celula ATM și în pachetul Ethernet
În cazul ATM, eticheta înlocuiește perechea VPI-VCI. În cazul în care se folosește PPP (SONET sau SDH), eticheta se interpune între antetul nivelului rețea și antetul PPP. În mod similar, la antetul LAN MAC, eticheta se interpune între antetul MAC și antetul nivelului rețea, acest lucru se intitulează adăugarea antetului. Când operam in “frame-mode” (modul cadru) MPLS vom avea întotdeauna adăugarea de antet. Acest lucru este aplicabil și când se conectează rutere peste ATM PVCs și se realizează MPLS in mediul clasic IP-peste-ATM.
2.3 Arhitectura MPLS
MPLS este alcătuit din două mari componente, planul de control și planul de date.
2.3.1 Planul de control
Este responsabil de popularea și menținerea informației din LFIB. Toate nodurile MPLS trebuie să ruleze un protocol de rutare IP pentru a schimba informație IP de rutare cu toate celelalte noduri MPLS din rețea. Nodurile ATM ce pot trimite pachete MPLS lucrează cu un LSC (Label Switch Controller) pentru a putea participa la acest schimb de informație.
Protocoalele de rutare IS-IS (Intermediate System to Intermediate System) sau OSPF (Open Shortest Path First), pot fi o alegere pentru protocoale de distribuire. În ruterele convenționale, tabela de rutare IP este folosită pentru a construi FSC (Fast Switching Cache) sau FIB (Forwarding Information Base). În rețelele MPLS, tabele de rutare IP furnizează informație în rețeaua destinație pentru atribuirea de etichete pachetelor.
Informația despre distribuirea etichetelor poate fi transportată în rețea folosind protocolul LDP (Label Distribution Protocol).
Protocolul de rutare OSPF inundă cu informație ruterele care nu sunt neapărat adiacente, în timp ce distribuirea de etichete cu ajutorul protocolului LDP se face doar la ruterele adiacente din rețeaua MPLS. Acest lucru face evidentă alegerea unui protocol special de distribuție a informațiilor despre etichete.
Planul de control:
– construiește o tabelă de rutare (RIB-Baza de rutare a informației) pe baza protocoalelor de rutare.
– folosește un protocol de schimbare a etichetei pentru a crea și a menține etichetele interne și pentru a schimba aceste etichete cu alte echipamente. Protocoalele de schimbare a etichetei includ MPLS LDP sau TDP, BGP(folosit de MPLS VPN) și RSVP (folosit de MPLS TE pentru a realiza schimbul de etichete).
– construiește de asemenea două tabele de dirijare: FIB de la informațiile din RIB și LFIB (Label Forwarding Information Base) ce se bazează pe protocolul de schimbare a etichetei și RIB. Tabela LFIB include valoarea etichetelor și asocierea acestora cu interfețele de ieșire pentru fiecare prefix a rețelei.
Etichetele schimbate cu nodurile MPLS adiacente sunt folosite la construirea LFIB. MPLS folosește o metoda de trimitere a pachetelor bazată pe schimbarea etichetelor care poate fi combinată cu o serie de diferite module de control. Fiecare modul de control este responsabil pentru distribuirea și asignarea etichetelor, precum și de menținerea altor informații.[12]
Module de control MPLS
Modulele de control MPLS includ:
Modulul de rutare Unicast
Modulul de rutare Multicast
Modulul de control al traficului
Modulul de VPN (Virtual Private Network)
Modulul de QoS (Quality of Service)
Modulul de rutare Unicast
Construiește tabela FEC folosind IGP (Interior Gateway Protocol). Tabela de rutare IP este folosită pentru a schimba informația despre etichete cu nodurile/ruterele adiacente. Aceasta schimbare de informație se face prin intermediul protocolului LDP.
Modulul de rutare Multicast
Construiește tabela FEC folosind un protocol de rutare numit PIM (Protocol Independent Multicast). Tabela de rutare multicast este folosită pentru a schimba informații despre etichete cu nodurile alăturate pentru subrețelele din tabela de rutare multicast.
Modulul de control al traficului
Modulul de control al traficului lasă explicit ca anumite LSP (Label Switched Path) să fie create în rețea din motive de control al traficului. Folosește definiția de tunel MPLS și o extensie a protocolului de rutare OSPF pentru a construi tabela FEC. Schimbul de etichete este făcut cu ajutorul protocolului RSVP (Resource Reservation Protocol) sau CR-LDP(Constraint-based Routing LDP) care este o extensie a protocolului LDP.
Modulul VPN (Virtual Private Network)
Este folosit pentru tabelele de rutare VPN și pentru asocierile FEC, in cazul VPN-urilor implementate prin etichete stivuite.
Modulul de QoS
Construiește tabela FEC folosind protocoale de rutare IGP cum ar fi: IS-IS, OSPF, etc. Tabela de rutare IP este folosită pentru schimbul de etichete între nodurile MPLS adiacente.
2.3.2 Planul de date
Este o simplă mașină de dirijare ce este independentă de protocolul de rutare sau protocolul folosit pentru schimbarea etichetei. Planul de date dirijează pachetele pe interfața corespunzătoare pe baza informațiilor obținute din tabelele LFIB și FIB.
Fig. 2.3 – Baza de informație
Algoritmul de trimitere a etichetelor
Switch-urile de etichete folosesc un algoritm de trimitere bazat pe înlocuirea de etichete. Nodurile MPLS care folosesc tabele LFIB, extrag valorile etichetei din câmpul de etichetă al pachetelor care au sosit și folosesc aceasta valoare ca index în LFIB. După ce a găsit o intrare în tabelă, nodul MPLS înlocuiește eticheta din pachet cu eticheta de ieșire din subintrarea corespunzătoare, trimite pachetul prin interfața specificată către nodul următor specificat în subintrare.
Dacă subintrarea specifică și o coadă de ieșire, atunci nodul MPLS plasează pachetul în coada respectivă. Dacă nodul MPLS folosește multiple tabele LFIB pentru fiecare interfață a sa, el va folosi interfața pe care vine pachetul pentru a selecta un LFIB care va fi folosit pentru trimiterea pachetului mai departe în rețea.
În rețelele convenționale, pentru transmiterea pachetelor se folosesc mai multe tipuri de algoritmi în funcție de tipul pachetelor, unicast, multicast și pachete unicast cu biții de Type of Service (ToS) setați. În tehnologia MPLS se folosește o singura metodă de transmitere a pachetelor, cea bazată pe înlocuirea de etichete.
Un nod MPLS poate să obțină toată informația de care are nevoie pentru a transmite un pachet precum și rezervarea resurselor necesare pentru transmitere folosind o singură memorie de acces. Acest lucru conduce la o mărire a vitezei de transmitere a pachetelor. MPLS suportă de asemenea transportul altor protocoale de nivel 3, cum ar fi: Ipv6, IPX sau AppleTalk.
2.4 Elementele MPLS
Principalele elemente MPLS sunt:
Comutator de Etichete (Label Switched Ruter ) – LSR
Cale cu comutație de etichete (Label Switched Path ) – LSP
Protocol pentru distribuția etichetelor (Label Distribution Protocol) –LDP, CR-LDP, RSVP, BGP.
2.4.1 Comutator de Etichete (Label Switch Ruter) – LSR
LSR este un echipament care implementează componentele de trimitere și control MPLS. LSR-ul trimite un pachet de date bazându-se pe valoarea unei etichete încapsulate în pachet. De asemenea, LSR-ul poate trimite pachete de Layer 3.
LSR-urile sunt rutere ce pot prelucra pachete MPLS sau switch-uri ATM care folosesc etichete pentru a transmite pachetele de date.
LSR-urile bazate pe pachete, pot fi ușor construite prin încărcarea unui modul software într-un ruter obișnuit. LSR-urile ATM/MPLS sunt construite folosind switch-urile ATM, cu software MPLS integrat sau prin adăugarea facilitații MPLS folosind un LSC (Label Switch Controler) extern.
Un pas important în comutarea de etichete, este comunicarea între LSR-uri pentru stabilirea etichetelor pe care le vor utiliza pentru a transmite pachete. Ele cad de acord folosind protocolul Label Distribution Protocol (LDP) sau extensii ale lui cum ar fi: BGP, PIM, RSVP, sau CR-LDP. LSR-urile de nod de rețea MPLS, sunt localizate în locațiile de prezenta POP (Point of Presence) sau la granița rețelei MPLS și aplică etichete sau stive de etichete pachetelor.
Atribuirea de pachete sau pregătirea etichetelor pentru pachete este denumită acțiune „push".
LSR-urile de nod fac înlăturarea etichetelor în punctele de ieșire din rețeaua MPLS, acțiune care se mai numește acțiune „pop". LSR-urile de nod de rețea pot de asemenea trimite pachete IP normale.
Acțiunile care pot fi întreprinse de un LSR sunt enumerate în continuare.
Tab. 1. Acțiunile care pot fi întreprinse de un LSR
Operațiile LSR bazate pe pachete
MPLS folosește noțiunea de transmitere de pachete bazate pe etichete pentru a transporta pachete de Layer 3 peste o rețea bazată pe rutare. Operațiile de baza ale unui LSR sunt figurate în desenul următor:
Fig. 2.4.1 Operații de baza LSR
LSR1 funcționează ca un ruter LSR de nod de rețea. El aplică etichete inițiale pachetului de date după ce face o verificare convențională a header-ului IP și determină FEC-ul pentru pachetul respectiv. Parametrii cum ar fi: interfața de intrare, în cazul unui VPN, sau o cale predeterminată de trimitere a pachetului, pot determina alegerea unui anume FEC. Această alegere a FEC-ului este realizată o singură dată la intrarea în rețeaua MPLS. După ce pachetul este etichetat, LSR-ul următor trimite pachetul folosind strict eticheta. LSR-urile înlocuiesc eticheta unui pachet venit cu o nouă valoare pe care o trimit mai departe. La ieșirea din rețea, LSR4 face o căutare în tabela lui internă, extrage eticheta atribuită anterior, și face o căutare de Layer 3 pentru a găsi următoarea destinație trimițând pachetul către aceasta. [19]
2.4.2 Cale cu comutație de etichete (Label Switched Path) – LSP
LSP-ul este o conexiune configurată între două LSR-uri în care, pentru a transmite pachete, este folosită tehnica de comutare de etichete. Un LSP este o cale specifică de trafic printr-o rețea MPLS. LSP-urile sunt furnizate folosind LDP-ul, CR-LDP (Constraint-Based Routed LDP), RSVP-TE (Resource Reservation Protocol with Traffic Engineering) sau extensii ale protocoalelor de rutare cum ar fi BGP.
CR-LDP rulează peste protocolul TCP și RSVP-TE rulează peste protocolul UDP.
Protocolul RSVP-TE este mai indicat pentru interoperabilitatea cu rețelele IP. LSP-ul poate fi considerat ca o cale printre mai multe LSR-uri în care pachetele aparțin unui anumit FEC. Este posibil ca într-o rețea MPLS să avem diferite LSP-uri la diferite nivele ale etichetelor pentru un pachet care își atinge destinația. LSP-urile sunt unidirecționale – un pachet se poate întoarce pe căi diferite.
În figura următoare, LSR-uri de nod sunt LSR1 și LSR6, și LSR2, LSR3, LSR4 și LSR5 sunt LSR-uri de backbone. Pentru a putea trimite etichetele, LSR1 și LSR6 lucrează la nivel de „border gateway" și LSR2, LSR3, LSR4 și LSR5 lucrează la nivel de „interior gateway". Acest desen figurează două LSP-uri: un LSP de nivel 1 capăt la capăt de la LSR1 la LSR6, și un LSP de nivel 2 între LSR4 și LSR5. Pentru a putea construi un LSP, LSR-ul folosește protocoale de rutare și rutele învățate de la aceste protocoale.
Fig. 2.4.2 Stabilirea unui LSP
Un LSP se poate stabili folosind una din cele două posibilități:
Controlul independent;
Controlul ordonat.
Acestea pot coexista în aceeași rețea fără niciun fel de problemă d.p.d.v. al arhitecturii sau interoperabilității. Metoda independentă furnizează o convergență și stabilire a LSP-ului mai rapida, deoarece, LSR-ul poate stabili și trimite etichete oricând, fără întârziere sau așteptare pentru mesajele ce urmează a fi propagate dintr-o parte a rețelei într-alta. Stabilirea LSP-ului depinde foarte mult de protocolul de rutare. În metoda controlului ordonat, legăturile sunt propagate de-a lungul rețelei înainte ca LSP-ul să fie stabilit. Această metodă furnizează o mai bună prevenire și evitare a buclelor. [12]
2.4.3 Protocoale de distribuție a etichetelor
2.4.3.1 LDP (Label Distribution Protocol)
Este un protocol definit în RFC 3036. În acest document sunt specificate mesajele comunicate între noduri, precum și formatul acestor mesaje.
Primul pas într-o sesiune LDP este descoperirea vecinilor. Astfel toate nodurile trimit pachete de tip “Hello” la o adresă multicast. Doar vecinii direcți vor răspunde și astfel se va stabili o sesiune TCP între 2 vecini. Prin intermediul acestei sesiuni, cei doi vecini își comunica parametrii doriți. După inițierea sesiunii, partenerii trimit un mesaj de tip “Initialization” prin intermediul căruia stabilesc modul de funcționare (cum ar fi dacă se folosește detecția buclelor, sau distribuția etichetelor nesolicitată). Dacă parametrii sunt acceptați începe distribuția etichetelor prin mesaje care realizează o corespondență de genul: “pentru a ajunge la destinația X folosește eticheta Y”. Nodurile își comunica pe rând destinațiile cunoscute și etichetele ce vor trebui folosite pentru ca pachetele să ajungă la destinație.
Dacă o etichetă propusă nu este acceptată (cel mai probabil deoarece este deja folosită și nodul nu suporta modul de lucru cu spațiu de etichete pe interfață), se răspunde cu un mesaj “Notification”. Astfel, cei doi vecini negociază ce etichete vor folosi pentru anumite destinații și la finalul negocierii își completează tabela de dirijare.
Fig. 2.4.3(1) Stabilirea sesiunilor LDP între vecini
Conexiunea TCP între cei 2 vecini este menținută permanent și periodic se transmit mesaje de tipul „KeepAlive”. Mesajele inițiale de tip „Hello” sunt trimise prin UDP și au un rol similar cu mesajele „KeepAlive”. Diferența este ca mesajele „Hello” indica faptul ca un link între vecini este activ, pe când mesajele „KeepAlive” indica faptul ca un vecin este activ. Acest lucru este evident când exista mai multe linkuri între 2 vecini; astfel se vor primi mai multe pachete „Hello”, dar un singur „KeepAlive”. Soluția aceasta ajuta LDP-ul să fie mai scalabil în rețelele mari.[RIBL][RFC3036][MPLS-TE]
Distribuția etichetelor se poate face în două moduri:
-Downstream on Demand.
-Downstream Unsolicited.
Modul Downstream on Demand presupune construirea căii LSP când apare necesitatea de a transmite trafic prin intermediul acelui LSP. Nodul de intrare în rețeaua MPLS primește trafic corespunzător unui FEC nou. Entitatea LDP va solicita o etichetă nodului din aval. Nodul din aval transmite și el o solicitare de etichetă următorului nod și nu trimite nimic înapoi nodului de intrare până nu primește răspuns la solicitarea transmisă. Procesul continuă până când penultimul nod solicită o etichetă nodului de ieșire. Abia apoi, etichetele sunt alocate începând de la nodul de ieșire până la nodul de intrare, de unde și numele downstream-on-demand .
Fig. 2.4.3.(2) Modul de lucru Downstream on Demand
În modul de lucru Downstream Unsolicited un ruter propune etichete pentru toate prefixele IP cunoscute, către toti vecinii, fie ca au solicitat sau nu etichete.
Deoarece etichetele propuse nu sunt folosite efectiv în dirijarea pachetelor în mod implicit, nu este greșit să se trimită etichete tuturor vecinilor, chiar dacă acei vecini nu folosesc acest ruter ca următorul nod. LDP nu este un protocol de rutare; el depinde de un protocol de rutare pentru a elimina buclele (deși are și mecanisme de detecție și prevenire a buclelor, folosibile în rețele ATM).
Modul de lucru Downstream Unsolicited presupune faptul că un nod poate primi etichete de care nu are nevoie. Se pune problema dacă nodul va stoca acele etichete în cazul în care va fi nevoie de ele, sau dacă le va ignora. Modul de lucru conservator implică că ruterul va arunca etichetele de care nu are nevoie, ceea ce conduce la eliberarea de spațiu în tabela de dirijare, dar în același timp duce la stabilirea mai lentă a căilor. Modul liberal implică stocarea tuturor etichetelor primite și introducerea lor în tabela de dirijare, acest lucru mărește spațiul ocupat, dar reduce timpul necesar de stabilire a căilor.
Alocarea etichetelor nu este singurul lucru pe care îl face LDP, în anumite cazuri etichetele sunt retrase (dacă un link către o destinație se defectează), astfel încât trebuie să existe mesaje pentru realiza acest lucru.
Ca o particularitate, LDP preia o parte din funcțiile MPLS în anumite scenarii. De exemplu, în rețelele ATM, celulele MPLS nu au câmpul TTL. La intrarea în domeniul MPLS-ATM nodul de intrare decrementează TTL-ul pachetelor cu mai multe unități conform cu numărul de noduri pe care trebuie să le traverseze. Semnalizarea legata de numărul de noduri se face prin pachete LDP. De asemenea, pentru evitarea buclelor în rețelele ATM se folosesc câmpuri speciale din pachetele LDP pentru a stoca lista de noduri traversate. Dacă un nod apare de două ori, înseamnă ca există o buclă pe calea respectivă.[RFC3036][MPLS-TE]
2.4.3.2 CR-LDP (Constraint Route Label Distribution Protocol)
Constraint-based Routing Label Distribution Protocol este o extensie a protocolului LDP și introduce capabilități de construcție a căilor comutate bazându-se și pe alte informații, nu doar pe informațiile oferite de protocolul de rutare. Astfel, se pot construi căi cu constrângeri explicite ale rutei (de exemplu se impune ca o rută să treacă prin anumite noduri) sau cu constrângeri de calitate a serviciilor oferite. De regula, CR-LDP află informațiile necesare despre capabilitățile linkurilor (banda disponibilă, delay, jitter, etc) de la un protocol de rutare cu astfel de capabilități. Un exemplu de astfel de protocol este OSPF-TE. CR-LDP a fost gândit să fie utilizat în Traffic Engineering, dar poate fi folosit și în construirea VPN-urilor bazate pe MPLS.[RFC3213]
2.4.3.3 RSVP-TE (Resource Reservation Protocol)
RSVP-TE reprezintă o propunere de a adauga funcționalitate unui protocol deja consacrat, care să-i permită să distribuie și etichete. Ideea a aparținut companiei Cisco și astfel protocolul RSVP-TE a adoptat conceptele de QoS din IP în detrimentul conceptelor QoS din ATM.
Această alegere a avut ca scop principal interconectarea mai ușoara între provideri. Deși inițial RSVP nu a fost folosit în rețelele core deoarece nu era scalabil, folosirea sa împreună cu MPLS îi crește considerabil scalabilitatea. În acest scenariu clasele de echivalenta MPLS nu mai sunt la fel de rigide ca fluxurile RSVP, iar garanțiile oferite nu mai sunt capăt la capăt. RSVP-TE este utilizat pentru a stabili căi cu garanții numai în interiorul domeniului MPLS.
În mod curent există o concurență între RSVP-TE și CR-LDP, dar se pare că RSVP-TE este mai larg răspândit, deoarece a fost implementat timpuriu în echipamentele Cisco. [RFC3210]
2.4.3.4 BGP( Border Gateway Protocol )
Distribuția de etichete MPLS prin BGP implică o extensie a protocolului BGP. Dorința a fost să se poată interconecta domenii autonome MPLS, fără a fi necesar să se ajungă la IP. În plus, BGP este larg răspândit în domeniile ce oferă soluții VPN, având un rol important în stabilirea VPN-urilor MPLS. Totuși, între nodurile vorbitoare de BGP trebuie să se stabilească căi MPLS folosind alt protocol de distribuție de etichete.
2.5 Avantaje și dezavantaje ale tehnologiei MPLS
Tehnologia MPLS a fost definitivată în anul 2001, când specificațiile sale au fost ridicate la rang de standard. Totuși, de atunci implementările MPLS nu au crescut în ritmul așteptat. Acest lucru s-a datorat mai multor factori, cum ar fi recesiunea economică din 2001, care a dus la scăderea volumului de afaceri purtate prin Internet. În ultimii ani, rețelele MPLS au început să se dezvolte, în principal prin beneficiile pe care le aduc furnizorilor de servicii.
În continuare sunt argumentate câteva idei ce susțin folosirea MPLS în rețelele core , dar și câteva idei care neagă importanța acestuia:
Avantaje
– Ruterele care nu au circuite specializate pentru procesul de rutare, sau alte metode pentru căutări rapide vor beneficia de o creștere de viteză în cazul folosirii unei implementări software MPLS;
– Este ușor de integrat treptat în rețele mari bazate pe IP, deoarece ruterele MPLS pot comunica cu ruterele tradiționale IP;
– Este flexibil deoarece se poate baza pe informațiile de rutare furnizate de către protocoalele de rutare tradiționale folosite și de IP;
– Permite realizarea de rețele virtuale private (VPN) cu un overhead mai mic decât în cazul IP-ului;
– Permite realizarea mai ușor a unor funcții de Traffic Engineering;
– MPLS se poate integra ușor în spectrul de servicii IP QoS.
Dezavantaje/Critici
-MPLS are o dinamicitate mai mică față de IP, deoarece lucrează cu conexiune, și stabilește căi înainte de a transmite datele. Dacă o cale se întrerupe, protocolul de distribuție de etichete va sesiza acest lucru după protocolul de rutare și va construi o nouă cale înainte de a trimite trafic pe ea.
-Comutația MPLS nu este mai rapidă decât rutarea IP. Ruterele noi folosesc memorii cache în care stochează rutele cele mai des folosite. Astfel căutarea în tabelul de rutare se reduce considerabil. Într-un domeniu MPLS, ruterul de intrare și cel de ieșire trebuie să aibă și funcționare IP. Prin faptul ca au de făcut și prelucrări specifice MPLS, timpul lor de prelucrare e mai mare decât pentru un ruter IP.
-Celelalte rutere au, într-adevăr un timp de prelucrare mai mic, dar aceasta performanță se vede doar pentru căi cu mai mult de 5 noduri; dacă sunt mai puține noduri, performanta ruterelor IP e mai buna. În plus, ruterele MPLS pot consuma mai multa memorie decât ruterele IP (deoarece trebuie să memoreze și un tabel de rutare și un tabel de dirijare).
-MPLS nu are suport nativ pentru QoS – acest lucru a fost adăugat ulterior prin folosirea biților EXP. În anumite situații, clasele de servicii diferențiabile prin 3 biți pot să fie insuficiente pentru anumite rețele. De asemenea, pot apărea probleme la implementări diferite; unii constructori pot să nu tină cont de biții EXP. [MPLS-Myths] [RIBL] [L3vsL2]
Cap.3. Ingineria Traficului în rețele MPLS
3.1 Necesitatea Ingineriei de Trafic în MPLS
Rolul ingineriei traficului (Traffic Engeneering – TE) într-o rețea este de a transmite traficul de la o margine la alta, în cel mai optim mod. Cum în zilele actuale rețele se bazează în principal pe o soluție 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 întreaga rețea cât mai rapid posibil. Acesta este motivul pentru care rutarea IP este bazată 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 fiecărui link pentru o cale, este folosita pentru a calcula cel mai mic cost al căii. Acest cost reprezintă o metrică ce este atribuită unui link (de exemplu, Open Short Path First [OSPF] și Intermediate System to Intermediate System [IS-IS]), o metrică compusă (de exemplu, Interior Gateway Routing Protocol [IGRP] și Enhanced Interior Gateway Routing Protocol [EIGRP]), sau pur și simplu un 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 ruter poate păstra dirijarea de trafic pe o legătură, chiar dacă acest link este deja plin și produce pierdere de pachete.
Fig. 3.1 Dirijarea in rețele IP
De exemplu, în 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 ruterul R1 la ruterul 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.
Puteți distribui sarcina uniform schimbând costul pe link-uri pentru un anumit protocol de dirijare. Asta ar putea distribui traficul mai uniform, dar niciodată nu poți distribui sarcina perfect, deoarece, în reț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ă vă asigurați că cele două căi sunt egale făcând suma costurilor de link-uri în calea R1-R2-R5 și calea 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 către R4, și așa mai departe. Avem iar aceeași problemă, pentru că există două căi de la R2 la R4, puteți avea aceeași problemă între rutere R3 și R5 sau la oricare dintre celelalte. De asemenea în orice zi se poate lua decizia creșterii capacitații unui link, în acest caz fiind inutil calculul făcut mai devreme și va trebui să refacem costurile.
MPLS TE este o soluție pentru că:
– ajută la răspândirea eficienta a traficului în întreaga rețea, evitând neutilizarea sau suprautilizarea link-urilor;
– ține seama de configurațiile (statice) de lățime de bandă ale legăturilor;
– ia în considerare atributele legăturilor, precum: întârziere, jitter,etc;
– se adaptează automat la schimbarea de lățime de bandă pe un link;
– se poate trimite traficul in rețea după adresă sursă a pachetelor, nu neapărat după cea destinație.
MPLS TE permite ingineria traficului pentru un sistem în cazul în care ruterul de la capul unei LSP (headend) poate calcula cea mai eficientă cale prin intermediul rețelei spre ruterul de la coada LSP (tailend). Ruterul de la capul LSP poate face acest lucru în cazul în care acesta cunoaște topologia de rețea. În plus, ruterul 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 rutere astfel încât să se poată stabili LSP-uri cap la cap. Faptul că schimbarea de etichete este utilizata și nu comutarea după IP, calea poate fi definita in funcție de adresă sursă IP în loc de destinație. Asta se datorează faptului că MPLS transmite in planul de date potrivind eticheta de sosire din tabela LFIB și o schimba cu o eticheta de expediere.[30]
Prin urmare, ruterul 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ă folosească pentru care LSP. Figura de mai jos arată un exemplu de dirijare pe baza de sursa, capacitate a MPLS TE.
Fig.3.2 Dirijarea cu ingineria traficului
În figura 3.2, R6 dorește să trimită traficul pe calea R6-R1-R2-R5, iar R7 vrea să transmită traficul de-a lungul căii R7-R1-R3-R4-R5, acest lucru este imposibil să se realizeze într-o rețea IP clasica. În cazul în care se folosește o rețea MPLS, puteți configura aceste două căi ca două LSP-uri diferite, astfel încât etichete diferite sunt folosite. La ruter R1, valoarea diferita a etichetei de sosire indică dacă pachetul aparține de LSP-ul cu ruterul R6 ca și cap sau de LSP cu R7. R1 apoi înaintează pachetele pe una dintre cele două LSP-uri, dar nu după propriile sale dorințe cum era cazul cu simpla forwardare IP.
Există posibilitatea să se implementeze MPLS TE în orice rețea care are LSR-uri. Cu toate acestea, deoarece lățimea de bandă și alte atribute de link-uri trebuie să fie cunoscute de către LSR-ul de la capul LSP-ului, protocolul de dirijare folosit între capetele MPLS TE (LSR-ul cap și LSR-ul coada) trebuie să fie un protocol de dirijare link-state. Cu un astfel de protocol, fiecare ruter construiește o tabela cu stările link-urilor, care este apoi inundata la toate celelalte rutere în aceeași zonă. Aceasta înseamnă că, toate rutere 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țională, și are configurația tunelului TE numai la capul de la începutul LSR-ului, și nu la LSR-ul de la coada LSP-ului.
Dacă ingineria traficului este activată în rețea există posibilitatea de a crea tunele MPLS TE între orice pereche de LSR-uri din rețea. Ca atare, există posibilitatea să se orienteze tot traficul din rețea, evitând congestionarea în ea, și să se dea tot traficul in funcție de caracteristici (de lățime de banda, întârziere, bruiaj și așa mai departe) de care este nevoie. Acest lucru este esențial pentru miezul rețelei (CORE – backbone) al providerilor de servicii.
3.2 Modul de lucru al ingineriei traficului în MPLS
MPLS este o integrare a tehnologiilor Layer 2 și Layer 3. Prin aducerea caracteristici 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 calculate la capul tunelului pe baza resurselor necesare și resurselor disponibile. IGP-ul automat rutează acest trafic în aceste tuneluri. De obicei, pachetele ce trec o rețea cu MPLS TE în backbone circulă pe un singur tunel, care conectează punctul de pătrundere la cel de ieșire.
Ingineria de trafic in MPLS este construită pe următoarele mecanisme:
• Constrângerile legăturilor : cât de mult trafic fiecare link poate sprijini și cât poate utiliza tunelul TE;
• Distribuția informațiilor de inginerie a traficului de către protocolul link-state de dirijare cu MPLS TE-activat;
• Un algoritm (de calcul al căii – path calculation [PCALC]) pentru a calcula cea mai bună cale de la LSR-ul cap la LSR-ul coada;
• Un protocol de semnalizare Protocolul de rezervare a resurselor – Resource Reservation Protocol [RSVP]) pentru a semnala tunelul TE în întreaga rețea;
• O modalitate de a transmite trafic pe tunelul TE.
Primul nume folosit de Cisco pentru MPLS TE a fost de dirijare cu resurse de rezervare (Routing with Resource Reservation), de asemenea, cunoscut ca RRR sau R3 (a se citi ca R cub).
Acest nume ne indică faptul că un motiv important pentru a avea MPLS TE este de a dirija traficul sau a 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 și sunt anunțate de protocolul link-state (OSPF sau IS-IS). În loc de a crea un nou protocol pentru a transporta această informație și de a le anunța la toate LSR-urile, OSPF și IS-IS au fost extinse pentru a transporta această informație. Când se configurează un tunel TE pe un LSR, acesta devine capul (headend LSR) din acel tunel TE sau TE-LSP. Apoi se specifică destinația LSR de pe tunelul TE și constrângerile la care trebuie să se supună. De exemplu, se poate să se specifice cerința de lățime de bandă pe tunel.
În interiorul IOS-ului Cisco, o bază de date este construită cu informații de inginerie a traficului pe care protocolul link-state le trimite. Acesta bază conține 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) modificați 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 pentru acel LSP particular pentru acel tunel TE. LSR-urile intermediare pot afla etichetele doar în cazul în care LSR-ul cap și LSR-urile intermediare semnalizează etichetele cu un protocol de semnalizare. În trecut, două protocoale de semnalizare au fost propuse: RSVP cu extensii pentru TE (RSVP-TE) și LDP bazat pe constrângeri (constraint-based LDP sau CR-LDP).
Mult mai folosit este RSVP-TE, în care extensii au fost făcute la RSVP pentru a permite acesteia să poarte etichetă MPLS de informare și de alte date specifice TE, cum ar fi traseul explicit sau traseul înregistrat. În esență, RSVP încearcă să semnalizeze tunelul TE de-a lungul căii, 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. [30]
Distribuția informațiilor de inginerie a traficului
Un protocol de dirijare link-state trebuie să inunde constrângerile de pe link-uri în rețea pentru toate rutere pe care se execută ingineria traficului. În acest capitol, 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.
3.2.1 Cerințe pentru 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 rutere î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 ruter la toate ruterele 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 tabela de rutare), de aceea, informațiile cu privire la căile alternative sunt pierdute.
Ruterul de la capul tunelului cu TE (headend) trebuie să dispună de toate informațiile de topologie pentru a vedea toate căile posibile, dar acesta trebuie să aibă, de asemenea, toate informațiile legate de constrângerile de pe link-urile pe care le are la dispoziție.
Protocolul de rutare de tip link-state trebuie să fie extins pentru a obține această resursă de informații suplimentare.
Resursele de inginerie a traficului de pe un link sunt:
șmetrica TE
șlățimea de bandă maximă
șlățimea de bandă maximă rezervabilă
șlățimea de bandă nerezervabilă
șgrup administrativ
Metrica TE este un parametru care se poate utiliza pentru a construi o topologie cu TE diferită de topologia IP. Ca atare, metrica TE de pe un link poate fi diferită de costul OSPF sau metrica IS-IS de pe link. Lățimea de bandă maximă este lățimea de bandă totală de pe un link. Lățimea de bandă maximă rezervabila este, evident, lățimea de bandă la dispoziția TE pe link; cea nerezervabila este data de lățimea totală minus lățimea deja rezervată.
Grupul administrativ este un câmp de 32 de biți. Operatorul de rețea pot stabili individual, fiecare bit din acest domeniu pe 32 de biți și poate avea un sens ales de el. De exemplu, un bit ar putea să însemne că link-ul este o legătură cu o viteză de 48kbps, sau un link care este intercontinental, sau un link care are o întârziere mai mică de 100 ms. Link-ul poate avea mai multe resurse asociate cu această, cu un maxim de 32. Aceste resurse sunt inundate în întreagă zonă, atunci când acestea se schimbă în valoare sau la intervale regulate.
3.3 Extensii OSPF pentru Ingineria Traficului
RFC 2370 descrie o extensie a protocolului OSPF prin care cele trei noi anunțuri link-stat (LSA-uri) sunt definite și sunt numite LSA-uri opace. Aceste trei noi LSA-uri dau OPSF-ului un mecanism generalizat de a extinde OSPF. Acestea pot duce informații pentru a fi utilizate de către OSPF sau direct de către orice aplicație. Aceste LSA-uri sunt exact ceea ce MPLS TE are nevoie pentru a pune în OSPF. OSPF poate apoi inunda această informație în întreagă rețea.
Trei tipuri de LSA-uri există, diferă doar în domeniul de aplicare a inundațiilor. LSĂ de tipul 9 aplicat numai pe link-local; de tip 10 are un domeniu de aplicare a inundațiilor care este de zonă largă, și opac 11 are un tip de inundații, domeniul de aplicare, care este autonom, la nivel de sistem. Asta înseamnă că, LSA-urile de tip 9 sunt trimise numai pe link, dar niciodată transmise dincolo; cele de tip 10 sunt oprite de către ruterul de la zona de frontieră (gateway), și de tip 11 sunt inundate în întreg domeniul OSPF, la fel ca și cele de tip 5.
Un bit nou, bitul O, a fost definit pentru a fi folosit în câmpul opțiuni al OSPF. Acest bit poate indica dacă este un ruter 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.
Fig. 3.3 Campul optiuni OSPF
Figura 3.4 arată formatul opac al LSA-ului. LSA-urile de tip 9, 10, sau 11, unde campul cu valoare normală a ID-ul a fost înlocuit cu Opaque Type and Opaque ID.
Fig. 3.4 Formatul LSĂ opac
LSA-ul TE de tip 10 opac poartă una sau mai multe Valori ale Tipului de Lungime ( Type Length Value – TLV). Un TLV permite OSPF să transporte date într-un mod flexibil. Figura de mai jos arată formatul TLV.
Fig. 3.5 Formatul TLV
Acest TLV transportă date specifice MPLS TE. O adresă TLV a ruterului și un link TLV există. Adresă TLV tine ID-ul ruterului in TE. Link-ul TLV exercită un set de sub-TLV-uri care descriu un singur link pentru MPLS TE. Tabelul următor 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.
3.3.1 Operarea și Dirijarea pe Bază de Constrângeri în MPLS-TE (Constraint-Based Routing – CBR)
Cea mai importantă cerință a TE este aceea a caracteristicilor, precum și a disponibilității resurselor, pe link-urile din rețea (în plus fată de lățimea de bandă care ar putea fi folosita pentru calculul costului) se propagă în întreaga rețea pentru a permite alegerea pe cât de eficient posibil a cailor LSP cu TE. În protocoalele de dirijare link-state calea preferata, încă predominant, ia în considerare lățimea de bandă pe link-ul dintre două rutere 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 rutere în rețea pentru a le face disponibile de ruterul headend în tunelul TE în timpul calcului LSP-ului (tunele dinamice). Mesajele link-state transporta informații cum ar fi listele cu ruterele de vecini, rețeaua de resurse, precum și alte informații relevante legate de disponibilitatea resurselor reale ce ar putea fi necesare mai târziu pentru a efectua un calcul SPF pe bază de constrângeri. OSPF și IS-IS au fost furnizate cu extensii pentru a permite utilizarea lor într-un mediu MPLS TE pentru a propaga informații legate de disponibilitatea resurselor.
3.4 Calcularea și stabilirea căii
3.4.1 Cum funcționează SPF
În mod normal în procesul de calcul SPF, un ruter 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 rutare link-state, fiecare ruter știe despre toate celelalte rutere din rețea și link-urile care conectează aceste rutere. In OSPF aceasta informație este codata in LSA(Link-State Advertisments); in IS-IS aceasta informație este LSP(Link-State Packets),pentru a nu se confunda cu Label-Switched Path le vom numi LSA.
Imediat după ce ruterul cunoaște toate celelalte rutere și link-uri, rulează algoritmul Dijkstra Shortest Path First pentru a determina cea mai scurta cale dintre ruterul care calculează și toate celelalte rutere din rețea.
Deoarece toate ruterele rulează același calcul pe aceleași date, toate ruterele au aceeași imagine despre rețea, și pachetele sunt consecvent rutate la fiecare hop.
Fig. 3.6 O topologie simpla pentru a demonstra algoritmul SPF
Acest exemplu (Figura 3.6) ne arată ce se întâmpla când ruterul A rulează SPF și își generează tabela să de rutare.
După ce fiecare ruter a anunțat (flooded) cu informațiile sale rețeaua, toate ruterele știu despre toate celelalte rutere și link-urile dintre ele. Baza de date link-state pe fiecare ruter arata ca in Tabelul 3.1.
Tab. 3.1 Potrivirea claselor de planificare
În calculul SPF, fiecare ruter menține doua liste:
– O listă a nodurilor care sunt cunoscute a fi pe calea cea mai scurtă spre destinație. Această listă este numită lista PATH.
– O listă cu următoarele hopuri (next hops) care ar putea sau nu ar putea să fie pe calea cea mai scurtă spre destinație. Aceasta listă se numește lista TENT sau TENTative.
Fiecare listă este o tabelă de tripleti {ruter,distanta,next-hop} din perspectiva ruterului care calculează.
Algoritmul care calculează calea cea mai scurtă pentru fiecare nod este simplă. Fiecare ruter urmează următorul algoritm:
Pune “self” in lista PATH cu distanta 0 și următorul hop(next-hop) el(“self”=root node)
Tabelul 3.2
Tab. 3.2 Lista PATH și TENTE pentru Ruterul A
Ia nodul abia pus in lista PATH, și îl numește nod PATH. Se uită în lista vecinilor
nodului respectiv. Adaugă fiecare vecin din aceasta lista in lista TENTE cu nodul următor (next-hop) nodul PATH, in afara de cazul in care vecinul este deja in lista TENTE sau lista PATH cu un cost mai mic. Daca nodul abia adăugat în lista TENTE deja exista in lista, dar cu un cost mai mare, înlocuiește nodul cu costul mai mare cu nodul curent.
In exemplul nostru, {B,5,B} și {C,10,C} sunt adăugate in lista TENTE ca in Tabelul 3.3.
Tab. 3.3 Listele PATH și TENTE pentru Ruterul A după pasul 2
Găsește vecinul în lista TENTE ce are costul cel mai mic, adaugă acel vecin în lista PATH și repeta pasul 2). Daca lista TENT este goală se oprește.
{B,5,B} este mutat in lista PATH, deoarece aceasta este calea cea mai scurta către 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 alta cale către B cu un cost mai mic decât cel de până acum. Tabelul 3.4 reflecta listele PATH și TENTE la acest pas.
Tab. 3.4 Listele PATH și TENTE pentru Ruter A după pasul 3
Se repetă pasul 2.
Vecinii ruterului B sunt examinați. Ruterul B are un link către C cu un cost de 3 și un link către 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 adaugat in lista TENTE; costul de la A la D via B este 13 și este următorul hop(next-hop) a lui B. Deoarece calea către C cu un 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.5 reflecta listele PATH și TENTE la acest punct.
Tab. 3.5 Listele PATH și TENTE pentru Ruterul A după pasul 4
Găsește calea din lista TENTE cu costul cel mai mic, adaugă calea în lista PATH și se
repeta pasul 2. Daca 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 in Tabelul 3.6
Tab. 3.6 Listele PATH și TENTE pentru Ruterul A după pasul 5
Ia calea abia adăugată in lista PATH, și se uită in lista vecinilor nodului. Pentru fiecare vecin din lista, adaugă calea către acel vecin in lista TENTE, doar daca vecinul respectiv deja exista in lista TENTE sau PATH cu un cost mai mic. Daca nodul abia adăugat in lista TENTE deja exista in lista dar cu un cost mai mare, este înlocuita calea cu cost mai mare cu calea curentă.
Sub aceasta regula, calea de la D către B (B->C->D) cu un cost de 12 înlocuiește calea către D prin B->D cu un cost de 13, cum se vede in Tabelul 3.7
Tabelul 3.7 Listele PATH și TENTE pentru Ruterul A după pasul 6
Găsește vecinul in lista TENTE cu costul cel mai mic, adaugă acest vecin în lista PATH
și repetă pasul 2. Daca lista TENTE este goală se oprește.
Calea către D este mutată în lista D, așa cum se vede in Tabelul 3.8.
Tabelul 3.8 Listele PATH și TENTE pentru Ruterul A după pasul 7: Lista TENTE este goala
Găsește vecinul în lista TENTE cu costul cel mai mic, adaugă acest vecin in 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 rutare a ruterelui A, care arată ca in Tabelul 3.9.
Tab. 3.9 Tabel de rutare a Ruterului A
Fig. 3.7 Rețeaua văzută de Ruterul A după rularea algoritmului SPF
În această topologie se observă două lucruri:
-traficul care trece link-ul B->D este traficul provenit de la ruterul A
-link-ul de la ruterul A la ruterul C nu este folosit deloc, din cauza costului prea mare(10).
3.4.2 Cum funcționează CSPF
Procesul care generează calea pe care o ia un tunel TE nu este foarte mult diferit de SPF. Sunt doua diferențe majore intre SPF, realizat de protocoalele de rutare și CSPF, realizat de MPLS TE.
Procesul de determinare a căii nu este proiectat să găsească cea mai bună rută către toate ruterele – numai către capătul tunelului. Acest lucru face algoritmul SPF oarecum diferit.
De asemenea acum este mai mult de o metrica pentru fiecare nod fata de singurul cost per link intre vecini:
-lărgimea de banda
-atributele link-ului
-distanta administrativa
Tripletului folosit de SPF i se mai adaugă lărgimea de banda, atributele link-ului și distanta administrativa.Un alt detaliu pentru CSPF este : nu se face împărțirea sarcinii (load sharing) deoarece se caută o singura cale către nodul capăt.
După cum am precizat, cu CSPF, vom folosi mai mult decât costul pe link pentru a identifica căile care pot fi utilizate pentru drumuri LSP cu ingineria traficului. Decizia este efectuată la ruterul headend după eliminarea tuturor link-urile care nu respectă un anumit criteriu, cum ar fi cerințele de lățime de bandă în plus fată de costul pe link. Rezultatul calculului CSPF la ruterul headend este un set ordonat de adrese IP cu mapări 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 care să corespundă criteriilor. În plus, utilizatorul poate configura static un tunel TE sau LSP pe ruterul 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 hopuri configurate de către utilizator pentru LSP. De notat că LSP-ul format este unidirecțional.
În caz de egalitate a constrângerilor, calea cu cea mai mare lățime de bandă are prioritate, urmat de cel mai mic număr de hopuri. Dacă tot este egal, CSPF alege o cale, la întâmplare.
Prin urmare, succesiunea de pași în crearea unui tunel MPLS TE în rețea este, după cum urmează:
Pasul 1. Calculul CSPF se face la ruterul headend pe baza constrângerilor definite în tunel și cerințelor. Acest calcul este efectuat de către IGP în continuare, fie OSPF sau IS-IS.
Pasul 2. După ce calea LSP este calculată pe baza procesului CSPF, rezultatul din procesul CSPF, care este un set de adrese IP mapate pentru fiecare adrese de la hop-uri următoare, este trecut la RSVP.
Pasul 3. RSVP acum efectuează cereri cu rezervări de resurse și confirmare pe LSP, cum sunt definite de procesul CSPF, pentru a determina dacă LSP îndeplinește cerințele specifice resurselor solicitate in definirea tunelului.
Pasul 4. După ce procesul de RSVP primește un mesaj de rezervare, acesta semnalează 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, informațiile legate de tunel nu se adaugă în tabela de rutare; cu toate acestea, ruterul poate fi configurat astfel încât interfața tunel să fie adăugată în tabelul de rutare.
Fig. 3.8 O topologie simpla ce demonstreaza algoritmul CSPF
În aceasta topologie, Figura 3.8, s-au luat numai patru proprietăți ale link-ului: {link, cost, next hop și lățimea de bandă disponibilă}. Ruterul A vrea să construiască un tunel TE către ruterul D cu o lățime de banda de 60 Mbps. Fiecare link își listează metrica și lățimea de banda disponibila.
Dacă nu am lua in calcul lățimea de banda , calea cea mai bună 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 scurta care are disponibili 60 Mbps.
Algoritmul CSPF urmează următorii pași:
Pune “self” in lista PATH cu o distanta de 0 și următorul hop(next-hop) el însuși. Setează
lățimea de banda la N/A. Rezultatul este arătat in Tabelul 3.10.
Tab. 3.10 Listele PATH și TENTE după pasul 1
Pune vecinul ruterului A in lista TENTE. Rezultatul este arătat in Tabelul 3.11.
Tab. 3.11 Listele PATH și TENTE pentru Ruterul A după pasul 2
Îl muta pe B din lista TENTE in lista PATH, și pune vecinii lui B in lista TENTE.
Rezultatul este arătat in Tabelul 3.12.
Tab. 3.12 Listele PATH și TENTE pentru Ruterul A după pasul 3
{C,8,B,50} nu este adăugat în lista TENTE deoarece nu îndeplinește cerința de a avea minimul de lățime de bandă.
Pune vecinii lui B in lista TENTE și îl ia pe C din lista TENTE și îl pune in lista PATH.
Rezultatul este arătat in Tabelul 3.13.
Tabelul 3.13 Listele PATH și TENTE pentru Ruterul 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 decât costul de a ajunge prin C.
Îl ia pe D din lista TENTE. In 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.14.
Tabelul 3.14 Listele PATH și TENTE pentru ruterul A după pasul 5
CSPF trebuie să tina urma tuturor nodurilor din cale, nu numai a următorului hop.
In cazul in care nodul care trebuie pus in lista TENTE exista deja și are același cost este nevoie să se facă o diferențiere între aceste cai.
Criterii de diferențiere a căilor in ordine (tiebreakers):
1 Se ia calea cu cea mai mare lărgime de banda minim disponibila.
2 Dacă mai există un obstacol, se ia calea cu numărul cel mai mic de hopuri(numărul de rutere din care este formata calea)
3 Dacă mai există un obstacol, se ia o cale random (aliator)
Aceste criterii sunt aplicate când un nod este adăugat în lista TENTE. În orice moment, un nod dat ar trebui să fie adăugat numai o dată în lista TENTE. Aceasta este diferența față de un IGP SPF, unde se poate să ai mai multe rute către un nod dat și se poate face împărțirea sarcinii (load share) între ele.
Fig. 3.9 O rețea simplă în care sunt necesare criterii de diferențiere pentru CSPF
În aceasta topologie sunt cinci cai posibile de la A la Z,de la P1 la P5.In Tabelul 3.15 sunt listate atributele cailor.
Tab. 3.15 Atributele celor cinci cai posibile de la RtrA la Rtr Z
Procesul deciziilor prin care RtrA trece pentru a alege o cale din acestea cinci:
-P1 nu este folosita deoarece costul căii este mai mare decât celelalte cai
-P2 nu este folosit deoarece lărgimea să de banda minima este 80 Mbps, valoare care este mai mica decât minimul lărgimii de banda pentru alte cai
-P3 nu este folosit deoarece are 5 hopuri(noduri),celelalte căi având 4 hopuri(noduri)
-RtrA alege ori P4 ori P5 din capul listei TENTE.
Alte lucruri care influențează CSPF:
-Lărgimea de banda(bandwidth) : o cale nu este considerată acceptabilă de a fi folosită pentru un tunel MPLS TE daca nu are lărgimea de banda ceruta.
-Atributele link-ului(link attributes): dacă biții 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ța administrativa(administrative weight): este difuzată de IGP când sunt anunțate (flooded) informații TE. Inițial, numai distanța administrativă este folosită pentru a calcula calea tunelului.
3.5 Protocolul de rezervare a resurselor -Resource Reservation Protocol (RSVP)
După ce o cale este calculată cu ajutorul CSPF, această cale trebuie să fie semnalata de-a lungul rețelei din doua motive:
-Pentru a stabili un lanț hop-by-hop de etichete care reprezintă calea
-Să consume orice resursa(lărgime de banda) consumabila de-a lungul căii respective
Această semnalare este îndeplinită folosind RSVP, împreuna cu extensiile RSVP pentru MPLS TE.
3.5.1 Bazele RSVP(RSVP Basics)
RSVP este un mecanism de semnalizare folosit pentru a rezerva resursele peste tot in rețea. Are tipul său de protocol (46), deși este posibil să încapsulezi RSVP in UDP. MPLS TE nu încapsulează niciodată RSVP in UDP.
RSVP nu este un protocol de rutare. Orice decizie de rutare este luata de IGP (inclusiv extensiile TE) și CSPF. Funcția RSVP-ului este de a semnala și menține rezervarea resurselor din retea. In MPLS TE RSVP rezervă lățimea de banda la nivelul planului de control (control-plane).
RSVP are trei funcții de bază:
-setarea căii și menținerea ei;
– ruperea căii (path teardown);
-semnalarea erorii.
RSVP este un protocol soft-state. Asta înseamnă ca are nevoie să împrospăteze periodic rezervările din rețea prin resemnalizarea lor. Acest lucru este diferit fata de un protocol hard-state a cărui semnalări sunt cerute o dată după care se presupune ca acea cerere este up până este explicit pusă down. [RFC3210]
În Tabelul 3.16 sunt listate nouă tipuri de mesaje diferite ce definesc RSVP.
Tab. 3.16 Tipul mesajelor RSVP
3.5.2 Semnalizarea RSVP-TE
RSVP rezervă o lățime de bandă de-a lungul unui drum de la o anumită sursă la destinație. Mesajele RSVP sunt trimise de către ruterul cap (headend) într-o rețea pentru a identifica disponibilitatea resurselor pe drum. Ruterul cap sau headend este întotdeauna sursă tunelului MPLS TE și tailend ruter sau ruterul coadă, este un ruter 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 solicitate și stochează aceste informații.
O alta funcție 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 Explicit Route Object(ERO) ce specifica detaliile despre calea pe care mesajul RSVP PATH trebuie să o urmeze pentru a semnaliza tunelul cu TE. Seria de hopuri sau calea este rezultatul calcului făcut pe ruterul de la cap. La fiecare hop, acest mesaj de cale rezervă temporar lățimea de bandă și face o cerere de etichetă. În cele din urmă, mesajul de cale ajunge la coada, care returnează un mesaj RESV către cap. Acest mesaj RESV apoi returnează o etichetă pe care planul de date MPLS o poate utiliza pentru a transmite pachete pe acest tunel MPLS cu TE de-a lungul LSP. De asemenea, mesajul RESV spune LSR-urilor intermediare să rezerve resursele pe link-urile care se utilizează pe acest tunel cu TE.
RSVP RESERVATION – este creat de ruterul tailend (coada) în domeniul MPLS TE și utilizat pentru a confirma rezervarea, mesajul de cale (PATH) care a fost trimis mai devreme. Practic este un mesaj de răspuns la mesajul PATH. Mesajul RSVP de REZERVARE îndeplinește funcția de atribuire a etichetei pentru un anumit tunel TE. Daca mesajul de cale este transmis în aval, mesajele de rezervare sunt generate de tailend sau egress Edge LSR apoi propagate în amonte. Acest proces se repetă la fiecare hop in amonte pe un tunel TE și mesajele sunt propagate în amonte până la headend. [RFC3210]
Fig. 3.10 Mesajele RSVP Path și Reservation
Mesajele de eroare RSVP: PATHERR sau RESVERR – în caz de lipsă a resurselor solicitate, ruterul cu RSVP generează mesaje de eroare și le trimite la un ruter de la care cererea a fost primită.
Fig. 3.11 Mesajele de eroare RSVP
Mesaje de încheiere (tear down) – RSVP creează două tipuri de mesaje de încheiere, și anume, mesaj de încheiere de cale și mesaj de încheiere de rezervare. Odată ce mesajele de încheiere au fost trimise, se permite refolosirea resurselor de pe ruter 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 încheiere de rezervare la headend.
3.5.3 Operațiunile RSVP în MPLS TE
Așa cum am menționat mai devreme, rezultatul unei CSPF sau calcul CBR pe ruterul headend este o listă ordonata de adrese IP care identifică următorii pași de-a lungul drumului într-un tunel cu TE sau LSP. Această listă de rutere este calculată și este cunoscută doar de ruterul headend care este sursă de tunel. Alte rutere în domeniu nu efectuează un calcul CBR. Ruterul headend oferă informații despre rutere din calea tunelului cu TE prin semnalizare RSVP pentru a solicita și a confirma disponibilitatea resurselor pentru tunel. RSVP cu extensii pentru TE rezervă resurse corespunzătoare cu privire la fiecare LSR în calea definita de headend și atribuie etichete de Mapare a tunelului cu TE.
Extensiile RSVP pentru a permite semnalizarea într-un mediu în care se pune in aplicare MPLS TE sunt definite și prezentate in tabelul de mai jos:
Tab. 3.17
Pașii urmați de mesajele de tip cale (PATH) și de rezervare (RESV) sunt următorii:
Pasul 1. Valorile LABEL_REQUEST, EXPLICIT_ROUTE, RECORD_ROUTE SESSION și SESSION_ATTRIBUTE sunt aplicate de ruterul 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 următorul hop primește acest mesaj PATH, ruterul 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, ruterul nu este direct conectat la următorul hop în calea tunelului LSP. Prin urmare, ruterul va efectua un calcul de SPF constrâns (CSPF) pentru a stabili următorul/următoarele hop/hopuri în tunel.
În cazul în care bitul L este unset, ruterul local știe că aceasta este direct legat de următorul hop în calea LSP al tunelului. Se îndepărtează apoi toate intrările în EXPLICIT_ROUTE de mapare pentru ruterul local și înaintează mesajul PATH la următorul hop, cum sunt definit în obiectul EXPLICIT_ROUTE. În plus, acest ruter va adăuga interfața de ieșire spre următorul hop în câmpul RECORD_ROUTE.
Pasul 3. Procesul se repetă la următoarele hopuri.
Pasul 4. Când mesajul RSVP PATH este primit de ruterul tailend, el determină crearea de un mesaj de rezervare. Conceptul cheie de remarcat este că etichetarea începe de la ruterul tailend (de la coadă). Prin urmare, atunci când acesta generează un mesaj de rezervare, ruterul atribuie o etichetă la tunelul LSP. Mesajul de rezervare are acum obiectul RECORD_ROUTE care să indice ce interfață de ieșire de pe ruter tailend duce spre headend ruter. 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 ruterul cap primește mesajul de rezervare, acesta 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ă.
3.5.4 Setarea căii și menținerea ei
3.5.4.1 Setarea căii
După ce începutul tunelului(tunnel headent) termina calculul CSPF pentru un tunel particular, are nevoie să semnaleze aceasta cerere in rețea. Capătul tunelului (headend) face acest lucru prin trimiterea mesajelor Path următorului nod împreuna cu calculul căii spre destinație.
Ruterul care trimite mesajul Path se numește ruter amonte și ruterul care primește mesajul se numește ruter aval. Ruterul amonte se mai numește uneori hopul anterior(phop).
După ce ruterul din aval primește mesajul Path , face următoarele lucruri: verifică formatul mesajului pentru a se asigura ca totul este in ordine, după care verifica cantitatea de lărgime de banda ceruta de mesajul Path primit. Acest proces se numește controlul admisiei.
Daca controlul admisiei este reușit și mesajului Path i se permite să rezerve lărgimea de banda pe care o dorește, ruterul din aval creează 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- coada tunelului MPLS TE.
Capătul tunelului realizează controlul admisiei pentru mesajul Path, ca orice alt ruter din aval. Când capătul tunelului realizează ca este destinația mesajului Path, va răspunde cu un mesaj Resv. Mesajul Resv nu conține numai confirmarea(acknowledgment) ca rezervarea s-a realizat pe tot drumul spre capătul tunelului, ci conține și eticheta care intra(incoming) pe care ruterul din amonte ar trebui să o folosească in trimiterea pachetelor pe TE LSP către capăt. Figura 3.12 arata schimbul de mesaje RSVP: path și resv in timpul stabilirii LSP.
Fig. 3.12 Mesajul RSVP: PATH și RESV in timpul setarii căii LSP
Presupunând ca 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, verifică dacă mesajul are sintaxa corectă, verifica cu TE Link Manager pentru a se asigură că lărgimea de banda ceruta de R1 chiar este disponibilă. Daca ceva este greșit R2 trimite un mesaj de eroare înapoi la R1. Presupunând ca 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 verificări
6. R7, fiind capatul tunelului, trimite un mesaj Resv lui R6. Acest mesaj Resv indica eticheta pe care R7 dorește să o vada in pachetul pe acest tunel; deoarece R7 este capătul, trimite și implicit-null
7. R6 trimite un mesaj Resv lui R5 și indica ca vrea să vadă că eticheta de intrare 42, pentru acest tunel. Acest lucru înseamnă ca atunci când R6 primește eticheta 42, scoate aceasta eticheta(din cauza implicit-null) și trimite pachetul către R7.
8. R5 trimite un mesaj Resv către R3, semnalând eticheta 10921. Când R5 primește un pachet cu eticheta 10921, schimba aceasta 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.
În acest moment tunelul către R7 este up, și se cunosc care sunt etichetele de ieșire.
3.5.4.2 Menținerea căii
La fiecare 30 secunde, capătul tunelului (headend) trimite un mesaj Path per-tunel la vecinii din aval. Dacă un ruter trimite un mesaj Path și nu primește la timp mesajul resv, considera ca rezervarea nu mai este și trimite la ruterul din amonte un mesaj ce indica lipsă rezervării.
Mesajele Path și Resv sunt ambele independente și asincrone de la un vecin la altul.
Ruperea căii (path teardown)
Dacă un nod (în general capătul tunelului) decide ca o rezervare nu mai este necesară în rețea, trimite un masaj PathTear pe aceeași cale urmată de mesajele Path și se primesc mesajele ResvTear pe aceeași cale ca mesajele Resv.
Mesajele PathTear sunt în general văzute când capătul tunelului (headend) decide că nu mai dorește o rezervare in rețea (ex: când un tunel este down). Mesajele ResvTear sunt trimise in 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 de asemenea trimise in răspuns la o eroare în rețea.
Semnalarea erorii:
Ocazional pot exista erori in semnalarea RSVP. Aceste erori sunt semnalate prin mesajele PathErr sau ResvErr. O eroare detectată in mesajul Path i se răspunde cu mesajul PathErr, și o eroare detectata in mesajul Resv i se răspunde cu mesajul ResvErr. Mesajele de eroare sunt transmise către ruterul 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 din aval de nodul din amonte.
3.5.5 Pachetele 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ă.
RSVP Common Header
Fig.3.13 Formatul antetului RSVP
Tab. 3.18 explică câmpurile din header-ul obisnuit RSVP.
Formatul claselor de obiecte RSVP(RSVP Object Class Formats)
Toate obiectele RSVP au același format de baza, cum este ilustrat in Figura 3.14
Figura 3.14 Formatul obiectului RSVP
În Tab. 3.19 sunt descrise câmpurile din formatul obiectului de baza RSVP.
Tab. 3.19 Formatul obiectului RSVP
Sunt definite 23 de clase obiect(object classes) diferite. Nu toate sunt folosite în semnalizările RSVP pentru MPLS TE; acestea sunt listate in Table 3.20.
Tab. 3.20 Clasele obiectului RSVP
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.21 sunt listate clasele și C-Type folosite in implementarea Cisco a RSVP-TE.
Tab. 3.21 Obiectul RSVP C-Types
3.5.6 Operațiile RSVP
3.5.6.1 Ce este Make-Before-Break?
Reprezintă un mecanism RSVP-TE care permite schimbarea unor caracteristici a tunelului TE(numele, lărgimea de banda și calea pe care o ia un tunel) fără rezervarea de doua ori a lărgimii de banda și efectiv fără pierderi de date.
RSVP are o facilitate numita Shared Explicit(SE) ce este un stil de a rezerva ce permite un LSP existent să împartă lărgimea de banda cu el însuși astfel încât să nu se mai întâmple rezervarea de doua ori.
Rezervarea SE are doua componente:
-cererea stilului de rezervare SE de la rețea
-capabilitatea de a identifica ca o anumita rezervare este aceeași cu o rezervare deja existentă, astfel încât lărgimea de bandă să fie împărțita.
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 ale aceleiași rezervări.
Sender Address este RID-ul capătului tunelului. Endpoint Address este RID-ul cozii tunelului. Extended Tunnel ID este ori numai 0 ori adresă IP a ruterului. Tunnel ID este numărul interfeței tunelului din capăt. LSP ID este o “instanța de numărare”; de cate ori un tunel își schimbă cerințele de lărgime de banda sau calea pe care o ia, LSP ID se incrementează.
Fig. 3.15 Nevoia de Make-Before-Break
Presupunând că in Figura 3.15 R1 : RID=1.1.1.1 și R5: RID=5.5.5.5, Tabelul 3.22 arata ce trimite R1 și ce face R4 cu informația primita.
Tab. 3.22 Pașii in Make-Before-Break
În acest fel, atat Res1 cat ș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 in scurt timp nu va mai fi activ și nu va mai încerca nici o data să concureze cu Res2 pentru lărgime de banda.
3.5.6.2 Cum lucrează mecanismul de actualizare (refresh)?
RSVP este un protocol soft-state: rezervările sunt actualizate periodic. Rezervările sunt trimise folosind mesajele Path și Resv. Nu există diferență între mesajele Path și Resv folosite pentru setarea LSP inițială și cele folosite pentru actualizarea căii; formatul pachetului este la fel. Felul in care un ruter spune o noua cale setata după actualizare este pentru a vedea daca exista deja o rezervare cu un grup de cinci(five-tuple) care se potrivește cu mesajele Path și Resv in cauza.
Mecanismul de actualizare cuprinde doua puncte majore:
-timpii de actualizare (refresh) cu jitter
-mesajele Path și Resv sunt trimise independent intre doua rutere.
Timpii de actualizare cu jitter.
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 data are mesajul Path (sau Resv)trimis pentru actualizare la fiecare 15-45 de secunde.
Ideea generala este ca un vecin trimite intervalul sau de actualizare(R) la vecinii săi in obiectul TIME_VALUE din mesajele sale Path și Resv. Fiecare ruter de asemenea știe câte mesaje este dispus să le piardă înainte să declare rezervarea inactiva.(K).
Vecinul calculează un holdtime L pentru mesaj cu formula:
L>=(K+0.5)*1.5*R
În implementarea IOS curenta R=30 secunde, K=3: L este cel puțin 157.5 secunde. Aceasta înseamnă ca un ruter poate aștepta până in 157.5 secunde fără nici o reactualizare înainte de a rupe o legătura cu un vecin. Este suficient timp ca un ruter să aibă trei intervale consecutive cu toate pachetele pierdute in timpul de actualizare (45 secunde) înainte de a expira timpul(time out).
Fig. 3.16 Mesajele Path și Resv sunt trimise independent
Acest lucru este perfect normal. Mesajele Path și Resv nu sunt trimise in maniera ping/ACK ci sunt trimise independent unul față de celălalt.
Când, unde, și cui ii sunt trimise mesajele?
Exista nouă tipuri de mesaje RSVP (cum am menționat și mai devreme). Tabelul 3.23 rezumă ce mesaje sunt trimise , când și unde.
Tabelul are cinci coloane:
-Mesajul –tipul mesajului.
-Funcția –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, in direcția opusă de sfârșitul tunelului”.
-Adresă destinație –Destinația adresei IP a pachetului.
-Alerta ruterului(Ruter Alert?) – unele mesaje RSVP cară opțiunea Ruter Alert, altele nu.
Tab. 3.23 Tipul mesajelor RSVP
Strict vs Slab sub-obiect ERO.
In obiectul EXPLICIT_ROUTE L bit poate fi setat pe un hop in ERO pentru a indica o ruta slabă.
ERO este codata ca o serie de sub-obiecte numite noduri abstracte(abstract nodes) . Un nod abstract poate fi o adresă IPv4, adresă IPv6 sau un sistem autonom. Fiecare sub-obiect poate fi ori un hop precis, ori un hop slab. Când un ruter procesează un hop precis, adresă IPv4 din sub-obiect trebuie să fie direct conectata de ruterul care procesează, altfel va fi o eroare in ERO.
Daca un ruter procesează un sub-obiect ERO cu un hop slab, ruterul respectiv este responsabil să genereze un set de hopuri precise pentru ca mesajul Path să ajungă la destinație și să înlocuiască acel hop slab cu noul set generat de hopuri precise.
Implicit vs Explicit Null
Sfârșitul tunelului poate semnala doua tipuri de etichete- implicit null și explicit null.
Explicit null este semnalat folosind valoarea 0 in câmpul Label(eticheta) din obiectul LABEL.
Implicit null este semnalat folosind valoarea 3 in câmpul Label(eticheta) din obiectul LABEL.
Initial(default), nodul din sfârșitul (coada) tunelului semnalizează explicit null in mesajele Resv:
LABEL type 1 length 8 : 00000000
Dacă privim la penultimul hop, se observă că valoarea explicit null este interpretată ca implicit null, atât de hopul de la sfârșitul tunelului, cât și de penultimul hop.
3.6 Administrarea TE in MPLS
3.6.1 Protecție și restaurare.
Din perspectiva unui ruter sunt doua tipuri de eșec : eșecul link-ului și eșecul nodului. Abilitatea MPLS TE este de a călăuzi traficul departe de IGP obținând ajutor pentru calea cea mai scurta și micșorând pierderea de pachete in asociere cu un eșec a unui link sau nod din rețea.
Aceasta abilitate a MPLS TE este cunoscuta ca FRR (Fast 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ță (in cazul unui eșec in rețea):
-În rețelele mari, unui IGP îi poate lua câteva secunde să conveargă; până când întreaga rețea converge, exista pierderi de pachete.
-Un eșec al link-ului poate conduce la o congestie în unele parți a rețelei în timp ce în alte parți a rețelei nu este congestie.
-Configurând un IGP să conveargă rapid poate duce la o sensibilitate prea mare pentru o pierdere mica de pachete, cauzând convergenta IGP fără nici un motiv.
Presupunând ca 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. Aceasta problema este accentuata in MPLS TE: daca un link care face parte dintr-un LDP care devine down, LSP-ul devine down. După ce capătul tunelului TE recalculează o noua cale, SPF trebuie rulat din nou pentru rutarea prefixelor peste tunel cand este stabilita rutarea automata, aceasta făcând timpul de convergenta mai rău decât in rețelele IP tradiționale. Astfel s-a dezvoltat mecanismul FRR pentru a dobândi cât mai puține pierderi de pachete.
Ce este protecția?
Protecția in contextul de FRR (fast restoration), este procedura prin care, aplicată resurselor selectate, asigură pierdere minimă a traficului în urma 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 ca resursele back-up sunt pre-stabilite și nu sunt semnalate in urma unui esec.[31]
Tipuri de protecție
Protecția poate fi împărțita în :
-protecția căii
-protecție locală:
-protecția linkului
-protecția nodului
Protecția căii:
Protecția căii este esențiala în stabilirea unui LSP adițional in paralel cu LSP-ul existent; LSP-ul adițional este utilizat numai in cazul unui eșec. Acest LSP se mai numește backup, secondary sau standby LSP.
LSP backup este construit pe lângă calea existenta cat mai diferit posibil. Ambele LSP-uri primary și backup sunt configurate pe capătul tunelului TE.
Aceasta metoda, protecția căii, nu este scalabilă: pentru orice LSP ce se dorește protejat se construiește un alt LSP.
Fig. 3.17 Protecția căii
Protecție locală:
Protecția locala este un termen folosit când tunelul backup(tunelul de protecție) este construit să acopere numai un segment a LSP-ului primar. Protectia locala ca și protecția căii, cere ca LSP backup să fie pre-semnalizat. În protecția locală, LSP backup este rutat in 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 in LSP backup.
Protecția locala are câteva avantaje in comparație cu protecția căii: o recuperare asupra eșecului mai rapida,1:N scalabilitate, consumă mai puțin din starea rețelei.
Fig. 3.18 Elementele protectiei locale
Tab. 3.24 Terminologia folosita in protectia locala
“tunel backup”=”tunel de protectie”=”tunel FRR”
Protecția link-ului:
Protecția link-ului poate fi divizata in patru secțiuni :
-configurația înaintea eșecului (prefailure)
-se configurează pe capătul tunelului TE pe interfața tunelului care se dorește protejat
-pe PLR: activând FRR pe PLR implica două lucruri:
-crearea unui tunel backup pe Nhop
-configurarea link-ului protejat să folosească tunelul backup după eșec
Fig. 3.19 Protecția Link-ului
-detecția eșecului
Mecanisme adăugate la detecția acestor eșecuri:
-mecanismul de detecție a eșecului specifice unui nivel fizic particular(SONET)
-pentru link-urile punct-la-punct, PPP sau HDLC keepalives
-extensiile RSVP hello
Fig.3.20 Detecția eșecului folosind RSVP Hellos
Detecția bazata pe RSVP hello este considerată suficientă pentru detecția eșecului în protecția locala, și convergenta este mai rapida decât in IP sau MPLS TE fara FRR.
-restabilirea conectivității
Imediat ce este detectat un eșec, PLR este responsabil pentru comutarea traficului pe tunelul backup. Procesarea interna realizata pe PLR implica următoarele :
-asigurarea ca backup-ul LSP pre-semnalizat este stabilit. Aceasta include noua eticheta prevăzută pentru noul vecin din aval.
-noua informație de adiacenta(încapsularea de nivel 2) este calculata pe baza interfeței fizice de ieșire a tunelului backup.
-semnalizarea după eșec (post – failure)
Semnalizarea RSVP care se întâmpla după ce protecția FRR a avut loc se poate împarți in următoarele:
-semnalizarea în amonte
Fig.3.21 PathErr fără protecție locală
Când capătul tunelului TE unui LSP primește eroarea: nici o ruta nu este disponibila către destinație, aduce interfața tunelului down și apoi încearcă să găsească o nouă cale pentru LSP. Capătul tunelului TE ignora faptul ca protecția locală poate fi disponibilă in jurul link-ului căzut.
Ca 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 sa-i comunice lui 7200a următoarele: link-ul din aval de-a lungul căii LSP este down, rerutez traficul temporar. Calea folosita către destinație nu mai este cea optima, calculeaza(copute) o cale alternativa, daca este una disponibila. Lucru cunoscut ca LSR 12008a triggering reoptimization.[31]
Pentru semnalizarea informației nondestructive se folosește PathErr cu ERROR_SPEC continand codul de eroare 25, “Notification” și un subcod 3, “Tunnel locally repaired”.
Capatul tunelului TE care primește notificarea 25/3 încearcă să calculeze și să semnalizeze o noua cale pentru acel tunel. După ce primește mesajul de rezervare(RESV) pentru aceasta cale noua, eticheta pentru calea veche este înlocuita cu eticheta pentru calea noua. Numai după aceea LSP-ul vechi devine down. Aceasta realizează make-before-break și ajuta la minimizarea pierderii de pachete.
Fig. 3.22 PathErr cu protectie locala
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 in corpul mesajului Path. Tunelele LSP sunt identificate de o combinație a obiectelor SESSION și SENDER_TEMPLATE in mesajele Path și Resv. Obiectul SENDER_TEMPLATE este modificat de PLR pentru ca expeditorul adresei IP va conține acum adresă IP a PLR-ului și nu cea a capătului tunelului TE. În acest fel sfârșitul tunelului va observa ca 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țială, menținută de către sfârșitul tunelului pentru aceasta sesiune, devine down in cele din urma datorita timeout-ului;dar mesajul Path modificat de către PLR este suficient de eficient pentru a menține rezervarea lărgimii de banda atât cât este necesar. [31]
-notificarea IGP
În absenta FRR, daca capătul tunelului TE principal primește un link-down LSĂ pentru un link care a făcut parte din LSP-ul principal, capătul tunelului TE rupe tunelul principal. După aceasta, capătul tunelului TE poate, daca este configurat corect, să încerce să reruteze calea LSP.
Dacă tunelul principal este configurat pentru FRR, link-down LSĂ nu are nici un efect, capătul tunelului TE rupe un LSP protejat numai pe baza mesajelor de eroare RSVP și le ignora mesajele IGP care raportează un link down de-a lungul căii LSP. Asta înseamnă ca un link down nu este in mod necesar un LSP căzut deoarece calea LSP poate fi protejata.
-semnalizarea in aval
Figura 3.23 PathTear in absenta FRR
Când link-ul dintre 12008a și 12008c devine down(cand nici o protectie locala nu este stabilita), 12008c trimite un mesaj PatnTear către 7200c.
Dacă calea LSP era protejata de FRR, acest tip de mesaj ar fi avut un efect advers. Ar fi rezultat ca LSP să devina down, chiar daca LSP ar fi fost protejat local de PLR. Pentru a preveni aceasta, mesajul PathTear trebuie suprimat pentru LSP-ul primar care are flag-ul activat: “Loop Protection Desired”
Cum ruterul de la sfarsitul tunelului, 7200c nu stie daca tunelul protejat a esuat, in afara de cazul in care se intampla unul din urmatoarele lucruri :
-primește 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 tine sesiunea valabila pentru o anumita perioada de timp.
Dacă ruterul de la sfârșitul tunelului primește un update IGP despre eșecul unui link, nu se ia nicio măsura din perspectiva MPLS TE.
Dacă semnalizarea RSVP este declarata expirata, calea LSP este declarata inactiva, și un mesaj ResvTear este trimis către capatul tunelului TE. Aceasta inseamna ca , separat de prevenirea PathTear să fie trimis de MP 12008c, trebuie cumva să se asigure ca sfarsitul tunelului continua să primeasca mesaje de actualizare RSVP chiar daca unul din link-urile care alcătuia LSP-ul principal este down. Acest lucru este realizat asigurându-ne ca MP(12008c) continua să primească mesajele Path pentru LSP-ul primar pe tunelul backup.
Cap.4. Calitatea serviciilor in rețele MPLS
4.1 Introducere
QoS și MPLS sunt pe un anumit nivel politic similare. Totuși pe un nivel tehnic, QoS și MPLS sunt foarte diferite.
Prin QoS se înțelege caracteristicile de performanta a rețelei, și cuprinde doua parti:
-găsirea unei căi prin rețea care poate oferi serviciul
-obligarea îndeplinirii serviciului
Din punct de vedere al suportului pentru calitatea serviciilor (QoS), telul MPLS a fost să ofere ceea ce oferă IP-ul, adică Servicii Diferentiate (Diffserv). Când au apărut primele drafturi despre MPLS, au fost rezervați 3 biți pentru a transporta informații despre clasele de servicii. În final IETF a botezat acești biți ca fiind Experimentali, deși majoritatea constructorilor îi folosesc ca pe biții Precedenta din IP. Biții EXP sunt analogi (și cel mai adesea o copie) a biților Precedenta din IP. Arhitectura MPLS si-a dorit să se integreze bine cu protocolul IP și să fie cât mai independenta de protocolul de nivel 2. Astfel s-a ales să se ofere suport pentru Diffserv, în detrimentul suportului QoS oferit de ATM. Aceasta decizie a dus la o simplificare majora a implementarii MPLS, obtinând performante care sunt competitive deși sunt inferioare celor oferite de ATM.
Calitatea serviciilor înseamnă diverse lucruri pentru diverse persoane. La nivelul retea, QoS e compus din doua 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 cai prin rețea poate fi o acțiune de genul alegerii căii cu cost minim furnizate de IGP. Respectarea restricțiilor impuse se poate rezolva prin dimensionarea rețelei cu atât de multa banda încât să se elimine problema. Aceasta abordare mai este numita și “cantitatea serviciilor”, dar la baza este o soluție temporara pentru a asigura calitatea serviciilor.
Totuși, lucrurile pot fi rezolvate și altfel. O cale disponibila prin retea poate fi construita printr-un LSP TE, similar cu un ATM PVC, fara a tine cont de metrica protocolului de rutare. Respectarea restrictiilor impuse se poate face folosind mecanismele Diffserv, cum ar fi policing, marcare, repartizare în cozi și aruncare. MPLS este doar o unealta care poate fi folosita împreuna cu mecanismele Diffserv pentru a oferi calitatea serviciilor.
Quality of Service sau QoS reprezintă pe scurt prioritizarea traficului in 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. Astfel 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 imposibilitatea de folosire a tehnologiei respective. Există 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, Silver sau Bronze), precum și avantajul unor scheme de preț diferențiate și a unei asistente adaptate clientului. QoS oferă posibilitatea rețelei să aloce resurse pentru aplicațiile esențiale anumitor obiective sau pentru cele puternic dependente 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 previzibila, implementarea de politici și livrarea de noi servicii. Avantajele inerente de cost și viteza în administrarea și instalarea 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 ca implementarea să fie mult mai simpla. Exista doua metode de a indica clasă de servicii în tehnologia MPLS:
• Prima metoda 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 înseamna ca se pot defini până la 2³ = 8 clase de servicii diferite.
• A doua metoda este utilizarea de etichete diferite pentru clase de servicii diferite.
4.2 Modelele utilizate pentru implementarea QoS
Pentru utilizarea eficienta a tuturor 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 doua aspecte foarte importante:
• Ce tipuri de aplicații se folosesc în rețea.
• Care tehnici de QoS ar putea să îmbunătățească performantele 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 doua modele: Modelul Serviciilor Integrate (Integrated Services Model) și Modelul Serviciilor Diferentiate (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 medii, î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 care 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 vazut ca o tehnologie scalabila,
care nu împovareaza nodurile din centrul rețelei, obligându-le să faca multe prelucrari.
El foloseste clasificarea pachetelor pe marginea domeniului și un sistem de cozi cu prioritati în centrul rețelei.
4.2.1 Modelul Serviciilor Integrate
Modelul Serviciilor Integrate consta în faptul ca serviciile QoS sunt cerute în mod explicit de către aplicatia care le dorește, prin transmiterea prin retea a unei semnalizari adecvate. Semnalizarea cererilor de servicii QoS se realizeaza prin intermediul protocolului RSVP de rezervare a resurselor (Resource Reservation Protocol). Acest model are dezavantajul ca da nastere unui volum semnificativ de trafic de control, care duce la utilizarea ineficienta a benzii.
Se foloseste o semnalizare capat la capat între entitatiile comunicante prin care se cere rezervarea resurselor necesare în nodurile din retea. Pentru a face acest lucru s-a folosit traditional protocolul RSVP pentru a transporta semnalizarile și pentru a instala starile de rezervare în noduri. Principalele dezavantaje ale RSVP sunt necesitatea acestuia de a rula capat la capat (astfel trecând prin rețele care pot să nu suporte rezervarea de resurse) și nevoia de a folosi semnalizari per flux între doua entitati. Al doilea dezavantaj a avut un rol important în determinarea scalabilitatii soluției, deoarece într-o retea mare pot exista zeci sau sute de mii de stari într-un nod, iar traficul periodic de menținere a rezervarii poate ocupa o parte importanta din capacitatea linkului.
MPLS poate folosi RSVP pentru distribuția de etichete, folosind anumite extensii ale acestuia. Diferența fata de primul caz consta în rularea RSVP doar în rețeaua core, având nodurile de granița ca și capete. Acest lucru reduce mult numărul de entități comunicante, crescând scalabilitatea soluției. Al doilea avantaj consta în faptul ca rezervarea se face acum pe clase de echivalenta, și nu pe fluxuri individuale, reducând mai mult numărul de semnalizări și stări ce trebuie folosite. În funcție de cât de fine sunt clasele de echivalenta 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 rezerva în momentul respectiv. Nodul destinație aloca eticheta, dar face și cererea de rezervare a resurselor. Calea este menținută atâta timp cât se primesc periodic mesaje de tipul PATH.
Daca 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 noua rezervare în timp ce este folosita. Totuși, daca din diverse motive, rezervarea nu se poate face, calea va fi stearsă și traficul de date va fi întrerupt. Pentru a remedia aceasta problema posibila, mai exista un mod în care se pot cere resurse suplimentare. Calea inițială este menținută, dar în același timp este realizata alta cale cu anumiți parametrii de trafic doriți. În momentul în care calea secundara este gata, traficul este dirijat prin ea și calea originală este ștearsă. În acest caz, daca calea secundara nu poate fi construita, calea principala rămâne în folosința și nu apar întreruperi în trafic.
RSVP-TE nu este singurul protocol capabil să facă alocări de banda. CR-LDP permite crearea de cai cu comutație a etichetelor care să aibă o anumita banda garantata. De asemenea, parametrii acestor căi pot fi modificați pe timpul funcționarii căii, 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.
Bibliografie
1. M. Aissaoui et al. ATM/MPLS Mediation : A Basic Interworking Function
2. Grenville Armitage : MPLS: The Magic Behind the Myths
3. Braden, Ed., et. Al., Resource Reservation Protocol (RSVP)
4. Cuchiara, J Sjostrand , H Luciani , J.V., Definitions of Managed Objects for the Multiprotocol Label Switching , Label Distribution Protocol
5. Davie, Bruce et al , Mpls using LDP and ATM VC switching
6. Willibald Doeringer, Giinter Karjoth, Mehdi Nassehi, Routing on longest matching prefixes
7. Hideaki Takagi, Queueing A Fondation of Performance Evaluation
8. George Swallow , MPLS Advantage for trafiic Engineering
9. ITU Telecomunication Standardization Sector, OAM and Survivability Functionality for MPLS Networks
10 . Request for Comments 3031 , Multiprotocol Label Switching Arhitecture
11. Request for Comments 2684 , Multiprotocol Encapsulation over ATM Adaptation Layer 5
12 . Request for Comments 2917, A Core MPLS IP VPN Arhitecture
13. Request for Comments 3035, MPLS using LDP and ATM VC Switching
14. Request for Comments 3063, MPLS Loop Prevention Mechanism
15 . Request for Comments 1932 , IP over ATM
16. Site-ul Academiei Cisco http://cisco.netacad.net
17. Site-ul companiei Cisco www.cisco.com
18. Site-ul companiei Juniper www.juniper.net
19. Site-ul www.wikipedia.org
20. [RFC3031] E. Rosen, A. Viswanathan, R. Callon – Multiprotocol Label Switching Architecture ,2001 http://rfc.net/rfc3031.html
21. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette – LDP Specification, 2001 http://rfc.net/rfc3036.html
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Proiect cercetare științifică [309891] (ID: 309891)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.