NT1-4-2013.pdf

8/19/2019 NT1-4-2013.pdf

1/14

SOFTWARE DEFINED NETWORKING:

SFIDE E OPPORTUNITÀ PER LE RETI DEL FUTUROAntonio Manzalini, Vinicio Vercellone, Mario Ullio

30Usa il tuo

smartphone per 

visualizzare

approfondimenti

multimediali

8/19/2019 NT1-4-2013.pdf

2/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y 

Il paradigma SDN (Software Dened Networking), secondo l’accezione più diusa, propone l’am-biziosa visione di rendere i nodi di rete (ad es. router e switch) programmabili, introducendoopportuni livelli di astrazione, ai quali accedere attraverso l’uso di interfacce di controllo (API).Nell’ambito di questo paradigma, assume particolare rilievo anche il concetto di virtualizzazio-

ne di rete, ovvero l’idea di creare delle partizioni virtuali dell’infrastruttura di rete sica, in mododa permettere a più istanze di controllo e le rispettive applicazioni di utilizzare le partizioni asse-gnate: questo permetterebbe coesistenza di più reti virtuali, completamente isolate, che insisto-no sulla medesima infrastruttura hardware.La centralizzazione logica del controllo, potrebbe permettere di attuare più facilmente azioni dicongurazione e ottimizzazione delle risorse di rete. L’adozione di questo paradigma potrebbeabilitare lo sviluppo di nuovi ecosistemi.

Introduzione1

Operatore Lean o Smart ? È unadelle domande chiave. L’Operato-re Lean, in estrema sintesi, inve-ste principalmente sul ruolo di BitCarrier nell’ottica di consolidareil proprio business tradizionale,quindi punta ad un forte conte-nimento dei costi ma anche aduno snellimento dei processi or-ganizzativi; l’Operatore Smart,dovrebbe operare in maniera più

disruptive, secondo una galassiadi imprese, che puntano allo svi-luppo di nuovi ecosistemi e nuovimodelli di business.L’innovazione tecnologica legataal potenziale sviluppo del para-digma SDN potrebbe impattareentrambi i ruoli, ovviamente inmaniera più o meno sensibile, infunzione del livello e delle moda-lità di possibile adozione: infattimentre da una parte SDN potreb-

be portare vantaggi economiciper gli Operatori Lean, dall’altra

potrebbe abilitare lo sviluppo dinuovi ecosistemi di servizi, checostituirebbero potenziali oppor-tunità di sviluppo per gli Operato-ri Smart, nella misura in cui que-sti riescano a ritagliarsi un ruoloe inserirsi in un modello di busi-ness vantaggioso.Una delle principali sde tecnolo-giche del paradigma SDN riguar-da la centralizzazione della logicadel controllo: questo abiliterebbe

le applicazioni ad acquisire una vista astratta della rete, come sequesta fosse governata da un pia-no di controllo concettualmentecentralizzato (ed integrato conil sistema di gestione). Diventaquindi possibile implementarelogiche di controllo astraendodalla complessità sica della mol-teplicità degli apparati di rete. Lostrato di controllo ha il compi-to di presentare una vista unica,

globale e logicamente centraliz-zata, gestendo la topologia sica

della rete e la distribuzione delleinformazioni di stato necessariead implementare le logiche diservizio. Il cuore della SDN asso-miglia dunque ad un ecosistemadi moduli software di controllo,interagenti fra di loro e capaci diattuare più facilmente azioni dicongurazione e ottimizzazionedelle risorse di rete. D’altra parte,la stessa centralizzazione logicadel controllo potrebbe avere dei

punti critici, quali ad esempio li- velli di prestazioni, adabilità,scalabilità e stabilità [1].L’introduzione di diversi livel-li di astrazione di rete coniugatacon la virtualizzazione integratadelle risorse IT e di rete potrebbepermettere di estendere alle rete iparadigmi e gli strumenti (oppor-tunamente adeguati) oggi utiliz-zati all’interno dei Data Center:ad esempio uno dei vantaggi più

31

8/19/2019 NT1-4-2013.pdf

3/14

concreti potrebbe essere intro-durre nella rete dell’Operatore diun livello di essibilità, ad oggiimpensato, abilitandone la pro-grammabilità e permettendo diallocare ed invocare funzionalità

 virtualizzate di rete a seconda del-le esigenze e nei punti più oppor-tuni; a questo si aggiungerebbe lapossibilità di realizzare ridondan-ze (ad es. over-provisioning del-la connettività virtuale) secondoschemi ad oggi impossibili, e lacapacità rinnovare le piattaformehardware con limitato (o addirit-

tura senza) impatto sui servizi.Inoltre, potrebbe diventare parti-colarmente signicativo valutarele potenziali opportunità oertedalla declinazione del paradigmaSDN all’edge della rete (ad esem-pio, anche no a casa dell’Utente)nell’ottica di sviluppare nuovi ser-

 vizi ICT e nuovi modelli di busi-ness.Inne è utile rimarcare che il temaSDN, a dispetto dell’enfasi e delle

aspettative di cui è oggetto in que-sto momento, sebbene suragateda indubbie potenzialità dell’idea,necessita ancora di progressi nelprocesso di standardizzazione edi raggiungere una piena maturitàe disponibilità tecnologica per po-tere essere seriamente consideratoper un dispiegamento in campo.

 A questo proposito, quindi, anchegli esempi di attività internazio-nali sull’argomento, riportati nel

Capitolo 2, stanno a testimoniaresoprattutto lo sforzo di elaborareuna vision e di vericarne le po-tenzialità attraverso attività esplo-rative e “proof of concept”.

Il paradigma Software Dened

Networking2

SDN sta diventando una ‘keyword’imprescindibile per le architettu-

re di rete evoluta anche se ad oggimanca di fatto una visione comu-ne di quali siano gli obiettivi e glielementi che identicano questonuovo paradigma.Secondo Scott Shenker [2] e NickMcKeown [3] l’obiettivo principa-le di SDN è ristrutturare l’architet-tura di networking, introducendoopportuni livelli di astrazione ingrado di operare una trasforma-zione simile a quanto già avvenutonel campo delle architetture ela-borative. Nell’ambito del compu-ting infatti ormai da molto tempo

i programmatori sono in grado diimplementare sistemi complessisenza dovere gestire le tecnicalitàdei singoli dispositivi coinvolti ointeragire in linguaggio macchi-na, il tutto proprio grazie all’in-troduzione di opportuni livelli diastrazione nell’architettura.Questa visione, decisamente am-biziosa che propone un cambia-mento radicale nelle reti, non èmessa in discussione, ma spesso

