Badanie efektywno´sci protokołów rutingu rozgał˛e´znego w przewodowych sieciach pakietowych

(1)

Katedra Sieci Telekomunikacyjnych i Komputerowych

Badanie efektywno´sci protokołów rutingu rozgał˛e´znego w przewodowych

sieciach pakietowych

Tomasz Bartczak

Rozprawa doktorska przedło˙zona Radzie Wydziału

Elektroniki i Telekomunikacji Politechniki Pozna´nskiej

Promotor:

dr hab. in˙z. Piotr Zwierzykowski

Pozna´n 2017

(2)

Streszczenie . . . 4

Abstract . . . 5

Rozdział 1. Wprowadzenie . . . 6

Rozdział 2. Komunikacja grupowa w sieciach IP . . . 10

2.1. Wprowadzenie . . . 10

2.2. Wewn ˛atrzdomenowe protokoły rutingu rozgał˛e´znego . . . 11

2.2.1. Distance Vector Multicast Routing Protocol . . . 11

2.2.2. Multicast Extensions to Open Shortest Path First . . . 14

2.2.3. Core Based Trees . . . 15

2.2.4. Protocol Independent Multicast - Dense Mode . . . 18

2.2.5. Protocol Independent Multicast - Sparse Mode . . . 20

2.2.6. Bidirectional Protocol Independent Multicast . . . 22

2.2.7. Hierarchical DVMRP . . . 24

2.2.8. Hierarchical Protocol Independent Multicast . . . 26

2.3. Mi˛edzydomenowe protokoły rutingu rozgał˛e´znego . . . 29

2.3.1. Multiprotocol Border Gateway Protocol . . . 30

2.3.2. Multicast Source Discovery Protocol . . . 32

1

(3)

2.3.3. Border Gateway Multicast Protocol . . . 34

2.4. Podsumowanie . . . 36

Rozdział 3. Protocol Independent Multicast - Sparse Mode i Source Specific Multicast . . . 41

3.2. PIM Sparse Mode . . . 42

3.2.1. Zasada działania . . . 42

3.2.2. Wymiana wiadomo´sci Hello . . . 43

3.2.3. Tunel pomi˛edzy ruterem FHR i RP . . . 44

3.2.4. Proces konstrukcji drzewa . . . 45

3.2.5. Wymiana wiadomo´sci Assert . . . 49

3.2.6. Podsumowanie . . . 51

3.3. PIM Source Specific Multicast . . . 53

3.3.1. Opis protokołu PIM-SSM . . . 53

3.3.2. Podsumowanie . . . 54

Rozdział 4. Lightweight Protocol Independent Multicast . . . 56

4.2. Podstawowe mechanizmy protokołu LPIM . . . 57

4.3. Maszyna stanu interfejsu nadrz˛ednego . . . 63

4.4. Maszyna stanu interfejsu podrz˛ednego . . . 68

4.5. Maszyna stanu dla mechanizmu wyboru rutera nadrz˛ednego . . . 71

4.6. Mechanizm tunelowania . . . 73

4.6.1. Maszyna stanu interfejsu nadrz˛ednego . . . 74

4.6.2. Maszyna stanu interfejsu podrz˛ednego obsługuj ˛acego . . . 75

4.7. Przykład działania protokołu LPIM . . . 77

4.7.1. Działanie protokołu wewn ˛atrz domeny . . . 77

4.7.2. Działania protokołu pomi˛edzy domenami . . . 77

4.8. Podsumowanie . . . 79

(4)

Rozdział 5. ´Srodowisko symulacyjne . . . 81

5.2. Topologie sieci testowych . . . 81

5.3. Metody oceny ´srodowiska symulacyjnego . . . 83

5.4. Opis ´srodowiska symulacyjnego . . . 84

5.5. Podsumownie . . . 86

Rozdział 6. Badania symulacyjne . . . 87

6.2. Testy statyczne protokołów PIM w ´srodowisku ns-2 . . . 87

6.3. Testy dynamiczne protokołów PIM w ´srodowisku ns-2 . . . 89

6.4. Badania protokołów rodziny PIM . . . 95

6.5. Badania protokołu LPIM . . . 97

6.5.1. Wiadomo´sci Hello . . . 99

6.5.2. Wiadomo´sci steruj ˛ace . . . 100

6.5.3. Liczba wiadomo´sci Join(S,G) . . . 102

6.5.4. Liczba wiadomo´sci Prune(S,G) . . . 103

6.5.5. Liczba wykorzystywanych liczników czasu . . . 105

6.5.6. Liczba operacji wykonywanych na licznikach . . . 105

6.5.7. Sumaryczny czas wykorzystania liczników czasu . . . 106

6.6. Komentarz . . . 109

Rozdział 7. Podsumowanie . . . 110

Spis rysunków . . . 112

Spis tabel . . . 115

Spis algorytmów . . . 116

Bibliografia . . . 117

(5)

Rozprawa doktorska dotyczy wa˙znego obszaru badań sieci teleinformatycznych jakim s ˛a 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 ˛a uwag˛e autor po´swi˛ecił protokołom rutingu rozgał˛e´znego, które stanowiły główny obszar badań przedstawionych w rozprawie. Prac˛e rozpoczyna obszerne omówienie stanu badań obejmuj ˛ace m.in. model Multicast IP oraz przegl ˛ad protokołów rutingu rozgał˛e´znego opracowanych dla sieci IP. W kolejnych rozdziałach przedstawiono protokoły rutingu stosowane w sieciach produkcyjnych, ze szczególnym uwzgl˛ednieniem protokołów z rodziny PIM. Nast˛epne rozdziały zostały po´swi˛econe propozycji nowego pro- tokołu rutingu grupowego Lightweight Protocol Independent Multicast oraz obszernym ba- daniom symulacyjnym protokołów rutingu rozgał˛e´znego.

Głównym celem rozprawy było zaproponowanie nowego protokołu rutingu rozgał˛e´znego, który b˛edzie wyró˙zniał si˛e mniejsz ˛a zło˙zono´sci ˛a warstwy steruj ˛acej od dotychczaso- wych rozwi ˛azań. B˛edzie wi˛ec w mniejszym stopniu obci ˛a˙zał w˛ezły sieciowe (rutery) dzi˛eki czemu usługi korzystaj ˛ace z komunikacji grupowej b˛ed ˛a mogły być ´swiadczone w wi˛ek- szych sieciach oraz w sieciach, których w˛ezły maj ˛a mniejsze zasoby obliczeniowe. Przed- stawione wyniki badań symulacyjnych pozwalaj ˛a na stwierdzenie, ˙ze cel ten został przez autora osi ˛agni˛ety. Drugim, choć mniej istotnym, celem rozprawy było przeprowadzenie szerokiego zakresu badań porównawczych istniej ˛acych protokołów rutingu rozgał˛e´znego.

Analizuj ˛ac literatur˛e przedmiotu autorowi nie udało si˛e znale´zć badań, których zakres i obszerno´sć, byłby podobne do badań przeprowadzonych w ramach pracy. Mo˙zna zatem przyj ˛ać, ˙ze równie˙z ten cel został osi ˛agni˛ety.

4

(6)

The thesis deals with an important area of research in data communication networks such as routing protocols. In the work the protocols and mechanisms used to provide group-based communications over IP-based packet-switched networks have been discussed. Particular attention was paid to the multicast routing protocols, which form the main scope of research presented at the work. The thesis begins with a comprehensive discussion of the state of the art including the Multicast IP model and the overview of the multicast routing protocols developed for IP networks, such as DVMRP, H-DVMRP, MOSPF, CBT, PIM-DM, PIM-SM, PIM-SSM, Bidirectional or Hierarchical PIM. The following chapters show the routing protocols used in production networks, with particular reference to the PIM protocols.

The following chapters describe the proposal of the new Lightweight Protocol Independent Multicast and results of the comprehensive simulation of the multicast routing protocols.

The main purpose of the thesis was to propose a new multicast routing protocol that would be distinguished by the smaller complexity of the control plane from the existing solutions. Therefore, it will be less burdensome for network nodes (routers), so that services using group communications will being offered users located in larger networks or on networks with nodes of fewer resources. By analyzing the results of the simulation research, it can be stated that this goal was reached by the author of the work. The second, albeit slightly less important, objective was to conduct a broad range of comparative studies of existing multicast routing protocols. This goal has also been achieved, and the scope of simulation studies conducted by the author do not find counterparts in the literature of the subject.

5

(7)

Wprowadzenie

Jeste´smy ´swiadkami dynamicznego rozwoju sieci teleinformatycznych. Zmieniaj ˛a si˛e protokoły oraz technologie, dzi˛eki którym sieci mog ˛a przesyła´c coraz wi˛ecej danych [103].

Rozwój sieci pozwala na wprowadzanie coraz bardziej zaawansowanych usług takich jak Voice over IP (VoIP) [34, 120], wideokonferencje [57], wideo na ˙z ˛adanie (VoD) [77, 98, 117], Internet Protocol Television (IPTV) [81, 90, 98] oraz przetwarzanie w chmurze [47].

Rosn ˛acej popularno´sci zaawansowanych usług towarzyszy wzrost obci ˛a˙zenia zasobów sieciowych. Powoduje to konieczno´sć poszukiwania rozwi ˛azań, które pozwol ˛a na zwi˛ekszenie efektywno´sci wykorzystywanych zasobów. Jednym z takich rozwi ˛azań jest komunikacja grupowa. Komunikacja grupowa pozwala na przesyłanie jednego strumienia, zamiast wielu strumieni, danych. Strumień ten jest zwielokrotniony tylko wtedy gdy jest to konieczne, co pozwala na znaczne zmniejszenie obci ˛a˙zenia zasobów sieci.

