Badanie efektywności protokołów rutingu rozgałęźnego w przewodowych sieciach pakietowych

Transkrypt

1 POLITECHNIKA POZNAŃSKA WYDZIAŁ ELEKTRONIKI I TELEKOMUNIKACJI Katedra Sieci Telekomunikacyjnych i Komputerowych Autoreferat rozprawy doktorskiej Badanie efektywności protokołów rutingu rozgałęźnego w przewodowych sieciach pakietowych Tomasz Bartczak Promotor: dr hab. inż Piotr Zwierzykowski Poznań 207

2 Spis treści Streszczenie Rozdział. Wprowadzenie Rozdział 2. Lightweight Protocol Independent Multicast Podstawowe mechanizmy Przykład działania protokołu LPIM Działanie protokołu wewnątrz domeny Działania protokołu pomiędzy domenami Podsumowanie Rozdział 3. Badania protokołu LPIM Wiadomości sterujące Liczba wiadomości Join(S,G) Liczba wiadomości Prune(S,G) Liczba wykorzystywanych liczników czasu Liczba operacji wykonywanych na licznikach Sumaryczny czas wykorzystania liczników czasu Komentarz Rozdział 4. Podsumowanie Bibliografia Dodatek A. Spis publikacji

3 Streszczenie Rozprawa doktorska dotyczy ważnego obszaru badań sieci teleinformatycznych jakim są protokoły rutingu. W rozprawie szczegółowo omówiono protokoły i mechanizmy wykorzystywane do zapewnienia komunikacji grupowej w sieciach pakietowych opartych na protokole IP. Szczególną uwagę autor poświęcił protokołom rutingu rozgałęźnego, które stanowiły główny obszar badań przedstawionych w rozprawie. Pracę rozpoczyna obszerne omówienie stanu badań obejmujące m.in. model Multicast IP oraz przegląd protokołów rutingu rozgałęźnego opracowanych dla sieci IP. W kolejnych rozdziałach przedstawiono protokoły rutingu stosowane w praktyce, ze szczególnym uwzględnieniem protokołów z rodziny PIM. Następne rozdziały zostały poświęcone propozycji nowego protokołu rutingu grupowego Lightweight Protocol Independent Multicast oraz obszernym badaniom symulacyjnym protokołów rutingu rozgałęźnego. Głównym celem rozprawy było zaproponowanie nowego protokołu rutingu rozgałęźnego, który będzie wyróżniał się mniejszą złożonością warstwy sterującej od dotychczasowych rozwiązań. Będzie więc w mniejszym stopniu obciążał węzły sieciowe (rutery) dzięki czemu usługi korzystające z komunikacji grupowej będą mogły być świadczone w większych sieciach oraz w sieciach, których węzły mają mniejsze zasoby obliczeniowe. Przedstawione wyniki badań symulacyjnych pozwalają na stwierdzenie, że cel ten został przez autora osiągnięty. Drugim, choć mniej istotnym, celem rozprawy było przeprowadzenie szerokiego zakresu badań porównawczych istniejących protokołów rutingu rozgałęźnego. Analizując literaturę przedmiotu autorowi nie udało się znaleźć badań, których zakres i obszerność, byłby podobne do badań przeprowadzonych w ramach pracy. Można zatem przyjąć, że również ten cel został osiągnięty. 2

4 Rozdział Wprowadzenie Rozprawa doktorska dotyczy ważnego obszaru badań sieci teleinformatycznych jakim są protokoły rutingu. W rozprawie szczegółowo omówiono protokoły i mechanizmy wykorzystywane do zapewnienia komunikacji grupowej w sieciach pakietowych opartych na protokole IP. Szczególną uwagę autor poświęcił protokołom rutingu rozgałęźnego, które stanowiły główny obszar badań przedstawionych w rozprawie. W sieciach wykorzystujących protokół IP (ang. Internet Protocol) komunikacja grupowa najczęściej opiera się na tzw. modelu Multicast IP. Model ten został zaproponowany przez Stevena Deeringa [2, 5, 6, 7]. Zakłada on wprowadzenie do sieci teleinformatycznej dwóch dodatkowych typów protokołów. Pierwszy rodzaj protokołów odpowiada za komunikację pomiędzy użytkownikiem końcowym, a węzłem sieci do którego ten użytkownik jest dołączony. Ich zadaniem jest przekazywanie informacji o zainteresowaniu użytkownika udziałem w komunikacji grupowej. Natomiast drugi rodzaj protokołów - protokoły rutingu rozgałeźngo - odpowiadają za budowę i utrzymywanie drzew komunikacji grupowej, które łączą nadawcę lub nadawców z odbiorcami. Model Multicast IP nie wymaga autoryzacji zarówno od nadawców, jaki i od odbiorców. Stwarza to potencjalne zagrożenie dla bezpiecznego działania systemów [25]. Model Deeringa zakłada także, że nadawcy i odbiorcy są niezależni. Oznacza to, że nadawcy nie znają listy odbiorców. Podobnie odbiorcy nie znają adresów nadawców, a do dołączenia do danej grupy wykorzystują jedynie adres IP grupy. Wynika z tego, że główny ciężar obsługi połączeń rozgałęźnych został powierzony protokołom rutingu rozgałęźnego. Wpływa to na ich stopień złożoności oraz ogranicza ich skalowalność, a więc również skalowalność modelu Multicast IP. 3

5 Wprowadzenie 4 Do najważniejszych protokołów rutingu rozgałęźnego w sieci IP zaliczamy protokoły rodziny PIM (Protocol Indepedent Multicast) tj. PIM-DM, PIM-SM oraz PIM-SSM. Protokół PIM-DM wspiera komunikację grupową zgodną ze scenariuszem wielu-do-wielu (ang. ASM - Any Source Multicast) []. Cechą szczególną komunikacji grupowej wielu-do-wielu jest mechanizm wykrywania nadawców. Protokół PIM-DM wykorzystuje do tego celu pakiety danych generowane przez wszystkich aktywnych nadawców, które propagowane są w całej sieci. Dzięki temu rozwiązaniu każdy ruter może jednoznacznie określić listę nadawców. Prostota zastosowanego mechanizmu wiąże się jednak z mało efektywnym wykorzystaniem zasobów sieciowych, co z kolei ogranicza zastosowanie protokołu PIM-DM jedynie do małych sieci. Protokół PIM-SM, podobnie jak PIM-DM, wspiera komunikację grupową wielu-do-wielu, ale stosuje inny mechanizm wykrywania nadawców [2]. Zgodnie z tym mechanizmem pakiety danych wysyłane przez nowego nadawcę przesyłane są do tzw. punktu spotkań (ang. Rendezvous Point (RP)). Punkt spotkań wraz z ruterami pośrednimi tworzy drzewo komunikacji grupowej (ang. RP Tree (RPT)), którego korzeniem jest punkt RP, a liśćmi rutery LHR (ang. Last Hop Routers). Punkt RP, przesyła strumienie danych nadawców, przy pomocy drzewa RPT, do odbiorców. Rutery LHR poza przesyłaniem strumieni danych do odbiorców, określają też listę nadawców uczestniczących w danym połączeniu rozgałęźnym. Dzięki temu mogą zażądać odpowiednich danych bezpośrednio od nadawców, eliminując w ten sposób nadmierną koncentrację danych w punkcie RP, co w konsekwencji prowadzi do zmniejszenia opóźnień przesyłania danych. Protokół PIM-SM jest bardziej skalowalny od protokołu PIM-DM, ale jest jednocześnie bardzo złożony i wymaga dużej ilości zasobów w warstwie sterującej sieci m.in. ze względu na bardziej złożony mechanizm wykrywania nadawców. PIM-SM może być z powodzeniem stosowany w sieciach średniej wielkości (np. sieci operatorskie). Komunikacja grupowa może być realizowana zgodnie z dwoma scenariuszami: wielu-do-wielu (ASM) oraz jeden-do-wielu (ang. SSM - Source Specific Multicast) [26]. Wszystkie do tej pory omawiane protokoły należące do rodziny protokołów PIM, przeznaczone są do realizacji połączeń rozgałęźnych w oparciu o scenariusz wielu-do-wielu. Coraz więcej usług sieciowych korzysta jednak z komunikacji grupowej w oparciu o scenariusz jeden-do-wielu, który pozwala na ograniczenie zbioru nadawców wysyłających dane do odbiorców danej grupy. Rozwiązanie takie wykorzystywane jest np. do dystrybucji danych giełdowych. Zmodyfikowana wersja protokołu PIM-SM służąca do obsługi komunikacji grupowej typu jeden-do-wielu nosi nazwę PIM-SSM (ang. Protocol Independent Multicast - Source- Specific Multicast). Główną zaletą protokołu PIM-SSM, w porównaniu z protokołem Rutery odpowiedzialne za przekazywanie danych komunikacji grupowej od nadawców do odbiorców

