Realizzazione di un modello di router ottico in ambiente open source.

Università degli Studi di Bologna
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Reti di Telecomunicazioni LS

Realizzazione di un modello
di router ottico
in ambiente open source

Tesi di Laurea di: Relatore:
Raul Cafini Prof. Ing. Carla Raffaelli

Correlatori:
Dott. Ing. Walter Cerroni
Dott. Ing. Michele Savi

Sessione terza

Anno Accademico 2008/2009

Parole chiave:
Reti Ottiche
Multi-granular switching
Optical Packet Switching
Router programmabile
Click! Modular Router
Linux

D.E.I.S., Dipartimento di Elettronica, Informatica e Sistemistica.
Università di Bologna.
La tesi è scritta in L TEX 2ε , utilizzando come testo di riferimento [1].
A
La stampa è in PostScript.
Le immagini sono create in Adobe R Photoshop R Elements 2.0.
Adobe R Photoshop R Elements è un marchio registrato Adobe R Systems
Inc.

Ai compagni di viaggio,
tesoro più grande
di questa esperienza,
con la speranza di condividere insieme
nuove mete.

Aneddoto

Mi lamentavo con mia madre di quanto fosse dicile
e spaventoso quell'esame all'università.
Lei si inclinò verso di me, mi diede un buetto sulle spalle e mi disse:
Sappiamo bene come ti senti, tesoro, ma ricorda:
tuo padre alla tua età combatteva contro i tedeschi.
da The last lecture.
Randy Pausch1 .

1 Randy Pausch (Baltimore, 23 ottobre 1960 Chesapeake, 25 luglio 2008)

Indice

Indice vii

Elenco delle gure xi

Elenco delle tabelle xiii

Introduzione 1

1 Le reti ottiche 1
1.1 Le bre ottiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Composizione . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Principio di funzionamento . . . . . . . . . . . . . . . . . 3
1.2 Confronto con altri mezzi trasmissivi . . . . . . . . . . . . . . . 3
1.3 La comunicazione dei dati su bra ottica . . . . . . . . . . . . . 4
1.3.1 Finestre di trasmissione . . . . . . . . . . . . . . . . . . 6
1.3.2 Tecniche di multiplazione . . . . . . . . . . . . . . . . . 8
1.3.3 Wavelength Division Multiplexing (WDM) . . . . . . . . 8
1.4 Principi di commutazione ottica . . . . . . . . . . . . . . . . . . 11
1.4.1 Paradigmi di commutazione . . . . . . . . . . . . . . . . 12
1.5 Optical Packet Switching (OPS) . . . . . . . . . . . . . . . . . . 14
1.5.1 Packet Switching Scenario . . . . . . . . . . . . . . . . . 14
1.5.2 Optical Label Switching OLS . . . . . . . . . . . . . . . 15
1.5.3 Il pacchetto ottico . . . . . . . . . . . . . . . . . . . . . 16
1.5.4 Categorie di reti OPS . . . . . . . . . . . . . . . . . . . . 17
1.5.5 Content Resolution . . . . . . . . . . . . . . . . . . . . . 18
1.5.6 Riessioni sull'uso di OPS . . . . . . . . . . . . . . . . . 19

2 Architetture per router ottici 21
2.1 Generica architettura di un router ottico . . . . . . . . . . . . . 22
2.1.1 Input Interface . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Buer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

viii INDICE

2.1.4 Switching Matrix . . . . . . . . . . . . . . . . . . . . . . 24
2.1.5 Output Interfaces . . . . . . . . . . . . . . . . . . . . . . 24
2.2 La matrice di commutazione ottica . . . . . . . . . . . . . . . . 25
2.2.1 Erbium-Doped Fiber Ampliers (EDFA) . . . . . . . . . 25
2.2.2 WDM Demultiplexer . . . . . . . . . . . . . . . . . . . . 26
2.2.3 Fiber Delay Line (FDL) . . . . . . . . . . . . . . . . . . 26
2.2.4 Wavelength Converter (WC) . . . . . . . . . . . . . . . . 27
2.2.5 Splitter . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.6 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.7 WDM Multiplexer . . . . . . . . . . . . . . . . . . . . . 30
2.2.8 Combiner . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Shared Architectures . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 Shared-Per-Node (SPN) . . . . . . . . . . . . . . . . . . 31
2.3.2 Shared-Per-Link (SPL) . . . . . . . . . . . . . . . . . . . 31
2.3.3 Shared-Per-Wavelength (SPW) . . . . . . . . . . . . . . 31
2.4 L'architettura Broadcast-and-Select . . . . . . . . . . . . . . . . 33

3 Un modello software di router ottico 35
3.1 Architetture multi-granulari . . . . . . . . . . . . . . . . . . . . 35
3.2 L'architettura proposta . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 L'estensione per i paradigmi OCS e OBS . . . . . . . . . 39
3.3 Tecniche di valutazione di una architettura . . . . . . . . . . . . 39
3.3.1 La simulazione . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2 L'emulazione . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Il software di programmazione Click! . . . . . . . . . . . . . . 41
3.4.1 Introduzione al Click! . . . . . . . . . . . . . . . . . . . 41
3.4.2 Elementi, connessioni e pacchetti . . . . . . . . . . . . . 42
3.4.3 Il linguaggio e le congurazioni . . . . . . . . . . . . . . 43
3.5 Implementazione software della architettura . . . . . . . . . . . 45
3.5.1 Emulazione della architettura . . . . . . . . . . . . . . . 45
3.5.2 Analisi ed emulazione dei livelli di potenza . . . . . . . . 45
3.5.3 Implementazione basata sul software Click! . . . . . . . 46
3.6 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.1 OCS Signaling Channel . . . . . . . . . . . . . . . . . . . 48
3.6.2 OBS Control Channel . . . . . . . . . . . . . . . . . . . 48
3.6.3 Control Element (CE) . . . . . . . . . . . . . . . . . . . 48
3.6.4 Forwarding Element (FE) . . . . . . . . . . . . . . . . . 49
3.6.5 Forwarding Module (FM) OPS . . . . . . . . . . . . . . 51
3.7 Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.7.1 Optical Source . . . . . . . . . . . . . . . . . . . . . . . 53

INDICE ix

3.7.2 Input Fiber (IF) . . . . . . . . . . . . . . . . . . . . . . 54
3.7.3 HeaderTap (HT) . . . . . . . . . . . . . . . . . . . . . . 54
3.7.4 OEConverter . . . . . . . . . . . . . . . . . . . . . . . . 54
3.7.5 Switching Matrix (SM) . . . . . . . . . . . . . . . . . . . 54
3.7.6 EOConverter . . . . . . . . . . . . . . . . . . . . . . . . 58
3.7.7 NewHeader o NH . . . . . . . . . . . . . . . . . . . . . . 58
3.7.8 Output Fiber (OF) . . . . . . . . . . . . . . . . . . . . . 58
3.8 Comportamento del modello . . . . . . . . . . . . . . . . . . . . 58
3.8.1 Analisi dei punti di contesa . . . . . . . . . . . . . . . . 58
3.8.2 Analisi del traco attraverso il nodo . . . . . . . . . . . 58

4 Test e valutazioni sul modello 67
4.1 La piattaforma hardware di test . . . . . . . . . . . . . . . . . . 67
4.1.1 La distribuzione del traco . . . . . . . . . . . . . . . . 68
4.2 Le prestazioni misurate . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1 Packet Loss Probability (PLP) . . . . . . . . . . . . . . . 69
4.2.2 Tempo di processamento elettronico . . . . . . . . . . . . 69
4.3 Test e risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.1 Lo script di lancio dei test . . . . . . . . . . . . . . . . . 71
4.3.2 Test I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.3 Test IIa . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.4 Test IIb . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.5 Test III . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4 Confronto sui test di valutazione . . . . . . . . . . . . . . . . . . 82

Conclusioni 84
4.5 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.6 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.6.1 Riduzione delle tempistiche di emulazione . . . . . . . . 85
4.6.2 Implementazione della multi-granularità . . . . . . . . . 86
4.6.3 Implementazione di un modello reale del consumo di
potenza . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.7 Un pò di numeri . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A Appendice A: Il software Click! Modular Router 87
A.1 Introduzione a Click! . . . . . . . . . . . . . . . . . . . . . . . 87
A.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.2.1 Elementi . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.2.2 Connessioni . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.3 Pacchetti Click . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.4 Linguaggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

x INDICE

A.4.1 Sintassi . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

B Appendice B: Installazione in laboratorio 93
B.1 Installazione delle macchine . . . . . . . . . . . . . . . . . . . . 93
B.2 Installazione del sistema operativo . . . . . . . . . . . . . . . . . 94
B.2.1 Ottimizzazione . . . . . . . . . . . . . . . . . . . . . . . 94
B.2.2 Installazione delle dipendenze . . . . . . . . . . . . . . . 94
B.3 Installazione del software Click! . . . . . . . . . . . . . . . . . 95
B.3.1 Installazione di Clicky GUI . . . . . . . . . . . . . . . . 96

Ringraziamenti 99

Bibliograa 103

Elenco degli acronimi 107

Elenco delle gure

1.1 Un fascio di bre ottiche[2]. . . . . . . . . . . . . . . . . . . . . 2
1.2 Sezione di un cavo in Fibra Ottica: 1 - Core, 2 - Cladding, 3 -
Buer, 4 - Jacket [2]. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Tre esempi di un raggio di luce che dall'interno di una bra di si-
licio colpisce il conne aria/silicio con diversi angoli di incidenza,
no all'ottenimento della riessione totale. . . . . . . . . . . . . 3
1.4 Principio di funzionamento di una bra ottica multimodale [2] . 5
1.5 Dierenza tra bre ottiche multimodali (Step Index e Graded
Index) e monomodali (o Single Mode) [2] . . . . . . . . . . . . . 5
1.6 Relazione tra anni di produzione delle bre ottiche e relative
caratteristiche[21]. . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Finestre di trasmissione e lunghezze d'onda [2] . . . . . . . . . . 7
1.8 Lo spettro elettromagnetico, notare la posizione delle bre ottiche[2] 9
1.9 Tecnica di multiplazione WDM su bra ottica. . . . . . . . . . . 10
1.10 Esempio di scenario tipico della commutazione a pacchetti. . . . 14
1.11 Esempio di rete Optical Packet Switching (OPS) . . . . . . . . . 15
1.12 Modulazione della etichetta nel pacchetto ottico [18] . . . . . . . 16
1.13 Struttura del pacchetto ottico secondo proposta OPATM/KEOPS 17

2.1 Una generica architettura per router ottici . . . . . . . . . . . . 22
2.2 Simbolo graco di un amplicatore EDFA . . . . . . . . . . . . 26
2.3 Simbolo graco di un demultiplatore WDM . . . . . . . . . . . 26
2.4 Simbolo graco di una FDL . . . . . . . . . . . . . . . . . . . . 26
2.5 Simbolo graco di un convertitore WC . . . . . . . . . . . . . . 27
2.6 Simbolo graco di uno splitter . . . . . . . . . . . . . . . . . . . 28
2.7 Simbolo graco di un SOA . . . . . . . . . . . . . . . . . . . . . 29
2.8 Simbolo graco di un MEMS ad uso ottico . . . . . . . . . . . . 29
2.9 Simbolo graco di un multiplatore WDM . . . . . . . . . . . . . 30
2.10 Simbolo graco di un combiner . . . . . . . . . . . . . . . . . . 30
2.11 Architettura di riferimento SPW . . . . . . . . . . . . . . . . . . 32
2.12 Tipologie di architettura Broadcast-and-Select. . . . . . . . . . . 33

xii ELENCO DELLE FIGURE

3.1 La programmable node architecture basata sulla raccomandazione
ForCES come mostrata in [5] . . . . . . . . . . . . . . . . . . . . 36
3.2 Schema generale dell'architettura proposta . . . . . . . . . . . . 38
3.3 Logo del software Click Modular Router . . . . . . . . . . . . . 41
3.4 Schema rappresentativo di un pacchetto Click! . . . . . . . . . 43
3.5 Implementazione software della architettura proposta mediante
software Click! . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 Il piano di controllo dell'architettura in ambiente Click! . . . . 48
3.7 Elemento composto ControlElement . . . . . . . . . . . . . . . . 49
3.8 Elemento composto Click! ForwardingElement . . . . . . . . . . 50
3.9 Elemento composto Click! ForwardingModuleOPS . . . . . . . . 51
3.10 Il piano dati dell'architettura in ambiente Click! . . . . . . . . 52
3.11 Elemento Click! OpticalSource . . . . . . . . . . . . . . . . . . 53
3.12 Elemento Click! HeaderTap . . . . . . . . . . . . . . . . . . . . 54
3.13 Dettaglio della Switching Matrix . . . . . . . . . . . . . . . . . 55
3.14 WDM Demultiplexer . . . . . . . . . . . . . . . . . . . . . . . . 56
3.15 Fiber Delay Line . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.16 Tunable Wavelength Converter . . . . . . . . . . . . . . . . . . 56
3.17 WDM Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.18 Schema generale di funzionamento . . . . . . . . . . . . . . . . . 60
3.19 Prima fase del processamento dei pacchetti. . . . . . . . . . . . 61
3.20 Seconda fase del processamento dei pacchetti. . . . . . . . . . . 61
3.21 Terza fase del processamento dei pacchetti. . . . . . . . . . . . . 62
3.22 Quarta fase del processamento dei pacchetti. . . . . . . . . . . . 63
3.23 La matrice di commutazione in dettaglio . . . . . . . . . . . . . 65
3.24 Ultima fase del processamento dei pacchetti. . . . . . . . . . . . 66

4.1 Distribuzione bernoulliana con q = 0.8 . . . . . . . . . . . . . . 68
4.2 Confronto delle curve di simulazione ed emulazione per il TestI . 73
4.3 Confronto delle curve di simulazione ed emulazione per il TestIIa 77
4.4 Confronto delle curve di simulazione ed emulazione per il TestIIb 78
4.5 Confronto delle curve di simulazione ed emulazione dei TestIIa
eb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6 Confronto delle curve di simulazione ed emulazione per il TestIII 81
4.7 Confronto delle curve di simulazione ed emulazione per i test . . 82

A.1 Logo del software Click Modular Router . . . . . . . . . . . . . 88
A.2 Una rappresentazione del pacchetto Click! . . . . . . . . . . . . 91

B.1 Il logo della distribuzione Fedora . . . . . . . . . . . . . . . . . 94
B.2 L'interfaccia graca Clicky . . . . . . . . . . . . . . . . . . . . . 96

Elenco delle tabelle

4.1 Risultati Test I - Simulazione . . . . . . . . . . . . . . . . . . . 72
4.2 Risultati Test I - Emulazione . . . . . . . . . . . . . . . . . . . . 72
4.3 Risultati Test IIa - Simulazione . . . . . . . . . . . . . . . . . . 74
4.4 Risultati Test IIa - Emulazione . . . . . . . . . . . . . . . . . . 75
4.5 Risultati Test IIb - Simulazione . . . . . . . . . . . . . . . . . . 76
4.6 Risultati Test IIb - Emulazione . . . . . . . . . . . . . . . . . . 77
4.7 Risultati Test III - Simulazione . . . . . . . . . . . . . . . . . . 80
4.8 Risultati Test III - Emulazione . . . . . . . . . . . . . . . . . . . 81

B.1 Pacchetti e dipendenze Click! . . . . . . . . . . . . . . . . . . . 95

Introduzione

Internet non è al passo con i
tempi, ma con il futuro.

Anonimo.

Negli ultimi anni nel mondo della comunicazione, ed in particolare nel
settore informatico e della rete Internet, lo scenario globale su cui le moderne
tecnologie lavorano ogni giorno è in continua evoluzione.
Da un lato la necessità di trasferire una sempre maggiore quantità di in-
formazioni nel minor tempo possibile, dall'altro la crescita esponenziale degli
utenti unita alla proliferazione di servizi con richieste in termini di banda e ve-
locità sempre maggiori (ad esempio la fornitura di ussi dati audio e/o video)
ha posto il problema tra i gestori della rete, i centri di ricerca e le aziende del
settore su come adattare l'infrastrutura esistente ai nuovi requisiti.
In questo senso il trasporto del traco su tecnologia ottica ha ricoperto un
ruolo di primo piano, in quanto è proprio grazie a questa tecnologia se oggi
riusciamo a far fronte a questa enorme richiesta in termini di velocità, quantità
e qualità nella trasmissione delle informazioni sulla rete.
Anche se le dorsali intercontinentali per telecomunicazioni si basano ormai
da alcuni decenni su queste tecnologie, è solo a partire dalla scorsa decade,
con l'emergere di questi nuovi scenari, che si è cominciato a sfruttare a pieno
le potenzialità delle reti ottiche e a pensare a come trasportarle, grazie anche
alla diminuzione dei costi di realizzazione e di posa, in ambienti metropolitani
no a piccole realtà come enti o istituti.
Tutte le problematiche del trasporto delle informazioni nel dominio ot-
tico, il rispetto e la compatibilità verso i sistemi esistenti (ad esempio con
le reti ATM o quelle basate su protocollo IP), il processamento delle infor-
mazioni di instradamento ed inoltro, i colli di bottiglia e i limiti tecnologici
nella realizzazione di alcuni componenti, altrimenti elementari nel dominio
elettromagnetico, rappresentano un campo molto attivo della ricerca in questo
settore.

2 Introduzione