W sieciach wykorzystuj ˛acych protokół IP (ang. Internet Protocol) komunikacja grupowa najcz˛e´sciej opiera si˛e na tzw. modelu Multicast IP. Model ten został zaproponowany przez Stevena Deeringa [31, 37, 38, 39]. Zakłada on wprowadzenie do sieci teleinformatycznej dwóch dodatkowych typów protokołów. Pierwszy typ protokołów odpowiada za komunikacj˛e pomi˛edzy u˙zytkownikiem ko´ncowym, a w˛ezłem sieci do którego ten u˙zytkownik jest doł ˛aczony. Zadaniem protokołów tego typu jest przekazywanie informacji o zainteresowa- niu u˙zytkowników udziałem w komunikacji grupowej. Drugi rodzaj protokołów odpowiada natomiast za rozsyłanie danych pomi˛edzy nadawcom i odbiorcami komunikacji grupowej.

6

(8)

Protokoły tego typu odpowiedzialne s ˛a za budowanie i utrzymanie drzewa komunikacji grupowej.

Model Multicast IP nie wymaga autoryzacji zarówno od nadawców, jaki i od odbiorców.

Stwarza to potencjalne zagro˙zenie dla bezpiecznego działania systemów, poniewa˙z operato- rzy sieci nie mog ˛a kontrolowa´c kto nadaje i odbiera dane [60]. Model Deeringa zakłada tak-

˙ze, ˙ze nadawcy i odbiorcy s ˛a niezale˙zni. Oznacza to, ˙ze nadawcy nie znaj ˛a listy odbiorców.

Podobnie odbiorcy nie znaj ˛a adresów nadawców, a do doł ˛aczenia do danej grupy wykorzystuj ˛a jedynie adres IP grupy. Wynika z tego, ˙ze główny ci˛e˙zar obsługi poł ˛aczeń rozgał˛e´znych został powierzony protokołom rutingu rozgał˛e´znego. Wpływa to na ich stopień zło˙zono´sci oraz ogranicza ich skalowalno´sć, a wi˛ec równie˙z skalowalno´sć modelu Multicast IP.

W wielu mi˛edzynarodowych o´srodkach naukowo-badawczych prowadzono prace, któ- rych celem były algorytmy, mechanizmy i protokoły rutingu rozgał˛e´znego, które mo˙zna wykorzysta´c równie˙z w ramach modelu Multicast IP [4, 5, 27, 69, 71, 78, 99, 106, 107, 110, 111, 112, 6, 121, 126]. W grupie tej znajduj ˛a si˛e równie˙z protokoły rutingu, które zostały opracowane przez IETF (ang. Internet Engineering Task Force), zaliczamy do nich PIM-DM [7], PIM-SM [49], PIM-SSM [49] oraz Bidir-PIM [59].

Protokół PIM-DM wspiera komunikacj˛e grupow ˛a zgodn ˛a ze scenariuszem wielu-do-wielu (ang. ASM - Any Source Multicast) [7]. Cech ˛a szczególn ˛a 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 ˛a w całej sieci. Dzi˛eki temu rozwi ˛azaniu ka˙zdy ruter mo˙ze jednoznacznie okre´sli´c list˛e nadawców. Prostota zastosowanego mechanizmu wi ˛a˙ze si˛e 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˛e grupow ˛a wielu-do-wielu, ale stosuje inny mechanizm wykrywania nadawców [49]. Zgodnie z tym mechanizmem pakiety danych wysyłane przez nowego nadawc˛e przesyłane s ˛a do tzw.

punktu spotkań (ang. Rendezvous Point (RP)). Punkt spotkań wraz z ruterami po´srednimi¹ tworzy drzewo komunikacji grupowej (ang. RP Tree (RPT)), którego korzeniem jest punkt RP, a li´sć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´slaj ˛a te˙z list˛e nadawców uczestnicz ˛acych w danym poł ˛aczeniu rozgał˛e´znym. Dzi˛eki temu mog ˛a za˙z ˛adać odpowiednich danych bezpo´srednio od nadawców, eliminuj ˛ac w ten sposób nadmiern ˛a koncentracj˛e danych w punkcie RP, co w konsekwencji prowadzi do zmniejszenia opó´znień przesyłania danych. Protokół PIM-SM jest bardziej skalowalny od protokołu PIM-DM, ale jest jednocze´snie bardzo zło˙zony

1 Rutery odpowiedzialne za przekazywanie danych komunikacji grupowej od nadawców do odbiorców

(9)

i wymaga du˙zej ilo´sci zasobów w warstwie steruj ˛acej sieci m.in. ze wzgl˛edu na bardziej zło˙zony mechanizm wykrywania nadawców. PIM-SM mo˙ze by´c z jednak powodzeniem stosowany w sieciach ´sredniej wielko´sci (np. sieci operatorskie).

Protokół Bidir-PIM (ang. Bidirectional Protocol Independent Multicast) [59] zapewnia komunikacj˛e dwukierunkow ˛a, co wyró˙znia go z całej rodziny protokołów PIM i nie pozo- staje bez wpływu na jego zło˙zono´s´c. Protokół ten umo˙zliwia obsług˛e drzew komunikacji grupowej o bardzo du˙zej wielko´sci, ale jego ograniczeniem mo˙ze by´c znaczne opó´znienie przesyłanych danych. Protokół Bidir-PIM został opracowany dla komunikacji grupowej opartej na scenariuszu wielu-do-wielu. Protokół ten, główenie z uwagi na wprowadzane opó´znienia, nie jest wykorzystywany w praktyce.

Komunikacja grupowa mo˙ze by´c realizowana zgodnie z dwoma scenariuszami:

wielu-do-wielu (ASM) oraz jeden-do-wielu (ang. SSM - Source Specific Multicast) [67].

Wszystkie do tej pory omawiane protokoły nale˙z ˛ace do rodziny protokołów PIM, przezna- czone s ˛a do realizacji poł ˛acze´n rozgał˛e´znych w oparciu o scenariusz wielu-do-wielu. Coraz wi˛ecej 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 ˛acych dane do odbiorców danej grupy. Rozwi ˛azanie takie wykorzystywane jest np. do dystrybucji danych giełdowych.

Zmodyfikowana wersja protokołu PIM-SM słu˙z ˛aca do obsługi komunikacji grupowej typu jeden-do-wielu nosi nazw˛e PIM-SSM (ang. Protocol Independent Multicast - Source- Specific Multicast). Główn ˛a zalet ˛a protokołu PIM-SSM, w porównaniu z protokołem PIM-SM, jest mo˙zliwo´sć prostego wdro˙zenia w sieci teleinformatycznej. Pomimo ró˙znic, protokoły PIM-SM i PIM-SSM wykorzystuj ˛a wiele wspólnych rozwi ˛azań, które ograniczaj ˛a ich skalowalno´sć rozumian ˛a jako zdolno´sć do obsługi du˙zej liczby u˙zytkowników rozrzu- conych pomi˛edzy wiele systemów autonomicznych oraz mo˙zliwo´sć równoczesnej obsługi du˙zej liczby poł ˛aczeń rozgał˛e´znych.

Ograniczona skalowalno´s´c protokołów opracowanych w ramach modelu Multicast IP jest jedn ˛a z głównych przyczyn, dla których nie s ˛a one cz˛esto wykorzystywane w Internecie.

Podejmowano wiele ró˙znych prób rozwi ˛azania tego problemu np. poprzez wykorzystywanie wspólnych drzew komunikacji grupowej [66], rozwi ˛azania hybrydowe wykorzystuj ˛ace roz- gał˛ezienie poł ˛aczenia w warstwie sieciowej i w warstwie aplikacji (ang. Application Layer Multicast) [53, 72, 134],, czy te˙z automatyczne tunelowanie strumieni danych przesyłanych w ramach poł ˛acze´n rozgał˛e´znych (ang. Automatic Multicast Tunnelling) [52, 126]. Jednak

˙zadne spo´sród nich nie umo˙zliwia efektywnej komunikacji grupowej obejmuj ˛acej wielu od- biorców, rozmieszczonych w ró˙znych systemach autonomicznych, zapewniaj ˛ac przy tym opó´znienie pakietów na poziomie akceptowalnym przez współczesne usługi multimedialne tj. IPTV czy VoIP.

(10)

Przedstawione rozwa˙zania doprowadziły do sformułowania nast˛epuj ˛acej tezy pracy:

Mo˙zliwe jest opracowanie nowego protokołu rutingu rozgał˛e´znego dla sieci IP, o mniejszej zło˙zono´sci warstwy steruj ˛acej (liczba wiadomo´sci steruj ˛acych, liczba operacji na licznikach) od dost˛epnych rozwi ˛aza´n. Zaproponowany protokół umo˙zliwi zwi˛ekszenie skalowalno´s´c komunikacji grupowej.

Prac˛e podzielono na sze´sć rozdziałów. Rozdział 2 przedstawia przegl ˛ad najwa˙zniej- szych protokołów rutingu wykorzystywanych w modelu Multicast IP. Kolejny rozdział szczegółowo omawia protokoły najcz˛e´sciej stosowane w sieciach operatorskich tj. PIM-SM i PIM-SSM. Budow˛e nowego protokołu rutingu rozgał˛e´znego oraz uzasadnienie decyzji podj˛etych na etapie projektowania protokołu, zaprezentowano w rozdziale 4. Rozdział 5 opisuje ´srodowisko symulacyjne wykorzystane w czasie badań. Natomiast wyniki badań symulacyjnych protokołów rutingu rozgał˛e´znego, które obejmuj ˛a równie˙z badania protokołu zaproponowanego w ramach rozprawy, zostały przedstawione w rozdziale 6. Prac˛e kończy podsumowanie zawieraj ˛ace najwa˙zniejsze osi ˛agni˛ecia rozprawy.