6 Wprowadzenie 5 PIM-SM, jest możliwość prostego wdrożenia w sieci teleinformatycznej. Pomimo różnic protokoły PIM-SM i PIM-SSM wykorzystują wiele wspólnych rozwiązań, które ograniczają ich skalowalność rozumianą jako zdolność do obsługi dużej liczby użytkowników rozrzuconych pomiędzy wiele systemów autonomicznych oraz możliwość równoczesnej obsługi dużej liczby połączeń rozgałęźnych. Zgodnie z najlepszą wiedzą autora nie opracowano do tej porty protokołu rutingu rozgałęźnego, który rozwiązywałby ten problem. Przedstawione rozważania doprowadziły do sformułowania następującej tezy pracy: Możliwe jest opracowanie nowego protokołu rutingu rozgałęźnego dla sieci IP, o mniejszej złożoności warstwy sterujacej (liczba wiadomości sterujacych, liczba operacji na licznikach) od dostępnych rozwiazań. Zaproponowany protokół umożliwi zwiększenie skalowalność komunikacji grupowej.

7 Rozdział 2 Lightweight Protocol Independent Multicast 2.. Podstawowe mechanizmy Protokół LPIM, podobnie jak PIM SSM, działa zgodnie ze scenariuszem jeden-do-wielu. Protokoły te realizują te same podstawowe funkcje, ale różnią się mechanizmami wykorzystywanymi do ich realizacji. Protokół LPIM wykorzystuje niektóre mechanizmy znane z protokołu PIM-SSM. Dlatego omawianie mechanizmów protokołu LPIM rozpoczniemy od przedstawienia sposobu działania protokołu PIM-SSM z uwzględnieniem wiadomości i liczników wykorzystywanych do tworzenia i utrzymywania drzewa komunikacji grupowej. Kolejno omawiane rozwiązania zostaną porównane z metodami zastosowanymi w protokole LPIM. Proces odświeżania struktury drzewa rozpinającego protokołu PIM SSM został przedstawiony na rysunku. Protokół PIM-SSM generuje wiadomości Join(S,G) i wysyła je przez każdy interfejs należący do drzewa komunikacji grupowej. Proces generacji wiadomości jest obsługiwany przed dwa liczniki Join Expiry Timer (ET) i Join Timer (JT). Licznik ET wykorzystywany jest przez ruter nadrzędny do śledzenia dostępności ruterów podrzędnych. Natomiast ruter podrzędny wykorzystuje licznik JT, do okresowego rozsyłania wiadomości Join(S,G). Ruter nadrzędny może więc wykryć brak ruterów podrzędnych i przerwać przesyłanie danych komunikacji grupowej. Jeśli ruter nadrzędny straci informacje o stanie drzewa rozpinającego, to na podstawie regularnie rozsyłanych wiadomości Join(S,G) 6

8 Lightweight Protocol Independent Multicast 7 Router nadrz dny Router podrz dny Wyga ni cie 2 Join(S,G) licznika JT Powtórne uruchomienie licznika ET 3 60s 5 Join(S,G) Wyga ni cie licznika JT 4 Powtórne uruchomienie licznika ET 6 Rysunek. Mechanizm odświeżania stanu drzewa rozpinającego protokołu PIM-SSM może je odtworzyć. Niestety takie rozwiązanie wprowadza dużą nadmiarowość związaną z przesyłaniem i przetwarzaniem wiadomości sterujących. W protokole LPIM zmodyfikowano nieefektywny mechanizm odświeżania stanu drzewa rozpinającego wykorzystywany w PIM-SSM (rysunek 2). Współczesne węzły sieci odpowiedzialne za ruting wykorzystują skomplikowane oprogramowanie, spełniające wymagania systemów czasu rzeczywistego, często stosują architektury wieloprocesorowe i obsługują równolegle wiele jednoczesnych zgłoszeń [9, 20, 24, 29, 33, 37, 39]. Duża złożoność zwiększa podatność systemów na błędy, które mogą prowadzić do wykonania niezamierzonych działań, ich zaniechania, zakleszczeń (ang. deadlock) i wielu innych. Wymienione ograniczenia mogą istotnie wpłynąć na niepoprawne działanie protokołów oraz na utratę stanu obsługiwanych połączeń. Niepoprawne działanie protokołu oraz strata danych stanu może zostać wykryta dzięki monitorowaniu procesów przez liczniki WD (ang. watchdog) lub przez wewnętrzne mechanizmy sprawdzenia poprawności działania oprogramowania (ang. assert). Wykrywanie błędów może być jednym z zadań stawianym przed mechanizmem tworzenia i aktualizacji bazy informacji o sąsiadach. Do tworzenia i aktualizacji bazy informacji o ruterach sąsiednich protokół PIM-SSM wykorzystuje okresowo generowane wiadomości Hello. W wiadomości Hello znajduje się m.in pole GenID (ang. Generation ID). Zmiana wartości tego pola oznacza, że sąsiedni ruter stracił informacje o obsługiwanych połączeniach rozgałęźnych. Protokół LPIM modyfikuje algorytm wymiany wiadomości Hello, wykorzystywany przez inne protokoły z rodziny PIM. W protokole Lightweight PIM rutery generują nową wartość pola GenID nie tylko w momencie aktywacji działania protokołu na danym interfejsie, ale także w odpowiedzi na stratę danych opisujących stan drzew rozpinających dla poszczegól- Wartość losowa, generowana jest każdorazowo podczas aktywowania maszyny stanu protokołu PIM dla danego interfejsu sieciowego, wliczając restarty wynikające z awarii [2]

