sperimentazione di nuovi servizi nel test bed di rete ip multiaccesso ...

Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema 1
Fondazione Ugo Bordoni
Giuseppe Pierri, Giuseppe Del Prete, Elio Binnella
Istituto Superiore delle Comunicazioni e delle Tecnologie dell’Informazione
NOTE
SPERIMENTAZIONE DI NUOVI SERVIZI NEL TEST BED DI
RETE IP MULTIACCESSO MULTISERVIZIO DELL’ISCOM
(NOVEL SERVICE EXPERIMENTS IN THE IP MULTIACCESS
MULTISERVICE ISCOM TEST BED)
Sommario: in questo articolo riportiamo alcune
sperimentazioni di servizi innovativi che sono
stati testati sul test bed di rete IP che è stato realizzato,
presso l’ISCOM, dall’Istituto Superiore e dalla
Fondazione Ugo Bordoni.Tale test bed rappresenta un
segmento di rete core-edge-access con diversi dispositivi
di accesso, ed è stato realizzato secondo le prospettive
delle next generation networks (NGN) e cioè
è in grado di trattare enormi capacità in modo altamente
dinamico. Su questo test bed abbiamo studiato
le modalità di trasmettere nuovi servizi che richiedono
una enorme banda e che richiedono particolari funzionamenti
da parte della rete; in particolare abbiamo
focalizzato la nostra attenzione sulla IPTV, specialmente
nella modalità ad alta definizione. Inoltre un
altro importante servizio che è stato studiato e sperimentato
è la realizzazione automatica di virtual private
network (VPN) on demand con tempi di attivazione
estremamente rapidi. Le VPN sono oggi un servizio
sempre più richiesto, ma che ancora richiede un
intervento umano da parte dell’operatore che richiede
tempi di attivazione ancora molto lunghi (giorni). Uno
quindi degli obiettivi delle reti automatiche di prossima
generazione è la modalità da parte degli utenti di
poter creare VPN in maniera automatica, in cui quindi
la funzionalità dell’operatore è quella di mettere a disposizione
dei tool che facciano da interfaccia tra utenti
e macchine. In questo articolo proponiamo su questo
tema una modalità che abbiamo sperimentato con
successo e con tempi di attivazione di qualche secondo.
I risultati che qui sperimentiamo fanno riferimento
principalmente ad un accesso con tecnica ADSL2+, che
è quella attualmente maggiormente in uso. In questo
modo cerchiamo di verificare la possibilità di utilizzare
il più possibile le infrastrutture esistenti.Tuttavia sono
in corso studi su tecniche di accesso innovative del tipo
fiber to the curb/building/home ed in particolare sulla
tecnica Wavelength Division Multiplexing Passive
Optical Networks (WDM PON). Inoltre ai fini di migliorare
le prestazioni dei servizi IPTV si stanno testando
tecniche multicast con architettura basata sul Virtual
Private LAN Service (VPLS).
Abstract: in this paper we report some experiments
about novel services that we have
demonstrated in the IP network test bed that was
implemented in ISCOM by ISCOM and Fondazione
Ugo Bordoni. Such a test bed represents a segment of
a core-edge-access network with different access devices
and its implementation satisfies the main next
generation networks (NGN) requirements, that means
that is able to deliver wide capacities in a fast dynamic
way. Over such a test bed we studied several ways to
transmit novel services requiring huge bandwidth and
intelligent treatment by the network; in particular we
focused our attention about IPTV, especially in the High
Definition mode. Furthermore we also investigate
about the automatic implementation of virtual private
networks (VPN) on demand experimenting very fast
time for their set-up. In fact it has to be pointed out
that VPN is a service with demand that is increasing
more and more, but that it still requires a human operator
management with a consequent long set-up time
(days).Therefore one of the main objective of the future
VPN will be the user mode for VPN set-up, with an
operator role consisting in some tool interfaces between
user and machine. In this paper we propose and
we demonstrate an automaitic VPN procedure that we
experimented with a set-up time of about some
second.
The results reported in this paper mainly regards
an access with ADSL2+ systems, that is currently the
most considered in Italy.This way we try to stress the
twisted pair network in order to show the bottleneck of
this architecture. However we are also studying novel
access architectures based on optical fibres as Fiber to
the curb/building/home and in particular several tests
are running about the Wavelength Division
Multiplexing Passive Optical Networks ( WDM PON).
Furthermore in order to improve the IPTV services we
are also testing a multicast approach based on Virtual
Private LAN Service (VPLS).
1 - Ora con CORITEL, via Anagnina Roma
La Comunicazione - numero unico 2007 7

