arhitecturi pentru retele integrate de banda larga

ARIBL-RITC Master 2012-2013 page 1

ARHITECTURI PENTRU RETELE INTEGRATE DE BANDA LARGA

Master sem II

2012- 2013

Specializari: RITC

Prof. Eugen Borcoci


Continut

1 COMUTAŢIA DE ETICHETE MULTIPROTOCOL (MPLS) 4

1.1 CONCEPTE DE BAZA PENTRU “MULTI-PROTOCOL LABEL SWITCHING” - MPLS 4 1.2 AVANTAJE ALE TEHNOLOGIEI MPLS 5 1.3 DEFINIŢII ŞI TERMINOLOGIE MPLS 6 1.4 ETAPELE DE FUNCŢIONARE ÎN RUTAREA IP ŞI ÎN MPLS 7

1.4.1 Rutarea convenţională (IP) 7 1.4.2 Rutarea bazată pe MPLS 8

1.4.2.1 Etapele de funcţionare ale MPLS 8 1.4.2.2 Comparaţie intre un ruter tradiţional şi un ruter MPLS 9

1.5 ELEMENTE DE BAZA ALE MPLS 10 1.5.1 Codificarea etichetelor 10

1.5.1.1 Formatul etichetei MPLS 10 1.5.1.2 Incapsularea MPLS 11

1.5.2 Detalierea fazelor de operare MPLS 14 1.5.2.1 Faza de control 14 1.5.2.2 Faza de dirijare (transfer al fluxurilor de pachete) 15

1.5.3 Decizia de alocre a etichetelor 16 1.5.4 Utilizarea stivei de etichete 17 1.5.5 Manevrarea etichetelor 20

1.5.5.1 Asocierea etichetelor la clasele de echivalentă 20 1.5.5.2 Modurile de solicitare şi informare asupra etichetelor 21 1.5.5.3 Inregistrarile pentru dirijare spre nodul următor (NHLFE) 22 1.5.5.4 Asocierea etichetelor cu înregistrările NHLFE 22 1.5.5.5 Comutarea etichetelor 22 1.5.5.6 Domeniul de valabilitate şi unicitatea etichetelor 23 1.5.5.7 Căile cu comutaţie de etichete (LSP) 24 1.5.5.8 Eliminarea etichetei în nodul penultim al unei căi (PHP) 26 1.5.5.9 Nodul următor în LSP ("LSP Next Hop") 27 1.5.5.10 Agregarea fluxurilor 27 1.5.5.11 Selectarea rutelor 28 1.5.5.12 Timpul de viată al pachetelor (TTL) 29 1.5.5.13 Detalii privind codificarea etichetelor 29 1.5.5.14 Etichete comune 30

1.5.5.14.1 Principii de unificare a etichetelor ( “label merging”) 30 1.5.5.15 Ierarhii şi tunele MPLS 31

1.5.5.15.1 Tunele IP 31 1.5.5.15.2 Tunele LSP 31 1.5.5.15.3 Imperecherea nodurilor pentru distribuţia etichetelor şi ierarhiile asociate32

1.5.5.16 Concepte privind transportul LDP 33 1.6 STUDII DE CAZ PRIVIND RUTAREA SI ETICHETAREA 35

1.6.1 MPLS în rutarea traficului pe principiul nod-cu-nod 35 1.6.1.1 Distribuirea etichetelor pentru prefixe de adresa 36

1.6.1.1.1 Definiţii 36 1.6.1.1.2 Distribuţia etichetelor 36 1.6.1.1.3 Folosirea rutelor de tip “nod-cu-nod” ca LSP 37

1.6.2 Utilizarea MPLS LSP cu precizare explicită a rutei 38 1.6.3 Rutarea multi-cale şi arbori de căi LSP 39 1.6.4 Tunele LSP între rutere de frontieră BGP 39

1.6.4.1 Procedura de stabilire a tunelului 40 1.6.4.2 Un caz special de tunel 41

1.7 MPLS QOS 43 1.7.1 Necessary Conditions for QoS 44 1.7.2 Architectural Planes and QoS functions 45 1.7.3 IP Services 46


1.7.3.1 IntServ with RSVP-details 49 1.7.3.2 DiffServ-details 50

1.7.3.2.1 DiffServ basic terminology ( RFC 2475) 51 1.7.3.2.2 Functional blocks within a DS node 56 1.7.3.2.3 DiffServ Main Concepts – used in MPLS 58 1.7.3.2.4 Topological QoS Classes (CoS) Definitions 61 1.7.3.2.5 CoS Defined in DiffServ technology-standards 61

• Packet Marking 62 1.7.3.2.6 DiffServ Functions 64

1.7.4 MPLS cooperation with with DiffServ 65 1.7.4.1 MPLS Support of DiffServ 65

1.7.5 DiffServ-Aware MPLS Traffic Engineering 71 1.8 LABEL DISTRIBUTION PROTOCOLS (LDP) 73

1.8.1 Label Distribution with LDP 74 1.8.1.1 General features 74 1.8.1.2 Messages 75 1.8.1.3 Summary of Operation 75

2 ANEXE 77

2.1 METODE DE CODIFICARE PENTRU ATM_MPLS: 77 2.2 OPŢIUNI PENTRU REDUCEREA NUMĂRULUI DE ETICHETE 77 2.3 STIVA DE ETICHETE ŞI IMPERECHEREA IMPLICITĂ 78

2.3.1.1.1 Elemente de unificare a etichetelor în cazul interfeţelor ATM-LC 78 2.3.1.1.2 Inter-operarea nodurilor cu interfeţe de celule ATM 79

3 REFERINTE 81

NOTA IMPORTANTA:

Acest curs constituie o continuare a cursurilor

Arhitecturi si protocoale,

Retele si servicii din anul IV.

De revazut materialul corespunzator din acele cursuri.


1 COMUTAŢIA DE ETICHETE MULTIPROTOCOL (MPLS)

1.1 Concepte de baza pentru “Multi-Protocol Label Switching” - MPLS

- MPLS este o metoda de comutaţie rapidă de pachete la nivel trei

- folosită în reţele TCP/IP

- MPLS poate însă conlucra cu orice protocol de nivel 3, de unde şi numele de “multiprotocol”

- MPLS a fost dezvoltat pornind parţial de la ideile de baza din ATM ( eficienţa comutării de etichete de tip ATM în comparaţie cu dirijarea tradiţională IP- bazată pe analiza antetului de nivel trei al fiecarui pachet IP.

Rutarea IP tradiţională- funcţii principale:

- determinarea rutelor „routing” (algoritm de căutare a drumurilor de cost minim şi construirea tabelelor de dirijare -

- dirijarea ”forwarding” fiecărui pachet sosit la un Pin al unui ruter pe una din interfeţele de ieşire (sau mai multe, prin multiplicare, în cazul– „multicast”)

- Cautare pentru fiecare pachet în parte

- comparând a_dst (din antetul de nivel trei pachetului IP), cu informaţiile conţinute în Fwd_Table pentru determinarea celei mai bune potriviri între adresa de destinaţie şi înregistrările din tabel

- Rezultatul: identitatea portului de ieşire care va fi selectat

- IP „connectionless” ⇒ orice nou pachet este analizat în mod independent de cele anterioare ( flexibilitate a IP – ex. modificarea rutelor în mod dinamic)

- dar căutarea - consumă timp şi putere de calcul pentru fiecare pachet în parte

MPLS :

- înlocuieşte dirijarea bazată pe căutare cu o comutaţie („swapping”) de etichete realizata rapid (fără căutare)

- La intrarea într-un domeniu MPLS fluxurile de pachete sunt mai întâi clasificate în clase de echivalenţă (d.p.d.v al dirijarii – „Forwarding Equivalence Classes” - FEC)

- Fiecărei FEC îi corespunde un identificator de lungime fixă numită etichetă MPLS („label”)

- Fiecare pachet aparţinând unei clase FECi este etichetat cu eticheta clasei respective, iar eticheta se adaugă în faţa antetului IP

- Etichetele au valabilitate locală pe link-uri între nodurile comutatoare (alocarea etichetelor pentru o anumită rută se va discuta ulterior)

- În fiecare nod MPLS (comutator) următor, dirijarea pachetului etichetat, se face apoi prin comutaţie de etichete, pe baza unui tabel de comutaţie a etichetelor, conform relaţiei:

(port_intrare, etichetă_intrare) →→→→ (port_ieşire, etichetă_ieşire)

prin adresare indexată la un tabel de comutaţie

- La ieşirea din domeniul MPLS şi reintrarea într-un domeniu cu dirijare traditională IP, etichetele sunt eliminate de către ruterul de ieşire, care dirijează în continuare pachetul prin ”forwarding” tradiţional.

Pentru:

- compatibilitate cu arhitecturile existente si

- considerente economice


- MPLS a fost definit ca un nou sub-nivel arhitectural intermediar între nivelul 2-3; se păstrează implementările existente pentru nivelele DL şi N.

- Pentru a aloca etichete segmentelor (link-urilor) este nevoie de informaţii de rutare. În acest sens, o caracteristică importantă a MPLS este că admite informaţii furnizate de orice tip de protocol de rutare, de de unde şi numele de „multiprotocol”.

Domeniu MPLS = o zona dintr-o reţea, inclusă de regulă într-un singur domeniu adiministrativ IP, în care exista rutere comutatoare de etichete MPLS şi între care s-au distribuit într-un mod oarecare etichete MPLS.

Figura 2-1 : (simplitate) un singur domeniu MPLS, inclus intr-un altul IP (în ultimul este valabil un protocol de rutare IP şi dirijarea pachetelor se face în mod tradiţional)

Fiecărei FEC ⇔⇔⇔⇔ cale cu comutaţie de etichete (LSP - „Label Switched Path”).

Pachetele unui flux care aparţin unui FEC vor fi dirijate pe calea asociată

În fiecare nod comutator : comutaţia de etichete (e1→ e2, e2→ e3)

ER

LSR

ER ER

Domeniu M PLS

LSR

LSR Dirijare normala

(IP)

Dirijare normala (IP)

Dirijare M PLS

Domeniu IP

Cale M PLS (LSP)

e1 e3

e2

Figura 1-1 Dirijarea pachetelor în interiorul unui domeniu MPLS

LER – (“Label Edge Router”) -ruter de frontieră al domeniului MPLS

LSR – (“Label Switch Router”) - comutator de etichete/ruter intern domeniului MPLS

LSP - „Label Switched Path”)- cale cu comutaţie de etichete MPLS

1.2 Avantaje ale tehnologiei MPLS

MPLS : avantaje importante în special pentru reţele centrale (“core”) avansate:

• mai rapidă decât căutarea în tabele la nivel IP (“table look-up”), LSR sunt mai rapide decât ruterele tradiţionale (se pot folosi eventual chiar comutatoarele HW ATM).

• compatibilă cu orice nivel L2 sau L3 de ex. ATM şi respective. In ATM valoarea etichetei se poate include în VPI/VCI. Comutatoarele ATM intermediare vor lucra la fel ca în comutaţia ATM propriu-zisa.

• oferă flexibilitate prin aceea ca :

o lucrează la fel ca în rutarea de nivel 3, având în plus simplitatea dirijării asemănătoare cu comutaţia de nivel 2. MPLS permite realizarea de ierarhii de rutare (mai multe nivele de etichete) şi tehnici “tunel”.


o Poate colabora cu ruterele traditionale (domeniile MPLS pot coopera cu domenii de rutare tradiţionale ⇒ permite introducerea treptată a tehnologiei MPLS).

• facilitează creşterea performanţelor reţelei: suport necesar pentru inginerie de trafic (“Traffic

Engineering”- TE). În MPLS este posibil a defini explicit rutele dorite (similar cu rutarea de tip sursa) - rezultate de exemplu din considerente de TE, (ignorând sau folosind numai parţial informaţiile primite de la protocolul de rutare propriu-zis- RIP, OSPF, etc.).

• asigură suport suplimentar pentru controlul (QoS) MPLS fiind complementară cu tehnologii QoS specifice din Internet (IntServ, Diffserv).

• permite realizarea de reţele virtuale private (VPN).

• se poate generaliza şi aplica şi în reţele optice (GMPLS)

• permite flexibilitate în clasificarea pachetelor (la intrarea în domeniul MPLS) în clase de

echivalentă – definite din punct de vedere al dirijarii (FEC). În MPLS se pot folosi în principiu orice informaţii – de nivel L3 sau superior- pentru clasificarea pachetelor (prin contrast, la rutarea tradiţională IP singura informaţie utilizabilă este cea din antetul de nivel 3).

• etichetarea este flexibilă. În particular ea poate fi dependentă de ruterul de intrare. Un acelaşi pachet poate fi etichetat diferit (şi tratat în continuare în mod diferit) dacă soseşte pe unul sau altul dintre două rutere de intrare din domenii diferite (acţiune imposibilă în rutarea IP)

• arhitectura mai clara: separă planul de date (dirijare) în raport cu planul de control, oferind flexibilitate prin utilizarea de diferite plane de control.

Probleme – MPLS ?

În general : MPLS revine la modul de lucru CO ⇒ moşteneşte în mod inerent şi complexitatea acestuia precum şi un dinamism mai mic în comparatie cu IP:

• - funcţii şi protocoale suplimentare în planul de control care să conlucreze cu cele de rutare pentru distribuţia etichetelor între nodurile LSR.

• Căile MPLS trebuie construite în avans în raport cu transferul pachetelor de date

• Deteriorarea unei căi MPLS conduce la intreruperea transferului de date ceea ce face necesară definirea de căi LSP principale şi de rezervă.

• Rutarea este mai puţin dinamică decât în IP.

1.3 Definiţii şi terminologie MPLS

• Domeniu MPLS („MPLS domain”) –- porţiune dintr-o reţea în care dirijarea pachetelor se face prin MPLS şi care este inclus într-un singur sistem administrativ (AS) sau de rutare

• Flux de date („flow”) -– o instanţiere unică a secvenţei de pachete de date dintre două aplicaţii; uzual, un flux se poate caracteriza la nivelul patru prin multipletul { ( adresa_port, adresa IP)src , ( adresa_port, adresa IP)dst, protocol de transport }

• Clasa de echivalenţă din punct de vedere al dirijării (FEC – “Forwarding Equivalence Class”) - un grup de pachete IP care sunt dirijate de-a lungul aceleiaşi rute (suferă aceeaşi tratare din punct de vedere al dirijării)

• Etichetă MPLS (“MPLS Label”)

o identificator cu lungime fixă (32 biţi) amplasat înaintea antetului IP

o cu semnificaţie locală pe un link între două comutatoare MPLS

o care codifică un FEC

• Comutaţie de etichete (“label swap”) - operaţie de bază în MPLS, reprezentând modificarea etichetei la traversarea unui comutator MPLS


• Nod (generic) MPLS („MPLS node”) – un nod ce rulează MPLS, adică :

o cunoaşte protocoalele de control MPLS pentru distribuţia etichetelor

o rulează unul sau mai multe tipuri de protocoale de rutare

o capabil să dirijeze pachete pe bază de etichetă MPLS (dar poate opţional dirija şi pachete clasice IP)

• Nod MPLS de frontieră (“MPLS edge node” sau LER)- leagă un domeniu MPLS cu un domeniu non-MPLS sau cu un alt domeniu MPLS. Pot fi de două tipuri : de intrare („ingress”) şi de ieşire („egress”)

• Ruter comutator de etichete (LSR - “Label Switched Router”) – nod MPLS de nivel 3 capabil să comute etichete dar şi să dirijeze pachete folosind un mecanism tradiţional de nivel L3

• Cale cu comutaţie de etichete (LSP – “Label Switched Path”) – canal virtual ce traversează mai multe LSR, pe un anumit nivel în ierarhia de etichete MPLS; pachetele ce aparţin unui FECi urmeaza prin reţea aceeaşi LSP

• Stivă de etichete (“label stack”) – structura de date de tip stivă (LIFO – „Last Input First Output”) folosită pentru atunci când se lucrează cu mai multe nivele de etichete în dirijarea MPLS ierarhizată (domenii MPLS incluse unele în altele)

• Circuit virtual etichetat (LVC – “Labeled Virtual Circuit”) – conexiune virtuală “hop-by-hop” stabilită la nivel ATM (daca MPLS lucreaza „peste” ATM), pentru a se realiza un LSP. Spre deosebire de ATM traditional, conexiunea LVC nu este de tipul “capăt-la-capăt”)

• Protocol de distribuţie a etichetelor (LDP – “Label Distribution Protocol”) – protocol de comunicare şi distribuţie a etichetelor şi a semnificaţiilor acestora între LSR (lucrează în colaborare cu protocoalele de rutare: RIP, OSPF, BGP, IS-IS, EIGRP).

1.4 Etapele de funcţionare în rutarea IP şi în MPLS

1.4.1 Rutarea convenţională (IP)

În această secţiune se vor detalia etapele de lucru prezentate sumar în Secţiunea 5.1.

Determinarea/calcularea rutelor:

- planul de control calculează (dinamic) rutele : protocol de rutare

o schimb de mesaje între rutere (RIP, OSPF, BGP)

o algoritm de determinare a drumurilor cu cost minim (algoritm de rutare)

- Cu ajutorul informaţiilor obtinute se construiesc tabele de dirijare în fiecare ruter.

Dirijarea pachetelor:

- realizată de către planul de date

- Fiecare ruter (“hop”) ia în mod independent de celelate, o decizie de îndrumare către un “next hop”, bazându-se pe adresa destinaţie a pachetului

- Alegerea next-hop include 2 faze:

- gruparea pachetelor în clase de echivalenţă (FEC) şi realizarea corespondenţei („mapping”) : FEC/next-hop. - Din punct de vedere al dirijării, pachetele ce aparţin aceluiaşi FEC sunt tratate identic, fiind dirijate pe aceeaşi rută spre ieşire. Doua pachete sunt considerate că aparţin aceleiaşi FEC dacă tabelul de dirijare conţine un anumit prefix X, unde X este - pentru ambele pachete - porţiunea de adresă “cea mai lungă” de potrivire cu adresa de destinaţie a pachetului. Fiecare pachet în parte trebuie analizat pentru a i se atribui o clasă FEC.

- dirijarea propriu-zisa


1.4.2 Rutarea bazată pe MPLS

Presupunem ca s-au alocat etichete între nodurile MPLS (protocol LDP- bazat pe informaţiile obţinute de la RIP, BGP, etc.:

- alocarea unui pachet la o clasa FEC se face numai odată : la intrarea în domeniul MPLS

. Standardul MPLS nu impune restricţii privind clasificarea. Se pot folosi în principiu orice informaţii, din antetul propriu-zis IP dar chiar şi unele provenind de la nivelele superioare (flexibilitate a clasificarii MPLS).

- fiecare FEC la care există pachete asignate primeşte un antet cu 32 de biţi (eticheta propriu-zisa este cu 20 biti – si codifica un FEC)

- pachetul este dirijat către next hop (NH) numai pe baza etichetei, indiferent de informaţia cu ajutorul

căreia s-a decis apartenenţa la un anumit FEC.

- decuplare a clasificării faţă de comutaţie ⇒ flexibilitate in clasificari + simplitate pentru operaţia de dirijare şi comutaţie de etichete)