da molti è erroneamente iden-ticata con aspetti specici cheprobabilmente hanno un impat-to decisamente più limitato. Adesempio alcuni identicano SDNcon il problema della separazionedel piano di controllo dagli appa-rati di rete e della sua centralizza-zione, altri si focalizzano sull’a-pertura di interfacce di controllosui router attuali: entrambe que-ste innovazioni sono solo compo-

nenti di una soluzione comples-siva che permette l’interazionedelle applicazioni con la rete inmodo sucientemente sempliceda stimolare una vasta produzio-ne di nuove applicazioni. Eviden-za di questo fatto è che soluzionitecniche per questi due proble-mi specici esistono da anni (adesempio i lavori in IETF sul proto-collo ForCES, che permette la se-parazione tra piano di controllo e

piano di forwarding, è RFC già dal2010 [4]; Juniper mette a disposi-zione da anni API ed SDK sui pro-pri router), ma non hanno trovatosino ad oggi signicativo impiego.L’aspetto su cui si stanno da anniconcentrando le attività è la de-nizione del protocollo OF (Open-Flow), sviluppato inizialmente alivello accademico ed ora adottatoanche dalla ONF (Open Networ-king Foundation) come principaleipotesi di lavoro e fondamento dellavoro di standardizzazione.

IlprotocolloOpenFlow2.1

Il protocollo OpenFlow si ritieneche rappresenti un fattore abili-tante, anche se da solo ovviamen-te non suciente, per realizzarela trasformazione verso i concettidi rete essibile e programmabile.È inoltre doveroso aggiungere chela sua denizione non è al mo-

mento consolidata, ma è ancorasuscettibile di evoluzioni e perfe-zionamentiL’interfaccia realizzata da Open-Flow si colloca al livello più bassodi astrazione previsto dall’archi-tettura SDN, essa permette in-fatti di svincolarsi dall’hardwaredi forwarding dei pacchetti. Inquesto senso, uno degli aspettifondamentali, che sta alla basedell’attività di specica avviata

da OpenFlow, consiste nella de-nizione di un modello standarddell’hardware di forwarding deipacchetti che costituisce il nucleodei diversi dispositivi di networ-king. Scopo del protocollo Open-Flow è quindi, in questo senso,quello di presentare all’esternoun modello di nodo generale eunicato, rendendo gli strati piùalti dell’architettura di rete SDNindipendenti dall’implementa-

32

8/19/2019 NT1-4-2013.pdf

4/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y 

zione del particolare vendor delletecnologie impiegate nel piano diforwarding.Risalendo alle origini della propo-sta, l’idea di base di OpenFlow èquella di rendere programmabiliin senso generale le tabelle di clas-

sicazione ed instradamento deipacchetti presenti negli apparatidi networking (siano essi router oswitch); in questo modo il conte-nuto (le cosiddette entry) può es-sere congurato dalle applicazioni,per il tramite di un piano di con-trollo esterno al dispositivo, me-diante un’opportuna interfaccia.Quest’ultima, costituita appuntodal protocollo OpenFlow, permet-te di denirne in modo essibile il

contenuto, in funzione della logicadi servizio da realizzare.Le tabelle utilizzate per la clas-sicazione del traco a bordodei router sono generalmente ingrado di operare a velocità di li-nea e vengono sfruttate ancheper realizzare funzioni aggiun-tive al forwarding di base, quali:rewall, NAT, QoS, ecc. Nel mo-dello del nodo OpenFlow, questetabelle vengono denominate ow

table e specicano le regole ditrattamento associate a ciascunusso di traco. L’entità basecon cui viene rappresentato egestito il traco in OpenFlow èper l’appunto il usso di pacchet-ti ( ow); quest’ultimo è denito

da una regola di classicazioneottenuta specicando il contenu-to di opportuni campi dell’inte-stazione tramite una entry della

 ow table. Il protocollo Open-Flow permette quindi al pianodi controllo di denire in modoessibile e dinamico le regole di

instradamento e trattamento deipacchetti appartenenti ai diversiussi di traco.Normalmente l’implementazionedelle tabelle di classicazione deipacchetti, che presiedono alla de-nizione dei ussi e alla relativeregole di inoltro, è una caratteristi-ca proprietaria del particolare ap-parato di networking. Per superarequesto modello, OpenFlow miraad individuare e specicare ed arendere accessibili attraverso ilprotocollo, un insieme di funzionisupportate dalla maggior parte dei

router o switch commerciali. L’o-biettivo principale consiste quindinel denire un modello astrattodell’elemento che esegue il forwar-ding dei pacchetti, rendendoloprogrammabile attraverso un in-terfaccia aperta e standard.Uno schema molto semplicatodell’architettura OpenFlow è ri-portato nella Figura 2 seguente.In particolare lo schema di prin-cipio fa riferimento alla versione

base dell’architettura, come de-nita dalla specica OpenFlow nel-la versione 1.0.I principali elementi funzionalidel sistema, come si osserva dallagura, sono i seguenti:1) una tabella (Flow Table) i cui

elementi (entry) definiscono i

Feature

NorthBound API

Applicazioni

Network OS

Firmware

CPU NPU ASIC CAM...

HAL(Hardware Abstraction Layer)

OpenFlow

SDN Controller

Packet Forwarding

(routing, switch, ecc.)

Figura 1 - Rappresentazione dell’architettura di rete SDN

Scope of OpenFlow Switch Specification

Controller

OpenFlow

Protocol

SSLsw Secure Channel

OpenFlow Switch

Flow Tablehw

PC

Figura 2 - Schema di principio di un nodo OpenFlow

33

8/19/2019 NT1-4-2013.pdf

5/14

flussi e le azioni associate, de-terminando il trattamento daapplicare ai pacchetti apparte-nenti ai flussi stessi;

2) un canale sicuro (Secure Chan-nel ) tra il nodo ed un processodi controllo remoto (control-ler), che consente lo scambiodi pacchetti e messaggi di co-mando;

3) il protocollo OpenFlow, comeinterfaccia di comunicazionestandard ed aperta tra il nodoed il controller.

In linea di principio si può di-

stinguere un nodo nativo Open-Flow, in grado di svolgere tutte lesue funzioni unicamente tramiteprogrammazione remota da par-te di un controllore ed un nodotradizionale (es. router o switchcommerciale), che sia anche ingrado di ricevere ed interpreta-re comandi mediante OpenFlow.Nel seguito, indicheremo questotipo di apparati con il terminenodo OpenFlow ibrido, in uso in

