Nel post precedente sul modello NG-MVPN ho detto che questo offre diverse opzioni per quanto riguarda il piano dati, sia in termini di segnalazione che di incapsulamento del traffico. Per quanto riguarda l’incapsulamento, due sono le opzioni previste:

• Tunnel GRE.
• LSP MPLS Point-to-Multipoint (P2MP) o Multipoint-to-Multipoint (MP2MP).

Per la segnalazione, quando il trasporto è via Tunnel GRE, è previsto l’utilizzo del protocollo PIM nelle sue varie forme SSM/SM/Bidir. Questo è il tipo di trasporto utilizzato dal modello Draft-Rosen. Quando invece il trasporto è via MPLS, è possibile utilizzare sia LDP che RSVP-TE, opportunamente estesi per la realizzazione di LSP MPLS P2MP (Point-to-MultiPoint), e nel caso di LDP anche di LSP MPLS MP2MP (MultiPoint-to-MultiPoint).
I LSP MPLS di tipo multipoint trovano applicazioni anche in altri contesti, tra cui:

• Il trasporto del traffico BUM nelle VPLS (Virtual Private LAN Service), vedi a questo proposito la recente RFC 7117 Multicast in Virtual Private LAN Service (VPLS) del Febbraio 2014. Questa applicazione è già stata implementata sia da Cisco negli ASR9k a partire dalla versione 5.1.0 dell’IOS XR, con segnalazione RSVP-TE, che da Juniper a partire addirittura dalla versione 9.3 del JUNOS.
• Il trasporto del traffico BUM nel modello EVPN (Ethernet VPN), un modello molto sofisticato che eventualmente rimpiazzerà il servizio VPLS, definito nella RFC 7432 BGP MPLS-Based Ethernet VPN del Febbraio 2015. Su questo modello EVPN scriverò in seguito qualche post poiché lo ritengo molto importante (anche se io ho una certa idiosincrasia per le reti Switched Ethernet !).

In questo post tratterò solo LSP MPLS P2MP realizzati via RSVP-TE, lasciando a un post successivo il tema della realizzazione di LSP MPLS P2MP e MP2MP attraverso l’estensione multipoint di LDP (mLDP).
 
DEFINIZIONE DI LSP MULTIPOINT
Nella loro versione “classica”, i LSP MPLS possono essere stabiliti utilizzando come protocolli sia LDP (LSP di tipo Hop-by-Hop), che RSVP-TE (LSP di tipo Explicitly Routed). Nel primo caso i LSP MPLS sono di tipo MultiPoint-to-Point (MP2P), ossia trasportano traffico da più punti di ingresso a un punto di uscita. Per contro, nel secondo caso i LSP MPLS sono di tipo punto-punto, ossia partono da un LSR di ingresso e terminano su un ben preciso LSR di uscita.
Vi è una terza possibilità, quella di creare LSP di tipo punto-multipunto (Point-to-MultiPoint, P2MP), ossia LSP che trasportano traffico da un ben preciso LSR di ingresso a più LSR di uscita. In realtà vi è anche la possibilità di creare, ma solo attraverso mLDP, LSP di tipo MultiPoint-to-MultiPoint (MP2MP). Non li tratteremo in questo post, ma in un post successivo dedicato a mLDP.
Il concetto di LSP P2MP è molto simile al concetto di albero multicast, ossia un LSP P2MP permette di veicolare in modo efficiente traffico multicast, senza che il LSR di ingresso sia costretto a inviare più copie dello stesso traffico a più ricevitori. Come noto invece, un albero multicast ottimizza il trasporto del traffico verso più sorgenti, replicando i pacchetti solo in determinati punti (punti di diramazione dell’albero multicast).
I LSP P2MP possono essere realizzati sia attraverso RSVP-TE che LDP, opportunamente estesi. L’estensione di RSVP-TE per la realizzazione di LSP P2MP è specificata nello standard RFC 4875, Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs), Maggio 2007.
L’estensione di LDP per la realizzazione di LSP P2MP è specificata nella RFC 6388 - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths, Novembre 2011. Nella letteratura tecnica, questa estensione di LDP viene indicata, come ho detto nella premessa, mLDP (multipoint LDP).
L’utilizzo dell’uno o dell’altro protocollo è comunque legato agli stessi fattori per cui si preferisce utilizzare in pratica LDP o RSVP-TE. L’utilizzo di LDP rende la realizzazione di LSP più semplice e più “automatica”, ma non consente servizi aggiuntivi come la definizione di vincoli (di banda, di classi amministrative, di percorsi, ecc.) e il Fast Rerouting.
 
