XVII Poznańskie Warsztaty Telekomunikacyjne 13 grudnia 2013 Poznań

Transkrypt

1 XVII Poznańskie Warsztaty Telekomunikacyjne 13 grudnia 2013 Poznań Wydział Elektroniki i Telekomunikacji Politechnika Poznańska

2

3 XVII Poznańskie Warsztaty Telekomunikacyjne - PWT grudnia 2013 Poznań KOMITET PROGRAMOWY PWT 2013 Marek Amanowicz Daniel Józef Bem Anna Cysewska-Sobusiak Andrzej Dobrogowski (przewodniczący) Adam Dąbrowski Marek Domański Janusz Filipiak Wojciech Kabaciński Józef Lubacz Zdzisław Papir Wojciech Sobczak Paweł Szulakiewicz Zbigniew Szymański Krzysztof Wesołowski Marian Zientalski Wojskowa Akademia Techniczna Politechnika Wrocławska Politechnika Poznańska Politechnika Poznańska Politechnika Poznańska Politechnika Poznańska Akademia Górniczo-Hutnicza Politechnika Poznańska Politechnika Warszawska Akademia Górniczo-Hutnicza Politechnika Gdańska Politechnika Poznańska Politechnika Poznańska Politechnika Poznańska Politechnika Gdańska KOMITET ORGANIZACYJNY PWT 2013 Robert Kotrys Piotr Remlein Paweł Szulakiewicz Marzena Łopińska Przewodniczący Wydawca: POLITECHNIKA POZNAŃSKA Wydział Elektroniki i Telekomunikacji ul. Polanka 3, POZNAŃ pwt@et.put.poznan.pl Strona Internetowa: Wszystkie artykuły zostały zrecenzowane i opublikowane bez korekty w formie przekazanej przez autorów. All papers have been peer-reviewed and published as received without alteration of their technical contents. ISBN Wydział Elektroniki i Telekomunikacji Politechnika Poznańska

4

5 Spis referatów Sesja I. Kształcenie w dziedzinie elektroniki i telekomunikacji 1. SYSTEM ZDALNEGO DOSTĘPU DO LABORATORIUM BADAWCZEGO. 1 Marcin Dziuba, Marek Michalski, Mariusz Żal 2. WYKORZYSTANIE KART NETFPGA W PROCESIE DYDAKTYCZNYM. 6 Marek Michalski 3. WYKORZYSTANIE SYMULATORA NS-3 W DYDAKTYCE - ILUSTRACJA DZIAŁANIA SIECI TYPU MESH. Przemysław Kurylak, Katarzyna Wasielewska, Andrzej Borys 12 Sesja II. Nowe obszary badań systemów i sieci telekomunikacyjnych 4. SIECI STEROWANE PROGRAMOWO SDN W CENTRACH DANYCH SDDC. 18 Janusz Kleban, Maciej Puciński 5. MODYFIKACJA METODY WYZNACZANIA MAKSYMALNEGO BŁĘDU PRZEDZIAŁU CZASU. Andrzej Dobrogowski, Michał Kasznia, Jakub Nikonowicz OPROGRAMOWANIE WIELOKANAŁOWEGO SYSTEMU POMIAROWEGO SYGNAŁÓW SYNCHRONIZACJI. Michał Kasznia, Michał Kryściak, Paweł Malak PROJECT SNIFFER: CONTENT SERVER DISCOVERY BASED ON PLANETLAB INFRASTRUCTURE. Andrzej Bąk, Piotr Gajowniczek, Marcin Pilarski, Marcin Borkowski, Paweł Grochocki ZAPEWNIENIE INTEROPERACYJNOŚCI SYSTEMÓW ŁĄCZNOŚCI SŁUŻB BEZPIECZEŃSTWA PUBLICZNEGO I RATOWNICTWA. Maciej Szulejewski, Joanna Modławska, Andrzej Adamczyk, Wojciech Wojciechowicz 39 9.,,EKOLOGICZNE'' ALGORYTMY STERUJĄCE POLEM KOMUTACYJNYM. 43 Mariusz Żal, Przemysław Wojtasik 10. CHARACTER OF USER PORT TRAFFIC IN AX.25 NETWORK. 50 Remigiusz Olejnik - I-

6 Sesja III. Sieci i systemy bezprzewodowe 11. PERFORMANCE OF NC-OFDM AUTOCORRELATION-BASED SYNCHRONIZATION UNDER NARROWBAND INTERFERENCE. Paweł Kryszkiewicz, Hanna Bogucka 12. OVERVIEW OF THE LTE LINK LEVEL SIMULATOR DEVELOPED AT POZNAN UNIVERSITY OF TECHNOLOGY. Krzysztof Bąkowski, Karolina Ratajczak QOS PROVISIONING TRANSMISSION OBTAINED BY A STOCHASTIC GAME IN COGNITIVE RADIO NETWORKS. Jerzy Martyna ZASTOSOWANIE SIECI SENSOROWEJ W SYSTEMACH BEZPIECZEŃSTWA I NADZORU. Robert Kotrys, Piotr Rydzyński SECRET KEY AGREEMENT IN WIRELESS LANS BASED ON CSI- LIMITATIONS IN LINE-OF-SIGHT (LOS) SCENARIO. Michał Pilc, Jędrzej Stańczak ANALIZA PRZEPUSTOWOŚCI W SIECIACH WLAN IEEE DLA POTRZEB PLANOWANIA I OPTYMALIZACJI INFRASTRUKTURY TELETRANSMISYJNEJ. Adam Pieprzycki, Wiesław Ludwin 80 Sesja IV. Światłowody w sieciach telekomunikacyjnych 17. KOHERENTNY SYSTEM ŚWIATŁOWODOWY Z DYSKRETNIE PRZESTRAJALNYM NADAJNIKIEM. Andrzej Dobrogowski, Jan Lamperski, Piotr Stępczak KOMUTATOR OPTYCZNY Z KONWERSJĄ FAL. 87 Jan Lamperski - II-

7 System dostępu do laboratorium badawczego Marcin Dziuba, Marek Michalski, Mariusz Żal Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka 3, Poznań, imie.nazwisko@put.poznan.pl, Streszczenie Niniejszy artykuł prezentuje mechanizmy zwia- zane ze zdalnym dostępem stanowiace założenia oraz elementy uruchomione w ramach pilotażu projektu zdalnego laboratorium do testowania różnych protokołów, między innymi OpenFlow. Głównym elementem laboratorium sa komputery wyposażone w karty NetFPGA z interfejsami o przepustowości 1Gbps oraz 10Gbps i sterowniki protokołu OpenFlow, z ich wykorzystaniem powstaje sieć do testowania całej rodziny protokołów i mechanizmów zwiazanych z OpenFlow. Tak przygotowane laboratorium ma być dostępne zdalnie dla szerokiego grona badaczy, inżynierów i naukowców oraz studentów. I. WPROWADZENIE Mechanizmy działające w sieci Internet są stale modyfikowane w celu usprawnienia jej działania lub wprowadzenia nowych usług. Obecnie możemy wyróżnić dwa podejścia do zmian sieci Internet. Pierwsze z nich, zwane sposobem ewolucyjnym, polega na wprowadzaniu zmian małymi krokami, których rezultatem będzie pożądana architektura docelowa. Sieć uzyskana w ten sposób zwana jest siecią NGN (Next Generation Network). Drugie podejście polega na całkowitym przeprojektowaniu sieci, rozpoczynając od punktu zerowego. Takie sposób zmian w internecie wymaga zaprojektowania wszystkich niezbędnych elementów od początku. Ma swoje wady i zalety. Z jednej strony nowa architektura nie jest obciążona dziedzictwem poprzednich rozwiązań, z drugiej strony usługi, które mogłyby być dostarczane w początkowej fazie będą miały znikomą liczbę odbiorców. Obecnie prace badawcze nad Internetem Przyszłości, zgodnie z podejściem rewolucyjnym, prowadzone są w ramach wielu projektów badawczych. W obszarze Unii Europejskiej, w ramach 7. Programu Ramowego w celu Network in the Future" [1] zrealizowano wiele projektów między innymi: TRILOGY/TRILOGY2 [2], 4WARD [3], GEYERS [4] itd. Również poza obszarem UE prowadzone są prace badawcze w tym zakresie - w Japoni projekt AKARI [5] lub w USA projekt GENI [6]. Architektury sieci i stosowane w nich mechanizmy nazywane są sieciami NWGN (New Generation Networks). Dla sieci NWGN przewiduje się również nowe modele biznesowe, które dodają nowych graczy do tradycyjnych dostawców usług sieciowych oraz dostawców treści i usług. Również Zespoły Badawcze z Politechniki Poznańskiej biorą udział w rozwoju Internetu Przyszłości. Jednym z takich projektów jest projekt realizowany w Katedrze Sieci Telekomunikacyjnych i Komputerowych pt. Środowisko testowe protokołów sieciowych na bazie systemu OpenFlow. Głównym celem projektu są badania nad nowymi protokołami i algorytmami sterującymi w środowisku OpenFlow, które pozwala na ujednolicenie podejścia do zagadnień związanych z komutacją kanałów i komutacją pakietów w przełącznikach sieciowych. System OpenFlow dostarcza także narzędzi niezbędnych dla wirtualizacji sieci. Wirtualizacja sieci, jak również narzędzia jej służące są kluczowym elementem dla rozwoju Internetu Przyszłości. Cel główny został podzielony na dwa cele podrzędne. Pierwszym z nich jest opracowanie nowych metod transmisji danych, protokołów oraz algorytmów sterowania dla węzłów w sieciach pakietowych oraz przygotowanie eksperymentów mających na celu zweryfikowanie poprawności proponowanych rozwiązań. Drugim, równorzędnym celem jest opracowanie i implementacja środowiska testowego, które pozwoli na przeprowadzenie planowanych jak i przyszłych eksperymentów z zakresu Internetu Przyszłości. W artykule przedstawiono jeden z elementów realizowanego projektu - mechanizmy zdalnego dostępu do sieci eksperymentalnej. Pozostała części artykułu została zorganizowana w następujący sposób. W rozdziale II przedstawiono zasadę działania sieci wirtualnych oraz korzyści płynące z ich stosowania. Kolejny rozdział zawiera założenia realizowanego projektu w zakresie zdalnego dostępu do sieci eksperymentalnej. W następnym rozdziale opisano laboratorium, w którym realizowane będą eksperymenty z zakresu Internetu Przyszłości [7]. Cała idea zdalnego dostępu do laboratorium oraz wykorzystywane mechanizmy zostały opisane w rozdziale V. Rozdział VI zawiera podsumowanie oraz wskazuje dalsze kierunki rozwoju projektu. II. WIRTUALNE SIECI PRYWATNE - OPIS OGÓLNY Współcześnie wirtualizacja pojawia się w wielu aspektach technicznych. Jest obecna pod wieloma postaciami. Można wyróżnić dwa główne nurty. Pierwszy z nich to wirtualizacja zasobów. Polega to na tym, że jeden, duży, zbiór zasobów zostaje podzielony na mniejsze, niezależne, podzbiory, które z punktu widzenia użytkowania są odseparowane od innych użytkowników (np. pojemność łącza telekomunikacyjnego, dysku serwera, mocy obliczeniowej). W takiej sytuacji należy zwrócić uwagę na kilka istotnych parametrów realizacji tak pojętej wirtualizacji, np. separacja wydajności. Taka wirtualizacja jest szeroko wykorzystywana, istnieje wiele narzędzi ją realizujących i wspierających. Drugim rodzajem wirtualizacji jest logiczny rozdział niefizycznych zasobów, np., przestrzeni nazw, adresów itp. Umożliwia on współdzielenie zasobów fizycznych w taki sposób, że nie ma wzajemnego wpływu konfiguracji poszczególnych użytkowników. Najprostszym, wręcz typowym przykładem, są wirtualne sieci lokalne (Virtual Local Area Network - VLAN), które powstają przez portów w przełączniku lokalnego segmentu sieci LAN do wyimaginowanej PWT Poznań - 13 grudnia

