W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność.

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/WUT/D.2 Tytuł raportu: Implementacja warstwy zarządzania zasobami - część II Przewidywany termin dostarczenia raportu: 31/12/2009 Rzeczywisty termin dostarczenia raportu: 15/01/2010 Kierownik zadania: Wykonawcy: Wojciech Burakowski Sylwester Kaczmarek, Marcin Narloch, Piotr Pyda, Tomasz Dalecki, Jarosław Śliwiński, Witold Góralski, Andrzej Bęben, Halina Tarasiuk, Piotr Krawiec Abstrakt: Raport przedstawia stan implementacji systemu IP QoS na koniec etapu D projektu i dotyczy warstwy zarządzania zasobami. W raporcie opisano aktualny stopień realizacji poszczególnych węzłów i serwerów, w tym definicje interfejsów w języku SLICE, implementację oraz wymagania związane z wdroŝeniem wytworzonego oprogramowania. Ponadto w raporcie znajdują się równieŝ opisy konfiguracji i uruchamiania poszczególnych elementów oprogramowania. Słowa kluczowe: DiffServ, NGN, RACF, zarządzanie zasobami, wymiarowanie sieci

Streszczenie Raport przedstawia stan implementacji IP QoS na zakończenie etapu D projektu i dotyczy warstwy zarządzania zasobami. Opis implementacji dotyczy ostatecznego stanu całego oprogramowania (w tym oprogramowania, które powstało w etapie C) i zawiera: definicję interfejsów w języku SLICE, stan implementacji na koniec etapu D, wymagania związane z zastosowanymi narzędziami programistycznymi, sposób konfiguracji poszczególnych węzłów lub serwerów, sposób uruchamiania poszczególnych węzłów lub serwerów. PowyŜszy opis dotyczy: węzła RMS (Resource Management Subsystem), węzła ROMAN (Routing Management), węzła PD-PE (Policy Decision Physical Entity), węzła TRC-PE (Transport Resource Control Physical Entity), węzła PE-PE (Policy Enforcement Physical Entity) serwera konfiguracyjnego systemu. W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność. SPIS TREŚCISTRESZCZENIE... 2 SPIS TREŚCI... 2 1 ARCHITEKTURA SYSTEMU... 4 1.1 ZAŁOśENIA SYSTEMU... 4 1.2 PODZIAŁ FUNKCJONALNY SYSTEMU... 4 1.3 PROCESY WARSTWY ZARZĄDZANIA ZASOBAMI... 5 2 STAN IMPLEMENTACJI WĘZŁÓW SYSTEMU... 10 2.1 WĘZEŁ RMS (RESOURCE MANAGEMENT SUBSYSTEM)... 10 2.2 WĘZEŁ ROMAN (ROUTING MANAGER)... 13 2

2.3 WĘZEŁ PD-PE (POLICY DECISION PHYSICAL ENTITY)... 20 2.4 WĘZEŁ TRC-PE (TRANSPORT RESOURCE CONTROL PHYSICAL ENTITY)... 22 2.5 WEZEL PE-PE (POLICY ENFORCEMENT PHYSICAL ENTITY)... 24 2.6 SERWER KONFIGURACYJNY SYSTEMU... 26 2.7 KOLEJNOŚĆ URUCHAMIANIA WĘZŁÓW SYSTEMU... 27 3 PODSUMOWANIE... 28 LITERATURA... 30 LISTA SKRÓTÓW... 31 ZAŁĄCZNIK A: DEFINICJA INTERFEJSÓW W JĘZYKU SLICE... 32 3

1 Architektura systemu 1.1 ZałoŜenia systemu Rysunek 1-1 przedstawia podstawowy scenariusz działania systemu. WyróŜniamy w nim uŝytkowników, którzy są dołączeni do ruterów brzegowych. UŜytkownik uzyskuje dostęp do zasobów sieci za pomocą aplikacji, która komunikuje się z serwerami aplikacji (oferowanymi przez dostawcę usługi). Serwery aplikacji wysyłają Ŝądanie przygotowania zasobów sieciowych zgodnie z wymaganiami, które są zawarte w Ŝądaniu wysyłanym przez aplikację. Serwery zarządzania zasobami (nale- Ŝą do operatora) odpowiadają za zarządzanie zasobami sieci, tak, aby dla wybranych klas usług wprowadzić ścisłe gwarancje jakości przekazu w sieci od końca do końca. Ponadto zgodnie z zało- Ŝeniami architektury DiffServ [RFC2475], sieć składa się z ruterów brzegowych oraz ruterów szkieletowych (rutery szkieletowe nie zostały przedstawione na rysunku). Serwer aplikacji (dostawca usług) Serwery zarządzania zasobami (operatora) UŜytkownik A Aplikacja UŜytkownik B Aplikacja A Ruter brzegowy B Ruter brzegowy Rysunek 1-1: Podstawowy scenariusz działania systemu Ze względu na skalę czasu, wyróŝnia się dwie grupy procesów realizowanych w systemie: Procesy związane z obsługą wywołań skala sekund lub minut, Procesy związane z zarządzaniem zasobami skala godzin lub dni. W raporcie tym opisuje się implementację węzłów i interfejsów dla procesów drugiego rodzaju, czyli procesów związanych z zarządzaniem zasobami. 1.2 Podział funkcjonalny systemu Rysunek 1-2 przedstawia podział funkcjonalności systemu, zgodnie ze specyfikacją przedstawioną w [B1], na poszczególne węzły funkcjonalne wraz z interfejsami występujące pomiędzy poszczególnymi węzłami. Skierowanie strzałek oznacza jedynie kierunek, w którym wywołanie jest inicjalizowane. Wywołania te mogą otrzymywać wynik opisujący rezultat działania, tak więc wymiana wiadomości sygnalizacyjnych jest obustronna. Definicja w języku SLICE dla interfejsów rozwaŝanych w tym raporcie znajduje się w Załączniku A. 4

