Raport z realizacji zadania badawczego: A.2 Tytuł raportu: Analiza algorytmów i mechanizmów sterowania ruchem na poziomie pakietów w sieci 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.2 Tytuł raportu: Analiza algorytmów i mechanizmów sterowania ruchem na poziomie Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: 25/06/08 Kierownik zadania: Wojciech Burakowski Wykonawcy: Halina Tarasiuk, Wojciech Burakowski, Piotr Krawiec Abstrakt: Dokument ten jest raportem z realizacji zadania badawczego A.2 Analiza algorytmów i mechanizmów sterowania ruchem na poziomie. Słowa kluczowe: algorytmy przyjmowania nowych wywołań, mechanizmy QoS na poziomie pakietów, klasy usług, ścisłe gwarancje QoS, jakość przekazu pakietów, aplikacje QoS

2 Streszczenie Dokument ten jest raportem z realizacji zadania badawczego A.2 Analiza algorytmów i mechanizmów sterowania ruchem na poziomie. 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, 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. Raport składa się z siedmiu rozdziałów. W rozdziale 2 przedstawiamy analizę aplikacji, ruchu generowanego przez te aplikacje oraz wymagań na jakość przekazu w sieciach IP QoS. Rozdział 3 zawiera analizę mechanizmów QoS dla sieci IP typu DiffServ. Analizę przeprowadzamy zarówno dla mechanizmów na poziomie pakietów jak i algorytmów na poziomie wywołań. Rozdział 4 przedstawia rozwiązania, które mają stanowić alternatywę dla architektury DiffServ. Alternatywne rozwiązania mają wyeliminować konieczność stosowania w systemach IP QoS sygnalizacji użytkownik - sieć. Następnie, w rozdziale 5 analizujemy stan standaryzacji usług sieciowych dla sieci IP QoS. Praktyczne realizacje usług sieciowych przedstawia rozdział 6. Raport podsumowuje analizę wnioskami i zaleceniami dla projektu w rozdziale 7. 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]. 2

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

4 Spis treści STRESZCZENIE WSTĘP APLIKACJE, RODZAJE RUCHU I WYMAGANIA QOS W SIECIACH IP PRZEGLĄD APLIKACJI RODZAJE RUCHU Strumieniowy Elastyczny WYMAGANIA QOS/QOE PODSUMOWANIE ALGORYTMY I MECHANIZMY QOS DLA SIECI IP POZIOM PAKIETÓW Mechanizmy klasyfikacji pakietów Mechanizmy profilowania ruchu Monitorowanie i kształtowanie ruchu Oznaczanie pakietów Odrzucanie pakietów Szeregowanie pakietów POZIOM WYWOŁAŃ Algorytmy przyjmowania nowych wywołań PODSUMOWANIE INNE MECHANIZMY RÓŻNICOWANIA JAKOŚCI OBSŁUGI METODA FAN (FLOW-AWARE NETWORKING) TECHNIKA FSA (FLOW STATE AWARE TECHNOLOGY) PODSUMOWANIE STAN STANDARYZACJI USŁUG SIECIOWYCH DLA SIECI IP QOS PRAKTYCZNE REALIZACJE USŁUG SIECIOWYCH W SIECIACH IP QOS PROJEKT AQUILA

5 6.2 USŁUGI W SIECI AQUILA Mechanizmy obsługi ruchu na poziomie pakietów Zarządzanie zasobami Sterowanie przyjmowaniem nowych wywołań Podsumowanie PROJEKT EUQOS Podsumowanie WNIOSKI I ZALECENIA DLA PROJEKTU...38 LITERATURA...40 LISTA SKRÓTÓW...44 LISTA OZNACZEŃ

6 1 Wstęp Raport dotyczy analizy 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, 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. W konsekwencji dla sieci IP QoS zdefiniowano zestaw tzw. klas usług (classes of service) sieciowych [RFC4594], które określają zdolność sieci dla przekazu strumieni ruchu przy zapewnieniu gwarancji QoS. Strumienie ruchu obsługiwane w ramach poszczególnych klas powinny charakteryzować się podobnymi parametrami opisu ruchu oraz podobnymi wymaganiami na przekaz pakietów przez sieć. W sieci IP dla zapewnia ścisłych gwarancji QoS oprócz zastosowania mechanizmów sterowania ruchem na poziomie pakietów jest konieczne zastosowanie algorytmów, które realizują funkcję przyjmowania/odrzucania nowych wywołań (Admission Control - AC), a tym samym są odpowiedzialne za regulowanie ruchu w sieci do poziomu nie przekraczającego zadany poziom dopuszczalny (Admission Control limit). Zatem, funkcja AC zapobiega również stanom przeciążenia w sieci. Należy zauważyć, iż poziom wywołań w sieci IP QoS nie jest tak jednoznacznie sprecyzowany jak np. w sieci z komutacją kanałów, gdzie wywołanie jest jednoznacznie skojarzone z zainicjowaniem przez abonenta próby nawiązania połączenia. Przykładowo, Rysunek 1-1 przedstawia wielowarstwowy model ruchu [Taras04] dla scenariusza, w którym użytkownik korzysta z aplikacji takich jak HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol) itp., które współpracują z protokołami TCP/IP (Transmission Control Protocol/Internet Protocol). Wówczas, poziom wywołań można odnieść do poziomu np. sesji, do poziomu pod-sesji lub do poziomu pojedynczego połączenia TCP. Jest oczywiste, iż model generowanego ruchu w zależności od przyjętej strategii dla wywołań jest diametralnie inny i, dodatkowo, odnosi się do innych skal czasowych. W niniejszym raporcie dokonamy analizy znanych z literatury algorytmów AC oraz przedstawimy przykłady implementacji funkcji opartych na wybranych algorytmach. Przykłady zostały wybrane spośród prototypowych implementacji systemów IP QoS, które uwzględniały funkcje z algorytmami AC. 6

