Ingineria Traficului Bazat pe Procolul Multiprotocol Label Switching

Cuprins

Acronime

AF =Assured Forwarding

ATM =Asynchronous Transfer Mode

BA =Behavior Aggregate

BGP =Border Gateway Protocol

BS =Bottom Stack (Baza Stivei)

BR =Border Router (Rutere de Graniță)

CR-LDP =Constraint Routing –Label Distribution Protocol

CR =Core Router

DiffServ =Differentiated Services (Servicii Diferențiate)

DLCI = Data Link Connection Identifier

DSCP =DiffServ Code Point

EF =Expedited Forwarding PHB

E-LSP = EXP-Inferred-PSC LSP

ER =Edge Router

EXP =Experimental Field

FEC =Forwarding Equivalence Class (Clasă de Îndrumare)

FR =Frame Relay

FTN =FEC To NHLFE Table

IETF = Internet Engineering Task Force

ILM =Incomig Label Map

IS-IS =Intermediate System-Intermediate System

IP =Internet Protocol

IntServ =Integrated Services (Servicii Integrate)

JPEG =Joint Photographic Experts Group

LER =Label Edge Router

LDP =Label Distribution Protocol (Protocol de distribuire a Etichetelor)

LIFO =Last In First Out (Ultimul Intrat, Primul Ieșit)

L-LSP = Label-only-Inferred-PSC LSP

LSP =Label Switched Path

LSR =Label Switching Router

MF =Multi Field

MGCP = Media Gateway Control Protocol

MPLS =Multi Protocol Label Switching

MPEG =Moving Picture Experts Group

NGN =Next Generation Network (Noile Generații de Rețele de Telecomunicații)

NHLFE =Next Hop Label Forwarding Entry

OSPF =Open Shortest Path First

PHB =Per Hop Behavior

PHP =Penultimate Hop Popping

QoS =Quality of Services (Calitatea Serviciilor)

RSVP =Resource Reservatioin Protocol

RTP =Real Time Protocol

RTCP =Real Time Control Protocol

SLA =Service Level Agreement (Contract de Garantare a Serviciului)

SCTP = Stream Control Transmission Protocol

SDP =Session Description Protocol

SIP =Session Initiation Protocol

TCA =Traffic Conditiong Agreement

TCP =Transmission Control Protocol

TE =Traffic Engineering (Ingineria Traficului)

TLV =Type Length Value

ToS =Type of Service

TTL =Time To Live (timp de viață)

UDP =User Datagram Protocol

VPI =Virtual Path Identifier (Identificatorul de Canal Virtual)

VCI =Virtual Connection Identifier (Identificatorul de Cale Virtuală)

VPN =Virtual Private Network

Introducere

Comunicarea este un element indispensabil în orice societate. Evoluția instrumentelor de comunicare a atins un apogeu odată cu era informațională, când au apărut tehnologii ca și telefonia, radioul, televiziunea, calculatoarele și rețelele de calculatoare. Avântul telecomunicațiilor s-a făcut remarcat prin nevoia tot mai mare a consumatorilor de a avea acces la Internet, de a transfera fișiere între locații aflate la distanță folosind o bază de date comună, de a transmite imagini video în direct și multe alte aplicații care au făcut într-un fel viața mai ușoară. Email, comerț electronic, telefonie prin Internet sunt doar câteva din lucrurile ce anunță o revoluție în domeniul comunicațiilor la distanță. Internetul a devenit o parte indispensabilă din viața și munca noastră.

În ultima decadă toate aceste tehnologii tind să convearga. Această convergență a început pe la mijlocul anilor 80, când existau trei rețele de comunicare globale: rețeaua de telefonie care transporta voce, rețeaua de televiziune care transporta video și Internetul care tranporta date. Astel a apărut protocolul ATM (Asynchronous Transfer Mode) care a introdus și un concept foarte important, și anume: calitatea serviciilor (QoS). Însă protocolul ATM nu a avut același succes ca protocolul IP (Internet Protocol), care s-a dovedit a fi mult mai popular în rețelele de calculatoare. Protocolul IP reprezintă un protocol de rutare de pachete fără stabilirea unei conexiuni logice sau fizice între sursă și destinație. Fiecare ruter ia decizii pe baza informațiilor dintr-un pachet alegând drumul cel mai bun către destinație. Acest mod de rutare conduce la întârzieri ale pachetelor în noduri sau chiar pierderea pachetelor pe drum.

Astfel pe la mijlocul anilor 90, cercetătorii au încercat să proiecteze un nou protocol de rețea care să aibă atât simplitatea și flexibilitatea rețelelor IP cât și oferirea de garanții QoS din rețelele ATM. Rezultatul final a fost protocolul MPLS care oferă separarea dintre procesul de găsire a căii optime și trimiterea efectivă a pachetelor, precum și un nou mecanism ierahic de trimitere a pachetelor.

MPLS (Multi Protocol Label Switching) este o tehnologie nouă, foarte importantă pentru rețelele IP, care asigură convergența a două abordări fundamental diferite în rețelele de date: datagrame și circuit virtual. Îndrumarea în rețelele tradiționale (IP) este bazată pe modelul datagramelor, fiecare pachet va fi îndrumat independent la adresa destinație, pe baza informațiilor din tabelul de rutare din fiecare nod. Tehnologia MPLS este orientată pe conexiune. Prin folosirea unor protocoale de semnalizare specifice se setează un circuit virtual sau o cale folosită pentru îndrumarea datagramelor aparținând unei clase. Pentru îndrumare este utilizată o etichetă inclusă în antetul pachetului IP care este folosită de fiecare nod pentru a căuta calea de ieșire și noua etichetă necesară următorului nod. Se realizează deci o simplificare a îndrumării pachetelor în rețea.

În lucrarea de față se va studia mecanismul MPLS ca suport pentru modelul QoS (Quality of Services) Differentiated Services. Acest model al calității serviciilor are ca specific împărțirea pachetelor de date în fluxuri cu caracteristici comune de calitate. Altfel spus, la intrarea traficului într-o rețea MPLS-DiffServ se realizează o clasificare pe diferite criterii (destinație, sursă, protocol, prioritate, întârziere, etc) iar apoi fiecare pachet este marcat cu o etichetă și trimis spre destinație pe o cale virtuală numită Label Switch Path (LSP).

Ultimul capitol are ca scop prezentarea unui model de rețea, prezentarea modului de clasificare a pachetelor în primul nod din domeniu, precum și analiza rezultatelor obținute în urma simulărilor.

1. Calitatea Serviciilor în rețelele IP Multimedia

1.1. Introducere

Noile generații de rețele de telecomunicații (NGN – Next Generation Network) folosesc ca suport de bază rețeaua bazată pe comutație de pachete IP, completată cu tehnologii care să controleze și să asigure QoS pentru integrarea serviciilor de date, voce, video, multimedia.

Calitatea Serviciilor (QoS – Quality of Service) în ingineria traficului se referă la probabilitatea rețelei de telecomunicații de a satisface un anumit contract de trafic, sau informal, este folosit pentru a se referi la probabilitatea reușitei unui pachet de a trece prin două puncte din rețea în perioada de latență dorită. Deoarece tendința este ca acum Internetul să transporte pe lângă date, și voce și video, trebuie ținuta seama și de cerințele speciale ale acestor tipuri de trafic, care se pot face cu ajutorul QoS.

Quality of Service a devenit un subiect important pentru furnizorii de servicii și cercetatori. De când comunicarea prin internet a devenit o parte esențială din viețile noastre, s-a acordat mai multă atenție îmbunatățirii parametrilor QoS cu scopul de a satisface cerințele clientul. Mai mult decât atât, QoS a devenit un instrument de manipulare pentru furnizorii de servicii, care vor să atingă o eficiență în utilizarea resurselor, în sensul că pentru un client este mai important să beneficieze de un delay minim, în loc de o banda mare. [3]

În primul rând, Quality of Service se referă la capabilitatea unei rețele de a oferi servicii mai bune pentru traficul de rețea folosind tehnologii diferite: Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet și rețele 802.x, SONET si rețele IP.

Principalul scop al QoS este să asigure prioritate, banda dedicată, trafic interactiv și probabilitate mică a ratei erorilor.

1.2. Mecanisme de implementare QoS

Termenul QoS are un sens foarte larg și se poate folosi la orice modalitate prin care se poate asigura o îmbunătățire față de serviciul standard oferit de Internet, și anume „best effort”.

Inițial, IP a fost specificat ca fiind un protocol de tip „best effort”. Una din implicațiile acestei definiții a fost faptul că rețeaua va încerca să livreze traficul la destinație, în cel mai scurt timp posibil. Pentru serviciile de ”best effort”, rețeaua trimite trafic fără nicio asigurare de fiabilitate, întarziere sau transfer. [10]

O dată cu dezvoltarea internetului a apărut o nouă generație de aplicații, ceea ce a dus la o adaptare a infrastructurii pentru a putea face față la creșterea numărului de cereri. În plus, corporațiile, guvernele, instituțiile de învățământ au găsit în protocolul IP o opțiune atrăgătoare pentru a construi rețelele lor private de date. Multe dintre noile aplicații IP (de exemplu, vocea și video) au un caracter în timp real și toleranță limitată la variațiile lățimii de bandă, latență, bruiaj și pierdere. Așteptările și cerințele utilizatorilor serviciilor de rețea au facut ca protocolul „best effort” să fie insuficient.

Astfel, în 1990, Internet Engineering Task Force (IETF) a definit doua modele Qos stabilite pentru IP: servicii integrate (IntServ) și servicii diferențiate (DiffServ).

Mai târziu a aparut și tehnologia Multiprotocol Label Switching (MPLS) care poate fi considerată tot un mecanism QoS în curs de definire.

1.3. Servicii Integrate (IntServ)

1.3.1. Tipuri de servicii în modelul IntServ

Serviciile Integrate (RFC 1633) au fost implementate de IEFC în 1994, fiind motivate de nevoia de aplicații în timp real ca audio, video, conferințe multimedia.

IntServ este un mecanism bazat pe anumiți algoritmi orientați pe flux: „rezervarea resurselor” și „accesul controlat la resurse”. Acest mecanism controlează rezervarea de resurse pentru fluxurile de timp real, folosind protocolul RSVP (Resource Reservation Protocol). RSVP este un protocol de semnalizare care va rezerva resurse (bandwidth și buffer) pentru trafic în vederea reducerii întârzierii (delay) și a variației întârzierii (jitter).

Asfel arhitectura IntServ este folosită ca suport pentru:

servicii de timp real (audio, video) prin Internet, care să poată asigura servicii predictibile sau servicii garantate. IntServ poate fi folosit, de exemplu, pentru a permite fluxului video sau audio să ajungă la receptor fără întrerupere.

partajarea controlată a linkului, care permite furnizorilor de servicii de rețea să aloce bandă la cerere și să controleze tratamentul aplicat pachetelor care aparțin diverselor clase de servicii.

Internet Engineering Task Force (IETF) a dezvoltat pentru IntServ două clase de servicii orientate spre trafic în timp real: Servicii Garantate (Guaranteed Service) și Servicii de Încărcare Controlată (Controlled Load Service).

1.3.2. Servicii Garantate (Guaranteed Service)

Guaranteed Service este cel mai complet serviciu propus pentru implementare în internet. El asigură fluxurilor de date o bandă și o întârziere garantată. De asemenea nu sunt pierderi de pachete, iar rețeaua asigură un minim de interfață cu traficul „best effort”.

Această garantare se face printr-un control strict al admisiei și prin planificarea echilibrată a cozilor de așteptare. De obicei aplicațiile de timp real pentru care se cere un serviciu garantat au cereri stricte de bandă și întârziere. Din acest motiv acest tip de serviciu este folosit ca suport pentru aplicațiile în timp real (VoIP si videoconferință).

O aplicație furnizează o caracterizare a profilului de trafic al aplicației, și rețeaua calculează întârzierea (end-to-end delay) care poate fi garantată. Dacă această întârziere este în interiorul unei limite acceptate de aplicație, atunci calea definită este acceptată pentru transmiterea pachetelor aplicației. În caz contrar, aplicația poate modifica caracterizarea traficului și cere rețelei să recalculeze întârzierea (end-to-end delay) pe care o poate garanta. Rețeaua poate calcula întârzierea pe care o poate garanate garanta în cazul cel mai nefavorabil. Deși este un serviciu ideal pentru aplicații de timp real, complexitatea implementării acestui serviciu este destul de mare și de costisitoare. [10]

1.3.3. Servicii de Încărcare Controlată (Controlled Load Service)

Pentru aplicații care nu necesită un nivel strict al garantării serviciului, IEFT a propus o categorie mai slabă de garantare a serviciilor. Controlled Load Services asigură o tratare preferențială a fluxului în condiții de suprasarcina în comparație cu fluxurile încadrate în tipul „best effort” dar nu garanteaza QoS în orice condiții.

Asigură urmatoarele performanțe:

un foarte mare procentaj din pachetele transmise vor fi furnizate cu succes la nodurile terminale destinatare.

timpul de tranzit nu va depași întârzierea impusă pentru un procentaj foarte mare din pachetele furnizate

Serviciul cu încărcare controlată furnizează aceiași calitate a serviciului QoS indiferent de gradul de încărcare al legăturii pentru majoritatea pachetelor fluxului. De asemenea, Controlled Load Service garantează că pierderile de pachete nu sunt mai mari decât rata erorilor de transmisie ale mediului și că întârzierile pe care le suferă majoritatea pachetelor nu depășesc cu mult timpul de propagare de la un capăt la altul. Diferența între acest tip de serviciu și serviciul best effort este că performanțele observate de aplicații nu se deteriorează odată cu o creștere a încărcării rețelei. [10]

1.3.4. Diferențe între Serviciile Garantate și Serviciile de Încărcare Controlată

Controlled Load Services are implementare mai simplă, mai ieftină în comparație cu Guaranted Service, nu folosește parametrii de control delay și loss, impune controlul admisiei și unele mecanisme pentru monitorizarea conformanței fluxurilor conform SLA (Service Level Agreement), performanțele observate de aplicații nu se deteriorează odată cu o creștere a încărcării rețelei.

1.3.5. Arhitectura IntServ

Un principiu esențial al arhitecturii IntServ este cerința de rezervare de resurse. Această cerință presupune controlul admisiei pentru a administra resursele finite. Nodurile IntServ trebuie să evite să accepte solicitări neautorizate sau cereri care pot afecta rezervările existente. Diferitele tipuri de utilizatori au drepturi diferite să rezerve resursele rețelei. În plus, sarcina de rețea trebuie să fie controlată pentru a respecta specificațiile cantitative și calitative ale fluxurilor existente. IntServ lasă alegerea QoS-ului aplicației, nu rețelei.

Arhitectura definește fluxul ca unitatea de servicii de bază. Fluxurile sunt unidirecționale. Au o singură sursă și una sau mai multe destinații. IntServ necesită utilizarea stării per flux în nodurile rețelei. Această cerință rezultată din granularitatea fluxului și utilizarea rezervării de resurse cu controlul admisiei. Nodurile din rețea sunt cele care mențin starea fluxului iar acest lucru reprezintă o schimbare semnificativă a arhitecturii originale în care starea fluxului era monitorizată și menținută de sursă și destinație. Arhitectura recomandă utilizarea unui protocol de semnalizare pentru a configura și a actualiza starea fluxului. [4]

Fig. 1.1. Rețea IntServ [1]

1.3.6. Dezvoltarea și evoluția în timp a mecanismului

Arhitectura IntServ poate deveni un cadru de lucru viabil pentru rețelele corporațiilor, care sunt limitate în dimensiune și au un singur domeniu administrativ. Conceptele și mecanismele QoS dezvoltate în IntServ au fost folosite ulterior. Controlled Load Services a influențat dezvoltarea DiffServ și capabilitațile de rezervare de resurse au fost încorporate în MPLS pentru garantarea lărgimii de bandă pentru trunchiurile de trafic în rețelele core.

1.4. Servicii Diferențiate (DiffServ)

1.4.1. Introducere

Arhitectura DiffServ a fost dezvoltată ca răspuns la nevoia pentru metode relativ simple de implementare a diferitelor nivele de servire a traficului din Internet, care să suporte diverse tipuri de aplicații și cerințe specifice. Astfel in 1998, IETF a publicat RFC 2475 – Arhitectura DiffServ.

