Metoda QoS płaszczyzny danych w specjalnych systemach łączności

Szymon Kącik, Mateusz Michalski Krzysztof Zubel Zakład Systemów Łączności Wojskowy Instytutu Łączności Metoda QoS płaszczyzny danych w specjalnych systemach łączności W referacie zaprezentowana została metoda QoS bazująca na mechanizmach płaszczyzny danych opracowana w ramach Projektu Badawczo-Rozwojowego MNiSW (PBR nr 0 R00 0024 06) pt.: Metoda gwarantowania jakości usług w taktycznym systemie łączności wykorzystującym technikę sieciową IPv6 i integracji systemów bazujących na IPv4. Na wstępnie przedstawiono sposób różnicowania jakości usług proponowany do zastosowania w taktycznym systemie łączności STORCZYK 2010, natomiast w dalszej części specyfikację poszczególnych mechanizmów płaszczyzny danych zgodnie z kolejnością ich występowania w routerze sieci IPv6. Jako pierwszy opisano mechanizm klasyfikacji i znakowania pakietów, następnie mechanizm kolejkowania napływających pakietów, w dalszej kolejności mechanizm zapobiegania przeciążeniom w sieci i jako ostatni, mechanizm kształtowania ruchu wychodzącego z routera. Poszczególne mechanizmy zostały odpowiednio sparametryzowane, zgodnie z wymaganiami stawianymi taktycznym systemom łączności. 1. Wprowadzenie Obiektem implementacji przedstawionych w artykule mechanizmów wsparcia QoS jest system STORCZYK 2010. Jest to system łączności wprowadzany do polskich Sił Zbrojnych jako kolejna generacja systemu eksploatowanego i rozwijanego od kilkunastu lat. W pierwszej wersji system bazował wyłącznie na komutacji kanałów, realizując transmisję danych w trybie modemowym. System przechodził wielokrotne modernizacje, w ramach których dokonywano modernizacji poszczególnych elementów komutacyjnych oraz transmisyjnych, co umożliwiało realizację nowych, bardziej zaawansowanych usług. Obecnie system STORCZYK przystosowany jest do pracy z protokołem IPv4 w trybie best effort. W wersji STORCZYK 2010, w systemie zaproponowano zastosowanie routerów wykorzystujących protokół sieciowy IPv6. Ponieważ urządzenia odpowiedzialne za routing pakietów IP (zbudowane w oparciu o rozwiązania firmowe producenta systemu) nie posiadają funkcji gwarantującej realizację usług z żądaną jakością, konieczne było zaproponowanie odpowiednich mechanizmów, a następnie ich implementacja w urządzeniach sieciowych systemu. Docelowym rozwiązaniem wsparcia QoS w sieciach taktycznych powinna być architektura obejmująca mechanizmy związane zarówno z płaszczyzną danych (schemat DiffServ) jak i płaszczyzną sterowania (schemat IntServ) [12]. Tego typu rozwiązanie może zapewnić tzw. pełną gwarancję usług. Zastosowanie wyłącznie mechanizmów należących do schematu DiffServ także umożliwia świadczenie usług z określoną jakością, jednakże jakość ta nie jest w pełni gwarantowana zależy np. od liczby użytkowników i ilości generowanych pakietów (tzw. miękki lub statystyczny QoS). Mechanizmy przyporządkowane do płaszczyzny danych zwane są mechanizmami niskopoziomowymi. Mechanizmy te w sposób bezpośredni wpływają na obsługę przekazywanych danych we wszystkich elementach sieci (terminalach abonenckich, przełącznikach, routerach itp.). Do mechanizmów tych należą: mechanizm klasyfikacji i znakowania pakietów, mechanizm kolejkowania pakietów,