NOTE
Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema, Giuseppe Pierri
1. Introduzione
Reti di nuova generazione (o Next Generation
Networks) è un termine molto ampio per indicare
l’insieme delle reti di TLC che sono previste per i
prossimi 5-10 anni e che prevedono alcune evoluzioni
chiave come la convergenza dei servizi (triple
e quadruple play) e il trasporto su pacchetti IP (All
IP). In pratica la rete fissa, quella mobile e quella
broadcast tenderanno ad un processo di integrazione
sempre più ampio fino alla completa convergenza
sotto il paradigma IP.
Il 2006 ci ha mostrato che l’era delle Next
Generation Networks (NGN) è molto vicina, ma
non immediata e questo perché innanzitutto sarebbero
necessari degli ingenti investimenti per portare
essenzialmente la fibra ottica in prossimità dell’utenza.
FUB e ISCOM hanno molto investito nel campo
della ricerca sulle NGN ed hanno realizzato un
test bed di rete IP multiaccesso multiservizio che
rappresenta un segmento di rete core-edge-access
operante su rete regionale (i router sono connessi
con fibre lunghe 50 km).
Su questo test bed, su cui sono implementati i
protocolli BGP, OSPF, MPLS e DiffServ, sono state
già testate tecniche di ripristino GBE a livello ottico
con tempi di ripristino inferiori ai 50 ms e sono
state valutate le prestazioni di servizi IPTV con tecnica
DiffServ over MPLS [1].
2. il test bed di rete ip multiaccesso multservizio
La FUB e l’ISCOM hanno ulteriormente ampliato
il test bed di rete multiservizio multiaccesso IP,
che era stato mostrato su questa rivista lo scorso
anno, e che è ormai dimensionato per operare in
un ambito regionale, permettendo di garantire la
qualità del servizio per servizi real time multimediali,
anche ad alta definizione, mediante varie tecniche
di etichettatura dei pacchetti (DiffServ,
MPLS, GMPLS). Sono state introdotte delle metodologie
per la misura della qualità del servizio, sia
con prove oggettive (che misurano parametri fisici
come il ritardo dei pacchetti, la perdita dei dati e il
throughput della rete) che con prove soggettive e
cioè basate sulle valutazioni percettive (in questo
caso si parla spesso di Quality of Experience,
QoE).
La rete sperimentale che è stata realizzata, si
inserisce perfettamente nel contesto delle reti
Fig. 1: Schema attuale del test bed di rete IP multiaccesso multiservizio presso l’ISCOM
8 La Comunicazione - numero unico 2007

