Realizzazione di un modello di router ottico in ambiente open source
0 likes357 views
Realizzazione di un modello di router ottico in ambiente open source.
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 donda; ≒ Fino a 160 lunghezze donda, 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 linoltro 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 dallhardware. 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 unaltra lunghezza d'onda in uscita, permettendo cos狸 di risolvere le contese. Svantaggio: dispositivi molto costosi. 18/03/2010 Raul Cafini 6
- 7. Larchitettura 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 竪 larchitettura 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 dallalgoritmo 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 lattuazione dellhardware 竪 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 donda) 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 allinterno 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!: Allinterno 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 dellheader 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 dellinterfaccia 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 donda 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 linterfaccia 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 lheader 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 donda 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 allestensione studiata dal dipartimento; ≒ Obiettivo 5: Lemulazioni 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