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 Rzeszowieprozycki@wsiz.rzeszow.pl

W pracy przedstawiono koncepcje modelowania sieci GMPLS/ASON, założeniaimplementacji modelu oraz przykłady implementacji w popularnych środowiskach Omnet++oraz ns-2.

1. Wprowadzenie

Coraz powszechniejszy szerokopasmowy dostep do sieci globalnej powoduje corazdynamiczny rozwój technologii i usług internetowych takich jak VoIP czy VideoOn-Demandpowoduje, że udział ruchu IP w całkowitym ruchu ciagle rosnie. Jednoczesnie usługi tewymagaja coraz to wiekszych predkosci transmisji przy zachowaniu wysokiej jakosciszczególnie, jesli chodzi o małe czasy opóznien i duża niezawodnosc. Ten drugi parametr jestszczególnie istotny na przykład przy pewnych zastosowanych w medycynie.

Współczesne sieci szkieletowe, oparte w głównie na technologii SDH/WDM, projektowanebyły głównie do obsługi ruchu telefonicznego, co powoduje, że realizacja usług IP naodpowiednim QoS wymusza stosowanie czesto skomplikowanego i zasobożernego, a przez tokosztownego przesyłania tegoż ruchu za posrednictwem nawet kilku protokołów i technologiiposrednich. Typowe sieci do transmisji danych maja budowe czterowarstwowa. Warstwa IPdla 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 wielowarstwowaarchitektura powoduje, że zarzadzanie nią, a w szczególnosci realizacja nowoczesnych usługna żadanie staje sie bardzo trudna.

