Realizacja warstwy serwerów sterowania połączeniami dla ASON/GMPLS

Realizacja warstwy serwerów sterowania połączeniami dla ASON/GMPLS Sylwester Kaczmarek, Magdalena Młynarczuk, Marcin Narloch, Maciej Sac email: kasyl@eti.pg.gda.pl Afiliacja: Politechnika Gdańska, Wydział ETI, Katedra Sieci Teleinformacyjnych Słowa kluczowe: IP QoS, MPLS, ASON/GMPLS, RSVP-TE, DIAMETER, serwery sterowania połączeniem, testbed sieci serwerów Abstrakt W materiale przedstawiono wyniki prac badawczych wykonanych w ramach projektu PBZ w podprojekcie Architektury i protokoły sieciowe. Obejmują krótką charakterystykę wytworzonych modeli analitycznych i symulacyjnych przeznaczonych do badania sieci pakietowych z gwarancją jakości klas usług dla technologii IP QoS, MPLS, OBS oraz uzyskane wyniki. Jednakże główny punkt ciężkości został położony na sieci z architekturą ASON/GMPLS dla której badania skupiono na warstwie serwerów sterowania połączeniami, która odpowiadałaby koncepcji IMS. Omówiono specyfikację wymagań tej warstwy z punktu widzenia komunikacji w ramach własnej warstwy jak z warstwami sąsiednimi. Specyfikacji poddano także funkcjonalność i struktury danych konieczne dla realizacji funkcji sterowania. W oparciu o te specyfikacje wybrano protokoły komunikacyjne, bazy danych oraz zaproponowano rozwiązanie serwera sterowania połączeniami. Korzystając z otwartego oprogramowania projektu KOM RSVP dokonano adaptacji i uzupełnień tego oprogramowania na potrzeby niniejszego projektu i zrealizowano sieć serwerów sterowania połączeniami dla ASON/GMPLS wraz z emulacją warstwy serwerów sterowania usługą i zasobami dla realizacji funkcji transportu. Przeprowadzono badania realizacji założonej funkcjonalności i pomiary czasów zestawiania połączenia dla sieci złożonej z trzech i pięciu takich serwerów. Omówiono wyniki, przedstawiono wnioski i wynikające z nich kierunki dalszych prac. 1. Wprowadzenie Zmiany jakie zachodzą w obszarze działania dzisiejszych społeczności wskazują, że bardzo ważnym towarem staje się informacja, która może mieć wielorakie zastosowanie i przybierać różnorodne formy prezentacji. Ciągły wzrost ilości wytwarzanej informacji oraz potrzeba szybkiego jej udostępniania szerokiemu ogółowi jej odbiorców, w bezpośredniej lub przetworzonej postaci, spowodował potrzebę propozycji infrastruktury, która spełniałaby wymagania wynikające z zachodzących zmian. Infrastruktura ta obejmuje funkcjonalność wytwarzania, przetwarzania, udostępniania i z tym związanego przesyłania informacji. W wyniku prac prowadzonych na skalę międzynarodową dopracowano się koncepcji Globalnej Infrastruktury Informacyjnej (GII), która zawiera w sobie wyniki i wnioski z dwóch podstawowych obszarów działania określających architekturę GII, tzn. informatykę i telekomunikację. Nas z uwagi na cel Projektu Badawczego Zamawianego PBZ-MNiSW-02-II/2007 interesuje obszar telekomunikacji. Dla osiągnięcia celów i wymagań nałożonych na GII konieczne jest przebudowanie podejścia do realizacji funkcjonalności oferowanych przez telekomunikację. Ta nowa funkcjonalność i jej realizacja znalazły swe odbicie w koncepcji Sieci Następnej Generacji (NGN - Next Generation Network). Aspekt ekonomiczny i demonopolizacja rynku spowodowały, że realizacja tej koncepcji musi przebiegać w sposób ewolucyjny. Ewolucyjne przekształcanie istniejących rozwiązań i sieci zakłada, iż docelowo będą one oparte na technice pakietowej wykorzystującej w warstwie sieciowej Internet z protokołem IP. Aby spełnić wymagania stawiane sieciom NGN i oczekiwania społeczeństwa informacyjnego, któremu te sieci mają dostarczać usługi, utworzono model warstwowy tej sieci. W modelu tym wyróżniono, idąc od dołu, warstwę zasobów dla realizacji funkcji transmisji i komutacji (transportu), warstwę sterowania połączeniami, warstwę sterowania wywołaniami (usługami) oraz warstwę aplikacji wspierających usługi. W ramach projektu PBZ w zadaniu 2 Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej podprojektu Architektury i protokoły sieciowe, którego dotyczy niniejszy materiał, realizowano badania związane z warstwą serwerów sterowania połączeniami. Opis realizowanych zadań krótko przedstawiono w rozdziale 2. Ponieważ główny punkt ciężkości prac nakierowany był na praktyczną realizację tej warstwy dla architektury ASON/GMPLS to z uwagi na ograniczony rozmiar materiału dalsza jego część dotyczy tylko tego zagadnienia. Zatem w rozdziale 3 krótko scharakteryzowano architekturę ASON/GMPLS aby koncepcję jej realizacji w postaci testbedu przedstawić w rozdziale 4. Jego realizację omó- 1

