SAMODZIELNY ZAKA
AD SIECI KOMPUTEROWYCH
POLITECHNIKA A
ÓDZKA
90-924 A
ódz
ul. Stefanowskiego 18/22
tel./fax. [phone]
e-mail: [e-mail]
Jakub Turski
Gwarantowana jakość usług (QoS)
w sieciach IP
praca dyplomowa magisterska
Promotor:
dr inż. Michał Morawski
Dyplomant:
Jakub Turski
nr albumu 93692
A
ódz
, czerwiec 2003
Spis treści
Spis treści i
Wprowadzenie iii
I QoS  prawdy i mity 1
1 Czym jest, oraz czym nie jest QoS? 2
2 Parametry QoS 4
3 Korzyści kontra niedogodności 8
3.1 Wymagania implementacyjne . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Skalowalność rozwiązań . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Kształtować czy nie kształtować? . . . . . . . . . . . . . . . . . . . . . . 13
II Mechanizmy QoS 14
4 Metody zapewnienia QoS 15
4.1 Przekazywanie informacji o QoS . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Agregowanie przepływów . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Zarządzanie buforem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Techniki dodatkowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Protokół IP 20
5.1 IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
i
6 Protokoły warstwy II 37
6.1 Sieci lokalne  802.1p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 FrameRelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
III Implementacje QoS 41
7 Stosowane algorytmy 42
7.1 FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Kolejki  sprawiedliwe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Ograniczanie przepustowości . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.4 Kolejki klasowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.5 Unikanie zatorów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.6 Wydajność łącza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8 Przegląd możliwości wybranych systemów operacyjnych 54
8.1 Cisco IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.2 GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.3 Windows 2000 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.4 Zestawienie porównawcze . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9 Praktyka 60
IV Zakończenie 65
10 Przyszłość QoS 66
Zawartość płyty kompaktowej i
Literatura ii
Spis rysunków v
Skorowidz vii
ii
Wprowadzenie
 Ustanowiliśmy połączenie telefoniczne pomiędzy nami
a ludz
mi z SRI. Napisaliśmy L i zapytaliśmy ich:
 Widzicie L?
 Tak, widzimy L  nadbiegła odpowiedz
.
Napisaliśmy O i zapytaliśmy:
 Widzicie O?
 Tak, widzimy O.
Napisaliśmy G, i system się zawiesił. . .
Pomimo to, rozpoczęło to rewolucję.
 prof. Leonard Kleinrock w wywiadzie
dla Sacramento Bee, 1 maja 1996
Opisana powyżej sytuacja miała miejsce w roku 1969, podczas pierwszej próby trans-
misji poprzez sieć ARPANET, sieć która dała podwaliny temu co dziś egzystuje pod
nazwą Internet. Mimo dość pechowego startu, pomysłodawcy niezrażeni początkowy-
mi przeszkodami pracowali wytrwale dalej. W roku 1972 odbyła się pierwsza publiczna
prezentacja ARPANETu  uczestnicy międzynarodowej konferencji telekomunikacyjnej
mogli na własne oczy zobaczyć w działaniu pierwszą na świecie sieć WAN.
Nie trzeba było długo czekać na efekty.
Koniec roku  72 to już 40 węzłów ARPANETu. Jak grzyby po deszczu wyrastają
kolejne, udostępniając globalną sieć dla coraz większej rzeszy użytkowników. Powstają
kolejne usługi, e-mail, Telnet, FTP, Usenet, MUDy. . . W roku 1983 znika ostatnia bariera
ograniczająca swobodny wzrost sieci  zaimplementowana zostaje usługa DNS oferująca
hierarchiczną strukturę nazw komputerów w sieci. Prawdziwy przełom przychodzi jednak
w roku 1993  opracowana w ośrodku badawczym CERN graficzna przeglądarka WWW
o nazwie Mosaic rewolucjonizuje świat Internetu. Opracowana dwa lata wcześniej usługa
World Wide Web staje się nagle obiektem zainteresowania tysięcy użytkowników  a co
iii
za tym idzie, również świata biznesu i mediów. Jeżeli rewolucja zaczęła się w roku 1969,
to w roku 1994 jest w pełnym rozkwicie.
Jak potoczyło się to dalej? Wystarczy spojrzeć dookoła. Internet przestał być no-
wością, dziwem opisywanym w prasie, bardzo szybko z modnego terminu służącego do
upiększania reklam i ofert stał się częścią naszego codziennego życia. Pytanie  Czy uży-
wać Internetu? zmieniło się w  Jak używać Internetu? . Pozostał tylko jeden problem. . .
Nieubłagane prawo Moore a oraz zwykły ludzki apetyt na wygodę powodują że Inter-
net powiększa się w zastraszającym tempie. Coraz więcej ludzi uzyskuje do niego dostęp,
coraz więcej urządzeń jest do niego podłączanych. Coraz więcej danych, tych bardzo
ważnych oraz tych bardzo błahych przesyłanych jest przez międzykontynentalne łącza.
Coraz częściej na infostradzie zdarzają się zatory oraz korki. A prawie wszyscy użytkow-
nicy Internetu życzyliby sobie by wykonywane przez ich transmisje nie były obarczone
opóz
nieniami. Jak poradzić sobie z takim problemem? Kwestia ta komplikuje się dodat-
kowo, gdy spojrzymy na całość z punktu widzenia osoby nadzorującej ten cały bałagan.
Priorytetem administratora danego segmentu sieci jest to, aby działał on sprawnie i speł-
niał założenia które poczyniono przy jego budowie, co niekoniecznie musi stać w zgodzie
z dążeniami użytkowników do zapewnienia sobie komfortu psychicznego. Jak rozwikłać
taki węzeł gordyjski?
Odpowiedzią na tego typu pytania może być właśnie QoS , czyli gwarantowana jakość
usług. Pod tym dość ogólnym terminem kryje się zestaw technik i metod pozwalających
na ustanowienie hierarchii w obrębie transmisji sieciowych. Dzięki zastosowaniu tych 
czasami dość trywialnych  technik możliwe jest rozwiązanie części problemów i polepsze-
nie zarówno samopoczucia użytkowników jak i administratorów. Kluczem do tajemnicy
QoS jest dokładne określenie zapotrzebowania użytkowników (lub urządzeń) na zasoby
sieciowe. Przy odpowiednim zaplanowaniu hierarchii usług można każdemu użytkowni-
kowi zapewnić komfort psychiczny nie tracąc przy tym z pola widzenia cech bardziej
 technicznych takich jak koszty utrzymania, czy też wydajność danego fragmentu sieci.
Temat i zakres pracy
Tematem pracy jest gwarantowana jakość usług, czyli QoS oraz jej obecność w sie-
ciach opartych o protokół IP. Celem tej pracy jest przedstawienie problemu jakości usług,
zdefiniowanie jego celów i zasad realizacji oraz przedstawienie istniejących rozwiązań.
Praca zawiera przegląd technik i mechanizmów QoS , począwszy od najprostszych, stoso-
wanych w sieciach lokalnych, skończywszy na zaawansowanych mechanizmach obecnych
w sieciach rozległych. Tematyka pracy koncentruje się wokół protokołu IP, z racji jego
popularności i powszechności w spotykanych na codzień sieciach. Powoli, ale zdecydowa-
nie paradygmat sieci rozległych zmienia się z podejścia  IP po wszystkim (ang.  IP over
iv
anything ) na  wszystko po IP (ang.  anything over IP )  przykładem może być cho-
ciażby dynamiczny rozwój technik VoIP (Voice over IP, czyli techniki przesyłania głosu
za pomocą sieci IP). Z tego m.in. powodu, niniejsza praca skupia się wokół technik QoS
możliwych do zaimplementowania w warstwie protokołu IP.
Układ pracy
Praca została podzielona na cztery części.
Część pierwsza zawiera wprowadzenie do tematu QoS oraz definicje podstawowych
pojęć. Rozdział pierwszy stara się precyzyjnie określić co rozumiemy pod pojęciem QoS,
obalając przy tym parę powszechnych, mylnych poglądów na tą kwestie. Rozdział drugi
opisuje parametry transmisji, w zakresie których możemy definiować i kontrolować QoS.
Rozdział trzeci omawia kwestie wynikające z zastosowania QoS  sposoby wprowadzania
QoS , problemy jakie możemy napotkać, skalowalność rozwiązań.
Część druga koncentruje się na metodach i technikach stosowanych w celu osiągnię-
cia określonych wartości parametrów QoS . Rozdział czwarty wymienia i opisuje nisko-
poziomowe mechanizmy leżące u podstaw QoS , takie jak kolejkowanie czy znakowanie
pakietów. Rozdział piąty prezentuje preferowane rozwiązania problemu QoS w warstwie
III modelu OSI (protokół IP), podczas gdy rozdział szósty opisuje możliwe wsparcie dla
QoS oferowane przez różne technologie warstwy II modelu OSI.
Część trzecia przedstawia szczegóły implementacji mechanizmów QoS . W rozdziale
siódmym omówiono dokładnie zasady działania niskopoziomowych mechanizmów QoS.
Rozdział ósmy zawiera prezentację możliwości popularnych sieciowych systemów opera-
cyjnych w dziedzinie QoS . W rozdziale dziewiątym zawarty został przykład praktycznej
konfiguracji QoS dla prostej sieci domowej, razem z analizą osiągniętych wyników.
Część czwarta jest zakończeniem pracy. Rozdział dziesiąty zawiera podsumowanie
zgromadzonego w pracy materiału. Omawia również możliwą przyszłość i kierunki roz-
woju QoS . Część czwarta zawiera również spis zawartości płyty kompaktowej dołączonej
do pracy, wykaz cytowanej literatury, spis rysunków oraz skorowidz.
Konwencje typograficzne
W pracy zastosowano następujące konwencje typograficzne:
" definicje zapisano czcionką pogrubioną, np.:
marking  technika polegająca na znakowaniu pakietów w obrębie istniejących pól;
v
" wyrazy obcojęzyczne1 zapisano czcionką pochyłą, np.:
. . . anything over IP. . .
" treść plików konfiguracyjnych, wpisywane polecenia oraz komunikaty programów
zapisano czcionką maszynową, np.:
tar xzvvf kernel-source-2.4.20.tgz
Podziękowania
Podziękowania swe kieruję przede wszystkim do mojego promotora, dr inż. Michała
Morawskiego  za propozycję tematu pracy, za pomoc, za całą przekazaną wiedzę.
Podziękowania należą się też mojej najbliższej rodzinie, za to że wytrzymali pod jed-
nym dachem z osobą  piszącą pracę magisterską. Dziękuję też Przemkowi Piotrowskiemu
za pomoc w przeprowadzeniu korekty pracy.
Dziękuje Agacie, za nieustającą i gorącą motywację.
1
Część terminów świadomie pozostawiono w wersji oryginalnej, z racji braku rozsądnego i spójnego
tłumaczenia na język polski, lub też z powodu powszechnego przyjęcia się terminu obcojęzycznego w
rodzimej informatyce (np. router).
vi
Słowniczek terminów
" QoS
zbiór mechanizmów pozwalający na wyodrębnienie i priorytetyzacje ruchu IP;
" DiffServ
architektura QoS bazująca na znakowaniu pakietów;
" IntServ
architektura QoS bazująca na sygnalizacji rezerwacji;
" FrameRelay, ATM
techniki sieci rozległych;
" Ethernet
technika sieci lokalnych;
" IP
stosowany w Internecie protokół warstwy III;
" TCP, UDP
stosowane w Internecie protokoły transportowe warstwy IV;
" kolejkowanie
mechanizmy zarządzania pakietami IP w obrębie bufora;
" FIFO, PQ, pFIFO
kolejki proste;
" HTB,CBQ,CQ,CBWFQ
kolejki klasowe;
" SFQ, FQ, WFQ
kolejki  sprawiedliwe ;
" RED, GRED, WRED, BLUE
mechanizmy zapobiegania zatorom;
" TBF
mechanizm ograniczania przepustowości, model  wiadra z żetonami .
vii
Część I
QoS  prawdy i mity
1
ROZDZIAA
1
Czym jest, oraz czym nie jest QoS?
Pierwszą rzeczą jaką należy zrobić przed przystąpieniem do omawiania kwestii gwa-
rantowanej jakości usług w sieciach IP jest dokładne sprecyzowanie co tak naprawdę kry-
je się pod tym terminem. Bardzo często sformułowanie QoS jest nadużywane w różnego
rodzaju tekstach reklamowych, podsumowaniach czy też nawet w dokumentach technicz-
nych opisujących możliwości konkretnego urządzenia. Wiele z firm stosujących ten termin
w swoich opracowaniach i podręcznikach nagina jego znaczenie tak, aby najlepiej pasował
do zaimplementowanych przez daną firmę cech. Przy tego typu zamieszaniu niełatwo jest
poprawnie zdefiniować termin QoS , który ma znaczenie bardziej ogólne niż to co spotyka
się na ogół w rozmaitych opracowaniach. Poniższa definicja, powstała w oparciu o kom-
pilację z paru z
ródeł (m.in. [Cis02b,QoS99,Peu99]), jest możliwie najpełniejszym opisem
tego co kryje się pod sformułowaniem  gwarantowana jakość usług :
quality of service  zbiór technik i mechanizmów pozwalający na
zapewnienie przewidywalnego poziomu usług sieciowych w kontekście
określonych parametrów transmisji
Powyższa definicja wydać się może na pierwszy rzut oka dość ogólna, jednakże jej
ogólność jest tylko pozorna. Pod sformułowaniem  określone parametry transmisji kryje
się zestaw różnych kryteriów według których możemy oceniać jakość transmisji (więcej na
temat tych kryteriów można znalez
ć w rozdziale 2). Najczęściej stosowanym kryterium
jest przepustowość  parametr który występuje w wiecznym deficycie. Właśnie z tego
powodu wiele osób termin QoS kojarzy tylko i wyłącznie z problemem  sprawiedliwego
współdzielenia łącza internetowego. Tymczasem termin ten jest znacznie szerszy. Niektó-
2
1. Czym jest, oraz czym nie jest QoS ?
re z aplikacji sieciowych nakładają na transmisję inne wymagania niż określona wielkość
dostępnej przepustowości  przykładowo transmisja głosu wymaga aby dane przesyłane
były z opóz
nieniem nie większym niż zadana z góry wartość, oraz aby opóz
nienie ru-
chu charakteryzowało się określoną jednorodnością. Mechanizm QoS może posłużyć do
zapewnienia określonych warunków poszczególnym transmisjom lub grupom transmisji
wyróżniających się wspólnymi elementami (np. identycznym adresem docelowym). Zna-
jąc charakterystykę generowanego ruchu aplikacja jest w stanie wyrazić swoje zapotrze-
bowania na zasoby sieciowe w postaci konkretnych wartości liczbowych poszczególnych
parametrów (np.: opóz
nienie nie większe niż 5ms, pasmo co najmniej 5kbps) i zasygnali-
zować to odpowiednim urządzeniom i mechanizmom sieciowym.
Wspomniana wyżej  sprawiedliwość nieprzypadkowo została zapisana w cudzysło-
wie  pojęcie sprawiedliwości względem której dokonujemy przydziału parametrów może
być zdefiniowane różnorako. Z punktu widzenia użytkownika sieci sprawiedliwym wyda
się podział w którym jego aplikacjom zostanie przydzielona taka część zasobów siecio-
wych, która umożliwi użytkownikowi wygodną pracę. Na ogół subiektywne pojęcie wygo-
dy przekłada się na  kawałek przepustowości wynikający z równego podziału pomiędzy
użytkowników . Z kolei z punktu widzenia węzła sieci (np. routera), sprawiedliwość może
polegać na zapewnieniu każdej z przechodzących przez ten węzeł transmisji określonej
części łącza co nie zawsze jest zgodne z pragnieniami użytkowników. Przykładowo, firmo-
wy router może rezerwować większość dostępnej przepustowości na przesyłanie raportów
finansowych do centrali firmy, zostawiając dla użytkowników chcących przeglądać strony
WWW zaledwie kilka procent przepustowości łącza. Mówiąc zatem o  sprawiedliwych
podziałach w kontekście QoS należy dokładnie sprecyzować co kryje się pod słowem
 sprawiedliwość .
Trzeba też pamiętać że zapotrzebowania poszczególnych transmisji różnią się między
sobą. Sztywne dzielenie dostępnych zasobów na zasadzie  po równej części każdemu nie
jest dobrym pomysłem  inne wymagania stawia przed siecią ruch interaktywny, inne ruch
 hurtowy (np. transfery plików via FTP, Samba itp.), jeszcze inne transfer głosu, obrazu,
lub dowolna inna transmisja w czasie rzeczywistym. Dobry mechanizm QoS powinien więc
mieć możliwość odróżnienia i sklasyfikowania poszczególnych rodzajów transmisji po to,
by można było odpowiednio je potraktować.
Reasumując  QoS polega na zapewnieniu określonych z góry parametrów wybranym
transmisjom (lub ich grupom) zachodzącym w obrębie sieci.
3
ROZDZIAA
2
Parametry QoS
Jak już wspomniane zostało w poprzednim rozdziale, przepustowość to ważny, lecz nie
nie najważniejszy parametr w obrębie którego możemy definiować QoS . Trzy podstawowe
i najczęściej rozważane parametry to przepustowość, opóz
nienie i jednorodność.
Przepustowość
Pod określeniem przepustowości (ang. bandwidth) kryje się miara możliwości prze-
syłania danych przez określone urządzenie sieciowe lub łącze  czyli po prostu ilość in-
formacji jaka może zostać przesłana w ciągu jednostki czasu. Miara ta wyrażana jest
w bitach na sekundę (bps) lub jednostkach pochodnych (kilobit na sekundę, megabit na
sekundę). Jest to chyba najczęściej brany pod uwagę parametr QoS . Przepustowość jest
też na ogół głównym wyznacznikiem jakości (a co za tym idzie, często i ceny) danego łą-
cza dla jego użytkownika. Jest to również parametr najczęściej występujący w deficycie.
Sporą część problemów QoS rozwiązuje się zapewniając po prostu większą przepusto-
wość (ang. overprovisioning) [QoS99], nie likwiduje to jednak problemów w przypadku
bardziej wymagających aplikacji.
Przy definiowaniu zapotrzebowań aplikacji na przepustowość możemy żądać zarówno
wartości bezwzględnych ( przynajmniej 42kbps ) jak i względnych ( pięć procent dostęp-
nego łącza ). Pierwszy rodzaj rezerwacji ma sens w kontekście globalnym (np. podczas
rezerwacji zasobów w obrębie sieci, tak aby żądana przepustowość została zarezerwowana
na całej trasie), drugi  w kontekście lokalnym, konkretnego węzła sieci i konkretnego łą-
cza. Tego typu wymóg przydaje się w przypadku określania parametrów QoS dla zbiorczej
klasy ruchu który nie został zakwalifikowany do żadnej innej klasy.
4
2. Parametry QoS
Najczęstszym wymaganiem co do przepustowości jest zapewnienie określonego pro-
centu dostępnej przepustowości dla danej transmisji. W sieciach lokalnych sprowadza się
to na ogół do podzielenia dostępnego pasma pomiędzy aktywnych w danej chwili użyt-
kowników. Dla pojedynczego użytkownika ma być dostępne przynajmniej tyle pasma ile
wynika z podziału całości pomiędzy wszystkich użytkowników (dolna granica) oraz nie
więcej niż wynika z podziału całości pomiędzy aktywnych w danym momencie użytkow-
ników (górna granica).
Opóz
nienie
Czas, jaki zajmuje pakietowi przejście przez dany odcinek sieci. W zależności od po-
trzeb, możemy rozważać opóz
nienie na całym przebywanym przez pakiet odcinku sieci
(od nadawcy do odbiorcy) jak i opóz
nienie wprowadzane przez jeden węzeł sieci.
W kontekście QoS termin  opóz
nienie oznacza najczęściej czas który upływa od
momentu wysłania pakietu przez nadajnik do momentu odebrania go przez odbiorcę.
Aplikacja może zażądać od sieci z gwarantowaną jakością usług by wszystkie wysyłane
przez nią pakiety docierały do celu z opóz
nieniem nie większym niż określona wartość.
Tego typu wymaganie stawiają na ogół aplikacje interaktywne takie jak ssh czy telnet
(i inne usługi pracy zdalnej)  nie wymagają one dużej przepustowości łącza, jednakże
w celu zapewnienia płynnej pracy pakiety muszą podróżować z odpowiednio małym opóz
-
nieniem (wygodna praca z ssh to opóz
nienie rzędu kilkudziesięciu milisekund). Podobnego
traktowania wymagają też aplikacje typu VoIP przesyłające głos w czasie rzeczywistym
 zbyt duże opóz
