PIM Sparse Mode

Bevezetés

Az IP Multicastról beszéltünk. Ebben a hónapban a PIM Sparse móddal fogok foglalkozni. Korábbi cikkek, amelyek érdekelhetnek:

  • Az IP Multicast protokolljai
  • PIM Dense Mode

Sparse Versus Dense Mode

Emlékezzünk arra, hogy a PIM Dense Mode-ot (elvileg) akkor használjuk, ha a multicastot a legtöbb helyen szeretnénk. Így a kezdeti multicast csomagok mindenhová elárasztásra kerülnek, a metszés pedig levágja a forgalmat azokról a helyekről, amelyeknek nincs szükségük a multicast táplálásra. A közelmúltig a PIM Dense Mode szenvedett a 3 percenkénti periodikus újraárasztástól, de a 12.1(5)T-ben a PIM Dense Mode State Refresh funkció enyhítette ezt. Ezzel a funkcióval a PIM Dense Mode vitathatatlanul alkalmas a multicast egyszerű megvalósítására. Különösen ott, ahol nincs szükség a PIM Sparse Mode további ellenőrzésére, és ahol az alkalmi “véletlen” elárasztás nem lenne nagyon káros.

A PIM Sparse Mode explicit request megközelítést használ, ahol az útválasztónak egy PIM Join üzenettel kell kérnie a multicast táplálást. A PIM Sparse Mode akkor javasolt, ha pontosabb vezérlésre van szükség, különösen akkor, ha a sávszélességhez képest nagy mennyiségű IP-multicast forgalmat bonyolítunk. A PIM Sparse Mode meglehetősen jól skálázható, mert a csomagok csak oda mennek, ahol szükség van rájuk, és mert csak szükség szerint hoz létre állapotot a routerekben. Emiatt Internet Experimental Protocol-ként lett leírva.

Az ár, amit ezért az extra vezérlésért fizetünk, enyhe extra komplexitás. A PIM Sparse Mode egy speciális útválasztót, úgynevezett Rendezvous Pointot (RP) használ, hogy az áramlás forrását vagy a multicast fát összekapcsolja a wannabe vevő melletti útválasztóval. Az RP-t általában csak ideiglenesen használják, amint azt alább látni fogjuk.

A különböző multicast csoportoknak különböző RP-k lehetnek, ami a terhelés elosztásának egyik módja. Általában egy RP van multicast csoportonként. Az RP-k redundanciája egy haladó téma, és egy kicsit mélyebb szakértelmet igényel. Ennek egyik módja az MSDP protokoll (lehetséges későbbi cikk a sorozatban).

Emlékezzünk arra, hogy a PIM Join üzenetet egy forrás (vagy PIM-SM esetén esetleg egy RP) felé küldjük, az unicast útválasztás alapján. A Join üzenet tulajdonképpen azt mondja, hogy “szükségünk van egy másolatra a multicastokból ide”. A Join üzenet küldőjét és a közbeeső útválasztókat összekapcsolja bármely meglévő multicast fával, szükség esetén egészen a Join célpontjáig. A Prune üzenet azt mondja, hogy “erre már nincs szükségünk”. A Prune üzenetet fogadó útválasztó megnézi, hogy van-e más olyan interfésze, amely igényli a multicast áramlást, és ha nincs, elküldi a saját Prune üzenetét. Az egyik fejlett technika az, hogy az unicast útválasztási információk egy külön, esetleg eltérő példányát csak a multicast célokra szervezik. Ez lehetővé teszi a Join üzenetek “irányítását”. A többprotokollos BGP, MBGP, a multicasthoz, az egyik módja ennek (lehetséges későbbi cikk a sorozatban).

Basic Rendezvous Point (RP)

Az eddigiekben láttuk, hogy a PIM-SM egy Rendezvous Pointot (RP) használ, a forrás és a vevők összekapcsolására. Multicast csoportonként csak egy RP lehet, és a legegyszerűbb megvalósítás egy RP-t használ az összes multicast csoporthoz.

Mondjuk el az RP használatának alapjait. Tegyük fel, hogy a forrás már azelőtt elkezd küldeni, mielőtt még vevők lennének. Ha a dolgok fordítva történnek, akkor néhány részlet kissé megváltozik, de nem sokban különbözik.

