PROIECT DE DIPLOMĂ

PROIECT DE DIPLOMĂ

INTRODUCERE

Conceptul de bază al MPLS a fost introdus în 1996 de Ipsilon Networks și își propunea comutarea de pachete IP (IP switching). Ideea se baza chiar pe comutația de etichete prezentă în tehnologiile Frame Relay și ATM. Totuși IP switching era gândit inițial să funcționeze doar în rețelele ATM. Conceptul a fost preluat de Cisco Systems și dezvoltat ca Tag Switching – comutare de ștampile (tag-uri). Tag Switching nu mai era obligatoriu să funcționeze peste ATM, putând funcționa și peste Ethernet. Cisco a creat și primul protocol de semnalizare pentru distribuția acestora, Tag Distribution Protocol – TDP și astfel tehnologia a devenit utilizabilă.

Protocolul a fost redenumit MPLS – Multi-Protocol Label Switching când a fost standardizat de IETF iar protocolul de semnalizare a fost denumit Label Distribution Protocol – LDP.

Multiprotocol Label Switching este o tehnologie bazată pe comutația de etichete, scopul ei fiind acela de a simplifica rutarea IP în rețele. Arhitectura MPLS a fost dezvoltată astfel încât să poată oferi servicii de transport de date unificate pentru majoritatea tipurilor de trafic, cum ar fi pachetele IP, celulele ATM, cadrele SDH și Ethernet.

Multi Protocol Label Switching – Comutarea Multiprotocol cu Etichete – reprezintă o nouă arhitectură, în cadrul acesteia nodurile terminale adaugă o etichetă unui pachet IP, realizându-se identificarea traseului către destinație. Pachetele IP sunt redirecționate în baza etichetei, fără a fi necesar verificarea header-ului inițial.

Multi Protocol Label Switching reprezintă o nouă viziune în evoluția tehnologiilor de comutare / rutare, utilizând o soluție care îmbină controlul rutării IP cu comutarea de la nivelul legăturii de date (nivelul 3 din modelul OSI).

În orice caz, flexibilitatea oferită de MPLS a făcut ca aceasta să devină metoda optimă prin care rețelele moderne realizează Quality of Service (QoS), servicii VPN (Virtual Private Network) de ultimă generație sau semnalizare optică. MultiProtocol Label Switching oferă posibilitatea firmelor, dar și a furnizorilor de servicii Internet (ISP – Internet Service Provider) să dezvolte rețele inteligente de ultimă generație, care oferă o gamă largă de servicii avansate, peste o infrastructură unică. Această soluție economică poate fi integrată cu succes în arhitecturile existente, cum ar fi cea IP, Frame Relay, ATM, sau Ethernet.

CAPITOLUL I

GENERALITĂȚI DESPRE MPLS

Ideea care stă la baza dezvoltării acestei tehnologii este ca fluxurile de intrare într-o rețea MPLS să poată fi clasificate în clase de echivalență, care să fie poată fi tratate similar de către nodurile rețelei. O clasă de echivalență intră în corespondență cu un set de etichete de lungime fixă, fiind comutate în nodurile rețelei, până la destinația finală. Nodurile de intrare vor face clasificarea fluxurilor, iar nodurile intermediare efectuează mai puține prelucrări, fiind este suficient să realizeze comutarea etichetelor.

Multi-Protocol Label Switching definește un mecanism pentru transmiterea pachetelor către nodurile rețelei (rutere). Dezvoltarea sa inițială s-a realizat pentru creșterea eficienței de transmitere a pachetelor în raport cu rutarea IP tradițională, iar problema vitezei în cadrul rutării a fost rezolvată odată cu dezvoltarea hardware a echipamentelor de tip ruter.

Integrarea de componente ale aplicației Multi Protocol Label Switchig, unde se poate discuta despre VPN de nivel 2, VPN de nivel 3, Traffic Engineering, QoS sau IPv6, oferă posibilitatea dezvoltării unor rețele eficiente și sigure, care garantează SLA .

Tehnologia MPLS oferă furnizorilor de servicii, dar și abonaților, scalabilitate și grad înalt de diferențiere, simplificare a metodelor de configurare și de management. Soluția MPLS poate fi implementată într-o gamă largă de platforme, fiind esențial pentru furnizorii de servicii și pentru rețelele private.

Pentru identificarea punctelor intermediare sau terminale ale rețelelor, MPLS utilizează adresele IP versiune 4 și versiune 6. Prin acest lucru se observă compatibilitatea rețelelor MPLS cu cele IP, putând fi extrem de ușor de integrat soluția în rețele IP tradiționale.

MODELUL OSI

Modelul OSI (Open Systems Interconnection) este modelul de referință în analizarea, proiectarea și studierea rețelelor de calculatoare, fiind structurat pe 7 niveluri.

„Controlul este transferat de la un nivel superior la unul inferior, plecând de la nivelul aplicație într-unul din dispozitive spre nivelul de bază, cel fizic, de-a lungul canalului de comunicație către celălalt dispozitiv de rețea și înapoi la nivelul aplicație în ierarhia pe nivele” [1].

La fiecare nivel, datele transferate în rețea, numite generic, datagrame , au o structură specifică, un format aparte și poartă o denumire în funcție de nivelul la care se regăsesc.

1.2.1 Nivelul Aplicație (7)

Nivelul oferă suport pentru aplicațiile de rețea și procese. La acest nivel este identificată adresa destinației pachetelor, calitatea serviciilor (QoS) și sunt verificate restricțiile legate de sintaxa datelor.

Tot la acest nivel este realizată autentificarea utilizatorilor. Nivelul oferă servicii de aplicații pentru transfer de fișiere ftp, e-mail, chat, conexiuni distante gen telnet sau ssh–secure. Aplicațiile de tipul telnet sau ftp există în totalitate la nivelul aplicație.

Pentru nivelul aplicație, datagramele au denumirea generică de date.

1.2.2 Nivelul Prezentare (6)

Nivelul prezentare oferă independență cu privire la diferențele de reprezentare a datelor în diverse formate prin translatarea de la aplicație la formatul rețelei și invers.

Nivelul prezentare are rolul de a aduce datele într-o formă convenabilă nivelului anterior. La acest nivel, datele introduce în rețea urmează a fi formatate și criptate, neexistând probleme de compatibilitate. Nivelul prezentare se mai poate regăsi sub denumirea de nivelul sintaxei.

Pentru nivelul prezentare, datagramele au denumirea generică de date.

1.2.3 Nivelul Sesiune (5)

La nivelul sesiune este realizată inițializarea și administrarea sesiunilor de comunicație. Totodată, aici se încheie conexiunea între aplicații. Nivelul sesiune are rolul de a configura, coordona și finaliza interogările dintre aplicațiile aflate la cele două capete.

Pentru nivelul sesiune, datagramele au denumirea generică de date.

1.2.4 Nivelul Transport (4)

Acest nivel are rolul de a oferi o modalitate transparentă de transfer al datelor între sisteme .

De asemenea, la acest nivel se refac erorile generate și se asigură controlul fluxului de date, realizându-se transferul de date cu succes.

Pentru nivelul transport datagramele au denumirea generică de segmente.

1.2.5 Nivelul Rețea (3)

La acest nivel se implementează tehnologiile de comutare și cele de rutare, dezvoltând rute logice sau circuite virtuale.

Funcțiile de bază ale acestui nivel sunt rutarea respectiv redirecționarea pachetelor. Pentru adresarea logică, comunicarea între rețele, administrarea erorilor apărute și secvențierea pachetelor sunt utilizate adresele IP.

Pentru nivelul rețea datagramele au denumirea generică de pachete.

1.2.6 Nivelul Legătură de date (2)

Nivelul legătură de date oferă servicii legate de cunoașterea protocolului de administare și transmitere a datelor spre nivelul fizic, administrarea erorilor, controlul fluxului și sincronizarea frame-urilor.

Nivelul legătură de date se împarte în două nivele: nivelul MAC și nivelul LLC.

La nivelul MAC se verifică accesul la date și modalitatea de obținere a acestuia, precum și transmiterea datelor, de către un dispozitiv de rețea.

La nivelul LLC se verifică sincronizarea dintre frame-uri, controlul fluxului și al posibilelor erorilor.

Pentru nivelul legătură de date datagramele au denumirea generică de frame-uri.

1.2.7 Nivelul Fizic (1)

Nivelul fizic implică realizarea transferului fluxurilor de biți prin intermediul mediilor de comunicație, astfel:

– utilizarea impulsurilor electrice în cazul mediilor bazate pe fir de cupru;

– utilizarea undelor luminoase în cazul fibrelor optice;

– utilizarea undelor radio în cazul transmisiilor radio.

La acest nivel se identifică caracteristicile electrice, mecanice și procedurale din punct de vedere fizic, analizându-se cablajele, conectorii și plăcile de rețea. Există câteva protocoale care au în descrierea lor componente de nivel fizic. Acestea sunt: Fast Ethernet, Token Ring sau Asynchronous Transfer Mode (ATM).

PREZENTAREA GENERALĂ A MPLS

Multi Protocol Label Switching se regăsește la baza serviciilor avansate de rutare, asigurând rezolvarea unei serii de probleme:

pentru modelul IP-over-ATM rezolvă problemele apărute din punct de vedere al scalabilității;

prin utilizarea lui se poate reduce complexitatea operațiilor la nivelul rețelei;

îmbunătățirea tehnicilor de rutare IP existente prin implementarea MPLS care facilitează alte tehnici de rutare;

furnizori de produse si servicii IT realizează inter și intracooperarea pe o platformă standardizată bazată pe tehnologia MPLS

Caracteristica principală a protocolului MPLS este generarea unei etichete scurte, de dimensiune fixă, atașată header-ului pachetului. Prin utilizarea aceastei etichete se ia decizia în procesul de forward. Generarea etichetei pentru un pachet este similară cu adăugarea codului poștal unui plic sau colet în adresa poștală.

Adresa de rutare a unui pachet IP către destinație se regăsește pe un câmp din header-ul acestora. Astfel, informația este procesată de către fiecare ruter din cadrul rețelei, într-o cale a pachetului prin rețea. O astfel de tehnică de rutare se numește rutare pas cu pas.

Într-un mediu MPLS, încapsularea pachetului cu etichetă se realizează de către primul dispozitiv MPLS cu care pachetul IP se întâlnește în rețea. Ruterul MPLS are analizează conținutul header-ului pachetului IP și selectează o etichetă convenabilă pentru încapsularea pachetului. Un astfel de ruter se numește ruter MPLS de margine (edge-router).

Principalul avantaj al MPLS este că în procesul de analiză al pachetului sunt luate în considerare toate informațiile, nu numai cele din header-ul IP, cu privire la adresa destinatară.

În procesul decizional de forwarding al unui pachet IP, eticheta MPLS se utilizează pentru toate nodurile tranzitate în cadrul rețelei, header-ul IP al pachetului nefiind utilizat. Eliminarea etichetei se realizează de către un alt router de margine la părăsirea rețelei de către pachet.

Echipamentele utilizate pentru dirijarea pachetelor în mediile MPLS poartă denumirea de rutere cu comutare de etichete (label switched routers).

LSR dirijează pachetele IP pe baza etichetelor atașate header-ului IP, fiind capabile să ia decizii de comutare. Tabelele de rutare ale ruterelor IP convenționale sunt folosite pentru direcționarea pachetului. Protocoalele de rutare IP sunt folosite pentru construirea și actualizarea tabelelor de rutare. Aceste tabele dețin informații legate de viitoarea destinație a pachetelor, sub formă de adrese IP.

O proprietate fundamentală a unei rețele MPLS este aceea că poate fi folosită pentru encapsularea într-un tunel în rețeaua de core a diferitelor categorii de trafic. Acest procedeu de “tunelare” este foarte important deoarece doar routerele de intrare-ieșire ale tunelului trebuie să “știe” despre traficul encapsulat (de exemplu protocolul folosit pentru generarea traficului și metoda de rutare a acestuia către destinația finală). Acest lucru este “ascuns” pentru ruterele din rețeaua de core.

Spre deosebire de rutarea IP, MPLS folosește etichetele pentru a transmite traficul în domeniul MPLS. Când un pachet intră într-un domeniu MPLS, i se asociază o etichetă pe baza căreia se va determina următorul nod spre care va fi transmis. Etichetele sunt șterse de nodul de ieșire din domeniul MPLS.

„În practică observăm că acest forwarding (inspectarea header-ului IP) și planurile de control (generarea tabelelor de rutare) sunt strâns legate. Întrucât forwarding-ul MPLS este bazat pe etichete, este posibilă separarea clară a planului de forward-are (bazat pe etichete) de planul de control pentru protocolul de rutare. Prin separarea acestora două, fiecare poate să fie modificat independent. Cu o astfel de separare, nu mai avem nevoie să schimbăm mașina care face forwarding-ul, de exemplu, pentru a migra spre o nouă strategie de rutare în rețea.

Suita de protocoale TCP/IP (și în special protocolul IP) este acum fundamentul pentru multe rețele publice (INTERNET) și private (INTRANET) de date. Viitoarea convergență a vocii, datelor și rețelelor multimedia se așteaptă să fie în mare bazată pe protocoale IP, ducând la necesitatea de îmbunătățiri din punct de vedere tehnic și operațional”. [2]

CONCEPTE DE RUTARE ȘI COMUTARE

Conceptele de bază care se aplică în tehnologiile de comutare sunt următoarele:

1.4.1 Rutarea

Reprezintă totalitatea acțiunilor din cadrul unei rețele, astfel încât pachetele să poată tranzita acest mediu. Se poate spune că pachetele pot fi rutate de la punctul x la punctul y, sau că acestea pot fi rutate într-o rețea sau mai multe rețele. Orice rețea poate conține unul sau mai multe rutere. Pentru ca un pachet să poată ajunge la destinația finală sunt implicate protocoalele de rutare, acestea acționând astfel încât să permită mașinii din pasul pachetului, să direcționeze pachetul către mașina din următorul hop.

Pentru implementarea tabelelor de rutare este necesară utilizarea de către rutere a acestor protocoale de rutare. La apariția unui pachet care trebuie direcționat, ruterele consulta tabela de rutare, utilizând adresa IP de destinație a pachetului pentru identificarea următorului hop, astfel încât pachetul să poată fi direcționat către mașina respectivă [3].

1.4.2 Comutarea

Se folosește pentru a descrie transferul de date de la un port de intrare către un port de ieșire corespunzător unei mașini, selecția portului de ieșire fiind bazată pe informația de nivel legătură de date.

1.4.3 Componenta de control

Se utilizează pentru construirea tabelelor de forwarding, precum și pentru menținerea acestora în parametri. Funcționarea ei este bazată pe componentele de control de la alte noduri din rețea, în acest fel distribuirea informației de rutare se va realiza cu succes.

Componentele de control utilizează protocoalele de rutare pentru schimbul informațiilor de rutare. La apariția modificărilor în rețea, componentele de control pot identifica aceste modificări și nu execută intervenții în procesarea pachetelor.

1.4.4 Componenta de forwarding

Este utilizată pentru dirijarea pachetelor. Componenta de forwarding interoghează informațiile generate de tabela de forwarding și în raport cu setul de proceduri locale poate lua decizia de forwarding.