Abordarea DiffServ în susținerea capabilităților QoS stă în faptul că se utilizează un set mic, bine definit de blocuri din care pot fi construite diferite comportamente ale traficului. DiffServ oferă o tratare diferențială a fluxurilor agregate folosind marcarea pachetelor. Fiecare clasă de trafic poate fi gestionată în mod diferit, asigurând un tratament preferențial pentru traficul cu prioritate crescută în rețea.

Arhitectura DiffServ diferă de cea IntServ în mai multe aspecte. Cea IntServ alocă resurse fluxurilor individuale, pe când cealaltă divide traficul într-un număr mic de clase și atribuie resurse pentru fiecare clasă în parte, fără să intre în detaliile fluxurilor de date pe care le procesează. Această abordare oferă o soluție mai simplă din punct de vedere al implementării și dezvoltării. Rețeaua nucleu (core) a unei rețele DiffServ va trebui să distingă între câteva clase de echivalență decât între fluxuri individuale. Clasele pot fi transportate direct în antetul pachetului și în plus nu mai este necesară clasificarea complexă care se face la nivel de flux, eliminând astfel problema scalabilității din arhitectura IntServ. [5]

În implementările actuale DiffServ oferă două modele de servicii pe lângă clasicul „best effort”. „Premium service” garantează rata de vârf și este optimizat, oferind o întârziere minimă a pachetelor. Acest model poate asigura o calitate absolută a serviciului. „Assured service” este al doilea model și se bazează pe planificarea statistică a resurselor. Pachetele sunt marcate în două clase In și Out. Pachetele In au cea mai mică probabilitate de a fi eliminate, pe când pachetele Out sunt primele eliminate în cazul unei congestii. Acest serviciu asigură un Qos relativ. [10]

1.4.2. Rețea de referință pentru rețele DiffServ

Rețeaua de referință cuprinde unul sau mai multe domenii DiffServ într-o rețea care permite controlul calității serviciilor de la transmițător (Tx) la receptor (Rx) (End-to-End QoS).

Fig. 1.2. Configurația unei rețele simple

DiffServ pornește de la două principii de proiectare. Primul principiu este acela de a împinge complexitatea spre marginea rețelei, iar al doilea este acela de separare a politicii de mecanismele de implementare. Marginea rețelei este formată din stațiile și serverele conectate la rețea și routerele de frontieră. Deoarece la marginea rețelei numărul de fluxuri este relativ redus, operațiile de clasificare și marcare a pachetelor pot fi efectuate cu acuratețe maximă fără a necesita resurse deosebite. În contrast, în inima rețelei numărul de fluxuri este semnificativ mai mare și de aceea aici trebuie să se efectueze doar operații simple a căror durată să fie cât mai mică. Această diferențiere între routerele de graniță și routerele din centrul rețelei este vitală pentru scalabilitatea modelului DiffServ.
Domeniul DiffServ conține rutere care asigură controlul traficului agregat. Ruterele ER1 și ER2 sunt adiacente domeniului DiffServ, iar BR1 și BR2 sunt noduri de graniță care aparțin domeniului DiffServ. În funcție de controlul admisiei la resursele disponibile din domeniul DiffServ și a politicii definită de client, pot fi realizate de ER sau BR.

BR sunt rutere de graniță care fac parte din domeniul rețelei DiffServ. Dacă semnalizările RSVP sunt controlate în afara domeniului DiffServ, atunci BR realizează funcții de rutare DiffServ. Politica de tratare a traficului depinde de tipul serviciului specificat în DSCP (DiffServ Code Point) și de acordul încheiat cu clientul prin SLA (Service Level Agreement).

1.4.3. Arhitectura DiffServ

Un ruter IP tradițional recepționează pachetele de la intrare și le direcționează spre destinațiile lor. Ruterul conține următoarele blocuri funcționale: interfețe, modul de îndrumare și modul de management.

Interfețele de intrare acceptă pachete de la alte rutere. Pachetele sunt îndrumate spre interfața de ieșire adecvată pe baza adresei destinație. Fiecare interfață de ieșire folosește mecanisme specifice linkului pentru transmiterea pachetului la următorul ruter sau host. În cazul apariției congestiei locale, ruterul aruncă pachete sau le marchează pentru a semnala starea de congestie nodurilor vecine. Acțiunile modulului de îndrumare și răspunsul la congestie sunt controlate de modulul de management.

Serviciile diferențiate se extind peste granițele unui domeniu DiffServ prin stabilirea de SLA-uri între rețeaua din amonte și domeniul din aval. SLA-ul poate specifica modul de clasificare al pachetelor și regulile de marcare a lor și poate, de asemenea, să specifice profile de trafic precum și acțiuni ce se întreprind împotriva fluxurilor ce nu se încadrează în aceste profile. TCA-ul dintre domenii este derivat explicit sau implicit din acest contract de garantare a serviciului (SLA).

În DiffServ, nodurile de graniță sunt responsabile de atribuirea pachetelor la una din clasele de îndrumare suportate de rețea. Vor trebui să verifice dacă traficul este conform cu acordul încheiat între furnizorul de servicii și clientul care generează trafic. În interiorul rețelei, alocarea resurselor se face exclusiv pe baza clasei de îndrumare. În ruterele de graniță există mai multe unități funcționale care se ocupă de alocările pachetelor la clasele corespunzătoare și acțiunile luate în cazul nerespectării SLA-ului.

Fig. 1.3. Arhitectura DiffServ

În arhitectura DiffServ, procesările și deciziile complexe sunt făcute în nodurile de graniță, iar serviciile Edge-to-Edge sunt construite pentru un set restrâns de comportări în CRs. Aceste caracteristici ale DiffServ au ca efect realizarea în CR a unei îndrumări mai rapide și reduceri de stări pentru semnalizare, procesare și memorare. [10]

Core Routers stabilesc modul de îndrumare al pachetelor în funcție de valoarea DSCP transportat în fiecare pachet. DSCP este definit în câmpul DiffServ, obținut prin refolosirea câmpului Type of Service din pachetul IPv4. Codul DSCP este folosit pentru dirijarea pachetelor către o coadă de așteptare asociată unei clase de îndrumare. Planificatorul va extrage pachetele din cozile de așteptare și le va trasnmite prin linkul asociat în raport cu cerințele QoS ale clasei de îndrumare indicată de DSCP.

Modulul de clasificare al pachetului conține un clasificator și un marcator. Clasificatorul alege pachete pe baza regulilor predefinite în acordul contractual. Nodurile de graniță realizează interpretarea condițiilor impuse în TCA (Traffic Conditionig Agreements) pentru fiecare client. Profilul de trafic specifică proprietățile temporale ale traficului clientului pe înțelesul condiționerului de trafic și furnizează un set de reguli pentru identificarea pachetelor care aparțin acelui profil. Atunci pachetele se marchează cu codul clasei de îndrumare (DSCP particular). Se verifică dacă traficul se încadrează în profilul de trafic stabilit. Dacă nu se încadrează în profil, în acordul contractual se pot menționa o serie de acțiuni ce pot fi luate pentru această situație: întârziere (shapping), aruncare (dropping) sau remarcare (remarking). [5]

Implementarea tratamentului de îndrumare diferențiat al pachetelor clasificate se realizează prin introducerea pachetelor în cozi de așteptare distincte (queuing). Alegerea cozii se face pe baza DSCP. Extragerea pachetelor din cozi pentru transmitere se face sub controlul unui planificator care respectă prioritățile de trafic.

1.4.4. Clasificarea și condiționarea traficului

Nodurile periferice pot funcționa ca noduri DiffServ de intrare și de ieșire pentru direcții de trafic diferite. Traficul intră în domeniul DiffServ printr-un nod de intrare numit ingress și părăsește domeniul printr-un nod de ieșire egress. Nodurile de graniță sunt responsabile de maparea pachetelor la una din clasele de îndrumare suportate și trebuie să se asigure că traficul se conformează cu SLA-ul fiecărui client. Odată intrate în rețea pachetele, alocarea resurselor se face numai pe baza claselor de îndrumare.

Aceste funcții pe care nodurile de graniță le efectuează sunt cunoscute ca și clasificarea traficului și condiționarea traficului.

1.4.4.1. Clasificare

Clasificatorul de pachete alege pachetele dintr-un flux pe baza conținutului lor sau numai a antetului. Există două tipuri de clasificatori: BA (Behavior Aggregate) și MF (MultiField).

Cel mai simplu clasificator DiffServ este cel de tip BA. Acesta selectează pachetele numai pe baza câmpului DSCP din antetul pachetelor. Clasificatoarele BA sunt în general folosite atunci când valoarea DSCP a fost deja înscrisă înainte de sosirea pachetului la clasificator. Valoarea DSCP poate fi definită ori de către client, atunci când rețeaua acestuia suportă DiffServ și pachetele sunt marcate de sursă sau primul ruter din LAN, ori dacă nu se poate face de către client atunci furnizorul de servicii va asigura marcarea.

Clasificatorul MF este realizat în scopul eliminării limitărilor clasificatorului BA printre care: numărul limitat de clase (64) și lipsa informațiilor privind originea și destinația pachetului. Clasificatorul MF folosește o combinație de câmpuri (adresa sursă și destinație, portul sursă și destinație și protocol ID (TCP/UDP)) din antetul pachetului pentru clasificare. Poate suporta politici de alocare de resurse mai complicate, ca de exemplu :

Marcarea pachetelor după tipul aplicației (telnet, ftp, etc.)

Marcarea pachetelor după adresa sursei sau a destinației (traficul generat de directori, servicii importante sau de servere cu misiuni critice)

Marcare pachetelor bazată pe câmpurile de mai sus care indică o anume aplicație (streaming video)

Politicile de clasificare pot specifica un set de reguli și valorile DSCP corespunzătoare pentru marcarea pachetelor. Clasificarea MF este foarte versatilă dar mai dificil de implementat. Clasificarea BA este mult mai simplă cu o implementare bazată direct pe valorile DSCP. După clasificare și marcarea pachetelor acestea sunt trimise către următorul modul de condiționare pentru procesare.

Implementarea funcțiilor complexe de clasificare și condiționare se realizează numai în nodurile de graniță BR. Comportarea PHB se aplică agregatelor de trafic care au fost marcate corespunzător folosind în acest scop câmpul DiffServ din antetele IPv4 și IPv6. Clasificatorii sunt folosiți pentru a dirija operațiile ulterioare care se aplică pachetelor. [5]

1.4.4.2. Condiționarea

Un modul de condiționare trafic conține patru elemente de bază: sistem de masură (meter), sistem de marcare (marker), sistem de întârziere (shaper) și sistem de eliminare a pachetelor (dropper). Meter-ul sau masurătorul de trafic monitorizează și măsoară fluxurile de trafic, iar marcarea, întarzierea și aruncarea sunt acțiuni care pot fi folosite pentru pachetele neconforme.

Pentru fiecare clasă de îndrumare, meter-ul măsoară traficul scurs de la un client prin profilul său de trafic. Pachetele conforme (in-profile) sunt permise să intre în rețea iar cele neconforme (out-of-profile) sunt supuse condiționării pe baza TCA. Profilele de trafic sunt descrise în termenii algoritmilor: „leaky bucket” și „token bucket”, majoritatea meter-elor fiind implementate ca „token bucket”.

Algoritmul găleții care curge „leaky bucket” poate fi înțeles conceptual după cum urmează: pachetele sosite (PDUs) sunt plasate într-o găleată care este găurită în partea de jos. Găleata poate pune în coada de așteptare cel mult b octeți. Dacă un pachet sosește când găleata este plină, pachetul este eliminat. Pachetele se scurg prin gaura din găleată în rețea la o rata constanta de r octeți pe secundă, nivelând astfel vârfurile de trafic. Dimensiunea „b” a găleții este limitată de memoria disponibilă a sistemului.

Implementarea algoritmului „leaky bucket” nu folosește eficient resursele disponibile în rețea. Deoarece rata de scurgere este un parametru fix, sunt multe cazuri în care volumul traficului poate fi foarte scăzut și mari porțiuni din resursele de rețea (în special, lățimea de bandă) să nu fie utilizate. Prin urmare, nu există niciun mecanism în acest algoritm care să permită fluxurilor individuale să accelereze până la viteza de port și să consume în mod eficient resursele de rețea atunci când acestea nu sunt disputate.

Algoritmul găleții cu jetoane „token bucket” este similar în anumite privințe cu algoritmul găleții care curge dar diferența primară este aceea ca găleata cu jetoane permite traficului în rafale să-și continue cursul până la parametrul de revărsare al găleții. Găleata cu jetoane este un mecanism de control care dictează când poate fi transmis traficul, în funcție de prezența jetoanelor în găleată. Găleata cu jetoane conține jetoane, fiecare dintre ele reprezentând o unitate de biți. Administratorul de rețea specifică numărul de jetoane necesar pentru a transmite un anumit număr de biți.

Algoritmul poate fi înțeles din punct de vedere conceptual, după cum urmează: un jeton este adăugat în găleată la fiecare 1/r secunde. Găleata poate suporta maxim b jetoane. Dacă un jeton sosește când găleata este plină, acesta este eliminat. Când sosește un pachet de n octeți, din găleată sunt scoase n jetoane, iar pachetul este trimis în rețea. În cazul în care mai puțin de n jetoane sunt disponibile, niciun jeton nu este eliminat din găleată, iar pachetul este considerat a fi non-conform. Pachetele non-conforme pot fi tratate în diverse moduri: abandonate, puse în coada de așteptare pentru transmiterea ulterioară în momentul în care s-au acumulat în găleată suficiente jetoane sau transmise, dar cu posibilitatea ulterioară de a le elimina dacă rețeaua este supraîncărcată.

Implementarea găleții cu jetoane suportă, cu toate acestea, fluxurile de trafic cu caracteristici de rafală. Implementările galeții care curge și a galeții cu jetoane pot fi combinate pentru a oferi un maxim de control și eficientă în fluxurile de trafic dintr-o rețea.

Marker-ul este folosit pentru setarea câmpului DiffServ al unui pachet la o anumită valoare DSCP. În acest fel pachetul marcat este adăugat la clasa de îndrumare adecvată. Markerul poate acționa asupra pachetelor nemarcate sau poate realiza remarcarea celor marcate anterior.

Când traficul trece printr-un meter, unele pachete pot fi marcate cu un cod special DSCP pentru a indica non-conformanța cu profilul de trafic. Aceste pachete vor fi primele aruncate dacă apare congestie în rețea. Remarcarea poate fi necesară când pachetele trec prin domenii diferite dacă acestea utilizează DSCP-uri diferite.

Fig. 1.4. Traseul datelor într-un sistem DiffServ

Marker-ul setează câmpul DSCP al unui pachet particular și adaugă pachetul marcat la un agregat cu comportare DiffServ.

Funcția de marcare asigură protecția ruterelor downstream. Prin remarcarea pachetelor, acestea pot fi tratate ca aparținând unei clase inferioare.

Shaper-ul întârzie unele sau toate pachetele dintr-un flux de trafic în scopul armonizării fluxului cu un profil de trafic. Diferența dintre un shaper și un marker este aceea că markerul marchează pachetele neconforme și le dă drumul în rețea pe când shaperul previne intrarea în rețea până când traficul devine conform profilului de trafic contractat. Întârzierea este realizată prin memorarea temporară a pachetelor într-un buffer.

Acțiunea de întârziere poate fi de asemenea necesară într-un nod de graniță către un alt domeniu, deoarece este posibil ca profilul de trafic să se modifice. Nodul de ieșire poate necesita întârzierea fluxului traficului de ieșire pentru ca acesta sa fie conform cu profilul de trafic pentru următorul domeniu.

Dropper-ul realizează aruncarea pachetelor care sunt neconforme cu profilul de trafic.

Clasificatorii și condiționerii de trafic sunt de obicei situați în nodurile ingress și egress unde traficul trece în alt domeniu. [6]

1.5 Concluzii

Arhitectura IntServ asigură End-to-End QoS pentru orice tip de aplicație. Rețeaua realizează un control al admisiei la resursele solicitate. Aceasta verifică dacă există resurse disponibile și în caz afirmativ se face rezervarea acestora. Fluxurile aplicațiilor, pentru care s-a putut face rezervare de resurse, sunt clasificate în raport cu cerințele specifice și sunt tratate diferențiat în ruterele rețelei. Controlul rezervării de resurse se face pe flux, astfel că acest mecansim nu poate fi aplicat pentru rețele foarte mari.

