Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe. Opracowanie wymagań na system IP QoS

Transkrypt

1 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: Opracowanie wymagań na system IP QoS Przewidywany termin dostarczenia raportu: 30/06/2008 Rzeczywisty termin dostarczenia raportu: 25/06/2008 Kierownik zadania: Wykonawcy: Wojciech Burakowski PW, KTAGH, PG, NASK, WIŁ, IŁ Abstrakt: Dokument ten jest raportem z realizacji zadania badawczego A.8 Opracowanie wymagań na system IP QoS. Przedstawiona jest lista wymagań, które dotyczą architektury systemu, rodzajów aplikacji, sposobu obsługi wywołań, wymiarowania systemu, aspektów biznesowych oraz instalacji pilotowej. Raport ten jest podstawą dla specyfikacji systemu IP QoS. Słowa kluczowe: system IP QoS, architektura DiffServ, architektura NGN, obsługa wywołań, zarządzanie ruchem, sieć pilotowa, aspekty biznesowe.

2 Streszczenie Raport przedstawia wymagania dotyczące projektowanego systemu IP QoS, będące podstawą dla specyfikacji systemu. We wprowadzeniu przywołano architekturę systemu IP QoS, uwzględniającego architekturę ITU NGN oraz architekturę DiffServ. W rozdziale 1. przedstawiono szczegółowe wymagania na architekturę systemu. System podzielono na 2 główne warstwy, czyli warstwę usługową i zarządzania zasobami. Warstwa usługowa umożliwia użytkownikowi (aplikacji) wysłanie żądania zestawienia połączenia, które zawiera informacje o wymaganych zasobach dla obsługi generowanego ruchu oraz oczekiwaniach odnośnie jakości przekazu pakietów. Warstwa zarządzania zasobami odpowiada za przygotowanie elementów sieci w sposób, który spełnia oczekiwania aplikacji (użytkownika) opisane w żądaniu zestawienia połączenia. W rozdziale 2 przedstawiono wymagania dla obsługi wywołań. Odnośnie obsługi wywołań stwierdza się, iż: Dla realizacji usług sieciowych koniecznym jest zastosowanie funkcji przyjmowania nowych wywołań; Zastosowane funkcje przyjmowania nowych wywołań powinny wspierać ścisłe gwarancje jakości przekazu pakietów zarówno dla usług wspierających przekaz pakietów aplikacji strumieniowych, jak i elastycznych. Odnośnie schematu rezerwacji i alokacji zasobów stwierdza się, iż: Schemat rezerwacji i alokacji zasobów w proponowanym systemie IP QoS powinien wspierać realizację połączeń na żądanie - zakładany scenariusz obsługi żądania QoS generowanego przez użytkownika/aplikację (push mode). Sygnalizacja ta wymaga realizacji terminala użytkownika CPE w taki sposób, aby potrafił on określić zapotrzebowanie QoS za pomocą sygnalizacji warstwy usługowej. W rozdziale 3 przedstawiono wymagania dotyczące aplikacji i usług sieciowych. Stwierdza się, iż: Wymaganie 3.1: Usługi sieciowe powinny wspierać ścisłe gwarancje QoS dla następujących aplikacji: mowa, wideo na żądanie, gry interaktywne, przekaz dużych zbiorów danych. Wymaganie 3.2: Klasy usług dla aplikacji typu: mowa, wideo na żądanie, gry interaktywne, przekaz dużych zbiorów danych, powinny zapewniać ścisłe gwarancje QoS zgodnie z zaleceniami ITU-T oraz IETF. Wymaganie 3.3: Testowane w projekcie aplikacje powinny mieć zdolność wysyłania żądania QoS do sieci, tzw. aplikacje QoS. W sieci należy uwzględnić wymagania na jakość przekazu pakietów wiadomości sygnalizacyjnych. 2

3 Wymaganie 3.4: Jakość przekazu pakietów w sieci powinna być zapewniona poprzez zaimplementowanie usług sieciowych. Zalecamy stosowanie klas usług sieciowych typu koniec-koniec (end-to-end classes of service) zgodnie z zaleceniami IETF [RFC4594] oraz definicji klas usług zagregowanych zgodnie z [RFC5127]. Definicje klas usług powinny zawierać elementy zaproponowane w [RFC2216]. Wymaganie 3.5: Dla realizacji usług sieciowych koniecznym jest zastosowanie odpowiednich mechanizmów QoS i funkcji przyjmowania nowych wywołań. Wymaganie 3.6: Klasy usług powinny być definiowane w izolacji, tzn. jakość przekazu w ramach danej usługi sieciowej nie powinna zależeć, w szczególności ulegać degradacji ze względu na ruch przenoszony w ramach innych usług sieciowych. Wymaganie 3.7: Mechanizmy QoS powinny być dostępne w urządzeniach sieci IP. Mechanizmy QoS obejmują mechanizmy profilowania ruchu takie jak klasyfikatory BA i MF, mechanizmy monitorowania ruchu takie jak token bucket; mechanizmy oznaczania pakietów, mechanizmy odrzucania pakietów, oraz mechanizmy szeregowania pakietów. Mechanizmy szeregowania pakietów powinny wspierać podział zasobów między klasami ruchu oraz umożliwiać realizację proponowanych algorytmów przyjmowania nowych wywołań. Zalecane mechanizmy to CBWFQ (rutery brzegowe CISCO) oraz MDRR (rutery szkieletowe CISCO). W rozdziale 4 przedstawiono wymagania na organizację zarządzania w domenie IP QoS. Najważniejsze wymagania są następujące: Z racji swego przeznaczenia funkcja zarządzania zasobami ta musi posiadać interfejs zarządzania dla personelu administracyjnego i interfejsy komunikacji z elementami funkcjonalnymi domeny DiffServ oraz elementami funkcjonalnymi dodanymi do domeny w celu realizacji funkcji zarządzania. Elementami funkcjonalnymi są: rutery, funkcja AC, funkcja rutingu, agenci funkcji zarządzania, a w wersji rozszerzonej monitory pomiarowe [A2, A3, A7]. Te elementy funkcjonalne wynikają z wymagań na architekturę systemu przedstawioną w rozdziale 1. W rozdziale 5 przedstawiono wymagania na testowanie systemu. Najważniejsze wymagania są następujące: testy zgodności powinny obejmować sprawdzenie zgodności mechanizmów zastosowanych w urządzeniach sieciowych do realizacji usług sieciowych tj. mechanizmy profilowania ruchu, szeregowania pakietów, klasyfikatorów, itd. testy zgodności powinny obejmować sprawdzenie implementacji algorytmów przyjmowania nowych wywołań. testy zgodności powinny obejmować sprawdzenie poprawności konfiguracji urządzeń przez moduły sterujące systemu. testy zgodności powinny obejmować sprawdzenie zgodności funkcjonalności aplikacji. 3

4 testy zgodności powinny obejmować sprawdzenie zgodności styku pomiędzy aplikacją a systemem, w tym sprawdzenie poprawności obsługi sygnalizacji oraz sprawdzenie zgodności ruchu generowanego przez aplikacje. W rozdziale 6 przedstawiono wymagania na organizację zarządzania w domenie IP QoS. Najważniejsze wymagania są następujące: Umożliwienie świadczenia usług ze ścisłymi gwarancjami QoS przy minimalnych nakładach inwestycyjnych operatora. Ukierunkowanie systemu na aplikacje o dużych wymaganiach QoS (VoD, VIP, telekonferencje, interaktywne gry). Konieczność ścisłego przestrzegania gwarancji QoS ze względu na charakter potencjalnego użytkownika i aplikacji. Zapewnienie współpracy z platformami usługowymi zewnętrznych dostawców. Możliwość integracji z systemami bilingowymi i wspomagającymi zarządzanie (CRM, ERP). Dostarczenie kompletnego rozwiązania nie wymagającego zarządzania przez użytkownika. 4

