<< Torna agli Approfondimenti Tematici

Premesse

Con riferimento al precedente articolo “Perché MPLS Traffic Engineering non scala” e prendendo spunto dal lavoro di Seisho Yaukawa (NTT), Adrian Farrel (Old Dog Consulting) e Olufemi Komolafe (Cisco Systems) “An Analysis of Scaling Issues in MPLS-TE Backbone Networks”

In questo articolo verrà proposta una soluzione ampiamente scalabile per MPLS TE che si basa sull’utilizzo di tecniche di instaurazione di LSP (Labled Switched Path) con alberi multipunto-punto, anche detti “molti ad uno”: MP2P LSP (Multipoint-to-point Labeled Switched Path).

A questo scopo utilizzeremo tecniche di instaurazione LSP per MPLS tramite l’utilizzo, per il control plane, di una estensione di RSVP (Resource Reservation Protocol).

Prima di analizzare questa tecnica di scalabilità di MPLS TE, verranno introdotte alcune basi riguardanti le tecnologie coinvolte in questa soluzione, con riferimento al lavoro di Seisho Yasukawa “Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering”, al momento in stato di draft.

Funzionamento di base di MP2P LSP MPLS- TE

Con riferimento alla RFC 2205 “Resource ReSerVation Protocol (RSVP)”, RSVP prevede un’estensione per gestire flussi di traffico da diverse sorgenti verso una destinazione comune, tuttavia MPLS Traffic Engineering include solamente il supporto per tunnel punto-punto RFC 3209 “RSVP-TE: Extensions to RSVP for LSP Tunnels”. La tecnologia di seguito si propone di superare questo limite.

MP2P MPLS-TE LSP ha lo scopo di trasportare traffico da LSR (Labeled Switched Router) multipli ad un unico LSR di uscita con conseguente riduzione della tabella delle label mpls.

L’idea principale è quella di instaurare diversi P2P LSP ma consentire ad un “merge LSR” di mappare diverse label di ingresso su un’unica label di uscita.

In effetti un albero MP2P LSP può essere considerato come una serie di tunnel edge-to-edge in maniera simile a quanto descritto nella RFC 4206 riguardante LSP P2P gerarchici: ad esempio una segnalazione diretta del tipo MPLS-TE o Directed LDP funziona in maniera classica con lo scambio di label dedicate alla comunicazione P2P, questa label verrà aggiunta allo stack oltre a quella espressamente prevista per le normali funzioni di transport.

Dal punto di vista dell’head-end del tunnel, questo appare a tutti gli effetti come un tunnel punto-punto a livello di data plane, tuttavia se più tunnel attraversano un LSR comune, questo effettua un “merge” dei diversi percorsi operando le dovute modifiche al control plane. Così per n LSP indirizzati verso lo stesso tail-end, si ottiene a fronte di diversi tunnel entranti in un LSR di merge un solo LSP di uscita.

Da un punto di vista della banda allocabile esistono due possibili approcci che il LSR di merge può seguire:

• Semplicemente aggiungere la banda del nuovo LSP entrante a quella richiesta dal tunnel uscente MP2P LSP. Questo risulta adatto per traffici scorrelati all’interno dello stesso percorso MP2P
• La banda richiesta dal nuovo LSP entrante non viene aggiunta, ma semplicemente inglobata nel percorso MP2P uscente. Questo approccio può essere adatto a particolari applicazioni per le quali vi è una trasmissione di dati di una sorgente per volta.

Per quanto concerne la segnalazione verso il tail-end del tunnel, si possono seguire due approcci:

• Segnalare al tail-end ogni nuovo LSP che venga inglobato nel MP2P LSP, questo può avere senso se ad esempio si fa uso di forwarding adjencies per la propagazione di informazioni di routing in protocolli dinamici RFC4206
• Non effettuare alcuna segnalazione aggiuntiva, tenendo di fatto nascosto agli LSR tail-end ed head-end del tunnel che si tratti effettivamente di un MP2P LSP

Può essere interessante anche capire come possa essere gestito il FRR (Fast ReRoute) per una MP2P LSP, infatti in alcuni casi potrà essere gestito semplicemente come nel caso di un P2P LSP, ma quando il fault dovesse coinvolgere un link vicino al merge LSR o il merge LSR stesso, alcune considerazioni aggiuntive sono necessarie