Arhitectura DiffServ clasifică pachetele într-un număr mic de clase de îndrumare (FEC = Forwarding Equivalence Class) sau agregate de flux, folosind în acest scop marcarea pachetelor cu DSCP (DiffServ Code Point). În rețele DiffServ traficul este mapat în clase de îndrumare prin clasificatorul de pachete și condiționerul de trafic din ruterul de graniță al domeniului administrativ. Condiționerii de trafic măsoară traficul care intră în rețeaua DS pentru a defini încadrarea în profilele de trafic ale clientului. Pachetele nonconforme sunt tratate diferit prin acțiuni de tipul aruncare, întârziere, remarcare în conformitate cu prevederile SLA. În interiorul rețelei, pachetele sunt îndrumate pe baza DSCP din antetul IP.

Tehnologiile IntServ, RSVP și DiffServ sunt complementare și pot fi folosite împreună pentru asigurarea End-to-End QoS, necesare aplicațiilor VoIP, VoD, aplicații multimedia, aplicații critice.

2. Bazele Multiprotocol Label Switching

2.1. Multiprotocol Label Switching

Multiprotocol Label Switching (MPLS) a fost inițial propus ca o metodă de a permite comutarea pachetelor în locul rutării tradiționale, permițând viteze de lucru mult mai mari. Ulterior însă s-a dovedit a fi foarte util pentru asigurarea QoS. Similar cu domeniile DiffServ, MPLS folosește un concept de domeniu MPLS format din routere MPLS, iar pachetele sunt etichetate la intrarea în domeniu. Etichetele sunt eliminate atunci când pachetul iese din domeniu.

MPLS este o metodă îmbunătățită de a îndruma pachete printr-o rețea folosind informația conținută în antetul MPLS atașat pachetelor IP. Antetul MPLS conține o stivă de etichete cu 4 câmpuri: o etichetă de valoare de 20 de biți, un câmp de 3 biți pentru prioritatea QoS, un bit „sfârșitul stivei” și un câmp TTL (timp de viață) de 8 biți. Etichetele sunt inserate între antetul de nivel 3 și antetul de nivel 2 în cazul tehnologiilor de nivel 2 bazate pe cadre (frame-uri) sau sunt conținute în identificatorul de cale virtuală (VPI) și identificatorul de canal virtual (VCI) în cazul tehnologiilor bazate pe celule precum ATM.

MPLS funcționează la un nivel de model OSI, combinând tehnologiile de comutație de nivel 2 cu tehnologiile de rutare de nivel 3, adeseori fiind menționat ca protocol de „nivel 2.5”. Principalul obiectiv al MPLS este să creeze un material flexibil pentru rețelistică care să furnizeze perfomanțe și stabilitate mărite. Aceasta include capabilități de ingineria traficului (TE) și VPN (Virtual Private Network) care oferă servicii de calitate (QoS) cu multiple clase de servicii.

În urma cercetărilor, IEFT a recunoscut comutația de pachete ca fiind potențiala soluție pentru un număr de probleme. De exemplu comutația de pachete poate fi utilizată la simplificarea procesului de îndrumare sau la dezvoltarea procesului de îndrumare ca independent, permițând mai multe protocoale să fie implementate peste același drum. Metodele de comutație de etichete permit ruterelor MPLS și echipamentelor compatibile să ia decizii de îndrumare doar pe baza unei simple etichete, decât să efectueze o căutare intensă bazată pe adresei IP destinație. Această tehnică aduce multe beneficii rețelelor IP:

Calitatea serviciilor (QoS) – folosind QoS în MPLS, furnizorii de servicii pot garanta serviciile lor clienților VPN.

VPN – prin folosirea MPLS, furnizorii de servicii pot crea VPN-uri de nivel 3 prin rețeaua lor de backbone pentru clienți, folosind o infrastructură comună, fără nevoia de criptare sau aplicații pentru utilizatorii finali.

Ingineria traficului (TE – Trafic Engineering) – posibilitatea de setare a drumurilor sau drumului pe care traficul îl va parcurge prin rețea. Deasemenea oferă posibilitatea de setare a performanțelor caracteristice unei anumite clase de trafic. Această caracteristică optimizează utilizarea de bandă pentru căile slab folosite.

Integrarea între IP și ATM – majoritatea transportatorilor de date folosesc un model in care ATM este folosit la nivel 2 și IP la nivel 3. Astfel de implementări au mari probleme de scalabilitate. Prin MPLS, furnizorii pot muta multe din funcțiile planului de control ATM la nivelul 3, deci simplificând dezvoltarea, managementul și complexitatea rețelei. Această tehnică oferă scalabilitate mare și elimină adaosul (overhead) automat celulelor din ATM.

MPLS combină performanțele și capabilitățile nivelului 2 cu scalabilitatea dovedită a nivelului 3. Aceasta permite furnizorilor să înfrunte provocările creșterii explozive a utilizării rețelelor în timp ce promite oportunitatea serviciilor de calitate fără să sacrifice infrastructura existentă. Prin adoptarea MPLS în arhitectura rețelelor, mulți furnizori și-au redus costurile, au crescut profitul și productivitatea, au furnizat servicii diferențiate și au câștigat avantaj în fața celorlalți competitori care nu oferă încă servicii MPLS.

MPLS lucrează prin etichetarea pachetelor cu o etichetă pentru a fi identificată o cale numită LSP. În momentul în care un ruter numit LSR primește un pachet, se folosește de această etichetă pentru a identifica un LSP. Apoi routerul caută în propriul tabel de îndrumare pentru a determina calea prin care să îndrume pachetul și eticheta care va fi folosită în cadrul următorului nod. Vechea etichetă este înlocuită cu cea nouă și pachetul este trimis catre următoarea destinație. [7] [9]

2.2. Concepte Multiprotocol Label Switching

2.2.1. Label switched path (LSP), Label switch router (LSR)

O rețea MPLS este alcătuită din noduri numite rutere cu comutație pe bază de etichetă, capabile de comutare a pachetelor pe baza unei etichete asignate pachetului. În figura de mai jos este prezentată o rețea MPLS cu patru rutere cu comutație de etichete numite LSR și trei căi de îndrumare MPLS numite LSP.

Fig 2.1. Rețea simplă MPLS

Primul și ultimul LSR din calea LSP sunt numite LSR ingress (ruterul prin care intra traficul în domeniul de rețea MPLS) și respectiv LSR egress (ruterul prin care iese traficul din domeniul MPLS) De exemplu pentru LSP 1, A este ingress și C este egress.

Ruterele tranzit sunt ruterele din interiorul rețelei care efectuează operații de interschimbare a etichetei și transmit pachetul următorului nod.

O cale LSP este unidirecțională. Nodul care transmite pachete este numit upstream (ex. LSR A este upstream pentru B) și nodul care primește pachete este numit downstream. [8]

2.2.2. Eticheta (Label)

Eticheta MPLS numită label este de lungime fixă și este folosită pentru comutația de etichete. Un pachet care conține o etichetă se numește pachet etichetat. Eticheta poate fi mapată într-un pachet fie într-un câmp de la nivelul 2 fie într-un câmp de la nivelul 3.

Deoarece eticheta este singurul identificator care este folosit pentru înaintarea pachetului, un LSR trebuie să poată asocia eticheta cu o cale de îndrumare (LSP). Fiecare etichetă este asociată cu o clasă de îndrumare FEC (Forwarding Equivalence Class), care definește un grup de pachete IP care sunt îndrumate prin aceeași cale LSP și au același tratament aplicat pachetelor în raport cu QoS impus. Un exemplu de FEC este setul de pachete a căror adrese sursă și destinație este la fel. [11]

MPLS poate opera în două moduri:

Frame mode (modul cadru): este termenul folosit atunci când se dirijează un pachet cu o etichetă atașată pachetului în fața antetului de nivel 3.

Cell mode (modul celulă): este termenul folosit atunci când rețeaua conține ATM LSRs care folosește MPLS. Eticheta este codată în câmpul celulei VPI/VCI.

Antetul MPLS este plasat între antetul de nivel 2 (Legătură de date) și antetul de nivel 3 (Rețea) și are 32 de biți după cum urmează:

Fig. 2.2. Antetul MPLS

Label (Eticheta) – un câmp de 20 de biți ce conține valoarea efectivă a etichetei.

Exp – un câmp de 3 biți rezervați pentru a indica Clasa de Servicii.

BS (Bottom of Stack) – baza stivei; este un bit setat cu 1 dacă este ultima etichetă rămasă în stivă și cu 0 dacă sunt mai multe.

TTL (Time to live) – timpul de viață; în rutarea IP tradițională, orice pachet poartă o valoare TTL în antet. De fiecare dată când pachetul traversează un nod din rețea valoarea TTL este decrementată cu o unitate, dacă valoarea ajunge la 0 înainte ca pachetul să ajungă la destinație, acesta este aruncat. Astfel se realizează un mecanism împotriva circulației infinite a pachetelor în rețea în cazul buclelor. Este folosit și în MPLS. [9]

Este responsabilitatea fiecărui LSR să se asigure că poate să interpreteze în mod unic etichetele din pachetele de la intrare.

Un pachet poate avea una sau mai multe etichete, alcătuind o stivă de etichete.

Fig 2.3. Stivă de etichete

Se numește stivă deoarece ordinea de intrare și de ieșire este după regula LIFO (ultimul intrat, primul ieșit). Procesarea va fi bazată întotdeauna pe eticheta din capătul stivei, fără a se ține cont de celelalte etichete din stivă.

Stiva de etichete se folosește pentru a suporta formarea de tunele incluse în alte tunele. Îndrumarea se va face pe baza etichetei din vârful stivei; când pachetul iese din tunel, eticheta din vârf este îndepărtată și îndrumarea se face pe baza următoare etichete de la nivelul imediat inferior. [11]

Operațiile care pot fi aplicate stivei sunt următoarele:

Înlocuirea etichetei din vârf cu o altă etichetă

Scoaterea din stivă a ultimei etichete (pop)

Înlocuirea etichetei din vârful stivei cu una nouă și adăugarea încă a unei etichete (push)

Fig. 2.4. Stiva de etichete

2.2.3. Tabel de comutație de etichete – (ILM – Incoming Label Map)

Tabelul de comutație de etichete, numit și ILM (Incoming Label Map), menține maparea etichetei de intrare cu adresa de ieșire și cu eticheta următorului hop. Funcțiile sale sunt similare cu cele ale tabelului de rutare din ruterele IP. Intrarea pe care eticheta de sosire o indică este numită next-hop label forwarding entry (NHLFE) și reprezintă adresa următorului hop.

Tipic, NHLFE conține adresa următorului hop și eticheta de ieșire necesară hop-ului următor. Dacă LSR este nod ingress sau egress pentru LSP atunci NHLFE specifică de asemenea acțiunile pentru manipularea stivei de etichete

LSR folosește tabelul de comutație de etichete astfel: când un pachet de intrare sosește în LSR, acesta folosește eticheta MPLS pentru a găsi NHLFE. Adresa următorului hop din acest tabel este folosită pentru îndrumarea pachetului spre interfața de ieșire. Se citește de asemenea eticheta de ieșire care este folosită pentru a înlocui în antetul MPLS al pachetului eticheta existentă. Această etichetă introdusă va fi folosită de următorul nod pentru îndrumarea pachetului. [9]

Fig. 2.5. Tabelul de comutație de etichete

2.2.4. Protocoale de rutare Multiprotocol Label Switching

MPLS definește doar mecanismul de îndrumare. Pentru stabilirea LSP-urilor, MPLS folosește alte protocoale. Astfel sunt necesare două protocoale separate pentru a realiza această operație: un protocol de rutare și un protocol de semnalizare.

Protocolul de rutare se utilizează pentru determinarea topologiei rețelei în rețea, astfel încât să poată fi calculate căile LSP. De obicei este folosit un protocol de rutare de tip OSPF (Open Shortest Path First) sau IS-IS (Intermediate System-Intermediate System), deoarece rețelele MPLS acoperă în mod obișnuit un domeniu administrativ. Fiecare ruter își construiește astfel o tabelă de rutare.

Atunci când este necesară ingineria traficului pentru a stabili LSP-uri cu caracteristici garantate de calitate a serviciului sunt folosite extensii TE ale acestor protocoale. Aceste extensii distribuie informațiile legate de QoS și grupuri de link-uri către fiecare link din rețea. Aceste informații permit calcularea rutelor prin rețea cu parametri QoS garantați și a rutelor secundare (de backup).

2.2.5. Protocoale de distribuție (semnalizare) a etichetelor

Un protocol de distribuire a etichetelor este un set de proceduri prin care două LSR învață unul despre celălalt capabilitățile MPLS și realizează schimbul de mapare de etichete. Protocoalele de distribuție setează starea LSP în rețea. Asemenea protocoale mai sunt numite și protocoale de semnalizare pentru rețeaua MPLS.

În MPLS, decizia de mapare a unei etichete particulare unei clase particulare de îndrumare este realizată întotdeauna de LSR-ul din downstream cu referire la fluxul de pachete. LSR downstream informează LSR din upstream despre mapare. Astfel traficul de date și traficul de control curg în direcții opuse. Protocolul LDP controlează stabilirea căii LSP prin distribuirea etichetelor de îndrumare.

Un protocol de distribuire a etichetelor este un set de reguli prin care un LSR va informa un alt LSR de legătura etichetă-clasă pe care a făcut-o. Între 2 LSR-uri care folosesc un astfel de protocol pentru a schimba asocierea etichetă-clasă, se spune că există o adiacență de distribuție a etichetelor.

Pe orice adiacență de distribuție de etichete LSR din downstream și cu cel din upstream trebuie să se pună de acord ce mod se va folosi. Protocolul de semnalizare informează nodurile de pe o anumită rută despre ce etichete și link-uri să folosească pentru fiecare LSP.

IETF a considerat inițial un singur protocol de distribuție de etichete Label Distribution Protocol (LDP), acesta fiind și cel mai întâlnit. LDP este un protocol bazat pe informații de rutare IP, care permite construirea căilor comutate cu etichetă în domeniul MPLS. LDP a fost în mare parte bazat pe Tag Switching (Comutație de Etichete) dezvoltat de Cisco și propunerile ARIS (Aggregate Route-based IP Switching) de la IBM care erau dezvoltate să suporte rutarea hop cu hop. ARIS era modelul celor de la IBM de comutație a datagramelor IP. Este foarte asemănător cu MPLS în sensul că folosește etichetele pentru crearea unui circuit virtual pentru îndrumarea datagramelor.

Apărând ca o aplicație cheie a MPLS, ingineria traficului punea mare accent pe rutarea explicită. Au apărut două propuneri diferite: prima, Constraint-based LSP Setup using LDP a adăugat o extensie protocolului LDP pentru a suporta rutare explicită. Cea de-a doua propunere, Extensions to RSVP for LSP Tunnels, a extins protocolul RSVP (Resource Reservation Protocol) să efectueze comutație de etichete.

Cele două propuneri au cauzat dezbateri în cadrul grupului IETF dar nu s-a ajuns la nici un consens. Așadar s-a luat hotărârea să se standardizeze ambele propuneri. Sunt cunoscute sub numele de CR-LDP (Constraint Routing Label Distribution Protocol) și RSVP-TE (RSVP- Traffic Engineering). [10]

2.2.5.1. Label Distribution Protocol (LDP)

Label Distribution Protocol este primul protocol de distribuție a etichetelor standardizat de IETF și definit in RFC 3036. Protocolul este realizat astfel încât să suporte rutare hop cu hop. LDP este un protocol prin care două LSR, numite pereche LDP (peers), schimbă informații despre maparea etichetelor, construiesc și mențin tabela de comutație necesară îndrumării traficului MPLS.

Arhitectura MPLS definește un protocol de distribuție a etichetelor ca un set de proceduri prin care un LSR informează pe altul de semnificația etichetelor folosite pentru a îndruma traficul între ele.

Arhitectura MPLS permite conceperea a mai multor protocoale de distribuție și ca atare un număr de astfel de protocoale au fost dezvoltate. Protocoale existente au fost extinse pentru a suporta distribuția de etichete, mecanismul se numește piggyback. De asemenea s-au creat și protocoale noi explicit realizate în scopul distribuirii de etichete.

