MIĘDZYDOMENOWE PROTKOŁY ROUTINGU ROZGAŁĘŹNEGO Wraz z rozwojem Internetu prowadzone s

(1)

Tomasz Bartczak,

Maciej Piechowiak,

Tomasz Szewczyk,

Piotr Zwierzykowski,

Politechnika Poznańska

Wydział Elektroniki i Telekomunikacji

e-mail:

pzwierz@et.put.poznan.pl

MIĘDZYDOMENOWE PROTKOŁY ROUTINGU ROZGAŁĘŹNEGO

Wraz z rozwojem Internetu prowadzone są prace mające na celu zoptymalizowanie sposobu przesyłania danych w tej sieci. Wybór drogi, po której będą przesyłane pakiety uzależniony jest od współdziałania zestawu protokołów trasowania (ang. routing). Ze względu na specyfikę transmisji realizowanej w sieci, w celu osiągnięcia najlepszych rezultatów, należy zastosować różne metody wyboru ścieżek dla różnych jej typów. Dla transmisji typu punkt-punkt wybór ścieżek realizowany jest przez protokoły typu unicast. Natomiast dla transmisji rozgłoszeniowej wybór ten jest realizowany przez protokoły typu multicast. Celem tego artykułu jest przedstawienie obecnie stosowanych protokołów routingu rozgałęźnego w sieciach IP. Zaprezentowano w niej wybrane sposoby realizacji transmisji rozsiewczej w sieciach operatorskich.

1. Wprowadzenie do transmisji rozsiewczej

W pakietowych sieciach teleinformatycznych wykorzystujących protokół IP można wyróżnić cztery sposoby transmisji, ze względu na sposób dostarczania danych do odbiorcy:

• unicast, • broadcast, • anycast, • multicast.

Tradycyjnie w sieci Internet wykorzystywana była transmisja unicast, w której dane przesyłane były pomiędzy dwoma urządzeniami w sieci. W transmisji unicast pakiet IP zawiera źródłowy adres nadawcy oraz docelowy adres odbiorcy. Na podstawie tych informacji pakiet kierowany jest przez routery od nadawcy do odbiorcy1. Tego typu transmisja dobrze sprawdza się w przypadku, gdy konieczna jest wymiana danych tylko pomiędzy dwoma urządzeniami w sieci.

Transmisja typu „broadcast” polega na dostarczeniu pakietu do wszystkich użytkowników w sieci. Współcześnie, ze względu na rozmiar i dynamiczny rozwój sieci Internet ogranicza się ona tylko i wyłącznie do pojedynczej podsieci. Tego typu transmisję praktycznie stosuje się do przesyłania danych sterujących, które muszą zostać odebrane przez wszystkie urządzenia w danej podsieci (np. arp-query).

Transmisja typu „anycast” stosowana jest w sieciach wykorzystujących protokół IPv6. Jej istota polega na istnieniu grupy urządzeń świadczących te same usługi, identyfikowanych przez pojedynczy adres IPv6 [16]. Żądanie wysłane na ten adres zostanie dostarczone do najbliższego urządzenia należącego do grupy anycast. Tego typu transmisja nie jest jeszcze szeroko stosowana w sieciach i znajduje się obecnie w stadium badań [17]. Przykładem zastosowania transmisji anycast może być procedura poszukiwania agenta (ang. home agent) przez mobilną stację IPv6.

1

W nowoczesnych routerach implementowana jest technologia FBF (ang. Filter Based Forwarding) pozwalająca na określanie bramki (ang. gateway) do jakiej ma zostać przekazany pakiet IP, również na podstawie innych informacji zawartych w nagłówku pakietu. FBF pozwala na przesyłanie pakietów inną drogą niż wynika to z działania protokołu routingu.

Transmisja rozgłoszeniowa (multicast) polega na dostarczeniu pakietów do grupy odbiorców. Wyróżnia się dwa przypadki tego typu transmisji:

• jeden do wielu (ang. one-to-many), • wielu do wielu (ang. many-to-many).

Gdy pakiety mają zostać wysłane z pojedynczego źródła i dostarczone do grupy odbiorców, mówimy o transmisji jeden do wielu (one-to-many). W tym przypadku najczęściej nie ma potrzeby odpowiedzi na dane otrzymane ze źródła, a zatem dane przesyłane są tylko w jednym kierunku. Przykładem tego typu transmisji, może być przesyłanie odpowiednio zakodowanych sygnałów audiowizualnych z rozgłośni radiowych lub telewizyjnych za pośrednictwem sieci IP. (rysunek 1).