ambito ONF, ente incaricato dellosviluppo degli standard su SDN/OpenFlow. I nodi ibridi rappre-sentano infatti lo scenario più re-alistico, nell’ipotesi di un’introdu-zione in rete della tecnologia.Gli elementi contenuti nella FlowTable (le versioni più recenti dellaspecica prevedono la presenza dipiù tabelle in cascata) specicanocome devono essere gestiti i diver-si ussi di pacchetti. Le azioni di

base, che il nodo deve OpenFlowdeve supportare sono:1) inoltrare il pacchetto verso una

determinata porta di uscita,2) incapsulare il pacchetto e spe-

dirlo al controller attraversol’interfaccia di comunicazio-ne; tipicamente questa azione

 viene applicata al primo pac-chetto di un nuovo flusso, ilcontroller potrà poi decideredi configurare un nuovo entry

nella tabella per specificare iltrattamento dei pacchetti suc-cessivi; infine, nulla vieta, incasi particolari, di inviare tuttii pacchetti di un flusso verso ilcontroller per la loro elabora-zione;

3) scartare i pacchetti apparte-nenti al flusso;

4) trattare i pacchetti secondo lenormali procedure di forwar-ding del nodo (nel caso di nodiOpenFlow ibridi).

Glisviluppirecenti

2.2La denizione dell’architetturaOpenFlow ha subito delle evolu-zioni rispetto alla versione inizia-le da quando è stata fatto oggettodi studio e specica da parte diONF ed ha visto parallelamenteun sempre maggiore coinvolgi-mento da parte dell’industria. Adierenza della semplice schema-

tizzazione discussa in precedenzaa titolo esemplicativo, il modellodi nodo OF attualmente denitodalla versione più recente dellaspecica (Versione 1.3) prevede lapresenza di una sequenza di  owtable in cascata, al ne di consen-tire una maggiore essibilità neltrattamento dei pacchetti.Inne è bene notare che, se l’in-troduzione di un livello di inter-facciamento aperto verso i dispo-

sitivi di forwarding rimane unodei capisaldi dell’architetturaSDN, comincia ad emergere, inseno alla comunità scientica eindustriale che lavora alla de-nizione di OpenFlow, l’idea chel’astrazione supportata dalle ver-sioni di OpenFlow attualmentein corso di specica (versioni 1.x)sia soggetta a limiti che possonoostacolare la piena applicabilitàdella tecnologia.

Il principale limite identica-to, all’interno della stessa ONF,per il modello corrente, consistenel fatto che la rappresentazionesemplicata su cui si basa attual-mente OpenFlow non è in gradodi veicolare agevolmente le infor-mazioni sulla logica di forwardingche l’applicazione intende im-plementare, rendendo dicile senon talora impossibile fare levasulle funzionalità messe a dispo-sizione dall’hardware. Anche nelmodello corrente, la rappresen-tazione consiste in una sequenza

di tabelle e obbliga l’applicazionea ragionare a basso livello, man-cando in denitiva la possibilitàdi esprimere in termini concisiil comportamento (il cosiddetto forwarding behavior ) end-to-enddesiderato.Questa è la ragione principale percui in ambito ONF è stato istitu-ito di recente un nuovo gruppodi lavoro incaricato della de-nizione del modello astratto del

piano di forwarding del nodo.Sarà poi compito di un opportu-no HAL (Hardware AbstractionLayer ) presentare ai livelli supe-riori tale astrazione (Figura 1),interpretando i comandi prove-nienti dal controllo. Naturalmen-te, la denizione del livello HALnon rientra tra i compiti di ONF;trattandosi di un aspetto speci-co legato alle diverse implemen-tazioni tecnologiche dei vendor,

spetta a questi ultimi svilupparetale strato di adattamento sul lorohardware proprietario.Parallelamente all’iniziativa direvisione di OpenFlow scaturitada ONF, si segnalano altre criti-che mosse al modello corrente daparte di esponenti della comunitàscientica. Ad esempio, secondoun parere autorevole [5], il proto-collo OF, così com’è denito oggi,sarebbe troppo complesso per un

34

8/19/2019 NT1-4-2013.pdf

6/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y 

impiego nel core della rete, a sca-pito della sua scalabilità, ed invecetroppo semplicato per soddisfa-re i requisiti di maggiore ricchez-za funzionale tipici dell’edge diservizio. Da questa critica conse-gue la proposta di dierenziare le

 versioni del protocollo a secondadell’ambito di applicazione; sug-gerendo un’implementazione sof-tware della versione destinata acontrollare i nodi edge della rete,per una maggiore essibilità edevoluzione della tecnologia, man-tenendo invece un prolo molto

semplice per il core della rete abenecio della scalabilità e del co-sto ma anche della compatibilitàin ambiente multi-vendor.

Illivellodeicontrollercomesistema

operativodirete2.3

Come si nota nella Figura 1, unodegli elementi che compongo-no l’architettura SDN è costituito

dallo strato di cui fanno parte icontroller. Vale la pena ricordare che tradi-zionalmente nelle reti a pacchettole funzionalità del piano di con-trollo e quelle del piano dati sonostrettamente accoppiate; ossiache sono gli stessi dispositivi cheeettuano il forwarding del tra-co a decidere come trattare e doveinoltrare i pacchetti.Da questo punto di vista, il para-

digma SDN/OpenFlow introduceinvece, come già accennato, unprincipio di disaccoppiamento trapiano di controllo e di forwarding.L’approccio adottato prevede discorporare le funzionalità delpiano di controllo ed assegnarlead elementi dedicati. Ciascunodei controller, a sua volta, gesti-sce uno o più nodi che eettuanoil forwarding dei pacchetti. Unodegli aspetti salienti della visio-

ne SDN è quindi la possibilità didisegnare le applicazioni consi-derando la rete come se fosse go-

 vernata da un piano di controlloconcettualmente centralizzato,invece che con un sistema com-plesso e distribuito. Le applicazio-ni possono quindi implementarele loro logiche di controllo astra-endo dalla complessità sica dellarete, sarà compito dei controllerpresentare una vista unica, glo-bale e logicamente centralizzata,gestendo la topologia sica dellarete e la distribuzione delle infor-

mazioni di stato necessarie ad im-plementare le logiche di servizio.Lo strato di controllo dell’archi-tettura SDN sarà generalmentecomposto da un ecosistema dimoduli software, di cui il princi-pale nucleo è costituito dal con-troller. Sebbene non vi sia unadenizione completamente uni-

 voca e universalmente condivisadi controller, un punto fermo èrappresentato dal fatto che esso

ha il compito di terminare l’in-terfaccia OpenFlow (vedi Figura1). Inoltre questo modulo oreun’interfaccia di programmazio-ne verso le applicazioni, sianoesse interne o esterne allo stratodi controllo stesso. È quella chein ambito ONF viene convenzio-nalmente indicata con il terminedi “northbound” API, mediante laquale le applicazionipossono fare uso delle funziona-