9 Lightweight Protocol Independent Multicast 8 Router nadrz dny Router podrz dny Wyga ni cie licznika ET 2 PruneEcho(S,G) 3 Join(S,G) Czas przetwarzania Wyga ni cie licznika ET 4 5 PruneEcho(S,G) 600s 6 Join(S,G) Rysunek 2. Działanie mechanizmu zapytań protokołu LPIM nych połączeń rozgałęźnych. Takie działanie pozwala ruterom podrzędnym wykryć niepoprawne działanie rutera nadrzędnego. Przedstawiona modyfikacja sposobu wymiany wiadomości Hello nie jest jednak w pełni niezawodna i nie może zastąpić mechanizmu regularnej generacji wiadomości Join(S,G). Możliwe są sytuacje, w których ruter nadrzędny ulegnie awarii, a mechanizm regeneracji pola GenID, nie zadziała poprawnie. W takim przypadku ruter nadrzędny nie może przesyłać danych komunikacji grupowej, a rutery podrzędne nie zostały o tym poinformowane. Należy również rozważyć możliwość utraty wiadomości Prune(S,G), która została wysyłana przez ruter podrzędny opuszczający drzewo rozpinające. W takim przypadku ruter nadrzędny będzie kontynuował przesyłanie danych pomimo nieobecności ruterów podrzędnych zainteresowanych odbiorem danych. Rozwiązaniem, które przeciwdziała tego typu zjawiskom w protokole PIM-SSM jest wykorzystanie pary liczników JT oraz ET. Każdy ruter podrzędny stosuje licznik JT do wyznaczenia momentu wysłania okresowych wiadomości Join(S,G) (rysunek ). Ruter nadrzędny wykorzystuje z kolei licznik ET, który jest uruchamiany ponownie po otrzymaniu wiadomości Join(S,G). Jeśli wiadomości Join(S,G) przestaną napływać, to licznik ET osiąga wartość zero i przesyłanie danych do ruterów podrzędnych zostanie przerywane. Jeśli w danym segmencie sieci jest więcej niż jeden ruter podrzędny, to każdy z nich uruchamia oddzielną instancję licznika JT. Prowadzi to jednak do znacznego obciążenia zasobów pamięciowych i obliczeniowych ruterów podrzędnych. W przypadku protokołu LPIM rutery podrzędne wysyłają wiadomość Join(S,G) w odpowiedzi na zapytanie przesłane przez ruter nadrzędny (wiadomość PruneEcho(S,G)). W takim scenariuszu tylko ruter nadrzędny wykorzystuje licznik, który steruje wysyłaniem zapytań. Zastosowanie jednego licznika znacznie redukuje wykorzystanie zasobów przez pro-

10 Lightweight Protocol Independent Multicast 9 tokół LPIM. Rysunek 2 przedstawia wymianę wiadomości pomiędzy ruterem nadrzędnym i podrzędnym stosowaną przez protokół LPIM. Wskazany na rysunku czas przetwarzania uwzględnia również opóźnienia związane z obsługą sprzętową wiadomości, takie jak przesyłanie danych poprzez magistrale sprzętowe, obliczanie sum kontrolnych oraz transfery DMA (ang. Direct Memory Access). Czas przetwarzania obejmuje także obsługę zadań realizowanych przez oprogramowanie tj. obsługa przerwań, działanie maszyn stanu protokołu LPIM oraz generowanie wiadomości zwrotnej. Do monitorowania dostępności ruterów podrzędnych oraz odbudowy struktury drzewa rozpinającego protokół PIM-SSM wykorzystuje okresowe rozsyłanie wiadomości Join(S,G). Jeśli ruter nadrzędny ulegnie awarii i straci informacje związane ze stanem obsługiwanej komunikacji grupowej, to najpóźniej po 60 sekundach otrzyma wiadomość Join(S,G), która pozwoli na odbudowanie drzewa rozpinającego i wznowienie przesyłania danych. Protokół LPIM inaczej rozwiązuje ten problem. Nieprzerwany napływ strumienia danych i wiadomości Hello do rutera podrzędnego wskazuje, że ruter nadrzędny działa poprawnie. W takiej sytuacji regularne wiadomości Join(S,G) nie są generowane i rutery podrzędne odpowiadają jedynie na zapytania wysyłane przez ruter nadrzędny. W przypadku braku danych (np. w wyniku niepoprawnego działania routera nadrzędnego), rutery podrzędne rozpoczynają generacje okresowych wiadomości Join(S,G). Protokół PIM-SSM wykorzystuje wiadomości Join(S,G) również do zapobiegania przesyłaniu danych do ruterów, które nie obsługuję odbiorców komunikacji grupowej. Wiadomości te są przesłane co 60 sekund przez rutery podrzędne zainteresowane odbiorem komunikacji grupowej. Jeśli ruter nadrzędny nie odbierze wiadomości Join(S,G) przez 60 sekund, to uzna, że do danego rutera podrzędnego, nie ma dołączonych odbiorców. W przypadku protokołu LPIM to routery nadrzędne odpowiedzialne są za wysyłanie regularnych wiadomości PruneEcho(S,G), których celem jest sprawdzenie dostępności routerów podrzędnych. Sprawdzenie to ma na celu upewnienie się, że istnieją urządzenia odbiorcze dla przesyłanego strumienia danych. Przesyłanie danych bez urządzeń odbiorczych prowadzi do nieefektywnego wykorzystania zasobów sieciowych. Celem częstej generacji wiadomości Join(S,G) w protokole PIM-SSM jest minimalizacja ewentualnej przerwy w przesyłaniu danych. Sprawdzenia dokonywane przez protokół LPIM są mniej krytyczne, gdyż nie wpływają na niezawodność komunikacji grupowej. Zatem mogą odbywać się rzadziej, zmniejszając tym samym liczbę wiadomości sygnalizacyjnych, co w konsekwencji prowadzi do redukcji obciążenia ruterów ruchem sygnalizacyjnym. Przyjmuje się, że we współczesnych sieciach pakietowych większość awarii wynika z niepoprawnego działania łączy [23, 3]. Rutery LPIM do wykrycia uszkodzenia łączy wykorzystują m.in. zmianę statusu fizycznego łącza (np. łącze światłowodowe), odebranie wiadomości Hello ze zmienionym numerem GenID lub brak wiadomości Hello. Rutery

