TESTY WYDAJNOŚCI PROTOKOŁÓW ROUTINGU ROZGAŁĘŹNEGO

Transkrypt

1 Tomasz Szewczyk, Piotr Zwierzykowski, Politechnika Poznańska Wydział Elektroniki i Telekomunikacji pzwierz@et.put.poznan.pl 26 Poznańskie Warsztaty Telekomunikacyjne Poznań 7-8 grudnia 26 TESTY WYDAJNOŚCI PROTOKOŁÓW ROUTINGU ROZGAŁĘŹNEGO Jednym z głównych czynników wpływających na efektywność transmisji w sieci Internet jest sposób wyboru drogi, po której przesyłane będą pakiety. Poszukiwanie skutecznych metod trasowania wymaga często porównania róŝnych mechanizmów wykorzystywanych do tego celu. Wybór ścieŝek realizowany jest przez protokoły routingu typu punkt-punkt (ang. unicast) oraz protokoły routingu rozgałęźnego (ang. multicast). Celem artykułu jest przedstawienie metod i przykładowych wyników pomiaru wydajności protokołów routingu rozgałęźnego w sieci IP. 1. Wprowadzenie Rozwój sieci Internet oraz rozpowszechnianie transmisji rozsiewczej spowodował konieczność opracowania metod, pozwalających na pomiar parametrów tej transmisji oraz efektywności działania protokołów routingu rozgałęźnego. Pomiary takie pozwalają na: sprawdzenie działania urządzeń sieciowych pod względem wydajności przesyłania danych, zbadanie wydajności działania sieci, określenie efektywności działania protokołów sygnalizacyjnych. Sprawdzenie działania urządzeń sieciowych umoŝliwia zarówno ocenę działania pojedynczego urządzenia, jak równieŝ porównanie róŝnych urządzeń między sobą. Zbadanie wydajności działanie sieci pozwala na ocenę działania zespołu urządzeń sieciowych, wzajemnie połączonych łączami o określonych parametrach. Określenie efektywności działania protokołów sygnalizacyjnych pozwala na zbadanie zasobów potrzebnych do ich funkcjonowania oraz wprowadzanie ewentualnych zmian mających na celu poprawę ich działania. W tym celu w ramach grupy roboczej IETF Benchmarking Methodology (BMWG) opracowany został zestaw dokumentów [1][2][3][4][5] definiujących metody wykonywania oraz sposób prezentacji wyników pomiarów. NaleŜy zwrócić uwagę, Ŝe dokumenty te określają sposób pomiarów parametrów transmisji rozsiewczej, nie wskazując jaki protokół routingu rozgałęźnego ma być stosowany w trakcie pomiarów. Pozwala to zarówno na badanie i porównywanie efektywności działania wielu róŝnych protokołów, jak i zestawu współdziałających ze sobą. Metody pomiarowe moŝna podzielić na dwie grupy [5]: pomiar wydajności przekazywania pakietów pomiędzy interfejsami urządzenia sieciowego, pomiar opóźnień związanych z działaniem protokołów sygnalizacyjnych. Pomiar wydajności przekazywania pakietów pomiędzy interfejsami urządzenia sieciowego, zaleŝy w głównej mierze od jego parametrów konstrukcyjnych, a nie od działania protokołów routingu rozgałęźnego. Z tego względu w dalszej części artykułu skupiono się na drugiej grupie pomiarów. Artykuł podzielono na 6 rozdziałów. W rozdziale 2 przedstawiono podstawowe parametry pomiarowe, rozdział 3 prezentuje metody pomiarowe, natomiast rozdziały 4 i 5 piąty prezentują testy wykonane z uŝyciem analizatora oraz pomiary w rzeczywistej sieci. Rozdział 6 zawiera podsumowanie. 2. Procedury pomiarowe Prezentacja procedur pomiarowych omówionych w RFC 3918 wymaga wcześniejszego zdefiniowania kilku pojęć. Podstawowymi pojęciami są System Under Test (SUT) oraz Device Under Test (DUT), które zostały zdefiniowane w RFC 2285 [2]: Device Under Test (DUT) oznacza urządzenie sieciowe, którego odpowiedź na wygenerowany jest ruch testowy jest przedmiotem badania; System Under Test (SUT) oznacza zespół urządzeń sieciowych, traktowanych jako całość, której odpowiedź na wygenerowany jest ruch testowy jest przedmiotem badania. MoŜna wyróŝnić 2 najwaŝniejsze parametry pomiarowe: Aggregated Multicast Throughput (AMT) - określa maksymalną liczbę ramek na sekundę, kierowanych do jednej grupy multicast, wysyłanych na N interfejsów wyjściowych, które mogą być przesłane bez strat [4], Group Join Delay (GJD) oznacza czas jaki upływa od momentu wysłania do DUT Ŝądania dołączenia do grupy (IGMP Group Membership Report) do rozpoczęcia przez DUT wysyłania pakietów, kierowanych do tej grupy, na interfejsie, na którym odebrano to Ŝądanie Architektura systemu pomiarowego W procedurach pomiarowych rozwaŝa się sytuację, gdy jedno źródło wysyła dane do wielu odbiorców, łatwo moŝna je jednak rozszerzyć, o kolejne źródła. JeŜeli przedmiotem badania jest grupa urządzeń (SUT), to naleŝy zastosować stanowisko pomiarowe przedstawione na rysunku 1. Source test port Ingress SUT DUT A Egress DUT B Egress DUT C DUT D Egress Destination test port 1 Destination test port 2 Destination test port n Rysunek 1. Stanowisko pomiarowe SUT [5] W przedstawionym systemie pomiarowym pakiety ze źródła wysyłane są na pojedynczy interfejs jednego z urządzeń wchodzących w skład SUT, a następnie przesyłane przez kolejne urządzenia wchodzące w skład SUT, do momentu, gdy dotrą do odpowiednich interfejsów wyjściowych. Sposób konfiguracji SUT, zawierający opis topologii połączeń oraz konfiguracji poszczególnych urządzeń wchodzących w jego skład, które muszą zostać przedstawione w trakcie prezentacji wyników pomiarów. Stanowisko przedstawione na rysunku 1 moŝna równieŝ wykorzystać w przypadku, gdy przedmiotem badania jest jedno urządzenie (DUT), zastępując blok SUT badanym urządzeniem. W obu przypadkach, przed rozpoczęciem właściwych testów, naleŝy sprawdzić poprawność działania SUT lub DUT. Sprawdzenie to powinno