8 do realizacji prac związanych z badaniami wykorzystania protokołu OpenFlow [9]. IV. LABORATORIUM PROJEKTOWE Rysunek 1. Schemat połączenia z wykorzystaniem VPN sieci LAN charakteryzowanej numerem. W tym przypadku zasoby fizyczne (takie jak pamięć przełącznika, bufory, przepustowość łączy i matrycy przełączającej) są współdzielone, natomiast logicznie urządzenia będące w różnych VLANach nie mają ze sobą bezpośredniej (na poziomie warstwy łącza danych) łączności. Innym rodzajem wirtualnych sieci są wirtualne sieci prywatne (Virtual Private Networks - VPN). Ich wirtualizacja polega na logicznym połączeniu fizycznie odległych zasobów. Dzięki temu znikają ograniczenia wynikające z fizycznego położenia, natomiast hosty będące w takiej sieci mogą być skonfigurowane tak, jakby logicznie były wpięte bezpośrednio do sieci, z którą są połączone. Sytuację taką przedstawiono na rysunku 1. Odpowiednie oprogramowanie umożliwia klientowi zestawienie tunelu do serwera VPN i dzięki temu ma on możliwość korzystania z sieci laboratorium tak, jakby był wpiety do niej bezpośrednio. III. WYBRANE ZAŁOŻENIA PROJEKTU Głównym celem projektu jest udostępnienie w kontrolowany sposób struktury laboratoryjnej badaczom i naukowcom, którzy uzyskają akceptację planowanych badań. Ważnym elementem jest bezpieczeństwo sprzętu oraz kontrola dostępu. Jednocześnie istotna jest poufność i autentyczność przekazywanych informacji między zdalnym naukowcem a laboratorium, a także bezpieczeństwo wyników przeprowadzanych badań. Zakładamy wstępną weryfikację oraz monitoring czynności, które będą realizowane przez zdalnych badaczy w naszym laboratorium. Kwestia poufności uzyskanych rezultatów wykracza poza techniczne aspekty i nie będzie dyskutowana w niniejszym artykule. Badacze, którzy zostaną zaakceptowani do współpracy, uzyskają szeroki dostęp do wyodrębnionej części laboratorium, który pozwoli przeprowadzić zaplanowane eksperymenty. Techniczne możliwości naszego laboratorium pozwalają na przygotowanie oraz uruchomienie nawet bardzo złożonych doświadczeń i eksperymentów sieciowych. Możemy udostępnić hosty zarówno fizyczne jak i wirtualne, ale przede wszystkim sieć testową zbudowaną z w pełni programowalnych węzłów sieciowych pozwalających na tworzenie różnych topologii sieciowych przez zdalną konfigurację węzłów. Aktualnie laboratorium jest dostępne dla badaczy prowadzących prace w ramach projektu Alien [8], a także dla studentów podczas niektórych zajęć laboratoryjnych i w celu przeprowadzenia badań pod kątem prowadzonych prac dyplomowych. Zdalny dostęp do laboratorium wykorzystywany jest głównie Struktura laboratorium jest heterogeniczna. Obok typowych urządzeń sieciowych (rutery i przełączniki wielu różnych firm) oraz hostów (fizycznych oraz wirtualnych) dostępne są bardzo nowoczesne urządzenia deweloperskie o ogromnym potencjalne naukowym i badawczym. Są to komputery wyposażone w karty NetFPGA [10], procesory sieciowe [11] oraz urządzenia pomiarowe [12]. Karty NetFPGA są kartami rozszerzeń do komputerów PC, posiadają po cztery interfejsy sieciowe. Ich główny układ jest programowalny, dzięki temu można przygotowywać i uruchamiać instancje zmodyfikowanych protokołów sieciowych lub ich prototypy. Aktualnie w laboratorium posiadamy 12 kart NetFPGA z interfejsami o przepustowości 1Gbps oraz 5 kart o przepustowości 10Gbps. Ważnym elementem laboratorium jest generator i analizator ruchu sieciowego - Spirent Test Center [12]. Większość pomiarów będzie dokonywana za pomocą narzędzi autorskich, jednak dokładne pomiary przepustowości i opóźnienia mogą być zrealizowane przy użyciu certyfikowanego, referencyjnego, urządzenia pomiarowego. V. WYKORZYSTANIE MECHANIZMÓW VPN Wirtualna sieć prywatna VPN (ang. Virtual Private Network) została utworzona na potrzeby zdalnego dostępu do zasobów sprzętowych znajdujących się w laboratorium. W głównej mierze chodziło o zabezpieczenie danych przesyłanych siecią publiczną pomiędzy użytkownikiem, a serwerem VPN działającym w laboratorium. Zastosowanie wirtualnej sieci dało możliwość kodowania przesyłanych danych oraz przesyłania ich transparentnie przez węzły sieci publiczej. Schemat zdalnego połączenia do laboratorium z wykorzystaniem VPNa został przedstawiony na rysunku 1. Jak można zauważyć z rysunku 1, wszystkie połączenia z wykorzystaniem VPN-a mają całkowitą izolację od sieci publicznej. Wykorzystanym rodzajem VPNa jest OpenVPN [13]. Jest to darmowy pakiet oprogramowania, dzięki któremu można tworzyć bezpieczne połączenia typu punkt-punkt lub sieć-sieć. W celu zestawiania zaszyfrowanych połączeń pomiędzy hostami, OpenVPN wykorzystuje bibliotekę OpenSSL [14], która swoje działanie opiera na protokołach SSLv3 oraz TLSv1. W laboratorium został przygotowany sprzęt komputerowy, na którym zainstalowano system operacyjny Fedora 15x64. Na tak skonfigurowanym środowisku zainstalowano serwer OpenVPN. Konfiguracja serwera przebiega poprzez modyfikację skrypu uruchamianego podczas startu serwera. Przykład takiego skrytu przedstawiono na rysunku 2. W linii 2 oraz 3 zostało określone na jakim porcie ma działać serwer (1180) oraz wykorzystywany protokół warstwy transportowej (UDP). Kolejna linie definiuje w jakim trybie pracuje serwer VPN. W prezentowanym przykładzie jest to tryb mostkowania (tap). Jest to tryb, w którym klient jest podłączony bezpośrednio do sieci LAN serwera. Podłączony 2 XVII Poznańskie Warsztaty Telekomunikacyjne

