Modelowanie sieci szkieletowych następnej generacji Raport techniczny*

Modelowanie sieci szkieletowych następnej generacji Raport techniczny* Paweł Różycki, Andrzej Niedziałek, Janusz Korniak, Leszek Puzio, Leszek Gajecki, Rafał Niemiec, Paweł Cudek, Łukasz Tomal, Krzysztof Sobejko, Oleksandr Kolodiychuk Wyższa Szkoła Informatyki i Zarządzania w Rzeszowie prozycki@wsiz.rzeszow.pl W pracy przedstawiono koncepcje modelowania sieci GMPLS/ASON, założenia implementacji modelu oraz przykłady implementacji w popularnych środowiskach Omnet++ oraz ns-2. 1. Wprowadzenie Coraz powszechniejszy szerokopasmowy dostep do sieci globalnej powoduje coraz dynamiczny rozwój technologii i usług internetowych takich jak VoIP czy VideoOn-Demand powoduje, że udział ruchu IP w całkowitym ruchu ciagle rosnie. Jednoczesnie usługi te wymagaja coraz to wiekszych predkosci transmisji przy zachowaniu wysokiej jakosci szczególnie, jesli chodzi o małe czasy opóznien i duża niezawodnosc. Ten drugi parametr jest szczególnie istotny na przykład przy pewnych zastosowanych w medycynie. Współczesne sieci szkieletowe, oparte w głównie na technologii SDH/WDM, projektowane były głównie do obsługi ruchu telefonicznego, co powoduje, że realizacja usług IP na odpowiednim QoS wymusza stosowanie czesto skomplikowanego i zasobożernego, a przez to kosztownego przesyłania tegoż ruchu za posrednictwem nawet kilku protokołów i technologii posrednich. Typowe sieci do transmisji danych maja budowe czterowarstwowa. Warstwa IP dla aplikacji i usług, ATM (Asynchronous Transfer Mode) dla realizacji inżynierii ruchu, warstwa SONET/SDH odpowiedzialna za transport oraz DWDM (Dense Wavelength- Division Multiplexing) dla zapewnienia odpowiednich przepływnosci. Taka wielowarstwowa architektura powoduje, że zarzadzanie nią, a w szczególnosci realizacja nowoczesnych usług na żadanie staje sie bardzo trudna. Odpowiedzia na te problemy jest koncepcja sieci opartych na zasadzie integracji różnych technik przełaczania, łaczac w sobie zalety możliwosci użycia wielu warstw (tzw. stosu protokołów) a w raz z nimi niektórych ich mechanizmów (np. odtworzenie ruchu poniżej 50 ms w sieciach SDH) z możliwoscia zarzadzania wspólnego zintegrowanego mechanizmu sterowania. Koncepcje taka prezentuje z jednej strony srodowisko zwiazane z IETF czego efektem jest stworzenie wstepnych wersji specyfikacji dla sieci GMPLS (Generalized Multiprotocol Label Switching), z drugiej rozwijana przez Miedzynarodowa Unie Telekomunikacyjna (ITU-T) koncepcja ASON (Automatically Switched Optical Network), w * Raport przygotowany w projektu: Nowe metody analizy i optymalizacji architektury złożonych sieci telekomunikacyjnych następnej generacji. Projekt współfinansowany ze środków Unii Europejskiej z Europejskiego Funduszu Rozwoju Regionalnego oraz z budżetu Państwa w ramach Regionalnego Programu Operacyjnego Województwa Podkarpackiego na lata 2007 2013. Inwestujemy w rozwój województwa podkarpackiego.

której jako jedna z możliwych opcji, podaje się zastosowanie mechanizmów sterowania takich jak w sieci GMPLS. Działanie sieci GMPLS opiera sie na przeniesieniu koncepcji przełaczania etykiet znanej z sieci MPLS na inne warstwy sieci transportowej takie od przełaczania przestrzennego na poziomie łaczy swiatłowodowych, poprzez przełaczenie długosci fali na poziomie zwielokrotnienia falowego WDM, przełaczenie w systemach o zwielokrotnieniu czasu TDM po przełaczenie pakietów. W przypadku warstw niższych role etykiet pełnia tu konkretne zasoby takie jak długosc fali czy szczelina czasowa, a nie abstrakcyjny numer jak w przypadku klasycznego MPLS. W celu lepszej skalowalnosci i efektywnosci siec podzielono na płaszczyzny funkcjonalne: płaszczyzne danych zwiazana z przełaczaniem w tej płaszczyznie przenoszone są dane użytkowników; płaszczyzne sterowania zwiazana z procesami realizujacymi usługi tutaj w sposób automatyczny beda realizowane usługi (np. zestawianie i usuwanie połaczen); płaszczyzne zarzadzania pełniaca role nadzorcza ta płaszczyzna nie jest brana pod uwage w specyfikacjach GMPLS ale w komercyjnych zastosowaniach bedzie odgrywała bardzo istotna role zwiazana z realizacja strategii funkcjonowania sieci (policy). Nad efektywnym wykorzystaniem zasobów oraz sposobem realizacji usług czuwac ma rozproszony mechanizm oparty o znane z MPLS, rozszerzone o nowe własciwosci, protokoły dystrybucji etykiet takie jak RSVP-TE, CR-LDP, protokoły routingu IS-IS, OSPF oraz nowy protokół zarzadzajacy kanałami sygnalizacyjnymi LMP (Link Management Protocol). 2. Architektura sieci ASON/GMPLS Kluczowa role w funkcjonowaniu GMPLS odgrywa płaszczyzna sterowania. Jej mechanizmy odpowiedzialne sa m.in. za automatyczne zestawianie i usuwanie połaczen - tzw. LSP (Label Switched Path) - oraz zarzadzanie zasobami sieciowymi. Do tych celów używane sa znane z MPLS protokoły sygnalizacyjne (RSVP lub LDP) oraz routingu (OSPF lub IS-IS). Wiadomosci wymienionych protokołów sa przesyłane między wezłami sieci poprzez tzw. kanały sygnalizacyjne tworzace siec sygnalizacyjna, która w swym założeniu jest niezależna od płaszczyzny danych, w której realizowana jest transmisja. Poszczególne kanały sygnalizacyjne moga byc wydzielane z łacza transmisyjnego np. korzystajac z kanału DCC w nagłówku kontenera SDH, lub wydzielenie kanału wirtualnego VCC w sieci ATM. W tym przypadku mówimy o sygnalizacji in-fiber. Możliwe jest jednak użycie kanałów niezależnych, odseparowanych fizycznie od płaszczyzny danych np. poprzez wydzielenie dedykowanego łacza miedzy poszczególnymi wezłami. W tym przypadku mówimy o sygnalizacji typu out-of-fiber. Realizacja kanałów tego drugiego typu pozwala na tworzenie całkowicie lub czesciowo fizycznie odseparowanych od siebie sieci: sieci płaszczyzny sterowania oraz sieci płaszczyzny danych. W przypadku gdy topologie płaszczyzn sa takie same (np. w przypadku realizacji sieci typu in-fiber) mówimy o symetrycznej architekturzepłaszczyzn. W przeciwnym wypadku mamy do czynienia z architektura asymetryczna. Należy pamietac, że w przypadku komercyjnych zastosowan specyfikacja ITU-T przewiduje stosowanie dodatkowo płaszczyzny zarzadzania, która