SPERIMENTAZIONE DI NUOVI SERVIZI NEL TEST BED DI RETE IP MULTIACCESSO MULTISERVIZIO DELL’ISCOM
(NOVEL SERVICE EXPERIMENTS IN THE IP MULTIACCESS MULTISERVICE ISCOM TEST BED)
NOTE
che hanno portato i risultati più interessanti ed in
particolare la diffusione dei servizi HDTV nella
rete in rame e le reti VPN on demand.
3. Fattibilita’ di servizi tv ad alta definizione
in una rete ottica multivendor
Fig. 2 – Schema del test bed. I router (Cisco e Juniper) sono connessi in fibra ottica con interfacce GbE, mentre i PC e l’ISAM è connesso
ai router con connessioni UTP FE. L’ISAM al modem tramite doppino telefonico.
nazionali moderne: infatti l’impiego del protocollo
MPLS ripropone tutti i vantaggi di ATM su una rete
IP, consentendo un approccio Connection
Oriented su di un mondo che per sua natura è
Connectionless. D’altro canto è necessario la tutela
di stringenti caratteristiche per opportune tipologie
di traffico, ed è qui che si fa strada l’approccio
DiffServ che è stato implementato nella rete e
che risulta essere il più utilizzato anche dagli operatori
di IPTV.
Con le prove soggettive si è introdotto un
modo diverso di concepire la progettazione di una
rete. Nasce la necessità di centrare la progettazione
di una rete non solo sulle sue prestazioni ma
anche sulla soddisfazione dell’utente finale.
La rete realizzata è attualmente costituita dalla
architettura riportata in figura 1 con 7 router (4
Juniper M10 e 3 CISCO 3845) 2 connessi con le
fibre contenute nel Poligono Sperimentale Ottico
Roma-Pomezia (25 km).
I router, che rappresentano i nodi della rete,
sono connessi a dispositivi per l’accesso con interfacce
10/100 MbE come dislam xDSL e access
point WI-FI.
I router gestiscono i seguenti protocolli: RSVP,
OSPFv3, MPLS–GMPLS, LDP, LMP, BGP, Ipv6. La
gestione della Qualità del Servizio è effettuata
mediante meccanismi di CoS (Class of Service)
basati sul DiffServ Aware Traffic Engineering.
Nel seguito riportiamo le attività sperimentali
2 - A gennaio 2007 è stato aggiunto un altro router, questa volta
ALCATEL.
Oggi una banda disponibile di circa 20 Mbps
all’utente finale in ADSL2+ pone le basi per lo sviluppo
dell’erogazione di contenuti televisivi in alta
definizione (HDTV) su protocollo IP, servizio che
ad oggi è prerogativa solo di alcune emittenti satellitari.
Un segnale televisivo digitalizzato in alta
definizione richiede almeno 15 Mbps. Questo
richiede importanti requisiti alla rete sia in termini
di accesso che di core. L’eterogeneità dei contenuti
unita all’alta variabilità d’intensità del traffico
potrebbero comportare notevoli problemi soprattutto
a quei servizi real time come fonia e TV dove
la perdita di pacchetti IP comporta inevitabilmente
perdita di contenuto. Notevole importanza avrà
quindi l’implementazione di tecniche per garantire
la Qualità del Servizio (QoS, Quality of Service)
che serviranno proprio a definire la giusta priorità
d’instradamento ai pacchetti IP.
Per quesi studi la rete di fig.1 è stata confifurata
come mostrato in fig. 2, completando la sezione
di accesso mediante un ISAM Alcatel 7324 per la
connessione dell’utente finale in ADSL2+ a 24
Mbit/s.
Le misure di rete (o oggettive) sono state effettuate
mediante il software ETHEREAL che per-
La Comunicazione - numero unico 2007
9