- un ruter intermediar : comutaţie de etichete – fara analiza de tip L3

1.4.2.1 Etapele de funcţionare ale MPLS

În această secţiune vom relua etapele principale de funcţionare ale MPLS.

1. Faza de Control

1.a Protocoalele de rutare interioare (RIP, OSPF, IS-IS, etc.) calculează rutele pentru toate destinaţiile accesibile. (ex.: OSPF, fiecare nod (ruter) determină graful reţelei prin mesaje “link state” de la vecini calculează drumurile cele mai scurte de la el către diferite destinaţii/reţele aplicând un criteriu de cost minim) se completează tabelul de dirijare.

1.b Spaţiul total de dirijare se împarte în FEC-uri. (Pachetele care vor urma acelaşi drum vor aparţine aceleiaşi FEC -se face “legarea etichetelor” – “label binding”, prin care se atribuie câte o etichetă pentru fiecare FEC. Label scope = un link între două rutere MPLS.

1.c LDP– distribuie etichetele între noduri, contribuind la alocarea în fiecare nod a unei etichete pentru o anumită clasă FEC (“map labels to each FEC în every hop”). Astfel se stabilesc căile LSP (unidirecţionale) prin domeniul MPLS.

2. Dirijarea pachetelor

Fie pachet IP sosit pe un port de intrare într-un ruter de frontiera MPLS.

2.a Se examinează ruta la nivel L3

- clasificarea pachetului pe baza potrivirii prefixului celui mai lung al destinaţiei şi pe baza potrivirii exacte a altor câmpuri şi se gaseste FEC (*)

- se alocă o etichetă corespunzatoare clasei FEC alese

- se eticheteaza pachetul IP cu antet MPLS

- pachetul este dirijat pe baza acesteia prin comutaţie de etichete în fiecare nod.

(*) Observaţie :

- se examinează de regulă antetul de nivel L3

- pot fi considerare şi alte informaţii auxiliare ( ex. de QoS, TE etc.) Corespunzător acestor informaţii ruterul de frontieră E-LSR poate decide alocarea clasei FEC şi a etichetei corespunzătoare ce va fi aplicată antetului.

2.b Fiecare LSR comută etichetele (“label swapping”) folosind eticheta de intrare ca index în tabelul de


dirijare (analog - ATM). Pachetul este dirijat pe portul de ieşire spre nodul următor. Comutaţia realizată este : (Port-în, L-in) -> (Port-out, L-out).

2.c Nodul de ieşire din domeniul MPLS elimină eticheta şi dirijează pachetul mai departe, în stil IP (eventual spre un alt domeniu) pe baza analizei de antet L3.

- opţional PHP („Penultimate Hop Popping”): penultimul ruter din domeniul MPLS, după determinarea portului de ieşire către ultimul nod MPLS, elimină deja eticheta deoarece ruterul de ieşire, oricum nu o va mai folosi.

ER

LSR

ER ER

- receptioneaza pachet - analiza antet la nivel L3 - eticheteaza pachet - dirijeaza catre urmatorul hop

Domeniu MPLS

LSR

LSR

-elimina eticheta - analiza L3 dirijeaza pachet

comuta etichete (se poate realiza PHB)

Tabel de dirijare

Tabel de comutare etichete

Calea LSP cu comutare de etichete (identificata in ER)

Figura 1-2 Dirijarea pachetelor în domeniul MPLS, pe baza etichetelor

PHB –Per Hop Behaviour – comportament special al unui nod (hop) pentru asigurarea unor caracteristici de calitate a serviciilor (Quality of Services – QoS)

1.4.2.2 Comparaţie intre un ruter tradiţional şi un ruter MPLS


Plan control C

Protocol rutare IP

Tabela rutare IP

Control de rutare IP MPLS

LIB

Actualizare rute

Actualizare ptrlegarea etichetelor

Label infoBase

Plan de date (U)

Forwarding Info Base (FIB)

Label Forwarding InfoBase (LFIB)

Tabela de dirijare MPLS

LCLC LC

LC

Buffer {Pachete

Protocoale rutare IP

Tabele rutare IP

“Routing Updates” actualiz. rute

Rutare IP

Tabele de dirijare (forwarding)

Procesare pachete

LC LC LCLC

Buffer

Pachete in

Pachete out

LC=line Card

Figura 1-3 a. Ruter traditional IP b. Ruter de frontiera - MPLS

LFIB – baza de date cu informatii: etichete de intrare; etichete de iesire; FEC asociate

1.5 Elemente de baza ale MPLS

1.5.1 Codificarea etichetelor

1.5.1.1 Formatul etichetei MPLS

IP-H TCP-H Date aplicatie Datgrama IP

MPLS-H IP-H TCP-H Date aplicatie Datgrama IP etichetata

LABEL EXP S TTL Antet MPLS 20 Biti 3 1 8

32 biti

Figura 1-4 Codificarea antetului MPLS

TCP-H antet TCP

IP-H – antet IP

LABEL – eticheta MPLS propriu-zisa. Aceasta are semnificaţie locală pe un link între două LSR.

EXP - câmp experimental - uzual indica o clasa de serviciu ( ex. In DiffServ/MPLS - codifica prioritaţi diferite ale pachetelor).

S - arată (dacă ia valoarea 1) că eticheta este la sfârsitul unei stive LIFO de etichete (folosită pentru a


realiza o ierarahie de domenii MPLS incluse unele în altele).

TTL – “Time To Live” –-vezi IP (timpul de viaţă rămas al pachetului în reţea).

Utilizarea etichetelor în cazuri practice: etichetele se pot aplica (include) în adrese de nivel 2:

- în indicatorii VPI, VCI în cazul ATM

- în indicatorul DLCI ( “Data Link Connection Identifier”) în cazul “Frame Relay”.

Etichete cu valoare rezervată - RFC 3032, [ ].

0 - IPv4 Explicit Null : are sens doar dacă S=1, şi semnifică faptul că trebuie eliminat antetul MPLS urmând ca rutarea mai departe să se facă pe principii IP.

1 - Router Alert : nu are sens dacă S=0, indicaţie pentru ruter: pop pentru eticheta curentă şi dirijare după eticheta următoare din stivă.

2 - IPv6 Explicit Null : are aceeaşi semnificaţie ca pentru IPv4.

3 - folosită de LDP pentru cereri PHP.

4…15 sunt valori rezervate.

Un domeniu MPLS, poate inclus în alt domeniu MPLS.

- se va utiliza stiva de etichete

- permite o rutare ierarhizată (dirijarea pachetului într-un domeniu se face cf.etichetei din vârful stivei).

Antet L2 Antet L3 Date Terminator

L2 Etichete MPLS

“Shim header”

Figura 1-5 Pachet cu stiva de etichete

1.5.1.2 Incapsularea MPLS

Incapsularea generică MPLS rezultă din amplasarea MPLS în stiva de protocoale: Antet L2, Antet MPLS

(“shim header”), Antet L3, etc., conform Figurii 2-5.

Antet L2 Antet MPLS

“Shim header” Antet L3 Antete de

nivel superior

Date Terminator L2

Figura 1-6 Incapsularea generică MPLS

În Figura 2-6 : încapsulare generică MPLS pentru diverse cazuri L2: PPP, PPP peste SONET/SDH,

Ethernet, Frame Relay PVC, MPLS peste ATM PVC.

Terminologie: - încapsulare bazată pe cadre (“frame based”). Antetul L2 conţine informaţiile sale uzuale. Eticheta MPLS nu este folosită la nivelul L2.


Antet L2 Antet MPLS

Antet L3 Date PPP , PPP over SONET/SDH Ethernet Frame Relay PVC

Antet ATM

Antet MPLS

Antet L3 Date MPLS over ATM- PVC Prima celula ATM

Antet ATM

Date Urmatoarele celule ATM

Tipuri de L2

Figura 1-7 Exemple de încapsulare generică MPLS pentru diverse nivele L2

• Incapsularea MPLS/PPP

“Point-to-Point Protocol” (PPP)

- folosit pentru comunicaţii 1-la-1 (ex. pe legături seriale).

- În modelul OSI, PPP –este definit la nivelul L2.

- Are trei componente principale cu ajutorul cărora stabileşte o conexiune şi apoi trimite pachete pe conexiunea creată.

- oferă o metodă de încapsulare pentru a se putea lucra cu diferite protocoale de nivel 3. PPP conţine un sub-nivel inferior pentru stabilirea, configurarea şi testarea unei conexiuni de nivel 2 („Link Control Protocol” - LCP) şi un subnivel superior – cu funcţii de adaptare („Convergence sublayer”) denumit „Network Control Protocol NCP”, care permite conlucrarea cu diferite protocoale de nivel 3. NCP include printre altele şi funcţii relative la securitatea informaţiei.

- Incapsularea PPP este ~ HDLC, cu unele excepţii. Un câmp special numit „protocol” indică tipul conţinutului informaţiei sau - echivalent - ce protocol superior se foloseste peste legătura de date propriu-zisă: LCP(0x co21), NCP(0x 8021), IP(0x 0021), control - MPLS-CP (0x8281 ), etc.

- În MPLS/PPP

- Se transmit pachete LCP pentru testarea şi configurarea legăturii

- Se transmit apoi pachete de tip MPLS Control Protocol (MPLS CP) – identificate pentru a configura transmisia de pachete etichetate MPLS

- După ce în urma schimbului de mesaje MPLS CP legătura de date a ajuns în starea “Open” se pot transmite pachete etichetate. MPLS CP foloseşte acelaşi mecanism de schimbare de mesaje ca şi LCP cu următoarele excepţii:

După ce PPP a ajuns în faza de Network Control şi MPLS CP a atins starea “Open”, se pot transmite pachete pe legătura de date, identificabile prin câmpul Protocol (0x0281 pentru MPLS 1-la-1 – „unicast” şi respectiv 0x0283 pentru MPLS – comunicaţii de grup – „multicast”.

• Incapsularea MPLS/Ethernet

- un cadru Ethernet va încapsula un singur pachet etichetat: antetul MPLS urmeaza celui de nivel 2, inclusiv în cazul existenţei unor forme modificate ale acestuia din urma (de exemplu pentru IEEE 802.1q -VLAN). Pentru identificare se foloseşte câmpul Type din cadrul Ethernet (octeţii 13 şi 14) cu valoarea 0x8847 pentru MPLS unicast şi 0x8848 pentru multicast. Cu aceste valori se face identificarea unui pachet etichetat şi dacă se foloseşte încapsularea L2 de tip 802.3 LLC/SNAP, [ ].

• Incapsularea MPLS/ATM

a. Incapsularea generică


- presupune (Figura 2.7) utilizarea de ATM-PVC

- datagrama de nivel trei se segmentează în celule

- numai prima celulă contine eticheta MPLS, celelalte conţinând doar restul datagramei

- Transport tradiţional-ATM, (bazat pe VPI, VCI) - independent de eticheta MPLS, care nu are vreun rol nici în selectarea circuitului virtual ATM şi nici în comutatia ATM

- Pentru a se putea efectua operaţii specifice MPLS intr-un ruter LSR, este necesară reasamblarea datagramei din celule.

b. Incapsularea etichetei MPLS în VPI, VCI

- Metoda anterioara- redundantă

- Alternativa: VPI şi VCI transporta eticheta MPLS. Comutatoarele ATM care lucrează în acest mod sunt denumite ATM-LSR.

- Terminologie: metoda de încapsulare ATM-MPLS. Comutatoarele LSR dispun de interfete de celule de tip ATM. Aceste interfete sunt numite în RFC 3031, [ ], LC-ATM ( “Label Switched

Controlled” - ATM). Eticheta MPLS se include în eticheta ATM înlocuind semnificaţia tradiţionala a acesteia, (figura 5-8). Soluţia permite folosirea interfeţelor şi comutatoarelor ATM în tehnologia MPLS.

Particularităţi:

- eticheta din vârful stivei se include în VPI, VCI

- între ATM-LSR nu se mai face reasamblarea celulelor ATM

- comutaţia MPLS se efectuează acum ca o comutaţie ATM, pe baza VPI, VCI

- din punct de vedere arhitectural, planul U (“User”) este planul ATM clasic dar în planul de control C se înlocuiesc protocoalele de semnalizare ATM (UNI, PNNI) cu protocoale proprii lui MPLS: OSPF, LDP

- în timpul transferului pachetelor nu se foloseşte decrementarea valorii lui TTL, (deosebire faţă de transportul IP al pachetelor)

- valorile rezervate de VCI ( vezi Capitolul ATM....) cuprinse între 0..31 nu se vor folosi ca etichete MPLS

- în funcţie de modul de interconectare al comutatoarelor ATM- LSR (SVC, SVP) există mai multe variante de încapsulare – subiect ce se va relua ulterior.

GFC VPI VCI PTI CLP HEC Antet

L3 Date Prima celula

GFC VPI VCI PTI CLP HEC Antet L3

Date Urmatoarele celule

Eticheta MPLS

Eticheta MPLS

Antet ATM

Figura 1-8 Includerea etichetei MPLS în VCI, VPI în cazul comutatoarelor ATM-LSR


1.5.2 Detalierea fazelor de operare MPLS

1.5.2.1 Faza de control

Reamintim etapele fazei de control:

1.a Calcularea rutelor de către protocoalele de rutare şi construcţia tabelelor de dirijare

1.b Divizarea spatiului total de dirijare în clase FEC şi atribuirea de etichete acestor clase (“label

binding”)

Note:

• Impartirea spatiului de adrese in clase FEC se face inainte de a face clasificarea fluxurilor in

clase de echivalenta d.p.d.v al dirijarii (este natural, caci clasificarea are loc in faza de transfer

de date- adica arhitectural vorbind – se face in “Data Plane” si nu in “Control Plane”).

• Deci clasele de dirijare depind (intr-o abordare minima) doar de adresele de destinatie (sau

intermediare ) si nu de tipurile de fluxuri ce vor circula prin caile LSP asociate acestor clase.

• Ca urmare doua pachete provenite din fluxuri dferite pot apartine aceleiasi FEC.

• Poe de alta parte pachetele dintr-un FEC sunt tratate la fel la iesirea unui LSR. Deci daca se

doreste a avea o tratare diferitea (de ex d.p.d.v. QoS) pentru doua fluxuri de pachete care

calatoresc pe un acelasi segmnent, sau ruta, atunci ele trebuie asignate la FEC diferite.

[ FEC is a group of IP packets which are forwarded in the same manner, over the same path, and with the same forwarding treatment. An FEC might correspond to a destination IP subnet, but it also might correspond to any traffic class that the Edge-LSR considers significant. For example, all traffic with a certain value of IP precedence might constitute a FEC.]

1.c LDP – distribuie etichetele între noduri, contribuind la alocarea în fiecare nod a unei etichete pentru o anumită clasă FEC şi astfel se stabilesc căile LSP.

Căile LSP sunt construite într-o manieră controlată explicit, cu urmatoarele variante:

- rutare explicită strictă (“strict explicit routing”) – caz în care toate nodurile prin care trece LSP sunt precizate/fixate

- rutare explicită cu grade de libertate – caz în care numai un subset de noduri ale căii LSP sunt fixate; celelalte pot fi în principiu oricare dintre cele diferite de subsetul de noduri precizate explicit.

• Exemplu :

stabilirea unei căi spre o maşină terminală având adresa (IPv.4) de destinaţie x.y.z.w, conectată la o reţea locală având prefixul de adresă x.y.

Figura 1-9: domeniu MPLS şi fazele de control.

Faţă de un nod LSRk, există (considerând sensul de transfer al datelor) noduri în aval (“downstream”) şi noduri în amonte (“upstream”).

Standardul MPLS : etichetele sunt distribuite întotdeauna de către nodurile din aval faţă de un nod dat.

Nodul amonte poate obţine de la cel din aval o etichetă, pentru o anumită clasă FEC, (pp. că această clasă FEC este asociată cu o anumită destinaţie din reţea), astfel:

- face o cerere de etichetă către nodul din aval (“solicited downstream mode”) –aflat pe ruta către destinaţia dorită, sau


- primeşte o indicaţie – de la nodul din aval- de a folosi o anumită etichetă pentru o anumită FEC dar fără a solicita el însusi aceasta (“unsolicited downstream mode”).

Figura 5-9 : exemplu pentru (“unsolicited downstream mode”)

Exemplu: LSR2 îi comunică (prin mesaj LDP) lui LSR1 :

<propun eticheta L=5 pentru o cale LSP, care trece pe la mine si merge catre destinaţia cu prefix de

adresă x.y>.

Semnificaţia mesajului: (“use label 5 for destination x.y”)

Dupa un lanţ de asfel de mesaje (in sens invers cu cel al datelor) se poate stabili o cale LSP catre destinaţia x.y.

E-LSR

non MPLS

LSR1

LSR2

E-LSR LSR

LSR

E-LSR

Reţea x.y

x.y.z.w

non MPLS

Tabel de dirijare în E-LSR

Tabel de comutaţie de etichete

Label Switch Path

Alocare de etichete de tip "downstream" nesolicitat

Rute alese de IGP

Domeniu MPLS

Propun eticheta 7 pentru dest.x.y x.y

Propun eticheta 5 pentru dest.x.y

Propun eticheta 9 pentru dest. x.y

Figura 1-9 MPLS - faza de control

E-LSR – Edge Label Switched Router; IGP Interior Gateway Protocol

1.5.2.2 Faza de dirijare (transfer al fluxurilor de pachete)

Figura 1-10 :

-transferul unui flux de pachete etichetate pe o cale MPLS

către o reţea având adresa x.y (prefix de adresă IPv.4)

S-a presupus că în urma fazei de control în fiecare LSR există cate un tabel de comutaţie care conţine informaţiile de comutaţie de etichete.


Penultimul LSR poate elimina eticheta, căci ea nu va mai fi necesară în E-LSR

Tabela de comutare pentru I/F0 etichetă IN

prefix adresă

I/F OUT

etichetă OUT

9 XY 2 5

E-LSR

LSR

Reţea XY

XYZ

Rută aleasă de IGP

3

2

LSR

LSR

LSR

E-LSR

E-LSR

1 0

9

0

1 2

5

2 1

3 7

2

0

1

3

Recepţionează pachetul L3 "look up" clasifică FEC etichetează pachetul dirijează către nodul următor

Comutaţie de etichete (adresare indexată): IF0->IF2, 9-> 5

Dirijare tradiţională

0

Label Switch Path

Domeniu MPLS

Figura 1-10 Operare MPLS: dirijarea pachetelor

1.5.3 Decizia de alocre a etichetelor

IETF RFC 3031: două moduri de control al alocării etichetelor: independent şi ordonat („Independent

Control”-IC, „Ordered Control”-OC) .

IC:

- fiecare LSR

- decide - independent de alte LSR, partiţionarea în FEC

- aloca etichete pentru FEC-urile stabilite

- distribui etichetele către vecini.

- Probleme: de ex. - daca un LSR decide că fiecare prefix de adresă din tabela de rutare va reprezenta un anumit FEC, iar dacă un vecin al său va lua decizii diferite referitoare la aceleasi FEC-uri, atunci este posibil ca pentru anumite FEC-uri să nu poată crea căi LSP.

[RFC 3031:

“In Independent LSP Control, each LSR,

- upon noting that it recognizes a particular FEC,

- makes an independent decision to bind a label to that FEC

- and to distribute that binding to its label distribution peers.

This corresponds to the way that conventional IP datagram routing works; each node makes an independent decision as to how to treat each packet, and relies on the routing algorithm to converge rapidly so as to ensure that each datagram is correctly delivered.]

OC:


- un LSR poate face o corespondenţă („mapping”) FEC/label numai dacă a primit o etichetă de la nodul următor sau dacă este un “egres” ruter pentru acel FEC.

Caracteristici:

- iniţierea o poate face un ruter de iesire din domeniul MPLS

- selectarea FEC se face la ruterul iniţiator

- pe măsura formării LSP, toate LSR din calea respectivă vor utiliza acelaşi FEC. Este însă necesar ca orice LSR să poată determina care este „next-hop” pentru FEC în cauză, astfel încât să poată verifica că legarea (“binding”) etichetelor vine de la un “next-hop” corect.

RFC 3031:

In Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC.

Comparaţie IC/OC:

- OC

- avantaj: control administrativ mai strict,

- Dezavantaj: timpului mai mare de propagare al etichetelor

- IC

- Avantaj: convergenta mai rapida ( orice LSR poate stabili şi anunţa în reţea legarea de etichete fără a mai aştepta propagarea ordonată a mesajelor de la un ruter la altul)

- Dezavantaj : posibilitatea ca un ruter să înceapă dirijarea de pachete etichetate înainte ca LSP-ul să fie format corect, nerespectându-se astfel eventuale restricţii

- există posibilitatea interoperabilităţii între ele

Alegerea uneia sau alteia dintre abordări nu influenţează mecanismul folosit în distribuţia etichetelor

1.5.4 Utilizarea stivei de etichete

Stiva se utilizeaza

- în cazul incluziunii domeniilor MPLS unele în altele

- la rutarea inter-domeniu

- la realizarea de VPN, etc.

Figura 1-11: exemplu de rutare MPLS între trei domenii A, B, C.

Pp: între domenii se foloseşte comutaţia de etichete MPLS, stabilite cu ajutorul informaţiilor furnizate de (BGP – „Border Gateway Protocol”).

În domeniul B se foloseşte MPLS, etichetele fiind stabilite anterior pe baza informaţiilor de rutare furnizate de un ( IGP – „Interior Gateway Protocol”).

Intuitiv: calea MPLS inter-domeniu, poate fi privita ca un tunel MPLS (care foloseşte etichetele 4, 9 si 6). Între ruterele R1 (din A), ELSR1, ELSR2 (din B) şi R2 ( din C) exisă relaţii de semnalizare de tip BGP.

Dirijarea în domeniul MPLS B:

- se face cu un nou nivel de etichete – stivă ce va avea în vârf etichetele folosite şi comutate în LSR din B.

- Etichetele exterioare lui B nu sunt folosite în operatiile „swap” din comutatoarele LSR ale lui


B.

- Exprimare echivalenta: se transferă pachetele din tunelul MPLS A-B-C printr-un nou tunel, cuprins între ELSR1 şi ELSR2 din domeniul B. La ieşirea din B se elimină etichetele tunelului din domeniul B.

Acţiunile executate pentru realizarea acestui tunel sunt urmatoarele (poziţiile şi elementele în care au loc în domeniu sunt indicate în figură):

1. R1 (din A) adaugă / comuta o etichetă, de exemplu 4 (pe baza informaţiilor BGP, pentru a urma o cale R1 → ELSR1 → ELSR2, ...)

2. ELSR1 face o comutaţie de etichete 4 → 9, in tunelul A-B-C.

a. [ELSR2 nu este accesibil direct de către ELSR1 din domeniul B] ⇒ELSR1 caută o cale MPLS: ELSR1 → ELSR2 prin B ( pe baza informaţiilor MPLS din ELSR1).

b. De ex. calea MPLS va fi ELSR1→LSR1→LSR2→ELSR2.

c. Pentru a realiza acest transfer ELSR1 introduce un nou nivel de etichete (prin operatia push).

i. În particular, se foloseşte o cale ce trece prin LSR1 cu adăugarea în stivă (push) a etichetei 7. Pachetul etichetat cu 7, 9 se transferă pe un port către LSR2.

3. LSR2 nu modifică eticheta 9 dar realizează o comutaţie asupra etichetei din în vârful stivei , în particular, 7→5.

4. LSR2 execută o comutaţie similară celei din ELSR1 şi anume, 5→2. Observăm că eticheta 2 nu este strict necesară deoarece ea nu va mai fi folosită de catre ELSR2. De aceea este posibil a avea şi un alt un mod de funcţionare, în care penultimul nod MPLS dintr-un domeniu elimină eticheta (PHP- „penultimate hop popping”) – caz care nu este prezentat în acest exemplu.

5. LSR2 elimină (pop) eticheta 2 care se gasea din vârful stivei şi comută după eticheta iniţială, în particular, execută comutatţia 9→6.


Domeniul A

E-LSR1 LSR1 E-LSR2 LSR2 R1 R2

9 7 4 9 5 9 2 6

Domeniul B Domeniul C

1 2 3 4 5

BGP BGP IGP IGP IGP

In NH Out In NH Out In NH Out In NH Out

? LSR1 7

push

7 LSR2 5 5 E-LSR2 2 2

pop

R2 ?

Înregistrări IGP

In NH Out In NH Out In NH Out In NH Out

- E-LSR1 4 4 E-LSR2

9 9 R2 6 6 - -

Înregistrări BGP

Eticheta 7 Eticheta 5 Eticheta 2

4

9

6

9 9

Tunel MPLS intra-domeniu B

"7 – 5 – 2" prin care sunt transportate pachetele cu etichete "exterioare" 4 – 9 – 6

Etichetă utilizată pentru dirijare în interiorul domeniului B

Etichetă utilizată pentru dirijare interdomenii A-B-C

Figura 1-11 Utilizarea stivei de etichete pentru un transfer MPLS inter-domeniu

1 – adaugă eticheta 4;

2 – comutaţie 4→9; E-LSR2 nu este direct accesibil: găseşte o conexiune via LSR1 şi adaugă (push) eticheta 7;

3 – comută eticheta din vârf 7→5 şi 9 rămâne nemodificată;

4 – comută eticheta din vârf 5→2 şi 9 rămâne nemodificată;

5 – elimină (pop) eticheta internă şi comută eticheta externă 9→6.

Rezumăm acţiunile care au loc la intrarea unui pachet aflat în interiorul unui domeniu MPLS1 într-un alt domeniu inclus, în speţă MPLS2 ( vezi figura 1-12):

1. la intrarea în MPLS2 se execută operaţia „push” cu o nouă etichetă pe nivelul de etichete


activ în MPLS2

2. în interiorul lui MPLS2 se face comutaţie de etichete conform acestui nou nivel

3. la ieşirea din MPLS2 se execută operaţia „pop” pentru nivelul de etichete valabil în MPLS2, revenind la nivelul de etichete din MPLS1.

MPLS1

MPLS2 (1) (3)

(2)

Figura 1-12 Domenii MPLS incluse şi folosirea stivei

1.5.5 Manevrarea etichetelor

1.5.5.1 Asocierea etichetelor la clasele de echivalentă

Asocierea etichetă/ FEC = „legare a etichetelor” („label binding”)

- Două comutatoare LSR de pe aceeaşi cale se află într-o relaţie de amonte-aval.

- Două LSR se afla intr-o în relaţie (u-d) dacă pentru aceleaşi FECi folosesc o etichetă “L” cunoscută de ambele pentru dirijarea pachetelor etichetate.

- Rd ia decizia legării L/FEC şi îl informează (distribuie L) pe Ru. (“downstream assigned

mode”)

R u R d

1.Aloca L/FEC 2. Informeaza Ru

LSP

Date –(in viitor)

Figura 1-13 Principiul distribuţiei înspre „amonte” ( de jos în sus) a etichetelor MPLS

O legatură L/FEC poate avea şi unele atribute asociate.

- Daca Ru joacă la rândul său rol de Rd pentru a distribui în amonte etichete, atunci el va retransmite spre amonte şi aceste atribute

- De regulă atributele se utilizează atunci când există o stivă de etichete în rutarea ierarhizată MPLS.

- Procedurile prin care se transmit legările L/FEC între LSR = Label Distribution Protocol (LDP)

- În plus, LDP poate include şi eventuale negocieri între LSR vecine în scopul de a afla


capabilităţile MPLS ale fiecăruia.

După distribuirea etichetei către Ru acesta poate în principiu să o folosească pentru transferul MPLS (Figura 1-14).

Figura 1-14 Ruterele Ru şi Rd folosesc eticheta agreată anterior

1.5.5.2 Modurile de solicitare şi informare asupra etichetelor

a. Distributie nesolicitata ("unsolicited downstream label distribution")

Un ruter R afla o etichetă, dacă :

- primeşte un mesaj de la un Rd, care tocmai a stabilit o etichetă pentru un FEC anume (R poate sau nu să reţină informaţia, deoarece nu el a cerut-o)

Figura 1-15 Informare de tipul "unsolicited downstream label distribution " asupra etichetei

b. Distribuţia de etichete cerută de la un ruter din aval, “downstream on demand”

Figura 1-16: pe linkul R2-R3 sunt 2 cereri pentru o aceeaşi destinaţie, care vor apărea ca distincte numai dacă este vorba de FEC-uri diferite.

Figura 1-16 Obţinerea etichetelor prin cereri explicite adresate în aval "downstream-on-demand"

Două LSR vecine trebuie să decidă care dintre metode o vor utiliza intre ele. Pe acelaşi ruter însă este posibilă coexistenţa metodelor, dar folosite pe porturi diferite.

Informaţia asupra unei etichete primită de un R poate fi tratată în două feluri:

L

Flux de date

eticheta de ieşire din Ru

Ru Rd

Rd Ru

Mesaj iniţiat de Rd: " for dest =128.9, please use label = 7 "

128.9.X.x Reţine sau nu informaţia

primită

R3 R2 128.9

132.5

R1

R5 R4

Cere etichetă pentru 128.9

Cere etichetă pentru 132.5

Cere etichetă pentru 128.9 Cere etichetă

pentru 132.5

Cere etichetă pentru 128.9 (2 cereri distincte dacă sunt 2 FEC diferite)


- “Liberal Label Retention Mode”: ruterul reţine total informaţia chiar dacă momentan nu-i este necesară, pentru o eventuală folosire rapidă, ulterioară. Cost: creşterea spaţiului de memorie ocupat fata de cel efectiv, folosit la un moment dat.

- “Conservative Label Retention Mode”: ruterul reţine numai informaţia de care are momentan nevoie; se reduce dimensiunea memoriei utilizate, cu dezavantajul că dacă va avea nevoie de acea informaţie trebuie reluată activitatea de aflare a ei (creşte timpul de răspuns).

1.5.5.3 Inregistrarile pentru dirijare spre nodul următor (NHLFE)

Pentru dirijarea pachetelor sunt necesare înregistrari - în tabelele de dirijare - asupra nodului urmator “Next Hop Label Forwarding Entry” = NHLFE cu informaţii:

- nodul urmator (“next-hop”) din calea LSP

- operaţiile de executat pe stivă:

- comutaţie de etichete (doar modificarea de eticheta; nu se intampla nimic cu stiva)

- (pop) – iar decizia de dirijare se va lua din eticheta următoare din stivă;

- comutaţie de etichete + push o noua eticheta în stivă pentru formarea unui tunel.

In plus, NHLFE poate conţine şi informaţii auxiliare :

- încapsularea de nivel 2,

- modul de codificare al stivei

- informaţii utile modului de prelucrare al pachetului.

LSR („next-hop”) al unui Ri poate fi chiar el însuşi, dacă Ri se află la ieşirea dintr-un domeniu MPLS. Ri dirijează pachetul către el însuşi, iar următoarea dirijare se va face în funcţie de informaţiile rămase în stivă după ce Ri a făcut “pop” la stiva primită iniţial (urmeaza o dirijare dupa eticheta rămasă în stivă sau, după caz, o dirijare IP clasica).

1.5.5.4 Asocierea etichetelor cu înregistrările NHLFE

- Pachet de intrare deja etichetat: Eticheta se asociaza cu una sau mai multe înregistrări de tip NHLFE.

- funcţia de corespondenţă = ILM – „Incoming Label Map”. Daca unei etichete îi corespund mai multe NHLFE, RFC 3031 nu precizează asocierea : etichetă –un NHLFE -pentru a se putea face dirijarea (libertate pentru diferite criterii de selectare a NHLFE, de ex. “load

balancing”)

- Pachet de intrare neetichetat:

- el trebuie clasificat şi etichetat

- funcţia („mapping”) „FEC-to-NHLFE” (FTN). asociază fiecărui FEC un set de NHLFE, (pentru dirijarea efectivă este folosită doar prima înregistrare)

- asocierea cu un set de mai multe înregistrari permite - “load-balancing”.

1.5.5.5 Comutarea etichetelor

- pentru un pachet de intrare etichetat cu L, aflată în varful stivei:

- funcţia ILM determină înregistrarea NHLFE, ce indică operaţiile

- se execută operatiile

- pachetul este dirijat spre un port de ieşire.

- pachet de intrare neetichetat:

- se analizează antetul L3 şi (eventual alte informatii) pentru a determina cărui FEC aparţine (clasificare)


- FTN determina un set de NHLFE

- Se execută apoi operaţiile cerute de NHLFE selectat şi se dirijează pachetul spre un port de ieşire.

1.5.5.6 Domeniul de valabilitate şi unicitatea etichetelor

In ce zona MPLS este valabila o eticheta L ?

- principiu : L are valabilitate locală:

- pe un anumit link între două rutere

- este asociată unei clase FEC cunoscută pe acel link

- Consecinta: pe linkuri de intrare diferite ale aceluiaşi ruter pot exista etichete egale valoric dar reprezentând clase diferite, de exemplu F1, F2.( trebuie ca ruterul în cauză să poată identifica distinct interfeţele de sosire)

-

Exemplul 1: Figura 1-17.a.

Un LSR Rd:

- asociază L1 /F, şi distribuie asocierea lui Ru1

- asociază L2 aceluiaşi F şi distribuie asociere lui Ru2.

Deci aceeaşi clasă F există pe doua link-uri diferite marcată cu două etichete L1 şi L2. Arhitectura nu impune ca L1= L2 sau L1≠ L2; aceasta depinde de informaţiile disponibile local. Dacă ruterul poate face distincţia între intefeţele pe care sosesc pachetele, atunci L1 poate fi chiar egal cu L2 fără a apărea ambiguitate.

Exemplul 2: LSR Rd poate să:

- asocieze L/ F1 şi să distribuie asocierea lui Ru1

- asocieze L /F2 şi să distribuie asocierea lui Ru2.

F1 poate fi diferit de F2 ⇔ Rd poate distinge daca pachetul cu eticheta cu L a venit de la adica de la Ru1 sau Ru2)

altfel F1 si F2 trebuie sa fie egale.

Date

Ru1

Rd

Ru2

(L1, F)

(L2, F)

a.

Date

Ru1

Rd

Ru2

(L, F1)

(L, F2)

b.

Figura 1-17 Unicitatea etichetelor

a. Aceeaşi clasă, cu etichete diferite pe linkuri diferite

b. Aceeaşi valoare de etichetă pentru clase diferite pe linkuri diferite

Problemă mai generală: moduri de folosire de către un LSR a spaţiului (mulţimea de valori numerice) etichetelor ?

- soluţii RFC 3031 :

- “per-interface-label-space”.


- Eticheta unica per I/F; diferite I/F ale LSR pot folosi etichete egale (cazul b de mai sus)

- - este necesar ca ruterul receptor să poată face distinctia, spatiala intre I/F de pe care a primit pachetele

- „per-platform-label-space”. - o etichetă este unică per ruter ( se aplică daca metoda precedentă precedentă nu se poate aplica din cauza ambiguităţilor).

Rd 0

Ru

[ ]nL,,L3,L2,L10S K=

1 2

Figura 1-18 Spaţii de etichete distincte la nivelul unei interfeţe

(pe interfeţele 1 şi 2 pot exista etichete din setul S0)

Rd

0

Ru

1

(L, F1)

(L, F2)

Figura 1-19 Etichete unice la nivelul LSR

Figura 1-19 : totusi un Rd poate folosi aceeaşi L pentru F1≠ F2, în asociere cu acelaşi vecin Ru, dacă la primirea unui pachet de la Ru, Rd poate face distincţia intre I/F0 si I/F 1

Std. MPLS :

- spaţiul (multimea) etichetelor este unul singur pentru toate nivelele ierarhice. De fapt, atunci când este interpretată o eticheta nivelul ierarhic al acesteia nici nu conteaza, căci alte mecanisme dictează care nivel ierarhic se foloseşte.

- Permite folosirea mai multor spaţii de etichetare, per platformă sau per interfaţă (aceste spaţii pot fi mulţimi de valori cu intersecţie nevide!). Este necesar însă a exista mijloace particulare (non specificate de arhitectura MPLS) pentru a putea spune cărui spaţiu aparţine o anumită etichetă.

- De exemplu: MPLS-shim specifică faptul că pentru unicast şi multicast se folosesc spaţii de etichetare diferite şi atunci se foloseşte un cod de nivel doi care va indica despre care spaţiu de adresare este vorba.

1.5.5.7 Căile cu comutaţie de etichete (LSP)

Definiţia formala (completă) a unei căi LSP

O cale LSP de nivel m pentru un pachet P este prin definiţie : o secvenţă de LSR cu proprietăţile

(<R1..Rn> , unde R1-„ingress” şi Rn-„egress”) :

1. R1 – „LSP ingress” adaugă o etichetă la stiva existentă a lui P, prin care ridică stiva la nivel m ( “push” la antetul lui P)

2. pentru orice i, 1 < i < n , nivelul stivei lui P , |stivaP| = m atunci când pachetul este recepţionat de Ri

3. în orice moment al tranzitului lui P intre R1 şi Rn-1, nivelul stivei lui P este |stivaP| ≥ m

4. pentru orice i, 1< i < n, Ri va dirija P spre Ri+1 pe baza etichetei de nivel m prin adresare indexată în ILM


5. pot exista elemente intercalate între Ri şi Ri+1 (de exemplu un comutator S de nivel doi, etc.) care nu dirijează pachetul P după eticheta de nivel m ci se afla în una din situaţiile:

o nu folosesc deloc eticheta şi nici antetul de nivel 3

o dirijarea se face dupa o etichetă de nivel mai mare (m+k, k>0). (aici de fapt este vorba de un alt domeniu MPLS prin care calea în cauză trece sub formă de tunel).

MPLS 1

Domeniu non-MPLS

push push

push pop pop

pop

0 1

2

Nivel stivă

(se poate aplica şi PHP)

E-LSR

MPLS 3

MPLS 2

MPLS 1 Domeniu

non-MPLS

push push

pop

pop

0

1

2

Nivel stivă

E-LSR

MPLS 2

2

Figura 1-20 Evoluţia stivei de etichete la traversarea domeniilor MPLS

Cale LSP de nivel m pentru un pachet P: o secvenţă de rutere în care:

primul execută „push” la nivelul m

ruterele intermediare comută etichete de nivel m

ultimul LSR din LSP execută o dirijare la nivel m-k, k>0, sau o dirijare non-MPLS ( de exemplu

IP).

Figura 1-20: modificarea stivei din antetul unui pachet pe timpul parcurgerii a trei domenii MPLS incluse unele în altele.

Definiţie: LSP pentru o clasă particulară F este :

- o secvenţă de LSR,

- ce constitue o cale LSP de nivel m pentru pachete P

- unde eticheta de nivel m pentru P corespunde cu clasa F.

Conform acestei definiţii pot exista şi arbori de LSP care pornesc de la „ingress” E-LSR diferite şi ajung


la acelaşi egress E-LSR. Căile ce aparţin arborelui au aceeaşi clasă FEC. (figura 1-21).

Domeniu MPLS

F E-LSR

F

F Aceeaşi clasă

FEC = F

Figura 1-21 Arbore de căi LSP

1.5.5.8 Eliminarea etichetei în nodul penultim al unei căi (PHP)

Penultimate HOP Popping”- PHP –

- opţional într-un domeniu MPLS = posibilitatea ca un LSR,

- stiind ca el este penultimul LSR din domeniu),

- atunci poate elimina eticheta corespunzătoare nivelului său ierarhic caci ultimul LSR nu o va mai folosi (figura 1-22.b).

Avantaj: eliminarea unei duble analize în ruterul « egress » (una pentru eticheta de nivel m şi alta pentru eticheta de nivel m-1 sau pentru antetul de nivel 3). Folosind PHP, în ultimul ruter va fi necesar doar un singur "look-up", fie pentru a afla noua etichetă fie pentru a realiza o rutare IP clasică.

Obs. : PHP = opţional, deci pot exista comutatoare care nu ştiu să implementeze PHP.

PHP se aplică

- daca este ceruta de ruterul “egress”

- daca următorul nod în LSP nu suportă MPLS. Protocolul LDP trebuie să permită nodurilor LSR să determine dacă vecinii lor cunosc opţiunea PHP

-

De asemenea, LSR-urile nu vor cere aplicarea PHP decât nodurilor vecine despre care ştiu că sunt capabile de acest lucru.

Figura 1-22 Eliminarea etichetei la capătul căii LSP

m – 1

m Nivelul stivei

Pop

Rn-1 Rn

m – 1

m Pop pentru eticheta de

nivel m

Rn-1 Rn

a. b.

a. în nodul ultim al LSP b. În nodul penultim al LSP


1.5.5.9 Nodul următor în LSP ("LSP Next Hop")

Pentru un pachet particular: "LSP Next Hop" este acel LSR, selectat prin NHLFE folosit pentru dirijarea pachetului.

• Pentru o clasă FEC, LSP next Hop : nodul selectat prin adresare indexată la NHLFE de către eticheta corespunzătoare acestui FEC.

• "Next-hop" în sensul MPLS nu coincide obligatoriu cu "next-hop" selectat de un algoritm de rutare de nivel L3. De exemplu nodul urmator în cazul MPLS poate fi unul ales din alte criterii decât drumul de cost minim.

• Un pachet etichetat de intrare gasit sosit cu o etichetă de intrare incorectă ("Invalid Incoming

Label"), de regulă este eliminat.

1.5.5.10 Agregarea fluxurilor

• Uzual se asociaza câte o clasa FEC pentru fiecare prefix distinct de adresă din tabelul de rutare.

• Este posibil ca pe anumite porţiuni din domeniul MPLS, mai multe fluxuri cu FEC diferit să urmeze aceeaşi rută.

o În acest caz, în domeniul MPLS uniunea de FEC-uri poate constitui tot o clasa FEC, pe segmentul respectiv de rută.

o Prin operaţia numită agregare se asocieză o singură etichetă întregii uniuni de FEC-uri, datorită faptului că pe acel segment toate fluxurile în cauza sunt dirijate la fel.

Granularitatea de agregare poate fi variată : dându-se un set de FEC-uri "agregabile" este posibil ca acestea :

(a) să fie agregate într-un singur FEC – adică avem o granularitate grosieră (minima),

(b) să fie agregate într-un set de mai multe FEC-uri sau

(c) să nu fie agregate)- granularitate fină (maximă).

Când este folosit controlul ordonat al etichetelor, un LSR trebuie să adopte pentru un set de FEC-uri dat, aceeaşi granularitate ca "next hop".

pe această secţiune se pot agrega cele 3 fluxuri, prin alocarea unei

etichete unice

Figura 1-23 Agregarea fluxurilor

În cazul controlului independent, este posibil ca două LSR adiacente, Ru şi Rd, să agrege diferit anumite seturi de FEC-uri.

Dacă Ru are granularitatea mai fină decât Rd, atunci Ru poate să retragă o parte din etichetele sale.

Dacă Ru are granularitatea mai grosieră decât Rd, atunci Ru :

- va retrage etichetele sale şi va prelucra etichetele lui Rd, (recomandare RFC 3031)sau

- asociază etichetele sale (ale lui Ru) cu un subset de etichete ale lui Rd.


Pentru a se putea realiza agregarea este necesară cunoaşterea de către toate LSR prin configurarea iniţială a fiecaruia, a nivelului de granularitate ce trebuie folosit.

În reţelele reale se foloseşte însă uzual un singur nivel de granularitate pentru toate FEC (de exemplu: 1_eticheta/prefix_adresa, 1_eticheta/nod_iesire, etc.)

1.5.5.11 Selectarea rutelor

Selectarea rutelor se referă la metoda folosită pentru alegerea unei căi LSP pentru o anumită clasă de echivalenţă FEC.

Există două metode de selecţie:

1. nod-cu-nod ("hop-by-hop"): fiecare nod LSR alege în mod independent nodul următor pentru fiecare pachet (asemănător cu rutarea tradiţională IP ; (IGP calculeaza anterior rutele)

2. rutarea explicită ("explicit routing"): un singur LSR (fie "ingress" sau "egress") alege ruta şi specifică total ("strictly explicitly routed") sau parţial ("loosely explicitly routed") nodurile care o compun, ca în figura 2-24.

Specificare totala

(stricta)

Specificare numai a anumitor puncte (partiala)

Pot fi oricare

Figura 1-24 Metode de specificare a unei rute LSP pentru o clasă FEC

Selectarea explicită a unei rute de către un LSR se poate face:

- static, prin configurarea iniţială a acestuia

- dinamic, de către un singur nod care cunoaşte topologia reţelei (în urma rulării în reţea a unui protocol de tip “link-state”).

- Având imaginea grafului reţelei şi valorile costurilor asociate arcelor, nodul poate decide ce rută vor urma anumite pachete.

- De exemplu, un nod LSR „egress” ar putea calcula un arbore de rute care converg spre el cu plecare din diferite noduri „ingress” ale domeniului MPLS.

Obs.: rutarea explicită MPLS este parţial similară cu rutarea de tip-sursă în IP („source routing”),

dar mai avantajoasă decât aceasta.

- În rutarea-sursă IP, ruta de urmat trebuie sa fie specificată explicit în fiecare pachet al unui flux. Ruta de folosit („next hop”) este determinată de fiecare nod prin analiza informaţiei de rutare de tip sursă existentă în fiecare pachet.

- În rutarea explicita MPLS ruta trebuie specificată doar în momentul distribuirii etichetelor. În continuare, după alocarea etichetelor şi etichetarea pachetelor, se face doar comutaţie de etichete fără a mai fi necesară analiza informaţiei de rutare din pachet.


Posibilitatea rutării explicite : avantaj al MPLS :

- se pot aplica politici („Policy based routing”)

- sau în ingineria traficului (Traffic Engineering”).

Dacă pentru un pachet nu se poate afla eticheta de ieşire (din diverse motive) şi deci nu se ştie ruta de urmat, atunci solutia uzuala este eliminarea pachetului.

1.5.5.12 Timpul de viată al pachetelor (TTL)

Similar ca în rutarea IP, valoarea TTL („Time To Live”) este folosită în MPLS pentru a suprima buclele tranzitorii, sau pentru alte funcţii, ex. - limitarea zonei de accesibilitate acordată în reţea unui pachet.

Câmpul TTL din antetul MPLS este decrementat cu o unitate la trecerea printr-un nod a unui pachet, iar dacă valoarea sa ajunge la TTL=0, atunci pachetul este eliminat de către nodul de reţea care constată aceasta.

Datorită organizarii în stivă a antetului MPLS, este necesar transferul valorii TTL, de la o etichetă din stivă la cea imediat următoare în sus sau în jos după caz.

În figura 1-25:

- valoarea TTL1, este copiată de catre nodul de intrare R1 în câmpul corespunzător din antetul MPLS

- în fiecare nod LSR din interior, valoarea TTL este decrementată cu 1

- la ieşire în nodul R2, (dacă pachetul a ajuns aici), se copiază valoarea TTL ramasă (adică un TTL2) în câmpul TTL al antetului L3 al pachetului ce iese din domeniu (poate urma un domeniu MPLS sau IP).

Obs.: Pot însă exista porţiuni de LSP (insule de reţea) cu LSR “non-TTL capabile”- de exemplu noduri ATM), care nu ştiu să scadă valoarea TTL. În acest caz, LSR-ul de la intrarea în zona respectivă anticipează care ar fi efectul traversarii acelei zone asupra valorii TTL, şi ca urmare a acestei estimări, va scadea TTL cu o valoare aproximativ egală cu numărul de noduri din segmentul respectiv. Dar această soluţie rezolvă problema eventualelor bucle numai după ce pachetul va ieşi din acea insulă; deci pentru a se preveni buclele în interiorul insulei trebuie ori ca protocolul din acea zonă să aibă propriul mecanism de detecţie şi evitare a buclelor ori ca LDP să prevadă şi alte mecanisme.

TTL2

L

MPLS

Valoarea lui TTL1 se introduce în eticheta L, în câmpul TTL, şi apoi se scade la fiecare LSR traversat

TTL1 R1 R2

Figura 1-25 Utilizarea TTL în MPLS

1.5.5.13 Detalii privind codificarea etichetelor

S-a aratat ca MPLS suportă mai multe tehnici diferite de codificare:

- încapsularea generică MPLS – folosind antetul « shim » intre nivelele L2 şi L3

- şi incapsularea ATM-LC în care se folosesc campurile VPI,VCI ale celulelor pentru a include etichetele.


Alegerea unei tehnici depinde de dispzitivele folosite pentru dirijarea pachetelor etichetate.

1.5.5.14 Etichete comune

1.5.5.14.1 Principii de unificare a etichetelor ( “label merging”)

• etichetă comună este una pe care un LSR o alocă unui grup de fluxuri de intrare ce aparţin aceluiaşi FEC şi care au sosit în acest LSR cu etichete diferite.

• Tehnica se numeste “label merging”, - Figura 2-26.

• Avantajul obţinut este o economie importantă de etichete.

• Din punct de vedere al dirijării identitatea distinctă a unui flux de intrare se pierde ( aceasta va pune probleme în interfeţele de tip I/F LC-ATM).

LSR

L1

L2

L3

L Fluxuri ce

aparţin aceluiaşi FEC

Figura 1-26 Utilizarea etichetelor în comun

• Un LSR este capabil de a executa "merge" dacă primind pe I/F diferite, pachete cu etichete diferite le poate transmite mai departe cu o aceeaşi etichetă comună.

• Un LSR non capabil de unificare a etichetelor (« non-merge ») va păstra la ieşire etichete distincte pentru fluxurile individuale.

• Arhitectura MPLS : ruterele capabile de unificare şi cele non-capabile trebuie să poată coopera.

Conlucrarea este posibilă dar apar anumite probleme.

• Caz 1

• Presupunem un Ru non-capabil de unificare.

o El va scoate în aval spre un Rd pachete cu acelasi FEC dar etichetate diferit. Ţinând seama ca în MPLS modul de alocare a etichetelor este „downstream to upstream” apare intrebarea: de câte etichete va avea nevoie un Ru de la Rd? Evident Rd nu are cum să ştie acest lucru pentru un FEC.

o Singura soluţie este ca Ru să ceară explicit lui Rd numărul de etichete necesar, în particular pentru fiecare flux de intrare chiar dacă acestea aparţin aceleiaşi FEC.

o Figura 1-27 prezintă un astfel de caz. Dacă la rândul său Rd este tot de tip „non-merging”, atunci Rd va proceda similar în dialogul cu cel din aval faţă de el.

o Dacă nodul Ru cunoaşte mecanismul “label merging”, atunci el cere lui Rd doar o singură etichetă.

o Daca Ru poate agrega numai un număr limitat de etichete şi el are nevoie de mai multe etichete, decât poate agrega, atunci face mai multe cereri, ca în cazul c. din figura 2-26.


Flux1

Fluxuri ce aparţin

aceluiaşi FEC Flux6

a. şase cereri distincte daca Ru = “non-merge”

b. o cerere daca Ru = “merge” si poate agrega > 6 etichete

Cereri de etichete

Etichete Ru

Ru

Rd

Ru

c. doua cereri daca Ru = “merge” dar poate agrega =< 4 etichete b. cerere daca Ru – “non-merge” si poate agrega > 6 etichete

Figura 1-27 Cererea explicită de etichete de la Rd

1.5.5.15 Ierarhii şi tunele MPLS

1.5.5.15.1 Tunele IP

Tehnica “tunel” permite transportul unui pachet:

- printr-o reţea diferită (cu alt sistem de adresare)

- sau printr-o zonă din aceeaşi reţea

prin încapsularea sa intr-o “anvelopă” care conţine alte adrese decât cele originale.

Calea traversată astfel se numeşte tunel.

La capătul tunelului se elimină anvelopa şi se reia utilizarea adreselor originale.

Tehnica tunel este foarte folosită în reţele IP.

Exemplu: un ruter Ru doreşte să trimită un pachet la Rd, dar Ru şi Rd nu sunt consecutive şi Rd nu este destinaţia finală a pachetului, atunci Ru încapsulează pachetul într-o anvelopă cu destinaţia Rd. Astfel se crează un "tunel" de la Ru la Rd.

Tunelele IP transporta pachetele încapsulate (între Ru şi Rd) cu rutare:

- de tip nod-cu-nod ("hop-by-hop"), – capătul Tx: Ru, iar capătul Rx: Rd şi fiecare ruter intermediar ia decizii independente asupra lui « next hop » al unui pachet

- rutare de tip sursă (explicită), în care încapsularea unui pachet se face intr-o anvelopă ce conţine toate informaţiile asupra rutei.

1.5.5.15.2 Tunele LSP

• Tunelele LSP, folosesc comutaţia de etichete în locul încapsularii din tehnica tunel

tradiţionala.

• Tunelul este de forma

o LSP = <R1,…,Rn>, în care Tx=R1 Rx=Rn.

• Echivalentul încapsulării de principiu din tehnica tunelului, este în MPLS introducerea unui nou nivel de etichete asociate tunelului respectiv.

• Setul de pachete transportat constituie o clasă FEC şi fiecare LSR din tunel atribuie o etichetă acestei FEC.

• Decizia de a introduce un pachet într-un tunel este locală primului ruter Ru.

• Pentru a crea un tunel, Ru introduce o nouă etichetă şi face « push » pentru aceasta în stiva de etichete.


• Penultimul nod din tunel poate face “pop”în cazul folosirii opţiunii PHP, sau nivelul de etichete asociat tunelului este eliminat de Rd.

• Tunelele LSP pot fi de asemenea cu rutare "hop-by-hop" sau cu rutare explicită în funcţie de modul în care s-a stabilit calea LSP.

MPLS permite o ierarhie de nivele LSP, exemplificată în figura 2-29.

Lab

Tunel R2 – R3

Lbc Ra Rb Rc

R3 R4 L34

L2a

R2

nivel 2

R1 L12

L23

L12 L2a L23

Lab L23

Lbc L23

- L23 L34

push în R2 pop în Rc

Figura 1-28 Tunel LSP inclus în LSP

O ierarhie de acest fel poate avea oricâte nivele. În particular, în Figura 2-29 avem două LSP :

nivelul 1 <R1,R2,R3,R4>

nivelul 2 <R2,Ra,Rb,Rc,R3>

Obs.:

R2 şi Ra : sunt vecini – in relatia IGP

R2 şi R3 nu trebuie să fie vecini in relatia IGP.

• Doua LSR vecine-IGP formează o pereche de rutere LSR pentru distribuţia locală de etichete ("local label distribution peers").

• Două LSR care constituie o pereche pentru distribuţia de etichete, dar nu sunt vecine IGP, formează o pereche de LSR pentru distribuţia distantă de etichete ("remote label distribution

peers").

1.5.5.15.3 Imperecherea nodurilor pentru distribuţia etichetelor şi ierarhiile asociate

Fie pachet P (vezi Figura 1-29) transferat prin LSP1 de nivel 1, format din <R1, R2, R3, R4>.

În “interiorul” lui LSP1 există un LSP2 de nivel 2, notat

LSP2 = <R2, R21=Ra, R22=Rb, R23=RC, R3>,

care conţine ruterele Ra, Rb, Rc intermediare între R2 şi R3.

• Pe nivelul 1 vecinii lui R2 pentru distribuţia de etichete sunt R1 şi R3.

• Pe nivelul 2 vecinul lui R2 pentru distribuţia de etichete este Ra.

Deci relatia de vecinatate se asociaza unui nivel ierarhic.


MPLS suportă două moduri de distribuţie a etichetelor pe nivele ierarhice diferite:

• împerechere explicită ("Explicit Peering")

• şi împerechere implicită ("Implicit Peering").

Distribuţia de etichete de către un ruter, spre un vecin pereche-locala se face prin transmiterea mesajelor LDP care sunt adresate ruterului pereche.

Distribuţia de etichete de către un ruter către un vecin pereche-distantă se poate face în unul din cele doua moduri introduse în textul de mai sus :

• împerechere explicită ("Explicit Peering"): se transmit mesaje LDP spre un partener pereche ("peer") la fel ca la distribuţia locală.

o Acest mod se utilizează când

� numărul de perechi LSR este mic,

� sau numărul de etichete de nivel superior este mare,

� sau LDP pereche este în alt domeniu/arie de rutare;

• împerechere implicită ("Implicit Peering"): nu se transmit direct mesajele LDP pentru distribuţia de etichete către partenerul pereche, ci :

o etichetele de nivel superior sunt codificate ca atribute ale unei etichete de nivel inferior

o se transmite eticheta de nivel inferior impreuna cu aceste atribute către un partener –pereche local.

o partenerul-pereche local va propaga această informaţie mai departe către un alt partener-pereche local, ş.a.m.d. , din aproape în aproape (transportând şi atributele), până ce este atins partenerul-pereche distant

Imperecherea implicită se utilizează când numărul de LSR-uri perechi de distribuţie de tip distant este mare.

1.5.5.16 Concepte privind transportul LDP

Protocolul de distribuţie de etichete LDP este utilizat între noduri MPLS pentru a stabili şi menţine legăturile etichetă-FEC.

Pentru o operare corectă sunt necesare transmiterea corectă a informaţiei şi păstrarea secvenţialităţii mesajelor.

Arhitectura MPLS nu impune un anumit protocol de distribuţie a etichetelor.

Soluţii : protocoale noi LDP sau adaptarea/completarea unor protocoale existente pentru a putea suporta şi distribuţia de etichete.

• BGP [ ], [ ], (rutare inter-domeniu), poate fi folosit şi pentru distribuţia LDP: în multe scenarii este frecvent cazul în care se asociază etichetele cu prefixe de adresă.

o Dacă există protocoale standard, deja utilizate ce conţin algoritmi de rutare şi care distribuie informaţii despre rute în reţea, atunci e posibil ca informaţiile despre etichete să fie transportate în stil "piggy-back" pe mesajele care distribuie rutele propriu-zise.

o Acesta este şi cazul protocolului exterior BGP. Se beneficiază în plus de scalabilitatea BGP.


• RSVP [ ], [ ], [ ], folosit şi pentru distribuţia de etichete.

o În mod « clasic », RSVP este folosit pentru rezervarea de resurse pentru anumite fluxuri particulare de date.

o Considerând acest lucru, atunci este de dorit a eticheta pachetele acestor fluxuri de date pentru a evita operaţiile de filtrare pe bază de adrese/port ( « RSVP filterspec ») în fiecare nod.

o Astfel, folosirea RSVP ca transportor/distribuitor nu numai al informaţiilor de rezervare dar şi al etichetelor (ca parte a procesului PATH/RESV) este eficientă în contextul controlului QoS al LSP.

SRC A

RESV

� R1 R2

DST B

DST establish the QoS requirements

for this flow

� PATH)

Idem as in R1

R1 finds Next hop No reservation

R2 can reserve resources for

R2-DST

PATH)