7 Sesja Od minut do godzin Pod-sesja Pod-sesja Pod-sesja Minuty Połączenie Połączenie Połączenie Połączenie Od ms do minut Pakiet Pakiet Pakiet Pakiet Pakiet Pakiet Pakiet Od μs do ms Rysunek 1-1: Wielowarstwowy model ruchu w przypadku użycia przez użytkownika aplikacji typu HTTP lub FTP współpracujących ze stosem protokołów TCP/IP Raport zawiera przegląd mechanizmów QoS na poziomie pakietów, które są przewidziane w architekturze DiffServ dla wspierania gwarancji i różnicowania QoS w węzłach sieci IP (ruterach). Do grupy mechanizmów QoS do sterowania ruchem na poziomie pakietów zaliczamy mechanizmy: (1) klasyfikacji pakietów (classifiers), (2) monitorowania ruchu (meters), oznaczania pakietów (marker), kształtowania (shapers) ruchu oraz odrzucania pakietów (droppers), określane wspólną nazwą jako mechanizmy dla profilowania ruchu (traffic conditioners), oraz (3) mechanizmy szeregowania pakietów (schedulers). Na potrzeby przeglądu mechanizmów zalecanych dla sieci IP bazującej na architekturze DiffServ będziemy posługiwać się dokumentem [RFC3290]. Dokument ten proponuje pewien nieformalny model zarządzania dla ruterów działających w architekturze sieci DiffServ ( DiffServ Informal Management Model ). Dokument ten definiuje przede wszystkim mechanizmy QoS dla ruterów brzegowych oraz szkieletowych w architekturze DiffServ. W raporcie przedstawimy również przykłady praktycznych implementacji, np. mechanizmów szeregowania pakietów w ruterach dostępnych na rynku. Należy zauważyć, iż wszystkie z wymienianych mechanizmów QoS mają swoje implementacje w ruterach IP wspierających architekturę DiffServ, np. w ruterach takich producentów jak CISCO i Juniper. Raport składa się z siedmiu rozdziałów. W rozdziale 2 przedstawiamy analizę aplikacji, ruchu generowanego przez te aplikacje oraz wymagań na jakość przekazu w sieciach IP QoS. Rozdział 3 zawiera analizę mechanizmów QoS dla sieci IP typu DiffServ. Analizę przeprowadzamy zarówno dla mechanizmów na poziomie pakietów jak i algorytmów na poziomie wywołań. Rozdział 4 przedstawia rozwiązania, które mają stanowić alternatywę dla architektury DiffServ. Alternatywne rozwiązania mają wyeliminować konieczność stosowania w systemach IP QoS sygnalizacji użytkownik - sieć. Następnie, w rozdziale 5 analizujemy stan standaryzacji usług sieciowych dla sieci IP QoS. Praktyczne realizacje usług sieciowych przedstawia rozdział 6. Raport podsumowuje analizę wnioskami i zaleceniami dla projektu w rozdziale 7. 7

8 2 Aplikacje, rodzaje ruchu i wymagania QoS w sieciach IP W rozdziale przedstawiamy przegląd i klasyfikację obecnie istniejących aplikacji, z których korzystają użytkownicy sieci IP. W klasyfikacji uwzględniamy zarówno profile generowanego ruchu, jak i wymagania QoS (tzw. wymagania obiektywne) na jakość przekazu pakietów przez sieć. Należy podkreślić, iż obiektywne wymania QoS wynikają z tzw. wymagań subiektywnych (QoE) na jakość obsługi, które są odczuwane przez użytkowników aplikacji. W rozdziale podjęto analizę tych zagadnień oraz sposobu przetłumaczenia wymagań QoE na parametry QoS dotyczące jakości przekazu pakietów przez sieć. Analizę przedstawiamy na podstawie dokumentów ITU-T [ITU- Y1540], [ITU-Y1541]. Więcej informacji na temat wymagań QoE oraz metod subiektywnej i obiektywnej oceny jakości zawiera raport z realizacji zadania badawczego A Przegląd aplikacji Aplikacje dla sieci IP QoS można podzielić na dwie główne grupy (patrz Rysunek 2-1). Pierwsza grupa to aplikacje zaprojektowane dla sieci Internet oferującej jedynie usługę standardową. Z punktu widzenia sieci IP QoS są to tzw. aplikacje zastane (legacy applications). Aplikacje te można zakwalifikować do grupy aplikacji nieświadomych możliwości oferowania QoS w sieci IP (non-qosaware applications), dla uproszczenia dalej będziemy określać te aplikacje jako aplikacje standardowe. Drugą grupę aplikacji stanowią tzw. aplikacje świadome możliwości oferowania QoS (QoSaware applications), dla uproszczenia zwane dalej aplikacjami QoS. Aplikacje QoS są to aplikacje, które powinny być projektowane przy założeniu, że sieć oferuje dany zbiór klas usług sieciowych o określonych możliwościach zapewnienia gwarancji QoS. Należy podkreślić, iż takie aplikacje są wspierane przez odpowiedni protokół sygnalizacyjny typu użytkownik-sieć, pozwalający m.in. na przekaz żądania QoS do sieci. Możemy sobie wyobrazić, że idealna sieć IP QoS mogłaby obsługiwać aplikacje z obu wymienionych grup zapewniając im jakość przekazu pakietów. Jednakże, w przypadku aplikacji standardowych wymagałoby to zastosowania metod wykrywania np. wiadomości sygnalizacyjnych na poziomie sygnalizacji aplikacji, np. SIP (Session Initiation Protocol), tak żeby umożliwić identyfikację połączeń w sieci lub metod wykrywania przez sieć pakietów i oznaczania ich za pomocą kodów DSCP (Differentiated Services Code Point), żeby w sieci umożliwić ich obsługę zgodną z obsługą dla odpowiedniej klasy usług. Zastosowanie bezpośredniej sygnalizacji użytkownik-sieć tak jak w przypadku aplikacji QoS wymaga zdefiniowania interfejsu do komunikacji z siecią. Zapewnienie QoS dla aplikacji standardowych wymaga monitorowania pakietów generowanych przez sieć w celu identyfikacji połączeń, które wymagają QoS. Jednakże, dla obu przypadków można stosować w systemie te same metody rezerwacji zasobów. Spośród aplikacji standardowych można wyróżnić zarówno aplikacje wymagające jak i niewymagające zachowania reżimu czasu rzeczywistego dla przekazu pakietów przez sieć. Podobnie jak w przypadku aplikacji standardowych, również spośród aplikacji QoS można wyróżnić te, które wymagają reżimu czasu rzeczywistego i te, które nie mają takich wymagań. Przykładem aplikacji należącej do pierwszej grupy są tzw. aplikacje głosowe (Voice over IP VoIP) korzystające np. z protokółu SIP. Do tej grupy aplikacji należy zaliczyć również aplikacje realizujące wideo-konferencje, np. aplikacje, które działają w oparciu o protokół H.323. Aplikacje te generują ruch o tzw. charakterze strumieniowym. 8

