Tytuł raportu: Podsumowanie aktywności za okres styczeńczerwiec

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.0 Tytuł raportu: Podsumowanie aktywności za okres styczeńczerwiec 2008 Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: Kierownik zadania: Wykonawcy: dd/mm/yy Wojciech Burakowski PW, KTAGH, PG, NASK, WIŁ, IŁ

2 Spis treści 1 TEMATYKA PROJEKTU ZARZĄDZANIE PROJEKTEM ZADANIA REALIZOWANE W OKRESIE STYCZEŃ CZERWIEC RAPORT A1: ANALIZA ARCHITEKTUR PROPONOWANYCH DLA REALIZACJI SIECI IP QOS (DIFFSERV, MPLS) ORAZ STANU STANDARYZACJI RAPORT A2 USŁUGI I SIECI TELEINFORMATYCZNE NASTĘPNEJ GENERACJI ASPEKTY TECHNICZNE, APLIKACYJNE I RYNKOWE RAPORT A3 ANALIZA METOD I ALGORYTMÓW ZARZĄDZANIA ZASOBAMI W SIECIACH IP QOS RAPORT A4 ANALIZA USŁUG KOMERCYJNYCH DOTYCZĄCYCH SIECI IP QOS RAPORT A5: ANALIZA I OCENA METOD SUBIEKTYWNYCH I OBIEKTYWNYCH BADANIA JAKOŚCI SYGNAŁÓW AUDIO I WIDEO RAPORT A6 ANALIZA ZASTOSOWANIA MECHANIZMU RED/WRED W SIECIACH IP RAPORT A7A ANALIZA METOD ROUTINGU W SIECI IP QOS RAPORT A7B PRZEGLĄD DOSTĘPNEGO SPRZĘTU DO WYKORZYSTANIA W SIECI PILOTOWEJ RAPORT A8 OPRACOWANIE WYMAGAŃ NA SYSTEM IP QOS RAPORT A9 OPRACOWANIE WYMAGAŃ NA SIEĆ LABORATORYJNĄ SYSTEM IP QOS POSUMOWANIE

3 1 Tematyka projektu Tematem projektu jest wielo-usługowa sieć IP o strukturze jedno-domenowej. Sieć taka powinna oferować pewną liczbę usług sieciowych, przy czym poszczególne usługi powinny być dedykowane do przekazu strumieni informacyjnych wysyłanych przez określone typy aplikacji. W konsekwencji, każda z usług sieciowych powinna zapewnić inny poziom tzw. jakości przekazu pakietów mierzonej wartościach takich parametrów jak straty pakietów oraz opóźnienie przekazu pakietów (wartość średnia i zmienność opóźnienia). Tak zdefiniowaną sieć będziemy w dalszej części nazywali siecią IP QoS (Internet Protocol Quality of Service). Celem projektu jest specyfikacja architektury IP QoS, zdefiniowanie odpowiednich mechanizmów sterowania ruchem, zaimplementowanie rozwiązań, zbudowanie prototypu, przetestowanie sprawności sieci w środowisku laboratoryjnym oraz przygotowanie rozwiązania do zastosowania w sieci komercyjnej. Proponowane rozwiązanie będzie mogło być zastosowane w sieciach publicznych, pozwalając przy tym operatorom sieci na oferowanie zróżnicowanej jakości przekazu strumieni informacji. Ponadto, rozwiązanie to będzie niezmiernie przydatne do budowy sieci specjalnych wymagających jakości przekazu pakietów, w tym np. sieci e-zdrowie. Architektura sieci IP QoS dotyczy rozwiązania dla sieci jedno-domenowej i będzie wzorowana na architekturze sieci DiffServ. W stosunku do architektury DiffServ, proponowane rozwiązanie zostanie wzbogacone o warstwę sterowania nowymi wywołaniami oraz o warstwę sterowania zasobami. Stworzenie powyższych warstw pozwoli na sterowanie ruchem przychodzącym do sieci i odpowiednie zarządzanie zasobami sieci. W oparciu o specyfikację architektury, zostaną oprogramowane ww. nowe warstwy i zaimplementowane w sieci laboratoryjnej. Sieć laboratoryjna IP QoS zostanie zbudowana w oparciu o rutery komercyjne. Dla oceny jakości sieci IP QoS zostanie opracowany i zaimplementowany zestaw narzędzi pomiarowych służących do oceny jakości przedstawionego rozwiązania. Narzędzia te będą oceniały stopień zadowolenia użytkowników sieci, czyli tzw. QoE (Quality of Experience). W szczególności, oceny te będą dotyczyły oceny zadowolenia użytkownika z korzystania z aplikacji bazujących na przekazie mowy i wideo. Ostatecznie, zostanie przedstawiona analiza wprowadzenia sieci IP QoS do sieci komercyjnych. 3

