30

Usa il tuo
smartphone per
visualizzare
approfondimenti
multimediali

NUOVE RETI

SOFTWARE DEFINED NETWORKING:

SFIDE E OPPORTUNIT PER LE RETI DEL FUTURO
Antonio Manzalini, Vinicio Vercellone, Mario Ullio

31

PRIVACY
SPECIALE

globale e logicamente centralizzata, gestendo la topologia fisica

della rete e la distribuzione delle
informazioni di stato necessarie
ad implementare le logiche di
servizio. Il cuore della SDN assomiglia dunque ad un ecosistema
di moduli software di controllo,
interagenti fra di loro e capaci di
attuare pi facilmente azioni di
configurazione e ottimizzazione
delle risorse di rete. Daltra parte,
la stessa centralizzazione logica
del controllo potrebbe avere dei
punti critici, quali ad esempio livelli di prestazioni, affidabilit,
scalabilit e stabilit [1].
Lintroduzione di diversi livelli di astrazione di rete coniugata
con la virtualizzazione integrata
delle risorse IT e di rete potrebbe
permettere di estendere alle rete i
paradigmi e gli strumenti (opportunamente adeguati) oggi utilizzati allinterno dei Data Center:
ad esempio uno dei vantaggi pi

GOVERNANCE

Operatore Lean o Smart ? una

delle domande chiave. LOperatore Lean, in estrema sintesi, investe principalmente sul ruolo di Bit
Carrier nellottica di consolidare
il proprio business tradizionale,
quindi punta ad un forte contenimento dei costi ma anche ad
uno snellimento dei processi organizzativi; lOperatore Smart,
dovrebbe operare in maniera pi
disruptive, secondo una galassia
di imprese, che puntano allo sviluppo di nuovi ecosistemi e nuovi
modelli di business.
Linnovazione tecnologica legata
al potenziale sviluppo del paradigma SDN potrebbe impattare
entrambi i ruoli, ovviamente in
maniera pi o meno sensibile, in
funzione del livello e delle modalit di possibile adozione: infatti
mentre da una parte SDN potreb-

be portare vantaggi economici

per gli Operatori Lean, dallaltra
potrebbe abilitare lo sviluppo di
nuovi ecosistemi di servizi, che
costituirebbero potenziali opportunit di sviluppo per gli Operatori Smart, nella misura in cui questi riescano a ritagliarsi un ruolo
e inserirsi in un modello di business vantaggioso.
Una delle principali sfide tecnologiche del paradigma SDN riguarda la centralizzazione della logica
del controllo: questo abiliterebbe
le applicazioni ad acquisire una
vista astratta della rete, come se
questa fosse governata da un piano di controllo concettualmente
centralizzato (ed integrato con
il sistema di gestione). Diventa
quindi possibile implementare
logiche di controllo astraendo
dalla complessit fisica della molteplicit degli apparati di rete. Lo
strato di controllo ha il compito di presentare una vista unica,

SECURITY

Introduzione

NUOVE RETI

l paradigma SDN (Software Defined Networking), secondo laccezione pi diffusa, propone lambiziosa visione di rendere i nodi di rete (ad es. router e switch) programmabili, introducendo
opportuni livelli di astrazione, ai quali accedere attraverso luso di interfacce di controllo (API).
Nellambito di questo paradigma, assume particolare rilievo anche il concetto di virtualizzazione di rete, ovvero lidea di creare delle partizioni virtuali dellinfrastruttura di rete fisica, in modo
da permettere a pi istanze di controllo e le rispettive applicazioni di utilizzare le partizioni assegnate: questo permetterebbe coesistenza di pi reti virtuali, completamente isolate, che insistono sulla medesima infrastruttura hardware.
La centralizzazione logica del controllo, potrebbe permettere di attuare pi facilmente azioni di
configurazione e ottimizzazione delle risorse di rete. Ladozione di questo paradigma potrebbe
abilitare lo sviluppo di nuovi ecosistemi.

SPECIALE

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

32

concreti potrebbe essere introdurre nella rete dellOperatore di

un livello di flessibilit, ad oggi
impensato, abilitandone la programmabilit e permettendo di
allocare ed invocare funzionalit
virtualizzate di rete a seconda delle esigenze e nei punti pi opportuni; a questo si aggiungerebbe la
possibilit di realizzare ridondanze (ad es. over-provisioning della connettivit virtuale) secondo
schemi ad oggi impossibili, e la
capacit rinnovare le piattaforme
hardware con limitato (o addirittura senza) impatto sui servizi.
Inoltre, potrebbe diventare particolarmente significativo valutare
le potenziali opportunit offerte
dalla declinazione del paradigma
SDN alledge della rete (ad esempio, anche fino a casa dellUtente)
nellottica di sviluppare nuovi servizi ICT e nuovi modelli di business.
Infine utile rimarcare che il tema
SDN, a dispetto dellenfasi e delle
aspettative di cui oggetto in questo momento, sebbene suffragate
da indubbie potenzialit dellidea,
necessita ancora di progressi nel
processo di standardizzazione e
di raggiungere una piena maturit
e disponibilit tecnologica per potere essere seriamente considerato
per un dispiegamento in campo.
A questo proposito, quindi, anche
gli esempi di attivit internazionali sullargomento, riportati nel
Capitolo 2, stanno a testimoniare
soprattutto lo sforzo di elaborare
una vision e di verificarne le potenzialit attraverso attivit esplorative e proof of concept.

Il paradigma Software Defined

Networking

SDN sta diventando una keyword

imprescindibile per le architettu-

re di rete evoluta anche se ad oggi

