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

1. 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: Raul Cafini
Relatore: Prof.ssa Carla Raffaelli
Correlatori: Dott. Ing. Walter Cerroni
Dott. Ing. Michele Savi

2. Sommario
Una breve agenda del lavoro mostrato oggi …
• Cenni sulla tecnologia
• Le reti ottiche e paradigmi di commutazione
• Architetture per router ottici
• Il concetto di multi-granularità
• Il modello di router programmabile
• Implementazione software
• Test e valutazioni
• Conclusioni
• Sviluppi futuri
18/03/2010 Raul Cafini 2

3. Reti Ottiche
Reti Ottiche: le informazioni viaggiano sotto
forma di segnali luminosi.
Fibre ottiche:
• Flessibili, immuni ai disturbi elettrici e alle
condizioni atmosferiche
Multiplazione WDM:
• Multiplazione di lunghezza d’onda;
• Fino a 160 lunghezze d’onda, limite teorico
di 1.6Tbit/s.
Paradigmi di commutazione:
• Optical Circuit Switching (OCS)
• Optical Burst Switching (OBS) Fig. 3) Esempio di rete ottica OPS
• Optical Packet Switching (OPS)
Rispetto ai normali router, nelle reti ottiche si cerca di far coesistere vari paradigmi di
commutazione per far fronte alle diverse esigenze del traffico e ai diversi servizi offerti:
Concetto di Multi-Granularità
18/03/2010 Raul Cafini 3

4. Architettura generale di router ottico
• Input Interface: ingresso del traffico, delineazione e separazione delle informazioni di routing;
• Control Unit: Unità di controllo sulla gestione e l’inoltro del traffico mediante algoritmi di scheduling.
• Switching Matrix: Possibili implementazioni differenti per architetture e tecnologie utilizzate.
• Output Interface: interfaccia di uscita del traffico schedulato con successo verso altri nodi
18/03/2010 Raul Cafini 4

5. Router ottico programmabile …
Questa soluzione è conforme alla RFC 3746 che esprime le
raccomandazioni IEEE per la Forwarding and Control
Element Separation:
• Separazione logica tra Control Element CE e Forwarding
Element FE
• Protocollo standard di comunicazione tra CE e FE (ora
soluzioni proprietarie)
Una estensione proposta dal modello di studio da parte del
dipartimento consiste nella introduzione di elementi detti
Forwarding Modules (FM)
• Indipendenza dall’hardware. Solo i FM sono definiti
specificatamente per una determinata implementazione
hardware.
• Alta personalizzazione da parte degli ISP che possono
definire i propri FM
18/03/2010 Raul Cafini 5

6. Contention Resolution
Contention Resolution: quando due o più pacchetti competono per la stessa risorsa, ovvero
la stessa fibra di uscita e sulla stessa lunghezza d'onda allo stesso istante. Questo problema
può essere affrontato in diversi domini:
• Spazio: aumento delle risorse, aumento dei costi
• Tempo: bufferizzare le informazioni
• Frequenza: o più propriamente lunghezza d'onda
L'approccio OPS permette di affrontare la contesa nel dominio delle lunghezze d'onda
(wavelength domain) sfruttando le proprietà della conversione.
• Tunable Wavelength Converters (TWCs): dispositivi in grado di
convertire la lunghezza d'onda del segnale in ingresso su un’altra
lunghezza d'onda in uscita, permettendo così di risolvere le contese.
Svantaggio: dispositivi molto costosi.
18/03/2010 Raul Cafini 6

7. L’architettura Broadcast-&-Select
Esistono diverse architetture per le matrici di
commutazione:
• Alcune pongono attenzione al contenimento dei
costi (Shared Architectures, condivisione TWC)
• Altre forniscono un supporto nativo alla QoS senza
preoccuparsi dei costi. Un esempio è l’architettura
Broadcast-&-Select:
• Il traffico è propagato a tutte le interfacce di
uscita (supporto nativo a broadcast e multicast).
• Il percorso è ostacolato da dei dispositivi in
grado di comportarsi come interruttori ottici.
• Configurando i dispositivi secondo le istruzioni
fornite dall’algoritmo di scheduling è possibile
instradare i pacchetti verso i percorsi voluti.
• Dispositivi diversi in base alla tecnologia: fast
(SOA) e slow (MEMS).
18/03/2010 Raul Cafini 7

8. Il modello implementato
Dato che queste architetture e questi dispositivi sono in realtà molto costosi, per studiare
queste soluzioni si può ricorrere a diverse approcci:
• Test-bed: difficoltà di verifica delle prestazioni logiche, scarsa modularità e flessibilità nella
configurazione, costi elevati …
• Simulatori: le interazioni nel piano di controllo non sono evidenti, la modellazione e
l’attuazione dell’hardware è poco realistica, in caso di traffico non reale risultati fuorvianti.
La nostra soluzione propone un approccio differente:
• Emulatore altamente configurabile (numero di ingressi, uscite, lunghezze d’onda) e
modulare (modifica della architettura semplice ed immediata);
• Realizzato in ambiente open source (Linux) mediante il software Click! Modular Router;
• Implementazione attuale: architettura di tipo Broadcast-&-Select, con opzione Multi-
Granulare (OPS-Slotted) e in linea con le raccomandazioni espresse in ForCES (RFC3746);
• Analisi e valutazione dei livelli di potenza e consumo all’interno del nodo.
18/03/2010 Raul Cafini 8