FORWARDINGDEL TRAFFICO 
La figura seguente riporta un esempio come il traffico multicast potrebbe essere veicolato su una rete IP/MPLS, utilizzando LSP di tipo punto-punto.
 

 
Il pacchetto IP multicast generato dalla sorgente, viene replicato dal LSR dove la sorgente è attestata (LSR A) due volte, un pacchetto con l’etichetta MPLS del LSP da LSR A a LSR D (etichetta 16), e un pacchetto con l’etichetta MPLS del LSP da LSR A a LSR E (etichetta 20). In particolare, il pacchetto iniziale viene veicolato verso i ricevitori utilizzando due LSP punto-punto, il primo dal LSR A al LSR D ed il secondo dal LSR A al LSR E.
Dal punto di vista della segnalazione RSVP-TE, il LSR A scambia messaggi PATH e RESV con i LSR D ed E in modo “ordinario” creando due LSP punto-punto.
Il punto chiave è nel LSR B, che genera messaggi RESV con etichette MPLS diverse per ciascun LSP (nella figura l’etichetta MPLS 16 per il LSP da A a D, e l’etichetta 20 per il LSP da a ad E).
Questa modalità di trasporto del traffico multicast, benché inefficiente dal punto di vista dell’utilizzo della banda, è comunque presente tra le 7 possibilità di piano dati del modello NG-MVPN (identificata dal tipo 6 (= Ingress Replication), vedi post precedente sul modello NG-MVPN). Ha il vantaggio che non richiede alcuna estensione di RSVP-TE (o LDP), ma è applicabile solamente a reti di piccole dimensioni.
Un LSP P2MP ha un singolo LSR di ingresso e più LSR di uscita. Nella rete della figura seguente, il LSR di ingresso è il LSR A e i due LSR di uscita sono i LSR D ed E.
 

 
Come si può vedere nella figura, utilizzando un LSP P2MP con origine nel LSR A, il LSR di ingresso A crea una sola copia del pacchetto multicast destinato ai due ricevitori. A questa singola copia è associata l’etichetta MPLS 16. Il pacchetto viene inviato al LSR B, che lo replica verso C e D eseguendo rispettivamente le operazioni MPLS “swap 21” e “label pop” (NOTA: mostrerò nel seguito come l’operazione di “label pop”, nota in MPLS come Penultimate Hop Popping, non è appropriata nel modello NG-MVPN). Il LSR B è un punto di diramazione del traffico, ossia un punto dove un pacchetto in ingresso viene replicato su più punti di uscita.
La differenza con il caso precedente, dove il traffico multicast viene veicolato su due LSP punto-punto separati, è nel LSR B. Nella tabella LFIB di B, in corrispondenza dell’etichetta 16 vi sono due uscite, una verso il LSR C con l’etichetta 21 e l’altra verso il LSR D senza etichetta (operazione di “label pop”). Questo indica al LSR B che quando riceve un pacchetto MPLS con etichetta 16, deve replicare il pacchetto verso i due LSR C e D eseguendo le operazioni sulla pila di etichette MPLS descritte nella tabella LFIB.
Il vantaggio dell’utilizzo di un LSP P2MP rispetto all’utilizzo di più LSP punto-punto è evidente: sul collegamento tra i LSR A e B viene utilizzata metà della banda. In ultima analisi, questa è la stessa differenza che esiste nel veicolare traffico multicast su una rete puramente IP, utilizzando protocolli routing multicast in luogo di protocolli di routing unicast.
 
DETERMINAZIONE DEI PERCORSI
La determinazione dei percorsi seguiti da un LSP P2MP è un argomento che in realtà esula dal tipo di segnalazione adottato. Ciononostante è un argomento di grande interesse, molto complesso, di cui daremo solo alcuni cenni.
L’obiettivo è quello di determinare il percorso del LSP P2MP tenendo conto di criteri che definiscono un percorso “ottimo” secondo i desiderata dell’utilizzatore. Ad esempio, se l’obiettivo fosse quello di minimizzare il ritardo end-to-end, un albero di cammini minimi (shortest-path tree) con metrica minimum-hop potrebbe essere sufficiente. Se d’altra parte l’obiettivo fosse quello di minimizzare l’utilizzo della banda, un albero a minimo costo in termini di utilizzo della banda (minimum-cost tree, detto anche Steiner tree) potrebbe essere più appropriato.
La figura seguente mette a confronto proprio questi due criteri, con l’ipotesi che ciascun link della rete abbia identica banda e ciascuna interfaccia identica metrica.
 

 
Nel caso di shortest-path tree vengono utilizzate sei unità di banda (ossia, un totale di 6 link), mentre nel caso di minimum-cost tree solo 4 unità di banda, ma con il rovescio della medaglia che alcuni percorsi sono distanti tre hop, e quindi il ritardo end-to-end è maggiore.
Questa libertà nella determinazione del percorso del LSP P2MP secondo i desiderata dell’utilizzatore, contrasta con quanto avviene nel tradizionale routing IP multicast, dove come risultato si ottengono solo shortest-path tree (con radice un Rendezvous-Point o un LSR dove è attestata una sorgente di traffico multicast). E non c’è modo di variare questo comportamento di base.
Come per i LSP punto-punto realizzati via MPLS-TE (con segnalazione RSVP-TE), sono possibili tre metodi per la determinazione del percorso:

• Manuale, attraverso una attenta analisi della topologia della rete.
• Online, utilizzando l’algoritmo CSPF (previa definizione di eventuali vincoli).
• Off-line, utilizzando appropriati programmi di calcolo ottimo di percorsi.

La scelta di uno dei tre metodi dipende dal particolare contesto. Nelle applicazioni del modello NG-MVPN, per evitare ulteriori complessità di configurazione, si preferisce spesso utilizzare il metodo online, con pochi vincoli o addirittura nessuno.
 
SEGNALAZIONE RSVP-TE DI LSP MPLS P2MP
Come citato sopra, i LSP P2MP possono essere realizzati sia via RSVP-TE che LDP, opportunamente estesi. Con RSVP-TE, un LSP P2MP viene visto come un insieme di LSP, denominati Source-to-Leaf (S2L) sub-LSP, che partono tutti da un comune LSR di ingresso e ciascuno termina su un LSR di uscita (NOTA: per brevità nel seguito indicheremo i S2L sub-LSP semplicemente come sub-LSP). Nell’esempio visto sopra, vengono segnalati due sub-LSP, entrambi con LSR di ingresso A e  ciascuno rispettivamente con LSR di uscita D ed E.
Per dare ai LSR uno strumento che permetta loro di capire che i sub-LSP sono associati ad uno stesso LSP P2MP, la segnalazione RSVP-TE utilizza un nuovo oggetto denominato “P2MP Session Object”, contenuto sia nei messaggi PATH che RESV. Un “P2MP Session Object” è costituito da una tripletta di elementi che identificano univocamente un LSP P2MP: <P2MP ID, Tunnel ID, Extended Tunnel ID>, per il cui significato rimandiamo alle RFC 2205 e RFC 4875.
Il meccanismo di segnalazione è analogo a quello per la realizzazione di LSP di tipo punto-punto, e verrà descritto nelle sue linee generali fra poco.
Un aspetto importante è che in qualche modo è necessario informare il LSR di ingresso su quali siano i LSR di uscita del LSP P2MP e sui percorsi da seguire. Una volta avute queste informazioni, vengono generati dal LSR di ingresso messaggi PATH e RESV per ciascun sub-LSP, con ciascun messaggio PATH contenente un oggetto ERO, determinato allo stesso modo dei LSP punto-punto.
Le figura seguente e la successiva riportano un esempio di segnalazione RSVP-TE di un LSP P2MP. In particolare questa diapositiva riporta il flusso dei messaggi PATH.
 

 
Il LSR di ingresso invia un messaggio PATH per ciascun sub-LSP. Ogni messaggio PATH contiene essenzialmente le stesse informazioni già citate per la realizzazione di LSP punto-punto, con in più il “P2MP Session Object” che identifica univocamente il LSP P2MP.
L’ERO (Explicit Route Object) contenuto nei messaggi PATH è funzione del metodo utilizzato nella determinazione del percorso (manuale, online, off-line) e del criterio utilizzato (shortest-path tree, minimum-cost tree, ecc.).
Nell’esempio della figura, ecco ciò che avviene:

1. A fronte di una configurazione sul LSR di ingresso A, che permette di identificare i due LSR di uscita e i percorsi verso ciascuno di questi (segnalazione out-of-band), oppure attraverso una procedura di segnalazione automatica originato dai LSR di uscita (segnalazione in-band) vengono generati due messaggi PATH, uno per il sub-LSP da A ad E e uno per il sub-LSP da A a D. Ciascun messaggio PATH contiene un ERO che specifica il percorso e un identico “P2MP Session Object” (esemplificato con X nella figura, ma in realtà costituito da una tripletta di elementi). I due messaggi PATH vengono inviati al primo LSR presente negli ERO, che per entrambi i sub-LSP è il LSR B.
2. Il LSR B, alla ricezione dei due messaggi PATH, esegue le stesse identiche operazioni come se i due sub-LSP fossero di tipo punto-punto. Crea così due nuovi messaggi PATH con gli ERO aggiornati e li invia rispettivamente ai LSR C e D.
3. I LSR C e D ricevono i messaggi PATH e di nuovo li elaborano come se i due sub-LSP fossero di tipo punto-punto.

A questo punto, entrambi i LSR di uscita avranno ricevuto il messaggio PATH con ERO contenente il proprio identificativo e identico “P2MP Session Object”. A fronte di questo, i due LSR di uscita generano a ritroso i messaggi RESV (vedi figura seguente).
 

 
La figura mostra il flusso di messaggi RESV inviati a ritroso dai due LSR di uscita D ed E. Si noti che come per i LSP punto-punto, si utilizza una allocazione di etichette di tipo downstream. Nell’esempio della figura, ecco ciò che avviene:

1. I LSR di uscita inviano ai due LSR da cui hanno ricevuto i messaggi PATH, due messaggi RESV ciascuno contenente una etichetta MPLS (inserita nel “Label Object”), e il comune “P2MP Session Object”. Nell’esempio, entrambi i LSR di uscita associano l’etichetta speciale 3 ai due sub-LSP (Penultimate Hop Popping), ma non è sempre questo il caso. 
2. Il LSR C riceve il messaggio RESV e a sua volta ne genera un altro, allocando la sua etichetta al sub-LSP da A ad E (etichetta 21).
3. A questo punto il LSR B riceve due messaggi RESV con identico “P2MP Session Object”. E qui sta l’aspetto chiave della segnalazione: il LSR B associa ad entrambi i sub-LSP con identico “P2MP Session Object” la stessa etichetta MPLS (etichetta 16 nella figura). In conseguenza di ciò, il LSR B invia al LSR di ingresso A due messaggi RESV con identico “Label Object” contenente la stessa etichetta MPLS, e identico “P2MP Session Object” (NOTA: la RFC 4875 non obbliga l’invio di due messaggi RESV separati, ma contempla la possibilità di inviarne solo uno. Alcuni costruttori inviano inizialmente due messaggi RESV separati, e successivamente come rinfresco inviano un solo messaggio RESV).

Riassumendo, l’aspetto chiave della segnalazione RSVP-TE è la seguente regola: quando un LSR riceve messaggi RESV con identico “P2MP Session Object”, associa ai relativi sub-LSP la stessa etichetta MPLS.
Un LSR che riceve messaggi RESV con identico “P2MP Session Object” diventa così automaticamente un punto di diramazione del LSP P2MP.
Solo per fare un esempio pratico, i due comandi di tipo “show” seguenti, eseguiti su un router Juniper, mostrano le caratteristiche di un LSP MPLS P2MP realizzato via RSVP-TE, sul LSR di ingresso (PE1) e sul LSR di transito successivo (P1):
 
tt@PE1> show rsvp session p2mp ingress
Ingress RSVP: 2 sessions
P2MP name: 1:1:mvpn:VPN-A, P2MP branch count: 2
To                   From               State   Rt Style Labelin Labelout    LSPname
192.168.0.3  192.168.0.1    Up       0  1 SE       -         299840      192.168.0.3:1:1:mvpn:VPN-A
192.168.0.2  192.168.0.1    Up       0  1 SE       -         299840      192.168.0.2:1:1:mvpn:VPN-A
Total 2 displayed, Up 2, Down 0
 
tt@P1> show rsvp session p2mp transit
Transit RSVP: 2 sessions
P2MP name: 1:1:mvpn:VPN-A, P2MP branch count: 2
To                     From                State   Rt Style   Labelin   Labelout  LSPname
192.168.0.3    192.168.0.1    Up    0  1 SE         299840   299856   192.168.0.3:1:1:mvpn:VPN-A
192.168.0.2    192.168.0.1    Up    0  1 SE         299840   299840   192.168.0.2:1:1:mvpn:VPN-A
Total 2 displayed, Up 2, Down 0
 