Odpowiedzia na te problemy jest koncepcja sieci opartych na zasadzie integracji różnychtechnik przełaczania, łaczac w sobie zalety możliwosci użycia wielu warstw (tzw. stosuprotokołów) a w raz z nimi niektórych ich mechanizmów (np. odtworzenie ruchu poniżej 50ms w sieciach SDH) z możliwoscia zarzadzania wspólnego zintegrowanego mechanizmusterowania. Koncepcje taka prezentuje z jednej strony srodowisko zwiazane z IETF czegoefektem jest stworzenie wstepnych wersji specyfikacji dla sieci GMPLS (GeneralizedMultiprotocol Label Switching), z drugiej rozwijana przez Miedzynarodowa UnieTelekomunikacyjna (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ępnejgeneracji”.Projekt współfinansowany ze środków Unii Europejskiej z Europejskiego Funduszu Rozwoju Regionalnego oraz z budżetu Państwa wramach Regionalnego Programu Operacyjnego Województwa Podkarpackiego na lata 2007 – 2013. Inwestujemy w rozwójwojewództwa podkarpackiego.

której jako jedna z możliwych opcji, podaje się zastosowanie mechanizmów sterowaniatakich jak w sieci GMPLS.

Działanie sieci GMPLS opiera sie na przeniesieniu koncepcji przełaczania etykiet znanej zsieci MPLS na inne warstwy sieci transportowej takie od przełaczania przestrzennego napoziomie łaczy swiatłowodowych, poprzez przełaczenie długosci fali na poziomiezwielokrotnienia falowego WDM, przełaczenie w systemach o zwielokrotnieniu czasu TDMpo przełaczenie pakietów. W przypadku warstw niższych role etykiet pełnia tu konkretnezasoby takie jak długosc fali czy szczelina czasowa, a nie abstrakcyjny numer jak wprzypadku klasycznego MPLS. W celu lepszej skalowalnosci i efektywnosci siec podzielonona 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óbautomatyczny beda realizowane usługi (np. zestawianie i usuwanie połaczen);

• płaszczyzne zarzadzania pełniaca role nadzorcza – ta płaszczyzna nie jest brana poduwage w specyfikacjach GMPLS ale w komercyjnych zastosowaniach bedzieodgrywała bardzo istotna role zwiazana z realizacja strategii funkcjonowania sieci(policy).

Nad efektywnym wykorzystaniem zasobów oraz sposobem realizacji usług czuwac marozproszony mechanizm oparty o znane z MPLS, rozszerzone o nowe własciwosci, protokołydystrybucji etykiet takie jak RSVP-TE, CR-LDP , protokoły routingu IS-IS, OSPF oraz nowyprotokół zarzadzajacy kanałami sygnalizacyjnymi LMP (Link Management Protocol).

2. Architektura sieci ASON/GMPLS

Kluczowa role w funkcjonowaniu GMPLS odgrywa płaszczyzna sterowania. Jej mechanizmyodpowiedzialne sa m.in. za automatyczne zestawianie i usuwanie połaczen - tzw. LSP (LabelSwitched Path) - oraz zarzadzanie zasobami sieciowymi. Do tych celów używane sa znane zMPLS 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żnaod 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 wirtualnegoVCC w sieci ATM. W tym przypadku mówimy o sygnalizacji in-fiber. Możliwe jest jednakużycie kanałów niezależnych, odseparowanych fizycznie od płaszczyzny danych np. poprzezwydzielenie dedykowanego łacza miedzy poszczególnymi wezłami. W tym przypadkumówimy o sygnalizacji typu out-of-fiber. Realizacja kanałów tego drugiego typu pozwala natworzenie całkowicie lub czesciowo fizycznie odseparowanych od siebie sieci: siecipłaszczyzny sterowania oraz sieci płaszczyzny danych. W przypadku gdy topologiepłaszczyzn sa takie same (np. w przypadku realizacji sieci typu in-fiber) mówimy osymetrycznej architekturzepłaszczyzn. W przeciwnym wypadku mamy do czynienia zarchitektura asymetryczna. Należy pamietac, że w przypadku komercyjnych zastosowanspecyfikacja 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 bycniezależna od pozostałych.

W przypadku architektury niesymetrycznej wezły połaczone bezposrednio w płaszczyzniedanych moga nie miec bezposredniego połaczenia w płaszczyznie sterowania, podobnie jakmoga 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łówsygnalizacyjnych 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 czymechanizmów identyfikacji sasiadów. Zastosowanie architektury asymetrycznej, a przedewszystkim sygnalizacji outof-fiber może miec jednak wiele zalet, zwłaszcza w obszarzezapewniania niezawodnosci sieci. Sygnalizacja tego typu może także znacznie uproscicpraktyczna implementacje sieci w przypadku gdy mamy do czynienia z systemami w którychwydzielenie pakietów IP jest szczególnie trudne lub kosztowne. Przykładem tutaj sakrosownice optyczne OXC (Optical Cross-Connect) które działaja na poziomie przełaczaniadługosci fali lub nawet całych sygnałów swiatłowodowych. W tym przypadku procesprzeł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 symulatoraASON/GMPLS, który jest głównym przedmiotem pracy. W pierwszej części przedstawionejest środowisko symulacji OMNeT++, następnie framework INET dla OMNeT ++ gdziezostanie szczegółowo opisana architektura modułu routera MPLS będącego podstawąimplementacji modułu ASON/GMPLS. W kolejnych rozdziałach przedstawiony zostaniemodel sieci utworzony w środowisku ns-2.

4. Modelowanie w środowisku Omnet++

Omnet++ jest modułowym symulatorem zdarzeń dyskretnych używanym głównie domodelowania 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żonejstruktury. Moduły komunikują się przy pomocy komunikatów, które mogą mieć dowolniezł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 dodostosowania modułu jego zachowanie i parametryzacji topologii modelu. Modułynajniższego poziomu kodowanie w języku C++ implementują atomowe elementysymulowanego systemu/sieci i mogą być łączone w większe struktury.

OMNeT ++ zapewnia wydajne narzędzia, pozwalające opisać strukturę system. Głównymicechami 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 bibliotekdostępnych w Omnet++, mogą być łączne w większe moduły będące bardziej złożonymielementami modelu.Struktura modułu jest opisywana w skojarzonym z nim pliku NED (Network ElementDescriptor). Tworząc model sieci korzystamy z tak utworzonych deskryptorów w celuzamodelowania dowolnie złożonych struktur.Moduły mogą mieć zdefiniowane parametry, którym wartości można ustwiać na poziomiepliku 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ędzymoduł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 bramkiwejś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 errorrate

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łaminapisanymi 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 ładowanepodczas uruchamiania symulacji, co pozwala zwiększyć możliwości konfiguracyjne podczasprzeprowadzania różnych scenariuszy.W wyniku otrzymujemy plik wykonywalny który podczas uruchamiania pobiera parametrysieci 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ą wybranychprotokołów i aplikacji takich jak IPv4, IPv6, TCP, UDP, PPP, czy RSVP.

Jako przykład implementacji modelu w INET posłuży MPLS, który został w niniejszej pracyużyty jako podstawa implementacji modelu sieci ASON/GMPLS oraz przykładowu modelzałączony do INET (Rysunek 1). Zawiera on kilka połączonych węzłów MPLS o nazwachLSR, do których dołączono urządzenia końcowe host1 do host5. Z punktu widzenia niniejszejpracy 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ływyższych warstw czyli routing i sygnalizacja (RSVP w tym przypadku choć Omnet++implementuje także LDP) poprzez warstwę sieciową reprezentowaną przez moduł

Rysunek 1: Model sieci MPLS ze środowiska Omnet++

Rysunek 2: Implementacja węzła MPLS

NetworkLayer po warstwę łącza danych reprezentowaną przez moduł protokołu PPP. Międzytymi ostatnimi modułami umieszczony jest moduł MPLS . Podobnie implementowany jest w INET host, którego model został przedstawiony narysunku 3. Na uwagę zasługuje model tablicy routingu, który jest umieszczony w obu typachwęzła. Tablice routingu mogą być inicjowane statycznie przy pomocy plikówkonfiguracyjnych zawierających ponadto konfigurację interfejsów. Przykladowy plik dlaLSR3 został przedstawiony poniżej.

ifconfig:name: ppp0 inet_addr: 10.1.3.1 MTU: 1500 Metric: 1name: ppp1 inet_addr: 10.1.3.2 MTU: 1500 Metric: 1name: ppp2 inet_addr: 10.1.3.3 MTU: 1500 Metric: 1ifconfigend.

route:10.1.1.1 10.1.1.2 255.255.255.255 H 0 ppp010.1.4.1 10.1.4.3 255.255.255.255 H 0 ppp110.1.7.1 10.1.7.1 255.255.255.255 H 0 ppp2routeend.

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

Ponadto w przypadku modułu MPLS należy skonfigurować ustawienia modułów Classifier,RSVP oraz LIBTable. Jest to realizowane poprzez pliki XML. Przykład plikukonfiguracyjnego 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 tunelemlogicznym 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żnaokreś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>

Rysunek 3: Model hosta w INET Oment++

<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 pakietemopisanym 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 ppp1ma być skierowany na interfejs ppp2 a etykieta ma być z niego usunięta, a pakiet opatrzonyetykietą 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 wieluwarstwach modeli ISO nie zawiera wsparcia dla sieci GMPLS/ASON. Należy zauważyć, żerównież tak potężne narzędzia jak Riverband OPNET nie zawiera implementacji tego typusieci. Ze względu jednak na to, że zarówno Omnet++ jak i biblioteka INET jestogólnodostępna na zasadach open source oraz fakt że INET zawiera już podstawoweimplementacje 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 takaby 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

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 nalistingu 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[];

Rysunek 4: Model węzła GMPLS

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łącznikaoptycznego 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ł onprzedstawiony na rysunku 5. Łatwo zauważyć, że jest on bardzo podobna do węzła MPLSznanego z INET (rysunek 2).

Kluczowe moduły zostały jednak na nowo zaimplementowane tak aby wspierały zestawprotokołów GMPLS

CtrOSPFRouting

Moduł ten implmenetuje protokół routingu stanu łącza. Oparty jest na OSPF z INETFramework. Na listingu 4 przedstawiono jego implementację w języku NED. Jegokonfiguracja jest analogiczna ze standardową konfiguracją OSPF w INET.

Listing 4. Moduł CtrlOSPFRouting

Rysunek 5: Model GMPLS_Control

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 wASON/GMPLS. Jest odpowiedzialny na zestawianie i usuwanie połączeń optycznych. Jestoparty o moduł RSVP pakietu INET Framework. Jego implementacja w języku NED jestpokazana na listingu 5. Na uwagę zasługują dwa parametry:

• helloInterval – określa z jaką częstotliwością węzeł ma wysyłać komnikatyRSVPHello 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ł matraktować węzeł jako nieaktywny

W przeciwieństwie do standardowego RSVP w pakiecie INET w implementacji dla GMPLSparametry traffic i peers nie są wymagane gdyż węzeł jest w stanie budować bazę danychsesji w oparciu o zestawiane połączenia (traffic) a listę sąsiadów buduje w oparciu omechanizm 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) dlaASON/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ł (LabelInformation Base Table ) dla ASON/GMPLS. Moduł RSVP przechowuje w niej operacje naetykietach które są używane w węźle (swap, puch, pop). Ponowanie, w przeciwieństwie dostandardowej implementacji w INET Framework moduł buduje bazę w oparciu o informacje zkomnukató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 aktualizacjistanu 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 jestza alokację z zwalnienia zasobów warswy transportowej oraz dystrybuowanie informacji onich. Moduł nie posiada żadnych szczególnych parametrów konfiguracyjnych na poziomieNED 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łuGMPLS_Control oraz typowego modułu IP/MPLS pakietu INET Framework.

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 kontrolerpołą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ówkonfiguracyjnych.