wiono w rozdziale 5 a wyniki testowania w rozdziale 6. Materiał ten kończy podsumowanie. 2. Zrealizowane zadania W ramach drugiego zadania badawczego podprojektu Architektury i protokoły sieciowe projektu PBZ- MNiSW-02-II/2007 zrealizowane prace badawcze można podzielić na trzy obszary: teoretyczny, specyfikacji i realizacji. Każdy z obszarów dotyczy wybranych zagadnień z sieci następnej generacji i zostanie krótko scharakteryzowany w tym rozdziale. W obszarze teoretycznym przeprowadzono prace dotyczące modeli analitycznych i symulacyjnych umożliwiających badanie algorytmów sterowania zasobami w warstwie realizacji połączeń. Modele te dotyczyły technologii MPLS i OBS. W pierwszym przypadku opracowano algorytmy sterowania zasobami dla realizacji połączeń z wywłaszczaniem uwzględniające priorytety przewidziane w technologii MPLS. Ponieważ zagadnienie to nie jest proste w przypadku próby propozycji modeli analitycznych dla sensownych rozmiarów sieci dlatego też jako metodę badania przyjęto symulację komputerową. Opracowano od podstaw uniwersalny symulator przy pomocy którego zostały przebadane właściwości proponowanych algorytmów [5,10]. Uzyskano interesujące wyniki, które zostały opublikowane w pracy [7]. W przypadku technologii OBS, która jest propozycją realizacji techniki komutacji pakietów w technologii optycznej, zaproponowano nowe algorytmy umożliwiające różnicowanie klas usług. Dla tych algorytmów zaproponowano modele analityczne a dla ich weryfikacji zrealizowano model symulacyjny. Uzyskane wyniki zaprezentowano w pracy [11] i potwierdzają one dobre właściwości tych algorytmów oraz dobrą dokładność modeli analitycznych zweryfikowaną za pomocą modelu symulacyjnego. Osobnym zagadnieniem, które było badane w kontekście sterowania połączeniami był problem związany z przełączaniem dróg połączeniowych czy to w przypadku wywłaszczania czy też w przypadku dynamicznych algorytmów rutingu. Jest to mianowicie zjawisko zmiany kolejności pakietów przy przełączaniu dróg połączeniowych. Badanie dotyczyło stwierdzenia w jakich warunkach problem tego zjawiska jest istotny. Został w związku z tym zaproponowany model analityczno-symulacyjny, przy pomocy którego zostało zamodelowane wymienione zjawisko i przeprowadzono badania. Uzyskano wyniki, które wskazują że zjawisko to musi być uwzględniane w ocenie jakości usług gdy zachodzą określone warunki w intensywności przełączania dróg połączeniowych i różnicy czasów opóźnienia przełączanych dróg. Wyniki dotyczące tego problemu oraz rutingu dynamicznego zostały zamieszczone w pracach [1,2,4]. W przypadku specyfikacji prace dotyczyły warstwy serwerów sterowania połączeniami (zarządzania zasobami) a były one realizowane w kontekście przewidzianej późniejszej praktycznej realizacji tej warstwy serwerów w laboratorium dla prowadzenia badań funkcjonalnych i wydajnościowych. Zanim przystąpiono do specyfikacji przeprowadzono analizę funkcji sterowania w poszczególnych obszarach sieci, tzn. w dostępie, agregacji i szkielecie, z uwzględnieniem koncepcji sieci następnej generacji. Szczególną uwagę zwrócono na obszar agregacji i szkieletu [8], gdyż to dla tych obszarów miała być realizowana specyfikacja warstwy serwerów sterowania połączeniami. Specyfikacja funkcjonalności serwerów sterowania połączeniami została przeprowadzona osobno dla MPLS i dla ASON/GMPLS. Uwzględniono w niej nie tylko funkcjonalność wynikającą z tej warstwy ale także ze współpracy z sąsiednimi warstwami [9], w tym także zagadnienia komunikacji. Szczególną uwagę zwrócono na interfejsy (styki) i scenariusze współpracy oraz wymiany wiadomości. Określono zawartość informacyjną tych wiadomości. Opisy te wykonano dla styków zarówno między serwerami warstwy serwerów sterowania połączeniami, jak i tymi serwerami a warstwą serwerów usług i warstwą zasobów transportu. Także wyspecyfikowano zawartość baz danych tych serwerów. W konsekwencji tego przedstawiono koncepcję testbedu [3]. W dalszej kolejności została opracowana koncepcja algorytmów sterowania zasobami oraz modele baz danych i koncepcja ich realizacji [12]. Wymienione specyfikacje zostały przeprowadzone dla technologii MPLS i ASON/GMPLS, jednakże do prac w następnych etapach i praktycznej realizacji w laboratorium została wybrana jedynie warstwa serwerów sterowania połączeniami dla technologii ASON/GMPLS [14]. Praktyczna realizacja sieci warstwy serwerów sterowania połączeniami wymagała przetestowania i modyfikacji dla potrzeb projektu dostępnego otwartego oprogramowania protokołów komunikacyjnych RSVP-TE, Diameter, Netconf. Także konieczne było przetestowanie i modyfikacja otwartego oprogramowania serwera sterowania połączeniami. Założono wariantowość realizacji warstwy serwerów sterowania połączeniami: wariant I tylko warstwa serwerów sterowania połączeniami bez otoczenia tej warstwy z ograniczoną funkcjonalnością, wariat II z rozszerzoną funkcjonalnością oraz emulacja warstw sąsiednich [14]. Opisowi tej części projektu, tzn. praktycznej realizacji warstwy serwerów sterowania połączeniami dla ASON/GMPLS, zostanie poświęcona w całości dalsza część tego artykułu. 3. Architektura ASON/GMPLS Architektura ASON/GMPLS jest wynikiem prac standaryzacyjnych ITU-T (International Telecommunication Union Telecommunications Standardization Sector), IETF (Internet Engineering Task Force) jak również forum OIF (Optical Internetworking Forum). Oparta jest na koncepcji automatycznie komutowanej sieci 2

