Biologie | Chimie | Didactica | Fizica | Geografie | Informatica | |
Istorie | Literatura | Matematica | Psihologie |
MPLS in Retele Optice
Capitolul 1 Prezentarea protocolului MPLS
Introducere
Fiecare dintre ultimele trei secole a fost dominat de o anumita tehnologie. Secolul al XVIII-lea a fost secolul marilor sisteme mecanice care au insotit Revolutia Industriala. Secolul al XIX-lea a insemnat era masinilor cu aburi. In secolul XX, tehnologia cheie este legata de colectarea, prelucrarea si distribuirea informatiei. Printre alte realizari, am asistat la instalarea retelelor telefonice mondiale, la inventia radioului si a televiziunii, la nasterea si cresterea nemaivazuta a industriei de calculatoare si la lansarea satelitilor de comunicatii.
Datorita progresului tehnologic rapid, aceste domenii converg in ritm alert, iar diferentele intre colectarea, transportul, stocarea si prelucrarea informatiei dispar pe zi ce trece. Organizatii cu sute de birouri raspandite pe o arie geografica larga se asteapta sa poata examina in mod curent printr-o simpla apasare de buton chiar si echipamntele lor cele mai indepartate. Pe masura ce posibilitatile noastre de a colecta , prelucra si distribui informatia cresc tot mai mult, cererea pentru o prelucrare si mai sofisticata a informatiei creste si mai rapid.
Desi industria de calculatoare este tanara in comparatie cu alte industrii (de exemplu constructia de automobile si transportul aerian), domeniul calculatoarelor a cunoscut un progress specataculos intr-un timp scurt. In primele decenii de existenta, sistemele de calcul erau foarte centralizate, de obicei in interiorul unei singure incaperi. Adesea, aceasta incapere avea peretii de sticla prin care vizitatorii se puteau holba la marea minune electronica dinauntru. O companie de marime mijlocie sau o universitate ar fi putut avea unul sau doua calculatoare, in timp ce institutiile mari aveau cel mult cateva zeci. Ideea ca in mai putin de 20 de ani calculatoare la fel de puternice, mai mici decat un timbru postal, vor fi produse pe scara larga in milioane de exemplare parea desprinsa dintr-un scenariu stiintifico-fantastic.
Intrepatrunderea dintre domeniul calculatoarelor si cel al comunicatiilor a avut o influenta profunda asupra modului in care sunt organizate sistemele de calcul. Conceptul de "centru de calcul" - in acceptiunea sa de camera unde exista un calculator mare la care utilizatorii vin sa ruleze programele - este total depasit. Vechiul model al unui singur calculator care serveste problemele de calcul ale organizatiei a fost inlocuit de un model in care munca este facuta de un numar mare de calculatoare separate, dar interconectate. Aceste sisteme se numesc retele de calculatoare.
Deosebim in acest context doua tipuri de retele :
Din punct de vedere al intinderii lor ca arie geografica, deosebim alte trei tipuri de retele :
-retele locale (LAN-Local Area Network) sunt retele private localizate intr-o singura cladire sau intr-un campus de cel mult cativa kilometri. LAN-urile se disting de alte tipuri de retele prin 3 caracteristici : (1) marime, (2) tehnologie de transmisie si (3) topologie. Astfel (1) LAN-urile au dimensiuni restranse ceea ce inseamna ca timpul de transmisie e limitat si dinainte cunoscut. Cunoscand aceasta limita, este posibil sa utilizam anumite tehnici de proiectare. Deasemeni, se simplifica administrarea retelei. Pentru (2), LAN-urile utilizeaza frecvent o tehnologie de transmisie care consta dintr-un singur mediu (cablu in special, dar exista si Wireless LAN) la care sunt atasate toate masinile. LAN-urile traditionale functioneaza la viteze cuprinse intre 10 si 100 Mbps, au intarzieri mici (zeci de microsecunde) si produc erori foarte putine. In privinta (3), mai cunoscute sunt reteaua cu magistrala (cu cablu liniar), de exemplu standardul IEEE 802.3, popular numit Ethernet (functionand la 10-100 Mbps) si standardul IEEE 802.5 numit inel cu jeton (token ring) ce lucreaza la viteze de 4-16 Mbps.
-retelele metropolitane (MAN-Metropolitan Area Network) este in linii mari o versiune extinsa de LAN si utilizeaza in mod normal topologii similare cu acesta. Un MAN se poate intinde pe zona ocupata de un grup de birouri invecinate sau pe suprafata unui intreg oras si poate fi atat privata cat si publica. Un MAN poate suporta atat date cat si voce si dispune numai de un cablu sau doua, fara sa contina elemente de comutare care deviaza pachetele pe una din cele cateva linii posibile de iesire.Un exemplu de MAN este standardul IEEE 802.6 denumit DQDB (Dual Queue Dual Bus- magistrala duala cu coada distribuita). DQDB consta din doua magistrale unidirectionale la care sunt conectate toate calculatoarele.
-retelele larg
raspandite geografic (WAN-Wide Area Network) - acopera o arie geografica intinsa -
deseori o
Ce este MPLS
Multi-Protocol Label Switching (MPLS) este un set de protocoale care devine tot mai folosit pentru provizionarea si managementul nucleului retelelor. Retelele pot fi de date, exemplu fiind cele ale furnizorilor de internet, pot fi de voce cum ar fi cele ale companiilor traditionale de telecomunicatii, sau pot fi retele convergente care conbina datele cu vocea. In general la extremitati, toate retelele converg catre un model care foloseste Internet Protocol (IP) pentru transportarea datelor.
Tehnologia MPLS este bazata pe conceptul de tag switching (schimbare de eticheta) elaborat de Cisco, inspiriat de IP switiching scheme, o abordare de switching de pachete IP in retele ATM propus de Ipsilon Networks (care a fost mai tarziu cumparata de firma Nokia). MPLS a fost standardizat de IETF, si introduce o structura orientata pe conexiune intr-o retea fara conexiune IP. MPLS este mai rapid decat cautarea in tabela de rutare pentru a determina urmatorul router pentru un pachet IP. De asemenea este folosit pentru implemetarea Quality of Service (QOS) in retelele IP.
MPLS necesita un set de proceduri pentru distribuirea de etichete in mod sigur. Nu este impus un anumit protocol, astfel mai multe modalitati de distribuire a etichetelor au fost propuse dintre care Label Distribution Protocol (LDP) si resource reservation protocol - traffic engineering (RSVP-TE) sunt cele mai des intalnite.
Internet Protocol (IP)
IP este o parte din stiva de protocoale Transmission Control Protocol/Internet Protocol (TCP/IP) folosita in Internet. Aceste protocoale au fost dezvoltate la mijlocul anilor 70 de Defense Advanced Research Projects Agency (DARPA) pentru a facilita comunicatia intre sisteme de calcul diferite. Aceste protocole sunt impartite de modelul Open Sistem Interconnec (OSI). TCP apartine nivelului 4, de jos in sus, nivelul transport iar protocolul IP apartine nivelului 3, de retea.
Modelul OSI
FTP (File Transfer protocol) Telnet SMTP (Simple Mail Transfer Protocol) SNMP(Simple Network Management Protocol) |
TCP sau UDP |
IP , protocole de rutare(RIP, OSPF, IS-IS) |
Ethernet, FDDI, Token Ring |
Semnale electrice, optice, radio |
7.Aplicatie |
6.Prezentare |
5.Sesiune |
4.Transport |
3.Retea |
2.Legatura de date |
1.Fizic |
Protocolul Internet (IP) este
un protocol de nivel 3 care contine informatie despre adresa si cateva
informatii de control care faciliteaza rutarea pachetului. IP este descris in RFC 791 si este principalul protocol de
nivel retea in
IP ofera o livrare lipsita de conexiune prestabilita, folosind tehnica de rutare a pachetelor. Intr-o retea orientata pe conexiune cum este cea de telefonie intai se stabileste un circuit logic intre echipamente pe care il vor urma datele apoi toate datele urmeaza aceasi cale intre entitatile comunicante. Intr-o retea lipsita de conexiune prestabilita, nu exista un circuit logic ci adresa de destinatie continuta in pachetul ip este analizata de fiecare ruter in parte, in urma compatariei cu tabela de rutare, echipamentul decide pe loc interfata pe care trebuie sa iasa pachetul spre destinatie.
Un pachet IP este format dintr-un preambul si sarcina, datele transportate intre statiile comunicante. Consta dintr-o parte fixa de 20 de byti si o parte optionala de lungime variabila. Campurile urmatoare sunt definite intr-un pachet IP:
Versiune |
LPI |
Tip-de-Serviciu |
Lungime Totala |
|
Identificare |
Fanioane |
Decalajul Fragmentului |
||
Timp de viata |
Protocol |
Suma de Verificare a Preambulului |
||
Adresa Sursa |
||||
Adresa Destinatie |
||||
Optiuni |
Adresarea IP
Fiecari gazde a unei retele TCP/IP ii este atribuita o retea IP unica de 32 de biti care este divizata in doua parti: partea de retea si partea de gazda. Adresele sunt distribuite de furnizorii de internet care la randul lor cumpara clase de adrese de la institutii care distribuie, cum ar fi Réseaux IP Européens (RIPE).
Adresa IP este impartita in 4 grupuri a cate 8 biti, separati de puncte si reprezentata in forma zecimala.
<--------- 32biti --------->
RETEA |
GAZDA |
...
172 . 16 . 1 . 1
Clasele de adrese IP
Adresarea IP suporta cinci clase diferite A,B,C,D si E. Doar clasele A, B, si C sunt disponibile pentru uz comercial. Clasa D este folosita pentru multicasting, clasa E este folosita in scopuri experimentale. Bitii din stanga indica clasa retelei.
Clasa A
0 |
Retea |
Gazda |
Clasa B
10 |
Retea |
Gazda |
Clasa C
110 |
Retea |
Gazda |
Clasa D
1110 |
Multicasting |
Clasa E
11110 |
Folosite experimental |
Rutarea de pachete IP
Protocoalele de rutare IP sunt dinamice. Aceste aplicatii dinamice solicita echipamentelor (ruterelor) calcularea automata a rutelor la intervale regulate. Acest lucru este in contrast cu rutarea statica, unde rutele sunt stabilite de admnistrator si nu se schimba decat atunci cand administratorul doreste.
O tabela de rutare IP, consista din perechi adresa IP/urmator router. Tabela este folosita pentru a facilita rutarea dinamica. Un rand din tabela de rutare s-ar putea interpreta astfel: pentru a ajunge la reteaua X trimite un pachet pe interfata Ethernet Y.
Rutarea IP specifica ca pachetele IP sa parcurga traseul de la sursa la destinatie din echipament in echipament si la fiecare ruter se calculeaza interfata de iesire in functie doar de adresa destinatie si de tabela de rutare, nu exista o ruta prestabilita.
Dezavantajele Rutarii Traditionale de Pachete IP
Deoarece la fiecare ruter in parte se face o cautare in tabela de rutare, atunci cand un pachet ajunge pe o interfata se pot consuma resurse din ce in ce mai mari in functie de tabela de rutare. Tabelele de rutare pot contine de la cateva rute, pentru firmele mici pana la peste 100,000 in Internet astfel cautarea poate dura mult timp.
In retelele ATM, switch-urile de nivel 2 nu au cunostinte despre rutarea la nivel 4, astfel circuite virtuale trebuiesc configurate manual.
La nivelul 2 topologia poate diferi de cea la nivelul 3, de unde rezulta cai de comunicatie suboptime. De obicei la nivel 2 configuratia este de tipul Hub and Spoke ( butuc cu spite) pentru un management mai usor si costuri mai reduse. Astfel un pachet care trebuie sa mearga dintr-o spita in alta trebuie sa treaca mai intai prin butuc, parcurgand astfel cai suboptimale.
Descrierea tehnologiei MPLS
MPLS este un nou mecanism de innaintare a pachetelor bazat pe etichete. Etichetele de obicei corespund retelelor destinatie, sau pot corespunde altor parametrii cum ar fi calitatea serviciilor sau adresa sursa.
Figura de mai jos demonstreaza modalitatea de functionare a unei retele in care este implementat MPLS. Ruterul intermediar nu trebuie sa mai faca o cautare care consuma timp in tabela de rutare. Echipamentul doar schimba etichetele intre ele (12 este inlocuit cu 23) si inaintarea pachetului se face bazandu-se pe eticheta primita (12) si nu nu dupa adresa IP destinatie. Astfel, in retelele mai mari doar ruterele din extremitati fac o cautare dupa IP destinatie, restul echipamentelor doar schimba etichete, un proces mult mai rapid.
In retelele de tip ATM, switch-urile trebuie sa cunoasca protocoalele de nivel 3, ele trebuie sa ruleze un protocol de rutare. Astfel nu mai este nevoie de stabilirea manuala a circuitelor virtuale si MPLS creaza automat cu ajutorul informatiilor de nivel 3 o arhitectura de tip full-mesh(fiecare are legatura cu fiecare).
Arhitectura MPLS
MPLS este alcatuit din doua componente arhitecturale principale:Planul de Control si Planul de Date. Planul de control se ocupa cu schimbul informatie de rutare si schimbul etichetelor intre rutere adiacente in timp ce planul de date este mai simplu si mai rapid, el se ocupa de inaintarea pachetelor bazata pe adresa destinatie sau dupa eticheta.
Un numar mare de protocoale diferite pot fi folosite in planul de control. Protocoalele de rutare folosite pot fi: Open Shortest Path First (OSPF),Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol(EIGRP), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP). De asemenea se folosesc si protocoale de schimbare a etichetelor cum ar fi: Tag Distribution Protocol (TDP), Label Distribution Protocol (LDP), BGP (Folosit in VPN-uri tip MPLS). Resource Reservation Protocol (RSVP) este folosit in Ingineria Traficului.
Planul de date este un plan simplu de inaintare a pachetelor in functie de eticheta, care este independent de tipul de protocol de rutare sau de protocolul de schimbare a etichetelor. Tabela cu informatii despre etichete (LFIB Label Forwarding Information Base) este folosita pentru a inainta pachetele in functie de etichete. Aceasta tabela este populata de protocoalele de schimbare a etichetelor (TDP sau LDP).
In exemplul de mai sus este explicat cum este folosit planul de control pentru a crea planul de date. Protocolul de rutare RIP primeste ruta 1.1.1.0/8, o instaleaza in tabela de rutare si o propaga mai departe catre alte rutere vecine. De asemenea protocolul de schimbare a etichetelor LDP primeste eticheta 22 atribuita retelei 1.1.1.0/8 de catre ruterul vecin, aceasta atribuire este instalata in tabela de etichete (FIB). O alta eticheta 44 este atribuita local si apoi propagata prin LDP la ruterul vecin. In planul de date este creata legatura intre eticheta 44 si eticheta 22, astfel atunci cand un pachet etichetat cu eticheta 44 ajunge la ruter, acest pechet este trimis spre ruterul vecin si eticheta este schimbata in 22.
Etichetele MPLS
MPLS poate fi folosit in aproape orice fel de retea de nivel 2. Majoritatea protocoalelor de incapsulare la nivel 2 folosesc "rame" pentru incapsularea pachetelor IP, astfel pachetul nu este segmentat. In acest tip de retele, MPLS introduce un camp de 32 de biti intre preambulul de nivel 2 si cel de nivel 3.
In cazul retelelor de nivel 2 ATM, incapsularea se face in celule fixe de 53 de byti, si o eticheta nu poate fi introdusa in fiecare celula, ocupand prea mult spatiu. MPLS foloseste campul Virtual Path Identifier/Virtual Channel Identifier(VPI/VCI) din preambulul ATM ca eticheta.
Preambul Nivel 2 |
Preambul MPLS |
Preambul IP |
Date |
Pachet IP cu eticheta MPLS incapsulat in rama
22 23 24 32
ETICHETA |
EXP |
S |
TTL |
Preambul MPLS
Preambulul
MPLS contine un
In retelele ATM, pe baza de celule, MPLS foloseste campul VPI/VCI din preambulul ATM pentru decizii de inaintare a celulelor. Preambulul MPLS de 32 de biti este pastrat in pachet dar nu este folosit in reteaua ATM. Eticheta originala este pastrata doar in prima celula a pachetului segmentat.
Preambul ATM |
Preambul ATM Adaption Layer 5 (AAL5) |
Eticheta |
Preambul IP |
Date |
Celula 1
Preambul ATM |
Date |
Celula 2
O retea MPLS consta din Rutere pentru Switching de Etichete (Label Switch Router, LSR) si Rutere pt Switching de Etichete din Extremitati (Edge Label Switch Router, Edge LSR) . Un Ruter pentru Switching de Etichete din Extremitati este un ruter IP pe care ruleaza protocolul MPLS. Acesta poate atribui etichete FEC-urilor, poate inainta pachetele IP in functie de eticheta lor daca exista sau in functie de adresa IP destinatie. Un LSR indeplineste aceleasi functii ca un Edge LSR in afara de inaintarea pachetelor in functie de adresa IP.
************pot pune schema cu rutere edge si interne ** ** ***
Calea
pe care o urmeaza datele intr-o retea este definita de
schimbarea valorilor etichetelor in fiecare LSR. Valoarea etichetelor si
corespondenta etichetelor primite cu cele locale este
Protocoale Folosite Pentru Distribuirea Etichetelor
MPLS necesita un set de proceduri pentru distribuierea etichetelor intre LSR-uri. MPLS nu necesita folosirea unui singur protocol de distribuire a etichetelor. Astfel au fost dezvoltate mai multe mai multe metode de distribuire a etichetelor. Dintre care cele mai des intalnite sunt Protocolul de Distribuire a Etichetelor (Label distribution Protocol LDP) si resource reservation protocol - traffic engineering (RSVP-TE).
LDP este un protocol care distribuie maparile de etichete pentru o cale LSP asociata unei FEC. O extindere a acestui protocol este Constrait Basesd routing label distribution protocol (CR-LDP), care este folosit pentru a defini o ruta explicita.
O metoda alternativa de distribuire a unui protocol este extinderea capabilitatilor unui protocol IP cum ar fi BGP, PIM si RSVP pentru a distibui maparile de etichete. Versiunea extinsa a RSVP este denumita RSVP-TE si este cel mai utilizat protocol de distribuire a etichetelor.
Protocolul de Distribuire a Etichetelor
LDP este folosit pentru a crea si a mentine legaturi=mapari pentru un o cale LSP asociata cu un FEC. Doua rutere care folosesc LDP pentru a schimba etichete sunt membri LDP.
LDP foloseste protocolul TCP care asigura siguranta cu exceptia mesajelor de descoperire, care folosesc protocolul UDP, mai rapid si nesigur. LDP trimite periodic mesaje de descoperire. Daca un alt ruter foloseste protocolul MPLS, acesta intelege mesajele de initiale de descoperire si poate incepe negocierea unui sesiuni. Pachetele pentru crearea sesiunii sunt de tip TCP. Dupa crearea sesiunii sunt distribuite legaturile de etichete apoi sunt transmise in continuare mesaje de descoperire pentru a se detecta o eventuala defectiune.
Protocolul pentru rezervarea resurselor (RSVP)
O alternativa pentru LDP este resource reservation protocol - traffic engineering (RSVP-TE). RSVP-TE este o extensie a resource reservation protocol care a fost creat pentru fi folosit in arhitectura Integrated Services(intserv).
Arhitectura intserv a fost dezvolatata de IETF la mijlocul anilor 90 pentru a introduce callitarea serviciilor in reteaua IP.
Calitatea serviciilor in retelele MPLS se poate obtine prin Ingineria Traficului.
Ingineria traficului se refera la procesul de selectie a cailor alese de traficul de date pentru a facilita operatii eficiente in rete si pentru a optimiza utiliazarea resurselor. Scopul ingineriei traficului este de a calcula o cale de la un echipament la altul tinand cont de lucruri cum ar fi lungimea de banda. O data ce calea este calculata, ingineria traficului este responsabila pentru a forma si a mentine starea de inaintare pentru o astfel de cale.
Componentele ingineriei traficului
Protocoalele de rutare existente nu sunt capabile de a suporta ingineria traficului. Deciziile de rutare sunt bazate de obicei pe algoritmi care gasesc cea mai scurta cale care folosesc de obicei o metrica aditiva si nu tin cont de disponibilitatea lungimii de banda sau alte caracteristici de trafic.
Ce mai usoara cale de a furniza astfel de servicii ar fi folosirea unui protocol care se suprapune peste alte protocoale existente, astfel fiind create topologii virtuale peste retele fizice. Topologia virtuala este construita din conexiuni virtuale care sunt considerate ca fiind fizice de protocoalele de rutare. Protocolul suprapus trebuie sa furnizeze: (1) rutare constransa, in functie de latimea de banda alocata, (2) modelarea traficului, (3) monitorizarea legaturilor virtuale. Aceste capabilitati permit mutarea traficului de pe o conexiune suprautilizata catre o conexiune subutilizata.
MPLS este protocolul peste care se suprapune ingineria traficului. Multi Protocol Label switiching furnizeaza cai explicite care nu sunt constranse de protocoalele normale de rutare astfel caile facute de schimbarile intre etichete pot fi mai usor sustinute. Trunchiurile de trafic pot fi instalate si mapate pe cai LSP. Acestor trunchiuri li se pot asocia diferite atribute sau atributele pot fi asociate resurselor caracteristice trunchiurilor.
Pentru a functiona, Ingineria Traficului are nevoie de mai multe componente:
Distributia informatie
Ingineria traficului se bazeaza pe protocoale de rutare interne pentru a distribui informatii legate de conexiune, disponibilitatea resurselor, atribuitele caii, metrica specifica ingineriei traficului si clasa de resurse atribuita unei conexiuni.
Protocoalele interne de rutare au fost imbunatatite pentru a transporta noi atribute. Au fost incluse trei noi mesaje Type Length Value (TLV)
Algoritmul de rutare bazat pe constrangere
Ruterele folosesc extensii ale protocoalelor de rutare pentru a crea si a mentine baza de date a ingineriei traficului. Aceasta baza de date este similara cu baza de date folosita in alte protocoalele de rutare normale OSPF sau IS-IS. Baza de date contine topologia retelei care este tinuta la curent de mesajele protocolului de rutare de fiecare data cand se intampla un eveniment( se stabilieste o noua cale, se schimba latimea de banda disponibila).
Algoritmul de rutare bazat pe constrangere este folosit pentru a gasi cea mai buna cale pentru un tunel LSP. Este folosit de capatul de plecare al trunchiului atunci cand un nou tunel este creat, calea curenta a picat sau pentru a re-optimiza un trunchi existent.
Algoritmul i-a in considerare urmatoarele informatii:
Descrierea algoritmului:
Intai toate conexiunile care nu au resurse suficiente si incalaca politicile bazate pe constragere sunt inchise. Dupa ce s-a efectuat primul pas se ruleaza algoritmul Dijkstra pentru topologia existenta care tine cont de metricile ingineriei traficului sau ale protocolului. Dupa rularea algoritmului se selecteaza cea mai buna cale cu banda minima cea mai mare. Astfel rezulta o cale constransa care va produce o ruta explicita numita Calea cea mai Scurta Constransa.
Mesajele RSVP-TE
Mesajul CALE RSVP-TE
Ruterul din capatul de intrare va transmite mesaje de tip RSVP PATH. Acest mesaj va fi transmis catre ruterele din calea constransa aleasa si fiecare ruter in parte vor analiza obiectele continute in mesaj. Mesajul CALE contine urmatoarele obiecte:
Obiectul de Cerere de Eticheta care contine campurile:
Mesajul CALE va parcurge ruterele listate in Obiectul Ruta Explicita. La fiecare echipament, Obiectul Retinere Ruta este actualizat cu adresa IP a echipamentului vizitat. Atributul sesiune care contine prioritizarea si detinerea caii este folositor atunci cand latimea de banda ceruta nu este disponimila la prioritatea specificata . In acest caz , daca latimea de banda este disponibila dar este folosita de sesiuni cu prioritate mai mica, acestea pot elibera resursele atunci cand este necesar.
Mesajul RESV(de rezervare) RSVP-TE
Mesajul RESVeste trimis inapoi de catre routerul de iesire dupa primirea mesajului CALE. Capatul de iesire trebuie sa initieze procesul de distribuire a etichetelor. Urmatoarele obiecte sunt disponibile:
La fiecare ruter, un mesaj RSVP identifica si atribuie valoarea etichetei interfetei de intrare. Fiecare echipament trebuie sa aloce o eticheta locala( care va fi apoi distribuita prin Obiectul Eticheta) pentru urmatorul echipament in aval.
Doua plane de control sunt folosite pentru a crea calea. Controlul Admiterii Trunchiului si Controlul Admiterii Conexiunii.
Controlul Admiterii Trunchiului determina daca resursele sunt disponibile de-a lungulunei cai LSP. Este de asemenea responsabil pentru intreruperea cailor existente cu prioritati mai mici, atunci cand ele nu sunt necesare.
Controlul Admiterii Conexiunii este folosit in mesajul CALE astfel: daca latimea de banda este disponibila, aceasta latime de banda este mutata intr-o coada de asteptare pana cand mesajul RESV este primit. Altfel este generat un mesaj de eroare.
GMPLS
Generalized MultiProtocol Label Switching este o extensie a MPLS care a fost dezvoltata pentru a aplica tehnicile de schimbare de eticheta in retele de tip Time Division Multiplexing (TDM) si retele cu rutare in funcie de lungimea de unda.
O retea de tip Time Division Multiplexing (TDM) este o retea formata din conexiuni SDH (Sinchronous Digital Hierarchy) interconectate de digital connect systems (DCS). Un DCS preia semnalul optic SDH si il transforma intr-un semnal electric din care preia informatia tributara pe care o foloseste la construirea unui pachet de iesire. Pachetele de iesire sunt apoi transmise pe alte linii optice. Este posibila agregarea liniilor SDH intr-un alt nivel SDH superior. O conexiune poate fi creata prin reteaua SDH alocand unul sau mai multe sloturi din rama SDH. GMPLS poate fi folosit pentru a configura o conexiune DCS-urile SDH.
GMPLS poate fi folosit si pentru crearea unei cai de lumina intr-o retea cu rutare in funcie de lungimea de unda. In plus mai poate fi folosit de un switch optic pentru a interschimba tot semnalul optic de la o fibra de intrare la o fibra de iesire.
In GMPLS, ruterele IP, switchurile ATM, switchurile Frame Reley, switchurile Ethernet, DCS-urile si switchurile optice sunt recunoscute ca o retea IP simpla din punct de vedere al planululi de control.
Pentru arhitectura GMPLS sunt necesare protocoale de semnalizare. RSVP-TE si CR-LDP au fost extinse pentru a suporta protocolul.
Etichetele generalizate
MPLS pleaca de la premisa ca o eticheta poate fi generalizata astfel incat sa poata reprezenta orice lucru care este suficient pentru a identifica un curs al traficului. De exemplu, intr-o fibra optica a carei latime de banda este impartita in lungimi de unda, oi lungime de unda poate fi alocata pentru un curs de trafic. Ruterele de la fiecare capat al fibrei trebuie sa cada de acord asupra frecventei folosite. Spre deosebire de etichetele ne-generalizate, datele dintr-un curs cerut nu trebuiesc sa fe toate marcate cu valoarea etichetei pentru ca valoare etichetelor este implicita deoarece datele sunt transportate pe o lungime de unda prestabilita. Unele reprezentari ale valorii etichetei sunt necesare la protocolul de semnalizare pentru ca prin mesajele transmise intre rutere sa se ajunga la o valoare comuna a etichetei ce va fi folosita.
MPLS Generalizat extinde reprezentarea etichetei de la un numar de 32 de biti la o valoare arbitrara si introduce Obiectul Eticheta Generalizata in RSVP si TLV-ul Eticheta Generalizata in CR-LDP pentru a transporta eticheta si informatii referitoare la eticheta.
Etichetele in MPLS Generalizat pot reprezenta urmatoarele lucruri:
O legatura intre echipamente poate consta dintr-o multitudine de fibre optice. Echipamentele pot alege o fibra pentru un curs de date si astfel este necesar stabilirea fibrei. Interpretarea numarului fibra/port este o alegere locala pentru fiecare LSR in parte. Atunci cand doua LSR-uri au sisteme de numerotare diferite, Link Management Protocol furnizeaza un mecanism de schimbare a sistemelor diferite.
Atunci cand banda unei fibre optice este impartita in mai multe lungimi de unda, prin WDM, un LSR optic poate aloca o singura lungime de unda unui flux de date. Astfel valoarea etichetei este labda-ul selectat.
Daca mai multe lungimi de unda consecutive sunt grupate intr-o lungime de bada astfel incat toate sunt interschimbate in acelasi fel, eticheta este identificatorul de banda si o pereche de numere care sa indice lungimea de banda cea mai mica si pe cea mai mare.
Acolo unde latimea de banda a unuei fibre optice este divizata in mai multe sloturi prin Time Division Multiplexing, un switch optic poate identifica un flux de date alocand unul sau mai multe sloturi fluxului respectiv.
Alocarea Latimii de Banda
Pentru toate tipurile de etichete prezentate mai sus, valoarea etichetei trebuie sa descrie latimea de banda disponibila pentru corespunzatorul flux de trafic. De exemplu, daca o eticheta descrie un slot temporal SDH STM-1, atunci latimea de banda este in mod cert cea alocata unui slot temporal STM-1. In acelasi mod se deduce banda alocata si pentru o anumita lungime de unda, lungime de banda sau fibre optice.
Cererile de Etichete Generalizate
Formula de baza a protocolului de schimbare a etichetei intre doua rutere nu se schimba pentru retele optice.
GMPLS generalizeaza mesajul de cerere din doua motive: pentru a distinge mesajul generalizat de cel negeneralizat si pentru a putea transporta parametrii aditionali care descriu mai multe detalii. In RSVP este introdus mesajul Cerere Eticheta Generalizat.
Unele informatii de care LSR-ul din aval are nevoie pentru a aloca o eticheta corespunzatoare sunt considerate implicite. De exemplu, daca ambele echipamente cunosc faptul ca sunt conectata la o retea optica atunci ambele se vor astepta la etichete generalizate si vor distribui unul altuia etichete generalizate.
Cu toate acestea, din moment ce o legatura optica poate consta intr-o multime de fibre, si switchurile pot suporta unul sau mai multe tipuri de multiplexari pe acele fibre, este necesar pentru un LSR din amonte sa specifice tipul de condare a caii LSP pe care doreste sa o stabileasca pentru fluxul de trafic. Tipul de codare determina daca eticheta va insemna un slot temporal sau o lungime de unda.
Cererea de eticheta generalizata specificata de GMPLS transporta un camp in care este descris tipul de codare a caii LSP. Valorile suportate de acest camp, care sunt relevante pentru retelele optice sunt:
Deoarece unele rutere pot anunta prin intermediul protocolului intern de rutare capabilitatea de a suporta mai multe tipuri de interschimbare, campul Cerere Eticheta Generalizata contine un camp care indica modul de interschimbare care poate fi aplicat pentru o anumita cale LSP. Acest lucru permite, de exemplu, ca un switch sa poata alege interschimbare unei fibre optice sau a unei lungimi de unda. Alegerea metodei de interschimare pentru o cale anume este facuta odata crearea caii. Acest lucru creste flexibilitatea utilizarii resurselor din retea.
Pentru etichete atribuite fibrelor sau lungimilor de unda, nu este necesara decat stabilirea acestora.
Atunci cand este ceruta o eticheta SDH, poate fi necesar ca latimea de banda pentru o cale LSP sa fie impartita in mai multe sloturi temporale. Deci atunci cand tipul de codare este SDH, cererea de eticheta generealizata transporta campuri care specifica numarul de sloturi temporale care trebuie rezervate pentru a raspunde cererii si cum pot fi concatenate acele sloturi si daca este necesar ca ele sa fie alocate continuu.
Constrangerea alegerii etichetei
Asa cum a fost descris mai sus, alegerea etichetei pentru legatura de date este in mod normal dictata de nodul din aval al legaturii. In MPLS non-generalizat, unde etichetele sunt doar niste numere alese arbitrar, acest mod de distribuire este suficient. In MPLS Generalizat, unde etichetele sunt in legatura directa cu resursele retelei acest lucru poate genera conflicte atunci cand se creaza calea LSP.
De exemplu, un switch optic bazat pe micro-oglinzi poate reusi sa canalizeze o lungime de unda de pe un port de intrare catre unul de iesire dar nu poate modifica lungimea de unda.
In figura de mai jos se pot observa doua cai LSP intr-o retea optica unde switchurile optice(Optical Exchange) sunt incapabile sa converteasca lungimea de unda. Calea LSP albastra se intinde de la switch-ul optic A la F trecand prin echipamentele B,D si E. Calea rosie strabate reteaua plecand de la echipamentul C, trecand prin D si E si terminandu-se in G. Culorile reprezinta lungimile de unda folosite pentru cele doua cai. Pe legatura dintre D si E nu apare nici un conflict din moment ce cele doua cai LSP au lungimi de unda diferite.
Cu toate acestea atunci cand echipamentul C doreste sa creeze o alta cale LSP pana la G trecand prin D si prin E acesta trebuie sa aleaga o lungime de unda noua. Daca alegerea este lasata in seama echipamentului G (aceasta fiind calea normala pentru MPLS), G poate alege culoarea albastra. Cum aceasta este deja folosita intre D si E, alegerea echipamentului G aceasta optiune nu este valabila. Daca alegerea ar fi facuta de C o problema similara va aparea.
Este deci nevoie de a ingadui switchurilor de-a lugul caii sa poata constrange sau influenta alegerea etichetelor pentru a asigura functionarea normala a retelei.
Setul de etichete
MPLS Generalizat introduce conceptul Setul de Etichete. Un echipament LSR din amonte include Setul de Etichete in cererea facuta catre echipamentul din aval pentru a interzice acestuia alegerea unei etichete necorespunzatoare. Echipamentul din aval trebuie sa selecteze o eticheta din Setul de Etichete sau calea nu mai poate fi creata.
Acest lucru este util in reteaua optica atunci cand de exemplu:
Setul de etichete este construit prin includerea sau exluderea unui numar arbitrar de liste de etichete. Daca nici o eticheta nu este explicit inclusa, setul consta in toate etichetele valide care nu sunt explicit excluse. Daca nici un set de etichete nu este prezent, LSR-ul din aval nu este constrans in nici un fel la alocarea etichetelor.
In timp de setul de etichete este propagat in mesajul CALE, fiecare LSR poate genera un nou set de etichete, bazat pe capabilitatile sale fizice si pe setul de etichete primit. De exemplu, un echipament care este incapabil de conversie a lungimii de unda, genereaza un set de etichete inaintand setul de etichete primit minus etichetele pe care nu le poate genera sau primi. In contrast cu acesta un echipament care este capabil de a converti toate lungimile de unda dintr-un set de etichete si poate trimite mesajul CALE fara set de etichete pentru a indica faptul ca poate accepta orice eticheta pe legatura din aval.
De exemplu in figura de mai sus, daca LSR-ul C poate genera doar lungimi de unda dintr-o plaja P, acesta comunica setul de etichete "orice eticheta din plaja P cu exceptia culorii rosu". Echipamentul D modifica acest mesaj si comunica "orice eticeta din plaja P cu exceptia culorii rosu sau albastru". LSR-ul E inainteaza acest mesaj neschimbat, si astfel LSR-ul G poate selecta o culoare care este acceptabila pentru toate echipamentele din calea LSP daca exista.
Controlul explicit al etichetelor
MPLS generalizat introduce controlul explicit al etichetelor. Acest lucru imbunatateste conceptul de ruta explicita permitand LSR-ului de intrare sa specifice eticheta/etichetele care trebuie folosita pe una sau toate legaturile explicite pentru calea de inaintare sau de intoarcere.
Aces lucru este folositor, de exemplu, atunci cand LSR-ul de intrare insista ca lungimea de unda folosita sa fie aceeasi pe toata lungimea caii LSP. Acest lucru este dorit pentru a evita distorsionarea etichetei.
Poate fi folositor si in Ingineria Traficului unde algoritmul de calculare a caii are cunostinte despre etichetele folosite in retea si despre capabilitatile de interschimbare ale echipamentelor. In acest caz, calea poate fi calculata in functie de etichete specificate pentru folosire la fiecare echipament in parte.
Etichetele explicite sunt specificate de LSR-ul de intrare ca parte a caii explicite. La fiecare LSR de-a lungul caii, fiecare eticheta explicita care este specificata in ruta explicita pentru urmatorul echipament este scoasa si convertita intr-un obiect set de etichete care contine o singura eticheta pentru urmatorul echipament. LSR-ul care primeste acest set de etichete va folosi eticheta specificata pentru acel LSR vecin.
Controlul Etichetei la Iesire
Atunci cand un administrator de retea initiaza crearea unei cai LSP, acesta este liber sa specifice mai mult sau mai putin strict calea pe care o vor urma datele, asignand etichetele care trebuiesc folosite pentru fiecare link.
Uneori administratorul de retea poate avea informatii aditionale despre rutarea traficului de date si cum iese acesta prin capatul terminal al caii LSP. De exemplu, se poate cunoaste faptul ca doar traficul de voce va fi injectat in aceasta cale,si ca, la iesirea din LSP, tot traficul trebuie rutat prin un echipament de telefonie cu o adresa binecunoscuta. In aceste cazuri, este utila evitarea examinarii pachetelor de date si calcularii rutelor pe care echipamentul de iesire ar fi facut-o semnalizand adresa echipamentului de voce de-a lungul caii LSP.
Acest lucru se poate realiza cu ajutorul controlului de etichete la iesire. Administratorul doar adauga un obiect "eticheta" aditional pentru ruta explicita dupa obiectul "ultim echipament". Eticheta codata nu trebuie sa se conformeze cu alt format standard MPLS, dar trebuie sa fie inteleasa de ultimul LSR din cale. Atunci cand LSR-ul de iesire primeste mesajul de creare a caii, acesta observa obiectul eticheta aditional la sfarsitul rutei explicite si interpreteaza mesajul intr-un mod folositor.
Semanalizarea In Afara Benzii
Protocoalele de semnalizare folosite in MPLS nongeneralizat presupun ca traficul de date intr-o cale LSP va urma aceeasi cale ca si mesajele de semnalizare. In retele optice, granularitatea latimii de banda a canalelor pe legaturile optice este ridicata, si ar fi o risipa de resurse folosirea unei parti a latimii de banda(slot temporal sau lungime de unda) ca un canal de semanlizare. Deci sunt motive puternice pentru ca semnalizarea sa urmeze o cale "in afara benzii", printr-un canal de control care este separat fizic de canalul de date. Acest lucru simplifica tehnologia pe care un echipament optic trebuie sa o implementeze in planul de date, daca planul de date nu trebuie sa inteleaga protocoalele pe care sunt bazate mesajele de semnalizare.
Unele solutii folosesc o legatura cu latime de banda mica (ex Ethernet) care circula paralel cu canalul de date. Metoda alternativa prin care putem evita provizionarea unui canal de semnalizare este rutarea printr-o retea IP existenta.
Semnalizarea in afara benzii intampina trei probleme importante in aplicarea tehnologiei MPLS Generalizat in retelele optice.
Extinderea capacitatii de rutare
Cand un LSR incearca pe caile de date si de semnalizare sa creeze calea LSP, acesta trebuie sa calculeze doua rute de iesire catre urmatorul echipament, unul pe calea de date si unul pe calea de semnalizare. Calea de date trebuie evaluata mai intai si calea de semnalizare este stabilita apoi, daca este o legatura pe calea de date.
Topologiile pentru reteua de date si de voce sunt in mod evident diferinte, astfel decizia de rutare este complicata. Este inca in lucru imbunatatiea protocolului OSPF care va permite distribuirea datelor despre topologie pentru ambele tipuri de retele, de date sau semnalizare. Dupa ce informatia a fost distribuita, fiecare LSR are informatia necesara pentru a calcula rutele necesare pentru semanalizarea in afara benzii.
Incapsularea mesajululi de Semnalizare
Atunci cand se foloseste protocolul RSVP pentru semanalizare, fiecare mesaj de semnalizare este trimis catre LSR-ul de iesire, niciodata nu este trimis catre urmatorul LSR in cale. Ruterele din cale intercepteaza aceste mesaje, observand ca fanionul "rutare" este setat. Cu semnalizarea in afara benzii, sunt doua probleme care apar cu aceasta abordare.
Sunt doua abordari posibile pentru a asigura ca mesajele de semnalizare ajung la urmatorul LSR in calea de date si ca nodurile de tranzit in calea de semnalizare nu interfereaza.
Adresarea catre urmatorul LSR in cale ne asigura ca pachetul va ajunge la LSR-ul corect, dar este necesar ca LSR-ul care primeste pachetul sa relaxeze regula in care este precizat ca adresantul este LSR-ul de iesire.
Trimiterea pachetului fara fanionul setat inseamna ca pachetul va fi inaintat fara a fi interceptat de alte rutere cu exceptia celui caruia ii este adresat.
Cu toate acestea, este posbil ca unele implementari ale stivei IP sa nu interpreteze fanionul de rutare in mod corect. Deci, atunci cand pachetul trece printr-un nor IP arbitrar nu este o solutie sigura.
Cea de-a doua abordare este mai robusta. Este necesar ca LSR-ul care primeste pachetul sa recunoasca faptul ca este destinatar, da decapsuleze pachetul si sa trateze pachetul din interior in mod normal, trecandu-l prin stiva de semnalizare.
Identificarea Interfetei de Date
Un LSR se poate astepta sa primeasca mesaje de semnalizare in afara benzii pe o intefata diferita decat cea de date. Acest lucru ridica doua probleme.
Prima: atunci cand primeste mesajul CALE, cum cunoaste acest LSR care interfata de date este semnalizata? Sunt mai multe optiuni:
A doua: LSR-ul poate relaxa procesarea rutei explicite, astfel incat sa fie acteptabil pentru echipamentul de intrare sa se refere la calea de date si nu cea de semanalizare.
Procesul de Standardizare
Ultimele rapoarte despre GMPLS adreseaza unele din problemele de semnalizare in afara benzii
Identificarea interfetei de date. Este implementata de ID TLV de Interfata, care poate transporta oricare din urmatoarele combinatii de adrese:
In RSVP-TE generalizat, acest TLV este o parte a obiectului IF_ID RSVP_HOP, care inlocuieste si extinde obiectul RSVP_HOP.
Legatura planului de control si defectarea unui nod.
RSVP-TE generalizat foloseste mecanismul de refresh pentru a detecta defectarile din planul de control sau defectarile nodurilor. De asemenea defineste o cale de a negocia perioada maxima de recuperare a planului de control si refoloseste obiectul Eticheta Sugerata, pentru a permite unui nod din amonte sa comunice nodului din aval recuperat etichetele pe care le-a alocat inaintea defectarii.
Singura problema ramasa este modul de distribuire a mesajelod de semnalizare RSVP-TE catre urmatorul LSR. Inca nu este nimic standardizat dar se favorizeaza abordarea care necesita dubla incapsulare ori in IP ori in Generic Route Encapsulation descris in RFC 2784.
Reducerea Latentei la Semnalizare
Caracteristicile de performanta a retelelor optice sun deseori diferite de cele ale retelelor electronice pentru care MPLS a fost conceput.
Urmatoarea parte descrie cum MPLS Generalizat a evoluat pentru a intampina problemele de performanta.
Latenta de Programare a Switchurilor Optice
Procedura normala pentru MPLS este ca switchul sa fie programat cand un raspuns de semnalizare este primit. Modul este urmatorul: cererea de semnalizare este procesata de fiecare echipament din cale de la intrare pana la iesire. Raspunsul de semnalizare apoi calatoreste de la iesire la intrare, fiecare switch din calea LSP il analizeaza si apoi se programeaza. Cand raspunsul ajunge inapoi la intrare, toata calea LSP este programata si datele pot circula.
Alocarea etichetelor se face in acest mod pentru a oferi un grad mai mare de siguranta impotriva conflictelor ce pot aparea. Deci la fiecare LSR din amonte, nu este cunoscuta eticheta pana nu este primit un raspuns.
Switchurile optice pot fi programate relativ lent. Cu toate ca viteza selectarii si ajstarii componentelor de interschimbare poate fi destul de mare, timpul necesar componentelor sa se stabilizeze poate fi mult mai mare, de ordinul milisecundelor. De exemplu, o micro-oglinda poate fi programata rapid, dar oglindei ii sunt necesare zeci de microsecunde pentru a se stabiliza si a se opri din vibrare dupa ce aceasta a fost ajustata. Un LSR nu poate transmite in siguranta raspusuri de semnalizare vecinului din amonte cat timp oglinda vibreaza in continuare, astfel, LSR-ul de intrare poate trimite date prematur si datele ar fi pierdute.
In consecinta, timpul necesar pentru a stabili o cale LSP care traverseaza un numar N de LSR-uri optice este: 2*(timpul de semnalizare de la capat la capat N*(timpul de programare si stabilizare a switchului).
Combinatia intre switchuri optice si MPLS conventional rezulta in latente foarte mari in crearea caii LSP.
Eticheta sugerata
Pentru a reduce latenta la crearea caii LSP, GMPLS introduce conceptul de Eticheta Sugerata.
Fiecare LSR selecteaza o eticheta pe care o considera potrivita pentru folosire pe o legatura intre el si vecinul din aval. Routerul semnalizeaza aceasta eticheta pe calea de semnalizare si incepe imediat programarea presupunand ca vecinul va fi de acord cu aceasta eticheta.
Cand raspunsul de semnalizare este primit, acesta transporta o eticheta. Daca aceasta eticheta confirma alegerea suferata in cerere, nu sunt necesari pasi urmatori pentru ca switchul este deja programat. Daca componentele s-au stabilizat, raspunsul de semanalizare poate fi inaintat imediat in amonte. Daca eticheta este diferita de cea sugerata in cerere, echipamentul trebuie sa fie reprogramat, dar nu este pierdut foarte mult timp comparativ cu primul mod in care nu exista nici o sugestie.
In exemplu, o cerere de semnalizare este primita de un LSR. Este folosit protocolul de semnalizare RSVP-TE.
Mesajul CALE transporta un obiect Eticheta Sugerata care indica eticheta λa pe care LSR-ul din amonte o prefera pentru folosire pe segmentul caii LSP care leaga cele doua LSR-uri. LSR-ul care primeste mesajul il proceseaza in modul urmator:
1. Selecteaza o eticheta care trebuie folosita pentru legatura din amonte
(Lambda D). Daca este posibil se impunde λd= λa
2. Selecteaza o eticheta preferata pentru legatura din aval (λb). Depinzand de proprietatile switchului, aceasta poate avea aceeasi valoare ca cea selectata pentru interfata din amonte λd= λb, daca un switch nu este capabil de modificarea lungimii de unda.
3. Trimite comanda catre componentele switchului pentru a incepe programarea switchului.
4. Trimite un mesaj CALE in aval continant eticheta pe care doreste sa o foloseasca pe segmentul din aval (λb)
5. Dupa un anumit timp, primeste un mesaj Resv de la ruterul din aval. Acest mesaj indica eticheta care v-a fi folosita pe segmentrul din aval(λc).
6. Daca eticheta folosita este diferita de cea sugerata(λc= λb) switchul trebuie sa:
Aleaga o alta valoare posibila pentru eticheda din amonte λd(acest lucru este necesar daca switchul nu este capabil de conversie a lungimii de unda, deci trebuie sa aleaga o eticheta asemenea cu cea furnizata din aval (λd= λc ≠ λa))
Trimita o comanda catre componentele switchului pentru a programa interschimbarea intre λd si λc
Sa astepte ca switch-ul sa fie programat complet si stabil
Sa trimita o comanda catre componentele swichului pentru a deprograma interschimbarea speculativa intre λd si λc ca eveniment pe fundal
Daca eticheta este cea sugerata (λc=λd), atunci nu este necesara alta programare, dar echipamentul trebuie sa se asigure ca programarea inceputa anterior s-a finalizat corespunzator.
In final, LSR-ul trimite un mesaj Resv in amonte indicand eticheta pe care doreste sa o foloseasca pe legatura(λd).
Daca totul a functionat corespunzator si conversia lungimii de unda nu este posibila, eticheta sugerata de catre mesajul original este folosita in toate mesajele, (λa= λb= λc= λd). Daca sunt probleme( de exemplu, o eticheta nu poate fi acceptata), calea LSP este desfiintata folosind protocolul de semnalizare si switchul este reprogramat.
Surplusul de latime banda necesar pentru soft
Retelele optice MPLS au proprietatea de a fi foarte stabile, o cale LSP dupa creare are o durata de functionare lunga si ramane neschimbata. Aceasta stabilitate ne pune in atentie surplusul de banda necesara pentru protocolul RSVP, care necesita refreshuri la intervale regulate intre fiecare nod al retelei pentru a mentine o cale LSP. Surplusul folosit pentru rularea acestui protocol este mai evident in retelele stabile, pentru ca beneficiul obtinut din curatarea automata a unei cai expirate este necesar mai rar. In urmatorul paragraf sunt evidentiate niste abordari pentru a reduce surplusul de banda necesar. Toate abordarile sunt folosite in general in RSVP-TE, dar au aplicabilitate in retelele optice datorita stabilitatii lor.
Identificatorul de Mesaj
Natura de protocol soft a RSVP permite detectarea pierderii legaturii prin mesaje care trebuiesc procesate prin asteptarea urmatorului interval de refresh, sau in cazul mesajului de desfiintare, asteptarea starii de functionare sa expire. O consecinta a acestui lucru este dificultatea alegerii intre un interval de refresh scurt, pentru a avea o retea mai receptiva si cresterea surplusului de banda necesar pentru mesajele RSVP mai dese.
Identificatorul de mesaj este o alternativa la imbunatatirea robustetii retelei care nu creste semnificativ surplusului de banda folosit de RSVP. Fiecare mesaj include un identificator de mesaj, ales de catre emitator, care identifica in mod unic mesajul. Identificarorele de mesaj receptionate sunt confirmate de receptor, prin alipirea lor la alte mesaje RSVP sau in mesaje de tip ACK de dimensiuni mici. Emitatorul poate tine un temprorizator de reincercare pentru mesajele trimise, retransmitand mesajele pana cand este primita confirmarea. Din moment ce pierderea unui masaj este rar, si confirmarea identificatoarelor de mesaj este rapida, retransmiterea de mesaje este minima, chiar si cu un interva de retransmitere mic. Acest mecanism ofera beneficiul sigurantei imbunatatite in transmiterea mesajelor, fara a creste in mod semnificativ surplusul necesar pentru rularea RSVP.
Urmatoarea schema ilustreaza utilizarea identificatorilor de mesaj si a confirmarilor.
Reducerea procesarii mesajelor refresh
O consecinta importanta a identificatorului de mesaj este aceea ca un identificator poate fi folosit pentru manevrarea continutului mesajului.
Daca un mesaj CALE sau Resv este trimis pentru a transmite un
refresh catre un nod vecin, atunci acelasi identificator este refolosit
Atunci cand un LSR primeste un mesaj CALE sau Resv cu acelasi ID de mesaj ca cel de mai devreme, acesta indica fatul ca mesajul este doar unul de refresh, si LSR-ul poate evita procesarea continutului mesajului.
Pe masura ce sarcina mesajului LSR creste, este importanta evitarea procesarii intregului mesaj de refresh.
Identificatorul de mesaj este un numar de 32 de biti. Este alocat de catre emitator in ordine crescatoare de la un punc de start(exceptie facand mesajele de refresh, asa cum a fost explicat mai sus); acest lucru permite receptorului sa detecteze si sa ignore mesaje care nu au venit in ordine. Acest mecanism ajuta in cazuri in care nodurile se defecteaza, pierzandu-se numerele de secventa, incluzand o valoare aproximativa a identificatorului. Daca aceasta valoare se schimba, nodurile interpreteaza identificatoarele de mesaj in mod corespunzator.
Reducerea mesajelor de refresh
Indetificatorul de mesaj furnizeaza o modalitate simpla de a reduce procesarea sarcinii de catre receptor, identificand mesajele de refresh, dar acest lucru impune emitatorului sa genereze si sa trimista un mesaj RSVP complet. Mesajele refresh sumare (Srefresh) construite pe modelul identificatorelor de mesaj furnizeaza o modalitate de a reduce incarcarea emitatorului si a retelei. Emitatorul grupeaza mai multe ID-uri de mesaje trimise pentru starea care necesita refresh. Identificatoarele sunt trimise ca o lista intr-un mesaj dedicat Srefresh.
La primirea mesajului Srefresh, receptorul poate sa compare ID-urile cu starea instalata, efectuand actiunea normala de mentinere pentru fiecare stare care corespunde mesajului.
Identificatoarele de mesaj care corespund nu sunt confirmate.
Identificatoarele de mesaj care nu corespund sunt trimise inapoi
emitatorului ca neconfirmate intr-un obiect NACK.
Cand emitatorul de mesaj Srefresh primeste un obiect NACK, acesta il
compara cu starea locala care a generat ID-ul de mesaj, si trimite imediat un mesaj refresh intreg.
Srefresh furnizeaza o reducere importanta a surplusului resurse necesar pentru rularea protocolului RSVP in retelele stabile, reducand procesarea atat la emitator cat si la receptor, si reducand latimea de banda necesara pentru a transmite mesaje refresh periodice. Inlocuind mesaje CALE si Resv multiple cu unsimplu mesaj Srefresh ,economisirea latimii de banda poate fi mare.
Cu toate ca economisirea latimii de banda pe canalul de control nu este foarte importanta, acesta fiind de multe ori supra-provizionat, reducerea procesarii poate fi semnificativa in special in retelele mari cu multe cai LSP.
Srefresh furnizeaza beneficii semnificante pentru mesajele de refresh periodice, dar nu poate fi aplicat la mesaje declansate, unde este necesar tot continutul mesajului. Gruparea de mesaje aduce inbunatatiri in aceste situatii, colectand continutul mai multor mesaje RSVP in spatele unui preambul IP. Acest lucru economiseste latime de banda cu pretul cresterii burstului in transmitere latenta din cauza timpului necesar pentru a grupa mesajele. Srefresh poate furniza beneficii in scenarii de nefunctionare a unui echipament, unde numere mari de mesaje de desfiintare sau creare sunt schimbate intre vecini.
Manevrarea eficienta a erorilor
Restabilirea functionarii retelei dupa o defectare a resurselor este un aspect tot mai important al construirii retelei. In mod ideal, utilizatorul trebuie sa fie protejat de o eventuala problema in retea. Ei nu ar trebui sa intampine probleme in traficul lor de date.
MPLS ofera multe optiuni pentru protejarea cailor LSP de problemele retelelor. In retelele optice, aceste proceduri utilizeaza niste extensii MPLS specifice descrise mai jos.
Mesajele de notificare
Interschimbarea de protejare este o metoda de restabilire dupa o defectare in retea prin dirijarea datelor de pe o cale LSP principala pe o cale de siguranta( de obicei presemnalizata) care foloseste o cale fizica diferita.
In figura, liniile albastre si roz reprezinta cai LSP primare prin retea. Cand legatura din mijlocul retelei cade, datele sun redirectionate catre LSP-ul de siguranta(colorat in verde).
Pentru ca schema sa functioneze, un nod din amonte(punctul de reparare) trebuie sa perceapa eroarea. Punctul de reparare este de obicei initiatorul in MPLS non-generalizat, metoda de notificare este mesajul PathErr care parcurge calea LSP in amonte. Parcurgerea mesajului este eficienta dar inceata deoarece:
Calea fizica selectata pentru LSP nu trebuie sa fie cea mai scurta cale
intre punctul de detectare si initiator(din cauza rutarii Trafiic Engineering), dar mesajul PathErr trebuie sa parcurga aceasta cale intarziind instiintarea erorii.
Un mesaj de tip PathErr este interceptat si procesat de fiecare LSR in
parte ceea ce mareste timpul necesar transmiterii problemei initiatoruli.
Pot fi multe cai LSP afectate, pentru fiecare in parte este necesar un
mesaj tip PathErr in acelasi timp;acest lucru poate inunda reteaua cu pachete si poate consuma resurse importante ale echipamentelor.
Este posibil ca un nod din amonte care primeste mesajul PathErr poate sa decida in mod eronat, sa isi asume responsabilitatea pentru eroare, sa incerce sa initieze o reparare locala si sa nu inainteze mesajul PathErr in amonte pana cand observa ca a gresit. Astfel se poate introduce o intarziere extrem de mare in propagarea erorii catre puncul de reparare.
MPLS Generalizat introduce nu nou mesaj pentru a inbunatatii procesul de avertizare. Mesajul Avertizare este trimis direct de la un punct de defectare catre un punct de reparare. In figura de mai sus, cand calea LSP albastra, un mesaj Avertizare este rimis direct catre initiator. Acest mesaj este trimis direct catre inititiator si nu are fanionul de rutare setat pentru a nu fi interceptat de catre nodurile de tranzit care sunt capabile de a intelege MPLS; poate folosi incapsularea dubla in IP. Foloseste rutarea IP normala pentru a alege ruta cea mai buna catre initiator.
Daca calea LSP este bidirectionala, un mesaj Avertizare este trimis de asemenea catre punctul terminal pentru a permite acestuia sa transfere datele pe calea de siguranta. Acest mesaj este trimis de catre nodul care detecteaza eroarea pe partea terminala a legaturii nefunctionale.
Nu este nici un motiv pentru ca punctele de reparare sa fie initiatorul si punctul terminal. In figura, calea LSP roz este protejata de o cale de siguranta (verde). Un LSR care doreste sa cunoasca o problema a caii LSP adauga un obiect care contine adresa lui in mesajul CALE sau Resv in timp ce acesta trece prin retea. Acest obiect, cere in mod expres folosirea mesajelor de Avertizare si identifica receptorul mesajului. Mesajul CALE identifica receptorul mesajului Avertizare de partea initiatorului si mesajul Resv identifica receptorul mesajului Avertizare de partea punctului terminal.
In timp ce mesajul CALE sau Resv parcurge reteaua, echipamentele pot schimba receptorul de mesaj Avertizare. Astfel pot fi definite mai multe puncte de reparare definite pentru o cale LSP.
Cea mai eficienta utilizare a mesajului Avertizare este de a-l trimite catre un echipament din retea care poate recalcula o cale fizica si care sa comunice aceasta cale catre initiator.
Raportarea mai multor cai LSP afectate
Asa cum a fost descris mai sus, unul dintre principalele motive de ingrijjorare cu folosirea mesajelor PathErr pentru a avertiza problemele unei cai LSP este faptul ca defectarea unei singure legaturi fizice afecteaza mai multe cai LSP si necesita trimiterea mai multor mesaje PathErr pentru fiecare LSP. Acest lucru poate produce un varf de trafic pe canalul de control si poate cauza insuficiente de resurse in echipamentele care proceseaza mesajele.
Din acest motiv, mesajel Avertizare este definit pentru a raporta mai multe cai LSP in acelasi timp. Singurele constrangeri sunt urmatoarele:
Toate caile LSP afectate dintr-un mesaj Avertizare trebuie sa fie anuntate cu acelesi cod.
Toate caile LSP dintr-un mesaj Avertizare trebuie sa aiba acelasi destinatar.
Inlaturarea Starii cu Mesajul PathErr
In RSVP este specificat ca mesajele de eroare sa fie trimise catre nodurile din amonte folosind mesajul PathErr si catre nodurile din aval utilizand mesajul ResvErr. Cand ruterul de intrare primeste mesajul PathErr acesta poate:
Acest lucru este ineficient daca o defectiune serioasa se produce din moment ce doua linii de mesaje sun necesare(PathErr si PathTear)
MPLS generalizat introduce o optiune in mesajul PathErr pentru a putea raporta starea care a fost inlaturata la nodul emitator. Fanionul indica faptul ca LSR-ul care a trimis mesajul PathErr a deprogramat switchul pentru calea LSP.
Fanionul de Inlaturare a Starii este aplicat din echipament in echipament. Cand un LSR primeste un mesaj PathErr cu fanionul setat, acesta trebuie sa trimita un mesaj PathErr in amonte. Aceta poate alege sa seteze fanionul in mesajul PathErr pe care il trimite. Daca nu seteaza fanionul in mesajul PathErr trimis, acesta poate alege sa inregistreze faptul ca a primit fanionul de la un LSR din aval.
In figura de mai sus este ilustrat drumul mesajelor produse de o cale LSP intrerupta. In exemplu, nodul care detecteaza eroarea trimite un mesaj Avertizare catre echipamentrul de intrare si trimite un mesaj PathErr in amonte indicand faptul ca starea a fost inlaturata. Mesajul PathErr se propaga in amonte, iar cele doua rutere din cale nu seteaza fanionul de Stare Inlaturata. In continuare in amonte, un LSR decide sa reseteze fanionul si de asemenea trimite mesajul PathTear in aval. La urmatorul nod, mesajul PathErr calatorind in amonte intalneste un mesaj PathTear care calatoreste in aval si nu este necesara procesarea aditionala.
In figura de jos este aratat cum aceasta proprietate poate fi folositoare la curatarea retelei atunci cand aceasta este fragmentata. In amonte fata de intreruperea legaturii LSP(partea stang a diagramei), procesarea este ca in figura de sus. Combinatia intre mesaje PathErr(cu si fara fanionul Stare Inlaturata setat) si PathTear(declansat de Avertizare sau de PathErr) duce la inlaturarea starii.
In aval, RSVP poate furniza inlaturarea starii prin expirarea timpilor de refresh. Echipamentul care detecteaza eroarea poate trimite mesaje Avertizare sau ResvErr si echipametul de iesire poate trimite mesaje ResvTear, dar aceste scimburi nu inlatura complet starea sau rezervarile in nodurile intermediare. Mai mult, mesajul PathTear trimis de catre ruterul de intrare nu va ajunge niciodata in partea din aval a defectiunii caii daca aceasta defectiune afecteaza atat calea de date cat si calea de control.
Aceasta situatie poate fi remediata folosind fanionul Stare Inlaturata in mesajul PathErr. Cand primeste mesajul Avertizare, LSR-ul de iesire poate inlatura starea, apoi poate deprograma switchul. Apoi trimite mesajl PathErr in amonte indicand inlaturarea starii si calea LSP este curatata.
Bidirectionalitate
De multe ori este necesar ca trunchiurile din nucleul retelelor sa fie bidirectionale. Adica trebuie sa poata transporta in amblele sensuri informatia.
In specificatiile MPLS, conexiunile bidirectionale erau formate din doua conexiuni LSP unidirectionale, deci trebuia ca cele doua noduri din capetele caii sa fie coordonate. Aceasta abordare putea necesita ca cele doua capete sa interschimbe mesaje de management. Astfel aparea nevoia de doua protocoale de semnalizare: unul pentru MPLS si unul pentru mesajele de management. De asemenea putea rezulta in construirea de doua cai LSP care urmau cai fizice diferite prin retea. Nodurile din capete trebuiau sa determine o cale de a identifica si coordona cele doua cai LSP unidirectionale care formau o cale LSP bidirectionala.
O inbunatatire a fost realizata folosind o procesare speciala la nodul terminal al unei cai LSP unidirectionale, acesta reactiona la primirea unei cerere pentru o cale LSP trimitand o cerere in directia opusa si nu doar trimitand un raspuns de confirmare inapoi. Cu folosirea proprietatii de inregistrare a rutei si rutarea explicita, era posibil ca cele doua cai LSP sa urmeze aceeasi cale fizica prin retea dar ramaneau probleme de coordonare intre ce le doua directii ale caii LSP.
Ambele solutii necesitau patru mesaje de semnalizare(o cerere si un raspuns in ambele directii) pentru a crea o cale LSP.
MPLS generalizat aduce extensii protocolului MPLS pentru a adresa toate aceste probleme si a permite ca o cale LSP bideritionala sa fie construita cu un singur mesaj. Acest lucru are avantajul de a necesita mai putine mesaje de semnalizare si reuseste coordonarea imediata intre directiile de transmisie.
Ca o notare putem defini capatul de intrare a caii LSP 'initiator@
Copyright © 2024 - Toate drepturile rezervate