Strona 1 z 7

Wydział AEiI

Gliwice dn. 14.05.2002

Informatyka

[MATERIAŁY DO SKRYPTU Z SIECI KOMPUTEROWYCH]

MULTICAST ROUTING – opracowanie teoretyczne

i przykład wykorzystania w systemie LINUX

AUTOR ROZDZIAŁU:

Aleksander Wala

gr. 2, sem VIII

[e-mail]

http://www.email.pl/~awala

Strona 2 z 7

Rozdział ten ma na celu przedstawić działanie protokołu rozpowszechnianego

sukcesywnie w Internecie i związanego z zaawansowanymi metodami trasowania (routingu) i
maksymalnej optymalizacji metod transmisji wraz z optymalnym wykorzystaniem
istniejących łącz. Na czym polega multicast routing?

1.) Wprowadzenie

Multicast routing powstał w odpowiedzi na potrzeby. Wraz ze wzrostem ilości

komputerow podłączonych do Internetu, wraz ze wzrostem poziomu usług w Internecie a co
za tym idzie transmisji coraz to większych danych do coraz to większej rzeszy odbiorców
narodziła się potrzeba zoptymalizowania dotychczasowego sposobu przesyłu informacji.
Mieliśmy dotąd 3 sposoby transmisji:

• UNICAST – gdzie informacja była przesyłana do konkretnego odbiorcy

• BROADCAST – gdzie informacje były wysyłane do wszystkich niezależnie od tego

czy ktoś informacji żądał czy nie

• ANYCAST – informacja dociera do dowolnego z zadanych adresatów.

Metoda omawiana w tym rozdziale to MULTICAST, czyli przesyłanie informacji do wielu
odbiorców (ale nie wszystkich). Unicast to po prostu standardowy przesył między dwoma
węzłami sieci. Przykładowo całe TCP/IP jest ze swojej natury zorientowane unicastowo.
Wystarczało to aż do roku 1993, kiedy to po raz pierwszy w systemach BSD 4.4
zaimplementowano protokół multicast.

Załóżmy sytuację gdzie jest stacja nadawcza np. internetowa rozgłośnia
radiowa/telewizyjna znajdująca się w mieście X oraz oddaleni o k węzłów odbiorcy Y1...YN.

Strona 3 z 7

W tradycyjnym modelu odbiorca Y(n) żąda informacji a stacja X ją nadaje. Przy N
odbiorcach dane przesyłane są dublowane. O ile nie ma to znaczenia w mniejszych sieciach to
przy K węzłach i M stacjach radiowych (np. łącza międzykontynentalne) takie dublowanie się
informacji jest stratą cennych i drogich pasm i kanałów transmisji.

Multicast to coś w rodzaju radia czy telewizji. Nadawana jest informacja a odbiera ją

tylko ten, kto „nastawi swój odbiornik na odpowiednią częstotliwość”.

2.) Adresowanie

multicastowe

Jak zapewne była już mowa we wcześniejszych rozdziałach adresowanie w Internecie

bazuje na 32-bitowym adresie zwanym adresem IP. Składa się on z czterech ośmiobitowych
pól. Przyjrzyjmy się dokładnemu podziałowi całej puli adresów.

Bit --> 0 31 Zakresy adresów:
+-+----------------------------+
|0| Klasa A | 0.0.0.0 - 127.255.255.255
+-+----------------------------+
+-+-+--------------------------+
|1 0| Klasa B | 128.0.0.0 - 191.255.255.255
+-+-+--------------------------+
+-+-+-+------------------------+
|1 1 0| Klasa C | 192.0.0.0 - 223.255.255.255
+-+-+-+------------------------+
+-+-+-+-+----------------------+
|1 1 1 0| Adresy multicastowe | 224.0.0.0 - 239.255.255.255
+-+-+-+-+----------------------+
+-+-+-+-+-+--------------------+
|1 1 1 1 0| Zarezerwowane | 240.0.0.0 - 247.255.255.255
+-+-+-+-+-+--------------------+

Jak więc widać każdy datagram w Internecie, którego adres zaczyna się od sekwencji

bitów 1110 lub mniej inżyniersko od adresu 224.0.0.0 do 239.255.255.255 to datagram
multicastowy. Pozostałe bity to niejako ta nasza „częstotliwość” określająca grupę odbiorców.
Nie można jednak wykorzystywać sobie tych adresów dowolnie. Są one podzielone na
funkcje. Jest kilka grup o określonych z góry funkcjach, które nie powinny być
wykorzystywane do zwykłych celów. Przykładowo:

• 224.0.0.1 – grupa wszystkich hostów (komputerów, serwerów) obsługujących

