Emulator bezprzewodowych mobilnych sieci ad

Marcin Frąckowiak
Radosław Olgierd Schoeneich
Jarosław Domaszewicz
Michał Koziuk
Instytut Telekomunikacji
Politechnika Warszawska
Emulator bezprzewodowych mobilnych sieci
ad-hoc oparty na sterowniku TUN/TAP
W artykule przedstawiono emulator dla bezprzewodowych mobilnych sieci ad-hoc umoŜliwiający łatwe i
szybkie przeprowadzanie testów protokołów rutingu projektowanych dla tych sieci. W rozwiązaniu
wykorzystano sterownik TUN/TAP, umoŜliwiając stworzenie wirtualnej infrastruktury sieciowej w
środowisku systemu operacyjnego Linux. Artykuł opisuje architekturę i funkcjonalność emulatora.
1. Wprowadzenie
Testowanie protokołów rutingu dla bezprzewodowych mobilnych sieci ad-hoc (ang. Mobile
Ad-hoc Network, MANET) stanowi waŜną część procesu projektowania oprogramowania.
Specyficzne cechy sieci jak częste zmiany topologii spowodowane mobilnością węzłów, czy brak
stałej infrastruktury muszą być uwzględniane od najwcześniejszych stadiów projektowania.
Dostępność łatwych w uŜyciu i skutecznych narzędzi do przeprowadzania testów w trakcie procesu
tworzenia, jest krytycznym czynnikiem, który decyduje o poprawności działania protokołu w jego
ostatecznym kształcie. Ma to równieŜ wpływ na czas i koszt potrzebny do osiągnięcia
satysfakcjonującego rezultatu.
Częścią procesu tworzenia jest bieŜące analizowanie i porównywanie dopuszczalnych
alternatyw, sprawdzanie skutków przyjętych rozwiązań, sprawdzanie czy spełniane są zakładane
oczekiwania w sensie ilościowym i jakościowym, czy porównywanie rezultatów z innymi,
pokrewnymi rozwiązaniami. MoŜna wyróŜnić trzy sposoby przeprowadzania testów, które spełniają
te zadania [1]: faktyczna implementacja i testy w rzeczywistym środowisku (testy polowe),
wykorzystanie symulatora, wykorzystanie emulatora. Zasadniczą przewagą wykorzystania
emulatora nad pozostałymi dwoma rozwiązaniami jest moŜliwość testowania kodu w wersji, która
moŜe być od razu uruchomiona w rzeczywistym systemie, przy jednoczesnym zachowaniu kontroli
nad parametrami środowiska testowego (powtarzalność eksperymentów) i niskich kosztach
realizacji.
W artykule tym opisano emulator stworzony na potrzeby przeprowadzenia testów protokołu
rutingu dla sieci MANET zaprojektowanego i zaimplementowanego przez Zespół Aplikacji
Mobilnych i Wbudowanych IT PW [2] w ramach projektu EU 6FP MIDAS [3,4] (ang. Middleware
Platform for Developing Advanced Mobile Services). W dwóch kolejnych rozdziałach artykułu
opisano motywację dla stworzenia nowego emulatora. W rozdziale 4 został opisany sposób
dostarczania funkcjonalności sieci MANET testowanym protokołom.
2. Wymagania dla Emulatora
Wymagania postawione projektowanemu emulatorowi moŜna ująć w punktach:
a) Minimalny "wkład początkowy" uŜytkownika – emulator łatwy do uruchomienia
i korzystania, posiadający interfejs graficzny.
b) Niski koszt korzystania – aplikacja działająca na pojedynczym komputerze osobistym klasy
PC z systemem operacyjnym Linux.
c) Skalowalność – aplikacja umoŜliwiająca emulację sieci zarówno małych jak i o duŜej liczbie
węzłów.
d) Przenośność kodu – kod testowanych protokołów moŜliwy do uruchomienia
w rzeczywistych urządzeniach z minimalnymi zmianami. Emulator ma dostarczać
standardowych interfejsów systemowych, do których procesy protokołów rutingu mogą
wysyłać i odbierać dane za pośrednictwem standardowego API gniazd surowych (ang. raw
socket) systemu Linux.
e) MoŜliwość porównywania rezultatów emulacji z symulacjami przeprowadzanymi z uŜyciem
narzędzia Network Simulator (ns-2) [5] – wykorzystanie standardowego formatu pliku
scenariusza symulatora ns-2 do opisu mobilności węzłów emulowanej sieci.
f) Emulacja na poziomie warstwy łącza danych modelu OSI – aplikacja ma wykorzystywać
sterownik TUN/TAP [6] do dostarczania funkcjonalności oraz odzwierciedlania
charakterystyki warstwy łącza danych mobilnej sieci ad-hoc. Emulacja na poziomie
warstwy łącza danych ma umoŜliwić testowanie protokołów warstwy sieciowej (protokołów
rutingu).
Działanie Emulatora oparte jest na wykorzystaniu sterownika TUN/TAP do stworzenia na
pojedynczym komputerze zestawu wirtualnych urządzeń sieciowych. Reprezentują one urządzenia
poszczególnych węzłów sieci rzeczywistej. Procesy protokołów rutingu kaŜdego z węzłów
uruchamiane są jednocześnie w przestrzeni uŜytkownika systemu. KaŜdemu z nich dedykowany
jest konkretny, pojedynczy interfejs wirtualnego urządzenia. Procesy kaŜdego węzła wysyłają
i odbierają dane z interfejsu za pośrednictwem standardowego API gniazd sieciowych. Odbywa się
to w taki sam sposób, w jaki miałoby to miejsce w przypadku ich działania na osobnej platformie
sprzętowej. Emulator, na podstawie informacji ze scenariusza mobilności węzłów, przesyła dane
pomiędzy wirtualnymi urządzeniami, co odzwierciedla istnienie (lub brak) bezprzewodowych
połączeń w sieci rzeczywistej. Zarys koncepcji działania aplikacji przedstawiony został na rys. 1.
a)
b)
Procesy
protokołów
rutingu
Urządzenie
sieciowe
węzła
Procesy
protokołów
rutingu
Procesy
protokołów
rutingu
Urządzenie
sieciowe
węzła
Urządzenie
sieciowe
węzła
Procesy
protokołów
rutingu
Urządzenie
sieciowe
węzła
Procesy
protokołów
rutingu
Procesy
protokołów
rutingu
Wirtualne urządzenia sieciowe
Procesy
protokołów
rutingu
Procesy
protokołów
rutingu
Wirtualne urządzenia sieciowe
Emulator
Rys. 1. Zarys działania Emulatora: a) sieć rzeczywista, b) sieć emulowana.
3. Emulator na tle istniejących rozwiązań
W związku z testowaniem powstałych implementacji protokołów rutingu, stworzonych zostało
kilka emulatorów sieci bezprzewodowych. śadna z dostępnych aplikacji nie spełniała jednak
jednocześnie wszystkich z przedstawionych w poprzednim punkcie wymagań. Zadecydowało to o
konieczności stworzenia naszego narzędzia.
Emulatory MNE [7] i EMWIN [8] wykorzystują statyczną infrastrukturę sieciową do
emulowania sieci MANET. Zakładają istnienie połączonego w lokalną sieć zestawu komputerów,
w których kaŜde z urządzeń reprezentuje pojedynczy węzeł sieci emulowanej. Urządzenia sieciowe
posiadają po dwa interfejsy, gdzie jeden z nich wykorzystywany jest jako kanał kontrolny emulacji
(do przesyłania informacji o zmianach topologii), a drugi do przesyłania danych. Przesyłane
w kanale kontrolnym informacje o zmianach połączeń pomiędzy węzłami są wykorzystywane do
dynamicznego wprowadzania zmian w tablicach rutingu IP. Pomimo, iŜ EMWIN pozwala na
wykorzystanie kilku urządzeń sieciowych w kaŜdym z komputerów (w MNE kaŜdy z węzłów musi
być oddzielną maszyną), to i tak prezentowane podejście wymaga wykorzystania znaczącej ilości
sprzętu, co czyni je niepraktycznym i drogim.
Fizyczna architektura systemu MobiNet [9] składa się z węzłów szkieletowych,
wykorzystywanych do emulowania charakterystyki sieci bezprzewodowej oraz węzłów
brzegowych. W MobiNet moŜliwa jest emulacja duŜej liczby bezprzewodowych urządzeń dzięki
tworzeniu wirtualnych węzłów brzegowych z róŜnymi adresami IP w kaŜdym z fizycznych węzłów
brzegowych. W tym przypadku ilość koniecznego do uŜycia sprzętu jest istotnie mniejsza
w porównaniu do dwóch poprzednich emulatorów. System ten jest jednak skomplikowany
w konfiguracji i korzystaniu.
Emulator NEMAN [1] jest aplikacją, która spośród dostępnych, gotowych narzędzi,
w największym stopniu spełnia opisane w poprzednim rozdziale wymagania. NEMAN został
stworzony do emulowania duŜych sieci bezprzewodowych, z wykorzystaniem pojedynczego
komputera osobistego. Zastosowany w aplikacji sterownik TUN/TAP umoŜliwia tworzenie
i zarządzanie wirtualnymi urządzeniami sieciowymi. Przyłączane są do nich procesy testowanych
protokołów, które w rzeczywistości dedykowane są do działania na osobnych platformach
sprzętowych – węzłach sieci MANET. UŜytkownik ma równieŜ do dyspozycji interfejs graficzny.
Rozwiązanie, które reprezentuje NEMAN, jest tanie, skalowalne, proste w uŜyciu i gwarantuje
przenośność kodu testowanych programów. NEMAN nie mógł jednak zostać uŜyty przez Zespół
Aplikacji Mobilnych i Wbudowanych do testowania tworzonego protokołu, poniewaŜ program ten
zakłada wykorzystanie protokołu IP jako protokołu rutingu. Ten emulator nie uwzględnia
moŜliwości bezpośredniego dostępu do warstwy łącza danych emulowanej sieci z uŜyciem API
gniazd surowych. Testowane programy muszą korzystać z dostarczanej przez emulator
funkcjonalności na poziomie warstwy sieciowej z protokołem IP.
NEMAN nie moŜe zostać uŜyty do testowania protokołów rutingu. Zastosowana w nim
koncepcja uŜycia sterownika TUN/TAP do tworzenia wirtualnej infrastruktury sieciowej, została
jednak ponownie wykorzystana przy projektowaniu nowego emulatora.
4. Architektura Emulatora
W działaniu Emulatora wykorzystano następujące fakty:
a) Procesy testowanych protokołów rutingu mają bezpośredni dostęp do interfejsów urządzeń
sieciowych swoich węzłów (warstwy łącza danych sieci) oraz mogą wysyłać i odbierać
z nich informacje za pośrednictwem API gniazd surowych systemu operacyjnego.
b) Wiedza procesów na temat sieci, z której korzystają, ograniczona jest do informacji
moŜliwych do uzyskania na poziomie dostępu do warstwy łącza danych (interfejsów
urządzeń sieciowych) i nie jest im znany rzeczywisty sposób transmisji informacji.
c) Sterownik TUN/TAP umoŜliwia stworzenie wirtualnych urządzeń sieciowych na poziomie
warstwy łącza danych i aplikacja działająca w przestrzeni uŜytkownika systemu
operacyjnego moŜe przesyłać pomiędzy tymi urządzeniami dane w dowolny sposób
kształtując charakterystykę tej komunikacji.
Rys. 2 prezentuje główną ideę działania Emulatora. Aplikacja tworzy wirtualne urządzenia
TAP, które zastępują fizyczne urządzenia sieciowe Ethernet, z których korzystałyby węzły. KaŜdy
węzeł wirtualnej sieci składa się z procesów uruchomionych w przestrzeni uŜytkownika systemu
oraz dedykowanego dla niego wirtualnego urządzenia sieciowego, który zastępuje całą
infrastrukturę fizyczną węzła.
Gniazda
sieciowe
Procesy protokołów rutingu wirtualnych węzłów
Warstwa sieciowa i wyŜsze
Warstwa łącza danych
Warstwa fizyczna
Interfejsy wirtualnych
urządzeń TAP
Proces Emulatora
Rys. 2. Idea działania Emulatora.
Tak jak w przypadku rzeczywistej sieci MANET, kaŜdy węzeł identyfikowany jest na
podstawie 48-bitowego adresu MAC – w tym przypadku jest to jednak adres MAC urządzenia
TAP, a nie fizycznego urządzenia sieciowego Ethernet. PoniewaŜ Emulator jest twórcą wszystkich
urządzeń TAP, dane wysyłane na interfejsy przez procesy kaŜdego z węzłów mogą być przez niego
odebrane, a następnie moŜe on podjąć decyzję, do których innych interfejsów zostaną dostarczone.
Decyzja o tym gdzie dane powinny być przekazane podejmowana jest na podstawie posiadanych
przez emulator informacji o bieŜącej topologii emulowanej sieci, które wczytywane są z pliku
scenariusza mobilności węzłów. Dane wysłane przez kaŜdy wirtualny węzeł dostarczane są do
wszystkich pozostałych, które w prawdziwej sieci MANET byłyby w jego zasięgu.
Procesy protokołów testowanych w Emulatorze wykorzystują to samo API gniazd sieciowych,
jakie byłoby uŜywane w przypadku działania na osobnych platformach sprzętowych. Wszystkie
funkcje tworzenia gniazd oraz wysyłania i odbierania danych (socket(), sendto(), recvfrom() [10])
są takie same. Konieczne jest jednak dodatkowe przywiązanie (funkcja bind()) wykorzystywanych
przez procesy gniazd, aby zapewnić, Ŝe dany wirtualny węzeł będzie się komunikował z resztą sieci
tylko za pośrednictwem dedykowanego dla niego interfejsu.
Procesy protokołów nie są świadome fizycznego przemieszczania się węzłów. O tym, Ŝe węzeł
zmienia połoŜenie, proces dowiaduje się na podstawie tego, z którymi innymi węzłami moŜe
nawiązać bezpośrednie połączenia oraz Ŝe w róŜnych momentach moŜe nawiązać te połączenia
z róŜnymi węzłami. Mobilność węzłów jest równoznaczna ze zmianami moŜliwości nawiązywania
połączeń między nimi. Aplikacja przez cały czas trwania emulacji utrzymuje w swojej pamięci
tablicę, w której zapisane są statusy bezpośrednich połączeń pomiędzy wszystkimi węzłami –
dostępne, niedostępne. Na podstawie informacji zawartych w tej tablicy, Emulator, gdy odbiera z
któregoś z wirtualnych urządzeń ramkę, decyduje, do których innych urządzeń powinna być ona
przesłana. Jednocześnie jeden z wątków programu wprowadza zmiany w statusach tych połączeń na
podstawie scenariusza emulacji, który został zadany przez uŜytkownika aplikacji.
Scenariusz emulacji jest plikiem, który jest wczytywany do programu za kaŜdym razem przed
rozpoczęciem emulacji i określa, w jaki sposób węzły przemieszczałyby się w rzeczywistej sieci
oraz jakie miałoby to konsekwencje dla istnienia połączeń między nimi. Scenariusz mobilności
węzłów jest tworzony przez uŜytkownika aplikacji i jest odzwierciedleniem jego zapotrzebowania
na przeprowadzenie konkretnego scenariusza testowego. Z uwagi na zunifikowanie formatu
wczytywanych scenariuszy z formatem uŜywanym w ns-2, do ich tworzenia moŜna wykorzystać
program setdest wchodzący w skład pakietu narzędzi Network Simulator 2.
Funkcjonalność Emulatora nie obejmuje zagadnień specyficznych dla warstwy fizycznej
mobilnych sieci ad-hoc związanych z propagacją sygnału radiowego. Aplikacja nie emuluje
właściwości sieci takich jak istnienie kolizji, problemu ukrytych węzłów, czy parametrów
jakościowych sygnału. Uznano, Ŝe zagadnienia te są stosunkowo mało istotne przy testowaniu
protokołów rutingu i nie zostały włączone do wymagań aplikacji.
Uruchomione w systemie operacyjnym procesy testowanych protokołów, mają do dyspozycji
równieŜ inne (niŜ sieciowe) API umoŜliwiające dostęp do pozostałych zasobów systemowych
takich jak np. pamięć podręczna i dyskowa. Aplikacja nie emuluje dostępu do tych zasobów,
dlatego zagwarantowanie braku konfliktów przy ich wykorzystaniu spoczywa na barkach twórców
testowanych protokołów.
Architekturę Emulatora przedstawiono na rys. 3.
Rys. 3. Architektura Emulatora.
Architekturę Emulatora podzielono na trzy elementy składowe: (a) Interakcja programu
z uŜytkownikiem za pośrednictwem terminala tekstowego, interfejsu graficznego oraz programu
Network Animator (NAM) [5]. (b) Część właściwa programu odpowiedzialna za stworzenie
wirtualnej sieci i wykonanie scenariusza emulacji. (c) Procesy testowanego protokołu
reprezentujące poszczególne węzły korzystające z wirtualnej infrastruktury sieciowej.
Architektonicznie działanie aplikacji podzielono na cztery etapy: (1) Wczytanie oraz
sprawdzenie poprawności danych wejściowych. (2) Stworzenie i konfiguracja urządzeń TAP oraz
oczekiwanie na przywiązanie do ich interfejsów procesów reprezentujących węzły. (3) Wykonanie
scenariusza emulacji – przesyłanie ramek oraz dynamiczne modyfikowanie tablicy połączeń
pomiędzy węzłami zgodnie ze scenariuszem. (4) Zakończenie działania programu.
Dane wejściowe oraz opcje programu wczytywane są z linii poleceń terminala uŜytkownika
(tryb tekstowy) lub z interfejsu graficznego. W skład danych wejściowych wchodzą ustawienia
związane ze sposobem prezentowania uŜytkownikowi wyników działania aplikacji oraz dane
związane z samym przebiegiem emulacji – w tymi ścieŜka dostępu do pliku, w którym jest zapisany
scenariusz mobilności węzłów. Funkcje przetwarzające dane wejściowe sprawdzają czy plik
scenariusza jest poprawnie skonstruowany pod względem syntaktyki. Następnie tworzona jest
tablica połączeń pomiędzy węzłami (topologia sieci), na jej podstawie Emulator będzie przesyłał
ramki pomiędzy urządzeniami TAP, oraz chronologiczna lista zmian w statusach tych połączeń.
Lista zdarzeń wykorzystywana jest przez wątek programu, który w czasie trwania emulacji
modyfikuje tablicę połączeń.
W trakcie wczytywania scenariusza tworzona jest równieŜ jego wizualizacja, która jeszcze
przed rozpoczęciem emulacji moŜe zostać odtworzona w programie Network Animator. UmoŜliwia
to przejrzenie zawartości scenariusza przed jego wykonaniem.
Emulator tworzy taką liczbę wirtualnych urządzeń sieciowych TAP, jaka jest liczba węzłów
emulowanej sieci. KaŜdemu z nich przypisywany jest unikalny adres MAC o numerze
ab:cd:ef:00:XX:XX oraz interfejs o nazwie „tapXX”, gdzie „XX” jest numerem węzła sieci.
Informacja o kaŜdym z urządzeń TAP zapisana zostaje w programie w postać struktury
zawierającej numer deskryptora pliku urządzenia, adres MAC oraz nazwę interfejsu. Deskryptory
wykorzystywane są do przesyłania ramek pomiędzy urządzeniami, a adresy MAC i nazwy
interfejsów do identyfikacji urządzeń oraz przywiązywania do nich procesów.
Wykonanie scenariusza emulacji następuje w dwóch wątkach programu. Wątek główny
nasłuchuje czy na interfejsach urządzeń TAP pojawiają się ramki danych. JeŜeli tak, ramka zostaje
odebrana, a program sprawdza informacje w tablicy połączeń. Dane zostają wysłane do interfejsów
wszystkich urządzeń, z którymi istnieje połączenie. Równocześnie z procesem głównym programu
działa wątek obsługi zdarzeń – tzw. scheduler. Wątek ten monitoruje na bieŜąco czas, który upłynął
od rozpoczęcia emulacji i dokonuje zmian w tablicy połączeń. Wątek obsługi zdarzeń
odpowiedzialny jest równieŜ za przesłanie do wątku głównego informacji o upłynięciu zadanego
czasu trwania emulacji.
Zakończenie działania programu następuje w momencie upłynięcia zadanego czasu emulacji.
Wszystkie utworzone przez program wirtualne urządzenia sieciowe zostają usunięte z systemu
operacyjnego. Bez wykonywania Ŝadnych dodatkowych czynności program moŜe zostać ponownie
uruchomiony.
5. Zastosowanie Emulatora
Emulator został wykorzystany w projekcie EU 6FP MIDAS przy testowaniu implementacji
elementu składowego warstw pośrednich protokołu rutingu dla adresowania kontekstowego
MIDAS Context Based Routing. Z wykorzystaniem emulatora przeprowadzono testy funkcjonalne
dla emulowanych sieci bezprzewodowych złoŜonych od kilkunastu do kilkudziesięciu węzłów.
6. Podsumowanie
W artykule przedstawiono opis architektury i działanie emulatora bezprzewodowych sieci
działających w trybie ad-hoc przeznaczonego do testowania oprogramowania rutującego
wykorzystującego interfejs gniazd. Emulator został wykorzystany w praktyce przy testowaniu
implementacji elementów oprogramowania warstw pośrednich (ang. middleware) projektu EU 6FP
MIDAS.
Literatura
1.
M. Puzar, T. Plagemann, NEMAN: A Network Emulator for Mobile Ad-Hoc Networks,
Technical Report #321, Department of Informatics, University of Oslo, 2005. Dostępny na:
http://www.ifi.uio.no/forskning/grupper/dmms/papers/138.pdf
2.
Strona domowa Zespołu Aplikacji Mobilnych i Wbudowanych (ang. Mobile and Embedded
Application Group), listopad 2006: http://meag.tele.pw.edu.pl/
3.
Strona domowa projektu MIDAS, listopad 2006: http://www.ist-midas.org/
4.
J. Domaszewicz, M. Koziuk, M. Rój, R. Schoeneich, K. Kacperski, Projekt MIDAS: Platforma
Programistyczna do Tworzenia i WdraŜania Zaawansowanych Usług Mobilnych, Instytut
Telekomunikacji Politechniki Warszawskiej, Warszawa, 2006. Dostępny na:
http://kst.tele.pw.edu.pl/kst2006/ref/pm.05.pdf
5.
Strona domowa programu Network Simulator (ns-2), listopad 2006:
http://www.isi.edu/nsnam/ns/
6.
M. Krasnyansky, Universal TUN/TAP device driver, listopad 2006. Strona domowa projektu:
http://vtun.sourceforge.net/tun
7.
J. P. Macker, W. Chao, J. W. Weston, A low-cost, IP-based mobile network Emulator (MNE),
MILCOM 2003 – IEEE Military Communications Conference, 2003, 22, 481-486. Dostępny
na: http://cs.itd.nrl.navy.mil/pubs/docs/mne_milcom03.pdf
8.
P. Zheng, L. M. Ni, EMWIN: Emulating a Mobile Wireless Network using a Wired Network,
5th ACM international workshop on Wireless mobile multimedia, Atlanta, Georgia, 2002.
Dostępny na: http://gargoyle.arcadia.edu/mathcs/zhengpei/publications/wowMoM02_zheng.pdf
9.
P. Mahadevan, A. Rodriguez, D. Becker, A. Vahdat, MobiNet: A Scalable Emulation
Infrastructure for Ad Hoc and Wireless Networks, UCSD Technical Report CS2004-0792,
2004. Dostępny na: http://sysnet.ucsd.edu/~pmahadevan/publications/mobinet-mc2r.pdf
10. W. Richard Stevens, UNIX, Programowanie usług sieciowych, Tom 1, Wydawnictwa
Naukowo-Techniczne , Warszawa, 2000