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

(1)

Tomasz Szewczyk,

Piotr Zwierzykowski,

Politechnika Poznańska

Wydział Elektroniki i Telekomunikacji

e-mail:

pzwierz@et.put.poznan.pl

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.

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

Destination test port 1 Destination test port n Destination test port 2 Source test port DUT A DUT B DUT C DUT D Ingress Egress Egress Egress SUT

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

2006

Poznańskie Warsztaty Telekomunikacyjne Poznań 7 - 8 grudnia 2006

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

2.2. 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 Database1 (MFDB). MoŜna wyróŜnić

dwa stany MFDB:

− stan 0, 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 MFDB2.

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 0. 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 ta a czasem tb odebrania pierwszej ramki kierowanej do

grupy na właściwym interfejsie:

a b

GJD

t

=

−

,

gdzie ta jest czasem wysłania ostatniego bitu wiadomości

IGMP Group Membership Report, natomiast tb 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ą.

2.3. 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 ta a czasem tb odebrania ostatniej

ramki kierowanej do grupy na właściwym interfejsie:

a b

GLD

t

=

−

,

gdzie ta jest czasem wysłania ostatniego bitu wiadomości

IGMP Leave Group, natomiast tb 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

(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

(RPT-to-SPT Switchover Delay),

• Reverse Path Forwarding Check3.

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.

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

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

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

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.

Rysunek 3. Stanowisko do pomiaru RPT-to-SPT switchover

3.4. 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. Multicast groups DST 233.35.152.1 SRC 192.168.1.1 TESTER SUT 192.1 68.1.0/30 192.168. 5.0/30 Multicast groups DST 233.35.152.1 SRC 192.168.1.1 TESTER SUT 192.168.1.0/30 DST 233.35.152.1 SRC 192.168.5.1 192.168.5.0/30 a) b)

Rysunek 4. Mechanizm RPF check

4. Pomiary w rzeczywistej sieci

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.

4.1. 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 M10 [8], Foundry NetIron XMR 16000 [9] oraz Cisco 7507 [10]. Połączenia pomiędzy urządzeniami oraz sposób podłączenia testera przedstawiono na rysunku 5. Głównym routerem w badanej sieci był Juniper M10, który pełnił funkcję RP. Za pośrednictwem przełącznika ATM ASX 1000 i PVC został on połączony z routerem Cisco 7507. Do routera M10 podłączono równieŜ, za pomocą interfejsu GE router NetIron XMR16000. 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 101/2 testera podłączony

został do wolnego interfejsu GE routera.

Tabela 1. Połączenia zastosowane w testowanej sieci Urządzenie docelowe Interfejs

testera Nazwa Interfejs

101/1 NetIron XMR GigabitEthernet

101/2 C7507 FastEthernet

103/1 C7507 ATM 622Mbps

103/2 C7507 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. 10 1/1 101/ 2 103/ 1 103/ 2

Rysunek 5. Schemat testowanej sieci

Test przeprowadzono dla pięciu grup rozgłoszeniowych wysyłając Ŝądania dołączenia do grupy z interfejsu 101/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 101/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 PIM4, 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.

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

Rysunek 6. W y n i k i p o m i a r ó w I G M P

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

