Michał Czarkowski, Sylwester Kaczmarek, Magdalena Młynarczuk, Marcin Narloch, Krzysztof Nowak

Transkrypt

1 Numer Projektu Badawczego Zamawianego: PBZ-MNiSW-02-II/2007 Tytuł projektu: Numer dokumentu: Tytuł podprojektu: Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe PBZ-MNiSW-02-II/2007/GUT/2.3 Architektury i protokoły sieciowe Raport z realizacji zadania badawczego: 2.3 Tytuł zadania badawczego: Opracowanie struktury funkcjonalnej dla warstwy serwerów sterowania połączeniem. Określenie protokołów komunikacji pomiędzy serwerami warstwy sterowania połączeniem oraz między tą warstwą a warstwami przyległymi. Przewidywany termin dostarczenia raportu: 30/06/09 Rzeczywisty termin dostarczenia raportu: Kierownik zadania: Wykonawcy: dd/mm/yy Sylwester Kaczmarek Michał Czarkowski, Sylwester Kaczmarek, Magdalena Młynarczuk, Marcin Narloch, Krzysztof Nowak Abstrakt: Dokument ten jest raportem z realizacji zadania badawczego 2.3 w ramach podprojektu badawczego Architektury i protokoły sieciowe. Można w nim wyróżnić dwa obszary badań, jeden dotyczy szczegółowego opisu koncepcji realizacji serwerów sterowania połączeniami dla technologii MPLS i ASON/GMPLS, drugi narzędzi i wyników badań symulacyjnych algorytmów sterowania. W przypadku realizacji serwerów sterowania połączeniami szczególny nacisk położono na funkcjonalność i na zasady komunikacji prowadzące do wyspecyfikowania styków (interfejsów) i koniecznych wiadomości na tych stykach. Umożliwiło to zaproponowanie i wybór protokołów komunikacji. Niezależnie od tego opisano podstawowe scenariusze i procedury obsługi wiadomości oraz scenariusze pracy serwera. Także sprecyzowano wymagania co do baz danych serwerów. Ostatecznie zaproponowano koncepcję współpracy obu technologii z punktu widzenia serwerów sterowania połączeniami. W wyniku tych prac dokonano specyfikacji wymagań dla docelowo realizowanego testbedu, będącej podstawą zakupu sprzętu i oprogramowania. Druga część pracy dotyczy badań algorytmów sterowania połączeniami dla których wytworzono odpowiednie narzędzia symulacyjne. Obejmują one model symulacyjny dla architektur MPLS z wywłaszczaniem ścieżek o niższych priorytetach oraz model symulacyjny rutingu dynamicznego w domenie, który to model umożliwia badanie także problemu zmiany kolejności pakietów na skutek przełączania dróg połączeniowych. Słowa kluczowe: model warstwowy sieci telekomunikacyjnej, serwery sterowania połączeniem, sieci szkieletowe, GII, NGN, IP QoS, MPLS, ASON, GMPLS

2 Spis treści 1. WPROWADZENIE STRUKTURA FUNKCJONALNA WARSTWY SERWERÓW STEROWANIA POŁĄCZENIEM W TECHNOLOGII MPLS Interfejsy serwera sterowania połączeniem Odniesienie do prac ITU-T Zasada komunikacji Współpraca z technologią ASON/GMPLS Wiadomości komunikacyjne na styku I C IC_CREATE_REQ IC_DELETE_REQ IC_MODIFY_REQ IC_RESPONSE IC_ACKNOWLEDGE Wiadomości komunikacyjne na styku I S IS_CREATE_REQ IS_DELETE_REQ IS_MODIFY_REQ IS_RESPONSE IS_ACKNOWLEDGE Wiadomości komunikacyjne na styku I R IR_CREATE_REQ IR_DELETE_REQ IR_MODIFY_REQ IR_RESPONSE Scenariusz obsługi wiadomości Procedury obsługi wiadomości IC_CREATE_REQ i IS_CREATE_REQ IC_DELETE_REQ i IS_DELETE_REQ IC_MODIFY_REQ i IS_MODIFY_REQ Struktury danych serwera sterowania połączeniem Struktura tablic Fazy działania serwera sterowania połączeniem Podsumowanie STRUKTURA FUNKCJONALNA WARSTWY SERWERÓW STEROWANIA POŁĄCZENIEM W TECHNOLOGII ASON/GMPLS Wprowadzenie Struktura funkcjonalna serwera sterowania połączeniem (opis bloków funkcjonalnych) Struktura warstwy sterowania połączeniem i zasady komunikacji Typy wiadomości Scenariusze pracy serwera i warstwy Scenariusz pracy serwera dla pojedynczej domeny ASON/GMPLS Scenariusz pracy serwera dla dwóch domen ASON/GMPLS Struktura danych Protokoły dla komunikacji z otoczeniem Protokół na styku Ic Protokół na styku I NMI Protokół na styku I S Protokół na styku I R /104

3 Interfejs I RC Interfejs I SIG Koncepcja współpracy warstwy sterowania połączeniem dla technologii ASON/GMPLS oraz MPLS Podsumowanie SPECYFIKACJA WYMAGAŃ NA LABORATORIUM TESTBEDU Wprowadzenie Specyfikacja dla MPLS Ogólna koncepcja Podział funkcjonalności Model warstwowy System uruchomieniowy Wymagania sprzętowe Protokoły Badania Specyfikacja dla ASON/GMPLS Propozycja testbedu Badania i pomiary NARZĘDZIA I ŚRODOWISKO BADAWCZE Wprowadzenie Model symulacyjny dla MPLS Wstęp Model sieci Symulacja Węzeł Źródła ruchu Ścieżki Aplikacja symulatora Informacje ogólne Struktura programu Główne cechy programu Symulacja zdarzeń dyskretnych Sieć opisana w pliku konfiguracyjnym Automatyczne generowanie raportów Powtórzenia Główne obiekty programu Menedżer symulacji Menedżer kolejki zdarzeń Menedżer konfiguracji Menedżer połączeń Menedżer raportów Menedżer topologii Generowanie raportów Przykłady zastosowań Ruting dynamiczny Algorytmy wywłaszczania Aplikacja Vims: graficzne rozszerzenie programu msim Podsumowanie Przeprowadzenie badań wpływu przełączania dróg połączeniowych na zmianę kolejności pakietów w strumieniu /104

4 Wprowadzenie Definicja problemu Przegląd literatury i dostępnych metod analizy zmiany kolejności pakietów w ramach pojedynczego strumienia Model analityczny Model symulacyjny Założenia do modelu Opis środowiska symulacyjnego Dekompozycja i opis modelu Weryfikacja poprawności modelu Przeprowadzenie badań Opis badanych scenariuszy Konfiguracja środowiska symulacyjnego Wyniki badań dla serii pomiarowych Analiza wyników Podsumowanie PODSUMOWANIE I WNIOSKI BIBLIOGRAFIA /104