(11)

Komunikacja grupowa w sieciach IP

2.1. Wprowadzenie

Podstawowym modelem wykorzystywanym do zapewnienia komunikacji grupowej w sieciach IP jest model zaproponowany przez Stevena Deeringa [31].¹ W ramach modelu Multicast IP opracowano dwie grupy protokołów. Pierwsz ˛a grup˛e stanowi ˛a protoko- ły sygnalizacyjne IGMP (ang. Internet Group Management Protocol) [29, 37, 51, 63] dla protokołu IPv4 lub protokół MLD (ang. Multicast Listener Discovery) [36, 63, 128] dla protokołu IPv6. Protokoły te odpowiadaj ˛a za przekazywanie protokołom rutingu informacji o uczestnikach komunikacji grupowej. Drug ˛a grup˛e protokołów stanowi ˛a protokoły rutingu odpowiedzialne za wyznaczanie drzew. Model Multicast IP wspiera scenariusz komunikacji grupowej typu wielu-do-wielu, cz˛esto nazywany ASM (ang. Any Source Multicast).

Model stworzony przez Deeringa zakłada, ˙ze w komunikacji grupowej mo˙ze uczestniczy´c dowolna liczba nadawców [38]. Adresy tych nadawców nie s ˛a znane odbiorcom transmisji grupowej. Oznacza to, ˙ze zadaniem protokół rutingu jest okre´slenie zbioru nadawców i dostarczenie generowanych przez nich danych do odbiorców. Zadanie to jest zło˙zone z powodu braku zdefiniowanego zbioru nadawców, który mo˙ze ulega´c zmianom podczas trwania poł ˛aczenia rozgał˛e´znego. Wi ˛a˙ze si˛e to z konieczno´sci ˛a wymiany du˙zej liczby wiadomo´sci

1 Model ten jest cz˛esto nazywany modelem Multicast IP i tak ˛a nazw˛e b˛edziemy wykorzystywa´c w dalszej cz˛e´sci pracy.

10

(12)

sygnalizacyjnych. W celu zmniejszenia zło˙zono´sci protokołów korzystaj ˛acych ze scenariu- sza ASM, wprowadzono scenariusz SSM (ang. Source-Specific Multicast). Zgodnie z za- ło˙zeniami tego modelu, w komunikacji grupowej mo˙ze uczestniczy´c tyko jeden nadawca, którego adres jest znany odbiorcom.

Wzrost wielko´sci sieci Internet sprawił, ˙ze tradycyjne protokoły rutingu ² stawały si˛e mało wydajne w warunkach rosn ˛acego ruchu. Dokonano wówczas podziału sieci na domeny i wprowadzono podział protokołów rutingu na protokoły wewn ˛atrzdomenowe i mi˛edzydomenowe. Podobne rozwi ˛azania, oparte na idei rutingu hierarchicznego, zostały opracowane tak˙ze dla komunikacji grupowej.

2.2. Wewn ˛ atrzdomenowe protokoły rutingu rozgał˛e´znego

W rozdziale tym przedstawiono wewn ˛atrzdomenowe protokoły rutingu rozgał˛e´znego wykorzystywane w praktyce, b ˛ad´z b˛ed ˛ace rezultatem bada´n prowadzonych w o´srodkach badawczych i badawczo-rozwojowych.

2.2.1. Distance Vector Multicast Routing Protocol

DVMRP (ang. Distance Vector Multicast Routing Protocol) był pierwszym protokołem rutingu Multicast IP. Warto podkre´sli´c, ˙ze było to rozwi ˛azanie przełomowe, które zapo- cz ˛atkowało zastosowanie modelu Multicast IP w praktyce np. w sieci MBone [105, 129].

Protokół ten składa si˛e z nast˛epuj ˛acych modułów: modułu wykrywania ruterów s ˛asiednich, modułu tradycyjnego rutingu i modułu rutingu rozgał˛e´znego.

W momencie rozpocz˛ecia działania proces odpowiedzialny za obsług˛e protokołu DVMRP nie dysponuje wiedz ˛a na temat s ˛asiednich uprz˛edze´n obsługuj ˛acych ten proto- kół. Urz ˛adzenia s ˛asiednie te˙z nie dysponuj ˛a informacj ˛a na temat nowego rutera DVMRP.

Dlatego zaraz po uruchomieniu ruter wysyła wiadomo´s´c Probe zawieraj ˛ac ˛a jego adres IP.

W odpowiedzi urz ˛adzenia s ˛asiednie tak˙ze generuj ˛a wiadomo´sci Probe. Wiadomo´sci te, poza adresem s ˛asiednich ruterów, zawieraj ˛a tak˙ze adres nadawcy pocz ˛atkowej wiadomo´sci Probe. Prowadzi to do ustanowienia dwustronnej relacji pomi˛edzy s ˛asiednimi ruterami. Po ustanowieniu relacji s ˛asiedzkiej rutery mog ˛a rozpocz ˛a´c proces wymiany wiadomo´sci steru- j ˛acych.

Unikaln ˛a cech ˛a protokołu DVMRP jest wykorzystanie tuneli. Tunele wykorzystane s ˛a do poł ˛aczenia tych regionów sieci, które nie s ˛a poł ˛aczone ruterami obsługuj ˛acymi ten proto- kół. Takie podej´scie umo˙zliwia budowanie rozległych drzew komunikacji grupowej³nawet w tych sieciach, które nie obsługuj ˛a tego protokołu.

2 Tradycyjnymi protokołami rutingu nazywamy protokoły umo˙zliwiaj ˛ace znalezienie najlepszej ´scie˙zki pomi˛edzy jednym nadawc ˛a i jednym odbiorc ˛a.

3 Drzewa te okre´slane s ˛a równie˙z mianem drzew rozpinaj ˛acych

(13)

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

(a) Reverse Path Forwarding

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

(b) Truncated Reverse Path Broadcasting

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

Dane Prune

(c) Reverse Path Multicasting

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

(d) Ko´ncowa posta´c drzewa rozpinaj ˛acego Rysunek 2.1. Ilustracja działania protokołu DVMRP

Zadaniem protokołu DVMRP jest konstrukcja drzew rozpinaj ˛acych. Do budowy takich drzew potrzebne s ˛a równie˙z informacje zwi ˛azane z rutingiem tradycyjnym. Jednak topologie sieci dla rutingu tradycyjnego i rozgał˛e´znego mog ˛a si˛e znacz ˛aco ró˙zni´c. Dlatego protokół DVMRP nie wykorzystuje informacji zwi ˛azanych z działaj ˛acymi ju˙z w sieci tradycyjnymi protokołami rutingu, ale stosuje własny protokół wektora odległo´sci oparty na protokole RIP [61].

Ostatnim i najbardziej istotnym komponentem protokołu DVMRP jest moduł rutingu rozgał˛e´znego odpowiedzialny za konstrukcje drzew rozpinaj ˛acych. W momencie, gdy nadawca rozpoczyna transmisj˛e danych, rozpoczyna si˛e te˙z proces zalewania sieci pakietami danych (rysunek 2.1(a)). W celu unikni˛ecia p˛etli podczas realizacji tego procesu wykorzystuje si˛e mechanizm RPF (ang. Reverse Path Forwarding) [33]. Po otrzymaniu pakietu ruter sprawdza, czy został on odebrany przez interfejs sieciowy nale˙z ˛acy do najkrótszej ´scie˙zki prowadz ˛acej do nadawcy. Je´sli tak, to jest on akceptowany i przesyłany dalej, w przeciwnym wypadku pakiet jest ignorowany. Informacje o najkrótszych ´scie˙zkach, niezb˛edne do działania mechanizmu RPF, dostarczane s ˛a przez moduł rutingu tradycyjnego.

Zalewanie sieci, zrealizowane w oparciu o mechanizm RPF, pozwala na dostarczenie pakietów danych bez ryzyka powstania p˛etli. Niestety proces ten jest nieefektywny, poniewa˙z zu˙zywa du˙zo zasobów sieciowych. Zauwa˙zmy, ˙ze zalewanie sieci w swej podstawowej postaci prowadzi do duplikacji pakietów danych. Ruter, po odebraniu pakietu danych przez interfejs RPF, rozsyła go przez wszystkie pozostałe interfejsy, nawet wtedy, gdy dane s ˛a ju˙z

(14)

dostarczane do tych cz˛e´sci sieci do których prowadz ˛a te interfejsy. Problem ten ilustruje poł ˛aczenie pomi˛edzy ruterami D i E na rysunku 2.1(a).

W celu rozwi ˛azania tego problemu protokół DVMRP u˙zywa algorytmu RPB (ang. Re- verse Path Broadcasting) [38, 43, 122]. W algorytmie tym ruter le˙z ˛acy na najkrótszej ´scie˙zce prowadz ˛acej do nadawcy lub router o najmniejszym adresie IP, gdy ´scie˙zki s ˛a jednakowo długie, jest wybierany jako tzw. ruter dedykowany. Tylko ruter dedykowany mo˙ze przesyła´c pakiety danych, rozsyłanych w ramach komunikacji grupowej, w danym segmencie sieci.

