SYMULACJA MECHANIZMÓW ROUTINGU QoS W SYMULATORZE

Maciej Kowalczyk
Marcin Godlewski
Sławomir Przyłucki
Politechnika Lubelska
ul. Nadbystrzycka 38a
20-618 Lublin
[email protected]
2006
Poznańskie Warsztaty Telekomunikacyjne
Poznań 7 - 8 grudnia 2006
SYMULACJA MECHANIZMÓW ROUTINGU QoS W SYMULATORZE NS2
Streszczenie: Artykuł przedstawia koncepcję routingu
Quality of Service, jako jedno z możliwych rozwiązań
zapewniania jakości usługom na warstwie sieciowej.
Omówione zostaną podstawowe algorytmy wyboru
tras właściwe dla QoSR. Przedstawione zostaną
również wyniki symulacji algorytmu wyznaczania
tras On-Demand, przy użyciu symulatora NS2.
przeciążeń, routing QoS, jako że oparty jest o
mechanizmy kontroli stanu łącza, powinien być w stanie
zapewnić lepszy przepływ danych, niż routing best
effort lub inne mechanizmy nie badające stanu łącza
[3][2][1].
1. Wstęp
Aby wymagania jakości usług mogły być
zaimplementowane i spełnione oraz by mogła być
wyliczona odpowiednia ścieżka routingu, należy wyrazić
je za pomocą pewnych miar Quality of Service – metryk.
Wyrażają one jeden, bądź kombinację parametrów QoS.
Metryką może być koszt, przepustowość, opóźnienie na
łączu, wartość jitter, straty pakietów. Istnieją
3 typy metryk używanych w routingu Quality of Service:
addytywna (ang. additive), multiplikatywna (ang.
multiplicative) oraz wklęsła (ang. concave).
Koncepcja routingu Quality of Service powstała
jako odpowiedź na wprowadzanie nowoczesnych
technologii usług czasu rzeczywistego, takich jak np.
wideo na żądanie, czy audio/telekonferencja. Wymagają
one zapewnienia odbiorcy gwarancji parametrów
jakości transmisji . Dzisiejszy Internet opiera swoje
działanie na podejściu best-effort, które traktuje każdy
rodzaj ruchu sieciowego w sposób jednakowy,
uniemożliwiając jakiekolwiek rozróżnienie przesyłanych
danych . Podejście to nie jest w stanie także zapewnić
gwarancji utrzymania parametrów transmisji danych
krytycznych czasowo i wrażliwych na dostępną
przepustowość [4]. Mechanizm routingu Quality of
Service bierze pod uwagę dostępną przepustowość oraz
szereg innych informacji na temat łącza. Na ich
podstawie zestawia ścieżki, które spełniają wymagania
jakości usługi dla danego przepływu [3].
Podstawowe założenia koncepcji routingu QoS
zdefiniowane są w poniższych punktach:
-Dynamiczne
zestawianie
odpowiednich
(prawidłowych) ścieżek – znalezienie ścieżki
umożliwiającej co najmniej duże prawdopodobieństwo
zapewnienia parametrów QoS dla danego przepływu.
-Optymalizacja zużycia zasobów sieciowych –
Routing QoS może być użyty w celu balansowania
ruchem sieciowym (ang. load balancing). Uzyskuje się w
ten sposób znaczne polepszenie wykorzystania
dostępnego pasma, a przez to realne zwiększenie
prędkości transmisji przysyłanych danych.
-Korzystny rozkład wydajności – w sytuacjach
2. Metryki
Załóżmy, że m(n1,n2) jest metryką dla łącza (n1,n2).
Dla każdej ścieżki P = (n1,n2,...,ni,nj ), gdzie (n1,n2,...,ni,nj)
reprezentują węzły w sieci, metryka m jest:
a. Addytywna, jeśli
m(P) = m(n1,n2) + m(n2,n3) + ... + m(ni,nj) (1)
Przykładami parametrów reprezentowanych przez
metryki addytywne są: opóźnienie, jitter a także koszt i
hop-count (ilość routerów pośredniczących na trasie).
b. Multiplikatywna, jeśli
m(P) = m(n1,n2) * m(n2,n3) * ... * m(ni,nj) (2)
Przykładem parametru wykorzystującego tę
metrykę może być pewność dostarczenia pakietu, w tym
przypadku 0 < m(ni,nj) <1.
c. Wklęsła, jeśli
m(P) = min{m(n1,n2),m(n2,n3), ..., m(ni,nj)} (3)
Przykładem jest minimalna przepustowość łącza,
wystarczająca do zapewnienia usłudze jakości [2][5][6].
3. Klasy algorytmów routingu
Do głównych zadań algorytmów routingu QoS
należy zbieranie informacji o stanie łącza, stała ich
aktualizacja oraz przeszukiwanie tablic routingu w celu
zestawienia odpowiedniej ścieżki dla nadchodzącego
przepływu. Algorytmy routingu Quality of Service
podzielone są na trzy główne klasy, odwzorowujące
sposób wykonywania wyżej wymienionych zadań.
3.1 Source routing
W tej klasie odpowiednie ścieżki dla przepływów
ruchu wyliczane są przez węzeł źródłowy. Następnie, do
węzłów pośredniczących na długości wybranej ścieżki,
wysyłane są wiadomości informujące je o występujących
po nich węzłach. Ścieżka zawarta może być także w
nagłówku każdego pakietu. Strategia lokalnego
wyliczania ścieżek oznacza, że węzły musza znać ogólny
stan sieci. Oznacza to, że informacje o topologii i stanie
łącza muszą być aktualizowane często na każdym węźle,
co może doprowadzać do znacznej zajętości łącza
spowodowanej
samym
działaniem
algorytmu.
Przeciążenia obejmują także węzeł źródłowy, który
oblicza całą trasę dla danego ruchu, co w przypadku
rozległej sieci powoduje wydłużenie czasu obliczeń i
znaczne obciążenie procesora routera. Source routing nie
jest rozwiązaniem skalowalnym i szeroko używanym w
Internecie, ale jest jednocześnie prosty i elastyczny.
Ponieważ w praktyce cały proces routingu wykonywany
jest w węźle źródłowym, użyty może zostać jakikolwiek
algorytm. Zcentralizowana natura algorytmów klasy
source routing pozwala na ich łatwą implementację i
aktualizację, ale jednocześnie konieczność zawarcia
konkretnej ścieżki w nagłówku IP nie wydaje się być
rozwiązaniem praktycznym. W kontekście routingu
Quality of Service, algorytmy klasy source routing są
bardziej stosowne, niż dla tradycyjnego routingu z
algorytmem najkrótszej ścieżki (ang. Shortest Path
First), gdzie bardziej właściwa byłaby klasa distributed
routing. Wchodzą tutaj pod rozwagę takie dodatkowe
zagadnienia, jak kontrola dostępu do łącza (ang.
admission control), czy rezerwacja zasobów (ang.
resource reservation). Węzeł źródłowy musi więc brać
pod uwagę całą ścieżkę, co czyni wątpliwymi korzyści
płynące z zastosowania klasy distributed routing .
3.2 Distributed routing
Zwany jest także hop-by-hop routing. Ścieżki
obliczane są w sposób rozproszony, czyli przez każdy
węzeł. Większość algorytmów tej klasy wymaga od
każdego routera, by utrzymywał bazę o stanie sieci i na
jej podstawie podejmował decyzje routingu do
następnego
węzła.
Są
to
w większości protokoły typu link-state. Innym
podejściem do distributed routing jest rozszerzenie
algorytmów typu distance-vector o możliwość
dołączania informacji na temat dostępnej przepustowości
oraz innych metryk, łącznie z informacjami dotyczącymi
następnego węzła. Obciążenie związane z obliczeniami
na pojedynczym węźle jest dużo mniejsze, niż
w przypadku source routing, ponieważ potrzebne jest
tylko znalezienie następnego węzła (next hop).
Distributed routing jest bardziej skalowalny niż source
routing. Problemy pojawić się mogą w momencie, gdy
informacje na temat ścieżkek w poszczególnych węzłach
są niespójne. Może to powodować pętle i uniemożliwić
wyliczenie ścieżki. Distributed routing jest wiodącą
strategią dzisiejszego Internetu.
3.3 Hierarchical routing
Ta klasa algorytmów opiera swe działanie na
tworzeniu topologii hierarchicznej, polegającej na
grupowaniu węzłów w logiczne grupy, które wchodzą w
skład podobnej grupy na wyższym poziomie hierarchii.
Rys. 1. Architektura hierarchiczna na dwóch poziomach.
Hierarchical routing w odniesieniu do routingu
Quality of Service jest podobny do klasy source routing,
z tym, że każdy węzeł posiada szczegółowe informacje o
innych routerach jedynie z tej samej grupy logicznej.
Oprócz tego przechowywane są zagregowane informacje
o węzłach z innych grup. W momencie rozpoczęcia
transmisji, router wysyła wiadomość kontrolną. Gdy ta
dociera do węzła granicznego będącego składnikiem
grupy widocznej na wyliczonej trasie, jako logiczny
węzeł, uruchamiany jest mechanizm source routing w
celu wyznaczeniu ścieżki przez tę grupę. Algorytmy
source routing używane są na każdym poziomie
hierarchii.
Hierarchical
routing
rozwiązuje
problem
skalowalności mechanizmu source routing. Jest
postrzegany jako najbardziej obiecujące rozwiązanie tej
kwestii w odniesieniu do routingu Quality of Service.
Agregacja węzłów wprowadza jednakże dodatkowe
nieścisłości. Mogą pojawić się ścieżki wielokrotne
biegnące przez węzły logiczne. Żądania routingu
zawierające wymagania np. niskich wartości opóźnień
lub szerokiego pasma mogą być kierowane poprzez
węzły logiczne, ale oba wymagania nie mogą być
spełnione jednocześnie. Typowym przykładem protokołu
routingu opartego na hierarchical routing jest PNNI (ang.
Private Network-Network Interface) [3].
4. Tryb Pre-Computation oraz
On-Demand w routingu QoS
Routing Quality of Service opiera się na dwóch
podstawowych koncepcjach obliczania i doboru ścieżki
routingu. Są to algorytmy Pre-Computation oraz OnDemand. Dla pierwszego, ścieżka wyliczana jest bądź
okresowo, bądź gdy nie może być odnaleziona pośród
rezultatów obliczonych już ścieżek. Działanie drugiego
algorytmu opiera się na wyliczaniu ścieżek w przypadku
nadejścia nowego żądania routingu. Komunikaty o stanie
łącza oraz proces wyliczania ścieżek pochłania znaczącą
ilość zasobów sieciowych, a także sprzętowych.
Powoduje to znaczne obciążenie procesora routera, a
przechowywanie rozległych tablic routingu zmniejsza
zasoby pamięci. Częste wyliczanie ścieżek zwiększa
jakość ich wyboru, lecz obciąża zasoby i doprowadza do
złożoności implementacji algorytmu, szczególnie w
dużych sieciach szkieletowych. Kontrolowanie obciążeń
powodowanych działaniem algorytmuobliczania i
wyboru ścieżki pozwala na wyważenie pomiędzy
dokładnością routingu, a złożonością systemu [7].
4.1 Algorytm Pre-Computation
Specyficzne wymagania gwarancji parametrów
jakości ruchu wymagają stworzenia i utrzymywania
odpowiedniej
tablicy
routingu,
podobnej
do
wykorzystywanej w routingu best effort. W przypadku
użycia algorytmu Pre-Computation, czyli wyliczania
odpowiednich ścieżek „z góry”, wymagania te nie są
jeszcze znane. W związku z tym tablica routingu musi
zawierać szereg ścieżek z wyspecyfikowanymi parami
źródło-przeznaczenie, z powodu różnych wymagań QoS.
Wymagania te, w celu zmniejszenia stopnia złożoności
wyliczeń, grupowane są w szereg klas. Żądania
znajdujące się w jednej klasie posiadają podobne
wymagania co do parametrów QoS np. przepustowości.
Dla każdej klasy i pary źródło – przeznaczenie obliczana
jest odpowiednia ścieżka, która umieszczana jest w
tablicy routingu. Inne podejście tego algorytmu zakłada
brak klasyfikacji żądań. W tablicy routingu
przechowywane są przepustowości ścieżki z minimalną
liczbą hopów, a także ścieżki posiadające większe
zasoby przepustowości, ale przebiegające dłuższymi
trasami. Dla przychodzącego żądania sprawdzany będzie
w pierwszej kolejności wpis z minimalną liczbą węzłów.
Jeśli trasa ta nie spełnia warunku zapewnienia parametru
QoS w postaci wystarczającej przepustowości,
sprawdzane są trasy dłuższe [1][7][8][9].
Do zalet podejścia Pre-Computation zaliczyć
można:
–Dobrą skalowalność algorytmu. Zwiększenie
ilości węzłów i połączeń sieciowych powoduje
pojawianie się większej ilości zmian w topologii.
Skutkuje to generowaniem większej ilości komunikatów
LSA, a przede wszystkim zwiększeniem obciążenia
zasobów sieciowych i sprzętowych poprzez obliczanie
ścieżek. Algorytm Pre-Computation jest niezależny od
ilości żądań routingu. Większe sieci generują więcej
żądań routingu w jednostce czasu. Algorytm umożliwia
rozłożenie obliczeń na kilka żądań, a w ten sposób
przyczynić się do zmniejszenia całkowitego obciążenia
sieci.
–Jest tolerancyjny dla błędów wynikających z
awarii
węzłów
bądź
połączeń
sieciowych.
Rozwiązaniem jest ominięcie uszkodzonej części sieci
poprzez wybór trasy alternatywnej. Algorytm umożliwia
wcześniejsze obliczenie tras alternatywnych, by poradzić
sobie z takimi awariami.
–Potrafi zwiększyć wydajność sieci w czasie jej
dużej zajętości, gdy może pojawić się znacznie więcej
żądań, niż zwykle. Ponieważ ścieżki zostały już
obliczone i są przechowane w tablicy routingu,
obsłużenie nawet większej ilości przychodzących żądań
nie stanowi obciążenia zasobów. Algorytm PreComputation jest bardziej wydajny w przypadku dużego
natężenia ruchu.
–Umożliwia
poprawienie
load
balancingu.
Ponieważ szereg ścieżek do tego samego przeznaczenia
obliczanych jest z wyprzedzeniem, dostępne zasoby
mogą być przydzielane w sposób bardziej efektywny. W
związku z tym ruch sieciowy może być wyważony
poprzez kierowanie ruchu trasami alternatywnymi.
Algorytm Pre-Computation postrzegany jest jako
rozwiązanie poprawiające skalowalność i czas reakcji
sieci na żądania routingu, także redukujące obciążenie
dostępnych zasobów spowodowane obliczeniami
ścieżek, lecz za cenę obniżenia jakości decyzji routingu.
Poprzez wyliczanie z wyprzedzeniem ścieżek do
każdego adresu przeznaczenia, zmniejsza się czas
obsługi przychodzących żądań routingu. Widoczne jest
to w chwilach zwiększonego natężenia ruchu.
Jednocześnie taki sposób wyliczania ścieżek, może
przyczynić się do marnowania zasobów, jeśli używane
będzie tylko kilka z obliczonych wcześniej tras
[1][7][8][9].
4.2 Algorytm On-Demand QoS Routing
Algorytm ten wylicza trasy wtedy, gdy nadejdzie
nowe żądanie routingu. Używając najnowszych
informacji o stanie sieci, może być podjęta lepsza
decyzja o routingu, niż w przypadku algorytmu PreComputation. On-Demand nie wylicza tras do
wszystkich adresów przeznaczenia i różnych wymagań
zachowania parametrów jakości usług. Odpowiednia
ścieżka wyliczana jest tylko wtedy, gdy nadejdzie
żądanie routingu, więc przeznaczenie jest znane. Jeśli
jest to ruch, który wymaga np. konkretnej
przepustowości, jej wartość również jest znana.
W związku z tym, tylko jedna ścieżka, która spełnia te
założenia, musi zostać wyliczona. Dla sieci o małym
natężeniu ruchu, algorytm On-Demand może być
efektywny. Nie ma potrzeby utrzymywania tablic
routingu, więc implementacja jest łatwiejsza, niż w
przypadku algorytmu Pre-Computation. Rozważana jest
także architektura zakładająca przechowywanie tras
wyliczonych dla poprzednich żądań routingu. Dla ruchu
przychodzącego, ścieżka może zostać obliczona tylko
wtedy, gdy nie może być znaleziona w dedykowanym
rejestrze. Jeśli tak będzie, nowa ścieżka jest dodawana
do tego rejestru w celu dalszego użycia. Takie
rozwiązanie stanowi podstawę do dalszej redukcji
kosztów obliczeń i obciążenia zasobów [1][10][2].
5. Działanie protokołu QoSPF na podstawie
zasymulowanego środowiska sieciowego.
Koncepcja routingu Quality of Service objęła
protokół, który miałby być zaimplementowany w
routerach. Nazwany został QoSPF (ang. Quality of
Service Path First). Jest on rozszerzeniem istniejącego,
jednego z najbardziej rozpowszechnionych protokołów
routingu dynamicznego, OSPF (ang. Open Shortest Path
First). Jednym z głównych założeń protokołu QoSPF jest
uzyskanie polepszenia wydajności przepływu dla ruchu
wymagającego zapewnienia parametrów QoS. Uzyskuje
się to poprzez kierowanie danego ruchu najkrótszą trasą
zawierającą odpowiednie zasoby, a ściślej biorąc
przepustowość, by móc sprostać tym wymaganiom. Do
wyliczania ścieżek i dokonywania właściwych decyzji
routingu, używane są wcześniej omówione algorytmy
Pre-Computation oraz On-Demand routing. Protokół
QoSPF należy do klasy Distributed routing. Bazuje na
algorytmie Link State, jako metodzie wymiany
informacji o stanie łącza pomiędzy węzłami (ang. Link
State Advertisements), a także utrzymywania
stosownych tablic routingu. Zawartość tych wiadomości,
w przypadku protokołu QoSPF, została rozszerzona o
informacje dotyczące stanu dostępnej przepustowości i
opóźnienia łącza. QoSPF używa trzech rodzajów
metryk: przepustowość, opóźnienie propagacji i ilość
hopów. Najważniejszą z nich i podstawową dla
protokołu jest metryka oparta o przepustowość.
Opóźnienie propagacji, jako metryka, brane jest pod
uwagę, tylko w przypadku konieczności uniknięcia
użycia łącz np. satelitarnych, nieodpowiednich dla usług
czasu rzeczywistego. Liczba hopów nie jest w swej
istocie metryką Quality of Service, ale uczestniczy w
wyliczaniu kosztu ścieżki [1][11].
wymagania przepustowości.
4.Trzeci ruch – kolor czarny, posiadał rezerwowaną
przepustowość 6 Mbit/s. Transmisja odbywała się przez
sieć ścieżką alternatywną do pozostałych, która wypełnia
wymagania przepustowości. W końcowej części trasy
zagregował się on z ruchem nr 1.
Jako czwarty, był transmitowany przez sieć ruch,
który posiadał rezerwowaną przepustowość 1,5 Mbit/s.
Ponieważ sieć nie posiada już zasobów przepustowości,
by zapewnić mu wymaganą część pasma, był kierowane
ścieżką najkrótszą, zgodnie z działaniem algorytmu
routingu.
Wybór topologii zdeterminowany był możliwością
zestawiania ścieżek równorzędnych pod względem
długości, co umożliwia symulację działania algorytmu
wyboru trasy, ale również posiada wyraźnie zaznaczoną
ścieżkę najkrótszą, by możliwe było przeprowadzenie
obserwacji
ruchu
wymagającego
gwarancji
przepustowości wraz z ruchem typu best-effort. Węzły 04 stanowią źródła generujące ruch pakietów UDP o stałej
wielkości, ze stałą częstotliwością. Węzły 4-12 stanowią
domenę routingu złożoną z 8 routerów. Każdy z nich
posiada implementację mechanizmów routingu Quality
of Service zawartą w ramach protokołu QoSPF.
Posiadają funkcjonalność routerów Quality of Service.
Węzeł 13 stanowi miejsce przeznaczenia dla wszystkich
przepływów generowanych przez w/w. źródła. Ponadto
węzeł nr 4 oraz nr 11 posiada wbudowany monitor
kolejek, pozwalający śledzić rozkład pakietów w
routerze, oraz kolejność ich transmisji. Końcową
topologię sieci, w której przeprowadzona została
symulacja przedstawia rysunek nr 2.
5.1 Przebieg symulacji
Symulacja
planu:
przebiegała
według
następującego
1.Model routingu Quality of Service zestawia sesje
wykorzystane w symulacji, wylicza ścieżki oraz
przedstawia wyniki obliczonych ścieżek w postaci tablic
zawierających informacje na temat adresu źródłowego i
docelowego, numeru identyfikacji przepływu (ang. flow
ID), dokładnej trasy pakietów, rozmiaru rezerwowanej
przez przepływ przepustowości, oraz liczby węzłów
pośredniczących (ang. hop count).
2.Jako pierwsza, została uruchomiona transmisja
pakietów z rezerwowaną przepustowością 4 Mbit/s. Jest
ona oznaczona kolorem czerwonym. Ma to na celu
pokazanie wyboru najkrótszej ścieżki z wymaganą
przepustowością, zgodnie z działaniem algorytmu
routingu.
3.Drugi ruch, który został przetransmitowany
przez sieć, oznaczony kolorem zielonym, posiadał
rezerwowaną przepustowość 0.5 Mbit/s. Został on
przesłany przez sieć podobnie jak przepływ nr 1,
najkrótszą ścieżką (lecz nie tą samą) spełniającą
Rys 2. Topologia sieciowa z zaznaczonymi wartościami
przepustowości pomiędzy węzłami.
Symulacja działania protokołu QoSPF przebiega
przy użyciu modelu zaimplementowanego w środowisku
symulacyjnym NS2. Szczegółowej analizie poddany
został algorytm wyliczania i wyboru ścieżki On-Demand
QoS routing. Do wizualizacji oraz animacji
zasymulowanej sieci użyty został Network Animator
(NAM), który wchodzi w skład symulatora NS2. Wyniki
w postaci wykresów przedstawione są z wykorzystaniem
programu Xgraph.
W trakcie symulacji, zgodnie z jej założeniami,
utworzone zostały 4 sesje z węzła źródłowego n0 do
sieci docelowej n13. Z przedstawionego rysunku można
odczytać informacje o identyfikatorze przepływu (FID),
dokładnej trasie pakietów, jak i wymagań pakietów co do
przepustowości, a także liczbie hopów. Jak pokazano na
rysunku, w trzech przypadkach możliwa była rezerwacja
zasobów, w postaci przepustowości, dla przepływów.
Dla sesji o identyfikatorze FID 4, rezerwacja nie była
możliwa z powodu braku dostępnej przepustowości. Jak
widać, wyliczone ścieżki różnią się od siebie długością.
Wynika to z działania protokołu QoSPF, który, przy ich
wyliczaniu bierze pod uwagę także wymagania
przepływu, co bezpośrednio wpływa na długość ścieżki.
transmitowane jest 2 Mbit/s. W związku z tym, pod
wpływem przeciążenia, jakie powstaje na węźle nr 4, w
wyniku
przepełnienia
kolejki
na
interfejsie
wychodzącym z węzła, pojawiają się odrzucenia
pakietów, co obrazuje przedstawiony niżej rysunek nr 3.
Rys. 3 Obraz odrzuceń pakietów w wyniku przepełnienia
kolejki wyjściowej węzła 4
6. Podsumowanie
Tab. 1. Wykaz sesji utworzonych podczas symulacji
wraz z parametrami
W trakcie symulacji, zgodnie z jej założeniami,
utworzone zostały 4 sesje z węzła źródłowego n0 do
sieci docelowej n13. Z tabeli nr 1 można odczytać
informacje o identyfikatorze przepływu (FID), dokładnej
trasie pakietów, jak i wymagań pakietów co do
przepustowości, a także liczbie hopów. Jak pokazano na
rysunku, w trzech przypadkach możliwa była rezerwacja
zasobów, w postaci przepustowości, dla przepływów.
Dla sesji o identyfikatorze FID 4, rezerwacja nie była
możliwa z powodu braku dostępnej przepustowości. Jak
widać, wyliczone ścieżki różnią się od siebie długością.
Wynika to z działania protokołu QoSPF, który, przy ich
wyliczaniu bierze pod uwagę także wymagania
przepływu, co bezpośrednio wpływa na długość ścieżki.
W przypadku nadejścia żądania routingu dla
przepływu o FID 4, oznaczonego kolorem niebieskim,
sieć nie jest w stanie zapewnić przepływowi
wymaganego pasma. W związku z tym, protokół QoSPF,
zachowuje się w tej sytuacji podobnie do protokołu
OSPF. Ruch zostaje kierowany najkrótszą istniejącą
ścieżką. Pierwszy rysunek przedstawia sytuację, gdy
węzeł 4 radzi sobie jeszcze z obsługą wszystkich
przepływów przechodzących przez niego, nie powodując
odrzuceń pakietów. Widoczny na rysunku monitor
kolejki na routerze 4 wskazuje, ile pakietów oczekuje na
wysłanie. Należy zaznaczyć, że priorytet w transmisji
mają
pakiety,
które
posiadają
rezerwowaną
przepustowość, stąd w ukazanej na rysunku kolejce
przeważa kolor niebieski. Router nr 4 nie jest w stanie
obsłużyć całego ruchu, a więc po agregacji 1,5 Mbit/s +
0.5 Mbit/s, w łączu o przepustowości 0,5Mbit/s
Przeprowadzona symulacja miała za zadanie
przeanalizować koncepcję routingu Quality of Service na
przykładzie implementacji węzła o funkcjonalności
routera QoS oraz protokołu QoSPF w symulatorze NS2.
Model obsługuje dwie metody wyliczania tras i
podejmowania decyzji routingu Pre-Computation oraz
On-Demand. Do analizy wybrana została metoda
routingu na żądanie (ang. On-Demand). Wydaje się on
być bardziej stosowny do wykorzystania w routingu
wewnątrzdomenowym, w niewielkich systemach
autonomicznych (AS) o małym natężeniu ruchu
sieciowego.
Podstawowym atutem symulowanego systemu jest
zapewnienie
jakości
transmisji
przepływom
wymagającym takich gwarancji, poprzez obliczanie
ścieżek z minimalną wartością przepustowości,
umożliwiającą spełnienie tych wymagań. W ten sposób
możliwe jest uzyskanie polepszenia jakości transmisji w
stosunku do istniejących mechanizmów routingu
dynamicznego. Poprawia to także wykorzystanie
zasobów sieciowych mimo że w pewnych przypadkach
prowadzi do wydłużenia trasy pakietów przez sieć.
Wykorzystana
w
symulacji
metoda
On-Demand ukazuje opisane wyżej mechanizmy.
Dodatkowo, działanie tego algorytmu nie powoduje
nadmiernego obciążenia sieci, jak ma to miejsce przy
użyciu metody Pre-Computation, gdy zachodzi
transmisja komunikatów o stanie łącza, ponieważ
informacje te wymieniane są tylko w przypadku
nadejścia żądania routingu. Stwarza to okazję do
wyliczania bardziej efektywnych tras, lecz za cenę czasu
obsługi routingu.
W wyniku przeprowadzonej symulacji, można
wnioskować, że pomimo dużej złożoności obliczeniowej
tego rozwiązania, nie może być ono traktowane jako
koncepcja docelowa. Problemem, który cały czas
pozostaje nierozwiązany, jest brak uwzględnienia
wszystkich parametrów QoS, które powinny zawierać
metryki routingu. Dalszy rozwój koncepcji routingu
Quality of Service zależeć będzie od opracowania
odpowiednio prostych, a zarazem wydajnych
algorytmów dających podstawę do budowy metryk
wielokrotnych, które uwzględniać będą kombinacje
wszystkich parametrów Quality of Service. Nie jest to
zadanie proste, szczególnie jeśli wziąć pod uwagę
realizację tych mechanizmów w trybie On-Demand.
Jednocześnie, warte podkreślenia wydaje się być to, że
liczne propozycje dostępnych w literaturze metryk
wielokrotnych, nie są kompatybilne z istniejącą
architekturą routingu w Internecie, co może stwarzać
poważne problemy wdrożeniowe.
Bardzo intensywnie rozwijaną architekturą,
tworzącą alternatywę dla koncepcji routingu Quality of
Service, jest technologia MPLS (ang. Multiprotocol
Label Switching). Należy jednak podkreslić, iż
obserwując wsparcie dla tej technologii wiodących
producentów sprzętu sieciowego, a także biorąc pod
uwagę trudności ze spełnieniem wszystkich parametrów
jakości usług w routingu Quality of Service,
rozwiązanie, jakim jest MPLS, pomimo swoich wad,
poprzez upowszechnienie oraz względną prostotę
działania, jest w tej chwili rozwiązaniem wiodącym, co
nie oznacza, że zagadnienie routingu QoS nie jest
rozwijane. Kluczowe znaczenie będzie miała możliwość
efektywnego budowania metryk routingu na podstawie
pomiarów stanu rzeczywistego sieci, co jeszcze w chwili
obecnej jest zadaniem stosunkowo trudnym. Jak
wykazały symulacje, koncepcja routingu On-Demand
jest dobrym punktem wyjścia do dalszych badań.
7. Literatura
[1] G. Apostolopoulos, D.Williams, S. Kamat, R. Guerin,
A. Orda, T. Przygienda. QoS Routing Mechanisms and
OSPF extensions, RFC2676, 1999.
[2] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. “A
Framwork for QoS-based Routing in the Internet”,
RFC2386, 1998.
[3] I. Juva. „Analysis of Quality of Service Routing.
Approaches and Algorytms”. Espoo 2003.
[4] P. Paul, S.V. Raghavan. „Survey of QoS Routing”.
2002.
[5] W. Sun. „QoS/Policy/Constraint Based Routing”.
2000.
[6] R.A. Guerin, A. Orda, D.Williams. „QoS Routing
Mechanisms and OSPF Extensions”.
[7] H. Zhu. „Comparison Between Pre-Computation and
On-Demand Computation QoS Routing with Different
Link State Update Algorythms”. Espoo 2003.
[8] A. Orda, A. Sprintson. „Precomputation Schemes for
QoS
Routing”.
IEEE/ACM
Transactions
on
Networking”. August 2003.
[9] A. Shaikh i inni. Efficient precomputation of qualityof-service routes,. July 1998.
[10] S. Vegesna. IP Quality of Service. 2001.
[11] M. Kowalczyk, S. Przyłucki, K. Płachecki. “Rola
Routingu Quality of Service we współczesnych sieciach
pakietowych”. Lublin, LAFI 2005.
[12] www.isi.edu/nsnam/ns/