<< Torna agli Approfondimenti Tematici
|
|
Premesse
Davvero sta per cadervi il mondo addosso per questa notizia? No potete stare tranquilli, ma a volte essere allarmisti è l’unico modo per catturare la vostra attenzione su problematiche complesse.
Oggi MPLS è perfettamente funzionante in molte reti service provider anche di grandissime dimensioni ma:
- MPLS TE non scala all’infinito
- Il problema è ben conosciuto come “Full-Mesh Problem” o “n al quadrato”: il numero degli LSP (Link State Path ha un andamento simile a quello del quadrato del numero dei PE)
Per parlare di tali problemi di scalabilità sintetizzerò e prenderò spunto dall’ottimo lavoro di |
MPLS è una tecnologia molto importante per le reti odierne Service Provider. Tra le caratteristiche che rendono MPLS una scelta adeguata individuiamo certamente il controllo granulare del traffico, la possibilità di ottimizzare le risorse a nostra disposizione garantendo inoltre la qualità del servizio per i flussi interessanti.
I carrier hanno in ultima analisi l’esigenza di fornire connettività edge-to-edge attraverso la loro rete core garantendo la possibilità di fornire servizi differenziati. Le tecniche di scalabilità e coesistenza di piani di indirizzamento in sovrapposizione sono certamente varie ed interessanti, come VPN di livello 3, tecnologie di livello 2 come VLAN, Pseudo Wires o VPLS. Tramite queste tecniche vi è la possibilità di distribuire traffico interessante come video broadcasto voce, e farlo coesistere senza degrado con il semplice traffico dati ip a volte anche difficile da trattare come quello FTP, o download file su http caratterizzato da un profilo “bandwidth greedy”.
Per renderci conto di quale possa essere il problema di scalabilità consideriamo il caso di una rete service provider con 1000 PE: non stiamo parlando di dimensioni impossibili, anzi direi che siamo in un range assolutamente reale. Ovviamente possiamo pensare di dividere questa rete in sotto autonomous systems o semplicemente in diverse aree. Se andiamo a calcolare una full mesh di PE-PE LSP, se consideriamo tunnel paralleli per differenti sevizi, differenti profili di qualità del servizio ed anche tunnel di protezione ad esempio con tecnologie fast reroute, considerando anche la unidirezionalità di suddetti tunnel, possiamo raggiungere facilmente multipli di 999.000, considerando che se avessimo semplicemente un coppia di tunnel per bidirezionalità tra tutti i PE, in osservanza della regola (n ∙ (n - 1))⁄ 2 ∙ 2 , otterremmo 999.000
In questo caso dovremmo chiederci quale sia la capacità del nostro Management Network System e dei Provider Router di core che saranno quelli ad essere maggiormente soggetti a problemi di dimensioni eccessive delle strutture dati di controllo del traffico come la MPLS switching table, o la Label Binding Table. Inoltre dovremmo anche porci il problema del carico di CPU nel momento del ricalcolo di qualche percorso o semplicemente dal refresh dello stato dei percorsi, tenendo conto che un limite tipico può essere quello di “solamente” 1.000.000 di etichette per interfaccia.
Topologia Snowflake (Fiocco di Neve)
In questa topologia consideriamo una rete che sia costituita da:
- P1: router P di core in full-mesh
- Pi+1: router di core collegati ad un solo Pi
- Nodi PE connessi ad un solo nodo Pn
La simmetria di questa topologia consente un calcolo esatto di molti parametri di metrica e scalabilità della rete senza vincolare le dimensioni della topologia, infatti possiamo variare secondo le nostre necessità:
- Il numero dei nodi di core P1
- Il numero dei Pi+1 router connessi ai rispettivi router Pi
- Il valore massimo dell’indice i quindi dei “livelli” di core della rete
- Il numero dei nodi PE collegati ad un nodo Pn
|
Passando all’analisi di questa topologia:
Definiamo:
- Pn un nodo a livello n° (il livello 1 è il vero e proprio core)
- Sn il numero di nodi al livello n°
- Mn il moltiplicatore a livello n° (quanti il numero di nodi Pn+1 connessi al livello Pn)
- Ln il numero di LSP visti da un nodo Pn
Considerando che ogni tunnel TE è monodirezionale quindi per un traffico bidirezionale dobbiamo prevedere un tunnel TE separato per verso:
Mentre può essere dimostrato che: | LPE = 2 ∙ (SPE − 1) |
e che: |
L2 = M2 ∙ (2 ∙ SPE − M2 − 1) |
Traducendo questo in numeri reali |
|
si ottiene che: | SPE = 2000, LPE = 3998, L2 = 79580, L1 = 756000 |
Topologia Ladder (scala)
|
Questa topologia comune a molte reti geografiche nazionali si compone di un core “a scala” al quale vengono connessi diversi altri P di livello superiore in una topologia a più livelli, caratterizzata da:
- Pi+1: router di core collegati ad un solo Pi
- nodi PE connessi ad un solo nodo Pn
Anche qui la simmetria di questa topologia consente un calcolo esatto di molti parametri di metrica e scalabilità della rete senza vincolare le dimensioni della topologia, infatti possiamo variare secondo le nostre necessità.
Definiamo come nel caso di topologia Snowflake:
- Pn un nodo a livello n° (il livello 1 è il vero e proprio core)
- Sn il numero di nodi al livello n°
- Mn il moltiplicatore a livello n° (quanti il numero di nodi Pn+1 connessi al livello Pn)
- Ln il numero di LSP visti da un nodo Pn
- Nel caso particolare in cui il livello massimo di core sia 2, definiamo E = M1 ∙ M2 che è il numero di PE sottesi ad un singolo P di core.
Anche qui considerando che ogni tunnel TE è monodirezionale quindi per un traffico bidirezionale dobbiamo prevedere un tunnel TE separato per verso:
Mentre può essere dimostrato che: | LPE = 2 ∙ (SPE − 1) |
e possiamo approssimare: |
L2 = 2 ∙ M2 ∙ (SPE − 1) − M2 ∙ (M2 − 1) |
Traducendo questo in numeri reali |
|
si ottiene che: | E = 200, SPE = 2000, LPE = 3998, L2 = 79580, L1 = 2516000 |
come si nota la scalabilità della topologia “a scala” è anche peggiore della topologia a “fiocco di neve”.
Risoluzione dei problemi di scalabilità
La prima regola da rispettare è che se una scelta architetturale non scala va evitata, quindi una full mesh di tunnel TE in uno scenario PE-PE nel caso di centinaia di router edge non è una scelta praticabile.
|
Una scelta possibile è quella di costruire una full mesh a livello Pnto Pn e lasciare ad un classico modello di mpls ldp il calcolo degli lsp PE to Pn. In questo modo la scalabilità passa da 0(1000)2 a 0(100)2. Ovviamente questa scelta ha un prezzo in termini di funzionalità, perdiamo una full-mesh PE-to-PE, dobbiamo fronteggiare il problema della potenziale sovrapposizione di indirizzi privati (se non siamo nel caso di VPN MPLS di livello3).
|
Una seconda possibilità è quella di utilizzare ben conosicute funzionalità MPLS come:
- Forwarding agencies (RFC 4206)
- Label multiple
Ad esempio connettere tutti i nodi P2 tramite tunnel TE in full mesh ed incapsulare i tunnel in full mesh PPE in quelli di livello P2 in questo modo i nodi P1 vedranno solamente i tunnel di livello P2 riducendo in maniera sostanziale il numero di LSP da mantenere.
Considerando il caso Snowflake, la scelta di operare una full mesh a livello P2 non è semplicemente di esempio, ma un buon equilibrio, infatti tunnel esclusivamente di livello PPE non scalano, mentre tunnel full mesh di livello P1 sono inutili dal momento che il core è tipicamente in full mesh.
Quindi considerando che i P2 vedono i tunnel dei PE direttamente collegati e tutti i tunnel di livello P2 si ottiene che L2 = M2 ∙ (2SPE − M2 − 1) + 2 ∙ (S2 − 1) La situazione sui nodi P1 è molto migliore, infatti essi vedono solamente i tunnel di livello P2 e quindi L1 = M1 ∙ (2 ∙ S2 − M1 − 1)
Nel caso in cui S1 = 10, M1 = 10, M2 = 20 facendo un confronto tra il caso di full mesh PE con il caso gerarchico appena discusso si ottiene:
| Caso Full Mesh | Caso Gerarchico | |
|---|---|---|
SPE |
2000 |
2000 |
LPE |
3998 |
3998 |
L2 |
79580 |
79778 |
L1 |
756000 |
1890 |
In questo caso aggiungere un livello 3 raggiunge comunque un numero di tunnel troppo alto.
Considerando il caso Ladder, tunnel esclusivamente di livello PPE non scalano, mentre tunnel full mesh di livello P1 possono essere una buona scelta dal momento che il core non è totalmente connesso, è quindi possibile arrivare fino a 3 livelli di gerarchia incapsulando tunnel di Pe in tunnel di livello 2 e successivamente in tunnel di livello 1.
Considerando un solo livello di gerarchia i tunnel di livello P1 possono essere calcolati | |
| L1 ≈ S12 ⁄ 2 + 2 ∙ S1 + 2 ∙ E2 (S1 − 1) − E ∙ M2 − 2 |
| L1 = S12 ⁄ 2 + 2 ∙ S1 + 2 ∙ M12 ∙ S1 - M1 ∙ (M1 + 1) - 2 |
L2 = 2 ∙ M2 ∙ (SPE − 1) − 2 ∙ M2 ∙ (M2 + 1) + 2 ∙ (S1 ∙ M1 − 1) |
Nel caso in cui S1 = 10, M1 = 10,M2 = 20 facendo un confronto tra il caso di full mesh PE con il caso gerarchico appena discusso si ottiene:
| Caso Full Mesh | Caso Gerarchico 2 livelli | Caso Gerarchico 3 livelli | |
|---|---|---|---|
SPE |
2000 |
2000 |
2000 |
LPE |
3998 |
3998 |
3998 |
L2 |
79580 |
79580 |
79778 |
L1 |
2516000 |
716060 |
1958 |
In ogni caso anche ricorrendo a tunnel gerarchici i problemi di scalabilità vengono risolti solo parzialmente; inoltre è necessario capire come reagisca a questa architettura il sistema di monitoraggio della rete. Un punto decisamente critico per la scalabilità l’introduzione di tecniche di fast reroute che introducono un maggior numero di lsp da gestire, inoltre una topologia non simmetrica rende molto complesso un colcolo anche solamente approssimato.
Una soluzione che interessante per superare anche i suddetti limiti può essere quella di utilizzare tecniche di lsp point-to-multipoint fuori dall’oggetto di questa trattazione.
Conclusioni
La scalabilità di MPLS Traffice Engineering non è al giorno d’oggi da considerarsi una criticità ad alta priorità, riuscendo di fatto ancora a sostenere le esigenze delle reti attuali. Tuttavia è bene tenere presente che questo non scala indefinitamente e che una pianificazione oggi per evitare problemi di crescita domani è quindi oltre che necessaria doverosa. Abbiamo visto come la soluzione full mesh non sia praticabile e la soluzione gerarchica sia meno efficace di quanto non ci si attenda. Migliori prestazioni sono raggiunte tramite RSVP TE multipoint-to-point. Certamente sono necessarie ulteriori soluzioni e sforzi di ricerca.