NOTE
Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema, Giuseppe Pierri
metteva di misurare parametri come throughput,
jitter e data lost. Per misurare invece la QoS in termini
percettivi (o soggettivi), ci si è basati sul giudizio
fornito da un gruppo di valutatori inseriti in una
camera silente a cui erano mostrati degli streaming
audio-video. Per maggiori informazioni si può andare
al sito www.iscom.gov.it. I valutatori erano in
possesso di un dispositivo con un cursore che
azionavano durante la visione di un filmato, dispositivo
che permette di esprimere il compiacimento
del valutatore fornendo una curva che poteva
variare da 0 (pessima immagine) a 100 (ottima
immagine). E’ evidente che nel caso di un filmato
percepito con una ottima qualità la curva emessa
dal dispositivo è una linea che nel tempo rimane
fissa ad un valore prossimo a quello massimo (100
nel nostro caso). Particolare rilevanza è stata data
alla correlazione tra misure oggettive e soggettive.
I primi test avevano riguardato l’utilizzo della
tecnica DiffServ over MPLS per garantire la QoS
nel caso di rete che veniva saturata con un generatore
di traffico. I risultati mostravano l’importanza
di una etichettatura di tipo Expedited
Forwarding come già mostrato nel sito
www.iscom.gov.it.
I risultati presentati in questo contributo si riferiscono
alle degradazioni che sono subite da filmati
in alta definizione quando la rete presenta 2 tipi
di degradazione: a) l’interruzione di un collegamento
(link failure), e b) la saturazione della banda nella
connessione di accesso. Come riferimento è stato
• MPEG2 1280x720p 16/9, 18,94 Mbit/s di
media, 60 fps, 65 MB per 45000 pks IP
• MPEG2 1920x1080i 16/9, 20 Mbit/s di
media, 29.97 fps, 80MB per 62000 pks IP
• Audio: In tutti i casi si è utilizzato l'MP2
192 Kbit/s e 48 kHz.
Vediamo i risultati delle indagini:
a) Link failure. Per i test sulla rete nel caso di
link failure si è inviato un flusso dati da un un punto
ad un altro della rete e successivamente si è
manualmente disattivato un link costringendo i
routers interessati ad un ricalcalo del percorso.
Mediante un software, Ethereal, si è potuto catturare
lato destinazione tutti i pacchetti IP entranti
ed in base al loro tempo di interarrivo si è potuto
valutare il tempo impiegato dalla rete per il ripristino
del collegamento. Lo stesso test è stato condotto
prima con il ripristino in OSPF e successivamente
in MPLS; i routers interessati sono stati i
Juniper M10. Nel caso OSPF il tempo medio sulle
quindici prove ripetute si è assestato sui 170 ms,
invece l’MPLS, mediante i meccanismi di link protection
e standby secondary path (MPLS LP+SSP),
ha registrato tempi medi di 50 ms. La tecnica OSPF
è risultata subito inadeguata a causa del lungo
tempo di ripristino richiesto e quindi l’analisi della
QoS è stata basata solo sulla tecnica MPLS LP+SSP.
Sono stati analizzati tutti e tre i flussi, 576p,
720p e 1080i: il numero di pacchetti persi in 50 ms
è crescente con la risoluzione ma la percentuale
sul totale dei pacchetti costituenti il flusso rimane
Fig. 3: Immagini da filmati video (SD, HD 720p e HD 1080i da sinistra a destra) durante un processo di ripristino MPLS LP+SSP. La
degradazione avveniva per un tempo brevissimo (meno di 1 secondo).
preso in considerazione l’unico documento che ad
oggi definisce degli standard minimi di QoE
(Qualità of Experience), il WT-126 del DSL Forum
[2].
I flussi video utilizzati nei test di durata pari a
28 secondi erano tutti codificati in MPEG2 sia
Video che Audio:
• MPEG2 720x576p 16/9, 9,29 Mbit/s di
media, 29.97 fps, 30 MB per 24500 pks IP
identica per i tre filmati comportando un livellamento
degli effetti nei tre casi considerati. Il danno
rimane comunque contenuto intaccando si il filmato
ma preservando l’intellegibilità dei contenuti.
b) Saturazione della banda nel collegamento di
accesso. In questa analisi si sono ricreate le condizioni
di saturazione del collegamento verso l’utente
finale. Si è avviato il download di dati da un web
server durante la ricezione di uno streaming video
10 La Comunicazione - numero unico 2007

SPERIMENTAZIONE DI NUOVI SERVIZI NEL TEST BED DI RETE IP MULTIACCESSO MULTISERVIZIO DELL’ISCOM
(NOVEL SERVICE EXPERIMENTS IN THE IP MULTIACCESS MULTISERVICE ISCOM TEST BED)
NOTE
in alta definizione di 18 Mbit/s di bitrate medio. Per
quel che riguarda la connessione in ADSL2+ si è
settato il collegamento alla massima banda disponibile
di 24 Mbit/s. I flussi ricevuti erano quindi di
due tipi, UDP nel caso video e TCP per i dati.
Non appena si è dato il via al download di dati
in TCP il flusso video ha subito una perdita di pacchetti
continuata nel tempo rendendo la fruizione
del filmato impossibile.
Si è cercata quindi una possibile soluzione che
permettesse di continuare a vedere il filmato
durante il download di dati: la più semplice soluzione
che è stato possibile implementare è stata
quella di etichettare i traffico video UDP come
Expedited Forwarding applicando quindi una
forma di QoS basata su DiffServ [3]. Per fare ciò si
è costruita una policy ad hoc sul router Cisco al
quale era direttamente connesso il PC che funzionava
da video server.Tramite il software Ethereal si
è potuto verificare il funzionamento della soluzione
trovata e i risultati sono riportati in fig. 4.
Come si può verificare all’applicazione della
policy il traffico dati si stabilizza ad un bitrate
medio più basso. Lo streaming HDTV è stato
mostrato ai valutatori che lo hanno valutato con il
dispositivo per la misura della qualità percepita [1].
I valori mediati sui 20 utenti sono stati riportati nel
grafico di figura 5, ciascuno in corrispondenza del
throughput misurato in fig. 4.
Figura 4 – Ethereal: Grafico dei pacchetti ricevuti con (secondo intervallo) e senza (prima intervallo) etichettatura dei pacchetti DiffServ
Figura 5: grafico a dispersione del throughput con e senza etichettatura dei pacchetti con tecnica DiffServ
La Comunicazione - numero unico 2007
11

