• Nie Znaleziono Wyników

Lightweight Protocol Independent Multicast

4.6. Mechanizm tunelowania

W rozdziale 4.1 przedstawiono ogóln ˛a koncepcj˛e działania mechanizmu tunelowania wykorzystywanego przez protokół LPIM. Wiadomo´s´c Join(S,G), która dociera do sieci nie-obsługuj ˛acej protokołu LPIM, jest przekształcana na pakiet Unicast Join(S,G) i kierowa-na zgodnie z adresem docelowym kierowa-nadawcy. Na wiadomo´s´c Unicast Join(S,G) mo˙ze zare-agowa´c ruter po´sredni znajduj ˛acy si˛e na ´scie˙zce do nadawcy. Ruter ten wysyła wówczas pojedyncze ˙z ˛adanie Unicast Join(S,G), a nast˛epnie replikuje otrzymany strumie´n danych i przesyła przez wszystkie interfejsy, na których odebrano wiadomo´s´c Unicast Join(S,G).

Takie działanie prowadzi do efektywniejszego wykorzystania zasobów sieciowych, ponie-wa˙z ilo´s´c przesyłanych strumieni danych w sieci jest redukowana5.

Wymiana wiadomo´sci Hello jest jednym z podstawowych elementów protokołu LPIM.

Wiadomo´sci Hello wykorzystywane s ˛a do monitorowania i wykrywania s ˛asiednich ruterów obsługuj ˛acych protokół LPIM. Sieci, których rutery nie obsługuj ˛a LPIM, nie wykrywaj ˛a i nie monitoruj ˛a ruterów s ˛asiednich. Dlatego wiadomo´sci Hello nie s ˛a wykorzystywane do zestawiania i utrzymywania poł ˛acze´n rozgał˛e´znych przez tunel.

5 Odfiltrowywanie wiadomo´sci Unicast Join(S,G) jest realizowane przez wyspecjalizowane układy sprz˛e-towe, które mog ˛a rozpozna´c pakiety na podstawie wzorca i dostarczy´c je do procesora centralnego np. poprzez magistral˛e PCI Express.

4.6.1. Maszyna stanu interfejsu nadrz˛ednego

Maszyna stanu interfejsu nadrz˛ednego wykorzystywana jest do zestawienia tunelu ko-munikacji grupowej i wysyłania ˙z ˛ada´n odbioru danych. Maszyna ta wykorzystuje dwa ro-dzaje wiadomo´sci Unicast Join(S,G) i Unicast Prune(S,G). Wiadomo´s´c Unicast Join(S,G) słu˙zy do zestawienia tunelu i wysyłania ˙z ˛ada´n odbioru danych. Wiadomo´s´c Unicast Pru-ne(S,G) przerywa przesyłanie danych i rozł ˛acza tunel. Rozwa˙zana maszyna stanu wykorzy-stuje licznik JT (ang. Join Timer), który powoduje cyklicznie wysyłanie wiadomo´sci Unicast Join(S,G).

JoinDesired->Prawda 1

JoinDesired->Fa sz 3

Wyga ni cie JT 2

Rysunek 4.7. Diagram maszyny stanu interfejsu nadrz˛ednego obsługuj ˛acej mechanizm tunelowania

Ka˙zdy tunel jest obsługiwany poprzez dedykowany wirtualny interfejs uruchamiany w momencie wysyłania pocz ˛atkowej wiadomo´sci Unicast Join(S,G) i usuwany, gdy lista interfejsów wyj´sciowych staje si˛e pusta. Działanie maszyny stanu przedstawiono w tabe-li 4.3. Diagram tej maszyny zilustrowano na rysunku 4.7.

NotJoined jest stanem pocz ˛atkowym maszyny stanu interfejsu nadrz˛ednego. Odpowia-da on sytuacji braku urz ˛adze´n zainteresowanych odbiorem danych przesyłanych w ramach danego poł ˛aczenia rozgał˛e´znego. Oznacza to, ˙ze ruter nie przetwarza, ani nie przechowuje,

˙zadnych informacji. Natomiast w stanie Joined lista interfejsów wyj´sciowych nie jest pusta.

Zatem istnieje chocia˙z jeden ruter podrz˛edny, lub lokalny odbiorca, który jest zainteresowa-ny odbiorem dazainteresowa-nych.

Mechanizm tunelowania wykorzystuje równie˙z funkcj˛e JoinDesired, która pełni w nim dokładnie tak ˛a sam ˛a rol˛e jak w przypadku interfejsu wewn ˛atrzdomenowego (rozdział 4.3).

Je´sli lista interfejsów wyj´sciowych nie jest pusta, to funkcja JoinDesired zwraca warto´s´c

„Prawda", co skutkuje przej´sciem maszyny w stan Joined (przej´scie 1 na rysunku 4.7).

W momencie przej´scia do stanu Joined tworzony jest nowy interfejs wirtualny i urucha-miany jest licznik JT, którego zadaniem jest cykliczne rozsyłanie wiadomo´sci Unicast Jo-in(S,G).

Wyga´sni˛ecie licznika Join Timer powoduje wygenerowanie wiadomo´sci Unicast Join oraz ponowne uruchomienie tego licznika (przej´scie 2, rysunek 4.7). Je´sli natomiast lista

Tabela 4.3. Maszyna stanu dla interfejsu nadrz˛ednego obsługuj ˛acego mechanizm tunelowania

Zdarzenie Poprzedni stan

NotJoined (NJ) Joined (J)

JoinDesired(S,G)->Prawda

-> stan J;

wy´slij Unicast Join(S,G);

uruchom JT

-JoinDesired(S,G)->Fałsz

--> stan NJ;