manca di fatto una visione comune di quali siano gli obiettivi e gli
elementi che identificano questo
nuovo paradigma.
Secondo Scott Shenker [2] e Nick
McKeown [3] lobiettivo principale di SDN ristrutturare larchitettura di networking, introducendo
opportuni livelli di astrazione in
grado di operare una trasformazione simile a quanto gi avvenuto
nel campo delle architetture elaborative. Nellambito del computing infatti ormai da molto tempo
i programmatori sono in grado di
implementare sistemi complessi
senza dovere gestire le tecnicalit
dei singoli dispositivi coinvolti o
interagire in linguaggio macchina, il tutto proprio grazie allintroduzione di opportuni livelli di
astrazione nellarchitettura.
Questa visione, decisamente ambiziosa che propone un cambiamento radicale nelle reti, non
messa in discussione, ma spesso
da molti erroneamente identificata con aspetti specifici che
probabilmente hanno un impatto decisamente pi limitato. Ad
esempio alcuni identificano SDN
con il problema della separazione
del piano di controllo dagli apparati di rete e della sua centralizzazione, altri si focalizzano sullapertura di interfacce di controllo
sui router attuali: entrambe queste innovazioni sono solo componenti di una soluzione complessiva che permette linterazione
delle applicazioni con la rete in
modo sufficientemente semplice
da stimolare una vasta produzione di nuove applicazioni. Evidenza di questo fatto che soluzioni
tecniche per questi due problemi specifici esistono da anni (ad
esempio i lavori in IETF sul protocollo ForCES, che permette la separazione tra piano di controllo e

piano di forwarding, RFC gi dal

2010 [4]; Juniper mette a disposizione da anni API ed SDK sui propri router), ma non hanno trovato
sino ad oggi significativo impiego.
Laspetto su cui si stanno da anni
concentrando le attivit la definizione del protocollo OF (OpenFlow), sviluppato inizialmente a
livello accademico ed ora adottato
anche dalla ONF (Open Networking Foundation) come principale
ipotesi di lavoro e fondamento del
lavoro di standardizzazione.

2.1

Il protocollo OpenFlow

Il protocollo OpenFlow si ritiene

che rappresenti un fattore abilitante, anche se da solo ovviamente non sufficiente, per realizzare
la trasformazione verso i concetti
di rete flessibile e programmabile.
inoltre doveroso aggiungere che
la sua definizione non al momento consolidata, ma ancora
suscettibile di evoluzioni e perfezionamenti
Linterfaccia realizzata da OpenFlow si colloca al livello pi basso
di astrazione previsto dallarchitettura SDN, essa permette infatti di svincolarsi dallhardware
di forwarding dei pacchetti. In
questo senso, uno degli aspetti
fondamentali, che sta alla base
dellattivit di specifica avviata
da OpenFlow, consiste nella definizione di un modello standard
dellhardware di forwarding dei
pacchetti che costituisce il nucleo
dei diversi dispositivi di networking. Scopo del protocollo OpenFlow quindi, in questo senso,
quello di presentare allesterno
un modello di nodo generale e
unificato, rendendo gli strati pi
alti dellarchitettura di rete SDN
indipendenti
dallimplementa-

33

Feature
NorthBound API

Network OS

SDN Controller

HAL

(Hardware Abstraction Layer)

Firmware
CPU NPU ASIC ... CAM

Figura 1 - Rappresentazione dellarchitettura di rete SDN

Figura 2 - Schema di principio di un nodo OpenFlow

Scope of OpenFlow Switch Specification

OpenFlow Switch
sw

Secure Channel

hw

Flow Table

OpenFlow
Protocol
SSL

PC

Controller

SPECIALE

table e specificano le regole di

trattamento associate a ciascun
flusso di traffico. Lentit base
con cui viene rappresentato e
gestito il traffico in OpenFlow
per lappunto il flusso di pacchetti (flow); questultimo definito
da una regola di classificazione
ottenuta specificando il contenuto di opportuni campi dellintestazione tramite una entry della
flow table. Il protocollo OpenFlow permette quindi al piano
di controllo di definire in modo
flessibile e dinamico le regole di

GOVERNANCE

zione del particolare vendor delle

tecnologie impiegate nel piano di
forwarding.
Risalendo alle origini della proposta, lidea di base di OpenFlow
quella di rendere programmabili
in senso generale le tabelle di classificazione ed instradamento dei
pacchetti presenti negli apparati
di networking (siano essi router o
switch); in questo modo il contenuto (le cosiddette entry) pu essere configurato dalle applicazioni,
per il tramite di un piano di controllo esterno al dispositivo, mediante unopportuna interfaccia.
Questultima, costituita appunto
dal protocollo OpenFlow, permette di definirne in modo flessibile il
contenuto, in funzione della logica
di servizio da realizzare.
Le tabelle utilizzate per la classificazione del traffico a bordo
dei router sono generalmente in
grado di operare a velocit di linea e vengono sfruttate anche
per realizzare funzioni aggiuntive al forwarding di base, quali:
firewall, NAT, QoS, ecc. Nel modello del nodo OpenFlow, queste
tabelle vengono denominate flow

SECURITY

Packet Forwarding
(routing, switch, ecc.)

NUOVE RETI

OpenFlow

PRIVACY

Applicazioni

instradamento e trattamento dei

pacchetti appartenenti ai diversi
flussi di traffico.
Normalmente limplementazione
delle tabelle di classificazione dei
pacchetti, che presiedono alla definizione dei flussi e alla relative
regole di inoltro, una caratteristica proprietaria del particolare apparato di networking. Per superare
questo modello, OpenFlow mira
ad individuare e specificare ed a
rendere accessibili attraverso il
protocollo, un insieme di funzioni
supportate dalla maggior parte dei
router o switch commerciali. Lobiettivo principale consiste quindi
nel definire un modello astratto
dellelemento che esegue il forwarding dei pacchetti, rendendolo
programmabile attraverso un interfaccia aperta e standard.
Uno schema molto semplificato
dellarchitettura OpenFlow riportato nella Figura 2 seguente.
In particolare lo schema di principio fa riferimento alla versione
base dellarchitettura, come definita dalla specifica OpenFlow nella versione 1.0.
I principali elementi funzionali
del sistema, come si osserva dalla
figura, sono i seguenti:
1) una tabella (Flow Table) i cui
elementi (entry) definiscono i

SPECIALE

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

34

flussi e le azioni associate, determinando il trattamento da

