Emulator bezprzewodowych mobilnych sieci ad-hoc oparty na sterowniku TUN/TAP

Transkrypt

1 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 projektowanych dla tych sieci. W rozwiązaniu wykorzystano sterownik TUN/TAP, umoŝliwiając stworzenie wirtualnej infrastruktury j w środowisku systemu operacyjnego Linux. Artykuł opisuje architekturę i funkcjonalność emulatora. 1. Wprowadzenie Testowanie 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 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.

2 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 moŝliwy do uruchomienia w rzeczywistych urządzeniach z minimalnymi zmianami. Emulator ma dostarczać standardowych interfejsów systemowych, do których procesy 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 warstwy j ( ). 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. 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. kaŝdego 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) Wirtualne urządzenia Emulator Wirtualne urządzenia Rys. 1. Zarys działania Emulatora: a) sieć rzeczywista, b) sieć emulowana.

3 3. Emulator na tle istniejących rozwiązań W związku z testowaniem powstałych implementacji, 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 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 mi są wykorzystywane do dynamicznego wprowadzania zmian w tablicach 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, które w rzeczywistości dedykowane są do działania na osobnych platformach sprzętowych ch 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. 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 j z protokołem IP. NEMAN nie moŝe zostać uŝyty do testowania. Zastosowana w nim koncepcja uŝycia sterownika TUN/TAP do tworzenia wirtualnej infrastruktury j, została jednak ponownie wykorzystana przy projektowaniu nowego emulatora. 4. Architektura Emulatora W działaniu Emulatora wykorzystano następujące fakty: a) testowanych 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.

4 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 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 go, który zastępuje całą infrastrukturę fizyczną. Gniazda wirtualnych węzłów Warstwa sieciowa i wyŝsze Warstwa łącza danych Warstwa fizyczna Interfejsy wirtualnych urządzeń TAP Rys. 2. Idea działania Emulatora. Proces 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 go 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. 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. 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 mi moŝe nawiązać bezpośrednie połączenia oraz Ŝe w róŝnych momentach moŝe nawiązać te połączenia z róŝnymi mi. 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 mi 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

5 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 i nie zostały włączone do wymagań aplikacji. Uruchomione w systemie operacyjnym procesy testowanych, mają do dyspozycji równieŝ inne (niŝ ) 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. Architekturę Emulatora przedstawiono na rys. 3. Rys. 3. Architektura Emulatora.

6 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) testowanego protokołu reprezentujące poszczególne węzły korzystające z wirtualnej infrastruktury j. 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 mi 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 mi (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 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 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 dla adresowania kontekstowego

7 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, Dostępny na: 2. Strona domowa Zespołu Aplikacji Mobilnych i Wbudowanych (ang. Mobile and Embedded Application Group), listopad 2006: 3. Strona domowa projektu MIDAS, listopad 2006: 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, Dostępny na: 5. Strona domowa programu Network Simulator (ns-2), listopad 2006: 6. M. Krasnyansky, Universal TUN/TAP device driver, listopad Strona domowa projektu: 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, Dostępny na: 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, Dostępny na: 9. P. Mahadevan, A. Rodriguez, D. Becker, A. Vahdat, MobiNet: A Scalable Emulation Infrastructure for Ad Hoc and Wireless Networks, UCSD Technical Report CS , Dostępny na: W. Richard Stevens, UNIX, Programowanie usług sieciowych, Tom 1, Wydawnictwa Naukowo-Techniczne, Warszawa, 2000