wy´slij Unicast Prune(S,G);

zatrzymaj JT

licznik JT wygasł

-wy´slij Unicast Join(S,G);

uruchom ponownie licznik JT

interfejsów wyj´sciowych jest pusta (przej´scie 3, rysunek 4.7 ), to nast˛epuje powrót do stanu NotJoined, wysłanie wiadomo´sci Unicast Prune(S,G) i usuni˛ecie wirtualnego interfejsu.

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

Odebrano Unicast Join(S,G) 1

2

Odebrano Unicast Prune(S,G) 3

Odebrano Unicast Join(S,G)

4 Wyga ni cie ET

Rysunek 4.8. Diagram maszyny stanu interfejsu podrz˛ednego obsługuj ˛acego mechanizm tunelowa-nia

Maszyna interfejsu podrz˛ednego reprezentuje urz ˛adzenie, które mo˙ze rozpozna´c i prze-tworzy´c wiadomo´sci Unicast Join(S,G). Takim urz ˛adzeniem mo˙ze by´c zarówno ruter brze-gowy podł ˛aczony do sieci obsługuj ˛acej protokół LPIM, jak i ruter nie b˛ed ˛acy cz˛e´sci ˛a sieci wspieraj ˛acej protokół LPIM. W tym drugim przypadku ruter agreguje przesyłane

wiadomo-´sci Unicast Join(S,G) i wysyła dalej pojedyncze ˙z ˛adanie odbioru danych. Je´sli wiadomo´s´c Unicast Join(S,G) nie zostanie rozpoznana na drodze do odbiorcy, to dotrze do rutera pierw-szego skoku.

Działanie rozwa˙zanej maszyny stanu przedstawiono w tabeli 4.4. Maszyna wykorzystuje dwa stany: NoInfo (NI) i Join (J). W stanie NoInfo urz ˛adzenie sieciowe nie dysponuje in-formacjami na temat odbiorców komunikacji grupowej. Zatem w tym stanie pakiety danych komunikacji grupowej nie s ˛a wysyłane. Po odebraniu wiadomo´sci Unicast Join(S,G) ma-szyna przechodzi do stanu Join. Mama-szyna stanu wykorzystuje tak˙ze licznik JET (ang. Join

Tabela 4.4. Maszyna stanu dla interfejsu podrz˛ednego obsługuj ˛acego mechanizm tunelowania

Zdarzenie Poprzedni stan

NoInfo (NI) Join (J)

Odebrano Unicast Join(S,G)

-> stan J;

uruchom JET;

stwórz interfejs wirtualny uruchom ponownie licznik JET

Odebrano Unicast Prune(S,G)

--> stan NI;

zatrzymaj JET;

usu´n interfejs wirtualny

Wygasł licznik JET

--> stan NI;

usu´n interfejs wirtualny

Expiry Timer) słu˙z ˛acy do przerywania przesyłu pakietów i usuwania z pami˛eci odpowied-nich danych, je´sli odbiorca nie informuje o swej aktywno´sci poprzez okresowe wysyłanie wiadomo´sci Unicast Join(S,G).

NoInfo jest stanem pocz ˛atkowym, w którym jedynie odbiór wiadomo´sci Unicast Jo-in(S,G) powoduje przej´scie do stanu Join (przej´scie 1, rysunek 4.8). W rezultacie takiego działania powstaje wirtualny interfejs, który staje si˛e cz˛e´sci ˛a listy interfejsów wyj´sciowych rozwa˙zanych przez funkcj˛e JoinDesired. W momencie przej´scia do stanu Join nast˛epuje uruchomienie licznika JET, który chroni przed niepoprawnym opuszczeniem drzewa przez urz ˛adzenie odbiorcze.

Przej´scie 2 na rysunku 4.8 okre´sla wa˙zn ˛a dla tunelu wła´sciwo´s´c protokołu LPIM.

LPIM wymaga, aby urz ˛adzenia odbiorcze okresowo generowały wiadomo´s´c Unicast Jo-in(S,G). Wiadomo´sci Unicast Join(S,G) informuj ˛a urz ˛adzenie nadrz˛edne, ˙ze odbiorca jest aktywny i jest zainteresowany dalszym odbiorem danych. Po odebraniu pakietu Unicast Join(S,G) licznik JET uruchamiany jest ponownie.

Wiadomo´s´c Unicast Prune(S,G) wykorzystywana jest do usuni˛ecia tunelu i przerwania przesyłu danych (przej´scie 3, rysunek 4.8). Odbiór wiadomo´sci Unicast Prune(S,G) powo-duje natychmiastowe przej´scie maszyny do stanu NoInfo i usuni˛ecie wirtualnego interfejsu.

Przesyłanie danych przez tunel odbywa si˛e pomi˛edzy dwoma urz ˛adzeniami na ko´ncach tu-nelu. Oznacza to, ˙ze nie ma potrzeby wprowadzenia dodatkowego stanu po´sredniego, jak miało to miejsce w przypadku interfejsu wewn ˛atrzdomenowego (rysunek 4.5).

Przej´scie 4 na rysunku 4.8 umo˙zliwia przej´scie do stanu NoInfo w przypadku braku odbioru regularnych wiadomo´sci Unicast Join(S,G). Niedost˛epno´s´c tych wiadomo´sci jest interpretowana jako opuszczenie struktury drzewa przez urz ˛adzenie odbiorcze. Stan ten wy-krywany jest po wyzerowaniu licznika JET, które powoduje przerwanie transmisji danych, usuni˛ecie wirtualnego interfejsu i przej´scie do stanu NoInfo.

Uczestnik R

Rysunek 4.9. Przykład działania protokołu LPIM wewn ˛atrz domeny