nienia niweczą całe przedsięwzięcie.
Sieć IP nie jest siecią izochroniczną i jako taka nie daje  mocnych gwarancji prze-
słania danego pakietu danych w określonym z góry czasie. Rozwiązaniem optymalnym
byłoby skorzystanie z adekwatnych mechanizmów w warstwie II (np. ATM lub Frame-
Relay)  nie zawsze są one jednak dostępne. Dzięki technikom QoS można postarać się
o poprawnienie działania sieci IP pod tym względem, jednakże osiągnięty rezultat nie
będzie pozbawiony wad.
Jednorodność opóz
nienia
Nie mniej ważnym parametrem od opóz
nienia jest jego jednorodność (ang. jitter).
Informacja przesyłana za pomocą sieci IP może zostać podzielona na wiele pakietów IP.
Każdy z pakietów może zostać przesłany odmienną trasą pomiędzy nadajnikiem a od-
biornikiem. Każdy pakiet może więc charakteryzować się odmiennym opóz
nieniem. Nie
mamy też gwarancji że pakiety dotrą na miejsce w takiej kolejności w jakiej były wysyła-
ne. Pewnym rozwiązaniem może być użycie w warstwie wyższej protokołu połączeniowego
5
2. Parametry QoS
(np. TCP) który ma za zadanie zająć się tymi kwestiami. Jednak w przypadku transmi-
sji obrazu lub dz
więku transmisja połączeniowa może przynieść więcej szkód niż korzyści
(z racji konieczności retransmisji zgubionych lub opóz
nionych pakietów, potwierdzania
odebranych itp.). Z drugiej jednak strony, transmisje multimedialne wymagają zagwaran-
towania stałego  napływu nowych informacji, nierównomierność w przesyłaniu danych
może zaowocować utratą synchronizacji, lub też utratą jakości przesyłanej informacji
(w zależności od użytego protokołu).
Rozwiązaniem tego problemu może być narzucenie ograniczenia na jednorodność
opóz
nienia. Aplikacja żąda od sieci aby wszystkie wysyłane przez nią pakiety posiadały
w miarę możliwości stałe opóz
nienie. Niekoniecznie warunek ten musi iść w parze z wy-
mogiem małego opóz
nienia  interesuje nas tylko by opóz
nienie utrzymywało się cały
czas na tym samym, określonym z góry poziomie.
Powyższe trzy parametry to najczęściej brane pod uwagę parametry QoS . Są one
również najłatwiejsze do zapewnienia  powszechnie znane są mechanizmy ogranicza-
nia przepustowości, czy też wyrównywania opóz
nień transmisji. Nic nie stoi jednak na
przeszkodzie by wziąć pod uwagę również inne, bardziej abstrakcyjne cechy transmisji.
Utrata pakietów
W momencie powstania zatorów w sieci IP niektóre pakiety IP mogą zostać odrzucone
 przypadkowo lub specjalnie. Pomimo iż protokoły warstwy wyższej (np. TCP) mogą
troszczyć się o korygowanie tego typu sytuacji, niekontrolowane odrzucanie pakietów
może być problemem. Utrzymanie utraty pakietów na określonym poziomie (na ogół
określanym procentowo) może być parametrem transmisji. Wymaga jednak dokładnego
sprecyzowania warunków dopuszczalnego stopnia gubienia pakietów. Ważne jest zarówno
miejsce (w którym miejscu sieci może występować utrata pakietów) jak i okres czasu
w jakim ta utrata następuje (np  nie więcej niż 10% w przeciągu 15min ).
Tego typu gwarancja jest na ogół trudna do osiągnięcia. Bez znajomości charakte-
rystyki ruchu któremu mamy zapewnić tego typu gwarancję może być to bardzo trudne
zadanie. Staje się ono łatwiejsze w momencie gdy mamy zapewnić określony poziom
pakietów w obrębie jednej konkretnej transmisji o znanych z góry parametrach.
Koszt
Bardzo często zdarza się że klienta dostawcy usług sieciowych bardziej od innych
cech usługi interesuje koszt całego przedsięwzięcia. Pomimo iż cena przesłania jednego
6
2. Parametry QoS
pakietu IP jest pojęciem dość abstrakcyjnym, istnieje możliwość wprowadzenia gwaran-
cji określonego kosztu transmisji jako parametru QoS . Przykładowo, niektóre protokoły
routingu oferują możliwość określenia  kosztu każdej z dostępnych tras [Moy98]. Jeżeli
teraz koszt tras będzie odzwierciedlał faktyczne koszty ponoszone przez dostawcę, oraz
będą prowadzone odpowiednie rozliczenia, dostawca jest w stanie zaoferować klientowi
zróżnicowane usługi:  taniej ale wolniej ,  drożej i szybciej itp.
Inne
Oprócz opisanych powyżej parametrów, zdefiniować można wiele innych, zarówno
jakościowych jak i ilościowych. O ile jednak powyższe parametry przekładają się w jasny
sposób na konkretne traktowanie pakietów, o tyle inne parametry mają bardziej wymiar
 biznesowy niż techniczny. Bardzo często  biznesowe parametry QoS znajdują miejsce
w umowach odnośnie świadczenia usług sieciowych. Tego typu zobowiązania nazywane
są uzgodnieniami poziomu usług (ang. SLA, Service Level Agreement) i przyjmują na
ogół formę opisową.
Uzgodnienia te precyzują warunki na jakich dostawca usług sieciowych świadczy usłu-
gi na rzecz klienta. Uzgodnienie poziomu usług zawiera informacje na temat sposobu
w jaki zostanie potraktowany ruch generowany przez klienta. Na ogół w SLA określone
są parametry  biznesowe które przekładają się na konkretne wartości trzech podstawo-
wych parametrów QoS . SLA może zawierać również dokładną specyfikację metod i miejsc
pomiaru parametrów ruchu sieciowego  dostawca może swoje gwarancje ograniczyć do
określonego fragmentu sieci, na ogół jest to obszar  do pierwszego routera brzegowego .
Często też SLA zawiera konsekwencje niewypełnienia umowy.
Przykładowe treści SLA:
dostępność łącza  strona świadcząca usługi określa przez jaki procent czasu usługa ma
prawo działać nieprawidłowo, wskutek konserwacji czy też nieprzewidzianej awarii
( dostępność łącza wynosi 98% w skali miesiąca );
utrata pakietów  określona zarówno opisowo ( niska utrata pakietów ) lub ilościowo
( nie więcej niż 5% w ciągu tygodnia );
koszt  klient będzie rozliczany na podstawie ilości przesłanych danych, po przekro-
czeniu określonego limitu miesięcznego dostawca przestaje gwarantować niektóre
parametry ruchu (np. likwidowana jest gwaranacja minimalnej przepustowości).
7
ROZDZIAA
3
Korzyści kontra niedogodności
Po przeczytaniu wymienionej w poprzednim rozdziale listy parametrów QoS powstaje
pytanie: czy warto się troszczyć o określone parametry transmisji? Po co zabiegać o utrzy-
manie konkretnych wartości opóz
nienia, czy też dbać o sprawiedliwy podział przepusto-
wości łącza? Internet istnieje już od dość dawna  skoro radził sobie do tej pory, czy
naprawdę nie można się obejść bez QoS ?
Odpowiedz
brzmi: tak oraz nie.
Dzisiejszy Internet nie jest już tą samą siecią, którą projektowali na początku lat
 70 amerykańscy specjaliści. Przy bieżącej tendencji podłączania do Internetu coraz to
nowych urządzeń, ilość ruchu w globalnej sieci rośnie lawinowo. Jeżeli nie podejmie się
żadnych kroków mających na celu polepszenie wydajności transmisji w sieci, Internet
udławi się samym sobą.
Skoro jednak wymagana jest jakaś zmiana, to czemu akurat QoS ? Czy jest to magicz-
ny środek który rozwiąże wszystkie problemy? Oczywiście nie. QoS nie jest panaceum
które  od ręki rozwiąże wszystkie problemy tłoku w sieciach. Właściwie zaaplikowany
potrafi jednak znacząco poprawić działanie danego fragmentu sieci. Kluczowe słowo to
 właściwie  pomimo starań wielu firm, gwarantowana jakość usług jest mechanizmem
który należy w momencie implementacji dokładnie i precyzyjnie skonfigurować, dosto-
sowując konfigurację do zastanej w danym fragmencie sieci sytuacji. Dodatkową zaletą
mechanizmów QoS jest to, że sporą część z nich można zaaplikować już istniejącym sie-
ciom bez konieczności dokonywania gruntownych zmian w ich obrębie. Oczywiście im
większy region sieci będzie świadom istnienia mechanizmów QoS , tym lepsze efekty uda
się osiągnąć.
8
3. Korzyści kontra niedogodności
Co daje poprawne zaimplementowanie mechanizmów QoS w sieci? Stwierdzenie, iż
przynosi ono zawsze bezwarunkową i widoczną poprawę byłoby nie do końca prawdzi-
we. QoS może poprawić wydajność w przypadku współdzielenia jednego łącza sieciowe-
go przez więcej niż jednego użytkownika. Wachlarz możliwych do wprowadzenia ulep-
szeń jest szeroki  od automatycznej semi-sprawiedliwości  każdemu po równo począw-
szy, na skomplikowanych systemach uprawnień i klas skończywszy. Dzięki mechanizmom
gwarantowanej jakości usług można też wyodrębnić z ruchu sieciowego określone rodza-
je transmisji i potraktować je w specjalny  priorytetowy bądz
też marginalny. Mimo
iż wprowadzona hierarchia nie będzie przestrzegana zawsze w sposób ścisły (ze wzglę-
du na właściwości protokołu IP, patrz rozdział 5), pozwoli to na w miarę precyzyjne
określenie priorytetów pomiędzy poszczególnymi transmisjami. Tym samym, osoby za-
rządzające siecią otrzymają potężne narzędzie do kształtowania ruchu. W zależności od
sposobu zaaplikowania, może ono posłużyć do różnych celów. Przykładowo, w biurowej
sieci komputerowej, po wprowadzeniu odpowiednich mechanizmów QoS , administrator
może wyodrębnić ruch ważny  korespondencję służbową, sprawozdania dla zarządu, pra-
ca interaktywna z systemem rozliczeniowym firmy  oraz mniej ważny  korespondencję
prywatna pracowników, przeglądanie stron WWW.
Należy jednak pamiętać, że mechanizmy QoS mają swoją cenę. Węzeł sieci który
oprócz routowania ma pełnić dodatkowo rolę klasyfikatora treści, bądz
też  zagląda-
jąc do wnętrza pakietów decydować o ich poziomie ważności będzie potrzebował więcej
mocy obliczeniowej niż zwykły węzeł zajmujący się zwykłym routowaniem. Jeżeli nie
ma możliwości zapewnienia owej dodatkowej mocy obliczeniowej, prawdopodobna jest
sytuacja w której wprowadzenie mechanizmów QoS pogorszy wydajność sieci  routery
będą tracić zbyt dużo czasu na podejmowaniu decyzji. Alternatywą może być dobranie
odpowiednich, mało kosztownych obliczeniowo algorytmów [QoS99].
Zupełnie osobną kwestią pozostaje świadomość istnienia mechanizmów QoS wśród
użytkowników sieci. Koncepcja gwarantowania jakości usług sieciowych nie jest pomysłem
nowym, QoS było już tematem wielu rozpraw, zarówno teoretyków jak i praktyków.
Mimo to, temat gwarantowanej jakości usług jest stosunkowo mało popularny wśród
użytkowników sieci, z bliżej nieznanych autorowi pracy powodów. Jedną z możliwych
przyczyn jest najprawdopodobniej spory stopień skomplikowania dokumentacji opisującej
QoS w najpopularniejszym sieciowym systemie operacyjnym  Linuksie. Co za tym idzie
 wdrożenia QoS ograniczają się na ogół do niewielkich obszarów sieci.