PATH)

RESVconf

RESV

PATH

RESV

PATH specifies flow

and the amount of traffic (TSPEC)

RESV carries DST

request for R2 to reserve resources on the

segment R2-> DST

RESVconf

RESVconf

RESV follows the same route as PATH

Optional confirmation

Data

Figura 1-29 Semnalizari RSVP

Actiuni de semnalizare pentru rezervare

1. PATH – sursa anunta caracteristici de trafic ce va fi generat

2. RESV – cerere de la Receptor

3. RESVconf- confirmare a rezervarii


� Utilizarea mesajelor RSVP pentru cereri de etichete si rezervare de resurse in MPLS

� Ruterul din aval aloca etichete la crerea celui din amonte (regula MPLS)

� Se foloseste mesajul PATH pentru a cere eticheta

� Descrierea traficului ce se va genera este continuta in PATH

� Mesaj RESV propune o eticheta pentru segmentul respectiv si indica resursele ce trebuie rezervate

RA

RESV

RC

RB

RD

PATH

PATH : End of LSP: RD Traffic description Label request

RESV: Label L1 Reserved resources

RE



LSP

Figura 1-30 Utilizarea RSVP pentru disrtributia de etichete in MPLS

• Etichete pentru LSP-uri cu rutare explicită: există aplicaţii (ex.: « MPLS-Traffic

Engineering » – MPLS -TE ) în care este utilă