RomanToRms RmsToRoman RmsToPd PdToRms RomanToPd PdToSce SceToPd PdToTrc TrcToPd PdToPe Rysunek 1-2: Elementy funkcjonalne systemu wraz z interfejsami Raport ten dotyczy wyłącznie procesów związanych z obsługą wywołań. Z tego względu nie zostały opisane w nim węzeł funkcjonalny SCE oraz strona aplikacji, które biorą udział wyłącznie w procesach związanych z obsługą wywołań (procesy te zostały opisane w raporcie D.1). Dodatkowym elementem systemu, który został wprowadzony w celu usprawnienia procesu konfiguracji oprogramowania, jest serwer konfiguracyjny. Serwer ten umoŝliwia automatyczną konfigurację węzłów (wraz z lokalizacją) i przez to upraszcza część oprogramowania związaną z uruchomieniem wstępnym kaŝdego węzła. 1.3 Procesy warstwy zarządzania zasobami Warstwa zarządzania zasobami realizuje następujące procesy: Proces ustalenia rutingu w domenie jest wykonywany w module ROMAN. W procesie ustalona jest ścieŝka MPLS między kaŝdym wejściowym i wyjściowym ruterem brzegowym. W opisywanym rozwiązaniu cały ruch naleŝący do róŝnych klas usług przesyłany jest tą samą ścieŝką (MPLS) między ruterami brzegowymi. Przydzielanie zasobów dla róŝnych klas usług realizowane jest w module RMS. Moduł ten przydziela odpowiednie pasmo wszystkim klasom usług w danej ścieŝce (MPLS). Dodatkowo przydziela odpowiednie pasmo dla ścieŝek MPLS przechodzących przez dane łącze. Rozmiary buforów ustawiane są odpowiednio dla poszczególnych klas kaŝdego portu wyjściowego rutera (port przez który przebiega co najmniej jedna ścieŝka). Wyniki uzyskane z algorytmu przydzielania zasobów wykorzystywane są do konfigurowania interfejsów wyjściowych ruterów naleŝących do domeny (wyliczenie rozmiarów buforów). Dodatkowo wyliczone wartości wykorzystywane są w algorytmie przyjmowania nowych wywołań w odrębnym module. 5

Do opisu algorytmu zastosowano następujące oznaczenia: l=1..l, numer łączy (L liczba łączy), s=1..s, numer ścieŝki (S liczba ścieŝek), k=1..k, numer klasy usług (K liczba klas usług), C l przepustowość łączy l, δ ls = 1 kiedy ścieŝka s zawiera łączę l, inaczej δ ls =0, M[k,s] macierz zapotrzebowań, opisująca zapotrzebowanie ruchu klasy k dla ścieŝki s. W szczególności, algorytm przydzielenia zasobów dla klas usług polega na przeliczeniu macierzy zapotrzebowań od wejściowej macierzy relatywnej (zapotrzebowania wyraŝone w procentach) do absolutnej macierzy zainteresowań opisującej dokładną przepustowość dla kaŝdej ścieŝki i klasy usług. Na wejściowej macierzy zapotrzebowań dane są zapotrzebowania procentowe dla róŝnych klas dla danej ścieŝki. W ogólnym przypadku dla wszystkich klas i ścieŝek zapotrzebowania są takie same (elementy wejściowej macierzy równą się 1). Po uruchomieniu algorytmu, wyjściowa macierz zapotrzebowań zawiera wartości przepustowości dla kaŝdej ścieŝki i kaŝdej klasy ruchu. Wtedy, moŝna obliczyć wartości przepustowości C kl do skonfigurowania na wyjściowym interfejsie rutera łącza l dla ruchu klasy k przez następującą formułę: C kl = M[ k, s] s δ ls Dane wejściowe związane z topologią sieci i rutingiem (rozmieszczenie ścieŝek) przekazywane są z modułu ROMAN do modułu RMS. Konfiguracja wymogów QoS przechowywana jest w pliku qos.txt, natomiast wartości zapotrzebowań zapisane są w pliku demands.txt. Rysunek 1-3 pokazuje algorytm przedzielenia pasma dla poszczególnych ścieŝek i klas ruchu. 6

Start fac=? l_=1 M*[l_]=0 k_=1 l_=1 C[l_,k_]=0 s_=1 s_=1 δ l_s_ =1? TAK k_=1 NIE s_++ δ l_s_ =1? NIE TAK C[l_,k_]= C[l_,k_]+M[k_,s_] s_++ M*[l_]= M*[l_]+M[k_,s_] s_=s? NIE s_++ k_=k? s_=s? l_=l? TAK TAK C l_/m*[l_]<fac _? TAK fac= C l_/m*[l_] NIE NIE NIE k_++ s_++ NIE l_++ l_=l? TAK TAK k_=k? l_=1 TAK Σ CoS C[l_,k_]>C l_? TAK s_=1 NIE NIE l_++ k_++ l_++ NIE l_=l? TAK KONIEC NIE TAK M[k_,s_]= M[k_,s_] fac δ l_s_ =1? NIE s_++ TAK k_=1 M[k_,s_]=M[k_,s_] C l_/ Σ CoSC[l_,k_] k_=k? TAK NIE k_++ Rysunek 1-3: Algorytm przedzielenia pasma. L liczba łączy, S liczba ścieŝek, K liczba klas, C l przepustowość łączy l, M[k,s] macierz zapotrzebowań, pozostałe zmienne losowe pomocnicze Po obliczeniu wartości pasma dla poszczególnych klas usług rozpatrujemy rozmiar buforów dla danych klas. Następnie przedstawiono potrzebne rozmiary buforów dla kaŝdej klasy usług. Długość bufora przydzielona dla kaŝdej klasy zaleŝy od moŝliwości szeregowania w ruterach. Na przykład, do niedawna rutery CISCO pozwalały pracować z maksymalnym całkowitym rozmiarem kolejki o 7

długości 64 pakietów (dla wszystkich klas). Podsumowując przedstawione w dalszej części rozmiary buforów są tylko wartościami względnymi uwzględniającymi maksymalny rozmiar kolejki (moŝliwości szeregowania ruterów). Klasa Signalling: Wymiarowanie zasobów dla ruchu sygnalizacyjnego jest dość skomplikowane. Najnowsze badania [Mong09] pokazały, iŝ pojedyncza procedura zestawienia połączenia w przykładowej architekturze sieci Następnej Generacji potrzebuję przynajmniej 30 [kbps]. Jeśli mamy zarezerwowane pasmo C SIG dla ruchu sygnalizacyjnego, wtedy moŝemy dopuścić do systemu maksymalnie C SIG /30 procedur zestawienia połączenia. Jedna procedura zestawienia połączenia wysyła jednocześnie do sieci N wiadomości, gdzie N jest liczba Physical Entities w systemie według referencji [B1] rozdział 3.1. Zestawienie połączenia. Dlatego rozmiar bufora dla klasy Signalling moŝemy liczyć według następującego wzoru: B CSIG [ kbps] = 30 [ kbps] SIG N [ packets] Klasa RT Interactive: Obliczanie rozmiaru bufora dla tej klasy musi uwzględniać maksymalną wartość zmiany opóźnienia (IPDV) według następującego wzoru: IPDV RT B [ s] = RT d RT [ Bytes / packet] 8 hop C RT [ kbps] gdzie: d RT - największa długość pakietów wszystkich strumień RT, hop - liczbą skoków dla najdłuŝszej ścieŝki, B RT - długość bufora dla tej klasy, C RT - podzielonym pasmem dla klasy RT. Klasy usług MM Streaming oraz HTD wymagają małych strat pakietów [B2]. Dlatego rozmiar bufora powinien być wystarczająco duŝy, aby zminimalizować liczbę odrzuconych pakietów naleŝących do tych klas usług. Z drugiej strony, wymaganie na opóźnienie (IPTD) jest 0.5 [s] dla opóźnienia od końca do końca [B2] podczas, gdy nie ma wymagań dla zmienności opóźnienia. Dla klas usług MM Streaming i HTD wymiarowanie bufora na podstawie wartości opóźnienia nie jest realizowane. Dlatego opóźnienie zaleŝy od obciąŝenia (ρ) podobnie jak poziom strat pakietów. Jedynie, moŝna obliczyć rozmiar bufora dla maksymalnego opóźnienia. Przypadek ten będzie miał miejsce, gdy bufor jest zawsze pełny (ρ 1). Wtedy bufor moŝna obliczyć według następującego wzoru: gdzie: IPTD MMS / HTD ( B [ s] = MMS / HTD + 1) d C MMS / HTD MMS / HTD [ Bytes / packet] 8 hop [ kbps] 8