Protocolul LDP este un set de proceduri și mesaje prin care ruterele LSR stabilesc căi (LSP) prin rețea mapând informația de nivel trei direct la rutele de nivel doi. Aceste rute LSP pot avea capătul direct atașat la un vecin (comparabil cu rutarea hop-cu-hop din IP) sau pot avea capătul la un nod egress și astfel comutația de etichete se realizează în toate nodurile intermediare.

O sesiune LDP începe prin descoperirea vecinilor prin trimiterea unor mesaje de tip Hello. După inițierea sesiunii, se trimit mesaje de tip Initialization prin care se stabilește modul de funcționare. Apoi se începe distribuția etichetelor, LDP asociind o clasă echivalentă de îndrumare (FEC) cu fiecare LSP pe care îl creează. Clasa asociată specifică ce fel de pachete sunt asociate cu calea respectivă. LSP-urile sunt extinse în rețea pe măsură ce fiecare LSR combină etichetele de intrare cu etichete de ieșire asignate următorului hop pentru o clasă de echivalență dată. La sfârșitul negocierii, LSR-urile își completează tabela de comutație. Dacă o etichetă propusă nu este acceptată, se va raspunde cu un mesaj de tip Notification. [12]

2.2.5.2. Constraint Routing Label Distribution Protocol (CR-LDP)

Constraint Routing-Label Distribution Protocol este un protocol de distribuție a etichetelor special realizat să suporte ingineria traficului. Este în mare parte bazat pe specificațiile LDP la care s-au adăugat un set de extensii pentru acceptarea rutelor explicite și rezervării de resurse. În CR-LDP, o rută explicită mai este numită și rută bazată pe constrângere, pe scurt CR-LSP. O cale LSP poate fi instanțiată pe baza constrângerilor explicite de rutare, pe baza constrângerilor de QoS sau a altor constrângeri.

Un model de rutare bazat pe constrângeri folosește ca intrări următoarele informații:

Atributele asociate trunchiurilor de trafic;

Atributele asociate resurselor;

Alte informații legate de topologia rețelei.

Un proces de rutare bazat pe constrângeri calculează pentru fiecare nod, rutele explicite pentru fiecare trunchi de trafic care își are originea în acel nod. În acest caz, o rută explicită pentru fiecare trunchi de trafic este o specificare a căii comutate ce satisface cerințele exprimate în atributele trunchiului respectiv, subiect al contrângerilor impuse de existența resurselor, politici administrative și alte informații topologice. [15]

Protocolul CR-LDP introduce noi caracteristici:

Rutare explicită

Rute fixe

Rezervarea de resurse și înlocuirea căilor

LSP ID

Rutele explicite

CR-LDP poate suporta două moduri ale rutelor explicite: în sens strict și în sens larg. Într-un mesaj de Cerere Etichetă (Label Request), o astfel de rută este reprezentată ca o listă de noduri sau un grup de noduri de pe parcursul rutei. Fiecare CR-LSP este identificat prin un LSP ID, un identificator unic într-o rețea MPLS. LSP ID se compune din identificatorul nodului LSR ingress și un identificator unic local al căii din acel LSR, și este folosit atunci când parametrii unui LSP existent trebuie modificați.

În figura de mai jos avem un exemplu de stabilirea LSP-ului cu CR-LDP. Nodul Ingress LER inițiază stabilirea unui LSP și decide că ruta ar trebui să treacă prin LSR. Trimite o cerere de etichetă către LSR în care specifică nodurile rutei . LSR primește mesajul, îl analizează și îl trimite mai departe modificat conform rutei. Egress LSR îl primește și îi asignează o etichetă și trimite înapoi la LSR un mesaj de mapare etichetă. LSR folosește LSP ID pentru a identifica pentru ce rută a venit răspunsul de mapare, atribuie și el o etichetă pentru linkul între LSR și Ingress LER și apoi populează tabela de comutație cu etichetele obținute.

Fig. 2.6. Stabilirea unui LSP cu CR-LDP

Reoptimizarea căilor și rutele fixe

CR-LDP poate reoptimiza un LSP, și folosirea unui LSP ID evită dublarea rezervării în timpul optimizării. În unele cazuri, schimbările de rută nu sunt de dorit și pentru acest caz CR-LDP are o opțiune de fixarea a rutei. Atunci când este folosită această opțiune, LSP nu se mai poate schimba după setarea inițială.

Implementarea rutării bazate pe constrângeri se realizează prin folosire de mecanisme privind:

Schimbul de informații legate de topologie (valabilitatea și existența resurselor, starea link-urilor, atributele resurselor) între procesele rutării bazate pe constrângeri;

Managementul informațiilor legate de topologia rețelei;

Mecanisme de adaptare la cerințele (atributele) trunchiurilor de trafic.

Rutarea bazată pe constrângeri ajută la optimizarea performanțelor rețelelor operaționale, prin căutarea automată a căilor posibile care satisfac un set de cerințe pentru trunchiurile de trafic.

Deoarece LDP este un protocol peer-to-peer, care se bazează pe stabilirea și menținerea sesiunilor TCP, există în mod natural câteva avantaje pentru CR-LDP:

Mesajele CR-LDP sunt transmise în mod eficient prin intermediul TCP și informația de stare asociată cu căile LSP rutate explicit nu necesită o reîmprospătare periodică

CR-LDP are ca obiectiv principal stabilirea și menținerea LSP-urilor rutate explicit. Capabilitățile opționale sunt folosite pentru negocierea serviciilor LSP și a parametrilor de management de trafic (alocarea lărgimii de bandă, stabilirea și menținerea priorităților). CR-LDP permite modificarea acestor parametri în mod dinamic, fără întreruperi ale LSP-urilor operaționale.

CR-LDP este proiectat pentru a suporta toate tipurile de medii pe care le suportă MPLS (ATM, FR, Ethernet, PPP, etc). De aceea va funcționa la fel de bine pe rețele comutate multi-serviciu, rețele pe bază de rutere sau rețele hibride. [15]

Rezervarea de resurse și înlocuirea căilor

CR-LDP permite rezervarea resurselor pentru rute explicite. Caracteristicile unei căi pot fi descrise prin rata maximă a datelor, rata garantată, rafala maximă, rafala garantată, pondere și granularitatea. Resursele pot fi clasificate în clase sau pe culori astfel încât LSP-urile pot specifica din care clasă o rută explicită poate retrage resurse.

Dacă un LSP cere anumite resurse pentru rezervare și nu sunt suficiente pentru a satisface cererea, atunci LSP poate înlocui rute existente. Pentru aceasta, au fost asociați cu LSP doi parametri: prioritatea de setare și prioritatea de menținere. Cele două priorități reflectă preferințele pentru adăugarea unei noi rute sau pentru menținerea uneia deja existente. O rută nouă poate înlocui pe alta existentă dacă prioritatea de setare este mai mare decât prioritatea de menținere a celei existente. Valorile pentru priorități sunt cuprinse între 0 și 7, unde 0 este prioritatea asignată rutei cele mai importante, deci prioritatea cea mai mare.

2.2.5.3. Resource Reservatioin Protocol – Traffic Engineering (RSVP – TE)

Resource Reservatioin Protocol a fost inițial dezvoltat ca un protocol pentru rezervarea resurselor în rețelele IP. RSVP-TE extinde protocolul pentru a efectua distribuție de etichete și a suporta rutare explicită. Avantajul acestei implementări constă în faptul că nu toate ruterele din rețeaua MPLS trebuie să implementeze protocolul RSVP. Este suficient ca ruterele LER să implementeze un subset la acestui protocol, iar în momentul definirii unui traseu, să se contacteze celelalte rutere de pe traseu pentru a rezerva resurse.[8] [16]

Noile caracteristici adăugate includ:

Distribuția de etichete

Rutare explicită

Rezervare de bandă pentru LSP

Rerutarea LSP-urilor după defectări

Urmărirea rutei actuale a LSP

Conceptul de nod abstract

Opțiuni de înlocuire

Tunel LSP

Deși protocolul original RSVP a fost realizat să rezerve rute peste rețeaua IP, este o mare diferență între rutele rezervate în IP și LSP. În protocolul inițial o cale rezervată este întodeauna asociată cu o destinație particulară și cu un protocol de nivel transport, iar nodurile intermediare îndrumă pachetele pe baza antetului IP. Spre deosebire, cu un LSP pregătit de RSVP-TE, este posibil să implementăm un tunel drept o cale de comutație de etichete și să folosim comutația de etichete pentru rutarea pachetului prin tunel. Un asemenea tunel se numește tunel LSP.

Setul de pachete ce urmează să fie trimise prin tunelul LSP este asociat unei clase de îndrumare și fiecare LSR din tunel trebuie să asigneze o etichetă acelei clase. Criteriul de asociere a unui anumit pachet unui tunel este o problemă locală în capătul de transmisie. [9]

Pentru a putea continua cu modul de stabilire a tunelului trebuie precizat că s-au adaugat câteva atribute mesajelor RSVP, conform tabelului.

Tabel 2.1. Obiecte noi in RSVP-TE

Vom considera aceeași topologie ca la CR-LDP. Pentru a crea un tunel LSP, nodul Ingress LSR crează un mesaj PATH de tipul LSP_TUNNEL. Mesajul conține un obiect de tip LABEL_REQUEST care indică că se cere și o mapare de etichetă.

Fig. 2.7. Setarea tunelului LSP

Pentru setarea unei rute explicite, Ingress LSR trebuie să specifice ruta într-un obiect de tipul EXPLICIT_ROUTE și să-l adauge la mesajul PATH. Se mai pot adăuga obiecte de tipul RECORD_ROUTE care pot fi folosite pentru a cere notificări despre modificările survenite asupra rutei sau detectarea buclelor. Controlul adițional (înlocuire, prioritate, protecție și diagnostic) se poate realiza prin introducerea atributului SESSION_ATTRIBUTE în mesajul PATH.

Odată construit mesajul PATH, Ingress LSR îl trimite următorului hop specificat în ruta explicită. Dacă nu există obiect de tipul EXPLICIT_ROUTE decizia următorului nod se face în fiecare hop. LSR primește mesajul, îl modifică corespunzator și îl trimite mai departe. Egress LSR întoarce un mesaj de tipul RESV cu obiectul LABEL (22) înapoi la sursă, folosind calea creată de mesajul PATH dar în sens invers. Asemenea procedează și LSR când primește mesajul RESV și ruta este stabilită când ajunge eticheta la nodul Ingress LSR.

Rerutarea tunelelor LSP

Un tunel LSP se poate reruta pentru a optimiza utilizarea resurselor rețelei sau pentru a restaura conectivitatea după defecțiuni ale rețelei.

RSVP-TE folosește o tehnică numită construiește înainte de a strica pentru a minimiza întreruperea fluxurilor de trafic în timpul rerutării. Așadar, în vederea rerutării se construiește întâi noul tunel LSP, se comută pe acesta și apoi cel vechi este închis. Însă, în timpul tranziției, cele două tunele coexistă și concurează pe aceleași resurse pe segmentele pe care le au în comun. Noul tunel nu se poate stabili deoarece cel vechi nu a eliberat resursele iar cel vechi nu le poate elibera deoarece cel nou nu a fost creat. Pentru rezolvarea acestei probleme trebuie să ne asigurăm că nu se ocupă de două ori aceleași resurse, și acest lucru se face prin folosirea resurselor în comun pe linkurile comune.

Extensia RSVP-TE permite rezervarea de resurse prin stabilirea de căi cu comutare de etichete în rețele MPLS. Tunelele LSP permit implementarea de politici variate în ceea ce privește optimizarea performațelor rețelei (ingineria traficului permite optimizarea performanțelor rețelelor operaționale). Ceea ce introduce nou ingineria traficului este posibilitatea definirii căilor de transmitere a pachetelor introducând constrângeri de rutare în raport cu gradul de încărcare și starea rețelelei.

2.2.6. Stabilirea rutei și rutarea explicită

În procesul de stabilire a căii, un LSR trebuie să determine care este următorul hop pentru calea pe care încearcă s-o stabilească. Sunt două metode de bază în scopul acesta: rutare hop cu hop și rutare explicită.

Rutarea hop cu hop se bazează pe informația de rutare din IP pentru a seta LSP. Modulul de control MPLS va apela în fiecare nod modulul de rutare care alege în mod independent următorul hop bazându-se pe rutarea IP sau alte metode de rutare.

În rutarea explicită, un singur nod, în general ingress sau egress al căii, specifică întreaga rută pentru LSP. Rutele pentru căi pot fi căutate de algoritmi de rutare desemnați să asigure anumiți parametri. Astfel de rutare este numită rutare bazată pe constrângeri (Constraint-Based Routing). Dacă întreaga rută este specificată, atunci LSP este strict explicită, dar dacă numai o porțiune este precizată expres atunci calea este explicită în sens larg.

Rutarea explicită este una din cele mai importante caracteristici ale MPLS, deoarece permite stabilirea sau modificarea unor căi de rutare luând în calcul starea de încărcare a rețelei, ceea ce conduce la o utilizare mai bună a rețelei și la creșterea calității serviciilor. Un astfel de mecanism lipsea în rețele IP clasice.

2.3. Clase de echivalență de îndrumare – (FEC – Forwarding Equivalence Class)

O clasă de îndrumare de echivalență (FEC – Forwarding Equivalence Class) este un grup de pachete care sunt trimise pe aceeași cale și sunt tratate la fel. Toate pachetele aparținând aceluiași FEC au aceeași etichetă. Însă nu toate pachetele care au aceeași etichetă aparțin aceluiași FEC. LSR ingress este cel care decide care pachete aparțin unei anumite clase deoarece acesta este primul nod pe care îl întâlnesc pachetele atunci când traversează rețeaua MPLS.

Cele mai întâlnite tipuri de clase de echivalență includ:

Ruterul egress (identificatorul ruterului) – o clasă folositoare este aceea de a include toate pachetele care merg către același nod de ieșire.

Prefix IP – pachetele cu prefixul adresei destinație identic cu cel din tabela de rutare sunt considerate aparținând aceleiași clase FEC. Acest tip de mapare directă permite MPLS să suporte îndrumarea bazată pe destinație din IP. Un avantaj al unei asemenea clase este că distribuția de etichete poate fi cuplată cu rutarea IP.

Fluxuri de aplicații (perechi adresă sursă – adresă destinație) – acest tip de clasă este cel mai fin grad de granularitate care se poate obține din moment ce fiecare flux de aplicație este o clasă FEC. Este cel mai puțin scalabil tip, dar are avantajul că oferă control capăt la capăt maxim pentru trafic. [17]

Se dă o bătălie între scalabilitate și control. Abilitatea MPLS de a suporta multiple tipuri de clase cu granularități diferite îi oferă o mare flexibilitate în acomodarea diferitelor cerințe și combinarea diferitelor necesități în aceeași rețea.

2.4. Funcționarea MultiProtocol Label Switching

2.4.1. Nodurile de graniță

Sunt două categorii de LSR. La marginea rețelei, avem nevoie de clasificări de pachete de mare viteză care pot aplica (și îndepărta) etichetele necesare. În centrul rețelei, nodurile LSR trebuie să poată procesa pachetele etichetate pentru lărgimi de bandă extrem de mari.

Ruterele de la granița unui domeniu MPLS sunt numite Label Edge Router (LER). Un LER termină și/sau originează o cale LSP și realizează îndrumarea bazată pe etichete.

La intrarea într-un domeniu, LER ingress acceptă pachete neetichetate și creează un antet MPLS prin introducerea (pushing) uneia sau mai multor câmpuri de etichete „MPLS Label”. Prin procesarea pachetului IP convențional, la intrarea într-o rețea MPLS, se determină FEC și deci contextul unei noi stive de etichete MPLS a pachetului, urmată de introducerea pachetului etichetat în coada de așteptare. Odată etichetate, pachetele sunt transmise în rețeaua nucleu (Core) prin calea definită anterior, folosind în acest scop protocolul LDP. Informația de îndrumare este obținută din tabelul de îndrumare.

La ieșirea din domeniul MPLS, un LER egress termină o cale LSP prin extragerea (popping) elementului din vârful stivei de etichete și îndrumă pachetul rămas pe baza regulilor de îndrumare clasică.