4 2 Zarządzanie projektem W ramach projektu organizowane są cykliczne spotkania robocze. Do tej odbyły się następujące spotkania robocze: - Styczeń 2008, Warszawa, spotkanie rozpoczynające projekt - Marzec 2008, Warszawa, - Kwiecień 2008, Warszawa - Maj 2008, Warszawa W każdym spotkaniu uczestniczyło ok. 20 osób. Na spotkaniu w maju był obecny przedstawicie firmy CISCO. Każdy raport był oceniany wewnętrznie. 4

5 3 Zadania realizowane w okresie styczeń czerwiec 2008 Zadania przewidziane do realizacji w okresie styczeń czerwiec 2008 zamieszcza tabela 1. Tabela 1 L.p. Nazwa zadania badawczego Kierownik zadania (imię, nazwisko, jednostka) Termin rozpoczęcia realizacji zadania */ Termin zakończenia realizacji zadania */ Przewidywane koszty (zł) A Analiza stanu zaawansowania standaryzacji i implementacji sieci IP QoS oraz opracowanie wymagań na system IP QoS A. 1 Analiza architektur proponowanych dla realizacji sieci IP Wojciech Burakowski, PW QoS (DiffServ, MPLS,...) oraz stanu standaryzacji A. 2 Analiza algorytmów i mechanizmów sterowania ruchem na poziomie pakietów w sieci IP QoS Wojciech Burakowski, PW A.3 Analiza metod i algorytmów zarządzania zasobami w sieciach IP QoS Sylwester Kaczmarek, PG A. 4 Analiza usług komercyjnych dotyczących sieci IP QoS Ewa Niewiadomska- Szynkiewicz, NASK A. 5 Analiza i ocena metod subiektywnej i obiektywnej oceny Sławomir Kula, PW jakości sygnałów audio i wideo A. 6 Analiza zastosowania mechanizmu RED/WRED w sieciach IP QoS Andrzej Jajszczyk, AGH A.7 Analiza metod rutingu w sieci IP QoS Piotr Pyda, WIŁ A.8 Opracowanie wymagań na system IP QoS Wojciech Burakowski, PW Sylwester Kaczmarek, PG Andrzej Jajszczyk, AGH Piotr Pyda, WIŁ Ewa Niewiadomska- Szynkiewicz, NASK Henryk Gut, IŁ A. 9 Opracowanie wymagań na sieć laboratoryjną systemu IP QoS Wojciech Burakowski, PW Ewa Niewiadomska- Szynkiewicz, NASK Henryk Gut, IŁ Dodatkowo, w okresie styczeń-marzec 2008, Instytut łączności opracował raport Analiza dostępnego sprzętu na rynku, co pozwoliło na zorientowanie się w obecnej ofercie rynkowej dla budowy sieci pilotowej. Krótki opis poszczególnych raportów: 3.1 Raport A1: Analiza architektur proponowanych dla realizacji sieci IP QoS (DiffServ, MPLS) oraz stanu standaryzacji 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 5

6 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 (IP Multimedia Subsystem), 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, autorstwa 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 6PR 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 ś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ę: 6