d MMS/HTD - największa długość pakietów wszystkich strumień MMS lub HTD, hop - liczbą skoków dla najdłuŝszej ścieŝki, B MMS/HTD - długość bufora dla klasy MMS lub HTD, C MMS/HTD - podzielonym pasmem dla klasy MMS lub HTD. Dla powyŝszych wartości długości bufora na podstawie IPTD jest przewymiarowana (normalnie ρ<1). Jeśli wyliczony rozmiar bufora okazuje się zbyt mały (to będzie znaczyło zbyt duŝe przewymiarowanie), wtedy wybieramy większy rozmiar bufora w naszej implementacji, około 100 pakietów jako wartość minimalna. PoniŜsza tabela krótko podsumowuje wzory wykorzystane w implementacji do obliczania rozmiarów buforów dla poszczególnych klas usług. Dane potrzebne do wyliczenia rozmiarów buforów znajdują się w pliku qos.txt jako część modułu RMS. Tabela 1-1: Zdefiniowane klasy usług - stan implementacji systemu (etap D) dla modułu zarządzania zasobami(moduł RMS) Klasa usług Formuła Wartości Signalling CSIG [ kbps] BSIG = N [ packets] 50 [ kbps] C SIG przepustowość (plik) N liczba Physical Entities w systemie (wartość ustalona) RT Interactive B RT = IPDVRT [ s] CRT [ kbps] IPDV Tel wartość zmiany opóźnienia d RT [ Bytes / packet] 8 hop (plik) C Tel przepustowość (plik) d RT długość pakietu (plik) hop hopów na najdłuższej ścieżce IPTDMMS CMMS IPTD MM Streaming BMMS = max 1, 100 packets} MMS wartość opóźnienia (plik) dmms 8 hop C MMS przepustowość (plik) D MMS długość pakietu (plik) hop hopów na najdłuższej ścieżce IPTDHTD CHTD IPTD HTD BHTD = max 1, 100packets} HTD wartość opóźnienia (plik) d HTD 8 hop C HTD przepustowość (plik) D HTD długość pakietu (plik) hop hopów na najdłuższej ścieżce 9

2 Stan implementacji węzłów systemu 2.1 Węzeł RMS (Resource Management Subsystem) Węzeł RMS odpowiada za realizację algorytmu wymiarowania zasobów dla łączy w zaleŝności od dostępnych zasobów i rozpływu ruchu w domenie (rutingu) oraz algorytmu odpowiadającego za realokację zasobów. Realizacja tych zadań wymaga komunikacji z węzłem ROMAN oraz z węzłem PD-PE. W pierwszym etapie realizowana jest wersja uproszczona, która dokonuje statycznej alokacji zasobów. Podstawowym zadaniem węzła RMS jest określenie dla ruterów brzegowych (ER) przydzielonej pojemności dla kaŝdej klasy usług sieciowych w domenie. Pojemność ta jest wykorzystywana przez funkcję AC realizowaną w ruterach brzegowych. Ponad to węzeł RMS oblicza dla kaŝdego portu pojemności buforów dla poszczególnych klas usług zgodnie z raportem [B.2-6]. 2.1.1 Opis działania interfejsów oferowanych przez węzeł Podczas działania modułu RMS za pomocą metody topologyhaschanged() odbierane są zdarzenia od modułu ROMAN informujące o zmianie topologii sieciowej. Sama metoda nie przenosi struktur danych, jedynie ma na celu zasygnalizowanie koniczności pobrania aktualnych danych od węzła ROMAN. Za pomocą metody requesttopology() węzeł RMS pobiera od węzła ROMAN aktualną topologię sieci. Dodatkowo węzeł RMS podczas działania moŝe być powiadamiany przez węzeł ROMAN o zmianie ścieŝek w sieci za pomocą metody routingpathshavechanged(). Podobnie jak poprzednia metoda, tak i w tym przypadku nie przekazuje dodatkowych danych. Z tego powodu węzeł RMS za pomocą metody requestpath() pobiera aktualną strukturę danych zawierającą aktualne ścieŝki w sieci. W interfejsie RomanToRms zdefiniowano metody: topologyhaschanged() oraz routingpaths- HaveChanged() umoŝliwiające przesłanie informacji od węzeł ROMAN do węzła RMS odpowiednio o zmianie topologii sieciowej lub zmianie ścieŝek. Natomiast w interfejsie RmsToRoman zdefiniowano metody: requesttopology() oraz requestpath() umoŝliwiające pobranie przez moduł RMS aktualnych struktur danych opisujących aktualną topologię sieci lub aktualne ścieŝki. Rysunek 2-1 przedstawia sekwencję wiadomości przesyłaną między węzłami ROMAN, RMS oraz PD-PE podczas aktualizacji ścieŝek i topologii sieciowej. 10

ROMAN RMS PD-PE topologyhaschanged() [] requesttopology() [LinkList] routingpathshavechanged() [] requestpath() [RoutingPathList] configureresources(cacconflist) [bool] configureports(rouconflist) [] Rysunek 2-1: Sekwencja wiadomości aktualizacja topologii sieciowej i ścieŝek Po otrzymaniu nowych danych węzeł RMS uruchamia algorytm obliczający nowe wartości parametrów CAC i konfiguracji portów wyjściowych ruterów. Następnie nowe dane przesyłane są do węzła PD-PE w strukturach danych za pomocą metod: configureresources(cacconflist) oraz configure- Ports(RouConfList). Metoda configureresources(cacconflist) przekazuje jako parametr strukturę CacConfList zawierającą konfigurację ruterów brzegowych dla funkcji CAC (obliczanej na podstawie wyliczonej pojemności). Natomiast metoda configureports(rouconflist) przekazuje jako parametr strukturę RouConfList zawierającą konfigurację wykorzystywanych portów wyjściowych ruterów. W interfejsie RmsToPd zdefiniowano metody: configureresources(cacconflist) oraz configure- Ports(RouConfList) umoŝliwiające przesłanie konfiguracji od węzła RMS do węzła PD-PE odpowiednio o parametrach CAC i konfiguracji portów wyjściowych. Listingi specyfikacji interfejsów RomanToRms i PdToRms wraz ze specyfikacją struktur danych są zamieszczone w Załączniku A. 2.1.2 Interfejsy wykorzystywane przez węzeł Węzeł RMS wykorzystuje metody requesttopology() i requestpath() z interfejsu RmsToRoman oferowanego przez węzeł ROMAN oraz metody configureresources(), configureports(), requestresourcestate(), configurerequestresourcestate() z interfejsu PdToRms oferowanego przez węzeł PD-PE. Opis działania tych interfejsów i udostępnianych metod znajduje się odpowiednio w punktach 2.2 i 2.3. 2.1.3 Wymagania dla instalacji węzła Węzeł RMS zrealizowano z wykorzystaniem języka C++ i wymaga następujących składników: 11