3.1 Wymagania implementacyjne
Warto spróbować oszacować problemy przed jakimi staje osoba pragnąca wprowa-
dzić gwarantowaną jakość usług w swojej sieci. Dokładne zidentyfikowanie potrzeb oraz
9
3. Korzyści kontra niedogodności
przeszkód jest podstawą doboru optymalnych technik QoS dla danego fragmentu sieci.
Żelazną zasadą implementacji1 QoS jest postępowanie według następującego schema-
tu:
1. Sprawdzenie stanu bieżącego.
Przed przystąpieniem do jakichkolwiek działań należy dokonać pomiarów ruchu
w badanym fragmencie sieci oraz wyizolować punkty w których następują zatory.
Poprzez analizę ruchu w sieci należy wyznaczyć jaki rodzaj ruchu w niej dominu-
je. Dodatkowo należy ustalić jakie jest pierwotne przeznaczenie danego fragmentu
sieci (by móc wyodrębnić sytuację, w której ruch niepożądany  zagłusza ruch po-
żądany w sieci).
2. Zaproponowanie rozwiązań.
Przeanalizować różnice pomiędzy stanem bieżącym a pożądanym. Wyznaczyć moż-
liwe do osiągnięcia cele. Spośród dostępnych i pasujących do zbadanej sytuacji
mechanizmów QoS wybrać najbardziej optymalne, pamiętając jednocześnie o ich
kosztach obliczeniowych.
3. Implementacja wybranych mechanizmów.
W wybranych węzłach sieci uruchomić odpowiednie mechanizmy QoS , w miarę
potrzeby na bieżąco modyfikując ich parametry.
4. Dokonanie pomiarów wydajności.
Dokonać pomiarów ruchu w tych samych miejscach co uprzednio. Zlokalizować
ewentualne miejsca zatorów (o ile istnieją). Przeanalizować strukturę ruchu w sieci.
W miarę możliwości uwzględnić opinie użytkowników sieci.
5. Ocena implementacji.
Przeanalizować różnice pomiędzy stanem bieżącym a pożądanym. W przypadku
zaistnienia nieakceptowalnych rozbieżności, wrócić do punktu 2. Jeżeli osiągnięty
został konsensus, wskazane jest przeprowadzanie co pewien czas kontrolnych po-
miarów wydajności działania sieci.
Na ogół mechanizmy QoS umiejscowione są w III warstwie modelu OSI/ISO. Podczas
ich działania decyzje podejmowane są na podstawie dokonanej uprzednio konfiguracji
węzła, oraz z analizy nagłówków pakietów IP. Niekiedy analizowane są również warstwy
wyższe (np. w przypadku mechanizmu NBAR analizowana jest warstwa aplikacji [Cis02b])
aczkolwiek są to operacje bardziej złożone i czasochłonne. Do zapewnienia określonych
1
Odnosi się to zresztą do każdej zmiany mającej na celu podniesienie wydajności dowolnego systemu.
10
3. Korzyści kontra niedogodności
parametrów transmisji stosowane są różnego rodzaju algorytmy kolejkowania pakietów
IP, lub też algorytmy zapobiegania zatorom [QoS99]. Jeżeli w warstwie II występują
adekwatne mechanizmy kontroli przepływu mogą one zostać również wykorzystane.
3.2 Skalowalność rozwiązań
W przypadku implementacji mechanizmów QoS w obrębie jednego węzła sieci można
przyjąć schemat działania przedstawiony na rysunku 3.1.
Rysunek 3.1: Koncepcja działania QoS w obrębie jednego węzła sieci
Router posiada informacje odnośnie parametrów QoS , które ma zapewnić poszczegól-
nym przepływom danych. Z całego ruchu przechodzącego przez węzeł należy wyodrębnić
pakiety należące do poszczególnych transmisji. Transmisje grupowane są w klasy ruchu
na podstawie zapotrzebowań na parametry QoS . Poszczególne klasy ruchu obsługiwane
są przez adekwatne do zapotrzebowań mechanizmy QoS .
Podstawowym problemem rozwiązań QoS jest ich skalowalność. W najbardziej pod-
stawowym scenariuszu mechanizmy QoS implementowane są tylko i wyłącznie w obrębie
jednego węzła sieci, najczęściej routera brzegowego dla danego fragmentu sieci. Tego typu
wdrożenie jest stosunkowo proste, zmiany w konfiguracji wprowadzane są tylko w obrębie
jednego węzła, analiza ruchu przebiega też wyłącznie w jednym miejscu. Jest to jednak
rozwiązanie lokalne, które może zapewnić QoS tylko w obrębie bezpośrednio przylegają-
cych sieci.
W momencie gdy implementacja QoS ma objąć więcej niż jeden węzeł pojawiają się
dodatkowe problemy. Z racji tego, że określone parametry transmisji muszą zostać zapew-
nione na całym odcinku pomiędzy nadajnikiem a odbiornikiem, do mechanizmów QoS
należy dodać jakąś metodę sygnalizacji zapotrzebowań na parametry ruchu. Podstawo-
wym założeniem takiej metody powinna być minimalizacja ilości przesyłanych przez nią
11
3. Korzyści kontra niedogodności
informacji, tak, aby przesyłanie informacji kontrolnych nie zakłócało normalnego ruchu.
Sygnalizacja może odbywać się zarówno w obrębie pakietów zawierających dane (np.
DiffServ, opisany w rozdziale 5.2) jak i w ramach dodatkowej transmisji (np. protokół
RSVP, rozdział 5.1). Sygnalizacja taka musi też być skalowalna tak, aby można było ją
zastosować zarówno w sieciach o niewielkiej liczbie węzłów jak i w sieciach rozległych,
oraz w Internecie, gdzie pomiędzy nadajnikiem a odbiornikiem występuje wiele niepodle-
gających wspólnemu zarządzaniu routerów. Całość mechanizmu QoS (czyli mechanizmy
zapewniające określone parametry transmisji plus mechanizmy sygnalizacji) powinna też
działać niezależnie rodzaju medium i techniki sieci występujących w warstwie II. Tam
gdzie jest to możliwe QoS powinien wykorzystywać istniejące już mechanizmy (np. usłu-
gi sieci ATM). Tam gdzie nie ma takiej możliwości, należy stworzyć możliwie  solidne
gwarancje za pomocą mechanizmów warstw wyższych.
Podstawowe mechanizmy QoS ( sprawiedliwy podział łącza, itp.) świetnie spraw-
dzają się w punktach styku sieci lokalnych z sieciami WAN. W sieciach szkieletowych,
gdzie węzły sieci odpowiedzialne są za przekazywanie gigantycznych ilości ruchu dokładne
kształtowanie ruchu może okazać się niemożliwe do przeprowadzenia. Wraz z natężeniem
ruchu wzrasta też ilość danych koniecznych do przeanalizowania  w przypadkach eks-
tremalnych wprowadzenie mechanizmów QoS może doprowadzić do spowolnienia mecha-
nizmu routowania. W takich przypadkach możliwe jest wprowadzenie mniej dokładnych
(a co za tym idzie, mniej kosztownych obliczeniowo) mechanizmów kształtowania ruchu.
Alternatywą może być zaimplementowanie mechanizmów QoS w postaci sprzętowej.
Ostatnim aspektem który należy rozważyć przy  globalnym wprowadzaniu QoS,
jest kontrola i konfiguracja całości mechanizmów. Wraz z rosnącą liczbą węzłów rośnie
liczba koniecznych do dokonania konfiguracji sprzętu. W celu rozwiązania tej kwestii
opracowano protokół COPS (ang. Common Open Policy Service) [Dur00]. Służy on do
przekazywania informacji o sposobie w jaki pojedyńczy węzeł powinien traktować okre-
ślone klasy ruchu. Używając COPS, możemy zdefiniować w obrębie segmentu sieciowego
jedno punkt  konfiguracyjny w którym administrator określa zestawy reguł. Punkt taki
nosi nazwę PDP (ang. Policy Decision Point). Każdy węzeł sieci biorący udział w za-
pewnianiu gwarantowanej jakości usług pobiera zestaw reguł z PDP, i wprowadza je
w życie, stając się tym samym punktem PEP (ang. Policy Enforcement Point). Protokół
COPS jest standardem otwartym, co nie ogranicza pola zastosowania tego protokołu do
jakiejś konkretnej platformy sprzętowej [Dur00].
12
3. Korzyści kontra niedogodności
Rysunek 3.2: Przykład rozdziału informacji pomiędzy PDP a PEP.
3.3 Kształtować czy nie kształtować?
Abstrahując od technicznych aspektów wdrożeń systemów QoS warto rzucić okiem na
dodatkowe kwestie wynikające z faktu kształtowania ruchu. Jako iż aplikowanie mecha-
nizmów QoS może zostać odebrane przez użytkowników sieci jako działanie  negatywne
(np. zmniejszanie ilości dostępnego pasma), kwestia ta powinna być zawsze uregulowana
pomiędzy dostawcą usług sieciowych a korzystających z nich klientem. Dość często zda-
rzają się przypadki kształtowania ruchu wychodzącego z sieci klienta po stronie dostawcy.
Z drugiej jednak strony, zawierane powszechnie umowy o świadczenie usług internetowych
bardzo rzadko zawierają konkretne gwarancje jakichkolwiek parametrów ruchu, a jeżeli
już takowe występują to okupione są znacznym wzrostem ceny usługi. Wydawałoby się
więc, że w obliczu braku gwarancji jakości usług w umowie, dostawca ma prawo dość do-
wolnie kształtować ruch generowany przez sieć klienta. Jest to jednak miecz obosieczny 
niezadowoleni klienci  zagłosują portfelem i zrezygnują z usług dostawcy. Wskazanym
byłoby więc wszelkie kwestie QoS omawiać z bezpośrednio zainteresowaną stroną. Dodat-
kowo, można pokusić się o wprowadzenie pewnego  społecznego QoS  , sprowadzającego
się do ustalenia umownych reguł odnośnie poziomu ruchu w sieci. Wbrew pozorom, tego
typu podejście bywa czasami równie skuteczne jak wyszukane mechanizmy QoS imple-
mentowane wbrew chęciom klienta.
13
Część II
Mechanizmy QoS
14
ROZDZIAA
4
Metody zapewnienia QoS
W momencie gdy zdefiniowaliśmy już pojęcie QoS oraz nasze oczekiwania wobec
tego mechanizmu są jasno sprecyzowane, możemy przystąpić do rozważań odnośnie jego
budowy. Na całościowy obraz QoS składać się będzie wiele części składowych.
Wydajny mechanizm QoS powinien zawierać:
" sposób na zakomunikowanie dokonywanych rezerwacji wybranym węzłom sieci;
" sposób na faktyczne zapewnienie nienaruszalności zarezerwowanych zasobów w ob-
rębie węzła sieci [QoS99].
Praktyczna implementacja takiego mechanizmu powinna zostać dodatkowo wzbogaco-
na o:
" interfejs dla aplikacji chcących dokonać rezerwacji zasobów sieciowych;
" scentralizowany model zarządzania działającymi mechanizmami QoS .
O ile dwa ostatnie problemy są ściśle związane z platformą sprzętową na której do-
konywana jest implementacja QoS , o tyle w dziedzinie pierwszych dwóch problemów
istnieje szeroka gama proponowanych rozwiązań. Poniżej przedstawione zostały najpopu-
larniejsze, najczęściej stosowane rozwiązania w dziedzinie sygnalizacji oraz zaspokajania
zapotrzebowań na zasoby sieciowe.
Warto pamiętać że wymienione metody są metodami niskopoziomowymi  żadna
z nich w pojedynkę nie stanowi kompletnego rozwiązania problemu QoS . Dopiero po-
łączenie kilku z nich jest w stanie pretendować do miana działającego mechanizmu.
15
4. Metody zapewnienia QoS
4.1 Przekazywanie informacji o QoS
Jeżeli mechanizm QoS ma funkcjonować poprawnie na obszarze większym niż poje-
dynczy węzeł sieci, sieć musi dysponować metodą powiadomienia sąsiadujących węzłów
o istniejących rezerwacjach. Informacja ta, musi podążać dokładnie tą samą trasą co
pakiety IP których dotyczy rezerwacja, tak aby rezerwacji dokonały routery przez któ-
re przechodzi dana transmisja. Kluczowym elementem jest  gadatliwość rozwiązania 
przy zbyt wielkiej ilości przekazywanych informacji o rezerwacjach stłamszeniu ulegnie
zwykły ruch sieciowy.
Sygnalizowanie (ang. signaling)
Do przekazywania informacji o rezerwacjach służy osobny protokół warstwy III mode-
lu OSI. Przykładem takiego protokołu może być RSVP (Resource ReSerVation Protocol)
zdefiniowany w [RB97]. Każdy z węzłów sieci zaangażowany w mechanizm QoS tego typu,
zobowiązany jest odbierać i przesyłać dalej komunikaty RSVP, niezależnie od tego czy
zamierza je samemu honorować. Router powinien odczytywać zawartość pakietów RSVP
i wprowadzać ją w życie  w określony sposób potraktować transmisję której dany pakiet
RSVP dotyczy [Bra94]. Jeżeli dla każdej przechodzącej przez router transmisji dostępne
są informacje odnośnie QoS uzyskane dzięki RSVP, to router jest w stanie precyzyjnie
regulować przydział zasobów sieciowych dla poszczególnych transmisji. Wadą tego typu
rozwiązania jest narzut jaki wprowadza dodatkowy ruch w postaci komunikatów RSVP.
Dodatkowo, wszystkie węzły sieci pomiędzy nadajnikiem i odbiornikiem muszą rozumieć
i honorować ten sposób sygnalizacji  jeżeli chociaż jeden z nich zignoruje pakiety RSVP
rezerwacja nie obejmie całej trasy.
Dokładny opis RSVP zawarty został w punkcie 5.1.
Znakowanie pakietów (ang. packet marking)
Metoda ta polega na umieszczeniu informacji odnośnie QoS w obrębie nagłówka pa-
kietu IP. Dzięki takiemu rozwiązaniu znika problem generowania nadmiarowego ruchu
w sieci  pakiety IP zyskują swoistą  etykietkę zawierającą informacje odnośnie żąda-
nych parametrów QoS . Przykładem takiego znakowania może być pole ToS (Type of
Service) lub jego rozszerzenie zdefiniowane w ramach struktury DiffServ [Nic98]  DSCP
(DiffServ Code Point). Przy tego typu sygnalizacji znika problem  inteligencji urządzeń
 nawet jeśli pewien węzeł po drodze zignoruje dane zawarte w nagłówku to żadna in-
