Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe

Numer Projektu Badawczego Zamawianego: -MNiSW-02-II/2007 Tytuł projektu: Numer dokumentu: Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe -MNiSW-02-II/2007/WUT/A.1 Tytuł raportu: Analiza architektur proponowanych dla realizacji sieci IP QoS Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: 25/06/08 Kierownik zadania: Wojciech Burakowski Wykonawcy: Halina Tarasiuk, Wojciech Burakowski, Andrzej Bęben, Piotr Krawiec, Jarosław Śliwiński Abstrakt: Raport przedstawia analizę architektur proponowanych dla sieci IP z gwarancją jakości obsługi (IntServ i DiffServ) oraz stan standaryzacji dotyczącej architektury sieci następnej generacji NGN. Prezentuje również możliwości zastosowania techniki MPLS w sieciach QoS IP. Ostatni rozdział raportu zawiera wnioski i sugestie dotyczące architektury systemu tworzonego w ramach projektu, które wynikają z realizacji zadania A.1. Słowa kluczowe: IntServ, DiffServ, IMS, NGN, TISPAN, RACF, MPLS

Streszczenie W raporcie dokonano analizy architektur oraz stanu standaryzacji dotyczących realizacji sieci IP z gwarancją jakości obsługi QoS. W pierwszej części raportu przedstawiono dwie architektury dla sieci IP QoS zaproponowane przez IETF: IntServ oraz DiffServ. Architektura IntServ pozwala zapewnić ścisłe gwarancje QoS dzięki rezerwacji zasobów (dla pojedynczego lub zbiorczego strumienia) w każdym węźle i łączu danej ścieżki. Jednakże konieczność przeprowadzenia procesu zestawiania połączenia w sieci (wykonywanego za pomocą protokołu sygnalizacyjnego RSVP) i przechowywania informacji o połączeniu w każdym ruterze należącym do danej ścieżki pomiędzy użytkownikami końcowymi, spowodowały, iż architektura IntServ rozpatrywana jest jako rozwiązanie o ograniczonej skalowalności. W związku z tym rozwój jej został zarzucony na rzecz bardziej skalowalnej architektury DiffServ. Główna koncepcja DiffServ polega na tym, iż rutery brzegowe obsługują pojedyncze strumienie pakietów, natomiast w sieci szkieletowej obsługa odbywa się na podstawie strumieni zbiorczych (klas ruchu), zgodnie z przyjętymi modelami przekazu pakietów (tzw. PHB). Poprzez odpowiednio zdefiniowane PHB, DiffServ pozwala na różnicowanie jakości obsługi poszczególnych klas ruchu. Celem zapewnienia ścisłych gwarancji QoS dla poszczególnych strumieni pakietów konieczne jest jednak rozszerzenie architektury DiffServ o dodatkowe elementy, którymi są mechanizmy realizujące funkcje sterowania przyjmowaniem nowych wywołań AC, przydziału zasobów dla połączeń i obsługi żądań generowanych przez użytkownika. Kolejna część raportu dotyczy analizy stanu standaryzacji sieci następnej generacji NGN, której jedną z podstawowych cech jest zapewnienie jakości przekazu pakietów od końca do końca. Prace standaryzacyjne, mające na celu specyfikację sieci NGN, prowadzone są przez różne organizacje, m.in. 3GPP, ITU-T oraz ETSI. Cechą wspólną proponowanych rozwiązań jest podział funkcjonalności systemu na dwie niezależne warstwy: usługową i transportową. System IMS, opracowany przez 3GPP, odpowiedzialny jest za zarządzanie multimedialnymi usługami oferowanymi użytkownikowi, stanowi zatem przykład realizacji warstwy usługowej, bez określania aspektów warstwy transportowej. Z kolei architektura TISPAN, zaproponowana przez ETSI, definiuje zarówno płaszczyznę usługową, jak i transportową, jednakże obejmuje swym zasięgiem jedynie obszar sieci dostępowej i ruter brzegowy sieci szkieletowej. Ostatnia z prezentowanych specyfikacji, zdefiniowana przez ITU-T, jest opracowaniem kompleksowym, obejmującym wszystkie elementy architektury sieci NGN. W dalszej części rozdziału zostały przedstawione elementy funkcjonalne tej architektury realizujące funkcje związane z zarządzaniem sposobem przesyłania danych, metody obsługi żądania QoS oraz mechanizmy QoS przewidziane dla sieci ITU-T NGN. Na zakończenie, jako przykład implementacji elementów architektury NGN, zaprezentowano system opracowany w ramach projektu 6.PR EuQoS. Następny rozdział raportu prezentuje stan standaryzacji oraz możliwości wykorzystania techniki MPLS w sieci IP QoS. W ramach IETF opracowano zasady współpracy pomiędzy techniką MPLS a DiffServ. Zdefiniowano dwie metody przyporządkowania pakietów przenoszonych w ramach ścieżek MPLS do klas usług zdefiniowanych w technice DiffServ: (1) odwzorowanie każdej klasy usług na osobną ścieżkę MPLS, (2) przyporządkowanie pakietów przenoszonych w ramach danej 2

ścieżki MPLS do różnych klas usług poprzez ustawienie pola EXP w nagłówku MPLS. Technika MPLS w połączeniu z DiffServ umożliwia zestawianie niezależnych ścieżek MPLS dla poszczególnych klas usług oraz optymalizację zasobów sieci z uwzględnieniem wymagań oferowanych usług. Ostatni rozdział raportu zawiera, wynikające z realizacji zadania A.1, następujące wnioski i zalecenia dla projektu: Projektowany system powinien uwzględniać elementy architektury ITU-T NGN, zwłaszcza w aspektach dotyczących obsługi żądań i rezerwacji zasobów. W szczególności, następujące aspekty architektury ITU-T NGN powinny być wzięte pod uwagę: o Dekompozycja funkcjonalności systemu na płaszczyznę usług (funkcje SCF) i płaszczyznę transportową (funkcje RACF i NACF); o Realizacja połączeń na żądanie (zakładany scenariusz obsługi żądania QoS generowanego przez użytkownika/aplikację push mode); o Użyte protokoły komunikacyjne powinny być zgodne z protokołami objętymi standaryzacją i zalecanymi dla architektury NGN. Stosując powyższą zasadę, gwarantujemy możliwość potencjalnego rozwoju zaprojektowanego systemu poprzez współpracę z innym systemami zgodnymi ze specyfikacją ITU. Warstwę transportową systemu należy opracować w oparciu o skalowalną architekturę DiffServ, uzupełnioną o funkcję przyjmowania nowych wywołań, co razem umożliwi zapewnienie ścisłych gwarancji QoS. Zgodnie z architekturą DiffServ, jedynie w ruterach brzegowych rozróżniamy pojedyncze strumienie i dla tych strumieni definiujemy funkcje profilowania ruchu, zaś w ruterach szkieletowych rozróżniamy jedynie strumienie zbiorcze (zagregowane) obsługiwane w ramach danej usługi sieciowej. Odnośnie realizacji sieci DiffServ, należy rozważyć możliwość użycia techniki MPLS. 3