mechanizm przeciwdziałania przeciążeniom, mechanizm kształtowania ruchu. W architekturze DiffServ zapewnienie jakości usług nie odbywa się na poziomie pojedynczego strumienia danych, lecz na poziomie grupy strumieni danych przydzielonych do pewnej klasy usług sieciowych, tzw. CoS (ang. Class of Service), którym są przypisane odpowiednie parametry QoS. Napływające od użytkownika pakiety danych są klasyfikowane oraz znakowane na wejściu do sieci przy wykorzystaniu unikalnego kodu DS (ang. Differentiated Services). Każda wartość kodu DS przyporządkowana jest do pewnej klasy usług CoS. Poszczególne klasy usług CoS mają przypisane określone wartości parametrów QoS. Na potrzeby realizacji Projektu Badawczo-Rozwojowego (PBR nr 0 R00 0024 06) pt.: Metoda gwarantowania jakości usług w taktycznym systemie łączności wykorzystującym technikę sieciową IPv6 i integracji systemów bazujących na IPv4 zostały przyjęte cztery podstawowe klasy usług sieciowych CoS opisane podstawowymi parametrami QoS [1]. Specyfikacja przyjętych klas usług CoS została przedstawiona w tabeli nr 1. Tabela 1. Wymagania jakościowe dla różnych klas usług sieciowych Klasy usług sieciowych CoS Poziom strat pakietów Wymagania QoS /wartości dopuszczalne/ Wielkość opóźnienia Zmienność opóźnienia Real Time (RT) 10-3 100 msek 50 msek Non Real Time- Time Critical (NRT-TC) 10-3 400 msek - Rodzaje usług użytkownika Przekaz mowy, przekaz wideo Przekaz informacji sterujących, komunikatów głosowych, danych pilnych Non Real Time 10-3 1 sek - Przekaz obrazów i grafiki, (NRT) www. Best Effort (BE) - - - e-mail Pierwsza klasa usług sieciowych (RT) jest przeznaczona dla obsługi ruchu strumieniowego (o stałej i zmiennej szybkości bitowej) z rygorystycznymi wymaganiami dotyczącymi zapewnienia małego opóźnienia przekazu pakietów, małego jittera oraz małego poziomu utraty pakietów. Ruch o takim profilu i takich wymaganiach QoS jest właściwy dla aplikacji realizujących usługi konwersacyjne (telefon, wideotelefon) oraz usługi strumieniowe (audio i wideo). Ruch kierowany do sieci przez użytkownika jest w tym przypadku charakteryzowany określoną wartością szczytowej szybkości bitowej PBR (Peak Bit Rate). Wartość ta wynika z zastosowanych kodeków głosu, audio i wideo. Dwie kolejne usługi (NRT-TC, NRT) są przeznaczone dla obsługi ruchu elastycznego, tj. wykorzystującego protokół TCP (Transmission Control Protocol). Usługa NRT-TC jest przeznaczona do przesyłania ruchu generowanego przez krótkotrwałe połączenia TCP. Usługa NRT jest przeznaczona do przesyłania ruchu związanego z długotrwałymi połączeniami TCP, w których źródło ma charakter zachłanny (greedy source). W obydwu przypadkach ruch jest scharakteryzowany, przez podanie wartości PBR i SBR (Sustainable Bit Rate). Wartości te powinny być przypisane do odpowiednich usług użytkownika. Ostatnia usługa bez QoS odpowiada standardowemu przekazowi pakietów na zasadzie Best Effort.