9 przygotowano bazę danych, w której zapisywane są dane klientów VPN, oraz dane wszystkich wygenerowanych kont VPN. Serwer bazy danych został zainstalowany i uruchomiony na tej samem maszynie, na której równolegle działa serwer VPN. Na rysunku 3 zaprezentowano stronę logowania klienta do systemu oraz stronę, na której podając własne dane można założyć konto systemowe. Rysunek 2. Plik konfiguracyjny serwera klient otrzymuje ten sam adres co pozostałe urządzenia podłączone do servera. Tryb mostkowania wymaga zestawienia mostka pomiędzy wirtualnym interfejsem OpenVPN (tap0), a interfejsem mającym dostęp do sieci LAN serwera. Linie 6-9 wzkazują na miejsce, gdzie zostały zapisane pliki certyfikujące dla serwera. Kolejne linie (12-13) określają w jakim trybie ma działać serwer (tryb mostkowania). Wewnętrzny adres IP serwera to , a klienci będą otrzymywali adresy z zakresu Wpisy w liniach określają dokładnie adresy sieci do jakich podłączony klient będzie miał dostęp. Ostatnimi ważnymi wpisami w pliku konfiguracyjnym są linie 26 oraz 27. Są to polecenia odpowiedzialne za dokonywanie wpisów w osobnych plikach logowania. Pliki te zawierają informacje o zalogowanych klientach oraz przechowują informacje o wcześniejszych logowaniach klientów. Przechowywane informacje pozwalają administratorowi zweryfikować, jazy klienci łączyli się łączyli się z serwerem VPN. Generowanie kont klienckich, pozwalających na zdalne łączenie się z serwerem VPN, nie należy do rzeczy łatwych. Szczególnie uciążliwe dla administratora było tworzenie kilkunastu kont jednorazowo, gdzie należy podawać nazwę każdego konta oraz podpisywać potrzebne ceftyfikaty. W celu ułatwienia procedury generowania konta, został zaprojektowany i utworzony specjalny system, który w znaczny sposób ułatwia ten proces. Do przygotowania działającego konta VPN, niezbędne są cztery pliki, z których trzy są plikami certyfikującymi klienta, a ostatni konfiguruje ustawienia klienta VPN. Wszystkie pliki mogą zostać utworzone przez kilenta z wykorzystaniem przygtowanego systemu. Potrzebne jest założenie własnego konta systemowego oraz zalogowanie się do systemu. Na potrzeby, wspomnianego wcześniej systemu, Rysunek 3. Strona logowania i tworzenia konta w systemie Po pomyślnej procedurze rejestracyjnej i weryfikacji danych przez administratora, badacz ma dostęp do wszystkich zasobów i możliwości systemu automatycznej generacji kont. Na rysunku 4 przedstawiono stronę główną systemu, na której umieszczono opis laboratorium oraz sprzętu znajdującego się w laboratorium badawczym. Przechodząc do odpowiedniej zakładni można znaleźć dane kontaktowe do administratora systemu, podejrzeć jakie konta istnieją, pobrać ponownie pliki konta VPN, usunąć własne konto VPN bądź wylogować się ze strony. Jedną z najważniejszych opcji, jaka była opisywana wcześniej, jest możliwość generowania własnych kont VPN. Jest to możliwe za pomocą formularza dostępnego w zakładce Załóż konto VPN. Rysunek 5 przedstawia formularz, który należy uzupełnić w celu wygenerowania odpowiedniego konta. Oprócz danych osobowych, niezbędne jest wybranie sieci do której użytkownik chce mieć dostęp. W celu zapewnienia bezpeiczeństwa oraz porządku w sieci laboratoryjnej, zdecydowano, że każde urządzenie, które jest osiągalne w zdalnym dostępie, działa w osobnej wewnętrznej sieci. Dla przykładu, jeśli użytkownik chce mieć dostęp do kart NetFPGA [10], musi wygenerować konto, które da mu możliwość dostępu do sieci /24. Po wypełnieniu formularza należy użyć przycisku Utwórz konto VPN aby otrzymać skonfigurowane konto. W tym czasie system uruchamia odpowiednie skrypty generujące pliki certyfikujące. Uruchamiany jest również specjalnie przygotowany program, pozwalający na wygenerowanie pliku konfiguracyjnego klienta VPN. Po pomyślnej pro- PWT Poznań - 13 grudnia

10 na ikonę aplikacji OpenVPN GUI, spowoduje pojawienie się dodatkowej mniejszej ikonki z prawej strony, dolnego paska narzędzi. Mniejsza ikonka pozwala na wybranie konta, które dany klient chce wykorzystać. Weryfikacją prawidłowego połączenia jest sprawdzenie tablicy routingu na komputerze klienckim. Przykład tablicy przedstawiono na rysunku 6. Rysunek 4. Główna strona automatycznego systemu generowania kont cedurze tworzenia konta VPN oraz podpisaniu odpowiednich certfikatów zostaje przygotowane nowe konto VPN, dające dostęp do serwera VPN działającego w laboratorium. Konto jest ważne przez pewien okres czasu, zależny od konfoguracji serwera. Jeśli czas ten upłynie, wówczas konto traci ważność i nie daje możliwości połączenia się z serwerem. Konto może zostać usunięte również przy pomocy systemu automatycznego tworzenia kont. Na stronie systemowej znajsuje się specjalna zakładka, która daje możliwość przeglądania istniejących już kont oraz ich usuwania przy pomocy odpowiedniego przycisku. Ta funkcja pozwala na usuwanie kont wykorzytywanych na zajęciach ze studentami. Jeśli konta zostały użyte na zajęciach, to w celach bezpieczeństwa mogą zostać usunięte przez administratora lub prowadzącego zajęcia, który wcześniej wygenerował konta dla studentów. Rysunek 5. Formularz tworzenia nowego konta VPN Łączenie z serwerem odbywa się przy pomocy specjalnej aplikacji o nazwie OpenVPN GUI wykorzystującej pliki konfiguracyjne aktywnych kont VPN. Po udanej procedurze instalacyjnej oprogramowania kliencikiego w systemie Windows, należy umieścić plik konfiguracyjny klienta oraz pliki certyfikujące w katalogu config, który znajduje się w drzewie katalogów oprogramowania OpenVPN GUI. Dwukrotne kliklięcie Rysunek 6. Przykład tablicy routingu klienta po połączeniu z serwerem VPN Jak można zauważyć, dodane zostały dwie trasy do sieci /24 oraz /24. Sieci te są osiągalne przez bramę, której adres IP jest tożsamy z adresem servera VPN. Brama jest osiągalna przez interfejs komputera klienciekiego o adresie Kolejne dwie sieci /24 oraz również są osiągalne przez server VPN oraz interfejs Dwie ostatnie sieci są sieciami z puli sieci Politechniki Poznańskiej. Dzięki łączeniu się z tymi sieciami przez server VPN, zapewniane jest bezpieczeństwo danych poprzez ich szyfrowanie. Wszystkie trasy są automatycznie dodawane po pomyślnym połączeniu z zerwerem VPN. To serwer poprzez swoją odpowiednią konfigurację wymusza dodatkowe wpisy w tablicy routingu klienta. Server VPN odpowiada również za utworzenie wirtualnego (programowego) interfejsu, na który kierowany jest cały ruch danych dedykowany do sieci związanych z serwerem VPN. VI. PODSUMOWANIE I DALSZE PRACE Przedstawione mechanizmy zostały uruchomione i przetestowane niezależnie (należy zwrócić uwagę, iż z powodu ogólnie pojętego bezpieczeństwa, publiczne adresy IP oraz nymery portów, jak i pewne wrażliwe informacje, zostały zmienione lub pominięte). Pierwszym wydarzeniem, podczas którego przygotowane mechanizmy zostały wykorzystane, były pięciodniowe warsztaty z programowania i wykorzystania kart NetFPGA [15], [16]. Odbyły się one w salach laboratoryjnych Wydziału Elektroniki i Telekomunikacji Politechniki Poznańskiej w maju 2013 roku, zostały one zorganizowane przy współpracy pracowników Katedry Sieci Telekomunikacyjnych oraz Computer Laboratory University of Cambridge [17]. Podczas przygotowań do nich instruktorzy z Cambridge mieli zdalny dostęp do wewnętrznej sieci IP i urządzeń znajdujących się w laboratorium. Dzięki temu mogli na bieżąco weryfikować konfigurację topologii podczas jej przygotowywania do zajęć laboratoryjnych. Również uczestnicy warsztatów, nocy mieli dostęp poprzez SSH oraz X- tunneling do maszyn, na których pracowali. Pozwalało im to przeprowadzać i nadzorować długotrwałe operacje symulacji, testów i syntezy przygotowywanych projektów. Łącznie z instruktorami, w szczytowym momencie w sieci było aktywnych 30 zdalnych użytkowników. Testy zaawansowanej 4 XVII Poznańskie Warsztaty Telekomunikacyjne

11 funkcjonalności zdalnego dostępu wykonywane są na bieżąco przez pracowników katedry, którzy są zarówno twórcami tego systemu, jak i jego pierwszymi użytkownikami. Takie podejście pozwala zweryfikować poprawność działania oraz na bieżąco rozbudowywać funkcjonalność systemu. Zdalny dostęp przedstawiony w niniejszym artykule jest regularnie wykorzystywany podczas zajęć laboratoryjnych ze studentami. Pozwala to zrealizować wiele praktycznych ćwiczeń i wykorzystać różnorodne mechanizmy sieciowe. Przy wykorzystaniu odpowiednio przygotowanych kont VPN niektórzy studenci mają nieograniczony czasowo dostęp do wybranych urządzeń laboratoryjnych w celu realizacji badań i eksperymentów przeprowadzanych na potrzeby ich prac dyplomowych. Wykorzystanie zdalnego dostępu zwalnia z obowiązku bezpośredniej obecności w laboratorium pracownika pilnującego studentów, natomiast samym studentom daje ogromną elastyczność w planowaniu własnych działań. Również pracownicy chętnie wykorzystują zdalny dostęp, gdyż pozwala on w pełni korzystać z laboratorium, a nie zmusza do fizycznej w nim obecności, co może być kłopotliwe, szczególnie w godzinach wieczornych i nocnych. VII. PODZIEKOWANIA Projekt został sfinansowany ze środków Narodowego Centrum Nauki przyznanych na podstawie decyzji numer DEC- 2011/01/B/ST7/03959 LITERATURA [1] Decision No. 1982/2006/Ec of the European Parliament and of the Council of 18 December 2006 concerning the Seventh Framework Programme of the European Community for research, technological development and demonstration activities ( ). December [2] TRILOGY2, Dostępne na stronie: [Stan z dnia: ]. [3] 4WARD, Dostępne na stronie: [Stan z dnia: ]. [4] GEYSERS, Dostępne na stronie: [Stan z dnia: ]. [5] AKARI, Dostępne na stronie: [Stan z dnia: ]. [6] GENI, Dostępne na stronie: [Stan z dnia: ]. [7] Strona projektu Inżynieria Internetu Przyszłości [Stan z dnia: ]. [8] Strona projektu Alien - Abstraction Layer For Implementation Of Extensions In Programmable Networks [Stan z dnia: ]. [9] Strona projektu Środowisko testowe protokołów sieciowych na bazie systemu OpenFlow [Stan z dnia: ]. [10] Główna strona poświęcona kartom NetFPGA [Stan z dnia: ]. [11] Strona produktu NP3 firmy EzChip - Network Processor ezchip.com/p_np3.htm [Stan z dnia: ]. [12] Strona produktu Spirent Test Center Spirent-TestCenter_Live [Stan z dnia: ]. [13] Główna strona Openvpn [Stan z dnia: ]. [14] Główna strona Openssl [15] Strona informacyja warsztatów NetFPGA [16] Wydarzenia organizowane w ramach projektu NetFPGA [Stan z dnia: ]. [17] Główna strona www Computer Laboratory, Faculty of Computer Science and Technology, University of Cambridge [Stan z dnia: ]. PWT Poznań - 13 grudnia