Nel seguito introdurremo ed analizzeremo queste problematiche nei loro
aspetti di rilievo, forniremo dei cenni sulla struttura e sul funzionamento base
dei punti di accesso e smistamento delle informazioni, i router, che permet-
tono l'interconnessione di tali reti, e di alcune soluzioni che implementano le
tecnologie proposte.
Una volta fornite queste nozioni, introdurremo una architettura per router
ottici di tipo modulare, sviluppata presso il dipartimento da parte dei corre-
latori di questo testo, la cui principale caratteristica consiste nell'essere alta-
mente ricongurabile, in modo da adattarsi a requisiti, anche futuri, come la
multi-granularità nella gestione del traco.
Il lavoro di tesi consisterà dunque nella implementazione software di questa
soluzione architetturale mediante l'uso di strumenti di programmazione mod-
ulari e altamente congurabili. Dato inoltre l'alto costo dei dispositivi base
per la manipolazione delle informazioni su bra (dai laser no ai convertitori
di lunghezza d'onda) il ne ultimo sarà quello di dimostrare la fattibilità della
realizzazione di un vero e proprio banco di prova per architetture ottiche, in
grado di eseguire, con contenute limitazioni, su un comune hardware elettron-
ico e che sia in grado di valutare le prestazioni e i beneci dei sistemi che
operano nel dominio della luce, cercando di riprodurre il più fedelmente pos-
sibile il comportamento di una matrice di commutazione ottica, contenendo
però i costi che derivano dall'uso di veri dispositivi.

Capitolo 1

Le reti ottiche

Le stelle sono piccole fessure
attraverso le quali fuoriesce la
luce dell'innito.

Confucio, losofo cinese.
(551 a.C. - 479 a.C.)

In questo capitolo introdurremo la tecnologia alla base delle comunicazioni
nel dominio ottico, analizzandone il principio di funzionamento, la compo-
sizione, le tecniche di trasmissione dei dati e le ultime soluzioni l'incremento
delle prestazioni e la riduzione dei costi.

1.1 Le bre ottiche
Le bre ottiche sono lamenti di materiali vetrosi o polimerici, normalmente
disponibili sotto forma di cavi, realizzati in modo da poter condurre la luce.
Sono classicate quindi come guide d'onda dielettriche, permettono cioè di
convogliare al loro interno un campo elettromagnetico di frequenza suciente-
mente alta (in genere in prossimità dell'infrarosso) con perdite estremamente
limitate. Sono essibili, immuni ai disturbi elettrici ed alle condizioni atmos-
feriche più estreme, e poco sensibili a variazioni di temperatura e per questi
aspetti vengono comunemente impiegate nelle telecomunicazioni anche su gran-
di distanze e nella fornitura di accessi di rete a larga banda (dai 10 Mbit/s al
Tbit/s usando le più ranate tecnologie di multiplazione)[2].

1.1.1 Composizione
Ogni singola bra ottica è composta da due strati concentrici di materiale
trasparente estremamente puro: un nucleo cilindrico centrale, detto core, ed

2 Le reti ottiche

Figura 1.1: Un fascio di bre ottiche[2].

un mantello o cladding attorno ad esso. La bra ottica funziona come una
specie di specchio tubolare, la luce che entra nel core ad un certo angolo (detto
angolo limite) si propaga mediante una serie di riessioni sulla supercie di
separazione fra i due materiali[2].

Figura 1.2: Sezione di un cavo in Fibra Ottica: 1 - Core, 2 - Cladding, 3 -
Buer, 4 - Jacket [2].

Nel silicio destinato alla produzione del core viene aggiunto del germanio
in modo da aumentarne l'indice di rifrazione senza variarne l'attenuazione. Il
cladding invece ha un indice di rifrazione inferiore (ottenuto mediante drogag-
gio al boro). Intorno a questi due strati vi è un mantello detto buer con
uno spessore maggiore della lunghezza di smorzamento dell'onda evanescente,
caratteristica della luce trasmessa, in modo da catturare la luce che non viene
riessa nel core. Inne un guaina protettiva polimerica detta jacket ricopre il
tutto per dare resistenza agli stress sici e alla corrosione ed evitare il contatto
fra la bra e l'ambiente esterno. Le bre ottiche possono essere realizzate in
bra di vetro (che però dà luogo a fragilità e dicoltà nel caso di raccordi) o
in polimeri (se costituita da una materia plastica, in tal caso risulta molto più
facile da maneggiare e più resistente allo stress meccanico). Due tratti di bra

1.2. Confronto con altri mezzi trasmissivi 3

ottica dello stesso tipo possono essere giuntati mediante semplice fusione, che
se ben eseguita mediante strumenti di precisione comporta una attenuazione
inferiore a 0,05 dB[2].

1.1.2 Principio di funzionamento
Una descrizione approfondita e scientica del funzionamento delle bre ot-
tiche richiederebbe nozioni di ottica quantistica ma semplicando e usando
un paragone di ottica classica, nelle bre ottiche avviene un fenomeno di ri-
essione totale interna, per cui la discontinuità dell'indice di rifrazione tra i
materiali del nucleo e del mantello intrappola la radiazione luminosa nché
questa mantiene un angolo abbastanza radente, in pratica nché la bra non
compie curve troppo brusche. Infatti quando un raggio luminoso passa da un
materiale (ad esempio il silicio fuso) ad un altro (ad esempio l'aria) questo si
rifrange (ovvero si curva) sul conne tra i due materiali[2].

Figura 1.3: Tre esempi di un raggio di luce che dall'interno di una bra
di silicio colpisce il conne aria/silicio con diversi angoli di incidenza, no
all'ottenimento della riessione totale.

In gura sono mostrati tre esempi di un raggio di luce che dall'interno di
una bra colpisce il conne aria/silicio con diversi angoli di incidenza. L'en-
tità della rifrazione (curvatura) dipende dalle proprietà dei due materiali ed
in particolare dal loro indice di rifrazione. Per angoli di incidenza che super-
ano un certo valore critico la luce rimane intrappolata nel silicio senza fug-
gire nell'aria, ottenendo la così detta riessione totale. Un segnale luminoso
può così propagarsi per chilometri all'interno della bra senza subire perdite
signicative[2].

1.2 Confronto con altri mezzi trasmissivi
Come già accennato esistono parecchi vantaggi che privilegiano l'uso delle -
bre rispetto ai cavi in rame nelle telecomunicazioni. In particolare l'uso della
tecnologia ottica garantisce una bassa attenuazione, il che rende possibile la

4 Le reti ottiche

trasmissione su lunga distanza senza ripetitori. Inoltre questa mette a dispo-
sizione una banda molto ampia in grado di garantire una grande capacità di
trasporto oltre ad avere una pressochè totale immunità da interferenze elet-
tromagnetiche, inclusi gli impulsi elettromagnetici nucleari (ma possono essere
danneggiate da radiazioni alfa e beta). L'alta resistenza elettrica rende pos-
sibile usare le bre vicino ad equipaggiamenti ad alto potenziale, o tra siti
a potenziale diverso anche grazie al peso e ingombro modesto. Un cavo di
bra ottica, in quanto contiene più bre ottiche, è infatti solitamente molto
più piccolo e leggero di un lo o cavo coassiale con simili capacità di canale.
È più facile da maneggiare e da installare ed è ideale per le comunicazioni
sicure in quanto è molto dicile da intercettare e altrettanto facile da mon-
itorare. Idealmente, le bre ottiche sono un mezzo di trasmissione perfetto,
infatti oltre a non risentire in nessun modo di disturbi elettromagnetici o di
diafonia, se strutturate adeguatamente per garantire la riessione totale del
segnale d'ingresso, permettono teoricamente di trasferire completamente la
potenza in ingresso nell'uscita e lavorando con fenomeni sici ad elevatissima
frequenza (le onde luminose) sarebbero possibili velocità di trasmissione molto
elevate. In pratica, però, intervengono dei fattori sici che limitano la banda
di trasmissione possibile e causano delle perdite di potenza lungo la bra[2].

1.3 La comunicazione dei dati su bra ottica
Un sistema di comunicazione ottico è formato da tre componenti fondamentali:
una sorgente luminosa (un Light Emitting Diode LED o un laser a semicon-
duttore), un mezzo di trasmissione (la bra ottica) e un rilevatore (ad esempio
un fotodiodo). Per convenzione si è stabilito che un impulso di luce corrispon-
da al valore 1, mentre l'assenza di luce indichi il valore 0. La sorgente di
luce accetta in ingresso un qualsiasi segnale elettrico (binario), lo converte in
una serie di impulsi luminosi che si propagano attraverso il mezzo trasmissi-
vo. Grazie alla sue proprietà di riessione totale, l'informazione sotto forma
di luce viaggia senza dispersione all'interno della bra. All'altra estremità del
mezzo trasmissivo vi è un rilevatore che, quando è colpito dalla luce, gen-
era un impulso elettrico riconvertendo così l'informazione dal dominio ottico
a quello elettromagnetico. Nella gura precedente era rappresentato un so-
lo raggio intrappolato nel mezzo di trasmissione, ma poichè tutti i raggi di
luce che colpiscono l'interfaccia con un angolo maggiore di quello critico (per
la riessione totale) ee entro un cono di accettazione (per l'ingresso nella -
bra) sono tutti riessi internamente, una bra può contenere molti raggi che
rimbalzano ad angoli diversi. In questo caso si dice che ogni raggio ha una

1.3. La comunicazione dei dati su bra ottica 5

modalità diversa.

Figura 1.4: Principio di funzionamento di una bra ottica multimodale [2]

All'interno di una bra ottica quindi il segnale può propagarsi in modo
rettilineo oppure essere riesso un numero molto elevato di volte. Distinguiamo
quindi due tipologie base di bre:

• Fibre ottiche monomodali: se il diametro della bra è ridotto a poche
lunghezze d'onda al loro interno viaggia un solo raggio luminoso e la bra
si comporta come una guida d'onda ovvero la luce può propagarsi solo
in linea retta detta anche modo di ordine zero.

• Fibre ottiche multimodali: al loro interno viaggiano più raggi lumi-
nosi a dierenti angoli di incidenza, quindi consentono la propagazione
di più modi (da qui il loro nome).

Figura 1.5: Dierenza tra bre ottiche multimodali (Step Index e Graded
Index) e monomodali (o Single Mode) [2]

Le bre multimodali permettono l'uso di dispositivi più economici, ma
subiscono il fenomeno della dispersione intermodale, per cui i diversi modi si
propagano a velocità leggermente diverse, e questo limita la distanza massima a

6 Le reti ottiche

cui il segnale può essere ricevuto correttamente. Le bre monomodali di contro
hanno un prezzo molto più elevato rispetto alle multimodali, ma riescono a
coprire distanze e a raggiungere velocità nettamente superiori[2].

1.3.1 Finestre di trasmissione
Nelle comunicazioni ottiche, lo spettro trasmissivo è descritto in termini di
lunghezza d'onda (wavelength ) invece che di frequenza. Combinando i diversi
fenomeni di attenuazione, rifrazione, dispersione, vi sono delle nestre partico-
larmente adatte all'uso della trasmissione delle informazioni, con prestazioni e
costi crescenti. Nel corso degli anni infatti, grazie al ranamento del processo
produttivo si è arrivati alla costruzione di bre ottiche in grado di garantire
buone prestazioni in termini di attenuazione e ampiezza trasmissiva. Nelle bre
prodotte negli anni '70, come visibile in gura, si avevano caratteristiche poco
performanti che lasciavano spazio alla denizione di una sola nestra trasmis-
siva. Già negli anni '80 si è raggiunto un notevole miglioramento perfezionato
nel decennio successivo con l'introduzione di ben tre nestre di trasmissione[2].

Figura 1.6: Relazione tra anni di produzione delle bre ottiche e relative
caratteristiche[21].

L'attenuazione della luce nella bra è espressa solitamente in dB per chi-
lometro lineare e si ricava dalla formula:


energia_trasmessa
attenuazione = 10log10
energia_ricevuta

Come accennato nelle moderne bre ottiche sono disponibili dalle 3 alle 4
nestre di trasmissione poste dove le caratteristiche della bra con una luce ad
una determinata lunghezza d'onda garantiscono la minima attenuazione per
chilometro possibile[2].

Figura 1.7: Finestre di trasmissione e lunghezze d'onda [2]

Queste nestre, come è possibile vedere nella gura, sono[2]:
• Prima Finestra (rossa): 850 nm (nel campo del visibile), usata so-
prattutto con economici laser a diodo con luce multimodale. Permette
di realizzare collegamenti di 275 m su bre 62.5/125 e di 550 m su bre
50/125.

• Seconda Finestra (verde): 1310 nm, usata con laser multimodali o
monomodali. Permette di realizzare collegamenti di 5 o 10 km su bre
monomodali.

• Terza nestra (blu): 1550 nm, usata con laser monomodali. Ques-
ta nestra permette di realizzare le distanze maggiori, compresi col-
legamenti di 100 km con apparati relativamente economici. Sfruttando
questa lunghezza d'onda, una buona bra monomodale raggiunge una
attenuazione dell'ordine degli 0,2-0,25 dB/km.
Tutte e tre le nestre o bande hanno ampiezze comprese tra i 25.000 e i
30.000 GHz, la seconda e la terza nestra hanno buone proprietà di attenu-
azione (meno del 5% di dispersione per chilometro) mentre la prima nestra ha

8 Le reti ottiche

una attenuazione più alta ma, a questa lunghezza d'onda, è possibile costruire
i laser e l'elettronica di supporto con l'uso dello stesso materiale per il dro-
gaggio (arseniuro di gallio) risparmiando sui costi e semplicando il processo
produttivo[2].

1.3.2 Tecniche di multiplazione
Nelle telecomunicazioni la multiplazione (in inglese multiplexing ) è un mecca-
nismo per cui la capacità disponibile di un collegamento viene condivisa tra
diversi canali trasmissivi. Questo avviene combinando più segnali analogici o
ussi di dati digitali in un solo segnale trasmesso su un singolo collegamento
sico, al ne di risparmiare nella comunicazione dei dati, e in particolare, di
ridurre il numero di linee di segnale e il numero di componenti. La capacità
del collegamento può essere suddivisa con diversi meccanismi[2]:

• a divisione di tempo o Time Division Multiplexing (TDM)

• a divisione di frequenza o Frequency Division Multiplexing (FDM)

• a divisione di lunghezza d'onda (o Wavelength Division Multiplexing
(WDM) nelle comunicazioni ottiche)

La multiplazione a divisione di tempo ci permette di frazionare sull'asse dei
tempi l'uso del canale in modo da assegnare ad ogni risorsa un quanto di tempo
su cui può trasmettere, mentre la multiplazione a divisione di frequenza e di
lunghezza d'onda, che è una forma particolare di multiplazione a divisione di
frequenza in cui ogni canale trasmissivo viene inviato su una diversa lunghezza
d'onda, e i canali possono essere combinati e separati restando nel dominio
ottico, ovvero senza riconvertirli in segnali digitali[2].

1.3.3 Wavelength Division Multiplexing (WDM)
Questo tipo di multiplazione è utilizzato propriamente nei sistemi di comuni-
cazione ottica. E' una variazione della multiplazione a divisione di frequenza
dalla quale dierisce sia perchè viene attuata a frequenze molto più alte (ovvero
quelle proprie dei fasci di luce usati nelle bre ottiche) sia perchè per la sud-
divisione ci si ada ad un sistema (ottico) completamente passivo (e quindi
molto adabile) basato su un reticolo di dirazione[2][7]. Supponiamo di voler
trasmettere 4 segnali ottici che trasportano ognuno energia ad una dierente
lunghezza d'onda su un unica bra. Questi segnali, mediante l'azione di un
combinatore ottico (che applica la multiplazione WDM), vengono uniti in un


Figura 1.8: Lo spettro elettromagnetico, notare la posizione delle bre
ottiche[2]

unico spettro in modo da viaggiare su di un unica bra ottica, verso una des-
tinzione lontana anche migliaia di chilometri. Al suo arrivo la bra è suddivisa
in tante copie quante sono i segnali mediante uno splitter, poi viene ltrata
da un ltro che permette solo ad una determinata banda di passare ottenendo
così i segnali originali. Per modulare diversi canali su una stessa bra ottica
si usano diverse portanti di dierenti lunghezze d'onda, una per ogni canale,
e per la singola portante si usa la modulazione di intensità. In questo modo
è possibile sfruttare la grande banda ottica disponibile. In gergo, le lunghezze
d'onda vengono anche chiamate colori e la trasmissione WDM viene detta col-
orata, anche se in realtà le lunghezze d'onda usate non sono nel campo del
visibile. Un sistema WDM usa un multiplexer in trasmissione per inviare più
segnali insieme, e un demultiplexer in ricezione per separarli. I dispositivi di
ltraggio ottico usati nei modulatori-demodulatori sono di solito degli interfer-
ometri di Fabry-Perot a stato solido e singola frequenza, nella forma di vetro
ottico ricoperto da lm sottile. I sistemi moderni possono gestire no a 160
segnali e possono quindi moltiplicare la banda di una bra a 10 Gbit/s no a
un limite teorico di oltre 1.6 Tbit/s su una singola coppia di bre.
I sistemi WDM sono apprezzati dalle società telefoniche perché consentono
di aumentare la banda disponibile in una rete senza dover stendere altra bra
ottica. Usando il WDM e gli amplicatori ottici, è possibile aggiornare pro-
gressivamente la tecnologia degli apparati di rete senza essere costretti a rifare
totalmente la rete backbone. La capacità di banda di un certo collegamento
può essere aumentata semplicemente aggiornando i multiplatori e demultipla-
tori a ciascun capo del collegamento. Essendo le reti ottiche basate su WDM
in contatto ai loro estremi con reti normali basate su segnali elettromagneti-

10 Le reti ottiche

Figura 1.9: Tecnica di multiplazione WDM su bra ottica.

ci, si renderà necessario ad un tal punto convertire il contenuto informativo
nel dominio lettromagnetico. Questo è spesso realizzato compiendo una se-
rie di conversioni Optical-Electrical-Optical (OEO) alle estremità della rete
di trasporto, permettendo così l'interoperabilità con gli esistenti apparati con
interfacce ottiche. L'energia su una singola bra WDM è generalmente ampia
pochi GHz in quanto non è ancor oggi possibile eettuare una conversione
OEO in tempi più rapidi.
I sistemi WDM si possono suddividere, in base alla separazione tra le
diverse lunghezze d'onda usate, in:
• Conventional WDM o semplicemente WDM: forniscono no a
16 canali nella terza nestra di trasmissione (la banda C) delle bre in
silicio, intorno alla lunghezza d'onda di 1550 nm, con una separazione
tra i canali di 100 Ghz.

• Dense WDM o DWDM: usa la stessa nestra di trasmissione ma con
minore separazione tra i canali, arrivando a 31 canali a intervalli di 50
GHz; sistemi a 62 canali e intervalli di 25 GHz sono a volte chiamati
ultra densi. Nuove possibilità di amplicazione (amplicazione Raman)
consentono l'utilizzo anche delle lunghezze d'onda nella banda L, tra i
1570 nm e i 1610 nm, circa raddoppiando il numero di canali.

• Coarse WDM o CWDM: letteralmente a `grana grossa', la sepa-
razione tra le lunghezze d'onda usate è maggiore che nel convenzionale e

1.4. Principi di commutazione ottica 11

nel DWDM, in modo da poter utilizzare componenti ottici meno sosti-
cati e quindi meno costosi. Per continuare a fornire 16 canali su una
sola bra, il CWDM usa interamente la banda di frequenze compresa tra
la seconda e la terza nestra di trasmissione (1310/1550 nm rispettiva-
mente) in cui, oltre alle due nestre (la nestra a minima dispersione e
quella a minima attenuazione) è compresa anche l'area critica dove può
aversi lo scattering (dispersione).

La tecnica WDM è semplice e il suo principio è noto da tempo, ma ha avuto
applicazione pratica solo in tempi recenti. Il problema principale era la man-
canza di amplicatori adatti. Da quando sono in uso le bre ottiche, l'unico
modo per superare lunghe distanze era la rigenerazione del segnale attraverso
i rigeneratori optoelettronici. In un rigeneratore optoelettronico gli impulsi
indeboliti vengono trasformati da un rivelatore fotoelettrico e, debitamente
amplicati, modulano un trasmettitore laser. Il problema è che il rivelatore
fotoelettrico non distingue una lunghezza d'onda da un'altra. La nuova in-
venzione che ha permesso il superamento di questa dicoltà è la tecnica che
permette l'amplicazione della quantità di luce del segnale, senza bisogno di
trasformarlo in segnale elettrico. Questi congegni, detti Erbium-Doped Fiber
Ampliers (EDFA) o amplicatori a bra drogata con erbio, vennero svilup-
pati verso la ne degli anni '80 ed hanno reso possibile la rivoluzione basata
su questa tecnica. La multiplazione su lunghezza d'onda è emersa al momento
giusto, quando i vecchi cavi in bra cominciavano ad essere saturi. L'esigenza
di risparmiare tempo e denaro ha causato una rapida diusione della tecnica
WDM nell'industria delle telecomunicazioni. Ha evitato la spesa connessa con
la posa di nuovi cavi semplicemente pompando altre lunghezze d'onda nelle
bre esistenti. Alla metà degli anni '90, le aziende hanno iniziato ad usare
sistemi che trasmettono su 4 lunghezze d'onda e poco dopo sono salite ad 8 e
poi a 16 (1996). Nel 1997 si è saliti a 32 e 40 bande, larghe appena 0.8 nm
ciascuna. Nel 1998 si è giunti ad 80 canali. Visto che la domanda di larghezza
di banda non sembra voler rallentare, si sta pensando al modo di stipare un
numero maggiore di lunghezze d'onda in ogni bra impiegando ad esempio tre
amplicatori all'erbio ottimizzati per bande separate fra 1525 e 1605 nm[2][7].

1.4 Principi di commutazione ottica
Come accennato nell'introduzione, i requisiti futuri nelle speciche di costruzio-
ne delle reti di telecomunicazioni sono molteplici e dierenti, ma molti conver-
gono con la richiesta di una capacità maggiore in termini di banda, essibilità,
robustezza, riduzione dei costi e di fornitura di energia, come di equipaggia-

12 Le reti ottiche

mento e manutenzione. Tutto questo ha orientato il mondo delle telecomu-
nicazioni verso la comunicazione basata su backbone a bre ottiche, dato che
questo mezzo trasmissivo raccoglieva ampiamente la maggior parte di questi
requisiti. Scelta la tecnologia di base occorre stabilire come le informazioni per-
meranno la rete e come risolvere il percorso dal mittente al destinatario. La
commutazione nelle telecomunicazioni riguarda i concetti generali sui quali è
basato il funzionamento logico dei nodi di rete, ovvero è un'operazione all'inter-
no di un nodo che tratta l'informazione da trasmettere, anché sia indirizzata
verso la destinazione desiderata. Una commutazione è attuata per mezzo delle
funzioni d'instradamento o routing (decisionale) e di attraversamento o for-
warding (attuativa). Il framework su cui si basano oggi le trasmissioni dati su
bra ottica prevedono una comunicazione punto-a-punto e funzioni di inoltro
di tipo packet switching a controllo (ancora) elettronico, questo per una serie di
problematiche legate alla dicoltà di implementare algoritmi di routing rima-
nendo nel dominio ottico. Infatti al giorno d'oggi nella tecnologia ottica sono
principalmente due gli ostacoli sui quali la ricerca sta concentrando i propri
sforzi:

• Non è possibile avere delle memorie sulle linee ottiche.

• La commutazione ottica è dispendiosa e complessa.

Vedremo di seguito come risolvere questi problemi e realizzare una struttura
per l'uso della bra ottica nelle comunicazioni a pacchetto.

1.4.1 Paradigmi di commutazione
Come abbiamo accennato la commutazione è una potenzialità di una rete di
costruire, mantenere e abbattere un collegamento tra i nodi che la compongono.
Esistono due grandi famiglie che si dierenziano per le modalità in cui la
commutazione avviene:

• Commutazione di circuito o multiplazione deterministica

• Commutazione di pacchetto o multiplazione statistica

Mentre in una rete a commutazione di circuito la capacità del canale
trasmissivo è interamente dedicata ad una specica comunicazione, la com-
mutazione di pacchetto si rivela molto più eciente nonostante la maggior
quantità di dati inviata, in quanto i canali sici sono utilizzati solo per il tem-
po strettamente necessario. Inoltre, poiché ogni pacchetto porta con sé la sua
identicazione, una rete può trasportare nello stesso tempo pacchetti prove-
nienti da sorgenti dierenti. La commutazione di pacchetto permette quindi

1.4. Principi di commutazione ottica 13

a più utenti di inviare informazioni attraverso la rete in modo eciente e si-
multaneo, risparmiando tempo e costi mediante la condivisione di uno stesso
canale trasmissivo (cavo elettrico, etere, bra ottica, . . . ). Storicamente la
commutazione di pacchetto poneva qualche problema nel caso fosse necessaria
una disponibilità garantita di banda o nelle trasmissioni real time : si pensi a
una trasmissione video, dove le immagini arrivano con un usso costante. Al
giorno d'oggi è però possibile aggiungere una priorità ai pacchetti per garantire
che un numero suciente di essi venga inviato, a scapito di altri pacchetti che
non abbiano un'urgenza specica, ad esempio, un le da trasferire[9].
In base a queste due grandi famiglie si sono deniti tre diversi paradigmi
di commutazione ottica

• Optical Circuit Switching (OCS)

• Optical Packet Switching (OPS)

• Optical Burst Switching (OBS)

Optical Circuit Switching (OCS)
Fa propria la commutazione di circuito in ambito ottico cercando di costruire
dei percorsi tra il mittente ed il ricevente mediante delle procedure, che viag-
giano su un canale di segnalazione fuori banda per la mediazione, la creazione
e l'abbattimento della connessione.

Optical Packet Switching (OPS)
Trasposizione della commutazione di pacchetto in ambito ottico, in cui vi-
aggiano pacchetti e informazioni di instradamento sulla stessa banda (non
esistono canali di segnalazione o controllo.

Optical Burst Switching (OBS)
Questo tipo di commutazione si trova tra la commutazione di circuito otti-
co e la commutazione di pacchetto ottico. Opera a livello di sub-lunghezza
d'onda, il traco in ingresso dai client ai margini della rete viene aggregato
alla penetrazione della rete in base a un parametro particolare, comunemente
per destinazione, tipo di servizio (TOS byte) la classe di servizio e qualità del
servizio (ad esempio, secondo Diserv). Pertanto, al router edge OBS, code
diverse rappresentano le varie destinazioni o la classe di servizi.

14 Le reti ottiche

Figura 1.10: Esempio di scenario tipico della commutazione a pacchetti.

1.5 Optical Packet Switching (OPS)
Vedremo ora in dettaglio il paradigma OPS analizzando in primis uno scenario
tipico di utilizzo, mostrandone i punti di forza che ne hanno favorito lo sviluppo
e la diusione.

1.5.1 Packet Switching Scenario
Supponiamo di voler trasmettere un le da un host ad un altro attraverso una
rete (ad esempio dall'host A all'host D). Il le viene suddiviso in pacchetti
(segmenti blu) e vengono inseriti degli header ad ognuno di essi (segmenti
rossi) contenenti le informazioni sull'host destinazione da raggiungere. I pac-
chetti viaggiano nella rete e in ogni nodo intermediario che incontrano vi è una
tabella di inoltro (forwarding table ) che contiene l'informazione riguardante il
percorso che ogni pacchetto deve seguire per una determinata destinazione.
Come abbiamo evidenziato, ricorriamo al packet switching perchè ci perme-
tte una allocazione dinamica della banda (i collegamenti saranno occupati solo
quando necessario ed esistono delle alternative routes quando si vericano con-
gestioni) inoltre i pacchetti da dierenti sorgenti possono coesistere sulla stessa
rete permette di far lavorare terminali a dierenti bit rates [18].
Nelle reti MAN quindi generalmente i link tra i nodi sono realizzati me-
diante l'uso di bre ottiche e i pacchetti che viaggiano al suo interno sono
dei pacchetti ottici. Per utilizzare la commutazione di pacchetto è dunque

1.5. Optical Packet Switching (OPS) 15

Figura 1.11: Esempio di rete Optical Packet Switching (OPS)

necessaria una conversione di tipo Optical-Electrical-Optical (OEO) alle inter-
facce per operare lo switching dei pacchetti. Questa operazione di conversione
dal segnale ottico a quello elettronico genera un elevato overhead in quanto è
una operazione lenta per le tempistiche della rete ottica (quindi per essa pe-
nalizzante) limitata nel numero di pacchetti processabili contemporaneamnete
costosa e complessa oltre ad introdurre un difetto proprio delle comunicazioni
elettriche come la diafonia (cross-talk) ovvero il rumore o interferenza elettro-
magnetica che si può generare tra due cavi vicini di un circuito o apparato elet-
tronico. Queste limitazioni nella conversione OEO degradano le performance
della bra diminuendone la banda trasmissiva[18].
La soluzione è individuata nella tecnica dell Optical label Switching (OLS)
che permette di instradare i pacchetti ottici all'interno della rete di bra rima-
nendo nel dominio ottico senza convertire il segnale nel campo elettromagneti-
co. Si posiziona un etichetta (label ) sulla frequenza portante del pacchetto, così
facendo le informazioni di instradamento possono essere estratte convertendo
il solo header e lasciando così il payload intatto nel dominio ottico[18].

1.5.2 Optical Label Switching OLS
Questa tecnica viene utilizzata per costruire su una rete a pacchetto diverse
reti virtuali indipendenti e reciprocamente impermeabili. A ciascun pacchetto

16 Le reti ottiche

viene aggiunta una etichetta che lo identica come appartenente ad una parti-
colare rete virtuale, e potrà essere consegnato solo se il destinatario appartiene
alla stessa rete virtuale. Tra gli esempi, le VLAN su Ethernet (802.11q) e Multi
Protocol Label Switching (MPLS), che è un meccanismo che crea reti private
virtuali su tecnologie eterogenee, tipicamente utilizzato dai provider[18].

Figura 1.12: Modulazione della etichetta nel pacchetto ottico [18]

Funzionamento
Nell'OLS si posiziona dunque una label (con le informazioni di switching per i
nodi ottici) ad una sottofrequenza della portante come mostrato in 1.12. Così
facendo le informazioni possono essere estratte convertendo (elettronicamente)
il solo header lasciando il payload nel dominio ottico.

1.5.3 Il pacchetto ottico
Quando trasmettiamo i pacchetti nel dominio ottico, dobbiamo denire anche
quale forma hanno i dati inviati. Una proposta che tende a modellare una
versione ottica della cella ATM prevede che il pacchetto sia composto da quat-
tro componenti fondamentali, un header con le informazioni di label switching
per l'instradamento ottico, il payload e due bande di guardia (guard bands ) che
facilitano nella individuazione delle due sezioni durante l'analisi del segnale[18]
come mostrato in 1.13.
Come si evince in gura, le due sezioni importanti sono l'header e il pay-
load. Mentre quest'ultimo rappresenta un incapsulamento delle informazioni
che viaggiano ad un livello superiore a quello di trasporto su bra ottica,
tutte le informazioni che riguardano l'instradamento dei pacchetti in OPS sono
contenute nell'header, che è composto da diversi campi[19]:

• Sync: Contiene dei bit di sincronizzazione.


Figura 1.13: Struttura del pacchetto ottico secondo proposta OPATM/KEOPS

• Source Label: Etichetta del nodo sorgente del pacchetto.

• Destination Label: Etichetta del nodo destinazione del pacchetto.

• Type: Tipo e priorità del payload trasportato.

• Sequence Number: Numero sequenziale del pacchetto per riordinare i
pacchetti all'arrivo e garantire una consegna in ordine.

• OAM: Operation, Administration, Maintenance.

• HEC: Head Error Correction.

1.5.4 Categorie di reti OPS
Esistono fondamentalmente due grandi famiglie di reti OPS, le prime dette
Slotted OPS Networks suddividono il tempo in slot di dimenione ssa al cui
interno possono presentarsi o meno dei pacchetti, e reti di tipo Unslotted
OPS Networks in cui abbiamo un approccio meno rigido in cui ogni pacchet-
to è considerato al suo istante di arrivo. Vediamo ora in dettaglio le due
cateogrie[20].

Slotted OPS networks
Nelle reti OPS di tipo slotted i pacchetti che viaggiano all'interno sono di
dimensione ssa e sono posizionati all'interno di intervalli di tempo pressati
detti time slots. Ogni time slot può contenere un singolo paccheto (composto
come visto da header, payload e le bande di guardia addizionali). I nodi su
questa tipologia di rete lavorano in maniera sincrona mantenendo i conni dei
time slot allineati fra loro. Inoltre l'uso di switch sincroni in reti di tipo slotted
ci permette di dover risolvere un minor numero di contese tra pacchetti (dato
che questi sono di lunghezza ssa e vengono inoltrati insieme con i limiti degli
slot allineati) oltre a poter portare pacchetti già nativamente di dimensione
ssa (come ad esempio nelle celle ATM). Come contro questa tipologia richiede
l'allineamento dei pacchetti e uno stadio di sincronizzazione[20].

18 Le reti ottiche

Unslotted OPS networks
Nelle reti OPS di tipo unslotted i pacchetti che viaggiano all'interno possono
essere di dimensione variabile, e il tempo non è suddiviso in slot. I nodi su
questa tipologia di rete lavorano in maniera asincrona senza alcun requisito di
allineamento. Inoltre l'uuso di switch di tipo asincrono in reti di tipo unslotted
ci permette di evitare la segmentazione e il riassemblamento dei pacchetti sia in
ingresso sia in uscita dai nodi, è in grado di trasportare pacchetti di dimensione
variabile (ad es. su protocollo IP) ma presenta un numero maggiore di contese
da risolvere[20].

1.5.5 Content Resolution
Uno dei principali problemi dell'approccio di tipo Optical Packet Switching
(OPS) è la così detta Contention Resolution (o risoluzione di contesa) che si
verica quando due o più pacchetti competono per la stessa risorsa (nel caso
ottico stessa bra e lunghezza d'onda) allo stesso istante[20]. Questo problema
può essere arontato e risolto in diversi domini:

• Spazio

• Tempo

• Frequenza o più propriamente lunghezza d'onda

• ...

Mentre però nella commutazione di pacchetto su dominio elettromagneti-
co Electronic Packet Switching (EPS)) il problema della contesa è aontato
operando nel dominio del tempo usando delle memorie RAM come code, in
ambito ottico Optical Packet Switching (OPS)) questo approccio si scontra
con un limite tecnologico tuttora irrisolto. Ad oggi infatti non si è riusciti
ad implementare un componente che agisca come memoria ottica, in modo
equivalente alle RAM elettroniche, e per ovviare a questa carenza si ricorre a
delle linee di ritardo che permettano alla logica di instradamento di stabilire
il percorso ritardando al proprio interno il usso dati, no a quando l'elabo-
razione e il percorso di uscita non siano stabiliti. Questi componenti prendono
il nome di Fiber Delay Line (FDL). Inoltre le FDL orono solo valori di ritardo
discreti e in numero limitato e contribuiscono ulteriormente al degrado della
qualità del segnale. D'altra parte però l'approccio OPS permette di arontare
la contesa nel dominio delle lunghezze d'onda (wavelength domain ) sfruttando
le proprietà della wavelength conversion. Mediante dei particolari dispositivi


detti Wavelength Converter (WC) è possibile, in caso di contesa sulla stes-
sa lunghezza d'onda, far variare la lunghezza d'onda di appartenenza di un
pacchetto risolvendo così la contesa. Purtroppo i WC sono componenti molto
complessi e costosi e, come vedremo, il loro utilizzo è molto razionalizzato nelle
architetture di commutazione alla base delle reti ottiche[20].

1.5.6 Riessioni sull'uso di OPS
Le caratteristiche che fanno di OLS una tecnica vincente sono da ricercare
nei suoi punti di forza. OLS permette l'uso di una singola tecnologia (quella
ottica) tra le end-stations della rete, quando un pacchetto lascia un host ed
entra in una rete ottica gestita da OLS esso vede solo un unica lunga bra
ottica che lo conduce all'uscita alla rete di destinazione. Questò è conces-
so grazie al disaccoppiamento tra data payload e header informations spesso
trasmessi a dierenti livelli di bit rate (per facilitare il processamento elettron-
ico dell'header). Inoltre i pacchetti che vengono inoltrati attraverso uno stesso
percorso (path) sperimentano lo stesso ritardo, e se un pacchetto è bloccato
ad un determinato nodo può essere rediretto ad un altro percorso o buttato
via (dropped ). Inoltre OLS introduce delle informazioni per il timing consid-
eration. Il contention control (controllo sulla contesa) è eettuato mediante la
deviazione su un altra lunghezza d'onda. Ovvero quando dei pacchetti prove-
nienti da molteplici utenti arrivano allo switch node allo stesso tempo, posso
indirizzare un pacchettoa ad una lunghezza d'onda meno sovraccarica.
Per quanto riguarda l'impatto a livello tecnologico ed economico l'uso di
OLS ore numerosi vantaggi. Ad esempio il suo uso permette di colmare il
gap tra l'uso di IP nelle normali reti e la tecnica OLS delle dorsali ottiche
nei punti di contatto fra queste, sostituisce l'esistente topologia ad anello delle
MAN con quella a optical switching, fornirà la base per i servizi della prossima
generazione e semplicherà i costi di gestione per i service provider (veloci e
semplici da gestire)
Riassumendo abbiamo visto che la tecnica di electrical packet switching non
è compatibile con la trasmissione su tecnologia ottica rendendo necessario l'uso
della tecnica detta di Optical Label Packet Switching (OLPS) che ci permette
di evitare le conversioni di tipo OEO (prestazioni) garantendo al tempo stesso
la compatibilità con numerosi layer protocols (mediante OLS). Inoltre OLPS è
compatibile con la multiplazione in tecnica WDM fornendo dei miglioramenti
prestazionali e, sulla giusta scala, economico in rapporto ad un proporzionale
incremento della complessità[8].

Capitolo 2

Architetture per router ottici

Bisogna stare attenti agli
ingegneri. Cominciano con le
macchine da cucire e niscono
con la bomba atomica.

Marcel Pagnol, scrittore e regista
francese.
(1895 - 1974)

Esistono dierenti approcci nella progettazione di architetture per reti ot-
tiche. Tutto ruota intorno alle necessità di progetto e alle speciche in termini
di prestazioni, funzionalità e costi. Essendo la tecnologia ottica ancora in uno
stadio precedente alla diusione su larga scala il prezzo dei singoli componen-
ti è ancora particolarmente elevato e questo spesso spinge alla progettazione
di architetture che condividano il più possibile l'uso di questi dispositivi, in
un ottica di contenimento dei costi. In un approccio invece più orientato alla
fornitura di servizi con elevata Quality of Service (QoS), in cui è importante
garantire la presenza di ussi dati di tipo burst o pacchetti, senza avere vin-
coli e limitazioni nell'uso di componenti ottici, allora aorano architetture più
complete ma più costose. E' proprio in questo caso dove risulterebbe utile una
piattaforma per il collaudo e la valutazione dell'architettura proposta prima
della sua realizzazione e quindi dell'acquisto dei componenti che la realizzano.
Introdurremo ora una generica architettura di router per reti ottiche OPS, in
modo da introdurre i principali componenti in gioco, le tecnologie con cui ven-
gono implementati e i rispettivi ruoli per poi presentare una carrellata delle
principali architetture note in letteratura.

22 Architetture per router ottici

2.1 Generica architettura di un router ottico
Prima di analizzare a fondo le caratteristiche e le diverse potenzialità delle
varie architetture, introduciamo una schematizzazione della struttura di base
di uno di questi nodi per reti ottiche in modo da presentare i componenti
principali e i loro ruoli all'interno del meccanismo di interconnessione svolto
dal nodo stesso.

Figura 2.1: Una generica architettura per router ottici

Come visibile in gura 2.1, l'architettura di base si compone di diverse
unità o blocchi. L'interfaccia di ingresso, quella di uscita, la matrice di commu-
tazione, uno stadio di buering e un unità di controllo. Nel seguito forniremo
nozione dei principali ruoli di queste unità nel processamento dei pacchetti ot-
tici all'interno del router al ne di chiarire meglio le interazioni che avvengono
tra queste ed il percorso del traco attraverso il nodo.

2.1.1 Input Interface
L'interfaccia di ingresso è il primo componente del router ottico che viene
attraversato dal traco in arrivo. Qui le informazioni vengono identicate,
misurate e preparate al processamento nel nodo. In particolare possiamo
identicare tre distinte fasi:
• Delineazione del pacchetto

• Sincronizzazione

• Pre-processamento dell'header

Delineazione del pacchetto
In questa fase l'interfaccia di ingresso identica l'inizio e la ne del pacchetto,
ed in particolare dell'header e del payload che lo compongono grazie all'aiuto

2.1. Generica architettura di un router ottico 23

delle due guard band concepite per favorire questo scopo. Questa operazione
separa quindi le informazioni di routing dal carico pagante operando la prima
grande distinzione tra piano dati e piano di controllo. A livello di potenza, la
delineazione dell'header e la sua successiva divisione dal payload non comporta
una perdita signicativa in termini di potenza globale del segnale. In questo la-
voro quindi, come dettagliato in seguito non si terrà conto di questa variazione
anche se in futuro, in una versione maggiormente dettagliata della corrente
implementazione, questa modellazione può essere facilmente considerata.

Sincronizzazione (solo in switch sincroni)
Solo per quanto riguarda gli switch basati su un meccanismo di tipo slotted sin-
crono è prevista una fase di sincronizzazione ed allineamento dei pacchetti che
arrivano da dierenti lunghezze d'onda e dierenti bre di ingresso, considerati
all'interno dello stesso timeslot.

Pre-processamento dell'header
Prima di lasciare l'interfaccia di ingresso il pacchetto è dunque separato dal
payload come accennato, successivamente convertito dal dominio ottico a quel-
lo elettronico mediante un convertitore di tipo Optical-Electrical (OE), quindi
decodicato e inoltrato all'unità di controllo per il processamento elettroni-
co. Il payload invece, separato dall'header ma ancora nel dominio ottico viene
posto in ingresso alla matrice di commutazione, o meglio nel buer ad es-
sa collegata, in attesa del processamento delle informazioni di routing che lo
riguardano.

2.1.2 Control Unit
L'unità di controllo è il secondo componente in ordine di processamento all'in-
terno del nodo, che si pone però su un piano diverso da quello dei dati nora
coinvolto, e attiene più propriamente al piano detto, appunto, di controllo.
Qui le informazioni contenute nell'header arrivano in forma elettronica, quindi
sono più facili da elaborare grazie ai paradigmi, alle tecnologie e agli algoritmi
di scheduling noti e disponibili da tempo in ambito elettronico ed informatico,
a dierenza delle neo tecnologie in ambito ottico. Queste informazioni, elab-
orate per risolvere le necessità del traco in termini di qualità e destinazione
da raggiungere, determinano quindi la congurazione della matrice di commu-
tazione. Qui si delina dunque un punto di contatto tra il piano di controllo
(decisionale) e il piano dati (attuatore). Si vedrà in seguito come alcune rac-
comandazioni di enti internazionali stiano denendo e cercando uno standard


per questa interazione. Una volta quindi processate le informazioni di rout-
ing e opportunamente congurata la matrice per il pacchetto in esame, il suo
header viene aggiornato con le nuove informazioni che gli saranno necessarie
all'uscita dal nodo per dialogare con il prossimo intermediario nel percorso tra
il mittente e il destinatario, e spedito all'interfaccia di uscita.

2.1.3 Buer
Questa unità in realtà, in base alle diverse architetture, può far parte o meno
della matrice di commutazione, ed esservi posta in incipit o in uscita dalla stes-
sa. La sua funzione però non cambia a prescindere dal suo posizionamento.
All'interno di questa unità infatti il payload è in attesa che l'unità di con-
trollo conguri opportunamente la matrice di commutazione nei termini dei
dispositivi interessati, secondo le informazioni presenti nel suo header. Questa
attesa, ssa o con una componente variabile, sempre in base alle varie architet-
ture disponibili, è realizzata in ambito ottico mediante delle Fiber Delay Lines
(FDL), componenti che ritardano il segnale ottico che le attraversa di un cer-
to valore. Come accennato il ruolo che nel dominio elettronico è adato a
delle memorie RAM qui è svolto da questi componenti, se pur in maniera non
proprio analoga.

2.1.4 Switching Matrix
La matrice di commutazione ottica è il componente più complesso e caratter-
izzante dell'intera architettura. Introdurremo qui solo le nozioni base della
logica di funzionamento rimandando un dettagliato approfondimento sui com-
ponenti interni della struttura che ne delineano il funzionamento nel prossimo
capitolo. La matrice di commutazione inoltra il payload attraverso i suoi dis-
positivi interni in accordo alle direttive ricevute dall'unità di controllo con lo
scopo di convogliare il traco in ingresso verso le sue uscite cercando ove possi-
bile di risolvere eventuali contese mediante la conversione su lunghezze d'onda
dierenti.

2.1.5 Output Interfaces
L'interfaccia di uscita è l'ultimo componente del router ottico che viene at-
traversato dal traco che attraversa il nodo. Qui le informazioni aggiornate
provenienti da piano di controllo e quelle in uscita dalla matrice di commu-
tazione vengono riunite, misurate e preparate a lasciare il nodo. In particolare
possiamo identicare tre distinte fasi, mostrate di seguito.

2.2. La matrice di commutazione ottica 25

Aggiornamento dell'header

Innanzitutto l'header aggiornato proveniente dall'unità di controllo viene ri-
convertito al dominio ottico mediante un convertitore di tipo Electrical-Optical
(EO). Successivamente questo viene unito al payload proveniente dalla ma-
trice di commutazione ricreando così il pacchetto ottico iniziale, aggiornato
però nelle sue informazioni di instradamento ed inoltro. In questa operazione
vengono sempre inserite le due guard band per distinguere le varie parti del
segnale prima di spedirlo verso l'uscita.

Rigenerazione 3R

All'interno dell'interfaccia di uscita eettua spesso una rigenerazione del seg-
nale ottico in termini di amplicazione di potenza, squadratura del segnale e
temporizzazione. Questa operazione è detta rigenerazione 3R dalle iniziali in
inglese delle tre operazioni reamplication, reshaping e retiming.

Sincronizzazione (solo in switch sincroni)

Solo per quanto riguarda gli switch basati su un meccanismo di tipo slotted sin-
crono è prevista una fase di sincronizzazione ed allineamento dei pacchetti che
arrivano da dierenti lunghezze d'onda per dierenti bre di uscita, considerati
all'interno dello stesso timeslot.

2.2 La matrice di commutazione ottica
Come già accennato la matrice di commutazione ottica è il componente più
complesso e che realmente dierenzia le deiverse architetture. Forniremo ora
una descrizione di base dei principali componenti che costituiscono questo com-
plesso dispositivo al ne di chiarire le dinamiche e le principali dierenze tra
le varie architetture proposte nel prossimo capitolo.

2.2.1 Erbium-Doped Fiber Ampliers (EDFA)
Questo dispositivo è l'amplicatore più distribuito per le soluzioni in bra
ottica, e la sua nestra di amplicazione coincide con la terza nestra di
trasmissione del silicio sulla bra ottica [2].


Figura 2.2: Simbolo graco di un amplicatore EDFA

2.2.2 WDM Demultiplexer
Questo componente è in grado di ripartire il segnale ottico presente su una
singola bra ottica in ingresso, nelle sue W componenti pari alle lunghezze
d'onda presenti.

Figura 2.3: Simbolo graco di un demultiplatore WDM

Grazie a questa demultiplazione si è in grado di manipolare le singole
lunghezze d'onda, e quindi le informazioni presenti sulla stessa, senza pre-
occuparsi della contemporanea presenza di ulteriori segnali presenti ad altre
frequenze o lunghezze d'onda.

2.2.3 Fiber Delay Line (FDL)
Un buer ottico è un dispositivo che è in grado di immagazzinare temporanea-
mente la luce. Proprio come nel caso di un normale buer standard, è un
supporto di memorizzazione che consente la compensazione nella dierenza
dei tempi del vericarsi degli eventi. Più precisamente, un buer ottico è in
grado di memorizzare i dati trasmessi otticamente, senza la conversione al do-
minio elettrico. Inoltre le operazioni di processamento elettronico sono il vero
collo di bottiglia dell'OPS, oltre al problema della generazione delle contese.

Figura 2.4: Simbolo graco di una FDL


Ogni volta che due o più pacchetti di dati arrivano ad un nodo della rete,
nello stesso istante e contendono per la stessa uscita, si verica una situazione
di contesa. La scelta più ovvia ma meno performante sarebbe quella di ab-
bandonare tutti i pacchetti in eccesso, ma si possono applicare in genere tre
soluzioni: il buering, deection routing o la conversione di lunghezza d'on-
da. Il buering ottico utilizza delle linee di ritardo in bra o Fiber Delay
Line (FDL) per ritardare la luce, ed è considerato come il più ecace. Sic-
come la luce non può essere congelata, un buer ottico è costituito da bre
ottiche, ed è generalmente molto più grande di un chip di memoria RAM di
capacità comparabile. Una singola bra può servire come un buer. Tuttavia,
una serie di più di solito è usato. Una possibilità, per esempio, è quello di
scegliere un certo T per la bra più piccola, e poi lasciare che il secondo, terzo,
. . . hanno lunghezze 2T, 3T, . . . . Un altro esempio tipico è quello di utilizzare
un ciclo unico, in cui i dati circola un numero variabile di volte. [2]

2.2.4 Wavelength Converter (WC)
Un dispositivo in grado di convertire la lunghezza d'onda di appartenenza del
sengale di ingresso ad un'altra lunghezza d'onda in uscita è detto convertitore
di lunghezza d'onda o più propriamente Wavelength Converter o WC.

Figura 2.5: Simbolo graco di un convertitore WC

Il classico convertitore di lunghezza d'onda è costituito da uno schermo di
materiale luminescente, che assorbe le radiazioni luminose e le irradia in un
lunghezza d'onda superiore. Esistono dierenti tipologie di convertitori in base
alla varietà.

Fixed-input Tunable-output Wavelength Converter (FTWC)
Convertitore che accetta solo un determinata lunghezza d'onda ssa in ingresso
mentre permette di convertirla verso l'uscita su una qualsiasi altra lunghezza
d'onda. Rappresenta il più economico dei dispostivi della sua categoria.

Tunable-input Tunable-output Wavelength Converter (TTWC)
Convertitore che accetta in ingresso una qualsiasi lunghezza d'onda e permette
di convertirla verso l'uscita su una qualsiasi altra lunghezza d'onda. Più costoso


dei precedenti, permette però l'uso di un singolo dispositivo per un insieme di
lunghezze d'onda al posto di W dispositivi di tipo FTWC.

2.2.5 Splitter
Grazie a questo dispositivo il segnale in ingresso proveniente da una singola
bra ottica può essere riprodotto, e quindi duplicato, verso un numero N di
copie in uscita.

Figura 2.6: Simbolo graco di uno splitter

A livello di caratterizzazione di potenza è ovvio che la duplicazione del
segnale ne comporta anche una sua attenuazione proporzionale al numero di
copie in uscita dal dispositivo. L'entità di questa attenuazione è pari al valore
espresso nel modello dalla formula di attenuazione ideale:

attenuazione = 10log10 N

2.2.6 Switches
I veri dispositivi alla base del meccanismo di commutazione all'interno della
matrice sono i cosidetti switch o interuttori. Questi componenti sono in grado
di inoltrare o bloccare in base al loro stato (chiuso/aperto o ON/OFF) il
passaggio dell'informazione attraverso di loro. Esistono dunque tecnologie e
meccanismi dierenti per realizzare tali dispositivi, ognuno dei quali presenta
dierenti caratteristiche e prestazioni in termini di velocità di commutazione
dello stato, consumi e costi di realizzazione. Accenniamo ora due delle tecniche
base per la costruzione degli switch all'interno della matrice di commutazione.

Semiconductor Optical Amplier (SOA)
Gli amplicatori ottici a semiconduttore sono dei dispositivi che utilizzano
un semiconduttore come mezzo per fornire il guadagno di potenza del segnale.
Amplicatori di questo tipo vengono utilizzati nei sistemi di telecomunicazione


sia come puri e semplici amplicatori, sia come dispositivi interuttori. Tipica-
mente operano a lunghezze d'onda del segnale tra 0,85 micron e 1,6 micron e
sono in grado di generare un guadagno no a 30 dB[7].

Figura 2.7: Simbolo graco di un SOA

L'amplicatore ottico a semiconduttore è tipicamente di piccole dimensioni,
e questo favorisce il processo di integrazione dei componenti nella matrice
e inoltre è comandato (pompato) elettricamente. A certi livelli di scala, il
SOA risulta meno costoso di un EDFA e può essere integrato con laser a
semiconduttore, modulatori, e altri dispositivi, tuttavia, le prestazioni non
sono ancora paragonabili a quelle di un EDFA. Infatti un SOA genera un
rumore più alto e fornisce un minore guadagno. Ciò deriva dal tempo di vita
dello stato, che dura approssimativamente qualche nanosecondo o poco più,
ed è proprio per questo che il guadagno reagisce rapidamente alle variazioni di
potenza del segnale che possono causare cambiamenti di fase e dar luogo ad
alterazione dei segnali.

Micro-Electro-Mechanical Systems (MEMS)

Con questo termine si racchiude tutta la tecnologia dell'innitamente picco-
lo, che porta a scala micrometrica i sistemi elettromeccanici. I MEMS sono
anche denominati micromacchine o Micro Systems Technology (MST) e sono
costituiti da componenti da 1 a 100 micrometri in termini di dimensioni (vale
a dire 0,001-0,1 mm) e i dispositivi in generale variano nel formato da 20 mi-
crometri (20 milionesimi di metro), a un millimetro[2]. In ambito ottico questi
dispositivi vengono utilizzati per creare array di micro specchi riettenti usati
poi come dispositivi interuttori.

Figura 2.8: Simbolo graco di un MEMS ad uso ottico


2.2.7 WDM Multiplexer
Questo componente è in grado di ricomporre a partire dalle sue W componenti
pari alle lunghezze d'onda presenti, il segnale ottico da presentare in uscita

Figura 2.9: Simbolo graco di un multiplatore WDM

Grazie a questa multiplazione si è in grado di rigenerare il segnale ottico da
trasmettere in uscita con tutte le proprietà e le potenzialità che la tecnica di
multiplazione WDM garantisce per la trasmissione dei dati a lunga distanza.

2.2.8 Combiner
Grazie a questo dispositivo il segnale in ingresso disponibile su M copie può
essere ricombinato per tornare, in uscita, sotto forma di un singolo segnale
ottico.

Figura 2.10: Simbolo graco di un combiner

Anche qui a livello di caratterizzazione di potenza la riduzione dei sengali
ne comporta anche una sua attenuazione proporzionale al numero di copie
presenti in ingresso al dispositivo. L'entità di questa attenuazione è pari al
valore espresso nel modello dalla formula di attenuazione ideale:

attenuazione = 10log10 M

2.3. Shared Architectures 31

2.3 Shared Architectures
Come abbiamo visto in ambito ottico il problema della contesa (content reso-
lution ) si aronta nel dominio delle lunghezze d'onda sfruttando le proprietà
della wavelength conversion. Dato però che i WC sono componenti complessi e
costosi, molte delle architetture proposte dalla comunità di ricerca considerano
che i WC siano condivisi il più possibile in diverse modalità, all'interno di un
nodo ottico, per garantire il risparmio sul costo di costruzione del dispositivo.
Le tre principali modalità di condivisione, mostrate anche in [4] sono:

• Shared-Per-Node (SPN)

• Shared-Per-Link (SPL)

• Shared-Per-Wavelength (SPW)

2.3.1 Shared-Per-Node (SPN)
Questa soluzione prevede che un insieme di WC sia completamente condi-
viso tra tutti i canali in ingresso (input channels ). Questo schema richiede
però l'uso di convertitori di tipo Tunable-input Tunable-output Wavelength
Converter (TTWC) che consentano ad un pacchetto appartenenete ad una
qualsiasi lunghezza d'onda di poter usare uno qualsiasi dei convertitori disponi-
bili ed essere convertito su una qualsiasi lunghezza d'onda in uscita. Questi par-
ticolari convertitori sono molto costosi e compessi proprio perchè permettono
di variare a piacimento le lunghezze d'onda di ingresso e di uscita[4].

2.3.2 Shared-Per-Link (SPL)
In questo schema i convertitori sono condivisi per bra di uscita (output ber ).
Anche questo schema richiede però l'uso di convertitori di tipo Tunable-input
Tunable-output Wavelength Converter (TTWC) costosi e molto complessi[4].

2.3.3 Shared-Per-Wavelength (SPW)
Recentemente è stato proposto un nuovo schema di utilizzo dei convertitori,
qui sono condivisi per lunghezza d'onda (da cui il nome). In questa cong-
urazione possiamo usare dei convertitori di tipo Fixed-input Tunable-output
Wavelength Converter (FTWC) meno complessi e più economici dei TTWC in
quanto impostati su una determinata lunghezza d'onda di ingresso, pur man-
tenendo la capacità di conversione verso qualsiasi altra lunghezza d'onda di


uscita. Questa soluzione permette con un limitato numero di WC può garan-
tire le stesse performance del caso in cui abbia a disposizione un numero di
convertitori tale da coprire ogni evenienza, gsrantendo così un risparmio sul
costo del dispositivo[4].

Figura 2.11: Architettura di riferimento SPW

Come si evince in gura 2.11 l'architettura base è composta da:

• N Input ber Interfaces (II) ognuna contenente un segnale multiplexato
mediante tecnica WDM (su singola bra) con M lunghezze d'onda

• N Output ber Interface (OI) ognuna contenente un segnale multiplexato
mediante tecnica WDM (su singola bra) con M lunghezze d'onda

• N Demodulatori 1:M che scindono il segnale WDM nelle sue M compo-
nenti (lambda1, . . . , lambdam)

• N Space Fabric

• M Insiemi dierenti ognugno formato da B ( N) Wavelength Converter
(WC) per un totale di M*B WC. Ogni insieme degli M presenti ha
in ingresso segnali con la stessa lunghezza d'onda quindi può usare dei
FTWC

2.4. L'architettura Broadcast-and-Select 33

Come accennato in precedenza questo schema garantisce una serie di van-
taggi, a cominciare dall'uso di convertitori del tipo FTWC, oltre alla possibilità
di organizzare la componente di switch in maniera meno onerosa in quanto è
possibile usare M piccoli switch fabric per ogni lunghezza d'onda al posto di
un singolo grande switching fabric necessario nell'approccio SPN. La perdi-
ta di pacchetti può avvenire per output blocking (se non abbiamo abbastanza
lunghezze d'onda nella OI di destinazione per accomodare tutti i pacchetti ad
essa indirizzati) o per inability to convert o inabilità a convertire il pacchetto
per carenza di converitori[4].

2.4 L'architettura Broadcast-and-Select
Seppur interessanti e ecenti dal punto di vista del risparmio sui costi queste
architetture non consentono una adeguata gestione di traci dierenziati per
tipologia e basati su livelli di servizio. In contrapposizione alle soluzioni
presentate vi è una architettura che rientra nella denizione Broadcast-and-
Select (BaS). In questa architettura le informazioni vengono propagate a tutte
le interfacce di uscita del nodo verso cui il percorso è ostacolato solo da alcu-
ni dispositivi in grado di comportarsi come interruttori ottici, permettendo al
segnale di passare o meno in base al loro stato [5].

Figura 2.12: Tipologie di architettura Broadcast-and-Select.

Congurando opportunamente questi dispositivi, ovvero la matrice di com-
mutazione ottica, secondo le direttive fornite dal piano di controllo secondo
l'algoritmo di scheduling utilizzato è possibile attivare o disattivare gli inter-


ruttori ottici in modo da instrdare i pacchetti nei percorsi voluti rispettando
l'ordine e le contese.
In gura 2.12 è possibile osservare la struttura di una rete di Broadcast-
and-Select (BaS) tipica di un nodo centrale di una rete ottica (possibilmente
anche multi-granulare). L'architettura dispone di N bre di input/output che
trasportano un segnale WDM a M lunghezze d'onda. Questo tipo di architet-
tura è stato studiato molto in passato in una congurazione con una sola
tipologia di interruttori ottici mentre qui viene proposta una architettura con
dispositivi veloci (fast ) e dispositivi lenti (slow ) come SOA e MEMS, fornendo
così buone prestazioni e garantendo la scalabilità del nodo, pur mantenendo il
costo della scalabilità più basso possibile. In questo esempio F lughezze d'onda
sono connesse ai dispositivi veloci, mentre M - F a dispositivi lenti. L'architet-
tura BaS fornisce alcuni vantaggi rispetto ad altre soluzioni. Innanzitutto
supporta facilmente le comunicazioni di tipo multicast e broadcast inoltre la
switching fabric è implementata sfruttando i dispositivi ottici come semplici
interruttori ON/OFF. Così facendo non si ha più bisogno di switching elements
di grandi dimensioni, costosi e poco scalabili. L'architettura così proprosta è
bloccante sulle lunghezze d'onda ovvero se due segnali arrivano allo switch da
input dierenti sulla stessa lunghezza d'onda non possono essere inoltrati alla
stessa bra di uscita a causa di collisione nello stesso canale. Questa scelta
limita molto le performance del nodo, per far fronte a questo si è pensato di
introdurre dei componenti in grado di eettuare la conversione di lunghezza
d'onda sui segnali in arrivo in modo da risolvere quando possibile le contese
sui canali. Nella gura 2.12 (b) è visibile un ulteriore pre-stadio con M Fixed-
input Tunable-output Wavelength Converter (FTWC)[5]. Non limitando l'uso
di dispositivi questa soluzione può risultare più dispendiosa, ma garantisce un
alto supporto a quei meccanismi che consentono la trasmissione ecente di
traco altamente basato su livelli di Quality of Service (QoS).

Capitolo 3

Un modello software di router
ottico

Raramente si migliora se non si
ha altro modello da imitare che
se stessi.

Oliver Goldsmith, scrittore e
drammaturgo irlandese.
(1730 - 1774)

L'utilizzo delle reti in bra ottica sta raggiungendo una diusione sempre
più capillare nel mondo delle telecomunicazioni. Purtroppo il punto a svan-
taggio di tale soluzione è l'elevato costo di un singolo nodo di commutazione
che raggiunge le diverse decine di migliaia di dollari rendendone giustica-
to l'acquisto solo per reti metropolitane o strutture molto ampie. Da questa
premessa emerge la necessità, per avere una piattaforma di studio della tec-
nologia, di poter in qualche modo emulare un tale dispositivo mediante una
modellazione il più reale possibile, e possibilmente conforme alle Request For
Comments (RFC) relative, in modo da poterlo implementare mediante degli
strumenti software che, opportunamente installati su hardware dedicati, costi-
tuiscano un banco di prova con prestazioni vicine all'originale ma a costi molto
più contenuti.

3.1 Architetture multi-granulari
Una risposta alla richiesta di essibilità della rete avanzata dalle necessità delle
moderne applicazioni in termini di banda, QoS e troughput può trovarsi nelle
così dette multi-granular optical networks. Queste particolari reti ottiche per-
mettono di sfruttare diverse granularità nel trasporto del traco e sono una

36 Un modello software di router ottico

soluzione chiave per servizi di alta prestazioni dinamiche di rete, nello sce-
nario futuro di Internet. In quest'ottica l'idea di sviluppare un framework di
emulazione per sostenere delle prove di prototipazione rapida permettendo di
prendere in considerazione l'interazione tra le diverse entità del nodo, diventa
lo scopo principale di questo lavoro[5]. L'archittetura introdotta inoltre deve
supportare il concetto di nodo ottico programmabile, ovvero denire una pi-
attaforma software e hardware che semplichi il controllo della rete, la sua
riprogrammazione (a livello logico, come ad esempio la sua topologia) e garan-
tire la trasparenza del servizio traducendo le tecnologie informatiche speciche
per una determinata tecnologia, rendendola indipendente sul piano astratto
e logico. Questo consentirà un uso essibile ed ecente delle risorse di rete,
insieme al soddisfacimento dei bisogni delle applicazioni. La progettazione di
un tale nodo programmabile permetterà la possibilità di orire una gestione
multi-servizio e multi-provider dello switch, e della relativa interfaccia con un
piano di controllo migliorato per supportare servizi multi-granulari[5].

Figura 3.1: La programmable node architecture basata sulla raccomandazione
ForCES come mostrata in [5]

Il percorso tracciato in Forwarding and Control Element Separation (ForCES)
denita nella RFC 3746 rappresenta una serie di raccomandazioni in grado di
denire un framework per la separazione nel piano di controllo di un router ot-
tico degli elementi di controllo Control Element (CE) e di inoltro Forwarding
Element (FE) denendo inoltre un protocollo standard per lo scambio delle

3.2. L'architettura proposta 37

informazioni tra CE e FE. Questo concetto permette di rimpiazzare la co-
municazione tra i moduli basata ora su standard proprietari trasformando le
network boxes in sistemi multi-vendor con i sottosistemi di controllo ed in-
oltro sviluppabili ed evolbibili separatamente[5]. Il lavoro svolto dal gruppo
di ricerca del relatore e dei correlatori di questa tesi mira ad introdurre un
ulteriore modularizzazione del sistema denito nella raccomandazione ForCES
nel cosidetto Forwarding Module (FM). Questo componente tende ad essere
totalmente congurabile da ogni Internet Service Provider (ISP) per le proprie
speciche necessità di traco tramite il CE e il FE. Il FE può inoltre interagire
con moduli software interni al router come meters, shaper e classier in modo
da permettere ai dati di essere instradati attraverso il corretto FM in relazione
alla classe di servizio cui appartiene il traco.

3.2 L'architettura proposta
Presentiamo ora l'architettura base del router ottico implementato nel corso di
questo lavoro. Il nodo deve essere interfacciato a un piano generico di controllo
della rete (ad esempio GMPLS) tramite un'interfaccia standard che permetta al
nodo di essere controllato da qualsiasi piano di controllo, in modo da garantire
la distribuzione e l'interoperabilità di rete in contesti diversi. L'interazione tra
piano di controllo e di gestione interna del nodo è stata adata all'entità che si
trova al livello più alto, il CE. Questo elemento elabora le richieste di servizio
provenienti sui canali di segnalazione e, secondo l'applicazione speciche esi-
genze di ogni richiesta in arrivo (ad esempio long-term waveband/wavelength
path establishment o fast sub-wavelength switching service ), negozia le risorse
necessarie per la trasmissione con l'elemento dello strato intermedio, FE. Il FE
è incaricato di gestire ed eseguire le operazioni logiche di inoltro internamente,
vericando la disponibilità di lunghezze d'onda di conversione, risoluzione dei
conitti, di scheduling di pacchetti o ussi burst. L'FE è sempre a conoscenza
dello stato attuale delle risorse di trasmissione, e risponde alle interrogazioni
del CE secondo la capacità del nodo di soddisfare una richiesta in arrivo [5].
Tuttavia, al ne di essere il più indipendente possibile dalla tecnologia real-
izzativa delle risorse di inoltro, il FE deve operare su una astrazione dell'had-
ware di attuazione, la cui congurazione sica è quindi delegata ai moduli di
livello inferiore, o Forwarding Module (FM). Ogni FM è incaricato di guidare
l'attuazione dei dispositivi hardware di uno specico paradigma di commu-
tazione in base alle decisioni del FE. Ad esempio, un dato FM sarà dedicato
ai dispositivi di commutazione ottica lenta (ad esempio, MEMS), mentre un
altro FM sarà incaricato di ssare i dispositivi di commutazione veloce (ad


Figura 3.2: Schema generale dell'architettura proposta

esempio per la commutazione di pacchetti o ussi burst ). Questo approccio
consente una visione virtualizzata delle risorse hardware di commutazione, che
può essere utilizzato dal FE quando si eseguono le funzioni di inoltro. Così i
fornitori di servizi sono quindi in grado di costruire e installare i loro FM e
controllarli attraverso il CE e gestire così l'interazione mediante il FE. Questo
sarà incaricato di creare le tabelle di inoltro, gestire gli algoritmi di spedi-
zione, e così via per le diverse applicazioni volute a seconda della QoS o di
altre necessità. In questo modo è possibile ottenere la compartimentazione
degli switch tra diversi enti, riducendo così l'ammontare dei costi attraverso la
condivisione delle risorse. Gli FM interagiscono con il sistema multi-granulare
per gestire i dati di spedizione secondo la granularità di trasporto richiesto
gestendo lo sfruttamento dell'hardware disponibile. Finora, la progettazione
dell'architettura dei nodi ottici non ha tenuto conto della interazione con il
piano di controllo e, ancora più importante, della possibilità di rendere il nodo
aperto e programmabile in modo essibile. Per fare questo, è necessaria una
attenta analisi di come mappare le applicazioni disponibili per le capacità di
commutazione. La soluzione di nodo programmabile proposta in questo la-
voro ne permetterà la congurazione dinamica e lo sfruttamento delle risorse
di inoltro al ne di renderle controllabili dalle applicazioni. Di conseguenza,
l'infrastruttura di rete sarà suddivisa in reti virtuali, attraverso l'astrazione
delle risorse di rete, permettendo così ai diversi fornitori di condividere queste
risorse e quindi trasformandola in una rete secondo il concetto multi-servizi,
multi-fornitore. Gli edge e core nodes in queste reti aggregheranno il traco in
modo eciente e gestiranno le proprie risorse in modo opportuno al ne di es-
eguire le operazioni di inoltro. La Switching Matrix (SM) inoltre dovrà essere
gestita da algoritmini di controllo adeguati per congurare dinamicamente le
risorse e fornire supproto ai servizi di rete [5].

3.3. Tecniche di valutazione di una architettura 39

3.2.1 L'estensione per i paradigmi OCS e OBS
L'architettura proposta, ed esplicata nel dettaglio per quanto concerne la
modalità OPS è inoltre estendibile al caso in cui debba gestire, come espresso
dalla sua natura, granularità di traco diverse a livello di commutazione di
circuito o ussi di traco di tipo burst. Come accennato, i canali di controllo
e segnalazione presenti nella gura generale della architettura[5].

3.3 Tecniche di valutazione di una architettura
Una volta denita l'architettura di commutazione in tutti i suoi aspetti, è il
momento di valutare le sue prestazioni da un punto di vista logico e sico. Per
ottenere ciò è possibile seguire diversi approcci metodologici come l'analisi, la
simulazione, l'emulazione o i test sici.
L'approccio analitico è spesso dicile e oneroso da realizzare sopratutto su
architetture complesse e sosticate come quelle in esame. Testare le perfor-
mance sul piano sico signica realizzare un banco di prova o (test-bed ) della
architettura proposta, tuttavia è stato dimostrato in recenti lavori, come in
[22] e [23], che con un numero elevato di porte e/o canali questi approcci sono
molto costosi e spesso impossibili da testare a fondo a causa della immaturità
della tecnologia ottica integrata. Inoltre con queste limitazioni, non è possi-
bile mediante l'uso dei test-bed vericare le prestazioni logiche (ad esempio la
perdita di pacchetti) dell'architettura.
Quindi in questi casi occorre testare l'architettura mediante un approccio
diverso, come la simulazione o l'emulazione software.
Per simulazione si intende la creazione di un modello della realtà che si
desidera studiare che consenta di valutare e prevedere lo svolgersi dinamico
di una serie di eventi susseguenti all'imposizione di certe condizioni da parte
dell'analista o dell'utente. L'emulazione invece nel senso più generale possibile
accepisce alla caratteristica di duplicare le funzioni di un determinato sistema
su un secondo sistema dierente dal primo ovvero permette l'esecuzione di una
serie di comportamenti deniti un ambiente (traco ottico) diverso da quello
sul quale l'emulatore viene eseguito (ambiente eletronico). Analizziamo ora
in dettaglio le caratteristiche di queste due soluzioni mettendo in risalto le
potenzialità ed i limiti di ognuna in modo da motivare la scelta eettuata.

3.3.1 La simulazione
La simulazione è il modo più semplice e diretto per implementare funzionalità
di una data architettura permettendo di ottenere risultati realistici, quando


le funzionalità degli switch ottici siano adeguatamente denite e considerate
nello strumento di simulazione. Per questo motivo, numerose attività di ricer-
ca in questo campo vengono eettuate tramite l'uso di simulatori ad-hoc o
facenti parte di un framework di simulazione (come OPNET, NS2, . . . ). D'al-
tra parte il suo utilizzo comporta un dispendio notevole in termini di tempo,
specialmente in presenza di eventi rari di campionamento. Per ottenere risul-
tati signicativi e ragionevoli, infatti, i parametri di simulazione devono essere
congurati correttamente, il che spesso non è un compito facile da eseguire.
Inoltre, le interazioni tra il controllo (vale a dire le decisioni di forwarding ) e il
set-up dell'hardware di commutazione non è eettivamente messo in evidenza
attraverso la simulazione, a causa della mancanza di conoscenza delle carat-
teristiche dell'hardware reale. Inne, se il traco in ingresso simulato non è
realistico e si discosta molto dagli scenari applicativi reali, questo potrebbe
generare risultati fuorvianti. Pertanto, la simulazione in sé non è suciente
per ottenere una buona comprensione delle funzionalità di un nodo ottico.

3.3.2 L'emulazione
Per questi motivi si è pensato che l'emulazione software di dispositivi di com-
mutazione ottici e dei relativi moduli di controllo collegati potrebbe rappre-
sentare un buon modo per fornire una valutazione delle prestazioni sia siche e
logiche. I software router consentono infatti la modularizzazione della architet-
tura e l'emulazione dei dispositivi ottici utilizzati per costruire il l'hardware
commutazione (sia dal punto di vista logico che sico). I moduli sono poi col-
legati gli uni agli altri per emulare l'architettura del nodo. Questo approccio
permette di valutare, osservare e testare le interazioni tra i diversi moduli,
migliorando la essibilità rispetto all'approccio della simulazione. Inoltre l'ar-
chitettura può essere testato su un framework di emulazione piuttosto che
dover implementare test-bed complessi, costosi e dicili da gestire. I principali
vantaggi della emulazione per quanto riguarda la simulazione sono:
• Modularità del documento: una volta deniti, i moduli possono es-
sere aggiunti, rimossi, collegati e scambiati per ottenere diverse architet-
ture;

• Chiarezza punto di interazione: le interazioni tra i diversi moduli
sono esplicitate dalle connessioni tra gli stessi che possono essere prese
in considerazione ed analizzate;

• Testabilità dei moduli: i moduli software dedicati al controllo dello
switching fabric possono essere testati, anche se il costoso hardware che
li costituisce nella realtà non è disponibile;

3.4. Il software di programmazione Click! 41

• Facile modica del traco in ingresso: il traco in ingresso può
essere facilmente modicato cambiando la sorgente.

Per raggiungere questi obiettivi ed essere in grado di fornire un adeguato
livello di essibilità e capacità di integrazione con la nalità, per questi sistemi
di poter essere utilizzati in contesti reali l'autore ritiene che l'emulazione si
adatta bene ai requisiti di prova di una intera architettura nodo.

3.4 Il software di programmazione Click!
Ora introdurremo brevemente e negli aspetti in uso al nostro lavoro la pi-
attaforma software su cui è basata l'implementazione della architettura voluta,
ovvero il Click! Modular Router. Cenni ulteriori e un breve approfondimento
del framework è presente in appendice A.4.1 a questo testo.

3.4.1 Introduzione al Click!
Il Click! è una architettura software open-source modulare, orientata alla
realizzazione di una vasta gamma di dispositivi come router, processori di pac-
chetti, sorgenti di traco, Ethernet switch, rewall . . . basata su piattaforma
GNU/Linux e sviluppata dal Massachusetts Institute of Technology (MIT).

Figura 3.3: Logo del software Click Modular Router

Un qualsiasi dispositivo Click! è modellato esclusivamente attraverso l'ag-
gregazione di moduli di elaborazione dei pacchetti chiamati elementi e non
esiste ulteriore astrazione per un componente (del dispositivo) oltre a questa.
Gli elementi inoltre sono collegati tra loro mediante delle linee orientate che
rappresentano il usso dei pacchetti che li attraversa dette connessioni. Ogni
elemento implementa semplici funzioni come ad esempio la classicazione del
traco o l'accodamento piuttosto che lo scheduling o l'interfacciamento con
i dispositivi di rete. Un insieme di elementi connessi con più linee orientate
rappresenta una congurazione, ovvero il modello del dispositivo che vogliamo
simulare[24][17].


3.4.2 Elementi, connessioni e pacchetti
Diamo ora una breve descrizione dei costrutti base del Click! e delle loro
funzionalità al ne di rendere più chiara la comprensione del lavoro svolto.

Elementi
Un elemento è un componente software che rappresenta un'unità di elabo-
razione del traco (inteso ad esempio come pacchetti dati) ed esegue con-
cettualmente semplici calcoli, come ad esempio decrementare il campo Time-
to-live (TTL) di un pacchetto, piuttosto che calcoli complessi, come il routing
IP. In generale essi esaminano o modicano i pacchetti in un certo modo. Ogni
elemento è un oggetto C++ che può mantenere una sua autonomia. Disposi-
tivi di processamento, tabelle di instradamento, gestione delle code, conteggi
e quant'altro, sono tutte funzioni implementate dagli elementi. Gli elementi
sono dunque deniti come istanze di classi C++ in cui è specica la struttura
dei dati che possono essere trattati dall'elemento stesso e il suo comportamento
(quante porte avrà, quali handlers supporterà e come elaborerà i pacchetti).
In C++ ogni elemento corrisponde ad una sottoclasse della struttura Element.
Inoltre ogni elemento può avere un numero arbitrario di porte di ingresso e
uscita collegate ad altri elementi mediante dell connessioni. Ogni connessione
collega una porta di uscita di un elemento con una porta di entrata di un altro.
Il numero di porte di un elemento può essere sso, oppure può dipendere da una
stringa di congurazione, oppure da quante porte sono usate nella particolare
congurazione. Particolare caratteristica degli elementi è la denizione degli
Handler. Questi sono modalità di interfaccia esportate a livello di utente piut-
tosto che agli altri elementi della congurazione router. Ad esempio l'elemento
Queue ha un handler che riporta la sua lunghezza corrente come una stringa
ASCII decimale, mentre l'elemento Counter mette a disposizione un handler
che permette all'utente di conoscere il valore corrente del suo contatore[24][17].

Pacchetti Click!
I pacchetti Click! rappresentano le particelle elementari della comunicazione,
trasportando le informazioni che vengono eleborate dagli elementi. Durante il
funzionamento del dispositivo mappato nella congurazione, i pacchetti pas-
sano da un elemento all'altro attraverso collegamenti chiamati connessioni. Un
pacchetto Click! consiste in una serie di annotazioni e in un puntatore al reale
campo dati del pacchetto IP.
L'intestazione del pacchetto punta ai dati (rappresentati in gura 3.4 dal
pacchetto ottico), e grazie a questo meccanismo molte intestazioni possono

3.4. Il software di programmazione Click! 43

Figura 3.4: Schema rappresentativo di un pacchetto Click!

condividere gli stessi dati. Quando si copia un pacchetto, ad esempio tramite
l'elemento Tee, il Click! produce una nuova intestazione che condivide lo
stesso pacchetto dati. I pacchetti di dati condivisi sono detti perciò copy-on-
write mentre le intestazioni invece non lo sono mai, così la loro modica non
provoca mai una copia.
Oltre al puntatore ai dati l'intestazione contiene un certo numero di an-
notazioni, le quali possono essere condivise con il sistema operativo Linux,
oppure mediante speciche del linguaggio. Alcune annotazioni contengono in-
formazioni indipendenti dai dati (per esempio il tempo in cui il pacchetto è
arrivato), mentre altre memorizzano informazioni riguardanti i dati. Le anno-
tazioni sono memorizzate nell'intestazione del pacchetto in un ordine sso e
statico mentre i dati del pacchetto sono memorizzati in un singolo buer di
memoria[24][17].

Connessioni
Ogni connessione rappresenta un percorso possibile per il trasferimento dei pac-
chetti e collega una porta di uscita di un elemento con una porta di ingresso di
un altro, ed ognuna rappresenta un possibile percorso per il trasferimento dei
pacchetti tra gli elementi. In una congurazione Click! in esecuzione le con-
nessioni sono rappresentate come puntatori agli oggetti elemento e il passaggio
dei pacchetti lungo una connessione è implementato da una singola chiama-
ta di una funzione virtuale. Gracamente le connessioni vengono rappresen-
tate come frecce che collegano una porta sorgente ad una porta destinazione,
indicando la direzione del usso di pacchetti[24][17].

3.4.3 Il linguaggio e le congurazioni
Gli ultimi due tasselli del framework Click! , utili ad una maggiore compren-
sione del lavoro di implementazione svolto, sono mostrati di seguito.


Il linguaggio
Alla base della programmazione Click! vi è un linguaggio dichiarativo, ovvero
un linguaggio che descrive semplicemente il grafo relativo ad una congurazione
(a dierenza dei linguaggi di script, come per esempio i le .tcl di Network
Simulator 2 (NS2)). I linguaggi dichiarativi hanno il vantaggio della leggibilità,
ma soprattutto possono essere analizzati e modicati in maniera molto più
semplice di quanto invece non consentano i linguaggi imperativi.
Il linguaggio Click! è semplice, dato che comprende un numero ridotto
di costrutti utilizzabili, preferendo implementare delle estensioni del linguag-
gio attraverso elementi che avessero degli scopi specici. Questa scelta limita
i meccanismi ed i costrutti che possono essere utilizzati in fase di program-
mazione, ma consente di ottenere una grande essibilità. I programmi scritti
in linguaggio Click! e le congurazioni grache sono due strutture equivalenti.
Come abbiamo visto ciascun elemento appartiene ad una classe di elemen-
ti, la quale è specicata dal nome ed opzionalmente da una stringa di con-
gurazione. Gli elementi sono connessi attraverso le loro porte d'ingresso e
d'uscita. Nel linguaggio specico del Click! , le porte sono distinte attraverso
l'uso di numeri, mentre gli elementi sono distinti utilizzando un nome. Cias-
cun elemento in una congurazione possiede un unico nome, che un utente
può specicare in maniera opzionale. Tali elementi individuano e dierenziano
i vari elementi durante il processo di analisi (anche sintattica eseguita in fase
di compilazione), ed permettono inoltre al singolo utente, o ad altri program-
mi, di accedere ad un particolare elemento, anche in fase di esecuzione (lancio
della congurazione).

Denizione di una congurazione
Una congurazione è descritta mediante un semplice le di testo che rispetti la
sintassi del linguaggio Click! . Essa può essere pensata come un grafo orientato
in cui gli elementi ne rappresentano i vertici. Una congurazione è solitamente
divisa in due parti:

• Dichiarazioni: sezione in cui si deniscono gli elementi e se ne specico
i parametri.

• Connessioni: sezione in cui viene specicato come connettere gli elmenti
sopra deniti

Una qualsiasi congurazione Click! è costituita quindi una serie di compo-
nenti elementi, scelti dall'utente in base alle loro caratteristiche e peculiarità

3.5. Implementazione software della architettura 45

e in base alle nalità del modello, uniti mediante delle connessioni. Per im-
plementare delle estensioni o dei comportamenti specici per gli elementi si
possono scriverne di nuovi, oppure comporre più elementi esistenti nel modo
opportuno[24][17].

3.5 Implementazione software della architettura
Mostreremo ora in dettaglio una prima implementazione dell'architettura di
tipo Broadcast-and-Select (BaS) con estensione multi-granulare esposta prece-
dentemente, dettagliando gli aspetti implementativi d questa prima versione.
Dato il lavoro di ricerca e documentazione prima, di sviluppo e testing poi
si è deciso di portare a termine una prima versione della architettura che se
pur incompleta in alcuni aspetti, fosse funzionale e in grado di restituire dei
risultati da poter analizzare e confrontare. Inoltre l'implementazione propos-
ta sarà facilmente estendibile nelle componenti momentanemante trascurate,
non pregiudicando quindi il lavoro n qui svolto. In particolare ci si è concen-
trati sulla realizzazione di una architettura di tipo Broadcast-and-Select (BaS)
multi-granulare di cui si è implementato il solo paradigma di commutazione
OPS tralasciando per ora la commutazione ottica di circuito e a burst. Per
compensare a questa carenza si è puntato ad una relizzazione di una rete OPS
di tipo slotted sincrona, in quanto il caso asincrono, più generale, può essere
da questa facilmente derivato.

3.5.1 Emulazione della architettura
Una interessante possibilità per costruire un banco di prova programmabile
per router ottici, in grado di emularne il funzionamento, è rappresentato come
abbiamo visto dal framework Click! Modular Router [17]. Questo approc-
cio è stato recentemente dimostrato ecace per la misurazione e il controllo
programmabile dei router nei lavori [25][26][27].
La nuova sda è rappresentata dalla progettazione di una estensione del
framework al supporto di complesse funzioni di routing, organizzate in moduli,
che interagiscono tra di loro per mezzo di un protocollo adatto come speci-
cato per esempio nella direttiva Forwarding and Control Element Separation
(ForCES).

3.5.2 Analisi ed emulazione dei livelli di potenza
Degna di nota è l'estensione del modello per l'emulazione dei livelli di potenza
dei segnali e dei relativi andamenti all'interno della architettura. L'emulazione


infatti, in seguito alla generazione casuale di un livello di potenza discretizzato
per ogni segnale in ingresso è in grado poi di attribuire una attenuazione della
potenza stessa per ogni componente passivo attraversato dal segnale, su una
determinata lunghezza d'onda, calcolata mediante l'elaborazione di formule
ideali per l'attenuazione delle varie tipologie di dispositivi. Specularmente il
modello è in grado di emulare guadagni e equalizzazioni del livello di poten-
za del segnale nel caso questi attraversi componenti attivo come, ad esempio,
i SOA. Seppur implementata ad un livello iniziale questa estensione sarà in
futuro in grado di presentare un resoconto dettagliato sull'andamento del con-
sumo di potenza e sull'entità dei valori in gioco, indice di notevole interesse
per le archiettture in esame.

3.5.3 Implementazione basata sul software Click!
Una possibile congurazione che implementi l'architettura programmabile mo-
strata nei paragra precedenti, con riferimento ad un nodo ottico che im-
plementi i paradigmi di commutazione ottica a circuito, burst e pacchetto è
mostrato in gura 3.5.
Il software Click! ci permette di denire dei le di congurazione alta-
mente modulari in grado di realizzare i passi elementari della architettura. Ad
esempio la molteplicità di lunghezze d'onda è simulata usando la caratteristica
Paint Annotation la quale ci permette di marcare i dati e distinguere le varie
lunghezze d'onda. Lo schema considerato, può essere suddiviso concettual-
mente su due piani direnti:

• Control Plane: costituito dagli elementi più scuri, identica il piano in
cui si prendono le decisioni in termini di controllo ed inoltro del traco.

• Data Plane: costituito dagli elementi più chiari, identica il piano in
cui viaggia il traco dati.

Gli elementi più scuri rappresentano la realizzazione dei moduli del piano
di controllo, cioè il Control Element (CE), Forwarding Element (FE) e i tre
Forwarding Module (FM) uno per ogni paradigma di commutazione. Il CE
gestisce la prima parte del piano di controllo del nodo, avendo cura delle richi-
este provenienti dai canali di segnalazione e controllo fuori banda dei paradigmi
OCS e/o OBS e di segnalzione in banda dell'OPS (cioè l'intestazione dei pac-
chetti). La matrice di commutazione può essere implementata utilizzando degli
elementi Click! opportunamente personalizzati che emulano le caratteristiche
logiche e siche, in termini di congurazione e ritardi oerti dai diversi disposi-
tivi, attenuazione del segnale ottico, segnale-rumore e disponibilità della risor-
sa. Questo approccio potrebbe costituire la base per una futura integrazione

3.5. Implementazione software della architettura 47

Figura 3.5: Implementazione software della architettura proposta mediante
software Click!


di diverse funzionalità sviluppate per il controllo e la trasmissione, infatti, la
modularità garantisce che i diversi moduli possano essere rapidamente sostitu-
iti con quelli nuovi e testati molto facilmente. L'analisi comparativa del router
ottico programmabile qui modellato può inoltre essere emulata fornendo un
traco reale da parte di generatori ad hoc già disponibili.
Vediamo ora in dettaglio i componenti della architettura suddivisi sui vari
piani logici, introducendono le caratteristiche e le funzionalità.

3.6 Control Plane
Rappresentato dagli elementi di colore più scuro, identica il piano in cui si
prendono le decisioni in termini di controllo ed inoltro del traco. E' quin-
di composto dal Control Element (CE), Forwarding Element (FE) e dai tre
Forwarding Module (FM).

Figura 3.6: Il piano di controllo dell'architettura in ambiente Click!

3.6.1 OCS Signaling Channel
Questo elemento realizzerà in futuro, quando l'architettura sviluppata sarà es-
tesa a livello multi-granulare, il canale dedicato alla segnalazione per l'instau-
razioni di comunicazioni basate sul paradigma a commutazione di circuito.

3.6.2 OBS Control Channel
Anche questo elemento realizzerà in futuro, quando l'architettura sviluppata
sarà estesa a livello multi-granulare, il canale di controllo per l'instaurazioni
di comunicazioni basate sul paradigma di comunicazione burst.

3.6.3 Control Element (CE)
Il CE gestisce le richieste in arrivo dai canali di segnalazione fuori banda di
tipo OCS e/o OBS e le richieste in banda di tipo OPS (contenute negli header

3.6. Control Plane 49

dei pacchetti). Il CE dopo aver identicato le necessità associate alle richieste
in arrivo, invia la richiesta al FE.

Figura 3.7: Elemento composto ControlElement

HeadersQueue
Questo elemento realizza una coda FIFO di buerizzazione degli header conver-
titi nel dominio elettronico che si accodano per essere processati. L'estrazione
da questa coda avviene in modalità pull da parte dell'elemento successivo, il
TimeslotManager.

TimeslotManager
Il TimeslotManager estrae il valore del secondo byte dell'intestazione del pac-
chetto ottico. Questo valore esprime il timeslot cui il pacchetto appartiene e
viene memorizzato così nella annotazione Click! relativa.

SetTracNeed
Questo componente realizzerà in futuro la cattura delle informazioni relative
alle necessità richieste dal traco in esame. Questo aspetto, legato alla multi-
granularità del traco è momentaneamente impostato per generare delle in-
formazioni relative alle necessità che inidirizzino il traco sempre e solo al
modulo di inoltro destinato al paradigma OPS.

3.6.4 Forwarding Element (FE)
Il FE gestisce le operazioni logiche di forwarding in accordo alle richieste che gli
arrivano dal CE e dai messaggi di notica provenienti dai FM. Il FE è concepito
come indipendente dall'hardware quindi prende le sue decisioni indipendente-
mente dalle risorse di switching disponibili a livello hardware garantendo la
separazione tra piano di controllo e piano dati. A questo punto FE invia la
richiesta allo specico FM in accordo al trac need impostato dal CE con il
messaggio di congurare opportunamente la matrice se possibile.


Figura 3.8: Elemento composto Click! ForwardingElement

Label Lookup (LL)
Questo elemento legge il primo byte dell'header ottico del pacchetto e lo inter-
preta come la label di destinazione del traco. Questa viene dunque inoltrata
ad una struttura interna che implementa la Forwarding Table e così propria-
mente chiamata. L'interrogazione restituisce le informazioni sulla nuova des-
tination label che l'header dovrà assumere una volta processato e sulla inter-
faccia di uscita che il pacchetto dovrà seguire per raggiungere la destinazione
espressa. Queste informazioni veranno scritte nei relativi campi annotazione.

FESimpleScheduler
Questo elemento realizza in dettaglio l'algoritmo di scheduling nella sua parte
indipendente dall'hardware. Infatti recependo le speciche espresse nella di-
rettiva ForCES in questo componente non si ha conoscenza dell'hardware a
disposizione e quindi i controlli sullo scheduling dei pachetti devono avvenire
senza conoscenza diretta dello status della matrice di commutazione. Nel-
la versione implementata questo componente conta semplicemente i pacchetti
schedulati ed eettivamente inoltrati per ogni bra di uscita. Se, per il cor-
rente timeslot, per l'interfaccia di destinazione che il pacchetto in esame vuole
raggiungere sono già stati inoltrati W pacchetti, ciò vuol dire che non esiste
possibilità alcuna che il pacchetto, anche convertendo su un altra ulteriore
lunghezza d'onda, possa raggiungere l'uscita. Viene dunque scartato, incre-
mentando l'opportuno contatore. Altrimenti, se per il corrente timeslot, per
l'interfaccia di destinazione che il pacchetto in esame vuole raggiungere sono
stati inoltrati un numero minore di W pacchetti, ciò vuol dire che esiste la
possibilità che il pacchetto, magari dopo un opprotuna conversione su un al-
tra lunghezza d'onda in caso di contesa, possa raggiungere l'uscita. Questa
eventualità però è demandata al ForwardingModule che è a conoscenza del-
l'hardware e del suo stato corrente e quindi più qualicato a determinare il
buon esito della schedulazione. Le informazioni sul numero di pacchetti usciti

3.6. Control Plane 51

per ognuna delle bre di output è fornito al FESimpleScheduler dal Forward-
ingModule mediante l'opportuna connessione in retroazione che realizza così
una delle linee di comunicazione del piano di controllo.

Label Swap (LS)
Questo elemento riscrive il primo byte dell'header ottico del pacchetto con la
nuova destination label ottenuta precedentemente dal Label Lookup (LL).

3.6.5 Forwarding Module (FM) OPS
Il FM decide quale richiesta proveniente dal FE può essere soddisfatta e quale
no in accordo alla disponibilità di risorse hardware e l'occupazione delle risorse
corrente per richiesta ricevuta. Se risulta possibile soddisfare la richiesta l'FM
pilota sicamente gli switch hardware in accordo alle richieste e ritorna il
successo della operazione al FE. In caso non risultasse possibile soddisfare
la richiesta l'FM ritorna un messaggio di insuccesso della operazione al FE
che può decidere, qualora fosse possibile, di inoltrare la richiesta ad un altro
FM (es. fast-to-slow ). Il controllo dei dispositivi hardware è reso possibile
agli FM in ambiente Click! dall'uso degli handlers, non visibili in gura che
permettono ad un elemento di modicare la congurazione di un altro elemento
(es. la Switching Matrix (SM)) a run-time in modo che sia possibile emulare
il comportamento della logica di controllo di un nodo ottico.

Figura 3.9: Elemento composto Click! ForwardingModuleOPS

FMSimpleScheduler
Questo elemento realizza in dettaglio l'algoritmo di scheduling nella sua parte
dipendente dall'hardware. Recependo le speciche della direttiva ForCES in
questo componente si è nalmente a conoscenza dell'hardware a disposizione e


quindi i controlli sullo scheduling dei pachetti possono avvenire con la conoscen-
za diretta dello status della matrice di commutazione. Nella versione imple-
mentata questo componente controlla se per il pacchetto da schedulare esiste
un canale libero per la sua lunghezza d'onda, o se è possibile convertirlo su un
altra ulteriore lunghezza d'onda per raggiungere l'uscita. Se esiste un incas-
tro possibile, tra convertitori, SOA e bra in uscita il pacchetto è segnalato
al FE come schedulato e viene posto in ingresso allo script di controllo del-
l'attuazione. Altrimenti il pacchetto viene scartato e viene comunque inviata
un opportuna segnalazione al FE che, in un'implementazione futura, potrebbe
prevedere di reinviare il pacchetto ad un dierente FM.

NewTimeslotScript
Questo script di controllo, resetta la matrice ad ogni nuovo timeslot. Se il
pacchetto che esce dal FM è il primo pacchetto di un nuovo timeslot questo
script provvede a disabilitare i Wavelength Converter (WC) ed i SOA in mo-
do da ripristinare la matrice per l'inoltro dei pacchetti nel corrente quanto
temporale.

FMScript
L'FMScript è il cuore del meccanismo di attuazione dei dispositivi della matrice
di commutazione. Leggendo gli handler dell'elemento FMSimpleScheduler è in
grado di attivare il Wavelength Converter (WC) relativo al pacchetto, sulla
lunghezza d'onda impostata dallo scheduler del FM, e il relativo SOA.

3.7 Data Plane
A questo livello nell'architettura vi sono tutti i componenti sici del nodo e
che sono sicamente attraversati dal traco dati.

Figura 3.10: Il piano dati dell'architettura in ambiente Click!

3.7. Data Plane 53

3.7.1 Optical Source
Questo componente, collegato ad una socket sulla macchina di test, rappreseta
la sorgente di pacchetti per una determinata lunghezza d'onda, che poi si pone
in ingresso alla bra di input.

Figura 3.11: Elemento Click! OpticalSource

Socket
Elemento della classe Socket del Click! permette di ricevere i pacchetti da una
socket UDP specicando un indirizzo ed una porta validi.

setInputFiber
Elemento della classe Paint del Click! ci permette di marcare nelle annotazioni
il byte relativo alla bra di ingresso del pacchetto.

randomPowerScript
Elemento della classe Script del Click! ci permette di calcolare un valore
casuale di potenza per un range impostato.

setPower
il byte relativo alla potenza del segnale.

setWavelength
il byte relativo alla lunghezza d'onda di appartenenza del pacchetto.

setTimeslot
il byte relativo al numero di timeslot di appartenenza del pacchetto.


3.7.2 Input Fiber (IF)
Questo elemento modella la bra di ingresso. Al suo interno sono presenti vari
elementi OpticalSource in grado di connettere la congurazione a più sorgen-
ti di provenienza dei pacchetti nel caso si voglia testare il modello proposto
generando internamente i pacchetti, o ascoltando una socket UDP in modalità
userlevel o catturando i pacchetti da una interfaccia di rete se la congurazione
è installata come modulo kernel.

3.7.3 HeaderTap (HT)
Questo elemento, analizza i pacchetti nel dominio ottico e ne separa l'header
dal payload. L'header è inviato in ingresso al CE dove rappresenta la richiesta
in banda di tipo OPS, mentre il payload è posto in ingresso alla SM.

Figura 3.12: Elemento Click! HeaderTap

3.7.4 OEConverter
Questo elemento simula la conversione dell'header ottico del pacchetto nel
dominio elettronico.

3.7.5 Switching Matrix (SM)
Per semplicità nella implementazione è stata impostata una matrice di tipo
Broadcast-and-Select (BaS) che consenta di connettere due N = 2 bre ottiche
in ingresso a M = 2 bre ottiche in uscita. Ogni bra ottica trasporta poi
un segnale WDM a W = 4 canali o lunghezze d'onda. I vantaggi proposti da
questa architettura per la matrice di commutazione, rispetto ad altre soluzioni
sono stati presentati nel capitolo precedente. Brevemente ricordiamo che ques-
ta congurazione ci permette di supportare comunicazioni di tipo multicast e
broadcast, permette l'utilizzo di disositivi ottici (ad es. Semiconductor Opti-
cal Amplier (SOA)) come interruttori di tipo ON/OFF permettendo così di

3.7. Data Plane 55

evitare l'uso di switching elements di grandi dimensioni, costosi, scarsamente
prestazionali e poco scalabili.

Figura 3.13: Dettaglio della Switching Matrix

WDM Demux
Questo componente Click! emula un dispositivo ottico passivo in grado di
scindere un segnale ottico WDM nelle sue componenti per lunghezza d'onda.
A livello di potenza l'elemento è impostato per attenuare il segnale secondo la
formula ideale:

attenuazione = 1, 2log2 W

dove W indica il numero di lunghezze d'onda componenti la bra.

Fiber Delay Line (FDL)
Questo componente Click! emula un dispositivo ottico in grado di ritardare
la luce in esso intrappolata per un valore determinato di tempo. L'uso di tali
componenti permette di ovviare al problema della mancanza di dispositivi di
memorizzazione com le RAM in ambiente elettronico.


Figura 3.14: WDM Demultiplexer

Figura 3.15: Fiber Delay Line

Converter
Questo componente rappresenta uno stadio per la conversione della lunghezza
d'onda dei pacchetti, basata su convertitori di tipo Fixed-input Tunable-output
Wavelength Converter (FTWC) che permette di incrementare le performance
in termini di packet loss risolvendo le contese. Quando due o più pacchetti
contendono per la stessa bra di uscita sulla stessa lunghezza d'onda, uno è
inoltrato direttamente mentre gli altri sono convertiti su un'altra lunghezza
d'onda libera.

Figura 3.16: Tunable Wavelength Converter

Splitter
Questo componente emula un dispositivo ottico in grado di replicare l'ingresso
su un numero variabile di uscite. Questa replicazione introduce però una at-
tenuazione del segnale proporzionale al numero di porte in uscita di un valore
logaritmico. A livello di potenza dunque l'elemento è impostato per attenuare
il segnale secondo la formula ideale:


3.7. Data Plane 57

dove N indica il numero di bre su cui il segnale è replicato.

Semiconductor Optical Amplier (SOA)
Questo componente emula un Semiconductor Optical Amplier (SOA) ovvero
un dispositivo ottico in grado di comportarsi come un interruttore, quindi
permettendo o meno alla luce di attraversarlo, e in caso positivo è anche in
grado di amplicare, o meglio equalizzare, il segnale nel suo parametro di
potenza.

WDMMultiplexer
Questo componente Click! emula un dispositivo ottico in grado di mutiplexare
mediante tecnica WDM diverse lunghezze d'onda su un unica bra. A livello
di potenza l'elemento è impostato per attenuare il segnale secondo la formula
ideale:

attenuazione = 1, 2log2 W

dove W indica il numero di lunghezze d'onda componenti la bra.

Figura 3.17: WDM Multiplexer

Combiner
Questo componente, complementare allo Splitter, emula un dispositivo ottico
in grado di unire un numero variabile di ingressi su un unica uscita. Questa
riduzione introduce però una attenuazione del segnale proporzionale al numero
di porte in ingresso di un valore logaritmico. A livello di potenza dunque
l'elemento è impostato per attenuare il segnale secondo la formula ideale:


dove N indica il numero di bre su cui il segnale è replicato.


3.7.6 EOConverter
Questo elemento emula la conversione del nuovo header dal dominio elettronico
di controllo al dominio ottico del piano dati.

3.7.7 NewHeader o NH
Qui viene eettuata l'operazione di giunzione tra il payload che ha attravesato
la matrice di commutazione e il nuovo header, riconvertito nel dominio ottico.
Il nuovo pacchetto ottico è quindi pronto ad uscire dal nodo.

3.7.8 Output Fiber (OF)
Questo elemento modella la bra di uscita. Al suo interno è presente un
contatore in grado di fornire i risultati statistici in fase di valutazione della
architettura.

3.8 Comportamento del modello
3.8.1 Analisi dei punti di contesa
La matrice così strutturata presenta due punti di contesa, ovvero dove pacchet-
ti che viaggiano sulla stessa lunghezza d'onda contendono per la stessa bra
di uscita allo stesso istante. Il primo punto è in uscita dai convertitori TWC
dedicati alla stessa bra in ingresso. Infatti due pacchetti che provengono dalla
stessa bra in ingresso non possono essere convertiti alla stessa lunghezza d'on-
da in uscita dai TWC anche se sono diretti a bre in uscita dierenti. Questo
è dovuto allo stadio di multiplexing/combiner a valle dei convertitori. Il secon-
do punto di contesa è sulle bre di uscita dove la stessa lunghezza d'onda non
può essere usata più di una volta nella stessa bra. Quindi un pacchetto può
essere inoltrato su una lunghezza d'onda W se e solo se la lunghezza d'onda
è disponibile in uscita al gruppo di TWC della bra di input del pacchetto e
sulla sua bra di output. Queste condizioni saranno tenute in conto in fase di
progettazione degli algoritmi software di forwarding del nostro modello. Il FM
quindi manipola e gestisce la matrice tenendo conto di queste contese.

3.8.2 Analisi del traco attraverso il nodo
Osserviamo ora in dettaglio come si comporta il traco quando attraversa il
nodo, cercando di dare una visione d'insieme delle tempistiche e dei ruoli dei

3.8. Comportamento del modello 59

componenti presentati nora. Per semplicità analizziamo cosa accade all'inter-
no del nodo ad ogni singolo timeslot, durante il quale si possono presentare al
massimo W pacchetti in ingresso per ogni bra, per un totale di M*W (ovvero il
numero di bre ottiche in ingresso al nodo moltiplicato per il numero lunghezze
d'onda di ognuna). Nel nostro caso abbiamo dimensionato il nodo in modo
da avere M = 2 bre di ingresso, su ognuna delle quali sono disponibili W
= 4 lunghezze d'onda per un massimo totale di M*W = 8 possibili possibili
pacchetti presenti in ingresso al nodo per ogni timeslot. Concentriamoci ora
sul primo di questi pacchetti, che giunge in ingresso al modello, in modo da
descrivere i principali passi svolti dal modello realizzato. Innanzitutto, quando
il traco viene preso in gestione dal modello realizzato mediante Click! non
viaggia direttamente all'interno della congurazione. Infatti al suo posto viene
creato un pacchetto Click! formato da un puntatore al pacchetto dati reale
in ingresso, da una serie di annotazioni e da altri dati utili al processamen-
to. E' proprio questo a viaggiare all'interno della congurazione e a subire il
processamento secondo le operazioni previste dal modello.
Ricevendo dunque i dati da una socket UDP, propria per ogni bra,ed in
particolare per ogni lunghezza d'onda, si eettua la creazione di un pacchet-
to Click! che punti al datagramma UDP ricevuto come mostrato in gura
3.19. Il pacchetto Click! viene caratterizzato nelle annotazioni dall'elemento
composto InputFiber. Questo elemento infatti memorizza nelle annotazioni la
bra di input dalla quale proviene il pacchetto, la sua lunghezza d'onda e la
sua dimensione. Successivamente calcola poi un valore casuale di potenza da
attribuire al segnale per la caratterizzazione del comporamento in potenza del
nodo.
A questo punto il pacchetto Click! relativo al datagram packet UDP arri-
va al componente HeaderTap. Qui i dati ricevuti devono essere separati nelle
due componenti di header e payload ottico rispettivamente. Per far questo
l'HeaderTap duplica il pacchetto Click! che punta ai dati reali, cancellando
dalla prima istanza i dati relativi al payload e nella seconda quelli relativi all'-
header e alle guard band. Il payload entrerà in ingresso alla SwitchingMatrix,
dove in base alla lunghezza d'onda e alla bra di ingresso di provenienza viene
posto in attesa nella Fiber Delay Line (FDL) ad esso associato. L'header in-
vece viene convertito dal dominio ottico al dominio elettronico dall'apposito
elemento OEConverter per essere letto e processato dai dispositivi del piano di
controllo per il suo instradamento. Mentre il payload attende nella FDL per un
tempo consono al processamento elettronico dell'header, questo entra in coda
al Control Element (CE) come mostrato in gura 3.20. Se il Click! non ha in
ingreso dalla bra un altro pacchetto allora il CE estrae dalla coda degli head-
ers, secondo logica First-In First-Out (FIFO), il primo header da processare.


Figura 3.18: Schema generale di funzionamento


Figura 3.19: Prima fase del processamento dei pacchetti.

Il CE controlla se il pacchetto che sta processando fa parte del timestamp di
riferimento o se fa parte di un nuovo timestamp. Se il pacchetto fa parte di
un nuovo timestamp allora l'annotazione relativa del pacchetto Click! viene
impostata ad 1, in modo da segnalare al Forwarding Module (FM) la necessità
di resettare la matrice per il nuovo timeslot. A questo punto il CE legge le
necessità del traco in termini di qualità richiesta, lo elabora secondo delle
direttive (ad esempio se riconosce una label denita come prioritaria ne accor-
da le richieste) e imposta il risultato di questa elaborazione come informazione
sulla necessità del traco da passare al Forwarding Element (FE).

Figura 3.20: Seconda fase del processamento dei pacchetti.

Il pacchetto contenente l'header e pronto al processamento di inoltro viene


dunque passato al componente FE mostrato in gura 3.21. All'interno di
questo modulo, vi sono diversi sotto-elementi ognuno con un ruolo particolare.
Il primo elemento che il pacchetto incontra è denominato Label Lookup (LL).

Figura 3.21: Terza fase del processamento dei pacchetti.

In questo elemento viene letta la destination label dall'header ottico nel
campo dati del pacchetto Click! . Questa label, secondo il modello base del pro-
tocollo Generalized Multi-Protocol Label Switching (GMPLS) è confrontata
all'interno di una struttura dati interna indicata come Forwarding Table (FT).
Questa tabella si compone, in questa prima versione molto semplicata, di tre
colonne. La prima colonna è la colonna di ricerca della destination label letta,
la seconda indica la nuova destination label e la terza indica quale interfaccia
di uscita consente di raggiungerla. Le informazioni della seconda e terza colon-
na vengono dunque scritte dal LL nelle annotazioni del pacchetto, per un uso
futuro. Il secondo componente che l'header attraversa è denito come FESim-
pleScheduler il quale impementa un semplice algoritmo per lo scheduling dei
pacchetti all'interno del nodo mostrato sotto:
0 1 : i f ( s c h e d u l e == 0 ) {
02: i f ( out c o u n t e r [ n ] W) {
03: s e l e c t main FM( need ) ;
04: send r e q u e s t t o FM( n , w,m) ; }
05: else {
06: droppacket / flow ;}}
0 7 : i f ( s c h e d u l e == 1 ) {
08: out c o u n t e r [ n]++;}
0 9 : i f s c h e d u l e==2 {
10: i f ( a l t e r n a t i v e FM == t r u e ) {
11: s e l e c t a l t e r n a t i v e FM( need ) ;
12: send r e q u e s t t o FM( n , w,m) ; }
13: else {
14: droppacket / flow ;}}


A questo punto l'header ottico entra nel terzo ed ultimo componente del FE,
il Label Swap (LS). Al suo interno vengono lette le informazioni riguardanti
la nuova destination label e l'interfaccia di uscita del nodo ad essa relativa.
La nuova destination label viene dunque scritta in quello che diventa da ora
il nuovo header ottico del pacchetto. In base alle informazioni inserite dal
CE sulle necessità del traco elaborate poi dall'algoritmo di scheduling del
FE si decide quindi a questo punto verso quale FM inoltrare la richiesta per
il corrente pacchetto. Come accennato nella corrente implementazione viene
fornita soluzione per il traco di tipo OPS.

Figura 3.22: Quarta fase del processamento dei pacchetti.

All'interno del Forwarding Module (FM), come mostrato dalla gura 3.22 il
nuovo header ottico attraversa il primo elemento denominato FMSimpleSched-
uler. Tale elemento impementa un semplice pseudo codice per lo scheduling
dei pacchetti all'interno del nodo applicando in questo caso una conoscenza
esplicita sull'hardware a disposizione per gestire e risolvere eventuali contese
nel traco. In particolare all'interno dello scheduler si esegue lo pseudo codice
sottostante, ricordando che a questo punto si ha completa visione dell'hard-
ware della matrice di commutazione e si può eettuare un controllo mirato alla
disponibilità dei componenti che la implementano:
01: found =0;
02: k i n i t =0;
03: end s c a n =0;
04: while ( found == 0 end s c a n == 0 ) {
05: i f (OF av [ n ] [ k ] == 0 WC av [m] [ k ] == 0 ) {
06: found =1;
07: OF av [ n ] [ k ] = 1 ;
08: WC av [m] [ k ] = 1 ; }
09: else {
10: k =(k+1)% W;
11: i f k == k i n i t [ n ] {
12: end s c a n =1;}}}


1 3 : i f ( found==0) {
14: s c h e d u l e =2;
15: send f e e d b a c k t o FE( s c h e d u l ) ; }
16: else {
17: s e t d e v i c e s ( n , k ,m) ;
18: s c h e d u l e =1;
19: send f e e d b a c k t o FE( s c h e d u l ) ; }

Quindi se il pacchetto da inoltrare non genera contese o è possibile risol-
vere queste allocando il pacchetto su una dierente lunghezza d'onda allora
è possibile inoltrarlo altrimenti è necessario scartarlo o richiedere un ulteriore
soluzione (magari attraverso un FM alternativo mediante l'FE). In entram-
bi i casi dunque si deve segnalare al FE l'esito dello scheduling da parte del
FM e questa operazione è visibile con l'arco di retroazione dal FM al FE che
simula la linea di scambio delle informazioni del piano di controllo. Nel caso
non riesco ad inoltrare il pacchetto allora segnalo al FE l'esito schedule ==
2 altrimenti se riesco nell'operazione segnalo come schedule == 1 e inoltro il
nuovo header verso gli elementi di script per l'attuazione dei componenti della
matrice per la risoluzione del percorso di inoltro. Il nuovo header, ancora nel
FM, viene sottoposto ad un test sul timeslot di appartenenza. In caso l'head-
er appartenga, e quindi sia il primo di un nuovo timeslot, allora si decide di
eseguire lo script denominato NewTimeslotScript. Questo elemento permette
di ripristinare la matrice nei suoi componenti elementari allo stato iniziale,
ovvero con i convertitori e i SOA relativi disabilitati. In questa congurazione
dunque il traco non può raggiungere le uscite se non completamente schedu-
lato. Altrimenti o successivamente a tale passo il nuovo header accede allo
script denominato FMScript. Questo è il vero attuatore delle computazioni di
scheduling. Attraverso questo componente posso attivare il convertitore neces-
sario, alla lunghezza d'onda voluta e il relativo SOA di destinazione del traco
per ogni header che lo attraversa.
A questo punto come mostrato in gura 3.24 il nuovo header attraversa il
convertitore EOConverter che emula la conversione delle informazioni dal do-
minio elettronico a quello ottico per poi giungere nel componente NewHeader.
Qui verrà riunito al payload che attraverserà la matrice allo scadere dell'attesa
nella FDL sul piano ottico. Il pacchetto così rigenerato sarà portato in uscita
verso la output ber di destinazione secondo l'algoritmo di scheduling. Inne
tutti questi passi si ripetono per ogni nuovo pacchetto in ingresso al nodo e
per ogni timeslot elaborato dalla rete.


Figura 3.23: La matrice di commutazione in dettaglio


Figura 3.24: Ultima fase del processamento dei pacchetti.

Capitolo 4

Test e valutazioni sul modello

Il test di un programma può
essere usato per mostrare la
presenza di bug, ma mai per
mostrare la loro assenza.

Edsger Wybe Dijkstra,
informatico olandese.
(1930 - 2002)

In questo capitolo esporremo in breve il lavoro di congurazione di una
piattaforma hardware dedicata, allestita nel laboratorio del dipartimento. In-
oltre forniremo i dati sperimentali dell'esecuzione del modello di router ot-
tico per confrontarne i risultati con dei valori di riferimento provenienti da
congurazioni analoghe, testate all'interno di un simulatore.

4.1 La piattaforma hardware di test
Al ne di valutare le prestazioni del modello si è deciso di allestire una piccola
congurazione hardware in grado di operare in modo dedicato come emula-
tore di nodo ottico. A tale scopo sono state approntate in laboratorio tre
macchine, congurate per eseguire ognuna la congurazione scelta. In futuro
queste macchine saranno inteconnesse secondo uno schema il quale prevede
che due di questi calcolatori siano dedicati alla generazione del traco in in-
gresso al nodo (mediante una distribuzione bernoulliana di probabilità) mentre
sulla restante macchina verrà posta in esecuzione una specica congurazione
del router ottico al ne di raccoglierne i risultati. Un resoconto dettagliato
della fase di installazione e set-up della architettura allestita in laboratorio è
presente in appendice B.3.1.

68 Test e valutazioni sul modello

4.1.1 La distribuzione del traco
Per fornire dati attendibili, valutare l'architettura proposta e il modello im-
plementato occorre fornire in ingresso un traco dati simile, o quantomeno
comparabile, al traco reale che viene generato in una rete di questo tipo.
Per raggiungere tale scopo, la generazione dei pacchetti viene basata su una
distribuzione bernulliana di probabilità. Secondo questa funzione, una volta
impostato un valore q, che indica la probabilità di generare con successo un
pacchetto, durante la fase di creazione questo viene eettivamente generato se,
preso come riferimento un numero pseudo-casuale calcolato, questo è minore
della probabilità q, altrimenti, quindi con probabilità 1 - q il pacchetto non
viene generato come mostrato in gura 4.1.

Figura 4.1: Distribuzione bernoulliana con q = 0.8

Come generatore di traco si è ricorso alla scrittura di un programma in
linguaggio C (bernoulligen.c) appositamente creato per la valutazione delle
prestazioni. Questo programma è in grado di generare pacchetti secondo la
distribuzione bernulliana sopra citata, ed è in grado di ricevere da linea di
comando una serie di parametri variabili per la generazione del traco. A
livello funzionale il programma denisce una connessione di rete mediante una
datagram socket UDP e genera su di questa pacchetti in accordo al valore di
probabilità impostato. Il programma consente inoltre di passare una serie di
parametri utili ai ni della caratterizzazione del traco generato. Ad esempio
oltre ai dati per la creazione della socket, ovvero l'indirizzo IP e la porta UDP,
e il valore della distribuzione di probabilità q, è possibile impostare il seme
(seed ) per la generazione dei valori pseudo-casuali, la durata in millisecondi
del timeslot, il numero di timeslot da generare, la dimensione del payload e
dell'header dei pacchetti creati e il numero di labels di destinazione da generare.

4.2. Le prestazioni misurate 69

4.2 Le prestazioni misurate
Le misurazioni eettuate nei vari test mirano a vagliare la probabilità di perdita
dei pacchetti, in relazione ad una determinata congurazione del nodo (inter-
facce di ingresso, di uscita, numero di lunghezze d'onda per canale, . . . ) e per
un determinato fattore di carico relativo al traco in ingresso oltre ad una
misurazione dei tempi di processamento e scheduling in modo da determinare
le tempistiche di emulazione della architettura.

4.2.1 Packet Loss Probability (PLP)
Questo valore indica la probabilità di perdita dei pacchetti, espressa come risul-
tato della dierenza tra i pacchetti in ingresso e quelli eettivamente inoltrati
dal nodo sul totale dei pacchetti in ingresso. Questo rapporto è espresso dalla
formula:
pacchetti_entrati − pacchetti_usciti
P LP =
pacchetti_entrati

Ovviamente, minore è questo valore migliori sono le prestazioni del nodo
(e quindi della sua architettura e del suo algoritmo di scheduling, rispettiva-
mente). Variazioni del numero di ingressi, uscite, numero di lunghezze d'onda
del canale, così come delle possibili implementazioni di algoritmi di scheduling
dierenti sono tutti fattori che inuenzano il valore espresso dalla PLP. Scopo
dei test sarà esporre tali dierenze al variare dei suddetti fattori per eviden-
ziare quali soluzioni architetturali, in termini di prestazioni, risultano essere
più ecaci.

4.2.2 Tempo di processamento elettronico
Uno dei limiti in cui ci si è imbattuti nella realizzazione del modello sono stati
i tempi di emulazione del singolo timeslot. Queste tempistiche sono risultate
essere molto alte e non comparabili ai livelli di una equivalente simulazione. I
fattori di questa limitazione sono stati individuati e aprono la strada a future
e migliori implementazioni. Forniamo ora una serie di fattori che secondo l'au-
tore inuenzano queste tempistiche e alcune soluzioni applicabili nella futura
evoluzione del modello.

Esecuzione in ambiente userlevel
Uno dei fattori che inuenzano le tempistiche è l'esecuzione della congurazione
Click! in ambiente userlevel. In questa modalità infatti è il sistema operativo


che assegna risorse e tempistiche al Click! e, a fronte di richieste da parte di
altri programmi, queste vengono ripartite piu o meno equamente. Nelle prove
eettuate si è tenuto conto di questo dedicando il sistema all'esecuzione della
congurazione Click! , disabilitando l'interfaccia graca e i servizi superui, ma
una esecuzione a livello kernel comporterebbe sicuramente migliori prestazioni,
riducendo la tempistica di esecuzione del singolo timeslot.

Scrittura a video e su le
Un altro dei fattori rilevanti è l'output a video e su le dei risultati. L'accesso
al video così come alla RAM o al disco rallentano notevolmente l'esecuzione. Si
è così ridotto al minimo la produzione di messagi di testo, ma una soluzione di
immagazzinamento delle informazioni all'interno di variabili di processo, river-
sate su le o disco alla ne della emulazione, incrementerebbe ulteriormente le
prestazioni.

Esecuzione degli script FM
Questo è forse il fattore macroscopico delle tempistiche del processamento elet-
tronico degli header. Per impostare e resettare i dispositivi di commutazione
(ad esempio WC, SOA, . . . ) della SM si è ricorsi all'uso di codice script in
linguaggio Click! . Se pur comodi come strumento, questi script usano codice
a livello applicativo, obbligando il processo a risalire no all'interpretazione
dello stesso per poi tornare ad eseguire codice compilato. Empiricamente si è
trovato che mentre l'attraversamento di un pacchetto attraverso un semplice
componente Click! , composto dal solo codice C++, è nell'ordine dei 0,0001
secondi, lo stesso attraversamento del componente FM contenente gli script
di attuazione e reset, impiega un ordine di grandezza superiore facendo au-
mentare così notevolmente il tempo di emulazione del processamento elettron-
co. Soluzione proposta, anche tra gli sviluppi futuri, è quella di implementare
tali script direttamente nel codice C++ del componente FM.

Sequenzializzazione del Click!
Ultimo vincolo alle tempistiche di processamento è la sequenzializzazione im-
posta ai pacchetti in ingresso al router. Prima di poter processare un pacchet-
to infatti occorre che il precedente sia già stato elaborato o inserito in attesa
in una coda. Una possibile soluzione è emersa recentemente nella mailing
list del Click! dove si prospettava la possibilità di implementazione a livello
multithread del motore di elaborazione delle congurazioni.

4.3. Test e risultati 71

4.3 Test e risultati
4.3.1 Lo script di lancio dei test
Nei test di valutazione, l'esecuzione della congurazione Click! relativa, e del
programma generatore di traco è stata adata ad un particolare script bash.
Questo le (identicato dalla dicitura bernoulligenerator_real_trac.sh) per-
mette di mandare in esecuzione una particolare congurazione Click! e, su-
cessivamente, creare tante istanze del programma di generazione dei pacchetti
quante sono le interfacce di ingresso del nodo, ed in particolare quante sono le
lunghezze d'onda per ognuna di esse. Inoltre è possibile impostare mediante lo
script un determinato range di valori di carico su cui reiterare le simulazioni.
In questo modo, l'output generato dalla congurazione Click! posta in as-
colto, verrà rediretto su dei le di testo (output_NxN_w_q.txt) distinti per
ogni congurazione e per ogni valore di carico. Analizzando questi le è pos-
sibile estrapolare le informazioni rigurdanti i contatori dei pacchetti generati,
scartati (sia dal FE che dal FM) e quindi la loro dierenza ai ni di poter cal-
colare la PLP e le prestazioni della congurazione per un determinato fattore
di carico.

4.3.2 Test I
Per il primo test di valutazione del modello si è denita una congurazione
Click! con M = 2 bre in ingresso e N = 2 bre in uscita, ognuna con a
disposizione W = 4 lunghezze d'onda. Generando quindi un numero ssato di
timeslot con valori di carico q variabili per un traco a distribuzione bernoul-
liana, siamo riusciti ad ottenere vari riferimenti in termini di pacchetti inoltrati
o persi a fronte dei diversi valori di carico. Inoltre è stato possibile intercettare
i punti di perdita all'interno dell'algoritmo di scheduling fornendo un impor-
tante misura per le prestazioni dello stesso. Infatti vi può essere perdita in
base alla non disponibilità di interfacce di uscita (controllo ad opera del FE) o
di lunghezze d'onda (controllo ad opera del FM) il che varia la probabilità che
si verichino delle contese, risolvibili o meno da parte dello scheduler. Mos-
triamo ora dapprima in forma tabellare e successivamente gracati i risultati
ottenuti mediante simulazione prima e l'emulazione del modello implementato
poi.

I risultati della simulazione
Al ne di avere un termine di paragone che validasse la correttezza del modello
emulato si è deciso di produrre alcune simulazioni in modo da avere un riscontro


in termini di probabilità di perdita dei pacchetti rispetto ad un determinato
carico.

Test I - Simulazione:
Input bers: 2
Output bers: 2
Wavelengths per ber: 4
Emulated number of packets: 100.000
Packet Loss Probability (q=0.9): 0,1022240000

Tabella 4.1: Risultati Test I - Simulazione

Come si evince dalla tabella 4.1 sono riportati i valori di PLP per deter-
minati fattori di carico sulla generazione totale dei pacchetti. Ci aspettiamo
dunque che la congurazione emulata restituisca dei risultati concordi con
la simulazione al ne di valutarne l'eettiva funzionalità, a fronte di un più
complesso e dettagliato meccanismo di implementazione del modello.

I risultati dell'emulazione
tab:RisultatiTestIIbSimulazione

Test I - Emulazione:
Input bers: 2
Output bers: 2
Emulated number of timeslot: 16.000

Tabella 4.2: Risultati Test I - Emulazione


Come ci aspettavamo, i risultati forniti dalla emulazione sono comparabili
sia in termini di ordine di grandezza sia in valore con i risultati della simu-
lazione. Per una migliore chiarezza vediamo ora di gracare questi dati per
confrontarli e far emergere i risultati attesi.

Confronto
Sovrapponendo i graci ottenuti mediante interpolazione dei dati della emu-
lazione e della simulazione si ottiene il graco mostrato in gura 4.2.

Figura 4.2: Confronto delle curve di simulazione ed emulazione per il TestI

I due modelli coincidono in termini di prestazioni e PLP per i diversi fat-
tori di carico espressi, come atteso. I valori della simulazioni sono gracati
sotto forma di linea continua mentre i valori della emulazione sono presenti
sotto forma di punti. Alcuni discostamenti, soprattutto nella parte sinistra del
graco sono dovuti al fatto che, tenendo sso il numero di timeslot, si produce
un quantitativo minore di pacchetti per valori di carico più bassi e quindi il
risultato tende a non essere preciso in quanto calcolato su un minor numero di
pacchetti. Una volta comprovata la sostanziale eguaglianza dei risultati e la
funzionalità del modello la dierenza sostanziale rimane nel fatto che, mentre
nella simulazione ci limitiamo a generare via codice gli algoritmi di scheduling
di una architettura, nella emulazione riproduciamo l'intero processamento del
traco nel nodo, interpretando ogni singolo componente, realizzando così un
modello più complesso e dettagliato della tecnologia reale.


4.3.3 Test IIa
Per il secondo test di valutazione del modello, si è denita una congurazione
Click! con M = 4 bre in ingresso e N = 4 bre in uscita ognuna con a
disposizione, in questa prima variante del TestII W = 4 lunghezze d'onda.
Generando quindi un numero ssato di timeslot con valori di carico q vari-
abili per un traco a distribuzione bernoulliana, siamo riusciti ad ottenere
vari riferimenti in termini di pacchetti inoltrati e pacchetti persi a fronte di
diversi valori di carico. Inoltre è stato possibile intercettare i punti di perdita
all'interno dell'algoritmo di scheduling fornendo un importante misura per le
prestazioni dello stesso. Infatti vi può essere perdita in base alla non disponi-
bilità di interfacce di uscita (controllo ad opera del FE) o di lunghezze d'onda
(controllo ad opera del FM) il che varia la probabilità che si verichino delle
contese, risolvibili o meno da parte dello scheduler. Mostriamo ora dappri-
ma in forma tabellare e successivamente gracati i risultati ottenuti mediante
simulazione prima ed emulazione del modello implementato poi.

Al ne di avere un termine di paragone che validasse la correttezza del mod-
ello sviluppato si è deciso di produrre alcune simulazioni in modo da avere
un riscontro in termini di probabilità di perdita di pacchetti rispetto ad un
determinato carico.

Test IIa - Simulazione:
Input bers: 4
Output bers: 4
Tabella 4.3: Risultati Test IIa - Simulazione




I risultati analoghi per l'emulazione sono visibili nella tabella 4.4.

Test IIa - Emulazione:
Input bers: 4
Output bers: 4
Tabella 4.4: Risultati Test IIa - Emulazione


4.3.4 Test IIb
Per il secondo test di valutazione del modello, si è denita una congurazione
Click! con M = 4 bre in ingresso e N = 4 bre in uscita ognuna con a
disposizione, in questa seconda variante del TestII W = 8 lunghezze d'onda.
Generando quindi un numero ssato di timeslot con valori di carico q variabili,
per un traco a distribuzione bernoulliana siamo riusciti ad ottenere vari rifer-
imenti in termini di pacchetti inoltrati e pacchetti persi a fronte di diversi valori
di carico. Inoltre è stato possibile intercettare i punti di perdita all'interno del-
l'algoritmo di scheduling fornendo un importante misura per le prestazioni di
tale algoritmo. Infatti vi può essere perdita in base alla non disponibilità di
interfacce di uscita (controllo ad opera del FE) o di lunghezze d'onda (control-
lo ad opera del FM) il che varia la probabilità che si verichino delle contese,
risolvibili o meno da parte dello scheduler. Mostriamo ora dapprima in forma


tabellare e successivamente gracati i risultati ottenuti mediante simulazione
prima ed emulazione del modello implementato poi.

determinato carico.
Test IIb - Simulazione:
Input bers: 4
Output bers: 4
Tabella 4.5: Risultati Test IIb - Simulazione



Confronto
Per la prima variante, sovrapponendo i graci ottenuti mediante interpolazione
dei dati della emulazione e della simulazione si ottiene il graco mostrato in
gura 4.3.


Test IIb - Emulazione:
Input bers: 4
Output bers: 4
Tabella 4.6: Risultati Test IIb - Emulazione

Figura 4.3: Confronto delle curve di simulazione ed emulazione per il TestIIa


Come si evince dal graco, i due modelli coincidono in termini di prestazioni
e PLP per i diversi fattori di carico espressi, come atteso. I valori della sim-
ulazioni sono estressi sotto forma di linea continua mentre i valori della emu-
lazione sono espressi sotto forma di punti. Alcuni discostamenti, soprattutto
nella parte sono dovuti al fatto che tenendo sso il numero di timeslot si pro-
duce un quantitativo minore di pacchetti per valori di carico più bassi e quindi
il risultato tende a non essere preciso in quanto calcolato su un minor numero
di pacchetti.
Per la seconda variante, anche qui sovrapponendo i graci ottenuti medi-
ante interpolazione dei dati della emulazione e della simulazione si ottiene il
graco mostrato in gura 4.4.

Figura 4.4: Confronto delle curve di simulazione ed emulazione per il TestIIb

il risultato tende a non essere preciso in quanto calcolato su un minor numero
di pacchetti. Come già detto la dierenza sostanziale rimane nel fatto che
mentre nella simulazione ci limitiamo a generare via codice gli algoritmi di
scheduling di una architettura nella emulazione riproduciamo l'intero proces-
samento del traco nel nodo, emulando ogni singolo componente, realizzando
così un modello più complesso e dettagliato della tecnologia reale.


Andiamo ora a sovrapporre le curve ottenute per il TestII al variare del
numeo di lunghezze d'onda disponibili, W = 4 nel caso del TestIIa e W = 8
nel caso del TestIIb. I risultati gracati sono visibili in gura 4.5.

Figura 4.5: Confronto delle curve di simulazione ed emulazione dei TestIIa e b

Come emerge dal graco all'aumentare del numero di lunghezze d'onda
disponibili per canale, diminuisce la probabilità di perdita, soprattutto ai bassi
carichi come evidenziato dall'allontanamento delle due curve per valori prossi-
mi allo zero del carico. Questo comportamento è corretto in quanto con un
maggior numero W di lunghezze d'onda disponibili è possibile trovare soluzione
a più situazioni di contese rispetto ad un valore di W inferiore, da qui risultati
di probabilità di perdita più bassi.

4.3.5 Test III
Per il terzo ed ultimo test di valutazione del modello, si è denita una cong-
urazione Click! con M = 8 bre in ingresso e N = 8 bre in uscita ognuna
con a disposizione W = 4 lunghezze d'onda. Generando quindi un numero
ssato di timeslot con valori di carico q variabili per un traco a distribuzione
bernoulliana, siamo riusciti ad ottenere vari riferimenti in termini di pacchetti
inoltrati e pacchetti persi a fronte di diversi valori di carico. Inoltre è stato
possibile intercettare i punti di perdita all'interno dell'algoritmo di scheduling
fornendo un importante misura per le prestazioni dello stesso. Infatti vi può
essere perdita in base alla non disponibilità di interfacce di uscita (controllo ad
opera del FE) o di lunghezze d'onda (controllo ad opera del FM) il che varia


la probabilità che si verichino delle contese, risolvibili o meno da parte dello
scheduler. Mostriamo ora dapprima in forma tabellare e successivamente gra-
cati i risultati ottenuti mediante simulazione prima ed emulazione del modello
implementato poi.

determinato carico.

Test III - Simulazione:
Input bers: 8
Output bers: 8
Tabella 4.7: Risultati Test III - Simulazione

la simulazione al ne di valutarne la eettiva funzionalità, a fronte di più



Test III - Emulazione:
Input bers: 8
Output bers: 8
Tabella 4.8: Risultati Test III - Emulazione

Confronto
Sovrapponendo i graci ottenuti mediante interpolazione dei dati della emu-
lazione e della simulazione si ottiene il graco mostrato in gura 4.6.

Figura 4.6: Confronto delle curve di simulazione ed emulazione per il TestIII



il risultato tende a non essere preciso in quanto calcolato su un minor nu-
mero di pacchetti. Una volta comprovata dalla comparazione dei risultati la
funzionalità del modello la dierenza sostanziale rimane nel fatto che mentre
nella simulazione ci limitiamo a generare via codice gli algoritmi di schedul-
ing di una architettura nella emulazione riproduciamo l'intero processamento
del traco nel nodo, emulando ogni singolo componente, realizzando così un
modello più complesso e dettagliato della tecnologia reale.

4.4 Confronto sui test di valutazione
Sovrapponendo ora i graci ottenuti da tutti i test svolti, mediante l'interpo-
lazione dei dati delle emulazioni e delle simulazioni si ottiene il graco mostrato
in gura 4.7.

Figura 4.7: Confronto delle curve di simulazione ed emulazione per i test

Come visibile le varie congurazioni presentano prestazioni di perdita dif-
ferenti dovute alla variazione del numero di ingressi, del numero delle uscite
e del numero di lunghezze d'onda disponibili per canale oltre che ovviamente
per i valori di carico del traco generato. Abbiamo già espresso particolare
interesse per le curve dei test IIa e IIb in cui viene mostrato come, per lo stesso
numero di ingressi e uscite, al variare delle lunghezze d'onda disponibili varia
anche la PLP avendo lo scheduler a disposizione più soluzioni per risolvere le

4.4. Confronto sui test di valutazione 83

contese. Possiamo quindi mostrare come la probabilità di perdita aumenta al
crescere del numero delle interfacce di ingresso presenti nel nodo. Le curve delle
emulazioni dei test I, IIa e III evidenziano come la perdita cresca al crescere
di M ma al tempo stesso si attesti più o meno asintoticamente sopra un certo
valore. Mentre la dierenza tra la congurazione con M = 2 e M = 8 è più
marcata, questa si riduce tra M = 4 e M = 8 e tenderà a ridursi ancora tra M
= 8 ed un ipotetica congurazione M = 16 o M = 32.

Conclusioni

Per aspera sic itur ad astra.

Seneca, losofo, politico e
drammaturgo romano.
(4 a.C. - 65)

Il completamento del lavoro di tesi ha richiesto 13 settimane di lavoro,
suddiviso in documentazione, analisi ed implementazione dei concetti oggetto
di ricerca. Osserveremo ora in dettaglio il punto di arrivo del lavoro n qui
svolto e i suoi possibili sviluppi futuri.

4.5 Risultati ottenuti
Il bilancio del lavoro vede circa 4 mesi di applicazione di cui oltre due terzi
spesi presso il Dipartimento di Elettronica, Informatica e Sistemistica (DEIS)
a stretto contatto con i ricercatori e i laureandi dedicati a questo progetto.
L'impementazione realizzata è conforme nelle speciche alle direttive ForCES
e rispecchia i valori di PLP dei modelli più semplici di simulazione. Essa cos-
tituisce quindi una piattaforma di lavoro modulare e estremamente estendibile
in vari aspetti.

4.6 Sviluppi futuri
4.6.1 Riduzione delle tempistiche di emulazione
Uno dei primi sviluppi da curare sarà probabilmente la riduzione delle tem-
pistiche delle emulazioni. Come espresso nel capitolo dedicato ai test, alcuni
fattori sono stati evidenziati e alcune soluzioni proposte.

86 Conclusioni

4.6.2 Implementazione della multi-granularità
Il modello potrà poi essere in futuro esteso nei rimanenti paradigmi OCS e OBS
rendendo completa l'architettura nella sua accezione multi-granulare. Questo
comporterà la denizione di nuovi elementi di scheduling che prevedano ques-
ta possibilità e gestiscano opportunamente le informazioni provenienti dagli
elementi di controllo di queste modalità.

4.6.3 Implementazione di un modello reale del consumo
di potenza
Un aspetto interessante, in accordo anche con la tendenza del settore in questi
ultimi mesi, è quello di poter monitorare i livelli di potenza e consumo all'inter-
no del router. Una prima, seppur elementare, implementazione è già disponi-
bile come visto in precedenza, ma si potrebbe estenderla al ne di emulare
concretamente i valori in gioco in un dispositivo reale e restituire informazioni
utili sul consumo di potenza al variare delle architetture e degli algoritmi di
scheduling.

4.7 Un pò di numeri
• 25.700.000 circa le pagine riguardanti le reti ottiche.

• 355.000 circa le pagine riguardanti OPS.

• 85.400 circa le pagine riguardanti Click! .

• 600 ore circa di lavoro su 13 settimane.

• 300 circa le pagine di documentazione varia stampate.

• 200 ed oltre le pagine web visitate, di cui il 95% in lingua inglese.

• 120 circa le pagine scritte per la tesi.

• 80 i bookmark collezionati nel corso del progetto.

• 2 i forum frequentemente visitati.

• 3 le macchine usate.

Appendice A

Appendice A: Il software Click!
Modular Router

La disumanità del computer sta
nel fatto che, una volta
programmato e messo in
funzione, si comporta in maniera
perfettamente onesta.

Isaac Asimov, scrittore russo
naturalizzato statunitense.
(1920 - 1992)

In questa prima appendice presenteremo i concetti base, l'architettura e
il linguaggio della piattaforma software utilizzata nello sviluppo del nostro
modello.

A.1 Introduzione a Click!
Il Click! è una architettura software open source modulare, orientata alla
realizzazione di una vasta gamma di dispositivi come router, processori di pac-
chetti, sorgenti di traco, Ethernet switch, rewall . . . . basata su piattaforma
GNU/Linux e sviluppata dal Massachusetts Institute of Technology (MIT) è
ampiamente documentata e distribuita gratuitamente sul sito:
http://www.pdos.lcs.mit.edu/click.

88 Appendice A: Il software Click! Modular Router

Figura A.1: Logo del software Click Modular Router

A.2 Architettura
Un qualsiasi dispositivo Click! è modellato esclusivamente attraverso l'ag-
gregazione di moduli di elaborazione dei pacchetti chiamati elementi e non
esiste ulteriore astrazione per un componente (del dispositivo) oltre a questa.
Gli elementi inoltre sono collegati tra loro mediante delle linee orientate, che
rappresentano il usso dei pacchetti, dette connessioni. Ogni elemento imple-
menta semplici funzioni del router come la classicazione, l'accodamento, lo
scheduling e l'interfacciamento con i dispositivi di rete. Un insieme di elementi
connessi con più linee orientate, le connessioni, rappresenta una congurazione,
ovvero il modello del dispositivo che vogliamo simulare.

A.2.1 Elementi
Un elemento è un componente software che rappresenta un'unità di elabo-
razione del router, ed esegue concettualmente semplici calcoli, come ad esem-
pio decrementare il campo Time-to-live (TTL) di un pacchetto, piuttosto che
calcoli complessi, come il routing IP. In generale essi esaminano o modicano i
pacchetti in un certo modo. I pacchetti rappresentano le particelle elementari
della comunicazione, trasportando le informazioni di rete, che vengono elebo-
rate. Durante il funzionamento del dispositivo mappato nella congurazione
Click! i pacchetti passano da un elemento all'altro attraverso collegamenti
chiamati connessioni. Ogni elemento è un oggetto C++ che può mantenere
una sua autonomia. Dispositivi di processamento, tabelle di instradamento,
gestione delle code, conteggi e quant'altro, sono tutte funzioni implementate
dagli elementi. Gli elementi hanno cinque importanti proprietà:

1. Classe dell'elemento: specica la struttura dei dati che possono essere
trattati dall'elemento e il suo comportamento (quante porte avrà, quali
handlers supporterà e come elaborerà i pacchetti). In C++ ogni elemento
corrisponde ad una sottoclasse della struttura Element.

A.2. Architettura 89

2. Porte: Ogni elemento può avere un numero arbitrario di porte di ingres-
so e uscita. Ogni connessione collega una porta di uscita di un elemento
con una porta di entrata di un altro. Il numero di porte di un elemento
può essere sso, oppure può dipendere da una stringa di congurazione,
oppure da quante porte sono usate nella particolare congurazione. In-
fatti ogni porta che viene predisposta deve essere utilizzata da almeno
una connessione, altrimenti la congurazione è errata. Le porte possono
essere del tipo Push (il pacchetto viene fornito dall'elemento), Pull (il
pacchetto viene richiesto dall'elemento) o Agnostic (si adegua al tipo
Push o Pull della porta a cui è connessa).

3. Stringa di congurazione: La stringa di congurazione è un parametro
opzionale, che viene utilizzato per passare agli elementi gli argomenti
di congurazione durante la fase di inizializzazione della congurazione,
con lo scopo di determinarne lo stato interno e regolarne nemente il
comportamento. Dal punto di vista sintattico è costituita da una lista
di argomenti separati da virgole. La maggior parte degli argomenti di
congurazione appartengono a insiemi limitati di tipi di dati quali, ad
esempio numeri interi, o liste di indirizzi IP.

4. Modalità di interfaccia: ogni elemento esporta delle modalità di inter-
faccia a cui gli altri elementi possono accedere. Tutti gli elementi hanno
la modalità di interfaccia base, che consente di trasferire i pacchetti;
in più alcuni elementi dispongono di ulteriori interfacce. Ad esempio
l'elemento Queue che implementa una coda FIFO di pacchetti, esporta
un'interfaccia che riporta la sua lunghezza corrente.

5. Handler: gli handler sono modalità di interfaccia esportate a livello di
utente piuttosto che agli altri elementi della congurazione router. Ad
esempio l'elemento Queue menzionato prima ha un handler che riporta
la sua lunghezza corrente come una stringa ASCII decimale, mentre l'ele-
mento Counter mette a disposizione un handler che permette all'utente
di conoscere il valore corrente del suo contatore.

A.2.2 Connessioni
Ogni connessione rappresenta un percorso possibile per il trasferimento dei
pacchetti e collega una porta di uscita di un elemento con una porta di ingres-
so di un altro, ed ognuna rappresenta un possibile percorso per il trasferimento
dei pacchetti tra gli elementi. In un router in esecuzione le connessioni sono
rappresentate come puntatori agli oggetti elemento e il passaggio dei pacchetti


lungo una connessione è implementato da una singola chiamata di una fun-
zione virtuale. Gracamente le connessioni vengono rappresentate come frecce
che collegano una porta sorgente ad una porta destinazione, indicando la di-
rezione del usso di pacchetti. Ciascuna connessione collega una porta sorgente
ad una porta di destinazione. Una porta sorgente è normalmente una porta
d'uscita, mentre una porta di destinazione rappresenta una porta d'ingresso.
Nel proseguo spesso si utilizzerà la terminologia di elementi sorgenti ed ele-
menti di destinazione con il signicato ovvio. Una congurazione router può
essere pensata come un grafo orientato in cui gli elementi ne rappresentano
i vertici. Comunque è importante osservare che le connessioni collegano tra
loro le porte e non gli elementi stessi, e che ciascun elemento può avere più
porte contemporaneamente. Un modello più completo rappresenta le congu-
razioni router come un grafo orientato in cui le porte rappresentano i vertici.
Le porte presentano due tipi di connessioni, quelle ordinarie e quelle interne.
Le connessioni interne mostrano come un pacchetto può essere trasmesso da
una porta d'ingresso ad una porta d'uscita all'interno di un singolo elemento;
il collegamento esistente tra la porta d'ingresso di un elemento e la sua porta
d'uscita o, indica che un pacchetto che arriva alla porta d'ingresso i può essere
trasmesso sulla porta d'uscita o. Nel modello più semplice ogni elemento pre-
senta una rappresentazione completa dei collegamenti interni, che signica che
esistono delle linee interne che collegano ciascun ingresso ad una qualunque
uscita. Spesso però questo non sempre è corretto. Infatti, per alcune tipolo-
gie di elementi, i pacchetti che arrivano ad una determinata porta d'ingresso
possono essere trasmessi solo attraverso un insieme limitato di porte d'uscita,
o addirittura attraverso nessuna di esse. Informazioni interne più speciche,
permettono al sistema di decidere quali elementi possono essere raggiunti da
una determinata porta; in una lunga esecuzione, esse aiutano ad individuare le
proprietà di una congurazione. In generale, se esiste un percorso che collega
una porta d'uscita o con una porta d'ingresso i nella rappresentazione graca
della congurazione di un router, diremo che i è successivo ad o (downstream),
mentre al contrario, o è precedente ad i (upstream). Questa nozione può essere
generalizzata agli elementi.

A.3 Pacchetti Click
Un pacchetto Click consiste in una piccola intestazione di pacchetto e dal
reale campo dati del pacchetto IP. L'intestazione del pacchetto punta ai dati.
Molte intestazioni possono condividere lo stesso pacchetto dati. Quando si
copia un pacchetto, ad esempio tramite l'elemento Tee, Click produce una

A.4. Linguaggio 91

nuova intestazione che condivide lo stesso pacchetto dati. Gli elementi che
modicano i dati devono prima preoccuparsi che non siano condivisi da altre
intestazioni; se sono condivisi allora l'elemento deve fare un'unica copia dei
dati e cambiare l'intestazione del pacchetto in modo da farla puntare a questa
copia.

Figura A.2: Una rappresentazione del pacchetto Click!

I pacchetti di dati condivisi sono detti perciò copy-on-write. Le intes-
tazioni invece non sono mai condivise, così la loro modica non provoca mai
una copia. Oltre al puntatore ai dati l'intestazione contiene un certo numero
di annotazioni, le quali possono essere condivise con Linux, oppure speciche
di Click! . Alcune annotazioni contengono informazioni indendenti dai dati
(per esempio il tempo in cui il pacchetto è arrivato), mentre altre memoriz-
zano informazioni riguardanti i dati. Per esempio l'elemento CheckIPHeader
setta l'annotazione IPHeader nei pacchetti IP che transitano. Questa anno-
tazione segnala dove inizia l'intestazione IP e dove inizia il payload, liberando
i successivi elementi dall'esaminare il campo `Length' dell'intestazione IP. Le
annotazioni sono memorizzate nell'intestazione del pacchetto in un ordine s-
so e statico. I dati del pacchetto sono memorizzati in un singolo buer di
memoria.

A.4 Linguaggio
Il linguaggio del Click! descrive testualmente la congurazione del router. Due
obiettivi fondamentali guidano la progettazione di un linguaggio, e questi sono:

• leggibilità: un sistema modulare di internetworking risulta facilmente
ampliabile, solo se la sua congurazione può essere facilmente letta e
modicata


• praticità: La praticità dei tool fondamentalmente signica che dovrebbe
essere più facile progettare ed utilizzare degli strumenti specici per
analizzare e modicare i le scritti in Click!

Il linguaggio è dichiarativo, ovvero esso semplicemente descrive il grafo
relativo ad una congurazione (a dierenza dei linguaggi di script, come per
esempio i le .tcl di Network Simulator 2 (NS2)). I linguaggi dichiarativi
hanno il vantaggio della leggibilità, ma soprattutto possono essere analizzati
e modicati in maniera molto più semplice di quanto invece non consentano i
linguaggi imperativi.
Il linguaggio è semplice, dato che comprende un numero ridotto di costrutti
utilizzabili, preferendo implementare delle estensioni del linguaggio attraverso
elementi che avessero degli scopi specici. Questa scelta limita i meccanismi ed
i costrutti che possono essere utilizzati in fase di programmazione, ma consente
di ottenere una grande essibilità.
I programmi scritti in Click! e le congurazioni grache sono due strutture
equivalenti. Ciascuna congurazione corrisponde ad un semplice programma
nel linguaggio del Click! .

A.4.1 Sintassi
Come abbiamo visto ciascun elemento appartiene ad una classe di elementi, la
quale è specicata dal nome ed opzionalmente da una stringa di congurazione.
Gli elementi sono connessi attraverso le loro porte d'ingresso e d'uscita. Nel
linguaggio specico del Click! , le porte sono distinte attraverso l'uso di numeri,
mentre gli elementi sono distinti utilizzando un nome. Ciascun elemento in
una congurazione possiede un unico nome, che un utente può specicare in
maniera opzionale. Tali elementi individuano e dierenziano i vari elementi
durante il processo di analisi (anche sintattica eseguita in fase di compilazione),
ed permettono inoltre al singolo utente, o ad altri programmi, di accedere ad un
particolare elemento, anche in fase di esecuzione (lancio della congurazione).
Il comando utilizzato per eettuare la connessione crea una connessione dal-
la porta d'uscita port1 dell'elemento `name1' con la porta d'ingresso `port2'
dell'elemento `name2'. Gli elementi devono essere dichiarati prima di essere uti-
lizzati nelle connessioni. Ciascuna congurazione può essere descritta attraver-
so solo questi due costrutti sintattici; ma delle strutture sintattiche aggiun-
tive possono essere utilizzate per rendere visivamente più semplici le diverse
congurazioni.

Appendice B

Appendice B: Installazione in
laboratorio

L'esperienza è il tipo di
insegnante più dicile. Prima ti
fa l'esame poi ti spiega la lezione.

Anonimo.

In questa seconda appendice presenteremo il lavoro di installazione e con-
gurazione delle macchine del laboratorio del DEIS al ne di documentare
i passi svolti per testare l'implemntazione del modello e ottenere i risultati
sperimentali.

B.1 Installazione delle macchine
Si è scelto di approntare tre macchine per l'esecuzione dei test, in vista anche
di una futura congurazione che incrementi le prestazioni dell'emulazione. A
tale scopo sono state installate:

• 2 Macchine desktop Dell R Optiplex GX270

• 1 Macchina server Dell R PowerEdge Server 1600SC

Tutte e tre i calcolatori sono inoltre dotati di due interfacce di rete Intel R
con supporto per lo standard Gigabit Ethernet, in modo da non costituire colli
di bottiglia nella modellazione del nodo.

94 Appendice B: Installazione in laboratorio

B.2 Installazione del sistema operativo
Come sistema operativo si è optato per l'installazione della distribuzione Fedo-
ra core 12, per testare il software Click! su una piattaforma dierente da quel-
la di sviluppo e vericare ulteriormente la compatibilità dell'implementazione
realizzata.

Figura B.1: Il logo della distribuzione Fedora

Successivamente alla fase di installazione eseguita mediante l'assistente per-
sonalizzato della distribuzione (in cui si è avuto cura di selezionare i tool e le
librerie per lo sviluppo del software, tra cui i compilatori g++)

B.2.1 Ottimizzazione
Al ne di ottimizzare le risorse a disposizione del sistema operativo, e quindi
in denitiva a disposizione dell'istanza Click! che vi verrà eseguita, è stata
denita una congurazione di partenza del sistema operativo con un numero di
servizi e componenti ridotti al minimo. Si è dunque provveduto a modicare il
le grub.conf (il le di congurazione del bootloader ) in modo da inizializzare
il sistema a runlevel 3, una modalità in cui è disabilitata oltra l'interfaccia
graca, la gran parte dei servizi accessori. Inoltre si è provveduto a disabilitare
ulteriori servizi non indispensabili al nostro scopo come il servizio di stampa
(cups), il bluetooth (bluetooth daemon), i servizi legati alle remote procedure
call (rpc) e diversi altri. Alla ne di questo passo il sistema sarà leggero e
in grado di dedicare tutte le risorse al software Click! in esecuzione sulla
macchina.

B.2.2 Installazione delle dipendenze
Come ogni software creato per linux anche il Click! si appoggia a librerie
o eseguibili esterni che però non sempre sono compresi nella distribuzione di
base. Per ovviare a questo problema vengono riportati in tabella i pacchetti
necessari e/o complementari all'installazione del software di modellazione:

B.3. Installazione del software Click! 95

Pacchetti e dipendenze Click! :
Compiler: gcc
Compiler extension: gcc ada (gnat)
Perl extension: pcap
Compiler: gcc-c++ (g++)
Compiler: gcc-info
Compiler: gcc-objc (gobjc++)
Perl: perl5
Awk: gawk
Documentation: texinfo
Dvi: texi2dvi
Make: automake
Cong: autoconf
Gtk: libgtk2-dev
Graphics: graphviz

Tabella B.1: Pacchetti e dipendenze Click!

B.3 Installazione del software Click!
Di seguito vengono presentati i principali passi per l'installazione del software.

• Passo 1: Per ottenere il codice sorgente del Click! ci si è adati al
repository del progetto in cui è possibile trovare sempre l'ultima versione
stabile e aggiornata del software. Inoltre in questo modo è possibile ot-
tenere una versione Click! per l'esecuzione a livello kernel in modalità
patchless ovvero senza dover ricompilare il nucleo del sistema operati-
vo per l'inserimento della congurazione Click! come modulo del ker-
nel. Per ottenere i sorgenti dunque è necessario innanzitutto installare il
Concurrent Versions System (CVS) denominato git :
yum install git

• Passo 2: A questo punto, installato il CVS occorre reperire i sorgenti
del Click! mediante il comando clone per inserirli in una directory a
nostra scelta specicata dal parametro DIR:
git clone git://read.cs.ucla.edu/git/click DIR

• Passo 3: A questo punto vengono scaricati i sorgenti Click! , compresa
la change history in circa 37 MB di spazio su disco. A questo punto, spo-
standoci nella cartella dei sorgenti eseguiamo lo script di congurazione
con le opzioni per includere la compilazione dell'eseguibile kernel-level
patchless (enable-xincludes) e per la compilazione dei le C++ creati


per la congurazione del router ottico precedentemente posizionati nella
cartella DIR/elements/local:
./configure --enable-fixincludes --enable-local

• Passo 4: A questo punto non rimane che compilare il Click! con il
comando:
make

• Passo 5: Ed inne installare gli eseguibili con il comando:
make install

• Passo 6: A questo punto il software Click! è correttamente installato nel
sistema ed è possibile eseguire una qualsiasi congurazione Click! . Ad
esempio è possibile eseguire una congurazione di test con il comando:
click conf/test.click

B.3.1 Installazione di Clicky GUI
Il Click! è dotato di una interfaccia graca denominata Clicky GUI che è
compresa nel pacchetto sorgente ottenuto in precedenza.

Figura B.2: L'interfaccia graca Clicky

Per compilarla ed eseguirla è necessario eseguire alcuni semplici passi.

• Passo 1: Innanzitutti conguriamo clicky eseguendo dalla cartella DIR/app-
s/clicky il comando:
autoreconf -i

B.3. Installazione del software Click! 97

• Passo 2: A questo punto, lanciamo lo script di congurazione:
./configure

• Passo 3: A questo punto non rimane che compilare il Click! con il
comando:
make install

• Passo 4: A questo punto non rimane che lanciare l'applicazione:
clicky

Ringraziamenti

Lo studio: strumento per
costruire la propria libertà,
educazione dell'ingegno e della
creatività al lavoro, ma
soprattutto occasione privilegiata
di capire la vita.

Enrico Palandri, scrittore
italiano.
(1956 - vivente)

Se ti capiterà di leggere queste pagine, allora vorrà dire che ho avuto l'onore
di conoscerti. Così voglio dirti che porterò sempre con me i bei momenti pas-
sati insieme, le belle serate trascorse e le risate che ci siamo fatti, spesso,
anche a lezione. E a prescindere dalle occasionali incomprensioni, dai litigi, o
dalla distanza che può averci separato per qualche periodo o in alcune idee o
pensieri, grazie di cuore, perchè in tutto questo lavoro, in tutte queste pagine,
c'è anche un pò di te.

I primi sinceri e profondi ringraziamenti voglio dedicarli senza retorica alla
mia famiglia, alla mia Mamma, al mio Papà e a mio fratello Omar senza i quali,
devo riconoscerlo, non avrei raggiunto questo prestigioso traguardo. Sempre
presenti e vicini, sempre le parole giuste. Avete creduto in me più di quanto
lo facessi io. Troppo spesso con i miei comportamenti e le mie lamentele vi
ho visto chiedervi se eravate dei cattivi genitori, se non stavate sbagliando con
me. La risposta è sempre stata no, sempre, e siate orgogliosi perchè questo
risultato è anche vostro.
A mio fratello Omar dedico due righe in più, per sottolineare il piacere e
l'onore che ho avuto nel condividere con lui questa lunga esperienza. Il bene
che ti vuole un fratello forse non si può misurare, ma io ho avuto l'occasione di
provarlo, giorno dopo giorno, in questi lunghi otto anni insieme. Grazie tato.

100 Ringraziamenti

Ai nonni inne il mio pensiero va spontaneo; spero di avervi reso ero di
me tanto quanto mi mancano, ogni giorno di più, i vostri abbracci e i vostri
sorrisi. Non dimenticherò mai i vostri insegnamenti, che solo con il passare
degli anni, purtroppo, riscopro sempre più importanti e paterni. Quello che
mi rattrista è non potervi rendere merito di tutto ciò. Grazie Nonno Peppe,
Nonno Angelo, Nonna Anita e Nonna Fenisia.
Chi merita poi un ringraziamento speciale, fuori da ogni qualsivoglia classi-
ca, perchè sempre prima è e sarà nel mio cuore, è la mia danzata, Susanna.
Sei sempre stata al mio anco, nei momenti belli e ancor di più in quelli brutti,
mi hai spronato e confortato ogni giorno. Nessun aggettivo descriverebbe tutto
quello che sei per me e queste righe non sono sucenti per spiegare quanto tu
sia speciale. Spero però basti una vita insieme. Grazie, amore mio.
Un saluto sincero va anche a quelle persone che solo negli ultimi anni sono
entrati a far parte della mia famiglia, ma non per questo sono meno importanti.
A Giancarlo, Rosina e Giorgio, e alla mia cognatina Catia voglio dire grazie
per la naturalezza e l'aetto con il quale mi avete sempre accolto nelle vostre
case e mi avete fatto sentire parte delle vostre famiglie.
I ringraziamenti non sarebbero completi se non citassi due pilastri fon-
damentali del mio cuore, i miei due patatini, Porthos e Ares. Spesso siamo
lontani, a volte non vi coccolo abbastanza o fa troppo freddo per uscire ma
vorrei tanto sapeste, che come mi fate tornare il sorriso voi, non ci riesce nes-
suno. Anche se non potrete mai leggere queste parole il vostro posto è qui tra
i miei aetti più cari.
Al mio relatore, la professoressa Carla Raaelli, e ai miei correlatori, i
dottori Michele Savi e Walter Cerroni vanno i miei sinceri ringraziamenti per la
serietà, la profesionalità e l'aiuto mostratomi in questo progetto, attraverso le
sue dicoltà, i suoi alti e bassi, sempre duciosi delle mie capacità e disponibili
al dialogo e all'assistenza. Spero di aver ricambiato la vostra ducia con il
lavoro svolto.
Ai miei amici più cari, cui mi lega un'amicizia lunga una vita, Stefano
e Alessandro. Con loro ho condiviso tutta la mia adolescenza, le amicizie, i
momenti belli e quelli brutti, i miei ed i loro, quando abitavamo vicini, e quando
siamo stati lontani, insomma sempre. Ne abbiamo passate tante insieme, tutte
indimenticabili. Grazie di cuore, ragazzi.
Ai miei coinquilini, passati e presenti, con cui è stato memorabile vivere
tutti insieme come una grande famiglia, a partire dal mio amico Claudio, il
piccolo Mattia, Salvo, Paolo, il nonno Patric e il mio Maestro-Zio Andrea. Di
questi anni ricorderò sopratutto le serate insieme, gli scherzi e le risate che
non sono mai mancate. La nostalgia più grande di questa esperienza è e sarà
sempre quella di non avervi più in giro per casa. Mi mancherete.

101

A Eleonora, Simone, Valentina e Marco, un ringraziamento particolare per
avermi accolto nelle loro amicizie, nelle loro serate e inne, complice cupido,
nelle loro case. Gran parte di questi ultimi tre anni l'ho passata con voi, con-
dividendo le ansie, le paure ma anche qualche soddisfazione (e qualche pette-
golezzo!). Anche a queste belle serate saranno legati i miei ricordi universitari.
Grazie.
Ad un gruppo speciale, ormai con un pò di trasferte alle spalle e nuove
amicizie nate condividendo una passione ed un orgoglio tutto piceno. Agli
amici Esiliati mi legano i ricordi più intensi degli ultimi anni, i chilometri fatti
insieme, le delusioni ma anche clamorose soddisfazioni, sempre indelebili, di
un esperienza unica. Il mio vanto è essere uno di voi. Al mio amico Luca
de Filippis, e al nucleo storico formato da Marco Minelli, Tiziano Caponi, ai
numerosi altri che si sono aggiunti nel tempo: Gianmarco Rendina, Davide
Ferretti, Alessandro Ricci, Stefano Virgili, Francesco Aurini, Enrico Seghetti,
Matteo Sabatini, Antonio Angelelli, Piergiulio Manardi, Iacopo Mattia Perozzi,
Roberto Battilana. Siete pronti per una nuova trasferta, ragazzi?
Ai miei fedeli compagni di gradoni, nelle partite casalinghe del magico
Picchio, e ai miei amici ascolani, che aspettano da tempo questa notizia.
Voglio così ringraziare Carlo e Stefano Diamanti, Roberta Bordoni, Sara Abeti,
Stefano Ciannavei e Iole D'Angelo e tanti altri . . .
Agli amici conosciuti qui e con cui ho diviso quest'esperienza accademi-
ca, Christian Florio e Davide Gasbarro, Renato Grottesi, Costanzo Di Maria,
Francesco Achille, Leonardo D'Apote, Marco Damiani, Mauro Lopopolo, Francesco
Fazzini, Fabio Ciotoli, Andrea Cirri, Fausto Fusaro, Francesco Ceravolo e
Chiara Gualtieri. Indimenticabili i momenti a lezione, i pomeriggi di studio,
le tensioni degli esami fatti e le gioie di quelli passati, insieme.
Alla mia città, Ascoli Piceno, la cui nostalgia fa sempre capolino nel mio
cuore e all'Ascoli Calcio, passione vera e unico svago nei miei momenti dicili,
orgoglio e soddisfAzione.

A tutti Voi, grazie di cuore.
Raul.

Bibliograa

[1] Frank Mittelbach and Michel Goossens The LTEX Companion (Sec-
A

ond Edition) : Tools and Techniques for Computer Typesetting Addison
Wesley, 2004.

[2] AA. VV. Wikipedia: The Free Encyclopedia Wikimedia Foundation
http://www.wikipedia.org/

[3] AA. VV. Linux FEDORA. Guida professionale Apogeo, 2005.
http://www.apogeonline.com/libri/88-503-2314-
X/scheda?id=8KnyX6mC

[4] C.Raaelli, M. Savi, A. Stavdas Multistage Shared-Per-Wavelength Op-
tical Packet Switch: Heuristic Scheduling Algorithm and Performance
IEEE/OSA Journal of Lightwave Technology, Vol. 27, Issue 5, pages
538-551, March 2009.

[5] C.Raaelli, M. Savi, W. Cerroni Modular Design of Programmable Multi-
Granular Optical Switching Node

[6] Herbert Schildt C++ La guida completa McGraw-Hill, 1995.

[7] Biswanath Mukherjee Optical WDM Networks Springer, 2005.

[8] Tarek S. El-Bawab Optical Switching Springer, 2005.

[9] Rajiv Ramaswami, Kumar N. Sivarajan Optical Networks, a practical
perspective (Second Edition) Morgan-Kaufmann, 2001.

[10] G. S. Zervas, M. De Leenheer, L. Sadeghioon, D. Klonidis, Y. Qin, R. Ne-
jabati, D. Simeonidou, C. Develder, B. Dhoert, and P. Demeester, ÒMulti-
Granular Optical Cross-Connect: Design, Analysis and DemonstrationÓ,
Journal on Selected Areas in Communications (JSAC), IEEE, vol. 27, no.
4, April 2009.

104 BIBLIOGRAFIA

[11] F. Callegati, A. Campi, G. Corazza, D. Simeonidou, G. Zervas, Y. Qin,
R. Nejabati, SIP-empowered Optical Networks for Future IT Services and
Applications, IEEE Communications Magazine, Vol. 47, Issue 5, pp. 48-
54, May 2009.

[12] L. Wosinska, D. Simeonidou, A. Tzanakaki, C. Raaelli C. Politi, Optical
Networks for the Future Internet: Introduction, IEEE/OSA Journal of
Optical Communications and Networking, Vol. 1, Issue 2, pp. FI1ÐFI3,
July 2009.

[13] G. Zervas, R. Nejabati, D. Simeonidou, C. Raaelli, M. Savi, C. Develder,
M. De Leenheer, Dider Colle, M. Schiano, Programmable Multi-Granular
Optical Networks: Requirements and Architecture, in proceedings of
Broadnets 2009, Madrid, Spain, 14-16 September 2009.

[14] G. Zervas et al., Demonstration of Novel Multi-Granular Switch Architec-
ture on an Application-Aware End-to-End Multi-Bit Rate OBS Network
Testbed, European Conference on Optical Communication (ECOC 2007),
PostDeadline, PDS 3.2, Berlin, Germany, Sept. 2007.

[15] B. Martini, V. Martini, F. Baroncelli, K. Torkman, P. Castoldi, -
Application-Driven Control of Network Resources in Multiservice Optical
Networks, Journal of Optical Communications and Networking, Vol. 1,
Issue 2, pp. A270ÐA283, July 2009.

[16] Y. Qin et Al, Service-Oriented Multi-Granular Optical Network Testbed,
in proceedings of IEEE/OSA OFC 2009 x, Optical Fiber Communication
Conference, San Diego, USA, 22-26 March, 2009.

[17] E. Kohler, R. Morris, B. Chen, J. Jannotti, M.F. Kaashoek, The Click
Modular Router, ACM Transactions on Computer Systmes, 18(3), 2000,
pp. 263-297.

[18] Yu Ben, Qian Ying Tang Optical Packet Switching , May 2, 2006.

[19] AA. VV. An Optical Packet Switch Based on WDM Technologies

[20] AA.VV. Optical Packet Switching Cambridge Press.

[21] AA. VV. Gateway for India
http://www.gatewayforindia.com/technology/opticalber.htm

[22] K.Kitayama, M.Koga, H.Morikawa, S.Hara, and M.Kawai Optical Burst
Switching Network Test bed in Japan , in proceedings of Optical Fiber

BIBLIOGRAFIA 105

Communication Conference (OFC2005), Anaheim, USA, Mar. 2005,
PaperOFA6.

[23] O.Liboiron-Ladouceur, A.Shacham, B.A.Small, B.G.Lee, H.Wang,
C.P.Lai, A.Biberman, K.Bergman The Data Vortex Optical Packet
Switched Interconnection Network , Journal of Lightwave Technology,
Vol.26, Issue13, pp.1777-1789, July 2008.

[24] Carla Raaelli, Giovanni Schembra Introduzione all'uso dell'ambiente
Click! per la realizzazione di router IP , Rapporto tecnico DEIS -
Università di Bologna DEIS-NET-03-001

[25] G.Calarco, C.Raaelli, Implementation of Implicit QoS Control in a
modular software router context , QoS-IP2005, Catania, Italy, February
2005.

[26] J.Somers, P.Barford, M.Crovella Router Primitives for Programmable
Active Measurement , Proceedings of ACM SIGCOMM PRESTO
Workshop, August 2009.

[27] L.Zanolin, C.Mascolo, W.Emmerich Model checking programmable router
congurations , UCL Research Note (02/23).

Elenco degli acronimi

ASCII American Standard Code for Information Interchange. Ovvero Codice
Standard Americano per lo Scambio di Informazioni è un sistema di codi-
ca dei caratteri a 7 bit comunemente utilizzato nei calcolatori, proposto
dall'ingegnere dell'IBM Bob Bemer nel 1961, e successivamente accettato
come standard dall'ISO (ISO 646).

ATM Asynchronous Transfer Mode. E' un protocollo di rete a commutazione
di cella che incapsula il traco in celle a lunghezza ssa (53 byte) invece
che in pacchetti a lunghezza variabile come nelle reti a commutazione di
pacchetto (ad esempio IP).

BaS Broadcast-and-Select. Tipologia di architettura per router ottici che
prevede la duplicazione dei percorsi provenienti dagli ingressi verso tutte
le uscite possibili con una successiva selezione dei percorsi eettivamente
da abilitare.

CE Control Element. Componente dedicato alla gestione dei segnali di con-
trollo del router ottico.

CVS Concurrent Versions System E' un sistema di controllo versione, mantiene
cioè al corrente di tutto il lavoro e di tutti i cambiamenti in un insieme
di le, tipicamente è l'implementazione di un software in via di sviluppo,
in progetto, e permette a molti sviluppatori (potenzialmente distanti) di
collaborare. CVS è divenuto popolare nel mondo del software libero ed
è rilasciato sotto la GNU General Public License.

CWDM Coarse Wavelength Division Multiplexing. Variante della multi-
plazione WDM utilizzata nei sistemi di comunicazione ottica. Nel coarse
WDM la separazione tra le lunghezze d'onda usate è maggiore che nel
convenzionale e nel DWDM, in modo da poter utilizzare componenti
ottici meno sosticati e quindi meno costosi.

DEIS Dipartimento di Elettronica, Informatica e Sistemistica..

108 Elenco degli acronimi

DWDM Dense Wavelength Division Multiplexing. Variante della multiplazione
WDM utilizzata nei sistemi di comunicazione ottica. Il Dense WDM usa
la stessa nestra di trasmissione ma con minore separazione tra i canali,
arrivando a 31 canali a intervalli di 50 GHz.

EDFA Erbium-Doped Fiber Ampliers. Sono amplicatori ottici che usano
un bra ottica drogata come mezzo attivo per amplicare un segnale
ottico. Il segnale che si vuole amplicare ed un segnale di pompa vengono
multiplati in una bra drogata ed il segnale risulta amplicato mediante
l'interazione con gli ioni del drogante.

EO Electrical-Optical. Conversione di un segnale dal dominio elettromagneti-
co (livelli di tensione variabili, interpretabili come valore zero o uno) a
quello ottico (assenza o presenza di luce).

EPS Electronic Packet Switching. Con questo termine si intende il proces-
so di elaborazione e commutazione dei pacchetti all'interno dei router
elettronici.

FDL Fiber Delay Line. Componente in grado di ritardare nel tempo il segnale
ottico in ingresso di un valore T ssato.

FDM Frequency Division Multiplexing. Ovvero multiplazione a divisione di
frequenza, è una tecnica di condivisione di un canale di comunicazione
secondo la quale un canale trasmissivo è diviso in sottocanali, ognuno
costituito da una banda di frequenza separata. Questo rende possibile la
condivisione dello stesso canale da parte di diversi dispositivi che possono
comunicare contemporaneamente.

FE Forwarding Element. Componente dedicato alla gestione dell'inoltro dei
pacchetti nel router ottico.

FIFO First-In First-Out. Politica di gestione delle code, in cui il primo
elemento ad entrare nella coda sarà il primo ad uscirne.

FM Forwarding Module. Componente dedicato all'attuazione dell'inoltro dei
pacchetti nel router ottico.

ForCES Forwarding and Control Element Separation. Raccomandazione del-
l'IEEE per la separazione del piano di controllo ed inoltro nei router di
nuova generazione.

FT Forwarding Table. Tabella contenente le informazioni di inoltro per una
determinata label MPLS.

109

FTWC Fixed-input Tunable-output Wavelength Converter. Convertitore che
accetta solo un determinata lunghezza d'onda ssa in ingresso mentre
permette di convertirla verso l'uscita su una qualsiasi altra lunghezza
d'onda.

GMPLS Generalized Multi-Protocol Label Switching. MPLS è nato princi-
palmente per garantire alte performance di inoltro del traco, sia IP che
di livello 2, ed è stato oggetto di estensioni per garantire la creazione
di percorsi anche su reti non nativamente IP, quali reti SDH e WDM.
In questa forma è noto come Generalized MPLS o G-MPLS. Il concetto
di label è stato ampliato includendo anche identicativi di diverso tipo,
quali l'associazione a numero di timeslot in trama SDH oppure frequenze
di wavelenght per i sistemi WDM.

GNU GNU is Not Unix. Il progetto GNU lanciato nel 1983 da Richard Stall-
man, si basa su una gestione particolare dei diritti d'autore sul soft-
ware, secondo la denizione di software libero (contrapposta a software
proprietario).

IEEE Institute of Electrical and Electronic Engineers Istituto degli ingegneri
elettrici ed elettronici, nacque il 1o gennaio 1963 con lo scopo principale
di cercare nuove applicazioni e teorie nella scienza elettrotecnica, elet-
tronica, informatica, meccanica e biomedica; a questo scopo organizza
conferenze e dibattiti tecnici in tutto il mondo, pubblica testi tecnici e
sostiene programmi educativi. Si occupa inoltre di denire e pubblicare
standard in tali campi.

IETF Internet Engineering Task Force. E' una comunità aperta di tecnici,
specialisti e ricercatori interessati all'evoluzione tecnica e tecnologica di
Internet. Ciò che dierenzia IETF dagli Enti di standardizzazione più
tradizionali è la sua struttura aperta: il lavoro viene svolto da gruppi
di lavoro (working groups) che operano soprattutto tramite Mailing list,
aperte alla partecipazione di chiunque sia interessato, e che si riuniscono
tre volte l'anno. I gruppi di lavoro si occupano ciascuno di uno specico
argomento e sono organizzati in aree (protocolli applicativi, sicurezza,
. . . ).

IF Input Fiber. Fibra di ingresso.
IP Internet Protocol. E' un protocollo di interconnessione di reti (Inter-
Networking Protocol), nato per interconnettere reti eterogenee per tec-
nologia, prestazioni, gestione. E' di tipo connection-less ed è classicato
ISO/OSI livello 3 (rete).