7 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. Zatem, 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.2 Raport A2 Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe Dokument ten jest raportem z realizacji zadania badawczego A.2 Analiza algorytmów i mechanizmów sterowania ruchem na poziomie pakietów w sieci IP QoS. Analiza przeprowadzona w raporcie ma na celu określenie zaleceń i wytycznych dla projektu, aby na ich podstawie wybrać algorytmy i mechanizmy rekomendowane dla specyfikacji systemu IP QoS (Quality of Service). Zastosowanie algorytmów 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. 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, wideokonferencje, 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. Raport składa się z siedmiu rozdziałów. W rozdziale Błąd! Nie można odnaleźć źródła odwołania. przedstawiamy analizę aplikacji, ruchu generowanego przez te aplikacje oraz wymagań na jakość przekazu w sieciach IP QoS. Rozdział Błąd! Nie można odnaleźć źródła odwołania. zawiera analizę mechanizmów QoS dla sieci IP typu DiffServ. Analizę przeprowadzamy zarówno dla me- 7

8 chanizmów na poziomie pakietów jak i algorytmów na poziomie wywołań. Rozdział Błąd! Nie można odnaleźć źródła odwołania. przedstawia rozwiązania, które mają stanowić alternatywę dla architektury DiffServ. Alternatywne rozwiązania mają wyeliminować konieczność stosowania w systemach IP QoS sygnalizacji użykownik-sieć. Następnie, w rozdziale Błąd! Nie można odnaleźć źródła odwołania. analizujemy stan standaryzacji usług sieciowych dla sieci IP QoS. Praktyczne realizacje usług sieciowych przedstawia rozdział Błąd! Nie można odnaleźć źródła odwołania.. Raport podsumowuje analizę wnioskami i zaleceniami dla projektu w rozdziale Błąd! Nie można odnaleźć źródła odwołania.. Na podstawie przeprowadzonej analizy możemy sformułować następujące wnioski i zalecenia dla projektu: Projektowana sieć IP QOS powinna zapewniać ścisłe gwarancje QoS. Należy zatem zdefiniować wymagania na system obejmujące miary (i jeśli to możliwe podać wymagane wartości tych miar) dla oceny QoE w odniesieniu do badanych aplikacji. Pomiar QoE powinien być częścią oceny poprawnego działania systemu. Wymagania QoS stawiane projektowanemu systemowi powinny być zgodne z zaleceniami ITU-T [ITU-Y1540], [ITU-Y1541]. 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. Jakość przekazu pakietów w sieci powinna być zapewniona poprzez zaimplementowanie usług sieciowych. Zalecamy stosowanie klas usług sieciowych typu koniec-koniec (end-toend 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]. Klasy usług dla aplikacji typu, mowa, wideo, wideo-konferencja, przekaz dużych zbiorów danych powinny zapewniać ścisłe gwarancje QoS zgodnie z zaleceniami ITU-T oraz IETF. Dla realizacji usług sieciowych koniecznym jest zastosowanie odpowiednich mechanizmów QoS i funkcji przyjmowania nowych wywołań. 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). Biorąc pod uwagę wnioski płynące z realizacji klas usług, na podstawie literatury oraz w projektach naukowo badawczych jak AQUILA i EuQoS, dla projektu proponujemy zasto- 8

