KONCEPCJA MODELU DO BADANIA WYDAJNOŚCI DOMENY IP QoS

Sylwester Kaczmarek Politechnika Gdańska, Gdańsk Wydział ETI, Katedra Systemów i Sieci Telekomunikacyjnych kasyl@eti.pg.gda.pl Piotr Żmudziński Uniwersytet Kazimierza Wielkiego Zakład Podstaw Informatyki zmudzin@ukw.edu.pl 2005 Poznańskie Warsztaty Telekomunikacyjne Poznań 8-9 grudnia 2005 KONCEPCJA MODELU DO BADANIA WYDAJNOŚCI DOMENY IP QoS Streszczenie: Celem artykułu jest przedstawienie koncepcji hierarchicznie rozproszonego brokera MBB (Multiple Bandwidth Broker) realizującego funkcje AC w oparciu o pomiary. Zaproponowane zostały przez autorów modele funkcjonalne brokera centralnego oraz brokera brzegowego. Autorzy zaproponowali także algorytm realizujący MBAC, zaimplementowany w brokerze brzegowym. Prezentowany model koncepcyjny umożliwia zwiększenie skalowalności DS oraz ograniczenie ruchu sygnalizacyjnego dzięki zastosowaniu nadmiarowego przydziału pasma PoQ ścieżek domeny. 1. WSTĘP Dalszy rozwój globalnej sieci Internet uzależniony jest od usług świadczonych przez tą sieć. Obecnie usługi generujące ruch elastyczny: transport wiadomości e- mail, dostęp do stron WWW oraz możliwość zdalnej pracy na serwerach nie są wystarczające. Coraz większą popularność wśród użytkowników zyskują usługi: VoIP, wideokonferencji, VoD generujące strumień danych o zmiennej charakterystyce ruchowej. Wymienione usługi wymagają od sieci dostarczenia usług przenoszenia z gwarancjami jakości QoS, co obecnie nie jest możliwe ze względu na brak mechanizmów TE (Traffic Engineering). W tej sytuacji organizacja IETF (Internet Engineering Task Force) zaproponowała dwie odmienne architektury sieci IP QoS: Integrated Services (IS) [8] i Differentiated Services (DS) [11]. Badania dowiodły, że IS bazujący na koncepcji podobnej do ISDN nie jest architekturą wystarczająco skalowalną, co wyklucza stosowanie jej w sieci rozległej. Znacznie lepszą skalowalnością cechuje się architektura DS, dostarcza jednak słabszych gwarancji jakościowych (statystycznych). Podstawową ideą architektury DS jest zmiana modelu sieci z płaskiego na model hierarchiczny, pozwalający lepiej sterować oraz zarządzać zasobami operatorskimi. Każdy z operatorów sieci rdzeniowej administruje domeną sieci złożoną w ogólności z: ruterów brzegowych (RB), ruterów rdzeniowych (RR) oraz brokera pasma (BB) zarządzającego zasobami sieci oraz polityką obsługi klas ruchu (Rys.2). Rutery brzegowe realizują bardziej złożone funkcje sieciowe związane z przyjęciem do obsługi nowego strumienia - funkcje AC (Admission Control). RB przyporządkowuje napływające od użytkownika sieci pakiety do poszczególnych klas obsługi a następnie znakuje pakiety przez zamianę wartości pól TOS (Type of Service) znajdujących się w nagłówku pakietu IPv4 lub pól Traffic Class IPv6 na pole DSCP (DiffServ Code Point). Nadto RB realizuje analizę zgodności parametrów ruchowych przyjętych strumieni z kontraktem SLS (Service Level Specification) zawartym przez użytkownika z domeną DS. Rutery rdzeniowe cechują się możliwie prostą funkcjonalnością, nie przechowują informacji o przenoszonych przez nie strumieniach generowanych przez użytkowników domeny. Głównym zadaniem RR jest klasyfikowanie napływających pakietów do ustalonych klas BA (Behavior Aggregate) a następnie obsługa pakietów należących do strumieni zagregowanych, na którą składa się: buforowanie pakietów, usuwanie z kolejki jeżeli jest taka konieczność (np. mechanizmy RED, RIO), obsługa zgodnie z zaimplementowanym mechanizmem kolejkowania i określoną polityką obsługi PHB, kształtowanie ruchu. Broker pasma jest oprogramowaniem sterującym domeną DS, umożliwia świadczenie usług z ustalonym QoS przy maksymalnie dużym wykorzystaniu zasobów sieci. Główne zadania BB to: limitowanie ilości ruchu wpływającego do domeny MBAC (Measurement-Based Admission Control), celem zapobieżenia degradacji QoS dla obsługiwanych już strumieni, spójna dla domeny konfiguracja ruterów brzegowych i rdzeniowych, polegającej na przesyłaniu parametrów koniecznych do realizacji PHB (Per Hop Behaviour), taryfikacja, jeżeli operator inaczej taryfikuje usługi z różnych klas QoS, utrzymanie, polegające na zbieraniu statystyk ruchowych lub informacji o nieprawidłowym działaniu sieci na potrzeby rekonfiguracji sieci lub optymalnej rozbudowy infrastruktury operatorskiej, komunikacja z BB domen sąsiednich w celu umożliwienia przekierowania strumienia zagregowanego BA w kierunku domeny, której klientem jest odbiorca, spójne dla domeny konfigurowanie ruterów polegające na przesyłaniu do podległych urządzeń wag dla algorytmu WFQ oraz prawdopodobieństw odrzucenia pakietów dla mechanizmu np. RED. Niezależnie od wielkości domeny, koncepcja DS zakłada istnienie logicznie jednego BB odpowiedzialnego za centralne sterowanie całą domeną. Z oczywistych względów założenie to może spowodować powstanie wąskiego gardła. Ze względu na ograniczoną wydajność pojedynczego sytemu BB zaproponowane zostały w literaturze koncepcje rozproszonego BB mające na PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 1/6