Kompilator języka C++ (np. gcc w wersji 4.0 lub nowszy), Standardowa biblioteka C++, Bibliotekę ICE w wersji 3.3.0 dla języka C++, Kompilator slice2cpp. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/rms && make 2.1.4 Sposób konfiguracji węzła Węzeł RMS moŝna konfigurować za pomocą odpowiednich wpisów do następujących plików konfiguracyjnych: rms.cfg demands.txt qos.txt Dla działania węzła RMS jest wymagany plik konfiguracyjny rms.cfg, w którym są zawarte parametry konieczne dla właściwej pracy w środowisku ICE. Ten plik naleŝy konfigurować zgodne z dokumentacją dostarczaną razem ze środowiskiem ICE. W pliku kaŝdy wiersz odpowiada jednej grupie zapotrzebowań dla 5 klas, których ścieŝki rozpoczynają się w danym węźle rbx. Format wiersza: <rbx> <z1> <z2> <z3> <z4> <z5> gdzie: <rbx> - pierwszy ruter występujący na ścieŝkach (wartość domyślna default jest przeznaczona dla wszystkich niezdefiniowanych zapotrzebowań, które będą wykorzystać te parametry) <z1> - zapotrzebowanie dla klasy Signalling <z2> - zapotrzebowanie dla klasy Real Time <z3> - zapotrzebowanie dla klasy MM Streaming <z4> - zapotrzebowanie dla klasy High Throughput Data (HTD) <z5> - zapotrzebowanie dla klasy Standard Zapotrzebowania od <z1> do <z5> wyraŝone są wagami, a przydzielona pojemność będzie wprost proporcjonalna do podanych wag. W niektórych przypadkach plik z zapotrzebowaniami musi posiadać dodatkową pustą linie (w sieci testowej znak nowej linii na końcu pliku konfiguracyjnego jest niezbędny). W pliku qos.txt zapisane są wymagania na jakość przekazu pakietów dla poszczególnych klas (Tabela 2-1). W pliku dla odpowiednich klas określa się następujące metryki: poziom strat pakie- 12

tów IPLR (ang. IP Packet Loss Ratio), średnie opóźnienie przekazu pakietów IPTD (ang. IP Packet Transfer Delay), zmienność opóźnienia przekazu pakietów IPDV (ang. IP Packet Delay Variation), oraz rozmiar pakietu - d. Tabela 2-1 Wymagania na jakość przekazu pakietów dla poszczególnych klas Lp. Klasa IPLR IPTD IPDV d 1 Signalling X X X 2 RealTime X X X X 3 MMStreaming X X 4 HighThroughputData X X 5 Standard Format zawartości pliku qos.txt został przedstawiony poniŝej w ramce. Nazwy metryk pomiarowych podanych w nawiasach trójkątnych naleŝy zastąpić ich odpowiednimi wartościami. Signalling <IPLR> <IPTD> <IPDV> RealTime <IPLR> <IPTD> <IPDV> <d> MMStreaming <IPLR> <IPTD> HighThroughputData <IPLR> <IPTD> Standard gdzie: d - rozmiar pakietu [byte] IPLR - poziom strat pakietów (ang. IP Packet Loss Ratio) [sek.] IPTD - opóźnienie pakietów (ang. IP Packet Transfer Delay) [sek.] IPDV - wariancja opóźnienia pakietów (ang. IP Packet Delay Variation) [sek.] 2.1.5 Sposób uruchomienia węzła Uruchomienie węzła RMS musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł RMS naleŝy wykonać następujące polecenia: $ cd /opt/pbz/rms $./start_rms 2.2 Węzeł ROMAN (Routing Manager) 2.2.1 Opis działania interfejsów oferowanych przez węzeł W poniŝszej tabeli zawarto operacje, na interfejsach programowych pomiędzy współpracującymi modułami, które są udostępniane przez węzeł ROMAN. 13

Interfejs Operacja Opis RMS - ROMAN requesttopology() Pobranie topologii przez RMS od ROMANA. requestpaths() Pobranie ścieŝek rutingowych przez RMS od ROMANA. PD-PE - ROMAN requestaccessnetworks() Pobranie informacji o przynaleŝności podsieci (uŝytkowników) do poszczególnych ruterów brzegowymi przez PD-PE od ROMANA. Dane o sieciach lokalnych i topologii są wczytywane z pliku konfiguracyjnego conf.xml bądź są pobierane z bazy danych OSPF od jednego z ruterów w sieci. ŚcieŜki rutingowe są obliczane z wykorzystaniem jednego z dostępnych algorytmów rutingowych. Zaimplementowano algorytmy: Dijkstra, Kruskal oraz SAMCRA. Dodatkowo zaimplementowano cztery róŝne warianty modyfikacji wag przy obliczeniach ścieŝek rutingowych. Przy obliczaniu ścieŝek rutingowych uŝyto następującego oszacowania na przepustowość pomiędzy parą ruterów brzegowych: przepustowość najmniejszego łącza dostępowego C QoS = -------------------------------------------------- liczba ruterów brzegowych - 1 PowyŜszy wzór wynika z wymiarowania zasobów przyjętego w raporcie [B3] oraz realizacji funkcji AC jedynie w ruterach dostępowych. Wartość przepustowości łącza dla klasy QoS jest ograniczona i nie moŝe być większa niŝ C QoS. Kod implementujący interfejsy RMS-ROMAN oraz PDPE-ROMAN znajduje się w pliku roman.cs, gdzie umieszczono klasy: PdToRomanI oraz RmsToRomanI zawierające metody implementujące operacje, które oferuje węzeł. Są to odpowiednio: requestaccessnetworks(), requesttopology() oraz requestpaths(). Dane o topologii sieci oraz sieciach dostępowych są przechowywane w instancji klasy Repository, która uŝywa struktur Hashtable do przechowywania danych o sieci. Udostępnione są następujące metody publiczne: Metoda addaccessnetwork Opis Dodanie sieci dostępowej do repozytorium. 14