Źródło

Odbiorca

Odbiorca Odbiorca

Rysunek 1. Transmisja rozgłoszeniowa one-to-many W przypadku, gdy wymagana jest wymiana pakietów pomiędzy wszystkimi członkami grupy, mówimy o transmisji wielu do wielu (many-to-many). Potrzeba taka może się pojawić wtedy, gdy przy pomocy transmisji multicast musi zostać zrealizowana usługa telekonferencji (lub wideokonferencji). Na rysunku 2 przedstawiono przykład komunikacji many-to-many, w której dwa hosty nadają do grupy muticast, natomiast dane odbierane są przez wszystkich członków grupy.

Nadawca/Odbiorca

Nadawca/Odbiorca Odbiorca

Rysunek 2. Transmisja rozgłoszeniowa many-to-many Istotną cechą transmisji multicast jest powielanie danych tylko w takich punktach sieci, w których jest to konieczne. O tym jaką trasą przesyłane są pakiety kierowane do grupy multicast oraz w którym miejscu następuje ich replikacja decydują odpowiednie protokoły routingu rozgałęźnego.

Grupa odbiorców identyfikowana jest przez specjalny adres IP. Adres ten należy do klasy D, czyli musi zawierać się

2006

Poznańskie Warsztaty Telekomunikacyjne Poznań 7 - 8 grudnia 2006

(2)

w przedziale od 224.0.0.0 do 239.255.255.2552. Pakiet kierowany do grupy multicast musi zawierać adres z tego przedziału umieszczony w polu destination address nagłówka pakietu IP [19]. Urządzenie odbiorcy zgłasza żądanie dołączenia do grupy multicast za pomocą protokołu IGMP (ang. Internet Group Management Protocol) [5][12][13].

Ze względu na bardzo dobre wykorzystanie dostępnych zasobów sieciowych transmisja rozgłoszeniowa szczególnie często wykorzystywana jest do przesyłania treści multimedialnych, które wymagają dostarczenia danych do dużej grupy użytkowników oraz coraz większego pasma. Transmisja rozsiewcza pozwala na wysłane jednego strumienia o wyższej jakości przez pojedyncze łącze zamiast tysięcy strumieni o gorszej jakości – jak ma to miejsce w przypadku transmisji unicast. Stąd też bierze się wzrost zainteresowania technologiami multicast oraz coraz powszechniejsze wdrażanie ich w sieciach operatorów ISP (ang. Internet Service Providers).

Sieć Internet składa się z wielu połączonych ze sobą heterogenicznych sieci, które zarządzane i utrzymywane są przez oddzielne organizacje (np. firmy, korporacje, jednostki naukowo-badawcze). Część sieci będąca w domenie administracyjnej danej jednostki nazywana jest systemem autonomicznym. Każdy z systemów autonomicznych może stosować różne technologie sieciowe, protokoły routingu oraz sposoby (polityki) kierowania ruchem. Do wymiany informacji o podsieciach IP w obrębie systemu autonomicznego stosuje się protokoły IGP (ang. Interior Gateway Protocol). W celu umożliwienia wymiany ruchu IP pomiędzy różnymi organizacjami – a ściślej – pomiędzy administrowanymi przez nie systemami autonomicznymi, konieczne jest stosowanie protokołów EGP (ang. Exterior Gateway Protocol) na stykach pomiędzy nimi. Takie rozwiązanie daje możliwość tworzenia elastycznych sieci i efektywnej wymiany ruchu pomiędzy operatorami. Zatem, zbudowanie sieci pozwalającej na wydajną obsługę ruchu rozgłoszeniowego, wymaga zastosowania protokołów zapewniających efektywną transmisję zarówno wewnątrz, jak i na zewnątrz systemu autonomicznego. Prosty model najczęściej stosowany w sieciach operatorów ISP przedstawiony został na rysunku 3.

AS100 AS200 RP RP MSDP MBGP Domena PIM Domena PIM

Rysunek 3. Model połączeń międzyoperatorskich dla transmisji rozsiewczej

Zazwyczaj protokołem routingu rozgałęźnego wewnątrz systemu autonomicznego jest PIM (Protocol Independent Multicast [7]). Nazwa protokołu związana jest ze sposobem jego działania - PIM nie korzysta z protokołów routingu unicast do określania sposobu dystrybucji pakietów IP multicast. Protokół PIM pracuje najczęściej w trybie Sparse Mode [6], wykorzystując zdefiniowane w sieci punkty „spotkań” aktywnych źródeł i odbiorców. Punkty te nazywane są Rendezvous Point (RP). W systemie autonomicznym skonfigurowane jest co najmniej jedno urządzenie pełniące