Jednoczesne wykorzystanie zalewania i algorytmu RPB prowadzi do konstrukcji takiej struktury, w której dane trafiaj ˛a do wszystkich segmentów sieci, bez wprowadzania duplikacji. Algorytm TRPB (ang. Truncated Reverse Path Broadcasting) jest modyfikacj ˛a algorytmu RPB. W tym algorytmie wszystkie interfejsy rutera (poza interfejsem RPF) dzielone s ˛a na dwie grupy. Pierwsza grupa obejmuje te interfejsy, które nie posiadaj ˛a ani odbiorców transmisji rozgał˛e´znej, ani ruterów dla których dany ruter jest rodzicem na drodze do nadawcy. Druga grupa, zwana grup ˛a potomn ˛a, obejmuje te interfejsy, które posiadaj ˛a odbiorców komunikacji grupowej, b ˛ad´z te rutery, dla których dany ruter jest rodzicem na drodze do nadawcy. Algorytm TRPB ogranicza komunikacj˛e grupow ˛a jedynie do interfejsów nale˙z ˛a- cych do grupy reprezentuj ˛acej interfejsy potomne. W rezultacie powstaje drzewo rozpina- j ˛ace, które swym zasi˛egiem obejmuje wszystkie rutery w sieci. Wynik działania algorytmu w omawianym przykładzie przedstawia rysunek 2.1(b). Zauwa˙zmy, ˙ze zarówno ruter D nie jest rodzicem dla rutera E, jak i ruter E nie jest rodzicem dla rutera D. Co wi˛ecej, w segmencie sieci D-E nie ma odbiorców transmisji grupowej. Zatem zgodnie z zasad ˛a działania algorytmu TRPB, strumie´n danych nie jest przesyłany do tego segmentu sieci.

Drzewo rozpinaj ˛ace, obejmuj ˛ace swym zasi˛egiem cał ˛a sie´c, jest efektem działania pierwszej fazy protokołu DVMRP. Drzewo to nie jest optymalne, poniewa˙z dane dostarczane s ˛a tak˙ze do ruterów, które posiadaj ˛a wył ˛acznie interfejsy do których nie s ˛a doł ˛aczeni odbiorcy (np. ruter C na rysunku 2.1(b)). Druga faza, tak zwana faza odcinania (ang. prune), ma za zadanie ograniczenie zasi˛egu drzewa rozpinaj ˛acego. Faza odcinania wykorzystuje algorytm RPM (ang. Reverse Path Multicasting) [38]. Celem algorytmu RPM jest konstrukcja drzewa rozpinaj ˛acego, która obejmuje tylko rutery posiadaj ˛ace interfejsy potomne. Rutery posiadaj ˛ace tylko interfejsy, do których nie s ˛a doł ˛aczeni odbiorcy, nie przesyłaj ˛a danych.

Zgodnie z algorytmem RPM wysyłaj ˛a wiadomo´sć Prune poprzez interfejs RPF (patrzy rysunek 2.1(c)). Wiadomo´sć ta przesyłana jest dalej w kierunku nadawcy, a˙z dotrze do rutera, którego lista interfejsów potomnych nie jest pusta. W końcowej fazie odcinania formowane jest ostateczne drzewo rozpinaj ˛ace (rysunek 2.1(d)).

Protokół DVMRP działa w dwóch fazach: zalewania sieci i odcinania drzewa rozpina- j ˛acego. Zalewanie sieci pochłania jednak du˙z ˛a ilo´s´c zasobów, która wzrasta wraz z wielko´sci ˛a sieci i dlatego nie mo˙ze by´c stosowane w du˙zych sieciach, zwłaszcza w Internecie.

(15)

B

E F

G

C D

H

Nowe

cze

A

Router LSA(D) Router LSA(D)

Router LSA(D) Router LSA(D) Router LSA(D) Router LSA(D)

Router LSA(D) Router LSA(D)

(a) Wiadomo´s´c LSA informuj ˛aca o nowym ruterze

B

E F

G

C D

H A Ź^ródło S

Nowy odbiorca

Odbiorca H

Int. 1

GM-LSA(H): Nowy odbiorca na inter. 1

GM-LSA(H): Nowy odbiorca na inter. 1 GM-LSA(H): Nowy

odbiorca na inter. 1

GM-LSA(H): Nowy odbiorca na inter. 1 GM-LSA(H): Nowy

odbiorca na inter. 1

(b) Wiadomo´s´c LSA informuj ˛aca o nowym odbiorcy

Rysunek 2.2. Ilustracja działania protokołu MOSPF

Kolejnym czynnikiem ograniczaj ˛acym skalowalno´s´c protokołu DVMRP jest wykorzystanie własnego modułu rutingu tradycyjnego (unicast). Prowadzi to do generowania dodatkowych wiadomo´sci steruj ˛acych oraz do obci ˛a˙zenia pami˛eci ruterów nadmiarowymi danymi steruj ˛acymi. Podsumowuj ˛ac, protokół DVMRP ze wzgl˛edu na swoje ograniczenia mo˙ze by´c stosowany jedynie w sieciach o małych rozmiarach.

2.2.2. Multicast Extensions to Open Shortest Path First

DVMRP ł ˛aczy elementy rutingu tradycyjnego i rozgał˛e´znego. Moduł tradycyjnego rutingu wykorzystuje w du˙zej mierze protokół RIP, przez co charakteryzuje si˛e takimi samymi wadami, jak długi czas osi ˛agania zbie˙zno´sci oraz bardzo ograniczona skalowalno´s´c. Wspo- mniane ograniczenia dotycz ˛a wi˛ekszo´sci protokołów wektora odległo´sci i były powodem konstrukcji protokołów stanu ł ˛acza LSR (ang. Link State Routing) [86].

Powszechnie znanym i stosowanym protokołem stanu ł ˛acza jest OSPF (ang. Open Shor- test Path First) [93]. RFC 1584 rozszerza protokół OSPF o funkcjonalno´sci zwi ˛azane z ob- sług ˛a komunikacji grupowej [92]. Zmodyfikowana wersja protokołu OSPF okre´slana jest mianem MOSPF (ang. Multicast Extensions to OSPF).

Protokoły wektora odległo´sci buduj ˛a tablice rutingu na podstawie procesu ich wzajem- nej wymiany pomi˛edzy s ˛asiednimi ruterami. Protokoły stanu ł ˛acza wysyłaj ˛a natomiast pakiety LSA (ang. Link State Advertisement), informuj ˛ace wszystkie rutery o dost˛epnych ł ˛a- czach w sieci i ich stanie. Rysunek 2.2(a) przedstawia proces rozsyłania poprzez cał ˛a sie´c wiadomo´sci LSA informuj ˛acej o nowym ruterze w sieci (router D).

Protokół MOSPF, podobnie jak OSPF, wykorzystuje tak˙ze wiadomo´sci LSA do budowa- nia drzewa rozpinaj ˛acego. Protokół OSPF wykorzystuje kilka typów wiadomo´sci LSA np.

Ruter LSA, Network LSA czy Summary LSA. Protokół MOSPF wprowadza dodatkowy typ wiadomo´sci LSA mianowicie Group-Membership-LSA (GM-LSA).

Rozwa˙zmy ró˙znic˛e pomi˛edzy protokołami DVMRP i MOSPF. Protokół DVMRP działa dwufazowo. W pierwszym kroku cała sie´c zalewana jest pakietami danych, a w nast˛ep-

(16)

nym formowane jest drzewo rozpinaj ˛ace. W przypadku protokołu MOSPF wiadomo´sci Group-Membership-LSA odbierane s ˛a przez wszystkie rutery (rysunek 2.2(b)), co powoduje, ˙ze rutery w sieci znaj ˛a lokalizacje odbiorców. Dzi˛eki temu ka˙zdy ruter jest w stanie wy- znaczyć drzewo rozpinaj ˛ace dla dowolnej kombinacji nadawca-odbiorca i w konsekwencji mo˙ze okre´slić swoj ˛a pozycj˛e w drzewie oraz list˛e interfejsów, gdzie powinien przekazywać dane komunikacji grupowej.

Wyznaczanie drzew rozpinaj ˛acych, zwłaszcza w przypadku sieci rozległych, jest pro- cesem zło˙zonym obliczeniowo. W zwi ˛azku z tym wyznaczone drzewa s ˛a przechowywane w pami˛eci tych ruterów, które s ˛a cz˛e´sci ˛a drzewa rozpinaj ˛acego. Protokół MOSPF do obli- czenia drzewa rozpinaj ˛acego u˙zywa algorytmu Dijkstry [41].

Protokół MOSPF posiada szereg zalet w porównaniu do protokołu DVMRP. MOSPF jest protokołem stanu ł ˛acza, oferuje wi˛eksz ˛a skalowalno´s´c oraz znacznie krótszy czas zbie˙zno-

´sci. Dodatkowo zalet ˛a jest fakt, ˙ze nie stosuje zalewania sieci i tym samym efektywniej wykorzystuje zasoby sieciowe. Do wad protokołu MOSPF mo˙zna z kolei zaliczy´c znaczne zasoby obliczeniowe wymagane do wyznaczania drzew rozpinaj ˛acych. To ograniczenie uniemo˙zliwia zastosowanie protokołu MOSPF w sieci Internet.

2.2.3. Core Based Trees

Głównym celem pracy nad protokołem CBT (ang. Core Based Trees) [9, 10, 11] było zapewnienie du˙zej skalowalno´sci. Omawiane wcze´sniej protokoły DVMRP i OSPF tworz ˛a osobne drzewa rozpinaj ˛ace dla ka˙zdego ´zródła danych. W zwi ˛azku z tym ilo´s´c danych steruj ˛acych, przechowywanych przez rutery jest proporcjonalna do iloczynu S*N, gdzie S to liczba ´zródeł, a N to liczba odbiorców komunikacji grupowej. Twórcy protokołu CBT zdecydowali si˛e na zastosowanie drzew współdzielonych, zaproponowanych w [130]. Wy- nikiem przyj˛ecia takiego rozwi ˛azania jest poł ˛aczenie najkrótszymi ´scie˙zkami wszystkich odbiorców oraz ´zródeł z ruterem centralnym. W trakcie działania protokołu pakiety danych od nadawców s ˛a najpierw przekazywane do punktu centralnego, który nast˛epnie przekazuje je do odbiorców. W ten sposób, niezale˙znie od liczby nadawców, zawsze tworzone jest jedno drzewo rozpinaj ˛ace dla ka˙zdego poł ˛aczenia grupowego.

