Arhitecturi Pentru Retele Integrate de Banda Larga

ARHITECTURI PENTRU RETELE INTEGRATE DE BANDA LARGA
Master sem II 2012- 2013 Specializari: RITC

Prof. Eugen Borcoci
ARIBL-RITC Master 2012-2013
page
Continut
1 COMUTAIA DE ETICHETE MULTIPROTOCOL (MPLS) 1.1 CONCEPTE DE BAZA PENTRU MULTI-PROTOCOL LABEL SWITCHING - MPLS 1.2 AVANTAJE ALE TEHNOLOGIEI MPLS 1.3 DEFINIII I TERMINOLOGIE MPLS 1.4 ETAPELE DE FUNCIONARE N RUTAREA IP I N MPLS 1.4.1 Rutarea convenional (IP) 1.4.2 Rutarea bazat pe MPLS 4 4 5 6 7 7 8
1.4.2.1 1.4.2.2 1.5.1.1 1.5.1.2

1.5.2
Etapele de funcionare ale MPLS Comparaie intre un ruter tradiional i un ruter MPLS Formatul etichetei MPLS Incapsularea MPLS Faza de control Faza de dirijare (transfer al fluxurilor de pachete)
8 9
10 10
1.5 ELEMENTE DE BAZA ALE MPLS 1.5.1 Codificarea etichetelor
10 11
14
Detalierea fazelor de operare MPLS
1.5.2.1 1.5.2.2
1.5.3 1.5.4 1.5.5
14 15
16 17 20
Decizia de alocre a etichetelor Utilizarea stivei de etichete Manevrarea etichetelor
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 urmtor (NHLFE) 22 1.5.5.4 Asocierea etichetelor cu nregistrrile NHLFE 22 1.5.5.5 Comutarea etichetelor 22 1.5.5.6 Domeniul de valabilitate i unicitatea etichetelor 23 1.5.5.7 Cile cu comutaie de etichete (LSP) 24 1.5.5.8 Eliminarea etichetei n nodul penultim al unei ci (PHP) 26 1.5.5.9 Nodul urmtor 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 distribuia etichetelor i ierarhiile asociate32 1.5.5.16 Concepte privind transportul LDP 33
1.6 STUDII DE CAZ PRIVIND RUTAREA SI ETICHETAREA 1.6.1 MPLS n rutarea traficului pe principiul nod-cu-nod 35 35
1.6.1.1 Distribuirea etichetelor pentru prefixe de adresa 1.6.1.1.1 Definiii 1.6.1.1.2 Distribuia etichetelor 1.6.1.1.3 Folosirea rutelor de tip nod-cu-nod ca LSP
1.6.2 1.6.3 1.6.4 Utilizarea MPLS LSP cu precizare explicit a rutei Rutarea multi-cale i arbori de ci LSP Tunele LSP ntre rutere de frontier BGP
36 36 36 37
38 39 39
1.6.4.1 1.6.4.2
Procedura de stabilire a tunelului Un caz special de tunel
40 41
43 44 45 46
page
1.7 MPLS QOS 1.7.1 Necessary Conditions for QoS 1.7.2 Architectural Planes and QoS functions 1.7.3 IP Services
1.7.3.1 IntServ with RSVP-details 1.7.3.2 DiffServ-details 1.7.3.2.1 DiffServ basic terminology ( RFC 2475) 1.7.3.2.2 Functional blocks within a DS node 1.7.3.2.3 DiffServ Main Concepts used in MPLS 1.7.3.2.4 Topological QoS Classes (CoS) Definitions 1.7.3.2.5 CoS Defined in DiffServ technology-standards Packet Marking 1.7.3.2.6 DiffServ Functions
1.7.4 MPLS cooperation with with DiffServ
49 50 51 56 58 61 61 62 64
65
1.7.4.1
MPLS Support of DiffServ
65
71 73 74
1.7.5 DiffServ-Aware MPLS Traffic Engineering 1.8 LABEL DISTRIBUTION PROTOCOLS (LDP) 1.8.1 Label Distribution with LDP
1.8.1.1 1.8.1.2 1.8.1.3

2 ANEXE 2.1 2.2 2.3
General features Messages Summary of Operation
74 75 75
77 77 77 78
METODE DE CODIFICARE PENTRU ATM_MPLS: OPIUNI PENTRU REDUCEREA NUMRULUI DE ETICHETE STIVA DE ETICHETE I IMPERECHEREA IMPLICIT
2.3.1.1.1 2.3.1.1.2
3 REFERINTE
Elemente de unificare a etichetelor n cazul interfeelor ATM-LC Inter-operarea nodurilor cu interfee de celule ATM
78 79
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.
page
1
1.1
COMUTAIA DE ETICHETE MULTIPROTOCOL (MPLS)

Concepte de baza pentru Multi-Protocol Label Switching - MPLS
MPLS este o metoda de comutaie rapid de pachete la nivel trei folosit n reele TCP/IP MPLS poate ns conlucra cu orice protocol de nivel 3, de unde i numele de multiprotocol MPLS a fost dezvoltat pornind parial de la ideile de baza din ATM ( eficiena comutrii de etichete de tip ATM n comparaie cu dirijarea tradiional IP- bazat pe analiza antetului de nivel trei al fiecarui pachet IP.
Rutarea IP tradiional- funcii principale: - determinarea rutelor routing (algoritm de cutare a drumurilor de cost minim i construirea tabelelor de dirijare - dirijarea forwarding fiecrui pachet sosit la un Pin al unui ruter pe una din interfeele de ieire (sau mai multe, prin multiplicare, n cazul multicast) - Cautare pentru fiecare pachet n parte - comparnd a_dst (din antetul de nivel trei pachetului IP), cu informaiile coninute n Fwd_Table pentru determinarea celei mai bune potriviri ntre adresa de destinaie i nregistrrile din tabel - Rezultatul: identitatea portului de ieire 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 cutarea - consum timp i putere de calcul pentru fiecare pachet n parte MPLS : nlocuiete dirijarea bazat pe cutare cu o comutaie (swapping) de etichete realizata rapid (fr cutare) La intrarea ntr-un domeniu MPLS fluxurile de pachete sunt mai nti clasificate n clase de echivalen (d.p.d.v al dirijarii Forwarding Equivalence Classes - FEC) Fiecrei FEC i corespunde un identificator de lungime fix numit etichet MPLS (label) Fiecare pachet aparinnd unei clase FECi este etichetat cu eticheta clasei respective, iar eticheta se adaug n faa 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) urmtor, dirijarea pachetului etichetat, se face apoi prin comutaie de etichete, pe baza unui tabel de comutaie a etichetelor, conform relaiei: (port_intrare, etichet_intrare) (port_ieire, etichet_ieire) prin adresare indexat la un tabel de comutaie - La ieirea din domeniul MPLS i reintrarea ntr-un domeniu cu dirijare traditional IP, etichetele sunt eliminate de ctre ruterul de ieire, care dirijeaz n continuare pachetul prin forwarding tradiional. Pentru: compatibilitate cu arhitecturile existente si considerente economice
page
MPLS a fost definit ca un nou sub-nivel arhitectural intermediar ntre nivelul 2-3; pstreaz implementrile existente pentru nivelele DL i N.
se
Pentru a aloca etichete segmentelor (link-urilor) este nevoie de informaii de rutare. n acest sens, o caracteristic important a MPLS este c admite informaii furnizate de orice tip de protocol de rutare, de de unde i numele de multiprotocol.
Domeniu MPLS = o zona dintr-o reea, 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 tradiional) Fiecrei FEC cale cu comutaie de etichete (LSP - Label Switched Path). Pachetele unui flux care aparin unui FEC vor fi dirijate pe calea asociat n fiecare nod comutator : comutaia de etichete (e1 e2, e2 e3)
Dirijare M PLS
Dirijare normala (IP) e1 ER LSR
e2 LSR e3
Dirijare normala (IP)
ER LSR Cale M PLS (LSP)
Domeniu M PLS
ER
Domeniu IP
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 comutaie de etichete MPLS
1.2
Avantaje ale tehnologiei MPLS