5 1. WPROWADZENIE W ramach trzeciego etapu zadania 2 przeprowadzono prace badawcze będące kontynuacją prac, wyników i wniosków z poprzednich etapów tego zadania. Zostały one skupione na dwóch obszarach rozważań i działań badawczych. Pierwszy z nich dotyczył badań prowadzących do szczegółowej specyfikacji wymagań na serwer sterowania połączeniami. Zgodnie z tym co zostało wykonane w drugim etapie tego zadania rozważania obejmowały dwie technologie przewidziane do stosowania w rdzeniu sieci. Są to technologie MPLS i ASON/GMPLS. Dla osiągnięcia postawionego celu szczególny nacisk położono na szczegółowy opis i specyfikację funkcjonalności serwera z punktu widzenia samego serwera jak i współpracy z otoczeniem. W konsekwencji doprowadziło to do zdefiniowania styków i wymaganych zbiorów wiadomości na tych stykach wraz z ich zawartością informacyjną. Zapewnienie prawidłowej pracy serwerów wymagało określenia procedur i scenariuszy wymiany wiadomości dla typowych sytuacji wynikających z przyjętej funkcjonalności. Dla kompletności opisu działania i specyfikacji konieczne było także zaproponowanie niezbędnej minimalnej struktury danych w oparciu o którą możliwa jest realizacja podstawowej funkcjonalności serwera. W przypadku technologii MPLS w oparciu o ogólną koncepcję warstwy serwerów sterowania połączeniami wyspecyfikowano konieczne styki, którymi są: styk I C do klienta (użytkownika), styk I S do innego serwera, styk I R do warstwy zasobów w której realizowane są połączenia, styk I OS do systemu zarządzania, styk I Op do komunikacji z operatorem. W oparciu o cechy tych styków zaproponowano możliwe do wykorzystania istniejące lub opracowywane protokoły komunikacyjne. Tymi protokołami są: Diameter, COPS, SSH, Telnet, SNMP, FTP. Należy tu podkreślić, że dla styku I S nie znaleziono odpowiednika w istniejących protokołach. Ponieważ prowadzone są prace nad stykami dla sieci NGN to dokonano także porównania w odniesieniu do prac ITU-T. Można wskazać dużą aczkolwiek nie pełną zbieżność w uzyskanych, przynajmniej na tym poziomie rozważań, wynikach. Przyjęta w opracowaniu koncepcja zakłada zasadę komunikacji typu klient-serwer. Dla każdego ze styków określono typy wiadomości. I tak przykładowo dla styku I C jest ich pięć i są to: IC_CREATE_REQ, IC_DELETE_REQ, IC_MODIFY_REQ, IC_RESPONSE, IC_ACKNOWLEDGE. Dla każdego typu podano strukturę wiadomości, przeznaczenie i sposób wykorzystania poszczególnych pól. Po omówieniu wszystkich styków przedstawiono scenariusz obsługi wiadomości na przykładzie konkretnego scenariusza realizacji połączenia wielodomenowego (zestawienia ścieżki). Dla rozważanego scenariusza diagramy obsługi wiadomości przedstawiono wariantowo. Bazując na schemacie blokowo-funkcjonalnym serwera zaproponowano procedury obsługi wiadomości. Obejmują one sytuację żądania utworzenia, skasowania lub modyfikacji ścieżki. Dla każdej wiadomości opisany jest ciąg etapów z których każdy zawiera następujące informacje: Etap, Opis, Odpowiedzialny blok, Źródło informacji, Warunek sukcesu, Efekt sukcesu, Efekt niepowodzenia. Następnie przystąpiono do opracowania struktury danych serwera i w wyniku prac zaproponowano podstawowy zbiór tablic, ich strukturę i zawartość informacyjną. Są to tablice: CONFIG, ALLOWED_HOSTS, LINKS, NODES, CONN_PROFILE, OSS, CC_SERVERS, PATHS, PATH_ROUTES, LINK_STATES, NODE_STATES, ACT_TRANS, ALARMS. Mając przedstawione tu elementy przystąpiono do zaproponowania faz pracy serwera sterowania połączeniami. Zakłada się, że serwer może pracować w jednej z trzech faz: inicjalizacji, praca, zakończenie pracy. Dla każdej z faz zaproponowano zbiór zadań realizowanych przez serwer w kontekście i powiązaniu z wcześniej przedstawionymi propozycjami rozwiązań oraz przetwarzanymi informacjami. Z kolei w przypadku technologii ASON/GMPLS, bazując na koncepcjach przedstawionych w poprzednich etapach realizacji tego zadania, i mając określoną ogólną strukturę ser- 5/104

6 wera sterowania połączeniami zaproponowano styki (interfejsy) oraz zasady komunikacji w warstwie sterowania połączeniami. Podejście jest podobne do omówionego dla technologii MPLS. Wyróżniono siedem interfejsów i są nimi: interfejs I C od/do serwera usług, interfejs I NMI do systemu zarządzania, interfejs I S do innych serwerów sterowania połączeniami, interfejs I R do warstwy zasobów w którym zestawiane są połączenia, interfejs I RC do sterownika rutingu, interfejs I LRM do/od serwera sterownika zarządcy zasobów, interfejs I SIG do wymiany wiadomości sygnalizacyjnych. Następnie określono typy wiadomości dla poszczególnych interfejsów. I tak przykładowo dla interfejsu I C są to: IC_CALL_REQ, IC_CALL_COORDINATION, IC_CALL_INDICATION, IC_CALL_CONFIRMED, IC_CONNECTION_REQ, IC_CONNECTION_CONFIRMED, IC_CALL_CONFIRMED, IC_CALL_Delete, IC_CONNECTION_Delete, IC_CONNECTION_Delete_Response. Każda z wiadomości została opisana z punktu widzenia przeznaczenia i zawartości informacyjnej. Bazując na tych danych zaproponowano scenariusze pracy serwera i samej warstwy. Zrealizowano to dla pojedynczej domeny ASON/GMPLS, przy czym ograniczono się do przypadku struktury jaka ma być wykonana w ramach testbedu. Rozważano tu także wariantowość scenariuszy. Identyczne rozważania przeprowadzono dla scenariusza obejmującego dwie domeny ASON/GMPLS, przy czym podobnie jak poprzednio omówiono to dla struktury, która ma być zrealizowana w testbedzie. Tu także rozważano sytuacje wariantowo. Kolejnym krokiem było zaproponowanie struktury danych koniecznych do właściwej pracy serwera sterowania połączeniem. Wyróżniono tu struktury: LR, LRM oraz rekordy opisu połączenia. Ostatecznie mając te informacje dokonano analizy przydatności i wykorzystania istniejących lub opracowywanych protokołów. W jej wyniku stwierdzono, że do potencjalnych kandydatów należą protokoły: COPS, RSVP-TE, SNMP, OSPF-TE. Przy czym przydatność określonego protokołu jest uzależniona od rodzaju styku (interfejsu). Ponieważ w laboratorium mają być przeprowadzone badania współpracy obu tu rozważanych technologii w warstwie serwerów sterowania połączeniami to przedstawiono także koncepcję rozwiązania tej współpracy. Omówiono scenariusze wymiany wiadomości dla struktury proponowanej do zrealizowania w testbedzie. Struktura obejmuje sobą na brzegach domeny MPLS połączone domeną ASON/GMPLS. W oparciu o scharakteryzowane tu koncepcje realizacji projektu opracowano szczegółową specyfikację dla technologii MPLS i ASON/GMPLS, która jest podstawą do zamówienia określonego sprzętu i oprogramowania. Specyfikacja ta, zarówno dla MPLS jak i ASON/GMPLS, określa jaki i ile sprzętu zostanie wykorzystane w laboratorium oraz jaka funkcjonalność zostanie zainstalowana na tym sprzęcie aby można było osiągnąć cele postawione w projekcie. Wymagało to także określenia środowiska w którym będzie uruchamiane i instalowane oprogramowanie oraz protokoły komunikacyjne dla realizowania wybranej funkcjonalności serwerów sterowania połączeniami. Także krótko sformułowano jakie podstawowe badania ilościowe zostaną wykonane na tym sprzęcie, niezależnie od badań funkcjonalnych. Drugi obszar działań badawczych obejmował narzędzia i środowisko badawcze, które wykorzystywane jest do badań wymienionych technologii poza rzeczywistym sprzętem. Są to metody symulacji komputerowej przy pomocy których można określać właściwości czy też cechy a stąd wynikającą przydatność algorytmów sterowania. W ramach tego etapu zostały opisane zrealizowane dwa modele symulacyjne oraz częściowe wyniki uzyskane przy pomocy tych modeli. Pierwszy z modeli symulacyjnych dotyczy domeny z technologią MPLS. Umożliwia on badanie właściwości sterowania połączeniami (tworzeniem ścieżek LSP) z uwzględnieniem klas usług oraz wywłaszczania ścieżek o niższych priorytetach przez ścieżki o wyższym priorytecie. W raporcie opisano dość dokładnie strukturę blokowo-funkcjonalną, sposób realizacji poszczególnych bloków, pomiary wielkości podczas symulacji, analizę statystyczną wyników 6/104