applicare ai pacchetti appartenenti ai flussi stessi;
2) un canale sicuro (Secure Channel) tra il nodo ed un processo
di controllo remoto (controller), che consente lo scambio
di pacchetti e messaggi di comando;
3) il protocollo OpenFlow, come
interfaccia di comunicazione
standard ed aperta tra il nodo
ed il controller.
In linea di principio si pu distinguere un nodo nativo OpenFlow, in grado di svolgere tutte le
sue funzioni unicamente tramite
programmazione remota da parte di un controllore ed un nodo
tradizionale (es. router o switch
commerciale), che sia anche in
grado di ricevere ed interpretare comandi mediante OpenFlow.
Nel seguito, indicheremo questo
tipo di apparati con il termine
nodo OpenFlow ibrido, in uso in
ambito ONF, ente incaricato dello
sviluppo degli standard su SDN/
OpenFlow. I nodi ibridi rappresentano infatti lo scenario pi realistico, nellipotesi di unintroduzione in rete della tecnologia.
Gli elementi contenuti nella Flow
Table (le versioni pi recenti della
specifica prevedono la presenza di
pi tabelle in cascata) specificano
come devono essere gestiti i diversi flussi di pacchetti. Le azioni di
base, che il nodo deve OpenFlow
deve supportare sono:
1) inoltrare il pacchetto verso una
determinata porta di uscita,
2) incapsulare il pacchetto e spedirlo al controller attraverso
linterfaccia di comunicazione; tipicamente questa azione
viene applicata al primo pacchetto di un nuovo flusso, il
controller potr poi decidere
di configurare un nuovo entry

nella tabella per specificare il

trattamento dei pacchetti successivi; infine, nulla vieta, in
casi particolari, di inviare tutti
i pacchetti di un flusso verso il
controller per la loro elaborazione;
3) scartare i pacchetti appartenenti al flusso;
4) trattare i pacchetti secondo le
normali procedure di forwarding del nodo (nel caso di nodi
OpenFlow ibridi).

2.2

Gli sviluppi recenti

La definizione dellarchitettura
OpenFlow ha subito delle evoluzioni rispetto alla versione iniziale da quando stata fatto oggetto
di studio e specifica da parte di
ONF ed ha visto parallelamente
un sempre maggiore coinvolgimento da parte dellindustria. A
differenza della semplice schematizzazione discussa in precedenza
a titolo esemplificativo, il modello
di nodo OF attualmente definito
dalla versione pi recente della
specifica (Versione 1.3) prevede la
presenza di una sequenza di flow
table in cascata, al fine di consentire una maggiore flessibilit nel
trattamento dei pacchetti.
Infine bene notare che, se lintroduzione di un livello di interfacciamento aperto verso i dispositivi di forwarding rimane uno
dei capisaldi dellarchitettura
SDN, comincia ad emergere, in
seno alla comunit scientifica e
industriale che lavora alla definizione di OpenFlow, lidea che
lastrazione supportata dalle versioni di OpenFlow attualmente
in corso di specifica (versioni 1.x)
sia soggetta a limiti che possono
ostacolare la piena applicabilit
della tecnologia.

Il principale limite identificato, allinterno della stessa ONF,

per il modello corrente, consiste
nel fatto che la rappresentazione
semplificata su cui si basa attualmente OpenFlow non in grado
di veicolare agevolmente le informazioni sulla logica di forwarding
che lapplicazione intende implementare, rendendo difficile se
non talora impossibile fare leva
sulle funzionalit messe a disposizione dallhardware. Anche nel
modello corrente, la rappresentazione consiste in una sequenza
di tabelle e obbliga lapplicazione
a ragionare a basso livello, mancando in definitiva la possibilit
di esprimere in termini concisi
il comportamento (il cosiddetto
forwarding behavior) end-to-end
desiderato.
Questa la ragione principale per
cui in ambito ONF stato istituito di recente un nuovo gruppo
di lavoro incaricato della definizione del modello astratto del
piano di forwarding del nodo.
Sar poi compito di un opportuno HAL (Hardware Abstraction
Layer) presentare ai livelli superiori tale astrazione (Figura 1),
interpretando i comandi provenienti dal controllo. Naturalmente, la definizione del livello HAL
non rientra tra i compiti di ONF;
trattandosi di un aspetto specifico legato alle diverse implementazioni tecnologiche dei vendor,
spetta a questi ultimi sviluppare
tale strato di adattamento sul loro
hardware proprietario.
Parallelamente alliniziativa di
revisione di OpenFlow scaturita
da ONF, si segnalano altre critiche mosse al modello corrente da
parte di esponenti della comunit
scientifica. Ad esempio, secondo
un parere autorevole [5], il protocollo OF, cos com definito oggi,
sarebbe troppo complesso per un

35

GOVERNANCE
SPECIALE

Come si nota nella Figura 1, uno

degli elementi che compongono larchitettura SDN costituito
dallo strato di cui fanno parte i
controller.
Vale la pena ricordare che tradizionalmente nelle reti a pacchetto
le funzionalit del piano di controllo e quelle del piano dati sono
strettamente accoppiate; ossia
che sono gli stessi dispositivi che
effettuano il forwarding del traffico a decidere come trattare e dove
inoltrare i pacchetti.
Da questo punto di vista, il paradigma SDN/OpenFlow introduce
invece, come gi accennato, un
principio di disaccoppiamento tra
piano di controllo e di forwarding.
Lapproccio adottato prevede di
scorporare le funzionalit del
piano di controllo ed assegnarle
ad elementi dedicati. Ciascuno
dei controller, a sua volta, gestisce uno o pi nodi che effettuano
il forwarding dei pacchetti. Uno
degli aspetti salienti della visio-

SECURITY

Il livello dei controller come sistema

operativo di rete

quella di un controllore logicamente centralizzato, dal punto di

vista realizzativo sono possibili
diverse scelte progettuali. In linea
di principio, quella di un elemento di controllo fisicamente centralizzato un opzione possibile, e
forse adatta per ambiti molto circoscritti, quali una rete sperimentale o un campus universitario,
ma certamente non adeguata per
il dispiegamento in reti di produzione. La centralizzazione di un
elemento cos critico per il funzionamento della rete comporta
infatti evidenti limiti dal punto di
vista di: prestazioni, in particolare
tempi di risposta, a causa dei ritardi di propagazione dovuti alle
distanze geografiche, affidabilit, in termini di raggiungibilit e
disponibilit dellelemento e scalabilit. Questo significa che larchitettura del controllo dovr in
generale essere composta da elementi fisicamente replicati e distribuiti, ma capaci di comportarsi nel complesso come un piano di
controllo logicamente centralizzato. Naturalmente un certo grado di distribuzione dei controller
richiede la gestione delle usuali problematiche di consistenza
delle informazioni di stato tipiche dei sistemi distribuiti. I vari
controller dovranno poi essere in
grado di dialogare tra loro, attraverso opportune interfacce orizzontali, in particolare nel caso in
cui essi appartengano a domini di
rete differenti dal punto di vista
geografico e amministrativo.
Quindi, riassumendo, dal punto
di vista dellorganizzazione del
piano di controllo la vera novit
introdotta da SDN non sta nella sua centralizzazione, peraltro
logica, bens nella possibilit di
svincolarne la topologia da quella
dei nodi di rete che effettuano il
forwarding del traffico.