NOTE
Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema, Giuseppe Pierri
4.Virtual private network automatizzate
in reti di trasporto multi-vendor. Lavoro realizzato
in collaborazione con la Scuola S.
Anna di Pisa.
Le Virtual Private Networks (VPN) sono servizi
di rete che stanno riscuotendo un sempre crescente
successo tra le aziende e gli operatori telefonici
grazie alle loro caratteristiche di sicurezza e
flessibilità. Attualmente la creazione di una VPN
richiede un attento esame da parte di un operatore
dello stato dei nodi di reti interessati dal servizio
ed una successiva configurazione degli stessi
con tempi, in genere, dell’ordine di giorni. Un tale
processo può essere estremamente velocizzato ed
automatizzato dall’introduzione di opportune
estensioni all’architettura ASON/GMPLS che permetterebbero
agli operatori di configurare automaticamente
e con tempi ridotti i nodi di rete in
ambiente multi-dominio e multi-vendor ed agli
utenti di effettuare richieste di VPN ai loro operatori.
La fornitura di servizi VPN
Una VPN (Virtual Private Network) è un servizio
di rete che permette di emulare su di una rete
condivisa, l’esclusività fisica propria di una rete
locale consentendo, al contempo, politiche di QoS
e sicurezza. I maggiori vantaggi di una VPN rispetto
ad una rete fisica dedicata risiedono nella dinamicità
di creazione e nel basso costo di realizzazione al
punto da essere ad oggi la soluzione preferita dalle
aziende per l’interconnessione delle loro LAN dislocate
in aree geografiche diverse. Le tipologie di
VPN maggiormente diffuse attualmente sono quelle
che coinvolgono tecnologie classificabili nello
strato 2 e 3 della pila OSI, sebbene si preveda in
futuro la diffusione di VPN che utilizzano tecnologie
di strato 1, con granularità pari alla lunghezza
d’onda in una fibra ottica, grazie in particolare ai
progressi ottenuti della tecnologia WDM.
Un esempio di tecnologia VPN di livello 3 basato
sul protocollo di trasporto IP è il “BGP/MPLS IP
Virtual Private Network (VPN)” o VPN L3. Questo
servizio di rete permette la creazione di una rete
privata virtuale in un ambiente multi-dominio in
maniera scalabile e sicura grazie all’utilizzo dell’architettura
di rete MPLS e del protocollo BGP.
L’MPLS è utilizzato come protocollo di “tunnelling”
per ottenere una connettività tra i nodi di bordo
della rete con percorso prestabilito e possibilità di
ingegnerizzare il traffico grazie alla creazione di
Label Switched Path (LSP).
Il protocollo BGP è utilizzato per la creazione e
lo scambio di tabelle di instradamento dei pacchetti
specifiche per la VPN allo scopo di permettere
la coordinazione tra i bordi della rete collegati
dagli LSP. In particolare, in una VPN L3 l’instradamento
dei pacchetti IP tra i bordi della rete è ottenuto
con l’utilizzo dello spazio di indirizzamento
tipico del protocollo di trasporto IP, mentre l’evoluzione
del protocollo BGP, denominata BGP V4,
permette di distinguere su di uno stesso nodo di
rete più VPN L3 in quanto crea uno spazio di indirizzamento
privato e distinto, rispetto all’IP e al
BGP standard.
Il maggior vantaggio dell’utilizzo delle VPN L3 è
che è facilmente realizzabile con dispositivi di rete
commerciali che supportano la suite MPLS. In particolare,
l’intelligenza delle VPN L3 risiede solo nei
router di bordo, detti Provider Edge (PE), perché
essi gestiscono l’instaurazione degli LSP e la coordinazione
tra le tabelle di routing BGP private
appartenenti a differenti VPN L3. I router interni
non sono a conoscenza delle configurazioni necessarie
all’instaurazione delle VPN, rendendo le VPN
L3 scalabili al crescere delle dimensioni della rete.
Il principale svantaggio dell’uso delle VPN L3
risiede nella complessità necessaria per la configurazione
e la gestione dei protocolli BGP e MPLS in
maniera coordinata tra i nodi di bordo.
Attualmente le VPN L3 sono gestite da un operatore
in maniera centralizzata, senza meccanismi
automatizzati. Inoltre il costante fiorire di specifiche
di protocolli non ancora standardizzati ufficialmente
ma già operativi sugli apparati di produttori
diversi pone delle serie questioni di interoperatività
quando le VPN L3 devono essere create in reti
multi–dominio.
L’architettura ASON/GMPLS [4] è stata dotato
di un piano funzionale denominato Service Plane
(SP) [5], capace di colloquiare con i nodi di bordo
del piano di controllo allo scopo di permettere
l’automatizzazione della gestione dei servizi di rete
(creazione, abbattimento, modificazione). Il SP è
costituito da una entità centralizzata chiamata
“Centralized Service Element” (CSE) e da più elementi,
chiamati “Distributed Service Element”
(DSE) associati a ciascun PE della rete. L’elemento
CSE è addetto al controllo dell’identità di chi chiede
un servizio, e alla gestione del database che
12 La Comunicazione - numero unico 2007

