09.03.2014 Views

Test bed per la valutazione della Qualità del Servizio in reti ottiche ...

Test bed per la valutazione della Qualità del Servizio in reti ottiche ...

Test bed per la valutazione della Qualità del Servizio in reti ottiche ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Test</strong> <strong>bed</strong> <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> <strong>del</strong><strong>la</strong><br />

Qualità <strong>del</strong> <strong>Servizio</strong> <strong>in</strong> <strong>reti</strong> <strong>ottiche</strong><br />

<strong>in</strong>tegrate IP<br />

Francesco Matera, Vittorio Baronc<strong>in</strong>i, Luca Rea, Alessandro<br />

Tarant<strong>in</strong>o, Paolo Pasquali, Francesca Matteotti<br />

Fondazione Ugo Bordoni<br />

Giancarlo Gaud<strong>in</strong>o, Domenico Ciavatta, Giuseppe Del Prete<br />

ISCOM


SOMMARIO ...................................................................................................................................6<br />

INTRODUZIONE...........................................................................................................................8<br />

CAPITOLO 1 ................................................................................................................................12<br />

STATO ATTUALE DELLE RETI E PROSPETTIVE DI EVOLUZIONE FUTURE ..........12<br />

1.1 ARCHITETTURA DELLA RETE FISSA...................................................................12<br />

1.1.1 Infrastrutture di Trasmissione.................................................................................13<br />

1.1.2 La rete di accesso....................................................................................................14<br />

Accesso commutato su dopp<strong>in</strong>o telefonico ............................................................................14<br />

Accesso su dopp<strong>in</strong>o: <strong>la</strong> tecnologia xDSL...............................................................................14<br />

Accesso dedicato <strong>in</strong> fibra ottica.............................................................................................15<br />

1.1.3 La rete di giunzione.................................................................................................16<br />

1.1.4 La rete dorsale ........................................................................................................17<br />

1.1.5 Numerizzazione <strong>del</strong>le centrali di Commutazione nel<strong>la</strong> rete pubblica .....................18<br />

1.2 TECNOLOGIE DI COMMUTAZIONE......................................................................19<br />

1.2.1 I Sistemi SDH ..........................................................................................................19<br />

1.2.2 La tecnologia ATM..................................................................................................20<br />

1.2.3 La tecnologia IP ......................................................................................................20<br />

1.3 LE RETI NAZIONALI E PROSSIMI SVILUPPI........................................................21<br />

1.3.1 Le <strong>reti</strong> di raccolta e le <strong>reti</strong> dorsali...........................................................................21<br />

Collegamento tra nodi ...........................................................................................................22<br />

Piano di Controllo.................................................................................................................22<br />

Trattamento <strong>del</strong> traffico da parte dei nodi.............................................................................23<br />

1.4 SVILUPPO DEL CONTROL-PLANE ED EVOLUZIONE DELLE RETI DI<br />

TELECOMUNICAZIONI IN AREA METRO E CORE............................................................23<br />

1.4.1 Nuovi servizi e vantaggi economici dall’adozione di <strong>reti</strong> ASON/GMPLS...............26<br />

1.5 CONCLUSIONI...........................................................................................................31<br />

CAPITOLO 2 ................................................................................................................................33<br />

EVOLUZIONE DELLO STANDARD ETHERNET NELLE RETI MAN.............................33<br />

2.1 INTRODUZIONE........................................................................................................33<br />

2.2 LO STANDARD ETHERNET ....................................................................................33<br />

2.3 IL MECCANISMO DI ACCESSO CSMA/CD............................................................37<br />

2.4 IL DOMINIO DI COLLISIONE ..................................................................................40<br />

2.5 DALLE LAN ALLE MAN: SWITCHING ETHERNET .............................................42<br />

2.6 SERVIZI DI CONNETTIVITA’ ETHERNET PUNTO-PUNTO......................45<br />

2.7 LA GIGABIT ETHERNET..........................................................................................46<br />

2.8 LA STANDARDIZZAZIONE DEI SERVIZI ETHERNET ........................................46<br />

2.9 SDH/SONET, OTH ED ETHERNET NELLE RETI DI TRASPORTO:VISIONE<br />

DEGLI STANDARD INTERNAZIONALI E PROSPETTIVE PER IL FUTURO....................48<br />

2.9.1 Un mo<strong>del</strong>lo semplificato <strong>per</strong> una rete di trasporto .................................................48<br />

2.9.2 Descrizione funzionale <strong>del</strong> mo<strong>del</strong>lo.........................................................................50<br />

2.9.3 SDH ED OTH..........................................................................................................52<br />

2.9.4 ETHERNET: STANDARD FUTURI........................................................................53<br />

2.9.5 ETHERNET SU MPLS (MPLS ED OAM)...............................................................53<br />

2.9.6 ETHERNET PROVIDER BRIDGE..........................................................................54<br />

2.9.7 ETHERNET PROVIDER BACKBONE BRIDGE ...................................................55<br />

2.9.8 ETHERNET OAM ...................................................................................................55<br />

2.9.9 CONSIDRAZIONI FINALI......................................................................................56<br />

CAPITOLO 3 ................................................................................................................................59<br />

QUALITA’ DEL SERVIZIO: CARATTERIZZAZIONE ED IMPLEMENTAZIONE........59<br />

3.1 QUALITA’ DEL SERVIZIO .......................................................................................59<br />

2


3.1.1 SLA: Service Level Agreement ................................................................................62<br />

3.2 LA GESTIONE DELLA QUALITA’ DEL SERVIZIO ...............................................63<br />

3.2.1 IntServ: Integrated Service......................................................................................64<br />

3.2.2 Il Protocollo RSVP ..................................................................................................66<br />

3.2.3 Il protocollo RTP.....................................................................................................71<br />

3.2.4 DiffServ (Differentiated Services) ...........................................................................75<br />

3.2.5 Il campo DSCP........................................................................................................77<br />

3.2.6 PHB: Per-Hop Behaviour .......................................................................................78<br />

3.3 SCHEDULING E ALGORITMI..................................................................................79<br />

3.3.1 WRR: Weighted Round Rob<strong>in</strong> .................................................................................80<br />

3.3.2 Priority queu<strong>in</strong>g ......................................................................................................81<br />

3.3.3 Controllo <strong>del</strong><strong>la</strong> Congestione....................................................................................81<br />

3.3.4 Coesistenza IntServ , DiffServ .................................................................................85<br />

3.4 DIFFSERV OVER MPLS............................................................................................86<br />

3.4.1 L’architettura MPLS ...............................................................................................87<br />

3.4.2 MPLS e <strong>in</strong>gegneria <strong>del</strong> traffico ...............................................................................89<br />

3.4.3 Implementazione <strong>del</strong><strong>la</strong> QoS DiffServ su MPLS .......................................................91<br />

3.5 ARCHITETTURA GMPLS.........................................................................................94<br />

CAPITOLO 4 ................................................................................................................................97<br />

STRUTTURA ED ELEMENTI DEL..........................................................................................97<br />

TEST- BED....................................................................................................................................97<br />

4.1 TEST-BED MPLS PER LE MISURE OGGETTIVE DELLA QUALITA’ DEL<br />

SERVIZIO..................................................................................................................................98<br />

4.1.1 Struttura <strong>del</strong> test-<strong>bed</strong>...............................................................................................98<br />

4.1.2 Presentazione <strong>del</strong> <strong>Test</strong>-<strong>bed</strong>....................................................................................100<br />

4.2 ELEMENTI DELLA RETE .......................................................................................103<br />

4.2.1 Router Juni<strong>per</strong> M10...............................................................................................103<br />

4.2.2 Architettura generale dei router............................................................................105<br />

4.2.3 Router Juni<strong>per</strong> M10: architettura .........................................................................106<br />

4.2.4 Software JUNOS ...................................................................................................109<br />

4.2.5 Generatore/analizzatore di traffico.......................................................................112<br />

4.2.6 Chariot: Server e Client ........................................................................................114<br />

4.2.7 U.S.Robotics Wireless AP US5450.......................................................................115<br />

4.2.8 Anrtitsu MN9610B.................................................................................................116<br />

4.3 PRINCIPIO DI FUNZIONAMENTO DEL SISTEMA..............................................116<br />

4.3.1 Switch Ottico .........................................................................................................122<br />

4.3.2 La Porta paralle<strong>la</strong>.................................................................................................123<br />

4.3.3 Amplificatore di corrente ......................................................................................126<br />

CAPITOLO 5 ..............................................................................................................................128<br />

CONFIGURAZIONE DELLA RETE E PROVE OGGETTIVE...........................................128<br />

5.1 TIPOLOGIE DI PROVE E NORMATIVE DI RIFERIMENTO................................128<br />

5.1.1 Settaggio <strong>del</strong>le schede di rete................................................................................130<br />

5.2 CONFIGURAZIONE DEI ROUTER ........................................................................133<br />

5.2.1 Misure <strong>per</strong> il dimensionamento <strong>del</strong>l’Expedited Forward<strong>in</strong>g.................................133<br />

5.2.2 Misure <strong>per</strong> il dimensionamento <strong>del</strong>l’Assured Forward<strong>in</strong>g....................................139<br />

5.2.3 Configurazione def<strong>in</strong>itiva. .....................................................................................149<br />

5.3 TEST SUI SERVIZI...................................................................................................150<br />

5.3.1 <strong>Test</strong> sui servizi di video conferenza. ......................................................................150<br />

5.3.2 <strong>Test</strong> su servizio VoIP (Voice over IP)....................................................................155<br />

5.3.3 <strong>Servizio</strong> di trasferimento dati ................................................................................157<br />

5.3.4 Servizi audio-video non real time..........................................................................159<br />

CAPITOLO 6 ..............................................................................................................................162<br />

PROVE SOGGETTIVE E QUALITA’ PERCEPITA DALL’UTENTE FINALE ...............162<br />

3


6.1 TEST-BED SPERIMENTALE PER LA VALUTAZIONE SOGGETTIVA DELLA<br />

QUALITA’ DEL SERVIZIO. ..................................................................................................162<br />

6.2 PROVE SOGGETTIVE.............................................................................................165<br />

6.2.1 Scelta <strong>del</strong>le immag<strong>in</strong>i televisive.............................................................................165<br />

6.2.2 Registrazione <strong>del</strong>le sequenze.................................................................................171<br />

6.2.3 Scelta <strong>del</strong> metodo di <strong>valutazione</strong> e preparazione <strong>del</strong><strong>la</strong> camera afonica ...............174<br />

6.3 LA SESSIONE DI TEST...........................................................................................175<br />

6.3.1 Preparazione <strong>del</strong>le sequenze .................................................................................175<br />

6.3.2 Fase di e<strong>la</strong>borazione dei dati. ...............................................................................178<br />

6.4 RISULTATI OTTENUTI...........................................................................................185<br />

6.4.1 Analisi globale <strong>del</strong>le sequenze via cavo. ...............................................................185<br />

6.5 ANALISI DELLE SEQUENZE “VIA CAVO”..........................................................190<br />

6.5.1 Automobilismo.......................................................................................................191<br />

6.5.2 Tennis ....................................................................................................................194<br />

6.5.3 Nuoto S<strong>in</strong>cronizzato ..............................................................................................196<br />

6.5.4 Ciclismo.................................................................................................................198<br />

6.5.5 Musica...................................................................................................................201<br />

6.6 ANALISI DELLE SEQUENZE WI-FI.......................................................................203<br />

CAPITOLO 7 ..............................................................................................................................207<br />

MISURE OGETTIVE DEL TEMPO DI RIPRISTINO..........................................................207<br />

7.1 INTRODUZIONE......................................................................................................207<br />

7.2 TEMPO DI INTERRUZIONE DEL COLLEGAMENTO .........................................207<br />

7.3 TEMPO DI REAZIONE DEL ROUTER AL GUASTO ............................................209<br />

7.4 TEST SUI SERVIZI...................................................................................................214<br />

7.5 TEST BED UTILIZZATO PER LE MISURE CON IL SOFTWARE CHARIOT .....215<br />

7.5.1 <strong>Test</strong> sui servizi simu<strong>la</strong>ti .........................................................................................219<br />

7.5.2 <strong>Test</strong> di riprist<strong>in</strong>o su servizi di video conferenza ....................................................219<br />

7.5.3 Commutazione volontaria <strong>del</strong> mezzo trasmissivo..................................................226<br />

7.5.4 <strong>Test</strong> di riprist<strong>in</strong>o su servizio VoIP (Voice over IP)................................................226<br />

7.5.5 <strong>Test</strong> di riprist<strong>in</strong>o su servizi audio-video non real time ..........................................230<br />

7.5.6 <strong>Test</strong> di riprist<strong>in</strong>o su servizio di trasferimento dati.................................................235<br />

7.6 RISPRISTINO DEL SERVIZIO MEDIANTE PROTOCOLLO OSPF...................236<br />

CAPITOLO 8 ..............................................................................................................................240<br />

PROVE SOGGETTIVE E QUALITA’ PERCEPITA DALL’UTENTE FINALE ...............240<br />

8.1 ELEMENTI NORMATIVI PER LA VALUTAZIONE SOGGETTIVA DELLA<br />

QUALITA’ DEL SERVIZIO ...................................................................................................240<br />

8.2 NORMATIVE ITU-T ED ITU-R ...............................................................................240<br />

8.2.1 Enti <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> <strong>del</strong>le QoS..........................................................................240<br />

8.2.2 QoS <strong>del</strong><strong>la</strong> rete........................................................................................................242<br />

8.2.3 QoS <strong>del</strong> contenuto e QoS <strong>per</strong>cepita dall’utente.....................................................244<br />

8.3 TEST BED SPERIMENTALE (CON BACK_UP) PER LA VALUTAZIONE<br />

SOGGETTIVA DELLA QUALITA’ DEL SERVIZIO............................................................252<br />

8.4 SVOLGIMENTO DELLE PROVE SOGGETTIVE ..................................................255<br />

8.4.1 Scelta <strong>del</strong>le immag<strong>in</strong>i televisive.............................................................................255<br />

8.4.2 Registrazione <strong>del</strong>le sequenze.................................................................................258<br />

8.4.3 Scelta <strong>del</strong> metodo di <strong>valutazione</strong> e preparazione <strong>del</strong><strong>la</strong> camera afonica ...............260<br />

8.5 LA SESSIONE DEI TEST .........................................................................................262<br />

8.5.1 Preparazione <strong>del</strong>le sequenze .................................................................................262<br />

8.5.2 Fase di e<strong>la</strong>borazione dei dati ................................................................................263<br />

8.6 RISULTATI OTTENUTI...........................................................................................267<br />

8.6.1 Analisi globale <strong>del</strong>le sequenze via cavo. ...............................................................267<br />

6.6 ANALISI DELLE SEQUENZE SINGOLE ...............................................................271<br />

6.5.1 Automobilismo ............................................................................................................271<br />

8.6.2 Tennis ....................................................................................................................275<br />

6.6.3 Musica...................................................................................................................280<br />

4


APPENDICE 1 ............................................................................................................................285<br />

TECNICHE DI PROTEZIONE ................................................................................................285<br />

1.1 INTRODUZIONE......................................................................................................285<br />

1.2 MECCANISMI DI PROTEZIONE............................................................................291<br />

1.2.1 Protezione l<strong>in</strong>eare 1+1..........................................................................................293<br />

1.2.2 Protezione l<strong>in</strong>eare 1:1...........................................................................................293<br />

1.2.3 La topologia ad anello ..........................................................................................295<br />

1.2.4 Unidirectional Path Switched R<strong>in</strong>g (UPSR)..........................................................296<br />

1.2.5 Bidirectional L<strong>in</strong>e Switched R<strong>in</strong>g (BLSR) .............................................................298<br />

1.3 TECNICHE DI PROTEZIONE PROPIETARIE BASATE SUL PROTOCOLLO<br />

MPLS 300<br />

1.3.1 L’architettura MPLS .............................................................................................300<br />

1.3.2 MPLS e <strong>in</strong>gegneria <strong>del</strong> traffico .............................................................................303<br />

1.3.3 Resilience <strong>in</strong> MPLS ...............................................................................................305<br />

1.3.4 Tecniche di riprist<strong>in</strong>o MPLS su JUNIPER M10....................................................306<br />

1.4 ALGORITMO DI ROUTING OSPF..........................................................................308<br />

1.4.1 Analisi <strong>del</strong> tempo di attivazione di adiacenza tra router.......................................319<br />

APPENDICE 2 ............................................................................................................................322<br />

IL SOFTWARE DI MANAGEMENT PER IL RIPRISTINO...............................................322<br />

2.1 LE SOCKET ..........................................................................................................323<br />

2.1.1 Dichiarazione........................................................................................................325<br />

2.1.2 Dichiarazione <strong>del</strong>le librerie utilizzate ...................................................................325<br />

2.1.3 Dichiarazione <strong>del</strong>le costanti def<strong>in</strong>ite.....................................................................326<br />

2.1.4 Dichiarazione <strong>del</strong>le funzioni utilizzate ..................................................................327<br />

2.1.5 Dichiarazione e semantica <strong>del</strong>le variabili utilizzate nel ma<strong>in</strong>...............................327<br />

2.1.6 Verifica <strong>del</strong><strong>la</strong> correttezza <strong>del</strong>l’<strong>in</strong>put......................................................................329<br />

2.1.7 Creazione <strong>del</strong><strong>la</strong> socket...........................................................................................329<br />

2.1.8 strutture dati <strong>del</strong>le socket ......................................................................................331<br />

2.1.9 Inizializzazione <strong>del</strong>le strutture d’<strong>in</strong>teresse ............................................................332<br />

2.1.10 Inizializzazione <strong>del</strong><strong>la</strong> struttura controllore.......................................................332<br />

2.1.11 Richiesta di una porta al SO.............................................................................332<br />

2.1.12 Sdoppiamento dei processi ...............................................................................333<br />

2.1.13 La funzione fork() .............................................................................................333<br />

2.1.14 Ricezione <strong>del</strong> messaggio <strong>in</strong>viato dal router......................................................335<br />

2.1.15 Processamento <strong>del</strong> pacchetto ricevuto .............................................................336<br />

2.1.16 Gestione dei segnali.........................................................................................337<br />

2.1.17 Cattura dei segnali e gestione <strong>del</strong><strong>la</strong> porta paralle<strong>la</strong> ........................................338<br />

2.1.18 La funzione close( )...........................................................................................340<br />

2.2 FUNZIONI DI UTILITA’..........................................................................................341<br />

2.3 CHARIOT: SESRVER E CLIENT ............................................................................341<br />

APPENDICE 3 ............................................................................................................................343<br />

ELEMENTI NORMATIVI PER LA VALUTAZIONE SOGGETTIVA DELLA QUALITA’<br />

DEL SERVIZIO..........................................................................................................................343<br />

3.1 NORMATIVE ITU-T E ITU-R ..........................................................................................343<br />

3.1.1 Enti <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> <strong>del</strong>le QoS .............................................................................343<br />

3.1.2 QoS <strong>del</strong><strong>la</strong> rete........................................................................................................344<br />

3.1.3 QoS <strong>del</strong> contenuto e QoS <strong>per</strong>cepita dall’utente.....................................................349<br />

3.2 NORMATIVA DI RIFERIMENTO PER I TEST ......................................................360<br />

3.2.1 Normativa ITU-R BT 500-11.................................................................................360<br />

5


SOMMARIO<br />

In questo rapporto riportiamo i risultati s<strong>per</strong>imentali che sono stati ottenuti sul test<br />

<strong>bed</strong> di rete che è stato realizzato presso i <strong>la</strong>boratori ISCOM nell’ambito <strong>del</strong><strong>la</strong><br />

col<strong>la</strong>borazione tra FUB e ISCOM nel progetto FUB “QoSIP”. Scopo di tale<br />

progetto sono lo studio e <strong>la</strong> s<strong>per</strong>imentazione di modalità <strong>per</strong> <strong>la</strong> diffusione di<br />

servizi multimediali <strong>in</strong>terattivi su <strong>reti</strong> IP con alta Qualità <strong>del</strong> <strong>Servizio</strong>, anche <strong>in</strong><br />

condizioni di alta congestione <strong>del</strong><strong>la</strong> rete, con partico<strong>la</strong>re <strong>in</strong>teresse verso <strong>la</strong> IP-TV.<br />

Per queste ragioni è stato costituito un test <strong>bed</strong> di rete ottica <strong>in</strong>tegrata<br />

multiservizio che rappresenta un esempio di rete regionale con diversi tipi di<br />

accesso. In partico<strong>la</strong>re essa è costituita da una parte “core” realizzata con core<br />

router ad alta capacità connessi con lunghi collegamenti <strong>in</strong> fibra ottica (multipli di<br />

25 km) che rappresenta una rete regionale, a cui sono collegati diversi dispositivi<br />

di accesso <strong>per</strong> valutare le prestazioni <strong>del</strong>l’utenza. In partico<strong>la</strong>re sono disponibili<br />

connessioni <strong>del</strong> tipo Fibre-to-the-Build<strong>in</strong>g (FTTB) e Fibre-to-the Curb (FTTC),<br />

WI-FI e VDSL. In questo rapporto faremo riferimento ai soli collegamenti FTTB,<br />

FTTC e WI-FI, mentre le prestazioni VDSL saranno riportate <strong>in</strong> un successivo<br />

rapporto.<br />

Per garantire <strong>la</strong> QoS abbiamo <strong>in</strong>trodotto nel<strong>la</strong> rete <strong>la</strong> metodologia denom<strong>in</strong>ata<br />

DiffServ-MPLS che <strong>per</strong>mette una partico<strong>la</strong>re etichettatura dei pacchetti che<br />

garantisce un trattamento differenziato <strong>del</strong><strong>la</strong> <strong>in</strong>formazione. In partico<strong>la</strong>re abbiamo<br />

utilizzato una mappatura <strong>in</strong>novativa proposta da noi e basata sull’etichettatura <strong>del</strong><br />

campo DSCP, che si è rive<strong>la</strong>ta partico<strong>la</strong>rmente efficace.<br />

Su tale rete sono state <strong>in</strong>oltre studiato, proposto e <strong>in</strong>trodotte anche tecniche di<br />

riprist<strong>in</strong>o molto <strong>in</strong>novative e che si sono rive<strong>la</strong>te molto efficienti e poco costose.<br />

Inoltre sono state studiate metodologie <strong>per</strong> l’<strong>in</strong>stradamento <strong>del</strong> traffico <strong>in</strong> presenza<br />

di nuovi dispositivi di commutazione ottici come OXC e convertitori di frequenza.<br />

6


Tale metologie <strong>per</strong>mettono di effettuare commutazioni di camm<strong>in</strong>i fisici <strong>in</strong> rete<br />

senza <strong>in</strong>trodurre alterare <strong>la</strong> qualità <strong>per</strong>cepita da parte degli utenti.<br />

Una svariata serie di misure oggettive (di rete) e soggettive (<strong>per</strong>cepite) su diversi<br />

tipi di servizi ci ha <strong>per</strong>messo di concludere che <strong>la</strong> tecniche da noi proposte <strong>per</strong> <strong>reti</strong><br />

IP <strong>per</strong>mettono <strong>la</strong> fruizione di tali servizi con alta QoS anche <strong>in</strong> condizioni di forte<br />

congestione <strong>del</strong><strong>la</strong> rete. In partico<strong>la</strong>re <strong>la</strong> tecnica denom<strong>in</strong>ata Expedited Forward<strong>in</strong>g<br />

<strong>del</strong> DiffServ-MPLS è quel<strong>la</strong> che <strong>per</strong>mette un’altissima <strong>per</strong>cezione di servizi IP-<br />

TV anche <strong>in</strong> condizioni di estrema congestione <strong>del</strong><strong>la</strong> rete nel caso <strong>del</strong>l’architettura<br />

FTTB e FTTC (ma si prevede che analoghe prestazioni saranno ottenute con<br />

accessi VDSL). Resta <strong>in</strong>vece da sottol<strong>in</strong>eare i limiti <strong>in</strong> term<strong>in</strong>i di QoS <strong>per</strong> <strong>la</strong><br />

tecnica WI-FI anche quando le condizioni di traffico <strong>del</strong><strong>la</strong> rete core garantirebbero<br />

alte prestazioni <strong>per</strong> l’accesso.<br />

7


INTRODUZIONE<br />

Il sensazionale sviluppo di Internet ha avuto un impatto forte sull’<strong>in</strong>dustria <strong>del</strong>le<br />

telecomunicazioni determ<strong>in</strong>ando progressivamente l’affermazione dei concetti e<br />

dei paradigmi connessi con <strong>la</strong> tecnologia Internet e <strong>in</strong> partico<strong>la</strong>re con il protocollo<br />

IP. La crescita <strong>del</strong>le applicazioni ha fatto sì che <strong>in</strong> molte direttrici di<br />

telecomunicazioni <strong>in</strong>ternazionali e <strong>in</strong> <strong>reti</strong> nazionali dei paesi più avanzati il<br />

volume <strong>del</strong> traffico dati su<strong>per</strong>asse quello re<strong>la</strong>tivo ai servizi di telecomunicazione<br />

tradizionali (fonia, fax, ecc).<br />

Tuttavia, nonostante il grande volume di traffico determ<strong>in</strong>ato da Internet, i<br />

marg<strong>in</strong>i di profitto connessi sono piuttosto modesti ed <strong>in</strong> ogni caso molto <strong>in</strong>feriori<br />

a quelli re<strong>la</strong>tivi ai servizi di fonia. A tale riguardo alcune studi dimostrano che <strong>in</strong><br />

una prospettiva di medio term<strong>in</strong>e il rapporto fra i volumi dei traffici IP e dei<br />

servizi tradizionali è stimato circa uguale a dieci, mentre il rapporto dei re<strong>la</strong>tivi<br />

<strong>in</strong>troiti è stimato circa uguale ad un decimo. La necessità di ripagare gli<br />

<strong>in</strong>vestimenti sulle <strong>reti</strong> IP, <strong>in</strong>sieme al<strong>la</strong> prospettiva di sviluppo di una rete <strong>in</strong>tegrata<br />

(capace cioè di trasportare tutti i tipi di servizi con un’unica piattaforma di rete),<br />

sp<strong>in</strong>ge gli o<strong>per</strong>atori di <strong>reti</strong> IP a fornire su queste <strong>reti</strong> anche i servizi di<br />

telecomunicazione tradizionali. Lo sviluppo di una rete <strong>in</strong>tegrata multiservizio è<br />

stato da sempre <strong>per</strong>seguito dai pr<strong>in</strong>cipali o<strong>per</strong>atori di rete, e ciò ha portato a<br />

sviluppi importanti <strong>del</strong>le <strong>reti</strong> come ad esempio l’ISDN e successivamente l’ATM.<br />

Oggi <strong>la</strong> prospettiva di una rete <strong>in</strong>tegrata multiservizio basata su tecnologia IP<br />

com<strong>in</strong>cia a conc<strong>reti</strong>zzarsi con <strong>reti</strong> di o<strong>per</strong>atori, sia emergenti che storici, <strong>in</strong> grado<br />

di offrire anche servizi fonici e video. L’<strong>in</strong>tegrazione dei servizi di fonia e dati<br />

assume attualmente una valenza anche più forte che nel passato, <strong>in</strong> quanto apre <strong>la</strong><br />

possibilità di sviluppo di nuovi servizi e di nuovi modi di comunicazione. Oltre ai<br />

servizi multimediali già considerati nel passato, come ad esempio <strong>la</strong><br />

videocomunicazione e <strong>la</strong> multivideoconferenza, è possibile fornire servizi come <strong>la</strong><br />

8


messaggistica unificata (unified messag<strong>in</strong>g con e-mail, fax e casel<strong>la</strong> vocale),<br />

conferenze multimediali, accessi contemporanei a pag<strong>in</strong>e WWW e a servizi<br />

<strong>in</strong>formativi, comput<strong>in</strong>g e progettazione col<strong>la</strong>borative, home work<strong>in</strong>g,<br />

teleshopp<strong>in</strong>g, giochi <strong>in</strong>terattivi, e cosi via.<br />

La crescita <strong>del</strong> volume dei dati da trasportare e <strong>la</strong> fornitura di servizi con requisiti<br />

di tempo reale pongono, <strong>in</strong>sieme alle esigenze di affidabilità e di sicurezza, una<br />

serie di nuovi requisiti <strong>per</strong> le <strong>reti</strong> e gli apparati IP.<br />

Lo scopo di questo <strong>la</strong>voro è appunto quello di analizzare i trend di sviluppo <strong>del</strong>le<br />

architetture di rete, i requisiti emergenti <strong>per</strong> i router e le loro tendenze strutturali <strong>in</strong><br />

un’ottica di rete <strong>in</strong>tegrata multiservizio. A partire da un’analisi dei servizi da<br />

supportare, si concentra <strong>in</strong> prima istanza l’attenzione sulle caratteristiche richieste<br />

alle nuove <strong>reti</strong> <strong>ottiche</strong> metropolitane (MAN; Metropolitan Area Network) che<br />

costituiscono i nuclei di base <strong>del</strong>le nuove <strong>reti</strong> IP. Si analizza <strong>in</strong> partico<strong>la</strong>re il ruolo<br />

<strong>del</strong><strong>la</strong> tecnologia Ethernet sia sul<strong>la</strong> rete di accesso, dove essa si va affermando<br />

come <strong>la</strong> soluzione più favorevole <strong>per</strong> l’<strong>in</strong>sieme dei benefici che comporta, sia<br />

come livello di trasporto nel<strong>la</strong> MAN stessa.<br />

Le tecnologie Internet ed <strong>in</strong> partico<strong>la</strong>re l’architettura protocol<strong>la</strong>re IP, da un <strong>la</strong>to<br />

soddisfano <strong>in</strong> pieno i requisiti di flessibilità e sca<strong>la</strong>bilità richieste, dall’altro <strong>per</strong>ò<br />

necessitano di significativi adeguamenti architetturali che consentano alle<br />

prossime <strong>reti</strong> di essere <strong>in</strong> grado di assicurare adatte prestazioni <strong>in</strong> term<strong>in</strong>i di QoS<br />

e robustezza ai guasti. Per raggiungere questi obiettivi occorre <strong>la</strong>vorare su due<br />

aspetti chiave: l’ Ingegneria <strong>del</strong> Traffico e <strong>la</strong> differenziazione dei servizi.<br />

Le <strong>reti</strong> di trasporto ad alta velocità cui si fa riferimento comprendono le <strong>reti</strong> di<br />

giunzione e le <strong>reti</strong> dorsali. Queste ultime <strong>in</strong> partico<strong>la</strong>re hanno s<strong>per</strong>imentato <strong>in</strong><br />

tempi recenti un notevole potenziamento <strong>in</strong> Italia: migliaia di Km di fibra sono<br />

stati stesi su tutto il territorio nazionale con grande impegno economico dovuto<br />

agli alti costi <strong>del</strong> cab<strong>la</strong>ggio. Le fibre <strong>ottiche</strong>, oltre a rappresentare un vero e<br />

proprio patrimonio <strong>in</strong>frastrutturale, costituiscono il mezzo trasmissivo più veloce.<br />

Ne consegue che gli eventuali cambiamenti necessari <strong>per</strong> rispondere alle nuove<br />

esigenze di traffico riguarderanno soprattutto gli apparati di rete. Si prevede a<br />

questo proposito un impiego sempre più elevato di dispositivi ottici e di router più<br />

flessibili.<br />

9


La gestione <strong>del</strong><strong>la</strong> rete deve essere accompagnata da un adeguato piano di controllo<br />

che tenga conto dei problemi di disponibilità di risorse e di tipologia di traffico<br />

offerto.<br />

Lo scenario che si prospetta è quello di una rete ottica, eterogenea, multiservizio,<br />

basata sul protocollo IP e gestita <strong>in</strong> modo distribuito. Gli apparati di rete devono<br />

avere <strong>la</strong> capacità di <strong>in</strong>stradare il traffico <strong>in</strong> modo veloce ed efficiente, e soprattutto<br />

devono essere <strong>in</strong> grado di gestire <strong>in</strong> modo opportuno le politiche di QoS<br />

(Quality of Service).<br />

In questo contesto si colloca questo Progetto svolto dal<strong>la</strong> Fondazione Ugo<br />

Bordoni <strong>in</strong> col<strong>la</strong>borazione con l’ISCOM (Istituto Su<strong>per</strong>iore <strong>per</strong> le Comunicazioni<br />

e <strong>del</strong>le Tecnologie <strong>del</strong>l’Informazione).<br />

La pr<strong>in</strong>cipale f<strong>in</strong>alità è stata lo studio di <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche <strong>in</strong> presenza di<br />

diverse condizioni di traffico e di politiche di QoS; a tal scopo è stato realizzato<br />

un test-<strong>bed</strong> s<strong>per</strong>imentale di rete ottica utilizzando come modalità di accesso <strong>la</strong><br />

soluzione nota come FTTB (Fiber To The Bild<strong>in</strong>g).<br />

Le architetture di rete basate sul protocollo Ethernet <strong>per</strong> il trasporto di pacchetti<br />

IP/MPLS direttamente su fibra ottica (1 e 10 Gigabit Ethernet) costituisono una<br />

soluzione efficiente <strong>per</strong> il su<strong>per</strong>amento <strong>del</strong>le congestioni che da sempre limitano<br />

<strong>la</strong> velocità di trasmissione dati fra <strong>reti</strong> locali e <strong>reti</strong> geografiche. Sistemi basati su<br />

connessioni GbE <strong>ottiche</strong> trovano oggi impiego non solo <strong>per</strong> il collegamento fra<br />

switch di livello 2 <strong>in</strong> <strong>reti</strong> locali, ma anche <strong>per</strong> il collegamento diretto fra router che<br />

o<strong>per</strong>ano a livello 3 <strong>in</strong> <strong>reti</strong> metropolitane. Tuttavia <strong>la</strong> completa diffusione di GbE è<br />

<strong>in</strong>ficiata dal<strong>la</strong> mancanza di alcune importanti funzioni <strong>per</strong> <strong>la</strong> gestione e<br />

manutenzione <strong>del</strong><strong>la</strong> rete (OAM), come <strong>la</strong> protezione <strong>del</strong>le connessioni <strong>in</strong> caso di<br />

guasto. Lo schema di protezione di tipo 1+1, estremamente semplice e veloce, è<br />

quello più usato, <strong>per</strong> contro richiede <strong>la</strong> duplicazione <strong>del</strong>le risorse quali costose<br />

<strong>in</strong>terfacce sui router e fibre <strong>ottiche</strong>.<br />

Soluzioni più avanzate basate su tecnologia WDM riducono le necessità di fibre<br />

aumentano <strong>per</strong>ò il costo complessivo <strong>del</strong>l’<strong>in</strong>frastruttura di rete.<br />

In questo <strong>la</strong>voro viene dapprima implementato un test-<strong>bed</strong> <strong>per</strong> <strong>la</strong> riservazione<br />

<strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizi secondo l’approccio “DiffServ over MPLS”, poi vengono<br />

valutati s<strong>per</strong>imentalmente i pr<strong>in</strong>cipali limiti che caratterizzano <strong>la</strong> protezione di<br />

10


connessione punto-punto GbE su fibra ottica fra router commerciali di ultima<br />

generazione dest<strong>in</strong>ati ad un utilizzo <strong>in</strong> ambito metropolitano. Si evidenzia, <strong>in</strong><br />

partico<strong>la</strong>re, il tempo impiegato dai router <strong>per</strong> rilevare e gestire il guasto <strong>del</strong><strong>la</strong><br />

connessione, valutando <strong>la</strong> tempistica richiesta dal protocollo di <strong>in</strong>stradamento<br />

Open Shortest Path First (OSPF) <strong>per</strong> il riprist<strong>in</strong>o <strong>del</strong> corretto scambio di pacchetti<br />

dopo che è stata riattivata fisicamente <strong>la</strong> connessione.<br />

Al f<strong>in</strong>e di migliorare il comportamente dei router nelle situazioni considerate,<br />

vengono proposte <strong>del</strong>le l<strong>in</strong>ee di riferimento. Lo studio presenta <strong>in</strong>f<strong>in</strong>e<br />

l’implementazione di uno schema di protezione potenzialmente condivisibile,<br />

veloce ed economico che evita i problemi e le <strong>in</strong>efficienze evidenziate<br />

s<strong>per</strong>imentalmente dai router. Lo schema si basa sull’impiego di dispositivi di<br />

commutazione ottica (PXC) control<strong>la</strong>ti da segna<strong>la</strong>zione fuori-banda.<br />

L’implementazione mostra <strong>la</strong> possibilità di sfruttare le potenzialità <strong>del</strong> sistema di<br />

protezione <strong>per</strong> ridurre l’impiego di risorse pregiate <strong>del</strong>l’<strong>in</strong>frastruttura di rete<br />

(<strong>in</strong>terfacce sui router e fibre <strong>ottiche</strong>) pur garantendo tempi di riprist<strong>in</strong>o <strong>del</strong><strong>la</strong><br />

connessione di pochi millisecondi.<br />

11


Capitolo 1<br />

STATO ATTUALE DELLE RETI E<br />

PROSPETTIVE DI EVOLUZIONE FUTURE<br />

1.1 ARCHITETTURA DELLA RETE FISSA<br />

In generale quando si par<strong>la</strong> di <strong>reti</strong> bisogna dist<strong>in</strong>guere tra:<br />

• Infrastrutture di trasmissione (portanti e tecniche di trasferimento)<br />

• Infrastrutture di commutazione (nodi e procedure di smistamento e<br />

<strong>in</strong>stradamento)<br />

Una rete di telecomunicazione è costituita da un <strong>in</strong>sieme di apparecchiature e<br />

risorse <strong>per</strong> <strong>la</strong> trasmissione e <strong>la</strong> commutazione dei segnali.<br />

Dal punto di vista <strong>del</strong>l’architettura, una rete fissa può essere suddivisa <strong>in</strong> tre parti<br />

pr<strong>in</strong>cipali: accesso, giunzione (o raccolta), dorsale. In letteratura è molto spesso<br />

utilizzato il concetto di “rete di trasporto”, come l’<strong>in</strong>sieme di portanti e apparati<br />

trasmissivi che <strong>per</strong>mette di collegare tra loro i nodi di una rete di TLC.<br />

La rete di accesso <strong>per</strong>mette <strong>la</strong> connessione <strong>del</strong>l’utente al<strong>la</strong> centrale, <strong>in</strong> partico<strong>la</strong>re<br />

si può dividere <strong>in</strong> rete primaria, che riguarda <strong>la</strong> connessione dal<strong>la</strong> centrale<br />

all’armadio di distribuzione, e <strong>in</strong> rete secondaria, che riguarda <strong>la</strong> connessione<br />

dall’armadio all’utente.<br />

Va precisato che <strong>per</strong> <strong>la</strong> struttura utilizzata da Telecom Italia gli armadi <strong>in</strong> realtà<br />

sono due: il primo è connesso al<strong>la</strong> centrale ed è chiamato armadio di<br />

<strong>per</strong>mutazione ed il secondo che connette l’armadio di <strong>per</strong>mutazione con l’utente;<br />

quest’ultimo è detto armadio di distribuzione.


__________________________________________________________________<br />

La rete di raccolta o rete di giunzione è quel<strong>la</strong> che connette le centrali <strong>in</strong> ambito<br />

cittad<strong>in</strong>o.<br />

La rete dorsale connette le città o i grandi centri abitati.<br />

Tutto ciò rappresenta una schematizzazione di pr<strong>in</strong>cipio <strong>del</strong><strong>la</strong> rete di TLC, è molto<br />

probabile, <strong>in</strong>fatti, che nel futuro questa schematizzazione sarà sempre meno<br />

realistica, nel senso che saranno più comuni connessioni tra dom<strong>in</strong>i che oggi<br />

sembrano profondamente dist<strong>in</strong>ti.<br />

Figura 0.1 : Architettura di rete fissa<br />

1.1.1 Infrastrutture di Trasmissione<br />

L’ avvento <strong>del</strong><strong>la</strong> fibra, quale mezzo trasmissivo pr<strong>in</strong>cipale nelle <strong>reti</strong><br />

geograficamente estese, ha condotto, s<strong>in</strong> dai primi anni Novanta, ad un abbandono<br />

dei portanti coassiali <strong>in</strong> rame. L’uso <strong>del</strong>le fibre ha <strong>in</strong>izialmente <strong>in</strong>teressato solo <strong>la</strong><br />

rete dorsale, s<strong>in</strong> dal<strong>la</strong> metà degli anni Novanta <strong>per</strong>ò si è assistito ad un lento ma<br />

<strong>in</strong>esorabile affermarsi di questo mezzo anche nel<strong>la</strong> rete di giunzione, come<br />

conseguenza <strong>del</strong>l’ <strong>in</strong>troduzione dei sistemi SDH (Syncronous Digital Hierarchy).<br />

Sempre nei primi anni Novanta <strong>la</strong> rete ha subito una profonda ristrutturazione che<br />

ha consentito <strong>la</strong> posa di alcuni milioni di nuovi rilevamenti d’utente <strong>in</strong> coppia<br />

simmetrica (dopp<strong>in</strong>i telefonici), che hanno consentito al gestore, allora<br />

13


__________________________________________________________________<br />

monopolista, di rimediare ad una situazione di profonda carenza, soprattutto nelle<br />

grandi metropoli, <strong>per</strong> quello che riguarda il servizio telefonico di base.<br />

I grossi <strong>in</strong>vestimenti effettuati sul<strong>la</strong> rete d’accesso <strong>in</strong> dopp<strong>in</strong>o negli anni Novanta<br />

consentono oggi di poter offrire un’<strong>in</strong>frastruttura importante <strong>per</strong> <strong>la</strong> fornitura dei<br />

servizi a <strong>la</strong>rga banda attraverso <strong>la</strong> tecnologie xDSL (Syncronous Subscriber L<strong>in</strong>e).<br />

Tuttavia, <strong>per</strong> fare fronte all’<strong>in</strong>cremento di richiesta di banda sono necessarie altre<br />

soluzioni che vanno <strong>in</strong>dividuate nel portare una term<strong>in</strong>azione <strong>in</strong> una fibra ottica<br />

sempre più prossima a casa <strong>del</strong>l’utente.<br />

1.1.2 La rete di accesso<br />

Accesso commutato su dopp<strong>in</strong>o telefonico<br />

Il mezzo trasmissivo attualmente più utilizzato <strong>per</strong> <strong>la</strong> rete di accesso, nonché<br />

l’unico che copra completamente il territorio, è <strong>la</strong> coppia simmetrica <strong>in</strong> rame<br />

denom<strong>in</strong>ata usualmente “dopp<strong>in</strong>o telefonico”. Un dopp<strong>in</strong>o è costituito da due fili<br />

<strong>in</strong> rame, “twistati” e non schermati, e costituisce il portante storicamente<br />

utilizzato <strong>per</strong> <strong>la</strong> telefonia analogica <strong>in</strong> area d’accesso. Il dopp<strong>in</strong>o collega<br />

fisicamente <strong>la</strong> centrale locale dei servizi di telecomunicazioni (voce ed <strong>in</strong>ternet)<br />

con l’abitazione <strong>del</strong>l’utente <strong>per</strong> tratte che possono andare dalle cent<strong>in</strong>aia di metri<br />

f<strong>in</strong>o a qualche Km, da cui il nome di “ultimo miglio”. I collegamenti sono dedicati<br />

e <strong>per</strong>manenti, portando a <strong>reti</strong> con <strong>la</strong> tipica configurazione a stel<strong>la</strong>.<br />

Attualmente <strong>per</strong> ragioni storiche <strong>la</strong> pr<strong>in</strong>cipale rete d’accesso su dopp<strong>in</strong>o<br />

appartiene a Telecom Italia. La rete dispone di circa 50 milioni di dopp<strong>in</strong>i di cui<br />

poco più <strong>del</strong><strong>la</strong> metà sfruttati dal<strong>la</strong> cliente<strong>la</strong> d’accesso.<br />

In generale si tratta di una buona rete d’accesso con una vita residua di qualche<br />

dec<strong>in</strong>a d’anni.<br />

Accesso su dopp<strong>in</strong>o: <strong>la</strong> tecnologia xDSL<br />

Negli anni Ottanta, attraverso <strong>la</strong> ricerca sul<strong>la</strong> modu<strong>la</strong>zione, è stato def<strong>in</strong>ito un<br />

modem di concezione <strong>in</strong>novativa, <strong>la</strong> cosiddetta tecnologia DSL (Digital<br />

Subscriber Loop) di cui l’accesso base al<strong>la</strong> rete ISDN ( Integrated Service Digital<br />

Network ) costituisce un primo esempio.<br />

14


__________________________________________________________________<br />

Con il term<strong>in</strong>e xDSL si <strong>in</strong>tende una famiglia di tecniche trasmissive che<br />

consentono di fornire servizi a <strong>la</strong>rga banda <strong>in</strong> area d’utente utilizzando come<br />

mezzi di trasporto i portanti <strong>in</strong> rame già istal<strong>la</strong>ti.<br />

La realizzazione di un collegamento xDSL prevede l’istal<strong>la</strong>zione di un DSLAM<br />

(Digital Subscriber L<strong>in</strong>e Access Multiplexer) <strong>in</strong> una sede centrale e di un NT<br />

(Network Termiation) <strong>in</strong> casa <strong>del</strong>l’utente, comunemente chiamato modem. Si<br />

separa, tramite filtri, <strong>la</strong> banda fonica da quel<strong>la</strong> dati, senza <strong>la</strong> necessità di<br />

<strong>in</strong>tervenire sul collegamento fisico e riducendo così i costi di fornitura dei servizi.<br />

Va <strong>per</strong>ò osservato che, considerato lo stato di degrado di alcuni dopp<strong>in</strong>i, problemi<br />

di diafonia 1 rendono disponibili, <strong>per</strong> i servizi a banda <strong>la</strong>rga, solo il 50% di quelli<br />

esistenti.<br />

Una caratteristica <strong>del</strong>le tecniche xDSL è <strong>la</strong> possibilità di commercializzare<br />

all’utente f<strong>in</strong>ale un <strong>in</strong>sieme di soluzioni molto variegate <strong>in</strong> term<strong>in</strong>i di capacità da e<br />

verso <strong>la</strong> rete.<br />

L’ADSL (Asymmetric Digital Subscriber L<strong>in</strong>e) è una tecnica trasmissiva<br />

asimmetrica che prevede una maggiore capacità dal<strong>la</strong> rete “downl<strong>in</strong>k” ed una<br />

m<strong>in</strong>ore verso <strong>la</strong> rete “upl<strong>in</strong>k”. Per utenze di tipo bus<strong>in</strong>ess sono dedicati accessi di<br />

tipo SDSL (Symmetric Digital Subscriber L<strong>in</strong>e) , ed <strong>in</strong>oltre esiste una piattaforma<br />

xDSL che può essere resa disponibile anche <strong>per</strong> utenze domestiche e prende il<br />

nome di VDSL (Very Hight bit rate Digital Subscriber L<strong>in</strong>e). Si tratta di<br />

un’evoluzione dei sistemi asimmetrici ADSL verso capacità f<strong>in</strong>o a 52 Mbit/s<br />

verso l’utente e di alcuni Mbit/s verso <strong>la</strong> rete.<br />

E’ importante sottol<strong>in</strong>eare che le prestazioni trasmissive <strong>del</strong>le tecniche xDSL<br />

dipendono fortemente dal<strong>la</strong> lunghezza <strong>del</strong> dopp<strong>in</strong>o telefonico, essendo<br />

l’attenuazione proporzionale al<strong>la</strong> radice <strong>del</strong><strong>la</strong> frequenza, e dagli effetti <strong>del</strong><strong>la</strong><br />

diafonia su sistemi trasmissivi utilizzanti lo stesso settore di cavo.<br />

Accesso dedicato <strong>in</strong> fibra ottica<br />

La fibra ottica costituisce <strong>la</strong> modalità d’accesso più importante <strong>in</strong> term<strong>in</strong>i di<br />

sviluppo futuro <strong>del</strong><strong>la</strong> rete, soprattutto considerando le esigenze <strong>del</strong>l’<strong>in</strong>dustria e<br />

1 Fenomeno di accoppiamento elettromagnetico tra i segnali che viaggiano su portanti affasciati<br />

nello stesso cavo.<br />

15


__________________________________________________________________<br />

degli enti che necessitano di capacità ben più elevate di quelle disponibili con<br />

l’ADSL. Il costo <strong>del</strong>le tecnologie <strong>per</strong> l’accesso ottico risulta meno elevato, <strong>per</strong><br />

questo motivo, ad oggi, le fibre <strong>ottiche</strong> sono arrivate s<strong>in</strong>o al<strong>la</strong> connessione degli<br />

armadi e non mancano soluzioni che tendono a portare <strong>la</strong> fibra, qu<strong>in</strong>di l’alta<br />

capacità, sempre più <strong>in</strong> prossimità <strong>del</strong>l’utente. In questa maniera si tende a<br />

diffondere <strong>la</strong> fibra sia a livello d’accesso primario che secondario.<br />

In letteratura sono presenti tre soluzioni d’accesso <strong>per</strong> le fibre:<br />

♦ <strong>la</strong> FTTH (Fiber To The Home), che consiste nel raggiungere i s<strong>in</strong>goli<br />

utenti f<strong>in</strong>ali direttamente con <strong>la</strong> fibra ottica;<br />

♦ <strong>la</strong> FTTB (Fiber To The Build<strong>in</strong>g), che consiste nell’effettuare il<br />

cab<strong>la</strong>ggio ottico f<strong>in</strong>o agli edifici, adottando nell’ultimo tratto il dopp<strong>in</strong>o<br />

con sistemi xDSL, o un cavo UTP Fast ethernet;<br />

♦ <strong>la</strong> FTTC (Fibre To The Curb), che consiste nell’effettuare il cab<strong>la</strong>ggio<br />

f<strong>in</strong>o al marciapiede, cioè <strong>in</strong> prossimità degli edifici, con una soluzione<br />

<strong>in</strong>termedia che è molto vic<strong>in</strong>a a quel<strong>la</strong> al<strong>la</strong> FTTB.<br />

Esistono al momento molti esempi di applicazione <strong>in</strong> Italia <strong>del</strong><strong>la</strong> FTTB<br />

soprattutto <strong>per</strong> grandi aziende, banche, università etc.<br />

Allo stato attuale Telecom Italia possiede una rete d’accesso <strong>in</strong> fibra stimabile<br />

<strong>in</strong>torno a 400000 km, con una lunghezza media dei collegamenti tra centrale ed<br />

utilizzatore di circa 2 Km. Su questa rete sono forniti direttamente accessi SDH e,<br />

cosa che riguarda più da vic<strong>in</strong>o questo <strong>la</strong>voro, accessi di tipo GbE (Gigabit<br />

Ethernet).<br />

1.1.3 La rete di giunzione<br />

Il traffico generato dai s<strong>in</strong>goli utenti o da piccoli gruppi nel<strong>la</strong> rete d’accesso,<br />

prima di andare sul<strong>la</strong> dorsale, viene aggregato nel<strong>la</strong> rete, secondo modalità<br />

opportune, nel<strong>la</strong> rete di giunzione o raccolta.<br />

Caratteristica tipica <strong>del</strong>le <strong>reti</strong> di raccolta è <strong>la</strong> presenza di architetture ad anello, che<br />

possono essere artico<strong>la</strong>te su più livelli, <strong>in</strong> cui sono effettuate le o<strong>per</strong>azioni di<br />

concentrazione <strong>del</strong> traffico. Si com<strong>in</strong>cia da piccoli anelli di raccolta locali, <strong>in</strong><br />

pratica le centrali di un quartiere, f<strong>in</strong>o ad anelli più grandi, metropolitani, <strong>in</strong> cui<br />

16


__________________________________________________________________<br />

sono <strong>in</strong>globati nel <strong>per</strong>corso <strong>del</strong>l’anello i nodi di transito più importanti <strong>del</strong><strong>la</strong> zona<br />

urbana.<br />

Nel caso di accesso <strong>in</strong> fibra, che realizza <strong>la</strong> soluzione FTTB, il collegamento tra<br />

utente e centrale locale è realizzato mediante anelli <strong>in</strong> fibra ottica, dedicati e<br />

condivisi, secondo <strong>la</strong> tipologia degli utenti, che hanno lo scopo di convogliare il<br />

traffico sugli anelli metropolitani, sempre <strong>in</strong> fibra a più elevata capacità.<br />

La tecnologia più utilizzata è l’SDH ma, <strong>per</strong> il trattamento <strong>del</strong> traffico Internet, si<br />

sta diffondendo quel<strong>la</strong> <strong>del</strong><strong>la</strong> LAN estesa con <strong>in</strong>terfacce GbE.<br />

Già da qualche anno le <strong>reti</strong> di raccolta usano sistemi e tecnologie più moderni<br />

basate sul<strong>la</strong> trasmissione <strong>in</strong> WDM (Wavelength Division Multiplexig), che<br />

consentono d’<strong>in</strong>crementare notevolmente <strong>la</strong> capacità disponibile su ogni s<strong>in</strong>go<strong>la</strong><br />

fibra ottica.<br />

1.1.4 La rete dorsale<br />

Il panorama nazionale sulle <strong>reti</strong> dorsali evidenzia a breve term<strong>in</strong>e una capacità<br />

ampiamente su<strong>per</strong>iore al<strong>la</strong> domanda effettiva.<br />

Per motivi storici è opportuno trattare <strong>del</strong><strong>la</strong> rete dorsale di Telecom Italia, poiché<br />

data <strong>la</strong> condizione di ex monopolista è di fatto <strong>la</strong> più grande compagnia<br />

proprietaria di <strong>in</strong>frastrutture di telecomunicazione.<br />

La dorsale è oggi costituita, <strong>in</strong> prevalenza, da cavi <strong>in</strong> fibra ottica: circa 260000<br />

Km di fibra <strong>in</strong> 85000 Km di cavo ottico.<br />

Una <strong>del</strong><strong>la</strong> caratteristiche <strong>del</strong><strong>la</strong> dorsale Telecom è aver opportunamente sfruttato <strong>la</strong><br />

geografia <strong>del</strong> Paese <strong>in</strong>stal<strong>la</strong>ndo <strong>la</strong> cosiddetta “rete a festoni”, che consiste nel<br />

collegamento <strong>del</strong>le città che si affacciano sul mare mediante cavi sottomar<strong>in</strong>i:<br />

anziché effettuare onerosi scavi <strong>per</strong> collegare tutto il paese, si è preferito<br />

l’<strong>in</strong>stal<strong>la</strong>zione di cavi che costeggiano tutto il paese.<br />

Un cavo a festoni ha una lunghezza che si aggira tra i 100 ed i 200 Km. La rete<br />

dorsale è <strong>per</strong> <strong>la</strong> maggior parte cab<strong>la</strong>ta con fibre G.653 o dis<strong>per</strong>sion shifted , fibre<br />

che hanno <strong>la</strong> partico<strong>la</strong>rità di avere una dis<strong>per</strong>sione cromatica prossima allo zero<br />

nelle lunghezze d’onda degli amplificatori convenzionali (1530-1560 nm).<br />

Sfortunatamente <strong>la</strong> regione con dis<strong>per</strong>sione cromatica prossima allo zero ha una<br />

forte contro<strong>in</strong>dicazione <strong>per</strong> i sistemi WDM, poiché si generano forti effetti non<br />

17


__________________________________________________________________<br />

l<strong>in</strong>eari. Va <strong>per</strong>ò osservato che, negli ultimi anni, sono stati messi a punto nuovi<br />

amplificatori ottici che <strong>la</strong>vorano <strong>in</strong> una regione <strong>del</strong>lo spettro (1570-1610 nm) <strong>in</strong><br />

cui il valore <strong>del</strong><strong>la</strong> dis<strong>per</strong>sione cromatica riduce fortemente gli effetti non l<strong>in</strong>eari.<br />

A partire dal 1999 <strong>la</strong> dorsale Telecom Italia è passata da una tradizionale struttura<br />

magliata ad una struttura ad anelli <strong>in</strong>terconnessi, riducendo il numero dei nodi<br />

pr<strong>in</strong>cipali.<br />

1.1.5 Numerizzazione <strong>del</strong>le centrali di Commutazione nel<strong>la</strong> rete<br />

pubblica<br />

La progressiva sostituzione <strong>del</strong>le centrali analogiche con quelle numeriche nel<strong>la</strong><br />

rete di commutazione, e l’utilizzo <strong>del</strong><strong>la</strong> segna<strong>la</strong>zione SSN7, hanno <strong>per</strong>messo<br />

l’<strong>in</strong>troduzione di nuovi servizi come l’ISDN, l’<strong>in</strong>tegrazione completa con <strong>la</strong> rete<br />

di trasporto numerica, <strong>in</strong>izialmente PDH (Plesiochronous Digital Hierarchy) e<br />

successivamente SDH.<br />

I vantaggi ottenuti con <strong>la</strong> numerizzazione <strong>del</strong>le centrali si possono elencare nei<br />

seguenti punti:<br />

♦<br />

♦<br />

♦<br />

♦<br />

♦<br />

♦<br />

Maggiore qualità <strong>del</strong> servizio telefonico <strong>in</strong> term<strong>in</strong>i d’<strong>in</strong>telleggibilità,<br />

affidabilità e disponibilità;<br />

Integrazione <strong>del</strong><strong>la</strong> voce con <strong>la</strong> trasmissione dati;<br />

Servizi di segna<strong>la</strong>zione automatica a tutti i livelli gerarchici <strong>del</strong><strong>la</strong> rete di<br />

commutazione;<br />

Ottimizzazione <strong>del</strong><strong>la</strong> rete;<br />

Introduzione <strong>del</strong><strong>la</strong> flessibilità nel<strong>la</strong> rete e centralizzazione <strong>del</strong> controllo e<br />

<strong>del</strong><strong>la</strong> gestione;<br />

Maggiore efficacia nel<strong>la</strong> gestione.<br />

La migrazione dal<strong>la</strong> tecnica analogica a quel<strong>la</strong> numerica ha consentito al Paese di<br />

adeguarsi agli standard mondiali di qualità sul servizio telefonico, così come<br />

previsto dalle raccomandazioni ITU (International Telecomuncation Union) <strong>del</strong><strong>la</strong><br />

serie G.<br />

18


__________________________________________________________________<br />

1.2 TECNOLOGIE DI COMMUTAZIONE<br />

1.2.1 I Sistemi SDH<br />

La tecnologia PDH, che aveva caratterizzato f<strong>in</strong>o agli <strong>in</strong>izi degli anni Novanta le<br />

<strong>in</strong>frastrutture <strong>del</strong>le <strong>reti</strong> di trasporto numeriche, è stata affiancata e quasi<br />

completamente sostituita dai sistemi SDH anche detti “sistemi s<strong>in</strong>croni”.<br />

Gli apparati fondamentali <strong>del</strong>l’ SDH sono gli ADM (Add Drop Multiplexer) <strong>per</strong><br />

l’<strong>in</strong>serimento e il prelievo di flussi numerici e i DXC ( Digital Cross Connect )<br />

<strong>per</strong> <strong>la</strong> <strong>per</strong>mutazione <strong>del</strong> traffico a livello di flussi aggregati. Nel<strong>la</strong> seconda parte<br />

degli anni Novanta questi sistemi sono stati <strong>in</strong>seriti <strong>in</strong> grande quantità sia nel<strong>la</strong><br />

rete dorsale con frequenze di cifra di 622 Mbit/s e 2,5 Gbit/s (STM-4 e 16, DXC<br />

4/4 ), sia nel<strong>la</strong> rete di giunzione con sistemi a frequenze di cifra di 155 Mbit/s e<br />

622 Mbit/s (STM-1 e 4, DXC 4/3/1, ADM-1).<br />

Figura 0.2 : Blocchi funzionali di un DXC e di un ADM<br />

Allo stato attuale <strong>la</strong> massima penetrazione dei sistemi SDH si ha nel<strong>la</strong> rete<br />

nazionale dorsale, <strong>in</strong> cui gli apparati raggiungono il 90% di presenza mentre i<br />

sistemi PDH vengono progressivamente dimessi.<br />

In area metropolitana sono presenti e molto diffusi anelli di raccolta SDH che<br />

aggregano il traffico nell’ area di accesso e lo canalizzano verso l’ area di<br />

giunzione.<br />

Gli apparati <strong>del</strong><strong>la</strong> rete SDH hanno favorito un netto miglioramento <strong>per</strong> quanto<br />

concerne <strong>la</strong> trasmissione numerica dei flussi:<br />

19


__________________________________________________________________<br />

♦<br />

♦<br />

♦<br />

♦<br />

Razionalizzazione nel<strong>la</strong> gestione complessiva <strong>del</strong><strong>la</strong> rete, con un’unica<br />

potenziale struttura di trasporto capace di supportare qualsiasi tipo di<br />

traffico (voce, dati, traffico ATM e IP, segnali video);<br />

Automatizzazione completa <strong>del</strong>le o<strong>per</strong>azioni di <strong>per</strong>mutazione a livello di<br />

flussi aggregati;<br />

Compatibilità con tutti i sistemi numerici precedenti;<br />

Introduzione di potenti strumenti <strong>per</strong> <strong>la</strong> gestione, il controllo, <strong>la</strong><br />

protezione e <strong>la</strong> manutenzione <strong>del</strong><strong>la</strong> rete su base nazionale.<br />

1.2.2 La tecnologia ATM<br />

Dal ’94 Telecom ha avviato <strong>la</strong> realizzazione di una rete ATM (Asyncronous<br />

Transfer Mode), prima <strong>in</strong> ambito s<strong>per</strong>imentale all’<strong>in</strong>terno di un progetto con altri<br />

o<strong>per</strong>atori europei e dal 1996 <strong>in</strong> ambito commerciale, sostenendo <strong>in</strong>vestimenti <strong>in</strong><br />

<strong>in</strong>frastrutture di rete ATM <strong>in</strong> più di venti città italiane.<br />

Questa rete attualmente costituisce il supporto <strong>del</strong><strong>la</strong> <strong>la</strong>rga banda ed è impiegata<br />

<strong>per</strong> gestire il traffico dati proveniente dalle <strong>reti</strong> ADSL.<br />

1.2.3 La tecnologia IP<br />

L’affermazione <strong>del</strong> protocollo IP (Internet Protocol ) e dei servizi di Internet ha<br />

fortemente condizionato lo sviluppo <strong>del</strong>le <strong>reti</strong> ATM che, di fatto, non<br />

costituiscono più <strong>la</strong> struttura di riferimento <strong>per</strong> le <strong>reti</strong> future. Attualmente il<br />

trasporto <strong>del</strong> traffico IP avviene con ATM <strong>per</strong> <strong>la</strong> trasmissione a livello di<br />

pacchetto ed SDH <strong>per</strong> il trasporto <strong>del</strong> segnale. Sia ATM che SDH assicurano <strong>la</strong><br />

trasmissione <strong>del</strong> pacchetto IP, tuttavia questo doppio passaggio, IP over ATM<br />

over SDH, risulta oneroso <strong>in</strong> term<strong>in</strong>i di banda <strong>in</strong> primo luogo <strong>per</strong> il notevole<br />

overhead, poi <strong>per</strong> tutta una serie di duplicazioni funzionali.<br />

Oggi sono <strong>in</strong> fase di s<strong>per</strong>imentazione avanzata tecniche di trasporto più semplici e<br />

meno costose come ad esempio IP over WDM; <strong>in</strong> queste tecniche si cerca di<br />

elim<strong>in</strong>are le ridondanze presenti tra IP ed SDH poiché il protocollo IP,<br />

20


__________________________________________________________________<br />

<strong>in</strong>tr<strong>in</strong>secamente associato al TCP ( Transport Control Protocol ) già presenta di<br />

<strong>per</strong> se molte tecniche di protezione.<br />

1.3 LE RETI NAZIONALI E PROSSIMI SVILUPPI<br />

1.3.1 Le <strong>reti</strong> di raccolta e le <strong>reti</strong> dorsali<br />

La rete <strong>del</strong> trasporto sta divenendo sempre di più una rete “tutta ottica” nel senso<br />

che non è solo ottica <strong>la</strong> trasmissione dei segnali ma diverrà ottica anche<br />

l’e<strong>la</strong>borazione dei segnali nei nodi d’<strong>in</strong>stradamento e ri<strong>la</strong>ncio. Esistono precise<br />

normative che descrivono come deve essere realizzata una Rete di Trasporto<br />

Ottica (OTN, Optical Transport Network) <strong>la</strong> cui def<strong>in</strong>izione è formu<strong>la</strong>ta nel<strong>la</strong><br />

raccomandazione ITU-T G.872.<br />

Nonostante <strong>la</strong> capacità offerta dalle <strong>in</strong>frastrutture di telecomunicazione sia<br />

su<strong>per</strong>iore al<strong>la</strong> domanda gli attuali meccanismi di gestione non sembrano idonei a<br />

soddisfare le esigenze di traffico future a causa <strong>del</strong><strong>la</strong> natura statistica <strong>del</strong> traffico<br />

generato nei nuovi servizi a banda <strong>la</strong>rga, completamente diversa da quel<strong>la</strong> <strong>del</strong><br />

traffico telefonico. Il traffico subisce picchi molto <strong>in</strong>tensi e con distribuzione<br />

imprevedibile sui vari rami <strong>del</strong><strong>la</strong> rete, <strong>per</strong> questo si necessita che le <strong>reti</strong> di<br />

prossima generazione siano gestite con tecniche <strong>in</strong> grado di assegnare circuiti <strong>in</strong><br />

maniera rapida e automatica. Sul<strong>la</strong> base di queste considerazioni ci si aspetta di<br />

qui a poco un cambiamento nelle <strong>reti</strong> di trasporto.<br />

Questi cambiamenti avverranno sotto diversi aspetti, non necessariamente<br />

disgiunti, ma con due fattori <strong>in</strong> comune: <strong>per</strong>vasività <strong>del</strong>le tecniche <strong>ottiche</strong> e<br />

trasporto “tutto IP” direttamente sul<strong>la</strong> fibra, senza protocolli di livello <strong>in</strong>termedio.<br />

L’evoluzione <strong>del</strong><strong>la</strong> rete <strong>in</strong>teresserà tre campi dist<strong>in</strong>ti:<br />

♦ Collegamento tra nodi<br />

♦ Piano di controllo 2<br />

♦ Trattamento <strong>del</strong> traffico da parte dei nodi.<br />

2 Nel<strong>la</strong> term<strong>in</strong>ologia IETF il piano di controllo identifica l’<strong>in</strong>sieme <strong>del</strong>le procedure di controllo e<br />

l’istradamento dei pacchetti.<br />

21


__________________________________________________________________<br />

Collegamento tra nodi<br />

I collegamenti tra nodi sfruttano <strong>in</strong> gran parte le fibra <strong>ottiche</strong> già stese, e<br />

l’<strong>in</strong>cremento <strong>del</strong>le capacità avviene tramite l’<strong>in</strong>troduzione sia di sistemi a s<strong>in</strong>golo<br />

canale con capacità elevate (10 Gbit/s e 40 Gbit/s) sia di sistemi WDM.<br />

Vengono utilizzate tecniche partico<strong>la</strong>ri <strong>per</strong> adattare le fibre già <strong>in</strong>stal<strong>la</strong>te alle<br />

esigenze dei nuovi sistemi come ad esempio <strong>la</strong> compensazione <strong>del</strong><strong>la</strong> dis<strong>per</strong>sione<br />

cromatica nelle fibre G.652 e l’amplificazione <strong>in</strong> banda L nelle fibre G.653,<br />

tuttavia non sono escluse anche <strong>in</strong>stal<strong>la</strong>zioni di nuovi cavi, <strong>in</strong> partico<strong>la</strong>re abbiamo<br />

<strong>in</strong> o<strong>per</strong>a <strong>la</strong> stesura <strong>del</strong>le G.655 realizzate proprio <strong>per</strong> sistemi WDM ad alta<br />

capacità.<br />

Per quanto riguarda i formati di trasferimento, oggi si è orientati ad utilizzare<br />

sistemi più semplici ed economici <strong>del</strong>l’SDH.<br />

Attualmente <strong>la</strong> soluzione più <strong>in</strong>dicata è <strong>la</strong> trasmissione GbE (Gigabit-Ethernet),<br />

dal costo molto <strong>in</strong>feriore rispetto a quello <strong>del</strong><strong>la</strong> tecnica SDH, <strong>in</strong>oltre offre <strong>del</strong>le<br />

capacità molto competitive visti i profili di traffico attuale: 1.25 Gbit/s e<br />

recentemente <strong>in</strong> commercio anche versioni 10 Gbit/s. L’unico vero <strong>in</strong>conveniente<br />

è che <strong>la</strong> GbE non può essere utilizzata <strong>per</strong> collegamenti su<strong>per</strong>iori ai 70 Km.<br />

La breve distanza che mette a disposizione questa soluzione è tale che consentirne<br />

l’utilizzo esclusivamente <strong>in</strong> area metropolitana mentre sul<strong>la</strong> dorsale rimane<br />

l’SDH.<br />

Piano di Controllo<br />

Una <strong>del</strong>le caratteristiche fondamentali che deve avere una rete di nuova<br />

generazione è quel<strong>la</strong> di poter assegnare flussi numerici diretti tra due nodi<br />

prefissati <strong>in</strong> maniera automatica e d<strong>in</strong>amica <strong>per</strong> far fronte al traffico di Internet,<br />

<strong>per</strong> ora ci sono due possibilità: <strong>la</strong> prima è costituita dal piano di controllo GMPLS<br />

(Generalised Multi-Protocol Label Switch<strong>in</strong>g) def<strong>in</strong>ito nell’ambito <strong>del</strong>l’organismo<br />

IETF (Internet Eng<strong>in</strong>eer<strong>in</strong>g Task Force) e l’ASON ( Automatic Switched Optical<br />

Network), def<strong>in</strong>ito <strong>in</strong> ambito ITU-T. L’aspetto più rilevante sia di GMPLS che di<br />

ASON è che <strong>per</strong>mettono un’assegnazione automatica di banda , basata su una<br />

verifica <strong>del</strong> piano di controllo sullo stato <strong>del</strong>le risorse tra i nodi.<br />

22


__________________________________________________________________<br />

L’adozione <strong>del</strong> Bandwidth on Demand, oltre che ad offrire un <strong>in</strong>novativo servizio<br />

di rete, consente, di ridurre i costi di servizi tradizionali (CAPEX 3 e OPEX 4 )<br />

grazie ad una gestione più snel<strong>la</strong> di rete.<br />

Trattamento <strong>del</strong> traffico da parte dei nodi<br />

Una gestione <strong>del</strong> segnale a livello ottico favorisce una notevole dim<strong>in</strong>uzione dei<br />

tempi di commutazione nonchè un risparmio sui costi di gestione <strong>del</strong><strong>la</strong> rete.<br />

Nei sistemi WDM questo già avviene, tramite gli OADM (Optical Add Drop<br />

Multiplexer) i canali ottici sono <strong>in</strong>seriti ed estratti dal<strong>la</strong> rete, gli OADM sono<br />

dispositivi base <strong>per</strong> gli anelli ottici. Gli OXC (Optical Cross Connect) sono una<br />

c<strong>la</strong>sse di dispositivi <strong>per</strong> le nuove <strong>reti</strong>, questi consentono lo scambio di segnali<br />

all’<strong>in</strong>terno di matrici con moltissime porte.<br />

Un altro dispositivo chiave è il convertitore di frequenza, questi consente il<br />

cambiamento <strong>del</strong> colore <strong>del</strong> segnale secondo le esigenze di traffico, di<br />

congestione <strong>del</strong><strong>la</strong> rete e di riprist<strong>in</strong>o. Inf<strong>in</strong>e un altro dispositivo importante <strong>per</strong> <strong>la</strong><br />

rete ottica è l’impiego di “rigeneratori ottici 3R” (rigenerazione, risagomatura,<br />

recu<strong>per</strong>o), sig<strong>la</strong> che <strong>in</strong>dica l’<strong>in</strong>tegrazione di tre processi cui sottoporre il segnale:<br />

amplificazione, reshap<strong>in</strong>g <strong>del</strong>l’impulso ed elim<strong>in</strong>azione <strong>del</strong>le fluttuazioni nel<br />

ritardo di trasferimento (jitter).<br />

Nel prossimo paragrafo verrà approfondita <strong>la</strong> descrizione degli apparati appena<br />

citati.<br />

1.4 SVILUPPO DEL CONTROL-PLANE ED EVOLUZIONE<br />

DELLE RETI DI TELECOMUNICAZIONI IN AREA<br />

METRO E CORE<br />

Le <strong>reti</strong> trasmissive, <strong>in</strong> partico<strong>la</strong>re nelle aree metropolitane e lunga distanza (core),<br />

sono oggetto di un’evoluzione che si dipana su due direttrici pr<strong>in</strong>cipali: l’aumento<br />

<strong>del</strong>l’<strong>in</strong>telligenza degli apparati di rete, attraverso lo sviluppo di un piano di<br />

controllo (parzialmente distribuito), e l’<strong>in</strong>tegrazione dei livelli di switch<strong>in</strong>g<br />

all’<strong>in</strong>terno <strong>del</strong> nodo. La Figura 1.3 mostra uno scenario di rete che fotografa <strong>la</strong><br />

3 CAPEX: Costi <strong>in</strong>frastrutturali<br />

4 OPEX: Costi di manutenzione legati all’<strong>in</strong>tervento umano<br />

23


__________________________________________________________________<br />

situazione attuale o che si prospetta nel breve term<strong>in</strong>e (2006-2007). Tale scenario<br />

vede <strong>la</strong> presenza di un’evoluzione <strong>del</strong><strong>la</strong> tecnologia SDH (chiamata SDH agile) che<br />

<strong>per</strong>mette, attraverso GFP (Generic Fram<strong>in</strong>g Procedure) e LCAS (L<strong>in</strong>k Capacity<br />

Adjustment Scheme), <strong>la</strong> mo<strong>del</strong>lizzazione <strong>del</strong> profilo di un traffico a pacchetti<br />

(generalmente basato su trama Ethernet) <strong>in</strong> un numero variabile di VC-4 sul<strong>la</strong> rete<br />

trasmissiva server. Partico<strong>la</strong>rmente <strong>in</strong>teressanti le opportunità offerte<br />

dall’<strong>in</strong>tegrazione <strong>del</strong>le funzionalità <strong>del</strong> controllore LCAS con il piano di controllo<br />

ASON/GMPLS.<br />

Figura 0.3 :Scenario rete attuale<br />

Il più importante punto di <strong>in</strong>novazione <strong>del</strong><strong>la</strong> rete rappresentata dal<strong>la</strong> Figura 1.4,<br />

rispetto allo scenario di più breve term<strong>in</strong>e (Figura 1.3), è l’<strong>in</strong>tegrazione verticale<br />

(che comprende più livelli <strong>del</strong><strong>la</strong> pi<strong>la</strong> ISO/OSI) <strong>del</strong> piano di controllo; tale<br />

<strong>in</strong>tegrazione <strong>in</strong>teressa <strong>in</strong> partico<strong>la</strong>re i livelli 1 e 2, ma meno il livello 3 che, <strong>in</strong><br />

questo scenario, è rappresentato dai protocolli IP/MPLS attraverso un proprio<br />

piano di controllo.<br />

Questo scenario rende di fatto possibile il servizio di BoD (Bandwidth on<br />

Demand), vale a dire l’offerta di servizi di connettività a banda variabile su<br />

richiesta <strong>del</strong> cliente.<br />

24


__________________________________________________________________<br />

Figura 0.4 : Integrazione verticale <strong>del</strong> piano di controllo<br />

L’evoluzione <strong>in</strong> term<strong>in</strong>i di <strong>in</strong>telligenza e di <strong>in</strong>tegrazione <strong>del</strong>le funzionalità porta<br />

allo scenario rappresentato <strong>in</strong> Figura 1.5. Questo mo<strong>del</strong>lo, proiettato <strong>in</strong> uno<br />

scenario di lungo term<strong>in</strong>e (2010-2015), viene chiamato peer-to-peer <strong>in</strong> quanto<br />

elim<strong>in</strong>a di fatto il rapporto client/server tra i piani di controllo dei diversi strati di<br />

rete.<br />

Figura 0.5 : Mo<strong>del</strong>lo Peer to Peer<br />

25


__________________________________________________________________<br />

In questo mo<strong>del</strong>lo, le <strong>reti</strong> dati, basate sul protocollo IP, e le <strong>reti</strong> <strong>ottiche</strong><br />

condividono il medesimo protocollo di rout<strong>in</strong>g (concetto storicamente nato <strong>in</strong><br />

ambito IP), ovviamente dotato di estensioni che lo rendono fruibile anche <strong>per</strong> <strong>reti</strong><br />

trasmissive.<br />

Questo fatto <strong>per</strong>mette ad un router di calco<strong>la</strong>re il <strong>per</strong>corso end-to-end anche se i<br />

vari router sono connessi tra loro attraverso una complessa rete di trasporto. In<br />

def<strong>in</strong>itiva, apparati IP e trasmissivi condividono un’unica visione di rete.<br />

1.4.1 Nuovi servizi e vantaggi economici dall’adozione di <strong>reti</strong><br />

ASON/GMPLS<br />

Le <strong>reti</strong> con funzionalità ASON/GMPLS prevedono <strong>la</strong> presenza di un piano di<br />

controllo <strong>in</strong> grado di eseguire automaticamente alcune funzioni di base (rout<strong>in</strong>g,<br />

discovery, segna<strong>la</strong>zione) <strong>per</strong> l’<strong>in</strong>staurazione o l’abbattimento di connessioni a<br />

<strong>la</strong>rga banda end-to-end.<br />

A partire da queste, si possono predisporre funzionalità più complesse che mirano,<br />

<strong>in</strong> generale, ad ottenere una migliore efficienza ed una maggiore flessibilità e<br />

rapidità di risposta, attraverso l’utilizzo d<strong>in</strong>amico <strong>del</strong>le risorse di rete.<br />

Il fatto di adottare <strong>reti</strong> trasmissive dotate di un piano di controllo oppure, nel caso<br />

<strong>del</strong> GMPLS, <strong>la</strong> possibilità che tale piano di controllo sia comune a più livelli di<br />

rete, può condurre al contenimento degli <strong>in</strong>vestimenti (CAPEX) e al<strong>la</strong> riduzione<br />

dei costi o<strong>per</strong>ativi (OPEX).<br />

In partico<strong>la</strong>re, le funzionalità considerate, abilitate dal piano di controllo<br />

nell’ambito <strong>del</strong>le tecnologie ASON e GMPLS, che possono portare a vantaggi<br />

economici <strong>per</strong> l’o<strong>per</strong>atore di rete (riduzione CAPEX e OPEX) sono:<br />

♦<br />

♦<br />

♦<br />

♦<br />

♦<br />

♦<br />

Circuit Re-organization<br />

Instal<strong>la</strong>zione automatica / Network Inventory automatico<br />

Provision<strong>in</strong>g automatico<br />

Multi-<strong>la</strong>yer resilience<br />

Multi-<strong>la</strong>yer traffic eng<strong>in</strong>eer<strong>in</strong>g<br />

Trasparenza ottica<br />

26


__________________________________________________________________<br />

1.4.1.1 Circuit Re-organization<br />

Il vantaggio primario <strong>del</strong><strong>la</strong> Circuit Re-organization riguarda pr<strong>in</strong>cipalmente il<br />

recu<strong>per</strong>o di risorse trasmissive, che consente di posticipare <strong>in</strong>terventi di<br />

espansione <strong>del</strong><strong>la</strong> rete, e qu<strong>in</strong>di <strong>per</strong>mette di ridurre gli <strong>in</strong>vestimenti (CAPEX).<br />

L’entità <strong>del</strong> risparmio che si ottiene adottando tecniche di circuit reorganization<br />

automatiche dipende da numerosi fattori, i più importanti dei quali sono:<br />

♦<br />

♦<br />

♦<br />

♦<br />

topologia <strong>del</strong><strong>la</strong> rete (numero di nodi e grado di magliatura);<br />

risorse disponibili<br />

distribuzione ed evoluzione temporale <strong>del</strong> traffico;<br />

frequenza dei riord<strong>in</strong>i;<br />

L’esecuzione di procedure di Circuit Re-organization <strong>in</strong> una rete convenzionale<br />

richiederebbe un significativo <strong>in</strong>tervento di risorse umane (accesso ai data-base,<br />

progettazione dei <strong>per</strong>corsi, esecuzione dei ribaltamenti). La disponibilità di una<br />

rete ASON consente <strong>in</strong>vece l’esecuzione completamente automatica <strong>del</strong><strong>la</strong><br />

procedura, rendendo praticamente attuabile questa procedura, altrimenti di<br />

difficile realizzazione.<br />

1.4.1.2 Instal<strong>la</strong>zione automatica degli apparati<br />

La funzionalità di <strong>in</strong>stal<strong>la</strong>zione automatica <strong>per</strong>mette di <strong>in</strong>stal<strong>la</strong>re gli elementi di<br />

rete configurando, <strong>in</strong> modo automatico, le <strong>in</strong>formazioni re<strong>la</strong>tive ai collegamenti<br />

tra essi senza necessità di un <strong>in</strong>tervento manuale sugli apparati.<br />

I vantaggi di questa procedura automatica impattano pr<strong>in</strong>cipalmente sui costi<br />

o<strong>per</strong>ativi (OPEX), dal momento che si può ottenere un potenziale risparmio<br />

attraverso una riduzione <strong>del</strong>le risorse impegnate nel<strong>la</strong> configurazione degli<br />

apparati.<br />

1.4.1.3 Network Inventory automatico<br />

Grazie al resource discovery, <strong>la</strong> funzionalità di network <strong>in</strong>ventory automatico<br />

<strong>per</strong>mette di aggiornare <strong>in</strong> maniera automatica i data-base di rete, mantenendoli<br />

27


__________________________________________________________________<br />

costantemente all<strong>in</strong>eati con <strong>la</strong> situazione reale senza <strong>la</strong> necessità di complessi<br />

<strong>in</strong>terventi manuali.<br />

Il network <strong>in</strong>ventory automatico si traduce qu<strong>in</strong>di <strong>in</strong> una riduzione degli OPEX<br />

derivante dall’automazione di o<strong>per</strong>azioni che oggi vengono ancora compiute da<br />

o<strong>per</strong>atori umani. L’all<strong>in</strong>eamento automatico, e <strong>in</strong> tempo reale, fra <strong>la</strong> situazione<br />

<strong>del</strong><strong>la</strong> rete e i dati registrati nel data base impedisce <strong>in</strong>oltre di commettere errori di<br />

<strong>in</strong>serimento, rimuovendo al<strong>la</strong> radice <strong>la</strong> necessità di verificare e correggere il data<br />

base e contribuendo così ad un’ulteriore significativo risparmio di tempo e risorse.<br />

1.4.1.4 Provision<strong>in</strong>g automatico<br />

È bene evidenziare che nelle <strong>reti</strong> ASON/GMPLS il primo passo <strong>del</strong>lo schema<br />

(Figura 0.6) <strong>del</strong> provision<strong>in</strong>g di una connessione (cioè l'<strong>in</strong>oltro <strong>del</strong><strong>la</strong> richiesta da<br />

parte di un cliente e <strong>la</strong> re<strong>la</strong>tiva attivazione <strong>del</strong> processo di provision<strong>in</strong>g) può<br />

essere realizzato <strong>in</strong> tre modalità:<br />

♦<br />

♦<br />

♦<br />

tradizionale (richiesta <strong>in</strong>viata al front-end commerciale);<br />

semi-automatica (ad esempio richiesta <strong>in</strong>oltrata dal cliente via Web<br />

direttamente verso il piano di gestione);<br />

automatica (richiesta attraverso <strong>in</strong>terfaccia UNI, o <strong>in</strong>terfaccia <strong>in</strong>terna nel<br />

caso <strong>del</strong> GMPLS).<br />

Le prime due modalità abilitano connessioni di tipo soft-<strong>per</strong>manent, mentre <strong>la</strong><br />

terza <strong>in</strong>staura connessioni di tipo switched. Indipendentemente dal<strong>la</strong> modalità di<br />

richiesta <strong>del</strong><strong>la</strong> connessione, grazie alle funzionalità <strong>del</strong> piano di controllo<br />

(resource discovery, rout<strong>in</strong>g e connection management) i passi 2, 3 e 4 di<br />

Figura1.6 nel provision<strong>in</strong>g <strong>del</strong><strong>la</strong> connessione (sia soft-<strong>per</strong>manent sia switched)<br />

possono avvenire <strong>in</strong> maniera automatica.<br />

28


__________________________________________________________________<br />

Figura 0.6 : Provision<strong>in</strong>g <strong>del</strong><strong>la</strong> connessione<br />

In s<strong>in</strong>tesi, a presc<strong>in</strong>dere da come il cliente <strong>in</strong>oltri <strong>la</strong> richiesta (tradizionale, semiautomatica,<br />

automatica) di connessione, il possibile elemento di valore/risparmio<br />

risiede nello snellimento, <strong>in</strong> virtù degli automatismi <strong>in</strong>trodotti dal piano di<br />

controllo, <strong>del</strong><strong>la</strong> procedura di provision<strong>in</strong>g.<br />

1.4.1.5 Multi-<strong>la</strong>yer resilience<br />

La multi-<strong>la</strong>yer resilience consiste <strong>in</strong> una tecnica <strong>per</strong> cui i meccanismi di resilience<br />

(ad esempio restoration e protezione) sono applicati <strong>in</strong> modo coord<strong>in</strong>ato e<br />

d<strong>in</strong>amico dalle piattaforme IP e trasmissiva. Questo abilita una situazione<br />

partico<strong>la</strong>rmente vantaggiosa <strong>in</strong> quanto lo strato IP richiede <strong>in</strong> modo <strong>per</strong>manente<br />

esclusivamente <strong>la</strong> connettività necessaria <strong>in</strong> condizioni nom<strong>in</strong>ali, mentre solo <strong>in</strong><br />

presenza di guasto richiede <strong>la</strong> capacità aggiuntiva, ma limitatamente a dove è<br />

strettamente necessaria. Questa strategia richiede un’<strong>in</strong>terazione molto stretta tra i<br />

due strati di rete, che, <strong>in</strong> tecnologia ASON GMPLS, può essere realizzata dal<br />

piano di controllo e da <strong>in</strong>terfacce (UNI o <strong>in</strong>terfacce <strong>in</strong>terne) tra router IP e crossconnect<br />

ottici.<br />

29


__________________________________________________________________<br />

1.4.1.6 Multi-<strong>la</strong>yer traffic eng<strong>in</strong>eer<strong>in</strong>g<br />

Una <strong>del</strong>le pr<strong>in</strong>cipali tecniche adottate nel traffic eng<strong>in</strong>eer<strong>in</strong>g tradizionale (ad es. <strong>in</strong><br />

<strong>reti</strong> IP/MPLS) <strong>per</strong> garantire i requisiti di QoS e <strong>per</strong> ottimizzare l'uso <strong>del</strong>le risorse<br />

di rete, prevede il re-<strong>in</strong>stradamento <strong>del</strong> traffico (LSP MPLS). Estendendo questo<br />

concetto ad una rete IP su Ottico (ASON/GMPLS), il traffic eng<strong>in</strong>eer<strong>in</strong>g<br />

multilivello offrirebbe <strong>la</strong> possibilità di re<strong>in</strong>stradare <strong>in</strong> maniera <strong>in</strong>tegrata ed<br />

automatica sia il traffico IP (traffic eng<strong>in</strong>eer<strong>in</strong>g) sia effettuare connessioni <strong>ottiche</strong><br />

preposte al suo trasporto (circuit re-organisation). Questo potrebbe <strong>per</strong>mettere, a<br />

parità di traffico IP, un'ulteriore ottimizzazione <strong>del</strong>le risorse di rete preposte al suo<br />

trasporto e ciò implicherebbe un ulteriore risparmio sul numero di circuiti e di<br />

conseguenza sugli <strong>in</strong>vestimenti (CAPEX).<br />

Più <strong>in</strong> dettaglio, <strong>la</strong> possibilità di implementare il Traffic Eng<strong>in</strong>eer<strong>in</strong>g Multilivello<br />

porta ad un risparmio <strong>per</strong> quanto riguarda:<br />

♦<br />

Banda. Grazie alle funzionalità di Traffic Eng<strong>in</strong>eer<strong>in</strong>g Multilivello non<br />

è più necessario allocare risorse sul picco di traffico o tenendo libere<br />

<strong>del</strong>le risorse <strong>per</strong> far fronte a eventi improvvisi che potrebbero generare<br />

degli aumenti non programmati/bili <strong>del</strong><strong>la</strong> domanda.<br />

♦<br />

Dimensioni dei Router. La coo<strong>per</strong>azione tra il livello dati e quello<br />

trasmissivo <strong>per</strong>mette di <strong>del</strong>egare al secondo tutte le problematiche legate<br />

all’allocazione e all’utilizzo <strong>del</strong>le risorse, qu<strong>in</strong>di è proprio sullo strato IP<br />

che si possono avvertire i maggiori risparmi <strong>in</strong> term<strong>in</strong>i di banda,<br />

risparmio che si traduce <strong>in</strong> un numero m<strong>in</strong>ore di porte sui router e<br />

talvolta <strong>in</strong> apparati di livello 3 di taglia più picco<strong>la</strong>.<br />

1.4.1.7 Trasparenza ottica<br />

Un modo vantaggioso di sfruttare <strong>la</strong> disponibilità di matrici di commutazione<br />

<strong>ottiche</strong> consiste nel<strong>la</strong> def<strong>in</strong>izione di algoritmi/procedure che abilitano il rout<strong>in</strong>g<br />

d<strong>in</strong>amico (<strong>in</strong> una rete con funzionalità ASON/GMPLS), f<strong>in</strong>alizzato al risparmio di<br />

risorse di rete ed <strong>in</strong> partico<strong>la</strong>r modo di rigeneratori OEO e convertitori di<br />

30


__________________________________________________________________<br />

lunghezza d’onda). L’idea è quel<strong>la</strong> di poter disporre, <strong>per</strong> <strong>la</strong> progettazione <strong>del</strong> path<br />

di una connessione, di un piano di controllo evoluto, <strong>in</strong> grado di valutare il<br />

degrado fisico <strong>del</strong> segnale e di scegliere il <strong>per</strong>corso che consente di m<strong>in</strong>imizzare<br />

l’impiego di conversioni <strong>in</strong> elettrico.<br />

1.4.1.8 Aumento Revenues<br />

L’adozione <strong>del</strong>le tecnologie ASON/GMPLS (ed <strong>in</strong> partico<strong>la</strong>re <strong>la</strong> possibilità di<br />

<strong>in</strong>staurare connessioni on-demand) <strong>per</strong>mette <strong>la</strong> fornitura di alcuni servizi di<br />

connettività d<strong>in</strong>amica <strong>per</strong> il trasporto di <strong>in</strong>formazioni generate da partico<strong>la</strong>ri<br />

applicazioni (ad. esempio alcune applicazioni di comput<strong>in</strong>g grid) che sarebbe<br />

impossibile o troppo costoso fornire altrimenti.<br />

Inoltre il bandwidth on-demand abilita <strong>la</strong> riduzione <strong>del</strong> costo <strong>in</strong>dustriale di un<br />

collegamento grazie all’ottimizzazione <strong>del</strong>l’uso <strong>del</strong>le risorse di rete,<br />

all’automazione di alcune complesse procedure e soprattutto grazie al fatto di<br />

poter condividere alcune risorse trasmissive tra più clienti che non le utilizzano<br />

contemporaneamente. Tale dim<strong>in</strong>uzione <strong>del</strong> costo <strong>in</strong>dustriale può riflettersi <strong>in</strong> un<br />

aumento dei guadagni dovuto semplicemente ad una m<strong>in</strong>ore spesa <strong>per</strong> fornire gli<br />

stessi servizi, oppure grazie all’attrazione di nuovi clienti abilitata dal<strong>la</strong> possibilità<br />

di praticare prezzi più bassi.<br />

1.5 CONCLUSIONI<br />

Per più di un decennio le <strong>reti</strong> SDH/SONET sono state al<strong>la</strong> base <strong>del</strong>le <strong>in</strong>frastrutture<br />

di trasporto nelle <strong>reti</strong> metropolitane e a lunga distanza, consentendo gestione<br />

efficiente <strong>del</strong><strong>la</strong> banda e garanzia di qualita' <strong>del</strong> servizio. Piu' recentemente, l'ITU<br />

ha standardizzato l' OTN (recc. G709 e corre<strong>la</strong>te), estendendo i concetti<br />

"tradizionali" <strong>del</strong>le <strong>reti</strong> di trasporto al<strong>la</strong> tecnologia WDM. In questi ultimi anni si<br />

registra una diffusa tendenza a considerare obsolete tali tecnologie di trasporto, le<br />

quali (pur presentando caratteristiche vantaggiose) risultano costose e poco<br />

efficienti. Si ritiene qu<strong>in</strong>di che Ethernet possa essere una migliore alternativa <strong>per</strong><br />

l'aggregazione ed il trasporto nelle <strong>reti</strong> pubbliche, a partire da quelle di accesso<br />

31


__________________________________________________________________<br />

metropolitano. Nel capitolo seguente si analizzerà tale prospettiva sul<strong>la</strong> base <strong>del</strong>le<br />

caratteristiche di tale tecnologia <strong>per</strong> come e’ descritta negli standard già approvati<br />

(pr<strong>in</strong>cipalmente ITU ed IEEE) e <strong>per</strong> come potrebbe diventare grazie agli standard<br />

<strong>in</strong> via di def<strong>in</strong>izione, cercando di <strong>in</strong>dividuare il ruolo che tali caratteristiche le<br />

assegnano <strong>in</strong> una rete di trasporto "ideale" e, di conseguenza, il ruolo che essa<br />

potrà effettivamente giocare nelle <strong>reti</strong> <strong>del</strong> futuro.<br />

32


Capitolo 2<br />

EVOLUZIONE DELLO STANDARD ETHERNET<br />

NELLE RETI MAN<br />

2.1 INTRODUZIONE<br />

In questo capitolo verrà illustrato nel dettaglio lo standard Ethernet e <strong>la</strong> sua rapida<br />

evoluzione. Verranno qu<strong>in</strong>di descritti i processi di standardizzazione attualmente<br />

<strong>in</strong> corso che hanno come obiettivo primario quello di rendere l’Ethernet <strong>la</strong><br />

tecnologia dom<strong>in</strong>ante <strong>per</strong> il trasporto dati.<br />

2.2 LO STANDARD ETHERNET<br />

Lo standard Ethernet si sta affermando <strong>in</strong> questi ultimi anni come tecnologia<br />

dom<strong>in</strong>ante non solo a livello di rete locale, ma anche a livello di rete<br />

metropolitana e geografica. I maggiori vantaggi derivanti dal<strong>la</strong> migrazione <strong>del</strong><strong>la</strong><br />

tecnologia Ethernet a livello di area metropolitana si possono riassumere nei<br />

seguenti punti: velocità, sca<strong>la</strong>bilità, semplicità o<strong>per</strong>azionale, convenienza<br />

economica <strong>del</strong><strong>la</strong> soluzione. In questo contesto i pr<strong>in</strong>cipali costruttori e i pr<strong>in</strong>cipali<br />

o<strong>per</strong>atori di telecomunicazioni si stanno focalizzando sul<strong>la</strong> Ethernet nativa come<br />

soluzione primaria <strong>per</strong> l’<strong>in</strong>frastruttura <strong>del</strong><strong>la</strong> rete di accesso metropolitana <strong>per</strong><br />

fornire al<strong>la</strong> cliente<strong>la</strong> f<strong>in</strong>ale servizi di connessione Ethernet dedicati e/o condivisi.<br />

Ethernet è una tecnologia nata <strong>per</strong> le <strong>reti</strong> locali di computer, qu<strong>in</strong>di <strong>per</strong> consentire<br />

lo scambio diretto di dati <strong>in</strong> formato elettronico tra più di due computer. La natura<br />

generale di qualsiasi Local Area Network, e quel<strong>la</strong> di Ethernet <strong>in</strong> partico<strong>la</strong>re, è di<br />

consentire il libero colloquio con qualsiasi macch<strong>in</strong>a collegata e di trasmettere le


__________________________________________________________________<br />

stesse <strong>in</strong>formazione contemporaneamente a tutte le macch<strong>in</strong>e <strong>in</strong> ascolto<br />

(broadcast<strong>in</strong>g).<br />

Ethernet non è necessariamente <strong>la</strong> migliore <strong>del</strong>le tecnologie possibili, ma si è<br />

dimostrata <strong>la</strong> più economica e <strong>la</strong> più facile da utilizzare il che ne ha decretato un<br />

enorme successo a tutti i livelli d'impiego e <strong>in</strong> qualsiasi area geografica <strong>del</strong><br />

mondo. La tecnologia Ethernet fu sviluppata da tre società, Digital, Intel, Xerox.<br />

Successivamente, considerando le potenzialità di diffusione mondiale <strong>la</strong> sua<br />

standardizzazione fu affidata ad un ente al di sopra <strong>del</strong>le parti, all’ Institute of<br />

Electrical and Electronics Eng<strong>in</strong>eers (IEEE), un ente statunitense con sede a New<br />

York che riunisce scienziati, <strong>in</strong>gegneri e studenti e che nel<strong>la</strong> prima metà degli anni<br />

Ottanta creò un comitato, identificato dal<strong>la</strong> sig<strong>la</strong> IEEE 802, il cui compito è di<br />

codificare tutti i tipi primari di rete locale, <strong>in</strong>cluso naturalmente Ethernet. Lo<br />

standard Ethernet è l’IEEE 802.3, <strong>in</strong> cui <strong>in</strong>izialmente si def<strong>in</strong>irono le specifiche<br />

elettriche e fisiche <strong>per</strong> una rete Ethernet a 10 Mbit/s su cavo coassiale.<br />

Successivamente lo standard è stato ampliato e <strong>per</strong>fezionato a più riprese,<br />

com<strong>in</strong>ciando dal 1985 con <strong>la</strong> def<strong>in</strong>izione <strong>del</strong> metodo di accesso e proseguendo,<br />

poi, con l'aggiunta di versioni capaci di funzionare anche su cavi di tipo<br />

differente, coassiali, dopp<strong>in</strong>i multipli e fibra ottica, e a velocità diverse, 100<br />

Megabit/s, 1 Gigabit/s e 10Gigabit/s. Per identificare un’<strong>in</strong>terfaccia Ethernet, si<br />

utilizza un sistema di sigle dove il primo numero <strong>in</strong>dica <strong>la</strong> velocità <strong>in</strong> megabit (10,<br />

100, 1000, 10Giga), segue una sig<strong>la</strong> alfanumerica <strong>per</strong> identificare il tipo di mezzo<br />

(Base T <strong>per</strong> dopp<strong>in</strong>i <strong>in</strong> rame, Base SX, Base LX, Base LH, Base ZX <strong>per</strong> fibra<br />

ottica e distanze crescenti).<br />

Ethernet usa un solo cavo <strong>per</strong> collegare dec<strong>in</strong>e di stazioni di <strong>la</strong>voro, ciascuna <strong>del</strong>le<br />

quali riceve contemporaneamente tutto quel che passa sul<strong>la</strong> rete, mentre solo una<br />

stazione al<strong>la</strong> volta ha <strong>la</strong> facoltà di trasmettere. Ogni stazione è <strong>in</strong>dipendente e non<br />

esiste una s<strong>in</strong>go<strong>la</strong> entità che funzioni da arbitro. Per <strong>in</strong>ciso, esiste anche una<br />

partico<strong>la</strong>re versione di Ethernet che consente <strong>la</strong> trasmissione contemporanea da<br />

diverse stazioni multiple, usando canali separati che occupano<br />

contemporaneamente lo stesso cavo coassiale, seguendo un approccio analogo a<br />

quello usato <strong>per</strong> <strong>la</strong> televisione via cavo. In tal caso si par<strong>la</strong> di Ethernet broadband<br />

(a banda <strong>la</strong>rga) e ogni scheda di rete deve montare speciali modem ad alta<br />

34


__________________________________________________________________<br />

frequenza <strong>per</strong> trasmettere e ricevere sul cavo. Viene usata molto di rado e solo <strong>in</strong><br />

ambienti partico<strong>la</strong>ri, <strong>in</strong> ragione <strong>del</strong>l'elevato costo <strong>del</strong>le schede. Tornando<br />

all'Ethernet convenzionale, vediamo che le <strong>in</strong>formazioni sono trasmesse nel<strong>la</strong><br />

forma d'impulsi che si propagano a partire dal<strong>la</strong> stazione emittente verso i due<br />

estremi <strong>del</strong><strong>la</strong> rete (a destra e a s<strong>in</strong>istra) f<strong>in</strong>o a raggiungere il punto <strong>in</strong> cui il cavo<br />

term<strong>in</strong>a ai due estremi. In questo <strong>per</strong>corso <strong>in</strong>contrano altri nodi che sono collegati<br />

lungo il cavo e che ascoltano tutto quello che passa cercando di scoprire se è<br />

<strong>in</strong>dirizzato a loro. Ogni messaggio <strong>in</strong> transito sul<strong>la</strong> rete (detto anche trama o<br />

frame, all'<strong>in</strong>glese, <strong>per</strong>ché composto da una sequenza di bit tra loro comb<strong>in</strong>ati) reca<br />

al proprio <strong>in</strong>terno l'<strong>in</strong>dirizzo di orig<strong>in</strong>e e quello di dest<strong>in</strong>azione, <strong>per</strong>ciò ogni<br />

macch<strong>in</strong>a lo copia <strong>in</strong> una picco<strong>la</strong> porzione di memoria (buffer) di cui dispone<br />

nel<strong>la</strong> scheda d'<strong>in</strong>terfaccia, legge l'<strong>in</strong>dirizzo di dest<strong>in</strong>azione e, se non co<strong>in</strong>cide con<br />

il proprio, lo scarta.<br />

Figura 0.1 : Trama Ethernet<br />

Con questo meccanismo, assicurandosi che una so<strong>la</strong> macch<strong>in</strong>a al<strong>la</strong> volta abbia <strong>la</strong><br />

possibilità di trasmettere mentre tutte le altre sono <strong>in</strong> ascolto, si costruisce <strong>in</strong><br />

modo semplice una rete a cui è facile aggiungere nodi, visto che ogni nuovo nodo<br />

riceve automaticamente tutto quel che transita sul cavo e diventa immediatamente<br />

parte <strong>del</strong> gruppo di <strong>la</strong>voro, acquistando anche <strong>la</strong> facoltà di trasmettere ogni volta<br />

che <strong>la</strong> l<strong>in</strong>ea è libera. Questo sistema vale <strong>per</strong> qualsiasi genere di rete Ethernet,<br />

<strong>in</strong>dipendentemente dal<strong>la</strong> sua velocità di funzionamento o dal tipo di cavo<br />

utilizzato. Ogni scheda di rete disponibile <strong>in</strong> commercio dispone di un proprio<br />

35


__________________________________________________________________<br />

<strong>in</strong>dirizzo <strong>per</strong>manente, detto MAC address, unico al mondo, espresso <strong>in</strong> numeri<br />

esadecimali e lungo 48 bit. I primi 24 bit di questo <strong>in</strong>dirizzo <strong>in</strong>dicano il costruttore<br />

e vengono conservati <strong>in</strong> un registro mondiale così da evitare duplicazioni. Gli altri<br />

24 bit vengono assegnati dal costruttore medesimo, scheda <strong>per</strong> scheda, così da<br />

creare una comb<strong>in</strong>azione univoca <strong>per</strong> ciascun pezzo. Grazie a questo metodo, è<br />

possibile risalire <strong>in</strong> ogni momento a chi ha fabbricato <strong>la</strong> scheda e non esiste <strong>la</strong><br />

benché m<strong>in</strong>ima possibilità che sul<strong>la</strong> stessa rete esistano due nodi con il medesimo<br />

<strong>in</strong>dirizzo fisico.<br />

La connessione di varie macch<strong>in</strong>e sullo stesso cavo prende il nome di topologia<br />

elettrica a "bus" <strong>in</strong> quanto tutti i dispositivi sono collegati al medesimo <strong>per</strong>corso di<br />

trasmissione e ricevono contemporaneamente lo stesso segnale. Nelle prime <strong>reti</strong><br />

Ethernet <strong>la</strong> topologia elettrica corrispondeva anche al<strong>la</strong> topologia fisica, cioè al<br />

modo <strong>in</strong> cui fisicamente le varie stazioni venivano collegate tra loro.<br />

Successivamente, con l'adozione <strong>del</strong> dopp<strong>in</strong>o, si è mantenuto una topologia<br />

elettrica a bus (elemento <strong>in</strong>variabile nel<strong>la</strong> natura di Ethernet), ma <strong>la</strong> topologia<br />

fisica, cioè il modo <strong>in</strong> cui i cavi vengono distribuiti, è diventata una stel<strong>la</strong>: tutte le<br />

macch<strong>in</strong>e si collegano a un punto centrale.<br />

Figura 0.2 : Esempi di topologie fisiche<br />

Qualunque sia <strong>la</strong> topologia fisica e qualunque sia <strong>la</strong> velocità, <strong>la</strong> tecnica di<br />

trasmissione su rame rimane <strong>in</strong>variata e consiste nel trasmettere un segnale,<br />

un'onda quadra, che oscil<strong>la</strong> tra valori di tensione negativi e positivi e ogni<br />

transizione (da negativo a positivo o viceversa) <strong>in</strong>dica <strong>la</strong> presenza di una cifra<br />

b<strong>in</strong>aria, rispettivamente 1 e 0. Questo sistema prende il nome di codifica di<br />

Manchester e ha il vantaggio di rendere molto più sicuro il riconoscimento degli 1<br />

e degli 0 visto che non si misura l'ampiezza <strong>del</strong>l'impulso ma si usa l'<strong>in</strong>versione di<br />

36


__________________________________________________________________<br />

po<strong>la</strong>rità, facilmente riconoscibile anche <strong>in</strong> caso di presenza di disturbi. Inoltre,<br />

oltre a convogliare le <strong>in</strong>formazioni digitali, questo genere di codifica fornisce <strong>la</strong><br />

s<strong>in</strong>cronizzazione <strong>per</strong> tutte le <strong>in</strong>terfacce collegate al<strong>la</strong> rete.<br />

2.3 IL MECCANISMO DI ACCESSO CSMA/CD<br />

Nel<strong>la</strong> rete Ethernet non esiste un arbitro degli accessi bensì un meccanismo <strong>in</strong><br />

base al quale le s<strong>in</strong>gole stazioni di <strong>la</strong>voro si "autodiscipl<strong>in</strong>ano", astenendosi dal<br />

trasmettere quando qualcun'altra lo sta già facendo. Tecnicamente questo sistema<br />

prende il nome di CSMA/CD (Carrier Sense Multiple Access/Collision Detection<br />

- accesso multiplo a rilevazione di portante con segna<strong>la</strong>zione di collisione).<br />

Interpretando il significato di questa sig<strong>la</strong> si comprende anche l'anatomia <strong>del</strong><br />

meccanismo. La prima azione che qualsiasi <strong>in</strong>terfaccia esegue prima d'<strong>in</strong>iziare a<br />

trasmettere consiste nell'ascoltare se qualcuno lo sta già facendo, questa è <strong>la</strong><br />

rilevazione <strong>del</strong><strong>la</strong> portante. Nel caso di un sistema ad <strong>in</strong>terfacce Ethernet 10BaseT,<br />

se qualcuno sta trasmettendo, sul cavo sarà presente un segnale a 20 MHz su cui<br />

viaggiano 10 Mbit <strong>per</strong> secondo (codificati con il sistema di Manchester). In caso<br />

di "occupato" <strong>la</strong> work-station desiste e tenta di ritrasmettere più tardi. L'accesso<br />

al<strong>la</strong> rete è multiplo, <strong>per</strong>ciò tutte le stazioni hanno <strong>la</strong> stessa facoltà di par<strong>la</strong>re a<br />

condizione di accertarsi prima che <strong>la</strong> l<strong>in</strong>ea sia libera, o<strong>per</strong>azione che possono<br />

eseguire tutte <strong>in</strong> contemporanea. Supponiamo, a questo punto, che due stazioni<br />

siano pronte a trasmettere e che abbiano trovato <strong>la</strong> l<strong>in</strong>ea libera. La trasmissione<br />

parte nello stesso momento e quel<strong>la</strong> <strong>del</strong><strong>la</strong> prima <strong>in</strong>evitabilmente collide con quel<strong>la</strong><br />

<strong>del</strong><strong>la</strong> seconda provocando <strong>la</strong> sovrapposizione dei due segnali elettrici sul<strong>la</strong> l<strong>in</strong>ea e<br />

l'impossibilità di riconoscere i bit che vi erano contenuti. Se non esistesse nessun<br />

sistema che segna<strong>la</strong>sse l'avvenuta collisione, le due stazioni cont<strong>in</strong>uerebbero a<br />

trasmettere i rispettivi messaggi <strong>per</strong> <strong>in</strong>tero, nel<strong>la</strong> conv<strong>in</strong>zione che questi<br />

arriveranno a buon f<strong>in</strong>e.<br />

Per questo motivo si è previsto nel<strong>la</strong> <strong>in</strong>terfaccia un ulteriore circuito che rimane<br />

sempre <strong>in</strong> ascolto, anche quando <strong>la</strong> scheda d’<strong>in</strong>terfaccia medesima sta<br />

trasmettendo, <strong>per</strong> verificare che non siano avvenute collisioni. Il circuito deve<br />

37


__________________________________________________________________<br />

verificare <strong>la</strong> presenza sul<strong>la</strong> l<strong>in</strong>ea di valori di tensione su<strong>per</strong>iori al<strong>la</strong> norma. In caso<br />

di collisione, <strong>in</strong>fatti, i segnali elettrici <strong>del</strong>le due stazioni si mesco<strong>la</strong>no e f<strong>in</strong>iscono<br />

anche <strong>per</strong> sommarsi, <strong>per</strong>ciò <strong>la</strong> tensione risultante che circo<strong>la</strong> <strong>in</strong> rete è maggiore.<br />

Non appena <strong>la</strong> collisione viene rilevata, le schede d'<strong>in</strong>terfaccia di entrambe le<br />

stazioni non <strong>in</strong>terrompono immediatamente <strong>la</strong> trasmissione, ma cont<strong>in</strong>uano a<br />

<strong>in</strong>viare bit f<strong>in</strong>o a raggiungere <strong>la</strong> dimensione m<strong>in</strong>ima di un pacchetto di 64 Byte.<br />

Questo <strong>per</strong> fare <strong>in</strong> modo che anche tutte le altre macch<strong>in</strong>e sul<strong>la</strong> rete si accorgano<br />

che <strong>la</strong> collisione è <strong>in</strong> corso e che <strong>la</strong> rete è momentaneamente bloccata. Dopo di<br />

che <strong>in</strong>terrompono <strong>la</strong> trasmissione e attivano un timer di durata casuale prima di<br />

ritentare <strong>la</strong> trasmissione. Il fatto che il timer sia casuale impedisce che entrambe<br />

ripartano nello stesso istante, causando una nuova collisione. Se, nonostante l'uso<br />

dei timer, <strong>la</strong> collisione si verificasse ancora, il timer verrebbe allungato<br />

progressivamente f<strong>in</strong>o a un punto <strong>in</strong> cui il cont<strong>in</strong>uare <strong>del</strong>le collisioni <strong>in</strong>dicherebbe<br />

un guasto fisico sul<strong>la</strong> rete e le s<strong>in</strong>gole schede d'<strong>in</strong>terfaccia comunicherebbero al<br />

rispettivo computer l'impossibilità di trasmettere.<br />

Nel<strong>la</strong> realtà le collisioni sono più frequenti di quello che a prima vista potrebbe<br />

sembrare. Infatti, oltre al caso fortuito visto prima di due stazioni che trasmettono<br />

esattamente nello stesso momento, esistono anche altri casi <strong>in</strong> cui due o più<br />

macch<strong>in</strong>e cercano di prendere possesso <strong>del</strong><strong>la</strong> l<strong>in</strong>ea con <strong>la</strong> conv<strong>in</strong>zione che sia<br />

libera, quando questa <strong>in</strong> realtà non lo è, e c'è già qualcun altro che ha com<strong>in</strong>ciato a<br />

trasmettere.<br />

Per capire come questo possa accadere dobbiamo par<strong>la</strong>re di tempi: al<strong>la</strong> velocità di<br />

10 Mbit <strong>per</strong> secondo ci vogliono 100 nanosecondi <strong>per</strong> <strong>in</strong>viare un s<strong>in</strong>golo bit.<br />

Trattandosi di un impulso elettrico che viaggia al<strong>la</strong> velocità <strong>del</strong><strong>la</strong> luce, <strong>la</strong><br />

propagazione non è istantanea anche se molto veloce. Si verifica quello che <strong>in</strong><br />

term<strong>in</strong>i tecnici si chiama "ritardo di propagazione". Ci vuole circa un<br />

nanosecondo <strong>per</strong> <strong>per</strong>correre 30 centimetri e, prima che il secondo bit sia uscito<br />

dal<strong>la</strong> scheda di rete che sta trasmettendo, il primo bit ha circa trenta metri di<br />

vantaggio. Le <strong>reti</strong> Ethernet hanno lunghezze di cent<strong>in</strong>aia di metri <strong>per</strong>ciò può<br />

benissimo accadere che una seconda stazione, diciamo a 90 di metri distanza dal<strong>la</strong><br />

prima, ascolti <strong>la</strong> l<strong>in</strong>ea nel momento <strong>in</strong> cui <strong>la</strong> prima ha <strong>in</strong>iziato a trasmettere e <strong>la</strong><br />

trovi comunque libera, visto che il primo bit non è ancora arrivato f<strong>in</strong>o a lei. In tal<br />

38


__________________________________________________________________<br />

caso <strong>la</strong> seconda stazione <strong>in</strong>izierebbe <strong>la</strong> propria trasmissione e quasi subito si<br />

troverebbe co<strong>in</strong>volta <strong>in</strong> una collisione. Anzi, anche una terza stazione, ancora più<br />

distante, potrebbe partire nel frattempo e provocare un vero e proprio<br />

"tamponamento a catena". Questo ci fa capire <strong>per</strong> quale motivo, al crescere <strong>del</strong><br />

numero di stazioni presenti sul<strong>la</strong> rete, aumenti anche il numero di collisioni e ci<br />

spiega anche <strong>per</strong>ché una rete Ethernet non possa su<strong>per</strong>are una certa lunghezza. Il<br />

problema viene ulteriormente complicato dal fatto che, mentre <strong>la</strong> seconda e <strong>la</strong><br />

terza stazione si accorgono <strong>del</strong><strong>la</strong> collisione quasi immediatamente, <strong>la</strong> prima non se<br />

ne rende conto f<strong>in</strong>o a quando il segnale di collisione rimbalza <strong>in</strong>dietro lungo <strong>la</strong><br />

rete e ritorna f<strong>in</strong>o a lei. Qu<strong>in</strong>di si aggiungono ulteriori tempi morti <strong>per</strong>ché, come<br />

abbiamo visto prima, bisogna cont<strong>in</strong>uare a trasmettere almeno 64 Byte anche <strong>in</strong><br />

caso di collisione, così da far proseguire <strong>la</strong> collisione abbastanza a lungo da<br />

consentire a tutte le stazioni co<strong>in</strong>volte di accorgersene. La quantità di Byte da<br />

trasmettere è legata al tempo che il segnale elettrico impiega <strong>per</strong> completare un<br />

viaggio di andata e ritorno (round trip) sull'<strong>in</strong>tera rete. Per l'Ethernet a 10 Mbps,<br />

10BaseX, le specifiche dicono che, qualunque sia il tipo di cavo utilizzato, un<br />

s<strong>in</strong>golo bit non deve impiegare più di 50 µs <strong>per</strong> coprire l'<strong>in</strong>tera lunghezza <strong>del</strong><strong>la</strong><br />

rete nei due sensi, il che equivale a trasmettere 500 bit, cioè 62,5 Byte, arrotondati<br />

a 64. Da questi parametri di partenza deriva una serie di v<strong>in</strong>coli di lunghezza <strong>del</strong><br />

cavo, di numero massimo <strong>del</strong>le stazioni <strong>per</strong> tratta di cavo e di numero massimo di<br />

ripetitori. Questi v<strong>in</strong>coli cambiano <strong>per</strong> i vari tipi di Ethernet. Per estendere il<br />

limite <strong>del</strong><strong>la</strong> rete oltre il valore di 50 µs , <strong>per</strong> l'andata e ritorno, è necessario creare<br />

una seconda rete e collegar<strong>la</strong> al<strong>la</strong> prima attraverso un dispositivo "ponte"<br />

(chiamato bridge) che memorizza ogni messaggio <strong>in</strong> arrivo da una parte e lo<br />

ritrasmette al<strong>la</strong> rete successiva solo se è dest<strong>in</strong>ato a questa, oppure lo scarta se si<br />

tratta di un messaggio che deve rimanere all'<strong>in</strong>terno <strong>del</strong><strong>la</strong> prima rete. Così facendo<br />

si sv<strong>in</strong>co<strong>la</strong>no le temporizzazioni <strong>del</strong><strong>la</strong> prima rete (che dal punto di vista <strong>del</strong> bridge<br />

diventa un "segmento") dal<strong>la</strong> temporizzazione <strong>del</strong><strong>la</strong> seconda. Inoltre così facendo<br />

si riduce il traffico generale e le collisioni, visto che si evita il propagarsi di<br />

traffico <strong>in</strong>utile tra le due.<br />

39


__________________________________________________________________<br />

2.4 IL DOMINIO DI COLLISIONE<br />

Ethernet si è evoluta moltissimo negli ultimi dodici anni <strong>per</strong>ciò era <strong>in</strong>evitabile che<br />

alcuni dei suoi term<strong>in</strong>i orig<strong>in</strong>ali cambiassero significato oppure che scomparissero<br />

dall'uso comune. Esistono <strong>in</strong> effetti numerosi term<strong>in</strong>i che ricorrono nei vari<br />

standard, ma che qui non abbiamo neanche citato <strong>per</strong>ché ormai sostituiti da parole<br />

più semplici oppure semplicemente non più usati. La paro<strong>la</strong> "segmento"<br />

costituisce un caso partico<strong>la</strong>re, poiché, col tempo, ha ampliato il proprio<br />

significato <strong>per</strong> abbracciare cose nuove senza abbandonare al contempo le vecchie,<br />

<strong>per</strong>ciò cambia sfumatura a seconda <strong>del</strong> contesto <strong>in</strong> cui viene impiegata e può<br />

<strong>in</strong>durre <strong>in</strong> confusione non avendo conf<strong>in</strong>i ben <strong>del</strong>imitati.<br />

Le prime <strong>reti</strong> Ethernet funzionavano su cavo coassiale (10Base-5 e 10Base-2) e<br />

identificavano nel segmento <strong>la</strong> tratta di coassiale che costituiva un s<strong>in</strong>golo<br />

<strong>per</strong>corso elettrico non <strong>in</strong>terrotto, un s<strong>in</strong>golo lungo pezzo di cavo, chiuso alle due<br />

estremità dai term<strong>in</strong>atori. Quando si aggiungeva un ripetitore, si al<strong>la</strong>rgava <strong>la</strong> rete<br />

creando un secondo segmento, f<strong>in</strong>o a un massimo di c<strong>in</strong>que segmenti, di cui due<br />

riservati unicamente all'<strong>in</strong>terconnessione di ripetitori (segmenti di collegamento) e<br />

tre capaci di ospitare nodi (stazioni di <strong>la</strong>voro, server, eccetera) al loro <strong>in</strong>terno<br />

(segmenti popo<strong>la</strong>ti).<br />

I ripetitori erano oggetti costosi e venivano usati solo <strong>in</strong> <strong>reti</strong> di grandi dimensioni.<br />

Spesso, soprattutto con le <strong>reti</strong> su coassiale sottile, esisteva un solo segmento e<br />

questo veniva di fatto identificato con l'<strong>in</strong>tera rete e con il traffico che vi<br />

circo<strong>la</strong>va. Perciò il concetto si estese all'<strong>in</strong>sieme <strong>del</strong>le stazioni collegate tra loro<br />

da un <strong>per</strong>corso elettrico <strong>in</strong><strong>in</strong>terrotto con tutto il traffico re<strong>la</strong>tivo. Con l'avvento<br />

<strong>del</strong>le <strong>reti</strong> su dopp<strong>in</strong>o, il segmento, nel<strong>la</strong> def<strong>in</strong>izione orig<strong>in</strong>ale, f<strong>in</strong>isce <strong>per</strong> essere<br />

composto solo da due nodi: da una parte l’apparato (stazione di <strong>la</strong>voro, server o<br />

stampante) e dall'altra <strong>la</strong> porta <strong>del</strong> concentratore. In partico<strong>la</strong>re ogni concentratore,<br />

o HUB, funziona da ripetitore nei confronti di ciascuna porta <strong>per</strong>ciò, quello che<br />

una volta era molto costoso e usato solo <strong>in</strong> casi partico<strong>la</strong>ri adesso diventa talmente<br />

comune da trovare un ripetitore <strong>per</strong> ogni s<strong>in</strong>go<strong>la</strong> stazione collegata. Perciò, benché<br />

nelle <strong>reti</strong> 10Base-T sia sempre necessario usare <strong>la</strong> def<strong>in</strong>izione orig<strong>in</strong>ale di<br />

segmento al f<strong>in</strong>e di avere uniformità con gli altri standard 10Base-X, cioè tratto il<br />

40


__________________________________________________________________<br />

cavo elettricamente <strong>in</strong><strong>in</strong>terrotto che collega i nodi, l'abitud<strong>in</strong>e <strong>del</strong> recente passato<br />

ci porta ad associare al segmento l'idea di numerosi nodi e qu<strong>in</strong>di ad estenderne il<br />

significato f<strong>in</strong>o a coprire l'<strong>in</strong>tero dom<strong>in</strong>io di collisione.<br />

Ogni s<strong>in</strong>go<strong>la</strong> macch<strong>in</strong>a collegata al<strong>la</strong> rete 10Base-T costituisce un segmento<br />

elettrico a sé stante, ma fa parte di un s<strong>in</strong>golo dom<strong>in</strong>io di collisione che unisce a<br />

tutte le altre macch<strong>in</strong>e collegate allo stesso hub e tutti gli altri hub e le re<strong>la</strong>tive<br />

macch<strong>in</strong>e dei rimanenti quattro segmenti <strong>in</strong> cascata. Il dom<strong>in</strong>io di collisione<br />

unifica tutti i segmenti <strong>del</strong><strong>la</strong> rete e tutti i ripetitori <strong>per</strong> il fatto che questi ultimi si<br />

limitano ad amplificare il segnale di modo che possa proseguire nel segmento<br />

successivo, amplificando allo stesso modo anche le collisioni. Qu<strong>in</strong>di, tutte le<br />

macch<strong>in</strong>e collegate allo stesso dom<strong>in</strong>io di collisione condividono non solo il<br />

medesimo traffico ma anche le stesse collisioni, <strong>in</strong>dipendentemente da quale sia il<br />

concentratore a cui sono collegate. Chiunque colleghi almeno due macch<strong>in</strong>e a un<br />

hub 10Base-T ha creato un dom<strong>in</strong>io di collisione composto da due segmenti, e le<br />

sue dimensioni aumentano con l'aggiunta di altre connessioni.<br />

Sfortunatamente <strong>la</strong> paro<strong>la</strong> "dom<strong>in</strong>io di collisione" è alquanto roboante e non è<br />

molto pratica da usare, <strong>per</strong>ciò è caduta <strong>in</strong> disuso e lo stesso è accaduto ai<br />

segmenti. Si è com<strong>in</strong>ciato a par<strong>la</strong>re <strong>in</strong> generale di "rete" riferendosi all'<strong>in</strong>sieme<br />

<strong>del</strong>le macch<strong>in</strong>e legate tra loro dai vari hub. Tutto è andato bene f<strong>in</strong>o a che queste<br />

<strong>reti</strong> sono cresciute al punto da portare le collisioni a livelli vertig<strong>in</strong>osi<br />

compromettendone il funzionamento. Allora si è deciso di "segmentarle" vale a<br />

dire di suddividerle <strong>in</strong> diversi dom<strong>in</strong>i di collisione usando un altro oggetto, più<br />

sofisticato e costoso di un ripetitore, che funge da ponte tra i due dom<strong>in</strong>i,<br />

<strong>la</strong>sciando passare solo il traffico <strong>in</strong>crociato e filtrando tutte le collisioni e tutto il<br />

traffico che deve rimanere all'<strong>in</strong>terno di un solo dom<strong>in</strong>io di collisione, alias<br />

segmento. Questo genere di apparecchiatura prende il nome di bridge e non solo<br />

svolge le funzioni di ripetitore, ma memorizza e filtra tutti i messaggi <strong>in</strong> transito<br />

facendo passare solo quelli che sono effettivamente diretti al segmento dall'altra<br />

parte.<br />

Oggi <strong>la</strong> paro<strong>la</strong> segmento è pronta <strong>per</strong> una nuova ri<strong>valutazione</strong> e <strong>per</strong> sostituire un<br />

qualche altro "dom<strong>in</strong>io" di fascia più alta che nel frattempo si sia costituito. Infatti<br />

il bridge, da pr<strong>in</strong>cipio, era un'apparecchiatura abbastanza costosa. Si trattava di un<br />

41


__________________________________________________________________<br />

vero e proprio computer che svolgeva il <strong>la</strong>voro di filtro via software. Col tempo,<br />

<strong>la</strong> tecnologia elettronica è progredita al punto che le funzioni software sono state<br />

registrate <strong>per</strong>manentemente <strong>in</strong> circuiti hardware dedicati a svolgere esplicitamente<br />

questa funzione e <strong>per</strong>ciò molto veloci oltre che re<strong>la</strong>tivamente economici. Sono<br />

nati così gli switch (commutatori) che altro non sono che tanti bridge<br />

m<strong>in</strong>iaturizzati e completamente <strong>in</strong>tegrati <strong>in</strong> hardware, ciascuno assegnato a una<br />

porta <strong>in</strong>dividuale <strong>del</strong>lo switch. A questa porta si può collegare un <strong>in</strong>tero segmento<br />

Ethernet (dom<strong>in</strong>io di collisione) oppure una s<strong>in</strong>go<strong>la</strong> stazione. In questo ultimo<br />

caso <strong>la</strong> s<strong>in</strong>go<strong>la</strong> stazione può usare tutta <strong>la</strong> l<strong>in</strong>ea (10 o 100 Mbps) <strong>per</strong> sé senza il<br />

rischio d'<strong>in</strong>correre <strong>in</strong> collisioni, salvo quelle dovute accidentalmente a disturbi<br />

<strong>in</strong>contrati sul<strong>la</strong> l<strong>in</strong>ea. In tal modo l'efficienza si sp<strong>in</strong>ge f<strong>in</strong>o al<strong>la</strong> quasi totalità <strong>del</strong><strong>la</strong><br />

capacità di trasmissione teorica <strong>del</strong><strong>la</strong> rete Ethernet. Gli switch sono ancora<br />

re<strong>la</strong>tivamente costosi, ma il prezzo scende rapidamente e quando sarà sceso a<br />

sufficienza da diventare di uso comune, "segmento" probabilmente cambierà<br />

ancora una volta il proprio significato.<br />

2.5 DALLE LAN ALLE MAN: SWITCHING ETHERNET<br />

Perchè potesse assumere il ruolo di tecnologia unificante multiservizio, e qu<strong>in</strong>di<br />

poter realizzare tutte le funzioni <strong>del</strong> trasporto (trasmissione, commutazione,<br />

gestione, ecc) <strong>per</strong> servizi come <strong>la</strong> fonia, <strong>la</strong> videocomunicazione, il video on<br />

demand, lo standard Ethernet orig<strong>in</strong>ario è stato modificato. In partico<strong>la</strong>re, tramite<br />

gli standards IEEE 802.1p/q, sono state aggiunte le funzionalità necessarie <strong>per</strong><br />

suddividere e sottocanalizzare il flusso trasmissivo <strong>in</strong> una molteplicità di<br />

connessioni logiche denom<strong>in</strong>ate Virtual LAN (VLAN), ciascuna con le proprie<br />

opzioni di prestazioni QoS. Queste funzioni sono basate su etichettatura (tagg<strong>in</strong>g)<br />

<strong>del</strong>le trame fatta con l’aggiunta di un campo di quattro byte all’header MAC<br />

(Medium Access Control) <strong>del</strong>le trame Ethernet tradizionali. Il campo aggiunto, o<br />

tag, è fatto come <strong>in</strong>dicato <strong>in</strong><br />

Figura 0.3; esso è utilizzato <strong>per</strong> identificare i flussi di traffico (VLAN identifier-<br />

ID) e <strong>per</strong> stabilire differenti c<strong>la</strong>ssi di servizio (C<strong>la</strong>ss Of Services, COS), cioè<br />

differenti priorità con cui i flussi re<strong>la</strong>tivi a tali c<strong>la</strong>ssi devono essere trattati <strong>in</strong> rete.<br />

42


__________________________________________________________________<br />

INDIRIZZO DI<br />

DESTINAZIO<br />

NE 6 BYTE<br />

INDIRIZZO DI<br />

SORGENTE<br />

6 BYTE<br />

CAMPO DI<br />

CONTROLL<br />

4 BYTE<br />

TIPO/<br />

LUNG.<br />

2 BYTE<br />

PAYLOAD<br />

N BYTE<br />

FCS<br />

TIPO DI TRAMA<br />

TAGGATA 2<br />

PRIORITA’<br />

3BIT<br />

CANONIC<br />

O<br />

VLAN ID<br />

12 BIT<br />

Figura 0.3: Composizione <strong>del</strong> campo di controllo IEEE 802.1p/q nell’header Ethernet.<br />

Il campo VLAN ID è di 12 bit e consente qu<strong>in</strong>di l’identificazione, su uno stesso<br />

flusso trasmissivo, di 4096 VLAN, ciascuna <strong>del</strong>le quali può essere associata a un<br />

cliente o a specifici servizi dei vari clienti. Il campo “Priorità” è costituito da tre<br />

bit consentendo qu<strong>in</strong>di f<strong>in</strong>o a otto differenti COS. Questo <strong>per</strong>mette agli o<strong>per</strong>atori<br />

di offrire una grande varietà di servizi e di <strong>per</strong>sonalizzare l’offerta degli stessi ai<br />

vari clienti; <strong>in</strong>fatti su ciascuna VLAN, si possono applicare differenti politiche di<br />

QoS, di shap<strong>in</strong>g <strong>del</strong><strong>la</strong> banda, di filtraggio dei flussi, ecc., come schematicamente<br />

<strong>in</strong>dicato <strong>in</strong> Figura 0.4.<br />

Per quanto concerne <strong>la</strong> QoS nelle norme IEEE si def<strong>in</strong>iscono quattro c<strong>la</strong>ssi di<br />

servizio, ciascuna con uno specifico <strong>in</strong>sieme di prestazioni e tipo di trattamento<br />

dei pacchetti nei nodi di rete.<br />

La tecnologia <strong>del</strong>le VLAN, realizzate <strong>in</strong> conformità allo standard IEEE 802.1q,<br />

costituisce dunque <strong>la</strong> base <strong>per</strong> realizzare una MAN con Ethernet switch<strong>in</strong>g. La<br />

MAN <strong>in</strong> questo caso è costituita da nodi di tipo Switch Ethernet <strong>in</strong>terconnessi o<br />

con topologia ad anello o a maglia. In questa struttura si usa il protocollo IP come<br />

piano di controllo e le VLAN nel piano <strong>del</strong> trasporto (forward<strong>in</strong>g) <strong>del</strong> traffico.<br />

La topologia ad anello o a maglia è scelta <strong>in</strong> re<strong>la</strong>zione al meccanismo di<br />

protezione attuato dagli switch; quel<strong>la</strong> più comune è <strong>la</strong> topologia ad anello con<br />

protezione basata sul protocollo Spann<strong>in</strong>g Tree. Il protocollo STP (Spann<strong>in</strong>g Tree<br />

Protocol) è utilizzato dagli switch di livello 2 <strong>per</strong> ricavare una topologia priva di<br />

43


__________________________________________________________________<br />

loop a partire da un struttura di rete generalmente magliata. Prendendo come<br />

riferimento uno degli switch (root bridge), tramite lo scambio di opportuni<br />

pacchetti <strong>in</strong>formativi (Bridge Protocol Data Unit), ciascuno switch pone alcune<br />

<strong>in</strong>terfacce <strong>in</strong> stato di blocco <strong>in</strong> modo da elim<strong>in</strong>are i loop e costruire una topologia<br />

ad albero. Nel caso <strong>in</strong> cui uno dei l<strong>in</strong>k attivi diventi <strong>in</strong>disponibile, l’algoritmo STP<br />

viene eseguito di nuovo <strong>per</strong> tentare di riprist<strong>in</strong>are <strong>la</strong> connettività; tale processo<br />

può eventualmente provocare <strong>per</strong> qualche l<strong>in</strong>k <strong>la</strong> transizione dallo stato di blocco<br />

a quello di esercizio normale (forward<strong>in</strong>g).<br />

In effetti quel<strong>la</strong> <strong>del</strong><strong>la</strong> protezione da guasti di rete e dei re<strong>la</strong>tivi meccanismi di<br />

riconfigurazione e riprist<strong>in</strong>o <strong>del</strong> traffico costituisce uno dei pr<strong>in</strong>cipali problemi<br />

ancora a<strong>per</strong>ti <strong>per</strong> le <strong>reti</strong> geografiche basate su Ethernet. Infatti il protocollo<br />

Ethernet Spann<strong>in</strong>g Tree, sulle topologie di rete ad anello presenta tipicamente un<br />

tempo di convergenza di circa 1 secondo; <strong>per</strong> altre topologie e <strong>in</strong> partico<strong>la</strong>re <strong>per</strong><br />

<strong>reti</strong> magliate, i tempi di convergenza possono essere ben su<strong>per</strong>iori e non essere<br />

adeguati <strong>per</strong> <strong>reti</strong> pubbliche. Anche il Rapid Spann<strong>in</strong>g Tree presenta tempi ben più<br />

lunghi dei 50 ms, tipici dei sistemi SDH, che sono ormai presi come riferimento<br />

nelle <strong>reti</strong> pubbliche di telecomunicazioni.<br />

Come <strong>per</strong> molti altri aspetti <strong>del</strong>le <strong>reti</strong> Ethernet, esistono diverse soluzioni<br />

proprietarie <strong>per</strong> ottenere tempi di riprist<strong>in</strong>o più brevi, o con miglioramenti dei<br />

protocolli sopramenzionati o con soluzioni alternative.<br />

TR<br />

TR<br />

TR<br />

1<br />

2<br />

N<br />

SWITCH<br />

ETHERNET<br />

LO SWITCH DI<br />

ACCESSO INSERISCE<br />

LE VLAN ID ALLE<br />

TRAME ETHERNET<br />

VLAN 1<br />

VLAN N<br />

ROUTER/<br />

SWITCH<br />

DI EDGE<br />

RETE MAN<br />

GIGABIT<br />

ETHERNET<br />

CIASCUN CLIENTE PUO’<br />

AVERE DIFFERENTI<br />

SERVIZI SULLA BASE DEI<br />

VLAN ID<br />

Figura 0.4 : Le VLAN nello standard IEEE 802.1q<br />

44


__________________________________________________________________<br />

2.6 SERVIZI DI CONNETTIVITA’ ETHERNET<br />

PUNTO-PUNTO<br />

In una MAN basata su Ethernet switch<strong>in</strong>g i servizi di connettività Ethernet puntopunto<br />

sono implementati utilizzando le VLAN realizzate <strong>in</strong> conformità allo<br />

standard IEEE 802.1q. Tuttavia queste soluzioni presentano, oltre ai problemi di<br />

protezione discussi precedentemente, anche limitazioni di sca<strong>la</strong>bilità.<br />

Lo standard IEEE 802.1q VLAN <strong>in</strong>fatti, prevede un massimo di 4096 VLAN; ciò<br />

significa che, <strong>in</strong> ciascuna MAN, si possono realizzare al massimo 4096<br />

connessioni. Questo costituisce un limite piuttosto str<strong>in</strong>gente tenendo presente che<br />

ciascun utente può richiedere più di una VLAN <strong>per</strong> realizzare le sue <strong>reti</strong>, come ad<br />

esempio Intranet, Extranet, accesso a Internet e cosi via.<br />

ciascun apparato switch <strong>del</strong><strong>la</strong> MAN deve conoscere l’<strong>in</strong>dirizzo MAC Ethernet di<br />

tutti i dispositivi degli utenti connessi al<strong>la</strong> MAN stessa. Ciò comporta una<br />

notevole dimensione <strong>del</strong>le tabelle MAC, con lunghi tempi di look-up <strong>in</strong> fase di<br />

<strong>in</strong>stradamento dei pacchetti, e di riprist<strong>in</strong>o <strong>del</strong>le normali condizioni <strong>in</strong> caso di<br />

guasto di rete.<br />

Per risolvere o alleviare queste limitazioni proprie <strong>del</strong>lo standard IEEE 802.1q,<br />

alcuni manifatturieri propongono soluzioni proprietarie <strong>per</strong> <strong>la</strong> creazione di pile di<br />

VLAN, con l’aggiunta di un campo di quattro byte nell’header <strong>del</strong><strong>la</strong> trama<br />

Ethernet. Di questi quattro byte, dodici bit sono usati <strong>per</strong> identificare VLAN, che<br />

assumono significato solo all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> MAN, gli altri sono usati <strong>per</strong><br />

identificare i MAC <strong>per</strong> ciascuna VLAN. Questa soluzione porta due benefici. Essa<br />

iso<strong>la</strong> le tabelle di forward<strong>in</strong>g MAC degli swich<strong>in</strong>g dagli <strong>in</strong>dirizzi MAC dei<br />

dispositivi d’utente, rendendo dette tavole molto più maneggevoli; il secondo<br />

beneficio consiste nel fatto che ciascuna connessione può trasportare una<br />

moltitud<strong>in</strong>e di VLAN d’utente. Rimane tuttavia il limite <strong>del</strong>le 4096 connessioni<br />

contemporanee.<br />

45


__________________________________________________________________<br />

2.7 LA GIGABIT ETHERNET<br />

La Gigabit Ethernet ha mediamente le stesse caratteristiche di Ethernet e Fast<br />

Ethernet.<br />

L’estensione <strong>del</strong><strong>la</strong> portante espande il frame tim<strong>in</strong>g al f<strong>in</strong>e di garantire al m<strong>in</strong>imo<br />

uno slot time di 512-byte (4096 bit) <strong>per</strong> half-duplex Ethernet. Tale estensione<br />

<strong>del</strong><strong>la</strong> portante avviene dopo il campo FCS <strong>in</strong> modo da non variare <strong>la</strong> dimensione<br />

<strong>del</strong> frame, <strong>in</strong>fatti essa altera so<strong>la</strong>mente il tempo <strong>in</strong> cui il frame passa sul cavo.<br />

E’ mantenuta qu<strong>in</strong>di <strong>la</strong> compatibilità con i frame Ethernet precedenti anche se<br />

esiste un <strong>in</strong>evitabile aumento <strong>del</strong> costo <strong>in</strong> term<strong>in</strong>i di overhead, <strong>in</strong> quanto i bit di<br />

“carrier extension” su un frame breve ledono l’efficienza <strong>in</strong> banda.<br />

Figura 0.5:Confronto tra <strong>la</strong> trama Ethernet orig<strong>in</strong>ale e <strong>la</strong> trama Gigabit Ethernet<br />

Tramite <strong>la</strong> tecnica <strong>del</strong> Packet Burst<strong>in</strong>g, che consiste nel<strong>la</strong> capacità di trasferire<br />

pacchetti <strong>in</strong> stream unici viene neutralizzato l’overhead <strong>del</strong><strong>la</strong> carrier extension.<br />

Possono <strong>in</strong>fatti essere trasmessi più di 1500 Byte <strong>in</strong> un solo burst e, <strong>per</strong> evitare<br />

che altre stazioni trasmettano nel frattempo, vengono trasmessi dei segnali tra i<br />

frame.<br />

2.8 LA STANDARDIZZAZIONE DEI SERVIZI ETHERNET<br />

La standardizzazione dei servizi Ethernet è portata avanti <strong>in</strong> modo coord<strong>in</strong>ato da<br />

ITU-T, IEEE, IETF e dal Metro-Ethernet Forum (MEF), un’organizzazione senza<br />

46


__________________________________________________________________<br />

scopo di lucro costituita dai maggiori o<strong>per</strong>atori di telecomunicazione e dalle<br />

pr<strong>in</strong>cipali aziende <strong>del</strong> settore che si è posta l’obiettivo di accelerare l’adozione<br />

<strong>del</strong>l’Ethernet come tecnologia di riferimento <strong>per</strong> le <strong>reti</strong> metropolitane a livello<br />

mondiale. Il MEF def<strong>in</strong>isce, dal punto di vista <strong>del</strong>l’utente f<strong>in</strong>ale e qu<strong>in</strong>di<br />

<strong>in</strong>dipendentemente dal<strong>la</strong> tecnologia utilizzata all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete di trasporto<br />

(Ethernet, SDH, DWDM…), due generiche topologie di servizi, che stanno al<strong>la</strong><br />

base di tutte le possibili applicazioni Ethernet <strong>in</strong> ambito metropolitano:<br />

♦ Ethernet L<strong>in</strong>e (E-L<strong>in</strong>e): connessione punto-punto<br />

♦ Ethernet LAN (E-LAN): connessione multipunto-multipunto<br />

Le due topologie sono schematizzate <strong>in</strong> Figura 0.6.<br />

Figura 0.6 : Servizi E-L<strong>in</strong>e ed E-LAN (CE=Customer Edge)<br />

La descrizione completa di un servizio Ethernet comprende una serie di attributi<br />

con dei parametri associati (i.e. Physical Medium, Speed, Ingress Bandwidth<br />

Profile...). Al variare dei valori di questi parametri possono essere create diverse<br />

tipologie di servizi Ethernet. Gli attributi def<strong>in</strong>iti dal MEF si applicano al<strong>la</strong> UNI<br />

(User to Network Interface) o all’EVC (Ethernet Virtual Connection). Con EVC<br />

si <strong>in</strong>tende l’associazione di due (po<strong>in</strong>t-to-po<strong>in</strong>t EVC) o più UNI (Multipo<strong>in</strong>t-to-<br />

Multipo<strong>in</strong>t EVC). Dal punto di vista <strong>del</strong>l’utente f<strong>in</strong>ale <strong>la</strong> specifica completa degli<br />

attributi di un servizio Ethernet corrisponde al<strong>la</strong> def<strong>in</strong>izione di un Service Level<br />

Agreement (SLA) col fornitore di servizi.<br />

La serie di raccomandazioni ITU-T G.8011.x/Y.1307.x def<strong>in</strong>isce, dal punto di<br />

vista <strong>del</strong>l’o<strong>per</strong>atore di telecomunicazioni, dei servizi Ethernet che sono <strong>in</strong> l<strong>in</strong>ea<br />

con quelli previsti dal MEF: Ethernet Private L<strong>in</strong>e (EPL), Ethernet Virtual Private<br />

L<strong>in</strong>e (EVPL), Ethernet Private LAN (EPLAN) e Ethernet Virtual Private LAN. La<br />

struttura di questi servizi di rete è specificata <strong>in</strong> modo generico nel<strong>la</strong><br />

47


__________________________________________________________________<br />

raccomandazione ITU-T G.8011 che si basa sull’architettura di “Ethernet over<br />

Transport” descritta nel<strong>la</strong> racc. G.8010. L’ITU-T G.8011 def<strong>in</strong>isce tre <strong>in</strong>siemi di<br />

attributi a livello di Ethernet Connection (EC), UNI e NNI. L’Ethernet <strong>in</strong> the First<br />

Mile Task Force ha redatto <strong>la</strong> raccomandazione IEEE 802.3ah con i seguenti<br />

obiettivi:<br />

♦ def<strong>in</strong>ire i livelli fisici <strong>del</strong>le seguenti topologie di accesso: Ethernet over<br />

Po<strong>in</strong>t-to-Po<strong>in</strong>t cop<strong>per</strong> (EoVDSL), Ethernet over Po<strong>in</strong>t-to-Po<strong>in</strong>t Optical<br />

Fiber, EPON;<br />

♦ standardizzare un livello di OAM, <strong>in</strong> modo da garantire nel mondo<br />

Ethernet uno standard “Carrier C<strong>la</strong>ss” <strong>per</strong> le funzioni di O<strong>per</strong>ation,<br />

Adm<strong>in</strong>istration, Ma<strong>in</strong>tenance e Provision<strong>in</strong>g (OAM&P) e <strong>in</strong> modo da<br />

assicurare l’<strong>in</strong>tero<strong>per</strong>abilità <strong>in</strong> un ambiente di tipo multivendor.<br />

L’IEEE 802.3ah OAM prevede il trasporto <strong>del</strong>l’<strong>in</strong>formazione di su<strong>per</strong>visione <strong>in</strong><br />

banda, a livello di trama, senza aggiunta di overhead, evitando qu<strong>in</strong>di uno spreco<br />

<strong>del</strong><strong>la</strong> banda dest<strong>in</strong>ata all’utente e garantendo allo stesso tempo che <strong>la</strong> connessione<br />

Ethernet a casa <strong>del</strong>l’utente venga gestita dall’o<strong>per</strong>atore come un servizio<br />

tradizionale. L’EFM-OAM garantisce le funzionalità di monitoraggio <strong>del</strong><br />

collegamento, riporto degli al<strong>la</strong>rmi e gestione <strong>del</strong>le <strong>per</strong>formance.<br />

2.9 SDH/SONET, OTH ED ETHERNET NELLE RETI DI<br />

TRASPORTO:VISIONE DEGLI STANDARD<br />

INTERNAZIONALI E PROSPETTIVE PER IL FUTURO<br />

2.9.1 Un mo<strong>del</strong>lo semplificato <strong>per</strong> una rete di trasporto<br />

In Figura 0.7 e’ descritto un mo<strong>del</strong>lo semplificato, tipicamente orientato al<strong>la</strong><br />

connessione, <strong>per</strong> una rete di trasporto, nel tentativo di evidenziarne gli elementi<br />

costitutivi essenziali e <strong>la</strong> loro funzione. Scopo <strong>del</strong><strong>la</strong> rete e’ <strong>la</strong> fornitura di un<br />

servizio di trasporto, idealmente trasparente, <strong>per</strong> un generico cliente (ad esempio<br />

un flusso Ethernet) attraverso <strong>la</strong> rete stessa, con caratteristiche di affidabilità e<br />

disponibilità, che possono essere <strong>in</strong> generale espresse come <strong>per</strong>centuale di tempo<br />

48


__________________________________________________________________<br />

<strong>per</strong> cui il servizio su<strong>per</strong>a determ<strong>in</strong>ati requisiti di qualità.<br />

Figura 0.7 : Mo<strong>del</strong>lo semplificato di rete di trasporto<br />

A tale f<strong>in</strong>e il servizio deve essere tipicamente:<br />

♦ proteggibile (mediante contromisure a breve term<strong>in</strong>e verso guasti)<br />

♦ manutenibile (mediante contromisure a medio term<strong>in</strong>e verso guasti)<br />

♦ misurabile (<strong>per</strong> <strong>la</strong> verifica dei requisiti di qualità)<br />

Gli elementi costitutivi essenziali <strong>del</strong><strong>la</strong> rete, come si desume dal<strong>la</strong> figura, sono:<br />

♦ connessioni logiche (che sono associate al cliente, lo accompagnano dall’<br />

<strong>in</strong>gresso all’uscita <strong>del</strong><strong>la</strong> rete e di fatto realizzano il servizio di trasporto,<br />

portando con se le <strong>in</strong>formazioni necessarie <strong>per</strong> misurarne <strong>la</strong> qualità)<br />

♦ connessioni fisiche (il mezzo fisico, su cui diversi servizi, e qu<strong>in</strong>di clienti,<br />

devono essere aggregati <strong>per</strong> poterne consentire un utilizzo efficiente)<br />

♦ matrici di <strong>in</strong>terconnessione (che o<strong>per</strong>ando sulle connessioni logiche<br />

consentono da un <strong>la</strong>to di <strong>in</strong>stradare i servizi e dall’ altro di aggregarli sul<br />

mezzo fisico).<br />

49


__________________________________________________________________<br />

Le <strong>reti</strong> di trasporto reali, rispetto al mo<strong>del</strong>lo qui proposto, tipicamente variano <strong>per</strong><br />

<strong>la</strong> ricorsività <strong>del</strong> concetto di connessione logica e <strong>la</strong> possibilità di term<strong>in</strong>are e<br />

monitorare segmenti di connessione.<br />

2.9.2 Descrizione funzionale <strong>del</strong> mo<strong>del</strong>lo<br />

In Figura 0.8 il semplice mo<strong>del</strong>lo già <strong>in</strong>trodotto e’ arricchito con l’ ulteriore<br />

dettaglio dei blocchi funzionali che lo compongono, allo scopo di mostrarne il<br />

f<strong>in</strong>e rispetto alle citate caratteristiche di proteggibilità, manutenibilità,<br />

misurabilità.<br />

Figura 0.8 : Mo<strong>del</strong>lo funzionale di rete di trasporto<br />

La descrizione a strati è ricorsiva, e comprende <strong>per</strong> ogni strato una term<strong>in</strong>azione,<br />

una connessione, possibilità di monitoraggio non <strong>in</strong>trusivo ed un adattamento allo<br />

strato successivo. Nel nostro mo<strong>del</strong>lo gli strati sono solo 3: il cliente (<strong>per</strong> cui<br />

esiste <strong>la</strong> so<strong>la</strong> possibilità di monitoraggio non <strong>in</strong>trusivo), <strong>la</strong> connessione logica, il<br />

mezzo fisico. Cercando di riassumere quanto è espresso <strong>in</strong> Figura 0.8 è possibile<br />

dire che <strong>in</strong> generale, a livello di term<strong>in</strong>azioni e monitoraggi non <strong>in</strong>trusivi, si<br />

verificano:<br />

♦ l’ <strong>in</strong>tegrità<br />

50


__________________________________________________________________<br />

♦ <strong>la</strong> congruenza (rispetto al tipo di servizio atteso)<br />

♦ <strong>la</strong> corretta connessione<br />

♦ <strong>la</strong> qualità (secondo parametri che dipendono dal<strong>la</strong> connessione stessa)<br />

di una connessione. Di più, <strong>in</strong> una term<strong>in</strong>azione si generano:<br />

♦ un segnale <strong>in</strong>formativo sull’ <strong>in</strong>tegrità <strong>del</strong> segnale ricevuto verso il<br />

term<strong>in</strong>ale lontano<br />

♦ un segnale <strong>in</strong>formativo sul<strong>la</strong> qualità <strong>del</strong> segnale ricevuto verso il term<strong>in</strong>ale<br />

lontano.<br />

A carico <strong>del</strong>le funzioni di adattamento e’ <strong>in</strong>vece <strong>la</strong> generazione di<br />

♦ un segnale di silenziamento al<strong>la</strong>rmi a valle (storicamente def<strong>in</strong>ito come<br />

A<strong>la</strong>rm Indication Signal – AIS – e con il segnificato di <strong>in</strong>dicare al generico<br />

cliente che lo strato “servitore” e’ <strong>in</strong>disponibile).<br />

Le funzioni di connessione sono, come già detto, demandate all’ <strong>in</strong>stradamento ed<br />

all’ aggregazione. Risultati <strong>del</strong>le verifiche e segnali possono essere diversamente<br />

utilizzati secondo le diverse politiche dei gestori dei servizi di trasporto. Un caso<br />

“esemp<strong>la</strong>re” può essere quello <strong>in</strong> cui <strong>la</strong> protezione e’ fatta sia a livello di mezzo<br />

fisico (<strong>per</strong>chè tipicamente e’ quello che “si rompe” e <strong>per</strong>chè impatta diversi<br />

servizi allo stesso tempo) utilizzando come criteri <strong>per</strong> l’ attivazione di <strong>per</strong>corsi<br />

alternativi i risultati <strong>del</strong>le verifiche fatte a livello di term<strong>in</strong>azione, sia a livello di<br />

connessione logica (<strong>per</strong>chè <strong>in</strong> questo modo si ha l’assoluta certezza di proteggere<br />

“quel” servizio dall’ <strong>in</strong>izio al<strong>la</strong> f<strong>in</strong>e <strong>del</strong> <strong>per</strong>corso <strong>in</strong> rete, comprendendo anche gli<br />

apparati) utilizzando come criteri i risultati <strong>del</strong>le verifiche fatte a livello di<br />

monitoraggio non <strong>in</strong>trusivo. La manutenzione e’ pr<strong>in</strong>cipalmente basata sulle<br />

verifiche fatte a livello di term<strong>in</strong>azione <strong>del</strong> mezzo fisico, ed e’ facilitata dall’<br />

utilizzo <strong>del</strong> segnale di AIS <strong>per</strong> risalire alle cause prime <strong>del</strong> guasto. La misura <strong>del</strong><strong>la</strong><br />

qualità è basata sulle verifiche fatte a livello di term<strong>in</strong>azione <strong>del</strong><strong>la</strong> connessione<br />

logica, eventualmente utilizzando anche le <strong>in</strong>formazioni di qualità e <strong>in</strong>tegrità<br />

remote, che consentono <strong>la</strong> <strong>valutazione</strong> contemporanea di entrambe le direzioni<br />

senza ricorrere a corre<strong>la</strong>zioni fra i dati provenienti da diversi apparati. Il<br />

51


__________________________________________________________________<br />

monitoraggio non <strong>in</strong>trusivo <strong>del</strong> cliente consente al fornitore di <strong>in</strong>tegrare le<br />

<strong>in</strong>formazioni <strong>in</strong>erenti al<strong>la</strong> qualità <strong>del</strong> proprio trasporto con quelle re<strong>la</strong>tive al<br />

segnale trasportato.<br />

2.9.3 SDH ED OTH<br />

La mo<strong>del</strong>lizzazione s<strong>in</strong> qui descritta e’ facilmente r<strong>in</strong>venibile negli standard ITU<br />

che descrivono <strong>la</strong> Gerarchia di Multip<strong>la</strong>zione S<strong>in</strong>crona (SDH) e <strong>la</strong> Rete di<br />

Trasporto Ottica (OTN), che su tali mo<strong>del</strong>lizzazioni sono state costruite e proprio<br />

<strong>per</strong> questo sono <strong>in</strong> grado di garantire <strong>la</strong> proteggibilità, <strong>la</strong> manutenibilità, <strong>la</strong><br />

misurabilità <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio dei clienti trasportati e qu<strong>in</strong>di di def<strong>in</strong>irne <strong>la</strong><br />

disponibilità. In Tabel<strong>la</strong> 0.1 sono s<strong>in</strong>teticamente descritti gli strumenti (al<strong>la</strong>rmi,<br />

conteggi, segna<strong>la</strong>zioni) che SDH mette a disposizione re<strong>la</strong>tivamente al<strong>la</strong><br />

mo<strong>del</strong>lizzazione <strong>in</strong>trodotta. Una tabel<strong>la</strong> <strong>del</strong> tutto analoga descrive OTN, con<br />

qualche variante di nomenc<strong>la</strong>tura. In questo ultimo caso e’ partico<strong>la</strong>rmente<br />

rilevante il fatto che lo standard <strong>in</strong>troduca 2 mezzi fisici: l’ OTU (Optical<br />

Transport Unit), equivalente ad una s<strong>in</strong>go<strong>la</strong> λ, e l’OMS/OTS (Optical Multiplex<br />

Section/Optical Transport Section), equivalente al segnale ottico multip<strong>la</strong>to e<br />

qu<strong>in</strong>di <strong>in</strong> def<strong>in</strong>itiva al<strong>la</strong> fibra. Per entrambi sono <strong>in</strong>dividuabili gli elementi<br />

essenziali sopra descritti, con qualche limitazione <strong>per</strong> il segnale ottico.<br />

SDH<br />

Term<strong>in</strong>azione<br />

&<br />

monitoraggio<br />

non <strong>in</strong>trusivo<br />

Term<strong>in</strong>azione<br />

Connessione logica<br />

(Virtual Conta<strong>in</strong>er)<br />

Connessione fisica<br />

(STM-N)<br />

Integrità<br />

Server Signal Fail Loss of Signal<br />

Loss of Frame<br />

Congruenza<br />

Payload Label<br />

Mismatch<br />

-<br />

Connessione Trail Id Mismatch Section Id Mismatch<br />

Qualità<br />

Bit Error Rate<br />

(mediante<br />

Bit Error Rate<br />

(mediante<br />

verifica di parita’) verifica di parita’)<br />

Integrità remota<br />

Remote Defect Remote Defect<br />

Indication<br />

Indication<br />

Qualità remota<br />

Remote Error<br />

Indication<br />

Remote Error Indication<br />

Adattamento Silenziamento A<strong>la</strong>rm Indication Signal (server ⇒ client)<br />

Tabel<strong>la</strong> 0.1 : OAM SDH (al<strong>la</strong>rmi, conteggi, segna<strong>la</strong>zioni)<br />

52


__________________________________________________________________<br />

2.9.4 ETHERNET: STANDARD FUTURI<br />

Ethernet nasce come tecnologia dedicata a <strong>reti</strong> a commutazione di pacchetto<br />

locali, e come tale non supporta <strong>in</strong> modo nativo molte <strong>del</strong>le caratteristiche s<strong>in</strong> qui<br />

enunciate. Non è orientata al<strong>la</strong> connessione, non def<strong>in</strong>isce una connessione logica<br />

end-to-end e <strong>per</strong>tanto non ne consente una misura di qualità (le cifre di parità<br />

<strong>in</strong>serite <strong>in</strong> ogni pacchetto Ethernet sono term<strong>in</strong>ate <strong>in</strong> ogni nodo e ricalco<strong>la</strong>te), non<br />

dist<strong>in</strong>gue connessione logica da connessione fisica, non <strong>in</strong>corpora meccanismi di<br />

protezione veloci (ord<strong>in</strong>e dei 50 msec.) ne di silenziamento al<strong>la</strong>rmi. La mancanza<br />

pr<strong>in</strong>cipale, da cui discendono tutte le altre, e’ <strong>la</strong> natura “connectionless” di<br />

Ethernet: non e’ un caso che ATM, tecnologia a pacchetto concepita <strong>per</strong> essere<br />

“onnicomprensiva”, sia orientata al<strong>la</strong> connessione. Di fatto, tutte le attività di<br />

standardizzazione, cui assistiamo <strong>in</strong> questi anni, tese a generare soluzioni a<br />

commutazione di pacchetto “affidabili” passano <strong>in</strong>variabilmente <strong>per</strong> il tentativo,<br />

più o meno occulto, di “orientare al<strong>la</strong> connessione” tecnologie che <strong>in</strong> orig<strong>in</strong>e non<br />

lo sarebbero. E’ il caso di IP <strong>in</strong> modo palese con MPLS (Multi Protocol Label<br />

Switch<strong>in</strong>g); e’ il caso di Ethernet <strong>in</strong> modo molto più sottile.<br />

2.9.5 ETHERNET SU MPLS (MPLS ED OAM)<br />

MPLS nasce <strong>in</strong> ambito IETF come evoluzione di IP orientata al<strong>la</strong> connessione, di<br />

fatto replicando il concetto fondamentale già presente <strong>in</strong> ATM di identificare con<br />

un’ etichetta non già <strong>la</strong> dest<strong>in</strong>azione o <strong>la</strong> sorgente, ma un segmento di <strong>per</strong>corso <strong>in</strong><br />

rete, e di modificarne il valore nodo <strong>per</strong> nodo (<strong>per</strong> sca<strong>la</strong>bilità). Lo stesso<br />

meccanismo e’ applicabile ad Ethernet, oltre che ad IP, e come tale e’ <strong>in</strong>dirizzato<br />

da diversi standard. Il trasporto su MPLS e’ sicuramente una metodologia che<br />

avvic<strong>in</strong>a Ethernet alle caratteristiche di affidabilità che abbiamo s<strong>in</strong> qui descritto.<br />

Questo risultato e’ ottenuto <strong>in</strong> modo “non nativo”, aggiungendo un <strong>la</strong>yer ed il<br />

piano di controllo re<strong>la</strong>tivo basato su OSPF (Open Short Path First) e RSVP-TE<br />

(ReSerVation Protocol – Traffic Eng<strong>in</strong>eer<strong>in</strong>g), orientato al<strong>la</strong> connessione, che va a<br />

sostituire quello Ethernet basato su STP (Spann<strong>in</strong>g Tree Protocol), connectionless.<br />

Partico<strong>la</strong>rmente di rilievo sono le attività di standard, sia ITU che IETF, volte a<br />

completare <strong>la</strong> def<strong>in</strong>izione di MPLS con capacità di OAM e protezione, che,<br />

53


__________________________________________________________________<br />

soprattutto nel caso ITU, tendono a replicare gli analoghi meccanismi già def<strong>in</strong>iti<br />

<strong>per</strong> ATM.<br />

2.9.6 ETHERNET PROVIDER BRIDGE<br />

Il primo tentativo evidente di far evolvere Ethernet come tale oltre l’orizzonte<br />

limitato <strong>del</strong>le <strong>reti</strong> locali è di IEEE, con <strong>la</strong> specifica <strong>del</strong>l’ applicazione provider<br />

bridge. In essa si generalizza un meccanismo pre-esistente, nato con lo scopo<br />

primario di partizionare <strong>reti</strong> complesse <strong>in</strong> sotto<strong>reti</strong> entro cui conf<strong>in</strong>are il traffico<br />

broadcast (cioè <strong>in</strong>dirizzato a tutti i nodi, necessario <strong>per</strong> l’apprendimento degli<br />

<strong>in</strong>dirizzi di rete), al f<strong>in</strong>e di generare di fatto l’equivalente di una connessione<br />

logica dist<strong>in</strong>ta dal<strong>la</strong> connessione fisica. Il meccanismo orig<strong>in</strong>ale consiste nell’<br />

identificare le sotto<strong>reti</strong> (dette VLAN, o Virtual LAN) con un’ apposita etichetta<br />

appesa ad ogni trama Ethernet. In essa si def<strong>in</strong>isce l’ utilizzo di un etichetta<br />

analoga, sovrapposta al<strong>la</strong> precedente all’ <strong>in</strong>gresso <strong>del</strong><strong>la</strong> rete dal fornitore di<br />

servizio (provider) ed elim<strong>in</strong>ata all’ uscita, da utilizzarsi <strong>per</strong> il partizionamento di<br />

tale rete, così come <strong>la</strong> prima partiziona <strong>la</strong> rete <strong>del</strong> cliente. Tale partizionamento, se<br />

limitato ad un unico punto di <strong>in</strong>gresso ed un unico punto di uscita <strong>del</strong><strong>la</strong> rete <strong>del</strong><br />

provider, genera di fatto un <strong>per</strong>corso punto-punto, cioè una connessione logica, <strong>in</strong><br />

cui l’<strong>in</strong>stradamento è rigido e non richiede neppure più l’ ispezione <strong>del</strong>l’ <strong>in</strong>dirizzo<br />

MAC di dest<strong>in</strong>azione (basta l’ identificativo di VLAN). La limitazione più<br />

evidente di questa tecnica, se usata estensivamente, è <strong>la</strong> sca<strong>la</strong>bilità, <strong>in</strong> quanto l’<br />

identificativo di VLAN e’ di fatto univocamente associato ad un <strong>per</strong>corso <strong>in</strong> rete,<br />

e i 12 bit <strong>del</strong>l’ etichetta consentono al più 4096 possibili codifiche. Il su<strong>per</strong>amento<br />

di questa difficoltà non è ancora stato standardizzato, anche se esistono proposte<br />

<strong>in</strong> tal senso, ma <strong>per</strong> quel che riguarda il piano di traffico è abbastanza ovvio e<br />

consiste nel<strong>la</strong> possibilità di commutare il valore <strong>del</strong>l’ etichetta nodo <strong>per</strong> nodo,<br />

associando <strong>in</strong> tal modo i 4096 possibili valori alle sezioni di <strong>per</strong>corso<br />

congiungenti due nodi qualsiasi e non all’ <strong>in</strong>tero <strong>per</strong>corso, esattamente come è<br />

specificato <strong>per</strong> ATM ed MPLS. Re<strong>la</strong>tivamente al piano di controllo il discorso è<br />

più complesso, ma una soluzione potrebbe essere quel<strong>la</strong> di applicare ad Ethernet<br />

uno di quelli esistenti orientati al<strong>la</strong> connessione (e.g. derivato da MPLS, oppure<br />

da GMPLS, oppure da ATM).<br />

54


__________________________________________________________________<br />

2.9.7 ETHERNET PROVIDER BACKBONE BRIDGE<br />

Un’ ulteriore tentativo di consentire ad Ethernet prestazioni analoghe a quelle<br />

<strong>del</strong>le <strong>reti</strong> di trasporto tradizionali è riconoscibile <strong>in</strong> una norma che è solo all’<strong>in</strong>izio<br />

<strong>del</strong> suo <strong>per</strong>corso di standardizzazione. Se il provider bridge consente al fornitore<br />

<strong>del</strong> servizio un utilizzo <strong>del</strong>l’ identificativo di VLAN <strong>in</strong>dipendente da quello che ne<br />

fa il cliente, il provider backbone bridge estende lo stesso concetto agli <strong>in</strong>dirizzi<br />

MAC, def<strong>in</strong>endo una struttura di trama Ethernet che comprende 2 livelli di<br />

<strong>in</strong>dirizzamento sovrapposti, dei quali quello più esterno è aggiunto ed utilizzato<br />

dal provider, che lo elim<strong>in</strong>a prima di restituire <strong>la</strong> trama al cliente. Tale tecnica<br />

consente, come il provider bridge, una separazione di pr<strong>in</strong>cipio fra connettività<br />

logica e connettività fisica, ma non rende <strong>la</strong> tecnologia orientata al<strong>la</strong> connessione<br />

e come tale non consente di su<strong>per</strong>are tutte le difficoltà native di Ethernet rispetto a<br />

tecnologie di trasporto più consolidate. Di fatto consente al fornitore <strong>del</strong> servizio<br />

di realizzare una rete basata su connessioni multipunto-multipunto <strong>del</strong> tutto<br />

sv<strong>in</strong>co<strong>la</strong>ta da quel<strong>la</strong> analoga <strong>del</strong> cliente. Come tale consente di impi<strong>la</strong>re i piani di<br />

controllo basati su STP e di migliorare <strong>la</strong> sca<strong>la</strong>bilità <strong>del</strong>l’ applicazione provider<br />

bridge creando isole con campi dei valori di VLAN <strong>in</strong>dipendenti, ma non facilita<br />

il su<strong>per</strong>amento <strong>del</strong> paradigma “best effort”.<br />

2.9.8 ETHERNET OAM<br />

Se è vero che <strong>la</strong> possibilità di Ethernet di giocare nelle <strong>reti</strong> di trasporto un ruolo<br />

analogo a quello di SDH e OTH passa <strong>per</strong> una modalità di utilizzo orientata al<strong>la</strong><br />

connessione, è anche vero che ciò non sarebbe comunque sufficiente senza<br />

adeguati meccanismi di OAM (O<strong>per</strong>ation, Adm<strong>in</strong>istration & Ma<strong>in</strong>tenance),<br />

analoghi a quelli che abbiamo <strong>in</strong>dirizzato. A tale proposito sono <strong>in</strong> corso attività<br />

di standardizzazione sia <strong>in</strong> ITU che <strong>in</strong> IEEE, non ancora f<strong>in</strong>alizzate, ma<br />

sicuramente promettenti. Un esempio di quello che potrebbe diventare una rete<br />

Ethernet <strong>in</strong> cui le procedure di OAM <strong>in</strong> corso di def<strong>in</strong>izione siano applicate è<br />

mostrata <strong>in</strong> Figura 0.9. La rete <strong>del</strong> fornitore di servizio è partizionata mediante<br />

VLAN, come descritto <strong>in</strong> precedenza, <strong>in</strong> 3 sotto<strong>reti</strong> di cui 2 punto-punto. Lo<br />

55


__________________________________________________________________<br />

standard consente di def<strong>in</strong>ire punti term<strong>in</strong>ali di monitoraggio (MEP), ossia<br />

term<strong>in</strong>azioni, e punti di monitoraggio <strong>in</strong>termedi (MIP), ossia monitoraggi non<br />

<strong>in</strong>trusivi. Il fatto di ammettere diversi livelli (1, 2, 3... <strong>in</strong> figura) rende conto <strong>del</strong><strong>la</strong><br />

possibilità di term<strong>in</strong>are e monitorare segmenti di connessione, anche <strong>in</strong> modo<br />

ricorsivo, come può rendersi necessario <strong>in</strong> scenari di tipo “carriers’ carrier”. La<br />

Tabel<strong>la</strong> 0.2 descrive s<strong>in</strong>teticamente i meccanismi di OAM <strong>in</strong> corso di def<strong>in</strong>izione,<br />

<strong>in</strong> modo direttamente confrontabile con quelli equivalenti SDH ed OTN.<br />

Ethernet<br />

Term<strong>in</strong>azione<br />

&<br />

monitoraggio<br />

non <strong>in</strong>trusivo<br />

Term<strong>in</strong>azione<br />

Adattamento<br />

Connessione logica<br />

(Ma<strong>in</strong>ten. Entity<br />

o<strong>per</strong>ator-providercustomer)<br />

Loss of Cont<strong>in</strong>uity<br />

Connessione fisica<br />

(ME physical level)<br />

Loss of Cont<strong>in</strong>uity<br />

Integrità Loopback Fail L<strong>in</strong>k Loopback Fail<br />

Trace Mismatch<br />

Congruenza - -<br />

Connessione L<strong>in</strong>k Trace Mismatch (L<strong>in</strong>k Trace Mismatch)<br />

Frame PM parameters Port PM parameters<br />

Qualità (FR De<strong>la</strong>y, FR Loss, (FRTx, FrRx,FrDrop,<br />

ecc)<br />

ecc)<br />

Integrità remota<br />

Ethernet Remote Ethernet Remote<br />

Defect Indication Defect Indication<br />

Qualità remota - -<br />

Silenziamento<br />

Ethernet A<strong>la</strong>rm Indication Signal (server ⇒<br />

client)<br />

Tabel<strong>la</strong> 0.2 : OAM Ethernet (al<strong>la</strong>rmi, conteggi, segna<strong>la</strong>zioni)<br />

2.9.9 CONSIDERAZIONI FINALI<br />

Le <strong>reti</strong> tradizionali di trasporto, come SDH ed OTN, implementano un’<br />

architettura a strati e meccanismi consolidati di OAM che consentono di fornire<br />

servizi con elevate caratteristiche di affidabilità e disponibilità su <strong>reti</strong> geografiche.<br />

Ethernet nasce come tecnologia dedicata alle <strong>reti</strong> locali ed è caratterizzata da un’<br />

architettura “piatta” e dall’ assenza di tali meccanismi. Diverse attività di standard<br />

<strong>in</strong>ternazionale sono attualmente <strong>in</strong> corso nel tentativo di colmare il divario<br />

esistente. Questo <strong>per</strong>corso non è ancora consolidato, ma s<strong>in</strong> d’ ora è evidente che<br />

dal punto di vista puramente tecnico è possibile evolvere Ethernet ed arricchir<strong>la</strong><br />

56


__________________________________________________________________<br />

<strong>del</strong>le prestazioni necessarie a competere, anche <strong>in</strong> ambito geografico, con le<br />

tecnologie tradizionali di trasporto, sia aggiungendo un <strong>la</strong>yer orientato al<strong>la</strong><br />

connessione, come MPLS, sia <strong>in</strong> modo nativo. E’ <strong>per</strong>ò altrettanto evidente che<br />

tale <strong>per</strong>corso richiederà modifiche profonde degli apparati attualmente esistenti,<br />

nel senso di aumentarne <strong>la</strong> complessità e qu<strong>in</strong>di il costo, <strong>in</strong> quanto tipicamente le<br />

funzionalità di OAM, se applicate estensivamente, vanno realizzate <strong>in</strong> HW. Di<br />

più, esso è caratterizzato da estrema <strong>in</strong>certezza sul<strong>la</strong> dest<strong>in</strong>azione f<strong>in</strong>ale, dal<br />

momento che le alternative possibili sono diverse, tutte simili dal punto di vista<br />

tecnico ma non compatibili fra loro, ne essendosi ancora consolidata una<br />

posizione univoca <strong>in</strong> ambito standard, che ad oggi appare difficile da raggiungere.<br />

In questa situazione di <strong>in</strong>certezza è difficile supporre che tecnologie consolidate<br />

come SDH possano essere messe rapidamente <strong>in</strong> crisi dalle nuove soluzioni<br />

emergenti, che fra l’altro <strong>in</strong>izialmente aumentando <strong>in</strong> prestazioni <strong>per</strong>deranno<br />

molto probabilmente l’<strong>in</strong>iziale vantaggio di costo. Pur riconoscendo che <strong>la</strong> mutata<br />

natura <strong>del</strong> servizio, che da circuito è divenuto pacchetto, tende <strong>in</strong>evitabilmente a<br />

privilegiare tecnologie di trasporto aff<strong>in</strong>i, e’ verosimile pensare che l’<strong>in</strong>troduzione<br />

sarà graduale e <strong>la</strong> completa transizione, se mai vi sarà, richiederà un lungo arco<br />

temporale.<br />

Figura 0.9 : Rete Ethernet con OAM<br />

57


__________________________________________________________________<br />

In questo contesto si colloca questo <strong>la</strong>voro nel quale viene proposto un sistema<br />

automatico Software\Hardware di protezione ad un guasto <strong>in</strong> una connesione<br />

ottica punto-punto Gigabit Ethernet. Viene qu<strong>in</strong>di proposto un sistema <strong>in</strong> grado di<br />

gestire una connessione di questo tipo con una tempistica paragonabile a quel<strong>la</strong><br />

<strong>del</strong>le consolidate tecnologie di trasporto come SDH. Inoltre <strong>la</strong> soluzione realizzata<br />

<strong>in</strong> questo <strong>la</strong>voro presenta costi di implementazione decisamente contenuti, e<br />

qu<strong>in</strong>di risulta essere una valida proposta ed un punto di partenza <strong>per</strong> un<br />

evoluzione <strong>del</strong>l’OAM&P nelle <strong>reti</strong> Ethernet.<br />

58


__________________________________________________________________<br />

Capitolo 3<br />

QUALITA’ DEL SERVIZIO: CARATTERIZZAZIONE ED<br />

IMPLEMENTAZIONE<br />

In questo capitolo si mettono <strong>in</strong> luce le tematiche fondamentali di questo <strong>la</strong>voro<br />

che sono <strong>la</strong> QoS e <strong>la</strong> sua implementazione, <strong>per</strong> mezzo <strong>del</strong>l’approccio DiffServ,<br />

sul paradigma MPLS. L’<strong>in</strong>tegrazione di questi due aspetti, <strong>la</strong> QoS fornita da<br />

DiffServ da un <strong>la</strong>to, ed i <strong>per</strong>corsi end-to-end forniti da MPLS dall’altro,<br />

costituisce una solida base <strong>per</strong> <strong>la</strong> garanzia di servizi real-time che sono ad oggi i<br />

più critici <strong>per</strong> <strong>la</strong> rete.<br />

Nel capitolo viene fatta anche una panoramica generale sul<strong>la</strong> tecnologia Ethernet e<br />

<strong>del</strong> suo ruolo, argomento dal quale è impossibile presc<strong>in</strong>dere data <strong>la</strong> sua<br />

diffusione. In questo <strong>la</strong>voro Ehernet è essenzialmente utilizzata <strong>in</strong> term<strong>in</strong>i di<br />

trasmissione dati.<br />

3.1 QUALITA’ DEL SERVIZIO<br />

Il problema <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio e <strong>del</strong><strong>la</strong> sua gestione nasce con l’<strong>in</strong>troduzione<br />

di nuovi servizi che <strong>per</strong> loro natura non posso essere trattati allo stesso modo<br />

<strong>del</strong> semplice traffico dati.<br />

Per descrivere <strong>la</strong> QoS è opportuno riportare due esempi esplicativi <strong>del</strong>l’esigenza<br />

di questo servizio.<br />

• Un utente stipu<strong>la</strong> un contratto, SLA ( Service Level Agreement), con il<br />

proprio Service Provider <strong>per</strong> navigare <strong>in</strong> Internet e ricevere a casa propria<br />

<strong>la</strong> televisione tramite rete fissa. E’ immediato capire come i due servizi<br />

richiesti abbiano caratteristiche profondamente diverse: <strong>la</strong> navigazione <strong>in</strong><br />

Internet è un semplice trasferimento dati, è un servizio non real-time che<br />

non ha v<strong>in</strong>coli temporali o di <strong>per</strong>dita di pacchetti ed è senza garanzia di<br />

banda . Per contro <strong>la</strong> televisione è un servizio real-time, uno stream<strong>in</strong>g<br />

59


__________________________________________________________________<br />

audio/video che necessita di ritardi, jitter e <strong>per</strong>dite di <strong>in</strong>formazione entro<br />

limiti ben precisi aff<strong>in</strong>ché l’utente sia soddisfatto <strong>del</strong> servizio ricevuto.<br />

• Un altro utente vuole navigare <strong>in</strong> Internet ma con una certa banda<br />

garantita, ovvero senza subire quelle flessioni dovute, ad esempio, alle<br />

congestioni <strong>del</strong><strong>la</strong> rete nelle ore di punta.<br />

In entrambi i casi si par<strong>la</strong> di QoS: nel primo si effettua <strong>la</strong> differenziazione dei<br />

servizi, dove il trattamento dei pacchetti dipende dal tipo di servizio a cui<br />

appartengono, nel secondo <strong>la</strong> garanzia <strong>del</strong>le prestazioni <strong>in</strong> cui vengono garantite<br />

le prestazioni di rete <strong>in</strong>dipendentemente dal servizio. Il concetto di QoS, <strong>in</strong> base<br />

alle considerazioni fatte può essere def<strong>in</strong>ito nel modo seguente:<br />

“E’ <strong>la</strong> capacità di un sistema di garantire livelli di servizio prestabiliti,<br />

differenziati <strong>per</strong> c<strong>la</strong>sse e tipologia, <strong>in</strong> regime di risorse limitate.”<br />

Il livello di QoS richiesto da un utente o caratteristico di un partico<strong>la</strong>re servizio<br />

viene deciso sul<strong>la</strong> base di opportuni parametri e deve essere rispettato <strong>in</strong> accordo<br />

con il SLA (Service Level Agreement) stipu<strong>la</strong>to tra Service Provider e utente.<br />

Va osservato che quando si stipu<strong>la</strong> un contratto questi deve essere rispettato non<br />

solo dal gestore, ma anche dall’utente.<br />

I parametri che def<strong>in</strong>iscono <strong>la</strong> QoS sono pr<strong>in</strong>cipalmente sei:<br />

1- One Way De<strong>la</strong>y: è il ritardo ad una via che un pacchetto s<strong>per</strong>imenta<br />

attraversando tutta <strong>la</strong> rete, dal<strong>la</strong> sorgente al dest<strong>in</strong>atario. Esso è dato dal<strong>la</strong><br />

somma di tre term<strong>in</strong>i: il tempo di propagazione all’<strong>in</strong>terno dei mezzi<br />

trasmessivi, il tempo di processamento e il tempo di accodamento dei<br />

pacchetti all’<strong>in</strong>terno dei nodi (routers). I primi due si possono considerare<br />

costanti, mentre il tempo di accodamento determ<strong>in</strong>a <strong>in</strong> modo<br />

preponderante <strong>la</strong> variabilità <strong>del</strong> one-way de<strong>la</strong>y e il suo aumento <strong>in</strong> caso di<br />

rete congestionata.<br />

60


__________________________________________________________________<br />

2- Latency: si def<strong>in</strong>isce <strong>la</strong>tenza il tempo che <strong>in</strong>tercorre tra <strong>la</strong> ricezione e<br />

l’<strong>in</strong>oltro di un pacchetto all’<strong>in</strong>terno di un router.<br />

3- Jitter: è un parametro fondamentale <strong>per</strong> quanto riguarda soprattutto i<br />

servizi real-time ed è tipico <strong>del</strong>le <strong>reti</strong> a commutazione di pacchetto<br />

TCP/IP. Il fatto che ogni pacchetto, appartenente allo stesso flusso, venga<br />

trattato <strong>in</strong>dipendentemente dagli altri causa tempi di ritardo variabili da<br />

pacchetto a pacchetto: <strong>la</strong> variazione <strong>del</strong> one-way de<strong>la</strong>y viene chiamata<br />

jitter.<br />

Figura 3.1: Distribuzione <strong>del</strong>le Latenza e <strong>del</strong> Jitter<br />

4- Bandwidth: è <strong>la</strong> misura <strong>del</strong><strong>la</strong> capacità di trasmissione dei dati ed è<br />

espressa generalmente <strong>in</strong> kilobit <strong>per</strong> secondo (Kbps) o megabits <strong>per</strong><br />

secondo (Mpbs). Bandwidth <strong>in</strong>dica <strong>la</strong> teorica capacità massima di una<br />

connessione, molti fattori <strong>per</strong>ò possono <strong>in</strong>fluenzare questo dato. Le<br />

specifiche <strong>per</strong> <strong>la</strong> capacità possono <strong>in</strong>cludere parametri quali il “maximum<br />

burst size” (<strong>la</strong> banda di picco), <strong>la</strong> banda m<strong>in</strong>ima garantita o <strong>la</strong> capacità<br />

garantita di accesso.<br />

5- Packet Loss: con questo parametro viene misurata <strong>la</strong> <strong>per</strong>centuale di<br />

pacchetti <strong>per</strong>si calco<strong>la</strong>ta facendo il rapporto tra quelli ricevuti e quelli<br />

61


__________________________________________________________________<br />

<strong>in</strong>viati; comprende anche <strong>la</strong> ricezione errata dei pacchetti. Questo<br />

parametro non ha molta rilevanza <strong>per</strong> il trasporto di dati TCP/IP <strong>in</strong> quanto<br />

il protocollo di trasporto provvede al<strong>la</strong> ritrasmissione dei pacchetti <strong>in</strong> caso<br />

di <strong>per</strong>dita. Il Packet Loss diventa <strong>in</strong>vece molto importante quando si<br />

utilizza il protocollo RTP (Real Time Protocol) <strong>in</strong> quanto, essendo<br />

realizzato ad hoc <strong>per</strong> servizi real-time, non prevede il recu<strong>per</strong>o dei<br />

pacchetti <strong>per</strong>si.<br />

6- Avai<strong>la</strong>bility: <strong>in</strong>dica <strong>la</strong> disponibilità di un determ<strong>in</strong>ato servizio <strong>in</strong> un arco di<br />

tempo prefissato.<br />

3.1.1 SLA: Service Level Agreement<br />

E’ il contratto che viene stipu<strong>la</strong>to tra il Service Provider e l’utente riguardo a<br />

determ<strong>in</strong>ati servizi ed è basato proprio sui parametri di controllo <strong>del</strong><strong>la</strong> QoS. Gli<br />

SLA, oltre a garantire un determ<strong>in</strong>ato livello di QoS stabiliscono anche <strong>del</strong>le<br />

penali da pagare nel caso <strong>in</strong> cui il contratto non venisse rispettato; questo è un<br />

ulteriore motivo <strong>del</strong><strong>la</strong> grande importanza che ha <strong>la</strong> gestione <strong>del</strong><strong>la</strong> QoS nelle <strong>reti</strong><br />

attuali. Un SLA è composto da due parti pr<strong>in</strong>cipali:<br />

1- Service Level Specification. I dettagli o<strong>per</strong>azionali <strong>del</strong> SLA sono def<strong>in</strong>iti<br />

<strong>in</strong> term<strong>in</strong>i di Service Level Specifications (SLS). Le SLS comprendono:<br />

• il rendimento aspettato<br />

• <strong>la</strong> probabilità di cancel<strong>la</strong>zioni<br />

• i ritardi<br />

• i v<strong>in</strong>coli sui punti di entrata e uscita dal servizio<br />

• lo scopo <strong>del</strong> servizio<br />

• le caratteristiche <strong>del</strong> traffico necessarie <strong>per</strong> far sì che una richiesta<br />

sia fornita<br />

62


__________________________________________________________________<br />

• i metodi di gestione <strong>del</strong> traffico che eccede il profilo specificato<br />

• <strong>la</strong> c<strong>la</strong>ssificazione e <strong>la</strong> manipo<strong>la</strong>zione dei servizi forniti.<br />

2- Traffic Condition<strong>in</strong>g Specifications. Il TCS è un accordo che c<strong>la</strong>ssifica le<br />

regole e tutte le corrispondenze tra i vari profili e le metriche di traffico da<br />

applicare. Il TCS rafforza tutte le condizioni <strong>del</strong> traffico e i requisiti <strong>del</strong><br />

servizio già specificati nel SLA.<br />

Figura 3.2: Esempio di SLA<br />

3.2 LA GESTIONE DELLA QUALITA’ DEL SERVIZIO<br />

Circa <strong>la</strong> gestione <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio si è visto che è realizzabile direttamente<br />

su Ethernet oltre che su IP e l’una non esclude l’altra. La QoS implementata su<br />

Ethernet assume <strong>per</strong>ò un aspetto locale ed esu<strong>la</strong> dagli obiettivi di questo <strong>la</strong>voro,<br />

<strong>per</strong> questo motivo nel seguito verrà preso <strong>in</strong> considerazione il solo aspetto<br />

<strong>del</strong>l’implementazione <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio su IP.<br />

Le <strong>reti</strong> attuali sono fondate sul protocollo IP e offrono un solo tipo di servizio: il<br />

“best effort”. Infatti il protocollo IP non fa nessuna ipotesi sul tipo di servizio<br />

fornito dagli strati <strong>in</strong>feriori e svolge <strong>la</strong> so<strong>la</strong> funzione di trasferimento dati senza<br />

63


__________________________________________________________________<br />

offrire garanzia sul<strong>la</strong> qualità <strong>del</strong> servizio. Tale garanzia è demandata ai protocolli<br />

<strong>del</strong>lo strato di trasporto, tipicamente il TCP (Trasmission Control Protocol), e<br />

residenti sui term<strong>in</strong>ali <strong>del</strong><strong>la</strong> connessione, che provvedono al riord<strong>in</strong>amento dei<br />

pacchetti fuori sequenza ed al<strong>la</strong> richiesta di ritrasmissione nel caso di <strong>per</strong>dita o di<br />

errore. Questo tipo di sistema <strong>per</strong>ò, che è risultato v<strong>in</strong>cente <strong>per</strong> i servizi di solo<br />

trasferimento dati, è <strong>in</strong>adatto <strong>per</strong> i servizi real-time; i protocolli di trasporto <strong>in</strong>fatti,<br />

non offrono nessuna garanzia sui ritardi e sul<strong>la</strong> portata. I soli meccanismi di<br />

controllo posti sui term<strong>in</strong>ali sono dunque <strong>in</strong>efficienti nelle <strong>reti</strong> multiservizio ed è<br />

qu<strong>in</strong>di necessario <strong>in</strong>tervenire all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete. Le metodologie che affrontate<br />

nel seguito <strong>per</strong> <strong>la</strong> gestione <strong>del</strong><strong>la</strong> QoS riguardano dunque l’architettura <strong>del</strong><strong>la</strong> rete e<br />

non i term<strong>in</strong>ali <strong>del</strong>l’utenza, tali tecnologie sono IntServ ( Integrated Service) e<br />

DiffServ ( Differentiated Service).<br />

3.2.1 IntServ: Integrated Service<br />

Le <strong>reti</strong> odierne essendo basate sul protocollo IP sono connectionless:<br />

l’assegnazione <strong>del</strong><strong>la</strong> banda è su domanda, non vi è una fase di <strong>in</strong>staurazione <strong>del</strong><strong>la</strong><br />

connessione e l’utente può <strong>in</strong>viare pacchetti <strong>in</strong> qualsiasi momento senza chiedere<br />

preventivamente il <strong>per</strong>messo all’o<strong>per</strong>atore. Le risorse <strong>del</strong><strong>la</strong> rete qu<strong>in</strong>di vengono<br />

condivise da tutti gli utenti, nessuna richiesta di accesso viene rifiutata ma non<br />

può essere garantita <strong>la</strong> qualità <strong>del</strong> servizio.<br />

La tecnologia IntServ si basa sul concetto di pre-assegnazione 5 collettiva <strong>del</strong>le <strong>reti</strong><br />

ATM e risulta essere un’architettura di riferimento, ottenuta <strong>in</strong>tegrando quel<strong>la</strong><br />

c<strong>la</strong>ssica Internet, <strong>per</strong> supportare diverse c<strong>la</strong>ssi di servizio <strong>in</strong> aggiunta a quel<strong>la</strong> già<br />

esistente chiamata Best Effort. Per avere garanzie di QoS è necessario avere una<br />

connessione e il controllo di accesso. Poiché <strong>in</strong> una rete IP è connection-less viene<br />

5 Durante <strong>la</strong> fase di <strong>in</strong>staurazione l’utente chiede l’assegnazione di una determ<strong>in</strong>ata quantità di<br />

risorse e l’o<strong>per</strong>atore, nel caso <strong>in</strong> cui tali risorse siano disponibili, le assegna i modo virtuale: le<br />

risorse vengono assegnate collettivamente a tutti gli utenti abilitati.<br />

64


__________________________________________________________________<br />

<strong>in</strong>trodotto il concetto di flusso 6 e le c<strong>la</strong>ssi di servizio IntServ garantiscono al<br />

flusso stesso pre-determ<strong>in</strong>ate prestazioni di rete. I livelli prestazionali forniti da<br />

una data c<strong>la</strong>sse di servizio sono richiedibili su base flusso: una certa applicazione<br />

term<strong>in</strong>ale richiede determ<strong>in</strong>ate prestazioni e il re<strong>la</strong>tivo flusso <strong>in</strong>formativo sarà<br />

trattato dal<strong>la</strong> rete <strong>in</strong> modo da soddisfare le richieste <strong>del</strong>l’applicazione. Le risorse<br />

necessarie a soddisfare le richieste di ciascuna applicazione vengono allocate <strong>in</strong><br />

maniera soft mediante il protocollo RSVP ( ReSource reserVation Protocol ) che<br />

verrà trattato <strong>in</strong> seguito.<br />

Per il problema <strong>del</strong> controllo di accesso, ogni router deve esercitare una funzione<br />

di Admission Control <strong>per</strong> assicurare che le richieste siano accettate solo se<br />

esistono risorse sufficienti a garantire le prestazioni volute. Una volta che questa<br />

procedura è stata eseguita da tutti i routers attraversati dal flusso potranno essere<br />

garantite le caratteristiche prestazionali richieste.<br />

Le c<strong>la</strong>ssi di servizio previste dal IntServ , oltre a quel<strong>la</strong> Best Effort, sono due:<br />

1- Guaranteed Service ( <strong>Servizio</strong> Garantito): questo servizio fornisce un fissato<br />

ritmo b<strong>in</strong>ario di trasferimento, un limite su<strong>per</strong>iore al one-way de<strong>la</strong>y e<br />

l’assenza di <strong>per</strong>dita <strong>del</strong>le unità <strong>in</strong>formative. E’ stato concepito <strong>per</strong><br />

applicazioni hard real-time che sono altamente sensibili a valori di<br />

aspettazione e varianza <strong>del</strong> ritardo end-to-end. L’applicazione che richiede il<br />

servizio dovrà fornire un <strong>in</strong>sieme di parametri che descrivono il traffico che<br />

emetterà, il cosiddetto TSpec (5 parametri), ed un altro <strong>in</strong>sieme di parametri<br />

che specificano le prestazioni attese, RSpec ( 2 parametri ). L’<strong>in</strong>sieme<br />

formato dalle precedenti dichiarazioni viene detto Call Admission e necessita<br />

<strong>del</strong> protocollo di segna<strong>la</strong>zione RSVP. Il traffico appartenente a questo<br />

servizio viene control<strong>la</strong>to all’<strong>in</strong>gresso <strong>del</strong><strong>la</strong> rete e “mo<strong>del</strong><strong>la</strong>to” all’<strong>in</strong>terno di<br />

essa aff<strong>in</strong>chè rispetti le specifiche <strong>in</strong>dicate <strong>in</strong> TSpec; <strong>in</strong> caso negativo, i<br />

datagrammi non conformi vengono trattati come traffico Best Effort oppure<br />

scartati.<br />

6 Per flusso si <strong>in</strong>tende un aggregato di dati appartenenti al<strong>la</strong> stessa applicazione.<br />

65


__________________________________________________________________<br />

2- Controlled Load Service ( <strong>Servizio</strong> a carico control<strong>la</strong>to): questo servizio<br />

non offre partico<strong>la</strong>ri garanzie di prestazioni. L’applicazione, diversamente<br />

dal <strong>Servizio</strong> Garantito, comunica solo i parametri di traffico TSpec e il<br />

re<strong>la</strong>tivo flusso <strong>in</strong>formativo verrà trattato come un traffico di tipo Best Effort<br />

<strong>in</strong> una rete poco carica. Tale servizio è stato concepito <strong>per</strong> applicazioni soft<br />

real-time <strong>del</strong><strong>la</strong> rete IP che funzionano bene <strong>in</strong> una rete non sovraccarica.<br />

Anche <strong>per</strong> questo tipo di servizio è previsto sia il controllo di ammissione<br />

all’<strong>in</strong>gresso <strong>del</strong><strong>la</strong> rete e sia lo “shap<strong>in</strong>g” <strong>del</strong> traffico all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete<br />

stessa <strong>per</strong> verificare <strong>la</strong> conformità <strong>del</strong> flusso rispetto alle specifiche TSpec. In<br />

caso di non conformità <strong>del</strong> traffico i datagrammi vengono trattati come<br />

traffico best effort oppure scartati. La differenza sostanziale tra il servizio a<br />

carico control<strong>la</strong>to e il servizio best effort è il controllo di accesso mentre le<br />

differenze con il servizio garantito sono: le politiche di ammissione più<br />

flessibili, le garanzie prestazionali meno restrittive e dipendenza dal<strong>la</strong><br />

capacità di adattamento <strong>del</strong>l’applicazione che richiede il servizio.<br />

Vediamo ora più dettagliatamente il protocollo di segna<strong>la</strong>zione RSVP e il<br />

protocollo di trasporto RTP, realizzati appositamente <strong>per</strong> l’ IntServ e poi ripresi<br />

anche <strong>per</strong> <strong>la</strong> tecnologia DiffServ.<br />

3.2.2 Il Protocollo RSVP<br />

Il protocollo RSVP è un protocollo che <strong>per</strong>mette <strong>la</strong> riservazione “soft” <strong>del</strong>le<br />

risorse all'<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete <strong>in</strong> modo da garantire una fissata QoS a determ<strong>in</strong>ati<br />

flussi di dati all'<strong>in</strong>terno di una sessione. Per sessione si <strong>in</strong>tende un <strong>in</strong>sieme di uno<br />

o più flussi di dati caratterizzati da una certa dest<strong>in</strong>azione ed un certo protocollo di<br />

trasporto.<br />

Il protocollo RSVP usa dei messaggi di controllo, <strong>in</strong>capsu<strong>la</strong>ti <strong>in</strong> pacchetti IP.<br />

Quando un host richiede un <strong>in</strong>sieme di risorse <strong>per</strong> avere una certa QoS, <strong>in</strong>via un<br />

messaggio RSVP denom<strong>in</strong>ato Path con lo stesso <strong>in</strong>dirizzo IP di dest<strong>in</strong>azione dei<br />

dati. Con questo messaggio <strong>la</strong> sorgente notifica ai possibili host riceventi e ai<br />

router <strong>in</strong>termedi <strong>la</strong> presenza di un flusso di dati e le proprie caratteristiche di<br />

66


__________________________________________________________________<br />

traffico. Un host dest<strong>in</strong>atario che abbia ricevuto un messaggio Path, nel caso <strong>in</strong><br />

cui sia <strong>in</strong>teressato a ricevere i dati con QoS garantita, <strong>in</strong>via un messaggio di<br />

richiesta di prenotazione di risorse, detto Resv, nel quale specifica <strong>la</strong> QoS con cui<br />

vuole ricevere il flusso di dati generato dal<strong>la</strong> sorgente; di conseguenza, <strong>in</strong> una<br />

trasmissione di tipo multipunto-multipunto ciascun host ricevente può <strong>in</strong>dicare<br />

esplicitamente le sorgenti dalle quali ricevere con QoS garantita e quale QoS<br />

riservare a ciascun flusso di dati. Il protocollo RSVP offre qu<strong>in</strong>di sotto questo<br />

aspetto <strong>la</strong> massima flessibilità ed evita <strong>in</strong>utili sprechi di risorse.<br />

Figura 3.3: Diagramma <strong>del</strong>le o<strong>per</strong>azioni svolte <strong>in</strong> un nodo al<strong>la</strong> ricezione di un messaggio Resv<br />

Aff<strong>in</strong>chè ogni nodo presente sul camm<strong>in</strong>o dal<strong>la</strong> sorgente agli host riceventi possa<br />

allocare le risorse necessarie ad assicurare <strong>la</strong> QoS richiesta, i messaggi Resv<br />

devono <strong>per</strong>correre a ritroso lo stesso camm<strong>in</strong>o seguito dai messaggi Path e dal<br />

flusso di dati vero e proprio. Quando un messaggio Resv giunge ad un nodo,<br />

questi esegue determ<strong>in</strong>ati controlli <strong>per</strong> verificare se sono presenti risorse<br />

67


__________________________________________________________________<br />

sufficienti <strong>per</strong> soddisfare <strong>la</strong> richiesta. Se <strong>in</strong> tutti i nodi presenti sul camm<strong>in</strong>o questi<br />

controlli hanno un esito positivo allora vengono allocate lungo l'<strong>in</strong>tero <strong>per</strong>corso<br />

dal<strong>la</strong> sorgente al dest<strong>in</strong>atario le risorse necessarie al trasporto <strong>del</strong> flusso di dati <strong>in</strong><br />

questione con <strong>la</strong> QoS richiesta.<br />

In ogni nodo i messaggi Resv provenienti dai nodi a valle e re<strong>la</strong>tivi allo stesso<br />

flusso di dati vengono fusi <strong>in</strong>sieme prima di essere ulteriormente propagati verso<br />

<strong>la</strong> sorgente; se ad un nodo giungono due richieste di prenotazione da parte di due<br />

host re<strong>la</strong>tive allo stesso flusso di dati, tale nodo propaga verso <strong>la</strong> sorgente di tale<br />

flusso un'unica richiesta contenente <strong>la</strong> QoS più str<strong>in</strong>gente <strong>in</strong> term<strong>in</strong>i di qualità.<br />

Figura 10: Schema semplificato <strong>del</strong>lo scambio dei messaggi RSVP tra sorgenti e dest<strong>in</strong>atari<br />

Le risorse allocate <strong>in</strong> ciascun nodo e necessarie ad assicurare ad un certo flusso di<br />

dati <strong>la</strong> QoS richiesta non vengono tenute riservate <strong>in</strong>def<strong>in</strong>itamente, dopo un certo<br />

<strong>per</strong>iodo di tempo vengono liberate. Qu<strong>in</strong>di gli host sorgente e ricevente<br />

rispettivamente devono <strong>per</strong>iodicamente <strong>in</strong>viare dei messaggi Path e Resv di<br />

“refresh” <strong>per</strong> notificare ai nodi l'<strong>in</strong>tenzione di cont<strong>in</strong>uare a ricevere con una certa<br />

QoS una data sessione. Il meccanismo di refresh <strong>per</strong>mette <strong>in</strong>oltre al protocollo<br />

RSVP di adattarsi <strong>in</strong> maniera d<strong>in</strong>amica ai cambiamenti dei <strong>per</strong>corsi di<br />

<strong>in</strong>stradamento seguiti dai dati.<br />

Nel protocollo RSVP sono previsti due tipi di messaggi di errore: ResvErr e<br />

PathErr. Il messaggio di tipo PathErr è semplicemente trasmesso verso l'host<br />

sorgente che ha causato l'errore e non provoca alcun cambiamento nei router che<br />

attraversa. Sono pochi i motivi che possono causare un PathErr. Ad esempio<br />

un'applicazione potrebbe specificare nel messaggio Path parametri di traffico non<br />

congruenti, oppure <strong>in</strong>dicare nell'identificatore di sessione un numero di porta<br />

<strong>in</strong>compatibile col valore di ProtocolID.<br />

68


__________________________________________________________________<br />

Sono <strong>in</strong>vece più frequenti i messaggi <strong>del</strong> tipo ResvErr, e sono generalmente<br />

causati dal<strong>la</strong> mancanza di risorse <strong>in</strong> rete necessarie <strong>per</strong> accogliere una certa<br />

richiesta, o dal<strong>la</strong> mancanza dei requisiti <strong>per</strong> effettuare <strong>la</strong> prenotazione da parte <strong>del</strong><br />

richiedente. La gestione dei messaggi ResvErr è anche più complessa, <strong>in</strong> quanto,<br />

a causa <strong>del</strong> meccanismo di fusione, una richiesta di prenotazione di risorse è<br />

usualmente il frutto di più richieste, <strong>per</strong> cui un messaggio ResvErr deve essere<br />

notificato a tutti gli host riceventi che sono gli <strong>in</strong>iziatori di quelle richieste.<br />

Ogni richiesta di prenotazione <strong>del</strong>le risorse contiene al suo <strong>in</strong>terno un oggetto<br />

attraverso cui l'host ricevente specifica <strong>la</strong> QoS richiesta ed identifica il flusso di<br />

dati cui riservare quel<strong>la</strong> QoS. Tale oggetto è detto flow descriptor, ed è a sua<br />

volta costituito dal<strong>la</strong> coppia (flowspec, filter spec). Il flowspec 7 specifica <strong>la</strong><br />

QoS desiderata, mentre il filter spec identifica il flusso di dati al quale<br />

riservare <strong>la</strong> QoS <strong>in</strong>dicata dal flowspec. In ogni nodo ogni richiesta di<br />

prenotazione di risorse <strong>in</strong>teragisce con due entità locali: l'admission control ed il<br />

policy control: l'admission control verifica se <strong>la</strong> richiesta può essere esaudita,<br />

ovvero se sono presenti risorse sufficienti a garantire <strong>la</strong> QoS specificata nel<br />

flowspec senza <strong>in</strong>correre nel rischio che si deteriori <strong>la</strong> QoS riservata agli altri<br />

flussi di dati che <strong>in</strong> quel momento stanno attraversando il nodo <strong>in</strong> oggetto; il<br />

policy control verifica <strong>in</strong>vece che l'host richiedente sia autorizzato ad <strong>in</strong>oltrare tale<br />

richiesta, ed <strong>in</strong> più memorizza dei dati necessari successivamente al<strong>la</strong> tariffazione<br />

<strong>del</strong> servizio offerto. Se entrambi i controlli sono positivi, le <strong>in</strong>formazioni<br />

contenute negli oggetti flowspec e filter spec vengono rispettivamente<br />

utilizzate <strong>per</strong> configurare i parametri di due moduli: il packet scheduler, che ha il<br />

compito di dividere i pacchetti che giungono al nodo sul<strong>la</strong> base <strong>del</strong><strong>la</strong> QoS loro<br />

assegnata, ed il packet c<strong>la</strong>ssifier, che <strong>in</strong>via i datagrammi IP sul mezzo fisico <strong>in</strong><br />

maniera da rispettare <strong>la</strong> QoS negoziata selezionando i pacchetti dalle code ed<br />

<strong>in</strong>oltrandoli <strong>in</strong> rete al momento opportuno.<br />

7 Il flowspec <strong>in</strong> una richiesta di prenotazione è <strong>in</strong> generale composto da due set di parametri:<br />

Rspec, che specifica <strong>la</strong> QoS richiesta, e Tspec, che descrive le caratteristiche <strong>del</strong> flusso di<br />

dati cui assegnare <strong>la</strong> QoS richiesta<br />

69


__________________________________________________________________<br />

Figura 11: Sezione di I/O di un nodo IP<br />

Ogni richiesta di prenotazione <strong>del</strong>le risorse è caratterizzata da uno "stile di<br />

prenotazione" (reservation style). Attualmente sono def<strong>in</strong>iti tre stili di<br />

prenotazione:<br />

• Wildcard Filter (WF) style: se un ricevitore, appartenente ad un certo<br />

gruppo multicast, utilizza <strong>in</strong> una sua richiesta lo stile WF, allora esso vuole<br />

ricevere con <strong>la</strong> QoS specificata tutti i pacchetti <strong>in</strong>dirizzati a quel gruppo<br />

multicast, <strong>in</strong>dipendentemente da chi li trasmette: di conseguenza le risorse<br />

allocate nel<strong>la</strong> rete sul<strong>la</strong> base di quanto <strong>in</strong>dicato nel flowspec saranno<br />

condivise tra tutti coloro che <strong>in</strong> un certo istante trasmettono all'<strong>in</strong>dirizzo IP<br />

multicast cui appartiene l'host che ha richiesto <strong>la</strong> prenotazione.<br />

• Fixed Filter (FF) style: <strong>in</strong> una richiesta con stile FF l'host ricevente <strong>in</strong>dica<br />

esplicitamente quali flussi di dati vuole ricevere e con quale QoS; <strong>in</strong> altri<br />

term<strong>in</strong>i esso specifica nel<strong>la</strong> sua richiesta una serie di flow descriptor,<br />

ognuno associato ad un determ<strong>in</strong>ato flusso di dati.<br />

• Shared Explicit (SE) style: <strong>in</strong> una richiesta con stile SE l'host ricevente<br />

<strong>in</strong>dica una serie di flussi di dati che vuole ricevere (vale a dire una serie di<br />

sorgenti), ma associa ad essi un unico flowspec da condividere tra tutti i<br />

trasmettitori.<br />

Ogni richiesta di prenotazione <strong>del</strong>le risorse Resv deve essere soggetta ad un<br />

controllo amm<strong>in</strong>istrativo <strong>per</strong> verificarne <strong>la</strong> leggittimità, ovvero <strong>per</strong> control<strong>la</strong>re che<br />

le risorse richieste non eccedano un certo limite prestabilito e che il richiedente sia<br />

70


__________________________________________________________________<br />

autorizzato ad <strong>in</strong>oltrare richieste. A tal scopo i messaggi Resv possono<br />

comprendere dei "policy data" che contengono dei dati identificativi <strong>del</strong>l'utente<br />

che chiede le risorse. Il protocollo RSVP non <strong>in</strong>terpreta i policy data, ma li<br />

trasporta <strong>in</strong> modo trasparente e li passa ad un Local Policy Module (LPM) che<br />

esegue gli opportuni controlli e gestisce <strong>la</strong> tariffazione <strong>per</strong> I servizi richiesti.<br />

Non tutti i nodi sono dotati <strong>del</strong> LPM, <strong>in</strong> quanto il policy control viene usualmente<br />

eseguito ai conf<strong>in</strong>i di un dom<strong>in</strong>io amm<strong>in</strong>istrativo. In un nodo il modulo LPM<br />

svolge essenzialmente tre funzioni: anzitutto, riceve i policy data contenuti nei<br />

messaggi Resv che arrivano al nodo; poi, <strong>in</strong>terpreta tali dati e modifica il proprio<br />

stato di conseguenza, ad esempio aggiornando il numero di scatti dei vari utenti<br />

necessari poi <strong>per</strong> <strong>la</strong> tariffazione <strong>del</strong> servizio offerto, <strong>in</strong>f<strong>in</strong>e, deve generare i policy<br />

data da <strong>in</strong>cludere nei messaggi Resv che il nodo <strong>in</strong>via a sua volta sul<strong>la</strong> rete.<br />

3.2.3 Il protocollo RTP<br />

Il protocollo RTP ( Real-time Trasport Protocol ) è stato creato <strong>per</strong> estendere le<br />

funzionalità <strong>del</strong> protocollo TCP <strong>in</strong> modo da poterlo utilizzare anche <strong>per</strong> il<br />

trasporto di traffico real-time. Il protocollo RTP può o<strong>per</strong>are appoggiandosi su<br />

protocolli sia di tipo connection-oriented che connection-less e richiede che i<br />

servizi di frammentazione e riassemb<strong>la</strong>ggio dei pacchetti siano a carico degli strati<br />

<strong>in</strong>feriori. Il protocollo RTP non offre nessun meccanismo <strong>per</strong> assicurare <strong>la</strong><br />

consegna dei pacchetti entro tempi prestabiliti o alcun genere di garanzia circa <strong>la</strong><br />

qualità <strong>del</strong> servizio, ma si appoggia ai servizi forniti dai livelli <strong>in</strong>feriori nel<strong>la</strong><br />

gerarchia ISO-OSI come, <strong>per</strong> esempio, all’UDP/IP.<br />

Il pacchetto RTP rappresenta l’unità m<strong>in</strong>ima di <strong>in</strong>formazione utilizzata dal<br />

protocollo RTP <strong>per</strong> trasportare i dati forniti dall'applicazione e le <strong>in</strong>formazioni<br />

descrittive di tali dati: esso è formato da un’<strong>in</strong>testazione e dai dati.<br />

Header<br />

L’header costituisce <strong>la</strong> parte <strong>in</strong>iziale di ogni pacchetto RTP e contiene<br />

<strong>in</strong>formazioni di controllo che sono utili al<strong>la</strong> gestione <strong>del</strong> flusso di dati. È<br />

71


__________________________________________________________________<br />

composto da una parte fissa e da un’eventuale parte opzionale. La parte fissa<br />

<strong>del</strong>l’<strong>in</strong>testazione trasporta <strong>in</strong>formazioni utili <strong>per</strong> <strong>la</strong> corretta <strong>in</strong>terpretazione,<br />

identificazione e s<strong>in</strong>cronizzazione dei dati contenuti nel payload.<br />

La parte fissa <strong>del</strong>l’header ha il seguente formato:<br />

Figura 3.6: Parte fissa <strong>del</strong>l’ header di un pacchetto RTP<br />

Tra le funzioni pr<strong>in</strong>cipali <strong>del</strong> RTP sono <strong>in</strong>cluse l’identificazione <strong>del</strong> carico<br />

pagante, il payload, <strong>la</strong> serializzazione dei pacchetti ( Sequence Number ), <strong>per</strong><br />

determ<strong>in</strong>are le <strong>per</strong>dite e le <strong>in</strong>versioni nel<strong>la</strong> sequenza dei pacchetti, e il “timestamp<strong>in</strong>g”,<br />

necessario <strong>per</strong> equalizzare i tempi di ritardo dei pacchetti. E’ noto,<br />

<strong>in</strong>fatti, che nelle <strong>reti</strong> a commutazione di pacchetto, ogni unità <strong>in</strong>formativa viene<br />

trattata <strong>in</strong> modo <strong>in</strong>dipendente dalle altre, s<strong>per</strong>imentando all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete<br />

tempi di propagazione diversi: <strong>la</strong> rete <strong>in</strong>troduce il jitter. Questo vuol dire che <strong>la</strong><br />

rete non è temporalmente trasparente, caratteristica che <strong>in</strong>vece è essenziale <strong>per</strong> i<br />

servizi real-time che richiedono un jitter molto basso o al limite nullo.<br />

Per equalizzare i ritardi dei pacchetti, questi ultimi vengono memorizzati, prima di<br />

essere passati all’applicazione <strong>in</strong>teressata, <strong>in</strong> un buffer detto di p<strong>la</strong>y-out che<br />

<strong>in</strong>troduce a sua volta un ulteriore ritardo: <strong>per</strong> i pacchetti con ritardo maggiore<br />

verrà aggiunto un piccolo ritardo mentre quelli con ritardo m<strong>in</strong>ore verranno<br />

maggiormente ritardati.<br />

72


__________________________________________________________________<br />

Figura 12: Ritardo di p<strong>la</strong>y-out<br />

Perchè questo sistema funzioni bisogna conoscere l’istante <strong>in</strong> cui è stata emessa<br />

l’unità <strong>in</strong>formativa <strong>per</strong> poter stabilire <strong>in</strong> quale istante deve essere consegnata<br />

all’applicazione ricevente. Se <strong>la</strong> sorgente è a ritmo b<strong>in</strong>ario costante è sufficiente<br />

conoscere l’<strong>in</strong>tervallo che <strong>in</strong>tercorre tra l’emissione di due unità <strong>in</strong>formative<br />

consecutive; se il ritmo è variabile viene utilizzata <strong>la</strong> procedura “time stamp<strong>in</strong>g”,<br />

ad ogni pacchetto viene aggiunta una ulteriore <strong>in</strong>formazione: l’istante di<br />

emissione.<br />

Al protocollo RTP viene affiancato un protocollo ausiliario, denom<strong>in</strong>ato RTCP<br />

(RTP Control Protocol) <strong>per</strong> <strong>la</strong> rilevazione <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio, <strong>per</strong> il<br />

controllo <strong>del</strong><strong>la</strong> sessione e <strong>per</strong> le funzioni di identificazione dei partecipanti.<br />

L’RTP Control Protocol (RTCP) è <strong>la</strong> componente <strong>del</strong> protocollo RTP che si<br />

occupa <strong>del</strong> controllo e <strong>del</strong> monitoraggio <strong>del</strong> flusso dei dati trasportati nei pacchetti<br />

RTP. Lo scopo di RTCP è quello di fornire alle applicazioni un meccanismo che<br />

consenta di valutare <strong>la</strong> qualità <strong>del</strong> servizio che <strong>la</strong> rete, <strong>per</strong> mezzo di RTP, può<br />

offrire e di gestire, allo stesso tempo, il controllo dei partecipanti ad una sessione.<br />

RTCP si basa sul<strong>la</strong> trasmissione <strong>per</strong>iodica di pacchetti di controllo a tutti i<br />

partecipanti di una sessione utilizzando lo stesso meccanismo di distribuzione dei<br />

pacchetti di dati: <strong>la</strong> separazione tra pacchetti di dati e di controllo deve essere<br />

fornita dai protocolli sottostanti, <strong>per</strong> esempio utilizzando due porte separate <strong>in</strong><br />

UDP.<br />

73


__________________________________________________________________<br />

Ogni pacchetto RTCP <strong>in</strong>izia con una parte fissa simile a quel<strong>la</strong> dei pacchetti dati<br />

RTP, seguita da elementi strutturati che possono essere di lunghezza variabile <strong>in</strong><br />

base al tipo di pacchetto, ma sempre multipli di 32 bit. Tale caratteristica, unita<br />

all’<strong>in</strong>dicazione <strong>del</strong><strong>la</strong> lunghezza contenuta nel<strong>la</strong> parte fissa, <strong>per</strong>mette di<br />

concatenare più pacchetti RTCP <strong>in</strong> un unico pacchetto <strong>del</strong> protocollo di livello<br />

<strong>in</strong>feriore. Non esiste neanche un esplicito conteggio <strong>del</strong>le s<strong>in</strong>gole porzioni<br />

contenute <strong>in</strong> un pacchetto composto, <strong>in</strong> quanto è previsto che l’<strong>in</strong>dicazione <strong>del</strong><strong>la</strong><br />

lunghezza totale venga <strong>in</strong>dicata dai livelli <strong>in</strong>feriori.<br />

Il protocollo RTP si appoggia sui protocolli sottostanti <strong>per</strong> dist<strong>in</strong>guere i flussi di<br />

dati dai flussi di controllo: nel caso di UDP e protocolli simili, <strong>per</strong> RTP utilizza un<br />

numero di porta pari e <strong>per</strong> i pacchetti RTCP corrispondenti, <strong>la</strong> porta<br />

immediatamente su<strong>per</strong>iore.<br />

Figura 13: Esempio di applicazione real-time con protocollo RTP<br />

74


__________________________________________________________________<br />

3.2.4 DiffServ (Differentiated Services)<br />

La tecnologia DiffServ si fonda sul meccanismo di allocazione preferenziale <strong>del</strong>le<br />

risorse: vengono <strong>in</strong>trodotti dei livelli di priorità e <strong>in</strong> base ad essi il traffico viene<br />

trattato <strong>in</strong> un determ<strong>in</strong>ato modo. Il concetto di flusso <strong>in</strong>formativo, <strong>in</strong>trodotto nel<br />

IntServ, non ha più significato <strong>in</strong> questo mo<strong>del</strong>lo: i router non devono più gestire<br />

una connessione <strong>per</strong> ogni flusso ma prendono decisioni direttamente sul s<strong>in</strong>golo<br />

datagramma.<br />

L’<strong>in</strong>formazione sul trattamento che un datagramma deve ricevere è trasportata dal<br />

datagramma stesso evitando così <strong>la</strong> necessità <strong>del</strong>lo scambio <strong>del</strong>le <strong>in</strong>formazioni di<br />

controllo tra i routers e il mantenimento degli stati nei sistemi attraversati (tramite<br />

RSVP).<br />

L’idea <strong>del</strong> DiffServ è quel<strong>la</strong> di fornire differenti servizi creando <strong>del</strong>le c<strong>la</strong>ssi con<br />

diverse priorità; <strong>per</strong> fare questo viene usato il campo DSCP ( DiffServ Code<br />

Po<strong>in</strong>t), ottenuto dal campo type-of-service (TOS) <strong>del</strong> pacchetto IPv4 o dal campo<br />

traffic c<strong>la</strong>ss di IPv6. Con le c<strong>la</strong>ssi di servizio tutti i datagrammi vengono riuniti <strong>in</strong><br />

pochi flussi aggregati, BA 8 – Behaviour Aggregate, ai quali sono assegnati<br />

diversi trattamenti all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete.<br />

All’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete non esiste nessuna richiesta fatta da un flusso <strong>per</strong> ottenere un<br />

determ<strong>in</strong>ato trattamento <strong>in</strong> term<strong>in</strong>i di QoS.<br />

Il meccanismo DiffServ può essere riassunto nel modo seguente:<br />

- ai bordi <strong>del</strong><strong>la</strong> rete i s<strong>in</strong>goli pacchetti vengono c<strong>la</strong>ssificati dagli Edge Router 9 che<br />

marcano il campo DSCP presente nel<strong>la</strong> loro <strong>in</strong>testazione <strong>in</strong> base ai requisisti<br />

prestazionali richiesti;<br />

- ogni valore <strong>del</strong> campo DSCP corrisponde ad una c<strong>la</strong>sse di servizio e tutti i<br />

pacchetti aventi lo stesso campo DSCP riceveranno lo stesso trattamento<br />

all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete;<br />

8 Behaviour Aggregate ( BA): un <strong>in</strong>sieme di pacchetti con lo stesso DSCP che attraversano un l<strong>in</strong>k<br />

<strong>in</strong> una partico<strong>la</strong>re direzione<br />

9 Edge Router: sono i router ai bordi di un dom<strong>in</strong>io DS. Essi svolgono le funzioni fondamentali<br />

che prevede l’architettura DiffServ quali <strong>la</strong> c<strong>la</strong>ssificazione dei pacchetti, <strong>la</strong> marcatura <strong>del</strong> campo<br />

DSCP e <strong>la</strong> polic<strong>in</strong>g-shap<strong>in</strong>g <strong>del</strong> traffico.<br />

75


__________________________________________________________________<br />

- i pacchetti, una volta c<strong>la</strong>ssificati, vengono immessi nel<strong>la</strong> rete;<br />

- all’<strong>in</strong>terno <strong>del</strong><strong>la</strong> rete <strong>in</strong> ogni router vengono def<strong>in</strong>iti i PHB 10 ( Per Hop<br />

Behaviour) ovvero i comportamenti corrispondenti alle c<strong>la</strong>ssi di servizio con le<br />

quali sono c<strong>la</strong>ssificati i pacchetti;<br />

- quando un pacchetto arriva <strong>in</strong> un Core Router 11 , quest’ultimo esam<strong>in</strong>a il campo<br />

DSCP e tratterà il pacchetto <strong>in</strong> base al<strong>la</strong> c<strong>la</strong>sse di servizio corrispondente.<br />

Si osservi <strong>in</strong>oltre che DiffServ specifica solo il campo DSCP, e dunque le c<strong>la</strong>ssi di<br />

servizio, e i PHBs dei routers mentre spetta all’o<strong>per</strong>atore decidere quali partico<strong>la</strong>ri<br />

prestazioni far corrispondere al<strong>la</strong> s<strong>in</strong>go<strong>la</strong> coppia DSCP-PHB; <strong>in</strong>oltre DiffServ non<br />

specifica dei servizi: il servizio <strong>per</strong>cepito dall’utente è semplicemente il risultato<br />

dei vari PHB. Come <strong>per</strong> <strong>la</strong> tecnologia IntServ, un utente che vuole ricevere un<br />

servizio differenziato si deve accordare con il Service Provider stipu<strong>la</strong>ndo un<br />

SLA.<br />

10 Per Hop Behaviour ( PHB ): una descrizione <strong>del</strong> modo di <strong>in</strong>stradare un partico<strong>la</strong>re aggregato da<br />

parte di un router DS, così come lo si vede esternamente; è def<strong>in</strong>ito dai parametri <strong>del</strong>l’algoritmo di<br />

schedul<strong>in</strong>g, dal<strong>la</strong> quota di buffer e dal<strong>la</strong> quota di banda che di fatto consentono di ottenere un<br />

diverso servizio<br />

11 Core Router: sono router ad altissima capacità all’<strong>in</strong>terno <strong>del</strong> dom<strong>in</strong>io DS. Essi hanno il solo<br />

compito di eseguire i PHB sui datagrammi già c<strong>la</strong>ssificati e marcati dagli edge-router<br />

76


__________________________________________________________________<br />

3.2.5 Il campo DSCP<br />

Il campo DSCP è composto di sei bit ed è usato <strong>per</strong> identificare i flussi<br />

appartenenti ad un aggregato e associarli ad un PHB, deriva dal campo TOS<br />

( Type Of Service ) <strong>in</strong>trodotto già da tempo <strong>in</strong> IPv4.<br />

Figura 14: Campo DSCP ottenuto dal<strong>la</strong> ridef<strong>in</strong>izione <strong>del</strong> campo TOS<br />

Come si vede dal<strong>la</strong> figura il campo TOS è stato ridef<strong>in</strong>ito dal IETF appositamente<br />

<strong>per</strong> DiffServ: i sei bit più significativi sono stati def<strong>in</strong>iti DSCP mentre gli ultimi<br />

due rappresentano il campo CU che <strong>per</strong> ora non viene utilizzato e che si<br />

raccomanda di non utilizzare <strong>in</strong> nessuna implementazione.<br />

77


__________________________________________________________________<br />

3.2.6 PHB: Per-Hop Behaviour<br />

Nell’architettura DiffServ abbiamo, oltre al Best Effort, due c<strong>la</strong>ssi di servizio:<br />

Figura 15: C<strong>la</strong>ssi di <strong>Servizio</strong> nel<strong>la</strong> metodologia DiffServ<br />

1- Expedited Forward<strong>in</strong>g: Il PHB Expedited Forward<strong>in</strong>g <strong>per</strong>mette di offrire<br />

le prestazioni di una l<strong>in</strong>ea dedicata virtuale, caratterizzata da:<br />

• basse <strong>per</strong>dite;<br />

• basse <strong>la</strong>tenze;<br />

• basso jitter;<br />

• garanzia di <strong>la</strong>rghezza di banda.<br />

Il concetto su cui si basa l’implementazione di questo PHB è <strong>la</strong> seguente: gli<br />

eventi che <strong>in</strong>troducono variabilità nelle caratteristiche dette sopra si collocano<br />

nelle code dei router e sono causati dal<strong>la</strong> differenza tra <strong>la</strong> velocità di trasmissione<br />

<strong>del</strong> flusso aggregato <strong>in</strong> entrata e quel<strong>la</strong> riservata a quel<strong>la</strong> determ<strong>in</strong>ata coda <strong>in</strong><br />

uscita. Per l’Expedited Forward<strong>in</strong>g deve essere sempre garantita l’assenza di<br />

congestione <strong>del</strong><strong>la</strong> coda associata ad esso e tale garanzia deve essere salvaguardata<br />

<strong>in</strong>dipendentemente dall'<strong>in</strong>tensità <strong>del</strong> resto <strong>del</strong> traffico appartenente ad altri PHB:<br />

78


__________________________________________________________________<br />

le varie c<strong>la</strong>ssi di servizio non si devono <strong>in</strong>fluenzare tra loro. Un modo <strong>per</strong><br />

implementare questo PHB consiste nel predisporre una coda con priorità<br />

su<strong>per</strong>iore: <strong>per</strong> evitare <strong>in</strong>terferenze (pre-emptions) non dovrebbero essere tuttavia<br />

presenti altre code a priorità su<strong>per</strong>iore.<br />

2-Assured Forward<strong>in</strong>g : Il PHB Assured Forward<strong>in</strong>g rappresenta un servizio<br />

end-to-end con caratteristiche di garanzia sul recapito <strong>del</strong> pacchetto;viene def<strong>in</strong>ita<br />

una certa <strong>la</strong>rghezza di banda "di profilo", ed il traffico che rientra <strong>in</strong> quel<strong>la</strong><br />

<strong>la</strong>rghezza di banda viene recapitato con alta probabilità. L’ Assured Forward<strong>in</strong>g<br />

<strong>per</strong>mette di configurare diversi livelli di affidabilità e di priorità di <strong>in</strong>oltro <strong>del</strong><br />

traffico. Sono presenti quattro c<strong>la</strong>ssi di servizio e <strong>per</strong> ognuna ci sono tre differenti<br />

livelli re<strong>la</strong>tivi di scarto (drop); i pacchetti vengono marcati e <strong>in</strong>seriti <strong>in</strong> una <strong>del</strong>le<br />

c<strong>la</strong>ssi <strong>in</strong> base ai servizi sottoscritti dal cliente e <strong>in</strong> caso di congestione i nodi<br />

scartano <strong>in</strong> base ai livelli di priorità. Questo PHB si adatta molto bene a tutte<br />

quelle applicazioni che non hanno richieste assolute di banda ma che hanno<br />

bisogno di una priorità maggiore <strong>del</strong> normale traffico.<br />

3.3 SCHEDULING E ALGORITMI<br />

Per implementare il DiffServ si necessita di una gestione ottimale <strong>del</strong>le code<br />

presenti nei routers e <strong>per</strong> farlo bisogna ricorrere ad opportune procedure di<br />

schedul<strong>in</strong>g. Lo Schedul<strong>in</strong>g è il meccanismo con il quale si programma <strong>in</strong> quale<br />

sequenza e modo devono essere servite le code, nel caso di buffer multiplo, o i<br />

pacchetti, nel caso di buffer s<strong>in</strong>golo. Nel <strong>Test</strong>-<strong>bed</strong> s<strong>per</strong>imentale che verrà descritto<br />

dettagliatamente nel Capitolo 3 sono presenti due router Juni<strong>per</strong> provvisti di<br />

quattro code e qu<strong>in</strong>di gli algoritmi che più <strong>in</strong>teressano sono quelli a buffer<br />

multiplo.<br />

79


__________________________________________________________________<br />

Figura 16: Struttura di un router a buffer multiplo con queu<strong>in</strong>g e schedul<strong>in</strong>g<br />

La maggior parte degli algoritmi a buffer multiplo sono basati sul<strong>la</strong> tecnica<br />

Round-Rob<strong>in</strong> <strong>per</strong>chè è <strong>la</strong> più adatta quando si vogliono iso<strong>la</strong>re più flussi. Il<br />

funzionamento <strong>del</strong> Round-Rob<strong>in</strong> è il seguente: lo scheduler scorre tutte le code<br />

ciclicamente e se quel<strong>la</strong> che sta analizzando non è vuota spedisce il primo<br />

pacchetto presente, altrimenti passa al<strong>la</strong> coda successiva. Questo algoritmo<br />

dipende dal<strong>la</strong> lunghezza media dei pacchetti presenti nelle code e non dal<strong>la</strong><br />

lunghezza effettiva. Per ovviare questo problema viene <strong>in</strong>trodotto il cosiddetto<br />

quantum che rappresenta numero di byte che lo scheduler può spedire da ogni<br />

coda <strong>in</strong> un determ<strong>in</strong>ato istante.<br />

L’algoritmo che utilizza il quantum viene detto Deficit Round-Rob<strong>in</strong> ( DRR ) e<br />

funziona nel modo seguente: prima di servire <strong>la</strong> coda lo scheduler confronta <strong>la</strong><br />

grandezza <strong>del</strong> pacchetto con il valore <strong>del</strong> quantum; se il pacchetto è maggiore <strong>del</strong><br />

quantum non viene spedito e il quantum <strong>in</strong>crementa altrimenti il pacchetto viene<br />

spedito e il quantum decrementato al valore <strong>del</strong><strong>la</strong> grandezza <strong>del</strong> pacchetto spedito.<br />

3.3.1 WRR: Weighted Round Rob<strong>in</strong><br />

Questa tecnica, che poi è quel<strong>la</strong> implementata nei router Juni<strong>per</strong> utilizzati, prende<br />

<strong>in</strong> considerazione il peso di ogni c<strong>la</strong>sse di servizio: i pesi determ<strong>in</strong>ano il numero<br />

massimo di ottetti che possono uscire da una coda nello stesso turno. In questo<br />

modo ad ogni coda viene riservata una <strong>per</strong>centuale di banda differente e qu<strong>in</strong>di le<br />

80


__________________________________________________________________<br />

code a più alta priorità verranno servite più spesso rispetto a quelle con più bassa<br />

priorità: è come se nel DRR ci fossero valori di quantum diversi <strong>per</strong> ogni coda.<br />

3.3.2 Priority queu<strong>in</strong>g<br />

Il concetto di base di questo algoritmo è di assegnare ad ogni c<strong>la</strong>sse di servizio un<br />

numero che rappresenta <strong>la</strong> sua priorità. La c<strong>la</strong>sse con priorità più alta sarà servita<br />

ad ogni giro <strong>del</strong>lo scheduler e, f<strong>in</strong>ché questa avrà pacchetti da servire, essi saranno<br />

spediti. Non appena <strong>la</strong> coda si svuota lo scheduler passa a servire i pacchetti di<br />

quel<strong>la</strong> successiva, f<strong>in</strong>ché anche questi non term<strong>in</strong>ano e cosi via. Quando un<br />

pacchetto arriva nel<strong>la</strong> coda con priorità m<strong>in</strong>ore, questa viene servita non appena lo<br />

scheduler f<strong>in</strong>isce di spedire i pacchetti <strong>del</strong> servizio corrente. Il difetto di questo<br />

algoritmo è che le c<strong>la</strong>ssi con priorità m<strong>in</strong>ore possono cadere <strong>in</strong> starvation, e cioè<br />

non vengono servite <strong>per</strong> molto tempo <strong>in</strong> presenza di un flusso cont<strong>in</strong>uo di<br />

pacchetti appartenenti a c<strong>la</strong>ssi a priorità maggiore. Una soluzione a tale problema<br />

è il quantum, come <strong>per</strong> il WRR, che limita il numero di ottetti che possono essere<br />

spediti consecutivamente da una stessa coda.<br />

3.3.3 Controllo <strong>del</strong><strong>la</strong> Congestione<br />

Il controllo <strong>del</strong><strong>la</strong> congestione <strong>del</strong>le code <strong>in</strong>terne ai router è molto importante <strong>per</strong><br />

ottimizzare le prestazioni di rete. Come visto precedentemente il tempo di ritardo<br />

dei pacchetti (one-way de<strong>la</strong>y), è costituito dal<strong>la</strong> somma di tre fattori di cui solo<br />

uno è altamente variabile: il tempo di accodamento. Inizialmente è stata utilizzata<br />

<strong>la</strong> tecnica F.I.F.O. ( First In First Out): se il ritmo di entrata dei pacchetti è<br />

maggiore di quello di uscita, questi vengono memorizzati e quando <strong>la</strong> coda si<br />

riempie vengono scartati. Questa tecnica è molto semplice ma ha degli svantaggi<br />

che <strong>la</strong> rendono <strong>in</strong>efficiente nelle <strong>reti</strong> multiservizio:<br />

81


__________________________________________________________________<br />

- se le code sono troppo piene i ritardi dei pacchetti aumentano<br />

notevolmente;<br />

- ci possono essere problemi di s<strong>in</strong>cronizzazione <strong>in</strong> quanto i pacchetti<br />

scartati sono spesso consecutivi;<br />

- le sorgenti a ritmo variabile, che <strong>in</strong> alcuni momenti raggiungono<br />

picchi alti di traffico, sono penalizzate rispetto alle sorgenti a ritmo<br />

costante.<br />

Di seguito vengono descritti i pr<strong>in</strong>cipali algoritmi oggi utilizzati nei router <strong>per</strong> il<br />

controllo ottimale <strong>del</strong><strong>la</strong> congestione <strong>del</strong>le code.<br />

R.E.D. ( Random Early Discard ): I router <strong>in</strong> cui è implementato questo<br />

algoritmo scartano uno o più pacchetti prima che <strong>la</strong> coda si sia completamente<br />

riempita. Ogni volta che un pacchetto arriva, l’algoritmo RED calco<strong>la</strong> <strong>la</strong><br />

lunghezza media <strong>del</strong><strong>la</strong> coda, avg , e il router può assumere tre comportamenti:<br />

- se tale lunghezza è <strong>in</strong>feriore ad una soglia m<strong>in</strong>ima, <strong>la</strong> coda viene considerata non<br />

congestionata e il router memorizza i pacchetti;<br />

- se <strong>la</strong> lunghezza media è maggiore <strong>del</strong><strong>la</strong> soglia massima, <strong>la</strong> coda è considerata<br />

congestionata e il router scarta i pacchetti con probabilità <strong>del</strong> 100%;<br />

- se <strong>la</strong> lunghezza media si trova tra <strong>la</strong> soglia m<strong>in</strong>ima e massima, l’algoritmo<br />

calco<strong>la</strong> <strong>la</strong> probabilità di scarto dei pacchetti <strong>in</strong> base al<strong>la</strong> congestione <strong>del</strong><strong>la</strong> coda.<br />

82


__________________________________________________________________<br />

Figura 17: Probabilità di scarto dei pacchetti al variare <strong>del</strong><strong>la</strong> lunghezza media <strong>del</strong><strong>la</strong> coda.<br />

Come si vede <strong>in</strong> figura, all’aumentare <strong>del</strong><strong>la</strong> congestione <strong>del</strong><strong>la</strong> coda, <strong>in</strong>dicata dal<br />

parametro avg, viene scartato un numero sempre maggiore di pacchetti f<strong>in</strong>o ad<br />

arrivare al<strong>la</strong> soglia massima th max dopo <strong>la</strong> quale tutti i pacchetti entranti vengono<br />

scartati.<br />

Usando lo scarto probabilistico si evita <strong>la</strong> cancel<strong>la</strong>zione di pacchetti consecutivi e<br />

<strong>la</strong> probabilità di cancel<strong>la</strong>zione non è casuale ma calco<strong>la</strong>ta sul<strong>la</strong> base <strong>del</strong> numero di<br />

pacchetti <strong>del</strong> flusso di appartenenza presenti nel<strong>la</strong> coda.<br />

Lo svantaggio di questo algoritmo è che funziona male nel caso <strong>in</strong> cui i flussi che<br />

congestionano <strong>la</strong> coda siano “non-responsive” : se <strong>in</strong>fatti si è <strong>in</strong> presenza di<br />

multimedia non adattativi, ovvero se le sorgenti non possono abbassare le velocità<br />

di emissione, <strong>la</strong> coda rimarrà sempre congestionata e i pacchetti verranno<br />

cont<strong>in</strong>uamente scartati.<br />

Weighted R.E.D.: Questo algoritmo è una evoluzione <strong>del</strong> RED appena visto ed è<br />

stato proposto orig<strong>in</strong>ariamente dal CISCO. Rispetto al precedente vengono usati<br />

differenti parametri <strong>per</strong> i vari flussi entranti: <strong>in</strong> questo modo, <strong>in</strong>fatti, è possibile<br />

differenziare <strong>la</strong> distribuzione dei pacchetti <strong>per</strong>si. Questa soluzione può non essere<br />

<strong>per</strong>ò conforme al mo<strong>del</strong>lo DiffServ, <strong>in</strong>fatti con il WRED i router devono<br />

memorizzare i parametri <strong>del</strong>le code <strong>per</strong> ogni s<strong>in</strong>golo flusso e questo comporta<br />

83


__________________________________________________________________<br />

problemi di sca<strong>la</strong>bilità, tipici <strong>del</strong>le architetture ATM <strong>per</strong> le quali è stato realizzato<br />

questo algoritmo.<br />

Figura 18: Andamento <strong>del</strong><strong>la</strong> funzione di probabilità di cancel<strong>la</strong>zione nel WRED<br />

RED with IN and OUT ( RIO ): Questo algoritmo è tra i primi che supportano i<br />

servizi differenziati. Inizialmente RIO supportava due livelli di precedenza (In e<br />

Out), ma <strong>in</strong> seguito, è stato modificato <strong>per</strong> essere <strong>in</strong> grado supportarne di più. Le<br />

differenza rispetto alle altre metodologie riguarda soprattutto <strong>la</strong> grandezza media<br />

<strong>del</strong>le code. A differenza <strong>del</strong> WRED, RIO calco<strong>la</strong> questo valore <strong>per</strong> ogni livello di<br />

precedenza, ovvero il valore avg n<br />

viene aggiornato ogni volta che arriva nel<strong>la</strong> coda<br />

un pacchetto con precedenza n. In questo modo è possibile iso<strong>la</strong>re le probabilità di<br />

elim<strong>in</strong>azione <strong>per</strong> ogni livello di precedenza. Per esempio <strong>per</strong> cancel<strong>la</strong>re un<br />

pacchetto di bassa precedenza deve verificarsi un eccesso di pacchetti con lo<br />

stesso livello, <strong>in</strong>vece <strong>per</strong> elim<strong>in</strong>arne uno con alta precedenza, basta che si verifichi<br />

un eccesso generale di pacchetti.<br />

Per potenziare l’algoritmo RIO è previsto l’uso di differenti parametri (p max<br />

, th m<strong>in</strong><br />

e th max<br />

) <strong>per</strong> ogni livello di precedenza, come <strong>per</strong> il WRED. In questo modo,<br />

potrebbero essere usate soglie meno rigide, <strong>per</strong> far sì che <strong>la</strong> grandezza media <strong>del</strong>le<br />

code <strong>per</strong> i pacchetti con alta priorità possa aumentare più rapidamente rispetto al<br />

WRED o al RED, rendendo così questo sistema applicabile nel<strong>la</strong> rete.<br />

84


__________________________________________________________________<br />

3.3.4 Coesistenza IntServ , DiffServ<br />

Il mo<strong>del</strong>lo DiffServ nasce <strong>per</strong> far fronte ai problemi di sca<strong>la</strong>bilità di IntServ e si<br />

basa su un concetto completamente diverso dal suo predecessore. Nel IntServ<br />

l’applicazione che richiede una certa QoS deve generare un’<strong>in</strong>formazione di<br />

controllo ( tramite protocollo RSVP ) <strong>per</strong> avvertire tutti i router co<strong>in</strong>volti nel<br />

camm<strong>in</strong>o orig<strong>in</strong>e-dest<strong>in</strong>azione di trattare il suo flusso <strong>in</strong>formativo <strong>in</strong> un<br />

determ<strong>in</strong>ato modo. Perchè <strong>la</strong> rete possa garantire le prestazioni richieste, ogni<br />

router deve mantenere <strong>del</strong>le opportune <strong>in</strong>formazioni di stato ( ad esempio <strong>la</strong> banda<br />

e il buffer da riservare a un certo flusso <strong>in</strong>formativo) che vengono aggiornate<br />

durante <strong>la</strong> connessione. Nel<strong>la</strong> metodologia IntServ <strong>la</strong> gestione <strong>del</strong><strong>la</strong> QoS è su base<br />

flusso e ogni router deve avere <strong>in</strong>formazioni di stato <strong>per</strong> tutti i flussi che lo<br />

attraversano, <strong>in</strong> quel<strong>la</strong> DiffServ <strong>in</strong>vece viene meno <strong>la</strong> necessità di memorizzare le<br />

<strong>in</strong>formazioni di stato <strong>del</strong> s<strong>in</strong>golo flusso <strong>in</strong> quanto non vi è più riservazione <strong>del</strong>le<br />

risorse, <strong>in</strong>fatti vengono def<strong>in</strong>iti dei PHB. Qu<strong>in</strong>di se <strong>per</strong> IntServ si hanno garanzie<br />

maggiori <strong>del</strong>le prestazioni ma problemi di sca<strong>la</strong>bilità legati al numero di flussi da<br />

gestire, il DiffServ risulta <strong>in</strong>vece essere una architettura molto meno complessa<br />

ma tuttavia manca <strong>del</strong><strong>la</strong> capacità di “iso<strong>la</strong>re” le s<strong>in</strong>gole richieste di QoS.<br />

Anche se queste tecnologie sono state def<strong>in</strong>ite separatamente, non è detto che<br />

debbano essere utilizzate <strong>in</strong> modo esclusivo. IntServ è efficiente nelle piccole <strong>reti</strong>,<br />

come ad esempio le LAN, dove i flussi da gestire sono pochi e non si hanno<br />

problemi di sca<strong>la</strong>bilità; DiffServ al contrario consente <strong>la</strong> gestione <strong>del</strong><strong>la</strong> QoS <strong>per</strong><br />

grossi aggregati di traffico e può qu<strong>in</strong>di essere implementato su <strong>reti</strong> trasporto<br />

metropolitane o backbone. Uno scenario futuro di rete multiservizio con gestione<br />

<strong>del</strong><strong>la</strong> QoS potrebbe essere il seguente:<br />

85


__________________________________________________________________<br />

Figura 19: Architettura di rete con metodogie DiffServ e IntServ<br />

3.4 DIFFSERV OVER MPLS<br />

Le condizioni da soddisfare <strong>per</strong> <strong>la</strong> QoS si possono riassumere come segue:<br />

• È necessaria l’allocazione garantita di una certa misura di risorse<br />

trasmissive <strong>in</strong> tutto il <strong>per</strong>corso effettuato dai dati <strong>del</strong>l’applicazione di<br />

<strong>in</strong>teresse. Questa condizione di tipo end-to-end non deve venire meno<br />

neanche <strong>in</strong> situazioni di congestione o malfunzionamento di nodi <strong>del</strong><strong>la</strong><br />

rete.E’ necessaria <strong>in</strong>oltre <strong>la</strong> funzione di Admission Control;<br />

• Il flusso dati <strong>del</strong>l’applicazione deve s<strong>per</strong>imentare nei nodi <strong>del</strong><strong>la</strong> rete un<br />

trattamento specifico, scelto tra diverse possibili c<strong>la</strong>ssi di servizio, che<br />

rispetti determ<strong>in</strong>ati v<strong>in</strong>coli sul<strong>la</strong> <strong>per</strong>dita di pacchetti e sui ritardi nelle code.<br />

La metodologia DiffServ rappresenta un primo reale passo avanti <strong>per</strong><br />

l’implementazione e gestione <strong>del</strong><strong>la</strong> QoS nelle <strong>reti</strong> fisse ma è anche da considerarsi<br />

<strong>in</strong>completa <strong>in</strong> quanto non offre le garanzie quantitative end-to-end richieste dal<br />

primo dei due requisiti. MPLS (Multiprotocol Label Switch<strong>in</strong>g) è una architettura<br />

86


__________________________________________________________________<br />

di rete emersa negli ultimi anni e spesso viene erroneamente citata come<br />

architettura <strong>per</strong> <strong>la</strong> qualità <strong>del</strong> servizio; <strong>in</strong> realtà essa non fornisce di <strong>per</strong> sé alcun<br />

meccanismo <strong>per</strong> <strong>la</strong> gestione <strong>del</strong><strong>la</strong> QoS. Ciò che MPLS offre è <strong>la</strong> possibilità di<br />

<strong>la</strong>vorare <strong>in</strong> un ambiente connection oriented, nel quale è possibile riservare risorse<br />

ed utilizzare <strong>in</strong> modo efficiente <strong>la</strong> rete mediante applicazioni di traffic<br />

eng<strong>in</strong>eer<strong>in</strong>g. MPLS è qu<strong>in</strong>di un’architettura che può fornire il supporto <strong>per</strong> una<br />

completa gestione end-to-end <strong>del</strong><strong>la</strong> QoS.<br />

3.4.1 L’architettura MPLS<br />

Un dom<strong>in</strong>io MPLS è costituito da una serie di nodi contigui che supportano <strong>la</strong><br />

tecnologia Multiprotocol Label Switch<strong>in</strong>g, detti LSR (Label Switch<strong>in</strong>g Router). In<br />

questo scenario sono di partico<strong>la</strong>re importanza i nodi al conf<strong>in</strong>e <strong>del</strong> dom<strong>in</strong>io, che<br />

nel<strong>la</strong> term<strong>in</strong>ologia MPLS vengono chiamati LER (Label Edge Router). Essi<br />

rappresentano l’<strong>in</strong>terfaccia <strong>del</strong> dom<strong>in</strong>io MPLS con il resto <strong>del</strong><strong>la</strong> rete, qu<strong>in</strong>di<br />

devono implementare sia l’algoritmo di forward<strong>in</strong>g <strong>la</strong>bel switch<strong>in</strong>g sia quello<br />

tradizionale IP. Un altro loro compito è quello di assegnare le <strong>la</strong>bel al traffico <strong>in</strong><br />

<strong>in</strong>gresso. Un <strong>per</strong>corso effettuato dai pacchetti <strong>in</strong>stradati tramite <strong>la</strong>bel switch<strong>in</strong>g<br />

all’<strong>in</strong>terno <strong>del</strong> dom<strong>in</strong>io MPLS prende il nome di LSP (Label Switched Path). Da<br />

un punto di vista funzionale, l’architettura MPLS può essere divisa (come <strong>del</strong><br />

resto anche l’architettura tradizionale IP) <strong>in</strong> componente di forward<strong>in</strong>g e<br />

componente di controllo. La componente di forward<strong>in</strong>g consiste nel<strong>la</strong> procedura<br />

mediante <strong>la</strong> quale <strong>in</strong> un nodo si estraggono dai pacchetti le <strong>in</strong>formazioni <strong>per</strong><br />

identificare l’appropriato next hop nel<strong>la</strong> forward<strong>in</strong>g table. Un LER esegue il<br />

mapp<strong>in</strong>g <strong>del</strong> traffico <strong>in</strong> c<strong>la</strong>ssi di equivalenza <strong>per</strong> il forward<strong>in</strong>g (FEC), ossia <strong>in</strong><br />

gruppi di pacchetti che devono essere tutti <strong>in</strong>oltrati nel<strong>la</strong> stessa maniera. Di<br />

seguito associa l’etichetta ai pacchetti <strong>in</strong> base al<strong>la</strong> loro FEC di appartenenza.<br />

All’<strong>in</strong>terno <strong>del</strong> dom<strong>in</strong>io MPLS, ogni LSR ha una tabel<strong>la</strong> di forward<strong>in</strong>g nel<strong>la</strong> quale<br />

ad un determ<strong>in</strong>ato <strong>la</strong>bel corrisponde un next hop. L’<strong>in</strong>dirizzo di dest<strong>in</strong>azione<br />

f<strong>in</strong>ale dei pacchetti non è più preso <strong>in</strong> considerazione nelle decisioni riguardo al<br />

loro <strong>in</strong>oltro. Un parametro importante <strong>per</strong> <strong>la</strong> componente di forward<strong>in</strong>g è <strong>la</strong><br />

87


__________________________________________________________________<br />

granu<strong>la</strong>rità con cui i flussi <strong>in</strong> <strong>in</strong>gresso al dom<strong>in</strong>io MPLS vengono associati nelle<br />

FEC. In l<strong>in</strong>ea teorica sarebbe possibile associare una diversa etichetta ad ogni<br />

s<strong>in</strong>golo flusso, ma questo comporterebbe i medesimi problemi <strong>del</strong>l’architettura<br />

IntServ. Il pregio di MPLS da questo punto di vista è <strong>la</strong> possibilità di selezionare<br />

arbitrariamente i criteri <strong>per</strong> l’aggregazione di più flussi <strong>in</strong> c<strong>la</strong>ssi di equivalenza <strong>per</strong><br />

il forward<strong>in</strong>g.<br />

Dal momento che solo alcuni protocolli di livello 3 (ATM, Frame Re<strong>la</strong>y)<br />

supportano <strong>la</strong> presenza di un <strong>la</strong>bel, si è deciso di creare <strong>in</strong> ambito MPLS un<br />

header di 32 bit da <strong>in</strong>serire tra quello di livello 2 e quello di livello 3, detto shim<br />

header. Tutti i protocolli di livello 3 che non prevedono <strong>la</strong> presenza di una <strong>la</strong>bel<br />

(tra i quali rientra IP) possono fare uso <strong>del</strong>lo shim header <strong>per</strong> trasportare le<br />

<strong>in</strong>formazioni <strong>per</strong> il <strong>la</strong>bel switch<strong>in</strong>g.<br />

Figura 20: Shim Header MPLS<br />

Il campo di 20 bit Label è l’etichetta vera e propria. Il campo Exp, di tre bit, è<br />

stato riservato ad uso s<strong>per</strong>imentale ed è spesso utilizzato <strong>per</strong> il supporto <strong>del</strong><strong>la</strong> QoS<br />

<strong>in</strong> ambito MPLS.<br />

La componente di controllo nell’architettura MPLS consiste nelle procedure<br />

utilizzate <strong>per</strong> scambiare <strong>in</strong>formazioni di rout<strong>in</strong>g tra gli LSR e <strong>per</strong> convertire tali<br />

<strong>in</strong>formazioni <strong>in</strong> una tabel<strong>la</strong> di forward<strong>in</strong>g. Come <strong>la</strong> componente di controllo<br />

<strong>del</strong>l’architettura tradizionale IP, anche quel<strong>la</strong> di MPLS <strong>in</strong>clude dei protocolli di<br />

rout<strong>in</strong>g come ad esempio OSPF ( Open Shortest Path First ). Per <strong>la</strong> creazione<br />

<strong>del</strong>le tabelle di forward<strong>in</strong>g sono <strong>per</strong>ò necessarie <strong>in</strong> un LSR ulteriori funzionalità<br />

88


__________________________________________________________________<br />

oltre ai protocolli di rout<strong>in</strong>g. Un LSR, <strong>in</strong>fatti, deve essere <strong>in</strong> grado di creare<br />

associazioni (b<strong>in</strong>d<strong>in</strong>gs) tra <strong>la</strong>bel e FEC, <strong>in</strong>formare gli altri LSR dei b<strong>in</strong>d<strong>in</strong>gs ed<br />

aggiornare le tabelle di forward<strong>in</strong>g <strong>in</strong> base ai b<strong>in</strong>d<strong>in</strong>gs creati localmente e a quelli<br />

di cui viene <strong>in</strong>formato dagli altri LSR. I protocolli di rout<strong>in</strong>g consentono di<br />

effettuare il passaggio da FEC a next hop; le procedure di creazione e<br />

distribuzione dei b<strong>in</strong>d<strong>in</strong>gs portano al<strong>la</strong> conversione da FEC a <strong>la</strong>bel.<br />

Complessivamente si ottiene <strong>la</strong> re<strong>la</strong>zione tra <strong>la</strong>bel e next hop necessaria <strong>per</strong> <strong>la</strong><br />

creazione <strong>del</strong>le tabelle di forward<strong>in</strong>g,<br />

Figura 21: Procedura <strong>per</strong> <strong>la</strong> creazione <strong>del</strong><strong>la</strong> Forward<strong>in</strong>g Table<br />

La distribuzione <strong>del</strong>le <strong>la</strong>bel b<strong>in</strong>d<strong>in</strong>gs tra gli LSR viene affidata preferibilmente a<br />

protocolli tradizionali come RSVP ma può anche essere demandata ad un apposito<br />

protocollo detto LDP (Label Distribution Protocol).<br />

3.4.2 MPLS e <strong>in</strong>gegneria <strong>del</strong> traffico<br />

L’architettura MPLS è nata <strong>per</strong> aumentare le prestazioni dei nodi <strong>del</strong><strong>la</strong> rete,<br />

<strong>in</strong>troducendo <strong>per</strong> il forward<strong>in</strong>g un campo di dimensione fissa che consentisse un<br />

process<strong>in</strong>g più rapido dei pacchetti. Tuttavia questo tipo di necessità è<br />

progressivamente venuto meno <strong>in</strong> conseguenza <strong>del</strong>le cont<strong>in</strong>ue <strong>in</strong>novazioni<br />

tecnologiche che hanno portato a router sempre più veloci. Il vero vantaggio di<br />

MPLS, che non rientrava tra i suoi scopi orig<strong>in</strong>ari, è quello di consentire ai<br />

Service Provider di implementare il TE (traffic eng<strong>in</strong>eer<strong>in</strong>g) nelle <strong>reti</strong>,<br />

aumentandone l’efficienza e le prestazioni. Il TE <strong>per</strong>mette di bi<strong>la</strong>nciare il traffico<br />

89


__________________________________________________________________<br />

<strong>in</strong> una rete <strong>in</strong> modo da non avere l<strong>in</strong>k congestionati né scarsamente utilizzati, cosa<br />

che porta ad un pieno sfruttamento <strong>del</strong><strong>la</strong> rete, con il conseguente guadagno <strong>per</strong> i<br />

provider che possono servire più utenza a parità di risorse. Inoltre il TE consente<br />

l’allocazione <strong>del</strong>le risorse trasmissive <strong>per</strong> un aggregato di flussi, rendendo<br />

possibile lo sviluppo di meccanismi di QoS end-to-end.<br />

Figura 22: Rete MPLS<br />

Lo sviluppo <strong>del</strong> TE ha importanti implicazioni <strong>per</strong> le procedure di rout<strong>in</strong>g.<br />

Nell’architettura IP tradizionale <strong>la</strong> selezione <strong>del</strong> <strong>per</strong>corso <strong>per</strong> l’<strong>in</strong>stradamento <strong>del</strong><br />

traffico viene effettuata m<strong>in</strong>imizzando una determ<strong>in</strong>ata metrica, rappresentata ad<br />

esempio dal numero di nodi attraversati o dal<strong>la</strong> somma di term<strong>in</strong>i di costo<br />

assegnati staticamente ai l<strong>in</strong>k. La conseguenza di ciò è uno sbi<strong>la</strong>nciamento <strong>del</strong><br />

traffico che viene <strong>in</strong>stradato <strong>per</strong> <strong>la</strong> maggior parte su <strong>per</strong>corsi preferenziali<br />

risultando spesso soggetti a congestione. In questo contesto poco flessibile<br />

mancano le premesse <strong>per</strong> poter sviluppare il TE. MPLS su<strong>per</strong>a i limiti<br />

<strong>del</strong>l’architettura tradizionale supportando un nuovo tipo di rout<strong>in</strong>g, detto<br />

Constra<strong>in</strong>t-based Rout<strong>in</strong>g (CR). L’idea al<strong>la</strong> base di questa <strong>in</strong>novazione sta nel<br />

fatto che <strong>per</strong> avere un rout<strong>in</strong>g efficiente bisogna <strong>in</strong>stradare il traffico lungo<br />

<strong>per</strong>corsi a costo m<strong>in</strong>imo, rispettando contemporaneamente determ<strong>in</strong>ati v<strong>in</strong>coli<br />

(constra<strong>in</strong>ts) sullo sfruttamento <strong>del</strong>le risorse di rete. Per poter effettuare il CR<br />

90


__________________________________________________________________<br />

sono necessarie funzionalità aggiuntive nel<strong>la</strong> rete, tra le quali <strong>la</strong> presenza di<br />

protocolli di rout<strong>in</strong>g opportunamente estesi (come ad esempio OSPF-TE o ISIS-<br />

TE) <strong>per</strong> portare le <strong>in</strong>formazioni re<strong>la</strong>tive al TE. Servono poi algoritmi <strong>per</strong> il calcolo<br />

dei <strong>per</strong>corsi che rispett<strong>in</strong>o i v<strong>in</strong>coli, ed un protocollo <strong>per</strong> l’allocazione <strong>del</strong>le risorse<br />

esteso <strong>per</strong> il TE; il più famoso è senz’altro RSVP-TE (ReSerVation Protocol with<br />

Tunnel<strong>in</strong>g Extension), che è molto utilizzato <strong>per</strong> <strong>la</strong> distribuzione dei <strong>la</strong>bel nelle<br />

<strong>reti</strong> che implementano il traffic eng<strong>in</strong>eer<strong>in</strong>g e <strong>la</strong> QoS.<br />

3.4.3 Implementazione <strong>del</strong><strong>la</strong> QoS DiffServ su MPLS<br />

L ‘architettura MPLS grazie ai protocolli di rout<strong>in</strong>g estesi <strong>per</strong> fornire TE può<br />

offrire un ambiente connection-oriented, necessario <strong>per</strong> l’implementazione <strong>del</strong><strong>la</strong><br />

QoS, garantendo risorse trasmissive ad aggregati di traffico ma non discrim<strong>in</strong>ando<br />

i pacchetti nel trattamento ad essi riservato nei nodi. L’architettura DiffServ,<br />

<strong>in</strong>vece, <strong>per</strong>mette <strong>la</strong> c<strong>la</strong>ssificazione dei pacchetti <strong>in</strong> BA e il loro trattamento<br />

diversificato rappresentato dai PHB. L’<strong>in</strong>tegrazione <strong>del</strong>le due architetture porta<br />

qu<strong>in</strong>di allo sviluppo di una meccanismo <strong>per</strong> gestire <strong>in</strong> modo completo <strong>la</strong> QoS.<br />

Aff<strong>in</strong>ché MPLS possa supportare DiffServ, è necessario che gli LSR riescano a<br />

dist<strong>in</strong>guere i vari pacchetti <strong>in</strong> base al loro DSCP <strong>per</strong> <strong>in</strong>oltrarli secondo il PHB<br />

corrispondente. Sorge allora un problema <strong>in</strong> quanto gli LSR si basano<br />

esclusivamente sul<strong>la</strong> <strong>la</strong>bel <strong>del</strong>lo shim header MPLS <strong>per</strong> il forward<strong>in</strong>g dei<br />

pacchetti, e non esam<strong>in</strong>ano l’header IP. Le soluzioni che sono state proposte sono<br />

due:<br />

- E-LSP ( Ex<strong>per</strong>imental bit <strong>in</strong>ferred LSP ) : Viene utilizzato il campo EXP<br />

<strong>del</strong>lo shim header come sostituto <strong>del</strong> campo DSCP <strong>per</strong> portare l’<strong>in</strong>formazione sul<br />

DSCP all’<strong>in</strong>terno <strong>del</strong> dom<strong>in</strong>io MPLS. L’<strong>in</strong>conveniente di questo approccio<br />

consiste nel<strong>la</strong> dimensione <strong>del</strong> campo EXP, di soli tre bit contro i sei <strong>del</strong> campo<br />

DSCP: <strong>in</strong> questo modo si possono supportare al massimo otto diversi DSCP e<br />

qu<strong>in</strong>di otto diversi PHB. Nel caso di una rete nel<strong>la</strong> quale siano effettivamente<br />

91


__________________________________________________________________<br />

implementati o richiesti al massimo otto PHB, le funzioni DiffServ possono essere<br />

esplicate semplicemente leggendo negli LSR il valore <strong>del</strong> campo Exp ed<br />

assegnando di conseguenza i pacchetti al corretto BA. Questo metodo ha il pregio<br />

di essere semplice e non richiedere alcuna segna<strong>la</strong>zione di controllo aggiuntiva.<br />

Figura 23: I bit <strong>del</strong> campo TOS o i primi 3 bit <strong>del</strong> campo DSCP sono copiati nel campo Exp ai<br />

bordi <strong>del</strong><strong>la</strong> rete.<br />

- L-LSP ( Label <strong>in</strong>ferred LSP ) : La seconda soluzione proposta è utile qualora<br />

si debbano trattare più di otto PHB. In tal caso il campo Exp non è più sufficiente,<br />

e lo shim header necessita di essere <strong>in</strong> qualche modo rivisitato <strong>per</strong> consentire il<br />

trasporto <strong>del</strong>l’<strong>in</strong>formazione sul DSCP. Si è deciso di <strong>in</strong>crementare il significato<br />

<strong>del</strong> campo <strong>la</strong>bel, che deve <strong>in</strong>dicare sia l’appartenenza ad una certa FEC che<br />

l’appartenenza ad un certo BA; il campo Exp viene <strong>in</strong> questo caso utilizzato <strong>per</strong><br />

esprimere il valore <strong>del</strong><strong>la</strong> drop precedence, <strong>in</strong> modo da trattare i pacchetti secondo<br />

l’opportuno PHB. Par<strong>la</strong>ndo ad esempio <strong>del</strong><strong>la</strong> categoria di PHB AF, nel<strong>la</strong> <strong>la</strong>bel si<br />

troverebbe l’<strong>in</strong>formazione sullo schedul<strong>in</strong>g e qu<strong>in</strong>di riguardo al<strong>la</strong> coda sul<strong>la</strong> quale<br />

<strong>in</strong>stradare il pacchetto; nel campo Exp si troverebbe il valore (tra i tre possibili <strong>per</strong><br />

ogni c<strong>la</strong>sse di schedul<strong>in</strong>g di AF) <strong>del</strong><strong>la</strong> drop precedence.<br />

92


__________________________________________________________________<br />

Figura 24: Il PHB è <strong>in</strong>dicato dal valore <strong>del</strong><strong>la</strong> <strong>la</strong>bel mentre <strong>la</strong> drop precedence dal valore <strong>del</strong><br />

campo Exp.<br />

E’ necessario far confluire i pacchetti <strong>del</strong> medesimo BA <strong>in</strong> un L-LSP comune,<br />

poiché sono dest<strong>in</strong>ati tutti al<strong>la</strong> stessa coda: un L-LSP può trasportare una so<strong>la</strong><br />

c<strong>la</strong>sse di servizio. Questo modo di procedere consente di avere quanti PHB si<br />

vogliano, a spese di una complicazione nel<strong>la</strong> componente di controllo MPLS.<br />

Infatti è necessario estendere i protocolli <strong>per</strong> <strong>la</strong> distribuzione dei b<strong>in</strong>d<strong>in</strong>g tra <strong>la</strong>bel<br />

e FEC, che adesso devono <strong>in</strong>cludere anche il b<strong>in</strong>d<strong>in</strong>g tra <strong>la</strong>bel e PHB. La<br />

distribuzione deve essere effettuata al momento <strong>del</strong><strong>la</strong> creazione di un L-LSP.<br />

Le due alternative <strong>per</strong> gli LSP con supporto di DiffServ non sono mutuamente<br />

esclusive e possono coesistere non solo a livello di dom<strong>in</strong>io MPLS ma anche a<br />

livello di un s<strong>in</strong>golo l<strong>in</strong>k.<br />

93


__________________________________________________________________<br />

3.5 ARCHITETTURA GMPLS<br />

L’architettura GMPLS è nata <strong>per</strong> far fronte ai limiti <strong>del</strong>l’architettura MPLS nelle<br />

<strong>reti</strong> completamente <strong>ottiche</strong> di prossima generazione. Il concetto di base <strong>del</strong><br />

GMPLS è lo stesso <strong>del</strong> MPLS: tra lo strato 2 e lo strato 3 di ogni pacchetto viene<br />

<strong>in</strong>serita una <strong>la</strong>bel e l’<strong>in</strong>stradamento avviene proprio tramite questa <strong>la</strong>bel. In uno<br />

scenario di rete ottica l’architettura MPLS risulta <strong>in</strong>sufficiente <strong>per</strong> <strong>la</strong> gestione<br />

degli OXC, PXC e OADM, dispositivi che svolgono commutazione nel dom<strong>in</strong>io<br />

<strong>del</strong> tempo, <strong>del</strong>lo spazio e <strong>del</strong><strong>la</strong> lunghezza d’onda, ed è così stata estesa evolvendo<br />

nell’architettura GMPLS: l’<strong>in</strong>sieme dei protocolli IP che gestiscono e control<strong>la</strong>no<br />

gli LSP che attraversano le <strong>reti</strong> <strong>ottiche</strong> a pacchetto o TDM vengono modificati ed<br />

estesi all’<strong>in</strong>terno <strong>del</strong> GMPLS.<br />

Nell’architettura GMPLS gli LSR ( Label Switch<strong>in</strong>g Router ) comprendono<br />

dispositivi che <strong>in</strong>stradano su base time-slot, lunghezza d’onda o phisycal port. Le<br />

<strong>in</strong>terfacce presenti suli LSR possono essere c<strong>la</strong>ssificate <strong>in</strong>:<br />

- Packets Switch Capable ( PSC ): <strong>in</strong> cui l’<strong>in</strong>stradamento si basa sul contenuto<br />

<strong>del</strong> header <strong>del</strong> pacchetto, come ad esempio l’header IP;<br />

- Layer -2 Switch Capable ( LSC ): l’<strong>in</strong>stradamento avviene tramite il contenuto<br />

<strong>del</strong> frame/cell boundaries header, come ad esempio le <strong>in</strong>terfacce ATM-LSR che<br />

<strong>in</strong>stradano <strong>in</strong> base all’ ATM-VPI/VCI;<br />

- Time Division Multiplex Capable ( TDM ): <strong>in</strong> cui l’<strong>in</strong>stradamento si basa<br />

sull’<strong>in</strong>formazione contenuta <strong>in</strong> un determ<strong>in</strong>ato time-slot;<br />

- Lamda Switch Capable ( LSC ): l’<strong>in</strong>stradamento avviene sul<strong>la</strong> base <strong>del</strong><strong>la</strong><br />

lunghezza d’onda;<br />

- Fiber Switch Capable ( FSC ): <strong>in</strong> cui l’<strong>in</strong>stradamento è effettuato nel dom<strong>in</strong>io<br />

<strong>del</strong>lo spazio.<br />

Ogni LSP <strong>in</strong>izia e term<strong>in</strong>a su <strong>in</strong>terfacce <strong>del</strong>lo stesso tipo ed un nuovo LSP può<br />

essere annidato <strong>in</strong> un LSP già esistente ma di ord<strong>in</strong>e su<strong>per</strong>iore: esiste dunque una<br />

gerarchia tra gli LSP che si basa sul<strong>la</strong> capacità di multip<strong>la</strong>zione dei nodi <strong>del</strong><strong>la</strong> rete.<br />

94


__________________________________________________________________<br />

Figura 25: Annidamento degli LSP<br />

Diversi PSC-LSP possono essere annidati <strong>in</strong> un TDM-LSP e diversi TDM-LSP<br />

possono a loro volta essere annidati <strong>in</strong> un LSC-LSP. Al vertice <strong>del</strong><strong>la</strong> gerarchia vi<br />

sono gli FSC-LSP nei quali possono essere annidati diversi LSC-LSP. Tutti gli<br />

LSP sono presenti nel database di rout<strong>in</strong>e dei protocolli di l<strong>in</strong>k state IS-IS/OSPF<br />

come nuovi tipi di collegamento. Mediante <strong>la</strong> tecnica <strong>del</strong> fload<strong>in</strong>g ogni nodo <strong>del</strong><strong>la</strong><br />

rete si costruisce al suo <strong>in</strong>terno un L<strong>in</strong>k State Database, che contiene non solo<br />

<strong>in</strong>formazioni riguardanti i l<strong>in</strong>k tradizionali, con tutti i loro attributi, ma anche tutti<br />

gli LSP attivi. Poichè con il DWDM si possono avere molti l<strong>in</strong>k paralleli con<br />

conseguente aumento <strong>del</strong>le dimensione <strong>del</strong> L<strong>in</strong>k State Database, nell’architettura<br />

GMPLS è stato <strong>in</strong>trodotto il concetto di L<strong>in</strong>k Bundl<strong>in</strong>g, secondo il quale vengono<br />

aggregati gli attributi di collegamento di numerosi collegamenti paralleli, aventi<br />

caratteristiche simili, e poi assegnati ad un s<strong>in</strong>golo L<strong>in</strong>k (Bundl<strong>in</strong>g L<strong>in</strong>k). Un altro<br />

cambiamento <strong>in</strong>trodotto nel GMPLS riguarda <strong>la</strong> direzionalità degli LSP.<br />

Nell’architettura MPLS gli LSP sono unidirezionali, qu<strong>in</strong>di <strong>per</strong> <strong>in</strong>staurare un LSP<br />

bidirezionale, devono essere <strong>in</strong>staurati due LSP unidirezionali <strong>in</strong>dipendenti,<br />

questo approccio presenta diversi svantaggi:<br />

95


__________________________________________________________________<br />

- Ritardo di <strong>in</strong>staurazione<br />

- Scelta d’<strong>in</strong>stradamento<br />

- Dimensione <strong>del</strong>l’overhead.<br />

In GMPLS sono stati <strong>in</strong>trodotti dei metodi addizionali <strong>per</strong> <strong>per</strong>mettere<br />

l’<strong>in</strong>staurazione di LSP bidirezionali utilizzando un s<strong>in</strong>golo messaggio <strong>del</strong><br />

protocollo di segna<strong>la</strong>zione. Questo riduce il tempo di ritardo essenzialmente a un<br />

solo round-trip tra il nodo di potenza ed il nodo di dest<strong>in</strong>azione, più il tempo di<br />

e<strong>la</strong>borazione.<br />

Poichè il GMPLS <strong>per</strong>mette le commutazioni di fibra, di lunghezza d’onda e di<br />

time-slot, <strong>la</strong> <strong>la</strong>bel è stata necessariamente modificata. Infatti essa non è più<br />

associata solo ad un determ<strong>in</strong>ato pacchetto, ma anche ad una fibra, ad una<br />

lunghezza d’onda o ad un time-slot. Le <strong>in</strong>formazioni che una generalized <strong>la</strong>bel<br />

deve contenere riguardano:<br />

- LSP encod<strong>in</strong>g type: <strong>in</strong>dica il tipo di <strong>la</strong>bel a cui deve essere associato l’LSP;<br />

- Switch<strong>in</strong>g type: <strong>in</strong>dica il tipo di commutazione che si può effettuare su un<br />

determ<strong>in</strong>ato l<strong>in</strong>k;<br />

- Payload Identifier: <strong>in</strong>dica il tipo di payload trasportato da quel determ<strong>in</strong>ato LSP.<br />

96


__________________________________________________________________<br />

Capitolo 4<br />

STRUTTURA ED ELEMENTI DEL<br />

TEST- BED<br />

In questo capitolo vengono illustrati nel dettaglio <strong>la</strong> struttura <strong>del</strong> test-<strong>bed</strong><br />

utilizzato e le strumentazioni che lo costituiscono.<br />

Partico<strong>la</strong>re attenzione viene data ai Router Juni<strong>per</strong> M10, nucleo <strong>del</strong> test-<strong>bed</strong>, alle<br />

loro funzionalità ed al l<strong>in</strong>guaggio proprietario di configurazione JUNOS.<br />

Verranno descritti i pr<strong>in</strong>cipi di funzionamento <strong>del</strong> sistema da me proposto e<br />

verranno analizzate <strong>in</strong> dettaglio le parti hardware e software utilizzate <strong>per</strong> <strong>la</strong>sua<br />

effettiva realizzazione.<br />

97


4.1 TEST-BED MPLS PER LE MISURE OGGETTIVE DELLA<br />

QUALITA’ DEL SERVIZIO.<br />

4.1.1 Struttura <strong>del</strong> test-<strong>bed</strong><br />

Al f<strong>in</strong>e di valutare il comportamento <strong>del</strong><strong>la</strong> tecnica E-LSP 12 <strong>del</strong>l’ approccio<br />

“DiffServ over MPLS” è stato implementato un test-<strong>bed</strong> s<strong>per</strong>imentale. Il test-<strong>bed</strong><br />

realizzato <strong>in</strong> col<strong>la</strong>borazione con l’ISCOM (Istituto Su<strong>per</strong>iore <strong>del</strong>le<br />

Comunicazioni) è rappresentato <strong>in</strong> figura e prevede <strong>la</strong> col<strong>la</strong>borazione di tre<br />

<strong>la</strong>boratori dist<strong>in</strong>ti:<br />

• Trasmissioni <strong>ottiche</strong> (ufficio III ISCOM)<br />

• Valutazione <strong>del</strong><strong>la</strong> QoS multimediale (ufficio IV ISCOM)<br />

• Reti <strong>ottiche</strong> d<strong>in</strong>amiche (primo piano ISCOM)<br />

Tra i <strong>la</strong>boratori è stato creato un collegamento ad hoc <strong>in</strong> fibra ottica multimodale.<br />

Laboratorio trasmissioni <strong>ottiche</strong>.<br />

In questo <strong>la</strong>boratorio è attestato un collegamento all’anello ottico Roma-Pomezia;<br />

il l<strong>in</strong>k che collega <strong>in</strong> anello Roma e Pomezia è lungo 24 Km “one way” ed è<br />

costituito da 80 fibre di cui 30 ds (dis<strong>per</strong>sion shifted) 20 nzd (non zero dis<strong>per</strong>sion)<br />

e 30 sf.<br />

A questo l<strong>in</strong>k ottico sotto test sono connessi i due Router Juni<strong>per</strong> M10.<br />

12 Ex<strong>per</strong>imental bit Inferred LSP: Viene utilizzato il campo EXP <strong>del</strong>lo shim header come<br />

sostituto <strong>del</strong> campo DSCP <strong>per</strong> portare l’<strong>in</strong>formazione <strong>del</strong> DSCP all’<strong>in</strong>terno <strong>del</strong> dom<strong>in</strong>io MPLS.


__________________________________________________________________<br />

L<strong>in</strong>k sotto test<br />

L<strong>in</strong>k di collegamento fra <strong>la</strong>boratori <strong>in</strong> fibra ottica mmf<br />

L<strong>in</strong>k di collegamento <strong>in</strong> fibra ottica smf<br />

L<strong>in</strong>k di collegamento FastEthernet<br />

MULTIMEDIA SERVER<br />

SERVER CHARIOT<br />

Hub<br />

Laboratorio <strong>valutazione</strong> <strong>del</strong><strong>la</strong> QoS multimediale – Ufficio IV ISCOM<br />

conv e/o<br />

1,25 GBE<br />

Laboratorio trasmissivo <strong>reti</strong> <strong>ottiche</strong><br />

-ISCOM-<br />

ANELLO OTTICO<br />

ROMA-POMEZIA<br />

Fibra ottica smf<br />

1550<br />

Fibra ottica mmf<br />

conv e/o<br />

CLIENT-1 CHARIOT<br />

fe<br />

1,25 GBE 1,25 GBE<br />

fe<br />

<strong>la</strong>boratorio <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche – Ufficio III ISCOM<br />

GENERATORE-ANALIZZATORE DI<br />

CLIENT-2 CHARIOT<br />

Figura 4.1: Schema <strong>del</strong> <strong>Test</strong>-Bed utilizzato <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> Oggettiva <strong>del</strong><strong>la</strong> QoS<br />

Laboratorio <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche.<br />

In questo <strong>la</strong>boratorio sono presenti:<br />

• due router Juni<strong>per</strong> M10 ed un terzo sotto test.<br />

• un generatore/analizzatore di traffico Anritsu MD1230A<br />

• un attenuatore ottico variabile Anritzu MD9610B<br />

• due Client Chariot<br />

• un convertitore elettro-ottico che collega con il <strong>la</strong>boratorio <strong>per</strong> <strong>la</strong><br />

<strong>valutazione</strong> <strong>del</strong><strong>la</strong> QoS multimediale.<br />

99


__________________________________________________________________<br />

Laboratorio <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> <strong>del</strong><strong>la</strong> QoS multimediale.<br />

In questo <strong>la</strong>boratorio è presente il Server Chariot, col quale si effettuano le misure<br />

oggettive, e tutta <strong>la</strong> strumentazione che verrà utilizzata <strong>in</strong> seguito <strong>per</strong> le prove<br />

soggettive.<br />

4.1.2 Presentazione <strong>del</strong> <strong>Test</strong>-<strong>bed</strong><br />

All’ anello ottico, cui sono collegati i due router Juni<strong>per</strong>, viene <strong>in</strong>serito il<br />

generatore analizzatore di traffico Anritsu presente nel “<strong>la</strong>boratorio <strong>reti</strong> <strong>ottiche</strong><br />

d<strong>in</strong>amiche”. Questo strumento è dotato di due <strong>in</strong>terfacce <strong>ottiche</strong> GbE sulle quali è<br />

possibile generare traffico f<strong>in</strong>o a 800 Mbit/s ed otto <strong>in</strong>terfacce FastEthernet <strong>in</strong><br />

grado di produrre traffico <strong>per</strong> 100 Mbit/s ognuna.<br />

Tramite questo generatore è possibile saturare f<strong>in</strong>o al limite (1,25 Gbit/s) il l<strong>in</strong>k<br />

ottico sotto test, avendo così <strong>la</strong> possibilità di effettuare <strong>del</strong>le misure <strong>in</strong> ogni<br />

condizione di carico <strong>del</strong><strong>la</strong> rete.<br />

Il traffico di saturazione può essere etichettato <strong>in</strong> accordo con l’approccio<br />

DiffServ.<br />

Ai due router Juni<strong>per</strong> M10 sono stati collegati due PC, il primo è un Atlon dotato<br />

di un processore MD con CPU da 1.40 GHz, 512 MB di RAM, sistema o<strong>per</strong>ativo<br />

Microsoft W<strong>in</strong>dows XP Professional versione 2002 e Service Pack 1, scheda di<br />

rete Intel® PRO/100 VE Network Connection; il secondo PC è una Dell<br />

Workstation PWS 650 con doppio processore Intel® Xeon 240TM, clock <strong>del</strong><strong>la</strong><br />

CPU a 2.40GHz, 1,25 GB di Ram, sistema o<strong>per</strong>ativo Microsoft W<strong>in</strong>dows XP<br />

PRO versione 2002 e Service Pack 1, scheda di rete Intel® PRO/1000 MTW<br />

Network Connection.<br />

Tramite un collegamento <strong>in</strong> fibra multimodale il <strong>la</strong>boratorio <strong>del</strong>l’ufficio III è stato<br />

collegato con quello al sesto piano <strong>del</strong><strong>la</strong> QoS multimediale <strong>del</strong>l’ufficio VI.<br />

In questo <strong>la</strong>boratorio è presente un server di dati realizzato mediante l’istal<strong>la</strong>zione<br />

<strong>del</strong> software Chariot prodotto dal<strong>la</strong> NetIQ. La versione client di questo<br />

100


__________________________________________________________________<br />

programma è stata istal<strong>la</strong>ta sui PC <strong>del</strong> <strong>la</strong>boratorio 1S. Dopo alcune prove <strong>in</strong>ziali<br />

tra tutti i PC cui era stata istal<strong>la</strong>ta <strong>la</strong> versione client <strong>la</strong> scelta è andata su due PC<br />

descritti sopra. Mediante l’<strong>in</strong>terazione tra di queste tre macch<strong>in</strong>e (server più due<br />

client) è possibile effettuare uno scambio di traffico dati tra i client collegati ai<br />

due diversi router e dunque alle estremità <strong>del</strong>l’anello, e misurarne i parametri<br />

significativi col server. I dati scambiati posso essere di diverso tipo, ad esempio<br />

video conferenza realizzata mediante sessione Netmeet<strong>in</strong>g, “download” di dati di<br />

tipo FTP (File Transfer Protocol), sessioni di VoIP (Voice over IP) etc; <strong>in</strong>oltre<br />

tramite il server Chariot è possibile decidere il rate <strong>del</strong> traffico <strong>in</strong>viato e marcare il<br />

campo DSCP dei pacchetti IPv4 <strong>in</strong> accordo con l’approccio DiffServ.<br />

Quando i flussi etichettati dal Chariot giungono ad uno dei due router viene subito<br />

esam<strong>in</strong>ato il campo DSCP, questo determ<strong>in</strong>a il trattamento che subirà il pacchetto.<br />

In seguito il pacchetto viene <strong>in</strong>oltrato sull’<strong>in</strong>terfaccia GigabitEthernet di uscita<br />

verso l’<strong>in</strong>terfaccia GigabitEthernet di <strong>in</strong>gresso <strong>del</strong>l’altro router il quale, <strong>in</strong> seguito<br />

ad un ulteriore studio <strong>del</strong> campo DSCP, adotterà una opportuna politica di QoS ed<br />

<strong>in</strong>straderà i flussi verso <strong>la</strong> sua <strong>in</strong>terfaccia di uscita che <strong>in</strong> questo caso è una<br />

FastEthernet.<br />

Circa <strong>la</strong> descrizione <strong>del</strong> test-<strong>bed</strong> <strong>in</strong> esame va osservato che <strong>la</strong> totalità <strong>del</strong> traffico<br />

che entra ed esce dalle <strong>in</strong>terfacce dei router Juni<strong>per</strong>, ovvero il traffico di<br />

saturazione <strong>del</strong>l’Anritsu e quello di test <strong>del</strong> Chariot, è traffico etichettato; i due<br />

router non svolgono alcuna o<strong>per</strong>azione sui pacchetti ma applicano semplicemente<br />

il PHB re<strong>la</strong>tivamente al<strong>la</strong> c<strong>la</strong>sse di servizio cui appartengono. I due router Juni<strong>per</strong><br />

sono configurati come Core Router.<br />

101


__________________________________________________________________<br />

Figura 4.26: Partico<strong>la</strong>re <strong>del</strong> <strong>la</strong>boratorio <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche<br />

Figura 4.27: Partico<strong>la</strong>re <strong>del</strong> <strong>la</strong>boratorio <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche<br />

102


__________________________________________________________________<br />

4.2 ELEMENTI DELLA RETE<br />

4.2.1 Router Juni<strong>per</strong> M10<br />

Per <strong>la</strong> realizzazione <strong>del</strong> test-<strong>bed</strong> sono stati impiegati due router Juni<strong>per</strong> M10.<br />

Ogni router può montare f<strong>in</strong>o ad 8 PIC (Physical Interface Card), ognuna <strong>del</strong>le<br />

quali ospita una o più <strong>in</strong>terfacce <strong>del</strong>lo stesso tipo.<br />

Figura 4.4: Partico<strong>la</strong>re <strong>del</strong>le PIC <strong>del</strong> router Juni<strong>per</strong> M10 e degli attenuatori variabili.<br />

I router utilizzati nel test-<strong>bed</strong> sono equipaggiati entrambi <strong>del</strong>le stesse schede:<br />

103


__________________________________________________________________<br />

• Una PIC con 4 <strong>in</strong>terfacce Fast Ethernet (100 BASE TX), come risorse<br />

trasmissive vengono utilizzati cavi <strong>in</strong> rame <strong>in</strong>trecciati, e si può trasmettere<br />

f<strong>in</strong>o a 100Mbit/s. Nei router sono state <strong>in</strong>dicate con le sigle fe-0/1/0, fe-<br />

0/1/1, fe-0/1/2, fe-0/1/3 da s<strong>in</strong>istra verso destra.<br />

• Due PIC con 1 <strong>in</strong>terfaccia Gigabit Ethernet (1000 BASE LX – 1550 nm)<br />

ciascuna. Il mezzo trasmissivo di questo modulo è costituito da fibra ottica<br />

utilizzata <strong>in</strong> terza f<strong>in</strong>estra. La fibra viene di solito impiegata <strong>per</strong><br />

collegamenti ad alta velocità e molto capacitivi su <strong>reti</strong> LAN e MAN, va<br />

<strong>per</strong>ò osservato che esistono dei moduli Gigabit Ethernet con portante <strong>in</strong><br />

rame. Nei router le <strong>in</strong>terfacce sono state <strong>in</strong>dicate con le sigle ge-0/0/0<br />

quel<strong>la</strong> di destra che si collega all’anello Roma-Pomezia, e ge-0/2/0 quel<strong>la</strong><br />

di s<strong>in</strong>istra che si collega al generatore/analizzatore di traffico Anritsu.<br />

Le <strong>in</strong>terfacce disponibili appena descritte dei router sono state utilizzate <strong>in</strong><br />

questo modo:<br />

2 Fast Ethernet ed 1 Gigabit Ethernet sono state collegate al<br />

generatore/analizzatore di traffico Anritsu, <strong>per</strong> congestionare <strong>la</strong><br />

rete e metterci nelle probabili condizioni <strong>in</strong> cui può trovarsi una<br />

rete di trasporto metropolitana.<br />

1 Fast Ethernet è stata collegata ai Client Chariot <strong>per</strong> misurare lo<br />

scambio di traffico etichettato tra i due term<strong>in</strong>ali di rete.<br />

1 Gigabit Ethernet è stata utilizzata <strong>per</strong> collegare i due router con<br />

l’anello Roma-Pomezia (ge-0/0/0).<br />

Per quanto concerne <strong>la</strong> quarta porta Fast Ethernet disponibile, nel<br />

primo router è stata collegata ad un convertitore elettro-ottico <strong>per</strong><br />

<strong>per</strong>mettere il collegamento tra i due <strong>la</strong>boratori, mentre nell’altro<br />

router all’<strong>in</strong>terfaccia è connesso un access po<strong>in</strong>t.<br />

104


__________________________________________________________________<br />

4.2.2 Architettura generale dei router<br />

L’ architettura complessiva dei router è costituita essenzialmente da tre<br />

componenti fondamentali:<br />

1. Componente di controllo: gestisce le politiche di <strong>in</strong>stadamento e dunque si<br />

occupa <strong>del</strong> calcolo <strong>del</strong> <strong>per</strong>corso migliore che ogni pacchetto deve fare.<br />

2. Componente di forward<strong>in</strong>g: gestisce l’<strong>in</strong>oltro dei pacchetti dalle porte di<br />

<strong>in</strong>gresso alle porte di uscita <strong>per</strong> <strong>la</strong> trasmissione attraverso <strong>la</strong> rete.<br />

3. Componente di memorizzazione ed accoramento dei pacchetti: il sistema<br />

di memorizzazione ed accoramento ha <strong>la</strong> funzione di memorizzare<br />

temporaneamente i pacchetti <strong>in</strong> grandi buffer <strong>per</strong> assorbire i burst di traffico.<br />

Figura 4.28: Architettura generale di un router<br />

105


__________________________________________________________________<br />

Attualmente le funzioni di controllo e quelle di forward<strong>in</strong>g sono totalmente<br />

separate <strong>in</strong> modo da evitare colli di bottiglia e mantenere costantemente<br />

prestazioni elevate.<br />

La componente di controllo viene denom<strong>in</strong>ata Rout<strong>in</strong>e Eng<strong>in</strong>e (R.E.) ed è<br />

realizzata mediante software specifico, provvede ad implementare protocolli di<br />

rout<strong>in</strong>g ed a creare le tabelle di forward<strong>in</strong>g. Le funzionalità <strong>del</strong><strong>la</strong> R.E. sono svolte<br />

<strong>in</strong> maniera <strong>in</strong>dipendente dal traffico.<br />

La componente di forward<strong>in</strong>g è realizzata completamente i hardware mediante<br />

l’utilizzo di dispositivi di dispositivi dedicati e l’architettura complessiva viene<br />

chiamata Packet Forward<strong>in</strong>g Eng<strong>in</strong>e (P.F.E.).<br />

Le pr<strong>in</strong>cipale funzioni svolte dal Packet Forward<strong>in</strong>g Eng<strong>in</strong>e sono:<br />

Analisi ed e<strong>la</strong>borazione <strong>del</strong>l’<strong>in</strong>testazione dei pacchetti.<br />

Consultazione <strong>del</strong>le tabelle di rout<strong>in</strong>g <strong>per</strong> le decisioni di <strong>in</strong>stradamento.<br />

C<strong>la</strong>ssificazione ed accoramento dei pacchetti.<br />

La capacità di forward<strong>in</strong>g di un router dipende dal<strong>la</strong> velocità di identificazione<br />

<strong>del</strong>l’<strong>in</strong>terfaccia di uscita fatta tramite <strong>la</strong> consultazione <strong>del</strong>le tabelle di<br />

<strong>in</strong>stradamento.<br />

Il trasferimento dei pacchetti dalle porte di <strong>in</strong>gresso alle porte di uscita è attuato<br />

mediante sistemi di <strong>in</strong>terconnessione (switch fabric) e di accodamento dei<br />

pacchetti. La parte di <strong>in</strong>terconnessione può essere realizzata con diverse soluzioni:<br />

Bus<br />

Matrici Crossbar<br />

Memorie condivise<br />

4.2.3 Router Juni<strong>per</strong> M10: architettura<br />

L’architettura hardware <strong>del</strong><strong>la</strong> serie M di Juni<strong>per</strong> segue il mo<strong>del</strong>lo logico di<br />

architettura centralizzata, con P.F.E. a processori paralleli e condivisi, <strong>in</strong>dipendente<br />

dal<strong>la</strong> Rout<strong>in</strong>g Eng<strong>in</strong>e.<br />

Questo tipo di architettura è costituita logicamente da una parte centrale che<br />

contiene una matrice di connessione (switch fabric), da un <strong>in</strong>sieme di P.F.E. a<br />

106


__________________________________________________________________<br />

processori paralleli e da una memoria condivisa di grandi dimensioni. Il Router<br />

Juni<strong>per</strong> M10 presenta un unico Packet Forward<strong>in</strong>g.<br />

La componente di forward<strong>in</strong>g <strong>del</strong> router Juni<strong>per</strong> M10 è implementata mediante<br />

processori di pacchetto ASIC (Application Specific IntegratedCircuit) ed è<br />

composta da:<br />

1- Physical Interface Card (PIC): connettono fisicamente il router al<strong>la</strong> fibra<br />

ottica o agli altri mezzi trasmessivi come i cavi di rete. Un controllore<br />

ASIC effettua specifiche funzioni <strong>per</strong> ogni tipo di PIC, a seconda <strong>del</strong><br />

mezzo trasmissivo.<br />

2- Flexible PIC Concentrator (FPC): ospita le PIC e fornisce <strong>la</strong> memoria<br />

condivisa <strong>per</strong> il processamento dei pacchetti entranti. Le F.P.C.<br />

contengono anche due I/0 Manager ASIC che dividono i pacchetti entranti<br />

<strong>in</strong> blocchi di memoria (celle) e li riassemb<strong>la</strong>no quando sono pronti <strong>per</strong> <strong>la</strong><br />

trasmissione.<br />

3- Internet Processor II: è responsabile <strong>del</strong>le decisioni di forward<strong>in</strong>g.<br />

4- Distributed Buffer Manager ASIC: sono due, uno di essi distribuisce le<br />

celle di dati nel<strong>la</strong> memoria condivisa <strong>del</strong>le Flexible Pic Concentrator,<br />

l’altro <strong>in</strong>forma le F.P.C. <strong>del</strong>le decisioni prese dall’Internet Processor II <strong>per</strong><br />

i pacchetti uscenti.<br />

Il funzionamento <strong>del</strong><strong>la</strong> Packet Forward<strong>in</strong>g Eng<strong>in</strong>e può essere compreso seguendo il<br />

<strong>per</strong>corso di un pacchetto attraverso il router. I pacchetti arrivano ad una <strong>in</strong>terfaccia<br />

PIC di <strong>in</strong>gresso, il controller <strong>del</strong><strong>la</strong> PIC effettua alcune o<strong>per</strong>azioni di controllo, come<br />

ad esempio <strong>la</strong> verifica <strong>del</strong> checksum, e poi l’<strong>in</strong>terfaccia PIC cede i pacchetti al<strong>la</strong><br />

FPC che a sua volta li dirige verso l’I/0 Manager ASIC. L’I/0 Manager processa<br />

l’header dei pacchetti identificando se si tratta di un pacchetto IPv4 o di un home<br />

MPLS, li divide <strong>in</strong> celle di 64 byte e passa ogni blocco di memoria ad un<br />

Distributed Buffer Manager ASIC; quest’ultimo le distribuisce su tutte le memorie<br />

condivise posizionate su ogni FPC e contemporaneamente <strong>in</strong>via l’header <strong>del</strong><br />

pacchetto all’Internet Processor II <strong>per</strong> il lookup. Se l’unità di dati è un pacchetto<br />

IPv4 il Distributed Buffer Manager <strong>in</strong>via al processore ASIC le seguenti<br />

<strong>in</strong>formazioni: <strong>in</strong>terfaccia di arrivo, <strong>in</strong>dirizzo IP di dest<strong>in</strong>azione, <strong>in</strong>dirizzo IP di<br />

107


__________________________________________________________________<br />

orig<strong>in</strong>e, il numero di protocollo ed il campo porta di orig<strong>in</strong>e e dest<strong>in</strong>azione nel caso<br />

di UDP e TCP. Se, <strong>in</strong>vece, il pacchetto è MPLS l’unico valore da estrarre è <strong>la</strong> <strong>la</strong>bel<br />

<strong>in</strong> testa al pacchetto. A questo punto l’Internet Processor II accede al<strong>la</strong> forward<strong>in</strong>g<br />

table <strong>per</strong> <strong>in</strong>dividuare l’<strong>in</strong>terfaccia di uscita e lo specifico next-hop, qu<strong>in</strong>di notifica al<br />

secondo Distributed Buffer Manager ASIC <strong>la</strong> decisione presa. Quest’ultimo <strong>in</strong>via <strong>la</strong><br />

notifica al<strong>la</strong> FPC che ospita <strong>la</strong> giusta <strong>in</strong>terfaccia di uscita. Ogni porta di uscita ha<br />

quattro code, ognuna <strong>del</strong>le quali ha a disposizione parte <strong>del</strong><strong>la</strong> banda <strong>del</strong><br />

collegamento; quando un pacchetto giunge <strong>in</strong> testa al<strong>la</strong> coda ed è pronto <strong>per</strong> <strong>la</strong><br />

trasmissione viene riassemb<strong>la</strong>to dall’I/O Manager e poi <strong>in</strong>viato al<strong>la</strong> specifica PIC<br />

<strong>per</strong> <strong>la</strong> trasmissione <strong>in</strong> l<strong>in</strong>ea.<br />

In un’architettura centralizzata, come quel<strong>la</strong> <strong>del</strong> Router Juni<strong>per</strong> M10, le risorse di<br />

processamento, logicamente centralizzate, sono condivise da tutte le schede di l<strong>in</strong>ea<br />

consentendo un’utilizzazione molto efficace <strong>del</strong>le stesse. Infatti, non essendo<br />

necessario che le <strong>in</strong>formazioni di forward<strong>in</strong>g vengano distribuite su ogni l<strong>in</strong>e card,<br />

gli aggiornamenti <strong>del</strong><strong>la</strong> tabel<strong>la</strong> di forward<strong>in</strong>g non provocano <strong>in</strong>terruzioni <strong>del</strong>le<br />

o<strong>per</strong>azioni di ogni scheda di l<strong>in</strong>ea. In un’architettura distribuita <strong>in</strong>vece<br />

l’aggiornamento <strong>del</strong><strong>la</strong> tabel<strong>la</strong> di forward<strong>in</strong>g centrale determ<strong>in</strong>a un aggiornamento di<br />

tutte le forward<strong>in</strong>g table residenti sulle schede i l<strong>in</strong>ea che qu<strong>in</strong>di <strong>in</strong>corrono <strong>in</strong> un<br />

<strong>per</strong>iodo di blocco pari al tempo di aggiornamento <strong>del</strong><strong>la</strong> propria tabel<strong>la</strong> di<br />

forward<strong>in</strong>g.<br />

Figura 4.29: Architettura <strong>del</strong> router Juni<strong>per</strong> M10<br />

108


__________________________________________________________________<br />

I due router Juni<strong>per</strong> sono configurati con il protocollo OSPF ed RSVP <strong>per</strong> <strong>la</strong><br />

creazione e l’aggiornamento <strong>del</strong>le tabelle di rout<strong>in</strong>g e <strong>la</strong> riservazione <strong>del</strong>le risorse;<br />

<strong>in</strong>oltre sulle GigabitEthernet ge-0/0/0 (anello Roma-Pomezia), oltre al protocollo<br />

IP, è stato configurato anche il protocollo MPLS ed i re<strong>la</strong>tivi LSP unidirezionali.<br />

Figura 4.30: Foto di uno dei due router Juni<strong>per</strong> M10<br />

4.2.4 Software JUNOS<br />

Il software JUNOS gira sul<strong>la</strong> Rout<strong>in</strong>g Eng<strong>in</strong>e <strong>del</strong> router ed è costituito da tanti<br />

processi software che: supportano i protocolli di rout<strong>in</strong>g, control<strong>la</strong>no le <strong>in</strong>terfacce<br />

ed <strong>in</strong>oltre <strong>per</strong>mettono <strong>la</strong> gestione di tutto il router. I processi girano tutti sul<br />

Kernel che <strong>per</strong>mette <strong>la</strong> comunicazione tra i processi ed ha un collegamento diretto<br />

con il software <strong>del</strong><strong>la</strong> Packet Forward<strong>in</strong>g Eng<strong>in</strong>e. Il software Junos <strong>per</strong>mette di<br />

configurare i protocolli di rout<strong>in</strong>e e le proprietà <strong>del</strong>le <strong>in</strong>terfacce, può anche essere<br />

usato <strong>per</strong> monitorare il router e analizzare i problemi di rout<strong>in</strong>g o di connessione<br />

<strong>del</strong><strong>la</strong> rete. L’<strong>in</strong>sieme di tutti i processi che costituiscono lo Junos è suddiviso <strong>in</strong><br />

diversi gruppi:<br />

109


__________________________________________________________________<br />

- Processo protocolli di rout<strong>in</strong>g: questo processo control<strong>la</strong> i protocolli di<br />

rout<strong>in</strong>g configurati sul router ed è responsabile <strong>del</strong>l’<strong>in</strong>izializzazione dei<br />

protocolli stessi. Il processo mantiene aggiornate le tabelle di rout<strong>in</strong>g e dalle<br />

<strong>in</strong>formazioni ottenute dai protocolli, determ<strong>in</strong>a gli <strong>in</strong>stradamenti opportuni<br />

verso il router di dest<strong>in</strong>azione e <strong>in</strong>stal<strong>la</strong> tali route nel<strong>la</strong> Rout<strong>in</strong>g Eng<strong>in</strong>e<br />

forward<strong>in</strong>g table. Svolte queste o<strong>per</strong>azioni, il processo esegue <strong>la</strong> rout<strong>in</strong>g<br />

policy che <strong>per</strong>mette <strong>la</strong> gestione <strong>del</strong>le <strong>in</strong>formazioni di rout<strong>in</strong>g scambiate tra i<br />

protocolli di rout<strong>in</strong>g e <strong>la</strong> tabel<strong>la</strong> di rout<strong>in</strong>g. I protocolli di rout<strong>in</strong>g supportati<br />

dallo Junos sono il IS-IS, OSPF, RIP, ICMP, BGP, i procolli multicast come<br />

IGMP e SAP/SDP, e i protocolli re<strong>la</strong>tivi all’architettura MPLS quali MPLS,<br />

RSVP e LDP.<br />

- Processo <strong>in</strong>terfaccia: tale processo <strong>per</strong>mette di configurare e control<strong>la</strong>re le<br />

<strong>in</strong>terfacce fisiche e logiche <strong>in</strong>stal<strong>la</strong>te nel router. Il processo di <strong>in</strong>tefaccia <strong>del</strong>lo<br />

Junos comunica, attraverso il kernel Junos con il processo di <strong>in</strong>terfaccia nel<strong>la</strong><br />

Packet Forward<strong>in</strong>g Eng<strong>in</strong>e che abilita il software Junos ad analizzare e<br />

tracciare lo stato e <strong>la</strong> condizione <strong>del</strong>le <strong>in</strong>terfacce <strong>del</strong> router.<br />

- Processo chassis: <strong>per</strong>mette <strong>la</strong> configurazione e il controllo <strong>del</strong>le proprietà<br />

<strong>del</strong> router, <strong>in</strong>clusi al<strong>la</strong>rmi e sorgenti di clock.<br />

- Processo di gestione: nel sofware Junos esiste un processo <strong>per</strong> il controllo<br />

dei processi che attivato control<strong>la</strong> tutti i processi sofware che girano sul<br />

router. Nel momento <strong>del</strong> boot <strong>del</strong> router è proprio questo processo a far<br />

partire tutti i processi software e <strong>la</strong> CLI ( Command-L<strong>in</strong>e Interface ).<br />

- Rout<strong>in</strong>g Eng<strong>in</strong>e Kernel: è l’<strong>in</strong>frastuttura base sul<strong>la</strong> quale si appoggiano tutti<br />

i processi software <strong>del</strong>lo Junos; mette a disposizione un l<strong>in</strong>k <strong>per</strong> <strong>la</strong><br />

comunicazione tra le tabelle di rout<strong>in</strong>g e <strong>la</strong> Rout<strong>in</strong>g Eng<strong>in</strong>e forward<strong>in</strong>g table<br />

ed è <strong>in</strong>oltre responsabile di tutte le comunicazioni tra Rout<strong>in</strong>g Eng<strong>in</strong>e e<br />

Packet Forward<strong>in</strong>g Eng<strong>in</strong>e.<br />

110


__________________________________________________________________<br />

Per configurare il router viene messa a disposizione una <strong>in</strong>terfaccia utente/Junos<br />

detta CLI ( Command-L<strong>in</strong>e Interface ) che si attiva quando f<strong>in</strong>isce il boot <strong>del</strong><br />

router. La l<strong>in</strong>ea di comando CLI fornisce i comandi <strong>per</strong> <strong>la</strong> configurazione <strong>del</strong><br />

router e <strong>del</strong> software Junos e sono previste due modalità di funzionamento:<br />

- o<strong>per</strong>ational: è <strong>la</strong> modalità di default <strong>del</strong><strong>la</strong> CLI. Essa <strong>per</strong>mette di monitorare<br />

le o<strong>per</strong>azioni che sta svolgendo il router o il traffico che fluisce <strong>in</strong> esso, sia di<br />

servizio che di dati.<br />

- configuration: con il comando “configure” si passa dal<strong>la</strong> modalità<br />

o<strong>per</strong>ational al<strong>la</strong> modalità configuration ed è proprio <strong>in</strong> essa che è possibile<br />

configurare tutte le proprietà messe a disposizione dal software Junos, come<br />

<strong>la</strong> configurazione <strong>del</strong>le <strong>in</strong>terfacce, dei protocolli di rout<strong>in</strong>g e nel caso di<br />

questo <strong>la</strong>voro le c<strong>la</strong>ssi di servizio.<br />

Il software Junos presenta molte caratteristiche simili con il software Ios<br />

proprietario <strong>del</strong>le macch<strong>in</strong>e CISCO ma <strong>in</strong> partico<strong>la</strong>re differisce da quest’ultimo<br />

<strong>in</strong> quanto “meno ad alto livello”. Nel software Ios una buona parte di comandi<br />

gode di un alto grado di aumatizzazione, ad esempio quando si abilita un<br />

protocollo su un’<strong>in</strong>terfaccia non si ha poi <strong>la</strong> necessità di abilitare <strong>la</strong> stessa<br />

<strong>in</strong>terfaccia nel<strong>la</strong> dichiarazione <strong>del</strong> protocollo, nel software Junos <strong>in</strong>vece questo<br />

modo di procedere è obbligatorio.<br />

Circa <strong>la</strong> gestione <strong>del</strong> management il software Ios ha un protocollo proprietario<br />

simile al protocollo SMNP ma più semplice e user frendly nel software Junos<br />

<strong>in</strong>vece si deve ricorrere all’impiego <strong>del</strong>l’ SMNP <strong>in</strong> modo pienamente conforme<br />

all’RFC di riferimento.<br />

111


__________________________________________________________________<br />

4.2.5 Generatore/analizzatore di traffico<br />

Per produrre il traffico etichettato di simu<strong>la</strong>zione è stato impiegato un<br />

generatore/analizzatore di traffico Anritsu. Questo dispositivo è composto da<br />

quattro moduli ma quello utilizzato ne ha attivi due: uno con 8 FastEthernet e uno<br />

con due GigabitEthernet 13 (a 1310 nm ). Delle 8 FastEthernet ne sono state<br />

utilizzate quattro, due <strong>per</strong> router, mentre sono state impiegate tutte e due le<br />

GigabitEthernet (vedi figura). Ogni porta è gestita <strong>in</strong> modo separato, può produrre<br />

qualsiasi tipo di traffico <strong>in</strong>dipendentemente dalle altre e <strong>la</strong> velocità di trasmissione<br />

può essere settata dall’o<strong>per</strong>atore variando il tempo di <strong>in</strong>ter-frame. Il traffico<br />

generato <strong>per</strong> saturare <strong>la</strong> rete <strong>in</strong> esame è il seguente:<br />

- 2 GigabitEthernet sono state configurate <strong>per</strong> generare traffico Best-Effort al<br />

massimo <strong>del</strong> throughput: 800 Mbit/s;<br />

- 1 FastEthernet è stata settata <strong>per</strong> generare traffico Assured-Forward<strong>in</strong>g al massimo<br />

<strong>del</strong><strong>la</strong> velocità di trasmissione, ovvero 80 Mb/s;<br />

- 1 FastEthernet è stata impiegata <strong>per</strong> il traffico Expedited-Forward<strong>in</strong>g con una<br />

velocità di trasmissione di 32 Mb/s.<br />

I motivi <strong>per</strong> cui <strong>la</strong> descrizione è così dettagliata nascono dal fatto che questi valori<br />

rappresentano i limiti massimi cui si è sp<strong>in</strong>to il carico di rete <strong>per</strong> garantire <strong>la</strong> qualità<br />

<strong>del</strong> servizio rimanendo entro i limiti forniti dalle normative di riferimento. Tutto ciò<br />

verrà spiegato nel dettaglio <strong>in</strong> seguito.<br />

13 Le lunghezze d’onda <strong>del</strong>le GigabitEthernet dei router Juni<strong>per</strong> e <strong>del</strong> generatore di traffico<br />

Anritsu sono diverse ( III° e II° f<strong>in</strong>estra) ma <strong>la</strong> comunicazione può avvenire lo stesso grazie<br />

all’ampio spettro di guadagno dei fotodiodi <strong>in</strong> ricezione.<br />

112


__________________________________________________________________<br />

Figura 4.31: Partico<strong>la</strong>re dei moduli già configurati <strong>per</strong> le prove.<br />

Figura 4.32: throughput prodotto dalle GigabitEthernet dest<strong>in</strong>ato al<strong>la</strong> saturazione <strong>del</strong>l’anello<br />

Roma-Pomezia<br />

113


__________________________________________________________________<br />

4.2.6 Chariot: Server e Client<br />

Per <strong>la</strong> <strong>valutazione</strong> <strong>del</strong><strong>la</strong> QoS <strong>in</strong> term<strong>in</strong>i di prestazioni di rete è stato utilizzato il<br />

sistema software client-server Chariot. Il software Server è stato <strong>in</strong>stal<strong>la</strong>to nel<br />

<strong>la</strong>boratorio <strong>per</strong> <strong>la</strong> <strong>valutazione</strong> <strong>del</strong><strong>la</strong> QoS multimediale mentre il software Client su<br />

due PC presenti nel <strong>la</strong>boratorio <strong>reti</strong> <strong>ottiche</strong> d<strong>in</strong>amiche. Il funzionamento <strong>del</strong> sistema<br />

software è il seguente:<br />

• Tramite il Server si stabilisce il tipo di traffico che i due Client si devono<br />

scambiare, i protocolli di trasporto, le velocità di trasmissione e <strong>la</strong> c<strong>la</strong>sse<br />

di servizio dei pacchetti;<br />

• Dopo aver configurato il tipo di traffico, il Server stabilisce una<br />

connessione TCP/IP con i Client e simu<strong>la</strong> <strong>la</strong> sessione, impostata<br />

precedentemente, tra i due Client;<br />

• Term<strong>in</strong>ata <strong>la</strong> sessione, di durata anch’essa configurabile sul Server, i<br />

Client restituiscono al Server i dati ricavati sui s<strong>in</strong>goli pacchetti<br />

riguardanti i tempi di <strong>in</strong>terarrivo, le <strong>per</strong>dite ecc.<br />

• Il Server, ottenuti tutti i dati disponibili, calco<strong>la</strong> i parametri che<br />

caratterizzano le prestazioni di rete quali one-way de<strong>la</strong>y, jitter,<br />

throughput, <strong>per</strong>dite ecc.; i risultati vengono poi presentati all’o<strong>per</strong>atore<br />

sia graficamente sia <strong>in</strong> forma tabu<strong>la</strong>re.<br />

N.B. <strong>la</strong> sessione TCP/IP <strong>in</strong>iziata dal Chariot verso i client, dopo aver configurato<br />

il traffico viene usata esclusivamente <strong>per</strong> istaurare una connessione, ma non<br />

necessariamente tenuta durante <strong>la</strong> prova. Ad esempio, se si procede all’a<strong>per</strong>tura di<br />

una sessione Netmeet<strong>in</strong>g tra due client, <strong>la</strong> sessione com<strong>in</strong>cerà sul protocollo<br />

TCP/IP e una volta avviata i dati Netmeet<strong>in</strong>g verranno scambiati su RTP, i risultati<br />

ottenuti verranno poi ritrasmessi al Chariot con una nuova sessione TCP.<br />

114


__________________________________________________________________<br />

4.2.7 U.S.Robotics Wireless AP US5450<br />

Per una maggiore completezza <strong>del</strong>le prove è stato <strong>in</strong>trodotto un access po<strong>in</strong>t <strong>per</strong> lo<br />

studio <strong>del</strong> mantenimento <strong>del</strong><strong>la</strong> qualità <strong>del</strong> servizio anche su un supporto di tipo<br />

Wi-Fi <strong>in</strong> considerazione <strong>del</strong> crescente impiego di questo tipo di dispositivi. Le<br />

prove vere e proprie che implicano l’uso di questo apparecchio saranno quelle di<br />

tipo soggettivo che verranno spiegate <strong>in</strong> dettaglio nel prossimo capitolo, <strong>per</strong> ora ci<br />

si limita a fornire una breve descrizione <strong>del</strong>le caratteristiche di questo dispositivo.<br />

Si tratta di un dispositivo Wireless con doppia antenna e rate <strong>in</strong> trasmissione f<strong>in</strong>o<br />

a 54 Mbit/s. E’ stato configurato con sett<strong>in</strong>g mode di tipo access po<strong>in</strong>t, non è stata<br />

<strong>in</strong>trodotta nessuna chiave di crittografia WEP ed è stato utilizzato il canale 11 <strong>in</strong><br />

modo statico. Il rate è settato <strong>in</strong> modo da o<strong>per</strong>are d<strong>in</strong>amicamente.<br />

Figura 4.33: U.S. Robotica Wireless AP 5450<br />

115


__________________________________________________________________<br />

4.2.8 Anrtitsu MN9610B<br />

Il dispositivo Anritsu MN9610B è un attenuatore ottico con attenuazione<br />

rego<strong>la</strong>bile dall’o<strong>per</strong>atore. E’ stato impiegato <strong>per</strong> attenuare <strong>la</strong> potenza ottica<br />

generata dall’Anritsu MD1230A. Nel test-<strong>bed</strong> il <strong>per</strong>coso ottico Roma-Pomezia<br />

diventa un anello poiché viene chiuso tramite l’analizzatore generatore di traffico,<br />

<strong>la</strong> lunghezza <strong>del</strong>le fibre che uniscono l’MD1230A con le PIC <strong>ottiche</strong> <strong>del</strong> router è<br />

molto breve ed il segnale viene attenuato <strong>in</strong> maniera trascurabile, si genera così<br />

una situazione fortemente sconsigliata dai manuali <strong>del</strong> router. Per ovviare a questo<br />

problema sono state analizzate tre soluzioni differenti: <strong>la</strong> prima consiste nel porre<br />

un attenuatore ottico statico direttamente sull’attacco <strong>del</strong><strong>la</strong> fibra <strong>in</strong> trasmissione, <strong>la</strong><br />

seconda consiste nel collegare l’MD1230A ai router tramite l’impiego di rocchetti<br />

di fibra di 15 Km messi a disposizione dal<strong>la</strong> Fondazione Bordoni, <strong>la</strong> terza ed<br />

ultima quel<strong>la</strong> di impiegare <strong>in</strong> modalità passante gli attenuatori rego<strong>la</strong>bili Anritsu<br />

MN9610B. Per le prove oggettive di cui si parlerà tra breve è stata scelta <strong>la</strong> prima<br />

soluzione, <strong>la</strong> terza è stata adottata durante <strong>la</strong> conferenza NGI e verrà spiegata più<br />

avanti.<br />

4.3 PRINCIPIO DI FUNZIONAMENTO DEL SISTEMA<br />

Passiamo ora a descrivere nel partico<strong>la</strong>re il pr<strong>in</strong>cipio di funzionamento <strong>del</strong> sistema<br />

di protezione da me proposto.<br />

La topologia di rete su cui si è realizzato il <strong>la</strong>voro è di tipo l<strong>in</strong>eare punto-punto. Ai<br />

capi <strong>del</strong> collegamento vi sono due router Juni<strong>per</strong> M10 <strong>la</strong> cui configurazione<br />

completa sarà riportata <strong>in</strong> appendice. La struttura <strong>del</strong> sistema è mostrata <strong>in</strong> figura.<br />

116


__________________________________________________________________<br />

ROUTER 1 PXC LINEA DI SERVIZIO PXC<br />

ROUTER 2<br />

LINEA DI BACKUP<br />

CLIENT A<br />

LINUX BOX<br />

Traffico dati<br />

Collegamenti Fast Ethernet<br />

Collegamento ottico Gbe primario<br />

Collegamento ottico Gbe Secondario<br />

LINUX BOX<br />

CLIENT B<br />

Figura 0.11 : Topologia di rete utilizzata<br />

Ricordando quanto detto sulle diverse tecniche di protezione esam<strong>in</strong>ate nel terzo<br />

capitolo, è possibile rivedere <strong>in</strong> questo schema un c<strong>la</strong>ssico sistema di protezione<br />

1:1. Si tratta di fatto di un meccanismo hardware di ridondanza <strong>del</strong> collegamento<br />

<strong>in</strong> fibra ottica. In caso di <strong>in</strong>terruzione <strong>del</strong> l<strong>in</strong>k di servizio, il router <strong>in</strong>via un<br />

messaggio di al<strong>la</strong>rme ad un determ<strong>in</strong>ato <strong>in</strong>dirizzo, su una determ<strong>in</strong>ata porta.<br />

Gli <strong>in</strong>dirizzi a cui viene <strong>in</strong>viato il pacchetto di al<strong>la</strong>rme sono quelli corrispondenti<br />

ai PC di management opportunamente configurati. E’ di enorme importanza<br />

sottol<strong>in</strong>eare che tutto il traffico utile al<strong>la</strong> gestione <strong>del</strong> sistema si trova<br />

costantemente fuori banda. Ciò è stato reso possibile utilizzando <strong>la</strong> Fast Ethernet<br />

di management di cui sono forniti i Router Juni<strong>per</strong> M10, come ogni altro apparato<br />

di telecomunicazioni. E’ stato possibile così, separare il piano di controllo dal<br />

piano dati.<br />

117


__________________________________________________________________<br />

Figura 0.12 : Interfaccia di management<br />

Il protocollo utilizzato <strong>per</strong> <strong>la</strong> gestione <strong>del</strong>l’al<strong>la</strong>rme è il Simple Network<br />

Management Protocol (SNMP). La parte di configurazione re<strong>la</strong>tiva al<strong>la</strong> gestione<br />

<strong>del</strong>l’al<strong>la</strong>rme è di seguito riportata (l’<strong>in</strong>dirizzo 192.168.200.110 è appartente al<strong>la</strong><br />

sottorete di management).<br />

syslog {<br />

user * {<br />

any emergency;<br />

}<br />

host 192.168.200.110 {<br />

any notice;<br />

port 7574;<br />

}<br />

file messages {<br />

any notice;<br />

authorization <strong>in</strong>fo;<br />

}<br />

file cli {<br />

<strong>in</strong>teractive-commands any;<br />

}<br />

Figura 0.13 : Configurazione re<strong>la</strong>tiva all'<strong>in</strong>vio <strong>del</strong>l'al<strong>la</strong>rme<br />

Ogni apparato di telecomunicazioni è dotato di una serie di al<strong>la</strong>rmi gestibili da<br />

remoto. Dopo un attento studio, è stato possibile riconoscere un al<strong>la</strong>rme capace di<br />

118


__________________________________________________________________<br />

rilevare uno stato di ‘fuori servizio’ <strong>del</strong> l<strong>in</strong>k ottico roma-pomezia: LOL (loss of<br />

Light) - SNMP TRAP_LINK_DOWN.<br />

La gestione di questo al<strong>la</strong>rme è configurabile all’<strong>in</strong>terno <strong>del</strong> software JUNOS<br />

sotto il campo SYSLOG.<br />

Il messaggio di al<strong>la</strong>rme LOL viene <strong>in</strong>viato nel momento <strong>in</strong> cui viene <strong>per</strong>cepita una<br />

mancanza di potenza ottica sull’<strong>in</strong>terfaccia sotto test. Tale al<strong>la</strong>rme viene <strong>in</strong>viato<br />

nello stesso istante sia dal router <strong>in</strong> ricezione che dal router <strong>in</strong> trasmissione<br />

evitando così l’esigenza di implementare un protocollo di comunicazione tra RX e<br />

TX sul piano di controllo. Ciò è possibile <strong>in</strong> quanto, essendo i collegamenti <strong>in</strong><br />

fibra ottica bidirezionali su due fibre, entrambe le <strong>in</strong>terfacce dei router term<strong>in</strong>ali<br />

sono dotate di un apparato di ricezione che <strong>per</strong>cepisce <strong>la</strong> mancanza di potenza <strong>in</strong><br />

caso di guasto. Questo tipo di al<strong>la</strong>rme viene <strong>in</strong>viato <strong>in</strong> tempo reale al momento <strong>del</strong><br />

L<strong>in</strong>k failure.<br />

I test da me effettuati sono stati <strong>in</strong>teramente eseguiti simu<strong>la</strong>ndo <strong>la</strong> rottura su una<br />

<strong>del</strong>le due fibre <strong>ottiche</strong> che costituisce il collegamento tra i due router Juni<strong>per</strong>.<br />

Anche <strong>in</strong> questa situazione l’al<strong>la</strong>rme viene <strong>in</strong>viato da entrambi gli apparati<br />

term<strong>in</strong>ali, <strong>in</strong>fatti, nel momento <strong>in</strong> cui avviene un guasto su una <strong>del</strong>le due direzioni,<br />

l’<strong>in</strong>terfaccia <strong>in</strong> ricezione <strong>per</strong>cepisce il guasto ed istantaneamente passa nello stato<br />

di down, cessando di trasmettere potenza ottica sul<strong>la</strong> fibra di ritorno. In questo<br />

modo anche il router a monte <strong>del</strong> guasto non ricevendo più potenza ottica <strong>in</strong>via<br />

l’al<strong>la</strong>rme LOL rendendo possibile, anche <strong>in</strong> questo caso, <strong>la</strong> coord<strong>in</strong>azione <strong>del</strong><strong>la</strong><br />

fase di scambio senza l’attivazione di un protocollo esplicito di comunicazione tra<br />

i due PC di controllo.<br />

In Figura 0.1414 è mostrato ciò che viene <strong>per</strong>cepito dal<strong>la</strong> sottorete di<br />

management, <strong>in</strong> caso di l<strong>in</strong>k-failure. L’immag<strong>in</strong>e è stata ottenuta grazie<br />

all’utilizzo di un analizzatore di protocollo ( ETHEREAL ).<br />

119


__________________________________________________________________<br />

Figura 0.14 : Dettaglio re<strong>la</strong>tivo all'al<strong>la</strong>rme ‘Loss Of Light’<br />

Sulle due l<strong>in</strong>ux box, collegati ai router con collegamenti Fast Ethernet, è stato<br />

implementato un software <strong>in</strong> l<strong>in</strong>guaggio C, capace di eseguire le seguenti<br />

o<strong>per</strong>azioni:<br />

♦ Ricevere il messaggio proveniente dal router<br />

♦ analizzare il messaggio<br />

♦ Gestire <strong>la</strong> commutazione degli switch ottici nel caso <strong>in</strong> cui il messaggio<br />

ricevuto venga riconosciuto come al<strong>la</strong>rme.<br />

La commutazione degli switch ottici è <strong>per</strong>messa tramite <strong>la</strong> gestione diretta <strong>del</strong><strong>la</strong><br />

porta paralle<strong>la</strong> dei pc di management. Gli switch hanno il compito di deviare tutto<br />

il traffico dal<strong>la</strong> risorsa primaria verso <strong>la</strong> risorsa di back up elim<strong>in</strong>ando di fatto il<br />

fuori servizio. La spiegazione dettagliata <strong>del</strong> Software utilizzato verrà fornita nel<br />

seguito <strong>del</strong> capitolo. Le fasi appena descritte sono riportate cronologicamente <strong>in</strong><br />

Figura 0. nel<strong>la</strong> pag<strong>in</strong>a seguente.<br />

120


__________________________________________________________________<br />

Situazione di partenza<br />

LINEA DI SERVIZIO<br />

ROUTER 1 PXC PXC<br />

ROUTER 2<br />

LINEA DI BACKUP<br />

CLIENT A<br />

LINUX BOX<br />

Guasto <strong>del</strong><strong>la</strong> risorsa primaria<br />

LINUX BOX<br />

CLIENT B<br />

ROUTER 1<br />

PXC<br />

LINEA DI SERVIZIO<br />

PXC<br />

LINEA DI BACKUP<br />

CLIENT A<br />

LINUX BOX<br />

LINUX BOX<br />

CLIENT B<br />

Invio messaggio di al<strong>la</strong>rme<br />

LINEA DI SERVIZIO<br />

ROUTER 1 PXC PXC<br />

ROUTER 2<br />

SNMP<br />

LINEA DI BACKUP<br />

SNMP<br />

CLIENT A<br />

LINUX BOX<br />

Commutazione e riprist<strong>in</strong>o <strong>del</strong> servizio<br />

LINUX BOX<br />

CLIENT B<br />

ROUTER 1<br />

PXC<br />

LINEA DI SERVIZIO<br />

PXC<br />

LINEA DI BACKUP<br />

CLIENT A<br />

LINUX BOX<br />

LINUX BOX<br />

CLIENT B<br />

Figura 0.15 : Fasi cronologiche <strong>del</strong> sistema di protezione <strong>in</strong> caso di guasto <strong>del</strong> l<strong>in</strong>k di servizio<br />

121

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!