Ruterele de comutație LSR hibride pot origina sau termina unele LSP-uri, în timp ce acționează ca punct de tranzit pentru alte LSP-uri. LSR poate realiza ambele funcții simultan când suportă tunelarea unui LSP în interiorul altui LSP. La intrarea într-un astfel de tunel, LSR pune o nouă intrare în vârful stivei de etichete (push) care există în pachetul recepționat. La ieșirea din tunelul LSP, eticheta din vârful stivei este extrasă și LSR controlează îndrumarea pe baza noii etichete din vârful noii stive. Tunelarea unui LSP în alt LSP face ca o rețea MPLS să apară ca un singur hop în cadrul altei rețele MPLS.

Ruterele de graniță sunt de asemenea responsabile și de condiționarea traficului, care, conform definiției DiffServ, include clasificarea pachetelor asociate unui LSP particular și aplică politici de control al traficului la intrare, care trebuie să se încadreze în cerințele SLA pentru traficul care merge pe LSP-uri particulare pentru a realiza obiectivele serviciului global.

Dacă rețeaua MPLS suportă controlul în profil/în afara profilului, atunci LER trebuie să măsoare rata pachetelor care intră în rețea (meter) și să realizeze condiționarea traficului conform mecanismului QoS DiffServ (remarcare, întârziere, aruncare).

2.4.2. Label Switching Path (LSP)

Atribuirea unui pachet la o clasă de echivalență se face o singură dată, la intrarea pachetului în domeniul MPLS, mai explicit în nodul ingress. Clasa din care face parte pachetul este codată printr-o etichetă. Când pachetul este trimis spre următorul hop, eticheta este atașată în câmpul special din antetul MPLS, și astfel pachetul este considerat etichetat.

MPLS folosește eticheta din pachete pentru a identifica o cale numită LSP (Label Switching Path) între ruterul de intrare ingress și cel de ieșire egress. La primirea unui pachet etichetat, ruterul folosește eticheta ca index la propriul tabel de îndrumare (de comutație) pentru a determina drumul pe care să îndrume pachetul la destinație, adică următorul hop, și eticheta care o va schimba pe cea veche, pentru a se folosi de ea următorul nod în scopul dirijării pachetului.

Ruterul de intrare ingress al rețelei MPLS folosește adresa destinație a pachetelor pentru a determina LSP-ul folosit. În interiorul rețelei, ruterele MPLS folosesc numai etichetele pentru pentru îndrumarea pachetelor spre egress.

Multi Protocol Label Switching necesită un set de proceduri (protocoale) pentru a adăuga pachetelor de nivel rețea o etichetă (sau o stivă de etichete). Ruterele care suportă MPLS sunt cunoscute sub numele de LSR (Label Switching Router) sau ruter cu comutație de etichete.

Deoarece MPLS folosește doar eticheta pentru îndrumarea pachetelor, este independent de protocol, din acest motiv existând denumirea de Multi Protocol în MPLS. [10]

2.4.3. Procesarea pachetelor în ruterele interne

Label Switching Path nu trebuie neapărat să urmeze calea cea mai scurtă dintre două rutere de graniță LER. MPLS înlocuiește îndrumarea pe calea cea mai scurtă fără conexiune cu îndrumarea bazată pe comutația de etichete. Deși protocoalele de rutare IP convenționale nu generează rute pentru căi care nu sunt cele mai scurte, totuși pot fi folosiți algoritmi de rutare externi pentru a determina noi rute în vederea unei distribuții optime a sarcinii prin rețea. Această caracteristică este un avantaj major pentru MPLS peste DiffServ.

Din perspectiva QoS, etichetele MPLS simplifică procesul de clasificare, care este realizat numai în ruterele de graniță. Ruterele LSR pot face uz de toate tehnicile Qos: metering, policing, marking, queuing, scheduling. În nodurile interne, eticheta MPLS furnizează contextul necesar determinării următorului hop și a regulilor de tratare a pachetelor impuse de QoS solicitat.

Tabelul de îndrumare conține include adresa următorului hop asociată etichetei pe care o recunoaște LSR și o nouă etichetă, necesară nodului următor pentru îndrumarea pachetului, etichetă care se va include în antetul pachetului transmis în locul celei din pachetul recepționat. Fiecare intrare a tabelului de îndrumare poate conține reguli de procesare care se aplică pachetelor care sosesc cu o valoare particulară a etichetei.

În fiecare LSR sunt implementate funcții de management care sunt responsabile cu definirea și actualizarea informațiilor din tabela de comutare, pentru toate valorile etichetelor MPLS: a etichetei următorului hop, a portului de ieșire, a modului de introducere în cozile de așteptare și a regulilor de planificare. Intrările tabelului sunt modificate ori de câte ori o nouă etichetă necesită activare sau etichetele vechi trebuie eliminate.

Un LSP particular este asociat cu un FEC particular. Cand există cerințe QoS, sunt luate în calcul următoarele politici referitoare la introducerea în cozile de așteptare (queuing) și la planificarea (scheduling) extragerii pachetelor din cozi:

Asocierea unui FEC la un LSP permite definirea de cozi de așteptare distincte și comportarea planificatorului, ignorând câmpul experimental. Câmpul „label” poate furniza contextul care permite determinarea parametrilor pentru „queuing” și „scheduling”. Cu această abordare sunt posibile 220 combinații per hop și per cale. Totuși comportarea per hop este strâns asociată cu o cale LSP specifică, deoarece întregul câmp „label” este folosit de asemenea pentru pentru a determina următorul hop și contextul căii.

Câmpul experimental din antetul MPLS poate codifica până la 8 comportări diferite pentru „queuing” și „scheduling” pentru aceeași clasă FEC (LSP).

O rețea MPLS care folosește informația de cale (câmpul Label) ca parte a contextului pachetului, poate avea un control mai fin asupra partajării resurselor per hop decât într-o rețea DiffServ.

Valoarea „MPLS Label” este o versiune comprimată a informației derivate din clasificarea din nodul ingress al rețelei. Dacă Edge LSR clasifică fluxurile individuale și le asociază LSP-uri proprii, atunci valoarea Label permite unui Core LSR să cunoască contextul și să poată diferenția pachetele la nivel de flux. Beneficiul este că în ruterele Core nu trebuie să se mai facă clasificare.Aceste rutere folosesc antetul MPLS pentru a defini comportarea per-hop.

2.5 Concluzii

MPLS folosește o tehnică numită comutație de etichete. Cu aceasta, pachetele sunt îndrumate pe baza unei etichete scurte, de lungime fixă. Natura orientată pe conexiune a comutației de etichete oferă rețelelor IP importante capabilități care până acum au fost indisponibile. MPLS a ajutat la integrarea rețelelor IP peste ATM, a simplificat îndrumarea pachetelor și a oferit un mecanism critic pentru ingineria traficului în Internet și anume rutarea explicită.

Înaintea transmiterii pachetelor, MPLS trebuie să creeze un LSP. Standardul MPLS folosește un protocol de distribuție a etichetelor pentru a seta o rută, protocol care la rândul lui se bazează pe un protocol de rutare IP cu rol de descoperire a topologiei. Mai există o variantă în care rutele sunt explicit create, indicându-se de către un sistem de management al rețelei nodurile prin care trebuie să treacă calea.

Ruterele de graniță au responsabilitatea de mapare a pachetelor la o clasă. MPLS permite ca mai multe etichete să fie înscrise într-un pachet formând o stivă de etichete. Stiva este formată din intrări a câte 32 de biți fiecare, din care un câmp de 20 de biți este pentru etichetă. Antetul MPLS este introdus între antetul de nivel trei IP și cel de nivel doi.

Trei protocoale de distribuție a etichetelor au fost standardizate: LDP, CR-LDP și RSVP-TE. LDP este utilizat în principal pentru a efectua rutare hop-cu-hop, pe când celelate două sunt realizate pentru rutare explicită ca suport pentru ingineria traficului. Deși CR-LDP și RSVP-TE au multe asemănări, există diferențe importante în uzul mecanismelor de transport și de păstrare a stărilor.

3. MPLS suport pentru DiffServ

3.1. Introducere

Creșterea exponențială continuă a Internetului a pus o mare solicitare pe rețelele furnizorilor de servicii. Cuplat cu această creștere, mai există și un avânt puternic al noilor aplicații precum comerț electronic, voce și servicii multimedia care cer o lărgime de bandă mai mare și garanții de calitate mai stricte. Mărirea capacității rețelei este o idee costisitoare, așa că furnizorii caută arhitecturi care să le ofere mai mult control asupra traficului care traversează domeniul lor și astfel să asigure performanțe optime cu creșteri minime de resurse.

MPLS este o tehnologie de comutație de etichete cu caracteristici puternice de ingineria traficului precum specificarea rutelor explicite, înlocuirea rutelor și rerutarea rapidă. De cealaltă parte, Serviciile Diferențiate oferă calitate a serviciilor la nivel de nod prin agregarea traficului în clase și comportamente de agregare (BA) care primesc tratamentul adecvat în cadrul domeniului DiffServ.

Deși MPLS și DiffServ sunt tehnologii independente, se completează una pe cealaltă chiar foarte bine. Privind în ansamblu, MPLS este folosit pentru a transporta pachete dintr-un loc în altul printr-o serie de hopuri de-a lungul unei căi pre-selectate, în timp ce DiffServ este folosit să se asigure că pachetele primesc tratamentul adecvat la fiecare hop. Astfel DiffServ suprapus peste MPLS poate furniza în general garanții mai bune prin asigurarea QoS atât la nivel de nod cât și la nivel capăt la capăt.

3.2. DiffServ și MPLS

DiffServ a apărut ca o soluție mai simplă pentru calitatea serviciilor deoarece implementarea IntServ și RSVP era dificilă. Principalul scop al DiffServ era să întrunească condițiile utilizatorului, mecanismele DiffServ permițând furnizorilor de rețea să aloce diverse nivele de servicii diferiților utilizatori. Pentru a beneficia de servicii diferențiate, utilizatorii trebuie să încheie un contract (SLA) cu furnizorul de Internet.

Arhitectura DiffServ este compusă din câteva unități funcționale implementate în nodurile rețelei, în special cele de intrare și de ieșire. Acestea realizează clasificarea pachetelor și funcțiile de condiționare a traficului: măsurare, marcare, întârziere și aruncare. Ele împreună definesc PHB.

Traficul care intră într-un domeniu diferențiat pe servicii este clasificat în comportamente de agregare (BA), bazate pe codul DSCP, care include un câmp de șase biți numit câmp TOS. În interiorul domeniului DiffServ, un pachet este îndrumat în concordanță cu BA-ul său. Acest tratament de îndrumare aplicat unui agregat de trafic este numit comportament per hop (PHB).

Există două tipuri standard de PHB:

Îndrumare Expeditivă (EF – Expedited Forwarding) cu care avem cea mai mare prioritate pentru servicii cu latență scăzută, așa cum sunt pachetele de voce, video, streaming online

Îndrumare Asigurată (AF – Assured Forwarding) unde întâlnim patru clase, cu AF1 având cea mai mare prioritate și AF4 cea mai mică, apropiată de modelul Best Effort din IP. La rândul lor, în fiecare clasă AFx, mai există trei nivele de prioritate de aruncare a pachetelor (DP – Drop Precedence), subclasa DP1 având cea mai mică probabilitate de aruncare iar DP3 cea mai mare.

MPLS simplifică îndrumarea pachetelor prin formarea căilor cu comutație de etichetă (LSP) care acționează ca un tunel virtual. În interiorul domeniului MPLS, un pachet este mai întâi clasificat în o clasă de echivalență de îndrumare (FEC) și bazat pe aceasta este asignată o etichetă cu semnificație locală în nodul ingress. La următoarele hopuri, nu se mai efectuează nici o inspecție asupra antetului de nivel rețea ca în IP, și pe baza etichetei ca index la tabelul de comutație al fiecărui nod se face schimb de etichete și se trimite pachetul mai departe spre destinație. [10]

Atunci când un pachet DiffServ sosește într-o rețea MPLS, nodul ingress examinează câmpul TOS din antetul IP să caute informația DiffServ (DSCP) și astfel, traficul este asignat LSP-ului corespunzător. MPLS poate mapa traficul DiffServ la traficul MPLS în mai multe moduri. Mai multe BA pot fi asignate unui singur LSP sau un singur BA cu un singur LSP. Când multiple comportamente folosesc același LSP, câmpul EXP din antet MPLS specifică PHB-urile. Această metodă se numește EXP-Inferred-PSC LSP (E-LSP). În cazul în care este o mapare de tip unu la unu se numește Label-only-Inferred-PSC LSP (L-LSP). PSC vine de la PHB Scheduling Class și reprezintă setul de unu sau mai multe comportamente PHB care pot fi aplicate unui agregat de comportament (BA). De exemplu, AF1 este PSC pentru AF11, AF12, AF13. EF este un exemplu cu un singur PHB pentru PSC-ul EF.

E-LSP: dacă o rețea are până la 8 PHB, biții EXP sunt suficienți pentru acea rețea. Un LSR conține o tabelă cu mapările între valorile EXP și comportamentele PHB, similar cu un LER care ține mapările între DSCP și PHB. În acest caz, eticheta dictează ruterului LSR ce cale LSP să folosească, iar câmpul EXP dictează ce comportament trebuie aplicat pachetelor. Pentru E-LSP, nu este nevoie de semnalizare adițională deoarece PHB este înglobat în eticheta MPLS. O problemă este faptul că DiffServ poate avea 64 de valori posibile pentru DSCP, iar MPLS poate acoperi doar 8 dintre acestea.

L-LSP: un LSP separat poate fi stabilit pentru o singură combinație FEC-BA. În acest caz, ruterul LSR deduce atât calea cât și tratamentul pachetului din etichetă. Câmpul EXP codifică nivelul de precedență al pachetelor.

3.3. Rezervarea benzii pentru E-LSP și L-LSP

Indiferent de protocolul de distribuție a etichetelor utilizat, căile E-LSP și L-LSP pot fi stabilite cu sau fără rezervarea benzii.

Stabilirea unei rute cu bandă rezervată înseamnă că cererile legate de lărgimea canalului pentru LSP sunt semnalizate în faza de stabilire. Asemenea cerințe pot fi folosite de LSR-uri la momentul stabilirii pentru a controla admisia LSP-urilor semnalizate ținând cont de resursele DiffServ pe care le furnizează. De asemenea, se pot efectua ajustări ale resurselor DiffServ asociate cu clase de PHB, ca de exemplu ajustarea gradului de libertate pentru cozile de pachete la aruncare și transmitere. Însă aceste modificări nu trebuie să afecteze tratamentele de îndrumare așa cum sunt definite de către PHB.

Este important de știut că cerințele de bandă semnalizate pentru un L-LSP vor fi asociate cu grupul de PHB-uri asociat căii. Așadar, LSR-urile care vor efectua controlul admisiei vor controla admisia resurselor dedicate clasei de PHB (PSC). La fel se procedează și în cazul E-LSP-urilor, banda semnalizată este asociată colectiv cu întreg LSP-ul și deci întreg setul de PSC-uri transportate.[10] [12] [18]

3.4. Îndrumarea bazată pe etichetă

Comutația de etichete este realizată cu ajutorul unei tabele, numită Incoming Label Map (ILM), în care fiecare etichetă recepționată cu un pachet este asociată cu una sau mai multe intrări numite NHLFE (Next Hop Label Forwarding Entry). Pentru pachete fără etichetă există o tabelă FEC-To-NHLFE Map (FTN), unde fiecare clasă de echivalență FEC corespunde unei sau mai multe NHLFE.

Contextul DiffServ pentru o etichetă se compune din:

Tipul LSP (E-LSP, L-LSP)

Comportamentele suportate PHB

Tabela generică Encapsulare -˃ PHB pentru o etichetă recepționată

Tabela generică Set de PHB-uri -˃ Encapsulare pentru o etichetă transmisă

Tabelele IML și FTN conțin toate informațiile necesare pentru contextul DiffServ. Fiecare NHLFE are date despre cum trebuie tratat un pachet când sosește într-un LSR. Contextul DiffServ se stabilește în sesiunea de schimb de etichete de la începutul formării căilor LSP. Comportamentele PHB sunt fie predefinite, fie semnalizate pentru E-LSP; pentru L-LSP ele sunt din setul standard care definesc o grupă de PHB, semnalizată la setarea LSP-ului.