o stabilirea unei rute în mod explicit, de la ingress la egress,

o şi rezervarea de resurse pe această cale.

Două soluţii posibile :

o un protocol folosit iniţial pentru rezervarea de resurse şi apoi extins pentru a suporta rutarea explicită şi distribuţia de etichete ( exemplu: MPLS-RSVP-TUNNELS, [ ])

o un protocol folosit iniţial pentru distribuţia de etichete şi apoi extins pentru a suporta rutarea explicită şi rezervarea de resurse, ( exemplu: MPLS-CR-LDP, [ ], [ ]).

1.6 Studii de caz privind rutarea si etichetarea

1.6.1 MPLS în rutarea traficului pe principiul nod-cu-nod

Pachetele cu o anumită etichetă vor fi dirijate de-a lungul aceleaşi rute stabilite nod-cu-nod ("hop-by-

hop"), metodă utilizată şi în rutarea tradiţională.

(un ruter determină “next-hop” pentru un pachet P, prin căutarea în tabelul de dirijare a unui prefix de adresă X care constituie cea mai “bună/lungă- ca număr de biţi” potrivire cu adresa destinaţiei din P). In acest caz, FEC poate fi identificat cu un prefix de adresa.

Deci se asociază etichete prefixelor de adresă destinaţie(dar în general, nu e obligatoriu acest lucru în MPLS) – vezi nota:


Nota: un pachet P poate totusi fi asignat la un FEC F, iar F sa fie identificat cu un prefix de dresa X chair daca adresa de destinatie a lui Pnu se potriveste cu X.

1.6.1.1 Distribuirea etichetelor pentru prefixe de adresa

1.6.1.1.1 Definiţii

• Rutere-pereche pentru distribuţia etichetelor

Două LSR, R1 şi R2, sunt rutere pereche pentru distribuţia de etichete pentru un prefix de adresă X, dacă şi numai dacă este indeplinită una din următoarele condiţii (Figura 1-31):

1) R1 a aflat o rută spre X printr-o instanţiere particulară de IGP şi R2 este vecin cu R1 în acea instanţiere a IGP