Algoritmul decizional configurat pentru un ruter convențional este bazat pe o comparație între adresa de destinație a pachetului și indexurile din tabela de forwarding, acest algoritm realizându-pe până la cea mai bună potrivire. Procesul se repetă toate nodurile întâlnite de pachet în calea lui către destinație.

1.4.5 Tabela de forwarding

Este utilă pentru buna funcționare a procesului de switching realizat de către componenta de forwarding. Tabela de forwarding oferă soluția optimă de asociere între pachetul de intrare și intrucțiunile de deplasare ale pachetului.

1.4.6 Clasa de echivalență pentru forwarding

Reprezintă totalitatea grupurilor de pachete care pot fi asociate echivalent în vederea realizării opțiunii de forwarding.

Clasele de echivalență au următoarele caracteristici:

destinația unui set de pachete de unicast coincide cu prefixul unei adrese IP particulare;

adresa de expediție a unui pachet este identică cu adresa de destinație a pachetului;

clasele de echivalență pot fi definite la diferite nivele.

1.4.7 Eticheta

Reprezintă elementul de identificare nestructurat, cu lungime fixă, care este necesar asistării procesului de forwading. Eticheta este asociată unui FEC, iar în urma acestui proces sunt identificate două categorii de evenimente:

„Legăturile determinate de date se produc la începutul transferului de trafic, odată cu recunoașterea acestuia de către un comutator de etichete, într-un mediu LSR. Pentru a asigura cât mai puține intrări în tabela de forwarding, legăturile etichetelor sunt stabilite doar în cazurile impetuos necesare. Etichetele nu se asignează pachetelor singular, ci sunt folosite pentru fluxurile de trafic IP individuale. Scalabilitatea rețelei are de suferit datorită utilizării unui număr foarte mare de rețele virtual în rețelele ATM.

Legăturile determinate de control sunt acele legături care derivă din activitatea planului de control, ele fiing independente de date. Legăturile etichetei pot fi stabilite ca răspuns la actualizarea rutelor.

Printr-o comparație bazată pe scalabilitate într-un mediu MPLS se poate spune ca legăturile determinate de control pot fi folosite mult mai bine decât legăturile determinate de date” [4].

CAPITOLUL II

PROTOCOLUL „MULTI PROTOCOL LABEL SWITCHING” – MPLS

2.1 CONCEPTE DE BAZĂ PENTRU MULTI PROTOCOL LABEL SWITCHING

MPLS reprezintă o metodă de comutație rapidă de pachete, în particular fiind folosită în rețele TCP/IP. Tehnologia MPLS este capabilă să conlucreze cu orice protocol de nivel 3, fapt ce a generat expresia de multiprotocol.

„MPLS a fost dezvoltat pornind parțial de la ideile de bază din ATM observându-se eficiența comutării de etichete de tip ATM în comparație cu dirijarea tradițională a pachetelor în ruterele clasice IP, care era bazată pe analiza antetului de nivel trei al fiecarui pachet IP”[4].

Figura 2.1 Schema dirijării pachetelor în interiorul unui mediu MPLS

ER – reprezintă ruterul de frontieră al domeniului MPLS;

LSR – reprezintă comutatorul de etichete numit și ruter intern domeniului MPLS;

LSP – reprezintă calea cu comutație de etichete MPLS.

2.2 DEFINIȚII SI TERMINOLOGIE MPLS

• Domeniu MPLS reprezintă un fragment din cadrul unei rețele, unde dirijarea pachetelor se realizează prin intermediul MPLS, fiind inclus într-un sistem administrativ (AS) sau sistem de rutare;

• Flux de date („flow”) – o instanțiere unică a secvenței de pachete de date dintre două aplicații;

• Clasa de echivalență forwarding (FEC – „Forwarding Equivalence Class”) – un grup de pachete IP dirijate de-a lungul unei singure rute;

• Eticheta MPLS („MPLS Label”) – reprezintă un element de identificare, cu lungime fixă (32 biți) amplasat înaintea antetului IP;

• Comutație de etichete („label swap”) – operațiune în cadrul unui mediu MPLS, care implică modificarea unei etichete la trecerea printr-un comutator MPLS;

• Nod MPLS („MPLS node”) – un nod care rulează MPLS, în sensul identificării protocoalelor de control MPLS, în vederea realizării distribuției etichetelor. Nodul MPLS este capabil să ruleze unul sau mai multe tipuri de protocoale de rutare, realizând dirijarea pachetelor pe bază cu etichetă MPLS;

• Nod MPLS de frontieră („MPLS edge node”) – realizează legătura între un domeniu MPLS cu un domeniu non-MPLS sau cu un alt domeniu MPLS. Există 2 tipuri de noduri de frontieră: de intrare („ingress”) și de ieșire („egress”);

• Router comutator de etichete (LSR – „Label Switched Router”) – nod MPLS de nivel 3 caracterizat prin capacitatea de a comuta etichete, precum și dirijarea pachetelor, utilizând un mecanism de nivel Layer 3;

• Cale cu comutație de etichete (LSP – „Label Switched Path”) – cale virtuală care vehiculează mai multe LSR-uri, prin intermediul unui nivel specific în ierarhia de etichete MPLS. Pachetele dintr-o clasă de echivalență utilizează aceeași cale de comutație în interiorul rețelei;

• Stiva de etichete („label stack”) – structură de date de tip stivă, utilizată în dirijarea MPLS cu mai multe nivele de etichete;

• Circuit virtual etichetat (LVC – „Labeled Virtual Circuit”) – conexiune de tip „hop-by-hop” , identificabilă la nivelul ATM (MPLS over ATM), în vederea realizării unui LSP;

• Protocol de distribuție a etichetelor (LDP – „Label Distribution Protocol”) reprezintă un protocol de comunicare, distribuție a etichetelor și a caracteristicilor acestora între LSR.

2.3 ELEMENTE MPLS

2.3.1. Comutator de etichete (Label Switch Router) – LSR

Un ruter comutator de eticheta este un ruter configurat astfel încât să identifice și să colaboreze cu protocolul MPLS. Ruter-ul are capacitatea de a „înțelege” eticheta MPLS, totodată realizând recepția și transmiterea unui pachet deja etichetat prin intermediul unei legături de date.

Într-o infrastructură de tip MPLS sunt utilizate 3 tipuri de comutatoare de etichete:

Ingress LSRS – preia pachetul neetichetat, atașează eticheta în fața pachetului și realizează transmiterea acestuia prin intermediul unei legături de date;

Engress LSRS – realizează recepționarea pachetelor etichetate, elimină eticheta atașată și ulterior efectueză transmiterea acestora prin intermediul unei legături de date;

Intermediate LSRS – realizează recepționarea pachetelor etichetate, efectuează modificări asupra pachetului, și efectuează transmiterea acestora prin intermediul unei legături de corecție de date.

În vederea atașării sau eliminării etichetelor sunt utilizași clasificatori extrem de performanți, instalați în marginile rețelelor. Pentru aceste operațiuni sunt utilizate rutere MPLS de margine (Edge – LSR).

Ruterele de margine realizează operațiunile de atașare și eliminare a etichetei, în momentul în care pachetele intră, respectiv ies din rețeaua MPLS. Pentru identificarea informațiilor de rutare, comutatoarele de etichete utilizează protocoale de rutare IP.

Caracteristicile etichetei (format și lungime) sunt dependente de încapsularea lor,

negociată ruter prin intermediul interfețelor ATM. Pachetele pot avea atașate simultan una sau mai multe etichete, ordonate în stivă. Comutatoarele LSR utilizează valoarea primei etichete în procesul de forwarding.

2.3.2. Cale de comutație de etichete (Label Switched Path) – LSP

Calea de comutație de etichete reprezintă o secvență intermediară de comutator de etichete, care realizează tranzitul unui pachet deja etichetat într-o rețea MPLS, ralizându-se preluarea pachetului. Traseul pachetului este unidirecțional, distanța parcursă fiind decisă în funcție de configurația protocolului de rutare precum și de constângerile impuse.

Figura 2.3 Schema căii de comutație în rețeaua MPLS

În vederea transmiterii unui pachet din punctul A în punctul B prin calea de comutație cu etichete LSP, urmând traseul optim (latentă și jitter mimim, lațime de bandă maximă) am ales următorul exemplu:

Figura 2.4 Transferul de pachete prin intermediul LSP

Se execută operațiunile de configurare a ruterelor și a etichetelor atașate pachetelor corespunzătoare traseului, astfel:

Traseul pachetului exemplificat, bazat pe intrucțiunile prezentate mai sus se numește LSP (Label Switched Path). Selectarea căii urmate de pachet este realizată în funcție de informațiile legate de trafic (volum de trafic, latentă, pierderi ale pachetelor).

În vederea transformării pachetului IP în pachet MPLS, ruterul R1 realizează aplicarea etichetei 23, protocolul MPLS având caracteristici de suprapunere la IP.

2.3.3 Protocoale de distribuție / semnalizare a etichetelor

Pentru distribuirea etichetelor se folosesc următoarele tipuri de protocoale :

RSVP (Resource Reservation Protocol); 

LDP (Label Distibution Protocol);

CR-LDP (Constraint Route Label Distribution Protocol);

PIM (Protocol Independent Multicast);

BGP (Border Gateway Protocol).

Resource Reservation Protocol – RSVP

RSVP reprezintă un protocol de semnalizare utilizat de către un host în vederea identificării calității optime a serviciului (QoS), în vederea utilizării acesteia într-o aplicație particulară. Protocolul RSVP este utilizat de către un ruter pentru a răspunde cerințelor QoS în nodul tranzitat de fluxul de date al aplicației, ruterul realizând verificarea resurselor disponibile.

RSVP este utilizat în special în medii unde sunt identificate întârzieri (delay), fiind capabil să obțină rezervarea resurselor (bandwidth și buffer), în vederea reducerii întârzierii și a variației acesteia (jitter).

2.3.3.2 Label distribution protocol – LDP

LDP reprezintă un protocol de distribuție a etichetelor care permite construirea căilor comutate cu etichetă (LSP) în domeniul de rețea MPLS. Protocolul LDP realizează identificarea și comunicarea între rutere.

2.3.3.3 Constraint route label distribution protocol – CR-LDP

CR-LDP reprezintă un protocol de distribuție a etichetelor care utilizează constrângeri, fiind asimilat cu un mecanism de tip hardware pentru asigurarea QoS. Pentru implementarea CR-LDP nu sunt utilizate alte protocoale, deoarece se bazează pe structurile existente, realizând doar up-gradarea mecanismelor care asigură calitatea serviciului.

2.3.3.4 Independent Multicast Protocol – PIM

PIM reprezintă un protocol de rutare multicast. Este un protocol independent care conlucrează cu alte tipuri de protocoale pentru identificarea rutelor disponibile.

2.3.3.5 Border Gateway Protocol – BGP

BGP este un protocol de rutare caracterizat prin capacitatea de a identifica și stabili conexiuni între rutere, în locaborare cu protocolul TCP.

2.4 REȚEAUA MPLS

O rețea MPLS este formată din:

nodurile de margine Label Edge Router (LERs) sau Provider Edge (PE)

Ruterele care aplică unui pachet o anumită etichetă se numesc rutere de intrare în domeniul MPLS, Ingress LSR. Cele care șterg eticheta înainte de a transmite pachetul mai departe spre client sau spre o rețea non-MPLS se numesc de ieșire din domeniul MPLS, Egress LSR.

b. nodurile de core: Label Switchining Routers (LSR) sau Provider Routers (P).

Ruterele sunt capabile să comute pe baza etichetelor MPLS

Între aceste noduri se construiește o rețea de canale virtuale (tunele) unidirecționale cunoscute sub numele de Label Switch Path (LSPs).

Figura 2. Rețea MPLS

Între nodurile MPLS adiacente se stabilește o relație de vecinătate, prin protocolul de distribuție a etichetelor. Etichetele au semnificație locală, doar pentru conexiunea dintre cei doi vecini MPLS.

„Când un pachet intra în domeniul MPLS, routerul ingress determina cărui FEC (Forwarding Equivalence Class) aparține pachetul. Pachetele care vor fi trimise către același router egress din rețea, pe aceeași cale aparțin aceluiași FEC și vor fi trimise cu același label MPLS. Este datoria ruterului ingress LER de a determina routerul egress și LSP-ul către acel router asociat cu FEC. MPLS are proprietatea că diferite tipuri de trafic să fie multiplexate în același LSP.

Când se lucrează cu mai multe nivele de etichete în dirijarea traficului MPLS, etichetele sunt aplicate pachetului într-o stivă de tip LIFO (Last In First Out), numită Label Stack. Calea LSP prin rețea către destinație este stabilită de protocoalele de rutare dinamică tip IGP (OSPF, IS-IS, iBGP). Destinațiile sunt împărțite în clase FEC cărora li se atribuie etichete prin operațiunea de Label Binding. Destinațiile sunt clasificate în clase FEC diferite la nivelul unui ruter LSR în funcție de interfața de ieșire, de serviciul QoS ce trebuie satisfăcut sau după alte criterii. Etichetele sunt distribuite, anunțate ruterelor LSR adiacente prin protocolul LDP și astfel se stabilește corespondența între destinația IP și eticheta folosită pentru dirijarea pachetelor. Astfel se stabilesc căile LSP. Etichetele sunt distribuite de la nodul din aval către nodul din amonte. Distribuția poate fi solicitată de nodul din amonte sau nesolicitată”[16].

Figura 3. Distribuția și asignarea etichetelor

În transmiterea datelor propriu-zise prin rețeaua MPLS apar operații specifice MPLS:

SWAP, adică comutația de etichete la nivelul unui ruter LSR;

PUSH, aplicarea unei etichete pentru o clasă FEC la nivelul ruterului de intrare în domeniul MPLS;

POP, ștergerea etichetei la nivelul ruterului de ieșire din domeniul MPLS

2.5 ETICHETE MPLS

2.5.1 Formatul etichetei MPLS

MPLS se situează în cadrul modelului OSI la între nivelele 2 (de date) și 3 (de rețea) ceea ce face să fie denumit un protocol de nivel 2,5. Eticheta este elementul pe baza căruia se iau deciziile de comutare în rețeaua MPLS. Formatul acesteia este prezentat mai jos:

Figura 4. Formatul etichetei MPLS

Figura 5. Structura antetului MPLS

„Eticheta (Label), are lungimea de 20 biți. Poate lua diverse valori din care trebuie amintite câteva rezervate:

IPv4 Explicit NULL Label, are valoarea 0, indică faptul că pachetul trebuie să iasă din domeniul MPLS, rutarea făcându-se pe baza informațiilor din antetul IP. Valoarea 0 o poate lua doar eticheta de la baza stivei de etichete.

Router Alert Label, are valoarea 1 și indică faptul că pachetul are nevoie de procesare software, și va fi trimis la procesorul ruterului. Valoarea 1 o pot lua toate etichetele din stivă mai puțin cea de la baza stivei. Comutarea se va face în continuare pe baza etichetei următoare din stivă.

IPv6 Explicit Null Label, valoarea 2, are aceeași semnificație ca IPv4 Explicit Null Label dar se aplică pentru protocolul IP versiunea 6.