Supponiamo di avere un LSP MP2P formato dai percorsi ABCGHIJ e DEFGHIJ com merge LSR G ed analizziamo alcuni casi di fault:

Fault del link BC: il tunnel di protezione potrebbe essere BZG, che si chiude sul merge LSR lasciando di fatto invariato il MP2P LSP
Fault del link BC ed EF: il doppio fault con backup tunnel BZG ed EZG sposta idealmente il merge point a Z dal precedente G. Tuttavia il beneficio che si otterrebbe rinegoziando la posizione del merge LSR è trascurabile rispetto al sovraccarico di segnalazione che ne scaturirebbe.
Fault del link CG: il tunnel di protezione potrebbe essere CPH, questo vuol dire che il merge point si sposta da G ad H
Fault di LSR G: i tunnel di protezione CPH e FQH rendono H il nuovo merge LSR
Fault del link GH: in maniera simile al fault di LSR G questo porterebbe ad uno spostamento del merge point ad H utilizzando i tunnel di backup CPH e FQH
Fault del link HI: il questo caso il MP2P LSP può essere protetto come un normale P2P LSP con tunnel di backup HSI

Come estensione del protocollo RSVP è sufficiente utilizzare il flag “MP2P Merge Allowed” per consentire l’instaurazione del MP2P LSP. Questo fornisce il vantaggio che un LSR che non dovesse supportare tale estensione non eseguirà alcuna azione lasciando possibilmente al downstream LSR il ruolo di merge LSR.

Vale la pena sottolineare che l’introduzione di questa estensione non inficia e modifica in alcun modo il funzionamento della segnalazione ed instaurazione di P2P e P2MP LSP che possono continuare a coesistere sulla topologia MPLS.

Tecniche di scalabilità di MPLS-TE tramite l’uso di MP2P LSP

Analizziamo come le problematiche di scalabilità espresse nell’articolo “Perché MPLS TE non scala!” possano essere affrontate con l’uso di MP2P LSP.

Per confronto si tenga conto che nel caso di rete flat o gerarchica:

• Ogni LSP aggiunge uno stato da mantenere sull’head-end e sul tail-end
• Ogni LSP aggiunge due stati da mantenere sugli LSR si transito

Premettendo che in questo scenario ha senso contare lo stato degli LSP e non il numero assoluto di LSP P2P esistenti definiamo:

P₁: router P di core full mesh
P_i+1: router di core collegati ad un solo P_i
S_n: il numero di P a livello n°
S_PE: il numero di PE
M_n: il moltiplicatore di livello n° (il numero di nodi P_(n+1) connessi ai router P_n
X_n: il numero di LSP mantenuti da ogni nodo P_n
X_PE: il numero di LSP mantenuti da ogni nodo PE
E∶ numero di PE sottesi ad un singolo P di core
E = M₁ ∙ M₂: nel caso in cui la profondità massima sia 2

Tecniche di scalabilità di MPLS-TE tramite l’uso di MP2P LSP

X_PE = 2 ∙ (S_PE - 1)
X₂ = S_PE ∙ (M₂ + 1)
X₁ = M₁ ∙ M₂ ∙ (S₁ - 2) + S_PE ∙ (M₁ + 1)

Esaminando il caso in cui: S₁ = 10, M₁ = 10, M₂ = 20

Caso MP2P LSP Topologia Ladder (Scala):

X_PE = 2 ∙ (S_PE - 1)
X₂ = S₁ ∙ E ∙ (M₂ + 1)
X₁ ≤ (4 + M₁ ) ∙ S₁ ∙ E - M₁ ∙ E

Esaminando il caso in cui: S₁ = 10, M₁ = 10, M₂ = 20

Caso MP2P LSP Topologia Ladder (Scala):

I benefici di una soluzione che preveda MP2P LSP è evidente dai risultati riportati. E’ però da tenere presente che mentre RSVP supporta topologie MP2P non vale lo stesso per RSVP-TE per il quale la proposta permane oggi in stato di draft.

Da considerare anche il fatto che potrebbe rendersi necessaria l’aggiunta di una label di sorgente che possa consentire di discernere al tail-end la sorgente del traffico, questo potrebbe rendersi necessario per alcune applicazioni. Operation Administration and Maintenance di questa soluzione presenta certamente un livello di complessità maggiore. Il supporto per il Fast Reroute nelle casistiche di cambio del merge point deve ancora essere affrontato in maniera strutturata e completa.