Il LSP MPLS P2MP ha due sub-LSP (P2MP branch count: 2), entrambi con sorgente PE1 (RID 192.168.0.1) e destinazione due LSR: PE2 (RID 192.168.0.2) e PE3 (RID 192.168.0.3).
La visualizzazione riporta anche le etichette MPLS utilizzate. Sul LSR di ingresso, l’etichetta entrante ovviamente non esiste (Labelin – ), mentre l’etichetta uscente è per entrambi i sub-LSP pari a 299840 (Labelout 299840).
Sul primo LSR di transito incontrato (P1) l’etichetta entrante per entrambi i sub-LSP è 299840, mentre le etichette uscenti sono rispettivamente 299856 (per il sub-LSP con destinazione PE3) e 299840 (per il sub-LSP con destinazione PE2). Tutto ciò significa che P1 è un punto di diramazione del LSP P2MP. 
L’esempio è tratto dalla configurazione di un servizio NG-MVPN. Si noti che il JUNOS assegna automaticamente dei nomi sia al LSP P2MP che ai singoli sub-LSP:
•       Nome LSP P2MP = RD : mvpn : nome-VRF.
•       Nome sub-LSP = RID LSR di uscita : RD : mvpn : nome-VRF.
 
RSVP-TE P2MP LSP NEL MODELLO NG-MVPN 
Un aspetto molto importante, che differenzia il trasporto via MPLS del traffico VPN multicast da quello VPN unicast è che, mentre quest’ultimo viene trasportato utilizzando due etichette MPLS, il traffico VPN multicast viene trasportato utilizzando una sola etichetta MPLS.
Per indirizzare la VRF (o spesso, l’interfaccia) di uscita, il traffico VPN unicast utilizza come noto la seconda etichetta (interna), annunciata via MP-iBGP dal PE destinazione del traffico. Per contro, per indirizzare la mVRF di uscita, il traffico VPN multicast utilizza l’etichetta generata dal PE destinazione durante la fase di segnalazione del sub-LSP. Ciò significa che in questo contesto non viene applicato il Penultimate Hop Popping.
La figura seguente, tratta da un esempio reale in ambiente Juniper, riporta un esempio.
 

 
Il LSR PE1 è radice di un albero multicast (di tipo Selective o Inclusive, non fa differenza) e i LSR PE2 e PE3 sono due foglie. Tra PE1, PE2 e PE3 viene realizzato un LSP MPLS P2MP, costituito da due sub-LSP:

1. sub-LSP1 : origine PE1, destinazione PE2.
2. sub-LSP2 : origine PE1, destinazione PE3.

I LSR destinazione PE2 e PE3 generano rispettivamente per i due sub-LSP, le etichette 16 e 299.850 (la discrepanza tra l’ordine di grandezza di questi due valori dipende dal tipo di configurazione che si esegue nelle mVRF).
Il LSR PE1 incapsula il traffico multicast con l’etichetta MPLS 299.792, generata dal LSR P1, che è un punto di diramazione del LSP MPLS P2MP. Il LSR P1 genera due pacchetti MPLS, uno verso PE2 con etichetta 16 (generata da PE2 e associata al sub-LSP 1) e l’altro verso P2 con etichetta 299.792 (generata da P2 e associata al sub-LSP 2). Infine, P2 esegue la commutazione di etichetta da 299.792 a 299.850 (generata da PE3 e associata al sub-LSP 2) e inoltra il pacchetto MPLS verso PE3.
Ora, PE2 e PE3 utilizzano rispettivamente le etichette 16 e 299.850 per effettuare il lookup sulla tabella di routing multicast associata alla MVPN (ossia, sulla mVRF corretta).
 
CONCLUSIONI
In questo post ho illustrato il concetto di LSP MPLS multipoint di tipo P2MP, trattando in particolare la realizzazione di LSP MPLS P2MP tramite la segnalazione RSVP-TE. In un prossimo post sull’argomento illustrerò come sia invece possibile realizzare LSP P2MP e MP2MP via mLDP, mettendo a confronto i due tipi di segnalazione. Per motivi di spazio ho dovuto saltare alcuni aspetti, sui quali magari mi riprometto di tornare in seguito.
Ricordo che per chi volesse approfondire queste tematiche, abbiamo nel catalogo corsi della Reiss Romoli, un corso ad hoc di due giorni sul modello NG-MVPN (IPN269, Next Generation Multicast VPN), dove l’argomento dei LSP MPLS multipoint viene trattato con dovizia di particolari e dove sono previste esercitazioni con piattaforme Juniper.

• I comandi di configurazione di base (assegnazione del NET, abilitazione delle interfacce a IS-IS, scelta del tipo di IS, elezione del DIS, definizione delle metriche, ecc.).
• I comandi per configurare l’aggregazione dei prefissi e le modalità di configurazione.
• La procedura di configurazione del Route Leaking.
• I comandi di tipo “show …” e “traceoptions …” per la verifica della configurazione e la soluzione di problemi di troubleshooting.

PREMESSA
“Finita la festa, gabbato lo Santo” recita un vecchio detto. Finite le vacanze riprendo a scrivere su questo blog. Ho iniziato questa attività circa un anno fa (il primo post è datato 18 Settembre 2014) e in questo anno il blog si è arricchito di 30 post (31 con questo), ed ha avuto più di 10.000 visite totali.
Ho prodotto vari documenti che sono stati scaricati gratuitamente da centinaia di lettori, a riprova dell’interesse che questa iniziativa ha suscitato. Spero che la comunità si allarghi sempre di più e che questo blog divenga sempre più un punto d’incontro della comunità Italiana del Networking IP.
FINE DELLA PREMESSA