12 Karty NetFPGA w procesie dydaktycznym Marek Michalski Politechnika Poznańska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka 3, Poznań, imie.nazwisko@put.poznan.pl, Streszczenie W artykule przedstawiono karty NetFPGA. Sa to karty rozszerzeń do PC. Występuja w dwóch wersjach - z portami o przepustowości 1 Gbps oraz 10 Gbps. Ich funkcjonalność jest programowalna w bardzo szerokim zakresie, przykładowy kod jest dostępny na licencji BSD. Karty sa wykorzystywane zarówno do pracy w charakterze prototypowych urzadzeń sieciowych jak i otwartej platformy edukacyjnej. W artykule przedstawiono budowę kart, budowę i zasadę funkcjonowania zestawu oprogramowania typowych urzadzeń sieciowych zrealizowanych na kartach NetFPGA oraz sposób wykorzystania w dydaktyce. I. WPROWADZENIE Współczesny świat oczekuje szybkiej reakcji na swe potrzeby. Nie tylko wielkim korporacjom chodzi o szybkie wprowadzenie produktów na rynek, również naukowcy chcą jak nakrócej oczekiwać na odpowiedzi na swe pytania, jak najszybciej otrzymywać rezultaty swych badań, jak najszybciej realizować projekty. Nie chodzi tu wcale o realizację idei "czas to pieniądz", ale o możliwość jak najefektywniejszego wykorzystania czasu, który jest zasobem krytycznym. Współczesne technologie dają mozliwości, które kilka lat temu były w sferze science fiction. Przykładem techologii, na której skupię się w niniejszym artykule, są programowalne układy cyfrowe. Jednym z przedstawicieli szerokiej rodziny takich technologii są układy FPGA (ang. Field Programmable Gate Array). Współczesne układy FPGA oferują ogromne możliwości w wielu wymiarach - można w nich realizować rozbudowaną funkcjonalność logiczną, mogą posiadać w sobie dedykowane bloki różnego rodzaju układów specjalizowanych (przetwornik AC/CA, procesory, pamięci, rozmaite czujniki; np przyspieszenia, światła itp.). Są również bardzo szybkie. Bardzo ważną ich cechą jest możliwość wielokrotnego programowania bez utraty wydajności. Wszystkie te właściwości czynią z nich idealne układy do realizacj zadań protypowych, badawczych i naukowych. Odpowiednio przygotowany program może być wgrany do pojedynczego układu lub uruchomiony w wielu kopiach, dzięki temu ta technologia jest idealna zarówno do wykorzystania w przemyśle wielkiej skali oraz w pojedynczych urządzeniach. Karta NetFPGA jest bardzo dobrym przykładem, który wykorzystuje wszystkie wspomniane cechy charakterystyczne układów FPGA - jej główny układ to przedstawiciel właśnie tej technologii. II. OPIS KART NETFPGA 1G I 10G Karta NetFPGA jest produktem końcowym projektu Net- FPGA.org [1]. Został on założony przez grupę naukowców ze Stanford University [2] pod kierownictwem prof. Nicka McKeowna [3]. Aktualnie projekt jest prowadzony wspólnie z analogiczną grupą z University of Cambridge [4] pod Rysunek 1. Karta NetFPGA z elektrycznymi interfejsami sieciowymi RJ45 o przepustowości 1 Gbps kierownictwem Andrew W. Moore a [5]. Wszelkie informacje są dostępne na stronie projektu [1], są organizowane liczne wydarzenia promujące efekty prac grupy [6], ostatnio, w maju 2013, w Poznaniu odbyły się pięciodniowe warsztaty z programowania tych kart [7]. Na początku opracowana i udostępniona została karta Net- FPGA z portami o przepustowości 1 Gbps (przedstawiona na rys. 1) [8], od niedawna dostępna jest nowsza wersja z portami o przepustowości 10G (rys. 2). Aktualnie dostępne i szeroko używane są obie wersje kart NetFPGA. Obie są bardzo podobne, w przypadku każdej z nich mamy do czynienia z kartą rozszerzeń PC. Każda ma 4 porty ethernetowe, jednak, jak sugerują nazwy, mają porty o różnej maksymalnej przepustowości. W przypadku karty 1G do dysposycji są cztery porty elektryczne (RJ45), natomiast w przypadku karty 10G dostępne są 4 gniazda na wkładki SFP+. Różne są też magistrale, którymi łączą się z PC- są to odpowiednio PCI oraz PCIe. Ich wewnętrzna budowa, na pewnym poziomie abstrakcji, jest bardzo podobna. Karta 1G jest produkowana przez firmę Digilient [9], natomiast karta z portami 10G jest dostępna w ofercie firmy Hightech Global [10]. Obie wersje są osiągalne jako darowizny w ramach Xilinx University Program [11], którego nasza katedra jest beneficjentem - otrzymaliśmy pięć egzemplarzy karty z interfejsami 10G. Aktualnie nasza laboratoryjna sieć kart NetFPGA [12] składa się z 12 kart 1G i pięciu kart 10G oraz wielu dodatkowych urządzeń sieciowych, które umożliwiają 6 XVII Poznańskie Warsztaty Telekomunikacyjne

13 Rysunek 2. Karta NetFPGA z uniwersalnymi interfejsami sieciowymi SFP+ o przepustowości 10 Gbps im funkcjonowanie oraz tworzenie elastycznych topologii i wykorzystanie różnorodnych mechanizmów sieciowych. Platforma sprzętowa to jedno, równie istotne jest oprogramowanie tych kart, szczególnie, że praktycznie pełną funkcjonalność kart należy samemu zaprogramować. Na szczęście można skorzystać z udostępnionych przykładowych projektów referencyjnych. Są one dostępne zarówno jako kody źródłowe, jak i gotowe do uruchomienia pliki. Do kompilacji kodu źródłowego konieczne jest posiadanie rozbudowanego środowiska uruchomieniowego firmy Xilinx [13], pełne informacje o wymaganiach i sposobie konfiuguracji dostępne są na stronie projektu [1]. Zaprogramowanie karty NetFPGA to jeden z kroków koniecznych do jej wykorzystania. Karta może pracować samodzielnie, jednak aby mogła ona współdziałać z systemem operacyjnym komputera, należy zainstalować w nim odpowiedni sterownik. Jego kody źródłowe dostępne są w standardowym zestawie oprogramowania dla kart NetFPGA, należy go skompilować i uruchomić według dostarczonej procedury. Po poprawnym wykonaniu wszystkich wymaganych czynności interfejsy karty są widoczne w systemie jak standardowe interfejsy sieciowe, natomiast oprogramowanie do samej karty może być wgrane w zależności od wersji karty: w przypadku karty 1G - przez systemową magistralę PCI i dostarczony program (nf_download) lub w przypadku kart 10G - przez zewnętrzny programator USB i narzędzie z pakietu oprogramowania firmy Xilinx - program Impact. Poprawnie uruchomiona karta może być wykorzystywana jak zwykła karta sieciowa lub należy dla niej przygotować dodatkowe oprogramowanie, które jest specyficzne i zależne od realizowanych funkcjonalności. III. PRZEPŁYW DANYCH W ŚRODOWISKU NETFPGA Ramki ethernetowe odbierane są z fizycznych portów przez odpowiednie układy i umieszczane w postaci ciągu bitów w buforach wejściowych. Każdy port posiada swój bufor (na rysunku 3 oznaczone są jasnozielonym kolorem, na rysunku 4 dodatkowo podpisane są jako MAC0 - MAC3). Dane z ramek dzielone są na słowa o stałej długości, 64 bitowe słowa występują w całym projekcie karty NetFPGA 1G, natomiast w przypadku karty 10G długość słowa to 256 bitów. Zawartość poszczególnych słów i położenie w nich elementów ramki ethernetowej w przypadku karty NetFPGA 1G przedstawiono na rysunku 5. Należy zwrócić uwagę, że ramki wysyłane przez procesor do sieci, zanim przejdą przez kartę, są traktowane jak ramki do niej przychodzące i są umieszczane w jej buforach wejściowych powiązanych z procesorem. Te bufory zaznaczono na rysunku 3 kolorem jasnoniebieskim, natomiast na rysunku 4 dodatkowo podpisano jako CPU. Tym oto sposobem do karty wchodzi 8 strumieni danych, po cztery od strony portów fizycznych i po cztery od strony procesora. Z punktu widzenia przetwarzania danych są one równorzędne i mogą być traktowane jednorodnie lub unikatowo w zależności od zamierzeń programisty. Analogiczna sytuacja ma miejsce z buforami wyjściowymi - jeśli ramka ma być wysłana na port fizyczny - jest umieszczana w buforze wyjściowym powiązanym z odpowiednim portem (ciemnozielony port MAC), jeśli natomiast ma trafić do systemu operacyjnego - jest umieszczana w kolejce oznaczonej kolorem ciemnoniebieskim (CPU). Jak łatwo zauważyć, na rysunkach przyjęto konwencję, że bufory związane z portami fizycznymi są oznaczone kolorem zielonym, natomiast do procesora - niebieskim. Bufory na wejściu do karty oznaczono jasnym odcieniem odpowiedniego koloru, natomiast na wyjściu - ciemnym kolorem. Takie dodatkowe oznaczenie ułatwia studentom szybkie i intuicyjne odnalezienie się w środowisku karty NetFPGA. A. Obsługa ramki ethernetowej niosacej zapytanie ARP przez system z karta sieciowa NetFPGA Poniżej zostanie przeanalizowana procedura obsługi zapytania protokołu ARP w celu przedstawienia typowego sposobu obsługi ramki ethernetowej w karcie NetFPGA. Załóżmy, że do karty jest wgrane oprogramowanie, które czyni z niej typową kartę sieciową. Załóżmy również, że ramka niosąca zapytanie ARP została odebrana na porcie eth0. Zostanie więc ona umieszczona w buforze MAC0 na wejściu do karty (jasnozielony). Następnie moduł Input Arbiter w odpowiednim momencie wybierze z kolejki wejściowej tę ramkę do obsługi i przekaże ją domodułu Użytkownika i dalej do Output Port Lookup. Głównym zadaniem modułów w obrębie karty NetFP- GA jest przekazanie ramek na odpowiednie porty wyjściowe, przekazanie takie odbywa się przez ustawienie odpowiednich zmiennych sterujących oznaczających bufor wyjściowy. Na podstawie tych danych kolejny moduł (Output Queues) umieści ramkę w odpowiednim buforze wyjściowym. W tym przypadku funkcjonalność prorokołu ARP wymusza przekazanie tej ramki do systemu operacyjnego przez interfejs nf0, dlatego też ramka ta zostanie umieszczona w ciemnoniebieskim buforze na wyjściu, czyli w kolejce do nf0 (CPU0). W tym momencie ramkę przejmuje system operacyjny i odpowiedni proces sieciowy (o ile taki jest uruchomiony na danym komputerze) przeanalizuje zapytanie ARP i odpowiednio na nie zareaguje. Załóżmy, że analizowana ramka niesie zapytanie o adres MAC naszego komputera, więc, zgodnie z funkcjonalnością ARP, ten komputer odpowie na nią odpowiednim komunikatem ARP. Ten komunikat zostanie wygenerowany przez proces sieciowy w systemie operacyjnym i wysłany przez port nf0 do sieci. Wysłanie ramki przez interfejs nf0 polega na umiesz- PWT Poznań - 13 grudnia

