Piotr Zwierzykowski - Poznańskie Warsztaty Telekomunikacyjne

2003
Piotr Zwierzykowski
Instytut Elektroniki i Telekomunikacji
Politechniki PoznaĔskiej
ul. Piotrowo 3a, 60-965 PoznaĔ
Poznañskie Warsztaty Telekomunikacyjne
Poznañ 11-12 grudnia 2003
Maciej Piechowiak
Instytut Mechaniki ĝrodowiska i Informatyki
Stosowanej Akademii Bydgoskiej
ul. Chodkiewicza 30, 85-064 Bydgoszcz
IP MULTICAST – PRZEGLĄD PROTOKOàÓW ROUTINGU*
Streszczenie: W celu stworzenia topologii sieciowej dla
ruchu grupowego, potrzebne jest zdefiniowane protokoáów dziaáających w oparciu o algorytmy, które zapewniáyby konstruowanie wydajnych drzew dystrybucyjnych dla ruchu multicast oraz umoĪliwiáy transmisjĊ pakietów poprzez te struktury. W artykule przedstawiono algorytmy i wykorzystujące je protokoáy
routingu dla poáączeĔ typu multicast w sieciach IP ze
szczególnym uwzglĊdnieniem sieci Internet.
1. WPROWADZENIE
Transmisja multicast jest poĞrednią formą komunikacji miĊdzy powszechnie znaną techniką unicast – charakteryzującą poáączenie miĊdzy dwoma punktami (jedendo-jeden), a techniką rozsiewczą broadcast (polegającą na
wysyáaniu pakietów do wszystkich hostów w danej sieci).
Pozwala ona dostarczaü dane tylko do wybranej grupy
odbiorców, którzy identyfikowani są za pomocą adresu
grupowego (multicast address).
Pomysá wykorzystania techniki multicast w sieciach IP
zrodziá siĊ juĪ w koĔcu lat 80, jednak dopiero od kilku lat
jest ona gáównym przedmiotem badaĔ z zakresu sieci
teleinformatycznych [1-2]. To zainteresowanie wyniknĊáo
przede wszystkim z gwaátownego rozwoju Internetu –
wzrostu liczby nowo przyáączonych punktów sieci, a
takĪe wdroĪeniem nowych technologii, które w ostatnich
latach spowodowaáy wzrost przepustowoĞci sieci i pozwoliáy rozwinąü siĊ sieciowym aplikacjom multimedialnym.
Aplikacje takie, ze wzglĊdu na swój charakter, wymagają
innego podejĞcia w dystrybuowaniu danych.
W tradycyjnym modelu unicast wysáanie tego samego
pakietu do okreĞlonej liczby odbiorców w sieci wiąĪe siĊ z
nawiązaniem poáączenia (sesji TCP/IP) z kaĪdym z hostów biorących udziaá w transmisji. Wynika z tego, Īe
nadawca musi znaü adresy poszczególnych odbiorców i
powieliü ten sam pakiet. Liczba aktywnych poáączeĔ, a co
za tym idzie – liczba zwielokrotnionych pakietów – roĞnie
liniowo ze wzrostem liczby odbiorców w sieci.
Model komunikacyjny dla poáączeĔ multicast (rys. 1.1)
pozwala na redukcjĊ ruchu poprzez przekazywanie pojedynczych pakietów przez routery w dóá do gaáĊzi, w których znajdują siĊ hosty zainteresowane uczestnictwem w
grupie. Taki model komunikacyjny wymaga specjalnych
algorytmów budujących wydajne struktury transportu
pakietów w sieci – drzewa dystrybucyjne.
W rozdziale 2. skupiono siĊ na przeglądzie wykorzystywanych algorytmów i technik tworzenia takich drzew,
jako podstawy popularnych protokoáów routingu IP multicast (omówionych w rozdziale 3.).
2. ALGORYTMY ROUTINGU MULTICAST
2.1.
Algorytmy wyznaczania drzew o najkrótszych
ĞcieĪkach
Gáównym zadaniem grupy algorytmów znajdujących
drzewa o najkrótszych ĞcieĪkach (SPT – Shortest Path
Tree) jest wyznaczenie drzew dystrybucyjnych obejmujących wszystkich odbiorców danej grupy z początkiem
(korzeniem) w punkcie nadawcy w taki sposób, aby odlegáoĞü od nadawcy do kaĪdego z odbiorców wzdáuĪ drzewa
byáa minimalna. Najbardziej znanym algorytmem realizującym tą funkcjonalnoĞü jest algorytm Dijkstry [3]. Technika SPT zakáada istnienie jednego nadawcy w caáym
drzewie. W przypadku istnienia wielu róĪnych Ĩródeá,
osobne drzewa muszą byü wyznaczane dla kaĪdego z
nadawców. Z tego wzglĊdu powstaáy dynamiczne wersje
przywoáanych algorytmów.
2.1.1. Algorytm wektora odlegáoĞci
Rys. 1.1. Model komunikacyjny poáączeĔ multicast
* Praca powstaáa w ramach projektu KBN 4 T11D 02022
W algorytmie wektora odlegáoĞci (Distance Vector
Algorithm) router, do którego bezpoĞrednio podáączony
jest nadawca informuje sąsiednie routery, Īe koszt (odlegáoĞü) miĊdzy nim, a nadawcą wynosi 1. Routery te wyznaczają na podstawie otrzymanych informacji odlegáoĞci
od nadawcy i spoĞród tych wartoĞci wybierają najmniejszą. W nastĊpnym kroku kaĪdy z routerów rozgáasza obliczony koszt do sąsiednich urządzeĔ i proces siĊ powtarza.
Podstawową wadą powyĪszego rozwiązania jest záa skalowalnoĞü – algorytm bardzo wolno odpowiada na zmiany
topologii sieci, a wymiana duĪej liczby komunikatów
miĊdzy urządzeniami wydatnie wpáywa na zmniejszenie
efektywnego pasma w sieci [4].
2.1.2. Algorytm stanu áącza
Algorytm stanu áącza (Link State Algorithm) bazuje
na tradycyjnym algorytmie Dijkstry znajdowania najkrótszej ĞcieĪki i charakteryzuje siĊ tym, Īe kaĪdy router posiada informacje o topologii sieci (niezaleĪnie wyznacza
optymalny koszt do kaĪdego z wĊzáów w drzewie) [4].
Uaktualnianie informacji o topologii sieci polega na przesyáaniu miĊdzy sąsiednimi routerami komunikatów Link
State zawierających koszt poáączenia miĊdzy nimi i odpowiednim zmodyfikowaniu tabel routingu. Wykorzystana jest tutaj technika zalewania pakietami (flooding), przy
czym komunikaty Link State wysyáane są w obie strony –
w stronĊ urządzenia bliĪej nadawcy (up), jak i odbiorcy
(down). W wyniku uaktualnienia kaĪdy router posiada
kompletną informacjĊ o topologii sieci i moĪe wyznaczyü
drogĊ o najmniejszym koszcie miĊdzy nadawcą, a poszczególnymi odbiorcami z wykorzystaniem algorytmu
Dijkstry.
Gáówną zaletą tej techniki jest niezaleĪnoĞü w wyznaczaniu tras przez poszczególne routery. ĩaden z nich nie musi
polegaü na poĞrednich obliczeniach wykonywanych przez
urządzenia „powyĪej” (jak to miaáo miejsce w algorytmie
wektora odlegáoĞci). Proces pobierania informacji tylko z
sąsiedniego routera wydatnie zmniejsza liczbĊ i rozmiar
wymienianych w sieci komunikatów i zwiĊksza skalowalnoĞü drzewa.
2.2. Algorytmy wyznaczania drzew o najmniejszym
koszcie
bĊdące takimi czáonkami, których doáączenie do drzewa
pozwala zminimalizowaü caákowity koszt struktury. Znalezienie takiego drzewa jest problemem NP-zupeánym.
W trakcie projektowania wydajnych algorytmów dla
transmisji multicast, bierze siĊ pod uwagĊ dwa podstawowe parametry charakteryzujące áącze, czyli koszt i opóĨnienie, a nastĊpnie zmierza siĊ do zminimalizowania tych
wartoĞci.
Algorytmy znajdowania najkrótszej ĞcieĪki w drzewie
(SPT) minimalizują odlegáoĞci miĊdzy nadawcą, a kaĪdym
z odbiorców, co przekáada siĊ na zmniejszenie opóĨnienia
miĊdzy koĔcami. Wygenerowane w ten sposób drzewo
nie jest jednak drzewem minimalnym. Z kolei drzewo
Steinera minimalizuje caákowity koszt áączy – nie jest
jednak optymalne, gdyĪ standardowo wystĊpują tutaj
wiĊksze opóĨnienia miĊdzy koĔcowymi routerami. Zadaniem algorytmów multicast powinno byü zatem znalezienie optymalnego rozwiązania korzystając z wyznaczonej
dla kaĪdego áącza funkcji wagowej. Zadania te realizują
algorytmy heurystyczne szukające minimalnego drzewa
rozpinającego z zachowaniem wymagaĔ dotyczących
opóĨnienia. Algorytm te moĪna podzieliü na: wymuszone
drzewo Steinera (Constrained Steiner Tree),wymuszone
drzewo o najtaĔszych krawĊdziach (Constrained Cheapest
Edge Tree) oraz wymuszone drzewo najkrótszej ĞcieĪki
(Constrained Shortest Path Tree).
2.3. Techniki tworzące drzewa Ĩródáowe
Zamiast tworzyü drzewo rozpinające dla caáej podsieci, technika drzew Ĩródáowych (Source-Based Trees)
pozwala stworzyü strukturĊ drzewa dla kaĪdej pary
nadawca-grupa odbiorców (S,G). DziĊki temu kaĪdy host
moĪe byü czáonkiem wielu drzew, jeĞli oczywiĞcie naleĪy
do wiĊcej niĪ jednej grupy multicast.
2.3.1. Algorytm RPB
W przeciwieĔstwie do algorytmów znajdowania najkrótszych ĞcieĪek w drzewie, których gáównym zadaniem
jest zminimalizowanie kosztu (odlegáoĞci) miĊdzy nadawcą, a kaĪdym z odbiorców, algorytmy wyznaczania drzewa o najmniejszym koszcie (Minimum Cost Tree Algorithm) skupiają siĊ na zmniejszeniu caákowitego kosztu
danego drzewa (suma kosztów wszystkich poáączeĔ w
drzewie musi byü minimalna).
Gáównym zadaniem tego algorytmu jest wyznaczenie drzewa rozpinającego, obejmującego nadawcĊ i odbiorców, w ten sposób, aby caákowity koszt drzewa byá
minimalny (Minimum Spanning Tree Algorithm). Klasyczny algorytm Prima sáuĪy do wyznaczania tego typu
drzew, jednak traktuje on wszystkie wĊzáy drzewa jako
czáonków danej grupy, a nie wszystkie hosty w sieci muszą nimi byü.
Dziaáanie algorytmu RPB (Reverse-Path Broadcasting) polega na okreĞleniu drogi jaką przebyá pakiet od
Ĩródáa do routera, który dokonuje oceny. JeĞli jest to najkrótsza moĪliwa droga áącząca router ze Ĩródáem, to pakiet przekazywany jest do wszystkich sąsiednich routerów
w dóá (w stronĊ odbiorcy), poza tym który dany pakiet
wysáaá. W przeciwnym wypadku pakiet jest odrzucany.
àącza w kierunku nadawcy, tzn. te poprzez które routery
otrzymują pakiety, okreĞlane są mianem rodzica (parent),
z kolei te wzdáuĪ których pakiety są przekazywane w
kierunku odbiorców – okreĞla siĊ mianem dziecka (child).
Do kaĪdego z routerów prowadzi wiĊc jedno áącze parent,
które jednoczeĞnie jest elementem najkrótszej drogi od
Ĩródáa i tyle poáączeĔ typu child, ile routerów znajduje siĊ
w jego sąsiedztwie. Algorytmy RPB cechuje wydajnoĞü i
áatwoĞü implementacji. Dane od Ĩródáa do odbiorców
przekazywane są róĪnymi drogami, co zapobiega koncentracji ruchu w niektórych partiach sieci [5].
2.2.2. Algorytm minimalnego drzewa Steinera
2.3.2. Algorytm TRPB
NiedogodnoĞü powyĪszej techniki usuwa algorytm
minimalnego drzewa Steinera (Minimum Steiner Tree),
którego zadaniem jest utworzenie minimalnego drzewa
rozpinającego skáadającego siĊ tylko z czáonków danej
grupy multicast, a takĪe uwzglĊdniającego punkty nie
Algorytm
TRPB
(Truncated
Reverse-Path
Broadcasting) rozwija funkcjonalnoĞü algorytmu RPB.
Podczas przekazywania pakietów bierze pod uwagĊ informacje dotyczące czáonkostwa w grupach multicast,
przekazywanych przez protokóá IGMP [6]. JeĞli wiĊc w
2.2.1. Algorytm minimalnego drzewa rozpinającego
topologii sieci istnieje router nie zawierający w swej podsieci Īadnego hosta bĊdącego czáonkiem jakiejkolwiek
grupy multicast, nie otrzyma on pakietów kierowanych
wzdáuĪ drzewa do poszczególnych odbiorców.
Algorytm ten likwiduje niepotrzebny ruch w podsieciach
granicznych, które nie zawierają czáonków danej grupy
multicast. JednakĪe nie bierze on pod uwagĊ czáonkostwa
w tych grupach w obrĊbie podsieci poĞrednich.
2.3.3. Algorytm RPM
RPM (Reverse-Path Multicasting) jest algorytmem,
który tworzy drzewo dystrybucyjne w oparciu o podsieci
zawierające aktywnych czáonków grup multicast oraz
routery, znajdujące siĊ na drodze do podsieci zawierających czáonków grup. Pozwala wiĊc blokowaü ruch nie
tylko do podsieci danego routera, w której nie wystĊpują
czáonkowie grup (odcinanie liĞci), lecz takĪe zatrzymaü
ruch do routerów powyĪej, na drodze do nadawcy (odcinanie gaáĊzi).
Pierwszy etap algorytmu polega na wysáaniu pakietów do
wĊzáów drzewa za pomocą techniki TRPB. Gdy Īadna z
podsieci doáączonych do routera nie zawiera czáonków
grup multicast, router wysyáa komunikat zwrotny z Īądaniem odciĊcia go od struktury drzewa dystrybucyjnego
(prune) do routera powyĪej (parent link) z ustawionym
znacznikiem TTL o wartoĞci 1. JeĞli router bliĪej nadawcy
takĪe nie zawiera w swych podsieciach czáonków grup
multicast, to równieĪ wysyáa komunikat z Īądaniem odciĊcia. Pozwala to optymalizowaü drzewo poprzez usuwanie wiĊkszych gaáĊzi [5].
3. PROTOKOàY ROUTINGU MULTICAST
3.1. DVMRP
Protokóá DVMRP (Distance Vector Multicast Routing Protocol) stosowany w poáączeniach multicast wykorzystuje drzewa dystrybucyjne generowane „od Ĩródáa”. Pierwotne wersje protokoáu bazowaáy na algorytmie
RIP (Routing Information Protocol) wykorzystując jednoczeĞnie technikĊ TRBP [7]. Od wersji 3.0 oprogramowania mrouted, wspierającego routing w sieci MBone,
DVMRP dziaáa w oparciu o algorytm RPM.
Routery wykorzystujące DVMRP obsáugują bezpoĞrednie
poáączenia pomiĊdzy podsieciami oraz tzw. poáączenia
tunelowane, czyli przebiegające poprzez inne podsieci,
które bezpoĞrednio nie biorą udziaáu w transmisji multicast.
W sposób charakterystyczny dla algorytmu RPM, pierwszy pakiet transmitowany w obrĊbie pary: Ĩródáo-grupa
multicast, wysyáany jest do kaĪdej z podsieci (o ile wartoĞü wskaĨnika TTL na to pozwala). Po tej operacji routery stanowiące w sieci liĞcie, czyli nie transmitujące pakietów do Īadnych dalszych podsieci, mogą odáączyü siĊ od
drzewa dystrybucyjnego (jeĞli w obrĊbie swoich podsieci
nie posiadają aktywnych czáonków grupy). Pierwszą operacją realizowaną przez protokóá DVMRP jest wiĊc rozsyáanie wiadomoĞci odáączenia (prune message). Ze wzglĊdu na dynamikĊ powstaáego drzewa (routery mogą odáączaü siĊ od drzewa dystrybucyjnego na skutek komunikatów IGMP) istnieje potrzeba okresowej weryfikacji powstaáej struktury. Ta funkcjonalnoĞü protokoáu DVMRP
polega na periodycznym rozsyáaniu wiadomoĞci zalewają-
cej (flooding) docierającej ponownie do kaĪdej podsieci,
w celu okreĞlenia ewentualnych, nowych czáonków grupy.
Operacja ta jest szczególnie istotna z powodu wykorzystywania protokoáu UDP (User Datagram Protocol) do
transmisji wiadomoĞci odáączania. Ze wzglĊdu na to, Īe
UDP nie gwarantuje dotarcia informacji, szybka aktualizacja drzewa dystrybucyjnego zapobiega ewentualnym
nadmiarowym pakietom transmitowanym niepotrzebnie
do podsieci, które nie oczekują na te dane.
Ostatnią operacją realizowaną przez DVMRP jest funkcja
ponownego doáączenia (grafting). UmoĪliwia to szybkie
uaktualnienie drzewa dystrybucyjnego w przypadku pojawienia siĊ hosta zgáaszającego chĊü uczestnictwa w
danej grupie multicast. Router, który w swej podsieci
wykryje nowego czáonka grupy wysyáa komunikat graft w
stronĊ routerów wyĪej, które uaktualniają swe tablice
trasowania przyáączając nową gaáąĨ. Takie rozwiązanie
zapewnia szybkie podáączenie nowego uĪytkownika,
zanim sieü przeprowadzi operacjĊ odtwarzania caáej struktury drzewa.
Ze wzglĊdu na wykorzystanie powszechnie znanego algorytmu RIP, DVMRP cechuje wzglĊdnie prosta implementacja. Ponadto technikĊ tą charakteryzuje maáe wykorzystanie mocy obliczeniowej procesora, co w rezultacie
pozwala obsáuĪyü nawet duĪe sieci. Periodyczne zalewanie sieci pakietami w celu aktualizacji drzew dystrybucyjnych jest jednak czynnikiem niekorzystnym wydatnie
zmniejszającym przepustowoĞü w duĪych sieciach.
3.2. HDVMRP
HDVMRP (Hierarchical Distance Vector Multicast
Routing Protocol) pozwala transmitowaü pakiety w sieciach podzielonych na regiony (odzwierciedlające podziaá
na domeny). KaĪda z domen otrzymuje swój unikalny
identyfikator. W obrĊbie takiej domeny moĪe funkcjonowaü dowolny protokóá IP multicast (protokoáy pierwszego
poziomu), natomiast miĊdzy tymi obszarami stosuje siĊ
protokóá DVMRP implementowany w routerach granicznych (protokóá drugiego poziomu obsáugujący routing
miĊdzydomenowy). MoĪliwa jest równieĪ trzypoziomowa
hierarchia routingu (poprzez wprowadzenie superregionów), jednak skomplikowana enkapsulacja pakietów
sprawia, Īe jest to maáo wydajny protokóá routingu.
HDVMRP wykorzystywany jest w przypadku duĪych
obszarów sieciowych w celu podziaáu ich na mniejsze
jednostki, pozwalając znacznie ograniczyü ruch miĊdzy
domenami [5].
3.3. MOSPF
ZaleĪnoĞü DVMRP od protokoáów unicast powoduje, Īe staje siĊ on niepraktyczny w segmentach sieci, które
wykorzystują inne protokoáy routingu, np. OSPF (Open
Shortest Path First). MOSPF (Multicast Extensions to
Open Shortest Path First) rozszerza funkcjonalnoĞü tradycyjnego protokoáu OSPF o wsparcie dla transmisji multicast – wykorzystuje informacje gromadzone przez OSPF
w oparciu o algorytm stanu áącza i na ich podstawie buduje drzewa dystrybucyjne multicast [8]. Zapewnia takĪe
wspóápracĊ z routerami z zaimplementowanym OSPF, co
pozwala na przekazywanie pakietów unicast w drzewie
multicast.
Podobnie jak wczeĞniej omówione techniki, routery
MOSPF wykorzystują IGMP w celu wykrywania aktywnych czáonków grup w swych podsieciach i utrzymują
bazy danych takich lokalnych grup. KaĪdy z nich posiada
kompletną topologiĊ sieci oraz informacje na temat
uczestnictwa w grupach i na tej podstawie wyznacza najkrótsze trasy miĊdzy nadawcą, a czáonkami grup w sieci.
Gáówne cechy MOSPF:
x kaĪdy z routerów wyznacza to samo drzewo dystrybucyjne o najkrótszych ĞcieĪkach generowane od Ĩródáa,
x bazy danych o grupach multicast przechowywane w
routerach są zsynchronizowane – pozwala to na tworzenie i aktualizacje drzew dystrybucyjnych w pamiĊciach
routerów (w kierunku od Ĩródáa do odbiorców); oznacza
to, Īe zbĊdna staje siĊ technika zalewania pakietami
wszystkich punktów sieci w celu aktualizacji drzewa,
x tworzenie drzew dystrybucyjnych w trybie na Īądanie
sprawia, Īe aktualizacja informacji pomiĊdzy routerami
jest rozáoĪona w czasie, co ogranicza nadmierne wykorzystywanie zasobów routerów; moĪe to sprawiü pewne
problemy w przypadku licznych zmian w topologii w
obrĊbie niewielkiego obszaru sieci, lecz w obliczu usystematyzowanych, dáugich sesji, taki tryb jest bardzo
wydajny i stabilny.
Przesyáanie datagramów w obrĊbie obszarów okreĞlone
jest za pomocą pamiĊci przekazywania, w którą wyposaĪony jest kaĪdy router MOSPF. W przypadku przesyáania
danych miĊdzy róĪnymi obszarami sieci, MOSPF okreĞla
router miĊdzyobszarowy (inter-area multicast forwarder),
który odpowiedzialny jest za przekazywanie informacji o
czáonkostwie w grupach i datagramów z danymi. CzĊsto
jako wsparcie dla tego rozwiązania konfiguruje siĊ równieĪ graniczny router OSPF – ABR (Area Border Router),
który równieĪ pracuje jako przekaĨnik ruchu multicast
pomiĊdzy obszarami.
Routery peániące rolĊ áączników pomiĊdzy róĪnymi obszarami, tworzą podsumowania dotyczące czáonkostwa w
grupach w doáączonych do nich obszarach i transmitują te
dane do obszaru gáównego (backbone), zawierającego
informacje na temat wszystkich pozostaáych obszarów.
Odbywa siĊ to z wykorzystaniem komunikatów LSA
(Link State Advertisement). Problem ĞciĞle związany z
operowaniem pomiĊdzy obszarami to odáączanie routerów
(prunning). Proces ten musi byü poddawany specjalnej
kontroli, aby z drzewa nie zostaáy usuniĊte routery transmitujące dane do innych obszarów. Protokóá MOSPF
cechuje szybka adaptacja do zmian zachodzących w topologii, a takĪe brak techniki zalewania (flooding). Poprzez
wspóápracĊ z OSPF pozwala przekazywaü zarówno ruch
unicast, jak i multicast. MOSPF jest jednak protokoáem o
znacznej záoĪonoĞci obliczeniowej (wymaga od kaĪdego
routera wyznaczenia drzew o najkrótszych ĞcieĪkach
miĊdzy nadawcą, a grupą odbiorców dla kaĪdej grupy
multicast). Nie jest teĪ dobrym rozwiązaniem w topologiach o duĪym rozproszeniu czáonków grup (sparse mode).
3.4. PIM (Protocol-Independent Multicast)
GrupĊ protokoáów PIM (Protocol-Independent Multicast)
tworzą dwa protokoáy PIM-DM (Protocol-Independent
Multicast Dense Mode) i PIM-SM (Protocol-Independent
Multicast Sparse Mode), które charakteryzują siĊ one tym
samym zbiorem komunikatów i wiadomoĞci kontrolnych.
PIM-DM stosowany jest w Ğrodowisku, w którym czáonkowie grup multicast rozlokowani są na niewielkim obszarze, czyli gĊsto (dense). Wtedy moĪliwe jest osiągniĊcie duĪych przepáywnoĞci i protokóá dziaáa najwydajniej.
PIM-SM jest z kolei rozwiązaniem stosowanym w przypadku rzadkiego rozmieszczenia czáonków grup (sparse)
w wielu regionach sieci (przepáywnoĞci są wtedy relatywnie mniejsze). PIM jest niezaleĪny od protokoáu routingu
unicast (w przeciwieĔstwie do DVMRP i MOSPF).
3.4.1. PIM-DM
Podobnie jak DVMRP, PIM-DM [9] wykorzystuje
technikĊ floodingu w celu budowy drzewa – kaĪdy z routerów rozsyáa pakiety do wszystkich swoich interfejsów,
z wyjątkiem tego interfejsu, z którego pakiety napáynĊáy.
PodobieĔstwo wynika równieĪ z zastosowania algorytmu
RPM (Reverse-Path Multicasting) w celu odcinania od
drzewa gaáĊzi nie biorących udziaáu w transmisji.
W niektórych przypadkach PIM-DM moĪe siĊ okazaü
protokoáem mniej wydajnym od DVMRP, gdyĪ nie zapewnia dostatecznie wnikliwej kontroli interfejsów routerów, co sprawia, Īe nie są one wraĪliwe na ruch zalewający. Routery oparte na PIM-DM przechowują dane o wiadomoĞciach Īądania odáączenia (prune messages), w odniesieniu do par Ĩródáo – grupa, w swoich pamiĊciach.
Niejednokrotnie jednak moĪe siĊ zdarzyü, Īe z powodu
braku dostĊpnych zasobów (pamiĊci), router usunie najstarszy zapis. W wyniku tego sieü moĪe zostaü obciąĪona
dodatkowymi pakietami, przesyáanymi w celu ponownego
okreĞlenia drzewa dystrybucyjnego (dla usuniĊtego wpisu
Ĩródáo – grupa). Ta wada jednak nie jest zbyt istotna,
gdyĪ PIM-DM przeznaczony jest dla sieci o duĪych przepáywnoĞciach a periodyczny ruch zalewowy generowany
przez protokóá nie obciąĪa sieci w znaczący sposób. Protokoáy PIM wymagają obecnoĞci routera desygnowanego
w kaĪdej podsieci. W ten sposób tylko jedno urządzenie
zajmuje siĊ transmisją komunikatów IGMP i kontrolą
czáonkostwa w grupach.
Zarówno dla PIM-DM, jak i PIM-SM sposób wyboru
routera desygnowanego jest taki sam: jeĞli w podsieci
istnieje wiĊcej niĪ jeden router, to routerem desygnowanym zostaje ten, który posiada wyĪszy adres IP. O ile
rozsyáanie zapytania IGMP nie koniecznie musi byü realizowane przez router desygnowany, musi on zapewniü
przesyáanie wiadomoĞci odáączenia (prune) oraz przyáączenia (join) do tzw. punktu spotkania (rendezvous point).
Router desygnowany gromadzi równieĪ informacje na
temat aktywnych punktów spotkaĔ dla kaĪdej grupy multicast. Routery posiadające zaimplementowany protokóá
PIM zawierają procedury do wyboru alternatywnej drogi
spoĞród moĪliwych dróg o jednakowym koszcie. JeĞli
istnieją dwie drogi miĊdzy dwoma punktami w sieci i
kaĪdej z nich przypisany jest taki sam koszt, pakiet zostaje przesáany do urządzenia, które posiada wyĪszy adres IP
Zgodnie z rys. 3.1 router A przekazuje pakiet do routerów
B i C. W podsieci routera B taki pakiet zostanie przesáany
do czáonka grupy. PoniewaĪ w otoczeniu C nie ma aktywnych czáonków grup multicast, wyĞle on do A komunikat
z Īądaniem odáączenia. Gdyby sytuacja taka miaáa miejsce
odáączony zostaáby takĪe router B.
Rys. 3.1. Wspóádzielenie áącza przez routery PIM.
PIM zapewnia mechanizm rozwiązujący ten problem:
wszystkie wiadomoĞci z Īądaniem odáączenia muszą byü
wysyáane na adres multicast 224.0.0.2 (okreĞlający
wszystkie routery w podsieci). Tak wiĊc wiadomoĞü z
Īądaniem odáączenia wysáana przez router C, dotrze zarówno do routera A, jak i B. Router A nie odáączy grupy
od razu a jedynie zaplanuje takie dziaáanie. Tymczasem
router B po otrzymaniu tej wiadomoĞci wyĞle wiadomoĞü
przyáączenia na wspólny adres 224.0.0.2. Router A po jej
otrzymaniu zrezygnuje z operacji odáączenia grupy [10].
3.4.2. PIM-SM
Protokóá PIM-SM zostaá zaprojektowany w celu
efektywnego przekazywania ruchu multicast do czáonków
grup rozmieszczonych rzadko (sparse), tzn. w róĪnych
regionach sieci (taki rodzaj grup wystĊpuje w sieciach
WAN) [10]. Nieefektywne okazują siĊ zatem protokoáy
wykorzystujące flooding w początkowej fazie budowania
drzewa dystrybucyjnego.
W protokole PIM-SM najwaĪniejszą rolĊ odgrywają tzw.
punkty spotkaĔ (rendezvous points) czyli routery wykorzystywane przez nadawców (do rozgáoszenia swej obecnoĞci), jak i odbiorców – aby uzyskaü informacje na temat
nadawców w danej grupie multicast (rys. 3.2). Gdy uĪytkownik w danej podsieci wyrazi chĊü uczestnictwa w
grupie multicast, router obsáugujący jego podsieü musi
wysáaü wiadomoĞü z Īądaniem doáączenia (join message)
do punktu spotkaĔ. Dokonuje tej procedury po otrzymaniu
odpowiedniego komunikatu IGMP od uĪytkownika. PIMSM, w przeciwieĔstwie do PIM-DM, nie przesyáa danych
do wszystkich routerów (poza tymi, które odáączyáy siĊ od
struktury drzewa dystrybucyjnego), ale ogranicza ich
iloĞü, wysyáając pakiety jedynie do wczeĞniej przyáączonych routerów. Gdy topologia sieci tego wymaga, router
wysyáa Īądanie przyáączenia do kolejnego routera w kierunku rendezvous point. W ten sposób tworzy siĊ struktura, która ostatecznie poáączy nowego czáonka grupy z
routerem bĊdącym punktem spotkaĔ.
Dla danej domeny obsáugiwanej przez protokóá PIM-SM,
istnieje tylko jeden zestaw routerów – punktów spotkaĔ i
kaĪdy z nich peáni rolĊ równorzĊdną, obsáugując jedną
grupĊ uĪytkowników w danej chwili.
W topologii sieci lokalnej opartej na PIM-SM wystĊpuje
router desygnowany i charakteryzuje siĊ takimi samymi
cechami jak w przypadku PIM-DM. Gdy otrzyma on
raport IGMP informujący o tworzeniu nowej grupy, okreĞla czy grupa ta musi byü oparta na punkcie spotkaĔ. JeĞli
tak jest, router desygnowany tworzy wpis w swojej pamiĊci dotyczący pary: dowolne Ĩródáo – grupa i transmituje wiadomoĞü przyáączenia (join message) w trybie
unicast do najbliĪszego, dostĊpnego dla danej grupy,
punktu spotkaĔ.
Routery poĞrednie równieĪ dokonują wpisów dotyczących
nowej grupy w swoich pamiĊciach, o ile takie wpisy jeszcze nie istnieją. Dopiero po zakoĔczeniu tej operacji,
utworzona zostanie droga do dystrybucji pakietów dla
nowej grupy.
JeĞli nadawca jako pierwszy wyĞle pakiet, desygnowany
router dokona enkapsulacji pakietu i przeĞle go w trybie
unicast do punktu spotkaĔ, przypisanego grupie docelowej. Pakiet po enkapsulacji nosi nazwĊ pakietu rejestracyjnego PIM-SM (PIM-SM register packet). Gdy router
spotkaĔ otrzyma taki pakiet rejestracyjny, odsyáa w kierunku routera desygnowanego Ĩródáa wiadomoĞü przyáączenia.
Drzewo dystrybucyjne zakorzenione w punkcie spotkaĔ
zapewnia poáączenia do wszystkich czáonków grupy,
jednak stworzone drogi najczĊĞciej nie są optymalnymi
dla danej topologii. Protokóá PIM-SM umoĪliwia zarówno
przesyáanie pakietów poprzez te drzewa, jak i tworzenie
nowych drzew zakorzenionych w punkcie nadawcy i
charakteryzujących siĊ najkrótszymi, moĪliwymi ĞcieĪkami. Takie rozwiązanie ogranicza opóĨnienia w przekazywaniu pakietów od Ĩródáa do czáonków grupy oraz
redukuje koncentracjĊ ruchu jedynie w obrĊbie RP (rendezvous point).
Wadą PIM-SM jest tworzenie tzw. wąskich gardeá w
punktach spotkaĔ. Są one równieĪ potencjalnymi punktami zagraĪającymi integracji caáego drzewa w przypadku
awarii [11].
3.5. HPIM
HPIM (Hierarchical Protocol-Independent Multicast) jest hierarchiczną wersją protokoáu PIM. Charakteryzuje siĊ hierarchizacją punktów spotkaĔ i przydzieleniem ich do róĪnych grup w zaleĪnoĞci od usytuowania w
sieci oraz zakresu peánionych funkcji. Takie rozwiązanie
zapobiega powstawaniu pĊtli przy transmisji pakietów
oraz umoĪliwia rozdzielenie danych kontrolnych od danych aplikacji multicast [2].
3.6. CBT
Rys. 3.2. Model sieci z wykorzystaniem protokoáu PIM-SM
Protokóá CBT (Core Based Tree) zostaá zaprojektowany specjalnie w celu rozwiązania problemu skalowalnoĞci w sieciach publicznych, takich jak Internet. CBT
jest protokoáem niezaleĪnym od zaimplemen-towanych
protokoáów unicast – wykorzystuje istniejące tablice routingu do tworzenia drzew dystrybucyjnych.
UĪytkownik chcący doáączyü siĊ do grupy informuje
lokalny router (z zaimplementowanym protokoáem CBT)
wykorzystując komunikaty IGMP. Po otrzymaniu takiego
komunikatu router CBT wysyáa wiadomoĞü z Īądaniem
przyáączenia do kolejnego routera w kierunku do routera –
rdzenia drzewa dystrybucyjnego, przypisanego danej
grupie (rys. 3.3).
Rys. 3.3. Doáączanie czáonka grupy do drzewa CBT
Router rdzeniowy odpowiada na komunikat join potwierdzeniem przyáączenia do drzewa (acknowledge). Istnieje
teĪ bardziej korzystne rozwiązanie, jeĞli miĊdzy routerem
desygnowanym, a rdzeniowym istnieje urządzenie naleĪące juĪ do drzewa CBT – wtedy takie urządzenie wysyáa
wczeĞniej komunikat potwierdzający. Niemniej, kaĪdy z
routerów poĞrednich, po otrzymaniu wiadomoĞci z Īądaniem, przechodzi w chwilowy stan áączenia (transient join
state). W wyniku tego stanu nastĊpuje zapisanie informacji o grupie multicast oraz numerów portów: wejĞciowego
(przez który Īądanie zostaáo otrzymane) i wyjĞciowego
(przez który Īądanie zostanie przesáane dalej). UmoĪliwi
to przesáanie potwierdzenia tą samą drogą do nadawcy
Īądania. Gdy w kierunku przeciwnym przesyáana jest
wiadomoĞü potwierdzająca, routery poĞrednie zmieniają
swój stan na aktywny, co wiąĪe siĊ z zapisaniem w pamiĊci portu wejĞciowego i wyjĞciowego przy transmisji pakietów przeznaczonych dla danego czáonka grupy.
W takim drzewie dla kaĪdej pary sąsiednich routerów
wyróĪniamy: router dziecko (bliĪej odbiorcy) i router
rodzic (bliĪej nadawcy). Po utworzeniu gaáĊzi routery
poĞrednie periodycznie przesyáają komunikat echa do
swojego rodzica. Na taki komunikat router rodzic odpowiada analogicznym komunikatem. Wymiana komunikatów odbywa siĊ przy uĪyciu poáączenia unicast.
Ruch generowany przez protokóá CBT jest znacznie
mniejszy niĪ w przypadku protokoáów pracujących w
trybie gĊstym. Mniejsze są takĪe wymagania sprzĊtowe
stawiane routerom. Niestety, punkty spotkaĔ (RP) mogą
stanowiü wąskie gardáa w transmisji pakietów multicast, a
ich awarie – niekorzystnie wpáywaü na integralnoĞü drzewa dystrybucyjnego. Istnieje takĪe problem związany z
umiejscowieniem w topologii drzew routerów rdzeniowych (moĪliwa konfiguracja automatyczna lub rĊczna).
3.7. OCBT
OCBT (Ordered Core-Based Trees) jest wersją protokoáu CBT, która wprowadza hierarchiĊ wĞród rdzeni
obecnych w topologii sieci. Takie rozwiązanie zapewnia
brak wystĊpowania pĊtli przy przesyáaniu pakietów oraz
gwarantuje skoĔczony, maksymalny czas odtworzenia
struktury po wystąpieniu báĊdu (awarii) w którymkolwiek
z routerów.
4. PODSUMOWANIE
Implementacja technologii multicast w sieciach dalekiego zasiĊgu wiąĪe siĊ z potrzebą wyboru okreĞlonych
narzĊdzi w postaci stosownego protokoáu routingu opartego o wydajny algorytm. Podyktowane jest to przede
wszystkim dynamiką tworzenia grup multicast. DuĪe
znaczenie ma takĪe rozmieszczenie uĪytkowników w
sieci, jej wielkoĞü i przewidywany rozwój. Operacje trasowania zaimplementowane w routerach są bardzo skomplikowane, a poziom ich záoĪonoĞci wzrasta wraz z doáączaniem kolejnych podsieci.
W artykule omówiono popularne protokoáy routingu
w sieciach IP multicast pod kątem ich zastosowania w
sieciach gĊstych (DVMRP, MOSPF, PIM-DM) oraz rzadkich (PIM-SM, CBT). Z racji rozwoju sieci Internet, bĊdącej siecią rzadką, istnieje zapotrzebowanie na skalowalne protokoáy routingu uwzglĊdniające hierarchizacjĊ urządzeĔ sieciowych (routing hierarchiczny) oraz techniki
wspóádzielenia drzew dystrybucyjnych takie rozwiązania
wdroĪone zostaáy w protokoáach HDVMRP, HPIM czy
OCBT.
SPIS LITERATURY
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
S. E. DEERING, Host extensions for IP multicasting,
IETF, RFC 1112, August 1989.
S. HAREZ AND D. KATZ, Administrative Domains
and Routing Domains: A model for routing in the
Internet, IETF, RFC 1136, December 1989.
E. DIJKSTRA, A note on two problems in connection
with graphs, Numerical Mathematics 1, (1959),
395-412.
S. PAUL, Multicasting on the internet and its applications, Kluwer Academic Publishers, 1998.
D. KOSIUR, IP multicasting: the complete guide to
interactive corporate networks, Wiley Computer
Publishing, 1998.
W. FENNER, Internet Group Management Protocol,
version 2, IETF, RFC 2236, November 1997.
D. WAITZMAN, C. PARTRIDGE AND S. E. DEERING,
Distance Vector Multicast Routing Protocol, IETF,
RFC 1075, November 1988.
J. MOY, Multicast Extensions to OSPF, IETF, RFC
1584, March 1994.
A. ADAMS, J. NICHOLAS, W. SIADAK Protocol
Independent Multicast - Dense Mode (PIM-DM),
IETF, INTERNET DRAFT , February 2003.
W. R. PARKHURST, Cisco Multicast Routing and
Switching, McGraw-Hill, 1999.
S. HAREZ AND D. KATZ, Protocol Independent
Multicast – Sparse Mode (PIM-SM): Protocol
Specification, IETF, RFC 2117, December 1989.