optycznej ASON (Automatic Switched Optical Network), wykorzystując do jej realizacji protokoły wieloprotokołowej komutacji etykietowej GMPLS (Generalized Multiprotocol Label Switching). Podstawowe założenia dla ASON i GMPLS zostały przedstawione w [6,18]. Warstwa serwerów sterowania połączeniami dla ASON/GMPLS oparta jest na elementach funkcjonalnych płaszczyzny sterowania ASON takich jak: sterownik połączeń CC (Connection Controller), sterownik rutingu RC (Routing Controller), zarządca zasobów LRM (Link Resorce Manager), sterownik protokołów PC (Protocol Controller). Sterownik połączeń CC przy współpracy ze sterownikiem rutingu RC, zarządcą zasobów LRM, sterownikiem protokołów PC pełni rolę serwera połączenia, a pozostając w relacjach z innymi sterownikami CC tworzy warstwę serwerów sterowania połączeń. Przykładową strukturę blokowo-funkcjonalną dla domeny ASON/GMPLS zaprezentowano na rys.1. Rys. 1. Przykładowa architektura domeny ASON/GMPLS (a); Struktura blokowo-funkcjonalna domeny ASON/GMPLS (b) W architekturze ASON/GMPLS ustawienie połączenia w płaszczyźnie transportowej poprzedzone jest realizacją funkcji rutingu. Na potrzeby warstwy serwerów sterowania połączeniami istnieje abstrakcyjny model zasobów, który umożliwia zasłonięcie przed serwerem połączeń konkretnych rozwiązań w płaszczyźnie transportowej. Natomiast sterownik protokołu wykorzystuje wiadomości RSVP-TE na potrzeby sygnalizacji oraz protokół OSPF-TE na potrzeby rutingu. W trakcie prac nad projektem zaproponowano scenariusze wymiany wiadomości konieczne dla zestawienia połączenia w warstwie zasobów (transportu) [13]. Przykładowe struktury informacji zaprezentowano w [15]. Weryfikację poprawności scenariuszy przeprowadzono realizując testbed, którego koncepcję przedstawiono w rozdziale 3, natomiast opis realizacji i testy odpowiednio w rozdziałach 4 i 5. 3. Koncepcja testbedu Koncepcja testbedu architektury warstwy serwerów sterowania połączeniami została stworzona na potrzeby zbadania nie tylko podstawowej funkcjonalności, ale również w celu zbadania komunikacji tej warstwy z otoczeniem, tzn. warstwą serwerów usług oraz warstwą zasobów dla realizacji transportu. Etap prac związany z realizacją podstawowej funkcjonalności warstwy serwerów połączeń określono jako wariant I, natomiast zwiększenie funkcjonalności warstwy serwerów połączeń na potrzeby komunikacji z otoczeniem określono jako wariant II. Koncepcja architektury testowej ASON/GMPLS wykorzystana w wariancie I bazuje na realizacji zarówno serwera jak i warstwy serwerów sterowania połączeniami. Komunikacja z warstwą serwerów sterowania połączeniami odbywa się poprzez aplikację kliencką API Client. Wywołanie aplikacji klienckiej umożliwia wyspecyfikowanie parametrów pojedynczego żądania, które przekazywane jest do serwera sterowania połączeń. Serwer 3