2. Zasady klasyfikacji i znakowania strumieni danych Klasyfikacja pakietów odbywa się na podstawie oznakowanych strumieni danych. Wykorzystuje się do tego jednobajtowe pole DSCP w nagłówku IP, którego struktura pokazana została na rys. 1. Rysunek 1. Struktura pola DS wg RFC 2597 [11] W zaleceniu RFC 2475 [10] zdefiniowano podział pola DSCP na dwie części: pole Class Selector, które zapewnia kompatybilność z wcześniejszymi rozwiązaniami (Type of Service) dzięki analogii do trzybitowego pola IP Precedence w polu ToS, oraz pole Drop Precedence, które określa poziom prawdopodobieństwa utraty pakietu. Pole ECN określa natłok w sieci. Pole Class Selector pozwala na identyfikację ruchu sieciowego poprzez odpowiednie dzielenie ruchu na klasy usług sieciowych i klasyfikację priorytetową pakietów (datagramów) należących do tego ruchu. Pakiety o takiej samej wartości klasy DSCP powinny podlegać zbliżonym regułom obsługi w węzłach sieci. W tabeli 2 znajdują się wartości pól DSCP przyporządkowane poszczególnym kategoriom abonentów i rodzajom usług, zaproponowane na potrzeby systemu STORCZYK 2010. Tabela 2. Propozycja znakowania strumieni danych Kategoria Klasa ruchu Klasa lub nazwa Wartość Rodzaj usługi abonenta sieciowego DSCP DSCP Systemowy Sygnalizacja, zarządzanie CS7 111 000 Systemowy Routing CS6 110 000 Kategoria I EF 101 110 Telefonia VoIP, Kategoria II CS5 101 100 Sygnalizacja VoIP RT CS5 101 010 Kategoria I AF43 100 110 Kategoria II Wideokonferencja AF42 100 100 AF41 100 010 Kategoria I AF33 011 110 Transfer danych Kategoria II NRT-TC AF32 011 100 systemów dowodzenia AF31 011 010 Kategoria I AF23 010 110 Kategoria II Transfer danych FTP AF22 010 100 AF21 010 010 NRT Kategoria I AF13 001 110 Transfer danych Kategoria II AF12 001 100 HTTP(S) AF11 001 010 Wszystkie E-mail BE DF 000 000 Głównym zadaniem klasyfikacji jest powiązanie rodzajów usług z klasami ruchu sieciowego. Ponieważ rozróżnienie w sieci jedynie czterech strumieni danych byłoby niewystarczające, w celu zapewnienia (użytkownikom o różnych priorytetach obsługi) poprawności działania usług czasu rzeczywistego, zdecydowano się jeszcze na dodatkowy podział na trzy kategorie abonentów dla następujących klas: RT, NRT-TC i NRT. Kategoria pierwsza przeznaczona jest dla najważniejszych osób funkcyjnych, kategoria druga oznacza abonentów o średnim priorytecie obsługi, natomiast kategoria trzecia dotyczy pozostałych użytkowników systemu łączności.

Zaproponowane wartości pól DSCP dla poszczególnych usług sieciowych i kategorii abonenta są zgodne z dokumentem [9]. Dzięki temu możliwa jest współpraca z innymi operatorami na podstawie wcześniej ustalonych parametrów jakościowych ruchu (SLA). 3. Metoda segregacji i kolejkowania strumieni danych Rozwiązania praktyczne różnicowania jakości usług wskazują na konieczność umieszczania mechanizmów kolejkowania na wyjściu routera, a więc w buforach nadawczych interfejsów lub specjalnych kolejkach zlokalizowanych przed tymi buforami. W systemach cywilnych dość często stosowane są kolejki priorytetowe przeznaczone przede wszystkim do obsługi ruchu interaktywnego wymagającego możliwie najmniejszych opóźnień. Jednak wadą kolejek priorytetowych jest to, iż ruch interaktywny może całkowicie zablokować (wywłaszczyć) przepływ innych rodzajów ruchu telekomunikacyjnego. W wojskowych, zautomatyzowanych systemach dowodzenia oraz kierowania środkami walki istotna jest wymiana nie tylko danych interaktywnych ale i innych rodzajów danych. Dlatego też w wojskowych systemach łączności nie powinno się stosować rozwiązań dających bezwzględny priorytet jednemu rodzajowi ruchu telekomunikacyjnego (jednej klasie usług sieciowych). Dodatkowo przemawiają za tym również względy bezpieczeństwa. Można łatwo wyobrazić sobie atak typu fałszywy QoS stanowiący odmianę ataku DoS (Denial of Service), polegający na wysyłaniu do sieci przez atakującego dużej ilości pakietów o dużym rozmiarze z ustawionym polem TC (Traffic Class) na najwyższy priorytet. Taki atak byłby w stanie zablokować możliwość przesyłania przez sieć innych rodzajów ruchu telekomunikacyjnego. Z tego też względu w taktycznych systemach łączności zrezygnowano ze stosowania kolejek priorytetowych na rzecz kolejki typu HTB (Hierarchical Token Bucket hierarchiczne wiadro żetonów) z odpowiednio dobranym pasmem transmisyjnym do poszczególnych klas usług sieciowych wymienionych w tabeli 2. Do podstawowych cech charakteryzujących kolejkę typu HTB można zaliczyć: Możliwości tworzenia wielopoziomowych struktur hierarchicznych, tzw. drzew. Drzewa te złożone są z tzw.: korzenia, rodziców, dzieci i liści. Korzeń jest elementem najwyższym w hierarchii. Rodzice i dzieci są szczeblami pośrednimi, natomiast liść jest elementem końcowym zamykającym daną gałąź w drzewie. Gałęzie mogą również kończyć się na rodzicach lub dzieciach. Każda z gałęzi drzewa zapewnia zarówno gwarancję minimalnego pasma transmisyjnego jak i ograniczenie maksymalnej szybkości transmisji zgodnie z ustawieniami administratora sprzętu. Szczebel nadrzędny (korzeń) otrzymuje i przechowuje żetony przypadające na daną rodzinę kolejek HTB. W celu wysłania danych z kolejki, kolejka wysyła prośbę do szczebla nadrzędnego o przydział żetonów. Hierarchiczność tego systemu pozwala na pożyczanie wolnych żetonów innym kolejkom z własnej rodziny, zwiększając w ten sposób średnią szybkości transmisji z jednej konkretnej kolejki, do maksymalnej szybkości przysługującej danej rodzinie. Istnieje możliwość ustawienia priorytetów wskazujących kolejność przydzielania poszczególnym kolejkom pozostałego (wolnego) pasma transmisyjnego (żetonów). Proponowany do zastosowania w taktycznym systemie łączności mechanizm kolejkowania zakłada (rysunek 2): Utworzenie 4 rodzin kolejek HTB dla 4 klas ruchu: RT, NRT-TC, NRT i BE (tabela 1). W każdej rodzinie (poza klasą BE) utworzenie 3 kolejek dla 3 kategorii abonentów o różnym priorytecie: user A (najwyższy), user B (średni), user C (najniższy).

