Wieloprotokołowa komutacja etykietowa (MPLS) i jej rola w zapewnianiu jakości usług w sieciach IP

Rafa³ STANKIEWICZ*, Andrzej JAJSZCZYK* Wieloprotokołowa komutacja etykietowa (MPLS) i jej rola w zapewnianiu jakości usług w sieciach IP * Katedra Telekomunikacji, Akademii Górniczo Hutniczej w Krakowie, <nazwisko>@kt.agh.edu.pl Obserwuj¹c obecne trendy, nale y spodziewaæ siê, e w przysz³ych sieciach wielous³ugowych bêdzie powszechnie stosowany protokó³ IP. Jest oczywiste, e protokó³ ten w obecnej postaci nie jest w stanie sprostaæ rosn¹cym wymaganiom dotycz¹cym jakoœci us³ug. Zainteresowanie aplikacjami wymagaj¹cymi wysokiego i sta³ego poziomu QoS (Quality of Service) jest coraz wiêksze. Dlatego te przysz³e sieci IP musz¹ zostaæ rozszerzone o mechanizmy sterowania jakoœci¹ us³ug. Intensywne prace prowadzone przez IETF (Internet Engineering Task Force) doprowadzi³y do opracowania modeli IntServ i DiffServ [12]. Modele te nie rozwi¹zuj¹ jednak problemów wynikaj¹cych z nieefektywnoœci regu³ doboru trasy w sieci IP. Jednym z najnowszych rozwi¹zañ jest te technika wieloprotoko³owej komutacji etykietowej MPLS (MultiProtocol Label Switching). Podstawowym za³o eniem techniki MPLS by³o uproszczenie mechanizmów przekazywania pakietów w ruterach. Du e nadzieje wi¹ e siê z MPLS w zakresie in ynierii ruchu oraz wsparcia dla wirtualnych sieci prywatnych (Virtual Private Network). Jednak e MPLS jest czêsto nies³usznie traktowany jako jedna z technik rozwi¹zuj¹cych problemy zapewnienia jakoœci obs³ugi 251

i stawiany na równi z modelami IntServ lub DiffServ. W rzeczywistoœci protokó³ ten dostarcza jedynie odpowiednie mechanizmy u³atwiaj¹ce zapewnienie jakoœci obs³ugi. Mo e byæ miêdzy innymi stosowany do równowa enia obci¹ enia w sieci, sterowania przep³ywem, czy te zestawiania tuneli. Jedn¹ z najbardziej wartoœciowych cech techniki MPLS jest mo liwoœæ kierowania ruchu przez wybrane wêz³y (explixit routing). MPLS nie jest jednak wyposa ony w mechanizmy sterowania parametrami QoS. Ponadto zwykle nie dzia³a w relacji od koñca do koñca (end-to-end) i w przysz³oœci prawdopodobnie nie bêdzie wdro ony we wszystkich obszarach sieci IP. Stoi to w sprzecznoœci z podstawowym wymaganiem zapewnienia jakoœci us³ug w relacji od koñca do koñca. Dlatego te technika MPLS powinna byæ stosowana w po³¹czeniu z istniej¹cymi technikami wspieraj¹cymi zapewnianie jakoœci us³ug w sieciach IP (model IntServ lub DiffServ). Z drugiej strony protokó³ MPLS zapewnia rozszerzenie mo liwoœci modeli IntServ i DiffServ. Umo liwia miêdzy innymi wspó³pracê z wieloma protoko³ami sieciowymi. Dziêki temu pracuj¹ce w sieci IP protoko³y RSVP i DiffServ mog¹ byæ równie tunelowane w sieciach ATM czy FR. Mechanizmy zapewniania jakoœci obs³ugi mog¹ wiêc funkcjonowaæ poza œrodowiskiem sieci IP. W artykule przedstawiono najwa niejsze za³o enia techniki MPLS oraz bie ¹cy stan prac maj¹cych na celu opracowanie standardów wspó³pracy MPLS z modelami IntServ i DiffServ. TECHNIKA KOMUTACJI ETYKIETOWEJ MPLS Technika wieloprotoko³owej komutacji etykietowej MPLS jest jednym z nowszych zestawów protoko³ów opracowanych przez IETF [14]. Podstawowym za³o eniem protoko³u MPLS jest uproszczenie mechanizmów przekazywania pakietów w wêz³ach sieci. Jego koncepcja wywodzi siê z doœwiadczeñ protoko³u IP oraz techniki ATM. Jedn¹ z wad tradycyjnego protoko³u IP s¹ z³o one procedury wyboru dróg przesy³ania pakietów. W ka dym wêÿle jest podejmowana decyzja o wyborze nastêpnego odcinka drogi pakietu. Niezbêdna jest analiza relatywnie du ego nag³ówka pakietu oraz zastosowanie skomplikowanego algorytmu rutingu. Wad¹ tego rozwi¹zania jest koniecznoœæ przetwarzania du ej iloœci danych, co wymaga znacznych mocy obliczeniowych ruterów. Ponadto nag³ówek pakietu zawiera zwykle wiêcej informacji ni jest potrzebne do podjêcia decyzji o tym, gdzie nale y przes³aæ pakiet. Co wiêcej, regu³y doboru trasy w sieci IP s¹ nieefektywne. Pakiety przesy³a siê najkrótsz¹ drog¹, co mo e powodowaæ przeci¹ enie niektórych odcinków sieci przy jednoczesnym niewykorzystaniu innych. W protokole MPLS ka dy pakiet wchodz¹cy do sieci jest przydzielany do klasy równowa noœci przekazywania FEC (Forwarding Equivalence Class) na podstawie analizy nag³ówka. Ka dy pakiet otrzymuje etykietê (label) odpowiadaj¹c¹ danej klasie równowa noœci. Przydzielenie pakietu do klasy FEC odbywa siê tylko raz, w chwili wejœcia do domeny MPLS. W kolejnych wêz³ach sieci nie jest konieczne analizowanie nag³ówka pakietu, a decyzja o wyborze nastêpnego odcinka drogi jest dokonywana na podstawie etykiety. Etykieta ma znaczenie lokalne. Jest to identyfikator o sta³ej d³ugoœci, jednoznacznie identyfikuj¹cy klasê równowa noœci miêdzy dwoma wêz³ami dla okreœlonego kierunku transmisji. W ka dym ruterze LSR (Label Switch Router) znajduje siê tablica kierowania. Na podstawie etykiety, z jak¹ zosta³ przekazany pakiet, jest podejmowana decyzja, z jak¹ etykiet¹ i przez który interfejs nale y go przes³aæ dalej. Przed wys³aniem pakietu dotychczasowa etykieta jest zamieniana na now¹. W sieci MPLS etykieta jest 20-bitowym polem 32-bitowego nag³ówka dodawanego do pakietu IP. Strukturê nag³ówka MPLS przedstawiono na rys. 1. Oprócz etykiety, w jego sk³ad wchodz¹: M 3-bitowe pole Exp, opisane w dokumencie [13] jako zarezerwowane do celów eksperymentalnych, M bit S oznaczaj¹cy dno stosu etykiet, M 8-bitowe pole TTL (Time to Live). Pole Exp zosta³o przewidziane do ró nicowania jakoœci us³ug. Pozwala oznaczyæ pakiety nale ¹ce do oœmiu ró nych klas us³ug. W czasie gdy opracowywane by³y podstawy protoko³u MPLS, wydawa³o siê to wystarczaj¹ce. Jednoczeœnie by³a silna tendencja do utrzymania mo liwie prostej struktury nag³ówka i jego ograniczonej d³ugoœci. St¹d wynika 3-bitowa d³ugoœæ pola Exp. W technice MPLS dopuszcza siê mo liwoœæ nadawania pakietowi kolejnych etykiet, które s¹ uporz¹dkowane w formie stosu. Je eli pakiet ma tylko jedn¹ etykietê, jest to etykieta poziomu pierwszego. Nastêpnie mog¹ byæ dodawane etykiety drugiego poziomu, trzeciego itd. Rutery analizuj¹ i wykonuj¹ operacje zawsze na etykiecie najwy szego poziomu. Etykieta mo e byæ zdjêta ze stosu lub zamieniona na inn¹. Mo e te zostaæ dodana etykieta wy szego poziomu. Mechanizm ten znajduje zastosowanie przy tworzeniu tuneli, o czym bêdzie mowa dalej. Bit S nag³ówka MPLS s³u y do oznaczenia dna stosu. Jest ustawiony na 1 w przypadku etykiety pierwszego poziomu lub na 0 w pozosta- ³ych przypadkach. W praktyce, przez po³o enie nastêpnej etykiety na stos, nale y rozumieæ dodanie kolejnego nag³ówka MPLS. Pole TTL jest odpowiednikiem pola o tej samej nazwie przenoszonego w nag³ówku IP. Jego wartoœæ jest zmniejszana o 1 na ka dym odcinku drogi pakietu. W protokole MPLS stosuje siê je miêdzy innymi do zabezpieczenia przed powstawaniem pêtli. Je eli pomiêdzy dwoma ruterami istnieje powi¹zanie danej klasy FEC z okreœlon¹ etykiet¹, to w odniesieniu do tego powi¹zania ruter, który u ywa tej etykiety jako wychodz¹cej (outgoing label) jest nazywany ruterem poprzednim (upstream ruter), zaœ ruter u ywaj¹cy jej jako przychodz¹cej (incoming label) jest nazywany ruterem nastêpnym (downstream ruter) (rys.). Ci¹g takich powi¹zañ dla danej klasy FEC tworzy œcie kê komutowan¹ etykietowo LSP (Label Switched Path). Pakiety nale ¹ce do tej samej klasy równowa noœci FEC s¹ wiêc przesy³ane t¹ sam¹ œcie k¹ LSP i traktowane w taki sam sposób. W ka dej œcie ce mo na wyró niæ dwa rutery brzegowe (wejœciowy i wyjœciowy) oraz rutery poœrednie. Z punktu widzenia transmisji pakietów u ytkownika œcie ka LSP jest jednokierunkowa. Wyró nia siê jednak dwa kierunki transmisji informacji sygnalizacyjnej (rys.): O Rys. 1. Struktura nagłówka MPLS [13] O Rys. 2. Przesyłanie pakietu w sieci MPLS, zamiana etykiet 252