addtopologylink addpath getaccessnetworks gettopology getpaths Fill Dodanie łącza do repozytorium. Dodanie ścieŝki do repozytorium. Pobranie sieci dostępowych z repozytorium. Pobranie topologii sieci z repozytorium. Pobranie ścieŝek z repozytorium. Wczytanie łączy, ścieŝek i sieci dostępowych z pliku conf.xml do repozytorium. W przypadku uŝycia opcji pobierania informacji o topologii sieci z bazy danych OSPF ruterów wykorzystywana jest klasa OspfDiscovery, której implementacja znajduje się w pliku ospfdiscovery.cs. W uproszczeniu operacja polega na zdalnym zalogowaniu się do wybranego rutera (wskazanego w pliku konfiguracyjnym conf.xml) i wykonaniu szeregu komend wyświetlających informacje z bazy danych OSPF, tablicy rutingu oraz listy interfejsów rutera. Następnie naleŝy przeanalizować otrzymane od rutera odpowiedzi i wpisać otrzymane rezultaty do struktur danych repozytorium. Realizowane jest to poprzez następujące metody klasy OspfDiscovery: Metoda Start LoginToRouter GetInterfacesData Opis Główna metoda klasy, wywołująca pozostałe metody, które realizują zadania cząstkowe. Zdalne logowanie do rutera zdefiniowanego w pliku conf.xml w sekcji: ospfdataprovidingrouter. Pobieranie danych o interfejsach rutera, takich jak: nazwa interfejsu, adres IP oraz szybkośc bitową. Wykorzystywana jest komenda: show interfaces include Internet address BW Ethernet[0-9]". ExtractInterfacesData Analizowanie otrzymanej odpowiedzi z metody GetInterfacesData() i wstawia dane interfejsów do repozytorium. GetTopology ExtractTopology Pobieranie danych (topologia)z bazy danych OSPF. Wykorzystywana jest komenda: "show ip ospf database network include State Attached". Analizowanie otrzymanej odpowiedzi z metody GetTopology() i wstawianie danych do repozytorium. ExtractNodesFromLinks Przeglądanie tablicy łączy i tworzenie tablicy węzłów. 15

W celu automatycznej pracy na zdalnym ruterze zaimplementowano klasę Robot znajdującą się w pliku robot.cs. Jej funkcjonalność umoŝliwia połączenie się ze zdalnym ruterem, wysyłanie komend oraz oczekiwanie na odpowiedź, która moŝe być zadana w formie wyraŝenia regularnego (czyli specjalnego filtru sprawdzającego dopasowanie dla ciągu znaków). Algorytmy rutingowe zaimplementowano w pliku routingalgo.cs odpowiednio w klasach Samcra, Dijkstra oraz Kruskal. Wszystkie te klasy implementują interfejs IRoutingAlgo, który zawiera tylko dwie metody: Metoda SetLinks CalculateRouting Opis Ustawienie danych wejściowych dla algorytmu rutingu czyli danych o topologii sieci: łącza i przepływność łączy. Obliczenie rutingu i zwrócenie wyniku w postaci tablicy ścieŝek. 2.2.2 Interfejsy wykorzystywane przez węzeł Interfejs Operacja Opis ROMAN - RMS topologyhaschanged() Wiadomość informująca RMS, Ŝe ROMAN wykrył zmianę topologii sieci. RMS powinien w odpowiedzi wywołać requesttopology() w celu uaktualnienia topologii. routingpathshavechanged() Wiadomość informująca RMS o zmianie obliczonych ścieŝek przez ROMANA. RMS powinien w odpowiedzi wywołać requestpaths() w celu uaktualnienia ścieŝek rutingowych. PD-PE - ROMAN configureaccessnetworks() Wysłanie sieci dostępowych znajdujących się za ruterami brzegowymi przez ROMANA do PD-PE. W przypadku zmiany konfiguracji sieci węzeł ROMAN uaktualnia listę prefiksów sieci lokalnych w interfejsie RomanToPd za pomocą metody configureaccessnetworks(). W interfejsie RomanToRms wykorzystywane są metody topologyhaschanged() oraz routingpaths- HaveChanged(), które informują odpowiednio o zdarzeniach zmiany topologii sieci oraz obliczeniu nowych ścieŝek rutingowych. Przyjęto, Ŝe zawsze zmiana topologii pociąga za sobą rekonfigurację 16

ścieŝek i dlatego ROMAN zawsze przy wykryciu zmiany topologii oraz przy starcie wywołuje obie te metody. 2.2.3 Konfiguracja ruterów Konfiguracja rutingu w sieci sprowadza się do ustawienia ścieŝek tuneli MPLS. Korzystamy ze wstępnie skonfigurowanych ruterów, które mają ustanowione interfejsy tunelowe pomiędzy kaŝdą parą ruterów brzegowych. ROMAN ustawia dla tych tuneli dokładną ścieŝkę za pomocą komendy: ip explicit-path z podaniem kolejnych węzłów pośrednich. Implementacja konfiguracji ruterów jest zawarta w klasie PathConfigurator znajdującej się w pliku pathconfigurator.cs. Wykorzystywana jest opisana wcześniej klasa Robot. 2.2.4 Wymagania dla instalacji węzła Węzeł ROMAN wymaga instalacji następujących komponentów: maszyny wirtualnej MONO w wersji 1.9.1, kompilatora języka C# dla platformy.net 2.0 - gmcs, generatora klas dla schematu XML xsd, znajdującego się w narzędziach platformy MO- NO, biblioteki ICE w wersji 3.3.0 dla platformy.net, kompilatora slice2cs znajdującego się w narzędziach biblioteki ICE. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/roman && make W ten sposób węzeł ROMAN jest gotowy do uruchomienia. 2.2.5 Sposób konfiguracji węzła Konfiguracja węzła ROMAN zawarta jest w dwóch plikach. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/roman/ice.cfg, który definiuje parametry konfiguracji biblioteki ICE. Określono tylko jeden parametr - Ice.Default.Locator, który identyfikuje lokalizację rejestru nazw ICE. Drugim plikiem konfiguracyjnym jest conf.xml. Jest to poprawny dokument w formacie XML 1.0, który jest zgodny ze schematem XML zdefiniowanym w pliku conf.xsd. W pliku określono pięć sekcji głównych: Main opisuje główne parametry konfiguracyjne węzła ROMAN. Obecnie zdefiniowano trzy pola: o topologysource określa źródło informacji o topologii sieci. Dopuszczalne wartości: 17

