“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.
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.
- 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.
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.
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.
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.
