Capitolo 4
ARCHITETTURA CROSS-LAYER
La rete Internet collega milioni di dispositivi eterogenei e deve il successo, da un punto di vista tecnico, alla sua architettura interna, estensibile e robusta.
Tale architettura e caratterizzata dalla suddivisione delle funzionalita in moduli, che costituiscono i vari livelli della pila di protocolli. Ciascun protocollo opera ad uno speci co livello e regola solo una parte degli aspetti della comunicazione, permettendo di gestire piu facilmente la complessita del sistema. Infatti la divisione in livelli e fatta in modo che ciascuno di essi utilizzi esclusivamente i servizi forniti dal livello immediatamente inferiore, fornendo contemporaneamente dei servizi al livello superiore. Osserviamo che il livello superiore puo usufruire dei servizi o erti dal livello inferiore senza dover conoscere i dettagli su come tali servizi sono realizzati. In particolare nell'implementare un dato livello e suciente conoscere soltanto l'interfaccia che speci ca le funzionalita fornite dal livello immediatamente inferiore. Si dice quindi che l'architettura e "rigidamente suddivisa in livelli"
(strict-layered): i protocolli presenti a ciascun livello sono indipendenti tra loro e interagiscono mediante interfacce statiche ben de nite.
Questa scomposizione modulare dell'architettura permette di estendere o modi care la struttura di un dato livello, mantenendo completamente la compatibilita con il software gia sviluppato (a patto di conservare l'interfaccia
esportata verso il livello superiore della pila di protocolli), senza dover modi care, quindi, il resto del sistema.
All'interno di questa architettura (come schematizzato in gura 4.1) possiamo distinguere due di erenti ussi di comunicazione: un usso verticale e un usso orizzontale. Il usso verticale rappresenta l'informazione che viene scambiata tra i livelli della pila dei protocolli localmente ad un singolo nodo. Al contrario, il usso orizzontale rappresenta l'informazione che viene scambiata tra livelli corrispondenti della pila dei protocolli presenti in nodi distinti, durante una loro comunicazione.
In un'architettura strict-layered si privilegia il usso orizzontale di comunicazione piuttosto che quello verticale. Conseguentemente si tende a consumare banda trasmissiva (risorsa abbondantemente disponibile su Internet) piuttosto che potenza di elaborazione o memoria.
Figura 4.1: Flussi di comunicazione in una pila di protocolli
La possibilita di riutilizzare software gia esistente e collaudato e la visione delle reti MANET come estensione di Internet, ha portato ad utilizzare l'architettura strict-layered anche nel contesto delle reti ad hoc.
Tuttavia alcuni aspetti critici propri delle reti ad hoc (ad esempio sicurezza e cooperazione, gestione risparmio energetico e qualita del servizio) non possono essere gestiti interamente ad un dato livello ma devono essere sviluppati combinando e sfruttando i meccanismi implementati all'interno di tutti i livelli della pila dei protocolli. Inoltre in ambiente MANET si hanno
vincoli molto diversi rispetto a quelli presenti in Internet, dovendo gestire una dinamicita piu elevata e disponendo di minori risorse computazionali.
La ricerca si e quindi orientata verso lo sviluppo di nuove soluzioni architetturali che, riducendo la suddivisione stretta in livelli, sfruttano maggiormente la comunicazione e lo scambio di informazioni tra livelli non adiacenti della pila dei protocolli.
In particolare alcune soluzioni, pur introducendo delle interazioni cross- layer, sostanzialmente conservano la separazione tra i livelli. E' questo il caso dei cosidetti "layer trigger": un dato livello della pila, attraverso segnali ben de niti, noti ca determinati eventi ai livelli superiori. Ad esempio in Internet si e studiata la possibilita di far inviare dal livello rete al livello trasporto una noti ca esplicita di avvenuta congestione (ECN - Explicit Congestion Noti cation). Tale noti ca viene inviata dai router per segnalare al livello TCP il loro stato di congestione, in modo che si possano applicare prontamente delle politiche di recupero.
Esistono anche delle soluzioni completamente cross-layer che, sfruttando le interdipendenze tra i vari livelli, ottimizzano le prestazioni complessive della rete. In questo tipo di architetture le informazioni scorrono verticalmente tra i vari livelli della pila, permettendo a ciascun protocollo di adattare il proprio comportamento in funzione dei protocolli di livello piu alto e piu basso.
Nonostante un approccio di tipo cross-layer possa fornire un notevole miglioramento delle prestazioni, sono ancora molti coloro che preferiscono un'architettura strict-layered. In particolare in un'architettura strict-layered le interazioni tra livelli sono rigidamente controllate e il progetto di un dato livello puo essere svolto in maniera relativamente autonoma rispetto agli altri livelli. Al contrario, un approccio cross-layer potrebbe determinare delle interazioni non desiderate tra livelli diversi, diminuendo le prestazioni del sistema. Inoltre occorre prestare attenzione allo sviluppo delle soluzioni cross-layer per evitare di ottenere codice sorgente dicile da mantenere (dovendo, per ogni modi ca apportata, rendere consistenti tutti i livelli della pila). Nonostante questi aspetti critici, un approccio cross-layer permette notevoli ottimizzazioni. In particolare ciascun livello della pila di protocolli
4.1 Esempi di soluzioni cross-layer
puo ottenere la completa consapevolezza del contesto operativo e adattare conseguentemente il proprio comportamento. Inoltre l'uso di una strategia cross-layer permette di adattare il sistema alla notevole variabilita delle condizioni della rete, propria dell'ambiente MANET, migliorando cos le prestazioni complessive.
Nelle prossime sezioni, dopo aver illustrato alcuni contesti in cui si possono ottenere notevoli bene ci da un approccio cross-layer, illustreremo una nuova soluzione architetturale che consente di stabilire delle interazioni di tipo cross-layer continuando a rispettare il principio di separazione tra i vari livelli della pila.
4.1 Esempi di soluzioni cross-layer
La possibilita di far comunicare direttamente protocolli non adiacenti della pila permette di ottimizzare vari aspetti e consente ai vari livelli di avere una piena consapevolezza del contesto in cui si trovano ad operare. In letteraraura sono state proposte varie soluzioni basate su interazioni cross-layer tra speci ci livelli e rivolte ad ottimizzare le prestazioni del sistema.
Ad esempio in [AYL02] viene mostrata una possibile interazione tra i livello MAC e il livello routing. Infatti il livello MAC potrebbe comunicare al livello routing informazioni sulla qualita del collegamento quali il valore del rapporto segnale-rumore (SNR- Signal to noise ratio), la capacita o il ritardo (sperimentato a livello MAC) nell'invio di una trama. Queste informazioni, opportunamente combinate, potrebbero servire al routing per scegliere i percorsi ottimali.
In [Chi04], partendo dal fatto che il controllo di congestione in Internet viene risolto a livello trasporto (considerando le capacita dei collegamenti come valori costanti), si suggerisce di sfruttare le informazioni sulla potenza trasmissiva rilevata a livello sico (e quindi il throughput) per implementare nuove strategie di prevenzione e recupero della congestione.
In ne si potrebbe pensare, come indicato in [KKT04], di usare le informazioni sul livello della batteria prelevate da ciascun dispositivo per
4.2 Network Status - NeSt
fornire al livello routing dei parametri ulteriori per scegliere i nodi da attraversare nel percorso verso la destinazione.
Nonostante queste soluzioni proposte rappresentino, nei rispettivi settori, delle possibili ottimizzazioni, si corre il rischio di creare un'architettura caratterizzata da livelli troppo strettamente dipendenti gli uni dagli altri.
Questo puo portare ad una pila di protocolli piu dicile da mantenere nel tempo in modo eciente, dovendo rendere consistenti vari livelli per ogni modi ca apportata ad uno di essi.
Inoltre occorre evitare che di erenti ottimizzazioni possano interferire negativamente tra di loro. Ad esempio un livello MAC che adatta il proprio tasso di trasmissione sulla base della qualita del collegamento, potrebbe suggerire al livello routing collegamenti con tassi di trasmissione piu elevati, magari determinando percorsi piu lunghi per raggiungere la destinazione. Questo suggerimento, pero, sarebbe in contraddizione con la politica tipicamente seguita dai protocolli di routing che minimizzano il numero di passi in rete.
4.2 Network Status - NeSt
In [CMT04] viene proposta un'architettura innovativa che riesce a combinare il principio di separazione dei livelli della pila di protocolli con l'approccio cross-layer. Tale architettura prevede l'introduzione di un modulo software verticale, detto Network Status (NeSt), che ha il compito di controllare e gestire tute le interazioni cross-layer (vedere gura 4.2). Il NeSt memorizza e mantiene consistenti nel tempo delle informazioni raccolte ai vari livelli della pila, permettendone la condivisione da parte dei protocolli presenti. Tali informazioni sono codi cate sotto forma di astrazioni e la loro rappresentazione e nota e condivisa dai vari protocolli della pila. Inoltre un'interfaccia ben de nita stabilisce come i vari protocolli possono pubblicare o recuperare le informazioni all'interno del NeSt.
In questa nuova architettura i vari protocolli vengono ancora implementati in maniera autonoma a ciascun livello della pila. La presenza del modulo NeSt non richiede la modi ca delle funzionalita essenziali di
4.2 Network Status - NeSt
Figura 4.2: Collocazione modulo NeSt nella pila di protocolli
ciascuno di essi, rendendo compatibili con la nuova architettura anche i protocolli gia di usi. L'architettura riesce a mantenere il principio di separazione dei livelli, stabilendo in modo preciso come i vari protocolli possono accedere al modulo NeSt per recuperare o rendere disponibili delle informazioni.
Il modulo NeSt o re a ciascun livello della pila la possibilita di avere una completa consapevolezza del contesto in cui si trova ad operare. In particolare
e possibile rendere disponibili a tutti i livelli, tramite il NeSt, informazioni quali, ad esempio, la topologia della rete o il livello energetico della batteria presente nel nodo.
Il modulo NeSt si comporta da intermediario nella gestione della comunicazione verticale tra protocolli appartenenti a livelli diversi. In particolare deve esportare verso i protocolli un'interfaccia che consenta di condividere delle informazioni o reagire a determinati eventi. Inoltre i protocolli devono concordare delle astrazioni con cui rappresentare all'interno del NeSt dati ed eventi. In parallelo a questa sua attivita, gli
4.3 Interazioni middleware-routing
altri protocolli continuano regolarmente le comunicazioni livello per livello usando le interfacce tradizionali.
Da un punto di vista generale possiamo individuare due tipi di interazioni tra protocolli: asincrone e sincrone. In particolare e possibile che livelli diversi della pila condividano delle informazioni. In questo caso un protocollo puo chiedere al modulo NeSt di recuperare dei dati prodotti ad altri livelli della pila e bloccarsi in attesa di riceverli. Questa viene detta interazione sincronizzata. Al contrario le interazioni asincrone, si hanno al veri carsi di eventi di interesse per un qualche protocollo della pila. In particolare, un protocollo puo registrare presso il NeSt il proprio interesse ad essere
"avvisato" quando si veri ca un dato evento. Sara compito del NeSt noti care gli eventi ai protocolli interessati.
Anche gli eventi sono classi cabili in interni o esterni. Gli eventi interni sono prodotti generalmente all'interno di un protocollo (ad esempio un protocollo di routing potrebbe noti care la presenza di una rotta non piu valida). Gli eventi esterni, invece, vengono rilevati all'interno del NeSt sulla base delle informazioni registrate dai protocolli che hanno richiesto di essere avvisati. Ad esempio un protocollo potrebbe registrare un evento "batteria scarica" chiedendo al NeSt di essere avvisato quando la batteria del nodo locale scende al di sotto di una certa soglia.
In de nitiva possiamo osservare che la reciproca consapevolezza delle condizioni operative dei vari protocolli permette loro di adattare coerentemente il proprio comportamento, migliorando complessivamente le prestazioni per l'utente nale.
4.3 Interazioni middleware-routing
Nell'ambito di questa tesi abbiamo sviluppato un sistema software che realizza un'interazione tra middleware e routing in ambiente MANET.
Abbiamo gia visto come, a livello middleware, sia possibile utilizzare degli opportuni protocolli per costruire un overlay network formato da un sottoinsieme dei nodi della rete che o rono un determinato servizio.
4.3 Interazioni middleware-routing
Per costruire una tale rete occorre, innanzitutto, individuare quali sono i nodi che o rono il servizio e, quindi, stabilire e mantenere nel tempo dei percorsi (a livello sico) per poter comunicare con loro. Questo compito viene normalmente svolto dal middleware, con un costo proporzionale alla dinamicita della rete sica sottostante. Questa impostazione e derivata dalle soluzioni P2P gia di use in ambito Internet, dove normalmente non si ha alcuna conoscenza della topologia sica della rete e le informazioni vengono acquisite a livello middleware in modo distribuito. Naturalmente in tale contesto questa soluzione risulta ragionevole, essendo la rete Internet stabile dal punto di vista della topologia e avendo un'ampia banda disponibile. La situazione e completamente diversa in ambiente MANET, dove la banda disponibile e limitata e la topologia e fortemente dinamica.
Ecco, quindi, che risulta ragionevole utilizzare una soluzione di tipo cross-layer nella quale il livello routing esporta verso il middleware delle informazioni sulla topologia della rete e sui servizi disponibili nei vari nodi presenti. Sfruttando queste informazioni, recuperabili dal middleware con una comunicazione locale al nodo (schematizzata in gura 4.3), e possibile sempli care notevolmente la creazione e la manutenzione dell'overlay network.
Figura 4.3: Interazione cross-layer tra il livello middleware e il livello routing Da questo punto di vista possiamo notare come sia molto piu utile l'impiego di un protocollo di instradamento proattivo in grado di fornire, in ogni istante, una visione completa ed aggiornata della topologia della rete.
4.3 Interazioni middleware-routing
Ricordando che ogni overlay network e associato ad un dato servizio che i nodi partecipanti si impegnano ad o rire, occorre realizzare contestualmente un sistema di ricerca del servizio che permetta di individuare quali sono i nodi che lo o rono nell'ambito della rete.
Piuttosto che creare un vero e proprio protocollo di ricerca del servizio, che avrebbe contribuito ad aumentare notevolmente il sovraccarico del sistema, si e sviluppata una soluzione ottimizzata che sfrutta la natura proattiva del protocollo di routing a livello network.
Infatti e ragionevole pensare che ciascun nodo possa inviare periodicamente, incapsulato all'interno di un pacchetto LSU del routing proattivo, un semplice messaggio in cui viene annunciata la disponibilita di un servizio. In questo modo ogni nodo puo creare una struttura dati in cui vengono mappati, in corrispondenza di ogni servizio, gli indirizzi di tutti gli altri partecipanti che attualmente lo stanno o rendo. Questa informazione risultera direttamente accessibile, con un approccio cross-layer, da parte del livello middleware che potra utilizzarla per costruire autonomamente l'overlay network. Naturalmente tale struttura dovra essere mantenuta consistente nel tempo e dovranno essere sviluppati opportuni meccanismi per gestire le situazioni di errore.
Nei seguenti capitoli della tesi, svilupperemo nel dettaglio le idee sopra delineate. In particolare illustreremo una soluzione middleware ottimizzata per reti ad hoc, chiamata CrossROAD - Cross-Layer Ring Overlay for Ad Hoc Network [Del05]. Questa soluzione segue i principi di base del modello Pastry ma, sfruttando un'interazione cross-layer con il protocollo di routing, mantiene una corrispondenza tra spazio sico e logico in grado di ottimizzare la creazione ed il mantenimento dell'overlay network.
4.3 Interazioni middleware-routing
