BGP e MPLS nell'era SDN

In questo nostro mondo di tanto in tanto, come è giusto che sia, nascono nuove idee e nuovi paradigmi, alcune delle quali hanno successo, altre finiscono miseramente nel dimenticatoio. Si potrebbe scrivere un libro su tutti i "fallimenti" che negli anni si sono avuti nel mondo delle Telecomunicazioni. 

Gli esempi più clamorosi si sono avuti con l'esplosione delle reti IP e dell'Ethernet (che ovviamente non sono stati fallimenti), che hanno spazzato via standard in quel momento molto più "di moda" (X.25, SNA, Appletalk, IPX, Frame Relay, ATM, tanto per citarne alcuni). 

L'esplosione delle reti IP si è avuta a partire dalla metà degli anni 90, mentre lo standard era stato definito molto prima, alla fine degli anni 70, quasi 20 anni prima (NOTA STORICA: inizialmente il protocollo IP era parte del protocollo TCP (ideato da Vinton Cerf e Robert Kahn); con l'avvento alla fine degli 70 del modello a strati ISO/OSI, la componente di rete, ossia di Livello 3, fu enucleata dal protocollo TCP e fu coniato l'acronimo IP, per indicare il protocollo che svolgeva le funzioni di Livello 3; tutto ad opera di Jonathan (Jon) Postel e della sua RFC 791, pubblicata nel Settembre 1981 !).

E come tutti sanno, oggi le moderne reti sono basate sul protocollo IP, definito 35 anni fa ! Una grande lezione della storia, che dietro ha un concetto molto semplice: paradossalmente, non sono i tecnologi a guidare le scelte tecnologiche, ma è quell'entità astratta che si chiama "mercato". Pensate a come sarebbe diverso oggi questo mondo, se Tim Berners Lee non avesse inventato il servizio World Wide Web ! 