NUOVE RETI

2.3

ne SDN quindi la possibilit di

disegnare le applicazioni considerando la rete come se fosse governata da un piano di controllo
concettualmente
centralizzato,
invece che con un sistema complesso e distribuito. Le applicazioni possono quindi implementare
le loro logiche di controllo astraendo dalla complessit fisica della
rete, sar compito dei controller
presentare una vista unica, globale e logicamente centralizzata,
gestendo la topologia fisica della
rete e la distribuzione delle informazioni di stato necessarie ad implementare le logiche di servizio.
Lo strato di controllo dellarchitettura SDN sar generalmente
composto da un ecosistema di
moduli software, di cui il principale nucleo costituito dal controller. Sebbene non vi sia una
definizione completamente univoca e universalmente condivisa
di controller, un punto fermo
rappresentato dal fatto che esso
ha il compito di terminare linterfaccia OpenFlow (vedi Figura
1). Inoltre questo modulo offre
uninterfaccia di programmazione verso le applicazioni, siano
esse interne o esterne allo strato
di controllo stesso. quella che
in ambito ONF viene convenzionalmente indicata con il termine
di northbound API, mediante la
quale le applicazioni
possono fare uso delle funzionalit offerte dal controller. Questo
strato dellarchitettura SDN pu
essere visto pi in generale come
lanalogo di un sistema operativo
di rete (Network OS), come tale
deve offrire varie funzionalit di
supporto, quali fra laltro la gestione della comunicazione fra
moduli e laggiunta di nuove componenti.
Se lastrazione presentata dallarchitettura SDN alle applicazioni

PRIVACY

impiego nel core della rete, a scapito della sua scalabilit, ed invece
troppo semplificato per soddisfare i requisiti di maggiore ricchezza funzionale tipici delledge di
servizio. Da questa critica consegue la proposta di differenziare le
versioni del protocollo a seconda
dellambito di applicazione; suggerendo unimplementazione software della versione destinata a
controllare i nodi edge della rete,
per una maggiore flessibilit ed
evoluzione della tecnologia, mantenendo invece un profilo molto
semplice per il core della rete a
beneficio della scalabilit e del costo ma anche della compatibilit
in ambiente multi-vendor.

36

SPECIALE

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

2.4

La virtualizzazione di rete

Un ulteriore ingrediente che parte integrante della visione SDN relativamente allo strato di Network
OS rappresentato dalla virtualizzazione di rete (si veda anche il
riquadro di testo su questo argomento). Infatti, analogamente a
come, nel mondo del computing,
lintroduzione delle tecnologie
di virtualizzazione ha consentito
partizionare e condividere le risorse elaborative hardware, sotto
forma di macchine virtuali, tra pi
istanze di sistemi operativi, si pu
pensare di applicare dei principi
di virtualizzazione (slicing) anche
alle risorse di rete.
Lobiettivo della virtualizzazione di rete, nel contesto OpenFlow/SDN, consiste dunque nel
ricavare delle partizioni virtuali
dellinfrastruttura di rete fisica, in modo da permettere a pi
istanze di controllo e rispettive
applicazioni di utilizzare la slice
di rete assegnata, come se fosse
a tutti gli effetti dedicata e completamente isolata dalle altre reti
virtuali che insistono sulla medesima infrastruttura hardware.
Le tecniche di virtualizzazione
dovrebbero consentire ai diversi
soggetti che condividono linfrastruttura ed alle relative applicazioni di implementare protocolli
e schemi di indirizzamento totalmente indipendenti.
In questo senso, gi oggi nellambito dei data center e delle architetture di cloud computing, le tecnologie di virtualizzazione, come
ad esempio gli switch virtualizzati
(vSwitch) realizzati allinterno dei
moduli di gestione delle macchine virtuali, i cosiddetti hypervisor,
giocano un ruolo chiave nellevoluzione di queste soluzioni e
rappresentano una realt ormai

affermata dal punto vista commerciale.

Naturalmente diversi e pi articolati sono i requisiti ed i problemi
da affrontare per esportare le tecnologie di virtualizzazione anche
nellambito delle reti di telecomunicazione geografiche, tuttavia vi
sono segnali di una possibile evoluzione proprio in questa direzione.
Ad oggi, invece, le tecniche per
supportare dei principi di virtualizzazione in un ambiente generico di rete sono ancora in fase di
sviluppo e le implementazioni
disponibili sono limitate. Si tratta
sostanzialmente di strumenti destinati ad applicazioni in contesti
sperimentali e di ricerca, come il
software FlowVisor [6], sviluppato
nellambito del framework OpenFlow. Come le tecnologie di hypervisor si situano tra lhardware di
computing ed il sistema operativo,
infatti, il FlowVisor si colloca tra il
controller OpenFlow ed il piano di
forwarding, introducendo nellarchitettura un meccanismo di virtualizzazione (slicing) di rete.
Il FlowVisor si incarica di garantire che le diverse istanze di controllo siano in grado di vedere e gestire solo la slice a loro assegnata,
assicurandone lisolamento dalle
altre slice configurate in rete. Da
un punto di vista implementativo,
il FlowVisor si inserisce in modo
trasparente, in modalit proxy,
tra linterfaccia OpenFlow ed il
controller, intercettando ed elaborando i messaggi scambiati. Il
FlowVisor costituisce unimplementazione ancora embrionale
dei principi di virtualizzazione e
presenta alcune limitazioni, per
esempio le topologie virtuali possono essere costituite solo da sottoinsiemi della topologia fisica.
Tuttavia si pu sicuramente affermare che le tecnologie di virtualizzazione della rete costituiscono

in prospettiva una componente

qualificante dellarchitettura SDN
e potenzialmente in grado, quando mature, di abilitare nuovi ed
efficaci modelli di condivisione
delle infrastrutture di rete.

Alcuni scenari e possibili vantaggi per

lOperatore

Linteresse per il paradigma SDN

