Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe

Transkrypt

1 Numer Projektu Badawczego Zamawianego: -MNiSW-02-II/2007 Tytuł projektu: Numer dokumentu: Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe -MNiSW-02-II/2007/PG/A.3 Tytuł raportu: Analiza metod i algorytmów zarządzania zasobami w sieciach Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: 25/06/08 Kierownik zadania: Wykonawcy: Kaczmarek Sylwester Czarkowski M., Kaczmarek S., Narloch M., Żmudziński P. Abstrakt: Raport ten jest omówieniem problemów związanych z metodami i algorytmami zarządzania zasobami w domenie IP z gwarancją zróżnicowanej jakości dla kilku klas usług. Wskazano na istotne zagadnienia z którymi ten problem jest powiązany. Przedstawiono ogólne propozycje scenariuszy realizacji Systemu Zarządzania. Wskazano także uwarunkowania realizacji tego systemu oraz zagadnienia, które wymagają doprecyzowania. Słowa kluczowe: zarządzanie zasobami, domena IP, klasy usług, gwarancje QoS, metody statyczne, metody dynamiczne, optymalizacja

2 Streszczenie Właściwe wykorzystanie zasobów domeny przy jednoczesnej gwarancji zróżnicowanej jakości oferowanej dla klas usług wymaga odpowiednio zorganizowanego zarządzania zasobami na poziomie sieci. Sprowadza się ono do podziału istniejących zasobów między poszczególne klasy tak aby dla określonego stanu zapotrzebowania na obsługę ruchu zużyć jak najmniej zasobów gwarantując jednocześnie jakość dla tych usług. Podział tych zasobów nie jest trywialnym zadaniem, gdy macierz zapotrzebowań zmienia się w czasie. W ramach realizowanego projektu badawczego zadanie A.3 dotyczy tego problemu i obejmuje analizę metod i algorytmów zarządzania zasobami domeny, a w konsekwencji ich podziału i przydziału do klas usług. Do podstawowych zasobów zaliczamy pasmo i pojemność bufora przydzielane dla danej klasy usługi systemu obsługi skojarzonego z każdym portem łącza wyjściowego węzła domeny. Z punktu widzenia realizacji funkcji AC konieczne jest także określenie tych wielkości dla każdej pary węzłów brzeg-brzeg. Wykonanie tego zadania wymaga zidentyfikowania problemu prowadzącego do wyodrębnienia istotnych cech, które mogłyby być uznane za kryteria klasyfikacji na zadania częściowe. Analiza dostępnej literatury przedmiotu doprowadziła do zauważenia faktu, że zarządzanie zasobami dla wcześniej sformułowanego celu jest ulokowane na szeregu wzajemnie powiązanych płaszczyznach funkcjonalnych. To oznacza iż poszukiwanie właściwego rozwiązania jest wielokryterialne. Na sposób rozwiązania i skuteczność zarządzania ma wpływ zatem szereg czynników i tym samym przy analizie należy te czynniki określić i brać pod uwagę. Do podstawowych czynników zaliczono zakres i sposób pozyskiwania informacji niezbędnych do realizacji funkcji zarządzania zasobami. Są to przede wszystkim informacje o: źródłach ruchu obsługiwanych na wejściu do domeny, rozpływie ruchu, klasach usług sieciowych (przenoszenia), modelach systemów obsługi oraz stanach zajętości zasobów. Wartości wielkości ruchowych można pozyskiwać z kontraktów ruchowych lub z pomiarów ruchu w domenie. Także istotnym czynnikiem jest odpowiedniość modeli analitycznych opisu ruchu i rzeczywistych charakterystyk ruchowych. Decyduje ona o potrzebie lub braku wprowadzenia sprzężenia zwrotnego korygującego tą odpowiedniość. Z kolei dynamika zmian ruchu stawia dodatkowe wymagania na system zarządzania jeżeli ma być on skuteczny i nie tylko gwarantować jakość usług ale także optymalizować wykorzystanie zasobów. Mianowicie może to być system o działaniu statycznym lub dynamicznym. Kluczowym problemem dla systemu zarządzania jest znajomość struktury domeny oraz realizowanych dróg połączeniowych i stanu ich zajętości. Tu uwidacznia się uzależnienie pomiędzy systemem zarządzania i funkcją rutingu. Biorąc pod uwagę te wymienione czynniki oraz uwzględniając problem skalowalności wyróżniono cztery obszary w których dokonano analizy metod i algorytmów sterowania zasobami w obrębie domeny. Przeprowadzony podział nie jest i nie może być rozłączny, ponieważ z natury rzeczy metody i algorytmy w nich występujące działają na tych samych obiektach i mają osiągać te same cele. Te obszary to: - metody zarządzania bazujące na informacjach z kontraktów ruchowych, - metody zarządzania bazujące na pomiarach, - metody zarządzania wspierające z założenia przewymiarowanie, 2

3 - metody zarządzania oparte na optymalizacji projektowania lokacji ruchu. W każdym z obszarów rozważań dokonano analizy istotnych algorytmów, określając elementy funkcjonalne i ich lokalizację oraz zasady komunikacji. Omówiono zależności i wielkości konieczne do realizacji danego rozwiązania. Na zakończenie omawiania rozwiązań dla danego obszaru przedstawiono problemy związane z danym rozwiązaniem oraz podano wskazówki dla realizacji w projekcie. Mając tak przeprowadzoną analizę oraz opracowane dane zaproponowano scenariusze realizacji proponowanych rozwiązań. Obejmują one dwa podejścia, jedno w krótszej perspektywie czasowej a drugie w perspektywie produktu końcowego tego projektu badawczego. Takie podejście stopniowego wchodzenia w realizację Systemu Zarządzania jest uzasadnione zdobyciem doświadczenia i wyników mających wskazać rozwiązanie docelowe. Podyktowane to jest także i tym faktem, iż szereg założeń realizacyjnych jest na starcie projektu otwartych i może być sprecyzowane dopiero po pierwszych wynikach dla rozwiązań przejściowych. Ostateczna koncepcja rozwiązania systemu zarządzania jest uzależniona od wybrania rozwiązań zaproponowanych w zadaniu A.2 oraz A.7. Dlatego zauważono zagadnienia, które na tym etapie nie są jeszcze rozstrzygnięte i muszą być przedyskutowane, ustalone i uzgodnione wspólnie z zespołami, które realizują te zadania. Na koniec należy podkreślić, że ostateczna wersja rozwiązania systemu zarządzania będzie współokreślana także przez możliwości sprzętu wykorzystywanego do budowy domeny. Wydaje się, że ten materiał oraz materiał opracowany w ramach pozostałych zadań umożliwi wypracowanie szczegółowych wymagań na realizowany system, które to wymagania będą podzbiorem tu przedstawionych. 3