Per chiudere questo "amarcord" voglio raccontarvi un aneddoto. Alla fine degli anni 80, quando giovincello entrai in questo affascinante mondo delle telecomunicazioni, un amico mi disse, leggiti questo libro, è scritto molto bene. Il libro in questione era intitolato "Telecommunication Networks: Protocols, Modeling and Analysis", scritto da un guru del tempo, Mischa Schwartz e pubblicato nel 1987. Un libro bellissimo, scritto veramente bene, molto voluminoso (più di 700 pagine). A me piaceva molto poiché c'erano "molte formule", e questo soddisfaceva la mia indole un po' matematica. In questo libro c'era un capitolo dedicato ai protocolli di trasporto, in cui venivano trattati con dovizia di particolari i protocolli TP0, TP1, ..., TP4. Per i più giovani, questi erano i protocolli di trasporto (Livello 4) del mondo ISO/OSI. In particolare il TP4 era l'equivalente del TCP, ossia il protocollo di trasporto ISO/OSI da utilizzare per i servizi connection-less (CLNS). Bene, questo capitolo terminava più o meno così "non tratteremo in questo capitolo il protocollo TCP perché destinato a scomparire in breve tempo" ... E tutti sappiamo come è andata a finire ! (probabilmente molti di voi, se non ve lo avessi detto io, nemmeno sapevano dell'esistenza di protocolli che si chiamavano TP0, ..., TP4).

Bene, fatta questa premessa (un po' troppo lunga per la verità, ma sapete, io sono un po' prolisso), veniamo alla "moda" del momento. Tutto gira intorno a un acronimo magico: SDN, che sta per Software Defined Networking, introdotto per la prima volta da un gruppo di studiosi dell'Università di Stanford in California, capeggiati da Nick McKeown.

L'idea devo dire che è dirompente per almeno due motivi ben precisi (secondo me):

• Sposta il valore dall'hardware al software. Gli switch o router diventeranno una macchina "stupida" il cui compito sarà il solo forwarding del traffico e poco più. Macchine quindi semplici e poco costose, e soprattutto pilotate da software vendor-independent. 
• E' un grande attacco ai vendor tradizionali di apparati di networking, come Cisco, Juniper, ecc.

Ma come tutte le nuove idee, passata la fase dell'entusiasmo,è arrivata l'inevitabile fase del realismo. E così, qualcuno ha iniziato ad accorgersi che i gioielli della corona dell'IETF, BGP e MPLS, possono giocare un ruolo chiave anche in questo nuovo paradigma. E qui ci sta bene citare la sezione 2.11 della RFC 1925 "The Twelve Networking Truths", pubblicata il Primo Aprile del 1996 (notare bene la data) e scritta da Ross Callon:

RFC 1925, sez. 2.11 "Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works."

Prima di vedere però quale ruolo avranno BGP e MPLS in questo nuovo paradigma delle reti, devo però introdurvi brevemente a SDN e al protocollo correlato OpenFlow. Se già conoscete, anche a livello introduttivo, questi aspetti, potete saltare tranquillamente le prossime due sezioni.

IL PARADIGMA SDN (CENNI)

Vi sono molte definizioni di SDN. Quella ufficiale dell'ONF (Open Networking Foundation, https://www.opennetworking.org/) è questa (ed è praticamente inutile):

The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices.

Dico praticamente inutile perché la separazione fisica tra piano di controllo e piano dati è già implementata da tempo in tutte le nuove piattaforme di networking, che come noto hanno un piano di controllo (il software) costituito da un sistema operativo più o meno proprietario e le sue applicazioni (protocolli di routing, di segnalazione, ecc.) e da un piano dati costituito da ASIC dedicati, progettati generalmente dai costruttori oppure da costruttori indipendenti (es. Broadcom).

La novità di SDN è però nascosta nell'ultima parte della definizione, quando si dice che il piano di controllo "controlla" più dispositivi. In altre parole, il paradigma SDN è basato su un software centralizzato che controlla più (tutti) dispositivi di una rete. E questo contrasta con il paradigma attuale delle reti, dove ciascun dispositivo ha un suo piano di controllo, e quindi il controllo è distribuito. In ultima analisi, la differenza tra il paradigma SDN e quello su cui si basano le attuali reti IP/Ethernet è la differenza che c'è tra un controllo centralizzato e un controllo distribuito.

Nello scenario SDN vi è un software centralizzato, indicato come controller SDN, che "decide tutto", dalla topologia logica della rete ai percorsi del traffico, e quindi comunica le decisioni in qualche modo standard, ai dispositivi fisici. Questo software centralizzato dialoga "lato nord" con le applicazioni attraverso delle API (Northbound API), e "lato sud" con le macchine fisiche attraverso altre API (Southbound API). La rete diventa così "programmabile" e tutta l'intelligenza risiede nel software centralizzato. Il modo con cui le decisioni del software centralizzato vengono comunicate ai dispositivi fisici è (o meglio, dovrebbe essere secondo l'ONF) il protocollo standard OpenFlow (vedi prossima sezione per dei cenni sul suo funzionamento). E questo è un aspetto caratterizzante del paradigma SDN rispetto alla situazione attuale. Quando un controller SDN utilizza "lato sud" il protocollo OpenFlow, viene chiamato controller OpenFlow.

Nei dispositivi attuali infatti, il protocollo che consente al piano di controllo (distribuito) di comunicare le sue decisioni al piano dati (forwarding) è proprietario. Nel paradigma SDN i dispositivi fisici diventano quindi macchine quasi stupide, l'unica mini-intelligenza che devono avere è sapere installare nell'hardware le regole di instradamento ricevute da un protocollo standard (es. OpenFlow). E sono quindi vendor-independent, ossia non dipendono dal software proprietario di un particolare costruttore. Per questo vengono talvolta chiamati "whitebox switch".

L'architettura complessiva, riportata nella figura sopra, è sicuramente suggestiva. Una volta realizzata porterebbe innegabili vantaggi quali ad esempio:

• Programmabilità della rete: il controllo della rete è direttamente programmabile da un software centralizzato perché completamente disaccoppiato dal piano dati.  
• Agilità: astrarre il controllo dal piano dati consente agli amministratori della rete di aggiustare dinamicamente i flussi di traffico secondo convenienza, tenendo conto della banda disponibile, della banda e della qualità richiesta dai singoli servizi, e così via.
• Gestione centralizzata: l'intelligenza della rete è (logicamente) centralizzata nei controller SDN (software-based), che hanno una visione globale della rete, che quindi appare alle applicazioni come fosse un unico grande switch logico (sentito mai parlare dell'architettura QFabric di Juniper ? Segue esattamente questa filosofia).
• Personalizzazione delle configurazioni: essendo non più il software di proprietà dei singoli vendor, gli amministratori della rete possono personalizzarlo secondo le loro specifiche esigenze, aggiungendo del codice a piacere, possibile poiché i programmi sono aperti. 
• Standard aperti e soprattutto vendor-neutral: quando implementato attraverso controller di tipo aperto (open), il paradigma SDN consente di semplificare il progetto della rete e di renderne più semplice l'esercizio, poiché il codice non è proprietario ed è unico. Nelle reti odierne invece il codice è proprietario dei singoli vendor e quindi la configurazione e l'esercizio della rete diventano più complessi, poiché è necessaria una esperienza operativa su più tecnologie.