Spis treści STRESZCZENIE...2 1 WSTĘP...6 2 ARCHITEKTURA INTSERV...7 2.1 PODSUMOWANIE...8 3 ARCHITEKTURA DIFFSERV...9 3.1 PODSUMOWANIE...11 4 ARCHITEKTURY DLA SIECI NOWEJ GENERACJI...13 4.1 STAN STANDARYZACJI...13 4.1.1 3GPP IMS IP Multimedia Subsystem...13 4.1.2 ITU-T NGN...15 4.1.3 ETSI TISPAN...16 4.2 WYMAGANIA QOS...17 4.3 ELEMENTY FUNKCJONALNE NGN...17 4.3.1 Zarządzanie zasobami...17 4.3.2 Sygnalizacja...19 4.3.3 Mechanizmy QoS...20 4.4 PRAKTYCZNE REALIZACJE...21 4.4.1 Projekt EuQoS...21 4.5 PODSUMOWANIE...23 5 TECHNIKA MPLS...24 5.1 STAN STANDARYZACJI...25 5.1.1 Path Computation Element...25 5.2 ZASTOSOWANIA WEWNĄTRZ-DOMENOWE...26 5.3 ZASTOSOWANIA MIĘDZY-DOMENOWE...26 5.4 PRAKTYCZNE REALIZACJE...26 5.4.1 Projekt EuQoS...26 5.5 PODSUMOWANIE...27 4

6 WNIOSKI I ZALECENIA DLA PROJEKTU...28 LITERATURA...29 LISTA SKRÓTÓW...33 LISTA OZNACZEŃ...35 5

1 Wstęp W celu umożliwienia prawidłowego transferu przez sieć pakietową multimedialnych strumieni generowanych przez aplikacje takie jak: VoIP, wideo-konferencja czy wideo na żądanie, konieczne jest zapewnienie ścisłych gwarancji jakości obsługi pakietów QoS (Quality of Service). Termin ścisłe gwarancje QoS oznacza, że wszystkie lub część parametrów QoS (np. opóźnienie, zmienność opóźnienia, poziom strat pakietów) jest wyspecyfikowana za pomocą odpowiednich wartości liczbowych. Pierwsze specyfikacje architektur sieci IP QoS to IntServ i DiffServ zaproponowane w ramach IETF. W chwili obecnej trwają prace związane ze standaryzacją architektury funkcjonalnej dla sieci następnej generacji NGN (Next Generation Network), opartej na protokole IP. Cechą charakterystyczną takiej sieci jest oddzielenie płaszczyzny usługowej, przeznaczonej do obsługi sygnalizacji aplikacji, od płaszczyzny transportowej, odpowiedzialnej za zarządzanie przesyłaniem danych. Jednym z wymagań dla warstwy transportowej sieci NGN jest możliwość transmisji pakietów z zapewnieniem jakości obsług QoS. Niniejszy raport dotyczy analiz obecnego stanu definicji architektur dla sieci IP QoS. W dwóch następnych rozdziałach przedstawiono analizę architektur IntServ i DiffServ. Kolejny szczegółowo opisuje architektury dla sieci następnej generacji. W rozdziale 5 zaprezentowana jest technika MPLS oraz możliwości jej zastosowania w sieciach IP QoS. Ostatni rozdział raportu zawiera wnioski i sugestie dotyczące architektury systemu tworzonego w ramach projektu. 6

2 Architektura IntServ Obserwując brak aplikacji wykorzystujących usługi telekomunikacyjne oferowane przez technikę ATM oraz jednoczesny gwałtowny wzrost liczby użytkowników sieci Internet, projektanci nowych architektur zorientowanych na oferowanie QoS wnioskują, iż architektury te powinny być oparte na technice IP, ze względu na jej szerokie zastosowanie [RFC1633]. Architektura IntServ [RFC1633] stanowi rozszerzenie architektury sieci Internet o model tzw. usług zintegrowanych. W szczególności, w architekturze IntServ zakłada się, iż dostęp do zasobów sieci jest sterowany za pomocą mechanizmu przyjmowania nowych wywołań (Admission Control - AC). W celu zapewnienia QoS odpowiednie zasoby sieci (bufory, pasmo) są rezerwowane w każdym węźle i łączu wzdłuż drogi połączenia. Rezerwacje mogą być realizowane dla pojedynczego strumienia pakietów lub dla strumieni zbiorczych. wiadomość PATH(1) wiadomość PATH(2) wiadomość PATH(3) IBM PS/2 IBM PS/2 IBM PS/2 IBM PS/2 Nadawca Odbiorca wiadomość RESV(6) wiadomość RESV(5) wiadomość RESV(4) Nadawca Odbiorca Ruter Ruter Rysunek 2-1: Przepływ wiadomości sygnalizacyjnych w protokole RSVP. W celu rezerwacji zasobów, w architekturze IntServ zaproponowano zastosowanie odpowiedniego protokołu sygnalizacyjnego, dla zestawienia połączenia w sieci. W konsekwencji organizacja IETF zdefiniowała protokół Resource ReSerVation Protocol (RSVP) [RFC2205, RFC2210]. Przykładowy przepływ wiadomości sygnalizacyjnych w protokole RSVP przedstawia Rysunek 2-1. Żądanie rezerwacji zasobów jest inicjowane przez stronę nadawczą, która wysyła wiadomość typu PATH. Wiadomość ta zawiera informacje o generowanym profilu ruchowym. W oparciu o te dane określane są wymagania na pasmo oraz rozmiar bufora dla zapewnienia QoS w poszczególnych węzłach sieci. Strona odbiorcza po otrzymaniu wiadomości PATH, wysyła wiadomość RESV, której zadaniem jest rezerwacja zasobów w każdym węźle wzdłuż drogi połączeniowej pomiędzy stacją odbiorczą a nadawczą. Wiadomość RESV jest przesyłana od stacji odbiorczej do stacji nadawczej tą samą drogą jak wiadomość PATH. W przypadku, kiedy sieć dysponuje zasobami, algorytm AC akceptuje przyjęcie wywołania w każdym węźle na drodze połączeniowej. Dokonana rezerwacja musi być okresowo odnawiana (soft reservation). Rezerwacja zasobów na całej drodze połączeniowej wymaga również, aby w każdym węźle była przechowywana informacja o profilach ruchowych dla obsługiwanych strumieni ruchu, co z kolei ogranicza skalowalność tego rozwiązania. Oprócz mechanizmów AC oraz sygnalizacji RSVP, mechanizmami QoS, które wspierają jakość obsługi w sieci IntServ są klasyfikatory pakietów stosowane w interfejsach wejściowych ruterów oraz mechanizmy szeregowania pakietów, ulokowane w interfejsach wyjściowych. Model odniesienia dla implementacji rutera w sieci IntServ przedstawia Rysunek 2-2. W modelu tym możemy wyróżnić 7

dwie warstwy logiczne. Dolna część modelu przedstawia warstwę przekazu danych z urządzeniami do klasyfikacji i szeregowania pakietów, zaś górna część stanowi warstwę rezerwacji oraz sterowania zasobami, odpowiednio z agentami rutingu, zestawiania rezerwacji oraz zarządzania. Agent rutingu Agent zestawiania rezerwacji Agent zarządzania Tablice rutingu Baza danych sterowania ruchem Dane wejściowe Interfejs wejściowy Klasyfikacja Interfejs wyjściowy Szeregowanie pakietów Dane wyjściowe Rysunek 2-2: Model ścieżki pakietów w ruterze dla sieci IntServ. W ramach architektury IntServ zaproponowano dwie usługi sieciowe oferujące QoS: Usługę, która powinna oferować ścisłe gwarancje QoS - Guaranteed Service [RFC2212]. Usługa ta została zaprojektowana dla aplikacji wymagających obsługi w reżimie czasu rzeczywistego i powinna zapewnić, aby maksymalne wartości opóźnień, których doznają pakiety przekazywane przez sieć, nie przekraczały założonych wartości granicznych. Usługę, która powinna zapewniać pewną jakość obsługi dla elastycznych aplikacji standardowych - Controlled-load Service [RFC2211]. Usługa powinna zapewniać bardzo małe średnie opóźnienia pakietów, a także bardzo małe straty pakietów, w skalach czasowych większych, niż czas obsługi paczki pakietów. Dla obu wymienionych usług, aby zagwarantować założone wymagania QoS należy zdefiniować odpowiednią metodę AC. Zastosowanie konkretnego algorytmu AC zależy od implementacji danej usługi i pozostaje w gestii operatora sieci. Dodatkowo, w ramach architektury IntServ, przewidziano trzecią usługę, którą może być np. usługa standardowa. 2.1 Podsumowanie Pomimo dużych nadziei, jakie wiązano z zastosowaniem architektury IntServ, problem skalowalności rozwiązania stanowi istotny czynnik hamujący rozwój tego podejścia. Dlatego też, dalsze prace nad architekturą sieci opartej na protokole IP, która wspierałaby gwarancje QoS, zostały ukierunkowane na takie podejścia, które rozwiązałyby problem skalowalności. Taką architekturą jest architektura DiffServ. 8