sterowania połączeniem odpowiedzialny jest za dynamiczne zarządzanie zasobami optycznymi poprzez obsługę żądań zestawienia oraz usunięcia ścieżek. Żądania rezerwacji zasobów przetworzone są w bloku RSVP Demon, który korzysta z baz RC, LMP i Resources Database (LRM). Do komunikacji w warstwie serwerów sterowania wykorzystany jest protokół RSVP, rozszerzony o elementy konieczne na potrzeby rezerwacji zasobów w warstwie optycznej. Podczas projektowania funkcjonalności serwera sterowania połączeniem przyjęto założenia, iż: odwzorowanie płaszczyzny sterowania na płaszczyznę transportową jest jeden do jednego, pojedyncza sesja rezerwacji wiąże się z rezerwacją zarówno pojedynczej jednostki transportowej jak i kilku jednostek transportowych w zależności od żądanego pasma, identyfikatory warstwy zasobów przekazywane są w ramach procedur protokołu LMP, stosowany jest styl rezerwacji Fixed Filter (FF). Zarówno w przypadku realizacji prac wariantu I jak i wariantu II warstwa zasobów optycznych opartych na przełącznicach OXC (Optical Cross Connect) jest emulowana. W przypadku wariantu I stan zajętości pojedynczej przełącznicy OXC na poziomie wejścia-wyjścia jest odwzorowany w bazie Resources Database. W rzeczywistym systemie w wyniku aktualizacji informacji o zasobach w płaszczyźnie sterowania, powinna zostać wywołana funkcja realizująca fizyczną rezerwację w płaszczyźnie transportowej. Architekturę testową wariantu I zaprezentowano na rys. 2. Rys. 2. Testowa architektura warstwy serwerów sterowania połączeniami ASON/GMPLS (wariant I) Docelowa architektura testbedu wariantu II warstwy serwerów sterowania połączeniami uwzględnia komunikację pomiędzy tą warstwą a warstwą usług, jak również między warstwą serwerów sterowania połączeniami oraz elementami emulującymi działanie warstwy zasobów mediów. Testowa architektura wariantu II zawiera serwer usług (SU), pięć serwerów połączeń (SP) oraz pięć terminali warstwy zasobów (TZ) odwzorowujących stan warstwy zasobów. W prezentowanym wariancie komunikacja na stykach I C oraz I R realizowana jest przy wykorzystaniu protokołów komunikacyjnych. Realizacja wariantu II wymaga uzupełnienia możliwości serwera sterowania połączeniami w związku ze zwiększeniem funkcjonalności otoczenia warstwy serwerów. W tym wariancie funkcjonalność aplikacji klienckiej zostaje przeniesiona do serwera usług. Serwer usług umożliwia wygenerowanie żądania połączenia, które zostanie przekazane poprzez styk I S do warstwy pięciu serwerów sterowania połączeniami. Przykładowa architektura testbedu dla realizacji wariantu II została zaprezentowana na rys. 3. W bazie danych SU znajdują się tabele: CTRL_TABLE, CALL_STATE oraz CALL_STAT. Tabela CTRL_TABLE to tabela odwzorowująca powiązania adresów warstwy zasobów dla transportu (mediów) z odpowiednim adresem serwera połączenia. 4

www SU Baza SU I C I C I C I C I C Is Is SP1 SP2 SP3 Is Is SP4 Is SP5 I R I R I R I R I R Baza OXC Baza OXC Baza OXC Baza OXC Baza OXC TZ1 TZ4 TZ2 TZ5 TZ3 OXC 1 OXC 4 OXC 2 OXC 5 OXC 3 www T Rys. 3. Testowa architektura warstwy serwerów sterowania połączeniami ASON/GMPLS (wariant II) SU-serwer usług, SP - serwer połączeń, TZ - terminal zasobów Tabela CALL_STATE to tabela odwzorowująca stan obsługiwanych żądań połączenia. Natomiast w tabeli CALL_STAT znajdują się statystki związane z wydajnością serwera sterowania połączeniami. W przypadku wariantu II uwzględnia się możliwość blokady zestawienia połączenia pomiędzy parą wejście-wyjście przełącznicy OXC. Rezerwacja zasobu warstwy optycznej dokonywana jest dopiero po uzyskaniu potwierdzenia możliwości zestawiania połączenia. Potwierdzenie uzyskania połączenia wysyłane jest z terminala TZ, po sprawdzeniu możliwości blokady przełącznicy w bazie OXC. Terminal T posłuży do konfiguracji i weryfikacji poprawności stanu zarezerwowanych połączeń w emulowanych przełącznicach OXC. Poprzez interfejs WWW istnieje między innymi możliwość konfiguracji, odczytu stanu baz terminali TZ w celu weryfikacji poprawności rezerwacji zasobów. W kolejnym rozdziale zaprezentowano sposób realizacji testbedu zarówno wariantu I jak i wariantu II. 5. Realizacja testbedu Funkcjonalność warstwy serwerów połączeń badano dla architektury trzech oraz pięciu serwerów. Schemat fizyczny topologii dla pięciu serwerów zaprezentowano na rys. 4. Architektura logiczna każdego z serwerów ma postać jak na rys. 2. Demon RSVP wyszególniony na rys.2 zrealizowano w oparciu o implementację KOM RSVP Engine [19]. Dla realizacji funkcjonalności warstwy sterowania połączeniami należało rozwinąć podstawową implementację o możliwość rezerwacji zasobów w warstwie optycznej. W tym celu wykorzystano mechanizm protokołu LMP i wprowadzono interfejs L, umożliwiający komunikację z zewnętrzną bazą LMP, wprowadzono interfejs Physical Resource Interfece umożliwiający komunikację z bazą Resources Database, rozszerzono zbiór informacji przechowywanej w blokach PSB i RSB, utworzono aplikacje klienta sender_application i receiver application na potrzeby generacji żądań połączenia. Aby możliwe było poprawne zarządzanie zasobami, konieczne było rozszerzenie istniejących bloków stanów protokołu RSVP o informacje identyfikujące fizyczne zasoby przypisane dla indywidualnych sesji RSVP. Do 5