M w dó³ (downstream), czyli zgodny z kierunkiem przesy³ania danych oraz M w górê (upstream), czyli przeciwny do kierunku przesy³ania danych. Opisan¹ zasadê dzia³ania przedstawiono na rys. 2. Pakiety nale ¹ce do klasy FEC L s¹ przesy³ane z rutera LSR1 do LSR2 z etykiet¹ 7. W odniesieniu do tego powi¹zania LSR1 jest ruterem poprzednim, zaœ LSR2 ruterem nastêpnym. W ruterze LSR2, po znalezieniu odpowiedniego wpisu w tablicy kierowania, etykieta 7 jest zamieniana na 5 i pakiet jest wysy³any dalej. Tablica kierowania jest w praktyce nieco bardziej z³o ona ni przedstawiono to na rys. 2. Ka da para: etykieta przychodz¹ca interfejs wejœciowy mo e byæ odwzorowywana na jedn¹ lub wiêcej par, zaœ etykieta wychodz¹ca interfejs wyjœciowy. Ta cecha protoko³u umo liwia miêdzy innymi równowa enie obci¹- enia (load balancing) przez kierowanie ruchu na kilka ³¹czy oraz tworzenie œcie ek typu punkt-wielopunkt, o czym bêdzie mowa dalej. Poniewa decyzje wewn¹trz sieci MPLS s¹ podejmowane wy³¹cznie na podstawie etykiety, nie ma znaczenia, jakiego typu pakiet jest przenoszony. Jak ju wspomniano, pozwala to na wspó³pracê z wieloma protoko³ami sieciowymi. Ponadto umo liwia szyfrowanie ca³ych pakietów (³¹cznie z nag³ówkiem) przy wejœciu do sieci, co powa nie utrudnia okreœlenie, sk¹d pochodz¹ i dok¹d s¹ kierowane dane. Chroni to przed skutkami pods³uchu w sieci szkieletowej, a wiêc zwiêksza bezpieczeñstwo sieci. Protokó³ MPLS poza œrodowiskiem sieci IP Protokó³ MPLS mo e byæ stosowany poza œrodowiskiem sieci IP. W ramach IETF zosta³y opracowane odpowiednie dokumenty okreœlaj¹ce zasady wspó³pracy MPLS z technik¹ ATM [5] i protoko³em FR [4]. W ³¹czach tego typu, gdzie nie jest stosowany protokó³ IP, nie u ywa siê omówionego wy ej nag³ówka MPLS. Etykiety s¹ natomiast przenoszone odpowiednio w polach VPI/VCI nag³ówka ATM lub w polu DLCI nag³ówka FR. Prze³¹czniki ATM, po niezbêdnym rozszerzeniu oprogramowania, pe³ni¹ dodatkowo funkcjê ruterów LSR. S¹ wówczas zwane ruterami ATM LSR. Podobnie prze³¹czniki FR mog¹ pe³niæ funkcjê ruterów FR LSR. W ramach IETF opracowano te podstawy uogólnionej wieloprotoko³owej komutacji etykietowej GMPLS (Generalized MPLS). Za³o eniem tej koncepcji jest dostosowanie protoko³ów Internetu do realizacji funkcji niezbêdnych do sterowania sieci¹ optyczn¹ OTN [11]. Zaproponowano rozszerzenie funkcjonalnoœci ruterów LSR o mo liwoœæ przekazywania ruchu na podstawie uogólnionej etykiety odwzorowuj¹cej pozycjê szczeliny czasowej, noœn¹ optyczn¹ lub numer portu fizycznego. dwie metody przydzielania etykiet: niezamówiona (unsolicited downstream) oraz na ¹danie (downstream-on-demand). W pierwszym przypadku ruter nastêpny LSR N samodzielnie podejmuje decyzjê o powi¹zaniu klasy FEC z etykiet¹ przychodz¹c¹ i wysy³a informacjê o tym powi¹zaniu do wêz³a poprzedniego. Zestawienie odcinka œcie ki LSP jest wiêc inicjowane z do- ³u. W metodzie na ¹danie ruter poprzedni LSR P mo e ¹daæ od rutera nastêpnego przydzielenia etykiety dla okreœlonej klasy FEC. Przydzielanie etykiet jest wiêc równie dokonywane z do- ³u, jednak e inicjowane jest z góry. Protokó³ MPLS definiuje dwa style rozsy³ania etykiet: niezale - ny (independent) oraz uporz¹dkowany (ordered). W przypadku stylu niezale nego ka dy ruter LSR mo e niezale nie dokonywaæ powi¹zania etykiet przychodz¹cych i klas FEC oraz rozsy³aæ informacjê o tych powi¹zaniach do ruterów s¹siednich ( poprzednich w odniesieniu do danego powi¹zania). Ruter nie znaj¹c etykiety wychodz¹cej, a wiêc nie znaj¹c rutera nastêpnego dla danej klasy FEC, mo e rozsy³aæ powi¹zanie do swoich poprzedników. W sieci mog¹ wiêc powstawaæ fragmenty niepowi¹zanych ze sob¹ œcie ek, zaœ rutery mog¹ przesy³aæ pakiety zanim œcie - ka LSP zostanie w pe³ni zestawiona. W stylu uporz¹dkowanym ruter LSR mo e przydzieliæ etykietê dla danej klasy równowa noœci FEC tylko w jednym z dwóch przypadków: M gdy otrzyma³ wczeœniej informacjê o powi¹zaniu etykiety z t¹ klas¹ FEC od wêz³a nastêpnego lub M gdy jest ruterem brzegowym œcie ki LSP dla tej klasy FEC. Styl ten zapewnia zestawienie kompletnej œcie ki LSP przed rozpoczêciem wysy³ania pakietów. Stosowanie tego stylu jest konieczne, gdy istnieje potrzeba zestawienia œcie ki o okreœlonych w³aœciwoœciach. Ruter LSR mo e obs³ugiwaæ tylko jeden styl rozsy³ania etykiet. Jednak e ró ne rutery mog¹ stosowaæ ró ne style i wspó³pracowaæ ze sob¹. Oba style rozsy³ania etykiet mog¹ byæ stosowane w po³¹czeniu z obiema metodami przydzielania etykiet. Œcie ki LSP typu wielopunkt-punkt Standard MPLS dopuszcza mo liwoœæ tworzenia œcie ek o architekturze odwróconego drzewa (wielopunkt punkt). Jest to u yteczne w przypadku, gdy pakiety wchodz¹ce do domeny MPLS w ró nych wêz³ach mog¹ byæ zakwalifikowane do tej samej klasy równowa noœci i bêd¹ opuszczaæ domenê w tym samym wêÿle wyjœciowym. Pakiety, które zosta³y wprowadzone do domeny MPLS w ró nych wêz³ach, s¹ nierozró nialne. Podejœcie takie pozwala na bardziej efektywne wykorzystanie puli dostêpnych etykiet i uproszczenie tablic kierowania. W uproszczeniu zilustrowano to na przyk³adzie (rys. 3). Za³ó my, e pakiety wchodz¹ce do domeny MPLS w ruterach LSR1 i LSR4 s¹ przydzielane do tej samej klasy równowa noœci A. W celu zestawienia œcie ki wyjœciowy ruter brzegowy LSR3 przydziela dla klasy FEC Przydzielanie i rozsy³anie etykiet Aby zestawiæ œcie kê LSP jest konieczne utworzenie powi¹zania miêdzy dan¹ klas¹ FEC a etykietami w ka dym ruterze nale- ¹cym do zestawianej œcie ki. Dlatego te jednym z najistotniejszych problemów jest zdefiniowanie sposobów przydzielania i rozsy³ania etykiet. Jednym z zaproponowanych rozwi¹zañ jest protokó³ LDP (Label Distribution Protocol) [1]. W protokole MPLS przydzielenie etykiety dla danej klasy FEC jest dokonywane zawsze przez ruter nastêpny, a informacja o tym powi¹zaniu jest przesy³ana w górê do rutera poprzedniego. Dopiero po otrzymaniu tego powi¹zania ruter poprzedni wie, który wêze³ jest ruterem nastêpnym dla danej œcie ki LSP i z jak¹ etykiet¹ nale y wysy³aæ do niego pakiety. Mo liwe s¹ O Rys. 3. Ścieżka LSP typu wielopunkt punkt 253

