Protokoły routingu multicast – protokół wewnątrzdomenowy DVMRP

Protokół DVMRP (Distance-Vector Multicast Routing Protocol) jest jednym z pierwszych protokołów routingu multicastowego. Został opracowany na potrzeby testowej sieci mbone (Multicast Backbone). Jest to protokół trybu gęstego, który wykorzystuje drzewa dystrybucyjne budowane „od źródła”.

Pierwsze wersje protokołu DVMRP były oparte na algorytmie RIP (Routingu Information Protocol), wykorzystując dodatkowo techniki zaimplementowane w algorytmie TRPB (Truncated Reverse-Path Broadcasting). Protokół DVMRP od wersji 3.0 stosuje algorytm RPM (Reverse-Path Multicasting).

Dokument RFC 1075 stanowi jedyny oficjalny standard DVMRP w wersji 1, który w praktyce nie jest stosowany. Pomimo nie zakończonej do dnia dzisiejszego standaryzacji, od wielu lat w routerach multicastowych wykorzystywana jest wersja 3 tego protokołu, funkcjonująca na zasadzie projektu standardu (Internet draft). Dlatego ta wersja będzie przedmiotem niniejszego artykułu. Routery wykorzystujące protokół DVMRP obsługują zarówno bezpośrednie połączenia pomiędzy podsieciami, jak i tzw. połączenia tunelowe, czyli przebiegające poprzez inne podsieci, które nie biorą bezpośredniego udziału w obsłudze ruchu multicast.

Komunikaty protokołu DVMRP
Komunikaty protokołu DVMRP są przesyłane w datagramach IP i wszystkie posiadają ten sam nagłówek. DVMRP identyfikowany jest w polu protokół nagłówka stałego datagramu przez liczbę 2. Strukturę nagłówka protokółu DVMRP przedstawiono na rysunku 1.

Rysunek 1. Format nagłówka DVMRPv3

Nagłówek komunikatów DVMRP składa się z 6 pól:

• Typ – pole to identyfikuje komunikaty protokołu DVMRP. Wartość tego pola zawsze wynosi szesnastkowo 13.
• Kod – jest to pole, które decyduje, jaki komunikat jest przesyłany. DVMRPv3 posiada zestaw pięciu komunikatów, które zostały przedstawione w tabeli 1.
• Suma kontrolna– standardowa suma kontrolna chroniąca komunikat, która obejmuje komunikat DVMRPv3 i pseudonagłówek IP.
• Rezerwa – jest polem zarezerwowanym, wykorzystywanym do różnych celów przez niektóre spośród komunikatów DVMRPv3.
• Podwersja (Minor Version) – określa kolejną podwersję komunikatu.
• Wersja (Major Version) – identyfikuje wersję protokołu, w tym wypadku 3.

Pola Wersja oraz Podwersja pozwalają różnym routerom na zgodną współpracę z podaną wersją oraz podwersją protokołu DVMRP.

Tabela 1. Podstawowe komunikaty protokołu DVMRPv3 [RFC 1075]

Protokół DVMRP posługuje się pięcioma podstawowymi komunikatami, z których każdy ma swoją określoną funkcję. Za ich pomocą realizowana jest komunikacja miedzy routerami, co w konsekwencji prowadzi do sprawnej budowy i obsługi drzewa dystrybucji multicastowej.

Przy pomocy komunikatu Testuj (Probe) router sprawdza, jakie routery DVMRP znajdują się w jego sąsiedztwie. Określa w ten sposób, jakie wsparcie dla transmisji multicast i za pomocą jakiej wersji protokołu DVMRP realizują sąsiadujące routery. Wartość pola kod w przypadku komunikatu Testuj wynosi 01H.

Poza standardowymi polami nagłówka DVMRPv3 (rysunek 1) zawiera on pola: możliwości routera (Capabilities), identyfikator generacji (Generation ID), adres sąsiada (Neighbor IP Address).

Pole możliwości routera bardzo dokładnie określają funkcjonalność routera. Jest to możliwe poprzez zastosowanie szeregu znaczników (rysunek 2):

Rysunek 2. Znaczniki pola możliwości routera protokołu DVMRPv3