Con questo post voglio introdurre un argomento avanzato che ritengo di interesse. Come è noto, il servizio L3VPN (unicast) è stata la killer application che ha fatto decollare l’introduzione di MPLS nelle reti IP. Questo servizio è oggi offerto da (praticamente) tutti gli ISP mondiali, ed è anche utilizzato internamente da molte grandi reti Enterprise.
Poco più di 10 anni fa, questo servizio è stato esteso al traffico multicast, ossia alla possibilità per i Clienti VPN di veicolare traffico multicast sulla propria VPN. Si parla in questo caso di servizio MVPN (Multicast VPN).
Il primo modello di MVPN, supportato soprattutto da Cisco, ma implementato anche nei router Juniper, è il modello basato sul draft-rosen-vpn-mcast, anche noto come Draft-Rosen. Benché oggi è classificato come historical, è ancora quasi sempre quello implementato nelle applicazioni pratiche. Faccio notare però, che nonostante ciò, il Draft-Rosen non è mai diventato RFC !
L’idea alla base del modello Draft-Rosen è abbastanza intuitiva: rendere il backbone IP/MPLS, agli occhi dei router CE, simile ad una LAN. Nel paragrafo successivo ne illustrerò le idee fondamentali.
Il modello Draft-Rosen si è però dimostrato poco scalabile e soprattutto non conforme al modello generale di VPN BGP/MPLS, non utilizzando il BGP sul piano di controllo, né MPLS sul piano dati (anche se alcuni concetti del modello L3VPN unicast BGP/MPLS sono comunque utilizzati, come ad esempio il concetto di VRF). Per questo motivo è stato sviluppato un nuovo modello, denominato NG-MVPN (Next Generation-MVPN), che si integra perfettamente con il modello di L3VPN unicast BGP/MPLS. Il nuovo modello, supportato soprattutto da Juniper, ma anche da Cisco nell’IOS XR, utilizza il BGP nel piano di controllo, mentre sul piano dati può utilizzare varie alternative, tra cui la più importante è costituita da LSP MPLS Point-to-Multipoint (LSP MPLS P2MP) realizzati via mLDP (= multipoint LDP) o RSVP-TE (NOTA: affronterò in un post successivo la realizzazione di LSP MPLS P2MP).
Il modello NG-MPVN è definito dalle seguenti due RFC, entrambe pubblicate nel Febbraio 2012:

• RFC 6513 : Multicast in MPLS/BGP IP VPNs.
• RFC 6514 : BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs.

DUE PAROLE SUL MODELLO DRAFT-ROSEN
L’idea base del modello di MVPN basato sul Draft-Rosen, è quella di costruire all’interno del backbone BGP/MPLS, un albero multicast dedicato al trasporto del traffico multicast di ciascun Cliente (Multicast Distribution Tree, MDT) .
Anche i router P partecipano alla realizzazione dell’albero multicast interno, e quindi su questi router è richiesta la configurazione di protocolli di routing multicast (cosa che, si vedrà, non è necessaria nel modello NG-MVPN).
Altro aspetto fondamentale di questo modello è che il traffico multicast dei Clienti viene trasportato utilizzando Tunnel GRE, dove l’indirizzo IP destinazione è un indirizzo multicast che identifica l’albero interno.
È interessante notare che né il piano di controllo utilizza il BGP (utilizza invece un protocollo di routing multicast per costruire l’albero interno), né il piano dati utilizza MPLS.
Nell’architettura del servizio MVPN basato sul modello Draft-Rosen, possono essere evidenziate diverse tipologie di adiacenze; in primo luogo, non appena viene costruita una VRF relativa ad una particolare MVPN all’interno di un router PE, questa dà origine ad una adiacenza fra lo stesso router PE ed il router CE al quale è attestato il cliente appartenente alla VPN (previa configurazione dei protocolli di routing multicast, ovviamente).
Il router PE inoltre costruisce altri due tipi di adiacenze: la prima con i router PE all’interno dei quali è stata configurata una VRF relativa alla stessa MVPN, la seconda a livello globale con gli altri router P e PE suoi vicini.
Le adiacenze costruite fra PE relativi alla stessa MVPN servono a distribuire tra i PE, le informazioni di routing multicast scambiate con i CE della stessa MVPN (ruolo che nel modello L3VPN unicast BGP/MPLS è demandato al BGP). Poiché lo scambio di queste informazioni di routing multicast tra PE è relativo a ciascuna singola MVPN, il numero delle adiacenze tra PE dipende dal numero delle MVPN configurate su quel PE. La figura seguente mostra ad esempio, che tra PE-1 e PE-2 sono stabilite due diverse adiacenze PIM, una per ciascuna MVPN.
Si noti che ciò è profondamente diverso (e meno scalabile !) da quanto avviene nel modello L3VPN unicast BGP/MPLS, dove tra PE, per lo scambio delle informazioni di routing di tutte le MVPN, viene utilizzata una singola sessione BGP.
 

 
Le adiacenze PIM costruite fra i router PE e i router P (e tra i router P) sono invece utilizzate per realizzare la costruzione dei Multicast Distribution Tree  (MDT) che collegano le varie VRF di ciascuna MVPN. Si noti che è necessario un MDT per ciascuna MVPN, anche se l’istanza PIM utilizzata per la costruzione degli MDT è unica (in altre parole, gli stati (*, G) e (S, G) degli MDT, utilizzano tutti la tabella di routing multicast globale).
Il modello su cui si basa la rete di un ISP che offre servizi MVPN è simile a quello presente nelle L3VPN BGP/MPLS unicast :

• I router P contengono informazioni a livello di routing globale e non sono informati circa le sorgenti e i ricevitori appartenenti alle varie VPN, né tantomeno degli alberi multicast ad essi relativi.
• I router CE hanno adiacenze del protocollo di routing multicast solo con i router PE ai quali sono attestati, e possono scambiare informazioni di routing multicast, pur non avendone conoscenza, con gli altri router CE appartenenti alla stessa MVPN. Le informazioni di routing multicast sono trasportate dal Multicast Distribution Tree.

All’interno della rete di un ISP vengono realizzati due tipi di alberi multicast:

• Default-MDT: è l’albero iniziale creato per ciascuna MVPN; serve a trasportare i messaggi del protocollo di routing multicast (PIM) e dati a bassa velocità. È un albero di tipo “inclusivo”, nel senso che congiunge tutti i PE dove sono configurate mVRF della stessa istanza MVPN.
• Data-MDT: è un albero ottimizzato che entra in funzione solo nei casi in cui qualche sorgente superi una soglia configurata di banda, oltre la quale il traffico multicast viene trasportato sul Data-MDT. È un albero di tipo “selettivo”, nel senso che congiunge tutti i PE dove sono configurate mVRF della stessa istanza MVPN, dove però sono attestati le sorgenti e i ricevitori di traffico multicast della MVPN.

 

 
I pacchetti multicast generati dai router CE (C-packet) sono trasportati all’interno della rete dell’ISP utilizzando Tunnel GRE. L’intestazione IP dei pacchetti inseriti nei Tunnel GRE (P-Packet), ha come indirizzo IP destinazione l’indirizzo del gruppo multicast che l’ISP ha assegnato alla MVPN, e indirizzo IP sorgente l’indirizzo di una interfaccia (tipicamente di Loopback) del PE che inserisce il pacchetto nel Tunnel.


 
I LIMITI DEL MODELLO DRAFT-ROSEN
Il modello Draft-Rosen ha varie limitazioni, che hanno portato IETF a definire un nuovo modello di MVPN:

• Scarsa compatibilità con il modello di VPN IP BGP/MPLS (es. segnalazione basata su PIM e non su BGP, trasporto basato su Tunnel GRE piuttosto che su MPLS, ecc.) .
• Scalabilità del piano di controllo (necessità di mantenere sui PE un elevato numero di adiacenze PIM).  Questo perché il modello draft-Rosen utilizza un modello di tipo Virtual Router (vedi nota sotto).
• Necessità di estendere il protocollo PIM anche ai router P, per realizzare gli alberi Default-MDT e Data-MDT. Questo ha come conseguenza che i router P devono mantenere uno stato per-MVPN. Per contro nel modello L3VPN unicast i router P non hanno alcuno stato riguardante le singole VPN. Inoltre, ulteriore conseguenza è che è necessario definire manualmente un indirizzo multicast per MVPN  per realizzare l’albero MDT, aumentando le complessità di configurazione.
• Elevato ritardo nella diffusione dei messaggi Join/Prune.

Per ulteriori limitazioni del modello basato sul Draft-Rosen, vedi "draft-rekhter-mboned-mvpn-deploy - PIM/GRE Based MVPN Deployment Experience and Recommendations, Dicembre 2008".

NOTA (CULTURALE): il modello Virtual Router, definito nella RFC 4110 - A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs), Luglio 2005, prevede che lo scambio di informazioni di routing tra PE avvenga realizzando istanze separate di routing, una per ciascuna VPN. Inoltre, lo scambio di traffico dati tra PE avviene realizzando tunnel separati per ciascuna VPN, dove logicamente questi tunnel sono tra VRF della stessa istanza VPN. I tunnel vengono utilizzati come fossero normali link tra router (virtuali), e quindi trasportano anche le informazioni del piano di controllo, creando un forte accoppiamento tra piano dati e piano di controllo.
Il Draft-Rosen si basa proprio un modello di tipo Virtual Router, poiché una data VRF su un dato PE, deve mantenere adiacenze PIM con ogni altra VRF appartenente a quella MVPN su ogni altro PE. Inoltre, queste adiacenze devono essere mantenute non per PE, ma per MVPN. Un PE inoltre deve anche mantenere adiacenze PIM con tutti i CE collegati localmente.
Fino a che il numero medio di siti MVPN collegati ad un dato PE è inferiore rispetto al numero medio di PE che hanno siti di tale MVPN, per un dato PE il sovraccarico di mantenere adiacenze PIM con altri PE dominerà il sovraccarico di adiacenze PIM PE-CE. Si noti che questo sovraccarico cresce con il numero di PE di una istanza MVPN, nonché con il numero di MVPN. Ad esempio, consideriamo il caso di un PE con 1.000 VRF, e ciascuna di queste VRF corrisponda a una MVPN che in media è presente su 100 PE. Il numero medio di adiacenze PIM PE-PE che il PE dovrebbe mantenere è 100.000 e, considerando il periodo di default dei messaggi PIM Hello (= 30 sec), il numero medio di PIM Hello che il PE dovrebbe elaborare è 3.300 al secondo.
 
IL NUOVO MODELLO NG-MVPN
Per ovviare agli inconvenienti del modello Draft-Rosen, in particolare alla sua scarsa scalabilità, IETF ha definito un nuovo modello di MVPN (Next Generation-MVPN, NG-MVPN), che include comunque come caso particolare, il modello Draft-Rosen. Il nuovo modello si basa sui seguenti principi:

• Segnalazione via BGP (più precisamente attraverso sessioni MP-iBGP).
• Possibilità di trasporto del traffico multicast via MPLS.
• Maggiore integrazione con il modello di VPN IP BGP/MPLS unicast.

In ultima analisi, NG-MVPN può essere considerato come un servizio aggiuntivo di una L3VPN basata sul modello BGP/MPLS.

NOTA (CULTURALE): facendo un paragone con il modello Draft-Rosen, mentre questo, come detto nel paragragfo precedente, utilizza un modello Virtual Router, NG-MVPN utilizza un modello Aggregated Router (sempre secondo la definizione della già citata RFC 4110).
Il modello Aggregated Router utilizza, per lo scambio delle informazioni di routing VPN, una singola istanza di un protocollo di routing (che nel modello NG-MVPN è il MP-iBGP). Le informazioni di routing di più VPN sono quindi «aggregate» e trasportate dalla medesima istanza di routing (il processo MP-iBGP).
Come nel modello Virtual Router, anche il modello Aggregated Router trasporta il traffico dati su tunnel separati per ciascuna VPN. Ma a differenza del modello Virtual Router, il modello Aggregated Router utilizza questi tunnel esclusivamente per il trasporto dei dati e non delle informazioni del piano di controllo. Il risultato è una netta separazione del piano di controllo dal piano dati. Questo aspetto facilita l’utilizzo di diverse tecniche sul piano dati, cosa che non avviene ad esempio nel modello Draft-Rosen, che basandosi sul modello Virtual Router ha bisogno di un protocollo sul piano dati in grado di trasportare anche informazioni di routing, come ad esempio i tunnel GRE.
 
NG-MVPN: IL PIANO DI CONTROLLO
Nelle L3VPN unicast, le informazioni di routing dei siti VPN, costituite dai prefissi IP locali dei siti, vengono propagate:

•  Localmente da CE a PE attraverso un qualsiasi protocollo di routing PE-CE (statico, dinamico).
• Tra i PE della rete del Service Provider, attraverso sessioni MP-iBGP, dove il NLRI è costituito da un prefisso IP, con anteposto il Route Distinguisher.