lità oerte dal controller. Questostrato dell’architettura SDN puòessere visto più in generale comel’analogo di un sistema operativodi rete (Network OS), come taledeve orire varie funzionalità disupporto, quali fra l’altro la ge-stione della comunicazione framoduli e l’aggiunta di nuove com-ponenti.Se l’astrazione presentata dall’ar-chitettura SDN alle applicazioni

è quella di un controllore logica-mente centralizzato, dal punto di

 vista realizzativo sono possibilidiverse scelte progettuali. In lineadi principio, quella di un elemen-to di controllo sicamente centra-lizzato è un opzione possibile, eforse adatta per ambiti molto cir-coscritti, quali una rete sperimen-tale o un campus universitario,ma certamente non adeguata peril dispiegamento in reti di produ-zione. La centralizzazione di unelemento così critico per il fun-zionamento della rete comporta

infatti evidenti limiti dal punto di vista di: prestazioni, in particolaretempi di risposta, a causa dei ri-tardi di propagazione dovuti alledistanze geograche, adabili-tà, in termini di raggiungibilità edisponibilità dell’elemento e sca-labilità. Questo signica che l’ar-chitettura del controllo dovrà ingenerale essere composta da ele-menti sicamente replicati e di-stribuiti, ma capaci di comportar-

si nel complesso come un piano dicontrollo logicamente centraliz-zato. Naturalmente un certo gra-do di distribuzione dei controllerrichiede la gestione delle usua-li problematiche di consistenzadelle informazioni di stato tipi-che dei sistemi distribuiti. I varicontroller dovranno poi essere ingrado di dialogare tra loro, attra-

 verso opportune interfacce “oriz-zontali”, in particolare nel caso in

cui essi appartengano a domini direte dierenti dal punto di vistageograco e amministrativo.Quindi, riassumendo, dal puntodi vista dell’organizzazione delpiano di controllo la vera novitàintrodotta da SDN non sta nel-la sua centralizzazione, peraltrologica, bensì nella possibilità disvincolarne la topologia da quelladei nodi di rete che eettuano ilforwarding del traco.

35

8/19/2019 NT1-4-2013.pdf

7/14

Lavirtualizzazionedirete2.4

Un ulteriore ingrediente che è par-te integrante della visione SDN re-lativamente allo strato di NetworkOS è rappresentato dalla virtua-lizzazione di rete (si veda anche ilriquadro di testo su questo argo-mento). Infatti, analogamente acome, nel mondo del computing,l’introduzione delle tecnologiedi virtualizzazione ha consentitopartizionare e condividere le ri-sorse elaborative hardware, sotto

forma di macchine virtuali, tra piùistanze di sistemi operativi, si puòpensare di applicare dei principidi virtualizzazione (slicing) anchealle risorse di rete.L’obiettivo della virtualizzazio-ne di rete, nel contesto Open-Flow/SDN, consiste dunque nelricavare delle partizioni virtualidell’infrastruttura di rete si-ca, in modo da permettere a piùistanze di controllo e rispettive

applicazioni di utilizzare la slice di rete assegnata, come se fossea tutti gli eetti dedicata e com-pletamente isolata dalle altre reti

 virtuali che insistono sulla me-desima infrastruttura hardware.Le tecniche di virtualizzazionedovrebbero consentire ai diversisoggetti che condividono l’infra-struttura ed alle relative applica-zioni di implementare protocollie schemi di indirizzamento total-

mente indipendenti.In questo senso, già oggi nell’am-bito dei data center e delle archi-tetture di cloud computing, le tec-nologie di virtualizzazione, comead esempio gli switch virtualizzati(vSwitch) realizzati all’interno deimoduli di gestione delle macchi-ne virtuali, i cosiddetti hypervisor ,giocano un ruolo chiave nell’e-

 voluzione di queste soluzioni erappresentano una realtà ormai

aermata dal punto vista com-merciale.Naturalmente diversi e più artico-lati sono i requisiti ed i problemida arontare per esportare le tec-nologie di virtualizzazione anchenell’ambito delle reti di telecomu-nicazione geograche, tuttavia visono segnali di una possibile evolu-zione proprio in questa direzione.

 Ad oggi, invece, le tecniche persupportare dei principi di virtua-lizzazione in un ambiente gene-rico di rete sono ancora in fase disviluppo e le implementazioni

disponibili sono limitate. Si trattasostanzialmente di strumenti de-stinati ad applicazioni in contestisperimentali e di ricerca, come ilsoftware FlowVisor [6], sviluppatonell’ambito del framework Open-Flow. Come le tecnologie di hyper-visor   si situano tra l’hardware dicomputing ed il sistema operativo,infatti, il FlowVisor si colloca tra ilcontroller OpenFlow ed il piano diforwarding, introducendo nell’ar-

chitettura un meccanismo di vir-tualizzazione (slicing) di rete.Il FlowVisor si incarica di garanti-re che le diverse istanze di control-lo siano in grado di vedere e gesti-re solo la slice  a loro assegnata,assicurandone l’isolamento dallealtre slice  congurate in rete. Daun punto di vista implementativo,il FlowVisor si inserisce in modotrasparente, in modalità  proxy,tra l’interfaccia OpenFlow ed il

controller, intercettando ed ela-borando i messaggi scambiati. IlFlowVisor costituisce un’imple-mentazione ancora embrionaledei principi di virtualizzazione epresenta alcune limitazioni, peresempio le topologie virtuali pos-sono essere costituite solo da sot-toinsiemi della topologia sica.Tuttavia si può sicuramente aer-mare che le tecnologie di virtua-lizzazione della rete costituiscono

in prospettiva una componentequalicante dell’architettura SDNe potenzialmente in grado, quan-do mature, di abilitare nuovi edecaci modelli di condivisionedelle infrastrutture di rete.

Alcuni scenari e possibili vantaggi perl’Operatore3

L’interesse per il paradigma SDNè anche testimoniato dal crescen-te numero di iniziative interna-zionali di carattere industriale e

da una serie di attività di sviluppospeciche, prototipazione e pre-standardizzazione, nonché dalsorgere di start-up.In sintesi, se da un parte il para-digma SDN potrebbe permetteredi attuare più facilmente azioni dicongurazione e ottimizzazionedelle risorse di rete e dall’altra par-te, l’introduzione di diversi livellidi astrazione di rete coniugatacon la virtualizzazione integrata