11 Lightweight Protocol Independent Multicast 0 podrzędne stosują także specjalną procedurę opuszczenia drzewa, która gwarantuje poinformowanie rutera nadrzędnego nawet w warunkach przeciążenia sieci. Wprowadzone rozwiązania praktycznie eliminują możliwość niewykrycia awarii lub niepoprawnego opuszczenia drzewa. Zatem prawdopodobieństwo przesyłania danych do urządzenia, które odłączyło się od drzewa, jest znikome. Dlatego przyjęto, że routery nadrzędne w protokole LPIM będą dokonywały sprawdzenia routerów podrzędnych co 600 sekund. Taka wartość używana jest w podobnych sytuacjach, także przez inne protokoły. 2 Przełączanie pakietów danych w ruterach realizowane jest zazwyczaj przez szybkie, dedykowane układy sprzętowe [30]. Protokół LPIM wymaga, aby te układy dodatkowo monitorowały obecności, bądź brak, danych przesyłanych w ramach poszczególnych połączeń rozgałęźnych i informowały o tym oprogramowanie zarządzające ruterem. Protokół PIM-SSM wykorzystuje wiadomość Join(S,G) do budowy gałęzi drzewa rozpinającego, natomiast wiadomość Prune(S,G) odpowiada za proces usuwania gałęzi drzewa rozpinającego. Protokół LPIM wykorzystuje także wiadomość Prune(S,G). Jednak proces usuwania gałęzi został zmodyfikowany. Kiedy ruter, na którym działa protokół PIM-SSM, opuszcza drzewo rozpinające, to wysyła wiadomość Prune(S,G) i usuwa z pamięci informacje o stanie tego połączenia. Ruter obsługujący protokół LPIM także wysyła wiadomość Prune(S,G), ale oczekuje na jej anulowanie, które spowoduje odebranie wiadomości Join(S,G) wysłanej przez inny ruter podrzędny albo na potwierdzenie jej odbioru przez ruter nadrzędny. Wprowadzenie w protokole LPIM innego mechanizmu usuwania gałęzi drzewa rozpinającego jest motywowane względami wydajnościowymi. Wiadomość Prune(S,G) może ulec zagubieniu i nie dotrzeć do rutera nadrzędnego. W przypadku protokołu PIM-SSM ruter nadrzędny zaprzestanie przekazywania danych, jeśli nie otrzyma wiadomości Join(S,G) przez ponad trzy minuty [2]. W przypadku protokołu LPIM (rysunek 2) ruter nadrzędny sprawdza dostępność ruterów podrzędnych co dziesięć minut [40]. Oznacza to, że taka konstrukcja może prowadzić do przekazywania danych przez dziesięć minut pomimo braku rutera podrzędnego oczekującego ich odbioru. W przypadku braku napływu pakietów danych, routery wykorzystujące protokół LPIM wysyłają cyklicznie wiadomości Join(S,G), analogicznie jak ma to miejsce dla protokołu PIM-SSM. W przypadku napływu pakietów danych ruter nadrzędny wysyła z małą częstotliwością zapytania PruneEcho(S,G). Takie rozwiązanie prowadzi do zmniejszenia ruchu sterującego i pozwala na zmniejszenie mocy obliczeniowej wymaganej przez procesy obsługujące protokół LPIM. Komunikacja rozgałęźna oparta na modelu Multicast IP zakłada, że każdy ruter na ścież- 2 Routery w protokole NDP (ang. Neighbor Discovery Protocol) [34] informują o swojej obecności co 0 minut. W protokole IRDP (ang. ICMP Router Discovery Protocol) [4] także domyślnie zaleca się aby routery anonsowały swą obecność co 600 sekund.

12 Lightweight Protocol Independent Multicast ce pomiędzy nadawcą a odbiorcą wspiera protokół rutingu rozgałęźnego. W praktyce trudno spełnić to wymaganie, zwłaszcza w dużych sieciach lub przy połączeniach kierowanych do odbiorców znajdujących się w różnych systemach autnomicznych. W literaturze przedmiotu można jednak spotkać podejścia, które próbują rozwiązać ten problem tj. protokoły hybrydowe oraz mechanizmy tunelowania [22, 28, 43, 4]. Protokoły hybrydowe zakładają wykorzystanie dwóch rodzajów protokołów rutingu: protokołów rutingu rozgałęźnego oraz protokołów rutingu działających w warstwie aplikacji. Preferowane są protokoły rutingu rozgałęźnego, a jeśli nie można ich wykorzystać, to stosowane są protokoły rutingu działające w warstwie aplikacji. Niestety protokoły hybrydowe charakteryzują się ograniczoną skalowalnością i niewielką stabilnością budowanych drzew. Mechanizm tunelowania znany pod nazwą Automatic Multicast Tunneling (AMT) umożliwia dystrybucję danych komunikacji grupowej, nawet wtedy gdy protokoły rutingu rozgałęźnego nie są powszechnie wdrożone [4]. AMT tuneluje strumienie danych przesyłane w ramach komunikacji grupowej, wykorzystując do tego celu tradycyjne połączenia punkt-punkt. Mechanizm AMT ma jednak pewne ograniczenia. Najważniejszym ograniczeniem AMT jest brak gwarancji przesyłania danych po najkrótszej ścieżce, co prowadzi do wzrostu opóźnień. Innym ograniczeniem tego mechanizmu jest jego sposób działania, który prowadzi do koncentracji ruchu. Zastosowanie mechanizmu AMT ogranicza także tradycyjny sposób przesyłania, który prowadzi do powielania ruch sieciowego. Protokoły PIM-SSM i LPIM różnią się istotnie w warstwie sterującej, natomiast w warstwie danych, za wyjątkiem monitorowania dostępności danych, stosują podobne rozwiązania. Zatem oba protokoły budują drzewa rozpinające o identycznej strukturze i charakteryzują je te same parametry takie jak: poziom strat pakietów, opóźnienie czy przepustowość. Proces budowy drzewa wykorzystuje mechanizm Reverse Path Forwarding (RPF) [3]. Mechanizm RPF służy do wyboru odpowiedniego interfejsu sieciowego, który zostanie użyty do przyłączenia danego rutera do drzewa rozpinającego. Zgodnie z procedurą po odebraniu pakietu danych, ruter sprawdza czy interfejs odbiorczy jest interfejsem, który leży na najkrótszej ścieżce prowadzącej do nadawcy. Jeśli wynik sprawdzenia jest pozytywny, to pakiet danych zostaje zaakceptowany i przesłany dalej. W przeciwnym wypadku pakiet jest ignorowany i nie podlega dalszemu przetwarzaniu. Mechanizm RPF pozwala nie tylko przesyłanie danych z najmniejszym możliwym opóźnieniem, ale przede wszystkim gwarantuje strukturę drzewa rozpinającego pozbawioną pętli. Protokół LPIM wykorzystuje także mechanizm pozwalający na realizację komunikacji grupowej w sieci Internet. Rysunek 3 przedstawia przykład komunikacji grupowej w sieci, której fragmenty wspierają komunikację grupową. Załóżmy, że uczestnik R zainteresowany jest odbiorem transmisji grupowej od nadawcy S. W tym celu generuje wiadomość IGMP Report(S,G), która jest odebrana i przetworzona przez sąsiedni ruter D. Ponieważ