14 eth0 eth1 eth2 eth3 Input Arbiter Moduł użytkownika Output Port Lookup Output Queues CPU 0 MAC 0 CPU 1 MAC 1 CPU 2 MAC 2 CPU 3 Input Arbiter - wybór obsługiwanej kolejki wejściowej Moduł użytkownika (dodany) MAC 3 Output Port Lookup ustalenie kolejki wyjściowej NetFPGA FPGA chip PCI/PCIe driver Output Queues - Rozdział na kolejki wyjściowe Operating System nf0 nf1 nf2 nf3 CPU 0 MAC 0 CPU 1 MAC 1 CPU 2 MAC 2 CPU 3 MAC 3 Rysunek 3. Najważniejsze elementy budowy karty NetFPGA Rysunek 4. Sposób organizacji przepływu danych w kartach NetFPGA 1G czeniu jej w buforze wejściowym do karty NetFPGA, w tym przypadku ramka do karty przychodzi od strony procesora (przez interfejs obecny w systemie operacyjnym), czyli będzie umieszczona w jasnoniebieskim (wejściowym) buforze oznaczonym jako CPU0. Moduł Input Arbiter odbierze tę ramkę, a kolejne moduły zadecydują o przesłaniu jej na port wyjściowy eth0, czyli umieszczą ją w ciemnozielonej kolejce wyjściowej MAC0, stamtąd odpowiednie mechanizmy ją odczytająiwyślą do łącza przez port eth0. Obsługa ramek (podstawowa wersja) w głównej kości FPGA karty NetFPGA polega na przyjęciu ramki do kolejki na wejściu, zadecydowaniu o przeznaczeniu danej ramki, odpowiednim jego oznaczeniu i umieszczeniu ramki w odpowiedniej kolejce wyjściowej. Powyższy przykład przedstawił obsługę ramki przy współudziale procesora komputera i systemu operacyjnego, taka ramka przeszła przez kartę dwa razy. O wiele ciekawsza jest sytuacja, gdy do obsługi ramki wystarczy funkcjonalność zakodowana w kości FPGA i nie jest konieczna interakcja z systemem operacyjnym. Gdy karta samodzielnie obsługuje ruch, wydajność przetwarzania danych jest o wiele wyższa, gdyż pomijane jest dwukrotne przejście danych przez magistralę i obsługa przez procesor. Typowa taka sytuacja przedstawiona zostanie w kolejnym podrozdziale. B. Obsługa ramki ethernetowej przez przełacznik zrealizowany na karcie NetFPGA Załóżmy, że do karty NetFPGA zostało wgrane oprogramowanie pozwalające jej pracować jako przełącznik sieci Ethernet. Charakterystyczną cechą takiego przełącznika jest to, że potrafi on rozpoznać położenie adresata ramki (port, do którego jest on podłączony) i ograniczyć rozgłaszanie ruchu tylko do segmentów, w których znajduje się adresat ramek. Decyzję o porcie docelowym przełącznik podejmuje na podstawie zawartości swej tablic wiążącej adresy MAC i numery portów, natomiast jej zawartość to efekt analizy ruchu przychodzącego (a dokładnie adresów MAC nadawcy ramek) na konkretnych portach (ten mechanizm bywa określany jako proces uczenia się przełącznika). Jeśli do karty NetFPGA przygodzi ramka ethernetowa (załóżmy, że na port eth3), jest ona umieszczana w buforze wejściowym MAC3. Gdy najdejdzie jej kolej, jest ona pobierana do obsługi przez Input Arbiter i przekazywana do dalszej analizy. W tym przypadku analiza ramki przez przełącznik sieciowy (karta NetFPGA pracuje jako przełącznik) sprowadza się do dwóch głównych czynności: 1) przełącznik uczy się, że nadawca tej ramki (host o adresie MAC takim jak MAC źródłowy) jest podłączony do portu eth3 (gdyż to właśnie z tego portu przyszła od niego ramka); 2) przełącznik wysyła ramkę na port, na którym (wg jego aktualnej wiedzy) jest podłączony adresat tej ramki (host, o adresie MAC obecnym w ramce w polu MAC docelowy), przy czym, jeśli zna położenie adresata, to ramka jest wysyłana na jeden konkretny port, a jeśli nie ma wiedzy o położeniu adresata ramki, taka ramka jest rozgłaszana na wszystkie porty poza tym, z którego przyszła. W tym momencie porty wyjściowe dla ramki są wybrane (są to porty związane z fizycznymi interfejsami, czyli mogą tobyć MAC0, MAC1 lub MAC2 - MAC3 odpada, bo portem eth3 ta ramka przyszła) i ramka może być umieszczona w docelowych kolejkach wyjściowych (ciemnozielonych) i przesłana na zewnątrz karty. Całe zadanie karty (pracującej jako przełącznik sieci Ethernet) zostało w pełni zrealizowane. Należy zwrócić uwagę, że ramka weszła do karty i wyszła z niej bez udziału proceosora i systemu operacyjnego. To właśnie takie podejście stanowi wartość kart NetFPGA - w pełni sprzętowe przetwarzanie danych. 8 XVII Poznańskie Warsztaty Telekomunikacyjne