file plik konfiguracyjnego conf.xml (sekcja Topology i AccessNetworkList), ospf baza danych OSPF pobierana z wyznaczonego rutera z sieci, o ospfdataprovidingrouter wyznaczony ruter w sieci, z którego jest pobierana baza danych OSPF przy ustawionej opcji topologysource na wartość ospf, o routingalgo określa algorytm uŝywany do obliczania ścieŝek rutingowych. Dopuszczalne wartości: file ruting wczytywany z pliku konfiguracyjnego conf.xml (sekcja Routing), Dijkstra algorytm Dijkstry, Kruskal algorytm Kruskala, SAMCRA algorytm SAMCRA; BorderRouters lista ruterów brzegowych. Sekcja moŝe zawierać jedną lub kilka podsekcji <router>, które definiują ruter poprzez następujące parametry: o routerid identyfikator rutera, np.: RB1, o routerip adres IP rutera brzegowego; AccessNetworkList lista prefiksów sieci lokalnych. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><topologySource> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Network>, które definiują poszczególne sieci lokalne za pomocą następujących parametrów: o netprefix prefiks sieci wraz z maską, np.: 10.1.0.0/16, o routerid identyfikator rutera, np:. RB1, o routerip adres IP rutera brzegowego, za którym jest dana sieć lokalna; Topology topologia sieci. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><topologySource> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Link>, które definiują poszczególne łącza w sieci za pomocą następujących parametrów: o Name identyfikator/nazwa łącza, o SourceRouter ruter początkowy. Sekcja zawiera trzy parametry opisujące ruter: routerid identyfikator rutera, routerip adres IP rutera, routertype typ rutera, dopuszczalne wartości: Border (brzegowy) i Core (szkieletowy), 18

o SinkRouter ruter końcowy. Parametry analogiczne jak dla pierwszego rutera, o PortName nazwa fizycznego portu na ruterze, o Capacity przepływność łącza w [Mbit/s]; Routing lista ścieŝek rutingowych. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><routingAlgo> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Path>, które definiują poszczególne ścieŝki w sieci za pomocą następujących parametrów: o ClassOfService nazwa klasy usług sieciowych, o Capacity przepływność przeznaczona dla tej klasy w [Mbit/s], o Routers uporządkowana lista identyfikatorów ruterów na ścieŝce, zgodna z kolejnością przebiegu ścieŝki rutingowej, np.: <Routers> <Router>192.168.0.1</Router> <Router>192.168.0.3</Router> <Router>192.168.0.4</Router> <Router>192.168.0.2</Router> </Routers> 2.2.6 Konfiguracja systemu w laboratorium Wykonane oprogramowanie projektu IP QoS będzie testowane i demonstrowane w sieci laboratoryjnej w Instytucie Łączności opisanej w [B8] i [D6]. ROMAN wymaga, aby rutery brzegowe i szkieletowe były wstępnie skonfigurowane do przesyłania ruchu MPLS. W szczególności naleŝy wykonać następujące operacje: włączenie MPLS na interfejsach fizycznych: interface GigabitEthernet0/1 mpls ip mpls traffic-eng tunnels ip rsvp bandwidth 750000 750000 włączenie rutingu OSPF, utworzenie tuneli pomiędzy parą ruterów brzegowych: interface Tunnel1 description tunel1 tunnel destination 192.168.0.2 tunnel mpls traffic-eng path-option 1 explicit name sciezka_1 tunnel mpls traffic-eng record-route no routing dynamic 19

KaŜdy ruter w sieci laboratoryjnej posiada adresy IP związane z interfejsami fizycznymi rutera oraz adres logiczny, który jest unikalny w całej sieci (interfejs Loopback0). ROMAN uŝywa adresów interfejsów Loopback0 przy konfigurowaniu tuneli MPLS. W ramach testów laboratoryjnych aplikacja ROMAN będzie uruchamiana w fazie wstępnej konfiguracji sieci. Po uruchomieniu będzie następowało wykrycie topologii sieci, obliczenie ścieŝek rutingowych i skonfigurowanie tuneli MPLS. Następnie funkcjonalność ROMANa ograniczy się do udostępniania danych o topologii sieci i zestawionym runtingu dla innych aplikacji systemu. 2.2.7 Sposób uruchomienia węzła Uruchomienie węzła ROMAN musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł ROMAN naleŝy wykonać następujące polecenia: $ cd /opt/pbz/roman $ sh start_roman.sh 2.3 Węzeł PD-PE (Policy Decision Physical Entity) 2.3.1 Opis działania interfejsów oferowanych przez węzeł Węzeł PD-PE uczestniczy w procesie ustalenia rutingu w domenie. Węzeł PD-PE otrzymuje od węzła ROMAN informację o przynaleŝności adresów klientów do poszczególnych ruterów. Funkcja ta jest realizowana za pomocą metody configureaccessnetworks() w interfejsie RomanToPd. Po otrzymaniu aktualnej listy przynaleŝności adresów klientów do ruterów, stara lista jest usuwana. Węzeł PD-PE przekazuje informację w procesie konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń oraz w procesie konfiguracji zasobów dla interfejsu wyjściowego rutera. Obie funkcje znajdują się w interfejsie RmsToPd i są to odpowiednio configureresources() oraz configureports(). W przypadku procesu konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń węzeł PD-PE odszukuje odpowiednie węzły TRC-PE i przekazuje do nich Ŝądania. W przypadku procesu konfiguracji zasobów dla interfejsu wyjściowego rutera węzeł PD-PE odszukuje odpowiednie węzły PE-PE i przekazuje do nich Ŝądania. 2.3.2 Interfejsy wykorzystywane przez węzeł Węzeł PD-PE po uruchomieniu komunikuje się z węzłem ROMAN aby otrzymać informację o przynaleŝności adresów klientów do poszczególnych ruterów uczestniczy. Działanie to jest związane z procesem ustalenia rutingu w domenie. W wyniku uruchomienia funkcji requestaccessnetworks() naleŝącej do interfejsu PdToRoman jest uzyskiwana lista przynaleŝności adresów klientów do ruterów. W czasie procesu monitorowania stanu wykorzystania zasobów węzeł PD-PE przekazuje raporty (tworzone przez węzły TRC-PE) poprzez metodę reportresourcestate() w interfejsie PdToRms. W 20

implementacji węzła PD-PE dla etapu C funkcjonalność ta nie została zaimplementowana. Przewidujemy, Ŝe zostanie ona zrealizowana w etapie D. 2.3.3 Wymagania dla instalacji węzła Węzeł PD-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji 3.3.0 dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Bibliotekę języka Python: threadpool. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/pdpe && make Po spełnieniu powyŝszych wymagań węzeł PD-PE jest gotowy do uruchomienia. 2.3.4 Sposób konfiguracji węzła Konfiguracja węzła PD-PE znajduję się w pliku konfiguracyjnym /opt/pbz/pdpe/pdpe.cfg, który zawiera dwie sekcje [pdpe] i [ice]. W sekcji [pdpe] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów PD-PE, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 50. 21