9 sowanie algorytmów AC należących do grupy DBAC oraz metody bazującej na alokacji dla maksymalnej szybkości bitowej oraz oceny efektywności obsługi ruchu bazującej na prawdopodobieństwie strat pakietów. W konsekwencji, proponowanym opisem ruchu w ramach pojedynczych połączeń jest opis ograniczony do podania maksymalnej szybkości bitowej PBR (Peak Bit Rate) oraz tolerancji na PBR, PBRT (Peak Bit Rate Tolerance), zgodnie z parametrami pojedynczego mechanizmu token bucket (PBR, PBRT). W celu zdefiniowania, które klasy usług typu koniec-koniec będą wspierane w projekcie wymagane jest określenie typu użytkownika (domowy/korporacyjny) oraz rodzaju aplikacji z których użytkownicy będą korzystać. Obecnie są prowadzone prace nad metodami zapewnienia jakości przekazu pakietów przez sieć, które wg założeń projektantów mają stanowić alternatywne rozwiązanie dla architektury DiffServ, jednak urządzenia dostępne na rynku nie oferują funkcjonalności proponowanych metod, np. FAN lub FSA. Zatem, metody te nie będą w projekcie rozważane. 3.3 Raport A3 Analiza metod i algorytmów zarządzania zasobami w sieciach IP QoS Właściwe wykorzystanie zasobów domeny IP QoS przy jednoczesnej gwarancji zróżnicowanej jakości oferowanej dla klas usług wymaga odpowiednio zorganizowanego zarządzania zasobami na poziomie sieci. Sprowadza się ono do podziału istniejących zasobów między poszczególne klasy tak aby dla określonego stanu zapotrzebowania na obsługę ruchu zużyć jak najmniej zasobów gwarantując jednocześnie jakość dla tych usług. Podział tych zasobów nie jest trywialnym zadaniem, gdy macierz zapotrzebowań zmienia się w czasie. W ramach realizowanego projektu badawczego zadanie A.3 dotyczy tego problemu i obejmuje analizę metod i algorytmów zarządzania zasobami domeny a w konsekwencji ich podziału i przydziału do klas usług. Wykonanie tego zadania wymagało zidentyfikowania problemu prowadzącego do wyodrębnienia istotnych cech, które mogłyby być uznane za kryteria klasyfikacji na zadania częściowe. Analiza dostępnej literatury przedmiotu doprowadziła do zauważenia faktu, że zarządzanie zasobami dla wcześniej sformułowanego celu jest ulokowane na szeregu wzajemnie powiązanych płaszczyznach funkcjonalnych. To oznacza iż poszukiwanie właściwego rozwiązania jest wielokryterialne. Otóż na skuteczność zarządzania ma wpływ szereg czynników i tym samym przy analizie należy te czynniki określić i brać pod uwagę. Za podstawowy czynnik uznano sposób realizacji funkcji przyjmowania żądań do obsługi, ponieważ ujmuje on w sobie inne istotne składniki. Są to modele źródeł ruchu i klas usług oraz modele systemów obsługi. Innym istotnym czynnikiem jest odpowiedniość modeli analitycznych opisu ruchu i rzeczywistych charakterystyk ruchowych. Decyduje ona o potrzebie lub braku wprowadzenia sprzężenia zwrotnego korygującego tą odpowiedniość. O lokowaniu i tym samym stanie zajętości zasobów w domenie także decyduje funkcja rutingu. Biorąc pod uwagę te wymienione czynniki oraz uwzględniając problem skalowalności wyróżniono cztery obszary w których dokonano analizy metod i algorytmów wykorzystywanych lub wspierających funkcje zarządzania lub ściśle z nią powiązaną funkcję AC. Te obszary to: 9

10 - metody zarządzania wspierające DBAC, - metody zarządzania wspierające MBAC, - metody zarządzania wspierające overprovisioning, - metody zarządzania oparte na projektowaniu lokacji ruchu. W każdym z obszarów rozważań dokonano analizy istotnych algorytmów, określając elementy funkcjonalne i ich lokalizację oraz zasady komunikacji. Omówiono zależności i wielkości konieczne do realizacji danego rozwiązania. Na zakończenie omawiania rozwiązań dla danego obszaru przedstawiono wady i zalety danego rozwiązania oraz wskazówki dla realizacji projektu. Mając tak przeprowadzoną analizę oraz opracowane dane zaproponowano scenariusze realizacji proponowanych rozwiązań. Obejmują one dwa podejścia, jedno w krótszej perspektywie czasowej a drugie w perspektywie produktu końcowego tego projektu badawczego. Takie podejście stopniowego wchodzenia w realizację Systemu Zarządzania jest uzasadnione zdobyciem doświadczenia i wyników mających wskazać rozwiązanie docelowe. Podyktowane to jest także i tym faktem iż szereg założeń realizacyjnych jest na starcie projektu otwartych i może być sprecyzowane dopiero po pierwszych wynikach dla rozwiązań przejściowych. Ponieważ ostateczna koncepcja rozwiązania tego systemu jest uzależniona od rozwiązań zaproponowanych w zadaniu A.2 oraz A.7 to sformułowano także szereg kwestii, które muszą być przedyskutowane, ustalone i uzgodnione wspólnie z zespołami, które realizują te zadania. Na koniec należy podkreślić, że ostateczna wersja rozwiązania systemu będzie współokreślana także przez możliwości sprzętu wykorzystywanego do budowy domeny. Wydaje się, że ten materiał oraz opracowany w ramach pozostałych zadań umożliwi wypracowanie szczegółowych wymagań na realizowany system, które to wymagania będą podzbiorem tu przedstawionych. 3.4 Raport A4 Analiza usług komercyjnych dotyczących sieci IP QoS Dokument zawiera analizę usług komercyjnych dotyczących sieci IP QoS. Analiza została przeprowadzona w dwóch głównych obszarach, usługi transmisyjne z elementami gwarancji QoS i usługi dodane wymagające mechanizmów QoS. W ramach analizy usług sieciowych z zastosowaniem mechanizmów QoS przedstawiono przykładowe usługi telekomunikacyjne, które są realizowane przez operatorów telekomunikacyjnych z wykorzystaniem mechanizmów QoS. Analiza tego segmentu rynku telekomunikacyjnego wykazała, że obecnie na rynku funkcjonalność QoS oferuje się prawie wyłącznie klientom biznesowym i realizuje się ją za pomocą wydzielonych sieci jednodomenowych. Należy podkreślić, że żadna z oferowanych na rynku usług nie dostarcza mechanizmów ściśle zapobiegających przeciążeniom oraz nie umożliwia zmiany parametrów usługi ad-hoc na żądanie klienta. 10