9 Przykładem aplikacji standardowych nie wymagających przekazu pakietów z reżimem czasu rzeczywistego są tzw. aplikacje elastyczne. Aplikacje elastyczne korzystają z mechanizmów sterowania przekazem danych, które są zaimplementowane w warstwie transportowej. Mechanizmy te pozwalają dostosować szybkość wysyłania danych przez aplikacje do możliwości ich przekazu w sieci. Przykładami takich aplikacji są FTP, Telnet, SMTP (Simple Mail Transfer Protocol), HTTP [Wrig96]. Przykładem aplikacji, która może być zaliczana do aplikacji elastycznych lub strumieniowych, która nie wymaga zachowania reżimu czasu rzeczywistego dla przekazu pakietów w sieci, jest aplikacja wideo na żądanie. Aplikacja wideo na żądanie, w zależności od implementacji, może być realizowana w warstwie transportowej przez protokół UDP (User Datagram Protocol) lub TCP. Rysunek 2-1 podsumowuje proponowany podział aplikacji w sieciach IP QoS [Taras04]. Grupy aplikacji Aplikacje standardowe Aplikacje QoS Z reżimem czasu rzeczywistego Bez reżimu czasu rzeczywistego Z reżimem czasu rzeczywistego Bez reżimu czasu rzeczywistego Rysunek 2-1: Klasyfikacja aplikacji w sieciach IP QoS Prawie wszystkie z wymienionych aplikacji zostały zaadaptowane do aplikacji typu QoS. Przykłady takich aplikacji można znaleźć w rozwiązaniach prototypowych dla sieci IP QoS, np. AQUILA, EuQoS. Jak już wspomniano zapewnienie efektywnego działania danej aplikacji QoS wymaga dodatkowo zastosowania właściwych narzędzi wspomagających w stacji użytkownika aplikacji. Przykładem takiego narzędzia jest EAT (End user Application Toolkit) [Kem03], które wspomaga działanie zarówno aplikacji QoS, jak i aplikacji standardowych w środowisku sieci IP QoS lub realizacja sygnalizacji w projekcie EuQoS [Rodriguez08]. Więcej informacji o tych rozwiązaniach przedstawimy w rozdziale Rodzaje ruchu Zarówno aplikacje standardowe, jak i aplikacje QoS mogą generować do sieci strumienie pakietów o różnych profilach ruchowych. W sieciach IP QoS wyróżnia się dwa typy ruchu, tj. ruch strumieniowy i ruch elastyczny. 9

10 2.2.1 Strumieniowy W ramach ruchu strumieniowego, mamy strumienie pakietów generowane przez aplikacje ze stałą szybkością bitową (Constant Bit Rate - CBR) lub ze zmienną szybkością bitową (Variable Bit Rate - VBR). Źródłem ruchu strumieniowego, niezależnie od tego czy jest on typu CBR czy też VBR, mogą być aplikacje działające w reżimie czasu rzeczywistego, aplikacje interaktywne telefonia IP, wideo-konferencje lub bez reżimu czasu rzeczywistego, np. audio, czy wideo na żądanie. W obu przypadkach aplikacje korzystają np. z protokołu UDP (User Datagram Protocol) w warstwie transportowej [RFC0768] lub innych protokołów o charakterze bezpołączeniowym. Protokół UDP nie dopuszcza retransmisji utraconych pakietów. Charakter ruchu dla aplikacji z reżimem czasu rzeczywistego zależy od zastosowanego kodeka dla danej aplikacji, i to kodek determinuje, czy generowany ruch w ramach połączenia jest typu CBR, czy VBR. Dla zapewnienia przekazu z reżimie czasu rzeczywistego dla strumienia pakietów przez sieć wymaga się, aby opóźnienia przekazu poszczególnych pakietów nie przekraczały założonych wartości progowych przy jednoczesnym zachowaniu małej zmienności opóźnień. Dodatkowo, dopuszczalny poziom straty pakietów w sieci również nie powinien być większy niż założony jako dopuszczalny dla danej aplikacji. Tak postawione wymagania wiążą się z koniecznością zagwarantowania właściwej dla danej aplikacji szybkości przekazu pakietów przez sieć Elastyczny W odróżnieniu do ruchu strumieniowego, ruch elastyczny jest generowany przez źródła posiadające właściwość adaptowania szybkości wysyłania danych w zależności od obciążenia sieci. Przykładem takich źródeł są aplikacje korzystające z protokołu TCP [RFC0793, RFC3168] w warstwie transportowej, w dalszej części nazywane źródłami TCP. W przypadku ruchu elastycznego możemy wyróżnić dwa typy ruchu: (1) generowany przez źródła TCP typu zachłannego (greedy sources), np. aplikację FTP, (2) generowany przez źródła TCP typu nie zachłannego (non-greedy sources), np. aplikacje TELNET, HTTP, czyli przeglądarki WWW (Word Wide Web), SMTP poczta elektroniczna, gry interaktywne lub aplikacje realizujące zdalne operacje bankowe. W przypadku źródeł TCP typu zachłannego aplikacja w ramach połączenia ma zawsze dane do wysłania. Natomiast, w przypadku źródeł TCP typu nie zachłannego aplikacja nie zawsze ma dane do wysłania co jest charakterystyczne dla elastycznych aplikacji interaktywnych. Aplikacje elastyczne nie wymagają obsługi w reżimie czasu rzeczywistego. Aplikacja wideo na żądanie może być również realizowana przez protokół TCP. Jednak takie realizacje są raczej zalecane dla realizacji w sieciach lokalnych, gdzie straty pakietów, a w konsekwencji ich retransmisje nie przekładają się na znaczne opóźnienia ramek na poziomie aplikacji. Rysunek 2-2 podsumowuje przedstawiony podział strumieni ruchu występujących w sieciach IP QoS. 10