informacji zawartych w blokach PSB oraz RSB, dodana została informacja o resourceid, jednoznacznie identyfikująca zasoby fizyczne warstwy transportowej. Rys. 4. Schemat fizycznej topologii testbedu (wariant I) Dodatkowo blok PHOP został uzupełniony o informację identyfikującą zasób fizyczny dla interfejsu wejściowego. W rozszerzonej implementacji przyjęto założenie, że informacja o resourceid jest lokalna dla każdego z węzłów wspierających protokół RSVP. Zaimplementowany rozszerzony model Demona RSVP został zaprezentowany na rys. 5. API Client Other System Services Network Service Traffic Control Routing Service Admission Control Rys.5. Zaimplementowany model Demona wykorzystany w testbedzie Dla realizacji sygnalizacji rezerwacji optycznych zasobów fizycznych warstwy transportowej, konieczne było również rozszerzenie obiektu RSVP_HOP definiowanego w zaleceniu RFC 3477 o identyfikator zasobu fizycznego. Informacje dotyczące stanów zasobów fizycznych przechowywane są w bazie danych Resources Database. Przykładowa baza danych dla serwera połączeń 5 (SP5) została zaprezentowana na rys. 6. W tabeli skonfigurowane zostały kolumny incoming_id, resource_id, psb_resource_state, rsb_resource_state, interface. Resource_id identyfikuje pojedynczą jednostkę zasobu dla interfejsu wyjściowego, która odpowiada rzeczywistym zasobom fizycznym takim jak: pojedyncza długość fali (LSC) lub pojedynczy światłowód (FSC). Zarówno kolumna psb_resource_state jak i rsb_resource_state są typu BOOLEAN, przyjmując odpowiednio wartość false ( f ), w przypadku gdy stan zasobu uważany jest jako wolny, oraz wartość true ( t ), w przypadku, gdy stan zasobu uważany jest za zajęty. Kolumna incoming_id identyfikuje zasób fizyczny dla interfejsu wejściowego. Para incoming_id / resource_id (interfejs wejściowy / interfejs wyjściowy) odzwierciedla konfigurację pola komutacyjnego. Komunikacja pomiędzy demonem protokołu RSVP, a bazą danych zasobów fizycznych została osiągnięta dzięki rozszerzeniu podstawowej implementacji o dwie nowe klasy: RSVP_PSB_Resources oraz RSVP_RSB_Resources, wykorzystujących niestandardową bibliotekę libpq, w których zdefiniowane zostały funkcje wykorzystywane w procesie zarządzania zasobami fizycznymi. Kolumna interface przechowuje informacje identyfikujące interfejs. 6

Rys.6. Baza danych Resources Database dla SP5 Dodatkowo w bazie danych LMP przechowywana jest tabela LMP przechowująca wynik procedury Link Property Correlation protokołu LMP. Na podstawie tabeli LMP dokonywane jest odzwierciedlenie lokalnego oraz zdalnego identyfikatora zasobu. Tabela składa się z trzech kolumn: lokalnego identyfikatora zasobu (local_id), zdalnego identyfikatora zasobu (remote_id) oraz interfejsu identyfikującego interfejs w płaszczyźnie sterowania architektury ASON/GMPLS. W zakresie prac nad wariantem II zrealizowano interfejs WWW umożliwiający zarządzanie serwerem usług oraz warstwą zasobów, a także moduł obliczania statystyk żądań w serwerze usług. Do realizacji powyższych elementów wykorzystano bazę danych Oracle Database 10g Express Edition, serwer WWW Apache HTTP Server 2.2.15 oraz interpreter języka oprogramowania PHP PHP 5.3.2. Powiązanie między oprogramowaniem wykorzystanym do stworzenia interfejsu graficznego dostępu do systemu i jego komunikację z serwerem połączeń przedstawiono na rys. 7. Przeglądarka internetowa HTTP PHP 5.3.2 (libphp5.so) Apache HTTP Server 2.2.15 SQL (OCI8) Serwer usług (SU) Oracle Database 10g Express Edition (OCI8) SQL Moduł oprogramowania do komunikacji SU_SP Protokół komunikacyjny Moduł oprogramowania do komunikacji SP_SU Serwer połączeń (SP) Rys. 7. Relacje między oprogramowaniem wykorzystanym do realizacji elementów otoczenia warstwy sterowania połączeniami i jego komunikacja z serwerem połączeń Serwer WWW Apache korzysta z interpretatora języka PHP skompilowanego do postaci biblioteki współdzielonej (ang. shared object) libphp5.so. Biblioteka ta ładowana jest wraz z innymi modułami w chwili uruchomienia serwera. Komunikacja pomiędzy bazą danych a serwerem WWW odbywa z użyciem standardowej składni SQL. Funkcje umożliwiające połączenie się z bazą w celu przesyłania zapytań SQL i odbierania odpowiedzi na nie zapewnia pakiet PHP OCI8. Zarządzanie serwerem usług oraz warstwą zasobów może być dokonane za pomocą dowolnej współczesnej przeglądarki WWW użytkownik musi jedynie znać adres IP danego urządzenia. Dodawanie wierszy do tabel bazy danych oraz ich edycja i usuwanie odbywa się za pomocą formularzy HTML z metodą przekazywania informacji HTTP POST. Wszystkie operacje na poszczególnych tabelach są wykonywane za pomocą jednego skryptu PHP, który sprawdza przy wywoływaniu podane parametry i odpowiednio uaktualnia bazę danych. 7