SPERIMENTAZIONE DI NUOVI SERVIZI NEL TEST BED DI RETE IP MULTIACCESSO MULTISERVIZIO DELL’ISCOM
(NOVEL SERVICE EXPERIMENTS IN THE IP MULTIACCESS MULTISERVICE ISCOM TEST BED)
NOTE
memorizza i contratti detti “Service Level
Agreement” (SLA) stipulati con i clienti della rete.
Il DSE è una entità distribuita in grado di accettare
richieste di servizi di rete da applicazioni tramite
l’interfaccia denominata User to Service
Interface (USI). Queste richieste sono trasformate
in maniera completamente automatizzata in una
serie di direttive al piano di controllo tramite la
“User to Network Interface” (UNI) e distribuite ai
PE coinvolti nel servizio stesso grazie ai protocolli
di segnalazione CSE-DSE e DSE-DSE. Importante
sottolineare che il SP non è un gestore distribuito
perché non gestisce direttamente le risorse di
rete. Il principale vantaggio del SP risiede nel fatto
che il suo utilizzo non comporta modifiche agli
apparati di rete e non si sostituisce all’uso della
UNI e del sistema di gestione ma estende le capacità
della rete di fornire servizi di rete complessi in
maniera automatizzata e distribuita riducendo l’intervento
umano a semplice supervisore delle attività
della rete.
Il valore aggiunto del SP nel caso di fornitura di
servizi VPN L3 risiede nella constatazione che i
parametri identificativi necessari per creare quel
servizio di rete sono molto diversi se visti dalla
prospettiva dell’ utente oppure dalla prospettiva di
rete. Infatti un utente richiede una VPN L3 in termini
di banda e di indirizzi IP degli “host” o delle
LAN private che devono essere interconnesse. In
particolare la banda richiesta viene tradotta dal SP
nella banda da richiedere alla rete tenendo conto
della granularità che la stessa è in grado di supportare
(ad esempio VC4 nel caso di reti SDH).
Inoltre gli indirizzi IP elencati dagli utenti vengono
risolti dal SP negli indirizzi dei PE che servono il
traffico degli host o le LAN dell’utente stesso.
Tuttavia questi parametri passati dagli utenti non
sono sufficienti, a livello di rete, per creare il servizio
poichè i router coinvolti nell’instaurazione
della VPN necessitano di direttive specifiche per
quanto riguarda la configurazione dei protocolli
espresse in maniera differente a seconda del linguaggio
utilizzato. Al fine di instaurare la VPN, è
necessario configurare per ogni nodo: il protocollo
BGP, utile allo scambio delle tabelle VRF (VPN
Routing and Forwarding Table), l’MPLS per la prenotazione
di banda tramite gli LSP, e soprattutto
una istanza privata di protocollo di instradamento
costruita ad hoc per la VPN. I parametri necessari
all’instaurazione della VPN L3 vengono ottenuti dal
SP in modo trasparente all’utente in funzione della
topologia della rete e delle risorse disponibili ed
infine tradotti in un insieme di direttive UNI ad
opportuni nodi di bordo del piano di controllo per
la creazione degli LSP e delle configurazione dei
protocolli di rete necessari alla creazione della
VPN.
Il testbed
Questo lavoro è stato fatto in collaborazione
con il Dott.Valerio Martini e il Prof. Piero Castoldi
della Scuola Superiore Sant’Anna di Pisa, e i Dott.
Fabio Baroncelli e Barbara Martini del CNIT di
Pisa.
Il testbed di fig. 1 è stato configurato come
riportato in fig. 6, realizzato per validare l’instaurazione
automatica di una VPN L3 da parte di un
prototipo di Service Plane, e valutare l’interoperabilità
tra apparati di rete di differenti produttori
(vendor).
Il testbed utilizza l’anello ottico sperimentale
Roma-Pomezia di 50 km di lunghezza complessiva
ed è formato da sette router di differenti vendor,
interconnessi in maniera completamente magliata
allo scopo di poter creare topologie virtuali differenti.
In particolare nella scelta delle topologie si è
tenuto conto delle diverse situazioni riscontrabili
in una rete multi-vendor, considerando che gli elementi
nevralgici, sui quali andranno caricate dinamicamente
le configurazioni, sono i PE. Il ruolo del
PE, ovvero del router di bordo, viene coperto
alternativamente da router dei diversi vendor in
modo da ottenere genericità sui test. I nodi interni
della rete non necessitano di configurazioni “ad
hoc” per le VPN L3, ovvero questi elementi sono
trasparenti alle configurazioni presenti ai bordi
della rete quindi senza perdita di generalità possiamo
ignorare la scelta del vendor nei nodi interni.
Come protocollo di comunicazione tra i router
della LAN che si interfacciano con la rete di trasporto,
detti Customer Edge (CE), ed i PE è stato
scelto l’OSPF in quanto questa è la soluzione più
diffusa tra le LAN di tipo aziendale.
E’ stato valutato il tempo di instaurazione e si è
verificata l’effettiva connettività della VPN L3 dopo
la richiesta (on-demand) da parte di una applicazione
al SP. Dal grafico di fig. 7 si può notare come
il tempo di instaurazione della VPN L3, comprensivo
del signaling effettuato dal SP, sia di circa 16
secondi dalla richiesta. Questo risultato è assai
rilevante specialmente se confrontato con i tempi
La Comunicazione - numero unico 2007
13