A etykietê 8 i przesy³a to powi¹zanie do rutera LSR2. Nastêpnie ruter LSR2 przydziela etykietê przychodz¹c¹ 4 i rozsy³a informacjê o tym powi¹zaniu do obu ruterów (LSR1 i LSR4), z których bêdzie odbiera³ pakiety nale ¹ce do tej klasy. Pakiety dochodz¹ce do rutera LSR2 zarówno z rutera LSR1, jaki LSR4, bêd¹ wiêc mia³y tê sam¹ etykietê. Nastêpnie bêd¹ wysy³ane wspóln¹ czêœci¹ œcie ki do rutera LSR3. Agregacja œcie ek LSP W sieci MPLS wiele œcie ek utworzonych dla ró nych klas równowa noœci przekazywania mo e czêœciowo lub w ca³oœci siê pokrywaæ. Je eli kilka œcie ek ma wspólny wyjœciowy ruter brzegowy oraz wspólny koñcowy odcinek œcie ki, to istnieje mo liwoœæ zagregowania tych œcie ek w jedn¹ (rys. 4). Tworzona jest tzw. unia klas FEC, dla której przydziela siê jedn¹ etykietê. Z punktu O Rys. 4. Agregacja ścieżek i klas równoważności przekazywania FEC: a) dwie oddzielne ścieżki LSP dla dwóch klas FEC, b) ścieżka zagregowana widzenia systemu unia klas jest traktowana jak pojedyncza klasa FEC i nie ma mo liwoœci odró nienia pakietów pochodz¹cych z ró nych klas sk³adowych. Uogólniaj¹c, mo na zagregowaæ dowoln¹ liczbê N klas FEC do dowolnej liczby M unii [14]. Podejœcie takie pozwala efektywniej wykorzystywaæ pulê etykiet w ruterach, zmniejszyæ ruch sygnalizacyjny zwi¹zany z przydzielaniem i rozsy³aniem etykiet, jak równie uproœciæ tablice kierowania. szczególnym przypadkiem œcie ki komutowanej etykietowo. Wszystkie pakiety przesy³ane w tunelu s¹ traktowane jako jedna klasa FEC. W momencie wejœcia pakietów do tunelu do ich stosu etykiet jest dodawana etykieta wy szego poziomu. Dziêki temu mechanizmowi przez jeden tunel mo e przebiegaæ kilka œcie- ek LSP. Jednoczeœnie informacja o przynale noœci pakietów do poszczególnych klas nie jest tracona. Przed opuszczeniem tunelu etykieta wy szego poziomu jest zdejmowana, zaœ pakiety opuszczaj¹ce tunel znów s¹ rozró niane i przesy³ane dalej odpowiednimi œcie kami. Pozwala to na zagregowanie na pewnym odcinku kilku klas FEC. Zasadê funkcjonowania tunelu przedstawiono na rysunku 5. Œcie ka LSP przebiega kolejno przez rutery LSR1, LSR2, LSR3, LSR4, LSR5. Nale y zauwa yæ, e rutery LSR3 i LSR4 nie s¹ po³¹czone bezpoœrednio, lecz za poœrednictwem tunelu LSP, którego koñce stanowi¹. Tunel LSP sk³ada siê z ruterów LSR3, LSR31, LSR32 oraz LSR4. Ruter LSR3 ma w tablicy kierowania wpis, z którego wynika, e pakiety przychodz¹ce z etykiet¹ 5 maj¹ byæ kierowane do rutera LSR4 z etykiet¹ 2. W pierwszej kolejnoœci nastêpuje wiêc zamiana etykiety. Poniewa pomiêdzy ruterami LSR3 i LSR4 znajduje siê tunel LSP, pakiety musz¹ byæ przes³ane do rutera LSR31. Dlatego te w ruterze LSR3, bêd¹cym zarazem pocz¹tkiem tunelu, do stosu jest dodawana etykieta 7. Jest to etykieta drugiego poziomu. Ruter LSR31 zamienia etykietê przychodz¹c¹ 7 na etykietê wychodz¹c¹ 6 i przesy³a pakiet do rutera LSR32. Ruter LSR32, który jest przedostatnim wêz³em w tunelu, œci¹ga ze stosu etykietê drugiego poziomu i wysy³a do ostatniego wêz³a pakiet tylko z etykiet¹ poziomu pierwszego. Dziêki temu ruter LSR4 otrzymuje pakiety z etykiet¹ 2, tak jakby wys³a³ je bezpoœrednio ruter LSR3. Je eli przez tunel przebiega kilka œcie ek, to ostatni ruter w tunelu rozró nia pakiety do nich nale ¹ce i nastêpnie kieruje je do odpowiednich wêz³ów. Uzgadnianie etykiet na poszczególnych poziomach odbywa siê niezale nie. Z punktu widzenia sygnalizacji, ruter LSR4 wysy- ³a informacjê o powi¹zaniach etykiet i klas równowa noœci bezpoœrednio do rutera LSR3. Niezale nie, na wy szym poziomie, uzgadnia siê etykiety pomiêdzy poszczególnymi ruterami tworz¹cymi tunel. Tunele LSP mog¹ byæ stosowane do agregowania œcie ek LSP na pewnych odcinkach, aby efektywniej gospodarowaæ zasobami etykiet. Tunelem LSP mo e byæ te œcie ka ATM ³¹cz¹ca dwa obszary sieci IP. Ponadto tunele znajduj¹ zastosowanie jako przezroczyste ³¹cza pomiêdzy dwoma obszarami sieci jednego operatora czy firmy. Z kolei operator danej domeny MPLS mo e skierowaæ przez tunel ca³y ruch tranzytowy pomiêdzy dwoma wêz³ami brzegowymi. Po³¹czenia punkt-wielopunkt Wsparcie protoko³u MPLS dla po³¹czeñ typu punkt-wielopunkt (multicast) jest zagadnieniem skomplikowanym. Wynika to miêdzy innymi z du ej ró norodnoœci istniej¹cych protoko³ów rutingu wielopunktowego. Powa nym problemem jest utworzenie œcie - ki LSP o architekturze drzewa punkt-wielopunkt. W protoko³ach, Zestawianie tuneli LSP Istotn¹ zalet¹ protoko³u MPLS jest te mechanizm zestawiania tuneli, które mog¹ byæ traktowane jako ³¹cza wirtualne pomiêdzy dwoma wêz³ami stanowi¹cymi koñce tunelu. Tunel LSP jest O Rys. 5. Zasada funkcjonowania tunelu LSP 254