7 i ich graficzną prezentację. Opisano wszystkie cechy zrealizowanego modelu symulacyjnego oraz jego możliwości, a także wskazano na cechę otwartości modelu czyli możliwości rozbudowy. Na podkreślenie zasługuje fakt iż model ten posiada interfejs poprzez który można wczytywać dane co do badanych sieci, które są przechowywane w plikach XML. Pliki te są ogólnie dostępne na stronie WWW utworzonej przez środowisko badaczy międzynarodowych zajmujących się analizą i syntezą sieci telekomunikacyjnych. Znajdują się tam struktury zarówno rzeczywistych jak i teoretycznych sieci. Badania symulacyjne przeprowadzono dla struktur z tej strony WWW. Niezależnie od tego w modelu istniej możliwości samodzielnej i niezależnej generacji struktur sieci bazującej na metodzie Waxmana. Dla uproszczenia współpracy użytkownik-model symulacyjny została zrealizowana specjalna aplikacja, która dodaje do modelu symulacyjnego graficzny interfejs ułatwiający korzystanie z modelu symulacyjnego. Wersja wykonywalna tego modelu symulacyjnego wraz z tym interfejsem została udostępniona na stronie Katedry Sieci Teleinformacyjne Wydziału ETI PG. Sam model symulacyjny wraz z częściowymi wynikami był prezentowany w 2009 roku na konferencji SIMUTools 09, która odbyła się w Rzymie, a poświęcona była zagadnieniom metodologicznym w symulacji. Drugi z modeli symulacyjnych dotyczy realizacji oraz badań rutingu dynamicznego wspierającego klasy o zróżnicowanych wymaganiach jakościowych. W ramach tego raportu skupiono się na jednym z problemów jaki jest konsekwencją wprowadzenia rutingu dynamicznego, a mianowicie problemu i konsekwencji wynikających z przełączania dróg połączeniowych. To przełączanie ma miejsce, gdy nastąpi zmiana stanu sieci. Jeżeli dynamika ruchu jest duża to mamy dość często do czynienia z takim przełączaniem. W konsekwencji prowadzi to do zmiany kolejności pakietów w przełączanych strumieniach. Rodzi się pytanie, jakie muszą być spełnione warunki aby przełączanie nie pogarszało parametrów jakościowych, a konkretnie prawdopodobieństwa straty pakietów. Jest to istotne w przypadku strumieni czasu rzeczywistego. Przy pomocy modelu symulacyjnego zrealizowanego w środowisku omnet++, który umożliwia badanie dużych, rzeczywistych struktur sieci, zostało przebadane opisane wcześniej zjawisko. Uzyskano wyniki wskazujące na to, że zjawisko to może być pominięte, gdy dynamika zmian nie będzie większa od pewnej granicznej wartości. Miarą tej dynamiki w modelu symulacyjnym był czas między przełączeniami dróg połączeniowych. Dla badanych struktur (Polska i Atlanta) i charakterystyk oraz udziału poszczególnych klas generowanego ruchu ta graniczna wartość wynosiła 40 sekund. Jednocześnie zaproponowano prosty model analityczny, który umożliwia ilościowe oszacowanie od góry udziału pakietów dla których nastąpiła zmiana kolejności w strumieniu. W wyniku prac przedstawionych w tym raporcie zostały opublikowane lub przygotowane do publikacji (zgłoszone) następujące materiały: 1. Kaczmarek S., Nowak K., A Simulation Tool for Traffic Engineering Methods and QoS Evaluation of MPLS Networks, Międzynarodowa Konferencja SIMUTools 09, March , Rome, Italy. 2. 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, referat przyjęty na PTS 2009, wrzesień Kaczmarek S., Młynarczuk M., Narloch M., Nowak K., Warstwa serwerów sterowania połączeniami w NGN, zgłoszonie na KSTiT 2009 w ramach sesji zamawianej przez projekt PBZ finansowany przez MNiSW-02-II/2007, wrzesień /104

8 4. Czarkowski M., Kaczmarek S., Simulation model for evaluation of QoS dynamic routing, referat wstępnie przyjęty na konferencję ISAT /104

9 2. STRUKTURA FUNKCJONALNA WARSTWY SERWERÓW STEROWANIA PO- ŁĄCZENIEM W TECHNOLOGII MPLS 2.1. Interfejsy serwera sterowania połączeniem 1 Aby umożliwić bardziej precyzyjny opis funkcjonalny serwera sterownia połączeniem zidentyfikowano logiczne styki używane we współpracy z urządzeniami zewnętrznymi. W ramach technologii MPLS przewidziano dla serwera pięć styków przedstawionych na rysunku 2.1. Ich funkcje są następujące. 1. Styk I C do klienta służy do komunikacji z urządzeniami, które generują żądania utworzenia, modyfikacji lub skasowania ścieżek, a które nie są serwerami połączeń. Styk I C jest udostępniony jako otwarty port TCP lub UDP, zależnie od wybranego do komunikacji protokołu. Na tym etapie badań nie przewiduje się na tym styku tworzenia połączeń stałych. 2. Styk I S do innego serwera połączeń, który może kontrolować inną domenę w ramach tej samej lub innej technologii, np. urządzenia optyczne DWDM. Przewiduje się, iż w praktyce informacje przesyłane stykami I C i I S będą podobne. Zdecydowano się jednak wyróżnić oba styki ze względu na ewentualną możliwość zastosowania innych protokołów oraz mechanizmów autentykacji i autoryzacji. W przeciwieństwie do styku I C, na styku I S żądania kierowane mogą być w dwie strony a zbiór urządzeń, z którymi serwer się komunikuje, jest ściśle określony. Przewiduje się możliwość zestawiania stałego połączenia na styku I S. 3. Styk I R do urządzeń w warstwie zasobów, służący do przesyłania komend związanych z tworzeniem ścieżek LSP do ruterów IP/MPLS. I OS System zarządzania I Op Operator Klient I C I S I R Serwer sterowania połączeniami Serwer sterowania połączeniami Serwer usług Ruter w warstwie zasobów Rys Interfejsy serwera sterowania połączeniem. 1 W dalszej części używa się zamiennie pojęć serwer sterowania połączeniem i serwer połączeń. 9/104