cbb realizuje następujące zadania związane ze sterowaniem własną domeną: żąda od ruterów domeny danych pomiarowych dotyczących wykorzystania zasobów sieci, organizuje otrzymane dane pomiarowe w odpowiedniej bazie danych, wyznacza ścieżki między ruterami brzegowymi oraz na bieżąco aktualizuje ich obciążenie na podstawie bazy wykorzystania łączy, organizuje synchronizację odpowiednich części baz danych cbb i ebb; konieczny jest tu mechanizm sewww.pwt.et.put.poznan.pl celu zwiększenie skalowalności architektury DS. Koncepcja rozpraszania funkcjonalności BB zakłada istnienie jednego, centralnego brokera oraz pewnej liczby podległych brokerów brzegowych posiadających ograniczoną autonomię. Określenie rozproszony odnosi się jedynie do wybranych funkcji BB, konieczny jest nadal broker centralny, koordynujący proces pomiarowy, przydzielający zasoby oraz synchronizujący bazy danych podległych brokerów. Celem niniejszego referatu jest przedstawienie modelu funkcjonalnego rozproszonego brokera pasma realizującego funkcje AC w oparciu o metody bazujące na pomiarach MBAC. Prezentowana koncepcja stanowić będzie podstawę do dalszych badań zmierzających do implementacji modelu i badań związanych ze skutecznością metod MBAC opisanych w [2]. Referat zorganizowany jest w następujący sposób. W rozdziale 2 przedstawiona zostanie ogólna koncepcja BB zaproponowana w projekcie QBone. W rozdziale 3 zaprezentowany zostanie model hierarchicznie rozproszonego brokera pasma. Scharakteryzowane zostały funkcje brokera centralnego oraz brokera brzegowego. Rozdziały 4 i 5 poświecone zostały szczegółowemu opisowi budowy funkcjonalnej oraz organizacji baz danych brokera centralnego i brokera brzegowego. W rozdziale 6 zaprezentowano algorytm przyjęcia MBAC realizowany przez broker brzegowy. 2. KONCEPCJA IMPLEMENTACJI BB Na potrzeby projektu badawczego QBone [7] opracowana została pierwsza koncepcja architektury funkcjonalnej scentralizowanego brokera pasma. Alternatywne koncepcje modelu BB to: UCLA, Kansas, Merit, CA*net, GARA i ENICOM [1]. interfejsy do wymiany danych z innymi urządzeniami domeny oraz brokerami domen sąsiednich. 3. MODEL BB WYKORZYSTYWANY DO DALSZYCH BADAŃ Do dalszych badań związanych ze skutecznością algorytmów MBAC w domenie DS zaproponowano model rozproszonego brokera pasma oparty na koncepcja hierarchicznie rozproszonego brokera pasma MBB [5,6]. Alokacja zasobów oparta został na koncepcji PoQ (Pathorientated Quota-based) [5], która zakłada nadmiarowy przydział pasma w celu maksymalnego zmniejszenia obciążenia brokera centralnego oraz minimalizacji ilość ruchu sygnalizacyjnego między brokerami w pionie hierarchii. Koncepcja dopuszcza niewielki spadek wykorzystania pasma domeny ze względu na lokowanie zasobów z nadmiarem jako alternatywa do podejścia dokładnego wymagającego więcej mocy obliczeniowej w warstwie sterowania. Warstwa sterowania MBB składa się z centralnego brokera pasma cbb oraz pewnej liczby brokerów brzegowych ebb. W skrajnym przypadku każdemu ruterowi brzegowemu odpowiada oddzielny broker ebb (Rys. 2). sterowania przesyłania pakietów sąsiednie BB serwer aplikacji GUI operatora sieci użytkownik / host Interfejs do przyległego BB Rutery Rdzeniowe Interfejs NMS Baza tablic rutingu Interfejs do przyległego BB Usługi sterowania Interfejs do ruterów domeny Zarządzanie politykami Repozytorium danych Rutery Brzegowe Rys. 1. Ogólny model brokera pasma wg QBone Budowa funkcjonalna brokera prezentowana w projekcie QBone jest na tyle ogólna, że może być reprezentantem architektury BB. Na oprogramowanie BB składają się (Rys.1): baza danych repozytorium i baza rutingu, moduły usług sterowania, Rys. 2. Rozproszony BB w warstwie sterowania 3.1. Funkcja cbb Centralny broker pasma pełni rolę centralnego elementu sterującego domeną. Zadania cbb podzielić można ze względu na interakcje z elementami własnej domeny oraz domenami sąsiednimi. Do zadań związanych ze współpracą z brokerami innych domen należą: wysyłanie żądań RAR (Resource Allocation Requests) w imieniu użytkownika własnej domeny celem zarezerwowania zasobów sąsiedniej domeny na potrzeby nowej lub istniejącej ścieżki, autoryzacja i obsługa napływających żądań RAR. PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 2/6

