IP Multicast

IP Multicast to metoda przekazywania pakietów telekomunikacyjnych IP do grupy zainteresowanych odbiorców. Przejdź do artykułu multicast, aby zobaczyć ogólne informacje na ten temat – w tym artykule omawiany jest konkretnie temat IP Multicast.

Implementacje

Operatorzy płatnych stacji telewizyjnych oraz niektórych instytucji edukacyjnych ze znaczącymi przykładami na kampusach studenckich skutecznie zaimplementowali jednostronne strumieniowanie multimedia, takich jak wideo wysokiej przepływności do dużych grup odbiorników. Ponadto, multicast znalazł zastosowanie w niektórych rodzajach konferencji audio i wideo. Są one znacznie mniej rozpowszechnione i są najczęściej stosowane przez instytucje szkolnictwa wyższego i badań naukowych, które często mają większe możliwości sieci wewnętrznych do obsługi takich żądań. Niektóre konferencje i spotkania są transmitowane przy użyciu multicastu IP. Do niedawna wiele spotkań stowarzyszenia IETF było transmitowanych przy użyciu multicastu.

Innym wykorzystaniem multicastu w sieciach szkół wyższych i sieciach komercyjnych jest dystrybucja plików, w szczególności dostarczanie obrazów systemu operacyjnego i aktualizacje zdalnych komputerów. Kluczową zaletą rozsyłania obrazów rozruchowych przez multicast nad rozsyłaniem Unicast jest znacznie niższe wykorzystanie przepustowości sieci.

Multicast IP znajduje zastosowanie w sektorze finansowym, takie jak systemy rozprowadzania informacji na giełdach papierów wartościowych i w systemach komunikacji ciągłej stosowanych między innymi przez maklerów giełdowych.

Chociaż IP multicast odnosi pewne sukcesy w każdej z tych dziedzin, nie jest szeroko rozpowszechniony i generalnie nie jest dostępny jako usługa dla przeciętnego użytkownika końcowego. Istnieją co najmniej dwa główne czynniki wpływające na brak powszechnego wdrażania multicastu powiązane w pewnym stopniu ze sobą. Z jednej strony, transmitowanie ruchu multicast, szczególnie dla komunikacji dwukierunkowej, wymaga skomplikowanych rozwiązań. Z drugiej strony, istnieje szereg dodatkowych problemów związanych z działaniem takiej sieci, w dużej mierze wynikających ze złożoności samego projektu. Jednym z nich jest możliwość dodatkowych awarii, w szczególności związanych z atakami typu Denial-of-Service. Wiele z tych kwestii opisano szczegółowo poniżej.

Historia i „kamienie milowe”

MBone był daleko idącym eksperymentalnym sposobem umożliwiającym tunelowanie ruchu multicast. MBone nie jest już działającym rozwiązaniem, jednakże zainteresowanie tunelowaniem ruchu multicast przez sieć do szerokiej rzeszy odbiorców nadal istnieje.

Adresowanie

Istnieją cztery rodzaje adresowania IP, a każdy z nich ma właściwe dla siebie właściwości.

• Unicast: Najpowszechniejszy rodzaj adresowania IP. Normalnie oznacza jednego odbiorcę i jednego nadawcę oraz może być stosowany do ruchu w obie strony. Zazwyczaj adres tego typu jest przypisany do jednego urządzenia albo odbiorcy, ale nie jest to odpowiednik typu jeden-do-jednego. Niektóre komputery posiadają kilka różnych adresów unicast, każdy ma swój własny, odrębny cel. Wysyłanie tych samych danych do wielu adresów unicast wymaga od nadawcy wysłania wszystkich danych wiele razy, po jednym dla każdego odbiorcy.

• Broadcast: Rozsyłanie danych do każdego możliwego odbiorcy, pozwala na wysłanie danych tylko raz, a wszyscy odbiorcy dostają ich kopie. W protokole IP, adres 255.255.255.255 umożliwia ograniczone rozsyłanie danych tą metodą. Dodatkowo, kierowane (ograniczone) rozsyłanie może być dokonywane przez kombinacje prefiksów sieci z sufiksami odbiorców stworzonymi z binarnych jedynek. Przykładowo, rozsyłanie danych do wybranej grupy odbiorców w sieci z prefiksem 192.0.2 dokonywane jest z adresu IP 192.0.2.255 (zakładając, że maska podsieci to 255.255.255.0).