Implicit NULL Label, valoarea 3, indică că mai departe de-a lungul căii LSP se află un ruter de ieșire, care nu va mai avea nevoie de etichetă pentru a ruta pachetul. Valoarea nu este trecută niciodată într-o etichetă aplicată unui anumit pachet ci se va găsi în tabela de etichete (Label Information Base – LIB). Când ruterul va găsi această valoare pentru eticheta de ieșire a unui pachet va ști că urmează un ruter de ieșire și o va șterge direct.

Valorile 4-15 sunt rezervate

EXP – Experimental, în DiffServ MPLS codifică priorități diferite ale pachetelor, 3 biți

S – Bottom of Stack, arată, dacă are valoarea 1, că eticheta este la sfârșitul unei stive

LIFO de etichete, folosită pentru a realiza o ierarhie de domenii MPLS incluse unele în altele. Are lungimea de 1 bit.

TTL – Time To Live, valoarea este copiată din antetul IP la intrarea în domeniul MPLS și folosită pentru detectarea buclelor de rutare / comutare; are lungimea de 8 biți”[13].

2.5.2 Distribuția etichetelor

Distribuția etichetelor îndeplinește două funcții:

Semnalizare cailor LSP – este o funcție prin care ruterul de intrare în domeniul MPLS (Ingress LSR) stabilește o cale LSP și anunță fiecare LSR de pe parcurs să rezerve resursele necesare

Distribuirea etichetelor – este funcția prin care un LSR anunța unui alt LSR ce etichete să folosească pentru o serie de LSP-uri

2.6 AVANTAJE ȘI DEZAVANTAJE ALE TEHNOLOGIEI MPLS

2.6.1 Avantajele utilizării tehnologiei MPLS

În contextul dezvoltării continue a serviciilor în domeniul comunicațiilor și tehnologia informației, implementarea protocolului MPLS oferă o serie de avantaje din perspectiva proiectării, operaționalizării și operării eficiente a rețelelor, dar și o scalabilitate crescută.

„MPLS reprezintă un nou pas în evoluția tehnologiei de comutare multilevel, fiind dezvoltat în baza standardelor IETF. Bazat pe standarde IETF si luând în considerare experiența mai multor soluții de comutare multilevel, MPLS combină folosirea schimbului de etichete în cadrul componentei de direcționare cu rutarea IP, semnalizarea standardizată IP și protocoale de distribuție de etichete din componenta de control. Mai mult, MPLS a fost conceput special pentru a rula pe orice tehnologie de nivel de legătură (nu doar peste o structură ATM) facilitând astfel, migrarea către noua generatie de Internet, bazată pe infrastructuri de fibre optice SONET/WDM si IP/WDM”[5].

În raport cu caracteristicile clasice ale serviciilor de rutare, protocolul MPLS satisface o serie de neajunsuri, cum ar fi:

scalabilitatea (în special la modelul IP over ATM);

complexitatea operațiilor din rețea;

implementarea de noi opțiuni de rutare care conduc la creșterea tehnicilor de rutare actuale;

standardizarea (posibilitatea cooperării inter și intra instituțională);

„ În raport cu tehnicile de rutare convenționale IP, se constată că analiza pachetelor MPLS este bazată pe o serie de elemente inedite (decizia de forwarding este luată în baza etichetei MPLS, la fiecare din nodurile tranzitate, eliminarea etichetelor fiind executată de un ruter de tip edge router, la părăsirea rețelei), acesta fiind avantajul major în utilizarea MPLS”[2].

Prin implementarea MPLS în cadrul rețelelor au fost constatate îmbunătățiri majore:

performanță crescută în dirijarea pachetelor (comutare la nivel 2, viteză de comutare crescută);

compatibilitate cu QoS și CoS (garantarea serviciilor, stabilirea conexiunilor în condiții restrictive);

scalabilitate (implementarea în rețele de tip IP-ATM);

integrarea IP-ATM în rețele (este liantul între IP și ATM, utilizând infrastructura ATM pentru conectarea componentelor de tip ruter și comutator);

interoperatibilitate (posibilitatea interconectării rețelelor IP, ATM, VPN și realizarea garanțiilor cu privire la calitatea QoS);

2.6.2 Dezavantajele utilizării tehnologiei MPLS

Principalele dezavantaje ale utilizării MPLS sunt următoarele:

– dinamicitate scăzută (transmiterea pachetelor se realizează după identificarea conexiunii și stabilirea căii, calcularea unei noi căi în cazul apariției de sincope);

– comutație lentă în raport cu rutarea IP (interogarea tabelelor de rutare);

– timp de prelucrare crescut (prelucrarea căilor de către ruterele de intrare / ieșire este mai mare deoarece acestea sunt configurate și pentru regimuri de funcționare IP);

– memorie cache (în vederea stocării informațiilor cu privire la tabelele de rutare și dirijare este necesară dotarea suplimentară cu memorie pentru ruterele MPLS);

– complexitate crescută (necesitatea dezvoltării infrastructurilor actuale pentru implementarea MPLS).

CAPITOLUL III

MPLS ȘI PROTOCOALELE DE RUTARE IP

PROTOCOALE DE RUTARE

3.1.1. Elemente de introducere

Un protocol reprezintă un set de reguli unanim acceptate, definite în vederea bunei desfășurări a unei comunicații, sau o înțelegere între participanții care comunică, derulate înainte de începerea schimbului de mesaje.

Luând ca exemplu două fișiere cu extensii diferite, dar cu aceeași reprezentare binară, la comunicarea între doi participanți, există posibilitatea solicitării unui fișier și recepționarea altuia, deoarece nu a fost stabilită o regulă pentru transferul în rețea. În vederea stabilirii condițiilor comunicării, intervine protocolul de comunicație.

Protocoalele de comunicație se împart în 2 categorii:

protocoale rutabile – IP, IPX, AppleTalk (alocă o adresă unică unui nod de rețea);

protocoale nerutabile – NetBEUI (identificarea gazdei se realizează prin alocarea unui nume; solicită servicii pentru procesele de nivel scăzut).

Pentru realizarea operațiunilor de rutare se au în vedere 2 aspecte: determinarea rutei optime și efectuarea transportului de pachete. Ruta este determinată la nivelul 3, dar poate fi un proces complex, în funcție de numărul de noduri din rețea.

Rutele se pot clasifica în:

rute dinamice (sunt primite de la un ruter vecin);

implicite (definite manual sub forma traseului pe care îl urmează un pachet când cunoaște calea către destinație);

rute statice (definite în prealabil de către administratorul de rețea) [6].

Totalitatea rutelor cunoscute sunt înregistrate în tabela de rutare. În cazul unor destinații care nu pot fi determinate dinamic, pentru asigurarea unei rute implicite se utilizează algoritmi de rutare. Tabela de rutate conține informații legate de adresele rețelelor, porturi disponibile ale ruter-ului, actualizarea acesteia realizându-se de către protocolul de rutare.

Rutarea dinamică se bazează pe algoritmul utilizat de către protocolul de rutare, deoarece infrastructura rețelei poate suferi modificări, astfel încât tabela de rutare să fie actualizată conform cu realitatea rețelei. Optimizarea acestor factori (algoritmi, topologia rețelei) conduc către fenomenul numit convergența rețelei.

Metrica (lungime – lenght, siguranță – reliability, întârziere – delay, lațime bandă – bandwidth, încărcare – load, cost – communication cost) reprezintă coeficientul utilizat de către protocoalele de rutare pentru calcularea rutei optime și a costului unei rute. Metrica se calculează în funcție de anumiți factori implicați: număr de noduri, viteza de transfer, timp de răspuns, securitatea rețelei [8].

3.1.2 Clasificarea protocoalelor de rutare

Clasificarea protocoalelor se poate face după mai multe criterii:

în funcție de algoritmul utilizat există protocoale bazate pe vectori distanță și protocoale bazate pe starea legăturilor.

în funcție de includerea rutelor în sistemul autonom există protocoale de interior (RIPv1, RIPv2 EIGRP) și protocoale de exterior (BGP);

în funcție de informațiile cu privire la masca rețelei există protocoale de tip classfull (RIPv1,IGRP) și protocoale de tip classless (RIPv2, EIGRP, OSPF).

3.1.3 Switching

Protocoalele de rutare utilizează algoritmi de switching cu complexitate scăzută. Pentru realizarea transferului unui pachet între 2 host-uri se execută următorii pași:

identificarea adresei ruter-ului și transmiterea pachetului la adresa fizică a acestuia;

identificarea adresei protocolului pentru destinația pachetului;

înlocuirea adresei inițiale cu adresa următorului pas al pachetului și transmiterea acestuia către destinație.

3.1.4.Algoritmi de rutare

Algortimul de rutare se clasifică în funcție de particularitățile și resursele rețelei, precum și de metricile utilizate de către acesta, în raport cu obiectivele specifice (optimizare, simplitate, stabilitate, convergență, flexibilitate), în funcție de tipul algoritmului [7]:

static (rutarea este realizată de către administratorul de rețea, fără a interveni asupra rutelor, utilizată în rețele mici) și dinamic (rutare ajustabilă în raport cu modificările de topologie, utilizată în relețe mari). În cazul pachetelor cu destinație neidentificată, tipurile de rutari statice și dinamice pot fi combinate, prin introducerea unei rute statice într-un algoritm dinamic;

single-path și multipath (traficul este multiplexat către aceeași destinație);

plat (la realizarea rutării ruterele nu sunt diferențiate) și ierarhic (ruterele sunt ierarhizate, astfel rutarea se realizează organizat, în funcție de ierarhizarea ruterelor);

host inteligent (determinarea rutei se face de către gazdă, funcția ruter-ului fiind doar de a transmite pachetul) și router intelligent (determinarea rutei se realizează de către ruter);

intradomeniu (algoritmul este funcțional doar în cadrul unui domeniu) și interdomeniu (algoritmul este funcțional în cadrul unuia su mai multor domenii);

statutul legăturii (informațiile de rutare cu privire la statutul legăturii sunt transmise către toate ruter-ele, care înmagazinează informațiile în tabela de rutare proprie) și vector distanță (informațiile de rutare cu privire la statutul legăturii sunt transmise doar către ruterele din vecinătate).

Tabela de rutare

Rutarea pechetelor dintr-o rețea se realizează prin intermediul ruterelor, dar decizia este luată de comun acord de către dispozitivele angrenate în rețea (host, ruter). Pentru majoritatea host-urilor decizia se face prin transmiterea pachetului către destinație (rețele locale) și transmiterea pachetului către ruter (rețele distante).

În contextul rutării la nivelul rețelei, decizia de rutare este luată de către modulul IP, în baza adresei de destinație alocate de către rețea. Modulul IP este capabil să identifice care parte din adresă este adresa de rețea, masca aplicată putând fi masca de rețea, ulterior acesta interoghează tabela de rutare locală. În raport cu informațiile obținute din tabela de rutare, pachetele urmează a fi rutate către adresa de destinație.

Tabela de rutare este formată din următoarele coloane:

Destination – host-ul unde urmează să ajungă pachetul;

Gateway – prin gateway-ul specificat urmează să iasă pachetul către host-ul specificat;

Flags – specificații ale rutei pachetului către destinație (există 4 valori posibile pentru completarea câmpului Flags: U – confirmă operaționalitatea rutei, H – confirmă identitatea host-ului destinație, G – indică trecerea pachetului prin gateway, D – semnalizează implicarea unui mesaj de, tip ICMP în stabilirea rutei);

Ref – numărul de încercări de stabilire a conexiunii de către ruter;

Use – numărul de pachete care urmează să fie transmis prin ruter;

Interface – numele interfeței de rețea utilizată pentru transmiterea pachetului.

Un exemplu de tabelă de rutare este prezentat în figura următoare:

Fig. 3.1.5 Tabelă de rutare [3]

Linia 1 – sunt înregistrate informații despre ruta de tip loopback a host-ului local, această adresă fiind rezervată. Se completează în toate tabelele de rutare, deoarece toate sistemele utilizează rute de loopback pentru transmiterea datagramelor. Se observă completarea câmpului Flags cu valoarea UH, deoarece ruta este exclusivă pentru un anumit host, fiind ocolită rețeaua (127.0.0.0).

Linia 3 – sunt înregistrate informații cu privire la rețeaua 192.1.1.0. Ruta către acestă rețea din tabela de rutare nu specifică folosirea unui gateway extern. În tabela de rutare pentru ruta spre 192.1.1.0 nu este setat flagul G, astfel încât host-ul trebuie să fie conectat direct la rețea.

Linia 4 – sunt înregistrate informații cu privire la ruta default, cu configurarea default a gateway-ului. Orice pachet rutat către altă rețea urmează să fie redirecționat către adresa 192.1.1.1.

„În figura 3.1.6 nivelul IP al fiecărui host și gateway dintr-o reațea imaginară este înlocuit cu o mică parte din tabela de rutare, în care se văd rețelele destinație și gateway-urile folosite pentru comunicarea cu aceste destinații.

Când hostul sursă (192.1.1.1) trimite date către hostul destinație (192.1.2.1), trebuie mai întâi să determine dacă adresa acestuia se află între adresele rețelei locale și să aplice masca de subrețea.

191.1.2.1 AND 255.255.255.0 = 191.1.2.0

După aplicarea măștii de subrețea, IP va ști că adresa rețelei destinație este 192.1.2.0. Conform tabelei de rutare a hostului sursă, datele către 192.1.2.0 trebuie trimise către gateway-ul 192.1.1.2. Gateway-ul 192.1.1.2 va face livrarea direct prin intrefața 192.1.2.2. Examinând tabelel de rutare se observă că toate sistemele afișează numai gateway-urile rețelelor la care sunt direct conectate. De remarcat că 192.1.1.3 este gateway-ul default și pentru 192.1.1.1 și pentru 192.1.1.2. Dar pentru că 192.1.2.1 nu e conectat direct cu rețeaua 192.1.1.0, are un alt gateway pentru ruta default”[3].

Figura 3.1.6 – Procesul de rutare

Tabela de rutare nu este capabilă să descrie tot traseul pachetului de la sursă la destinație. Rutele conțin specificații cu privire la gateway-ul următor, fiind elementul de bază în transmiterea pachetului. Pachetul este transmis de la un gateway la altul, până la destinația finală.

Protocoale de rutare statică

Pentru utilizarea corectî a informațiilor cu privire la o rută, înmagazinate în tabela de rutare, este necesară configurarea și activarea în prealabil a interfeței de ieșire a ruter-ului. Un dezavantaj major este faptul că este necesară actualizarea manuală a tabelei la orice modificare de topologie a rețelei.

Avantajele rutării statice sunt următoarele:

nu este consumatoare de lațime de bandă și memorie;

este avantajoasă pentru rețele de mici dimensini sau grad redus de complexitate.

3.1.7 Protocoalele de rutare dinamice

Protocoalele de rutare dinamică sunt utilizate pentru îndeplinirea următoarelor obiective:

identificarea noilor rute;

transmiterea informațiilor cu privire la rutele disponibile către alte rutere din cadrul rețelei;

transmiterea pachetelor prin intermediul rutelor disponibile[8].