NOTE
Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema, Giuseppe Pierri
Figura 6. Il testbed
dell’ordine dei giorni che un operatore impiega
oggi per instaurare lo stesso servizio.
5. Conclusioni
Dalla indagine sulla QoS di servizi HDTV in una
rete IP possiamo affermare che i danni al video in
alta risoluzione dovuti a link failure e a congestione
della rete risultano trascurabili se rimangono
distanziati in tempo nel rispetto dei limiti suggeriti
nel documento WT-126 del DSL Forum. Risulta
invece indispensabile l’implementazione di una
forma di etichettatura dei pacchetti per garantire la
QoS per poter evitare possibili danni da congestione
del collegamento verso l’utente finale quando
la banda di accesso è limitata.
Per quanto riguarda invece le reti VPN on
demand sono state presentate le potenzialità offerte
dalle VPN L3 e abbiamo mostrato come una
Figura 7.Tempo di instaurazione VPN L3
14 La Comunicazione - numero unico 2007

SPERIMENTAZIONE DI NUOVI SERVIZI NEL TEST BED DI RETE IP MULTIACCESSO MULTISERVIZIO DELL’ISCOM
(NOVEL SERVICE EXPERIMENTS IN THE IP MULTIACCESS MULTISERVICE ISCOM TEST BED)
NOTE
estensione dell’architettura di rete ASON/GMPLS,
denominata Service Plane (SP), possa automatizzare
la fornitura di questo servizio. Stimiamo che
grazie all’utilizzo del SP, gli operatori di telefonia
potrebbero automatizzare la forniture di VPN L3
per tutte le applicazioni come il Vod (Video ondemand),
che richiedono connessioni a banda larga
e ritardo dei pacchetti contenuto e garantito, con
notevoli risparmi rispetto alla situazione odierna
dove le VPN sono manualmente configurate tramite
la gestione diretta della rete.
6. Ulteriori sviluppi
Dai risultati che sono stati mostrati ci si rende
conto che la rete in rame ormai mostra delle gravi
limitazioni per i futuri servizi.
Per un paio di anni questa avrà ancora la possibilità
di essere utilizzata per fornire a molti utenti
capacità idonee a servizi come la IPTV ad alta definizione
se nella rete verranno utilizzate tecniche di
indirizzamento in grado di garantire la QoS.
Ma via via che il numero di queste utenze
aumenterà la rete in rame, a causa delle grosse
interferenze che verranno a crearsi, risulterà sempre
meno affidabile.
E’ quindi ormai cosa risaputa che sarà indispensabile
sostituire, almeno parte della rete in rame
con reti in fibra ottica, arrivando con la fibra almeno
al secondo armadio di ripartizione.
La cosa preferibile è arrivare all’interno dell’edificio
dove si possono collocare con sicurezza i
terminali di conversione ottica-elettrica e poi arrivare
nelle case ancora con il doppino utilizzando
tecniche xDSL in grado di trasportare fino a 50-
100 Mb/s (VDSL2).
Questo è in pratica il piano di Telecom Italia
che proprio nel prossimo autunno dovrebbe iniziare
l’installazione di queste reti in fibra a cominciare
da Milano.
ISCOM e FUB da molti anni hanno studiato
tecniche di accesso in fibra ottica e negli ultimi
mesi hanno intensificato le loro ricerche su reti
PON.
In particolare uno degli interessi è per le PON
basate sulla trasmissione GBE sia in downstream
che in upstream, e proprio per la modalità
upstream sono state testate tecniche WDM basate
sulla multiplazione di canali GBE.
Questa tecnica permetterebbe adeguate capacità
nelle modalità peer-to-peer anche con streaming
ad alta definizione.
I risultati sulle reti PON sono presentati in
altro articolo di questo volume mentre i risultati
sulle WDM PON verranno presentati nella successiva
edizione di questa rivista.
Inoltre ai fini di ottenere una garanzie della
QoS stiamo facendo studi su metodi di etichettatura
basati più sul livello 2 che sul livello 3, e cercando
quindi di sfruttare le proprietà della tecnica
Ethernet.
In particolare gli studi in atto in questo periodo
riguardano in particolare la modalità Virtual
Private LAN service (VPLS) che permette la creazione
di LAN dedicate a servizi e che risulta particolarmente
interessante per la IPTV sia nella
modalità live (con tecnica multicast) che nella
modalità on-demand.
Anche le indagini su quest’ultima tecnica, che
sono in fase di conclusione, verranno riportate nel
numero successivo di questa rivista.
Ringraziamenti
Si ringrazia ALCATEL per il DSLAM ADSL2+ e
l’Ing.V. Baroncini per la consulenza sulla HDTV e il
Prof. V. Eramo (UNIROMA1) per i suggerimenti
nell’implementazione del test bed. Il lavoro sulle
VPN è stato fatto in collaborazione con il CNIT di
Pisa e la Scuola Superiore S. Anna di Pisa e quindi
si ringrazia il Dott.Valerio Martini e il Prof. Piero
Castoldi (Scuola Superiore Sant’Anna) e i Dott.
Fabio Baroncelli e Barbara Martini (CNIT).
La Comunicazione - numero unico 2007
15