2

W przypadku wykorzystania protokołu IPv6 adres ten musi należeć do przedziału FF00::/8. W odróżnieniu od adresów IPv4 adres grupy multicast zawiera dodatkowo flagi określające typ adresu (stały lub tymczasowy) oraz zasięg grupy.(ang. scope)[18]. Zasięg grupy umieszczony w adresie IPv6 pozwala w prosty sposób kontrolować i ograniczać na jaką odległość wysyłane będą dane kierowane do grupy. W przypadku transmisji IPv4 w celu ograniczenia zasięgu grupy konieczne było ustawienie odpowiedniej wartości w polu TTL.

funkcję RP. Główną rolą RP jest rejestracja aktywnych źródeł, nadających do grup multicast oraz interfejsów, na które należy wysłać pakiety przeznaczone do danej grupy.

W celu zapewnienia wymiany informacji, dotyczących aktywnych źródeł, pomiędzy systemami autonomicznymi, stosuje się protokół MSDP (Multicast Source Discovery Protocol [8]). Protokół ten za pośrednictwem wiadomości SA (Source Active) informuje RP w sąsiedniej domenie o aktywnych źródłach nadających do grup multicast.

W celu umożliwienia wymiany pakietów IP multicast pomiędzy systemami autonomicznymi, konieczne jest również przesłanie informacji potrzebnych dla mechanizmu RPF (Reverse Path Forwarding)[4] zabezpieczającego sieci wspierające technologię IP multicast przed powstawaniem pętli. Informacje te przesyłane są za pomocą rozszerzenia protokołu BGP jakim jest MBGP (Multiprotocol Border Gateway Protocol [9]).

Przedstawiony zbiór protokołów konieczny jest w przypadku gdy odbiorca zgłasza żądanie dołączenia do grupy multicast, nie znając adresu źródła. Stąd też bierze się potrzeba utrzymywania przez RP informacji o aktywnych źródłach oraz wymieniania jej z sąsiednimi RP w innych systemach autonomicznych. Model, w którym odbiorca wysyła żądanie dołączenia do grupy nie znając adresu źródła opisany został w RFC 1112 i nosi nazwę ASM (Any-Source Multicast). W modelu tym sieć jest odpowiedzialna za przekazanie i utrzymywanie informacji o aktywnych źródłach. Biorąc pod uwagę dynamiczny rozwój sieci Internet nie trudno zgadnąć, że nałożenie takich wymagań na sieć prowadzi do dużej komplikacji działania protokołów oraz do wzrostu informacji sygnalizacyjnych jakie muszą zostać przesłane. Należy zauważyć, że dla każdego źródła zaczynającego wysyłać pakiety do grupy multicast w całej sieci Internet wspierającej tę technologię zostanie rozpropagowana za pomocą protokołu MSDP wiadomość SA. Na rysunku 4a przedstawiono przykładowy rozkład liczby aktywnych źródeł w ciągu doby, zmierzony na głównym routerze sieci miejskiej (POZMAN) w Poznaniu. Obserwacje prowadzone były w lipcu 2006 r. Pomiary wykonano wykorzystując program MRTG (Multi Router Traffic Grapher), który przy pomocy protokołu SNMP generował co pięć minut zapytanie o liczbę aktywnych źródeł. Rysunek 4b przedstawia rozkład liczby aktywnych źródeł w ciągu tygodnia, natomiast rysunek 4c w ciągu miesiąca. Jak łatwo zauważyć, średnia liczba aktywnych źródeł w czasie obserwacji była stała. Niewielka liczba tych źródeł wskazuje na to, że transmisja rozgłoszeniowa nie jest stosowana powszechnie a jej zastosowanie w główniej mierze związane jest z pracami naukowo-badawczymi3.

a) b)

c)

Rysunek 4. Rozkład liczby aktywnych źródeł w zależności od czasu:

a) dobowy, b) tygodniowy, c) miesięczny

Obserwując rozwój sieci Internet zaczęto zastanawiać się nad tym w jakich wypadkach odbiorca jest w stanie zdobyć adres źródła nadającego do grupy, do której chce się dołączyć. Jak wcześniej wspomniano, transmisję rozsiewczą w sieciach IP,

3

