IP multicast används för att skicka ett "IP-datagram" till en s.k. "host-grupp", en grupp av noll eller fler "hostar" identifierade med en unik "IP-adress". Ett "multicast-datagram" överförs till alla medlemmar i en host-grupp enligt samma "best-efforts-garanti" som vanliga "unicast-IP-datagram", d.v.s utan någon som helst garanti för att datagrammet förmedlas intakt till alla medlemmar i host- gruppen eller att det ankommer i samma relativa ordning gentemot andra datagram från samma källa som det avsänts.
Medlemskapet i en host-grupp är dynamisk; d.v.s hostar kan delta eller lämna grupper när som helst. Det finns ingen begränsning vad gäller placering av gruppens medlemmar i nätverket, eller antalet medlemmar som tillåts finnas i en grupp. En host kan vara medlem av flera grupper samtidigt, och behöver inte vara medlem i en grupp för att kunna sända till den.
Det finns olika typer av grupper; permanenta och transienta. En "permanent grupp" har en välkänd IP-adress tilldelad av nätverkets administratör. Adressen är alltså permanent tilldelad till gruppen, antalet medlemmar i gruppen fluktuerar dock och medlemskap i gruppen är inte permanent. De IP-adresser som inte är reserverade för en viss grupp är tillgängliga för bildandet av "transienta grupper" som endast existerar sålänge som det finns medlemmar kvar i gruppen.
Förmedlingen av IP-multicast-datagram i ett IP-nätverk hanteras av "multicast-routrar" som kan vara en del av, eller separerade från de routrar som hanterar unicast. Om det lokala nätverk som en host är ansluten till stödjer multicast så sänds ett IP-multicast- datagram via denna mechanism till alla gruppmedlemmar på det lokala nätverket. Om datagrammet har en IP time-to-live större än 1, så vidarebefordrar de(n) multicast-router(rar) som är ansluten till det lokala nätverket datagrammet mot alla andra lokala nätverk som innehåller medlemmar av samma grupp. På dessa andra "medlems- nätverk" som kan nås inom datagrammets IP time-to-live levererar anslutna multicast-routrar datagrammet via lokal multicast till gruppmedlemmarna där.
IPv4 och IPv6 använder olika typer av adressering för att stödja förmedling av IP multicast-dtagram. IPv4 multicast använder IP-adresser av klass D, dvs de adresser som har "1110" som "high-order-bitar". Beskrivet i Internet standard "dotted decimal"-notation finns klass-D-adresser i intervallet 224.0.0.0 till 239.255.255.255. Adressen 224.0.0.0 får inte tilldelas till någon grupp och 224.0.0.1 (ALL-HOSTS.MCAST.NET) är tilldelad till den permanenta gruppen som består av alla hostar (inklusive routrar) på det lokala nätverket som stödjer IP multicast. IP multicast-datagram som skickas till denna adress förmedlas aldrig vidare av multicast-routrarna. Det finns ingen adress eller grupp som innehåller alla hostar på ett internetnätverk. Alla adresser tilldelade permanenta grupper hanteras av IANA. För tilldelning av övriga adresser se RFC 1519.
Internet Group Management Protocol (IGMP) används av IP hosts för att rapportera medlemskap i Internet Multicast-grupper till närmaste multicast routrar.
Multicast-routrar skickar "Host Membership Query message"-datagram periodiskt för att hålla sig uppdaterade om gruppmedlemskapet för det lokala nätverket. Hostarna på det lokala nätverket svarar då med Report-datagram. Hostarna besvarar endast Qyery-datagram för de grupper som de är med i. Om inga rapporter för en viss grupp har synts efter ett visst antal Query-datagram så antar routern att det inte finns någon gruppmedlem på det lokala nätverket. Sedan vidarebefordrar den inte fler datagram för den gruppen från andra nätverk till det lokala nätverket.
När en host ska gå med i en grupp skickar den ett Report-datagram ett par gånger med korta intervall.
Det finns idag tre olika versioner av IGMP-protokollet. IGMP version 1 beskrivs i RFC 1112 som dessutom specificerar de utökningar av IP-implementationen i en host som krävs för att stödja IP multicast. IGMP v2 beskrivs i RFC 2236 och skillnaden mot v1 är att det finns stöd för att låta hostar, och det lokala nätverk de sitter på, lämna en grupp utan att behöva invänta ett par obesvarade Query-datagram. IGMP v3 beskrivs i RFC 3376 och innehåller utökningen att kunna abonnera på datagram från endast en delmängd av källorna i en viss grupp.
IGMP version 1 och version 2 finns implementerad i de flesta moderna operativsystem. Version 3 är på väg.
IGMPs position i en TCP/IP stack på en host:
| |
| Upper-Layer Protocol Modules |
|__________________________________________________________|
--------------------- IP Service Interface -------------------
__________________________________________________________
| | | |
| | ICMP | IGMP |
| IP |______________|______________|
| Module |
| |
|__________________________________________________________|
--------------- Local Network Service Interface --------------
__________________________________________________________
| | |
| Local | IP-to-local address mapping |
| Network | (t.ex., ARP) |
| Modules |_____________________________|
| (t.ex., Ethernet) |
| |
I IGMP använder multicast-routrar ALL-HOSTS.MCAST.NET 224.0.0.1 för
att skicka Query-datagram.
I IGMPv1 och v2 skickar hostarna rapporten på den adress som hosten ska abbonnera på. I IGMP v3 används 224.0.0.22 för att skicka rapporter.
För att hantera distribution av multicast-datagram mellan alla lokala nätverk som ingår i en grupp behövs en mekanism för att dela kunskap mellan alla multicast-routrar i ett internet-nätverk. Flera olika metoder för att hantera "multicast-routing" inom en viss administrativ domän, intra-domain, och mellan olika domäner inter-domain, har föreslagits. Liksom i unicast-fallet måste man vara noga med att hålla isär de båda routingtyperna.
I routingsammanhang betecknas IPv4-adressen för en viss källa med 'S', och IPv4-adressen för en viss multicastgrupp betecknas med 'G'. Ett paket, eller en serie av paket, från samma källa S till en given grupp G representeras som (S,G). En mängd paket med måladressen G från multipla källor representeras (*,G).
En multicast-router håller reda på tillståndet för varje multicastgrupp för varje lokalt nätverk den är ansluten till. Varje tillståndselement kan vara "source specific" (S,G) eller "source-generic/group-specific" (*,G).
Paket från en viss källa till en viss grupp ska bilda en trädstruktur av förmedlingsvägar genom IP-nätverket för att undvika onödig trafik. Därför kan varje tillståndselement i en router ses som en nod i en trädstruktur och innehåller ett "Input Interface" (IIF) och en lista av "Output Interfaces" (OIL). När ett paket ankommer på en IIF kontrollerar routern "Reverse Path Forwarding" (RPF) för paketet. Om RPF är godkänd så skickas paketet till alla interface i OIL.
I fallet (S,G) så utgör källans närmaste multicast-router roten på trädet, medan i fallet (*,G) så delas samma trädstruktur av alla källor till gruppen. Roten till trädet utgörs då av en dedikerad källa för den gruppen.
Förmedling av multicast-datagram sker alltså på likartat sätt som för IP unicast, med den skillnaden att de byggstenar som används för att bygga förmedlingsträden, alltså källadresser och gruppadresser ändras oftare vilket gör att hela träden måste rivas ner och byggas upp på nytt.
En annan kritisk faktor är mängden tillståndsinformation som lagras i multicast-routrarna. I unicastfallet kan man reducera mängden tillståndsinformation genom att gruppera hostadresser i nät och subnät samt att man kan minimera antalet utgångar från en domän och använda default-route för allt man inte har direkt tillgång till. I multicastfallet är inte gruppadresserna indelade i nät, men man kan göra subnät (Administratively scoped multicast) och man kan använda delade förmedlingsträd i så stor utsträckning som möjligt (Protocol Independent Multicast Sparse Mode, PIM-SM). Man kan också minimera antalet källor genom att ändra i applikationsprotokoll och applikationsprogram (Source-Specific Multicast, SSM).
För att bygga dessa förmedlingsträd, och underhålla dem, har ett flertal routingprotokoll tagits fram.
I IETFs arbetsgrupp MBONED tas för närvarande fram ett dokument, "IPv4 Multicast Best Current Practice", som beskriver det för närvarande bästa sättet att tillhandahålla IP multicast i en nätverksdomän, samt bästa sättet att koppla upp sig mot andra nätverksdomäner som stödjer IP multicast.
Maintained by Tobias Öbrink