Indledning
Vi har talt om IP Multicast. I denne måned vil jeg begynde at dække PIM Sparse Mode. Tidligere artikler, der kan være af interesse:
- Protokollerne for IP Multicast
- PIM Dense Mode
Sparse Versus Dense Mode
Husk, at PIM Dense Mode bruges (i princippet), når der ønskes multicast de fleste steder. Således oversvømmes de oprindelige multicast-pakker overalt, med beskæring, der afskærer trafikken til steder, der ikke har brug for multicast-feed. Indtil for nylig led PIM Dense Mode under periodisk re-flooding hvert tredje minut, men i 12.1(5)T blev dette afhjulpet med funktionen PIM Dense Mode State Refresh. Med denne funktion er PIM Dense Mode velegnet til simpel implementering af multicast. Især hvor der ikke er behov for den ekstra kontrol i PIM Sparse Mode, og hvor lejlighedsvis “utilsigtet” oversvømmelse ikke vil være særlig skadelig.
PIM Sparse Mode anvender en eksplicit anmodning, hvor en router skal bede om multicast-feed med en PIM Join-meddelelse. PIM Sparse Mode er indiceret, når du har brug for mere præcis kontrol, især når du har store mængder IP multicast-trafik i forhold til din båndbredde. PIM Sparse Mode skalerer ret godt, fordi pakker kun sendes derhen, hvor der er brug for dem, og fordi der kun oprettes tilstand i routere efter behov. På grund af dette er den blevet skrevet op som en Internet Experimental Protocol.
Den pris, vi betaler for denne ekstra kontrol, er en mild ekstra kompleksitet. PIM Sparse Mode bruger en særlig router kaldet Rendezvous Point (RP) til at forbinde flowkilden eller multicasttræet med den router, der ligger ved siden af den ønskede modtager. RP’et bruges typisk kun midlertidigt, som vi vil se nedenfor.
Der kan være forskellige RP’er for forskellige multicastgrupper, hvilket er en måde at fordele belastningen på. Der er normalt én RP pr. multicastgruppe. Redundans af RP’er er et avanceret emne, og det kræver lidt dybere ekspertise. En måde at gøre dette på er med MSDP-protokollen (evt. senere artikel i serien).
Husk, at en PIM Join-meddelelse sendes mod en Source (eller for PIM-SM, muligvis mod en RP), baseret på unicast-routing. Join-meddelelsen siger i realiteten “vi har brug for en kopi af multicasts herovre”. Den forbinder afsenderen af Join-meddelelsen og de mellemliggende routere med ethvert eksisterende multicast-træ, om nødvendigt helt tilbage til målet for Join-meddelelsen. En Prune-meddelelse siger i realiteten “vi har ikke længere brug for dette herovre”. En router, der modtager en Prune-meddelelse, ser, om den har andre grænseflader, der har brug for multicast-flowet, og hvis ikke, sender den sin egen Prune-meddelelse. En avanceret teknik er at sørge for en separat og måske anderledes kopi af unicast-routingoplysningerne kun til multicastformål. Dette muliggør “styring” af Join-meddelelserne. MultiProtocol BGP, MBGP, til multicast, er en måde at gøre dette på (mulig senere artikel i serien).
Basic Rendezvous Point (RP)
Vi har indtil videre set, at PIM-SM bruger et Rendezvous Point (RP) til at forbinde kilde og modtager. Der kan kun være ét RP pr. multicast-gruppe, og den enkleste implementering bruger ét RP til alle multicast-grupper.
Lad os gennemgå det grundlæggende i, hvordan RP’et bruges. Lad os antage, at kilden begynder at sende, før der er nogen modtagere. Hvis tingene sker omvendt, ændres nogle af detaljerne en smule, men det er ikke meget anderledes.
Så: Multicast-kilden begynder at sende. Som vi allerede har bemærket, er der ingen protokol eller noget som helst til registrering af kilder med IP multicast. Kilden sender, og det er op til naborouter(e) at gøre det rigtige. Med PIM-SM kender naborouteren til RP’en. (Hvordan den ved det, er et emne for en helt anden artikel.) Naborouteren videresender multicast-dataene til RP’en ved at indkapsle dem i en eller flere unicast Register-meddelelser. Normal routing leverer registret til RP’en. RP’en de-kapsler multicast-dataene og videresender kopier ned gennem et eventuelt Shared Tree (der er et på forhånd opbygget, hvis der var tilsluttet modtagere, før kilden begyndte at sende). Hvis der er modtagere (udgående grænseflader i Shared Tree-tilstand), sender RP’en en PIM Join tilbage til kilden. Dette forbinder kilden med RP’en med et kildetræ, (S, G) Shortest Path Tree (SPT). Når RP’en modtager multicasts langs dette SPT, sender den en Register-Stop for at fortælle routeren ved kilden, at den skal holde op med at sende Register-pakker. Grunden til denne adfærd er, at der ikke går multicast-pakker tabt, hvis der allerede er modtagere til stede.
I øvrigt, hvis der ikke er nogen modtagere til stede, sendes Register-Stop-meddelelsen. Når der så efterfølgende dukker en modtager op (IGMP til naborouter, PIM Join fra naborouter tilbage til RP), så sender RP’en PIM Join til kilden på det tidspunkt.
Den følgende figur antager, at der er en kilde og aktive modtagere (ikke vist). Den viste modtager sender en IGMP-rapport til router D. Router D sender derefter en PIM Join til RP’en. Da der er andre modtagere, er RP allerede tilsluttet til Source Tree (vist med blå farve) og modtager multicaststrømmen. Den sender Source Tree-flow-pakkerne videre via Shared Tree, vist med grønt.
Nu har vi altså pakkerne, der går fra Source til RP langs Source Tree (Shortest Path Tree, SPT) og fra RP til modtageren langs Shared Tree. Når den samlede (*, G) pakkebitrate (fra alle kilder) overstiger en tærskelværdi i Kbps, udløser dette, at den router, der er nærmest modtageren, forsøger at tilslutte sig Source Tree. Den sender en Join til multicast-strømmens kilde. Bemærk, at den tidligere Join, som den sendte, var mod RP’en. Join-signalet mod kilden går router for router mod kilden, indtil det støder på en router, der allerede er med i Source Tree. Dette tilføjer routeren i nærheden af modtageren til Kildetræet. Når der rent faktisk modtages en pakke i dette træ, sendes der en Prune til RP’en. I realiteten “tak, men jeg får nu min multicast wholesale, ikke retail”, da denne proces skærer RP’en ud i midten.
Den følgende figur viser, hvordan dette fungerer. De røde pile øverst til venstre viser Join mod kilden. Dette får det øverste blå flow i gang, pakker, der videresendes langs Source Tree. De nederste højre røde pile er så Prunes, da Shared Tree flowet ikke længere er nødvendigt (vist som grøn stiplet linje). Bemærk, at Source Tree-pakkerne ankommer til modtageren ad en mere direkte vej, generelt med lavere latenstid.
Vi kontrollerer i øvrigt tærsklen. Den er konfigurerbar. Standardværdien er nul Kbps: Modtag en pakke, og skift over til Source Tree. Hvis vi har mange kilder til en bestemt multicast-gruppe (tænk konferenceopkald, VoIP), så er der en (S, G) Source Tree-post for hver enkelt. Hvis vi indstiller tærsklen til aldrig at blive aktiveret, går alle pakker gennem RP’en (lidt ligesom en bro til konferenceopkald) og bruger kun (*, G) Shared Tree. Tærsklen bruges også til switchback såvel som switchover. Kildetræer med lav hastighed (S, G) skiftes tilbage til det delte træ. Trafikmængden kontrolleres hvert minut.
Hvis en modtager ønsker at tilslutte sig, og dens naborouter er på SPT (Source Tree), så kopieres den udgående grænseflade Shared Tree-post til Source Tree-posten, hvilket beskytter mod at skulle sende trafik til RP og derefter “tilbage” til routeren på SPT.
I øvrigt undrer du dig måske over, hvad formålet er med at have RP her? På grund af tærskelmekanismen giver RP’en os en måde at bruge det delte træ på og kontrollere den eksplosive oprettelse af tilstandsinformationer i routere, hvis mange modtagere tilmelder sig på samme tid.
Delte versus kildetræer
PIM Sparse Mode (PIM-SM) kan bruge både delte træer (der passerer gennem RP’en) og kildetræer (til effektiv direkte levering langs den “korteste” vej fra kilde til modtager). Typisk kan den bruge begge dele. Hvis effektiv levering er mindre vigtig for dig, og det er vigtigere at mindske mængden af tilstandsinformationer, som routerne opbevarer, kan PIM konfigureres til kun at bruge et Shared Tree.
Når en PIM-SM-router modtager en multicast-pakke, kontrollerer den Source Tree for den pågældende kildeadresse og multicast-gruppe (destinationsadresse). Hvis der ikke er nogen post, kontrollerer den derefter for en Shared Tree (*, G)-post for multicastgruppen. Hvis der er poster til stede for begge træer, fortæller den indgående grænseflade routeren, hvilket træ den skal bruge. Hvis begge træer har den samme indgående grænseflade, forhindrer RP-bitten for en (S, G)-post dobbeltpakker: dette indikerer, at RPF-grænsefladen ligger langs det fælles træ.
For en multicast-strøm med mindst én aktiv modtager vil stien mellem kilden og RP’en være en del af Source Tree (kilde-træet). (Bemærk, at “stien mellem” er lidt vagt her, jeg forsøger at holde mig fra at give for mange detaljer.)
Shared Tree-poster vil forbinde RP’en med nogle af modtagerne. RPF-grænsefladen for det (*, G) delte træ er grænsefladen i RP’ens retning, ikke multicastgruppens kilde. Derfor er der mulighed for, at (S, G) Source og (*, G) Shared Trees har forskellige RPF-interfaces.
Posterne i Shared Tree (*, G) viser interfaces, hvor der er modtaget et join til RP’en, eller interfaces med direkte tilsluttede gruppemedlemmer (konfigureret eller IGMP modtaget). Posterne i Source Tree (S, G) viser, hvor der blev modtaget en Join eller en Prune eller et Register.
Konfigurering af PIM Sparse Mode
Den grundlæggende del af det, du har brug for, er:
ip multicast-routing
interface ethernet 0
ip-adresse 10.1.1.1.1 255.255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip adresse 10.1.2.1 255.255.255.255.0
ip pim sparse-mode
Du skal også fortælle hver router RP’en, enten for alle grupper eller for udvalgte grupper (ved hjælp af adgangslister til at angive hvilken RP for hvilke grupper). Dette kan gøres statisk med:
ip pim rp-address 1.2.3.4
Vi ser på de andre muligheder for at administrere RP i næste artikel.
I konklusion
Næste måned ser vi på de forskellige måder at arbejde med Rendezvous Points på. Vi berører måske også let et par andre mere avancerede IP multicast-emner.