11 Typy ruchu IP Strumieniowy Elastyczny Stałej szybkości bitowej Zmiennej szybkości bitowej Ź ródła zachłanne Ź ródła nie zachłanne Rysunek 2-2: Typy ruchu w sieciach IP QoS Dotychczas powstało bardzo wiele implementacji protokołu TCP. Najbardziej istotną modyfikacją, w stosunku do pierwotnej wersji [RFC0793], było wprowadzenie mechanizmu zapobiegania przeciążeniom w sieci (congestion avoidance) [RFC2001]. Ta wersja TCP jest określana jako TCP Tahoe. Mechanizm zapobiegania przeciążeniom reguluje liczbę pakietów wysyłanych do sieci poprzez odpowiednie sterowanie rozmiarem okna TCP. W tym celu nadajnik wykorzystuje tzw. zduplikowane potwierdzenia wysyłane przez odbiornik. W przypadku, kiedy nie występują straty pakietów w sieci, TCP utrzymuje tendencję do stałego zwiększania szerokości okna. Zwiększając szerokość okna, TCP przechodzi odpowiednio przez fazę powolnego startu (slow start), następnie fazę zapobiegania przeciążeniom, aż do osiągnięcia maksymalnej szerokości okna [Stev96, Stev96a]. Jednak, w przypadku występowania strat pakietów w sieci, wersja TCP Tahoe okazała się mało efektywna, gdyż przy stracie pakietu, TCP rozpoczyna generowanie nowych segmentów od fazy powolnego startu. Kolejne wersje TCP, np. Reno [RFC2001], Sack, [RFC2581], New Reno [RFC2582], zostały zaproponowane w celu polepszenia efektywności TCP, w stosunku do TCP Tahoe, dla przypadków gdy w sieci występują straty pakietów. Szczególnie efektywne okazały się mechanizmy szybkiej retransmisji (fast retransmit) i szybkiego odtwarzania połączenia (fast recovery), wprowadzone w wersji TCP Reno. Na podstawie badań [Lee01], można stwierdzić, że w 2001 roku 62% stron WWW istniejących w sieci korzystało z TCP NewReno, a 41% było obsługiwanych przez TCP SACK. Wymienione powyżej wersje TCP można scharakteryzować następująco: TCP NewReno w tej wersji nieznacznie zmieniono działanie protokołu TCP Reno [RFC2582]. Celem wprowadzenia tej modyfikacji było poprawienie wydajności protokołu w przypadku, gdy dla pojedynczego okna TCP jest stracony więcej niż jeden pakiet. Ta zmiana została wprowadzona dla algorytmu szybkiego odtwarzania. Po wysłaniu zagubionego pakietu w fazie szybkiej retransmisji, jeżeli nadawca znajdujący się już w fazie szybkiego odtwarzania nie odbierze potwierdzenia wszystkich pakietów z ostatnio wysłanego okna, uznaje że pakiet o kolejnym numerze sekwencyjnym został zgubiony i retransmituje go nie czekając na upływ czasu retransmisji. Mechanizm ten zdecydowanie poprawia działanie TCP, czego potwierdzenie można odnaleźć między innymi w [Fall96]. TCP SACK modyfikacja TCP mająca poprawić działanie protokołu w przypadku straty kilku pakietów z jednego okna transmisyjnego szczególnie na łączach o znacznych opóźnieniach. Została ona szczegółowo opisana w [RFC2018]. W rozwiązaniu tym, odbiornik bezpo- 11