5 Spis treści STRESZCZENIE...2 WPROWADZENIE ARCHITEKTURA SYSTEMU WARSTWA USŁUGOWA WARSTWA ZARZĄDZANIA ZASOBAMI WYMAGANIA DOTYCZĄCE OBSŁUGI WYWOŁAŃ ALGORYTMY PRZYJMOWANIA NOWYCH WYWOŁAŃ WYMAGANIA NA SCHEMAT REZERWACJI I ALOKACJI ZASOBÓW WYMAGANIA DOTYCZĄCE APLIKACJI I USŁUG SIECIOWYCH WYMAGANIA DOTYCZĄCE APLIKACJI QOS/QOE WYMAGANIA DOTYCZĄCE USŁUG SIECIOWYCH PODSUMOWANIE WYMAGANIA DOTYCZĄCE ORGANIZACJI ZARZĄDZANIA RUCHEM W DOMENIE ZAKRES I CEL OTOCZENIE DLA FUNKCJI ZARZĄDZANIA ZARZĄDZANE ZASOBY STRUKTURA BLOKOWO-FUNKCJONALNA FUNKCJONALNOŚĆ I ZASADA DZIAŁANIA ZASADY KOMUNIKACJI WYMAGANIA NA RUTING OPTYMALIZACJA POZOSTAŁE WYMAGANIA DOTYCZĄCE TESTOWANIA SYSTEMU WYMAGANIA DOTYCZĄCE TESTOWANIA ZGODNOŚCI Usługi sieciowe (podstawowe) Aplikacje System sygnalizacji

6 5.1.4 System zarządzania ruchem WYMAGANIA DOTYCZĄCE TESTOWANIA SPRAWNOŚCI SYSTEMU Usługi sieciowe Testy jakości postrzeganej przez użytkowników (QoE) Wydajność systemu sygnalizacji Wydajność systemu zarządzania ruchem WYMAGANIA DOTYCZĄCE ASPEKTÓW BIZNESOWYCH PODSUMOWANIE...30 LITERATURA...31 LISTA SKRÓTÓW

7 Wprowadzenie Niniejszy raport przedstawia wymagania na system IP QoS, który jest podstawą dla opracowania specyfikacji systemu. Celem opracowania systemu IP QoS jest pokazanie działania systemu IP, który może zapewnić założoną jakość przekazu pakietów, a tym samym umożliwić użytkownikom na korzystanie z aplikacji, z których nie można korzystać w zadowalający sposób w sieci IP oferującej jedynie usługę best effort. Końcowym wynikiem projektu jest pokazanie polskim operatorom rozwiązania sieci IP QoS. Na podstawie przeprowadzonej analizy architektur dla sieci IP QoS (raport A1 - Analiza architektur proponowanych dla realizacji sieci IP QoS (DiffServ, MPLS,...) oraz stanu standaryzacji), przyjęto, że 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ę: Dekompozycja funkcjonalności systemu na płaszczyznę usług (funkcje SCF) i płaszczyznę transportową (funkcje RACF i NACF); Realizacja połączeń na żądanie (zakładany scenariusz obsługi żądania QoS generowanego przez użytkownika/aplikację push mode); Użyte protokoły komunikacyjne powinny być zgodne z protokołami objętymi standaryzacją i zalecanymi dla architektury NGN. Dzięki zastosowaniu powyższej zasady, 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. Architekturę systemu przedstawia Rysunek 1-1. System IP QoS opiera się na architekturze DiffServ. Zgodnie z tą architekturą, wyróżniamy w systemie pewną liczbę klas usług, każda z nich dedykowana dla obsługi określonego profilu ruchowego i zapewniająca a priori zdefiniowane wymagania odnośnie jakości przekazu pakietów, a więc maksymalne dopuszczalne wartości takich parametrów jak prawdopodobieństwo straty pakietu, średnie czasy opóźnień w przekazie pakietów i wartości opóźnień, które powinny być mniejsze od zadanej wartości dla 99% procent pakietów (kwantyl rozkładu). Zakładamy, iż projektowany system IP QoS powinien działać przy obu wersjach protokołu IP, tj. dla wersji 4 i 6. 7

8 Struktura raportu jest następująca. W rozdziale 1. przedstawiono wymagania związane z architekturą systemu związaną z funkcją obsługi połączenia, zgodną z obecnie zdefiniowaną architekturą ITU dla sieci NGN. Rozdział 2. dotyczy wymagań dotyczących obsługi połączenia. Wymagania dotyczące badanych aplikacji i usług sieciowych w systemie IP QoS są opisane w rozdziale 3. Następny rozdział, czyli rozdział 4., dotyczy wymagań odnośnie zarządzania zasobami w sieci. Wymagania na instalację pilotową systemu przedstawia rozdział 5. Ostatecznie, w rozdziale 6. opisano wymagania na system z punktu widzenia aspektów biznesowych. Rozdział 7. podsumowuje raport. Opcja 1: explicite Sygnalizacja użytkownika Opcja 2: implicite Sieć Dostępowa Conditioning Device Ruter Brzegowy SCF SCF Diameter RACF Diameter/COPS-PR/H.248 PE-FE Ruter Szkieletowy Ruter Ruter Brzegowy Szkieletowy Ruter Szkieletowy Sieć Dostępowa Rysunek 1-1. Architektura systemu IP QoS SCF Funkcja sterowania obsługą wywołania (ang. Service Control Functions); RACF Funkcja sterowania zasobami i przyjmowaniem nowych połączeń (ang. Resource and Admission Control Function); PE-FE Funkcja ustawiania parametrów mechanizmów w ruterze (ang. Policy Enforcement Functional Entity). 8