3 Architektura DiffServ Architektura DiffServ dzięki zastosowaniu właściwych mechanizmów QoS ma pozwolić operatorom sieci na świadczenie usług różniących się oferowaną jakością obsługi. Różnicowanie jakości obsługi może odbywać się ze względu na różnicowanie jakości obsługi w ramach różnych klas abonentów lub różnych klas ruchu [RFC2475, RFC3260, RFC3290]. Agent przydzielania pasma IBM PS/2 IBM PS/2 Nadawca IB M P S/2 IB M P S/2 Odbiorca Wejściowy ruter brzegowy Wyjściowy ruter brzegowy Ruter szkieletowy Rysunek 3-1: Ogólna architektura DiffServ. Rysunek 3-1 przedstawia ogólną architekturę DiffServ. Wyróżniamy w niej rutery brzegowe, usytuowane na wejściu i wyjściu z sieci szkieletowej oraz rutery szkieletowe. Jak już wspomniano jednym z warunków, który ma być spełniony przez architekturę DiffServ, jest skalowalność rozwiązania. Elementem wyróżniającym architekturę DiffServ, od wcześniej przedstawionej architektury IntServ, jest zastosowanie tzw. agenta przydzielania pasma (Bandwidth Broker). Agent ten odpowiada za realizację funkcji AC, zarządzanie zasobami sieci oraz za funkcje związane z konfiguracją ruterów brzegowych. Wymienione funkcje są realizowane tylko w węzłach brzegowych sieci. Zakłada się, iż sieć szkieletowa jest odpowiednio przewymiarowana, aby nie stanowić ograniczenia dla przekazu pakietów. Główna koncepcja DiffServ polega na tym, iż rutery brzegowe obsługują pojedyncze strumienie pakietów, natomiast w sieci szkieletowej obsługa odbywa się na podstawie strumieni zbiorczych. Dlatego też funkcje profilowania ruchu są realizowane jedynie w węzłach brzegowych sieci. Natomiast, obsługa ruchu zbiorczego (klas ruchu) przez sieć powinna odbywać się zgodnie z przyjętymi modelami przekazu pakietów, określanymi jako Per-Hop-Behaviour (PHB). PHB określają, w jaki sposób ruch w ramach danej klasy ruchu ma być przekazywany między poszczególnymi węzłami sieci. Pakiety, obsługiwane wg tego samego PHB są rozpoznawane w ruterach dzięki odpowiedniemu ustawieniu pola DSCP nagłówka pakietu IP. Odpowiednie definicje dla wartości pól nagłówków pakietów zarówno dla IPv4 oraz IPv6 przedstawiono w dokumencie [RFC2474] oraz [RFC4594]. 9

W ramach architektury DiffServ zdefiniowano dwie główne grupy PHB: Expedited Forwarding (EF) [RFC3246] i Assured Forwarding (AF) [RFC2597]. Grupa EF PHB została zdefiniowana dla przekazu pakietów wymagających obsługi w reżimie czasu rzeczywistego, natomiast grupa AF PHB odpowiada za przekaz pakietów w ramach wielu klas ruchu elastycznego oraz ruchu bez reżimu czasu rzeczywistego. W przypadku obu grup PHB, zdefiniowane mechanizmy QoS powinny zapewnić jakość przekazu pakietów zgodnie z wymaganiami QoS przyjętymi dla danej klasy ruchu oraz zapewnić różnicowanie jakości między poszczególnymi klasami ruchu. Dlatego też, w celu gwarancji QoS przy przekazie pakietów przez sieć, w każdym węźle sieci (ruterze), powinny być utworzone tzw. bloki dla regulowania ruchu (Traffic Conditioning Blocks - TCB) [RFC3290], które stanowią zestaw wybranych mechanizmów QoS dla regulowania ruchu w ramach danej usługi sieciowej. Zestaw mechanizmów QoS w ramach bloków TCB zależy od typu rutera. Bloki TCB dla ruterów brzegowych będą zawierały mechanizmy QoS dla obsługi pojedynczych strumieni ruchu, zaś bloki ruterów szkieletowych tylko mechanizmy QoS dla obsługi strumieni zbiorczych. Przykładowo, mechanizmy monitorowania ruchu dedykowane do obsługi pojedynczych strumieni ruchu są stosowane jedynie w ruterach brzegowych sieci. Również funkcje związane z sygnalizacją QoS oraz metodami AC, a w konsekwencji konfiguracją parametrów urządzeń monitorujących ruch, powinny być realizowane jedynie na wejściu do sieci szkieletowej oraz na jej wyjściu. Główne elementy funkcjonalne rutera w architekturze DiffServ przedstawia Rysunek 3-2. Zarządzanie np.: SNMP, COPS Interfejs konfiguracji oraz zarządzania DiffServ Dane wejściowe Interfejs wejściowy Klasyfikacja Licznik Monitorowanie Kolejkowanie Ruting wewnętrzny Interfejs wyjściowy Klasyfikacja Licznik Monitorowanie Kolejkowanie Dane wyjściowe Sygnalizacja QoS Agent QoS (opcjonalnie) (np.: RSVP) Rysunek 3-2: Główne elementy funkcjonalne rutera DiffServ Jak wynika z definicji architektury DiffServ, architektura ta powinna wspierać różnicowanie jakości obsługi np. różnych klas abonentów lub różnych klas ruchu. Biorąc pod uwagę obecny stan sztuki, na potrzeby projektu rozważane są jedynie aspekty różnicowania jakości obsługi z punktu widzenia różnych klas ruchu, a zwłaszcza ze względu na stawiane tym klasom wymagania QoS. Różnicowanie jakości obsługi wymaga zastosowania odpowiednich mechanizmów. Najprostszym mechanizmem dla zróżnicowania QoS jest nadanie strumieniom poszczególnych klas ruchu różnych priorytetów obsługi. Jednak zastosowanie jedynie prostego mechanizmu priorytetów w ruterach szkiele- 10