Protokół CBT, podobnie jak MOSPF, nie wykorzystuje mechanizmu zalewania sieci.

Ruter CBT po odebraniu wiadomo´sci Report protokołu IGMP [29, 37, 51] - informuj ˛acej o tym, ˙ze jedno spo´sród bezpo´srednio doł ˛aczonych urz ˛adzeń wymaga dostarczenia danych komunikacji grupowej - generuje wiadomo´sć Join_Request. Wiadomo´sć Join_Request jest przesyłana w kierunku rutera centralnego (rysunek 2.3(a)). Wiadomo´sć ta jest przekazywana dalej, przez kolejne rutery, a˙z dotrze do rutera centralnego lub rutera, który jest ju˙z cz˛e´sci ˛a współdzielonego drzewa rozpinaj ˛acego. Wiadomo´sć Join_Request nie powoduje powstania nowej gał˛ezi drzewa rozpinaj ˛acego. Nowa gał ˛a´z tworzona jest na podstawie wiadomo´sć Jo-

(17)

Nowy Odbiorca

B

E F

G

C D

H A Router Centralny

Join_Request Join_Request

Join_Request

Join_Ack Join_Ack Join_Ack Nowy

Odbiorca

Odbiorca H1

Join_Request Join_Request

Join_Ack Join_Ack

Odbiorca H2

Report

(a) Proces rozbudowy drzewa

Nowe ródo H G F E

B C D

A Router

Centralny

Dane

ród o S

Odbiorca H1

Enkapsulowane dane

Dane Dane Dane

Odbiorca H2

Dane Dane

Dane

(b) Przesyłanie danych ze ´zródła do rutera centralnego

E F

G H

B C D

A Router Centralny

Odbiorca H1

ródo S Odbiorca H2

Dane Dane

Dane

Dane Dane

(c) Drzewo rozpinaj ˛ace

Rysunek 2.3. Ilustracja działania protokołu CBT

(18)

in_Ack, która jest generowana przez ruter centralny lub urz ˛adzenie b˛ed ˛ace ju˙z cz˛e´sci ˛a drzewa rozpinaj ˛acego. Wiadomo´s´c Join_Ack pod ˛a˙za ´sladem pakietu steruj ˛acego Join_Request, lecz jest przesyłana w kierunku nadawcy wiadomo´sci Join_Request. Proces generowania wiadomo´sci Join_Request i Join_Ack został pokazany na rysunku 2.3(a).

Rysunek 2.3(b) ilustruje sposób dostarczania danych generowanych przez ´zródła do rutera centralnego w protokole CBT. Ruter dedykowany, s ˛asiaduj ˛acy bezpo´srednio z nadawc ˛a, enkapsuluje dane komunikacji grupowej i przesyła je do rutera centralnego. Ruter centralny dekapsuluje odebrane dane i przesyła je do odbiorców poprzez współdzielone drzewo rozpinaj ˛ace.

Porównajmy protokół CBT z przedstawionymi wcze´sniej protokołami. Protokoły DVMRP i MOSPF pozwalaj ˛a na przesyłanie danych tylko w jednym kierunku - od nadawcy do odbiorców. Co wi˛ecej, przysyłane s ˛a tylko dane odebrane przez interfejs nadrz˛edny (ang. upstream) tj. interfejs le˙z ˛acy na ´scie˙zce prowadz ˛acej do nadawcy. ´Scie˙zki konstruowane przez CBT s ˛a dwukierunkowe, a dane s ˛a akceptowane i przesyłane dalej do pozostałych interfejsów nale˙z ˛acych do drzewa, niezale˙znie od interfejsu, który je odebrał. Sposób przesyłania danych poprzez współdzielone drzewo rozpinaj ˛ace pokazano na rysunku 2.3(c). Zwró´cmy uwag˛e, ˙ze ruter C po odebraniu danych z rutera F, zgodnie z przedstawionym algorytmem przekazywania danych, wysyła je przez pozostałe interfejsy nale˙z ˛ace do drzewa.

Współdzielenie pojedynczego drzewa przez wielu nadawców zwi˛eksza skalowalno´s´c protokołu. Jednak przesyłanie danych najpierw do rutera centralnego, a potem do odbior- ców, zwi˛eksza opó´znienie przesyłanych danych. Zjawisko to jest niepo˙z ˛adane, szczególnie w przypadku aplikacji multimedialnych. Innym ograniczeniem protokołu CBT zwi ˛azanym z wykorzystaniem rutera centralnego jest efekt koncentracji ruchu. Zjawisko to wpływa ne- gatywnie na wzrost oraz fluktuacje opó´znienia i w konsekwencji mo˙ze powodowa´c utrat˛e pakietów.

Kluczowym elementem protokołu CBT jest ruter centralny. Jego bezawaryjno´s´c jest niezmiernie istotna dla poprawnego działania protokołu. Awaria rutera centralnego prowadzi do podziału drzewa rozpinaj ˛acego i zablokowania mo˙zliwo´sci przesyłania danych.

W celu zwi˛ekszenia niezawodno´sci działania, protokół CBT wyposa˙zono w mechanizmy:

wykrywania awarii rutera centralnego, wyboru rutera alternatywnego i odbudowy drzewa.

Funkcjonalno´sci te s ˛a realizowane przy pomocy mechanizmu BRM (ang. Bootstrap Router Mechanism) [26].

Jedn ˛a z głównych przesłanek opracowania protokołu CBT była redukcja obci ˛a˙zenia ru- terów danymi steruj ˛acymi. Cel ten osi ˛agni˛eto przez zastosowanie współdzielonego drzewa rozpinaj ˛acego. Wad ˛a takiego rozwi ˛azania jest jednak obni˙zenie niezawodno´sci przesyłania danych, poniewa˙z awaria rutera centralnego powoduje przerwanie transmisji. Problemem

(19)

jest równie˙z wybór rutera centralnego w du˙zych sieciach, w których nie mo˙zna wykorzysta´c konfiguracji statycznej. Przedstawione ograniczenia wykluczaj ˛a mo˙zliwo´s´c zastosowania protokołu CBT dla zapewnienia komunikacji grupowej w Internecie.

2.2.4. Protocol Independent Multicast - Dense Mode

W ramach prac standaryzacyjnych IETF stworzono cztery wersje protokołów z rodziny PIM (ang. Protocol Independent Multicast): PIM Sparse Mode (PIM-SM) [49], PIM Sour- ces Specific Multicast (PIM SSM) [49, 63], PIM Dense Mode (PIM-DM) [7] i Bidirectional PIM (Bidir-PIM) [59]. Ka˙zdy z tych protokołów charakteryzuje si˛e własnym sposobem obsługi komunikacji grupowej w sieci IP. Protokoły nale˙z ˛ace do rodziny PIM mog ˛a współpracowa´c z protokołami stanu ł ˛acza oraz z protokołami wektora odległo´sci.

Protokół PIM-DM wykazuje wiele podobieństw z omawianym wcze´sniej protokołem DVMRP. Protokół PIM-DM działa w dwóch fazach (rysunek 2.4). W pierwszej fazie cała sieć jest zalewana pakietami danych. W tej fazie rutery po odebraniu pakietów danych przez interfejsy RPF przekazuj ˛a je dalej za po´srednictwem pozostałych interfejsów. W przeci- wieństwie do protokołu DVMRP, protokół PIM-DM nie wykorzystuje mechanizmu RPB (ang. Reverse Path Broadcast), który pozwala na efektywniejsze wykorzystanie zasobów sieciowych na podstawie znajomo´sci tablicy rutingu ruterów s ˛asiednich.

Proces zalewania jest wysoce nieefektywny i prowadzi do nadmiernego wykorzystania zasobów sieciowych. W zwi ˛azku z tym PIM-DM w drugiej fazie, zwanej faz ˛a odcinania (ang. prune)(rysunek 2.4(b)), usuwa wszystkie zb˛edne gał˛ezie przy pomocy wiadomo´sci Prune. Je´sli przez dany interfejs ruter odebrał wiadomo´s´c Prune, to ruter nie b˛edzie ju˙z dłu˙zej wysyłał przez niego pakietów komunikacji grupowej. O takim interfejsie mówi si˛e,

˙ze jest w stanie odci˛ecia (ang. pruned state).

Ruter generuje wiadomo´s´c Prune (rysunek 2.4(b)), gdy nie jest zainteresowany odbio- rem danych przesyłanych w ramach komunikacji grupowej. Oznacza to, ˙ze ruter nie posiada

˙zadnych odbiorców ani ruterów podrz˛ednych (poło˙zonych ni˙zej w hierarchii drzewa rozpinaj ˛acego), do których powinien przekazywać takie dane. Stan odci˛ecia nie jest permanentny i wygasa po okre´slonym czasie. Odnowienie stanu odci˛ecia powoduje cykliczna wymiana wiadomo´sć State Refresh. Zatem, dzi˛eki wprowadzeniu wiadomo´sci State Refresh, proces zalewania i odci˛ecia nie jest powtarzany. Inn ˛a wiadomo´sci ˛a cyklicznie generowan ˛a przez rutery PIM-DM jest wiadomo´sć Hello. Rutery wykorzystuj ˛a j ˛a do wykrywania i monitoro- wania s ˛asiednich ruterów (obsługuj ˛acych ten protokół).

Jak wcze´sniej odnotowano, protokół PIM-DM nie wykorzystuje mechanizmu RPB.