13 Lightweight Protocol Independent Multicast 2 ruter D nie jest częścią drzewa rozpinającego, wysyła w kierunku nadawcy danych wiadomość Join(S,G) protokołu LPIM. Wiadomość Join(S,G) dociera do rutera C. Ruter C nie może jednak przekazać jej dalej, ponieważ ścieżka prowadząca do nadawcy S nie zapewnia komunikacji grupowej. W konsekwencji ruter C przekształca wiadomość Join(S,G) na jej odpowiednik wykorzystywany w połączeniach typu punkt-punkt, tj. wiadomość Unicast Join(S,G) i wysyła ją w kierunku nadawcy S. Ruter B otrzymuje wiadomość Unicast Join(S,G), przekształca ją do postaci właściwej dla protokołu LPIM. Następnie ruter B przekazuje wiadomość Join(S,G) dalej w kierunku nadawcy. Ostatecznie wiadomość Join(S,G) dociera do rutera A, do którego przyłączony jest nadawca. Proces budowy nowej gałęzi drzewa rozpinającego zostaje zakończony. Zauważmy, że nowo zbudowana gałąź nie jest homogeniczna. Składa się ona z dwóch odcinków wykorzystujących komunikację rozgałęźną oraz z odcinka, w którym komunikacja realizowana jest przez tunel typu punkt-punkt. Po odebraniu pakietów danych od nadawcy ruter pierwszego skoku A może rozpocząć przesyłanie danych przez nowo zbudowaną gałąź prowadzącą do rutera D. Następnie dane przesyłane są z wykorzystaniem drzewa komunikacji rozgałęźnej w kierunku rutera B. Ruter B dokonuje przekształcenia danych w pakiety danych typu punkt-punkt, których adresem docelowym jest ruter C. W kolejnym kroku ruter C dokonuje ponownego przekształcenia danych i przesyła je dalej w kierunku rutera D w oparciu o drzewo komunikacji grupowej. W ostatnim kroku ruter D przesyła dane do tego segmentu sieci, do którego przyłączony jest uczestnik komunikacji grupowej R. Opisane rozwiązanie ma pewne zalety. Dane zawsze przekazywane są po najkrótszej ścieżce,co pozwala na minimalizacja opóźnienia. Zmniejszane jest też prawdopodobieństwo wystąpienia koncentracji ruchu, a więc zmniejsza się ryzyko wystąpienia przeciążenia sieci i straty pakietów. W celu szczegółowego omówienia proponowanego protokołu w dalszej części rozdziału przedstawiono maszyny stanów interfejsu nadrzędnego i podrzędnego, maszynę umożliwiająca wybór dedykowanego rutera nadrzędnego, maszyny stanu obsługujące tunelowanie oraz przykład działania protokołu LPIM Przykład działania protokołu LPIM Rozdział ten przedstawia przykład działania omawianego protokołu wewnątrz domeny (rozdział 2.2.) i międzydomenami (rozdział 2.2.2) Działanie protokołu wewnatrz domeny Rysunek 4 przedstawia przykładową komunikację grupową zrealizowaną przy pomocy protokołu LPIM. W kroku pierwszym urządzenie R przyłącza się do grupy odbiorców.

14 Lightweight Protocol Independent Multicast 3 ród o S Router pierwszego skoku A B Router ostatniego skoku Sie niewspieraj ca C D komunikacji grupowej Uczestnik R IGMP Report(S,G) 2 Join(S,G) 3 Unicast Join(S,G) 4 Join(S,G) 5 Join(S,G) 6 Dane Rysunek 3. Przykład zastosowania mechanizmu tunelowania protokołu LPIM Sieć B Interfejs podrz dny Interfejs nadrz dny A Uczestnik R 4 Join(S,G) IGMP Report(S,G) -> stan J; Uruchom JET; JEC=0 5 JD->True: -> Stan Joined; Wy lij Join(S,G) 3 Lista interfejsów wyj. nie 2 jest pusta 6 Dane Rysunek 4. Przykład działania protokołu LPIM wewnątrz domeny

15 Lightweight Protocol Independent Multicast Źródło S Join(S,G) Chmura LPIM Unicast Join(S,G) Unicast Join(S,G) A B C Join(S,G) Chmura LPIM 7 IGMP Report(S,G) D F Uczestnik R Uczestnik R2 Join(S,G) IGMP Report(S,G) 6 Rysunek 5. Przykład działania tunelowania w protokole LPIM W tym celu wysyła wiadomość Report(S,G) protokołu IGMP (krok, rysunek 4). Po odebraniu wiadomości Report(S,G) lista interfejsów wyjściowych rutera A uczestniczących w komunikacji grupowej nie jest już pusta (krok 2, rysunek 4). Oznacza to, że funkcja JD dla rutera A przyjmuje wartość Prawda". Interfejs nadrzędny rutera A przechodzi do stanu Joined i wysyłana jest wiadomość Join(S,G) (krok 3 i 4, rysunek 4). Maszyna stanu interfejsu podrzędnego rutera B w odpowiedzi na wiadomość Join(S,G) przechodzi do stanu Join (krok 5, rysunek 4). W tym stanie uruchamiany jest licznik JET, którego zadaniem jest wysyłanie cyklicznych zapytań PruneEcho(S,G). Licznik JEC jest zerowany, ponieważ nie wysłano jeszcze żadnych zapytań PruneEcho(S,G). Ostatecznie w kroku 6 ruter B rozpoczyna przekazywanie danych na podstawie nowej struktury drzewa rozpinającego Działania protokołu pomiędzy domenami Rysunek 5 prezentuje przykładową sieć wykorzystującą protokół LPIM. W pierwszym kroku lokalny odbiorca komunikacji grupowej R przesyła wiadomość Report(S,G) protokołu IGMP. Wiadomość Report(S,G) odebrana jest przez ruter D. Lista interfejsów wyjściowych rutera D nie jest już pusta, dlatego funkcja JoinDesired zwraca wartość Prawda. W takim przypadku ruter D wysyła wiadomość Join(S,G) (krok 2, rysunek 5) i jego maszyna stanu interfejsu nadrzędnego przechodzi do stanu Joined. Wiadomość Join(S,G) przesyłana jest dalej poprzez kolejne rutery LPIM 3, aż dotrze do rutera C. Zauważmy, że ruter C jest urządzeniem brzegowym zlokalizowanym pomiędzy częścią sieci obsługującą protokół LPIM a Internetem. W celu umożliwienia przepływu danych w ramach komunikacji grupowej wymagane jest zestawienie tunelu. W chwili, gdy lista interfejsów wyjściowych routera C przestaje być pusta, funkcja JoinDesired(S,G) zwróci wartość Prawda. Zatem interfejs nadrzędny rutera C przechodzi w stan Joined. W stanie 3 Liczba ruterów obsługujących protokół LPIM może być bardzo duża i dlatego na rysunku oznaczono Chmura LPIM.

16 Lightweight Protocol Independent Multicast 5 Joined uruchomiony jest licznik JT i wysłana jest wiadomość Unicast Join(S,G). Jednocześnie jest tworzony wirtualny interfejs (krok 3, rysunek 5). Wiadomość Unicast Join(S,G) wysłana jest z adresem docelowym S, natomiast adresem wyjściowym pozostaje adres rutera C. W kroku 4 wiadomość Unicast Join(S,G) przesyłana jest przez ruter B dalej, w kierunku rutera A. Ruter A obsługuje protokół LPIM i przetwarza wiadomość Unicast Join(S,G). Ruter A w reakcji na otrzymaną wiadomość Unicast Join(S,G), tworzy nowy interfejs wirtualny i uruchamia licznik JET. Dane będą przesyłane na adres rutera C, który rozpoczął obsługę tunelu. Odebranie wiadomości Unicast Join(S,G) powoduje przyjęcie przez funkcję JD rutera A wartość Prawda. Ponieważ ruter A należy do domeny sieciowej obsługującej protokół LPIM, zmiana wartość funkcji JD z Fałsz na Prawda jest realizowana przez maszynę stanu interfejsu wewnątrzdomenowego. Ruter A wysyła wiadomość Join(S,G) (krok 5 na rysunku 5), co oznacza, że dochodzi do zmiany wiadomości Unicast Join(S,G) na jej odpowiednik w komunikacji grupowej Join(S,G). Po zestawianiu gałęzi drzewa rozpinającego pomiędzy ruterem pierwszego skoku obsługującym nadawcę S a ruterem A dane komunikacji grupowej przesyłane są do rutera A. W kolejnym kroku ruter A przesyła odebrane pakiety danych poprzez tunel do rutera C. Ruter C przesyła pakiety danych dalej z wykorzystaniem połączenia rozgałęźnego, aż do odbiorcy R. Zauważmy, że dołączenie do grupy odbiorców nowego odbiorcy R2 tworzy nową gałąź drzewa komunikacji grupowej rozciągającą się pomiędzy ruterami C i F (kroki 6 i 7, rysunek 5). Nie ma jednak potrzeby przesyłania kolejnego strumienia danych pomiędzy nadawcą a ruterem C, ponieważ ruter C replikuje dane otrzymywane poprzez tunel Podsumowanie Protokoły PIM-SSM i LPIM używają mechanizmu wymiany wiadomości Hello do wykrywania i monitorowania dostępności sąsiednich ruterów. Protokół LPIM wysyła wiadomość Hello ze zmienionym numerem GenerationID, także w reakcji na stratę danych sterujących opisujących stan komunikacji grupowej. W rezultacie rutery sąsiednie mogą szybko podjąć działania prowadzące do przywrócenia danych opisujących stan komunikacji grupowej (Tabela 2.). Protokół PIM-SSM wykorzystuje licznik ET do monitorowania ciągłości działania ruterów podrzędnych i ewentualnego zaprzestania przesyłania danych w sytuacji, gdy rutery podrzędne opuszczą strukturę drzewa rozpinającego bez poprawnej sygnalizacji. Każdy ruter podrzędny wykorzystuje licznik JT do sygnalizacji swojej obecności ruterowi nadrzędnemu. Protokół LPIM, w trakcie aktywnej komunikacji grupowej, wymaga ciągłego