anche testimoniato dal crescente numero di iniziative internazionali di carattere industriale e
da una serie di attivit di sviluppo
specifiche, prototipazione e prestandardizzazione, nonch dal
sorgere di start-up.
In sintesi, se da un parte il paradigma SDN potrebbe permettere
di attuare pi facilmente azioni di
configurazione e ottimizzazione
delle risorse di rete e dallaltra parte, lintroduzione di diversi livelli
di astrazione di rete coniugata
con la virtualizzazione integrata
delle risorse IT e di rete potrebbe
permettere di estendere alle rete i
paradigmi attualmente utilizzati
allinterno dei Data Center.
La migrazione dellintelligenza
del piano di controllo dagli apparati ad un sistema logicamente
centralizzati potrebbe favorire lo
sviluppo di una nuova generazione di software router ad alte prestazioni (100 o pi Gbps) basati su
hardware standard. Il throughput
di un router fondamentalmente
limitato dal routing processing
(che detta il tradeoff tra numero
di porte e relative banda per connessione): il paradigma SDN potrebbe permettere il superamento
di questa limitazione, rendendo
possibile attuare in rete delle ridondanze (ad es. over-provisioning della connettivit virtuale)
secondo schemi ad oggi impossibili, o introducendo un alto livello

37

Could Service Center

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

Could Service Center

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

PRIVACY

DE intern
R2

R2

NUOVE RETI

DWDM
R1

R1

R1

DWDM
xDSL

L2 Agg
OLT

R1

L2 Switch

Mobile

L2 Agg

FTTx

Figura 3 TeraStream Architecture (Fonte DT)

Virtualizzazione, programmabilit e integrazione delle risorse

di rete e IT sono le caratteristiche
principali della visione di NTT per
il futuro della rete. Lastrazione

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

GOVERNANCE

ratore (attestati ai nodi R2) per la

centralizzazione di alcune logiche
di controllo di rete e per lottimizzazione di alcuni processi di gestione.

SECURITY

di flessibilit e programmazione
nellutilizzo delle risorse di rete.
Nel seguito di riportano alcuni
esempi di attivit internazionali
di ricerca e sviluppo.
Il progetto FP7 SPARC Split architecture carrier class networks,
finanziato dalla Comunit Europea e coordinato da Deutsche Telekom, ha portato allo sviluppo e
sperimentazione di nodi di rete
basati sul disaccoppiamento dei
piani di controllo e forwarding.
I prototipi di nodo sviluppati
nel progetto SPARC si basano su
piattaforme hardware fornite da
Cavium, Broadcom ed Emerson.
Inoltre, in linea con questi sviluppi, Deutsche Telekom sta sperimentando lutilizzo di soluzioni
alla OpenFlow/SDN nellambito
dello sviluppo della rete greenfield TeraStream dispiegata in
Croazia (figura 3). Larchitettura punta a sfruttare la potenza di
calcolo dei Data Centre dellOpe-

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

SPECIALE

Virtual networks (slices)

IT resources

Physical network

NW resources

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

38

virtuale delle risorse permetterebbe lesercizio di una molteplicit di reti logiche (overlay) coesistenti ma separate sulla stessa
infrastruttura fisica.
La programmabilit ai diversi livelli di rete (con interfacce standard) aumenterebbe ulteriormente la flessibilit nella fornitura di
servizi (Figura 4).
In figura 5 illustrato un esempio
di scenario di utilizzo di SDN per
linterconnessione di data centre
in corso di sviluppo in Telefonica
I+D.
Le applicazioni (attraverso lSDN
Orchestrator) potrebbero riservare le risorse IT e di rete in maniera
integrata, secondo i requisiti richiesti e per il tempo necessario
ad eseguire determinati task, o
per attuare migrazioni tra diversi

Application

SDN Orchestrator
Automatic provision based on
standard interfaces

Provisioning,
Discovery,
Monitoring

Openflow
Data
Center
A

Openflow
Data
Center
B

Elastic Core Network

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

server. il modello del sistema

operativo di rete.
Un modello molto simile il
Dynamic Enterprise Cloud di Ve-

rizon (figura 6), dove nuovamente

ricorrono i temi della virtualizzazione, programmabilit e integrazione delle risorse di rete e IT.

Figura 6 Dynamic Enterprise Cloud (Fonte Verizon)

1. Customer requests Cloud

Computing (CC) service instance

CC Servise
Controller
(ANC)

Customer Data Centers,

Sensors, etc.

Access Transport
Network

Virtual Machines
Storage
Processing

TNC

PE

CE

2. CC service checks resource

status, commands resource
changes as needed
5. CC servicereleases all
resources, updates status

4. Customer releases
CC service instance

SPECIALE

Coordination of the IT and

network resources to optimally
used the overall resources

NorthBound
Interface

TNC

CE

Apps

PE

PE

Virtual Machines

3. Customer executes Cloud

Computing (CC) application

PE
TNC

PE

Backbone
Transport Network

CE

Storage
Processing

PE
CE

Access Transport
Network

Apps

ANC - Application Network Controller

TNC - Transport Network Controller

39

Posizionamento dei Vendor

SECURITY
GOVERNANCE

NUOVE RETI

sostanza, la filosofia che in questo

momento alcuni vendor propongono consiste in un approccio che
potremmo definire ibrido. Il controllo rimane fondamentalmente a bordo dei nodi e distribuito,
ma le piattaforme si aprono per
veicolare informazioni e accettare
anche comandi di configurazione,
relativamente ad alcuni aree funzionali, da elementi (controller)
esterni.
In questo senso, per esempio,
molti si stanno orientando ad
esportare verso le applicazioni
informazioni sulla topologia e lo
stato dei nodi, anche se ci contrasta con la filosofia SDN, che
prevede invece di creare livelli di
astrazione progressivi, in modo da
rendere trasparente la complessit sottostante allo strato applicativo. In ogni caso, lintroduzione
di principi di apertura rappresenta una novit per le strategie dei
vendor incombenti.

PRIVACY

Attivit internazionali

La notevole trazione che il tema

SDN sta esercitando sullindustria
ha fatto s che siano state avviate
diverse iniziative per cercare di
definire delle soluzioni condivise e dei protocolli interoperabili.
Prima fra tutte lONF. Si tratta
di una iniziativa relativamente recente, costituitasi nel marzo dello
scorso anno sotto forma di consorzio industriale non-profit.
La missione principale di ONF
di promuovere un nuovo approccio al networking ispirato ai principi dellapproccio SDN. In questa
prospettiva, il consorzio ONF si
assunto come compito principale
quello di presiedere allo sviluppo
degli standard fondamentali al riguardo, tra i quali, in primo luogo,