2) R1 a aflat o rută spre X printr-o instanţiere a unui algoritm de rutare A1, ruta aflată este redistribuită printr-un algoritm de rutare A2, şi R1 şi R2 sunt vecini în instanţierea lui A2

3) R2 este capat de transmisie R1 este capat de receptie al unui tunel LSP inclus în altă cale LSP. R1 şi R2 sunt participanţi la o instanţiere comună de IGP (ele sunt în aceeaşi arie dacă IGP are arii de rutare) şi R1 a aflat o rută spre X de la această instanţiere IGP.

4) R1 a aflat o rută spre X de la BGP şi R2 este pereche BGP pentru R1.

Tunel R1 – R2

R2 R1 R3

dest

X

IGP IGP

(1)

R2 R1 R3 dest

X

A1/BGP A2/BGP

(2), (4)

R2 R1 X (3)

IGP

Figura 1-31 Cazuri de perechi pentru distribuţia de etichete

Regulile generale de mai sus asigură :

- dacă o rută spre X estre distribuită prin IGP/BGP atunci ruterele pereche pentru distribuţia de etichete spre X sunt vecini IGP, respectiv BGP.

1.6.1.1.2 Distribuţia etichetelor

Fiecare LSR trebuie

- să lege mai multe etichete pentru fiecare X ce apare în tabelul de dirijare

- şi pentru fiecare X să distribuie prin LDP, etichete pentru X, către toţi LSR pereche pentru acest LSR.

Caz special :

- ruterul în cauză NU a facut el insusi legarea etichetei pentru direcţia X

- ci doar a aflat despre această legatura

El totusi trebuie să distribuie această informaţie.


Ex.:

R1 foloseste BGP şi pe post de distribuitor de etichete şi:

- distribuie info despre rute spre X via BGP,

- In ipoteza: R1 ştie că

- un R2 este " next-hop - BGP " spre X

- şi ştie că R2 a făcut legătura etichetă-X,

- atunci R1 trebuie să distribuie legătura etichetă-X către toţi LSR care sunt pereche BGP cu el .

-

1.6.1.1.3 Folosirea rutelor de tip “nod-cu-nod” ca LSP

Dacă o ruta "hop-by-hop" pe care un pachet P (src, dst) o urmează este <R1,…,Rn>, atunci ea poate fi LSP, cât timp se îndeplinesc condiţiile:

1) există un singur prefix X, astfel încât pentru orice i, 1≤i<n , X este ("best match") în tabelul de dirijare al lui Ri, pentru adresa dst

2) pentru orice i, 1≤i<n, Ri a atribuit eticheta L lui X şi a distribuit L catre R[i-1].

Un LSP al unui pachet se poate prelungi până ce se intâlneşte cu un ruter a cărui tabelă de dirijare are o potrivire mai lungă/mai-buna între adresa dst şi prefixele din tabelul de dirijare.

În acel punct, LSP se termină şi trebuie rulat din nou algoritmul "best match". Figura 1-32, [ ], ilustreaza un exemplu.

R2

dest

X LSP1

10.2.153.78

R3 R1

Adv. 10.2/16 ptr. X Adv. ptr. X 10.2.153/23 10.2.154/23 10.2/16

date

Figura 1-32 Exemplu de LSP spre destinaţia X

Fie destinaţia X= 10.2.153.78. Presupunem că :

- R2 a distribuit ruta 10.2/16, pentru X, spre R1

- R3 a distribuit mai multe rute (unele cu potrivire mai lunga) spre X, catre R2

Concluzii:

R2 a distribuit o rută agregată spre R1.

Pachetul P va fi dirijat pe LSP1 până la R2.

Deoarece R2 a efectuat o agregare de rute când a distribuit informaţia lui R1, în consecinţă R2 va trebui să ruleze din nou algoritmul « best match », pentru a găsi FEC pentru pachetul P. Deci calea LSP1 se termină la R2.

Definitii: Rutere LSP de ieşire ("LSP Egress") şi rutere "proxy-egress":

Un LSR R este "LSP Egress" pentru un prefix X, dacă şi numai dacă se îndeplineşte una dintre condiţiile :

1) pentru o adresă dst=Y a unui pachet, exista un X in tabelul Fwd. al lui R este "longest match"


pentru Y

2) R este un punct de de agregare pentru prefixul X

a. Mai detaliat, R conţine în tabelul de dirijare unul sau mai multe prefixe de adresă Y pentru care X este un subsir propriu,

b. dar ruterul din amonte al lui R nu cunoaşte nici unul dintre aceste prefixe ( vezi figura 1-32)

Un ruter R1 este "LSP Proxy Egress", pentru un prefix X, dacă şi numai dacă se indeplineşte una din condiţiile :

1) Ruterul în aval faţa de R1 ("next hop" al lui R1) pentru destinaţia X, este R2, dar R1 şi R2 nu formează o pereche de distribuţie de etichete (de exemplu, R2 nu cunoaşte MPLS);

2) R1 a fost configurat ca atare (adică Proxy Egress pentru X).

Aceste definiţii permit unui ruter non-MPLS sa fie ruter de ieşire (“ Egress LSR”). În acest caz penultimul ruter din LSP este “Proxy-egress”.

Exista şi o etichetă "Implicit Null" cu semantică specială.

Ea se distribuie de către ruterul de ieşire din LSP către penultimul pentru a indica acestuia din urmă că trebuie să execute pop pentru eticheta asociată unui prefix de adresă X.

Un ruter Rd distribuie în amonte o legatură (“Implicit Null-X”) către Ru dacă şi numai dacă:

1) Rd şi Ru sunt perechi de distribuţie de etichete

2) Rd ştie că Ru suportă procesarea "pop"

3) Rd este "LSP Egress" (nu este "proxy Egress").

Dacă un ruter a fost configurat ca „Proxy-egress”, atunci el în mod automat va lucra în modul PHP.

1.6.2 Utilizarea MPLS LSP cu precizare explicită a rutei

• Se utilizează în MPLS-TE sau în rutarea bazată pe politici („policy based routing”):

o esenţa : o cale LSP nu urmează neaparat ruta indicata drept optimă de catre un protocol IGP.

• Vorbim în aces caz despre tunele LSP cu rutare explicită.

• Ruta poate fi determinată static – prin configurare, sau dinamic prin alte mecanisme (exemplu: „Constrained Based Routing”).

Condiţiile ce trebuie îndeplinite pentru aplicarea unei tehnici de tip tunel cu rutare explicită sunt:

- există

- o metodă de selectare a pachetelor care vor fi trimise prin tunelul cu rutare explicită („Explicitly Routed LSP Tunnel” – ERLT)

- şi o metodă de a selecta fiecare asemenea tunel ERLT

- există o metodă de evitare a buclelor (pachetul transmis prin tunel nu trebuie să se întoarcă la punctul de transmisie al tunelului)

Primul ruter de la intrarea în tunel va face „push” în stivă de etichete a unui pachet de transmis prin tunel, cu o valoare comunicată anterior spre el de către primul „next-hop” din tunel.


1.6.3 Rutarea multi-cale şi arbori de căi LSP

Dacă un ruter LSR poate alege mai multe căi spre o destinaţie X, pentru un flux particular, atunci el poate distribui în amonte către un Ru, nu una ci mai multe etichete diferite, de forma

( L1, X) ( L2, X) ( L3, X),

legate cu o aceeaşi destinaţie X, indicând prin aceasta existenţa de opţiuni în alegerea rutei spre X de către Ru.

• Este posibil a defini şi arbori de căi LSP ca în Figura 1-33, caz în care R3 va distribui aceeaşi etichetă (L2, X) către R1 şi R2.

• Pe linkul R3-R4 se va folosi o aceeaşi etichetă de exemplu L3. Pe acest tronson fluxurile provenind de la R1 sau R2 nu mai sunt distincte din punct de vedere al dirijarii lor prin reţea.

• Notăm că acest mod de lucru crează dificultăţi în cazul ruterelor ATM-LSR care nu pot lucra în mod multi-punct la punct, [ ].

R2

Cale nod-cu-nod <R1, R3, R4 >

(L2, X)

Destinatie

R3

R1

X R4

(L2, X) (L3, X)

Cale nod-cu-nod <R2, R3, R4 >

Figura 1-33 Exemplu de arbori LSP

1.6.4 Tunele LSP între rutere de frontieră BGP

Diferite rutere de frontieră BGP se afla in relatii iBGP sau eBGP.

Ex.: trei domenii autonome AS1, AS2, AS3, interconectate prin ruterele R1, ..R4 care rulează BGP.

AS1

EBGP

R1

AS2

AS3 R2 R3 R4

IBGP EBGP

Figura 1-34 Relaţii EBGP şi IBGP

AS1, AS2, AS3 – domenii autonome

R1, …R4 – rutere de frontieră care rulează protocoale BGP.

• „Interior BGP”: Două rutere care aparţin aceluiaşi AS şi schimbă între ele informaţii despre rute exterioare lui AS ( cunoscute de catre ele), se numesc rutere BGP aflate în relaţie internă – IBGP. Doi vecini interni schimbă între ei mesaje despre rute aflate din alte surse: de la EBGP


sau în mod static.

• „External BGP”: Două rutere care aparţin unor domenii AS diferite şi schimbă între ele informaţii despre rute, se numesc rutere BGP în relaţie externă – EBGP. Vecinii BGP schimbă între ei mesaje despre rute aflate din alte surse: EBGP sau în mod static.

IBGP şi EBGP au în comun

- aceleaşi tipuri de mesaje,

- de atribute ale acestora

- şi o aceeaşi maşină cu stări finite extinsă (EFSM) care le defineşte comportamentul,

dar pot avea reguli diferite privind prefixele de adresă („ advertising prefixes”) pe care le anunţă către vecinii lor:

- prefixele invăţate de la o entitate EBGP pot fi transmise unui vecin IBGP

- prefixele învăţate de la un vecin IBGP nu pot fi transmise altui vecin IBGP- pentru a evita buclele.

AS1

m(x)

R1 AS2 R2

R3

R4

IBGP EBGP

m(x)

m(x)

n(y) n(y)

Nu se transmite n(y) spre R4

x

y

Figura 1-35 Mesaje BGP retransmise

m(x) mesaj – relativ la dest=x, aflat de R2 de la R1 (via EBGP) şi retransmis lui R3 is R4

n(y) mesaj - relativ la dest=y aflat de R2 de la R3 via IBGP şi retransmis numai lui R1

Problema corelata: tranzitarea traficului printr-un domeniu autonom A.

• Presupunem că A are mai multe rutere de frontieră BR care rulează BGP şi o reţea virtuala (“mesh”) de conexiuni BRi - BRj prin care se distribuie informaţiile despre rutele externe lui A.

• Dar traficul de date trebuie să tranziteze domeniul A pe o rută internă lui A.

• Ruterele interne lui A nu sunt interesate şi nici nu este nevoie să cunoască informaţiile privitoare la rutele externe.

• Soluţia uzuală pentru tranzitare este construcţia de tunele de exemplu BRi - BRj .

1.6.4.1 Procedura de stabilire a tunelului

- orice BRj distribuie spre alte rutere BR din domeniul A câte o etichetă pentru fiecare prefix de adresă către care BRj are o rută externă.

- protocolul IGP din A menţine căte o rută de tip “host” (“ host-route”) spre fiecare ruter de frontieră BR. Ruterele interioare din A distribuie între ele aceste informatii cu ajutorul mesajelor IGP.

Considerăm doua scenarii posibile:


Scenariul 1. • Pp: B1 şi B2 sunt vecini - BGP iar B1 primeşte un pachet neetichetat P.

• În tabelul de rutare BGP al lui B1 (Fig.1-36 ) X = cea mai “lungă” potrivire pentru adresa destinaţie din antetul lui P (X poate fi prefix sau adr. completa a unei masini)

• Presupunem că B2 a făcut legătura între eticheta L2-X şi a transmis perechea (L2, X) lui B1.

• Presupunem că prin informaţiile produse de IGP, ruterul intern I1 a făcut legătura L1-B2 ( B2 este privit aici ca “destinatie” a unei noi cai LSP) şi a transmis această pereche lui B1.

• Ruterul B1 va construi un nou tunel MPLS B1-B2 prin acţiunile de tip MPLS asupra pachetului P:

- push L2, push L1 - în stiva lui P

- transmite pachetul cu eticheta L1 în “top” către I1

- în I1 are loc comutaţia etichetei L1 în altă valoare, ş.a.m.d. până ce pachetul ajunge la B2

- B2 elimina (“pop”) nivelul de etichete corespunzător tunelului şi face comutaţia după eticheta L2.

AS

B1 B2

IGP

P

Next hop = I1

(L2, X)

(L1, B2)

X

Tabel BGP Adr Next

hop

X B2

X

L1 L2 P

BGP peers

I1

Figura 1-36 Stabilirea unui tunel printr-un domeniu autonom. Scenariul 1.

Scenariul 2.

• B1 primeşte un pachet etichetat P, cu eticheta L2.

o deoarece P are deja o etichetă “externă”, B1 va face comutaţia L2 → Lk, apoi crează tunelul prin “push L1” şi transmite pachetul etichetat spre I1, etc.

o Deoarece ruterele interioare lui AS nu cunosc legăturile (etichetă - prefix_adresă) făcute de BGP,

� rezultă că ruterele de frontieră BR ( „border router”) trebuie să se afle reciproc în perechi de relaţii explicite ( fiecare cu fiecare) privind distribuţia etichetelor.

1.6.4.2 Un caz special de tunel

Intre două BR din domenii diferite se poate stabili un tunel LSP de tip “hop by hop”, ca în Figura 1-37 extins de la BR1- BR3, din AS1 până la din AS3:

• BR3 distribuie rute la BR2 via EBGP şi opţional atribuie etichete la prefixele de adresă.

• BR2 redistribuie rutele la BR1 (via IBGP), inicând că nodul urmator (“next hop”) pentru fiecare astfel de ruta este BR3.

• Daca BR3 a alocat etichete atunci acestea se transmit nemodificate la BR1, de către BR2.


• Protocolul intern IGP din AS1 are o rută de tip “host” spre BR3.

AS1

EBGP

BR1 AS2

IBGP

BR2 BR3

Zona comuna ce apartine lui AS1 si AS2

(“demilitarizata”)

Figura 1-37 Tunel extins pe linkul dintre două domenii


1.7 MPLS QoS

(English)

No single “official” definition of QoS exists, the following definitions are considered in this paper as authoritative. Some authors distinguished between active and passive QoS definitions.

• A passive definition describes the service quality experienced by traffic transiting a network o QoS is defined as “a set of service requirements to be met by the network while

transporting a connection or flow; the collective effect of service performance which

determine the degree of satisfaction of a user of the service.”

• Active definition refers to the mechanisms that control the service quality experienced by traffic

transiting a network. o “The capability to control traffic-handling mechanisms in the network such that the

network meets the service needs of certain applications and users subject to network policies.”

o We will refer to the relevant traffic-handling mechanisms as “QoS mechanisms.” o QoS Resource Management is active: “network functions” which include

� class-of-service identification, � routing table derivation, � connection admission, � bandwidth reservation and allocation, � bandwidth protection, � priority routing, and priority queuing.”

o In this text, we will use “QoS mechanisms” and “QoS resource management functions” interchangeably.

Summary of the two views:

• QoS seen as the service needs of various applications (given by parameters: bandwidth, delay, jitter, packet loss, preemption, etc.). We will refer to these parameters as QoS variables.

• QoS mechanisms / QoS resource management functions as network control mechanisms that allow a network to satisfy QoS.

Note: In services as seen by the end users the term QoE is used ( “Quality of experience”)

There is a non 1-to-1 mapping between QoS/QoE ( why?) QoS is related to Traffic Engineering from a SP’s point of view. TE methods :

- capacity management and network planning- mid long term - traffic management.

• Capacity management and network planning � ensure future performance of the network,

• Taffic management � refers to optimization of the existing network resources under various

conditions, including load shifts and failures. � encompasses control of routing functions, which include call routing (number or

name translation to a routing address), connection routing, routing table management, QoS resource management, and dynamic transport routing.


Figure 1-1 Mechanisms for Traffic Control in the network

1.7.1 Necessary Conditions for QoS In order to provide QoS for more demanding types of applications (e.g., voice, multimedia), a network must satisfy two necessary conditions.

• bandwidth must be guaranteed for an application under various circumstances, including congestion and failures.

• When application flow traverses the network, it must receive the appropriate class-based

treatment, including scheduling and packet discarding. Note : the two conditions are partially independent (depending on the time interval and toplogy span where the „bandwidth” is measured.

• A flow may get sufficient bandwidth (measured on short term or on a given link) but get delayed on the way, or,

• Alternatively, a flow may be appropriately serviced in most network nodes but get terminated or severely distorted by occasional lack of bandwidth

Conclusion:

• It is necessary to satisfy both conditions (in order to achieve the hard QoS guarantees that are required by service providers and their customers).

• The notion of mean through put can be more relevant ( it includes the effect of the both) Types of QoS guarantees:

• Hard guarantees ( e.g. peak bandwidth assured 100%) • Statistical quantitative (e.g. 95% of time a given bandwidth is assured)

o Or guaranteed minimum plus possible additional bandwidth depending on the network conditions

� Commited Information Rate (CIR), Peak Information Rate ( PIR)


• CIR- hard guarantees • PIR- statistical guarantees

• Statistical qualitative: Platinum, Gold, Silver, Bronze, .., ...etc. • No guarantees (best effort)

1.7.2 Architectural Planes and QoS functions

(see the previous chapter)

Mechanisms dealing with:

Control plane - pathways for user data traffic: Admission control, QoS routing, and resource reservation.

Data plane- transport of user data traffic directly:

• Forwarding ( implicit function)

• traffic classification,

• packet marking,

• traffic policing,

• traffic shaping,

• buffer management,

• congestion avoidance,

• queuing and scheduling

Management plane- the operation, administration, and management aspects of the user data traffic:

• metering,

• policy,

• service level agreement (SLA),

• and service restoration.


Figure 1-2 QoS functional building blocks (ITU-T)

QoS building block may be specific

- to a network node (e.g. buffer management)

- applicable to a network segment (e.g. QoS routing)

The latter, in particular, requires signaling between network nodes:

end to end, end to edge, edge to edge, or network to network.

Signaling can take place in any of the three logical planes

For CPl or MPlane, signaling -> use of a signaling protocol.

For DPL- inband signalling is used.

1.7.3 IP Services • Best Effort – (BE)

Classical internet (TCP/IP stack)

Characteristics


- lowest complexity, lowest service differentiation (and level of guarantees), best scalability - fairness between different flows is an objective - behaviour of applications/transport protocols can influence the obtained QoS - no priorities of some flows, no service guarantees

o the network should do its best to carry packets towards their destination without any guarantee

o BE QoS highly depend on current network load o possible network load control by:

� utilisation of traffic engineering tools � routing policies for interdomain traffic � utilisation of scheduling mechanisms � utilisation of buffer acceptance mechanisms

IntServ

DiffServ

Best Effort

Complexity

Degree of service

differentiation

Scalability

Per flow: QoS processing

Per class QoS processing

No QoS processing

Figure 1-3 IP Services

• Differentiated Services (DiffServ) QoS Technology Characteristics:

Differential treatment of packets based on some marking of them

No distinction between flows inside the core netwwork

Medium scalability

Medium level of differentiation between services

Medium complexity

Diffserv:

- treates a packet based on its class of service as encoded in its IP header - the SP establishes with each user a SLA/SLS ( specifies how much traffic a user may send

within any given class of service - the traffic is then policed at the border of the service provider’s network - Once the traffic enters the network, routers provide it with differentiated treatment (In

contrast to the IntServ approach, the treatment is based not on a perflow basis, but solely on the indicated class of service)

- the overall network is set up to meet all SLAs.


The building blocks relevant to DiffServ:

packet marking

buffer management,

SLA

traffic metering and recording, policing, shaping, scheduling.

The relevant building blocks for MPLS:

buffer management, packet marking, QoS routing, queuing, resource reservation, traffic classification, and traffic shaping.

Diffserv advantages

• Simple implementable mechanisms • Good scalability • Can cooperate with L2 technologies • Preserve classic concepts of TCP/IP ( complexity at the network edge only) • Maintain stateless routers • Extendable to multicast • No out-of band signalling •

Diffserv problems/drawbacks

• No reservation • Diffserv is not a complete QoS technology, but only a set of relative prioritisation

mechanisms o To become a full QoS technology a resource (domain) manager and AC function

is needed • Rough granularity

• Integrated Services ( IntServ )Technology

Characteristics: Basic idea:

Differential treatment of different micro-flows

Reservation based

Fine granularity distinction between flows inside the core netwwork

Low scalability

High level of differentiation between services and hard guarantees possible

High complexity

Intserv:

- Support of real-time delay-sensitive applications

- a flow serviced at a rate slightly higher than its data rate has a bounded delay

- the network can guarantee the delay bound of a flow by per-flow resource reservation

Phases:


- application before sending data, first signals to the network the desired service request (traffic profile, bandwidth and delay requirements)

- The network then determines whether it can allocate adequate resources (e.g., bandwidth or buffer space) to deliver the desired performance of the service request

- Only after the request is granted can the application start to send data

As long as the application honors its traffic profile, the network meets its service commitment by maintaining per-flow state and using advanced queuing disciplines (e.g.,WFQ) for link sharing.

Building blocks relevant to the IntServ:

- admission control (AC) - queuing - resource reservation (RR) ( RR protocol - RSVP) - traffic classification - and traffic policing.

Intserv advantages

• Can offer E2E guarantees (e.g. bandwidth, …) per flow - emulate the telecom channel ( but not fixed allocation)

• Can cooperate with L2 technologies • Preserve classic concepts of TCP/IP ( complexity at the network edge only) • Extendable to multicast • Dynamic- the reservation follows the routes if the latter are cahanged • Follows the route changes •

Diffserv problems/drawbacks

• Complex implementable mechanisms • Fine granularity (per-flow)---> needs large memory • Need statefull routers • Low scalability ( statefull routers- per flow image stored, • Reservation refresh needed

• Combined technologies: Integrated Services ( IntServ )T + Diffserv

1.7.3.1 IntServ with RSVP-details

IntServ has defined the requirements for QoS mechanisms in order to satisfy two goals: (1) to serve real-time applications and (2) to control bandwidth-sharing among different traffic classes.

Two types of service defined : Guaranteed Service (GS)

- provide an assured level of bandwidth, a firm end-to-end delay bound, and no queuing loss; - intended for rt applications such as voice and video

Controlled Load Service (CLS) definition - did not include any firm quantitative guarantees but rather “the appearance of a lightly loaded network.”

- intended for applications that could tolerate a limited amount of loss and delay, including adaptive real-time applications.

- CLS: provided better than BE performance (it would not noticeably deteriorate as the network load increased).

IntServ models included various traffic parameters :


- rate and slack term (depending on delay) (for GS) - average rate, peak rate and burst size for CLS

RSVP : signaling protocol for reservations and explicit admission control. The IntServ arch. has satisfied both necessary conditions for the network QoS,

- i.e., it provided the appropriate bandwidth and queuing resources for each application flow (a “microflow”).

Drawback: per-microflow state and signaling at every hop. (non-scalable) Consequence: IntServ model was implemented only in a limited number of networks (usually at the edge networks) IETF moved to develop DiffServ as an alternative QoS approach with minimal complexity.

1.7.3.2 DiffServ-details

DiffServ - different approach w.r.t IntServ It treats the packets per classes and not individually. It defined Classes of Service (CoS), called Aggregates, and QoS resource management functions with node-based, or Per-Hop, operation. • Network is divided in two parts

- Interior nodes are simple to operate at high speeds

- Boundary nodes (border and edge routers) - complex functionalities

• No change to existing routing protocols

• Provision of different types of service

- The type of service is indicated explicitly inside each IP packet

- Marking can be performed by: customer/ edge router/ border router

- Interior routers only rely on this indication to provide the different types of services

- Complexity of interior routers depends on number of different services, not on number of layer or flows

ER ES

DS Domain A

CR

BR

CR

BR

CR

ES

CR

ER

DS Domain B

Figure 1-4 DiffServ Domains

ER – Edge Router BR – Border Router

ES – End System CR – Core Router


1.7.3.2.1 DiffServ basic terminology ( RFC 2475)

1.7.3.2.1.1 Traffic related definitions

Traffic profile - a description of the temporal properties of a traffic stream such as rate and burst size

Micro-flow (Layer 4 flow) - a single instance of an application-to- application flow of packets which is identified by source address, source port, destination address, destination port and protocol id.

Traffic stream - an administratively significant set of one or more micro-flows which traverse a path segment. A traffic stream may consist of the set of active micro-flows which are selected by a particular classifier.

Traffic Conditioning Agreement (TCA) - an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier.

A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy.

Traffic conditioning - control functions performed to enforce rules specified in the Traffic Conditioning Agreemnt (TCA), including metering, marking, shaping, and policing.

Service Level Agreement (SLA)

- a service contract between a customer and a service provider that specifies the forwarding service a customer should receive

- customer may be a user organization (source domain) or another DS

domain (upstream domain)

- SLA may include traffic conditioning rules which constitute a TCA in whole or in part.

• Service Level Agreement (SLA) –in DS context

- specifies for each service supported by the DS domain the amount of traffic that customer can send inside the network (possibly with some specification of destination)

- network will commit to some performance figures o packet loss rate over some period o end to end delay at key points o network reliability

• Different service quality considerations (requirements/constraints)


Quality consideration Description Units/parameters

Requirement/Constraint from

End-User View

Perceived QoS (PQoS)

User’s perception Platinum/Olympic, Gold, Silver, Bronze

R/C

Application level

Application software (e.g. NetMeeting,

RealPlayer) requirements

Video: Codec, frame size, frame rate, colour depth.

Audio: Number of channels, sampling rate

R/C

Terminal Terminal characteristics Processing power, memory etc. For video terminals: Resolution,

number of colours, frame rate, encoders

C

Access Connectivity

Access “last mile” characteristics

Bandwidth, performance-related information

R/C

Network Network level QoS parameters

Bandwidth/throughput, packet loss, delay, jitter

R/C

Figure 1-5 QoS factors


SLA Element/Clause Attributes/Parameters Description

Resource Digital Item Id Identifier for the Digital Item

Scope Addresses User end-point, Content end-point

Type of service Premium or Olympic Service User perception

Service schedule & Activation time

Service invocation time/date Content delivery start and stop times

Application level (Traffic and Performance) requirements/constraints

MPEG-7 Media Information and Media Format, Service Class canonical meanings

Application performance requirements

Terminal capability MPEG-21 Terminals Descriptor (codecs, processing power)

Terminal capability constraints

Connectivity/Access Access Networks information (MPEG-21 Network Condition descriptor)

Last-mile connectivity information

Availability Guarantees Reliability, Outages, Interface throughput

Guarantees for service invocation

Reliability Guarantees Mean downtime (MDT), Mean time to repair/patch (MTTR)

Service guarantees in terms of reliability

Security Authentication & authorisation parameters etc.

Information required for using the service and accessing the content

Billing By DI content, SP contract, etc. Cost and payment aspects

Others

Figure 1-6 SLA template with clauses (optional/mandatory)


SLS Element/Clause Attributes Description

SLS Identification Key A unique identification key (set by service provider).

Scope Ingress-Egress points Identifies the topological region over which the QoS applies (IP addresses or layer 2 identifiers).

Flow Identification DSCP, source, destination, application information

Defines the stream of IP datagrams.

Traffic Conformance (TC)

TC Algorithm and parameters for in and out of profile packets

Describes the criteria that injected traffic should comply with to get QoS guarantees specified by Performance Guarantee clause. TC information is required for configuring traffic conditioners at the edge and border routers. TC algorithms are leaky bucket, token bucket etc. and TC parameters are peak rate, token bucket depth, etc.

Excess Treatment Action for out-of-profiles packets

Describes how the excess traffic will be treated.

Network Level Performance Guarantees

Delay, loss, jitter, throughput, error

Describes the performance guarantees a provider agrees to offer to the packets entitled to this SLS.

Service Schedule (optional)

Timetable for delivery planning

Describes possible time intervals allowed for service invocation.

Reliability (optional) MDT per-year etc. Describes the allowed figure of non-availability of the service

Figure 1-7 SLS template example

1.7.3.2.1.2 General DS definitions

Service - the overall treatment of a defined subset of a customer's traffic within a DS domain or E2E

DS-compliant entity – an entity supporting DiffServ functions and behaviors as defined in DiffServ standards; usually used in reference to a node or device

DS-capable - capable of implementing differentiated services as described in this architecture; usually used in reference to a domain consisting of DS-compliant nodes

DS field - the IPv4 header ToS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in [DSFIELD]. The bits of the DSCP field encode the DS codepoint, while the remaining bits are currently unused.

DS behavior aggregate (BA) - a collection of packets with the same DS codepoint crossing a link in a particular direction

Per-Hop-Behavior (PHB) - the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate


PHB group- a set of one or more PHBs that can only be meaningfully specified and implemented

simultaneously, due to a common constraint applying to all PHBs in the set

- such as a queue servicing - or queue management policy.

A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group.

DS codepoint (DSCP) - a specific value of the DSCP portion of the DS field, used to select a PHB

Mechanism - a specific algorithm or operation (e.g., queueing discipline) that is implemented in a node to realize a set of one or more PHBs

1.7.3.2.1.3 Regions, nodes

DS domain - a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions

DS boundary node - connects one DS domain to a node either in another DS domain or in a domain that is not DS-capable

DS egress node - a DS boundary node in its role in handling traffic as it leaves a DS domain

DS ingress node - a DS boundary node in its role in handling traffic as it enters a DS domain

DS interior node - a DS node that is not a DS boundary node

DS region - a set of contiguous DS domains which can offer differentiated services over paths across those DS domains

Downstream DS domain - downstream of traffic flow on a boundary link

Upstream DS domain - the DS domain upstream of traffic flow on a boundary link

Legacy node - implements IPv4 Precedence as defined in [RFC791, RFC1812] but which is otherwise not DS-compliant

Provider DS domain - the DS-capable provider of services to a source domain

Boundary link a link connecting the edge nodes of two domains

Source domain - contains the node(s) originating the traffic receiving a particular service.

Service Provisioning Policy - a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS BAs to achieve a range of services.


1.7.3.2.2 Functional blocks within a DS node

Classifier - an entity which selects packets based on the content of packet headers according to defined rules

Traffic conditioner (TCd)

- an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers

- typically deployed in DS boundary nodes only

- TCd may re-mark a traffic stream or may discard or shape packets to

alter the temporal characteristics of the stream and bring it into compliance with a traffic profile

MF Classifier - a multi-field (MF) classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, DS field,

protocol ID, source port and destination port.

Behaviour Aggregate (BA) classifier - selects packets based only on the contents of the DS field Note that it does not matter the identity of each flow

Meter - entity performing the measuring of the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes.

Meter example: Basic Token Bucket Algorithm (TB)

TB - formal definition of a rate of transfer.

TB components: a burst size, a mean rate, and a time interval (Tc).

mean rate = burst size / time interval

• Mean rate – also called Committed Information Rate (CIR): how much data can be sent or forwarded per unit time on average.

• Burst size - also called the Committed Burst (Bc) size: specifies in bits (or bytes) per burst how much traffic can be sent within a given unit of time to not create scheduling concerns.

• Time interval - also called the measurement interval: the time quantum in seconds per burst.

TB - Simple implementable scheme to control (measure) the input rate

R - average rate in bytes/sec

T=1/R – period between two successive tokens

B - size of the token bucket [bytes]

c- current fill of TB = credit, c ≤ B


arriving packets

rate R

token generator

Non-conforming packets

M

Bucket size B

Conforming packets (pass)

Current fill(c= credit)

M= measuring algorithm

Discard/mark

Figure 1-8 Basic Token Bucket scheme

Token generation process:

Initialization: c=B;

every T second do { if(c<B) then c=c+1;}

Arrival of packet P of length L:

if (L ≤ c) then { /* packet is accepted */ c=c-L;}

else { /* packet is discarded-basic treatment of non conforming packets */}

Traffic anvelope A(t) = B+ Rt – maximum traffic accepted by TB in t seconds

• TB advantages - simple implementation - usable in traffic contract to detect conforming/nonconforming packets - R – is a bound on average rate - B is the maximum busrt size for this flow - Traffic anvelope provide a maximum limit of traffic in any time interval (useful to dimension

the data buffers size in the router)

Marker – entity that performs the process of setting the DS codepoint in a packet based on defined rules; pre-marking, re-marking.

- Pre-mark - action to set the DS codepoint of a packet prior to entry into a downstream DS domain

- Re-mark - to change the DS codepoint of a packet, usually performed by a marker in accordance with a TCA.

Dropper - a device that performs dropping (discarding packets based on specified rules; policing)


Shaper - performs shaping (delaying packets within a traffic stream to cause it to conform to some defined traffic profile).

Policer - device performing the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile.

Classifier

Shaper/ Dropper

Meter

Traffic Conditioner

Marker

Figure 1-9 Logical View of a Packet Classifier and

Traffic Conditioner in Edge Router ( RFC 2475)

Classifier

Shaper

Meter

Traffic Conditioner

Marker

Dropper

Figure 1-10 Generalisation of Traffic Conditioner

1.7.3.2.3 DiffServ Main Concepts – used in MPLS

Main definitions used in MPLS-DiffSErv - RFCs 2474 , RFC 2475, RFC 3260

Per-hop behaviour (PHB) in DiffServ or MPLS: It defines the policy and priority applied to a packet when traversing a hop (such as a router) in a DiffServ network.

PHB Scheduling Class: A PHB group for which a common constraint is that, ordering of at least those packets belonging to the same microflow must be preserved.


Behavior Aggregate (BA) : all the IP packets crossing a link and requiring the same Diff-Serv behavior are said to constitute a BA.

• At the ingress node of the DS domain, the packets are classified and marked with a DSCP which corresponds to their BA.

• At each transit node, the DSCP is used to select the PHB that determines the scheduling treatment and, in some cases, drop probability for each packet.

Ordered Aggregate (OA):

A set of BA that share an ordering constraint.

The set of PHBs that are applied to this set of BA constitutes a PHB scheduling class.

Classification and marking

• Network traffic entering a DS domain is classified and conditioned. Traffic may be classified by many different parameters, such as source address, destination address or traffic type and

assigned to a specific traffic class.

• Traffic classifiers may honor any DiffServ markings in received packets or may ignore or override those markings.

• Because network operators want tight control over volumes and type of traffic in a given class, it is frequent that that the network overrides the incoming markings at the ingress to the DiffServ domain: i.e. traffic in each class may be further conditioned by subjecting the traffic to rate limiters, traffic policers or shapers.

The Per-Hop Behavior is determined by the DS field of the IP header.

The DS field contains a 6-bit Differentiated Services Code Point (DSCP) value.

Explicit Congestion Notification (ECN) occupies the least-significant 2 bits of the IPv4 Type of Service field (TOS) and IPv6 Traffic Class field (TC).

In theory, a network could have up to 64 different traffic classes using different DSCPs. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes.

In practice, however, most networks use the following commonly-defined Per-Hop Behaviors:

• Default PHB (Per hop behavior)—which is typically best-effort traffic

• Expedited Forwarding (EF) PHB—dedicated to low-loss, low-latency traffic

• Assured Forwarding (AF) PHB—gives assurance of delivery under prescribed conditions

• Class Selector PHBs—which maintain backward compatibility with the IP Precedence field.

Default PHB

• A Default PHB (a.k.a. Default Forwarding (DF) PHB) is the only required behavior. Essentially, any traffic that does not meet the requirements of any of the other defined classes is placed in the default PHB.

• Typically, the default PHB has best-effort forwarding characteristics. The recommended DSCP for the default PHB is 000000B (0).

Expedited Forwarding (EF) PHB

• The IETF defines Expedited Forwarding behavior in RFC 3246. • The EF PHB has the characteristics of low delay, low loss and low jitter.


• These characteristics are suitable for voice, video and other realtime services. EF traffic is often given strict priority queuing above all other traffic classes.

• Because an overload of EF traffic will cause queuing delays and affect the jitter and delay tolerances within the class, EF traffic is often strictly controlled through input rate control ( i.e admission control performed in Data Plane), policing and other mechanisms.

• Typical networks will limit EF traffic to no more than 30%—and often much less—of the capacity of a link.

• The recommended DSCP for expedited forwarding is 101110B (46 or 2EH).

Voice Admit (VA) PHB

• The IETF defines Voice Admit behavior in RFC 5865. • The Voice Admit PHB has identical characteristics to the EF PHB. • But Voice Admit traffic is also admitted by the network using a Call Admission Control (CAC)

procedure. • The recommended DSCP for voice admit is 101100B (44 or 2CH).

Assured Forwarding (AF) PHB group

• The IETF defines the AF behavior in RFC 2597 and RFC 3260. • AF allows the operator to provide assurance of delivery as long as the traffic does not exceed

some subscribed rate. • Traffic that exceeds the subscription rate faces a higher probability of being dropped if

congestion occurs. • The AF behavior group defines four separate AF classes with Class 4 having the highest

priority. • Within each class, packets are given a drop precedence (high, medium or low). The

combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see table)

Assured Forwarding (AF) Behavior Group

Class 1 (lowest) Class 2 Class 3 Class 4 (highest)

Low Drop AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)

Med Drop AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)