formacja nie zostanie utracona. Niestety, pole przeznaczone do znakowania jest na ogół
niewielkie (np. 1 bajt) i nie pozwala na dokładne zdefiniowanie zapotrzebowań danej
16
4. Metody zapewnienia QoS
transmisji. Zamiast tego, w polu tym znajduje się na ogół liczba która określa klasę
ruchu zgodnie z opisaną w RFC klasyfikacją.
4.2 Agregowanie przepływów
W momencie gdy przez dany węzeł sieci przechodzi duża liczba transmisji, niemoż-
liwym staje się pilnowanie parametrów każdej z nich osobno  zadanie to staje się zbyt
złożone obliczeniowo. Aby temu zapobiec, transmisje grupowane są w większe grupy lub
też klasy ruchu, po czym właśnie im zapewniane są określone parametry QoS . Tego typu
podejście sprawdza się wyśmienicie przy statycznych rezerwacjach, dokonywanych  na
sztywno w obrębie węzła, np.:  wszystkie transmisje HTTP mają zajmować nie więcej
niż 30% pasma .
4.3 Zarządzanie buforem
W momencie gdy pakiet IP ma opuścić dany węzeł sieci, kierowany jest do specjalnego
bufora związanego z interfejsem wyjściowym. W najbardziej podstawowym przypadku,
bufor ten działa na zasadzie kolejki FIFO (ang. First In First Out)  pakiety opuszczają
bufor w kolejności w jakiej do niego wchodzą.
Rysunek 4.1: Najprostszy bufor przypisany do interfejsu.
Pakiety oznaczone tym samym znakiem należą do jednej transmisji.
Zmieniając parametry bufora oraz zasadę jego działania możemy uzyskać odpowiednie
gwarancje w zakresie parametrów transmisji. Ten rodzaj mechanizmów leży u podstaw
gwarantowanej jakości usług.
Analogiczny bufor związany może być również z interfejsem wejściowym. Bardziej za-
awansowane implementacje pozwalają też na stworzenie bufora pośredniego, przez który
przepływa określona część ruchu, niezależnie od interfejsu z którego przychodzi oraz przez
który opuszcza router.
17
4. Metody zapewnienia QoS
Kolejkowanie pakietów (ang. packet scheduling/queueing)
Tego rodzaju techniki bazują na zmianie algorytmu układania pakietów w buforze.
Możliwości modyfikacji są bardzo duże, jedyną granicą pozostaje szybkość działania al-
gorytmu kolejkowania. Wśród obecnych implementacji wyróżnia się m.in.:
" kolejki priorytetowe  bazujące na wprowadzaniu systemu priorytetów wśród pa-
kietów;
" kolejki klasowe  grupujące pakiety w określone grupy ruchu;
" kolejki  sprawiedliwe  zaprowadzające pewnego rodzaju sprawiedliwość pomiędzy
określonymi grupami ruchu.
Dokładne omówienie tego typu algorytmów znajduje się w punkcie 7.4.
Kształtowanie przepływu (ang. traffic shaping)
Algorytmy tego typu zajmują się ograniczaniem prędkości przepływu. Stosowane są
w miejscach gdzie występuje konieczność spowolnienia zbyt szybko nadpływających da-
nych. Nadchodzące dane kolejkowane są w buforze z którego wypuszczane są w okre-
ślonym tempie. Najczęściej spotykana implementacja to algorytm  wiadra z żetonami
(TBF, Token Bucket Filter). Więcej na ten temat znalez
ć można w punkcie 7.3.
Unikanie zatorów (ang. congestion avoiding)
Większość mechanizmów zarządzających buforem aktywowanych jest dopiero w mo-
mencie gdy w buforze wystąpi zator (tzn. stopień jego zapełnienia wzrośnie powyżej
określonego poziomu, np. 80%). Możliwe jest jednak inne podejście  działać tak, by nie
dopuścić do sytuacji zbytniego zapełnienia bufora. Sprowadza się to na ogół do celowego
gubienia wybranych pakietów wchodzących do bufora. Nie dezorganizuje to w istotny
sposób transmisji  warstwa IP nie gwarantuje że pakiety dotrą na miejsce, zajmuje się
tym warstwa IV. Jeżeli tylko nadajnik kontroluje tempo transmisji (w zależności od ilości
otrzymywanych od odbiornika potwierdzeń), tego typu prewencyjne odrzucanie pakietów
może przynieść zaskakująco dobre skutki. Poszczególne algorytmy tego typu różnią się
głównie sposobem doboru odrzucanych pakietów  zostało to opisane bliżej w punkcie
7.5.
4.4 Techniki dodatkowe
Poniższe techniki nie należą do ścisłego repertuaru mechanizmów QoS , mogą być
jednak pomocne w poprawieniu wydajności działania danego interfejsu.
18
4. Metody zapewnienia QoS
Fragmentacja pakietów (ang. packet fragmentation)
Podczas podróży przez sieć, pakiet IP może zostać podzielony na części w momencie
gdy sieć przez którą przechodzi nie jest w stanie przenieść tak dużego pakietu w całości.
Proces taki nazywany jest fragmentacją. Fragmentacja pakietów może też być stosowana
jako mechanizm poprawiający wydajność obsługi bufora  pakiety mogą być dzielone
na równe części, tak by zmniejszyć dysproporcje pomiędzy pakietami poszczególnych
transmisji [Cis02b].
Kontrola dostępu do łącza (ang. admission control)
Jeżeli dany węzeł sieci posiada informacje odnośnie dostępnych parametrów QoS w in-
nych częściach sieci, jest w stanie na podstawie tych danych ocenić, czy możliwe jest
dopuszczenie kolejnej transmisji. W przypadku braku zasobów aplikacja która próbowała
dokonać rezerwacji zostanie poinformowana przez router że rezerwacja została odrzu-
cona i połączenie nie może być zrealizowane. Aplikacja może spróbować ponownie, po
odczekaniu pewnego czasu, lub też rozpocząć transmisję bez jakiejkolwiek gwarancji jej
parametrów ze strony sieci. Tego typu model sprawdza się szczególnie dobrze w rozwią-
zaniach VoIP, zwłaszcza gdy w roli  nadajnika występuje człowiek  odmowa transmisji
będzie porównywalna z komunikatem  abonent chwilowo niedostępny znanym z telefonii
tradycyjnej [Cis02b, W2k00].
19
ROZDZIAA
5
Protokół IP
Protokół IP (wersja 4) jest swoistym kamieniem węgielnym Internetu. W chwili obec-
nej jest on najczęściej używanym protokołem warstwy III, zarówno w sieciach rozległych,
jak i w sieciach lokalnych. Pomimo projektów protokołów nowej generacji, mających za-
stąpić IP (np. IPv6), protokół IP pozostaje najbardziej powszechnym protokołem siecio-
wym. Z tego m.in. powodu, niniejsza praca skupia się na kwestiach dotyczących sposobu
implementacji mechanizmów QoS w sieciach IP.
Protokół IP zdefiniowany został w roku 1981, w ramach projektu DARPA [oSC81].
Motywacją do jego opracowania była chęć stworzenia sieci działającej w oparciu o prze-
łączanie pakietów. Zadaniem pakietów IP jest transport informacji zawartej w nim, po-
między nadawcą a odbiorcą. Do zadań protokołu IP nie należy natomiast zapewnienie
spójności przesyłanych danych czy też zachowanie ich poprawnej kolejności  tymi rze-
czami mają się zająć protokoły warstwy wyższych, w szczególności warstwy IV (np. TCP
albo UDP). Protokół IP jest protokołem bezpołączeniowym, dane  pakowane są do
pakietów IP, po czym wysyłane są poprzez sieć, bez wcześniejszego wyboru trasy lub
też dokonywania jakichś czynności sterujących. Pojedyńczy pakiet IP podróżuje  samo-
dzielnie , niezależnie od reszty pakietów wchodzących w skład danej transmisji. Dopiero
odbiornik który  w wariancie optymistycznym  otrzyma wszystkie pakiety IP, skleja
informację z powrotem, kierując się informacjami kontrolnymi warstw wyższych.
Z punktu widzenia QoS ma to zarówno dobre jak i złe strony. Brak mechanizmu kon-
trolnego uniemożliwia sprawowanie dokładnej kontroli nad parametrami poszczególnych
transmisji. Z drugiej strony  skoro RFC nie określa takiego mechanizmu, można pokusić
się o opracowanie osobnych rozwiązań, w zależności od potrzeb.
20
5. Protokół IP
Większość metod opisanych w rozdziale 4 znajduje swoje zastosowanie w przypadku
protokołu IP. W trakcie przetwarzania przez router pakiet IP jest umieszczany w bu-
forach kolejno interfejsu wejściowego a potem interfejsu wyjściowego. Można więc sto-
sować wszystkie techniki bazujące na manipulacji pakietami w buforze (kolejkowanie,
kształtowanie, unikanie zatorów, fragmentacja). Problemem który pozostaje nierozwią-
zany jest klasyfikacja ruchu i informowanie o rezerwacjach. Obydwa zjawiska wymagają
chociażby szczątkowej informacji o przechodzących przez dany węzeł transmisjach, która
w przypadku pakietów IP jest trudna (ale nie niemożliwa) do odczytania z racji jego
bezpołączeniowości.
RFC definiuje dokładnie budowę nagłówka pakietu IP.
Rysunek 5.1: Budowa nagłówka pakietu IP.
Na skali zaznaczono numery bitów.
Szczegółowe omówienie funkcji wszystkich pól nagłówka wykracza poza zakres tej
pracy (informacje te można znalez
ć w [oSC81]). Z punktu widzenia QoS, istotne są trzy
pola:
" adres nadawcy oraz adres odbiorcy  według tych pól można dokonywać klasyfikacji
i agregacji pakietów IP.
" ToS (ang. Type of Service) określające rodzaj usługi przenoszonej przez dany pa-
kiet.
Ośmiobitowe pole ToS miało w intencjach autorów specyfikacji protokołu IP stanowić
możliwość wyróżnienia kilku poziomów ruchu, traktowanego odmiennie. Pierwotna pro-
pozycja składu tego pola szybko okazała się być mało praktyczna i została rozbudowana
w [Alm92].
21
5. Protokół IP
W polu ToS można wyróżnić trzy składowe.
Rysunek 5.2: Składowe pola ToS.
Najbardziej istotne dla QoS jest pole drugie, określające rodzaj  usługi jaką dany
pakiet powinien od routera otrzymać. Odpowiednie bity w polu ToS odpowiadają:
1000  minimize delay
taki pakiet powinien zostać przesłany z minimalnym opóz
nieniem;
0100  maximize throughput
dla tych pakietów należy zarezerwować jak największą część dostępnego pasma;
0010  maximize reliability
takiego pakietu nie należy odrzucić, należy zapewnić takie warunki by został on na
pewno dostarczony;
0001  minimize monetary cost
przesłanie tego pakietu ma być możliwie najtańsze;
0000  normal service
pakiet nie zawiera informacji odnośnie QoS , można potraktować go dowolnie.
Pole  ważność określa jak bardzo istotny jest dany pakiet i na ile niewskazane jest
jego odrzucenie, dając możliwość stworzenia dodatkowej gradacji w obrębie danej usługi.
Ostatni bit jest równy zero.
Niestety, tego typu klasyfikacja nie sprawdziła się w praktyce. Jej podstawową wadą
była zbyt mała rozdzielczość klasyfikacji  znacząc pakiet IP aplikacja mogła zażądać
maksymalnej przepustowości, nie mogła natomiast zażądać określonej przepustowości.
Analogicznie w przypadku innych parametrów  były to rezerwacje w stylu  wszystko
albo nic . Trzybitowe pole ważność nie dawało możliwości dokładnego wyspecyfikowania
parametrów QoS , pozwalało tylko określić względny poziom ważności pakietów.
W odpowiedzi na niewystarczającą funkcjonalność pola ToS rozpoczęto prace nad in-
nymi metodami sygnalizowania rezerwacji. Jako pierwszy, w 1994 roku powstał IntServ
(ang. Integrated Services, czyli  usługi zintegrowane ), bazujący na pomyśle sygnalizo-
wania rezerwacji QoS za pomocą osobnego protokołu [Bra94,RB97]. Cztery lata póz
niej,
22
5. Protokół IP
w ramach alternatywy, jako rozwiązanie bardziej  lekkie powstała specyfikacja Diff-
Serv [Bla98,Bla01] (ang. Differentiated Services, czyli  usługi zróżnicowane ). Koncepcja
DiffServ bazowała na znakowaniu pakietów IP, w obrębie (ponownie przedefiniowanego)
pola ToS [Nic98]. Obydwa rozwiązania znalazły swoje zastosowania, w pewien sposób
uzupełniając się nawzajem.
Przy analizowaniu obydwu propozycji należy pamiętać, że są to rozwiązania proble-
mów wysokopoziomowych. Ani DiffServ ani IntServ nie precyzują jakich konkretnie algo-
rytmów mają używać węzły sieci w celu osiągnięcia konkretnych parametrów QoS . W tej
dziedzinie RFC ograniczają się wyłącznie do sugestii rodzin algorytmów. Dokumenty te
opisują natomiast dokładnie problemy propagowania informacji dotyczących rezerwacji
QoS w sieci, jak i określają co ma być podstawą podejmowania decyzji o użyciu konkret-
nych algorytmów.
5.1 IntServ
Angielski termin Integrated Services tłumaczy się na język polski jako  usługi zinte-
growane  chodzi o integrację usług QoS z istniejącą strukturą IP. IntServ bazuje na
pomyśle sygnalizowania zapotrzebowań na parametry QoS za pomocą osobnego proto-
kołu warstwy III, RSVP [RB97].
Rezerwacja jest jednostronna  nawet jeśli używany jest dwukierunkowy (ang. full-
-duplex) protokół TCP, gwarancja parametrów QoS istnieje tylko  w jedną stronę .
Odbiornik przed rozpoczęciem transmisji dokonuje rezerwacji zasobów na trasie pomię-
dzy nadajnikiem a odbiornikiem, za pomocą protokołu RSVP. Wszystkie węzły sieci do
których dociera prośba z odbiornika, zobowiązane są do oceny możliwości przyjęcia żą-
danej rezerwacji. W momencie gdy któryś z węzłów nie jest w stanie dokonać wymaganej
rezerwacji, informuje o tym zainteresowane strony. Jeżeli wszystkie węzły sieci po drodze
zaakceptowały rezerwację, nadajnik rozpoczyna transmisję. Pakiety IP podróżując po
utworzonej uprzednio ścieżce mają gwarancję zarezerwowanych uprzednio parametrów
transmisji.
Rysunek 5.3 przedstawia zasadę działania protokołu RSVP w architekturze IntServ.
Procesy RSVP odpowiedzialne są za przetwarzanie komunikatów RSVP wysyłanych przez
nadajnik oraz odbiornik. Router odbiera informacje odnośnie rezerwacji po czym konsul-
tuje je ze zbiorem reguł zapisanych w konfiguracji oraz z faktycznym stanem łącza. Jeżeli
rezerwacja jest dopuszczalna to pakiet RSVP przesyłany jest dalej, a w obrębie routera
dokonywana jest rekonfiguracja niskopoziomowych mechanizmów QoS tak, aby uwzględ-
niły wymagania nowej transmisji.
23
5. Protokół IP
Rysunek 5.3: Architektura IntServ
Rezerwacja zasobów
Proces rezerwacji przebiega w następujący sposób:
1. Nadajnik wysyła do odbiornika komunikaty PATH.
Rysunek 5.4: Propagacja komunikatów PATH
24
5. Protokół IP
Komunikaty te nie dokonują żadnej rezerwacji. Ich celem jest poinformowanie wę-
złów sieci o zamiarze przeprowadzenia rezerwacji przez odbiornik. Jako że pakie-
ty RSVP podlegają tym samym zasadom routowania co pakiety IP, komunikaty
PATH podążają do odbiornika tą samą trasą którą podążać będą pakiety IP1. Każ-
dy router w momencie otrzymania komunikatu PATH zapisuje sobie IP węzła od
którego dostał ten komunikat.
2. Odbiornik wysyła komunikaty RESV.
Rysunek 5.5: Propagacja komunikatów RESV.
Dzięki utworzonej w punkcie pierwszym  ścieżce , komunikaty RESV zostaną prze-
słane dokładnie tą samą trasą którą podróżować będą pakiety IP należące do trans-
misji której dotyczy rezerwacja. Bez komunikatów PATH, komunikaty RESV zo-
stałyby przesłane zgodnie z regułami routingu  a to nie daje gwarancji że droga
pomiędzy nadajnikiem a odbiornikiem będzie taka sama w obydwie strony.
Komunikaty RESV niosą ze sobą informację o pożądanej rezerwacji. Każdy z wę-
złów sieci zobowiązany jest do podjęcia decyzji odnośnie tego czy będzie w stanie
zaakceptować transmisję o określonych parametrach. Jeżeli którykolwiek z węzłów
odmówi, rezerwacja się nie powiedzie.
1
Zakładając brak zmian w routingu. Przy ich występowaniu konieczna jest renegocjacja rezerwacji.
25
5. Protokół IP
3. Rozpoczyna się transmisja.
Rezerwacja dokonana w powyższy sposób nie jest rezerwacją stałą  musi ona zo-
stać odświeżona po określonym czasie. Można też wymusić rezygnację z rezerwacji 
stara rezerwacja jest wymazywana z pamięci węzłów sieci za pomocą komunikatów
ResvTear (wysyłanych przez odbiornik) oraz PathTear (wysyłanych przez nadaj-
nik). Mechanizm ten przydaje się pod koniec transmisji oraz w przypadku zmian
w routingu pakietów.
Tego typu strategia gwarantuje określone parametry QoS na całej trasie pomiędzy
nadajnikiem a odbiornikiem. Każdy z uczestniczących w transmisji routerów jest świa-
dom faktu istnienia transmisji o określonych parametrach, oraz konieczności zarezerwowa-
nia zasobów. Problemem jest tylko spora ilość danych organizacyjnych (pakiety RSVP)
przesyłanych w trakcie dokonywania rezerwacji. Co gorsza, rezerwacja musi okresowo
renegocjowana, problemem jest też każda zmiana w routingu pakietów  trzeba doko-
nać rezerwacji na nowej trasie. W przypadku transmisji unicastowych narzut jest zbyt
duży, by stosowanie tego mechanizmu miało sens. IntServ znajduje za to zastosowanie
w tranmisjach multicastowych, w scenariuszach z wieloma odbiornikami i niewielką ilością
nadawców.
Rysunek 5.6: IntServ a multicast.
W sytuacji takiej jak przedstawiona powyżej (jeden nadawca, czterech odbiorców),
routery pośrednie są w stanie rozpoznać rezerwacje pochodzące od odbiorców należących
do tej samej transmisji i zsumować rezerwacje żądane przez odbiorniki. W stronę nadajni-
26
5. Protokół IP
ka wysyłany jest już tylko jeden pakiet RSVP zawierający komunikat RESV rezerwujący
zasoby dla obydwu odbiorników [RB97].
Protokół RSVP
Opis protokołu RSVP definiuje następujące pojęcia:
sesja  grupa transmisji wyróżniająca się wspólnym adresem docelowym
(unicastowym lub multicastowym), protokołem warstwy IV oraz (opcjonalnie)
numerem portu w ramach tego protokołu
przepływ  grupa transmisji wyróżniająca się wspólnym adresem nadawcy
W obrębie sesji występuje zawsze przynajmniej jeden przepływ.
Rysunek 5.7: Przykład sesji RSVP zawierającej dwa przepływy
Dokładny opis komunikatów RSVP wykracza poza ramy niniejszej pracy, poniżej omó-
wiona zostanie budowa najistotniejszych z nich. Pełną specyfikację protokołu RSVP moż-
na znalez
ć w [RB97].
Każdy komunikat RSVP składa się z:
nagłówka  nagłówek zawiera liczba określająca rodzaj komunikatu, oraz całkowita dłu-
gość komunikatu.
obiektów RSVP  obiekty są częściami składowymi komunikatu, pakiet zawiera przy-
najmniej jeden obiekt.
27
5. Protokół IP
W komunikacie PATH zawarte są m.in. następujące obiekty RSVP:
" SESSION
identyfikator sesji RSVP;
" RSVP HOP
do tego obiektu każdy węzeł sieci w momencie przesyłania komunikatu dalej wpisuje
swój adres IP  dzięki temu możliwe jest stworzenie ścieżki którą będą przesyłane
komunikaty RESV;
" TIME VALUES
określa jak często rezerwacja ma być renegocjowana;
" SENDER TEMPLATE
określa po czym można rozpoznać pakiety należące do danego przepływu
" SENDER TSPEC
zawiera charakterystykę ruchu generowanego przez nadajnik;
" ADSPEC
do tego obiektu każdy węzeł sieci dopisuje swoje  możliwości w zakresie oferowa-
nych parametrów QoS .
Odbiornik po otrzymaniu komunikatu PATH dysponuje parametrami QoS jakie po-
winien zarezerwować, oraz przeglądem tego, co oferują routery po drodze.
W komunikacie RESV zawarte są m.in. następujące obiekty RSVP:
" STYLE
zawiera specyfikację rodzaju rezerwacji:
fixed filter  żądane zasoby rezerwowane są osobno dla każdego przepływu
(nadawcy);
shared explicit  żądane zasoby rezerwowane są wspólnie dla określonych w ko-
munikacie przepływów;
wildcard filter  żądane zasoby rezerwowane są wspólnie dla wszystkich prze-
pływów w obrębie sesji.
" FILTER SPEC
określa po czym można rozpoznać pakiety należące do danego przepływu;
" FLOWSPEC
zawiera opis rezerwacji która ma zostać dokonana.
28
5. Protokół IP
Wszystkie węzły sieci przez które przechodzi komunikat RESV odczytują rezerwację
jakiej życzy sobie odbiornik. Komunikat RESV docierający do nadajnika jest dla niego
sygnałem że rezerwacja została dokonana i może rozpocząć transmisję.
Usługi IntServ
W standardzie Integrated Services zdefiniowano dwa rodzaje usług [She97, Wro97,
Peu99]. Dokonując rezerwacji, aplikacja wskazuje z której usługi życzy sobie skorzystać.
Usługa gwarantowana (ang. Guaranted QoS)
Ta usługa pozwala aplikacji dokonać rezerwacji dwóch rzeczy: przepustowości oraz
opóz
nienia. Węzły sieci zobowiązują się utrzymywać dla danej transmisji przepustowość
nie mniejszą niż określona w rezerwacji. Opóz
nienie transmisji pomiędzy nadajnikiem
i odbiornikiem nie będzie większe niż opóz
nienie wyspecyfikowane w rezerwacji. Dodat-
kowo, żaden pakiet transmisji nie zostanie celowo odrzucony2 [She97].
Najczęściej ta usługa implementowana jest za pomocą algorytmu TBF (patrz 7.3),
z jedną istotną modyfikacją  jeżeli transmisja przekracza zarezerwowane parametry, nad-
miar klasyfikowany jest jako ruch dla którego sieć nie daje żadnej gwarancji parametrów
QoS .
Usługa kontrolowanego obciążenia (ang. Controlled-load Network Element
Service)
W momencie gdy sieć przez którą dokonywana jest transmisja nie jest obciążona,
a aplikacja nie dokonała żadnej rezerwacji, transmisja odbywa się na zasadzie  najwięk-
szego wysiłku (ang. best effort). Tego typu podejście, typowe dla tradycyjnych sieci IP
pozbawionych mechanizmów kontroli w warunkach niskiego obciążenia charakteryzuje
się małym opóz
nieniem, oraz niewielką utratą pakietów. Usługa kontrolowanego obcią-
żenia ma za zadanie zagwarantować warunki transmisji zbliżone do tych z chwil gdy sieć
nie jest obciążona3. Usługa ta nie daje konkretnych liczbowych gwarancji na określone
parametry QoS , pozwala jednak poprawić jakość transmisji w momencie występowania
zatorów w sieci [Wro97]. Typowym narzędziem stosowanym do implementacji tej usługi
są algorytmy  sprawiedliwe (patrz 7.2).
Wady i zalety
Zasadniczą zaletą architektury IntServ jest to, że daje ona  mocne gwarancje para-
metrów. Rezerwacja dokonywana jest przed rozpoczęciem transmisji na wszystkich wę-
2
Oczywiście nie eliminuje to strat wynikających z przekłamań transmisji, etc.
3
Nieobciążona nie oznacza że występuje tylko jedna transmisja.
29
5. Protokół IP
złach sieci, które będą brały udział w transmisji. Wymaga to oczywiście aby wszystkie
te urządzenia rozumiały protokół RSVP. Dodatkowo przez cały czas trwania transmisji
routery muszą utrzymywać w swojej pamięci informacje odnośnie rezerwacji, jej stan itp.
Wystarczy by chociaż jeden z węzłów uczestniczących w transmisji danych zapomniał o
rezerwacji, a cała rezerwacja przestaje przynosić oczekiwane efekty. Jeżeli jednak wszyst-
kie węzły sieci honorują komunikaty RSVP, rezerwacja działa bez zarzutu.
Narzut związany z przesyłaniem informacji kontrolnych czyni mechanizm IntServ
praktycznie bezużytecznym w przypadku transmisji unicastowych. Prawdziwie przydatny
okazuje się on w przypadku ruchu multicastowego.
Osobnym problemem pozostaje kwestia uwierzytelniania stron dokonujących rezerwa-
cji  w momencie gdy routery honorują wszystkie komunikaty RSVP bez dokonywania
żadnych sprawdzeń, złośliwy osobnik mógłby dokonać wielu rezerwacji, kradnąc zasoby
tym transmisjom, które są uprawnione do wykorzystywania tych zasobów. W [Bak00] opi-
sano rozszerzenie protokołu RSVP, które dodaje możliwość zabezpieczenia mechanizmu
rezerwacji przed niepowołanym dostępem poprzez wprowadzenie obowiązku wzajemnego
uwierzytelniania uczestniczących w dialogu RSVP stron.
5.2 DiffServ
Termin Differentiated Services tłumaczy się na język polski jako  usługi zróżnicowa-
ne  architektura DiffServ pozwala na wprowadzenie zróżnicowania w obrębie pakietów
IP. Działanie to ma na celu wyróżnienie niektórych pakietów IP i potraktowanie ich
w specjalny sposób [Bla98]. Architektura DiffServ bazuje na znakowaniu pakietów w po-
lu DSCP (ang. DiffServ Code Point) które znajduje się w nagłówku IP [Nic98].
W odróżnieniu od architektury IntServ w DiffServ nie występuje pojęcie rezerwacji.
Informacja  ta transmisja powinna być potraktowana w określony sposób transmitowa-
na jest razem z pakietem wchodzącym w skład tej transmisji. Zadaniem węzła sieci przez
który taki pakiet przechodzi jest odczytanie informacji z nagłówka, zaklasyfikowanie pa-
kietu do określonej kategorii i przesłanie dalej zgodnie z regułami obowiązującymi dla
danej kategorii.
30
5. Protokół IP
Działanie mechanizmu DiffServ w obrębie jednego węzła sieci przedstawione zostało
na rysunku 5.8.
Rysunek 5.8: Mechanizm DiffServ.
Przychodzące pakiety IP są oceniane przez klasyfikator. Na podstawie zawartości
pola DSCP pakiet zaliczany jest do odpowiedniej grupy ruchu w obrębie oferowanych
usług. W niektórych przypadkach (patrz niżej) dany węzeł sam dokonuje znakowania
pakietu zastępując poprzednią wartość pola DSCP. Liczniki pakietów oraz mechanizmy
kolejkowania służą do osiągnięcia pożądanych dla danej kategorii parametrów QoS.
Domena DiffServ
W celu przypieszenia procesu przesyłania pakietów, przy jednoczesnym zachowaniu
parametrów QoS w architekturze DiffServ wprowadzono rozdział funkcji. Wyłącznie wy-
znaczone węzły sieci dokonują znakowania pakietów. Cała reszta węzłów dokonuje jedynie
klasyfikacji bazującej na tym znakowaniu i przesyła pakiety w odpowiedni sposób. Spo-
sób przesyłania pakietów zaklasyfikowanych do danej kategorii ruchu, charakteryzujący
się użyciem określonych algorytmów określany jest skrótem PHB (ang. Per Hop Behavio-
ur, obsługa zależna od węzła sieci). Grupa routerów (na ogół pozostająca pod wspólną
kontrolą) cechująca się identycznym podejściem do kwestii mapowania wartości z pola
DSCP na odpowiednie zasady PHB nazywana jest domeną DiffServ.
31
5. Protokół IP
Rysunek 5.9: Działanie domeny DiffServ.
Ruch przychodzący z zewnątrz domeny DiffServ jest znakowany na pierwszym route-
rze należącym do domeny. Znakowanie odbywa się wg reguł ustalonych przez administra-
tora w obrębie domeny DiffServ (np.  cały ruch HTTP otrzymuje niski priorytet ) oraz
wg SLA zawartych z sąsiadującymi sieciami (np.  pakiety ICMP od dostawcy Foo Inc.
będą przesyłane z małym opóz
nieniem ). Wewnętrzne węzły sieci zajmują się wyłącz-
nie klasyfikacją pakietów wg znajdującej się w polu DSCP wartości, i na podstawie tej
klasyfikacji aplikują odpowiednie zasady PHB. Ruch generowany wewnątrz sieci można
traktować na trzy sposoby:
" pierwszy router wewnątrz domeny DiffServ, który otrzyma taki pakiet dokonuje
znakowania;
" aplikacja wysyłająca pakiet dokonuje znakowania we własnym zakresie  leży tu
pole do nadużyć, nic nie stoi na przeszkodzie by aplikacja oznaczyła generowane
przez siebie pakiety w preferencyjny sposób;
" zakładając że pola DSCP pakietów zawierają same zera, pakiety nie są traktowane
w żaden szczególny sposób.
Ruch wychodzący z domeny może zostać potraktowany na dwa sposoby:
" ostatni router domeny DiffServ dokona znakowania wg reguł ustalonych w SLA
zawartym z sąsiednią siecią;
32
5. Protokół IP
" pakiet opuści domenę z bieżącą wartością w polu DSCP, ewentualną zmianą tej
wartości zajmie się następny węzeł sieci, będący węzłem brzegowym sąsiedniej sieci.
Pole DSCP
Pole to jest odpowiednikiem pola ToS. Znajduje się w tym samym miejscu w nagłówku
IP (patrz rysunek 5), lecz jego zawartość jest interpretowana w inny sposób.
Rysunek 5.10: Budowa pola DSCP
Sześć starszych bitów określa do jakiej kategorii odpowiedniej usługi należy skierować
dany pakiet IP. Dwa skrajne prawe bity pozostają obecnie niewykorzystywane, zarezer-
wowane są do przyszłych zastosowań.
RFC definiujące architekturę DiffServ nie precyzuje dokładnego mapowania poszcze-
gólnych wartości pola DSCP na konkretne PHB. Sugerowane wartości pola DSCP można
znalez
ć w dokumentach [Dav02,Hei99] opisujących konkretne usługi funkcjonujące w ra-
mach architektury DiffServ.
Usługi DiffServ
W obrębie mechanizmu DiffServ zdefiniowano dwie usługi, dwa rodzaje PHB. Router
znacząc pakiet odpowiednią wartością w polu DSCP definiuje z której usługi powinien
skorzystać router dostarczając dany pakiet.
Przesyłanie gwarantowane (ang. Assured Forwarding)
Usługa przesyłania gwarantowanego zdefiniowana w [Hei99] jest luz
nym odpowied-
nikiem usługi gwarantowanej występującej w modelu IntServ. Transmisje korzystające
z tej usługi otrzymują gwarancję określonej przepustowości łącza. Usługa AF dzieli się
na cztery ponumerowane klasy. Każdej klasie przypisana jest pewna część przepustowości
dostępnej w obrębie danego węzła sieci. W obrębie każdej klasy wyróżnia się trzy pozio-
my prawdopodobieństwa odrzucenia pakietu, w momencie gdy w danej klasie wystąpi
zator. Daje to tym samym dwanaście poziomów usługi AF, oznaczanych w sposób AF xy
gdzie x jest numerem klasy, a y poziomem odrzucenia (wyższa liczba symbolizuje większe
prawdopodobieństwo tego, że pakiet zostanie odrzucony).
33
5. Protokół IP
Rysunek 5.11: Przykładowy podział przepustowości pomiędzy klasy usługi AF
Sposób podziału dostępnej przepustowości pomiędzy poszczególne klasy jest jednoli-
ty w obrębie danej domeny DiffServ, i zależy od konfiguracji routerów dokonanej przez
administratora. Sugerowane jest jednak, by klasa AF1 dysponowała największym przy-
działem, a klasa AF4  najmniejszym.
W momencie gdy transmisje w obrębie danej klasy nie wykorzystują całości przy-
dzielonego łącza, możliwe jest  pożyczenie niewykorzystanej części na rzecz innej klasy.
W momencie gdy w obrębie danej klasy jest więcej ruchu niż wynikałoby to z przydzia-
łu, węzeł sieci zobowiązany jest do odrzucenia części pakietów. Pakiety do odrzucenia
dobierane są wg poziomu prawdopodobieństwa wynikającego z wartości pola DSCP.
RFC proponuje przypisanie następujących wartości poszczególnym klasom AFxy:
Klasa 1 Klasa 2 Klasa 3 Klasa 4
niskie prawdopodobieństwo odrzucenia 001010 010010 011010 100010
średnie prawdopodobieństwo odrzucenia 001100 010100 011100 100100
wysokie prawdopodobieństwo odrzucenia 001110 010110 011110 100110
Jak widać, pierwsze trzy bity określają klasę ruchu, natomiast kolejne trzy  prawdo-
podobieństwo odrzucenia.
Oprócz gwarancji określonej części przepustowości, poszczególne klasy uzyskują rów-
nież rezerwację części bufora wyłącznie na pakiety znajdujące się w danej klasie. Pakiety
należące do tej samej klasy nie są poddawane sortowaniu w obrębie przydzielonej im
części bufora.
Usługę przesyłania gwarantowanego implementuje się na ogół za pomocą mechanizmu
kolejek klasowych (patrz 7.4) w połączeniu z algorytmem TBF (7.3).
Przesyłanie przyspieszone (ang. Expedited Forwarding)
Zadaniem usługi przesyłania przyspieszonego jest utrzymanie na niskim poziomie
opóz
nienia i niejednorodności transmisji oraz zapewnienie niskiej utraty pakietów. Im-
plementacyjnie sprowadza się to do prostej zasady: prędkość z jaką pakiety korzystające
34
5. Protokół IP
z tej usługi opuszczają węzeł sieci nie może być mniejsza niż prędkość z jaką pakiety
do danego węzła wchodzą. Oczywiście ślepe trzymanie się tej zasady może spowodować
zapchanie łączy pojedynczą, bardzo szybką transmisją. Jako iż przekazanie informacji
o pożądanej prędkości nie jest możliwe za pomocą sześciu bitów pola DSCP, każdy węzeł
w domenie DiffServ powinien ograniczać z góry prędkość tej usługi do ustalonej przez
administratora wartości. Dodatkowo transmisja może być spowalniana w momencie wej-
ścia do domeny DiffServ poprzez mechanizmy ograniczania przepustowości działające na
routerze brzegowym.
Zakładając identyczne działanie tej usługi w obrębie całej domeny DiffServ możliwe
jest osiągnięcie swoistego  wirtualnego połączenia pomiędzy dwoma punktami domeny.
Jeżeli punkty początkowy i końcowy transmisji lezą poza granicami domeny DiffServ,
gwarancję  przyspieszenia uzyskujemy tylko w obrębie domeny. Rozszerzenie gwarancji
poza granicę domeny mogą nam zapewnić odpowiednie SLA zawarte z przylegającymi
sieciami.
Proponowana wartość DSCP oznaczająca usługę przesyłania przyspieszonego to
101110. Najczęstszy mechanizm stosowany do zaimplementowania tej usługi to kolejki
priorytetowe (7.1).
Wady i zalety
Mechanizm DiffServ wyśmienicie nadaje się do zapewniania parametrów QoS ruchowi
unicastowemu. Umiejscowienie informacji kontrolnych w obrębie samej transmisji oznacza
brak narzutu związanego z sygnalizacją QoS . Węzły sieci nie muszą kontrolować bieżą-
cego stanu transmisji  do odczytania PHB wystarczy analiza nagłówków pakietów IP,
która i tak jest wykonywana podczas normalnego routowania. Dodatkowo fakt iż jeden
z węzłów ignoruje informacje zawarte w polu DSCP nie oznacza od razu klęski całego
mechanizmu QoS . Parametry transmisji mogą ulec pogorszeniu (zwłaszcza w przypadku
usługi przesyłania przyspieszonego), ale na całej reszcie trasy pakiety traktowane będą
zgodnie z deklaracją zawartą w nagłówku. Ta cecha ułatwia implementację architektury
DiffServ w istniejących instalacjach sieciowych  urządzenia oraz oprogramowanie wyko-
rzystujące pole DSCP mogą być wprowadzane stopniowo.
Ceną jaką przychodzi zapłacić za taką elastyczność mechanizmu DiffServ jest jego
słaba rozdzielczość. O ile w przypadku IntServ węzeł sieci zajmował się pojedynczymi
transmisjami, o tyle w przypadku DiffServa węzeł zajmuje się grupami pakietów przyna-
leżącymi do określonej klasy lub usługi. Oznacza to, że dany PHB dotyczyć może wielu
jednocześnie występujących transmisji. Gwarancja parametrów QoS nie jest w przypadku
DiffServa tak silna jak w przypadku IntServa, ponieważ praktycznie gwarancje udzielane
są nie pojedynczym transmisjom a ich agregatom. Doświadczenie jednak pokazuje, że
w przypadku ruchu unicastowego jest to i tak dobre rozwiązanie.
35
5. Protokół IP
Z racji znakowania pakietów na granicy domeny niebezpieczeństwo wystąpienia nad-
użyć jest tutaj znacznie mniejsze  nawet jeżeli aplikacja zażąda nadmiarowych zasobów
to zostanie to zweryfikowane w momencie wejścia do domeny. Z drugiej strony brak moż-
liwości dokonania dynamicznych rezerwacji ( ta transmisja wymaga przynajmniej 23kbps
oraz opóz
nienia nie większego niż 30ms ) może być problemem. DiffServ wymaga wcze-
śniejszej sztywnej konfiguracji (przydziału zasobów do klas AF, określenia maksymalnej
prędkości dla przesyłania przyspieszonego, itd.) [Bla98, Hei99, Dav02].
Znakowanie występujące w architekturze DiffServ może sprawiać kłopoty w przy-
padku tunelowania ruchu IP, w momencie gdy koniec tunelu nie znajduje się na routerze
brzegowym, dokonującym znakowania. Wychodzący z tunelu pakiet IP nie zostanie ozna-
czony właściwą wartością DSCP. Routery wewnątrz sieci będą kolejkowały ten pakiet wg
starej wartości pola DSCP. Jeżeli koniec tunelu umieszczony zostanie na routerze doko-
nującym znakowania, pakiet zostanie poprawnie oznaczony.
36
ROZDZIAA
6
Protokoły warstwy II
Pomimo iż większość logiki QoS zlokalizowana jest w obrębie warstwy III sieciowe-
go modelu OSI, niektóre techniki warstwy II również oferują mechanizmy QoS. Część
z nich można spożytkować w połączeniu z mechanizmami warstwy III, część z nich po-
trafi działać niezależnie od warstw wyższych. Z jednej strony tego typu  ułatwienia
(np. sieć podkładowa ATM oferująca zróżnicowane w sensie parametrów QoS usługi) są
pomocne w osiągnięciu sprawnej architektury QoS . Architektury DiffServ i IntServ mo-
gą korzystać z oferowanych przez warstwę II mechanizmów do zapewnienia poprawnego
funkcjonowania własnych usług. Z drugiej jednak strony, chcąc otrzymać gwarancję jako-
ści usług w dowolnej sieci IP, nie można opierać jej na obecności określonego mechanizmu
w warstwie niższej. Dodatkowo, często do podjęcia właściwych i przynoszących wymierne
efekty decyzji i tak wymagana jest wiedza z warstw wyższych (nagłówki IP, lub też nawet
protokołu transportowego czy też aplikacji), do których urządzenia warstwy II co prawda
mają dostęp, lecz z racji zachowania odpowiedniej szybkości przetwarzania danych, nie
powinny ich analizować.
Na przestrzeni lat, podczas opracowywania różnych technik sieciowych w różny sposób
podchodzono do kwestii jakości usług sieciowych. Poniżej przedstawiono trzy techniki
które z powodzeniem wykorzystywane są do wspomagania działania mechanizmu QoS.
Pierwsza z nich dotyczy sieci lokalnych, dwie pozostałe: sieci rozległych.
6.1 Sieci lokalne  802.1p
802.1p jest standardem odnoszącym się do sieci Ethernet, powszechnie spotykanych
w roli sieci lokalnych lub małych sieci metropolitalnych. Jego działanie sprowadza się
37
6. Protokoły warstwy II
do stworzenia systemu priorytetów w obrębie ruchu ethernetowego. Pojedyncza ramka
klasyfikowana jest do jednej z ośmiu klas ważności. W ramach ramki ethernetowej wpro-
wadzane jest dodatkowe pole, służące za swojego rodzaju etykietę. Czterobajtowa ety-
kieta umiejscawiana jest pomiędzy adresem odbiorcy a polem określającym typ danych
zawartych w ramce.
Rysunek 6.1: Umiejscowienie etykiety 802.1p/q w nagłówku ramki ethernetowej.
Sama etykieta wykorzystywana jest nie tylko do celów QoS , na przykład standard
802.1q umieszcza w niej informacje określające przynależność ramki ethernetowej do okre-
ślonego VLANu. W obrębie etykiety, standardowi 802.1p poświęcone są 3 bity, określające
priorytet ramki  od 0 do 7, przy czym 7 określa priorytet największy, a 0  najmniejszy.
Z systemu priorytetów mogą korzystać przełączniki (ang. switch) oraz koncentrato-
ry (ang. hub) przez które przechodzi oznakowany w ten sposób ruch. Opis standardu
802.1p nie definiuje sposobu reakcji na poszczególne priorytety. Najczęściej spotykanym
zachowaniem jest preferencyjne traktowanie ramek (ramki z wyższym priorytetem prze-
syłane są w pierwszej kolejności) oraz adekwatny do priorytetu poziom odrzucania ramek
w momencie wystąpienia zatoru.
Tego typu znakowanie nie pozwala na przekazanie bardziej skomplikowanych żądań
QoS , sugerowane jest więc, by priorytet ramki określany był przez urządzenie warstwy
III (router) na podstawie osobnych kryteriów (informacje uzyskane za pomocą RSVP,
pole DSCP, inne).
6.2 ATM
ATM jest standardem opracowanym początkowo jako fragment specyfikacji B-ISDN.
Opisuje on nie tyle nowy rodzaj medium transmisyjnego, co sposób komunikacji w sieci.
Dane przesyłane są w postaci jednakowych co do wielkości komórkach, o wielkości 53 bajty
(z czego na dane przeznaczono 48 bajty). ATM działać może w oparciu o różne media
transportowe (skrętkę, światłowód, kabel koncentryczny, radio), pełniąc rozmaite role
38
6. Protokoły warstwy II
(sieć lokalna, szkieletowa, rozległa). Najczęściej ATM wykorzystywany jest jako szkielet
sieci rozległych, pełniąc rolę podkładową pod sieć IP.
Dokładny opis sieci ATM wykracza poza zakres niniejszej pracy (można znalez
ć go np.
w [ATM03]). Warto jednak przyjrzeć się dokładniej sposobowi transmisji danych w sieci
ATM, z racji na zastosowane tam mechanizmy QoS . Pomiędzy poszczególnymi węzłami
sieci tworzone są wirtualne kanały (ang. Virtual Channels) grupowane w ścieżki (ang. Vir-
tual Paths). Pojedynczemu kanałowi lub ścieżce można przypisać jedną z następujących
usług:
" CBR (ang. Constant Bit Rate)
Usługa charakteryzuje się utrzymaniem stałego, określonego poziomu prędkości
transferu.
" VBR (ang. Variable Bit Rate)
Usługa dla transmisji o zmiennym tempie transmisji, gwarantująca utrzymaniem
prędkości transferu w określonych granicach. Występuje w dwóch odmianach,
rtVBR (ang. real-time) oraz nrtVBR (ang. non real-time) różniących się gwa-
rancjami w zakresie dopuszczalnego opóz
nienia (transmisje czasu rzeczywistego)
 występuje ona tylko dla usługi rtVBR.