SPECIALE

Larchitettura SDN ha mostrato la

capacit di valicare i confini della ricerca accademica, allinterno della quale ha avuto origine il
protocollo OpenFlow, e di affermarsi concretamente nellambito
dellindustria come paradigma
emergente di architettura di rete.
Come ogni soluzione potenzialmente in grado di portare trasformazioni anche significative
nel comparto industriale di riferimento, il paradigma SDN ha
prodotto reazioni diversificate da
parte dei soggetti del settore, ed
in particolare dei vendor. Intendiamo riferirci qui in primo luogo
ai vendor presenti nel segmento
di mercato delle piattaforme di
rete per i service provider, senza
peraltro trascurare ci che avviene
in settori adiacenti, le soluzioni di
networking per le reti enterprise e i data center. Per cominciare
dalle realt pi pronte a muoversi
nel mercato che le nuove opportunit tecnologiche sono in grado
di creare, partiamo dal caso delle
numerose startup che sono nate
per esplorare questo filone.
Fra tutte, possiamo citare Nicira
e BigSwitch, entrambe fondate da
esponenti di primo piano delluniversit di Stanford che, lo ricordiamo, stata lincubatore delle
attivit su SDN/OpenFlow. Entrambe hanno orientato i loro sviluppi verso uno sbocco commerciale nel segmento delle soluzioni
di networking per il cloud computing ed i data center. In questo
ambito, OpenFlow viene impiegato come elemento nellambito
di tecnologie di virtualizzazione
di rete. In particolare, Nicira, che
ha sviluppato la piattaforma NVP
(Network Virtualization Platform)
basata sulla tecnologia Open

vSwitch, stata recentemente acquisita da VMware, leader nelle

tecnologie di virtualizzazione. Altro gruppo di vendor rappresentato da costruttori come HP, IBM
e Brocade, che dispongono di linee di prodotto basate su apparati
di networking destinati in primo
luogo al segmento delle reti enterprise/campus e dei data center.
Questi vendor hanno gi annunciato la disponibilit commerciale
di prodotti in grado di supportare
il protocollo OpenFlow; essi sono
inoltre tra gli esponenti pi attivi
in questo momento allinterno dei
gruppi di lavoro di ONF.
Anche i tradizionali fornitori di
tecnologie per le reti dei service
provider stanno seguendo con attenzione questo filone ed elaborando le strategie per incorporare
elementi della soluzione SDN nei
propri prodotti. Si segnalano ad
esempio vendor come NEC che
proprio facendo leva sul tema
SDN/OpenFlow stanno cercando di riposizionarsi sul mercato
nel settore del networking. NEC
uno dei vendor particolarmente coinvolti nelle attivit in ONF
ed ha annunciato una soluzione,
larchitettura denominata ProgrammableFlow, che introduce
principi di programmabilit e di
virtualizzazione nei dispositivi di
rete. Anche altri costruttori affermati di apparati di networking,
come ad esempio Cisco e Juniper,
hanno inserito il tema SDN allinterno delle loro strategie evolutive
di prodotto.
Generalmente viene prevista lapertura di interfacce che consentono in qualche misura la programmabilit dei nodi di rete; di
solito linterazione con la piattaforma avviene a livello pi alto
rispetto a quanto prevede il protocollo OpenFlow, e talvolta sono
presenti aspetti proprietari. In

SPECIALE

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

40

Network Virtualization
Ormai da anni una delle tecnologie dominanti nei Data Center quella di virtualizzazione: Hypervisor commerciali
(e.g. VMware vSphere [7]) o Open
Source (e.g. XEN [8]) permettono di
utilizzare un server fisico per realizzare istanze di server virtuali gestiti da
organizzazioni differenti e che utilizzino eventualmente sistemi operativi
diversi.
Le tecnologie di virtualizzazione possono essere potenzialmente impiegate nel dominio di rete con due diversi
obiettivi:
utilizzo di una stessa infrastruttura
fisica per realizzare pi reti virtuali,
appartenenti a soggetti diversi;
utilizzo di una stessa piattaforma hardware per realizzare pi funzionalit
di rete.
Il primo obiettivo in realt gi indirizzato da anni attraverso limpiego della
tecnologia MPLS per realizzare reti private virtuali (Virtual Private Network) di
livello 2 o livello 3, che utilizzano piani
di indirizzamento eventualmente so-

la specifica del protocollo OpenFlow. ONF governata da un board costituito da rappresentanti

di Deutsche Telekom, Facebook,
Google, Microsoft, NTT, Verizon
e Yahoo. Anche Telecom Italia
recentemente entrata a fare parte del consorzio ONF, che annovera ormai oltre 70 membri, tra
cui diverse altre aziende di rilievo
come: Cisco, HP, Juniper, IBM,
Ericsson, VMware, NEC, Orange
e Comcast.
Lattivit di specifica di ONF
organizzata in gruppo di lavoro.
Laspetto centrale del lavoro di definizione degli standard rappresentato attualmente da OpenFlow,

vrapposti; attraverso le soluzioni Carrier Supporting Carrier anche possibile condividere una stessa infrastruttura
tra pi operatori. I vincoli delle soluzioni
attuali sono da una parte limpossibilit di applicare alle diverse partizioni di
rete soluzioni completamente disgiunte (tutte le reti virtuali condividono la
tecnologia IP/MPLS), dallaltra alcune
limitazioni quali la granularit con cui
possibile associare il traffico ad una
data rete virtuale (tipicamente una porta logica e non un singolo flusso) o la
limitata dinamicit.
Il secondo obiettivo si inserisce nel dibattito su un dilemma tecnologico con
cui da anni devono confrontarsi i costruttori di apparati delle reti dati: realizzazione delle funzioni in hardware o in
software. Negli ultimi 10-15 anni si osservato una progressivo spostamento di
funzionalit negli apparati (forwarding,
accodamento differenziato, filtraggio del
traffico, ) da una realizzazione in software ad una realizzazione in hardware.
Questo ha permesso la realizzazione di

sia in termini di modello dellhardware di rete che di protocollo. A

