IP multicast

IP multicast är en metod för att skicka Internet Protocol (IP) datagram till en grupp av intresserade mottagare i en enda överföring. Det är den IP-specifika formen av multicast och används för strömmande media och andra nätverkstillämpningar. Den använder speciellt reserverade multicast-adressblock i IPv4 och IPv6 .

Protokoll förknippade med IP multicast inkluderar Internet Group Management Protocol , Protocol Independent Multicast och Multicast VLAN Registration . IGMP snooping används för att hantera IP multicast-trafik på lager-2- nätverk.

  IP multicast beskrivs i RFC 1112 . IP multicast standardiserades först 1986. Dess specifikationer har utökats i RFC 4604 för att inkludera grupphantering och i RFC 5771 för att inkludera administrativt omfångade adresser.

Teknisk beskrivning

IP multicast är en teknik för en-till-många och många-till-många realtidskommunikation över en IP-infrastruktur i ett nätverk. Den skalas till en större mottagarpopulation genom att varken kräva förkunskaper om en mottagares identitet eller förkunskaper om antalet mottagare. Multicast använder nätverksinfrastruktur effektivt genom att kräva att källan bara skickar ett paket en gång, även om det behöver levereras till ett stort antal mottagare. Noderna i nätverket (vanligtvis nätverksväxlar och routrar ) tar hand om att replikera paketet för att nå flera mottagare så att meddelanden skickas över varje länk i nätverket endast en gång.

Det vanligaste transportlagerprotokollet för att använda multicast-adressering är User Datagram Protocol (UDP). Till sin natur är UDP inte tillförlitlig – meddelanden kan gå förlorade eller levereras ur funktion. Pålitliga multicast -protokoll som Pragmatic General Multicast (PGM) har utvecklats för att lägga till förlustdetektering och återsändning ovanpå IP-multicast.

Nyckelkoncept i IP multicast inkluderar en IP multicast gruppadress, ett multicast distributionsträd och mottagardrivet trädskapande.

En IP multicast-gruppadress används av källor och mottagare för att skicka och ta emot multicast-meddelanden. Källor använder gruppadressen som IP-destinationsadress i sina datapaket. Mottagare använder denna gruppadress för att informera nätverket om att de är intresserade av att ta emot paket som skickas till den gruppen. Till exempel, om något innehåll är associerat med grupp 239.1.1.1 kommer källan att skicka datapaket destinerade till 239.1.1.1 . Mottagare för det innehållet kommer att informera nätverket om att de är intresserade av att ta emot datapaket skickade till gruppen 239.1.1.1 . Mottagaren ansluter sig till 239.1.1.1 . Det protokoll som vanligtvis används av mottagare för att gå med i en grupp kallas IGMP ( Internet Group Management Protocol) .

Med routingprotokoll baserade på delade träd, när mottagarna går med i en viss IP-multicast-grupp, konstrueras ett multicast-distributionsträd för den gruppen. Det protokoll som används mest för detta är Protocol Independent Multicast (PIM). Den sätter upp multicast-distributionsträd så att datapaket från avsändare till en multicast-grupp når alla mottagare som har anslutit sig till gruppen. Det finns varianter av PIM-implementeringar: Sparse Mode (SM), Dense Mode (DM), källspecifik multicast (SSM) och Bidirectional Mode (Bidir, eller Sparse-Dense Mode, SDM). Av dessa är PIM-SM den mest utbredda från och med 2006; [ citat behövs ] SSM och Bidir är enklare och skalbara varianter som utvecklats på senare tid och blir allt populärare. [ citat behövs ]

IP multicast-drift kräver inte en aktiv källa för att känna till gruppens mottagare. Multicast-trädkonstruktionen är mottagardriven och initieras av nätverksnoder som är nära mottagarna. IP multicast skalar till en stor mottagarpopulation. IP multicast-modellen har beskrivits av internetarkitekten Dave Clark som: "Du lägger paket i ena änden, och nätverket konspirerar för att leverera dem till alla som frågar."

IP multicast skapar statusinformation per multicast distributionsträd i nätverket. Om en router är en del av 1000 multicast-träd har den 1000 multicast-dirigerings- och vidarebefordranposter. Å andra sidan behöver en multicast-router inte veta hur man når alla andra multicast-träd på Internet. Den behöver bara veta om multicast-träd som den har nedströmsmottagare för. Detta är nyckeln till att skala multicast-adresserade tjänster. Däremot måste en unicast-router veta hur man når alla andra unicast-adresser på Internet, även om den gör detta med bara en standardrutt. Av denna anledning är aggregering nyckeln för att skala unicast-routing. Det finns också kärnroutrar som bär rutter i hundratusentals eftersom de innehåller routingtabellen för Internet.