Dokonanie priorytetyzacji rodzin poprzez zróżnicowany przydział części pasma transmisyjnego danego interfejsu wyjściowego routera: RT minimalnie 40% pasma interfejsu, NRT-TC minimalnie 30% pasma interfejsu, NRT minimalnie 20% pasma interfejsu, BE minimalnie 10% pasma interfejsu. W ramach rodzin, priorytetyzacja użytkowników poprzez przydział części pasma transmisyjnego dostępnego dla danej rodziny: user A - 60% pasma dostępnego dla rodziny, user B - 30% pasma rodziny, user C - 10% pasma rodziny (na rysunku 2 oznaczenie rate). Możliwość pożyczania pasma pomiędzy typami użytkowników w ramach danej klasy ruchu (rodziny). Utworzenie kolejnego szczebla hierarchii poprzez połączenie rodzin możliwość pożyczania pasma pomiędzy rodzinami (klasami ruchu). Na rysunku 2 poszczególne rodziny oznaczone są jednakowym kolorem. Ustalenie procentowych ograniczeń górnych w zakresie zajmowania nominalnej przepływności interfejsu wyjściowego routera: rodzina RT maksymalnie 95% przepływności interfejsu, pozostałe rodziny maksymalnie 90% przepływności interfejsu (oznaczenie ceil na rysunku 2). Ustalenie priorytetu w dostępie do wolnego pasma przez poszczególne rodziny: RT priorytet 1 (najwyższy), NRT-TC priorytet 2, NRT priorytet 3, BE priorytet 4 (oznaczenie prio na rysunku 2). Dla klasy BE zaproponowano minimalnie 10 % pasma interfejsu. Spowodowane jest to brakiem podziału na użytkowników (userów) w ramach tej rodziny. Graficzne zobrazowanie proponowanego mechanizmu kolejkowania przedstawione zostało na rys. 2. Rysunek 2. Architektura proponowanego mechanizmu kolejkowania