lekcji danych, tak by do odpowiedniego ebb docierały tylko wykorzystania ścieżek, którymi on zarządza (unikanie nadmiarowego ruchu sygnalizacyjnego), przetwarza otrzymane komunikaty protokołu grupy IGP, następnie przetwarza informacje i buduje spójną tablicę rutingu QoS dla całej domeny, zarządzanie politykami obsługi PHB, umożliwia personelowi administracyjnemu modyfikację parametrów związanych ze sterowaniem domeną. 3.2. Funkcja ebb Każdy z brokerów brzegowych zarządza wykluczającą się grupą ścieżek end-to-end. Dla lepszego podziału uprawnień przyjęto, że ścieżki między brzegami domeny są jednokierunkowe (Rys.3). ebb realizuje funkcję AC, w razie potrzeby żąda od cbb przyznania dodatkowej porcji pasma dla podległej grupy ścieżek. centralnymi brokerami sąsiednich domen, podległymi ebb własnej domeny. W dalszej części omówione zostaną szczegółowo wymienione wyżej moduły oprogramowania. 4.1. Usługi sterowania cbb Manager komunikacji cbb-ebb odpowiada za przesyłanie do każdego z ebb odpowiednio przygotowanej części Path dbase obejmującej wykorzystanie oraz pojemność całkowitą ścieżek zarządzanych przez dany ebb. Ponadto manager komunikacji odbiera od ruterów brzegowych żądania utworzenia nowej ścieżki lub przyznania większej ilości zasobów dla ścieżki już istniejącej. Kolejnym zadaniem managera jest wysyłanie odpowiedniej części centralnej bazy autoryzowanych użytkowników wraz z maksymalnymi akceptowalnymi w SLA parametrami ruchowymi o podległych ebb. Manager komunikacji BB-to-BB odpowiada za wymianę wiadomości sygnalizacyjnych RAR między sąsiadującymi domenami. sterowania przesyłania pakietów Rys. 3. Podział zażądanej domeny Zadania ebb ograniczają się do: realizacji MBAC dla użytkowników dołączonych do niewielkiej grupy ruterów podległych danemu brokerowi (w skrajnym przypadku do jednego), uwierzytelnienia użytkownika żądającego obsługi, co wyklucza szkodliwe działanie użytkowników złośliwych, komunikacji z zarządzanymi ruterami brzegowymi w celu przesłania informacji o przyjęciu nowego strumienia i sposobu jego obsługi (przypisanie do klasy usług) formułowania żądań przydziału dodatkowych zasobów do zarządzanych ścieżek lub tworzenia nowych, realizacji komunikacji z cbb. 4. BUDOWA FUNKCJONALNA cbb Oprogramowanie centralnego brokera pasma składa się z następujących modułów funkcjonalnych (Rys.4): usług sterowania, bazy tablic rutingu, bazy repozytorium, interfejsów do komunikacji z: użytkownikami (aplikacjami użytkowników), ruterami rdzeniowymi, ruterami brzegowymi, serwer aplikacji GUI operatora sieci Interfejs zarządzania Rys. 4. Model funkcjonalny cbb Manager pomiarów odpowiedzialny jest za zarządzanie sposobem uzyskiwania danych pomiarowych o aktualnym wykorzystaniu zasobów w domenie. Do uzyskania aktualnych wartości wykorzystania zasobów można zastosować polling oraz cykliczne odpytywanie każdego rutera sieci o żądane parametry. Alternatywną metodą jest wybór przyrostu wartości obciążenia, po przekroczeniu którego zarządzany ruter przesyła do managera pomiarów aktualną wartość obciążenia. Podejście to redukuje ilość ruchu sygnalizacyjnego w domenie tym lepiej im fluktuacje obciążenia są mniejsze. Algorytm budowania tablicy rutingu dla domeny. Dla poprawnego funkcjonowania domeny DS konieczne jest zaimplementowanie tego samego algorytmu rutingu QoS w ruterach sieci oraz cbb. W literaturze proponowanych jest kilka obiecujących algorytmów: SAMCRA [3], E_MCOP i H_MCOP [4]. Algorytm rutingu umożliwia określenie drogi między brzegami domeny na podstawie zadanych kryteriów. Wykorzystanie algorytmów wielokryterialnych (multi constrained) uwzględniających dane pomiarowe np. średnich opóźnień i średniego obciążenia łączy oraz podejmowanie decyzji w oparciu o PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 3/6