• znacznik U (Unused) – są to pola aktualnie niewykorzystywane, w których wartość ustawiana jest na zero,
• znacznik N (Netmask) – określa możliwość ustawienia maski w komunikatach Odłącz (Prune), Dołącz (Graft) i Potwierdzenie dołączenia (Graft Ack),
• znacznik S (SNMP) – informuje, że router obsługuje protokół SNMP (Simple Network Management Protocol),
• znacznik M (Mtrace) – informuje, że router obsługuje multicastową wersję polecenia traceroute (pozwala na śledzenie trasy, po której przesyłane są datagramy IP),
• znacznik G (Genid) – informuje, że router potrafi obsługiwać mechanizm generowania identyfikatorów umieszczanych w polu identyfikator generacji,
• znacznik P (Prune) – oznacza, że router obsługuje mechanizm odłączania routerów, do których nie ma dołączonych odbiorców,
• znacznik L (Leaf) – obecnie niewykorzystywany, ale planowane jest wykorzystanie jego w kolejnych wersjach protokołu.

Pole identyfikator generacji jest to unikalny identyfikator bieżącej generacji serii komunikatów Testuj. Wartość tego pola po każdym restarcie ustawiana jest przez router na wartość zależną od zegara czasu rzeczywistego. W ten sposób wszystkie sąsiadujące routery mogą stwierdzić, czy od ostatniego wysłania komunikatu Testuj dany router był restartowany. Jeżeli tak, to wszelkie akcje podjęte przez routery sąsiadujące zostaną przez nie automatycznie anulowane.

Pole adres sąsiada zawiera adres IP routera, od którego router wysyłający aktualny komunikat Testuj otrzymał kiedyś wcześniej komunikat Testuj. Komunikat Testuj zawiera tyle pól adres sąsiada, ile jest routerów sąsiadujących, które zidentyfikowały router wysyłający komunikat Testuj. Każdy router odbierający komunikat Testuj tworzy na ich podstawie listę sąsiadów dla każdego interfejsu. Ponieważ komunikat Testuj nie zawiera informacji na temat liczby adresów sąsiada, router może ją określić na podstawie długości datagramu IP przenoszącego komunikat.

Protokół DVMRP oparty jest na stosowaniu wektorów odległości. Informacje o odległościach od źródeł multicastowych przenoszone są przez routery za pomocą komunikatu Raport (Report). Komunikat Raport oprócz standardowego nagłówka zawiera listę źródeł multicastowych w postaci par (maska, lista źródeł). Z kolei lista źródeł jest wykazem identyfikatorów sieci miejscowych źródeł multicastowych, podawanej dla danej maski. Listy źródeł występują w rekordach jako pary (sieć źródłowa, metryka). Mimo, że w danej podsieci miejscowej może znajdować się wiele źródeł multicastowych, pole sieć źródłowa jest zamieszczane w Raporcie tylko raz.

W polu metryka znajduje się informacja o liczbie routerów dzielących dany router od źródła. W protokole DVMRP ogranicza się tę liczbę do przedziału od 1 do 31. Przy czym w specyfikacji DVMRP przyjęto, że wartość 32 oznacza, tzw. odległość nieskończoną od źródła (Infinity metric).

W drzewie dystrybucji multicastowej budowanej przy pomocy protokołu DVMRPv3 routery nie biorące udziału w transmisji od źródła do członków grupy odłączają się od transmisji multicastowej, wysyłając komunikat Odłącz (Prune). Komunikat taki odłącza dany router i tym samym odcina gałąź od drzewa dystrybucji multicastowej. Komunikat ten oprócz standardowego nagłówka protokołu DVMRPv3 zawiera pola: adres źródła, adres grupy, czas życia odłączenia oraz maska. Za pomocą tych pól komunikaty Odłącz w pełni identyfikują danego nadawcę (adres źródła, maska i adres grupy).

W momencie wysłania komunikatu Odłącz router nie będzie już otrzymywał datagramów nadawanych multicastowo. Dlatego komunikat ten wysyła dopiero w przypadku, kiedy w swojej podsieci nie zawiera członków grup i dodatkowo nie jest routerem tranzytowym, tzn. pośredniczącym w transmisji multicast. Odłączone routery nie otrzymują datagramów multicastowych, ale ciągle utrzymują informację niezbędną do przyłączenia się do grupy w dowolnym czasie. Aby umożliwić odtworzenie stanu po restarcie routera spowodowane, np. awarią, działanie komunikatu Odłącz zostało ograniczone czasowo przez pole czas życia odłączenia. Po upływie tego czasu datagramy nadawane multicastowo znowu zaczną docierać do routera, który wcześniej wysłał komunikat Odłącz. Dlatego prawidłowo działający router powinien ponawiać komunikaty Odłącz przed upływem czasu życia odłączenia.