17 Lightweight Protocol Independent Multicast 6 Tabela 2.. Porównanie protokołów PIM-SSM i LPIM Cecha PIM-SSM LPIM Wymiana wiadomości Używany do wykrycia i monitorowania ruterów Używany do wykrycia i monitorowania rute- Hello sąsiednich. rów sąsiednich. Dodatkowo wykorzystywa- ny do informowania o potencjalnej utracie danych sterujących. Mechanizm Assert Ten sam mechanizm używany jest przez oba protokoły. Tworzenie drzew rozpinających Oba protokoły wykorzystują Join(S,G) do tworzenia gałęzi drzewa rozpinającego. Usuwanie gałęzi Ruter opuszczający drzewo rozpinające wysyła wiadomość Prune(S,G). Ruter opuszczający drzewo rozpinające wysyła wiadomość Prune(S,G). Jednakże wiadomość ta musi być nadpisana przez Join(S,G) lub potwierdzona przez Prune- Ack(S,G). Opóźnienia transmisji Takie same. Oba protokoły budują drzewa rozpinające poprzez użycie najkrótszych ścieżek. Monitorowanie danych pakietów Utrzymanie drzewa rozpinającego Nadmiarowość Używane ze względu na wymagania mechanizmu Assert. Rutery podrzędne i nadrzędne nieprzerwanie działające liczniki, aby wysyłać i oczekiwać na okresowe wiadomości Join(S,G). Duża ze względu na dużą liczbę używanych liczników i częstą wymianę ruchu kontrolnego. Używane ze względu na wymagania mechanizmu Assert, jak również do monitorowania dostępności rutera nadrzędnego. Tylko rutery nadrzędne posiadają cały czas działające liczniki. Rutery podrzędne aktywują liczniki tylko przez krótki czas w celu wysłania wiadomości Join(S,G) będącej odpowiedzią na zapytanie PruneEcho(S,G). Mniejsza niż w protokole PIM-SSM. Tylko rutery nadrzędne utrzymują w sposób ciągły liczniki. Dodatkowo poprzez wykorzystanie monitorowania pakietów danych wiadomości sterujące wysyłane są rzadziej. Tunelowanie - Wykorzystuje tunelowanie, zwiększając tym samym zasięg komunikacji. wykorzystania licznika JET tylko przez ruter nadrzędny. Rutery podrzędne odpowiadają na zapytania PruneEcho(S,G) wysyłane przez ruter nadrzędny. Porównując protokół LPIM z protokołem PIM-SSM można zauważyć, że LPIM redukuje liczbę generowanych wiadomości sterujących zmniejszającą aktywność liczników i liczbę wymaganych operacji (Tabela 2.).

18 Rozdział 3 Badania protokołu LPIM W tym rozdziale przedstawiono rezultaty badań zaproponowanego w ramach pracy protokołu rutingu rozgałęźnego. Wyniki badań uzyskane dla protokołu LPIM (ang. Lightweight PIM) porównano z wynikami badań protokołu PIM-SSM, który oparty jest na takim samym scenariuszu komunikacji rozgałęźnej, z którego korzysta protokół LPIM. Podczas badań symulacyjnych przyjęto następujące założenia: badania prowadzono dla topologii sieci o wielkości od 00 do węzłów, średni stopień węzła wynosił 4 [35], topologie badanych sieci wyznaczone zostały na podstawie metody Barabasi-Alberta węzły nadawcze generowały 0 pakietów na sekundę, każdy o wielkości bajtów, wyniki wyznaczane były co 600 sekund. Prowadzone badania symulacyjne pozwoliły na dokładną ocenę liczby wymienianych wiadomości sterujących. Do oceny liczby wymienianych wiadomości sterujących wykorzystano pojęcie narzutu sygnalizacyjnego (ang. signaling overhead). Do jego oceny wykorzystuje się następujące parametry: całkowita liczba wymienianych wiadomości sterujących, liczba aktywnych liczników czasu, liczba operacji wykonywanych przez liczniki czasu, całkowity czas wykorzystania liczników specyficznych dla danego protokołu. W literaturze przedmiotu można spotkać się również z określeniem nadmiar sygnalizacyjny. 7

19 Badania protokołu LPIM 8 Zakładając ciągły przepływ danych, można przyjąć, że narzut sygnalizacyjny każdego spośród badanych protokołów jest stały i nie zależy od ilości przesyłanych danych oraz od ich charakteru. Z tego względu w prowadzonych badaniach przyjęto, że strumień przesyłanych danych jest ciągły i ma stałą przepływność (ang. Constant Bit Rate - CBR). Założono także, że generowane pakiety mają wielkość bajtów i że są wysyłane co 0, sekundy, a czas nadpisania (t_override) jest generowany zgodnie z rozkładem jednostajnym. Protokoły PIM-SSM oraz LPIM budują takie same drzewa dystrybucyjne, a więc parametry wykorzystywane do oceny efektywności protokołu w płaszczyźnie danych tj. opóźnienie, poziom strat pakietów oraz koszt drzewa są takie same i dlatego nie są prezentowane w tym rozdziale. W celu porównania charakterystyk protokołów PIM-SSM oraz LPIM wprowadzono również nowy parametr nazwany gęstością odbiorców: ρ = r n, (3.) gdzie ρ jest gęstością odbiorców, r jest liczbą odbiorców, a n jest liczbą węzłów. Porównanie właściwości protokołów LPIM i PIM-SSM przeprowadzono m.in. w zależności od całkowitej liczby wiadomości sterujących, liczby wiadomości Join i Prune, liczby wykorzystanych liczników czasu oraz liczby operacji wykonywanych przez liczniki czasu. 3.. Wiadomości sterujace W tym rozdziale przedstawiono relację pomiędzy liczbą wiadomości sterujących, których wymiana ma bezpośredni wpływ na zarządzanie drzewem dystrybucyjnym a danym protokołem rutingu. Na rysunku pokazano liczbę wymienianych wiadomości sterujących, związanych z pojedynczym połączeniem rozgałęźnym 2. Protokół LPIM generuje mniejszą liczbę wiadomości sterujących. Wyniki te potwierdzają wnioski z dyskusji teoretycznej przedstawionej w rozdziale 2. Ciągły system monitorowania strumienia danych, połączony z dodatkową funkcjonalnością wiadomości Hello, eliminuje potrzebę częstej wymiany pakietów sterujących. Protokół PIM-SSM wymaga od ruterów znajdujących się w dolnej części drzewa cyklicznego wysyłania (co 60 sekund) wiadomości Join(S,G). Natomiast protokół LPIM zapewnia, że rutery położone w dolnej części drzewa będą wysyłały wiadomości Join(S,G) tylko w odpowiedzi na bezpośrednie żądanie wysłane przez sąsiedni ruter, znajdujący się bliżej nadawcy. Rysunek 2 pokazuje zależność pomiędzy liczbą wiadomości sterujących a gęstością odbiorców. Także na tym wykresie można zauważyć, że liczba generowanych wiadomości sterujących jest niższa w przypadku protokołu LPIM. 2 Liczba wiadomości Hello nie jest brana pod uwagę.