ISO International Organization for Standardization E' la più importante or-
ganizzazione a livello mondiale per la denizione di norme tecniche.
Fondata il 23 febbraio 1947, ha il suo quartier generale a Ginevra in
Svizzera.

ISP Internet Service Provider. Un fornitore di servizi internet è una strut-
tura commerciale o un'organizzazione che ore agli utenti (residenziali o
imprese) servizi inerenti Internet i principali dei quali sono l'accesso alla
rete stessa e la posta elettronica.

KEOPS KEys to Optical Packet Switching. Progetto europeo per lo studio
delle soluzioni in ambito del trasferimento ottico delle informazioni.

LED Light Emitting Diode. Diodo ad emissione luminosa, sfrutta le proprietà
ottiche di alcuni materiali semiconduttori per produrre fotoni a partire
dalla ricombinazione di coppie elettrone-lacuna.

LL Label Lookup. Dispositivo di interrogazione e risoluzione degli indirizzi
nelle label usate in ambienti tipo MPLS.

LS Label Swap. Dispositivo di sostituzione degli indirizzi nelle label usate in
ambienti tipo MPLS.

MAN Metropolitan Area Network. La rete in area metropolitana è una
tipologia di rete di telecomunicazioni con un'estensione limitata a perimetro
metropolitano. Storicamente le MAN sono nate per fornire servizi di tv
via cavo alle città dove c'era una cattiva ricezione terrestre. In pratica
un'antenna posta su una posizione favorevole, distribuiva poi il segnale
alle case mediante cavo. Quando il fenomeno Internet è esploso, queste
società hanno ben pensato di diondere la comunicazione internet an-
che attraverso il cavo TV utilizzando la stuttura preesistente. Tipica-
mente questa struttura, attualmente, utilizza la bra ottica come mezzo
di collegamento.