Komunikaty Dołącz (Graft) są nadawane, kiedy w miejscowej podsieci routera pojawi się pierwszy odbiornik, który chce otrzymywać dane wysyłane na dany adres grupy multicast. Router wysyła taki komunikat w kierunku źródła multicastowego.

Aby zapewnić niezawodność sygnalizacji, komunikaty Dołącz muszą zostać potwierdzone. Potwierdzenie takie uzyskuje się za pomocą komunikatu Potwierdzenie dołączenia (Graft Ack). W momencie kiedy komunikat Dołącz nie zostanie potwierdzony, po ustalonym czasie wysyłany jest on ponownie.

Komunikaty Dołącz i Potwierdzenie dołączenia wyglądają bardzo podobnie, różnią się tylko wartością pola kod. Obydwa komunikaty zawierają standardowy nagłówek DVMRPv3 oraz pola: adres źródła, adres grupy i maska. Dzięki polu adres źródła, w którym zapisany jest adres typu „unicast” nadawcy i polu maska, komunikat Dołącz może sygnalizować dołączenie do wszystkich źródeł multicastowych w obrębie jednej sieci miejscowej nadającej na adres danej grupy multicastowej.

Podstawowe mechanizmy działania protokołu
Budowa lub przebudowa drzewa dystrybucji multicastowej wymaga, aby każdy router znajdujący się w tym drzewie znał swoją pozycję w nim. Aby znać swoją pozycję, router musi mieć kilka informacji: jaka jest odległość od źródła, które routery są routerami sąsiadującymi oraz które są routerami zależnymi od routera, od których on sam jest zależny. Odległość od źródła multicastowego mierzona jest liczbą routerów tranzytowych dzielących dany router od tego źródła. Jest ona metryką trasy i przenoszona jest w komunikatach Raport.

Pierwszy pakiet transmitowany w obrębie pary: źródło – grupa multicast, wysyłany jest zgodnie z algorytmem RPM do każdej podsieci, o ile wartość wskaźnika TTL na to pozwala. Następnie wszystkie routery będące w drzewie liśćmi (Leaf), czyli nie mające w swoich podsieciach żadnych aktywnych członków grupy ani też nie będące routerami tranzytowymi w topologii drzewa, mogą odłączyć się od drzewa dystrybucyjnego. Robią to za pomocą wiadomości odłącz (prune message). Router wysyła komunikat odłącz przez interfejs wejściowy dla danego strumienia (w górę drzewa dystrybucji, czyli przeciwnie do kierunku transmisji).

Ponieważ grupy odbiorców przekazów multicastowych mogą zmieniać się dynamicznie, tzn. w każdym momencie do grupy może dołączyć się nowy host (lub odłączyć się), istnieje potrzeba weryfikacji powstałej struktury. Operację taką realizuje się za pomocą okresowego rozsyłania wiadomości zalewającej, a więc ponownie docierającej do każdej podsieci. Po zakończeniu etapu „zalewania” rozpoczyna się okres optymalizacji drzewa dystrybucji, polegający na odłączeniu zbędnych wierzchołków, tzn. routerów liści (leaf routers).

Kolejnym procesem optymalizacji drzewa jest dołączanie (grafiting) nowych członków grupy. Proces ten umożliwia szybkie uaktualnienie stanu drzewa dystrybucyjnego o nowe hosty zgłaszające chęć odbioru przekazu multicastowego. Każdy z routerów, który wykryje w swojej podsieci nowego członka (tzn. pierwszego w swojej podsieci), wysyła komunikat dołącz do routerów znajdujących się wyżej w kierunku do źródła. Routery nie posiadające żadnych odbiorców grup multicastowych w momencie odebrania komunikatu dołącz wysyłają go wyżej w kierunku do źródła tak, jak routery z nowym członkiem. Od tego momentu biorą udział w transmisji multicast i stają się routerami tranzytowymi. Wszystkie routery, które otrzymały komunikat dołącz, uaktualniają swoje tablice trasowania, przyłączając nową gałąź.