10 4. Styk I OS do systemu zarządzania, przeznaczony do przesyłania informacji związanych z funkcjami fault management (obsługą alarmów generowanych przez serwer), performance management (przesyłaniem pomiarów) i accounting management (przesyłaniem danych do systemu bilingowego). 5. Styk I Op do komunikacji z operatorem, służący do konfiguracji serwera w czasie rzeczywistym przez operatora lub system zarządzania w funkcji configuration management. W tabeli 2.1. zawarto porównanie podstawowych cech styków serwera sterowania połączeniami. Dla części styków zaproponowano również protokoły komunikacyjne. W przypadku styków I C i I S nie sprecyzowano jeszcze jaki protokół będzie używany. Na styku I R przewiduje się użycie protokołu Common Object Policy Sernice (COPS) [RFC2748] lub, w przypadku jego niedostępności na ruterze, wykorzystanie sesji ssh lub telnet do rutera. Komunikacja z operatorem na styku I Op powinna odbywać się w oparciu o sesję terminalową. W odniesieniu do styku I OS do systemu zarządzania, rodzaj komunikacji zależy od typu danych. Alarmy powinny być przesyłane za pomocą protokołu SNMP, natomiast dane pomiarowe i rekordy bilingowe udostępnione dla transferu FTP. Tab Cechy styków serwera połączeń. Styk Połączenia stałe Styk symetryczny Zbiór urządzeń zdefiniowany Proponowany protokół I C Diameter I S (nie zdefiniowany) I R COPS/SSH/Telnet I OS SNMP/FTP I Op SSH/Telnet Odniesienie do prac ITU-T Organizacja ITU-T pracuje nad zaleceniami dotyczącymi architektury i protokołów sterowania zasobami [Q.3300]. W ramach tych prac wyodrębniono szereg styków i określono protokoły, jakie mogą być zastosowane na poszczególnych stykach. Poniżej wyszczególniono relacje pomiędzy stykami zdefiniowanym przez ITU-T a terminologią stosowaną w niniejszym opracowaniu. Serwer sterowania połączeniem jest odpowiednikiem bloku funkcjonalnego RACF (ang. Resource Admission and Control Function), który został dodatkowo podzielony na bloki PD (ang. Policy Decision) i TRC (ang. Transport Resource Control). Styk I C jest odpowiednikiem interfejsu R s, na którym przewiduje się zastosowanie protokołu Diameter [RFC3588]. Stykowi I S równoważny jest interfejs R i, dla którego jednak nie określono jeszcze typu protokołu. W zaleceniach ITU-T dotyczących NGN nie ma odpowiednika dla styku I OS i I Op. Warto dodać, że w ramach tej samej domeny, pomiędzy różnymi RACF wyróżniono dwa dodatkowe styki. Pomiędzy elementami PD jest to interfejs R d, natomiast pomiędzy elementami TRC zdefiniowano interfejs R p. Dla tego drugiego przewiduje się zastosowanie zdefiniowanego przez ITU-T protokołu RCIP (ang. Resource Connection Initiation Protocol) [Q ]. 10/104

11 2.2. Zasada komunikacji Na obecnym etapie prac przyjęto następującą notację dla typów wiadomości IF_MSGTYPE, gdzie IF jest symbolem styku, tj. IC, IS, IR itd., natomiast MSGTYPE to jest typem wiadomości. Zakłada się, że komunikacja na stykach I C, I S i I R będzie odbywała się na zasadzie żądanie-odpowiedź, z możliwością przesłania potwierdzenia przyjęcia żądania, tak jak to pokazano na rysunku 2.2. Zdecydowano, iż każde zapytanie musi zawierać unikalny identyfikator, który strona odpowiadająca umieści w odpowiedzi na to zapytanie. Dzięki temu klient będzie w stanie powiązać odpowiedź z żądaniem w przypadku wygenerowania kilku żądań w krótkim czasie. Identyfikator żądania jest liczbą dowolnie wybraną przez klienta. Ze strony serwera nie prowadzi się kontroli unikalności tego identyfikatora, za jej zapewnienie odpowiada klient. Należy podkreślić, iż różni klienci komunikujący się z danym serwerem mogą używać tych samych identyfikatorów. W ogólności nawet dany klient może ponownie użyć określonego identyfikatora, kiedy tylko poprzedni dialog jest zakończony. W rezultacie identyfikator żądania nie może być traktowany jako wartość unikalna w ramach serwera, a w szczególności nie może być użyty np. jako identyfikator ścieżki LSP. Klient Serwer IC_REQUEST Request ID: 1256 Request: Create Path [...] Przesłanie żądania do serwera. IC_ACKNOWLEDGE Request ID: 1256 Opcjonalne odesłanie potwierdzenia przyjęcia żądania do obsługi. IC_RESPONSE Request ID: 1256 Path ID: 275 [...] Odesłanie odpowiedzi zawierającej rezultat obsługi żądania. Rys Zasada komunikacji na styku I C. Jednym z podstawowych celów komunikacji na styku I S jest tworzenie ścieżek, których początek i koniec znajduje się w innej domenie. Taka ścieżka składa się z odcinków zlokalizowanych w różnych domenach, a więc kontrolowanych przez inne serwery połączeń. Każdy z tych serwerów jest odpowiedzialny za utworzenie własnego odcinka ścieżki. Aby z utworzonych odcinków stworzyć jedną ciągłą ścieżkę, konieczna jest dodatkowa wymiana danych pomiędzy serwerami połączeń i odpowiednia konfiguracja ścieżek po to, aby koniec jednego odcinka stał się początkiem następnego. W przypadku tworzenia dwukierunkowej ścieżki sprowadza się to do wymiany wartości etykiet przydzielonych przez rutery na brzegach domeny. Serwery następnie wysterowują rutery w celu połączenia obu fragmentów ścieżek. 11/104