MEMS Micro-Electro-Mechanical Systems. Sigla che indica quello che la
tecnologia del microscopico ha prodotto (si intende qui che la dimen-
sione media degli oggetti considerati sia di un micrometro). I micro-
sistemi elettromeccanici non sono altro che un insieme di dispositivi di
varia natura (meccanici, elettrici ed elettronici) integrati in forma alta-
mente miniaturizzata su uno stesso substrato di silicio, che coniugano
le proprietà elettriche degli integrati a semiconduttore con proprietà
opto-meccaniche.

111

MIT Massachusetts Institute of Technology. E' una delle più importanti uni-
versità di ricerca del mondo, con sede a Cambridge, nel Massachusetts.

MPLS Multi Protocol Label Switching. E' una tecnologia per reti IP che per-
mette di instradare ussi di traco multiprotocollo tra origine (Ingress
Node) e destinazione (Egress Node) tramite l'utilizzo di identicativi (la-
bel) tra coppie di router adiacenti ed operazioni semplici sulle etichette
stesse.

MST Micro Systems Technology. Sinonimo dei Micro-Electro-Mechanical
Systems (MEMS).

NS2 Network Simulator 2. Software per la simulazione di architetture di rete.
OBS Optical Burst Switching. Paradigma di commutazione a burst, prevede
il passaggio prioritario di ussi di dati contrassegnati da un qualche tipo
di livello di servizio o indice di priorità.