Avantajul existenței a mai multor intrări NHLFE pentru o singură etichetă este acela că putem efectua load balancing pe mai multe căi de costuri diferite, uniformizând astfel traficul pe toate rutele. Alegerea unei căi se face pe baza contextului DiffServ astfel încât să fie suportat PHB-ul de plecare al pachetului de îndrumat. Dacă există mai multe rute care acceptă tratamentul PHB indicat de context se poate face load balancing. [17]

3.5. Modele de tunele DiffServ peste MPLS

Există și asemănări și deosebiri între tunelele IP și căile LSP din MPLS. Totuși căile LSP nu sunt o formă de tunele IP deoarece nu conțin antet IP dar sunt o formă de tunel. Din punct de vedere al DiffServ, LSP-urile au câteva caracteristici în comun cu tunelele IP:

Nodurile intermediare văd și operează numai cu învelișul exterior al tunelului

Ambele sunt unidirecționale

Informația exterioară poate fi modificată de către nodurile intermediare

Însă, din punct de vedere al DS, LSP au o proprietate distinctivă comparată cu tunelele IP. În general, nu există comportament asemănător Penultimate Hop Popping (PHP) la tunelele IP. Mai mult, din cauza PHP, informația exterioară a tunelului nu este vizibilă nodului de ieșire, egress. În situații când acest lucru nu este necesar, nu este o problemă, dar când este folositoare nodului egress, trebuie transportată în alte moduri. [19]

3.6. Extensia RSVP pentru suportul DiffServ

Standardul MPLS nu precizează un protocol specific de semnalizare a etichetelor. Protocolul RSVP a fost adaptat pentru acest lucru și mai mult pentru crearea de căi LSP cu servicii diferențiate.

Față de protocolul original, RSVP a introdus în mod special un atribut numit DIFFSERV, aplicabil numai mesajelor de tip Path. Se folosește la stabilirea tunelelor LSP, dar nu este obligatoriu decât în cazul în care trebuie semnalizate mapările EXP -˃ PHB. Două tipuri de obiecte DIFFSERV sunt posibile corespunzător celor două tipuri de LSP-uri: E-LSP și L-LSP. Alegerea tipului se face într-un alt obiect, SESSION.

Obiectul DiffServ pentru E-LSP conține:

Un câmp rezervat de 28 de biți (setat 0 la transmisie);

Un câmp MAPnb de 4 biți care indică câte intrări de asociere conține obiectul (0-8)

Mai multe intrări care asociază un câmp EXP cu un PHB. O intrare MAP conține:

13 biți rezervați;

Câmp EXP – valoarea EXP din asociere (3 biți)

PHBID – identificatorul PHB-ului din asociere (16 biți).

Obiectul DiffServ pentru L-LSP conține:

un câmp rezervat (16 biți);

un câmp PSC care identifică grupul de PHB suportat de LSP (16 biți)

Pentru stabilirea unui tunel LSP cu RSVP, transmițătorul creează un mesaj Path cu un atribut Session și unul Label Request. Crearea unui tunel LSP de tipul E-LSP se poate realiza cu mapări EXP -˃ PHB predefinite odată fără obiectul DiffServ sau alternativ cu obiectul DiffServ dar fără intrări de tip MAP. În cazul cu mapărilor explicite se folosește obligatoriu un obiect DiffServ cu intrări MAP care să precizeze comportamentele PHB. În cazul mai multor obiecte DiffServ numai primul este relevant, celelalte fiind ignorate. Dacă în mesajul Path există un obiect DiffServ pentru L-LSP se consideră că este o cerere pentru setarea unui L-LSP. Nodul care recepționează mesajul răspunde cu un mesaj Resv cu eticheta cerută. [19] [17]

În cazul în care se recepționează un mesaj care conține un obiect DiffServ, dar nu conține un obiect Label Request sau Sesiune, nodul transmite înapoi un mesaj de eroare cu un cod ce informează cauza erorii. Tipurile de mesaje de eroare și codurile aferente sunt:

Tabel 3.1. Mesaje de eroare

3.7. Concluzii

Serviciile diferențiate furnizează un mod simplu de a categoriza și prioritiza agregatele de trafic ale rețelei. MPLS este suportul cel mai adecvat pentru acest lucru, având în vedere avantajele ambelor tehnologii și caracteristicile comune. Se realizează o legătura între căile LSP și agregatele de trafic BA, prin corespondențe între comportamentele PHB și biții din câmpurile EXP și LABEL ale antetului MPLS. Ruterele LSR DiffServ îndrumă pachetele conform tabelei ILM, în care pentru fiecare etichetă există un context DiffServ în concordanță cu tratamentul de trafic aplicat fluxului.

Două tipuri de căi s-au definit pentru transportul pachetelor, fiecare dintre ele având avantaje și dezavantaje. În combinație pot asigura un număr mare de clase de îndrumare îndeplinind cerințele de calitate impuse.

4. Ingineria Traficului

4.1. Introducere

Noțiunea de inginerie de trafic a apărut încă de la primele rețele inventate. Aceasta se referă la arta de a face eficientă utilizarea resurselor de rețea fiind dată o topologie de rețea și un set de fluxuri de trafic. Cu alte cuvinte, obiectivul fundamental al ingineriei traficului este de a ruta trafic, astfel încât să se evite congestionarea rețelei și de a crește capacitatea rețelei de a absorbi maximul de trafic. Pentru a îndeplini un astfel de obiectiv, se pot folosi mai multe tehnici de inginerie de trafic, dintre care una este ingineria traficului bazat pe MPLS. [20]

Cel mai bun mod de a introduce Ingineria Traficului MPLS este prezentarea ilustrației "Problema Peștelui".

Rutarea IP se bazează pe conceptul fundamental de rutare bazată pe destinație. Așa cum se arată în figura 4.1, când cele două fluxuri de trafic provenite de la ruterele R8 și R1 spre R5 ajung la routerul R2, ele urmează calea cea mai scurtă (calea furnizata de protocolul de rutare interior), deoarece pachetele IP sunt rutate în mod implicit pe baza adresei IP a destinației lor. În acest exemplu, cele două fluxuri urmeze calea R2R3R4R5. În cazul în care suma traficului de la aceste două fluxuri depășește capacitatea rețelei pe această cale, acest lucru duce inevitabil la congestionarea rețelelor. Această congestie poate fi evitată prin rutarea a o parte din trafic pe cealaltă cale disponibilă R2R6R7R4R5.

Fig. 4.1. „Problema Peștelui” [2]

Într-o astfel de rețea simplă, este ușor să se adapteze măsurătorile IGP (Interior Gateway Protocol), astfel încât să se balanseze traficul între cele două căi disponibile (care în mod normal, trebuie să aibă costuri egale). Cu toate acestea, rețelele sunt mult mai complexe și optimizarea metrici IGP nu este atât de simplă și nu poate oferi întotdeauna nivelul de granularitate necesar.

O altă opțiune este de a dezvolta Ingineria Traficului MPLS, care oferă un set bogat de caracteristici cu o granularitate foarte mare pentru a putea inginerii traficul eficient într-o rețea MPLS / IP.

4.2. Componentele Ingineriei Traficului MPLS

Ideea fundamentală a MPLS TE este să se poata folosi o cale de comutare de etichete cu ingineria traficului (LSP TE sau tunel) pentru a transmite trafic în rețea, luând în considerare o serie de constrângeri, topologia rețelei și a resurselor disponibile, cu obiectivul de a face eficientă utilizarea rețelei.

Pe scurt, atributele LSP TE (constrângeri) determină caracteristicile dorite de LSP (între sursă și destinație). Atributele LSP TE sunt:

Destinație;

Lărgime de banda;

Afinități;

Preempțiune;

Protecție prin redirijarea rapidă (Fast Reroute);

Metrică optimizată.

4.2.1. Destinația

Sursa LSP TE este router-ul unde LSP TE a fost configurat, în timp ce destinația trebuie să fie configurată în mod explicit.

4.2.2. Largimea de bandă

Unul din atributele unui LSP TE este, evident, lățimea de bandă necesară pentru LSP TE. Mai multe metode pot fi folosite pentru a estima cerința de lățime de bandă. Modul cel mai evident este acela de a obține o matrice de trafic între routerele implicate într-o plasă de LSP-uri TE. Acest lucru poate fi realizat prin intermediul unor instrumente diferite, cum ar fi NetFlow de la Cisco. De asemenea, este de remarcat faptul că unele tehnici mai recente se bazează pe măsurarea utilizării link-ului pentru a calcula matricea traficului. Cu toate acestea, astfel de metode furnizează doar estimări a căror exactitate este variabilă și variază foarte mult in funcție de topologia rețelei.

Modelul fluxului de trafic între două puncte este rareori o constantă și este de obicei în funcție de ora din zi, ca să nu vorbim de creșterea traficului generată de introducerea unor noi servicii în rețea sau doar o utilizare a serviciilor existente acumulată. Prin urmare, este responsabilitatea administratorului de rețea să determine cerința de lățime de bandă între două puncte și cât de des ar trebui să fie reevaluată. Putem adopta o abordare foarte conservatoare, luând în considerare X la sută din vârful de trafic sau o medie a valorilor lățimii de bandă. După ce se determină cerința de lățime de bandă, putem aplica o rație mai mare sau mai mică, în funcție de obiectivele generale. O altă abordare constă în a ne baza pe rutere pentru a calcula lățimea de banda necesară bazată pe traficul observat trimis către un anumit LSP. LSP-ul este setat cu o valoare prestabilită (care poate fi 0), iar ruter-ul păstrează monitorizarea volumul de trafic trimis la destinație pe LSP-ul respectiv. Pe un ruter Cisco, o astfel de capacitate se numește autobandwidth. Aceasta oferă o mare flexibilitate prin intermediul mai multor parametrii, configurabili: frecvența de eșantionare (frecvența la care lățimea de bandă este eșantionată), frecvența cu care se redimensionează un LSP, și valorile minime și maxime pe care un LSP le poate lua. De exemplu, ruterul poate proba cantitatea de trafic trimis la fiecare 30 de minute, se selectează valoarea de vârf, și se redimensionează LSP-ul nu mai frecvent decât o dată pe zi, cu constrângerea de a fi mereu între 30 Mbps (valoarea minimă) și 200 Mbps (valoarea maximă). Acest lucru oferă flexibilitate ridicată pentru administratorul de rețea, care poate determina cele mai adecvate compromisuri între adaptarea cererii la cerința de lățime de bandă reală și stabilitatea rețea (cât de des ar trebui un LSP să fie redimensionat). [10]

4.2.3. Afinități

Un indicator pe 32 de biți care trebuie să se potrivească cu setul de link-uri pe care un LSP le traverseaza reprezintă afinitățile. Într-un cuvânt, acest lucru poate fi văzut ca o schemă colorată (cu până la 32 de culori). Fiecare link din rețea poate avea, de asemenea, până la 32 de culori. S-ar putea să fie de dorit, în anumite circumstanțe, să ne asigurăm că un LSP traverseaza exclusiv link-uri de culori specificate. Spre exemplu, considerarăm o rețea cu un amestec de legături terestre și prin satelit. Ele diferă în principal prin întârzierea cu care se propagă (care este semnificativ mai mare pentru link-uri prin satelit). Prin urmare, administratorul de rețea poate decide să coloreze aceste link-uri (prin setarea unu bit specific din campul de afinitate pe 32 de biți). [10]

4.2.4. Preempțiune

Noțiunea de preempțiune se referă la capacitatea de a defini până la șapte niveluri de prioritate. Aceasta permite unui LSP cu o mai mare prioritate să prevină un LSP cu o prioritate mai mică în cazul în care ambele LSP-uri nu pot fi introduse pe link din cauza lipsei de resurse de lățime de bandă.

De exemplu, să presupunem că un LSP T1 de prioritate X1 nu poate fi stabilit de-a lungul unei căi specifice, deoarece alte trei LSP-uri T2, T3, și T4 care au, respectiv prioritățile X2, X3, X4 <X1 . Deoarece T1 are o prioritate mai mare, se poate să prevină orice LSP de prioritate mai mică pentru a se potrivi cerințelor sale de lățime de bandă. Este de reținut că un număr redus de preemptiune indică o preempțiune mare (preempțiune 0 corespunde cu cea mai mare prioritate). [10]

4.2.5. Protecție prin redirijarea rapidă

Ingineria Traficului MPLS prevede un sistem eficient de protecție locală numit Fast Reroute pentru a redirija rapid LSP-urile printr-un tunel de rezervă presemnalizat în câteva zeci de milisecunde. Un astfel de sistem de protecție local poate fi folosit pentru unele LSP-uri care necesită redirecționare rapidă în cazul unui eșec în rețea și este semnalat ca un atribut al LSP. Cu alte cuvinte, este posibil atunci când se crează un LSP să se ceară în mod explicit protecția prin Fast Reroute pentru LSP-ul respectiv ori de câte ori opțiunea de Fast Reroute este disponibilă pe ruterul traversat. Acest lucru vă permite să definiți diferite clase de recuperare, în care unele LSP-uri sunt redirecționate în conformitate cu procedurile normale de MPLS Traffic Engineering și alte LSP-uri să beneficieze de recuperare rapidă prin redirijarea rapidă. [10]

4.2.6. Metrică optimizată

Noțiunea de calea cea mai scurtă este întotdeauna legată de o anumită metrică. De obicei, într-o rețea IP, fiecare link are o metrică, și calea cea mai scurtă este calea a cărei sumă a metricelor link-urilor de-a lungul căi este minimă.

MPLS TE folosește, de asemenea, măsurători pentru a alege calea cea mai scurtă pentru un tunel care satisface constrângerile specificate. MPLS TE a introdus propria metrică. Când MPLS TE este configurat pe un link, router-ul poate denunța două metrici pentru un link: metrica protocolului de rutare și metrica TE (care poate sau nu poate fi aceeași).

Luăm în considerare cazul în care avem link-uri cu lățime de bandă și întarziere de propagare diferite. Având în vedere acest lucru, ar putea fi avantajoasă reflectarea fiecărei proprietăți prin intermediul unei metrice diferite. Metrica IGP ar putea, de exemplu, reflecta lățime de bandă, în timp ce metrica TE ar fi o funcție de întârzierea de propagare. De exemplu, calea cea mai scurtă pentru un LSP care are trafic de voce ar putea fi calea care oferă o întârziere de propagare cât mai mică. În schimb, calea calculată pentru LSP-uri care transportă cantități mari de trafic de date va fi determinat cu obiectivul de a traversa link-uri de mare viteză. Este de reținut că actuala implementare Constraint Shortest Path First (CSPF) încearcă calcularea căi cea mai scurte bazându-se pe una dintre cele două metrice (IGP sau TE). [10]

4.3. Calcularea căii LSP TE

Există două opțiuni pentru a calcula o cale TE LSP: offline sau online. Cu calcul căii offline, un instrument offline este folosit pentru a calcula calea pentru fiecare LSP TE, ținând seama de constrângerile și atributele (cum ar fi lățime de banda, afinități, optimizarea metricii, exercitarea dreptului de preempțiune), topologia rețelei, și a resurselor. Deoarece calcul este efectuat simultan pentru toate LSP-urile din rețea, uneltele offline încerca să realizeze o rețea globală de optimizare cu criterii multiple, cum ar fi utilizarea maximă a link-ului, întarziere de propagare minimă și cu obiectivul de maximizare a valorii traficul pe care rețeaua îl poate transporta. Acest lucru poate fi realizat datorită unei imagini de ansamblu a caracteristicilor rețelei și cererilor de trafic. Apoi, LSP-urile TE sunt descărcate în fiecare ruter headend corespunzător.

Cea de a doua metodă de calcul se bazează pe calcularea distribuită a căii, prin care fiecare ruter este responsabil pentru calculul căii pentru LSP-ul TE pentru care este headend. Nici un server central nu calculează calea LSP TE în rețea. Un algoritm foarte bine cunoscut pentru calculul LSP-urilor TE este algoritmul CSPF. CSPF calculează calea cea mai scurtă care satisface un set de constrângeri specificate. De exemplu, toate link-urile care nu satisfac cerința de lățime de bandă sau de afinitate pentru un LSP TE sunt șterse din topologia rețelei. Apoi, algoritmul Dijkstra calculeaza calea cea mai scurtă din subgraful rezultat.