12 średnio informuje nadajnik o tym, które pakiety dotarły do niego, a co za tym idzie umożliwia retransmisję jedynie straconych pakietów. Niestety, dla nowych wersji TCP, kiedy występują niekontrolowane straty pakietów w sieci, predykcja zmian rozmiaru okna, a w konsekwencji dokładny opis ruchu, jest zadaniem skomplikowanym [Brand05]. Wynika to z faktu, iż poziom strat pakietów może zmieniać się w czasie. Zatem jego oszacowanie jest trudne. Dlatego też, z punktu widzenia opisu ruchu, słusznym podejściem jest dążenie do utrzymania kontrolowanych zachowań rozmiaru okna TCP [Bur03, Brand05]. Wiele pozycji literaturowych poświęcono modelowaniu ruchu TCP w sieci Internet z usługą standardową. W modelach tych jest uwzględniany wpływ poziomu strat pakietów w sieci na szybkość bitową osiąganą przez połączenia TCP np. [Pad98, Sah00]. Niestety, w przytoczonych rozważaniach zakłada się odgórną znajomość poziomu strat pakietów, np. dla pojedynczego połączenia TCP. Należy także zauważyć, iż w sieci Internet z usługą standardową, może dochodzić do stanów przeciążeń niekontrolowanych. Dlatego też, z punktu widzenia opisu ruchu, który mógłby być użyteczny dla algorytmu AC przytoczone sposoby modelowania ruchu TCP w praktyce są trudne do wykorzystania, gdyż operator usług musiałby znać poziom strat pakietów dla poszczególnych połączeń w ramach danej usługi. Jednocześnie samo rozważanie modelu ruchu dla sieci w stanie przeciążenia nie ma zastosowania w przypadku użycia algorytmów przyjmowania nowych wywołań, których zadaniem jest niedopuszczanie ruchu powodującego stany przeciążeń w sieci. Należy zauważyć, iż w przypadku, kiedy pakiety nie są tracone, zarówno TCP Tahoe, Reno, Sack oraz New Reno zachowują się tak samo, osiągając taką samą efektywność. W sieci Internet możemy również wyróżnić tzw. protokoły przyjazne TCP (TCP friendly/tcp-like), np. protokół TFRC (TCP-Friendly Rate Control Protocol) [RFC3448]. Protokół TFRC został stworzony dla obsługi aplikacji strumieniowych w sieci Internet typu best effort. Głównym założeniem działania TFRC, jest wspieranie obsługi aplikacji z reżimem czasu rzeczywistego w sieci best effort, np. audio, wideo na żądanie. Protokół TFRC [RFC3448], [RFC3448bis] nie jest samodzielnym protokołem transportowym, a jedynie protokołem z mechanizmami do zapobiegania przeciążeniom w sieci, który stanowi uzupełnienie dla protokołu transportowego takiego jak np. UDP. Głównym zadaniem TFRC jest przede wszystkim reagowanie na zmianę warunków panujących w sieci przy jednoczesnym zachowaniu płynności zmian szybkości transmisji. W ten sposób zapobiega się również degradacji jakości przekazu pakietów z działających połączeń TCP. Więcej informacji o możliwościach zastosowania protokołu TFRC oraz wyniki badań symulacyjnych można znaleźć w [Kurowski07], [Kurowski08]. 2.3 Wymagania 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ę analizą wymagań QoS dla ruchu generowanego w ramach połączeń dla transmisji dany. W przypadku aplikacji z reżimem czasu rzeczywistego, które generują ruch CBR 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 wymagania na jakość obsługi są podobne jak dla ruchu CBR. 12

13 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 danej wielkości, 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 2-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). Tabela 2-1:Wymagania typu koniec-koniec dla wybranych alikacji na poziomie aplikacji i sieci VoIP VTC (voice) VTC (video) VoD FTP Szybkość bitowa (poziom aplikacji) 8-64kb/s 6-128kb/s kb/s kb/s Zależy od rozmiaru zbioru i akceptowalnego czasu transmisji zbioru Wymagania koniec-koniec (poziom aplikacji) Opóźnienie <150ms (lokalne) <400ms (dalekodystansowe) <150ms (lokalne) <400ms (dalekodystansowe) <150ms (lokalne) <400ms (dalekodystansowe) < 10s Czas transmisji zbioru < 15s (preferowany), <60s (akceptowalny) Zmienność opóźnienia <1ms < 1ms Pomijalna Pomijalna N/A Straty <3% < 3% <1% <1% 0 Dodatkowe wymagania Synchronizacja mowy < 80ms Synchronizacja mowy < 80ms (poziom sieci) IPTD (lo- <100ms kalne) Wymagania konieckoniec <350ms (dalekodystansowe) <100ms (lokalne) <350ms (dalekodystansowe) <100ms (lokalne) <350ms (dalekodystansowe) Nie jest krytyczne N/A 13

14 IPDV <50ms <50ms <50ms N/A IPLR <10-3 <10-3 <10-3 <10-3 N/A Dodatkowe wymagania Nie jest krytyczne Synchronizacja mowy < 80ms Synchronizacja mowy < 80ms 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. Przekł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 generowanych 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. Użytkownicy sieci IP oferującej jedynie względną jakość przekazu pakietów nie mogą się spodziewać dotrzymania ścisłych gwarancji jakości przekazu a jedynie ich zróżnicowania, w zależności od przyjętych kryteriów uprzywilejowania dla wybranych strumieni pakietów. W szczególności, w [Nyb01] przyjęto jako kryterium różnicowania wartości nominalnej szybkości bitowej dla poszczególnych klas strumieni. W efekcie, w przypadku przeciążenia sieci poszczególne strumienie obsługiwane są z szybkością bitową w proporcji do żądanych przez nie szybkości nominalnych. W podejściu [Hur01] przyjęto, iż dla wybranych strumieni pakietów czasy przekazu pakietów w poszczególnych węzłach nie przekraczają zadanych wartości progowych, a w przypadku możliwości ich przekroczenia pakiety są po prostu tracone. Innym podejściem jest proporcjonalne różnicowanie opóźnień przekazu pakietów w zależności od przyjętych dla strumieni wartości nominalnych [Dov99a]. W [Taras04] zaproponowano podejście zakładające stopniowanie lepszej jakości przekazu (mniejsze opóźnienia przekazu pakietów) dla wybranych strumieni pakietów w zależności od aktualnego obciążenia ruchowego w węzłach sieci. Należy jednak zauważyć, iż relatywne gwarancje jakości przekazu pakietów nie znalazły dotychczas uznania zarówno w organizacji ITU-T [ITU-Y1540], [ITU-Y1541], jak i w realizacji sieci prototypowych. Dlatego też nie są zalecane dla realizacji tzw. klas usług QoS. 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 14

15 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. 2.4 Podsumowanie W rozdziale przedstawiono grupy aplikacji, typy ruchu oraz wymagania na jakość przekazu pakietów w sieciach IP QoS. Wyróżniono dwie grupy aplikacji, które mogą występować w rozważanych sieciach, tj. aplikacje standardowe oraz aplikacje QoS. W obu tych grupach są aplikacje wymagające obsługi z reżimem czasu rzeczywistego oraz nie wymagające takiej obsługi. W rozdziale podano wymagania na jakość przekazu pakietów kierując się wymaganiami z punktu widzenia aplikacji oraz przedstawiono rozważania na temat konieczności różnicowania jakości obsługi w sieciach IP QoS. Spośród typów ruchu występujących w sieciach IP QoS, wskazano na cztery zasadnicze grupy. Każda z grup charakteryzuje się specyficznymi i różnymi wymaganiami QoS. Zapewnienie tych wymagań 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. Podsumowując, w ramach pierwszej fazy projektu należy określić zestaw aplikacji, które ma wspierać system IP QoS, w celu zdefiniowania wymagań QoS. 15