towych sieci bez użycia właściwych metod AC na dostępie do sieci nie wystarczy dla zapewnienia ścisłych gwarancji QoS, gdyż niekontrolowany ruch w ramach klas o wyższym priorytecie obsługi mógłby wpływać na pogorszenie lub całkowitą blokadę przekazu pakietów z klas o niższym priorytecie. W ramach architektury DiffServ można, oprócz usług oferujących ścisłe gwarancje QoS, zaprojektować również usługi, które będą oferować względne gwarancje QoS. Usługi takie nie wymagają zastosowania mechanizmów AC. W ramach IETF, w oparciu o EF PHB, zaproponowano realizację usługi Premium [RFC2638], dla aplikacji generujących ruch o stałej szybkości bitowej. Usługa Premium realizuje emulację łącza o stałej szybkości (na poziomie pakietów). Wymagania QoS dla usługi Premium są następujące: usługa powinna gwarantować bardzo małe opóźnienia przekazu pakietów, małą zmienność tych opóźnień oraz małe straty pakietów. Zakłada się, iż pakiety w ramach usługi Premium będą obsługiwane z najwyższym priorytetem z zastosowaniem odpowiedniej metody AC. W tym przypadku proponuje się zastosowanie metody AC typu REM (Rate Enveloped Multiplexing) z alokację pasma na podstawie maksymalnej szybkości bitowej (peak rate allocation scheme). Dla pełnej realizacji usługi należy uzgodnić tzw. kontrakt ruchowy między użytkownikiem a siecią. Kontrakt taki jest określany jako Service Level Agreement (SLA) i jest zawierany na podstawie parametrów mechanizmu token bucket, tj. maksymalnej szybkości bitowej oraz maksymalnego rozmiaru paczki pakietów. Dodatkowo, w ruterach brzegowych sieci DiffServ ruch, w ramach pojedynczych strumieni, podlega procesowi kształtowania, aby był zgodny z zawartym kontraktem ruchowych na wejściu do sieci szkieletowej i na jej wyjściu. Usługa Premium jest jedną z propozycji realizacji usługi w ramach architektury DiffServ, która została zaproponowana przez IETF. Dla pozostałych usług nie przygotowano dokładnych definicji, aczkolwiek ogólne wymagania zostały zawarte np. w [RFC4594]. Inne podejście do wykorzystania architektury DiffServ, nie dla oferowania ścisłych gwarancji QoS, ale dla oferowania względnych gwarancji QoS, zostało przedstawione np. w artykułach [Nyb01, Nyb03]. Względne gwarancje QoS są związane z tzw. nominalną szybkością obsługi. W artykule [Nyb01] autorzy przedstawiają modele analityczne dla usług w architekturze DiffServ z zastosowaniem mniej znanego niż EF, czy AF PHB o nazwie Dynamic RT/NRT (Dynamic Real Time/ Non- Real Time PHB) oraz mechanizmu SIMA (Simple Integrated Media Access). Zaś w artykule [Nyb03] zaproponowane modele analityczne dla usług z zaprojektowanych na bazie AF PHB oraz mechanizmu SIMA. Jednak dotychczas żadna z tych propozycji nie znalazła odbicia w ramach zaleceń IETF. 3.1 Podsumowanie Nie ma wątpliwości, iż niezależnie od proponowanej architektury sieci wielo-usługowej, obsługa ruchu z wymaganiami reżimu czasu rzeczywistego powinna różnić się od obsługi ruchu elastycznego. Stąd też, konieczność zastosowania odpowiednich metod różnicowania jakości obsługi. Metody różnicowania obsługi wymagają istnienia odpowiedniej architektury, która pozwoli na ich realizację. W konsekwencji metody różnicowania obsługi sprowadzają się do zdefiniowania odpowiedniej dla danej architektury grupy klas usług sieciowych, które będą mogły obsługiwać strumienie ruchu o podobnych charakterystykach oraz wymaganiach QoS. 11

Obecnie najbardziej obiecującą architekturą wspierającą ścisłe gwarancje QoS w sieciach wielousługowych jest architektura DiffServ, która może działać zarówno w oparciu o technikę IPv4, jak i IPv6. Dlatego też, znalazła ona najwięcej zwolenników dla zastosowania w przypadku sieci IP QoS, czy też szeroko rozumianych sieci następnej generacji NGN [Potts03], [ITU-Y2001]. Praktyczną realizacją sieci IP QoS jest np. instalacja pilotowej sieci europejskich projektów AQUILA [Bak03, Koch03], EuQoS [Masip07] oraz europejska sieć badawcza GEANT [Geant]. Należy podkreślić, iż architektura DiffServ pozwala jedynie na różnicowanie jakości obsługi w sieci szkieletowej, poprzez zdefiniowane PHB. Dlatego też, konieczne jest rozszerzenie tej architektury o nowe elementy, aby uzyskać ścisłe gwarancje QoS dla poszczególnych strumieni pakietów. Przykładami takich elementów są mechanizmy QoS realizujące odpowiednio metody AC [Brand02], metody przydziału pasma dla połączeń [D1301, D1302], metody obsługi żądań użytkownika [D1301], metody współpracy aplikacji użytkownika z siecią [Kem03], [Rodriguez08]. Dopiero właściwe połączenie grup PHB zdefiniowanych w ramach architektury DiffServ z wymienionymi mechanizmami pozwoli na zbudowanie właściwych usług sieciowych oferujących QoS w sieci IP. 12

4 Architektury dla sieci nowej generacji Jedną z podstawowych cech sieci następnej generacji NGN jest wykorzystanie tej samej sieci transportowej, opartej na protokole IP, do przekazu wszystkich danych generowanych przez użytkownika, niezależnie od użytej aplikacji (VoIP, telekonferencja, wideo na żądanie VoD, pobieranie zbiorów danych z serwera FTP itd.). Prace standaryzacyjne, związane ze specyfikacją sieci NGN, prowadzone są równocześnie przez różne organizacje standaryzacyjne, m.in. 3GPP, ITU-T oraz ETSI. 4.1 Stan standaryzacji 4.1.1 3GPP IMS IP Multimedia Subsystem IMS (IP Multimedia Subsystem) ([TS23002] [TS23228]) opracowany został przez ciało standaryzacyjne 3GPP [3gpp] w celu dostarczenia usług multimedialnych użytkownikom mobilnym. Pomimo że projektowany był do zastosowania w sieciach bezprzewodowych 3G, w chwili obecnej rozpatrywany jest jako płaszczyzna usługowa niezależna od technologii, w jakiej zostały wykonane sieci dostępowe. IMS odpowiedzialny jest za zarządzanie multimedialnymi usługami oferowanymi użytkownikowi, z punktu widzenia sterowania sesją, sterowania usługą, zarządzania bazą danych zawierającą informacje o użytkownikach sieci itp. Mb IP Multimedia Networks Mb IM - MGW Mb CS Network CS CS M n MGCF BGCF Mk Mj BGCF Mk Mg Mr Mg I-CSCF Mi Mm Mw S - CSCF Mw Mm Dx Cx Legacy mobile signalling Networks ISC Cx AS Dh SLF Sh C, D, Gc, Gr HSS Mb MRFP Mb Mp Mb MRFC P-CSCF Gm UE Ut IMS Subsystem Rysunek 4-1. IMS IP Multimedia Subsystem (źródło: [TS23228]) Rysunek 4-1 przedstawia architekturę funkcjonalną systemu IMS. Jej główne elementy to: CSCF (Call Session Control Function) główna funkcja systemu, obejmuje serwery przeznaczone do obsługi sygnalizacji SIP: 13