questo riguardo sono al momento
attivi principalmente due gruppi
di lavoro: il WG Extensibility ed
il WG Forwarding Abstractions,
di recente costituzione. Il primo
ha il compito di evolvere la specifica attuale, individuando ed
introducendo estensioni volte ad
incrementarne la flessibilit e la
ricchezza funzionale. Mentre il
secondo si propone di ripensare
il modello astratto del nodo con
un duplice obiettivo; da un lato,
renderne pi agevole limplementazione sullhardware piuttosto
eterogeneo, per caratteristiche

apparati con prestazioni via via crescenti in grado di contrastare la crescita del
traffico mantenendo i costi contenuti. Il
perdurare di questa tendenza tuttavia
oggi non cos scontato:
lo sviluppo di ASIC in grado di supportare sempre nuove funzionalit a
velocit pi elevata sempre pi complesso e costoso e richiede tempi molto lunghi (centinaia di risorse coinvolte,
tempi nellordine di 18-24 mesi);
le nuove funzionalit introdotte allinterno delle reti sono sempre pi complesse;
lingegnerizzazione di nuovi servizi
in tempi relativamente brevi richiederebbe unelevata flessibilit delle
macchine;
lo sviluppo tecnologico di server e
schede di rete non specializzati pu
contare su un mercato molto pi ampio.
Sulla base di questi fattori viene quindi
proposto un ritorno al passato con lutilizzo di hardware non specializzato per
realizzare funzionalit di rete: in par-

ed architettura, dei dispositivi di

rete; dallaltro, permettere alle applicazioni di controllo di esprimere in modo pi conciso ed efficace
il cosiddetto forwarding behavior
desiderato, senza dover ragionare
in termini di compilazione di un
numero imprecisato di singole
flow table. Accanto ai due gruppi di lavoro citati ve ne sono poi
altri i cui compiti riguardano per
esempio la definizione del modello dei nodi ibridi (WG Hybrid),
affrontando le problematiche di
consistenza nella gestione delle
risorse derivanti dalla presenza
di piani di controllo distinti, oppure gli aspetti di configurazione

41

SECURITY
GOVERNANCE

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

prodotto soluzioni per semplificare la configurazione degli apparati, oppure del gi citato WG
ForCES [4], che ha specificato un
protocollo per separare piano di
controllo e forwarding dei nodi
di rete. In questo quadro, sono
emerse anche nuove proposte
per lapertura della piattaforma di
rete, come nel caso dell IRS (Internet Routing System), che mira
a consentire alle applicazioni di
interagire con il sistema di routing della rete. Se la discussione
in ambito IETF rimane comunque ancora molto aperta su questi temi, nel contesto della IRTF
(Internet Research Task Force),

SPECIALE

gine ad alcune prime iniziative al

riguardo. stata proposta la creazione di un gruppo di lavoro su
SDN, ma la discussione che si
sviluppata non per il momento
approdata ad una decisione finale. Tenendo conto del mandato
precipuo di IETF, il dibattito stato per lo pi centrato sulleffettiva
necessit di definire nuovi protocolli per rispondere ad esigenze
specifiche in questo contesto. La
discussione ha affrontato tra laltro il tema delleventuale ruolo di
protocolli esistenti, derivanti da
attivit IETF pregresse, in relazione al nuovo filone SDN. questo
il caso del WG NETCONF, che ha

caso sono istanziate le funzionalit di

rete) sia allinterno di un dato sito tra
pi macchine fisiche, sia in un contesto
Cloud tra siti diversi. Da qui il legame
tra SDN e Network Virtualization che
per altri aspetti potrebbero essere considerati temi ortogonali: la separazione
del piano di controllo dal forwarding o
lapertura di API verso lo strato applicativo non sono necessari per realizzare
unarchitettura in linea con gli obiettivi
della Network Virtualization; potrebbero tuttavia essere un elemento utile per
gestire la mobilit delle Virtual Machine
nello stesso modo come soluzioni basate su Openflow sono ad oggi considerate allinterno dei Data Center per
risolvere lo stesso problema

NUOVE RETI

(Configuration & Management),

di validazione (Testing & Interoperability) e di definizione dei
principi architetturali (Architecture & Framework). Infine, merita di essere menzionata lattivit
sulla definizione della cosiddetta
Northbound Interface, che ha lobiettivo di definire linterfaccia
esposta dallo strato di Network
OS verso le applicazioni.
Anche in IETF il tema SDN ha
stimolato il confronto sul coinvolgimento e sul possibile ruolo
dellente da sempre preposto alla
definizione degli standard per il
mondo Internet nellambito di
questo nuovo filone, dando ori-

general purpose e della maggiore concorrenza sulle componenti software, o