16 3 Algorytmy i mechanizmy QoS dla sieci IP Biorąc pod uwagę rozważane w rozdziale 2 wymagania na jakość przekazu pakietów dla wybranych aplikacji, sieci IP powinny być wspierane przez algorytmy i mechanizmy sterowania ruchem, które zapewnią przekaz pakietów na zadanym poziomie QoS. W rozdziale dokonujemy przeglądu mechanizmów sterowania ruchem (mechanizmy QoS) na poziomie pakietów dla architektury DiffServ oraz algorytmów i metod przyjmowania nowych wywołań, które działają w skali czasu odpowiadającej napływom nowych wywołań do systemu. Stosowanie mechanizmów QoS oraz algorytmów przyjmowania nowych wywołań pozwoli na zapewnienie ścisłych gwarancji QoS w sieci IP i jest zalecane dla realizacji sieci IP QoS w oparciu o architektury DiffServ oraz NGN (patrz Raport z realizacji zadania A.1). 3.1 Poziom pakietów Poniżej, dokonujemy przeglądu mechanizmów QoS na poziomie pakietów. Mechanizmy te są przewidziane w architekturze DiffServ dla wspierania gwarancji i różnicowania QoS w węzłach sieci IP (ruterach). Do grupy mechanizmów QoS do sterowania ruchem na poziomie pakietów zaliczamy mechanizmy: (1) klasyfikacji pakietów, (2) monitorowania ruchu, oznaczania pakietów, kształtowania ruchu oraz odrzucania pakietów, określane wspólną nazwą jako mechanizmy dla profilowania ruchu, oraz (3) mechanizmy szeregowania pakietów. Na potrzeby przeglądu mechanizmów zalecanych dla sieci IP bazującej na architekturze DiffServ będziemy posługiwać się dokumentem IETF [RFC3290]. Dokument ten proponuje pewien nieformalny model zarządzania dla ruterów działających w architekturze sieci DiffServ. W raporcie przedstawimy również przykłady praktycznych implementacji, np. mechanizmów szeregowania pakietów w ruterach dostępnych na rynku. Należy zauważyć, iż urządzenia w sieci testowej projektu powinny być wyposażone w wymienione mechanizmy. Obecnie, mechanizmy te mają swoje implementacje w ruterach IP wspierających architekturę DiffServ, np. w ruterach takich producentów jak CISCO i Juniper. Zgodnie z architekturą DiffServ, mechanizmy sterowania ruchem na poziomie pakietów powinny być zaimplementowane w węzłach sieci IP i odnoszą się do sposobu obsługi poszczególnych pakietów w danym węźle (Per Hop Behaviour - PHB). Mechanizmy te realizują swoje funkcje w skali czasowej mikro- lub mili-sekund (w zależności od szybkości łączy w sieci). Mechanizmy QoS powinny wspierać zapewnienie takich wymagań QoS jak dopuszczalne opóźnienie przekazu pakietów przez sieć, dopuszczalna zmienność tego opóźnienia, dopuszczalne prawdopodobieństwo utraty pakietów wynikające z chwilowego przeciążenia sieci, czy też zapewnienie danej średniej szybkości bitowej przekazu pakietów Mechanizmy klasyfikacji pakietów Mechanizmy klasyfikacji pakietów składają się z klasyfikatorów, które realizują filtrowanie pakietów przychodzących do danego węzła. Klasyfikatory służą np. do przyporządkowania napływających pakietów do poszczególnych usług sieciowych na podstawie wartości przyjętych pól nagłówka IP. Odpowiednie elementy filtrujące dzielą pakiety na dopasowane i nie dopasowane do przyjętego modelu filtra. W oparciu o dokonaną selekcję, pakiety są przekazywane dalej, czyli na właściwą ścieżkę przekazu (datapath) w węźle. Klasyfikator za pomocą filtrów może dokonywać rozdzie- 16

17 lenia pojedynczego napływającego strumienia ruchu na wiele strumieni. Liczba możliwych strumieni ruchu, wychodzących z klasyfikatora, zależy od liczby przyjętych filtrów. Najprostszym modelem klasyfikatora jest taki klasyfikator, który uznaje wszystkie przychodzące pakiety za dopasowane i wówczas strumień wyjściowy pakietów jest po prostu strumieniem wejściowym. Filtry mogą działać np. w oparciu o wartości wybranego pola nagłówka pakietu, bądź też kilku pól. Przykładowo, Tabela 3-1 przedstawia możliwe ustawienia filtrów dla klasyfikatora odpowiedzialnego za przyporządkowanie napływających do danego węzła strumieni pakietów do uprzednio zdefiniowanych klas ruchu, czyli klasyfikatora typu BA (Behaviour Aggregate) zdefiniowanego dla architektury DiffServ [RFC3290]. Dla tego przypadku, klasyfikacja pakietów jest przeprowadzana na podstawie wartości pola DSCP (Differentiated Services Code Point) nagłówka pakietu IPv4. Innym przykładem jest klasyfikator, który może być zastosowany np. w ruterach brzegowych, nazywanym klasyfikatorem MF (Multi-Field), który działa na podstawie wartości kilku pól nagłówka IPv4, np.: adresu źródłowego, adresu docelowego, źródłowego portu TCP, docelowego portu TCP. Klasyfikator taki jest niezbędny przy klasyfikacji pakietów należących do pojedynczego strumienia. Tabela 3-1: Przykład klasyfikatora BA z trzema filtrami Filtr DSCP Filtr Filtr Filtr3 Pozostałe Mechanizmy profilowania ruchu Jak powyżej wspomniano, mechanizmy profilowania ruchu realizują [RFC2475]: monitorowanie ruchu, kształtowanie ruchu, oznaczanie pakietów, oraz odrzucanie pakietów. Rysunek 3-1 przedstawia schemat blokowy logicznych powiązań między mechanizmami dla klasyfikacji pakietów i profilowania ruchu [RFC2475]. Należy zauważyć, iż mechanizmy profilowania ruchu zastosowane dla konkretnej klasy usług, nie muszą zawierać wszystkich czterech realizowanych funkcji. Wybór zestawu funkcji zależy np. od sposobu realizacji danej usługi w sieci. Monitorowanie Pakiety Klasyfikacja Oznaczanie Kształtowanie/ Odrzucanie Rysunek 3-1: Logiczne powiązania między mechanizmami klasyfikacji pakietów oraz profilowania ruchu w węźle sieci 17