11 W części raportu dotyczącej usług dodanych wymagających mechanizmów QoS przeanalizowano obecną ofertę rynkową i zaproponowano sposób pogrupowania analizowanych usług ze względu na cechy funkcjonalne (grupowanie z punktu widzenia użytkownika). Następnie wskazano, które z analizowanych usług mogą być najbardziej miarodajne do wskazania kierunku kolejnych prac realizowanych w ramach projektu. Zaproponowane grupy usług to: IP TV, VoIP, wideokonferencje, radio internetowe, WEB 2.0, serwisy WWW udostępniające multimedia, gry on-line, treści 3D, przechowywanie danych, aplikacje webowe / software as a service, aplikacje krytyczne i peer to peer. Po przeanalizowaniu ww. grup usług, zaproponowano dwie grupy jako najbardziej miarodajne do testowania praktycznej efektywności systemu, który ma stanowić rezultat prac projektu. Są to usługi: wideo na żądanie VOD (Video on Demand) i interaktywna gra on-line. Przedstawiono również wstępny model biznesowy świadczenia takich usług przez operatora z wykorzystaniem projektowanego systemu IP QoS. Zwrócono uwagę na potencjalne korzyści (nie tylko finansowe) operatora i klienta oraz koszty związane z implementacją i utrzymaniem systemu gwarantującego bezwzględną jakość transmisji. Wspomniane usługi wybrano ze względu na duże wymagania na zasoby sieciowe jak i jakość transmisji. Usługi interaktywnej gry on-line zostały zaproponowane jako usługi testowe ze względu na wymagania odnośnie opóźnienia pakietów, stałości opóźnienia pakietów i utraty pakietów. Obydwie ww. grupy usług należą do dynamicznie rozwijających się segmentów rynkowych, w związku z czym opracowanie rozwiązań wspomagających świadczenie tych usług będzie stanowiło dużą wartość dla firm telekomunikacyjnych. 3.5 Raport A5: Analiza i ocena metod subiektywnych i obiektywnych badania jakości sygnałów audio i wideo W raporcie przedstawiono metody i badania jakości sygnałów audio (głównie mowy telefonicznej) i wideo. Podstawowe znaczenie mają tu metody subiektywne, bazujące na uśrednionej reakcji grupy słuchaczy (sygnał audio) lub obserwatorów. Opisano je w p.2.1, a w p.4 podano oparte na nich normy. Metody te wymagają przeprowadzania długotrwałych badań z udziałem grupy słuchaczy/obserwatorów, dlatego coraz częściej używa się mniej dokładnych, lecz łatwych w użyciu metod obiektywnych (p.2.2 i 3). Oparte są one na pomiarze sygnału audio i wideo (metody intruzyjne po stronie nadawczej i odbiorczej, nieintruzyjne wyłącznie po stronie odbiorczej) i niejako zastępują słuchacza/obserwatora, wykorzystując model percepcji (słuchowej i wzrokowej). Muszą być jednak kalibrowane z wykorzystaniem metod obiektywnych. Z kolei metody parametryczne opierają się na pomiarze wybranych, charakterystycznych, fizycznych parametrów połączenia telekomunikacyjnego i na tej podstawie określeniu jakości sygnału, bez udziału odbiorców i bez pomiarów dźwięku i obrazu. Te ostatnie są najwygodniejsze w stosowaniu, lecz najmniej dokładne. Celem zadania realizowanego w jest dostarczenie narzędzi dla operatora, pozwalających mierzyć stopień zadowolenia (QoE) usługobiorcy z aplikacji, którą ma być VoIP 11