4 Spis treści STRESZCZENIE CELE I FUNKCJE ZARZĄDZANIA ZASOBAMI WPROWADZENIE MODELE STRUKTURALNO-FUNKCJONALNE ZARZĄDZANIA ZASOBAMI CHARAKTERYSTYKA I OPIS METOD ZARZĄDZANIA OPARTYCH NA KONTRAKTACH RUCHOWYCH OPIS METODY I PROPONOWANE ALGORYTMY WNIOSKI I UWAGI CO DO REALIZACJI W PROJEKCIE CHARAKTERYSTYKA I OPIS METOD ZARZĄDZANIA ZASOBAMI OPARTYCH NA POMIARACH WARSTWOWY MODEL DOMENY DIFFSERV MODEL ZARZĄDZANIA Przydział pierwotny Przydział dynamiczny Weryfikacja jakości WYMAGANIA DOTYCZĄCE RUTINGU I POMIARÓW ZARZĄDZANIE ZASOBAMI BAZUJĄCE NA PRZEWYMIAROWANIU OPIS METODY I PROPONOWANE ALGORYTMY Overprovisioning statyczny Overprovisioning dynamiczny WNIOSKI I UWAGI CO DO REALIZACJI W PROJEKCIE CHARAKTERYSTYKA I OPIS METOD ZARZĄDZANIA OPARTYCH NA PROJEKTOWANIU LOKACJI RUCHU OPIS METODY I PROPONOWANE ALGORYTMY ZALEŻNOŚCI I WIELKOŚCI KONIECZNE DO REALIZACJI WNIOSKI I UWAGI CO DO REALIZACJI W PROJEKCIE WNIOSKI I ZALECENIA DLA PROJEKTU PODSUMOWANIE

5 LITERATURA...43 LISTA SKRÓTÓW

6 1 Cele i funkcje zarządzania zasobami 1.1 Wprowadzenie Cele i funkcje zarządzania wynikają bezpośrednio z definicji zarządzania oraz technologii i architektury sieci której dotyczą. Ponieważ mamy do czynienia z technologią IP wspierającą jakość usług poprzez zastosowanie architektury DiffServ, która być może będzie z kolei wspierana przez technologię MPLS, to zarządzaniu zasobami można przyporządkować ogólny cel sprowadzający się do minimalizacji zasobów koniecznych do obsługi żądań strumieni o różnorodnych wymaganiach jakościowych i różnorodnych charakterystykach ruchowych, które to zasoby zagwarantują te wymagania jakościowe. Zarządzanie zasobami ma obejmować jedną domenę DiffServ, której architektura jest zgodna z odpowiednimi dokumentami RFC. Przyjmuje się wykorzystanie zdefiniowanych w nich mechanizmów i zasad obsługi, które zostaną wykorzystane do świadczenia usług przez domenę na zewnątrz tej domeny. Usługi te są podzielone na klasy. Zakłada się jednoznaczne przyporządkowanie klas usług do mechanizmów architektury DiffServ oraz zasobów dla ich obsługi. Rodzaje zasobów, które mogą podlegać zarządzaniu wynikają także z zastosowanej technologii i architektury. Ich znajomość jest konieczna dla realizacji funkcji przyjmowania żądań obsługi strumieni należących do określonej klasy oraz ustawiania parametrów systemów obsługi w węzłach domeny. System zarządzania realizujący funkcje zarządzania jest elementem, który jest poza domeną i jest z nią połączony łączami komunikacyjnymi dla wymiany informacji. W kierunku od systemu zarządzania do domeny i jej elementów funkcjonalnych przekazywane są, wcześniej przez ten system obliczone, wielkości konieczne dla realizacji przede wszystkim funkcji przyjmowania żądań obsługi nowych strumieni oraz parametrów systemów obsługi. Na ogół realizowana jest także funkcja komunikacji w przeciwną stronę, tzn. od typowych elementów funkcjonalnych domeny DiffServ lub od specjalnych elementów funkcjonalnych umieszczonych w domenie po to aby możliwa była realizacja funkcji zarządzania zasobami dla przyjętej metody i modelu zarządzania. To jakie będą te dodatkowe elementy zależy od tego jakimi zasobami chcemy zarządzać oraz postawionych zarządzaniu celów szczegółowych. Może to na przykład być moduł pomiarowy, który ma dostarczać informacji o stanie zajętości zasobów. Elementami funkcjonalnymi domeny DiffServ są dwa typy ruterów: brzegowe i rdzeniowe oraz łącza dostępowe do domeny i łącza między węzłami (ruterami) domeny. Każdy z ruterów ma specyficzną architekturę funkcjonalną, która dla prawidłowej pracy musi mieć ustawione określone parametry funkcjonalne. Są to między innymi długości kolejek, wagi dla WFQ, parametry dla charakterystyk dopuszczania pakietów do systemu obsługi. Parametry te gwarantują określone cechy poszczególnych PHB. Niezależnie od tego potrzeba gwarancji jakości usług wymaga realizacji funkcji przyjmowania nowych strumieni do obsługi przez domenę. Z kolei dla jej prawidłowej realizacji konieczna jest znajomości pasma dostępnego dla danej klasy usługi oraz modelu opisującego charakter ruchowych tego strumienia. 6

7 System Zarządzania Domena DiffServ Strumienie wejściowe Elementy funkcjonalne: - domeny DiffServ - oraz wspierające zarządzanie. Zarządzane Zasoby Strumienie wyjściowe Rysunek 1-1: Ogólny schemat relacji domena DiffServ a System Zarządzania zasobami Ponieważ z obserwacji wynika iż dynamika zmian ruchu w sieci IP jest znaczna a ilość zasobów w domenie w postaci dostępnego pasma jest ograniczona, to konieczne jest nadążanie z tym dostępnym pasmem za zmianami zapotrzebowania na nie, wynikające właśnie z ograniczenia udostępnianego przez domenę pasma i potrzebę gwarancji jakości usług przy optymalizacji wykorzystania zasobów. Jest to podyktowane koniecznością minimalizacji kosztu usługi. Ta wieloaspektowość funkcji celu powoduje iż w ogólności poprawne i zadawalające rozwiązanie postawionego zadania jest uzależnione od stopnia uwzględnienia wielu czynników wynikających z architektury i stosowanych mechanizmów w płaszczyźnie przenoszenia pakietów (usługi sieciowe), płaszczyźnie sterowania (AC oraz ruting) oraz płaszczyźnie zarządzania (system zarządzania zasobami i jakością) domeny. Istnieje wiele modeli opisujących sposób rozwiązania postawionego zadania, które uwzględniają różny stopień i sposób wzajemnych współzależności wymienionych płaszczyzn. Określenie tego modelu nie jest trywialne i wymaga przeprowadzenia wstępnej analizy rozwiązań a następnie w oparciu o dodatkowe założone kryteria wybór jednego z nich do realizacji i zweryfikowanie na drodze eksperymentalnej. 1.2 Modele strukturalno-funkcjonalne zarządzania zasobami Najogólniej ujmując problem modelu strukturalno-funkcjonalnego systemu zarządzania to można wyróżnić dwa podejścia: statyczne oraz dynamiczne. Pierwsze podejście jest odpowiednie dla w miarę stabilnego profilu ruchu obsługiwanego przez domenę. Ta stabilność dotyczy zarówno ruchu w skali pojedynczych strumieni jak i zagregowanych strumieni. Uwzględniając dodatkowo aspekt stopnia wykorzystania zasobów zakłada się w nim także konieczność wystarczająco dobrej znajomość tych profili ruchu. W przypadku podejścia dynamicznego wychodzimy z założenia, że profile ruchu są zmienne zarówno na poziomie pojedynczych strumieni jak i zagregowanych strumieni. Dodatkowo można założyć iż istnieje trudność dokładnego opisu rzeczywistego ruchu. Mogą tu być dwie podstawowe przyczyny takiego stanu. Jedną jest brak dokładnych z punktu widzenia 7