18 Monitorowanie i kształtowanie ruchu Monitorowanie ruchu ma na celu sprawdzenie, czy dany strumień pakietów ma profil zgodny, czy niezgodny z założonym. Monitorowanie ruchu odbywa się za pomocą elementów, które w oparciu o przyjęte profile ruchu oraz poziomy zgodności, dzielą pojedynczy strumień wejściowy pakietów na wiele strumieni wyjściowych. Liczba strumieni wyjściowych zależy od liczby przyjętych poziomów zgodności [RFC3290]. Najczęściej stosowany mechanizm monitorowania ruchu to mechanizm token bucket. Token bucket jest opisany dwoma parametrami (R, B), gdzie R oznacza stałą szybkość napływu tokenów do puli, zaś B maksymalny rozmiar puli tokenów. Ponieważ w sieciach IP występują pakiety o zmiennej długości możemy wyróżnić przynajmniej dwa testy zgodności dla mechanizmu token bucket: (1) test pełnej zgodności oraz (2) test częściowej zgodności. W pierwszym przypadku, pakiet o rozmiarze L bajtów jest uznawany za zgodny tylko wówczas, jeżeli w chwili przybycia pakietu, liczba zgromadzonych tokenów w puli jest nie mniejsza niż rozmiar przybywającego pakietu. W uproszczeniu strumień pakietów jest uznany za zgodny z parametrami token bucket (R, B), jeżeli maksymalna ilość danych napływających do token bucket, w pewnym przedziale czasowym t, nie przekracza wartości opisanej następującym wyrażeniem: ( R t) + B * Rów. 3-1 Z kolei w teście częściowej zgodności, przybywający pakiet jest uznawany za zgodny, jeżeli istnieje przynajmniej jeden nie zaabsorbowany token w puli tokenów. Liczba dostępnych tokenów, nie musi wystarczać do zaabsorbowania całego pakietu, aby pakiet został uznany za zgodny. Dla przykładu, algorytm realizacji testu pełnej zgodności jest przedstawiony w [RFC3290]. O ile test pełnej zgodności jest dobrym rozwiązaniem dla przypadków, kiedy pakiety strumienia poddawanego testowi mają taką samą długość, o tyle np. dla pakietów generowanych przez źródła TCP, dla których oprócz dłuższych pakietów danych, występują krótkie pakiety z potwierdzeniami odbioru, lepszym rozwiązaniem wydaje się użycie testów niepełnej zgodności [RFC3290]. Pakiety po przejściu przez element monitorowania ruchu mogą być przekazywane do elementów oznaczania. Przykładowo pakiety uznane za zgodne przez token bucket mogą być oznaczane jako te, które są przekazywane do dalszej obsługi, zaś pakiety niezgodne mogą zostać po prostu usunięte przez mechanizm odrzucania pakietów Oznaczanie pakietów Oznaczanie pakietów w węźle sieci może odbywać się bezpośrednio po przejściu pakietu przez mechanizm klasyfikacji, bądź też po przejściu przez mechanizm monitorowania ruchu. Oznaczanie pakietów polega na ustawianiu odpowiedniej wartości pól nagłówka pakietu, które są przewidziane do tego celu. Przykładowo, w przypadku architektury DiffServ oznaczanie pakietów polega na ustawianiu odpowiedniej wartości pól DSCP w nagłówku pakietu. W przypadku przejścia pakietu przez mechanizm monitorowania, wartości pól zależą od przyporządkowania pakietu do odpowiedniego poziomu zgodności. Kolejny przykład: pakiety zgodne z założonym profilem ruchu mogą być oznaczane inaczej niż pakiety niezgodne, mogą zostać przypisane do innej podklasy usług. Oznaczanie pakietów pozwala na ich odpowiednią obsługę przez kolejne mechanizmy na ścieżce prze- 18