również wymaga sieci komunikacyjnej, która w ogólnym przypadku równie# mo#e byc niezależna od pozostałych. W przypadku architektury niesymetrycznej wezły połaczone bezposrednio w płaszczyznie danych moga nie miec bezposredniego połaczenia w płaszczyznie sterowania, podobnie jak moga istniec kanały sygnalizacyjne miedzy wezłami niesasiednimi w płaszczyznie danych. Należy zwrócic uwage na fakt, że w każdej z płaszczyzn funkcjonalnych musi być realizowany niezależny routing, co oznacza, że w płaszczyznie sterowania oprócz protokołów sygnalizacyjnych takich jak RSVP beda uruchomione dwie instancje routingu, np. OSPF. Taka separacja powoduje, że struktura sieci staje sie skomplikowana, trudna w implementacji. Wymagane jest np. wprowadzenie niezależnej adresacji w poszczególnych płaszczyznach czy mechanizmów identyfikacji sasiadów. Zastosowanie architektury asymetrycznej, a przede wszystkim sygnalizacji outof-fiber może miec jednak wiele zalet, zwłaszcza w obszarze zapewniania niezawodnosci sieci. Sygnalizacja tego typu może także znacznie uproscic praktyczna implementacje sieci w przypadku gdy mamy do czynienia z systemami w których wydzielenie pakietów IP jest szczególnie trudne lub kosztowne. Przykładem tutaj sa krosownice optyczne OXC (Optical Cross-Connect) które działaja na poziomie przełaczania długosci fali lub nawet całych sygnałów swiatłowodowych. W tym przypadku proces przełaczania może byc realizowany w domenie optycznej bez koniecznosci stosowania, szczególnie kosztownego przy dużych przepływnosciach, przetwarzania optoelektrycznego. 3. Modelowanie ASON/GMPLS Kolejne rozdziały daja przegląd narzędzi wykorzystywanych do realizacji symulatora ASON/GMPLS, który jest głównym przedmiotem pracy. W pierwszej części przedstawione jest środowisko symulacji OMNeT++, następnie framework INET dla OMNeT ++ gdzie zostanie szczegółowo opisana architektura modułu routera MPLS będącego podstawą implementacji modułu ASON/GMPLS. W kolejnych rozdziałach przedstawiony zostanie model sieci utworzony w środowisku ns-2. 4. Modelowanie w środowisku Omnet++ Omnet++ jest modułowym symulatorem zdarzeń dyskretnych używanym głównie do modelowania i symulowania sieci teleinformatycznych, w szczególności m.in. do: Modelowanie ruchu sieciach telekomunikacyjnych Modelowania protokołów Modelowanie systemów kolejkowych Modelowania systemów wieloprocesorowych oraz innych rozproszonych systemów Modelowania i walidacji architektur sprzętowych Weryfikacji aspektów wydajnościowych w systemach złożonych Modele w Omnet++ składają się z zagnieżdżonych modułów, przy czym głębokość zagnieżdzenia nie jest ograniczona stąd możliwe jest modelowanie dowolnie złożonej struktury. Moduły komunikują się przy pomocy komunikatów, które mogą mieć dowolnie złożoną strukturę. Moduły mogą przesyłać komunikaty bezpośrednio do przeznaczenia lub