8 inżynierskiego modeli opisu, drugą to fakt iż występują różnice między tym co może deklarować użytkownik a tym co on faktycznie wygeneruje. W przypadku rozwiązania statycznego system zarządzania jest oparty na projektowaniu przydziału zasobów bazując na modelach typowych dla projektowania sieci. Zakłada się przy tym, podobnie jak dla realizacji funkcji przyjmowania nowych żądań według podejścia DBAC ale w dłuższej skali czasowej, że potrzebne dane otrzymujemy z deklarowanych kontraktów ruchowych. W przypadku trudności określenia dokładnych, z inżynierskiego punktu widzenia, zależności analitycznych między deklarowanymi w kontrakcie parametrami a ilością potrzebnych zasobów wykorzystuje się dodatkowo podejście przewymiarowania przydzielanych zasobów. Oczywiście prowadzi to do mniej efektywnego wykorzystania zasobów ale daje gwarancje jakości. Dla dynamicznego rozwiązania systemu zarządzania zasobami w początkowej fazie także stosuje się projektowanie przydziału zasobów, podobnie jak dla podejścia statystycznego, ale ponieważ nie mamy dokładnych informacji co do profili ruchu to konieczne jest uwzględnienie tego faktu w modelu działania systemu jako całości. Mamy tu sytuację podobną jak w przypadku realizacji funkcji przyjmowania nowych żądań wykorzystującej podejście MBAC, przy czym działanie jest nastawione na średnio- i długookresową skalę czasu. Z uwagi na to istotne zróżnicowanie skal czasowych może zaistnieć, na skutek dużej dynamiki zmian ruchu, rozbieżność działania między obiema funkcjami, tzn. zarządzania zasobami i AC. To może skutkować trudnościami w gwarancji jakości usług. Dlatego aby w takiej sytuacji zapewnić jednak gwarancję jakości usług dopuszcza się przewymiarowanie przydzielanych zasobów. Praktyczna realizacja każdego z wymienionych podejść musi uwzględniać problem skali, który dotyczy zarówno struktury domeny a dokładniej mówiąc jej wielkości i pojemności, jak i napływającego do domeny ruchu. Problem skali przekłada się na skalowalność rozwiązania systemu zarządzania. Z tego też powodu wyróżnia się tu typowo rozwiązania scentralizowane i zdecentralizowane. Każde z nich ma swoje wady i zalety wynikające z potrzeb mocy przetwarzania i problemu komunikacji między poszczególnymi elementami systemu. Nie bez znaczenia jest także uwzględnienie problemu optymalizacji wykorzystania zasobów, który może brać pod uwagę różne kryteria w zależności od postawionego celu oraz zdefiniowanej funkcji optymalizacji. Zatem biorąc pod uwagę wymienione aspekty, które mają istotny wpływ na rozwiązanie systemu zarządzania zasobami domeny, możemy wymienić zbiory cech lub metod, których kombinacje dają nam dopuszczalne rozwiązania. W przypadku Systemu Zarządzania mamy następujący zbiór cech lub metod charakteryzujących ten system: scentralizowany, zdecentralizowany, statyczny, dynamiczny, projektowanie lokacji ruchu, przewymiarowanie, zagadnienie optymalizacji. Dla różnych kombinacji cech i metod z tego zbioru, z których niektóre się wykluczają, możemy otrzymać różne propozycje rozwiązań Systemu Zarządzania. To która z nich może zostać wykorzystana będzie uzależnione od dokładnie sprecyzowanego celu i dodatkowych uwarunkowań nałożonych na realizację tego systemu. 8

9 Aby można było przeprowadzić wybór rozwiązania konieczne jest zatem przeprowadzenie analizy cech, metod i rozwiązań opisanych w dostępnej literaturze przedmiotu. Analiza ta, przedstawiona w kolejnych rozdziałach, zawiera krótką charakterystykę metod i algorytmów zarządzania zasobami takich jak: - statyczne oparte na deklaracjach w kontraktach ruchowych, - dynamiczne oparte na pomiarach, - przewymiarowania zasobów, - projektowania zasobów z uwzględnieniem problemu optymalizacji. 9