9 1 Architektura systemu Głównym wymaganiem związanym z architekturą systemu IP QoS jest zapewnienie zgodności ze strukturą podziału funkcji jaką zaproponowano dla architektury ITU-T NGN [A1]. Z tego też powodu, funkcje opracowywanego systemu IP QoS powinny zostać podzielone na 2 główne warstwy, czyli warstwę usługową i zarządzania zasobami. Warstwa usługowa umożliwia użytkownikowi (aplikacji) wysłanie żądania zestawienia połączenia, które zawiera informacje o wymaganych zasobach dla obsługi generowanego ruchu oraz oczekiwaniach odnośnie jakości przekazu pakietów. W projekcie, skupiamy się jedynie na wymaganiach związanych z zapewnieniem przekazu pakietów w sieci. W projekcie nie są rozważane aspekty związane np. z bezpieczeństwem (autoryzacja, uwierzytelnianie, wykrywanie ataków), z naliczaniem opłat oraz zarządzaniem usługami. Warstwa zarządzania zasobami odpowiada za przygotowanie elementów sieci w sposób, który spełnia oczekiwania aplikacji (użytkownika) opisane w żądaniu zestawienia połączenia. System IP QoS powinien wspierać wszystkie wymagania związane z zarządzeniem zasobami dla zapewnienia odpowiedniej jakości przekazu pakietów. 1.1 Warstwa usługowa Głównym celem warstwy usługowej jest stworzenie mechanizmów dostępu do zasobów sieci z punktu widzenia aplikacji użytkownika. Warstwa ta jest podzielona na 3 podstawowe grupy funkcji, dla których główne wymagania są podsumowane w Tabela 1-1. F-U1: Funkcje sygnalizacji aplikacyjnej (zlokalizowane w aplikacji i w węźle warstwy usługowej). F-U2: Funkcje uzupełniające brakujące informacje w żądaniu zestawienia połączenia (zlokalizowane w węźle warstwy usługowej). F-U3: Funkcje sygnalizacji z warstwą zarządzania zasobami (zlokalizowane w węźle warstwy usługowej). Tabela 1-1: Wymagania dla warstwy usługowej. Wymaganie Grupa funkcji Opis wymagania W1.1 F-U1 Sygnalizacja aplikacyjna powinna umożliwić niezawodne przesłanie żądania zestawienia/rozłączenia połączenia od terminala użytkownika do węzła warstwy usługowej. W1.2 Stan zestawiania połączenia powinien być jednoznacznie określony zarówno w aplikacji (terminalu), jak i w węźle warstwy usługowej, w każdej fazie połączenia (zestawianie połączenia, odrzucenie połączenia, przyjęcie połączenia, trwanie połączenia, zakończenie połączenia). 9

10 W1.3 Pomiędzy aplikacją (terminalem) i węzłem warstwy usługowej powinien istnieć mechanizm okresowo sprawdzający osiągalność aplikacji (tzw. wiadomości keep alive). Mechanizm ten jest inicjalizowany przez węzeł warstwy usługowej. W1.4 F-U2 Informacje przenoszone przez wiadomości sygnalizacji aplikacyjnej muszą pozwolić jednoznacznie określić, bezpośrednio lub pośrednio, strony biorące udział w przekazie danych, tj. adresy IP nadawcy i odbiorcy, rodzaj protokołu IP oraz przynajmniej jeden numer portu protokołu transportowego (dla TCP/UDP), jak również zasoby niezbędne do realizacji tego przekazu danych. W1.5 W przypadku stosowania sygnalizacji aplikacyjnej korzystającej z własnej metody adresacji użytkowników (adresacja pośrednia), węzeł warstwy usługowej powinien być wyposażony w mechanizmy niezbędne do określenia adresów IP stron biorących udział w transmisji danych. W1.6 F-U3 Sygnalizacja z warstwą zarządzania zasobami powinna w niezawodny sposób umożliwić przesyłanie wiadomości. W1.7 Informacje przenoszone przez wiadomości sygnalizacji z warstwą zarządzania zasobami muszą bezpośrednio określać strony, pomiędzy którymi połączenie jest zestawiane oraz powinny jednoznacznie identyfikować połączenie. W1.8 Węzeł warstwy usługowej jest odpowiedzialny za synchronizację stanu połączenia, tj. w przypadku awarii węzła, jego stan musi być odtworzony. 1.2 Warstwa zarządzania zasobami Głównym celem działania warstwy zarządzania zasobami jest stworzenie mechanizmów zarządzania zasobami sieci oraz konfiguracji urządzeń sieci. Warstwa zarządzania zasobami jest podzielona na 4 podstawowe grupy funkcji, dla których główne wymagania przedstawia Tabela 1-2. F-Z1: Funkcje sygnalizacji z warstwą usługową (zlokalizowane w węźle warstwy zarządzania zasobami). F-Z2: Funkcje reprezentacji zasobów sieci (zlokalizowane w węźle warstwy zarządzania zasobami). F-Z3: Funkcje konfiguracji urządzeń sieci (zlokalizowane w węźle warstwy zarządzania zasobami). F-Z4: Funkcje wymiarowania sieci (zlokalizowane w węźle warstwy zarządzania zasobami). 10

11 Tabela 1-2: Wymagania dla warstwy zarządzania zasobami. Wymaganie Grupa funkcji Opis wymagania W1.9 F-Z1 Sygnalizacja z warstwą usługową powinna w niezawodny sposób umożliwiać przesyłanie wiadomości. W1.10 Informacje przenoszone przez wiadomości pochodzące z warstwy usługowej muszą bezpośrednio określać strony, pomiędzy którymi połączenie powinno być zestawione oraz jednoznacznie identyfikować połączenie. W1.11 Węzeł warstwy zarządzania zasobami jest odpowiedzialny za synchronizację stanu połączenia, tj. w przypadku awarii węzła, jego stan musi być odtworzony. W1.12 W przypadku niemożności przesłania odpowiedzi do warstwy usługowej, wszystkie zmiany w konfiguracji sieci związane z żądaniem muszą być wycofane. W1.13 F-Z2 Reprezentacja zasobów sieci powinna udostępniać funkcję przyjmowania nowych połączeń, która zapewnia wymaganą jakość przekazu pakietów. W1.14 Reprezentacja zasobów sieci powinna uwzględniać informację o połączeniach przyjętych do obsługi w sieci. W1.15 Reprezentacja zasobów sieci powinna umożliwić wyznaczenie zbioru elementów sieci biorących udział w obsłudze zadanego połączenia. W1.16 F-Z3 W czasie konfiguracji urządzeń sieciowych, węzeł zarządzania zasobami powinien weryfikować rezultat poleceń konfiguracyjnych. W1.17 W przypadku przyjmowania nowych połączeń, konfiguracja urządzeń sieciowych powinna być ograniczona do urządzeń brzegowych. W1.18 F-Z4 Wymiarowanie sieci powinno uwzględniać ograniczenia związane z jakością przekazu. W1.19 Wymiarowanie sieci powinno uwzględniać ograniczenia związane z prawdopodobieństwem blokady połączeń. 11