OCS Optical Circuit Switching. Paradigma di commutazione a circuito, prevede
l'instaurazione di un canale di comunicazione dedicato ed esclusivo tra il
mittente e il ricevente.

OE Optical-Electrical. Conversione di un segnale dal dominio ottico (assenza
o presenza di luce) a quello elettromagnetico (livelli di tensione variabili,
interpretabili come valore zero o uno).

OEO Optical-Electrical-Optical. Serie di conversioni di un segnale dal do-
minio ottico (assenza o presenza di luce) a quello elettromagnetico (liv-
elli di tensione variabili, interpretabili come valore zero o uno) per il
processamento mediante dispositivi elettronici. Successivamente il seg-
nale viene di nuov convertito dal dominio elettromagnetico a quello della
luce per tornare a viaggiare all'interno della rete ottica.

OF Output Fiber. Fibra di uscita.
OLS Optical Label Switching. Tecnica di commutazione basata sulla inter-
pretazione di etichette apposte in incipit al traco. In base al valore
espresso in queste etichette il traco viene rediretto o meno verso una
determinata interfaccia di uscita.

OLPS Optical Label Packet Switching. Termine equivalente per indicare la
tecnica OLS.

OPATM Optically Transparent Asynchronous Transfer Mode. Proposta di
protocollo trasparente alla rete ATM su bra ottica.