w których drzewo jest budowane za pomoc¹ sygnalizacji, rozsy- ³anie etykiet mo e odbywaæ siê wraz z przesy³aniem komunikatów sygnalizacyjnych. Przyk³adowo, w protokole PIM SM (Protocol Independent Multicast Sparse Mode) etykiety mog¹ byæ umieszczane w komunikatach JOIN. Podejœcie takie wymaga jednak rozszerzenia protoko³ów rutingu o mechanizmy przenoszenia etykiet. Istniej¹ równie takie protoko³y, jak DVMRP (Distance-Vector Multicast Routing Protocol), w których drzewo typu punkt-wielopunkt jest tworzone wraz z przesy³aniem pakietów danych (nie s¹ przesy³ane komunikaty sygnalizacyjne). Konieczne jest wówczas zastosowanie osobnego protoko³u przydzielania i rozsy³ania etykiet, np. LDP. Rutery LSR musz¹ byæ wyposa one w mechanizmy umo liwiaj¹ce okreœlenie, do której œcie ki punkt-wielopunkt nale y przychodz¹cy pakiet. Ruter odbieraj¹cy pakiet powinien jednoznacznie zidentyfikowaæ jego nadawcê. W sieciach o architekturze po³¹czeñ punkt-punkt jest to automatyczne, gdy na danym interfejsie ruter nastêpny jest po³¹czony dok³adnie z jednym ruterem poprzednim. Problem pojawia siê w sieciach wielodostêpowych (takich jak Ethernet), gdzie wiele ruterów jest przy³¹czonych do wspólnego medium. Zwa ywszy, e pakiety s¹ rozró - niane jedynie na podstawie etykiety oraz interfejsu, przez który dotar³y do rutera, nie ma mo liwoœci okreœlenia nadawcy pakietu. Dlatego te jest konieczne podzielenie ca³ej puli etykiet pomiêdzy rutery, z których ka dy otrzymuje unikalny zbiór etykiet wychodz¹cych. Po otrzymaniu pakietu nale ¹cego do sesji typu punkt-wielopunkt ruter LSR znajduje w tablicy kierowania zbiór interfejsów, przez które pakiet bêdzie wys³any do nastêpnych wêz³ów drzewa oraz zbiór odpowiednich etykiet wychodz¹cych. W sieciach typu punkt-punkt przez jeden interfejs pakiety s¹ wysy³ane dok³adnie do jednego rutera nastêpnego. Zestawienie œcie ki punkt-wielopunkt jest wiêc stosunkowo ³atwe. Odpowiednie pary ruterów uzgadniaj¹ miêdzy sob¹ przydzia³ etykiety dla tej œcie ki, przy czym etykieta mo e zostaæ wybrana z ca³ej dostêpnej puli. W sieciach wielodostêpowych pakiet wys³any do wspólnego medium jest obierany przez wszystkie przy³¹czone do niego rutery. Rutery nale ¹ce do œcie ki powinny odebraæ pakiet i przes³aæ dalej, zaœ pozosta³e rutery musz¹ porzuciæ pakiet. Przyk³ad takiej sytuacji przedstawiono na rys. 6. Ruter LSR2 nale ¹cy do œcie ki LSP punkt-wielopunkt ma dwa rutery nastêpne : LSR4 i LSR5. Ponadto do wspólnego ³¹cza fizycznego s¹ przy³¹czone rutery LSR1 i LSR3. Wszystkie rutery bêd¹ otrzymywaæ pakiety wysy³ane przez ruter LSR2. Tylko rutery LSR4 i LSR5 mog¹ odbieraæ pakiety, zaœ rutery nie nale ¹ce do œcie ki powinny je odrzuciæ. Poniewa ruter poprzedni nie powiela pakietu, lecz wysy³a go raz z okreœlon¹ etykiet¹, wiêc wszystkie rutery nastêpne, nale ¹ce do œcie ki, musz¹ powi¹zaæ z t¹ œcie k¹ tak¹ sam¹ etykietê przychodz¹c¹. W praktyce jeden ruter nastêpny uzgadnia etykietê z ruterem poprzednim, zaœ kolejne rutery nastêpne przy³¹czaj¹ce siê do drzewa musz¹ podporz¹dkowaæ siê i korzystaæ z uzgodnionej etykiety. Rozwi¹zanie to, niestety, komplikuje proces zestawiania œcie ek LSP. Mimo prowadzonych na œwiecie prac, problem zapewnienia realizacji po³¹czeñ typu punkt-wielopunkt w sieciach MPLS nadal nie jest rozwi¹zany. Jednak e równie w tym zakresie z protoko³em MPLS wi¹ e siê du e nadzieje. Oczekuje siê znacznego uproszczenia i zwiêkszenia wydajnoœci istniej¹cych protoko- ³ów rutingu wielopunktowego. Niew¹tpliw¹ zalet¹ protoko³u MPLS jest mo liwoœæ realizowania po³¹czeñ wielopunktowych IP w œrodowisku ATM przy u yciu ruterów ATM-LSR. Eliminuje to wady skomplikowanego odwzorowywania protoko³u IP w sieci ATM. Dotychczasowe rozwi¹zania sieci IP na ATM nie pozwala- ³y na pe³n¹ wspó³pracê mechanizmów rutingu wielopunktowego stosowanych w tych dwóch technikach. WSPÓŁPRACA INTSERV I MPLS Wspó³praca modelu IntServ i protoko³u MPLS mo e przynieœæ wiele korzyœci. Z jednej strony wprowadza do sieci MPLS mechanizmy zapewniania jakoœci us³ug, z drugiej rozwi¹zuje niektóre problemy wynikaj¹ce z ograniczeñ modelu IntServ, jak np. skalowalnoœæ. Umo liwia zmniejszenie obci¹ enia ruterów zwi¹zanego z obs³ug¹ œcie ek zarezerwowanych oraz efektywniejsze wykorzystanie zasobów sieci. Istotnymi zaletami takiej wspó³pracy s¹ te : wprowadzenie do modelu IntServ mo liwoœci zestawiania œcie ek na z góry wybranej trasie oraz rozszerzenie zakresu stosowania modelu IntServ na obszary sieci, w których nie jest stosowany protokó³ IP. W praktyce realizacja wspó³pracy protoko³ów IntServ i MPLS wymaga rozszerzenia protoko³u RSVP, który jest w zasadzie jedynym protoko³em sygnalizacyjnym opracowanym w celu realizacji modelu us³ug zintegrowanych. Protokó³ RSVP powinien byæ przede wszystkim rozszerzony o mechanizmy zestawiania œcie ek komutowanych etykietowo (LSP). Jest to konieczne, gdy rutery LSR klasyfikuj¹ pakiety wy³¹cznie na podstawie etykiet (nie analizuj¹ nag³ówków pakietów). Musi wiêc istnieæ powi¹zanie miêdzy sesjami RSVP a zbiorem etykiet. W praktyce strumieñ pakietów podlegaj¹cych rezerwacji traktuje siê jako odrêbn¹ klasê równowa noœci przekazywania FEC, zaœ œcie ka zarezerwowana jest tunelowana w œcie ce komutowanej etykietowo. O Tabela 1. Definicja nowych obiektów protokołu sygnalizacyjnego RSVP Nazwa obiektu Komunikat Obowiązkowy / opcjonalny LABEL REQUEST PATH obowi¹zkowy LABEL RESV obowi¹zkowy EXPLICIT_ROUTE PATH opcjonalny RECORD_ROUTE PATH, RESV opcjonalny SESSION_ATRIBUTE PATH opcjonalny O Rys. 6. Połączenie typu punkt wielopunkt w łączu wielodostępo wym Zaproponowano rozszerzenie protoko³u RSVP o piêæ nowych obiektów (tabela) [2]. Obiekt LABEL_REQUEST s³u y do przes³ania do poszczególnych ruterów ¹dania przydzielenia etykiet dla zestawianej œcie ki. Komunikat RESV przenosi wartoœci przydzielanych etykiet u ywaj¹c obiektu LABEL. W sieciach MPLS istnieje mo liwoœæ zestawiania œcie ki na z góry wybranej trasie (w sieciach bez MPLS œcie ka jest zestawiana wy³¹cznie na trasie wybranej przez protoko³y rutingu). Aby zestawiæ tak¹ œcie kê, w komunikacie PATH musi byæ przes³any obiekt EXPLICIT_ROUTE. Zarówno odbiorca, jak i nadawca, mog¹ gromadziæ informacje o zestawionej œcie ce, przesy³aj¹c obiekt RECORD_ROUTE. Obiekt SESSION_ATRIBUTE jest u ywany do diagnostyki œcie ek. 255