Szóval: a multicast forrás elkezd küldeni. Ahogy már megjegyeztük, az IP multicast esetében nincs protokoll vagy bármi a források regisztrálására. A forrás küld, és a szomszédos útválasztó(k)n múlik, hogy helyesen cselekszik-e. A PIM-SM esetében a szomszédos útválasztó tud az RP-ről. (Hogy honnan tud, az egy teljesen különálló cikk témája.) A szomszédos útválasztó továbbítja a multicast adatokat az RP-nek úgy, hogy azokat egy vagy több unicast Register üzenetbe kapszulázza. A normál útválasztás eljuttatja a Register-t az RP-hez. Az RP dekapszulálja a multicastot, és továbbítja a másolatokat lefelé bármely Shared Tree (van egy előre felépített, ha a forrás küldésének megkezdése előtt csatlakoztak vevők). Ha vannak vevők (Shared Tree állapotú kimenő interfészek), az RP visszaküld egy PIM Join-t a forrás felé. Ez összeköti a Forrást az RP-vel egy Forrásfával, az (S, G) legrövidebb út fával (SPT). Amint az RP multicastokat fogad ezen az SPT-n, Register-Stop-ot küld, hogy megmondja a Forrásnál lévő útválasztónak, hogy hagyja abba a Register csomagok küldését. Ennek a viselkedésnek az az oka, hogy nem vesznek el multicast csomagok, ha már vannak vevők.

Mellesleg, ha nincsenek vevők, a Register-Stop üzenetet elküldi. Majd amikor később megjelenik egy vevő (IGMP a szomszédos routerhez, PIM Join a szomszédos routertől vissza az RP-hez), akkor az RP ekkor elküldi a PIM Join üzenetet a forrásnak.

A következő ábrán feltételezzük, hogy van forrás és aktív vevők (nem látható). A bemutatott vevő IGMP Reportot küld a D router felé. A D router ezután PIM Join-t küld az RP felé. Mivel vannak más vevők is, az RP már csatlakozott a forrásfához (kékkel ábrázolva), és fogadja a multicast áramlást. A zölddel ábrázolt Shared Tree-n keresztül továbbítja a Source Tree áramlási csomagokat.

Most a csomagok a Source Tree (Shortest Path Tree, SPT) mentén jutnak el a Source-től az RP-hez, az RP-től pedig a Shared Tree mentén a vevőhöz. Amikor az összesített (*, G) csomagok bitrátája (az összes forrásból) meghalad egy Kbps-ban kifejezett küszöbértéket, ez elindítja a vevőhöz legközelebbi útválasztót, hogy megpróbáljon csatlakozni a Forrásfához. Csatlakozást küld a multicast-áramlás forrása felé. Megjegyzendő, hogy az előző Join az RP felé volt küldve. A forrás felé irányuló Join útválasztóról útválasztóra halad a forrás felé, amíg nem találkozik egy olyan útválasztóval, amely már a Source Tree-ben van. Ez hozzáadja a vevőhöz közeli útválasztót a Source Tree-hez. Amikor egy csomag ténylegesen érkezik a fa mentén, egy Prune-t küld az RP felé. Gyakorlatilag “köszönöm, de most már nem kiskereskedelmi, hanem nagykereskedelmi multicastot kapok”, mivel ez a folyamat kivágja az RP-t középen.

A következő ábra mutatja, hogyan működik ez. A bal felső piros nyilak a Join-t mutatják a Source felé. Ez elindítja a felső kék áramlást, a csomagokat a Source Tree mentén továbbítja. A jobb alsó piros nyilak ezután a Prunes, mivel a Shared Tree áramlásra már nincs szükség (zöld szaggatott vonalként látható). Vegyük észre, hogy a Source Tree csomagok közvetlenebb úton, általában kisebb késleltetéssel érkeznek a Receiverhez.

