MPLS News : LSP di tipo Multipoint – Parte I

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, e nel caso di LDP anche di LSP MPLS MP2MP.

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), 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, Febbraio 2015. Su questo modello EVPN scriverò in seguito qualche post poiché lo ritengo molto importante (anche se io ho una certa idiosincrasia per tutto ciò che riguarda 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 nella 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. Maggiori informazioni nel prossimo post su mLDP.

FORWARDING DEL 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 a quello 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 router 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 ("Explicit Route Object"), 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 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 (implicit-null) ai due sub-LSP, 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 (vedi post su NG-MVPN).

Per indirizzare la VRF (o spesso, l’interfaccia) di uscita, il traffico VPN unicast utilizza come noto la seconda etichetta (quella interna, sovente indicata come service label), 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:

• sub-LSP-1 : origine PE1, destinazione PE2.
• sub-LSP-2 : 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.