Nel post "BGP e MPLS nell'era SDN" ho introdotto le idee fondamentali del protocollo PCEP, un protocollo che consente la comunicazione tra router della rete e un controller centralizzato, per la definizione, realizzazione e gestione di percorsi MPLS (LSP), utilizzando le tecniche del Traffic Engineering MPLS (MPLS-TE) (NOTA: questi percorsi nel gergo MPLS, vengono chiamati LSP Explicitly Routed).
Ricordo che il protocollo PCEP è del tipo Client-Server e consente il dialogo tra due elementi:
- PCE (Path Computation Element): un programma di calcolo che risiede in un controller centralizzato, eseguito tipicamente su un server x86 (eventualmente virtualizzato), al quale è demandata la determinazione dei percorsi ottimi, eventualmente soggetti a vincoli amministrativi. Dalla prospettiva del protocollo PCEP, il PCE agisce come Server.
- PCC (Path Computation Client): il sistema di segnalazione che risiede in un router, che ha il compito di realizzare i percorsi decisi dal PCE (o, come vedremo, dal PCC stesso), utilizzando come protocollo di segnalazione RSVP-TE o altri protocolli equivalenti tipo ad esempio SPRING, meglio conosciuto come Segment Routing (che tratterò diffusamente in un prossimo post).
Ovviamente il PCE, che risiede nel controller, per ottimizzare i suoi calcoli, deve avere a disposizione la completa topologia della rete e le proprietà di ciascun link. Ma a questo pensa il BGP-LS, ampiamente trattato in questo post, o qualsiasi altra funzionalità, a seconda dei protocolli supportati dai router della rete sottostante. La figura seguente mostra uno schema a blocchi del PCE (NOTA: a essere precisi lo schema a blocchi riguarda la versione stateful del PCE. Esiste anche una versione stateless del PCE, ma consentitemi di glissare su questo punto poiché la versione stateless non gode di molto successo).
In ambito
IETF è stata dapprima definita una architettura centralizzata di
calcolo (vedi la RFC 4655 "A Path Computation Element (PCE)-Based Architecture"
dell'Agosto 2006) e quindi il protocollo di comunicazione PCEP (Path
Computation Element Protocol), introdotto con la RFC 5440 "Path Computation Element (PCE)
Communication Protocol (PCEP)" del Marzo 2009.
NOTA: la lettura del seguito di questo post richiede una conoscenza di base del Traffic Engineering MPLS (MPLS-TE). Per chi volesse apprendere le basi di questo argomento, o "ripassarne" gli elementi fondamentali, potete scaricare a questo link il Capitolo 7 del mio vecchio libro su MPLS (scritto nel 2003, edito dalla Hoepli, non più disponibile in formato cartaceo). Una sola avvertenza. In questo capitolo si parla anche del protocollo CR-LDP (Constraint-based Routing - LDP), una estensione del protocollo LDP per le applicazioni MPLS-TE. Questo protocollo è stato abbandonato da IETF nel lontano 2003 (contemporaneamente all'uscita del libro), a vantaggio di RSVP-TE (RFC 3468, The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols, Febbraio 2003). Per cui potete saltare tutti i paragrafi che parlano di CR-LDP.
NOTA: la lettura del seguito di questo post richiede una conoscenza di base del Traffic Engineering MPLS (MPLS-TE). Per chi volesse apprendere le basi di questo argomento, o "ripassarne" gli elementi fondamentali, potete scaricare a questo link il Capitolo 7 del mio vecchio libro su MPLS (scritto nel 2003, edito dalla Hoepli, non più disponibile in formato cartaceo). Una sola avvertenza. In questo capitolo si parla anche del protocollo CR-LDP (Constraint-based Routing - LDP), una estensione del protocollo LDP per le applicazioni MPLS-TE. Questo protocollo è stato abbandonato da IETF nel lontano 2003 (contemporaneamente all'uscita del libro), a vantaggio di RSVP-TE (RFC 3468, The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols, Febbraio 2003). Per cui potete saltare tutti i paragrafi che parlano di CR-LDP.
INTERAZIONE PCE/PCC
La RFC 5440 descrive un modello secondo il quale, il PCC prima richiede al PCE il calcolo di un percorso. Il PCE, nel caso in cui sia stato in grado di determinare il percorso secondo i vincoli richiesti, ritorna al PCC i risultati del calcolo del percorso, e infine, il PCC segnala il nuovo percorso via RSVP-TE.
Sebbene la RFC 5440 copra un possibile paradigma, gli scenari tipici reali sono un po' diversi, e sono di due tipi:
Sebbene la RFC 5440 copra un possibile paradigma, gli scenari tipici reali sono un po' diversi, e sono di due tipi:
- PCE-initiated LSP : il PCE, di sua iniziativa, determina un percorso e invia il risultato al PCC, che a sua volta provvede alla segnalazione. In questo caso il PCC non richiede alcunché al PCE, che prende l'iniziativa dell'intero processo, anche se l'effettiva segnalazione è poi svolta dal PCC.
- PCC-initiated LSP : il PCC ha un LSP MPLS-TE configurato localmente e invia al PCE le caratteristiche del LSP. Il PCE inserisce il nuovo LSP nel proprio LSP Database (vedi schema a blocchi del PCE sopra). Questo è un aspetto importante poiché il PCE, per svolgere il suo lavoro in maniera ottimale, deve avere una visione completa di tutti i LSP già attivi sulla rete.
- Vanilla LSP (NOTA: il nome curioso vanilla indica in questo caso "ordinario"): il LSP è configurato interamente sul PCC, che provvede sia alla segnalazione RSVP-TE (o altro protocollo) che alla comunicazione al PCEP dei parametri caratteristici del LSP (es. percorso (ossia, l'oggetto RSVP-TE ERO), banda riservata, priorità, stato, ecc.). La comunicazione avviene attraverso il nuovo messaggio PCEP Rpt (PCEP Report), definito nel draft citato sopra. Per questo tipo di LSP, il PCE non è autorizzato ad apportare alcuna modifica al percorso, ma si limita solo a prendere nota della sua esistenza e delle sue caratteristiche. Nonostante a prima vista per questo tipo di LSP il PCE non giochi alcun ruolo, risulta comunque molto utile come punto centralizzato dove verificare stato e percorso del LSP.
- Delegated LSP: costruzione identica al Vanilla LSP, ma con una differenza fondamentale: il PCC passa al PCE il controllo del LSP, subito o dopo un tempo differito. In altre parole, il PCE può cambiare in qualsiasi momento i parametri del LSP e comunicarli al PCC per la nuova segnalazione.
L'implementazione di questi nuovi paradigmi richiede l'introduzione di nuovi messaggi del protocollo PCEP, oltre a quelli già introdotti nella RFC 5440. Il documento IETF che tratta queste estensioni è ancora allo stato draft ed è il seguente: draft-ietf-pce-stateful-pce-14 (scadenza 21 Settembre 2016). Il draft è comunque già implementato nelle piattaforme più avanzate Juniper e Cisco basate su JunOS e IOS XR.
Illustrerò ora qualche dettaglio sui due nuovi paradigmi.
PCE-INITIATED LSP
Con il paradigma PCE-INITIATED LSP, il PCE determina un percorso e quindi, attraverso il nuovo messaggio PCEP INITIATE, comunica al PCC le caratteristiche del percorso. Il PCC riscontra al PCE l'avvenuta ricezione del messaggio PCEP INITIATE e inizia la procedura di segnalazione RSVP-TE per il setup del LSP. Il tutto è schematicamente riassunto nella figura seguente.
La figura seguente riporta in maggiore dettaglio, lo scambio di messaggi PCEP e la fase di segnalazione via RSVP-TE. Per semplicità sono evidenziati i soli PE di ingresso (che in questo caso gioca il ruolo di PCC) e il PE di uscita, oltre ovviamente al PCE. Si noti che il protocollo PCEP utilizza per lo scambio di messaggi una comunissima sessione TCP, utilizzando la porta well-known 4189 (maggiori dettagli nella RFC 5440). Sempre per semplicità, non ho evidenziato il three-way-handshake iniziale per il set-up della connessione TCP.
Il primo messaggio scambiato tra PCC e PCE è il messaggio PCEP OPEN, che serve a negoziare alcune caratteristiche della sessione, come ad esempio Keepalive timer, Dead Timer, policy, ecc. (come si può notare, il PCEP mutua alcune idee dal BGP !). Ulteriori dettagli nella RFC 5440.
Quando un amministratore/orchestratore definisce un nuovo LSP MPLS-TE, il PCE determina un nuovo ERO (Explicit Route Object). Questo è uno degli oggetti inclusi nel messaggio PCEP INITIATE che il PCE invia al PCC, attraverso il quale il PCE comunica al PCC il percorso del nuovo LSP. Oltre all'oggetto ERO, il messaggio PCEP INITIATE contiene altri oggetti, tra cui (NOTA: la lista è parziale, riporta solo i più importanti):
Alla ricezione del messaggio PCEP INITIATE, il PCC risponde con un messaggio PCEP REPORT, che contiene un oggetto LSP aggiornato rispetto a quello ricevuto nel messaggio PCEP INITIATE. In particolare, come detto sopra, il PCC comunica il valore di PLSP-ID scelto (nell'esempio della figura sopra PLSP-ID = 10) e inoltre comunica delle flag aggiuntive, tra cui la più importante è la flag Delegate (bit D). Quando D = 1, il PCC delega al PCE il controllo del LSP (Delegated LSP). Viceversa, D = 0 indica che il controllo del LSP rimane al PCC (Vanilla LSP). Oltre all'oggetto LSP, il messaggio PCEP REPORT contiene anche due oggetti ben noti, l'oggetto ERO ricevuto tramite il messaggio PCEP INITIATE, e l'oggetto RRO (Record Route Object), che contiene il percorso effettivo (NOTA: questi due ultimi oggetti possono coincidere, ma anche no. L'ERO infatti specifica un sottoinsieme o al più tutti i nodi del percorso, il RRO specifica invece tutti i nodi effettivamente attraversati dal percorso). Si noti che nel primo messaggio PCEP REPORT, il RRO è (ovviamente) vuoto. Diventa non vuoto solo dopo la segnalazione del LSP via RSVP-TE.
Il PCC invia periodicamente messaggi PCEP REPORT. Aggiornando l'oggetto LSP, il PCC può comunicare al PCE eventuali messaggi di errore RSVP-TE (es. RSVP-TE PATHERR, RESVTEAR, ecc.). Dal lato PCE, quando questo, su input di un amministratore/orchestratore, deve cambiare le caratteristiche del LSP, invia un messaggio PCEP UPDATE al PCC.
NOTA: tutti i messaggi PCEP citati, a parte il messaggio PCEP OPEN, sono definiti nel documento "draft-ietf-pce-stateful-pce" citato sopra.
PCC-INITIATED LSP
Con il paradigma PCC-INITIATED LSP, il PCC determina un percorso in modo classico e quindi, attraverso un messaggio PCEP REPORT, comunica al PCE le caratteristiche del percorso e, o ne mantiene il completo controllo (Vanilla LSP), o eventualmente delega il controllo del LSP al PCE (Delegated LSP).
Lo scambio dei messaggi PCEP è schematicamente riassunto nella figura seguente, dove ho ipotizzato un Delegated LSP. Nel caso di Vanilla LSP lo scambio dei messaggi è identico, solo che nel messaggio PCEP REPORT la flag Delegate è pari a zero.
La flag Sync è posta a 1 solo nel primo messaggio PCEP REPORT. Serve a indicare che PCE e PCC sono sincronizzati sulle caratteristiche del LSP. Dopo che il PCC termina la trasmissione di tutte le informazioni sul nuovo LSP creato, nei successivi messaggi la flag Sync viene posta a zero.
Illustrerò ora qualche dettaglio sui due nuovi paradigmi.
PCE-INITIATED LSP
Con il paradigma PCE-INITIATED LSP, il PCE determina un percorso e quindi, attraverso il nuovo messaggio PCEP INITIATE, comunica al PCC le caratteristiche del percorso. Il PCC riscontra al PCE l'avvenuta ricezione del messaggio PCEP INITIATE e inizia la procedura di segnalazione RSVP-TE per il setup del LSP. Il tutto è schematicamente riassunto nella figura seguente.
La figura seguente riporta in maggiore dettaglio, lo scambio di messaggi PCEP e la fase di segnalazione via RSVP-TE. Per semplicità sono evidenziati i soli PE di ingresso (che in questo caso gioca il ruolo di PCC) e il PE di uscita, oltre ovviamente al PCE. Si noti che il protocollo PCEP utilizza per lo scambio di messaggi una comunissima sessione TCP, utilizzando la porta well-known 4189 (maggiori dettagli nella RFC 5440). Sempre per semplicità, non ho evidenziato il three-way-handshake iniziale per il set-up della connessione TCP.
Quando un amministratore/orchestratore definisce un nuovo LSP MPLS-TE, il PCE determina un nuovo ERO (Explicit Route Object). Questo è uno degli oggetti inclusi nel messaggio PCEP INITIATE che il PCE invia al PCC, attraverso il quale il PCE comunica al PCC il percorso del nuovo LSP. Oltre all'oggetto ERO, il messaggio PCEP INITIATE contiene altri oggetti, tra cui (NOTA: la lista è parziale, riporta solo i più importanti):
- Oggetto LSP: contiene vari parametri, tra cui:
- Un valore identificativo del LSP (PLSP-ID), che nel messaggio PCEP INITIATE assume il valore zero. Il valore viene quindi scelto dal PCC e comunicato tramite il messaggio PCEP REPORT (nell'esempio della figura sopra PLSP-ID = 10), e questo valore rimane costante per tutta la durata della sessione PCEP. La coppia <Indirizzo IP del PCC ; PLSP-ID> identifica in modo univoco il LSP in tutte le comunicazioni PCEP.
- Varie flag, tra cui una indicante lo stato del LSP (Admin Up). Altre flag sono utilizzate nel messaggio PCEP REPORT.
- Alcune informazioni opzionali, strutturate nella forma di moduli TLV. Una di queste è visualizzata nella figura ed è un nome mnemonico assegnato al LSP (REISSLAB-12 nella figura).
- Oggetto Endpoint: contiene gli indirizzi IP dei PE di ingresso e di uscita (tipicamente indirizzi di interfacce di Loopback). Nella figura questi sono rispettivamente 1.1.0.1 (PE di ingresso) e 1.1.0.2 (PE di uscita).
- Oggetto SRP (Stateful PCE Request Parameters) : è un numero di sequenza che viene incrementato ogniqualvolta il PCE decide di cambiare le caratteristiche del LSP.
- Oggetto LSPA (LSP Attributes): definito nella RFC 5440, contiene i vettori (ciascuno di 32 bit) delle proprietà dei link, i valori di priorità setup e holding ed eventuali informazioni aggiuntive.
- Oggetti Metric e Bandwidth: autoesplicativi.
Alla ricezione del messaggio PCEP INITIATE, il PCC risponde con un messaggio PCEP REPORT, che contiene un oggetto LSP aggiornato rispetto a quello ricevuto nel messaggio PCEP INITIATE. In particolare, come detto sopra, il PCC comunica il valore di PLSP-ID scelto (nell'esempio della figura sopra PLSP-ID = 10) e inoltre comunica delle flag aggiuntive, tra cui la più importante è la flag Delegate (bit D). Quando D = 1, il PCC delega al PCE il controllo del LSP (Delegated LSP). Viceversa, D = 0 indica che il controllo del LSP rimane al PCC (Vanilla LSP). Oltre all'oggetto LSP, il messaggio PCEP REPORT contiene anche due oggetti ben noti, l'oggetto ERO ricevuto tramite il messaggio PCEP INITIATE, e l'oggetto RRO (Record Route Object), che contiene il percorso effettivo (NOTA: questi due ultimi oggetti possono coincidere, ma anche no. L'ERO infatti specifica un sottoinsieme o al più tutti i nodi del percorso, il RRO specifica invece tutti i nodi effettivamente attraversati dal percorso). Si noti che nel primo messaggio PCEP REPORT, il RRO è (ovviamente) vuoto. Diventa non vuoto solo dopo la segnalazione del LSP via RSVP-TE.
Il PCC invia periodicamente messaggi PCEP REPORT. Aggiornando l'oggetto LSP, il PCC può comunicare al PCE eventuali messaggi di errore RSVP-TE (es. RSVP-TE PATHERR, RESVTEAR, ecc.). Dal lato PCE, quando questo, su input di un amministratore/orchestratore, deve cambiare le caratteristiche del LSP, invia un messaggio PCEP UPDATE al PCC.
NOTA: tutti i messaggi PCEP citati, a parte il messaggio PCEP OPEN, sono definiti nel documento "draft-ietf-pce-stateful-pce" citato sopra.
PCC-INITIATED LSP
Con il paradigma PCC-INITIATED LSP, il PCC determina un percorso in modo classico e quindi, attraverso un messaggio PCEP REPORT, comunica al PCE le caratteristiche del percorso e, o ne mantiene il completo controllo (Vanilla LSP), o eventualmente delega il controllo del LSP al PCE (Delegated LSP).
Lo scambio dei messaggi PCEP è schematicamente riassunto nella figura seguente, dove ho ipotizzato un Delegated LSP. Nel caso di Vanilla LSP lo scambio dei messaggi è identico, solo che nel messaggio PCEP REPORT la flag Delegate è pari a zero.
La flag Sync è posta a 1 solo nel primo messaggio PCEP REPORT. Serve a indicare che PCE e PCC sono sincronizzati sulle caratteristiche del LSP. Dopo che il PCC termina la trasmissione di tutte le informazioni sul nuovo LSP creato, nei successivi messaggi la flag Sync viene posta a zero.
UN PO' DI SANO PRAGMATISMO ...
Tempo fa ho avuto l'occasione di partecipare al webinar "BGP-LS e PCEP Deep Dive", organizzato dal mio amico Ivan Pepelnjak, e tenuto da Julian Lucek, un grande esperto di reti e coautore (insieme a Ina Minei) dello stupendo libro MPLS-Enabled Applications (III ed.), Ed. J. Wiley, 2011. Webinar molto interessante, alla fine del quale però una domanda mi è venuta spontanea e l'ho posta a Ivan e Julian: ma il Traffic Engineering MPLS è ancora attuale ?
Evidentemente la domanda non era così peregrina, tanto che Ivan, uno dei migliori blogger in circolazione e genio delle reti, ci ha scritto un apposito post, la conclusione del quale è stata che:
Evidentemente la domanda non era così peregrina, tanto che Ivan, uno dei migliori blogger in circolazione e genio delle reti, ci ha scritto un apposito post, la conclusione del quale è stata che:
- In totale accordo con la mia opinione, in ambito Data Center è completamente inutile per almeno due ragioni: la prima è che la banda disponibile in ambito Data Center è sempre più a buon mercato e la seconda è che le classiche topologie Leaf-and-Spine (Reti di Clos), che ho ampiamente trattato in questo post, lasciano poco spazio all'immaginazione nella determinazione dei percorsi.
- In parziale disaccordo con la mia opinione, secondo la quale l'interesse per il Traffic Engineering MPLS va scemando anche in ambito grandi reti degli ISP ed Enterprise, alcuni commenti ne hanno ribadito l'utilità e lo stesso Ivan ha detto di essere a conoscenza di applicazioni interessanti. Il perché della mia opinione è presto detto, il driver principale per l'introduzione del Traffic Engineering MPLS nelle grandi reti degli ISP è stato il Fast ReRouting, o meglio, utilizzando la terminologia standard della RFC 4090 (sezione 3.2) Fast Reroute Extensions to RSVP-TE for LSP Tunnels, Maggio 2005, il Facility Backup (NOTA: per chi di voi fosse familiare con l'implementazione del Traffic Engineering MPLS nel JunOS, il termine Fast ReRoute è lì utilizzato per il One-to-One Backup (nomenclatura sempre della RFC 4090), una funzionalità diversa che non utilizza il concetto di riparazione locale, bensì quello di "percorso di aggiramento" (detour path)). Ora, oggi per la protezione locale del traffico è disponibile come alternativa LFA (Loop Free Alternate), e comunque con un opportuno tuning dei protocolli Link-State (tematica ampiamente trattata in questo blog) è possibile ottenere tempi di convergenza molto bassi, sufficienti per tutte le applicazioni importanti. Queste tecniche potrebbero quindi sostituire il Facility Backup senza richiedere l'utilizzo di protocolli aggiuntivi come RSVP-TE. E per la definizione di percorsi arbitrari è disponibile il Segment Routing (oggetto di un prossimo post). Per cui molti ISP stanno pianificando di sostituire i percorsi MPLS-TE con queste nuove tecniche.
CONCLUSIONI
Il Traffic Engineering MPLS (MPLS-TE) è stato in passato uno dei principali driver per l'introduzione di MPLS nelle reti IP. Uno degli aspetti più complessi legati a MPLS-TE è la determinazione dei percorsi. Come già visto nel post "BGP e MPLS nell'era SDN", la centralizzazione di questo aspetto consente di migliorare notevolmente la determinazione dei percorsi, consentendo di risolvere problemi come i percorsi Inter-Area/Multi-livello e il problema del bin packing. E così MPLS-TE sta avendo una seconda giovinezza, grazie anche all'introduzione del concetto di SDN e dell'idea di utilizzare controller centralizzati.
In realtà questa esigenza era ben nota agli esperti di MPLS ben prima della nascita del concetto di SDN, ma con l'introduzione di SDN si sono aperte nuove prospettive, subito recepite, che hanno portato alla definizione (non ancora completata, ma già disponibile negli apparati dei principali vendor) a nuovi paradigmi, più vicini all'idea stessa di SDN e più vicini ai modelli di applicazioni reali.
Coming up next ... Segment Routing (parte I) - Stay tuned !!!
Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo:
In realtà questa esigenza era ben nota agli esperti di MPLS ben prima della nascita del concetto di SDN, ma con l'introduzione di SDN si sono aperte nuove prospettive, subito recepite, che hanno portato alla definizione (non ancora completata, ma già disponibile negli apparati dei principali vendor) a nuovi paradigmi, più vicini all'idea stessa di SDN e più vicini ai modelli di applicazioni reali.
Coming up next ... Segment Routing (parte I) - Stay tuned !!!
Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo:
- IPN272: MPLS: dalla teoria alla Pratica
- IPN273: MPLS: aspetti avanzati
- IPN276: MPLS nell’IOS XR Cisco
- IPN258: MPLS nel JunOS Juniper
Nessun commento:
Posta un commento