Mo˙zliwe jest zatem, ˙ze wi˛ecej ni˙z jeden ruter przekazuje dane przesyłane w ramach tej samej komunikacji grupowej do danego segmentu sieci. Zjawisko to prowadzi do duplikacji pa- kietów i nieefektywnego wykorzystania zasobów sieciowych. Wybór rutera dedykowanego

(20)

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

(a) Faza zalewania

A B

Odbiorca R1

ródo S Odbiorca R2

D C E

Dane Prune

(b) Faza odcinania

A B

Odbiorca R1

ródo S Odbiorca R2

C D

E

(c) Drzewo rozpinaj ˛ace

Rysunek 2.4. Ilustracja działania protokołu PIM-DM

(21)

odpowiedzialnego za przesyłanie danych jest realizowany na podstawie wiadomo´sci Assert.

W momencie wykrycia powielenia pakietów danych wszystkie rutery generuj ˛a wiadomo´sci Assert. Wiadomo´s´c Assert przenosi informacje o odległo´s´c rutera od nadawcy, która jest wykorzystywana do wyboru rutera dedykowanego, nazywanego w specyfikacji protokołu Assert Winner [7].

Protokół PIM Dense Mode mo˙zna potraktowa´c jako modyfikacj˛e protokółu DVMRP.

PIM-DM redukuje nadmiarowo´s´c poprzez wykorzystanie danych dostarczanych przez tradycyjne protokoły rutingu. Wykorzystanie wiadomo´sci State Refresh znacz ˛aco ogranicza negatywne efekty zalewania sieci, chocia˙z podstawowy model działania jest w obu proto- kołach taki sam. W pierwszym kroku dane, przesyłane w ramach komunikacji grupowej, s ˛a dostarczane do całej sieci, natomiast w drugim kroku, dzi˛eki wykorzystaniu procesu odcinania, formowane jest drzewo rozpinaj ˛ace (rysunek 2.4(c)). Takie podej´scie upraszcza imple- mentacj˛e przy jednoczesnym ograniczeniu skalowalno´sci protokołu. Dlatego te˙z protokół PIM-DM nie spełnia wymaga´n stawianych protokołom rutingu rozgał˛e´znego przeznaczo- nym do zastosowania w Internecie.

2.2.5. Protocol Independent Multicast - Sparse Mode

Protokół PIM-SM (ang. Protocol Independent Multicast - Sparse Mode) wykorzystuje, podobnie jak protokół CBT, ruter centralny, który okre´slany jest mianem punktu spo- tkań (ang. Rendezvous Point (RP)). Podobnie jak w przypadku protokołu CBT, wokół rutera RP budowane jest współdzielone drzewo rozpinaj ˛ace. W protokole PIM-SM to drzewo jest jednokierunkowe i pozwala na przesyłanie danych od nadawców do odbiorców. Protokół PIM-SM działa w trzech fazach [49]. W pierwszej fazie nadawcy przesyłaj ˛a dane do punktu spotkań. W kolejnym kroku punkt RP przesyła dane za po´srednictwem drzewa rozpinaj ˛acego do odbiorców. W trzeciej i ostatniej fazie rutery ˙z ˛adaj ˛a dostarczenia danych komunikacji grupwej bezpo´srednio od nadawców, a wiec z pomini˛eciem punktu spotkań.

Na rysunku 2.5(a) przedstawiono pierwsz ˛a i drug ˛a faz˛e działania protokołu, natomiast faz˛e trzeci ˛a przedstawiono na rysunku 2.5(b). W pierwszej fazie dane przesyłane przez nadawców dostarczane s ˛a do punktu spotkań poprzez tunel (pierwszy krok na rysunku 2.5(a)). W drugiej fazie budowane jest drzewo współdzielone, które pozwala na rozsyła- nie danych z punktu RP do odbiorców. Odbiorca powiadamia rutery o potrzebie dostarczenia danych komunikacji grupowej przy pomocy wiadomo´sci Report protokołu IGMP (krok drugi na rysunku 2.5(a)). Rutery w odpowiedzi buduj ˛a gał ˛a´z drzewa rozpinaj ˛acego, do punktu spotkań wykorzystuj ˛ac wiadomo´sć Join(*,G) protokołu PIM-SM (krok trzeci na rysunku 2.5(a)). Wiadomo´sć Join(*,G), przesyłana w kierunku punktu RP, tworzy gał ˛a´z współdzielonego drzewa rozpinaj ˛acego (ang. RP Tree (RPT)). Punkt RP rozsyła dane otrzy-

(22)

Źródło S

B C

D

E RP

A

Odbiorca R 2ms

3ms

2ms 3ms

2ms 5ms

Dane

4 3

2 1

LHR Join(*,G)

FHR

(a) Pierwsza i druga faza działania

Źródło S

B

C D

E RP

A

Odbiorca R 2ms3ms

2ms 3ms

2ms 5ms

Dane

1 2

LHR

Join(S,G) FHR

(b) Trzecia faza działania Rysunek 2.5. Ilustracja działania protokołu PIM-SM

mywane ze ´zródła przez wszystkie interfejsy, na których wcze´sniej otrzymał wiadomo´sci Join(*,G) (krok czwarty na rysunku 2.5(a)).

Wykorzystanie punktu spotka´n wymaga, aby wszystkie rutery w sieci współdzieliły spójn ˛a informacj˛e na temat adresu punktu RP. Wymaganie to jest w praktyce spełnione przez wykorzystanie statycznej konfiguracji lub przez wykorzystanie mechanizmu BRM (ang. Bo- otstrap Router Mechanism) [26]. Warto odnotowa´c, ˙ze dokładnie te same rozwi ˛azania sto- sowano w przypadku protokołu CBT.

Wprowadzenie punktu spotkań w sposób zasadniczy upraszcza komunikacj˛e grupow ˛a realizown ˛a zgodnie ze scenariuszem wielu-do-wielu. Rutery otrzymuj ˛ace dane od nadaw- ców nie musz ˛a znać adresów odbiorców. Znaj ˛ac adres punktu spotkań nadawcy przesyłaj ˛a dane w ramach komunikacji grupowej poprzez tunel. Równie˙z rutery obsługuj ˛ace odbior- ców nie znaj ˛a adresów nadawców. W odpowiedzi na wiadomo´sć Report generuj ˛a wiadomo´sć Join(*,G) i przesyłaj ˛a j ˛a w kierunku RP, do którego przesyłane s ˛a dane kierowane do danej grupy odbiorców. Niestety, wprowadzenie punktu spotkań prowadzi do ograniczeń znanych z protokołu CBT. Zaliczamy do nich koncentracj˛e ruchu, zwi˛ekszenie opó´znienia oraz zmniejszenie niezawodno´sci komunikacji grupowej.

Protokół PIM-SM w trzeciej fazie swego działania przeł ˛acza si˛e z drzewa współdzielo- nego RPT na drzewa ´zródłowe. Oznacza to, ˙ze tworzone jest osobne drzewo dla ka˙zdego ze ´zródeł, którego korzeniem jest ruter obsługuj ˛acy dane ´zródło, nazywany dalej ruterem

´zródłowym lub ruterem pierwszego skoku (ang. First Hop Router (FHR)). Zgodnie z rysunkiem 2.5(b) w kroku pierwszym trzeciej fazy działania protokołu PIM-SM, ruter ob- sługuj ˛acy odbiorc˛e – nazywany ruterem ostatniego skoku (ang. Last Hop Router (LHR)) – wysyła wiadomo´s´c Join(S,G) w kierunku nadawcy. W kroku drugim dane trafiaj ˛a poprzez

(23)

drzewo ´zródłowe bezpo´srednio do rutera LHR, bez po´srednictwa punktu RP. Taka procedura zmniejsza opó´znienie przesyłanych danych oraz koncentracj˛e ruchu.

Niestety, konstrukcja oddzielnego drzewa rozpinaj ˛acego dla ka˙zdego nadawcy, ogranicza skalowalno´sć protokołu. Rutery musz ˛a wymieniać pakiety steruj ˛ace oraz zu˙zywać zasoby, aby utrzymywać maszyn˛e stanów odpowiedzialn ˛a za obsług˛e ka˙zdego z drzew. Obsługa dwóch rodzajów drzew komplikuje budow˛e protokołu. PIM-SM wymaga, od wykorzystu- j ˛acych go ruterów, obsługi trzech głównych maszyn stanu. Pierwsza maszyna stanu jest u˙zywana do budowy tunelu pomi˛edzy ruterem FHR a punktem RP. Druga maszyna stanu odpowiada za obsług˛e drzewa RPT, natomiast trzecia wykorzystywana jest do budowy i utrzymania drzew ´zródłowych. Nale˙zy podkre´slić, ˙ze obsługa ka˙zdego spo´sród obsługiwa- nych przez ruter drzew ´zródłowych wymaga własnej instancji maszyny stanu.

Protokół PIM-SM wykorzystuje koncepcje drzew współdzielonych i ´zródłowych. Zasto- sowanie drzew RPT upraszcza komunikacj˛e grupow ˛a realizowan ˛a zgodnie ze scenariuszem wielu-do-wielu, poniewa˙z wykorzystanie punktu spotkań eliminuje konieczno´sć okre´slania zbioru nadawców i odbiorców. Z drugiej strony zastosowanie drzew ´zródłowych zmniejsza poziom koncentracji ruchu i opó´znienia przesyłanych danych. Protokół PIM-SM działa efektywniej od omówionych do tej pory protokołów. Jednak jego du˙za zło˙zono´sć oblicze- niowa oraz nadmiarowo´sć uniemo˙zliwia wdro˙zenie tego protokołu w sieci Internet.

2.2.6. Bidirectional Protocol Independent Multicast

