Řídký režim PIM

Úvod

Mluvili jsme o vícesměrovém vysílání IP. Tento měsíc se začnu zabývat režimem PIM Sparse Mode. Předchozí články, které by vás mohly zajímat:

  • Protokoly IP Multicast
  • PIM Dense Mode

Sparse Versus Dense Mode

Připomeňte si, že PIM Dense Mode se používá (v zásadě) tehdy, když je požadován multicast na většině míst. Počáteční pakety vícesměrového vysílání jsou tedy zaplaveny všude, přičemž prořezávání odřízne provoz do míst, která vícesměrové vysílání nepotřebují. Donedávna trpěl režim PIM Dense Mode periodickým přeplňováním každé 3 minuty, ale ve verzi 12.1(5)T to zmírnila funkce PIM Dense Mode State Refresh. Díky této funkci je PIM Dense Mode pravděpodobně vhodný pro jednoduchou implementaci vícesměrového vysílání. Zejména tam, kde není potřeba dodatečná kontrola režimu PIM Sparse Mode a kde by občasné „náhodné“ zaplavení nebylo příliš škodlivé.

PIM Sparse Mode používá přístup explicitního požadavku, kdy směrovač musí požádat o multicastový kanál pomocí zprávy PIM Join. Režim PIM Sparse Mode je indikován, pokud potřebujete přesnější řízení, zejména pokud máte velké objemy IP multicastového provozu v porovnání s šířkou pásma. Režim PIM Sparse Mode se poměrně dobře škáluje, protože pakety putují pouze tam, kde jsou potřeba, a protože vytváří stav ve směrovačích pouze podle potřeby. Z tohoto důvodu byl zapsán jako internetový experimentální protokol.

Cenou, kterou za tuto dodatečnou kontrolu platíme, je mírná složitost navíc. Režim PIM Sparse Mode používá speciální směrovač zvaný Rendezvous Point (RP), který spojuje zdroj toku nebo strom vícesměrového vysílání se směrovačem vedle rádoby příjemce. RP se obvykle používá pouze dočasně, jak uvidíme dále.

Pro různé skupiny vícesměrového vysílání mohou existovat různé RP, což je jeden ze způsobů, jak rozložit zátěž. Na každou skupinu vícesměrového vysílání obvykle připadá jeden RP. Redundance RP je pokročilé téma a vyžaduje trochu hlubší znalosti. Jedním ze způsobů, jak toho dosáhnout, je protokol MSDP (možný pozdější článek seriálu).

Připomeňte si, že zpráva PIM Join je odesílána směrem ke zdroji (nebo v případě PIM-SM případně k RP) na základě směrování unicast. Zpráva Join v podstatě říká „potřebujeme kopii multicastu sem“. Připojuje odesílatele zprávy Join a zasahující směrovače k jakémukoli existujícímu stromu vícesměrového vysílání, v případě potřeby až k cíli zprávy Join. Zpráva Prune v podstatě říká „tady už to nepotřebujeme“. Směrovač, který přijímá zprávu Prune, zjišťuje, zda má další rozhraní vyžadující tok vícesměrového vysílání, a pokud ne, odešle vlastní zprávu Prune. Jednou z pokročilých technik je vytvoření samostatné a možná odlišné kopie směrovacích informací unicast pouze pro účely multicastu. To umožňuje „řízení“ zpráv Join. MultiProtocol BGP, MBGP, pro vícesměrové vysílání je jedním ze způsobů, jak toho dosáhnout (možný pozdější článek seriálu).

Základní Rendezvous Point (RP)

Dosud jsme viděli, že PIM-SM používá Rendezvous Point (RP), pro spojení zdroje a příjemců. Pro každou skupinu vícesměrového vysílání může existovat pouze jeden RP a nejjednodušší implementace používá jeden RP pro všechny skupiny vícesměrového vysílání.