mai rapid dect cutarea n tabele la nivel IP (table look-up), LSR sunt mai rapide dect ruterele tradiionale (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 comutaia ATM propriu-zisa. ofer flexibilitate prin aceea ca : o lucreaz la fel ca n rutarea de nivel 3, avnd n plus simplitatea dirijrii asemntoare cu comutaia de nivel 2. MPLS permite realizarea de ierarhii de rutare (mai multe
MPLS : avantaje importante n special pentru reele centrale (core) avansate:
nivele de etichete) i tehnici tunel.

ARIBL-RITC Master 2012-2013 page
Poate colabora cu ruterele traditionale (domeniile MPLS pot coopera cu domenii de rutare tradiionale permite introducerea treptat a tehnologiei MPLS).
faciliteaz creterea performanelor reelei: 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, (ignornd sau folosind numai parial informaiile 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 reele virtuale private (VPN).
se poate generaliza i aplica i n reele 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 informaii de nivel L3 sau superior- pentru clasificarea pachetelor (prin contrast, la rutarea tradiional IP singura informaie utilizabil este cea din antetul de nivel 3). etichetarea este flexibil. n particular ea poate fi dependent de ruterul de intrare. Un acelai pachet poate fi etichetat diferit (i tratat n continuare n mod diferit) dac sosete pe unul sau altul dintre dou rutere de intrare din domenii diferite (aciune 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 motenete n mod inerent i complexitatea acestuia precum i un dinamism mai mic n comparatie cu IP: - funcii i protocoale suplimentare n planul de control care s conlucreze cu cele de rutare pentru distribuia etichetelor ntre nodurile LSR. Cile MPLS trebuie construite n avans n raport cu transferul pachetelor de date Deteriorarea unei ci MPLS conduce la intreruperea transferului de date ceea ce face necesar definirea de ci LSP principale i de rezerv. Rutarea este mai puin dinamic dect n IP.
1.3

Definiii i terminologie MPLS

Domeniu MPLS (MPLS domain) - poriune dintr-o reea 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 instaniere unic a secvenei de pachete de date dintre dou aplicaii; 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 dirijrii (FEC Forwarding Equivalence Class) un grup de pachete IP care sunt dirijate de-a lungul aceleiai rute (sufer aceeai tratare din punct de vedere al dirijrii) Etichet MPLS (MPLS Label) o o o identificator cu lungime fix (32 bii) amplasat naintea antetului IP cu semnificaie local pe un link ntre dou comutatoare MPLS care codific un FEC
Comutaie de etichete (label swap) - operaie de baz n MPLS, reprezentnd modificarea etichetei la traversarea unui comutator MPLS
page
Nod (generic) MPLS (MPLS node) un nod ce ruleaz MPLS, adic : o o o cunoate protocoalele de control MPLS pentru distribuia etichetelor ruleaz unul sau mai multe tipuri de protocoale de rutare capabil s dirijeze pachete pe baz de etichet MPLS (dar poate opional 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 ieire (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 tradiional de nivel L3 Cale cu comutaie de etichete (LSP Label Switched Path) canal virtual ce traverseaz mai multe LSR, pe un anumit nivel n ierarhia de etichete MPLS; pachetele ce aparin unui FECi urmeaza prin reea aceeai LSP Stiv de etichete (label stack) structura de date de tip stiv (LIFO Last Input First Output) folosit pentru atunci cnd 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 capt-la-capt) Protocol de distribuie a etichetelor (LDP Label Distribution Protocol) protocol de comunicare i distribuie a etichetelor i a semnificaiilor acestora ntre LSR (lucreaz n colaborare cu protocoalele de rutare: RIP, OSPF, BGP, IS-IS, EIGRP).
1.4 1.4.1
Etapele de funcionare n rutarea IP i n MPLS Rutarea convenional (IP)
n aceast seciune se vor detalia etapele de lucru prezentate sumar n Seciunea 5.1. Determinarea/calcularea rutelor: planul de control calculeaz (dinamic) rutele : protocol de rutare o o schimb de mesaje ntre rutere (RIP, OSPF, BGP) algoritm de determinare a drumurilor cu cost minim (algoritm de rutare)
Cu ajutorul informaiilor obtinute se construiesc tabele de dirijare n fiecare ruter. - realizat de ctre planul de date
Dirijarea pachetelor: - Fiecare ruter (hop) ia n mod independent de celelate, o decizie de ndrumare ctre un next hop, bazndu-se pe adresa destinaie a pachetului - Alegerea next-hop include 2 faze: - gruparea pachetelor n clase de echivalen (FEC) i realizarea corespondenei (mapping) : FEC/next-hop. - Din punct de vedere al dirijrii, pachetele ce aparin aceluiai FEC sunt tratate identic, fiind dirijate pe aceeai rut spre ieire. Doua pachete sunt considerate c aparin aceleiai FEC dac tabelul de dirijare conine un anumit prefix X, unde X este - pentru ambele pachete - poriunea de adres cea mai lung de potrivire cu adresa de destinaie a pachetului. Fiecare pachet n parte trebuie analizat pentru a i se atribui o clas FEC. - dirijarea propriu-zisa
page
1.4.2
Rutarea bazat pe MPLS
Presupunem ca s-au alocat etichete ntre nodurile MPLS (protocol LDP- bazat pe informaiile obinute 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 restricii privind clasificarea. Se pot folosi n principiu orice informaii, 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 primete un antet cu 32 de bii (eticheta propriu-zisa este cu 20 biti si codifica un FEC) - pachetul este dirijat ctre next hop (NH) numai pe baza etichetei, indiferent de informaia cu ajutorul creia s-a decis apartenena la un anumit FEC. - decuplare a clasificrii fa de comutaie flexibilitate in clasificari + simplitate pentru operaia de dirijare i comutaie de etichete) - un ruter intermediar : comutaie de etichete fara analiza de tip L3 1.4.2.1 Etapele de funcionare ale MPLS n aceast seciune vom relua etapele principale de funcionare ale MPLS. 1. Faza de Control 1.a Protocoalele de rutare interioare (RIP, OSPF, IS-IS, etc.) calculeaz rutele pentru toate destinaiile accesibile. (ex.: OSPF, fiecare nod (ruter) determin graful reelei prin mesaje link state de la vecini calculeaz drumurile cele mai scurte de la el ctre diferite destinaii/reele aplicnd un criteriu de cost minim) se completeaz tabelul de dirijare. 1.b Spaiul total de dirijare se mparte n FEC-uri. (Pachetele care vor urma acelai drum vor aparine aceleiai FEC -se face legarea etichetelor label binding, prin care se atribuie cte 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 cile LSP (unidirecionale) 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 destinaiei i pe baza potrivirii exacte a altor cmpuri 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 comutaie de etichete n fiecare nod.
(*) Observaie : - se examineaz de regul antetul de nivel L3 - pot fi considerare i alte informaii auxiliare ( ex. de QoS, TE etc.) Corespunztor acestor informaii ruterul de frontier E-LSR poate decide alocarea clasei FEC i a etichetei corespunztoare 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 ieire spre nodul urmtor. Comutaia realizat este : (Port-n, L-in) -> (Port-out, L-out). 2.c Nodul de ieire din domeniul MPLS elimin eticheta i dirijeaz pachetul mai departe, n stil IP (eventual spre un alt domeniu) pe baza analizei de antet L3. - opional PHP (Penultimate Hop Popping): penultimul ruter din domeniul MPLS, dup determinarea portului de ieire ctre ultimul nod MPLS, elimin deja eticheta deoarece ruterul de ieire, oricum nu o va mai folosi.
comuta etichete (se poate realiza PHB)
Tabel de comutare etichete
LSR ER - receptioneaza pachet - analiza antet la nivel L3 - eticheteaza pachet - dirijeaza catre urmatorul hop LSR
LSR
Tabel de dirijare
Domeniu MPLS
ER
-elimina eticheta - analiza L3 dirijeaza pachet ER
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
Comparaie intre un ruter tradiional i un ruter MPLS
page
Protocoale rutare IP Tabele rutare IP
Routing Updates actualiz. rute
Actualizare rute
Plan control C Protocol rutare IP Tabela rutare IP
Rutare IP
Actualizare ptr legarea etichetelor
Control de rutare IP MPLS
LIB
Tabele de dirijare (forwarding)
Label info Base
Plan de date (U)

Forwarding Info Base (FIB)
Procesare pachete Buffer

LC LC LC LC
Label Forwarding Info Base (LFIB)

Tabela de dirijare MPLS
Pachete in LC=line Card
Pachete out Buffer

LC
LC
LC
LC
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 1.5.1
Elemente de baza ale MPLS Codificarea etichetelor

Formatul etichetei MPLS
1.5.1.1
IP-H MPLS-H IP-H
TCP-H TCP-H
Date aplicatie Date aplicatie
LABEL 20 Biti
EXP 3 32 biti
S 1
TTL 8
Figura 1-4 Codificarea antetului MPLS TCP-H antet TCP IP-H antet IP LABEL eticheta MPLS propriu-zisa. Aceasta are semnificaie local pe un link ntre dou LSR. EXP - cmp experimental - uzual indica o clasa de serviciu ( ex. In DiffServ/MPLS - codifica prioritai diferite ale pachetelor). S - arat (dac ia valoarea 1) c eticheta este la sfrsitul unei stive LIFO de etichete (folosit pentru a
{
Pachete
Datgrama IP Datgrama IP etichetata
Antet MPLS
10
realiza o ierarahie de domenii MPLS incluse unele n altele). TTL Time To Live -vezi IP (timpul de via rmas al pachetului n reea). 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 urmnd ca rutarea mai departe s se fac pe principii IP. 1 - Router Alert : nu are sens dac S=0, indicaie pentru ruter: pop pentru eticheta curent i dirijare dup eticheta urmtoare din stiv. 2 - IPv6 Explicit Null : are aceeai semnificaie ca pentru IPv4. 3 - folosit de LDP pentru cereri PHP. 415 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 vrful stivei).
Antet L3 Etichete MPLS Shim header Date Terminator L2
Antet L2
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 conine informaiile sale uzuale. Eticheta MPLS nu este folosit la nivelul L2.
page
11
Antet L2
Antet MPLS Antet MPLS
Antet L3
Date
Tipuri de L2 PPP , PPP over SONET/SDH Ethernet Frame Relay PVC MPLS over ATM- PVC Prima celula ATM Urmatoarele celule ATM
Antet ATM Antet ATM
Antet L3
Date
Date
Figura 1-7 Exemple de ncapsulare generic MPLS pentru diverse nivele L2
Incapsularea MPLS/PPP folosit pentru comunicaii 1-la-1 (ex. pe legturi seriale). n modelul OSI, PPP este definit la nivelul L2. Are trei componente principale cu ajutorul crora stabilete 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 conine un sub-nivel inferior pentru stabilirea, configurarea i testarea unei conexiuni de nivel 2 (Link Control Protocol - LCP) i un subnivel superior cu funcii de adaptare (Convergence sublayer) denumit Network Control Protocol NCP, care permite conlucrarea cu diferite protocoale de nivel 3. NCP include printre altele i funcii relative la securitatea informaiei. Incapsularea PPP este ~ HDLC, cu unele excepii. Un cmp special numit protocol indic tipul coninutului informaiei sau - echivalent - ce protocol superior se foloseste peste legtura de date propriu-zis: LCP(0x co21), NCP(0x 8021), IP(0x 0021), control - MPLSCP (0x8281 ), etc. n MPLS/PPP Se transmit pachete LCP pentru testarea i configurarea legturii 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 legtura de date a ajuns n starea Open se pot transmite pachete etichetate. MPLS CP folosete acelai mecanism de schimbare de mesaje ca i LCP cu urmtoarele excepii:
Point-to-Point Protocol (PPP)
Dup ce PPP a ajuns n faza de Network Control i MPLS CP a atins starea Open, se pot transmite pachete pe legtura de date, identificabile prin cmpul Protocol (0x0281 pentru MPLS 1-la-1 unicast i respectiv 0x0283 pentru MPLS comunicaii 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 existenei unor forme modificate ale acestuia din urma (de exemplu pentru IEEE 802.1q -VLAN). Pentru identificare se folosete cmpul Type din cadrul Ethernet (octeii 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 folosete ncapsularea L2 de tip 802.3 LLC/SNAP, [ ]. Incapsularea MPLS/ATM a. Incapsularea generic
page
12
- presupune (Figura 2.7) utilizarea de ATM-PVC - datagrama de nivel trei se segmenteaz n celule - numai prima celul contine eticheta MPLS, celelalte coninnd doar restul datagramei - Transport tradiional-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 operaii specifice MPLS intr-un 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 semnificaia tradiionala a acesteia, (figura 5-8). Soluia permite folosirea interfeelor i comutatoarelor ATM n tehnologia MPLS. Particulariti: eticheta din vrful stivei se include n VPI, VCI ntre ATM-LSR nu se mai face reasamblarea celulelor ATM comutaia MPLS se efectueaz acum ca o comutaie 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 folosete 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 funcie de modul de interconectare al comutatoarelor ATM- LSR (SVC, SVP) exist mai multe variante de ncapsulare subiect ce se va relua ulterior.
Antet ATM GFC VPI VCI PTI CLP HEC Antet L3 Date Prima celula
ruter LSR, este necesar
Eticheta MPLS
GFC
VPI
VCI
PTI
CLP
HEC
Antet L3
Date
Urmatoarele celule
Eticheta MPLS
Figura 1-8 Includerea etichetei MPLS n VCI, VPI n cazul comutatoarelor ATM-LSR
page
13
1.5.2
1.5.2.1 1.a
Detalierea fazelor de operare MPLS

Faza de control Calcularea rutelor de ctre protocoalele de rutare i construcia tabelelor de dirijare
Reamintim etapele fazei de control: 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 cile LSP. Cile 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 cii LSP sunt fixate; celelalte pot fi n principiu oricare dintre cele diferite de subsetul de noduri precizate explicit.
Exemplu :
stabilirea unei ci spre o main terminal avnd adresa (IPv.4) de destinaie x.y.z.w, conectat la o reea local avnd prefixul de adres x.y. Figura 1-9: domeniu MPLS i fazele de control. Fa de un nod LSRk, exist (considernd sensul de transfer al datelor) noduri n aval (downstream) i noduri n amonte (upstream). Standardul MPLS : etichetele sunt distribuite ntotdeauna de ctre nodurile din aval fa de un nod dat. Nodul amonte poate obine de la cel din aval o etichet, pentru o anumit clas FEC, (pp. c aceast clas FEC este asociat cu o anumit destinaie din reea), astfel: face o cerere de etichet ctre nodul din aval (solicited downstream mode) aflat pe ruta ctre destinaia dorit, sau
page
14
primete o indicaie de la nodul din aval- de a folosi o anumit etichet pentru o anumit FEC dar fr 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 destinaia cu prefix de adres x.y>. Semnificaia 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 destinaia x.y.
Propun eticheta 9 pentru dest. x.y
Propun eticheta 5 pentru dest.x.y LSR1 LSR2 Propun eticheta 7 pentru dest.x.y x.y Reea x.y E-LSR
E-LSR non MPLS Domeniu MPLS
LSR LSR E-LSR
x.y.z.w non MPLS Rute alese de IGP Alocare de etichete de tip "downstream" nesolicitat Label Switch Path
Tabel de dirijare n E-LSR Tabel de comutaie de etichete
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) -transferul unui flux de pachete etichetate pe o cale MPLS ctre o reea avnd adresa x.y (prefix de adres IPv.4)
Figura 1-10 :
S-a presupus c n urma fazei de control n fiecare LSR exist cate un tabel de comutaie care conine informaiile de comutaie de etichete.
page
15
Recepioneaz pachetul L3 "look up" clasific FEC eticheteaz pachetul dirijeaz ctre nodul urmtor 9 3 E-LSR 0 Dirijare tradiional 1 2
Comutaie de etichete (adresare indexat): IF0->IF2, 9-> 5 LSR 1 LSR LSR E-LSR Domeniu MPLS Penultimul LSR poate elimina eticheta, cci ea nu va mai fi necesar n E-LSR 5 2 0 1 LSR 2 1 3 7 0 E-LSR 2 3 XYZ Reea XY
Tabela de comutare pentru I/F0 etichet prefix I/F etichet IN adres OUT OUT 9 XY 2 5 Rut aleas de IGP Label Switch Path
Figura 1-10 Operare MPLS: dirijarea pachetelor
1.5.3
Decizia de alocre a etichetelor
IETF RFC 3031: dou moduri de control al alocrii etichetelor: independent i ordonat (Independent Control-IC, Ordered Control-OC) . IC: fiecare LSR decide - independent de alte LSR, partiionarea n FEC aloca etichete pentru FEC-urile stabilite distribui etichetele ctre 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 su va lua decizii diferite referitoare la aceleasi FEC-uri, atunci este posibil ca pentru anumite FEC-uri s nu poat crea ci 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:
16
- un LSR poate face o coresponden (mapping) FEC/label numai dac a primit o etichet de la nodul urmtor sau dac este un egres ruter pentru acel FEC. Caracteristici: iniierea o poate face un ruter de iesire din domeniul MPLS selectarea FEC se face la ruterul iniiator pe msura formrii LSP, toate LSR din calea respectiv vor utiliza acelai FEC. Este ns necesar ca orice LSR s poat determina care este next-hop pentru FEC n cauz, astfel nct 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.
Comparaie IC/OC: OC IC Avantaj: convergenta mai rapida ( orice LSR poate stabili i anuna n reea legarea de etichete fr a mai atepta 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, nerespectndu-se astfel eventuale restricii avantaj: control administrativ mai strict, Dezavantaj: timpului mai mare de propagare al etichetelor
exist posibilitatea interoperabilitii ntre ele
Alegerea uneia sau alteia dintre abordri nu influeneaz mecanismul folosit n distribuia etichetelor
1.5.4
Utilizarea stivei de etichete

n cazul incluziunii domeniilor MPLS unele n altele la rutarea inter-domeniu la realizarea de VPN, etc.
Stiva se utilizeaza
Figura 1-11: exemplu de rutare MPLS ntre trei domenii A, B, C. Pp: ntre domenii se folosete comutaia de etichete MPLS, stabilite cu ajutorul informaiilor furnizate de (BGP Border Gateway Protocol). n domeniul B se folosete MPLS, etichetele fiind stabilite anterior pe baza informaiilor de rutare furnizate de un ( IGP Interior Gateway Protocol). Intuitiv: calea MPLS inter-domeniu, poate fi privita ca un tunel MPLS (care folosete etichetele 4, 9 si 6). ntre ruterele R1 (din A), ELSR1, ELSR2 (din B) i R2 ( din C) exis relaii de semnalizare de tip BGP. Dirijarea n domeniul MPLS B: se face cu un nou nivel de etichete stiv ce va avea n vrf etichetele folosite i comutate n LSR din B. Etichetele exterioare lui B nu sunt folosite n operatiile swap din comutatoarele LSR ale lui
page
17
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 ieirea din B se elimin etichetele tunelului din domeniul B.
Aciunile executate pentru realizarea acestui tunel sunt urmatoarele (poziiile i elementele n care au loc n domeniu sunt indicate n figur): 1. 2. R1 (din A) adaug / comuta o etichet, de exemplu 4 (pe baza informaiilor BGP, pentru a urma o cale R1 ELSR1 ELSR2, ...) ELSR1 face o comutaie de etichete 4 9, in tunelul A-B-C. a. [ELSR2 nu este accesibil direct de ctre ELSR1 din domeniul B] ELSR1 caut o cale MPLS: ELSR1 ELSR2 prin B ( pe baza informaiilor MPLS din ELSR1). b. De ex. calea MPLS va fi ELSR1LSR1LSR2ELSR2. c. Pentru a realiza acest transfer ELSR1 introduce un nou nivel de etichete (prin operatia push). i. n particular, se folosete o cale ce trece prin LSR1 cu adugarea n stiv (push) a etichetei 7. Pachetul etichetat cu 7, 9 se transfer pe un port ctre LSR2. 3. 4. LSR2 nu modific eticheta 9 dar realizeaz o comutaie asupra etichetei din n vrful stivei , n particular, 75. LSR2 execut o comutaie similar celei din ELSR1 i anume, 52. Observm 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 funcionare, n care penultimul nod MPLS dintr-un domeniu elimin eticheta (PHP- penultimate hop popping) caz care nu este prezentat n acest exemplu. LSR2 elimin (pop) eticheta 2 care se gasea din vrful stivei i comut dup eticheta iniial, n particular, execut comutatia 96.
5.
page
18
Domeniul A 1 4 R1 E-LSR1 9 2 7 LSR1 IGP
Domeniul B 3 9 5 LSR2 4 9 2 E-LSR2 5 6
Domeniul C
R2
BGP
IGP
IGP
BGP
In NH ?
Out
In NH 7
Out
In NH 5
Out
In
NH Out ?
LSR1 7 push
LSR2 5
E-LSR2 2
2 R2 pop
nregistrri IGP In NH E-LSR1 Out 4 In NH 4 ELSR2 Out 9 In NH 9 R2 Out 6 In NH Out 6 -
nregistrri BGP Eticheta 7 Eticheta 5 Eticheta 2
9 4
9 6
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 comutaie 49; E-LSR2 nu este direct accesibil: gsete o conexiune via LSR1 i adaug (push) eticheta 7; 3 comut eticheta din vrf 75 i 9 rmne nemodificat; 4 comut eticheta din vrf 52 i 9 rmne nemodificat; 5 elimin (pop) eticheta intern i comut eticheta extern 96. Rezumm aciunile 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 operaia push cu o nou etichet pe nivelul de etichete
19
activ n MPLS2 2. n interiorul lui MPLS2 se face comutaie de etichete conform acestui nou nivel 3. la ieirea din MPLS2 se execut operaia pop pentru nivelul de etichete valabil n MPLS2, revenind la nivelul de etichete din MPLS1.
(1) MPLS1
MPLS2 (3) (2)
Figura 1-12 Domenii MPLS incluse i folosirea stivei
1.5.5
1.5.5.1
Manevrarea etichetelor
Asocierea etichetelor la clasele de echivalent - Dou comutatoare LSR de pe aceeai cale se afl ntr-o relaie de amonte-aval.
Asocierea etichet/ FEC = legare a etichetelor (label binding) - Dou LSR se afla intr-o n relaie (u-d) dac pentru aceleai FECi folosesc o etichet L cunoscut de ambele pentru dirijarea pachetelor etichetate. - Rd ia decizia legrii L/FEC i l informeaz (distribuie L) pe Ru. (downstream assigned mode)
Date (in viitor) LSP Ru 2. Informeaza Ru Rd 1.Aloca L/FEC
Figura 1-13 Principiul distribuiei nspre amonte ( de jos n sus) a etichetelor MPLS O legatur L/FEC poate avea i unele atribute asociate. - Daca Ru joac la rndul su rol de Rd pentru a distribui n amonte etichete, atunci el va retransmite spre amonte i aceste atribute - De regul atributele se utilizeaz atunci cnd exist o stiv de etichete n rutarea ierarhizat MPLS. - Procedurile prin care se transmit legrile L/FEC ntre LSR = Label Distribution Protocol (LDP) - n plus, LDP poate include i eventuale negocieri ntre LSR vecine n scopul de a afla
20
capabilitile MPLS ale fiecruia. Dup distribuirea etichetei ctre Ru acesta poate n principiu s o foloseasc pentru transferul MPLS (Figura 1-14).
Flux de date Ru L eticheta de ieire din Ru Rd
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 : primete un mesaj de la un Rd, care tocmai a stabilit o etichet pentru un FEC anume (R poate sau nu s rein informaia, deoarece nu el a cerut-o)
Reine sau nu informaia primit
Ru
Rd
128.9.X.x
Mesaj iniiat de Rd: " for dest =128.9, please use label = 7 "
Figura 1-15 Informare de tipul "unsolicited downstream label distribution " asupra etichetei
b. Distribuia de etichete cerut de la un ruter din aval, downstream on demand Figura 1-16: pe linkul R2-R3 sunt 2 cereri pentru o aceeai destinaie, care vor aprea ca distincte numai dac este vorba de FEC-uri diferite.
Cere etichet pentru 128.9 (2 cereri distincte dac sunt 2 FEC diferite)
R1
Cere etichet pentru 128.9 Cere etichet pentru 132.5
R2
R3
128.9
R5 R4
Cere etichet pentru 128.9 Cere etichet pentru 132.5
132.5
Figura 1-16 Obinerea 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 acelai ruter ns este posibil coexistena metodelor, dar folosite pe porturi diferite. Informaia asupra unei etichete primit de un R poate fi tratat n dou feluri:
21
Liberal Label Retention Mode: ruterul reine total informaia chiar dac momentan nu-i este necesar, pentru o eventual folosire rapid, ulterioar. Cost: creterea spaiului de memorie ocupat fata de cel efectiv, folosit la un moment dat. Conservative Label Retention Mode: ruterul reine numai informaia de care are momentan nevoie; se reduce dimensiunea memoriei utilizate, cu dezavantajul c dac va avea nevoie de acea informaie trebuie reluat activitatea de aflare a ei (crete timpul de rspuns). Inregistrarile pentru dirijare spre nodul urmtor (NHLFE)
1.5.5.3
Pentru dirijarea pachetelor sunt necesare nregistrari - n tabelele de dirijare - asupra nodului urmator Next Hop Label Forwarding Entry = NHLFE cu informaii: nodul urmator (next-hop) din calea LSP operaiile de executat pe stiv: comutaie de etichete (doar modificarea de eticheta; nu se intampla nimic cu stiva) (pop) iar decizia de dirijare se va lua din eticheta urmtoare din stiv; comutaie de etichete + push o noua eticheta n stiv pentru formarea unui tunel.
In plus, NHLFE poate conine i informaii auxiliare : ncapsularea de nivel 2, modul de codificare al stivei informaii utile modului de prelucrare al pachetului.
LSR (next-hop) al unui Ri poate fi chiar el nsui, dac Ri se afl la ieirea dintr-un domeniu MPLS. Ri dirijeaz pachetul ctre el nsui, iar urmtoarea dirijare se va face n funcie de informaiile rmase n stiv dup ce Ri a fcut pop la stiva primit iniial (urmeaza o dirijare dupa eticheta rmas n stiv sau, dup caz, o dirijare IP clasica). 1.5.5.4 Asocierea etichetelor cu nregistrrile NHLFE Pachet de intrare deja etichetat: Eticheta se asociaza cu una sau mai multe nregistrri de tip NHLFE. funcia 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: 1.5.5.5 el trebuie clasificat i etichetat funcia (mapping) FEC-to-NHLFE (FTN). asociaz fiecrui FEC un set de NHLFE, (pentru dirijarea efectiv este folosit doar prima nregistrare) asocierea cu un set de mai multe nregistrari permite - load-balancing.
Comutarea etichetelor pentru un pachet de intrare etichetat cu L, aflat n varful stivei: funcia ILM determin nregistrarea NHLFE, ce indic operaiile se execut operatiile pachetul este dirijat spre un port de ieire.
pachet de intrare neetichetat: se analizeaz antetul L3 i (eventual alte informatii) pentru a determina crui FEC aparine (clasificare)
page
22
FTN determina un set de NHLFE Se execut apoi operaiile cerute de NHLFE selectat i se dirijeaz pachetul spre un port de ieire.
1.5.5.6 -
Domeniul de valabilitate i unicitatea etichetelor 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 aceluiai ruter pot exista etichete egale valoric dar reprezentnd clase diferite, de exemplu F1, F2.( trebuie ca ruterul n cauz s poat identifica distinct interfeele de sosire)
In ce zona MPLS este valabila o eticheta L ?
Exemplul 1: Figura 1-17.a. Un LSR Rd: asociaz L1 /F, i distribuie asocierea lui Ru1 asociaz L2 aceluiai F i distribuie asociere lui Ru2.
Deci aceeai 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 informaiile disponibile local. Dac ruterul poate face distincia ntre intefeele pe care sosesc pachetele, atunci L1 poate fi chiar egal cu L2 fr a aprea 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.
Ru1 Date Ru2 a. (L2, F) (L1, F) Rd Ru1 Date Ru2 b. (L, F2) (L, F1) Rd
Figura 1-17 Unicitatea etichetelor a. Aceeai clas, cu etichete diferite pe linkuri diferite b. Aceeai valoare de etichet pentru clase diferite pe linkuri diferite Problem mai general: moduri de folosire de ctre un LSR a spaiului (mulimea de valori numerice) etichetelor ? - soluii RFC 3031 : - per-interface-label-space.
23
- 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 ambiguitilor).
1
Ru
Rd
S0 = [L1, L2, L3, K, Ln]
Figura 1-18 Spaii de etichete distincte la nivelul unei interfee (pe interfeele 1 i 2 pot exista etichete din setul S0)
(L, F1) Ru (L, F2)
Rd
1
Figura 1-19 Etichete unice la nivelul LSR Figura 1-19 : totusi un Rd poate folosi aceeai L pentru F1 F2, n asociere cu acelai vecin Ru, dac la primirea unui pachet de la Ru, Rd poate face distincia intre I/F0 si I/F 1 Std. MPLS : spaiul (multimea) etichetelor este unul singur pentru toate nivelele ierarhice. De fapt, atunci cnd este interpretat o eticheta nivelul ierarhic al acesteia nici nu conteaza, cci alte mecanisme dicteaz care nivel ierarhic se folosete. Permite folosirea mai multor spaii de etichetare, per platform sau per interfa (aceste spaii pot fi mulimi de valori cu intersecie nevide!). Este necesar ns a exista mijloace particulare (non specificate de arhitectura MPLS) pentru a putea spune crui spaiu aparine o anumit etichet. De exemplu: MPLS-shim specific faptul c pentru unicast i multicast se folosesc spaii de etichetare diferite i atunci se folosete un cod de nivel doi care va indica despre care spaiu de adresare este vorba. Cile cu comutaie de etichete (LSP)
1.5.5.7
Definiia formala (complet) a unei ci LSP O cale LSP de nivel m pentru un pachet P este prin definiie : o secven de LSR cu proprietile (<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 cnd pachetul este recepionat 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
page
24
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 situaiile: o o nu folosesc deloc eticheta i nici antetul de nivel 3 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).
Domeniu non-MPLS MPLS 3 MPLS 1 2 1 Nivel stiv 0 push push push pop pop MPLS 2
E-LSR
pop
(se poate aplica i PHP) E-LSR MPLS 2 MPLS 1 2 1 Nivel stiv 0 push push pop pop 2 Domeniu non-MPLS
Figura 1-20 Evoluia 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. Definiie: 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 definiii pot exista i arbori de LSP care pornesc de la ingress E-LSR diferite i ajung
25
la acelai egress E-LSR. Cile ce aparin arborelui au aceeai clas FEC. (figura 1-21).
E-LSR
Domeniu MPLS F F F Aceeai clas FEC = F
Figura 1-21 Arbore de ci LSP 1.5.5.8 Eliminarea etichetei n nodul penultim al unei ci (PHP) opional ntr-un domeniu MPLS = posibilitatea ca un LSR, stiind ca el este penultimul LSR din domeniu), atunci poate elimina eticheta corespunztoare nivelului su ierarhic caci ultimul LSR nu o va mai folosi (figura 1-22.b).
Penultimate HOP Popping- PHP
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 = opional, deci pot exista comutatoare care nu tiu s implementeze PHP. PHP se aplic De asemenea, LSR-urile nu vor cere aplicarea PHP dect nodurilor vecine despre care tiu c sunt capabile de acest lucru. daca este ceruta de ruterul egress daca urmtorul nod n LSP nu suport MPLS. Protocolul LDP trebuie s permit nodurilor LSR s determine dac vecinii lor cunosc opiunea PHP
Rn-1
Rn
Rn-1
Rn
Nivelul stivei
m m1 Pop a.
m m1 b.
Pop pentru eticheta de nivel m
Figura 1-22 Eliminarea etichetei la captul cii LSP

a. n nodul ultim al LSP b. n nodul penultim al LSP
page
26
1.5.5.9
Nodul urmtor 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 ctre eticheta corespunztoare 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 dect 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 cte o clasa FEC pentru fiecare prefix distinct de adres din tabelul de rutare. Este posibil ca pe anumite poriuni din domeniul MPLS, mai multe fluxuri cu FEC diferit s urmeze aceeai rut. o o n acest caz, n domeniul MPLS uniunea de segmentul respectiv de rut. FEC-uri poate constitui tot o clasa FEC, pe
Prin operaia numit agregare se asociez o singur etichet ntregii uniuni de FECuri, datorit faptului c pe acel segment toate fluxurile n cauza sunt dirijate la fel.
Granularitatea de agregare poate fi variat : dndu-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). Cnd este folosit controlul ordonat al etichetelor, un LSR trebuie s adopte pentru un set de FEC-uri dat, aceeai granularitate ca "next hop".
pe aceast seciune 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 dect Rd, atunci Ru poate s retrag o parte din etichetele sale. Dac Ru are granularitatea mai grosier dect 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.
page
27
Pentru a se putea realiza agregarea este necesar cunoaterea de ctre toate LSR prin configurarea iniial a fiecaruia, a nivelului de granularitate ce trebuie folosit. n reelele reale se folosete 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 ci LSP pentru o anumit clas de echivalen FEC. Exist dou metode de selecie: 1. nod-cu-nod ("hop-by-hop"): fiecare nod LSR alege n mod independent nodul urmtor pentru fiecare pachet (asemntor cu rutarea tradiional 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 parial ("loosely explicitly routed") nodurile care o compun, ca n figura 2-24.
Specificare totala (stricta) Pot fi oricare Specificare numai a anumitor puncte (partiala)
Figura 1-24 Metode de specificare a unei rute LSP pentru o clas FEC
Selectarea explicit a unei rute de ctre un LSR se poate face: static, prin configurarea iniial a acestuia dinamic, de ctre un singur nod care cunoate topologia reelei (n urma rulrii n reea a unui protocol de tip link-state). Avnd imaginea grafului reelei 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 parial similar cu rutarea de tip-surs n IP (source routing), dar mai avantajoas dect 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 informaiei 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 comutaie de etichete fr a mai fi necesar analiza informaiei de rutare din pachet.
page
28
Posibilitatea rutrii 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 ieire (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 funcii, ex. - limitarea zonei de accesibilitate acordat n reea unui pachet. Cmpul 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 ctre nodul de reea care constat aceasta. Datorit organizarii n stiv a antetului MPLS, este necesar transferul valorii TTL, de la o etichet din stiv la cea imediat urmtoare n sus sau n jos dup caz. n figura 1-25: valoarea TTL1, este copiat de catre nodul de intrare R1 n cmpul corespunztor din antetul MPLS n fiecare nod LSR din interior, valoarea TTL este decrementat cu 1 la ieire n nodul R2, (dac pachetul a ajuns aici), se copiaz valoarea TTL ramas (adic un TTL2) n cmpul TTL al antetului L3 al pachetului ce iese din domeniu (poate urma un domeniu MPLS sau IP).
Obs.: Pot ns exista poriuni de LSP (insule de reea) 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 estimri, va scadea TTL cu o valoare aproximativ egal cu numrul de noduri din segmentul respectiv. Dar aceast soluie rezolv problema eventualelor bucle numai dup ce pachetul va iei din acea insul; deci pentru a se preveni buclele n interiorul insulei trebuie ori ca protocolul din acea zon s aib propriul mecanism de detecie i evitare a buclelor ori ca LDP s prevad i alte mecanisme.
Valoarea lui TTL1 se introduce n eticheta L, n cmpul TTL, i apoi se scade la fiecare LSR traversat L TTL2 TTL1 R1 R2 MPLS
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.
29
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 aparin aceluiai FEC i care au sosit n acest LSR cu etichete diferite. Tehnica se numeste label merging, - Figura 2-26. Avantajul obinut este o economie important de etichete. Din punct de vedere al dirijrii identitatea distinct a unui flux de intrare se pierde ( aceasta va pune probleme n interfeele de tip I/F LC-ATM).
L1 L2 L3
Fluxuri ce aparin aceluiai FEC
LSR
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 aceeai etichet comun. Un LSR non capabil de unificare a etichetelor ( non-merge ) va pstra la ieire 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. innd seama ca n MPLS modul de alocare a etichetelor este downstream to upstream apare intrebarea: de cte etichete va avea nevoie un Ru de la Rd? Evident Rd nu are cum s tie acest lucru pentru un FEC. Singura soluie este ca Ru s cear explicit lui Rd numrul de etichete necesar, n particular pentru fiecare flux de intrare chiar dac acestea aparin aceleiai FEC. Figura 1-27 prezint un astfel de caz. Dac la rndul su Rd este tot de tip nonmerging, atunci Rd va proceda similar n dialogul cu cel din aval fa de el. Dac nodul Ru cunoate mecanismul label merging, atunci el cere lui Rd doar o singur etichet. Daca Ru poate agrega numai un numr limitat de etichete i el are nevoie de mai multe etichete, dect poate agrega, atunci face mai multe cereri, ca n cazul c. din figura 2-26.
o o o o
page
30
Flux1 Fluxuri ce aparin aceluiai FEC Ru Flux6 Ru
Etichete Rd Cereri de etichete Ru
a. ase cereri distincte daca Ru = non-merge b. o cerere daca Ru = merge si poate agrega > 6 etichete 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 reea diferit (cu alt sistem de adresare) sau printr-o zon din aceeai reea
prin ncapsularea sa intr-o anvelop care conine alte adrese dect cele originale. Calea traversat astfel se numete tunel. La captul tunelului se elimin anvelopa i se reia utilizarea adreselor originale. Tehnica tunel este foarte folosit n reele IP. Exemplu: un ruter Ru dorete s trimit un pachet la Rd, dar Ru i Rd nu sunt consecutive i Rd nu este destinaia final a pachetului, atunci Ru ncapsuleaz pachetul ntr-o anvelop cu destinaia 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"), captul Tx: Ru, iar captul 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 conine toate informaiile asupra rutei.
1.5.5.15.2 Tunele LSP Tunelele LSP, folosesc comutaia de etichete n locul ncapsularii din tehnica tunel tradiionala. Tunelul este de forma o LSP = <R1,,Rn>, n care Tx=R1 Rx=Rn. Echivalentul ncapsulrii 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.
page
31
Penultimul nod din tunel poate face popn cazul folosirii opiunii 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 funcie de modul n care s-a stabilit calea LSP.
MPLS permite o ierarhie de nivele LSP, exemplificat n figura 2-29.
Tunel R2 R3 Ra
L12 L2a Lab
Rb
Lbc
Rc
L23
nivel 2
R1
R2
L2a L23 Lab L23 Lbc L23 L23 pop n Rc
R3
L34
R4
L12
L34
push n R2
Figura 1-28 Tunel LSP inclus n LSP O ierarhie de acest fel poate avea oricte 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 distribuia local de etichete ("local label distribution peers"). Dou LSR care constituie o pereche pentru distribuia de etichete, dar nu sunt vecine IGP, formeaz o pereche de LSR pentru distribuia distant de etichete ("remote label distribution peers").
1.5.5.15.3 Imperecherea nodurilor pentru distribuia 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 conine ruterele Ra, Rb, Rc intermediare ntre R2 i R3. Pe nivelul 1 vecinii lui R2 pentru distribuia de etichete sunt R1 i R3. Pe nivelul 2 vecinul lui R2 pentru distribuia de etichete este Ra.
Deci relatia de vecinatate se asociaza unui nivel ierarhic.

32
MPLS suport dou moduri de distribuie a etichetelor pe nivele ierarhice diferite: mperechere explicit ("Explicit Peering") i mperechere implicit ("Implicit Peering").
Distribuia de etichete de ctre un ruter, spre un vecin pereche-locala se face prin transmiterea mesajelor LDP care sunt adresate ruterului pereche. Distribuia de etichete de ctre un ruter ctre 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 distribuia local. o Acest mod se utilizeaz cnd numrul de perechi LSR este mic, sau numrul 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 distribuia de etichete ctre 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 ctre un partener pereche local. o partenerul-pereche local va propaga aceast informaie mai departe ctre un alt partenerpereche local, .a.m.d. , din aproape n aproape (transportnd i atributele), pn ce este atins partenerul-pereche distant Imperecherea implicit se utilizeaz cnd numrul de LSR-uri perechi de distribuie de tip distant este mare.
1.5.5.16 Concepte privind transportul LDP Protocolul de distribuie de etichete LDP este utilizat ntre noduri MPLS pentru a stabili i menine legturile etichet-FEC. Pentru o operare corect sunt necesare transmiterea corect a informaiei i pstrarea secvenialitii mesajelor. Arhitectura MPLS nu impune un anumit protocol de distribuie a etichetelor. Soluii : protocoale noi LDP sau adaptarea/completarea unor protocoale existente pentru a putea suporta i distribuia de etichete. BGP [ ], [ ], (rutare inter-domeniu), poate fi folosit i pentru distribuia LDP: n multe scenarii este frecvent cazul n care se asociaz etichetele cu prefixe de adres. o Dac exist protocoale standard, deja utilizate ce conin algoritmi de rutare i care distribuie informaii despre rute n reea, atunci e posibil ca informaiile despre etichete s fie transportate n stil "piggy-back" pe mesajele care distribuie rutele propriu-zise. Acesta este i cazul protocolului exterior BGP. Se beneficiaz n plus de scalabilitatea BGP.
page
33
RSVP [ ], [ ], [ ], folosit i pentru distribuia de etichete. o o n mod clasic , RSVP este folosit pentru rezervarea de resurse pentru anumite fluxuri particulare de date. Considernd acest lucru, atunci este de dorit a eticheta pachetele acestor fluxuri de date pentru a evita operaiile de filtrare pe baz de adrese/port ( RSVP filterspec ) n fiecare nod. Astfel, folosirea RSVP ca transportor/distribuitor nu numai al informaiilor de rezervare dar i al etichetelor (ca parte a procesului PATH/RESV) este eficient n contextul controlului QoS al LSP.
SRC A
PATH R1 R2 RESV
DST B
PATH )
R1 finds Next hop No reservation
PATH )
RESV follows the same route as PATH
PATH specifies flow and the amount of traffic (TSPEC)
Idem as in R1
PATH)
DST establish the QoS requ irements for this flow RESV RESV R2 can rese rve resources for R2-DST RESV carries DST request for R2 to reserve resources on the se gment R2-> DST
RESVconf RESVconf
RESVconf 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
34
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
LSP
PATH : End of LSP: RD Traffic description Label request
RB
RE RD
RA RC PATH RESV
RESV: Label L3 Reserved resources RESV: Label L2 Reserved resources RESV: Label L1 Reserved resources
Figura 1-30 Utilizarea RSVP pentru disrtributia de etichete in MPLS
Etichete pentru LSP-uri cu rutare explicit: exist aplicaii (ex.: MPLS-Traffic Engineering MPLS -TE ) n care este util o o stabilirea unei rute n mod explicit, de la ingress la egress, i rezervarea de resurse pe aceast cale. un protocol folosit iniial pentru rezervarea de resurse i apoi extins pentru a suporta rutarea explicit i distribuia de etichete ( exemplu: MPLS-RSVP-TUNNELS, [ ]) un protocol folosit iniial pentru distribuia de etichete i apoi extins pentru a suporta rutarea explicit i rezervarea de resurse, ( exemplu: MPLS-CR-LDP, [ ], [ ]).
Dou soluii posibile : o o
1.6 1.6.1
Studii de caz privind rutarea si etichetarea MPLS n rutarea traficului pe principiul nod-cu-nod
Pachetele cu o anumit etichet vor fi dirijate de-a lungul aceleai rute stabilite nod-cu-nod ("hop-byhop"), metod utilizat i n rutarea tradiional. (un ruter determin next-hop pentru un pachet P, prin cutarea n tabelul de dirijare a unui prefix de adres X care constituie cea mai bun/lung- ca numr de bii potrivire cu adresa destinaiei din P). In acest caz, FEC poate fi identificat cu un prefix de adresa. Deci se asociaz etichete prefixelor de adres destinaie(dar n general, nu e obligatoriu acest lucru n MPLS) vezi nota:
35
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 1.6.1.1.1
Distribuirea etichetelor pentru prefixe de adresa Definiii
Rutere-pereche pentru distribuia etichetelor
Dou LSR, R1 i R2, sunt rutere pereche pentru distribuia de etichete pentru un prefix de adres X, dac i numai dac este indeplinit una din urmtoarele condiii (Figura 1-31): 1) R1 a aflat o rut spre X printr-o instaniere particular de IGP i R2 este vecin cu R1 n acea instaniere a IGP 2) R1 a aflat o rut spre X printr-o instaniere a unui algoritm de rutare A1, ruta aflat este redistribuit printr-un algoritm de rutare A2, i R1 i R2 sunt vecini n instanierea 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 participani la o instaniere comun de IGP (ele sunt n aceeai arie dac IGP are arii de rutare) i R1 a aflat o rut spre X de la aceast instaniere IGP. 4) R1 a aflat o rut spre X de la BGP i R2 este pereche BGP pentru R1.
IGP R2 R1 IGP R3 dest X dest R3 X (2), (4) (1)
A2/BGP R2 R1 IGP R2
A1/BGP
Tunel R1 R2
R1
(3)
Figura 1-31 Cazuri de perechi pentru distribuia de etichete Regulile generale de mai sus asigur : - dac o rut spre X estre distribuit prin IGP/BGP atunci ruterele pereche pentru distribuia de etichete spre X sunt vecini IGP, respectiv BGP. 1.6.1.1.2 Distribuia 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, ctre toi LSR pereche pentru acest LSR. Caz special : - ruterul n cauz NU a facut el insusi legarea etichetei pentru direcia X - ci doar a aflat despre aceast legatura El totusi trebuie s distribuie aceast informaie.
page
36
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 1.6.1.1.3 Folosirea rutelor de tip nod-cu-nod ca LSP un R2 este " next-hop - BGP " spre X i tie c R2 a fcut legtura etichet-X,
- atunci R1 trebuie s distribuie legtura etichet-X ctre toi LSR care sunt pereche BGP cu el .
Dac o ruta "hop-by-hop" pe care un pachet P (src, dst) o urmeaz este <R1,,Rn>, atunci ea poate fi LSP, ct timp se ndeplinesc condiiile: 1) exist un singur prefix X, astfel nct pentru orice i, 1i<n , X este ("best match") n tabelul de dirijare al lui Ri, pentru adresa dst 2) pentru orice i, 1i<n, Ri a atribuit eticheta L lui X i a distribuit L catre R[i-1]. Un LSP al unui pachet se poate prelungi pn ce se intlnete cu un ruter a crui 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.
date R1 LSP1 dest R2 Adv. ptr. X 10.2.153/23 10.2.154/23 10.2/16 R3 X 10.2.153.78 Adv. 10.2/16 ptr. X
Figura 1-32 Exemplu de LSP spre destinaia X Fie destinaia X= 10.2.153.78. Presupunem c : Concluzii: R2 a distribuit o rut agregat spre R1. Pachetul P va fi dirijat pe LSP1 pn la R2. Deoarece R2 a efectuat o agregare de rute cnd a distribuit informaia lui R1, n consecin R2 va trebui s ruleze din nou algoritmul best match , pentru a gsi FEC pentru pachetul P. Deci calea LSP1 se termin la R2. Definitii: Rutere LSP de ieire ("LSP Egress") i rutere "proxy-egress": Un LSR R este "LSP Egress" pentru un prefix X, dac i numai dac se ndeplinete una dintre condiiile : 1) pentru o adres dst=Y a unui pachet, exista un X in tabelul Fwd. al lui R este "longest match"
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
37
pentru Y 2) R este un punct de de agregare pentru prefixul X a. Mai detaliat, R conine 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 cunoate nici unul dintre aceste prefixe ( vezi figura 132)
Un ruter R1 este "LSP Proxy Egress", pentru un prefix X, dac i numai dac se indeplinete una din condiiile : 1) Ruterul n aval faa de R1 ("next hop" al lui R1) pentru destinaia X, este R2, dar R1 i R2 nu formeaz o pereche de distribuie de etichete (de exemplu, R2 nu cunoate MPLS); 2) R1 a fost configurat ca atare (adic Proxy Egress pentru X). Aceste definiii permit unui ruter non-MPLS sa fie ruter de ieire ( 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 ctre ruterul de ieire din LSP ctre 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) ctre Ru dac i numai dac: 1) Rd i Ru sunt perechi de distribuie 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 esena : 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).
Condiiile 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 ctre primul next-hop din tunel.
page
38
1.6.3
Rutarea multi-cale i arbori de ci LSP
Dac un ruter LSR poate alege mai multe ci spre o destinaie X, pentru un flux particular, atunci el poate distribui n amonte ctre un Ru, nu una ci mai multe etichete diferite, de forma ( L1, X) ( L2, X) ( L3, X), legate cu o aceeai destinaie X, indicnd prin aceasta existena de opiuni n alegerea rutei spre X de ctre Ru. Este posibil a defini i arbori de ci LSP ca n Figura 1-33, caz n care R3 va distribui aceeai etichet (L2, X) ctre R1 i R2. Pe linkul R3-R4 se va folosi o aceeai 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 reea. Notm c acest mod de lucru creaz dificulti n cazul ruterelor ATM-LSR care nu pot lucra n mod multi-punct la punct, [ ].
R1
Cale nod-cu-nod <R1, R3, R4 > (L2, X) (L2, X)
R3 (L3, X)
R4
X Destinatie
R2
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.
AS2 AS1 R1 R2 R3 R4 AS3
EBGP
IBGP
EBGP
Figura 1-34 Relaii EBGP i IBGP AS1, AS2, AS3 domenii autonome R1, R4 rutere de frontier care ruleaz protocoale BGP. Interior BGP: Dou rutere care aparin aceluiai AS i schimb ntre ele informaii despre rute exterioare lui AS ( cunoscute de catre ele), se numesc rutere BGP aflate n relaie intern IBGP. Doi vecini interni schimb ntre ei mesaje despre rute aflate din alte surse: de la EBGP
page
39
sau n mod static. External BGP: Dou rutere care aparin unor domenii AS diferite i schimb ntre ele informaii despre rute, se numesc rutere BGP n relaie extern EBGP. Vecinii BGP schimb ntre ei mesaje despre rute aflate din alte surse: EBGP sau n mod static. aceleai tipuri de mesaje, de atribute ale acestora i o aceeai main cu stri finite extins (EFSM) care le definete comportamentul,
IBGP i EBGP au n comun
dar pot avea reguli diferite privind prefixele de adres ( advertising prefixes) pe care le anun ctre vecinii lor: prefixele invate de la o entitate EBGP pot fi transmise unui vecin IBGP prefixele nvate de la un vecin IBGP nu pot fi transmise altui vecin IBGP- pentru a evita buclele.
n(y) AS1 R1 m(x) R2 n(y) m(x) AS2 m(x) R4 EBGP x IBGP
Nu se transmite n(y) spre R4
R3
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 reea virtuala (mesh) de conexiuni BRi - BRj prin care se distribuie informaiile 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 informaiile privitoare la rutele externe. Soluia uzual pentru tranzitare este construcia 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 cte o etichet pentru fiecare prefix de adres ctre care BRj are o rut extern. - protocolul IGP din A menine cte 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. Considerm doua scenarii posibile:
40
Scenariul 1.
Pp: B1 i B2 sunt vecini - BGP iar B1 primete un pachet neetichetat P. n tabelul de rutare BGP al lui B1 (Fig.1-36 ) X = cea mai lung potrivire pentru adresa destinaie din antetul lui P (X poate fi prefix sau adr. completa a unei masini) Presupunem c B2 a fcut legtura ntre eticheta L2-X i a transmis perechea (L2, X) lui B1. Presupunem c prin informaiile produse de IGP, ruterul intern I1 a fcut legtura 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 aciunile de tip MPLS asupra pachetului P: push L2, push L1 - n stiva lui P transmite pachetul cu eticheta L1 n top ctre I1 n I1 are loc comutaia etichetei L1 n alt valoare, .a.m.d. pn ce pachetul ajunge la B2 B2 elimina (pop) nivelul de etichete corespunztor tunelului i face comutaia dup eticheta L2.
P X B1
(L2, X) I1 B2 X
(L1, B2)
L1 Tabel BGP Adr Next hop IGP X B2 Next hop = I1 BGP peers L2 P AS
Figura 1-36 Stabilirea unui tunel printr-un domeniu autonom. Scenariul 1.
Scenariul 2.
B1 primete un pachet etichetat P, cu eticheta L2. o o deoarece P are deja o etichet extern, B1 va face comutaia L2 Lk, apoi creaz tunelul prin push L1 i transmite pachetul etichetat spre I1, etc. Deoarece ruterele interioare lui AS nu cunosc legturile (etichet - prefix_adres) fcute de BGP, rezult c ruterele de frontier BR ( border router) trebuie s se afle reciproc n perechi de relaii explicite ( fiecare cu fiecare) privind distribuia 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 137 extins de la BR1- BR3, din AS1 pn la din AS3: BR3 distribuie rute la BR2 via EBGP i opional atribuie etichete la prefixele de adres. BR2 redistribuie rutele la BR1 (via IBGP), inicnd 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 ctre BR2.
page
41
Protocolul intern IGP din AS1 are o rut de tip host spre BR3.
BR1
AS1 IBGP
BR2 EBGP
BR3
AS2
Zona comuna ce apartine lui AS1 si AS2 (demilitarizata)
Figura 1-37 Tunel extins pe linkul dintre dou domenii
page
42
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 SPs 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.
page
43
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)
44
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.
page
45
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
page
46
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
Degree of service differentiation IntServ