Bidirectional PIM (Bidir-PIM) [59], podobnie jak CBT, jest protokołem wykorzystuj ˛a- cym drzewo współdzielone. Kluczowym elementem protokołu Bidir-PIM jest adres RP (ang. Rendezvous Point Address (RPA)). RPA pełni rol˛e korzenia drzewa, podobnie jak punkt spotka´n w przypadku protokołu PIM-SM lub ruter centralny w przypadku protokołu CBT. Protokół Bidir-PIM nie wymaga jednak, aby adres RPA był przypisany do konkretnego portu lub urz ˛adzenia. Jedynym wymaganiem jest dost˛epno´s´c RPA z dowolnego miejsca w sieci.

Protokół Bidir-PIM działa dwufazowo. W pierwszej fazie Bidir-PIM buduje drzewo rozpinaj ˛ace, które swym zasi˛egiem obejmuje cał ˛a sie´c (rysunek 2.6(a)). Podstaw ˛a tej fazy jest wybór rutera desygnowanego (ang. Designated Forwarder (DF)) dla ka˙zdego ł ˛acza sieci, za wyj ˛atkiem ł ˛acza, do którego nale˙zy RPA. Rol˛e rutera DF w danym segmencie sieci pełni urz ˛adzenie, które charakteryzuje si˛e najkrótsz ˛a drog ˛a do RPA. Wybór pojedynczego rutera DF dla ka˙zdego segmentu sieci jest oparty na kryterium odległo´sci do RPA i gwarantuje,

˙ze powstałe drzewo rozpinaj ˛ace nie ma p˛etli. Drzewo rozpinaj ˛ace słu˙zy do przesyłania danych ze ´zródeł do punktu RPA i dlatego głównym zadaniem rutera DF jest przesyłanie pa- kietów danych w kierunku korzenia drzewa RPA (rutery H i G na rysunku 2.6(c)). Oznacza

(24)

B

E G F

C D

H A ^RPA

DF DF

(a) Drzewo rozpinaj ˛ace (linie przerywane)

E G F

H

RPA

Odbiorca H1

Odbiorca H2

Join Join

Join

Join Join

B C D

A

DF DF

(b) Drzewo dystrybucyjne (linie pogrubione)

E F

G H

RPA Dane

ródo S

Odbiorca H1

Dane Dane Dane

Odbiorca H2

Dane Dane

Dane

B C D

A

DF DF DF

DF DF

DF

(c) Przykład przesyłania danych

Rysunek 2.6. Ilustracja działania protokołu Bidir-PIM

to, ˙ze dane generowane przez nadawców nie s ˛a dostarczane do wszystkich w˛ezłów w sieci, mimo ˙ze drzewo rozpinaj ˛ace obejmuje swym zasi˛egiem cał ˛a sie´c.

W drugiej fazie działania protokołu Bidir-PIM budowane jest drzewo dystrybucji, któ- rego zadaniem jest przesyłanie danych z punktu RPA do ruterów LHR. Ruter posiadaj ˛acy lokalnych odbiorców generuje wiadomo´s´c Join(G) i wysyła j ˛a w kierunku punktu RPA.

Interfejs rutera, który wysyła wiadomo´sci steruj ˛ace w kierunku punktu RPA jest okre´slany mianem interfejsu nadrz˛ednego (ang. upstream). Zgodnie z rysunkiem 2.6(b), wiadomo´sci Join(G) pod ˛a˙zaj ˛ac w stron˛e punktu RPA, powoduj ˛a tworzenie gał˛ezi drzewa dystrybucji danych. Oznacza to, ˙ze drzewo dystrybucyjne pozwala na przesyłanie danych jedynie do tych w˛ezłów, które rzeczywi´scie oczekuj ˛a ich dostarczenia.

Nadawca rozpoczyna wysyłanie danych komunikacji grupowej do rutera DF, dane s ˛a nast˛epnie przesłane przez DF w kierunku punktu RPA (rys. 2.6(c)). Taka konstrukcja nie wymaga wymiany wiadomo´sci steruj ˛acych ani tworzenia tunelu, co odró˙znia protokoł Bidir-PIM od rozwi ˛aza´n stosowanych w protokołach PIM-SM i CBT.

Protokół Bidir-PIM umo˙zliwia ograniczenie ilo´s´c przesyłanych wiadomo´sci sygnaliza-

(25)

cyjnych. Jego wad ˛a s ˛a ograniczenia zwi ˛azane z wykorzystaniem drzew współdzielonych, tj. koncentracja ruchu czy wzrost opó´znienia przesyłanych danych. Równie˙z konstrukcja drzewa rozpinaj ˛acego obejmuj ˛acego swym zasi˛egiem cał ˛a sie´c sprawia, ˙ze rozwi ˛azanie to nie mo˙ze by´c zastosowane w Internecie.

2.2.7. Hierarchical DVMRP

Idea rutingu hierarchicznego dla tradycyjnych poł ˛acze´n punkt-punkt została zapropono- wana w latach siedemdziesi ˛atych ubiegłego wieku [74]. W tym czasie Internet był stosun- kowo mał ˛a sieci ˛a i nie wymagał tak zło˙zonego rozwi ˛azania. Z czasem zacz ˛ał si˛e on jednak gwałtownie rozrasta´c i w zwi ˛azku z tym wprowadzono podział Internetu na podsieci [91].

Rozwi ˛azanie zaproponowane w RFC 950 zostało zast ˛apione przez RFC 1009 [28] i osta- tecznie sformułowane w CIDR (ang. Inter-Domain Routing) [54].

W komunikacji grupowej koncepepcja hierarchiczno´sci pojawiła si˛e wkróce po pierwszej implementacji protkołu DVMRP w testowej sieci MBone [45]. W roku 1995 sie´c MBone miała około 1500 w˛ezłów, co spowodowało powa˙zne problemy z jej skalowalno-

´sci ˛a [127] i zaowocowało prób ˛a zastosowania elementów rutingu hierarchicznego do komunikacji grupowej. W pracach [105, 127] zaproponowano dwupoziomowy protokół Hie- rarchical DVMRP (H-DVMRP) Protokół H-DVMRP dzieli sie´c na regiony poł ˛aczone poprzez rutery brzegowe (rysunek 2.7). Realizacja ruting odbywa si˛e na dwóch poziomach.

Poziom pierwszy to ruting wewn ˛atrz regionu (rysunek 2.7), a poziom drugi to ruting pomi˛e- dzy regionami (rysunek 2.8). Ruting na poziomie pierwszym jest realizowany za pomoc ˛a protokołu DVMRP, cho´c autorzy dopuszczaj ˛a tak˙ze wykorzystanie innego protokołu (np.

MOSPF). Ruting pomi˛edzy regionami realizowany jest przy pomocy protokołu H-DVMRP.

Gdy nadawca rozpoczyna przesyłanie danych komunikacji grupowej, to dane dostarczane s ˛a nie tylko do odbiorców, ale tak˙ze do ruterów brzegowych (rysunek 2.7), które z kolei do- starczaj ˛a dane do innych regionów (rysunek 2.8).

Protokół H-DVMRP wykorzystuje mechanizmy protokołu DVMRP z modyfikacjami wynikaj ˛acymi z wymaga´n narzuconych przez ruting hierarchiczny. Rutery DVMRP s ˛a bezpo´srednio poł ˛aczone ze sob ˛a poprzez ł ˛acza fizyczne lub tunele. Rutery poziomu drugiego nie zawsze s ˛asiaduj ˛a ze sob ˛a bezpo´srednio i mog ˛a by´c poł ˛aczone za pomoc ˛a ruterów poziomu pierwszego. Dlatego rutery drugiego poziomu komunikuj ˛a si˛e ze sob ˛a za pomoc ˛a specjalnej grupy nazywanej ABR (ang. All Boundary Routers). Dane przesyłane pomi˛edzy ruterami grupy ABR s ˛a traktowane przez rutery pierwszego poziomu tak jak wszystkie pozostałe dane przesyłane w ramach komunikacji grupowej. Grupa ABR jest nie tyko wykorzystywana do wymiany wiadomo´sci steruj ˛acych, ale tak˙ze do przesyłania pakietów danych. Zgodnie z rysunkiem 2.8 pakiety danych s ˛a enkapsulowane przez rutery brzegowe i przesyłane przy

(26)

wykorzystaniu grupy ABR. S’ jest adresem rutera brzegowego, G’ to adres grupy ABR.

RegionID to identyfikator regionu w którym pakiet danych został wygenerowany.

Źródło S

Odbiorca R1 Region A

Odbiorca R3 Odbiorca R2

Router poziomu 1

Router poziomu 2 Drzewo

wewntrzregionalne Region B

Region C Region D

Region E

Rysunek 2.7. H-DVMRP faza pierwsza

Protokół DVMRP w pierwszej fazie działania zalewa cał ˛a sie´c pakietami danych. Na- st˛epnie w fazie odcinania ogranicza zasi˛eg drzewa do urz ˛adze´n, które wymagaj ˛a dostarczenia danych. W podobny sposób H-DVMRP buduje drzewo rozpinaj ˛ace pomi˛edzy ruterami brzegowymi. Załó˙zmy, ˙ze ´zródło rozpoczyna transmisj˛e danych. Dane te dostarczane s ˛a do wszystkich w˛ezłów sieci, w tym do ruterów brzegowych (rysunek 2.7).

Rutery brzegowe zmieniaj ˛a format otrzymanych pakietów danych na format danych przesyłanych w ramach komunikacji grupowej ABR i przesyłaj ˛a je do regionów s ˛asiednich.