19 kazu w danym węźle. Dzięki oznaczaniu pakietów, można m.in. różnicować pakiety w ramach strumienia, na te które powinny być obsłużone np. w procesie kolejkowania z wyższym lub niższym priorytetem, bądź też na te które powinny być przekazane do dalszej obsługi lub powinny zostać odrzucone w pierwszej kolejności w razie przeciążenia w danym węźle sieci Odrzucanie pakietów Mechanizmy odrzucania pakietów pozwalają na usuwanie pakietów, które są bądź to niezgodne z deklarowanym profilem ruchu (reakcyjne regulowanie ruchu), bądź ich odrzucenie może zmienić ruch generowany przez źródło z którego pochodzą pakiety (prewencyjne regulowanie ruchu). W obu przypadkach usuwanie pakietów, powinno wspierać obsługę ruchu, zgodnie z założonymi dla danej usługi sieciowej wymaganiami QoS. Odrzucanie pakietów może się odbywać na zasadzie bezwzględnego lub selektywnego odrzucania. Bezwzględne odrzucanie polega na tym, iż wszystkie pakiety napływające do elementu odrzucającego są po prostu usuwane. Taki element odrzucający nie przekazuje pakietów dalej, dlatego nie musi posiadać elementu wyjściowego. W przypadku mechanizmu z selektywnym odrzucaniem pakietów, pakiety napływające do elementu odrzucającego są usuwane selektywnie, zgodnie z przyjętym algorytmem usuwania. Dlatego też, taki element odrzucający pakiety posiada zarówno wejście, jak i wyjście. Algorytm selektywnego odrzucania pakietów może być skojarzony z kolejką o dyscyplinie obsługi FIFO. Dla takiego przypadku można wymienić dwa typowe algorytmy odrzucania: (1) odrzucany jest pakiet, który miałby zostać umieszczony w ogonie kolejki FIFO (Tail Dropper). W tym przypadku, element wyjściowy urządzenia odrzucającego jest połączony z elementem wejściowym kolejki, lub (2) odrzucany jest pakiet, który znajduje się na samym początku kolejki (Head Dropper). W przypadku 2., element wejściowy urządzenia odrzucającego jest połączony z elementem wyjściowym kolejki. Jak już wspomniano, wymienione przypadki selektywnego odrzucania pakietów pozwalają na tzw. reakcyjne regulowanie ruchu. Inną grupą mechanizmów są te, które służącą prewencyjnemu regulowaniu ruchu, określane, jako mechanizmy aktywnego zarządzania kolejką (Active Queue Management - AQM). Trzy najczęściej wymieniane w literaturze mechanizmy typu AQM, to: Random Early Detection (RED) [Floyd93, Zieg01], Weighted RED (WRED) [Cisco] oraz RED gateway with In/Out (RIO). Z dotychczasowych analiz wynika, iż zastosowanie tych mechanizmów służy głównie zapobieganiu przeciążeniom w węzłach sieci, w której nie stosuje się odpowiednich mechanizmów AC. Więcej informacji na temat mechanizmów RED/WRED można znaleźć w Raporcie z zadania badawczego A Szeregowanie pakietów Poniżej zostaną przedstawione, znane z literatury (np. pozycja [Kesh97]) metody szeregowania pakietów, ich porównanie z punktu widzenia możliwości uzyskania sprawiedliwego podziału pasma (fairness), jak również zapewnienia odpowiednich wymagań QoS dla przekazu pakietów. W konsekwencji zastosowania metod szeregowania pakietów możemy mówić o dwóch parametrach przekazu pakietów, są to: poziom straty pakietów oraz opóźnienie pakietów. Należy podkreślić, iż zasto- 19

20 sowanie odpowiednich metod szeregowania pakietów w węzłach sieci może wspierać zapewnienie różnicowania jakości przekazu pakietów w ramach różnych strumieni. W literaturze możemy znaleźć bardzo wiele propozycji dla mechanizmów szeregowania pakietów. Jednak biorąc pod uwagę cel projektu, w raporcie skupimy się jedynie na przeglądzie mechanizmów, które są obecnie stosowane w urządzeniach producentów ruterów, czyli na tych które spełniają przede wszystkim wymagania na łatwość implementacji oraz służą wspieraniu i różnicowaniu jakości przekazu. Dotychczas wymienianych jest pięć podstawowych metod szeregowania pakietów, które w mniejszym bądź większym stopniu spełniają wymagania na sprawiedliwy podział zasobów (max-min fair share) oraz zapewnienie obsługi, są to: Generalized Processor Sharing - GPS, Weighted Round Robin WRR, Deficit Round Robin DRR, Weighted Fair Queuing WFQ, Packet-by-packet Generalized Processor Sharing PGPS. Niestety, wymagania na łatwość implementacji nie spełnia metoda GPS, dlatego też nie istnieje praktyczna możliwość wykorzystania tej metody. GPS jest idealną metodą szeregowania pakietów, która poprzez sposób obsługi pakietów w najwyższym stopniu spełnia wymagania sprawiedliwego podziału zasób max-min [Kesh97]. Dla przypadku klas usług oferujących ścisłe gwarancje QoS metody szeregowania pakietów powinny spełniać następujące wymagania: łatwość implementacji, zapewnienie QoS, możliwość implementacji łatwego i efektywnego algorytmu AC, czyli m.in. łatwość zapewnienia limitu pasma (AC limit) dla danej klasy usług. Wymienione wymagania są w najlepszym stopniu spełniane przez metodę WFQ, gdyż najdokładniej przybliża ona metodę GPS, a więc realizuje sprawiedliwy podział zasobów max-min. Z punktu widzenia ścisłych wymagań QoS, należy zauważyć, że WFQ pozwala dla każdego zagregowanego strumienia pakietów skojarzonego z klasą ruchu wprowadzić pewne ograniczenie na przydzielone pasmo. Dodatkowo, Parekh i Gallager udowodnili istotne ograniczenie dla najgorszego przypadku opóźnienia typu koniec-koniec, wprowadzanego przy przekazie pakietów danego strumienia przez łańcuch węzłów z mechanizmami szeregowania pakietów WFQ [Kesh97]. Znajomość takiego ograniczenia jest bardzo pomocna w procesie wymiarowania sieci pod kątem wymagań dla usług oferujących ścisłe gwarancje QoS. Poszczególni producenci sprzętu realizują własne implementacje w/w algorytmów szeregowania pakietów, stąd też ich nazwy mogą nieznacznie różnić się od tych wymienionych powyżej. Stosuje się również algorytmy które stanowią połączenie np. mechanizmu priorytetów (non-preemptive) z mechanizmem WFQ, np. mechanizm szeregowania CBWFQ (Class Based Weighted Fair Queueing) stosowany w ruterach CISCO lub mechanizm MDRR (Modified Deficit Round Robin). Oba mechanizmy obsługuję jedną klasę z wyższym priorytetem w stosunku do pozostałych klas ruchu. W przypadku CBWFQ, pozostałe klasy są obsługiwane zgodnie z algorytmem WFQ, zaś w przypadku mechanizmu MDRR z algorytmem DRR. MDRR jest stosowany np. w ruterach dla sieci szkieletowych, np. CISCO GSR series. Stosuje się w nich mechanizm DRR, który wymaga mniejszych mocy obliczeniowych niż np. WFQ. Mechanizm CBWFQ stosowany jest raczej w ruterach brzegowych ze względu na złożoność operacji, które są konieczne dla obsługi każdego pakietu przez mechanizm WFQ. 20