Zestawianie œcie ki zarezerwowanej W procesie zestawiania œcie ki komutowanej etykietowo dla strumienia zarezerwowanego stosuje siê metodê przydzielania etykiet na ¹danie. ¹danie przydzielenia etykiety jest inicjowane przez wejœciowy ruter brzegowy domeny MPLS. Do komunikatu PATH jest dodawany nowy obiekt LABEL_REQUEST. Tak uzupe³niony komunikat PATH jest nastêpnie przesy³any przez kolejne wêz³y w kierunku odbiorcy. Przydzielanie etykiet nastêpuje (podobnie jak rezerwacja zasobów) na etapie przesy³ania komunikatu RESV. Do przes³ania wartoœci przydzielonej etykiety s³u y obiekt LABEL umieszczany wewn¹trz komunikatu RESV. Ruter LSR, oprócz typowych procedur rezerwacji, wpisuje w tablicy kierowania otrzyman¹ w komunikacie RESV etykietê jako wychodz¹c¹ oraz przydziela etykietê przychodz¹c¹, któr¹ nastêpnie umieszcza w komunikacie RESV wysy³anym do poprzedniego wêz³a. Ruter mo e przydzieliæ etykietê tylko z dostêpnej puli etykiet. Przyk³ad zestawiania œcie ki zarezerwowanej przedstawiono na rysunku. Przyjêto, e zarówno nadawca, jak i odbiorca, znajduj¹ siê poza domen¹ MPLS. Nadawca wysy³a komunikat PATH. Ruter brzegowy LSR1 dodaje do komunikatu PATH obiekt LA- BEL_REQUEST (rys. 7a) i przesy³a do wêz³a LSR2. Komunikat PATH jest dalej przesy³any do rutera LSR3, a nastêpnie do odbiorcy. Odbiorca odpowiada komunikatem RESV. Ruter brzegowy LSR3 przydziela etykietê przychodz¹c¹ 3 i wysy³a j¹ do rutera LSR2 w obiekcie LABEL w komunikacie RESV (rys. 7b). Ruter LSR2 wpisuje w tablicy kierowania otrzyman¹ etykietê jako wychodz¹c¹ i przydziela etykietê przychodz¹c¹ 8. Nastêpnie wysy³a komunikat RESV do rutera LSR1, umieszczaj¹c w obiekcie LABEL przydzielon¹ etykietê. W tablicy kierowania rutera LSR1 jest zapisywane powi¹zanie pomiêdzy adresem sesji RSVP a etykiet¹ wychodz¹c¹ 8. Nastêpuje wiêc przypisanie strumienia pakietów podlegaj¹cych rezerwacji do odpowiedniej klasy równowa noœci FEC. Podobnie jak w zwyk³ym RSVP, ka dy ruter wykonuje procedury rezerwacji zasobów. Je eli ca³y proces zakoñczy siê sukcesem, w sieci zostanie utworzona œcie ka zarezerwowana pomiêdzy nadawc¹ i odbiorc¹, tunelowana na odcinku LSR1 LSR3 w œcie ce komutowanej etykietowo LSP (rys. 7c). Pakiety wysy³ane przez nadawcê s¹ klasyfikowane w ruterze brzegowym na podstawie nag³ówka IP. Ponadto wykonuje siê operacje typowe dla wêz³a RSVP, takie jak kontrola zgodnoœci i operacje szeregowania. Nastêpnie pakiety s¹ przydzielane do odpowiedniej klasy równowa noœci i po dodaniu etykiety 8 wysy³ane do rutera LSR2. Ruter LSR2 nie musi ju dokonywaæ klasyfikacji pakietów na podstawie nag³ówka IP ani sprawdzaæ uprawnieñ nadawcy, gdy rozpoznaje pakiety nale ¹ce do danej sesji na podstawie etykiety. Podejmuje tylko niezbêdne akcje w celu zapewnienia jakoœci obs³ugi, a nastêpnie przesy³a pakiety do rutera LSR3 z etykiet¹ 3. Ruter brzegowy LSR3 wysy³a pakiety do odbiorcy, pos³uguj¹c siê adresem IP. Agregacja strumieni zarezerwowanych Jedn¹ z najistotniejszych zalet wynikaj¹cych ze wspó³pracy protoko³ów RSVP i MPLS jest mo liwoœæ tworzenia rezerwacji dla ruchu zagregowanego. W rozszerzonym protokole RSVP sesja jest zdefiniowana jako zbiór pakietów nale ¹cych do tej samej klasy FEC, czyli takich, którym przypisano tê sam¹ etykietê w ruterze brzegowym, bêd¹cym pocz¹tkiem tunelu LSP [2, 3]. Jak wspomniano wczeœniej, w tradycyjnym protokole RSVP pakiety s¹ klasyfikowane na podstawie adresu i numeru portu odbiorcy, identyfikatora protoko³u warstwy transportowej oraz adresu i numeru portu nadawcy (w zale noœci od stylu rezerwacji). Wynika z tego ograniczenie mo liwoœci tworzenia rezerwacji tylko do pojedynczych strumieni. Rozszerzony protokó³ RSVP dopuszcza mo liwoœæ klasyfikowania pakietów na podstawie szerszych kryteriów i agregowanie wielu strumieni w jednym tunelu LSP. Dziêki temu mo liwe jest miêdzy innymi emulowanie ³¹cza dzier awionego o okreœlonych parametrach [6]. Mo na stworzyæ jedn¹ rezerwacjê dla pakietów o tej samej czêœci wspólnej adresu, uzyskuj¹c w ten sposób agregacjê ruchu. Rozszerzony protokó³ RSVP rozwi¹zuje wiêc problem skalowalnoœci tradycyjnego RSVP. Dziêki agregacji strumieni liczba zestawianych po³¹czeñ zarezerwowanych (tuneli LSP) nie roœnie wprost proporcjonalnie do liczby pojedynczych strumieni [2]. Style rezerwacji O Rys. 7. Proces zestawiania ścieżki zarezerwowanej w sieci MPLS (opis w tekście) Rozszerzony protokó³ RSVP wspiera wszystkie style rezerwacji zdefiniowane w podstawowym standardzie RSVP [3]. Odbiorca mo e wybraæ ró ne style rezerwacji dla ró nych tuneli LSP. W przypadku stylu WF (Wildcard-Filter Style) jest konieczne zestawienie œcie ki komutowanej etykietowo typu wielopunkt-punkt. Na odcinkach œcie ki wspólnych dla kilku nadawców przydziela siê tylko jedn¹ etykietê do wszystkich pakietów. Je eli jest wielu nadawców, œcie ka LSP ma architekturê odwróconego drzewa. Styl rezerwacji SE (Shared-Explicit Style) zak³ada, e lista nadawców jest œciœle okreœlona. Mo na w tym przypadku zastosowaæ œcie kê typu wielopunkt-punkt lub utworzyæ osobne œcie - ki punkt-punkt dla ka dego nadawcy. Pierwsze rozwi¹zanie mo- e byæ stosowane, gdy nadawcy nie ¹daj¹ œciœle okreœlonej trasy (rys. 8a) lub ¹dane trasy pokrywaj¹ siê w sposób umo liwiaj¹cy zestawienie takiej œcie ki (rys. 8b). Zalet¹ tego rozwi¹zania jest oszczêdne wykorzystanie zasobów sieci. Wad¹ jest na- 256

