source: doc/AssociazioneMultipla.tex @ 10

\documentclass[a4paper,10pt]{article}

\usepackage[italian]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[pdftex,bookmarks,colorlinks]{hyperref}

% SoujaK
 %\usepackage[pdftex,pdftitle={},pdfauthor={},pdfpagemode=FullScreen,
 %plainpages=false,pdfpagelabels,urlcolor=blue,linkcolor=red,citecolor=green,
 %bookmarks=false]{hyperref}

\title{Associazione multipla simultanea di~un~\textit{client}~802.11}
\author{Andrea~Rappini, Alessio~Romagnoli,\\Marco~Solieri, Andrea Simeone}

\makeindex


\begin{document}

\maketitle

\begin{abstract}
La diffusione di reti \textit{wireless} è in forte crescita a causa della sua
comodità e della larga disponibilità di connessioni ad Internet con ampie
larghezze di banda.
Sfruttare contemporaneamente la connessione alla molteplicità di reti spesso
presente permetterebbe un utilizzo migliore di tali risorse, migliorando il
\textit{throughput} aggregato e incrementandone l'affidabilità.

Si intende dapprima introdurre il lettore allo scenario nel quale è stato
condotto lo studio, evidenziandone gli aspetti salienti che riguardano lo
standard IEEE 802.11 e le sue interpretazioni.
In un secondo momento si presenteranno non solo le proposte risolutive
individuate, ma anche spunti per ulteriori ottimizzazioni.
\end{abstract}

\clearpage
\tableofcontents

\clearpage
\section{Introduzione}
\label{sec:introduzione}

