source: doc/AssociazioneMultipla.tex @ 4

\documentclass[a4paper,10pt]{article}

\usepackage[italian]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[pdftex,bookmarks,colorlinks,linkcolor=red,urlcolor=blue]{hyperref}

% testo colorato
%\usepackage{color}
% riferimenti incrociati dinamici
%\usepackage{varioref}

% 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}

\begin{document}

\maketitle

\begin{abstract}
La diffusione di reti wireless è in forte crescita a causa della sua comodità e
della diffusa 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} e incrementandone l'affidabilità.

Lo studio intende quindi analizzare 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 wireless.
\end{abstract}

% \newpage
\section{Introduzione}
\label{sec:intro}

\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 wireless).

Nel presente documento 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 proposte risolutive, ma anche spunti
accessori.

\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
consentendo al \textit{client} di agire in qualità di ponte. 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 sfruttare
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 hanno
risentito dei 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.
\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 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}
Affinché una stazione mobile possa partecipare ad una rete wireless, le è fatto
obbligo di annunciare la sua presenza attraverso una procedura detta di
\textbf{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.

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 \textbf{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.

\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 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}. 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 precedentemente (nella 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.

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.

Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
anche degli annunci di 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.

\footnotetext{Ancora una volta è 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.}

In aggiunta a quanto detto, il 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à \texttt{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 sono ancora pochi i driver che si sono completamente uniformati a
questo insieme di interfacce, ma questa scelta è stata dettata dalla speranza
che esse diventino presto lo standard \textit{de facto}.

% TODO
% introduzione alla terminologia (managed, master, ad-hoc, monitor)

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 precisione 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 impostazioni) consentite dalla specifica implementazione di MAC.
Questo discorso diventa tanto più importante quanto la soluzione perseguita si
discosta dalla rigidità dello standard.

La revisione 802.11i, 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 però 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
controcorrente, e pertanto interessanti, vengono riportati da
\refname{guidadefinitiva}: Atheros\footnotemark e Broadcom.
\footnotetext{L'unico (dei due) provato dagli autori, con driver
\texttt{MADWiFi}.}

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


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

Nemmeno le più fedeli realizzazioni di 802.11 supportano la
preautenticazione (\refname{guidadefinitiva}), quindi i servizi di
autenticazione e associazione risultano indissolubilmente legati, vanificando
ogni possibilità di realizzare autenticazione multipla.
Di conseguenza, il superamento di questo limite, vincolante per realizzare
associazione multipla simultanea, sarà, in tutta la sua complessità, compito
dell'implementatore della soluzione proposta in \ref{manca}.

Un'altra eventuale 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 \texttt{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 \texttt{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 chipset Atheros}
\label{sec:atheros}

I \textit{chipset} \texttt{Atheros} equipaggiano i dispositivi 802.11 di alcuni
fra i maggiori produttori di \textit{hardware} per la connettività, come
\texttt{Linksys}, \texttt{NETGEAR}, \texttt{D-Link}, \texttt{Orinoco},
\texttt{Proxim} o \texttt{3Com}.

Il suo \textit{firmware} consente un grado di interazione di 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
\texttt{HAL} (\textit{Hardware Abstraction Layer}), interviene limitando le
radiofrequenze operative del dispositivo, continuando comunque a concedere le
libertà auspicate.

\subsubsection{Il driver MADWifi}
\label{sec:madwifi}
A partire dallo scorso anno la spinta innovatrice di \texttt{Atheros} ha avuto
riscontro anche nel progetto \texttt{MADWiFi}, i driver liberi per piattaforme
Linux sviluppati inizialmente da Sam Leffler. Le novità dal nuovo HAL sono state
sfruttate introducendo una serie di funzionalità di grande rilevanza. Il
carattere rivoluzionario rende il progetto, come spesso capita, piuttosto
instabile ma assai vitale.

L'aspetto indubbiamente più interessante è l'introduzione della modalità
\textbf{VAP} (\textit{Virtual Access Point}), grazie alla quale è possibile
virtualizzare il dispositivo creando molteplici interfacce di rete operanti
concorrentemente in maniera indipendente. 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à \texttt{managed} o \texttt{ad-hoc}. La
nota modalità \texttt{monitor} viene inoltre resa inseribile in una qualsiasi
delle configurazioni appena destritte, con la semplice aggiunta di un VAP di
questo tipo.\\
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.
% TODO
% Chiarire il concetto di DS?

Le interfacce virtuali create saranno esposte ed utilizzate in piena
trasparenza, essendo presentate come ordinarie interfacce di rete aderenti alle
\textit{Wireless Extensions}.
% TODO
% Comodità?

L'alto grado di controllo permesso dal \textit{firmware} \texttt{Atheros} si
propaga fino all'utente attraverso il \textit{driver} e i suoi numerosi
parametri specifici, che ricordiamo essere gestibili tramite il comando
\texttt{iwpriv} degli \textit{Wireless Tools}.

%   * interfaccia verso l'alto con wlanconfig


\section{Soluzioni}
\label{sec:soluzioni}

\section{Ottimizzazioni ulteriori per le scelte di swinging}
\label{sec:ottimizzazioni}

\section{Bibliografia}
\label{sec:bibliografia}

\section{Ringraziamenti}
\label{sec:ringraziamenti}

\end{document}