Maciej Kowalczyk
Marcin Godlewski
Sławomir Przyłucki
Politechnika Lubelska
ul. Nadbystrzycka 38a
20-618 Lublin
maciejk@politechnika.lublin.pl
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.
1. Wstęp
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
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].
2. Metryki
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).
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,
2006
Poznańskie Warsztaty Telekomunikacyjne Poznań 7 - 8 grudnia 2006
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 On-Demand. 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 Pre-Computation 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 Pre-Computation. 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].
5.1 Przebieg symulacji
Symulacja przebiegała według następującego planu:
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ą
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 0-4 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.
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.
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
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
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
quality-of-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.