se sia pi conveniente un approccio
meno innovativo che cerchi di coniugare hardware specializzato con funzioni
virtualizzate, o se semplicemente, nel
medio periodo, questa proposizione
non sia ancora sostenibile.
I vantaggi legati allimpiego di questa architettura vanno tuttavia al di l del semplice risparmio economico: come allinterno dei Data Center la soluzione abilita
un livello di flessibilit ad oggi impensato,
permettendo di accendere le funzionalit
a seconda delle esigenze nei punti di della rete pi opportuni, realizzare ridondanze 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 problematica analoga a quelle che sta
ad oggi diventando una criticit per i
Data Center: come realizzare in maniera semplice e scalabile la mobilit
delle Virtual Machine (su cui in questo

PRIVACY

ticolare ad esempio le funzionalit ad

oggi fornite da appliance (NAT, Firewalling, Deep Packet Inspection), quelle
fornite dagli apparati di Core Network
Mobile (GGSN, EPC, MME) o quelle
fornite dagli apparati di edge della rete
fissa (BRAS, PE). In questo contesto
le funzionalit diventano istanze SW
associate a macchine virtuali che condividono una infrastruttura di server fisici distribuiti sulla rete o concentrati in
Data Center di rete.
Un interrogativo rispetto a questa proposizione sicuramente quello delle
prestazioni: scontato che limpiego
di hardware non specializzato non permetta di ottenere le stesse prestazioni
attuali per realizzare alcune funzionalit, quindi le risorse computazionali
necessarie saranno quantitativamente
maggiori; linterrogativo diventa quindi
se il costo complessivo di una architettura di rete basata sul paradigma Network Virtualization sia interessante rispetto alle soluzioni attuali come effetto
delle economie di scala sul hardware

SPECIALE

GOVERNANCE

SECURITY

NUOVE RETI

PRIVACY

42

altro ente sponsorizzato da IETF

e Internet Society, il cui mandato
di promuovere e condurre la ricerca su temi di riconosciuta importanza per levoluzione di Internet, stato ufficialmente creato di
recente un gruppo di ricerca su
SDN (SDNRG). Parallelamente a
queste iniziative, si sta registrando un crescente interesse da parte
di alcuni Operatori (ad es. Telefonica e Deutsche Telekom) per lo
sviluppo (in open source) di un
sistema operativo (kernel OS) di
nodo SDN.
In definitiva, lo stato delle attivit internazionali su un tema cos
attuale e di crescente rilievo come
il Software Defined Networking
in continua evoluzione ed verosimile che accanto alle iniziative
gi in atto altre vedano la luce nei
mesi a venire.

Conclusioni
Il potenziale impatto del paradigma SDN sulle reti del futuro
potrebbe essere duplice: mentre
da una parte SDN potrebbe portare vantaggi economici per gli
Operatori in termini di riduzione
costi, dallaltra potrebbe abilitare
lo sviluppo di nuovi ecosistemi
di servizi ICT, che costituirebbero potenziali opportunit di sviluppo per gli Operatori a patto in
cui questi riescano a ritagliarsi un
ruolo e inserirsi in un modello di
business vantaggioso.
Lintroduzione di diversi livelli di astrazione di rete coniugata
con la virtualizzazione integrata
delle risorse IT e di rete potrebbe
permettere di estendere alla rete
i paradigmi attualmente utilizzati allinterno dei Data Center. Le
soluzioni SDN potrebbe permettere alle applicazioni di acquisire

una vista astratta della rete, come

se fosse governata da un piano di
controllo concettualmente centralizzato: diventerebbe quindi
possibile implementare logiche
di controllo astraendo dalla complessit fisica della molteplicit di
apparati. Il cuore della SDN assomiglia dunque ad un ecosistema
di moduli software di controllo,
interagenti fra di loro e capaci di
attuare pi facilmente azioni di
configurazione e ottimizzazione
delle risorse di rete: daltro canto questa stessa centralizzazione
logica potrebbe avere dei punti
critici, quali ad esempio livelli di
prestazioni, affidabilit, scalabilit e stabilit.
Linteresse verso il paradigma
SDN testimoniato dal crescente
numero di iniziative di carattere
industriale e da una serie di attivit di sviluppo specifiche, prototipazione e pre-standardizzazione,
nonch dal sorgere di start-up di
un certo rilievo. Se verr dimostrata la fattibilit tecnologica
delle reti SDN, a valle di un processo di standardizzazione, le ricadute sullevoluzione della rete
degli Operatori potrebbero essere
particolarmente innovative

Bibliografia

[1] A. Manzalini, N. Crespi Mitigating

Systemic Risks in Future Networks in
IEEE CAMAD, Barcellona, Settembre
2012.
[2] S. Shenker, The Future of Networking, and the Past of Protocols, Open
Networking Summit 2011.
[3] N. McKeown, How SDN will Shape
Networking, Open Networking Summit 2011.
[4] IETF RFC 5860 Forwarding and
Control Element Separation (ForCES)
Protocol Specification.

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

A. Tootoonchian, Fabric: A Retrospective on Evolving SDN, Workshop
HotSDN, Agosto 2012.
[6] R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, 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

Usa il tuo
smartphone per
visualizzare
approfondimenti
multimediali

43

Antonio
Manzalini

ingegnere elettronico,
nel 1984 entrato in
Azienda. Da allora opera
nel settore innovazione
di Telecom Italia, dove
ha inizialmente lavorato
nel campo dello sviluppo
della tecnica ATM e
delle sue applicazioni.
Dal 1997 al 2000
ha ricoperto anche
l'incarico di docente
presso il Politecnico di
Torino. Ha contribuito
ad attivit e progetti
di ricerca nel settore
del networking IP ed
MPLS e nellofferta
dei relativi servizi di
rete. In questi ambiti
autore di numerosi
brevetti internazionali
e pubblicazioni.
Attualmente svolge la
sua attivit nell'area
Data Networks
Innovation, dove
contribuisce a progetti
di ricerca su soluzioni di
networking innovative
per le reti dati, ambito
nel quale si colloca la
sua partecipazione al
progetto europeo FP7
SAIL. Recentemente
le sue attivit di ricerca
hanno abbracciato
anche il filone
emergente del Software
Defined Networking.

Mario
Ullio

ingegnere elettronico
nel 1990 entrato
in Azienda dove si
inizialmente occupato
di architetture e servizi
per reti metropolitane.
Dal 1993 al 1995
ha contribuito alla
standardizzazione
di reti e servizi ATM
e ha partecipato alla
realizzazione della
rete pilota ATM italiana
e pan Europea. Dal
1996 ha seguito le
sperimentazioni di
soluzioni di accesso
IP basate su ADSL e
le successive fasi di
deployment della rete e
dei servizi commerciali
per utenza residenziale
e business. Dal 2003
al 2005 ha lavorato
su soluzioni per reti
metro Ethernet ed ha
contribuito al primo
deployment di OPM. Dal
2006 responsabile
di un progetto in cui
studiata levoluzione
tecnologica e
architetturale di medio/
lungo termine delle
reti IP.

NUOVE RETI

ingegnere elettronico
con certificazione PMI,
entrato in Telecom
Italia nel 1990 ed ha
partecipato a diversi
progetti di ricerca
riguardanti reti di
trasporto SDH ed ottico
(WDM), occupando
varie posizioni di
responsabilit. Ha
inoltre partecipato
a molte attivit di
standardizzazione,
guidando alcuni gruppi
di lavoro in ITU-T.
Attualmente si occupa
di tecnologie, sistemi
ed architetture di reti
auto-adattative e capaci
di auto-gestione (quali
Autonomic/Cognitive
Networking e Self
Organizing Networks).
Recentemente le sue
attivit comprendono
lanalisi e definizione
di scenari riguardanti
il paradigma Software
Defined Network.
autore di alcune
decine di pubblicazioni,
di un libro sulla
sincronizzazione delle
reti di telecomunicazioni
e di cinque brevetti
internazionali.

Vinicio
Vercellone