12 2 Wymagania dotyczące obsługi wywołań Wymagania dotyczące obsługi wywołań dla proponowanego systemu IP QoS podzielimy na dwie grupy wymagań. Pierwsza z nich będzie dotyczyć wymagań na algorytmy przyjmowania nowych wywołań, druga zaś wymagań na schemat rezerwacji i alokacji zasobów. 2.1 Algorytmy przyjmowania nowych wywołań Od algorytmów przyjmowania nowych wywołań (Admission Control - AC) zdefiniowanych dla sieci IP oczekuje się, iż powinny one wspierać wymagania QoS w takim samym stopniu, jak ma to miejsce dla sieci z komutacją kanałów [Bur00]. Wymagania te wyrażają się poprzez zapewnienie wartości prawdopodobieństwa odrzucenia zgłoszenia na poziomie nie większym niż około W sieci IP QoS inne są jednak warunki ruchowe, przy których to wymaganie powinno być spełnione. W sieci telefonicznej operuje się pojęciem GNR (Godzina Największego Ruchu), natomiast w sieciach IP (zwłaszcza w sieci Internet) obciążenie sieci jest mniej zróżnicowane w ciągu doby, niż w przypadku sieci telefonicznej. Zastosowanie algorytmów przyjmowania nowych wywołań i mechanizmów QoS w sieci IP wspiera zapewnienie ścisłych gwarancji jakości przekazu pakietów dla wybranych strumieni ruchu oraz umożliwia różnicowanie jakości przekazu pakietów między strumieniami ruchu należącymi do tzw. klas ruchu/klas usług [RFC4594]. Konieczność zapewnienia ścisłych gwarancji QoS oraz różnicowania QoS wynika z różnych wymagań na jakość przekazu pakietów z punktu widzenia aplikacji oraz ze zróżnicowanych charakterystyk generowanego ruchu. Ścisłe gwarancje QoS oznaczają zapewnienie takich parametrów QoS, jak np.: poziom strat pakietów, czas przekazu pakietów (zmienność), szybkość bitowa. W sieciach IP możemy również rozważać względne gwarancje QoS, przez które rozumiemy zapewnienie takich parametrów QoS, jak np.: proporcjonalny podział zasobów względem przyjętych wag obsługi klas ruchu, lub czas przekazu pakietów w proporcji do przyjętych wag. Jednakże, zgodnie z obecnymi zaleceniami organizacji ITU-T [ITU-Y1540, ITU-Y1541] oraz IETF [RFC4594] sieć IP QoS powinna spełniać ścisłe gwarancje QoS dla aplikacji takich jak np.: mowa, wideo, wideo-konferencje, przekaz dużych zbiorów danych. Wymaganie te wynikają z subiektywnych odczuć użytkowników (Quality of Experience - QoE), które przekładają się na ścisłe wymagania QoS aplikacji względem sieci. Algorytmy przyjmowania nowych wywołań w sieci IP oferującej ścisłe gwarancje QoS są kluczowym elementem, który pozwala na kontrolę przydziału zasobów w sieci, a tym samym pozwala zapobiegać niekontrolowanym przeciążeniom. Algorytmy przyjmowania nowych wywołań powinny wspierać zapewnienie jakości przekazu pakietów w ramach połączeń działających oraz nowo przyjmowanych do sieci. W tym celu w ruterach brzegowych sieci, dla każdej usługi dla obliczenia przez algorytm AC limitu pasma dedykujemy pasmo oraz bufor na łączu wyjściowym ruterów oraz zakładamy odpowiedni dla danej usługi sieciowej poziom strat pakietów. Limit pasma jest obliczany przez funkcję AC na podstawie algorytmu AC w procesie wymiarowania sieci. Funkcja ta powinna być realizowania w warstw ie odpowiedzialnej za przyjmowanie nowych wywołań. Jak powszechnie uznano, bez właściwych metod AC, nie można mówić o zapewnieniu jakości obsługi na ściśle określonym poziomie. W artykule [Mass99] argumentuje się, iż zastosowanie mechanizmów AC jest istotne dla zapewnienia QoS nie tylko dla ruchu strumieniowego, ale również 12

13 dla ruchu elastycznego, poprzez zapewnienie przynajmniej minimalnej szybkości bitowej dla obsługiwanych połączeń. Metody AC dla sieci IP ogólnie możemy podzielić na takie, które wymagają zastosowania sygnalizacji żądanych zasobów od sieci poprzez wysłanie tzw. żądania QoS przed zestawieniem połączenia lub takie, które nie stosują bezpośrednio systemu sygnalizacji żądań QoS, a działają w oparciu o identyfikację już istniejących połączeń w sieci (stosowane np. w podejściu FAN Flow Aware Networking [A2]). O ile pierwsze podejście pozwala na zapewnienie ścisłych gwarancji QoS dla wybranych strumieni pakietów, drugie podejście umożliwia jedynie względne różnicowanie jakości przekazu pakietów w ramach wybranych strumieni ruchu. Ponieważ w projekcie chcemy zapewnić ścisłe gwarancje QoS, więc wymagania dotyczące obsługi wywołań w systemie IP QoS będą się odnosić do algorytmów przyjmowania nowych wywołań, które pozwalają na rezerwację zasobów w węzłach brzegowych sieci, a w konsekwencji system ma możliwość sygnalizacji żądań QoS przez użytkowników/aplikacje. Ogólnie metody AC możemy charakteryzować wg kilku kryteriów [Shio99, Knigh99]. Ze względu na sposób oceny stanu systemu wyróżniamy metody AC: oraz bazujące na deskryptorach ruchu (Traffic Descriptor Based Admission Control) opisujących profile ruchowe. Zamiennie stosuje się również określenie tej grupy metod, jako metody bazujące na deklaracjach (Declaration Based Admission Control - DBAC). W metodach tych zakłada się, iż charakterystyki ruchu są znane a-priori i stanowią informację podawaną przez źródło ruchu. Dla tej grupy metod punktem odniesienia w ocenie stanu systemu jest to, czy założone wymagania QoS mogą być spełnione na poziomie zadeklarowanym przez źródło w deskryptorze ruchu. bazujące na pomiarach (Measurement Based Admission Control - MBAC), które określają bieżący stan systemu za pomocą metod pomiarowych, w celu predykcji zachowań systemu w przyszłości. Zazwyczaj metody typu MBAC korzystają również z deskryptorów ruchu dostarczanych przez źródło ruchu, w celu wspomagania działania metod pomiarowych. Dla tej grupy metod, deskryptory ruchu nie muszą przekazywać tak dokładnych parametrów ruchu, jak to jest oczekiwane w przypadku metod DBAC. Główny problem, związany z efektywnością działania metod typu DBAC, polega na tym, iż efektywność danej metody jest ściśle związana z dokładnością deklaracji parametrów ruchu, które podawane są a priori dla danego wywołania. W celu rozwiązania tego problemu przy metodach DBAC może być brana pod uwagę pewna nadmiarowość wynikająca z niedokładności deklaracji, dla przypadków, kiedy dostępne są pewne statystyczne opisy zachowań rozpatrywanych źródeł ruchu. Z kolei metody typu MBAC mogą, korzystając z deklaracji zawartych w deskryptorach ruchu, korygować nadmiarowość deklaracji w oparciu o pomiary ruchu w czasie realizacji połączeń. Dodatkowo, dla metod MBAC mogą być wykorzystywane prostsze opisy ruchu, tym samym pozwalając na osiągnięcie efektywności metod MBAC, podobnych do otrzymywanych dla metod DBAC. Metody DBAC można dalej podzielić na dwie grupy: metody deterministyczne (Deterministic) oraz metody statystycznej multipleksacji (Statistical Multiplexing). 13