WSPÓ PRACA DIFFSERV I MPLS O Rys. 8. Zestawianie ścieżek komutowanych etykietowo dla stylu rezerwacji SE: a) ścieżka typu wielopunkt punkt, b) żądane przez nadawców ścieżki pokrywają się w stopniu umożliwiającym zesta wienie ścieżki typu wielopunkt punkt, c) żądane przez nadawców ścieżki są rozłączne, brak możliwości zestawienia ścieżki typu wie lopunkt punkt tomiast niebezpieczeñstwo przekroczenia zarezerwowanych parametrów na wspólnym odcinku œcie ki lub niewykorzystania zasobów w pobli u nadawców. Je eli nadawcy ¹daj¹ roz³¹cznych œcie ek (ró ne EXPLICIT_ROUTE), jest konieczne utworzenie wielu œcie ek punkt-punkt (rys. 8c). Rozwi¹zanie to jest równowa ne zestawieniu wielu rezerwacji typu FF (Fixed-Filter Style). Wszyscy nadawcy mog¹ jednoczeœnie korzystaæ z ca³ych zarezerwowanych zasobów, mimo e jest to tylko jedna sesja. Wad¹ tego rozwi¹zania jest du e obci¹ enie zasobów sieci. W przypadku rezerwacji FF istnieje tylko jeden nadawca i jest tworzona jedna œcie ka typu punkt-punkt. Zestawienie œcie ki na trasie wybranej przez nadawcê W rozszerzonym protokole RSVP zestawianie œcie ki zarezerwowanej mo e odbywaæ siê niezale nie od protoko³ów rutingu. Nadawca, znaj¹c topologiê i stan sieci, mo e za ¹daæ zestawienia œcie ki przez wybrane wêz³y (explicit ruting). Zapewnia to wybranie optymalnej trasy, na której zestawienie œcie ki o wymaganych parametrach jest najbardziej prawdopodobne. W celu zestawienia takiej œcie ki nadawca umieszcza w komunikacie PATH obiekt EXPLICIT_ROUTE, w którym jest zapisany ci¹g kolejnych wêz³ów abstrakcyjnych 1), przez które ma ona przebiegaæ. Je eli po zestawieniu œcie ki zarezerwowanej nadawca znajdzie lepsz¹ trasê, mo e dynamicznie zmieniæ œcie kê wysy³aj¹c w komunikacie PATH zmieniony obiekt EXPLICIT_ROUTE. Jak wynika z obserwowanych trendów, model us³ug zró nicowanych DiffServ, podobnie jak technika MPLS, bêdzie stosowany g³ównie w sieci szkieletowej. Obie te techniki wzajemnie siê uzupe³niaj¹. Ich efektywna wspó³praca mo e przynieœæ wiele korzyœci miêdzy innymi w zakresie in ynierii ruchu, jak i w zapewnianiu jakoœci us³ug. Z zapewnieniem wspó³pracy protoko³ów MPLS i DiffServ wi¹- e siê koniecznoœæ okreœlenia sposobu reprezentacji klas us³ug DiffServ w sieci MPLS. W domenie DiffServ przynale noœæ pakietów do poszczególnych klas us³ug okreœla odpowiednia wartoœæ punktu kodowego DSCP (Differentiated Services Code Point). Punkt kodowy jest przenoszony w nag³ówku pakietu IP. Pakiety oznaczone tym samym punktem kodowym tworz¹ zespó³ zachowañ BA (Behaviour Aggregate) i s¹ traktowane w sieci jednakowo. Sposób traktowania pakietów w ruterach okreœlaj¹ regu³y przesy³ania pakietów PHB (Per Hop Behaviour) zdefiniowane dla ka dego zespo³u zachowañ. W przypadku klas us³ug AF (Assured Forwarding) dodatkowo wprowadza siê pojêcia uporz¹dkowanego zestawu zachowañ OA (Ordered Aggregate) oraz zbioru uporz¹dkowanego regu³ przesy³ania pakietów PSC (PHB Scheduling Class) [12]. Nag³ówek ka dego pakietu przychodz¹cego do rutera jest analizowany. Na podstawie wartoœci punktu kodowego pakiet otrzymuje odpowiedni poziom jakoœci obs³ugi. W sieci MPLS nag³ówki pakietów nie s¹ analizowane. Przynale noœæ pakietu do klasy us³ug i wynikaj¹cy z tego sposób traktowania pakietu w wêÿle musz¹ byæ wiêc okreœlone na podstawie etykiety lub innych pól nag³ówka MPLS. Aby mo liwe by- ³o wybranie regu³y PHB, zgodnie z któr¹ powinno siê przes³aæ pakiet, nale y zdefiniowaæ odwzorowanie miêdzy wartoœciami punktu kodowego a wartoœciami pól nag³ówka MPLS. W wyniku prac prowadzonych w ramach IETF zaproponowano dwa rozwi¹zania: model E LSP oraz model L LSP [7]. Model E-LSP Pierwsze rozwi¹zanie polega na u yciu do oznaczania pakietów pola Exp nag³ówka MPLS. Zwa ywszy jednak, e pole to ma d³ugoœæ trzech bitów, podczas gdy punkt kodowy DSCP jest szeœciobitowy, liczba rozró nianych klas us³ug jest ograniczona do oœmiu. Jednak e w sieciach, w których jest obs³ugiwanych nie wiêcej ni 8 klas, jest to wystarczaj¹ce. Podstawow¹ zalet¹ modelu E-LSP jest jego prostota. Funkcjonalnoœæ rutera MPLS praktycznie pokrywa siê z funkcjonalnoœci¹ zwyk³ego rutera DiffServ. Do poprawnej pracy jest wymagane jedynie skonfigurowanie w ka dym ruterze powi¹zañ miêdzy wartoœciami pola Exp a regu³ami przesy³ania pakietów PHB lub uporz¹dkowanymi zbiorami regu³ przesy³ania pakietów PSC. Powi¹zania te mog¹ byæ skonfigurowane statycznie, dziêki czemu sygnalizacja nie jest wymagana. Istotne jest tylko aby konfiguracja w danym obszarze sieci by³a spójna. Sposób traktowania pakietu w wêÿle jest jednoznacznie okreœlony przez wartoœæ pola Exp, zaœ sama etykieta nie niesie adnych informacji o klasie us³ugi DiffServ. Etykieta okreœla dok¹d powinien byæ wys³any pakiet, a pole Exp sposób obs³ugi. W pojedynczej œcie ce mog¹ byæ przenoszone pakiety nale ¹ce do oœmiu ró nych klas us³ug DiffServ. Tak zdefiniowana œcie ka jest nazywana œcie k¹ E LSP (Exp-inferred-PSC LSP). St¹d te omawiane rozwi¹zanie nazywane jest modelem E-LSP. Model E-LSP ma jednak pewne wady. Jak ju wspomniano, liczba rozpoznawanych klas us³ug jest ograniczona do oœmiu, co 1) Wêze³ abstrakcyjny jest to zbiór wêz³ów, których topologia po³¹czeñ jest przezroczysta z punktu widzenia zestawianej œcie ki [3] 257