2 nastąpić, przez wysłanie z urządzeń testowych, wiadomości IGMP Group Report, w kierunku interfejsów wyjściowych SUT/DUT. Następnie z testowego źródła danych naleŝy wysłać strumień danych kierowany do grupy, której dotyczyła wiadomość IGMP i sprawdzić, czy został odebrany na wszystkich interfejsach wyjściowych. W czasie testów muszą zostać wyłączone wszelkie mechanizmy związane z QoS, Flow Control lub inne, mogące wpłynąć na sposób przekazywania pakietów Pomiar Group Join Delay Celem pomiaru GJD jest określenie jakie wartości przyjmuje ten parametr w trakcie badania DUT lub SUT. Metody pomiaru GJD są uzaleŝnione od aktualnego stanu Multicast Forwarding Database 1 (MFDB). MoŜna wyróŝnić dwa stany MFDB: stan, w którym MFDB nie zawiera adresu grupy, uŝywanej w trakcie pomiarów, stan 1, w którym MFDB zawiera adres grupy, uŝywanej w trakcie pomiarów. W pierwszym przypadku, pomiar uwzględnia czas, który jest potrzebny do stworzenia odpowiednich wpisów w MFDB oraz rozpoczęcia przekazywania pakietów na odpowiednie interfejsy. Pomiar ten umoŝliwia określenie jaki czas potrzebny jest na dodanie nowej grupy multicast do bazy MFDB. W drugim przypadku pomiar uwzględnia czas potrzebny na modyfikację bazy MFDB przez dodanie nowych interfejsów wyjściowych oraz rozpoczęcie przekazywania pakietów kierowanych do grupy multicast. Pomiar ten umoŝliwia sprawdzenie mechanizmów stosowanych do modyfikacji MFDB 2. MoŜna zatem wyróŝnić dwie metody pomiaru GJD uwzględniające odpowiednie stany w jakich znajduje się MFDB. Metody te mogą być stosowane oddzielnie, jednak podając wyniki pomiarów naleŝy określić jakiej metody uŝywano. W celu zminimalizowania zmian opóźnienia wynikających z liczby grup multicast obsługiwanych przez DUT/SUT w danym momencie, pomiary powinny być wykonywane z wykorzystaniem jednej grupy multicast. Metoda A: W metodzie tej załoŝono, Ŝe baza MFDB nie zawiera wpisów dla grupy multicast, uŝywanej w czasie testów, a zatem zgodnie z wcześniejszą definicją MFDB znajduje się w stanie. W czasie pomiarów naleŝy uŝywać tylko jednego interfejsu źródłowego oraz jednego wyjściowego. Przed rozpoczęciem pomiaru naleŝy upewnić się, ze dany interfejs wyjściowy nie jest juŝ uŝywany do przekazywania pakietów kierowanych do grupy multicast uŝywanej do testu. Metoda B: W metodzie tej załoŝono, Ŝe baza MFDB zawiera wpisy dla grupy multicast, uŝywanej w czasie testów, a zatem zgodnie z wcześniejszą definicją MFDB znajduje się w stanie 1. W czasie pomiarów moŝna uŝywać jednego interfejsu źródłowego oraz jednego lub wielu interfejsów wyjściowych. Przed rozpoczęciem pomiaru naleŝy upewnić się, ze dany interfejs wyjściowy nie jest juŝ uŝywany do 1 MFDB (Multicast Forwarding Database) oznacza bazę informacji DUT lub SUT, na podstawie której pakiety kierowane do grup multicast, wysyłane są na właściwe interfejsy. W ogólnym przypadku wpisy w bazie MFDB mają postać pary (InIf,OIL), gdzie InIf oznacza interfejs wejściowy, natomiast OIL oznacza listę interfejsów wyjściowych. 2 NaleŜy zwrócić uwagę, Ŝe w przypadku badania DUT, baza MFDB dotyczy pojedynczego urządzenia, natomiast w przypadku badania SUT, baza jest sumą stanów na poszczególnych urządzeniach. ZauwaŜmy teŝ, Ŝe baza MFDB powstaje jako rezultat działania protokołów routingu rozgałęźnego, zatem wyniki pomiarów zaleŝne są od ich działania. przekazywania pakietów kierowanych do grupy multicast uŝywanej do testu. Po zakończeniu procedur sprawdzających odpowiednich dla metod A i B, naleŝy rozpocząć wysyłanie danych ze źródła. Zaleca się, aby ruch generowany był na poziomie określonym przez Aggregated Multicast Throughput (AMT). Następnie, w kierunku odpowiedniego interfejsu wyjściowego naleŝy wysłać Ŝądanie dołączenia do grupy (IGMP Group Membership Report). Group Join Delay wyznaczany jest jako odstęp czasu pomiędzy wysłaniem Ŝądania dołączenia do grupy t a a czasem t b odebrania pierwszej ramki kierowanej do grupy na właściwym interfejsie: t GJD = tb ta, gdzie t a jest czasem wysłania ostatniego bitu wiadomości IGMP Group Membership Report, natomiast t b jest czasem odbioru pierwszego bitu pierwszej ramki kierowanej do grupy multicast. Wyniki pomiarów muszą uwzględniać następujące parametry: rozmiar ramek, liczbę interfejsów wyjściowych, wersję IGMP, liczbę grup multicast, szybkość za jaką dane wysyłane były ze źródła oraz zastosowaną metodę pomiarową Pomiar Group Leave Delay Celem pomiaru GLD jest określenie jakie wartości przyjmuje ten parametr w trakcie badania DUT lub SUT. Pomiary powinny być prowadzone z wykorzystaniem jednej grupy multicast. Przed ich rozpoczęciem naleŝy sprawdzić czy wszystkie interfejsy wyjściowe zostały dołączone do grupy multicast, przez wysłanie ze źródła strumienia danych skierowanego do grupy multicast uŝywanej w trakcie pomiarów, oraz weryfikację, czy pakiety zostaną odebrane na odpowiednich interfejsach wyjściowych. Gdy procedury weryfikacyjne zostaną zakończone, naleŝy rozpocząć generowanie strumienia danych ze źródła. Zaleca się, aby strumień był generowany z szybkością AMT. Następnie w kierunku kaŝdego z portów docelowych naleŝy wysłać wiadomości IGMP Leave Group. Group Leave Delay wyznaczany jest jako odstęp czasu pomiędzy wysłaniem Ŝądania odłączenia do grupy t a a czasem t b odebrania ostatniej ramki kierowanej do grupy na właściwym interfejsie: t GLD = tb ta, gdzie t a jest czasem wysłania ostatniego bitu wiadomości IGMP Leave Group, natomiast t b czasem odbioru ostatniego bitu ostatniej odebranej ramki kierowanej do grupy multicast. Wyniki pomiarów muszą uwzględniać następujące parametry: rozmiar ramek, liczbę interfejsów wyjściowych, wersję IGMP, liczbę grup multicast oraz liczbę interfejsów wyjściowych. 3. Testy z uŝyciem analizatorów sprzętowych W praktyce często zachodzi potrzeba sprawdzenia działania protokołów w rzeczywistej sieci lub na pojedynczym urządzeniu. Sprzętowe testery protokołów pozwalają na sprawdzenie działania zarówno pojedynczego urządzenia, jak i całej sieci. Obiekt testów często nazywany jest systemem testowanym. SUT w trakcie testów moŝe być sprawdzany pod kątem działania mechanizmów sterujących i wydajnościowym dla danego protokołu. Parametry związane z wydajnością przesyłania danych testowanego systemu (ang. forwarding performance) silnie związane są z jego architekturą wewnętrzną. Nie są one zaleŝne od działania protokołu kierowania ruchem, poniewaŝ protokół dostarcza mechanizmów pozwalających na określenie sposobu przesyłania danych. W dalszej części omówione zostaną pomiary, jakie moŝna wykonać za pomocą sprzętowego testera (ang. router tester), których wyniki zaleŝą bezpośrednio od działania protokołu kierowania ruchem w sieci rozgłoszeniowej [15]. NaleŜą do nich takie pomiary jak:

3 opóźnienie dołączenia do grupy (Group Join Delay), opóźnienie odłączenia od grupy (Group Prune Delay), opóźnienie przełączenie z drzewa RPT na SPT (RPTto-SPT Switchover Delay), Reverse Path Forwarding Check 3. Najczęściej stosowanym protokołem trasowania pozwalającym na budowę drzew dystrybucyjnych w sieciach z transmisją rozsiewczą jest PIM (Protocol Independent Multicast), dlatego wymienione typy pomiarów omówione zostaną na przykładzie tego protokołu. podłączone jest źródło (FHR) oraz dodatkowo moŝe zawierać kilka routerów obsługujących protokół PIM-SM. W pierwszej fazie testu z interfejsu źródłowego wysyłany jest strumień pakietów kierowany do grupy multicast. Po jego odebraniu przez odpowiedni port testera, z portu inicjującego przełączenie na drzewo SPT wysyłana jest w kierunku FHR wiadomość PIM Join (S,G). Następnie mierzony jest czas, po którym odebrany zostanie pierwszy pakiet przesłany wzdłuŝ drzewa SPT. Test ten moŝe zostać oczywiście rozszerzony o wiele grup multicast oraz wiele źródeł nadających do nich Opóźnienie dołączenia do grupy Stanowisko testowe przedstawione jest na rysunku 2. Testowany system (SUT) podłączony jest jednym interfejsem do portu testera, emulującego router, do którego podłączone jest źródło (ang. First Hop Router). Pozostałe interfejsy SUT (lub co najmniej jeden interfejs) dołączone są do portów testera emulujących routery, do których podłączeni są odbiorcy (ang. Last Hop Router). Rysunek 3. Stanowisko do pomiaru RPT-to-SPT switchover Rysunek 2. Stanowisko do pomiaru Group Join Delay Na początku testu, z portu testera emulującego router FHR wysyłany jest strumień pakietów kierowany do grup multicast. Następnie, z portów testera, emulujących routery LHR, wysyłane są wiadomości PIM Join. Opóźnienie dołączenie do grupy mierzone jest jako róŝnica pomiędzy czasem wysłania wiadomości Join, a czasem odebrania pierwszego pakietu kierowanego do grupy, której ta wiadomość dotyczyła Opóźnienie odłączenia od grupy Stanowisko testowe jest podobne jak w przypadku testu Group Join Delay (rysunek 2). Na początku testu, z portu testera emulującego router FHR wysyłany jest strumień pakietów kierowany do grup multicast, natomiast z portów testera, emulujących routery LHR, wysyłane są wiadomości PIM Join. Po osiągnięciu stanu stabilnego, w którym ruch wysyłany ze źródła dociera do wszystkich odbiorców, z portów emulujących routery LHR wysyłane są wiadomości PIM Prune. Opóźnienie odłączenia od grupy mierzone jest jako róŝnica pomiędzy czasem wysłania wiadomości Prune, a czasem odebrania ostatniego pakietu kierowanego do grupy, której ta wiadomość dotyczyła Opóźnienie przełączenia drzewa Celem testu jest sprawdzenie, po jakim czasie pakiety kierowane do grupy multicast będą przesyłane wzdłuŝ drzewa SPT (tzw. RPT-to-SPT Switchover). Struktura sieci testowej przedstawiona jest na rysunku 3. Oprogramowanie testera emuluje źródło pakietów kierowanych do grupy na jednym interfejsie, oraz router pełniący funkcję RP oraz grupy odbiorców na innym porcie. Trzeci port testera emuluje router LHR, który inicjować będzie przełączenie z drzewa RPT na SPT. SUT składać się co najmniej z routera do którego 3 RPF Check nie jest funkcją specyficzną dla protokołu kontrolującego tworzenie drzew dystrybucyjnych, jednak naleŝy o nim wspomnieć, jako o jednym z fundamentalnych mechanizmów uŝywanych w transmisji rozsiewczej RPF Check Celem tego testu jest sprawdzenie poprawności działania mechanizmu RPF Check, czyli sprawdzenia czy pakiety multicast odebrane zostały na właściwym interfejsie routera. Architektura sieci testowej przedstawiona jest na rysunku 4. Test ten moŝe zostać przeprowadzony w dwojaki sposób. W pierwszym wariancie (rysunek 4a) pakiety z tym samym adresem źródłowym mogą być generowane na dwóch róŝnych interfejsach testera. W takim przypadku strumień, przychodzący na interfejsie innym od tego, którego router mógłby uŝyć w celu osiągnięcia źródła, zostanie odrzucony. Drugi wariant (rysunek 4b) polega na wysyłaniu dwóch strumieni przez jeden interfejs testera, jednak posiadających róŝne adresy źródłowe. W tym przypadku, strumień z niewłaściwym adresem źródłowym powinien zostać odrzucony. a) b) TESTER DST SRC TESTER DST SRC DST SRC / / / /3 SUT SUT Rysunek 4. Mechanizm RPF check 4. Pomiary w rzeczywistej sieci Multicast groups Multicast groups Testy, których wyniki zostały zamieszczone przeprowadzono w miejskiej sieci komputerowej POZMAN w Poznaniu, której operatorem jest Poznańskie Centrum Superkomputerowo-Sieciowe oraz między systemami autonomicznymi w sieci Internet. Ze względu na zastosowane metody oraz zakres pomiarów moŝna je podzielić na dwie grupy. Pierwsza grupa obejmuje pomiary, które moŝna wykonać w miejskiej sieci komputerowej przy pomocy