złożone metryki co jest konieczne dla zapewnienia QoS oferowanych usług. Do wymiany wiadomości sygnalizacyjnych między ruterami warstwy przenoszenia pakietów oraz cbb, zawierających niezbędne informacje dla metryk, konieczny jest protokół z grupy IGP (Interior Gateway Protocol). Dobrym przykładem protokołu spełniającego to zadanie jest OSPFv2 [13]. cbb jest tak skonfigurowany, aby postrzegany był przez rutery domeny jak węzeł sieci, zatem będzie odbierał pakiety z wiadomościami protokołów grupy IGP. Na podstawie tych wiadomości algorytm sterowania buduje spójną tablicę rutingu odzwierciedlającą zasady kierowania pakietów w warstwie przesyłania pakietów. Wynik pracy procesu umieszczony jest w Bazie tablic rutingu. Zarządca zasobów domeny odpowiedzialny jest za przydział wolnego pasma do określonych ścieżek. W przypadku, gdy klient żąda usługi wymagającej więcej pasma niż ebb może przydzielić na żądanej ścieżce, usługa nie może być zrealizowana. ebb powinien zatem zażądać od cbb przydziału dodatkowej porcji pasma, zwykle większej od przeciętnego żądania, aby w przyszłości podobne żądanie mogło być zrealizowane. Realizację przydziału (lub odebrania) zasobów do ścieżek realizuje proces zarządcy domeny na podstawie bazy rutingu oraz bazy aktualnego wykorzystania zasobów w sieci. Nowe wartości przydziału zasobów do ścieżek są przesyłane niezwłocznie do podległego ebb. Mechanizm synchronizacji baz danych realizuje synchronizację odpowiednich części Path dbase zlokalizowanej w cbb z bazami ścieżek umieszczonych w ebb. Demon konfiguracji jest procesem tłumaczącym komendy sterujące na odpowiedni język skryptowy zaimplementowanych RB i RR. Zastosowanie tego modułu umożliwia dynamiczne konfigurowanie ruterów domeny niezależnie od metod konfiguracji przewidzianych przez różnych dostawców sprzętu. Moduł zarządzania politykami PHB odpowiedzialny jest za dystrybucję danych konfiguracyjnych do ruterów warstwy przekazywania pakietów w szczególności prawdopodobieństw odrzucenia dla każdej z klasa oraz wag dla mechanizmu WFQ obsługi pakietów. 4.2. Interfejsy cbb Do komunikacji cbb z personelem administracyjnym zaimplementowano Interfejs zarządzania. Moduł Interfejs NMS umożliwia dołączenie cbb do systemu zarządzającego siecią (Network Management System). Do realizacji procesu wymiany wiadomości zaimplementowany został Interfejs komunikacyjny do BB. W [7] zaproponowano protokół komunikacyjny SIBBS (Simple Interdomain Bandwidth Broker Signaling). Do komunikacji cbb-ebb zaimplementowano interfejs zarządzania ruterami domeny wykorzystujący jeden lub więcej protokołów: COPS (Common Open Policy Services [12], SNMP (Simple Network Management Protocol) [10] lub telnet/ssh. Należy zauważyć że komunikacja ta może być inicjowana z obu stron w dowolnym momencie. 4.3. Repozytorium danych Dla prawidłowego działania BB konieczne są syntetyczne informacje zawarte w bazie danych zwanej repozytorium. W celu czytelnego podziału gromadzonych informacji, wyodrębniono logicznie bazy danych związane z poszczególnymi funkcjami lub fazami realizacji procesu MBAC. Z oczywistych względów repozytorium cbb i ebb różnią się. Poniżej dokonano skrótowego opisu z uwzględnieniem różnic. SLA dbase baza użytkowników, zawiera dane konieczne do weryfikacji uprawnień użytkowników żądających świadczenia usługi. Nadto gromadzone są w bazie informacje o usługach dostępnych dla każdego z użytkowników oraz maksymalne wartości poszczególnych parametrów w SLS jakie może zaakceptować BB. Autentykacja użytkowników eliminuje problem złośliwych użytkowników destabilizujących pracę domeny. Rys. 5. Budowa funkcjonalna repozytorium w cbb Inter ISP SLA dbase baza sąsiednich BB uprawnionych do obsługi. RAR pochodzący od sąsiedniego BB jest weryfikowany także pod względem żądanych parametrów. Podobnie jak w poprzednim przypadku, każdy BB ma określone maksymalne parametry usług, które świadczy na rzecz domen przyległych. Link dbase zawiera aktualne obciążenie łączy międzywęzłowych. Wartości przechowywanych parametrów odzwierciedlają rzeczywiste obciążenie łączy z dokładnością do kwantu czasu między pomiarami w przypadku metody polling albo wyznaczonego przyrostu, po którego przekroczeniu następuje przesłanie przez ruter danych pomiarowych do cbb. Path dbase baza zawierająca listę istniejących ścieżek łączących rutery brzegowe. Nadto przechowywane są wartości wykorzystania pasma dla każdej ze ścieżek. Aktualne obciążenie ścieżki wyznaczane jest na podstawie wykorzystania łączy pochodzących z pomiarów i zgromadzonych w Link dbase. Edge resource dbase baza zawiera informację o ruterach brzegowych domeny oraz o adresowaniu sieci dołączonych do poszczególnych RB. BB Neighbour Database baza przechowująca informacje po sąsiednich BB, ich adresy sieciowe oraz adresy i porty własnych ruterów łączących się bezpośrednio z ruterami brzegowymi sąsiednich domen. 5. BUDOWA FUNKCJONALNA ebb Broker brzegowy ma znacznie prostszą budowę i ze względu na ograniczone funkcje polegające przede wszystkim na uwierzytelnieniu użytkownika oraz realizacji funkcji AC (Rys.6). PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 4/6

Podstawowym założeniem metody PoQ jest wirtualny podział całkowitego pasma każdego z łączy międzywęzłowych na równe części zwane porcjami (quotas). Wielkość porcji powinna zostać tak dobrana, aby była znacznie większa od typowego żądania pasma napływającego do BB. Broker pasma pracuje w dwóch trybach: w trybie normalnym i trybie krytycznym. Pracując w trybie normalnym BB przydziela lub odbiera, jeżeli jest taka konieczność, pojedynczą porcję pasma dla danej ścieżki. W bazie danych ścieżek QoS przechowywana jest zatem informacja o bieżącym obciążeniu oraz liczbie przydzielonych porcji dla każdej ze ścieżek domeny. Jeżeli BB otrzyma zgłoszenie nowego strumienia na danej ścieżce, moduł AC sprawdza jedynie w bazie ścieżek czy obecna liczba przydzielonych porcji pasma jest wystarczająca do obsługi sumy ruchu przenoszonego i nowego w analizowanej ścieżce. Jeżeli odpowiedź jest pozytywna, żądanie jest przyjęte a wartość pola zarezerwowanego pasma w bazie ścieżek zostanie uaktualniona o wartość przyjętego strumienia. W przypadku nie wystarczających zasobów BB przydziela dodatkową porcję pasma na ścieżce (czyli na wszystkich łączach w szeregu) tak by zaspokoić żądanie i ewentualne przyszłe, podobne zgłoszenia. Istnieje także mechanizm kontroli wykorzystania pasma. Jeżeli okaże się, że porcja pasma została przydzielona ze zbytnim nadmiarem (co ma miejsce w przypadku zakończenia obsługi pewnej liczby strumieni), cbb odbiera jedną porcję pasma, która dostępna będzie od tego momentu na każdym składowym łączu, tak by w przyszłości mogła być zaalokowana na innej ścieżce Jeżeli na dowolnym łączu składowym ścieżki cbb nie będzie mógł przydzielić, ze względu na brak zasobów, konieczna będzie zmiana trybu pracy BB. W tej sytuacji BB przechodzi w tryb krytyczny, a proces przydziału pasma dla wszystkich ścieżek zawierających silnie obciążone łącze polega na przydziale pasma w ilości żądanej nie zaś w ustalonej wielkości porcji. W trybie krytycznym BB przydziela oszczędniej pasmo, bez nadmiarowości, aby obsłużyć maksymalnie dużą liczbę strumieni kosztem wzrostu na moc obliczeniową sterowania domeną. Jeżeli wielkość parametru porcji zostanie dobrana poprawnie to nawet w przypadku dużej liczby zgłoszeń obsługi i rezygnacji z obsługi (tear-down) w jednostce czasu, większość decyzji AC zostanie podjęta w oparciu o bazę ścieżek, co w sposób znaczący usprawnia i skraca czas podejmowania decyzji. Z punktu widzenia wydajności rozwiązanie pozwala odciążyć oprogramowanie cbb czyli zwiększa skalowalność. Zgłoszenie żądania obsługi generowane jest przez użytkownika sieci i przekazywane jest do ebb (Rys.7). ebb sprawdza swój stan i w przypadku chwilowego zajęcia buforuje żądanie. Następnie autoryzuje w SLA dbase użytkownika. Jeżeli użytkownik jest nieznany, komunikuje się z cbb żądając weryfikacji. Po poprawnej autoryzacji sprawdzane są dane charakteryzujące struwww.pwt.et.put.poznan.pl 5.1. Usługi sterowania cbb Usługa uwierzytelniania umożliwia weryfikację uprawnień użytkownika do obsługi. Nadto weryfikowane jest czy usługa o zadeklarowanych parametrach ruchowych może być przez użytkownika żądana. cbb Agent jest oprogramowaniem współpracującym z Managerem komunikacji cbb-ebb zaimplementowanym w cbb do wymiany danych i komunikatów sterujących. Przykładem danych przesyłanych do Agenta cbb mogą być wartości pojemności ścieżek zażądanych przez dany ebb. cbb domeny własnej Path dbase Interfejs do cbb Usługi sterowania cbb Agent Usługi uwierzytelnienia ` AC Manager Demon Konfiguracji Repozytorium ebb SLA dbase Tablica rutingu Interfejs do zarządzanych RB Zarządzane Rutery Brzegowe Rys. 6. Model funkcjonalny ebb Demon konfiguracji jest procesem tłumaczącym komendy sterujące na odpowiedni język skryptów konfiguracyjnych zaimplementowany w ruterach brzegowych. AC Manager jest oprogramowaniem decydującym o przyjęciu nowego strumienia do obsługi ze względu na żądane parametry usługi oraz dostępne pasmo w ścieżce. Algorytmy MBAC omówione zostały szczegółowo w [2]. 5.2. Interfejsy ebb Dzięki zaimplementowanemu w ebb interfejsowi, użytkownik może komunikować się z ebb zgłaszając żądanie obsługi wraz z jej parametrami ruchowymi. Do tego celu wykorzystuje się protokół RSVP [9]. Interfejs do cbb umożliwia przesyłanie żądań utworzenia nowej ścieżki end-to-end lub zmianie przydzielonego pasma. Interfejs do zarządzanych RB umożliwia konfigurację ruterów aby akceptowały nowy strumień i znakowały odpowiednio napływające pakiety do określonych klas ruchu. 5.3. Repozytorium danych W brokerze brzegowym repozytorium danych składa się z dwóch baz: Path dbase i SLA dbase. Obie bazy zawierają cześć danych zawartych w repozytorium w cbb dotyczącą zbioru łączy zarządzanych przez ebb oraz użytkowników obsługiwanych przez ten ebb. Tablica rutingu zawiera informacje dotyczące odwzorowania adresów docelowych na konkretne ścieżki. 6. PROCES PRZYJĘCIA NOWEGO ZGŁOSZENIA PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 5/6

mień, które zostały przesłane przez użytkownika. Jeżeli żądane parametry przekraczają wcześniej ustalone z operatorem domeny maksymalne wartości dla usługi, następuje renegocjacja albo odrzucenie żądania obsługi. Na podstawie adresu docelowego oraz tablicy rutingu ebb określa w Patch dbase ścieżkę do odbiorcy, albo do rutera wyjściowego z domeny, jeżeli odbiorca nie jest dołączony do tej samej domeny. Jeżeli ebb nie potrafi określić ścieżki, odrzuca żądanie i wysyła do cbb wiadomość żądania zestawienia ścieżki i przydzielenia minimalnej liczby zasobów czyli porcji. W przypadku istnienia ścieżki, ebb wyznacza pasmo efektywne w oparciu o wybrany przez administratora algorytm a następnie sprawdza czy na ścieżce do celu może przydzielić wyznaczoną ilość pasma. Jeśli na żądanej ścieżce brakuje zasobów ebb wysyła żądanie do cbb o przyznanie dodatkowej porcji pasma. Jeżeli ścieżka nie jest w trybie krytycznym cbb przyznaje porcję w przeciwnym przypadku przyznaje jedynie tyle pasma, ile jest niezbędne. Po sprawdzeniu dostępności zasobów ebb akceptuje strumień. Dalsze czynności związane z realizacją obsługi nowego strumienia realizuje usługa demona konfiguracji, która zmienia konfigurację rutera tak, aby możliwe było przyjęcie i znakowanie pakietów należących do nowego strumienia. 7. PODSUMOWANIE W prezentowanym referacie rozważona została koncepcja hierarchicznie rozproszonego brokera pasma. Metoda przyjęcia nowego strumienia oparta jest na pomiarach, natomiast przydział pasma bazuje na bardzo ciekawej metodzie nadmiarowego przydziału pasma. W rozdziale 4 i 5 omówiono zaproponowane przez autorów architektury funkcjonalne cbb i ebb oraz ich bloki funkcjonalne, natomiast w rozdziale 6 przedstawiono propozycję dotyczącą algorytmu realizacji przyjęcia nowego zgłoszenia obsługi w MMB PoQ. Dalsze prace autorów koncentrować się będą na implementacji proponowanego modelu rozproszonego BB w symulatorze ns-2 w celu przebadania jego wydajności w kontekście gwarancji jakości usług i maksymalizacji wykorzystania zasobów domeny. SPIS LITERATURY [1] Kaczmarek S., Żmudziński P., Broker pasma jako element dynamicznego sterowania siecią diffserv, Internet - Wrocław 2005, 2005 [2] Kaczmarek S., Żmudziński P, Metody admission control oparte na pomiarach, PWT 2004, Poznań, pp. 84-89 [3] Mieghem P., Kuipers F.A., Concepts of Exact QoS Routing Algorithms, IEEE/ACM Transaction on networking, vol.12, no.5, October 20004, pp. 851-864 [4] Feng G., Pissinou N., Douligers D., Heuristic and Exact Algorihms for QoS Ruting with Multi Constrains, IEICE Transactions on Communications, E85B(12), December 2002, pp. 2838-2850 [5] Zhang Z., Duan Z., Hou Y.: On Scalable Design of Bandwidth Brokers, IEICE Trans. Communications, Vol. E84-B, No.8 August 2001, pp. 2011-2025 [6] Bouras Ch., Stamos K., Examining the Benefits of a Hybrid Distributed Architecture for Bandwidth, IPCCC 2005 - April 7-9, 2005 - Phoenix, Arizona [7] QBone Bandwidth Broker Architecture, QBone Signaling Design Team, http://qbone.internet2.edu/bb/bboutline2.html [8] Braden R., at all, RFC1633, Integrated Services in the Internet Architecture: an Overview, June 1994 [9] Braden R. at all, RFC2205, Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification, September 1997 [10] Case J. at all RFC2272, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), January 1998 [11] Blake. S. at all RFC2475, An Architecture for Differentiated Services, December 1998 [12] Durham D. at all, RFC2748, The COPS (Common Open Policy Service) Protocol, January 2000 [13] Katz D. at all RFC3630, Traffic Engineering (TE) Extensions to OSPF Version 2, September 2003 Rys. 7. Algorytm MBAC realizowany przez ebb PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005 6/6