eliminuje zastosowanie tego podejœcia w sieciach obs³uguj¹cych wiêksz¹ ich liczbê. Dodatkowy problem pojawia siê w obszarach sieci MPLS, w których zastosowano protokó³ ATM. Nie stosuje siê tam nag³ówka MPLS, a etykieta jest przenoszona w polach VCI i VPI nag³ówka pakietu ATM. Nie wystêpuje wiêc odpowiednik pola Exp. Wyklucza to mo liwoœæ rozró nienia w ³¹czach ATM oœmiu klas us³ug. Model L-LSP Problem wspó³pracy z technik¹ ATM zosta³ rozwi¹zany w modelu L-LSP, w którym definiuje siê odwzorowanie pomiêdzy wartoœciami punktu kodowego a etykietami. Decyzja o wyborze odpowiedniej regu³y PHB lub zbioru uporz¹dkowanego regu³ PSC jest podejmowana w ruterze LSR na podstawie wartoœci etykiety. W przypadku ³¹czy ATM, gdzie nie stosuje siê nag³ówka MPLS, decyzjê tak¹ podejmuje siê analizuj¹c wartoœæ pola VCI. Jednej klasie us³ug DiffServ odpowiada wiêc jedna klasa równowa noœci przekazywania FEC. Pojedyncza œcie ka LSP jest zestawiana dla jednej klasy us³ug. Œcie ka taka jest nazywana œcie k¹ L-LSP (Label-only-inferred-PSC LSP). St¹d bierze te nazwê omawiany model. W modelu L-LSP, w celu zachowania niezale noœci protoko- ³ów MPLS i DiffServ, nale y unikaæ arbitralnego wydzielenia pewnego zbioru etykiet dla poszczególnych klas us³ug DiffServ. Odwzorowanie pomiêdzy etykietami a odpowiednimi regu³ami PHB i zbiorami uporz¹dkowanymi regu³ PSC nie mo e byæ skonfigurowane statycznie. Jest ono okreœlane dynamicznie, na etapie zestawiania œcie ki dla konkretnej klasy us³ug. Nale y to do zadañ protoko³u sygnalizacyjnego. Takie podejœcie wymaga rozszerzenia funkcjonalnoœci istniej¹cych protoko³ów przydzielania i rozsy³ania etykiet. Istotnym problemem w modelu L-LSP jest zapewnienie zgodnej ze specyfikacj¹ obs³ugi pakietów nale ¹cych do klas us³ug AF. W ramach ka dej klasy AF okreœlono trzy poziomy prawdopodobieñstwa porzucenia pakietu (drop precedence). Pakiety przyporz¹dkowane do danej klasy AF s¹ umieszczane we wspólnej kolejce, a ich kolejnoœæ nie mo e byæ zmieniana. Poziomy prawdopodobieñstwa porzucenia pakietu s³u ¹ jedynie priorytetyzacji pakietów w kolejce. Je eli pakietom ró ni¹cym siê jedynie prawdopodobieñstwem porzucenia (w ramach jednej klasy AF) przyporz¹dkowano by ró ne etykiety, wówczas nie by³oby mo liwe zapewnienie, e bêd¹ umieszczane w jednej kolejce. Ich kolejnoœæ mog³aby byæ zmieniona, a w szczególnoœci mog³yby byæ przes³ane ró nymi drogami. Aby zapewniæ obs³ugê zgodn¹ ze specyfikacj¹ klasy AF, wszystkie pakiety nale ¹ce do tej klasy musz¹ wiêc byæ przes³ane dok³adnie t¹ sam¹ œcie k¹ LSP. Wynika z tego, e informacja o prawdopodobieñstwie porzucenia pakietu nie mo e byæ przenoszona wewn¹trz etykiety. Do tego celu korzysta siê z bitów pola Exp. W przypadku ³¹czy ATM, w których nie stosuje siê nag³ówka MPLS, u yto bitu CLP (Cell Loss Priority) nag³ówka ATM. Wynika st¹d ograniczenie liczby poziomów prawdopodobieñstwa porzucenia pakietu w ³¹czach ATM do dwóch. Propozycjê sposobu odwzorowania poszczególnych wartoœci pola Exp i bitu CLP na poszczególne poziomy prawdopodobieñstwa porzucenia pakietu przedstawiono w dokumencie [7]. Odwzorowanie to jest okreœlone jednoznacznie. Rezerwacja zasobów dla œcie ek typu E-LSP i L-LSP Œcie ki typu E-LSP i L-LSP mog¹ byæ zestawione bez rezerwacji, jak i z rezerwacj¹ zasobów sieciowych. ¹dane parametry rezerwacji powinny byæ przes³ane w czasie tworzenia œcie ki LSP. Mo na w tym celu u yæ protoko³u RSVP. Niezbêdne wydaje siê jednak rozszerzenie jego mo liwoœci. W wyniku prac prowadzonych w ramach IETF zaproponowano wiele rozwi¹zañ. Najprostszym z nich jest rozszerzenie protoko³u RSVP o definicjê obiektu DIFFSERV [7]. Niestety, przewidziano jedynie mo - liwoœæ zestawiania rezerwacji dla poszczególnych œcie ek, a nie pojedynczych strumieni. Oznacza to, e jedynie w modelu L-LSP œcie ka o okreœlonych parametrach jest zarezerwowana dla pojedynczej klasy us³ug. W przypadku œcie ki E-LSP, rezerwacja odbywa siê dla ca³ej œcie ki, czyli dla strumieni ruchu, nale ¹cych do ró nych klas us³ug zagregowanych w jednej œcie ce. Z punktu widzenia zapewnienia jakoœci us³ug mo e jednak okazaæ siê po ¹dane rezerwowanie œciœle okreœlonych zasobów sieciowych dla pojedynczej us³ugi, niezale nie od stosowanego modelu wspó³pracy. Opracowano dwa odmienne sposoby rozwi¹zania tego problemu: M rozszerzenie protoko³u RSVP o definicjê nowego obiektu ELSP dedykowanego do rezerwacji zasobów w œcie kach E-LSP [8], M zmodyfikowanie istniej¹cego obiektu SENDER_TSPEC [10]. Porównanie modeli E-LSP i L-LSP Zestawienie omówionych wy ej cech obydwu modeli wspó³pracy protoko³ów MPLS i DiffServ zawiera tabela 2. Nale y podkreœliæ, e obydwa modele wspó³pracy protoko³ów MPLS i Diff- Serv mog¹ byæ stosowane równolegle w jednej sieci. Wyj¹tkiem s¹ ³¹cza ATM, w których nie stosuje siê nag³ówka MPLS i zastosowanie modelu E-LSP jest niemo liwe [6]. Sposób praktycznego u ycia ka dego z modeli do zapewnienia jakoœci us³ug zale- y od decyzji administratora sieci. O Tabela 2. Porównanie cech modeli współpracy protokołów MPLS i DiffServ [6] Model E LSP PHB lub PSC jest okreœlane na podstawie pola Exp nag³ówka MPLS. Sygnalizacja nie jest wymagana. Mo e byæ jednak zastosowana podobnie jak w modelu L-LSP. Odwzorowanie wartoœci pola Exp na PHB jest zwykle skonfigurowane statycznie; mo e byæ konfigurowane dynamicznie. Nie mo e byæ stosowany w ³¹czach ATM. Maksymalnie 8 strumieni ró ni¹cych siê jakoœci¹ obs³ugi (klas¹ DiffServ) w jednej œcie ce LSP. Model L LSP PHB lub PSC jest okreœlane na podstawie etykiety oraz pola Exp nag³ówka MPLS lub pola CLP nag³ówka ATM. Powi¹zanie PHB lub PSC z wartoœciami etykiet przenoszone przez sygnalizacjê w czasie zestawiania œcie ki. Odwzorowanie etykiet na PHB lub PSC jest dynamiczne; odwzorowanie wartoœci pola Exp lub CLP na prawdopodobieñstwo porzucenia pakietu œciœle zdefiniowane. Mo e byæ stosowany w ³¹czach ATM. Jeden strumieñ (jedna klasa Diff- Serv) w jednej œcie ce. Za zastosowaniem modelu E-LSP przemawia jego prostota. Jest on bardzo podobny do podstawowego modelu us³ug zró nicowanych. Istotn¹ zalet¹ jest te mo liwoœæ przes³ania strumieni danych nale ¹cych do oœmiu ró nych klas us³ug w jednej œcie - ce LSP. Pozwala to na bardziej efektywne wykorzystanie puli etykiet. Mo e to mieæ du e znaczenie w obszarach sieci, w których liczba dostêpnych etykiet jest ma³a. Wa n¹ zalet¹ modelu L-LSP jest brak ograniczenia liczby obs³ugiwanych klas us³ug. Dla ka dej klasy us³ug jest zestawiana oddzielna œcie ka, dziêki czemu jest mo liwe dobranie najlepszej drogi w sieci dla poszczególnych klas. Przyk³adowo œcie ka przenosz¹ca ruch klasy EF mo e byæ zestawiona w ³¹czach 258