14 Spośród metod deterministycznych wyróżniamy następujące: Analiza najgorszego przypadku (Worst Case Analysis). W tej grupie metod deterministycznie przyjmuje się zerowe straty pakietów. W konsekwencji wymagania związane z wymiarowaniem buforów oraz maksymalnym dopuszczalnym opóźnieniem wynikającym z kolejkowania pakietów są określane na podstawie najgorszego przypadku opisu ruchu. Alokacja dla maksymalnej szybkości bitowej (Peak Rate Allocation). W tym przypadku zakłada się, iż suma maksymalnych szybkości bitowych dla strumieni przyjętych do obsługi, nie może przekraczać przyjętej wielkości pasma, tzw. limitu AC. Ograniczeniem tej metody jest mała efektywność jej zastosowania np. dla źródeł o zmiennej szybkości bitowej. Jednak, z drugiej strony, jest to w miarę nie skomplikowana metoda, gwarantująca bardzo wysoką jakość obsługi. Rozważana metoda może być realizowana nie tylko w ramach metod deterministycznych, ale także wykorzystuje się statystyczne podejście do jej realizacji. Przykładowo, podejście gwarantujące pomijalną zmienność opóźnienia komórek/pakietów (negligible cell/packet delay variation) [ITU-E736, COST242]. Obie grupy metod, statystyczne metody DBAC oraz metody MBAC, mogą być także pogrupowane do różnych klas zgodnie z przyjętymi kryteriami, np. czy wpływ kolejkowania będzie brany pod uwagę przy ocenie wydajności systemu, czy też nie. W związku z tak przyjętym kryterium wyróżniamy następujące grupy metod: REM (Rate Envelope Multiplexing): metody REM zakładają mały rozmiar buforów, wystarczający jedynie na zaabsorbowanie przeciążenia wynikającego z jednoczesnego napływu pojedynczych pakietów z różnych strumieni ruchu (packet scale congestion). W konsekwencji REM pozwala na zaabsorbowanie nadmiaru pakietów wynikającego z konfliktu na poziomie pakietów (a nie na poziomie paczek pakietów). W tym przypadku chwilowa szybkość ruchu zagregowanego może przekroczyć pojemność łącza wyjściowego jedynie z bardzo małym prawdopodobieństwem, wynikającym z jednoczesnego napływu pakietów z przyjętych strumieni ruchu. Dlatego też dla tej grupy metod wpływ kolejkowania na wydajność systemu nie musi być brany pod uwagę. RSM (Rate Sharing Multiplexing): w odróżnieniu od metod typu REM, w przypadku RSM zakłada się relatywnie duży rozmiar bufora do zaabsorbowania przeciążenia wynikającego z napływu paczek pakietów (burst level congestion). Dlatego też, dla tej grupy metod konieczne jest właściwe modelowanie procesu kolejkowania pakietów w buforze, jak również dokładne, a w konsekwencji raczej skomplikowane metody opisu ruchu. Kolejne kryterium klasyfikacji metod AC dzieli metody na te, dla których ocena efektywności obsługi ruchu zależy odpowiednio od: prawdopodobieństwa straty (Loss Ratio): pozytywna decyzja o przyjęciu nowego wywołania podejmowana jest wówczas, gdy założony poziom prawdopodobieństwa strat pakietów może być zachowany. W przeciwnym przypadku, nowe wywołanie zostaje odrzucone. lub pasma efektywnego (Effective Bandwidth): decyzja o przyjęciu nowego wywołania jest podejmowana zgodnie z wyliczoną wartością pasma efektywnego dla strumienia pakietów. Wyznaczone pasmo efektywne dla strumienia, który ma być przyjęty jest sumowane wraz z 14

15 wartościami pasma efektywnego wyznaczonymi dla już przyjętych strumieni. Całkowita suma nie może przekroczyć dostępnego pasma. Tylko wówczas nowy strumień może zostać przyjęty do obsługi. Przykłady zastosowań algorytmów AC oraz mechanizmów QoS na poziomie pakietów dla sieci IP QoS zostały przedstawione dla klas usług zdefiniowanych w ramach projektów europejskich takich jak AQUILA i EuQoS w [A2]. Biorąc pod uwagę wnioski płynące z realizacji klas usług, dla projektu proponujemy zastosowanie algorytmów AC należących do grupy DBAC oraz metody bazującej na alokacji dla maksymalnej szybkości bitowej, z zastosowaniem metody REM oraz oceny efektywności obsługi ruchu bazującej na prawdopodobieństwie strat pakietów dla obsługi aplikacji strumieniowych. Dla aplikacji elastycznych, czyli FTP proponujemy zastosowanie metod należących do grupy DBAC, które wspierają się aktywnymi mechanizmami zarządzania koleją, czyli RED. Jednakże, na tym etapie projektu, dla aplikacji elastycznych nie zdefiniowano parametrów deklaracji użytkownika. Należy zauważyć, iż w przypadku stosowania metod DBAC, dla usług nie wymagających obsługi w reżimie czasu rzeczywistego, takich jak obsługa wideo na żądanie można zastosować metody kształtowania ruchu, które zminimalizują problemy z opisem ruchu o zmiennej szybkości bitowej. Zastosowanie mechanizmów kształtowania ruchu pozwala na stosowanie metod DBAC bez konieczności implementacji złożonych metod MBAC. Biorąc pod uwagę powyższą analizę możemy sformułować następujące wymaganie dotyczące realizacji algorytmów przyjmowania nowych wywołań w projekcie: Wymaganie 2.1: Dla realizacji usług sieciowych koniecznym jest zastosowanie funkcji przyjmowania nowych wywołań. Wymaganie 2.2: Zastosowane funkcje przyjmowania nowych wywołań powinny wspierać ścisłe gwarancje jakości przekazu pakietów zarówno dla usług wspierających przekaz pakietów aplikacji strumieniowych, jak i elastycznych. 2.2 Wymagania na schemat rezerwacji i alokacji zasobów Dotychczas, w ramach architektury ITU-T NGN określono dwie zasady rezerwacji zasobów i tym samym sygnalizacji dla obsługi wywołań, push i pull. W pierwszej z nich system powinien rezerwować zasoby na podstawie informacji o sieci zgromadzonej w warstwach architektury odpowiedzialnych za zarządzanie i alokację zasobów, zaś w drugim przypadku na podstawie wiedzy o stanie sieci pochodzącej bezpośrednio z odpytywanych urządzeń, np. przez sygnalizację protokołu RSVP. Jednakże dla obu metod rezerwacji zasobów, aby je zaimplementować w architekturze dla rzeczywistej sieci, należy dokładnie wyspecyfikować schemat obsługi wywołań w poszczególnych elementach systemu. W przypadku architektury DiffServ, szczegóły systemu obsługi wywołań pozo-stawiono w gestii operatorów sieci/usług. Brak jest standardów i zaleceń. Zgodnie z zaleceniami Raportu z realizacji zadania A.1 [A1], projektowany system powinien uwzględniać elementy architektury ITU-T NGN, zwłaszcza w aspektach dotyczących obsługi wywołań i rezerwacji zasobów. Bazując na tym zaleceniu, możemy sformułować następujące wymagania dotyczące obsługi wywołań w systemie IP QoS: Wymaganie 2.3: Schemat rezerwacji i alokacji zasobów w proponowanym systemie IP QoS powinien wspierać realizację połączeń na żądanie - zakładany scenariusz obsługi żąda- 15

16 nia QoS generowanego przez użytkownika/aplikację (push mode). Sygnalizacja ta wymaga realizacji terminala użytkownika CPE w taki sposób, aby potrafił on określić zapotrzebowanie QoS za pomocą sygnalizacji warstwy usługowej. Rysunek 2-1 przedstawia scenariusz obsługi zgłoszenia przewidziany dla terminali typu 2 (push mode) architektury NGN. 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. 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 NACF (1) (2) (3) RACF CPE PE-FE Rysunek 2-1. Scenariusz obsługi wywołania QoS push mode. Dla pełnej realizacji scenariusza obsługi wywołań w systemie niezbędne jest opracowanie pełnego schematu dla przyjęcia zgłoszenia zarówno w węzłach wejściowych jak i wyjściowych architektury oraz obsługi wywołania zarówno dla strony wywołującej jak i wywoływanej, np. w przypadku komunikacji dwustronnej. 16