Większość aktywnych źródeł jakie zarejestrowane zostały przy pomocy protokołu MSDP zlokalizowana była w sieciach naukowo-badawczych (ang. National Research Networks) oraz sieciach uczelni wyższych.

(3)

stosuje się do dystrybucji danych z rozgłośni radiowych lub telewizyjnych. W takich przypadkach w prosty sposób możliwe jest dostarczenie odbiorcy adresu (lub w szczególnych przypadkach adresów) źródła nadającego do grupy. Model, w którym odbiorca oprócz grupy do której chce się dołączyć sygnalizuje również źródło, z którego chce otrzymywać dane nosi nazwę SSM (Source Specific Multicast [10][11]). Jak łatwo zauważyć, w modelu tym wyeliminowana została potrzeba utrzymywania w sieci punktów RP oraz wymieniania informacji SA za pomocą protokołu MSDP. W celu zasygnalizowania żądania dołączenia do grupy i wskazania źródła pakietów, odbiorca musi zastosować protokół IGMPv3 [12].

2. Sygnalizacja

w

łączu abonenckim

– protokół IGMP

Jak już wspomniano, efektywność transmisji rozgłoszeniowej wynika z dostarczania danych tylko do grupy odbiorców, którzy wcześniej zgłosili żądanie dołączenia do danej grupy. W celu zapewnienia możliwości wysłania takiego żądania, zdefiniowano specjalny protokół, działający na łączu pomiędzy urządzeniem odbiorczym a najbliższym routerem (tzw. first hop router). Protokół ten nosi nazwę IGMP (Internet Group Management Protocol) i we współczesnych sieciach IP występuje w trzech odmianach: IGMPv1 [5], IGMPv2 [13] oraz IGMPv3 [12]. Głównym zadaniem IGMP jest przesłanie do routera, do którego bezpośrednio podłączony jest odbiorca informacji z żądaniem dołączenia do grupy. Zasadnicze różnice pomiędzy poszczególnymi wersjami protokołu IGMP polegają głównie na usprawnieniu komunikacji pomiędzy hostem i routerem oraz zwiększeniu funkcjonalności w kolejnych wersjach przy jednoczesnym zachowaniu kompatybilności wstecz (ang. backward compatibility). Wiadomości protokołu IGMP wysyłane są jako pakiety IP z polem TTL (time to live) ustawionym na 1.

Protokół IGMPv1 używa dwóch typów wiadomości: • Host Membership Query (HMQ), • Host Membership Report (HMR).

Urządzenie odbiorcze, w celu wysłania żądania dołączenia do grupy multicast wysyła wiadomość HMR podając adres IP klasy D identyfikujący tą grupę. Router, po odebraniu wiadomości HMR, okresowo (co 125 sekund) wysyła pytania Host Membership Query. Wiadomości te służą potwierdzeniu, czy do danego interfejsu dołączeni są nadal odbiorcy, zainteresowani odbieraniem informacji przeznaczonej dla grupy multicast. Członek grupy, który odbierze takie pytanie odpowiada wiadomością HMR. Wiadomość HMQ nie zawiera adresu grupy multicast, dlatego odbiorca wysyłając odpowiedź HMR ponownie ustawia w niej adres grupy, do której należy.

Główną wadą protokołu IGMPv1 jest brak sygnalizacji odłączenia odbiorcy od grupy. Router zaprzestaje wysyłania pakietów kierowanych do danej grupy w kierunku odbiorcy, dopiero po upłynięciu czasu GMI (Group Membership Interval), który domyślnie wynosi 260 sekund. Efektem tego jest niepotrzebne zajmowanie pasma na interfejsie, gdy nie ma na nim dołączonych odbiorców. Problem ten rozwiązano w kolejnej wersji protokołu IGMPv2. Protokół IGMPv2 (RFC 2236) używa czterech typów wiadomości [13]:

• Membership Query (MQ),

• Version 2 Membership Report (MR), • Leave Group (LG),

• Version 1 Membership Report (w celu realizacji kompatybilności z protokołem IGMPv1).

Istotną zmianą wprowadzoną w tej wersji protokołu jest dodanie wiadomości Leave Group, wysyłanej przez odbiorcę, który zamierza odłączyć się od grupy. Po otrzymaniu tej wiadomości, router wysyła pytanie (Membership Query), czy

do danego interfejsu dołączeni są jeszcze inni odbiorcy zainteresowani odbieraniem danych przeznaczonych dla tej grupy. Jeżeli w odpowiedzi nie otrzyma wiadomości Membership Report, to przestaje wysyłać dane do grupy multicast na danym interfejsie.