delle risorse IT e di rete potrebbepermettere di estendere alle rete iparadigmi attualmente utilizzatiall’interno dei Data Center.La migrazione dell’intelligenzadel piano di controllo dagli ap-parati ad un sistema logicamentecentralizzati potrebbe favorire losviluppo di una nuova generazio-ne di software router ad alte pre-stazioni (100 o più Gbps) basati suhardware standard. Il throughput

di un router è fondamentalmentelimitato dal routing processing(che detta il tradeo tra numerodi porte e relative banda per con-nessione): il paradigma SDN po-trebbe permettere il superamentodi questa limitazione, rendendopossibile attuare in rete delle ri-dondanze (ad es. over-provisio-ning della connettività virtuale)secondo schemi ad oggi impossi-bili, o introducendo un alto livello

36

8/19/2019 NT1-4-2013.pdf

8/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y 

di essibilità e programmazionenell’utilizzo delle risorse di rete.Nel seguito di riportano alcuniesempi di attività internazionalidi ricerca e sviluppo.Il progetto FP7 SPARC “Split ar-chitecture carrier class networks”,nanziato dalla Comunità Euro-pea e coordinato da Deutsche Te-lekom, ha portato allo sviluppo esperimentazione di nodi di retebasati sul disaccoppiamento deipiani di controllo e forwarding.I prototipi di nodo sviluppatinel progetto SPARC si basano su

piattaforme hardware fornite daCavium, Broadcom ed Emerson.Inoltre, in linea con questi svilup-pi, Deutsche Telekom sta speri-mentando l’utilizzo di soluzionialla OpenFlow/SDN nell’ambitodello sviluppo della rete green-eld TeraStream dispiegata inCroazia (gura 3). L’architettu-ra punta a sfruttare la potenza dicalcolo dei Data Centre dell’Ope-

Could Service Center

(TV, IMS,CDN, OTT,...)

Could Service Center

(TV, IMS,CDN, OTT,...)

DE intern

DWDM

DWDM

xDSL OLT   Mobile   FTTx

L2 Agg L2 AggL2 Switch

R2 R2

R1 R1 R1R1

Figura 3 – TeraStream Architecture (Fonte DT)

Example: the virtual network provided to a user is in the form of a single-star switched network 

Virtual networks (slices)

Physical network IT resources

NW resources

Figura 4 – Visione di NTT sulla rete del futuro: astraz ione e integrazione di risorse di rete e IT (Fonte NTT) 

ratore (attestati ai nodi R2) per lacentralizzazione di alcune logichedi controllo di rete e per l’ottimiz-zazione di alcuni processi di ge-stione.

 Virtualizzazione, programmabi-lità e integrazione delle risorsedi rete e IT sono le caratteristicheprincipali della visione di NTT peril futuro della rete. L’astrazione

37

8/19/2019 NT1-4-2013.pdf

9/14

 virtuale delle risorse permette-rebbe l’esercizio di una moltepli-cità di reti logiche (overlay) coe-sistenti ma separate sulla stessainfrastruttura sica.La programmabilità ai diversi li-

 velli di rete (con interfacce stan-dard) aumenterebbe ulteriormen-te la essibilità nella fornitura diservizi (Figura 4).In gura 5 è illustrato un esempiodi scenario di utilizzo di SDN perl’interconnessione di data centrein corso di sviluppo in TelefonicaI+D.

Le applicazioni (attraverso l’SDNOrchestrator) potrebbero riserva-re le risorse IT e di rete in manieraintegrata, secondo i requisiti ri-chiesti e per il tempo necessarioad eseguire determinati task, oper attuare migrazioni tra diversi

Application

SDN Orchestrator

Elastic Core Network Data

CenterA

DataCenter

B

Coordination of the IT and

network resources to optimally

used the overall resources

Automatic provision based on

standard interfaces

OpenflowOpenflow

NorthBound

Interface

Provisioning,Discovery,Monitoring

Figura 5 – Interconnessione di Data Centre (Fonte Telefonica I+D) 

Figura 6 – Dynamic Enterprise Cloud (Fonte Verizon)

Customer Data Centers,

Sensors, etc.

ANC - Application Network Controller

1. Customer requests Cloud Computing (CC) service instance

 2. CC service checks resourcestatus, commands resourcechanges as needed 

5. CC servicereleases all resources, updates status

3. Customer executes Cloud Computing (CC) application

4. Customer releasesCC service instance

TNC - Transport Network Controller

CE

CE

PE

PE

PE

PE

PE

CE

CE

PE

Virtual Machines

Virtual Machines

Storage

Processing

Apps

Storage

Processing

Apps

Access Transport

Network 

Access Transport

Network 

Backbone

Transport Network 

CC ServiseController

(ANC)

TNC

TNC

TNC

server. È il modello del sistemaoperativo di rete.Un modello molto simile è ilDynamic Enterprise Cloud di Ve-

rizon (gura 6), dove nuovamentericorrono i temi della virtualizza-zione, programmabilità e integra-zione delle risorse di rete e IT.

38

8/19/2019 NT1-4-2013.pdf

10/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y 

Posizionamento dei Vendor 4

L’architettura SDN ha mostrato lacapacità di valicare i conni del-la ricerca accademica, all’inter-no della quale ha avuto origine ilprotocollo OpenFlow, e di aer-marsi concretamente nell’ambitodell’industria come paradigmaemergente di architettura di rete.Come ogni soluzione potenzial-mente in grado di portare tra-sformazioni anche signicativenel comparto industriale di ri-

ferimento, il paradigma SDN haprodotto reazioni diversicate daparte dei soggetti del settore, edin particolare dei vendor. Inten-diamo riferirci qui in primo luogoai vendor presenti nel segmentodi mercato delle piattaforme direte per i service provider, senzaperaltro trascurare ciò che avvienein settori adiacenti, le soluzioni dinetworking per le reti enterpri-se e i data center. Per cominciare

dalle realtà più pronte a muoversinel mercato che le nuove oppor-tunità tecnologiche sono in gradodi creare, partiamo dal caso dellenumerose startup che sono nateper esplorare questo lone.Fra tutte, possiamo citare Nicirae BigSwitch, entrambe fondate daesponenti di primo piano dell’u-niversità di Stanford che, lo ricor-diamo, è stata l’incubatore delleattività su SDN/OpenFlow. En-