Probereme si základní informace o tom, jak se RP používá. Předpokládejme, že zdroj začne vysílat dříve, než se objeví nějací příjemci. Pokud se věci odehrávají opačně, některé detaily se mírně změní, ale příliš se neliší.

Takže: zdroj multicastu začne vysílat. Jak jsme již poznamenali, neexistuje žádný protokol nebo cokoli pro registraci zdrojů s IP multicastem. Zdroj vysílá a je na sousedních směrovačích, jak se zachovají. V případě PIM-SM ví sousední směrovač o RP. (Jak to ví, je téma na celý samostatný článek.) Sousední směrovač předává data vícesměrového vysílání RP tak, že je zapouzdří do zprávy nebo zpráv unicast Register. Normální směrování doručí zprávu Register do RP. RP deenkapsuluje multicast a předá kopie dolů po případném sdíleném stromu (existuje jeden předpřipravený, pokud byly přijímače připojeny předtím, než zdroj začal vysílat). Pokud existují přijímače (výstupní rozhraní ve stavu sdíleného stromu), RP odešle zpět směrem ke Zdroji zprávu PIM Join. Tím se Zdroj spojí s RP pomocí zdrojového stromu, (S, G) Shortest Path Tree (SPT). Jakmile RP obdrží multicasty podél tohoto SPT, odešle Register-Stop, aby sdělil směrovači u Zdroje, že má přestat posílat pakety Register. Důvodem tohoto chování je, že nedojde ke ztrátě paketů multicast, pokud jsou již přítomni příjemci.

Pokud nejsou přítomni žádní příjemci, je zpráva Register-Stop odeslána. Když se pak následně nějaký přijímač objeví (IGMP sousednímu směrovači, PIM Join od sousedního směrovače zpět k RP), pak RP v té době odešle PIM Join zdroji.

Následující obrázek předpokládá, že existuje zdroj a aktivní přijímače (nejsou zobrazeny). Zobrazený přijímač odešle IGMP Report směrovači D. Směrovač D poté odešle PIM Join směrem k RP. Protože existují další příjemci, RP je již připojen ke stromu zdroje (zobrazeno modře) a přijímá tok vícesměrového vysílání. Předává pakety toku zdrojového stromu dále prostřednictvím sdíleného stromu, který je znázorněn zeleně.

Nyní máme pakety, které jdou od zdroje k RP po zdrojovém stromu (Shortest Path Tree, SPT) a od RP k příjemci po sdíleném stromu. Když souhrnná (*, G) přenosová rychlost paketů (ze všech zdrojů) překročí prahovou hodnotu v Kb/s, spustí to směrovač, který je nejblíže k příjemci, aby se pokusil připojit ke zdrojovému stromu. Ten odešle zprávu Join směrem ke zdroji multicastového toku. Všimněte si, že předchozí Join, který odeslal, směřoval k RP. Join směrem ke zdroji postupuje směrovač po směrovači směrem ke zdroji, dokud nenarazí na směrovač, který je již ve zdrojovém stromu. Tím se směrovač v blízkosti příjemce přidá do zdrojového stromu. Když je paket podél tohoto stromu skutečně přijat, je směrem k RP odeslán Prune. V podstatě „děkuji, ale nyní dostávám multicast ve velkém, ne v malém“, protože tento proces vyřadí RP uprostřed.

Následující obrázek ukazuje, jak to funguje. Červené šipky vlevo nahoře ukazují Připojení směrem ke Zdroji. Tím se rozběhne horní modrý tok, pakety jsou předávány podél stromu zdroje. Pravé dolní červené šipky pak představují Prunes, protože tok sdíleného stromu již není potřeba (znázorněno zelenou přerušovanou čarou). Všimněte si, že pakety Zdrojového stromu dorazí k Příjemci přímější cestou, zpravidla s nižší latencí.