15 Rysunek 5. Położenie poszczególnych elementów ramki ethernetowej w jednostkach danych w karcie NetFPGA IV. OPIS PRZYKŁADOWYCH PROJEKTÓW Jednym z elementów pakietu instalacyjnego są kody przykładowych projektów. Są one w pełni kompletne, można je wykorzystać zarówno przez samodzielne skompilowanie dostarczonego kodu źródłowego bądź też użycie dostarczonego pliku bit. Poniżej zostaną omówione trzy projekty typowych urządzeń sieciowych (karta sieciowa, przełącznik oraz router) oraz projekt będący praktycznym ćwiczeniem w przygotowywaniu własnej aplikacji na kartę NetFPGA. A. Reference NIC Nazwa NIC pochodzi z angielskiego akronimu Network Interface Card. Poprawnie zainstalowania w systemie operacyjnym karta sieciowa występuje w dwóch postaciach. Pierwsza z nich to jej reprezentacja w uruchomionym oprogramowaniu komputera. Dzięki odpowiedniemu sterownikowi każdy port jest widoczny w systemie jako aktywny interfejs w sieciowy. Druga postać karty to jej fizyczna realizacja, czyli fizyczne porty (np. gniazda RJ45), do których mogą być podłączone przewody sieci Ethernet. Zadaniem karty jest odbieranie przychodzących ramek ethernetowych z portów fizycznych i przekazywanie ich do reprezentacji tych portów w systemie operacyjnym oraz odbieranie ramek wychodzących przez inferfejsy reprezentowane w systemie operacyjnym i wysyłanie ich przez porty fizyczne. Ramka odebrana na porcie ethx będzie przesłana do portu nfx, natomiast ramka wygenerowana przez system operacyjny na porcie nfy będzie wysłana do sieci przez port ethy. Te operacje bardzo łatwo można zobrazować na przykładzie rysunku 3. B. Reference switch Jednym z dostarczonych przykładowych projektów na kartę NetFPGA jest Reference switch, czyli kod przełącznika sieci Ethernet. Podstawowe działanie takiego przełącznika polega na odbieraniu ramek i przesyłaniu ich na wybrane porty, jego szczegóły przedstawiono w poprzednim rozdziale. Wśród dostępnych kodów źródłowych jest kod programu, który pozwala analizować zawartość tablicy przełącznika oraz zbierać statystyki ruchu do poszczególnych adresatów (adresów MAC). Bardzo cennym z punktu widzenia dydaktyki elementem tego kodu jest dostarczenie i przykładowe wykorzystanie pamięci TCAM (Ternary Content Addressable Memory). C. Reference router Ruter IP ma dwa główne zadania: określić adres następnego skoku (interfejs wyjściowy) oraz dokonać przełączenia (przesłania) pakietu na wybrany interfejs. Realizacja przełączenia odbywa się na zasadzie analogicznej jak w przypadku przełącznika - na podstawie odpowiednich bitów w słowie sterującym ramka ethernetowa z pakietem IP jest umieszczana w kolejce powiązanej odpowiednim portem wyjściowym. Należy pamiętać o wykonaniu operacji typowych dla rutingu (zmiana TTL) oraz przejściu do innego segmentu drugiej warstwy (czyli zmiana adresu MAC źródłowego na adres interfejsu wychodzącego i ustawienie adresu MAC docelowego na adres interfejsu przychodzącego w sąsiednim węźle). D. Crypto NIC Crypto_NIC to rozszerzona wersja reference NIC. Rozszerzenie polega na dodaniu jednego modułu do pipeline. Jest to moduł Crypto_NIC. Jego zadaniem jest szyfrowania i deszyfrowanie danych wychodzących i przychodzących. Zarówno szyfrowanie jak i deszyfrowanie polega na wykonaniu operacji XOR na danych i kluczu. Z uwagi na odwracalność operacji XOR, operacja szyfrowania i deszyfrowania jest realizowana tak samo. V. ELEMENTY PROJEKTU Twórcy środowiska do programowania kart NetFPGA wykonali ogromną pracę uruchamiając je i przygotowując demonstracyjne projekty. Na ich podstawie można przygotować projekty własnych urządzeń sieciowych. Można samodzielnie zaprojektować całe rozwiązanie, ale bez wątpienia warto skorzystać z dostarczonych szkieletów projektów. Każdy projekt powinien posiadać bufory wejściowe i wyjściowe (rysunek 4), standardowe elementy sterowania przetwarzaniem danych (Input Arbiter,Output Port Lookup, Output Queues) oraz własną funkcjonalność. Dzięki modułowości kodu wystarczy w odpowiednim miejscu dodać własny moduł, który odpowiednio wpasuje się w strukturę kodu i zapewni pożądaną funkcjonalność. Kod źródłowy na projekt karty obejmuje bardzo dużo plików, ale podstawowe wykorzystanie nie wymaga ich znajomości, a tym bardziej modyfikacji. Projekt NetFPGA od samego początku miał charakter dydaktyczny i wiele mechanizmów zostało tak zaprojektowanych, aby użytkownik nie musiał ich modyfikować. VI. MECHANIZMY PRZYGOTOWANIA I WERYFIKOWANIA POPRAWNOŚCI PROJEKTU A. Przygotowanie projektu Jak wspomniano wcześniej, możliwe jest całkowicie samodzielne przygotwanie oprogramowania karty NetFPGA. Jednak wymaga to dużo czasu, a przede wszystkim, ogromnej wiedzy i doświadczenia. Dlatego też nawet doświadczeni deweloperzy chętnie korzystają z wzorców dostarczonych przez twórców kart NetFPGA. W takim przypadku przygotowanie PWT Poznań - 13 grudnia

16 własnego projektu sprowadza się do dodania pustego własnego modułu i zaprogramowania jego funkcjonalności. Takie podejście wydaje się dużo prostsze. I takie jest. Ale prostsze nie oznacza proste. Nadal należy pamiętać o wielu rzeczach: o odpowiedniej interakcji z innymi modułami, o zachowaniu odpowiedniej konwencji nazewnictwa zmiennych (aby nie doprowadzić do konfliktu nazw), o zaimplementowaniu poprawnego sterowania itp. Własny moduł należy zdefiniować w Verilogu, jego definicję umieścić w odpowiednim miejscu w drzewie plików projektu, powiązać go z innymi modułami oraz uzupełnić informację o powiązaniach z nim w pliku projektu. Czynności, które należy wykonać mogą się nieco różnić w zależności od wersji kodu, z którą pracujemy. Na stronie projektu są dostępne opisy poszczególnych etapów, najwięcej praktycznej wiedzy z tego zakresu można zdobyć podczas warsztatów z programownia tych kart [6], [7]. Bardzo często jest tak, że kod naszego projektu wymaga fragmentów, które objęte są zewnętrzną licencją (np. IP Core, TMAC, itp). Co więcej, kod źródłowy, który wystarczy do kompilacji, nie stanowi całości poprawnego projektu. Aby być pewnym poprawności projektu należy przygotować również pliku testów, które pozwolą automatycznie zweyryfikować poprawność projektu. B. Testowanie Analiza funkcjonalności nawet podstawowych projektów na kartę NetFPGA jest bardzo złożona. Aby ją ułatwić, a wręcz umożliwość i urealnić, opracowano mechanizm testów. Polega on na wygenerowaniu testowego ruchu (przy pomocy bibloteki Scapy napisanej w Perlu) i przepuszczeniu go przez symulator (ModelSim [14] lub ISim [15]). Każda funkcjonalność powinna być testowana pojedynczo, tzn. należy przygotować bardzo dużo testów, przy czym każdy test skupia się na pojedynczym mechanizmie, a jego wynik jest dwuwartościowy - PASS lub FAIL. Nawet wykonanie wszystkich testów z wynikiem pozytywnym nie oznacza poprawności całego projektu, gdyż nie ma pewności, że przygotowane testy pokrywają wszystkie funkcjonalności. Niestety, nawet jeden wynik negatywny oznacza niepoprawność i konieczność poprawiania kodu źródłowego. Należy zwrócić uwagę, że błędy mogą być zarówno w kodzie projektu, jak i w kodzie testów. Niestety, możliwe są wyniki fałszywie pozytywne oraz fałszywie negatywne. Jak widać, testowanie projektów jest bardzo złożonym, żmudnym i pracochłonnym procesem, ale i bardzo potrzebnym. Testowanie sprowadza się do przygotowania pierwotnej reprezentacji ruchu ethernetowego (ramek) dla każdego portu, które będą wysyłane do symulatora działania kodu oraz reprezentacji ruchu, który spodziewamy się otrzymać na poszczególnych portach. Ruch pierwotny jest wysyłany do symulatora, a to co z niego wyjdzie jest porównywane z ruchem spodziewanym. Porównanie może dać wynik pełnej zgodności (wówczas test jest zaliczany) lub nie (wówczas test nie jest zaliczany). Przykładowe testowanie kodu karty sieciowej sprowadza się do przygotowania zawartości testowej ramki ethernetowej (jako tablicy bajtów) i wysłanie jej na port np. eth0. W Rysunek 6. Kod w języky Python - fragment odpowiedzialny za testowanie karty sieciowej - przygowanie pakietu, wysłanie go na cztery interfejsy i oczekiwanie na jego niezmodyfikowaną kopię na czterech wyjściach przypadku karty sieciowej dokładnie te same dane (bez modyfikacji) są oczekiwane na wyjściu bufora CPU0. W przypadku testowania przełącznika należy zwrócić uwagę na stan jego pamięci (tablicy MAC) i numery portów, na których pojawia się ruch po przejściu przez symulator. Błędy mogą polegać na tym, że ramki po przejściu przez symulator będą inne niż spodziewane, że ramki nie dotrą do portów, na których ich się spodziewamy lub też ramki pojawią się na portach, na których ich nie oczekujemy. W przypadku testowania rutera należy zwrócić uwagę na poprawność adresów IP oraz oczekiwać zmienionego pakietu IP ze zmniejszoną wartością TTL oraz zmienionymi adresami warstwy 2 (MAC). Fragment przykładowego kodu do testowania funkcjonalnosci karty sieciowej przedstawiono na rysunku 6. Definicja testu zawiera dokładny opis sytuacji na wejściu i na wyjściu. Symulator generuje rezultaty po przejściu przez zaprogramowaną funckcjonalność, a następnie mechanizm testów porównuje opis sytuacji wygenerowanej przez sumulator z opisem spodziewanej sytuacji zadeklarowanym testach. Pełna zgodność oznacza zaliczenie testu, choć jedna rozbieżność powoduje niezaliczenie testu. Takie podejście pozwala zautomatyzować testy. Mechanizm można opisywać bardzo szeroko, ale nie jest to głównym celem tego artykułu. Możliwa jest również analiza sytuacji wewnątrz poszczególnych modułów. Do tego celu wykorzystywane jest odpowiednie oprogramowanie (ModelSim lub ISim). Fragmentu przykładowego widoku okna programu ModelSim podczas analizy w trybie graficznym przedstawiono na rysunku 7. Warto zwrócić uwagę, że w przedstawionym przykładzie pojawiają się parametry (dwa adresy MAC, EthType) ustawione w kodzie z rysunku 6. C. Przygotowanie kodu uruchomieniowego Gdy wszyskie przeprowadzone testy pozwolą założyć, że przygotowany kod jest poprawny, można przystąpić do syntezy. Jest to proces wieloetapowy i bardzo złożony. Bardzo często zajmuje ponad godzinę nawet na współcześnie wydajnych komputerach. Dlatego też istotne jest, aby syntezie poddawać wyłącznie przetestowane projekty. Efektem poprawnie zakończonej syntezy jest plik z rozszerzeniem bit, który można wgrać do karty NetFPGA i uruchomić własny projekt. Do sterowania takim projektem można użyć dodatkowego oprogramowania, które otczytuje i ustawia wartość odpowiednich rejestrów w karcie NetFPGA. 10 XVII Poznańskie Warsztaty Telekomunikacyjne