Funkcje routerów DVMRP
Podstawowym zadaniem routerów korzystających z protokołu DVMRP jest budowa i utrzymanie drzewa dystrybucji danych multicastowych poprzez stosowanie optymalnych ścieżek transmisji. Jednym z problemów przy ustalaniu tras jest możliwość powstawania nadmiarowych połączeń. Aby zapobiec takiej sytuacji, protokół DVMRP umożliwia stosowanie w swojej strukturze sieciowej routerów dominujących nazywanych także routerami desygnowanymi (Designated Forwarder) oraz podrzędnych. Na rysunku 3 został pokazany przykład struktury sieciowej, w której zastosowano router dominujący eliminujący nadmiarowe połączenie.

Rysunek 3. Topologia o nadmiernej ilości połączeń (protokół DVMRP)

Na rysunku 3 router C może dostawać pakiety pochodzące z tej samej podsieci za pośrednictwem zarówno routera A, jak i C. Routerem dominującym w tym przykładzie jest ten, którego wskaźnik kosztu przesłania datagramu, w odniesieniu do sieci, z której pochodzą datagramy, jest mniejszy od drugiego routera. Podczas gdy ten drugi router (o większym wskaźniku kosztu) zostanie routerem podrzędnym. Oznacza to, że datagramy transmitowane będą poprzez jeden z routerów, a drugi z nich będzie je odrzucał. W przypadku, kiedy obydwa routery, zarówno A i B, posiadają taki sam wskaźnik kosztu przesłania datagramu, routerem dominującym zostaje ten, który ma niższy (bitowo) adres IP. Sytuacja taka bardzo często ma miejsce, kiedy odbiorca (lub odbiorcy) przekazu multicastowego jest podłączony do miejscowej podsieci, w której występuje kilka routerów.

Gdyby na rysunku 3 routerem dominującym został router A, router B stałby się routerem podrzędnym. Router dominujący może samodzielnie określić obecność routera (dla przykładu z rysunku 3 – jednego, w innych topologiach – więcej) podrzędnego, gdyż w informacji routingowej wysyłanej periodycznie przez sieć LAN określone będzie, że ten router nie przekazuje dalej pakietów od danego źródła. Wynika z tego, że nie znajduje się on na najkrótszej możliwej drodze źródło – odbiorca. Router dominujący przechowuje informacje na temat routerów podrzędnych.

Do routerów podrzędnych nie docierają wiadomości z żądaniem odłączenia, dlatego z punktu widzenia protokołu DVMRP są to dla niego routery nie aktywne. Żądanie odłączenia może dotrzeć tylko do routera dominującego i tylko od routerów znajdujących się o jeden poziom niżej w topologii drzewa. On sam może wysłać taką wiadomość w przypadku, kiedy nie posiada aktywnych członków oraz gdy nie jest routerem tranzytowym przekazującym dalej datagramy multicastowe przez któryś ze swoich interfejsów.

Wszelkie informacje potrzebne do obsługi ruchu multicast oparte na protokole DVMRP znajdują się w specjalnej tablicy routingu danego routera. Przykładowe dane zostały zamieszczone w tabeli 2.

Tabela 2. Przykładowa tablica routingu dla protokołu DVMRP

Poszczególne elementy w tabeli 2 oznaczają:

• podsieć źródłowa – podsieć, w której znajduje się nadawca przekazu multicast,
• maska podsieci – maska skojarzona z podsiecią źródłową,
• brama – poprzedni router w kierunku do źródła,
• wskaźnik kosztu – określa koszt związany z transmisją przez dany port,
• status – aktualna dostępność portu,
• TTL – czas życia (Time to Live) – podaje ile sekund dany wpis jest przechowywany w tabeli routingu,
• port wejściowy – port routera służący do odbioru ruchu przychodzącego,
• porty wyjściowe – porty służące do obsługi ruchu wychodzącego.