trambe hanno orientato i loro svi-luppi verso uno sbocco commer-ciale nel segmento delle soluzionidi networking per il cloud com-puting ed i data center. In questoambito, OpenFlow viene impie-gato come elemento nell’ambitodi tecnologie di virtualizzazionedi rete. In particolare, Nicira, cheha sviluppato la piattaforma NVP( Network Virtualization Platform)basata sulla tecnologia Open

 vSwitch, è stata recentemente ac-quisita da VMware, leader nelletecnologie di virtualizzazione. Al-tro gruppo di vendor è rappresen-tato da costruttori come HP, IBMe Brocade, che dispongono di li-nee di prodotto basate su apparatidi networking destinati in primoluogo al segmento delle reti en-terprise/campus e dei data center.Questi vendor hanno già annun-ciato la disponibilità commercialedi prodotti in grado di supportareil protocollo OpenFlow; essi sonoinoltre tra gli esponenti più attivi

in questo momento all’interno deigruppi di lavoro di ONF. Anche i tradizionali fornitori ditecnologie per le reti dei serviceprovider stanno seguendo con at-tenzione questo lone ed elabo-rando le strategie per incorporareelementi della soluzione SDN neipropri prodotti. Si segnalano adesempio vendor come NEC cheproprio facendo leva sul temaSDN/OpenFlow stanno cercan-

do di riposizionarsi sul mercatonel settore del networking. NECè uno dei vendor particolarmen-te coinvolti nelle attività in ONFed ha annunciato una soluzione,l’architettura denominata Pro-grammableFlow, che introduceprincipi di programmabilità e di

 virtualizzazione nei dispositivi direte. Anche altri costruttori aer-mati di apparati di networking,come ad esempio Cisco e Juniper,

hanno inserito il tema SDN all’in-terno delle loro strategie evolutivedi prodotto.Generalmente viene prevista l’a-pertura di interfacce che consen-tono in qualche misura la pro-grammabilità dei nodi di rete; disolito l‘interazione con la piat-taforma avviene a livello più altorispetto a quanto prevede il pro-tocollo OpenFlow, e talvolta sonopresenti aspetti proprietari. In

sostanza, la losoa che in questomomento alcuni vendor propon-gono consiste in un approccio chepotremmo denire ibrido. Il con-trollo rimane fondamentalmen-te a bordo dei nodi e distribuito,ma le piattaforme si aprono per

 veicolare informazioni e accettareanche comandi di congurazione,relativamente ad alcuni aree fun-zionali, da elementi (controller)esterni.In questo senso, per esempio,molti si stanno orientando adesportare verso le applicazioni

informazioni sulla topologia e lostato dei nodi, anche se ciò con-trasta con la losoa SDN, cheprevede invece di creare livelli diastrazione progressivi, in modo darendere trasparente la complessi-tà sottostante allo strato applica-tivo. In ogni caso, l’introduzionedi principi di apertura rappresen-ta una novità per le strategie dei

 vendor incombenti.

Attività internazionali5

La notevole trazione che il temaSDN sta esercitando sull’industriaha fatto sì che siano state avviatediverse iniziative per cercare didenire delle soluzioni condivi-se e dei protocolli interoperabili.Prima fra tutte è l’ONF. Si trattadi una iniziativa relativamente re-

cente, costituitasi nel marzo delloscorso anno sotto forma di con-sorzio industriale non-prot.La missione principale di ONF èdi promuovere un nuovo approc-cio al networking ispirato ai prin-cipi dell’approccio SDN. In questaprospettiva, il consorzio ONF si èassunto come compito principalequello di presiedere allo sviluppodegli standard fondamentali al ri-guardo, tra i quali, in primo luogo,

39

8/19/2019 NT1-4-2013.pdf

11/14

Ormai da anni una delle tecnologie do-

minanti nei Data Center è quella di vir-

tualizzazione: Hypervisor commerciali

(e.g. VMware vSphere [7]) o Open

Source (e.g. XEN [8]) permettono di

utilizzare un server sico per realizza-

re istanze di server virtuali gestiti da

organizzazioni differenti e che utiliz-

zino eventualmente sistemi operativi

diversi.

Le tecnologie di virtualizzazione pos-

sono essere potenzialmente impiega-

te nel dominio di rete con due diversi

obiettivi:

  utilizzo di una stessa infrastruttura

sica per realizzare più reti virtuali,

appartenenti a soggetti diversi;

  utilizzo di una stessa piattaforma har-

dware per realizzare più funzionalità

di rete.

Il primo obiettivo è in realtà già indiriz-

zato da anni attraverso l’impiego della

tecnologia MPLS per realizzare reti pri-

vate virtuali (Virtual Private Network) dilivello 2 o livello 3, che utilizzano piani

di indirizzamento eventualmente so-

Network Virtualization

vrapposti; attraverso le soluzioni Car-

rier Supporting Carrier è anche possibi-

le condividere una stessa infrastruttura

tra più operatori. I vincoli delle soluzioni

attuali sono da una parte l’impossibili-

tà di applicare alle diverse partizioni di

rete soluzioni completamente disgiun-

te (tutte le reti virtuali condividono la

tecnologia IP/MPLS), dall’altra alcune

limitazioni quali la “granularità’” con cui

è possibile associare il trafco ad una

data rete virtuale (tipicamente una por-

ta logica e non un singolo usso) o la

limitata dinamicità.

Il secondo obiettivo si inserisce nel di-

battito su un dilemma tecnologico con

cui da anni devono confrontarsi i co-

struttori di apparati delle reti dati: realiz-

zazione delle funzioni in hardware o in

software. Negli ultimi 10-15 anni si è os-

servato una progressivo spostamento di

funzionalità negli apparati (forwarding,

accodamento differenziato, ltraggio del

trafco, …) da una realizzazione in sof -tware ad una realizzazione in hardware.

Questo ha permesso la realizzazione di

apparati con prestazioni via via crescen-

ti in grado di contrastare la crescita del

trafco mantenendo i costi contenuti. Il

perdurare di questa tendenza è tuttavia

oggi non così scontato:

  lo sviluppo di ASIC in grado di sup-

portare sempre nuove funzionalità a

velocità più elevata è sempre più com-

plesso e costoso e richiede tempi mol-

to lunghi (centinaia di risorse coinvolte,

tempi nell’ordine di 18-24 mesi);

  le nuove funzionalità introdotte all’in-

terno delle reti sono sempre più com-

plesse;

  l’ingegnerizzazione di nuovi servizi

in tempi relativamente brevi richie-

derebbe un’elevata essibilità delle

macchine;

  lo sviluppo tecnologico di server e

schede di rete non specializzati può

contare su un mercato molto più am-

pio.

Sulla base di questi fattori viene quindi

proposto un ritorno al passato con l’uti-lizzo di hardware non specializzato per

realizzare funzionalità di rete: in par -

la specica del protocollo Open-Flow. ONF è governata da un bo-ard costituito da rappresentantidi Deutsche Telekom, Facebook,Google, Microsoft, NTT, Verizone Yahoo. Anche Telecom Italia è

