Control of a Network Operation Generator from an OPNET Modeler Environment.
Článek se zabývá propojením simulace v OPNET Modeleru a generátoru síťového provozu (IxChariot), který je ovládán na základě dat extrahovaných ze simulace. Je popsán postup vytváření midddleware vrstvy přenášející data z OPNET do IxChariot.
Control of a Network
Operation Generator from an OPNET Modeler Environment - Abstract
This article concerns
with interfacing OPNET Modeler simulations with a network operation generator.
Data are extracted from the OPNET simulation, and then the network operation
generator (IxChariot) producing data flow into real network is controlled by
these data. Creating a middleware application transmitting data from OPNET to
IxChariot is described.
Keywords: OPNET Modeler, IxChariot, ESYS, API, middleware
Úvod
Tento článek je součástí projektu zaměřeného na vývoj nových možností QoS.
Článek popisuje middleware vrstvu pro propojení síťového simulátoru OPNET
Modeler s generátorem síťového provozu IxChariot.
Na základě dat, získaných simulací v OPNET Modeleru, generuje IxChariot
parametrizovaný datový tok. IxChariot následně sbírá informace o stavu a výkonu
sítě v průběhu vysílání datového toku. Takto je umožněno okamžité
testování teoretických poznatků v praktických podmínkách reálné sítě se
zpětnou vazbou vedoucí zpět do simulátoru.
OPNET Modeler
Simulace
Simulace v OPNET Modeleru zpracovává data, která budou následně použita
k ovládání generátoru síťového provozu. Za účelem vývoje byla umístěna na
pracovní plochu jediná pracovní stanice, jejíž atributy obsahují přidaný
uživatelsky definovaný celočíselný atribut. Tato hodnota reprezentuje data
k ovládání generátoru.
Data jsou transportována vnitřní síťovou architekturou stanice ke speciálnímu
procesu, zapisujícímu data na External System (ESYS) rozhraní. Toto rozhraní
slouží k předávání dat dovnitř a ven ze simulace. [5] Trasa paketů ve
vnitřní architektuře stanice je zobrazena na obr. 1.
Obr. 1 Trasa paketu uvnitř procesů stanice
Mezi procesy na obrázku výše se nachází další proces, který nepatří do
základního vybavení stanice. Jeho název je snmp_manager,
byl vytvořen v rámci jiného projektu a jeho funkcí je generování paketů
(více v [4]).
V atributech tohoto procesu byla vytvořena nová celočíselná proměnná a
byla povýšena na globální atribut stanice. Tato hodnota bude sloužit
k nastavení DSCP a ECN bitů [6] v IP záhlaví paketů vytvářených
generátorem síťového provozu. Rozmezí jejích hodnot je 0 až 255. Význam těchto
hodnot bude vysvětlen později. V průběhu simulace je tato hodnota
přenášena uvnitř paketů generovaných procesem, který byl popsán výše.
Proces esys
Uvnitř procesu esys jsou přijaté
pakety rozbaleny a celočíselná hodnota je načtena. Tato proměnná bude poté
zapsána na ESYS rozhraní a poslána do vnějšího prostředí.
V tomto bodě nastávají lehké komplikace. Podle dokumentace [3] je
v momentě zápisu dat na rozhraní v simulaci vyvolána pauza a řízení
je předáno externí aplikaci ke zpracování dat příchozích ze strany OPNET
Modeleru. Proces, který toto přerušení vyvolal, se v momentě pauzy nachází
v „nepřipraveném“ stavu a v případě příchodu dat z externí aplikace
není schopen tato data zpracovat. Pokud by tedy došlo ke zpětnému zápisu dat na
rozhraní od externí aplikace, budou data ztracena z důvodu blokace procesu
esys.
OPNET Modeler nabízí východisko pro tento problém použitím tzv. „dceřinného
procesu“. Je to druh procesu, který je vyvolán jiným existujícím procesem.
Volající proces může tomuto procesu předat data ke zpracování. Použitím tohoto
mechanizmu je procesu esys poskytnut
dostatečný čas k návratu do stavu „připraven“, kdy je schopen zpracovávat
příchozí data.
Externí aplikace
Struktura
Externí aplikace je kompilována ve formě dynamické knihovny (DLL soubor).
Sestává se ze tří důležitých částí: hlavní funkce s inicializačními
procedurami, tzv. „callback funkce“ ke zpracování dat a funkce komunikující
s API IxChariotu. První dvě zmiňované funkce musejí být exportovány pomocí
prefixů uvedených v ukázce. Export těchto funkcí je zpřístupňuje pro volání
z jádra OPNET Modeleru.
Hlavní funkce
Hlavní funkce obsahuje inicializační procedury kosimulace (simulace
v OPNET Modeleru provázaná s vnějším prostředím). Tyto funkce se
nazývají Esa_Init a Esa_Load. Jejich deklarace se nachází
v hlavičkovém souboru esa.h,
který je třeba připojit ke kódu externí aplikace.
Po dokončení inicializace je potřeba připojit callback funkci ke konkrétnímu
ESYS rozhraní. V ukázce je uvedena funkce realizující toto propojení.
Identifikátor esaHandle je
ukazatel na běžící instanci simulace v OPNET Modeleru. proměnná status slouží k uložení návratového
statusu funkce. Další dva ukazatele představují požadované rozhraní a callback
funkci. Poslední dva argumenty funkce nejsou použity.
Řízení kosimulace se během inicializační fáze nachází na straně externí
aplikace. Po skončení této fáze je nutné předat řízení simulaci v OPNET
Modeleru. Toto předání zajišťuje funkce Esa_Execute_Until
s časovým parametrem ESAC_TIME_MAX.
Tímto je dosaženo předání řízení simulaci po celou dobu jejího trvání.
Callback
p>Funkce callback je propojena s konkrétním ESYS rozhraním. Kdykoli jsou
na toto rozhraní zapsána data, je řízení dočasně předáno externí aplikaci a je
proveden kód uvnitř callback funkce. Po dosažení jejího konce je řízení
navráceno zpět do OPNET Modeleru.
Jako první jsou načtena data z ESYS rozhraní. Daty je myšlena
celočíselná zmiňovaná v předchozí kapitole. Funkce pro načítání dat jsou
zobrazeny v ukázce níže. První funkce vrací ukazatel na požadované
rozhraní, druhá funkce načítá data a ukládá je do lokální proměnné dscp.
V další části callback funkce jsou implementovány funkce pro ovládání
IxChariot API (TCL/C). Tyto funkce budou popsány později.
Po nastavení a spuštění generátoru síťového provozu je dosaženo konce
callback funkce. Požadovaný datový tok byl vygenerován, tudíž pokračování
simulace není žádoucí. Ukončování simulace se sestává ze dvou fází: ukončení
simulace v OPNET Modeleru a ukončení externí aplikace. První fázi
zajišťuje volání speciální funkce Esa_Terminate,
druhou fázi obstarává standardní funkce exit.
Generátor síťového provozu IxChariot
Síťový generátor IxChariot je produktem společnosti IXIA. Disponuje dvěma
API rozhraními umožňujícími jeho komunikaci s ostatními aplikacemi. První
z těchto rozhraní je založeno na programovacím jazyce C, druhé rozhraní
používá funkcí jazyka TCL. [1]
V následující části je proveden rozbor využití obou zmiňovaných rozhraní.
Na závěr jsou výsledky analyzovány a jsou vyvozeny závěry o vhodnosti použití
těchto rozhraní.
TCL API
Pro umožnění ovládání IxChariotu pomocí TCL API je třeba v externí
aplikaci implementovat mechanizmus volání TCL skriptu obsahujícího samotné funkce
rozhraní. Aby toto bylo možné, musí počítač provádějící kosimulaci disponovat
TCL runtime prostředím nazývaným „TCL Shell“. V této kapitole je popsána
struktura a obsah TCL skriptu a mechanizmus volání tohoto skriptu
z externí aplikace.
Na počátku TCL skriptu je třeba načíst potřebné knihovny s funkcemi
rozhraní API. Za tímto účelem jazyk TCL implementuje funkce load a package require. [2]
Po úspěšném načtení knihoven je třeba vytvořit proměnnou pro test (kontext
pro generování datových toků) a pár (definice datového toku). Proměnné testu se
přiřazuje název souboru, čímž je umožněno pozdější uložení na disk.
Po vytvoření proměnné testu lze nastavit i dobu trvání testu. Nejdříve je
nutné načíst nastavení testu do pomocné proměnné pomocí funkce getRunOpts. Následně je nastavena doba
trvání na pevný časový limit je možné zadat požadovaný počet sekund.
Parametry generovaného datového toku se nastavují u proměnné páru. Těmito
parametry jsou IP adresy koncových bodů, komunikační protokol, skript
popisující charakter komunikace (velikost paketů, interval generování paketů
apod.) a nastavení kvality služeb (QoS). Nastavení těchto hodnot prezentuje
ukázka níže. Výraz [lindex $argv X],
kde X znamená číslo v dekadickém
formátu, představuje přístup do argumentů skriptu. Zmiňované číslo slouží
k indexování v rámci vektoru argumentů. Princip předávání argumentů
skriptu bude představen dále.
Nastavení QoS je ovšem poněkud komplikovanější. IxChariot implementuje
externí soubor pro ukládání tzv. „QoS šablon“. Součástí těchto šablon je
unikátní název a maska. Maska obsahuje informace o bitové kombinaci v DSCP
poli uvnitř IP záhlaví generovaných paketů. Tato informace je uložena ve formě
celočíselné proměnné v rozsahu 0 až 255. Konverzí z dekadického do
binárního formátu je odhaleno výsledné nastavení bitů.
Za účelem nastavení daného páru pomocí QoS hodnoty z vektoru argumentů
je nutné vytvořit nejprve novou šablonu. Nicméně funkce newQosTosTemplate, používaná k těmto účelům, hlásí chybu
v případě, že zadaný název šablony již existuje. Pro předcházení tomuto
chování je umístěna tato funkce do argumentů funkce catch. Funkce catch
spouští funkci ve svých argumentech a v případě jejího selhání je chybový
výstup uložen do proměnné err (viz
ukázka) a provádění skriptu pokračuje.
Proměnná err je testována
v podmínce a pokud obsahuje informace o výše zmiňované chybě, je zavolána
další funkce upravující již existující šablonu. Vytvořená/modifikovaná šablona
je poté přiřazena k páru.
Po dokončení nastavení je pár přidružen k testu a test může být spuštěn.
Test je nastaven, aby běžel po určitý časový interval. Skript sehrává roli
dohledu a kontroluje, zdali byl dosažen časový limit a v případě, že test
stále běží, explicitně test ukončí. Funkce isStopped
v ukázce indikuje, jestli test skončil v zadaném časovém úseku.
Funkce stop slouží k násilnému
ukončení testu.
Po skončení testu skript uloží jeho konfiguraci společně
s nashromážděnými výsledky do souboru a ukončí svoji činnost.
Skript musí být volán z kódu externí aplikace. Aby mohlo dojít
k jeho spuštění, je třeba spustit program TCL Shell s argumentem
cesty k požadovanému skriptu. V případě, že skript samotný rovněž
přebírá argumenty, jsou tyto argumenty umístěny za argument cesty ke skriptu.
Volání skriptu z příkazového řádku může vypadat jako na ukázce níže.
Tclsh85 je název spouštěcího
souboru TCL Shellu 8.5. Následuje název skriptu a argumenty – IP adresy a
protokol. Číslo 156 reprezentuje QoS masku EF
(Expedited Flow). [6] Poslední argument zajišťuje přesměrování chybového
výstupu skriptu na standardní výstup. Toto přesměrování bude mít význam
později.
Spouštění skriptu z externí aplikace je prováděno pomocí funkcí _popen a _pclose (viz ukázka).
Řetězec path obsahuje cestu ke
spouštěcímu souboru TCL Shellu a k TCL skriptu, řetězec parameters obsahuje ostatní argumenty
(viz volání z příkazového řádku). Tyto dva řetězce jsou konkatenovány a
předány jako parametr funkci _popen.
Tato funkce spustí nový proces a jeho standardní výstup připojí k proměnné
souborového typu output.
Uvnitř cyklu while je výstup
načítán a tisknut do debugovací konzole OPNET Modeleru. S přesměrováním
chybového výstupu na standardní je konzole schopna zobrazovat chyby vzniklé
uvnitř skriptu. Výskyt znaku EOF
(konec souboru) na výstupu indikuje skončení běhu skriptu. Cyklus je ukončen a
propojení výstupu procesu s proměnnou je zrušeno funkcí _pclose.
C API
Toto API je ovládáno funkcemi programovacího jazyka C. Jelikož je externí
aplikace kódována v tomto jazyce, mohou být tyto funkce implementovány
přímo uvnitř jejího kódu. Ve srovnání s TCL API přináší C API jednu
nevýhodu. V TCL jazyce všechny funkce obsahují mechanizmus chování v případě
chyby. V jazyce C je na programátorovi, aby implementoval vlastní
mechanizmus. Externí aplikace tedy obsahuje dvě interní (neexportované) funkce:
první pro nastavení a spuštění testu a druhou pro zpracování chybových stavů. Pro
umožnění volání funkcí z IxChariot C API je v externí aplikaci třeba
přidat hlavičkový soubor chrapi.h.
Ve funkci pro nastavení a spuštění testu je nutné nejprve voláním funkce CHR_api_initialize inicializovat
rozhraní. Tato funkce mimo jiné slouží i k přístupu k informacím o
chybách při volání funkcí rozhraní. Pokud toto volání selže, API není
inicializováno a pro ošetření chyby je použit jiný mechanizmus než u ostatních
funkcí (viz ukázka).
Proměnná rc uchovává návratový kód
funkce. Po volání funkce je tato proměnná testována na případnou indikaci
chybového stavu. [2] Tento mechanizmus ukládání návratového kódu je implementován
při každém volání funkce rozhraní C API, ačkoli v následujících ukázkách nebude
zobrazován.
Následující struktura je velice podobná TCL skriptu. Na počátku jsou vytvořeny
proměnné pro test a pár, proměnné testu je přiřazen název souboru a proměnné
páru ostatní parametry jako IP adresy atd.
Situace s nastavováním QoS je stejná jako v případě TCL skriptu.
Napřed je volána funkce pro vytvoření nové šablony, a pokud již šablona
existuje, volá se funkce pro její modifikaci. Šablona se přiřadí k páru, proměnná
páru se přiřadí k testu a test je spuštěn.
Po spuštění testu aplikace čeká na jeho ukončení. V cyklu while v následující ukázce je
testováno, zdali test skončil a zdali byl dosažen časový limit. Funkce CHR_test_query_stop
vrací hodnotu CHR_OK v případě, že test skončil v rámci
časového intervalu zadaného v proměnné timeout.
Při návratové hodnotě CHR_TIMED_OUT je
inkrementován čítač a smyčka pokračuje. Jakákoli jiná hodnota návratového kódu
indikuje chybu. Přímo za cyklem se nachází další podmínka zjišťující, zdali
test skončil. V negativním případě je hlášena chyba o dosažení časového
limitu pro běh testu.
V opačném případě je test uložen a program se vrací do funkce callback.
Funkce pro ošetření chyb se nazývá show_error
a jejím hlavním účelem je sběr informací o chybách a zobrazování hlášení do
konzole v OPNET Modeleru. Její koncept byl převzat z ukázkových kódů v SDK
(Software Development Kit) složce IxChariotu.
Ke sběru základních informací o chybách se používá funkce CHR_api_get_return_msg. Pokud její volání
uspěje, jsou získané informace zobrazeny v konzole.
Ve specifických případech, kde návratový kód nese hodnotu CHR_OPERATION_FAILED nebo CHR_OBJECT_INVALID,
jsou dostupné rozšířené informace o chybě. Tyto informace se zapisují do logovacího souboru.
Závěr
Tento článek popisuje dva možné přístupy k vytvoření middleware vrstvy
pro propojení simulace v OPNET Modeleru s generátorem síťového
provozu IxChariot. Přístupy se liší v použitém API uskutečňujícím
propojení.
Použití TCL API vyžaduje dodatečný software (TCL Shell). Navíc dochází k rozdělení
middleware vrstvy mezi externí aplikaci a TCL skript, čímž kód ztrácí
integritu.
Na druhou stranu C API vyžaduje větší programátorské úsilí ve fázi vývoje. Vyšší
konzistence a menší softwarové nároky v porovnání s TCL API nicméně dělají
z C API výhodnějšího kandidáta pro propojování OPNET Modeleru s IxChariotem.
Rozhraní TCL API by přinášelo výhody v případě, že aplikace generující
data (v tomto případě OPNET Modeler) by byla založena na jazyce TCL. Takovou
aplikací může být například síťový simulátor NS-2.
Literatura
[1] IXIA. IxChariot User Guide, Release 7.0. 913-0843 Rev. A. July 2009
[2] IXIA. IxChariot API Guide, Release 7.10. 913-0954-02 Rev. A. June 2010
[3] OPNET TECHNOLOGIES. OPNET Modeler Documentation Set, Release 16.0. OPNET Technologies Inc. July 2010
[4] HOŠEK, J.; RŮČKA, L.; MOLNÁR, K.; BARTL, M.; MATOCHA, T. Integration of Real Network Components into OPNET Modeler Co-simulation Process. WSEAS TRANSACTIONS on COMMUNICATIONS, 2010, volume 9, issue 9, p. 553-562. ISSN: 1109-2742.
[5] BARTL, M. Aplikace zpracovávající reálný síťový provoz v prostředí OPNET Modeler. Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2009. 31 s.
[6] BEDNÁRIK, J. Modelovanie komunikácie proprietárnym protokolom, určeným pre výmenu informácií s podporovanou technológiou QoS, v prostredí Opnet Modeler, Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2007. 35 s.
Ovládání generátoru síťového provozu z prostředí OPNET Modeler