4 specjalnego urządzenia testowego (ang. router tester). Natomiast druga grupa pomiarów związana jest z pomiarem opóźnienia GJD przeprowadzonych dla róŝnych źródeł znajdujących się w sieci Internet Pomiary wewnątrz sieci POZMAN W testach protokołów routingu rozgałęźnego w rzeczywistej sieci wykorzystano tester N2X firmy Agilent Technologies [7]. Tester wyposaŝony był w dwa interfejsy Gigabit Ethernet oraz dwa interfejsy ATM STM-1/STM-4. Pomiary wykonywano wykorzystując następujące routery sieci: Juniper M1 [8], Foundry NetIron XMR 16 [9] oraz Cisco 757 [1]. Połączenia pomiędzy urządzeniami oraz sposób podłączenia testera przedstawiono na rysunku 5. Głównym routerem w badanej sieci był Juniper M1, który pełnił funkcję RP. Za pośrednictwem przełącznika ATM ASX 1 i PVC został on połączony z routerem Cisco 757. Do routera M1 podłączono równieŝ, za pomocą interfejsu GE router NetIron XMR16. Tester podłączono do sieci czterema interfejsami, które przedstawiono w tabeli 1. Pierwszy test polegał na sprawdzeniu działania protokołu IGMP na routerze NetIron XMR. W tym celu sieć testowa przedstawiona na rysunku 5 została zmodyfikowana. Interfejs 11/2 testera podłączony został do wolnego interfejsu GE routera. Tabela 1. Połączenia zastosowane w testowanej sieci Interfejs Urządzenie docelowe testera Nazwa Interfejs 11/1 NetIron XMR GigabitEthernet 11/2 C757 FastEthernet 13/1 C757 ATM 622Mbps 13/2 C757 ATM 155Mbps Następnie uruchomiono test polegający na pomiarze opóźnienia jakie wystąpiło od momentu wysłania wiadomości IGMP Membership Report do otrzymania pierwszego pakietu IP multicast. małej liczby grup. Przeprowadzone pomiary nie wskazują równieŝ na występowanie zaleŝności pomiędzy opóźnieniami występującymi na róŝnych interfejsach. Celem kolejnego testu był pomiar opóźnienia jaki występował w sieci przedstawionej na rysunku 5. Podobnie jak w poprzednim przypadku, wykonano pomiar opóźnienia jakie wystąpiło od momentu wysłania wiadomości IGMP Membership Report do otrzymania pierwszego pakietu IP multicast, z tą róŝnicą, Ŝe port źródłowy i docelowy podłączone były do innych routerów. Test ten pozwolił więc na ocenę współdziałania protokołów IGMP oraz PIM w testowanej sieci. Wyniki pomiarów przedstawiono na rysunku 6c z którego wynika, Ŝe podobnie jak w przypadku testów pojedynczego urządzenia, opóźnienia wynikające z działania zestawu protokołów w sieci składającej się z kilku routerów, są równieŝ niezauwaŝalnie małe dla uŝytkownika. Poprzednie testy prowadzone były przy małej liczbie grup i postanowiono je powtórzyć dla większej liczby grup odbiorców (rysunku 6d). Uzyskane wyniki wskazują, na okresowy wzrost opóźnienia w funkcji ilości grup. Jest to spowodowane niedoskonałością testów zdefiniowanych w zestawie QuickTests. Okazuje się bowiem, Ŝe w trakcie działania skryptu testowego, Ŝądania dołączenia do grupy nie są wysyłane z maksymalną prędkością. W rezultacie tego ruch testowy generowany moŝe być jeszcze przed zakończeniem generowania tych Ŝądań. 11/2 13/1 13/2 11/1 Rysunek 6. Wyniki pomiarów IGMP W kolejnych testach sprawdzono opóźnienia jakie wystąpiło od momentu wysłania wiadomości PIM Join do otrzmania pierwszego pakietu IP multicast. W odróŝnieniu do poprzednich testów, w których tester symulował Ŝądania wysyłane przez aplikację, za pomocą której odbierana była transmisja rozgłoszeniowa, kolejne testy związane są z wymianą wiadomości pomiędzy routerami. W tym przypadku interfejs testera symulował router podłączony do badanej sieci (SUT). Rysunek 5. Schemat testowanej sieci Test przeprowadzono dla pięciu grup rozgłoszeniowych wysyłając Ŝądania dołączenia do grupy z interfejsu 11/2 testera. Jego wyniki przedstawiono na rysunku 6a. Następnie zmieniono interfejs, z którego wysyłane były wiadomości IGMP Membership Report na 11/1 i powtórzono test. Jego wyniki przedstawione są na rysunku 6b. Otrzymane wyniki wskazują, Ŝe opóźnienie wynikające z działania protokołów IGMP oraz PIM 4, z punktu widzenia uŝytkownika aplikacji, wykorzystującej transmisją rozgłoszeniową, jest niewielkie dla 4 NaleŜy zauwaŝyć, Ŝe działanie protokołu PIM jest wymagane równieŝ gdy pakiety mają być przesyłane tylko i wyłącznie w obrębie jednego urządzenia. Rysunek 7. Wyniki pomiarów działania protokołu PIM-SMv2