Questo è il libro dei sogni. Ora è tempo di tornare con i piedi in terra ed introdurre una buona dose di sano realismo e pragmatismo. La domanda da porsi è semplice (un po' meno la risposta): con quali funzionalità è possibile realizzare un simile paradigma ? 

E' ovvio che le funzionalità devono avere "in primis", una caratteristica: essere standard. E poi devono essere scalabili anche a reti di grandi dimensioni, essere sufficientemente flessibili e possibilmente già note al grande pubblico dei networker. Ed è qui che entrano in gioco i "gioielli della corona" di IETF. Ma prima di vedere il ruolo di BGP e MPLS nel paradigma SDN, voglio darvi un piccolo cenno su OpenFlow, che dell'architettura SDN è parte integrante (almeno secondo l'ONF). Anche se, in teoria si potrebbe sviluppare il paradigma SDN senza far ricorso a OpenFlow, tanto che esistono oggi delle implementazioni reali SDN-like che non utilizzano OpenFlow (vedi ad esempio l'architettura aperta Juniper OpenContrail).

IL PROTOCOLLO OPENFLOW (CENNI)
OpenFlow è un protocollo aperto che nelle intenzioni degli sviluppatori, consente di programmare il forwarding engine di un qualsiasi dispositivo di switching (da qui in poi chiamato switch OpenFlow).

La sua versione iniziale (1.0, pubblicata nel Dicembre 2009) è fondamentalmente un'astrazione di uno switch. Nel corso del tempo, le diverse versioni di OpenFlow hanno incorporato più funzionalità, i cui dettagli sono al di là del scopo di questo post. Nel seguito, su OpenFlow sarà pubblicato un post specifico a cura del mio giovane e brillante collega Lorenzo Salvatore. Attualmente, l'ultima versione è la 1.5, pubblicata poco più di un anno fa. La tabella seguente riassume le tappe più importanti nello sviluppo di OpenFlow. Per ulteriori dettagli sullo standard e sul suo stato di avanzamento, è sufficiente consultare il sito ONF a questo link. 

La struttura logica di un switch OpenFlow è riportata dalla figura seguente, direttamente tratta dal documento ufficiale ONF "OpenFlow Switch Specification, Version 1.5.0 ( Protocol version 0x06 )", pubblicato il 19 Dicembre 2014.

Un switch OpenFlow è costituito da una o più flow tables e da una group table, che eseguono il lookup e il forwarding dei pacchetti, e da uno o più canali OpenFlow (OpenFlow Channel) che consentono la comunicazione con un controller esterno. Il switch comunica con il controller, e il controller gestisce lo switch attraverso il protocollo OpenFlow. La comunicazione tra switch e controller avviene attraverso una semplice connessione TCP, per la quale è  stata riservata dallo IANA la porta well-known 6653. Utilizzando il protocollo, il controller può aggiungere, aggiornare ed eliminare i flow entries delle flow tables, in modo sia reattivo (ossia, in risposta all'arrivo di un pacchetto) che proattivo. 

Ogni flow table contiene un insieme di flow entries, che consistono di tre entità:

• Campi attraverso i quali vengono riconosciuti i flussi (flow) di pacchetti (es. indirizzi MAC, IP, etichette MPLS, VLAN tag, ecc.).
• Contatori per raccogliere statistiche sul traffico (es. numero di lookup, di match, di pacchetti ricevuti, inviati, di pacchetti persi, ecc.).
• Un insieme di azioni da applicare ai pacchetti appartenenti a un determinato flusso (es. inoltra il pacchetto su una determinata porta, incapsula e inoltra il pacchetto, scarta il pacchetto, ecc.).

Il numero di campi attraverso i quali vengono definiti i flussi varia in funzione della versione di OpenFlow. Ad esempio, nella versione iniziale 1.0 erano 12, per poi salire a 15 nella versione 1.1 e quindi arrivare a 40 nella versione 1.3. 

Tutti i dettagli di funzionamento saranno visti nel prossimo post dedicato interamente a OpenFlow. Qui voglio solo limitarmi ad illustrare con un breve esempio come viene costruito un flow entry di una flow table. Prendiamo l'esempio illustrato nella figura seguente, dove un Host H1 attestato al switch OpenFlow S1, vuole inviare traffico TCP/IP a un Host H2 attestato al switch OpenFlow S2. Gli indirizzi IP sorgente/destinazione e le porte TCP sorgente/destinazione sono rispettivamente: <IP-S, IP-D ; TCP-S, TCP-D> = <10.1.1.1, 10.1.1.2 ; 1234, 80>.

Quando il primo pacchetto inviato da H1 ad H2 arriva al primo switch OpenFlow (S1), questo non avendo ancora un flow entry che gli consente il forwarding sulla porta di uscita, utilizza il suo control agent (ossia, la sua componente software che dialoga con il controller) e invia (punts, nella terminologia tecnica inglese) il pacchetto al controller. 

Nell'ipotesi che il controller abbia in qualche modo appreso in precedenza la "localizzazione" dell'Host H2, questo è in grado di programmare il nuovo flow entry e comunicarlo al switch S1. Il nuovo flow entry è caratterizzato dalla quadrupla <IP-S, IP-D ; TCP-S, TCP-D> = <10.1.1.1, 10.1.1.2 ; 1234, 80> e ha come azione "inoltra sulla porta 2". Il nuovo flow entry così costruito, viene quindi inviato attraverso i messaggi del protocollo OpenFlow a S1, che provvederà a installarlo sulla sua flow table. A questo punto, tutti i pacchetti successivi avranno a disposizione per il switching il nuovo flow entry e quindi non saranno più inviati al controller (non vi somiglia al vecchio fast switching di Cisco, sostituito successivamente dal CEF ?). Il tutto è riassunto nella figura seguente.

In realtà questo è solo un banalissimo esempio, sufficiente solo per illustrare l'idea di fondo di OpenFlow. Per una descrizione più dettagliata dovete aspettare il prossimo post dedicato interamente a questo nuovo protocollo, dove saranno discussi anche gli aspetti di scalabilità, che se non correttamente gestiti, possono diventare il tallone d'Achille di OpenFlow. Comunque, per chiudere questa sezione voglio solo aggiungere che vi sono già vari prodotti commerciali che supportano OpenFlow nelle varie versioni (NEC, HP, Brocade, ecc.).

IL RUOLO DEL BGP NELL'ERA SDN
Un errore che molti fanno quando si avvicinano per la prima volta a queste tematiche, è pensare che sia vera l'equazione SDN = OpenFlow. Non è così, è possibile realizzare una architettura SDN aperta (ossia, basata su protocolli standard) senza far ricorso a OpenFlow.

Pensate per un attimo di sostituire gli switch "alla moda" dell'esempio sopra (gli switch OpenFlow S1 e S2), con banali switch legacy (tradizionali) di tipo multilayer (termine che piace molto ai "markettari" dei vari vendor, ma che in fondo indica dispositivi configurabili sia come switch L2 tradizionali che come router), e supponiamo che questi switch supportino il BGP. Di switch di questo tipo oggi sul mercato se ne trovano a tonnellate, tra i più moderni, solo per citarne alcuni, gli switch Cisco della serie ASR/Nexus, gli switch Juniper della serie EX/MX/QFX, i Brocade, ec. ecc. .

Supponiamo inoltre che il controller abbia una implementazione (open) del BGP (anche di queste ne esistono molte in giro, es. Quagga, ExaBGP, Bird), e che abbia stabilito una sessione BGP (internal) con S1 e S2. Supponiamo inoltre che "magicamente" qualcuno abbia detto al controller che il percorso da seguire per il traffico H1 --> H2 è S1 --> S2. Per installare il flow entry su S1 è sufficiente che il controller invii a S1 un classico annuncio BGP con NLRI il prefisso IP a cui appartiene l'indirizzo IP di H1, e BGP Next-Hop l'indirizzo IP della porta 2 di S2. E il gioco è fatto. Provare per credere, io ho fatto una banale prova utilizzando come S1 e S2 due router Cisco e come controller un terzo router Cisco, funziona tutto perfettamente. Bisogna solo "magheggiare" un po' con i comandi del BGP (solo roba base comunque).

Però, c'è un però. Con questo trucchetto potete solo installare negli switch flow entry di tipo IP e basati sul solo prefisso destinazione (classico routing IP basato sul paradigma Destination-based Forwarding). Flow entry più sofisticati basati su altri campi L2/L3/L4 non sono possibili (o perlomeno, sono possibili con implementazioni più sofisticate del BGP). OpenFlow da questo punto di vista è infinitamente più flessibile, anche se vi è da chiedersi se questa maggiore flessibilità non vada poi a discapito della scalabilità. Ma su questo torneremo nel seguito.

Il ruolo del BGP nello scenario SDN non i limita comunque al banale esempio che ho descritto. Innanzitutto questo esempio può essere reso molto più sofisticato, e utilizzando le varie metriche del BGP è possibile effettuare anche un po' di Traffic Engineering tramite un meccanismo di Third-party Next-Hop. Vi faccio un esempio, per rendere l'idea. Come al solito sono costretto per brevità a glissare su alcuni dettagli. Consideriamo 4 switch in configurazione Leaf-and-Spine come nella figura seguente e supponiamo che il traffico sul collegamento L1-->S1 sia molto alto mentre gli altri collegamenti siano abbastanza scarichi. L'idea è quella di bilanciare il traffico tra il collegamento congestionato L1-->S1 e il percorso alternativo L1-->S2-->L2-->S1, in modo da scaricare un po' il collegamento sovraccaricato. 

La rete è di tipo IGP-free, ossia utilizza solo ed esclusivamente sessioni eBGP tra switch, come ampiamente descritto in questo post. Il controller ha sessioni iBGP con ciascun switch (attenzione che questo è un po' atipico, ma con un po' di aggiustamenti al codice del BGP, si può fare). Ora, per dividere il traffico sui due percorsi L1-->S1 e L1-->S2-->L2-->S1, si può fare quanto segue. In generale, per tutti gli annunci iBGP inviati dal controller agli switch:

• Fare in modo che abbiano un Local Preference sufficientemente alto da preferire gli annunci iBGP a quelli eBGP.
• Aggiungere la well-known community "no-export" per evitare che gli annunci vengano propagati alle sessioni eBGP.

Per ottenere la politica di traffico desiderata, inoltre:

• Inviare dal controller, due annunci iBGP al switch L1, con BGP Next-Hop rispettivamente S1 e S2, in modo tale che sia possibile su L1 l'applicazione del BGP multipath.
• Inviare a S2 un annuncio iBGP con BGP Next-Hop L2, per evitare che S2 utilizzi come Next-Hop L1, creando così un forwarding loop.

Per generalizzare tutto questo a una rete di grandi dimensioni, è necessario che il controller abbia una chiara visione della topologia della rete. Anche qui, il BGP gioca un suo ruolo. Infatti, è in via di standardizzazione una estensione del BGP, nota come BGP-LS (BGP-Link State), che consente al BGP di annunciare al controller, tramite opportuni messaggi UPDATE, la topologia della rete sottostante (vedi draft-ietf-idr-ls-distribution-13). Il BGP-LS è applicabile solo nel caso in cui la rete sottostante utilizzi un protocollo Link-State (OSPF o IS-IS) e non nel caso di reti IGP-free. Un esempio abbastanza noto di controller che implementa BGP-LS è Open DayLight. 

Per le reti IGP-free che utilizzano come unico protocollo di routing il BGP, quel gran genio di Petr Lapukhov, nel draft IETF "draft-lapukhov-bgp-sdn-00" ha proposto una soluzione ingegnosa basata esclusivamente sul BGP, tanto che nel draft chiama il controller "BGP controller". La sua soluzione è stata applicata con successo ai giganteschi Data Center in produzione di due ben note società, Microsoft e Facebook e questa è la migliore prova della bontà delle sue teorie. Ciò che è più stupefacente è che tutto è basato su funzionalità classiche del BGP, senza l'aggiunta di alcuna estensione.  

Infine, una funzionalità BGP interessante, che trova applicazione nei controller per mitigare l'effetto di attacchi DDOS (Distributed Denial Of Service), è la BGP Flowspec, funzionalità ben nota da tempo e standardizzata nella RFC 5575 "Dissemination of Flow Specification Rules" dell'Agosto 2009. La funzionalità BGP Flowsec è implementata in tutte le principali piattaforme dei maggiori vendor (Cisco, Juniper, Nokia-ALU) ed ha come caratteristiche principali:

• Utilizza i messaggi BGP UPDATE per distribuire TCAM entry (PBR, rate limiting, ACL).
• Consente una notevole varietà di condizioni match: IP sorgente/destinazione, porte TCP/UDP, tipi pacchetti ICMP, flag TCP, lunghezza dei pacchetti, DSCP, ecc.
• Consente vari tipi di azioni: rate limiting, scarto di pacchetti, sampling e logging, next-hop redirect, DSCP remark, ecc.

Come si può notare, una sorta di OpenFlow in piccolo.

La funzionalità BGP Flowspec può essere utilizzata, come ho detto sopra, per mitigare gli effetti degli attacchi DDOS, e per questo si è dimostrata ampiamente più flessibile della classica RTBH (Remote Triggered Black Hole), una funzionalità anche questa ben nota da tempo, descritta nella RFC 5635 "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", dell'Agosto 2009, dove è anche possibile trovare degli esempi di configurazione nei router Cisco e Juniper.

E qui mi fermo con il ruolo del BGP nell'era SDN. C'è molta roba per futuri post, ogni argomento sarà approfondito, questo post era solo una rassegna dell'esistente. 

IL RUOLO DI MPLS NELL'ERA SDN
MPLS è come noto uno standard ben consolidato e adottato universalmente dalla quasi totalità degli ISP mondiali e da molte reti Enterprise. La sua introduzione nelle reti IP ha consentito l'introduzione di nuovi servizi, alcuni dei quali hanno avuto grande successo commerciale come le L3VPN, altri in ogni caso di primaria importanza come 6PE/6VPE, pseudowire, L2VPN (VPLS, EVPN), NG-MVPN. 

Poi ha introdotto nelle reti IP, nate connection-less, il concetto di connessione virtuale, grazie all'introduzione del Traffic Engineering (da qui in poi abbreviato in TE) e del suo protocollo di segnalazione RSVP-TE. E questo aspetto, grazie anche e soprattutto al suo servizio correlato di Fast ReRouting, ha trovato interessanti applicazioni nelle reti in produzione.

L'aspetto più intrigante del TE MPLS, è che consente di creare percorsi arbitrari, su cui inoltrare del traffico ritenuto importante. Devo riconoscere che con il passare del tempo, grazie alla caduta libera dei costi per unità di banda, il TE MPLS ha perso un po' del "fascino" iniziale. Però è ancora molto utilizzato. Solo per fare un esempio, il maggiore ISP Italiano fa viaggiare tutto il traffico telefonico nazionale su percorsi realizzati via TE MPLS. 

Il problema chiave del TE MPLS è come ottimizzare il calcolo dei percorsi. Purtroppo da questo punto di vista, il TE MPLS classico soffre di un problema legato alla completa "visibilità" della rete. La determinazione dei percorsi online è infatti basata su una estensione del classico LSDB dei protocolli Link State (OSPF, IS-IS), estensione che arricchisce il LSDB di base con delle informazioni aggiuntive sulle proprietà dei singoli collegamenti, che consentono una determinazione di percorsi soggetta a vincoli di vario tipo. 

Il problema è però che la visibilità dei LSDB è circoscritta a una sola parte del dominio di routing. Ad esempio, in una rete OSPF multiarea, un LSDB conosce la topologia logica di una particolare area, ignorando completamente la topologia delle altre aree. Una cosa simile accade in IS-IS, dove i LSDB di Livello 1 sono a conoscenza della sola topologia di una singola area e il LSDB di Livello 2 ha le sole informazioni topologiche del backbone IS-IS. Per cui, i percorsi TE MPLS possono essere realizzati solo all'interno di un'area, o del solo backbone IS-IS. E questo porta alla realizzazione di percorsi non ottimi (NOTA: un problema simile si incontra in IS-IS, e in OSPF per le aree stub/Totally Stubby/NSSA/Totally NSSA).

Un altro problema legato alla non completa "visibilità" globale della rete, è il problema del bin packing, un problema classico di ricerca operativa, che trasportato nel linguaggio del TE MPLS, è il problema dell'allocazione ottima dei percorsi TE MPLS soggetti a un vincolo di banda. In soldoni, il problema del bin packing consiste in questo: data una topologia di rete e una banda disponibile per ciascun link, come è possibile allocare il numero massimo di percorsi TE MPLS, ciascuno richiedente una determinata banda ? (NOTA: il problema originario parla di pacchi di dimensione variabile, da allocare in un determinato numero di container).

Una soluzione a questi problemi si avrebbe se gli algoritmi deputati alla determinazione dei percorsi ottimi (vincolati) avessero a disposizione l'intera topologia della rete. Quale soluzione migliore quindi, di quella di avere un sistema centralizzato (un controller !) che conosca l'intera topologia della rete, e mettere questa conoscenza a disposizione degli algoritmi deputati alla determinazione dei percorsi ottimi ? La presa d'atto di questo problema si è comunque avuta molto prima dell'introduzione del paradigma SDN. In ambito IETF è stata 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.

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 (o se preferite, switch, tanto nel linguaggio SDN coincidono; sono diversi solo sulla mente dei "markettari" !), che ha il compito di realizzare i percorsi decisi dal PCE, utilizzando come protocollo di segnalazione RSVP-TE. Si noti che in generale, non tutti i router sono necessariamente PCC, ma solo quelli da dove originano i percorsi TE MPLS, ossia i router PE di ingresso.

Ovviamente il PCE, che risiede nel controller, per ottimizzare i suoi calcoli, deve avere a disposizione la completa topologia (logica) della rete e le proprietà di ciascun link. Ma a questo pensa il BGP-LS citato nella sezione precedente, o qualsiasi altra funzionalità, a seconda dei protocolli supportati dai router della rete sottostante.

L'idea del PCEP è riassunta nella figura seguente. Per le applicazioni a SDN, sono in via di definizione alcune modifiche alla versione originale, attualmente allo stato di draft IETF, ma già implementate dai principali vendor. Di queste tratterò nel post di approfondimento sul PCEP.

Al momento esistono varie soluzioni commerciali che implementano il protocollo PCEP. Le più note sono la Juniper Northstar e Cisco Open SDN Controller, quest'ultima basata su Open DayLight. Queste soluzioni sono il risultato di due acquisizioni: Wandl da parte di Juniper e Cariden da parte di Cisco.

CONCLUSIONI
E' fuor di dubbio che l'introduzione di OpenFlow è stata una scintilla che ha causato un cambiamento di mentalità nel settore del networking, innescando un sano dibattito che ha agito come un catalizzatore per l'era SDN.

Detto questo, vi è in atto una accesa discussione circa la rilevanza tecnica di OpenFlow. Mentre alcuni credono che OpenFlow sia un componente chiave ed indispensabile per la realizzazione di un architettura SDN, altri ritengono che non propone nulla di fondamentalmente nuovo, e che peggio sia un libro dei sogni, che sbatterà il muso con insormontabili problemi di scalabilità (vedi a questo proposito un bellissimo post del mio amico e grande guru del networking IP Ivan Pepelnjak, intitolato "OpenFlow and Fermi Estimates"). 


In tutta onestà, come con qualsiasi altro protocollo o tecnologia, OpenFlow si sta evolvendo attraverso le sue diverse versioni. Sarà solo il tempo a dire se davvero nel futuro apporterà dei vantaggi o no al mondo del networking.

In parallelo allo sviluppo di OpenFlow, altri enti di standardizzazione, come ad esempio IETF, stanno sviluppando concetti simili. Anzi, alcuni sono anche precedenti all'introduzione di OpenFlow e del paradigma SDN. In particolare, due dei "gioielli della corona" di IETF, BGP e MPLS, stanno guadagnando slancio come protocolli SDN-Enabler.

Non è sorprendente trovare ancora il vecchio BGP nell'era SDN, perché è il protocollo più scalabile che sia mai stato progettato e realizzato, e l'Internet ne è il testimone migliore. E anche MPLS, grazie alla sua idea ancestrale di disaccoppiamento del servizio dal trasporto, sta guadagnando una rilevanza sempre crescente nello sviluppo e nella distribuzione di soluzioni SDN scalabili.  

Ben, come potete immaginare, questo è un post di assaggio. Ho introdotto vari concetti nuovi (nuovi per questo blog ovviamente !) e tante altre cose che dovranno essere approfondite.

L'approfondimento inizierà da OpenFlow, con un post in preparazione, scritto dal mio giovane e brillante collega Lorenzo Salvatore. 

Stay tuned !!!

P.S. Vi ricordo che potete essere avvisati via e-mail di ogni nuovo post, utilizzando il riquadro a destra "Seguimi via e-mail", presente nella Home Page del blog (niente di invasivo, tranquilli, una e-mail ogni 15 giorni circa).  Tutto ciò che dovete fare è inserire il vostro indirizzo e-mail, e quindi confermare l'iscrizione rispondendo a una e-mail iniziale. Alcuni amici mi hanno segnalato il problema che questa e-mail viene a volte inserita nella posta indesiderata, per cui se non la vedete controllate che non sia finita lì.