o ma³ym opóÿnieniu pakietów, podczas gdy œcie ka przenosz¹ca ruch klasy AF mo e przebiegaæ przez ³¹cza o wiêkszym opóÿnieniu pakietów, ale o du ej przep³ywnoœci. Administrator mo e wiêc efektywnie gospodarowaæ zasobami sieci, jak równie optymalizowaæ strukturê logiczn¹ po³¹czeñ ze wzglêdu na zapewnienie jakoœci us³ug. W modelu L-LSP informacja o powi¹zaniu klasy us³ug DiffServ z odpowiedni¹ etykiet¹ jest przesy³ana na etapie zestawiania œcie ki komutowanej etykietowo. W przypadku œcie ki E-LSP odwzorowanie pomiêdzy klasami us³ug a wartoœciami pola Exp mo e byæ skonfigurowane statycznie. Nie wyklucza siê jednak konfiguracji dynamicznej. Stosuje siê wówczas, podobnie jak w modelu L-LSP, sygnalizacjê odpowiedzialn¹ za zestawienie œcie ki LSP. Dziêki opracowaniu modeli wspó³pracy protoko³ów MPLS i Diff- Serv, funkcjonalnoœæ sieci DiffServ mo e byæ rozszerzona o mechanizm równowa enia obci¹ enia. Strumieñ pakietów nale ¹cych do tej samej klasy us³ug DiffServ mo e byæ w szczególnoœci przesy³any wiêcej ni jedn¹ œcie k¹ LSP. Nie dotyczy to oczywiœcie klas us³ug z ograniczeniem na zachowanie kolejnoœci przesy³anych pakietów (np. AF). Technika MPLS we wspó³pracy z modelami architektur sieciowych IntServ i DiffServ stwarza du e mo liwoœci w zakresie zapewnienia jakoœci us³ug w sieci Internet. Sama komutacja MPLS zapewnia przede wszystkim uproszczenie sterowania przep³ywem, przyspieszenie realizacji procesów komutacyjnych w ruterach, a w szczególnoœci pozwala na efektywniejsze gospodarowanie zasobami sieciowymi. Komutacja MPLS umo liwia tworzenie œcie ek z uwzglêdnieniem aktualnego stanu sieci. Dziêki mechanizmom wspó³pracy z modelami IntServ i DiffServ, w œcie kach tych mo na gwarantowaæ jakoœæ us³ug. Co wiêcej, gwarantowanie jakoœci us³ug jest mo liwe równie w ³¹czach ATM czy FR. Nale y jednak zwróciæ uwagê, e proces standaryzacji komutacji MPLS nie zosta³ jeszcze zakoñczony. Mimo przygotowania silnych podstaw standardu, brak jest, miêdzy innymi, szczegó³owych procedur zarz¹dzania czy przydzia³u zasobów do œcie ek. Stale s¹ te prowadzone prace nad rozwojem mechanizmów wspó³pracy MPLS z modelami IntServ i DiffServ. Owocem ich jest miêdzy innymi istotne ulepszenie protoko³u RSVP i zwiêkszenie zakresu jego zastosowania. Wydaje siê, e rola techniki MPLS bêdzie nadal ros³a. LITERATURA [1] Andersson L., Doolan P., Feldman N., Fredette A., Thomas B.: LDP Specification, IETF RFC 3036, January 2001 [2] Awduche D. et al.: Applicability Statment for Extentions to RSVP for LSP-tunnels, IETF Draft, draft-ietf-mpls-rsvp-tunnel-applicability-02. txt, April 2001 (praca w toku) [3] Awduche D. et al.: RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF Draft, draft-ietf-mpls-rsvp-lsp-tunnel-09. txt, August 2001 (praca w toku) [4] Conta A., Doolan P., Malis A.: Use of Label Switching on Frame Relay Networks Specification, IETF RFC 3034, January 2001 [5] Davie B., Lawrence J., McCloghrie K., Rosen E., Swallow G., Rekhter Y., Doolan P.: MPLS using LDP and ATM VC Switching, IETF RFC 3035, January 2001 [6] Davie B., Rekhter Y.: MPLS: Technology and Applications, Morgan Kaufmann Publishers, USA 2000 [7] Faucheur F. et al.: MPLS Support of Differentiated Services, IETF Draft, draft-ietf-mpls-diff-ext-09. txt, April 2001 (praca w toku) [8] Ganti S. et al.: MPLS Support of Differentiated Services using E-LSP, IETF Draft, draft-ganti-mpls-diffserv-elsp-00. txt, April 2001 (praca w toku) [9] Gozdecki J., Pacyna P., Papir Z.: Konwergencja sieci Internet i ATM z perspektywy jakoœci us³ug, Przegl¹d Telekomunikacyjny i Wiadomoœci Telekomunikacyjne, nr 5-6, 2001 [10] Iovanna P. et al.: Definition of the MPLS FlowSpec for RSVP-TE, IETF Draft, draft-iovanna-rsvp-mpls-flowspec-00. txt, October 2001 (praca w toku) [11] Jajszczyk A., Lasoñ A., Wajda K.: Trendy rozwojowe optycznych sieci transportowych budowanych na potrzeby sieci Internet, Przegl¹d Telekomunikacyjny i Wiadomoœci Telekomunikacyjne, nr 5-6, 2001 [12] Jajszczyk A., Stankiewicz R.: Sposoby zapewnienia gwarantowanej jakoœci us³ug w sieciach IP, Przegl¹d Telekomunikacyjny i Wiadomoœci Telekomunikacyjne, nr 2, 2002 [13] Rosen E., Tappan D., Fedorkow G., Rekhter Y., Farinacci D., Li T., Conta A.: MPLS Label Stack Encoding, IETF RFC 3032, January 2001 [14] Rosen E., Viswanathan A., Callon R.: Multiprotocol Label Switching Architecture, RFC 3031, January 2001 Praca wykonana w ramach badañ w³asnych nr 10.10.120.294 Artykuł recenzowany (Artyku³ nades³ano do red. grudzieñ 2001) Zapraszamy na stronę internetową Przeglądu TelekomunikacyjnegoT i Wiadomości TelekomunikacyjnychT www.ptiwtel.com.pl Większość informacji jest zamieszczona również w angielskiej wersji językowej 259