wzdłuż określonej, predefiniowanej ścieżki za pośrednictwem bramek (gates) i połączeń (connections). Moduły mogą mieć określone własne parametry. Parametry mogą być wykorzystywane do dostosowania modułu jego zachowanie i parametryzacji topologii modelu. Moduły najniższego poziomu kodowanie w języku C++ implementują atomowe elementy symulowanego systemu/sieci i mogą być łączone w większe struktury. OMNeT ++ zapewnia wydajne narzędzia, pozwalające opisać strukturę system. Głównymi cechami są: hierarchicznie zagnieżdżone moduły, moduły przesyłają komunikaty przez kanały, elastyczne parametry modułu, język opisu topologii. Model Omnet++ składa się z hierarchicznie zagnieżdżonych modułów, które komunikują się przesyłając między sobą komunikaty. Moduły najniższego poziomu, napisane w języku C++ de facto implementujące elementarne zachowanie systemu i korzystające z bibliotek dostępnych w Omnet++, mogą być łączne w większe moduły będące bardziej złożonymi elementami modelu. Struktura modułu jest opisywana w skojarzonym z nim pliku NED (Network Element Descriptor). Tworząc model sieci korzystamy z tak utworzonych deskryptorów w celu zamodelowania dowolnie złożonych struktur. Moduły mogą mieć zdefiniowane parametry, którym wartości można ustwiać na poziomie pliku NED lub na poziomie pliku konfiguracyjnego całego modelu (zazwyczaj omentpp.ini) Moduły komunikują się przesyłając między sobą komunikaty, które mogą reprezentować pakiety, ramki, wiadomości czy inne elementy które mogą być przekazywane między modułami. Komunikaty mogą mieć dowolną strukturę. Oprócz modułów w modelach występują także następujące elementy: bramki (gates), które reprezentują interfesy wejścia/wyjścia danego modułu komunikaty są wysyłane przez bramkę wyjściową jednego modułu do bramki wejściowej innego modułu. Połączenia (connection lub link) łączy moduły na danym poziomie. Połączenia mają zazwyczaj zdefiniowane następujące parametry: data rate, propagation delay, bit error rate Poszczególne elementy modeli (moduły, komnikaty itd) są reprezentowane przez klasy C++, które zostały zaprojektowane w ten sposób aby efektywnie współpracowały ze sobą. Podsumowując model Omnet++ składa się z następujących elementów: Implementacji modułów plików C++ (.cpp/.h) Plików opisujących modele (moduły oraz całe sieci) pliki NED Definicji komunikatów pliki.msg. Omnet++ na etapie kompilacji generuje na ich podstawie klasy C++. Program symulacji jest budowany z wyżej wymienionych elementów. Pliki.msg są konwertowane do plików C++ przy użyciu narzędzia opp_msgc. Następnie wraz z modułami napisanymi w C++ są one kompilowane i linkowane z bibliotekami udosępnionymi przez środowisko Omnet++ tworząc plik wykonywalny. Piki NED także mogą być (opcjonalnie)

konwertowane do kodów C++ (narzędzie nedtool) lub mogą być dynamicznie ładowane podczas uruchamiania symulacji, co pozwala zwiększyć możliwości konfiguracyjne podczas przeprowadzania różnych scenariuszy. W wyniku otrzymujemy plik wykonywalny który podczas uruchamiania pobiera parametry sieci oraz scenariusza/y z pliku konfiguracyjnego (zazwyczaj omnetpp.ini) lub/i plików.ned. INET Framework Jest to zestaw modułów i modeli dla środowiska Omnet++ z impelementacją wybranych protokołów i aplikacji takich jak IPv4, IPv6, TCP, UDP, PPP, czy RSVP.

Rysunek 1: Model sieci MPLS ze środowiska Omnet++ Rysunek 2: Implementacja węzła MPLS Jako przykład implementacji modelu w INET posłuży MPLS, który został w niniejszej pracy użyty jako podstawa implementacji modelu sieci ASON/GMPLS oraz przykładowu model załączony do INET (Rysunek 1). Zawiera on kilka połączonych węzłów MPLS o nazwach LSR, do których dołączono urządzenia końcowe host1 do host5. Z punktu widzenia niniejszej pracy szczególnie istotna jest budowa węzła LSR. Została ona przedstawiona na Rysunku Rysunek. Odzwierciedla ona typowy stos protokołów stosowany w MPLS. U góry protokoły wyższych warstw czyli routing i sygnalizacja (RSVP w tym przypadku choć Omnet++ implementuje także LDP) poprzez warstwę sieciową reprezentowaną przez moduł

NetworkLayer po warstwę łącza danych reprezentowaną przez moduł protokołu PPP. Między tymi ostatnimi modułami umieszczony jest moduł MPLS. Podobnie implementowany jest w INET host, którego model został przedstawiony na rysunku 3. Na uwagę zasługuje model tablicy routingu, który jest umieszczony w obu typach węzła. Tablice routingu mogą być inicjowane statycznie przy pomocy plików konfiguracyjnych zawierających ponadto konfigurację interfejsów. Przykladowy plik dla LSR3 został przedstawiony poniżej. ifconfig: name: ppp0 inet_addr: 10.1.3.1 MTU: 1500 Metric: 1 name: ppp1 inet_addr: 10.1.3.2 MTU: 1500 Metric: 1 name: ppp2 inet_addr: 10.1.3.3 MTU: 1500 Metric: 1 ifconfigend. route: 10.1.1.1 10.1.1.2 255.255.255.255 H 0 ppp0 10.1.4.1 10.1.4.3 255.255.255.255 H 0 ppp1 10.1.7.1 10.1.7.1 255.255.255.255 H 0 ppp2 routeend. Sekcja ifconfig: ifconfigured. zawiera konfiguracji interfejsów a sekcja route: routeend. zawiera konfigurację routingu statycznego. Format konfiguracji interfejsu: name: nazwa interfejsu (np.: eth0, ppp0) inet_addr: adres IP Mask: maska IP Groups: grupy multikastowe MTU: MTU łącza (np. dla Ethernetu 1500) Metric: metryka flags: BROADCAST, MULTICAST, POINTTOPOINT Format konfiguracji tras: Destination Gateway Netmask Flags Metric Interface

Rysunek 3: Model hosta w INET Oment++ Ponadto w przypadku modułu MPLS należy skonfigurować ustawienia modułów Classifier, RSVP oraz LIBTable. Jest to realizowane poprzez pliki XML. Przykład pliku konfiguracyjnego dla modułu Classifier został przedstawiony poniżej. Określa on klasyfikację określonego strumienia pakietów między danymi hostami i skojarzenie go z danym tunelem logicznym określonym przez tunnel_id oraz lspid <?xml version="1.0"?> <fectable> <fecentry> <id>1</id> <destination>host3</destination> <source>host1</source> <tunnel_id>1</tunnel_id> <lspid>100</lspid> </fecentry> </fectable> Plik konfiguracja RSVP określa konfigurację sesji na danym węźle MPLS w których można określić ścieżki dla poszczególnych połączeń LSP określonych przez parę tunnel_id/lsp_id. Przykładowy plik został przedstawiony poniżej. <sessions> <session> <endpoint>host3</endpoint> <tunnel_id>1</tunnel_id> <paths> <path> <lspid>100</lspid> <bandwidth>100000</bandwidth> <route> <node>lsr1%routerid</node>