Per class QoS processing Per flow: QoS processing
DiffServ Complexity Best Effort

No QoS processing
Scalability
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 providers 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.
page
47
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:
48
- 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 :
49
- 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
DS Domain A
DS Domain B
CR ER CR BR BR
CR ER CR ES
ES
Figure 1-4
ER Edge Router BR Border Router ES End System CR Core Router
DiffServ Domains
page
50
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 Conditioning Agreemnt (TCA), including metering, marking, shaping, and policing. Traffic
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)
page
51
Quality consideration Perceived QoS (PQoS)
Description Users perception
Units/parameters Platinum/Olympic, Gold, Silver, Bronze Video: Codec, frame size, frame rate, colour depth. Audio: Number of channels, sampling rate Processing power, memory etc. For video terminals: Resolution, number of colours, frame rate, encoders Bandwidth, performance-related information Bandwidth/throughput, packet loss, delay, jitter
Requirement/Co nstraint from End-User View R/C
Application software (e.g. NetMeeting, Application level RealPlayer) requirements Terminal Access Connectivity Network Terminal characteristics Access last mile characteristics Network level QoS parameters
R/C C
R/C R/C
Figure 1-5 QoS factors
page
52
SLA Element/Clause Resource Scope Type of service Service schedule & Activation time Application level (Traffic and Performance) requirements/constraints Terminal capability Connectivity/Access
Attributes/Parameters Digital Item Id Addresses Premium or Olympic Service Service invocation time/date MPEG-7 Media Information and Media Format, Service Class canonical meanings MPEG-21 Terminals Descriptor (codecs, processing power) Access Networks information (MPEG-21 Network Condition descriptor) Reliability, Outages, Interface throughput Mean downtime (MDT), Mean time to repair/patch (MTTR) Authentication & authorisation parameters etc. By DI content, SP contract, etc.
Description Identifier for the Digital Item User end-point, Content end-point User perception Content delivery start and stop times Application performance requirements
Terminal capability constraints Last-mile connectivity information
Availability Guarantees Reliability Guarantees Security Billing Others
Guarantees for service invocation Service guarantees in terms of reliability Information required for using the service and accessing the content Cost and payment aspects
Figure 1-6 SLA template with clauses (optional/mandatory)
page
53
SLS Element/Clause SLS Identification Scope Flow Identification Traffic Conformance (TC) Key
Attributes
Description A unique identification key (set by service provider). Identifies the topological region over which the QoS applies (IP addresses or layer 2 identifiers).
Ingress-Egress points
DSCP, source, destination, Defines the stream of IP datagrams. application information TC Algorithm and Describes the criteria that injected traffic should parameters for in and out of comply with to get QoS guarantees specified by profile packets 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. Action for out-of-profiles Describes how the excess traffic will be treated. packets Delay, loss, throughput, error Timetable planning for jitter, Describes the performance guarantees a provider agrees to offer to the packets entitled to this SLS. delivery Describes possible time intervals allowed for service invocation. Describes the allowed figure of non-availability of the service
Excess Treatment Network Level Performance Guarantees Service Schedule (optional) Reliability (optional)
MDT per-year etc.
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
page
54
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.
55
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
page
56
token generator M= measuring algorithm rate R Bucket size B Conforming packets (pass) M Non-conforming packets Discard/mark
Current fill (c= credit) arriving packets
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)
page
57
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.
Meter Classifier Marker
Shaper/ Dropper
Traffic Conditioner
Figure 1-9 Logical View of a Packet Classifier and Traffic Conditioner in Edge Router ( RFC 2475)
Traffic Conditioner
Shaper
Classifier Marker
Dropper Meter
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.
58
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) PHBdedicated to low-loss, low-latency traffic Assured Forwarding (AF) PHBgives assurance of delivery under prescribed conditions Class Selector PHBswhich 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.
59
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 lessof 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
page
60
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 domains 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 providers 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
page
61
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
page
62
Figure 1-12 IP ToS field and DSCP (1)
7
MBZ
3 DSCP
7
CU
Precedence
Type of Service
RFC 1122
RFC 1349
Must Be Zero
Class Selector
U nused
IP Type of Service (TOS)
Differenciated Services Codepoint (DSCP)
Figure 1-13 IP ToS field and DSCP (2)
page
63
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
64
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)
page
65
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
page
66
- 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
01234567890123456789012345678901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | TC |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry Label: Label Value, 20 bits
TC:
S: TTL:
Traffic Class field, 3 bits