Mimochodem, práh kontrolujeme. Je konfigurovatelný. Výchozí hodnota je nula Kb/s: přijetí jednoho paketu a přepnutí na zdrojový strom. Pokud máme mnoho zdrojů pro určitou skupinu vícesměrového vysílání (představte si konferenční hovor, VoIP), pak pro každý z nich existuje položka (S, G) Source Tree. Pokud nastavíme práh tak, aby se nikdy neaktivoval, pak všechny pakety procházejí přes RP (něco jako most pro konferenční hovory) a používají pouze (*, G) sdílený strom. Práh se používá také pro přepínání zpět i pro přepínání. Zdrojové stromy s nízkou rychlostí (S, G) se přepínají zpět na sdílený strom. Objem provozu se kontroluje každou minutu.

Pokud se chce příjemce připojit a jeho sousední směrovač je na SPT (Source Tree), pak se položka odchozího rozhraní Shared Tree zkopíruje do položky Source Tree, což chrání před nutností posílat provoz na RP a pak „zpět“ na směrovač na SPT.

Možná se ptáte, k čemu je zde RP? Díky prahovému mechanismu nám RP dává možnost používat sdílený strom a řídit explozivní vytváření stavových informací ve směrovačích, pokud se připojí mnoho příjemců najednou.

Sdílený versus zdrojový strom

PIM Sparse Mode (PIM-SM) může používat jak sdílené stromy (procházející přes RP), tak zdrojové stromy (pro efektivní přímé doručení po „nejkratší“ cestě od zdroje k příjemci). Obvykle může používat obojí. Pokud je pro vás efektivní doručení méně důležité a důležitější je snížení množství stavových informací uchovávaných směrovači, pak lze PIM nakonfigurovat tak, aby používal pouze sdílený strom.

Když směrovač PIM-SM přijme paket vícesměrového vysílání, zkontroluje zdrojový strom pro danou zdrojovou adresu a adresu skupiny vícesměrového vysílání (cílovou). Pokud není přítomna žádná položka, vyhledá položku sdíleného stromu (*, G) pro skupinu vícesměrového vysílání. Pokud jsou přítomny záznamy pro oba stromy, příchozí rozhraní sdělí směrovači, který strom má použít. Pokud mají oba stromy stejné příchozí rozhraní, pak bit RP pro položku (S, G) zabrání duplicitním paketům: to znamená, že rozhraní RPF leží podél sdíleného stromu.

Pro tok vícesměrového vysílání s alespoň jedním aktivním příjemcem bude cesta mezi zdrojem a RP součástí zdrojového stromu. (Všimněte si, že „cesta mezi“ je zde poněkud vágní, snažím se neuvádět příliš mnoho podrobností)

Zápisy sdíleného stromu budou spojovat RP s některým z příjemců. Rozhraní RPF pro (*, G) sdílený strom je rozhraní ve směru RP, nikoli zdroj skupiny vícesměrového vysílání. Proto existuje možnost, že zdrojový a (*, G) sdílený strom mají různá rozhraní RPF.

Záznamy sdíleného stromu (*, G) zobrazují rozhraní, kde bylo přijato připojení k RP, nebo rozhraní s přímo připojenými členy skupiny (konfigurovanými nebo přijatými IGMP). Položky zdrojového stromu (S, G) zobrazují místa, kde bylo přijato připojení, nebo Prune, nebo Register.

Konfigurace PIM Sparse Mode

Základní část, kterou potřebujete, je:

ip multicast-routing

interface ethernet 0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode

Každému směrovači musíte také sdělit RP, buď pro všechny skupiny, nebo pro vybrané skupiny (pomocí přístupových seznamů určíte, který RP pro které skupiny). To lze provést staticky pomocí:

ip pim rp-address 1.2.3.4

Na další možnosti správy RP se podíváme v příštím článku.

Závěr

Příští měsíc se podíváme na různé způsoby práce se směrovacími body. Možná se také lehce dotkneme několika dalších pokročilejších témat vícesměrového vysílání IP.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.