Apropó, a küszöbértéket mi szabályozzuk. Ez konfigurálható. Az alapértelmezett érték nulla Kbps: egy csomag fogadása, és átváltás a Source Tree-re. Ha sok forrásunk van egy adott multicast csoporthoz (gondoljunk konferenciahívásra, VoIP-re), akkor mindegyikhez van egy (S, G) Source Tree bejegyzés. Ha a küszöbértéket úgy állítjuk be, hogy soha ne aktiválódjon, akkor minden csomag átmegy az RP-n (olyan, mint egy konferenciahívó híd), és csak a (*, G) megosztott fát használja. A küszöbértéket a visszakapcsolásnál és az átkapcsolásnál is használjuk. Az alacsony sebességű (S, G) forrásfák visszakapcsolódnak a megosztott fára. A forgalom mennyiségét percenként ellenőrzik.

Ha egy vevő csatlakozni kíván, és a szomszédos útválasztója az SPT-n (Source Tree) van, akkor a kimenő interfész Shared Tree bejegyzését átmásolják a Source Tree bejegyzésbe, ami megóv attól, hogy a forgalmat az RP-hez kelljen küldeni, majd “vissza” az SPT-n lévő útválasztóhoz.

Mellesleg felmerülhet a kérdés, hogy mi értelme van itt az RP-nek? A küszöbmechanizmus miatt az RP lehetőséget ad a megosztott fa használatára, és az állapotinformációk robbanásszerű létrehozásának ellenőrzésére az útválasztókban, ha sok vevő csatlakozik egyszerre.

Megosztott és forrásfák

A PIM Sparse Mode (PIM-SM) egyaránt használhat megosztott fákat (az RP-n keresztül haladva) és forrásfákat (a forrás és a vevő közötti “legrövidebb” útvonalon történő hatékony közvetlen kézbesítéshez). Általában mindkettőt használhatja. Ha a hatékony kézbesítés kevésbé fontos, és az útválasztók által tárolt állapotinformációk mennyiségének csökkentése fontosabb, akkor a PIM konfigurálható úgy, hogy csak a Shared Tree-t használja.

Amikor egy PIM-SM útválasztó multicast csomagot kap, ellenőrzi a Source Tree-t az adott forráscím és multicast csoport (cél)cím tekintetében. Ha nincs ilyen bejegyzés, akkor ellenőrzi, hogy van-e a multicast csoportnak egy Shared Tree (*, G) bejegyzése. Ha mindkét fához vannak bejegyzések, a bejövő interfész megmondja az útválasztónak, hogy melyik fát használja. Ha mindkét fának ugyanaz a bejövő interfésze, akkor az (S, G) bejegyzés RP bitje megakadályozza a duplikált csomagokat: ez azt jelzi, hogy az RPF-interfész a megosztott fa mentén fekszik.

A legalább egy aktív vevővel rendelkező multicast-áramlás esetében a forrás és az RP közötti útvonal a forrásfa része lesz. (Megjegyzendő, hogy a “kettő közötti út” itt kissé homályos, igyekszem nem túl részletezni.)

A megosztott fa bejegyzései összekötik az RP-t a vevők egy részével. A (*, G) Shared Tree RPF interfésze az RP irányában lévő interfész, nem pedig a multicast csoport forrása. Ezért lehetséges, hogy az (S, G) forrás és a (*, G) megosztott fáknak különböző RPF-interfészük van.

A megosztott fa (*, G) bejegyzései olyan interfészeket mutatnak, ahol az RP-hez való csatlakozás érkezett, vagy olyan interfészeket, amelyeken közvetlenül csatlakozó csoporttagok vannak (konfigurált vagy IGMP-vel fogadott). A Source Tree (S, G) bejegyzések azt mutatják, ahol Join vagy Prune vagy Register érkezett.

PIM Sparse mód beállítása

Az alapvető rész, amire szükséged van:

ip multicast-routing

interface ethernet 0
ip cím 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

Az egyes útválasztóknak meg kell adnunk az RP-t is, vagy az összes csoporthoz, vagy a kiválasztott csoportokhoz (hozzáférési listák segítségével megadva, hogy melyik csoporthoz melyik RP-t). Ezt statikusan megtehetjük:

ip pim rp-address 1.2.3.4

A következő cikkben megnézzük az RP kezelésének egyéb lehetőségeit.

Végezetül

A következő hónapban megnézzük a randevúpontokkal való munka különböző módjait. Könnyedén érinthetünk néhány más, haladóbb IP multicast témát is.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.