• Multicast: Adres tego typu przypisany jest do grupy zainteresowanych odbiorców. Zgodnie z RFC 3171 ↓, adresy od 224.0.0.0 do 239.255.255.255 są wyznaczone jako adresy dla multicastu. Ten zakres adresów był pierwotnie nazywany „klasą D”. Nadawca wysyła pojedynczy datagram (z adresu przypisanego do unicastu) do „ogólnego” adresu multicastu, a rutery pośredniczące zajmują się kopiowaniem i dalszym przesyłaniem kopii do wszystkich zainteresowanych odbiorców.

• Anycast: Podobnie jak broadcast i multicast, anycast jest topologią transmisji typu jeden-do-wielu. Jednakże, dane nie są przekazywane do wszystkich odbiorców, lecz tylko do jednego, który zostanie oznaczony przez ruter jako najbliższy. Anycast jest użyteczny do balansowania globalnego ruchu, działając poprzez najkrótsze drogi według protokołu BGP. Jest powszechnie stosowany w systemie nazw domen (DNS), ale nie bierze pod uwagę zatłoczenia ani innych protokołów.

Aplikacje i protokoły

Ponieważ multicast jest inną metodą transmisji niż unicast, tylko protokoły zaprojektowane dla niego mogą być racjonalnie używane z nim.

Większość z istniejących protokołów, które wykorzystują multicast, jest oparta na protokole UDP. W wielu aplikacjach, Real-time Transport Protocol (RTP), jest używany do przenoszenia multimediów przez multicast, a protokół RSVP może być wykorzystywany do rezerwacji pasma w dystrybucji przez multicast.

W sieci lokalnej, transmisja przez multicast jest kontrolowana przez IGMP (w sieciach typu IPv4) i MLD (w sieciach typu IPv6); w obrębie domeny trasowania, PIM SPB lub MOSPF jest stosowane; między domenami trasowania stosowane są wewnątrzdomenowe i protokoły trasowania, takie jak MBGP.

Wiele błędów może się zdarzyć, jeśli pakiety są przeznaczone dla unicastu przypadkowo zostaną wysłane na adres typu multicast, w szczególności, wysyłanie pakietów ICMP do adresu typu multicast zostało użyte jako wzmocnienie ataków typu DoS.

Adresowanie w IP multicast

Klasa adresów D, która jest nadal związana z grupą adresów dla multicastu, nie jest rozdzielona w sposób, w jaki rozdzielane są adresy unicast. W rzeczywistości, przydzielanie adresów grupy multicastu ciągle jest problemem. Rezultatem jest wiele, w większości niezadowalających rozwiązań.

Aktualnie istnieje szereg strategii przypisywania adresów, opisane niżej to tylko niektóre z nich. Aby uzyskać ogólne informacje oraz wskaźniki do innych dokumentów, zajrzyj do specyfikacji RFC 3171 ↓.

Blok adresów 224.0.0.0/24 służy tylko dla łączenia do lokalnego rutera multicastu. Znajduje się tu wiele rzeczy, takich jak protokoły trasowania. Datagramy do tych miejsc nigdy nie powinny być przekazywane dalej przez router.

Duża część pozostałej przestrzeni adresowej wewnątrz 224/8 została przydzielona do kilku różnorodnych aplikacji i zastosowań na przestrzeni lat lub jest po prostu zastrzeżona przez IANA.

Blok 232.0.0.0/8 jest zarezerwowany dla żądań multicastu od wybranego źródła (SSM). Blok 233.0.0.0/8 jest odłączony od adresów GLOP. W skrócie – dwa środkowe oktety bloku tworzone są przez systemy autonomiczne (AS), udzielając każdemu operatorowi przypisanemu przez AS 256 globalnie unikalnych grup adresów (na każdy AS). Ta grupa adresowa była jednym z najbardziej udanych schematów adresacji. Niestety nie jest zbyt elastyczny.

Grupa adresów 239.0.0.0/8 jest obecnie administracyjną przestrzenią adresową. Niektórzy operatorzy traktują ją zgodnie ze specyfikacją RFC 1918 ↓. Po dokładnym zapoznaniu się ze specyfikacją RFC 2365 ↓ można dowiedzieć się, że tylko podsieć tej grupy adresowej powinna być traktowana w ten sposób. Istnieje pewna grupa adresów, przydzielanych względnie, które są bardzo podobne do prywatnego zakresu adresowania unicast.

Pozostała część klasy D jest oznaczona jako zarezerwowana dla IANA.

Routing