<node>lsr2%routerid</node> <node>lsr4%routerid</node> <node>lsr5%routerid</node> </route> <permanent>true</permanent> <color>100</color> </path> </paths> </session> </sessions> W końcu plik konfiguracyjny LIBTable określa co dany węzeł MPLS ma zrobić z pakietem opisanym przez daną etykietę. Przykład takiej konfiguracji został pokazany poniżej: <?xml version="1.0"?> <libtable> <libentry> <inlabel>203</inlabel> <ininterface>ppp1</ininterface> <outinterface>ppp2</outinterface> <outlabel> <op code="pop"/> </outlabel> <color>200</color> </libentry> <libentry> <inlabel>202</inlabel> <ininterface>ppp0</ininterface> <outinterface>ppp4</outinterface> <outlabel> <op code="swap" value="203"/> </outlabel> <color>300</color> </libentry> </libtable> W podanym przykładzie pakiet opatrzony etykietą 203, który pojawi się na interfejsie ppp1 ma być skierowany na interfejs ppp2 a etykieta ma być z niego usunięta, a pakiet opatrzony etykietą 202 z interfejsu ppp0 ma być skierowany na interfejs ppp4 z etykietą o wartości 203. Modelowanie ASON/GMPLS w narzędziu Omnet++/INET Framework INET, mimo wielu zalet i implementacji szerokiej gamy protokołów w wielu warstwach modeli ISO nie zawiera wsparcia dla sieci GMPLS/ASON. Należy zauważyć, że również tak potężne narzędzia jak Riverband OPNET nie zawiera implementacji tego typu sieci. Ze względu jednak na to, że zarówno Omnet++ jak i biblioteka INET jest ogólnodostępna na zasadach open source oraz fakt że INET zawiera już podstawowe implementacje protokołów wykorzystywanych w tego typu sieciach można rozpocząć implementację symulatora sieci GMPLS w tym właśnie środowisku. Projekt i implementacja powinna zawierać:

Rozszerzenie istniejących protokołów RSVP-TE oraz protokołu routingu Linkstate tak aby wspierały one GMPLS/ASON Projekt i implementacja przełącznicy optycznej OXC Modyfikacje mechanizmu routingu i konfiguracji LSP tak aby były one dynamicznie budowane Implementacja routera GMPLS Router GMPLS zawiera: OXC, która reprezentuje płaszczyznę danych Moduł płaszczyzny sterowania ASON/GMPLS, który steruje i nadzoruje OXC, komunikuje się z innymi węzłami Rysunek 4: Model węzła GMPLS Każdy router GMPLS zawiera szereg modułów, które współpracują ze sobą. Architekturę routera najlepiej obrazuje jej opis w postaci skryptu w pliku NED, przedstawionym na listingu 1 oraz jego wizualizacji pokazanej na rysunku 4. Listing 1. Implementacja węzła GMPLS module GmplsNode { parameters: @display("b=420,387;bgb=424,384"); int rposx; int rposy; int numofwaves; int numofports; string routingfile; int hosts; string routerid; gates: input fromgenerator[]; input inputfibers[]; output outputfibers[]; input controlin[]; output controlout[]; input inputlightpaths[]; //Number of incoming ports output outputlightpaths[]; //Number of outgoing ports inout ethg[];

submodules: control: GMPLS_Control { parameters: @display("i=block/buffer2_l; p=337,282"); numofinterfaces = sizeof(inputfibers); routerid = routerid; routingfile = routingfile; gates: inputlightpaths[sizeof(inputfibers)]; outputlightpaths[sizeof(outputfibers)]; phy: PhyConnections { parameters: @display("i=block/buffer2_l;p=337,188;b=90,68"); numofwaves = numofwaves; numofports = numofports; gates: portsinput[numofports]; portsoutput[numofports]; inputfibers[sizeof(inputfibers)]; outputfibers[sizeof(outputfibers)]; virt: GMPLS_LSR { parameters: @display("i=block/buffer2_l;p=337,88;t=virt"); numofinterfaces = numofports; routingfile = routingfile; routerid = routerid; gates: ethg[hosts]; inputlightpaths[numofports]; outputlightpaths[numofports]; setup: SetUpHandler { parameters: @display("i=block/control_l;p=208,122"); gates: fromgenerator[hosts]; connections allowunconnected: for i=0..sizeof(inputfibers)-1 { inputfibers[i] --> phy.inputfibers[i]; outputfibers[i] <-- phy.outputfibers[i]; for i=0..sizeof(inputfibers)-1 { controlin[i] --> control.inputlightpaths[i]; controlout[i] <-- control.outputlightpaths[i]; // these connections will be automatically created at runtime for i=0..(numofports)-1 { phy.portsoutput[i] --> Wavelength --> virt.inputlightpaths[i]; phy.portsinput[i] <-- Wavelength <-- virt.outputlightpaths[i]; //display "o=blue"; for i=0..(hosts)-1 { ethg[i] <--> virt.ethg[i]; fromgenerator[i] --> setup.fromgenerator[i]; Najważniejsze parametry węzła GMPLS to: rposx, rposy określają pozycję węzła w diagramie wizualizującym modelach

numofports, numofwaves określają optyczne właściwości węzła routerid określa adres IP węzła identyfikujący węzeł w sieci. Węzeł składa się ponadto z kilku modułów, z których najważniejsze to GMPLS_LSR, PhyConnections oraz GMPLS_Control. Moduł PhyConnections Moduł PhyConnections, przedstawiony na listingu 2 jest implementacją przełącznika optycznego OXC (Optical Cross-Connect), który jest w pełni sterowany przez płaszczyznę sterowania węzła GMPLS. Listing 2. Moduł PhyConnections module PhyConnections { parameters: @display("b=494,318"); int numofwaves; int numofports; gates: input inputfibers[]; //fibers from other network nodes output outputfibers[]; //fibers to other network nodes input portsinput[]; //connections from ports output portsoutput[]; //connections to ports submodules: wdm[sizeof(inputfibers)]: WDM { parameters: @display("i=block/queue"); gates: inwavelengths[numofwaves]; outwavelengths[numofwaves]; connections allowunconnected: for i=0..sizeof(inputfibers)-1 { inputfibers[i] --> { @display("o=blue"); --> wdm[i].fromfiber; outputfibers[i] <-- { @display("o=blue"); <-- wdm[i].tofiber; Najbardziej istotne parametry to: numofports definiuje liczbę portów między warstwą optyczną a warstwą elektroniczną IP/MPLS numofwaves definiuje liczbę długości fal jakie są obsługiwane w danym włóknie Submoduł WDM implementuje podział włókna światłowodowego na długości fal. Listing 3. Moduł WDM

simple WDM { gates: input fromfiber; output tofiber; input inwavelengths[]; output outwavelengths[]; Moduł GMPLS_Control Jest to implementacja płaszczyzny sterowania węzła ASON/GMPLS. Został on przedstawiony na rysunku 5. Łatwo zauważyć, że jest on bardzo podobna do węzła MPLS znanego z INET (rysunek 2). Kluczowe moduły zostały jednak na nowo zaimplementowane tak aby wspierały zestaw protokołów GMPLS CtrOSPFRouting Rysunek 5: Model GMPLS_Control Moduł ten implmenetuje protokół routingu stanu łącza. Oparty jest na OSPF z INET Framework. Na listingu 4 przedstawiono jego implementację w języku NED. Jego konfiguracja jest analogiczna ze standardową konfiguracją OSPF w INET. Listing 4. Moduł CtrlOSPFRouting

simple CtrlOSPFRouting { parameters: xml ospfconfig; // xml containing the full OSPF AS configuration string ospfconfigfile; // xml file containing the full OSPF AS configuration // default values for attributes of interface xml entries: int hellointerval @unit(s) = default(10s); int pollinterval @unit(s) = default(120s); int routerdeadinterval @unit(s) = default(40s); int retransmissioninterval @unit(s) = default(5s); int interfaceoutputcost = default(1); int interfacetransmissiondelay = default(1); int routerpriority = default(1); string authenticationtype = default("nulltype"); // SimplePasswordType CrytographicType NullType string authenticationkey = default("0x00"); // 0xnn..nn int linkcost = default(1); bool RFC1583Compatible = default(false); string areaid = default(""); int externalinterfaceoutputcost = default(1); string externalinterfaceoutputtype = default(""); // Type1 Type2 @display("i=block/network2"); gates: input ipin @labels(ipv4controlinfo/up); output ipout @labels(ipv4controlinfo/down); CtrlRSVP Moduł ten implmenetuje protokół RSVP używany jako protokół konfiguracyjny w ASON/GMPLS. Jest odpowiedzialny na zestawianie i usuwanie połączeń optycznych. Jest oparty o moduł RSVP pakietu INET Framework. Jego implementacja w języku NED jest pokazana na listingu 5. Na uwagę zasługują dwa parametry: hellointerval określa z jaką częstotliwością węzeł ma wysyłać komnikaty RSVPHello do węzłów sąsiednich w celu odświeżenia statusu Hello. HelloTimeout określa po jakim czasie po braku komunikatów RSVPHello węzeł ma traktować węzeł jako nieaktywny W przeciwieństwie do standardowego RSVP w pakiecie INET w implementacji dla GMPLS parametry traffic i peers nie są wymagane gdyż węzeł jest w stanie budować bazę danych sesji w oparciu o zestawiane połączenia (traffic) a listę sąsiadów buduje w oparciu o mechanizm odkrywania sieci (peers). Listing 5.

simple CtrlRSVP { parameters: //xml traffic = default(xml("<sessions/>")); // specifies paths to set up //string peers; // names of the interfaces towards RSVP peers double hellointerval @unit(s); double hellotimeout @unit(s); @display("i=block/control"); gates: input from_ip; output to_ip; input from_mpls_switch; input from_app; CtrlTED Moduł ten implmenetuje bazę danych o stanie sieci (Traffic Engineering Database) dla ASON/GMPLS. Moduł ten współpracuje z modułem routingu oraz modułem RSVP. CtrlLIBTable Moduł ten implmenetuje tabelę informacji o etykietach używanych przez dany węzeł (Label Information Base Table ) dla ASON/GMPLS. Moduł RSVP przechowuje w niej operacje na etykietach które są używane w węźle (swap, puch, pop). Ponowanie, w przeciwieństwie do standardowej implementacji w INET Framework moduł buduje bazę w oparciu o informacje z komnukatów sygnalizacyjnych i dane nie są statycznie ładowane na początku symulcji.

CtrlSimpleClassifier Moduł oparty o SimpleClassifier z modułu INET. Różnica polega na dynamicznej aktualizacji stanu w trakcie wykonywania symulacji zamiast użycia konfiguracyjnego pliku XML. OXCVirtualIf Moduł interfejsu routera ASON/GMPLS. Jest on zbliżony implementacyjnie do modułu PPP. Odpowiedzialny za komunikację między routerem a warstwą fizyczną. Jego kod został przedstawiony na listingu 6. Listing 6. Impmenetacja modułu interfejsu ASON/GMPLS module OXCVirtualIf { parameters: string queuetype; gates: input physin; output physout; input netwin; output netwout; submodules: queue: <queuetype> like IOutputQueue { parameters: @display("i=block/queue;p=60,85;q=l2queue"); oxc: OXCVirtual {

parameters: queuemodule = "queue"; txqueuelimit = 1; // queue sends one packet at a time @display("i=block/rxtx;p=88,165"); connections: netwin --> queue.in; // display "m=n"; queue.out --> oxc.netwin; netwout <-- oxc.netwout;// display "m=n"; physin --> { @display("t=m-s"); --> oxc.physin; physout <-- { @display("t=m-s"); <-- oxc.physout; simple OXCVirtual { parameters: double txqueuelimit; //only used if queuemodule==""; zero means infinite string queuemodule; //name of external (QoS,RED,etc) queue module gates: input physin; output physout; input netwin; output netwout; LinkResourceManager Jest to najprawdopodobniej najważniejszy moduł węzła ASON/GMPLS. Odpowiedzialny jest za alokację z zwalnienia zasobów warswy transportowej oraz dystrybuowanie informacji o nich. Moduł nie posiada żadnych szczególnych parametrów konfiguracyjnych na poziomie NED stąd zostanie omówiony w szczegółach w rozdziale dotyczącym implementacji C++. Moduł GMPLS_LSR Moduł implementuje warstwę elektroniczną routera ASON/GMPLS. Jego model został przedstawiony na ryskunku 6. Budowa modułu jest bardzo zbliżona do modułu GMPLS_Control oraz typowego modułu IP/MPLS pakietu INET Framework.

Rysunek 6: Model GMPLS_LSR GOSPFRouting, Jest to moduł bardzo zbliżony do standardowego OSPFRouting znanego z modułu IP/MPLS GRSVP, GTED, GLIBTable, GSimpleClassifier Moduły analogiczne do swoich odpowiedników w module GMPLS_Control ConnectionController Jest to moduł który wyróżnia GMPLS_LSR od GMPLS_Control. Implementuje on kontroler połączeń dla ASON/GMPLS i odpowiedzialny jest za zarządzanie (zestawianie i zwalnianie) połączeń na poziomie warstwy IP/MPLS. Współpracuje w modułem LinkResourceManager (LRM) modułu GMPLS_Control. Podobnie jak LRM nie zawiera parametrów konfiguracyjnych.

Szczegóły implementacji modułów w C++ Na rysunku 7 przedstawiono hierarchię klas środowiska Omnet++ i umiejscowienie kluczowych dla implementacji modułów klas cmodule oraz csimplemodule. Rysunek 7: Hierarchia klas modułu Omnet++ [Omnet++ API] csimplemodule jest klasą bazową wszystkich prostych modułów. Najważniejszymi metodami tej klasy są: void initialize() - wywoływana przy tworzeniu modułu void handlemessage(cmessage *msg) wywoływana kiedy moduł otrzymuje komunikat void finish() - wywoływany po zakończeniu symulacji StatisticsCollector Klasa implemnetowana jako rozszerzenie csimplemodule. Odpowiedzialna za zbieranie statystyk. ConnGenerator Klasa odpowiedzialna za generowanie żądań zestawienia połączenia. Diagram UML został przedstawiony na rysunku 8. najważniejsze pola to: numofnodes ilość węzłów w sieci. callcounter ilość żądań do wywołania

htime, iatime parametry odpowiedzialne na częstotliowość generowania żądań stats wskaźnik na StatisticCollector SetUpHandler Jest modułem znajdującym się w każdym węźle. Najważniejszymi atrybutami są cc wskaźnik do ConnectionController, lrm wskaźnik do LinkResourceManager, olsp wektor obiektów Lightpath, które zostały stworzone, stats wskaźnik do StatisticCollector. LinkResourceManager Rysunek 8: Diagram UML klasy ConnGenerator Moduł odpowiada za synchronizację procesu zestawiania i usuwania połączeń w warstwie optycznej. Diagram UML został przedstawiony na rysunku 9. Najważniejsze atrybuty to ift, localrsvp, ted, które są wskaźnikami do kluczowych modułów związanych z sygnalizacją InterfaceTable, RSVP, TED. Najważniejsze metody: findtoroute() - zwraca ścieżkę do określonego przeznaczenia wywoływane przez SetUpHandler findfreeport(), findfreewavelenght() - zwraca dostępne zasoby createlp(), deletelp() - tworzy lub usuwa Lightpath notifyendofcreation(), notifyendofteardown() setopticalswitching(), unsetopticalswitching() setelectronicswitching()

Rysunek 9: Diagram UML klasy LinkResourceManager ConnectionController Moduł odgrywa podobną rolę w GMPLS_LSP co LinkResourceManager w GMPLS_Control. Odpowiada za synchronizację procesu zestawiania i usuwania połączeń LSP w warstwie IP/MPLS. Diagram UML został przedstawiony na rysunku 9. Najważniejsze atrybuty to ift, localrsvp, ted, które podobnie jak w przypadku LinkResoirceManager są wskaźnikami do modułów InterfaceTable, RSVP oraz TED. Ponadto zawiera lspvector, który przechowuje informacje na temat LSP utworzonych w przez dany węzeł. CtrlOSPFRouting, GOSPFRouting Są to klasy implementujące protokół stanu łącza dla GMPLS_Control oraz GMPLS_LSP. Diagram UML dla CtrlOSPFRouting został przedstawiony na rysunku 10.

CtrlRSVP, GRSVP Klasy te implementują protokół RSVP rozszerzając implementację z pakietu INET Framework, dodając m.in. metody: addpath(), removepath() - inicjuje tworzenie i usuwanie ścieżek (długości fal w przypadku GMPLS_Control i LSP w przypadku GMPLS_LSP addnewpeer(), removepeer() - tworzą struktury RSVP jeśli nowy peer jest osiągalny w warstwie fizycznej. CrtlLIBTable Rysunek 10: Diagram UML dla klasy CtrlOSPFRouting Moduł zawiera informacje o etykietach użytych w danym węźle. Etykiety mają uogólniony format tak aby wspierać różne typy przełączania.

Synchronizacja międzywarstowowa Polityki MTE W symulatorze zaimplementowano dwie strategie międzywarstwowej inżynierii ruchu (Multilayer Traffic Engineering): PT-First (Physical Topology First) jeśli istnieje możliwość realizacji bezpośredniego połączenia w warstwie fizyczbej to jest ono realizowane, jeśli nie następuje próba znalezienia połączenia wirtualnego taka strategia jest często nazywana bottom-up VT-First (Virtual Topology First) w pierwszej kolejności jest próba znalezienia ścieżki w warstwach wyższych (wirtualnych) jeśli takowe nie istnieje następuje utworzenie połączenia w warstwie fizycznej strategia jest często nazywana up-down. Symulacje Narzędzie symulacyjne pozwoliło wykonać serię symulacji sieci wielowarstwowej i analizę wpływu przyjętej strategii na wydajność mechanizmów sieci oraz wykorzystanie zasobów.

Topologie Topologie użyte w badaniach symulacyjnych zostały przedstawione na rysunkach 11-14. Parametry topologii zostały przedstawione w tabeli Rysunek 11: Topologia testowa Rysunek 12: Topologia NSF Rysunek 13: Topologia Italy

Rysunek 14: Topologia Europa Topologia Liczba węzłów Liczba połączeń testowa 7 11 NSF 14 21 Italy 21 33 Europe 28 41 Do generowania obciążenia sieci został użyty generator opisany w poprzednim rozdziale. Generował on połączenia pomiędzy losowo wybranymi węzłami zgodnie z rozkładem Poissona. Średni czas między generowanymi żądaniami zestawienia połączenia jest określony przez parametr T ia, a średni czas połączenia wynosi T hold. Ruch oferowany wyrażony w Erlangach (Elr) przez dany węzeł jest zatem określony przez T hold / T ia * B a /C, gdzie B a jest średnią przepływnością połączenia a C pojemością pojedynczego łącza. W trakcie symulacji przyjęto następujące zełożenia: Liczba połączeń: 50000 Pojemność łącza: 10 Gb/s (co odpowiada przepływności OC-192) Średnia przepływność zestawianego połączenia B a : 1.65Gb/s 40% połączeń 1Gb/s (przepływność OC-24)

40% połączeń 2Gb/s (przepływność OC-48) 10% połączeń 3Gb/s opóźnienie propagacji: 0,33ms/100km opóźnienie przetwarzania IP: 10μs/węzeł Ruch oferowany: ok. 140 Erl Rysunek 15 przedstawia średni czas zestawiania połączenia dla poszczególnych topologii przy zastosowaniu strategii PT-First oraz VT-First. Jak można zauważyć czas potrzebny na zestawienie połączenia jest większy dla sieci zawierających więcej węzłów i jest nieznacznie większy dla strategii VT-First i różnica ta jest większa dla większych sieci. Rysunek 15: Średni czas zestawienia połączenia Następne symulacje pozwoliły przeprowadzić badania wpływu przyjętej strategii na liczbę ścieżek LSP i łączy Lightpath. Rysunek 16: Średnia długość ścieżki w warstwie fizycznej

Rysunek 17: Średnia długość ścieżki w warstwie IP Kolejny eksperyment związany był badaniem wpływu strategii na prawodpodobnieństwo blokady przy różnych obciążeniach ruchem. 5. Modelowanie ASON/GMPLS w środowisku ns-2 Jak wspomniano brak obecnie narzędzia które umożliwiałoby w sposób zadowalający symulacje sieci GMPLS i jej mechanizmów. Modelowanie takie uniemożliwia to ilościową analizę sieci tego typu. Zaproponowano zatem środowisko Network Simulator (ns-2) jako takie, które w sposób względnie prosty umożliwi implementacje mechanizmów specyficznych dla GMPLS. W rozdziale przedstawiono także prostą symulację demonstrującą proces realizacji LSP w sieci z odseparowanymi płaszczyznami. Ns-2 jest symulatorem zdarzeń dyskretnych przystosowanym do modelowania sieci komputerowych udostępnianym na zasadach open source. Środowisko umożliwia modelowanie wielu znanych technologii. W obecnej wersji srodowisko zawiera MNS (MPLS Network Symulator) - moduł obsługujacy wybrane mechanizmy MPLS m.in. protokół dystrybucji etykiet LDP (Label Distribution

Protocol) i CD-LDP (Constraint- Routing Label Distribution Protocol). Jako moduł dodatkowy dostępną jest również implementacja protokołu sygnalizacyjnego RSVP-TE dla NS-2. W dalszej części tego podrozdziału przedstawione zostaną modyfikacje środowiska ns-2 niezbędne do modelowania sieci GMPLS. W pierwszej kolejności postanowiono uruchomić wsparcie obsługi dostępnej implementacji MPLS z protokołami sygnalizacyjnymi dla rozdzielonych fizycznie płaszczyzn transportowej i sterowania. W tym celu węzeł GMPLS został rozdzielony na dwie skojarzone ze sobą, funkcjonalne części (rysunek 18): moduł przełączający, którego role pełni węzeł MPLS (w przyszłosci zostanie on zastąpiony węzłem GMPLS), moduł sterujący, którego role pełni węzeł IP - router. Połączone węzły MPLS stanowią sieć płaszczyzny transportowej, natomiast połączone węzły sieci IP tworza siec płaszczyzny sterowania. Każdy węzeł MPLS posiada powiązanie z odpowiadającym mu węzłem IP, który pełni role sterującą. W rzeczywistych warunkach moduły beda zazwyczaj jednym urządzaniem. W celu wsparcia architektury, w której płaszczyzna danych jest odseparowana od płaszczyzny sterowania zostały dokonane pewne modyfikacje implementacji protokołów sygnalizacyjnych MPLS oraz protokołu routingu. Ze względu na to, iż preferowanym protokołem sygnalizacyjnym w GMPLS jest RSVP, właśnie ten protokół wybrano do realizacji sterowania w opisywanym symulatorze. W przyszłości planuje się stosowne modyfikacje w istniejacej implementacji LDP modułu MNS tak, by możliwe były analizy porównawcze obu protokołów. Głównym elementem implementacji protokołu RSVP jest obiekt klasy RSVPAgent. Ponieważ wiadomości sygnalizacyjne przesyłane miedzy obiektami tego typu mają być transportowane przez siec płaszczyzny sterowania zostały one przypisane do węzłów IP (modułów sterujących węzła GMPLS). Obiekt RSVPAgent posiada powiązanie z węzłem MPLS (modułem przełączającym GMPLS), do którego przekazuje dane pozwalające modyfikować jego tablice etykiet co jest jednoznaczne z tworzeniem, usuwaniem czy modyfikowaniem scieżek LSP (Label Switched Path). Przykładowo, jesli ustanawiana jest nowa ścieżka węzeł brzegowy domeny GMPLS zleca swojemu agentowi RSVP (zlokalizowanemu w powiązanym z nim węźle IP) zestawienie ścieżki LSP do odpowiedniego węzła przeznaczenia. Ten, korzystając z informacji w tablicach routingu modułu przełączającego oraz modułu sterującego, wysyła komunikat PATH do węzła w płaszczyźnie sterowania skojarzonego z wybranym węzłem w płaszczyźnie transportowej. Należy zauważyć, że ze względu na separacje obu płaszczyzn, komunikat taki może być przesyłany dowolną ścieżkę wynikającą z użytej topologii w płaszczyźnie sterowania, oraz użytych mechanizmów routingu. RSVPAgent analizując otrzymany komunikat PATH zapisuje dane dotyczące nowo tworzonej ścieżki LSP w swojej wewnętrznej bazie danych, a następnie w oparciu o tablice routingu przesyła wiadomość do kolejnych węzłów. Węzeł docelowy po otrzymaniu komunikatu PATH wysyła komunikat RESV, który przechodząc przez ścieżkę wyznaczona przez komunikat PATH dokonuje rezerwacji zasobów i ustawienia etykiet na poszczególnych węzłach. Węzeł sterujący odebrawszy komunikat RESV operuje zarówno na swojej wewnętrznej bazie zapisując w niej dane dotyczące zestawianej ścieżki jak i na tablicach wezła MPLS m.in.

ustawiajże etykiety używane podczas przełączania oraz modyfikując wpisy w tablicy routingu. Jak wspomniano wcześniej dla poprawnego funkcjonowania sieci niezbędne jest uruchomienie routingu w obu płaszczyznach. Płaszczyzna transportowa powinna przenosić jednak wyłącznie dane użytkowników, a cały ruch związany z sygnalizacja musi byc przenoszony przez płaszczyznę sterowania. Dokonano zatem niezbędnych modyfikacji protokołu routingu typu stanu łacza, dostępnego w środowisku ns-2, Umożliwiły one przesyłanie wiadomości routingowych płaszczyzny danych za pośrednictwem modułu sterujacego czyli przez siec płaszczyzny sterowania. Obiekt klasy rtprotols, odpowiedzialny za rozgłaszanie informacji routingowej, zlokalizowany w wezle MPLS używa do wysyłania uaktualnien obiektu rtprotols zlokalizowanego w odpowiadajżcym mu wezle IP. Rysunek 18: Model węzła GMPLS w środowisku ns-2 Mechanizmy zaimplementowane w środowisku ns-2 Zaimplementowane w ns-2 mechanizmy wspierają działanie sieci w z fizycznie rozłaczną płaszczyzną sterowania i obejmują tworzenie powiązanych wezłów MPLS i IP, zestawianie, modyfikowanie i usuwanie LSP, oraz zestawianie ścieżek zapasowych. Jak wspomniano węzeł ASON/GMPLS tworzony jest przez dwa węzły związane sa ze sobą relacjami przynależności węzła MPLS w płaszczyźnie danych oraz węzła IP w płaszczyźnie sterowania. Sieć tworząca płaszczyznę danych może być przy tym włączona do tradycyjnej sieci IP.

Ścieżki LSP mogą być tworzone zarówno w oparciu o tablice routingu jak i poprzez ręczne wskazanie węzłów, przez które dana ścieżka ma przebiegać. W pierwszym przypadku wybór ścieżki następuje w oparciu o zawartość tablicy routingu w module płaszczyzny danych. Dzięki zastosowaniu protokołu routingu typu linkstate oraz mechanizmom in#ynierii ruchu, algorytmy wyznaczania ścieżek uwzględniają aktualny stan rezerwacji pasma w poszczególnych łączach. W przypadku recznego wskazywania scieżki jako parametr podawana jest lista wezłów płaszczyzny danych, przez które przebiegać ma ścieżka LSP. Możliwe jest przy tym ustanawianie ścieżki zarówno w przypadku architektury symetrycznej jak i asymetrycznej. Zaimplementowane mechanizmy protekcji obejmują kilka typów reroutingu ścieżki: oparty o wyznaczanie tras na podstawie tablic routingu, oparty o ręczne określanie ścieżek. W obu przypadkach możliwe jest zastosowanie protekcji pre-kalkulowanej, gdzie scieżka jest wyznaczona, ale zasoby nie są rezerwowane, jak i pre-alokowanej, gdzie ścieżka zapasowa jest wcześniej ustanowiona a zasoby rezerwowane. W przypadku protekcji opartej o routing możliwe jest ponadto obliczenie trasy dopiero w momencie stwierdzenia uszkodzenia. W płaszczyźnie sterowania protekcja jest realizowana przez klasyczne mechanizmy reroutingu IP. Zaimplementowano także mechanizm detekcji awarii w płaszczyźnie sterowania z wykorzystaniem komunikatu HELLO. Separacja płaszczyzn wymaga również przeniesienia ruchu sygnalizacyjnego protokołów routingu. Implementacja protokołu LS (stanu łącza) została rozszerzona o mechanizm wykrywania separacji płaszczyzn i przesyłania informacji routingu płaszczyzna sterowania.