multicast. Jeśli zrobimy pinga na ten adres odpowiedzą wszystkie komputery, które
obsługują multicast – oczywiście nie wszystkie na świecie tylko wszystkie w naszej
podsieci. Może to być rodzaj testu po konfiguracji komputera czy multicast działa
(ping 224.0.0.1)

• 224.0.0.2 – grupa wszystkich routerów obsługujących multicast
• 224.0.0.4 – grupa routerów DVMRP

• 224.0.0.5 – grupa routerów OSPF

• 224.0.0.13 – grupa routerów PIM
• oraz wiele innych, których wipisywanie tutaj nie jest celowe

Wszystkie te grupy są zdefiniowane w odpowiednim RFC numer 2365.

Strona 4 z 7

Generalnie cały zakres 224.0.0.0 – 224.0.0.255 przeznaczony jest do sieci LAN i

pakiety z tymi adresami przeznaczenia nie wychodzą poza routery – nawet multicastowe (tak
jak np. pula 192.168.x.x nie jest standardowo przez jądro routowana)

Podobnie grupa 239.0.0.0 – 239.255.255.255 została już zarezerwowana do celów

administracyjnych.

3.) Poziomy

zgodności z MULTICAST’em

Węzły w sieci mogą mieć trzy różne poziomy zgodności z protokołem multicastowym:
• Poziom 0 – całkowity brak zgodności z IP multicastingiem. Wiele komputerów na

dzień dzisiejszy jest na tym poziomie, jako że multicast nie jest obowiązkowy i
wewnętrznie obsługiwany przez IP w wersji czwartej. Wersja 6 implementacji IP w
pełni wspiera już multicasting nie jest jednak ona obowiązująca (na dzień dzisiejszy)
w Internecie.

• Poziom 1 – wsparcie do wysyłania datagramów multicastowych ale bez możliwości

odbioru. Nie ma potrzeby zapisywania się do grup, jeśli chcemy tylko nadawać.
Niewiele pracy kosztuje przejście z poziomu 0 do poziomu 1. Sens pozostania w tym
poziomie jest dla serwisów udostępniających dane, które mają zapewnione kilka
kolejnych routerów wspierających poziom 2

• Poziom 2 – pełne wsparcie dla odbioru i wysyłania pakietów multicastowych. Punkty

w tym poziomie zgodności wiedzą jak zapisywać się do grup oraz jak przesyłać
informacje do routerów multicastowych. Pociąga to za sobą implementację Internet
Group Management Protocol (IGMP) w konfiguracji stosu TCP/IP.

4.) Wysyłanie datagramów multicastowych

Cały ruch multicastowy odbywa się w warstwie transportowej z wykorzystaniem UDP

ponieważ TCP to z natury połączenia z punktu do punktu i nie nadaje się do muticastu.
Trwają bardzo intensywne badania nad wdrożeniem nowych protokołów transportowych, dla
multicastu (Multicast Transport Protocols – MTP). Aby więc wysłać informacje należy
otworzyć gniazdo UDP i wysłać pakiet z odpowiednim adresem multicastowym. Jest jednak
kilka operacji niezbędnych, które proces transportu musi kontrolować.

a) TTL – ma tutaj podwójne znaczenie. Standardowo czas Time To Live w nagłówku IP

ma za zadanie zapobiegać nieskończonej pętli przy błędach routingu. Kolejne routery
zmniejszają ttl i gdy osiągnie zero pakiet jest porzucany i nieprzesyłany dalej. TTL w
IPv4 multicastowym ma także znaczenie progowe. TTL steruje pakietami w znaczeniu
takim że TTL jest porównywane z odpowiednimi wartościami i wypuszczane dalej
przez dane routery czy interfejsy. Oto spis poszczególnych wartości. Warto dodać iż
są to umowne wartości i zależą w dużej mierze od administratora i konfiguracji.
• TTL=0 – ograniczenie pakietu do tego samego interfejsu. Pakiety nie wychodzą

poza żaden interfejs.

• TTL=1 – Ograniczenie do podsieci. Pakiet nie wyjdzie poza router (mrouter).
• TTL<32 – ograniczenie do danego departamentu lub organizacji.

• TTL<64 – ograniczenie do danego regionu

• TTL<128 – ograniczenie do danego kontynentu
• TTL<256 – zasięg globalny

b) Loopback – pętla zwrotna – domyślnie jeśli dany węzeł sieci jest w 2 poziomie

zgodności z IP multicastingiem kopia danych przychodzących jest zwrotnie pętlona na
danym interfejsie. Chodzi o to, że gdy nadajemy dane a sami mamy procesy, które

Strona 5 z 7