17 3 Wymagania dotyczące aplikacji i usług sieciowych Na podstawie dotychczas przeprowadzonych analiz w ramach projektu zakładamy, że projektowana sieć IP QoS powinna wspierać jakość przekazu pakietów dla następujących aplikacji użytkownika: aplikacja głosowa VoIP, aplikacja wideo na żądanie VoD, aplikacja do transmisji zbiorów danych FTP. W rozdziale przedstawimy wymagania QoS/QoE dla tych aplikacji oraz wymagania dla usług sieciowych wspomagających obsługę wybranych aplikacji przez sieć IP. Ponieważ, w celu zestawienia połączenia w sieci konieczna jest wymiana wiadomości sygnalizacyjnych między elementami systemu, sieć powinna wspierać jakość przekazu pakietów przenoszących wiadomości sygnalizacyjne. 3.1 Wymagania dotyczące aplikacji QoS/QoE Dla sieci IP QoS oferującej ścisłe gwarancje jakości przekazu pakietów przez sieć, gwarancje QoS bezpośrednio wynikają z danego typu aplikacji i profilu generowanego przez nie ruchu. Istotne jest również, że w sieci wyróżniamy zarówno ruch generowany w ramach połączeń dla danych, jak i tzw. ruch sygnalizacyjny. W pierwszej kolejności zajmiemy się wymaganiami QoS dla ruchu generowanego w ramach połączeń dla transmisji dany. W przypadku aplikacji z reżimem czasu rzeczywistego (VoIP, gry interaktywne), które generują ruch CBR (Constant Bit Rate) sieć powinna gwarantować: bardzo małe opóźnienia pakietów i bardzo małą zmienność opóźnienia (jitter), bardzo małe straty pakietów oraz odpowiednią szybkość bitową obsługi pojedynczego strumienia (zgodną z szybkością generowania pakietów przez aplikację). Dla ruchu VBR (Variable Bit Rate) generowanego przez omawianą grupę aplikacji wymagania na jakość obsługi są podobne jak dla ruchu CBR. W przypadku ruchu elastycznego oczekiwania od sieci są różne w zależności od tego czy dane połączenie dotyczy źródła typu zachłannego czy też nie zachłannego. Dla źródeł TCP typu zachłannego (np. aplikacja FTP) wymaga się, aby dla danego połączenia sieć gwarantowała określoną a priori minimalną szybkość bitową. W szczególności, dla przekazu zbioru o danym rozmiarze, można w ten sposób określić maksymalny czas jego przesłania przez sieć. Dla źródeł TCP typu nie zachłannego (np. operacje bankowe, gry interaktywne) zwykle wymaga się, aby straty pakietów były na możliwie niskim poziomie, co w konsekwencji zapobiega niepożądanym retransmisjom pakietów i zatem pozwala na minimalizację opóźnienia przy przekazie krótkich wiadomości przez sieć. Należy przypomnieć, iż takie własności sieci są pożądane w przypadku krótkich wiadomości ale z krytycznymi wymaganiami na czas ich przekazu. Z kolei aplikacje typu wideo lub audio na żądanie mają większą tolerancję na opóźnienia pakietów, gdyż na poziomie aplikacji stosowane są tzw. bufory odtwarzające, które niwelują opóźnienia oraz zmienność opóźnień przekazu pakietów przez sieć. Zestawienie wymagań typu koniec-koniec dla wybranych aplikacji na dwóch poziomach aplikacji i sieci zawiera Tabela 3-1. Należy zwrócić uwagę, że wymagania na poziomie sieci są związane z gwarancją takich parametrów QoS, jak IPTD (IP Packet Transfer Delay), IPDV (IP Packet Delay Variation), IPLR (IP Packet Loss Ratio) [ITU-Y1540], [ITU-Y1541] i muszą być one bardziej rygorystyczne niż wymagania na poziomie aplikacji. Zaś wymagania na poziomie aplikacji przekładają się bezpośrednio na subiektywne odczucia użytkowników (QoE). 17

18 Tabela 3-1: Wymagania typu koniec-koniec dla wybranych aplikacji na poziomie aplikacji i sieci. Szybkość bitowa (poziom aplikacji) Wymagania koniec-koniec (poziom aplikacji) Wymagania koniec-koniec (poziom sieci) Opóźnienie VoIP VoD FTP 8-64kb/s <150ms (lokalne) <400ms (dalekodystansowe) kb/s < 10s Zmienność opóźnienia <1ms Pomijalna N/A Straty <3% <1% 0 IPTD Dodatkowe wymagania <100ms (lokalne) <350ms (dalekodystansowe) Nie jest krytyczne Zależy od rozmiaru zbioru i akceptowalnego czasu transmisji zbioru Czas transmisji zbioru < 15s (preferowany), <60s (akceptowalny) N/A IPDV <50ms Nie jest krytyczne N/A IPLR <10-3 <10-3 <10-3 Gwarantowana szybkość bitowa Powyższa tabela zawiera jedynie wymagania dla przekazu danych generowanych przez wybrane aplikacje. Oprócz tych wymagań, jak już wspomniano, należy zdefiniować wymagania dla przekazu wiadomości sygnalizacyjnych przez sieć (sygnalizacja użytkownik-sieć). Ruch sygnalizacyjny, powinien być tak obsługiwany w sieci, aby zapewnić użytkownikom taki czas zestawienia połączenia, który nie będzie odczuwany jako zbyt długi. Wzorując się na zaleceniach dla sieci PSTN, zakładamy że w sieci IP QoS, np. dla połączeń daleko-dystansowych czas zestawiania połączenia nie powinien być dłuższy niż 11 sekund dla 95% obsługiwanych zgłoszeń. Należy jednak zauważyć, że wpływ sieci na czas zestawienia połączenia jest tylko jednym z elementów, oprócz wpływu opóźnień wynikających z przekazu pakietów wiadomości sygnalizacyjnych przez sieć, istotny wpływ mają czasy przetwarzania w serwerach systemu sygnalizacyjnego. Przykładową analizę systemu sygnalizacji dla heterogenicznej sieci QoS można znaleźć w [Taras08], [Batalla07]. Charakterystyki ruchu sygnalizacyjnego ściśle zależą od stosowanych protokołów sygnalizacyjnych, np. SIP, NSIS (Next Step in Signaling), oraz towarzyszących im protokołów transportowych, np. UDP, TCP, SCTP (Stream Control Transimission Protocol). Dla przykładu ruch generowany przez protokół SIP charakteryzuje się tym, iż pakiety są generowane do sieci w tzw. paczkach. Podsumowując, wymiarowanie sieci dla ruchu sygnalizacyjnego powinno uwzględniać wszystkie wspomniane aspekty. Podsumowując, występowanie różnych typów ruchu w sieciach IP QoS oraz różnych wymagań na przekaz pakietów przez sieć w istotny sposób rzutuje na projektowanie klas usług sieciowych (usług telekomunikacyjnych). Każdy z typów ruchu wymaga odrębnego podejścia do jego opisu, co jest zwłaszcza konieczne przy monitorowaniu parametrów ruchu i przy podejmowaniu decyzji o przyjęciu/nie przyjęciu nowych wywołań. Jednocześnie, zróżnicowanie wymagań na jakość przekazu pakietów dla różnych strumieni ruchu wpływa na konieczność wprowadzenia do sieci mechanizmów zapewniających zróżnicowanie obsługi pakietów w poszczególnych węzłach sieci. Zapew- 18