Do protokołu IGMPv3 dodano możliwość sygnalizowania przez odbiorcę nie tylko grupy, do której chce się dołączyć, ale również określenia źródła, z którego dane wysyłane są do tej grupy4. Protokół IGMPv3 posiada ponadto możliwość określenia źródeł, z których odbiorca nie powinien otrzymywać danych. Specyfikacja protokołu definiuje trzy typy zapytań wysyłanych w wiadomościach Query[12]:

• General Query - wysyłana przez router, w celu określenia pełnego stanu odbiorców grup multicast na danym interfejsie,

• Group-Specific Query - wysyłana przez router, w celu określenia stanu odbiorców dla pojedynczej grupy multicast,

• Group-and-Source-Specific Query - wysyłana przez router, w celu określenia stanu odbiorców dla pojedynczej grupy multicast, do których pakiety wysyłane są z określonych źródeł (lub jednego źródła).

Wiadomości General Query wysyłane są na adres 224.0.0.1, natomiast pozostałe na adres grupy, której dotyczą. Wiadomości Membership Query Message (MQM) wysyłane są w celu sprawdzenia czy na dołączonych do routera interfejsach są odbiorcy transmisji rozsiewczej przeznaczonej dla danej grupy. Wiadomości Membership Report wysyłane są w celu poinformowania routera o grupach i źródłach, od jakich odbierana mają być pakiety. Wiadomości MR wysyłane są na adres 224.0.0.22, czyli do wszystkich urządzeń wspierających protokół IGMPv3.

3. Sygnalizacja