W tabeli routingu znajdują się informacje na temat topologii drzewa opinającego o możliwie najkrótszych trasach do źródeł datagramów w obrębie sieci. Ponieważ tabela ta nie zawiera informacji na temat grup multicastowych, ani też nie zawiera otrzymanych komunikatów odłącz, istnieje jeszcze jedna tabela – tabela przekazywania (Forwarding Table). Łączy ona w sobie dane z tabeli routingu i dane o grupach multicast oraz informacje o komunikatach odłącz. Dzięki takiej kombinacji router ma informacje na temat drzewa dystrybucji dla każdej pary: źródło – grupa. Przykładowa tabela przekazywania została pokazana w tabeli 3, natomiast odpowiadający jej przepływ wiadomości na rysunku 4.

Tabela 3. Przykładowa tablica przekazywania dla protokołu DVMRP

Tabela 3. zawiera nowe elementy, które nie były określone wcześniej w tablicy routingu lub mają inne znaczenie:

• grupa multicast – zawiera adres IP klasy D, do którego adresowane są pakiety,
• port wejściowy – jest to port podłączony do połączenia „rodzicielskiego” dla pary: źródło – grupa, przez który napływają dane multicast; dopisek „pr” oznacza wysłanie wiadomości odłącz (prune message) do routera znajdującego się poziom wyżej w topologii drzewa,
• porty wyjściowe – są to porty podłączone do połączeń „dziecięcych”, poprzez które przekazywane są dane multicast; dopisek „p” informuje o otrzymaniu wiadomości odłącz (prune message) od routera znajdującego się o poziom niżej w topologii drzewa.

Rysunek 4. Przepływ wiadomości dla przykładowej tabeli przekazywania (tabela 2)

Cechy charakterystyczne
Główną cechą a zarazem bardzo pożądanym parametrem protokołu DVMRP jest relatywnie proste skonfigurowanie routerów. Następną zaletą jest bardzo małe obciążenie zasobów sprzętowych routerów, przez co tylko niewielka część mocy obliczeniowej tych routerów jest wykorzystywana na potrzeby protokołu DVMRP. Pomimo tego, że te wymagania są dużo mniejsze od stawianych przez inne, bardziej zaawansowane protokoły, protokół DVMRP jest w stanie obsłużyć nawet większe sieci.

Cechą niepożądaną stosowania protokołu DVMRP jest dość duże uszczuplanie zasobów sieciowych. Dzieje się tak, ponieważ protokół ten wykorzystuje do aktualizacji drzew dystrybucyjnych technikę okresowego zalewania (flooding). Jest to bardzo niepraktyczna operacja, przy czym dla wielkich sieci, konieczność ciągłego aktualizowania danych pomiędzy setkami urządzeń zajmuje mu po prostu zbyt wiele czasu, co powoduje, że dane we wcześniej zsynchronizowanych urządzeniach mogą być nieaktualne, zanim proces „odświeżania” dobiegnie końca. Lepszym rozwiązaniem jest tutaj unowocześniony protokół DVMRP – HDVMRP (Hierarchical DVMRP), który charakteryzuje się lepszą skalowalnością.

HDVMRP
HDVMRP (Hierarchical Distance-Vector Multicast Routing Protocol) to protokół, który transmituje datagramy pomiędzy określonymi obszarami sieci. Obszary te to unikatowe regiony odzwierciedlające podział na domeny. Każdy z takich regionów otrzymuje swój unikatowy identyfikator. W obrębie danej domeny może być używany dowolny protokół routingu IP multicast pierwszego poziomu (np. DVMRP, MOSPF, PIM lub CBT). Z kolei w transmisji pomiędzy tymi obszarami (domenami) stosowany jest protokół routingu drugiego poziomu, którym musi być protokół DVMRP. Jest to routing międzydomenowy, więc implementowany w routerach granicznych łączących poszczególne obszary (domeny). Wynika z tego, że każdy z obszarów musi mieć przynajmniej jeden router graniczny. Możliwe jest także wprowadzenie, tzw. „super regionów”, przez co uzyskujemy trzypoziomową hierarchię routingu. Jednak kombinacja taka wymaga skomplikowanej enkapsulacji pakietów, co sprawia, że jest to mało wydajny mechanizm routingu.

Wykorzystanie protokołu HDVMRP jest korzystne w przypadku dużych obszarów sieciowych, w celu podziału ich na mniejsze fragmenty, co znacznie ogranicza ilość informacji routingowej przesyłanej między domenami.

Autor: Jacek Kajdasz, www.multicast.pl