Introduction
Olemme puhuneet IP Multicastista. Tässä kuussa alan käsitellä PIM Sparse Modea. Aiemmat artikkelit, jotka saattavat kiinnostaa:
- IP Multicastin protokollat
- PIM Dense Mode
Sparse Versus Dense Mode
Muistathan, että PIM Dense Modea käytetään (periaatteessa) silloin, kun monilähetystä halutaan useimmissa paikoissa. Näin ollen alkuperäiset multicast-paketit tulvivat kaikkialle, ja karsinta katkaisee liikenteen paikkoihin, jotka eivät tarvitse multicast-syöttöä. Viime aikoihin asti PIM Dense Mode kärsi säännöllisestä 3 minuutin välein tapahtuvasta uudelleen tulvimisesta, mutta 12.1(5)T:ssä PIM Dense Mode State Refresh -ominaisuus helpotti tätä. Tämän ominaisuuden ansiosta PIM Dense Mode soveltuu kiistatta multicastin yksinkertaiseen toteuttamiseen. Etenkin silloin, kun PIM Sparse Moden lisäkontrollia ei tarvita ja kun satunnainen ”vahingossa” tapahtuva tulviminen ei olisi kovin haitallista.
PIM Sparse Mode käyttää eksplisiittistä pyyntöä, jossa reitittimen on pyydettävä monilähetyssyöttöä PIM Join -sanomalla. PIM Sparse Mode -tilaa suositellaan silloin, kun tarvitaan tarkempaa ohjausta, erityisesti silloin, kun IP-multicast-liikenteen määrä on suuri kaistanleveyteen nähden. PIM Sparse Mode skaalautuu melko hyvin, koska paketit menevät vain sinne, missä niitä tarvitaan, ja koska se luo tilaa reitittimissä vain tarpeen mukaan. Tämän vuoksi se on kirjattu Internetin kokeelliseksi protokollaksi.
Hinta, jonka maksamme tästä ylimääräisestä valvonnasta, on lievä ylimääräinen monimutkaisuus. PIM Sparse Mode käyttää erityistä reititintä nimeltä Rendezvous Point (RP) yhdistämään virtauslähteen tai monilähetyspuun wannabe-vastaanottajan vieressä olevaan reitittimeen. RP:tä käytetään tyypillisesti vain tilapäisesti, kuten näemme jäljempänä.
Eri monilähetysryhmille voi olla eri RP:t, mikä on yksi tapa jakaa kuormaa. Multicast-ryhmää kohti on yleensä yksi RP. RP:n redundanssi on edistynyt aihe, ja se vaatii hieman syvempää asiantuntemusta. Yksi tapa tehdä tämä on MSDP-protokolla (mahdollinen myöhempi artikkeli sarjassa).
Muistetaan, että PIM Join -viesti lähetetään lähteen (tai PIM-SM:ssä mahdollisesti RP:n) suuntaan unicast-reitityksen perusteella. Join-viesti sanoo käytännössä ”tarvitsemme kopion multicastista tänne”. Se yhdistää Join-sanoman lähettäjän ja väliin tulevat reitittimet kaikkiin olemassa oleviin monilähetyspuihin, tarvittaessa aina takaisin Join-sanoman kohteeseen asti. Prune-viestissä sanotaan käytännössä, että ”emme enää tarvitse tätä täällä”. Prune-viestin vastaanottava reititin katsoo, onko sillä muita monilähetysvirtaa tarvitsevia rajapintoja, ja jos ei ole, se lähettää oman Prune-viestinsä. Eräs kehittynyt tekniikka on järjestää erillinen ja mahdollisesti erilainen kopio unicast-reititystiedoista vain monilähetystarkoituksiin. Tämä mahdollistaa Join-viestien ”ohjaamisen”. MultiProtocol BGP, MBGP, monilähetystä varten on yksi tapa tehdä tämä (mahdollinen myöhempi artikkeli sarjassa).
Basic Rendezvous Point (RP)
Olemme tähän mennessä nähneet, että PIM-SM käyttää Rendezvous Pointia (RP), joka yhdistää lähteen ja vastaanottajat. Monilähetysryhmää kohti voi olla vain yksi RP, ja yksinkertaisin toteutus käyttää yhtä RP:tä kaikille monilähetysryhmille.
Keskustellaan RP:n käytön perusteet. Oletetaan, että lähde alkaa lähettää ennen kuin on yhtään vastaanottajaa. Jos asiat tapahtuvat toisinpäin, jotkin yksityiskohdat muuttuvat hieman, mutta se ei ole kovin erilaista.
Selvä: Multicast-lähde alkaa lähettää. Kuten olemme jo huomanneet, IP-multicastin lähteiden rekisteröintiin ei ole olemassa mitään protokollaa tai vastaavaa. Lähde lähettää ja on naapurireitittimen/-reitittimien tehtävä tehdä oikein. PIM-SM:ssä naapurireititin tietää RP:n. (Naapurireititin välittää monilähetystiedot RP:lle kapseloimalla ne yksilähetysrekisteriviestiin tai -viesteihin. Normaali reititys toimittaa Registerin RP:lle. RP purkaa monilähetyksen kapseloinnin ja välittää kopiot alaspäin mitä tahansa jaettua puuta pitkin (sellainen on valmiiksi rakennettu, jos vastaanottajia oli yhdistetty ennen kuin lähde alkoi lähettää). Jos vastaanottajia on (Shared Tree -tilan lähtevät rajapinnat), RP lähettää PIM Join -liitännän takaisin lähdettä kohti. Tämä yhdistää lähteen ja RP:n lähdepuulla, (S, G) lyhimmän polun puulla (SPT). Kun RP vastaanottaa monilähetyksiä tätä SPT:tä pitkin, se lähettää Register-Stopin kertoakseen lähteen reitittimelle, että sen on lopetettava Register-pakettien lähettäminen. Syy tähän käytökseen on se, että monilähetyspaketteja ei menetetä, jos vastaanottajia on jo paikalla.
Sivumennen sanoen, jos vastaanottajia ei ole paikalla, Register-Stop-sanoma lähetetään. Sitten kun vastaanotin myöhemmin ilmaantuu (IGMP naapurireitittimelle, PIM Join naapurireitittimeltä takaisin RP:lle), RP lähettää tuolloin PIM Join -viestin lähteelle.
Oheisessa kuvassa oletetaan, että on olemassa lähde ja aktiivisia vastaanottimia (ei kuvassa). Kuvassa oleva vastaanotin lähettää IGMP-raportin reitittimelle D. Reititin D lähettää sen jälkeen PIM Joinin RP:n suuntaan. Koska vastaanottajia on muitakin, RP on jo liittynyt lähdepuuhun (kuvassa sinisellä) ja vastaanottaa monilähetysvirtaa. Se välittää Source Tree -virran paketit eteenpäin Shared Tree -tiedonsiirtopuun kautta, joka näkyy vihreällä.
Nyt paketit kulkevat Source Tree -tiedonsiirtopuuta pitkin Source Tree -tiedonsiirtopuuta pitkin RP:lle ja Shared Tree -tiedonsiirtopuuta pitkin RP:ltä vastaanottajalle. Kun pakettien yhteenlaskettu (*, G) bittinopeus (kaikista lähteistä) ylittää kynnysarvon kilobittiä sekunnissa (Kbps), tämä käynnistää vastaanottajaa lähimpänä olevan reitittimen yrittämään liittyä lähdepuuhun. Se lähettää Join-viestin monilähetysvirran lähteelle. Huomaa, että aiempi Join-lähetys suuntautui RP:hen. Lähdettä kohti suuntautuva Join kulkee reititin reitittimeltä kohti lähdettä, kunnes se kohtaa reitittimen, joka on jo mukana lähdepuussa. Tämä lisää vastaanottajan lähellä olevan reitittimen lähdepuuhun. Kun paketti todella vastaanotetaan tätä puuta pitkin, RP:n suuntaan lähetetään Prune. Käytännössä ”kiitos, mutta nyt saan multicastin tukkuna, en vähittäismyyntinä”, koska tämä prosessi leikkaa RP:n pois keskeltä.
Seuraavassa kuvassa näytetään, miten tämä toimii. Vasemmalla ylhäällä olevat punaiset nuolet osoittavat liittymisen kohti lähdettä. Tämä saa ylimmän sinisen virtauksen käyntiin, paketit lähetetään eteenpäin Source Tree -puuhun. Oikealla alhaalla olevat punaiset nuolet ovat sitten Prunes, koska Shared Tree -virtaa ei enää tarvita (näkyy vihreänä katkoviivana). Huomaa, että Source Tree -paketit saapuvat vastaanottajalle suorempaa reittiä pitkin, yleensä pienemmällä viiveellä.
Hallitsemme muuten kynnysarvoa. Se on konfiguroitavissa. Oletusarvo on nolla Kbps: vastaanotetaan yksi paketti, ja siirrytään Source Treeyn. Jos meillä on monta lähdettä tietylle monilähetysryhmälle (ajattele neuvottelupuhelua, VoIP), jokaiselle on (S, G) Source Tree -merkintä. Jos asetamme kynnysarvon niin, että se ei koskaan aktivoidu, kaikki paketit kulkevat RP:n kautta (ikään kuin konferenssipuhelusilta) käyttäen vain (*, G) jaettua puuta. Kynnysarvoa käytetään myös takaisinkytkennässä sekä siirtymisessä. Alhaisen nopeuden (S, G) lähdepuut kytketään takaisin jaettuun puuhun. Liikennemäärä tarkistetaan minuutin välein.
Jos vastaanottaja haluaa liittyä ja sen naapurireititin on SPT:ssä (Source Tree), lähtevän rajapinnan Shared Tree -merkintä kopioidaan Source Tree -merkintään, mikä suojaa siltä, että liikennettä ei tarvitsisi lähettää RP:lle ja sen jälkeen ”takaisin” SPT:ssä olevalle reitittimelle.
Sivumennen sanottuna saatat miettiä, mitä järkeä RP:llä on tässä? Kynnysmekanismin takia RP antaa meille tavan käyttää jaettua puuta ja hallita tilatietojen räjähdysmäistä luomista reitittimissä, jos monet vastaanottajat liittyvät samaan aikaan.
Jaketut vs. lähdepuut
PIM Sparse Mode (PIM-SM) voi käyttää sekä jaettuja puita (RP:n kautta kulkevia) että lähdepuita (tehokasta suoraa jakelua ”lyhintä” reittiä pitkin lähteestä vastaanottajalle). Tyypillisesti se voi käyttää molempia. Jos tehokas jakelu ei ole yhtä tärkeää ja reitittimien ylläpitämän tilatiedon määrän vähentäminen on tärkeämpää, PIM voidaan konfiguroida käyttämään vain jaettua puuta.
Kun PIM-SM-reititin vastaanottaa monilähetyspaketin, se tarkistaa lähdepuun kyseisen lähdeosoitteen ja monilähetysryhmän (kohdeosoitteen) osalta. Jos merkintää ei ole, se tarkistaa, onko monilähetysryhmälle Shared Tree (*, G) -merkintä. Jos merkintöjä on molemmissa puissa, saapuva rajapinta kertoo reitittimelle, kumpaa puuta käytetään. Jos molemmilla puilla on sama saapuva rajapinta, (S, G)-merkinnän RP-bitti estää päällekkäiset paketit: tämä osoittaa, että RPF-rajapinta sijaitsee jaetun puun varrella.
Monilähetysvirrassa, jossa on vähintään yksi aktiivinen vastaanottaja, lähteen ja RP:n välinen polku on osa lähdepuuta. (Huomaa, että ”väliin jäävä polku” on tässä hieman epämääräinen, yritän olla antamatta liikaa yksityiskohtia.)
Shared Tree -merkinnät yhdistävät RP:n joihinkin vastaanottimiin. Jaetun puun (*, G) RPF-rajapinta on RP:n suuntaan oleva rajapinta, ei monilähetysryhmän lähde. Siksi on mahdollista, että (S, G)-lähde- ja (*, G)-jakopuilla on eri RPF-liitännät.
Jakopuun (*, G)-merkinnät näyttävät liitännät, joissa vastaanotettiin liittyminen RP:hen, tai liitännät, joihin on suoraan liitettyjä ryhmän jäseniä (konfiguroituja tai IGMP:n vastaanottamia). Source Tree (S, G) -merkinnät näyttävät, missä vastaanotettiin Join tai Prune tai Register.
PIM Sparse Mode -tilan konfigurointi
Perusosa mitä tarvitset on:
ip multicast-routing
interface ethernet 0
ip-osoite 10.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
Sinun on myös kerrottava kullekin reitittimelle RP, joko kaikille ryhmille tai valituille ryhmille (käyttämällä pääsylistoja määrittääksesi, mikä RP millekin ryhmille). Tämä voidaan tehdä staattisesti seuraavasti:
ip pim rp-address 1.2.3.4
Katsomme seuraavassa artikkelissa muita vaihtoehtoja RP:n hallintaan.
Johtopäätöksessä
Viime kuussa tarkastelemme eri tapoja työskennellä Rendezvous-pisteiden kanssa. Saatamme myös koskettaa kevyesti paria muuta edistyneempää IP-multicast-aihetta.