Protocoalele de rutare dinamică se clasifică astfel:

cu vectori distanță (se bazează pe algoritmul cu vectori distanță, prin transmiterea informațiilor legate de tabela de rutare către un ruter aflat în vecinătate, operațiunea fiind executată de fiecare ruter care primește informația într-un mod similar. Astfel fiecare ruter își actualizează propria tabelă de rutare cu informațiile astfel obținute);

cu starea legăturilor (se bazează pe algoritmul cu starea legăturilor, prin schimbul de informații legat de starea legăturii, cu alte rutere, și actualizarea datelor proprii din tabela de rutare. Este avantajoasă prin capacitatea de a identifica modificările apărute ăn topologia rețelei, dar este un consumator de memorie și procesor, generând costuri mari de implementare);

hibride (se bazează pe asocierea dintre protocoalele cu vectori distanță și protocoalele cu starea legăturilor, speculând caracteristicile acestora în calcularea de măsurători mult mai precise și în creșterea convergenței).

Clase de protocoale de rutare

În funcție de aparteneța la același sistem autonom, protocoalele se pot clasifica astfel:

protocoalele de rutare pentru rețele ad-hoc;

protocoale de rutare internă (Interior Gateway Protocols – IGP);

protocoale de rutare externă (Exterior Gateway Protocols – IGP).

3.1.8.1 Protocoale cu rutare internă

Se utilizează în interiorul unui domeniu sau între domenii aflate în vecinătate, pentru rețele de mici dimensiuni. Cele mai importante protocoale cu rutare internă sunt următoarele:

RIP (Routing Information Protocol) este printre primele protocoale de rutare cu vectori-distanță dezvoltate;

IGRP (Interior Gateway Routing Protocol) este un protocol de rutare cu starea legăturilor. A fost dezvoltat de Cisco Systems, fiind utilizat doar pe astfel de configurații hardware;

EIGRP (Enhanced Interior Gateway Routing Protocol) este un protocol de rutare bazat pe protocolul IGRP. A fost dezvoltat de Cisco Systems

OSPF (Open Shortest Path First) este un protocol de rutare cu starea legăturilor;

IS-IS (Intermediate System to Intermediate System) este un protocol bazat pe OSI [9].

3.1.8.1.1 Protocoale de rutare distance-vector

Caracteristica protocoalelor de rutare distrance-vector este determinarea direcției și a distanței unei rute care vehiculează o rețea. Algoritmul unui astfel de protocol realizează transmiterea periodică a informațiilor stocate în tabela de rutare de la un ruter la altul, în vederea actualizării modificărilor survenite în topologia rețelei. Acest algoritm poartă numele de algoritm Bellman – Ford.

Transmiterea informațiilor cu privire la tabela de rutare se realizează doar dinspre ruterele conectate direct la rețea, astfel încât nu se poate identifica topologia completă a rețelelor. Actualizarea tabelei se face doar după identificarea ruterelor aflate în vecinătate.

Tabelul de rutare este transmis de către ruter în vecinătăți, realizându-se un trafic mărit în rețele. Algoritmul are capacitatea de a alege cel mai redus număr de hopuri pentru a ajunge la o anumită destinație.

Astfel, în rețeaua din schema prezentată mai jos, distanța de la router-ul A la rețeaua D este 3.

Distanță : 3 hopuri

Rețeaua A Rețeaua B Rețeaua C Rețeaua D

Figura 3.1.9 Distanța de la un router la destinație

Din perspectiva unei rețele dimensionate liniar, distanța dinte ruter-ul A și destinația D poate avea mai multe rute, cu mai multe hopuri:

Drumul cel mai scurt de la ruter-ul A la rețeaua D

Figura 3.1.10 Calea cea mai scurtă

Algoritmul Bellman-Ford asigură identificarea rutei de la A la D, realizând și distribuirea către nodurile de rețea a informațiilor cu privire la calea aleasă.

3.1.8.1.2 Protocolul RIP

RIP (Routing Information Protocol) este un protocol de rutare din clasa protocolalelor bazate pe algoritmul Bellman-Ford.

„RIP este un protocol de rutare de tip distanta-vector ce implica utilizarea ca metrica de rutare a numărului de pași de rutat (hop count). Prin aceasta, RIP previne apariția buclelor de rutare, utilizând o valoare limita maxima ca număr de pași de rutare pe calea de la sursa la destinație. In general, limita este fixata la 15 (o valoare fixata la 16 reprezinta o distanta de rutare infinita, inoperabila, prin urmare de evitat în selecția procesului de rutare)”. [10]

Caracteristici ale protocolului RIP:

utilizează „metrice” fixe pentru compararea rutelor alternative. Caracteristica nu este potrivită pentru rutele alese în raport cu parametrii de tip întârziere, fiabilitate sau încărcare;

permite host-urilor și gateway-urilor să intercaționeze prin schimbul de informații cu privire la identificarea unei rute într-o rețea bazată pe IP;

Hostul care utilizează protocolul RIP are o tabelă de rutare care conține linii distincte pentru fiecare destinație posibilă, cu următorii parametri implementați: IP-ul destinației și metrica (costul traseului până la destinație), IP-ul gataway-ului următor, informații cu privire la timpii asociați rutei.

Protocolul RIP este un protocol bazat pe UDP. Fiecare host care utilizează RIP transmite și recepționează datagrame (mesaje către alt host, mesaje de actualizare, etc) prin intermediul portului UDP numărul 520, în cadrul procesului de rutare.

Figura 3.1.11 – Formatul pachetului RIP

„Formatul pachetului (RIP versiunea 1) este evidențiat în figura 3.1.11. Porțiunea din datagramă de la address family identifier până la metric poate apărea de până la 25 de ori. Adresa IP (IP address) este adresa Internet obișnuită (versiunea 4) pe 32 de biți”[12].

Caracteristicile datagramei sunt următoarele:

– are în conținut o comandă

– are alocat un număr de versiune;

– are alocat un argument.

Comenzile pentru configurarea unei datagrame RIP (versiunea 1) sunt:

– request – reprezintă o cerere necesară transmiterii tabelei de rutare de către sistem;

– response – reprezintă un mesaj care conține tabela de rutare sau o parte a acesteia;

– traceon – reprezintă un mesaj ignorat, nefiind de actualitate;

– traceoff – reprezintă un mesaj ignorat, nefiind de actualitate;

– reserved – reprezintă un mesaj care conține comenzi utilizate de către Sun Microsystems.

Protocolul IGRP

IGRP (Interior Gateway Routing Protocol) reprezintă un protocol de rutare care are caracteristica de a permite coordonarea proceselor de rutare de către un anumit număr de gateway-uri.

Obiectivele protocolului IGRP sunt următoarele:

stabilitatea rutării în rețele dezvoltate; este exclusă apariția buclelor de rutare;

capacitate de răspuns la modificările rețelelor din punct de vedere al topologiei;

reducerea supraîncărcării rețelei prin utilizarea lățimii de bandă adecvate;

calcularea ratei de eroare pentru rute diferite;

optimizarea traficului de-a lungul rutelor paralele în cazul în care acestea sunt echivalente.

Protocolul IGRP permite gateway-urilor să construiască tabela de rutare prin interogarea altor gateway-uri, având capacitatea de a obține informații necesare actualizării tabelei cu date despre: adresa de destinație, adresa gateway-ului următor, interfața de rețea care urmează a fi utilizată, metrica folosită.

Pentru valorificarea informațiilor cu privire la metrica folosită sunt colectate aspecte cu privire la întârzierea generată de conexiune (timpul alocat pachetului pentru a ajunge la adresa de destinație în raport cu încărcarea rețelei), lățimea de bandă (capacitatea de trafic calculată în bit per secundă), gradul de încărcare al conexiunii (utilizarea lățimii de bandă), precum și fiabilitatea acesteia (calcularea ratei de erori).

Odată cu transmiterea metricii sunt recepționate și informații auxiliare cu privire la numărul de hopuri până la adresa de dedtinație (hop count) și dimensiunea maximă a pachetului transmis fără fragmentarea acestuia (MTU).

EIGRP

EIGRP (Enhanced Interior Routing Protocol) reprezintă un protocol de rutare bazat pe vectori de distanță.

În raport cu protocoalele RIP și IGRP, protocolul EIGRP are caracteristici crescute:

– convergență rapidă;

– consum redus de lațăme de bandă;

– oferă suport pentru protocoalele de rutare multiplă;

– complexitate redusă de configurare și adminstrare a protocolului.

Raportat la celelalte protocoale bazate pe vectori distanță, EIGRP permite doar actualizările parțiale, fiind transmise doar atunci când metrica pentru o destinație este schimbată, oferind doar informații cu privire la rutele modificate.

Componentele care definesc protocolul EIGRP față de celelalte protocoale sunt următoarele:

– module independente de protocol – RTP;

– Reliable Transport Protocol;

– mecanismul de descoperire a vecinilor;

– Diffusing Update Protocol – DUAL.

„Modulele independente permit ca EIGRP să suporte mai multe protocoale de nivel rețea, precum IP, AppleTalk și IPX. Aceste module sunt responsabile cu cerințele specifice nivelului rețea. RTP va garanta livrarea controlată a pachetelor EIGRP tuturor vecinilor, deși, din motive de eficiență, doar anumite pachete vor avea livrarea garantată. RTP folosește o combinație între transmisia unicast și multicast”[9].

Protocolul EIGRP are caracteristica de a construi 3 tabele: cu vecinii (stochează informații cu privire la ruterele învecinate), de topologie (stochează informații cu privire la căile din rețea) și de rutare (stochează informații cu privire la cele mai bune căi din tabela de topologie).

Pentru comunicarea între routere, protocolul EIGRP utilizează 5 tipuri de pachete incapsulate în IP:

– hello – sunt transmise la interval fixe;

– update – sunt utilizate pentru comunicarea rutelor;

– ack – sunt utilizate pentru confirmarea pachetelor transmise;

– query – utilizate pentru obținerea de informații de la routerele sin vecinătate;

– reply – utilizate pentru comunicarea răspunsurilor la pachetele query.

OSPF

Open Shortest Path First reprezintă un protocol bazat pe starea conexiunilor.

Caracteristicile protocolului sunt următoarele:

– convergență ridicată;

– nu prezintă limitări ale capacității de rutare în raport cu numărul de hopuri până la destinație;

– în calcularea rutelor nu intervin bucle de trafic;

– detectează rapid schimbările de topologie din sistemul autonom;

„OSPF rutează pachetele IP doar pe baza adresei IP destinație și a tipului de serviciu specificat în header-ul pachetului IP. Pachetele IP sunt rutate fără a fi încapsulate în vreun alt format al unui protocol suplimetar atât timp cât tranzitează un sistem autonom.

OSPF calculează rute separate pentru fiecare tip de serviciu. Când sunt câteva rute cu cost egal către o anume destinație, traficul este distribuit în mod egal de-a lungul acestora. Costul unei rute este descris de o singură metrică simplă.

OSPF are capacitatea de a permite gruparea mai multor tipuri de rețele, denumită arie. Topologia unei arii este ascunsă de restul sistemului autonom, realizându-se o reducere semnificativă a traficului de rutare. De asemenea, rutarea în interiorul ariei este determinată numai de propria topologie a ariei, asigurând totodată protecția împotriva unor informații de rutare greșite” [12].

Funcționarea procesului OSPF în cadrul unui ruter de desfășoară etapizat:

– se identifică vecinii ruterului și se stabilesc relațiile de vecinătate;

– se selectează ruterul de actualizări și cel de back-up (pentru rețelele multiacces);

– se descoperă rutele;

– se selectează rutele optime către destinație;

– se actualizează informațiile de rutare.

OSPF se poate implementa în următoarele tipuri de rețele:

rețea Point-to-point (se pot interconecta 2 routere);

rețea „broadcast” (suportă mai multe routere conectate);

rețea Non-broadcast (suportă mai multe routere conectate, fără posibilitate de broadcast).

Protocolul OSPF are caracteristica de a construi 3 tabele: de adiacență (tabela se actualizează după expirarea intervalului de timp alocat unui ruter pentru trimiterea pachetelor, prin ștergerea informațiilor legate de routerul respectiv), de topologie (stochează informații cu privire la topologia rețelei, cu privire la starea legăturilor tuturor routerelor din rețea) și de rutare (stochează informații cu privire la ruta optimă, fiind actualizată permanent).

IS-IS

Intermediate System to Intermediate System este protocolul dinamic de rutare legătură-stare dezvoltat de către ISO, ca parte a stivei de protocoale OSI. Are caracteristica de a ruta dinamic pachetele între routere.

IS-IS este bazat pe o metodă de routare dezvoltată la Digital Equipment Corporation, realizând distribuția informațiilor de rutare pentru rutarea datelor CLNP (protocol al stratului de rețea OSI care transportă date ale stratului superior și indicațiile de eroare prin legături fără conexiune) în mediul CLNS (furnizează serviciile stratului de rețea către stratul de transport).

În terminologia ISO, stațiile se numesc ES (end-system) , iar rutele se numesc IS (intermediate system), operațiunile de rutare fiind realizate de către IS-uri.

În figura următoare sunt prezentate 4 procese utilizate de către IS-IS. Integrated IS-IS a păstrat neschimbate procesele de rutare de nivel 1 și nivel 2. Pentru rutarea de nivel 3 este folosit BGP, iar rutarea de nivel 0 este înlocuită de ARP.

Fig. 3.1.8.1.6 Rutarea în IS-IS

3.1.8.2 Protocoale cu rutare externă

Se utilizează pentru tranferul informațiilor în exteriorul domeniului. Cele mai importante protocoale cu rutare externă sunt următoarele:

EGP (Exterior Gateway Protocol) este un protocol de rutare învechit, în prezent nefiind utilizat;