17 Rysunek 7. Graficzne przedstawienie efektów pracy symulatora (fragment okna Wave programu ModelSim) VII. WYKORZYSTANIA KART W PROCESIE DYDAKTYCZNYM Pierwsza styczność studentów z kartami sprowadza się do teoretycznego wykładu na ich temat. Następnie demonstrowany jest przebieg przygotowania przykładowego oraz własnego projektu. Podkreślone są czynności, których nie można pominąć. Podczas laboratorium studenci pracują na odpowiednio przygotowanych maszynach virtualnych, które zostały przygotowane tak, aby skupić się na najważniejszych elementach. Pliki maszyn wirutalnych są udostępnianie zainteresowanym studentom, dzięki temu samodzielnie mogą poszerzać doświadczenie i ugruntowywać wiedzę zdobytą na zajęciach. Do pełnego wykorzystania narzędzi konieczne są licencje, które udostępniane są w ramach programu Europractice [16]. Dzięki odpowiednim połączeniom VPN studenci mogą na nich pracować również w domu. Podczas zajęć studenci dogłębnie poznają budowę sprzętu sieciowego, a także towarzyszącego jemu oprogramowania (sterowniki), w praktyczny sposób spotykają się również z profesjonalnym oprogramowaniem szeroko wykorzystywanym na skalę przemysłową. VIII. PODSUMOWANIE Karta NetFPGA, zarówno w wersji z portami 1G i 10G, jest wszechstronnym narzędniem badawczym, naukowym oraz edukacyjnym. Dzięki niej można realizować między innymi prototypowe urządzenia sieciowe realizujące niestandardowe protokoły sieciowe. Dzięki otwaremu kodowi źródłowemu, zarówno dla części sprzętowej jaki i sterownika programowego, stanowi ona nieocenioną pomoc dydaktyczną, szczególnie tak bliską rzeczywistym urządzeniom sieciowym. IX. PODZIEKOWANIA Projekt został sfinansowany ze środków Narodowego Centrum Nauki przyznanych na podstawie decyzji numer DEC- 2011/01/B/ST7/03959 LITERATURA [1] Główna strona projektu NetFPGA [2] Strona informacyjna grupy NetFPGA [3] Strona informacyjna - Nick McKeown [4] Główna strona www Computer Laboratory, Faculty of Computer Science and Technology, University of Cambridge [5] Strona informacyjna - Andrew W. Moore [6] Wydarzenia w ramach projektu NetFPGA [7] Strona informacyja warsztatów NetFPGA [8] Glen Gibb, John W. Lockwood, Jad Naous, Paul Hartke, and Nick McKeown NetFPGA Open Platform for Teaching How to Build Gigabitrate Network Switches and Routers IEEE Trans. on Education, [9] Strona produktu NetFPGA 1G Detail.cfm?Prod=NETFPGA. [10] Strona produktu NetFPGA 10G PCIExpress_SFP+.htm. [11] Xilinx University Program [12] Strona projektu Środowisko testowe protokołów sieciowych na bazie systemu OpenFlow [13] Główna strona www firmy Xilinx [14] ModelSim - strona produktu [15] ISim - strona produktu [16] EUROPRACTICE Software Service PWT Poznań - 13 grudnia

18 Wykorzystanie symulatora NS-3 w dydaktyce - ilustracja działania sieci typu mesh Przemysław Kurylak, Katarzyna Wasielewska, Andrzej Borys Streszczenie W artykule zostały przedstawione wyniki przeprowadzonych badań mających na celu rozpoznanie możliwości, jakie dają symulacje wykonywane przy pomocy symulatora sieci NS-3 w ilustracji działania różnych sieci telekomunikacyjnych omawianych na zajęciach ze studentami. Przy czym tutaj skoncentrowano się na przykładach symulacji ruchu w sieciach kratowych (tj. typu MESH). Szczegółowo przeanalizowano wyniki symulacji trzech przykładowych, prostych sieci kratowych, objaśniając na ich podstawie funkcjonowanie protokołów komunikacyjnych w tych sieciach. Na koniec przedstawiono propozycję studenckiego ćwiczenia laboratoryjnego dotyczącego sieci MESH, bazującego na symulacjach z wykorzystaniem symulatora NS-3. Słowa kluczowe - sieci kratowe, sieci mesh, symulator NS-3 B I. WSTĘP EZPRZEWODOWE sieci kratowe (ang. mesh networks, MESH) to technologia umożliwiająca budowę sieci komputerowych w oparciu o samoorganizujące się urządzenia mobilne [1]. Do obsługi sieci kratowych zaprojektowano dedykowane protokoły, ponieważ klasyczne protokoły komunikacyjne stosowane w sieciach kablowych nie sprawdzają się w takich strukturach. Tematyka sieci MESH zawarta jest w programie studiów inżynierskich na kierunku Informatyka. W niniejszym artykule zaprezentowano ćwiczenia umożliwiające symulację działania sieci MESH podczas zajęć laboratoryjnych. W tym celu wykorzystano symulator NS-3. Wszystkie skrypty zostały omówione i przetestowane w ramach realizacji pracy dyplomowej [2]. W pracach inżynierskich w PWSZ w Elblągu symulator NS-3 został wykorzystany również do symulacji innych typów technologii i zagadnień z dziedziny sieci IP ([3], [4], [5]). Opierając się na symulacjach za pomocą symulatora NS-3, można opracować wiele ciekawych studenckich ćwiczeń laboratoryjnych do laboratorium z sieci teleinformatycznych. Instalacja symulatora NS-3 (a także jego poprzednika NS-2) na komputerze pracującym pod systemem operacyjnym Windows (np. NT, XP, czy 2000) nie jest banalna i oczywista. Środowisko instalacyjne NS-3 jest wieloelementowe i złożone, każdy szczegół jest istotny i jego wdrożenie może sprawić wiele kłopotów. Proces jego instalacji został szczegó- P. Kurylak jest absolwentem Instytutu Informatyki Stosowanej Państwowej Wyższej Szkoły Zawodowej w Elblągu, ul. Wojska Polskiego 1, Elbląg ( pkurylak@wp.pl). K. Wasielewska i A. Borys są pracownikami Instytutu Informatyki Stosowanej Państwowej Wyższej Szkoły Zawodowej w Elblągu, ul. Wojska Polskiego 1, Elbląg ( k.wasielewska@pwsz.elblag.pl). łowo opisany w pracy dyplomowej jednego ze współautorów tego artykułu [2]. W rozdziale II zaprezentowano podstawowe architektury, w których pracują sieci typu MESH oraz omówiono sposób realizacji procesów routingu. W rozdziale III zaprezentowano przykładowe scenariusze symulacyjne. Scenariusz prostego ćwiczenia laboratoryjnego omówiono w rozdziale IV, a podsumowanie zawarto w rozdziale V. II. SIECI TYPU MESH Poniżej omówiono architektury, protokoły komunikacyjne oraz inne zagadnienia i problemy występujące w sieciach typu MESH, które mogą być przedmiotem eksperymentów symulacyjnych z wykorzystaniem symulatora NS-3. A. Architektury sieci MESH W sieciach kratowych wyróżnia się trzy typy architektur [1]: - hierarchiczną, w której urządzenia łączone są w grupy zwane klastrami. W klastrach zaś można wyróżnić trzy rodzaje urządzeń [1]: 1. główne (ang. cluster-head nodes) - wybierane na podstawie kilku statystyk, takich jak np. siła nadawania, mobilność. Spełniają one podobne zadania jak punkty dostępowe, tzn. każde urządzenie w danym klastrze może połączyć się ze swoim urządzeniem głównym; 2. bramy (ang. gateway nodes) - zapewniają połączenia pomiędzy klastrami; mogą łączyć się równocześnie z kilkoma urządzeniami głównymi, dzięki czemu istnieje kilka możliwych ścieżek do danej bramy; 3. członkowskie (ang. cluster-member nodes) są to podstawowe urządzenia w klastrze. Pakiet przesyłany z jednego klastra do drugiego musi przebyć drogę z urządzenia członkowskiego do urządzenia głównego, które przesyła go dalej do bramy. Brama zaś przesyła pakiet do następnego urządzenia głównego, i tak dalej, aż dotrze on do urządzenia członkowskiego w klastrze docelowym. - płaską nazywana jest tak ze względu na brak jakiegokolwiek grupowania w niej urządzeń; wszystkie składające się na nią urządzenia spełniają te same funkcje, tzn. spełniają funkcje samokonfigurujących się routerów i jednocześnie są urządzeniami końcowymi. Połączenia w tej sieci są nawiązywane pomiędzy urządzeniami znajdującymi się na tyle blisko, aby zapewnić łączność. Pakiety przesyłane są z jednego urządzenia do drugiego, aż dotrą do urządzenia docelowego. - hybrydową stanowi ona połączenie dwóch poprzednich. 12 XVII Poznańskie Warsztaty Telekomunikacyjne