9. Click! Modular Router
Il Click! è un framework open source modulare, orientato
alla realizzazione di dispositivi come:
• Router, processori di pacchetti, sorgenti di traffico,
Ethernet switch, firewall, etc.
Linguaggio:
• Dichiarativo
• I modelli definiti in file di configurazione, definendo gli
elementi e le connessioni che li caratterizzano (modularità).
• E’ possibile creare propri elementi in classi C++ per scopi
particolari (estendibilità)
Pacchetti Click!: All’interno delle configurazioni non
viaggiano i dati reali ma dei pacchetti formati da:
• Un puntatore ai dati reali
• Una serie di annotazioni (memoria comune nel piano di
controllo)
18/03/2010 Raul Cafini 9

10. Il modello implementato
• Control Plane: piano di controllo.
• Data Plane: piano del traffico dati.
18/03/2010 Raul Cafini 10

11. Diagramma di funzionamento
Input Fiber (IF):
• Inserimento delle informazioni nelle
annotazioni (InputFiber, wavelength,
power, …)
• Separazione tra header e payload
• Conversione OE dell’header e invio al
piano di controllo (CE)
• Invio del payload alla Switching Matrix
(SM)
Control Element (CE):
• Gestione del timeslot di appartenenza
(OPS Slotted)
• Individuazione delle necessità di
traffico (priorità, banda, …)
18/03/2010 Raul Cafini 11

12. il Forwarding Element
Ingresso nel Forwarding Element (FE):
• Label Lookup (LL): Controllo della label di destinazione nella Forwarding Table e risoluzione
dell’interfaccia di uscita relativa;
• FESimpleScheduler: Algoritmo di scheduling che valuta il numero di pacchetti già inoltrati per
la voluta interfaccia di uscita, in aggiunta alle informazioni provenienti in retroazione dal
Forwarding Module (FM);
• Label Swap (LS): Inserimento delle nuove informazioni di routing nel nuovo header;
18/03/2010 Raul Cafini 12

13. il Forwarding Module
Ingresso nel Forwarding Module (FM):
• FMSimpleScheduler: Algoritmo di scheduling che valuta le contese per la fibra di uscita
voluta e la lunghezza d’onda di provenienza. Le informazioni di successo o meno della
risoluzione vengono inviate in retroazione al Forwarding Element (FE);
• NewTimeslotScript: Script di reset dei dispositivi della matrice nel caso di un nuovo timeslot;
• FMScript: Script di attuazione dei dispositivi della Switching Matrix in accorso agli handler
impostati dal FMSimpleScheduler;
18/03/2010 Raul Cafini 13

14. La SM e l’interfaccia di output
Switching Matrix (SM):
• Solo i dispositivi attivati correttamente dallo
scheduler permettono ai pacchetti di
attraversare la matrice;
• I pacchetti che attraversano i dispositivi sono
caratterizzati in potenza (attenuazione,
amplificazione, rapporto segnale/rumore)
secondo le funzioni “ideali” dei dispositivi;
Output Fiber (OF):
• Il nuovo header è riconvertito nel dominio
ottico;
• Il payload e l’header sono ricongiunti a
formare di nuovo il pacchetto ottico in uscita al
nodo;
18/03/2010 Raul Cafini 14

15. Le prestazioni misurate
Packet Loss Probability (PLP): Probabilità di perdita dei pacchetti, espressa
come differenza tra i pacchetti in ingresso e quelli effettivamente inoltrati sul
totale dei pacchetti in ingresso:
• Minore è, migliori sono le prestazioni del nodo (e quindi della sua
architettura e del suo algoritmo di scheduling).
• Variazioni del numero di ingressi, uscite, numero di lunghezze d'onda del
canale e delle possibili implementazioni degli algoritmi di scheduling sono
tutti fattori che, come vedremo, influenzano il valore espresso dalla PLP.
18/03/2010 Raul Cafini 15

16. Confronto tra due configurazioni …
N.B. La PLP ha valori minori a parità di ingressi e uscite per un numero
di lunghezze d’onda disponibili maggiori, si è in grado di risolvere
un maggior numero di contese …
18/03/2010 Raul Cafini 16

17. Confronto tra varie configurazioni …
N.B. La PLP ha valori più distanti tra la configurazione 2:2 e 4:4
rispetto alle configurazioni 4:4 e 8:8 e così aumentando …
18/03/2010 Raul Cafini 17

18. Conclusioni
Il lavoro si è suddiviso in documentazione, analisi ed implementazione dei
concetti oggetto di ricerca:
• Obiettivo 1: Si sono studiate le tecnologie, i paradigmi e le soluzioni
proposte dalla letteratura per quanto riguarda la trasmissione dei dati nel
dominio ottico;
• Obiettivo 2: Si sono analizzate le principali architetture per matrici di
commutazione ottiche valutandone punti a favore e contrari;
• Obiettivo 3: Si è scelto mediante le informazioni raccolte di implementare
una determinata architettura in un modello di router ottico programmabile;
• Obiettivo 4: L'implementazione realizzata è di tipo B&S per reti OPS-
Slotted e conforme nelle specifiche alle direttive della ForCES (RFC 3746) e
all’estensione studiata dal dipartimento;
• Obiettivo 5: L’emulazioni testate su varie configurazioni della nostra
implementazione rispecchiano i valori di PLP dei modelli equivalenti di
simulazione garantendone quindi la correttezza di funzionamento a livello
logico e fisico.
18/03/2010 Raul Cafini 18

19. Sviluppi futuri
• Riduzione delle tempistiche di emulazione: rendere le emulazioni più
veloci e verosimilmente comparabili con le tempistiche reali.
• Implementazione totale della multi-granularità: estendere il modello
anche per i paradigmi OCS e OBS rendendo l'architettura completamente
multi-granulare.
• Implementazione totale del modello di consumo di potenza: monitorare
i livelli di potenza e consumo all'interno del router, ed emulare
concretamente i valori in gioco in un dispositivo reale per restituire
informazioni utili sul consumo di potenza al variare delle architetture e degli
algoritmi di scheduling.
18/03/2010 Raul Cafini 19