Rysunek 6: Model GMPLS_LSR

Szczegóły implementacji modułów w C++

Na rysunku 7 przedstawiono hierarchię klas środowiska Omnet++ i umiejscowieniekluczowych dla implementacji modułów klas cModule oraz cSimpleModule.

cSimpleModule jest klasą bazową wszystkich prostych modułów. Najważniejszymi metodamitej klasy są:

void initialize() - wywoływana przy tworzeniu modułuvoid handleMessage(cMessage *msg) – wywoływana kiedy moduł otrzymuje

komunikatvoid finish() - wywoływany po zakończeniu symulacji

StatisticsCollector

Klasa implemnetowana jako rozszerzenie cSimpleModule. Odpowiedzialna za zbieraniestatystyk.

ConnGeneratorKlasa odpowiedzialna za generowanie żądań zestawienia połączenia. Diagram UMLzostał przedstawiony na rysunku 8. najważniejsze pola to:

• numOfNodes – ilość węzłów w sieci.• callCounter – ilość żądań do wywołania

Rysunek 7: Hierarchia klas modułu Omnet++[Omnet++ API]

• 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 doStatisticCollector.

LinkResourceManager

Moduł odpowiada za synchronizację procesu zestawiania i usuwania połączeń w warstwieoptycznej. 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 przezSetUpHandler

