Inleiding
We hebben het gehad over IP Multicast. Deze maand ga ik beginnen met het behandelen van PIM Sparse Mode. Eerdere artikelen die van belang kunnen zijn:
- De protocollen van IP Multicast
- PIM Dense Mode
Sparse Versus Dense Mode
Houd in gedachten dat PIM Dense Mode (in principe) wordt gebruikt wanneer de multicast op de meeste locaties gewenst is. Dus initiële multicast pakketten worden overal overspoeld, met snoeien dat verkeer afsnijdt naar locaties die de multicast voeding niet nodig hebben. Tot voor kort had PIM Dense Mode last van periodieke re-flooding om de 3 minuten, maar in 12.1(5)T, heeft de PIM Dense Mode State Refresh eigenschap dit verholpen. Met deze eigenschap is PIM Dense Mode aantoonbaar geschikt voor eenvoudige implementatie van multicast. Vooral waar de extra controle van PIM Sparse Mode niet nodig is, en waar af en toe “per ongeluk” flooding niet erg schadelijk zou zijn.
PIM Sparse Mode gebruikt een expliciete verzoekbenadering, waarbij een router om de multicast feed moet vragen met een PIM Join bericht. PIM Sparse Mode is aangewezen wanneer u preciezere controle nodig hebt, vooral wanneer u grote volumes IP multicast-verkeer hebt in verhouding tot uw bandbreedte. PIM Sparse Mode schaalt vrij goed, omdat pakketten alleen daarheen gaan waar ze nodig zijn, en omdat het alleen toestand in routers aanmaakt als dat nodig is. Daarom is het opgeschreven als een Internet Experimental Protocol.
De prijs die we betalen voor deze extra controle is een milde extra complexiteit. PIM Sparse Mode gebruikt een speciale router genaamd een Rendezvous Point (RP) om de flow source of multicast tree te verbinden met de router naast de wannabe ontvanger. De RP wordt meestal slechts tijdelijk gebruikt, zoals we hieronder zullen zien.
Er kunnen verschillende RP’s zijn voor verschillende multicast groepen, wat één manier is om de belasting te spreiden. Meestal is er één RP per multicast groep. Redundantie van RP’s is een geavanceerd onderwerp, en vereist een beetje diepere kennis. Een manier om dit te doen is met het MSDP protocol (mogelijk later artikel in de serie).
Houd in gedachten dat een PIM Join bericht wordt verzonden naar een Source (of voor PIM-SM, mogelijk naar een RP), gebaseerd op unicast routing. Het Join-bericht zegt in feite “we hebben een kopie nodig van de multicasts hier”. Het verbindt de verzender van de Join en tussenliggende routers met elke bestaande multicast boom, helemaal terug naar het doel van de Join indien nodig. Een Prune bericht zegt in feite “we hebben dit hier niet langer nodig”. Een router die een Prune ontvangt kijkt of hij nog andere interfaces heeft die de multicast stroom nodig hebben, en zo niet, stuurt hij zijn eigen Prune bericht. Een geavanceerde techniek is om een aparte en wellicht andere kopie van de unicast-routeringsinformatie alleen voor multicast-doeleinden te regelen. Dit maakt “sturen” van de Join berichten mogelijk. MultiProtocol BGP, MBGP, voor multicast, is een manier om dit te doen (mogelijk later artikel in de serie).
Basic Rendezvous Point (RP)
We hebben tot nu toe gezien dat PIM-SM gebruik maakt van een Rendezvous Point (RP), om bron en ontvangers met elkaar te verbinden. Er kan slechts één RP per multicast groep zijn, en de eenvoudigste implementatie gebruikt één RP voor alle multicast groepen.
Laten we de basisprincipes doornemen van hoe de RP wordt gebruikt. Laten we aannemen dat de bron begint te zenden voordat er ontvangers zijn. Als het andersom gebeurt, veranderen sommige details enigszins, maar het is niet erg verschillend.
Dus: de multicast-bron begint met zenden. Zoals we al hebben opgemerkt, is er geen protocol of iets voor het registreren van bronnen met IP multicast. De bron zendt en het is aan de naburige router(s) om het juiste te doen. Met PIM-SM weet de naburige router van de RP. (Hoe hij dat weet is een onderwerp voor een heel apart artikel.) De naburige router stuurt de multicast data door naar de RP door deze in te kapselen in een unicast Register bericht of berichten. Normale routing levert het Register af bij de RP. De RP de-encapsuleert de multicast en stuurt kopieën door naar een Shared Tree (er is er een vooraf gebouwd als er ontvangers waren aangesloten voordat de bron begon te zenden). Als er ontvangers zijn (Shared Tree state uitgaande interfaces), zendt de RP een PIM Join terug naar de bron. Dit verbindt de Source met de RP met een Source Tree, de (S, G) Shortest Path Tree (SPT). Zodra de RP multicasts langs deze SPT ontvangt, zendt hij een Register-Stop om de router bij de Source te vertellen te stoppen met het zenden van Register-pakketten. De reden voor dit gedrag is dat er geen multicast-pakketten verloren gaan, als er al ontvangers aanwezig zijn.
Aan de andere kant, als er geen ontvangers aanwezig zijn, wordt het Register-Stop-bericht verzonden. Als er vervolgens een ontvanger opduikt (IGMP naar buurrouter, PIM Join van buurrouter terug naar RP), dan stuurt de RP op dat moment de PIM Join naar de bron.
De volgende figuur gaat ervan uit dat er een bron is en actieve ontvangers (niet afgebeeld). De getoonde ontvanger zendt een IGMP Report naar router D. Router D zendt vervolgens een PIM Join naar de RP. Aangezien er andere ontvangers zijn, is de RP al toegetreden tot de Source Tree (in blauw weergegeven) en ontvangt de multicast stroom. Het geeft de Source Tree flow pakketten door via de Shared Tree, weergegeven in groen.
Wel, nu hebben we de pakketten die van de bron naar de RP gaan langs de Source Tree (Shortest Path Tree, SPT), en van de RP naar de ontvanger langs de Shared Tree. Wanneer de geaggregeerde (*, G) pakket bitsnelheid (van alle bronnen) een drempel in Kbps overschrijdt, triggert dit de router het dichtst bij de ontvanger om te proberen lid te worden van de Source Tree. Hij zendt een Join naar de bron van de multicast-stroom. Merk op dat de vorige Join naar de RP ging. De Join naar de bron gaat router voor router naar de bron totdat deze een router tegenkomt die al in de Source Tree zit. Dit voegt de router dichtbij de ontvanger toe aan de Source Tree. Wanneer een pakket langs die boom wordt ontvangen, wordt een Prune naar de RP gestuurd. In feite, “bedankt, maar ik krijg nu mijn multicast wholesale, niet retail”, omdat dit proces de RP in het midden wegsnijdt.
De volgende figuur laat zien hoe dit werkt. De rode pijlen linksboven tonen de Join naar de Source. Dit brengt de bovenste blauwe stroom op gang, pakketten die worden doorgestuurd langs de Source Tree. De rode pijlen rechtsonder zijn dan de Prunes, aangezien de Shared Tree flow niet langer nodig is (weergegeven als groene stippellijn). Merk op dat de Source Tree pakketten via een directer pad bij de ontvanger aankomen, in het algemeen met een lagere latency.
Over het algemeen controleren we de drempel. Deze is configureerbaar. Standaard is nul Kbps: ontvang één pakket, en schakel over naar Source Tree. Als we veel bronnen hebben voor een bepaalde multicast groep (denk aan conference call, VoIP), dan is er een (S, G) Source Tree entry voor elke bron. Als we de drempel op nooit activeren zetten, dan gaan alle pakketten door de RP (zoiets als een conference call bridge), waarbij alleen de (*, G) Shared Tree wordt gebruikt. De drempel wordt ook gebruikt voor zowel switchback als switchover. Low rate (S, G) Source Trees worden teruggeschakeld naar de Shared Tree. Het verkeersvolume wordt elke minuut gecontroleerd.
Als een ontvanger wil toetreden, en zijn buurrouter is op de SPT (Source Tree), dan wordt de uitgaande interface Shared Tree entry gekopieerd naar de Source Tree entry, die beschermt tegen het moeten verzenden van verkeer naar de RP en dan “terug” naar de router op de SPT.
Maar je kunt je afvragen, wat is het nut van de RP hier? Vanwege het drempelmechanisme geeft de RP ons een manier om de Shared Tree te gebruiken, en de explosieve aanmaak van statusinformatie in routers te controleren als veel ontvangers zich tegelijkertijd aansluiten.
Shared Versus Source Trees
PIM Sparse Mode (PIM-SM) kan zowel Shared Trees (die door de RP gaan) als Source Trees (voor efficiënte directe levering langs het “kortste” pad van bron naar ontvanger) gebruiken. Gewoonlijk kan het beide gebruiken. Als efficiënte aflevering minder belangrijk voor u is, en het verminderen van de hoeveelheid statusinformatie die door de routers wordt bijgehouden belangrijker is, dan kan PIM worden geconfigureerd om alleen een gedeelde boom te gebruiken.
Wanneer een PIM-SM router een multicast pakket ontvangt, controleert hij de Source Tree voor dat specifieke bronadres en multicast groep (bestemmings) adres. Als er geen vermelding aanwezig is, controleert hij vervolgens of er een Shared Tree (*, G)-vermelding voor de multicastgroep is. Als er voor beide trees entries aanwezig zijn, vertelt de inkomende interface de router welke tree hij moet gebruiken. Als beide trees dezelfde inkomende interface hebben, voorkomt de RP-bit voor een (S, G) entry dubbele pakketten: dit geeft aan dat de RPF-interface langs de Shared Tree ligt.
Voor een multicast-stroom met ten minste één actieve ontvanger, zal het pad tussen de bron en de RP deel uitmaken van de Source Tree. (Merk op dat “het pad tussen” hier een beetje vaag is, ik probeer niet te veel details te geven.)
Shared Tree entries zullen de RP verbinden met sommige van de ontvangers. De RPF interface voor de (*, G) Shared Tree is de interface in de richting van de RP, niet de multicast groepsbron. Daarom is er de mogelijkheid dat de (S, G) Source en (*, G) Shared Trees verschillende RPF interfaces hebben.
De Shared Tree (*, G) entries tonen interfaces waar een join naar de RP werd ontvangen, of interfaces met direct verbonden groepsleden (geconfigureerd of IGMP ontvangen). De Source Tree (S, G) entries laten zien waar een Join of een Prune of een Register werd ontvangen.
Configuring PIM Sparse Mode
Het basisgedeelte van wat je nodig hebt is:
ip multicast-routing
interface ethernet 0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip adres 10.1.2.1 255.255.255.0
ip pim sparse-mode
Je moet ook elke router de RP vertellen, ofwel voor alle groepen of voor geselecteerde groepen (met behulp van toegangslijsten om te specificeren welke RP voor welke groepen). Dit kan statisch gedaan worden met:
ip pim rp-address 1.2.3.4
We zullen de andere opties om RP’s te beheren in het volgende artikel bekijken.
In Conclusie
Volgende maand zullen we de verschillende manieren om met Rendezvous Points te werken bekijken. We kunnen ook een paar andere meer geavanceerde IP multicast onderwerpen lichtjes aanstippen.