6. Testy W przypadku realizacji wariantu I przeprowadzono testy poprawności działania warstwy serwerów sterowania połączeniem oraz poprawności poleceń wydawanych do tej warstwy. Testy poprawności działania warstwy serwerów sterowania połączeniami wykonano dla architektury trzech oraz pięciu serwerów Wykonana została weryfikacja obsługi kilku jednoczesnych żądań połączenia wraz z rezerwacją zasobów fizycznych. Sesje obsługi pojedynczych żądań połączenia tworzone były w obu kierunkach. Dla każdej sesji wykonywana była próba rezerwacji zasobów fizycznych. W przypadku braku dostępności wolnych zasobów następowało odrzucenie żądania rezerwacji. Scenariusze testowe obejmowały weryfikację poprawności operacji: przetwarzania wiadomości PATH - wiadomości żądania zestawienia sesji, w tym poprawności konfiguracji obiektów wiadomości protokołu RSVP ze szczególnym uwzględnieniem obiektu RSVP_HOP przenoszącego identyfikator zasobu wprowadzony przez dodaną funkcjonalność, utworzenia bloku PSB, zawierającego identyfikator zasobu wyjściowego, utworzenie bloku PHopSB, zawierającego identyfikator zasobu wejściowego (utworzenie klucza PHopSB- Key), przetwarzanie wiadomości RESV - wiadomości potwierdzenia utworzenia wiadomości, utworzenie bloku RSB, uaktualnienie bazy danych informacji o zasobach sygnalizacja rezerwacji oraz zwalniania zasobów fizycznych płaszczyzny transportowej, przetwarzanie wiadomości PTEAR, RTEAR, PERR, RERR. Wyniki testów zostały zaprezentowane w pracach [9,16,17]. Testy obejmowały różne scenariusze zestawienia i rozłączenia połączeń. Jednocześnie dla testbedu wariantu I zostały wykonane pomiary czasu reakcji rozumiane jako czasy odpowiedzi warstwy serwerów sterowania połączeniami na ręcznie generowane żądania przy pomocy sender_application oraz receiver_application. Pomiary wykonano zarówno dla architektury trzech jak i pięciu serwerów połączeń. W przypadku architektury trzech serwerów pomiary wykonano w warunkach laboratoryjnych jak i nielaboratoryjnych. W przypadku warunków laboratoryjnych wykorzystano komputery z procesorami Intel Pentium III 1 GHz, pamięć RAM-384 MB. W warunkach nielaboratoryjnych wykorzystano komputery o parametrach: SP1 - procesor AMD Phenom 9550 Quad Core, pamięć RAM 4GB, SP2 - procesor Intel Core 2 Duo T7700, pamięć RAM 4GB, SP3 - procesor Intel Core 2 Duo E7200, pamięć RAM 2GB. W warunkach nielaboratoryjnych w zależności od miejsca przeprowadzenia rezerwacji (zdalnie, lokalnie) uzyskano wyniki zaprezentowane w tabeli 1. Tabl.1. Porównanie czasów przeprowadzenia rezerwacji lokalnej i zdalnej w warunkach nielaboratoryjnych Rezerwacja Rezerwacja lokalna [ms] Rezerwacja zdalna [ms] SP1-SP3 625 926 SP1-SP2 przy trwającej rezerwacji SP1-SP3 351 338 SP2-SP3 przy trwającej rezerwacji SP1-SP2 orazsp1-sp3 330 330 SP3-SP1 przy trwającej rezerwacji SP1-SP2,SP1-SP3.SP2-SP3 575 606 Czasy rezerwacji nieznacznie się różnią, co uzasadnia skuteczność aplikacji klienckiej. Porównanie czasów przeprowadzenia rezerwacji lokalnej w warunkach nielaboratoryjnych z czasami uzyskanymi dla warunków laboratoryjnych przedstawiono w tabeli 2. Prezentowane wyniki potwierdzają, iż im większe możliwości wydajnościowe serwerów, tym krótszy czas zestawiania połączenia. Tabl.2. Porównanie czasów przeprowadzenia rezerwacji lokalnej Rezerwacja Konfiguracja laboratoryjna [ms] Konfiguracja nielaboratoryjna [ms] SP1-SP3 2330 926 SP1-SP2 przy trwającej rezerwacji SP1-SP3 852,1 338 SP2-SP3 przy trwającej rezerwacji SP1-SP2 orazsp1-sp3 813,0 330 SP3-SP1 przy trwającej rezerwacji SP1-SP2,SP1-SP3.SP2-SP3 -------- 606 W przypadku testbedu opartego na architekturze pięciu serwerów połączeń w warunkach laboratoryjnych uzyskano wyniki zaprezentowane w tabeli 3. 8