High Drop AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)

• Some measure of priority and proportional fairness is defined between traffic in different classes.

• Should congestion occur between classes, the traffic in the higher class is given priority.

• Rather than using strict priority queuing, more balanced queue servicing algorithms such as fair queuing or weighted fair queuing (WFQ) are likely to be used.

• If congestion occurs within a class, the packets with the higher drop precedence are discarded first.

• To prevent issues associated with tail drop, more sophisticated drop selection algorithms such as random early detection (RED) are often used.

Class Selector (CS) PHB


• Prior to DiffServ, IPv4 networks could use the Precedence field in the TOS byte of the IPv4 header to mark priority traffic.

• The TOS octet and IP precedence were not widely used.

• The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks.

• In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the Class Selector PHB.

• The Class Selector code points are of the form 'xxx000'. The first three bits are the IP precedence bits. Each IP precedence value can be mapped into a DiffServ class.

• If a packet is received from a non-DiffServ aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.

1.7.3.2.4 Topological QoS Classes (CoS) Definitions

A QoS transfer capability, is a set of attribute-value pairs, where the attributes express various packet transfer performance parameters such as

one-way transit delay,

packet loss,

inter-packet delay variation (jitter),

and their particular values.

A provider domain’s supported (CoS or QCs) are divided into - local QoS classes (l-QCs) and

- extended QoS classes (e-QCs),

to allow us to capture the notion of QoS capabilities across domains.

Note that the bandwidth itself is not a QoS parameter ( but how the necessary bandwidth is assured for a given flow – is a QoS parameter)

From a service offering perspective, QoS classes correspond to the performance (transfer quality) guarantees expressed in contracts as SLSs.

From a service provisioning perspective, QoS classes split the network QoS space into a number of distinct classes, and hence set the traffic-related objectives of traffic engineering functions. The concept of l-QC could be compared to the differentiated services (DiffServ) per domain behaviors (PDBs).

. • QoS class (QC): is a basic network-wide QoS transfer capability of a single provider’s domain. It

is defined (in Diffserv technology, but not only) as a set of parameters expressed in terms of {Delay, Jitter, Latency}.

• Local QC (l-QC): a QC that spans a single Autonomous System (AS). This is a notion similar to Per Domain Behaviour (PDB) –in Diffserv technology).

• Extended QC (e -QC): a QC that spans several ASes. It consists of an ordered set of, l-QCs. The

topological scope of an e-QC therefore usually extends outside the boundaries of the local domain.

1.7.3.2.5 CoS Defined in DiffServ technology-standards The CoS definitions include a


- Behavior Aggregate (BA) which has specific requirements for scheduling and packet

discarding, and an - Ordered Aggregate (OA) which performs classification based on scheduling requirements

only, and may include several drop precedence values. Thus, an OA is a coarser classification than a BA and may include several BAs. The node behavior definitions correspond to the CoS definitions.

• Per Hop Behavior (PHB) is offered to a BA; PHB mechanisms include scheduling and packet discarding

• a PHB Scheduling Class (PSC) serves an OA; it only concerns scheduling. DiffServ redefined the the 8-bit ToS field in the IP header. Now the field is split into the 6-bit DiffServ Code Point (DSCP) value and the 2-bit Explicit Congestion Notification (ECN) part, as shown in Figure 1-2.

Figure 1-11 Relationship between ToS and DiffServ / ECN

D = Delay, T = Throughput, R =Reliability, C = Cost, ECN = Explicit Congestion Notification. DSCP field value specifies a BA (i.e., a class), which is used by DiffServ-compliant nodes for choosing the appropriate PHB (i.e., a queue servicing treatment). In practice only fourteen PHBs have been defined, including

one for Expedited Forwarding (EF), twelve for Assured Forwarding (AF) one for Default, or Best Effort

The twelve AF PHBs ( see above table)

- are divided into four PSCs, - and each of the AF PSCs consists of three sub-behaviors related to different packet discarding

treatment.

• Packet Marking

Redefining the ToS field of IP packets


Figure 1-12 IP ToS field and DSCP (1)

Type of ServicePrecedence

RFC 1122Must

BeZero

IP Type of Service (TOS)

0 32 4 5 6 71

MBZ

RFC 1349

DSCP

Class Selector Unused

0 32 4 5 6 71

Differenciated Services

Codepoint (DSCP)

CU

Figure 1-13 IP ToS field and DSCP (2)


Figure 1-14 DiffServ Marking

1.7.3.2.6 DiffServ Functions

Figure 1-15 DiffSErv QoS capable router – generic diagram

Summary Advantages:

• DiffServ allows the network to classify (combine) microflows into flow aggregates (BAs) and then to offer to these aggregates differentiated treatment in each DS node.

• This treatment is reflected in the queue servicing mechanisms which include scheduling and packet discarding.

• PHB is reflected in both scheduling and discarding, • whereas PSC applies only to scheduling. • DS is scalable – largely applied in the nets


Drawback:

• DS satisfies only the second QoS condition (scheduling)- but not bandwidth (only a relative treatment)

• It is not complete QoS technology ( lack of AC)

Figure 1-16 Policing and shaping

1.7.4 MPLS cooperation with with DiffServ

1.7.4.1 MPLS Support of DiffServ

DiffServ and MPLS can be combined for QoS assurance. DS cannot guarantee QoS, because it does not influence a packet path, and therefore, during a congestion or failure, even high-priority packets do not get guaranteed bandwidth. However, MPLS, can force packets into specific paths and - in combination with constraint-based routing - can guarantee bandwidth for FECs. But in its basic form MPLS does not specify class-based differentiated treatment of flows. Combining the DS -based classification and PHBs with MPLS-based TE leads to true QoS in packet backbones. What is Unchanged in MPLS DiffServ

Functional components (TCA/PHB) and where they are used Classification, marking, policing, and shaping at network boundaries Buffer management and packet scheduling mechanisms used to implement PHB – PHB definitions • EF: low delay/jitter/loss • AF: low loss • BE: No guarantees (best effort)


Figure 1-17 MPLS-DiffServ cooperation [ ]

Prec/DSCP field is not directly visible to MPLS Label Switch Routers (they forward based on MPLS Header and EXP field)

• Information on DiffServ must be made visible to LSR in MPLS Header using EXP field / Label. • How do we map DSCP into EXP ? Interaction between them.

Figure 1-18 Example of DSCP – EXP mapping [ ]

The mechanisms for MPLS support of DiffServ are described in RFC3270 [MPLS-DiffServ]. However, RFC3270 does not recommend specific EXP values for DS PHBs (EF/AF/CS) Problem: IP DSCP = 6 bits while MPLS EXP = 3bits

• Solution: where 8 or less PHBs are used, those can be mapped into EXP fielduse “E-LSPs with preconfigured mapping”

• Solution: where more than 8 PHBs are used in core, those need to be mapped in both “label and EXP”-->”LLSPs” are needed

• [MPLS-DiffServ] defines two types of LSPs:

- E-LSPs and


- L-LSPs. E-LSP

• a label is used as the indication of the FEC destination, and the 3-bit Exp field is used as the indication of the class of a flow in order to select its PHB, including both scheduling and drop priority.

• Note that DiffServ uses 6 bits to define BAs and the corresponding PHBs, whereas E-LSP has only 3 bits for this function. (1-to-1 mapping not possible)

L-LSP

• a label is used as the indication of both the FEC destination and its scheduling priority.

• The Exp field in an L- LSP is used only for the indication of the drop priority.

Note RFC 5462- Feb 2009