Routing

Varje värd som vill vara en mottagande medlem i en multicast-grupp (dvs. ta emot data som motsvarar en viss multicast-adress) måste använda IGMP för att gå med. Intilliggande routrar använder också detta protokoll för att kommunicera.

I unicast-routing undersöker varje router destinationsadressen för ett inkommande paket och slår upp destinationen i en tabell för att bestämma vilket gränssnitt som ska användas för att det paketet ska komma närmare sin destination. Källadressen är irrelevant för routern. I multicast-routing används emellertid källadressen (som är en enkel unicast-adress) för att bestämma dataströmmens riktning. Källan till multicast-trafiken anses uppströms. Routern bestämmer vilka nedströmsgränssnitt som är destinationer för denna multicast-grupp (destinationsadressen) och skickar ut paketet genom lämpliga gränssnitt. Termen vidarebefordran av omvänd väg används för att beskriva detta koncept att dirigera paket bort från källan, snarare än mot destinationen.

Ett antal fel kan inträffa om paket avsedda för unicast av misstag skickas till en multicast-adress; i synnerhet har att skicka ICMP-paket till en multicast-adress använts i samband med DoS-attacker som ett sätt att uppnå paketförstärkning.

På det lokala nätverket styrs multicast-leverans av IGMP (på IPv4 -nätverket) och MLD (på IPv6 -nätverket); inom en routingdomän används PIM eller MOSPF ; mellan routingdomäner använder man multicast-routingprotokoll mellan domäner, såsom MBGP .

Följande är några vanliga leverans- och routingprotokoll som används för multicast-distribution:

Lager 2 leverans

Unicast-paket levereras till en specifik mottagare på ett Ethernet- eller IEEE 802.3-subnät genom att ställa in en specifik MAC-adress för lager 2 på Ethernet-paketadressen. Broadcast-paket använder sig av broadcast-MAC-adressen FF:FF:FF:FF:FF:FF .

IPv4 multicast-paket levereras med Ethernet MAC-adressintervallet 01:00:5E:00:00:00 till 01:00:5E:7F:FF:FF (med en OUI som ägs av IANA ). Detta intervall har 23 bitar tillgängligt adressutrymme. Den första oktetten (01) inkluderar broadcast/multicast-biten. De nedre 23 bitarna av 28-bitars multicast-IP-adressen mappas till de 23 bitarna av tillgängligt Ethernet-adressutrymme. Detta innebär att det finns oklarheter i att leverera paket. Om två värdar på samma subnät var och en prenumererar på en annan multicast-grupp vars adress skiljer sig endast under de första 5 bitarna, kommer Ethernet-paket för båda multicast-grupperna att levereras till båda värdarna, vilket kräver att nätverksmjukvaran i värdarna kasserar de oönskade paketen.

För IPv6 multicast-adresser härleds Ethernet MAC av de fyra lågordningens oktetter ELLER med MAC 33:33:00:00:00:00, så till exempel IPv6-adressen ff02:dead:beef::1: 3 skulle mappas till Ethernet MAC-adressen 33:33:00:01:00:03 . Om en switch inte förstår multicast-adresser kommer den att översvämma den trafiken till alla medlemmar i ett LAN; i detta fall måste systemets nätverkskort (eller operativsystem) filtrera de paket som skickas till multicast-grupper som de inte abonnerar på.

Det finns switchar som lyssnar på IGMP-trafik och upprätthåller en tillståndstabell över vilka nätverkssystem som abonnerar på en given multicast-grupp. Denna tabell används sedan för att vidarebefordra trafik som är destinerad till en given grupp endast till en begränsad uppsättning värdar (portar). Denna process att lyssna på IGMP-trafiken kallas IGMP snooping .

Dessutom kan vissa switchar med lager 3-funktioner fungera som en IGMP-querier. I nätverk där det inte finns någon router för att fungera som en multicast-router, kan en switch med IGMP snooping querier aktiverad användas för att generera de nödvändiga IGMP-meddelandena för att få användare att prenumerera på multicast-trafik.

Trådlösa överväganden