19 nienie tych wymagań QoS przez sieć pozwoli użytkownikowi na efektywne korzystanie z danej aplikacji, charakteryzującej się danym typem generowanego ruchu i określonymi wymaganiami na jakość przekazu pakietów. 3.2 Wymagania dotyczące usług sieciowych [RFC4594] i [RFC5127] definiują zbiór usług sieciowych/klas usług (classes of service), które są rekomendowane do zaimplementowania w sieci IP QoS, dokładniej usługi te są zdefiniowane dla architektury DiffServ. Jednakże znaczenie tych usług jest szersze i mogą one być uważane za typy usług oferowanych jako usługi od-końca-do-końca (end-to-end classes of service) [RFC4594], czyli obejmujące całe połączenie pomiędzy użytkownikami lub nadawcą i odbiorcą, lub jako klasy usług zagregowanych [RFC5127]. Wykaz usług sieciowych, wraz z wartościami parametrów QoS, takimi jak IPLR, IPTD i IPTV, przedstawia Tabela 3-2. Usługa sieciowa jest implementowana na poziomie sieci i dotyczy zapewnienia jakości przekazu pakietów zgodnie z przynależnością do danej usługi. Przynależność danego pakietu (należącego do danego strumienia) do danej usługi sieciowej jest wyrażana poprzez podanie wartości pola DSCP. W urządzeniach sieciowych (tj. ruterach), przychodzący pakiet jest klasyfikowany na określoną ścieżkę obsługi, która to ścieżka obejmuje odpowiedni zestaw mechanizmów QoS i określa dostęp do przepływności bitowej łącza. W danej sieci nie jest koniecznym, aby wszystkie usługi były zaimplementowane. Wybór usług sieciowych zależy od danego operatora sieci. Na podstawie analizy w raporcie A.2 [A2] przedstawiamy przykładowe mapowanie aplikacji na usługi typu koniec-koniec dla sieci IP QoS oraz wymania QoS koniec-koniec na poziomie sieci dla sieci jedno-domenowej (nie uwzględniamy wpływu sieci dostępowych). Tabela 3-2: Wymagania QoS oraz mapowanie aplikacji na usługi sieciowe typu koniec-koniec dla jedno-domenowej sieci IP. Typy aplikacji Klasy usług Wymagania QoS koniec-koniec IPLR Średnie IPTD IPDV Rodzaj połączeń Opis ruchu VoIP Telephony ms 50 ms Punkt-punkt Gry interaktywne Wideo na żądanie FTP RT Interactive ms 50 ms Punkt-punkt MM Streaming High Throughput Data Standard s 10-3 Nie jest krytyczne Nie jest krytyczne Nie jest krytyczne Nie jest krytyczne Nie jest krytyczne Nie jest krytyczne Punkt-punkt Punkt-punkt Maksymalna szybkość bitowa Maksymalna szybkość bitowa Maksymalna szybkość bitowa Brak definicji na tym etapie projektu 19

20 3.3 Podsumowanie Na podstawie przeprowadzonej analizy możemy sformułować następujące wymagania na usługi sieciowe: Wymaganie 3.1: Usługi sieciowe powinny wspierać ścisłe gwarancje QoS dla następujących aplikacji: mowa, wideo na żądanie, gry interaktywne, przekaz dużych zbiorów danych. Wymaganie 3.2: Klasy usług dla aplikacji typu: mowa, wideo na żądanie, gry interaktywne, przekaz dużych zbiorów danych, powinny zapewniać ścisłe gwarancje QoS zgodnie z zaleceniami ITU-T oraz IETF. Wymaganie 3.3: Testowane w projekcie aplikacje powinny mieć zdolność wysyłania żądania QoS do sieci, tzw. aplikacje QoS. W sieci należy uwzględnić wymagania na jakość przekazu pakietów wiadomości sygnalizacyjnych. Wymaganie 3.4: Jakość przekazu pakietów w sieci powinna być zapewniona poprzez zaimplementowanie usług sieciowych. Zalecamy stosowanie klas usług sieciowych typu koniec-koniec (end-to-end classes of service) zgodnie z zaleceniami IETF [RFC4594] oraz definicji klas usług zagregowanych zgodnie z [RFC5127]. Definicje klas usług powinny zawierać elementy zaproponowane w [RFC2216]. Wymaganie 3.5: Dla realizacji usług sieciowych koniecznym jest zastosowanie odpowiednich mechanizmów QoS i funkcji przyjmowania nowych wywołań. Wymaganie 3.6: Klasy usług powinny być definiowane w izolacji, tzn. jakość przekazu w ramach danej usługi sieciowej nie powinna zależeć, w szczególności ulegać degradacji ze względu na ruch przenoszony w ramach innych usług sieciowych. Wymaganie 3.7: Mechanizmy QoS powinny być dostępne w urządzeniach sieci IP. Mechanizmy QoS obejmują mechanizmy profilowania ruchu takie jak klasyfikatory BA i MF, mechanizmy monitorowania ruchu takie jak token bucket; mechanizmy oznaczania pakietów, mechanizmy odrzucania pakietów, oraz mechanizmy szeregowania pakietów. Mechanizmy szeregowania pakietów powinny wspierać podział zasobów między klasami ruchu oraz umożliwiać realizację proponowanych algorytmów przyjmowania nowych wywołań. Zalecane mechanizmy to CBWFQ (rutery brzegowe CISCO) oraz MDRR (rutery szkieletowe CISCO). 20

21 4 Wymagania dotyczące organizacji zarządzania ruchem w domenie 4.1 Zakres i cel Zawartość tego rozdziału określa wymagania dotyczące funkcji zarządzania i rutingu w domenie o architekturze DiffServ obsługującej ruch, który jest zróżnicowany pod względem parametrów ruchowych i jakościowych (różne klasy usług) zgodnie z opisem w rozdziale 2 i 3. Docelowo zakłada się możliwość realizacji tych funkcji dla przypadku wsparcia tej architektury przez technologię MPLS. W wyniku działania tych funkcji ma być zapewniona ścisła gwarancja jakości obsługi strumieni ruchu poprzez przydział zasobów w postaci pasma i pojemności buforów na ściśle wyznaczonych przez funkcję rutingu drogach połączeniowych. Znajomość tych zasobów na brzegu domeny zostanie wykorzystana przez funkcję AC do kontrolowania ilości ruchu dopuszczanego do obsługi. W średnio- i długo-okresowej skali czasu obie funkcje (zarządzania i rutingu) powinny w swym działaniu nadążać za zmianami ruchu napływającego do domeny. Dodatkowo zakłada się także możliwość optymalizacji wykorzystania zasobów według kryteriów, które zostaną sprecyzowane na etapie specyfikacji systemu. Należy dołożyć starań aby rozwiązanie było zgodne z koncepcją NGN. 4.2 Otoczenie dla funkcji zarządzania Wymaganie 4.2.1: Z racji swego przeznaczenia funkcja ta musi posiadać interfejs zarządzania dla personelu administracyjnego i interfejsy komunikacji z elementami funkcjonalnymi domeny Diff- Serv oraz elementami funkcjonalnymi dodanymi do domeny w celu realizacji funkcji zarządzania. Wymaganie 4.2.2: Elementami funkcjonalnymi są: rutery, funkcja AC, funkcja rutingu, agenci funkcji zarządzania, a w wersji rozszerzonej monitory pomiarowe [A2, A3, A7]. Te elementy funkcjonalne wynikają z wymagań na architekturę systemu przedstawioną w rozdziale Zarządzane zasoby Wymaganie 4.3.1: Funkcja zarządzania w wyniku swego działania określa limit zasobów (pasmo, pojemność buforów), które funkcja AC wykorzystuje do podjęcia decyzji o przyjęciu albo odrzuceniu żądania obsługi dla każdej pary ruterów brzegowych w relacji wejście-wyjście domeny z uwzględnieniem klas usług sieciowych (przenoszenia). Wymaganie 4.3.2: Ponadto dla każdego systemu obsługi skojarzonego z łączem pomiędzy ruterami domeny musi być określone pasmo przydzielone każdej klasie obsługi ruchu oraz pojemność buforów, biorąc pod uwagę specyficzne dla każdej klasy usługi gwarancje jakości obsługi [A2, A3]. Modele stosowane do opisu ilościowego wynikają bezpośrednio z założeń i wymagań poczynionych w rozdziale 3. 21