12 Zagadnienie łączenia odcinków ścieżek zostało podjęte przez IETF [RFC5150]. W zaprezentowanym tam podejściu połączenie jednej ścieżki do drugiej następuje za pomocą pola explicit route (ERO) wiadomości PATH protokołu RSVP-TE. Poprzez odpowiednie zakodowanie istniejącej ścieżki jako kolejnego kroku (ang. hop) na drodze połączeniowej uzyskuje się sklejenie obu ścieżek. Na tym etapie badań wydaje się, że podejście takie nie może być wykorzystane w implementacji serwera połączeń, gdyż zakłada się, iż serwery nie wymieniają między sobą informacji o ścieżkach utworzonych we własnych domenach Współpraca z technologią ASON/GMPLS Przewiduje się, że styk I S może być interfejsem do serwera połączeń obsługującego urządzenia warstwy transportowej innej niż MPLS. W szczególności przewiduje się możliwość współpracy na styku I S z serwerami w domenie ASON/GMPLS. W warstwie serwerów sterowania połączeniem założono, iż przesyłane dane pozwolą na zestawienie ścieżki w warstwie zasobów niezależnie od zastosowanej tam technologii, ze szczególnym uwzględnieniem współpracy MPLS i ASON/GMPLS. Ze względu na inną technologię w warstwie zasobów następujące zagadnienia muszą zostać wzięte pod uwagę: reprezentacja liczbowa etykiet ma zupełnie inne znaczenie po stronie MPLS i ASON/GMPLS; serwer połączeń nie ma wiedzy w zakresie interpretacji wartości etykiety w innej domenie; na granicy domen może istnieć potrzeba modyfikacji wartości etykiet, w domenie ASON/GMPLS parametry określające jakość obsługi (straty pakietów i zmienność opóźnienia) nie mają zastosowania, gdyż parametrami branym pod uwagę przy rezerwacji ścieżki jest pasmo i opóźnienie; nieużywane parametry muszą być jednak przenoszone przezroczyście przez domenę ASON/GMPLS w celu ewentualnego użycia w kolejnej domenie Wiadomości komunikacyjne na styku I C Na styku I C służącym do komunikacji klienta z serwerem przewiduje się użycie następujących pięciu typów wiadomości: IC_CREATE_REQ, IC_DELETE_REQ, IC_MODIFY_REQ, IC_RESPONSE, IC_ACKNOWLEDGE. W kolejnych sekcjach opisano szczegółowo zadania poszczególnych wiadomości IC_CREATE_REQ IC_CREATE_REQ jest żądaniem utworzenia ścieżki. Klient przesyła do serwera żądanie zestawienia ścieżki pomiędzy określonymi adresami IP. Następujące dane są niezbędne do realizacji tej funkcji: adres IP klienta adres ten jest umieszczony w nagłówku IP, identyfikator żądania, początkowy adres IP, końcowy adres IP, maska podsieci adresu końcowego, pasmo ścieżki oraz klasa obsługi, pozwalająca określić priorytet tworzonej ścieżki. 12/104

13 O ile początkowy adres IP musi należeć do podsieci dołączonej do domeny zarządzanej przez serwer, o tyle końcowy adres IP może znajdować się poza własną domeną. W tym przypadku utworzenie dalszej części ścieżki zostanie zlecone serwerowi z innej domeny. Maska podsieci adresu końcowego pozwala określić, jaki zakres adresów końcowych należy do tej samej podsieci i przez to jakie adresy powinny być osiągalne przez tworzoną ścieżkę. Jest to informacja konieczna dla rutera brzegowego, który będzie klasyfikować przychodzący ruch IP do kreowanej ścieżki, tzn. będzie przydzielał ruch do klasy FEC (Forwarding Equivalence Class) [RFC3031]. Poza wymienionymi informacjami możliwe jest umieszczenie w żądaniu dodatkowych parametrów, zdefiniowanych w toku dalszych prac nad serwerem. Następujące parametry są przykładami parametrów opcjonalnych: wymagania jakościowe, określające dopuszczalne prawdopodobieństwo straty, opóźnienie i zmienność opóźnienia, dodatkowe informacje dla rutera brzegowego klasyfikującego ruch IP do ścieżki, np. numer portu TCP, informacje dla uwierzytelnienia nadawcy, pozwalające na realizację bardziej zaawansowanych mechanizmów bezpieczeństwa. W wyniku analizy scenariuszy zdecydowano o usunięciu z żądania dwóch pól: droga połączeniowa i priorytety ścieżki. Powody takiej decyzji są następujące: droga połączeniowa klient będący elementem spoza zarządzanej domeny nie ma wiedzy o topologii ani też nie ma uprawnień do wpływania na sposób rutingu wewnątrz domeny, priorytety setup i holding klient nie może decydować o priorytetach ścieżki wewnątrz domeny, gdyż doprowadziłoby to do nadmiernej ingerencji klienta w sposób rutingu wewnątrz domeny, a nawet naraziłoby domenę na niebezpieczeństwo niestabilności w przypadku generowania zgłoszeń o wysokim priorytecie. W odpowiedzi na żądanie IC_CREATE_REQ serwer podejmuje próbę utworzenia żądanej ścieżki. W odpowiedzi serwer odsyła wiadomość IC_RESPONSE, zawierającą unikalny w obrębie serwera identyfikator ścieżki lub zero w przypadku niepowodzenia. Przekazany w ten sposób identyfikator musi być potem użyty przez klienta w razie potrzeby skasowania lub modyfikacji ścieżki IC_DELETE_REQ IC_DELETE_REQ jest żądaniem skasowania ścieżki. Klient przesyła do serwera żądanie skasowania poprzednio zestawionej ścieżki. Następujące dane są niezbędne do realizacji tej funkcji: adres IP klienta adres ten jest umieszczony w nagłówku IP, unikalny identyfikator żądania, identyfikator ścieżki, przeznaczonej do usunięcia, otrzymany od serwera po utworzeniu ścieżki, informacje dla uwierzytelnienia nadawcy IC_MODIFY_REQ IC_MODIFY_REQ jest żądaniem modyfikacji ścieżki, przesyłanym do serwera w celu zmiany parametrów utworzonej wcześniej ścieżki. Parametry potrzebne do realizacji tej funkcji to: adres IP klienta, umieszczony w nagłówku IP, identyfikator żądania, 13/104

14 identyfikator ścieżki, informacje dla uwierzytelnienia nadawcy. Poza tymi danymi niezbędne jest dołączenie danych podlegających zmianie. Na bieżącym etapie prac zdecydowano, że nie jest możliwa zmiana drogi połączeniowej, zatem adresy IP początku i końca ścieżki nie mogą podlegać zmianie. W przypadku potrzeby zmiany położenia ścieżki należy wygenerować żądanie jej skasowania a następnie utworzyć nową ścieżkę. Nie jest również możliwa zmiana maski podsieci i innych parametrów do klasyfikacji ścieżki do klasy FEC. Zatem wśród danych podlegających zmianie mogą być następujące: pasmo ścieżki, klasa obsługi, wymagania jakościowe. Możliwe jest umieszczenie w pakiecie nie tylko danych, które podlegają zmianie, ale także danych niezmienionych, łącznie z powtórzeniem w pakiecie wszystkich danych dotyczących ścieżki, włączając w to adresy IP początku i końca ścieżki, których wartości jednak będą ignorowane IC_RESPONSE IC_RESPONSE jest odpowiedzią na żądanie utworzenia, skasowania lub modyfikacji ścieżki, przesyłaną przez serwer do klienta. Wiadomość zawiera następujące dane: identyfikator żądania, którego dotyczy odpowiedź, status operacji, identyfikator ścieżki. Wartość identyfikatora żądania jest zawsze tą samą wartością, jaka została przysłana do serwera w żądaniu, podobnie jak to pokazano na rysunku 2.2. Identyfikator umożliwia klientowi powiązać odpowiedź z żądaniem w przypadku wygenerowania przez klienta kilku żądań. Serwer nie wykonuje żądnej kontroli wartości identyfikatora. Identyfikator ścieżki jest liczbą całkowitą utworzony przez serwer i jest unikalny w ramach danego serwera, choć nie w ramach domeny lub sieci. Zapewnienie tych ostatnich może być osiągnięte przez odpowiednią konfigurację serwera, np. poprzez zadanie zakresu identyfikatorów ścieżek generowanych przez serwer. Identyfikator ścieżki musi być umieszczony w odpowiedzi na żądanie utworzenia ścieżki. Obecność tego pola w przypadku odpowiedzi na żądanie skasowania lub modyfikacji ścieżki nie jest wymagana i zostanie zweryfikowana w trakcie dalszych prac. W przypadku niemożności utworzenia ścieżki, identyfikator ścieżki jest równy zero, a pole status operacji zawiera kod błędu. Przykładowe przyczyny niepowodzenia są następujące: nieautoryzowany dostęp, brak wolnego pasma, brak zasobów, np. wyczerpany zbiór identyfikatorów ścieżek, niedostępna trasa, nieprawidłowe dane w żądaniu, przekroczony czas realizacji żądania. Pełna lista przyczyn niepowodzenia zostanie opracowana w trakcie prac implementacyjnych serwera. Status operacji w przypadku prawidłowego zakończenia operacji jest równy zero IC_ACKNOWLEDGE 14/104