4. Mechanizm zapobiegania przeciążeniom na traktach międzywęzłowych Mechanizm zapobiegania przeciążeniom poprzez oddziaływanie na proces przyjmowania pakietów uzależniony od stopnia zapełnienia kolejek wyjściowych, pozwala na kontrolowane straty pakietów oraz w pewnym zakresie na kształtowanie ruchu wpływającego do routera IP. Zasada działania mechanizmu zapobiegania przeciążeniom polega na odrzucaniu pakietów przychodzących spełniających określone, wcześniej ustalone kryteria (głównie dotyczące stopnia zajętości bufora). Do tej grupy mechanizmów należy mechanizm WRED (ang. Weighted Random Early Detection). Typowo posiada on dwa progi działania: dolny, po przekroczeniu którego prawdopodobieństwo odrzucenia pakietu jest większe od zera oraz górny, którego przekroczenie powoduje odrzucanie pakietów z prawdopodobieństwem równym 1, czyli odrzucanie wszystkich pakietów należących do danej klasy usług sieciowych. W specyfikacji mechanizmów zapobiegania przeciążeniom w systemie STORCZYK 2010 konieczne było określenie dla każdej klasy usług sieciowych następujących parametrów mechanizmu WRED: MPSP Maksymalny Poziom Strat Pakietów, tj. prawdopodobieństwo odrzucania pakietów przychodzących po osiągnięciu progu Lmax, Lmax górny próg zapełnienia bufora wyjściowego, przy osiągnięciu którego pakiety przychodzące danej klasy usług sieciowych będą losowo odrzucane z maksymalnym dopuszczalnym dla danej klasy prawdopodobieństwem, Lmin dolny próg zapełnienia bufora wyjściowego, po przekroczeniu którego pakiety przychodzące danej klasy usług sieciowych będą losowo odrzucane. Zgodnie z tabelą 1 parametr MPSP dla trzech klas usług (RT, NRT-TC oraz NRT) wynosi 10-3. Oznacza to, że po osiągnięciu progu Lmax, losowo jeden na tysiąc pakietów przychodzących będzie odrzucany. Natomiast dla usług typu Best Effort nie definiuje się parametru MPSP. Przyjmuje się, że prawdopodobieństwo odrzucania pakietów narastać będzie liniowo od wartości zerowej do 1. Kolejnym zdefiniowanym parametrem jest maksymalny próg odrzucania pakietów Lmax. Należy go wyznaczyć z parametru maksymalnego dopuszczalnego opóźnienia pakietów dla danej klasy usług sieciowych (tabela 1), ponieważ stopień zapełnienia bufora wyjściowego przekłada się bezpośrednio na poziom tego opóźnienia. Próg Lmax należy wyznaczyć z prostej zależności: Lmax [ byte] gdzie: d - wartość maksymalnego opóźnienia, B - przepływność interfejsu. = d [ s] B[ bit / s] 8[ bit / byte] (1) Maksymalny próg Lmax, jak wynika z zależności (1), uzależniony będzie od przepływności interfejsu, na którym zastosowano mechanizm WRED. Na przykład, dla interfejsu o przepływności 10Mbit/s, Lmax dla klasy usługi RT wyniesie 125kB. Ponieważ usługi typu Best Effort nie posiadają zdefiniowanych parametrów jakościowych (w tym maksymalnego dopuszczalnego opóźnienia) proponuje się, aby Lmax dla usług BE wynosił 90% wielkości bufora wyjściowego. Wielkość bufora wyjściowego dla usługi BE proponuje się przyjąć taką samą jak dla usługi NRT. Ostatnim parametrem charakteryzującym mechanizm zapobiegania przeciążeniom WRED jest próg minimalny Lmin, po przekroczeniu którego następuje losowe odrzucanie pakietów z określonym prawdopodobieństwem. Próg minimalny będzie wyznaczony z tej samej zależności, jak próg Lmax, przy czym należy ustalić inne kryteria opóźnienia podstawiane do wzoru (1). Dla usługi Best Effort, zaproponowano przyjęcie progu minimalnego Lmin na poziomie wynoszącym