10 2 Charakterystyka i opis metod zarządzania opartych na kontraktach ruchowych W celu zapewnienia jakości obsługi (Quality of Service, QoS) ruch w sieci IP musi być precyzyjnie zarządzany. W szczególności dotyczy to natężenia ruchu w danej klasie usług w danym łączu, co przy warunku ściśle określonych zasobów sieci wynikających z: przepływności łączy i topologii sieci, rozwiązań systemu obsługi pakietów (w tym wag przydzielonych różnym klasom usług w systemach obsługi pakietów typu Weighted Fair Queuing (WFQ) i długości buforów, oraz ściśle określonych (i kontrolowanych) dróg połączeniowych (ruting), umożliwia zagwarantowanie jakości obsługi. Oznacza to realizację podstawowego celu funkcji zarządzania zasobami i sterowania ruchem jaką jest zapewnienie gwarancji QoS, przy możliwe jak najpełniejszym wykorzystaniu zasobów sieciowych. To ostatnie zagadnienie stanowi cel dodatkowy, który pozostaje istotny zarówno z punktu widzenia operatora sieci, jak i użytkownika, ponieważ możliwość obsługi z gwarancją QoS jak największej liczby strumieni w sieci o zadanych zasobach oznacza wysokie przychody operatora oraz wpływa na wartości prawdopodobieństwa odrzucenia żądania połączenia - jeden z bardzo wielu elementów opisujących jakość odczuwaną przez użytkownika, tzw. Quality of Experience (QoE). Jak wynika z powyższych rozważań niezwykle istotną rolę w zarządzaniu zasobami gwarantującym jakość obsługi pełni funkcja sterowania przyjęciem zgłoszeń do obsługi (Admission Control, AC) podejmująca decyzję o przyjęciu danego strumienia do obsługi, a w konsekwencji regulująca natężenie ruchu obsługiwanego w sieci (ruch załatwiony). Funkcja AC podejmuje decyzje na podstawie porównania dostępnych zasobów (pasma, pojemności buforów) z zapotrzebowaniem na te zasoby ze strony dotychczas obsługiwanych strumieni oraz nowego żądania, które są opisywane parametrami ruchowymi oraz jakościowymi, ewentualnie biorąc pod uwagę dodatkową informację pochodzącą z obserwacji, pomiarów i analizy pracy systemu. Istotą współpracy systemu zarządzania ruchem z mechanizmem AC jest dostarczanie przez ten system wartości określających pasmo łącza oraz pojemność bufora (zasoby) w ramach których funkcja AC podejmuje opisane powyżej decyzje o przyjęciu/odrzuceniu żądania obsługi. 2.1 Opis metody i proponowane algorytmy W ogólności metody AC należy podzielić na dwie podstawowe klasy: oparte wyłącznie na parametrach z kontraktu ruchowego (Declaration Based AC, DBAC) nazywane także (Parametric Based AC, PBAC), (Traffic Descriptor Based AC, TDBAC) wykorzystujące pomiary (Measurement Based AC, MBAC). Przedstawione w tym rozdziale metody DBAC są oparte wyłącznie na parametrach zawartych w kontrakcie ruchowym dla danego strumienia pakietów. W praktyce stosowania DBAC jedynie na podstawie tych parametrów modelowana jest charakterystyka ruchowa strumienia pakietów, okre- 10

11 ślane jest zapotrzebowanie na zasoby sieci (pasmo łączy oraz bufory w węzłach sieci) i podejmowana decyzja o przyjęciu albo odrzuceniu żądania obsługi. Opis ten oparty jest na parametrach przeznaczonych dla funkcji sprawdzania (kontroli) zgodności z kontraktem ruchowym (traffic policing) realizowanym na brzegu sieci. Typowo stosowany w tym przypadku jest model pojedynczego, lub podwójnego wiadra żetonów. Z konieczności, opis ten jest syntetyczny i nie wszystkie źródła ruchu mogą być przez takie modele dokładnie opisywane. Ponadto, dokładne określenie wartości parametrów opisujących źródła w takich modelach może stanowić problem, który prowadzi do niedoszacowania parametrów ruchowych w kontrakcie (niekoniecznie celowego, czy świadomego), a w konsekwencji narażenie się na skutki działania funkcji kontroli zgodności z kontraktem ruchowym w skrajnym przypadku tożsamym z odrzucaniem, stratą pakietów określonych w wyniku działania algorytmu na brzegu sieci jako niezgodne z warunkami kontraktu. Z drugiej strony, sytuacja w której użytkownicy (źródła) deklarują wartości parametrów ruchowych w sposób przeszacowany z zapasem dla zapewnienia marginesu błędu także nie jest korzystna. W szczególności prowadzi ona do nadmiarowej rezerwacji zasobów w całej sieci, przy jednoczesnym znaczącym ich niewykorzystaniu, z racji opierania się w obliczeniach zapotrzebowania na zasoby sieciowe przede wszystkim pasmo łączy - wyłącznie na przeszacowanych parametrach. W przypadku braku pomiarów, czyli braku odniesienia się do rzeczywistego obciążenia łączy w sieci na zasadzie sterowania ze sprzężeniem zwrotnym, metody zarządzania ruchem nakierowane na rozwiązania wykorzystujące wyłącznie parametry ruchowe mogą ostatecznie prowadzić do małego wykorzystana zasobów sieciowych. Taka sytuacja jest niekorzystna z punktu widzenia jednego z kluczowych celów funkcji zarządzania ruchem jakim jest zapewnienie możliwie wysokiego poziomu wykorzystania zasobów sieciowych z jednoczesnym zapewnieniem gwarancji jakości usługi. Algorytmy DBAC można podzielić na dwie podstawowe grupy deterministyczne i statystyczne. Do metod deterministycznych należy zaliczyć metody oparte na: analizie najgorszego przypadku wykorzystywane jest podejście wywodzące się z analizy gwarancji jakościowych w sieci Integrated Services (brak strat pakietów, najmniej korzystny schemat napływu pakietów i skupienie się jedynie na górnej wartości ograniczenia opóźnienia pakietów od końca do końca sieci) [Cha00], podejście to jest stosunkowo trudne do zastosowania praktycznie i jednocześnie nie zapewniające odpowiedniego poziomu wykorzystania zasobów; alokacji w oparciu o wartość szczytową (peak rate allocation, PRA) wykorzystuje wyłącznie pojedynczy parametr opisujący źródło ruchu, wartość szczytową PR szybkości bitowej strumienia. Z oczywistych względów metoda ta jest stosowana dla strumieni o charakterystyce CBR (wraz z wnioskami wypływającymi z koncepcji pomijalnego jittera) [Rob96]. Niezależnie od tego, metodę tą można zastosować do dowolnej klasy strumieni, także o zmiennej szybkości bitowej (VBR) uzyskując wysoki poziom gwarancji jakości obsługi oraz uproszczenie procedury AC, kosztem znacznie zmniejszonego wykorzystania sieci. W tej metodzie określenie wypadkowego pasma dla agregacji strumieni jest bardzo proste: B PA () = N PA PR i i= 1 ρ PA. Rów

12 Tabela 2-1: Parametry DBAC dla alokacji PA Parametr PR i N PA Opis parametru Maksymalna szybkość bitowa i-tego strumienia Liczba strumieni (włączając przyjmowany) w ramach danej agregacji strumieni z PA ρ PA Maksymalne dopuszczalne obciążenie w ramach pasma przydzielonego agregacji strumieni z PA Parametr ρ PA pozwala na powiązanie decyzji o przyjęciu zgłoszenia do obsługi z określeniem parametrów QoS dla strumieni. Wykorzystując aproksymację dużego obciążenia (ρ 1) systemu M/D/1 [Rob96] można określić: ρ PA = 2B PA 2BPA ln( P loss ). Rów. 2-2 gdzie P loss to parametr określający gwarancje jakościowe prawdopodobieństwo straty pakietu, natomiast B PA to bufor obsługujący agregację strumieni PA. Ten ostatni parametr może zostać określony na podstawie wymagań na opóźnienie strumieni obsługiwanych w danym buforze. Metody statystyczne wykorzystują cechy źródeł ruchu (np. charakterystyka VBR), wymagania jakościowe oraz odpowiednie dla danego rodzaju ruchu modele multipleksacji. Przyjęcie danego modelu multipleksacji, silnie uzależnione jest od rodzaju wymagań jakościowych uwzględniających zależności czasowe (opóźnienie, zmienność opóźnienia) danej usługi. Z tego ostatniego punktu widzenia wyróżniamy podział na usługi należące do klasy real-time, związane ze źródłami ruchu strumieniowego (stream traffic), ponieważ stawiają one ścisłe wymagania na opóźnienie i zmienność opóźnienia wprowadzane przez sieć, usługi należące do klasy non-real time, związane ze źródłami ruchu elastycznego (elastic traffic), nie mające ścisłych wymagań na opóźnienie i na zmienność opóźnienia wprowadzane przez sieć. W zależności od przynależności usługi do danej klasy w analizie zapotrzebowania na współużywalne zasoby wykorzystujemy jedną z dwóch koncepcji multipleksacji statystycznej: multipleksacja z zachowaniem obwiedni przepływności (REM - Rate Envelope Multiplexing), multipleksacja z podziałem przepływności (RSM - Rate Sharing Multiplexing). Szczegółowy opis źródeł oraz dokładny opis dwóch rodzajów multipleksacji statystycznej znajduje się w raporcie A.2 i w związku z tym nie będzie tu przytaczany. Z punktu widzenia zarządzania zasobami należy jednakże podkreślić, że w przypadku multipleksacji REM pojemność istniejącego w każdym węźle sieci pakietowej rzeczywistego bufora nie jest uwzględniana w decyzjach AC i pozostaje parametrem swobodnym w kontekście określania wymagań na opóźnienia od końca do 12

13 końca. W przypadku multipleksacji RSM taka swoboda nie jest możliwa parametr pojemności bufora odgrywa ważną rolę w analizie takiego systemu. W raporcie A.2 wymienione i opisane zostały dwie podstawowe klasy statystycznych algorytmów DBAC: oparte na obliczaniu prawdopodobieństwa strat, oparte na koncepcji pasma efektywnego. Należy podkreślić, że z punktu widzenia praktycznego zarządzania zasobami, atrakcyjniejsza wydaje się charakteryzacja strumieni w oparciu o koncepcję pasma efektywnego. W literaturze proponowanych jest wiele metod (o różnym stopniu przydatności praktycznej) określania tej wielkości dla różnych rodzajów multipleksacji: pasmo efektywne dla REM, określenie pasma efektywnego wykorzystujące aproksymację gaussowską [Gue91], określenie pasma efektywnego wykorzystujące efektywną wariancję [Kal94], określenie pasma efektywnego wykorzystujące prostą formułę aproksymującą [Bri98], określenie pasma efektywnego wykorzystujące twierdzenie Czernowa [Kel91], określenie pasma efektywnego wykorzystujące zależność wielomianową [Vil96], pasmo efektywne dla RSM, addytywne pasmo efektywne [Gue91], określenie pasma efektywnego oparte na Teorii Wielkich Odchyleń, Large Deviations Theory [Kes93], metoda dyfuzyjna [Gel97], pasmo efektywne w ujęciu alternatywnym (metoda EMW) [Elw95]. Osobnym, ale równie ważnym zagadnieniem pozostaje problem oszacowania zapotrzebowania na zasoby dla strumieni ruchu elastycznego TCP z racji ich tradycyjnego znaczenia oraz dominującego wolumenu w sieciach IP. Interesujące rozwiązania tego problemu dla źródeł TCP typu zachłannego i niezachłannego można znaleźć w dokumentach wynikowych projektu Aquila i EuQoS, m. in. [Sal03]. Jako podsumowanie metod określania zapotrzebowania na zasoby w oparciu o metody DBAC, należy przedstawić zaproponowaną w projekcie Aquila w ramach systemu zarządzania ruchem i zasobami koncepcję uogólnionego AC dla strumienia, osobno dla każdego łącza pomiędzy węzłem brzegowym i rdzeniem oraz dla łączy w rdzeniu sieci [Sal03]. W przypadku łączy od węzła brzegowego do rdzenia uogólniony schemat AC uwzględnia ograniczenia wynikające z QoS: 13

14 x2 ( ) x1 B2 B1 () + C Rów. 2-3 w low 2 ( ) x3 w3 x1 x2 B3 () C R1 () R2 () Rów. 2-4 w low ( ) x4 w4 x1 x2 B4 () C R1 () R2 () Rów. 2-5 w oraz ograniczenia wynikające z gwarancji minimalnego pasma dla danej klasy ruchu: ( G2 ) C x2 x1 max B2 ( () ) ( ), B, G + max 1 1 Rów. 2-6 w 2 max x3 w3 x1 ( B (), G ) C max R () x2 ( (, G ) max( R () G ) Rów , wlow 2 max x3 w3 x1 ( B (), G ) C max R () x2 ( (, G ) max( R () G ) Rów , wlow W powyższych wzorach B i xi ( ) określa wymagania na pasmo dla i-tej klasy usług przenoszenia określonej na podstawie jednej z metod AC: alokacja na wartość szczytową, pasmo efektywne dla DBAC albo pasmo efektywne dla MBAC, natomiast R i xi ( ) określa natężenie ruchu generowane przez i-tą klasę, zaś G i minimalne gwarantowane pasmo dla i-tej klasy. Pomimo sformułowania uogólnione w powyższych wzorach widoczny jest silny związek wyrażeń określających warunki AC z konkretnym rozwiązaniem systemu obsługi pakietów w tym przypadku będącym dwupoziomowy system obsługi złożonym z mechanizmu Priority Queuing (PQ) oraz WFQ, wag systemu WFQ wynikających z wzajemnego wpływu różnych klas ruchu obsługiwanych w tym samym łączu. Z drugiej strony schemat ten umożliwia szeroko rozumianą uniwersalność doboru metod określania pasma danej klasy. W przypadku łączy w rdzeniu sieci strumień może zostać przyjęty do obsługi jeżeli spełnione są warunki, których całkowitą liczbę określa liczba obsługiwanych klas usług z QoS, np. 4: T xi i () Li Rów

15 gdzie T i xi ( ) określa natężenie ruchu w danej klasie - np. tożsame z R i xi ( ) natomiast L i, określa limit (próg) dla i-tej klasy, tzw. limit AC. Należy podkreślić, że obciążenie rdzenia jest wynikiem decyzji podejmowanych lokalnie w ruterze brzegowym. Oznacza to, że warunkiem przyjęcia strumienia do obsługi jest pozytywna decyzja AC w ramach przydzielonego limitu zasobów (pasma) dla danego systemu brzegowego (ruter i zarządzający agent) przez scentralizowany system Bandwith Brokera (Resource Control Agent w terminologii projektu Aquila). Specyfiką przyjętego rozwiązania jest wymaganie dwóch pozytywnych decyzji AC, zarówno na łączu pomiędzy wejściowym ruterem brzegowym a rdzeniem oraz a łączu pomiędzy rdzeniem a wyjściowym ruterem brzegowym. Przydział zasobów (rozumianych jako pojedynczy zasób - pasmo) opiera się na hierarchcznym systemie zasobów (opis grafem drzewiastym) w którym ewentualna obecność podsieci wprowadza więcej niż jeden poziom liści. Limity dla AC mogą być zmieniane w trakcie pracy (zwiększane gdy jest przekroczony próg, a niewykorzystane zmniejszane i przydzielane innym agentom Admission Control Agent (ACA). W projekcie została opracowana procedura początkowego przydziału zasobów. Wymagana ona znajomości: topologii, dostępnych zasobów, rodzaju rutingu (statyczny, dynamiczny zmiany tras, np. w wyniku działania OSPF wymagają ponownej rekalkulacji przydziału zasobów), rozpływu ruchu. Ostatecznie procedura przydziału zasobów pozwala na określenie maksymalnego natężenia ruchu danej klasy (usługi przenoszenia) w każdym łączu rdzenia (!!!) oraz limitów dla AC dla danej klasy na potrzeby ACA. W ogólności procedura składa się z następujących kroków: 1. Estymacja ruchu określenie ułamkowego udziału ruchu wpływającego do domeny z danego węzła brzegowego (Edge Device, ED) w całości ruchu w domenie w danej klasie oraz rozdział (ułamkowy) ruchu danej klasy z wejściowego ED do wyjściowych ED. 2. Podział przepływności poszczególnych łączy rdzenia na klasy. 3. Przydział pasma operacja ta wymaga znajomości rozpływu ruchu i pozwala znaleźć łącze będące wąskim gardłem oraz ograniczenie na maksymalne natężenie ruchu danej klasy. W systemie proponowana jest heurystyka pozwalająca zwiększyć ruch z ED oraz klas nie obciążających wąskiego gardła, co prowadzi do poszukiwania kolejnych wąskich gardeł dla innych ED oraz klas i stopniowego ich wyłączenie ze zwiększania natężenia ruchu. 4. Budowanie drzewiastej hierarchii zasobów. Rozszerzeniem tej procedury jest procedura oparta na pomiarach ruchowych. 2.2 Wnioski i uwagi co do realizacji w projekcie Wykorzystanie metod zarządzania zasobami w sieciach w oparciu o kontrakt ruchowy niesie zarówno korzyści, jak i wiąże się z pewnymi wadami. Do tych ostatnich należą: 15

16 wymóg znajomości a priori parametrów ruchowych strumienia - szczególnie w przypadku parametru przeciętnej szybkości bitowej Sustainable Rate (SR) i parametru BSS (Burst Size) - pojemności wiadra żetonów dla kontroli SR): jest bardzo kłopotliwe do określenia dla użytkownika, ponadto ruch z niektórych aplikacji nie zawsze może być w ten sposób opisany, rzeczywisty stan zasobów w sieci znany jest z dokładnością oferowaną przez przyjęty (przybliżony) model multipleksacji, opracowywany zazwyczaj dla jednej klasy usług bez określania wzajemnego wpływu różnych klas usług w rzeczywistych systemach obsługi; rezerwacje dokonywane w oparciu o takie podejście mogą być zachowawcze, co wiążę się z niedostatecznym wykorzystaniem dostępnych zasobów. Korzyści z wykorzystania metod opartych na kontrakcie ruchowym to przede wszystkim: otwarta pętla sterowania - decyzja o przyjęciu zgłoszenia do obsługi i związana z tym alokacja zasobów jest jednorazowa i wiąże się z wymianą informacji wyłącznie w warstwie sterowania, wykorzystanie wyłącznie parametrów zawartych w deskryptorze ruchowym z kontraktu ruchowego (SLS), stosowanych dla algorytmu token bucket (pojedynczego, podwójnego) zależnie od klasy, brak konieczności organizacji pomiarów (mniejsze wymagania na funkcjonalność węzłów w zakresie pomiarów, mniejsze obciążenie sterowania węzłów pomiarami, wymianą danych pomiarowych), albo realizacja pomiarów ruchowych wyłącznie na potrzeby zarządzania zasobami (w dłuższej skali czasu, niż skala połączeń). Na podstawie przeprowadzonej analizy można sformułować następujące wnioski i zalecenia dla projektu związane z zarządzaniem zasobami w sieciach w oparciu o kontrakt ruchowy: Radykalnym rozwiązaniem problemu prawidłowego określenia wartości parametrów SR i BSS może być wykorzystanie jedynie wartości szczytowej PR oraz parametru PRT (tolerancji PR) - opis na potrzeby algorytmu pojedynczego wiadra żetonów jako metody kontroli zgodności na brzegu sieci; Przyjęcie uproszczonego modelu opisu ruchowego strumienia pakietów skutkuje uproszczeniem modelu multipleksacji i możliwych do wykorzystania metod; Z punktu widzenia zarządzania zasobami opis ruchowy strumienia ograniczony do maksymalnej szybkości bitowej strumienia pozwala na przyjęcie prostszych modeli alokacji pasma, szczególnie w rdzeniu sieci na potrzeby obsługi agregacji strumieni; Dla strumieni o charakterystyce ruchowej innej niż CBR, opis z wykorzystaniem parametrów pojedynczego wiadra żetonów oznacza deklarację zachowawczą, z wymienionym powyżej skutkiem niedostatecznego wykorzystania zasobów; należy podkreślić, że jedno- 16

17 cześnie zapewnia margines bezpieczeństwa dla realizacji gwarancji QoS, np. w przypadku zastosowania uproszczonych metod zarządzania zasobami; Zarządzanie zasobami wykorzystujące alokację pasma w oparciu o wartość maksymalną powinno zostać dodatkowo wsparte pomiarami wykorzystania zasobów (pasma). 17

18 3 Charakterystyka i opis metod zarządzania zasobami opartych na pomiarach Zarządzanie zasobami w domenie jest kluczową funkcją zapewniającą efektywne i ekonomiczne wykorzystanie zasobów przez operatora. Powszechnie wykorzystywana sieć IP BE funkcjonuje jako zbiór autonomicznych węzłów i jest klasycznym przykładem sterowania rozproszonego. Każdy węzeł posiada informacje o lokalnym obciążeniu procesora i łączy w kierunku sąsiedniego węzła. Brak jest natomiast jakichkolwiek informacji o obciążeniu pozostałych zasobów obsługujących pakiety tego samego strumienia. Ponieważ sieć IP miała być możliwie prosta, nie występują w klasycznej architekturze mechanizmy sterowania i zarządzania na skalę większą niż lokalna. Siec DiffServ zakłada zmianę obsługi pakietów w węzłach, zamiast FIFO zaproponowano PQ czy WFQ. Z punktu widzenia sieci nadal ruter pozostał jednostką autonomicznie sterowaną bez możliwości zarządzania zasobami czy zarządzania jakością z perspektywy połączeń end-to-end. Wprowadzenie płaszczyzny zarządzania zasobami na poziomie domeny wpłynie istotnie na zwiększenie wykorzystania zasobów. Nadto, płaszczyzna ta może realizować funkcje zarządzania jakością. W pierwszym podejściu będzie ona sprawdzać analitycznie czy określone parametry usług mieszczą się w założonych przedziałach. W rozdziale 3.1 scharakteryzowany będzie model warstwowy domeny, następnie w 3.2 przedstawiony zostanie model zarządzania, a w rozdziale 3.3 zarządzanie jakością. Zagadnienia sterowania strumieniami pakietów, ze szczególnym uwzględnieniem metod AC, są omówione w raporcie A.2 i ich znajomość jest potrzebna dla zrozumienia omawianych w tym rozdziale problemów. 3.1 Warstwowy model domeny DiffServ Proponowana tu budowa domeny jest rozwinięciem płaskiej koncepcji domeny DiffServ, podanej w RFC2475. W projekcie wykorzystany zostanie model domeny złożony z dwóch warstw [Ter99], [Bou05]: warstwy przekazywania pakietów i warstwy sterowania (Rysunek 3-1). W celu realizacji funkcji zarządzania zasobami oraz zarządzania jakością (QM Quality Management) niezbędne jest także wprowadzenie płaszczyzny zarządzania, komunikującej się z obiektami wymienionych płaszczyzn. W warstwie przekazywania pakietów zlokalizowane są rutery brzegowe (RB) i rutery rdzeniowe (RR). Mechanizmy i ich funkcje zdefiniowane zostały w RFC2475 oraz kolejnych dokumentach. Warstwa sterowania składa się z obiektów MSA agenta zarządcy systemu. Funkcje MSA można w pierwszym przybliżeniu scharakteryzować jako: obsługa komunikacji z użytkownikiem w celu odbierania żądań do obsługi, realizacja autoryzacji użytkowników oraz uwierzytelnienia SLA napływających żądań (AAA), realizacja AC według przyjętej w domenie metody, 18

19 przekazywanie do systemu operacyjnego węzła parametrów konfiguracyjnych, niezbędnych do prawidłowej klasyfikacji, znakowania oraz kształtowania ruchu należącego do nowo przyjętego strumienia, komunikacja z płaszczyzną zarządzania w przypadku braku wystarczających zasobów do realizacji otrzymanego żądania, utrzymanie lokalnej bazy użytkowników zsynchronizowanej z bazą w systemie zarządzającym MS, komunikacja z MS w celu przesłania wykorzystania pasma wszystkich ścieżek end-to-end. Ze względu na relatywnie proste funkcjonalności, MSA może być aplikacją uruchomioną w systemie operacyjnym RB. Główne zadanie MSA polega na podejmowaniu autonomicznych decyzji o przyjęciu do obsługi nowego strumienia [Chu00]. Zgodnie z wnioskiem z raportu A.2, AC realizowany jest na podstawie deklarowanych przez użytkownika parametrów: PRB (Peak Bit Rate), PBRT (Peak Bit Rate Tolerance). Dla żądanej klasy ruchu, MSA wyznacza pasmo efektywne obsługiwanego strumienia zagregowanego oraz nowego strumienia [Kac05]. Następnie sprawdzana jest dostępność pasma ścieżki end-to-end dla danej klasy ruchu (Tabela na Rysunku 3-1). Podsieci docelowe EF AF BE pasmo wolne pasmo wolne pasmo wolne A / B / C / MS MSA1 MSA3 RB MA MSA2 7 MA RR MA RB MSA4 Użytkownik A req RB MA MA RB req Użytkownik B Rysunek 3-1: Warstwowy model domeny DiffServ 19

20 Dla uproszczenia sterowania można przyjąć, że każdy z MSA lokuje zasoby symetrycznie, jednocześnie w obu kierunkach między brzegami sieci. Jednakże bardziej efektywne rozwiązanie polega na lokowaniu zasobów na ścieżkach jednokierunkowych w kierunku ujścia strumienia. Informacje o zasobach ścieżki w przeciwnym kierunku posiada zdalny MSA. Podczas realizacji funkcji AC niezbędne jest sprawdzenie dostępności zasobów na ścieżkach w obu kierunkach. W tym celu lokalny MSA, z punktu widzenia użytkownika MSA, powinien wysłać zapytanie do zdalnego MSA o dostępność zasobów ścieżki od zdalnego do lokalnego MSA. Widać zatem, że niezbędny jest algorytm postępowania oraz protokół komunikacji między obiektami MSA. Ponieważ proces sterowania w sieci telekomunikacyjnej musi odbywać się szybko aby reagować na zmianę warunków ruchowych w sieci, obiekty MSA posiadają relatywnie prostą funkcjonalność. Aby domena świadczyła usługi przenoszenia (sieciowe) z QoS, niezbędne jest wprowadzenie dodatkowej płaszczyzny dla realizacji funkcji sterowania. Zarządzanie zasobami domeny polega na przydziale lub odbieraniu pasma do ścieżek end-to-end oraz na przydziale buforów do kolejek skojarzonych z łączami wyjściowymi, obsługującymi poszczególne klasy ruchu. Zarządzanie siecią jest zadaniem skomplikowanym ze względu na: autonomiczność rutingu w warstwie przekazywania pakietów, konieczność prowadzenia pomiarów wykorzystania wszystkich łączy międzywęzłowych, konieczność ścisłych gwarancji dla usług w sytuacji współdzielenia łączy przez ruch: EF, AF i BE, skomplikowane zależności numeryczne wzorów analitycznych. Mając na uwadze funkcje płaszczyzny sterowania, zaproponowano realizację płaszczyzny zarządzania w postaci systemu zarządzania (MS) oraz agentów pomiarowych (MA). W pierwszym podejściu MS powinien zostać zrealizowany w sposób centralny. Ponieważ zarządzanie zasobami odbywa się w średnio- lub długo-okresowej skali czasu, centralizacja MS nie stanowi zagrożenia dla skalowalności domeny. W każdym z ruterów domeny proponuje się umieszczenie agenta pomiarowego MA dokonującego pomiarów i dostarczania wyników do MS. Wyniki pomiarów stanowić będą dane wejściowe dla algorytmów zarządzania zasobami. Główne zadania MS to: zbieranie od MA danych pomiarowych o wykorzystaniu łączy międzywęzłowych oraz bieżące wykorzystanie przydzielonego pasma dla każdej ze ścieżek, budowanie tablicy topologii sieci na podstawie informacji o rutingu, który realizowany jest autonomicznie przez rutery domeny zgodnie z protokołem wspierającym QoS, np. QoSPF; więcej informacji o rutingu QoS dostępne jest w raporcie A.7, rekalkulacja oraz przydział pasma dla konkretnych klas ruchu na ścieżkach end-to-end, realizacja zarządzania jakością (QM) dla poszczególnych ścieżek end-to-end, utrzymywanie i zarządzanie centralną bazą użytkowników oraz ich SLA, dystrybucja i uaktualnienie fragmentów bazy użytkowników dołączonych do poszczególnych RB, 20

21 wprowadzanie nowych lub korygowanie istniejących klas obsługi ruchu przez zmianę konfiguracji ruterów RB i RR, np. zmianę parametrów PHB (Per-Hop Behaviour). 3.2 Model zarządzania Uwzględniając wnioski z raportu A.2, w projekcie przyjęto założenie, że domena będzie obsługiwała cztery typy aplikacji: VoIP, gry interaktywne, wideo na żądanie oraz aplikacje bez gwarancji. Z punktu widzenia inżynierii ruchu niezbędne będzie wprowadzenie trzech klas obsługi ruchu, oznaczone zgodnie z DiffServ: EF, AF i BE oraz przydzielenie strumieni generowanych przez te aplikacje do jednej z klas. Zarządzanie pasmem można rozdzielić na dwa etapy: przydział pierwotny i dynamiczne zarządzenie zasobami i jakością Przydział pierwotny Na etapie projektowania domeny przydzielone zostanie pierwotne pasmo dla każdej ze ścieżek endto-end. Można dokonać tego na podstawie prognozy operatora lub algorytmem przydziału proporcjonalnego, zaproponowanego w dalszej części tego raportu. Sprawnie funkcjonująca płaszczyzna zarządzania skoryguje pierwotny przydział zasobów jako odpowiedź na zmianę macierzy zainteresowań. Pomiary ruchu stanowią zatem pętlę sprzężenia zwrotnego sterowania. 1. Niech sieć składa się z N węzłów ponumerowanych od 1 do N; w skład domeny wchodzi Z ruterów brzegowych ponumerowanych od 1 do Z oraz N Z ruterów rdzeniowych ponumerowanych od Z+1 do N (Rysunek 3-2). 2. Niech domena składa się z L łączy jednokierunkowych. 3. Niech początkowy podział na klasy ruchu będzie dany współczynnikami a EF, a AF, a BE; a EF + a AF + a BE =1. 4. Utworzyć macierz kolumnową C=[c l, l {1,,L}] zwierającą pojemności wszystkich łączy międzywęzłowych. 5. Na podstawie znajomości działania OSPF oraz wag wynikających z przepustowości łączy, utworzyć trójwymiarową macierz dróg D [d ijk, i,j {1,,Z}, k {1,,L}]; każdy z elementów macierzy przechowuje numer łącza; wektor D[1,3] jest zatem ciągiem numerów kolejnych łączy na ścieżce między brzegami czyli między RB1 i RB3. 6. Utworzyć macierz kolumnową H[h i, i {1,,L}]; każdy z jej elementów będzie liczbą wystąpień indeksu łącza w macierzy D, co oznacza liczbę dróg end-to-end między brzegami domeny, które korzystają z i-tego łącza. 7. Utworzyć macierze pomocnicze P EF [p EFijk, i,j {1,,Z}, k {1,,L}], P AF [p AFijk, i,j {1,,Z}, k {1,,L}], P BE [p ijk, i,j {1,,Z}, k {1,,L}]; pasmo między kolejnymi węzłami ścieżki wyznaczone będzie następująco: jeśli element d ijk =4, to p EFijk = c 4 / h 4 *a EF. 8. Utworzyć macierze C EF [c EFij, i,j {1,,Z}], C AF [c AFij, i,j {1,,Z}], C BE [c BEij, i,j {1,,Z}] zawierające pasmo dla każdej ścieżki end-to-end, danej klasy ruchu. Każdy element macierzy C np. c AFij oznacza minimum wartości wektora p AFij. Wynikiem proponowanego algorytmu jest przydział pasma początkowego do każdej ze ścieżek end-to-end. Z chwilą wprowadzenia ruchu użytkowego, MSA przyjmując kolejne strumienie do obsługi będą zajmowały pierwotnie przydzielone pasmo. 21

22 3.2.2 Przydział dynamiczny W trakcie działania domeny, zapotrzebowanie na pasmo na ścieżkach ulega zmianie z powodu zmiany macierzy zainteresowań. Sterowanie przyjmowaniem do obsługi po zajęciu całego dostępnego pasma ścieżki odrzuca kolejne zgłoszenia i jednocześnie wysyła do MS żądania przyznania dodatkowych zasobów w postaci pasma. Aby zmniejszyć liczbę komunikatów sygnalizacyjnych między MS i podległymi MSA można zaproponować dwa tryby pracy: normalny i krytyczny. W pierwszym z wymienionych, zarządca przyznaje agentowi porcję pasma zwaną quotą [Pie06], [Zha01]. Wielkość quoty jest ustalona administracyjnie dla całej domeny, jednak powinna być tak dobrana, aby przekraczać kilkukrotnie typowe zapotrzebowanie klienta. Kolejne zgłoszenie do tego samego MSA będą obsłużone bez komunikacji z MS. Przy ustalonym stanie sieci właściwy dobór quoty powoduje powstanie pętli histerezy zmniejszając tym samym liczbę stanów żądań dodatkowego pasma oraz żądań zwrotu pasma. Wybór zbyt małej quoty skutkuje częstymi żądaniami przydziału dodatkowego pasma, wysyłanymi przez MSA. Jeśli natomiast quota jest znacznie większa od typowego zapotrzebowania na pasmo, może powodować mniejsze wykorzystanie zasobów domeny i zbyt szybkie przejście MS w tryb krytyczny. RB1 RB2 RB 1 L1, L2 RR 8 L5, L6 RR 4 L3, L4 L7, L8 RR 5 RR7 L11, L12 L9, L10 L18, L19 RR6 L13, L14 L16, L17 RB 3 RB1 RB3 RB2 RB3 RB 2 Rysunek 3-2: Oznaczenia stosowane w algorytmie Drugim parametrem podlegającym dostrojeniu jest opóźnienie rekalkulacji. Zarządzanie jest procesem długookresowym, zatem MS powinien realizować tą funkcję po przekroczeniu progu liczby żądań przydziału pasma na ścieżkę. Opóźnienie rekalkulacji z jednej strony zmniejsza szansę na zdestabilizowanie sieci, z drugiej strony możliwe jest wyznaczenie ścieżki tracącej więcej zgłoszeń i dodatnie zasobów na tej ścieżce w pierwszej kolejności. Schemat blokowy algorytmu przydziału pasma podany jest na Rysunku 3-3. W trybie krytycznym MS powinien przyznawać zasoby zgodnie z żądaniem MSA. Przejście w tryb krytyczny następuję, gdy na jednym z łączy sieci brakuje pasma o wielkości quoty ze względu na duże obciążenie. Od tego momentu MS dla wszystkich ścieżek korzystających z nasyconego łącza MS realizuje zarządzanie krytyczne, czyli przyznaje pasmo dokładnie żądane. Przejście z powrotem do trybu normalnego odbywa się na podstawie analizy wyników pomiarowych dokonywanych przez funkcję zarządcy. 22

23 Ponieważ MS posiadając pełną wiedzę o sytuacji ruchowej sieci, oblicza czy dla żądanej usługi nie przekroczono maksymalnego wysycenia łączy składowych oraz czy na każdym łączu ścieżki istnieje wolne pasmo. Jeśli oba warunki są spełnione, MS sprawdza jakość usługi wprowadzając jako dane wejściowe do obliczeń nowy przydział zasobów. Jeżeli nowy przydział zasobów nadal zapewnia gwarancje QoS dla danej klasy, MS przyznaje quotę pasma na żądanym kierunku. Podobne obliczenia są realizowane w trybie krytycznym, z tą różnicą, że MS przyznaje zasoby adekwatne do żądania Weryfikacja jakości Ostatnią fazą dynamicznego przydziału zasobów jest weryfikacja jakości (QC - Quality Check) usług świadczonych przez domenę. MS powinien sprawdzić, czy dodanie zasobów do konkretnej ścieżki zapewni wymaganą jakość dla danej ścieżki oraz wymaganą jakość dla pozostałych ścieżek korzystających z tych dodanych zasobów fizycznych. Funkcja weryfikacji jakości stanowi sprzężenie zwrotne dla zarządzania zasobami. Poprawna realizacja QC wymaga dostarczenia do algorytmu obliczeniowego wyników pomiarów obciążenia dla każdej z klas ruchu fizycznego łącza międzywęzłowego. Celem QC jest nadrzędny wymóg spełniania SLA przez domenę, nawet kosztem mniejszego wykorzystania sieci. Może się zatem okazać, że QC zmniejszy sumaryczną ilość ruchu dopuszczonego przez MS do przenoszenia przez domenę. Weryfikacja jakości jest zadaniem skomplikowanym i złożonym obliczeniowo. Trudności w opracowaniu skutecznego i wydajnego algorytmu QC spowodowane są: brakiem dostatecznie prostych i przystających do rzeczywistości modeli ruchowych, koniecznością analizy trzech parametrów QoS dla ścieżki end-to-end, koniecznością analizy wpływu zmiany obciążenia klasy na łączu na wszystkie inne ścieżki korzystające z tego łącza fizycznego; w praktyce oznacza to weryfikację jakości w klasie EF i AF dla liczby ścieżek zależnej od liczby węzłów brzegowych domeny. 23

24 Rysunek 3-3: Algorytm zarządzania pasmem w MS; Zarządzanie jakością Analiza jakości powinna być przeprowadzana dla łańcucha węzłów i łączy. Dla każdej ścieżki należy wyznaczyć sumaryczne maksymalne opóźnienie między brzegami domeny, zmienność opóźnienia (poprzez kwantyl) oraz prawdopodobieństwo straty pakietów, czyli parametry: IPTD (IP Packet Transfer Delay), IPDV (IP Packet Delay Variation), IPLR (IP Packet Loss Ratio). Wartości graniczne powyższych parametrów zostały podane w raporcie A.2. 24

25 Ze względu na skomplikowanie zadania, należy przyjąć w początkowym podejściu szereg uproszczeń, które w dalszych krokach można eliminować. Najważniejszymi uproszczeniami są: niezależność opóźnienia oraz prawdopodobieństwa straty w każdym węźle, każdy z węzłów wnosi do całkowitego prawdopodobieństwa straty i bilansu opóźnienia taki sam wkład; nie musi to być optymalne rozwiązanie, WFQ dostatecznie dobrze separuje oddziaływania między klasami obsługi, funkcja weryfikacji zwraca tylko stan binarny: TAK albo NIE; nie przewiduje się początkowo, by funkcja QC proponowała przyznanie porcji pasma, innej niż żądana. Poniżej zaproponowano uproszczony algorytm weryfikacji jakości przyznania zasobów C Xij dla ścieżki, gdzie X jest usługą, i,j są numerami węzłów brzegowych; oznaczenia jak w punkcie krok 1. Korzystając z modeli obsługi zaproponowanych w raporcie A.2 i własności rozkładu czasu napływania pakietów, można wyznaczyć maksymalne obciążenie ρ Xij_max oraz pojemności buforów ścieżki niosącej ruch klasy X, by spełnić warunek na IPTD, IPDV i IPLR. krok 2. Sprawdzić, czy obecne obciążenie ścieżki pochodzące z pomiarów powiększone o quotę nie przekracza ρ Xij_max (algorytm jest słuszny także dla MS pracującego w trybie krytycznym, z tym, że zamiast wartości quoty wykorzystana jest wielkość dokładnie żądanego pasma), krok 3. Sprawdzić czy obecne obciążenie ścieżki i pojemności buforów gwarantują czasy opóźnienia i jej zmienności (w praktyce łatwiej jest wyznaczyć maksymalną zmienność), krok 4. Wyznaczyć wektor T zawierający numery łączy fizycznych przenoszących analizowaną ścieżkę, krok 5. Ustalić wszystkie ścieżki klas EF i AF, korzystające z łączy określonych przez wektora T, krok 6. Dla każdej z wyżej wskazanych ścieżek zrealizować kroki 1 i 2. Ostateczna weryfikacja przyznania zasobów ma miejsce w przypadku pozytywnej weryfikacji w każdym z kroków powyższego algorytmu. 3.3 Wymagania dotyczące rutingu i pomiarów System zarządzania domeną spełnia swoje zadania jeśli uzyskuje od funkcji rutingu warstwy przenoszenia pakietów następujące informacje: topologia sieci, bieżąco wykorzystywane drogi między brzegami sieci, pasmo łączy międzywęzłowych. 25