Proces jest powtarzany iteracyjnie do momentu, gdy pakiety zostan ˛a odebrane przez wszystkie rutery warstwy drugiej. Rutery brzegowe, które nie musz ˛a dostarczać danych do innych ruterów poziomu drugiego (ani do regionów posiadaj ˛acych odbiorców), wysyłaj ˛a wiadomo´sć Prune w kierunku regionu, który wygenerował dany strumień danych. Rysunek 2.9 przedstawia ostateczny kształt drzewa komunikacji mi˛edzyregionalnej. Dane komunikacji grupowej s ˛a rozsyłane przy pomocy drzewa transmisji mi˛edzyregionalnej do ruterów poziomu drugiego. Rutery poziomu drugiego dekapsuluj ˛a dane i przesyłaj ˛a je do odbiorców znajduj ˛acych si˛e w danym regionie.

(27)

Źródło S

Router poziomu 1

Router poziomu 2 Drzewo midzyregionalne Drzewo

wewntrzregionalne Region B

Region C Region D

Region E

Rysunek 2.8. H-DVMRP faza druga

Protokołu H-DVMRP nie mo˙zna zastosowa´c w sieci Internet, poniewa˙z wykorzystuje podobne rozwi ˛azania jak protokół DVMRP, a w szczególno´sci zalewanie sieci i odcinanie drzewa rozpinaj ˛acego.

2.2.8. Hierarchical Protocol Independent Multicast

Wykorzystanie punktu spotkań w protokołach CBT czy PIM-SM upraszcza ich imple- mentacj˛e kosztem zwi˛ekszonej koncentracji ruchu, wzrostu opó´znienia przesyłanych danych oraz obci ˛a˙zenia punktu RP ruchem i danymi steruj ˛acymi zwi ˛azanymi z utrzymaniem tuneli pomi˛edzy nadawcami a punktem spotkań. Te negatywne zjawiska zwielokrat- niaj ˛a si˛e w przypadku obsługi przez punkt RP wielu komunikacji grupowych. Protokół HPIM (ang. Hierarchical Protocol Independent Multicast) [105, 83] został skonstruowany z my´sl ˛a o wyeliminowaniu problemów zwi ˛azanych z wykorzystaniem punktu spotkań. Dla- tego te˙z protokół HPIM wykorzystuje wiele punktów spotkań nazywanych C-RP (ang. Can- didate Rendezvous Point), które tworz ˛a pewn ˛a struktur˛e hierarchiczn ˛a.

Ka˙zdy C-RP ma przypisany identyfikator (numer) odpowiadaj ˛acy jego poło˙zeniu w hierarchii (rysunek 2.10). Punkty C-RP z najwy˙zszego poziomu n informuj ˛a o swojej dost˛epno-

´sci punkty spotka´n C-RP z poziomu n-1. W kolejnym kroku rutery z poziomu n-1 obliczaj ˛a

(28)

Źródło S

Region B

Region C Region D

Region E

Rysunek 2.9. H-DVMRP drzewo mi˛edzyregionalne

Odbiorca R1 Odbiorca R2 ródo S

IGMP Report Dane

Router DR Router C-RP

Join-Ack Join

Register Register-Ack

Poziom 0 Poziom 1 Poziom 2 Poziom 3

IGMP Report

Rysunek 2.10. Proces tworzenia drzewa HPIM

(29)

swoj ˛a odległo´s´c do ruterów poziomu wy˙zszego n i przesyłaj ˛a te dane do ruterów poziomu ni˙zszego n-2 wraz z informacj ˛a o swojej dost˛epno´sci. Proces jest powtarzany do osi ˛a- gni˛ecia punktów C-RP poziomu zerowego.

Odbiorca zainteresowany otrzymywaniem danych przesyłanych w ramach komunikacji grupowej przesyła wiadomo´s´c Report protokołu IGMP, która przetwarzana jest przez ruter poziomu zerowego DR (rysunek 2.10). Ruter DR okre´sla warto´s´c funkcji skrótu⁴dla adresu transmisji grupowej i na jej podstawie dokonuje wyboru punktu C-RP poziomu pierwszego.

Nast˛epnie wysyła wiadomo´sć Join(G) do wybranego punktu spotkań. Punkt spotkań poziomu pierwszego tak˙ze okre´sla warto´sć funkcji skrótu dla adresu grupowego i na jej podstawie dokonuje wyboru punktu C-RP poziomu drugiego. Proces powtarzany jest kolejno dla po- zostałych poziomów (rysunek 2.10).

Kiedy ruter DR odbiera pakiety danych przesyłane przez nadawc˛e, sprawdza czy jest cz˛e´sci ˛a drzewa HPIM. Je´sli tak, to pakiet przesyłany jest dalej przez wszystkie interfejsy nale˙z ˛ace do drzewa za wyj ˛atkiem interfejsu, który dane odebrał. Rysunek 2.10 przedstawia sytuacj˛e, w której ruter DR nie jest jeszcze cz˛e´sci ˛a drzewa. W takim przypadku dane s ˛a umieszczane w wiadomo´sci Register i przesyłane do punktu C-RP poziomu pierwszego.

Po odebraniu wiadomo´sci Register ruter C-RP poziomu pierwszego potwierdza jej odbiór i wysyła wiadomo´s´c zwrotn ˛a Register-Ack. Je´sli ruter C-RP poziomu pierwszego jest ju˙z cz˛e´sci ˛a drzewa, to dekapsuluje odbierane pakiety danych i przesyła je dalej po drzewie rozpinaj ˛acym (rysunek 2.11). W przeciwnym przypadku ruter C-RP przekazuje odebran ˛a wiadomo´s´c do rutera C-RP poziomu wy˙zszego (rysunek 2.10).

Rysunek 2.10 przedstawia proces budowy drzewa rozpinaj ˛acego protokołu HPIM, natomiast rysunek 2.11 ilustruje sposób dystrybucji danych. Zauwa˙zmy, ˙ze gał˛ezie drzewa rozpinaj ˛acego okre´slone przez wiadomo´sci Join(G) s ˛a dwukierunkowe i pozwalaj ˛a na prze- syłanie danych zarówno w dół, jak i w gór˛e drzewa.

Głównym celem konstrukcji protokołu HPIM było zminimalizowanie negatywnych skutków działania protokołów z pojedynczym punktem spotkań takich jak: du˙ze obci ˛a˙zenie rutera pełni ˛acego funkcj˛e RP zwi ˛azane z przetwarzeniem danych komunikacji grupowych oraz danych steruj ˛acych utrzymaniem tuneli. Wprowadzanie pewnej liczby hierarchicznych C-RP ograniczyło obci ˛a˙zenie pojedynczych punktów spotkań, poniewa˙z w wersji HPIM rutery C-RP musz ˛a utrzymywać poł ˛aczenia tylko z ruterami warstwy ni˙zszej i wy˙zszej.

Takie podej´scie nie zmniejsza jednak opó´znie´n przesyłanych danych oraz koncentracji ruchu. Co wi˛ecej budowa struktury hierarchicznej w znacz ˛acy sposób komplikuje działanie protokołu. Z tego wzgl˛edu protokół HPIM nie znalazł szerszego zastosowania w realizacji komunikacji grupowej wewn ˛atrz domeny i nie mo˙ze zosta´c wykorzystany do komunikacji grupowej w sieci Internet.

4 Funkcja przypisuj ˛aca wej´sciowemu ci ˛agowi danych quasi-losow ˛a liczb˛e.

(30)

Odbiorca R1 Odbiorca R2 ródo S Router DR Router C-RP Dane

Poziom 0 Poziom 1 Poziom 2 Poziom 3

Drzewo rozpinaj ce Tunel unicast

Rysunek 2.11. Drzewo rozpinaj ˛ace protokołu HPIM

2.3. Mi˛edzydomenowe protokoły rutingu rozgał˛e´znego

W rozdziale 2.2 przedstawiono opis wewn ˛atrzdomenowych protokołów rutingu roz- gał˛e´znego opracowanych dla modelu Multicast IP. Pomimo, ˙ze wykorzystuj ˛a one ró˙zne strategie budowy drzew rozpinaj ˛acych, to wszystkie charakteryzuj ˛a si˛e ograniczon ˛a skalowalno´sci ˛a oraz nie mog ˛a by´c stosowane, w efektywny sposób, przy poł ˛aczaniach rozga- ł˛e´znych obejmuj ˛acych kilka systemów autonomicznych. Warto podkre´sli´c, ˙ze problemy ze skalowalno´sci ˛a wyst˛epowały tak˙ze w tradycyjnych protokołach rutingu zaproponowanych w pierwszym okresie rozwoju sieci Internet.

Rozwi ˛azaniem, które wówczas zaproponowano, był ruting hierarchiczny. Podej´scie to zakłada, ˙ze sie´c dzielona jest na autonomiczne regiony (systemy, domeny), w których dzia- łaj ˛a niezale˙zne instancje protokołów rutingu wewn ˛atrzdomenowego. Takie regiony poł ˛a- czone s ˛a ze sob ˛a przy pomocy protokołów rutingu mi˛edzydomenowego, który zapewnia komunikacj˛e pomi˛edzy domenami.

Zastosowanie koncepcji rutingu hierarchicznego jest jednym z mo˙zliwych rozwi ˛azań problemu skalowalno´sci modelu Multicast IP. Mi˛edzydomenowy ruting rozgał˛e´zny jest bardziej zło˙zony od jego wewn ˛atrzdomenowego odpowiednika. Protokół rutingu mi˛edzydomenowego musi zapewnić rozwi ˛azanie problemów takich jak: skalowalno´sć oraz zarz ˛adzanie pul ˛a adresów IP. Powinien tak˙ze umo˙zliwić dystrybucj˛e informacji o aktywnych nadawcach.

Zgodnie z najlepsz ˛a wiedz ˛a autora taki protokół nie został do tej pory opracowany.