(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field

The early MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

The intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field because the CoS use was not sufficiently defined at that time. Today a number of standards documents define its usage as a CoS field.

RFC 5462

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label

| Label | TC |S| TTL | Stack

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

Label: Label Value, 20 bits

TC: Traffic Class field, 3 bits

S: Bottom of Stack, 1 bit

TTL: Time to Live, 8 bits


Figure 1-19 Types of Label Switched Paths [ ]

Both E-LSP and L-LSP can use LDP or RSVP for label distribution

Figure 1-20 Another view of mapping between an DSCP IP header and an MPLS shim header for

an E-LSP

Figure 1-21 Another view of mapping between an IP header and an MPLS shim header for an L-LSP


“5-tuple” = five fields in an IP packet header ( src-IP, dst-IP addresses, src-port, dst-port, protocol indicator ) that can be used for defining a FEC.

• E-LSPs o advantages: easier to operate, and are more scalable because they preserve labels and use

the EXP field for DiffServ features. o drawbacks: MPLS signaling reserves bandwidth on a per-LSP basis, the bandwidth is

reserved for the entire LSP without the PSC-based granularity, and there may be insufficient bandwidth in queues serving some particular PSCs.

• L-LSPs

o advantages: (because a label carries the scheduling information) when bandwidth is reserved for a given L-LSP, it is associated with the priority queue to which this LSP belongs.

o drawbacks : more cumbersome to provision, because more labels are needed to tag all PSCs of all FECs.

Figure 1-22 MPLS DiffServ Topology

Example to illustrate

- how routing and QoS improve network routing by using basic MPLS - and then DiffServ Support of MPLS.


Figure 1-23 Packet flow in MPLS without DiffServ

Figure 1-23

- path taken by packets that follow shortest path routing (1) - and a traffic-engineered path (2).

Path (2) may have been chosen because it has sufficient bandwidth to serve a given FEC, but this bandwidth is not associated with any specific class of service, and thus priority traffic (for example, VoIP) may not have sufficient bandwidth for its particular queue.

Figure 1-24 Packet flow in MPLS with DiffServ

Figure 1-19 illustrates an improvement w.r.t previous case. Paths (1) and (2) of the previous figure are shown here in dashed lines for reference. MPLS support of DS technology is deployed, and bandwidth reservations can be made with respect to specific priority queues. Example:

• Let us assume that VoIP traffic uses queue-0, which is the top queue in every LSR.


• LSR-4 may have sufficient bandwidth across all of its queues, but it does not have enough bandwidth in queue-0, and therefore, path (2) will not provide QoS that is appropriate for the VoIP traffic.

• Solution example: if an L-LSP is used with queue-0-specific bandwidth reservations, then traffic can be routed along path (3) LSR-2, and VoIP is delivered with guaranteed QoS.

Summary

• MPLS support of DiffServ satisfies both necessary conditions for QoS: guaranteed bandwidth

and differentiated queue servicing treatment. • MPLS

o satisfies the first condition, i.e., it forces applications flows into the paths with guaranteed bandwidth;

o and along these paths, DiffServ satisfies the second condition by providing differentiated queue servicing.

MPLS + DiffServ is still simpler and more scalable than IntServ with Standard RSVP.

• IntServ o requires per-microflow signaling and per- microflow states in each router.

• In contrast, o LSPs may themselves be aggregations of many microflows and thus require less

signaling. o Additionally, routers do not keep per- flow states. o Instead, LSRs keep aggregated information on the bandwidth availability for all LSPs or

for each priority queue.

1.7.5 DiffServ-Aware MPLS Traffic Engineering To achieve (MPLS+ DS) – and the resultant QoS –these networks have to be carefully engineered with TE applied on a per-class basis as opposed to the aggregated TE described in section above. IETF TE-WG : specs on DiffServ-aware MPLS Traffic Engineering (DS-TE) DS-TE goal of is to guarantee bandwidth separately for each type of traffic in order to improve and optimize its compliance with QoS requirements. The DS-TE model modifies the existing, aggregate-based TE model by enabling a more-granular, CoS-based TE, where

• a Class of Service (CoS) is defined by the model as a set of Ordered Aggregates (OA) generalized from the link level to the network level.

In the DS-TE model, the CoS-based bandwidth guarantee is achieved by two new network functions:

1. separate bandwidth reservations for different sets of traffic classes and 2. admission-control procedures applied on a per-class basis.

To describe these two functions, the DS-TE model introduces two new concepts:

1. Class-Type (CT) is a grouping of Traffic Trunks (TT) based on their CoS values so that they share the same bandwidth reservation, and where a single CT can represent one of more classes; and 2. Bandwidth Constraint (BC) is a limit on the percentage of a link’s bandwidth that a particular CT or a group of CTs may take up.

The relationships between CTs and BCs are defined in the Bandwidth Constraint Models

(BC Models).

Examples: two BC Models defined by TE-WG:


1. Maximum Allocation Model (MAM) assigns a BC to each CT (Figure 7 below)

Figure 1-25

2. Russian Dolls Model (RDM) assigns BC to groups of CTs in such a way that

- CT with the strictest QoS requirements (e.g., CT7 for VoIP) receives its own bandwidth reservation, BC7

- a CT with the next strictest QoS requirements, CT6, shares bandwidth reservation BC6 with CT7 (BC6 > BC7);

and so on, up to CT0 (e.g., Best Effort traffic) which shares BC0 (i.e., the entire link bandwidth) with all other types of traffic.

Figure 1-26 Russian Dolls Model (RDM)

The DS-TE model also defines a mechanism that allows the release of shared bandwidth occupied by lower priority traffic when higher priority traffic arrives. It introduces the concept of Traffic Engineering Class (TE-Class), where a TE-Class is defined by two parameters:

- Class-Type (CT) and - preemption priority (p).


Two or more TE-Classes may contain - the same CT with different p values, - or different CTs with the same p values,

thus enabling preemption and reservations of LSPs within and between CTs. In order to implement DS-TE, the IGPs (OSPF-TE and ISIS-TE) and the LDP (RSVPTE) must be extended beyond the currently defined MPLS-TE-based extensions to carry additional information. Note that [DSTE-PRO] does not repeat the definitions, TLVs and objects defined in [OSPF-TE], [ISIS-TE], and [RSVPTE], but it only introduces new components and modifications.

[DSTE-REQ] F. Le Faucheur, “Requirements for Support of Diff-Serv-aware MPLS

Traffic Engineering,” draft- ietf-tewg-diff-te-reqts-07.txt, Feb. 2003.

• For extended IGPs it defines additional sub-TLVs that carry values of BC and Unreserved Bandwidth for each TE-Class.

• Likewise, RSVP-TE is extended by specifying in Path messages a new “CLASSTYPE object” which includes a CT field.

• Thus, the extended protocols allow an LSR to manage accounting and decision-making on a per-class basis.

• For example, an LSR can o calculate the bandwidth utilized by all existing traffic trunks on the per-CT and per-

preemption priority basis, o make a decision on whether to admit a new TT that is being set up by a Path message,

and compute unreserved bandwidth values to be used by IGPs. Conclusions:

• The DS-TE model provides a lot of flexibility for the implementation of TE • For example, it allows

o assignment of CTs to an LSR scheduler queue and, o when a scheduler enforces bandwidth, the scheduler adjusts the bandwidth parameters of

each queue to the reservation state of the traffic grouping it services. • The adjustment of the schedulers can be made dynamically, as reservations by new class-based

LSPs increase and decrease, or statically, by aligning scheduler configuration with properly anticipated loads.

1.8 Label Distribution Protocols (LDP)

English

• Two methods (i.e. protocols) of labels distribution

– Piggyback the labels on an existing IP routing protocol

– Have a separate protocol distribute labels

Piggyback the Labels on an Existing IP Routing Protocol

• In this way, the existing IP routing protocol needs to be extended to carry the labels


• Advantage : the routing and label distribution are always in sync, which means that you cannot have a label if the prefix is missing or vice versa

• The implementation for DV routing protocol is straightforward, since each router originates a prefix from its routing table. The router then just binds a label to that prefix

• Link State (LS) routing protocol do not function in this way since each router originates link state updates that are then forwarded unchanged by all routers inside one area

• The problem is that for MPLS to work, each router needs to distribute a label for each prefix even the routers that are not originators of that prefix

• Solution: if LS routing protocols are applied in the domains, then a separate protocol is

preferred to distribute the labels

• Real life:

• none of the IGPs have been changed to deploy the first method.

• However, BGP can carry prefixes and distribute labels at the same time. That is why BGP is used primarily for label distribution in MPLS VPN networks.

Separate Protocol for Label Distribution

• Advantage of being routing protocol independent

• Several varieties of protocols distribute labels:

– Tag Distribution Protocol (TDP)

– Label Distribution Protocol (LDP)

– Resource Reservation Protocol (RSVP)

• TDP : first CISCO proprietary protocol for label distribution.

• IETF later formalized LDP.

– LDP and TDP are similar in the way they operate, but LDP has more functionality

• RSVP is used for MPLS TE (traffic engineering) only

1.8.1 Label Distribution with LDP

1.8.1.1 General features

• LDP is a protocol defined for label distribution (RFC 3036 in 2001) .

• LDP is currently defined by the IETF (RFC 5036) to distribute labels, build and maintain LSP databases (to forward traffic); the exchange of information is bi-directional

• It contains procedures and messages by which LSRs establish LSPs by mapping network-layer routing information directly to data-link layer switched paths. LDP associates a FEC [RFC3031] with each LSP it creates.

• Two LSR (LDP peers) exchange label mapping information.

• These LSPs may have an endpoint at

o a directly attached neighbor (comparable to IP hop-by-hop forwarding),

o or may have an endpoint at a network egress node, enabling switching via all intermediary nodes.

• The FEC associated with an LSP specifies which packets are "mapped" to that LSP.


• LSPs are extended through network as each LSR "splices" incoming labels for a FEC to the outgoing label assigned to the next hop for the given FEC.

• LDP relies on the underlying routing information provided by an IGP in order to forward label packets.

• The router FIB is responsible for determining the hop-by-hop path through the network.

• Unlike traffic engineered (TE) paths, which use constraints and explicit routes to establish end-to-end LSPs), LDP is used only for signaling best-effort LSPs.

• LDP can be used to distribute the inner label (VC/VPN/service label) and outer label (path label) in MPLS.

• For inner label distribution, targeted LDP (tLDP) is used.

• Details: LDP and tLDP discovery runs on UDP port 646 and the session is built on TCP port 646.

o During the discovery phase hello packets are sent on UDP port 646 to the 'all routers on this subnet' group multicast address (224.0.0.2).

o However, tLDP unicasts the hello packets to the targeted neighbor's address.

1.8.1.2 Messages

LDP has four categories messages :

1. Discovery: to announce and maintain the presence of an LSR in a network.

2. Session: to establish, maintain, and terminate sessions between LDP peers.

3. Advertisement : to create, change, and delete label mappings for FECs.

4. Notification : to provide advisory information and to signal error information.

1.8.1.3 Summary of Operation

• For every IGP IP prefix in its IP routing table, each LSR creates a local binding—that is it binds

a label to the IPv4 prefix

• The LSR then distributes this binding to all its LDP neighbors. Those received bindings become remote bindings

• The neighbors then store these remote and local bindings in a special table, the label information base (LIB)

• Each LSR has only one local binding per prefix, at least when the label space is per platform. If the label space is per interface, one local binding can exist per prefix per interface

• The LSR can get more than one remote binding per prefix because it usually has more than one adjacent LSR

• LSR then needs to pick only one and use that one to determine the outgoing label for that IP prefix

• The LSR choose the remote binding received from the downstream LSR, which is the next hop in the IP routing table for that prefix

• It uses this information to set up its label forwarding information base (LFIB) where

• the label from the local binding serves the incoming label

• and the label from the one remote binding serves as the outgoing label


129; Data

Phase 1

Phase 2 17; Data 33; Data

Figure 1-27 Phase 1: LDP actions; Phase 2: MPLS switching

TLDP

• Targeted LDP sessions are different because during the discovery phase “hellos” are unicast to

the LDP peer rather than using multicast.

• A consequence of this is that tLDP can be set up between non-directly connected peers whereas non-targeted LDP peers must be on the same subnet. tLDP may still be used between connected peers if desired.

RSVP-TE

• This method determines a path through the network based on the interior gateway protocol's view of the network.

• If no constraints are applied to the LSP then the routers simply send the request for a path to the active next hop for that destination, without explicit routing.

• The IGP at each router is free to select active next hops based on the link state database.


2 ANEXE

2.1 Metode de codificare pentru ATM_MPLS:

1. Codificare SVC ("Switched Virtual Circuit"): se foloseşte VPI,VCI pentru a codifica eticheta din vârful stivei. Această metodă poate fi utilizată în orice reţea. Protocolul de distribuţie a etichetelor LDP devine protocol de "semnalizare" ATM. Observăm că, comutatoarele ATM-LSR nu pot face operaţii de eliminare şi adăugare a etichetelor din stivă.

2. Codificarea SVP ("Switched Virtual Path"): se foloseşte VPI pentru a codifica eticheta din vărful stivei şi VCI pentru a codifica următoarea etichetă din stivă, dacă există. În acest caz, ATM-LSR efectuează numai comutaţie de fascicule virtuale (VP)

3. Codificarea SVP multipunct (“SVP Multipoint Encoding”): se foloseşte VPI pentru a codifica eticheta din vârful stivei, o parte din VCI pentru a codifica următoarea etichetă din stivă (dacă există), şi partea rămasă din VCI pentru identificarea nodului LSR "ingress". Metoda este folosită pentru VP-uri multipunct-la-punct cu condiţia ca punctele de intrare să fie codificate cu VCI diferite. Dacă în stivă există mai multe etichete astfel încât spaţiul de biţi VPI, VCI nu este suficient, atunci se poate folosi o încapsulare combinată (generică şi VPI/VCI).

Apare problema interoperabilităţii celor doua tehnici de codificare a etichetelor. Arhitectura MPLS prevede că pot exista căi LSP de-a lungul carora se pot folosi tehnici diferite de codificare a etichetelor în noduri de reţea diferite. Când primeşte un pachet etichetat, un LSR trebuie să decodifice pachetul pentru a afla valoarea etichetei, apoi execută « swap » şi operează asupra stivei pentru a determina noua etichetă şi apoi codifică noua valoare în functie de tipul I/F de ieşire. Totusi, comutatoarele ATM nu pot face translaţia între tehnicile de codificare. Este necesar ca două LSR-ATM successive să folosească aceeaşi tehnică de codificare.

Dacă un LSR are interfeţe cu încapsulare generică şi interfeţe de tip LC-ATM, atunci el trebuie să fie capabil a efectua translaţia.

2.2 Opţiuni pentru reducerea numărului de etichete

În practică are importanţă aplicarea, dacă este posibil,a unor metode de reducere a numărului de etichete, deoarece anumite comutatoare/rutere utilizate în context MPLS pot avea limitări asupra numărului maxim de etichete tratabile.

Una dintre aceste metode este alocarea de etichete orientată spre un ruter de ieşire („Egress Targeted

Label Assignment”). Ideea de bază este căa dacă un ruter de intrare Ri („Ingress LSP”), cunoaşte că pachetele care aparţin unor clase FEC diferite, vor urma aceeaşi LSP către un ruter de ieşire Re („Egress

Router”), atunci Ri poate aloca aceeaşi etichetă pentru toate FEC în cauză.

Condiţiile necesare şi suficiente ca să se poată face această acţiune sunt:

1. adresa lui Re se găseşte în tabelul de dirijare al lui Ri ca o adresă „ host-route” şi

2. Ri poate afla într-un mod oarecare ca Re poate fi Egress-Router pentru un anumit grup de clase FEC

Modurile în care informatiile din condiţia 2. se pot afla de către Ri sunt descrise în continuare:

a. toate nodurile respectivei arii suportă MPLS şi existăa un algoritm de tipul „link state” care poate informa pe Ri asupra rutelor prin care pachetele din FEC respective pot ieşi din domeniul/aria de rutare, spre destinaţia dorită

b. reţeaua rulează un protocol BGP, deci Ri poate determina ca o clasă FECi particulară, poate părăsi reţeaua printr-un anumit ruter Re, care este şi pereche de tip BGP cu ruterul Ri şi „BGP


next-hop” pentru acea clasă FEC

c. LDP – poate distribui informaţii despre anumite prefixe de adresă ataşate unor „LSP-Egress”.

Aceasta ar evita necesitatea existenţei unui algoritm de rutare de tipul ”link state”

O reţea se poate configura ca în mod implicit să lucreze cu opţiunea („Egress Targeted Label

Assignment”), iar eventual anumite rutere să nu o aplice.

2.3 Stiva de etichete şi imperecherea implicită

O problemă de interes practic este aceea în care un ruter Re este „Proxy-Egress”, pentru n prefixe de adrese primite pe n interfeţe distincte. Cum va aloca Re etichete în amonte? RFC 3031 propune mai multe soluţii:

- Re alocă acelaşi prefix L . Prin aceasta Re devine „LSP Egress” pentru cele n prefixe de adresă. Totuşi pentru a putea determina pe care I/F de ieşire va trebui să scoată fiecare pachet, Re va trebui să examineze antetul de nivel L3 şi să facă „look-up” pentru fiecare pachet în parte.

- Re alocă individual, câte o etichetăa distinctă fiecărei I/F de intrare. Astfel, Re devine un „Proxy-Egress”pentru cele n prefixe de adresă. Re nu mai trebuie să facă analiza antetului L3 pentru a detrermina pe care I/F de ieşire trebuie să dirijeze un pachet. În schimb numarul de etichete consumate este mare.

- Re leagă cele n prefixe cu o etichetă comună L, de nivel 1 (eticheta este legată şi cu adresa lui Re insuşi); Re leagă câte o etichetă distinctă (de nivel 2). Aceasta va fi tratată ca un atribut al etichetei de nivel 1 – de unde şi denumirea de „Stack Attribute”

Se impun urmatoarele reguli de functionare, valabile în situaţia în care:

- Ru etichetează un pachet P, neetichetat, având o adresă de destinaţie X

- cea mai „lungă” potrivire pentru X, gasită de Ru, îl indică pe Rd ca „nexthop” al lui Ru

- Rd a distribuit lui Ru o etichetă L1 legată de X, impreună cu un atribut în stiva L2.

Regulile sunt:

- Ru execută „push L2” şi apoi „push L1” în stiva de etichete a lui P

- Ru dirijează pachetul spre Rd

- când Ru distribuie eticheta asociată de el lui X, către ruterele din amonte, el va include L2 ca un atribut în stiva de etichete

- actualizează atributul din stivă în situaţia în care ar apărea modificări ale acestuia.

Observăm că eticheta asociată lui X distribuită spre amonte se poate schimba de la un ruter la altul, în schimb eticheta L2 stabilită de „Proxy-egress” se transmite nemodificată. În acest fel, „LSP Proxy” devine un ruter pereche implicită pentru fiecare LSR în acea arie sau domeniu. Imperecherea explicită aplicată în acest caz ar fi ineficienta din cauza că numarul de rutere-pereche ar fi prea mare.

2.3.1.1.1 Elemente de unificare a etichetelor în cazul interfeţelor ATM-LC

Problema principală a unificarii etichetelor în acest caz, este aceea că dacă mai multe fluxuri diferite de celule ATM primesc o aceeaşi etichetă VPI/VCI iar celulele lor sunt intercalate în timp pe legătura de date, atunci nu mai este posibilă identificarea fluxurilor originale şi deci nici reasamblarea din celule a datagramelor. RFC 3031 propune două soluţii, prezentate sumar mai jos.

a. Unificarea de etichete la nivel de VP („VP merge”)

Această metodă este utilizată în contextul codificării „SVP multipoint-to-point”. Presupunem un LSR şi la intrarea acestuia în fluxuri etichetate diferit, dar care aparţin la aceeaşi FEC. Pentru unificarea etichetelor în LSR se foloseşte la ieşirea acestuia: o etichetă VPI comună pentru cele n fluxuri; n etichete


VCI distincte pentru cele n fluxuri. Astfel se poate face distincţia între fluxurile de celule diferite. Schema de unificare a etichetelor este:

{(VPI1, VCI1), …(VPIn, VCIn)} → {(VPIc, VCI1), …( VPIc, VCIn)}, unde VPIc este eticheta comună la nivel de fascicul virtual, observabilă la ieşirea LSR unificator de etichete.

b. Unificarea de etichete la nivel de VC („VC merge”)

În acest caz se foloseste un identificator comun VPI/VCI pentru celulele ATM provenind de la n fluxuri unificate prin etichetă. Identitatea datagramelor din care au provenit celulele l ATM se menţine prin evitarea intercalarii în timp a celulelor unor datagrame diferite. Se foloseşte indicatorul de sfarşit de datagramă al lui AAL5, pentru a marca ultima celulă ATM dintr-o datagramă (mesaj).

Metoda a. are avantajul că este compatibilă cu un numar mai mare de comutatoare ATM întâlnite în practică precum şi faptul că nu necesită memorare şi întarzieri – necesare în metoda b. pentru evitarea intercalarii celulelor din pachete diferite.

2.3.1.1.2 Inter-operarea nodurilor cu interfeţe de celule ATM

Considerăm mai multe cazuri/exemple.

a. ATM-LSR cu unificare la nivel de VC.

Fie legătura Rum - Rd unde Rum este un ATM LSR „up” de tip „VC-merge” iar Rd un ATM-LSR oarecare. Rum va cere de la Rd o singură etichetă VPI/VCI şi va evita intercalarea celulelor din pachete diferite.

b. ATM-LSR de tip „VC-non-merge”

Ru este de tip „VC-non-merge”. El va cere de la Rd un număr de etichete VPI/VCI egal cu numarul de fluxuri pe care doreşte să le unifice şi în plus va cere etichete făcând releu pentru cereri similare sosite spre el din amonte de la alte ATM-LSR.

c. ATM-LSR de tip „VP-merge”

Rum este de tip „VP-merge”. Presupunem ca Rum doreşte să unifice trei etichete a trei fluxuri diferite. El va cere de la Rd o singură etichetă VPI şi trei etichete VCI, ca să poată identifica cele trei fluxuri de celule.

d. Două ATM-LSR1 (Rum1) şi LSR2 (Rum2) de tip „VP-merge” urmate de un LSR3 (Ru3) de tip „VP-non-merge”

Flux1

Flux6

Cereri etichete

Rum1

Ru Rd3

Ru

Rum2

Ru

“VP-merge”

“VP-merge” “VP-non-merge”

Figura 2-1 Configuraţie de noduri ATM-LSR

Rd3 va face în aval următoarele cereri de etichete:

- cerere de VPI/VCI pentru el traficul cu originea în el însuşi

- cerere de VPI plus un set de VCI-uri pentru Rum1

- cerere de VPI plus un set de VCI-uri pentru Rum2.

În concluzie, pentru ca o reţea MPLS să poată suporta configuraţii mixte de tipul „VC-merge”, „VP-merge”, ‚non-merge”, este necesar ca ruterele LSR să poată cere de la cele din aval de ele combinaţii de etichete:


• n ≥ 0 identificatori de VC ( constând în VPI/VCI)

• n ≥ 0 identificatori de VP ( identificatori VPI)

Fiecare dintre aceşti identificatori poate conţine un numar specificat de VC-uri.


3 REFERINTE

arhitecturi pentru retele integrate de banda larga

Documents