OPNET OPerations NETwork. Software per la simulazione di architetture
di rete.

OPS Optical Packet Switching. Paradigma di commutazione a pacchetto in
cui le informazioni di più canali di comunicazioni viaggiano mediante lo
stesso collegamento, connate in pacchetti che usano il mezzo trasmissivo
per frazioni di tempo distinte, realizzando di fatto la condivisione del
canale.

OSI Open Systems Interconnection E' uno standard stabilito nel 1978 dal-
l'ISO, il principale ente di standardizzazione internazionale, che stabilisce
una pila di protocolli in 7 livelli di un modello standard di riferimento
per l'interconnessione di sistemi di computer.

PLP Packet Loss Probability. Probabilità di perdita di pacchetti in un nodo
della rete. E' il risultato della divisione tra il valore dei pacchetti in
ingresso al nodo meno il valore dei pacchetti in uscita (quindi il valore
dei pacchetti persi nelle operazioni di scheduling) e il valore dei pacchetti
in ingresso al nodo.

QoS Quality of Service. Termine per indicare i parametri usati per carat-
terizzare la qualità del servizio oerto dalla rete (ad esempio perdita di
pacchetti, ritardo), o gli strumenti per ottenere una qualità di servizio
desiderata. La qualità del servizio è normalmente correlata negativa-
mente con il traco oerto alla rete, e positivamente con le risorse
impegnate per realizzare e gestire la rete.