NOTE
Francesco Matera, Luca Rea, Sergio Pompei, Cristiano Zema, Giuseppe Pierri
BIBLIOGRAFIA
[1] F. Matteotti, F. Matera,V. Barboncini, G.Tosi Beleffi, G. Del Prete, atti Fotonica 2005,Trani 29
maggio 2005.
[2] DSL Forum WT-126v0.5 – “Triple-play Service Quality of Experience Mechanism”
[3] K. Nichols, S. Blake “RFC 2474- Definitions of Differentiated Service Fields in IPv4 and IPv6
Headers” IETF,Tech. Rep.December 1998.
[4] Rec. G.8080/Y.1304,“Architecture for the automatically switched optical network (ASON)”.
ITU-T, June 2006
[5] B.Martini, F.Baroncelli, and P.Castoldi,“A novel service oriented framework for automatically
switched transport network,” in 9th IFIP-IEEE International Symposium on Integrated Network
Management (IM), Nice, France, 15-19 May 2005.
[6] Arora,A.; Subramaniam, S. "Wavelength Conversion Placement in WDM Mesh Optical
Networks". Photonic Network Communications,Volume 4, Number 2, May 2002.
[7] E. Rosen and Y. Rekhter,“RFC 4364 - BGP/MPLS IP Virtual Private Networks (VPNs),” IETF,
Tech. Rep., February 2006.
16 La Comunicazione - numero unico 2007