2.3.5 Sposób uruchomienia węzła Uruchomienie węzła PD-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł PD-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/pdpe $ python pdpe.py 2.4 Węzeł TRC-PE (Transport Resource Control Physical Entity) 2.4.1 Opis działania interfejsów oferowanych przez węzeł Węzeł TRC-PE realizuje algorytm przyjmowania nowych połączeń i jest elementem końcowym w procesie konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń. W tym celu w interfejsie PdToTrc wyróŝniono metodę configureresources(), której parametrem jest opis konfiguracji zasobów z podziałem na poszczególne klasy usług. Po uruchomieniu tej metody wykonywane są następujące działania: Węzeł TRC-PE identyfikuje w bazie danych poszukiwany punkt realizacji algorytmu przyjmowania połączeń. W przypadku, gdy punkt nie zostanie odnaleziony metoda zwraca wynik negatywny. Wśród opisu konfiguracji zasobów znajduje się przepływność i rozmiar bufora przydzielony dla danej klasy usług oraz wymagany poziom strat pakietów. Na podstawie tych parametrów wyliczane jest maksymalne dopuszczalne obciąŝenie, które określane jest za pomocą algorytmu przyjmowania połączeń. Wartość ta zostaje zapisana w bazie danych. W przypadku gdy algorytm przyjmowania nowych połączeń nie wspiera danej klasy usług, metoda zwraca wynik negatywny. Po obsłuŝeniu wszystkich grup opisujących zasoby algorytm zwraca wyniki pozytywny. ZauwaŜmy, Ŝe moŝe wystąpić sytuacja, w której aktualny poziom zajętości zasobów moŝe przekraczać nowe maksymalne obciąŝenia danej klasy usług. W obecnej wersji implementacji zjawisko to jest ignorowane, jednak w docelowej wersji systemu zostanie zastosowany algorytm zwalniający zasoby wśród działających połączeń w sposób minimalizujący liczbę rozłączonych połączeń. 2.4.2 Interfejsy wykorzystywane przez węzeł Węzeł TRC-PE nie wykorzystuje zewnętrznych interfejsów w przypadku procesów zarządzania zasobami. 2.4.3 Wymagania dla instalacji węzła Węzeł TRC-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, 22

Bibliotekę ICE w wersji 3.3.0 dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Biblioteki języka Python: threadpool, SQLAlchemy, psycopg2, Bazę danych PostrgreSQL w wersji 8.3. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/trc && make W bazie danych PostgreSQL naleŝy stworzyć bazę danych o nazwie pbz_trc dla uŝytkownika user (parametry te moŝna zmienić w pliku /opt/pbz/trc/trc.cfg w parametrze konfiguracyjnym o nazwie database_string). Następnie naleŝy przygotować strukturę bazy danych za pomocą polecenia $ cd /opt/pbz/trc/database && python db_create.py Po spełnieniu powyŝszych wymagań węzeł TRC-PE jest gotowy do uruchomienia. 2.4.4 Sposób konfiguracji węzła Konfiguracja węzła TRC-PE składa się z dwóch elementów. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/trc/trc.cfg, który zawiera dwie sekcje [trc] i [ice]. W sekcji [trc] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów TRC-PE, database_string określa dostęp do bazy danych PostrgreSQL, w tym nazwę uŝytkownika oraz nazwą bazy danych, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, emulation określa czy węzeł działa w trybie emulacji, w którym nie uŝywa się bazy danych, emulation_rate określa prawdopodobieństwo negatywnej odpowiedzi w przypadku działania a w trybie emulacji. W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, 23

Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 50. Druga część konfiguracji węzła TRC-PE znajduje się w bazie danych. Plik /opt/pbz/trc/database/db_dummyfill.py przedstawia przykładowy sposób wypełnienia bazy danych. Jego główne elementy to klasy TrcPoint i TrcResource, które definiują punkty algorytmu przyjmowania nowych połączeń oraz wspierane klasy usług. 2.4.5 Sposób uruchomienia węzła Uruchomienie węzła TRC-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry), serwera konfiguracyjnego systemu (katalog /opt/pbz/config) oraz bazy danych PostgreSQL. Aby uruchomić węzeł TRC-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/trc $ python trc.py 2.5 Węzeł PE-PE (Policy Enforcement Physical Entity) 2.5.1 Opis działania interfejsów oferowanych przez węzeł Węzeł PE-PE zarządza konfiguracją urządzeń i jest elementem końcowym w procesie konfiguracji zasobów dla interfejsu wyjściowego rutera. W tym celu w interfejsie PdToPe wyróŝniono metodę configureports(), której parametrem jest opis konfiguracji interfejsu rutera. Opis ten zawiera podział zasobów dla poszczególnych klas usług włączając m.in. przepływności oraz rozmiary buforów. 2.5.2 Interfejsy wykorzystywane przez węzeł Węzeł PE-PE jest skrajnym elementem łańcucha sygnalizacji i sam nie wykorzystuje interfejsów systemowych. Z drugiej strony węzeł ten kontaktuje się z urządzeniami sieciowymi, jednak ten sposób komunikacji jest specyficzny dla kaŝdego urządzenia i nie jest przedmiotem tego raportu. 2.5.3 Wymagania dla instalacji węzła Węzeł PE-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji 3.3.0 dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Biblioteki języka Python: threadpool. 24

W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/pepe && make Węzeł PE-PE wykorzystuje lokalną bazę danych, której zawartość trzeba przygotować przed uruchomieniem węzła. Przykładowe skrypty z zawartością znajdują się w zbiorach db_fill_dummy_core.py i db_fill_dummy_edge.py. MoŜna je wykorzystać aby stworzyć strukturę bazy danych za pomocą polecenia $ cd /opt/pbz/pepe && python db_fill_dummy_edge.py Po spełnieniu powyŝszych wymagań węzeł PE-PE jest gotowy do uruchomienia. 2.5.4 Sposób konfiguracji węzła Konfiguracja węzła PE-PE składa się z dwóch elementów. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/pepe/pepe.cfg, który zawiera dwie sekcje [pepe] i [ice]. W sekcji [pepe] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów PE-PE, database_string określa dostęp do bazy danych przechowującej konfigurację węzła, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 50. Druga część konfiguracji węzła PE-PE znajduje się w bazie danych. Zbiory db_fill_dummy_core.py i db_fill_dummy_edge.py przedstawiają przykładowy sposób wypełnienia bazy danych, odpowiednio dla rutera szkieletowego oraz rutera brzegowego. 25

