Metoda QoS płaszczyzny danych wer_7

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
Real Time (RT)
Non Real TimeTime Critical
(NRT-TC)
Non Real Time
(NRT)
Best Effort (BE)
Wymagania QoS
/wartości dopuszczalne/
Poziom strat
pakietów
Wielkość
opóźnienia
Zmienność
opóźnienia
10-3
100 msek
50 msek
10-3
400 msek
-
10-3
1 sek
-
-
-
-
Rodzaje usług
użytkownika
Przekaz mowy, przekaz
wideo
Przekaz informacji
sterujących, komunikatów
głosowych, danych pilnych
Przekaz obrazów i grafiki,
www.
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
Rodzaj usługi
abonenta
sieciowego
Systemowy Sygnalizacja, zarządzanie
Systemowy
Routing
Kategoria I
Telefonia VoIP,
Kategoria II
Sygnalizacja VoIP
RT
Kategoria III
Kategoria I
Wideokonferencja
Kategoria II
Kategoria III
Kategoria I
Transfer danych
NRT-TC
Kategoria II
systemów dowodzenia
Kategoria III
Kategoria I
Transfer danych FTP
Kategoria II
Kategoria III
NRT
Kategoria I
Transfer danych
Kategoria II
HTTP(S)
Kategoria III
Wszystkie
E-mail
BE
Klasa lub nazwa
DSCP
CS7
CS6
EF
CS5
CS5
AF43
AF42
AF41
AF33
AF32
AF31
AF23
AF22
AF21
AF13
AF12
AF11
DF
Wartość
DSCP
111 000
110 000
101 110
101 100
101 010
100 110
100 100
100 010
011 110
011 100
011 010
010 110
010 100
010 010
001 110
001 100
001 010
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] =
d [s ] ⋅ B[bit / s ]
8[bit / byte]
(1)
gdzie:
d - wartość maksymalnego opóźnienia,
B - przepływność interfejsu.
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:
σ = Vint ⋅ DRT
(2)
gdzie:
σ – wielkość wiadra żetonów,
Vint – przepływność interfejsu,
DRT – 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.