\subsection{Oggetto}
\label{sec:oggetto}
Lo studio di fattibilità si interroga sulle possibilità realizzative di
connessione di un singolo \textit{client} 802.11 a diverse reti, partecipando a
più BSS (cioè l'insieme di nodi costituenti una rete \textit{wireless}).

Si analizzano le effettive possibilità di realizzazione di un'estensione delle
comuni implementazioni dello standard IEEE 802.11 che permetta al singolo
\textit{client} in ambiente GNU/Linux l'associazione simultanea a differenti
reti \textit{wireless}.

\subsection{Scopi}
\label{sec:scopi}
L'intento più evidente è quello di aumentare la connettività del
\textit{client}, permettendogli connessioni simultanee a reti altrimenti isolate
ed eventualmente consentendogli di agire in qualità di ponte fra di esse.
Qualora i punti di accesso resi contemporaneamente utilizzabili riferiscano (più
o meno direttamente) alla medesima rete, allora la molteplicità si traduce in
ridondanza e, conseguentemente, in affidabilità.
I più coraggiosi potranno infine sfruttare le multi-connettività in oggetto come
punto di partenza per la realizzazione di politiche di gestione al fine di
massimizzare il \textit{throughput} aggregato.

\subsection{Obiettivi supplementari}
\label{sec:obiettivi}
I criteri con i quali si sono prese le svariate decisioni che hanno
caratterizzato lo studio e che si concretizzano nelle soluzioni proposte sono
stati influenzati dai seguenti obiettivi supplementari:
\begin{description}
 \item [\textit{overhead} minimo]
 abbattere i costi introdotti dalla gestione simultanea delle connessioni
 multiple;
 \item [perdite minime]
 ridurre o eliminare ogni possibile perdita di dati in ricezione causata dalla
 temporanea assenza su un BSS (cfr. sezione \ref{sec:mezzotrasmissivo});
 \item [portabilità]
 essere quanto più indipendente dalle specifiche piattaforme
 \textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente
 GNU/Linux;
 \item [facilità implementativa]
 ridurre gli sforzi per l'effettiva messa in opera;
 \item [trasparenza]
 virtualizzare le interfacce di rete associate ad ogni connessione per
 minimizzare l'impatto per l'utente come per il sistema.
\end{description}

\section{Scenario}
\label{sec:scenario}

\subsection{Caratteristiche del mezzo trasmissivo}
\label{sec:mezzotrasmissivo}
Il mezzo trasmissivo utilizzato nelle comunicazioni di reti senza fili è, per
sua natura, disponibile e condiviso da ogni utilizzatore, pertanto lo standard
IEEE 802.11 ne sancisce il partizionamento in diversi spettri di frequenza
denominati canali. In tal modo si permette la coesistenza di reti
\textit{wireless} distinte in aree limitrofe o addirittura sovrapposte grazie
all'uso di canali differenti.

\label{salti}
Lo studio ha pertanto tenuto presente la necessità da parte del \textit{client}
di effettuare salti periodici di canale per poter raggiungere ogni BSS a cui
desideri partecipare.

\subsection{Standard IEEE 802.11}
\label{sec:80211}
\subsubsection{Accesso alla rete}
\label{sec:accessoallarete}
\paragraph{Associazione}
Affinché una stazione mobile possa partecipare ad una rete \textit{wireless}, le
è fatto obbligo di annunciare la sua presenza attraverso una procedura detta di
associazione.
Questo legame unisce una stazione ad uno ed un solo BSS e garantisce che la
stazione possa effettuare trasmissioni dirette ad ognuno dei nodi appartenente
all'intera rete e viceversa.
Lo studio intende proprio scardinare l'univocità del rapporto fra stazione
e BSS che lo standard impone esplicitamente.

\paragraph{Autenticazione}
A causa della natura condivisa del mezzo trasmissivo, l'accesso alla rete
sarebbe aperto a qualunque stazione richieda di associarsi.
IEEE ha quindi elaborato una strategia di regolazione dell'accesso  richiedendo
la mutua identificazione di entrambi gli estremi di ogni comunicazione.
Tale procedura, definita autenticazione, risulta pertanto essere un prerequisito
della stessa associazione.\\
Il processo può diventare oneroso in termini di tempo a causa dei \textit{frame}
da scambiare e dell'elaborazione necessaria (si pensi ai calcoli crittografici
coinvolti), quindi ne viene permessa l'invocazione anche in maniera indipendente
dal servizio di associazione. Così facendo lo standard permette di mantenere
questo carico lontano dai momenti in cui il tempo è un fattore
critico\footnotemark, sfruttando la \textbf{preautenticazione}.
\footnotetext{Infatti, se la STA è in movimento fra due BSS e se
l'autenticazione cade prima che la stessa STA possa riassociarsi con il
successivo AP, la procedura potrebbe richiedere tempi considerevoli che
andrebbero a degradare pesantemente le prestazioni.}
Da quanto detto risulta quindi evidente che, a differenza dell'associazione,
una stazione può essere autenticata presso molteplici altre stazioni.

\paragraph{802.11i}
\label{80211i}
L'estensione 802.11i \cite{80211i} dello standard intende migliorare
il livello di sicurezza e confidenzialità introducendo nuovi protocolli e
meccanismi.
Tutti i suoi metodi di autenticazione basati su autenticatori esterni
(\textit{server} RADIUS) provengono dallo standard 802.1x, che riguarda proprio
il controllo d'accesso a reti dell'insieme 802 (Ethernet, Token-ring \ldots).
Questo genere di comunicazioni viene quindi effettuato a strati di rete
superiori coinvolgendo marginalmente il livello 802.11 in oggetto.
È per questa ragione che i dettagli inerenti l'autenticazione ad alto livello
(pertanto scorrelata da quella di 802.11 da poco descritta) sono sostanzialmente
irrilevanti per gli scopi del presente studio.