" ABR (ang. Available Bit Rate) oraz UBR (ang. Unspecified Bit Rate)
Usługi te wykorzystują zasoby które pozostały po rozdysponowaniu pomiędzy usłu-
gi VBR i CBR. Sieć nie daje żadnych gwarancji ilościowych transmisjom korzysta-
jącym z usługi UBR, komórki tych transmisji podczas przeciążenia zostaną od-
rzucone. Transmisje ABR mają dysponują gwarancją minimalnej przepustowości.
Dodatkowo, nadajnik transmisji ABR jest informowany o przeciążeniach w sieci
tak, by mógł zmodyfikować ilość generowanego ruchu.
Rysunek 6.2: Podział pasma pomiędzy usługi sieci ATM.
39
6. Protokoły warstwy II
Oprócz tego, sieć ATM wyposażona jest w mechanizmy kontroli dostępu do sieci (ang.
Connection Admission Control) oraz mechanizmy sygnalizacji zatorów. Powoduje to, iż
bardzo często węzły sieci korzystające z sieci ATM jako mechanizmu transferu pakietów
IP dokonują bezpośredniego mapowania mechanizmów QoS warstwy III na odpowiednie
usługi sieci ATM (patrz 8.1) [Cis02a].
6.3 FrameRelay
FrameRelay jest kolejną, dość już wiekową propozycją w dziedzinie sieci rozległych.
Podobnie jak ATM jest protokołem transportowym pracującym w trybie pakietowym,
funkcjonującym w I i II warstwie modelu OSI. Transmisja pomiędzy dwoma węzłami
sieci FrameRelay odbywa się w ramach tworzonego statycznie (PVC, ang. Permanent
Virtual Circuit) lub dynamicznie (SVC, ang. Switched Virtual Circuit) obwodu wirtu-
alnego łączącego nadajnik z odbiornikiem [FRF02]. Dla każdego takiego obwodu węzły
sieci mogą wynegocjować dwa parametry: CIR (ang. Commited Information Rate), czyli
przepustowość gwarantowaną oraz EIR (ang. Excess Information Rate)  maksymalną
dostępną dla danego obwodu przepustowość. Dodatkowo każdy z obwodów może zostać
zaklasyfikowany do odpowiedniej kategorii ruchu:
" rtVFR (ang. real-time Variable Frame Rate)
Ruch tego typu oprócz gwarantowanej przepustowości otrzymuje również gwarancję
niewielkiego opóz
nienia oraz małej utraty pakietów.
" nrtVFR (ang. non real-time Variable Frame Rate)
Ta kategoria ruchu posiada tylko gwarancję przepustowości.
" AFR (ang. Available Frame Rate)
Ruch w tej kategorii korzysta z dostępnych zasobów sieciowych nieprzydzielonych
transmisjom z innej kategorii.
Sieć FrameRelay posiada również dwustronny mechanizm powiadamiania o wystąpie-
niu zatoru  obydwie strony biorące udział w transmisji otrzymują informację o poten-
cjalnych problemach. Funkcjonalnie zbliżona nieco do sieci ATM, sieć FrameRelay powoli
traci na znaczeniu, właśnie na rzecz sieci ATM. Istniejące instalacje mogą być jednak
z powodzeniem wykorzystywane jako sieci podkładowe zapewniające QoS [FRF02].
40
Część III
Implementacje QoS
41
ROZDZIAA
7
Stosowane algorytmy
W przedstawionym dotychczas w pracy obrazie QoS brakuje jednego elementu. Żad-
na z proponowanych architektur nie zajmuje się niskopoziomowymi mechanizmami które
należy zastosować by osiągnąć pożądane parametry transmisji. Zarówno IntServ jak i Diff-
Serv precyzują raczej w jaki sposób należy propagować w sieci informacje o rezerwacjach
QoS oraz jak powinny zachowywać się węzły sieci w określonych sytuacjach (np. domyśl-
ne zachowania, co robić w przypadku braku informacji odnośnie rezerwacji, jak reagować
na przeciążenia itp.).
Rysunek 7.1: Problem stawiany przed węzłami sieci.
Węzeł sieci uczestniczący w strukturach QoS staje przed następującym proble-
mem: w jaki sposób, dysponując zamówieniami na parametry transmisji, powinien za-
rządzać ruchem by owe zamówienia zrealizować? Odpowiedzią na to pytanie są niskopo-
ziomowe algorytmy leżące u podstaw architektury QoS. Typowe działanie węzła sieci to
42
7. Stosowane algorytmy
odczytanie informacji odnośnie QoS z odpowiednich struktur kontrolnych (RSVP, po-
le DSCP, itp.) a następnie wykorzystanie dostępnych mechanizmów niskiego poziomu,
po uprzednim wyliczeniu niezbędnych dla nich parametrów. Znacząca większość owych
algorytmów odnosi się do sposobu zarządzania buforem w którym przebywają pakiety
IP składające się na przechodzące przez węzeł transmisje. Poszczególne rodziny algoryt-
mów odpowiadają na ogół określonym zadaniom stawianym przed mechanizmami QoS
 np. algorytm  wiadra z żetonami stosowany jest do ograniczania zużywanego przez