Każda maszyna (a właściwie każda aplikacja na tej maszynie), która chce być odbiorcą grupy multicastu (np. otrzymywać dane odpowiadające konkretnej grupie adresów) musi użyć protokołu IGMP (Internet Group Management Protocol), aby dołączyć do grupy odbiorców. Sąsiadujące rutery również korzystają z tego protokołu do komunikacji.

W przypadku unicastu, każdy ruter określa adres docelowy każdego pakietu przychodzącego oraz określa z tabeli interfejsów, gdzie należy przekazać dalej ten pakiet, aby znalazł się bliżej celu. Adres źródłowy nie ma znaczenia dla rutera.

W przypadku multicastu adres źródłowy (który jest zwykłym adresem unicastu) stosowany jest do określenia celu pakietu. Ruch multicastu jest rozpatrzony jako ruch wysyłany. Ruter określa, które interfejsy odbierające są celami dla grup multicastu (adresami docelowymi) i wysyła pakiet przez odpowiednie interfejsy. Określenie reverse path forwarding jest stosowane raczej do określenia tego pojęcia transmisji danych jako od źródła, niż do celu.

Dostarczanie drugopoziomowe

Pakiety unicast dostarczane są do wybranego odbiorcy na Ethernecie albo podsieci IEEE 802.3 przez ustalanie specyficznego adresu MAC drugiego poziomu na adresie adresu Ethernetu. Pakiety nadawane korzystają z nadawczego adresu MAC (FF:FF:FF:FF:FF:FF), który zawiera bit sterujący broadcast/multicast w adresie. IANA jest właścicielem OUI adresu MAC 01:00:5e, stąd też pakiety multicastu dostarczane są przy użyciu adresów Ethernet MAC z przedziału 01:00:5e:00:00:00 - 01:00:5e:7f:ff:ff. Jest to 23-bitowy zakres dostępnych adresów. Pierwszy oktet (01) zawiera bit sterujący broadcast/multicast. Niższe 23 bity z 28 bitowego adresu IP multicastu są mapowane w te 23 bity dostępnych adresów. Oznacza to wieloznaczność przy dostarczaniu pakietów. Jeśli dwie maszyny z tej samej podsieci należą do dwóch różnych grup multicastu, których adresy różnią się tylko pierwszymi 5 bitami, pakiety Ethernetu dla obu grup będą dostarczane do obu maszyn, zmuszając ich oprogramowanie do odfiltrowywania pakietów multicastu.

Dla adresacji multicastu w IPv6, Ethernet MAC jest uzyskiwany przez cztery ostatnie oktety mieszczące się wewnątrz adresu MAC 33:33:00:00:00:00. Przykładowy adres IPv6 FF02:DEAD:BEEF::1:3 odpowiadałby adresowi Ethernet MAC 33:33:00:01:00:03.

Przełączniki sieciowe nie rozumiejące adresacji multicastu będą rozsyłać cały jego ruch do wszystkich maszyn będących wewnątrz danej sieci LAN; w tym przypadku karta sieciowa maszyny (i system operacyjny) muszą filtrować wszystkie odbierane pakiety w poszukiwaniu tych pożądanych.

Istnieją przełączniki sieciowe, które nasłuchują ruchu typu multicast i zarządzają tabelą stanów, które systemy należą do konkretnych grup odbiorców multicastu. Tabela ta jest używana do przekierowywania ruchu adresowanego do konkretnej grupy do konkretnych maszyn lub portów. Osiągane jest to przez IGMP snooping.

Dodatkowo, część przełączników ze zdolnościami „trzeciego poziomu” może symulować maszynę wysyłającą zapytania IGMP. W sieciach pozbawionych rutera (lub z wyłączonym ruterem), który mógłby przekierowywać ruch multicastu, przełączniki takie mogą generować konieczne przekazy IGMP, aby określić użytkowników konkretnych grup multicastu.

Niezawodność multicastu

Multicast, ze względu na swój charakter, nie jest mechanizmem zorientowanym na połączenia, w związku z czym protokoły takie jak TCP, które pozwalają na retransmisję brakujących pakietów, nie są odpowiednie. Do zastosowań takich jak strumieniowanie wideo i audio, okazjonalne „zgubione” pakiety nie są problemem. Dla dystrybucji krytycznych danych, mechanizm wysyłania żądań retransmisji jest konieczny.