chcą tych danych słuchać nie trzeba nasłuchiwać na kablu tych ramek. Należe jeszcze
podczas wysyłania, gdy dana ramka jest wewnątrz naszego stosu TCP/IP przekazywać
odpowiedniemu procesowi. Zapobiega to nadmiernym i niepotrzebnym obciążeniom.
Cecha ta może być świadomie włączona lub nie.

c) Wybór interfejsu – należy programowo zadbać o wybór interfejsu. Jądro będzie

wybierało domyślny ustawiony przez administratora. Ma to znaczenie przy większych
systemach podłączonych do wielu sieci (>1).

5.) Odbieranie

datagramów multicastowych

a) Dołączanie się do grupy – polega na tym, że mówimy jądrze systemu, że jesteśmy

zainteresowani daną grupą multicastową i aby przekazywał nam wszystkie pakiety
związane z daną grupą. Jednak nie tylko nam, ale każdemu procesowi, który wyrazi
zainteresowanie. Jeśli więc dany proces chce korzystać z grupy musi powiedzieć o
tym kernelowi i przydzielić port, na którym będziemy chcieli te datagramy odbierać.
UDP korzysta z adresu i portu, aby demultipleksować nadsyłane pakiety.

b) Odłączanie się od grupy – polega na daniu sygnału do jądra, że dana grupa już nas nie

interesuje. Wcale to nie znaczy, że jądro nie bedzie już odbierać z danej grupy, jako że
inne procesy, które zadeklarowały przyłączenie dalej mogą potrzebować tych
informacji. Trzeba zrozumieć, że członkostwo w grupie muticastowej jest per-host a
nie per-proces. Nawet idąc dalej, jeśli pozostajemy na nasłuchu na danym porcie a
inne grupy nadal słuchają na danej grupie to, mimo iż zrezygnowaliśmy jako proces ze
słuchania datagramy będą do nas docierały.

6.)

Podstawy konfiguracji LINUX’a do obsługi multicastingu

LINUX to wielozadaniowy, wieloużytkownikowy system operacyjny, którego główne

i najbardziej na dzień dzisiejszy racjonalne wykorzystanie jest w zastosowaniach sieciowych
jako serwer (z wszelkimi możliwymi usługami) oraz jako router a także firewall.
Zastosowania LINUX’a są bardzo szerokie i pisanie o nich nie jest celem tego rozdziału
warto jednak wspomnieć iż przez coraz to liczniejsze osoby wykorzystywany jest także jako
stacja robocza w zastosowaniach biurowych.

Nie będzie więc zaskoczeniem jeśli powiemy sobie iż LINUX doskonale może

pracować w drugim poziomie zgodności z multicastingiem czyli może zarówno odbierać jak i
nadawać pakiety multicastowe oraz spełniać funkcje routera multicastowego (mrouter’a).
Powiemy sobie jak przystosować LINUX’a do pracy zgodnej z multicastem.

Pierwszym krokiem jest tutaj odpowiednia konfiguracja jądra systemu. W niektórych

wersjach multicasting jest jeszcze oznaczony jako „EXPERIMENTAL”. Trzeba wtedy
włączyć w sekcji "Code maturity level options" punkt "Prompt for development and/or
incomplete code/drivers". Aby odbierać i nadawać multicastowo trzeba zaznaczyć funkcję
"IP: multicasting". Jeśli chcemy wykorzystać linux’a jako router multicastowy musimy w
konfigracji jądra zaznaczyć: "IP: forwarding/gatewaying", "IP: multicast routing" oraz
"IP: tunneling". Opcja tunelowania multicastowego jest wymagana, ponieważ routing
multicastowy jest w nowych wersjach oparty o tunele. Pakiety multicastowe są
enkapsulowane w pakiety unicastowe. Jest to konieczne, jeśli chcemy tunelować podsieci
multicastowe rozdzielone nie multicastowanymi routerami lub sieciami.

Strona 6 z 7

Jeśli ustawimy już jądro do ruchu multicastowego potrzebujemy demona, który będzie

ten ruch kontrolować. Taki demon w linuxie to mrouted. Ma on zaimplementowane
algorytmy routingu multicastowego i instruuje on jądro, w jaki sposób przekazywać
multicastowe datagramy.

W tym celu instalujemy mrouted. Po zainstalowaniu konfiguracja znajduje się w pliku

/etc/mrouted.conf. W niej umieszczamy linie, które wymuszają na interfejsach eth0 i eth1
IGMP versję 1 jako, że ta wersja jest na dzień dzisiejszy bardziej popularna. Dodatkowo bez
limitów przepustowości:

phyint eth0 rate_limit 0 igmpv1
phyint eth1 rate_limit 0 igmpv1

Następnie musimy dodać do tablicy routingu sieć 224.0.0.0, która będzie nas

