Ovládání generátoru síťového provozu z prostředí OPNET Modeler

Autor: M. Bartl, K. Molnár <ing.milan.bartl(at)gmail.com>, Pracoviště: Vysoké učení technické v Brně, Téma: Aplikace a služby, Vydáno dne: 29. 08. 2011

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.

OPNet_01

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.

OPNet_02

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í.

OPNet_03

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.

OPNet_04

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.

OPNet_05

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]

OPNet_06

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.

OPNet_07

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.

OPNet_08

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.

OPNet_09

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.

OPNet_10

Po dokončení nastavení je pár přidružen k testu a test může být spuštěn.

OPNet_11

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.

OPNet_12

Po skončení testu skript uloží jeho konfiguraci společně s nashromážděnými výsledky do souboru a ukončí svoji činnost.

OPNet_13

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.

OPNet_14

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).

OPNet_15

Ř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).

OPNet_16

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.

OPNet_17

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.

OPNet_18

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.

OPNet_19

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.

OPNet_20

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.

OPNet_21

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.