Bottom of Stack, 1 bit Time to Live, 8 bits
page
67
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
page
68
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. 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.
page
69
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.
70
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, CoSbased 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 links 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:
71
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).
page
72
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], [ISISTE], 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 perclass basis. For example, an LSR can o calculate the bandwidth utilized by all existing traffic trunks on the per-CT and perpreemption 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
page
73
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 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.
Real life:
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
1.8.1.1
Label Distribution with LDP

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 o a directly attached neighbor (comparable to IP hop-by-hop forwarding), 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.
page
74
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 endto-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 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). 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 bindingthat 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
page
75
Phase 1
Phase 2
129; Data
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.
page
76
ANEXE
2.1 Metode de codificare pentru ATM_MPLS:
1. Codificare SVC ("Switched Virtual Circuit"): se folosete VPI,VCI pentru a codifica eticheta din vrful stivei. Aceast metod poate fi utilizat n orice reea. Protocolul de distribuie a etichetelor LDP devine protocol de "semnalizare" ATM. Observm c, comutatoarele ATM-LSR nu pot face operaii de eliminare i adugare a etichetelor din stiv. 2. Codificarea SVP ("Switched Virtual Path"): se folosete VPI pentru a codifica eticheta din vrful stivei i VCI pentru a codifica urmtoarea etichet din stiv, dac exist. n acest caz, ATM-LSR efectueaz numai comutaie de fascicule virtuale (VP) 3. Codificarea SVP multipunct (SVP Multipoint Encoding): se folosete VPI pentru a codifica eticheta din vrful stivei, o parte din VCI pentru a codifica urmtoarea etichet din stiv (dac exist), i partea rmas din VCI pentru identificarea nodului LSR "ingress". Metoda este folosit pentru VP-uri multipunct-la-punct cu condiia ca punctele de intrare s fie codificate cu VCI diferite. Dac n stiv exist mai multe etichete astfel nct spaiul de bii VPI, VCI nu este suficient, atunci se poate folosi o ncapsulare combinat (generic i VPI/VCI). Apare problema interoperabilitii celor doua tehnici de codificare a etichetelor. Arhitectura MPLS prevede c pot exista ci LSP de-a lungul carora se pot folosi tehnici diferite de codificare a etichetelor n noduri de reea diferite. Cnd primete 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 ieire. Totusi, comutatoarele ATM nu pot face translaia ntre tehnicile de codificare. Este necesar ca dou LSR-ATM successive s foloseasc aceeai tehnic de codificare. Dac un LSR are interfee cu ncapsulare generic i interfee de tip LC-ATM, atunci el trebuie s fie capabil a efectua translaia.
2.2
Opiuni pentru reducerea numrului de etichete
n practic are importan aplicarea, dac este posibil,a unor metode de reducere a numrului de etichete, deoarece anumite comutatoare/rutere utilizate n context MPLS pot avea limitri asupra numrului maxim de etichete tratabile. Una dintre aceste metode este alocarea de etichete orientat spre un ruter de ieire (Egress Targeted Label Assignment). Ideea de baz este ca dac un ruter de intrare Ri (Ingress LSP), cunoate c pachetele care aparin unor clase FEC diferite, vor urma aceeai LSP ctre un ruter de ieire Re (Egress Router), atunci Ri poate aloca aceeai etichet pentru toate FEC n cauz. Condiiile necesare i suficiente ca s se poat face aceast aciune sunt: 1. adresa lui Re se gsete 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 condiia 2. se pot afla de ctre Ri sunt descrise n continuare: a. toate nodurile respectivei arii suport MPLS i exista un algoritm de tipul link state care poate informa pe Ri asupra rutelor prin care pachetele din FEC respective pot iei din domeniul/aria de rutare, spre destinaia dorit reeaua ruleaz un protocol BGP, deci Ri poate determina ca o clas FECi particular, poate prsi reeaua printr-un anumit ruter Re, care este i pereche de tip BGP cu ruterul Ri i BGP
page
b.
77
next-hop pentru acea clas FEC c. LDP poate distribui informaii despre anumite prefixe de adres ataate unor LSP-Egress. Aceasta ar evita necesitatea existenei unui algoritm de rutare de tipul link state
O reea se poate configura ca n mod implicit s lucreze cu opiunea (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 interfee distincte. Cum va aloca Re etichete n amonte? RFC 3031 propune mai multe soluii: Re aloc acelai prefix L . Prin aceasta Re devine LSP Egress pentru cele n prefixe de adres. Totui pentru a putea determina pe care I/F de ieire 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, cte o eticheta distinct fiecrei I/F de intrare. Astfel, Re devine un Proxy-Egresspentru cele n prefixe de adres. Re nu mai trebuie s fac analiza antetului L3 pentru a detrermina pe care I/F de ieire 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 insui); Re leag cte 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 Ru eticheteaz un pachet P, neetichetat, avnd o adres de destinaie 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. Ru execut push L2 i apoi push L1 n stiva de etichete a lui P Ru dirijeaz pachetul spre Rd cnd Ru distribuie eticheta asociat de el lui X, ctre ruterele din amonte, el va include L2 ca un atribut n stiva de etichete actualizeaz atributul din stiv n situaia n care ar aprea modificri ale acestuia.
Se impun urmatoarele reguli de functionare, valabile n situaia n care: -
Regulile sunt:
Observm 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 interfeelor ATM-LC
Problema principal a unificarii etichetelor n acest caz, este aceea c dac mai multe fluxuri diferite de celule ATM primesc o aceeai etichet VPI/VCI iar celulele lor sunt intercalate n timp pe legtura de date, atunci nu mai este posibil identificarea fluxurilor originale i deci nici reasamblarea din celule a datagramelor. RFC 3031 propune dou soluii, prezentate sumar mai jos. a. Unificarea de etichete la nivel de VP (VP merge) Aceast metod este utilizat n contextul codificrii SVP multipoint-to-point. Presupunem un LSR i la intrarea acestuia n fluxuri etichetate diferit, dar care aparin la aceeai FEC. Pentru unificarea etichetelor n LSR se folosete la ieirea acestuia: o etichet VPI comun pentru cele n fluxuri; n etichete
page
78
VCI distincte pentru cele n fluxuri. Astfel se poate face distincia 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 ieirea 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 menine prin evitarea intercalarii n timp a celulelor unor datagrame diferite. Se folosete indicatorul de sfarit 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 ntlnite 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 interfee de celule ATM
Considerm mai multe cazuri/exemple. a. ATM-LSR cu unificare la nivel de VC. Fie legtura 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 numr de etichete VPI/VCI egal cu numarul de fluxuri pe care dorete s le unifice i n plus va cere etichete fcnd 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 dorete 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 VP-merge Rum1 Ru VP-merge Rum2 Flux6 Ru VP-non-merge Rd3 Ru Cereri etichete
Figura 2-1 Configuraie de noduri ATM-LSR Rd3 va face n aval urmtoarele cereri de etichete: cerere de VPI/VCI pentru el traficul cu originea n el nsui 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 reea MPLS s poat suporta configuraii mixte de tipul VC-merge, VPmerge, non-merge, este necesar ca ruterele LSR s poat cere de la cele din aval de ele combinaii de etichete:
page
79
n 0 identificatori de VC ( constnd n VPI/VCI) n 0 identificatori de VP ( identificatori VPI)
Fiecare dintre aceti identificatori poate conine un numar specificat de VC-uri.
page
80
REFERINTE
page
81