recentemente entrata a fare par-te del consorzio ONF, che anno- vera ormai oltre 70 membri, tracui diverse altre aziende di rilievocome: Cisco, HP, Juniper, IBM,Ericsson, VMware, NEC, Orangee Comcast.L’attività di specica di ONF èorganizzata in gruppo di lavoro.L’aspetto centrale del lavoro di de-nizione degli standard è rappre-sentato attualmente da OpenFlow,

sia in termini di modello dell’har-dware di rete che di protocollo. Aquesto riguardo sono al momentoattivi principalmente due gruppidi lavoro: il WG Extensibility edil WG Forwarding Abstractions,

di recente costituzione. Il primoha il compito di evolvere la spe-cica attuale, individuando edintroducendo estensioni volte adincrementarne la essibilità e laricchezza funzionale. Mentre ilsecondo si propone di ripensareil modello astratto del nodo conun duplice obiettivo; da un lato,renderne più agevole l’implemen-tazione sull’hardware piuttostoeterogeneo, per caratteristiche

ed architettura, dei dispositivi direte; dall’altro, permettere alle ap-plicazioni di controllo di esprime-re in modo più conciso ed ecaceil cosiddetto  forwarding behaviordesiderato, senza dover ragionare

in termini di compilazione di unnumero imprecisato di singole ow table. Accanto ai due grup-pi di lavoro citati ve ne sono poialtri i cui compiti riguardano peresempio la denizione del model-lo dei nodi ibridi (WG Hybrid ),arontando le problematiche diconsistenza nella gestione dellerisorse derivanti dalla presenzadi piani di controllo distinti, op-pure gli aspetti di congurazione

40

8/19/2019 NT1-4-2013.pdf

12/14

 S P E  C I  A L E 

 G  O V E R N A N  C E 

 S E  C  U R I  T Y 

N  U  O V E 

R E T I  

P R I  V A  C Y ticolare ad esempio le funzionalità ad

oggi fornite da appliance (NAT, Firewal-

ling, Deep Packet Inspection), quelle

fornite dagli apparati di Core Network

Mobile (GGSN, EPC, MME) o quelle

fornite dagli apparati di edge della rete

ssa (BRAS, PE). In questo contesto

le funzionalità diventano istanze SW

associate a macchine virtuali che con-

dividono una infrastruttura di server -

sici distribuiti sulla rete o concentrati in

Data Center di rete.

Un interrogativo rispetto a questa pro-

posizione è sicuramente quello delle

prestazioni: è scontato che l’impiego

di hardware non specializzato non per-

metta di ottenere le stesse prestazioni

attuali per realizzare alcune funziona-

lità, quindi le risorse computazionali

necessarie saranno quantitativamente

maggiori; l’interrogativo diventa quindi

se il costo complessivo di una architet-

tura di rete basata sul paradigma “Net-

work Virtualization” sia interessante ri-spetto alle soluzioni attuali come effetto

delle economie di scala sul hardware

general purpose e della maggiore con-

correnza sulle componenti software, o

se sia più conveniente un approccio

meno innovativo che cerchi di coniuga-

re hardware specializzato con funzioni

virtualizzate, o se semplicemente, nel

medio periodo, questa proposizione

non sia ancora sostenibile.

I vantaggi legati all’impiego di questa ar-

chitettura vanno tuttavia al di là del sem-

plice risparmio economico: come all’in-

terno dei Data Center la soluzione abilita

un livello di essibilità ad oggi impensato,

permettendo di accendere le funzionalità

a seconda delle esigenze nei punti di del-

la rete più opportuni, realizzare ridondan-

ze secondo schemi ad oggi impossibili,

rinnovare le piattaforme hardware senza

impatti sui servizi, …

Per poter avere questi vantaggi ci si

trova tuttavia ad affrontare una pro-

blematica analoga a quelle che sta

ad oggi diventando una criticità per i

Data Center: come realizzare in ma-niera semplice e scalabile la mobilità

delle Virtual Machine (su cui in questo

caso sono istanziate le funzionalità di

rete) sia all’interno di un dato sito tra

più macchine siche, sia in un contesto

Cloud tra siti diversi. Da qui il legame

tra SDN e Network Virtualization che

per altri aspetti potrebbero essere con-

siderati temi ortogonali: la separazione

del piano di controllo dal forwarding o

l’apertura di API verso lo strato applica-

tivo non sono necessari per realizzare

un’architettura in linea con gli obiettivi

della Network Virtualization; potrebbe-

ro tuttavia essere un elemento utile per

gestire la mobilità delle Virtual Machine

nello stesso modo come soluzioni ba-

sate su Openow sono ad oggi consi-

derate all’interno dei Data Center per

risolvere lo stesso problema ■

Per approfondimenti

http://www.blog.telecomfuturecentre.it/

(Confguration  & Management),di validazione (Testing & Inter-operability) e di denizione deiprincipi architetturali ( Architec-ture & Framework ). Inne, meri-ta di essere menzionata l’attività

sulla denizione della cosiddetta Northbound Interface, che ha l’o-biettivo di denire l’interfacciaesposta dallo strato di NetworkOS verso le applicazioni.

 Anche in IETF il tema SDN hastimolato il confronto sul coin-

 volgimento e sul possibile ruolodell’ente da sempre preposto alladenizione degli standard per ilmondo Internet nell’ambito diquesto nuovo lone, dando ori-

gine ad alcune prime iniziative alriguardo. È stata proposta la cre-azione di un gruppo di lavoro suSDN, ma la discussione che si èsviluppata non è per il momentoapprodata ad una decisione na-

le. Tenendo conto del mandatoprecipuo di IETF, il dibattito è sta-to per lo più centrato sull’eettivanecessità di denire nuovi proto-colli per rispondere ad esigenzespeciche in questo contesto. Ladiscussione ha arontato tra l’al-tro il tema dell’eventuale ruolo diprotocolli esistenti, derivanti daattività IETF pregresse, in relazio-ne al nuovo lone SDN. È questoil caso del WG NETCONF, che ha

prodotto soluzioni per sempli-care la congurazione degli ap-parati, oppure del già citato WGForCES [4], che ha specicato unprotocollo per separare piano dicontrollo e forwarding dei nodi

di rete. In questo quadro, sonoemerse anche nuove proposteper l’apertura della piattaforma direte, come nel caso dell’ IRS (In-ternet Routing System), che miraa consentire alle applicazioni diinteragire con il sistema di rou-ting della rete. Se la discussionein ambito IETF rimane comun-que ancora molto aperta su que-sti temi, nel contesto della IRTF(Internet Research Task Force),

41

8/19/2019 NT1-4-2013.pdf

13/14

42

