Alma Mater Studiorum
Università di Bologna
Facoltà di Ingegneria
Dipartimento di Elettronica, Informatica e Sistemistica
DEIS-TLC
Relazione di attività
sulla creazione di un emulatore per
router ottico programmabile
per reti ibride
Relazione di: Raul Cafini
Correlatori: Carla Raffaelli
Michele Savi
Walter Cerroni
Collaboratori: Ivan Aldaya
retro della copertina
Versione 1
Indice
1 Introduzione.......................................................................................................................................5
1.1 Reti Ottiche e Multigranularità.................................................................................................. 5
1.2 Wavelength Division Multiplexing............................................................................................6
1.3 Optical Switching Paradigms.....................................................................................................6
1.3.1 Optical Circuit Switching...................................................................................................6
1.3.2 Optical Burst Switching..................................................................................................... 7
1.3.3 Optical Packet Switching................................................................................................... 7
1.4 Slotted vs. Unslotted Networks................................................................................................. 7
1.5 Architettura................................................................................................................................ 7
1.6 Contention Reslution................................................................................................................. 8
2 L'Approccio Scelto............................................................................................................................ 8
2.1 Simulazione vs. Emulazione......................................................................................................9
2.2 La proposta IETF ForCES......................................................................................................... 9
2.3 L'estensione del gruppo DEIS-TLC.........................................................................................10
3 Il Modello Software.........................................................................................................................10
3.1 Architettura del nodo............................................................................................................... 10
3.2 Management Plane...................................................................................................................11
3.2.1 Network Management Plane............................................................................................ 12
3.2.2 Node Management Plane................................................................................................. 12
3.2.3 Standard Protocol NETCONF......................................................................................... 12
3.3 Control Plane........................................................................................................................... 12
3.3.1 Standard Protocol RSVP-TE (over GMPLS)...................................................................13
3.3.2 Standard Protocol ForCES............................................................................................... 14
3.4 Forwarding Plane.....................................................................................................................14
3.4.1 Forwarding Element.........................................................................................................15
3.4.2 Switching Module............................................................................................................ 16
4 Il Click!............................................................................................................................................16
4.1 Elementi................................................................................................................................... 17
4.2 Configurazioni......................................................................................................................... 17
4.3 Pacchetto Click!....................................................................................................................... 17
4.3.1 Puntatore.......................................................................................................................... 18
4.3.2 Annotazioni...................................................................................................................... 18
4.3.3 Dati...................................................................................................................................19
4.4 Elementi Propri........................................................................................................................ 19
4.4.1 Creare un nuovo elemento............................................................................................... 19
4.4.2 Metodo simple_action......................................................................................................19
4.4.3 Compilare un nuovo elemento......................................................................................... 19
4.5 Driver Userlevel e Kernelmodule............................................................................................ 20
5 Il Test-Bed....................................................................................................................................... 20
5.1 Architettura.............................................................................................................................. 20
5.1.1 Macchina di Gestione da Remoto.................................................................................... 22
5.1.2 Macchina Generatrice di Traffico.................................................................................... 23
5.1.3 Macchina Router.............................................................................................................. 24
5.1.4 Macchina Ricevitore del Traffico.....................................................................................24
5.2 Management Plane...................................................................................................................25
5.2.1 Management Element.......................................................................................................25
5.3 Control Plane........................................................................................................................... 26
14 dicembre 2010
1
Versione 1
5.3.1 OCS Signaling Channel................................................................................................... 26
5.3.2 Control Element (CE)...................................................................................................... 26
5.3.3 From/To Kernel................................................................................................................ 28
5.4 Forwarding Plane.....................................................................................................................29
5.4.1 From/To User................................................................................................................... 29
5.4.2 Logical Forwarding Element (LFE).................................................................................31
5.4.3 Physical Forwarding Element (PFE) – OCS....................................................................31
5.4.4 Physical Forwarding Element (PFE) – OBS....................................................................31
5.4.5 Physical Forwarding Element (PFE) – OPS.................................................................... 32
5.4.6 Control Bus...................................................................................................................... 32
5.5 Switching Module....................................................................................................................32
5.5.1 Architettura Broadcast & Select.......................................................................................32
5.5.2 EDFAs.............................................................................................................................. 33
5.5.3 WDM Multiplexer & Demultiplexer............................................................................... 33
5.5.4 Fiber Delay Lines.............................................................................................................33
5.5.5 Wavelength Converters (WC).......................................................................................... 33
5.5.6 Splitters & Couplers.........................................................................................................34
5.5.7 Semiconductor Optical Amplifier (SOA)........................................................................ 34
5.6 Livelli di Esecuzione............................................................................................................... 34
5.6.1 Livello Userlevel..............................................................................................................35
5.6.2 Livello Kernelmodule...................................................................................................... 36
5.7 Programmi e Script di Emulazione.......................................................................................... 36
5.7.1 Ricezione del Traffico (deisnet67)................................................................................... 37
5.7.2 Emulatore Router (deisnet 69)......................................................................................... 37
5.7.3 Generazione del Traffico (deisnet68)...............................................................................38
5.8 Caratterizzazione di Potenza....................................................................................................39
5.8.1 Tabelle di funzioni complesse.......................................................................................... 39
5.8.2 Numeri in Virgola Fissa................................................................................................... 39
6 Elenco degli Elementi......................................................................................................................39
6.1 Attenuator.................................................................................................................................39
6.2 Bus........................................................................................................................................... 39
6.3 CEScheduler............................................................................................................................ 39
6.4 CESecurityModule...................................................................................................................39
6.5 CircuitsTable............................................................................................................................ 39
6.6 Click2Data............................................................................................................................... 40
6.7 Combiner................................................................................................................................. 40
6.8 Connector.................................................................................................................................40
6.9 CrossTalk................................................................................................................................. 40
6.10 Data2Click............................................................................................................................. 40
6.11 EDFA..................................................................................................................................... 40
6.12 FEScheduler...........................................................................................................................40
6.13 FMOCSScheduler..................................................................................................................40
6.14 FMOPSScheduler.................................................................................................................. 40
6.15 LabelLookup.......................................................................................................................... 40
6.16 LabelSwap............................................................................................................................. 41
6.17 LogarithmicAttenuator...........................................................................................................41
6.18 NETCONFManager...............................................................................................................41
6.19 NewElement...........................................................................................................................41
6.20 NewHeaderAppend................................................................................................................41
6.21 NoiseSource........................................................................................................................... 41
2
11 novembre 2010
Versione 1
6.22 OCSSignalingChannel........................................................................................................... 41
6.23 OpticalRouterAnnotations..................................................................................................... 41
6.24 Power..................................................................................................................................... 41
6.25 PowerModule.........................................................................................................................41
6.26 ReadAnnotationBytes............................................................................................................ 42
6.27 ReadAnnotation..................................................................................................................... 42
6.28 ReadWavelengthColor........................................................................................................... 42
6.29 RSVPManager....................................................................................................................... 42
6.30 RSVPMessage....................................................................................................................... 42
6.31 SetPower................................................................................................................................ 42
6.32 SetTimeslot............................................................................................................................ 42
6.33 SetTrafficNeed....................................................................................................................... 42
6.34 SOASwitch............................................................................................................................ 42
6.35 Splitter...................................................................................................................................42
6.36 TimeslotManager................................................................................................................... 43
6.37 TimeslotMarker......................................................................................................................43
6.38 TimeWrite.............................................................................................................................. 43
6.39 TunableWavelengthConverter................................................................................................43
6.40 Wavelength............................................................................................................................ 43
6.41 WDMDemultiplexer.............................................................................................................. 43
6.42 WDMMultiplexer.................................................................................................................. 43
6.43 WritePower............................................................................................................................ 43
7 Risultati............................................................................................................................................43
7.1 Validazione...............................................................................................................................44
7.2 Standardizzazione, Multi-granularità e Sicurezza................................................................... 45
7.2.1 RSVP/GMPLS Protocol...................................................................................................51
7.2.2 NETCONF Protocol.........................................................................................................51
7.2.3 ForCES Protocol.............................................................................................................. 52
7.3 Performance............................................................................................................................. 52
7.3.1 Packet header processing time......................................................................................... 52
7.3.2 Time Slot reduction.......................................................................................................... 54
7.4 Caratterizzazione di Potenza....................................................................................................54
7.4.1 Generico percorso del segnale ottico............................................................................... 55
7.4.2 Profili di Potenza e OSNR............................................................................................... 56
8 Software, wiki e manuali................................................................................................................. 58
8.0.1 Pubblicazione dei lavori presentati alle conferenze sul sito del Click!............................58
8.0.2 Pubblicazione del software sul sito del Click! Come pacchetto aggiuntivo del tool;......59
8.0.3 Pubblicazione di un sito per il progetto;.......................................................................... 59
8.0.4 Pubblicazione di un sotto-sito wiki per la documentazione del progetto;.......................59
8.0.5 Pubblicazione di una pagina di interazione con il modello;............................................59
9 Sviluppi futuri..................................................................................................................................60
9.1 Re-Ingegnerizzazione del modello e documentazione............................................................ 60
9.2 Apertura ad altri attori..............................................................................................................60
9.2.1 Laureandi, Borsisti e Dottorandi...................................................................................... 61
9.2.2 Aziende.............................................................................................................................61
9.3 Consumo di Potenza................................................................................................................ 61
9.3.1 Consumo del Piano di Controllo...................................................................................... 61
9.3.2 Consumo del Piano di Inoltro.......................................................................................... 61
9.4 Test sulle performance............................................................................................................. 61
9.4.1 Funzionamento a “polling” delle schede di rete.............................................................. 62
14 dicembre 2010
3
Versione 1
9.5 Interfaccia utente......................................................................................................................62
9.5.1 Soluzione Java..................................................................................................................62
9.5.2 Soluzione PHP................................................................................................................. 62
10 Guide per l'installazione................................................................................................................ 62
10.1 Installazione del Sistema Operativo...................................................................................... 63
10.1.1 Scelta della Distribuzione.............................................................................................. 63
10.1.2 Installazione................................................................................................................... 63
10.1.3 Ottimizzazione Iniziale.................................................................................................. 64
10.1.4 Ottimizzazione Avanzata................................................................................................65
10.2 Installazione del Click! Modular Router............................................................................... 65
10.2.1 Installazione................................................................................................................... 65
10.3 Installazione Interfaccia Grafica Clicky (Opzionale)............................................................ 67
10.4 Installazione e Compilazione di un Kernel per Click!...........................................................67
10.4.1 Download dei sorgenti................................................................................................... 67
10.4.2 Installazione delle Patch.................................................................................................68
10.4.3 Configurazione del Nuovo Kernel................................................................................. 68
10.4.4 Compilazione ed Installazione....................................................................................... 69
10.4.5 Installazione del Click! Con il nuovo Kernel.................................................................69
10.5 Installazione di NETCONF (YUMA)....................................................................................71
10.5.1 Installazione dei sorgenti................................................................................................71
10.5.2 Avvio del Demone NETCONF (netconfd).....................................................................71
10.5.3 Avvio del Client NETCONF (yangcli)...........................................................................72
10.5.4 Realizzazione del Modulo “Optical Router”................................................................. 72
10.5.5 Caricamento del Modulo................................................................................................72
10.6 Installazione del plugin ForCES per Wireshark.................................................................... 73
10.6.1 Reperimento del codice dissector.................................................................................. 73
10.6.2 Installazione di Wireshark..............................................................................................73
10.6.3 Estensione per protocolli aggiuntivi.............................................................................. 73
10.6.4 Installazione del dissector ForCES “nativo”..................................................................73
10.6.5 Installazione del dissector ForCES come “plugin”........................................................73
4
11 novembre 2010
Introduzione
Versione 1
1 Introduzione
Negli ultimi anni, lo scenario di Internet è in continua evoluzione. Le nuove necessità infatti richiedono di poter trasferire una maggiore quantità di informazioni (nel minor tempo possibile)
unite alla crescita esponenziale degli utenti e ad una proliferazione di servizi con richieste di banda e velocità sempre maggiori pongono nuove sfide al mondo delle reti di telecomunicazioni.
•
Problema: i gestori della rete, i centri di ricerca e le aziende del settore si chiedono come
adattare l'infrastruttura esistente ai nuovi requisiti.
Trasporto del traffico su tecnologia ottica (garantisce grandi margini in termini di velocità, quantità e qualità della trasmissione delle informazioni). Le dorsali intercontinentali per telecomunicazioni si basano già su queste tecnologie, Con l'emergere di questi nuovi scenari, si è cominciato a sfruttare a pieno le potenzialità (anche nelle reti di calcolatori) Con il passare degli anni la
tecnologia si è resa disponibile anche in ambito metropolitano e per grandi istituti ed enti di ricerca
Problematiche del trasporto delle informazioni nel dominio ottico: Rispetto e la compatibilità
verso i sistemi esistenti (ad esempio con le reti ATM o quelle basate su protocollo IP) Processamento delle informazioni di instradamento e di inoltro nel dominio ottico (presenza o assenza di
luce) in dispositivi in grado di manipolare ed instradare le informazioni (router ottici) Presenza
di colli di bottiglia (bottleneck) Limiti tecnologici nella realizzazione di alcuni componenti, altrimenti elementari nel dominio elettromagnetico (RAM vs. FDL) Obiettivo: Studio di architetture
per router e soluzioni efficienti, compatibili con i sistemi legacy esistenti, scalabili, dinamiche …
Come studiare queste architetture e tecnologie a basso costo? Come comparare le prestazioni in
maniera veloce Come testare diverse soluzioni in maniera rapida ed economica?
1.1 Reti Ottiche e Multigranularità
Nelle reti ottiche le informazioni viaggiano sotto forma di segnali luminosi, connettendo due
o più Standard Networks periferiche basate sullo scambio di segnali elettromagnetici realizzando una backbone ottica;
Illustrazione 1: Esempio di backbone ottica.
•
•
Edge Router: convertono i segnali da e verso il dominio ottico;
Core Router: scambiano e elaborano segnali nel dominio ottico;
14 dicembre 2010
5
Introduzione
Versione 1
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 realizzando così il concetto di Multi-Granularità.
1.2 Wavelength Division Multiplexing
E’ una tecnica di multiplazione del segnale ottico su diverse lunghezze d’onda (portanti).
I diversi contenuti informativi sono posti in ingresso ad un combinatore ottico (multiplexer
WDM). Il combinatore modula i vari segnali insieme ma su diverse portanti a diverse lunghezze d’onda;
Illustrazione 2: Esempio di modulazione WDM.
Il segnale viaggia così multiplexato all’interno della fibra, a destinazione questa è ripartita in
più copie mediante uno Splitter;
Ogni copia è posta in ingresso ad un filtro per la corrispondente lunghezza d’onda (l) e ogni
contenuto informativo è così riottenuto dal segnale globale.
In gergo le lunghezze d'onda vengono anche chiamate colori e la trasmissione WDM viene
detta colorata, anche se in realtà le lunghezze d'onda usate non sono nel campo del visibile. I
sistemi moderni possono gestire fino a 160 lunghezze d’onda e possono quindi moltiplicare la
banda di una fibra a 10Gbit/s fino ad un limite teorico di circa 1.6Tbit/s.
1.3 Optical Switching Paradigms
Esistono quindi diversi paradigmi in cui può essere realizzata la commutazione del traffico all’interno delle reti ottiche. Le tre principali tecniche sono:
•
Optical Circuit Switching (OCS): paradigma a circuito;
•
Optical Packet Switching (OPS): paradigma a pacchetto;
•
Optical Burst Switching (OBS): via di mezzo tra i due;
1.3.1 Optical Circuit Switching
Fa propria la commutazione di circuito in ambito ottico cercando di costruire dei percorsi tra il mittente ed il ricevente mediante dei messaggi di segnalazione, che viaggiano
6
11 novembre 2010
Introduzione
Versione 1
su un canale dedicato e fuori banda per la mediazione, la creazione e l'abbattimento della connessione.
1.3.2 Optical Burst Switching
Questo tipo di commutazione si trova tra la commutazione di circuito e la commutazione di pacchetto. Il traffico in ingresso dai client ai margini della rete viene aggregato in
base a un parametro particolare, comunemente per destinazione, o tipo di servizio (TOS
byte).
Pertanto, all’Edge Router OBS, code diverse rappresentano le varie destinazioni o la
classe di servizi.
1.3.3 Optical Packet Switching
Trasposizione della commutazione di pacchetto in ambito ottico, in cui viaggiano pacchetti e informazioni di instradamento (G-MPLS) sulla stessa banda (non esistono canali di segnalazione o controllo). Possono esistere due tipologie:
•
OPS Slotted / Sincrono
•
OPS Unslotted / Asincrono
1.4 Slotted vs. Unslotted Networks
•
•
Slotted OPS Networks: Pacchetti di dimensione fissa, posizionati all'interno di intervalli di tempo prefissati detti timeslot (ognuno può contenere un singolo pacchetto) I
nodi lavorano in maniera sincrona mantenendo i confini dei timeslot allineati fra loro
(richiede uno stadio di sincronizzazione). Minor numero di contese tra pacchetti (essendo di lunghezza fissa vengono inoltrati insieme con i limiti degli slot allineati).
Compatibile con ATM
Unslotted OPS Networks: I pacchetti possono essere di dimensione variabile, Il tempo non è suddiviso in timeslot. I nodi su questa tipologia di rete lavorano in maniera
asincrona senza alcun requisito di allineamento. Presenta un numero maggiore di contese da risolvere. Compatibile con IP
1.5 Architettura
•
•
•
•
Input Interface (IF): Delineazione del pacchetto (Guard Band) Sincronizzazione (reti
OPS-Slotted): allineamento di pacchetti appartenenti allo stesso timeslot Pre-processamento dell'header separazione header e payload e converisione OE dell’header Buffer: Immagazzinamento delle informazioni in attesa del processamento elettronico dell’header.
Control Unit: Operazioni di controllo ed inoltro (nel dominio elettronico) del traffico
in accordo a degli algoritmi di scheduling sulle informazioni contenute negli header
dei pacchetti.
Switching Matrix (SM): Set-up dei dispositivi interni (FDL, Convertitori TWC, Switch SOA o MEMS) Inoltro del payload dall’unità di buffer all’output interface
Output Interface (OI): Aggiornamento dell’header (nuove informazioni in uscita dal
nodo da ricongiungere al payload) Rigenerazione 3R del segnale (reamplification, reshaping, retiming) Sincronizzazione (solo in reti OPS-Slotted)
14 dicembre 2010
7
Introduzione
Versione 1
1.6 Contention Reslution
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 si parla di contesa.
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
Nel dominio elettromagnetico (EPS) il problema è affrontato nel dominio del tempo usando le
memorie RAM come code. In ambito ottico (OPS) ci si scontra con un limite tecnologico, la
difficoltà di implementare un componente che agisca come memoria ottica. Questi componenti, detti:
Fiber Delay Lines (FDL) non permettono di immagazzinare l’informazione ma solo di ritardarne il suo percorso di un tempo fissato. L'approccio OPS permette di affrontare la contesa
nel dominio delle lunghezze d'onda (wavelength domain) sfruttando le proprietà della conversione.
Illustrazione 3: Fiber Delay
Line.
Illustrazione 4: Tunable
Wavelength Converter.
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.
2 L'Approccio Scelto
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 MultiGranulare (OPS-Slotted e OCS) e in linea con le raccomandazioni espresse in ForCES (RFC3746);
8
11 novembre 2010
L'Approccio Scelto
◦
Versione 1
Analisi e valutazione dei livelli di potenza e consumo all’interno del nodo.
2.1 Simulazione vs. Emulazione
•
•
Simulazione: prevede 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.
◦ I parametri di configurazione devono essere impostati correttamente
◦ Le interazioni tra il controllo (le decisioni di forwarding) e il set-up dell'hardware
di commutazione non è effettivamente messo in evidenza attraverso la simulazione;
◦ Se il traffico in ingresso simulato non è realistico, questo potrebbe generare risultati fuorvianti.
Emulazione: si differenzia per la caratteristica di duplicare in tutto per tutto le funzioni di un determinato sistema su un secondo sistema differente dal primo.
◦ Modularità: una volta definiti, i moduli possono essere aggiunti, rimossi, collegati
e scambiati per ottenere diverse architetture;
◦ Chiarezza del 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 possono essere testati, anche se il costoso hardware che li costituisce nella realtà non è disponibile;
◦ Facile modifica del traffico in ingresso: può essere facilmente modificato cambiando soltanto le proprietà della sorgente (e non l’intero simulatore).
2.2 La proposta IETF ForCES
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).
14 dicembre 2010
9
L'Approccio Scelto
Versione 1
Illustrazione 5: Schema di relazioni tra CE ed FE secondo
la direttiva ForCES.
2.3 L'estensione del gruppo DEIS-TLC
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.
3 Il Modello Software
Si è deciso quindi di approntare un test-bed su hardware PC per collaudare tutti i meccanismi,
validare e valutare le prestazioni delle proposte in atto.
3.1 Architettura del nodo
Si è dunque approntata un modello di architettura del nodo come visibile in figura:
10
11 novembre 2010
Il Modello Software
Versione 1
Illustrazione 6: Piani dell'architettura del nodo (Network Element NE).
N.B: Spesso a seguire si troverà la dicitura FM alternativa ma duale a quella PFE!!!
Il nodo (o Network Element NE secondo la dicitura ForCES), è rappresentato suddiviso nei suoi
3 piani fondamentali:
•
(Node) Management Plane;
•
(Node) Control Plane;
•
(Node) Forwarding Plane;
Inoltre il nodo è interconnesso alla rete ed in particolare al piano di management della stessa:
•
(Network) Management Plane;
In figura sono presenti le connessioni interpiano e, ove previsto, queste sono corredate dall'opportuno standard utilizzato.
14 dicembre 2010
11
Il Modello Software
Versione 1
3.2 Management Plane
Piano deputato alla gestione del nodo. Il nodo è una risorsa dispendiosa ed è prevista la sua
condivisione da parte di più utenti abilitati alla suddivisione della risorsa stessa. Possiamo individuare così due entità:
•
Host Operator (HO): entità proprietaria dell'hardware del nodo, responsabile della
condivisione della risorsa.
•
Guest Operator (GO): entità appaltatrice della risorsa e dei suoi servizi (ad. Esempio
un Internet Service Provider (ISP))
Uno o più GO possono dunque interagire con la risorsa e richiedere l'attivazione o la rimozione di servizi e/o risorse secondo il contratto d'uso del nodo firmato con l'HO.
Nella architettura il piano di management si può riferire alla rete o al nodo:
3.2.1 Network Management Plane
Piano di gestione della rete. E' formato dagli elementi:
•
Network Management (NM): è il punto da cui la rete invia e riceve le informazioni di configurazione del nodo.
In pratica è il punto da cui il GO invia i comandi di configurazione del nodo a
suo piacimento (in base ad un contratto stabilito tra GO e HO) mediante il protocollo NETCONF.
3.2.2 Node Management Plane
Piano di gestione del nodo. E' formato dagli elementi:
•
Management Element (ME): è il punto da cui il nodo riceve e invia le informazioni che riguardano la sua configurazione.
In pratica è il punto da cui l'HO riceve i comandi di configurazione del nodo da
parte di un GO. Si controlla se questi è autorizzato (meccanismo basato su SSH)
e si da luogo alla configurazione richiesta mediante il protocollo NETCONF.
3.2.3 Standard Protocol NETCONF
Il NM ed il ME comunicano attraverso lo standard NETCONF. Il Network Configuration Protocol, o NETCONF, è un protocollo IETF di gestione della rete, pubblicato nel
dicembre 2006 come RFC 4741.
N.B: I dettagli del NETCONF sono fruibili nel lavoro di tesi di Ramon Righini che
ha curato in maniera approfondita questo aspetto nel suo lavoro!!!
NETCONF fornisce meccanismi per installare, modificare e eliminare configurazioni
dei dispositivi di rete. Le sue interazioni sono realizzate mediante semplici Remote Procedure Call (RPC) di alto livello.
Il protocollo NETCONF utilizza l'Extensible Markup Language (XML) per la codifica
di dati di configurazione così come per i messaggi di protocollo. Questo a sua volta
viaggia in cima al protocollo di trasporto (es. SSH).
Operazioni di Base: Il protocollo di base include le operazioni seguente protocollo:
<get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>,
<close-session> , <kill-session>.
12
11 novembre 2010
Il Modello Software
Versione 1
3.3 Control Plane
Piano deputato al controllo del nodo. Si compone dei seguenti elementi:
•
Control Element (CE): elemento deputato al controllo del nodo, si interfaccia con i
differenti piani:
◦ Piano di management del nodo (dialoga con il ME)
◦ Piano si forwarding del nodo (dialoga con il FE via ForCES Protocol)
◦ Canali di segnalazione fuori banda (dialoga via RSVP-TE / GMPLS)
Illustrazione 7: Control
Element.
3.3.1 Standard Protocol RSVP-TE (over GMPLS)
Il meccanismo di segnalazione fuori banda utilizzato nel paradigma a circuito (OCS) si
avvale dell'uso del protocollo RSVP-TE basato su GMPLS per riservare le risorse necessarie al circuito nei nodi intermediari la comunicazione tra mittente e destinatario del
traffico a circuito.
•
Resource Reservation Protocol – Traffic Engeneering (RSVP-TE) : è un protocollo di prenotazione e differisce in modo sostanziale dai protocolli di segnalazione convenzionali usati nelle reti orientate alla connessione.
Illustrazione 8: Schema di interazione protocollo RSVP.
Uno dei presupposti chiave di RSVP è quello di non togliere nulla alla robustezza attuale delle reti prive di connessione, tali reti si basano sul fatto di non avere
informazioni di stato (o averne pochissime) memorizzate al proprio interno, pertanto è possibile che i router interrompano bruscamente il proprio funzionamento e si riavviino o che le linee di collegamento si guastino e poi riprendano la
14 dicembre 2010
13
Il Modello Software
•
Versione 1
propria operatività, senza che la connettività tra i nodi terminali sia compromessa.
Il protocollo RSVP cerca di mantenere viva questa robustezza usando il concetto
di stato soft nei router: lo stato soft, al contrario dello stato hard che si usa nelle
reti orientate alla connessione, non ha bisogno di essere rimosso esplicitamente
quando non è più necessario perché scade dopo un periodo di tempo opportuno
se non viene periodicamente aggiornato.
Un'altra caratteristica di RSVP è quella di supportare i flussi multicast con la
stessa efficacia di quella offerta ai flussi unicast. Questo protocollo fa uso di un
approccio orientato ai destinatari. Piuttosto che lasciare il compito al mittente di
tenere traccia di un numero di destinatari potenzialmente elevato, è più sensato
che siano i destinatari a gestire le proprie necessità, come un'unica persona che
parla e tante che ascoltano una lezione tenuta su una rete Mbone.
◦ Funzionamento:
▪ Fase di Downstream: ovvero una fase di discovery basata su messaggi
in grado di definire un “percorso”. Il mittente indirizza un pacchetto di
tipo PATH verso il primo router del percorso fino all'host destinatario.
Nel suddetto pacchetto sono indicati il Phop, Sender_Tspec e Adspec. Il
Phop è l'indirizzo del router al passo precedente, mentre Sender_Tspec e
Adspec includono informazioni sulle caratteristiche richieste alla linea
che si intende prenotare. Quando un router riceve il PATH, aggiorna le
sue informazioni, aggiorna il timer della prenotazione ed inoltra il PATH
al router successivo, dopo aver modificato il campo Phop.
▪ Fase di Upstream: viene spedito a ritroso un pacchetto di tipo RESV
contente il FlowSpec. Ogni router valuterà tramite l'Admission Control
se tale traffico è accettabile dalla rete, e in caso aggiunge al Packet Classifier le informazioni su tale traffico ricavate dal FilterSpec, e al Packet
Scheduler le informazioni tratte dal FlowSpec per poter fare un corretto
scheduling. Inoltre aggiorna il timer associato allo stato RESV e inoltra il
pacchetto al router indicato nel Phop, fino al mittente originale. In caso il
traffico non sia accettabile dalla rete, viene generato un messaggio di errore.
Applicare RSVP con IntServ porta ad avere una scarsa scalabilità, in quanto è
necessario mantenere le informazioni di stato per ciascun microflusso, e il numero di questi microflussi può risultare molto elevato (basti pensare che solitamente un microflusso è individuato da 5-tuple: indirizzo IP sorgente, indirizzo IP destinazione, porta sorgente, porta destinazione e protocol ID). È tuttavia errato
pensare che sia RSVP a essere poco scalabile. Infatti può essere utilizzato con
successo nel campo dell'MPLS, laddove l'approccio non è a microflusso ma a
flussi aggregati.
Generalized Multi Protocol Label Switching (GMPLS): sd
4
3
2,5
2
1
14
Layer
Transport
Network
Link
Physical
Protocol
RSVP-TE
IP
GMPLS
Ethernet, Optical Lambda
Cable, Fiber, ...
11 novembre 2010
Il Modello Software
Versione 1
3.3.2 Standard Protocol ForCES
Il protocollo ForCES è definito dall'IETF nelle RFC 5810 e seguenti per definire un linguaggio comune per la separazione tra gli elementi di controllo ed inoltro all'interno di
dispositivi di rete.
N.B: I dettagli del NETCONF sono fruibili nel lavoro di tesi di Ramon Righini che
ha curato in maniera approfondita questo aspetto nel suo lavoro!!!
3.4 Forwarding Plane
Il Forwarding Plane è il piano in cui riceviamo il traffico e lo smistiamo verso la destinazione
richiesta. E' formato dai seguenti elementi:
•
Forwarding Element (FE): è l'elemento deputato alla gestione delle funzioni di inoltro del traffico. Molto più ampiamente si può suddividere questo elemento, in accordo
all'idea proposta dal nostro gruppo di ricerca, in due piani distinti in base alle conoscenze dirette sull'hardware sottostante.
•
Header Tap: elemento che separa la parte di informazioni trasportate in banda dal
traffico a pacchetto (OPS).
•
Switching Module: modulo di commutazione, ovvero l'insieme dei dispositivi che
realizza l'hardware per l'inoltro del traffico. Teoricamente questo modulo può rappresentare un qualsiasi tipo di hardware destinato allo smistamento del traffico sia questo
nel dominio elettronico (dispositivi switch elettronici) sia ottico (dispositivi ottici
SOA, MEMS etc..).
3.4.1 Forwarding Element
Il Forwarding Element FE è un oggetto contenitore di due entità distinte: una parte
“hardware independent” che conterrà al suo interno le funzionalità logiche della fase di
inoltro (es. Label Lookup, ...) detta LFE e una parte “hardware dependent” che conterrà
al suo interno le funzionalità più a stretto contatto con l'hardware della fase di inoltro
(es. Attivazione dei dispositivi):
Illustrazione 9: Forwarding Element.
14 dicembre 2010
15
Il Modello Software
◦
Versione 1
Logical Forwarding Element (LFE): è l'elemento che secondo la concezione del
nostro gruppo di lavoro è deputato allo svolgimento di quelle azioni necessarie all'inoltro del traffico che siano però indipendenti dallo stato dell'hardware realizzando quindi una separazione di funzionalità di tipo “hardware-independent” (nessuna
conoscenza dello stato della matrice e della tipologia dei suoi componenti). Può instanziare a tal proposito uno o più PFE in grado di gestire l'hardware per un determinato servizio offerto (es. OPS, OCS, …):
Illustrazione 10: Logical FE.
◦
Physical Forwarding Element (PFE ex Forwarding Module FM): è l'elemento
che secondo la concezione del nostro gruppo di lavoro è deputato allo svolgimento
di quelle azioni necessarie all'inoltro del traffico che siano però fortemente dipendenti dallo stato dell'hardware realizzando quindi una separazione di funzionalità
di tipo “hardware-dependent” (totale conoscenza dello stato della matrice e della
tipologia dei suoi componenti).
Illustrazione 11:
Physical FE.
3.4.2 Switching Module
Il modulo di commutazione è l'insieme dei dispositivi che realizza l'hardware per l'inoltro del traffico. Teoricamente questo modulo può rappresentare un qualsiasi tipo di hardware destinato allo smistamento del traffico sia questo nel dominio elettronico (dispositivi switch elettronici) sia ottico (dispositivi ottici SOA, MEMS etc..).
16
11 novembre 2010
Il Modello Software
Versione 1
Illustrazione 12: Switching Module.
Nel nostro caso l'implementazione prevede lo studio e la caratterizzazione di un router
ottico, e di conseguenza lo switching module sarà del tipo:
◦ Optical Switching Module: al suo interno può presentare varie architetture composte da diversi dispositivi in uso nelle matrici ottiche per indirizzare il traffico verso
lunghezze d'onda o percorsi differenti. Nel nostro caso avremo una architettura del
tipo Broadcast & Select:
▪ Archtettura Broadcast & Select: è un tipo di architettura in cui il traffico è indirizzato verso tutte le uscite possibili e successivamente autorizzato a lasciare
solo l'interfaccia voluta.
Illustrazione 13: Esempio dell'architettura B&S utilizzata.
Come si vede il traffico in ingresso, opportunamente convertito in lunghezza d'onda
per risolvere eventuali contese, viene inviato contemporaneamente a tanti pool di SOA
quante sono le uscite (broadcast). Questi opportunamente attivati (select) indirizzano il
traffico verso l'uscita desiderata.
4 Il Click!
Il Click! è un framework open source modulare, orientato alla realizzazione di dispositivi come:
•
Router, processori di pacchetti, sorgenti di traffico, Ethernet switch, firewall, etc.
14 dicembre 2010
17
Il Click!
Versione 1
Basato su piattaforma GNU/Linux è sviluppato dal MIT, si avvale di un Linguaggio Dichiarativo (human-readable).
Illustrazione 14: Click! Modular Router Logo.
4.1 Elementi
Il software Click è scritto in C++ ed ogni elemento appartiene ad una sottoclasse della classe
“Element” la quale contiene diverse funzioni virtuali (push, pull e run_scheduled, … ) base
per il funzionamento di tutti gli elementi.
Gli elementi possono avere più porte in ingresso o in uscita (identificate dalle parentesi e dal
numero della porta [0]) e queste possono essere di tipo push, pull e agnositche.
E’ possibile definire elementi composti (da più sotto-elementi, vedi elementclass) e/o implementare elementi personalizzati per scopi particolare scrivendone direttamente il codice C++.
E’ stato proprio il nostro caso in cui abbiamo definito nuovi elementi per modellare i componenti ottici del router (SOA, Splitter, Combiner, etc…) per caratterizzarli nel comportamento
logico e fisico.
4.2 Configurazioni
Le configurazioni sono dei semplici file di testo con estensione .click. Sono normalmente separati in due sezioni diverse:
•
Sezione delle Dichiarazioni: in questa sezione vengono definiti gli elementi da utilizzare nella configurazione specificando un nome dell'istanza e la classe di appartenenza
ad esempio:
◦ nome_istanza::Classe(parametri_della_classe);
•
Sezione dei Collegamenti: in questa sezione gli elementi precedentemente definiti
vengono collegati (mediante l'operatore ) in modo da definire il percorso che il flusso dati percorrerà una volta in esecuzione la configurazione.
◦ istanza1->istanza2
Elementi composti: esiste anche la possibilità di definire un macro elemento che contiene al
suo interno diversi elementi raggruppandoli in un unico contenitore. Questa soluzione è possibile definendo un elemento come elementclass:
•
•
18
elementclass NomeClasse{parametri |
// definizione elementi
11 novembre 2010
Il Click!
Versione 1
•
istanza1::Classe1();
•
istanza2::Classe2();
•
// definizione connessioni
•
input->istanza1->istanza2->output;
•
}nome_istanza_nuova_classe;
Un oggetto del tipo elementclass è dunque una classe che racchiude al suo interno altri elementi base interconnessi tra loro. Questi oggetti vengono poi espansi dal Click in fase di esecuzione del file di configurazione.
Esempio di configurazione: di seguito viene illustrata un semplice file di configurazione click:
// Sezione Dichiarazioni
source::TimedSource(INTERVAL 1, LIMIT 5);
print::Print(“Hello”);
sink::Discard();
// Sezione Collegamenti
source->print->sink;
questa configurazione definisce una sorgente di pacchetti attiva ad intervalli di 1 secondo che
genera 5 pacchetti passati ad un elemento che li stampa ed un altro che li distrugge.
4.3 Pacchetto Click!
Il pacchetto Click è l'astrazione dei dati di rete che fluiscono all'interno di un file di configurazione. Per non consumare risorse il software non fa attraversare all'intero blocco dati tutti gli
elementi della configurazione ma li fa attraversare dalla sua astrazione “pacchetto click” che
punta in qualche modo sempre ai dati senza portarsi la loro pesantezza dietro.
In particolare dunque il pacchetto Click! è composto da:
•
Puntatore: ai dati reali.
•
Annotazioni: byte di appoggio per l'utente click.
•
Dati: dati reali del pacchetto in arrivo dalla rete.
Illustrazione 15: Il pacchetto secondo la rappresentazione
Click!.
Le annotazioni sono state usate come memoria comune tra gli elementi del nodo: Ogni volta
che un pacchetto Click! Attraversa un elemento, questo può:
•
Leggere ed interpretare le informazioni presenti nelle annotazioni al fine di determinare le azioni da intraprendere
•
Scrivere/Modificare le informazioni presenti come risultato della sua operazione
In uscita dal modello possiamo dunque catalogare tutte le informazioni contenute nelle annotazioni dei pacchetti per caratterizzare il comportamento del router.
14 dicembre 2010
19
Il Click!
Versione 1
E' importante inoltre distinguere tra pacchetti standard e di tipo writable:
•
Standard Packet: sono così tutti i pacchetti che riceviamo dalla rete, non sono modificabili nei loro dati.
•
Writable Packet: tutti i pacchetti per cui cambia il campo dati sia in valore sia in dimensione vanno ricreati come WritablePacket.
Tutte le informazioni sui campi e i metodi relativi all classe packet (e in generale a tutte le
classi) possono essere recuperati sul sito del Click! nella sezione API Documentation Classess Packet (http://read.cs.ucla.edu/click/doxygen/classPacket.html).
4.3.1 Puntatore
Il puntatore è lo strumento in grado di riferirsi alle diverse strutture del pacchetto Click!
Negli elementi usati è possibile mediante il puntatore Packet *packet, riferirsi al campo
annotazioni o dati:
•
packet->anno_<dim>
•
packet->data()
4.3.2 Annotazioni
Le annotazioni sono dei byte a disposizione dell'utente per marcare con diversi significati i pacchetti all'interno di una configurazione.
La dimensione totale delle annotazioni è di 48 bytes e i loro valori, nel caso del nostro
emulatore, sono definiti per gli elementi click che ne fanno uso nel file “CLICKDIR/elements/local/OpticalRouterAnnotations.hh” mentre se vi vogliamo far riferimento nel file
di configurazione click, come nel nostro caso, vanno definite all'inizio (come nei file
.click del nostro testbed).
E' possibile accedere ai byte dei dati mediante il puntatore:
•
packet->data() punta al byte 0 del pacchetto (es. il primo byte dell'intestazione
Ethernet)
4.3.3 Dati
Il campo dati del pacchetto rappresenta il vero “pacchetto” che viene ricevuto dal nodo
in esame, a partire dall'intestazione Ethernet in su.
E' possibile accedere ai byte dei dati (in sola lettura se il pacchetto è standard, in lettura
e scrittura se di tipo “writable”) mediante il puntatore:
•
packet->data() punta al byte 0 del pacchetto (es. il primo byte dell'intestazione
Ethernet)
4.4 Elementi Propri
La estendibilità del Click! e del nostro emulatore si concretizza con la possibilità di definire
nuovi elementi (nuove classi) con funzionalità logiche proprie e specifiche.
Nel nostro caso abbiamo deciso di definire classi per tipologie di elementi sia reali (come i dispositivi di commutazione, SOA, TWC, etc...) sia logici (scheduler ed elementi del piano di
controllo).
20
11 novembre 2010
Il Click!
Versione 1
4.4.1 Creare un nuovo elemento
Per creare un nuovo elemento occorre in particolare definire due files (in generale nella
cartella “CLICKDIR/elements/local”):
•
NewElement.cc: contiene il codice implementativo delle funzioni dell'elemento.
•
NewElement.hh: contiene le definizioni di variabili globali e metodi.
4.4.2 Metodo simple_action
La maggior parte degli elementi è caratterizzata da un singolo metodo in fase di funzionamento, ovvero quando un pacchetto click attraversa l'elemento.
Questo metodo prende nome di “simple_action” e fornisce un puntatore al pacchetto
click, e lo restituisce alla fine.
Questo metodo viene scatenato quando un pacchetto arriva in ingresso all'elemento e da
li in poi il click esegue il codice C presente nel metodo.
Nel codice, grazie al puntatore è possibile leggere e scrivere i dati e le annotazione in
modo da definire il comportamento logico dell'elemento.
Alla fine del metodo occorre sempre restituire il pacchetto con l'istruzione return packet
oppure con return 0;
Per distruggere il pacchetto e non ritornare nulla occorre eseguire packet->kill() seguita
da return 0;
4.4.3 Compilare un nuovo elemento
Una volta finita la creazione del nostro elemento (salvato in “CLICKDIR/elements/local”) occorre riposizionarsi sulla cartella principale ed eseguire:
•
[root@deisnetXX click-git]# make elemlist
Questo comando serve a dire al click che è stato aggiunto un nuovo elemento e in fase
di compilazione dovrà tenerne conto!!!
Ora si può compilare il tutto con il comando:
•
[root@deisnetXX click-git]# make install
N.B: La fase di compilazione di consta di due fasi:
•
La prima fase si compila il codice C dell'elemento e qui vengono fuori problemi
relativi alla sintassi dell'elemento.
•
La seconda fase, invece, il compilatore si occupa di linkare (fase che inizia con
la stringa “LINK” mostrata a video) le librerie necessarie all'elemento e creare i
moduli oggetto usrlevel e kernelmodule.
◦ N.B.B: E' proprio qui se capita qualche errore per il modulo kernel che viene
notificato, e il modulo kernel del click non sarà loadable finchè questi problemi non saranno risolti (si va da un blocco della compilazione perchè le librerie non sono raggiungibili fino ad una semplice notifica di simbolo non
definito che poi impedisce il caricamento dell'elemento.. occhio!!!)
14 dicembre 2010
21
Il Click!
Versione 1
4.5 Driver Userlevel e Kernelmodule
Una configurazione Click gira all’interno di un driver che implementa le funzioni usate da tutti gli elementi. Esistono due driver:
•
User-level driver: è un’applicazione a livello utente, che interviene sui pacchetti IP
separatamente dal kernel (quindi dipende da come il kernel gestisce il flusso di pacchetti IP);
•
Linux-kernel driver: funziona come modulo caricabile nel kernel e può completamente rimpiazzare le funzionalità di rete del sistema operativo (offre maggiori prestazioni);
5 Il Test-Bed
Il nostro gruppo ha provveduto alla realizzazione di un piccolo test-bed hardware approntando
tre macchine in laboratorio per eseguire le prove di emulazione.
5.1 Architettura
L'architettura del test-bed è rappresentata in figura:
Illustrazione 16: L'architettura del Test-Bed approntato in laboratorio.
22
11 novembre 2010
Il Test-Bed
Versione 1
Come si evince dall'immagine il test-bed vero e proprio è rappresentato dalla macchina router
(deisnet69) che si trova al centro dello schema.
Alla sinistra troviamo il generatore di traffico OPS/OCS (deisnet68) e alla destra il ricevitore
del traffico (deisnet67)
Infine possiamo notare la macchina di gestione remota del test-bed (deisnet209) e il gateway
che fa da portale verso internet (deisnet254).
Tutte queste macchine sono collegate tra loro mediante la rete interna del deis (deisnet) con
indirizzi 192.168.10.XX dove XX è il numero della macchina, sulle rispettive interfacce di
rete “eth0”. Su questa rete (e quindi se ci poniamo in ascolto sulle interfacce “eth0” di queste
macchine) viaggiano:
•
Il traffico DEIS-TLC da/verso Internet che costituisce il grosso del traffico;
•
I segnali di controllo remoto del test-bed (sessioni X e ssh dalla macchina di gestione
remota deisnet209 verso deisnet67/68/69);
•
I messaggi di segnalazione fuori banda del traffico OCS test-bed (Protocollo RSVP)
•
I messaggi di gestione del nodo da parte dei GOs via HOs (Protocollo NETCONF)
Inoltre le macchine che più strettamente fanno parte del test-bed, ovvero generatore (deisnet68), router (deisnet69) e ricevitore (deisnet67) sono collegate tra loro mediante ulteriori interfacce di rete in una configurazione:
•
Il generatore (deisnet68) invia il traffico OPS, OCS e la segnalazione OPS (in banda)
attraverso la sua seconda interfaccia di rete “eth1” direttamente collegata all'ingresso
del router. La segnalazione OCS (fuori banda) viene inviata tramite “eth0” sempre
verso il router.
•
Il router (deisnet69) riceve il traffico in ingresso OPS, OCS e la segnalazione OPS (in
banda) attraverso la sua seconda interfaccia di rete “eth2” direttamente collegata al generatore di traffico. La segnalazione OCS (fuori banda) viene ricevuta tramite “eth0”.
A questo punto il router analizza le informazioni di routing in banda per l'OPS o le
eventuali richieste fuori banda per OCS elabora i messaggi e il traffico.
Il Il router invia il traffico OPS, OCS e la segnalazione OPS (in banda) se correttamente schedulati attraverso la sua terza interfaccia di rete “eth1” direttamente collegata al
ricevitore di traffico. La segnalazione OCS (fuori banda) viene inviata tramite “eth0”.
•
Il ricevitore (deisnet67) riceve il traffico OPS, OCS e la segnalazione OPS (in banda)
attraverso la sua seconda interfaccia di rete “eth1” direttamente collegata all'uscita del
router. La segnalazione OCS (fuori banda) viene inviata tramite “eth0” sempre dal il
router.
5.1.1 Macchina di Gestione da Remoto
Questa macchina in realtà può essere una qualsiasi macchina sotto la rete deisnet
192.168.10.X in grado di collegarsi via terminale SSH alle macchine del test-bed per
avviare, terminare e monitorare le emulazioni.
14 dicembre 2010
23
Il Test-Bed
Versione 1
Illustrazione 17: La macchina di gestione da
remoto deisnet209.
Nel periodo in esame tale macchina era a disposizione nel box laureandi con una installazione Linux FC12 simile a quelle installate nel test-bed ed in particolare:
•
Nome: deisnet209
•
Utenti
◦ Utente: raul.cafini
◦ Password Utente: raul.cafini
•
Root
◦ Utente Root: root
◦ Password Root: 209raul
Da qui ci si connette aprendo il terminale linux e connettendosi come utente root via
SSH alle macchine in laboratorio:
•
[root@deisnet209 /]# ssh -X [email protected]
N.B: Il parametro -X serve per utilizzare il server X11 (interfaccia grafica) della macchina locale per renderizzare le applicazioni grafiche delle macchine in laboratorio (es.
gedit e wireshark).
5.1.2 Macchina Generatrice di Traffico
La macchina generatrice di traffico (deisnet68 IP:192.168.10.68) è collegata alla rete
deisnet mediante l'interfaccia “eth0” dalla quale riceve il controllo remoto dalla macchina di gestione deisnet209.
24
11 novembre 2010
Il Test-Bed
Versione 1
Illustrazione 18: La macchina generatrice di
traffico deisnet68.
In particolare ad essa si accede con le seguenti credenziali:
•
Nome: deisnet68
•
Utenti
◦ Utente: user68
◦ Password Utente: user68
•
Root
◦ Utente Root: root
◦ Password Root: opticalrouter
Questa macchina è destinata ad eseguire processi di generazione di traffico e segnalazione OPS e OCS ed inoltrarli attraverso le opportune interfacce di rete al fine di raggiungere il nodo router.
L'area di lavoro di questa macchina è composta dalle seguenti directory:
•
/home/user68/
Directory di lavoro principale
•
/home/user68/Configurazioni
Directory contenente i file di generazione
5.1.3 Macchina Router
La macchina router (deisnet69 IP:192.168.10.69) è collegata alla rete deisnet mediante
l'interfaccia “eth0” dalla quale riceve il controllo remoto dalla macchina di gestione deisnet209.
14 dicembre 2010
25
Il Test-Bed
Versione 1
Illustrazione 19: La macchina router deisnet69
In particolare ad essa si accede con le seguenti credenziali:
•
Nome: deisnet69
•
Utenti
◦ Utente: user69
◦ Password Utente: user69
•
Root
◦ Utente Root: root
◦ Password Root: opticalrouter
Questa macchina è destinata ad eseguire i processi di emulazione del nodo ottico sia a
livello user (configurazione eseguita come processo) sia livello kernel (configurazione
inserita come modulo kernel).
L'area di lavoro di questa macchina è composta dalle seguenti directory:
•
/home/user69/
Directory di lavoro principale
•
/home/user69/Configurazioni
Directory con i file di configurazione
•
/home/user69/click-git
Directory contenente il click
•
/home/user69/click-git/elements/local Directory contenente gli elementi
5.1.4 Macchina Ricevitore del Traffico
La macchina ricevitore di traffico (deisnet67 IP:192.168.10.67) è collegata alla rete deisnet mediante l'interfaccia “eth0” dalla quale riceve il controllo remoto dalla macchina
di gestione deisnet209.
26
11 novembre 2010
Il Test-Bed
Versione 1
Illustrazione 20: La macchina ricevitore di traffico
deisnet67.
In particolare ad essa si accede con le seguenti credenziali:
•
Nome: deisnet67
•
Utenti
◦ Utente: user67
◦ Password Utente: user67
•
Root
◦ Utente Root: root
◦ Password Root: opticalrouter
Questa macchina è destinata ad eseguire processi di cattura del traffico (correttamente
schedulato dal router) e della segnalazione OPS e OCS, rispondere alla segnalazione
fuori banda OCS e memorizzare statistiche su di esso.
L'area di lavoro di questa macchina è composta dalle seguenti directory:
•
/home/user67/
Directory di lavoro principale
•
/home/user67/Configurazioni
Directory contenente i file di ricezione
5.2 Management Plane
La gestione del nodo da parte di GO e HO è realizzata mediante l'uso del protocollo NETCONF attraverso la sua implementazione open source provvista dalla suite di tool YUMA.
5.2.1 Management Element
E' composto da:
•
Demone NETCONFd:
◦ Modulo “opticalrouter”: è un semplice file di testo (con estensione .yang)
scritto nel metalinguaggio definito da YUMA. Qui sono dunque definite le
14 dicembre 2010
27
Il Test-Bed
Versione 1
•
operazioni che il GO, una volta caricato il modulo lato server e autenticato il
GO via SSH al nodo del router dove è in esecuzione il demone netconfd, può
richiedere. Ogni operazione eseguirà una chiamata via RPC tra nodo client
(GO) e nodo server (HO o nodo router) per eseguire una determinata azione.
Le azioni definite nel modulo “opticalrouter.yang” sono:
▪ Aggiungere un indirizzo IP alla WhiteList :
•
add-address address=<ip-address>
▪ Rimuove un indirizzo IP dalla WhiteList
•
remove-address address=<ip-address>
▪ Ridurre il throughput OPS di un numero di canali
•
reduce-bandwidth channels=<channels-number>
Il codice eseguibile relativo alle operazioni chiamate è definito nel file opticalrouter.c (vedi installazione di netconf).
Nel nostro caso, all'invocazione di uno dei comandi di cui sopra, abbiamo
creato un pacchetto UDP da inviare alla configurazione clcik in ascolto sull'interfaccia di loopback contenente le informazioni sul tipo di azione (primo
byte) e sul valore passato come parametro (indirizzo IP). Il pacchetto UDP è
inviato sull'interfaccia di segnalazione del modello e catturato dal NETCONFManager.
NETCONF Manager: è il modulo deputato alla gestione dei messaggi di protocollo gestione.
5.3 Control Plane
Il controllo del nodo passa per una serie di componenti che gestiscono le varie mansioni.
5.3.1 OCS Signaling Channel
E' un elemento click composto, che funge da canale di segnalazione fuori banda per il
paradigma a pacchetto:
Illustrazione 21: Schema a blocchi elemento
OCSSignalingChannel.
All'elemento provengono pacchetti dalla rete (su interfaccia eth0 su cui viaggia la segnalazione OCS via RSVP) o dal nodo stesso (messaggi di risposta alla segnalazione).
I pacchetti in ingresso dalla rete (ingresso [0]) vengono analizzati da un Classifier che
filtra il traffico, ad esempio in caso di pacchetti di tipo ARP risponde per mantenere fun-
28
11 novembre 2010
Il Test-Bed
Versione 1
zionante lo smistamento dei pacchetti IP nella rete mentre permette ai soli pacchetti
IP/RSVP di entrare nel modello.
I pacchetti IP portatori di RSVP vengono spogliati della loro intestazione IP ed Ethernet
ed inviati all'oggetto OCSSignalingChannel.
I pacchetti provenienti dal nodo, ossia il CE (ingresso [1] messaggi in risposta ad una
precedente richiesta sul canale di segnalazione) giungono anch'essi direttamente all'OCSSignalingChannel.
L'elemento OCSSignalingChannel discrimina la provenienza e la destinazione dei pacchetti (es. dalla rete verso il CE o dal CE verso la rete) e insieme all'outputSwitch:
•
Rispedisce i messaggi destinati alla rete aggiungendovi l'intestazione IP ed
Ethernet opportuna (settata via click handler dall'RSVPManager)
•
Oppure invia i messaggi RSVP giunti dalla rete al CE
5.3.2 Control Element (CE)
Il Control Element è anch'esso un elemento composto, deputato al controllo logico delle azioni all'interno del nodo, del dialogo con gli altri piani di interfcciamento, degli
aspetti di sicurezza e controllo.
In particolare il suo funzionamento dipende, in particolare nelle richieste di servizio a
circuito, da una Macchina a Stati Finiti come quella in figura:
Illustrazione 22: Macchina a Stati Finiti del CE
(CEScheduler).
N.B: Sarebbe ottimale inserire il comportamento del CE con un modello di implementazione a thread indipendenti in modo da gestire le richieste in maniera concorrente. Il problema è utilizzare i thread nel Click.
In particolare osserviamo due comportamenti in base al paradigma ricevuto:
N.B: Lo stato iniziale sia per OPS che per OCS è LISTEN!!!
•
OPS Message: Lo stato del CE (dell'elemento CEScheduler in particolare...) alla
ricezione di un messaggio OPS ovvero in particolare di un Packet Header (PH)
transita nello stato di OPS Security Check (il PH è passato al CESecurityModu14 dicembre 2010
29
Il Test-Bed
Versione 1
•
le). Se il controllo di sicurezza per OPS (non ancora implementato!!!) va a buon
fine, il CE invia il PH al FE con l'indicazione di processare le informazioni in
esso contenute per schedulare il payload relativo (in attesa nella FDL dello Switching Module) per l'inoltro, altrimenti se fallisce il PH viene scartato. In entrambi i casi il CE torna nello stato di LISTEN in attesa di nuovi pacchetti.
OCS Message: Lo stato del CE (dell'elemento CEScheduler in particolare...)
alla ricezione di un messaggio OCS/RSVP PATH ovvero di una richiesta di instaurazione di circuito (crea un istanza relativa alla richiesta nella tabella CircuitRequests) e transita nello stato di OCS Security Check (il campo state del record relativo alla richiesta in CircuitRequests viene settato opportunamente). Se
il controllo di sicurezza per OCS (vedi dopo) va a buon fine, il CE invia una
OCS_REQ al FE con l'indicazione di valutare se è possibile accettare la richiesta
di circuito, altrimenti se fallisce il pacchetto RSVP PATH viene scartato.
Nel primo caso il CE (ovvero lo stato del CE per la corrente richiesta) transita in
PATH_RECEIVED. Se l'FE risponde positivamente alla richiesta di circuito allora questo invia al CE un OCS_GRANT, il CE invia il PATH al NextHop e
transita nello stato di PATH_SENT. Se l'FE risponde negativamente alla richiesta
di circuito allora questo invia al CE un OCS_DENY, il CE invia un PATHERR
al PreviousHop e transita nello stato iniziale di LISTEN.
•
Una volta nello stato di PATH_SENT ci aspettiamo di ricevere un RSVP RESV
come conferma di instaurazione del circuito o un PATHERR in caso di errore. In
quest'ultimo caso il CE invia un NACK al FE per avvisarlo non tener conto più
della precedente richiesta in quanto fallita (ripristino soglia) e contemporaneamente riflette il PATHERR al PreviousHop.
•
Se invece riceviamo un RSVP RESV allora il CE invia un OCS_COMMIT al FE
per dirgli di settare opportunamente i dispositivi in quanto la richiesta di circuito
è in fase di instaurazione. Il CE passa nello stato di RESV_RECEIVED.
•
Se l'FE ha successo nel riservare i dispositivi allora invia un OCS_SUCCESS ed
il CE invia un RESV al NextHop transitando nello stato di CIRCUIT_ESTABLISHED. Per il CE il circuito dal prossimo timeslot è attivo!!!
•
Se l'FE non ha successo nel riservare i dispositivi allora invia un OCS_FAILURE ed il CE invia un RESVERR al NextHop transitando nello stato di LISTEN.
•
Infine nel caso di un RSVP PATHTEAR il CE chiude il circuito inviando al FE il
messaggio OCS_REL, propagando al NextHop un PATHTEAR e torna nello stato di LSITEN.
Vediamo ora nel dettaglio come è composto il CE internamente e quali sono gli elementi che lo compongono e i loro ruoli:
Illustrazione 23: Schema a blocchi elemento Control
Element (CE).
30
11 novembre 2010
Il Test-Bed
Versione 1
E' composto da:
•
RSVPManager: gestore dei messaggi RSVP, decodifica il protocollo definendo
il tipo messaggio e i parametri fondamentali (indirizzi ip, etc) da utilizzare nel
CE. Questi dati sono scritti nel campo condiviso rsvpmessage. I messaggi che
passano al RSVPManager vengono poi spediti al CESM per il controllo di sicurezza.
•
CE Security Module (CESM): questo è l'elemento o modulo dedicato al controllo e verifica degli aspetti di sicurezza (esposti di seguito nel dettaglio). In
particolare per quanto riguarda il paradigma OCS si effettua un controllo di integrità del messaggio con l'opportuno campo INTEGRITY di RSVP ed un controllo di autenticazione confrontando gli indirizzi di sender e receiver del circuito
con quelli presenti nelle WhiteList.
◦ WhiteList: Tabella degli indirizzi fidati per il servizio a circuito. E' possibile
stabilire un circuito tra A e B se e solo se gli indirizzi IP di A e B sono nella
tabella!!!
•
CE Scheduler: questo è l'elemento chiave del CE, il cervello delle azioni logiche di controllo compiute dall'elemento. Al suo interno si trovano sezioni divere
per ogni paradigma con comportamenti diversi in base alle differenti situazioni
che si possono verificare (ovvero in base al messaggio in ingresso al CEScheduler e allo stato delle sue variabili come ad esempio la tabella CircuitRequests)
◦ CircuitRequests: Tabella delle richieste di circuito, contiene un record per
ogni PATH diverso che arriva e mantiene nota dello stato in cui è la richiesta
(PATH_RECEIVED; SENT; RESV_RECEIVED, etc) caratterizzando così il
comportamento del CE.
•
CE Bus: elemento di interscambio dei messaggi tra i sotto-elementi del CE.
Security Aspects: come accennato il modello prevede anche la computazione di alcune
semplici tecniche per garantire gli aspetti di sicurezza.
Illustrazione 24: Aspetti e meccanismi di sicurezza nel CE.
In particolare, per quanto riguarda il paradigma a circuito, ogni richiesta che giunge via
RSVP dopo essere stata processata dall'elemento OCS Signaling Channel viene passata
al CE. L'elemento RSVPManager effettua il parsing del protocollo, identificando il tipo
di messaggio (PATH, RESV, …) gli indirizzi del sender, receiver, previous e next hop
14 dicembre 2010
31
Il Test-Bed
Versione 1
oltre ad una serie di informazioni aggiuntive (es. lunghezze d'onda disponibili per l'instaurazione del circuito nel nodo precedente).
A questo punto, note le informazioni chiave contenute nella richiesta di servizio per un
circuito, i messaggio è passato al CESM, l'elemento deputato ai controlli di sicurezza. In
particolare vengono controllati due aspetti:
•
Integrità: viene estrapolato il campo “INTEGRITY” dal protocollo RSVP che
contiene il “digest” dell'intero pacchetto processato all'invio secondo una funzione hash del tipo HMAC (es. MD5 o SHA-1). In ricezione il CESM ricalcola il
digest sul pacchetto e lo confronta con quello inviato. Se sono uguali vuol dire
che il messaggio non è stato alterato e quindi viene giudicato genuino, altrimenti
può essere stato vittima di un attacco (es. di tipo Man in The Middle) e viene
quindi scartato (qui è giusto non inserire alcun tipo di notifica al mittente in
quanto fornirebbe informazioni utili a chi vuole attaccare il nodo).
•
Validazione: il pacchetto, se genuino, viene inoltre processato per verificare se,
gli indirizzi di sender e receiver del circuito sono presenti nella tabella degli indirizzi autorizzati ad usufruire del servizio a circuito (WhiteList). In caso affermativo la richiesta lascia il CESM in quanto autorizzata a procedere, altrimenti il
pacchetto viene scartato (qui forse è giusto inserire qualche tipo di notifica al
mittente in modo da comunicare che non si è abilitati a mandare/ricevere per
questo tipo di servizio)
A questo punto la richiesta lascia il CESM e raggiunge il CE dove viene creato un record nella tabella CircuitRequests con tutte le informazioni necessarie al fine di mantenere lo stato della richiesta.
Per quanto riguarda il paradigma a pacchetto OPS attualmente l'implementazione fornisce il pacchetto in arrivo dalle fibre in ingresso al CESM ma questo non effettua alcun
tipo di controllo di sicurezza sul traffico. Questo perché, nella nostra implementazione,
manca un vero riferimento alla struttura dell'header ottico, in particolare riferimento ad
uno standard che lo delinei ed identifichi i campi necessari come ad esempio il campo
INTEGRITY del protocollo RSVP.
N.B: Si veda lo standard OPS KEOPS come linea guida per la definizione del nostro
header ottico!!!
5.3.3 From/To Kernel
Elementi che inviano/ricevono informazioni (pacchetti) verso/dalla configurazione che
gira in kernelmodule:
•
32
FromKernel: elemento che riceve le informazioni (pacchetti) dalla configurazione che gira in kernelmodule.
11 novembre 2010
Il Test-Bed
Versione 1
Illustrazione 25: Schema a blocchi
elemento FromKernel.
•
•
•
•
•
•
•
14 dicembre 2010
E' composto da:
Classifier: elemento che classifica i pacchetti in arrivo dall'interfaccia di rete in
ascolto (tap0).
◦ Pacchetti ARP: vengono inviati ad un opportuno elemento ARPResponder
che provvede a rispondere alle interrogazioni ARP.
◦ Pacchetti IP: vengono inviati all'elemento successivo;
-Eth: elimina l'intestazione ethernet (14 bytes)
-IP: elimina l'intestazione IP (20 bytes)
-UDP: elimina l'intestazione UDP (8 bytes)
Data2Click: preleva dal campo dati le annotazioni e le inserisce nel campo annotazioni.
CircuitTable: estrapola le informazioni di aggiornamento della tabella dei circuiti.
------ToKernel: elemento che invia le informazioni (pacchetti) alla configurazione
che gira in kernelmodule.
33
Il Test-Bed
Versione 1
Illustrazione 26: Schema a blocchi elemento ToKernel.
•
•
•
•
•
E' composto da:
CircuitTable: inserisce le informazioni di aggiornamento della tabella dei circuiti.
Click2Data: preleva dal campo annotazioni le annotazioni e le inserisce nel
campo dati.
+UDP: aggiunge l'intestazione UDP (8 bytes)
+IP: aggiunge l'intestazione IP (20 bytes)
+Eth: aggiunge l'intestazione ethernet (14 bytes)
5.4 Forwarding Plane
Il piano di inoltro contiene al suo interno i dispositivi che compongono il percorso attraversato dai dati, che vengono configurati dagli elementi logici e fisici del FE anch'essi nel piano di
inoltro.
5.4.1 From/To User
Elementi che inviano/ricevono informazioni (pacchetti) verso/dalla configurazione che
gira in userlevel:
•
FromUser: elemento che riceve le informazioni (pacchetti) dalla configurazione
che gira in userlevel.
34
11 novembre 2010
Il Test-Bed
Versione 1
Illustrazione 27: Schema a blocchi elemento FromUser.
•
14 dicembre 2010
E' composto da:
◦ Classifier: elemento che classifica i pacchetti in arrivo dall'interfaccia di rete
in ascolto (tap0).
▪ Pacchetti ARP: vengono inviati ad un opportuno elemento ARPResponder che provvede a rispondere alle interrogazioni ARP.
▪ Pacchetti IP: vengono inviati all'elemento successivo;
◦ -Eth: elimina l'intestazione ethernet (14 bytes)
◦ -IP: elimina l'intestazione IP (20 bytes)
◦ -UDP: elimina l'intestazione UDP (8 bytes)
◦ Data2Click: preleva dal campo dati le annotazioni e le inserisce nel campo
annotazioni.
◦ CircuitTable: estrapola le informazioni di aggiornamento della tabella dei
circuiti.
------ToUser: elemento che invia le informazioni (pacchetti) alla configurazione che
gira in kernelmodule.
35
Il Test-Bed
Versione 1
Illustrazione 28: Schema a blocchi elemento
ToUser.
E' composto da:
◦ CircuitTable: inserisce le informazioni di aggiornamento della tabella dei
circuiti.
◦ Click2Data: preleva dal campo annotazioni le annotazioni e le inserisce nel
campo dati.
◦ +UDP: aggiunge l'intestazione UDP (8 bytes)
◦ +IP: aggiunge l'intestazione IP (20 bytes)
◦ +Eth: aggiunge l'intestazione ethernet (14 bytes)
5.4.2 Forwarding Element (FE)
Come detto il FE si compone di due sotto-moduli, il LFE e i PFEs.
•
Logical Forwarding Element: precedentemente indicato (come visibile in figura) semplicemente come FE si compone di vari sotto-elementi:
36
11 novembre 2010
Il Test-Bed
Versione 1
◦
◦
14 dicembre 2010
LabelLookup: elemento che controlla (solo traffico a pacchetto) la label
GMPLS dell'header OPS per determinarne (attraverso l'interrogazione della
tabella ForwardingTable) l'interfaccia di uscita. Una volta calcolata questa
informazione viene introdotta nell'annotazioni del pacchetto click per essere
utilizzata nell'algoritmo di scheduling.
▪ N.B: Qui la ForwardingTable è realizzata in maniera molto semplice, ovvero si valuta il 3° byte dell'indirizzo IP destinazione che viene diviso
modulo n° di fibre di uscita del nodo. Nel caso di due fibre di uscita, se il
resto è 0 (3° byte pari) allora OF per il pacchetto è OF0, mentre se il resto è 1 (3° byte dispari) allora OF per il pacchetto è OF1.
FEScheduler: è l'elemento che coordina le operazioni all'interno del LFE oltre che determinare l'inoltro vero e proprio del traffico grazie all'algoritmo di
scheduling (la versione del corrente algoritmo è possibile trovarla definito e
commentato in dettaglio nei paper HPSR 2010 e Globecom 2010). In particolare qui vengono lette le informazioni contenute nelle annotazioni del pacchetto click contenente l'header OPS (IF, OF (da LabelLookup), IW) e ne
viene calcolata la destinazione di uscita:
▪ Se non si è raggiunto il n° massimo di pacchetti schedulati per quella fibra nel corrente timeslot
▪ In caso di contesa sulla stessa lunghezza d'onda si cerca di determinare
un possibile schema di conversione che ottimizzi il traffico
37
Il Test-Bed
Versione 1
▪
•
38
In caso negativo il pacchetto viene droppato (informazione inserita nelle
annotazioni e l'elemento drop uccide successivamente il pacchetto).
Inoltre lo scehduler indirizza opportunamente il pacchetto correttamente
schedulato logicamente verso il suo relativo PFE Packet (ex FMOPS).
La tabella CircuitRequests2 è una copia in replica della tabella CircuitRequests presente nel CE. Questo perché se una struttura dati è dichiarata extern in c può essere condivisa tra tutti gli elementi della configurazione click
corrente (elementi di uno stesso processo click, condividono la risorsa extern) questo non può essere fatto da elementi appartenenti a configurazioni
diverse. E così l'LFE che necessita di alcune informazioni presenti in CircuitRequests per compiere le sue mansioni deve costituire la sua replica e tenerla aggiornata con quella del CE dato che FE e CE si trovano in due file di
configurazioni diversi, ovvero in due processi diversi tra cui peraltro uno (la
configurazione che contiene l'FE) esegue come modulo kernel (ed è quindi
impensabile l'uso di una struttura condivisa tra processi userlevel, dato che lo
spazio di indirizzamento in memoria tra processi user e kernel è
differente!!!)
Per quanto riguarda il traffico OCS invece l'LFE intercambia i messaggi secondo lo standard ForCES con il CE e i vari PFEs (ex FMs).
◦ GranularitySwitch: questo elemento in base alla relativa annotazione invia
i pacchetti al PFE (ex FM) di destinazione.
◦ *LabelSwap: questo elemento era presente nelle prime implementazioni in
cui si prevedeva di poter alterare le informazioni presenti nell'header ottico
(in questo piano convertito in elettronico) per poter poi essere reinserite nel
traffico. E' stato successivamente eliminato in quanto con il protocollo GMPLS questo non è strettamente necessario.
Phisical Forwarding Elements: precedentemente indicati (come visibile in figura) semplicemente come FMs si compongono di un singolo sotto-elemento:
11 novembre 2010
Il Test-Bed
Versione 1
Illustrazione 29: PFEs, ex FMs.
•
FMScheduler: è l'elemento che riceve le richieste dal LFE e interagisce con
l'hardware. In particolare è a corrente dello stato dei dispositivi della matrice
(numero, tipo, stato [occupato o meno e con quale priorità]) e può interagire con
essi attraverso l'uso degli handler click (invocazione mediante la funzione handlercall_read/write)
5.4.3 Control Bus
Questo elemento è stato introdotto per ragioni di ottimizzazione delle connessioni e di
pulizia della configurazione click.
Tutte le uscite degli elementi e gli ingressi delle configurazioni sono collegate al solo ingresso del Bus mentre tutti gli ingressi degli elementi e le uscite delle configurazioni
sono connesse ai suoi output. Questo permette al Bus di far viaggiare le informazioni
dentro e fuori la configurazione e da verso qualsiasi dispositivo che ne faccia parte.
La logica è realizzata associando ad ogni elemento e configurazione un numero (presente in OpticalRouterAnnotation.hh) e caratterizzando opportunamente le annotazioni dei
dati che attraversano la configurazione nei campi FROM (elemento/configurazione mittente) e TO (elemento/configurazione destinatario).
5.5 Switching Module
Il modulo di commutazione contiene al suo interno tutti i dispositivi, propri di una certa tecnologia, attui allo switch dei dati dalle interfacce di ingresso alle interfacce di uscita.
14 dicembre 2010
39
Il Test-Bed
Versione 1
Se pur in linea di principio questo elemento possa emulare il comportamento di differenti tecnologie (elettronica, ottica...) il nostro studio si è caratterizzato sull'uso di tecnologia ottica.
5.5.1 Architettura Broadcast & Select
Tra le tante architetture proposte in letteratura per quanto riguarda le matrici di commutazione ottiche si è scelto di adottare una matrice di semplice architettura come quella
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).
5.5.2 EDFAs
Questi dispositivi sono posti all'ingresso della matrice (interfacce di input) e nello stadio
intermedio post conversione per garantire che il segnale ottico mantenga valori di potenza e OSNR accettabile per la soglia di rilevazione dei dispositivi ottici della matrice
stessa.
•
Funzionalità Logica: i pacchetti dati li attraversano senza alcun effetto nel percorso.
•
Caratterizzazione in Potenza: essendo componenti attivi questi dispositivi affliggono sia il livello di potenza del segnale sia il rapporto OSNR.
5.5.3 WDM Multiplexer & Demultiplexer
Questi dispositivi ripartiscono o multiplano da/verso un'unica fibra ottica le sue componenti di lunghezza d'onda secondo lo schema WDM.
•
Demultiplexer:
40
11 novembre 2010
Il Test-Bed
Versione 1
◦
•
Funzionalità Logica: i pacchetti che entrano nell'unico ingresso del dispositivo vengono portati verso l'uscita dedicata alla lunghezza d'onda cui appartengono memorizzata nel campo wavelength delle proprie annotazioni.
◦ Caratterizzazione in Potenza:
Multiplexer:
◦ Funzionalità Logica: i pacchetti che entrano nei diversi ingressi (uno per
lunghezza d'onda) del dispositivo vengono portati verso l'unica uscita.
◦ Caratterizzazione in Potenza:
5.5.4 Fiber Delay Lines
Le fibre di ritardo rappresentano l'unico espediente assimilabile alle memorie in ambiente ottico. Queste incanalando il segnale in un loop di lunghezza variabile ritardano il suo
arrivo ai dispositivi di conversione e switch permettendo il contemporaneo processamento delle informazioni di instradamento.
•
Funzionalità Logica: i pacchetti vengono ritardati di un dt necessario al processamento delle informazioni di instradamento e alla attivazione dei dispositivi di
switching.
•
Caratterizzazione in Potenza: l'attraversamento del loop introduce attenzuazione nella potenza del segnale.
5.5.5 Wavelength Converters (WC)
Questi dispositivi permettono di convertire la lunghezza d'onda fissa del segnale che ricevono (Fixed Input) verso una qualsiasi altra lunghezza d'onda (Tunable Output):
•
Funzionalità Logica: se necessario (ovvero se impartito dall'algoritmo di scheduling per risolvere eventuali contese) si varia la lunghezza d'onda del pacchetto
andando a variare il campo annotazione relativo.
◦ N.B: Essendo comandati dallo scheduling questi dispositivi dovranno prevedere un meccanismo di interfaccia (click handlers) per modificare il loro stato durante il funzionamento della matrice in base al risultAto dello scheduling (conversione o meno del segnale per il corrente timeslot)
•
Caratterizzazione in Potenza: essendo componenti attivi questi dispositivi affliggono sia il livello di potenza del segnale sia il rapporto OSNR in modi diversi in base al fatto che avvenga conversione o meno.
5.5.6 Splitters & Couplers
Questi componenti si occupano di ripartire o accoppiare il segnale ottico su più o sulla
stessa fibra:
•
Splitter:
◦ Funzionalità Logica: la fibra ottica posta in ingresso viene ripartita su più
fibre ottiche in uscita (quindi tutti i pacchetti/segnali in ingresso sono duplicati su tutte le uscite).
◦ Caratterizzazione in Potenza: ripartendo una fibra su più uscite ne deriva
una attenuazione della potenza.
•
Coupler:
14 dicembre 2010
41
Il Test-Bed
Versione 1
◦
◦
Funzionalità Logica: le fibra ottica poste in ingresso vengono riunite su una
singola fibra in uscita (quindi qui i pacchetti non devono presentare collisioni!!!).
Caratterizzazione in Potenza: ricongiungendo il segnale di più fibre su una
ne deriva una attenuazione della potenza.
5.5.7 Semiconductor Optical Amplifier (SOA)
Questi dispositivi si caratterizzano logicamente come dei semplici interruttori on/off, e
quindi è semplice la loro implementazione derivata dall'elemento Switch del Click!
•
Funzionalità Logica: in base al loro stato (aperto/chiuso) si caratterizzano logicamente come dei semplici interruttori on/off permettendo al pacchetto/segnale
di attraversarli o meno.
◦ N.B: Essendo comandati dallo scheduling questi dispositivi dovranno prevedere un meccanismo di interfaccia (click handlers) per modificare il loro stato durante il funzionamento della matrice in base al risultAto dello scheduling (conversione o meno del segnale per il corrente timeslot)
•
Caratterizzazione in Potenza: essendo componenti attivi questi dispositivi
affliggono sia il livello di potenza del segnale sia il rapporto OSNR.
5.6 Livelli di Esecuzione
•
•
In base ad alcune necessità intrinseche nelle funzionalità dell'emulatore è stato deciso di suddividere l'esecuzione dello strumento su due piani distinti:
Livello Userlevel: qui risiedono i componenti che non hanno bisogno di prestazioni estreme
di calcolo e/o richiedono l'appoggio a librerie utilizzabile solo in userspace.
Livello Kernelmodule: qui risiedono i componenti che hanno bisogno di accedere alle
massime prestazioni di calcolo e/o non richiedono l'appoggio a librerie esterne in userspace.
5.6.1 Livello Userlevel
•
•
42
Come accennato qui risiedono i componenti che non hanno bisogno di prestazioni estreme di calcolo e/o (soprattutto) richiedono l'appoggio a librerie utilizzabile solo in userspace.
Ne fanno parte:
OCS Signaling Channel: ovvero il canale di segnalazione fuori banda per il paradigma di
traffico a circuito;
Control Element (CE): al suo interno troviamo diverse componenti tra cui
◦ CE Security Module (CESM): questo componente elabora tutti i meccanismi di sicurezza che coinvolgono il nodo (es. Il meccanismo di integrità dei messaggi RSVP) e si
avvale degli algoritmi di sicurezza della libreria OpenSSL fruibile solo a livello userspace.
▪ Secure Sockets Layer (SSL): è un protocollo crittografico che permettono una comunicazione sicura e una integrità dei dati su reti TCP/IP come, ad esempio, internet.
Cifra la comunicazione dalla sorgente alla destinazione (end-to-end) sul livello di
trasporto.
11 novembre 2010
Il Test-Bed
◦
Versione 1
CE Scheduler: il cuore logico del CE oltre a coordinare deve gestire le varie richieste in
arrivo al nodo (es. Richieste di circuito dal canale di segnalazione OCS). Per fare ciò ed
essere concorrente utilizza dei thread per gestire concorrentemente le varie richieste*.
▪ N.B: Questa funzionalità non è implementata ed è opzionalmente prevista per estensioni future.
5.6.2 Livello Kernelmodule
Come accennato qui risiedono i componenti che abbisognano di prestazioni elevate di
calcolo e/o (soprattutto) non richiedono (o possono fare a meno) di librerie utilizzabili
solo in ambiente userspace.
14 dicembre 2010
43
Il Test-Bed
Versione 1
Difficoltà maggiore la si ha nella emulazione dei calcoli legati alla caratterizzazione in
potenza dei dispositivi in quanto in kernelmodule non è possibile utilizzare né le librerie
matematiche (si pensi alle funzioni logaritmiche nel calcolo delle attenuazioni di potenza), né il calcolo in virgola mobile.
5.7 Programmi e Script di Emulazione
L'emulatore allo stato attuale prevede la configurazione vista in precedenza e si avvale fondamentalmente di tre diverse procedure per eseguire una simulazione. In particolare si deve:
1. Avviare il ricevitore del traffico che raccoglie il traffico correttamente schedulato dal
router.
2. Avviare il router in ascolto sulle interfacce di rete.
3. Avviare la generazione del traffico voluto per testare le prestazioni della configurazione corrente.
5.7.1 Ricezione del Traffico (deisnet67)
I programmi e gli script per la ricezione del traffico risiedono in “/home/user67/Confi gurazioni/” ed in particolare abbiamo:
•
receiver<ANNO><MESE><GIORNO>.c: è il codice sorgente del ricevitore di
traffico, parametrizzato per porsi in ascolto su un numero variabile di sorgenti di
traffico OPS sincrone e per rispondere alla sequenza asincrona di richieste di circuito (OCS) che pervengono correttamente inviando opportuni messaggi di
RESV;
•
receiver.sh: è lo script che lancia il codice del ricevitore di traffico con i parametri impostati;
44
11 novembre 2010
Il Test-Bed
Versione 1
•
•
•
interface_config_rx.sh: è lo script che imposta correttamente gli indirizzi delle
sottoreti necessarie a simulare la rete ottica;
◦ N.B: da eseguire ad ogni riavvio della macchina in esame!!!
kill_rx.sh: è uno script che si assicura di uccidere tutti i processi mandati in esecuzione dal ricevitore per interrompere correttamente una simulazione;
workspace_rx.sh: è uno script che apre l'editor di testo e tutti i file editabili della cartella corrente per dare allo sviluppatore il controllo del workspace;
5.7.2 Emulatore Router (deisnet 69)
Su questa macchina abbiamo due sezioni distinte:
•
/home/user69/Configurazioni
•
/home/user69/click-git/
Nella cartella “/home/user69/click-git/” vi è l'installazione locale del click compilato in
modo da avere sia i driver per userlevel che per linuxmodule (e quindi sulla macchina è
in esecuzione un kernel particolare, non quello della distribuzione FC12, ovvero un kernel vanilla [2.6.24.7] a cui è applicata la patch click opportuna).
In particolare poi nella cartella “/home/user69/click-git/elements/local/” risiedono i files
sorgenti degli elementi caratteristici del router (es. SOA, CEScheduler, … ) che sono
necessari per utilizzare le funzionalità del router.
Nella cartella “/home/user69/Configurazioni/” risiedono i programmi e gli script per l'esecuzione dell'emulatore ed in particolare abbiamo:
•
optical_router<VERSION>_user_<M>x<N>_w<W>.click: è il file di configurazione click a livello userlevel (contiene CE e altri elementi che necessitano
di librerie a livello utente) lanciato come processo semplice (a massima priorità)
con il comando click dallo script router_script.sh;
•
optical_router<VERSION>_kernel_<M>x<N>_w<W>.click: è il file di configurazione click a livello kernelmodule (contiene la matrice di commutazionee
altri elementi che necessitano della velocità massima di processamento) installato come modulo kernel con il comando click-install dallo script router_script.sh;
•
router_script.sh: è lo script che lancia il codice del ricevitore di traffico con i
parametri impostati;
•
output_user<M>x<N>_w<W>_ocs_q<LOADFACTOR>.txt: l'output dell'emulazione per scopi di debug (può essere molto grande!!!)
•
output_kernel<M>x<N>_w<W>_ocs_q<LOADFACTOR>.txt: l'output dell'emulazione per scopi di debug (può essere molto grande!!!)
•
readcounter.sh: è uno script che campiona ogni 20 secondi lo stato di alcuni
contatori della configurazione in esecuzione (pacchetti OPS, pacchetti OCS, … )
per statistiche sul throughput.
•
readtime.sh: è uno script che campiona ogni 20 secondi lo stato di alcuni contatori della configurazione in esecuzione per statistiche sui tempi e performance
della configurazione.
•
makeinstall.sh: è uno script che compila gli elementi in “../clickgit/elements/local/” senza dover uscire dalla cartella corrente.
•
makeelemlist.sh: è uno script che aggiorna la lista degli elementi da compilare
senza dover uscire dalla cartella corrente (solo se aggiungo nuovi elementi!!!).
14 dicembre 2010
45
Il Test-Bed
Versione 1
•
•
•
•
interface_config_router.sh: è lo script che imposta correttamente gli indirizzi
delle sottoreti necessarie a simulare la rete ottica;
◦ N.B: da eseguire ad ogni riavvio della macchina in esame!!!
throughput.txt/.ods/.dat/.plt: file per il plotting del throughput. Il file .txt viene
scritto dallo script readcounters e dato in pasto al file .ods. Il risultato della elaborazione del foglio di calcolo è inserito nel file .dat che è il file plottato da gnuplot caricando il file .plt.
kill_click.sh: è uno script che si assicura di uccidere tutti i processi mandati in
esecuzione dallo script router (configurazioni e readers...) per interrompere correttamente una simulazione;
workspace_router.sh: è uno script che apre l'editor di testo e tutti i file editabili
della cartella corrente e degli elementi in “../git-click/local/” per dare allo sviluppatore il controllo del workspace;
5.7.3 Generazione del Traffico (deisnet68)
I programmi e gli script di generazione del traffico risiedono in “/home/user68/Configurazioni/” ed in particolare abbiamo:
•
generator<ANNO><MESE><GIORNO>.c: è il codice sorgente del generatore
di traffico, parametrizzato per generare un numero variabile di sorgenti di traffico OPS sincrone a carico variabile verso un certo indirizzo e una sequenza asincrona di richieste di circuito (OCS) ad intervalli IAT;
•
generator.sh: è lo script che lancia il codice del generatore di traffico con i parametri impostati;
•
interface_config_tx.sh: è lo script che imposta correttamente gli indirizzi delle
sottoreti necessarie a simulare la rete ottica;
◦ N.B: da eseguire ad ogni riavvio della macchina in esame!!!
•
kill_tx.sh: è uno script che si assicura di uccidere tutti i processi mandati in esecuzione dal generatore per interrompere correttamente una simulazione;
•
workspace_tx.sh: è uno script che apre l'editor di testo e tutti i file editabili della
cartella corrente per dare allo sviluppatore il controllo del workspace;
5.8 Caratterizzazione di Potenza
N.B: Questa sezione è stata sviluppata con il fondamentale contributo di Ivan Aldaya.
Questa caratteristiche dell'emulatore è definita elemento per elemento all'interno della matrice
di commutazione.
Come abbiamo visto in kernelmodule non è possibile utilizzare né le librerie matematiche (si
pensi alle funzioni logaritmiche nel calcolo delle attenuazioni di potenza), né il calcolo in virgola mobile. Per ovviare a questi problemi si sono introdotte due soluzioni:
5.8.1 Tabelle di funzioni complesse
In kernelmode è proibito l'uso di librerie di sistema a livello utente come ad esempio la
libreria matematica. Va da sé che i calcoli necessari alla caratterizzazione di potenza, i
quali utilizzano spesso funzioni di tipo logaritmico e/o esponenziale, non possono essere eseguiti con facilità.
46
11 novembre 2010
Il Test-Bed
Versione 1
Per ovviare a questa mancanza, tenendo conto del limitato range dei valori in ingresso
utilizzati come parametri per queste funzioni oltre che il numero contenuto di queste, si
è pensato di implementare delle tabelle in grado di restituire il valore di una determinata
funzione (logaritmo, divisione, esponente) per un determinato valore (parametro della
funzione) utilizzato come indice della tabella stessa.
Esistono dunque funzioni della libreria kernel Power.hh (in CLICKDIR/elements/local)
che restituiscono il valore di queste funzioni interrogando tabelle in cui spesso il primo
indice è la parte intera del valore e il secondo è la parte decimale spesso arrotondata per
eccesso o difetto.
N.B: Questa soluzione non è ottimale, soprattutto per i valori dei calcoli che ne risultano ovviamente inficiati. E' opportuno far presente che i calcoli che le utilizzano (es.
la caratterizzazione in potenza e OSNR) possono essere affetti da un errore più o
meno marcato che può deriva da questo stratagemma.
5.8.2 Numeri in Virgola Fissa
Oltre all'impossibilità di fare uso di librerie esterne in un modulo kernel (come tale è la
configurazione del forwarding plane) è vietato anche l'uso dei valori in virgola mobile.
Si è dunque preso spunto da librerie disponibili su internet all'utilizzo di valori in virgola fissa, con le dovute limitazioni che questi impongono. Infatti un numero in virgola fissa può avere una determinata precisione nei confronti della parte intera o di quella decimale, ma non di entrambe. Occorre dunque tenerne conto nei calcoli.
Esistono dunque una serie di classi di tipo dato fixed point nella libreria Fixed.hh che
abilitano queste funzionalità.
5.9 Il Traffico OPS e OCS
Analizziamo ora come si presenta al nodo il traffico OPS e OCS:
5.9.1 Traffico OPS
Il traffico OPS originato dal generatore è composto da pacchetti UDP/IP incapsulati su
Ethernet che trasportano un payload ottico variabile tra 64 e 1500 bytes (parametro da
riga di comando del generatore)
•
Ethernet: qui si trovano gli indirizzi MAC della scheda associata all'IP sorgente
(ovvero la scheda di rete del generatore) e della scheda associata al next hop per
raggiungere l'IP destinazione (ovvero la scheda di rete associata al traffico in ingresso del router). Questi indirizzi sono forniti mediante protocollo ARP opportunamente istruito dai script di configurazione delle interfacce di rete presenti
nelle cartelle “/home/userXX/Configurazioni”.
•
IP: qui si trovano gli indirizzi IP sorgente del pacchetto ottico e destinazione.
•
UDP: qui si trovano le informazioni UDP che distinguono i pacchetti per porta
sorgente. La porta sorgente individua anche il canale (lunghezza d'onda e fibra)
su cui il pacchetto giunge al nodo. Le porte nella corrente confiugrazione 2x2
w=4 sono:
◦ Fibra 0:
▪ 10000 lunghezza d'onda 0;
▪ 10001 lunghezza d'onda 1;
14 dicembre 2010
47
Il Test-Bed
Versione 1
▪
•
10002 lunghezza d'onda 2;
▪ 10003 lunghezza d'onda 3;
◦ Fibra 1:
▪ 10004 lunghezza d'onda 0;
▪ 10005 lunghezza d'onda 1;
▪ 10006 lunghezza d'onda 2;
▪ 10007 lunghezza d'onda 3;
Optical Packet: questo è il “protocollo ottico” su cui viaggiano le vere informazioni elaborate nel nodo. In particolare avremo:
◦ Header (? bytes): a default i byte dell'header (parametro) sono posti al valore
'H' 72.
▪ byte 0 = label
▪ byte 1 = timeslot corrente
▪ byte 2-5 = emulated arrival power level
▪
◦
byte 6-9 = emulated arrival OSNR level
▪ byte 10 = byte di fine emulazione, settato ad 1 quando è l'ultimo pacchetto dell'emulazione per avvertire il ricevitore.
Payload (? Bytes): a default i byte del payload (parametro) sono posti al valore 'P' 80.
5.9.2 Traffico OCS
Il traffico di segnalazione OCS originato dal generatore è composto da pacchetti
RSVP/IP incapsulati su Ethernet che trasportano messaggi RSVP per l'instaurazione del
circuito:
•
Ethernet: qui si trovano gli indirizzi MAC della scheda associata all'IP sorgente
(ovvero la scheda di rete del generatore) e della scheda associata al ricevitore
l'IP destinazione (ricorda che i messaggi tipo PATH sono tra sender e receiver e i
messaggi tipo RESV sono hop-by-hop). Questi indirizzi sono forniti mediante
protocollo ARP opportunamente istruito dai script di configurazione delle interfacce di rete presenti nelle cartelle “/home/userXX/Configurazioni”.
•
IP: qui si trovano gli indirizzi IP sorgente del pacchetto ottico e destinazione
(sender e receiver nel PATH e sender e nexthop nei messaggi tipo RESV).
•
RSVP: qui si trovano le informazioni proprie del protocollo RSVP tra cui tipo
messaggio, IP Sender e Recever e rispettivi tunnel ID, …
Inoltre le richieste arrivano con un tempo di interarrivo di tipo IAT e una durata parametrizzabile da linea di comando all'esecuzione del generatore.
Il traffico OCS puro originato dal generatore e inviato sul canale dedicato al circuito, e
qui l'header ricopre solo un importanza marginale in quanto porta con se solo le informazioni di sincronizzazione:
•
Ethernet: qui si trovano gli indirizzi MAC della scheda associata all'IP sorgente
(ovvero la scheda di rete del generatore) e della scheda associata al next hop per
raggiungere l'IP destinazione (ovvero la scheda di rete associata al traffico in ingresso del router). Questi indirizzi sono forniti mediante protocollo ARP oppor-
48
11 novembre 2010
Il Test-Bed
Versione 1
•
•
•
tunamente istruito dai script di configurazione delle interfacce di rete presenti
nelle cartelle “/home/userXX/Configurazioni”.
IP: qui si trovano gli indirizzi IP sorgente del traffico a circuito ottico e destinazione.
UDP: qui si trovano le informazioni UDP che distinguono i pacchetti facenti
parte del traffico a circuito per porta sorgente. La porta sorgente individua anche
il canale (lunghezza d'onda e fibra) su cui il pacchetto giunge al nodo. Le porte
nella corrente confiugrazione 2x2 w=4 sono (come sopra);
Optical Packet: questo è il “protocollo ottico” su cui viaggiano le vere informazioni elaborate nel nodo. In particolare avremo:
◦ Header (? bytes): a default i byte dell'header (parametro) sono posti al valore
'H' 72.
▪ byte 0 = label
▪ byte 1 = timeslot corrente
▪ byte 2-5 = emulated arrival power level
▪ byte 6-9 = emulated arrival OSNR level
▪
◦
byte 10 = byte di fine emulazione, settato ad 1 quando è l'ultimo pacchetto dell'emulazione per avvertire il ricevitore.
Payload (? Bytes): a default i byte del payload (parametro) sono posti al valore 'P' 80.
6 Elenco degli Elementi
Ecco ora un elenco punto per punto degli elementi presenti e facenti parte del framework di lavoro.
N.B: Ogni elemento è composto dai rispettivi files .cc e .hh inoltre può includere delle librerie
come OpticalRouterAnnotation.hh o altri files presenti nelle librerie del SO o nella stessa cartella “CLICKDIR/elements/local”
6.1 Attenuator
Elemento che modella l'attenuazione del segnale ottico.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Valore attenuazione: in db;
•
Emulazione di Potenza: attiva o meno;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
14 dicembre 2010
49
Elenco degli Elementi
Versione 1
Nel metodo simple-action invece, all'arrivo del pacchetto se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità e modifica
di conseguenza i valori nelle annotazioni e si inizializzano le variabili da usare.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.2 Bus
Elemento che collega e smista i messaggi tra diversi elementi a lui connessi attraverso la lettura delle annotazioni TO e FROM.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Ports: numero di porte in uscita;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla l'annotazione FROM e
TO quindi si stampa(se verbose true) da dove proviene il pacchetto e dove va, poi lo si smista
verso la porta dell'elemento corrispondente al valore memorizzato nella annotazione TO del
pacchetto.
Gli elementi che vogliono usare il bus devono implementare un metodo di tipo send_message
per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.3 CEScheduler
Elemento che modella il centro logico del CE.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INPUT_FIBERS: numero fibre in ingresso del nodo;
•
OUTPUT_FIBERS: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
non usati
50
11 novembre 2010
Elenco degli Elementi
Versione 1
6.4 CESecurityModule (CESM)
Elemento che modella il controllo di sicurezza ed integrità nel CE.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INPUT_FIBERS: numero fibre in ingresso del nodo;
•
OUTPUT_FIBERS: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza (controllo sicurezza ed integrità).
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.5 CircuitsTable
Elemento che inserisce le informazioni delle CircuitsTable per lo scambio e la sincronizzazione delle stesse tra CE e FE (che sono su due configurazioni diverse, per di più a livelli differenti e non condividono la stessa struttura CircuitsTable).
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
LEVEL: indica se l'elemento agisce a livello userlevel o kernelmodule;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla a quale livello si agisce
e in che direzione CE
FE o FE
CE. In base a ciò si incapsulano o si aggiornano le informazioni delle CircuitsTable.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.6 Click2Data
Elemento che inserisce le informazioni delle annotazioni click del pacchetto nel campo dati
dello stesso per lo scambio e la sincronizzazione delle stesse tra CE e FE (che sono su due
configurazioni diverse e non manterrebbero le stesse annotazioni).
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
14 dicembre 2010
51
Elenco degli Elementi
Versione 1
Nel metodo simple-action invece, all'arrivo del pacchetto si inseriscono le annotazioni nel
campo data in modo da inviarle attraverso l'interfaccia di rete condivisa tra le due configurazioni.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.7 Combiner
Elemento che modella un combiner ottico.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
PORTS: numero di porte in ingresso del Combiner;
•
Emulazione di Potenza: attiva o meno;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, tutti i pacchetti in ingresso al nodo vengono convogliati da
tutti gli ingressi alla stessa uscita e se è attiva la funzione di emulazione della potenza viene
richiamato il metodo di powerMethod che ne calcola l'entità e modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.8 Connector
Elemento che modella un connettore fisico tra due elementi ottici.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Value: valore di attenuazione;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action viene richiamato il metodo di powerMethod che ne calcola l'entità
e modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.9 CrossTalk
Elemento che modella l'effetto di cross-talk tra elementi ottici.
52
11 novembre 2010
Elenco degli Elementi
Versione 1
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
PORT: numero di porte da considerare per il valore di cross-talk;
•
Emulazione di Potenza: attiva o meno;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo per il calcolo del valore del cross-talk per dispositivi con un certo numero di porte, ne calcola l'entità e modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
id
•
port
6.10 Data2Click
Elemento che recupera le informazioni delle annotazioni click del pacchetto dal campo dati
per lo scambio e la sincronizzazione delle stesse tra CE e FE (che sono su due configurazioni
diverse e non manterrebbero le stesse annotazioni).
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si estraggono le annotazioni dal
campo data e si rimettono in quello annotation.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.11 EDFA
Elemento che modella un amplificatore ottico tipo EDFA.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Wavelengths: numero di lunghezze d'onda;
•
Emulazione di Potenza: attiva o meno;
•
Control Type: tipo di controllo potenza o guadagno;
•
Model Type: modello EDFA, secondo datasheet modello 1 o 2 vedi report Ivan;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
14 dicembre 2010
53
Elenco degli Elementi
Versione 1
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
id
6.12 FEScheduler
Elemento che modella il centro logico del FE.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INPUT_FIBERS: numero fibre in ingresso del nodo;
•
OUTPUT_FIBERS: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Soglia Circuiti: soglia logica massima di circuiti contemporanei nel nodo;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
value
•
fe_dropped packets pacchetti scartati dal FE
6.13 FMOCSScheduler
Elemento che modella il centro logico del PFEs (ex FM) paradigma OCS.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
OCS_IF: numero fibre in ingresso del nodo;
•
OCS_OF: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Priority: la priorità del modulo rispetto agli altri;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
54
11 novembre 2010
Elenco degli Elementi
•
•
•
•
Versione 1
schedule
inputfiber
outputfiber
wavelength
6.14 FMOPSScheduler
Elemento che modella il centro logico del PFEs (ex FM) paradigma OPS.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INPUT_FIBERS: numero fibre in ingresso del nodo;
•
OUTPUT_FIBERS: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Priority: la priorità del modulo rispetto agli altri;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
•
Switching Matrix: stringa dell'elemento SM nel file configurazione per richiamare gli
handler click (obsoleta)
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
TWCName1: il primo indice del twc da abilitare;
•
TWCName2: il primo indice del twc da abilitare;
•
TWCValue: il primo indice del twc da abilitare;
•
SOAName1: il primo indice del soa da abilitare;
•
SOAName2: il primo indice del soa da abilitare;
•
SOAName3: il primo indice del soa da abilitare;
•
fmdroppedpackets
6.15 LabelLookup
Elemento che modella l'azione di LabelLookup.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INPUT_FIBERS: numero fibre in ingresso del nodo;
•
OUTPUT_FIBERS: numero fibre in uscita del nodo;
•
WAVELENGTHS: numero lunghezze d'onda per canale;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
14 dicembre 2010
55
Elenco degli Elementi
Versione 1
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla il paradigma di appartenenza (OCS, OBS, OPS) e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi in base al tipo di appartenenza (LabelLookup solo per OPS).
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.16 LabelSwap
Elemento che modella l'azione di LabelSwap (obsoleto).
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si esegue l'operazione di aggiornamento dell'header ottico del pacchetto.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.17 LogarithmicAttenuator (not used)
Elemento che modella l'attenuazione logaritmica del segnale ottico.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
TYPE: indica se modellare l'attenuazione logaritmica di uno splitter, combiner, etc...;
•
N: valore parametrico per la funzione logaritmo;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action si restituisce il paccchetto.
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.18 NETCONFManager
Elemento che modella la gestione dei messaggi provenienti dal demone NETCONF.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ANNO: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, quando riceve un pacchetto dalla socket deputata al dialogo con il NETCONF, esegue le operazioni in base al comando ricevuto.
L'elemento ha inoltre i seguenti handlers:
•
non usati
56
11 novembre 2010
Elenco degli Elementi
Versione 1
6.19 NewElement
Scheletro per a definizione di nuovi elementi.
6.20 NewHeaderAppend (not used)
Elemento che modella l'aggiornamento dell'header ottico all'uscita dal nodo.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
WAVELENGTH: la lunghezza d'onda;
•
GUARDBAND1: dimensione guardband1;
•
GUARDBAND2: dimensione guardband 2;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action in base alle informazioni si esegue un determinato codice.
N.B: Qui era pensato di agire su un pacchetto ottico formato da un header (5 bytes) una
guard band da 6 byte il payload 48 byte e un'altra guard banda da 5 bytes!!! Vedi esempio
formato pacchetto ottico KEOPS
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.21 NoiseSource
Elemento che modella una sorgente di rumore.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
INPUT_W: numero di lunghezze d'onda;
•
Emulazione di Potenza: attiva o meno;
•
Gain: guadagno;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
id
6.22 OCSSignalingChannel
Elemento che modella il canale di segnalazione per OCS.
14 dicembre 2010
57
Elenco degli Elementi
Versione 1
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ANNO: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, all'arrivo del pacchetto si controlla la provenienza e si entra in un'opportuna biforcazione del codice sorgente per caratterizzare comportamenti diversi
in base al tipo di appartenenza.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
id
6.23 OpticalRouterAnnotations
Questo è un file particolare in cui sono presenti le costanti condivise ed utilizzate in tutto il
modello in particolare:
•
Byte relativi alle annotazioni: ogni pacchetto click porta con se le annotazioni, 48 bytes, che assumono il significato espresso in questo file. In particolare questi valori sono
riportati anche all'inizio dei file di configurazione per essere usati al loro interno.
•
Costanti di vario tipo
◦ Messaggi RSVP
◦ Valori paradigmi OPS, OBS e OCS e priorità
◦ Valori ControlBus
◦ Soglie valori di potenza
•
Strutture condivise: strutture dati condivise da più elementi vengono dichiarate qui
con 'extern'
◦ Circuit
◦ WhiteAddress
6.24 PowerModule
Elemento per il calcolo del valore di potenza
6.25 ReadAnnotationBytes
Elemento di prova per leggere le annotazioni.
6.26 ReadAnnotation
Elemento di prova per leggere le annotazioni.
58
11 novembre 2010
Elenco degli Elementi
Versione 1
6.27 ReadWavelengthColor
Elemento che legge la lunghezza d'onda del pacchetto
6.28 RSVPManager
Elemento che modella la gestione dei messaggi provenienti dalla segnalazione OCS su GMPLS/RSVP-TE.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
INTEGRITY: se controllare o meno l'integrità dei pacchetti RSVP;
•
CURRENTHOPADDRESS: indirizzo corrente del nodo ottico nella rete;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action invece, quando riceve un pacchetto dal canale di segnalazione o
dal CEScheduler, esegue le operazioni in base al tipo di messaggio e al mittente ricevuto.
Il metodo send_message indica che questo elemento è collegabile ad un elemento bus per inviare e riceverne messaggi settando il tipo, sorgente e destinazione;
L'elemento ha inoltre i seguenti handlers:
•
non usati
6.29 RSVPMessage
Elemento che modella il messaggio RSVP come punto di appoggio nella memorizzazione.
6.30 SetPower
Elemento per impostare i valori di OSNR e Potenza(not used);
6.31 SetTimeslot
Elemento per valutare il valore del corrente timeslot;
6.32 SetTrafficNeed
Elemento che imposta il traffico in base al paradigma (not used);
6.33 SOASwitch
Elemento che modella uno switch ottico.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
14 dicembre 2010
59
Elenco degli Elementi
Versione 1
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Emulazione di Potenza: attiva o meno;
•
Control Type: tipo di controllo potenza o guadagno;
•
Model Type: modello EDFA, secondo datasheet modello 1 o 2 vedi report Ivan;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
switch
•
config
6.34 Splitter
Elemento che modella uno splitter.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Ports: numero di lunghezze d'onda;
•
Emulazione di Potenza: attiva o meno;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
none
6.35 TimeslotManager
Elemento per la gestione del timeslot;
6.36 TimeslotMarker
Elemento per la marcatura del timeslot;
60
11 novembre 2010
Elenco degli Elementi
Versione 1
6.37 TimeWrite
Elemento per la scrittura dei timestamp per il calcolo delle performance;
6.38 TunableWavelengthConverter
Elemento che modella un convertitore di lunghezza d'onda.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
Wavelengths: numero di lunghezze d'onda;
•
Emulazione di Potenza: attiva o meno;
•
Colore: lunghezza d'onda su cui convertire a default;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
color
6.39 Wavelength
Elemento per la lettura e l'impostazione dei parametri sulla lunghezza d'onda del segnale
6.40 WDMMulti e Demultiplexer
Elemento che modella un mux o demux ottico WDM.
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ID elemento: un valore numerico in formato stringa che lo identifichi nella configurazione;
•
PORTS: numero di porte;
•
Emulazione di Potenza: attiva o meno;
•
Aggiunta del connettore: se l'elemento deve prevedere nel calcolo di potenza l'inserimento di due connettori nei punti di collegamento;
•
Verbose: se l'elemento deve stampare a video stringhe utili al debug;
14 dicembre 2010
61
Elenco degli Elementi
Versione 1
Nel metodo simple-action se è attiva la funzione di emulazione della potenza viene richiamato il metodo di powerMethod che ne calcola l'entità in base al tipo di modello e di controllo e
ne modifica di conseguenza i valori nelle annotazioni.
L'elemento ha inoltre i seguenti handlers:
•
none
6.41 WritePower
Elemento che scrive il valore di potenza dalle annotazioni all'header ottico in uscita dal nodo
(per essere rilevate dal ricevitore e valutare le oscillazioni prodotte).
Nel metodo configure imposta i parametri passati nella stringa di configurazione all'atto di
creazione nel file di configurazione click e si inizializzano le variabili da usare.
•
ANNO: un valore numerico in formato stringa che lo identifichi nella configurazione;
Nel metodo simple-action invece, si copiano i valori di Power e OSNR dalle annotazioni all'intestazione del pacchetto;
7 Risultati
In questa sezione verranno presentati i risultati ottenuti durante i mesi di lavoro e pubblicati sui
vari articoli scientifici prodotti (HPSR 2010, ITWDC 2010, GLOBECOM 2010, INFOCOM
2011*). In particolare mostreremo i risultati riguardo agli aspetti di:
•
Validazione (HPSR 2010);
•
Standardizzazione, Multi-granularità e Sicurezza (ITWDC 2010, GLOBECOM 2010);
•
Performance (INFOCOM 2011*);
•
Caratterizzazione in Potenza (INFOCOM 2011*)
* N.B: L'articolo per la conferenza internazionale INFOCOM 2011 non è stato accettato (acceptance rate 16%), il lavoro verrà ampliato e riproposto ad un altra conferenza.
7.1 Validazione
Il primo risultato voluto ed ottenuto è stata la validazione del modello. Si è lavorato in modo
che l'emulatore, in una data configurazione in termini di matrice di commutazione e algoritmo
di scheduling, presentasse lo stesso comportamento (ovvero quantità di traffico correttamente
schedulato e/o perso a fronte di contese insolubili) di un simulatore software esistente e collaudato, caratterizzato dalla stessa architettura per la matrice di commutazione e lo stesso algoritmo di scheduling.
62
11 novembre 2010
Risultati
Versione 1
Illustrazione 30: Validazione al variare del carico e delle configurazioni del nodo.
Come si evince dalla figura, i risultati sono rappresentati dalle curve (risultati simulazione) e
dai punti (risulati emulazione) che esprimono il tasso di perdita di un nodo con architetture simili.
La sovrapposizione di punti e curve indica che i due strumenti (simulatore ed emulatore)
giungono alle stesse conclusioni di perdita per carico di traffico crescente confermando di fatto la correttezza (e quindi la validazione) dello strumento emulatore.
Le curve esprimono come accennato la percentuale di perdita di un nodo al variare della architettura e del carico di traffico, in un solo termine viene espressa la Packet Loss Probability.
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:
PLP =
•
•
Pacchetti Entrati− Pacchetti Usciti
Pacchetti Entrati
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.
7.2 Standardizzazione, Multi-granularità e Sicurezza
Altri tre aspetti della categoria dei risultati riguardano la standardizzazione (in termini di protocolli usati per il dialogo all'interno e/o all'esterno del modello), l'introduzione della multigranularità (ovvero della co-esistenza di paradigmi di traffico differenti come quello a pacchetto OPS e a circuito OCS) e la presenza di meccanismi di sicurezza (insiti nei protocolli
ma anche in elementi modulari del modello che permettono di analizzare il traffico e autorizzarlo solo in caso di successo nella verifica di opportune caratteristiche).
Per evidenziare tali risultati viene utilizzato uno strumento di analisi e cattura del traffico sulla rete, chiamato Wireshark (opportunamente modificato per includere anche i protocolli di re14 dicembre 2010
63
Risultati
Versione 1
cente definizione come ad es. IETF ForCES) e di questo ne viene proposta la finestra di cattura relativa ad una emulazione a traffico misto OPS + OCS oltre ad un grafico che illustra il throughput complessivo del nodo differenziato per tipologia di traffico.
Illustrazione 31: Cattura Wireshark.
Illustrazione 32: Grafico del throughput OPS/OCS.
•
•
64
La cattura è in ascolto sul canale di segnalazione fuori banda del traffico OCS e sul canale di comunicazione tra il demone NETCONF ed eventuali Client (interazione HO e
GOs), presenta una riga per ogni pacchetto catturato (n°), l'istante di cattura (in secondi, qui 1 timeslot = 1 sec), l'IP sorgente e destinazione del pacchetto, il protocollo in
uso (RSVP), il tipo di messaggio.
Il grafico a destra mostra il throughput del traffico OPS (rosso, in alto) e OCS (blu, in
basso) con dei riferimenti negli istanti significativi della emulazione. Il throughput del
nodo è plottato analizzando i contatori (via click handlers) diversificati per paradigma
presenti all'interno del modello.
11 novembre 2010
Risultati
Versione 1
Sull'asse orizzontale è presente il riferimento temporale in timeslot (1 timeslot = 1
sec) mentre sull'asse verticale è presente il throughput.
Questo è normalizzato ad 1 per una configurazione 2x2 con 4 lunghezze d'onda ovvero 8 canali.
Questo significa che se avessimo solo traffico a pacchetto (es. nel tratto tra il timeslot
0 e 500) su tutti i canali con carico pari ad 1 e nessuna contesa la linea rossa sarebbe
fissa ad 1. In realtà il traffico OPS generato dalla nostra emulazione ha si carico = 1
ma non è esente da contese e questo caratterizza il classico andamento ondulatorio del
throughput OPS che si attesta tra 0.8 e 1 evidenziando le perdite dovute alle contese.
In presenza invece di traffico OCS (dal timeslot 500 in poi) si possono osservare due
comportamenti distinti, ovvero il throughput del traffico OCS totale balza ad un valore
pari a 0,125 in quanto il traffico OCS è di tipo Constant Bit Rate (CBR) ed occupa
quindi tutto il canale, ovvero 1/8 = 1,25 del throughput totale mentre il throughput del
traffico OPS totale diminuisce (in quanto meno prioritario un canale OPS viene perso
per realizzare il circuito) di un valore pari a – 0,125.
Analizziamo ora la cattura in ordine temporale ricordando le seguenti condizioni iniziali che:
•
La tabella Whitelist contiene i seguenti indirizzi:
◦
•
Receiver Fidati (N.B: mancano gli indirizzi pari!!!)
▪ 192.168.101.1
▪ 192.168.103.1
▪ 192.168.105.1
▪ 192.168.107.1
◦ Sender Fidati
▪ 172.16.0.1
▪ 172.16.1.1
▪ 172.16.2.1
▪ 172.16.3.1
▪ 172.16.4.1
▪ 172.16.5.1
▪ 172.16.6.1
▪ 172.16.7.1
◦ Next e PreviousHop
▪ 10.50.50.1
▪ 10.50.51.1
▪ 10.50.50.2
▪ 10.50.51.2
▪ 10.100.50.1
▪ 10.100.51.1
▪ 10.100.50.2
▪ 10.100.51.1
La tabella CircuitRequests è vuota;
14 dicembre 2010
65
Risultati
Versione 1
•
La soglia circuiti (variabile fe_circuitsallowedthreshold) è impostata a 2;
Vediamo ora l'interazione temporale:
1. Il primo pacchetto è un ping per sincronizzare la cattura di Wireshark con i timeslot
dell'emulazione (pacchetto non visibile);
2. Il secondo pacchetto viene ricevuto sul canale di segnalazione fuori banda OCS all'istante/timeslot n°300. Il messaggio indica una richiesta di instaurazione di circuito per
un sender/client (IP 172.16.2.1) verso un receiver (IP 192.168.102.1). Questa richiesta
viene analizzata dal nodo, in particolare dal CE che la passa al CESM per la verifica di
sicurezza ed autenticità. Per scelta progettuale, staticamente prima dell'inizio della
emulazione, si è provveduto a riempire la WhiteList associata al CESM con i soli indirizzi dispari delle sotto-reti 172.16.1/3/5/7.1 e 192.168.101/103/105/107.1. Nel confronto tra sender e receiver il CESM non trova corrispondenza nella WhiteList e da indicazione al CE di rifiutare la richiesta in quanto non pervenuta da indirizzi autorizzati
all'utilizzo del servizio a circuito.
Il pacchetto viene semplicemente ucciso nel nodo senza dare notifica al mittente, a cui
scadrà il timeout di attesa di risposta e proverà in seguito (N.B: questa soluzione non è
ottimale occorrerebbe sempre dare notizia dell'avvenuto rifiuto, vedere se esistono tipi
di errore RSVP per segnalare questo evento).
3.
66
Il secondo pacchetto viene ricevuto all'istante/timeslot n°510. Il messaggio indica una
richiesta di instaurazione di circuito per un sender/client (IP 172.16.5.1) verso un receiver (IP 192.168.105.1). Questa richiesta viene analizzata dal nodo, in particolare dal
CE (in realtà viene decodificata dal RSVPManager) che la passa al CESM per la verifica di sicurezza ed autenticità. Questa volta sender e receiver fanno parte della WhiteList (che come detto è riempita staticamente in avvio con i soli indirizzi dispari delle
sotto-reti 172.16.1/3/5/7.1 e 192.168.101/103/105/107.1).
Nel confronto tra sender e receiver il CESM trova dunque corrispondenza nella WhiteList e da indicazione al CE di accettare la richiesta in quanto pervenuta da indirizzi
autorizzati all'utilizzo del servizio a circuito.
Il CE a questo punto (CEScheduler) crea una istanza nella tabella delle richieste di
circuito CircuitRequests per gestire la stessa, in cui vengono memorizzati tutti i parametri relativi (record occupato = true, stato = listen, IP src, IP dst, … N.B: ogni circuito è univocamente identificato dalla coppia Destination IP e tunnel-id del protocollo
RSVP) e passa la richiesta al FE (FEScheduler messaggio interno OCS_REQ o equivalente ForCES).
L'FE (FEScheduler) controlla la soglia di circuiti correnti instaurati attraverso il nodo.
Per scelta progettuale si è definita una soglia logica di circuiti OCS contemporaneamente possibili sul nodo pari a Th=2. Questo perché non avere una soglia potrebbe significare l'occupazione del nodo esclusivamente per il traffico a circuito, maggiormente prioritario rispetto al pacchetto, rendendo il nodo impermeabile al traffico a pacchetto. Con questa soluzione si mantiene dunque attiva sempre la multi-granularità.
Dato che, attualmente (all'istante 500), nel nodo non sono presenti circuiti il FE dà
l'ok al controllo sulla soglia (diminuendola Th = 2 – 1 = 1), e passa il messaggio al FM
deputato (FM_OCS attraverso un messaggio OCS_REQ o equivalente ForCES).
Il FM controlla se, attualmente (all'istante 500), sarebbe in grado di instaurare il circuito come richiesto in base alla disponibilità dell'hardware ed in particolare su quale e
quante lunghezza d'onda è in grado di convertire il circuito in ingresso al nodo per diventarne parte. Questo dipende dalla fibra di ingresso e di uscita del circuito derivata
dagli indirizzi IP del sender e del receiver del circuito. Se per la data IF e OF voluta vi
sono nel pool di convertitori di lunghezza d'onda delle lunghezze d'onda libere o occupate con priorità inferiore a quella del circuito, allora sono in grado di accettare. Se
11 novembre 2010
Risultati
Versione 1
riesco a trovare almeno una lunghezza d'onda vuol dire che (attualmente) sono in grado di instaurare sul nodo il circuito richiesto, memorizzo la lista delle lunghezze d'onda su cui posso convertire e restituisco al FE un messaggio OCS_GRANT o l'equivalente ForCES.
In realtà se trovo una sola lunghezza d'onda e dò l'ok a questo circuito può avvenire
che arrivi un'altra richiesta OCS e anche a questa verrà comunicata la disponibilità
della lunghezza d'onda (allo stato attuale non è occupata da nessun circuito!). Questo
perché è meglio “prenotare” in questa fase la lunghezza d'onda anziché marcare come
occupata per il futuro perché se la fase di instaurazione del primo circuito dovesse fallire nei nodi a valle avremmo rifiutato il secondo senza motivo e quindi perso la potenzialità di instaurare almeno 1 dei 2 circuiti.
Se non trovo alcuna lunghezza d'onda libera comunico al FE l'impossibilità di instaurare il nodo per indisponibilità hardware corrente ed invio un messaggio OCS_DENY
o l'equivalente ForCES.
Nel nostro caso il nodo ha disponibilità di lunghezze d'onda e risponde con un
OCS_GRANT al FE.
A questo punto l'FE se riceve un OCS_GRANT o l'equivalente ForCES lo ritorna
semplicemente al CE (come nel caso corrente) mentre se riceve un OCS_DENY aumenta di nuovo il valore di soglia di 1 (nel nostro caso Th = 1 + 1 = 2) e ritorna il
messaggio OCS_DENY o l'equivalente ForCES.
Il CE a questo punto aggiorna lo stato della richiesta di circuito corrente nella tabella
CircuitRequests a PATH_SENT ed invia il PATH (aggiornato nell'indirizzo del previous hop, nodo corrente, e nella lista delle lunghezze d'onda disponibili per il next
hop) al next hop (N.B: il path inviato dal nodo al next hop non si vede nella cattura occorre inserire la cattura completa!!!).
4. Il terzo pacchetto viene ricevuto all'istante/timeslot n°513 (3 secondi è infatti il tempo
che attende il programma receiver per rispondere con un RESV, tempo introdotto per
simulare il tempo di attraversamento di una serie di nodi a valle). Il messaggio indica
la conferma di instaurazione del circuito precedente (ogni circuito è univocamente
identificato dalla coppia Destination IP e tunnel-id del protocollo RSVP) e proviene
questa volta dal next hop (IP 10.100.51.2) verso una delle reti rappresentate dal current
hop (IP 10.100.51.1). Questo messaggio come tutti viene analizzato dal nodo, in particolare dal CE (in realtà viene decodificata dal RSVPManager) che la passa al CESM
per la verifica di sicurezza ed autenticità. Anche questa volta sender e receiver fanno
parte della WhiteList (vedi sopra).
Nel confronto tra sender e receiver il CESM trova dunque corrispondenza nella WhiteList e da indicazione al CE di accettare la richiesta in quanto pervenuta da indirizzi
autorizzati all'utilizzo del servizio a circuito.
Il CE a questo punto (CEScheduler) aggiorna l'istanza nella tabella delle richieste di
circuito CircuitRequests passando allo stato RESV_RECEIVED e passa la richiesta al
FE (FEScheduler messaggio interno OCS_ACK o equivalente ForCES).
L'FE (FEScheduler) ha già tenuto conto di questa richiesta nel computo della soglia e
quindi passa diretamente il messaggio al FM deputato (FM_OCS attraverso un messaggio OCS_COMMIT o equivalente ForCES).
Il FM controlla se, attualmente (all'istante 513) è in grado di instaurare il circuito
come richiesto in base alla disponibilità dell'hardware ed in particolare su quale e
quante lunghezza d'onda è in grado di convertire il circuito in ingresso al nodo per diventarne parte. Questo dipende dalla fibra di ingresso e di uscita del circuito derivata
dagli indirizzi IP del sender e del receiver del circuito e dalla lunghezza d'onda scelta
14 dicembre 2010
67
Risultati
Versione 1
dal next hop per ricevere e dalle lunghezze d'onda disponibili a trasmettere comunicte
dal previous hop nel precedente PATH.
Cerco quindi di stabilire se posso occupare le risorse hardware opportune ovvero, per
questa architettura, il convertitore di lunghezza d'onda ed il SOA opportuno.
Per il convertitore scelgo innanzitutto un convertitore nel pool della IF da cui proviene il circuito (che dipende dall'IP del sender) ed in particolare quello della lunghezza
d'onda da cui voglio ricevere il traffico a circuito, scelto come la prima lunghezza tra
quelle libere comunicatemi come disponibili dal previous hop (nel messaggio PATH
relativo a questo circuito). Inoltre imposterò il TWC in modo da convertire sulla lunghezza d'onda richiesta dal nexthop e comunicatami nel corrente RESV (nella parte
GMPLS del protocollo RSVP)
Il SOA da riservare sarà determinato dalla IF, lunghezza d'onda di conversione e OF
del circuito.
Se queste risorse sono libere o occupate con priorità inferiori a quella del paradigma a
circuito (priorità massima) allora posso instaurare il circuito ed invio OCS_SUCCESS
o l'equivalente ForCES. altrimenti comunico un errore nell'allocazione delle risorse ed
invio OCS_FAILURE o l'equivalente ForCES..
5.
6.
7.
8.
9.
68
Nel nostro caso il nodo ha disponibilità di lunghezze d'onda e risponde con un
OCS_SUCCESS al FE.
A questo punto l'FE ritorna semplicemente il messaggio OCS_SUCCESS o FAILURE
o l'equivalente ForCES al CE.
Il CE a questo punto aggiorna lo stato della richiesta di circuito corrente nella tabella
CircuitRequests a CIRCUIT_ESTABLISHED ed invia il RESV (aggiornato nell'indirizzo del previous hop, nodo corrente, e nella lista delle lunghezze d'onda disponibili
per il next hop) al previous hop.
Nel grafico si può notare che a partire da questo istante si avverte il traffico CBR di
tipo OCS (throughput 0,125) e l'equivalente diminuzione nel throughput OPS (uno dei
canali in cui fluiva prima traffico OPS ora è destinato al circuito).
I pacchetti 5, 6 e 7 all'istante 634 sono pacchetti della transazione di un comando
NETCONF da parte di un GO verso l'HO incapsulati in una sessione criptata e protetta
via SSH. In particolare qui riceviamo il comando NETCONF da parte di una console
Client remota rispetto al nodo (la command console deisnet 209 ad es.) che chiede al
modulo netconf-yang opticalrouter di aggiornare la WhiteList inserendo tra l'elenco
dei receiver fidati anche gli indirizzi “pari” ovvero 192.168.100/102/104/106.1. Questo comando realizza di fatto la programmabilità del nodo e simula ad esempio l'intenzione di un Internet Service Provider (GO) di abilitare il servizio a circuito per alcune
sue sotto-reti destinazione (quelle appunto, con l'indirizzo pari)
Vedi sopra;
Vedi sopra;
L'ottavo pacchetto indica (di nuovo) una richiesta di instaurazione di circuito per un
sender/client (IP 172.16.2.1) verso un receiver (IP 192.168.102.1). Questa richiesta
viene analizzata dal nodo, in particolare dal CE che la passa al CESM per la verifica di
sicurezza ed autenticità. Questa volta, grazie al comando netconf impartito in precedenza, il confronto di sender e receiver nella WhiteList effettuato dal CESM troverà riscontro e la richiesta verrà accettata!!! La soglia diventa Th = 0 (se si rimane così nes sun altro circuito può essere richiesto per limite di soglia!!!).
RESV Message di accettazione del circuito precedente. Nel grafico si può notare che a
partire da questo istante si avverte che il traffico CBR di tipo OCS balza ad un throu-
11 novembre 2010
Risultati
Versione 1
ghput 0,250) e l'equivalente diminuzione nel throughput OPS (due dei canali in cui
fluiva prima traffico OPS ora sono destinati al circuito).
10. I pacchetti 10, 11 e 12 all'istante 1206 sono pacchetti della transazione di un comando
NETCONF da parte di un GO verso l'HO incapsulati in una sessione criptata e protetta
via SSH. In particolare qui riceviamo il comando NETCONF da parte di una console
Client remota rispetto al nodo (la command console deisnet 209 ad es.) che chiede al
modulo netconf-yang opticalrouter di ridurre la banda del traffico OPS di un valore
corrispondente a 2 canali. Questo comando realizza di fatto la programmabilità del
nodo e simula ad esempio l'intenzione del gestore del nodo (HO) di ridurre il traffico
OPS in attraversamento sul suo device.
Nel grafico si può notare che a partire da questo istante si avverte che il traffico di tipo
OPS decresce di un valore pari a 0,250 l'equivalente diminuzione del traffico di 2 canali.
11. Vedi sopra;
12. Vedi sopra;
13. Questo messaggio indica la chiusura del primo circuito instaurato, il nodo rilascia le
risorse e torna disponibile su quel canale al traffico OPS. Nel grafico si può notare che
a partire da questo istante si avverte che il traffico CBR di tipo OCS si riduce ad un throughput 0,125 (un solo circuito in atto) e l'equivalente aumento nel throughput OPS
(al netto della riduzione dovuta al comando netconf di riduzione banda).
14. Questo messaggio indica la chiusura del secondo circuito instaurato, il nodo rilascia le
risorse e torna disponibile su quel canale al traffico OPS. Nel grafico si può notare che
a partire da questo istante si avverte che il traffico CBR di tipo OCS si riduce ad un throughput 0 (nessun circuito in atto) e l'equivalente aumento nel throughput OPS (al
netto della riduzione dovuta al comando netconf di riduzione banda).
15. Nuova richiesta circuito accettata.
16. Instaurazione del circuito.
Analizziamo ora la cattura protocollo per protocollo.
7.2.1 RSVP/GMPLS Protocol
Ogni richiesta di circuito che attraversa il nodo è catturata mediante un filtro su protocollo RSVP.
Ai messaggi di discovery del mittente PATH si risponde, in caso ci sia disponibilità di
risorse, inoltrando il PATH al NextHop e ponendosi in attesa di un messaggio di conferma per l'occupazione delle risorse destinate al circuito attraverso la ricezione di un messaggio RESV da parte del NextHop.
In caso di indisponibilità delle risorse correnti il nodo risponde ai messaggi di discovery
del mittente PATH mediante PATHERROR.
In caso di indisponibilità delle risorse sui nodi a valle nodo riceve dei RESVERROR.
In caso di abbattimento del circuito da parte del mittente il nodo riceve un PATHTEAR
che viene propagato al seguito del rilascio delle risorse occupate per il circuito.
Analogamente in caso di abbattimento del circuito da parte del ricevente il nodo riceve
un RESVTEAR che viene propagato al seguito del rilascio delle risorse occupate per il
circuito.
14 dicembre 2010
69
Risultati
Versione 1
7.2.2 NETCONF Protocol
Il protocollo di management del nodo si appoggia sull'implementazione YUMA di
NETCONF e i comandi che prevedono l'abilitazione di una serie di indirizzi IP di un
ISP autorizzato a interagire sulla WhiteList del nodo sono evidenti in cattura e nel graffico.
All'istante P1 arriva al router una richiesta di circuito da parte di un mittente
(192.168.102.1) non inserito nella WhiteList, la sua richiesta viene dunque scartata
(nessuna risposta RSVP).
All'istante N1 della emulazione il G.O. (ovvero l'ISP che possiamo pensare è a capo della rete del mittente non autorizzato 192.168.102.1) si autentica alla gestione del nodo
mediante NETCONF e in particolare sfruttando SSH (username e password ssh) al nodo
come evidenziato dalla cattura dei pacchetti netconf-ssh su Wireshark.
I comandi che il G.O. Impartisce riguardano l'aggiunta di un determinato indirizzo alla
WhiteList (in particolare l'indirizzo 192.168.102.1) che da ora in poi sarà autorizzato
alla richiesta del servizio a circuito.
All'istante successivo P3 arriva di nuovo al router una richiesta di circuito da parte del
mittente 192.168.102.1 questa volta non inserito nella WhiteList, la sua richiesta viene
dunque accolta.
All'istante N2 della emulazione l'H.O. (ovvero il gestore del nodo hardware condiviso tr
più GOs) si autentica alla gestione del nodo mediante NETCONF e in particolare sfruttando SSH (username e password ssh) come evidenziato dalla cattura dei pacchetti netconf-ssh su Wireshark e richiede l'abbassamento della banda a pacchetto per il GO in
esame riducendola di 2 canali.
All'istante successivo è possibile osservare un'abbassamento proporzionale del throughput OPS nel nodo in esame.
7.2.3 ForCES Protocol
Questo protocollo è stato implementato di recente con il lavoro del laureando Ramon
Righini. In particolare sono stati creati degli elementi tra il CE ed il FE che incapsulano
i messaggi correnti in formato “click” (OCS_REQ, OCS_ACK, …) nel formato del protocollo forces, di cui si mostra sotto in figura la cattura:
7.3 Performance
Un'altro dei risultati ottenuti è l'andamento delle performance dell'emulatore quando spinto ai
limiti della velocità con cui si presenta il traffico e delle configurazioni di conversione che
questo affronta. Possiamo quindi individuare due sotto-aspetti:
•
Tempo di processamento dell'header e set-up della matrice di commutazione;
•
Riduzione della durata del timeslot;
N.B: Questa analisi è completamente dipendente dall'hardware utilizzato in questo caso
ovvero un Server Dell PowerEdge 1600SC con mP a 3.6 Ghz, 512 MB RAM, tre schede di
rete, gigabit ethernet ad interrupt!!!
70
11 novembre 2010
Risultati
Versione 1
7.3.1 Packet header processing time
Nella valutazione delle performance importante rilevanza ha il tempo di processamento
dell'header del pacchetto e del relativo tempo di set-up dei dispositivi della matrice. In
particolare si possono avere differenti scenari relativi alla matrice di commutazione:
•
Bar State: in questo scenario i pacchetti in ingresso all'interfaccia IF0 sono
schedulati in modo da fuoriuscire dal nodo attraverso l'interfaccia di uscita OF0
senza subire conversione.
•
Switching Only: in questo scenario i pacchetti in ingresso all'interfaccia IF0
sono schedulati in modo da fuoriuscire dal nodo attraverso l'interfaccia di uscita
OF1 e viceversa senza subire conversione (solo cambio di interfaccia).
•
Conversion Only: in questo scenario i pacchetti in ingresso all'interfaccia IF0
sono schedulati in modo da fuoriuscire dal nodo attraverso l'interfaccia di uscita
OF0 e subiscono tutti conversione (chi arriva su lambda 0 diventa lambda 3,
lambda 1 diventa lanbda 2 etc...).
•
Switching & Conversion: in questo scenario i pacchetti in ingresso all'interfaccia IF0 sono schedulati in modo da fuoriuscire dal nodo attraverso l'interfaccia
di uscita OF1 e subiscono tutti conversione (chi arriva su lambda 0 diventa
lambda 3, lambda 1 diventa lanbda 2 etc oltre a cambiare interfaccia...).
◦ N.B: Teoricamente il caso peggiore!!!
•
Random Scheduling: in questo scenario i pacchetti in ingresso sono schedulati
e convertiti per lunghezze d'onda e interfacce casuali;
◦ N.B: Simulazione di traffico reale!
Illustrazione 33: Bar State.
Illustrazione 34: Only switching.
Illustrazione 35: Only conversion.
Illustrazione 36: Switching & conversion.
14 dicembre 2010
71
Risultati
Versione 1
I risultati pervenuti dal test sul modello sono espressi nella tabella a seguire:
Illustrazione 37: Risultati sul tempo di
processamento dell'header e set-up dei
dispositivi della matrice.
Queste misure sono state svolte facendo stampare al click! Il campo timeslot dei pacchetti in ingresso ed in uscita dal piano di controllo, processando l'output per raccoglierre questi valori ed utilizzando un foglio di calcolo per estrapolarne i risultati.
E' stato calcolato il tempo medio in micro-secondi impiegato dal modello a processare
l'header ottico di un singolo pacchetto dall'ingresso nel piano di controllo fino al set-up
dei corrispondenti dispositivi nella matrice di controllo. Questa misura è ripetuta per
ogni scenario di configurazione, ognuna ricalcolata più volte (5-10) per derivarne la varianza delle misurazioni e l'intervallo di confidenza al 95%.
Possiamo quindi vedere che il caso peggiore risulta essere il caso random (al contrario
del previsto caso switching & conversion) con un tempo medio di 80 micro-secondi ed
una varianza di 3.48 micro-secondi.
7.3.2 Time Slot reduction
Un'altro aspetto delle performance riguarda valutare fino a che punto l'hardware a disposizione è in grado di processare correttamente i pacchetti, ovvero fino a quale intervallo di tempo è possibile ridurre il timeslot mantenendo la funzionalità del modello al
fine di ridurre i tempi delle emulazioni.
Ad esempio finora si sono osservate emulazioni con timeslot dell'ordine del secondo o
poco meno, il che significa che se volessimo valutare un numero molto alto di pacchetti,
ad es. 1.000.000, in una configurazione 2x2 a 4 lunghezze d'onda a pieno carico occorrerebbero 1.000.000 / 8 * 1 sec = 34,72 ore!!! Un tempo non ragionevole.
Per cercare questo limite si è imposta una configurazione nota del traffico in cui l'header ottico proposto al nodo non prevedeva conflitti in modo da avere in uscita al nodo lo
stesso numero di pacchetti in ingresso. Si è poi parametrizzato il generatore di traffico in
modo da generare pacchetti ogni timeslot di dimensione variabile in modo da poter effettuare le misure.
Riducendo man mano il timeslot, per una configurazione nota in cui la perdita dei pacchetti in ingresso (80.000) è nulla, osserviamo (per differenti misure del payload ottico)
il comportamento del modello:
72
11 novembre 2010
Risultati
Versione 1
Illustrazione 38: Effetto della riduzione
del timeslot sulle performance del
modello.
Ovviamente, diminuendo man mano il timeslot il modello “perde” pacchetti e questa
perdita non è dovuta a contese ma al fatto che il modello non riesce a far fronte ad un
traffico così “veloce” e quindi a settare i suoi dispositivi per schedulare con correttezza
il traffico. Ad un limite di 15 milli-secondi per timeslot abbiamo che il modello non perde nulla, e questo rappresenta il limite oltre cui non possiamo andare nelle nostre emulazioni senza perdere di validità.
7.4 Caratterizzazione di Potenza
L'aspetto della caratterizzazione di potenza del modello è uno degli aspetti più interessanti e
di maggior successo nella realizzazione del modello.
Come parametri utili ai fini dello studio si è pensato di fornire riferimenti rispetto alla potenza del segnale ottico ed al suo rapporto segnale rumore o OSNR.
In particolare vedremo:
•
Il percorso del segnale ottico all'interno del nodo;
•
I profili di potenza e OSNR relativi a segnali ottici convertiti o meno in lunghezza
d'onda;
N.B: Questi risultati saranno introdotti ed analizzati solo negli aspetti
principali ed implementativi in quanto lo studio analitico e di modellazione
fisica è fornita nel report di Ivan Aldaya presente nella documentazione!!!
7.4.1 Generico percorso del segnale ottico
La figura sottostante mostra il percorso del segnale ottico attraverso il nodo ed in particolare i vari stadi che questo attraversa:
14 dicembre 2010
73
Risultati
Versione 1
Illustrazione 39: Il percorso del segnale ottico attraverso il nodo.
Nel dettaglio abbiamo:
•
Connettori: Ogni piccolo pallino bianco rappresenta un punto di connessione ed
affligge il segnale con una attenuazione in potenza pari a 0,2 dB;
•
EDFA_1: E' il primo amplificatore di segnale (elemento attivo) serve per aumentare la potenza del segnale in modo da irrobustirlo per attraversare i componenti del nodo (e superare la soglia di sensitività di alcuni di questi). L'attenuazione di potenza e OSNR è complessa ed è presente nel report di Ivan;
•
DEMUX: Il demultiplexer WDM introduce una attenuazione della potenza in
base alla seguente formula che dipende dal numero di uscite del dispositivo:
Loss WDMDemux = 1,676 ln  N 1,046
•
•
FDL: La fibra di ritardo è modellata come un link ed introduce un attenuazione
proporzionale alla sua lunghezza (in tal caso pari a 3 dB)
TWC: Non esistendo datasheet disponibili di un così cruciale elemento la soluzione proposta da Ivan è stata quella di modellare il comportamento in base ai
due casi disponibili ovvero nel caso di conversione e in caso di non conversione
(Ivan sollevava anche dubbi sul fatto che un TWC possa solo convertire e non
mantenere la lunghezza d'onda uguale!!!).
◦ Splitter: questo splitter divide il segnale verso i due percorsi introduce una
attenuazione della potenza in base alla seguente formula che dipende dal numero di uscite del dispositivo:
Loss Splitter = 5,561 ln  N −0,221
◦
◦
◦
74
Conversion Path: nel caso in cui il convertitore performi la conversione di
lunghezza d'onda questo può essere modellato come:
▪ WC: elemento vero e proprio che effettua la conversione, affligge notevolmente la potenza del segnale di circa 24 dB generando rumore fino a
40 dB;
▪ SOA Amplifier: SOA utilizzato come amplificatore per riequalizzare la
potenza del segnale a valle del WC;
No-Conversion Path: nel caso in cui il convertitore non performi alcuna
conversione di lunghezza d'onda questo può essere modellato come:
▪ Attenuatore;
▪ SOA Switch: SOA utilizzato come interruttore;
Combiner: riunisce il segnale proveniente dai due percorsi introduce una attenuazione della potenza in base alla seguente formula che dipende dal numero di uscite del dispositivo:
11 novembre 2010
Risultati
Versione 1
Loss Combiner = 0,11052⋅N 0,979
◦
•
•
•
•
•
•
NoiseSource: in base alle conversioni contemporanee nel pool dei convertitori possono essere presenti dei disturbi modellati da questo componente. Ad
ogni timeslot si controlla il numero di conversioni contemporanee e si setta il
componente per introdurre un rumore proporzionale.
Combiner: riunisce il segnale proveniente dai due percorsi;
EDFA_2: E' il secondo amplificatore di segnale (elemento attivo) serve per aumentare la potenza del segnale in modo da irrobustirlo per attraversare i componenti del nodo (e superare la soglia di sensitività di alcuni di questi). L'attenuazione di potenza e OSNR è complessa ed è presente nel report di Ivan;
Splitter: questo splitter divide il segnale verso i due percorsi;
DEMUX: Il demultiplexer WDM;
SOA Switch: SOA utilizzato come interruttore l'attenuazione di potenza e
OSNR è complessa ed è presente nel report di Ivan;
MUX: Il multiplexer WDM introduce una attenuazione della potenza in base
alla seguente formula che dipende dal numero di uscite del dispositivo:
Loss WDMMux = 0,11052⋅N 0,979
•
•
Combiner: riunisce il segnale proveniente dai due percorsi;
CrossTalk: introduce il rumore che dipende dal numero di porte, nel report di
Ivan vi è una tabella con i valori riportati;
7.4.2 Profili di Potenza e OSNR
Presentiamo ora dei grafici che mostrano i profili di potenza e OSNR del segnale ottico
che attraversa tutti gli stadi visti in precedenza nel caso in cui incontri sul suo cammino
una conversione o meno o se nello stesso pool avvengano contemporaneamente altre
conversioni di lunghezza d'onda:
14 dicembre 2010
75
Risultati
Versione 1
•
Come si vede dalla prima figura vengono mostrati le variazioni di OSNR e potenza quando nel pool di twc (stessa IF) non vengono eseguite contemporaneamente altre conversioni (nessuna sorgente di rumore aggiuntiva) per i casi in cui:
◦ a) il segnale non viene convertito in lunghezza d'onda: si possono notare i livelli che variano di stadio in stadio.
◦ b) il segnale viene convertito in lunghezza d'onda: si può notare il gradino
dovuto alla conversione e successiva riamplificazione nello stadio 5 e 6;
•
Nella seconda figura vengono mostrati le variazioni di OSNR e potenza quando
nel pool di twc (stessa IF) avvengono 3 conversioni simultanee (aumento da parte di sorgente di rumore aggiuntiva) per i casi in cui:
◦ a) il segnale non viene convertito in lunghezza d'onda: si può notare un leggero gradino nello stadio 8 dovuto al rumore;
◦ b) il segnale viene convertito in lunghezza d'onda: si può notare il gradino
dovuto alla conversione e successiva riamplificazione nello stadio 5 e 6 e un
grande gradino nello stadio 8 dovuto al rumore;
L'immagine sottostante invece propone la variazione in dB di potenza e OSNR in ingresso ed uscita al/dal nodo per un determinato canale in una emulazione di durata pari
a 50 timeslot (per evidenziare meglio i punti).
Assumendo un traffico OPS con carico pari ad uno, emuliamo dei valori di OSNR e potenza per i pacchetti in ingresso che variano casualmente in un range di valori ammissibili. Se il valore casuale è sopra la soglia di rilevazione del primo dispositivo in ingresso
(EDFA_1) allora per il corrente timeslot esisterà il segnale, quindi il pacchetto ed il rispettivo punto nel grafico. I pacchetti ad ogni timeslot possono trovarsi in situazioni differenti, in cui si necessita che siano convertiti o meno, o che siano sottoposti a conversioni adiacenti che ne influenzano il rapporto segnale rumore. I pacchetti correttamente
schedulati (contese risolte) e con valori non troppo logori di potenza e rumore fuoriescono dal nodo (sono infatti in numero minore rispetto ai pacchetti in ingresso).
76
11 novembre 2010
Risultati
Versione 1
Mentre i valori di potenza per i pacchetti in ingresso variano, in uscita i pacchetti correttamente schedulati vengono equalizzati dall'EDFA in uscita, mentre il loro OSNR è
afflitto dal fatto che vengano sottoposti o meno a conversione.
8 Software, wiki e manuali
Si era cominciato a discutere della possibilità di pubblicare il software sviluppato o quantomeno
la sua documentazione on-line per raggiungere visibilità ed attirare l'attenzione e/o ricercare collaborazioni in ambito sia universitario che industriale.
Le proposte avanzate riguardavano:
•
Pubblicazione dei lavori presentati alle conferenze sul sito del Click!
•
Pubblicazione del software sul sito del Click! Come pacchetto aggiuntivo del tool;
•
Pubblicazione di un sito per il progetto;
•
Pubblicazione di un sotto-sito wiki per la documentazione del progetto;
•
Pubblicazione di una pagina di interazione con il modello;
8.0.1 Pubblicazione dei lavori presentati alle conferenze sul
sito del Click!
Questo aspetto è stato assolto almeno in parte dato che Walter ha provveduto a pubblicare il paper HPSR 2010 sulla pagina.
Si suggerisce di aggiungere ITWDC 2010 e GLOBECOM 2010 per maggiore visibilità.
8.0.2 Pubblicazione del software sul sito del Click! Come
pacchetto aggiuntivo del tool;
Questo aspetto è stato preso in considerazione come elemento chiave per l'approvigionamento di supporto esterno al progetto. Rendendo aperto e di pubblico dominio il codice sorgente altre università o enti interessati potrebbero decidere di entrare valutandone
le potenzialità e segnalando bug e migliorie.
14 dicembre 2010
77
Software, wiki e manuali
Versione 1
Purtroppo esiste anche un aspetto negativo che riguarda la tutela del lavoro svolto che
non si vuole venga “attinto” e riproposto senza autorizzazione. Per questa delicata caratteristica l'idea è temporaneamente sospesa.
8.0.3 Pubblicazione di un sito per il progetto;
La realizzazione di un sito riguardante il progetto è stata messa in cantiere ma ha subito
la forza maggiore delle scadenze delle varie conferenze che richiamavano l'attenzione
ad aspetti più concreti del lavoro.
Raul e Walter avevano cominciato ad imbastire una piattaforma web basata su Joomla
per contenere le informazioni sul progetto, la documentazione e l'eventuale software.
Questa soluzione permette inoltre la possibilità di creare utenti e gestire i profili per la
pubblicazione delle news e l'accesso riservato ad alcune sezioni;
N.B: La piattaforma è ancora raggiungibile nel repository sulla macchina che funge
da host web del dipartimenot DEISNET (per l'indirizzo chiedere a Walter, user e password sono i nostri nomi e/o opticalrouter)!!!
8.0.4 Pubblicazione di un sotto-sito wiki per la
documentazione del progetto;
La realizzazione di un sotto-sito wiki raggiungibile dal sito del progetto per la documentazione è stata messa in cantiere ma ha subito la forza maggiore delle scadenze delle varie conferenze che richiamavano l'attenzione ad aspetti più concreti del lavoro.
Raul e Walter avevano cominciato ad imbastire una piattaforma basata su mediawiki
per contenere le informazioni relative alla documentazione che sono fondamentalmente
quelle poi scritte in questa relazione;
N.B: La pagina wiki è ancora raggiungibile nel repository sulla macchina che funge
da host web del dipartimenot DEISNET (per l'indirizzo chiedere a Walter, user e password sono i nostri nomi e/o opticalrouter)!!!
8.0.5 Pubblicazione di una pagina di interazione con il
modello;
Un ultimo aspetto riguarda la pubblicazione di una qualsiasi interfaccia web che permetta a chi è interessato di provare le funzionalità del modello;
Nonostante non abbia mai visto la luce rimane un punto cardine secondo il relatore per
la visibilità e la fruibilità del progetto.
9 Sviluppi futuri
Illustriamo ora brevemente una serie di accorgimenti o sviluppi futuri che rappresentano le priorità a breve e lungo termine della vita del progetto:
Due aspetti non legati alla implementazione:
•
Re-ingegnerizzazione del modello e documentazione
•
Apertura ad altri attori
Aspetti legati alla implementazione:
78
11 novembre 2010
Sviluppi futuri
•
•
•
Versione 1
Consumo di Potenza
Performance
Interfaccia Utente
9.1 Re-Ingegnerizzazione del modello e
documentazione
Ad avviso del relatore il lavoro mostrato fin qui ha tolto numerose soddisfazioni e raccolto
notevole interesse ma è stato svolto in condizioni di continua evoluzione dettata dalle tempistiche e deadline delle varie conferenze in cui questo è stato proposto.
Il primo e fondamentale sviluppo di cui occorrerebbe prendere carico è sfruttare le conoscenze fin qui acquisite riguardo il funzionamento logico e implementativo del modello nonché le
nozioni acquisite sul click e le sue funzionalità per impostare una re-ingegnerizzazione del
modello che passi da una sua completa riscrittura:
•
Partire da un modello ben definito in termini di nomi, protocolli ed interazioni come
quello raggiunto in stesura del CommunicationMagazine;
•
Ridefinire gli elementi per essere conformi alla nuova nomenclatura;
•
Definire meglio gli elementi in particolare:
◦ Definire regole base per gli elementi (es. nomi variabili etc...)
◦ Commentare in inglese tutti i passi fondamentali
◦ Togliere il codice superfluo
◦ Rendere il tutto parametrizzabile eliminando i pochi vincoli fissi ancora rimasti;
•
Estendere il testo base per il copyright e prevedere una qualche versione di licenza del
software tipo GPL etc.
Ad avviso del relatore è difficile proseguire senza prevedere un ampio lavoro di questo tipo
oltre che ad una completa ed affidabile riscrittura della documentazione (mancanza da ricercarsi nella lacuna di tempo alternativo allo sviluppo).
9.2 Apertura ad altri attori
Come visto nel paragrafo dedicato alla documentazione on line crocevia fondamentale della
prosecuzione del progetto è il reclutamento di manpower per il suo sviluppo:
9.2.1 Laureandi, Borsisti e Dottorandi.
Provenienti dalla facoltà;
9.2.2 Aziende
Aziende interessate (CISCO, TILab, … ) che diano supporto di personale e/o finanziario.
14 dicembre 2010
79
Sviluppi futuri
Versione 1
9.3 Consumo di Potenza
Un'altra possibile estensione delle funzionalità del modello è prevedere un meccanismo per
l'emulazione del consumo di potenza del nodo in termini sia di energia spesa in fase di sche duling e forwarding del traffico (nel piano di controllo) sia come energia spesa ai fini del funzionamento e switching dei dispositivi.
•
Obiettivi: estrapolare un grafico del consumo di potenza del nodo per una data architettura della matrice e dell'algoritmo di scheduling.
◦ Dal grafico dovrà risultare che in fase di traffico più intenso si ha un maggiore
consumo in termini di potenza istantanea e viceversa.
◦ Confrontando più architetture e più algoritmi di scheduling si suppone vengano
mostrate le differenze in termini di consumo di potenza al variare di questi parametri con il fine di determinare la scelta migliore in termini di consumo.
9.3.1 Consumo del Piano di Controllo
Per quanto riguarda il consumo in fase di elaborazione della destinazione del traffico si
può prevedere, come prima implementazione, una serie di contatori adibiti a tener conto
di:
•
Operazioni di lettura/scrittura in memoria (aspetto con impatto maggiore) inteso
come accesso alle Forwarding/Routing Table
•
Durata ed impiego di risorse dell'algoritmo di scheduling stesso.
9.3.2 Consumo del Piano di Inoltro
Per quanto riguarda il consumo in fase di inoltro del traffico si può prevedere, come
prima implementazione, di caratterizzare ogni componente ottico in due aspetti:
•
Consumo a riposo: il consumo di potenza del componente quando alimentato e a
“riposo”.
•
Consumo in fase “attiva”: il consumo di potenza del componente quando è attraversato da un segnale ottico/pacchetto (un contatore nel metodo simple action di
ogni elemento Click può darne un idea).
9.4 Test sulle performance
Uno degli aspetti da analizzare in particolare riguarda un test approfondito sulle performance
del router in termini di pacchetti processabili e durata del timeslot.
9.4.1 Funzionamento a “polling” delle schede di rete
Attualmente le schede del test-bed funzionano in modalità “interrupt”, per migliorare le
performance è noto che questo metodo di funzionamento è penalizzante.
Una soluzione potrebbe essere il settaggio delle schede di rete per un funzionamento a
“polling” in grado di gestire così una maggior frequenza di traffico.
80
11 novembre 2010
Sviluppi futuri
Versione 1
Per fare questo occorre indagare se è necessario impostare qualche parametro a livello
di s.o. e inoltre nella configurazione Click!.
9.5 Interfaccia utente
Forse l'aspetto più importante da implementare è la realizzazione di una interfaccia utente che
permetta di testare, controllare, modificare ed analizzare i risultati di varie configurazioni del
nodo emulato, variandone parametri, simulando traffico in arrivo e analizzandone la risposta.
•
Obiettivo: definire un interfaccia in grado di permettere all'utente di modificare i parametri della emulazione (tipo traffico, carico, dimensione, etc.) e del nodo (tipo di architettura, algoritmo di scheduling, etc.) e di eseguire l'emulazione e valutarne i risultati.
9.5.1 Soluzione Java
Una possibile implementazione prevede l'uso di una applicazione Java che permetta di
creare il file di configurazione Click, impostare i parametri per il traffico ed eseguire l'emulazione.
•
Pro: possibilità di disegnare in tempo reale il grafico del throughput o di altri parametri grazie alle librerie grafiche Java.
•
Contro: se si vuole rendere pubblico lo strumento, l'utente che lo scarica per uso
personale deve installare il click e java ed impostare alcuni parametri.
9.5.2 Soluzione PHP
Una differente soluzione prevede la creazione di una interfaccia web in linguaggio PHP
che permetta da remoto (da un qualsiasi browser) di impostare i parametri base di una
emulazione, richiederla al test-bed e visualizzarne i risultati:
•
Pro: mobilità estrema, da qualsiasi punto attraverso un browser lo strumento è
fruibile;
•
Contro: la visibilità dello strumento è opaca, limitata alle impostazioni settabili
via web dalla pagina php.
10 Guide per l'installazione
Di seguito sono riportate le procedure eseguite per il setup del test-bed in laboratorio ed in particolare:
•
Installazione del Sistema Operativo
•
Installazione Click!
•
Installazione Kernel ottimizzato per Click!
•
Installazione di NETCONF
•
Installazione di un “dissector” per Wireshark.
14 dicembre 2010
81
Guide per l'installazione
Versione 1
10.1 Installazione del Sistema Operativo
Per utilizzare le funzionalità del modello occorre disporre di una piattaforma software altamente personalizzabile e performante su cui testare il modello nelle sue prestazioni.
La nostra scelta è ricaduta sul sistema operativo Linux per il suo ampio utilizzo nell'ambiente
della ricerca e la sua alta configurabilità anche a livello di codice nativo.
10.1.1 Scelta della Distribuzione
Seppure Linux sia disponibile in diverse distribuzioni nel nostro test-bed si è scelta la
distribuzione Fedora release 12 (d'ora in poi Fedora Core 12 o FC12). Fedora a differenza di altre distribuzioni (come ubuntu) mantiene uno standard nella disposizione dei file
di configurazione, l'accesso come utente root e altre configurazioni avanzate che la prediligono rispetto a distribuzioni più user-friendly (anche se fedora lo è molto). Da ora in
poi in questo manuale faremo riferimento alla configurazione sotto questa distribuzione,
anche se in generale i comandi ed i settaggi saranno riproducibili sotto qualsiasi distro,
con minime variazioni.
10.1.2 Installazione
•
•
•
•
•
•
82
L'installazione di FC12 è eseguita nel nostro caso dal cd Net-Install il quale contiene
l'ambiente minimo necessario ad eseguire l'installazione e recupera i pacchetti della distribuzione (aggiornati) dal sito del progetto fedora.
N.B: E' altamente consigliato disporre di almeno 512 MB di RAM per eseguire l'installer in modalità grafica il che ci permette di selezionare poi i pacchetti a piacimento (si
farà riferimento a questa modalità da ora in poi).
Inserire il CD e riavviare;
Scegliere installare o sovrascrivere il S.O. dal menù di boot che appare una volta in esecuzione il net cd;
Eseguire a piacimento il controllo del cd per verificare la presenza di errori (da effettuare
una volta sola ...);
Una volta partita l'interfaccia grafica selezionare:
◦ Lingua: italiano
◦ Tastiera: italiano
◦ Nome macchina: sostituire localhost.localdomain con deisnetXX (dove XX è il numero
che si vuole assegnare alla macchina).
◦ Fuso orario: Roma
◦ Password di amministrazione (root): opticalrouter
A questo punto vengono analizzati i supporti per l'installazione (HDDs) per stabilire la struttura del sistema;
Scegliere di definire uno schema personalizzato per l'installazione e alla pagina successiva:
◦ Liberare tutto lo spazio (eliminare le partizioni) su HDD
◦ Creare il seguente schema:
▪ sda1 mount point: /
formattare: ext3*
dim: available
11 novembre 2010
Guide per l'installazione
Versione 1
▪
•
•
sda2 mount point: null formattare: swap
dim: 2 x RAM
Ovvero creare la partizione sda1 dove installerò il so formattata ext3 (* N.B: è obbligatorio farlo in ext3 e non ext4 per personalizzare poi il kernel in caso di necessità!!!) di
dimensione pari a tutta la dimensione del disco meno 2 volte la dimensione della RAM
(se 512MB di RAM allora dim disco – 1024MB).
Creare poi la partizione sda2 per lo spazio di swap formattata come swap di dimensione
paria a 2 volte la dimensione della RAM (se 512MB di RAM allora dim disco –
1024MB).
Lasciare invariate le impostazioni del boot loader;
Ora appare una schermata che mostra le interfacce di rete disponibili e chiede di impostarle
per raggiungere la sorgente dei pacchetti sul sito fedora;
◦ Selezionare l'interfaccia connessa ad internet (di solito eth0 ma non sempre!!!)
◦ Disabilitare DHCP
◦ Indirizzo IP: 192.168.10.XX
◦ Maschera: 255.255.255.0
◦
•
•
•
•
•
•
Gateway: 192.168.10.254
◦ DNS: 137.204.57.1
N.B: Se premendo avanti non si trovano i pacchetti o da errore probabilmente con i settaggi
non si raggiunge l'esterno (internet) oppure si è selezionata la scgeda di rete sbagliata. In tale
caso occorre (penso per un bug del sistema) riavviare l'installazione in quanto non è più possibile accedere alla scheda di settaggio della interfaccia di rete.
Alla schermata successiva verranno mostrati i pacchetti installati di default. Per il nostro test-bed possiamo eliminare tutto il superfluo come pacchetti per giochi grafica e ufficio mentre è importante inserire i pacchetti per lo sviluppo ed in particolare per le librerie.
Proseguendo si avvia l'installazione la cui durata dipende dal numero di pacchetti selezionati
dalla velocità di download da internet e dalle prestazioni dell'hardware;
Una volta terminata l'installazione riavviare;
Togliere il CD dal drive o selezionare avvio da HDD;
Nella schermata di benvenuto inserire i dati dell'utente:
◦ Nuovo utente: userXX
◦ Password: opticalrouter o userXX
Avvio del s.o.
Complimenti, ora FC12 è installato!!!
10.1.3 Ottimizzazione Iniziale
Come prima fase di ottimizzazione si può andare su Sistema->Preferenze->Applicazioni
di Avvio e rimuovere tutti i demoni non utilizzati.
10.1.4 Ottimizzazione Avanzata
•
Come fase di ottimizzazione avanzata possiamo operare diverse operazioni:
Eseguire in runlevel 3:
14 dicembre 2010
83
Guide per l'installazione
Versione 1
◦
•
•
•
Modificare il file “/etc/inittab” sostituendo “id:5:initdefault:” con id:3:initdefault:”
Disattivare i servizi in background:
Impostare il setting per le schede di rete:
◦ modificare /etc/sysconfig/network-scripts/ifcfg-ethX
▪ #<Device Name Description>
▪ DEVICE=eth<X>
▪ HWADDR=<MAC_ADDRESS>
▪ BOOTPROTO=static
▪ IPADDR=<IP_ADDRESS>
▪ NETMASK=<NETMASK>
▪ ONBOOT=yes
Impostare il login remoto di root senza password: (in dettaglio la procedura su http://linuxproblem.org/art_9.html)
◦ Andare sulla macchina da cui vogliamo collegarci al test-bed e digitare
▪
◦
◦
[root@deisnetXA ~] ssh-keygen -t rsa
Eseguire:
▪ [root@deisnetXA ~] ssh [email protected] mkdir -p .ssh
Infine
▪ [root@deisnetXA ~] cat .ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'
10.2 Installazione del Click! Modular Router
Il tool di cui faremo uso è il Click!
10.2.1 Installazione
Per ottenere una versione aggiornata del software è consigliabile ottenerlo mediante l'uso di un cvs (Concurrent Versioning System) come ad esempio git o cvs.
•
Loggarsi sulla macchina in questione (deisnetXX) come root;
•
Verificare la presenza del comando git nel sistema, altrimenti installare il cvs con
il comando:
◦ [root@deisnetXX ~] yum install git
•
Creare la cartella principale per l'installazione del Click riferita d'ora in poi nella
corrente relazione e nella documentazione ufficiale come CLICKDIR. Nel nostro caso andare su /home/userXX/ e creare una cartella di nome “click-git”:
◦ [root@deisnetXX ~]# cd /home/userXX/
◦ [root@deisnetXX userXX]# mkdir click-git
•
Eseguire il comando:
◦ [root@deisnetXX userXX]# git clone git://read.cs.ucla.edu/git/click CLICKDIR
84
11 novembre 2010
Guide per l'installazione
Versione 1
Una volta terminato di ottenere i sorgenti è possibile installare il software;
•
Entrare nella directory di installazione:
◦ [root@deisnetXX userXX]# cd click-git
•
Eseguire lo script di configurazione
◦ [root@deisnetXX click-git]# ./configure
▪ N.B: è possibile eseguire lo scirpt con alcuni parametri di configurazione
come
•
--enable-local: abilita la compilazione degli elementi nella cartella local (abilitata di default)
•
--enable-fixincludes: cerca di compilare il modulo per il kernel provando a pathcare gli header del kernel (soluzione di rimedio)
N.B: Lo script analizza il sistema alla ricerca dei pacchetti di sviluppo necessari alla
compilazione (gcc, gcc-c++, etc...) e alla versione del kernel per vedere se è possibile
compilare anche il driver per l'esecuzione come kernel-module delle configurazioni
Click!
Se appare:
configure: WARNING:
=========================================
Your Linux kernel header files cause errors when included by a C++ program,
so I won't try to compile the linuxmodule driver.
There are two common reasons for this error:
1. You have not applied the Linux kernel patch that comes with this
distribution. Apply the right patch and try again. See the INSTALL
file for more information.
2. Your Linux configuration enables some functionality that is not yet
covered by our patches. Turn off this functionality and try again,
or fix the error and tell us how you did it. See the config.log file
for more detailed information on the error.
=========================================
•
•
•
•
14 dicembre 2010
Compilare il codice:
◦ [root@deisnetXX click-git]# make
Installare il software nel sistema:
◦ [root@deisnetXX click-git]# make install
Se l'installazione ha generato solo il driver Userlevel troveremo il comando
“click” installato nel sistema se invece siamo su un sistema con kernel pathcabile
e l'installazione ha quindi generato il driver Kernelmodule troveremo anche il comando “click-install” installato nel sistema;
Per verificare se l'installazione è andata a buon fine si possono lanciare delle configurazioni di test ed in particolare:
◦ Userlevel:
▪ [root@deisnetXX click-git]# click conf/test.click
85
Guide per l'installazione
◦
Versione 1
Questo comando stampa a video 5 pacchetti con il tag “ok” davanti;
ok: 40 | 45000028 00000000 401177c3 01000001 02000002 13691369
Kernelmodule:
▪ [root@deisnetXX click-git]# click-install conf/test.click
ok: 40 | 45000028 00000000 401177c3 01000001 02000002 13691369
Questo comando (se l'installazione del driver kernel module è andata a buon
fine altrimenti il comando click-install non è presente nel sistema!!!) stampa
su un file (/proc/click/messages) 5 pacchetti con il tag “ok” davanti;
10.3 Installazione Interfaccia Grafica Clicky (Opzionale)
10.4 Installazione e Compilazione di un Kernel per
Click!
Come annunciato l'installazione del driver kernelmodule per l'esecuzione delle configurazioni
a livello kernel dipende dalla presenza o meno nel sistema di un kernel specifico e in grado di
interfacciarsi con il click.
N.B: E' possibile trovare una guida dettagliata nel file INSTALL in CLICKDIR.
10.4.1 Download dei sorgenti
Installare (file INSTALL sotto click-git/):
•
Archiviare il kernel linux attualmente funzionante per ripristinare il sistema in
caso di errore (non necessario nel nostro caso in quanto il core FC12 precompilato installato in fase di installazione è già salvato)
•
Ottenere un Kernel Vanilla:
◦ Scaricare un kernel vanilla da www.kernel.org ed in particolare una delle
versioni supportate dal Click! (We supply patches for Linux 2.4.18-32,
2.6.16.13, 2.6.19.2, and 2.6.24.7.). La scelta del kernel ricade sull'ultima versione su cui è disponibile la patch degli headers del software Click! Infatti,
solo con un kernel patchato è possibile eseguire una configurazione Click
come modulo kernel. Presa come riferimento la versione 1.8.0 di Click Modular Router è possibile verificare le versioni di kernel per cui esiste la patch
esaminando il sito di riferimento o la cartella CLICKDIR/etc/ al suo interno
si troveranno tanti file del tipo linux-2.X.X.X-patch che indicano le varie
patch per le rispettive versioni del kernel. La più recente versione del kernel
linux supportata al momento della stesura di questa relazione è la 2.6.24.7
che sarà quella in uso nel nostro caso e da ora in poi faremo riferimento a
tale release. La versione del kernel installato di default dalla distribuzione
Fedora è la più recente 2.6.31. Occorre dunque scaricare il kernel 2.6.24.7 ed
installarlo prima di proseguire. N.B: Una nota presente nel file recita “Get a
vanilla Linux kernel source distribution from www.kernel.org or one of its
mirrors. (Patched kernels, such as Red Hat kernels, usually do not work.)
Unpack this distribution into /usr/src/linux. (Save the old kernel source tree,
if you had one.)” occorre quindi scaricare la versione vanilla 2.6.24.7 del
86
11 novembre 2010
Guide per l'installazione
•
Versione 1
kernel (ovvero la versione 2.6.24.7 originale, non patchata e personalizzata
da parte del fornitore della distribuzione come Red Hat per Fedora) dal sito
www.kernel.org.
Scompattare i sorgenti in “/usr/src/kernels/”
10.4.2 Installazione delle Patch
Occorre ora installare le patch per il kernel scaricato:
•
Andare in:
◦ [root@deisnetXX / ]# cd /usr/src/linux/LINUXSRCDIR/
•
Eseguire:
◦ [root@deisnetXX LINUXSRCDIR ]# patch -p0 -b < CLICKDIR/etc/linuxVERSION-patch
N.B: Le patch sono disponibili per i kernel inclusi nel file INSTALL del click ovvero:
Kernel version
2.6.24.7
2.6.19.2
2.6.16.13
…
Patch
linux-2.6.24.7-patch
linux-2.6.19.2-patch
linux-2.6.16.13-patch
“The patch fixes syntax errors in several header files (the C++ compiler doesn't accept
them), adds several new functions, and changes the 'struct device' kernel data structure.
Therefore, you WILL need to recompile any kernel modules that touch 'struct device'.”
Nell'esperienza diretta dell'installazione DEIS-TLC si è dovuto provvedere a patchare
manualmente (anziché ricorre a path ufficiali che come da nota possono dare problemi)
due dei file sorgenti del kernel 2.6.24.7 per non incappare in errori durante il comando
di compilazione/make. In particolare le modifiche si riferiscono ai files:
•
/usr/src/kernels/linux-2.6.24.7/scripts/unifdef.c: in questo file è presente una funzione chiamata getline() che genera conflitto in fase di make in quanto un'altra
funzione ha lo stesso nome. Occore aprire il file con un editor di testo (gedit per
esempio) e sostituire tutte le istanze di 'getline' con la stringa 'get_line'.
•
/usr/src/kernels/linux-2.6.24.7/arch: rimpiazzare 'm' o 'q' con r. Questo perchè la
lettera da rimpiazzare indica un registro hardware non presente nella architettura.
10.4.3 Configurazione del Nuovo Kernel
Prima di compilare il kernel è necessario editare il suo file di configurazione per inserire
e deselezionare le opzioni che vogliamo includere o escludere dal nostro kerenel:
•
Eseguire:
◦ [root@deisnetXX LINUXSRCDIR ]# make menuconfig
•
Configure the new kernel. The Click patch does not add any configuration options, so you can start from your old configuration, or you can do the usual
'make menuconfig'. Use a minimal set of options.Click is not currently safe for
kernels with involuntary preemption. Make sure that the CONFIG_PREEMPT
option is off. CONFIG_PREEMPT_VOLUNTARY is OK. We welcome patches
to improve Click's preemption behavior.
14 dicembre 2010
87
Guide per l'installazione
Versione 1
Questo passo è molto delicato e dipende fondamentalmente dall'hardware sul quale vogliamo installare il s.o. A parte le raccomandazioni fornite come quella sulla preemption
nel nostro caso in particolare ma anche in generale è consigliabile settare il minor numero di opzioni possibili per ottenere le massime performance in fase di esecuzione, in
particolare ricordarsi di togliere:
•
SYS_DEPRECATED_FS
•
Tutte le periferiche inutilizzate come joystick, tablet, bluetooth etc.
•
Abilitare: Security Options -> Default Linux Capabilities (per poi poter ricompilare Wireshark!!!)
10.4.4 Compilazione ed Installazione
A questo punto è possibile compilare ed installare il kernel:
•
Eseguire il comando per la compilazione dei sorgenti (il parametro -j3 indica di
eseguire make con 3 thread concorrenti per aumentare la velocità di compilazione!):
◦ [root@deisnetXX LINUXSRCDIR ]# make -j3
•
Eseguire:
◦ [root@deisnetXX LINUXSRCDIR ]# make dep
•
Eseguire il comando per la creazione dell'immagine:
◦ [root@deisnetXX LINUXSRCDIR ]# make bzImage
•
Eseguire il comando per la compilazione dei moduli:
◦ [root@deisnetXX LINUXSRCDIR ]# make modules
•
Eseguire il comando per l'installazione dei moduli:
◦ [root@deisnetXX LINUXSRCDIR ]# make mudules_install
•
Eseguire il comando per l'installazione del kernel:
◦ [root@deisnetXX LINUXSRCDIR ]# make install
Il file INSTALL del Click! avverte che “You may get errors in one of these steps, such
as the 'make bzImage' step. This indicates that you turned on too many options when
configuring your kernel. Return to Step 5, turn off the option that seems to be causing a
problem, and try again.”
•
Riavvia la macchina con il nuovo kernel;
10.4.5 Installazione del Click! Con il nuovo Kernel
Ora siamo pronti a ricompilare ed installare il Click! Con il nuovo kernel e quindi con il
driver per l'esecuzione in kernelmodule.
•
Rieseguire configure:
•
dsf
8. Now you are ready to compile and install the Click module. Rerun
1.1.1.1.1
'./configure' to tell the system about your new kernel:
1.1.1.1.2
1.1.1.1.3
rm -f config.cache ; ./configure [OPTIONS]
▪
88
11 novembre 2010
Guide per l'installazione
Versione 1
1.1.1.1.4
1.1.1.1.5
If your Linux source is not in /usr/src/linux, give './configure'
the
1.1.1.1.6
'--with-linux=LINUXDIR' option. If your System.map file is
not in
1.1.1.1.7
LINUXDIR/System.map, give it the '--with-linuxmap=MAPFILE' option.
1.1.1.1.8
1.1.1.1.9
If './configure' reports "Your header files must be patched
before a
1.1.1.1.10
C++ program can include them", check that you applied the
patch in Step
1.1.1.1.11
3, and that you supplied the correct '--with-linux' option to
1.1.1.1.12
'./configure'.
1.1.1.1.13
1.1.1.1.14
9. Then build and install the click module, its companion
proclikefs
1.1.1.1.15
module, and the language tools:
1.1.1.1.16
1.1.1.1.17
gmake install
1.1.1.1.18
1.1.1.1.19
If you get errors while compiling the Linux kernel module
(the
1.1.1.1.20
'linuxmodule' directory), and the errors look like they are in
Linux
1.1.1.1.21
header files, you may have turned on too many options when
configuring
1.1.1.1.22
your kernel. Return to Step 5, turn off the option that seems to
be
1.1.1.1.23
causing a problem (for example, an error involving the
"atalk_iface *"
1.1.1.1.24
type means you should turn off AppleTalk via
CONFIG_ATALK), and try
1.1.1.1.25
again.
1.1.1.1.26
1.1.1.1.27
10. This will create two module object files,
'linuxmodule/click.ko' and
1.1.1.1.28
'linuxmodule/proclikefs.ko', and place them in
'CLICKPREFIX/lib'. (In
1.1.1.1.29
Linux 2.4 and prior versions, the files end in '.o'.) To install
these
1.1.1.1.30
modules and a router configuration, run
1.1.1.1.31
1.1.1.1.32
CLICKPREFIX/sbin/click-install
ROUTERCONFIGFILE
1.1.1.1.33
1.1.1.1.34
Alternatively you could use /sbin/insmod by hand; see
click.o(8)
1.1.1.1.35
14 dicembre 2010
89
Guide per l'installazione
Versione 1
10.5 Installazione di NETCONF (YUMA)
Per installare NETCONF (nella sua implementazione open source YUMA) è necessario riferirsi alle risorse su: http://www.netconfcentral.org/
10.5.1 Installazione dei sorgenti
Primo passo consiste nella installazione dei sorgenti YUMA, operazione che sotto Fedora è semplificata dall'esistenza della versione precompilata .rpm:
•
Scarica yuma-VERSION-DISTRO-PLATFORM.rpm da http://www.netconfcentral.org/ di seguito si farà riferimento alla versione per Fedora 12 (per altre distro
seguire le istruzioni sul sito web).
•
Controllo dipendenze: per installare YUMA è necessario avere installato nel sistema le librerie “libxml2” ed “ncurses”. Per controllare eseguire:
◦ root@localhost> rpm -q libxml ncurses
Se la query ritorna i due risultati nel sistema sono installate le librerie e posso passare al
punto successivo, altrimenti devo installarle con il comando:
◦ root@localhost> yum install libxml ncurses
•
Installo il pacchetto .rpm eseguando il comando:
◦ root@localhost> rpm -Uvh yuma-VERSION-fc12-PLATFORM.rpm
•
Edito il file /etc/ssh/sshd_config inserendovi le righe:
#Netconf-Subsystem
Port 22
Port 830
Subsystem netconf
/usr/sbin/netconf-subsystem
10.5.2 Avvio del Demone NETCONF (netconfd)
Una volta installato posso avviare il demone netconf
•
Avvio il demone netconf eseguendo:
◦
root@localhost> netconfd –log=/home/user69/netconfd_log –superuser=root &
Dove il primo parametro specifica il path del file di log del demone e il secondo indica
che se ci si autentica come root al demone superuser saranno possibili tutte le azioni.
•
N.B: Nel caso si dovesse riavviare il demone netconfd è necessario prima rimuovere il file “/tmp/ncxserver.sock”!!!
•
Riavvio ssh con il comando:
◦ root@localhost> /etc/rc.d/init.d/sshd restart
10.5.3 Avvio del Client NETCONF (yangcli)
Avvio il programma client per verificare la corretta installazione:
•
Eseguo yangcli:
◦ [root@deisnetXX / ]# yangcli
90
11 novembre 2010
Guide per l'installazione
•
•
Versione 1
Mi connetto al server netconf:
◦ yangcli> connect server=localhost user=root password=opticalrouter
Una volta connesso per prova posso lanciare il modulo toaster (Vedi esempio su
slides YUMA).
10.5.4 Realizzazione del Modulo “Optical Router”
Realizzazione del modulo “opticalrouter.yang”:
•
Creo una cartella in “/usr/share/yuma/modules” chiamandola “opticalrouter”
•
Creo all'interno di “/usr/share/yuma/modules/opticalrouter” il file “opticalrouter.yang”
•
Vado in “/usr/share/yuma/src” ed eseguo:
◦ [root@deisnetXX / ]# make_sil_dir opticalrouter
•
Questo crea una cartella con il nome del modulo, “/usr/share/yuma/src/opticalrouter”
•
Vado in “/usr/share/yuma/src/opticalrouter/src” e qui trovo i files:
◦ Makefile
◦ opticalrouter.c
◦ opticalrouter.h
•
Edito il file .c inserendovi il codice che mi interessa.
•
Una volta terminato il passo precedente, eseguo:
◦ [root@deisnetXX / ]# make
•
Ed infine:
◦ [root@deisnetXX / ]# make install
10.5.5 Caricamento del Modulo
Per caricare il modulo:
•
Una volta connessi eseguire:
◦ yangcli> load opticalrouter
•
Poi per avere la disponibilità dei comandi anche in locale (N.B. Il file .yang del
modulo deve essere presente anche sulla macchina che esegue il client yangcli)
eseguire:
◦ yangcli> mgrload opticalrouter
•
E' ora possibile eseguire i comandi definiti nel modulo:
◦ yangcli> add-address address=X.X.X.X
◦ yangcli> remove-address address=X.X.X.X
◦ yangcli> reduce-bandwidth channels=X
14 dicembre 2010
91
Guide per l'installazione
Versione 1
10.6 Installazione del plugin ForCES per Wireshark
Per visualizzare ed avere una testimonianza delle interazioni tra CE ed FE che si scambiano
informazioni e messaggi mediante un protocollo di recente costituzione è necessario disporre
di un tool avanzato per la cattura di tali informazioni.
Come già utilizzato ricorreremo a Wireshark il quale però non è provvisto di un “dissector”
(ovvero un analizzatore di protocollo) nativo per il protocollo ForCES e quindi occorrerà integrarlo con questa potenzialità.
10.6.1 Reperimento del codice dissector
Il codice in grado di analizzare il pacchetto è stato esposto in un lavoro chiamato “Method and Implementation of Building ForCES Protocol Dissector Based on Wireshark ”
ad opera di Feng Luo e Ligang Dong, Fenggen Jia del College of Information and Electronic Engineering della Zhejiang Gongshang University con sede in Hangzhou, P.R.China, 310018.
Scaricando il pacchetto completo di ethereal reso disponibile all'indirizzo http://netcom.zjgsu.edu.cn/netcom_download_eng.html è possibile reperire il file packet-forces.c
dentro la directory /epan/dissectors ed estrarlo per intergrarlo in wireshark.
10.6.2 Installazione di Wireshark
Come primo passo occorre installare l'ultima versione di Wireshark, quindi ottengo dal
sito i sorgenti.
•
Scompatto il file con il comando
10.6.3 Estensione per protocolli aggiuntivi
Per estendere Wireshark con un nuovo analizzatore di protocollo o “dissector” è possibile inserire questo come:
•
Componente Nativo nella cartella epan/dissectors
•
Plugin: maggiori informazioni sono disponibili nel file doc/README.plugins
10.6.4 Installazione del dissector ForCES “nativo”
Asfd
10.6.5 Installazione del dissector ForCES come “plugin”
•
•
•
•
92
N.B: Maggiori informazioni sono disponibili nel file:
WIRESHARKDIR/doc/README.plugins
Posizionarsi in “WIRESHARKDIR/plugins/”
Creare una sottocartella di nome “forces”
Copiare dentro “plugins/forces/” il file sorgente del dissector “packet-forces.c”:
Copiare dalla cartella “plugins/gryphon/” dentro “plugins/forces/” i files:
◦ AUTHORS
11 novembre 2010
Guide per l'installazione
Versione 1
◦
•
•
COPYING
◦ ChangeLog
◦ CmakeLists.txt
◦ Makefile.am
◦ Makefile.common
◦ Makefile.nmake
◦ moduleinfo.h
◦ moduleinfo.nmake
◦ plugin.rc.in
Seguire le istruzioni su WIRESHARKDIR/doc/README.plugins
Andare in WIRESHARKDIR/ ed eseguire
◦ [root@deisnetXX WIRESHARKDIR ]# autogen.sh
◦ [root@deisnetXX WIRESHARKDIR ]# ./configure –prefix=$
{HOME}/build/root/
◦
•
14 dicembre 2010
[root@deisnetXX WIRESHARKDIR ]# cd plugins
◦ [root@deisnetXX plugins ]# cd forces
◦ [root@deisnetXX forces ]# make
◦ [root@deisnetXX forces ]# make install
Ora si può lanciare wireshark eseguendo:
◦ [root@deisnetXX / ]# ./root/build/root/bin/wireshark
93