22 4.4 Struktura blokowo-funkcjonalna Wymaganie 4.4.1: Funkcja zarządzania zasobami powinna być zrealizowana jako system scentralizowany według zasady zarządca agent. Zarządca realizowałby określone metody i algorytmy konieczne do zarządzania zasobami wynikające z obsługi klas ruchu. Agenci skojarzeni z węzłami (ruterami) domeny mają być wyposażeni tylko w funkcje komunikacji w relacji zarządca - agent oraz komunikacji z elementami funkcjonalnymi domeny w celu ich konfigurowania i pobierania określonych parametrów. Wymaganie 4.4.2: Z uwagi na potrzebę monitorowania strumieni żądań obsługi przez domenę, agent skojarzony z ruterem brzegowym domeny musi gromadzić informacje o tych zdarzeniach. Zakres zbieranych informacji jest uzależniony od klasy ruchu. W wersji rozszerzonej każdy agent byłby wyposażony także w moduł pomiarowy dla określania bieżącego stanu zasobów, tzn. ich obciążenia z podziałem na klasy ruchu. Wymaganie 4.4.3: Dla komunikacji z personelem administracyjnym konieczny jest interfejs graficzny z odpowiednio zdefiniowanym językiem komunikacji. 4.5 Funkcjonalność i zasada działania Zakłada się dwuetapowość realizacji funkcji zarządzania zasobami. W pierwszym etapie byłoby to rozwiązanie oparte o model statyczny, natomiast w drugim o model dynamiczny [A3]. Wymaganie 4.5.1: Model statyczny będzie zawierał inicjalizację stanu początkowego przydzielonych zasobów, a dla realokacji zasobów będzie wykorzystywał informacje z kontraktów ruchowych. Zmiany przydziału zasobów będą miały miejsce w oparciu o obserwacje żądań skierowanych do AC z zastosowaniem mechanizmu progowego (tryb asynchroniczny). Informacje o drogach w domenie udostępniać będzie funkcja rutingu, która powinna określać drogi w sposób statyczny. Dopuszcza się możliwość optymalizacji wykorzystania zasobów. Wymaganie 4.5.2: Model dynamiczny będzie zawierał inicjalizację stanu początkowego przydzielonych zasobów oraz dla realokacji zasobów będzie wykorzystywał informacje z pomiarów. Zmiany przydziału zasobów będą miały miejsce w oparciu o wyniki pomiaru obciążenia i obserwacje żądań skierowanych do AC z zastosowaniem mechanizmu progowego (tryb asynchroniczny). Informacje o drogach w domenie udostępniać będzie funkcja rutingu, która powinna stosować algorytm dynamiczny [A7]. Dopuszcza się możliwość optymalizacji wykorzystania zasobów [A3]. 4.6 Zasady komunikacji Wymaganie 4.6.1: Wymianę informacji rozpoczynają elementy funkcjonalne w których zaszło zdarzenie wymagające realokacji zasobów. Tymi elementami są: funkcja rutingu (nastąpiła zmiana dróg połączeniowych), agent zarządcy (przekroczenie progów liczników zdarzeń lub stanu zajętości), sam zarządca. Wymaganie 4.6.2: W pierwszym etapie realizacji zakłada się wykorzystanie, pomiędzy elementami funkcjonalnymi odpowiedzialnymi za sterowanie ruchem, istniejących protokołów komunikacji. Protokoły te powinny być ujednolicone dla całego projektu. W dalszej kolejności można uwzględ- 22

23 nić potrzebę wykorzystania lub opracowania protokołu, który spełniałby zalecenia dla koncepcji NGN. 4.7 Wymagania na ruting Wymaganie 4.7.1: Przyjęta metoda rutingu powinna znajdować ścieżkę (punkt-punkt) w sieci pomiędzy ruterami brzegowymi. Znaleziona ścieżka powinna spełniać wymagania QoS danej klasy usług. Wymaganie 4.7.2: Realizacja rutingu powinna przebiegać w dwóch etapach realizacji projektu: w pierwszym etapie ścieżka powinna być wyznaczona na podstawie przepustowości łączy, w kolejnym etapie projektu, na podstawie aktualnych stanów łączy. Wymaganie 4.7.3: Przekaz wiadomości rutingowych w sieci powinien być realizowany w domenie z najwyższym priorytetem. Wymaganie 4.7.4: Algorytmy wyznaczania drogi powinny uwzględniać wykorzystywanie w sieci protokołów IPv4 i/lub IPv6. Zakłada się opcjonalnie możliwość realizacji rutingu dla przypadku wykorzystywania technologii MPLS. Wymaganie 4.7.5: Algorytm rutingu przyjęty do znajdowania ścieżek powinien być typu precomputation. Obliczanie ścieżek i tworzenie tabel rutingu powinno odbywać się poza ruterami, za pomocą modułu centralnego mechanizmu rutingu (MCMR). Wytworzone przez MCMR tabele rutingu powinny być przesłane do wszystkich ruterów w domenie. Wymaganie 4.7.6: Dla potrzeb wyznaczania drogi w sieci, MCMR powinien posiadać bazę danych z informacją o topologii i stanach łączy (opcjonalnie baza ta może być wykonana w sposób rozproszony). Wymaganie 4.7.7: MCMR powinien posiadać zdolność komunikacji z funkcją zarządzania zasobami, w szczególności dotyczącą wymiany informacji o topologii, przepustowości łączy, tabelach rutingowych, (opcjonalnie: aktualnego obciążenia łączy i ruterów). Ponadto, MCMR może być modułem podsystemu zarządzania zasobami. Wymaganie 4.7.8: Liczba tabel rutingu przechowywana w ruterze powinna być powiązana z liczbą klas usług w domenie. Tabele rutingowe powinny być zmieniane w przypadku istotnych zmian w sieci. Wymaganie 4.7.9: W pierwszym etapie projektu tabele rutingowe powinny bazować na przepustowości łączy, a w kolejnej na dostępnym paśmie. Dodatkowo, w drugim etapie projektu powinna istnieć możliwość uwzględniania wieloparametrowych metryk. Wymaganie : Wiedzę o topologii, aktualnym stanie ścieżek i łączy w sieci powinien dostarczać podsystem pomiarowy. W pierwszej etapie projektu podsystem pomiarowy powinien ograniczać się do współdziałania z mechanizmami wykrywania topologii i przepustowości łączy. Podsystem pomiarowy powinien działać w sposób ciągły. 23