altro ente sponsorizzato da IETFe Internet Society, il cui mandatoè di promuovere e condurre la ri-cerca su temi di riconosciuta im-portanza per l’evoluzione di Inter-net, è stato ucialmente creato direcente un gruppo di ricerca suSDN (SDNRG). Parallelamente aqueste iniziative, si sta registran-do un crescente interesse da partedi alcuni Operatori (ad es. Telefo-nica e Deutsche Telekom) per losviluppo (in open source) di unsistema operativo (kernel OS) dinodo SDN.

In denitiva, lo stato delle attivi-tà internazionali su un tema cosìattuale e di crescente rilievo comeil Software Dened Networking èin continua evoluzione ed è vero-simile che accanto alle iniziativegià in atto altre vedano la luce neimesi a venire.

Conclusioni

Il potenziale impatto del para-digma SDN sulle reti del futuropotrebbe essere duplice: mentreda una parte SDN potrebbe por-tare vantaggi economici per gliOperatori in termini di riduzionecosti, dall’altra potrebbe abilitarelo sviluppo di nuovi ecosistemidi servizi ICT, che costituirebbe-ro potenziali opportunità di svi-luppo per gli Operatori a patto in

cui questi riescano a ritagliarsi unruolo e inserirsi in un modello dibusiness vantaggioso.L’introduzione di diversi livel-li di astrazione di rete coniugatacon la virtualizzazione integratadelle risorse IT e di rete potrebbepermettere di estendere alla retei paradigmi attualmente utilizza-ti all’interno dei Data Center. Lesoluzioni SDN potrebbe permet-tere alle applicazioni di acquisire

una vista astratta della rete, comese fosse governata da un piano dicontrollo concettualmente cen-tralizzato: diventerebbe quindipossibile implementare logichedi controllo astraendo dalla com-plessità sica della molteplicità diapparati. Il cuore della SDN asso-miglia dunque ad un ecosistemadi moduli software di controllo,interagenti fra di loro e capaci diattuare più facilmente azioni dicongurazione e ottimizzazionedelle risorse di rete: d’altro can-to questa stessa centralizzazione

logica potrebbe avere dei punticritici, quali ad esempio livelli diprestazioni, adabilità, scalabili-tà e stabilità.L’interesse verso il paradigmaSDN è testimoniato dal crescentenumero di iniziative di carattereindustriale e da una serie di attivi-tà di sviluppo speciche, prototi-pazione e pre-standardizzazione,nonché dal sorgere di start-up diun certo rilievo. Se verrà dimo-

strata la fattibilità tecnologicadelle reti SDN, a valle di un pro-cesso di standardizzazione, le ri-cadute sull’evoluzione della retedegli Operatori potrebbero essereparticolarmente innovative ■

Bibliografa

[1] A. Manzalini, N. Crespi “ Mitigating

Systemic Risks in Future Networks” inIEEE CAMAD, Barcellona, Settembre

2012.

[2] S. Shenker, “The Future of Networ-

king, and the Past of Protocols”, Open

Networking Summit 2011.

[3] N. McKeown, “How SDN will Shape

 Networking”, Open Networking Sum-

mit 2011.

[4] IETF RFC 5860 “Forwarding and

Control Element Separation (ForCES)

Protocol Specifcation”.

[5] M. Casado, T. Koponen, S. Shenker,

 A. Tootoonchian, “Fabric: A Retro-

spective on Evolving SDN ”, Workshop

HotSDN, Agosto 2012.

[6] R. Sherwood, G. Gibb, K. Yap, G. Ap-

penzeller, N. McKeown, G. Parulkar,

“FlowVisor: A Network Virtualization

Layer ”, Technical Report, 2009.

[7] http://www.vmware.com/products/

datacenter-virtualization/vsphere/

overview.html 

[8] http://www.xen.org

8/19/2019 NT1-4-2013.pdf

14/14

N  U  O V E 

R E T I  

Mario

Ullio

ingegnereelettroniconel1990èentratoinAziendadovesièinizialmenteoccupatodiarchitettureeserviziperretimetropolitane.Dal1993al1995hacontribuitoallastandardizzazionediretieserviziATMehapartecipatoallarealizzazionedellaretepilotaATMitalianaepanEuropea.Dal1996haseguitolesperimentazionidisoluzionidiaccessoIPbasatesuADSLelesuccessivefasidideploymentdellareteedeiservizicommercialiperutenzaresidenzialeebusiness.Dal2003

al2005halavoratosusoluzioniperretimetroEthernetedhacontribuitoalprimodeploymentdiOPM.Dal2006èresponsabilediunprogettoincuièstudiatal’evoluzionetecnologicaearchitetturaledimedio/lungoterminedelleretiIP.

 Antonio

Manzalini

ingegnereelettronicoconcertifcazionePMI,èentratoinTelecomItalianel1990edhapartecipatoadiversiprogettidiricercariguardantiretiditrasportoSDHedottico(WDM),occupando

varieposizionidiresponsabilità.Hainoltrepartecipatoamolteattivitàdistandardizzazione,guidandoalcunigruppidilavoroinITU-T.Attualmentesioccupaditecnologie,sistemiedarchitetturediretiauto-adattativeecapacidiauto-gestione(qualiAutonomic/CognitiveNetworkingeSelf

OrganizingNetworks).Recentementelesueattivitàcomprendonol’analisiedefnizionediscenaririguardantiilparadigmaSoftwareDefnedNetwork.Èautoredialcunedecinedipubblicazioni,diunlibrosullasincronizzazionedelleretiditelecomunicazioniedicinquebrevettiinternazionali.

 Vinicio

 Vercellone

ingegnereelettronico,nel1984èentratoinAzienda.DaalloraoperanelsettoreinnovazionediTelecomItalia,dovehainizialmentelavoratonelcampodellosviluppodellatecnicaATMedellesueapplicazioni.Dal1997al2000haricopertoanchel'incaricodidocentepressoilPolitecnicodiTorino.HacontribuitoadattivitàeprogettidiricercanelsettoredelnetworkingIPedMPLSenell’offertadeirelativiservizidirete.Inquestiambitièautoredinumerosibrevettiinternazionaliepubblicazioni.

Attualmentesvolgelasuaattivitànell'areaDataNetworksInnovation,dovecontribuisceaprogettidiricercasusoluzionidinetworkinginnovativeperleretidati,ambitonelqualesicollocalasuapartecipazionealprogettoeuropeoFP7SAIL.Recentementelesueattivitàdiricercahannoabbracciatoancheilflone

emergentedelSoftwareDefnedNetworking.

43Usa il tuo

smartphone per 

visualizzare

approfondimenti

multimediali