interesować i przypisać ją do odpowiedniego interfejsu. Nie będziemy się tu rozwlekać na
temat znaczenia adresu IP, maski podsieci itp. Te rzeczy były omawiane w rozdziałach
wcześniejszych i są podstawami sieci TCP/IP. Zakładamy, iż osoby zainteresowane
multicastingiem mają te podstawy już opanowane. Dodawanie do tablicy routingu
realizujemy następującą komendą: „route add 224.0.0.0 netmask 240.0.0.0 dev eth0” lub „ip
route add 224.0.0.0/4 dev eth0” jeśli korzystamy z pakietu iproute2. Można oczywiście wedle
potrzeb dać inny interfejs (dev). Ostatnim krokiem jest ustawienie jądra, aby forwardowało
pakiety czyli „echo 1 > /proc/sys/net/ipv4/ip_forward”. Możemy teraz wystartować demona
mrouted poleceniem „mrouted -c /etc/mrouted.conf -d”. W katalogu /proc reprezentującym
dynamiczne zmiany w konfiguracji jądra możemy zobaczyć do jakich grup aktualnie
należymy. Można to zobaczyć w pliku (/proc/net/igmp). Dopisywanie się do danej grupy
realizujemy już poprzez program. Nie ma różnicy w odbieraniu zwykłych datagramów i
multicastowych. Przykłady programów multicastowych są dostępne w bardzo obszernej ilości
w Internecie.

7.) Szkielet

multicastowy (MBone)

Często zdarza się, iż mimo intensywnej pracy, wysiłkowi wymianie sprzętu i systemu

operacyjnego nasze całe zaangażowanie poszło na marne z racji tego, że inne komputery nie
zostały odpowiednio skonfigurowane, aby dalej rozsyłać multicastowo komunikaty. Wtedy
jedynym wyjściem jest tunelowanie pomiędzy obsługującymi multicast częściami sieci
poprzez tradycyjne routery. Pakiety multicastowe są pakowane do pakietów multicastowych,
wysyłane do przeznaczenia i tam znów rozpakowywane (deencapsulated) do pakietów
multicastowych. Tym właśnie jest MBone lub, jak kto woli Multicast Backbone. To wirtualna
sieć tuneli łącząca podsieci obsługujące multicasting. Wykorzystywane jest to przy odległych
telekonferencjach i innych usługach wykorzystujących duże przepustowości i transmitujących
te same dane do większej liczby odbiorców. Więcej informacji na ten temat pod adresem
http://www.mediadesign.co.at/newmedia/more/mbone-faq.html.

8.)

Zastosowanie - aplikacje multicastowe

Przykład wykorzystania protokołu multicastowego:

• Konferencje Audio

• Konferencje Video

• Radio internetowe
• Telewizja internetowa

• inne usługi jak mmphone, webcast, shared white boards

Strona 7 z 7

Wszystkie te aplikacje korzystają z sieci MBone aby nie ograniczać się do zastosowań
lokalnych.

9.) Wyjaśnienie pojęć związanych z multicastem – wskazanie źródeł

• RIP - Routing Information Protocol – standardowy protokół do routingu (RFC1058)

• DVMRP - Distance Vector Multicast Routing Protocol – rozbudowany RIP o wektory

odległości (RFC1075)

• OSPF- sposoby routingu oparte o topologie liczące najszybsza trasę (RFC2328)
• MOSPF - Multicast Extensions to OSPF – rozszerzenie OSPF dla multicastingu

(RFC 1584)

• PIM – Protocol Independent Multicast - czeka na żądania klientów dokonuje zmian w

tablicy routingu PISM dostarcza datagramy. W momencie inicjalizacji transmisji
tworzą pustą tablicę routingu grupowego, a następnie dołączają odbiorców do danej
grupy jedynie na ich wezwanie, czyli wysłanie komendy przyłączenia protokołu
IGMP

• PIM-SM – Protocol Independent Multicast-Sparse Mode (RFC2362) – tryb

rozproszony, który zakłada że użytkownicy są mocno rozproszeni – głównie w
Internecie

• PIM-DM - Protocol Independent Multicast-Dense Mode – tryb zagęszczony, który

zakłada że grupy użytkowników będą blisko siebie – głównie w sieciach lokalnych

• IGMP - Internet Group Management Protocol – protokół do zarządzania grupami

multicastowymi (RFC3228)

10.) Literatura

• Multicast over TCP/IP HOWTO Juan-Mariano de Goyeneche [e-mail]

(http://www.netsys.com/library/suse/howto/en/Multicast-HOWTO.txt)

• Linux Advanced Routing & Traffic Control HOWTO
• Linux-Mrouted-MiniHOWTO

• inne dokumentacje techniczne dostępne w internecie związane z tematem.

• RFC (Request for Comment) – wiele pozycji