Takim systemem, zaproponowanym przez Cisco, jest PGM (pierwotnie „Pretty Good Multicasting”, ale zmieniony z powodów znaku towarowego na Pragmatic General Multicast), udokumentowany w RFC 3208 ↓. W ramach tego schematu, pakiety multicast mają numery sekwencji i gdy pakiet jest gubiony, odbiorca może zażądać, aby pakiet został ponownie przekazany, pozwalając innym członkom grupy multicastu na ignorowanie retransmitowanych danych, jeśli nie są im potrzebne. Niedawno, rozszerzonej wersji, PGM-IC starał się stworzyć multicast IP bardziej „przyjazny protokołowi TCP”, przez obniżenie całej grupy do przepustowości dostępnej dla najgorszego odbiornika.

Dwoma innymi schematami udokumentowanymi przez Internet Engineering Task Force (IETF) są tzw. „NACK-Oriented Reliable Multicast” (NORM), udokumentowana w specyfikacji RFC 3940 ↓, i „File Delivery over Unidirectional Transport” (FLUTE), udokumentowana w RFC 3926 ↓. Oprócz własnościowych istnieją również implementacje otwarto źródłowe. Istnieją inne protokoły, takie jak Scalable Reliable Multicast, i są definiowane przez różne źródła. Protokoły te różnią się sposobem wykrywania błędów, mechanizmami stosowanymi w odzysku błędnych pakietów, skalowalnością takiego odzysku oraz leżącymi u podstaw ideami określającymi, co znaczy być niezawodnym. Lista niezawodnych protokołów Multicastu z ACM SIGCOMM Multicast Workshop, 27 sierpnia 1996 r., dokumentuje szereg podejść do tego problemu.

Niezależne grupy, takie jak Internet Protocol Multicast Standards Initiative (IPMSI) stwierdziły, że brak prawdziwie skalowalnego protokołu „Secure Reliable IP Multicast”, jak proponowany SMART Multicast (SMART) (Secure Multicast for Advanced Repeating of Television) hamuje przyjęcie IP Multicast do trasowania śróddomenowego. Brak powszechnie przyjętego systemu zawierającego mechanizmy bezpieczeństwa na poziomie AES i niezawodnie skalowalnego były przyczyną, dla której media masowej transmisji wydarzeń sportowych (np. Super Bowl) i/lub wydarzeń, informacji, czy wiadomości nie są nadawane w publicznym Internecie.

Niezawodne protokoły IP multicastu, takie jak PGM i SMART (wymienione powyżej), mają charakter eksperymentalny.

Sieci bezprzewodowe 802.11 a multicast

Sieć bezprzewodowa 802.11 będzie obsługiwać ruch multicast inaczej, w zależności od konfiguracji oszczędzania zasilania, konfiguracji DTIM (Delivery Traffic Indication Message) i ustawień częstotliwości sygnalizacji. Jeśli tryb oszczędzania energii jest wyłączony, punkt dostępu dostarczy dane multicastu po każdej sygnalizacji (domyślny interwał = 100ms, możliwy do zmiany). Jeśli tryb oszczędzania energii jest włączony, punkt dostępu będzie dostarczał datagramy multicastu po każdym interwale DTIM, który domyślnie jest co 1, 2 lub 3 sygnalizacje w większości punktów dostępu. W rezultacie, DTIM i interwał sygnalizacji, powinny być dostosowane do optymalnej wydajności podczas wdrażania multicastu w sieciach bezprzewodowych.

Linki zewnętrzne

• Y.Y. Rekhter Y.Y. i inni, Address Allocation for Private Internets, BCP 5, RFC 1918, IETF, luty 1996, DOI: 10.17487/RFC1918, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Meyer D.D., Administratively Scoped IP Multicast, BCP 23, RFC 2365, IETF, lipiec 1998, DOI: 10.17487/RFC2365, ISSN 2070-1721, OCLC 943595667  (ang.).
• Z.Z. Albanna Z.Z. i inni, IANA Guidelines for IPv4 Multicast Address Assignments, RFC 3171, IETF, sierpień 2001, DOI: 10.17487/RFC3171, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Speakman T.T. i inni, PGM Reliable Transport Protocol Specification, RFC 3208, IETF, grudzień 2001, DOI: 10.17487/RFC3208, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Paila T.T. i inni, FLUTE - File Delivery over Unidirectional Transport, RFC 3926, IETF, październik 2004, DOI: 10.17487/RFC3926, ISSN 2070-1721, OCLC 943595667  (ang.).
• B.B. Adamson B.B. i inni, Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol, RFC 3940, IETF, listopad 2004, DOI: 10.17487/RFC3940, ISSN 2070-1721, OCLC 943595667  (ang.).