Il software che implementa i SIP UA coinvolti nella segnalazione è stato chiamato “RESUA – RDF-enabled SIP User Agent”. Questo software è interamente basato su PJSIP4, che fornisce uno stack SIP lato client molto completo.
RESUA è stato sviluppato per essere un SIP UA semplice ma capace di inviare messaggi con body di tipo multipart. Esso ha due modalità di funzionamento. In mo- dalità “client”, può essere usato per iniziare una sessione SIP con un SIP UA remoto, trasmettendo un messaggio INVITE contenente sia la descrizione delle risorse di re- te, che quella di risorse applicative. Invece in modalità “server” il software rimane in ascolto aspettando richieste INVITE; alla ricezione di un INVITE, esso risponde con un messaggio di risposta “183 Session Progress” contenente una descrizione di risorse di rete, infine risponde con “200 OK”, stabilendo la sessione tra i SIP UA.
Questo software non implementa alcuna logica applicativa, i contenuti dei messag- gi SIP vengono ricavati da opportuni file. Lo scopo di RESUA è unicamente quello di permettere il test dell’architettura proposta.
Validazione sperimentale
I
n questo capitolo viene introdotto il testbed sperimentale usato per la vali-dazione dell’architettura proposta in questa tesi, quindi viene descritto l’e- sperimento condotto su tale testbed. L’esperimento ha il duplice obiettivo di verificare il funzionamento basilare dell’architettura e di valutare l’impatto della nuova segnalazione sui tempi di segnalazione complessivi.6.1
Testbed
L’infrastruttura di prova è composta dai seguenti componenti hardware:
• Service Plane SOON: comprende 3 mini-computer equipaggiati con sistema operativo Linux (kernel 2.6) sui quali è eseguita un’istanza del software DSE. Il DSExcontrolla il router di bordo (edge router) ERx(x = 1, 2, 3) attraverso diretti-
ve NETCONF[25]. Ogni mini-computer dispone di due interfacce Fast Ethernet, una viene utilizzata per la comunicazione con il router associato, mentre all’al- tra è assegnato un indirizzo pubblico per poter ricevere richieste di servizio da applicazioni esterne (modulo NET-M, in questo caso).
• Rete di trasporto: è composta da sei router IP/MPLS Juniper™ connessi fra loro come mostrato in figura 10. I router ER1, ER2 ed ER3 sono configurati per
essere router di confine, mentre i router CR sono configurati come router interni (core). Tutti e sei i router dispongono di interfacce Fast Ethernet e supportano le funzionalità MPLS, OSPF e RSVP.
Figura 10. Testbed sperimentale
A DSE3 è associato un modulo AO-M, il quale ricopre il ruolo di SCF e gestisce la
segnalazione fra gli utenti, nonché la riservazione delle risorse di rete.
I SIP User Agent UAAe UABrappresentano le applicazioni utenti della rete e sono
due istanze del software RESUA, la prima in modalità “client” e la seconda in modalità “server”. La segnalazione SIP tra i due UA non è diretta, ma passa attraverso il proxy determinato dal modulo SIP-M.
6.2
Test
Al fine di fornire una validazione dell’architettura proposta, è stato condotto un test di verifica sul testbed descritto in precedenza. L’esperimento è consistito nella creazione di una sessione di comunicazione tra le due applicazioni.
Nello scenario simulato, l’applicazione utente associata a UAAintende fruire di un
certo contenuto multimediale (es. un film in alta definizione) presente all’interno dello streaming server cui è associato UAB. Per raggiungere il suo obiettivo l’applicazione
utente, oltre a richiedere al server la risorsa applicativa, richiede al Service Stratum del- la rete, in maniera esplicita, le risorse di rete di cui necessita, con ben precisi parametri di qualità come bitrate e classe di traffico.
Figura 11. Scambio di messaggi durante il test
Il modulo SIP-M incorpora le funzionalità di proxy e registrar server, pertanto de- termina l’esistenza di un dominio SIP. In questo caso si assume che UAAe UABsiano
stati precedentemente registrati e autenticati presso tale dominio.
6.2.1
Descrizione
L’esecuzione del test ha dato vita allo scambio di messaggi illustrato in figura 11, rico- struito grazie al software di cattura Wireshark1. Con riferimento a tale figura, UA
Adà
inizio alla segnalazione trasmettendo al modulo SIP-M un messaggio SIP di richiesta di tipo INVITE. Questo messaggio è in formato multipart e al suo interno sono presen- ti due diversi contenuti: il descrittore delle risorse applicative e quello delle risorse di rete. La descrizione delle risorse applicative in questo caso contiene il titolo del film, l’indirizzo per la ricezione dei dati, i codec supportati, ecc.; tuttavia questo aspetto è al di là degli scopi di questa tesi, in quanto il funzionamento dell’architettura non ne è influenzato. La descrizione delle risorse di rete è in formato NRDL e rappresenta
i requisiti di connettività dell’applicazione utente. Essa specifica la connessione che si intende stabilire e i relativi parametri di qualità (in questo caso bitrate e classe di traffico): <? xml v e r s i o n = " 1 . 0 " e n c o d i n g =" utf -8"? > < rdf : RDF x m l n s : rdf =" ht tp :// www . w3 . org / 1 9 9 9 / 0 2 / 2 2 - rdf - syntax - ns #" x m l n s : nr dl =" h ttp :// d e i s n e t . d eis . u n i b o . it / n rdl / nrdl - syntax - ns #" > <! - - R i c h i e d e n t e - - > < n rdl : S I P D e v i c e rdf : a b o u t =" sip : c l i e n t @ e x a m p l e . net "/ > <! - - B i t r a t e r i c h i e s t a - - > < n rdl : B a n d w i d t h rdf : a b o u t ="# bw " > < n rdl : b a n d w i d t h V a l u e > 2 0 0 0 0 0 0 0 < / nrd l : b a n d w i d t h V a l u e > </ nrd l : B a n d w i d t h > <! - - C l a s s e di t r a f f i c o r i c h i e s t a - - > < n rdl : T r a f f i c C l a s s rdf : a b o u t ="# tc " > < n rdl : t r a f f i c C l a s s V a l u e > S t r e a m i n g </ n rdl : t r a f f i c C l a s s V a l u e > </ nrd l : T r a f f i c C l a s s > <! - - I n d i r i z z o del s e r v e r - - > < n rdl : E n d p o i n t rdf : a b o u t ="# s e r v e r " > < n rdl : ipv4 > 1 0 . 2 0 . 1 0 . 2 < / n rdl : ipv4 > </ nrd l : End poi nt > <! - - I n d i r i z z o del c l i e n t - - > < n rdl : E n d p o i n t rdf : a b o u t ="# c l i e n t " > < n rdl : ipv4 > 1 0 . 2 0 . 1 2 . 2 < / n rdl : ipv4 > </ nrd l : End poi nt > <! - - C o n n e s s i o n e : i da ti v a n n o dal s e r v e r al c l i e n t - - > < n rdl : C o n n e c t i o n rdf : a b o u t ="# con n " > < n rdl : s o u r c e rdf : r e s o u r c e ="# s e r v e r "/ > < n rdl : d e s t i n a t i o n rdf : r e s o u r c e ="# c l i e n t "/ > < n rdl : h a s B a n d w i d t h rdf : r e s o u r c e ="# bw "/ > < n rdl : h a s T r a f f i c C l a s s rdf : r e s o u r c e ="# tc "/ >
</ nrd l : C o n n e c t i o n >
<! - - S e s s i o n e c o m p r e n d e n t e un ’ u n i c a c o n n e s s i o n e - - > < n rdl : S e s s i o n rdf : a b o u t ="# s e s s i o n " >
< n rdl : name > V i d e o S t r e a m i n g session </ nrd l : name > < n rdl : h a s C o n n e c t i o n rdf : r e s o u r c e ="# c onn "/ > </ nrd l : Session >
</ rdf : RDF >
Il modulo SIP-M, in quanto proxy, trasmette ad UAAla risposta temporanea “100
Trying”, indicante che il messaggio è stato correttamente ricevuto e interpretato. Su- bito dopo, tale modulo estrae il contenuto NRDL dal messaggio e lo invia al modu- lo NET-M. Quest’ultimo trasmette la richiesta di servizio, debitamente derivata dal documento NRDL, a DSE3.
A questo punto ha inizio la segnalazione interna alla rete SOON. Ricevuta la ri- chiesta di servizio, DSE3 risale agli edge router coinvolti nella comunicazione (ER1
ed ER2) e ai DSE che li controllano (DSE1 e DSE2), quindi verifica la disponibilità
di risorse di rete (ovvero i 20 Mbit/s di banda richiesti) al router ER2, in particolare,
all’interfaccia verso ER1, in quanto la richiesta di servizio riguarda i dati che da UA2
fluiscono in direzione di UA1. Questa verifica ha luogo attraverso una precisa richiesta
di disponibilità di risorse a DSE2. Una volta verificata la disponibilità di risorse, DSE3
invia a DSE1e DSE2una richiesta di “connection set-up”, ovvero di configurazione dei
rispettivi router di bordo, al fine di stabilire la riservazione di una precisa quantità di banda (20 Mbit/s) e in una precisa classe di traffico, per i dati che vanno dall’indirizzo del server verso l’indirizzo del client.
Conclusasi la segnalazione interna del Service Plane SOON, il modulo NET-M riceve la risposta affermativa da DSE3, che indica che la riservazione delle risorse di
rete è andata a buon fine, così aggiorna il documento NRDL di richiesta con lo stato di riservazione delle risorse di rete (proprietà answer) e lo trasferisce al modulo SIP-M:
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g =" utf -8"? > < rdf : RDF ... <! - - B i t r a t e r i c h i e s t a - - > < n rdl : B a n d w i d t h rdf : a b o u t ="# bw " > < n rdl : b a n d w i d t h V a l u e > 2 0 0 0 0 0 0 0 < / nrd l : b a n d w i d t h V a l u e >
< n rdl : answer > Allowed </ nr dl : answer > </ nrd l : B a n d w i d t h > <! - - C l a s s e di t r a f f i c o r i c h i e s t a - - > < n rdl : T r a f f i c C l a s s rdf : a b o u t ="# tc " > < n rdl : t r a f f i c C l a s s V a l u e > S t r e a m i n g </ n rdl : t r a f f i c C l a s s V a l u e >
< n rdl : answer > Allowed </ nr dl : answer > </ nrd l : T r a f f i c C l a s s >
... </ rdf : RDF >
Il modulo SIP-M sostituisce il documento NRDL iniziale con quello aggiornato e lo inoltra a UAB. Questo risponde con un messaggio SIP “200 OK”, infatti nella
simulazione di video streamig il server non ha requisiti di connettività diversi da quelli che sono già soddisfatti per il client. Il messaggio di risposta viene inoltrato senza modifiche al client, il quale risponde con un messaggio di ACK, dando così vita alla sessione di comunicazione. In questo istante, in uno scenario reale, inizierebbe lo stream del contenuto multimediale.
6.2.2
Risultati
Dal test eseguito possono essere ricavati due risultati. Il primo è rappresentato dal- la corretta creazione del canale di comunicazione richiesto fra i router ER1 ed ER2.
Questo si evince dal file di configurazione di ER2dopo la riservazione delle risorse:
s c h e d u l e r s {
EF - S c h e d u l e r { ...
}
AS - S c h e d u l e r {
tr ans mit - rat e 2 0 9 7 1 5 2 0 e x a c t ; p r i o r i t y h igh ; } BE - S c h e d u l e r { ... } }
Quello mostrato è un estratto del file di configurazione di ER2, in JUNOScript,
relativo all’interfaccia di rete diretta verso la rete core. In esso è mostrata l’effettiva configurazione dello scheduler associato al traffico Assured Forwarding[26] ad alta priorità, per un tasso di trasmissione di circa 20 Mbit/s, a seguito della richiesta di servizio da parte del modulo NET-M. La velocità di trasmissione è in realtà impostata ad un valore di poco superiore a 20 Mbit/s per tollerare l’overhead introdotto all’interno della rete di trasporto.
Il secondo risultato riguarda il tempo relativo alla segnalazione extra introdotta dall’architettura proposta. A questo proposito il grafico di figura 12 rappresenta (non in scala) gli intervalli temporali più rilevanti durante la segnalazione. Si può osservare come il tempo di segnalazione interno SOON (in cui il tempo di configurazione dei router è largamente predominante) sia di un ordine di grandezza maggiore rispetto al ritardo introdotto dalla nuova segnalazione.
Conclusioni
Q
uesta tesi ha proposto un’architettura di rete basata sul concetto di applica-tion-aware networking. Alle applicazioni è data la possibilità di richiedere direttamente le risorse di rete di cui necessitano, tramite l’uso di un linguag- gio generale e di alto livello che permette loro di astrarre completamente rispetto agli aspetti tecnologici e topologici relativi alle infrastrutture di accesso e di trasporto usate. Inoltre, lo sfruttamento del protocollo SIP dona all’architettura proposta una struttura di segnalazione robusta e meccanismi di supporto nelle fasi di pubblicazione e scoperta delle risorse di tipo applicativo.È stato mostrato come l’architettura presentata in questo lavoro trovi corrisponden- za con le linee guida ITU-T per le reti di nuova generazione (NGN).
Sono state presentate le implementazioni dell’alfabeto NRDL e dei moduli soft- ware fondamentali per una prima validazione dell’architettura da un punto di vista funzionale. Validazione che è stata eseguita sfruttando una particolare infrastruttura di rete, la rete SOON. Nonostante si riferiscano ad uno scenario estremamente limitato, i risultati del test permettono di trarre alcune conclusioni riguardo l’impatto dell’intro- duzione della nuova segnalazione all’interno di una infrastruttura di rete esistente. È possibile infatti affermare che le prestazioni globali, in termini temporali, restano per lo più invariate, in quanto il tempo di configurazione dei dispositivi di rete continua a rappresentare il maggior fattore di ritardo.
Alla luce di questo tipo di risultati è auspicabile un’estensione del lavoro svol- to in questa tesi, che renda il moduo NET-M a sua volta modulare. Così facendo, l’architettura presentata potrà essere applicata a differenti reti di trasporto.
File di configurazione di OpenSIPS
# # $Id : o p e n s i p s . cfg 442 3 2008 -06 -27 1 0 : 2 5 : 0 1 Z h e n n i n g w $ # ... l o a d m o d u l e " acc . so " # - - - e n a b l e n e t r e s m o d u l e - - - - - l o a d m o d u l e " n e t r e s . so " ... # - - - u s r l o c p a r a m s - - - - - m o d p a r a m (" u s r l o c " , " d b _ m o d e " , 0) # - - - n e t r e s p a r a m s - - - - - m o d p a r a m (" n e t r e s " , " n e t m _ i p v 4 " , " 1 2 7 . 1 . 2 . 3 " ) m o d p a r a m (" n e t r e s " , " n e t m _ p o r t " , 1 8 4 6 ) m o d p a r a m (" n e t r e s " , " n e t m _ r e s p _ t i m e o u t " , -1) # # # # # # # R o u t i n g L o g i c # # # # # # # # # m ain r e q u e s t r o u t i n g l o g i cr o u t e {
if (! m f _ p r o c e s s _ m a x f w d _ h e a d e r ( " 1 0 " ) ) { s l _ s e n d _ r e p l y ("4 83" ," Too Man y Hop s ") ; ex it ; } # - - - n e t r e s o p e r a t i o n on I N V I T E - - - - - if ( i s _ m e t h o d (" I N V I T E ") && h a s _ n r d l _ r e q u e s t () ) { s l _ s e n d _ r e p l y ("100" , " T r y i n g ") ; if (! p r o c e s s _ n r d l _ r e q u e s t () ) { s w i t c h ( $ r e t c o d e ) { ca se -1: s l _ s e n d _ r e p l y ("500" , " I n t e r n a l e r r o r ") ; ex it ; ca se -2: s l _ s e n d _ r e p l y ("503" , " R e s o u r c e r e s e r v a t i o n s e r v i c e not a v a i l a b l e ") ; ex it ; ca se -3: s l _ s e n d _ r e p l y ("504" , " R e s o u r c e r e s e r v a t i o n t i m e o u t ") ; ex it ; ca se -4: s l _ s e n d _ r e p l y ("500" , " R e s o u r c e r e s e r v a t i o n r e s p o n s e too l a r g e ") ; ex it ; ca se -5: s l _ s e n d _ r e p l y ("406" , " R e s o u r c e r e s e r v a t i o n r e q u e s t not a c c e p t e d ") ; ex it ; ca se -6: s l _ s e n d _ r e p l y ("485" , " A m b i g u o u s ( too many RDF s ) ") ; ex it ; } } } ...
r o u t e (1) ; } o n r e p l y _ r o u t e { # - - - n e t r e s o p e r a t i o n on 183 - - - - - if ( s t a t u s == " 1 8 3 " && h a s _ n r d l _ r e q u e s t () ) { if (! p r o c e s s _ n r d l _ r e q u e s t () ) { xl og (" N RDL m o d u l e : SIP r e p l y los t \ n ") ; ex it ; } } } r o u t e [1] { ...
[1] E. Mannie, “Generalized Multi-Protocol Label Switching (GMPLS) Architectu- re,” RFC 3945, ottobre 2004.
[2] K. Knightson et al., “NGN Architecture: Generic Principles, Functional Archi- tecture, and Implementation,” Communications Magazine, IEEE, vol. 43, n. 10, ottobre 2005.
[3] J. Rosenberg et al., “SIP: Session Initiation Protocol,” RFC 3261, giugno 2002. [4] G. Zervas et al., “SIP-enabled Optical Burst Switching architectures and pro-
tocols for application-aware optical networks,” Computer Networks, 2008, doi: 10.1016/j.comnet.2008.02.016.
[5] J. van der Ham, et al., “Using the Network Description Language in Opti- cal Networks,” 10th IFIP/IEEE International Symposium on Integrated Network Management (IM), maggio 2007.
[6] ITU-T Y.2001 “General Overview of NGN,” dicembre 2004.
[7] H. Zimmermann, “OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection,” IEEE Transactions on Communications, vol. COM-28, n. 4, pp. 425-432, aprile 1980.
[8] IETF, “Requirements for Internet Hosts – Communication Layers,” RFC 1122, ottobre 1989.
[9] M. Handley et al., “SIP: Session Initiation Protocol,” RFC 2543, marzo 1999. [10] M. Handley et al., “SDP: Session Description Protocol,” RFC 4566, luglio 2006.
[11] University of Southern California, “Transmission Control Protocol,” RFC 793, settembre 1981.
[12] J. Rosenberg et al., “Reliability of Provisional Responses in the Session Initiation Protocol (SIP),” RFC 3262, giugno 2002.
[13] A. Niemi, “Session Initiation Protocol (SIP) Extension for Event State Publication,” RFC 3903, ottobre 2004.
[14] A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, giugno 2002.
[15] B. Campbell et al., “Session Initiation Protocol (SIP) Extension for Instant Messaging,” RFC 3428, dicembre 2002.
[16] O. Lassila, “Resource Description Framework (RDF) Model and Syntax Spe- cification,” W3C Recommendation, febbraio 1999, http://www.w3.org/TR/ 1999/REC-rdf-syntax-19990222/
[17] G. Klyne et al., “Resource Description Framework (RDF): Concepts and Ab- stract Syntax,” W3C Recommendation, febbraio 2004, http://www.w3.org/ TR/2004/REC-rdf-concepts-20040210/
[18] Resource Description Framework (RDF), http://www.w3.org/RDF/ [19] Extensible Markup Language (XML), http://www.w3.org/TR/xml/
[20] D. Brickley et al., “RDF Vocabulary Description Language 1.0: RDF Schema,” W3C Recommendation, febbraio 2004, http://www.w3.org/TR/ rdf-schema/
[21] T. Berners-Lee, “What the Semantic Web can represent,” 1998, http://www. w3.org/DesignIssues/RDFnot.html
[22] B. Martini et al., “A Novel Service Oriented Framework for Automatically swit- ched Transport Network,” 9th IFIP/IEEE International Symposium on Integrated Network Management (IM), maggio 2005.
[23] F. Baroncelli et al., “Supporting Control Plane-enabled Transport Networks wi- thin ITU-T Next Generation Network (NGN) architecture,” Network Operation and Management Symposium (NOMS) 2008, Salvador, Brasile, aprile 2008. [24] A. Swartz, “application/rdf+xml Media Type Registration,” RFC 3870, settembre
2004.
[25] R. Enns, “NETCONF Configuration Protocol,” RFC 4741, dicembre 2006. [26] J. Heinanen et al., “Assured Forwarding PHB Group,” RFC 2597, giugno 1999.
Devo un sentito ringraziamento al professor Franco Callegati, per avermi concesso la possibilità di affacciarmi su un mondo davvero stimolante – quello della ricerca. Inoltre devo ringraziarlo per la grande simpatia, disponibilità e pazienza adoperata nei miei riguardi in questi due anni di “Specialistica” e soprattutto durante il lavoro di tesi. In secondo luogo è doveroso ringraziare il mio correlatore, Ing. Aldo Campi, per la sua attenta supervisione e la fiducia riposta nei miei confronti. Ringrazio inoltre il professor Walter Cerroni, che ha dato il suo grande contributo, materiale e morale, anche nella realizzazione di questa tesi.
Un ringraziamento speciale va a tutto il personale con sede a Pisa che in questi mesi mi ha messo a disposizione l’infrastruttura di rete SOON:
• Barbara Martini, Fabio Baroncelli (CNIT);
• Piero Castoldi, Karim Torkmen, Valerio Martini (Scuola Superiore Sant’Anna). Tengo particolarmente a ringraziare Karim per le giornate intere passate con me su Skype™ supportandomi nel mio lavoro.
Un ringraziamento a Stefano Bianchini, Marco Ramilli e Nicola Calisesi, un trio di informatici che ha sicuramente cambiato la mia vita.
Ora è il momento di ringraziare coloro che hanno reso questi cinque anni di uni- versità un’esperienza unica, indimenticabile, ineguagliabile:
• Cola (Baggy), per la sua simpatia, intelligenza e autoironia; • Vincenza, per non essersi ancora stancata di lui;
buonista;
• Valentina, per essere disponibile nel momento dello scherzo;
• Nico, per aver messo a disposizione la sua casa nelle cene universitarie, per aver messo i suoi ciliegi a disposizione mia e di Baggy, e per quell’aura da bravo ragazzo che lo circonda anche se in realtà nasconde una mente diabolica; • Giova, per la sua inflessibilità e attitudine al comando;
• Maikol, per la sua pazzia sfrenata;
• Campe (F.d.F.), per le sue impareggiabili lezioni di vita e la sua creduloneria, che è seconda solo alla sua maestria con le donne;
• Jari (il finnico), per la sua grande generosità di spirito accompagnata da una malcelata acidità;
• Elisabetta, amica del finnico;
• Montini, per essere un provetto cacciatore di cinghiali e volatili, e per offrirci sublimi libagioni a casa sua;
• Ama, per averci spesso invitati a giocare e divertirci a casa sua;
• Moschino, perché è uno di noi e perché ci fece visitare luoghi stupendi vicino casa sua;
• Il Gagio, perché è un po’ burbero, ma di cuore tenero; • Crescia, che è semplicemente un genio;
• Simone Minardi, un motivo ci sarà;
• Migno, per avermi fatto provare i suoi pattini roller-blade una mattina in facoltà, per la sua incrollabile calma e per il suo salutismo portato all’estremo;
• Cisco, per essere la vera colonna portante della sede di Cesena della Seconda Facoltà di Ingegneria.
Sicuramente ho dimenticato qualcuno che avrei voluto includere. Mi perdoni!
Succintamente vorrei porgere un sincero ringraziamento a tutto il personale (docen- ti, segretari, tutor, dottorandi) di Ingegneria a Cesena, per il loro ammirevole impegno. Voglio ringraziare, inoltre Nicoletta, Alice, Jessica, Daniele e Tommaso, per esser- mi stati vicini nell’ultimo anno di università.
Intendo ringraziare i miei genitori, Mario e Olimpia, per avermi sempre supportato e sostenuto, insieme alle mie due sorelle Ilaria e Lisa.
Inoltre è opportuno che io ringrazi Benny Prijono (autore di PJSIP), Dave Becket (autore di Raptor), Donald Knuth per aver inventato TEX, Leslie Lamport per averlo esteso creando LATEX, gli sviluppatori di LYX, per aver creato un così potente front-end
per LATEX, infine gli sviluppatori di Linux e Debian, per aver costruito una piattaforma
solida sulla quale svolgere la tesi.
Ringrazio, infine, Luca, Luca, Rainer, Michele, Michele e tutti i miei più vecchi amici che hanno sempre creduto in me. Ringrazio anche Martin e la sua famiglia, che da Frankenwinheim non hanno mai cessato di farmi sentire il loro incoraggiamento.
Ora è arrivato il momento di rendere grazie alla persona che, ancora una volta, ha realmente permesso che tutto questo si avverasse. Sto parlando della ragazza che mi sta vicino, sopportandomi, da oltre quattro anni. È generosa, intelligente, caparbia, onesta, profonda. Voglio ringraziarla perché è l’artefice della mie fortune e delle mie felicità. Ogni istante passato insieme a lei è la cosa più preziosa che esista. Se l’Amore avesse un nome sarebbe sicuramente Elisa.
Filippo, Viserbella, 8 ottobre 2008