802.11 trådlösa nätverk använder samma intervall av MAC-adresser som trådbundet Ethernet för att kartlägga IP-multicastadresser. Ett trådlöst 802.11-nätverk hanterar dock multicast-trafik på olika sätt, beroende på konfigurationen av leveranstrafikindikeringsmeddelande (DTIM) och beacon-intervallinställningar . Om inga stationer inom bastjänsten är i energisparläge, skickas multicast-paket direkt när de anländer. Om det finns en eller flera stationer i energisparläge levererar accesspunkter endast multicast-trafik efter varje DTIM-intervall och sänder med en av de stödda hastigheterna i grundhastighetsuppsättningen. I de flesta trådlösa åtkomstpunkter är standardkonfigurationen för detta intervall antingen 102,4 ms [ citat behövs ] (Beacon-intervall = 100 ms, DTIM = 1) eller 204,8 ms [ citat behövs ] (Beacon-intervall = 100 ms, DTIM = 2) och sändningshastigheten är antingen 1 Mbit/s eller 6 Mbit/s [ citat behövs ] , beroende på driftband och skyddsläge. Inställningarna för DTIM och beaconintervall kan justeras för att förbättra multicast-prestandan i trådlösa nätverk.

Till skillnad från Ethernet skickas den mesta trafiken i 802.11 på ett tillförlitligt sätt med hjälp av ACK och NACK så att radiostörningar inte orsakar olidligt höga paketförluster. Men multicast-paket skickas en gång och bekräftas inte, så de är föremål för mycket högre förlustfrekvenser. Det finns olika metoder för att hantera detta, som att välja att unicast multicast-data upprepade gånger till varje klient, eller begära ACK från varje klient. Vissa metoder kräver endast modifiering av åtkomstpunkten och stöds i vissa enheter i företagsklass, medan andra förbättringar skulle kräva modifieringar av klienter och därför inte har fått någon utbredd användning.

Säker multicast

IP multicast är en internetkommunikationsmetod där ett enda datapaket kan överföras från en avsändare och replikeras till en uppsättning mottagare. Replikeringsteknikerna är något beroende av media som används för att överföra data. Sändning av multicast på ett inbyggt sändningsmedium som Ethernet eller en satellitlänk tillåter automatiskt att datapaketet tas emot av alla mottagare som är direkt kopplade till mediet. Däremot kräver överföring av multicast på media som är punkt-till-punkt eller punkt-till-multipunkt att paketet replikeras för varje länk. Replikeringsprocessen bör ske på ett optimalt sätt där ett distributionsträd byggs inom nätverket. Paketet kan replikeras vid var och en av grenarna i trädet. Detta minskar kravet på avsändaren att replikera paketet en gång för varje mottagare.

Användningen av IPsec som en kommunikationslänk kräver en punkt-till-punkt-anslutning. Vanligtvis krävs säkerhet från avsändare till mottagare, vilket innebär att avsändaren måste replikera paketet på var och en av de säkra anslutningarna - en för varje mottagare. När antalet mottagare växer måste avsändaren skala genom att replikera paketet till var och en av mottagarna. Bearbetningsbelastningen på avsändaren kan vara hög vilket begränsar skalbarheten för avsändaren. En ny metod krävdes för att säkert överföra multicast och detta kallades Secure Multicast eller Multicast Security.

Internet Engineering Task Force ( IETF ) skapade ett nytt Internet Protocol (IP) för att säkert överföra multicast-trafik över ett paketnätverk. Protokolldefinitionen utvecklades i Multicast Security Workgroup och ledde till flera Request for Comments (RFC) som nu används som standarder för att säkra IP multicast-trafik. Protokollet gjorde det möjligt för en avsändare att kryptera multicast-paketet och vidarebefordra det till paketnätverket på det optimala distributionsträdet. Paketet kan replikeras på de optimala platserna i nätverket och levereras till alla mottagare. Mottagarna kan dekryptera paketet och vidarebefordra paketet i den säkra nätverksmiljön. Avsändaren av ett multicast-paket känner inte till de potentiella mottagarna; därför är skapandet av parvisa krypteringsnycklar (en för varje mottagare) omöjligt. Avsändaren måste kryptera paket med en delad nyckel som alla legitima mottagare använder för att dekryptera paketen. Systemets säkerhet är baserad på möjligheten att kontrollera distributionen av nycklarna endast till dessa legitima mottagare. För detta skapade IETF Group Domain of Interpretation (GDOI) definierat i RFC 6407. Protokollet tillåter avsändaren och mottagaren att ansluta sig till en nyckelserver där policyer och nycklar krypteras och distribueras till medlemmarna i den säkra multicast-gruppen. Nyckelservern kan autentisera och auktorisera avsändare och mottagare till en specifik grupp där den delade nyckeln används för att kryptera och dekryptera trafik mellan medlemmar i gruppen.