o P-CSCF (Proxy-CSCF) SIP proxy z którym komunikuje się terminal użytkownika UE (User Equipment); o S-CSCF (Serving-CSCF) serwer SIP odpowiedzialny m.in. za zarządzanie wszystkimi sesjami użytkowników, obsługę rejestracji użytkowników, wybór serwera aplikacji AS dostarczającego usługę; o I-CSCF (Interrogating-CSCF) SIP proxy zlokalizowany na brzegu domeny, przeznaczony do obsługi wiadomości SIP przychodzących z innych domen; MRFC (Media Resource Function Controller) steruje MRFP (Media Resource Function Processor), który jest odpowiedzialny za obsługę strumieni multimedialnych przesyłanych do i od użytkownika, m.in. łączenia strumieni w przypadku usługi telekonferencji, konwersję kodeków pomiędzy strumieniami użytkowników, wysłanie komunikatów przeznaczonych dla użytkownika; MGCF (Media Gateway Control Function) funkcja odpowiedzialna za konwersję pomiędzy protokołem SIP a protokołem sygnalizacyjnym ISUP wykorzystywanym w sieci PSTN; IM-MGW (IMS Media Gateway Function) dokonuje transkodowania strumieni danych przesyłanych pomiędzy siecią IP i siecią z komutacją kanałów (np. PSTN); BGCF (Breakout Gateway Control Function) serwer SIP odpowiedzialny za przesyłanie wiadomości SIP według numerów telefonicznych, wykorzystywany podczas nawiązywania połączenia pomiędzy użytkownikiem sieci IMS a użytkownikiem sieci stacjonarnej PSTN; HSS (Home Subscriber Server) główna baza danych systemu, zawierająca informacje o profilu użytkownika, jego aktualnej lokalizacji, jak również dane wymagane do uwierzytelnienia i autoryzacji użytkownika; SLF (Subscription Locator Function) moduł odpowiedzialny za lokalizację HSS zawierającego informację o danym użytkowniku w sytuacji, gdy system zawiera wiele baz HSS; AS (Application Server) serwer aplikacji, dostarczający usługi oferowane użytkownikom sieci za pomocą IMS. Podczas projektowania systemu IMS założono wykorzystanie istniejących już protokołów (opracowanych przez IETF: SIP [RFC3261] oraz Diameter [RFC3588]) wszędzie tam, gdzie to jest możliwe. IMS stosuje zatem protokół SIP (interfejsy: Gm, ISC, Mg, Mi, Mj, Mk, Mr, Mw) do sygnalizacji zgłoszenia użytkownika oraz Diameter (interfejsy: Cx, Dh, Dx) dla funkcji związanych z uwierzytelnieniem i naliczaniem opłat. Standard IMS specyfikuje platformę służącą do realizacji usług multimedialnych, z pominięciem jednakże aspektów dotyczących warstwy transportowej. Dlatego też architektura IMS jako taka nie gwarantuje jakości obsługi QoS na poziomie pakietów, niemniej jednak może być zastosowana jako warstwa usługowa w sieci NGN. 14

4.1.2 ITU-T NGN Architektura sieci ITU-T NGN [ITU-Y2000][ITU-Y2001] zakłada podział funkcjonalności na dwie niezależne warstwy (Rysunek 4-2). Rysunek 4-2. Architektura sieci ITU-T NGN (źródło: [ITU-Y2000]) Pierwsza z nich to warstwa usługowa (Service stratum). Obsługuje ona sygnalizację aplikacji, w tym uwierzytelnianie i naliczanie, oraz przechowuje profil użytkownika. Realizację tej warstwy pozostawiono otwartą, i tak np. system IMS może być wykorzystany do jej realizacji. Druga warstwa (Transport stratum) związana jest z zarządzaniem sposobem przesyłania danych (Resource and Admission Control Functions RACF) oraz zarządzaniem lokalizacją użytkownika (Network Attachment Control Functions NACF). Realizacja tej warstwy oparta jest na definicji interfejsów i protokołów sygnalizacyjnych. Szczegółowy opis elementów funkcjonalnych wchodzących w jej skład przedstawiony jest w rozdziale 4.3. Ponadto specyfikacja ITU-T określa następujące wymagania, które sieć NGN powinna spełniać: umożliwienie dostępu do usług dla terminali niezależnie od tego czy posiadają funkcjonalność NGN, możliwość rozproszenia elementów funkcjonalnych, w celu poprawienia skalowalności systemu, oraz współpracy z innymi systemami za pomocą otwartych protokołów, zapewnienie bezpieczeństwa w dostępie do usług, 15

wspieranie jakości przekazu od końca do końca, wspieranie aspektów mobilności zarówno z punktu widzenia profilu użytkownika, jak i z punktu widzenia sieci. 4.1.3 ETSI TISPAN Kolejnym ciałem standaryzacyjnym zajmującym się opracowaniem architektury NGN jest ETSI, który specyfikuje architekturę TISPAN (Telecoms and Internet converged Services and Protocols for Advanced Networks) [ETSI282001]. Dzięki współpracy z ITU, architektura TISPAN jest zbliżona do architektury NGN ITU-T. Podobnie jak w NGN ITU-T, architektura TISPAN składa się z dwóch odrębnych płaszczyzn (Rysunek 4-3): usługowej (Service Layer) oraz transportowej (Transport Layer). Jako realizację warstwy usługowej dla sieci IP, TISPAN zaadoptował system IMS. Również elementy funkcjonalne wyodrębnione w warstwie transportowej, czyli NASS (Network Attachment Subsystem) zarządzający fizycznym dostępem terminala do sieci i lokalizacją użytkownika oraz RACS (Resource and Admission Control Subsystem) odpowiedzialny za zarządzanie sposobem przesyłania danych, posiadają odwzorowanie w architekturze NGN ITU-T. Są to odpowiednio funkcje NASF oraz RACF zaprezentowane na rysunku 4-2. Rysunek 4-3. Architektura NGN TISPAN (źródło: [ETSI282001]). Jedną z różnic pomiędzy architekturą TISPAN a NGN ITU-T jest obszar do którego dana architektura się odnosi. W przypadku TISPAN, RACS zdefiniowany jest dla sieci stacjonarnych, zaś zakres jego działania obejmuje jedynie sieć dostępową oraz ruter brzegowy sieci szkieletowej, a więc obszar, gdzie nie występują zmiany rozpływu ruchu związane ze zmianą rutingu. Natomiast RACF występujący w NGN ITU-T definiowany jest celem zapewnienia jakości obsługi QoS od końca do końca, obejmuje zatem zarówno sieć dostępową (stacjonarną oraz mobilną), jak i szkieletową. Można zatem przyjąć, iż funkcjonalność RACS jest podzbiorem funkcjonalności RACF [Song07]. 16

Architektura NGN opracowywana w ramach ITU jest zatem rozwiązaniem bardziej ogólnym, obejmującym wszystkie aspekty sieci NGN. 4.2 Wymagania QoS W sieci NGN rozróżniono dwa modele zapewniania jakości obsługi QoS [ITU-Y2111]. Są to: ścisłe gwarancje QoS (absolute QoS), kiedy wszystkie lub część parametrów QoS (np. opóźnienie, zmienność opóźnienia, poziom strat pakietów) jest wyspecyfikowana bezpośrednio, poprzez podanie wartości numerycznych; względne gwarancje QoS (relative QoS), kiedy poszczególne klasy usług wspierane przez sieć są obsługiwane w różny sposób, przez co uzyskują inne parametry QoS, jednakże parametry te nie są wyrażone za pomocą konkretnych wartości liczbowych. 4.3 Elementy funkcjonalne NGN Architekturę NGN możemy podzielić na następujące główne elementy funkcjonalne (Rysunek 4-4): (1) terminal użytkownika CPE (Customer Premises Equipment), (2) SCF (Service Control Functions) będący realizacją warstwy usługowej, (3) RACF zarządzający sposobem przesyłania danych (Transport Functions) w warstwie transportowej oraz (4) NACF zarządzający dostępem użytkownika do sieci. Rysunek 4-4. Elementy funkcjonalne architektury NGN ITU-T (źródło: [ITU-Y2111]). 4.3.1 Zarządzanie zasobami Rysunek 4-5 przestawia fragment architektury sieci ITU NGN z punktu widzenia funkcji zarządzania zasobami RACF [ITU-Y2111]. Wyróżniono na nim następujące elementy: PD-FE (Policy Decision Functional Entity) spełnia rolę pojedynczego punktu kontaktowego dla warstwy usługowej (SCF). PD-FE podejmuje ostateczną decyzję o przyjęciu lub odrzuceniu połączenia. Ponadto pozwala wprowadzić polityki operatora związane z charakterem dozwolonych połączeń. 17