międzywęzłowa

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żce5. 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 też, należy przyjąć inne podejście do ich kierowania (ang. routing). Ruch multicast przesyłany jest „od źródła”. Router musi określić przez jaki interfejs jest w stanie osiągnąć adres źródła (ang. upstream) oraz interfejsy, na które należy wysłać pakiety w kierunku odbiorców (ang. 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ę rozsiewczą realizuje algorytm RFP Check, czyli procedurę weryfikację, 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

4

Jest to funkcjonalność wymagana w modelu SSM (Source Specific Multicast)

5

Pakiety unicast mogą być przesyłane różnymi ścieżkami, gdy stosuje się tzw. load balancing. Technologii tej nie stosuje się jednak per pakiet ze względu na możliwość powstanie reorderingu. Najczęściej load balancing realizowany jest per adres lub per strumień. W takim przypadku pomiędzy źródłem a odbiorcą pakiety należące do różnych strumieni mogą być przesyłane różnym ścieżkami.

(4)

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 8. 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 rozsiewcza. 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 8 pokazuje, że topologia sieci z punktu widzenia transmisji rozsiewczej, 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, konieczna 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 tej właśnie 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 [9]. 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. AS300 unicast AS100 unicast/ multicast AS200 unicast / multicast AS400 unicast / multicast Źródło Odbiorca A unicast multiicast

Rysunek 5. 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 (ang. 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 dla wymiany prefiksów IPv6. Prefiksy należące do różnych protokołów rozróżniane są na podstawie przypisanych im numerom, zdefiniowanym w RFC 3232 [20]. 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ę rozsiewczą, 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 modelu tym, pakiety ze źródła przesyłane są na wszystkie interfejsy routera, za wyjątkiem tego, z którego otrzymano pakiet6, 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 (ang. 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 grupy7. 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ło

6

Należy oczywiście pamiętać, że warunkiem przesłania pakietu jest pozytywne zakończenie procedury RPF check

7 _{Żądania tego nie należy jednak mylić z sygnalizacją odbiorcy}

(5)

by możliwe stworzenie stanów przekazywania pakietów a tym samym zbudowania drzewa dystrybucyjnego.

3.1. Protokół PIM

Protokół PIM-DM należy to protokołów typu dense. Protokół ten korzysta z tablicy kierowania ruchem (ang. routing table) zbudowanej przez inne protokoły (ang. underlying protocol) dla celów realizacji procedury RPF check. Niezależność protokołu PIM (w tym również PIM-DM) polega na tym, że nie wymaga on określonego zestawu protokołów IGP oraz EGP aby wykonać procedurę RPF check i może korzystać z tablic zbudowanych przy pomocy protokołów OSPF, IS-IS, M-ISIS lub BGP. Router tworzy stany przekazywania pakietów, na podstawie rozgłaszania ruchu multicast na wszystkie interfejsy (w początkowej fazie), zatem od początku transmisji znane jest źródło oraz grupa do której nadaje. Ze względu na charakter rozmieszczenia odbiorców PIM-DM stosowany jest raczej w sieciach korporacyjnych przedsiębiorstw niż w sieciach operatorów ISP.

Protokół PIM-SM (Protocol Independent Multicast – Sparse Mode) wykorzystuje punkt RP, w którym rejestrowane są aktywne źródła oraz grupy posiadające odbiorców.

Możliwy jest dynamiczny lub statyczny wybór RP. Najprostszą metodą jest statyczne skonfigurowanie na wszystkich routerach domeny jednego RP dla wszystkich grup. Jakkolwiek metoda ta nie zapewnia redundancji w przypadku awarii, jest stosowana w sieciach z mniejszą ilością routerów, ze względu na prostotę analizy ewentualnych błędów w konfiguracji sieci. Metoda ta nie jest jednak zalecana w sieciach z dużą liczbą routerów ponieważ wymaga rekonfiguracji wszystkich urządzeń w wypadku zmiany RP.

Dynamiczny wybór RP jest możliwy przy zastosowaniu jednego z dwóch mechanizmów:

• Auto-RP,

• PIM Bootstrap router (BSR).

Pierwsza metoda została opracowana przez firmę Cisco Systems i jest implementowana na urządzeniach tego producenta. Drugą metodą jest BSR, która opisana została w standardzie określającym działanie protokołu PIM [6] oraz jest rozwijana w ramach grupy roboczej IETF [14]. Do poprawnego działania mechanizmu BSR wymagane jest, aby wszystkie routery w domenie używały protokołu PIM w wersji 2 oraz co najmniej jeden router był skonfigurowany jako candidate BSR.

Zasadniczymi operacjami, wykonywanymi przez PIM są: • zbudowanie drzewa RPT, wzdłuż którego

dostarczane będą pakiety z RP do odbiorców,

• zbudowanie drzewa dostarczającego pakiety od źródła do RP,

• zbudowanie drzewa SPT, dostarczającego pakiety bezpośrednio ze źródła do odbiorców.

W momencie, gdy router odbiera pierwszy pakiet multicast, nadany ze źródła, które jest podłączone bezpośrednio do jednego z jego interfejsów, dokonuje enkapsulacji tego pakietu we wiadomość Register i wysyła jako pakiet unicast bezpośrednio do RP dla danej grupy. Wiadomość ta zwiera adres źródła oraz grupy, do której przesłane mają zostać pakiety. Jeżeli w RP istnieje drzewo RPT (shared tree) to zgodnie ze specyfikacją, router może dokonać dekapsulacji pakietu umieszczonego w wiadomości register i przesłać go w dół drzewa RPT. Jednocześnie RP wysyła wiadomość Join w kierunku źródła, z którego nadeszła wiadomość Register, tak aby pakiety ze źródła przekazywane były do niego wzdłuż drzewa SPT, bez konieczności ich enkapsulacji po stronie routera, do którego podłączone jest źródło oraz dekapsulacji po stronie RP. Gdy RP zacznie

odbierać pakiety multicast wzdłuż drzewa SPT, wysyła do routera podłączonego bezpośrednio do źródła wiadomość Register-Stop. Po otrzymaniu tego pakietu router wysyła okresowo w kierunku RP wiadomości Null-Register, w celu zasygnalizowania obecności źródła nadającego do grupy.

Gdy router, do którego podłączony jest odbiorca, otrzyma od niego wiadomość IGMP z żądaniem dołączenia do grupy, to rozpoczyna proces tworzenia gałęzi drzewa RPT (shared tree). Router ten nazywany jest routerem DR (Designated Router) odbiorcy. W tym celu wysyłana jest wiadomość Join w kierunku RP a ponieważ jest to proces budowy drzewa typu shared tree na routerach tworzone będą stany (*,G). Kolejne routery, które odbierają wiadomość Join, wysyłają taką samą wiadomość w kierunku RP, tworząc jednocześnie w swojej tablicy kierowania pakietami stan (*,G). W momencie, gdy wiadomość Join dotrze do RP, również tworzony jest na nim stan (*,G), oznaczając tym samym, że w domenie PIM jest co najmniej jeden odbiorca zainteresowany odbiorem pakietów dla grupy G.

W tej sytuacji, gdy w RP zarejestrowane jest aktywne źródło, pakiety do odbiorców dostarczane są do odbiorców za pośrednictwem RP. Nie jest to oczywiście optymalne rozwiązanie z punktu widzenia wykorzystania zasobów sieciowych oraz opóźnienia w dostarczaniu pakietów. Dlatego też, po zakończeniu fazy rejestrowania źródła i odbiorców w RP, routery domeny PIM rozpoczynają proces tworzenia drzewa SPT.

W momencie, gdy do routera DR odbiorcy dotrze pierwszy pakiet z danego źródła, wysyła on w jego kierunku wiadomość Join, wskazując źródło i grupę której dotyczy (S,G). Wiadomość ta przekazywana jest przez kolejne routery na drodze od DR do routera, do którego podłączone jest źródło oraz tworzone są na nich stany (S,G). Jednocześnie, gdy do routera DR zaczną docierać pakiety multicast kierowane do niego wzdłuż nowo utworzonego drzewa SPT, wysyła w kierunku RP wiadomość Prune (S,G,RPT) z żądaniem zaprzestania przekazywania do niego pakietów ze źródła nadającego do grupy. Jest to konieczne, gdyż po stworzeniu drzewa SPT, router DR otrzymywałby duplikaty pakietów, przesyłanych do niego dwiema drogami jednocześnie. Jeżeli w tym samym czasie nie ma innych odbiorców w grupie, wówczas RP po odebraniu wiadomości Prune od strony routera DR, wysyła w stronę routera do którego podłączone jest źródło, wiadomość Prune (S,G).

Jak łatwo zauważyć, protokół PIM tworzy drzewa dystrybucyjne tylko wtedy gdy są one potrzebne, czyli w momencie gdy pojawiają się odbiorcy i źródła. Dodatkowo drzewa te, konstruowane są od odbiorcy8 do źródła – czyli nie jako „od końca”.

3.2. Protokół MSDP

Protokół MSDP został opracowany jako tymczasowe rozwiązanie stosowane w modelu ASM, w celu umożliwienia wymiany informacji pomiędzy punktami RP zlokalizowanymi w różnych domenach administracyjnych9 (systemach AS). Cechuje go słaba skalowalność, związana z generowaniem dużej ilości informacji sterujących, wraz ze wzrostem liczby aktywnych źródeł. W uproszczeniu, działanie MSDP polega na

8

Odbiorcą może być również RP, który będzie następnie przekazywać pakiety w dół drzewa RPT

9_{Wymiana informacji pomiędzy RP za pomocą protokołu MSDP nie}

jest jedyną możliwością jego wykorzystania. Protokół ten może być również stosowany w przypadku systemów autonomicznych, które zajmują się jedynie tranzytem ruchu IP multicast. W takim przypadku w systemach tych może być uruchomiony protokół MSDP bez konieczności utrzymania RP, lecz nie mogą w nich być zlokalizowane

(6)

tym, że w momencie, gdy RP otrzyma wiadomość PIM Register, oznaczającą pojawienie się aktywnego źródła, router, za pomocą wiadomości MSDP Source Active, wysyła do swoich sąsiadów informacje zawierającą adres tego źródła oraz grupy do której ono nadaje. Następnie wiadomość ta jest rozpropagowana do wszystkich routerów, używających pomiędzy sobą protokołu MSDP. W momencie, gdy RP w danej domenie otrzyma informację o adresie aktywnego źródła, które jest zlokalizowane w innej domenie, po stwierdzeniu, że zarejestrował odbiorców w tej grupie, wysyła wiadomość PIM Join w kierunku tego źródła.

Ze względu na istnienie różnych dróg połączeń pomiędzy tymi routerami wiadomości SA mogły by być duplikowane i krążyć w pętli pomiędzy wieloma routerami. W celu uniknięcia tego zjawiska, MSDP używa mechanizmu zapobiegania powstawania takich pętli, który polega on na wyborze jednego sąsiada MSDP, od którego zaakceptowana zostanie wiadomość SA (tzw. RPF peer). W MSDP zaimplementowano pięć reguł, pozwalających na wybranie właściwego sąsiada, które sprawdzane są w następującej kolejności:

• sąsiad MSDP jest źródłem wiadomości SA (originating RP),

• sąsiad MSDP oraz BGP, który został wybrany jako następny router (next-hop) w kierunku źródła wiadomości SA,

• sąsiad MSDP oraz BGP, który rozgłosił najlepszą (aktywną) ścieżkę do źródła wiadomości SA, • sąsiad MSDP o najwyższym adresie IP, znajdujący

się na ścieżce w kierunku źródła wiadomości SA, przenoszonej za pośrednictwem atrybutu AS_PATH, • statycznie określony sąsiad MSDP dla źródła

wiadomości SA.

Przypomnijmy, że źródłem wiadomości SA jest RP, w którym zarejestrowane zostało źródło, którego dotyczy ta wiadomość.

Jak już wspominano, protokół MSDP został opracowany jako tymczasowe rozwiązanie w modelu ASM, które było konieczne przed wdrożeniem modelu SSM. Z kolei wprowadzenie SSM odsunęło w czasie prace nad znacznie lepszym rozwiązaniem jakim jest protokół BGMP [15].

4. Podsumowanie

Protokoły routing rozgałęźnego pozwalają na zrealizowanie w sieciach wykorzystujących protokół IP, transmisji polegającej na dostarczeniu tych samych danych do grupy odbiorców. Ze względu na bardzo dobre wykorzystanie dostępnego pasma transmisja rozgłoszeniowa pełni istotną rolę w sieci Internet. W artykule przedstawiono protokoły routingu rozgałęźnego najczęściej stosowane w sieciach operatorskich oraz naszkicowano sposób ich wykorzystania.

Przedstawione w artykule mechanizmy związane z działaniem transmisji typu multicast mogą stanowić podstawę teoretyczną umożliwiającą zrozumienie metod badania wydajności tych protokołów oraz ich implementacji w sieciach.

Literatura

[1] B.M. Edwards, L.A. Giuliano, B.R. Wright: Interdomain Multicast Routing. Practical Juniper Networks and Cisco Systems Solutions. Addison Wesley 2002.

[2] W.R. Parkhurst: Cisco Multicast Routing and Switching. McGraw-Hill 1999.

[3] J. Doyle, M. Kollon: Juniper Networks Routers. The Complete Refernece. McGraw-Hill 2002.

[4] Cisco Systems Documentation: Internet Protocol Multicast.

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm

[5] RFC 1112 - S. Deering: Host Extensions for IP Multicasting. Stanford University. August 1989. http://www.ietf.org/rfc/rfc1112.txt

[6] RFC 2362 - D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. June 1998.

http://www.ietf.org/rfc/rfc2362.txt

[7] RFC 3973 - A. Adams, J. Nicholas, W. Siadak: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). January 2005. http://www.ietf.org/rfc/rfc3973.txt

[8] RFC 3618 - B. Fenner, D. Meyer: Multicast Source Discovery Protocol (MSDP). October 2003. http://www.ietf.org/rfc/rfc3618.txt

[9] RFC 2858 - T. Bates, Y. Rekhter, R. Chandra, D. Katz: Multiprotocol Extensions for BGP-4. June 2000. http://www.ietf.org/rfc/rfc2858.txt

[10] RFC 3569 - S. Bhattacharyya: An Overview of Source-Specific Multicast (SSM). July 2003. http://www.ietf.org/rfc/rfc3569.txt

[11] Internet Draft - draft-ietf-ssm-arch-07.txt. H. Holbrook, B. Cain: Source-Specific Multicast for IP. 4 October 2005. http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-07.txt

[12] RFC 3376 - B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan: Internet Group Management Protocol, Version 3. October 2002.

[13] RFC 2236 - W. Feiner: Internet Group Management Protocol, Version 2. November 1997. http://www.ietf.org/rfc/rfc2236.txt

[14] Internet Draft - N. Bhaskar, A. Gall, J. Lingard, S. Venaas: Bootstrap Router (BSR) Mechanism for PIM. draft-ietf-pim-sm-bsr-09.txt. May 2006. http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-bsr-09.txt

[15] RFC3913 - D. Thaler: Border Gateway Multicast Protocol (BGMP): Protocol Specification. September 2004.

[16] RFC 2526 - D. Johnson, S. Deering: Reserved IPv6 Subnet Anycast Addresses. March 1999. http://www.ietf.org/rfc/rfc2526.txt

[17] The 6net Consortium: An IPv6 Deployment Guide. September 2006.

http://www.6net.org/book/deployment-guide.pdf

[18] RFC4291 - R. Hinden, S. Deering: IP Version 6 Addressing Architecture. February 2006. http://www.ietf.org/rfc/rfc4291.txt

[19] RFC0791 - J. Postel: Internet Protocol. September 1981.

[20] RFC 3232 – J. Reynolds: Assigned Numbers. January 2002. ftp://ftp.rfc-editor.org/in-notes/rfc3232.txt