15 IC_ACKNOWLEDGE jest potwierdzeniem przyjęcia żądania do przetwarzania. Wiadomość ta zawiera tylko jedną daną: identyfikator żądania. Potwierdzenie przyjęcia żądania ma na celu poinformowanie klienta, iż jego żądanie zostało odebrane i jest w trakcie realizacji. Wiadomość ta powinna być wysłana do klienta zawsze w przypadku, gdy czas realizacji zgłoszenia przekracza określony czas. Wartość tego czasu zostanie określona w trakcie prac nad implementacją serwera. W przypadku krótkiego czasu realizacji wysłanie zgłoszenia do klienta jest opcjonalne. Potwierdzenie nie powinno być wysyłane, jeśli zgłoszenie nie jest autoryzowane lub zostało odrzucone na etapie weryfikacji danych. Otrzymanie przez klienta potwierdzenia przyjęcia zgłoszenia jest potwierdzeniem, że zgłoszenie nie zostało wstępnie odrzucone i serwer jest w trakcie jego realizacji. Otrzymanie potwierdzenia nie oznacza, że żądanie zostanie poprawnie zrealizowane, ani że nie zostanie z innych powodów odrzucone na dalszym etapie jego przetwarzania. Klient nie powinien oczekiwać, iż każde przyjęte do przetwarzania zgłoszenie zostanie potwierdzone przez IC_ACKNOWLEDGE Wiadomości komunikacyjne na styku I S Styk I S służy do komunikacji pomiędzy różnymi serwerami starowania połączeniem. Serwery mogą być zlokalizowane w tej samej lub w różnych domenach. Przewiduje się użycie następujących typów wiadomości: IS_CREATE_REQ, IS_DELETE_REQ, IS_MODIFY_REQ, IS_RESPONSE, IS_ACKNOWLEDGE. Styk I S jest funkcjonalnie zbliżony do styku I C, dlatego oba zestawy wiadomości są podobne. W dalszej części opisano dokładniej poszczególne wiadomości, przy czym skupiono się na różnicach w stosunku do styku I C IS_CREATE_REQ IS_CREATE_REQ jest żądaniem utworzenia ścieżki. Serwer zleca utworzenie ścieżki innemu serwerowi, jeśli jej początek i koniec znajdują się obszarach kontrolowanych przez różne serwery, w szczególności w różnych domenach. Następujące dane są częścią w wiadomości: identyfikator żądania, początkowy adres IP, końcowy adres IP, pasmo ścieżki, klasa obsługi, wymagania jakościowe, informacje dla uwierzytelnienia nadawcy dane opcjonalne, etykieta, przydzielona przez ruter na granicy domeny dla komunikacji w kierunku od domeny serwera-adresata do serwera-nadawcy. Początkowy adres IP jest adresem ostatniego interfejsu w poprzedniej domenie, na którym zakończyła się ścieżka utworzona w poprzedniej domenie, tak jak to pokazano na rysunku /104

16 Domena A Domena B IS_CREATE_REQ Request ID: 238 Source IP: Label: 420 [...] Serwer połączeń A IS_RESPONSE Request ID: 238 Label: 235 [...] Serwer połączeń B Warstwa serwerów połaczeń IP: IP: Warstwa zasobów A Etykieta: 420 (kier. B do A) Etykieta: 235 (kier. A do B) B D Rys Żądanie utworzenia ścieżki i źródłowy adres IP w komunikacji na styku I S. C W odpowiedzi na żądanie IS_CREATE_REQ serwer-adresat podejmuje próbę utworzenia ścieżki w ramach własnej domeny, a ściślej przedłużenia ścieżki utworzonej w domenie serwera-nadawcy żądania. Po zakończeniu operacji serwer-adresat żądania odsyła do serweranadawcy żądania wiadomość IS_RESPONSE, która podobnie jak w przypadku komunikacji na styku I C zawiera identyfikator ścieżki i status operacji. Żądanie utworzenia ścieżki na styku I S zawsze dotyczy ścieżki tworzonej przez przynajmniej dwa serwery połączeń i składanej z fragmentów obejmujących zwykle różne domeny. Aby ścieżka była kompletna, wymagane jest więc utworzenie fragmentu ścieżki na łączu międzydomenowym, tj. pomiędzy adresami a na rysunku 2.3. Zestawienie tego odcinka ścieżki musi być przeprowadzone przez serwery połączeń z obu sąsiednich domen. Konieczne jest jednak poinformowanie serwera sąsiedniej domeny o etykiecie ustawionej we własnym ruterze. Odpowiednia komunikacja musi odbywać się w dwie strony, gdyż tworzone muszą być ścieżki dwukierunkowe; wynika to z założeń dla sieci GMPLS [RFC3945]. W kierunku do rutera-adresata wartość etykiety zostaje przekazana w dodatkowym polu wiadomości IS_CREATE_REQ, natomiast w kierunku do serweranadawcy w wiadomości IS_RESPONSE IS_DELETE_REQ IS_DELETE_REQ jest żądaniem skasowania ścieżki wygenerowanym przez serwer, który zlecił wcześniej jej utworzenie. Następujące dane są niezbędne do realizacji tej funkcji: identyfikator żądania, identyfikator ścieżki przeznaczonej do usunięcia, otrzymany od serwera-adresata w momencie tworzenia ścieżki. 16/104

