Modelowanie sieci szkieletowych następnej generacji

Modelowanie sieci szkieletowych następnej generacji

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
[email protected]
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 WavelengthDivision 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
name: ppp1
inet_addr: 10.1.3.2 MTU: 1500
name: ppp2
inet_addr: 10.1.3.3 MTU: 1500
ifconfigend.
Metric: 1
Metric: 1
Metric: 1
route:
10.1.1.1
10.1.4.1
10.1.7.1
routeend.
0
0
0
10.1.1.2
10.1.4.3
10.1.7.1
255.255.255.255 H
255.255.255.255 H
255.255.255.255 H
ppp0
ppp1
ppp2
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).
Rysunek 5: Model GMPLS_Control
Kluczowe moduły zostały jednak na nowo zaimplementowane tak aby wspierały zestaw
protokołów GMPLS
CtrOSPFRouting
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
Rysunek 8: Diagram UML klasy ConnGenerator
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
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.
Rysunek 10: Diagram UML dla klasy CtrlOSPFRouting
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
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 1114. 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 Tia, a średni czas połączenia wynosi Thold. Ruch oferowany wyrażony w
Erlangach (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)
•
•
•
◦ 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.