\subsubsection{Risparmio energetico}
\label{sec:risparmioenergetico}
Lo standard prevede la possibilità di utilizzare l'\textit{hardware} in maniera
efficiente rispetto ai consumi energetici, dal momento che i dispositivi
portatili alimentati a batteria sono tutt'altro che rari.
Le stazioni che supportano tale funzionalità hanno infatti la facoltà di
``addormentarsi'' durante i periodi di inattività.
In questi momenti, gli eventuali dati ad esse destinati vengono conservati dal
BSS\footnotemark per un invio successivo, essendo esso stato precedentemente
avvisato dello stato delle stazioni in questione.
I BSS, quindi, annunciano periodicamente la presenza delle trasmissioni in
attesa, indicandone i destinatari con un messaggio chiamato TIM che è presente
all'interno di alcuni dei \textit{beacon} (cfr. \ref{sec:vincolitemporali}.
Conseguentemente le stazioni in risparmio energetico sono tenute a risvegliarsi
in corrispondenza di questi intervalli regolari, per poi richiedere l'invio
tramite un apposito tipo di \textit{frame} (il \texttt{PS-Poll}).
\footnotetext{In realtà sarebbe doveroso fare una distinzione fra le reti
infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la
conservazione dei dati è appannaggio, rispettivamente, dell'\textit{access
point} e del nodo trasmittente.}

