Inledning
Vi har talat om IP Multicast. Den här månaden ska jag börja behandla PIM Sparse Mode. Tidigare artiklar som kan vara av intresse:
- The Protocols of IP Multicast
- PIM Dense Mode
Sparse Versus Dense Mode
Håller i minnet att PIM Dense Mode används (i princip) när multicast önskas på de flesta platser. De första multicastpaketen översvämmas således överallt, och genom beskärning skärs trafiken av till platser som inte behöver multicastmatningen. Fram till nyligen drabbades PIM Dense Mode av periodisk återflödning var tredje minut, men i 12.1(5)T har funktionen PIM Dense Mode State Refresh (Uppdatering av tillstånd i PIM Dense Mode) lindrat detta. Med den här funktionen kan man hävda att PIM Dense Mode är lämpligt för enkel implementering av multicast. Särskilt där den extra kontrollen i PIM Sparse Mode inte behövs och där en tillfällig ”oavsiktlig” översvämning inte skulle vara särskilt skadlig.
PIM Sparse Mode använder en metod med uttrycklig begäran, där en router måste be om multicastmatningen med ett PIM Join-meddelande. PIM Sparse Mode indikeras när du behöver mer exakt kontroll, särskilt när du har stora volymer av IP multicast-trafik i förhållande till din bandbredd. PIM Sparse Mode skalar ganska bra, eftersom paketen bara går dit de behövs och eftersom den skapar tillstånd i routrarna bara vid behov. På grund av detta har det skrivits upp som ett Internet Experimental Protocol.
Priset vi betalar för denna extra kontroll är mild extra komplexitet. PIM Sparse Mode använder en speciell router som kallas Rendezvous Point (RP) för att ansluta flödeskällan eller multicastträdet till routern bredvid den önskade mottagaren. RP används vanligtvis bara tillfälligt, vilket vi kommer att se nedan.
Det kan finnas olika RP:er för olika multicastgrupper, vilket är ett sätt att sprida belastningen. Det finns vanligtvis en RP per multicastgrupp. Redundans av RP:s är ett avancerat ämne och kräver lite djupare kunskaper. Ett sätt att göra detta är med MSDP-protokollet (eventuell senare artikel i serien).
Hålls i minnet att ett PIM Join-meddelande skickas mot en källa (eller för PIM-SM, eventuellt mot en RP), baserat på unicast-routing. Join-meddelandet säger i själva verket ”vi behöver en kopia av multicasts här borta”. Det ansluter avsändaren av Join och mellanliggande routrar till varje befintligt multicastträd, hela vägen tillbaka till målet för Join om det är nödvändigt. Ett Prune-meddelande säger i praktiken ”vi behöver inte längre detta här borta”. En router som tar emot ett Prune-meddelande ser om den har några andra gränssnitt som kräver multicastflödet, och om så inte är fallet skickar den sitt eget Prune-meddelande. En avancerad teknik är att ordna en separat och kanske annorlunda kopia av unicast-routinginformationen enbart för multicaständamål. Detta gör det möjligt att ”styra” Join-meddelandena. MultiProtocol BGP, MBGP, för multicast, är ett sätt att göra detta (möjlig senare artikel i serien).
Basic Rendezvous Point (RP)
Vi har hittills sett att PIM-SM använder en Rendezvous Point (RP), för att koppla ihop källa och mottagare. Det kan bara finnas en RP per multicastgrupp, och den enklaste implementeringen använder en RP för alla multicastgrupper.
Låt oss gå igenom grunderna för hur RP används. Låt oss anta att källan börjar sända innan det finns några mottagare. Om saker och ting sker tvärtom ändras vissa detaljer något, men det är inte särskilt annorlunda.
Så: multicastkällan börjar sända. Som vi redan har noterat finns det inget protokoll eller något för att registrera källor med IP multicast. Källan sänder och det är upp till grannroutern/routerna att göra rätt. Med PIM-SM känner grannroutern till RP. (Hur den vet är ett ämne för en helt annan artikel.) Grannroutern vidarebefordrar multicastdata till RP genom att kapsla in den i ett eller flera unicast Register-meddelanden. Normal routning levererar registret till RP. RP avkapslar multicasten och vidarebefordrar kopior nedåt i ett eventuellt delat träd (det finns ett förbyggt om det fanns mottagare som anslöt sig innan källan började sända). Om det finns mottagare (utgående gränssnitt med delat trädtillstånd) skickar RP en PIM Join tillbaka till källan. Detta ansluter källan till RP med ett källträd, (S, G) Shortest Path Tree (SPT). När RP tar emot multicasts längs detta SPT skickar den en Register-Stop för att tala om för routern vid källan att sluta skicka Register-paket. Anledningen till detta beteende är att inga multicastpaket går förlorade om det redan finns mottagare närvarande.
Förresten, om det inte finns några mottagare närvarande skickas meddelandet Register-Stop. När en mottagare sedan dyker upp (IGMP till grannroutern, PIM Join från grannroutern tillbaka till RP) skickar RP PIM Join till källan vid den tidpunkten.
Följande figur förutsätter att det finns en källa och aktiva mottagare (visas inte). Den visade mottagaren skickar en IGMP-rapport till router D. Router D skickar sedan en PIM Join till RP. Eftersom det finns andra mottagare är RP redan ansluten till källträdet (visas i blått) och tar emot multicastflödet. Den skickar vidare flödespaketen från källträdet via det delade trädet, som visas i grönt.
Ja, nu har vi paketen som går från källan till RP längs källträdet (Shortest Path Tree, SPT), och från RP till mottagaren längs det delade trädet. När den aggregerade (*, G) paketbithastigheten (från alla källor) överskrider ett tröskelvärde i Kbps, triggar detta routern närmast mottagaren att försöka ansluta sig till Källträdet. Den skickar en Join till multicastflödets källa. Observera att den tidigare Join som den skickade var mot RP. Join mot källan går router för router mot källan tills den stöter på en router som redan ingår i källträdet. Detta innebär att routern nära mottagaren läggs till i Källträdet. När ett paket faktiskt tas emot längs det trädet skickas en Prune till RP. I själva verket ”tack, men jag får nu min multicast i grossistledet, inte i detaljhandeln”, eftersom denna process skär bort RP i mitten.
Följande figur visar hur detta fungerar. De röda pilarna uppe till vänster visar Join mot källan. Detta får igång det övre blå flödet, paket som vidarebefordras längs Source Tree. De nedre högra röda pilarna är sedan Prunes, eftersom Shared Tree-flödet inte längre behövs (visas som grön streckad linje). Observera att källträdspaketen anländer till mottagaren längs en mer direkt väg, i allmänhet med lägre latenstid.
Förresten kontrollerar vi tröskelvärdet. Det är konfigurerbart. Standardvärdet är noll Kbps: ta emot ett paket och växla över till Source Tree. Om vi har många källor för en viss multicastgrupp (tänk konferenssamtal, VoIP) finns det en (S, G) Source Tree-post för varje källa. Om vi ställer in tröskeln så att den aldrig aktiveras går alla paket genom RP (ungefär som en brygga för konferenssamtal) och använder endast (*, G) Shared Tree (delat träd). Tröskelvärdet används också för switchback samt switchover. Source Trees med låg hastighet (S, G) växlas tillbaka till Shared Tree. Trafikvolymen kontrolleras varje minut.
Om en mottagare vill ansluta sig och dess grannrouter befinner sig på SPT (Source Tree), kopieras posten för det utgående gränssnittet Shared Tree till posten för Source Tree, vilket skyddar mot att behöva skicka trafik till RP och sedan ”tillbaka” till routern på SPT.
Förresten kanske du undrar, vad är poängen med att ha RP här? På grund av tröskelmekanismen ger RP oss ett sätt att använda det delade trädet och kontrollera det explosiva skapandet av tillståndsinformation i routrar om många mottagare ansluter sig samtidigt.
Shared Versus Source Trees
PIM Sparse Mode (PIM-SM) kan använda både Shared Trees (som passerar genom RP) och Source Trees (för effektiv direktleverans längs den ”kortaste” vägen från källa till mottagare). Vanligtvis kan den använda båda. Om effektiv leverans är mindre viktigt för dig, och det är viktigare att minska mängden tillståndsinformation som hålls av routrarna, kan PIM konfigureras för att bara använda ett delat träd.
När en PIM-SM-router tar emot ett multicastpaket kontrollerar den Source Tree för den specifika källadressen och multicastgruppens (destinations)adress. Om det inte finns någon post kontrollerar den sedan om det finns en post i Shared Tree (*, G) för multicastgruppen. Om det finns poster för båda träden talar det inkommande gränssnittet om för routern vilket träd som ska användas. Om båda träden har samma inkommande gränssnitt förhindrar RP-biten för en (S, G)-post dubbla paket: detta indikerar att RPF-gränssnittet ligger längs det delade trädet.
För ett multicastflöde med minst en aktiv mottagare kommer vägen mellan källan och RP att vara en del av källträdet. (Observera att ”vägen mellan” är lite vagt här, jag försöker hålla mig borta från att ge för mycket detaljer.)
Poster i det delade trädet kommer att ansluta RP till några av mottagarna. RPF-gränssnittet för (*, G) Shared Tree är gränssnittet i RP:s riktning, inte multicastgruppens källa. Därför finns det en möjlighet att (S, G) Source och (*, G) Shared Trees har olika RPF-gränssnitt.
Posterna för Shared Tree (*, G) visar gränssnitt där en anslutning till RP togs emot, eller gränssnitt med direktanslutna gruppmedlemmar (konfigurerade eller IGMP mottagna). Posterna för Source Tree (S, G) visar var en Join eller en Prune eller ett Register togs emot.
Konfigurera PIM Sparse Mode
Den grundläggande delen av det du behöver är:
ip multicast-routing
interface ethernet 0
ip address 10.1.1.1.1 255.255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.255.0
ip pim sparse-mode
Du måste också tala om för varje router vilken RP det är, antingen för alla grupper eller för utvalda grupper (med hjälp av åtkomstlistor för att specificera vilken RP som ska gälla för vilka grupper). Detta kan göras statiskt med:
ip pim rp-address 1.2.3.4
Vi kommer att titta på de andra alternativen för att hantera RP i nästa artikel.
I slutsats
Nästa månad tar vi en titt på de olika sätten att arbeta med Rendezvous Points. Vi kan också lätt beröra ett par andra mer avancerade IP multicast-ämnen.