BGP (Border Gateway Protocol este un protocol de rutare bazat pe algoritmul vector distanță, care menține tabelele de adrese de rețele IP și pot fi accesate între sistemele autonome.

3.1.8.2.1 EGP

Exterior Gateway Protocol a fost implementat pentru a transporta informațiile legate de accesibilitate între gateway-uri aflate în vecinătate (sunt interogate periodic prin intemediul mesajelor). Protocolul are în componență mecanisme configurate pentru:

– identificarea vecinilor;

– monitorizarea accesibilității vecinilor;

– schimbul de informații cu privire la accesiblilitatea în rețea.

3.1.8.2.2 BGP

Border Gateway Protocol face parte din familia protocoalelor EGP (Exterior Gateway Protocol), implementat din perspectiva permiterii traficului pe bază de reguli în interiorul unui AS (rețea aflată sub adminstrare comună).

CAPITOLUL IV

PREZENTAREA SERVICIILOR LIVRATE ÎN ASOCIERE CU MPLS

Există foarte multe aplicații cunoscute care folosesc protocolul MPLS, utilizate de furnizorii de servicii de internet, precum și de marile companii cu sedii distante.

Cele mai importante soluții livrate în asociere cu MPLS sunt următoarele:

Calitatea serviciilor în rețele MPLS (MPLS QoS);

Controlul Traficului cu MPLS (Traffic Engineering);

Clase de servicii cu MPLS (Class of Service – CoS);

Rețele private virtuale VPN cu MPLS (Layer 2 și Layer 3)

VPLS (Virtual Protocol Label Switching);

Retele MPLS VPN folosind IPv6 peste tunelele IPv4;

Next Generation Network (NGN).

În acest capitol voi trata următoarele servicii sau soluții livrate în asociere cu protocolul MPLS:

Rețele private virtuale VPN cu MPLS (Layer 2, Layer 3);

VPLS (Virtual Protocol Label Switching);;

Controlul Traficului cu MPLS (Traffic Engineering).

4.1 REȚELE PRIVATE VIRTUALE VPN CU MPLS (LAYER 2, LAYER 3).

4.1.1 INTRODUCERE

„BPG/MPLS IP VPNs sau MPLS L3 sunt unele din cele mai răspândite aplicații ale protocolului MPLS. Soluția a fost extinsă și la Layer 2 astfel au apărut aplicațiile de Layer 2 Transport și VPLS”[14].

În cel mai simplu scenariu un client are câteva locații în diferite zone geografice și dorește conectivitate între ele, dar nu dorește să investească în infrastructura necesară conectării sediilor. Din punctul lui de vedere scopul este de a obține conectivitate intre sediile firmei cu un minim efort financiar și tehnic, prin urmare soluția conectării sediilor prin linkuri punct-la-punct este exclusă din cauza costurilor mari. Din punctul de vedere al furnizorului de servicii, scopul este de a implementa cerințele clientului și maximizarea profitului. Pentru a implementa dorința clientului furnizorul trebuie nu doar să asigure conectivitate intre sediile actuale ale clientului ci și să extindă serviciul oferit cu ușurință pentru un nou sediu și să permită clienților să folosească adrese IP private (deci posibil aceleași adrese IP în diferite locații). Pentru maximizarea profitului furnizorul trebuie să suporte un număr mare de clienți și să poată oferi acestor clienți servicii Premium. Toate aceste servicii trebuiesc oferite pe aceeași infrastructură fizică.

4.1.2 MODELE DE VPN

4.1.2.1 Overlay Model

Cel mai intuitiv model de VPN este cel suprapus peste rețeaua furnizorului de servicii (Overlay model). Clientul și-ar putea conecta sediile prin linkuri punct-la-punct intre echipamentele lui. Aceste linkuri pot fi circuite ATM, Frame Relay , linii închiriate sau tunele IP-over-IP (GRE, IPSec).

În acest model furnizorul oferă doar serviciul de transport și nu are cunoștință de structura și adresarea IP a rețelei interne a clientului. Ceea ce oferă furnizorul este o rețea virtuală peste infrastructura proprie ca suport pentru rețeaua clientului. De cele mai multe ori în acest scenariu este dificil de estimat capacitatea necesară de bandă (traficul necesar sediului respectiv). După ce circuitele au fost configurate și sunt funcționale banda care nu este folosită este pierdută, astfel soluția devine costisitoare.

În acest model serviciul este oferit prin echipamentul instalat la sediul clientului CE (Customer Equipment). În momentul în care clienții sunt responsabili de aceste echipamente ei în realitate își fac singuri VPN-urile, lucru pentru care nu întotdeauna sunt pregătiți sau în care doresc să se implice.

Oricum, indiferent de cine administrează aceste echipamente, modelul în care fiecare locație exista un echipament care schimba informațiile privind rutarea pachetelor are și alte limitări. De exemplu, un scenariu în care există foarte multe locații, numărul de parteneri între care se schimbă aceste informații poate fi foarte mare, prin urmare ar putea apare o problemă de scalabilitate a rețelei pentru protocoalele IGP folosite. O altă limitare apare în momentul în care se dorește adăugarea unei noi locații în VPN. În acest caz noul echipament trebuie configurat astfel încât să schimbe informațiile de rutare cu toate celelalte echipamente cât și echipamentele existente trebuie configurate astfel încât să comunice cu noul echipament.

Prin acest model se atunci scopurile VPN-ului (conectivitate intre locații și asigurarea utilizării unui plan de adresare privat și a traficului privat intre locații), dar totul este sub un anumit cost: dificultatea în a evalua banda necesară fiecărei locații, necesitatea de a administra un număr mare de echipamente instalate la client, configurarea complexă în momentul adăugării unei noi locații.

4.1.2.2 Peer model

„Un alt tip de model este modelul “peer” în care, față de modelul “overlay” unde echipamentele clientului trebuiau conectate direct cu toatele celelalte echipamente din VPN, aici echipamentul clientului CE Router este conectat doar cu echipamentul PE (Provider Edge) al furnizorului de servicii. Din punctual de vedere al clientului astfel rutarea pachetelor devine ușoară și se elimină complexitatea rețelei. În acest fel, problema distribuirii rutelor în VPN este a furnizorului de servicii”[17].

Beneficiile acestui model:

adăugarea unui nou sediu presupune configurarea CE și PE doar pentru noul sediu

o singură infrastructura poate fi utilizată pentru mai mulți clienți

matrice de trafic intre sedii nu trebuie știută exact, este necesar să se știe ce trafic face un singur sediu la un moment dat, traficul dintre sedii va folosi infrastructura furnizorului de servicii

mărirea capacității în general se face mărind capacitatea între CE și PE, decât mărirea capacității pe linia închiriată sau a circuitului

4.1.2.3 Modelul BGP/MPLS VPN – VPN Layer 3

Acest model are la baza modelul VPN “peer” descris mai sus. El a fost publicat prima dată în RFC 2547 (era documentată o soluție dezvoltată de Cisco). Între timp s-a format un grup de studiu IETF care au elaborat documentul 2547bis, ulterior standardizat în RFC 4364.

Scopurile serviciul VPN sunt:

izolarea traficului intre VPN-uri

conectivitatea intre sedii (locațiile aceluiași VPN)

folosirea adreselor IP private

„Pentru a atinge aceste scopuri se folosesc tabelele de rutare per-VPN: per VPN routing and forwarding tables – VRFs. Aceste tabele de rutare sunt adiționale tabelei globale folosită pentru rutarea traficului non-VPN (internet de exemplu) și conțin rutele aferente echipamentelor clientului. Fiecare interfața se asociază unui VRF și astfel echipamentul PE știe ce VRF să folosească în momentul în care un pachet ajunge la interfața respectivă. Mai jos este o diagramă simplă a unei rețele cu doi clienți, fiecare client având propriul VPN”[18].

Figura 6. Rețea cu doi clienți

interfața if1 conectează PE1 cu CE1 și este asociată VPN-ului Customer1

interfața if2 conectează PE2 cu CE2 și este asociată VPN-ului Customer2

când un pachet ajunge în interfața if1, destinația pachetului este căutată în VRF-ul Customer1

când ajunge în interfața if2, destinația pachetului este căutată în VRF-ul Customer2.

dacă pachetul ajunge pe o interfață care nu este asociată cu nici un VRF atunci destinația este căutată în tabela globală.

Folosirea mai multor VRF-uri este o condiție necesară pentru a oferi posibilitatea folosirii aceluiași plan de adresare IP în VPN-uri diferite. Totuși folosirea diferitelor tabele de rutare pentru VPN-uri nu ne asigura condiția ca traficul să nu fie trimis dintr-un VPN în alt VPN. Dacă VPN-ul Customer1 din exemplul de mai sus conține în tabela de rutare informații privind destinația pachetelor către VPN-ul Customer2 atunci acest trafic va fi trimis către cel de-al doilea VPN. Astfel este necesar să controlăm ce rute se instalează în tabele de rutare pentru fiecare VPN în parte. Acest lucru se realizează prin constrângerea informației de rutare pentru fiecare VPN.

Soluția BGP/MPLS VPN de a realiza acest lucru este de a avea toate rutele pentru VPN-uri într-un singur protocol de rutare în rețeaua furnizorului de servicii și de a aplica constrângerea pe echipamentele PE. Ca și protocol de rutare în rețeaua furnizorului de servicii se poate folosit BGP pentru că:

are suport pentru filtrarea rutelor folosind atributul comunitate

se pot atașa rutelor atribute aleatoare, putând astfel să se extindă atributul comunitate

are suport pentru un număr mare de rute, prin urmare poate fi folosit pentru un număr mare de clienți.

poate schimba informațiile intre echipamente care nu sunt direct conectate, prin urmare informațiile privind rutele pot fi păstrate doar la nivelul echipamentelor PE.

Poate transporta informația de etichetă asociata rutelor

Are suport pentru mai multe address families

Se poate folosi intre AS-uri diferite.

4.4 VPN-IPv4 și identificatorul de rute (route distinguisher RD)

Protocolul BGP poate instală în tabela de rutare o singură ruta către o anumită destinație, ceea ce poate deveni o problemă în momentul în care în două VPN-uri diferite se folosește același plan de adresare IP. Soluția pentru a identifica rutele a fost de a adăuga un câmp înaintea prefixului IP: identificatorul de rute – route distinguisher RD creând astfel o nouă familie de adrese VPN-IPV4. Un lucru interesant este acela că adresele IP în VPN-IP este necesar să fie știute doar de către echipamentele care participă la acest schimb de informații privind destinațiile. Translatarea dintre rutele clientului dintr-un anumit VPN și toate celelalte rute din rețeaua furnizorului de servicii se face de către PE. Înainte de a anunța o rută a clientului în rețeaua furnizorului de servicii PE atașează mai întâi RD-ul acelui VPN creând astfel o rută VPN-IP. În momentul în care ajunge la PE-ul de la destinație, acesta șterge RD-ul și trimite traficul către CE.

RD are 8 bytes și conține 3 câmpuri:

Câmpul type – 2 bytes

câmpul administrator

câmpul număr asignat

Există două modalități de a construi RD-ul (în funcție de cum este setat câmpul type)

o combinație de AS number (2 bytes) și un număr asignat local (4 bytes)

o combinație de adresa IP (4 bytes) și un număr asignat local (2 bytes)

Indiferent de modalitatea aleasă trebuie să avem grijă ca în toată rețeaua RD-ul să fie unic asigurându-se astfel unicitatea rutei VPN-IP în rețea.

4.5 Route target RT

Protocolul BGP poate marca o rută atașând la ea una sau mai multe comunități. Acest lucru permite celorlalte echipamente să determine dacă pot accepta sau nu această rută. Atributul comunitate are 32 bit unde primii 16 biți reprezintă numărul AS și ultimii 16 biți reprezintă un număr local, folosit în interiorului rețelei furnizorului. Având în vedere că numărul AS este unic în rețea, limita maximă pentru numărul de valori pentru o comunitate dește de 216. Furnizorul trebuie să se asigure că valorile folosite pentru VPN când și pentru celelalte politici de rutare sunt diferite. Pentru a rezolva această limitare au fost introduse comunitățile extinse RFC 4360, care folosesc 32 biți pentru porțiunea numărului local, astfel limita maximă devenind 232. În contextual VPN-urilor comunitatea extinsă folosită pentru filtrarea rutelor este denumită route target (RT).

Proprietățile RT:

unul sau mai multe RT pot fi atașate unei singure rute

până la 232 RT-uri sunt valabile per AȘ

RT-ul poate fi atașat atât pentru tot VPN-ul cât și pentru fiecare rută în parte

În figură următoare este un exemplu cu două VPN-uri, doua sedii conectate la un PE1, celelalte două conectate la PE2. Ambele PE-uri au cunoștință de rutele direct conectate (către CE). Scopul este de a avea conectivitate intre CE-uri. Astfel PE1 atașează rutei informația RD după care o exporta în protocolul BGP. Tot acum ruta este marcată cu atributul RT (export-RT). PE2 trebuie să decidă în care tabela de rutare instalează rutele. Acest lucru se realizează prin compararea atributului RT cu ce este definit local prin politicile de import (import-RT).

Figura 7 Folosirea RT si RD

„Sumarizând, constrângerea distribuției rutelor este realizată prin politicile de import/export folosind informația RT. O rută marcată cu unul sau mai multe RT-uri este adăugată în tabela de rutare a VPN-ului doar dacă măcar un RT coincide cu RT-ul definit în import-RT în VPN-ul de pe echipamentul respectiv. Mai jos sunt câteva exemple de modele de VPN implementate cu ajutorul informației RT”[19].

Full mesh

Toate locațiile pot comunica între ele creând o topologie full mesh. Un singur RT poate fi folosit pentru politicile de import și export pentru toate locațiile dintr-un VPN. În final, fiecare site instalează toate rutele de la celelalte locații.

Hub and spoke

„Locațiile pot comunica cu celelalte prin intermediul unui site dedicat (the hub) creând o topologie hub-and-spoke. Este folositoare în momentul în care se dorește ca tot traficul să treacă printr-un singur loc, eventual printr-un firewall care este instalat într-o anumită locație. Aceasta topologie poate fi implementata folosind doua RT-uri, unul pentru locații RT1 și unul pentru hub, RT2 după cum este prezentat în figură de mai jos. Toate rutele exportate din locații au atașat la export informația RT1, iar hub-ul va exporta informația folosind RT2. La import locațiile vor importa rutele marcate cu informația RT2, iar hub-ul cu informația RT1. Astfel se asigura conectivitatea intre site-uri dar tot traficul va fi efectuat prin intermediul hub-ului”[19].

Figura 8 Hub and spoke

VPN-uri suprapuse

Sunt folosite în momentul în care anunțe locații din VPN+uri diferite doresc să acceseze același locație (de exemplu unde este instalată o bază de date, folosită de doi clienți diferiți). O soluție este să se marcheze rutele din acest site cu un RT special și aceste rute să fie importate doar în site-urile unde este nevoie de acces.

4.6 Eticheta VPN

„Pentru a crea tunele în rețeaua MPLS este nevoie de o etichetă asociată unei rute VPN. În momentul în care traficul este transmis, traficul VPN este etichetat la intrarea în rețeaua MPLS de către PE și trimis către PE-ul de ieșire. Bazându-se pe această eticheta, PE-ul de ieșire va trimite traficul către VPN-ul corect”[15].

Configurarea și administrarea acestor tunele este utilă dacă se îndeplinesc următoarele condiții:

distribuția informațiilor despre tunele este făcută în mod automat și nu este necesară intervenția manuală

ruterele P nu trebuie să mențină statusul acestor tunele PE-PE

Prima condiție este îndeplinită de protocolul BGP prin redistribuirea etichetei VPN alături de informația de rutare. A doua condiție este asigurată de proprietatea protocolului MPLS de a adăuga mai multe etichete: eticheta interioară asociata VPN-ului și eticheta exterioară asociata tunelului PE-PE. Transmiterea traficului este efectuată întotdeauna folosind eticheta exterioară, deci ruterele P nu trebuie să mențină nici un status privind tunelele VPN. Eticheta interioară este folosită de către PE pentru a transmite traficul către CE.

Sumarizând, eticheta VPN este anunțată alături de fiecare rută VPN-IP folosind BGP-ul. Următorul hop al acestor rute este echipamentul PE care le anunță, iar tunele PE-PE asigura conectivitate intre hopuri.

4.7 Rutarea la echipamentul PE de ieșire

Din punct de vedere al implementării, echipamentul PE are două opțiuni:

o căutare în tabela de etichete după etichetă VPN-ului pentru a determina VPN-ul cărui îi aparține, apoi o căutare în tabela de rutare a VPN-ului după IP-ul destinație pentru a determina interfața de ieșire

o căutare în tabela de etichete, caz în care tabela va întoarce interfața de ieșire.

În primul caz eticheta este folosită pentru a identifica corect VRF-ul, în al doilea caz pentru a identifica interfața de ieșire. La final rezultatul este același: pachetul este trimis spre interfața către CE.

„Mai jos este exemplificat procesul de rutare în cadrul unui VPN. Este analizată doar o singură direcție: de la PE2 către PE1, același proces întâmplându-se și în sens invers.

Figura 9 Rutarea PE2 catre PE1

presupunem că avem un protocol de rutare dinamic intre PE2 și CE2, astfel PE2 primește prefixul 10.2.0.0/16 de la CE2. În cazul în care nu există un protocol de rutare dinamic, atunci PE2 are configurata o rută statică către CE2. În exemplu se presupune că există BGP intre PE și CE.

PE2 atașează RD 65000:1 acestei rute și o etichetă, ex 100.

PE2 exporta ruta în MP-BGP folosind RT: RTCustomer1

65000:1:10.2.0.0/26, label 100, RT RTCustomer1, next-hop PE2

PE 1 primește acest anunț și conform informației RT, el decide că această rută să fie instalată în tabela de rutare. Șterge informația RD și o adăugă cu label 100 și netxt-hop PE2. Ca această rută să devină activa trebuie ca PE2 să poată comunică cu PE1 folosind o cale MPLS (traficul trimis către PE2 va fi etichetat folosind eticheta 100). Presupunând că între PE1 și PE2 exista un tunel creat de LDP și că el are eticheta 200, ruta va se va active cu destinație 10.2.0.0/16 adăugare etichete 100,200.

Dacă există un protocol de rutare dinamic intre PE1 și CE1 atunci ruta va fi anunțată către CE1”[14].

Sumarizând, eticheta VPN permite echipamentelor PE șa demultiplexeze traficul VPN care ajunge la ele. BGP-ul ne oferă o cale automată de a anunța etichetele, atașându-le la rutele VPN-IP. Informația despre VPN-uri este ascunsă de echipamentele P de pe traseu și multiple tunele VPN pot fi adăugate într-un singur tunel PE-PE.

4.8 Rutarea PE-CE

Tabela VRF pentru un VPN conține rute învățate atât de la CE-ul local cât și de la celelalte CE-uri din același VPN. Rutele de la CE-ul local pot fi învățate prin protocolul static sau prin protocoale dinamice: OSPF, BGP. Indiferent de metoda folosită, aceste rute trebuiesc instalate în tabela de rutare a VPN-lui respective. Factorii care pot influența alegerea unui protocol:

limitările echipamentului CE – echipamentele mai ieftine din punct de vedere al costurilor în general suporta doar rutarea statică. Pe de o parte rutarea statică este simplă și suportată de toate echipamentele, pe de altă parte echipamentul CE nu are cunoștință de toate destinațiile din VPN. În cazul în care un LSP din rețeaua furnizorului de servicii devine inactiv, acest lucru nu este semnalizat către CE, prin urmare este posibil să apară întreruperi ale serviciilor oferite clienților.

Gradul de încredere pe care furnizorul îl are față de posibilitățile clientului de a efectua configurări complexe asupra echipamentului CE.

Protocolul folosit de către client în locațiile lui (adăugarea unui nou protocol presupune redistribuirea rutelor ceea ce duce la o creștere a complexității soluției)

Controlul pe care îl poate oferi un protocol aspră a ceea ce exportă clientul – BGP-ul oferă posibilitatea filtrării rutelor care se instalează în tabela de rutare. Este foarte ușor să configurezi greșit un peer de BGP și astfel să se anunțe rutele care nu trebuie. Furnizorul de servicii trebuie să se asigure că el va accepta întotdeauna doar rutele necesare configurând filtre sau un număr maxim de rute.

Folosirea OSPF ca protocol de rutare intre PE-CE:

OSPF-ul folosește LSA-ul pentru a comunica informațiile privind topologia. Ele nu pot fi filtrate, prin urmare orice LSA trebuie procesat de către PE. Rutele sunt de tip VPN-IPv4 în rețeaua de core și tipul LSA-ului trebuie menținut același când rutele sunt anunțate către celelalte site-uri din VPN. Acest lucru este realizat prin folosirea comunităților extinse ale protocolului BGP.

Folosirea BGP ca protocol de rutare intre PE-CE:

Când folosim acest protocol apare EBGP-ul (presupunând că furnizorul și clientul au AS-uri diferite). El este cea mai populară alegere deoarece oferă posibilitatea filtrării anunțurilor și a prefixelor acceptate și nici nu exista reactualizări periodice ale informaților de rutare.

Problema apare în momentul în care clientul are două locații și în ambele folosește același AȘ. Datorită protecției de buclă a BGP-ului (loop-prevention – nu se învață o rută care are în AS path același AS că și AS-ul local) atunci rutele exportate din locația 1 folosind AS65000 nu vor fi învățate de către echipamentul din locația a doua (AS65000). Problema poate fi rezolvată prin:

configurarea pentru fiecare locație în parte a unui AS diferit

configurarea echipamentului CE să treacă peste această verificare și să accepte prefixele chiar dacă în AS Path este prezent AS-ul local

rescrierea AS-ului clientului cu AS-ul furnizorului în momentul în care rutele se anunță că VPN-IP

Sumarizând, pentru a obține informațiile de rutare de la CE este nevoie de instanțe separate ale protocoalelor de rutare per VPN. Alegerea metodei de rutare depinde de mai mulți factori: capabilitatea echipamentului CE, protocolul folosit deja în rețeaua clientului, încrederea pe care o are furnizorul în capacitatea clientului de a configura echipamentele.

4.9 Beneficiile soluției BGP/MPLS VPN – VPN Layer 3

Această soluție permite clienților să renunțe configurarea echipamentelor cu tunele intre diferite sedii, acest lucru fiind efectuat de către furnizorul de servicii. La rândul său, furnizorul de servicii poate oferi clienților sau servicii cu valoare adăugată, cum ar fi un firewall sau un server de autentificare. De asemenea el poate folosi aceeași infrastructura pentru mai mulți clienți, nefiind necesară administrarea pentru fiecare client în parte a unui backbone virtual. Prin “ascunderea” informației la nivelul P, complexitatea rutării este lăsată la latitudinea PE-urilor și serviciul poate fi extins doar prin adăugarea de noi PE în cazul în care este necesar.

Dar cea mai importantă proprietate este tunelarea. „Ea ne permite:

să construim o ierarhie privind cunoștințele de rutare ale echipamentelor, este posibil să transmitem traficul către adrese care nu sunt cunoscute de către rețeaua de core (echipamentele P)

să identificăm un anumit trafic ca aparținând unui anumit VPN în punctul de ieșire din rețeaua furnizorului de servicii”[20].

4.10 Tratarea diferențiată a VPN-urilor în rețeaua furnizorului

În rețeaua e core se poate aplica tratamente diferite pentru traficul diferitor clienți, astfel:

traficul efectuat din locațiile unui client “gold” poate fi transportat prin căi protejate în rețeaua MPLS asigurându-se astfel un grad mare de disponibilitate a serviciului. Pentru clienții “silver” această protecție nu este necesară.

Un anumit tip de trafic din rețea (de exemplu cel de voce) poate fi transportat prin anumite LSP-uri care îndeplinesc anumite condiții de latentă și protecție.

Izolarea traficului de VPN față de restul traficului (de exemplu pentru bănci sau instituții guvernamentale) – LSP-urile create trebuie să fie doar pentru acest tip de trafic șiș a nu vie valabile și pentru restul VPN-urilor.

4.11 Rolul Route-Reflectors

Route-reflectorii (RRs) ne oferă următoarele beneficii:

reducerea în numărul sesiunilor BGP care trebuie configurate. Echipamentul PE trebuie să stabilească doar o sesiune BGP cu RR în loc să aibă sesiuni BGP cu toate echipamentele PE.

Nivel simplu de configurare: adăugarea unui nou echipament PE presupune configurarea unei sesiuni BGP doar cu RR-ul.

Diferențele în folosirea RR într-o rețea IP generală și o rețea de VPNs apar din deferentele de informații de rutare:

informațiile de rutare din echipamentele PE

numărul de rute către destinația finală

Într-un scenariu IP general, în tabela de rutare a protocolului BGP găsim Tabela Internet. Prin urmare toate echipamentele trebuie să conțină o cale către destinație și, este posibil, să existe una sau mai multe căi având în vedere că în general furnizorii de servicii au câteva conexiuni externe prin care obțin aceasta tabela.

În acest scenariu, RR-urile sunt folosite pentru a determina calea cea mai bună către destinație, cu următoarele consecințe:

reducerea numărului de cai, RR-ul va selecta calea cea mai bună șip e ea o va anunța către parteneri.

reducerea numărului de actualizări generate sau procesate de către un echipament care are configurate sesiuni BGP

resursele de memorie și procesor necesare RR-urilor.

Într-un scenariu de VPN:

echipamentele PE trebuie să mențină tabela de rutare doar pentru VPN-urile la care sunt conectate

căile multiple pentru aceeași destinație nu sunt predominante. Chiar dacă aceeași destinație este anunțată din mai multe VPN-uri, selectarea caii nu apare decât în cazul în care se folosește același RD

Observații privind folosirea RR-urilor într-o rețea de VPN-uri:

este de dorit ca PE-urile să primească actualizările de informații de rutare doar pentru VPN-urile care sunt conectate la el, decât să primească toate rutele din VPN-uri

nu este necesar ca RR-urile să conțină tabele de rutare pentru toate VPN-urile configurate în rețea. Presupunând că avem configurare RD-uri distincte, RR-urile nu vor fi nevoite să aleagă calea cea mai bună, prin urmare traficul nu trebuie să treacă prin RR.

Totuși RR-ul poate deveni o problemă având în vedere că un sigur echipament este necesar pentru a avea toate rutele din toate VPN-urile din rețea. Soluția poate fi adăugarea mai multor RR-uri (pentru redundantă) și împărțirea rutelor din VPN-uri. Astfel un echipament PE va stabili o sesiune BGP doar cu RR-urile care conțin informații privind VPN-urile la care este conectat. Problema apare în momentul în care un echipament PE are nevoie de rutele de pe mai multe RR-uri. Soluția este că PE să informeze RR despre rutele de care are nevoie. Acest lucru se poate face prin două modalități:

outbound route filtering (ORF) – limitat la doi vecini BGP conectați direct – limitează numărul de actualizări trimise între cei doi vecini.

route-target filtering (RT) – informațiile de filtrare sunt propagate în rețea exact ca și în cazul informațiilor de rutare și pot fi folosite peste hopuri multiple sau chiar între AS-uri diferite.

4.12 VPN-uri de nivel 2

Serviciile L2 au existat, bazându-se pe Frame Relay sau ATM, ele fiind folosite de către clienți pentru a conecta în același Local Area Network doua sedii într-o topologie full mesh sau hub-and-spoke. În majoritatea cazurilor aceste servicii se pot migra peste o rețea MPLS menținând în același timp Service Level Agreement (SLA) definit pentru parametrii de pierderi de pachete, latenta sau delay.

În afară de serviciile L2 point-to-point, mulți furnizori de servicii pot oferi și servicii Ethernet multipoint, cunoscute sub numele de Virtual Private LANs (VPLS).

L2 Transport

„O conexiune punct-la-punct transportată peste o rețea MPLS mai este cunoscută sub denumirea de pseudowire. Un serviciu L2VPN este o colecție de pseudowire ce interconectează CE-urile din diferite locații într-o topologie aleasă de către client, (full mesh sau hub-and-spoke). Exemple de protocoale ce pot fi transportate peste un asemenea serviciu: ATM, Ethernet (maparea traficului în pseudowire se poate face per VLAN sau per port), Frame Relay (maparea se face per DLCI sau per port)”[21].

Există două metode de configurare a acestor servicii:

folosind semnalizarea LDP [MRT-TRS, PWE3-CON]

folosind semnalizarea BGP [KOM-BGP].

Detalii despre cum sunt encapsulate pachetele L2 pentru transportul peste MPLS într-un pseudowire sunt în documentul IETF “Metode de encapsulare pentru transportul frameurilor Layer 3 peste rețele IP și MPLS”. Mai jos este un exemplu prin care un furnizor de servicii folosește rețeaua MPLS pentru a oferi un serviciu L2 către un client.

Figura 10 L2 Transport intre 3 locații

4.2 VIRTUAL PRIVATE LANS (VPLS)

„VPLS-ul ne permite să conectăm diferite sedii din diferite locații ca și cum ar fi atașate la același LAN. În cazul L2VPN descris mai sus pentru a conecta cele trei sedii a fost nevoie de 2 VLAN ID-uri / per conexiune PE-CE (din cauza faptului că s-a dorit o rețea full mesh). În cazul VPLS este necesar un singur VLAN ID per conexiune PE-CE, figură de mai jos.

Figura 11 VPLS intre 3 locații

Asta deoarece VPLS-ul este un serviciu multipunct și echipamentul PE este responsabil pentru transportul frameurilor către destinația/destinațiile finale. Ca și în cazul L2VPN orice tip de protocol L3 poate fi transportat peste VPLS, cum ar fi IPX” [22].

Mod de funcționare

În exemplul de mai jos sunt locațiile aferente pentru doi clienți X și Y. Clientul X are locațiile conectate în PE1, PE2 și PE3. Clientul Y are locațiile conectate în PE1, PE3 și PE4. Din punctul de vedere al clienților locațiile apar ca fiind conectate la același LAN (clientul X aparține unui VPLS, clientul Y aparține celui de-al doilea VPLS).

Figura 12 Rețeaua furnizorului și locațiile pentru doi clienți VPLS

Pentru fiecare instanță de VPLS, echipamentele PE sunt conectate full mesh cu pseudowire. Acest lucru este necesar astfel încât PE-ul care primește un frame de la alt PE să poată identifica VPLS-ul de care aparține după etichetă de la pseudowire. În plus, sunt necesare și tunele intre PE-uri. În general se folosesc LSP-uri, dar pot fi folosite și tunele GRE sau IPSec ca alternativă. „Pseudowire sunt construite ca și în cazul serviciilor L2Transport prin două metode:

bazate pe semnalizarea BGP – există mecanismul de autodiscovery care construiește în mod automat aceste pseudowire

bazate pe semnalizarea LDP – în acest caz pseudowire le construim manual sau ne putem baza pe un mecanism de autodiscovery extern.

Din punctul de vedere al clientului, un frame care este trimis către rețeaua furnizorului de servicii este trimis mai departe către destinație bazându-se pe adresa MAC destinație a acestuia. Este datoria PE-ului să inspecteze toate frameurile care ajung pe interfața locală și analizeze adresa MAC destinație a lor. Dacă destinația este un alt PE atunci PE-ul de intrare (ingress PE) trebuie să trimită pachetul către pseudowire-ul aferent PE-ului destinație. Pentru VPLS fiecare PE este responsabil pentru aflarea cărui PE îi este asociat un MAC”[23].

Fiecare PE este echivalent unui bridge, cu instanțe separate pentru fiecare VPLS configurat pe el. În esență, funcția de “învățare”: se analizează adresa sursa MAC a frameului care ajunge pe un port, fie că este o interfață direct conectată, fie că este un pseudowire și creează o intrare în tabela de rutare. Astfel echipamentul PE va ști unde să trimită frameurile următoare care au ca destinație această adresă MAC. În acest mod nu este necesar un echipament care să știe toate aceste corespondente și nici nu este necesar ca ele să fie anunțate către celelalte echipamente PE din VPLS. Acesta asociere se întâmplă pentru fiecare adresă MAC în parte din rețeaua VPLS (dacă cineva își va conecta un laptop într-un echipament CE L2 – switch – atunci corespondenta port-MAC se va regăsi pe toate echipamentele PE care aparțin instanței de VPLS ). Acest lucru nu se întâmplă în cazul L3VPN – unde în tabela de rutare sunt doar subneturile aferente VPN-ului sau în cazul L2 Transport – unde în tabela de rutare apare doar corespondenta cu pseudowire-ul aferent circuitului. Prin urmare este posibil că furnizorul de servicii să decidă să pună o limită pentru numărul maxim de adrese MAC acceptate. În cazul clienților mari este bine ca să se folosească un echipament L3 ca și CE decât echipamente Layer 2.

4.13 Comparație între VPN-urile Layer 3 și VPN-urile Layer 2

BGP/MPLS Layer 3 VPN este un model de tip peer privind conectivitatea. În contrast, serviciile L2 VPN sunt construite pe o rețea de tip overlay. Astfel apar diferențele între cele două tipuri:

în cazul L2 nu este necesară prezenta unui protocol de rutare intre Pe și CE. În cazul L3 cele două echipamente trebuie să facă schimb de informații de rutare

Funcție de tipul de trafic transportat – în cazul L2 clientul poate să ruleze orice protocol de nivel 3 peste acest serviciu (rețeaua furnizorului se servicii pur și simplu transporta framurile), în cazul L3 se poate transporta doar trafic IP

Scalabilitate – din punct de vedere al scalabilității, un factor de limitare pentru ambele soluții este numărul maxim de LSP-uri sau/și VC-uri care pot fi suportate de un LSR. Un alt factor limitator este mărimea maximă a fișierului de configurare care poate fi memorat în router-ul PE. În soluția Layer 3 fișierul de configurare conține definiții pentru VRF-uri, RDuri, și politici de filtrare și rutare. În cazul soluției Layer 2 fișierul de configurare conține definiții pentru VPN-urile care aparțin PE-ului și porturile asociate cu VPN-urile client. Folosirea funcției de autodescoperire împreună cu soluția Layer 2 evită configurarea explicită a VPN-urilor ce aparțin PE-ului, și implicit micșorarea impactului introdus de mărimea fișierelor de configurare

în cazul L2 sunt necesare mai multe interfețe (logice) între CE și PE (către una pentru fiecare CE distant la care CE –ul local trebuie conectat). În cazul L3 este necesară o singură interfața deoarece echipamentul PE este responsabil pentru rutarea informației către destinație.

CONTROLUL TRAFICULUI CU MPLS (TRAFFIC ENGINEERING)

Traffic Engineering, implement în rețele ATM sau Frame Relay, dirijează și optimizează traficul de la un capăt al rețelei, la celălalt capăt, transportul fiind realizat prin intermediul circuitelor virtuale.

Utilizarea TE implică configurarea și calcularea rutelor de-a lungul unei rețele, astfel încât lățimea de bandă să poată fi utilizată în cel mai eficient mod. TE este instrumentul cheie în atingerea obiectivelor de viteză, utilizare maximă a lățimii de bandă disponibile și a costurilor aferente traficului.

Implementarea TE MPLS poate fi folosit de ISP pentru a echilibra transportul de trafic prin diferite link-uri, în vederea creșterii performanțelor rețelei [24].

Pentru organizarea circuitelor virtuale se utilizează modele de suprapunere, cel mai cunoscut fiind Overlay model. Chiar dacă în rețele ATM sau Frame Relay încă se folosește protocolul IP, se observă că tot mai des întâlnim soluții IP care rulează peste rețele de tip MPLS enabled. Pentru acest lucru este nevoie de prioritizarea traficului pentru rețelele IP. Având în vedere că TE nu este funcțional într-o rețea IP clasică, este nevoie de implementarea acestuia în rețele MPLS.

4.2.1. Necesitatea folosirii MPLS TE

Scopul rutării într-o rețea IP este de a transporta traficul în cel mai scurt timp. Pentru aceasta se folosește principiul de rutare cu costuri minime. Costul unui link din cadrul rețelei este asociat fiecărui protocol de rutare IP. Traficul prin rețea este transmis după calcularea căii care presupune costul cel mai redus.

Suplimentar, pachetele IP traversează hopurile luând în considerare adresa IP a destinației, fără a ține cont de modalitatea transmiterii acestora anterior hopului, sau după traversarea acestuia.

Totodată, la transmiterea pachetelor IP nu se folosesc informațiile cu privire la lățimea de bandă disponibilă. Lățimea de bandă nu este direct proporțională cu costul asociat, iar ruterul transmite permanent traficul indicat de către tabela de rutare, fără să țină cont de aspectele cu privire la parametrii lățimii de bandă. Raportat la modul de transmitere a pachetelor IP se constată suprasolicitarea unor linkuri din cadrul rețelei și neutilizarea eficientă a altora. Pentru reglarea neajunsurilor cu privire la utilizarea linkurilor se poate folosi o solutie TE în scopul dirijării traficului uniform.

Un exemplu de rețea IP Forwarding este prezentată în schema de mai jos. Să presupunem că linkurile R1, R2, R3, R4 și R5 au același cost. Se poate observa că traficul va fi dirijat pe ruta R1 – R2 – R5, suprasolicitând linkul R2, în timp ce ruta R1 – R3 – R4 – R5 va fi liberă.

Figura 4.2. Rețea clasică IP Forwarding

Pentru decongestionarea traficului se poate modifica costul linkurilor asociate protocolurilor de rutare, astfel încât să fie realizată o anumită uniformizare a traficului, cu mențiunea că distribuția încărcării nu poate fi egală datorită diferențelor dintre lățimile de bandă. Teoretic, dacă suma costurilor linkurilor dispuse în ruta R1 – R2 – R5 este egală cu suma costurilor linkurilor dispuse în ruta R1 – R3 – R4 – R5, atunci rutele sunt egale și încărcarea traficului este echilibrat. Privind cu atenție se observă totuși o diferență între cele 2 rute și anume numărul de hopuri. Pe de-o parte avem 2 noduri și pe cealaltă parte avem 3 noduri, din acest context rezultând o sarcină extrem de complicată în scopul încărcării egale a linkurilor. Având în vedere că lățimea de bandă se poate majora prin creșterea vitezei prin linkurile din rețea, problemele cu privire la echilibrarea traficului cresc proporțional. Procedura de modificare a costurilor linkurilor este reluată, operațiunile fiind executate manual.

Pentru rezolvarea acestor probleme se poate utiliza soluția MPLS TE.

Principalele avantaje ale utilizării soluției MPLS TE sunt următoarele:

distribuirea eficientă a traficului în rețea;

evitarea linkurilor suprasolicitate sau a celor nesolicitate;

distribuirea traficului în funcție de lățimea de bandă accesibilă;

distribuirea traficului în funcție de factori ca întarzierea sau bruiajul linkurilor;

reconfigurarea automată a traficului în contextul modificării lățimii de bandă sau a atributelor linkurilor din rețea.

Principiul de funcționare a MPLS TE este acela de utilizare a ruterului head end pentru eficientizarea căii LSP și calcularea acesteia către ruterul tail end. Acest lucru este posibil doar în cazul în care ruterul head end dispune de informații cu privire la topologia rețelei, lățimea de bandă disponibilă în momentul respectiv la toate linkurile din rețea. Legătura LSP de la un capăt la celalalt al rețelei poate fi stabilită prin activarea MPLS la nivelul ruterelor dispuse în cadrul rețelei. Astfel, este posibilă rutarea bazată pe sursă, prin utilizarea Label switching în detrimentul IP Forwarding.

Un exemplu de rețea bazată pe MPLS TE este prezentată în schema de mai jos. În raport cu schema IP Forwarding prezentată anterior, au fost adăugate 2 rutere, R6 și R7, pentru a prezenta conceputul MPLS TE. Astfel, în cazul în care este utilizat IP Forwarding, căile posibile de deplasare a pachetelor dinspre ruterele R6 și R7 către ruterul R5 sunt R6 – R1 – R2 – R5 și R7 – R1 – R2 – R5, configurarea ruterelor R6 și R7 nefiind luată în calcul la stabilirea căilor. Deoarece în cazul unei rețele IP, ruterul R1 nu are informații cu privire la configurația ruterelor R6 și R7, acesta transmite pachetele în funcție de tabela de rutare proprie.

Figura 4.3 Rețea sursă MPLS TE

În exemplul prezentat, ruterul R6 este configurat astfel încât traseul de deplasare să fie realizat pe calea R6 – R1 – R2 – R5, iar ruterul R7 este configurat astfel încât traseul de deplasare să fie realizat pe calea R7 – R1 – R3 – R4 – R5. În rețeaua MPLS prezentată, etichetele folosite sunt diferite și sunt utilizate de LSP-uri diferite. Ruterul R1 este configurat astfel încât să fie capabil să identifice valorile etichetelor de intrare ale pachetelor și să cunoască dacă pachetul este transmis de către unul din cele 2 rutere head end R6 sau R7, precum și ce LSP folosește. În consecință, ruterul R1 transmite pachetul prin intermediul LSP-urilor definite.

Implementarea MPLS TE se poate realiza în orice rețea care are LSR, dacă sunt îndeplinite anumite condiții:

– ruterul head end să cunoască parametrii lățimii de bandă și a atributelor (întârzieri sau bruiaje) linkurilor;

– să fie utilizat un protocol de rutare de tip link state între punctele finale ale MPLS TE.

Prin utilizarea protocolului de rutare link state, ruterele prezente în rețea au capacitatea de a genera o stare cu privire la propriile linkuri, aceasta fiind distribuită ulterior către ruterele aflate în vecinătate. Cu alte cuvinte, informațiile cu privire la topologia rețelei vor fi cunoascute de toate ruterele prezente în rețea. „Având aceste informații ruterul head end al LSR-ului poate stabili LSP-ul utilizat în rețeaua MPLS TE. Un astfel de LSP poartă denumirea de tunel MPLS TE” [25]. Caracteristicile unui tunel MPLS TE sunt:

– în contextul în care LSP-ul este unidirecțional, atunci și tunelul MPLS TE este unidirecțional;

– detaliile cu privire la tunelul MPLS TE sunt configurate doar la nivelul ruterului head end al LSR;

– este necesară semnalizarea tunelului MPLS TE.

Odată cu activarea tunelului MPLS TE, acesta poate fi utilizat din 2 perspective:

a. configurarea de tunele MPLS TE distincte pentru fiecare pereche de LSR dispuse în marginea rețelei, astfel încât să fie realizată dirijarea traficului în rețea, fără apariția fenomenelor de congestionare; asigurarea distribuirii informațiilor cu privire la parametrii lățimii de bandă și a atributelor linkurilor;

b. în cazul implementării MPLS TE la nivelul întregii rețele este realizată obturarea tunelelor MPLS TE când nu există trafic și activarea acestora la cerere; tunelele pot fi activate în cazul apariției blocajelor sau a supraîncărcării unui punct din rețea.

4.2.2 FUNCTIONAREA MPLS TE

4.2.2.1 Caracteristici ale MPLS TE

Soluția MPLS TE a fost folosită prima dată sub numele de RRR. Dintr-o analiză sumară a numelui, factorul decisiv pentru implementarea MPLS TE este raportul dintre rutarea / direcționarea traficului în rețea și resursele / constrângerile din rețea (lățime de bandă, atribute ca întârzieri sau blocaje).

Parametrii de funcționare ai MPLS TE sunt:

– disponibilitatea linkului în raport cu taficul maxim realizat, precum și identificarea tunelului TE alocat în utilizarea linkului – constrângeri ale linkului;

– facilitarea distribuirii de informații de către protocolul de rutare link state;

– calcularea rutei optime, în baza unui algoritm, între head end LSR și tail end LSR;

– utilizarea protocolului RSVP pentru semnalizarea tunelului TE la nivelul întregii rețele;

– transmiterea traficului prin intermediul tunelului TE.

Protocoalele de rutare link state OSPF sau IS-IS au capacitatea de a avertiza apariția atributelor, având rolul de a distribui informația către toate LSR-urile. Astfel, apare asa numitul TE LSP, de fapt fiind head end LSR pentru tunelul TE MPLS.

În figura 4.4 este prezentată schema funcțională pentru un tunel TE.

Fig. 4.4 Schema unui tunel TE sau LSP

După cum se observă, tunelul TE este creat între ruterele R5 la R6. La nivelul ruterului R6 se crează o bază de date (algoritm) denumită generic PCALC, prin intermediul protocolului link state care trimite informațiile.

Datele stocate sunt:

– informații cu privire la linkurile active;

– caracteristicile și atributele linkurilor.

În baza acestora poate fi calculată calea cea mai scurtă dintre LSR-ul head end și LSR-ul tail end. Constrângerile pot fi actualizate la nivelul linkurilor rețelei. Pentru a alege traseul optim, PCALC analizează caracteristicile tunelului, precum și cele ale linkurilor, corelând cerințele cu privire la parametrii lățimii de bandă și a atributelor. Activitățile se realizează la nivelul ruterului head end.

4.2.2.3 Modul de operare MPLS TE

Pentru a înțelege în mod adecvat funcționarea MPLS TE voi prezenta unui scenariu practic:

1. „În cazul unui ruter care are implementat protocolul de rutare link state, acesta permite o suplimentarea lățimii de bandă pentru utilizarea unui link de rezervă. TE MPLS necesită rutarea link state pentru fiecare LSR, pentru a avea o topologie completă a rețelei și pentru a calcula cea mai bună cale pentru tunel. Atât IS-IS și OSPF sunt protocoalelor de rutare link state, care au extensia necesare pentru TE.

Fig. 4.5 Schema unui tunel TE varianta I

2. În figura 4.5, ruterul H, de la capătul tunelului, este un rutr de tip head end și funcționează ca un CSPF pentru a determina cea mai bună cale către nodul B, bazat pe lățimea de bandă disponibilă;

3. Cu ajutorul CSPF, pachetelefolosesc calea H-G-F-E-D-C-B, dar link-ul prin D este foarte lent din cauza congestiei. În cazul modificărilor de utilizare ale linkurilor, CSPF poate schimba rezultatele pentru aceeași destinație.

4. RSVP este utilizat pentru a crea tunele. Ruterul transmite un „path message” spre celălalt capăt al tunelului așa cum se observă în figura de mai sus. Acesta urmează aceeași cale a tunelului definit de către CSPF.

5. Se verifică disponibilitatea lățimii de bandă solicitată tunel la fiecare LSR intermediar, iar dacă solicitările sunt îndeplinite, ruterul egress transmite un mesaj RSVP de tip reply, înapoi, prin același tunel.

6. Având în vedere că mesajul RSVP primit de ruterul ingress este unul de tip de ACK, care îl asigură pe acesta că toate resursele necesare sunt alocate și rezervate la nivelul fiecărui LSR, se trece la alocarea etichetelor pentru tunel.

7. Valorile etichetelor sunt transmise către LSR prin intermediul unui mesaj RSVP.

8. Configurația tunelului trebuie să fie adăugate în tabela de rutare a ruterului înainte de a activa tunelul. Acum tunelul este pregătit pentru a fi utilizat, conform figurii 4.6, prezentată mai jos.

Fig. 4.6 Schema unui tunel TE varianta II

Acesta este operațiunea de bază a TE MPLS” [26].

Pentru a observa eficiența utilizării lățimii de bandă de către MPLS Traffic Engineering, voi prezenta un exemplu elocvent, în figura următoare.

––––––-> LSP 1 reprezintă traficul de la LSR 1 la LSR 3

––––––-> LSP 2 reprezintă traficul prin LSR 2

Fig. 4.7 TE într-un domeniu MLPS

În figura 4.7 sunt prezentate 3 LSR-uri, și anume, LSR 1, LSR2 și LSR 3. Pentru host-urile A, B, C și D. Putem presupune că ruterele sunt conectate printr-o conexiune de 100 Mbps.

În rețeaua teoretică astfel creată, perechile de comunicare sunt host-ul C către gazda host A, respectiv host-ul D către gazda host B. Ne asumăm faptul că traficul pentru ambele hosturi către linkurile lor stabilite au nevoie de 100 Mbps. Cu ajutorul capabilităților de rutare în MPLS, traficul de la hostul A la hostul C va fi dirijat prin prin LSP2 (LSR 1-LSR 2- LSR 3), iar traficul de la hostul B la hostul D, prin LSP 1 (LSR 1- LSR 3).

Din exemplul de mai sus concluzionăm că traficul este uniform distribuit prin rute multiple, prin intermediul capabilităților de rutare MPLS. Traficul poate fi dirijat prin rețea conform necesităților sale, cum ar fi parametrii lățimii de bandă, stabilirea diferitelor ordini ale LSP-urilor pentru eficientizarea resurselor alocate, precum și pentru realizarea unor performanțe înalte în rețea.

„Caracteristici TE-RSVP sunt robuste și oferă capabilități semnificative în contextul implementării Traffic Engineerig în domenii MPLS. Acestea includ:

– QoS și parametrii de trafic pentru gestionarea eficientă a traficului;

– mesaj de alertă la imposibilitatea stabilirii unui LSP sau pierderea unuia deja existent;

– Loop detection – necesar pentru LSP-uri slab dirijate și utilizat pentru restabilirea căii;

– suport Multi Protocol – suportă orice tip de protocol;

– management pentru LSP-uri;

– Record Route Objects;

– Path Pre-emption – posibilitatea de întrerupere a unei căi existente, pentru a stabili un tunel cu prioritate mai mare”[27].

4.2.2.4 Modul de realizare a distribuției informațiilor MPLS TE

După activarea TE în cadrul unei rețele, ruterele din zonă trebuie să primească informațiile cu privire la starea linkurilor prin intermediul unui protocol link state de tip Interior Gateway Protocol. Informațiile cu privire la topologia rețelei nu pot fi transmise decât prin intermediul unui protocol de acest tip. Starea legăturilor aferentă unui ruter este disipată către toate ruterele prezente în rețea. Astfel, ruterele prezente în rețea pot alege rute alternative de transmitere a pachetelor. Diferența dintre un protocol IGP și unul distance vector este că cel din urmă nu poate distribui starea legăturilor către toate ruterele prezente, rezultând alterarea informațiilor cu privire la rutele alternative. Protocolul distance vector este capabil să aleagă doar cea mai bună cale, potrivit tabelei de rutare.

După cum am menționat și în subcapitolul precedent, informațiile cu privire la topologia rețelei și a constrângerilor linkurilor sunt stocate la nivelul ruterului head end din cadrul tunelului TE.

Informațiile TE distribuite de către protocolul link state sunt:

– metrica TE (este utilizată pentru elaborarea unei topologii TE, diferită de cea IP);

– lățimea de bandă maximă (reprezintă lățimea de bandă maximă a linkului);

– lățimea de bandă care a fost rezervată (reprezintă lățimea de bandă disponibilă pentru TE la nivelul unui link);

– lățimea de bandă care nu a fost rezervată (reprezintă lățimea de bandă rămasă disponibilă pentru TE la nivelul unui link);

– grupul administrativ (reprezintă un câmp de 32 de biți, iar configurația optimă a acestuia poate fi stabilită de către un administrator de rețea).

CONCLUZII

MPLS este o tehnologie extrem de utilă, care simplifică infrastructura rețelelor, permițând consolidarea multiplelor tehnologii și aplicații, cum ar fi voce, video și de date. MPLS oferă securitate îmbunătățită, scalabilitate și disponibilitate ridicată.

„Beneficiul real al tehnologiei MPLS este că oferă o separare distinctă între procesul de rutare (control) și procesul de forwarding (transferul pachetelor). Această separare permite dezvoltarea unei singur algoritm de forwarding –MPLS–, care poate fi folosit pentru multiple servicii și tipuri de trafic. În viitor, infrastructura MPLS poate rămâne la fel, în timp ce noile servicii sunt construite prin simpla schimbare a modului în care pachetele sunt atribuite unui LSP. De exemplu, pachetele pot fi atribuite unui LSP bazat pe o combinație de subrețele destinație și tip de aplicației, o combinație între sursa și destinația subrețelelor, o cerință specific QoS, un grup IP multicast sau un VPN. În acest fel, noile servicii pot migra în vederea operării pe infrastructuri MPLS comune”[28].

În economia de piață, cele mai importante obiective pentru furnizorii de servicii și Purtătorii sunt:

• reducerea costurilor de operare;

• păstrarea serviciilor existente

• introducerea de noi servicii în mod eficient.

Tehnologia MPLS ți-a dovedit valoarea pentru furnizarea de noi servicii, în același timp, permițând migrarea către noile tipuri de rețea. Prin realizarea convergenței în rețelele MPLS, furnizorii și operatorii de transport pot fi mai eficienți, realizând totodată și mari economii în costurile de operare. Ca urmare, MPLS poate fi implementar în rețelele din întreaga lume, devenind un standard în tehnologie, coloană vertebrală pentru rețelele convergente.

Cu toate acestea, MPLS s-a dovedit a fi o tehnologie extrem de complexă, cuprinzând o gamă largă funcționalități și aplicații. Dezvoltatorii tehnologiei MPLS, precum și clienții care doresc să implementeze MPLS, trebuie să ia în considerare complexitatea tehnologiei, permanenta evoluție, precum și impactul acesteia asupra performanțelor rețelei și a scalabilității.

Pentru a gestiona complexitatea MPLS, o gamă largă de protocoale, servicii, aplicații, și infrastructuri hardware necesită operațiuni de testare și, ulterior, de validare, fiind cruciale pentru succesul tehnologiei MPLS.

BIBLIOGRAFIE

[1] prof. dr. Zota Răzvan – Rețele de calculatoare, Academia de Studii Economice București, Facultatea de cibernetică, statistică și informatică economică, curs 2012;

[2]Tehnici avansate în rețelele de comunicații, Universitatea Politehnică Timișoara, Facultatea de Electronică și comunicații, curs 2012;

[3] conf. dr. Dan Mancaș – Administrarea rețelelor de calculatoare, Universitatea din Craiova, Facultatea de automatică, calculatoare și electronică, curs 2013;

[4] prof. Borcoci Eugen – Comunicații de bandă largă și multimedia, Universitatea Politehnică București, Facultatea de electronică și telecomunicații, curs 2012;

[5] Pepelnjak I., Guichard J. – Multiprotocol Label Switching and Virtual Private Networks, Cisco Press, 2000;

[6] Andrew S. Tanenbaum – Rețele de calculatoare, ediția a-3-a revizuită, Ed. Agora, 1998;

[7] conf. dr. ing. Scripcariu Luminița – Bazele rețelelor de calculatoare, Editura CERMI, 2005;

[8] Rughiniș, R., Deaconescu, R., Ciorba, A., Doinea, B. – Rețele locale, București, Editura Printech, 2009;

[9] Răzvan Rughiniș – Proiectarea rețelelor, București, Editura Printech, 2009;

[10] Protocoale de rutare – http://ro.wikipedia.org/wiki/Rutare;

[11] RFC 1058 – Routing Information Protocol, https://tools.ietf.org/html/rfc1058;

[12] Uyless Black – IP Routing Protocols RIP, OSPF, BGP, PNNI & CISCO Routing Protocols, 2000;

[13] Dhiman D. Chowdhury – Unified IP Internet – Working, 2001;

[14] Ina Minei, Julian Lucek – MPLS – Enabled Applications, Emerging Developments and new technologies, 2010<

[15] Luc De Ghein – MPLS Fundamentals, Cisco Press, 2007;

[16] Sean J. Harnedy – The MPLS Primer: An Introduction to Multiprotocol Label Switching, 2002;

[17] Cisco Systems – Implementing Cisco MPLS ,MPLS VPN Technology, https://learningnetwork.cisco.com/servlet/JiveServlet/download/16346-1-60731/MPLS-VPN-Technology.pdf, 2002;

[18] H. Jeng, R. Bonica, Y. Rekhter L3VPN Routing Working Group https://datatracker.ietf.org/meeting/88/agenda/l3vpn-drafts.pdf, 2013;

[19] Chris Lewis, Steve Pickavance – Selecting MPLS VPN Services (Networking Technology), 2006;

[20] Chuck Semeria – RFC 2547bis – BGP/MPLS VPN Fundamentals, 2001, http://www.nationalcommunicationsgroup.com/white_papers/mpls/RFC_2547.pdf;

[21] Cisco Systems – Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide, Release Implementing Point to Point Layer 2 Services, 2012;

[22] Cisco Systems – Cisco Software Configuration GuideVirtual Private LAN Services (VPLS), 2013, http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/ configuration/ guide/15_0_sy_swcg/vpls.pdf;

[23] Lobo L.,  Lakshman U. – MPLS Configuration on Cisco Software VPLS Topology-Single PE or Direct Attachment,  http://flylib.com/books/en/2.686.1.86/1/;

[24] International Engineering Consortium – White Papers: Multiprotocol Label Switching (MPLS), http://www.iec.org/online/tutorials/mpls/index.html;

[25] Cisco Systems – Advanced Topics in MPLS-TE Deployment, Multiprotocol Label Switching Traffic Engineering, 2009;

[26] Umesh Lakshman, Lancy Lobo – MPLS Traffic Engineering, Cisco Press, 2006

[27] D Aweduche, L Berger, D Gan, T Li, G Swallow and V Srinivasan – RSVP-TE Extensions to RSVP for LSP Tunnels”, RFC 3209, December 2001;

[28] Chuck Semeria – Traffic Engineering for the New Public Network, 1999, http://www.fe.up.pt/~jruela/DOC/TE_NPN.pdf;

BIBLIOGRAFIE

[1] prof. dr. Zota Răzvan – Rețele de calculatoare, Academia de Studii Economice București, Facultatea de cibernetică, statistică și informatică economică, curs 2012;

[2]Tehnici avansate în rețelele de comunicații, Universitatea Politehnică Timișoara, Facultatea de Electronică și comunicații, curs 2012;

[3] conf. dr. Dan Mancaș – Administrarea rețelelor de calculatoare, Universitatea din Craiova, Facultatea de automatică, calculatoare și electronică, curs 2013;

[4] prof. Borcoci Eugen – Comunicații de bandă largă și multimedia, Universitatea Politehnică București, Facultatea de electronică și telecomunicații, curs 2012;

[5] Pepelnjak I., Guichard J. – Multiprotocol Label Switching and Virtual Private Networks, Cisco Press, 2000;

[6] Andrew S. Tanenbaum – Rețele de calculatoare, ediția a-3-a revizuită, Ed. Agora, 1998;

[7] conf. dr. ing. Scripcariu Luminița – Bazele rețelelor de calculatoare, Editura CERMI, 2005;

[8] Rughiniș, R., Deaconescu, R., Ciorba, A., Doinea, B. – Rețele locale, București, Editura Printech, 2009;

[9] Răzvan Rughiniș – Proiectarea rețelelor, București, Editura Printech, 2009;

[10] Protocoale de rutare – http://ro.wikipedia.org/wiki/Rutare;

[11] RFC 1058 – Routing Information Protocol, https://tools.ietf.org/html/rfc1058;

[12] Uyless Black – IP Routing Protocols RIP, OSPF, BGP, PNNI & CISCO Routing Protocols, 2000;

[13] Dhiman D. Chowdhury – Unified IP Internet – Working, 2001;

[14] Ina Minei, Julian Lucek – MPLS – Enabled Applications, Emerging Developments and new technologies, 2010<

[15] Luc De Ghein – MPLS Fundamentals, Cisco Press, 2007;

[16] Sean J. Harnedy – The MPLS Primer: An Introduction to Multiprotocol Label Switching, 2002;

[17] Cisco Systems – Implementing Cisco MPLS ,MPLS VPN Technology, https://learningnetwork.cisco.com/servlet/JiveServlet/download/16346-1-60731/MPLS-VPN-Technology.pdf, 2002;

[18] H. Jeng, R. Bonica, Y. Rekhter L3VPN Routing Working Group https://datatracker.ietf.org/meeting/88/agenda/l3vpn-drafts.pdf, 2013;

[19] Chris Lewis, Steve Pickavance – Selecting MPLS VPN Services (Networking Technology), 2006;

[20] Chuck Semeria – RFC 2547bis – BGP/MPLS VPN Fundamentals, 2001, http://www.nationalcommunicationsgroup.com/white_papers/mpls/RFC_2547.pdf;

[21] Cisco Systems – Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide, Release Implementing Point to Point Layer 2 Services, 2012;

[22] Cisco Systems – Cisco Software Configuration GuideVirtual Private LAN Services (VPLS), 2013, http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/ configuration/ guide/15_0_sy_swcg/vpls.pdf;

[23] Lobo L.,  Lakshman U. – MPLS Configuration on Cisco Software VPLS Topology-Single PE or Direct Attachment,  http://flylib.com/books/en/2.686.1.86/1/;

[24] International Engineering Consortium – White Papers: Multiprotocol Label Switching (MPLS), http://www.iec.org/online/tutorials/mpls/index.html;

[25] Cisco Systems – Advanced Topics in MPLS-TE Deployment, Multiprotocol Label Switching Traffic Engineering, 2009;

[26] Umesh Lakshman, Lancy Lobo – MPLS Traffic Engineering, Cisco Press, 2006

[27] D Aweduche, L Berger, D Gan, T Li, G Swallow and V Srinivasan – RSVP-TE Extensions to RSVP for LSP Tunnels”, RFC 3209, December 2001;

[28] Chuck Semeria – Traffic Engineering for the New Public Network, 1999, http://www.fe.up.pt/~jruela/DOC/TE_NPN.pdf;