Elaborato Ferrandino Umberto N46000932

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Protocolli per Reti Mobili
IP Mobility e Multihoming nell'architettura Serval
Anno Accademico 2014/2015
Candidato:
Umberto Ferrandino
matr. N46/000932
IP Mobility e Multihoming nell'architettura Serval
Umberto Ferrandino
LATEX
2
Dedicato a chi, nei modi più svariati, ma sempre
con le migliori intenzioni, mi ha sostenuto
ed accompagnato in questo cammino.
3
Indice
Introduzione
5
1 Serval Architecture
6
1.1 Problematiche arontate . . .
1.2 Cos'è Serval ? . . . . . . . . .
1.2.1 La rete del futuro . . .
1.2.2 Il concetto di Servizio
1.3 Service Access Layer (SAL) .
1.3.1 Installazione del SAL .
1.3.2 Funzionalità di base .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
. 7
. 7
. 8
. 9
. 9
. 10
2 Ripensare lo stack TCP/IP
13
3 Astrazione dei servizi e dei ussi
15
2.1 Livello Applicazione . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Livello Trasporto . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Livello Rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Service Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Flow Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Inoltro dei pacchetti nello stack Serval
4.1
4.2
4.3
4.4
Active Socket . . . . . . . . . . . .
Forwarding e data plane . . . . . .
Service discovery e registration . .
Meccanismi di segnalazione eventi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
20
23
24
5 Prototipo dell'architettura
26
6 Casi di studio
27
7 Translator per compatibilità con host legacy
32
8 Dimostrazioni e test di funzionamento
34
9 Conclusioni
39
Bibliograa
40
5.1 Benchmark performance . . . . . . . . . . . . . . . . . . . . . 26
6.1 Web Service replicato con load balancing . . . . . . . . . . . . 27
6.2 Storage distribuito . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Migrazione ussi e macchine virtuali . . . . . . . . . . . . . . 30
8.1 Catturare pacchetti Serval con Wireshark . . . . . . . . . . . 35
8.2 Invio di un le . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Flow migration . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4
Introduzione
Fin dagli anni sessanta, la rete Internet, o ancora prima ARPANET, si è
evoluta seguendo quelle che erano le necessità cui tale invenzione poteva far
fronte. In pochi anni, il mondo intero ha assistito a quella che è probabilmente una delle più grandi rivoluzioni tecnologiche che la storia ricordi: da
un progetto partito per essere un esperimento militare, poi un modo per
interconnettere una quantità limitata di terminali, si è giunti ad interconnettere l'intero globo, rendendo pressoché irrisoria ogni distanza e possibile
ogni comunicazione. Come è ovvio che sia, anché tale evoluzione fosse
possibile, la rete ha dovuto subire una serie di cambiamenti e migliorie, con
l'introduzione di nuovi protocolli e funzionalità, al ne di restare al passo
con i tempi e garantire specici standard in materia di sicurezza, ecienza
e quant'altro.
Ad oggi, Internet va incontro ad ulteriori e più radicali cambiamenti. Infatti, nel corso degli anni, pur evolvendosi, la struttura di base della rete è
rimasta fedele allo stesso modello, il famoso Stack TCP/IP.
Con l'avvento del cosiddetto Web 2.0, Internet è diventato fortemente interattivo, grazie alla creazione delle piattaforme e delle applicazioni, che fanno
ormai parte, della vita di tutti i giorni di ognuno di noi. Tuttavia, tale processo, ha mostrato agli sviluppatori, agli ingegneri e a chiunque lavorasse
nell'ambito del networking, una serie di inadeguatezze cui la rete è soggetta,
specialmente in vista di quello che potrebbe essere il passo successivo nella
trasformazione di Internet e dunque, inevitabilmente, della vita di coloro che
ne usufruiscono. Per far fronte alle problematiche postesi, quali ad esempio il
crescente numero di dispositivi connessi alla rete (e di conseguenza al carico
di lavoro dei server), o alla sempre più frequente presenza nella rete di dispositivi mobili, molti provvedimenti, sono già stati messi in atto, altrettanti
invece, sono in cantiere o in attesa di essere standardizzati.
Ad ogni modo, così come si è passati da un web prevalentemente statico,
ad uno fortemente sociale, che basa le propria fondamenta sulla libertà di
espressione e di condivisione (appunto il Web 2.0 ), allo stesso modo, si viaggia verso un nuovo web, in cui ogni oggetto possa essere connesso alla
rete per sfruttarne le potenzialità, in cui l'utente possa vivere un'esperienza
virtuale completa grazie alla realtà aumentata e alla semantica dei contenuti
(solitamente indicato con Web 3.0 ).
Tale elaborato, si propone dunque, di illustrare uno dei progetti in via
di sviluppo più interessanti nell'ambito della mobilità e del multihoming,
ovvero: Serval Architecture.
5
1 Serval Architecture
1.1 Problematiche arontate
Un tempo, il web era popolato prevalentemente da dispositivi la cui mobilità era limitata ad un ambiente domestico o aziendale. La comunicazione
avveniva dunque, tra singoli terminali che dicilmente avevano necessità di
spostarsi. Oggigiorno, le cose sono profondamente cambiate. Infatti, sempre più spesso, un'altissima percentuale dei client che usufruiscono di un
determinato servizio, sono dispositivi mobili con diverse interfacce di comunicazione (ad esempio, Wi-Fi e 3G/4G ). Data la proliferazione degli abitanti
del web, i provider, e in generale tutte le realtà che forniscono servizi online
ad una copiosa utenza, hanno dovuto adeguare i propri organismi, passando
ad architetture che prevedono numerosi server dislocati in tutto il globo.
Tutto ciò ovviamente, si ripercuote sul funzionamento e sulla essibilità dei
servizi. Lo stack TCP/IP, risulta essere inadeguato per quelli che sono i
prossimi step nell'evoluzione della mobilità e della fruizione dei contenuti.
Ad esempio, diverse sono le problematiche legate allo spostamento del usso
di rete da un'interfaccia all'altra (si pensi ad esempio al fatto che, sul proprio
smartphone, non si possa intercambiare Wi-Fi e 3G/4G in modo trasparente
e senza interrompere le connessioni in corso), o all'utilizzo parallelo di più
interfacce per lo stesso scopo (ad esempio, uno streaming in cui il download
dei dati avviene in parallelo tra rete wireless e rete mobile). Per quanto
riguarda invece la gestione dei server, si rende necessario un load balancer,
in grado di distribuire nel miglior modo possibile il carico di lavoro tra i
server, evitandone il sovraccarico.
An application can run on multiple servers at dierent locations,
and can launch at or migrate to a new machine at any time. In
addition, user devices are often multi-homed (e.g., WiFi and 4G)
and mobile. In short, modern services operate under unprecedented multiplicity (in service replicas, host interfaces, and network
paths) and dynamism (due to replica failure and recovery, service
migration, and client mobility). Yet, multiplicity and dynamism
match poorly with today's host-centric TCP/IP-stack that binds
connections to xed attachment points with topology-dependent
addresses and conates service, ow, and network identiers.
This forces online services to rely on clumsy and restrictive techniques that manipulate the network layer and constrain how services are composed, managed, and controlled. For example, today's load balancers repurpose IP addresses to refer to a group of
(possibly changing) service instances; unfortunately, this requires
all client trac to traverse the load balancer.
Si veda [1, p. 1] per maggiori informazioni.
6
1.2 Cos'è Serval ?
Serval, è un progetto open source dell'università di Princeton, nato da
un'idea di Michael J.Freedman, professore associato della facoltà di In-
formatica. Come spiegato precedentemente, le problematiche cui va incontro
Internet, sono molteplici e rischiano di comprometterne un funzionamento
ottimale in futuro. Per tale motivo, molti sono i progetti nati al ne di
evitare che ciò accada. Serval è uno di questi: Freedman infatti, sostiene
che ad oggi, gli ingegneri per poter implementare talune funzionalità, debbano ricorrere ad una serie di hack piuttosto complessi, che non sarebbero
necessari risolvendo alla base le problematiche di cui sopra. Si veda [3].
Smart engineers are great at mastering complexity and hacking
around it. But with the current approach, everybody needs to
reinvent the wheel [...] Serval is something that will make things
easier to build and easier to manage without relying on these
hacks.
Oltre Freedman, lavorano a Serval, anche Erik Nordstrom, David Shue, Prem
Gopalan, Robert Kiefer, Matvey Arye, Steven Y.Ko e Jennifer Rexford. Il
progetto, è stato nanziato da: National Science Fundation, DARPA,
Oce of Naval Research e Cisco Systems. [4]
1.2.1 La rete del futuro
L'idea che sta alla base di Serval, vede l'utente, non più interessato al web
come mezzo per interconnettersi ad uno specico terminale nella rete, ma
piuttosto come tramite verso uno specico servizio. Si pensi ad esempio a
realtà quali Google, che mettono a disposizione una moltitudine di servizi
(Gmail, Maps, Drive etc.) dislocati su altrettanti server: un indirizzo IP, all'interno della rete, non può che rappresentare una specica macchina. Tale
approccio, che prevede l'utilizzo dei load balancers sopracitati, risulta dunque
fortemente limitativo in ambienti in cui, ogni funzionalità deve necessariamente essere dislocata su più server per far fronte al carico di lavoro. Inoltre,
tutto ciò, impone dei vincoli in termini di mobilità degli host, i quali, non
possono ad esempio migrare da una interfaccia all'altra, e dunque cambiare
il proprio indirizzo IP, senza che la fruizione del servizio venga interrotta.
Jennifer Rexfort, professoressa del dipartimento di Informatica, impegnata nello sviluppo di Serval, sostiene che (si veda [3]):
A lot of applications can be rewritten to hide the fact that you
break your connection and re-establish it, but it makes things unnecessarily complex and more expensive.
The Internet is increasingly a platform for connecting mobile
7
users with the cloud and the Internet was not designed to do that
[...] All the work that goes into shoehorning that into the old
network architecture is very dicult.
1.2.2 Il concetto di Servizio
Gli sviluppatori di Serval, hanno deciso di astrarre il concetto di servizio
al punto da far sì che, l'utente, piuttosto che connettersi ad un indirizzo
IP, e di conseguenza ad un terminale ben preciso, possa invece richiedere la
connessione ad uno specico servizio, senza avere diretta visibilità dell'IP.
Diamo allora una denizione più rigorosa di servizio [1, p. 1]:
Un servizio, corrisponde ad un gruppo di sistemi, che orono le stesse funzionalità, disaccoppiando il servizio stesso, dagli identicatori di rete. Le
applicazioni, possono instaurare una comunicazione senza badare ad indirizzo IP e porto.
In altre parole:
Service names identify who one communicates with, ow names
identify what communication context to use, while addresses tell
where to direct the communication.
8
1.3 Service Access Layer (SAL)
Il cuore di Serval, è il Service Access Layer (di qui in poi SAL), che viene
introdotto nello stack TCP/IP tra il livello rete e il livello trasporto.
Lo scopo del SAL, è quello di realizzare l'astrazione di cui sopra e di mappare l'identicatore del servizio all'indirizzo IP corrispondente, mediante una
service table, similmente a quel che avviene nel livello rete per le forwarding
table. Tutto ciò senza nessuna ulteriore modica allo stack TCP/IP e senza
che siano necessari ulteriori apparecchi di rete.
Figura 1: Lo stack TCP/IP con e senza Serval. [1, Fig. 1]
1.3.1 Installazione del SAL
Il SAL, viene integrato all'interno del sistema operativo, mediante un modulo del Kernel Linux e/o Android, (in futuro gli sviluppatori prevedono di
rendere il tutto compatibile con tutti i SO Unix-based nonché con i sistemi
Windows) che può essere caricato e rimosso a tempo d'esecuzione mediante
gli specici comandi da shell. Il codice sorgente necessario, può essere prelevato dall'apposita pagina del progetto su Github : Princeton-sns/Serval.
Ovviamente, prima che sia possibile caricare il modulo del SAL, sarà necessario generarlo compilando il codice sorgente scaricato, mediante la tipica
procedura certamente nota agli utilizzatori di un sistema operativo GNU/Linux.
Per ogni dubbio, è possibile consultare la documentazione online (Serval Wiki)
o i le README ed INSTALL all'interno del pacchetto contenente i sorgenti. Una volta caricato il modulo, sarà possibile far uso dei servizi messi a
9
disposizione da Serval ed avviare alcuni software di base (forniti all'interno
dell'archivio disponibile su Github ) per il testing delle funzionalità.
1.3.2 Funzionalità di base
Uno degli scopi principali di Serval è quello di migliorare la mobilità delle
connessioni (Mobility e Multihoming ), che nell'approccio attuale risulta essere ineciente. In particolare, tramite l'astrazione realizzata dal SAL, Serval fa in modo che, non avendo le applicazioni visibilità in tutto e per tutto
degli indirizzi IP, quest'ultimo possa variare senza interrompere il usso dati,
nel passare da una rete all'altra o nel cambiare interfaccia di connessione.
Figura 2: Mobility e multihoming. [2, Pag. 6]
Oltre che per la mobilità dei client, Serval, prevede anche delle migliorie che possano invece interessare gli Internet Provider e più in generale i
fornitori di servizi online. Attualmente, una architettura che prevede la distribuzione del carico di lavoro su più server, richiede l'utilizzo di terminali che
si occupino di gestire le connessioni in entrata per indirizzarle in modo intelligente ad uno dei server disponibili. Tale approccio, fa sì che i load balancer,
debbano gestire l'inoltro di tutti i pacchetti inviati dai client verso i server,
cosa che, evidentemente, accresce la complessità ed il costo del sistema complessivo. Un simile approccio viene inoltre utilizzato per la risoluzione dei
nomi tramite DNS, e di conseguenza presenta le stesse problematiche.
10
Figura 3: Approccio con load balancer. [2, Pag. 8]
Serval gestisce tali situazioni, in modo diverso e sicuramente più eciente, e lo fa tramite i cosiddétti service routers, dei terminali che si occupano di instaurare il collegamento al servizio su richiesta del client, mediante
un apposito pacchetto. Il traco successivamente generato, viaggia invece
direttamente tra gli host implicati nella comunicazione (dierentemente da
quando accade in presenza dei load balancer, che rischiano invece di essere
sovraccaricati). Michael J.Freedman, spiega infatti che (si veda [4]):
One can think of this as an overlay, but really, it means there is
some software running on machines that act as service routers
(much like DNS resolvers/nameservers or DHCP servers [...]
These are only 'on-path' for the rst packet of each ow, unlike
today's load balancers, which must be on-path for each packet.
Inne, altra interessante miglioria, che potrebbe interessare in particolar modo i servizi di Cloud riguarda la migrazione delle macchine virtuali.
Attualmente, qualora una organizzazione in possesso di diversi server, su
ognuno dei quali sono in funzione più VM, abbia necessità di trasferirne
una o più da un terminale ad un altro, dovrà necessariamente sospendere la
comunicazione con i client che stavano interfacciandosi con la macchina in
questione.
11
Figura 4: Migrazione VM tra diversi host. [2, Pag. 9]
Tale inconveniente, potrebbe essere evitato se fosse possibile migrare le
connessioni dei client implicati, verso altre VM. Ed è proprio in tal modo che
Serval conta di risolvere tale problematica, oltre che riuscendo a diminuire
il tempo di interruzione del servizio durante la migrazione della macchina.
12
2 Ripensare lo stack TCP/IP
Le problematiche dello stack TCP/IP odierno, derivano prevalentemente
dal fatto che, i concetti di indirizzo IP e porta, siano sovraccaricati dei più
svariati signicati. Dierentemente, Serval, separa in modo netto il servizio
dal usso dati corrispondente (relativo ad una specica socket ) e dall'indirizzo di rete (che identica l'interfaccia dell'host). Di seguito sono riportati, per
vari livelli dello stack, i cambiamenti che hanno luogo all'interno di quest'ultimi quando Serval è in funzione.
Per maggiori informazioni, si veda [1, p. 2].
2.1 Livello Applicazione
Ad oggi, il livello applicativo, presenta le seguenti limitazioni:
• Indirizzo IP e port number, identicano solo in modo implicito il nome
del servizio, che deve essere eventualmente risolto generando ulteriore
traco (ad esempio tramite DNS), prima che la connessione possa aver
luogo (early-binding ).
• Le applicazioni utilizzano meccanismi di caching per velocizzare la
risoluzione dei nomi, tuttavia, possono creare rallentamenti in caso
di fallimento.
• Ogni socket, può essere legata al più ad un unico, immodicabile,
indirizzo.
In presenza del SAL, la necessità, all'interno delle applicazioni, di implementare alcuni meccanismi di risoluzione e di ottimizzazione della gestione
del traco di rete, possono essere evitati o resi superui. In particolare, in
termini di livello applicativo, l'introduzione del SAL comporta le seguenti
migliorie:
• Grazie al concetto di servizio, attraverso il quale fa sì che l'IP sia
trasparente alle applicazioni, è possibile risolvere l'indirizzo di rete,
direttamente quando si instaura l'eettiva connessione tra gli host
(late-binding). Tale questione è trattata in modo più approfondito
nel paragrafo 4.1.
• In presenza di load balancer (ed eventualmente di NAT), la connes-
sione può essere stabilita mediante l'invio di uno specico pacchetto
(anycast-forwarded ), senza che il restante traco debba attraversare il
load balancer stesso.
13
2.2 Livello Trasporto
Lo stack TCP/IP, a livello trasporto, fa uso della classica quintupla di
elementi, formata da: IP mittente, porta mittente, IP destinatario, porta destinatario, protocollo. Tali informazioni, risultano necessarie per il
demultiplexing dei pacchetti. In conseguenza di ciò, accade che:
• L'IP non può cambiare senza che le connessioni in corso siano inter-
rotte;
• Le possibilità di mobilità e migrazione, sono pressoché nulle.
Ad oggi, esistono diverse proposte per quanto riguarda l'integrazione della mobilità e del multihoming in TCP, ma nessuna ricopre tutti i possibili
scenari in modo soddisfacente. Alcune soluzioni, prevedono che gli IP nella
quintupla sopracitata possano cambiare dinamicamente, altre sostituiscono
agli indirizzi altri identicatori, ma nessuna di queste soluzioni è in grado di
supportare, oltre che TCP, altri protocolli di livello trasporto.
Dierentemente, Serval, risolve il problema alla base, facendo sì che i protocolli di trasporto non si occupino del demultiplexing dei pacchetti, il quale
ha luogo invece nel SAL grazie agli identicatori di servizio (serviceID) e di
usso (owID). Così facendo, gli indirizzi di rete sono liberi di cambiare, e
poiché il controllo del usso dati è relegato al SAL, tale soluzione può essere
adottata con diversi protocolli di trasporto.
2.3 Livello Rete
Dal momento che il SAL è posizionato al di sopra del livello rete, l'inoltro
dei pacchetti, avviene così come previsto dal protocollo IP mediante una
gestione gerarchica degli indirizzi.
14
3 Astrazione dei servizi e dei ussi
3.1 Service Naming
Ogni servizio, è rappresentato da un nome di facile memorizzazione per gli
utenti, e da un identicatore, che viene invece utilizzato dai dispositivi di
rete e dai terminali, comunemente detto serviceID. Le istanze del servizio
corrispondente, si aspettano dunque di ricevere in ingresso connessioni per
quello specico identicatore, nascondendo ai client indirizzi e porti, garantendo dunque una certa essibilità.
Seguendo la schematizzazione vista su [1, p. 3.1], è possibile discutere le
seguenti caratteristiche:
•
Granularità: Il concetto di servizio, realizza un'astrazione tale da
•
Formato dell'identicatore: Di fondamentale importanza è la ques-
•
Sicurezza e registrazione: Dal punto di vista della sicurezza, Ser-
•
nascondere l'eettiva tipologia del sistema complessivo, ad esempio:
un service name può indierentemente rappresentare un singolo demone, un cluster di stampanti, un insieme di peer che distribuiscono
lo stesso le o un normale servizio online distribuito su più macchine.
In sostanza, la granularità del servizio è estranea ai client.
tione del naming. È necessario infatti, stabilire le dimensioni dei serviceID e decidere come questi debbano essere memorizzati. Gli sviluppatori di Serval, suggeriscono una soluzione che preveda un namespace di
256 bit, gestito eventualmente da autorità che si occupino della memorizzazione ed eventualmente di una suddivisione in blocchi, in base a
dei pressi rappresentativi di speciche entità. È possibile in tal modo, adoperare una risoluzione gerarchica dei servizi, specialmente per
quelle realtà che ne orono molteplici.
val, propone l'utilizzo di una bitstring alla ne del serviceID, ottenuta
mediante crittograa hash di una chiave pubblica e del presso, rappresentativi del servizio. Tale meccanismo, non richiede la presenza di
infrastrutture, ma soltanto una strategia per garantire che i serviceID
vengano appresi attraverso canali sicuri e che la registrazione stessa dei
servizi, avvenga mediante un sistema adabile di registrazione. Ad ogni modo, da questo punto di vista, Serval non impone alcuna politica
di gestione dei serviceID, lasciando libere le imprese di scegliere come
eettuare le registrazioni all'interno della propria rete. Tuttavia, va
specicato che tali misure di sicurezza, non bastano ad assicurare che
l'hoster del servizio sia autorizzato.
Memorizzazione dei nomi: Anche per quanto riguarda questo as-
petto, non vi è alcuna imposizione. Serval non si occupa di gestire
15
il mapping tra serviceID e service name, lasciando che sia l'utente a
decidere come associare ad un identicatore un nome che possa essere
facilmente memorizzato, mediante gli più svariati meccanismi (come
accade ad esempio per DNS).
3.2 Flow Naming
Serval fornisce un sistema di naming per il usso dati di una specica connessione, basato sul owID. Tramite tale identicatore, il SAL può eettuare
il demultiplexing dei pacchetti, senza aver bisogno della classica quintupla di
elementi di cui si è discusso nel paragrafo 3.2.
In denitiva, il serviceID e il owID rappresentano tutto ciò che è necessario per l'inoltro dei pacchetti. Tali informazioni, vengono trasportate
all'interno di uno specico header, posizionato tra quello del livello rete e
quello del livello trasporto, come da immagine.
Figura 5: Identicatori di Serval all'interno di un pacchetto (alcuni campi
sono stati omessi per una migliore leggibilità). [1, Fig. 2]
Possiamo quindi concludere che, come spiegato in [1, p. 3.2], Serval,
tramite i suoi identicativi, implementa:
•
Mobilità e multi-path: attraverso eventi che possano modicare
•
Inconsapevolezza del livello rete: i ussi dati sono identicati pur
•
Migrazione in presenza di NAT: un NAT consapevole della presenza del SAL, sostituisce l'indirizzo IP mittente, con l'IP pubblico
(come di consueto) e il owID, unica informazione necessaria a destinazione per l'identicazione del usso dati corrispondente. In questo
modo, può passare da una rete provvista di NAT all'altra, senza alcuna
preoccupazione.
l'interfaccia corrispondente ad un owID, o associando ad un'unica
interfaccia più ussi che attraversino percorsi diversi.
senza conoscere gli indirizzi IP corrispondenti, cosa che permette a
Serval, di supportare indierentemente IPv4 e IPv6.
16
•
•
Sicurezza: dal momento che i owID possono essere generati casual-
mente, un identicatore sucientemente lungo, dovrebbe servire a proteggere da eventuali malintenzionati. Tuttavia, un owID troppo lungo, potrebbe generare un overhead eccessivo: per tale motivo, Serval
adotta un owID di 32 bit più dei nonces che sono scambiati soltanto
durante il setup della connessione e durante eventuali migrazioni.
Port number non richiesto: il numero di porta, spesso identica
anche il protocollo utilizzato per il usso dati verso l'applicazione (si
pensi ad esempio al fatto che, il porto 80, è generalmente associato al
protocollo HTTP). Il owID, invece, non tiene in alcun modo memoria del protocollo utilizzato, che può essere eventualmente specicato
all'interno dell'apposito campo nel transport-header.
17
4 Inoltro dei pacchetti nello stack Serval
Vedremo, nei paragra successivi, come Serval gestisce l'inoltro e il demultiplexing dei pacchetti all'interno delle reti, mediante i seguenti approcci e
componenti:
• Scissione del control plane dal data plane ;
• Service-controller, una componente che si occupa della risoluzione dei
servizi, della gestione di particolari eventi, della comunicazione con gli
altri controller;
• Service table che realizzano il mapping tra serviceID ed indirizzi di
rete;
• Flow table che realizzano il mapping tra owID e socket;
• Meccanismi di comunicazione e segnalazione per la gestione di parti-
colari eventi;
• Active socket per l'interazione tra le applicazioni.
Figura 6: Stack Serval con le varie componenti che partecipano all'inoltro
e alla gestione del traco. [1, Fig. 3]
18
4.1 Active Socket
Le Active Socket, così come le socket BSD, su cui sono basate, vengono
utilizzate per il passaggio dei dati da e verso le applicazioni, realizzando
un'astrazione di un canale di comunicazione. Tali socket, si dierenziano da
quelle classiche, per via del fatto che, le funzioni normalmente utilizzate per
la gestione delle connessioni, hanno tra i parametri il serviceID, invece che
gli indirizzi IP e il porto. Mediante un meccanismo di segnalazione eventi (si
veda 4.4), Serval gestisce automaticamente la registrazione/deregistrazione
dei servizi, quando vengono eseguite speciche operazioni sulle socket.
Tipiche funzioni sono ad esempio:
•
bind(): associa un indirizzo e un porto ad una socket (nel caso di Ser-
•
close(): chiude la socket (causa una deregistrazione all'interno della
•
connect(): chiamata utilizzata dai client per connettersi ad una speci-
•
accept(): accetta la prima connessione in coda.
•
sendto(): invia i dati verso la specica destinazione.
val fa uso invece di un serviceID ), su cui ci si pone in ascolto (l'evento
generato da una chiamata alla funzione bind, causa una registrazione
all'interno della service table che viene noticata al service-controller ).
service table che viene noticata al service-controller ).
ca socket.
Figura 7: Dierenze d'utilizzo delle socket BSD classiche rispetto a quelle
modicate da Serval per il funzionamento tramite serviceID. [1, Tab. 1]
19
Le applicazioni che fanno uso di tali funzioni, di conseguenza, non hanno
visibilità dell'indirizzo di rete (dal momento che è il SAL ad occuparsi della
risoluzione del serviceID nell'indirizzo corrispondente). Questo, non solo fa
sì che gli IP possano cambiare liberamente, ma consente anche di eettuare il
late binding, ovvero di mappare l'identicatore del servizio sul corrispondente
indirizzo, solo all'atto di una connetct() o di una sendto().
4.2 Forwarding e data plane
L'instaurazione di una nuova connessione, mediante l'invio di uno specico
pacchetto, comporta che venga eettuata una ricerca all'interno della service table dello specico serviceID contenuto all'interno dell'header Serval,
mediante LPM (longest prex matching). Vari servizi infatti, possono avere
lo stesso presso, poiché appartenenti alla stessa entità. Come è possibile
notare guardando la Figura 6, la service table è composta da 3 campi, di cui
il campo Action, il quale può assumere 4 diversi valori:
•
FORWARD: viene utilizzato per l'inoltro di un pacchetto tramite il
•
DEMUX: è il ruolo presente nella service table del destinatario, per
livello rete ad uno o più indirizzi. Sia il mittente, sia eventuali hop
SAL intermedi o eventuali dispositivi di rete, presentano tuple all'interno della propria service table con ruolo impostato su FORWARD,
contribuendo all'invio del pacchetto verso la specica destinazione. Tali
hop, si comportano eettivamente come fossero dei service router.
poter smistare i pacchetti ricevuti verso la socket presso la quale la
specica applicazione è in ascolto per quel serviceID. Una chiamata alla funzione bind() (si veda 4.1) fa sì che all'interno della service table,
venga aggiunta una nuova voce con ruolo DEMUX per quel servizio,
viceversa, una chiamata alla funzione close(), causa l'eliminazione della stessa.
Figura 8: Aggiunta e rimozione di un ruolo DEMUX nella service
table per il servizio X. [2, Pag. 27-28]
20
•
DELAY: un pacchetto il cui serviceID trova nella service table in
sua corrispondenza una action DELAY, viene messo in coda ed una
notica viene inviata al service controller. Tale ruolo, viene ad esempio
utilizzato per una risoluzione ritardata (si veda 4.3).
•
DROP: utilizzato semplicemente per scartare i pacchetti per uno specico servizio.
Va specicato che, di default, ogni volta che un interfaccia si connette alla
rete, un ruolo FORWARD viene inserito nella service table, cui corrisponde
l'indirizzo di broadcast per l'interfaccia. Di seguito è illustrato un esempio
di come avviene l'inoltro di un pacchetto:
Figura 9: Inoltro di un pacchetto tra due terminali attraverso un service
router intermedio. [1, Fig. 4]
1. Un client stabilisce una connessione per il servizio X, per il quale è
presente nella service table un ruolo FORWARD verso il nodo b.
2. Il nodo intermedio, riceve il pacchetto; per lo specico serviceID ha
nella sua service table un ruolo FORWARD. Il pacchetto viene dunque
inoltrato verso il nodo g.
3. A destinazione, un ruolo DEMUX smista il pacchetto verso la socket
sulla quale l'applicazione è in ascolto.
Un esempio più complesso, è mostrato in Figura 10. Nell'esempio, un
client richiede di poter usufruire di un servizio X, disponibile su due diversi
server, allora il SAL assegna un owID ed un nonce generato casualmente
(per proteggere da eventuali attacchi) alla socket corrispondente, ed una
nuova tupla è aggiunta alla ow table.
21
Figura 10: Connessione ad un servizio X da parte del client a, tramite
inoltro del pacchetto SYN. I ruoli indicato con ' * ' sono quelli di default.
[1, Fig. 5]
1. Il SAL del client, cerca il serviceID all'interno della service table, ed
inoltra la richiesta verso il nodo b (indicato come indirizzo per il ruolo
FORWARD di default).
2. Il SR (service router ) b, trova all'interno della propria service table, un
ruolo FORWARD verso un ulteriore nodo, detto e. Reinoltra dunque
il pacchetto sovrascrivendo l'indirizzo destinazione.
3. Il forwarding del pacchetto continua ricorsivamente attraverso il nodo
e ed altri, nché non raggiunge il terminale g in ascolto sulla socket.
4. Il nodo g, crea quindi una nuova socket da utilizzare per l'invio della
risposta al pacchetto SYN ricevuto, aggiornando la propria ow table.
5. Il pacchetto SYN-ACK generato da g, contiene il suo indirizzo di rete,
il owID ed il nonce. Tale pacchetto, e tutti quelli che seguiranno,
saranno scambiati in modo diretto tra i due host, senza che debbano
attraversare i SR intermedi (b ed e). Va inoltre specicato, che il
demultiplexing dei pacchetti successivi potrà essere eettuato pur senza
l'invio del SAL header, essendo ormai noto il owID.
22
4.3 Service discovery e registration
Al ne di poter gestire situazioni dierenti, Serval, supporta diverse modalità
di registrazione e risoluzione dei servizi. Sono infatti i service controller a
gestire le service table, ed eventualmente a propagarle verso altri service
controller. È possibile distinguere diversi scenari:
•
Risoluzione e routing in larga scala (wide-area): ogni qual volta
•
Servizi nelle reti ad-hoc: essendo prive di infrastrutture di rete,
•
Risoluzione con lookup server (on demand): come spiegato nel
una nuova istanza di un servizio è disponibile, il service controller si occupa di propagare l'informazione agli altri controller, permettendo così
che il servizio possa essere raggiunto. Mediante l'utilizzo dei pressi,
organizzazioni che forniscono molteplici servizi, possono organizzare i
propri resolvers.
le informazioni sui servizi devono essere propagate tramite ooding.
Eventuali richieste vengono quindi inviate in broadcast, in attesa di
risposte da istanze del servizio richiesto. Lato server, all'atto di una
registrazione, il service controller può: inserire un ruolo DEMUX nella service table, propagare la registrazione agli altri controller (che
potranno quindi installare nelle proprie service table un ruolo FORWARD). Viceversa, all'atto di una deregistrazione.
paragrafo 4.2, uno dei possibili ruoli per una tupla all'interno della
service table, è DELAY. Tale ruolo, fa sì che i pacchetti corrispondenti
al servizio, vengano messi in coda, in attesa ad esempio che il service
controller si occupi della risoluzione. Una volta che tale risoluzione ha
avuto luogo, i DELAY corrispondenti possono essere sostituiti con ruoli
FORWARD per permettere l'inoltro dei pacchetti. Un approccio che
prevede simili meccanismi, è quello con lookup server : i client interessati, inoltrano il pacchetto SYN verso il server in questione, il quale
prima li mette in coda (DELAY) ed una volta eettuata la risoluzione,
li inoltra (FORWARD) verso il servizio destinazione.
23
4.4 Meccanismi di segnalazione eventi
I meccanismi di segnalazione, per la gestione di particolari eventi all'interno dello stack, sono fondamentali per garantire la essibilità e il dinamismo
messi a disposizione dal SAL, in particolar modo per una corretta gestione
della mobilità e della migrazione in presenza di più ussi dati. I protocolli
utilizzati in Serval, si dierenziano dai classici meccanismi solitamente adottati in TCP. Prima di tutto, i messaggi di controllo viaggiano separati dai
dati ed hanno un proprio sequence number, cosa che non accade ad esempio
nei più comuni MPTCP e TCP Migrate, i quali possono inviare messaggi
di controllo solo all'interno dei pacchetti dati, inoltre diversi protocolli di
trasporto sono supportati grazie alla presenza del SAL che gestisce i ussi
dati ad un livello più basso, e per lo stesso motivo migrazione e ussi multipli
sono ammissibili. Per maggiori informazioni si veda [1, p. 4.4].
Per meglio illustrare le possibilità messe a disposizione da Serval, in termini
di multihoming, multipath e migrazione, si faccia riferimento all'esempio riportato nella gura sottostante:
Figura 11: Esempio di comunicazione multipath (con possibilità di
migrazione) in presenza di terminali multihomed. [1, Fig. 6]
•
Multipath e multihoming: in presenza di diverse interfacce di rete,
possono essere instaurati più ussi dati lungo percorsi diversi. Si faccia
riferimento all'esempio di Figura 11: i due host, posseggono ambedue
una coppia di interfacce (a1 e a2 per il client Host C, a3 e a4 per
server Host S). Il primo usso viene instaurato quando il client richiede
di connettersi, usando ad esempio l'interfaccia a1 con owID fc1, che
lato server corrispondono all'interfaccia a3 con owID fs1. Ogni qual
volta viene inviato un pacchetto, all'interno del SAL extension header,
gli host possono indicare eventuali altre interfacce disponibili per la
connessione per dare la possibilità di creare più ussi dati. In questo
caso ad esempio, qualora Host S lo segnali ad Host C, quest'ultimo
potrebbe decidere di instaurare una nuova connessione tra le interfacce
a2 e a4.
24
•
Migrazione: essendo il livello trasporto ignaro della gestione del owID
da parte del SAL, è possibile migrare ussi dati da una interfaccia all'altra, su percorsi diversi o verso un altro indirizzo. Ovviamente, eventuali migrazioni possono inuire sulle prestazioni, e ridurre la banda a
disposizione per il trasferimento dati. Per questo motivo, il SAL può
noticare a livello trasporto l'avvio di una migrazione, così che questa
possa essere gestita in modo adeguato.
Facendo riferimento all'esempio di Figura 11, immaginiamo che improvvisamente l'interfaccia a3 del server smetta di funzionare. Per
non interrompere la connessione, il server può migrare il usso dati su
un'altra interfaccia, ad esempio a4. Tale migrazione avviene mediante
l'invio da parte del server, di un pacchetto di risincronizzazione detto RSYN, contenente i owID della connessione corrente (fc1 e fs1)
nonché l'indirizzo della nuova interfaccia (a4). Il client invia quindi un
RSYN-ACK per noticare al server il proprio assenso alla migrazione,
ed attende un ulteriore conferma da parte di quest'ultimo. La presenza di un sequence number all'interno dei pacchetti di sincronizzazione,
assicura che questa vada a buon ne anche nel caso in cui arrivino fuori
ordine (eventualità rara ma possibile).
25
5 Prototipo dell'architettura
Attraverso la prototipazione dell'architettura, gli sviluppatori, si sono resi
conto man mano di quelle che sono le potenzialità di Serval e i beneci che
può apportare in termini di dinamicità, prestazioni e quant'altro.
Attualmente, il prototipo disponibile, supporta: migrazione, SAL forwarding (comprensivo di service table con ruoli FORWARD e DEMUX,
risoluzione dei servizi e meccanismi di segnalazione) ed altre funzionalità.
Tuttavia, non è ancora possibile far uso del multi-path, che gli sviluppatori
progettano di aggiungere in futuro. Inoltre, la presenza del service controller
(che interagisce a sua volta con lo stack mediante una particolare socket),
permette una gestione dinamica delle service table in presenza delle chiamate
a funzioni bind(), connect() etc. Attualmente sono supportati i protocolli di
livello trasporto TCP e UDP. Per maggiori informazioni su come Serval sia
giunto all'architettura attuale attraverso le varie prototipazioni susseguitesi,
si veda [1, p. 5.1].
5.1 Benchmark performance
Gli sviluppatori di Serval, si sono preoccupati dell'esecuzione di alcuni test
che mostrassero in termini di throughput, pacchetti inviati, data loss, deviazione standard, le prestazioni di uno stack modicato dal SAL, rispetto ad
un classico TCP/IP.
Figura 12: Statistiche di confronto tra connessioni tramite stack TCP/IP
nativo e con SAL. [1, Tab. 2]
I dati mostrati, sono relativi a test di 10 secondi, eseguiti mediante tool
iperf su macchine con 2 CPU Intel E5620 @ 2.4GHz ed interfaccia GigE
con sistema operativo Ubuntu 11.04. Si consideri nel valutare i risultati
ottenuti da Serval, che alcune ottimizzazioni non sono ancora implementate.
Sono inoltre riportati nella tabella in Figura 12, i risultati in presenza di un
translator, ovvero una componente che si occupa del rendere possibile una
comunicazione tra host che implementano l'architettura Serval ed host che
fanno uso del classico stack TCP/IP (si veda il paragrafo 7).
26
La seconda parte della tabella in Figura 12, mostra i risultati ottenuti nell'inoltro di alcuni pacchetti con payload da 48 byte gestiti dal SAL,
rispetto ad altri inviati con l'approccio attuale previsto da IP. Gli sviluppatori condano di poter colmare il divario presente, specialmente in termini
di packet-rate, con le future ottimizzazioni.
6 Casi di studio
Per dimostrare l'ecacia di Serval in una serie di casi possibili, gli sviluppatori hanno realizzato dei test su sistemi realmente funzionanti, di svariati tipi.
Di seguito sono riportati i risultati ed una serie di considerazioni derivanti
da tali test, per diversi utilizzi di Serval in ambito server.
6.1 Web Service replicato con load balancing
In questo esperimento, si fa uso di un web-cluster con architettura Serval,
per mostrare i vantaggi che quest'ultimo può apportare all'interno di una
simile architettura. Supponiamo, che 4 client invino richieste verso il web
service, il quale gira su diverse istanze di un web server Mongoose. Tutti gli
host, sono connessi allo stesso switch di rete ToR GigE. Il load balancing,
è a carico di un singolo service router, che si occupa della risoluzione delle
richieste.
Per illustrare i risultati ottenuti, si faccia riferimento alla seguente immagine, considerando che ogni client richiede un le di 3MB su una nestra
di 20 richieste HTTP, al ne di saturare la banda a disposizione.
Figura 13: Relazione tra request rate e throughput in presenza di più
istanze di servizio. [1, Fig. 7]
27
Distinguiamo situazioni dierenti, in base alle istanze del servizio disponibili, in particolare:
•
0-60 secondi: due istante di servizio servono un totale di 80 richi-
•
60-120 secondi: dopo 60 secondi, due nuove istanze di servizio si
este al secondo (20 per client), raggiungendo un throughput di circa
1.8Gbps ;
registrano presso il service router, ed iniziano a servire richieste. Si
ottiene così un request rate di 160 req/s ed un throughput di circa
3.6Gbps ;
•
120-180 secondi: le prime due istanze di servizio, vengono stoppate.
•
180-240 secondi: una terza istanza viene avviata su uno dei server
Dunque, eseguono la deregistrazione e servono le ultime richieste pendenti. I risultati ottenuti in termini di request rate e throughput sono
comparabili a quelli ottenuti nei primi 60 secondi (avendo lo stesso
numero di istanze attive);
disponibili, ottenendo così migliori prestazioni (120 req/s e 2.7Gbps ).
Dall'esperimento si capisce dunque, come Serval sia in grado di gestire
senza l'uso di un costoso load balancer, un notevole carico di richieste riuscendo a distribuirle in modo adeguato sui server disponibili ed ottenendo
ottimi risultati in termini di throughput e request rate (tali da saturare la
banda disponibile). Il tutto, ricordando che il service router, non è altro che
un nodo coinvolto nella sola registrazione e risoluzione dei servizi (attraversato unicamente dal primo pacchetto di una connessione e non dall'interno
traco generato dal trasferimento dei dati).
6.2 Storage distribuito
Si illustra di seguito, l'impiego di Serval in un sistema di storage basato su
Memcached. Memcached fornisce un servizio di caching, basato sull'utilizzo
di alcune chiavi, tramite le quali un algoritmo di risoluzione, fa corrispondere
speciche partizioni distribuite su più server. Tramite una mappa, il client
può individuare il server contenente la partizione di interesse, ed inviare ad
esso le sue richieste. Tuttavia, la staticità di questo approccio, complica la
gestione dei server quando se ne vogliano aggiungere o sottrarre, o nel caso
in cui si voglia ripartizionare lo spazio.
Con Serval, il mapping delle partizione può avvenire dinamicamente: i
client possono inoltrare le proprie richieste al service router indicando un
serviceID con presso comune a Memcached, seguito dalla chiave del contenuto. Il mapping tra il serviceID e la partizione corrispondente alla chiave,
avviene mediante LPM nella service table. Le richieste possono quindi essere
28
inoltrate verso il server, il quale di qui in poi, comunicherà in modo diretto
col client. Nel caso in cui un nuovo server si registri alla rete, le partizioni
possono essere semplicemente riassegnate modicando la service table, tuttavia, con tale approccio, non avendo i client visibilità diretta del server (ma
solo del servizio) non possono aggregare richieste (si richiede che sia il service
router ad occuparsene).
L'immagine sottostante, riporta i risultati ottenuti per l'esperimento, in
presenza di 4 server ed un client (con un service router intermedio). Il client
ed il service router sono su macchine con le stesse speciche indicate per i
benchmark del paragrafo 5.1, mentre i server hanno le seguenti speciche:
due CPU AMD Opteron 2376 @ 2.4GHz quad-core con interfaccia GigE. Il
service router, assegna un totale di 16 partizioni (4 per ogni server), le cui
chiavi sono codicate sugli ultimi 4 bit del presso del serviceID.
Figura 14: Gestione Serval delle partizioni sotto Memcached, in presenza
di 4 server. [1, Fig. 8]
Anche in questo caso, come nell'esperimento precedente, distinguiamo
diverse situazioni in base ai server disponibili nei vari intervalli di tempo:
•
0-10 secondi: inizialmente, tutti i server sono in funzione;
•
10-20 secondi: dopo circa 10 secondi, un server viene rimosso (server
•
20-30 secondi: dopo 20 secondi, un altro server viene rimosso (server
3) ed il service router ridistribuisce le 4 partizioni del server rimosso
tra quelli rimanenti;
2) e le partizioni corrispondenti distribuite sui due server rimanenti;
29
•
30-40 secondi: il server 3, si registra nuovamente alla rete dopo
•
40-50 secondi: il server 4 si registra nuovamente, e si torna alla
circa 30 secondi, il carico dovuto alla gestione delle partizioni viene
ridistribuito;
situazione iniziale.
6.3 Migrazione ussi e macchine virtuali
Nel seguito, sono illustrati in breve, esperimenti che mostrano come Serval
possa gestire la migrazione di ussi dati su diverse interfacce, o di vere e
proprie macchine virtuali, situazione particolarmente di interesse ad esempio
per i servizi di cloud.
Nel primo caso, abbiamo un server (sul quale è lanciato iperf ) con due interfacce di rete GigE, che serve due client. Tali interfacce, possono garantire
una velocità a piena banda, di 1Gbps.
Figura 15: Miglioramenti in termini di throughput dovuti alla migrazione
del usso dati del secondo client sulla seconda interfaccia. [1, Fig. 9]
Inizialmente, i ussi di entrambi i client sono diretti verso un'unica interfaccia server, raggiungendo una velocità di circa 500Mbps (e dunque in
totale di 1Gbps). Dopo 6 secondi, il service controller segnala al SAL di voler
migrare uno dei ussi sulla seconda interfaccia. Trascorso un breve periodo,
necessario per l'assestamento della velocità di trasmissione, entrambi i client
ottengono una velocità pari a 1Gbps (2Gbps totali), raddoppiando dunque
il throughput rispetto alla situazione iniziale.
30
Un possibile uso della migrazione oerta da Serval, utile in particolar
modo a fornitori di servizi cloud, è quello in cui una macchina virtuale,
debba essere trasferita da un host all'altro senza una interruzione del usso
dati.
Figura 16: Flusso dati, in presenza di una migrazione. [1, Fig. 10]
Come l'immagine suggerisce, il usso dati subisce un lieve rallentamento
ed una breve interruzione, nel periodo in cui un nuovo indirizzo di rete viene
assegnato alla macchina virtuale, e mentre viene eettuata la risincronizzazione.
31
7 Translator per compatibilità con host legacy
L'integrazione di Serval all'interno dello stack TCP/IP, risulta essere piuttosto semplice, tuttavia, per ovvi motivi, è necessario garantire compatibilità
anche con host che presentano uno stack privo del SAL. Per questo motivo,
sono stati sviluppati dei translators, attraverso i quali è possibile risolvere tale
problematica. In particolar modo, il translator TCP-to-Serval, può tradurre
una normale connessione basata su TCP (senza SAL), in una connessione
adatta ad essere gestita da uno stack Serval. Un translator Serval-to-TCP,
eettua invece l'operazione inversa. [1, p. 7] - [5, p. 3.1]
•
TCP-to-Serval (lato client): per poter eettuare la traduzione, il
•
TCP-to-Serval (lato server): alcune grandi organizzazioni, che per-
translator (che in questo caso è un middlebox lato client) ha bisogno
di conoscere quale servizio il client desidera utilizzare, e di ricevere i
pacchetti relativi al usso dati associato. Il translator, agisce non molto
dierentemente da un recursive DNS, utilizzando i nomi dei domini
cui il client desidera connettersi, come nomi del servizio richiesto. Il
translator, mappa quindi tali nomi su un indirizzo IP privato.
mettono la fruizione di una molteplicità di servizi, potrebbero pensare
di implementare un proprio translator, presso i propri PoP (Points of
presence). Tale approccio, prevede una architettura siatta:
Figura 17: Comunicazione client-server mediante translator lato
server. Solo il primo pacchetto attraversa il service router, i restanti
solo il translator. [5, Fig. 2]
In una situazione simile, il client ovviamente non conosce il serviceID,
ma piuttosto risolve tramite DNS l'indirizzo IP di una specica macchina. Ogni server che permette l'utilizzo del servizio è associato ad un
IP pubblico e ad una porta. Tuttavia, l'IP che il client scopre, non
32
corrisponde ad una delle macchine del servizio, bensì al translator.
Quest'ultimo, riceve dunque tutto il traco generato dalle richieste
dei client, e tramite una tabella mappa l'IP e la porta richiesti dal
client sul corretto serviceID, come mostrato nell'immagine sottostante.
Figura 18: Tabella per il mapping di IP e porta sul corretto
serviceID. [5, Fig. 1]
Riconosciuto il serviceID corretto, il translator, invia una richiesta di
connessione mediante Serval, al service router della rete. Il service
router a sua volta, decide per quale server della rete stabilire la connessione. Una volta stabilita la connessione, i pacchetti successivi,
potranno essere trasferiti senza attraversare il service router, mentre
dovranno sempre essere gestiti dal translator, il quale mantiene una
connessione classica verso il client ed una basata su Serval, verso il
server che fornisce il servizio. Per le strategie di realizzazione di un
translator, si veda [5, p. 4].
•
Serval-to-TCP/UDP: un translator di questo tipo, funziona in modo
molto simile a quanto visto per il TCP-to-Serval.
È piuttosto interessante valutare la possibilità di utilizzare una coppia di
translator in serie, al ne di poter usufruire delle funzionalità messe a disposizione da uno stack Serval, ad esempio: si immagini un client privo di SAL,
che stabilisca una connessione verso una specica destinazione. I pacchetti
inviati, attraversano prima un translator TCP-to-Serval e poi un translator Serval-to-TCP, al ne di inoltrare a destinazione pacchetti mediante una
connessione legacy. Così facendo, pur essendo il client un dispositivo non
modicato, potrà usufruire dei vantaggi tipici dell'architettura Serval, grazie
alla presenza dei translator.
33
8 Dimostrazioni e test di funzionamento
Di seguito, sono riportati alcuni esempi e test dimostrativi eettuati, al ne
di mostrare il funzionamento di Serval in alcuni scenari d'uso comune. Tutte
le istruzioni riportare, fanno chiaramente riferimento a le generati tramite
il processo di compilazione, primo passo da eseguire, così come accennato
nel paragrafo 1.3.1 (si consiglia ad ogni modo di far riferimento alla pagina
Serval su Github e al relativo Wiki). I comandi vengono lanciati dall'interno della directory principale di Serval, comunemente chiamate servalmaster.
Serval, può essere avviato in due dierenti modalità: come modulo del
Kernel Linux, o in user-space. Tutti gli esempi riportati di seguito, sono
stati eseguiti lanciando Serval in user-space.
•
Avvio di Serval tramite caricamento del modulo nel Kernel:
# insmod ./src/stack/serval.ko
Per controllare che il modulo sia stato eettivamente caricato:
$ lsmod | grep serval
•
Avvio di Serval in user-space:
# ./src/stack/serval -i INTERFACCIA -d
Una lista delle interfacce disponibili si può ottenere lanciando ifcong.
L'opzione d, lancia Serval in background, come demone.
Serval fornisce anche un demone (il cui uso è opzionale), detto servd, utile
alla gestione degli eventi, poiché segnala registrazioni e deregistrazioni dei
servizi al service router di competenza. È possibile specicare alcune opzioni
per servd, creando il le /usr/local/etc/servd.conf.
Per lanciare il demone:
# ./src/servd/servd
L'opzione -rip può essere specicata per indicare esplicitamente l'IP del service router (che servd trova da solo qualora sia nella stessa sottorete, diversamente è necessario indicarlo in modo esplicito). Per maggiori informazioni,
si lanci servd -h.
34
Una volta avviato il demone, è possibile visualizzare service e ow table,
lanciando:
$ telnet 127.0.0.1 9999
Figura 19: Service e ow table, visualizzate tramite telnet.
Prima di iniziare, potrebbe essere utile aggiungere una entry d'esempio nella
service table per il serviceID 76568:
$ ./src/tools/serv service add 76568 IP_SERVER
8.1 Catturare pacchetti Serval con Wireshark
Di base, Wireshark, noto programma per l'analisi del traco di rete, non
è in grado di individuare all'interno dei pacchetti il SAL (e dunque header
ed estensioni realtive). Tuttavia, è possibile istruire Wireshark anché sia
in grado di individuare correttamente pacchetti Serval. Per farlo, è necessario un dissector. Un dissector non è altro che uno script, programmato in
LUA, contenente le direttive necessarie per la corretta decodica di talune
caratteristiche dei pacchetti nel traco di rete. Per maggiori informazioni,
si veda [6].
Un dissector attraverso il quale è possibile decodicare correttamente pacchetti Serval, è stato realizzato da Isaakidis Marios (misaakidis) nell'ambito
del suo progetto ServalDHT e distribuito sotto licenza GNU General Public License. Il le .lua, è disponibile tra i le del progetto sotto la directory:
serval/src/serval_wireshark_dissector.lua
Scaricato il le, è necessario istruire Wireshark anché ne faccia uso per
la decodica dei pacchetti. Wireshark, all'avvio, carica alcuni script in base
alle direttive che sono contenute nel le init.lua, dunque, per far uso del
dissector, si lancino si seguenti comandi:
35
# cp serval_wireshark_dissector.lua /usr/share/wireshark
# nano /usr/share/wireshark/init.lua
Inserire alla ne del le la direttiva:
dofile(DATA_DIR.."serval_wireshark_dissector.lua")
Wireshark, sarà adesso in grado di individuare il SAL. In alternativa,
si faccia uso di tshark (la versione a riga di comando di Wireshark). Il
comando da eseguire per catturare pacchetti Serval è il seguente:
$ tshark -i INTERFACCIA -X lua_script:serval_wireshark_dissector.lua
Come mostra la gura seguente, Wireshark individua correttamente il SAL.
Figura 20: Pacchetto Serval individuato da Wireshark.
36
8.2 Invio di un le
Serval, mette a disposizione una serie di semplici programmi di test, al ne
di vericare il corretto funzionamento di talune funzionalità. In questo esempio, verrà mostrato come, degli host Serval, possano scambiarsi un le
come se questo fosse fornito dal servizio.
Si noti che, qualora i due host si trovino in sottoreti diverse, sarà necessario
aggiungere nella service table, una entry che indichi presso quale indirizzo
raggiungere il servizio relativo al serviceID indicato.
Supponendo di voler inviare un le .jpg contenuto nella cartella Immagini di
nome dark_side.jpg, lato server si lanci:
$ ./src/test/tcp_server_user -s 76568 -f /home/user/Immagini/dark_side.jpg
Lato client invece, si può scaricare il le mediante il seguente comando:
$ ./src/test/tcp_client_user -s 76568 -f /home/user/Scrivania/serval_test.jpg
Figura 21: Invio di un le tramite stack Serval.
37
8.3 Flow migration
Tra i tool forniti insieme ai sorgenti di Serval, ce n'è uno attraverso il quale
è possibile migrare un usso dati da una interfaccia all'altra. Possiamo
distinguere diverse situazioni:
• Migrazione di un usso da un'interfaccia all'altra
$ ./src/tools/serv migrate flow flowID INT_DESTINAZIONE
• Migrazione di tutti i ussi associati ad una specica interfaccia;
$ ./src/tools/serv migrate interface INT_INIZIALE INT_DESTINAZIONE
• Migrazione di tutti i ussi associati ad un servizio.
$ ./src/tools/serv migrate service serviceID INT_DESTINAZIONE
La migrazione tra varie interfacce, avviene in modo simile a quanto discusso
per la Figura 11 nel paragrafo 4.
38
9 Conclusioni
Serval rappresenta senza dubbio, una delle proposte più interessanti per i
futuri sviluppi del web. Pur esistendo molteplici proposte, non del tutto
dissimili tra loro (si pensi ad esempio ad HIP, che pure adotta, almeno per
quanto riguarda lo stack, un livello simile al SAL), Serval ha il grande punto
di forza di non richiedere particolari modiche né dal punto di vista delle
infrastrutture di rete né da parte degli stessi host, incrementando notevolmente essibilità e dinamismo del sistema complessivo. È chiaro che essendo
un progetto ancora prevalentemente prototipale e mancante di talune ottimizzazioni, possa non soddisfare tutti gli standard in materia di ecienza
e di sicurezza. Ad ogni modo, solo attraverso lo sviluppo e il testing dell'architettura si potrà capire quali siano le reali potenzialità, specialmente
all'interno di scenari reali di utilizzo dei servizi, e se eettivamente Serval,
così com'è, rappresenti una valida alternativa all'approccio attuale.
Quel che è certo, è che l'idea di introdurre un maggiore livello d'astrazione
mediante il concetto di servizio, nascondendo quindi alle applicazioni gli indirizzi di rete, ben si riette sull'idea che l'utente ha per `far uso di un servizio
online`, cosa che certamente va a vantaggio dello sviluppo, e potrebbe rappresentare in linea di principio un buon punto di partenza per i futuri sviluppi
nell'ambito del networking.
39
Riferimenti bibliograci
[1] Erik Nordstrom, David Shue, Prem Gopalan, Robert Kiefer, Matvey
Arye, Steven Y.Ko, Jennifer Rexford, Michael J.Freedman (2012),
Serval: An End-Host Stack for Service-Centric Networking,
http://www.serval-arch.org/docs/serval-nsdi12.pdf
[2] Erik Nordstrom, David Shue, Prem Gopalan, Robert Kiefer, Matvey
Arye, Steven Y.Ko, Jennifer Rexford, Michael J.Freedman (2012),
Serval: An End-Host Stack for Service-Centric Networking,
http://www.serval-arch.org/docs/serval-nsdi12-slides.pdf
[3] J.Sullivan (2012), Upgrading the Internet for the mobile age,
http://www.princeton.edu/main/news/archive/S34/37/42E76/
[4] Bob Brown - NetworkWorld (2012), Serval: Princeton researchers tout
Layer 3.5 Internet upgrade,
http://www.networkworld.com/article/2190266/lan-wan/
serval--princeton-researchers-tout--layer-3-5--internet-upgrade.
html
[5] B. Podmayersky (Princeton CS, June 2011), An incremental deployment
strategy for Serval, Technical Report TR-903-11.
ftp://ftp.cs.princeton.edu/reports/2011/903.pdf
[6] Wireshark Wiki, Lua programming language for writing of Wireshark
dissector, http://wiki.wireshark.org/Lua
40

Download Report