Gdy do routera dociera pakiet unicast, przeszukuje on swoją tablice routingu w celu wyznaczenia najlepszej ścieżki do punktu przeznaczenia. Pakiety unicast przesyłane są pomiędzy źródłem, a odbiorcą po jednej ścieżce. Jest to więc kierowanie pakietów zorientowane na adres odbiorcy. W transmisji rozgłoszeniowej źródło nadaje pakiety do grupy odbiorców, przy czym istnieje zupełna dowolność ich lokalizacji w sieci. W takim przypadku pakiety z pewnością będą przesyłane po różnych ścieżkach.
Dlatego w przypadku w przypadku ruchu multicast, które jest przesyłany „od źródła”, należy przyjąć inne podejście do kierowania pakietów (routing). Router musi określić, przez który interfejs jest w stanie osiągnąć adres źródła (upstream) oraz interfejsy, na które należy wysłać pakiety w kierunku odbiorców (downstream). Mechanizm ten nosi nazwę Reverse Path Forwarding (RPF) i jedną z jego głównych funkcji jest zapobieganie powstawania pętli w ruchu multicast.
Router wspierający transmisję multicast realizuje algorytm RPF Check, czyli procedurę weryfikacji, czy pakiet adresowany do grupy odebrany został na interfejsie, którego router użyłby, aby wysłać dane do jego źródła. W trakcie realizacji procedury RPF Check router odczytuje adres źródłowy pakietu multicast, a następnie poszukuje w swojej tablicy routingu unicast, ścieżki do tego źródła. Jeżeli pakiet multicast został odebrany na interfejsie, którego router użyłby, aby osiągnąć źródło, to może zostać przesłany dalej, w przeciwnym wypadku pakiet jest odrzucany.
Zauważmy, że tablica routingu tworzona jest najczęściej w wyniku działania dynamicznych protokołów IGP i EGP oraz ścieżek statycznych. Rozważmy przypadek przedstawiony na rysunku 1. Pomiędzy systemami autonomicznymi, w celu wymiany informacji o aktywnych ścieżkach, uruchomiony został protokół BGP. Załóżmy, że router brzegowy w systemie AS 400 (router A) wybierze ścieżkę do systemu AS 100 biegnącą przez AS 300, w którym nie jest wspierana transmisja multicast. Wówczas w wyniku działania mechanizmu RPF Check wszystkie pakiety wysyłane ze źródła umieszczonego w AS100, które adresowane są do grupy multicast i trafią do AS 400 z AS 200, zostaną odrzucone.
Przykład przedstawiony na rysunku 1 pokazuje, że topologia sieci z punktu widzenia transmisji multicast może być zupełnie inna niż dla transmisji unicast. Zatem, aby możliwe było skuteczne przesyłanie ruchu rozgłoszeniowego pomiędzy systemami autonomicznymi, konieczne jest dostarczenie routerom informacji o topologii sieci multicast. Innymi słowy, należy stworzyć dodatkową tablicę routingu, która umożliwi poprawne wykonywanie procedury RPF Check i wskazać, że właśnie tej tablicy router ma używać w trakcie działania tego mechanizmu. Funkcje te są realizowane przez rozszerzenie protokołu BGP, jakim jest Multiprotocol Border Gateway Protocol, czyli MBGP (Multicast BGP). Gdy pomiędzy dwoma routerami uruchomiony jest protokół MBGP, wymieniają one dwa rodzaje ścieżek:
- ścieżki unicast (unicast prefixes/routes),
- ścieżki multicast RPF.
Rys 1. Różne topologie sieci dla transmisji unicast i multicast
Ścieżki multicast RPF są przekazywane w polu NLRI (Network Layer Reachability Information). MBGP nie jest oddzielnym protokołem, lecz stanowi rozszerzenie protokołu BGP. Rozszerzenie to polega na zdefiniowaniu dodatkowych atrybutów ścieżek rozgłaszanych przez BGP. Atrybuty te przekazywane są w wiadomościach BGP Update, które mogą zawierać informacje o wielu ścieżkach, posiadających te same atrybuty. W MBGP zdefiniowano dwa dodatkowe (w stosunku do BGP) atrybuty:
- MP_REACH_NLRI,
- MP_UNREACH_NLRI.
MP_REACH_NLRI jest używany dla prefiksów protokołów innych niż IPv4 lub dla prefiksów IPv4, które mają być umieszczone w innej tablicy (forwarding table), niż unicast forwarding table. Atrybut MP_UNREACH_NLRI używany jest zamiast atrybutu Withdrawn Routes protokołu BGP i oznacza, że dany prefiks jest nieosiągalny.
Należy w tym miejscu podkreślić, że zastosowanie protokołu MBGP nie ogranicza się jedynie do przenoszenia informacji potrzebnych w transmisji rozgłoszeniowej w sieciach IPv4, ale jest również wykorzystywany do wymiany prefiksów IPv6. Prefiksy należące do różnych protokołów rozróżniane są na podstawie przypisanych im numerów, zdefiniowanych w dokumencie RFC 3232. Numery te określane są jako AFI (Address Family Identifier). Dla protokołu IPv4 AFI=1 natomiast dla protokołu IPv6 AFI=2. MBGP używa dodatkowych atrybutów, pozwalających na dokładne określenie typu NLRI, zwanych SAFI (Subsequent Address Family Identifier). Wyróżnia się następujące identyfikatory SAFI:
- unicast (1),
- multicast (2),
- unicast i multicast (3).
Identyfikator trzeci został wprowadzony w celu minimalizacji ilości przesyłanych informacji sterujących. Jest on stosowany w przypadku, gdy prefiks posiada te same atrybuty dla transmisji unicast i multicast. Tak więc AFI określa protokół, którego dotyczy dany prefiks, natomiast SAFI określa jego typ.
Głównym zadaniem protokołu MBGP w sieciach wspierających transmisję multicast jest zgromadzenie informacji o topologiach sieci unicast i multicast. Informacje te wykorzystywane są przez opisany wcześniej mechanizm RPF Check, który jest jednym z fundamentalnych sposobów określających drogi, po których przesyłane będą pakiety IP multicast.
Protokoły routingu rozgałęźnego można podzielić na dwa typy:
- sparse,
- dense.
W protokołach typu dense założono gęsty rozkład w sieci odbiorców pakietów multicast. Przyjęto, że w każdej podsieci istnieje co najmniej jeden odbiorca zainteresowany transmisją kierowaną do grupy multicast. Rezultatem takiego założenia jest zastosowanie modelu typu flood-and-prune do przekazywania pakietów. W tym modelu pakiety ze źródła przesyłane są na wszystkie interfejsy routera za wyjątkiem tego, z którego otrzymano pakiet do momentu otrzymania wiadomości z żądaniem zaprzestania transmisji od sąsiada podłączonego na danym interfejsie. Wiadomość z żądaniem zaprzestania transmisji pakietów multicast na danym interfejsie (Prune) wysyłana jest przez sąsiedni router w przypadku, gdy nie ma on bezpośrednio podłączonych odbiorców lub otrzymał pakiet na niewłaściwym interfejsie (czyli wynik procedury RPF Check był niepomyślny).
Zaletą tego typu protokołów jest proste tworzenie drzew dystrybucyjnych, których punktem początkowym jest aktywne źródło, natomiast wadą jest słaba skalowalność mechanizmu polegającego na wstępnym wysyłaniu pakietów na wszystkie interfejsy (flood). Do protokołów typu dense zaliczają się DVMPR oraz PIM-DM (Protocol Independent Multicast – Dense Mode).
W protokołach typu sparse założono rzadkie rozłożenie odbiorców w sieci. Przyjęto, że na danym interfejsie nie ma odbiorców zainteresowanych pakietami kierowanymi do grupy do momentu, kiedy nie nadejdzie żądanie dołączenie do grupy . Protokoły te wykorzystują więc model „explicit join”, w którym dane przekazywane są na wyraźne żądanie. Takie podejście wiąże się jednak z koniecznością rejestrowania źródeł nadających do grupy, ponieważ bez tej wiedzy nie byłoby możliwe stworzenie stanów przekazywania pakietów, a tym samym zbudowania drzewa dystrybucyjnego.
Autor: Tomasz Szewczyk, www.multicast.pl
