PIM Sparse Mode

Introduzione

Abbiamo parlato di IP Multicast. Questo mese inizierò a coprire il PIM Sparse Mode. Articoli precedenti che potrebbero essere interessanti:

  • I protocolli di IP Multicast
  • PIM Dense Mode

Sparse Versus Dense Mode

Ricorda che PIM Dense Mode è usato (in linea di principio) quando il multicast è desiderato nella maggior parte dei luoghi. Così i pacchetti multicast iniziali sono inondati ovunque, con il pruning che taglia il traffico verso le località che non hanno bisogno di alimentazione multicast. Fino a poco tempo fa, il PIM Dense Mode soffriva di un periodico re-flooding ogni 3 minuti, ma nella 12.1(5)T, la caratteristica PIM Dense Mode State Refresh ha alleviato questo problema. Con questa caratteristica, il PIM Dense Mode è probabilmente adatto per una semplice implementazione del multicast. Specialmente dove il controllo addizionale del PIM Sparse Mode non è necessario, e dove il flooding occasionale “accidentale” non sarebbe molto dannoso.

PIM Sparse Mode usa un approccio di richiesta esplicita, dove un router deve chiedere il feed multicast con un messaggio PIM Join. PIM Sparse Mode è indicato quando hai bisogno di un controllo più preciso, specialmente quando hai grandi volumi di traffico IP multicast rispetto alla tua larghezza di banda. Il PIM Sparse Mode scala piuttosto bene, perché i pacchetti vanno solo dove sono necessari, e perché crea stato nei router solo se necessario. A causa di questo, è stato scritto come un protocollo sperimentale di Internet.

Il prezzo che paghiamo per questo controllo extra è una leggera complessità extra. PIM Sparse Mode usa un router speciale chiamato Rendezvous Point (RP) per connettere la sorgente del flusso o l’albero multicast al router vicino all’aspirante ricevitore. L’RP è tipicamente usato solo temporaneamente, come vedremo più avanti.

Ci possono essere diversi RP per diversi gruppi multicast, che è un modo per distribuire il carico. Di solito c’è un RP per gruppo multicast. La ridondanza degli RP è un argomento avanzato, e richiede un po’ più di esperienza. Un modo per farlo è con il protocollo MSDP (possibile articolo successivo della serie).

Ricorda che un messaggio PIM Join è inviato verso una sorgente (o per PIM-SM, possibilmente verso un RP), basato sul routing unicast. Il messaggio Join dice in effetti “abbiamo bisogno di una copia dei multicast qui”. Collega il mittente del Join e i router che intervengono a qualsiasi albero multicast esistente, fino alla destinazione del Join, se necessario. Un messaggio Prune dice in effetti “non abbiamo più bisogno di questo qui”. Un router che riceve un Prune vede se ha altre interfacce che richiedono il flusso multicast e, in caso contrario, invia il proprio messaggio Prune. Una tecnica avanzata è quella di organizzare una copia separata e forse diversa delle informazioni di routing unicast solo per scopi multicast. Questo permette di “guidare” i messaggi di Join. MultiProtocol BGP, MBGP, per il multicast, è un modo per farlo (possibile articolo successivo della serie).

Basic Rendezvous Point (RP)

Abbiamo visto finora che PIM-SM usa un Rendezvous Point (RP), per collegare sorgente e ricevitori. Ci può essere solo un RP per gruppo multicast, e l’implementazione più semplice usa un RP per tutti i gruppi multicast.

Parliamo delle basi di come viene usato l’RP. Supponiamo che la sorgente inizi ad inviare prima che ci siano dei ricevitori. Se le cose accadono al contrario, alcuni dettagli cambiano leggermente, ma non è molto diverso.