17 IS_MODIFY_REQ IS_MODIFY_REQ jest żądaniem modyfikacji ścieżki, wysłanym przez serwer zlecający wcześniej utworzenie ścieżki. przesyłanym do serwera w celu zmiany parametrów utworzonej wcześniej ścieżki. Parametry potrzebne do realizacji tej funkcji to: adres IP klienta, umieszczony w nagłówku IP, identyfikator żądania, identyfikator ścieżki. Poza tymi danymi niezbędne jest dołączenie przynajmniej jednej danej podlegającej zmianie, przy czym nie można zmieniać drogi połączeniowej. Należy więc dodać jedną lub więcej następujących danych: pasmo ścieżki, klasa obsługi, wymagania jakościowe. Możliwe jest umieszczenie w pakiecie nie tylko danych, które podlegają zmianie, ale także danych niezmienionych, przy czym ewentualna obecność adresów IP początku i końca ścieżki będzie ignorowane przez serwer wykonujący żądanie IS_RESPONSE IS_RESPONSE jest odpowiedzią na żądanie utworzenia, skasowania lub modyfikacji ścieżki. Wiadomość ta jest przesyłana od adresata żądania do nadawcy. Wiadomość zawiera następujące dane: identyfikator żądania, którego dotyczy odpowiedź, status operacji, identyfikator ścieżki, etykieta, nadana na łączu międzydomenowym. Wartość identyfikatora żądania jest zawsze tą samą wartością, jaką serwer otrzymuje w żądaniu. Obecność w pakiecie identyfikatora ścieżki jest obowiązkowa w przypadku odpowiedzi na żądanie utworzenia ścieżki, ale nie jest wymagana dla odpowiedzi na żądanie skasowania lub modyfikacji ścieżki. Jego obecność w tych przypadkach zostanie zweryfikowana w trakcie dalszych prac. Jeśli nie udało się zrealizować żądania, wówczas identyfikator ścieżki (jeśli jest obecny) jest równy zero, a pole statusu operacji zawiera kod błędu. Lista możliwych przyczyn zostanie opracowana w trakcie implementacji serwera. Status operacji w przypadku zrealizowania żądania jest równy zero IS_ACKNOWLEDGE IS_ACKNOWLEDGE jest potwierdzeniem przyjęcia żądania do przetwarzania. Wiadomość ta zawiera tylko jedną daną: identyfikator żądania. Rola wiadomości potwierdzającej przyjęcie żądania jest analogiczna do roli analogicznej informacji wysyłanej do klienta na styku I C. Szczegóły zawarto w rozdziale Wiadomości komunikacyjne na styku I R Styk I R służy do komunikacji pomiędzy serwerem w warstwie sterowania połączeniami a ruterami w warstwie zasobów. Przedmiotem komunikacji jest skonfigurowanie ruterów, 17/104

18 głównie pod kątem tworzenia, kasowania i modyfikacji ścieżek. Przewiduje się użycie na styku I R następujących typów wiadomości: IR_CREATE_REQ, IR_DELETE_REQ, IR_MODIFY_REQ, IR_RESPONSE. Styk I R ma pewne ograniczenia wynikające stąd, że rutery są często istniejącymi elementami sieci i mogą nie wspierać protokołów wybranych do współpracy z serwerem sterowania połączeń. Stąd przewiduje się, że dopuszczalnym sposobem komunikacji na styku I R będzie sesja ssh lub telnet. Z tego powodu zrezygnowano z wykorzystania na tym styku komunikatu IR_ACKNOWLEDGE, który w tym przypadku nie byłby potrzebny IR_CREATE_REQ IR_CREATE_REQ jest żądaniem utworzenia ścieżki lub fragmentu ścieżki. Na bieżącym etapie prac zakłada się, iż serwery mogą ale nie muszą wykorzystywać protokołu RSVP-TE w warstwie zasobów. Zależnie od wybranego sposobu, serwer zleca jednemu ruterowi utworzenie kompletnej ścieżki bądź każdemu ruterowi lokalnego odcinka ścieżki, co zilustrowano na rysunku Serwer połączeń 1a Serwer połączeń 1c Warstwa serwerów połaczeń 1b Warstwa zasobów A C A C B 1 IR_CREATE_REQ 2,3 PATH (RSVP) 4,5 RESV (RSVP) B 1 IR_CREATE_REQ Pośrednie tworzenie ścieżek przez serwer z wykorzystaniem protokołu RSVP -TE Bezpośrednie tworzenie ścieżek przez serwer Rys Dwa tryby tworzenia ścieżki na drodze A-B-C na styku I R. W przypadku wykorzystania protokołu RSVP-TE, pierwszemu ruterowi na drodze połączeniowej przekazane są następujące informacje: trasa dla ścieżki, w postaci listy adresów IP interfejsów, pasmo ścieżki, priorytety setup i holding. maska podsieci dla adresu docelowego, inne parametry do klasyfikacji ruchu IP do klasy FEC. 18/104

19 W przypadku bezpośredniego tworzenia ścieżki, bez wykorzystania RSVP-TE, następujące dane są dostarczane do każdego z serwerów na drodze połączeniowej: interfejs i etykieta wejściowa, interfejs i etykieta wyjściowa, pasmo ścieżki, priorytety setup i holding. Dodatkowo do pierwszego rutera na drodze połączeniowej należy dostarczyć informacje umożliwiające prawidłową klasyfikację ruchu IP: maska podsieci dla adresu docelowego, inne parametry do klasyfikacji ruchu IP do klasy FEC. W odpowiedzi na żądanie IR_CREATE_REQ ruter powinien odpowiedzieć wiadomością IR_RESPONSE ze statusem operacji i identyfikatorem ścieżki. Tryb tworzenie ścieżek zależy od możliwości wykorzystania protokołu RSVP-TE i od przyjętych założeń odnośnie wymaganej szybkości utworzenia ścieżki. Użycie protokołu RSVP-TE może pozwolić na uproszczenie procedur obsługi żądań, natomiast bezpośrednie sterowanie powinno pozwolić na szybsze tworzenie ścieżek IR_DELETE_REQ IR_DELETE_REQ jest żądaniem skasowania odcinka ścieżki w warstwie zasobów. Niezależnie od tego, czy wykorzystany jest protokół RSVP-TE czy nie, niezbędne jest dostarczenie pierwszemu (gdy używany RSVP-TE) lub wszystkim ruterom na drodze połączeniowej (gdy nie używany RSVP-TE) następującej danej: identyfikator ścieżki przeznaczonej do usunięcia, otrzymany od serwera-adresata w momencie tworzenia ścieżki. W trakcie dalszych prac zostanie zweryfikowane, czy wybór określonego protokołu dla styku I R nie narzuca przesyłania wraz z wiadomością IR_DELETE_REQ innych parametrów IR_MODIFY_REQ IR_MODIFY_REQ jest żądaniem modyfikacji własności ścieżki w warstwie zasobów. Niezależnie od tego, czy wykorzystuje się protokół RSVP-TE czy nie, nie jest wspierana zmiana trasy ścieżki lub kryteriów klasyfikacji ruchu IP do danej ścieżki. Parametr potrzebny do realizacji tej funkcji to: identyfikator ścieżki. Poza tym należy dołączyć podlegające zmianie cechy ścieżki, wśród których mogą wystąpić następujące dane: pasmo ścieżki, priorytety setup i holding. Możliwe jest umieszczenie w pakiecie nie tylko danych, które podlegają zmianie, ale także danych niezmienionych. Można również dołączyć parametry spoza listy cech ścieżki podlegających zmianie, ale zostaną one zignorowane IR_RESPONSE IR_RESPONSE jest odpowiedzią rutera na żądanie utworzenia, skasowania lub modyfikacji ścieżki. Wiadomość ta powinna zawierać następujące dane: status operacji, identyfikator ścieżki. 19/104