TRC-FE (Transport Resource Control Functional Entity) ukrywa przed PD-FE aspekty związane z różnorodnością technik, które mogą zostać wykorzystane do budowy sieci. Dostarcza funkcję przyjmowania nowych wywołań (decyzja o przyjęciu zgłoszenia do obsługi podejmowana jest na podstawie zajętości zasobów), której wynik przekazuje do PD-FE. Ponadto element ten gromadzi informację o dostępnych zasobach i topologii sieci. TRE-FE (Transport Resource Enforcement Functional Entity) odpowiada za konfigurację sieci warstwy drugiej w celu zapewnienia zasobów dla połączeń. PE-FE (Policy Enforcement Functional Entity) odpowiada za kontrolę połączeń w sieci. Moduł ten zarządza: mechanizmami kontroli i kształtowania ruchu, firewall ami, klasyfikacją i oznaczaniem pakietów. NACF (Network Attachment Control Functions) zarządza fizycznym dostępem terminala do sieci, przydziela adresy IP i monitoruje lokalizację użytkownika. Service control function (SCF) Service Stratum Transport Stratum Network attachment control functions (NACF) Ru RACF Rt Rs PD-FE Rd Ri Other NGNs TRC-FE Rp Rn Rc Rw TRF-FE PE-FE Transport functions Rysunek 4-5. Architektura RACF Tabela 4-1 podsumowuje aktualny stan specyfikacji protokołów interfejsów sieci NGN ITU-T w oparciu o roboczą wersję rekomendacji Q.3300 [ITU-Q3300]. Wśród wykorzystywanych protokołów wyróżniamy: Diameter ([RFC3588]), COPS-PR (Common Open Policy Service Policy Provisioning; [RFC2748] i [RFC3084]), SNMP (Simple Network Management Protocol; [RFC3410] i późniejsze), RCIP (Resource Connection Initiation Protocol; ITU-T Q.3302.1). Sposób realizacji interfejsów Rd, Ri, Rn i Ru nie został jeszcze określony. Tabela 4-1. Protokoły przewidziane do realizacji interfejsów sieci NGN ITU-T. Interfejs Związane elementy Protokół Specyfikacja Rs SCF, PD-FE Diameter ITU-T Q.3301.1 Rp TRC-FE RCIP ITU-T Q.3302.1 Rw PD-FE, PE-FE ITU-T Q.3303.0 18

Rc TRC-FE, Transport functions COPS-PR H.248 Diameter COPS-PR SNMP ITU-T Q.3303.1 ITU-T Q.3303.2 ITU-T Q.3303.3 ITU-T Q.3304.1 ITU-T Q.3304.2 Rt PD-FE, TRC-FE Diameter ITU-T Q.3305.1 4.3.2 Sygnalizacja NGN ITU-T zakłada 3 rodzaje terminali użytkownika CPE: typ 1 to terminal bez funkcji negocjacji QoS; aby korzystać z funkcji sieci NGN wymagane jest wprowadzenie do sieci elementów pośredniczących w sygnalizacji i dokonujących translacji wiadomości sygnalizacyjnych; typ 2 to terminal, który potrafi określić zapotrzebowanie QoS za pomocą sygnalizacji warstwy usługowej; typ 3 to terminal, który potrafi określić zapotrzebowanie zasobów za pomocą sygnalizacji warstwy transportowej, np. za pomocą protokołu RSVP; jednak autoryzacja użytkownika jest wykonywana za pomocą warstwy usługowej. SCF Service Stratum Transport Stratum NACF (1) (2) (3) RACF CPE PE-FE Rysunek 4-6. Scenariusz obsługi wywołania QoS push mode. Rysunek 4-6 przedstawia scenariusz obsługi zgłoszenia przewidziany dla terminali typu 2 (push mode). Składa się on z następujących kroków: Aplikacja znajdująca się w terminalu wysyła do SCF żądanie QoS (1), które zawiera opis zasobów oraz identyfikuje użytkowników zaangażowanych w połączenie. Moduł SCF autoryzuje użytkownika i przygotowuje procedurę naliczania. Moduł SCF uzupełnia żądanie QoS o brakujące dane, np. identyfikuje użytkowników po ich adresach SIP. 19

Moduł RACF otrzymuje żądanie (2) i przeprowadza algorytm AC przyjmowania nowych połączeń. Po stwierdzeniu przez RACF, że zasoby są dostępne, moduł PE-FE otrzymuje wiadomość (3) i konfiguruje mechanizmy per flow na wejściu do sieci. SCF Service Stratum Transport Stratum (1) (3) (2) NACF RACF (5) (6) CPE (4) PE-FE Rysunek 4-7. Scenariusz obsługi wywołania QoS pull mode. W przypadku terminala typu 3 procedura obsługi zgłoszenia jest inna (pull mode). Rysunek 4-7 przedstawia jej poszczególne kroki: Aplikacja znajdująca się w terminalu wysyła do SCF żądanie obsługi (1), które nie określa dokładnie zasobów. SCF autoryzuje użytkownika i wysyła wiadomość potwierdzającą (2) do modułu RACF. Potwierdzenie to umożliwia zapytanie o dostęp do zasobów. RACF poprzez SCF odsyła do CPE specjalny token autoryzacyjny (3) [RFC3520]. CPE wysyła do sieci żądanie rezerwacji zasobów (4) identyfikowane poprzez nadany wcześniej token autoryzacyjny. Moduł PE-FE przechwytuje żądanie rezerwacji zasobów i przekazuje je do RACF (5). RACF potwierdza dostępność zasobów (6). 4.3.3 Mechanizmy QoS Tabela 4-2 opisuje podstawowe mechanizmy QoS przewidziane w dla sieci NGN. Tabela 4-2. Wybrane mechanizmy QoS rozważane dla sieci NGN ITU-T. Akronim Funkcja Opis FDP Final Decision Point Jest to ostateczny punkt decyzyjny uwzględniający polityki 20