• findFreePort(), findFreeWavelenght() - zwraca dostępne zasoby• createLP(), deleteLP() - tworzy lub usuwa Lightpath• notifyEndOfCreation(), notifyEndOfTeardown()• setOpticalSwitching(), unsetOpticalSwitching()• setElectronicSwitching()

Rysunek 8: Diagram UML klasy ConnGenerator

ConnectionController

Moduł odgrywa podobną rolę w GMPLS_LSP co LinkResourceManager w GMPLS_Control.Odpowiada za synchronizację procesu zestawiania i usuwania połączeń LSP w warstwieIP/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 domodułów InterfaceTable, RSVP oraz TED. Ponadto zawiera lspVector, który przechowujeinformacje 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.

Rysunek 9: Diagram UML klasy LinkResourceManager

CtrlRSVP, GRSVP

Klasy te implementują protokół RSVP rozszerzając implementację z pakietu INETFramework, dodając m.in. metody:

• addPath(), removePath() - inicjuje tworzenie i usuwanie ścieżek (długości fal wprzypadku GMPLS_Control i LSP w przypadku GMPLS_LSP

• addNewPeer(), removePeer() - tworzą struktury RSVP jeśli nowy peer jest osiągalnyw warstwie fizycznej.

CrtlLIBTable

Moduł zawiera informacje o etykietach użytych w danym węźle. Etykiety mają uogólnionyformat tak aby wspierać różne typy przełączania.

Rysunek 10: Diagram UML dla klasy CtrlOSPFRouting

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ść realizacjibezpoś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ęstonazywana 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ępujeutworzenie 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.

TopologieTopologie 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

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łademPoissona. Średni czas między generowanymi żądaniami zestawienia połączenia jest określonyprzez parametr Tia, a średni czas połączenia wynosi Thold. Ruch oferowany wyrażony wErlangach (Elr) przez dany węzeł jest zatem określony przez Thold/ Tia * Ba/C, gdzie Ba 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 Ba: 1.65Gb/s

◦ 40% połączeń 1Gb/s (przepływność OC-24)

Rysunek 14: Topologia Europa

◦ 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 topologiiprzy zastosowaniu strategii PT-First oraz VT-First. Jak można zauważyć czas potrzebny nazestawienie połączenia jest większy dla sieci zawierających więcej węzłów i jest nieznaczniewiększy dla strategii VT-First i różnica ta jest większa dla większych sieci.

Następne symulacje pozwoliły przeprowadzić badania wpływu przyjętej strategii na liczbęścieżek LSP i łączy Lightpath.

Rysunek 15: Średni czas zestawienia połączenia

Rysunek 16: Średnia długość ścieżki w warstwie fizycznej

Kolejny eksperyment związany był badaniem wpływu strategii na prawodpodobnieństwoblokady 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ącysymulacje sieci GMPLS i jej mechanizmów. Modelowanie takie uniemożliwia to ilościowąanalizę sieci tego typu. Zaproponowano zatem środowisko Network Simulator (ns-2) jakotakie, które w sposób względnie prosty umożliwi implementacje mechanizmówspecyficznych dla GMPLS. W rozdziale przedstawiono także prostą symulację demonstrującąproces realizacji LSP w sieci z odseparowanymi płaszczyznami. Ns-2 jest symulatoremzdarzeń dyskretnych przystosowanym do modelowania sieci komputerowych udostępnianymna zasadach open source. Środowisko umożliwia modelowanie wielu znanych technologii. Wobecnej wersji srodowisko zawiera MNS (MPLS Network Symulator) - moduł obsługujacywybrane mechanizmy MPLS m.in. protokół dystrybucji etykiet LDP (Label Distribution

Rysunek 17: Średnia długość ścieżki w warstwie IP

Protocol) i CD-LDP (Constraint- Routing Label Distribution Protocol). Jako modułdodatkowy dostępną jest również implementacja protokołu sygnalizacyjnego RSVP-TE dlaNS-2.

W dalszej części tego podrozdziału przedstawione zostaną modyfikacje środowiska ns-2niezbędne do modelowania sieci GMPLS. W pierwszej kolejności postanowiono uruchomićwsparcie obsługi dostępnej implementacji MPLS z protokołami sygnalizacyjnymi dlarozdzielonych fizycznie płaszczyzn transportowej i sterowania. W tym celu węzeł GMPLSzostał 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 onzastą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łysieci IP tworza siec płaszczyzny sterowania. Każdy węzeł MPLS posiada powiązanie zodpowiadającym mu węzłem IP, który pełni role sterującą. W rzeczywistych warunkachmoduły beda zazwyczaj jednym urządzaniem.

W celu wsparcia architektury, w której płaszczyzna danych jest odseparowana od płaszczyznysterowania zostały dokonane pewne modyfikacje implementacji protokołów sygnalizacyjnychMPLS oraz protokołu routingu. Ze względu na to, iż preferowanym protokołemsygnalizacyjnym w GMPLS jest RSVP, właśnie ten protokół wybrano do realizacji sterowaniaw opisywanym symulatorze. W przyszłości planuje się stosowne modyfikacje w istniejacejimplementacji LDP modułu MNS tak, by możliwe były analizy porównawcze obuprotokołów.

Głównym elementem implementacji protokołu RSVP jest obiekt klasy RSVPAgent. Ponieważwiadomości sygnalizacyjne przesyłane miedzy obiektami tego typu mają być transportowaneprzez siec płaszczyzny sterowania zostały one przypisane do węzłów IP (modułówsterują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 modyfikowaniemscież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ązanymz 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łusterującego, wysyła komunikat PATH do węzła w płaszczyźnie sterowania skojarzonego zwybranym węzłem w płaszczyźnie transportowej. Należy zauważyć, że ze względu naseparacje obu płaszczyzn, komunikat taki może być przesyłany dowolną ścieżkę wynikającą zuż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 routinguprzesyła wiadomość do kolejnych węzłów. Węzeł docelowy po otrzymaniu komunikatu PATHwysyła komunikat RESV, który przechodząc przez ścieżkę wyznaczona przez komunikatPATH 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 baziezapisują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 tablicyroutingu.

Jak wspomniano wcześniej dla poprawnego funkcjonowania sieci niezbędne jesturuchomienie 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 bycprzenoszony przez płaszczyznę sterowania. Dokonano zatem niezbędnych modyfikacjiprotokołu routingu typu stanu łacza, dostępnego w środowisku ns-2, Umożliwiły oneprzesyłanie wiadomości routingowych płaszczyzny danych za pośrednictwem modułusterujacego czyli przez siec płaszczyzny sterowania. Obiekt klasy rtProtoLS, odpowiedzialnyza rozgłaszanie informacji routingowej, zlokalizowany w wezle MPLS używa do wysyłaniauaktualnien obiektu rtProtoLS zlokalizowanego w odpowiadajżcym mu wezle IP.

Mechanizmyzaimplementowane 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 wspomnianowęzeł ASON/GMPLS tworzony jest przez dwa węzły związane sa ze sobą relacjamiprzynależności – węzła MPLS w płaszczyźnie danych oraz węzła IP w płaszczyźniesterowania. Sieć tworząca płaszczyznę danych może być przy tym włączona do tradycyjnejsieci IP.

Rysunek 18: Model węzła GMPLS w środowisku ns-2

Ścieżki LSP mogą być tworzone zarówno w oparciu o tablice routingu jak i poprzez ręcznewskazanie 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 wposzczególnych łączach. W przypadku recznego wskazywania scieżki jako parametrpodawana 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 symetrycznejjak 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 jestwyznaczona, ale zasoby nie są rezerwowane, jak i pre-alokowanej, gdzie ścieżka zapasowajest wcześniej ustanowiona a zasoby rezerwowane. W przypadku protekcji opartej o routingmożliwe jest ponadto obliczenie trasy dopiero w momencie stwierdzenia uszkodzenia. Wpłaszczyźnie sterowania protekcja jest realizowana przez klasyczne mechanizmy reroutinguIP. Zaimplementowano także mechanizm detekcji awarii w płaszczyźnie sterowania zwykorzystaniem komunikatu HELLO.

Separacja płaszczyzn wymaga również przeniesienia ruchu sygnalizacyjnego protokołówroutingu. Implementacja protokołu LS (stanu łącza) została rozszerzona o mechanizmwykrywania separacji płaszczyzn i przesyłania informacji routingu płaszczyzna sterowania.