12 Wideostreaming (Video on Demand) Gra interaktywna Wymaga to testowania end to end pojedynczego połączenia, w związku z tym postuluje się, by zapewniony był dostęp do obu terminali nadawczego i odbiorczego. W przypadku wideostreamingu wystarczy znajomość wysyłanej sekwencji wideo. Pomiar jakości przeprowadzany byłby po stronie odbiorczej, na podstawie porównania nadawanej i odebranej sekwencji wideo. Podstawowym narzędziem byłyby tu metody obiektywne, po odpowiedniej kalibracji z wykorzystaniem metod subiektywnych. W przypadku aplikacji interaktywnych (VoIP, gra) po obu stronach połączenia powinien być umieszczony agent, symulujący interlokutora (lub gracza). Automat mógłby reagować, natychmiast odpowiadając na przekaz głosowy lub wiadomość o zmianie stanu gry, umożliwiając tym pomiar opóźnienia i innych parametrów wpływających na jakość usługi. W odniesieniu do gry interaktywnej należałoby, w pierwszym etapie, przeprowadzić badania metodami subiektywnymi. Wyników tych badań można będzie użyć do kalibracji odpowiedniej metody obiektywnej (należałoby taką metodę opracować). W dalszej fazie projektu można by podjąć próbę skonstruowania, dla wymienionych na wstępie aplikacji, agentów pomiarowych działających na poziomie pakietów, bez symulacji rozmówcy czy gracza. Agenci, zainstalowani po obu stronach połączenia telekomunikacyjnego, wymienialiby się oznakowanymi pakietami, mierząc parametry połączenia (przepływność, opóźnienie pakietów, jitter opóźnienia, stopa utraty pakietów). Odpowiedni algorytm dokonywałby oszacowania QoE na podstawie wyników przeprowadzonej sesji pomiarowej. 3.6 Raport A6 Analiza zastosowania mechanizmu RED/WRED w sieciach IP W raporcie dokonano analizy mechanizmów RED/WRED pod kątem praktycznego wykorzystania do realizacji klasy usług gwarantowanych AF w sieci DiffServ. Omówiono klasę usług AF oraz budowę węzła sieci DiffServ wspierającego realizację klasy usług AF. Przedstwiono funkcjonalność poszczególnych elementów sieci DiffServ niezbędnych do realizacji klasy usług gwarantowanych takich jak klasyfikator, blok pomiaru i znakowania, blok odrzucania pakietów, mechanizm szeregowania pakietów. W dalszej części skupiono się na analizie proponowanych rozwiązań praktycznych realizujących funkcjonalność bloku pomiaru i znakowania oraz bloku odrzucania pakietów. Przedstawiono najważniejsze i najciekawsze rozwiązania znane z literatury. Szczególną uwagę poświęcono praktycznym realizacjom bloku odrzucania pakietów. Omówiono standardowy mechanizm RED oraz jego wersje z wieloma kolejkami wirtualnymi, tzw. kolejki Multi-RED. Wśród kolejek Multi-RED wyróżniono trzy najbardziej popularne i najlepiej zbadane realizacje takie jak: WRED, RIO-C oraz RIO-DC. W dalszej części opracowania przeprowadzono dyskusję na temat możliwości zastosowania poszczególnych rozwiązań w rzeczywistej sieci. Przedstawiono też propozycję praktycznego zastosowania dla klasy usług AF oferowanej przez architekturę DiffServ. 12