Nel caso di routing multicast, l’informazione da propagare è costituita dai messaggi PIM-join e PIM-prune che il PE riceve dai CE. Una delle idee principali dietro il modello NG-MVPN è stata quella di riconoscere che questi messaggi PIM sono semplicemente delle informazioni di routing del Cliente (dette anche C-multicast route), che possono essere propagate all’interno della rete del Service Provider, al pari delle informazioni di routing dei siti L3VPN unicast, attraverso sessioni MP-iBGP (ovviamente, con diversa address family). Questo è diverso dal modello Draft-Rosen, che invece utilizza il protocollo PIM per trasportare queste informazioni.
Si potrebbe pensare a questo approccio come a un modo di redistribuire informazioni di routing da un protocollo (PIM) ad un altro (BGP). Il concetto di redistribuzione è ben noto in un ambiente unicast, dove ad esempio è possibile redistribuire route apprese via OSPF in BGP. Quello che accade nel modello NG-MVPN è una estensione di questo concetto alle route multicast, che apprese via PIM dai router CE, vengono propagate via MP-iBGP e quindi ripropagate da MP-iBGP in PIM: una sorta di redistribuzione PIM →BGP →PIM.
La figura seguente riporta schematicamente la logica del piano di controllo.
 

 
Le informazioni di routing multicast, ossia, le C-multicast route, vengono propagate da CE a PE attraverso il protocollo PIM. Il trasporto all’interno della rete del Service Provider avviene "codificando" in modo opportuno le informazioni di routing multicast in annunci MP-iBGP. A destinazione, il router PE "decodifica" gli annunci BGP e quindi invia i messaggi PIM al CE di destinazione. Si noti che i router CE sono completamente ignari del meccanismo utilizzato dai PE per propagare le C-multicast route. Dal loro punto di vista, può essere utilizzato qualsiasi protocollo. Questa è comunque una caratteristica di tutti i servizi VPN basati sul modello BGP/MPLS.
L’aspetto chiave del piano di controllo è la definizione di come le C-multicast route apprese dai PE via PIM, vengono "codificate" in annunci BGP. Questo è un aspetto molto complesso, di cui darò solo qualche cenno.
La maggiore novità (non l'unica) del modello NG-MVPN è quindi che il piano di controllo, così come avviene per i servizi L3VPN unicast, è basato sul BGP. In particolare, è necessaria una maglia completa di sessioni MP-iBGP tra i router PE, che può essere realizzata per maggiore scalabilità, utilizzando dei Route Reflector.
Per lo scambio delle informazioni di routing (multicast) necessarie al funzionamento del modello NG-MVPN, è stata definita una nuova famiglia di indirizzi e un associato codice SAFI = 5 (Address Family MCAST-VPN). Il codice AFI è come sempre 1 per la famiglia di indirizzi IPv4 e 2 per la famiglia di indirizzi IPv6.
Per il funzionamento del modello sono stati definiti 7 nuovi tipi di NLRI, il cui formato generale è riportato nella figura seguente (codifica TLV).


 
Sul significato e sull’utilizzo dei vari tipi di NLRI sono costretto a “glissare”, data la loro complessità. In questo post voglio solo esporre le idee di fondo, magari in post successivi darò qualche dettaglio in più.
Il piano di controllo di un modello per la realizzazione di MVPN assolve tre funzioni importanti:

• Auto-Discovery: nelle L3VPN unicast non vi è bisogno di alcun meccanismo di Auto-Discovery: un PE apprende dell’esistenza di un sito remoto quando riceve dal PE dove è attestato il sito remoto, annunci MP-iBGP di reti presenti nel sito. Le MVPN per contro, hanno bisogno di conoscere in anticipo la localizzazione di sorgenti e ricevitori di traffico C-multicast.
• Segnalazione dei messaggi PIM join/prune tra siti MVPN: il modello NG-MVPN utilizza sessioni MP-iBGP. Per contro, nel modello Draft-Rosen vengono utilizzate adiacenze PIM tra PE.
• Segnalazione dei P-tunnel (NOTA: i P-tunnel (Provider-tunnel) sono i tunnel utilizzati nella rete dell’ISP per trasportare il traffico multicast dei Clienti MVPN): il modello NG-MVPN, supporta vari tipi di P-tunnel, di cui alcuni basati su MPLS. Questa è la scelta considerata migliore a causa delle ricche funzionalità supportate da MPLS (traffic engineering, fast rerouting, supporto della QoS, ecc.). Il modello prevede comunque la possibilità di utilizzare P-tunnel basati sul protocollo PIM, come nel Draft-Rosen. Questo è possibile perché nel modello NG-MVPN vi è un totale disaccoppiamento tra piano di controllo e piano dati (ricordo che NG-MVPN utilizza un modello di tipo aggregated router).

 
NG-MVPN: IL PIANO DATI
Un altro aspetto dove il modello NG-MVPN si differenzia totalmente dal modello Draft-Rosen, è il piano dati, ossia le modalità con cui i pacchetti multicast sono trasportati all’interno della rete del Service Provider.
Il modello NG-MVPN prevede varie modalità di trasporto, tra cui come caso particolare anche i tunnel GRE segnalati via PIM (SM/SSM/BiDir), utilizzati nel modello Draft-Rosen. Ma il modello NG-MVPN prevede anche l’utilizzo di MPLS, attraverso la realizzazione di LSP MPLS di tipo Point-to-Multipoint (LSP P2MP). Questi LSP possono essere realizzati attraverso una estensione del protocollo RSVP-TE utilizzato per i LSP MPLS Point-to-Point (P2P), oppure attraverso una estensione del protocollo LDP, detta multipoint LDP (mLDP). In realtà, per emulare una modalità tipo PIM BiDir, è previsto anche l’utilizzo di LSP MPLS Multipoint-to-Multipoint (LSP MP2MP), realizzabili però solo attraverso mLDP.
Il punto chiave è che il piano di controllo e piano dati sono completamente disaccoppiati. Questo implica che una volta noti i PE che partecipano alla stessa istanza NG-MVPN, noti i PE dove sono connesse (attraverso i CE) le sorgenti di traffico e noti i PE dove sono connessi (sempre attraverso i CE) i ricevitori, il trasporto del traffico multicast può essere realizzato con una qualsiasi tecnica, realizzando alberi di distribuzione multicast all’interno della rete del Service Provider (Default-MDT e Data-MDT). 
La tendenza attuale, per motivi di scalabilità e compatibilità con il modello BGP/MPLS, è quella di utilizzare LSP MPLS P2MP, realizzati via RSVP-TE o mLDP. La figura seguente ne riporta l’idea base.
 

 
La RFC 6514 prevede 7 modalità di trasporto. La modalità utilizzata viene segnalata sul piano di controllo, attraverso il nuovo attributo BGP "PMSI Tunnel", che viene associato agli annunci MCAST-VPN con NLRI di tipo 1, 2 e 3.  La figura seguente ne riporta il formato.
 

Il tipo di P-tunnel per il trasporto del traffico C-multicast e la modalità di segnalazione sono specificati nel campo Tunnel Type. I valori utilizzati sono riportati nella figura e ufficializzati nella RFC 7385, IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points, Ottobre 2014. Il P-tunnel più utilizzato nelle applicazioni pratiche è costituito da LSP MPLS P2MP segnalati attraverso RSVP-TE o mLDP (estensione multipoint di LDP). Il Draft-Rosen utilizza Tunnel Type di tipo 3, 4 o 5.
 
CONSIDERAZIONI FINALI
In questo post ho introdotto il nuovo modello NG-MVPN per la realizzazione di servizi L3VPN multicast. Il modello è supportato sia nelle piattaforme Cisco che Juniper. Benché ancora poco noto, il modello NG-MVPN è già stato implementato con successo in Italia da un grande provider di servizi di comunicazione via satellite.
Il funzionamento è molto complesso e, parodiando il celebre magistrato-matematico Pierre de Fermat “dispongo di una ampia presentazione che però non entra nello spazio concesso a questo blog”. Però magari in futuro qualche dettaglio in più cercherò di darlo.
Comunque, se volete saperne di più, ho inserito nel nostro catalogo di corsi tecnici, un corso ad hoc di due giorni sull’argomento (IPN269, Next Generation Multicast VPN), dove tutto viene trattato con dovizia di particolari e dove sono previste esercitazioni con piattaforme Juniper.

• I messaggi NHRP Resolution Request non sono più innescati da adiacenze "invalid" e "glean" della tabella CEF. L'implicazione più importante di questo punto è che non è necessario mantenere negli annunci del protocollo di routing il Next-Hop originale, e quindi è possibile eseguire aggregazioni di prefissi sugli Hub.
• I router Hub non sono più le sole fonti di informazioni NHRP, ma al gioco partecipano anche i router Spoke. Oltre a un modello NHRP client-server, DMVPN fase 3 utilizza anche un modello NHRP di tipo peer-to-peer.
• I messaggi NHRP Reply contengono informazioni su un intero prefisso, invece che delle sole informazioni sulla risoluzione del Next-Hop.

1. Sui soli router Hub il comando "ip nhrp redirect", che abilita l'invio dei messaggi NHRP Redirect.
2. Sui soli router Spoke il comando "ip nhrp shortcut", che consente di riscrivere sulla tabella CEF il nuovo Next-Hop comunicato attraverso il messaggio NHRP Redirect. Si noti che senza questo comando un router Spoke si comporta esattamente come in un modello DMVPN fase 1, con il traffico Spoke-Spoke che fa sempre transito su un router Hub.

1. Non è possibile, sui router Hub, effettuare aggregazione di prefissi con il comando "ip summary-address eigrp numero-AS prefisso maschera" a livello interfaccia "tunnel X", altrimenti il prefisso aggregato verrebbe annunciato con il Next-Hop del router Hub, impedendo la comunicazione diretta Spoke-Spoke. In particolare, non è possibile utilizzare il comando "ip summary-address eigrp numero-AS 0.0.0.0 0.0.0.0" per generare una default-route, altrimenti non verrebbero annunciati dal router Hub i prefissi ricevuti dai router Spoke.
2. Ricordare di disabilitare sui soli router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".
3. Ricordare che è buona pratica abilitare la funzionalità EIGRP Stub sui router Spoke.

1. Disabilitare sui router Hub, con il comando "no ip next-hop-self eigrp numero-AS", il "Next-Hop self" automatico dell'EIGRP. 
2. Disabilitare sui router Hub lo split-horizon con il comando "no ip split-horizon eigrp numero-AS".
3. Non effettuare sui router Hub aggregazione di prefissi con il comando "ip summary-address eigrp ..." a livello interfaccia "tunnel X".
4. Abilitare la funzionalità EIGRP Stub sui router Spoke.

1. Abilitare sulle interfacce "tunnel X" di tutti i router, la modalità OSPF su reti NBMA "broadcast" (comando "ip ospf network broadcast").
2. Definire sui router Spoke una priorità nulla per l'elezione di DR e BDR.
3. (Opzionale) Configurare sui router Spoke delle default-route statiche verso i router Hub.  

1. E' richiesto l'utilizzo di un solo numero di AS. Per contro, con sessioni eBGP è necessario utilizzare più numeri di AS, al limite un numero di AS per ciascun router.
2. L'utilizzo del trucchetto dei BGP Dynamic Neighbor diviene molto più semplice, aumentando di molto la scalabilità della configurazione.
3. Utilizzando sessioni iBGP è possibile sfruttare la funzionalità BGP Route Reflection, eleggendo (via configurazione) i router Hub come Route Reflector (RR) e i router Spoke come Route Reflector Client (RRC). Ricordo che i RR non cambiano il BGP Next-Hop quando riflettono gli annunci ai RRC, e questo è fondamentale per l'applicazione del modello DVPN Fase 2.

• I comandi di configurazione di base (assegnazione del NET, abilitazione delle interfacce a IS-IS, scelta del tipo di IS, elezione del DIS, definizione delle metriche, ecc.).
• I comandi per configurare l’aggregazione dei prefissi e le modalità di configurazione.
• La procedura di configurazione del Route Leaking.
• I comandi di tipo “show …” e “debug …” per la verifica della configurazione e la soluzione di problemi di troubleshooting.