19 B. Routing w sieciach MESH Opracowanie sprawnych algorytmów routingu dla sieci kratowych zawsze sprawiało kłopoty. Powody występowania problemów z poprawnym działaniem protokołów komunikacyjnych implementowanych w sieciach typu MESH są następujące [1]: Częste zmiany topologii sieci sieci kratowe w porównaniu z innymi sieciami podlegają częstszym i bardziej radykalnym zmianom topologii; można zatem powiedzieć, że zachowują się bardziej dynamiczne. W związku z tym wymagają użycia protokołów komunikacyjnych wykrywających wszelkie zmiany w topologii w jak najkrótszym czasie - dzięki temu zapewnia się w nich szybkie wyznaczenie nowej trasy oraz zachowanie nawiązanych sesji lub uniknięcie zbyt dużej utraty nadawanych pakietów. Brak gwarancji, że dany pakiet zostanie dostarczony do miejsca docelowego. Połączenia mogą okazać się jednokierunkowe, tzn. stacja A może nawiązać połączenie z stacją B, ale stacja B nie może nawiązać połączenia ze stacją A. Jest to szczególnie kłopotliwe przy sesjach wymagających potwierdzenia odbioru. Techniczne ograniczenia urządzeń głównie ograniczona moc baterii, ograniczona szerokość pasma nadawczego, wolny zegar CPU. Opracowano wiele protokołów routingu przeznaczonych dla sieci typu MESH. Można je podzielić na następujące kategorie [1]: Protokoły routingu oparte o topologię w tym przypadku wyróżnia się ich trzy rodzaje: Protokoły proaktywne (tabelkowe) wykorzystuje się w nich tzw. tabele routingu. Polega to na tym, że każdy węzeł w sieci aktualizuje w sposób ciągły swój stan i określa możliwe drogi dla pakietów. Zatem w momencie, w którym ma przekazać dany pakiet dalej, nie traci czasu na wyliczanie dla niego drogi te dane ma już gotowe. W protokołach proaktywnych ww. tabele są tworzone za pomocą algorytmów stanu łącza lub algorytmów wektora odległości. Takie podejście do operacji routingu jest dobrze znane w klasycznych sieciach przewodowych. Jednakże w sieciach kratowych znajdowanie ścieżek w powyższy sposób ma wiele wad. Dwie największe to: duży pobór energii oraz, ze względu na dużą dynamikę sieci, generowanie sztucznego ruchu przy ciągłych aktualizacjach tabel routingu. Protokoły reaktywne (na żądanie) w tych protokołach zrezygnowano z tworzenia tabel routingu. Zamiast tego droga, którą ma być przekazany pakiet, jest określana w momencie, gdy pojawia się taka potrzeba. Urządzenie mające pakiet do wysłania najpierw wysyła zapytanie do wszystkich urządzeń, z którymi jest połączone, one przekazują je w identyczny sposób dalej, aż do momentu dotarcia pakietu do urządzenia docelowego. Urządzenie docelowe wysyła odpowiedź, która wraca do urządzenia nadawczego. Urządzenie docelowe może otrzymać zapytanie z kilku możliwych tras i tymi samymi trasami może na nie odpowiedzieć. Urządzenie nadawcze wybiera najlepszą trasę, po czym wysyła pakiet. Jeżeli w trakcie wysyłania połączenie zostanie zerwane, urządzenie nadawcze wybiera następną trasę. Po przesłaniu pakietu informacje o ścieżce zostają usunięte. Protokoły działające na tej zasadzie są wykorzystywane głównie w dużych sieciach kratowych. Główną wadą tego typu protokołów jest duże opóźnienie przy tworzeniu trasy z urządzenia nadawczego do docelowego. Protokoły hybrydowe w tym przypadku w różnym stopniu i w zależności od potrzeb łączone są protokoły proaktywne i reaktywne [1]. Protokoły routingu oparte o wyznaczone położenie geograficzne urządzeń. Pozycję geograficzną urządzeń można ustalić za pomocą: Systemu GPS główną wadą urządzeń z nadajnikami GPS jest duży pobór mocy, przez co wymagają częstszych wymian baterii. Siły sygnału jak wiadomo, im bardziej oddalony jest nadajnik, tym słabszy odebrany od niego sygnał. Pomimo dość dużych błędów pomiarowych w tej metodzie, jest to najtańszy sposób ustalania pozycji urządzeń. Czasu przybycia w tym przypadku protokoły dokonują estymacji odległości od urządzenia na podstawie pomierzonego czasu transmisji sygnału, uwzględniającego opóźnienie propagacyjne. Kąta przybycia korzystając z tej wielkości nie da się ustalić dokładnej pozycji urządzenia, ale dostarcza ona informacji o kierunku, z którego dochodzi sygnał. III. PRZYKŁADOWE SCENARIUSZE SYMULACJI SIECI MESH IICH ANALIZA NS-3 jest symulatorem sieci stworzonym do prowadzenia prac badawczych oraz dla celów edukacyjnych z zakresu teleinformatyki w szkołach wyższych. Jest to oprogramowanie na licencji GNU GPLv2 i wymaga podstawowej znajomości dwóch języków programowania: C++ oraz PYTHON. A. Kompilacja oraz uruchamianie skryptów Gotowe skrypty można kompilować oraz uruchamiać za pomocą dowolnego kompilatora. Jednak, aby uniknąć niepotrzebnych komplikacji, zaleca się używanie kompilatora dostarczonego razem z symulatorem. Wszystkie nowe skrypty najlepiej kopiować do folderu../ns-3-dev/scratch. Do kompilacji oraz wykrycia ewentualnych błędów składniowych należy używać komendy./waf, podczas gdy skompilowane programy należy uruchamiać za pomocą komendy./waf run nazwa_skryptu. Jeżeli w skrypcie przewidziano możliwość podawania nowych wartości parametrów, to robi się to za pomocą komendy:./waf run ''nazwa_skryptu -parametr = wartość. B. Uruchamianie skryptów i analiza wyników Skrypty wykorzystane do symulacji przedstawionych w tym podrozdziale są gotowymi skryptami załączonymi do pakietu symulatora NS-3; tutaj zostały one jednakże dostosowane do naszych scenariuszy symulacyjnych. Ich kody są podane w katalogu ns 3- dev/src [4]. Nazwy skryptów zostały przez nas zmienione. Powodem tego jest fakt, że jeżeli skrypt przykładowy oraz skrypt znajdujący się w folderze scratch mają identyczną nazwę, to w takim przypadku zostaje uruchomiony skrypt przykładowy, a nie ten zmodyfikowany. Zdecydowano się użyć gotowych skryptów z kilku powodów: PWT Poznań - 13 grudnia

20 Skrypty te są napisane w jak najprostszy oraz jak najbardziej przejrzysty sposób, dzięki czemu są idealne do nauki oraz analizy wygenerowanego w nich ruchu. Przykładowe skrypty dołączane razem z symulatorem są aktualizowane razem z nim, dzięki czemu nie traci się czasu na aktualizację samemu tych skryptów do najnowszych bibliotek NS-3. Powyższe skrypty często służą jako baza i wzór do pisania bardziej skomplikowanych. Wszystkie ww. skrypty generują pliki z rozszerzeniem.pcap, a tego rodzaju pliki bardzo dobrze dają się analizować przy pomocy oprogramowania ogólnodostępnego pod nazwą Wireshark [5]. W jednym z ww. skryptów symulowana jest sieć kratowa oparta na protokole HWMP (ang. Hybrid Wireless Mesh Protocol), podczas gdy dwa pozostałe wykorzystują protokoły OLSR (ang. Optimized Link State Routing Protocol) oraz AODV (ang. Ad hoc On-Demand Distance Vector). Pomimo iż te dwa ostatnie skrypty de facto nie symulują sieci kratowych, to za ich pomocą można doskonale prześledzić sposób działania protokołów, które są również wykorzystywane w sieciach typu MESH. Wyżej wymienione protokoły należą do różnych rodzajów protokołów routingu opartych o topologię (opisanych w punkcie 2.2 powyżej). Wszystkie skrypty posiadają licencję GNU. B.1. Skrypt mesh1.cc Skrypt mesh1.cc służy do symulacji sieci kratowych; wykorzystuje się w nim protokół komunikacyjny HWMP, który zgodnie ze standardem IEEE s jest głównym protokołem sieci typu MESH. Należy on do grupy hybrydowych protokołów routingu opartych o topologię; bazuje na protokole AODV. W tym protokole każde urządzenie śledzi urządzenia sąsiadujące i na tej podstawie aktualizuje tablice routingu. W sieciach opartych na protokole HWMP nie występują adresy IP, do routingu wykorzystywane są adresy MAC. Największy ruch jest generowany na samym początku pracy skryptu. TABELA I LICZBA PAKIETÓW PRZESYŁANYCH PRZEZ URZĄDZENIA Czas U1 U2 U3 U4 U5 U6 U7 U8 U Rys. 2. Liczba pakietów przesyłanych przez urządzenia TABELA II LICZBA PAKIETÓW PRZESYŁANYCH PRZEZ URZĄDZENIA Czas U1 U2 U3 U4 U5 U6 U7 U8 U Rys. 1. Topologia sieci w skrypcie mesh1.cc Topologię sieci kratowej zapisaną w skrypcie mesh1.cc przedstawia rys. 1. W omawianym tutaj przykładzie symulacji z wykorzystaniem tego skryptu z urządzenia nr 1 (U1) za pomocą UDP ping nawiązano połączenie z urządzeniem nr 9 (U9). Przetwarzając otrzymane pliki.pcap uzyskano zamieszczone poniżej tabele 1 i 2 oraz wykresy przedstawione na rys. 2 i 3. Ze względu na ograniczone miejsce tabele zostały umieszczone tylko częściowo. Analiza danych zawartych w tabelach 1 i 2, wykresów z rys. 2 i 3 oraz dziennika aktywności w programie Wireshark pozwala stwierdzić, że: Rys. 3. Liczba pakietów przesyłanych przez urządzenia Na większości urządzeń występują dodatkowe transmisje danych, każde urządzenie wysyła ramkę zwaną beacon frame. Ramki beacon frame odbierane są przez wszystkie sąsiadujące z nadawcą urządzenia. Mają one na celu informowanie pobliskich urządzeń o obecności urządzenia nadawcy w sieci. Jeżeli urządzenie nie informuje o swojej obecności, pobliskie urządzenia wyrzucają je ze swojej tablicy routingu oraz szukają innego urządzenia sąsiadującego bezpośrednio z nimi. 14 XVII Poznańskie Warsztaty Telekomunikacyjne