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 multipoint LDP, abbreviato in mLDP (NOTA: nella documentazione di qualche vendor, mLDP viene indicato impropriamente come “multicast LDP”. La RFC 6388 utilizza invece la terminologia “multipoint LDP”).
mLDP, a differenza di RSVP-TE, consente la realizzazione di LSP MPLS sia di tipo P2MP che MP2MP, questi ultimi utilizzati ad esempio in alcuni contesti come il modello PIM-Bidir.
INTRODUZIONE
Per la segnalazione di LSP MPLS di tipo multipoint, mLDP utilizza, nei messaggi LABEL MAPPING, tre nuovi moduli TLV, il cui formato è riportato nel seguito. In realtà i tre moduli hanno identico formato, cambia solo il campo “Type” che identifica il tipo di modulo. I nuovi moduli contengono informazioni su tipo di LSP (P2MP/MP2MP), indirizzo IPv4/IPv6 del nodo radice e un valore “opaco” dipendente dal tipo di servizio.
Il meccanismo di segnalazione è analogo a quello per la realizzazione dei LSP di tipo punto-punto, e verrà descritto nelle sue linee generali nelle prossima sezione.
Nelle applicazioni dei LSP multipoint al modello NG-MVPN, un aspetto importante che differenzia mLDP da RSVP-TE è che mentre la segnalazione dei LSP P2MP realizzati via RSVP-TE, inizia dal nodo sorgente, la segnalazione dei LSP P2MP realizzati via mLDP segue la logica classica del downstream label allocation tipica del protocollo LDP, che inizia dai nodi destinazione. Questo pone il problema della conoscenza della sorgente dell’albero multicast da parte delle destinazioni. Questo problema è disaccoppiato dalla costruzione del LSP P2MP, ed è risolto manualmente attraverso una opportuna configurazione (si noti che, per contro, nel caso di segnalazione via RSVP-TE la sorgente “impara” l’identità delle destinazioni del traffico multicast, attraverso opportuni messaggi BGP della famiglia di indirizzi MCAST-VPN).
IDENTIFICAZIONE DI LSP MULTIPOINT
Assumendo nota l’identità della radice dell’albero, sia esso di tipo P2MP o MP2MP, un problema chiave è come identificare un LSP di tipo multipoint. Questo aspetto è fondamentale per stabilire i corretti stati di forwarding sui rami dell’albero multicast.
Una prima informazione necessaria è certamente l’identità del nodo radice. Ma da sola questa informazione non è sufficiente, poiché da un nodo radice possono originare più LSP P2MP.
Così, è necessario identificare non solo la radice, ma anche il LSP che parte dalla radice. LDP non ha alcun bisogno di essere informato sulla semantica dell’identificativo del LSP; dal suo punto di vista l’identificativo è un valore “opaco”.
La soluzione è analoga a quella già vista nel post precedente, adottata dalla segnalazione RSVP-TE: un LSP di tipo multipoint è identificato dalla coppia <IP-Radice; Valore Opaco>. Il valore effettivo del secondo elemento può essere assegnato in modo arbitrario e può anche essere derivato dal tipo di servizio.
Ricordo che i LSP di tipo P2P realizzati via LDP seguono i percorsi del protocollo IGP. Per una FEC (Forwarding Equivalence Class) costituita da una subnet IP, questo implica che l’etichetta uscente utilizzata da ciascun router è quella annunciata dal Next-Hop IGP nel percorso verso la subnet IP. Per contro, nei LSP di tipo multipoint, l’etichetta annunciata da un router è relativa al percorso IGP verso la radice dell’albero. Quindi per l’allocazione delle etichette viene seguito il percorso a ritroso verso la radice dell’albero, e non il percorso IGP che termina sulla destinazione del LSP P2P.
LSP DI TIPO P2MP
La figura seguente mostra il flusso di messaggi LDP LABEL MAPPING che consentono la realizzazione di un LSP P2MP. Nella figura, il nodo A è la radice mentre i nodi D ed E sono gli Edge-LSR di uscita. In un ambiente NG-MVPN, il nodo radice è il router dove è attestata la sorgente di traffico multicast, mentre gli Edge-LSR di uscita sono i router dove sono attestati i ricevitori del traffico multicast.
I messaggi LDP LABEL MAPPING VENGONO inviati a ritroso dai due Edge-LSR di uscita D ed E. Si noti che come per i LSP P2P, si utilizza una allocazione di etichette di tipo downstream.
Nell’esempio della figura, ecco ciò che avviene:
- Gli Edge-LSR di uscita D ed E inviano ai due router Next-Hop nel percorso IGP verso la radice A, due messaggi LDP LABEL MAPPING, ciascuno contenente una etichetta MPLS (inserita nel modulo “Label TLV”), e il modulo TLV comune “P2MP FEC TLV” (NOTA: Il Next-Hop IGP verso la radice, normalmente non coincide con l’indirizzo IP utilizzato per la sessione LDP, che di solito è una interfaccia di Loopback. Il problema viene però risolto poiché tramite il messaggio LDP ADDRESS, ogni LDP speaker conosce tutti gli indirizzi IP configurati sui propri LDP peer). Nelle applicazioni al servizio NG-MVPN non viene utilizzato il PHP, quindi gli Edge-LSR di uscita non associano l’etichetta speciale 3 ai due sub-LSP, ma due etichette arbitrarie. In applicazioni diverse dal servizio NG-MVPN, che richiedono l’applicazione del PHP, i due Edge-LSR di uscita utilizzano entrambi l’etichetta riservata 3.
- Il LSR C riceve il messaggio LABEL MAPPING e a sua volta ne genera un altro allocando la sua etichetta (= 70) associata alla “P2MP FEC TLV”. (NOTA: lo spazio di etichette utilizzato per i LSP P2MP è lo stesso utilizzato per i LSP P2P).
- A questo punto il LSR B riceve due messaggi LABEL MAPPING con identico “P2MP FEC TLV”. E qui sta l’aspetto chiave della segnalazione: il LSR B associa alla FEC <IP-radice ; Valore Opaco>, definita nel modulo “P2MP FEC TLV”, una etichetta MPLS (= 70 nella figura). In conseguenza di ciò, il LSR B invia al LSR di ingresso A un messaggio LABEL MAPPING con “Label TLV” contenente l'etichetta 70 e identico “P2MP FEC TLV”.
Un dettaglio interessante è anche come i LSR installano lo stato di forwarding MPLS. Le etichette entranti e uscenti sono determinate come al solito. Ad esempio, il LSR B avrà nella tabella di forwarding MPLS, in corrispondenza dell’etichetta entrante 70, due NHLFE uscenti: <30 ; IP-D> e <70 ; IP-C>, dove IP-D e IP-C rappresentano gli indirizzi IP Next-Hop rispettivamente dei LSR D e C. Questi ultimi sono determinati dagli indirizzi IP sorgente dei messaggi LDP HELLO (un quesito interessante, che vi lascio come esercizio è il seguente: perché gli indirizzi IP Next-Hop dei router D e C non possono essere determinati dagli indirizzi IP sorgente dei messaggi LABEL MAPPING ?).
Per chiudere questa sezione sulla realizzazione di LSP MPLS P2MP, è utile dare uno sguardo al modulo “P2MP FEC TLV”.
Il supporto del modulo “P2MP FEC TLV” viene negoziato tra LDP peer, utilizzando il messaggio LDP INITIALIZATION nella fase di realizzazione della sessione LDP, utilizzando delle LDP Capability (maggiori informazioni nella RFC 6388). Può anche essere negoziato a sessione già operativa utilizzando il nuovo messaggio LDP CAPABILITY, specificato nella RFC 5561 – LDP Capabilities, Luglio 2009.
Il formato del modulo “P2MP FEC TLV” è riportato nella figura seguente.
I vari campi hanno il seguente significato:
- P2MP Type : indica il tipo di LSP. Per LSP P2MP assume il valore 0x06, mentre per LSP MP2MP vi sono due possibilità, in funzione della direzione dell’annuncio: MP2MP downstream type (0x08) and MP2MP upstream type (0x07).
- Address-family: contiene il valore di address-family così come stabilito dallo IANA (1 per IPv4 e 2 per IPv6).
- Address length : lunghezza (in byte) dell’indirizzo contenuto nel campo Root Node Address. Può assumere i due valori 4 per indirizzi IPv4 e 16 per indirizzi IPv6.
- Root Node Address : indirizzo (IPv4 o IPv6) del nodo radice del LSP P2MP.
- Opaque Length : lunghezza (in byte) del campo Opaque Value.
- Opaque Value : contiene uno o più valori opachi, che insieme al Root Node Address, identificano univocamente il LSP P2MP.
Solo per fare un esempio pratico, il comando di tipo “show” seguente, eseguito su un router Cisco che utilizza l’IOS XR, mostra le etichette locali e remote di un LSP MPLS di tipo P2MP realizzato via mLDP, sul LSR di transito B della figura sopra:
RP/0/1/CPU0:LSR-B# show mpls mldp database
Wed Oct 14 10:24:45.204 UTC
mLDP database
LSM-ID: 0x00006 Type: P2MP Uptime: 1w1d
FEC Root : 10.0.0.1
Opaque decoded : [vpnv4 3269:1 192.168.0.1 232.1.2.3]
Upstream neighbor(s) :
10.0.0.1:0 [Active] Uptime: 1w1d
Next Hop : 10.0.1.1
Interface : GigabitEthernet0/2/1/1
Local Label (D) : 70
Downstream client(s):
LDP 10.0.0.3:0 Uptime: 1w1d
Next Hop : 10.0.3.1
Interface : GigabitEthernet0/2/1/2
Remote label (D) : 30
LDP 10.0.0.4:0 Uptime: 1w1d
Next Hop : 10.0.4.1
Interface : GigabitEthernet0/2/1/3
Remote label (D) : 70
La visualizzazione mostra, tra le altre informazioni, le etichette MPLS locale (= 70) e remote (30 ricevuta dal LSR D e 70 ricevuta dal LSR C), che vengono successivamente utilizzate sul piano dati. Questo significa che quando il LSR B riceve un pacchetto MPLS con etichetta 70, il pacchetto verrà replicato sulle due interfacce Gi0/2/1/2 e Gi0/2/1/3 con etichette MPLS rispettivamente 30 e 70.
LSP DI TIPO MP2MP
I LSP di tipo MP2MP sono l’equivalente del servizio PIM-BiDir nel routing multicast. Poiché il PIM-BiDir potrebbe non essere familiare a molti, prima di mostrare come realizzare LSP di MP2MP voglio spendere due parole su questa variante del protocollo PIM.
********* NOTA CULTURALE: DUE PAROLE SUL PIM-BIDIR *********
Il PIM-BiDir è forse la variante meno nota del protocollo PIM. Tutti conosciamo il PIM-DM (PIM – Dense Mode), il PIM-SM (PIM – Sparse Mode) e il PIM-SSM (PIM – Source Specific Multicast). Le ultime due varianti sono quelle più adottate nelle applicazioni pratiche. Tutte queste varianti hanno la loro naturale applicazione in scenari con poche sorgenti e molti ricevitori. PIM-BiDir (PIM – BiDirectional) è stato invece sviluppato per scenari dove ogni host può essere al contempo sorgente e ricevitore di traffico multicast. Un classico esempio è il servizio di videoconferenza, dove ciascun host al tempo stesso invia e riceve il segnale video/audio. Lo svantaggio di utilizzare PIM-SM in un simile scenario è che le tabelle di routing multicast conterrebbero molti stati, sia di tipo (S, G) che di tipo (*, G). Con il PIM BiDir invece, vengono solo costruiti stati di tipo (*, G).
Un’altra differenza fondamentale tra PIM-SM e PIM-BiDir è che mentre con PIM-SM il traffico fluisce dalle sorgenti verso Rendezvous-Point (RP) e da questo verso i ricevitori (solo successivamente il traffico fluisce sull’albero ottimizzato con radice il router che riceve dalla sorgente il traffico multicast), con PIM-BiDir il traffico multicast fluisce su uno spanning-tree (simile a quello costruito nelle reti L2 Switched, ma per fortuna qui non ci sono porte nello stato blocking !) che ha come radice il RP. In altre parole, con PIM-BiDir il traffico multicast fluisce sia nella direzione downstream, ossia dal RP verso i ricevitori, che in direzione upstream, ossia nella direzione opposta. Vi sono altri dettagli importanti che differenziano PIM-SM da PIM-BiDir (es. assenza del Reverse Path Forwarding, assenza della registrazione delle sorgenti, e altro), ma per quanto diremo sui LSP MPLS di tipo MP2MP, è sufficiente quanto ho detto sin qui, in particolare la modalità con cui il traffico viaggia sull’albero multicast (di tipo condiviso).
********* FINE NOTA CULTURALE *********
La realizzazione di un LSP MPLS di tipo MP2MP si basa sulla presenza di un nodo radice, scelto a piacere e identificato da un indirizzo IP (tipicamente un indirizzo di loopback). Oltre al nodo radice, il LSP, al pari di quanto visto per i LSP di tipo P2MP, è identificato anche qui da un valore “opaco”. Un LSP di tipo MP2MP è quindi identificato dalla coppia <IP-radice ; Valore Opaco>.
L’aspetto interessante è la procedura di realizzazione del LSP, ossia l’allocazione delle etichette MPLS e la creazione degli entry della tabella di forwarding MPLS (la LFIB !). Un LSP MPLS di tipo MP2MP può essere pensato come costituito da due sezioni, downstream e upstream. La sezione downstream è identica a quella vista sopra per i LSP di tipo MP2MP, mentre la sezione upstream è costituita da un classico LSP MP2P. Per capire meglio il funzionamento, è bene prima chiarire i concetti di direzione downstream e upstream del traffico che scorre sul LSP. La direzione downstream è quella dal nodo radice verso i nodi foglia, al contrario, la direzione upstream è quella dai nodi foglia verso il nodo radice.
Vediamo con un esempio come avviene la segnalazione. I messaggi LDP Label Mapping utilizzano i due moduli “MP2MP DOWNSTREAM FEC TLV” e “MP2MP UPSTREAM FEC TLV” , che hanno formato identico al modulo “P2MP FEC TLV” visto sopra, cambia solo il campo “Type”, che per il modulo “MP2MP DOWNSTREAM FEC TLV” è pari a 0x08 e per il modulo “MP2MP UPSTREAM FEC TLV” è invece pari a 0x07.
La figura seguente riporta il flusso dei messaggi LDP Label Mapping per la sezione downstream (parte (a) della figura) e per la sezione upstream (parte (b) della figura).
(a)
(b)
Si noti che la sezione upstream altro non è che la classica segnalazione di LSP MPLS unicast, tutti convergenti verso lo stesso LSR di uscita (per questo il LSP MPLS risultante viene detto Multipoint-to-Point, MP2P). Per vederlo, il lettore può divertirsi a ruotare la figura nella parte (b) di 90° in senso orario e ritroverà la classica segnalazione di LSP MPLS unicast, con i messaggi LABEL MAPPING che partono da più LSR di ingresso (nella figura D, C ed E) e si propagano fino al nodo radice (nella figura il LSR A).
Il piano dati a questo punto è semplice. Supponendo che da un LSR foglia parta un pacchetto MPLS destinato a tutti gli altri LSR foglia, questo seguirà un percorso nella direzione upstream (ossia, verso il nodo radice) fino a che non incontra un punto di diramazione verso un nodo foglia, dopodiché seguirà il percorso verso il nodo foglia in direzione downstream. Le etichette MPLS utilizzate nella direzione upstream sono quelle annunciate nei messaggi LDP LABEL MAPPING contenenti il modulo “MP2MP UPSTREAM FEC TLV” e analogamente, le etichette MPLS utilizzate nella direzione upstream sono quelle annunciate nei messaggi LDP LABEL MAPPING contenenti il modulo “MP2MP DOWNSTREAM FEC TLV”
La figura seguente riporta un esempio, che fa riferimento alle etichette annunciate nelle figure precedenti.
Lascio al lettore la verifica della correttezza delle etichette MPLS utilizzate.
Per chiudere, anche qui per fare un esempio pratico, il comando di tipo “show” seguente, eseguito su un router Cisco che utilizza l’IOS XR, mostra le etichette locali e remote di un LSP MPLS di tipo MP2MP realizzato via mLDP, sul LSR di transito B della figura sopra:
RP/0/1/CPU0:LSR-B# show mpls mldp database
Wed Oct 14 11:32:14.155 UTC
LSM-ID: 0x00001 Type: MP2MP Uptime: 1w2d
FEC Root : 10.0.0.1
Opaque decoded : [mdt 3269:1 0]
Upstream neighbor(s) :
10.0.0.1:0 [Active] Uptime: 1w2d
Next Hop : 10.0.1.1
Interface : GigabitEthernet0/2/1/1
Local Label (D) : 50 Remote Label (U): 40
Downstream client(s):
LDP 10.0.0.3:0 Uptime: 1w2d
Next Hop : 10.0.3.1
Interface : GigabitEthernet0/2/1/2
Remote label (D) : 70 Local label (U) : 70
LDP 10.0.0.4:0 Uptime: 1w2d
Next Hop : 10.0.4.1
Interface : GigabitEthernet0/2/1/3
Remote label (D) : 70 Local label (U) : 60
RSVP-TE o mLDP ?
Vi sono molte differenze tra la segnalazione di LSP MPLS multipoint via RSVP-TE o via mLDP, tra cui le più importanti sono:
- Con RSVP-TE la segnalazione è iniziata dal PE radice attraverso messaggi PATH e i PE downstream rispondono con messaggi RESV. Con mLDP la segnalazione è iniziata dai PE downstream, che inviano verso il PE radice messaggi Label Mapping.
- In RSVP-TE la segnalazione viene ripetuta periodicamente (soft state) mentre con mLDP è “una tantum” (hard state).
- Con RSVP-TE è possibile sfruttare le tecniche MPLS di Fast-ReRouting per proteggere traffico dalla caduta di un link e/o nodo, mentre con mLDP lo stesso risultato si può raggiungere attraverso la funzionalità di LFA (Loop Free Alternate) tipica dei protocolli IGP Link State (OSPF, IS-IS).
- Sul piano di controllo RSVP-TE utilizza dei sub-LSP P2P, mentre mLDP è di tipo P2MP o MP2MP.
- Il piano dati è sempre P2MP per RSVP-TE e P2MP o MP2MP per mLDP.
Oltre a quanto mostrato nella figura, vi è anche un ulteriore aspetto da tener presente. Quando un PE foglia non ha più ricevitori interessati al gruppo multicast il cui traffico utilizza un albero Selective, con RSVP-TE deve inviare in direzione upstream fino al PE radice, un messaggio RESVTEAR. Questo messaggio deve quindi attraversare tutta la rete fino al PE radice. Per contro, con mLDP è sufficiente un semplice messaggio LABEL WITHDRAW fino al LDP peer adiacente, per raggiungere lo stesso risultato.
Nelle applicazione alle MVPN ricordo inoltre che con l’utilizzo di mLDP, nella creazione di alberi (P-tunnel) di tipo Selective non è necessario utilizzare annunci MCAST-VPN Leaf A-D. Questo perché con mLDP la segnalazione è iniziata dai PE downstream.
CONCLUSIONI
In questo post ho illustrato l’estensione del protocolo LDP nota come mLDP (multipoint LDP), che consente la realizzazione di LSP MPLS sia di tipo P2MP che di tipo MP2MP. Nel post ho anche fatto un confronto tra i due tipi di segnalazione mLDP e RSVP-TE, mettendo in luce le differenze, vantaggi e svantaggi dell’una e dell’altra.
Io ho la personale opinione che la segnalazione mLDP sia più semplice e meno dispendiosa. E questo mi fa ritornare in mente una cosa vecchia: ma non era forse preferibile il CR-LDP a RSVP-TE ? (NOTA (per i più giovani): CR-LDP era una estensione di LDP per la segnalazione di percorsi MPLS Explicitly Routed, meglio noti come tunnel MPLS-TE. Purtroppo IETF (spinta da Cisco) preferì a suo tempo sviluppare per questo scopo RSVP-TE, congelando lo sviluppo di CR-LDP, che oggi non è più supportato da alcun costruttore).
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.