RAM Random Access Memory. La memoria ad accesso casuale, è una tipolo-
gia di memoria informatica caratterizzata dal permettere l'accesso diret-
to a qualunque indirizzo di memoria con lo stesso tempo di accesso. La
memoria ad accesso casuale si contrappone alla memoria ad accesso se-
quenziale e alla memoria ad accesso diretto rispetto alle quali presenta
tempi di accesso sensibilmente inferiori motivo per cui è utilizzata come
memoria primaria.

RFC Request For Comments. E' un documento che riporta informazioni o
speciche riguardanti nuove ricerche, innovazioni e metodologie dell'am-
bito informatico o, più nello specico, di Internet. Attraverso l'Internet
Society gli ingegneri o gli esperti informatici possono pubblicare dei mem-
orandum, sottoforma di RFC, per esporre nuove idee o semplicemente
delle informazioni che una volta vagliati dall'IETF possono diventare
degli standard Internet.

113

SDM Space Division Multiplexing. La multiplazione a divisione di spazio,
è una tecnica di condivisione di un canale di comunicazione secondo la
quale ogni dispositivo abbia un canale separato di comunicazione e uno
spazio di guardia tra gli altri mittenti.

SM Switching Matrix. Matrice di commutazione. E' il componente che realiz-
za il passaggio delle informazioni dalle interfacce di input a quelle di out-
put mediante l'attuazione dei suoi dispositivi interni, che caratterizzano
l'architettura, secondo le direttive imposte dal piano di controllo.