Arhitecturi Pentru Retele Integrate de Banda Larga

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Arhitecturi Pentru Retele Integrate de Banda Larga

Încărcat de

Drepturi de autor:

Formate disponibile

ARHITECTURI PENTRU RETELE INTEGRATE DE BANDA LARGA

Master sem II 2012- 2013 Specializari: RITC

ARIBL-RITC Master 2012-2013

1.4.2.1 1.4.2.2 1.5.1.1 1.5.1.2

1.5 ELEMENTE DE BAZA ALE MPLS 1.5.1 Codificarea etichetelor

Detalierea fazelor de operare MPLS

Decizia de alocre a etichetelor Utilizarea stivei de etichete Manevrarea etichetelor

Procedura de stabilire a tunelului Un caz special de tunel

MPLS Support of DiffServ

1.8.1.1 1.8.1.2 1.8.1.3

General features Messages Summary of Operation

ARIBL-RITC Master 2012-2013

COMUTAIA DE ETICHETE MULTIPROTOCOL (MPLS)

ARIBL-RITC Master 2012-2013

Dirijare normala (IP) e1 ER LSR

Dirijare normala (IP)

ER LSR Cale M PLS (LSP)

Avantaje ale tehnologiei MPLS

MPLS : avantaje importante n special pentru reele centrale (core) avansate:

nivele de etichete) i tehnici tunel.

se poate generaliza i aplica i n reele optice (GMPLS)

Definiii i terminologie MPLS

ARIBL-RITC Master 2012-2013

Etapele de funcionare n rutarea IP i n MPLS Rutarea convenional (IP)

ARIBL-RITC Master 2012-2013

Rutarea bazat pe MPLS

comuta etichete (se poate realiza PHB)

Tabel de comutare etichete

-elimina eticheta - analiza L3 dirijeaza pachet ER

Calea LSP cu comutare de etichete (identificata in ER)

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

Comparaie intre un ruter tradiional i un ruter MPLS

ARIBL-RITC Master 2012-2013

Protocoale rutare IP Tabele rutare IP

Routing Updates actualiz. rute

Plan control C Protocol rutare IP Tabela rutare IP

Actualizare ptr legarea etichetelor

Control de rutare IP MPLS

Label info Base

Plan de date (U)

Procesare pachete Buffer

Label Forwarding Info Base (LFIB)

Pachete in LC=line Card

Pachete out Buffer

Figura 1-3 a. Ruter traditional IP

b. Ruter de frontiera - MPLS

Elemente de baza ale MPLS Codificarea etichetelor

IP-H MPLS-H IP-H

Date aplicatie Date aplicatie

Datgrama IP Datgrama IP etichetata

Figura 1-5 Pachet cu stiva de etichete 1.5.1.2 Incapsularea MPLS

Antet MPLS Shim header

Antete de nivel superior

Figura 1-6 Incapsularea generic MPLS

ARIBL-RITC Master 2012-2013

Antet MPLS Antet MPLS

Antet ATM Antet ATM

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

Point-to-Point Protocol (PPP)

ARIBL-RITC Master 2012-2013

ruter LSR, este necesar

ARIBL-RITC Master 2012-2013

Detalierea fazelor de operare MPLS