transmisję pasma, natomiast kolejkowanie  sprawiedliwe  do podziału dostępnego pa-
sma pomiędzy określone grupy transmisji. Algorytmy można modyfikować oraz łączyć ze
sobą w celu osiągnięcia pożądanego celu.
Jako iż temat QoS pozostaje w centrum uwagi wielu firm, naukowców, oraz specja-
listów z dziedziny sieci komputerowych, cały czas proponowane są nowe rozwiązania.
Poniżej omówione zostały najczęściej stosowane niskopoziomowe mechanizmy QoS .
7.1 FIFO
Kolejka FIFO jest najbardziej podstawowym mechanizmem zarządzania buforem, jaki
spotkać można w popularnych urządzeniach sieciowych. Angielski skrót FIFO rozwijany
jest następująco: First In, First Out. Na język polski przekłada się to jako  pierwszy
wszedł, pierwszy wychodzi . Sformułowanie to określa w jaki sposób działa kolejka FIFO
 pakiety IP opuszczają kolejkę dokładnie w takiej kolejności w jakiej do niej weszły.
W trakcie przebywania pakietów wewnątrz bufora nie jest dokonywana żadna reorgani-
zacja bufora.
Rysunek 7.2: Kolejka FIFO.
Pakiety oznaczone tym samym znakiem należą do jednej transmisji.
Tego typu schemat kolejkowania pakietów jest niedopuszczalny z punktu widzenia
QoS . Długość bufora jest ograniczona i ustalona z góry  w momencie gdy jest on zapeł-
niony pakietami, każdy nowy przychodzący pakiet zostanie odrzucony, niezależnie od tego
do jakiej transmisji należy. Brak możliwości przeszeregowania zawartości bufora odbiera
możliwość preferencyjnego potraktowania określonych pakietów.
43
7. Stosowane algorytmy
Rysunek 7.3: Przykład odrzucenia pakietu w kolejce FIFO.
Nadchodzący pakiet zostaje odrzucony, niezależnie od swojego priorytetu.
Kolejka FIFO nie posiada możliwości modyfikacji swojego zachowania. Tym samym,
nie nadaje się jako algorytm kolejkowania w przypadku węzła sieci uczestniczącego w QoS
 może dojść do niekontrolowanego gubienia pakietów, a co za tym idzie  niezamierzo-