13 3.7 Raport A7a Analiza metod routingu w sieci IP QoS Raport zawiera analizę metod routingu dla sieci IP QoS. W kolejnych rozdziałach przedstawiono: klasyfikację metod routingu, algorytmy routingowe stosowane w sieciach IP, sposoby obliczania kosztu ścieżek oraz wagi definiowane w literaturze, metody routingu IP zalety i wady podstawowych typów protokołów, wymagania na routing QoS, metody routingu QoS IP przykłady protokołów routingowych IP QoS. Na podstawie przeprowadzonej analizy w podsumowaniu przedstawiono wstępne wnioski do etapu A8 projektu. 3.8 Raport A7b Przegląd dostępnego sprzętu do wykorzystania w sieci pilotowej Niniejszy dokument stanowi raport z realizacji zadania badawczego A.7B, które jest etapem wstępnym szerszych działań zespołu, prowadzących do budowy i uruchomienia sieci pilotowej IP QoS (zwanej także TestBedem ), umożliwiającej integrację i badanie efektywności oprogramowania do dynamicznego zarządzania ruchem w sieciach IP z gwarantowanymi parametrami QoS, opracowywanego przez pozostałe zespoły w ramach projektu pt. Zarządzanie ruchem w sieciach - sieć IP QoS. Budowa takiej sieci wymaga zastosowania zarówno odpowiedniej klasy sprzętu sieciowego (routerów) z wbudowanymi mechanizmami DiffServ i MPLS, jak i użycia właściwego zestawu pomiarowego (generatory i analizatory ruchu IP), umożliwiającego kontrolowane obciążanie ruchem IP sieci pilotowej oraz pomiar wybranych parametrów QoS w tej sieci. W części pierwszej raportu zamieszczono charakterystykę ogólna i podstawowe parametry techniczne wybranych serii routerów (z wbudowanymi mechanizmami DiffServ i MPLS), które są obecnie oferowane na rynku przez głównych dostawców sprzętu teleinformatycznego, takich jak firmy Juniper, Cisco i Alcatel- Lucent, i które jako takie mogą być zastosowane do budowy sieci pilotowej. W części drugiej raportu opisano zaś funkcjonalnie zasoby pomiarowe zarówno sprzętowe, jak i programowe, które czy to są w posiadaniu Instytutu Łączności, czy też których zakup jest planowany w ramach planu inwestycyjnego Instytutu na rok 2008, i które jako wkład własny Instytutu mogą stanowić wyposażenie tejże sieci. 3.9 Raport A8 Opracowanie wymagań na system IP QoS 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 13

14 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. 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. 14

15 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. 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). 15

16 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 Raport A9 Opracowanie wymagań na sieć laboratoryjną system IP QoS Niniejszy dokument stanowi raport z realizacji zadania badawczego A.9, które jest etapem wstępnym szerszych działań zespołu, prowadzących do budowy i uruchomienia sieci laboratoryjnej systemu IP QoS. W dalszych działaniach projektu, sieć ta będzie wykorzystywana do integracji i badania efektywności oprogramowania do dynamicznego zarządzania ruchem w sieciach IP z gwarantowanymi parametrami QoS, opracowywanego przez pozostałe zespoły w ramach projektu pt. Zarządzanie ruchem w sieciach - sieć IP QoS. Budowa takiej sieci, zwanej także TestBedem, wymaga zastosowania zarówno odpowiedniej klasy sprzętu sieciowego (routerów) z wbudowanymi mechanizmami DiffServ i MPLS, jak i użycia właściwego zestawu pomiarowego (generatory i analizatory ruchu IP, aplikacje i serwery usług testowych). Niniejszy raport jest zbiorem wymagań dotyczących zarówno funkcjonalności testbedu jako takiego, jak i tworzących go urządzeń sieciowych i pomiarowych. 16

17 4 Posumowanie Projekt jest realizowany zgodnie z planem. Następne spotkanie projektu przewidziane jest na miesiąc wrzesień