Quindi: la sorgente multicast inizia a inviare. Come abbiamo già notato, non c’è un protocollo o qualcosa per registrare le fonti con IP multicast. La fonte invia e sta ai router vicini fare la cosa giusta. Con PIM-SM, il router vicino conosce l’RP. (Il router vicino inoltra i dati multicast all’RP incapsulandoli in uno o più messaggi di registro unicast. L’instradamento normale consegna il registro all’RP. L’RP deincapsula il multicast e ne inoltra delle copie lungo qualsiasi Shared Tree (ce n’è uno pre-costruito se c’erano ricevitori uniti prima che la sorgente iniziasse a inviare). Se ci sono ricevitori (interfacce in uscita con stato Shared Tree), l’RP invia un PIM Join indietro verso la Sorgente. Questo collega la sorgente all’RP con un albero della sorgente, lo (S, G) Shortest Path Tree (SPT). Una volta che l’RP riceve multicast lungo questo SPT, invia un Register-Stop per dire al router dalla sorgente di smettere di inviare pacchetti di registro. La ragione di questo comportamento è che nessun pacchetto multicast viene perso, se ci sono ricevitori già presenti.

A proposito, se non ci sono ricevitori presenti, il messaggio Register-Stop viene inviato. Poi, quando un ricevitore si presenta successivamente (IGMP al router vicino, PIM Join dal router vicino al RP), allora l’RP invia il PIM Join alla sorgente in quel momento.

La figura seguente assume che ci sia una sorgente e ricevitori attivi (non mostrati). Il ricevitore mostrato invia un IGMP Report al router D. Il router D poi invia un PIM Join verso l’RP. Poiché ci sono altri ricevitori, l’RP è già unito al Source Tree (mostrato in blu) e sta ricevendo il flusso multicast. Passa i pacchetti del flusso Source Tree attraverso lo Shared Tree, mostrato in verde.

Bene, ora abbiamo i pacchetti che vanno dalla sorgente all’RP lungo il Source Tree (Shortest Path Tree, SPT), e dall’RP al ricevitore lungo lo Shared Tree. Quando il bit rate aggregato (*, G) dei pacchetti (da tutte le fonti) supera una soglia in Kbps, questo fa sì che il router più vicino al ricevitore cerchi di unirsi al Source Tree. Esso invia un Join verso la sorgente del flusso multicast. Si noti che il Join precedente inviato era verso l’RP. Il Join verso la sorgente va router per router verso la sorgente finché non incontra un router che è già nel Source Tree. Questo aggiunge il router vicino al ricevitore al Source Tree. Quando un pacchetto viene effettivamente ricevuto lungo quell’albero, viene inviato un Prune verso l’RP. In effetti, “grazie, ma ora sto ricevendo il mio multicast all’ingrosso, non al dettaglio”, poiché questo processo taglia fuori l’RP nel mezzo.

La figura seguente mostra come funziona. Le frecce rosse in alto a sinistra mostrano il join verso la sorgente. Questo fa partire il flusso blu in alto, i pacchetti vengono inoltrati lungo l’albero della sorgente. Le frecce rosse in basso a destra sono le Prune, poiché il flusso Shared Tree non è più necessario (mostrato come linea tratteggiata verde). Si noti che i pacchetti del Source Tree arrivano al ricevitore lungo un percorso più diretto, generalmente con una latenza inferiore.

A proposito, noi controlliamo la soglia. È configurabile. L’impostazione predefinita è zero Kbps: riceviamo un pacchetto e passiamo al Source Tree. Se abbiamo molte fonti per un particolare gruppo multicast (pensiamo ad una chiamata in conferenza, VoIP), allora c’è una voce Source Tree (S, G) per ognuna. Se impostiamo la soglia per non attivarsi mai, allora tutti i pacchetti passano attraverso l’RP (una specie di ponte per chiamate in conferenza), usando solo il (*, G) Shared Tree. La soglia è usata anche per lo switchback e lo switchover. I Source Tree a basso tasso (S, G) vengono commutati di nuovo sullo Shared Tree. Il volume di traffico viene controllato ogni minuto.

Se un ricevitore vuole unirsi, e il suo router vicino è sull’SPT (Source Tree), allora la voce Shared Tree dell’interfaccia in uscita viene copiata nella voce Source Tree, che protegge dal dover inviare il traffico all’RP e poi “indietro” al router sull’SPT.

A proposito, potresti chiederti, qual è lo scopo di avere l’RP qui? A causa del meccanismo di soglia, l’RP ci dà un modo per usare lo Shared Tree, e controllare la creazione esplosiva di informazioni di stato nei router se molti ricevitori si uniscono allo stesso tempo.

Shared Versus Source Trees

PIM Sparse Mode (PIM-SM) può usare sia Shared Trees (passando attraverso l’RP) che Source Trees (per una efficiente consegna diretta lungo il percorso “più breve” dalla sorgente al ricevitore). In genere, può usarli entrambi. Se la consegna efficiente è meno importante per te, e diminuire la quantità di informazioni di stato mantenute dai router è più importante, allora PIM può essere configurato per usare solo uno Shared Tree.

Quando un router PIM-SM riceve un pacchetto multicast, controlla il Source Tree per quel particolare indirizzo sorgente e gruppo multicast (destinazione). Se non c’è nessuna voce presente, controlla se c’è una voce di Shared Tree (*, G) per il gruppo multicast. Se le voci sono presenti per entrambi gli alberi, l’interfaccia in entrata dice al router quale albero usare. Se entrambi gli alberi hanno la stessa interfaccia in entrata, allora il bit RP per una voce (S, G) previene i pacchetti duplicati: questo indica che l’interfaccia RPF si trova lungo lo Shared Tree.

Per un flusso multicast con almeno un ricevitore attivo, il percorso tra la sorgente e l’RP sarà parte del Source Tree. (Si noti che “il percorso tra” è un po’ vago qui, sto cercando di evitare di dare troppi dettagli.)

Le voci dell’albero condiviso collegheranno l’RP ad alcuni dei ricevitori. L’interfaccia RPF per lo Shared Tree (*, G) è l’interfaccia nella direzione dell’RP, non la sorgente del gruppo multicast. Ecco perché c’è la possibilità che gli alberi (S, G) Source e (*, G) Shared Tree abbiano diverse interfacce RPF.

Le voci Shared Tree (*, G) mostrano le interfacce dove è stato ricevuto un join all’RP, o le interfacce con membri del gruppo direttamente connessi (configurati o ricevuti da IGMP). Le voci Source Tree (S, G) mostrano dove è stato ricevuto un Join o un Prune o un Register.

Configurare PIM Sparse Mode

La parte base di ciò che ti serve è:

ip multicast-routing

interfaccia ethernet 0
indirizzo ip 10.1.1.1 255.255.255.0
ip pim sparse-mode
interfaccia ethernet 1
indirizzo IP 10.1.2.1 255.255.255.0
ip pim sparse-mode

Devi anche dire ad ogni router l’RP, o per tutti i gruppi o per gruppi selezionati (usando liste di accesso per specificare quale RP per quali gruppi). Questo può essere fatto staticamente con:

ip pim rp-address 1.2.3.4

Guarderemo le altre opzioni per gestire gli RP nel prossimo articolo.

In conclusione

Il mese prossimo daremo uno sguardo ai vari modi di lavorare con i Rendezvous Point. Potremmo anche toccare leggermente un paio di altri argomenti IP multicast più avanzati.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.