operatora dotyczące zasobów. QMTI QoS Mapping Technology Independent Decyduje o odwzorowaniu wymagań jakości przekazu z warstwy SCF na parametry QoS sieci, np. na klasy zdefiniowane w [ITU-Y1541]. IPMC IP Packet Marking Control Decyduje o sposobie oznaczania pakietów IP w sieci. RLC Rate Limiting Control Decyduje o sposobie kontroli ruchu generowanego przez użytkownika, np. policing, shaping QMTD QoS Mapping - Technology Dependent Decyduje o odwzorowaniu wymagań jakości przekazu z uwzględnieniem ograniczeń techniki sieciowej. TDDP Technology Dependent Decision Point Podejmuje decyzję o przyjęciu połączenia w oparciu o aktualny stan zasobów sieci, NRM Network Resource Maintenance Zbiera i przechowuje aktualny stan wykorzystania zasobów w sieci. ERC Element Resource Control Zarządza stanem elementów służących do realizacji mechanizmów QoS. 4.4 Praktyczne realizacje 4.4.1 Projekt EuQoS Przykładową architekturą dla realizacji sieci IP QoS jest architektura systemu EuQoS, opracowana w ramach projektu zintegrowanego 6PR IST EuQoS [EuQoS]. Jego celem było zaprojektowanie i zaimplementowanie systemu dla wielo-usługowej sieci telekomunikacyjnej opartej o protokół IP, która potrafi zagwarantować jakość przekazu informacji w relacji koniec-koniec pomiędzy użytkownikami wybranych rodzajów aplikacji. Architekturę systemu EuQoS przedstawia Rysunek 4-8. Możemy w niej wyróżnić następujące warstwy [Bur07]: Warstwa usługowa (Service Plane serwery ASSN i AQ-SSN) określająca sposób, w jaki użytkownik komunikuje się z systemem. Rezerwacja zasobów wykonywana jest niezależnie dla każdego zgłoszenia. W tym celu zdefiniowano trzy metody nawiązania i rozłączenia połączenia: (1) za pomocą protokołu SIP (korzystając ze specjalnego serwera proxy), (2) za pomocą protokołu EQ-SIP, będącego rozszerzeniem zwykłego protokołu SIP o informację opisującą zasoby wymagane przez połączenie, lub (3) za pomocą protokołu SOAP. Warstwa ta 21

spełnia również funkcje związane z autoryzacją, uwierzytelnianiem, weryfikacją uprawnień oraz naliczaniem. Legacy application signalling USER 1 USER 1 Application ASSN Service Plane ASSN Application Application Signalling EQ-SIP AQ-SSN Application QoS based e2e signaling EQ-SIP AQ-SSN Application Signalling QCM QCM Control Plane Transport Protocols RA1 Access Network 1 Network Technology Independent layer RM1 RMi RMj COPS NSIS Network Technology Dependent layer QoS Domain i NSIS QoS Domain j EQ-path NSIS RMk QoS Domain k NSIS RM2 RA1 RA1 RA1 RA1 Transport Plane Access Network 2 Transport Protocols Rysunek 4-8. Architektura systemu EuQoS (źródło: [Bur07]). Warstwa sterowania realizacją połączeń (Network Technology Independent Layer) odpowiedzialna za realizację procesu rezerwacji zasobów w sieci, której elementami są serwery RM (Resource Manager). Jej głównym zadaniem jest odnalezienie ścieżki w sieci, która będzie obsługiwać dane połączenie. Aby zrealizować rezerwację na całej ścieżce, serwery RM komunikują się pomiędzy sobą za pomocą protokołu NSIS [RFC4080] rozszerzonego o wymaganą funkcjonalność. Realizacja pojedynczej rezerwacji dla zadanego łącza na ścieżce przekazywana jest do serwerów RA (Resource Allocator) za pomocą protokołu COPS. Warstwa rezerwacji zasobów (Network Technology Dependent Layer serwery RA) wykonująca rezerwację zasobów w oparciu o model łącza lub sieci dostępowej. Proces rezerwacji ma dwie części: (1) odwzorowanie usługi sieciowej i przeprowadzenie algorytmu przyjmowania nowych połączeń CAC, oraz (2) konfiguracja mechanizmów niezbędnych w danej technice sieciowej. Dodatkowo, zgodnie z założeniami architektury DiffServ, w pierwszym elemencie sieciowym przyjmującym ruch użytkownika dokonuje się oznaczania pakietów oraz kontroli ruchu wprowadzanego do sieci. Warstwa transportu danych, która wykorzystuje mechanizmy kolejkowania w celu zapewnienia zagwarantowania jakości przekazu w sieci. Architekturę EuQoS cechuje podobieństwo do architektury NGN ITU-T. Zakłada ona wyraźne rozgraniczenie pomiędzy warstwą usługową (Service Plane) oraz warstwą zarządzającą sposobem 22

przesyłania danych (Control Plane). Serwery ASSN i AQ-SSN tworzące warstwę usługową odpowiadają funkcjom SCF architektury NGN. Z kolei funkcja zarządzania zasobami RACF NGN jest realizowana poprzez serwery RM (posiadają funkcjonalność elementów PD-FE) oraz RA (posiadają funkcjonalność elementów PD-FE i TRC-FE). Ponadto RA wykonują funkcje elementów TRE- FE i PE-FE warstwy transportowej architektury NGN [D122]. 4.5 Podsumowanie Architektura sieci następnej generacji, zarówno w organizacjach standaryzacyjnych jak i w przykładowych implementacjach, została podzielona na dwie warstwy. Pierwsza z nich to warstwa usługowa, której celem jest dostarczenie użytkownikowi aplikacji i usług w sposób dla niego zrozumiały, zarówno ze względu na opis usług jak i na sposób naliczania opłat. Druga część związana jest z realizacją funkcjonalności transportowych dla poszczególnych połączeń IP na żądanie pomiędzy użytkownikami. Podział taki pozwala różnym dostawcom usług wykorzystać możliwości transmisyjne operatorów na równych prawach. Jedną z istotnych cech sieci następnej generacji jest wprowadzenie jakości przekazu pakietów IP. Ta cecha warstwy transportowej musi być uwzględniona w wymaganiach wszystkich funkcjonalności systemu. Wśród przedstawionych standardów najbardziej wszechstronna jest architektura ITU NGN, którą łatwo można połączyć z architekturą usługową IMS oraz metodami rozważanymi przez fora dla specyficznych technik sieciowych, np. DSL Forum, 3GPP. Ponadto, architektura ITU NGN opiera się na dekompozycji funkcji opartej na otwartych standardach protokołów komunikacyjnych. Umożliwia to współpracę urządzeń różnych producentów, a więc obniża koszt zakupu. 23

5 Technika MPLS Multi-Protocol Label Switching (MPLS) jest techniką komutacji pakietów zorientowaną połączeniowo. W odróżnieniu od techniki IP, w której rutery przesyłają pakiety na podstawie adresu docelowego bez konieczności zestawiania połączeń, ruter MPLS, zwany ruterem LSR (Label Switching Router), przesyła pakiet na podstawie etykiety umieszczonej w nagłówku MPLS w oparciu o zawartość tablicy komutacji ustanowionej w fazie zestawiania ścieżki MPLS. Etykieta MPLS jest dodawana do pakietu IP w ruterze brzegowym domeny MPLS na podstawie przynależności pakietu do klasy FEC (Forwarding Equivalence Class) uzgadnianej w fazie zestawienia ścieżki MPLS. Pakiety IP są klasyfikowane do danej ścieżki MPLS w oparciu o wartości pól nagłówka pakietu IP tj. docelowy i/lub źródłowy adres IP, rodzaj protokołu, typ klasy usług, jak również wartości pól nagłówków protokołów warstwy transportowej i wyższych, np. numeru portu źródłowego lub docelowego. Nagłówek MPLS [RFC3032] ma rozmiar 32 bitów i składa się z: (1) pola Label (20 bitów) zawierającego etykietę, (2) pola Exp (3 bity), zarezerwowanego do przyszłych zastosowań, w tym przenoszenia informacji o przynależności ścieżki do danej klasy usług, (3) pola S (Bottom of Stack, 1 bit), którego wartość równa 1 wskazuje, iż dany nagłówek MPLS stanowi ostatnią etykietę MPLS w danym pakiecie, oraz (4) pola TTL (Time-To-Live, 8 bitów), którego wartość i rola jest identyczna jak w przypadku pola TTL w nagłówku pakietu IP. Szczegółowy format pakietu MPLS przedstawia Rysunek 5-1. Rysunek 5-1. Format pakietu w technice MPLS. Główną cechą techniki MPLS jest możliwość utworzenia ścieżek MPLS, które mogą być zestawiane w sposób w pełni kontrolowany przez operatora, niezależne od dróg wyznaczonych przez dynamiczne protokóły rutingu. Ponadto, technika MPLS umożliwia zestawienie wielu dróg pomiędzy daną parą źródło i ujście, a przez to istnieje możliwość zastosowania większej grupy algorytmów rutingu, obejmującej również algorytmy rutingu źródłowego oraz wielościeżkowego. W efekcie technika MPLS umożliwia operatorowi ścisłą kontrolę nad rozpływem ruchu w sieci, a przez to zastosowanie w praktyce metod inżynierii ruchu pozwalających na optymalizację wykorzystania zasobów sieci. W przypadku sieci wielo-usługowych, technika MPLS umożliwia zestawianie niezależnych ścieżek MPLS dla poszczególnych klas usług oraz optymalizację zasobów sieci z uwzględnieniem wymagań oferowanych usług. Należy jednakże zwrócić uwagę, iż MPLS jako taka, nie umożliwia zapewnienia gwarancji jakości przekazu pakietów. Z tego względu dla realizacji sieci wielo-usługowej zapewniającej gwarancję przekazu, opracowano zasady współpracy pomiędzy techniką MPLS a DiffServ [RFC3270]. Główna idea polega na przyporządkowaniu pakietów przenoszonych w ramach ścieżek MPLS do właściwych klas usług zdefiniowanych w ramach architektury DiffServ. W ten sposób pakiety MPLS podlegają tym samym mechanizmom tj. PHB, admission control, etc., jak przypadku ruchu przenoszonego w ramach klas usług. W zależności od moż- 24