5 W pierwszym teście zmierzono opóźnienia dla dwóch interfejsów odbiorczych. Jego wyniki przedstawiono na rysunku 7a. W trakcie pomiarów, tester wysyłał pakiety z interfejsu 11/1, natomiast na interfejsach 11/2 oraz 13/1 zasymulowano dwa routery wysyłające wiadomości PIM Join. Na rysunku 7a widać róŝnicę w opóźnieniach występującą pomiędzy interfejsami wyjściowymi. Dlatego teŝ wykonano następny test dodając kolejny interfejs wyjściowy, na którym zasymulowany został trzeci router wysyłający wiadomości PIM Join. Wyniki testów przedstawione na rysunkach 7a-b, wskazują, Ŝe zmiany opóźnienia na poszczególnych interfejsach wyjściowych, w funkcji ilości grup rozgłoszeniowych mają podobny charakter. MoŜna zauwaŝyć, Ŝe w pierwszym teście (rysunek 7a) większe opóźnienie występowało dla interfejsu 11/2, natomiast w drugim (rysunek 7b) dla interfejsu 13/1. Biorąc pod uwagę podobny charakter zmian opóźnienia w trakcie pomiarów, moŝna przypuszczać, Ŝe róŝnice te wynikają z kolejności generowania wiadomości PIM Join przez tester na poszczególnych interfejsach. Kolejny test polegał na sprawdzeniu opóźnienia jakie wystąpiło od momentu wysłania wiadomości PIM Prune do otrzymania ostatniego pakietu IP multicast. Wyniki testu przedstawiono na rysunek 7c. Łatwo zauwaŝyć, Ŝe opóźnienie otrzymane w trakcie pomiarów jest znacznie krótsze, niŝ w przypadku dołączania do grupy. MoŜna to uzasadnić, tym Ŝe do zakończenia wysyłania pakietów na interfejsie wystarczy obsługa wiadomości PIM Prune tylko na jednym routerze, natomiast nie jest konieczna interakcja z innymi routerami. Przedstawione w tym rozdziale testy ukazują moŝliwości badania protokołów routingu rozgałęźnego, jakie oferują współczesne urządzenia pomiarowe. Ze względu na niewielką liczbę powtórzeń poszczególnych pomiarów ich wyniki nie pozwalają na sformułowanie wniosków na temat działania tych protokołów w dłuŝszym okresie czasu Pomiary między domenami w sieci Internet Wykonanie pomiarów pomiędzy domenami w sieci Internet wymaga rozlokowania w wielu systemach autonomicznych specjalistycznych urządzeń pomiarowych, pozwalających na badanie zachowania się protokołów routingu rozgałęźnego. Z uwagi na wysoką cenę sprzętu pomiarowego wykonanie tego typu pomiarów jest jednak utrudnione. MoŜliwe jest jednak wykonanie uproszczonych pomiarów, dla realizacji których wykorzystane mogą zostać aktualnie dostępne źródła transmisji rozgłoszeniowej. W trakcie tych pomiarów zbadany moŝe zostać cały zestaw protokołów biorących udział w realizacji tej transmisji na wszystkich urządzeniach sieciowych znajdujących się na drodze od źródła do odbiorcy. Na rysunku 8 przedstawiono koncepcję uproszczonych testów działania protokołów routingu rozgałęźnego pomiędzy wieloma domenami. W celu przeprowadzenia testów wymagane jest znalezienie w sieci Internet źródła, nadającego strumień danych kierowany do grupy multicast. Następnie z serwera pomiarowego wysyłane jest Ŝądanie dołączenia do grupy, do której nadaje dane źródło oraz mierzony czas jaki upłynie do momentu odebrania pierwszego pakietu kierowanego do tej grupy. NaleŜy zwrócić uwagę, Ŝe na dokładność pomiaru istotny wpływ ma częstotliwość pakietów nadawanych przez źródło, ich wielkość oraz odstępy między nimi. Odstęp między kolejnymi pakietami nadanymi przez źródło lub przerwa związana z bieŝącą transmisją długiego pakietu moŝe zsumować się z czasem potrzebnym do zbudowania lub rekonfigurowania drzewa dystrybucyjnego przez urządzenia sieciowe. Sumowanie wystąpi w przypadku, gdy danym miejscu sieci zakończona zostanie procedura tworzenia lub modyfikacji gałęzi drzewa dystrybucyjnego oraz na interfejsie, na którym router odbiera pakiety ze źródła: odbierany będzie aktualnie pakiet kierowany do grupy, rozpocznie się przerwa pomiędzy kolejnymi pakietami wysyłanymi ze źródła. Rysunek 8. Koncepcja testów pomiędzy wieloma domenami W pierwszym przypadku na całkowite opóźnienie wpływ ma długość pakietów nadawanych przez źródło, natomiast w drugim przypadku odstępy pomiędzy nimi. NaleŜy więc dąŝyć do tego, aby źródło generowało małe pakiety, a odstępy między nimi były znacznie mniejsze od GJD. W celu wybrania źródła nadającego strumień danych do grupy multicast wykorzystano dane rozgłaszane za pomocą protokołu SDP. Dane te zawierają między innymi adres grupy oraz parametry strumienia danych. 21:: 21:4: 22:2: 23:: 23:4: :2: 1:: 1:4: 2:2: 3:: 3:4: 4:2: 5:: 5:4: 6:2: 7:: 7:4: Rysunek 9. Wyniki pomiarów GJD dla źródła i grupy Serwer pomiarowy pracował pod kontrolą systemu operacyjnego FreeBSD 6. i podłączony został do jednego z routerów sieci POZMAN (Cisco 726VXR) za pomocą interfejsu FastEthernet. Dostęp do sieci Internet wspierającej transmisję rozgłoszeniową odbywał się za pośrednictwem sieci naukowo-badawczych PIONIER [13] oraz GÉANT2 [14]. Na serwerze tym uruchomiono aplikację mlisten [11], która odpowiedzialna była za generowanie Ŝądań dołączenia do odpowiedniej grupy za pomocą protokołu IGMPv2. Pomiar czasu wykonywany był za pomocą aplikacji tcpdump [12] pozwalającej na pomiar odstępu czasu pomiędzy wybranymi pakietami jakie zostały odebrane lub wysłane na interfejsie sieciowym serwera pomiarowego. Pomiary parametru Group Join Delay wykonano wielu źródeł i grup multicast, których adresy znajdują się w Tabeli 2. Test polegał na generowaniu w odstępach pięciominutowych Ŝądań dołączenia do grupy oraz pomiarze czasu jaki upłynął od momentu wysłania tego Ŝądania do odebrania pierwszego pakietu kierowanego do badanej grupy multicast. Dodatkowo mierzono opóźnienia pomiędzy dwoma kolejno odebranymi pakietami kierowanymi do badanej grupy. Wyniki pomiarów przedstawiono na rysunkach Łatwo zauwaŝyć, Ŝe parametr GJD, w kaŝdym z przypadków rzadko przekracza 8ms. W tabeli 2 przedstawiono średnie wartości GJD uzyskane w czasie pomiarów. Nie trudno zauwaŝyć, Ŝe średnie opóźnienie kolejnych pakietów (następujących po pierwszym odebranym pakiecie kierowanym 8:2: 9:: 9:4: 1:2: 11:: 11:4:1 12:2:1 13:: 13:4: 14:2: 15:: 15:4: 16:2: 17:: 17:4: 18:2: 19:: 19:4: 2:2:1

6 do badanej grupy) jest znacznie mniejsze od GJD, co świadczy o niewielkim wpływie opóźnienia związanego z transmisją pakietów na błąd pomiaru GJD. Opóźnienie związane z transmisją danych dotyczy równieŝ pakietów sterujących poszczególnych protokołów. ZauwaŜmy, Ŝe im większe wartości RTT (Round Time Trip) tym większe średnie czasy GJD. Zatem uzyskane pomiary potwierdziły, Ŝe czas budowy drzewa dystrybucyjnego zaleŝy nie tylko od ilości urządzeń biorących udział w transmisji, ale równieŝ od czasu transmisji danych sterujących. Na podstawie danych uzyskanych za pośrednictwem protokołu SDP wiadomo, Ŝe badane źródła nadawały strumienie danych video, których odbiór moŝliwy był przy pomocy odpowiednich aplikacji uruchamianych przez uŝytkownika. Biorąc pod uwagę, Ŝe czas uruchamiania takiej aplikacji jest znacznie większy od GJD, moŝna stwierdzić, Ŝe jest ono niezauwaŝalnie małe z punktu widzenia uŝytkownika aplikacji. Na tej podstawie moŝna wnioskować, Ŝe ewentualne modyfikacje protokołów routingu rozgałęźnego powinny być ukierunkowane na zmniejszenie ilości danych sterujących oraz obciąŝenia routerów związanych z obsługą tych protokołów. Tabela 2. Średnie wartości GJD uzyskane w czasie pomiarów Lp. Źródło Grupa GJD średnie [µs] Odchylenie standardowe GJD [µs] Średnie opóźnienie kolejnych pakietów [µs] Odchylenie standardowe kolejnych pakietów [µs] RTT [ms] <2 W celu umoŝliwienie porównania róŝnic jakie występują w efektywności działania protokołów routingu rozgałęźnego w sieci Internet, a ich działaniem wewnątrz jednej domeny, pomiary zostały równieŝ przeprowadzone dla źródła podłączonego w tym samym systemie autonomicznym, w jakim znajdował się serwer pomiarowy. Porównując wyniki zamieszczone w tabeli 2 widać, Ŝe opóźnienie GJD jest znacznie mniejsze dla tego źródła. Na opóźnienie GJD dla źródła wpływało tylko i wyłącznie działanie protokołu PIM oraz IGMP w jednej domenie administracyjnej, a drzewo dystrybucyjne obejmowało znacznie mniej urządzeń. 21:: 21:4:1 22:2: 23:: 23:4: :2: 1:: 1:4: 2:2: 3::1 3:4: 4:2: 5::1 5:4: 6:2: 7:: 7:4: 8:2:1 Rysunek 12. Wyniki pomiarów GJD dla źródła i grupy :: 21:4: 22:2: 23:: 23:4: :2: 1:: 1:4: 2:2: 3:: 3:4: 4:2: 5::1 5:4:1 6:2: 7::1 7:4:1 8:2: Rysunek 13. Wyniki pomiarów GJD dla źródła i grupy Wzrost opóźnień w tych godzinach, moŝe być spowodowany cyklicznymi procedurami utrzymaniowymi stosowanymi przez operatorów ISP (np. aktualizacja filtrów akceptowanych prefiksów przez protokół BGP). DuŜa dynamika zmian opóźnienia GJD, która rozpoczyna się od godziny 14. moŝe być związana ze wzrostem ruchu w sieci, a tym samym wzrostem opóźnień dla danych sterujących. Przeprowadzone testy nie obejmowały sprawdzenia, czy w czasie ich trwania ścieŝka od źródła do odbiorcy nie zmieniała się. NaleŜy zatem pamiętać, Ŝe uzyskane wyniki są rezultatem działania wielu róŝnych protokołów, których celem jest wyznaczenie trasy przesyłania wszystkich rodzajów pakietów w tym takŝe rozgłoszeniowych ::1 9::1 9:4: 9:4:1 1:2: 1:2:1 11:: 11::1 11:4: 11:4: 12:2: 12:2:1 13:: 13::1 13:4: 13:4:1 14:2: 14:2: 15::1 15::1 15:4:1 15:4: 16:2:1 16:2: 17:: 17:: 17:4: 17:4: 18:2: 18:2: 19:: 19:: 19:4: 19:4: 2:2: 2:2: :: 21:4: 22:2: 23:: 23:4: :2: 1:: 1:4: 2:2: 3:: 3:4: 4:2: 5::1 5:4: 6:2: 7:: 7:4: 8:2: Rysunek 1. Wyniki pomiarów GJD dla źródła i grupy :2: 21:42: 22:22: 23:2: 23:42: :22: 1:2: 1:42: 2:22: 3:2: 3:42: 4:22: 5:2: 5:42: 6:22: 7:2: 7:42: 8:22: Rysunek 11. Wyniki pomiarów GJD dla źródła i grupy Analizując wykresy wyników pomiaru GJD dla moŝna zauwaŝyć, Ŝe istnieją chwile, w których opóźnienia wzrastają jednocześnie dla wielu grup i źródeł. Szczególnie dobrze widać to dla pomiarów wykonanych około godziny 1:4, 7: oraz 14:2. Na początku rozdziału zwrócono uwagę na znaczenie wyboru źródła, jakie będzie wykorzystane do przeprowadzenia pomiarów. 9:: 9:2: 9:4: 9:42: 1:2: 1:22: 11:: 11:2: 11:4:1 11:42: 12:2:1 12:22: 13:: 13:2: 13:4: 13:42: 14:2: 14:22: 15:: 15:2: 15:4:1 15:42: 16:2:1 16:22:1 17:: 17:2: 17:4: 17:42: 18:2:1 18:22: 19:: 19:2: 19:4: 19:42: 2:2: 2:22: 21:: 21:4:1 22:2: 23:: 23:4: :2: 1::1 1:4: 2:2: 3::1 3:4: 4:2: 5:: 5:4: 6:2: 7:: 7:4: 8:2:1 9:: Rysunek 14. Wyniki pomiarów GJD dla źródła i Na rysunku 15 zilustrowano wyniki pomiarów GJD dla źródła oraz grupy w sytuacji, gdy źródło nadawało jeden pakiet na sekundę. Pomiary wykazały duŝy rozrzut wartości GJD, który związany jest z tym, Ŝe procedury budowy drzewa dystrybucyjnego kończyły się w roŝnych momentach przerwy jaka występowała pomiędzy pakietami nadawanymi ze źródła. Zatem przerwa ta istotnie wpływała na wynik pomiaru GJD. Porównując wynik pomiaru dla źródła w sytuacji, gdy nadawało dane z prędkością około 15kbps (rysunek 14, Tabela 2), widać równieŝ wyraźny wzrost średniej wartości GJD oraz odchylenia standardowego. Obserwacje te potwierdzają znaczenie częstotliwości nadawanych przez źródło pakietów w trakcie pomiarów GJD w rzeczywistej sieci. Warto zauwaŝyć, Ŝe w rzeczywistej sieci nie zawsze moŝliwe jest wykonanie pomiarów zgodnie z definicjami i procedurami przedstawionymi wcześniej, poniewaŝ wygenerowanie przez źródło ruchu na poziomie AMT moŝe doprowadzić do powstanie strat pakietów ruchu produkcyjnego. Dodatkową trudnością było by ustalenie 9:4: 1:2: 11::1 11:4: 12:2: 13:: 13:4:1 14:2: 15:: 15:4: 16:2: 17:: 17:4:1 18:2: 19::1 19:4: 2:2:

7 poziomu AMT, poniewaŝ na poziom ten wpływa istniejący ruch sieciowy w chwili wykonywania pomiaru AMT i moŝe on ulec zmianie po zakończeniu pomiaru. Dlatego teŝ, źródło wykorzystane do przeprowadzenia pomiarów powinno nadawać pakiety w odstępach znacznie mniejszych od GJD, jednak ruch ten nie powinien wpływać na degradację istniejącego ruchu sieciowego. Opóźnienie :45: 17:15: 17:45: 18:15: 18:45: 19:15: 19:45:1 2:15: 2:45: 21:15: 21:45: 22:15: 22:45:1 23:15: 23:45: :15: Średnie GJD średnie GJD+s średnie GJD-s Trend GJD Rysunek 15. Wyniki pomiarów GJD dla źródła nadającego pakiety co 1 sekundę :45: 1:15: 5. Podsumowanie Transmisja rozgłoszeniowa pełni waŝną rolę w sieci Internet, poniewaŝ pozwala na efektywne dostarczanie danych do grupy urządzeń. Efektywność transmisji rozgłoszeniowej w duŝej mierze zaleŝy od sposobu w jaki skonstruowane zostanie drzewo dystrybucyjne, a tym samym od działania protokołów routingu rozgałęźnego. W artykule przedstawiono metody pomiarowe, które moŝna wykorzystać do oceny stosu protokołów realizujących połączenia rozgałęźne. W artykule zaprezentowano wykorzystanie procedur pomiarowych do pomiarów wykonanych w sieci MAN za pomocą sprzętowego testera N2X firmy Agilent Technologies oraz zaprezentowano własną metodę pomiarów parametrów routingu rozgałęźnego dla źródeł podłączonych w róŝnych systemach autonomicznych sieci Internet. Przedstawione metody oceny efektywności mogą zostać wykorzystane do wyboru protokołu routingu rozgałęźnego oraz oceny efektywności, która powinna poprzedzić wdroŝenie usług wykorzystujących ten typ transmisji. 1:45: 2:15: 2:45: 3:15: 3:45: 4:15: 4:45: 5:15: 5:45: 6:15: 6:45: 7:15: 7:45: 8:15: 8:45:1 9:15: Literatura [1] RFC S. Brander: Benchmarking terminology for network interconnection devices. July 1991, [2] RFC R. Mandeville: Benchmarking Terminology for LAN Switching Devices. February 1998, [3] RFC S. Bradner, J. McQuaid: Benchmarking Methodology for Network Interconnect Devices. March [4] RFC K. Dubray: Terminology for IP Multicast Benchmarking. October 1998, [5] RFC D. Stopp, B. Hickman: Methodology for IP Multicast Benchmarking. October 24, [6] RFC D. Johnson, S. Deering: Reserved IPv6 Subnet Anycast Addresses. March 1999, [7] Agilent Technologies. Multi-services test solution. [8] Juniper Networks. Juniper Networks M-series Multiservice Edge Routing Portfolio, [9] Foundry Networks. About the NetIron XMR 4, 8, 16, [1] Cisco Systems. Cisco 75 Series Routers. [11] Multicast test tools "msend", "mlisten", Andrew Daviel, TRIUMF, Jan 23, [12] tcpdump. Van Jacobson, Craig Leres and Steven McCanne. Lawrence Berkeley National Laboratory, University of California, Berkeley, CA, [13] PIONIER Polski Internet Optyczny, [14] GÉANT2 Network, [15] Agilent Technologies: Journal of Internet Test Methodologies. Podziękowania Autorzy dziękują Poznańskiemu Centrum Superkomputerowo - Sieciowemu za udostępnienie środków technicznych niezbędnych do przeprowadzenia badań przedstawionych w artykule.