Pålitlig multicast

Ytterligare information: Pålitlig multicast

Multicast, till sin natur, är inte en anslutningsorienterad mekanism, så protokoll som TCP , som möjliggör omsändning av saknade paket, är inte lämpliga. För applikationer som strömmande ljud och video är det inte ett problem att tappa paket då och då. Men för distribution av kritiska data krävs en mekanism för att begära omsändning.

Ett sådant schema, som föreslagits av Cisco, är PGM (ursprungligen Pretty Good Multicasting, men ändrades av varumärkesskäl till Pragmatic General Multicast ), [ citat behövs ] dokumenterat i RFC 3208. I detta schema har multicast-paket sekvensnummer och när ett paket är missat kan en mottagare begära att paketet ska multicastas på nytt med andra medlemmar i Multicast-gruppen och ignorera ersättningsdata om det inte behövs. En utökad version, PGM-CC, har försökt göra IP Multicasting mer "TCP-vänlig" genom att trappa ner hela gruppen till den bandbredd som är tillgänglig för den sämsta mottagaren.

Två andra scheman dokumenterade av Internet Engineering Task Force (IETF) är: standardspårprotokollet NACK-Oriented Reliable Multicast (NORM), dokumenterat i RFC 5740 och RFC 5401, och protokollet File Delivery over Unidirectional Transport (FLUTE), dokumenterat i RFC 6726. Open-source, förutom proprietära, implementeringar finns för dessa. Andra sådana protokoll finns, såsom Scalable Reliable Multicast , och definieras av en mängd olika källor. Sådana protokoll varierar i sättet för feldetektering, mekanismerna som används vid felåterställning, skalbarheten av sådan återställning och de underliggande idéerna som är involverade i vad det innebär att vara pålitlig. En lista över tillförlitliga multicast-protokoll från ACM SIGCOMM Multicast Workshop, 27 augusti 1996, dokumenterar ett antal tillvägagångssätt till problemet.

Oberoende grupper som Internet Protocol Multicast Standards Initiative (IPMSI) har hävdat att avsaknaden av ett verkligt skalbart Secure Reliable IP Multicast-protokoll som det föreslagna Secure Multicast for Advanced Repeating of Television (SMART) har hindrat antagandet av IP Multicast i interdomäner routing. Avsaknaden av ett allmänt antaget system som har AES-nivåsäkerhet och skalbar tillförlitlighet har hindrat massmedias sändningar av sportevenemang (som Super Bowl) och/eller senaste nyheter från att sändas på det offentliga internet. [ citat behövs ]

Pålitliga IP Multicasting-protokoll, såsom PGM och SMART, är experimentella; det enda standardspårprotokollet är NORM (standardspårrevisionen av RFC 3941 specificeras i RFC 5401, standardspårsrevisionen av RFC 3940 specificeras i RFC 5740).

Multicast-baserade protokoll

Eftersom multicast är ett annat överföringsläge än unicast, kan endast protokoll utformade för multicast användas med multicast. De flesta av de befintliga applikationsprotokollen som använder multicast körs ovanpå User Datagram Protocol (UDP).

I många applikationer används Real-time Transport Protocol (RTP) för inramning av multimediainnehåll över multicast; RSVP ( Resource Reservation Protocol ) kan användas för bandbreddsreservation i ett nätverk som stöder multicast-distribution. Multicast DNS (mDNS) kan användas för att lösa domän- eller värdnamn utan en dedikerad DNS-server genom att använda multicast.

Spridning

IP multicast används i stor utsträckning i företag, kommersiella börser och nätverk för leverans av multimediainnehåll. En vanlig företagsanvändning av IP multicast är för IPTV- applikationer som direktsänd tv-distribution och tv-sända företagsmöten. [ citat behövs ]

I besöksnäringen har IP-multicast blivit vanligt för IPTV- distribution på hotell, och inom detaljhandeln används IP-multicast i stor utsträckning för TV-distribution och videoreklamapplikationer.