Tabl.3. Porównanie czasów przeprowadzenia rezerwacji w warunkach laboratoryjnych Rezerwacja Rezerwacja lokalna [ms] SP1-SP5 2690 SP1-SP4 2550 SP1-SP3 2330 SP1-SP2 przy trwającej rezerwacji SP1-SP3 852 SP2-SP3 przy trwającej rezerwacji SP1-SP2 oraz SP1-SP3 813 SP3_SP1 przy trwającej rezerwacji SP1-SP2,SP1-SP3,SP2-SP3 789 Przeprowadzone pomiary czasów rezerwacji są dość duże. Szczegółowa analiza składników tego czasu wskazuje, iż największy wpływ na sumaryczny czas zestawienia połączenia mają zapytania do bazy danych. Dlatego w końcowym etapie prac podjęto prace w celu ich zmniejszenia. W zakresie prac związanych z realizacją testbedu wariantu II przeprowadzono testy wykorzystania proponowanych istniejących i zalecanych protokołów komunikacyjnych oraz ich implementacji w testbedzie wariantu II na stykach I C oraz I R zaprezentowanych na rys. 3. Testom poddano następujące protokoły: Diameter, Netconf. Analiza protokołów obejmowała zarówno dogłębne zapoznanie się z kodem źródłowym, próby jego kompilacji i uruchomienia działających wersji, a także sprawdzenie zgodności ze standardami dotyczącymi protokołów. Spośród dostępnych implementacji protokołu Diameter szczegółowym testom poddano implementację CDiameterPeer, natomiast w przypadku protokołu Netconf testom poddano implementację Netopeer. Obie implementacje spełniają podstawowe kryterium jakim jest język programowania C/C++. CDiameterPeer (cdp) jest implementacją wykorzystywaną w projekcie Open IMS Core. Konfiguracja pojedynczego peera cdp przechowywana jest w pliku w formacie XML. Przykładowe pliki konfiguracyjne ukierunkowane na wykorzystanie w projekcie Open IMS Core zostały dołączone do kodu źródłowego implementacji cdp. Plik konfiguracyjny umożliwia między innymi skonfigurowanie globalnych parametrów danego peera (element DiameterPeer): prawidłowa nazwa domenowa (atrybut FQDN), nazwę domeny, identyfikator dostawcy, liczba procesów Worker, długość kolejek wiadomości reguły określające zasady akceptacji nieznanych peerów. Plik konfiguracyjny umożliwia określenie portu TCP na którym nasłuchuje dany peer (atrybut port elementu Acceptor) oraz ewentualne określenie adresu IP interfejsu sieciowego na którym peer nasłuchuje (atrybut bind elementu Acceptor). Na podstawie analizy dokumentacji i kodu źródłowego implementacji Netopeer można wywnioskować, że w przypadku zastosowania w dalszych pracach implementacji Netopeer konieczna będzie zmiana sposobu obsługi managera poprzez rezygnację z linii komend i wywoływanie odpowiednich funkcji realizujących komunikację protokołu Netconf z poziomu własnej aplikacji C/C++. Ponadto, na podstawie przeglądu dokumentacji implementacji Netopeer oraz dokumentu RFC standaryzującego protokół Netconf, można wysnuć wniosek, że ograniczona liczba bardzo prostych poleceń protokołu i statyczna struktura plików XML przechowujących dane konfiguracyjne może okazać się niewystarczająca dla potrzeb dynamicznego sterowania zasobami sieciowymi. W takim przypadku, wykorzystanie protokołu Netconf w implementacji Netopeer, może wymagać zastosowania mechanizmów rozszerzeń protokołu (capabilities) oraz zastąpienie struktury pliku XML np. relacyjną bazą danych. Rys. 8. Strona WWW (show_stats.php) ze skryptem PHP W zakresie prac związanych z emulacją serwera usług oraz warstwy zasobów transportowych przetestowano poprawność operacji na bazie danych. Przetestowano funkcjonalność modułu pomiarowego zaimplementowanego w serwerze usług. Na rys. 8 zaprezentowano stronę WWW serwera usług ze skryptem PHP dokonującym obliczeń i prezentującym statystyki dla przykładowych danych. Dla przejrzystości rysunku zaprezentowano tylko wybrane kolumny tabeli CALL_STAT. 9