10% wielkości bufora wyjściowego. Spowoduje to losowe odrzucanie pakietów usługi BE już przy znikomym zapełnieniu bufora, jednak usługi te w dużej mierze realizowane będą z wykorzystaniem protokołu TCP, który spowoduje spowolnienie transmisji pakietów. Taką samą wielkość Lmin proponuje się przyjąć dla usług typu NRT, których pakiety, podobnie jak dla usług BE, będą transportowane za pomocą protokołu TCP. W przypadku usług RT wyznaczenie progu Lmin jest bardziej skomplikowane, ponieważ pakiety tych usług z reguły transportowane są za pośrednictwem protokołu UDP, który jest protokołem bezpołączeniowym stratnym. Przedwczesne (małe Lmin) odrzucanie pakietów spowoduje bezpowrotną utratę danych bez możliwości ponownego ich przesłania. Jeżeli usługą RT jest usługa głosowa, straty pakietów będą skutkowały zniekształceniami mowy. Dla niewielkich strat pakietów nie wpłynie to na zrozumiałość, czyli przekaz informacji. Współcześnie stosowane kodeki mowy są częściowo odporne na straty danych i za pomocą różnych mechanizmów poprawiają jej zrozumiałość. Ponieważ usługi RT będą realizowane za pomocą bezpołączeniowych i stratnych protokołów warstwy transportowej należy przyjąć, że próg Lmin będzie usytuowany blisko progu Lmax. W opracowanej specyfikacji zaproponowano następujące parametry: Maksymalny Poziom Strat Pakietów MPSP dla usług RT, NRT-TC oraz NRT wynosi 10-3, dla pakietów usług BE wynosi 1, próg maksymalny Lmax dla pakietów poszczególnych usług (RT, NRT-TC, NRT) będzie uzależniony od szybkości interfejsu, a dla usług BE będzie stanowił 90% wielkości bufora wyjściowego, próg minimalny Lmin dla pakietów usług BE oraz NRT będzie wynosił 10% wielkości bufora wyjściowego, a dla usług RT oraz NRT-TC będzie wynosił 90% wielkości progu maksymalnego Lmax(RT, NRT-TC). Z powyższego podsumowania widać, że w niektórych przypadkach nie jest możliwe określenie konkretnych wartości parametrów mechanizmów zapobiegania przeciążeniom WRED bez znajomości szybkości interfejsu wyjściowego. Wielkość ta niezbędna jest do wyznaczenia progów maksymalnych Lmax, a te do wyznaczenia progów minimalnych Lmin dla poszczególnych strumieni pakietów odpowiednich klas usług. Na rys. 3 przedstawiona została przykładowa charakterystyka mechanizmów WRED dla czterech klas usług zaproponowanych do zastosowania w taktycznym systemie łączności STORCZYK 2010. Rysunek 3. Przykładowa charakterystyka mechanizmów WRED

5. Mechanizm kształtowania ruchu na traktach międzywęzłowych Mechanizmy kształtowania ruchu poprawiają efektywność wykorzystania traktów międzywęzłowych poprzez wygładzanie bądź ucinanie ruchu, który wypływa z węzła do sieci. Tworząc reguły kształtowania ruchu można określać pewien nadmiar pakietów jakie są wysyłane z kolejki przez kilka początkowych chwil transmisji. Takie działanie jest szczególnie przydatne przy transmisjach krótkotrwałych o dużym nasileniu, jak np. ruch generowany przez protokół HTTP. W protokole tym bowiem żądania i odpowiedzi pomiędzy komputerem a serwerem wysyłane są stosunkowo rzadko, ale niosą dość dużą ilość informacji. Na wyjściu routera w taktycznym systemie łączności zaproponowano zastosowanie tzw. mechanizmu wiadra żetonów (Token Bucket). Wielkość wiadra żetonów określono z następującego wzoru: σ = V (2) int D RT gdzie: σ wielkość wiadra żetonów, V int przepływność interfejsu, D RT dopuszczalne opóźnienie dla danej klasy usług sieciowych. Dla interfejsu o przepływności 2 Mbit/s zarekomendowano następujące parametry mechanizmu wiadra żetonów dla klasy usług RT: wielkość wiadra żetonów σ = 26 kb; szybkość generacji żetonów: ρ = 2048000 żetonów/s (parametr określający szybkość generacji żetonów powinien być dobierany zależnie od szybkości interfejsu). Przy wyliczeniu tym zastosowano wielkość opóźnienia wyspecyfikowaną w tabeli 1 dla klasy RT wynoszącą 100 ms. Należy jednak zwrócić uwagę, że taka wartość opóźnienia powinna być zapewniona wzdłuż całej ścieżki od źródła do ujścia danych, a obliczona powyżej wielkość wiadra jest wartością sumaryczną pojemności buforów transmisyjnych dla wszystkich routerów na trasie danego pakietu. Działanie mechanizmu kształtowania ruchu opartego o Token Bucket zaprezentowano praktycznie na przykładzie prostej sieci przedstawionej na rys. 4. Z komputera PC1 przesyłano cztery strumienie TCP poprzez dwa routery do komputera PC2. Rysunek 4. Układ pomiarowy Na rys. 5a pokazany jest przepływ danych przy przepustowości łącza ograniczonej do 900 kbit/s i braku mechanizmu kształtowania ruchu, natomiast na rys. 5b przepływ przy włączonym na interfejsie Fa0/1 (rys. 4) mechanizmie kształtowania ruchu (czarny wykres to suma czterech strumieni TCP). Dzięki kształtowaniu ruchu efektywność przesyłu danych wzrosła o 17%. Rysunek 5. Wpływ mechanizmu Token Bucket na ruch w trakcie międzywęzłowym