(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 101/1, natomiast na interfejsach 101/2 oraz 103/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 101/2, natomiast w drugim (rysunek 7b) dla interfejsu 103/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.

4.2. 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. 0 200000 400000 600000 800000 1000000 1200000 21:0 0:0 0 21:4 0:0 0 22:2 0:0 0 23:0 0:0 0 23:4 0:0 0 0:2 0:0 0 1:0 0:0 0 1:4 0:0 0 2:2 0:0 0 3:0 0:0 0 3:4 0:0 0 4:2 0:0 0 5:0 0:0 0 5:4 0:0 0 6:2 0:0 0 7:0 0:0 0 7:4 0:0 0 8:2 0:0 0 9:0 0:0 0 9:4 0:0 0 10:2 0:0 0 11:0 0:0 0 11:4 0:0 1 12:2 0:0 1 13:0 0:0 0 13:4 0:0 0 14:2 0:0 0 15:0 0:0 0 15:4 0:0 0 16:2 0:0 0 17:0 0:0 0 17:4 0:0 0 18:2 0:0 0 19:0 0:0 0 19:4 0:0 0 20:2 0:0 1 Czas O pó ź n ie nie [ µ s]

Rysunek 9. Wyniki pomiarów GJD dla źródła 128.214.211.175 i grupy 233.6.205.134

Serwer pomiarowy pracował pod kontrolą systemu operacyjnego FreeBSD 6.0 i podłączony został do jednego z routerów sieci POZMAN (Cisco 7206VXR) 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 9-14. Łatwo zauwaŜyć, Ŝe parametr GJD, w kaŜdym z przypadków rzadko przekracza 800ms. 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

(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

1 128.214.211.17 233.214.211.175 198 120 171 547 4 417 28 242 55 2 207.75.164.73 233.45.17.41 318 599 92 830 29 763 20 295 151 3 128.233.157.21 224.2.231.231 419 352 93 253 7 510 54 856 198 4 139.133.204.31 224.2.132.76 256 065 134 255 81 381 43 535 51 5 129.186.8.11 225.1.8.1 377 855 146 959 24 415 22 153 157 6 150.254.210.89 233.35.152.50 72 567 13 174 31 040 6 012 <2 RTT [ms] Grupa Lp. Źródło Odchylenie standardowe kolejnych pakietów [µs] GJD średnie [µs] Odchylenie standardowe GJD [µs] Średnie opóźnienie kolejnych pakietów [µs]

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 150.254.210.89 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ń.

0 200000 400000 600000 800000 1000000 1200000 21:00:0 0 21:40:0 0 22:20:0 0 23:00:0 0 23:40:0 0 00:20:0 0 01:00:0 0 01:40:0 0 02:20:0 0 03:00:0 0 03:40:0 0 04:20:0 0 05:00:0 1 05:40:0 0 06:20:0 0 07:00:0 0 07:40:0 0 08:20:0 0 09:00:0 0 09:40:0 0 10:20:0 0 11:00:0 0 11:40:0 1 12:20:0 1 13:00:0 0 13:40:0 0 14:20:0 0 15:00:0 0 15:40:0 1 16:20:0 1 17:00:0 0 17:40:0 0 18:20:0 1 19:00:0 0 19:40:0 0 20:20:0 0 Czas O p ó ź n ie nie [ µ s]

Rysunek 10. Wyniki pomiarów GJD dla źródła 207.75.165.73 i grupy 233.45.17.41 0 200000 400000 600000 800000 1000000 1200000 21:0 2:00 21:4 2:00 22:2 2:00 23:0 2:00 23:4 2:00 00:2 2:00 01:0 2:00 01:4 2:00 02:2 2:00 03:0 2:00 03:4 2:00 04:2 2:00 05:0 2:00 05:4 2:00 06:2 2:00 07:0 2:00 07:4 2:00 08:2 2:00 09:0 2:00 09:4 2:00 10:2 2:00 11:0 2:00 11:4 2:00 12:2 2:00 13:0 2:00 13:4 2:00 14:2 2:00 15:0 2:00 15:4 2:00 16:2 2:01 17:0 2:00 17:4 2:00 18:2 2:00 19:0 2:00 19:4 2:00 20:2 2:00 Czas O p ó ź n ie n ie [ µ s ]

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:40, 7:00 oraz 14:20. Na początku rozdziału zwrócono uwagę na znaczenie wyboru źródła, jakie będzie wykorzystane do przeprowadzenia pomiarów. 0 200000 400000 600000 800000 1000000 1200000 21 :00:00 21 :40:01 22 :20:00 23 :00:00 23 :40:00 00 :20:00 01 :00:00 01 :40:00 02 :20:00 03 :00:01 03 :40:00 04 :20:00 05 :00:01 05 :40:00 06 :20:00 07 :00:00 07 :40:00 08 :20:01 09 :00:01 09 :40:00 10 :20:00 11 :00:00 11 :40:00 12 :20:00 13 :00:00 13 :40:00 14 :20:00 15 :00:01 15 :40:01 16 :20:01 17 :00:00 17 :40:00 18 :20:00 19 :00:00 19 :40:00 20 :20:00 Czas O p ó ź n ie n ie [ µ s ]

Rysunek 12. Wyniki pomiarów GJD dla źródła 139.133.204.31 i grupy 224.2.132.76 0 200000 400000 600000 800000 1000000 1200000 21:00:0 0 21:40:0 0 22:20:0 0 23:00:0 0 23:40:0 0 00:20:0 0 01:00:0 0 01:40:0 0 02:20:0 0 03:00:0 0 03:40:0 0 04:20:0 0 05:00:0 1 05:40:0 1 06:20:0 0 07:00:0 1 07:40:0 1 08:20:0 0 09:00:0 1 09:40:0 1 10:20:0 1 11:00:0 1 11:40:0 0 12:20:0 1 13:00:0 1 13:40:0 1 14:20:0 0 15:00:0 1 15:40:0 0 16:20:0 0 17:00:0 0 17:40:0 0 18:20:0 0 19:00:0 0 19:40:0 0 20:20:0 0 Czas O p ó ź nie nie [ µ s]

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

0 20000 40000 60000 80000 100000 120000 140000 21:00:0 0 21:40:0 1 22:20:0 0 23:00:0 0 23:40:0 0 00:20:0 0 01:00:0 1 01:40:0 0 02:20:0 0 03:00:0 1 03:40:0 0 04:20:0 0 05:00:0 0 05:40:0 0 06:20:0 0 07:00:0 0 07:40:0 0 08:20:0 1 09:00:0 0 09:40:0 0 10:20:0 0 11:00:0 1 11:40:0 0 12:20:0 0 13:00:0 0 13:40:0 1 14:20:0 0 15:00:0 0 15:40:0 0 16:20:0 0 17:00:0 0 17:40:0 1 18:20:0 0 19:00:0 1 19:40:0 0 20:20:0 0 Czas O p ó ź nie n ie [ µ s]

Rysunek 14. Wyniki pomiarów GJD dla źródła 150.254.210.89 i 233.35.152.50

Na rysunku 15 zilustrowano wyniki pomiarów GJD dla

źródła 150.254.210.89 oraz grupy 233.35.152.50 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 150.254.210.89 w sytuacji, gdy nadawało dane z prędkością około 150kbps (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

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

0 500000 1000000 1500000 2000000 2500000 1 6:4 5:0 0 1 7:1 5:0 0 1 7:4 5:0 0 1 8:1 5:0 0 1 8:4 5:0 0 1 9:1 5:0 0 1 9:4 5:0 1 2 0:1 5:0 0 2 0:4 5:0 0 2 1:1 5:0 0 2 1:4 5:0 0 2 2:1 5:0 0 2 2:4 5:0 1 2 3:1 5:0 0 2 3:4 5:0 0 0 0:1 5:0 1 0 0:4 5:0 0 0 1:1 5:0 0 0 1:4 5:0 0 0 2:1 5:0 0 0 2:4 5:0 0 0 3:1 5:0 0 0 3:4 5:0 0 0 4:1 5:0 0 0 4:4 5:0 0 0 5:1 5:0 0 0 5:4 5:0 0 0 6:1 5:0 0 0 6:4 5:0 0 0 7:1 5:0 0 0 7:4 5:0 0 0 8:1 5:0 0 0 8:4 5:0 1 0 9:1 5:0 0 Czas O p ó ź n ie nie

150.254.210.89 Ś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ę

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.

Podziękowania

Autorzy dziękują Poznańskiemu Centrum

Superkomputerowo - Sieciowemu za udostępnienie środków

technicznych niezbędnych do przeprowadzenia badań

przedstawionych w artykule.

Literatura

[1] RFC 1242 - S. Brander: Benchmarking terminology for network

interconnection devices. July 1991, http://www.ietf.org/rfc/rfc1242.txt

[2] RFC 2285 - R. Mandeville: Benchmarking Terminology for LAN Switching

Devices. February 1998, http://www.ietf.org/rfc/rfc2285.txt

[3] RFC 2544 - S. Bradner, J. McQuaid: Benchmarking Methodology for

Network Interconnect Devices. March 1999.

http://www.ietf.org/rfc/rfc2544.txt

[4] RFC 2432 - K. Dubray: Terminology for IP Multicast Benchmarking. October 1998, http://www.ietf.org/rfc/rfc2432.txt

[5] RFC 3918 - D. Stopp, B. Hickman: Methodology for IP Multicast

Benchmarking. October 2004, http://www.ietf.org/rfc/rfc3918.txt

[6] RFC 2526 - D. Johnson, S. Deering: Reserved IPv6 Subnet Anycast

Addresses. March 1999, http://www.ietf.org/rfc/rfc2526.txt

[7] Agilent Technologies. Multi-services test solution.

http://advanced.comms.agilent.com/n2x

[8] Juniper Networks. Juniper Networks M-series Multiservice Edge Routing Portfolio, http://www.juniper.net/products/mseries

[9] Foundry Networks. About the NetIron XMR 4000, 8000, 16000, 32000.

http://www.foundrynet.com/products/routers/netiron/ni_XMR.html

[10] Cisco Systems. Cisco 7500 Series Routers.

http://www.cisco.com/en/US/products/hw/routers/ps359/index.html

[11] Multicast test tools "msend", "mlisten", Andrew Daviel, TRIUMF, Jan 2003, http://andrew.triumf.ca/multicast-test/

[12] tcpdump. Van Jacobson, Craig Leres and Steven McCanne. Lawrence Berkeley National Laboratory, University of California, Berkeley, CA,

http://www.tcpdump.org

[13] PIONIER Polski Internet Optyczny, http://www.pionier.gov.pl

[14] GÉANT2 Network, http://www.geant2.net

[15] Agilent Technologies: Journal of Internet Test Methodologies.