En kort intro til IPv6-multicast
Som langt framme på IPv6, og del av UNINETTs nettverk (som igjen er del av M6bone) er IPv6-multicast en ting som er relativt naturlig for Samfundet å implementere, ikke minst ettersom det finnes interessant innhold på IPv4-multicast som kan være interessant å pumpe inn i kvadratsky-en. Det er imidlertid mange begreper som skal på plass og kan skape litt forvirring, så dette er en kort introduksjon til de viktigste akronymene.
Mye av det som sies gjelder også IPv4-multicast, men hovedfokuset er på IPv6.
Hovedtyper multicast
Det er to hovedtyper multicast:
- ASM: Any Source Multicast. I teorien «mange-til-mange»-multicast, selv om én sender er det vanligste i praksis. Det velges et RP (se under) for hver ASM-gruppe, og alle som vil sende trafikk til gruppen sender den til RP-et, som så distribuerer den videre. Nesten all «klassisk» multicast er ASM.
- SSM: Single Source Multicast. Den moderne og sikrere varianten, men foreløpig lite brukt. Multicastgruppene i SSM identifiseres ikke bare ved gruppeadressen, men også ved sourceadressen. SSM trenger derfor ikke noe RP, og bruker det da heller ikke. SSM-grupper i IPv6 har et eget prefiks, ff3e::/16.
Multicast-rutingprotokoller
- PIM-SM: Protocol Independent Multicast, Sparse Mode. («Protocol Independent» betyr her at den virker uavhengig av unicast-rutingprotokoll i bruk.) PIM-SM er den vanligste rutingprotokollen for multicast; de vanlige rutingprotokollene som OSPF, IS-IS og BGP håndterer kun unicast (men se under for MBGP). Rutere snakker PIM-SM med hverandre, og melder sin interesse (eller slutt på interesse) for gitte multicastgrupper.
- PIM-DM: PIM, Dense Mode. Som PIM-SM, men defaulten er at alle grupper sendes. Sjelden i bruk, og da bare i private kjernenett o.l. (type, om du distribuerer IPTV i nettet ditt, kan du like gjerne sende alle kanalene til alle corerouterne selv om det ikke tilfeldigvis er noen som ser på en gitt i den aktuelle landsdelen akkurat nå).
- MLD og IGMP: Multicast Listener Discovery, Internet Group Messaging Protocol. Har en tilvarende funksjon som PIM-SM, men går fra klient til lokal ruter (klienter snakker ikke PIM-SM). MLD brukes i IPv6 og IGMP brukes i IPv4; de er stort sett analoge.
- MLD snooping, IGMP snooping: Ethernet har ikke i utgangspunktet en forståelse av multicast, så om én klient på lokalnettet har meldt sin interesse for en gitt gruppe, vil ruteren broadcaste den ut på hele segmentet. MLD/IGMP snooping er et hack for å slippe å broadcaste trafikk til klienter som ikke er interessert iden, og innebærer at switchen lytter etter MLD/IGMP-pakker som går forbi for å se hvilke porter den trenger å sende multicasten videre til. (Dette kan brekke hardt dersom det brukes andre måter enn MLD/IGMP å melde seg inn i multicastgrupper på, for eksempel PIM! Cisco-switcher har PIM-snooping som en del av IGMP-snooping, men HP-switchene våre har ikke.) MLD/IGMP snooping er ikke standardisert, men brukes likevel i vid utstrekning.
- MBGP: Multiprotocol Border Gateway Protocol (ikke Multicast BGP, som en del tror). BGP støtter i utgangspunktet kun IPv4 unicast. MBGP er en utvidelse som støtter flere adressefamilier; opprinnelig kun IPv4 multicast, men i seinere tid også IPv6 unicast og altså IPv6 multicast. MBGP er imidlertid ikke en fullverdig multicastprotokoll; den utveksler ikke informasjon om multicastadresser overhodet. Man kan imidlertid bruke MBGP til å danne en alternativ unicast-rutingtabell, som brukes til å finne korteste vei til RP (se under) samt for RPF (return path-filtering, altså å redusere muligheten til å spoofe IP-pakker). Dette kan være nødvendig fordi unicast- og multicast-rutingtopologi ikke nødvendigvis er lik (ikke alle unicast-rutere støtter multicast).
Rendezvous Point (RP) og PIM-join
I ASM kan du ha flere sendere, og det er derfor ikke åpenbart hvor en mottaker skal melde sin interesse for en gitt gruppe. Man forenkler problemet ved å definere at all trafikken skal innom ett sted, altså et Rendezvous Point (RP), som identifiserer en fysisk host eller ruter som er villig til å ta på seg den oppgaven. Hver ASM-gruppe har sitt eget separate RP, men en host kan selvsagt være RP for så mange grupper man vil.
RPet kan enten settes manuelt i konfigurasjonen, velges i en protokoll som heter BSR (*Bootstrap Router*, evt. en eldre Cisco-proprietær protokoll kalt Auto-RP), eller være enkodet i multicastadressen (*Embedded-RP*). Det er selvsagt en fordel om RPet ligger et fornuftig sted nettverksmessig, gjerne nær kilden, så ikke trafikken må gå store omveier.
Klienter som vil melde sin interesse for en gitt gruppe, sender en PIM-join mot RP; hvilket interface dette skal ut på bestemmes av multicast-rutingtabellen (som inneholder unicastadresser!). Multicast-rutingtabellen er ofte identisk med den vanlige unicast-rutingtabellen, men kan være bygget opp helt separat, jfr. MBGP over.
I SSM er det bare én kilde, og alle vet hvilken den er. Derfor trenger man ikke noe RP; PIM-joinen sendes rett mot kilden.
Embedded-RP er en annen måte å slippe unna RP-konfigurering på, og spesifikk for IPv6. De laveste femten adressene i hvert /64 (xxxx::1 til. xxxx::f) er her spesielle, og er de eneste som kan være RP-adresser i Embedded-RP. Gruppeadressen konstrueres fra dette, slik at den inneholder informasjon om både prefiks og siste nibble, etter mønsteret ff7e:y40:aaaa:bbbb:cccc:dddd:gggg:hhhh, der RPet for gruppen implisitt blir aaaa:bbbb:cccc:dddd::y (gggg:hhhh kan brukes fritt til gruppe-ID). (Det er litt mer detaljer her, som scope og interface-ID, vi skal ignorere elegant i denne sammenhengen.) En multicastgruppe med Samfundets hovedruter 2001:700:300:1800::1 som implisitt RP kan med andre ord være f.eks. ff7e:140:2001:700:300:1800:dead:beef.
Lenker: Start
Epost: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2011-06-18 12:23 | Revisjon: 4 (historie, blame) | Totalt: 1904 kB | Rediger