Ostateczne testy i badania proponowanych rozwiązań warstwy serwerów połączeń, komunikacji pomiędzy tą warstwą a otoczeniem zostaną przeprowadzone na zakupionym w tym celu, pod koniec V etapu, sprzęcie i są realizowane w VI końcowym etapie realizacji tego zadania. 7. Podsumowanie Wyniki prac badawczych wykonanych w ramach projektu PBZ w podprojekcie Architektury i protokoły sieciowe wskazują, iż na chwilę obecną jesteśmy w stanie wskazać i zaimplementować architekturę, która ma szansę spełnić wymagania społeczeństwa informacyjnego. Zaimplementowany testbed wariantu I umożliwił zbadanie podstawową funkcjonalności warstwy serwerów sterowania połączeniami. Ten etap prac pozwolił na przejście do realizacji wariantu II, wskazał konieczność optymalizacji liczby zapytań do bazy danych. Ostateczne wyniki prac nad realizacją wariantu II zaprezentowane zostaną w raporcie końcowym projektu badawczego PBZ. Bibliografia [1] Czarkowski M., Kaczmarek S., Simulation model for evaluation of packet sequence changed order of stream in diffserv network, PWT 2008, Poznań 11.12.2008 [2] Czarkowski M., Kaczmarek S., Simulation model for evaluation of QoS dynamic routing. W: Information Systems Architecture and Technology, Library of Informatics of University Level Schools, Part 3, Chapter 22, Wrocław, 2009, s.255-264 [3] Czarkowski M., Kaczmarek S., Młynarczuk M., Narloch M., Nowak K.: Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej. Etap 3. PBZ-MNiSW-02- II/2007/GUT/2.3, Gdańsk, czerwiec 2009 [4] Czarkowski M., Kaczmarek S., Stępnicki S.: Simulation model for evaluation of QoS routing algorithm in large packet networks, W: Information Technologies, GUT FETI Annales, Vol. 18, 2010, s. 167-172 [5] http://www.eti.pg.gda.pl/katedry/kst/badania/msim/index.html [6] ITU-T G.8080/Y.1304: Architecture for the Automatically Switched Optical Network (ASON). June 2006 [7] Kaczmarek S., Nowak K., Performance of LSP preemption methods in different MPLS networks, PGTS 2008, Berlin 6-7.10.2008 [8] Kaczmarek S., Kostecki P., Młynarczuk M., Narloch M., Nowak K., Smoleński L.: Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej. Etap 1. PBZ-MNiSW-02- II/2007/GUT/2.1, Gdańsk, czerwiec 2008 [9] Kaczmarek S., Kostecki P., Młynarczuk M., Narloch M., Nowak K.: Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej. Etap 2. PBZ-MNiSW-02- II/2007/GUT/2.2, Gdańsk, grudzień 2008 [10] Kaczmarek S., Nowak K.: A Simulation Tool for Traffic Engineering Methods and QoS Evaluation of MPLS Networks. Międzynarodowa Konferencja SIMUTools 09, Rome, Italy, March 2-6 2009 [11] Kaczmarek S., Kostecki P.: Burst loss probability for the combination of extended offset time based service differentiation scheme and PPS in optical burst switching network. W: 16 th Polish Teletraffic Symposium, Łódź, 2009, s.71-74 [12] Kaczmarek S., Młynarczuk M., Nowak K.: Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej. Etap 4. PBZ-MNiSW-02-II/2007/GUT/2.4, Gdańsk, grudzień 2009 [13] Kaczmarek S., Młynarczuk M., Narloch M., Nowak K.,: Warstwa serwerów sterowania połączeniami w NGN. Przegląd Telekomunikacyjny + Wiadomości Telekomunikacyjne, 2009, s. 1061-1070 [14] Kaczmarek S., Młynarczuk M., Narloch M., Sac M.: Warstwa sterowania usługami i połączeniami w sieciach dla globalnej infrastruktury informacyjnej. Etap 5. PBZ-MNiSW-02-II/2007/GUT/2.5, Gdańsk, czerwiec 2010 [15] Kaczmarek S., Młynarczuk M.: Model of Control Plane of ASON/GMPLS NETWORK. W: Information Technologies, GUT FETI Annales, Vol. 18, 2010, s. 319-324 [16] Kaczmarek S., Młynarczuk M., Waldman M.: The realization of ASON/GMPLS Control Plane. W: Information Systems Architecture and Technology, System Analysis Approach to the Design, Control and Decision Support, Wrocław, Oficyna Wydawnicza Politechniki Wrocławskiej, 2010, s.313-324 [17] Kaczmarek S., Młynarczuk M., Waldman M.: RSVP-TE as a reservation protocol for optical networks, referat zgłoszony na Poznańskie Warsztaty Telekomunikacyjne 2010 [18] Mannie E., Ed.: Generalized Multi-Protocol Label Switching (GMPLS) Architecture. RFC 3945, October 2004 [19] Multimedia Communications Lab: KOM RSVP Engine, www.kom.e-technik.tu-darmstadt.de/rsvp 10