\subsubsection{Vincoli temporali}
\label{sec:vincolitemporali}
Come già anticipato (sezione \ref{salti}), il \textit{client} avrà l'illusione
di essere contemporaneamente associato ai BSS di interesse tramite continui
salti fra di essi; per questo motivo risulta importante chiarire quali siano i
vincoli temporali che lo standard gli impone.
La padronanza di queste informazioni è di grande rilevanza, sia perché dovranno
essere rispettate dal \textit{client} anche in seguito alle modifiche che
verranno proposte nel presente studio, sia perché potranno essere tenute
presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni (si
veda, più avanti, la sezione \ref{sec:ottimizzazioni}.

L'accesso al mezzo trasmissivo, a causa della sua stessa natura condivisa, è
regolato da convenzioni stabilite dallo standard che consentono una
ripartizione equa di questa risorsa.
Tali regolamentazioni di natura temporale si fondano sulla reciproca
sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta
tramite il mantenimento di un \textbf{orologio} comune al BSS\footnotemark di
appartenenza.
Il valore su cui accordarsi viene distribuito all'interno di un \textit{frame}
di gestione, il \textit{\textbf{beacon}}, inviato ad intervalli regolari e
prefissati.
Se già ora si intuisce che l'eventuale perdita di questi messaggi periodici
durante i salti va minimizzata, ancor di più se ne comprende l'importanza a
fronte della presenza di ulteriori informazioni di grande interesse per i fini
preposti.
\footnotetext{Ancora una volta sarebbe necessaria una distinzione fra le reti
infrastrutturate e le reti \textit{ad hoc}: il valore comune su cui accordarsi è
dettato rispettivamente dall'\textit{access point} e dall'intero BSS in maniera
distribuita.}

Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
anche degli annunci d'inizio dei periodi liberi da contesa presenti nelle reti
infrastrutturate, lassi di tempo durante i quali l'accesso al mezzo è
coordinato da un gestore centrale.
Esso risiede tipicamente nell'\textit{access point} e provvede a coordinare le
comunicazioni in maniera spesso più efficiente rispetto a quando il
coordinamento è distribuito.

In aggiunta a quanto detto, il \textit{client} non potrà trascurare le
\textbf{scadenze} temporali oltre le quali i rapporti di autenticazione e
associazione con i BSS vengono a cadere.

\subsection{\textit{Wireless Extensions}}
\label{sec:wext}
La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di
riferimento le Linux Wireless Extensions (per brevità \textsc{wext}).
Il progetto intende mettere ordine in uno scenario spesso dominato
dall'eterogeneità, proponendo delle interfacce unificate per i driver di sistema
delle varie soluzioni \textit{hardware} disponibili.
Nel momento in cui si scrive non tutti i \textit{driver} che si sono
completamente uniformati a questo insieme di interfacce, ma la speranza che esse
diventino presto lo standard \textit{de facto}.

Accanto alle API di programmazione sono stati sviluppati anche gli
\textit{Wireless Tools}, comodi strumenti per l'utente che intendono
offrire le medesime possibilità attraverso un'interfaccia a riga di comando.

\subsection{Implementazioni}
\label{sec:implementazioni}

\subsubsection{Architettura}
\label{sec:architettura}
Lo standard IEEE 802.11 definisce due strati di rete che sono riconducibili,
facendo riferimento al modello ISO/OSI, al livello fisico e a quello MAC
(\textit{Medium Access Control}), implementati dai produttori tramite
l'accoppiata \textit{hardware}/\textit{firmware}.
MAC viene solitamente realizzato così a basso livello per rispondere alle
esigenze di velocità e accuratezza temporale di cui si accennava in
\ref{sec:vincolitemporali}.
È importante sottolineare, quindi, che qualunque idea risolutiva dello studio in
questione non potrà prescindere dalle modalità di interazione (interfacce e
regolazioni) consentite dalla specifica implementazione di MAC.
Questa dipendenza diventa tanto più rilevante quanto la soluzione perseguita si
discosta dalla rigidità dello standard.

La revisione 802.11i (introdotta in \ref{80211i}, che estende lo standard
migliorando la sicurezza da esso offerta, definisce nuove funzionalità per il
livello MAC che possono invece essere tranquillamente implementate all'esterno
del \textit{firmware}.

\subsubsection{Libertà d'azione}
\label{sec:libertàdazione}
Le più diffuse implementazioni di 802.11 sono quantomai lontane dalle
libertà di azione sperabili poiché il \textit{firmware} risulta essere
scarsamente programmabile, consentendo poco più delle interazioni necessarie al
normale funzionamento.
Esempi di soluzioni \textit{chipset} che siano contrarie a questa tendenza, e
pertanto interessanti, vengono riportati da \cite{defguide}: Atheros e Broadcom;
il primo dei due, provato direttamente dagli autori, sarà oggetto della sezione
\ref{sec:casoreale}.

A complicare ulteriormente la situazione intervengono le limitazioni imposte
dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC
statunitense\footnotemark), che richiedono la distribuzione dei trasmettitori
radio con \textit{firmware} in forma necessariamente binaria per scongiurare
violazioni dei limiti di utilizzo delle frequenze.
\footnotetext{Per maggiori informazioni si veda:\\
\url{http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
}}

\subsubsection{Interpretazione dello standard}
\label{sec:interpretazionedellostandard}

Nemmeno le più fedeli realizzazioni di 802.11 (come segnala \cite{defguide})
supportano la preautenticazione , quindi i servizi di autenticazione e
associazione risultano indissolubilmente legati, vanificando ogni possibilità di
realizzare nativamente autenticazioni multiple.
Di conseguenza, il superamento di questo limite, vincolante per realizzare
associazioni multiple simultanee, sarà, in tutta la sua complessità, compito
dell'implementatore della soluzione proposta in \ref{sec:soprailfirmware}.

Un'altra eventuale (e poco probabile) limitazione dovuta all'interpretazione
dello standard può derivare dalla libertà concessa riguardo la stessa
implementazione del supporto alla gestione energetica.

\subsection{Caso reale}
\label{sec:casoreale}

Le schede Atheros costituiscono una realtà attraente per i fini dello studio, in
particolare per ciò che concerne le libertà d'azione concesse di cui al
\ref{sec:libertàdazione}.
Il driver MADWiFi è in grado sfruttare in maniera interessante le
potenzialità fornite da questo \textit{chipset}, offrendo funzionalità non
troppo distanti dagli scopi del presente.

\subsubsection{Il \textit{chipset} Atheros}
\label{sec:atheros}

I \textit{chipset} Atheros equipaggiano i dispositivi 802.11 di alcuni
fra i maggiori produttori di \textit{hardware} per la connettività, come
Linksys, NETGEAR, D-Link, Orinoco, Proxim o 3Com.
Il suo \textit{firmware} consente un grado di interazione dall'estensione
incomparabile, esponendo un'interfaccia in grado di offrire controllo anche su
dettagli generalmente offuscati.

Proprio per questa ragione la sua distribuzione è vincolata alla presenza di un
sovrastrato (reso disponibile in sola forma binaria) atto a limitare
l'interfaccia al fine di impedire utilizzi non conformi alle vigenti
regolamentazioni sugli apparecchi radio.
Tale componente, denominato HAL (\textit{Hardware Abstraction Layer}),
interviene limitando le radiofrequenze operative del dispositivo, continuando
comunque a concedere le libertà auspicate.

\subsubsection{Il \textit{driver} MADWiFi}
\label{sec:madwifi}
A partire dallo scorso anno la spinta innovatrice di Atheros ha avuto riscontro
nel progetto MADWiFi, i \textit{driver} liberi per piattaforme Linux sviluppati
inizialmente da Sam Leffler.
Infatti i miglioramenti introdotti dal nuovo HAL sono stati sfruttati
per l'introduzione di una serie di funzionalità di grande rilevanza.
Il carattere rivoluzionario rende il progetto, come spesso capita, piuttosto
instabile ma assai vitale.

\paragraph{VAP}
L'aspetto indubbiamente più interessante è l'introduzione della modalità
VAP (\textit{Virtual Access Point}), grazie alla quale è possibile
virtualizzare il dispositivo creando molteplici interfacce di rete operanti
concorrentemente.
Questa funzionalità è implementata facendo uso del medesimo livello fisico,
vincolando così l'operatività dei VAP sullo stesso canale trasmissivo.
Ciononostante, la rosa delle possibilità rimane ben assortita, permettendo la
creazione di molteplici \textit{access point} e/o una (e al più una) stazione in
modalità \textit{managed} o \textit{ad-hoc}.
La nota modalità \textit{monitor} viene inoltre resa inseribile in una qualsiasi
delle configurazioni appena descritte, con la semplice aggiunta di un VAP di
questo tipo.
Le interfacce virtuali create possono essere utilizzate comodamente in piena
trasparenza, essendo aderenti alle \textit{Wireless Extensions}.
\paragraph{WDS}
I vari VAP creati possono poi essere eventualmente interconnessi tramite il WDS,
un'altra delle caratteristiche salienti del driver, che realizza un sistema di
distribuzione basato su connessioni 802.11 fra i BSS d'interesse, siano
essi locali (e virtualizzati) o esterni.
Questa caratteristica risponde agilmente all'esigenza di creazione di
interconnessioni di differenti reti senza fili.
\paragraph{Gestione}
L'alto grado di controllo permesso dal \textit{firmware} Atheros si propaga fino
all'utente attraverso il \textit{driver} grazie ai suoi numerosi parametri
specifici, che si ricordano essere gestibili tramite il comando \texttt{iwpriv}
degli \textit{Wireless Tools}.
Un ulteriore strumento a riga di comando, \texttt{wlanconfig}, completa le
necessità di amministrazione proprie di questo \textit{driver}, permettendo
creazione, distruzione e cambio di modalità dei VAP.

\section{Soluzioni}
\label{sec:soluzioni}
Lo studio di fattibilità in oggetto non può che aver prodotto degli schemi di
soluzione che coniugano le idee emerse durante la fase di analisi del problema.
Queste proposte si differenziano per il livello implementativo di riferimento,
poiché esso comporta un importante \textit{trade-off} fra portabilità ed
efficienza.
Quanto più basso, infatti, è il livello al quale si opera, tanto più alta è la
possibilità di sfruttare appieno le potenzialità del dispositivo, a scapito
della compatibilità offerta e della facilità implementativa.
Punto fermo di ogni soluzione proponibile è l'effettuazione di salti periodici
fra i BSS ai quali il \textit{client} desideri essere ``contemporaneamente''
associato.
Le differenze di prestazioni fra le due soluzioni che si proporranno di
seguito sono dovute proprio ai diversi tempi che i salti periodici
richiedono, che costituiscono quasi interamente l'\textit{overhead} introdotto.

Si procederà quindi ad illustrare due soluzioni, dimostrando quanto appena
affermato e calcolando il rapporto fra vantaggi e svantaggi che esse comportano.

\subsection{Sopra il \textit{firmware}}
\label{sec:soprailfirmware}

\subsubsection{Descrizione}
Questa soluzione nasce dal desiderio di realizzare associazioni multiple
effettive per mezzo delle quali, cioé, in ogni istante ciascun BSS consideri il
\textit{client} regolarmente associato.
Ciò che si propone consiste sostanzialmente di modifiche al \textit{driver} per
implementare i salti fra i BSS in maniera tale da evitare la perdita di
associazione presso ognuno di essi.

\paragraph{Come}
Per far ciò si deve interagire direttamente (ed eventualmente in maniera
poco corretta) con l'entità di gestione di 802.11, che si è già chiarito
risiedere all'interno del \textit{firmware} della scheda \textit{wireless}.
Soltanto il \textit{driver} sovrastante ha infatti la possibilità di alterare
determinati stati interni al \textit{firmware} per modificare il comportamento
di MAC.
I parametri a cui ci si riferisce sono quelli che regolano i rapporti di
associazione e autenticazione della stazione: caratteristiche del
BSS, caratteristiche della crittografia e dell'autenticazione in uso, eventuali
chiavi temporanee \ldots

\paragraph{Gabola}
\label{gabola}
Uno degli aspetti più convincenti di questa soluzione è la possibilità di
utilizzare la modalità di risparmio energetico (introdotta nella sezione
\ref{sec:risparmioenergetico}), grazie all'effettività dell'associazione.
I ripetuti salti costringono il \textit{client} ad assenze dal canale che
possono infatti essere spacciate senza troppa difficoltà per riposi
preannunciati, costringendo con l'inganno i BSS a conservare i dati a lui
diretti. Per completare questa strategia, la stazione simula al suo ritorno un
risveglio per ricevere l'intera mole di informazioni in attesa di consegna.

\paragraph{Architettura}
Il \textit{design} della soluzione intende rispondere alle esigenze di
trasparenza per il sistema operativo e, di conseguenza, per l'utente.
Le interfacce virtuali, della cui presenza il \textit{driver} è tenuto a
notificare il SO, aderiscono alle \textit{Wireless Extensions} e si
differenziano attraverso diversi indirizzi MAC (verosimilmente fittizi).
Questa forma di \textit{spoofing} è necessaria sia per lo smistamento dei flussi
in entrata alla stazione e provenienti dai BSS, sia per il convogliamento di
quelli in uscita dalla stazione e diretti ai vari BSS.
% 
%       Grafico della faccenda
%       OS   [] [] []
%              \ | /
%       DRI     \|/
%       FW      [ ]
%     ANTENNA    Y
%              .'  `.
% BSS1       .'      B1
% BSS2     B2
% 
Così facendo si rende peraltro possibile l'utilizzo di associazioni multiple
all'interno del medesimo ESS per ridondare la partecipazione.
La residenza del componente di gestione dei flussi multipli di comunicazione
all'interno del \textit{driver} lascia chiaramente spazio all'aggiunta di
politiche per pianificazioni ottimali delle trasmissioni (se ne parlerà più
approfonditamente in \ref{sec:ottimizzazioni}.

\subsubsection{Vantaggi}
\begin{description}
 \item [Perdita di dati nulla]:\\
  \begin{math} \Leftarrow \end{math}
  i dati in arrivo vengono conservati dai BSS grazie allo sfruttamento della
  modalità di risparmio energetico (cfr. \ref{sec:risparmioenergetico} e
  \ref{gabola}).
 \item [Prestazioni massime]:\\
  \begin{math} \Leftarrow \end{math}
  l'effettiva associazione multipla minimizza il costo dei salti evitando
  riautenticazioni e riassociazioni (cfr. \ref{sec:accessoallarete}).
 \item [Trasparenza totale]:\\
  \begin{math} \Leftarrow \end{math}
  le interfacce aderenti alle \texttt{wext} nascondono completamente la realtà
  dei fatti (cfr. \ref{sec:wext}).
 \item [Punto di partenza già disponibile]:\\
  \begin{math} \Leftarrow \end{math}
  \texttt{MADWiFi} implementa un sottoinsieme delle funzionalità in oggetto
  (cfr. \ref{sec:madwifi}).
\end{description}

\subsubsection{Svantaggi}
\begin{description}
 \item [Sforzo implementativo considerevole]:\\
  \begin{math} \Leftarrow \end{math}
  le nuove funzionalità hanno un prezzo alto, dovendo mantentere le informazioni
  relative agli stati di autenticazione associazione ed eventualmente
  sincronizzare la presenza su un BSS ad infrastruttura con i suoi periodi
  liberi da  contesa (cfr. \ref{sec:vincolitemporali} o
  \ref{sec:ottimizzazioni});\\
  \begin{math} \Leftarrow \end{math}
  per evitare la perdita dei \texttt{beacon}, indispensabili per il rispetto
  dei vincoli temporali, si è costretti ad una parziale reimplementazione di
  MAC (cfr. \ref{sec:vincolitemporali});\\
  \begin{math} \Leftarrow \end{math}
  il basso livello a cui si è costretti ad agire implica un'intrinseca
  complessità;\\
  \begin{math} \Leftarrow \end{math}
  la forma binaria nella quale i \textit{firmware} sono sovente distribuiti
  può costringere a noiose operazioni di ingegneria inversa.
 \item [Limitazioni prestazionali]:\\
  \begin{math} \Leftarrow \end{math}
  i vincoli temporali dovuti ad esigenze ordinarie (mantenimento
  dell'associazione) e aggiuntive (ritiro dei dati conservati dai BSS)
  costringono a salti indesiderati (cfr. \ref{sec:vincolitemporali}).
 \item [Specificità]:\\
  \begin{math} \Leftarrow \end{math}
  la dipendenza dalla piattaforma \textit{hardware} sottostante azzera la
  portabilità;\\
  \begin{math} \Leftarrow \end{math}
  lo sviluppo è possibile solo sui rari \textit{firmware} sufficientemente
  controllabili (cfr. \ref{sec:libertàdazione} e \ref{sec:atheros});\\
  \begin{math} \Leftarrow \end{math}
  il supporto alla funzionalità di risparmio energetico dal  lato
  \textit{client} come da quello BSS è indispensabile per  l'efficienza, (cfr.
  \ref{sec:risparmioenergetico} e \ref{gabola}).
\end{description}

\subsection{Sopra il \textit{driver}}
\label{sec:sopraildriver}

\subsubsection{Descrizione}
\label{sec:descrizione2}
Lo spirito con il quale questa soluzione viene concepita è quello di lavorare ad
alto livello in piena aderenza allo standard, favorendo la portabilità e
minimizzando, peraltro, gli sforzi implementativi.
La scelta di interazione con un generico \textit{driver} di sistema per ambienti
GNU/Linux risponde a queste esigenze obbligando alla rinuncia dell'effettività
dell'associazione multipla e al pagamento degli esigui costi di riassociazione.


\paragraph{Come}
Come accennato in \ref{sec:interpretazionedellostandard} ogni implementazione
lega indissolubilmente i concetti di autenticazione e riassociazione,
vanificando la speranza di mantenere autenticazioni multiple ed obbligando a
rincarare (spesso non di poco) i costi dei salti fra i BSS.
Un salto dal BSS1 al BSS2 consta quindi di questa sequenza di operazioni:
<dissociazione da BSS1, deautenticazione da BSS1, autenticazione con BSS2,
associazione con BSS2>.
Si tenga a mente che la persistenza delle autenticazioni a livelli
superiori (si veda \ref{80211i}) non dovrebbe essere compromessa a causa di
questa pratica.

\paragraph{Interfacce}
La portabilità perseguita trova espressione nell'uso delle \textit{Wireless
Extensions}, in qualità di interfacce unificate dei driver per la piattaforma
di riferimento.
Ancor di più, si propone di rendere conformi a queste API le stesse interfacce
virtuali, create per rappresentare ognuna delle partecipazioni ai BSS nella
maniera quanto più comoda e trasparente.

\subsubsection{Vantaggi}
\label{vantaggi2}
\begin{description}
 \item[Facilità implementativa]:\\
  \begin{math} \Leftarrow \end{math}
  il livello implementativo è alto e si interagisce in maniera onesta con il
  \textit{driver}.
 \item[Trasparenza]:\\
  \begin{math} \Leftarrow \end{math}
  la presentazione di interfacce aderenti alle \textsc{wext} oscura la presenza
  dell'implementazione ai livelli superiori (permettendo compatibilità, ad
  esempio, con \texttt{wpa\_supplicant}) e ne semplifica la gestione.
 \item[Portabilità]:\\
  \begin{math} \Leftarrow \end{math}
  per dialogare con il \textit{driver} sottostante si fa uso delle interfacce
  \textsc{wext}, disponibili su ogni piattaforma GNU/Linux.
\end{description}

\subsubsection{Svantaggi}
\label{svantaggi2}

\begin{description}
 \item [Perdita di dati in arrivo]:\\
  \begin{math} \Leftarrow \end{math}
  la perdita di autenticazione e associazione fra un salto e l'altro comporta
  reali assenze dai BSS che non possono essere evitate; il problema potrebbe
  essere invero gestito da strati di rete superiori ed affidabili (e.g. TCP).
 \item [Prestazioni mediocri]:\\
  \begin{math} \Leftarrow \end{math}
  i salti e le conseguenti operazioni di riautenticazione, riassociazione e
  risincronizzazione richiedono tempi nell'ordine dei centesimi di secondi. Per
  avere un'idea dell'entità di questo \textit{overhead} si pensi che lo
  stesso lasso di tempo potrebbe essere impiegato per la trasmissione di un
  centinaio di KB.

\end{description}
\section{Ottimizzazioni}
\label{sec:ottimizzazioni}
Si propone infine una breve trattazione dei fattori che possono essere
tenuti in considerazione per pianificare oculatamente le trasmissioni al fine
di ridurre i costi di gestione relativi alle soluzioni descritte in
\ref{sec:soluzioni}.
È però compito del lettore valutare, a seconda della soluzione scelta, la
rilevanza specifica che ognuno di essi riveste.

\begin{description}
 \item [Scadenze temporali]
 Come già esplicitato in \ref{sec:vincolitemporali} sussistono scadenze
 temporali la cui osservanza risulta essere necessaria (\textit{timeout} di
 autenticazione e associazione) o semplicemente conveniente (periodi di
 sincronizzazione dei BSS o di inizio del CFP).
 \item [Impatto dei salti]
 Il costo dei salti può essere calcolato per regolare la frequenza minima con la
 quale essi sono effettuati.
 \item [Caratteristiche delle comunicazioni]
 Date le alte latenze che possono essere prodotte dai salti di BSS, una
 politica di pianificazione delle comunicazioni basata su priorità\footnotemark
 può migliorare la qualità della schedulazione.
 \footnotetext{La qualità di servizio (QoS) suggerita è peraltro oggetto dei
 miglioramenti presenti in \cite{80211e}.}
 \item [Qualità dei BSS]
 Qualora le destinazioni di interesse siano raggiungibili tramite più di uno
 dei BSS di appartenenza, la scelta potrebbe essere banalmente influenzata
 dalla qualità che essi offrono (qualità del segnale, carico di lavoro
 \ldots~).

\end{description}

\clearpage

\section{Ringraziamenti}
\label{sec:ringraziamenti}
Vittorio Ghini, docente del corso di ``Laboratorio di programmazione di rete'',
per averci proposto l'occasione di condurre questo studio e per l'entusiasmo
che ha saputo trasmetterci.\\
Luciano Bononi, docente del corso di ``Sistemi di reti \textit{wireless}'', per
gli indirizzamenti offerti.\\
Sam Leffler, autore di MADWiFi, per le conferme a proposito della soluzione
sopra il \textit{firmware} con schede Atheros.\\
Jouni Malinen, autore di \texttt{wpa\_supplicant}, per i chiarimenti riguardo
alcuni aspetti dell'autenticazione di 802.11i.

\bibliography{Bibliografia}
\bibliographystyle{alpha}
\nocite{*}

\end{document}