SOA Semiconductor Optical Amplier. Dispositivi di amplicazione del seg-
nale ottico i quali utilizzano un semiconduttore per fornire il guadagno.

SPL Shared-Per-Link. Architettura di tipo shared in cui i WC vengono
condivisi per interfaccia di ingresso.

SPN Shared-Per-Node. Architettura di tipo shared in cui i WC vengono
condivisi per nodo.

SPW Shared-Per-Wavelength. Architettura di tipo shared in cui i WC ven-
gono condivisi per lunghezza d'onda di ingresso.

TCP Transmission Control Protocol. E' un protocollo di livello di trasporto
della suite di protocolli Internet. Può essere classicato al livello trasporto
(OSI level 4) del modello di riferimento OSI, e di solito è usato in com-
binazione con il protocollo di livello rete (OSI level 3) IP. Il TCP è
stato progettato per utilizzare i servizi del protocollo IP, che non ore
alcuna garanzia in ordine alla consegna dei pacchetti, al ritardo, alla
congestione, e costruire un canale di comunicazione adabile tra due
processi applicativi. Il canale di comunicazione è costituito da un usso
bidirezionale di byte.

TDM Time Division Multiplexing. La multiplazione a divisione di tempo,
è una tecnica di condivisione di un canale di comunicazione secondo la
quale ogni dispositivo ottiene a turno l'uso esclusivo dello stesso per un
breve lasso di tempo (tipicamente 125 micro secondi).

TOS Type Of Service. Bit relativi al tipo di servizio desiderato che si trovano
nell'intestazione IPv4 per distinguere diversi tipi di datagrammi.

TTL Time-to-live. E' un campo dell'header del protocollo IP e di MPLS, che
determina il numero massimo di router che possono essere attraversati
da un pacchetto.


TWC Tunable-output Wavelength Converter. Convertitore in grado di con-
vertire la lunghezza d'onda in ingresso su una qualsiasi altra lunghezza
d'onda in uscita. Esistono diveri tipi di TWC come ad esempio i Fixed-
input Tunable-output Wavelength Converter (FTWC) o i Tunable-input
Tunable-output Wavelength Converter (TTWC).

TTWC Tunable-input Tunable-output Wavelength Converter. Convertitore
che accetta in ingresso una qualsiasi lunghezza d'onda e permette di
convertirla verso l'uscita su una qualsiasi altra lunghezza d'onda.

UDP User Datagram Protocol. E' uno dei principali protocolli della suite
di protocolli Internet a livello di trasporto a pacchetto, usato di soli-
to in combinazione con il protocollo IP. l'UDP è un protocollo di tipo
connectionless, inoltre non gestisce il riordinamento dei pacchetti né la
ritrasmissione di quelli persi, ed è perciò generalmente considerato di
minore adabilità. È in compenso molto rapido ed eciente per le ap-
plicazioni leggere o time-sensitive. Ad esempio, è usato spesso per la
trasmissione di informazioni audio o video. Dato che le applicazioni
in tempo reale spesso richiedono un ritmo minimo di spedizione, non
vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono
tollerare qualche perdita di dati, il modello di servizio TCP può non
essere particolarmente adatto alle loro caratteristiche.

VLAN Virtualized Local Area Network. Indica un insieme di tecnologie che
permettono di segmentare il dominio di broadcast, che si crea in una rete
locale (tipicamente IEEE 802.3) basata su switch, in più reti non comu-
nicanti tra loro. Le applicazioni di questa tecnologia sono tipicamente
legate ad esigenze di separare il traco di gruppi di lavoro o dipartimenti
di una azienda, per applicare diverse politiche di sicurezza informatica.

WC Wavelength Converter. Dispositivo in grado di convertire la lunghezza
d'onda di un segnale ottico modulato in WDM.

WDM Wavelength Division Multiplexing. Un tipo di multiplazione utilizzato
nei sistemi di comunicazione ottica. Per modulare diversi canali su una
stessa bra ottica si usano diverse portanti di dierenti lunghezze d'onda,
una per ogni canale, e per la singola portante si usa la modulazione di
intensità. In questo modo è possibile sfruttare la grande banda ottica
disponibile.

Realizzazione di un modello di router ottico in ambiente open source.

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Realizzazione di un modello di router ottico in ambiente open source. (20)

Realizzazione di un modello di router ottico in ambiente open source.