Modulul de calcul a căii trebuie să învețe lățimea de bandă disponibilă pe fiecare link pentru a calcula o cale LSP TE. Acest lucru se realizează prin extensii specifice ale protocolului de rutare. Fiecare link este configurat inițial cu o bandă rezervabilă (care poate sau nu poate fi egală cu viteza reală a link-ului în cazul în care administratorul de rețea este dispusă să facă o sub / suprasubscriere). Cum LSP-urile TE sunt instituite și demolate, cantitatea de lățime de bandă rezervată variază pe fiecare link și este reflectată de către IGP. Trebuie reținut că banda disponibilă este prevăzută pentru fiecare nivel de preempțiune. [4]

Desigur, este de nedorit să fie inundat un nou avertisment IGP Link-State (LSA) de fiecare dată când lățimea de bandă disponibilă se modifică. Prin urmare, un mecanism de prag neliniar este utilizat, astfel încât mici modificări să nu declanșeze inundarea unui update IGP LSA. Dezavantajul unei astfel de abordare este inexactitatea potențială dintre lățimea de bandă disponibilă inundată de IGP și a statutului rezervării reale. În consecință, un ruter headend poate calcula o cale, chiar dacă lățimea de bandă necesară nu este efectiv disponibil la unele hopuri. În acest caz, un ruter care nu poate satisface această solicitare respinge LSP-ul TE și declanșează imediat inundarea unui IGP LSA de actualizare pentru a informa ruterul headend (și toate ruterele din rețea) de statulul real al rezervării. Ruterul headend, la rândul său, calculează o nouă cale TE LSP, de această dată, luând în considerare informațiile actuale.

4.4. Semnalizarea unui LSP TE

De îndată ce calea LSP TE se calculează, următorul pas este de a stabili LSP-ul TE. Protocolul de semnalizare pentru MPLS TE este RSVP-TE, care de fapt se bazează pe RSVP cu unele extensii specifice MPLS. RSVP-TE foloseste mesaje de RSVP să înființeze, să mențină (reîmprospătare), să semnaleze o stare de eroare, și sa închidă un LSP TE. Aceste mesaje sunt Path, Resv, Path Error și Resv Error. Fiecare mesaj conține un set variabil de obiecte. Așa cum am menționat mai devreme, mai multe obiecte noi, în plus față de obiectele definite existente pentru fluxurile IPv4 au fost specificate pentru utilizarea de către MPLS TE. Aceste obiecte sunt legate de atributele LSP TE, cum ar fi calea de calculat, lățime de bandă, preempțiune, cerințele Fast Reroute, și afinități.

Atunci când se inițiază configurarea unui LSP TE, ruter-ul headend începe expedierea unui mesaj Path RSVP care specifică atributele LSP TE. Mesajul Path este procesat la fiecare hop până la destinația finală. Apoi, pe calea inversă, mesajele RSVP Resv sunt trimise la ruterul headend. Fiecare hop de-a lungul căii verifică dacă constrângerile TE LSP pot fi îndeplinite. Dacă pot, fiecare ruter trimite un mesaj Resv vecinului său din amonte de-a lungul căii LSP TE pentru a confirma setarea cu succes. Acesta prevede, de asemenea eticheta care va fi folosită pentru LSP-ul TE corespunzător. Această secvență de mesaje este prezentată în figura 4.2.

După ce un LSP TE este configurat, acesta trebuie să fie menținut cu reîmprospătări succesive despre starea corespunzătoare (RSVP este un protocol soft-state). Fiecare ruter trimite un mesaj Path în aval și un mesaj Resv amonte pentru fiecare LSP TE activ la un interval regulat configurabil. Ruterele diferite operează într-un mod asincron.

Fig. 4.2. Pașii necesari pentru setarea LSP TE

Manipularea erorilor este în mod evident parte din semnalizarea RSVP. Prin urmare, atunci când un LSP TE are parte de un eșec care declanșează desființarea lui, un set de mesaje RSVP este trimis atât în amonte și în aval de ruterul de declanșare. Aceste condiții pot fi provocate de resurse insuficiente la semnalizare, eșecuri ale elementelor de rețea (link-uri, nod), exercitarea dreptului de preempțiune al unui LSP TE cu prioritate mai mare.

4.5. Reoptimizarea unui TE LSP

Statutul rețelei se schimbă în continuu. Link-uri sau noduri pică și se ridică, noi LSP-uri TE sunt configurate, în timp ce altele sunt desființate. Astfel, pentru fiecare TE LSP, o cale mai bună poate să apară în rețea. Este de dorit să se detecteze existența unei astfel de căi și să se reoptimizeze un TE LSP pe o cale mai buna când devine valabilă. Avem un exemplu în figura 5.3.

Fig. 4.3. Reoptimizarea unui TE LSP

În figura 4.3, toate link-urile au un cost de 1 și o lățime de bandă rezervabilă inițială de 10 Mbps, cu excepția link-ului R4R5, care are 15 Mbps de bandă rezervabilă. Să presupunem că primul TE LSP să fie semnalat este T1 între R8 și R5 (pentru 3 Mbps), care urmează calea cea mai scurtă R8R2R3R4R5, ascultănd de constrângerea lățime de bandă. Imediat după acest eveniment, R1 semnalează TE LSP-ul T2 (pentru 8 Mbps), care urmează calea cea mai scurtă care oferă lățimea de bandă de 8 Mbps, care este R1R2R6R7R4R5. Prin urmare, în momentul t0, atât T1 si T2 sunt funcționale. La momentul t1, LSP TE T1 este desfințat, ceea ce eliberează 3 Mbps din lățimea de bandă de-a lungul căii R8R2R3R4R5. Atunci când un proces de reoptimizare este declanșat de R1, se stabilește că o cale mai bună există între R1 și R5 (calea R1R2R3R4R5), și se redirecționează TE LSP-ul de-a lungul acestui link. Acest lucru ilustrează conceptul de reoptimizare.

Un aspect important al oricărui design de rețea MPLS TE se referă la declanșarea reoptimizării. Cât de des și, când ar trebui să fie evaluate TE LSP-urile pentru reoptimizare? Un ruter Cisco are mai multe declanșatoare de reoptimizare:

Reoptimizare manuala: O comandă este dată pe ruter-ul headend care declanșează o evaluare de reoptimizare pentru fiecare TE LSP al cărui este headend. În cazul în care o cale mai bună este găsită, LSP TE este reoptimizată în conformitate cu procedura make-before-brake.

Reoptimizare bazată pe un timer: Un cronometru este configurat pe ruter-ul headend. La expirarea acestui termen, headend-ul încearcă să reoptimize fiecare LSP TE pentru care este headend.

Reoptimizare bazată pe un eveniment: În unele cazuri, poate fi de dorit să se declanșeze o reoptimizare la producerea unui eveniment special, cum ar fi refacerea unei legături în rețea. Într-adevăr, dacă un link este restaurat în rețea, unele TE LSP-uri pot beneficia de această cale nouă pentru a putea avea un traseu mai bun. Când este configurat un nou link de fiecare dată este anunțat ca operațional iar aceasta declanșează reoptimizarea. Este de remarcat faptul că aceasta ar trebui să fie manipulate cu grijă pentru a evita instabilitate în rețea. Să considerăm cazul unui link-ul instabil. Acest lucru ar avea ca efect atragerea în mod constant de noi TE LSP-uri, care ar eșua și iar să fie din nou reoptimizate, creând astfel instabilitate și perturbarea traficului în rețea. Aceasta explică de ce o astfel declanșare trebuie să fie întotdeauna utilizată în asociere cu un mecanism de încetinire la nivelul interfeței sau la nivelul IGP pentru a evita instabilitatea în rețea în cazul legăturilor instabile. [18]

Modelarea unei rețele MPLS

5.1. Obiective

Cu ajutorul simulatorului de rețele OPNET Modeler, am construit o rețea care folosește mecanismul MPLS pentru îndrumarea pachetelor în interiorul domeniului. Am utilizat extensia RSVP-TE a protoculului RSVP pentru a evidenția tratarea diferită a două fluxuri de trafic cu ajutorul ingineriei traficului în cazul unor evenimente în rețea (am simulat un fibercut în exemplu). Obiectivul primar al acestui exemplu este de a vedea cele 2 opțiuni de rerutare a traficului pe care le oferă MPLS-ul.

Modelul de rețea ales va fi configurat să asigure două LSP-uri asociate porturilor de intrare aferente celor două stații care generează trafic. Am configurat să se trimită fluxuri de la cele două stații din Oradea către serverul destinație din Constanța. Fluxurile fac si rezervarea de resurse cu ajutorul protocolului RSVP. S-au configurat două LSP-uri dinamice pentru cele două fluxuri si câte o metodă de backup pentru fiecare.

Pentru analiza rezultatelor se va pune în evidență tratarea diferită a LSP-urilor care inițial aveau același traseu iar în urma fibercut-ului fluxurile îsi vor modifica traseul către destinație.

5.2. OPNET

Simulările software sunt foarte utilizate în industria din zilele noastre. Multe din produsele hardware dar și software sunt pretestate în aplicații software. Avantajele folosirii programelor de simulare sunt evidente:

Mai puțin timp pentru dezvoltarea produselor hardware și software

Abilitatea de a încerca o mulțime de scenarii diferite pentru prototipurile hardware și software fără dezavantajul costului sau al timpului pierdut

Prezicerea potențialelor probleme înainte de uzul de zi cu zi

OPNET Modeler este un soft de dezvoltare pentru industria IT. A fost introdusă în 1986 și permite designul și studiul comunicațiilor în rețele, dispozitive, protocoale și între aplicații. OPNET Modeler este utilizat de către dezvoltatori de tehnologie pentru accelerarea procesului de cercetare și dezvoltare.

Modelul orientat pe obiect pe care se bazează și interfața grafică permit crearea relativ ușoară de modele ale rețelelor actuale, oferind posibilitatea vizualizării ierarhizate a rețelelor. OPNET suportă majoritatea tipurilor de rețele și tehnologii, permitând astfel obținerea de rezultate concludente asemănătoare cu cele utilizării în viața reală a produselor testate. OPNET permite rularea și compararea mai multor scenarii, urmate de analiza prin intermediul graficelor. Ariile de aplicație includ:

Planificarea rețelelor (atât LAN cât și WAN) și analiza performanțelor și problemelor posibile înainte de implementarea actuală

Scheme de comunicații wireless și prin satelit și protocoale aferente

Managementul rețelelor prin fibra optică

Dezvoltarea protocoalelor și managementul lor

Evaluarea algoritmilor de rutare pentru rutere,comutatoare și alte dispozitive interconectate

Programul de simulare OPNET oferă posibilitatea modificării parametrilor rețelei și observarea efectelor imediat. Aceste simulări furnizează mijloacele de testare pentru diverse schimbări ce ar putea avea loc înainte de implementarea reală, analiza fiabilității componentelor și efectele defectării uneia, planificarea scalabilității și multe altele. Costurile asociate cu construirea și funcționarea unei rețele fac din OPNET o soluție viabilă în luarea deciziilor de planificare, modificare și analiza performanței unei rețele. [14]

5.3. Construirea rețelei

OPNET Modeler oferă o varietate foarte mare de echipamente și soluții cu care se pot creea elementele unei rețele. Pentru crearea unui domeniu MPLS-DS este important de știut care sunt nodurile obligatorii și atributele de configurat astfel încât să funcționeze conform dorințelor. Nodurile obligatorii sunt:

Stație de lucru: este responsabilă de generarea traficului în interiorul rețelei;

Server: este folosit în aplicațiile de tip client-server; se conectează cu o stație pentru schimb de date;

LER: reprezintă nodul de intrare sau de ieșire al unui LSP, ingress respectiv egress; este nodul la care se conectează stațiile de lucru și serverele; are rol de clasificare și asociere a traficului la clasele de îndrumare folosite și realizează scriere sau scoatere de etichete în stivă;

LSR: reprezintă nodurile intermediare; ele schimbă etichete de-a lungul LSP-urilor;

MPLS Config: este responsabil de configurarea specificațiilor claselor de îndrumare FEC și profilele de trafic (Traffic Trunk) asociate diferitelor fluxuri;

Application Config: acest modul definește tipurile de aplicații care pot fi utilizate pentru a simula traficul în rețea.

Profile Config: acest modul creează unul sau mai multe profile care selectează aplicațiile ce vor fi folosite de către stațiile de lucru când acestea vor începe transmiterea datelor.

Atributele configurabile sunt:

Specificații FEC: precizează clasele echivalente de îndrumare folosite în rețea; acestea pot fi specificate după: una sau mai multe combinații ale câmpului ToS, protocolul folosit (TCP, UDP, OSPF, ICMP, etc), adresa sursă sau destinație, portul sursă sau destinație;

Profile Traffic Trunk: se specifică diverse profile de trafic cu diferite rate de trafic maxime, medii, rafale de trafic, acțiunea pentru pachetele care sunt în afara profilului. Fiecare Traffic Trunk este asociat unei clase DS;

Parametri MPLS: sunt parametrii MPLS folosiți și trebuie configurați în fiecare LER;

Configurații TE: se realizează în fiecare LER. Acestea sunt folosite pentru a efectua asocieri de trafic: diferite clase FEC și profile Traffic Trunk sunt legate pe diferite interfețe și pot fi asignate diferitelor LSP-uri.

Adăugarea nodurilor la proiect se face cu ajutorul paletei de obiecte. Aceasta conține toate nodurile posibile, aranjate pe categorii după tipul rețelei, producător, tipul componentei, etc.

5.4. Configurarea rețelei

În imaginea de mai jos se poate observa rețeaua MPLS creată. In partea de N-V a hărții sunt cele două stații (flow 1 și flow 2) care trimit fluxuri către serverul din partea de jos a hărții (flow destination). Cu verde si albastru deschis sunt configurate LSP-urile principale (au traseul Oradea – Arad – Timișoara – Craiova – Pitești – Ploiești – București – Constanța) aferente celor două fluxuri de trafic. Cu roșu este un LSP de backup cu Fast Reroute (denumit în simulare Bypass Tunnel) configurat intre Pitești – Brașov – Buzău – București iar cu albastru este un LSP de backup (Ingress Backup LSP) preconfigurat din ruter-ul ingress.

Fig. 5.1. Rețeaua MPLS

5.4.1. Task Configuration

Cu acest nod asignăm celor 2 stații din Oradea o sarcină. Astfel am configurat să trimită un trafic de 128kbps, am selectat destinația ca fiind server-ul din Constanța. Din figura de mai jos se poate vedea că am denumit task-ul 128kbps traffic task și l-am configurat să trimită un pachet de 16000 bytes = 128000 biți.

Fig. 5.2. Task Config

Fig. 5.3. Protocolul de transport – UDP

5.4.2. Application Configuration

Acest nod este unul de management al rețelei, mai exact al tipurilor de trafic care ar putea să existe în cadrul domeniului MPLS. În cadrul lui se definesc diverse forme de trafic (email, ftp, http, servicii de voce, video, etc) cu diverse grade de încărcare, distribuții în timp, codecuri și multe altele.

Pentru acest scenariu am folosit o aplicație custom care are task-ul definit înainte, și anume de a trimite 128kbps trafic către server. Se mai poate observa că folosește UDP ca protocol de nivel 4 și este de tip best effort (în acest scenariu nu ne interesează QoS-ul, ambele fluxuri având priorități egale).

Fig. 5.4. Applications Config

5.4.3. Profile Configuration

A doua etapă în configurarea rețelei este crearea profilului ce va fi atribuit stațiilor. Acest lucru se realizează în nodul Profile Config, alegând unul din tipurile de trafic definite mai sus, respectiv 128kbps traffic application.

Fig. 5.5. Profile Config

5.4.4. MPLS Configuration

MPLS Config este nodul în care se definesc tipurile de clase de îndrumare folosite de nodurile LSR din cadrul rețelei, corespondențele realizate între câmpul EXP și comportamentul PHB sau după caz între câmpul EXP și prioritatea de aruncare a pachetelor, precum și profilele de trafic.

Întrucât LSP-ul folosit la îndrumarea pachetelor este de tipul E-LSP dinamic, tratamentul aplicat pachetelor în fiecare nod va fi determinat de câmpul EXP și se va folosi corespondența RSVP-TE.