20 Badania protokołu LPIM 9 Liczba wiadomości sterujących 00 0 Gęstość 0. Gęstość Liczba routerów Liczba wiadomości sterujących 00 0 Gęstość 0. Gęstość Liczba routerów (a) LPIM (b) PIM-SSM Rysunek. Liczba wiadomości sterujących w funkcji wielkości sieci Liczba wiadomości sterujących routerów 37 krawędzi routerów 997 krawędzi Liczba wiadomości sterujących routerów 37 krawędzi routerów 997 krawędzi Gęstość odbiorców (a) LPIM Gęstość odbiorców (b) PIM-SSM Rysunek 2. Liczba wiadomości sterujących jako funkcja gęstości odbiorców Rysunek 3.3(a) oraz rysunek 3.3(b) prezentują względną liczbę wiadomości sterujących 3 wymienianych w protokołach PIM-SSM oraz LPIM w zależności od zmiennej wielkości sieci i gęstości odbiorców. Wyniki pokazują, że protokół LPIM generuje średnio pięciokrotnie mniej wiadomości niż protokół PIM-SSM Liczba wiadomości Join(S,G) Rysunki 4 i 5 przedstawiają liczbę generowanych wiadomości Join(S,G) przez protokoły PIM-SSM oraz LPIM odpowiednio w funkcji liczby ruterów i gęstości odbiorców. Rutery stosujące protokół PIM-SSM wysyłają wiadomości Join(S,G) do sąsiednich ruterów położonych bliżej nadawcy, cyklicznie, co 60 sekund. Wynika to z konieczności odświeżenia lub zmiany (w przypadku uszkodzenia) stanu rutera. Natomiast protokół LPIM monitoruje przepływ danych. Zakłada się, że ciągły przepływ danych potwierdza poprawne działanie 3 Względna liczba wiadomości sterujących wyrażona jest jako stosunek liczby wiadomości wymienianych przez protokół PIM-SSM do liczby wiadomości protokołu LPIM.

21 Badania protokołu LPIM 20 Porównanie liczby wiadomości sterujących [%] 540 Gęstość odbiorców Liczba routerów Porównanie liczby wiadomości sterujących [%] 540 routerów Gęstość odbiorców (a) Stała gęstość (b) Stała wielkość sieci Rysunek 3. Względna liczba wymienianych wiadomości sterujących 0 0 Liczba wiadomości Join(S,G) 00 0 Gęstość 0. Gęstość Liczba routerów Liczba wiadomości Join(S,G) 00 0 Gęstość 0. Gęstość Liczba routerów (a) LPIM (b) PIM-SSM Rysunek 4. Liczba wiadomości Join(S,G) jako funkcja wielkości sieci rutera położonego bliżej nadawcy. Taka konstrukcja skutkuje mniejszą liczbą wiadomości Join(S,G) w protokole LPIM. Zjawisko to nie zależy od gęstości odbiorców i od liczby ruterów. Rysunek 6 przedstawia procentowe porównanie wydajności protokołów PIM-SSM oraz LPIM na podstawie liczby przesyłanych wiadomości Join(S,G) 4. Można stwierdzić, że zastosowanie protokołu prowadzi do 0-krotnej redukcji liczby wiadomości Join(S,G) w porównaniu z protokołem PIM-SSM Liczba wiadomości Prune(S,G) W przypadku protokołu LPIM rutery znajdujące się w dolnej części drzewa dystrybucyjnego nie generują cyklicznie wiadomości Join(S,G). Natomiast rutery położone bliżej nadawcy wysyłają zapytania (wiadomości PruneEcho(S,G)) do ruterów w dolnej części 4 Względna liczba wiadomości Join(S,G) wyrażona jest jako stosunek liczby wiadomości wymienianych przez protokół PIM-SSM do liczby wiadomości protokołu LPIM.

22 Badania protokołu LPIM 2 Liczba wiadomości Join(S,G) routerów 37 krawędzi routerów 997 krawędzi Liczba wiadomości Join(S,G) routerów 37 krawędzi routerów 997 krawędzi Gęstość odbiorców (a) LPIM Gęstość odbiorców (b) PIM-SSM Rysunek 5. Liczba wiadomości Join(S,G) jako funkcja gęstości odbiorców Porównanie liczby wiadomości Join(S,G) [%] 00 Gęstość odbiorców Liczba routerów Porównanie liczby wiadomości Join(S,G) [%] 00 routerów Gęstość odbiorców (a) Stała gęstość (b) Stała wielkość sieci Rysunek 6. Względna liczba wymienianych wiadomości Join(S,G) drzewa. W przeciwieństwie do protokołu LPIM rutery PIM-SSM wysyłają wiadomość Join(S,G) cyklicznie, niezależnie od ruterów położonych bliżej nadawcy. W sytuacji, gdy drzewo jest stabilne, tzn. żaden odbiorca nie opuszcza grupy, rutery PIM-SSM nie generują wiadomości Prune(S,G). Wyniki przedstawione na rysunkach 7 oraz 8 potwierdzają przedstawione wnioski. Warto zwrócić uwagę również na liczbę wiadomości Prune(S,G) generowanych przez protokół LPIM. Liczba ta jest równa liczbie wiadomości Join(S,G) przedstawionych na rysunkach 3.4(a) oraz 3.5(a). Wynik ten jest zgodny z oczekiwaniem, ponieważ rutery LPIM położone w dolnej części drzewa generują wiadomości Join(S,G) w odpowiedzi na wiadomości PruneEcho(S,G) przesłane przez rutery położone bliżej nadawcy danych Liczba wykorzystywanych liczników czasu Wyniki przedstawione na rysunkach 9, 0 oraz wskazują na identyczną liczbę liczników wykorzystywaną w obu protokołach.