nego pogorszenia parametrów transmisji.
Koncepcja FIFO sprawdza się jednak w momencie wprowadzenia do schematu dzia-
łania modyfikacji.
Rysunek 7.4: pFIFO  kolejka FIFO uwzględniająca priorytety
44
7. Stosowane algorytmy
W obrębie bufora wyróżniono 3 poziomy uprzywilejowania. Z każdym z nich związana
jest osobna kolejka FIFO. Bufor opuszczają najpierw pakiety z kolejki o największym
priorytecie (prio1). Dopiero w momencie gdy prio1 jest pusta, brane pod uwagę są pakiety
z kolejki prio2. Analogiczne zachowanie tyczy się kolejki prio3. Przydział pakietów do
poszczególnych kolejek może odbywać się na podstawie dowolnych informacji QoS (np.
wartość pola ToS, DSCP, itp.). Tego typu kolejka określana jest mianem pFIFO (ang.
prioritized FIFO)  kolejka FIFO z systemem priorytetów.
Mimo iż kolejka pFIFO jest istotnym ulepszeniem zwykłego mechanizmu FIFO, nie
rozwiązuje ona jednak wszystkich problemów. W sytuacji ekstremalnego przeciążenia
wszystkie kolejki priorytetowe mogą ulec przepełnieniu. Dodatkowo przy odpowiednio
dużej ilości pakietów w ważniejszych kolejkach może dojść do  zagłodzenia kolejek
o niższych priorytetach. Kumulujące się w nich w takiej sytuacji pakiety doprowadzą
do przepełnienia. Z drugiej strony, priorytety pozwalają na wymuszenie bezwzględne-
go pierwszeństwa określonych pakietów, co pozwala na zagwarantowanie niskiego czasu
przesyłania pakietu.
7.2 Kolejki  sprawiedliwe
W przypadku współdzielenia jednego łącza przez kilku użytkowników zachodzi często
sytuacja w której dostępne zasoby sieciowe mają zostać sprawiedliwie rozdzielone pomię-
dzy wszystkie transmisje. Stosowane w tym celu kolejki  sprawiedliwe próbują rozwiązać
ten problem w następujący sposób:
1. Występujący w obrębie węzła ruch grupowany jest w agregaty. Grupowanie może
być dokonywane wg różnych kryteriów, np:
" pakiety z tym samym adresem z
ródłowym (wg nadawcy);
" pakiety z tym samym adresem docelowym (wg odbiorcy);
" pakiety z tym samym adresem z
ródłowym, docelowym, numerem protokołu
transportowego oraz (opcjonalnie) numerem portu (wg transmisji);
2. Powstałe w ten sposób agregaty obsługiwane są w sposób cykliczny (ang. round-
robin), tak aby pakiety z każdego agregatu miały jednakową szansę opuszczenia
bufora.
Bardzo często kolejką obsługującą pojedynczy agregat bywa zwykła kolejka FIFO.
Słowo  sprawiedliwe zapisane jest w cudzysłowie, ponieważ  sprawiedliwość zależy
od zasad grupowania pakietów w agregaty. Pierwszy sposób grupowania zapewni każdemu
nadawcy równą ilość zasobów sieciowych, drugi natomiast  każdemu odbiorcy. Trzeci
45
7. Stosowane algorytmy
rodzaj grupowania ma za zadanie podzielić dostępne zasoby po równo pomiędzy wszystkie
występujące w obrębie węzła transmisje.
Rysunek 7.5: Przykładowa kolejka  sprawiedliwa .
Niektóre implementacje zezwalają na przypisanie liczbowych wag do poszczególnych
agregatów. W takim wypadku, agregaty dalej są obsługiwane w sposób cykliczny, lecz
agregaty o większej wadze są obsługiwane częściej. Pozwala to na osiągnięcie  orwel-
lowskiej sprawiedliwości, działającej na zasadzie  wszystkie transmisje są równe, ale
niektóre są równiejsze od innych . Kolejki  sprawiedliwe występują w literaturze jako
rodzina kolejek FQ (ang. Fair Queueing) [Cis02b, Max02].
Uzyskiwana za pomocą kolejek  sprawiedliwych gwarancja równego podziału zaso-
bów nie jest jednak doskonała. Jeżeli jeden z agregatów zawierać będzie znacząco dłuższe
pakiety IP, czas jego obsługi zwiększy się. Spowoduje to zwiększenie opóz
nień w dostawie
pakietów należących do innych agregatów.
7.3 Ograniczanie przepustowości
W dość częstych przypadkach zachodzi potrzeba spowolnienia transmisji dokonywanej
poprzez węzeł. Formalnym celem takiego zabiegu jest to, by pakiety opuszczały router
z prędkością nie większą niż z góry ustalona wartość. Pakiety IP nadchodzą do węzła
nieregularnie, czasami wolniej niż jest to wymagane, czasami szybciej. Dobrym sposobem
na uregulowanie transmisji jest zastosowanie modelu  wiadra z żetonami (TBF ang.
Token Bucket Filter)
46
7. Stosowane algorytmy
Rysunek 7.6: Wiadro z żetonami.
W powyższym modelu wiadro symbolizuje bufor. Do wiadra wchodzą zarówno pakiety
IP, jak i żetony, których produkcja jest całkowicie kontrolowana przez stosujący ten model
węzeł sieci. Żetony wykorzystywane są w następujący sposób:
" Każdy opuszczający bufor pakiet IP  zużywa jeden żeton.
" Jeżeli w wiadrze brakuje żetonów, pakiety są buforowane do czasu pojawienia się
pierwszego żetonu.
" Jeżeli w wiadrze występuje nadwyżka żetonów, pakiety mogą1 przez chwilę opusz-
czać wiadro nieco szybciej niż wynika to z ograniczenia, korzystając z chwilowego
nadmiaru żetonów. Nadwyżka może zostać wykorzystana na dwa sposoby:
natychmiastowo, tzn. w ramach wykorzystywania nadwyżki pakiety będą wy-
puszczane tak szybko jak to jest możliwe;
stopniowo, tzn. pakiety będą wypuszczane szybciej niż w przypadku normal-
nego działania, ale nie szybciej niż z góry określona wartość.
" Żetony produkowane są w określonym (najczęściej stałym) tempie przez dany węzeł
sieci.
1
Aczkolwiek jest to zależne od konkretnej implementacji oraz konfiguracji.
47
7. Stosowane algorytmy
Wiadro (bufor) posiada stałą, określoną z góry wielkość. W momencie gdy przy-
chodzące pakiety przepełniają bufor, nadwyżka jest albo odrzucana, albo kolejkowana
poza wiadrem w zwykłej kolejce FIFO. Dodatkowymi parametrami wiadra jest określo-
na prędkość produkcji nowych żetonów oraz dopuszczalne  przyspieszenie w przypadku
nadwyżki żetonów [Max02].
Model w którym nadprodukcja żetonów nie jest magazynowana nie pozwala na zaist-
nienie sytuacji w której pakiety IP opuszczają wiadro w tempie większym niż produkcja
żetonów. Tego typu model nazywany jest  cieknącym wiadrem (ang. leaky bucket). Spo-
tykane są implementacje zawierające dwa wiadra; ruch wchodzący do bufora kierowany
jest do cieknącego wiadra, z którego kierowany jest do wiadra z żetonami. Tego typu stra-
tegia ma za zadanie wyrównać potencjalnie nierównomierny napływ danych do wiadra
z żetonami [Max02].
7.4 Kolejki klasowe
Kolejki klasowe są jednym z bardziej złożonych mechanizmów kolejkowania. Wyko-
rzystując pomysły występujące w do tej pory omówionych mechanizmach pozwalają na
zapewnienie określonego podziału zasobów sieciowych pomiędzy zdefiniowane klasy ru-
chu. Zasada działania mechanizmu kolejek klasowych jest następująca:
1. Występujący w obrębie węzła ruch grupowany jest w klasy ruchu. Grupowanie może
być dokonywane wg rozmaitych kryteriów  począwszy od informacji pochodzących
z samych pakietów (adres nadawcy lub odbiorcy, pole DSCP), skończywszy na
informacjach zewnętrznych (np. rezerwacja RSVP).
2. Powstałe w ten sposób agregaty traktowane są w specjalny, zależny od rodzaju
kolejki klasowej sposób. Przykładowo, poszczególne klasy mogą być obsługiwane
w sposób cykliczny. Na ogół poszczególnym klasom zapewniane są określone frag-
menty przepustowości jaką dysponuje router. Nie jest to jednak jedyna możliwość.
Do zapewnienia danemu agregatowi określonej przepustowości najczęściej stosowa-
na jest kolejka TBF. W bardziej zaawansowanych aplikacjach możliwe jest zastąpienie
domyślnej kolejki TBF inną kolejką (np. kolejką sprawiedliwą). Możliwe jest też umiesz-
czenie w miejscu TBF kolejnej kolejki klasowej, dzięki czemu można uzyskać swoiste
drzewo kolejek zachowujące się w określony sposób.
Z klasami może zostać związany priorytet. Klasy z wyższym priorytetem obsługiwa-
ne będą jako pierwsze, przy zachowaniu jednak gwarancji minimalnej przepustowości.
Dokładne zachowanie zależy od konkretnej implementacji.
W najczęściej spotykanym przypadku klasy współdzielą między sobą nieużywane zaso-
by. Oznacza to, że jeżeli któraś z klas nie wykorzystuje w pełni przydzielonej jej zasobów,
48
7. Stosowane algorytmy
nieużywana nadwyżka zostaje rozdzielona pomiędzy resztę klas (równomiernie albo pro-
porcjonalnie do priorytetów klas). W bardziej zaawansowanych implementacjach istnieje
możliwość określenia które dokładnie klasy mają prawo pożyczania niewykorzystywanych
zasobów oraz które klasy mogą udzielać pożyczek innym klasom.
Innym przykładem kolejki klasowej może być kolejka PRIO będąca funkcjonalnym
odpowiednikiem kolejki pFIFO. Podobnie jak pFIFO, mechanizm PRIO priorytetyzuje
ruch, z tą jednak różnicą że:
" klasyfikacja może zachodzić na podstawie większej ilości parametrów;
" proste kolejki FIFO składające się na kolejkę PRIO mogą zostać zastąpione bardziej
skomplikowanymi kolejkami.
Przykładowe zastosowanie kolejki klasowej przedstawione zostało na rysunku 7.7.
Rysunek 7.7: Przykładowe drzewo kolejek klasowych
W powyższym przykładzie kolejka klasowa HTB (ang. Hierarchical Token Bucket)
dzieli dostępną w obrębie węzła przepustowość na cztery równe klasy. Dla ustalenia uwa-
gi załóżmy że klasyfikacja dokonywana jest na podstawie adresu nadawcy. Oznacza to,
że każdemu z czterech nadawców przydzielone zostało 25% dostępnej przepustowości
łącza. W obrębie jednej klasy ruch zarządzany jest przez kolejkę PRIO  wyższy priory-
tet zyskują pakiety usług interaktywnych (telnet, ssh), obsługiwane przez prostą kolejkę
49
7. Stosowane algorytmy
FIFO. Cała reszta pakietów, obarczona niższym priorytetem, trafia do kolejki sprawiedli-
wej, która ma za zadanie wprowadzić równy podział dostępnej przepustowości pomiędzy
wszystkie występujące w tej klasie transmisje [Max02].
7.5 Unikanie zatorów
Wymienione powyżej mechanizmy opisują w jaki sposób węzeł sieci może reagować
na pojawiające się w sieci przeciążenia. W przypadku gdy ruch w sieci utrzymuje się na
niższym poziomie router może działać zapobiegawczo, w celu wykluczenia możliwości wy-
stąpienia zatoru. W tym celu okresowo z kolejki usuwane są wybrane pakiety IP. Rodzina
tego typu mechanizmów określana jest skrótem RED (ang. Random Early Detection).
Rysunek 7.8: Działanie mechanizmu unikania zatorów.
Jeżeli bufor uległby całkowitemu zapełnieniu gubione byłyby wszystkie nowe pakiety
starające się wejść do pełnego bufora. W momencie stosowania algorytmu RED szansa
na całkowite zapełnienie bufora znacznie się zmniejsza. Dodatkowo węzeł zyskuje pełną
kontrolę nad tym, które pakiety usuwane są z bufora.
Celowe zgubienie pakietu wymusza oczywiście na nadajniku jego retransmisję. Wy-
dawałoby się więc, że przyczynia się to do wzrostu ilości ruchu w obrębie sieci. Jednak
nadajnik może kontrolować ilość wysyłanych oraz odbieranych pakietów i adekwatnie do
ich stosunku modyfikować parametry generowanego ruchu. Przykładem tego typu dzia-
łań może być protokół TCP, który w momencie stwierdzenia utraty pakietów spowalnia
dalszą transmisję.
Poszczególne algorytmy różnią się między sobą sposobem analizy sytuacji panującej
w buforze oraz kryteriami doboru pakietów które mają zostać odrzucone. Najczęściej
spotykane działania to:
" Analiza stopnia zapełnienia bufora bufora  w momencie gdy przekroczy ono pewną
określoną z góry wartość (np. 85%), z bufora usuwane są pakiety. Usuwane pakiety
mogą zostać wybrane [Max02, Cis02a]:
50
7. Stosowane algorytmy
spomiędzy pakietów najliczniej obecnych w kolejce transmisji  tak aby spo-
wolnić tę transmisję która zużywa najwięcej zasobów;
spomiędzy pakietów o największym rozmiarze  by zwiększyć jednorodność
pakietów w kolejce;
spomiędzy pakietów sfragmentowanych  istnieje prawdopodobieństwo że
w przypadku wystąpienia przeciążenia reszta fragmentów nie dotrze na miej-
sce, bezcelowym więc jest przesyłanie obecnego fragmentu;
losowo.
" Analiza  per transmisja  w kolejce wyróżniane są pojedyncze transmisje, z naj-
dłuższej usuwane są pakiety.
" Usuwanie pakietów na podstawie informacji o QoS otrzymanych w wyniku działania
innych mechanizmów, np. RSVP, lub statyczna konfiguracja. Tego typu mechanizm
nazywany jest WRED (ang. Weighted RED. Bardzo często jako kryterium odrzu-
cania występuje klasa usługi AF w architekturze DiffServ [Hei99]  wyższa klasa
oznacza mniejsze prawdopodobieństwo odrzucenia.
" Analiza stopnia obciążenia łącza  jeżeli łącze jest aktywne przez zbyt długi czas,
z bufora usuwane są pakiety. Jest to nowe podejście w temacie unikania zatorów,
prekursorem tego typu analizy jest algorytm BLUE.
Proste mechanizmy unikania zatorów znajdują swoje zastosowanie w węzłach należą-
cych do szkieletu sieci. Przy dużej ilości ruchu, jego analiza staje się zbyt czasochłonna.
Zastosowanie mechanizmu RED bazującego na stopniu zapełnienia bufora pozwala roz-
ładować obciążenie i poprawić wydajność działania węzła.
7.6 Wydajność łącza
Niezależnie od stosowanego algorytmu kolejkowania węzeł sieci powinien uczynić
wszystko co leży w jego mocy by dostępne mu zasoby sieciowe wykorzystywane były
w sposób jak najbardziej efektywny. W tym celu router może stosować rozmaite techniki
dodatkowe.
Fragmentacja pakietów
Często wprowadzaną strategią  sprawiedliwą w obrębie pojedyńczego interfejsu jest
kolejkowanie na zasadzie  każdej transmisji po równo  router dba o to, by na zmianę
wypuszczać pakiety poszczególnych transmisji. W sytuacji w której pakiety tych transmi-
sji drastycznie różnią się rozmiarami (np. duże pakiety transmisji FTP oraz małe pakiety
51
7. Stosowane algorytmy
sesji ssh) sprawiedliwy przydział nie zostanie osiągnięty  transmisja pakietu FTP zaj-
mie więcej czasu niż transmisja pakietu ssh. Rozwiązaniem jest dokonanie fragmentacji
dużych pakietów tuż przed umieszczeniem ich w buforze. W ten sposób rozkład  masy
będzie bardziej jednorodny, co znacząco ułatwi osiągnięcie założonej sprawiedliwości.
Rysunek 7.9: Przykład fragmentacji pakietów
Fragmentacja jednak nie jest rozwiązaniem idealnym, sfragmentowane pakiety IP
sprawiają kłopoty w momencie ich analizy przez firewalle. Dodatkowo, różne implemen-
tacje stosu TCP/IP obfitowały w rozmaite błędy dotyczące fragmentowania pakietów
IP [Max02]. Z tego powodu pakiety nie powinny być fragmentowane bez wyraz
nej po-
trzeby.
Kompresja pakietów
W przypadku niektórych protokołów warstwy aplikacji, dysproporcja pomiędzy na-
główkiem niosącym informacje kontrolne a ilością faktycznie przenoszonych danych jest
stosunkowo duża. Korzystnym działaniem w takiej sytuacji jest kompresja obszernych
części pakietów. Platforma Cisco IOS oferuje tego typu możliwość dla protokołu RTP
(ang. Realtime Transport Protocol) [Sch96] przenoszącego głównie dane multimedialne
(obraz, dz
więk). W przypadku RTP rozmiar nagłówka to 40 bajtów, natomiast wielkość
przenoszonych danych waha się w przedziale od 20 do 150 bajtów. Routery Cisco umoż-
liwiają kompresję nagłówka z 40 do 2-5 bajtów. Tego typu operacja dokonywana jest na
pierwszym routerze występującym za nadajnikiem. Dekompresji dokonuje ostatni router,
52
7. Stosowane algorytmy
odbierający dane tuż przed odbiorcą. W ten sposób modyfikowany ruch określany jest
mianem cRTP (compressed RTP) [Cis02b].
Pomimo sporego zysku objętościowego podejście tego typu posiada zasadniczą wadę.
Kompresja i dekompresja nagłówków wymagają od routera poświęcenia pewnej części
mocy obliczeniowej, co może zaowocować spadkiem wydajności w przekazywaniu innego
ruchu [QoS99].
53
ROZDZIAA
8
Przegląd możliwości wybranych systemów operacyjnych
Tematyka QoS jest ostatnio bardzo popularna. Szeroka gama istniejących mechani-
zmów kolejkowania oraz dystrybucji informacji QoS nie powstrzymuje bynajmniej spe-
cjalistów od ciągłego opracowywania nowych technik z tego zakresu. Coraz częściej też
QoS bywa implementowany w różnego rodzaju urządzeniach sieciowych oraz oprogramo-
waniu. W niniejszym rozdziale przedstawione zostały możliwości popularnych sieciowych
systemów operacyjnych w zakresie QoS . Wśród omawianych systemów znalazły się te,
które najczęściej występują w roli serwerów sieciowych oraz routerów  system IOS firmy
Cisco, darmowy system GNU/Linux, oraz system Windows 2000 Server firmy Microsoft.
8.1 Cisco IOS
Firma Cisco jest jednym z największych na świecie producentów sprzętu sieciowego.
System IOS jest standardowym systemem operacyjnym obsługującym routery oraz nie-
które przełączniki produkcji firmy. Aktualna w momencie pisania niniejszej pracy wersja
systemu to IOS 12.3.
Pod względem liczby funkcji QoS IOS znacząco wyróżnia się wśród systemów ope-
racyjnych. System autorstwa firmy Cisco oprócz standardowych niskopoziomowych me-
chanizmów oferuje również możliwość skonfigurowania węzła sieci w pełni zgodnego z ar-
chitekturą IntServ lub DiffServ. Dodatkowo konfiguracja mechanizmów QoS w systemie
IOS może odbywać się z poziomu wygodnego, opartego na bazie usługi WWW interfej-
su [Cis02b].
54
8. Przegląd możliwości wybranych systemów operacyjnych
Zaimplementowane mechanizmy
Konfiguracja QoS w systemie IOS sprowadza się do określenia które z dostępnych me-
chanizmów mają obowiązywać w obrębie danego węzła. Większość usług posiada wstępną
konfigurację, przydatną jako podstawa do tworzenia bardziej zaawansowanych mechani-
zmów.
" Klasyfikacja ruchu może być przeprowadzana na podstawie wielu czynników: pa-
rametrów DiffServ (pole DSCP), parametrów IntServ (komunikaty RSVP), informa-
cji odnośnie routingu oraz informacji z warstw wyższych (NBAR, ang. Network Ba-
sed Application Resolution). Ostatni mechanizm pozwala na klasyfikowanie ruchu
na podstawie takich charakterystyk jak fragment adresu URI w transmisji HTTP,
czy też typu MIME przesyłanego pliku [Cis02a].
" Wydajność łącza  IOS obsługuje zarówno fragmentację pakietów IP jak i kom-
presję protokołu RTP [Cis02b].
" Mechanizmy kontrolne  węzeł sieci pracujący pod kontrolą systemu IOS jest
w stanie pełnić rolę pełnoprawnego węzła sieci DiffServ. IOS bez problemu obsłu-
guje też protokół RSVP [Cis02b, Cis02a].
" Algorytmy kolejkowania obsługiwane przez IOS [Cis02a]:
FIFO.
Kolejka priorytetowa PQ (ang. Priority Queue). Kryterium służącym do usta-
lania priorytetu może być m.in.: adres z
ródłowy, adres docelowy, rozmiar pa-
kietu lub interfejs z którego pakiet przychodzi.
Kolejka sprawiedliwa WFQ (ang. Weighted Fair Queueing). Agregaty tworzo-
ne są z pojedynczych transmisji występujących w obrębie węzła. Dodatkową
możliwością jest ustawienie wag dla poszczególnych agregatów ruchu.
Kolejki klasowe  CQ (ang. Class Queueing) oraz CBWFQ (ang. Class Based
Weighted Fair Queueing). Pierwsza z nich oferuje standardową funkcjonalność
kolejki klasowej, druga natomiast zapewnia sprawiedliwość w obrębie klasy za
pomocą kolejki WFQ.
" Unikanie zatorów na platformie IOS realizowane jest przez dwa rodzaje mecha-
nizmów. WRED (ang. Weighted RED) umożliwiają wzięcie pod uwagę priorytetu
(pole ToS lub DSCP) pakietów podczas ustalania który pakiet zostanie odrzucony.
Flow-WRED zapewnia RED w obrębie poszczególnych transmisji.
55
8. Przegląd możliwości wybranych systemów operacyjnych
Konfiguracja pojedynczego routera może odbywać się zarówno z linii poleceń (poprzez
telnet lub konsolę administracyjną) ale również poprzez interfejs graficzny. Dokładny
opis konfiguracji QoS na platformie IOS można znalez
ć w [Cis02a]. Cisco IOS wspiera
szeroką gamę technik warstw II  w tym również występujące w ich obrębie mechanizmy
QoS  począwszy od sieci lokalnych (802.1p), a skończywszy na technikach sieci rozległym
(ATM, FR).
Wady i zalety
Do zasadniczych zalet platformy firmy Cisco należy zaliczyć na pewno jakość imple-
mentacji oraz ilość dostępnych funkcji. Zastosowanie specjalizowanych procesorów VIP
(ang. Versatile Interface Processors) powoduje, że implementacje mechanizmów QoS
w IOS należą do jednych z najbardziej wydajnych. Na plus należy też zaliczyć fakt ist-
nienia szczegółowej dokumentacji, która nie ogranicza się wyłącznie do opisu konfiguracji
sprzętu, lecz zawiera również opisy zaimplementowanych mechanizmów. Nie bez znacze-
nia jest również fakt ścisłej współpracy urządzeń Cisco ze sobą, co ułatwia tworzenie
bardziej skomplikowanych konfiguracji (np. domeny DiffServ).
Cisco IOS nie jest jednak systemem wolnym od wad. Podstawową wadą jest jego cena
 IOS przeznaczony jest do uruchamiania na platformie sprzętowej Cisco (routery, prze-
łączniki), która oprócz wysokiej jakości cechuje się również wysoką ceną. Wadą dla osób
pragnących własnoręcznie zoptymalizować konfigurację mechanizmu QoS , będzie z pew-
nością brak udokumentowanej specyfikacji kolejności aplikowania poszczególnych mecha-
nizmów QoS . Również niektóre z parametrów mechanizmów opisane są nieco zdawkowo
lub też firma Cisco odradza zmianę ich wartości.
8.2 GNU/Linux
System GNU/Linux jest popularnym, darmowym systemem operacyjnym o ogólnie
dostępnych kodach z
ródłowych, w którego rozwój zaangażowanych jest wielu ludzi z całe-
go świata. Zapoczątkowany w 1991 przez Linusa Torvaldsa, z systemu pisanego w ramach
hobby, Linux rozwinął się w dojrzały i wydajny system operacyjny.
Linux nader często znajduje zastosowanie jako serwer usług sieciowych bądz
też węzeł
sieci. Z tego też powodu z biegiem czasu zaimplementowano w nim szereg mechanizmów
QoS . Pomimo iż za rozwojem tych implementacji nie stoją wielkie firmy, Linux dysponu-
je imponującym wachlarzem dostępnych usług. Aktualna w momencie pisania niniejszej
pracy wersja systemu to Linux 2.4.20. Mechanizmy QoS występują również we wcześniej-
szych wersjach systemu.
56
8. Przegląd możliwości wybranych systemów operacyjnych
Zaimplementowane mechanizmy
Architektura QoS w Linuksie została zaprojektowana w sposób modułowy. Admini-
strator sam decyduje w jaki sposób współdziałają ze sobą poszczególne mechanizmy QoS,
tworząc swoiste drzewo mechanizmów skojarzone z danym interfejsem [Max02]. Tego typu
podejście daje większe możliwości modyfikacji parametrów i zachowania mechanizmów
QoS niż w przypadku innych platform. Pociąga to jednak za sobą znaczne skomplikowa-
nie procesu konfiguracji. Jak to często bywa w przypadku systemów darmowych, większy
nacisk położony został na funkcjonalność, mniejszy natomiast na łatwość obsługi.
W Linuksie zaimplementowano następujące mechanizmy QoS:
" klasyfikatory ruchu [Max02]:
u32 pozwalający na klasyfikację wg dowolnego pola nagłówka pakietu IP, lub
wg nagłówków protokołów TCP oraz UDP;
route pozwalający na klasyfikację podług reguł routowania dotyczących da-
nego pakietu;
fw umożliwiający na klasyfikację pakietów  oznaczonych wcześniej w obrębie
firewalla;
rsvp, rsvp6 klasyfikujący pakiety wg informacji uzyskiwanych za pomocą
protokołu RSVP;
tcindex analizujący pole DSCP;
" algorytmy kolejkowania [Max02, Coe03]:
FIFO, oraz jej modyfikacje uwzględniające priorytety, pFIFO;
kolejki sprawiedliwe, zapewniające sprawiedliwość  per przepływ  SFQ oraz
WRR;
ograniczanie przepustowości  mechanizm  wiadra z żetonami TBF;
wydajne kolejki klasowe CBQ oraz HTB, wyposażone w mechanizm prioryte-
tów, mechanizm pożyczania zasobów, mechanizm ograniczania przepustowości
oraz możliwość zastąpienia kolejek obsługujących poszczególne klasy złożony-
mi zestawami innych kolejek;
" mechanizmy zapobiegania zatorom  RED oraz GRED (ang. Generic RED) zapew-
niająca RED w obrębie pojedynczych transmisji.
Odpowiednio skonfigurowany system Linuksowy może pełnić rolę zarówno węzła do-
meny DiffServ jak i sieci IntServ. Linux wspiera również wiele technik warstwy II, w miarę
możliwości korzystając z istniejących w nich mechanizmów QoS .
57
8. Przegląd możliwości wybranych systemów operacyjnych
Wady i zalety
Zasadniczą zaletą systemu Linux jest jego darmowość. Zaimplementowane mechani-
zmy QoS działają prawie równie wydajnie jak ich odpowiedniki z kosztownej platformy
Cisco IOS. System Linux dostępny jest na wiele platform sprzętowych, co dodatkowo
zwiększa jego uniwersalność. Z racji dostępności kodów z
ródłowych w Internecie dostęp-
nych jest sporo rozmaitego rodzaju łatek, zwiększających możliwości systemu w dziedzi-
nie QoS  przykładem może być łatka l7 (http://l7-filter.sf.net) udostępniająca
klasyfikację pakietów wg informacji z warstwy aplikacji.
Niestety brak centralnej kontroli rozwoju systemu pociąga za sobą spore niedocią-
gnięcia w obszarze dokumentacji zaimplementowanych mechanizmów. O ile podstawowe
mechanizmy QoS udostępniane przez Linuksa są stosunkowo dobrze opisane, o tyle część
z dostępnych mechanizmów posiada nader znikomą dokumentację. Przykładem może być
np. kolejka CSZ [Max02], której dokumentacja składa się wyłącznie z kodu z
ródłowe-
go. Dla niektórych osób wadą może okazać się brak spójnych, graficznych interfejsów
konfiguracji QoS .
8.3 Windows 2000 Server
System Windows 2000 Server jest następcą słynnego systemu Windows NT produkcji
firmy Microsoft. System ten projektowany był z myślą o zastosowaniach serwerowych.
Możliwe jest też wykorzystanie Windows 2000 jako węzła sieci, z racji jednak sporych
wymagań (spowodowanych obowiązkowym graficznym interfejsem użytkownika) system
ów rzadko spotykany jest w takiej roli.
Zaimplementowane mechanizmy
Firma Microsoft nie udostępnia informacji odnośnie zaimplementowanych w swoim
systemie niskopoziomowych mechanizmów QoS . Z dostępnej dokumentacji wynika, że
system przygotowany jest do pełnienia funkcji pełnoprawnego węzła sieci DiffServ lub
IntServ. Opisany w dokumentacji mechanizm kształtowania ruchu posiada cechy kolejki
klasowej, wyposażonej w możliwość pożyczania zasobów. Pakiety mogą być klasyfikowane
na podstawie pola ToS, DSCP lub informacji otrzymanych za pomocą protokołu RSVP
[Max02].
Aplikacjom działającym w systemie Windows 2000 udostępnione jest API (ang. Appli-
cation Programming Interface) za pomocą którego mogą dokonywać rezerwacji zasobów
QoS .
58
8. Przegląd możliwości wybranych systemów operacyjnych
8.4 Zestawienie porównawcze
Porównując omówione powyżej systemy ze sobą należy wziąć pod uwagę docelowe za-
stosowanie konkretnej implementacji. System Microsoftu wyśmienicie nadaje się na serwer
aplikacyjny uwzględniający mechanizmy QoS . Do użycia jako router bardziej nadają się
systemy Linux oraz IOS z uwagi na dokładniejszą dokumentację, oraz łatwiejszą konfigu-
rację. Konkretny wybór pomiędzy IOS a Linuksem uzależniony jest przede wszystkim od
ilości dostępnych środków finansowych  w większości zastosowań Linux oferuje zbliżoną
wydajność przy znacząco niższych kosztach. Platforma Cisco z kolei zaczyna przejawiać
swą wyższość w momencie implementacji mechanizmów QoS w sieciach rozległych.
Platforma Cisco IOS wyróżnia się głównie pod względem jakościowym  wydajność
oraz łatwość obsługi. Linux, oferujący niewiele mniejsze możliwości posiada dość skom-
plikowany mechanizm konfiguracji, który przemawia na jego niekorzyść. Mimo to obydwa
systemy wyśmienicie nadają się do pełnienia roli węzła sieci świadomej istnienia mecha-
nizmów QoS , podczas gdy serwery aplikacyjne działające pod kontrolą Windows 2000
powinny raczej pełnić rolę uzupełniającą.
59
ROZDZIAA
9
Praktyka
Na płycie kompaktowej dołączonej do niniejszej pracy znajduje się skrypt slicer napi-
sany przez autora pracy. Skrypt powstał w celu wprowadzenia mechanizmów QoS w ob-
rębie sieci domowej autora. Sieć składa się z czterech stacji roboczych, pracujących pod
kontrolą różnych systemów operacyjnych, oraz routera zbudowanego w oparciu o system
Debian GNU/Linux. Router dysponuje łączem do Internetu o przepustowości 115kbps,
zrealizowanym poprzez terminal SDI.
Skrypt został napisany w języku Perl. W skrypcie wykorzystano program tc z pa-
kietu iproute2 służący do kontroli mechanizmów QoS przypisanych do poszczególnych
interfejsów.
Działanie skryptu ma za zadanie:
" Zmniejszyć dostępną przepustowość łącza do Internetu o 1%. Zabieg ten ma na
celu wytworzenie sytuacji w której router jest najwolniejszym elementem na trasie
pakietu do Internetu. Dopiero przy spełnieniu tego warunku kształtowanie ruchu
w obrębie routera ma faktyczny wpływ na parametry transmisji. Gdyby router
wypuszczał pakiety z pełną prędkością, największy wpływ na parametry transmisji
miałby terminal SDI.
" Podzielić dostępną przepustowość łącza do Internetu (download) pomiędzy wszyst-
kich użytkowników sieci w sprawiedliwy sposób. Przekłada się to na zapewnienie
pojedynczemu komputerowi w sieci co najmniej 25% dostępnej przepustowości.
" Zapewnić równomierny rozkład przepustowości pomiędzy pojedyncze transmisje
występujące w obrębie klasy przeznaczonej dla pojedynczego użytkownika
60
9. Praktyka
" W miarę możliwości przydzielać (w sprawiedliwy sposób) użytkownikom niewyko-
rzystywane przez innych fragmenty przepustowości.
" W sposób priorytetowy traktować niektóre pakiety wychodzące z sieci. Dotyczy
to pakietów z ustawioną flagą ACK, pakietów ICMP oraz pakietów z polem ToS
oznaczającym niskie opóz
nienie.
" Zapewnić minimalną przepustowość dla określonych usług w ruchu wychodzącym
(upload).
Do interfejsu eth0 routera, należącego do sieci lokalnej przypisane zostaje drzewo
mechanizmów QoS przedstawione na rysunku 9.1.
Rysunek 9.1: Mechanizmy kolejkowania związane z eth0.
Osobne kolejki HTB zarządzają ruchem przychodzącym  z zewnątrz oraz ruchem
generowanym przez serwer. W obrębie tego pierwszego, utworzono cztery klasy, po jednej
dla każdego użytkownika, zapewniając mu przynajmniej 25% dostępnej przepustowości.
Ruch we wszystkich klasach obsługują kolejki SFQ, zapewniające równy podział dostęp-
nych zasobów pomiędzy obecne w danej klasie transmisje.
61
9. Praktyka
Do interfejsu ppp0 routera, będącego jego interfejsem zewnętrznym, przypisane zostaje
drzewo mechanizmów QoSprzedstawione na rysunku 9.2.
Rysunek 9.2: Mechanizmy kolejkowania związane z ppp0.
Kolejka HTB związana z interfejsem ppp0 wyróżnia cztery klasy:
" 15% zarezerwowane zostało dla pakietów ICMP, segmentów TCP z ustawioną fla-
gą ACK (rozpoczynających transmisję) i pakietów IP z polem ToS oznaczającym
minimalne opóz
nienie. Klasa ta posiada też wyższy priorytet niż pozostałe.
" Przynajmniej 20% przepustowości zarezerwowane zostało dla wychodzącego ruchu
HTTP (tzn. dla transmisji stron WWW z routera do klientów w Internecie).
" Przynajmniej 35% przepustowości zarezerwowane zostało dla wychodzącego ruchu
FTP (tzn. dla transmisji z routera do klientów w Internecie).
" Reszta ruchu ma gwarancję przynajmniej 30% przepustowości.
Uruchamianie skryptu
Skrypt musi być uruchamiany z uprawnieniami administratora.
62
9. Praktyka
Przed uruchomieniem należy dokonać konfiguracji skryptu, polegającym na edycji
początkowej jego części:
# komputery pomiedzy k t o r e z o s t a n i e p o d z i e l o n e l a c z e
@stacje = qw( magi wapor sylwek seba ) ;
# binar k a programu t c k t o r a bedziemy wykorzystywac
$tc =  / usr / l o c a l / s b i n / tc  ;
# predkosc l a c z a do I n t e r n e t u w o b i e s t r o n y
$inspeed = 115;
$outspeed = 115;
# i n t e r f e j s l a c z a do I n t e r n e t u
$ l i n k d e v =  ppp0  ;
# do i l u % ma z o s t a c przeskalowane dostepne pasmo?
$ s c a l e = 98;
# predkosc i i n t e r f e j s s i e c i l o k a l n e j
$lanspeed = 10000;
$landev =  eth0  ;
# i l e % pasma wychodzacego ma z o s t a c zarezerwowane na ACK/ICMP/ToS
$ f a s t = 15;
# i l e pasma ma z o s t a c przeznaczone na p o s z c z e g o l n e u s l u g i .
# " oznacza r e s z t e ruchu wychodzacego , i musi w y s t a p i c j a k o p i e r w s z e
# w k o n f i g u r a c j i
@ports = qw( " 80 2 1 ) ;
@min = qw( 3 0 20 3 5 ) ;
@max = qw( 1 0 0 1 0 0 1 0 0 ) ;
# w p o w yz s z e j k o n f i g u r a c j i zarezerwowano :
# pomiedzy 20% a 100% na ruch HTTP ( p o r t 80)
# pomiedzy 50% a 100% na ruch FTP ( p o r t 21 )
# pomiedzy 30% a 100% na r e s z t e ruchu wychodzacego
63
9. Praktyka
Analiza efektów działania skryptu
Przeprowadzone w środowisku sieci lokalnej testy wykazały co następuje:
" Szybkość transferu jest poprawnie ograniczana do 112kbit w kierunku  ze świa-
ta . Ograniczenia transferu dotyczące usług (w przykładzie powyższym HTTP oraz
FTP) również działają bez zarzutu.
" Zaproponowany schemat kolejek skojarzony z interfejsem wewnętrznym działa po-
prawnie, dzieląc w określony sposób dostępną przepustowość pomiędzy aktualnie
korzystających z łącza użytkowników.
" Wprowadzona priorytetyzacja pakietów spowodowała efekt mniejszy niż było to
oczekiwane. Poniżej zamieszczono przykładowe wyniki osiąganych prędkości po-
dróży pakietu ICMP Echo, w warunkach silnego obciążenia łącza (wychodzącym
pojedynczym transferem FTP). Test polegał na wysłaniu 250 pakietów ICMP Echo
i zmierzeniu stopnia utraty pakietu oraz średnich czasów podróży pakietu.
bez QoS :
utrata pakietów 5%
minimalny czas podróży 89,2 ms
średni czas podróży 350,7 ms
maksymalny czas podróży 650,3 ms
z QoS :
utrata pakietów 0%
minimalny czas podróży 70,1 ms
średni czas podróży 229,2 ms
maksymalny czas podróży 560,1 ms
Zysk wynikający z wprowadzenia mechanizmów QoS jest mniejszy niż było to ocze-
kiwane. W celu poprawienia sytuacji wskazane byłoby również zapewnienie więk-
szego priorytetu pakietom niosącym odpowiedzi (np. ICMP Echo Reply), jednak
w tym celu konieczne byłoby skonfigurowanie mechanizmów QoS u dostawcy usług
internetowych.
" Fragmentowane pakiety stanowią problem dla mechanizmu klasyfikatora, który nie
jest w stanie zakwalifikować pakietu do odpowiedniej klasy. Owocuje to niewielkimi
wahaniami ilości dostępnego pasma.
64
Część IV
Zakończenie
65
ROZDZIAA
10
Przyszłość QoS
Zdaniem autora mechanizmy QoS odegrają znaczącą rolę w rozwoju nowych tech-
nik sieciowych. Na dzień dzisiejszy, pomimo istnienia szerokiej gamy rozmaitych mecha-
nizmów gwarantowanej jakości usług, QoS pozostaje dość rzadko wdrażaną techniką.
Wynika to z faktu, iż wdrożenia sieciowe charakteryzują się dość dużą bezwładnością
i wszelkie zmiany w istniejących implementacjach okazują się ciężkie do przeprowadzenia.
Podobne zjawisko dotyczy standardów sieciowych. Niemniej jednak, nowo opracowywane
rozwiązania zwracają na ogół uwagę na problemy QoS . Pomimo cały czas wzrastają-
cych prędkości dostępnych łączy, QoS okazuje się być niezbędnym elementem większości
nowopowstających sieci.
Temat QoS pozostaje w centrum zainteresowania specjalistów sieciowych. Zagad-
nienia routingu uwzględniającego QoS są tematem sporej części publikowanych prac.
W dziedzinie niskopoziomowych algorytmów można zauważyć pewien zastój  istniejące
algorytmy okazują się dość wydajne. Co jakiś czas pojawiają się nowe pomysły  przy-
kładem może być algorytm unikania zatorów o nazwie BLUE. Typowe algorytmy unika-
nia zatorów bazują na idei analizy stanu bufora, podczas gdy BLUE podejmuje decyzje
o usuwaniu pakietów na podstawie czasu zajętości łącza. BLUE jest stosunkowo nowym,
a co za tym idzie nierozpowszechnionym pomysłem. W momencie pisania niniejszej pracy
istniała tylko jedna implementacja tego algorytmu (na platformie FreeBSD).
W dziedzinie klasyfikacji ruchu trwają intensywne prace nad mechanizmami analizy
warstw protokołów warstwy transportowej oraz aplikacji. W dobie wzmożonej popularno-
ści systemów peer-to-peer, generujących gigantyczne ilości ruchu istnieje zapotrzebowanie
na mechanizm pozwalający filtrować tego typu transmisje. Implementacja NBAR (ang.
Network Based Application Resolution) jest w stanie klasyfikować ruch względem cech
66
10. Przyszłość QoS
takich jak fragmenty lub całość adresu URI w ruchu HTTP czy też typ przesyłanego pli-
ku. Oczywiście tego typu analiza jest bardzo kosztowna obliczeniowo, lecz coraz częściej
staje się niezbędna w celu wychwycenia transmisji występujących na niestandardowych
portach [Cis02b].
Ciekawym zjawiskiem są też powstające ostatnio systemy automatycznego zarządza-
nia QoS . System tego typu nadzoruje ruch w określonych punktach w sieci i na podstawie
jego analizy zmienia parametry niskopoziomowych mechanizmów QoS działających w ob-
rębie węzłów tej sieci. Zakładając poprawność działania takiego systemu i integrując go
z architekturą DiffServ lub IntServ można otrzymać istotną poprawę wydajności całego
mechanizmu. Systemy tego typu występują od dość dawna w technikach VoIP.
Reasumując, techniki QoS mają przed sobą sporą przyszłość. Ich użycie w coraz
większej ilości przypadków wydaje się nieuniknione.
67
Zawartość płyty kompaktowej
Do niniejszej pracy dołączona została płyta kompaktowa zawierająca:
" skrypt opisany w rozdziale 9;
" dokumenty RFC wymienione w spisie literatury;
" plik PDF zawierający niniejszą pracę;
A
" z
ródła pracy w formacie LTEX.
i
Literatura
[Alm92] P. Almquist. Type of Service in the Internet Protocol Suite, lipiec 1992. RFC
1349.
URI:http://www.rfc-editor.org/rfc/rfc1349.txt
[ATM03] ATMForum.com. ATM Approved Specifications, luty 2003.
URI:http://www.atmforum.com/standards/approved.html
[Bak00] F. Baker, B. Lindell, M. Talwar. RSVP Cryptographic Authentication, styczeń
2000. RFC 2747.
URI:http://www.rfc-editor.org/rfc/rfc2747.txt
[Bla98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. An Architecture
for Differentiated Service, grudzień 1998. RFC 2475.
URI:http://www.rfc-editor.org/rfc/rfc2475.txt
[Bla01] D. Black, S. Brim, B. Carpenter, F. Le Faucheur. Per Hop Behavior Identifi-
cation Codes, czerwiec 2001. RFC 3140.
URI:http://www.rfc-editor.org/rfc/rfc3140.txt
[Bra94] R. Braden, D. Clark, S. Shenker. Integrated Services in the Internet Architec-
ture: an Overview, czerwiec 1994. RFC 1633.
URI:http://www.rfc-editor.org/rfc/rfc1633.txt
[Cis02a] Cisco. QC: Cisco IOS Quality of Service Solutions Configuration Guide,
Release 12.2, 2002.
URI: http://www.cisco.com/univercd/cc/td/doc/product/software/
ios122/122cgcr/fqos_c/index.htm
ii
[Cis02b] Internetworking Technology Handbook, rozdział Quality of Service (QoS).
Cisco, 2002.
URI: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/
qos.htm
[Coe03] S. Coene. Linux  Don t Fear the Penguins, marzec 2003.
URI:http://docum.org/
[Dav02] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney,
S. Davari, V. Firoiu, D. Stiliadis. An Expedited Forwarding PHB (Per-Hop
Behavior), marzec 2002. RFC 3246.
URI:http://www.rfc-editor.org/rfc/rfc3246.txt
[Dur00] D. Durham, J. Boyle, , R. Cohen, S. Herzog, R. Rajan, A. Sastry. The COPS
(Common Open Policy Service) Protocol, styczeń 2000. RFC 2748.
URI:http://www.rfc-editor.org/rfc/rfc2748.txt
[FRF02] FRForum.com. Frame Relay Implementation Agreements, maj 2002.
URI:http://www.frforum.com/5000/5000index.html
[Hei99] J. Heinanen, F. Baker, W. Weis, J. Wroclawski. Assured Forwarding PHB
Group, czerwiec 1999. RFC 2597.
URI:http://www.rfc-editor.org/rfc/rfc2597.txt
[Max02] G. Maxwell, R. van Mook, M. van Oosterhout, P. B. Schroeder, J. Spaans,
P. Larroy. Linux Advanced Routing & Traffic Control, czerwiec 2002.
URI:http://lartc.org/
[Moy98] J. Moy. OSPF Version 2, kwiecień 1998. RFC 2328.
URI:http://www.rfc-editor.org/rfc/rfc2328.txt
[Nic98] K. Nichols, S. Blake, F. Baker, D. Black. Definition of the Differentiated Servi-
ces Field (DS Field) in the IPv4 and IPv6 Headers, grudzień 1998. RFC 2474.
URI:http://www.rfc-editor.org/rfc/rfc2474.txt
[oSC81] Information Sciences Institute University of Southern California. Internet Pro-
tocol, DARPA Internet Program Protocol Specification, wrzesień 1981. RFC
791.
URI:http://www.rfc-editor.org/rfc/rfc791.txt
[Peu99] M. Peuhkuri. IP Quality of Service, maj 1999.
URI:http://keskus.hut.fi/u/puhuri/htyo/Tik-110.551/iwork/
iii
[QoS99] QoSforum.com. IP QoS FAQ, wrzesień 1999.
[RB97] Ed. R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. Resource ReSerVation
Protocol (RSVP)  Version 1 Functional Specification, wrzesień 1997. RFC
2205.
URI:http://www.rfc-editor.org/rfc/rfc2205.txt
[Sch96] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Pro-
tocol for Real-Time Applications, styczeń 1996. RFC 1889.
URI:http://www.rfc-editor.org/rfc/rfc1889.txt
[She97] S. Shenker, C. Partridge, R. Guerin. Specification of Guaranteed Quality of
Service, wrzesień 1997. RFC 2212.
URI:http://www.rfc-editor.org/rfc/rfc2212.txt
[W2k00] Windows 2000 Advanced Server Help, rozdział QoS admission control. Micro-
soft, luty 2000.
URI: http://www.microsoft.com/windows2000/en/advanced/help/sag_
ACStopnode.htm?id=3390
[Wro97] J. Wroclawski. Specification of the Controlled-Load Network Element Service,
wrzesień 1997. RFC 2211.
URI:http://www.rfc-editor.org/rfc/rfc2211.txt
iv
Spis rysunków
3.1 Koncepcja działania QoS w obrębie jednego węzła sieci . . . . . . . . . . 11
3.2 Przykład rozdziału informacji pomiędzy PDP a PEP. . . . . . . . . . . . 13
4.1 Najprostszy bufor przypisany do interfejsu. . . . . . . . . . . . . . . . . . 17
5.1 Budowa nagłówka pakietu IP. . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2 Składowe pola ToS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Architektura IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 Propagacja komunikatów PATH . . . . . . . . . . . . . . . . . . . . . . . 24
5.5 Propagacja komunikatów RESV. . . . . . . . . . . . . . . . . . . . . . . . 25
5.6 IntServ a multicast. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.7 Przykład sesji RSVP zawierającej dwa przepływy . . . . . . . . . . . . . 27
5.8 Mechanizm DiffServ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.9 Działanie domeny DiffServ. . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.10 Budowa pola DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.11 Przykładowy podział przepustowości pomiędzy klasy usługi AF . . . . . 34
6.1 Umiejscowienie etykiety 802.1p/q w nagłówku ramki ethernetowej. . . . . 38
6.2 Podział pasma pomiędzy usługi sieci ATM. . . . . . . . . . . . . . . . . . 39
7.1 Problem stawiany przed węzłami sieci. . . . . . . . . . . . . . . . . . . . 42
7.2 Kolejka FIFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Przykład odrzucenia pakietu w kolejce FIFO. . . . . . . . . . . . . . . . 44
7.4 pFIFO  kolejka FIFO uwzględniająca priorytety . . . . . . . . . . . . . 44
7.5 Przykładowa kolejka  sprawiedliwa . . . . . . . . . . . . . . . . . . . . . 46
7.6 Wiadro z żetonami. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
v
7.7 Przykładowe drzewo kolejek klasowych . . . . . . . . . . . . . . . . . . . 49
7.8 Działanie mechanizmu unikania zatorów. . . . . . . . . . . . . . . . . . . 50
7.9 Przykład fragmentacji pakietów . . . . . . . . . . . . . . . . . . . . . . . 52
9.1 Mechanizmy kolejkowania związane z eth0. . . . . . . . . . . . . . . . . 61
9.2 Mechanizmy kolejkowania związane z ppp0. . . . . . . . . . . . . . . . . 62
vi
Skorowidz
802.1p, 37 IntServ, 22, 23, 42, 54, 57
rezerwacja zasobów, 24
ABR, 39
usługi, 29
AFR, 40
wady i zalety, 29
ARPANET, ii
IP
ATM, 5, 38, 40
pakiet, 21
fragmentacja, 19, 51
BLUE, 51, 66
kompresja, 52
bufor, 17
pole ToS, 16, 23
CBR, 39
znakowanie, 16
cieknące wiadro, 48
protokół, 20
CIR, 40
kolejka, 18
Cisco IOS, 54
 sprawiedliwa , 18, 57
wady i zalety, 56
CBQ, 57
zaimplementowane mechanizmy, 55
CBWFQ, 55
cRTP, 52
CQ, 55
DiffSerV, 51
FIFO, 43, 55, 57
DiffServ, 23, 30, 42, 54, 57
FQ, 46
domena, 31
HTB, 49, 57, 61, 62
pole DSCP, 16, 30, 33 35
klasowa, 18, 48, 57
usługi, 33
pFIFO, 45, 49
wady i zalety, 35
PQ, 55
PRIO, 49
EIR, 40
priorytetowa, 18
FrameRelay, 5, 40
SFQ, 57, 61
sprawiedliwa, 45
GRED, 57
vii
WFQ, 55 komunikat RESV, 25, 28
WRR, 57 przepływ, 27
kontrola dostępu, 19 sesja, 27
RTP, 52
Linux, 56, 60
rtVFR, 40
klasyfikatory ruchu, 57
wady i zalety, 58
SLA, 7, 32
zaimplementowane mechanizmy, 57
SVC, 40
NBAR, 10, 66
TBF, 18, 34, 46, 48
nrtVFR, 40
TCP, 6, 50
parametry
UBR, 39
jednorodność, 5
usługa
koszt, 6
gwarantowana, 29
opóz
nienie, 5
kontrolowanego obciążenia, 29
przepustowość, 4
przesyłania gwarantowanego, 33
utrata pakietów, 6
przesyłania przyspieszonego, 34
PHB, 31
VBR, 39
przepływ
VLAN, 38
agregowanie, 17, 45, 48
kształtowanie, 18
Windows 2000 Server, 58
ograniczanie, 46, 57
zaimplementowane mechanizmy, 58
unikanie zatorów, 50
WRED, 51, 55
PVC, 40
QoS, iii, 2
konfiguracja, 12
przekazywanie informacji o, 16
przyszłość, 66
skalowalność, 11
społeczny, 13
sprawiedliwość, 3
sygnalizacja, 12
sygnalizowanie, 16
zasady implementacji, 10
RED, 50, 57
RSVP, 23, 27, 55
budowa, 27
komunikat PATH, 24, 28
viii