S-a creat o singură clasă de îndrumare, UDP_FEC, care sortează pachetele după protocolul UDP. La fel, s-a creat un singur profil de trafic, EF_Trunk, în care s-a specificat clasa de trafic, EF.

Pentru cele două stații, s-a folosit aceeași clasă de îndrumare și prin urmare aceeași clasă de trafic. Deci cele două fluxuri de trafic au aceeași prioritate în transmiterea pachetelor.

Fig. 5.6. MPLS Config

5.4.5. Configurarea clienților

Stațiile de lucru sunt configurate cu același profil, 128kbps profile, pentru a beneficia de traficul setat în cadrul Profile Config si Task Config. Ambele stații vor transmite pachetele în același ritm, cu aceeași rată, aceeași mărime, în concluzie vor fi la egalitate la momentul transmisiunii. Ambele stații au fost configurate să trimită traficul pe care îl generază către serverul din Constanța.

În figura următoare este prezentat modul în care s-au configurat stațiile si server-ul.

Fig. 5.7. Client Config

5.4.6. Configurarea nodurilor LER și LSR

În primul rând am configurat toate ruterele din rețea să ruleze protocolul OSPF. Am configurat global acest lucru (din meniu am selectat Protocols -> IP -> Routing -> Configure Routing protocols de unde am selectat OSPF):

Fig. 5.8. Rounting Protocol Config

Tot global am configurat și RSVP-ul pe toate ruterele din rețea (Protocols -> RSVP -> Configure Interface status).

Fig. 5.9. RSVP Protocol Config

Am pus IP-uri manual pe toate interfețele ruterelor pentru a avea un mai bun control asignarii lor. Toate ruterele fac parte din aceeași area ID = 0. În rest toată configurația din urmatoarele 3 poze a fost făcută automat și global după cum am descris mai sus.

Fig. 5.10. OSPF Config

Fig. 5.11. RSVP Config

Așa cum știm, pachetele sosesc în ruterul LER ingress unde sunt verificate pentru a vedea dacă se încadrează în profilul de trafic asociat clientului. Pentru aceasta, mai întâi trebuie configurat modul în care se delimitează traficul primit de la clienți. În configurația nodului de intrare Oradea putem observa că profilele de trafic se mapează pe interfața corespunzătoare stațiilor: UDP_FEC și EF_Trunk pentru ambele interfețe (0 si 3).

În același timp se face maparea traficului care intră în interfața respectivă pentru a fi îndrumat către un anumit LSP. Se observă că pentru interfața 0 care corespunde stației flow 1 se îndrumă pachetele către LSP-ul Primary with bypass. Pentru cea de a doua stație, flow 2, s-a mapat traficul de pe interfața 3 cu LSP-ul Primary with Ingress Backup și s-a preconfigurat un LSP de backup în cazul esecului celui primar și anume Ingress Backup LSP.

Fig. 5.12. Traffic Mapping Config

În LER-ul ingress s-a făcut și o detaliere a căii pe care trebuie să o urmeze LSP-urile. Deoarece sunt LSP-uri dinamice configurate cu ajutorul RSVP-TE se poate specifica doar sursa si destinația LSP-ului și/sau unul sau mai multe noduri intermediare. În scenariul pe care l-am construit am atribuit LSP-urilor câte un nod cheie astfel încat ele să urmeze calea dorită de administrator. Pentru LSP-urile primare am selectat Craiova ca fiind nod intermediar, iar pentru LSP-ul de backup am selectat Suceava ca nod intermediar.

Fig. 5.13. Explicit Routes

În nodurile intermediare, nu se mai face nici o altă clasificare a pachetelor, LSR-urile având rolul doar de a efectua schimbul de etichete și a respecta tratamentul pachetelor conform PHB-ului dedus din câmpul EXP al pachetului.

5.4.7. Configurarea LSP-urilor

Pentru configurarea LSP-urilor primare s-a folosit un E-LSP dinamic. Se observă că pentru LSP-ul cu protecție prin Fast Reroute s-a specificat că trebuie să se ofere protecție rapidă.

Fig. 5.14. LSP Routes

Pentru cel de al doilea nu este necesară protecția rapidă, el este protejat printr-un LSP preconfigurat de nodul ingress.

Fig. 5.15. LSP Routes

5.4.8. Configurarea ruter-ului Pitești

Este necesară configurarea ruter-ului din Pitești pentru a construi un tunel Fast Reroute. Acesta este folosit pentru a proteja LSP-urile care tranzitează ruter-ul, dar nu protejează toate LSP-urile, ci numai cele care specifică în mod explicit acest lucru. În exemplul nostru LSP-ul care specifică în mod explicit folosirea unui tunel Fast Reroute acolo unde este posibil este Primary with Bypass.

Configurarea tunelului Fast Reroute se face în ruterul Pitești pe interfața IF1 către Ploiești. Se specifică explicit calea tunelului (Pitești – Brașov – Buzău – București). Nu se mai face nici o alta mapare a traficului.

Fig. 5.16. Pitești Router Config

5.4.9. Configurarea obiectului Failure – Recovery

Acest obiect permite simularea picării unui link sau al unui nod. În acest scenariu am simulat picarea link-ului dintre Ploiești si București. Astfel, a picat după 450 de secunde și a revenit dupa 550s.

Fig. 5.17. Failure – Recovery Config

5.5. Statistici și rezultate

În scenariul pe care l-am creat vom urmări următorii parametri și pe baza lor vom analiza performanțele modelului MPLS-TE:

Timpul de rerutare

Traficul prin link-uri

Traficul prin LSP-uri

End-to-end delay

5.5.1. Timpul de rerutare

Obiectivul principal al simulării este acela de a demonstra eficiența rerutării rapide în comparație cu rerutarea inițiată de ruter-ul ingress al LSP-ului în cauză. În graficul următor se poate vedea că rerutarea cu Fast Reroute este de aproape 7 ori mai rapidă în comparație cu rerutarea semnalată de ingress.

Fig. 5.18. LSP Traffic Reroute Time

În momentul în care pică link-ul dintre Pitești si București, ruterul Pitești detectează avaria, studiază LSP-urile care treceau spre București, iar pe LSP-ul Primary with Bypass îl rerutează imediat pe calea de backup. Pentru cel de al doilea LSP va trebui să fie anunțat nodul ingress, Oradea, de protocolul de rutare intern, OSPF în cazul nostru.

Pentru servicii real time, care sunt foarte sensibile la jitter și delay, o rerutare bazată pe OSPF poate fi devastatoare. OSPF-ul este costisitor din punct de vedere al procesorului pentru că în momentul recalculării noii topologii a rețelei folosește multe resurse. Un alt dezavantaj este timpul de convergență relativ mare (este mai mare decât în graficul de deasupra). Acest timp poate fi ajustat prin micșorearea timpilor de reacție dar acest lucru trebuie făcut după un calcul îndelungat și atent pentru că poate duce la instabilitate în rețea (din cauza flapărilor, necesitatea recalculării topoligiei rețelei, etc).

5.5.2. Traficul prin link-uri

Se poate observa în graficul de mai jos că pe link-ul Pitești – București s-a făcut trafic doar până la momentul “fibercut-ului”. Până în secunda 450 amândouă LSP-urile treceau pe acolo. Chiar și după ce s-a remediat problema, adică în secunda 550 nu s-a mai făcut trafic pentru că LSP-urile au mers pe calea de backup. După remediere s-ar fi putut reveni la starea inițială doar dacă după un interval de timp ruterul ingress, Oradea, ar fi cerut reoptimizarea LSP-urilor.

Înainte de “fibercut” se trimitea 260kbps trafic pe link-ul afectat. În momentul avariei traficul de la stația flow 1 a fost rerutat de ruterul Pitești pe LSP-ul Bypass Tunnel și ca urmare a crescut traficul pe link-ul Pitești – Brașov de la 0 la peste 130 kbps.

Fig. 5.19. Link Traffic

De asemenea, inițial se făcea trafic doar pe traseul Oradea – Arad – Timișoara – Craiova – Pitești – Ploiești – București – Constanța. Imediat după fibercut pe link-ul Oradea – Arad se mai trimite doar traficul aferent LSP-ului Primary with Bypass. La fel se rerutează traficul primit de la stația flow 2 este trimis pe LSP-ul Ingress Backup LSP și automat se populează link-ul Oradea – Satu Mare si tot traseul respectiv până la Constanța.

Fig. 5.20. Link Traffic

5.5.3. Traficul prin LSP-uri

Cele două stații trimit 128kbps către serverul destinație din Constanța. Acest lucru este ilustrat și în graficul de jos. De asemenea este interesant de analizat felul în care ruterul ingress Oradea trimite mai departe traficul primit de la stațiile direct conectate. Pentru LSP-ul cu backup prin Fast Reroute ruterul continuă să trimită trafic cu toate că știe că e picat link-ul Ploiești – București. Pentru al doilea LSP dupa secunda 450 nu v-a mai trimite traficul către acest LSP, ci către LSP-ul de backup preconfigurat (Ingress Backup LSP).

Detalii despre modul în care se face rerutarea au fost prezentate la punctul 6.5.1.

Fig. 5.21. LSP Traffic

Fig. 5.22. Backup LSP Traffic

Chiar si după ce link-ul picat s-a ridicat, traficul a continuat să fie trimis pe LSP-urile de backup.

5.5.4. End-to-end delay

Imaginea de mai jos este cea mai potrivită pentru a demonstra întârzierea fluxului de la sursă (Oradea) la destinație (Constanța). Pană la secunda 450 delay-ul era același pentru ambele fluxuri. După momentul în care s-a realizat fiber cut-ul, fluxurile au avut căi diferite. Întârzierea este mai mare la LSP-ul Ingress Backup pentru că trece prin mai multe hopuri (8) decât LSP-ul Bypass Tunnel (4 hopuri).

Fig. 5.23. End-to-End Delay

Concluzii

În urma acestui scenariu am demonstrat o parte din capabilitățile MPLS-TE. Am văzut cum funcționează MPLS ca suport pentru DiffServ, chiar dacă nu am arătat comportări diferite pentru diferte tipuri de trafic.

Cu ajutorul RSVP-TE am creat rute explicite pentru cele 4 LSP-uri din scenariu. De asemenea s-a putut defini și ruta de backup cu Fast Reroute. Pentru LSP-ul Primary with Bypass s-a specificat, în cazul în care LSP-ul devine nefuncțional din cauza unui eveniment în rețea și pe traseu este posibil să se redirijeze rapid pentru a reruta LSP-ul către destinație, să se facă. Astfel ruterul care avea o astfel de posibilitate a știut care dintre LSP-uri să le redirijeze rapid pe LSP-ul Bypass Tunnel.

Am putut observa și avantajele tehnicii Fast Reroute asupra unei soluții de backup preconfigurată. Soluția cu Fast Reroute a fost de 7 ori mai rapidă decât cealaltă soluție.

MPLS-TE oferă soluții foarte bune pentru rețelele IP multimedia. Ingineria traficului permite furnizorilor de servicii să ruteze traficul pentru a oferii clienților cel mai bun serviciu din perspectiva ratei de transfer și a întârzierii. Ingineria traficului este esențială pentru furnizorul de servicii și pentru rețeaua backbone a acestuia. Rețeaua backbone trebuie să susțină o cantitate mare de trafic și trebuie să reziste la evenimentele ce pot apărea în rețea.

Mecanismul DiffServ este ideal pentru că oferă calitatea de care au nevoie clienții, iar suportul MPLS este cel mai bun pentru a realiza acest lucru deoarece este în avantajul furnizorilor de servicii. Granularitatea serviciilor oferite cu ajutorul DiffServ este cel mai bine preluată de viteza de comutație a etichetelor și cu o calitate a serviciilor foarte bună. Folosirea serviciilor diferențiate permite crearea de noi nivele de calitate personalizate după cerințele clienților, în timp ce MPLS este legătura între vechea rețea Best Effort și noua rețea cu QoS garantat, putându-se adapta la orice mediu fizic și cu costuri minime.

Bibliografie

[1]. http://wiki.sj.ifsc.edu.br/wiki/index.php/RMU-2012-1 – accesat în Iunie 2014

[2]. http://flylib.com/books/en/3.2.1.37/1/ – accesat în Iunie 2014

[3]. Gary A. Donahue, Network Warrior, O'Reilly Media, Sebastopol, 2011

[4]. http://tools.ietf.org/html/rfc1633 – accesat în Iunie 2014

[5]. http://www.ietf.org/rfc/rfc2475.txt – accesat în Iunie 2014

[6]. https://www.nanog.org/meetings/nanog36/presentations/sathiamurthi.pdf – accesat în Iunie 2014

[7]. http://www.ixiacom.com/pdfs/library/white_papers/mpls.pdf – – accesat în Iunie 2014

[8]. https://www.nanog.org/meetings/nanog49/presentations/Sunday/mpls-nanog49.pdf – accesat în Iunie 2014

[9]. http://www.ietf.org/rfc/rfc3031.txt – accesat în Iunie 2014

[10]. Tatiana Rădulescu, Henri-George Coandă, QoS în rețele IP multimedia, edit.Albastră, Cluj, 2007

[11]. http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/multiprotocol-label-switching-mpls/prod_presentation0900aecd8031204c.pdf – accesat în Iunie 2014

[12]. http://tools.ietf.org/html/rfc3036 – accesat în Iunie 2014

[13]. Advanced MPLS Design and Implementation, CiscoPress

[14]. OPNET Modeler Documentation

[15]. http://tools.ietf.org/html/draft-ietf-mpls-cr-ldp-05 – accesat în Iunie 2014

[16]. http://tools.ietf.org/html/rfc3209 – accesat în Iunie 2014

[17]. http://www.ietf.org/rfc/rfc3814.txt – accesat în Iunie 2014

[18]. http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/multiprotocol-label-switching-mpls/mpls_te_frr.pdf – accesat în Iunie 2014

[19]. http://www.cs.stevens.edu/~lbernste/papers/MPLSDiffServ.pdf – accesat în Iunie 2014

[20]. http://www.ietf.org/proceedings/50/I-D/tewg-qos-routing-01.txt – accesat în Iunie 2014

Bibliografie

[1]. http://wiki.sj.ifsc.edu.br/wiki/index.php/RMU-2012-1 – accesat în Iunie 2014

[2]. http://flylib.com/books/en/3.2.1.37/1/ – accesat în Iunie 2014

[3]. Gary A. Donahue, Network Warrior, O'Reilly Media, Sebastopol, 2011

[4]. http://tools.ietf.org/html/rfc1633 – accesat în Iunie 2014

[5]. http://www.ietf.org/rfc/rfc2475.txt – accesat în Iunie 2014

[6]. https://www.nanog.org/meetings/nanog36/presentations/sathiamurthi.pdf – accesat în Iunie 2014

[7]. http://www.ixiacom.com/pdfs/library/white_papers/mpls.pdf – – accesat în Iunie 2014

[8]. https://www.nanog.org/meetings/nanog49/presentations/Sunday/mpls-nanog49.pdf – accesat în Iunie 2014

[9]. http://www.ietf.org/rfc/rfc3031.txt – accesat în Iunie 2014

[10]. Tatiana Rădulescu, Henri-George Coandă, QoS în rețele IP multimedia, edit.Albastră, Cluj, 2007

[11]. http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/multiprotocol-label-switching-mpls/prod_presentation0900aecd8031204c.pdf – accesat în Iunie 2014

[12]. http://tools.ietf.org/html/rfc3036 – accesat în Iunie 2014

[13]. Advanced MPLS Design and Implementation, CiscoPress

[14]. OPNET Modeler Documentation

[15]. http://tools.ietf.org/html/draft-ietf-mpls-cr-ldp-05 – accesat în Iunie 2014

[16]. http://tools.ietf.org/html/rfc3209 – accesat în Iunie 2014

[17]. http://www.ietf.org/rfc/rfc3814.txt – accesat în Iunie 2014

[18]. http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/multiprotocol-label-switching-mpls/mpls_te_frr.pdf – accesat în Iunie 2014

[19]. http://www.cs.stevens.edu/~lbernste/papers/MPLSDiffServ.pdf – accesat în Iunie 2014

[20]. http://www.ietf.org/proceedings/50/I-D/tewg-qos-routing-01.txt – accesat în Iunie 2014