23 Badania protokołu LPIM 22 Liczba wiadomości Prune(S,G) Gęstość 0. Gęstość Liczba routerów Rysunek 7. Liczba generowanych wiadomości Prune(S,G) jako funkcja wielkości sieci 3.5. Liczba operacji wykonywanych na licznikach Każda operacja pojedynczego licznika, tj. uruchomienie i zatrzymanie, wykorzystuje określoną ilość zasobów obliczeniowych. Duża liczba takich operacji może mieć znaczący wpływ na wydajność rutera. Chociaż protokoły LPIM i PIM-SSM mają taką samą liczbę liczników, to LPIM zmniejsza wykorzystanie zasobów pojedynczego licznika. Ilustrują to wyniki przedstawione na rysunkach 2 oraz 3, które pokazują, że niezależnie od gęstości odbiorców i liczby nadawców protokół LPIM wykonuje zdecydowanie mniej operacji na licznikach. Routery podrzędne obsługujące protokół PIM-SSM generują co 60 sekund wiadomości Join(S,G). Natomiast podrzędne rutery LPIM nie rozsyłają regularnie wiadomości Join(S,G). Odpowiadają na zapytania wysyłane co 600 sekund przez rutery znajdujące się bliżej nadawcy. Rysunek 4 pokazuje, że takie działanie ogranicza znacząco aktywność liczników czasu protokołu LPIM 5 i prowadzi do redukcji mocy obliczeniowej zużywanej przez operacje zależne do aktywności liczników Sumaryczny czas wykorzystania liczników czasu Każdy aktywny licznik czasu zużywa pewną ilość pamięci i mocy obliczeniowej. Wraz ze wzrostem wielkości sieci rośnie liczba wymaganych liczników, a więc również zużycie zasobów ruterów. Zatem zużycie zasobów przez liczniki stanowi jedno z ograniczeń skalowalności protokołu i dlatego warto dążyć do jego minimalizacji. 5 Względna liczba operacji wykonywanych na licznikach wyrażona jest jako stosunek liczby operacji protokołu PIM-SSM do liczby operacji protokołu LPIM.

24 Badania protokołu LPIM 23 Liczba wiadomości Prune(S,G) routerów 37 krawędzi routerów 997 krawędzi Gęstość odbiorców Rysunek 8. Liczba generowanych wiadomości Prune(S,G) jako funkcja gęstości odbiorców Gęstość 0. Gęstość Gęstość 0. Gęstość 0.5 Liczba liczników Liczba liczników Liczba routerów Liczba routerów (a) LPIM (b) PIM-SSM Rysunek 9. Liczba wykorzystanych liczników czasu jako funkcja wielkości sieci Rysunek 5 oraz 6 przedstawiają całkowity czas działania liczników dla protokołów PIM-SSM oraz LPIM. Podczas transmisji danych rutery LPIM położone w dolnej części drzewa włączają liczniki tylko w odpowiedzi na wiadomości PruneEcho(S,G). Dzięki temu protokół LPIM uruchamia liczniki tylko przez ograniczony czas, co pozwala na zmniejszenie wykorzystywanych zasobów (rysunek 5 oraz 6). Rysunek 7 pokazuje, że dla symulowanych sieci aktywność liczników czasu w protokole PIM-SM jest dwukrotnie dłuższa od aktywności liczników czasu w protokole LPIM 6. Symulowana sieć składała się z łączy punkt-punkt. W każdym segmencie drzewa można więc zawsze znaleźć jeden ruter bliżej nadawcy i jeden w dolnej części drzewa. PIM-SSM wymaga od ruterów położonych bliżej nadawcy oraz od ruterów w dolnej części drzewa nieprzerwanej obsługi liczników czasu. 6 Względny czas aktywności liczników wyrażony jest jako stosunek czasu aktywności liczników protokołu PIM-SSM do czasu aktywności liczników protokołu LPIM.

25 Badania protokołu LPIM routerów 37 krawędzi routerów 997 krawędzi routerów 37 krawędzi routerów 997 krawędzi Liczba liczników Liczba liczników Gęstość odbiorców Gęstość odbiorców (a) LPIM (b) PIM-SSM Rysunek 0. Liczba wykorzystanych liczników czasu jako funkcja gęstości odbiorców 05 Gęstość odbiorców routerów Porównanie liczby liczników [%] Porównanie liczby liczników [%] Liczba routerów (a) Stała gęstość Gęstość odbiorców (b) Stała wielkość sieci Rysunek. Względna liczba wykorzystanych liczników czasu

26 Badania protokołu LPIM 25 Liczba operacji na licznikach Gęstość 0. Gęstość Liczba routerów Liczba operacji na licznikach Gęstość 0. Gęstość Liczba routerów (a) LPIM (b) PIM-SSM Rysunek 2. Liczba operacji na licznikach jako funkcja wielkości sieci Liczba operacji na licznikach routerów 37 krawędzi routerów 997 krawędzi Liczba operacji na licznikach routerów 37 krawędzi routerów 997 krawędzi Gęstość odbiorców (a) LPIM Gęstość odbiorców (b) PIM-SSM Rysunek 3. Liczba operacji na licznikach jako funkcja gęstości odbiorców W przypadku LPIM tylko ruter położony bliżej nadawcy w sposób ciągły utrzymuje licznik czasu. Ruter położony w dolnej części drzewa aktywuje licznik wyłącznie w odpowiedzi na wiadomości PruneEcho(S,G). W przypadku symulowanych sieci protokół LPIM prowadzi do 50% redukcji całkowitego czasu aktywności liczników zaobserwowanego na rysunku 7. Podsumowanie. Podsumowując można stwierdzić, że opracowany w ramach pracy protokół rutingu rozgałęźnego LPIM wymaga mniejszej liczby wiadomości sterujących od protokołu PIM-SSM. Wymaga też mniejszej liczby operacji oraz czasu wykorzystywania liczników. Zatem umożliwia on świadczenie usług wykorzystujących komunikację grupową w bardziej elastyczny, a więc również skalowalny sposób. Dotyczy to również połączeń rozgałęźnych, w których odbiorcy rozmieszczeni są w różnych systemach autonomicznych. Przeprowadzone badania wykazują, że te cechy protokołu LPIM nie zmieniają się nawet w dużych sieciach.

27 Badania protokołu LPIM 26 Porównanie liczby operacji na licznikach [%] 700 Gęstość odbiorców Liczba routerów Porównanie liczby operacji na licznikach [%] 700 routerów Gęstość odbiorców (a) Stała gęstość (b) Stała wielkość sieci Rysunek 4. Względna liczba operacji na licznikach 8e+08 7e+08 Gęstość 0. Gęstość 0.5 8e+08 7e+08 Gęstość 0. Gęstość 0.5 6e+08 6e+08 Czas całkowity 5e+08 4e+08 3e+08 Czas całkowity 5e+08 4e+08 3e+08 2e+08 2e+08 e+08 e Liczba routerów Liczba routerów (a) LPIM (b) PIM-SSM Rysunek 5. Skumulowany czas uruchomienia liczników jako funkcja wielkości sieci 9e+08 8e routerów 37 krawędzi routerów 997 krawędzi 9e+08 8e routerów 37 krawędzi routerów 997 krawędzi 7e+08 7e+08 Czas całkowity 6e+08 5e+08 4e+08 3e+08 Czas całkowity 6e+08 5e+08 4e+08 3e+08 2e+08 2e+08 e+08 e Gęstość odbiorców Gęstość odbiorców (a) LPIM (b) PIM-SSM Rysunek 6. Skumulowany czas uruchomienia liczników jako funkcja gęstości odbiorców