Betal-TV-operatörer och vissa utbildningsinstitutioner med betydande studentbostäder på campus har distribuerat IP multicast för att leverera envägsströmmande media som höghastighetsvideo till stora grupper av mottagare. Dessutom har det förekommit vissa användningar av ljud- och videokonferenser med multicast-teknik. Dessa är betydligt mindre förekommande och är oftast förpassade till forsknings- och utbildningsinstitutioner, som ofta har en högre grad av nätverkskapacitet att hantera kraven. [ citat behövs ] Vissa tekniska konferenser och möten överförs med IP multicast. Tills nyligen [ när? ] många av sessionerna vid IETF-mötena levererades med hjälp av multicast. [ citat behövs ]

En annan användning av multicast inom campus och kommersiella nätverk är för fildistribution, särskilt för att leverera operativsystemavbildningar och uppdateringar till fjärrvärdar. Den viktigaste fördelen med multicast-startavbildningar jämfört med unicasting-startavbildningar är betydligt lägre nätverksbandbreddsanvändning.

IP multicast har också sett utrullning inom finanssektorn för applikationer som aktiekurser och tjat-n-holler- system. [ citat behövs ]

De stora tillståndskraven i routrar gör att applikationer som använder ett stort antal träd inte kan fungera medan de använder IP multicast. Ta närvaroinformation som ett exempel där varje person behöver behålla minst ett träd av sina abonnenter, om inte flera. Ingen mekanism har ännu demonstrerats som skulle tillåta IP-multicast-modellen att skala till miljontals avsändare och miljontals multicast-grupper och därför är det ännu inte möjligt att göra helt allmänna multicast-applikationer praktiska. [ citat behövs ]

RFC 3170 ( IP Multicast Applications: Challenges & Solutions ) ger en översikt över distributionsproblem.

Historia

Utveckling

IP multicasting utvecklades först av Steve Deering vid Stanford University, för vilket han fick IEEE Internet Award.

MBONE var en långvarig experimentell metod för att möjliggöra multicast mellan platser genom användning av tunnlar . Medan MBONE inte längre är i drift finns det ett förnyat intresse för att tunnla multicast-trafik igen för att göra tjänsten tillgänglig för ett brett spektrum av slutanvändare.

CastGate

CastGate var ett försök från forskargruppen ETRO-TELE vid Vrije Universiteit Brussel att använda IP multicast på Internet.

Även om multicast skulle ha tillåtit en internetanvändare att ta emot rich media och annat innehåll utan att lägga en stor börda på nätet, var det fortfarande otillgängligt för de flesta internetanvändare. CastGate-projektet försökte fixa detta genom att tillåta slutanvändare att ansluta via en automatiskt konfigurerad IP-tunnel över nätverk som inte stödde IP multicast. Tanken var att om fler användare har multicast-kapacitet, skulle fler innehållsleverantörer se fördelen med att streama innehåll över multicast. Förhoppningen var att om tillräckligt många innehållsleverantörer och användare använde den här tjänsten, så skulle fler internetleverantörer möjliggöra IP-multicast för sina kunder.

CastGate levererade en mjukvaruklient för både Microsoft Windows och Linux för att ansluta till CastGate-tunnelnätverket. Den levererade också verktyg för att lägga till tunnelservrar och verktyg för att ta emot Session Announcement Protocol från multicast-nätverket med video- och ljudströmmar.

Projektet upprätthöll en webbplats under 2007.

Kommersiell utplacering

Från och med 2005 började BBC uppmuntra Storbritannien-baserade internetleverantörer att använda multicast-adresserbara tjänster i sina nätverk genom att tillhandahålla BBC Radio med högre kvalitet än vad som är tillgängligt via deras unicast -adresserade tjänster. Detta har också stötts av en mängd olika kommersiella radionätverk, inklusive BBC , GCap Media , EMAP och Virgin Radio .

De tyska public service-företagen ARD och ZDF och det fransk-tyska nätverket Arte erbjuder sina TV-program multicasted på flera nätverk. Den österrikiska internetleverantören Telekom Austria erbjuder sina kunder med digital subscriber line (DSL) en TV-set-top-box som använder multicast-adressering för att ta emot TV- och radiosändningar. I Tyskland erbjuder T-Home, ett varumärke från Deutsche Telekom , en liknande tjänst.

IP multicast programvara

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=IP_multicast&oldid=1133776893 "