6. Podsumowanie Przedstawiona w referacie metoda gwarantowania jakości usług w rzeczywistej taktycznej sieci IP może być realizowana w sposób ewolucyjny. W pierwszej kolejności mogą być w niej wdrożone podstawowe elementy architektury DiffServ. Elementy te zgodnie z przedstawioną przez ITU-T w Y.1291 [12] architekturą QoS są umieszczone w płaszczyźnie danych. Uzyskana na tym etapie rozwoju jakość usług, w przypadku właściwie zwymiarowanej sieci, może zapewnić oczekiwany poziom QoS i zagwarantować dotrzymanie wartości parametrów QoS ustalonych w kontrakcie (zgodnie z przyjętą polityką QoS, której elementem jest SLA/SLS). W dalszej kolejności mogą być wdrażane pozostałe elementy architektury QoS zapewniające gwarantowaną jakość dla usług czasu rzeczywistego. Obecnie trwają prace nad integracją mechanizmów wymienionych w referacie w jeden spójny mechanizm wspierających osiąganie QoS w taktycznej sieci łączności. Opracowywane są modele symulacyjne przy użyciu narzędzia symulacyjnego OPNET. W dalszych etapach pracy, wykonane modele symulacyjne posłużą weryfikacji symulacyjnej zaproponowanych rozwiązań. Literatura 1. K. Strzelczyk, Koncepcja gwarantowania jakości usług w taktycznych sieciach IP, PBR nr 0 R00 0024 06 zadanie nr 9, nr arch. WIŁ 597/2009/PBR. 2. K. Strzelczyk, Specyfikacja mechanizmów znakowania pakietów w taktycznym systemie łączności wykorzystującym technikę IPv6, PBR nr 0 R00 0024 06 zadanie nr 10, nr arch. WIŁ 42/2010/PBR. 3. K. Zubel, Specyfikacja mechanizmów kolejkowania pakietów w taktycznym systemie łączności wykorzystującym technikę IPv6, PBR nr 0 R00 0024 06 zadanie nr 10, nr arch. WIŁ 54/2010/PBR 4. M. Michalski, Opracowanie modelu znakowania pakietów w taktycznym systemie łączności wykorzystującym technikę IPv6, PBR nr 0 R00 0024 06 - zadanie nr 14, nr arch. WIŁ 138/2010/PBR. 5. M. Michalski, Opracowanie zasad kształtowania ruchu wyjściowego w elementach węzłowych taktycznych systemów łączności, nr arch. WIŁ 122/2010/SŁ. 6. S. Kącik, Opracowanie modelu kolejkowania pakietów w taktycznym systemie łączności wykorzystującym technikę IPv6, PBR nr 0 R00 0024 06 - zadanie nr 14, nr arch. WIŁ 130/2010/PBR. 7. S. Kącik, Opracowanie zasad kształtowania ruchu wejściowego w elementach węzłowych taktycznych systemów łączności, nr arch. WIŁ 121/2010/SŁ. 8. Zespół pracowników TRANSBIT, Specyfikacja wymagań militarnych dotyczących zapewnienia gwarancji jakości usług w taktycznych sieciach IP, PBR nr 0 R00 0024 06 zadanie nr 4, nr arch. WIŁ 237/2009/PBR. 9. Cisco, Implementing Quality of Service Policies with DSCP, doc. ID: 10103. 10. RFC 2475, An Architecture for Differentiated Services. 11. RFC 2597, Assured Forwarding PHB Group. 12. Y.1291, An architectural framework for support of Quality of Service in packet networks, ITU-T Recommendation.