2.5.5 Sposób uruchomienia węzła Uruchomienie węzła PE-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł PE-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/pepe $ python pepe.py 2.6 Serwer konfiguracyjny systemu 2.6.1 Opis działania interfejsów oferowanych przez serwer Sewer konfiguracyjny systemu jest serwerem pomocniczym, który nie jest związany bezpośrednio z Ŝadnym procesem systemu. Pozwala on jednak w łatwy sposób automatycznie skonfigurować zaleŝności pomiędzy węzłami za pomocą usługi rejestru icegridregistry. Serwer konfiguracyjne systemu rejestruje znane nazwy w rejestrze, które wykorzystywane są przez węzły podczas ich uruchamiania. W przypadku tego raportu istotne są: configurationpd@ dostęp do interfejsu konfiguracyjnego dla węzła PD-PE, configurationtrc@ dostęp do interfejsu konfiguracyjnego dla węzła TRC-PE, configurationpe@ dostęp do interfejsu konfiguracyjnego dla węzła PE-PE, configurationroman@ dostęp do interfejsu konfiguracyjnego dla węzła ROMAN, configurationrms@ dostęp do interfejsu konfiguracyjnego dla węzła RMS. 2.6.2 Wymagania dla instalacji serwera Serwer konfiguracyjny systemu wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji 3.3.0 dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, W celu przygotowania serwera do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/config && config Po spełnieniu powyŝszych wymagań serwer konfiguracyjny systemu jest gotowy do uruchomienia. 2.6.3 Sposób konfiguracji serwera Konfiguracja serwera konfiguracyjnego systemu znajduje się w pliku /opt/pbz/config/config.cfg, który zawiera dwie sekcje [config] i [ice]. 26

W sekcji [config] wyróŝniamy: debug określa poziom szczegółowości wyświetlanych informacji o działaniu serwera; dozwolone wartości to true i false. W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, 2.6.4 Sposób uruchomienia serwera Uruchomienie serwera konfiguracyjnego musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry). Aby uruchomić serwer konfiguracyjny systemu naleŝy wykonać następujące polecenia: $ cd /opt/pbz/config $ python config.py 2.7 Kolejność uruchamiania węzłów systemu Rysunek 2-2 przedstawia wymaganą kolejność uruchamiania poszczególnych elementów oprogramowania systemu. Pierwszym krokiem jest uruchomienie serwera rejestru icegridregistry. Drugim krokiem jest uruchomienie serwera konfiguracyjnego. Serwery znajdujące się w kroku trzecim mogą być uruchomione w dowolnej kolejności. Ponadto jest moŝliwe ponowne uruchomienie kaŝdego serwera ( zresetowanie ) w dowolnym stabilnym momencie, tzn. gdy nie są obsługiwane wywoływania. Podobnie postępujemy w kroku czwartym. Gdy wszystkie węzły zostaną uruchomione moŝna uruchomić aplikację testową. 1 icegridregistry 2 Serwer konfiguracyjny 3 SCE PD-PE TRC-PE PE-PE 4 RMS ROMAN 5 Aplikacja testowa Rysunek 2-2: Kolejność uruchamiania oprogramowania systemu 27

3 Podsumowanie W etapie D zostały zaimplementowane wszystkie węzły związane z zarządzaniem zasobami sieci. System IP QoS wymiaruje zasoby sieci zgodnie z załoŝonymi algorytmami oraz wymaganiami jakości przekazu pakietów. W szczególności system zarządza stanem zasobów w punktach przyjmowania nowych połączeń oraz zarządza konfiguracją mechanizmów sterowania ruchem w ruterach. Opis stanu implementacji został podzielony ze względu na poszczególne węzły funkcjonalne systemu, czyli węzły RMS, ROMAN, PD-PE, TRC-PE i PE-PE. Ponadto opisano serwer konfiguracyjny systemu, który jest elementem pomocniczym związanym z konfiguracją i zarządzaniem oprogramowania. Tabela 3-1 podsumowuje szczegóły stanu implementacji na zakończenie etapu D. Tabela 3-1: Stan implementacji systemu dla etapu D procesy zarządzania zasobami Nazwa Definicja interfejsu w języku SLICE Stan implementacji Węzeł RMS Węzeł ROMAN Węzeł PD-PE RmsToPd: TAK RmsToRoman: TAK RomanToPd: TAK RomanToRms: TAK RmsToPd: TAK RomanToPd: TAK TrcToPd: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem PD-PE Węzeł współpracuje z węzłem ROMAN Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem PD-PE Węzeł współpracuje z węzłem RMS Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem ROMAN Węzeł współpracuje z węzłem RMS Węzeł współpracuje z węzłem TRC-PE Węzeł TRC-PE PdToTrc: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł automatycznie rejestruje się w węzłach PD-PE 28

Węzeł PE-PE PdToPe: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł automatycznie rejestruje się w węzłach PD-PE konfigura- Serwer cyjny TAK specjalne interfejsy Serwer został zaimplementowany Serwer obsługuje węzły RMS, ROMAN, PD-PE i TRC-PE. 29

Literatura [A8] [B1] [B3] [B7] [B8] [D6] [Mong09] [RFC2475] W. Burakowski et. al., Opracowanie wymagań na system IP QoS, -MNiSW-02- II/2007/WUT/A.1, 2008. W. Burakowski et. al, Raport B.1: Specyfikacja architektury systemu IP QoS, -MNiSW- 02-II/2007/WUT/B.1, 2009. S. Kaczmarek et. al., Specyfikacja metod i algorytmów zarządzania zasobami w systemie IP QoS, -MNiSW-02-II/2007/PG/B.3, 2009. P. Pyda, T, Dalecki, Specyfikacja metody rutingu w sieci IP QoS, -MNiSW-02- II/2007/WIŁ/B.7, 2009. H. Gut et. al., Specyfikacja i instalacja sieci laboratoryjnej IP QoS, -MNiSW-02- II/2007/IŁ-PIB/B.8, 2009. H. Gut et. al., Integracja oprogramowania i instalacja w sieci laboratoryjnej IP QoS - część II, -MNiSW-02-II/2007/PW/D.6, 2009. J.Mongay Batalla, J. Śliwiński, H.Tarasiuk and W.Burakowski, Impact of Signaling System Performance on QoE In Next Generation Networks, Journal of Telecommunications and Information Technology, 4/2009, str. 124-137. S. Blake, et al., An Architecture for Differentiated Services, Internet RFC 2475, December 1998. 30

Lista skrótów CAC PD-PE PE-PE ROMAN RMS SCE TRC-PE Connection Admission Control Policy Decision Physical Entity Policy Enforcement Physical Entity Routing Management Resource Management System Service Control Entity Transport Resource Control Physical Entity 31

Załącznik A: Definicja interfejsów w języku SLICE Plik: router.ice #ifndef ROUTES_ICE #define ROUTES_ICE module pbz struct Router string name; string ipaddress; string type; // ingress, egress, core sequence<router> RouterList; struct AccessNetwork string prefix; Router borderrouter; sequence<accessnetwork> AccessNetworkList; struct Link bool com; string name; Router sourcerouter; Router sinkrouter; string portname; long capacity; sequence<link> LinkList; struct RoutingPath bool com; string classofservice; long capacity; RouterList pathnodes; sequence <RoutingPath> RoutingPathList; #endif Plik: rms_cac.ice #ifndef RMS_CAC_ICE #define RMS_CAC_ICE #include <router.ice> module pbz struct CacPolicy Router egressrouter; long maxcapacity; 32