20 2.6. Scenariusz obsługi wiadomości Scenariusz obsługi wiadomości zostanie omówiony na przykładzie wiadomości IC_CREATE_REQ będącej żądaniem utworzenia ścieżki. Przyjęto, że ścieżka przechodzi przez dwie różne domeny, z których tylko druga używa protokołu RSVP-TE do zestawienia ścieżki. Na rysunku 2.5 przedstawiono taki scenariusz, w którym zestawiona ma być ścieżka od rutera A do F a wybrana droga połączeniowa to A-B-C-D-E-F, gdzie łącze C-D jest łączem międzydomenowym. Domena A Domena B Serwer połączeń Serwer połączeń IC_CREATE_REQ IC_RESPONSE IS_CREATE_REQ IS_RESPONSE IR_CREATE_REQ IR_RESPONSE IR_CREATE_REQ IR_RESPONSE A C D F PATH (RSVP) RESV (RSVP) PATH (RSVP) RESV (RSVP) B E Rys Przykładowy scenariusz obsługi żądania zestawienia ścieżki. Są dwa warianty scenariusza zestawienia połączenia przez dwie domeny. W pierwszym żądanie zestawienia ścieżki w następnej domenie zostaje wysłane dopiero po poprawnym zestawieniu ścieżki we własnej domenie. W drugim scenariuszu przesłanie żądania do następnej domeny odbywa się zanim powstanie ścieżka we własnej domenie. Na rysunku 2.6. przedstawiono diagram obsługi wiadomości dla pierwszego scenariusza. Po otrzymaniu wiadomości IC_CREATE_REQ serwer w domenie A określa drogę połączeniową i interfejs wyjściowy do domeny B. Ponieważ domena A nie używa protokołu RSVP- TE, serwer wysyła do wszystkich ruterów żądania IR_CREATE_REQ. Po odebraniu od wszystkich ruterów pozytywnego potwierdzenia jest już zestawiony odcinek ścieżki przez domenę A. Następnie serwer przesyła żądanie zestawienie dalszego odcinka ścieżki do serwera w domenie B za pomocą wiadomości IS_CREATE_REQ. Serwer w domenie B po otrzymaniu wiadomości IS_CREATE_REQ określa swój odcinek drogi połączeniowej. Ponieważ używany jest protokół RSVP-TE, żądanie IR_CREATE_REQ jest skierowane tylko do pierwszego rutera na drodze połączeniowej, tzn. do rutera D. Ten tworzy wiadomość RSVP PATH zawierającą drogę połączeniową w elemencie ERO (explicite router) i przesyła ją w kierunku rutera E. Po otrzymaniu pozytywnej odpowiedzi z rutera D, serwer odsyła do serwera w domenie A potwierdzenie utworzenia 20/104

21 swojego odcinka ścieżki w wiadomości IS_RESPONSE. Jest to informacja dla serwera w domenie A, że cała żądana przez klienta ścieżka została zestawiona, co jest sygnalizowane klientowi poprzez wysłanie potwierdzenia IC_RESPONSE. Od tego momentu ścieżka może być używana. Domena A Domena B klient serwer połączeń warstwa zasobów serwer połączeń warstwa zasobów IC_CREATE_REQ IR_CREATE_REQ IR_RESPONSE IS_CREATE_REQ IR_CREATE_REQ IR_RESPONSE IS_RESPONSE IC_RESPONSE Sterowanie bezpośrednie Sterowanie z użyciem RSVP-TE Rys Diagram obsługi wiadomości dla scenariusza z rysunku 2.5. Drugi scenariusz przewiduje wysłanie żądania do serwera w domenie B jeszcze przed zestawieniem lokalnego odcinka ścieżki. Zyskać można w ten sposób szybsze zestawienie całej ścieżki. Pewnym ryzykiem jest możliwość uzyskania negatywnej odpowiedzi z domeny B, z powodu np. braku pasma, już po zestawieniu lokalnego odcinka ścieżki, co musi skutkować usunięciem właśnie zestawionego odcinka lokalnego. Problemem jest w tym przypadku nieznajomość wartości etykiety akceptowanej przy połączeniu przychodzącym z domeny B i konieczność przekazania jej wartości później poprzez dodatkową komunikację pomiędzy serwerami. 21/104

22 Domena A Domena B klient serwer połączeń warstwa zasobów serwer połączeń warstwa zasobów IC_CREATE_REQ IS_CREATE_REQ IR_CREATE_REQ IR_CREATE_REQ Rys Fragment scenariusza obsługi wiadomości IC_CREATE_REQ dla przypadku wczesnego przesyłania żądania do domeny B Procedury obsługi wiadomości W tym rozdziale przedstawiono schemat działań jakie podejmuje serwer w reakcji na otrzymanie poszczególnych wiadomości. Dla ułatwienia opisu zadań wykonywanych przez serwer, na rysunku 2.8 przedstawiono schemat blokowo-funkcjonalny serwera sterownia połączeniem. Omówienie poszczególnych bloków funkcjonalnych i ich rola została zawarta w poprzedniej części raportu tego projektu [KACZ208]. Informacje o działaniach serwera sterowania połączeniem zawarto w formie tabeli, w której wyróżniono numer, nazwę i opis etapu procedury, określono blok odpowiedzialny za przeprowadzenie danego etapu, podano skąd pobierana jest informacja niezbędna do wykonania danego etapu, a także podano warunek pozytywnego zakończenia danego etapu oraz jakie kroki są podejmowane w przypadku pozytywnego i negatywnego zakończenia. Kroki oraz dane opcjonalne oznaczono symbolem (O). Ich obecność zostanie zweryfikowana na etapie testów serwera. W odniesieniu do danych używanych na danym etapie w nawiasach podano źródło ich uzyskania: nagłówek IP: nagłówek pakietu zawierającego żądanie, dane: informacje zawarte w żądaniu, konfiguracja: informacja zawarta w konfiguracji serwera (w bazie danych), ruting: informacja wygenerowana przez funkcje bloku rutingu, sterowanie: informacja wygenerowana przez blok sterowania. Procedury obsługi wiadomości w postaci schematów zostały przedstawione na rysunkach 2.9 i Oba schematy opisują działania podejmowane przez serwer po otrzymaniu wiadomości z żądaniem utworzenia, skasowania lub modyfikacji ścieżki. Przedstawiona kolejność działań zakłada wykorzystanie scenariusza z rysunku 2.6, w którym żądanie do kolejnej domeny zostaje wysłane dopiero po zestawieniu lokalnego odcinka ścieżki. 22/104

23 Pliki Pliki dziennika dziennika Baza danych autoryzacji Autoryzacja Dane o zajętości łączy Topologia sieci Styki I C, I S i I R Mediacja Bufor wejściowy Ruting Wywłaszczanie Styk I OS Styk I Op Wejściewyjście Sterowanie Lista aktywnych połączeń Lista aktywnych transakcji Rys.2.8. Schemat blokowo-funkcjonalny serwera obsługi połączeń. 23/104