liwości ruterów, pakiety MPLS mogą korzystać z tych samych kolejek co ruch IP lub też mogą mieć dedykowane zasoby (bufory i pojemność). Z punktu wiedzenia zastosowania techniki MPLS w praktyce, należy podkreślić, iż technika ta była przewidywana do wykorzystania głównie w sieciach szkieletowych. Z tego względu, większość wiodących producentów ruterów udostępnia funkcjonalność MPLS jedynie w urządzeniach projektowych do budowy sieci szkieletowych, natomiast brak jest tej funkcjonalności w urządzeniach dostępowych i brzegowych. 5.1 Stan standaryzacji Prace standaryzacyjne dotyczące MPLS prowadzone są przez organizację IETF w ramach grup roboczych MPLS oraz PCE (Path Computation Element). Wymagania oraz architektura MPLS zostały przedstawione w zaleceniach RFC 2702 [RFC2702] oraz RFC 3031 [RFC3031]. W dokumencie [RFC3032] zdefiniowano format nagłówka MPLS oraz metody tworzenia hierarchii ścieżek przez włączanie kolejnych etykiet do nagłówka pakietu. Dokumenty [RFC5036], [RFC3037], [RFC3215], [RFC5037], [RFC5038] odnoszą się do protokołu LDP (Label Distribution Protocol), służącego do uzgadniania etykiet pomiędzy sąsiednimi ruterami LSR celem zestawienia ścieżki MPLS. Ponieważ technika MPLS pozwala na przesyłanie pakietów niezależnie od aktualnego rutingu IP, co umożliwia realizację funkcji zarządzania ruchem w sieciach IP, w ramach IETF przeprowadzono prace przystosowujące zarówno protokół sygnalizacyjny RSVP (RSVP-TE, [RFC3209], [RFC3477], [RFC4090], [RFC4420]), jak również LDP (CR-LDP, [RFC3212], [RFC3213], [RFC3214]), do przesyłania wiadomości koniecznych do zestawienia ścieżek MPLS zgodnych z wymogami zarządzania ruchem. W lutym 2003 podjęto decyzję o wstrzymaniu prac nad protokołem CR-LDP i rozwijaniu wyłącznie protokołu RSVP-TE jako podstawowego protokołu dla zarządzania ruchem w technice MPLS ([RFC3468]). Zagadnienia współpracy pomiędzy techniką MPLS a DiffServ są przedstawione w dokumentach [RFC3260], [RFC3270]. Dokumenty te definiują dwie metody przyporządkowania pakietów przenoszonych w ramach ścieżek MPLS do klas usług zdefiniowanych w technice DiffServ. Pierwsza z nich zakłada odwzorowanie wszystkich pakietów należących do danej ścieżki MPLS do jednej klasy DiffServ. W drugiej metodzie założono, że pakiety przenoszone w ramach danej ścieżki MPLS mogą być przyporządkowane do różnych klas usług DiffServ. Przyporządkowanie to jest realizowane przez nadanie odpowiedniej wartości polu EXP w nagłówku MPLS. Ze względu na długość pola EXP istnieje możliwość przyporządkowania pakietów MPLS do maksymalnie 8 klas usług DiffServ. 5.1.1 Path Computation Element Path Computation Element (PCE) jest wydzielonym elementem domeny MPLS, którego celem jest zarządzanie ścieżkami w domenie MPLS. Ponieważ zarządzanie ścieżkami jest operacją złożoną, wymagającą znacznej mocy obliczeniowej, wiedzy o stanie domeny jak również wiedzy o domenach współpracujących, zdecydowano się zdefiniować specjalizowany element przeznaczony do obliczania ścieżek zarówno wewnątrz domeny, jak i między domenami. Obliczone ścieżki są następnie konfigurowane w ruterach LSR za pomocą protokołów LDP lub RSVP-TE. Szczegółową architekturę elementów PCE przedstawiono w dokumencie [RFC4655]. 25

5.2 Zastosowania wewnątrz-domenowe Głównym zastosowaniem MPLS w obszarze domeny jest zarządzanie ruchem (Traffic Engineering). Zestawianie tuneli MPLS umożliwia operatorowi sterowanie rozpływem strumieni ruchu wewnątrz domeny. Ponadto, MPLS jest również stosowany do zabezpieczenia ścieżek w przypadku awarii. Szczegółowe opis zastosowań MPLS wewnątrz domeny przedstawiono w dokumencie [RFC4105]. 5.3 Zastosowania między-domenowe Stosowane obecnie rozwiązania bazują na scentralizowanym zarządzaniu ścieżkami, co powoduje problemy ze skalowalnością w przypadku dużych sieci. Ponadto, zestawienie ścieżek pomiędzy operatorami wymaga uzgodnień dotyczących informacji udostępnianych pomiędzy operatorami. Dlatego też zastosowanie MPLS w obszarze między-domenowym wymaga ścisłej współpracy pomiędzy operatorami. Szczegóły zastosowań techniki MPLS w obszarze między-domenowym przedstawiono w dokumencie [RFC4216]. 5.4 Praktyczne realizacje 5.4.1 Projekt EuQoS W projekcie EuQoS [EuQoS] technika MPLS została zastosowana do realizacji wirtualnych łączy między-domenowych, nazywanych EQ-link, umożliwiających połączenie domen pomiędzy którymi nie istnieją łącza fizyczne. Koncepcję zastosowania techniki MPLS w projekcie EuQoS przedstawia Rysunek 5-2. Rysunek 5-2. Koncepcja zastosowania MPLS w projekcie EuQoS (źródło: D122 Annex A [D122]). Łącza EQ-link mogą być ustanawiane pomiędzy ruterami brzegowymi domen MPLS. W projekcie EuQoS założono, że każda ścieżka MPLS przenosi ruch związany z daną klasą usług i ma dedykowane pasmo. Ścieżki MPLS są tworzone automatycznie przez elementy PCE umieszczone w po- 26