tesi

Facoltà di Ingegneria
Corso di Studi in Ingegneria delle Telecomunicazioni
tesi di laurea
Configurazione di nodi wireless con
supporto della qualità del servizio
Anno Accademico 2003/2004
Relatore
Ch.mo Prof. G. Ventre
correlatori
Ing. M. D’Arienzo
Ing. M. Ficco
candidato
Domenico Beneduce
matr. 39/1963
Configurazione di nodi wireless con supporto della qualità del servizio
Indice
Introduzione
6
Capitolo 1. Obiettivo della tesi: progetto iniziale
10
1.1
1.2
1.3
11
13
14
L’idea iniziale
La realizzazione
Il Sequence Diagram
Capitolo 2. Qualità del Servizio su Internet: IntServ e DiffServ
16
2.1
La qualità del servizio
17
2.2
2.2.1
2.2.2
2.2.3
2.2.4
Il
Il
Il
Il
Il
18
21
23
23
24
2.3
2.4
2.4.1
2.4.2
2.5
2.5.1
2.5.2
L’architettura di un Router nel modello Integrated Services
Le classi di servizio
Controlled Load Service (CLS)
Guaranteed Service (GS)
Tipologie di applicazioni
Applicazioni real time
Applicazioni Elastiche
24
26
26
27
28
28
31
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
Il modello Differentiated Services
Il condizionamento del traffico
Classificazione dei pacchetti
Profilo del Traffico: Meter
Marker
Sheduler
32
34
35
36
37
38
Modello Integrated Services
Protocollo RSVP
modulo Admission Control
modulo Packet Classifier
modulo Packet Scheduler
2
Configurazione di nodi wireless con supporto della qualità del servizio
2.6.6
2.6.7
2.6.8
2.6.9
2.6.10
2.6.10.1
2.6.10.2
2.6.10.3
Policing
Policy
Shaper
Dropper
Per Hop Behavior (PHB)
Expedited Forwarding (EF)
Assured Forwarding (AF)
Best Effort (BE)
39
39
40
41
41
42
43
44
2.7
Il protocollo RTP
45
Capitolo 3. La QoS negli end-system
46
3.1
La qualità de servizio sulle reti IP
46
3.2
L’influenza del sistema operativo
53
Capitolo 4. Reti wireless 802.11
62
4.1
4.1.1
4.1.2
4.1.3
Il protocollo IEEE 802.11
QoS su reti wireless 802.11
Il MAC 802.11
Il MAC 802.11e
62
65
65
67
4.2
4.2.1
4.2.2
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.3
4.2.4
4.2.5
4.2.5.1
Procedure di handoff
Strategie di attivazione dell’handoff
Schemi di controllo dell’handoff
Mobile Controlled Handoff (MCHO)
Network Controlled Handoff (NCHO)
Mobile Assisted Handoff (MAHO)
Network Assisted Handoff (MAHO)
Schemi di attivazione della connessione
Schemi di trasferimento della connessione
L’handoff a livello Rete
Il protocollo IP e gli handoff
70
72
73
74
74
75
75
77
77
78
79
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
Il protocollo Mobile IP
Il funzionamento di Mobile IP
Meccanismi di Agent Discovery
Cambiamento di rete
Procedura di registrazione presso l’Home Agent
L’IP Mobility ed i messaggi ARP
81
83
89
90
91
96
4.4
4.4.1
4.4.2
Cellular IP: un approccio all’Host Mobility
Introduzione a Cellular IP
Approccio alternativo alla gestione degli utenti mobili
98
99
104
3
Configurazione di nodi wireless con supporto della qualità del servizio
4.4.3
4.4.4
4.4.4.1
4.4.4.2
4.4.4.3
4.4.4.4
4.4.5
4.4.5.1
4.4.5.2
4.4.5.3
4.4.5.4
4.4.6
4.4.6.1
4.4.6.2
4.4.6.3
4.4.7
Modello di rete ad accesso wireless
Cellular IP
Meccanismi di mapping: Paging Caches e Routing Caches
Paging di Cellular IP
Routing di Cellular IP
Handoff di Cellular IP
Problemi relativi al disegno del protocollo
Indirizzamento e Migrazione
Pacchetti di controllo
Configurazione dei nodi
Algoritmi dei nodi
Realizzazione del protocollo
Realizzazione della temporizzazione
Realizzazione delle Caches
Realizzazione del Paging
Conclusioni su Cellular IP
109
113
114
118
123
125
129
129
130
131
132
133
133
135
136
137
Capitolo 5. Access Point con supporto della qualità del servizio: HostAP e HostQs
139
5.1
HostAP
140
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
HostQs: Differenziazione del traffico in WLAN
Introduzione a HostQs
QoS dell’IEEE 802.11e: la funzione EDCA
Differenziazione del traffico a livello LLC
L’implementazione di HostQs
Risultati del test
Conclusioni e sviluppi futuri
143
144
145
145
150
152
159
Capitolo 6. Sviluppo software e misurazioni
161
6.1
Modifica del codice di Queue Manager
168
6.2
6.2.1
6.2.2
Misurazioni
Studio dei parametri statistici
Calcolo della varianza approssimata
170
172
172
Appendice A. Codici dei programmi
176
A.1
A.2
A.3
A.4
176
179
180
180
Codice del programma Server
Codice del programma Client
Codice della libreria di servizio
Il Makefile
4
Configurazione di nodi wireless con supporto della qualità del servizio
Appendice B. How-to di installazione
182
B.1
B.2
B.3
B.4
B.5
B.6
182
183
186
187
189
190
Installazione del sistema di base
Compilazione del kernel
Installazione di HostAP e HostQs
Configurazione delle interfacce
Impostazione del DHCP
Impostazione del NAT
Bibliografia
192
5
Configurazione di nodi wireless con supporto della qualità del servizio
Introduzione
In uno scenario in cui la dimensione dei computer portatili diventa sempre più
ridotta e la loro presenza sempre più diffusa grazie anche ad un’accessibilità dei
costi quasi totale, si rende necessaria la possibilità di collegarsi ad una rete - nel
più classico dei casi ad Internet - in maniera semplice, veloce e con pochi click e
soprattutto senza l’impiego di fili.
Una possibilità di collegamento senza fili è già offerta in alcuni luoghi - ancora
pochi in realtà - come aeroporti o grandi alberghi dove sono presenti zone
fornite di un servizio di copertura wireless chiamate hot spot; tale servizio è
offerto dai principali gestori di telefonia mobile e per lo più a scopo
pubblicitario.
In verità l’accesso alla rete è efficiente ma abbastanza macchinoso perché c’è
bisogno dell’impostazione di alcuni parametri iniziali che per semplicità di
accesso o solamente per comodità, sarebbe bene che fosse eseguita in maniera
trasparente all’utente.
In altre parole, la sola presenza di un determinato computer portatile in una
rete dovrebbe essere quasi sufficiente a far partire automaticamente un
processo di configurazione di parametri base per la connessione alla rete locale
più vicina e, attraverso questa, a Internet.
In questa tesi vengono proposti alcuni sistemi per effettuare la connessione
wireless in poco tempo e se possibile senza impostazione manuale dei
6
Configurazione di nodi wireless con supporto della qualità del servizio
parametri; ovviamente un minimo di configurazione sarà comunque necessaria
e inoltre si immagina che la presenza di alcuni sistemi hardware e software
venga diffusa in aree più estese di quelle classicamente associate alle LAN.
Ma il cuore del presente studio è basato sulla configurazione di un Access Point
mobile che implementi la gestione della qualità del servizio: attraverso elementi
hardware particolari e soprattutto con l’aiuto di prodotti software studiati e
modificati ad hoc laddove necessario, è possibile fare in modo che un normale
computer portatile (un laptop o un palmare) possa essere configurato per
funzionare come un nodo di rete, dando la possibilità a qualunque altro nodo
all’interno di un certo raggio e fornito di una normale scheda di rete wireless, di
collegarsi alla LAN più vicina - volendo a Internet - proprio come se a gestire la
comunicazione fosse un normale Access Point.
Il nodo viene configurato prevedendo un supporto della qualità del servizio,
ossia la possibilità di creare classi di utenti, ognuna delle quali associata ad un
livello di priorità.
La differenziazione tra le classi, ovvero la decisione del livello di precedenza, è
stabilita attraverso l’analisi di un determinato campo dell’header IP; ora,
sebbene il campo ToS (Type of Service) sia un byte dedicato proprio a scopi di
questo tipo, è sembrato molto più utile distinguere un utente attraverso il suo
identificativo più univoco: l’indirizzo IP.
Una volta che un pacchetto sia giunto al portatile-Access Point, invece di essere
immediatamente servito, viene inviato ad un blocco studiato apposta che si
occupa di leggere l’indirizzo IP, decidere quale priorità assegnarvi, quindi riporre
il pacchetto nella coda relativa a quel livello di precedenza.
A questo punto entra in gioco uno schedulatore che dà al pacchetto un ritardo
7
Configurazione di nodi wireless con supporto della qualità del servizio
proporzionale alla dimensione della sua coda e a quelle delle code con priorità
più alta; solo dopo che il pacchetto avrà risalito tutta la fila, verrà rimandato al
punto da cui era stato prelevato e sarà quindi pronto per essere inoltrato.
Il blocco dei pacchetti (in altre parole la gestione della qualità del servizio)
avviene quindi all’interno del nostro nodo in un modo semplice quanto efficace.
L’efficienza del funzionamento del sistema viene testato con l’aiuto di piccoli
programmi pensati per questo scopo: una serie di programmi client generano
flussi di dati, gli assegnano una priorità e li inviano all’indirizzo di un programma
server che raccoglie informazioni statistiche sui tempi di consegna e sui ritardi
subiti dai dati.
Vengono inoltre proposti dei sistemi alternativi per la gestione della qualità del
servizio basati su idee innovative che tendono a sfruttare a pieno tutte le
potenzialità della rete.
Dato il crescente interesse verso le tecnologie senza filo, gli studi e le idee
esposte in questa tesi rappresentano un buon punto di partenza per sviluppi
futuri: in una visione più generale in cui la presenza di computer portatili
configurati come Access Point sia molto diffusa, lo scenario globale cambia
completamente. Infatti l’accesso wireless può essere fornito non più da un
singolo hot spot fissato in un punto ben definito dello spazio ma potrebbe
essere affidato ad utenti mobili, dando la possibilità di estendere la zona di
copertura wireless su un’area tanto estesa quanto il numero degli Access Point
permetta. In altre parole, non si può dire a priori quanto sia estesa una LAN
wireless perché in ogni punto può esserci copertura fornita da un Access Point
che a sua volta si trova nella zona di copertura di un altro Access Point.
8
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 0.1: Scenario attuale
Figura 0.2: Possibile scenario futuro
Il disegno generale nel quale si inquadra questo studio è interessante quanto
complesso e nel seguito sarà illustrato nei dettagli.
In effetti, un computer portatile con queste caratteristiche sbiadisce la
distinzione fra terminali e nodi di rete e può essere impiegato nelle situazioni
più disparate, cosa che la fantasia e la capacità di degli esperti del mondo
dell’informatica non tarderà a notare.
9
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 1
Obiettivo della tesi: progetto iniziale
L’idea che porta alla realizzazione di questo studio di tesi si presenta ambiziosa
ed allo stesso tempo di notevole interesse, soprattutto in un epoca come quella
attuale, dominata dalla presenza sempre più assidua - e qualche volta anche
asfissiante - di apparecchi elettronici delle più svariate forme e dimensioni, che
vanno dai personal computer nel classico formato monitor-case-tastiera, ai
moderni laptop, ai palmari, ai telefoni cellulari di ultima generazione.
Qualunque sia la natura del sistema elettronico, non mancherà mai una
caratteristica fondamentale: la possibilità di un collegamento senza fili verso
uno o più sistemi dotati della stessa tecnologia o verso una rete locale LAN e
verso la rete globale Internet.
La capacità di collegamento senza fili a un entità esterna che fino a poco fa
restava prerogativa esclusiva dei telefoni cellulari, è ormai una caratteristica
richiesta a qualunque computer anche non portatile.
Così diventa corredo standard per uffici, aeroporti, hotel e altre strutture
concepite per ospitare risorse umane, l’offerta di un servizio di accesso wireless
per tutti coloro che lo richiedano.
Da qui nascono tante altre problematiche di realizzazione basate soprattutto
10
Configurazione di nodi wireless con supporto della qualità del servizio
sulla gestione delle politiche di alcuni sistemi (nel caso più comune Internet)
che erano stati pensati per la comunicazione di utenti inquadrati in uno scenario
ben determinato e che si trovano oggi a dover essere convertiti per fornire
servizi in scenari del tutto diversi, come le reti wireless.
Nasce tra gli altri il problema della differenziazione degli utenti, comunemente
identificato con la realizzazione del supporto della qualità del servizio (QoS).
Proprio in questa direzione nasce il presente progetto che anche se non
realizzato in ogni suo punto, dà un’idea di una buona politica di gestione della
QoS e fornisce un sistema funzionante di differenziazione degli utenti che può
essere utilizzato da solo o può rappresentare un buon punto di partenza per
studi futuri.
1.1 L’idea iniziale
Lo scenario complessivo nel quale si inquadra questa tesi comprende una serie
di elementi, a volte anche indipendenti gli uni dagli altri, ma che messi insieme
danno una visione generale assolutamente sensata.
Si parta immaginando un dispositivo hardware wireless, che può essere
governato da qualsivoglia tecnologia; per fissare le idee si pensi ad un elemento
Bluetooth capace di gestire una scheda di rete: tale dispositivo sarà l’elemento
fondamentale per il riconoscimento di un utente.
Il dispositivo fornisce una chiave, ovvero un elemento univocamente associato
al possessore e leggendo dati dalla scheda di rete, invia ad un Access Point una
serie di dati, tra i quali:
11
Configurazione di nodi wireless con supporto della qualità del servizio
•
l’indirizzo MAC della scheda di rete che gestisce;
•
un ID, cioè la chiave che identifica univocamente un utente.
Quest’ultimo dato può essere impostato dall’esterno fornendo così un duplice
vantaggio:
•
il possessore del dispositivo può accedere alla rete con la stessa QoS
utilizzando anche terminali diversi;
•
lo stesso dispositivo può essere usato da utenti diversi, ognuno dei quali
può usufruire di una propria qualità del servizio.
Figura 1.1: Collegamento tra client e Access Point
Nel caso in cui l’Access Point sia già a conoscenza della ID, potrebbe assegnare
a quell’utente un livello di priorità alta, cioè dare al traffico generato da
quell’utente la precedenza rispetto al traffico generato da un cliente con una ID
sconosciuta.
Si verrà quindi a creare una tabella che associa ad ogni indirizzo MAC un certo
livello di priorità:
12
Configurazione di nodi wireless con supporto della qualità del servizio
ID
Già conosciuta
Indirizzo MAC
Priorità
ID1212
Sì
11-22-33-44-55-66
Alta
ID3434
Sì
77-88-99-00-AA-BB
Media
ID5656
No
00-DD-EE-FF-11-22
Bassa
ID7878
No
33-44-55-66-77-88
Bassa
Tabella 1.1: Associazione ID/priorità
C’è bisogno adesso della scelta di un criterio di associazione della ID/priorità
con un parametro caratteristico dello standard di comunicazione IEEE802.11 per
poter
rendere
la
gestione
della
qualità
del
servizio
effettivamente
implementabile.
Benché questa scelta possa essere indirizzata verso tante direzioni, si è scelto di
associare la ID/priorità al parametro che negli standard di comunicazione
rappresenta l’identificativo univoco per antonomasia: l’indirizzo IP.
1.2 La realizzazione
Per associare una ID/priorità all’indirizzo IP, si richiede un servizio speciale al
DHCP (Dynamic Host Configuration Protocol): quando richiesto, questo
protocollo non fornirà semplicemente il primo indirizzo IP disponibile ma
effettuerà una scelta: in base alla ID/priorità rilevata, darà all’utente un indirizzo
che sarà associato ad una casse di servizio.
Supponendo per fissare le idee che le classi di servizio siano 3, all’utente verrà
dato:
13
Configurazione di nodi wireless con supporto della qualità del servizio
•
un indirizzo IP tra X.X.X.1 e X.X.X.10 per una classe a priorità alta;
•
un indirizzo IP tra X.X.X.11 e X.X.X.30 per una classe a priorità media;
•
un indirizzo IP tra X.X.X.11 e X.X.X.30 per una classe a priorità bassa.
Le tre classi contengono un numero di possibili clienti che è proporzionale al
proprio livello di priorità: la prima classe avrà 10 possibili utenti, la seconda
classe 20 e infine la classe a priorità più bassa avrà possibili 30 utenti.
Tale ripartizione del numero di possibili utenti risulta lecita se si immagina che
gli utenti con priorità alta siano minori in numero rispetto a quelli con priorità
bassa.
Se una classe risulta saturata mentre le altre possono ancora accettare
connessioni, si potrà scegliere di assegnare un indirizzo di classe superiore o
inferiore.
ID/priorità
IP associato
utenti possibili
Alta
IP X.X.X.1 - X.X.X.10
10
Media
IP X.X.X.11 - X.X.X.30
20
Bassa
IP X.X.X.31 - X.X.X.60
30
Tabella 1.2: utenti per ogni classe di servizio
1.3 Il Sequence Diagram
Il Sequenze Diagram graficizza brevemente i passi per realizzare l’obiettivo
proposto.
Le ultime fasi del Server relative a HostAP e Queue Manager verranno
14
Configurazione di nodi wireless con supporto della qualità del servizio
analizzate nei dettagli nei relativi capitoli quando si esporranno tutte le
caratteristiche di questi prodotti software.
Figura 1.2: il Sequence Diagram
15
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 2
Qualità del servizio su Internet: IntServ e DiffServ
La rete Internet attuale offre un solo servizio di trasporto dei dati che viene
chiamato best effort. Questo tipo di servizio non fornisce nessuna garanzia sul
comportamento end-to-end della rete, dato che non è possibile fare alcun tipo
di ipotesi sulla banda disponibile, sul ritardo di transito o sulla corretta consegna
dei singoli pacchetti, se non su base statistica.
L’utilizzo di applicazioni con esigenze real time rimane quindi confinato
nell’ambito delle reti locali fino a che la rete Internet non sarà in grado di
garantire qualche forma di qualità di servizio.
Le alternative principali per fornire servizi di trasporto garantiti sono
essenzialmente due:
•
sovradimensionare la rete Internet in modo che anche nelle condizioni di
traffico elevato vi siano sempre risorse a sufficienza per soddisfare tutte
le richieste;
•
introdurre nella rete nuovi meccanismi per garantire, controllare e
tariffare la qualità richiesta, quindi suddividere i servizi disponibili per il
trasporto, differenziandoli in base alla qualità che possono fornire e
consentire l’utilizzo di tutta una nuova serie di servizi commerciali che
non possono prescindere da opportune politiche di tariffazione e garanzia
di qualità.
16
Configurazione di nodi wireless con supporto della qualità del servizio
Con riferimento agli standard IETF (Internet Engineering Task Force) sono state
proposte una serie di modifiche necessarie per far evolvere rete Internet attuale
verso una rete in grado di fornire un supporto di QoS.
2.1 La qualità del servizio
Il compito principale di una rete di telecomunicazioni è il trasporto
dell’informazione da un punto all’altro della rete stessa. Le informazioni
trasportate sono soggette ad una notevole variabilità; quindi per uno
sfruttamento
ottimale
delle
risorse
di
rete,
nasce
l’esigenza
di
una
diversificazione nel trattamento riservato ai singoli flussi di dati.
È evidente che applicazioni di video-conferenza che comportano la generazione
di traffico dati audio e video con vincoli di real time, hanno esigenze molto
diverse da applicazioni come il trasferimento di file o il servizio di posta
elettronica che possono invece accettare un ritardo nella consegna dei dati ma
assolutamente non tollerano perdite.
Si introduce il termine Qualità del Servizio (QoS) per individuare una
corrispondenza tra le esigenze di una data applicazione e il servizio di trasporto
che può essere fornito dalla rete di telecomunicazioni.
Nel seguito ci si riferirà al termine Qualità del Servizio intendendo la capacità
della rete nel fornire e garantire una serie di servizi di trasporto diversificati in
termini di banda utilizzabile, ritardo end-to-end, jitter e tasso di errore.
Nella rete Internet attuale l’unico servizio disponibile è quello di best effort, il
cui paradigma si basa sul trasporto dei datagrammi IP quando c’è banda
disponibile, sull’accodamento quando ci sono buffer liberi e sullo scarto quando
le risorse di rete sono esaurite.
17
Configurazione di nodi wireless con supporto della qualità del servizio
2.2 Il Modello Integrated Services
Le risorse messe a disposizione dalla rete Internet sono essenzialmente i router
e la banda trasmissiva dei link di interconnessione tra le entità costituenti la
rete stessa. I router sono caratterizzati da una determinata capacità elaborativa
e da buffer che consentono di conservare i dati tutte le volte che non è possibile
eseguire un loro reinstradamento immediato.
Nel documento “Integrated Service in the Internet Architecture” [1], redatto in
ambito IETF, si propone un’estensione dell’architettura di Internet e dei
protocolli utilizzati per realizzare l’integrazione di servizi differenziati per il
trasporto di flussi.
Questo modello, a cui ci si riferirà in seguito con il nome IntServ, si poggia su
due concetti fondamentali:
•
la scelta del ritardo come il parametro privilegiato per definire la QoS: si
è dimostrato che un limite più o meno rigido sul ritardo massimo
sperimentatile dai singoli pacchetti di dati consente effettivamente di
fornire servizi di trasporto garantiti in termini di banda utilizzabile, ritardo
end-to-end, jitter e tasso di errore;
•
la scelta del dominio a cui applicare il concetto di classe di servizio:
nell’Internet attuale, i router che si occupano di instradare i datagrammi
dalla
sorgente
alla
destinazione,
forniscono
un
trattamento
18
Configurazione di nodi wireless con supporto della qualità del servizio
indifferenziato secondo una disciplina di accodamento di tipo FIFO (first
in, first out), rendendo di fatto impossibile una qualunque previsione non
statistica sul ritardo o sulle perdite end-to-end.
Dato che nell’insieme di datagrammi trasportati è possibile individuare diversi
livelli di correlazione, il modello IntServ introduce il concetto di flusso, inteso
come l’insieme dei datagrammi scambiati in seguito alla stessa attività d’utente,
individuabili in modo univoco e caratterizzati dalla stessa Qualità del Servizio.
Si osservi che il flusso rappresenta la granularità minima del modello IntServ,
dato che è l’insieme minimo identificabile di datagrammi IP per i quali è
possibile fornire una desiderata QoS.
In aggiunta, per modellare le trasmissioni multicast si introduce anche il
concetto di sessione, definita come l’insieme di uno o più flussi aventi una
particolare destinazione ed un dato protocollo.
Per una caratterizzazione del flusso si usa il Filter Specificator formato da:
•
l’indirizzo IP Sorgente e Destinazione,
•
il tipo di protocollo di trasporto (TCP, UDP, etc.)
•
i porti Sorgente e Destinazione (nel caso di IPv6 è stato previsto
nell’header un campo apposito di 24 bit chiamato flow-label).
Si definisce un modulo, il Packet Classifier, che si occupa di discriminare i flussi
provenienti da applicazioni distinte; esso opera senza imporre variazioni ai
protocolli utilizzati per il trasporto, dato che le informazioni necessarie sono
contenute nell’header del datagramma IP.
19
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.1: il Filter Specificator
Il modello IntServ prevede di associare ad ogni flusso un oggetto chiamato Flow
Descriptor [2] che è formato dalla coppia Flow Specificator (Flow Spec) e Filter
Specificator.
Il FlowSpec è composto da, due insiemi distinti di parametri che permettono di
caratterizzare il flusso in termini di qualità del servizio richiesta e profilo di
traffico:
•
TSpec - Traffic Specification [3]: descrive le caratteristiche del flusso dati
generato dal nodo trasmettitore, fornendo i parametri di un modello di
occupazione di banda noto come token bucket [3]; nel caso del ricevitore
(fruitore del servizio) il TSpec definisce il livello di traffico per cui si vuole
veder garantita una certa QoS;
•
RSpec - Service Request Specification [3]: specifica la qualità del servizio
che l’applicazione ricevente il flusso dati vorrebbe veder garantita; l’host
fruitore del servizio specifica la banda minima di cui ha bisogno, il ritardo
e la perdita massima tollerabile per i pacchetti dati.
20
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.2: il Flow Descriptor
Una volta stabilite le basi logiche su cui poggia il modello Integrated Services
(flusso e massimo ritardo end-to-end) restano da definire i componenti da
aggiungere alla struttura di lnternet per ottenere la Qualità del Servizio.
Si individuano perciò quattro blocchi fondamentali:
•
un protocollo di segnalazione per la prenotazione delle risorse (attivo su
Host e Router);
•
un modulo per la verifica delle richieste fatte alla rete: Admission Control
Routine (Router);
•
un modulo per suddividere il traffico in flussi distinti secondo la QoS, il
cosiddetto Packet Classifier (Router);
•
un modulo per gestire la QoS richiesta ai vari flussi: il Packet Scheduler
(Router);
2.2.1 Il Protocollo RSVP
Il protocollo RSVP (Resource ReSerVation Protocol) [2] è un protocollo di
segnalazione a livello IP utilizzato per comunicare in modo dinamico all’interno
di una rete la richiesta di servizi di trasporto differenziati per trasmissioni
unicast o multicast: tramite una serie di messaggi è possibile dichiarare le
21
Configurazione di nodi wireless con supporto della qualità del servizio
esigenze in termini di risorse di rete richieste da un singolo flusso, esplicitare
alla rete la volontà di riservare queste risorse e comunicare quando le risorse
non sono più necessarie. Sarà poi compito del modulo di controllo del traffico
rendere operative queste richieste.
Quando un’applicazione ha intenzione di trasmettere dei dati a cui attribuire una
certa QoS è necessario comunicare ai ricevitori ed alla rete questa intenzione:
viene inviato un messaggio chiamato PATH che definisce un percorso tra
trasmettitore e ricevitore, comunicando al ricevitore e a tutti i router attraversati
le esigenze del flusso dati generato dall’applicazione.
Il ricevitore potrà a questo punto richiedere di riservare delle risorse inviando a
ritroso un messaggio di RESV, rendendo esplicita la richiesta di risorse, che
affinché diventi operativa deve essere accolta da tutti i router che collegano il
trasmettitore al ricevitore.
Si intuisce l’importanza di fissare una connessione virtuale identificata
univocamente dal percorso effettuato dal messaggio di PATH: in questo modo
viene meno il paradigma classico delle comunicazioni IP di tipo connectionless,
perché per garantire la qualità del servizio si deve fissare un percorso ed
allocare nei router attraversati le risorse necessarie.
I router RSVP conservano le informazioni riguardanti la qualità del servizio
assegnata ad ogni flusso con una tecnica di soft-state, quindi se ricevitore e
trasmettitore non inviano periodicamente i messaggi di RESV e di PATH le
risorse vengono liberate automaticamente allo scadere di un timeout.
Questa tecnica rende il protocollo RSVP estremamente robusto nei riguardi di
eventuali perdite di messaggi di servizio e flessibile nella gestione dinamica di
variazioni di percorso o qualità del servizio.
22
Configurazione di nodi wireless con supporto della qualità del servizio
Le caratteristiche principali di RSVP possono essere riassunte nei seguenti
punti:
•
protocollo receiver initiated;
•
indipendente dai meccanismi di routing: i messaggi di controllo di RSVP
sono incapsulati in pacchetti IP (Type 46) ed instradati come normali
pacchetti dati in modo che ci sia una completa indipendenza dai
meccanismi di routine)
•
utilizzo di stati soft;
•
disponibilità di diversi stili di prenotazione;
•
Compatibile sia con IPv4 che con IPv6
2.2.2 Il modulo Admission Control
Questo modulo si occupa di verificare se la richiesta di QoS per un dato flusso si
può accettare senza che vengano meno le risorse precedentemente allocate.
In pratica ogni volta che ad un nodo arriva una richiesta di prenotazione di
risorse viene presa una decisione per accettare o rifiutare la richiesta.
Questa funzione è particolarmente delicata perché scelte troppo conservative
porteranno ad uno sottosfruttamento delle risorse disponibili, mentre una scelta
poco
conservativa
potrebbe
far
venir
meno
la
qualità
del
servizio
precedentemente garantita.
2.2.3 Il modulo Packet Classifier
Il compito di questo modulo è di suddividere i pacchetti IP che arrivano alle
23
Configurazione di nodi wireless con supporto della qualità del servizio
interfacce di ingresso in classi opportune in base a criteri locali. Un router di
backbone cercherà di suddividere i flussi in poche classi per favorire
l’aggregazione e ridurre il numero di entità distinte da trattare, mentre router
più vicini alla periferia potranno adottare criteri diversi permettendo una
maggior differenziazione delle classi.
2.2.4 Il modulo Packet Scheduler
Questo modulo rappresenta la parte più critica di tutto il processo di allocazione
delle risorse perché dalla sua realizzazione dipende l’efficienza dell’intero
meccanismo
di
controllo
del
traffico:
la
funzione
principale
consiste
nell’instradare i vari flussi di pacchetti utilizzando degli opportuni sistemi di code
(Simple Priority Queuing, Class Based Queuing, Weigheted Fair Queuing [4]) in
modo da garantire un trattamento differenziato ai singoli flussi.
Lo Scheduler può anche svolgere la funzione di policing, cioè esercitare un
controllo per impedire che un host immetta in rete un traffico non conforme a
quello dichiarato.
2.3 L’architettura di un Router nel Modello Integrated Services
In figura 2.3, dove viene mostrata l’architettura di riferimento di un Router in
grado di supportare il modello Integrated Services; sono individuabili due
sezioni distinte: il Background Code ed il Forwarding Path posti rispettivamente
sopra e sotto la riga orizzontale.
24
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.3 Architettura di un Router nel Modello ISI
Il Forwarding Path opera su ogni pacchetto IP e rappresenta la parte operativa
del processo di routing. Il blocco di Internet Forwarding analizza l’header di tutti
i pacchetti IP eseguendo una loro classificazione utilizzata dal successivo
modulo di Packet Scheduler.
Il Background Code è un’insieme di routine che si occupano di gestire le
strutture dati necessarie al corretto funzionamento del Forwarding Path. Si
possono individuare le seguenti funzioni:
•
Routing Agent: implementa i protocolli di routing gestendo gli opportuni
database;
•
Reservation Setup Agent: implementa il protocollo per la gestione della
prenotazione delle risorse; il modulo di Admission Control verifica se le
richieste di QoS possono essere soddisfatte e successivamente vengono
configurati il Packet Classifier ed il Packet Scheduler;
25
Configurazione di nodi wireless con supporto della qualità del servizio
•
Management Agent: si occupa del network management: admission
control policies, controlled link sharing, etc.
Il router risulta quindi l’elemento fondamentale per garantire il controllo del
traffico a livello di rete. Nello svolgere questa funzione deve poter identificare i
singoli flussi per riservare ad ognuno di essi un trattamento ben determinato
per garantire il rispetto degli impegni presi nei confronti degli altri elementi della
rete. Si definisce stato del router la sua conoscenza sul trattamento da riservare
ai singoli flussi dati che lo interessano.
2.4 Le classi di servizio
Il gruppo di lavoro IntServ dell’IETF ha definito tre classi di servizio [1] che
permettono di identificare tre diversi scenari di comportamento end-to-end. Di
queste classi solo due implementano un servizio vero e proprio, in quanto la
classe tradizionale Best Effort, che può comportare ritardi e perdite impredicibili
di pacchetti, rappresenta il servizio che si riceve in assenza di richieste
specifiche.
2.4.1 Controlled Load Service (CLS)
La classe di servizio Controlled Load Service [5] fornisce ad un’applicazione un
comportamento end-to-end che approssima quello ottenibile da una rete non
congestionata con servizio best effort. Facendo l’ipotesi di assenza di
malfunzionamenti della rete, l’applicazione può ritenere che:
•
la rete con servizio CLS garantisce una percentuale di perdita di pacchetti
26
Configurazione di nodi wireless con supporto della qualità del servizio
molto vicina al tasso di errore del mezzo trasmissivo, dato che non si
verificano più perdite dovute alla congestione;
•
il ritardo medio dei pacchetti non si scosterà molto dal ritardo minimo
che consiste nel ritardo dovuto alla propagazione del segnale nel mezzo
trasmissivo più il tempo di processamento delle informazioni nei
dispositivi di rete attraversati.
Per gestire il servizio CLS è necessario che l’applicazione fornisca alla rete le
informazioni sul traffico che intende generare (Tspec), in modo che lungo il
percorso fatto dai dati siano allocate risorse sufficienti a soddisfare la QoS
richiesta.
Il servizio CLS è stato introdotto per essere di supporto a tutta una serie di
applicazioni che subiscono un degrado notevole delle prestazioni in condizione
di overload ma che non richiedono vincoli stringenti sul ritardo massimo
sperimentabile dai dati.
2.4.2 Guaranteed Service (GS)
Il servizio Guaranteed Service [6] assicura un ritardo massimo di consegna dei
pacchetti IP (ritardo tra sorgente e destinazione) non superiore al guaranteed
delivery time, garantendo allo stesso tempo l’assenza di perdite di pacchetti
dovute ad overflow dei buffer dei router. Per ottenere questo risultato è
necessario fissare il percorso che verrà fatto dai dati ed avere dei dispositivi di
rete in grado di supportare il Guaranteed Service lungo tutta la tratta
interessata.
27
Configurazione di nodi wireless con supporto della qualità del servizio
Il ritardo sperimentato da un pacchetto che viaggia lungo una rete è composto
da due parti: un ritardo fisso (transmission delay), dovuto alla distanza ed ai
tempi fissi di elaborazione dei dispositivi di rete, ed un ritardo dovuto all’attesa
per la presenza di buffer nei router (queuing delay).
Il transmission delay dipende dal percorso che viene scelto tra sorgente e
destinazione, mentre il queuing delay dipende dal Guaranteed Service, che
permette di impostare un valore massimo per il tempo di attesa in coda una
volta che si conoscono le caratteristiche del traffico.
Questo tipo di servizio è stato pensato per tutte quelle applicazioni che sono
intolleranti ad un ritardo eccessivo dei pacchetti: si pensi alle applicazioni di
video e audio playback che usano codifiche per le quali i datagrammi arrivati
oltre un certo ritardo non sono più utilizzabili per la riproduzione real time.
2.5 Tipologie di applicazioni
Per meglio caratterizzare la qualità del servizio è necessario focalizzarsi sulle
esigenze delle singole applicazioni.
In linea di principio la quantità che più pregiudica le prestazioni di una
applicazione è il ritardo che ogni pacchetto dati subisce nel transitare attraverso
la rete. Le applicazioni a seconda dell’effetto del ritardo dei pacchetti possono
essere suddivise in Applicazioni real time ed Applicazioni Elastiche.
2.5.1 Applicazioni real time
Si definiscono applicazioni real time tutte le applicazioni che impongono un
28
Configurazione di nodi wireless con supporto della qualità del servizio
limite massimo al ritardo subito da ogni pacchetto dati: se un pacchetto arriva
con eccessivo ritardo non è più utilizzabile dall’applicazione e quindi viene
scartato perché privo di valore.
Un classico esempio di applicazioni real time sono le applicazioni di signal
playback che svolgono la funzione di riprodurre un segnale generato da una
sorgente e trasportato dalla rete fino alla destinazione; il segnale trasformato in
forma numerica e successivamente segmentato in pacchetti dati, viene
trasportato dalla rete che introduce un ritardo aleatorio tra pacchetto e
pacchetto. Nel ricostruire il segnale originale, il ricevitore deve rispettare dei
vincoli temporali e quindi deve conoscere il ritardo massimo accumulabile da
ogni pacchetto per ritardare la riproduzione del segnale della stessa quantità
(Offset Delay).
Il ritardo massimo può essere dichiarato a priori se è disponibile una
conoscenza della rete, oppure ricavato dall’analisi dei ritardi dei singoli pacchetti
in modo da poter variare l’offset delay in modo dinamico.
Va precisato che le applicazioni di playback si possono suddividere in tolleranti
se accettano una variazione del ritardo massimo o intolleranti se il ritardo
massimo deve essere fissato perché non è consentita nessuna forma di
distorsione del segnale originale.
Tabella 2.1: Esempi di applicazioni con esigenze real time
29
Configurazione di nodi wireless con supporto della qualità del servizio
Per caratterizzare le applicazioni real time si usano i concetti di latenza e
fedeltà. Per latenza si intende il periodo di permanenza di un pacchetto dati
nella rete, cioè il ritardo che subisce nella tratta trasmettitore-ricevitore, mentre
per fedeltà ci si riferisce alla qualità del segnale riprodotto dall’applicazione.
La sensibilità alla latenza è tanto maggiore quanto più si richiede l’interazione
tra i due estremi della connessione: la latenza è più dannosa per una telefonata
o una videoconferenza piuttosto che per la riproduzione audio o video, che è
invece più sensibile alla variazione della fedeltà.
Si può quindi riformulare la definizione di applicazione intollerante come
un’applicazione che deve riprodurre esattamente il segnale trasmesso, a meno
di un inevitabile ritardo temporale, senza alcuna perdita di fedeltà.
Quindi un’applicazione real time intollerante deve appoggiarsi ad un servizio di
trasporto dati che garantisca un ritardo massimo per i pacchetti ed una assoluta
mancanza di perdite.
Le applicazioni real time di tipo tollerante sono in grado di accettare una
variazione dell’offset delay, anzi in genere cercano di ricavare questa quantità
dall’analisi dei ritardi dei singoli pacchetti per ridurre il ritardo con cui viene
riprodotto il segnale, nel qual caso si parla di Adaptive Playback.
Ne segue che le esigenze di questo tipo di applicazioni sono meno pesanti di
quelle viste per le applicazioni intolleranti: rilassando i vincoli sul ritardo viene
incrementato il livello di utilizzazione della rete, senza che l’applicazione ne
risenta in modo pesante. Per questo motivo per applicazione Adaptive Playback
si propone un servizio di trasporto analogo al classico Best Effort riferito però ad
una rete scarica.
30
Configurazione di nodi wireless con supporto della qualità del servizio
2.5.2 Applicazioni Elastiche
Nelle applicazioni elastiche, al contrario delle applicazioni real time, i dati
vengono elaborati a mano a mano che arrivano; quindi l’applicazione è in grado
di svolgere le sue funzioni anche se alcuni dati arrivano in ritardo.
Il ritardo riduce le prestazioni globali dell’applicazione, ma non al punto da
renderla inutilizzabile: il calo di prestazioni è dovuto al ritardo medio piuttosto
che alle code della distribuzione statistica dei ritardi, quindi alcuni pacchetti
possono arrivare con un ritardo notevole, ma il valore medio del ritardo deve
essere contenuto entro certi limiti. Per questo motivo il servizio più adatto a
soddisfare i requisiti delle applicazioni elastiche è sicuramente il Best Effort, con
una eventuale differenziazione a seconda della diversa sensibilità alla latenza
delle singole applicazioni.
Tabella 2.2: Sensibilità alla latenza di alcune applicazioni tipiche
31
Configurazione di nodi wireless con supporto della qualità del servizio
2.6 Il Modello Differentiated Services
L’architettura Differentiated Services detta anche DiffServ o DS, viene definita
nell’RFC2475 dell’IETF dove sono descritte tutte le regole che si devono
rispettare per garantire l’interoperabilità tra i sistemi DS.
La caratteristica di questa architettura è rappresentata dal traffico che non è più
considerato come un insieme generico di pacchetti che costituiscono un unico
flusso che viene trattato in modo best effort, ma la banda complessiva
disponibile nei vari collegamenti viene suddivisa in un insieme di flussi
caratterizzati da alcuni comportamenti comuni.
Al loro interno sono costituiti dei microflussi che rappresentano aggregati di
differenti connessioni aventi caratteristiche comportamentali analoghe (stesso
BA - Behavior Aggregate).
La gestione di un flusso prescinde quindi dalla sua composizione, ossia da come
sono organizzati dentro di sé i vari microflussi, in questo modo da un lato si
opera trattando analogamente tutti i microflussi appartenenti ad un unico
Behavior Aggregate, ma dall’ altro è necessario che questo flusso aggregato
rispetti i livelli di servizio concordati con l’utente.
Una caratteristica importante per la soluzione DS è la scalabilità, ossia la
possibilità di interfacciare tra loro differenti rete DS in sequenza o l’una dentro
32
Configurazione di nodi wireless con supporto della qualità del servizio
l’altra, anche senza conoscere nel dettaglio i meccanismi gestionali di ciascuna
rete; questo meccanismo è importante nel caso in cui due AS (Autonomus
System), che supportano entrambi DS, si interfaccino tra di loro.
La rete DiffServ quindi non prevede controlli sul singolo microflusso, ma solo
sugli aggregati, pertanto è necessario che verso i nodi più esterni della rete
venga previsto un controllo del rispetto dei requisiti che si vogliono mantenere
mediante delle policy opportune per evitare in seguito comportamenti
imprevedibili.
Poiché la rete DiffServ è asimmetrica, ogni connessione è vista come un flusso
monodirezionale. I pacchetti vengono quindi classificati e marcati in modo tale
da poter essere trattati in modo diverso: chiaramente la differenza di
trattamento è imposta dal particolare comportamento di inoltro (PHB - Per Hop
Behavior) sui nodi lungo il percorso.
C’è quindi una sequenza di operazioni che devono essere svolte per garantire
un corretto funzionamento di una rete DS.
La rete DiffServ è divisa in domini (figura 2.4) e a loro volta i domini si possono
suddividere in due insiemi significativi:
•
i domini centrali (CORE);
•
i domini di confine (EDGE).
I domini di confine (Edge Router) sono i più delicati per lo svolgimento delle
politiche di qualità e di differenziazione dei servizi, in quanto è lì che è
necessario classificare i pacchetti, e svolgere altre importanti operazioni come
shaping, policing, dropping e remarking.
33
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.4: Architettura di un dominio di rete DiffServ
2.6.1 Il condizionamento del traffico
Un condizionatore di traffico può contener i seguenti elementi:
•
classifier
•
meter
•
marker
•
shaker
•
dropper
Quando i pacchetti escono dal dispositivo di condizionamento del traffico di un
edge router, deve essere impostata ad un valore appropriato, un’etichetta DS
(DiffServ Code Point) per ogni pacchetto.
I condizionatori di traffico, che rappresentano la parte più complessa della rete
DS, sono normalmente situati sulla frontiera della rete ma non è escluso che
possano anche essere posizionati nei nodi interni di un dominio DS o talvolta
dentro un dominio non compatibile con DS. La figura 2.5 mostra un diagramma
a blocchi di un classificatore e condizionatore di traffico. Questo dispositivo può
non essere necessariamente costituito da tutti e quattro gli elementi. Per
34
Configurazione di nodi wireless con supporto della qualità del servizio
esempio nel caso in cui nessun profilo di traffico sua configurato, i pacchetti
passano soltanto attraverso un classificatore e un marker.
Figura 2.5: Condizionamento e classificazione del traffico
2.6.2 Classificazione dei pacchetti
Prima che il traffico di rete riceva un trattamento differenziato è necessario
classificarlo, ossia suddividerlo in classi differenziate in base ai comportamenti
di inoltro (PHB) che si vogliono garantire, quindi associarlo ad opportune code
specifiche per i vari tipi di traffico, per poi effettuare l’operazione di marking
inserendo un’etichetta (DSCP) presente nell’intestazione del pacchetto IP che
viene riconosciuta in tutta la rete DiffServ, in modo da garantire un trattamento
diverso dagli altri pacchetti. Pertanto queste funzioni avvengono ai nodi di
ingresso della rete DS.
I classificatori selezionano i pacchetti in un flusso di traffico basandosi sul
contenuto di una parte dell’intestazione del pacchetto. Esistono due tipi di
classificatori:
•
il classificatore Behavior Aggregate classifica i pacchetti basandosi solo
sull’etichetta DSCP;
•
il classificatore Multifield seleziona i pacchetti sulla base di uno o più
35
Configurazione di nodi wireless con supporto della qualità del servizio
campi dell’intestazione, come per esempio l’indirizzo IP sorgente e/o
destinatario, il campo DS, il protocollo (protocol ID), i numeri dei porti
sorgente o destinazione ed altre informazioni.
Figura 2.6 : Esempio di un elemento classifier
Sarà chiaro che un Classifier considera un flusso di traffico come input e lo
dirige al corretto output.
2.6.3 Profilo del Traffico: Meter
Se le proprietà di un flusso di pacchetti non superano certi parametri predefiniti,
i pacchetti sono chiamati in-profile; in caso contrario saranno detti out-profile.
I profili di traffico specificano le proprietà temporali (rate, burst) di un certo
livello di servizio e così forniscono le regole per la determinazione se un
pacchetto è in-profile oppure no.
Un esempio di profilo di traffico, può essere:
•
max bit rate = 1Mbit/s
•
burst di 2Mbit/s con massima durata di 20 secondi, se non sono entro 1
minuto l’uno dall’altro
36
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.7: Esempio di un elemento meter
La figura 2.7 mostra un elemento meter molto generico: esso considera un
flusso di dati come input e decide se quel flusso è conforme o non conforme ad
un certo profilo di traffico.
È facile capire che l’operazione di marking è fortemente influenzata dal
metering, infatti subito dopo la misurazione del traffico verranno prese decisioni
di dropper o shaping.
2.6.4 Marker
Sulla frontiera (EDGE) di ingresso della rete DiffServ, i pacchetti subiscono il
marking: vengono prima selezionati da un classificatore e successivamente
marcati opportunamente scrivendo una sequenza di codice sempre all’interno
dell’header, chiamata DS-byte (si utilizza la porzione di campo riservata al
ToS/CoS del pacchetto Ipv4/Ipv6) .
Si tratta di 8 bit, di cui 6 costituiscono il cosiddetto DiffServ Code Point (DSCP),
i restanti 2 bit (i meno significativi) sono riservati. Il marking di un pacchetto
quindi fa in modo di aggiungerlo ad un particolare flusso aggregato.
37
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 2.8: DSCP nell’header IP
Il marker può essere configurato per fare il marking di tutti i pacchetti che gli
arrivano ad una stessa etichetta, o può essere configurato per fare marking di
un pacchetto ad una o un insieme di etichette utilizzate per selezionare un
aggregato in un gruppo, in accordo con lo stato del misuratore.
Quando il marker cambia un precedente DSCP presente in un pacchetto in uno
nuovo si dice che esso ha subito un remarking.
2.6.5 Scheduler
Lo scheduler attua al suo interno vari algoritmi di selezione che descrivono il
modo con cui i pacchetti possono venire trattati dopo essere stati classificati ed
opportunamente accodati, determinando in quale ordine ed in che momento i
pacchetti che arrivano al suo ingresso sono inviati alla rete.
Tali algoritmi sono chiamati discipline di servizio.
Sono inoltre inclusi parametri che influiscono sull’operazione di uno scheduler:
parametri statici come la priorità relativa associata ai vari canali di input, e
parametri dinamici come il valore DSCP dei pacchetti presenti all’ingresso di uno
38
Configurazione di nodi wireless con supporto della qualità del servizio
scheduler. Sono possibili quindi diverse discipline di servizio, come:
•
FCFS: first come, first served
•
RB: rated based
•
WFBS: weighted fair bandwidth sharing
2.6.6 Policing
Il Policing è il processo di eliminazione dei pacchetti (per mezzo di un dropper)
appartenenti ad un determinato flusso di traffico in funzione dello stato di un
misuratore (meter). Esso è quindi costituito da un insieme di regole che devono
essere rispettate per mantenere la proporzione voluta fra i volumi di traffico che
devono occupare l’intera banda disponibile di un collegamento ed è pertanto
uno dei metodi che si utilizzano per realizzare il condizionamento del traffico.
Per mantenere all’interno la semplicità della rete DS, è fortemente consigliabile
effettuare l’operazione di policing solo nei nodi di ingresso.
2.6.7 Policy
Può succedere che i pacchetti che sono in eccesso ad un certo profilo di traffico
possano subire diversi trattamenti. Con l’impostazione delle policy è possibile
stabilire i limiti per i vari profili di traffico e le azioni da intraprendere tra le
seguenti:
•
scarto (dropping)
•
remarking
•
trasmissione come Best Effort
39
Configurazione di nodi wireless con supporto della qualità del servizio
Quando vengono intraprese azioni diverse dall’eliminazione dei pacchetti, come
il remarking dei pacchetti in eccesso, è consigliabile utilizzare un nuovo DSCP
che ha un comportamento associato differente, magari meno privilegiato
rispetto
al
precedente;
solitamente
inoltre
si
utilizza
come
nuovo
comportamento quello standard che identifica il traffico di default, chiamato
Best Effort.
In questi casi nasce un pericolo: è possibile che venga sovvertito l’ordine con
cui arrivano i pacchetti e questo infatti può mettere in crisi il meccanismo di
gestione della congestione.
Infatti alcuni pacchetti che andrebbero eliminati, nel caso in cui vengano
rimarcati come Best Effort, possono subire dei ritardi troppo elevati dovuti ai
diversi comportamenti di inoltro (PHB) che subiscono e rischiano quindi di
arrivare anche con ritardi consistenti rispetto agli altri, introducendo meccanismi
di ritrasmissione che non creano alcun beneficio.
Per risolvere questo problema quindi è necessaria un’accurata gestione delle
policy e un continuo monitoraggio della rete.
Le operazioni di policy solitamente sono svolte nei nodi di confine ed in
particolare nei cosiddetti ingress nodes, per garantire un’equa ripartizione delle
risorse disponibili tra i diversi domini che generano del traffico.
2.6.8 Shaper
Lo shaper ha il compito di ritardare qualcuno o tutti i pacchetti in un flusso di
traffico cercando di mantenere l’ordine all’interno dello stesso microflusso in
modo tale da fornire un profilo di traffico compatibile con il tipo di servizio che
si vuole offrire.
40
Configurazione di nodi wireless con supporto della qualità del servizio
Uno shaper normalmente ha un buffer a lunghezza finita ed i pacchetti possono
essere limitati se in esso non c’è spazio sufficiente per mantenere tutti quelli
che devono essere ritardati.
In ogni caso viene suggerito di evitare per quanto possibile l’eliminazione dei
pacchetti in quanto lo shaper serve per evitare che le policy successive
eliminino i pacchetti poco distribuiti, che si presentano cioè sotto forma di burst.
Essenzialmente ci sono tre tecniche per implementare il traffic shaping:
•
Leaky bucket
•
Token bucket
•
Flow specification
2.6.9 Dropper
Il dropper elimina qualcuno o tutti i pacchetti in un flusso di traffico senza però
cambiare l’ordine di arrivo per mantenere il flusso con un profilo di traffico
compatibile.
Da notare che un dropper può essere implementato come un caso particolare di
uno shaper attraverso la regolazione della lunghezza del buffer dello shaper a
zero o a pochi pacchetti.
2.6.10 Per Hop Behaviors (PHB)
Quando un pacchetto viene classificato all’interno di un router, viene
differenziato rispetto agli altri in base all’etichetta, ovvero dal valore del campo
DS. Questa può essere vista come divisa in due parti: la prima parte viene
utilizzata per scegliere la coda di appartenenza del pacchetto; la seconda per
41
Configurazione di nodi wireless con supporto della qualità del servizio
eseguire una differenziazione tra i pacchetti appartenenti alla stessa coda, nel
caso si verifichi una congestione.
Ognuna delle code presenti in un router è collegata ad una particolare classe di
servizio, quindi ad un Per Hop Behaviors (PHB), e le proprietà di queste code,
come l’ampiezza di banda o il ritardo medio, dipendono dal meccanismo di
scheduling adottato. Il PHB non è altro che una descrizione della regole di
smistamento del traffico assegnate a tutti i pacchetti aventi stesso valore DSCP.
Si descrive nel dettaglio tre differenti tipologie di PHB:
•
Expedited Forwarding (EF)
•
Assured Forwarding (AF)
•
Best Effort (BE)
2.6.10.1 Expedited Forwarding (EF)
L’Expedited Forwarding PHB (EF) è un servizio che fornisce all’utente una
percentuale minima garantita per l’utilizzo del collegamento. L’EF si presenta
quindi come la forma di traffico privilegiato a cui si fornisce quindi un minimo
ritardo, un jitter e una minima perdita di pacchetti.
Per poter garantire al traffico EF i requisiti minimi di basso delay e bassa delay
variation, bisogna fare in modo che la permanenza all’interno della coda sia
minima; pertanto il compito del manager della rete deve essere quello di
determinare un valore limite alla lunghezza delle code, fino al punto in cui si
abbia perdita di pacchetti molto bassa.
Infatti è preferibile perdere un pacchetto fra tanti, piuttosto che rallentarlo in
una coda lunga.
42
Configurazione di nodi wireless con supporto della qualità del servizio
E’ importante notare che la dimensione della coda dipende dal tipo di traffico EF
che si intende trasportare, cioè dalla composizione dei microflussi che
compongono l’aggregato EF; per cui è necessario monitorare i pacchetti
trasmessi da questa classe di servizio, in maniera da mantenere mediamente la
velocità dei pacchetti del flusso EF in arrivo sempre minore di quella con cui
vengono smaltiti.
2.6.10.2 Assured Forwarding (AF)
L’Assured Forwarding PHB (AF) è un servizio piuttosto complesso nella cui
specifica può essere osservato che la classe delle azioni standard è stata
ripartita nel seguente modo:
•
4 classi indipendenti
•
ciascuna classe in tre livelli di precedenza
Questa specifica indica quattro classi di traffico, per ognuna delle quali è
garantita una minima quantità di banda e di buffer; si tratta quindi di requisiti
non stringenti come invece si era osservato nell’EF, ma comunque migliori
rispetto al Best Effort.
Tabella 2.3: Schema di assegnazione delle classi secondo il PHB Assurded Forwarding
43
Configurazione di nodi wireless con supporto della qualità del servizio
La tabella che mette in relazione il DSCP della classe con il corrispettivo valore
di precedenza di scarto.
La suddivisione viene fatta chiamando ciascun comportamento con il simbolo
Afij con 0<i<4 e 0<j<3; quindi il pedice i indica la classe e il pedice j il livello di
precedenza.
Le quattro classi definibili sono indipendenti tra loro, quindi un flusso che viene
assegnato ad una classe non può essere rimarcato su una classe diversa.
Per rispettare le specifiche sul DSCP, una classe Afi è caratterizzata da
comportamenti associati a caratteristiche di inoltro superiori rispetto ad una
classe Afj quando i>j.
La precedenza di eliminazione invece è una caratteristica specifica di ogni classe
e può essere più alta o più bassa.
Essa serve soprattutto per permettere all’interno di una stessa classe ed in caso
di congestione, diversi comportamenti con caratteristiche di inoltro differenziate.
Normalmente all’interno della classe AF è consigliabile l’uso di due precedenze
in caso di rare situazioni di congestione, e tre nel caso di forti e prolungate
situazioni di blocco del corretto funzionamento della rete.
All’interno di una stessa classe la precedenza di eliminazione serve per stabilire
parametri di accodamento e di scarto dei pacchetti differenziati.
2.6.10.3 Best Effort (BE)
Il Best Effort (BE) rappresenta il comportamento associato al traffico non
privilegiato, cioè che non viene trattato per soddisfare requisiti particolari, ma a
cui possiamo comunque associare una banda minima garantita con opportune
policy per garantirne l’inoltro.
44
Configurazione di nodi wireless con supporto della qualità del servizio
Quando all’ingresso di un edge router si presenta del traffico che non rispetta le
condizioni imposte dai filtri (ossia nessun campo dell’ intestazione del pacchetto
è configurato per la rete DS), viene automaticamente assegnato ad un profilo di
traffico di tipo Best Effort.
2.7 Il protocollo RTP
Per rendere più agevoli le operazioni svolte dalle applicazioni real time è stato
introdotto il protocollo di trasporto RTP (Real-Time Protocol) che si appoggia al
protocollo UDP ma aggiunge una serie di nuovi servizi:
•
numerazione sequenziale dei pacchetti trasmessi;
•
gestione del timestamping per ricavare la temporizzazione corretta dei
dati;
•
identificazione del traffico trasportato (audio, video) e della codifica usata
(MPEG, H.261, ecc.);
•
controllo della qualità del servizio resa disponibile dalla rete.
Si osservi che il protocollo RTP non assicura nessuna qualità del servizio ma
pone in parte rimedio ai problemi dovuti al ritardo aleatorio dei pacchetti dati
perché fornisce all’applicazione una serie di informazioni che consentono di
migliorare la riproduzione del segnale.
Alcuni applicativi si appoggiano per il trasporto dei dati proprio al protocollo
RTP, permettendo di snellire la struttura dell’applicazione, a discapito di un
aumento in termini di banda occupata a causa dell’overhead dovuto ai protocolli
di trasporto.
45
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 3
La QoS negli end-system
In questo capitolo si cercherà di spiegare come può essere gestita la qualità del
servizio sui nodi terminali di una rete; verranno presentate le principali soluzioni
oggi presenti negli scenari classici evidenziandone i vantaggi e i limiti e le idee
proposte per un miglioramento delle prestazioni.
3.1 La qualità del servizio sulle reti IP
IP (Internet Protocol) è un protocollo di tipo connectionless, cioè senza
connessione. Questo protocollo non richiede che tutti i pacchetti attraversino lo
stesso percorso, bensì la decisione d’instradamento viene presa in maniera
indipendente dai pacchetti stessi, tipicamente in funzione delle condizioni di
traffico presenti nella rete. Questo garantisce una robustezza maggiore alla rete
nei confronti d’eventuali crash di nodi intermedi di un percorso.
Contemporaneamente però il protocollo IP non fa alcun riferimento al
trattamento esplicito del traffico. L’unica modalità di trasmissione di dati
prevista da tale protocollo è quella best effort. Tale modalità di trasmissione,
46
Configurazione di nodi wireless con supporto della qualità del servizio
pur prestando un elevato grado di robustezza, mal si adatta ad applicazioni di
tipo real time.
La nascita di questo tipo di applicazioni - in particolare delle applicazioni
multimediali - ha fatto sentire sempre di più la necessità di trovare delle
soluzioni capaci di garantire comunicazioni interattive caratterizzate da una
certa Quality of Service.
Le esigenze legate alle applicazioni multimediali hanno spinto il gruppo di lavoro
IETF a realizzare un modello che cercasse di superare i limiti di quello corrente
senza però sconvolgere la struttura stessa di Internet [1]. Quello che si è
proposto il gruppo di lavoro IntServ, è di modificare l’odierna infrastruttura di
Internet al fine di poter fornire garanzie di Quality of Service.
Il modello proposto cerca di offrire tre servizi di base:
•
servizi best effort
•
servizi real time
•
servizi di controllo della banda disponibile
L’assunzione di base del modello Integrated Service è la limitata capacità di
trasmissione dei link: una conseguenza di ciò è che il numero di flussi real time
che un link può sopportare è limitato.
Da queste prime assunzioni si può intuire che il modello IntServ fornisce ai
router la capacità di riservare risorse in modo da fornire una ben determinata
qualità del servizio per specifici flussi.
Un’altra assunzione del modello IntServ è che sia il traffico real time che quello
differito debbano usare le stesse infrastrutture di rete; in tal caso si dovrebbe
progettare un unico stack di protocolli che usi un singolo Internet layer per
entrambi i tipi di traffico.
47
Configurazione di nodi wireless con supporto della qualità del servizio
Una possibile infrastruttura che realizzi le ipotesi poste dal modello IntServ è
costituita da quattro nuovi componenti:
•
un packet scheduler
•
un packet classifier
•
un insieme di admission control
•
un protocollo per la prenotazione delle risorse.
Di questi quattro componenti i primi tre costituiscono il modulo di Controllo del
Traffico (Traffic Control) ossia il componente del router che si occupa di
garantire le differenti qualità del servizio ai flussi che lo attraversano.
Figura 3.1: Architettura RSVP negli host e nei router
L’unico componente a non essere incluso nel Traffic Control è il protocollo di
prenotazione delle risorse; la presenza di questo protocollo è legata alla
necessità di memorizzare uno stato nei nodi della rete per ogni flusso
48
Configurazione di nodi wireless con supporto della qualità del servizio
prenotato. Il protocollo funziona inviando una serie di messaggi sulla rete, che
informano i nodi intermedi della presenza di un nuovo flusso prenotato,
permettendo al packet scheduler di trattare i pacchetti appartenenti a questo
flusso in maniera da garantire la qualità del servizio. Nel modello non è
specificato come effettivamente è fatto questo protocollo, anche se di fatto
quello che sembra essere destinato ad essere utilizzato è il protocollo RSVP
(Resource reSerVation Protocol) [7].
Il modello IntServ prevede una serie di classi di servizio che fanno riferimento
fondamentalmente al ritardo di trasmissione:
•
Guaranteed Service [8]: impone al flusso di dati generato da
un’applicazione, un limite superiore sul ritardo di trasmissione end-to-end
cui un generico pacchetto può essere soggetto a causa delle attese nelle
code degli elementi di rete; in più fornisce garanzie sulla banda passante
assegnata al flusso; non agisce né sullo jitter né sul valore medio di tale
ritardo;
•
Controlled Load [5]: offre alle applicazioni un sevizio che approssima le
caratteristiche di un flusso best effort in condizioni di rete scarica. Si
assume in particolare che:
o un’alta percentuale dei pacchetti raggiungerà la destinazione;
o il ritardo di trasmissione di questi pacchetti non eccederà il ritardo
minimo sperimentato dai pacchetti consegnati con successo.
•
Bandwidth Recovery [9]: ha come principio base quello di recuperare
la banda assegnata in eccesso ai flussi appartenenti alla classe
Guaranteed Service.
Il modello a servizi integrati [10][11] si presta all’impiego in una serie di
49
Configurazione di nodi wireless con supporto della qualità del servizio
interessanti scenari applicativi. Esso tuttavia sfruttando in maniera intensiva le
informazioni di stato, presenta problemi di scalabilità, il che contrasta
nettamente con l’elevato tasso di crescita della rete Internet.
Diventa dunque necessario concepire un modello alternativo che non memorizzi
nei nodi della rete informazioni sullo stato dei singoli flussi ma gestisca il traffico
in maniera aggregata.
Su questo paradigma è fondato il modello elaborato dal gruppo di lavoro
Differentiated Services [10], nel quale l’aggregazione è ottenuta sfruttando un
apposito campo DS inserito all’interno del pacchetto IP.
Il modello di riferimento DiffServ è basato su un modello costituito da domini:
un flusso dati proveniente da una certa sorgente entra in un dominio DS
(DiffServ) e una volta classificato come appartenente ad una certa classe di
traffico e sottoposto ad un processo di condizionamento, viene aggregato a tutti
i flussi appartenenti alla stessa classe di traffico.
All’interno del dominio, viene identificato mediante il campo DS e viene trattato
secondo il per-hop-Behavior (PHB) associato al codice DS.
Quando un’entità richiede un servizio ad un fornitore di servizi DiffServ, tra i
due viene stabilito un contratto in termini di livello del servizio offerto detto
Service Level Agreement o SLA. Questo contratto specifica inoltre quale deve
essere il profilo del traffico generato da chi usufruisce del servizio e come deve
essere trattato se esso non coincide con il profilo stipulato.
I servizi offerti hanno due caratteristiche fondamentali: si riferiscono al traffico
in una sola direzione e fanno riferimento ad aggregati di traffico.
Una parte importante dell’SLA è il Traffic Condition Agreement (TCA): esso
50
Configurazione di nodi wireless con supporto della qualità del servizio
specifica in dettaglio i parametri che caratterizzano il livello di servizio e tali
parametri comprendono:
•
valori indicanti caratteristiche del servizio in termini di performance,
come throughput, probabilità di perdita dei pacchetti, latenza;
•
i profili di traffico a cui si deve aderire affinché il servizio possa essere
fornito in maniera corretta;
•
la disposizione sul traffico così detto out-of-profile, ossia quando la
banda utilizzata supera quella prenotata; la parte di traffico in più è
proprio quella detta “fuori dal profilo”;
•
caratteristiche
di
marking: i pacchetti da trasmettere vengono
preventivamente marcati allo scopo di distinguerli nel tragitto tra i due
end-point;
•
caratteristiche di shaping: ossia si cerca di rendere il traffico uniforme e
quindi senza fenomeni di burst.
Il Service Level Agreement specifica inoltre altri parametri più generali quali:
•
affidabilità di condizioni critiche, legate per esempio al re-routing dovuto
a danneggiamenti di nodi intermedi;
•
servizi di crittografia;
•
vincoli di instradamento;
•
meccanismi d’autenticazione;
•
meccanismi di monitoraggio del traffico offerto;
•
tariffazione.
Le architetture IntServ e DiffServ sembrano rappresentare due soluzioni
completamente opposte al problema dell’offerta di servizi di comunicazione
caratterizzati da QoS.
51
Configurazione di nodi wireless con supporto della qualità del servizio
Ognuna delle due presenta però una serie di problematiche: sostanzialmente il
problema del modello IntServ/RSVP è la scalabilità, dovuta alla memorizzazione
di uno stato per ogni flusso; il problema del modello DiffServ è che l’aggregato
non è adatto ad offrire servizi di tipo quantitativo, dove servizi qualitativi sono
servizi del tipo: “il 90% del traffico in-profile subirà al massimo 50ms di
latenza”.
Il DiffServ sembra tuttavia essere la soluzione più adatta ad essere realizzata in
tempi ragionevoli, anche se è importante assicurare che i meccanismi di host e
router già esistenti basati sul modello IntServ, possano interoperare con i
meccanismi di reti basate sul modello DiffServ.
Un possibile modello che prevede la coesistenza di rete IntServ e DiffServ è
costituito da una rete di transito (Transit Network) basata sul modello DiffServ e
da un certo numero di rete periferiche (Stub Networks) basate sul modello
IntServ.
In un modello del genere gli host utilizzano RSVP per effettuare le richieste di
QoS; tali richieste, oltre a generare messaggi RSVP, invocano il modello di
controllo del traffico locale.
Gli edge router, ovvero i router terminali, fanno invece da punti di connessione
tra le reti periferiche e le reti di transito. Tuttavia è spesso conveniente
separare questi elementi in due parti: una parte di tipo RSVP-capable, che si
affaccia sulla rete periferica e una parte DiffServ-capable, che si affaccia sulla
rete di transito.
52
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 3.2: Coesistenza tra IntServ e DiffServ
3.2 L’influenza del sistema operativo
Sebbene i due modelli standard IntServ e DiffServ propongano una soluzione al
problema della qualità del servizio relativa alla gestione delle risorse di rete nei
nodi intermedi (router), non è trattato in maniera altrettanto efficace la
gestione delle risorse sull’end-system (host).
In sostanza l’end-system è considerato come un semplice punto nel modello
della rete e non come un sistema a sua volta complesso che necessita di gestire
un numero notevole di risorse.
Recenti ricerche [12] hanno evidenziato come, al fine di fornire concrete
garanzie di QoS per applicazioni distribuite di tipo delay-sensitive, risulti
fondamentale considerare un modello di QoS che includa al suo interno sia le
caratteristiche della rete che del sistema operativo usato.
Ad esempio, per alcune applicazioni real time che richiedono servizi
audio/video, risulta fondamentale non solo “domandare” delle risorse alla rete,
come l’allocazione di una certa banda, ma è anche necessario configurare in
53
Configurazione di nodi wireless con supporto della qualità del servizio
maniera opportuna il sistema operativo degli host, come la schedulazione dei
processi, l’assegnazione della priorità dei pacchetti, in modo tale da garantire
una corretta tempificazione della trasmissione e della ricezione dei pacchetti
delle applicazioni che sono eseguite sull’end-system.
Il sistema operativo ha dunque il compito di gestire (coordinare ed allocare) le
risorse del sistema (memoria, accesso alle periferiche, tempo di CPU).
Tale gestione si rende necessaria per due ragioni fondamentali:
•
in primo luogo perché il numero di risorse presenti nel sistema, essendo
questo limitato, rende necessario un controllo sulle richieste multiple di
una stessa risorsa, ad esempio un disco, un’interfaccia seriale,
un’interfaccia di rete, ecc;
•
in secondo luogo perché è necessario controllare l’accesso, richiesto da
parte di uno o più processi utente, a risorse critiche o condivise come ad
esempio le memorie condivise, le code di messaggi, le strutture dati di
un processo, ecc.
Di seguito sono descritti i compiti del sistema operativo ed inoltre sono elencate
le attività di cui il sistema operativo è responsabile per la loro gestione:
•
la gestione dei processi:
o creare e deallocare i processi di utente e di sistema;
o schedulare i processi;
o fornire i meccanismi per la sincronizzazione dei processi;
o fornire i meccanismi per la comunicazione tra processi;
o fornire i meccanismi per la gestione dei deadlock;
•
la gestione della memoria centrale:
o tenere traccia di quali parti della memoria sono attualmente
utilizzate e da chi;
54
Configurazione di nodi wireless con supporto della qualità del servizio
o decidere quali processi debbono essere caricati in memoria
quando vi sia spazio disponibile;
•
la gestione della memoria secondaria:
o gestire ed allocare lo spazio libero;
o scheduling del disco;
•
la gestione dei file:
o creare e cancellare i file e le directory;
o fornire le primitive per la manipolazione di file e directory;
o mapping dei file sulla memoria secondaria;
o backup dei file su dispositivi di memoria stabili.
Inoltre il sistema operativo deve:
•
fornire un meccanismo di protezione che controlla l’accesso da parte dei
programmi, dei processi e degli utenti alle risorse del sistema;
•
fornire un interprete dei comandi, il quale costituisce l’interfaccia tra
l’utente ed il sistema operativo;
•
gestire il sistema di I/O che ha il compito di nascondere all’utente le
caratteristiche dei dispositivi hardware.
Nella
figura
3.3
viene
riportato
uno
schema
a
blocchi
semplificato
dell’architettura di un generico sistema operativo.
Un’importanza fondamentale va data allo scheduling dei processi ed al
meccanismo di I/O relativamente alla condivisione delle risorse nei sistemi
operativi: si ritiene che questi meccanismi siano le principali cause di ritardi
nella comunicazione all’interno degli end-system.
55
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 3.3: Struttura a blocchi di un kernel
Molti dispositivi hardware (dispositivi di memoria di massa, disk driver,
interfaccia di rete, ecc.) sono nascosti all’utente grazie meccanismi offerti dal
SO, come l’interfaccia socket ed il sottosistema di I/O.
Per capire la complessità di un end-system si può pensare ad esempio allo
scheduling dei processi che dipende dal tipo di programma da eseguire e dagli
obiettivi della politica di scheduling.
Il tempo d’esecuzione di un programma è generalmente composto da una parte
dovuta al tempo d’elaborazione di CPU e da un’altra dovuta al tempo di
elaborazione per eseguire le istruzioni di I/O. La politica di scheduling
56
Configurazione di nodi wireless con supporto della qualità del servizio
tipicamente ha il compito di bilanciare l’utilizzazione delle risorse in base al
tempo richiesto da un’applicazione al fine di completare il proprio task.
La priorità di un processo è periodicamente ricalcolata in base a vari parametri,
come l’intervallo di tempo in cui esso occupa la CPU, la quantità di memoria che
esso occupa o richiede per l’esecuzione, e così via.
Un esempio è il real time scheduling, il quale deve assicurare che il processo
finisca entro uno specifico deadline o in un particolare ordine.
Il sistema operativo 4.4BSD ad esempio non implementa il real time scheduling.
La politica di scheduling del 4.4BSD [13] assegna inizialmente ad ogni processo
la massima priorità e permette ad un processo di essere eseguito per un fissato
time slice.
Durante l’esecuzione del processo la sua priorità viene abbassata, cosicché il
processo che utilizza più a lungo la CPU avrà un priorità che si abbassa
rapidamente mentre i processi che rimangono inattivi hanno una priorità che
aumenta. Quando questi ultimi sono pronti per essere eseguiti possono
prelazionare le risorse al processo in esecuzione ammesso che questo abbia una
priorità più bassa. La priorità del processo dipende da due valori p_estcpu e
p_vice. Il valore p_estcpu fornisce una stima della recente utilizzazione della
CPU da parte del processo; il valore p_nice è modificabile a livello d’utente e
varia tra -20 e 20 (il valore normale è 0).
La priorità complessiva del processo viene ricalcolata periodicamente in base a
questi valori.
Solaris 2.x [14] è un sistema multithreaded e multiprocesso e quindi il suo
scheduler di processo deve supportare tali caratteristiche. Il risultato è uno
scheduler molto efficiente per l’esecuzione di processi real time. Lo scheduling
57
Configurazione di nodi wireless con supporto della qualità del servizio
dei thread è basato sulla priorità e su classi di scheduling.
Il sistema organizza e classifica i thread in quattro classi: interattivi (IA),
timesharing (TS), real time (RT) e thread di sistema (SYS). All’interno d’ogni
classe è assegnata una priorità al thread.
I thread TS sono eseguiti per un periodo di tempo al termine del quale, se non
hanno completato il loro task, vengono schedulati a favore di un altro thread.
Ad ognuno di essi è assegnato un time slice la cui lunghezza varia in base alla
priorità del thread. Comunque la priorità del thread è modificata ad ogni cambio
di contesto per evitare fenomeni di starvation in cui un thread monopolizza l’uso
di una risorsa del sistema.
La classe SYS è usata per eseguire processi di sistema; i thread in questa classe
hanno una priorità fissata e non posseggono un time slice. Essi sono eseguiti
finché non sono completati, oppure finché gli viene prelazionata la CPU da un
thread (a priorità maggiore) della stessa classe. I thread d’utente non possono
essere schedulati o assegnati alla classe SYS.
I thread della classe RT posseggono una priorità fissata e un time slice. Essi
sono schedulati in base alla priorità.
Anche Linux [15] è un sistema operativo multithreaded e multitask. La politica
di scheduling può assumere uno dei seguenti valori
•
SCHED_OTHER (la politica di default);
•
SCHED_FIFO;
•
SCHED_RR;
le ultime due individuano delle politiche speciali per applicazioni time critical.
Queste politiche consentono di sospendere i processi di tipo SCHED_OTHER. Un
58
Configurazione di nodi wireless con supporto della qualità del servizio
processo SCHED_FIFO può essere sospeso solo da un processo con priorità più
alta, ma un processo SCHED_RR, se necessario, sarà sospeso per condividere il
tempo di esecuzione con altri processi che hanno la stessa priorità.
Linux assegna inizialmente ad ogni processo una priorità intermedia, a meno
che non venga richiesta dall’utente una specifica priorità. Durante l’esecuzione
la priorità viene modificata dinamicamente.
Come in 4.4BSD e Solaris 2.x esiste un valore di priorità detto nice che è
modificabile a livello d’utente e varia tra -19 e 19. Anche in Linux il valore
nominale di nice è 0. Maggiore è la priorità nice associata ad un processo e più
il sistema operativo tenterà di abbassare la priorità interna associata allo stesso.
Ciò e dovuto alla politica alla base dello scheduling di Linux: tutti i processi
devono essere trattati in modo quanto più equo possibile.
Il problema di garantire parametri di qualità del servizio nella comunicazione
end-to-end richiede una diversità di risorse; tra queste le risorse di rete
rappresentano solo una piccola parte. Le altre risorse, come la capacità
d’elaborazione (CPU), I/O caching, I/O devices, memoria paginata, memorie
ausiliarie (buffer e memoria video), periferiche (videocamera, microfono) ecc.,
devono essere gestite in accordo con la rete al fine di garantire il
comportamento desiderato.
Nella figura 3.4 viene mostrato come le esigenze di QoS delle applicazioni non
riguardano solo i parametri di QoS della rete (throughput, latency, jitter, lost
rate) ma anche quelli del sistema operativo come la priorità assegnata ad un
processo, il time slice (quanto di tempo in cui la CPU è assegnata ad un dato
processo), la priorità dei pacchetti trasmessi, ecc. Di conseguenza, i parametri
di QoS forniti a livello di applicazione vengono in parte tradotti in parametri di
QoS per il sistema operativo e parte in parametri di QoS per la rete.
59
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 3.4: Parametri di QoS delle applicazioni
Si potrebbe pensare di migliorare la comunicazione tra processi remoti
ottimizzando la gestione delle risorse dell’end-system locale e in particolare i
meccanismi di I/O offerti dal sistema operativo. La schedulazione dei pacchetti
all’interno dello stream rappresenta la reale difficoltà per garantire pienamente
alcuni parametri di QoS nei sistemi host, più della schedulazione dei processi.
Risulta quindi necessario estendere il processo di Quality of Service
Management anche all’interno dell’end-system. Il compito di tale processo è
quello di ottimizzare, in base al livello di servizio richiesto dall’applicazione,
l’utilizzo delle risorse dell’end-system e i meccanismi offerti dal sistema
operativo in accordo con la rete. Il QoS Management deve essere in grado,
attraverso dei processi di Admission Subsystem e di Resource Scheduler, di
fornire garanzie alle richieste di risorse.
Attraverso il processo di prenotazione delle risorse un’applicazione può
60
Configurazione di nodi wireless con supporto della qualità del servizio
richiedere risorse ed ottenere una risposta dal sistema da parte dell’Admission
Subsystem il quale determina quante e quali risorse servono per soddisfare la
richiesta. Sarà poi compito del Resource Scheduler ottenere una corretta
suddivisione delle risorse tra le applicazioni ed in particolare offrire una
sufficiente garanzia della loro disponibilità.
Esso effettua un processo di scheduling che consiste nella determinazione della
disponibilità di risorse in un particolare istante di tempo. Se ci sono sufficienti
risorse disponibili, il Resource Scheduler restituisce una conferma all’Admission
Subsystem il quale accetta la richiesta dell’applicazione.
Nella figura 3.5 è rappresentato un modello di QoS Management che
comprende l’end-system. Tale modello prevede anche un processo di
prenotazione delle risorse coordinato e controllato delle risorse stesse non solo
della rete, ma anche di quelle offerte dal sistema operativo.
Figura 3.5: End-System QoS Management
61
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 4
Reti wireless 802.11
Le tecnologie per la comunicazione senza fili si stanno diffondendo rapidamente
in tutto il mondo. Esse sono utilizzate sia per realizzare reti locali (LAN) di
computer mobili, sia per la comunicazione tra dispositivi di uso comune come
telefoni, macchine fotografiche, ecc.
Le reti locali senza fili sono dette Wireless Local Area Network (WLAN) e
vengono utilizzate per fornire connettivitá ad utenti mobili con prestazioni
paragonabili alle soluzioni broadband via cavo che si trovano sul mercato. Le
principali tecnologie wireless si basano sulle specifiche del protocollo IEEE
802.11.
4.1 Il protocollo IEEE 802.11
Nel 1990 venne costituito il primo gruppo di lavoro 802.11 dedicato allo
sviluppo di uno standard per reti wireless, che venne approvato dall’IEEE sette
anni dopo. Parallelamente l’IEEE costituì diversi gruppi di lavoro dedicati allo
sviluppo di nuove funzionalità da aggiungere allo standard di base:
•
802.11a : è lo standard di trasmissione ad alta velocità (54 Mbit al
62
Configurazione di nodi wireless con supporto della qualità del servizio
secondo) sulla frequenza 5 GHz. I problemi legati a questa specifica non
sono pochi, ad esempio non è prevista alcuna compatibilità con 802.11b,
che era già molto diffuso al momento dell’approvazione di 802.11a.
Alcuni produttori hanno sviluppato tecnologie per rendere interoperabili i
due standard, anche se questa linea di prodotti non ha coinvolto i
consumatori.
Questo
contrasto
ha
sicuramente
influenzato
negativamente lo standard 802.11a, che lavorando sulla frequenza 5
GHz, eviterebbe eventuali interferenze con forni microonde o dispositivi
Bluetooth e permetterebbe una trasmissione con meno disturbi.
•
802.11b: è attualmente lo standard piú diffuso; consente trasmissioni a
11 Mbps sulla frequenza di 2,4 GHz. Dal momento che è ormai diffuso
con una certa capillarità sul territorio mondiale (soprattutto USA, Europa
e Giappone) l’IEEE sta rivolgendo i propri sforzi principalmente sulla
realizzazione di standard ad esso compatibili, come l’802.11g, ormai
pronto ad arrivare sul mercato. Alcuni produttori hanno sviluppato una
tecnologia proprietaria chiamata 802.11b+, che comunque non è
certificata dall’IEEE e che permette di trasmettere fino a 22 Mbps.
•
802.11c/d: sono stati raccolti questi due gruppi di lavoro perché il
primo è stato sospeso e si è poi unito al secondo; i lavori sono ancora in
corso e mirano alla definizione di un livello fisico utilizzabile in qualsiasi
paese.
•
802.11e: anche questo gruppo di lavoro, che si occupa della QoS, non
ha completato le proprie attività. Si lavora sul livello MAC per aggiungere
funzionalità multimediali alla tecnologia 802.11. Una volta approvato
questo
standard
riguarderà
tutte
le
specifiche
di
trasmissione
63
Configurazione di nodi wireless con supporto della qualità del servizio
(802.11a/b/g) e permetterà di sfruttare il wireless anche all’interno di
apparecchi multimediali.
•
802.11f: è stato già completamente implementato ed è solo in attesa
dell’approvazione dell’IEEE, definisce le specifiche a livello MAC, per la
realizzazione di sistemi wireless distribuiti e piú in generale per le attività
di roaming. La realizzazione del protocollo IAPP (Inter Access Point
Protocol), su cui la specifica si basa, è stata sostenuta da diversi
produttori tra cui Lucent e Cisco.
•
802.11g: è l’ultimo gruppo costituito per la definizione di nuovi
parametri di trasmissione sulla frequenza 2,4 GHz. Questo standard,
totalmente compatibile con 802.11b, è capace di trasmettere fino a 54
Mbps utilizzando la stessa tecnica di modulazione di 802.11a. Come già
detto le trasmissioni su 2,4 GHz sono ad alto rischio di interferenza, per
questo si pensa che 802.11g sia uno standard di transito verso una
futura specifica che permetterà di migrare sulla piú sicura e versatile
frequenza dei 5 GHz.
•
802.11h: si sta tuttora lavorando per la ridefinizione della frequenza di
trasmissione sui 5 GHz, per diminuire le emissioni di onde radio da parte
dei dispositivi.
•
802.11i: questo gruppo di lavoro sta lavorando all’implementazione di
sistemi di sicurezza per 802.11 che si affida attualmente al semplice
Wired Equivalent Privacy (WEP), un meccanismo che prevede la
possibilità di proteggere i dati trasmessi criptandoli tramite chiavi. Alcuni
miglioramenti sono stati già implementati e in alcuni casi già disponibili
64
Configurazione di nodi wireless con supporto della qualità del servizio
sul mercato (per esempio il Wi-Fi Protected Access WPA); le pressanti
richieste del mercato porteranno a breve alla realizzazione di altri sistemi
di sicurezza piú solidi.
•
802.11j: questo gruppo, non più attivo, si è occupato della
progettazione di una specifica unica, a livello nazionale, per LAN wireless
alla frequenza di 5 GHz.
4.1.1 QoS su reti wireless 802.11
Le reti WLAN 802.11 sono considerate come un “Ethernet senza filo” per il tipo
di servizio best effort fornito dal livello Medium Access Control (MAC), simile a
quello di Ethernet.
Ad oggi non sono stati ancora definiti standard per supportare a livello MAC la
QoS; sono solamente disponibili alcune bozze del protocollo 802.11e che dovrà
fornire questa funzionalità. Basandosi su queste bozze alcuni produttori hanno
già messo in commercio dispositivi che hanno caratteristiche di QoS.
Verranno ora analizzate le caratteristiche principali dei protocolli MAC presenti
nello standard originale 802.11 e nelle bozze 802.11e [16][17].
4.1.2 Il MAC 802.11
Il protocollo MAC 802.11 consiste di due funzioni di coordinamento: una
obbligatoria detta Distributed Coordination Function (DCF) basata sul Carrier
Sense Multiple Access with Collision Avoidance (CSMA/CA) e una opzionale
chiamata Point Coordination Function (PCF) basata su un protocollo di tipo poll65
Configurazione di nodi wireless con supporto della qualità del servizio
and-response.
La maggior parte dei dispositivi disponibili sul mercato utilizza solamente la
modalità DCF.
Il controllo del traffico realizzato dal DCF si basa su un servizio non-preemptive
(ad esempio con una coda FIFO). Il meccanismo del controllo di accesso del
canale è schematizzato in figura 4.1.
Figura 4.1: Accesso al canale 802.11 DCF
Quando un pacchetto MAC esce dalla coda, deve attendere finché non si liberi il
canale e successivamente aspettare per un intervallo di tempo fissato per
evitare potenziali collisioni con altri nodi di rete.
Questo tempo di attesa fissato è detto DCF InterFrame Space (DIFS). Quando il
canale rimane libero per il tempo DIFS, viene iniziato un conto alla rovescia di
durata casuale detto backoff (BO), al termine del quale viene trasmesso il
pacchetto.
Se il canale diventa occupato viene sospeso temporaneamente il BO, che
riprende dall’ultimo valore calcolato quando il canale ritorna libero per un tempo
maggiore di DIFS.
Ogni dispositivo che utilizza il canale wireless possiede un valore chiamato
Contention Window (CW), utilizzato per la scelta del BO. Il valore iniziale del BO
66
Configurazione di nodi wireless con supporto della qualità del servizio
è assegnato scegliendo in modo pseudo-casuale un numero intero nell’intervallo
[0,CW]. Se il pacchetto non viene trasmesso con successo viene calcolato un
nuovo BO utilizzando il valore di CW raddoppiato, per diminuire la probabilità di
collisione con altre stazioni.
Il valore iniziale del CW è indicato come CWmin, mentre limite massimo che può
assumere in caso di insuccessi è definito da CWmax.
Nel caso in cui un pacchetto arrivi in una coda vuota e il canale è libero da un
tempo maggiore di DIFS, il pacchetto viene inviato immediatamente.
Per offrire un supporto alla QoS, seppur in modo limitato, è stato definito il
Point Coordination Function (PCF).
Il PCF permette alle stazioni mobili di avere accesso al canale wireless con
diversa priorità, grazie ad una stazione Point Coordinator (PC) che svolge la
funzione di coordinamento.
Il PCF ha una priorità maggiore rispetto al DIFS, visto che può trasmettere dopo
un intervallo di tempo più breve rispetto alla durata del DIFS; nel caso di PCF, il
tempo di attesa viene chiamato PCF InterFrame Space (PIFS). Il PIFS è sempre
minore del Simple InterFrame Space (SIFS).
Per una spiegazione più dettagliata riguardo al PCF si rimanda al testo [16].
4.1.3 Il MAC 802.11e
Il gruppo di lavoro 802.11e ha proposto uno sviluppo del protocollo MAC
precedentemente descritto, definendo una unica funzione di coordinamento
Hybrid Coordination Function (HCF).
L’HCF combina le funzioni di DCF e PCF con l’aggiunta di alcune proprietà
specifiche per la QoS. L’HCF utilizza per il controllo d’accesso al canale
67
Configurazione di nodi wireless con supporto della qualità del servizio
l’Enhanced Distributed Coordination Function (EDCF). Le stazioni che operano
con il protocollo 802.11e sono chiamate Enhanced Station e in modo opzionale
possono operare come controllore centralizzato per le altre stazioni associate
nello stesso gruppo.
Generalmente questa funzione denominata Hybrid Coordinator (HC) viene
svolta dall’Access Point (AP). Un AP insieme al gruppo di stazioni ad esso
associate forma un Basic Service Set (BSS), mentre se questi componenti sono
compatibili con le specifiche del 802.11e l’insieme viene chiamato QoS Basic
Service Set (QBSS).
Figura 4.2: Categorie di accesso della EDCF
L’EDCF realizza la QoS introducendo delle categorie di traffico, in modo da
gestire otto differenti priorità. Il valore della priorità, detto Traffic Category
Identification (TCID), è memorizzato all’interno dell’header del pacchetto MAC.
68
Configurazione di nodi wireless con supporto della qualità del servizio
Una stazione 802.11e deve avere almeno quattro categorie d’accesso (AC) e al
massimo otto, una per ogni priorità. Ogni categoria d’accesso corrisponde ad
una variante estesa della coda FIFO presente nel DCF (figura 4.2).
Ogni pacchetto che arriva al livello MAC viene indirizzato in una categoria di
accesso in base alla priorità. È da notare come la priorità di valore 0 riceve una
priorità relativa tra il livello 2 e il livello 3 (in accordo con le specifiche IEEE
802.1d).
I parametri che influenzano il tempo di attesa prima della trasmissione sono
assegnati in funzione della categoria d’accesso del pacchetto elaborato. I
parametri utilizzati sono CWmin[AC], CWmax[AC] e AIFSD[AC], quest’ultimo
utilizzato in sostituzione del DISF presente nel DCF. L’AIFSD è calcolato in
questo modo:
AIFSD[AC] = SIFS + AIFS[AC] · SlotTime
I valori di CWmin[AC], CWmax[AC] e AIFSD[AC] sono determinati e comunicati
dall’AP attraverso dei beacon frame trasmessi periodicamente (generalmente
ogni 100 msec). L’AP può adattare questi parametri alle condizioni della rete e
utilizzarli per differenziare la priorità d’accesso alle diverse categorie di traffico.
Ogni coda associata ad un AC possiede un proprio valore di AIFS e un proprio
contatore di BO. Se più code finiscono il proprio BO contemporaneamente, la
collisione viene gestita in modo virtuale trasmettendo il pacchetto a più alta
priorità e riassegnando un BO agli altri con CW aumentato.
In [18] sono riportati i risultati di alcune simulazioni effettuate sul meccanismo
EDCF.
69
Configurazione di nodi wireless con supporto della qualità del servizio
4.2 Procedure di handoff
Quando un utente mobile si sposta, tipicamente si trova nella condizione di dover
lasciare l’area di copertura radio del suo fornitore di servizi per entrare nell’area
servita da un altro provider.
Occorre quindi gestire questo tipo di transizione denominata handoff o
handover.
Per poter capire meglio cosa si intende per handoff, è opportuno distinguere tra
due tipologie principali [19],[20]:
•
si verifica un Intra-Segment Handoff quando il terminale si sposta in
un’area servita da più celle della stessa natura di rete; questo tipo di
handoff avviene molto spesso spostandosi con un terminale GSM e
passando da una zona di copertura di una stazione base ad una zona
servita da un’altra. In questo caso vengono attivate delle procedure di
Intra-Segment Handoff che permettono al terminale mobile di spostare il
suo punto di accesso alla rete e che venga garantita la qualità del servizio
prevista nel passaggio da una stazione base all’altra;
•
si verifica un Inter-Segment Handoff quando il terminale si sposta in
un’area servita da più stazioni base, ad esempio quando si muove in
un’area coperta dal servizio GPRS verso un’altra area coperta da servizi
WLAN e ci si troverà nelle condizioni di eseguire un handoff tra elementi
di reti differenti. Il terminale in tal caso dovrà prevedere un sistema
70
Configurazione di nodi wireless con supporto della qualità del servizio
d’accesso multi-segmento. Quando il terminale si sposta dalla zona
servita dal GPRS a quella servita dalla WLAN dovrà attivare delle
procedure di Inter-Segment Handoff per assicurare che le comunicazioni
attivi rimangano tali.
Quindi l’Intra-Segment Handoff è applicato correntemente nelle reti cellulari
commerciali mentre l’Inter-Segment Handoff, che sarà oggetto di discussione in
seguito, non è attualmente molto utilizzato.
Per essere eseguito, il processo di handoff richiede innanzitutto la conoscenza
dello stato dei link radio ed eventualmente la possibilità di prevedere come
evolveranno in futuro.
La conoscenza dello stato delle connessioni può permettere di effettuare delle
scelte e quindi di eseguire il passaggio della connessione da un link ad un altro
reputato più conveniente.
Da ciò si evince che il processo si può pensare divisibile in tre fasi:
•
una fase di Information Gathering, nella quale vengono raccolte
informazioni sulla qualità radio dei segmenti d’accesso;
•
una fase di Decision, in cui sulla base delle misure raccolte si decide se
è necessario eseguire l’handoff, cioè spostare la comunicazione dal
segmento “corrente” ad un altro dei segmenti disponibili;
•
una fase di Execution : una volta presa la decisione viene stabilita una
nuova connessione sul segmento scelto e la vecchia connessione viene
rilasciata.
La qualità del processo di handoff dipende molto da come e con che cura
vengono eseguite queste fasi: in particolare la fase di Information Gathering
presuppone una scelta attenta dei parametri radio da considerare ed altrettanta
71
Configurazione di nodi wireless con supporto della qualità del servizio
importanza è data all’interpretazione di tali parametri.
4.2.1 Strategie di attivazione dell’handoff
L’attivazione del processo di handoff può avvenire per varie ragioni: la prima è il
mero spostamento di un utente da una zona di copertura ad un’altra ma può
essere anche generato a causa della degradazione del segnale radio e può
essere attivato da procedure di gestione della rete.
Di seguito si riportano le diverse condizioni che possono attivare il processo di
handoff:
•
le variazioni dei link radio percepiti possono determinare la necessità di
eseguire l’handoff; ad esempio se il livello del segnale radio ricevuto in
una certa zona diminuisce troppo, significa che verosimilmente stiamo
uscendo da questa zona di copertura e quindi si rende necessario il
trasferimento delle connessioni su un altro link più affidabile;
•
la necessità di eseguire un cambio di segmento può nascere anche da
condizioni della rete fissa; ad esempio se la rete attuale è congestionata
può essere conveniente spostare le connessioni su un segmento più
scarico;
•
non tutti i segmenti wireless sono in grado di assicurare la stessa qualità
del servizio e quindi possono essere adatti o meno ad essere usati per
determinate applicazioni per cui anche l’utente, richiedendo un servizio
particolare, può determinare la necessità di spostare le sue connessioni su
un segmento piuttosto che su un altro;
•
un’altra motivazione per eseguire un handoff è quella di prevedere degli
eventi; ad esempio, conoscendo l’attuale direzione e posizione – dati
72
Configurazione di nodi wireless con supporto della qualità del servizio
facilmente ottenibili utilizzando un sistema GPS (Global Positioning
System) - e conoscendo “l’ambiente” si può sapere in anticipo se il
terminale mobile sta uscendo dalla zona di copertura del segmento nel
quale si trova in un determinato momento e quindi attivare la procedura
di handoff.
4.2.2 Schemi di controllo dell’handoff
Esistono diverse modalità di controllo dell’handoff che si differenziano le une
dalle altre per la quantità di segnalazione, per le prestazioni e per la complessità
richiesta agli apparati della rete o del terminale mobile.
Di seguito si riporta uno schema delle differenti strategie.
Handoff
Schema
Controllo
Handoff
Handoff
Controllato
Da Rete
Handoff
Controllato
Da Mobile
Schema
Attivazione
Connessione
Handoff
Assistito
Da Rete
Handoff
Assistito
Da Mobile
Handoff
Verso Dietro
Schema
Trasferiment
o
Handoff
Verso Avanti
Switched
Diversity
Soft
Handoff
Hard
Handoff
Signalling
Diversity
Combined
Diversity
Schema 4.1: Strategie di handoff
Si vede che esistono diverse metodologie di controllo dell’handoff che si basano
su chi esegue il controllo del link radio e su chi esegue la decisione.
73
Configurazione di nodi wireless con supporto della qualità del servizio
Si possono distinguere quattro schemi di controllo dell’handoff.
4.2.2.1 Mobile Controlled Handoff (MCHO)
Lo schema di controllo MCHO prevede che il terminale mobile esegua tutte le
azioni; ossia è il terminale mobile ad effettuare le misure sui diversi segmenti
wireless ed in base a queste è sempre il terminale mobile a prendere la decisione
di effettuare l’handoff; in questo modo otteniamo che la segnalazione tra la rete
e il terminale mobile relativa all’handoff è praticamente nulla.
Il lato negativo di questo schema è che le decisioni sono prese considerando lo
stato di un solo link radio, ovvero quello detto downlink, e non viene
considerato l’altro capo della connessione, il cosiddetto uplink, che potrebbe
essere influenzato da fenomeni di shadowing e di fading. Inoltre, questo
schema comporta una maggiore complessità del terminale mobile.
Utilizzando questo schema si ottiene un handoff molto veloce; questo metodo è
utilizzato dal Digital Enhanced Cordless Telecommunications (DECT) che
presenta tempi di handoff compresi trai 100 e i 500 ms.
4.2.2.2 Network Controlled Handoff (NCHO)
Questo schema di controllo prevede che la rete si occupi sia di acquisire le
informazioni relative ai segnali radio, sia di prendere la decisione di
effettuare un handoff.
Questo metodo permette di avere un basso signalling tra rete e il
terminale e permette di semplificare notevolmente i terminali mobili dato
che
il
carico
elaborativo
per
quanto
riguarda
l’handoff,
è
tutto
74
Configurazione di nodi wireless con supporto della qualità del servizio
concentrato sulla rete fissa.
Un limite è nel fatto che basando le decisioni sulle sole misure di segnale
in uplink non si riesce ad un quadro completo dei link radio e quindi si
possono prendere decisioni poco affidabili.
Altro problema è la lentezza dell’algoritmo: infatti la rete corrente non ha
la capacità di misurare le risorse radio delle altre reti d’accesso e quindi
le procedure di handoff richiedono un notevole volume di segnalazione
tra la rete corrente e le altre reti.
4.2.2.3 Mobile Assisted Handoff (MAHO)
In questo schema la decisione è presa solo dalla rete ma le misure sui
link radio sono effettuate da entrambe le entità: la rete effettua misure
sull’ uplink e il terminale mobile sul downlink; queste vengono mandate al
nodo di rete per essere processate.
La frequenza con cui il terminale mobile effettua le misure sul link è
molto importante perché una frequenza troppo bassa può fornire dati
obsoleti, mentre una frequenza troppo alta può creare un traffico di
segnalazione troppo elevato rispetto al traffico dati utente e quindi ridurre
le prestazioni della rete.
Questo schema è affidabile anche se non molto veloce e presenta una
complessità modesta per il terminale mobile ma alta per il nodo di rete.
Una rete che utilizza questo schema è la GSM
75
Configurazione di nodi wireless con supporto della qualità del servizio
5.2.2.4 Network Assisted Handoff (NAHO)
In questo schema la decisione è presa solo dal terminale mobile ma le
misure sui link radio sono effettuate da entrambe le entità: la rete
effettua misure sull’ uplink e il terminale mobile sul downlink; le misure
effettuate dalla rete devono essere trasmesse al terminale mobile con
opportuni messaggi di segnalazione.
Lo schema proposto è molto affidabile e veloce dato che le decisioni
sono prese solo dal terminale mobile; ma come nel caso MAHO, si genera
un traffico di signalling abbastanza pesante ed una elevata complessità del
terminale mobile.
La tabella seguente riassume le principali caratteristiche degli schemi di
controllo visti.
Schema
MCHO
NCHO
MAHO
NAHO
Centralizzato
Centralizzato
Decentralizzato
Decentralizzato
Alta
Bassa
Moderata
Alta
Veloce
Lento
Lento
Veloce
Dimensione del signalling
Contenuta
Contenuta
Alta
Alta
Affidabilità
Moderata
Moderata
Alta
Alta
Processo di handoff
Complessità del terminale
Velocità dell’handoff
Tabella 4.1: Confronto tra gli schemi di handoff
76
Configurazione di nodi wireless con supporto della qualità del servizio
4.2.3 Schemi di attivazione della connessione
Per avviare o trasferire una connessione è necessario uno scambio di
segnalazione tra il terminale mobile e la rete. Nel caso di un trasferimento di
connessione la segnalazione può essere instradata sul nuovo canale oppure sul
vecchio canale che dovrà in seguito essere rilasciato.
Otteniamo quindi due metodi:
•
il metodo Backward Handoff
che utilizza il vecchio canale di
comunicazione per scambiare la segnalazione con la rete; questo metodo
non è molto affidabile perché se il vecchio link deve essere abbandonato
a causa di instabilità, non vi è assicurazione che la procedura di signalling
vada a buon fine prima della caduta del link provocando in tal caso la
perdita delle connessioni aperte;
•
il metodo Forward Handoff prevede di utilizzare il nuovo link per
scambiare la segnalazione con la rete; in tal caso anche la caduta
improvvisa del vecchio link non influenza il completamento della
procedura e quindi il trasferimento delle connessioni sul nuovo
segmento.
4.2.4 Schemi di trasferimento della connessione
Il trasferimento di una connessione da un link ad un altro può essere eseguito
in diversi modi; la classificazione tiene conto di come vengono gestite le risorse
radio e del modo in cui si instrada la segnalazione.
Si individuano tre categorie principali:
•
un primo metodo, il Soft Handoff , si presenta quando in corrispondenza
dell’handoff, le risorse radio relative al vecchio link vengono rilasciate
77
Configurazione di nodi wireless con supporto della qualità del servizio
solo quando il nuovo link è attivo; questo metodo permette di eseguire
un handoff completamente trasparente all’utente.
In relazione a come viene trasferito il signalling, nel Soft Handoff si
distinguono due casi:
o se la segnalazione passa su uno solo dei link attivi si parla di
Switched Diversity
o se la segnalazione passa su entrambi i link contemporaneamente
si parla di Combined Diversity;
La realizzazione del Soft Handoff presenta molti problemi legati alla
sincronizzazione della segnalazione nel caso di handoff tra link
eterogenei. Una soluzione è data dalla metodologia Signalling Diversity:
con questo sistema per la segnalazione viene creato un canale apposta
che fa coesistere insieme il vecchio ed il nuovo link; su questo canale
viaggia la segnalazione necessaria ad istaurare una nuova connessione e
a trasferire i flussi dati utente, in modo che tutto sia trasparente
all’utente stesso, e quella necessaria al rilascio della connessione
abbandonata;
•
un altro metodo è l’Hard Handoff: si verifica quando il vecchio link viene
rilasciato prima che il nuovo venga attivato; in questo caso lo
spostamento del punto di accesso, da una rete all’altra provoca
l’interruzione del servizio.
La rete GPRS adotta algoritmi di Hard handoff.
4.2.5 L’handoff a livello Rete
Fino ad ora si è discusso dell’handoff dal punto di vista metodologico ed
78
Configurazione di nodi wireless con supporto della qualità del servizio
architetturale e si è parlato di connessioni e di segmenti wireless eterogenei;
ora analizzeremo come si instaura una connessione e come si può trasferire una
connessione attiva da un segmento wireless ad un altro.
4.2.5.1 Il Protocollo IP e gli handoff
Il protocollo di rete più diffuso è senza dubbio l’IP (Internet Protocol); esso è il
protocollo principale del livello 3 dell’architettura TCP/IP [21]. È un protocollo
semplice, non connesso e non affidabile cioè non garantisce che l’informazione
spedita arrivi a destinazione; il suo compito principale è instradare i messaggi
sulla rete.
La comunicazione tra due host attraverso una rete generica formata da host e
router, è eseguita tramite lo scambio di pacchetti; questi pacchetti contengono
l’indirizzo IP della sorgente e l’indirizzo IP del destinatario. Il singolo pacchetto
si trova ad attraversare durante il suo percorso molti router che devono essere
in grado di sapere come instradare il pacchetto. Questa decisione è presa in
relazione alla “tabella di routing” che ogni router possiede e che contiene le
associazioni tra rete di destinazione e di interfaccia a cui devono essere inviati
pacchetti.
Partendo dall’host sorgente, ogni nodo della rete sa a quale nodo vicino deve
essere instradato il pacchetto per raggiungere la destinazione. Questo metodo,
prevede che ogni router mantenga una completa tipologia della rete in modo da
conoscere la destinazione di ogni singola sottorete; questo può andare bene per
reti limitate, ma quando si considerano reti di decine di migliaia di nodi, diventa
indispensabile ricorrere ad un’architettura di tipo gerarchico; si pensa così di
dividere la rete in varie Regioni.
Quindi un utente comunica con tutti gli altri della rete attraverso il suo indirizzo
79
Configurazione di nodi wireless con supporto della qualità del servizio
IP. Se questo host vuole muoversi deve utilizzare una connessione wireless con
la rete e se questa connessione non è grado di servirlo in tutti i suoi movimenti
deve dotarsi di più connessioni senza filo di tipo eterogeneo.
Un terminale del genere dovrà perciò avere un’interfaccia per ogni rete wireless
a cui collegato.
Ogni interfaccia ha caratteristiche dipendenti dal link radio considerato ma
queste differenze sono limitate dal livello fisico e da quello Data Link; esse sono
trasparenti rispetto al livello rete: ad ogni interfaccia è quindi assegnato un
indirizzo IP compatibile con la sottorete del relativo segmento wireless.
Un terminale siffatto sarebbe quindi raggiungibile da una rete differente
utilizzando ogni volta un indirizzo IP differente e questo di fatto lo renderebbe
inutilizzabile!
La soluzione a questo problema semplice ed è ottenibile utilizzando il protocollo
Mobile IP di cui si parlerà ampiamente in seguito.
Il problema dell’handoff, limitatamente all’esecuzione dello stesso, può essere
risolto impiegando il protocollo Mobile IP e modificando le tabelle di routing del
terminale.
80
Configurazione di nodi wireless con supporto della qualità del servizio
4.3 Il protocollo Mobile IP
L’importanza della mobilità nelle reti informatiche cresce di pari passo allo
sviluppo delle tecnologie di comunicazione wireless ed alla diffusione dei mezzi
di comunicazione portatili quali laptop, telefoni cellulari, computer palmari.
Questa richiesta di mobilità di comunicazione ovunque e comunque e di
interconnessione globale si basa su reti terrestri preesistenti, collegate tra loro
con mezzi diversi e gestite con politiche diverse.
Internet invece utilizza come protocollo di rete il protocollo IP.
Quando l’IP fu implementato, non si prese in considerazione il problema della
mobilità dei terminali poiché date le dimensioni dei computer dell’epoca, essi
erano necessariamente fissi.
Quando un terminale di rete si sposta da un luogo ad un altro, vale a dire se
non si trova più connesso al link corrispondente al prefisso di rete del suo
indirizzo IP, il protocollo IP prevede che il nodo sia considerato come non più
raggiungibile; vale a dire che i pacchetti spediti a quel nodo non saranno più
giudicati consegnabili e saranno scartati.
Per fare in modo che il nodo possa riprendere a comunicare dalla sua nuova
locazione, è necessario modificare le tabelle di routing di quei nodi che si
occupano dell’instradamento dei pacchetti indirizzati verso quel determinato
nodo mobile.
81
Configurazione di nodi wireless con supporto della qualità del servizio
Questa soluzione presenta notevoli problemi di scalabilità: ogni qualvolta un
terminale mobile si sposta, bisogna modificare la configurazione di tutti i router
attraversati dal flusso di pacchetti diretti quel terminale e ciò deve avvenire per
ogni singolo utente mobile che si sposta.
Un’altra soluzione al problema sarebbe quella di cambiare l’indirizzo IP del nodo
mobile e renderlo compatibile con la rete corrente.
Anche questa soluzione presenta dei problemi: cambiare l’indirizzo IP significa
chiudere tutte le connessioni attive nel momento del passaggio da una rete
all’altra; e poi cambiando l’indirizzo IP al nodo mobile, bisognerà aggiornare
tutti gli altri nodi che vogliono comunicare con lui.
Una soluzione efficiente e semplice al problema è data dall’introduzione di un
nuovo protocollo basato su IP: il Mobile IP.
Il Mobile IP (Mobile Internet Protocol) [22] è stato sviluppato nel 1996 per
assicurare la mobilità di un utente: rappresenta un’estensione del protocollo di
rete IP pensata per permettere proprio la mobilità di un utente; è una soluzione
scalabile, robusta e sicura e permette ai nodi mobili, anche durante lo
spostamento da un link all’altro, di mantenere attive tutte le comunicazioni in
corso.
In seguito si vedrà che l’utilizzo di tale questo protocollo è sconsigliato nei casi
in cui la rete da gestire sia molto estesa e verrà proposta una soluzione per
aggirare il problema utilizzando un altro protocollo, il Cellular IP, che sarà di
supporto al Mobile IP.
L’utilizzo del protocollo Mobile IP è trasparente ai protocolli di livello superiore
ed è altrettanto trasparente nodi e ai router attraversati dai flussi dati.
Il Mobile IP è un protocollo semplice, che richiede pochi messaggi di signalling,
82
Configurazione di nodi wireless con supporto della qualità del servizio
riservando in tal modo poca banda al protocollo stesso: questo è utile quando si
utilizza, come accade spesso per i sistemi mobili, un link di connessione wireless
caratterizzato da una banda limitata.
4.3.1 Il funzionamento di Mobile IP
Il problema discusso prima che ha richiesto l’ampliamento del protocollo IP è
che un nodo, quando si sposta, non può utilizzare il suo vecchio IP Address in
quanto questo, collegato ad una nuova rete, diventa irraggiungibile.
Con il protocollo Mobile IP si è pensato di associare ad ogni utente mobile due
indirizzi IP, uno della rete originaria detta home network ed uno della rete
correntemente utilizzata, chiamata foreign network.
I due indirizzi IP assegnati al modo mobile sono:
•
home-address: rappresenta l’indirizzo assegnato al nodo mobile dalla
rete di origine, quella che è stata chiamata la home network; questo
indirizzo è stabilmente attribuito al terminale mobile;
•
care-of-address: rappresenta l’indirizzo temporaneo assegnato al nodo
mobile dalla rete che lo ospita, ovvero dalla foreign network.
Il protocollo Mobile IP introduce delle entità con ben precise funzionalità e
caratteristiche:
•
il Mobile node rappresenta il terminale che si muove; questo terminale
deve quindi poter cambiare il punto di connessione alla rete pur
mantenendo il suo il suo indirizzo IP - cioè l’home address - e l’accesso
alle risorse; esso deve anche continuare ad essere raggiungibile;
•
l’Home Agent rappresenta un nodo ben determinato della home network
dell’utente mobile: le sue funzionalità sono essenzialmente di routing e di
83
Configurazione di nodi wireless con supporto della qualità del servizio
instradamento dei pacchetti al terminale mobile quando questi è lontano
dalla sua home network. La Home Agent mantiene quindi le giuste
informazioni sulla posizione corrente del nodo mobile;
•
il Foreign Agent rappresenta un router della rete ospite, cioè della foreign
network, e la sua funzione è assegnare il care-of-address e consegnare i
pacchetti al nodo mobile spediti dalla Home Agent.
Il protocollo Mobile IP risolve il problema della mobilità introducendo un’entità
router, l’Home Agent, che tiene traccia della posizione dell’utente mobile ed è
quindi in grado, tramite un Tunnelling di recapitare i pacchetti a questi
destinati.
L’applicazione del protocollo Mobile IP prevede una serie di messaggi scambiati
tra le diverse entità:
•
Foreign Agent e Home Agent (chiamati anche Mobility Agent)
pubblicizzano
la
loro
presenza
attraverso
messaggi
di
Agent
Advertisement; un nodo mobile può sollecitare l’emissione di tali
informazioni attraverso messaggi di Agent Solicitation;
•
il nodo mobile ricevendo un messaggio di Agent Advertisement
determina se si trova nella sua home network o in una foreign network;
•
se il nodo mobile si ricollega alla sua home network, ossia abbandona una
foreign network e torna nella sua rete primaria, allora si deregistra con il
suo Home Agent attraverso i messaggi di Registration Request e
Registration Reply;
84
Configurazione di nodi wireless con supporto della qualità del servizio
•
se il nodo mobile si collega ad una nuova foreign network, gli viene
assegnato un nuovo care-of-address; l’assegnazione può essere ottenuta
mediante un advertisement spedito da un Foreign Agent (che verrà
chiamato Foreign Agent care-of-address) oppure tramite protocolli tipo
DHCP (co-located care-of-address).
85
Configurazione di nodi wireless con supporto della qualità del servizio
•
quando il nodo mobile ha ottenuto un nuovo care-of-address deve
comunicarlo
all’Home
Agent.
La registrazione
avviene
attraverso
messaggi di Registration Request e Registration Reply scambiati
direttamente con l’Home Agent oppure tramite il Foreign Agent:
•
l’Home Agent, una volta registrato il care-of-address di un nodo mobile,
è in grado di intercettare i pacchetti ad esso destinati, cioè destinati
all’home address del nodo mobile, e mediante un tunnelling può
reinstradarli da questo verso l’indirizzo care-of-address del nodo mobile.
Il punto di uscita del tunnel può essere il nodo mobile o il Foreign Agent;
86
Configurazione di nodi wireless con supporto della qualità del servizio
•
i pacchetti spediti dal nodo mobile sono consegnati alla destinazione (il
cosiddetto correspondent node) usando i meccanismi standard di
routing;
87
Configurazione di nodi wireless con supporto della qualità del servizio
Quindi il traffico diretto all’utente mobile e proveniente da un nodo qualsiasi
della rete, cioè dal correspondent node, raggiunge la Home Network, viene
intercettato dall’Home Agent che lo incapsula e lo instrada verso il care-ofaddress attuale del nodo mobile.
I pacchetti spediti dal nodo mobile sono direttamente inviati al correspondent
node.
Tutto il meccanismo anzidetto si basa sulla capacità del nodo mobile di
determinare, tramite processi di Agent Discovery, il passaggio della sua
connessione da una rete ad una altra; questo permette al nodo mobile di
ottenere il care-of-address e di registrarlo presso il suo Home Agent.
88
Configurazione di nodi wireless con supporto della qualità del servizio
4.3.2 Meccanismi di Agent Discovery
Il modo con cui il nodo mobile riesce a capire se è connesso alla sua home
network oppure è collegato ad una foreign network o se si è spostato su
un’altra foreign network, è l’Agent Discovery [23].
Il protocollo Mobile IP per realizzare il meccanismo di Agent Discovery utilizza i
messaggi ICMP di Router Discovery ed amplia questi messaggi con delle
estensioni. Queste estensioni sono formate da tre campi: il tipo di estensione, la
lunghezza ed un campo contenente l’informazione vera e propria.
I messaggi utilizzati sono: Agent Advertisement ed Agent Solicitation.
Gli Agent Advertisement sono messaggi emessi dai Mobility Agent, sia da
Home Agent che da Foreign Agent, per informare i terminali mobili della loro
presenza. Un Agent Advertisement è un ICMP Router Advertisement esteso
con l’estensione Mobility Agent Advertisement.
L’estensione Mobility Agent Advertisement segue i campi dell’ICMP Router
Advertisement e contiene:
•
il Type di messaggio, che in questo caso vale 16;
•
il Registration Lifetime che rappresenta il massimo tempo (espresso in
secondi) che questo agent può accettare nei messaggi di Registration
Request; il nodo mobile utilizza questo valore per la richiesta di
registrazione;
•
i campi che indicano che tipo di Agent, Foreign o Home, che ha emesso il
messaggio ed il tipo di compressione ed encapsulation;
•
il care-of-address che fornisce l’agent.
Quando il nodo mobile si sposta in una foreign network riceve un messaggio di
Agent Advertisement da un Foreign Agent, se questo è presente:
89
Configurazione di nodi wireless con supporto della qualità del servizio
Il messaggio di Agent Advertisement ha nell’header IP come indirizzo sorgente
l’indirizzo del Foreign Agent, come indirizzo di destinazione un indirizzo
broadcast o multicast e il campo Protocol impostato a 1 (che corrisponde al
messaggio ICMP).
L’ICMP Router Advertisement che segue l’header IP, ha il campo Type posto a 9
per identificare il messaggio ICMP come un advertisement ed il campo lifetime
impostato ad un valore che indica con quale frequenza il Foreign Agent spedisce
gli advertisement.
Infine l’estensione Mobility Agent Advertisement, che segue l’ICMP Router
Advertisement, contiene il care-of-address che il nodo mobile dovrà utilizzare.
Gli Agent Solicitation sono messaggi emessi dai nodi mobili per sollecitare gli
Agent Advertisement; sono identici ai messaggi ICMP Router Solicitation (con la
sola restrizione che il campo Time To Live del pacchetto IP deve essere posto a
1). Il valore 10 per il campo Type dell’ICMP Router Solicitation distingue il
messaggio di sollecitazione dagli altri tipi di messaggi ICMP.
4.3.3 Cambiamento di rete
Quando un nodo mobile spostandosi cambia rete di accesso, deve riuscire a
90
Configurazione di nodi wireless con supporto della qualità del servizio
ottenere al più presto le informazioni indirizzate ad esso.
La sollecitudine con cui si riesce ad attivare le operazioni opportune, rappresenta
uno dei parametri per quantizzare il livello di prestazioni della rete.
Ci sono due meccanismi attraverso i quali un nodo mobile può capire se ha
cambiato rete di acceso: il primo è basato sul campo lifetime dell’ICMP Router
Advertisement: un nodo mobile monitorizza i messaggi di Agent Advertisement
che riceve da un Agent e controlla se sono cadenzati di un tempo lifetime; se
non riceve alcun Advertisement dallo stesso Agent entro il lifetime specificato
allora può presumere di aver cambiato collegamento, quindi deve cercare un
altro Mobile Agent a cui registrarsi.
Il secondo metodo consiste nell’analizzare tutti gli Agent Advertisement e
confrontare l’indirizzo di rete del mittente con il corrente care-of-address che è
utilizzato dal nodo mobile: se questi indirizzi sono differenti significa che i due
Agent Advertisement sono stati ricevuti su differenti link e quindi che il nodo
mobile ha cambiato posizione.
4.3.4 Procedura di registrazione presso l’Home Agent
Una volta ottenuto il care-of-address da un foreign agent o da un DHCP, se un
nodo mobile connesso ad una foreign network vuole essere raggiungibile deve
registrarsi presso il suo Home Agent o meglio registrare il nuovo care-ofaddress. Il nodo mobile deve anche rinnovare la registrazione prima dello
scadere del lifetime altrimenti la Home Agent lo elimina dalla lista dei terminali
mobili attivi rendendolo irraggiungibile.
Il nodo mobile si registra attraverso l’invio un messaggio di Registration
Request, direttamente presso il suo Home Agent se ha ottenuto il care-ofaddress da un DHCP oppure invia la richiesta al Foreign Agent che gli
91
Configurazione di nodi wireless con supporto della qualità del servizio
ha fornito l’indirizzo IP. Il Foreign Agent analizza la richiesta e la invia al
corrispondente Home Agent.
In presenza di una Registration Request, l’Home Agent controlla la richiesta e
risponde con Registration Reply. Il messaggio Registration Request è contenuto
in un pacchetto UDP ed include:
•
il Type del messaggio, che in questo caso vale 1;
•
un campo che specifica il Simultaneous Bindings: il nodo mobile richiede
all’Home Agent di mantenere la precedente (o le precedenti) binding
table;
in
questo
modo
restano
validi
tutti
i
care-of-address
precedentemente utilizzati: questa funzionalità è molto utile per
implementare meccanismi di Soft Handoff;
•
il lifetime che rappresenta il numero dei secondi rimanenti prima che la
registrazione sia considerata scaduta;
•
il care-of-address, cioè l’indirizzo IP del punto di uscita del tunnel; nel
caso particolare in cui il nodo mobile torni nella sua home network e cioè
desideri deregistrare tutti i suoi care-of-address, questo campo deve
essere riempito con l’home address che fornisce l’Agent;
•
l’Home Address, cioè l’indirizzo IP del nodo mobile;
•
l’Home Agent, cioè l’indirizzo IP dell’Home Agent del nodo mobile;
•
l’Identification che è un parametro costruito dal nodo mobile per il
matching
tra
Registration
Request
e
Registration
Reply
e
per
salvaguardarsi dagli attacchi esterni.
Il messaggio di Registration Reply contiene tutte le informazioni necessarie per
informare il nodo mobile sullo stato della sua richiesta di registrazione.
Il messaggio di Registration Reply segue l’header UDP e contiene:
•
il Type di messaggio, in questo caso vale 3;
•
un Code che indica il risultato della Registration Request;
92
Configurazione di nodi wireless con supporto della qualità del servizio
•
l’Home Agent, cioè indirizzo IP dell’Home Agent del nodo mobile;
•
l’Identification che è un parametro usato per il matching tra Registration
Request e Registration Reply, e per salvaguardarsi dagli attacchi esterni.
Il campo Identification presente sia nel messaggio di Registration Request sia in
quello di Registration Reply è legato alla gestione di meccanismi di sicurezza.
Nella registrazione gli scenari possibili sono tre:
•
il nodo mobile si registra usando un foreign care-of-address;
•
il nodo mobile si registra usando un co-located care-of-address;
•
il
nodo
mobile
si
deregistra
perché
è
di
ritorno
sulla
sua
home network.
In ogni caso il nodo mobile spedisce un messaggio di Registration Request che
è formato da un header IP, da un header UDP, dalla vera e propria Registration
Request e dalla Mobile Home Authentication. L’Home Agent, una volta ricevuto
una Registration Request, spedisce un messaggio di Registration Reply
composto da un header IP, un header UDP, dal messaggio Registration Reply e
dalla Mobile-Home Authentication.
Il nodo mobile invia la Registration Request al Foreign Agent: questa richiesta di
registrazione ha come Source Address dell’header IP l’home address del nodo
mobile e come Destination Address, l’indirizzo del Foreign Agent; nella
Registration Request che segue l’header UDP, i campi lifetime e care-of-address
includono gli stessi valori contenuti nel messaggio di Agent Advertisement
spedito dal Foreign Agent e diretto al nodo mobile.
93
Configurazione di nodi wireless con supporto della qualità del servizio
Il Foreign Agent ricevuta la richiesta di registrazione spedisce un pacchetto
all’Home Agent. Questa Registration Request ha come Source Address
dell’header IP l’indirizzo del Foreign Agent, mentre il Destination Address è
l’indirizzo dell’Home Agent.
Il resto del messaggio è identico a quello prodotto dal nodo mobile.
Questo messaggio raggiunge l’Home Agent, viene controllato e quindi avviene
l’aggiornamento della binding table con una riga contenente la tripla Home
Address, care-of-address, lifetime.
A questo punto l’Home Agent genera un messaggio di Registration Reply diretto
al Foreign Agent e quest’ultimo lo rigira al nodo mobile.
94
Configurazione di nodi wireless con supporto della qualità del servizio
Se la Foreign Network non possiede un Foreign Agent, lo scambio di messaggi è
direttamente tra il nodo mobile e Home Agent. Il nodo mobile ottiene il co-
located care-of-address da un DHCP. La registrazione, analogamente al caso
precedente, inizia con un messaggio di Registration Request dal nodo mobile
che contiene l’header IP il cui Source Address è riempito con il care-of-address
assegnato al nodo e il Destination Address è l’indirizzo dell’Home Agent.
Inoltre nella Registration Request il campo lifetime è impostato arbitrariamente
dal nodo mobile
95
Configurazione di nodi wireless con supporto della qualità del servizio
La Registration Request ha come Home Source Address l’home address del
nodo mobile e come Destination Address l’indirizzo IP dell’Home Agent. II
campo lifetime è impostato a 0 indicando in tal modo all’Home Agent il desiderio
del nodo mobile di deregistrarsi. Il campo care-of-address è riempito con l’home
address del nodo mobile. Quando l’Home Agent riceve la Registration Request,
aggiorna la binding table e risponde al nodo mobile con un messaggio di
Registration Reply inserendo nel campo Lifetime il valore 0.
4.3.5 L’IP Mobility ed i messaggi ARP
Nelle reti IP per conoscere gli indirizzi di livello Data Link di un host della stessa
sottorete, conoscendo l’indirizzo IP, si utilizza il protocollo ARP (Address
Resolution Protocol) [24]. Nel caso dell’IP Mobility il nodo mobile è connesso ad
un’altra network e quindi non è in grado di rispondere ai messaggi ARP, quindi
è l’Home Agent a farsi carico di rispondere con il proprio indirizzo MAC a tali
richieste.
Quindi l’Home Agent a tutti gli effetti si sostituisce al nodo mobile e per fare
questo utilizza dei messaggi ARP appositi:
•
Proxy ARP: è un particolare ARP Reply inviato a fronte di un ARP
Request indirizzato ad altro nodo incapace di rispondere;
•
Gratuitous ARP: è un ARP Request o ARP Reply usato per forzare tutte
le macchine della sottorete all’aggiornamento delle loro tabelle ARP.
Quando l’Home Agent intercetta un ARP Request diretta ad un nodo mobile che
gestisce, risponde utilizzando un Proxy ARP indicando come indirizzo di livello
Data Link quello associato alla sua interfaccia di rete.
96
Configurazione di nodi wireless con supporto della qualità del servizio
Quando un nodo mobile si registra al suo Home Agent con un care-of-address,
oltre alle già citate procedure di registrazione, invia in broadcast nella sottorete
un messaggio di Gratuitous ARP per costringere tutti i nodi della sottorete ad
aggiornare le loro tabelle ARP.
Le tabelle ARP dei nodi della home network assoceranno l’home address del
nodo mobile con l’indirizzo di livello data link dell’Home Agent.
Quando un nodo mobile torna nella sua home network, spedisce un messaggio
di Gratuitous ARP quindi si deregistra con il suo Home Agent. A
deregistrazione completata l’Home Agent invia a sua volta un messaggio
Gratuitous ARP; in tal modo tutti i nodi presenti nella home network
aggiorneranno le loro tabelle ARP associando all’home address l’indirizzo di
livello Data Link del nodo mobile.
97
Configurazione di nodi wireless con supporto della qualità del servizio
4.4 Cellular IP: un approccio all’Host Mobility
Questo documento presenta un nuovo modo di vedere Internet dal punto di
vista di un utente mobile.
Rimarcando la separazione che con il tempo è andata quasi dissolvendosi tra
aree locali e aree estese (cioè tra LAN e WAN), le prestazioni di alcuni protocolli
di connessione mobile proposti in passato (vedi Mobile IP) possono essere
significativamente migliorate.
Cellular IP è un protocollo leggero e allo stesso tempo robusto, ottimizzato per
supportare mobilità in aree locali e per interagire efficientemente con Mobile IP
fornendone una sorta di integrazione per fornire il supporto per la mobilità in
aree estese. Esso mostra enormi progressi rispetto alle altre proposte di
connessione mobile soprattutto per scenari dove gli utenti si muovono e
migrano frequentemente da una rete ad un’altra, situazione questa molto più
vicina ad una regola che ad un’eccezione in una realtà dove gli accessi wireless
ad Internet diventano sempre più frequenti nel tempo e nello spazio.
Questo protocollo mantiene delle cache distribuite per tutti i meccanismi di
gestione delle locazioni e del routing. Queste cache rimangono in stato di
inattività (o stato idle) per ogni utente ma vengono usate per determinare
velocemente e con efficienza gli utenti “idle” che vogliono impegnarsi per una
comunicazione attiva.
98
Configurazione di nodi wireless con supporto della qualità del servizio
Questo approccio è vantaggioso perché si possono allocare tanti clienti in una
rete senza sovraccaricare il sistema di gestione delle locazioni.
Altre cache dette di routing restano nello stato “attivo” nell’area dove è fornita
la connessione ma viene fatto un refresh dinamico dello stato di routing per
quegli utenti attivi che richiedono un handoff. In questo modo, gli algoritmi
distribuiti di gestione delle locazioni e del routing hanno un’implementazione
semplice e di basso costo e non sovraccaricano Internet giacché non richiedono
pacchetti in un nuovo formato né altra allocazione di spazio oltre a quella
normalmente richiesta dal protocollo IP.
4.4.1 Introduzione a Cellular IP
Data la dimensione sempre più ridotta dei computer portatili e la connessione a
una rete globale pressoché onnipresente, la domanda di fornire un accesso alla
rete agli utenti mobili è sempre più rapidamente in crescita.
La difficoltà di base della maggior parte dei protocolli che offrono questo tipo di
connessione [25][26][27][28] risiede nella natura dell’indirizzo IP che ha un
duplice significato: esso è infatti sia un identificativo univoco dell’utente (che
perciò
dovrebbe
essere
mantenuto
costante
indipendentemente
dalla
locazione), sia un parametro che identifica la posizione e che quindi deve
cambiare così come l’utente si sposta [29].
Questi sono due requisiti che vanno in competizione tra loro e che il protocollo
di connessione mobile dovrebbe risolvere efficientemente [29][30].
Il problema fondamentale da risolvere è la separazione di questi due ruoli e allo
stesso tempo si deve rendere disponibile una mappa di identificativi di utenti e
delle loro relative informazioni di localizzazione.
99
Configurazione di nodi wireless con supporto della qualità del servizio
Immaginiamo quindi un utente mobile in uno scenario in cui la connessione a
Internet avviene tipicamente in maniera wireless - anche se oggi questo è
ancora un’eccezione. Pensiamo quindi a un ambiente in cui sia presente un gran
numero di utenti mobili che si muovono e che spesso migrano da una zona ad
un’altra durante il trasferimento di dati e che si aspettano che la rete gestisca
questi handoff con il minimo disturbo sulla sessione.
Anche se è poco probabile (e poco prudente!) che si legga un testo o si guardi
un video mentre si guida o si cammina, si potrebbe comunque desiderare di
scaricare dati o di parlare a telefono sfruttando Internet mentre si è in
movimento.
Con la diffusione di computer portatili e palmari sempre più piccoli ed
economicamente convenienti, la visione di una rete globale di computer diventa
una realtà. Nasce così l’esigenza di un accesso wireless a Internet economico e
onnipresente. Si potrebbe addirittura pensare che in tale realtà la popolarità dei
telefoni cellulari possa essere offuscata dall’uso di palmari che supportino
Internet insieme ad una vasta gamma di servizi che si adattino perfettamente
ad ogni situazione senza il minimo intervento da parte dell’utente, un po’ come
avviene oggi per i telefonini.
In altre parole si può pensare che telefonini e computer palmari evolveranno
insieme verso un successore comune.
Si può vedere [28] che in uno scenario simile Mobile IP non rappresenta una
soluzione ottimale essendo meglio impiegato per mobilità di macro-livello dove
gli utenti si muovono lentamente e poco frequentemente. Infatti ad ogni
migrazione, Mobile IP prevede l’invio un messaggio di aggiornamento della
locazione verso una stazione server detta home agent che potrebbe anche
100
Configurazione di nodi wireless con supporto della qualità del servizio
trovarsi molto lontano: questo potrebbe da un lato avere effetti sulla latenza di
handoff e dall’altro sovraccaricare una parte della rete Internet.
Per sorpassare questa limitazione si introduce un approccio gerarchico della
gestione della mobilità: la soluzione è un’architettura formata da due livelli:
•
un primo livello è composto da più reti locali con accesso wireless che
gestiscono facilmente la mobilità locale;
•
un secondo livello comprende una grande rete Internet gestita da Mobile
IP che vi fornisce un servizio di mobilità per l’area estesa.
In questo caso una stazione home agent è informata del movimento di un host
solamente quando questo si sposta da una rete di accesso ad un’altra mentre
rimane all’oscuro degli spostamenti che effettuano gli host quando questi, pur
movendosi, restano nella stessa area di accesso (figura 4.3).
Figura 4.3: Compresenza di Celular IP e Mobile IP
Il vantaggio principale di dividere la mobilità tra l’area locale e estesa sta
proprio nel fatto che le home agent non hanno bisogno di essere informate
circa gli spostamenti locali all’interno delle aree di accesso wireless e questo
101
Configurazione di nodi wireless con supporto della qualità del servizio
diventa sempre più importante quando le celle diventano sempre più piccole, la
frequenza delle migrazioni più alta e la popolazione degli host più estesa.
Gestendo localmente la maggior parte degli handoff, possiamo studiare metodi
per renderli più veloci, limitare l’impatto che questi possono avere sulle sessioni
attive e inoltre evitare il problema delle migrazioni verso stazioni home agent
lontane.
Un ulteriore beneficio dell’approccio architetturale gerarchico della mobilità
sorge nel caso in cui un grande numero di utenti vuole spostarsi trasportando
computer portatili che hanno bisogno di essere permanentemente connessi a
Internet: questi utenti genererebbero frequenti messaggi di aggiornamento di
locazione anche non essendo attivamente in fase di trasmissione di dati.
La diminuzione della dimensione della singola cella porterebbe poi a un
aumento dei messaggi di servizio e il traffico da questi generato potrebbe
raggiungere un’entità paragonabile al traffico utile.
Quindi per permettere la connessione a un gran numero di utenti, il protocollo
di gestione della mobilità ha bisogno di uno schema di trasporto delle
informazioni di locazione che sia semplice e che allo stesso tempo non
sovraccarichi con traffico o processi la rete globale quando gli host sono in stato
idle. Ci riferiremo a questa proprietà chiamandola connessione passiva leggera
(cheap passive connectivity).
Per questi obiettivi viene utilizzato Cellular IP, un protocollo di mobilità
ottimizzato per reti ad accesso wireless con un gran numero di utenti.
Il primo obiettivo che Cellular IP si prefigge è la semplicità: il fatto che un AP
wireless di Cellular IP possa essere costituito da dispositivo un piccolo ed
economico (è necessaria una sola BS per ogni ufficio o per ogni piano) rende
102
Configurazione di nodi wireless con supporto della qualità del servizio
possibile un’applicazione per così dire “domestica”. D’altro canto Cellular IP può
essere implementato anche sui classici router IP per permettere delle migrazioni
più facili sui sistemi già installati e funzionanti.
Un altro obiettivo chiave è la scalabilità: il sistema di gestione distribuito rende
possibile l’uso dello stesso
protocollo e degli stessi nodi topologici (che
ricordiamo sono all’oscuro di ciò che inoltrano) sia in piccoli sistemi domestici,
sia in aree molto estese, sia addirittura in sistemi eterogenei.
Questo permette agli utenti di migrare liberamente e senza difficoltà tra aree
con diverse caratteristiche: si può pensare di ottenere una connessione dagli
operatori locali di telefonia cellulare che danno il servizio di Cellular IP e un
utente può ricevere una banda ampia per scaricare dati o per usare VoIP (Voice
over IP) mentre passeggia tranquillamente per strada e poi continuare a farlo
usando sempre lo stesso protocollo quando entra in un ufficio o in un edificio in
cui c’è una copertura wireless.
Si può vedere che fornire trasparenza insieme ad un supporto della qualità del
servizio indipendente dalla locazione non è un obiettivo semplice da ottenere
per protocolli di mobilità che lavorano in scenari wireless [29]. Cellular IP aggira
l’ostacolo fornendo scalabilità cioè la capacità di avere lo stesso protocollo in
ambienti diversi ottenendo sempre lo stesso servizio.
Questa proprietà inoltre permette ai gestori di rete di estendere la dimensione
della zona di servizio quando la domanda cresce. Ciò risulta molto importante
giacché la capacità globale dei sistemi wireless è determinata proprio dalla
densità delle BS e può essere estesa installando nuove apparecchiature che
portano con sé tutti i problemi relativi al costo.
Un altro vantaggio nell’uso di Cellular IP è la sua completa compatibilità con il
protocollo IP: non si richiede l’invio di pacchetti supplementari, non si
103
Configurazione di nodi wireless con supporto della qualità del servizio
richiedono ulteriori incapsulamenti, non si richiede spazio extra per gli indirizzi.
Il sistema di Cellular IP usa tre tipi di pacchetti di controllo che possono essere
implementate come opzioni di IP perciò non c’è alcun bisogno di aggiornare il
funzionamento dei regolari router IP.
Nel paragrafo seguente si propone un approccio alternativo al problema della
mobilità e lo paragona tale approccio al metodo di Cellular IP; nel paragrafo 3 si
presenta un nuovo modello di rete ad accesso wireless; nel paragrafo 4
vengono analizzate nel dettaglio le caratteristiche di Cellular IP; nel quinto e
sesto si discutono gli argomenti relativi all’implementazione.
4.4.2 Approccio alternativo alla gestione degli utenti mobili
Una soluzione che richieda agli utenti mobili un processo di aggiornamento
continuo, supporta portabilità ma non mobilità [29].
Il primo obiettivo quindi per un protocollo di mobilità è permettere all’utente di
cambiare punto di accesso senza una riconfigurazione manuale. Questo
requisito è fondamentale per la proprietà di trasparenza. Un utente potrebbe
desiderare di spostarsi durante il trasferimento di dati effettuando così un
cambio di punto di accesso mentre la connessione è attiva, operazione
chiamata migrazione o handoff.
Un’altra caratteristica importante per un protocollo che si occupa di utenza
mobile è la gestione di questi handoff senza disturbi significativi alla
trasmissione di dati.
104
Configurazione di nodi wireless con supporto della qualità del servizio
Si può vedere [30] che molti protocolli per la gestione di utenti mobili,
compreso il famoso IETF Mobile IP [31], possono essere considerati casi speciali
di un’architettura “a due livelli di indirizzamento” perché un utente mobile è
logicamente associato a due indirizzi IP:
•
un indirizzo detto home address assegnato dalla prima stazione (home
agent) che è un identificatore dell’utente e che rimane sempre lo stesso;
•
un altro indirizzo relativo all’attuale punto di collegamento a Internet,
dipendente perciò dalla posizione.
Quest’architettura generalizzata comprende tre componenti fondamentali:
•
una Tabella di Locazioni (Local Directory) cioè un data base
possibilmente distribuito che contiene i dati aggiornati relativi a ogni
utente e ai suoi due indirizzi;
•
un’Unità di Traduzione degli Indirizzi (Address Translation Agent) che
associa ad ogni utente l’indirizzo della destinazione dei pacchetti da esso
generati gestendo le richieste sia della Local Directory, sia di altre cache
locali;
•
un’Unità di Spedizione (Forwarding Agent) che assicura che i pacchetti
che arrivano all’utente mobile hanno un campo con l’home address e uno
con la destinazione finale.
Anche se queste soluzioni, in particolare quella dell’IETF Mobile IP, raggiungono
gli obiettivi di trasparenza operazionale e supporto degli handoff, sono in realtà
ottimizzate per gli utenti che si muovono molto lentamente e diventano
addirittura inefficienti nel caso di migrazioni frequenti [28].
Mobile IP richiede che la stazione home agent sia informata ogniqualvolta un
suo utente si muova verso un altro agent. Durante la fase di aggiornamento che
può durare non poco, alcuni utenti possono spostarsi e quindi i pacchetti a
105
Configurazione di nodi wireless con supporto della qualità del servizio
questi destinati verranno inoltrati verso una destinazione sbagliata con
conseguente disturbo per la trasmissione di dati.
Analogamente, durante l’ottimizzazione del processo di instradamento [32][33],
la trasmissione di dati sarà disturbata mentre il corrispondente host otterrà un
nuova connessione.
L’effetto di questi ritardi ovviamente cresce con l’aumento della frequenza di
migrazione.
Inoltre i messaggi di aggiornamento possono sovraccaricare sia Internet che la
home agent quando un utente si muove anche se non sta attivamente
trasferendo dati (stato idle).
L’entità del sovraccarico è proporzionale al numero degli utenti mobili e non al
traffico generato quindi si potrebbe venire a creare una situazione in cui un solo
utente sia in trasmissione attiva ma comunque incontri una rete sovraccaricata
da traffico di servizio.
Come se non bastasse, questo problema paradossalmente cresce con lo
sviluppo della mobilità perché la connessione deve essere onnipresente, le celle
più piccole e gli handoff più frequenti.
Per superare le limitazioni di Mobile IP, nasce un approccio di gestione della
mobilità di tipo gerarchico [28]. Sono definiti quindi tre livelli di mobilità:
•
il livello di mobilità locale;
•
il livello di mobilità all’interno di un dominio amministrativo;
•
il livello di mobilità globale.
Per ognuno di questi livelli viene proposto un protocollo di mobilità e Mobile IP
viene associato al livello di mobilità globale.
Cellular IP differisce da questo approccio per due aspetti importanti:
•
prima di tutto, invece di definire livelli gerarchici di mobilità, fornisce una
106
Configurazione di nodi wireless con supporto della qualità del servizio
struttura che può scalare da sistemi di piccoli uffici fino ad aree molto
estese. Infatti spesso queste aree possono trovarsi sovrapposte, per
esempio un ufficio potrebbe avere la sua propria rete locale e nello
stesso tempo essere all’interno di un campus e della sua relativa rete o in
un un’area metropolitana; ognuna di queste reti o sottoreti potrebbe
usare lo stesso protocollo di Cellular IP sebbene con un’impostazione
diversa del dispositivo di gestione delle locazioni (ved. paragrafo 4);
•
in seconda istanza Cellular IP utilizza un efficiente schema della gestione
e della ricerca delle locazioni che evita i problemi relativi al trasporto
degli utenti in stato idle, ovvero riducendo il carico sulle reti ad accesso
wireless. Questa caratteristica è necessaria per la proprietà di
connessione passiva leggera che abbiamo identificato come un
importante obiettivo per i futuri sistemi wireless basati su IP.
Una tecnica familiare alla telefonia cellulare è basata su un trasporto “leggero”
della posizione degli utenti mobili per poi zoomare su di essi quando c’è bisogno
di una connessione attiva, cioè quando inoltrano o ricevono una chiamata.
Per esempio nel sistema GSM (Global System for Mobile Communications) gli
utenti non attivi (ovvero in stato idle) sono localizzati con una precisione molto
bassa, si associa ad ognuno di essi solo l’area di localizzazione, ma vengono
focalizzati all’interno dell’area (si dice paged) quando c’è una chiamata in arrivo
o in uscita [34].
Aumentando la dimensione dell’area di localizzazione il traffico di paging può
essere associato al traffico di aggiornamento delle localizzazioni; il punto
operazionale ottimale dipende dalle caratteristiche di chiamata e di mobilità
degli utenti.
Cellular IP si basa su questo concetto e analogamente al sistema di telefonia
107
Configurazione di nodi wireless con supporto della qualità del servizio
cellulare, tende a evitare le procedure di aggiornamento delle localizzazioni
degli utenti non attivi che consumano risorse.
Tuttavia diversamente dal sistema di voce, Cellular IP non può far affidamento
su una fase di inizializzazione della connessione per focalizzare gli utenti mobili
come avviene nel sistema GSM ogni volta che si accende un telefonino. Al
contrario anzi, la gestione delle localizzazioni è basato su un sistema di
segnalazione “leggera”, detta soft-state, che è in grado di distinguere gli host
attivi e quelli inattivi (active o idle) senza introdurre operazioni come
l’inizializzazione della connessione.
Una tale visione differenzia il nostro approccio anche dai i continui sforzi di
fornire un servizio di trasporto dati attraverso la rete della telefonia cellulare.
Infatti il sistema GPRS (General Packet Radio Service) per esempio, prima che
una vera e propria trasmissione abbia inizio, richiede che sia stabilita una
connessione riservando un canale logico tra il cliente mobile e la rete. Inoltre il
sistema GPRS è implementato sull’infrastruttura di GSM che limita l’applicabilità
a piccole reti, specialmente quelle di tipo “domestico”.
Il sistema mobile di terza generazione è predisposto per fornire più servizi di
dati agli utenti mobili e questo, unito ai sistemi ATM e CDMA, dà supporto a una
vasta gamma di servizi che va dalla trasmissione di voce a quella di multimedia
di alta qualità [13].
In confronto a questa standard evoluto, Cellular IP fornisce un approccio
semplicistico offrendo un servizio di consegna non garantito e perciò è molto
più appropriato per i traffici best effort. In ogni caso essendo disegnato intorno
al paradigma IP, esso può evolvere per soddisfare futuri schemi della qualità del
sevizio di IP [15].
108
Configurazione di nodi wireless con supporto della qualità del servizio
Diversamente da alcune tecniche multicast di IP pensate per risolvere problemi
di indirizzamento e locazioni che richiedono alla rete la continua conoscenza
della posizione di ogni utente non attivo, Cellular IP usa un albero di percorsi
tempo-variante per ricercare gli utenti mobili. Queste tecniche multicast non
soddisfano il requisito di connessione passiva leggera e inoltre, come molti altri
protocolli di questo tipo, c’è bisogno di un router IP speciale in ogni stazione
base, cosa molto costosa rispetto al meccanismo proposto con Cellular IP.
4.4.3 Modello di rete ad accesso wireless
Una rete ad accesso wireless consiste in prima analisi di una o più BS (Base
Station) interconnesse con collegamenti wired come illustrato in figura 4.4.
Figura 4.4: Modello di rete ad accesso wireless
109
Configurazione di nodi wireless con supporto della qualità del servizio
A parte la stazione base, la rete può contenere nodi che non contengono
dispositivi radio ma che fungono da concentratori di traffico o supportano
funzioni di controllo della mobilità.
Nella figura 4.4 tutti i nodi, ad eccezione del nodo E, hanno un dispositivo radio.
Le reti ad accesso wireless sono connesse ad Internet attraverso i router
gateway. Questo router speciale rappresenta anche la migliore posizione per la
stazione home agent se la rete di accesso wireless funziona da home network
per alcuni utenti mobili; inoltre quella è anche la migliore posizione per la
stazione detta foreign agent per utenti ospiti.
Si supponga che nella rete Internet globale la mobilità sia affidata a Mobile IP e
che la precisione di localizzazione sia la posizione della rete ad accesso wireless.
Entrando in una rete wireless (azione 1 della figura) un utente mobile X si
connette attraverso la sua home agent (azione 2) che quindi inoltrerà i
pacchetti diretti all’utente X verso quella la rete wireless (azione 3).
Quindi fino a che l’utente rimane connesso alla stessa rete, i suoi spostamenti
sono celati alla sua home agent che d’altro canto si comporterebbe nella stessa
maniera anche se ne fosse informata.
Gli spostamenti tra reti wireless avvengono con una frequenza molto bassa e
perciò Mobile IP risulta un buon protocollo di controllo.
Nel prosieguo identificheremo alcuni requisiti chiave per le reti ad accesso
wireless.
All’interno dell’area di servizio della rete wireless, gli utenti mobili non hanno
una locazione base o un punto dedicato al loro aggancio alla rete. Le BS perciò
inviano periodicamente segnali di controllo per permettere agli utenti mobili di
110
Configurazione di nodi wireless con supporto della qualità del servizio
identificare una stazione base disponibile.
Fino a che sono connessi alla rete wireless, gli utenti mobili esterni alla rete
(come l’utente X della figura) sono trattati come se fossero interni. Però quando
uno di questi utenti si collega o lascia una rete ospitante, conformemente a
quanto richiesto da Mobile IP, deve informare la sua home agent.
Inoltre nel caso di ingresso a una rete ospitante, c’è bisogno anche di procedure
di registrazione e autenticazione.
Per facilitare la mobilità globale, le procedure di registrazione alla rete devono
essere facili e veloci. Tuttavia sebbene per migliorare una ricercabilità globale,
un utente ospite dovrebbe avere un indirizzo locale, è comunque vantaggioso in
termini di trasparenza che esso sia identificato proprio dal suo indirizzo IP
originario (quello della home network) anche all’interno di una rete ospitante.
In uno scenario dove gli utenti si portano dietro computer portatili capaci di
connettersi in maniera wireless che siano sempre accesi, un altro requisito
importante è la capacità di permettere l’accesso al maggior numero di utenti
possibile in una data rete ad accesso wireless. E mentre il traffico generato
dagli utenti attivi può essere limitato da alcuni meccanismi della rete, agli utenti
idle, che hanno bisogno solo della possibilità di essere raggiunti, si deve imporre
la generazione di traffico esiguo.
Come già precedentemente detto, ci riferiamo a questa proprietà chiamandola
connessione passiva leggera (cheap passive connectivity).
Una situazione comune e anche comoda si presenta quando due celle adiacenti
hanno angoli sovrapposti, facilitando così un perfetto supporto degli handoff. In
questo caso il protocollo della rete wireless può considerare soft handoff , cioè
se un utente cambia cella diventando temporaneamente irraggiungibile, i
111
Configurazione di nodi wireless con supporto della qualità del servizio
pacchetti continuano a essere consegnati anche se con un piccolo disordine. Ciò
si realizza permettendo temporaneamente una trasmissione simultanea
da/verso entrambe le stazioni base.
In ogni caso anche se ciò non fosse possibile perché le celle non si
sovrappongono, il protocollo deve comunque funzionare efficientemente.
Ora siccome le celle di solito coprono un’area piccola (delle dimensioni di
qualche stanza o tratto strada), la rete wireless deve poter funzionare bene
anche in presenza di migrazioni molto frequenti.
Tenere nota di ogni movimento di un utente con la precisione di una cella
richiede che sia inviato un messaggio di controllo dopo ogni migrazione verso
una locazione base e che questo sia processato in quel punto, cosa che può
diventare molto inefficiente in regime di un’alta frequenza di handoff. E
comunque lasciare che un utente si muova in un’area servita da una rete
wireless senza che nessuno ne rilevi il movimento per poi localizzarlo solo
quando ci siano dati da consegnare è una soluzione inefficiente e poco
scalabile.
Uno schema di gestione delle locazioni efficiente deve invece mantenere
informazioni circa la posizione degli utenti inattivi senza sovraccaricare la rete
con messaggi di aggiornamento e dovrebbe anche utilizzare un algoritmo di
ricerca veloce ed efficiente, da utilizzare anche nel caso in cui non ci siano dati
da consegnare ad utenti inattivi.
Dato che la frequenza delle migrazioni può variare nelle reti, il meccanismo di
gestione delle localizzazioni dovrebbe essere adattabile a caratteristiche locali,
in particolare in scenari con una frequenza di handoff bassa, si dovrebbe
mantenere per gli utenti idle un’informazione della localizzazione più accurata
mentre al contrario, in sistemi con una frequenza di migrazioni alta dovrebbero
112
Configurazione di nodi wireless con supporto della qualità del servizio
riporre molta fiducia in un meccanismo di ricerca on-demand per limitare il più
possibile il carico imposto dai messaggi di aggiornamento delle localizzazioni.
Per permettere la connessione anche a dispositivi portatili di bassa potenza (e
costo!), una rete ad accesso wireless non dovrebbe affidare una complessità
alta agli utenti mobili.
Idealmente un host mobile è senza memoria (o memoryless) nel senso che esso
continua ad operare le stesse azioni elementari per restare connesso sia nel
caso in cui sia sotto l’azione di ricerca di una BS, sia nel caso in cui resti
inattivo.
Inoltre nessuna operazione particolare dovrebbe essere richiesta nel caso di un
handoff o dopo un black out radio temporaneo.
In definitiva il disegno del protocollo di Cellular IP è motivato da ben 5 requisiti
chiave che una rete di accesso wireless deve soddisfare:
1. migrazione globale semplice;
2. connessione passiva leggera;
3. supporto degli handoff flessibile;
4. semplice gestione delle locazioni;
5. comportamento degli host mobili semplici e senza memoria.
4.4.4 Cellular IP
In aggiunta ai requisiti discussi nel paragrafo precedente, l’obiettivo principale
di Cellular IP è fornire la massima scalabilità e robustezza con la minima
complessità.
Una rete Cellular IP è completamente distribuita se:
113
Configurazione di nodi wireless con supporto della qualità del servizio
•
i nodi non conoscono la topologia della rete;
•
non esiste un data base centralizzato né alcun altro punto debole;
•
nessun elemento della rete può far aumentare la complessità quando
aumenta l’area di copertura (e quindi il potenziale numero di utenti
connessi).
4.4.4.1 Meccanismi di mapping: Paging e Routing Caches
Per semplicità e scalabilità, in una rete Cellular IP nessuno dei nodi conosce
l’esatta posizione di un utente mobile. I pacchetti indirizzati ad un utente mobile
sono inviati alla sua attuale BS con il classico metodo hop-by-hop dove ogni
nodo ha bisogno di sapere solo su quale porto di uscita inoltrare i pacchetti.
Questa tecnica di limitare le informazioni di routing solo localmente non richiede
che i nodi abbiano conoscenza della topologia dell’intera rete wireless.
Ci riferiremo a questo tipo di operazioni con la parola mapping (che tradotto
letteralmente significa “disegnare una mappa”) perché si associano un ogni
utente mobile (ovvero ad ogni suo identificatore, rappresentato dall’indirizzo IP)
ad un numero di porto.
Il meccanismo del mapping è generato e tenuto in piedi grazie all’invio dei
pacchetti trasmessi da tutti gli utenti mobili della rete: i pacchetti viaggiano
nella rete di accesso verso il gateway che è governato da una politica hop-by-
hop. Monitorando questi pacchetti e assegnando l’indirizzo del mittente al
relativo porto entrante, i nodi della rete creano un percorso inverso hop-by-hop
utile per i pacchetti che in futuro verranno indirizzati a quel determinato utente.
Per minimizzare la segnalazione di controllo, i dati di mapping non vengono
114
Configurazione di nodi wireless con supporto della qualità del servizio
cancellati in modo esplicito subito dopo un handoff; piuttosto si assegnato un
timer, scaduto il quale il mapping viene considerato antiquato e solo in quel
caso viene cancellato definitivamente.
Questo implica quello per mantenere vivo l’insieme di informazioni utili al
proprio mapping, un utente deve inviare pacchetti fittizi (detti dummy)
periodicamente anche quando non ha nessuno dato reale da spedire.
La combinazione di pacchetti emessi periodicamente e timer associati ai
mapping assicura che appena un utente mobile entri in un’area di servizio, tra il
gateway della rete ospitante e la BS di quell’host esisteranno sempre delle
informazioni aggiornate riguardanti il mapping.
Questo schema porta vantaggi anche relativamente alla facile migrazione tra
reti di accesso perché i nodi non hanno bisogno di nessuna informazione
preliminare riguardo ad un utente mobile per creare le tabelle di mapping e non
ha bisogno di essere informati quando un utente lascia l’area.
Comunque, affidarsi al meccanismo dei timer genera il seguente trade off: dopo
che un utente abbia compiuto un handoff, il suo percorso relativo alla “vecchia”
staziona rimarrà valido finché i tutte le informazioni di mapping non saranno
cancellate. Ma se nel frattempo verranno inviati dei pacchetti a quell’utente,
non saranno consegnati solo alla sua BS attuale ma anche a quella “vecchia”.
Questo risulta un spreco di risorse che può essere minimizzato selezionando un
timeout abbastanza piccolo.
D’altra parte gli utenti idle hanno bisogno di emettere pacchetti dummy con un
periodo comparabile con il timeout del mapping e minore risulta essere questo
parametro, più frequentemente saranno inviati pacchetti fittizi e quindi più alto
sarà il rischio di sovraccarico della rete!
115
Configurazione di nodi wireless con supporto della qualità del servizio
Questo può essere particolarmente pericoloso laddove le risorse radio sono
scarse perché in questi casi il timeout deve essere piccolo.
Per superare questo problema, si può osservare innanzitutto che il sistema ha
due caratteristici livelli di temporizzazione: per minimizzare lo spreco di risorse
dovuto ad informazioni di mapping non usate ma non ancora cancellate, il
timeout dovrebbe essere dell’ordine del tempo di consegna pacchetto (detto
anche tempo di pacchetto); ma d’altra parte per una periodicità ragionevole dei
pacchetti dummy, il timeout dovrebbe durare tutto il tempo che un utente resta
agganciato ad una BS, cioè il tempo tra due handoff successivi, che può essere
di ordini di grandezza maggiore del tempo considerato precedentemente.
Cellular IP risolve questo problema usando due strutture di mapping parallele. I
nodi mantengono un primo insieme di mapping, chiamato Paging Caches (PC)
che viene usato solo per gli utenti mobili inattivi. I mapping relativi alle PC
hanno un timeout comparabile alla frequenza di migrazione, possibilmente
nell’ordine dei secondi o addirittura dei minuti.
Poi indipendentemente dalle Paging Caches, i nodi mantengono un altro set di
mapping chiamato Routing Caches (RC): le informazioni che vi sono contenute
sono utilizzate solamente per quegli utenti mobili che attualmente ricevono o
sono in attesa di ricevere dati.
Per i mapping delle Routing Caches il timeout può essere dello stesso ordine di
grandezza del tempo di pacchetto.
Perciò questo motivo le Paging Caches si possono considerare dei data base di
informazioni di locazione di basso livello, adatto solo agli utenti idle. Quando poi
uno di questi utenti comincia ad entrare effettivamente in fase di trasmissione
attiva, ad esso vengono applicate le informazioni delle Routing Caches, viste
come data base più “nobili”.
116
Configurazione di nodi wireless con supporto della qualità del servizio
In figura 4.5 è rappresentata la relazione tra le Paging Caches e le Routing
Caches.
Fintantoché rimane inattivo, l’utente X tiene aggiornata la sua PC emettendo
pacchetti dummy ad una frequenza bassa (azione 1 della figura). Le Paging
Caches hanno un timeout relativamente lungo, poiché gli basta tener traccia di
un utente in maniera scadente, dato che l’utente in questione è inattivo.
Figura 4.5: Paging e Routing
Quando ci sono pacchetti da indirizzare ad un utente mobile idle, vengono
utilizzati i mapping delle PC per localizzare l’utente (azione 2 della figura). Da
questo momento e fintantoché continuano ad arrivare dati, un utente mantiene
attivi i timeout delle Routing Caches, sia attraverso i suoi pacchetti in partenza,
sia attraverso la trasmissione di pacchetti dummy (azione 3 della figura).
I pacchetti indirizzati all’utente sono gestiti dalle RC (azione 4 della figura) che
diversamente dalle PC localizzano l’utente più da vicino.
117
Configurazione di nodi wireless con supporto della qualità del servizio
La separazione delle Paging Caches dalle Routing Caches ha un ulteriore
vantaggio: una rete di accesso wireless può avere un grande numero di utenti
mobili collegati allo stesso tempo, dei quali solamente una piccola percentuale
sta ricevendo effettivamente dati.
In questo caso, la Paging Cache conterrà in ogni momento un gran numero di
tabelle di mapping, perciò il suo data base risulterà molto più esteso di quello
della Routing Cache. E siccome le PC sono usate solamente per cercare utenti
inattivi e non per inviare dati con un bit rate alto, il gestore della rete può
scegliere di mettere le Paging Caches solamente in un piccolo numero di nodi
posizionati strategicamente e lasciare agli altri nodi il compito di ricerca
broadcast, che è un’operazione ovviamente più delicata.
Creando più PC le informazioni di locazione possono essere realizzate con più
precisione
riducendo
così
la
dimensione
dell’area
di
ricerca.
Questa
caratteristica architetturale lascia al gestore della rete la libertà di sincronizzare
le operazioni di localizzazione secondo le caratteristiche di mobilità di quella
particolare rete.
Si discuterà più approfonditamente di questo problema nel paragrafo 6.
4.4.4.2 Paging di Cellular IP
Gli utenti mobili inattivi periodicamente generano pacchetti di controllo, di
lunghezza molto ridotta, chiamati pacchetti di aggiornamento del paging
(paging-update packets) e li spediscono alla stazione base attiva più vicina. I
pacchetti di aggiornamento del paging viaggiano nella rete di accesso verso il
router gateway (GW), instradati attraverso la politica dell’hop-by-hop, come
118
Configurazione di nodi wireless con supporto della qualità del servizio
illustrato in figura 4.6. I nodi dotati di Paging Caches monitorano
continuamente i pacchetti di aggiornamento che vi passano e mantengono
attive le cache che associano l’identificativo di utente con il porto al quale il
pacchetto di aggiornamento del paging è destinato (si veda il paragrafo 5.1 per
l’indirizzamento mobile). Il router gateway scarta automaticamente da Internet i
pacchetti di aggiornamento del paging che trasportano informazioni circa alcune
specifiche operazioni di Cellular IP.
Come illustrato in figura 4.6, un utente mobile X è attualmente nella cella del
nodo G.
Figura 4.6: Il mapping nelle PC creato dai pacchetti di aggiornamento del paging
I paging-update packets generati da X viaggiano verso il GW attraverso nodi G,
E, C ed A. In questo esempio i nodi A ed E contengono Paging Caches ma
nodo C no. Ora C semplicemente inoltra i pacchetti di aggiornamento del
paging verso il gateway senza registrare alcuna informazione di localizzazione
sull’utente X. Il nodo A nota che i pacchetti arrivano da X attraverso il porto di
C, mentre il nodo E nota che i pacchetti di X arrivano attraverso il porto di G.
119
Configurazione di nodi wireless con supporto della qualità del servizio
Quando un utente idle si muove, continua a spedire i suoi pacchetti di
aggiornamento del paging alla BS più vicina, forzando le Paging Caches ad
avere informazioni relative al mapping sempre aggiornate. I mapping antiquati
vengono fisicamente cancellati dopo uno specifico timeout impostato dal
sistema.
Se per esempio l’utente X si muove verso la cella F, i suoi pacchetti
aggiornamento del paging saranno spediti alla stazione F come illustrato in
figura 4.7: mentre il nodo A non noterà alcuna differenza, nel nodo E sarà
creato un nuovo percorso di instradamento per X e dopo un po’ (quando il
relativo timeout sarà scaduto) il vecchio percorso sarà considerato antiquato e
perciò verrà cancellato.
Figura 4.7: Aggiornamento delle Paging Caches per un utente mobile
Per un po’ di tempo i due percorsi di mapping coesistono garantendo sempre la
raggiungibilità per l’utente X anche durante la migrazione.
Quando al router gateway arrivano i pacchetti IP indirizzati ad un utente mobile
120
Configurazione di nodi wireless con supporto della qualità del servizio
per il quale non è disponibile nessuna informazione di mapping aggiornata,
vengono usate le Paging Caches per rintracciare l’utente.
Siccome non conosce l’esatta localizzazione del destinatario, il gateway accoda i
pacchetti IP arrivati e genera un pacchetto di controllo con lo scopo di
rintracciare l’utente, chiamato pacchetto di paging che contiene l’identificatore
dell’utente mobile cercato.
Il pacchetto di paging è instradato nella rete di accesso dalle Paging Caches che
semplicemente invertono il percorso di instradamento degli ultimi pacchetti di
aggiornamento del paging. A questo punto se tutti i nodi sono forniti di Paging
Caches, allora è disponibile un hop-by-hop inverso e si può risalire alla posizione
corrente dell’utente; se alcuni nodi invece non hanno le Paging Caches, allora
spediranno il pacchetto di paging a tutti i porti in uscita.
Continuando l’esempio (figura 4.8) per instradare i pacchetti di paging, il nodo
A controlla la sua cache e scopre che i paging update packets di X sono arrivati
recentemente al suo porto attraverso il nodo C. Quindi A inoltra il pacchetto di
paging verso C che invece non ha informazioni sull’utente X e perciò inoltra il
pacchetto in tutte le possibili direzioni.
Il pacchetto di paging spedito verso il nodo D si scarta perché D sa che l’utente
X non è nella sua cella.
Quello mandato ad E invece invita il nodo a controllare le sue cache e si scopre
che X sta spedendo pacchetti attraverso F; perciò E inoltra il pacchetto di
paging a F e quindi a X.
121
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 4.8: I pacchetti di paging vengono indirizzati dalle PC verso l’utente mobile
Una volta ricevuto il pacchetto di paging, l’utente mobile crea un pacchetto di
controllo chiamato pacchetto di aggiornamento dell’instradamento (route-
update packet) e lo invia alla sua stazione basi (F nell’esempio dell’utente X).
Analogamente ai pacchetti di aggiornamento del paging, i pacchetti di
aggiornamento dell’ instradamento viaggiano verso il router gateway in base ad
un meccanismo hop-by-hop e creano il mapping nelle Routing Caches per
l’utente mobile che ha spedito quel pacchetto.
Quando i pacchetti di aggiornamento dell’instradamento raggiungono il router
gateway, tutte le Routing Caches incontrate per la strada vengono
automaticamente aggiornate e i pacchetti di dati accodati nel router gateway
possono finalmente essere consegnati all’utente mobile.
Questo processo di ricerca dell’utente ritarda la consegna del primo pacchetto di
dati ma una volta che il percorso risulta stabilito, i pacchetti seguenti usano le
informazioni acquisite precedentemente senza ripetere la ricerca.
Comunque se in qualunque momento durante il trasferimento dei dati, l’utente
diviene temporaneamente irraggiungibile e scadono i timeout delle Routing
122
Configurazione di nodi wireless con supporto della qualità del servizio
Caches, i prossimi pacchetti di dati genereranno un nuovo processo di paging
proprio a partire dalle ultime informazioni che avevano a disposizione.
In questo modo anche un black-out temporaneo del canale radio non genera
nessuna reazione dell’utente, al più provoca un ulteriore ritardo nel processo di
paging.
4.4.4.3 Routing di Cellular IP
I pacchetti di dati emessi da un utente mobile sono instradati verso il router
gateway in una base ad una politica hop-by-hop. I nodi che contengono
Routing Caches controllano tutti i pacchetti di dati che vi passano e li usano per
creare le associazioni tra identificatori di utente e numeri di porto.
I pacchetti indirizzati verso l’utente mobile sono instradati dalle Routing Caches
attraverso un percorso hop-by-hop inverso quando ci sono le relative
informazioni oppure vengono mandati in broadcast quando queste informazioni
non ci sono.
La struttura e le operazione principali del routing sono fondamentalmente le
stesse di quelle del paging.
Per chiarire la dualità tra i due meccanismi, nella tabella 4.2 si espongono in
breve alcune caratteristiche delle Paging Caches a confronto con quelle delle
Routing Caches.
Può essere utile notare ancora una volta che le due funzioni sono divise a causa
dell’intrinseca differenza delle temporizzazioni caratteristiche dei relativi
meccanismi di funzionamento.
123
Configurazione di nodi wireless con supporto della qualità del servizio
Paging Caches (PC)
Routing Caches (RS)
tutti i pacchetti generati da un pacchetti dati e route-update
configurate da utente mobile (dati,route-update,
packets originati da un
paging-update)
utente mobile
localizzazione
scopo
timeout
sia degli utenti mobili attivi che
idle
Instradamento dei pacchetti di
paging
dell’ordine di grandezza della
frequenza di handoff
solo degli utenti mobili attivi
instradamento dei pacchetti
dati indirizzati ad un utente
mobile
dell’ordine di grandezza del
tempo di pacchetto
Tabella 4.2: confronto tra PC e RC
Le Routing Caches si occupano solamente degli utenti attivi (cioè di quelli che
effettivamente stanno ricevendo o emettendo pacchetti di dati) e sono
aggiornate da timeout dell’ordine di grandezza del cosiddetto tempo di
pacchetto, cioè quel tempo necessario alla consegna di un pacchetto.
Questo permette alle Paging Caches di operare su una scala temporale molto
più grande, la cui misura è data dalla frequenza di handoff, in modo da evitare
frequenti aggiornamenti del paging operati da utenti inattivi.
L’utente mobile può continuare a ricevere pacchetti di dati per un certo tempo
anche se non ha niente da spedire.
Per mantenere le Routing Caches configurate ed evitare paging ripetuti, gli
utenti mobili che sono in attesa di dati ma non hanno nessuno pacchetto da
inviare (cosa che succede ad esempio quando è aperta una connessione TCP)
124
Configurazione di nodi wireless con supporto della qualità del servizio
devono inviare periodicamente i pacchetti di aggiornamento dell’instradamento.
Così come i pacchetti di dati, anche i route-udate packets configurano le
Routing Caches ed assicurano che il percorso di instradamento basato sull’hop-
by-hop dal router gateway verso l’utente mobile rimanga aggiornato.
Si può notare poi che per scopi di affidabilità, le Paging Caches non smettono
mai di “inseguire” gli utenti quando questi sono attivi e che comunque gli utenti
attivi non hanno bisogno di spedire pacchetti di aggiornamento del paging
perché le Paging Caches sono configurate anche dai pacchetti di aggiornamento
dell’instradamento e da qualunque altro tipo di pacchetto generato dagli utenti.
4.4.4.4 Handoff di Cellular IP
I meccanismi sopra descritti assicurano che gli handoff, che altro non sono che
migrazioni durante un trasferimento dei dati in corso, vengano gestiti
automaticamente.
Un handoff in Cellular IP è sempre provocato dal movimento dell’utente:
appena un utente si avvicina ad una nuova stazione base, reindirizza i suoi
pacchetti di dati dalla vecchia alla nuova stazione. Il primo di questi pacchetti
reindirizzati configura automaticamente un nuovo percorso che sarà utilizzato
dalle Routing Caches per la localizzazione per di quell’utente.
Per un tempo uguale a quello del timeout del mapping delle Routing Caches, i
pacchetti indirizzati all’utente mobile saranno consegnati ad ambo le stazioni
base, quella vecchia e quella nuova.
Nel caso in cui l’apparecchiatura radio dell’utente sia capace di gestire due
canali logici nello stesso tempo, gli handoff saranno detti soft.
125
Configurazione di nodi wireless con supporto della qualità del servizio
Se invece l’utente non è capace di stare in ascolto di due stazioni
contemporaneamente, allora l’handoff è detto hard e l’efficienza della
migrazione dipende esclusivamente dalle apparecchiature radio.
Dopo un certo tempo, il percorso relativo alla vecchia stazione base sarà
giudicato antiquato e verrà cancellato, mentre i pacchetti inizieranno ad essere
consegnati alla locazione corrente dell’utente attraverso la sua nuova stazione
base.
In figura 4.9 è illustrato uno scenario di handoff. L’utente mobile X sta
trasferendosi dalla cella F a D mentre sta spedendo e ricevendo pacchetti di
dati. Presumendo che tutti i nodi abbiano a disposizione delle Routing Caches,
prima che l’utente si sia mosso, le informazioni di localizzazione delle RC sono
quelle indicate nelle bandiere.
Dopo la migrazione, i pacchetti di dati generati dall’utente, indicate in figura con
frecce continue, comunicano al nodo C un nuovo percorso di localizzazione. Per
un certo tempo, i pacchetti indirizzati a X sono consegnati sia a D che a F;
questo è mostrato in figura con frecce tratteggiate.
Dopo un tempo pari al timeout della Routing Cache del nodo E, il vecchio
percorso di localizzazione
viene cancellato, così come quello della Routing
Cache del nodo F.
Da quel momento in poi, è usato solamente il percorso di instradamento
aggiornato.
La cache di A rimane invariata per l’intera durata del processo.
Questo processo di handoff è semplice, trasparente ed automatico. Nei nodi
dove ai vecchi e ai nuovi percorsi corrisponde lo stesso instradamento, i vecchi
mapping vengono riusati automaticamente rendendo non necessaria per
126
Configurazione di nodi wireless con supporto della qualità del servizio
Cellular IP una nuova ricerca per quei punti detti “di cross-over”.
Figura 4.9: Il meccanismo di handoff di Cellular IP
Inoltre se vecchie e nuove celle si sovrappongono, c’è una piccola interruzione o
disturbo nella comunicazione: infatti se all’atto di un handoff l’utente mobile
rimane temporaneamente fuori contatto radio mentre si muove tra due celle,
negli strati superiori (cioè i TCP) si possono verificare dei ritardi e alcuni
pacchetti possono perfino andare persi; ma la comunicazione è comunque
ripresa appena l’utente riappare nella nuova cella.
Si può verificare che questo meccanismo è efficiente anche se applicato a quegli
utenti che temporaneamente risultano irraggiungibili a causa di ragioni diverse
dall’handoff.
Se un utente riappare prima della scadenza del timeout della Routing Cache, il
servizio continua senza alcun ulteriore ritardo; se invece il timeout è scaduto, le
Routing Caches vengono riconfigurate dal primo pacchetto inviato dall’utente al
quale non è neanche richiesto di conoscere la sua condizione di raggiungibilità
127
Configurazione di nodi wireless con supporto della qualità del servizio
dalla Routing Cache quando verso un’altra cella.
Nella descrizione del processo di handoff, si presuppone implicitamente che
l’utente mobile abbia sempre pacchetti di dati da spedire.
Quando un utente si aggancia alla rete ed entra nella zona di servizio di nuova
cella, per configurare il percorso di localizzazione manda immediatamente dei
pacchetti di aggiornamento dell’instradamento; questo però non accade nel
caso di un handoff perché l’utente è all’oscuro della sua migrazione: è la rete a
gestire il tutto in accordo con la regola di non caricare su un terminale le
procedure di gestione della rete.
Tuttavia siccome i pacchetti di dati hanno lo stesso effetto dei pacchetti di
aggiornamento dell’instradamento, il meccanismo degli handoff è gestito
comunque ottimamente quando un utente invia un pacchetto di dati.
Ovviamente nel caso in cui l’utente a non abbia nessun dati da spedire,
continuerà a inviare pacchetti di aggiornamento dell’instradamento alla sua
nuova cella per mantenere la localizzazione.
Mentre questo processo darebbe luogo normalmente a handoff semplici, ci sono
dei casi, soprattutto in sistemi “domestici”, dove gli handoff si possono
verificare con una frequenza molto alta oppure può addirittura accadere che un
utente mobile sia sul confine tra due celle e che il suo servizio rimbalzi tra le
due stazioni base.
Per assicurare una comunicazione continua in queste situazioni, l’utente mobile
mantiene il percorso di instradamento delle Routing Caches in entrambe le
stazioni base spedendo i suoi pacchetti di dati ad una e mandando in parallelo i
pacchetti di aggiornano dell’instradamento all’altra.
In questo caso, la rete è preparata per l’handoff e la trasmissione di dati sarà
128
Configurazione di nodi wireless con supporto della qualità del servizio
continua anche nel momento in cui l’utente decidesse improvvisamente di
spostarsi verso una delle due stazioni diventando irraggiungibile per l’altra.
Si noti che la stessa politica può essere usata per gli utenti mobili idle per
assicurarsi la raggiungibilità: invece di spedire pacchetti di aggiornamento del
paging a una sola stazione base, l’utente può spedirli a due o più stazioni in
parallelo.
Cellular IP può usare queste strategie per migliorare la raggiungibilità e la
qualità degli handoff in cambio di una piccola degradazione dell’efficienza della
rete.
4.4.5 Problemi relativi al disegno del protocollo
Nelle sezioni precedenti sono stati descritti i concetti base di Cellular IP e le sue
funzioni di paging, instradamento e handoff.
In seguito saranno discussi alcuni dettagli algoritmici di Cellular IP.
4.4.5.1 Indirizzamento e Migrazione
Siccome gli indirizzi dell’utente mobile non hanno un significato relativo alla
localizzazione all’interno di una rete di Cellular IP, può essere usato qualunque
spazio di identificatori di utente.
L’uso dell’home address IP è una soluzione semplice ma che allo stesso tempo
ha il vantaggio di non cambiare i pacchetti IP né mascherarli quando vengono
usati nella rete di accesso.
129
Configurazione di nodi wireless con supporto della qualità del servizio
Non è necessario nessun incapsulamento né conversione di indirizzo in una rete
di Cellular IP: l’uso degli indirizzi di IP come identificatori di utente mobile rende
la migrazione tra reti di accesso incredibilmente semplice.
Un utente mobile che accede ad una rete Cellular IP, ha semplicemente il
compito di comunicare l’indirizzo del router gateway locale alla sua home
agent 1 .
L’home agent invierà quindi i suoi pacchetti al router gateway che a sua volta
poi li smisterà sulla rete di Cellular IP. Il processo di paging e settaggio/modifica
delle Routing Caches non hanno bisogno di nessuna informazioni preliminare
per cominciare a creare le informazioni di mapping per l’utente che si è appena
agganciato alla rete, né richiedono di essere informati quando un utente mobile
lascia rete di accesso.
4.4.5.2 Pacchetti di controllo
I tre tipi di pacchetti di controllo (del paging, di aggiornamento del paging e di
aggiornamento dell’instradamento) usati da Cellular IP possono essere regolari
pacchetti IP.
Tutti e tre i tipi contengono solamente un singolo elemento di informazione:
l’identificatore dell’utente mobile. E poiché questo elemento viene indicato nel
campo di origine o di destinazione del pacchetto (per i pacchetti di
aggiornamento del paging/dell’instradamento e per i pacchetti di paging
rispettivamente), la parte contenente il payload può anche rimanere vuota.
I pacchetti di controllo possono essere implementati da una IP nuova opzione e
1
L’indirizzo di IP del router gateway può essere incluso in una segnalazione di controllo della stazione
base. Serve poi anche ad identificare la rete di accesso wireless quando l’utente è coperto da più reti
di accesso contemporaneamente.
130
Configurazione di nodi wireless con supporto della qualità del servizio
non è necessario che i router semplici comprendano il funzionamento di questa
opzione.
4.4.5.3 Configurazione dei nodi
In una rete Cellular IP, nessun dei nodi ha bisogno di avere una visione del
livello di rete o informazioni topologiche del sistema, né ha bisogno di
conoscere la propria posizione all’interno della rete. I nodi non hanno bisogno di
essere configurati: Cellular IP è una soluzione plug-and-play che permette
anche il recupero di un nodo se questo dovesse subire un crash. Comunque in
ogni nodo deve essere disponibile una certa quantità di informazioni di routing.
Un nodo deve sapere quale dei suoi porti usare per instradare i pacchetti verso
il router gateway.
Un modo semplice per mantenere queste informazioni è implementato proprio
dal router gateway che periodicamente trasmette segnali di controllo in
broadcast per permettere che i nodi registrino il porto attraverso il quale hanno
ricevuto l’ultimo pacchetto. Nella descrizione degli algoritmi, ci si riferirà a
questo porto con il nome “uplink-port”. Inoltre il nodo deve sapere quali dei
suoi porti è connesso all’uplink-port di un altro nodo 2 . Questi porti saranno
chiamati “downlink-port”.
È importante che le informazioni di instradamento immagazzinate nei nodi siano
consistenti, nel senso che esiste sempre un percorso di instradamento (che si
suppone senza cappi) che collega qualsiasi nodo al router gateway.
Mentre le modifiche frequenti di questi percorsi di instradamento possono
2
Questa informazione serve ad evitare dei loop quando dei pacchetti indirizzati ad un utente mobile
sono inviati in broadcast.
131
Configurazione di nodi wireless con supporto della qualità del servizio
degradare le prestazioni della rete in termini di aumento dei tempi di consegna
e del tasso di perdita dei pacchetti, il ripristino delle informazioni di
instradamento dopo un crash o la congestione temporanea di un tratto di rete
non mettono in pericolo le prestazioni, anzi questi meccanismi possono essere
usati per garantire la tolleranza alle situazioni anomale quando Cellular IP
lavora su una rete soggetta a frequenti congestioni.
4.4.5.4 Algoritmi dei nodi
I nodi che non hanno né Paging Caches né Routing Caches semplicemente
inoltrano tutti i pacchetti che arrivano al downlink-port verso il loro uplink-port e
i pacchetti che arrivano all’uplink-port verso il downlink-port . Un nodo con una
Paging Cache deve monitorare tutti i pacchetti che arrivano dai suoi downlinkport: prima di instradarli attraverso l’uplink-port, legge l’indirizzo del mittente ed
lo usa per aggiornare la PC secondo le seguenti regole: se sono disponibili
informazioni di localizzazione circa l’utente mobile mittente al porto al quale il
pacchetto è arrivato, il timer per questo mapping è azzerato; se queste
informazioni di localizzazione non esistono, vengono create adesso e il timer
viene inizializzato. Quando un pacchetto di paging arriva attraverso l’uplinkport, viene controllata la Paging Cache: se esistono informazioni aggiornate
sulla localizzazione della destinazione, il pacchetto è spedito sui relativi porti; se
non ci sono informazioni di localizzazione, il pacchetto viene scartato.
L’operazione di un nodo con Routing Caches differisce in due parti: primo, come
discusso nel paragrafo 4.4.4.3, i pacchetti di aggiornamento del paging non
aggiornano le Routing Caches. Secondo, invece dei pacchetti di paging, le
Routing Caches inoltrano i pacchetti dati che vi arrivano dall’uplink-port.
Ovviamente possono esserci nodi che hanno allo stesso tempo sia Paging
132
Configurazione di nodi wireless con supporto della qualità del servizio
Caches che Routing Caches nel qual caso vengono eseguiti entrambi gli
algoritmi. I nodi senza Paging Caches indirizzano tutti i pacchetti di paging
verso tutti i downlink-port mentre i nodi senza le Routing Caches spediscono
tutti i pacchetti di dati che arrivano dall’uplink-port a tutti i downlink-port.
4.4.6 Realizzazione del protocollo
Cellular IP definisce una struttura generale che dà grande libertà ad un
amministratore di rete di regolare il sistema in funzione delle caratteristiche
locali.
Attualmente le reti Cellular IP sono soltanto di tipo sperimentale e servono per
lo più come testbed per studi di prestazioni di sistema e di dipendenze dei
settaggi.
4.4.6.1 Realizzazione della temporizzazione
I timer giocano un ruolo fondamentale per l’efficienza di Cellular IP; anche se
l’accuratezza delle temporizzatori non è un fattore cruciale (e quindi la
sincronizzazione potrebbe essere omessa), i valori dei timeout delle Paging
Caches e delle Routing Caches e il periodo di invio dei pacchetti di
aggiornamento del paging e dei pacchetti di aggiornamento dell’instradamento
devono essere dimensionati attentamente per avere buone prestazioni.
Per entrambi i timeout, un valore più alto dà luogo a comunicazioni di controllo
meno frequenti, ma estende la validità di percorsi non usati.
Se dopo migrazione l’utente spedisce sempre un pacchetto di aggiornamento
133
Configurazione di nodi wireless con supporto della qualità del servizio
del paging extra alla nuova stazione base, allora la frequenza dei pacchetti di
aggiornamento del paging può essere bassa senza mettere in pericolo la
raggiungibilità.
L’ideale sarebbe settare tale frequenza ad un valore approssimativamente
uguale alla quello della frequenza di migrazione.
Per mantenere le informazioni di mapping delle Paging Caches anche se si
verificano alcune perdite di pacchetti di aggiornamento del paging consecutive, i
timeout delle Paging Caches dovrebbero essere qualche multiplo del tempo dei
pacchetti di aggiornamento del paging: con questo settaggio, il carico imposto
dai pacchetti di aggiornamento del paging sarà comparabile con quello imposto
dalla segnalazione relativa alle migrazioni esplicite.
Il tasso dei pacchetti di aggiornamento del paging è perciò il parametro
primario da considerare per la gestione della mobilità di Cellular IP e va
accordato con la dimensione della cella del sistema e la velocità media
dell’utente.
Le prestazioni sono anche molto sensibili ai timeout delle Routing Caches:
questo parametro dovrebbe essere settato in modo tale che un utente mobile
che generi un handoff soft riceva solo pochi pacchetti da ambo le stazioni base
per assicurare handoff senza difetti.
Un timeout delle Routing Caches più lungo dovrebbe essere evitato per limitare
lo spreco di risorse.
Il tasso di invio dei pacchetti di aggiornamento dell’instradamento dovrebbe
essere tale che durante il timeout delle Routing Caches arrivino pochi pacchetti
di aggiornamento dell’instradamento per mantenere il mapping anche quando
tali pacchetti vanno persi.
134
Configurazione di nodi wireless con supporto della qualità del servizio
Si noti che in molte sessioni di comunicazione ci saranno anche tanti pacchetti
di dati o di acknowledgement emessi dall’utente mobile, perciò i pacchetti di
aggiornamento dell’instradamento non sono sempre necessari.
4.4.6.2 Realizzazione delle Caches
Un altro modo per adattare la rete alle caratteristiche locali è utilizzando le
Paging e le Routing Caches.
Anche se il protocollo supporta nodi senza Routing Caches, è probabile che per
un utilizzo efficiente delle risorse della rete, si possa scegliere di associare una
RC ad ogni nodo.
Invece per le Paging Caches, che contengono un data base considerevolmente
più grande, si può pensare di posizionarle solamente in alcuni punti strategici
della rete.
Poiché i nodi senza Paging Caches non fanno altro che inoltrare in broadcast i
pacchetti di impaginazione, il processo di paging resta operativo anche con
poche PC. Perciò più Paging Caches danno luogo a meno carico di paging in
cambio ad un costo hardware ovviamente superiore.
Quindi l’amministratore posizionerà tipicamente le Paging Caches in nodi con
molti porti foglia (cioè quelli che sono connessi ad altri nodi ma che a loro volta
non sono connessi con altri) ed in nodi che interconnettono grandi aree della
rete che sono separate da tutto il resto.
Poiché il carico di routing è proporzionale al numero di sessioni e non al traffico
globale, ottimizzare la densità delle Paging Caches è il modo migliore per
adattare la rete alle caratteristiche del traffico: un numero di Paging Caches
maggiore dovrebbe essere considerato solo nel caso in cui il traffico consista
135
Configurazione di nodi wireless con supporto della qualità del servizio
principalmente di frequenti burst, cioè di comunicazioni piccole nella durata ma
grandi per la quantità di dati inviati; al contrario un numero di Paging Caches
minore è giustificato nel caso in cui il traffico sia formato soprattutto da
trasmissioni di dati grandi e prolungate nel tempo.
Comunque il router gateway dovrebbe contenere sempre una Paging Cache per
evitare l’accodamento dei pacchetti di quegli utenti che non sono più collegati
alla rete di accesso.
Sebbene nella descrizione del protocollo questo non è stato evidenziato, è
possibile avere nodi che hanno solo Paging Caches per alcuni dei loro downlinkport, ma non per tutti. Questo può avere senso specialmente nel caso di
stazioni base con porti molto usati e che perciò dovrebbero avere una PC anche
se la loro posizione nella rete può non giustifichi la presenza in quel punto.
Questi nodi si comporteranno come stazioni con Paging Caches per i porti per i
quali mantengono la cache, ma sembreranno nodi di senza PC per gli altri porti
foglia.
4.4.6.3 Realizzazione del Paging
Dipendentemente dalla dimensione di rete, il tempo per localizzare un utente
mobile qualche volta può essere lungo.
Sono necessari ulteriori studi per vedere se questi ritardi sono accettabile per la
maggior parte delle applicazioni IP: se il ritardo di paging è troppo alto, è
possibile usare il primo pacchetto di dati (o i primi pacchetti) come pacchetti di
paging invece di accodarli nel router gateway e generare dei piccoli pacchetti di
paging.
Questa soluzione semplifica anche le realizzazioni dei router gateway, sebbene
136
Configurazione di nodi wireless con supporto della qualità del servizio
provochi un più alto carico della rete giacché i pacchetti di dati sono ovviamente
più grandi di quelli di paging.
Si possono poi considerare delle implementazioni più sofisticate, intermedie tra
queste due soluzioni proposte e scelte ad hoc in funzione dalla dimensione e dal
tipo di payload dei pacchetti.
4.4.7 Conclusioni su Cellular IP
In questo capitolo sono state discusse alcune limitazioni dei protocolli per la
gestione di utenti mobili (come Mobile IP) che diventano difficilmente utilizzabili
in ambienti wireless dove gli utenti mobili si spostano molto velocemente dando
luogo a frequenti operazioni di handoff.
Quindi è stato analizzato nei dettagli un altro protocollo chiamato Cellular IP che
ha come scopo principale il miglioramento e l’integrazione di reti wireless con
barriere tecniche di quel tipo.
L’architettura di Cellular IP conta sulla separazione della mobilità locale dalla
mobilità di area estesa. È stato affermato che mentre Mobile IP può sostenere
efficientemente la mobilità di un’area estesa (come Internet ad esempio), la
mobilità locale impone speciali requisiti non presi in considerazione nel disegno
e dallo sviluppo di Mobile IP.
Si identificano perciò un insieme di requisiti chiave, come la migrazione globale
semplice, la connessione passiva leggera, il supporto flessibile degli handoff, la
gestione locale efficiente ed il concetto di utente mobile senza memoria:
Cellular IP è ottimizzato per reti ad accesso wireless ed è stato progettato per
soddisfare questi requisiti chiave.
Due ulteriori vantaggi del protocollo sono la sua semplicità e la sua robustezza.
137
Configurazione di nodi wireless con supporto della qualità del servizio
Una rete Cellular IP inoltre è scalabile: si possono usare gli stessi nodi semplici
ed economici sia per piccoli sistemi domestici che per aree metropolitane
estese.
La semplicità di un nodo di Cellular IP e la capacità di intercomunicazione con
Mobile IP facilita ne facilita l’introduzione nel panorama attuale dei sistemi di
gestione degli utenti mobili, data anche la sua compatibilità con sistemi più
datati; per queste proprietà una rete wireless può essere facilmente estesa
incrementandone un po’ per volta la sua dimensione e le sue capacità.
Attualmente le reti di Cellular IP esistono solo per scopi sperimentali che
serviranno come testbed per studi futuri.
138
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 5
Access Point con supporto della qualità del servizio:
HostAP e HostQs
Questo capitolo rappresenta la parte principale per l’acquisizione dello stato
dell’arte delle tecnologie che si sono utilizzate: attraverso uno studio dei
software di base HostAP 3 e HostQs 4 si può ottenere una prima realizzazione
di un Access Point che fornisca un supporto della qualità del servizio.
Sfortunatamente le regole sulle quali si basa la politica di schedulazione
dell’HostQs, o più precisamente di quella parte dell’HostQs che viene
chiamata Queue Manager, non sono utili alla realizzazione della idea iniziale
di cui si è parlato precedentemente.
Tuttavia per un buon utilizzo delle strategie da realizzare, si rende
necessaria un’analisi approfondita di questi due elementi chiave.
3
4
http://hostap.epitest.fi/
http://www.inlab.csp.it/tools/wireless/hostqs/
139
Configurazione di nodi wireless con supporto della qualità del servizio
5.1 HostAP
Il progetto di HostAP è formato da tre componenti principali:
•
il driver di HostAP che lavora sotto Linux con schede basate su
tecnologia Prism2/2.5/3 5
•
il demone hostapd per gli Access Point: include funzioni base per
l’autenticazione
di
sistemi
Linux
e
BSD
basate
sullo
standard
IEEE802.11x, identificatori EAP e autenticazioni per server RADIUS
•
WPA Supplicant per driver di Linux, BSD e Windows
HostAP è un driver che controlla sotto Linux le schede wireless basate sul
chipset Intersil Prism 2/2.5/3. Il driver supporta la cosiddetta modalità HostAP o
Master che controlla i time critical tasks, cioè le funzioni di gestione dello
standard IEEE802.11x per fa sì che un normale computer agisca come un
Access Point, senza alcun aggiunta di ulteriori firmware.
Inoltre esso fornisce supporti per le operazioni delle normali stazioni BBS e
IBBS. Alcune le funzioni (come WPA e RSN) sono supportate solo se il driver
viene accompagnato da altri programmi di utilità quali hostapd e WPA
Supplicant.
5
http://wiki.personaltelco.net/index.cgi/Prism2Card
140
Configurazione di nodi wireless con supporto della qualità del servizio
Le stazioni con tecnologia Intersil Prism2 supportano il cosiddetto modo HostAP
nel quale si gestiscono quei compiti legati alle temporizzazioni critiche come
l’invio di segnali di controllo e di riconoscimento di frame (beacon e
acknowledgement) ma lasciano gli altri compiti di gestione al driver del
computer host.
Oltre a implementare le funzioni di base necessarie a inizializzare e configurare
le schede basate sulla tecnologia Prism2, a inviare e ricevere frame, il driver è
anche fornito di un sistema per raccogliere informazioni di tipo statistico.
Inoltre esso include un’implementazione delle seguenti funzioni dello standard
IEEE802.11:
•
autenticazione (e deautenticazione)
•
associazione (con riassociazione e deassociazione)
•
trasmissione di dati tra due stazioni wireless
•
controllo dell’energia (PS - Power Saving)
•
gestione di frame per il PS con segnalazioni e buffering.
Nel pacchetto di HostAP sono presenti anche altre funzioni per il debugging e il
controllo
di
strutture
dello
standard
IEEE802.11
come
l’accesso
alle
configurazioni dei record hardware, ai registri di I/O e alle frames con gli header
802.11.
Quando viene usato anche il demone, la combinazione di HostAP e hostapd
permette funzioni speciali:
•
il settaggio della chiave come previsto dall’IEEE802.1x e del WEP (Wired
Encryption Privacy) dinamico;
•
l’accounting RADIUS per l’autenticazione IEEE802.11 (nel caso si utilizzi
questo server come supporto);
141
Configurazione di nodi wireless con supporto della qualità del servizio
•
l’accesso al sistema;
•
e altre funzionalità base dello standard IEEE802.11f.
Hostapd è un demone per Access Point e server di autenticazione che
implementa alcune funzionalità base degli Access Point previste dallo standard
IEEE802.11,
come
l’autenticazione
così
come
preista
dello
standard
IEEE802.1x/WPA e autenticazione RADIUS.
Il WPA (Wi-Fi Protected Access) è una tecnologia che ha come scopo la
gestione della sicurezza delle reti wireless attraverso la protezione dei dati
(encrypting) e il controllo di accesso alla rete attraverso un forte controllo
sull’utente: l’autenticazione e l’associazione sono affidati ad un meccanismo di
negoziazione di una chiave mentre il roaming è controllato dal driver wireless.
Sia l’hostapd che il WPA sono disegnati per essere programmi “demone” che
vengono eseguiti in background e agiscono come componenti finali controllando
le autenticazioni e le connessioni wireless.
142
Configurazione di nodi wireless con supporto della qualità del servizio
5.2 HostQs: Differenziazione del traffico in WLAN
La questione del supporto della qualità del servizio (QoS - Quality of Service)
nelle attuali reti locali senza filo (WLAN - Wireless Local Area Network) è
affrontata dal software Queue Manager con un approccio molto innovativo,
chiamato HostQs, che mira alla differenziazione del traffico a seconda di
requisiti di QoS lavorando a livello 2, ovvero al livello LLC.
L’approccio è basato sulla creazione di una coda LLC per ogni categoria di
traffico e sulla schedulazione delle code in accordo con il concetto di
connessione virtuale tra le differenti priorità all’interno della stazione wireless.
La frame alla testa della coda LLC che vince la contesa è consegnata al livello
MAC e gestita in base alle regole di questo sottolivello. Il meccanismo proposto
è stato implementato in ambiente Linux su un Access Point Open-Source
usando una scheda basata su un chipset Prism2.
5.2.1 Introduzione a HostQs
Una delle applicazioni più promettenti delle WLAN basate sulla tecnologia IEEE
802.11 è senza dubbio il supporto di traffico multimediale come ad esempio
Voice over IP (VoIP).
In realtà le WLAN potrebbero essere utilizzate con molto successo per
143
Configurazione di nodi wireless con supporto della qualità del servizio
trasportare traffico voce su un’architettura IP se la rete fosse utilizzata solo per
questo scopo! Ma nelle WLAN classiche che trasportano traffico di natura
eterogenea nascono molti problemi a causa del limitato grado di sviluppo del
supporto QoS che l’attuale tecnologia 802.11b riesce a fornire.
L’esigenza di servizi più potenti ha portato quindi allo sviluppo di nuovi standard
IEEE o almeno a degli abbozzi di standard, come il cosiddetto IEEE 802.11e
[35], nel quale si definiscono le procedure MAC per supportare applicazioni LAN
con requisiti di QoS, compreso traffico voce, audio e video su WLAN.
Lo standard IEEE 802.11e introduce una funzione di coordinamento ibrido (HFC
- Hybryd Coordination Function) e specifica poi due schemi di accesso: l’accesso
a canale distribuito migliorato (EDCA - Enhanced Distributed Channel Access) e
l’accesso a canale controllato da HCF (HCCA - HCF Controlled Channel Access)
[35]. Un analisi un po’ più approfondita dei meccanismi di accesso 802.11e
possono essere trovati in [37].
Tuttavia non si trovano disponibili implementazioni commerciali né dell’EDCA né
del HCCA e lo studio delle prestazioni si basa soltanto su analisi teoriche e
simulazioni. In particolare in [36] viene presentato uno studio analitico mentre
in [38], [39] e [40] si possono trovare risultati di simulazione.
L’approccio HostQs non fa parte dell’IEEE 802.11e ma può essere visto come un
miglioramento dell’architettura dello standard IEEE 802.11b che fornisce una
differenziazione del traffico in modo simile a EDCA ma senza richiedere
modifiche al livello MAC.
L’interpretazione principale di questo approccio è un’architettura che può essere
vista come una soluzione intermedia prima che lo standard 802.11e sia
definitivamente e largamente diffuso: siccome l’approccio HostQs si basa sugli
stessi principi dell’EDCA, è comprensibile come entrambe le soluzioni possano
144
Configurazione di nodi wireless con supporto della qualità del servizio
coesistere e allo stesso tempo, poiché HostQs non apporta modifiche al MAC
802.11b, si garantisce una compatibilità di base. Nel prossimo paragrafo si
elencano le principali caratteristiche dell’EDCA, nel paragrafo 5.2.3 si descrivono
le modifiche al livello LLC dell’IEEE 802.11b, nel 5.2.4 l’implementazione di
HostQs su una piattaforma Open-Source e infine nel paragrafo 5.2.5 vengono
proposti i risultati di alcune misurazioni effettuate con questo nuovo approccio e
l’effettiva funzionalità della soluzione proposta.
5.2.2 QoS dell’IEEE 802.11e: la funzione EDCA
In questo paragrafo saranno esposte brevemente le caratteristiche principali
dell’EDCA; per ulteriori informazioni si rimanda a [35] e [37].
Così come la funzione di coordinamento distribuito (DCF - Distributed
Coordination Function) presente nell’802.11, anche la funzione EDCA è basata
sullo schema CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)
e impiega il concetto di Inter Frame Space (IFS) come meccanismo di backoff.
Le innovazioni introdotte sono:
•
ogni volta che una stazione 802.11e si aggancia a un canale, viene
autorizzata a trasmettere una o più frame in un dato intervallo di tempo
chiamato Transmission Opportunity (TXOP) che è caratterizzato da una
durata massima, indicata con TXOP-limit;
•
vengono definite categorie di accesso (AC - Access Categories), ognuna
delle quali corrisponde ad un differente livello di priorità e ad un
differente insieme di parametri che vengono usati per la contesa del
canale. In particolare una stazione 802.11e che opera con la funzione
EDCA può includere fino a 4 code MAC. Una coda utilizza i seguenti
parametri per accedere al canale:
145
Configurazione di nodi wireless con supporto della qualità del servizio
o spazio tra due frame (AIFS[AC] - Arbitration Inter Frame Space),
parametro simile al DIFS usato dalla DCF;
o la Finestra di Contesa Minima e Massima, Contention Window
(CWmin[AC] ,CWmax[AC]);
o il tempo limite TXOP-limit[AC]
6
Più è alta la priorità di una AC, più sono piccoli i parametri AIFS[AC],
CWmin[AC] ,CWmax[AC]; più è grande TXOP-limit[AC], maggiore risulta la
capacità della categoria di accesso. In ogni caso i valori di CWmin[AC] e
CWmax[AC] devono essere scelti con molta cura per evitare situazioni di
alta probabilità di collisioni nei flussi di traffico che appartengono alla
stessa AC;
•
all’interno di ogni stazione 802.11e, uno schedulatore risolve le collisioni
virtuali tra le code AC, ovvero tra le varie istanze CSMA/CA, abilitando
alla trasmissione sempre la coda associata alla priorità più alta.
5.2.3 Differenziazione del traffico a livello LLC
Come
già
precedentemente
sottolineato,
l’obiettivo
principale
della
implementazione di un nuovo meccanismo di differenziazione del traffico è
realizzata attraverso uno schema di priorità simile a quello che lo standard IEEE
802.11e introdurrebbe se dovesse gestire un traffico molto eterogeneo,
mantenendo comunque una compatibilità di base con le WLAN esistenti.
I punti cardine del sistema sono:
•
nessuna modifica introdotta al livello MAC: per questo motivo il
protocollo CSMA/CA è applicato come nello standard IEEE 802.11b; le
6
Il valore di AIFS deve essere grande almeno quanto l’intervallo DIFS; l’unica eccezione è
rappresentata nel caso di un AP che può usare un AIFS grande anche μs.
146
Configurazione di nodi wireless con supporto della qualità del servizio
modifiche sono limitate al livello LLC;
•
la differenziazione del traffico è basata sull’inserimento delle frame di
differenti categorie di traffico in differenti code; tale divisione delle frame
viene effettuata in base ad un etichetta che nella soluzione proposta è
rappresentata dal valore del campo ToS (Type of Service);
sebbene le priorità possano essere forzate usando un qualsiasi algoritmo già
esistente (round robin, EDF, ecc.), la scelta di emulare EDCA ha portato ad un
supporto delle priorità attraverso contese e collisioni virtuali tra le code LLC.
Figura 5.1: Il ToS nel pacchetto IP
In figura 5.2 è rappresentato un disegno concettuale del nuovo livello LLC e
delle sue due componenti principali, le code di traffico e lo schedulatore delle
collisioni. Le diverse frame vengono accodate in accordo con le indicazioni dei
livelli superiori: in questa implementazione è stato usato lo standard DiffServ
nel campo ToS del pacchetto IP. Ogni coda di traffico i-ma ha una particolare
priorità che è espressa dai valori di quantità chiamate Finestra Minima e
Finestra Massima di Contesa Virtuale (VCWmin,i ,VCWmax,i - Minimum, Maximum
147
Configurazione di nodi wireless con supporto della qualità del servizio
Virtual Contention Window).
Figura 5.2: Schema del sistema delle code del livello LLC introdotto da HostQs
Le code di traffico sono poi servite in accordo all’ordine stabilito da una contesa
virtuale tra differenti Finestre di Connessione Virtuali VCWi : ad ogni coda di
traffico i-ma viene associato un numero intero tra 0 e VCWi che rappresenta il
tempo di backoff per la coda i-ma, tempo che sarà indicato con tb,i . La coda con
il tempo di backoff più piccolo, che sarà indicato con tb,min , vince la contesa
virtuale e viene quindi servita per prima: la frame in cima a tale coda sarà
148
Configurazione di nodi wireless con supporto della qualità del servizio
perciò la prima ad essere trasferita al livello MAC una volta scaduto il timer di
backoff, cioè non appena trascorso il tempo tb,min . Allo stesso istante in tutte le
altre code, il valore tb,i viene decrementato di una quantità che corrisponde
esattamente a tb,min e ci si prepara ad un nuovo processo di contesa. La coda
vincitrice quindi genera un altro tempo di backoff che il cui il valore è tra zero 0
e VCWi e la nuova contesa può iniziare.
Se in due code diverse il timer di backoff scade allo stesso istante, la coda a
trasferire la prima frame al MAC è quella con la priorità nominale più alta
mentre la coda perdente (o le code perdenti) che partecipavano alla collisione
virtuale generano un altro tempo di backoff dove però la nuova Finestra di
Connessione Virtuale è più grande e il suo valore cresce in maniera
esponenziale secondo la relazione:
VCWnew = 2 * VCWold + 1
Di conseguenza viene generato un flusso da inviare al MAC e l’ordine delle
frame risulta lo stesso di quello che sarebbe stato rispettato da una stazione
wireless 802.11e.
Successivamente le frame vengono trasmesse (o sarebbe meglio dire che
cercano di essere trasmesse) con spaziatura temporale che ricorda quella del
sistema di backoff orientato alle priorità adottato nello standard 802.11e.
Ovviamente con questo metodo a fianco alla struttura dei tempi di backoff
imposta al MAC si introduce un ulteriore backoff ma questa sovrapposizione è
necessaria per forzare la stessa priorità tra le varie stazioni wireless della
WLAN: in questo modo il traffico con bassa priorità accede al canale in media
con un tempo più lungo del normale periodo di backoff.
149
Configurazione di nodi wireless con supporto della qualità del servizio
In seguito si vedrà che il backoff addizionale viene richiesto solo se più di una
stazione implementa la differenziazione di traffico allo strato LLC, nel qual caso
il traffico con bassa priorità viene egualmente penalizzato.
5.2.4 L’ implementazione di HostQs
L’architettura di seguito proposta è stata implementata su un sistema Linux
facente uso di una scheda di rete dotata di una tecnologia particolare 7 . Il
sistema è fornito quindi di un driver capace di supportare la cosiddetta
funzionalità HostAP [41], cioè ha la capacità di gestire le funzioni dello standard
IEEE 802.11 in modo tale da trasformare un normale computer portatile fornito
di una scheda di rete wireless in un potente Access Point senza richiedere
l’utilizzo di alcun firmware ulteriore.
Oltre a comportarsi come un Access Point, la funzionalità HostAP supporta
anche la possibilità di gestire le normali operazioni sulle stazioni di una sottorete
semplice o BSS (Basic Service Set).
Nella modalità HostAP, il firmware si occupa della gestione dei compiti basati sui
cosiddetti tempi critici come ad esempio l’invio di segnali e la richiesta di
conferme di avvenuta ricezione delle frame (in gergo dette acknowledgement o
ack), lasciando gli altri compiti di gestione al computer host. Questo driver
implementa inoltre le funzionalità base necessarie per inizializzare e configurare
una scheda basata su tecnologia Prism2, per mandare e ricevere frame e per
raccogliere informazioni di tipo statistico. Inoltre esso include l’implementazione
di molte funzioni IEEE 802.11 come l’autenticazione (e la deautenticazione),
l’associazione (la reassociazione e la deassociazione) di una utente mobile, la
trasmissione dati tra due stazioni wireless, il controllo della potenza (PS - Power
7
scheda di rete dotata di chipset basato su tecnologia Intersil’s Prism2/2.5/3.
150
Configurazione di nodi wireless con supporto della qualità del servizio
Saving) e buffering di segnali e di frame per le stazioni PS.
HostQs è stato implementato attraverso la modifica del codice originale del
driver HostAP e l’aggiunta di un modulo supplementare che si occupa di frame
allo strato LLC (figura 5.2). Il modulo del driver contiene una funzione di
trasmissione modificata che invia i pacchetti di rete non direttamente allo strato
MAC ma prima al modulo supplementare la cui funzione di accodamento è
rappresentata attraverso simboli del kernel. La funzione di trasmissione
originale è mantenuta nel driver sotto un nome diverso e rappresentata
anch’essa attraverso simboli del kernel in modo da permettere che possa essere
utilizzata dal modulo supplementare per la spedizione dei pacchetti.
Il
modulo
supplementare
conserva
i
pacchetti
in
code
separate,
dipendentemente dai loro valori del ToS; un elemento separato risolve la
contesa virtuale e schedula le frame secondo il risultato della contesa virtuale.
Quando pacchetti devono essere spediti, il modulo utilizza la funzione di
trasmissione originale implementata nel driver di HostAP, così i messaggi
vengono spediti nello stesso ordine in cui erano stati accodati dallo strato
superiore.
Le code di traffico implementate con priorità decrescente sono le seguenti :
•
traffico in tempo reale (ad esempio chiamate VoIP)
•
applicazioni di streaming multimediale
•
dati best effort (trasferimento file, navigazione web, ecc.)
e i valori di VCW che vi sono stati assegnati sono mostrati in tabella 5.1.
La realizzazione è stata ottimizzata in modo da poter essere lanciata anche su
terminali lenti: nelle prove eseguite è stato usato un sistema operativo Linux
versione 2.4.22 installato su un Pentium III da 450 MHz con 256 MB RAM.
151
Configurazione di nodi wireless con supporto della qualità del servizio
Una implementazione Open-Source di HostQs è disponibile su rete [42].
Tabella 5.1: Impostazione del VCW
5.2.5 Risultati del test
In figura 5.3 è mostrata la configurazione di rete utilizzata per il test.
Figura 5.3: Scenario del test
Il nodo di HostQs è configurato come un Access Point per una BSS che include
alcune stazioni wireless indicate con WS (Wireless Stations). HostQs raccoglie
152
Configurazione di nodi wireless con supporto della qualità del servizio
traffico da un sintetizzatore di voce, da un generatore di streaming video e da
un generatore di traffico TCP. Quindi spedisce le frame alle varie WS dopo aver
stabilito le priorità attraverso il meccanismo della contesa virtuale.
Le priorità sono assegnate in ordine decrescente a voce, video e dati
rispettivamente; in tabella 5.1 sono stati riportati i valori scelti per le rispettive
VCWmin e VCWmax. Le stazioni wireless accedono al canale usando i criteri dello
standard IEEE 802.11b senza alcun miglioramento e senza alcuna priorità sul
traffico. Così la differenziazione di traffico e l’impostazione delle priorità è
realizzata solamente dalla direzione di downstreaming, in altre parole il blocco
avviene tra Queue Manager e il driver HostAP ma solo nella fase di invio dei dati
diretti alle WS.
La fonte di voce sintetica proveniente dal server voce è pensata per emulare un
flusso di traffico che potrebbe essere generato da VoIP codificato attraverso vocoder G.711 a 64 Kbps senza nessuna funzione di rivelazione di voce VAD
(Voice Activity Detection). Lo streaming video è di tipo Unicast, scorre con una
frequenza di 350 Kbps ed è generato da un server Fenice, un progetto Open-
Source studiato appunto per applicazioni di questo tipo[43]. Alcuni esperimenti
comprendono anche interferenza di traffico UDP, generato sinteticamente nella
direzione di downstream. La valutazione delle prestazioni relative alla qualità
della voce è operata da elementi come Agilent VQT e PESQ [44].
PESQ (Perceptual Evaluation of Speech Quality) è un tool di misurazione che
può predire i risultati di un test di ascolto su sistemi di telefonia basandosi su un
modello sensoriale che confronta il segnale originale, e perciò non processato,
col il segnale degradato dalla rete o da un elemento della rete. La qualità che
alla fine ne risulta è analoga a una “qualità media soggettivamente testata”,
153
Configurazione di nodi wireless con supporto della qualità del servizio
cioè misurata con prove empiriche; il valore che si dà a questa grandezza si
indica con l’acronimo MOS (Mean Opinion Score).
I risultati di PESQ sono calibrati usando un database molto complesso di test
soggettivi che dà alla qualità media soggettivamente testata una valutazione da
1 a 4.5. La qualità eccellente è indicata con valori tra 3.2 e 4.5, quella mediocre
è rappresentata da valori di PESQ tra il 2.5 ed il 3.2, quella cattiva infine ottiene
valori inferiori a 2.5.
La valutazione della prestazione di traffico video è operata direttamente dai
client video, in termini di percentuale di pacchetti video perduti.
Come nota finale, si riporta l’osservazione che l’uso di HostQs in una situazione
dove la BSS è formata da stazioni wireless che non offrono un supporto di
qualità del servizio, ha suggerito una semplificazione nell’algoritmo di
schedulazione di HostQs stesso. Infatti c’è effettivamente un piccolo svantaggio
nell’usare un meccanismo supplementare di gestione dei tempi di backoff nello
strato LLC poiché ogni WS usa una scheda gestita dai criteri di IEEE 802.11b: il
traffico al livello di HostQs sarebbe perciò inutilmente ritardato e i relativi
pacchetti verrebbero retrocessi per abbassare le priorità rispetto al traffico
proveniente dalle stazioni wireless, senza tener conto delle effettive priorità
interne.
Analogamente l’uso di HostQs in un’architettura che non supporta qualità del
servizio ha poco senso in termini di AIFS (Arbitration Inter Frame Space), cioè
lo spazio tra due frame. Per questo motivo, lo strato LLC dell’HostQs è
autorizzato a inoltrare immediatamente le frame al livello MAC quando la
contesa è risolta, senza aspettare il tempo di backoff.
Le contese virtuali divengono così semplicemente un algoritmo di ordinazione
all’interno del blocco HostQs, sebbene abbiano l’importantissima proprietà di
fornire un’ordinazione simile a quella della funzione EDCA dello standard
154
Configurazione di nodi wireless con supporto della qualità del servizio
802.11e.
Nella tabella 5.2 è mostrata una valutazione preliminare: lo scopo è riportare
delle scelte di CWmin e CWmax col relativo throughput ottenuto da due flussi UDP
con diverse priorità che usano quei CW.
Ai due flussi corrispondono diversi valori del ToS nell’header IP; questi valori del
ToS sono quindi elencati secondo tre categorie di accesso diverse, una alta
indicata con H, una media indicata con M e infine una bassa indicata con L; il
ToS pari a 6 indica una priorità alta, pari a 5 per una priorità media, pari al
valore nullo per una priorità bassa.
Tabella 5.2: Throughput dei flussi UDP per differenti valori di CW,
ovvero per priorità alta (H), media (M) e bassa (L)
I throughput della tabella misurati in Mbps evidenziano che:
•
è possibile ottenere delle priorità scalabili, cioè gradi diversi di priorità.
Infatti da un’analisi più accurata dei valori risulta che nella metà
superiore della tabella si nota una differenza di throughput molto grande
tra flussi con priorità alta e i flussi con priorità bassa; nella metà inferiore
della tabella invece la differenza di throughput tra i flussi con priorità alta
e i flussi con priorità media è molto ridotta;
155
Configurazione di nodi wireless con supporto della qualità del servizio
•
CWmin è il parametro dominante, mentre il sistema è insensibile alle
variazioni del valore di CWmax. Si osservi infatti che nella seconda riga
della tabella 5.2 è stato cambiato solo un valore rispetto alla prima riga:
il CWmin è stato ridotto da un valore 3 ad un valore nullo; per la relativa
categoria di accesso bassa (indicata con L) questo equivale a dare una
priorità molto bassa a tutti i flussi di quella categoria, come del resto ci si
poteva aspettare.
Si noti poi che nella terza riga della tabella 5.2 invece, l’unico valore ad essere
stato variato risulta il CWmax della categoria di accesso alta, ridotta da un valore
di 1023 a un valore di 511: la risposta del sistema in termini di throughput
risulta assolutamente invariata!
Il successivo insieme di risultati si riferisce ad un singolo flusso VoIP con rumore
di fondo crescente che interferisce con traffico UDP.
Figura 5.4. PESQ come funzione del traffico UDP formato da un flusso VoIP e traffico
interferente
156
Configurazione di nodi wireless con supporto della qualità del servizio
La figura 5.4 mostra il PESQ rilevato per tale flusso visto come funzione del
traffico globale offerto alla WLAN. Le due curve della figura riportano le
prestazioni del flusso VoIP con e senza il supporto delle priorità. Si vede
chiaramente che nel caso in cui vengano applicati solamente i normali criteri di
gestione del traffico dello standard IEEE 802.11b senza il supporto delle
priorità, la qualità del flusso VoIP comincia a degradarsi appena dopo i 4 Mbps
di traffico offerto e che prima dei 5 Mbps la qualità scende molto al di sotto di
livelli accettabili.
L’ultimo insieme di risultati delle figure 5.5, 5.6 e 5.7 mostrano le prestazioni di
una WLAN che trasporta un singolo flusso VoIP e 1, 2 o 3 streaming video
concorrenti, considerati di nuovo come una funzione di traffico UDP
interferente.
È interessante osservare che nel caso in cui vengano applicati solamente i
normali criteri di gestione del traffico IEEE 802.11 senza il supporto delle
priorità, sia VoIP che i flussi di video incontrano una degradazione della qualità
approssimativamente della stessa consistenza che si riscontra fra i 4.5 Mbps e 5
Mbps, dipendentemente dal numero di video concorrenti. Al contrario il traffico
che ha precedenza, cioè quello voce e video, sebbene con priorità diverse,
mantiene lo stesso livello di QoS indipendentemente dal carico della rete.
157
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 5.5: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP
interferente formato da un flusso VoIP, uno streaming video e traffico interferente
Figura 5.6: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP
interferente formato da un flusso VoIP, due streaming video e traffico interferente
158
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 5.7: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP
interferente formato da un flusso VoIP, tre streaming video e traffico interferente
5.2.6 Conclusioni e sviluppi futuri
Nel contesto delle reti locali ad accesso wireless 802.11 (WLAN) è stato studiato
un approccio innovativo che punta alla differenziazione del traffico al livello LLC
in base a dei requisiti di qualità del servizio. Questo approccio chiamato HostQs
è basato sulla creazione di una coda al livello LLC per ogni categoria di traffico
desiderata e sulla schedulazione delle code in base a priorità di traffico.
Questo meccanismo può offrire una differenziazione di traffico per lo standard
IEEE 802.11b attualmente in uso che non supporta alcun tipo di gestione delle
precedenze e allo stesso tempo può servire per migliorare il supporto della
qualità del servizio già previsto nel nuovo standard 802.11e, benché nella
versione attuale la gestione sia limitata a sole 4 categorie di accesso.
159
Configurazione di nodi wireless con supporto della qualità del servizio
È stato implementato a tale scopo un meccanismo basato su un Access Point
Open-Source che lavora in ambiente Linux e che si appoggia su un altro
interessante progetto chiamato HostAP che richiede l’uso di una scheda di rete
basata su un chipset con tecnologia Prism2.
Sono stati poi mostrati dei risultati preliminari che illustrano la flessibilità e
l’efficacia di configurazioni di BSS in cui HostQs venga montato su un solo nodo,
circondato poi da molte altre stazioni che lavorano in una normale
ambientazione wireless basata sullo standard IEEE 802.11b.
Gli sviluppi futuri prevedono uno scenario in cui anche le singole stazioni
wireless implementino un sistema di differenziazione del traffico basato su classi
di servizio che vengano gestite dallo strato LLC in modo da raggiungere una
interoperabilità ottimale tra i vari nodi di una rete.
160
Configurazione di nodi wireless con supporto della qualità del servizio
Capitolo 6
Sviluppo software e misurazioni
Per poter realizzare l’idea iniziale di sviluppare un prodotto software che
gestisca il supporto della qualità del servizio su sistemi wireless secondo i criteri
utili per il nostro fine, il punto di partenza è stato l’utilizzo dello schedulatore
fornito da Queue Manager che si appoggia a sua volta su HostAP:
•
il primo pacchetto software fornisce il vero e proprio schedulatore che a
seconda di determinate informazioni lette nell’header IP, accoda i
pacchetti in diverse liste, ognuna delle quali dotata di un proprio livello di
priorità;
•
il secondo software invece fornisce il driver che gestendo i tempi critici
delle schede wireless dotate di tecnologia Intersil Prism, è capace di
utilizzare un normale terminale mobile come se si trattasse di un vero e
proprio Access Point: esso permette di ricevere - oltre che di inviare - le
informazioni via radio.
Questi due software messi insieme forniscono quello che è stato chiamato
l’approccio HostQs:
161
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 6.1: Gestione dei sottolivelli LLC e MAC
Tuttavia l’HostQs, di cui è presente una implementazione su Internet [42], basa
la distinzione del traffico e la selezione dei pacchetti sul parametro ToS (Type of
Service) dell’header IP.
In verità tale campo fu pensato proprio per scopi di questa natura: infatti nei
suoi 8 bit, il ToS ne contiene 3 che rappresentano il sottocampo chiamato
Precedence, i 3 bit successivi sono i flag Delay, Throughput e Reliability, mentre
gli ultimi 2 bit completano l’ottetto e sono riservati per scopi futuri.
162
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 6.2: I bit del campo ToS
Su 3 bit possono codificarsi 8 valori, ma come già affermato precedentemente,
Queue Manager implementa solo 3 code, a ognuna delle quali è associata un
livello di precedenza.
Le 3 code si riferiscono a:
•
traffico in tempo reale (ad esempio chiamate VoIP)
•
applicazioni di streaming multimediale
•
dati best effort (trasferimento file, navigazione web, ecc.)
L’ordine dell’elenco rappresenta anche l’ordine della priorità.
Ma da un’analisi più approfondita del codice sorgente si può vedere che esiste
163
Configurazione di nodi wireless con supporto della qualità del servizio
una categoria di pacchetti che non subisce il blocco dello schedulatore: in totale
quindi le classi di priorità sono 4 e non 3!
Infatti la procedura che si occupa dell’analisi del ToS e dell’accodamento di
pacchetti è dichiarata come segue:
void queue_up_skb(struct sk_buff *skb, struct net_device *dev)
e all’interno di tale procedura vengono effettuati i seguenti controlli:
if(*((u16 *)(skb->data + 12)) != __constant_htons(ETH_P_IP)) {
…
queue = -1;}
e
if (*((u16 *)(skb->data + 12)) == __constant_htons(ETH_P_CONTROL)) {
…
queue = -1;}
Questi controlli servono ad analizzare un determinato flag dell’header IP: se
risulta che esso sia stato riempito con il valore ETH_P_IP oppure con il valore
164
Configurazione di nodi wireless con supporto della qualità del servizio
ETH_P_CONTROL, allora il pacchetto in questione è un dummy ovvero un
pacchetto di controllo.
Quindi i pacchetti che non passano attraverso lo schedulatore di HostQs sono
quelli che hanno funzioni utili per la gestione della rete e che per questo motivo
è importante che vengano consegnati con il minimo ritardo possibile: il valore
negativo della variabile queue sintetizza appunto questa caratteristica.
Può capitare che un pacchetto dummy contenga proprio nel suo header le
informazioni utili per la gestione della rete; ciò avviene ad esempio quando
viene richiesto un pacchetto di aggiornamento delle tabelle di mapping.
Le informazioni richieste in casi come questo sono semplicemente l’indirizzo IP
dell’host mobile o di uno dei router per i quali vengono instradati i pacchetti che
quell’host genera.
Ovviamente non sarebbe utile inviare un pacchetto senza dati perciò utilizzando
la tecnica del piggybacking, si inserisce payload anche nei dummy.
Perciò anche se abbastanza raramente, può capitare che alcuni dati che a rigore
dovrebbero avere una priorità bassa, vengano incapsulati con un header
contenente informazioni prioritarie e che per questo motivo vengano spediti
rapidamente, senza neanche passare nel blocco Queue Manager.
Per evidenziare questa caratteristica di funzionamento, nello schema principale
del funzionamento di HostQs che viene ripresentato di seguito, si nota una
freccia tratteggiata che va da direttamente da Queue Manager al blocco
identificativo del Livello MAC:
165
Configurazione di nodi wireless con supporto della qualità del servizio
Figura 6.3: Schema principale del funzionamento di HostQs
Di seguito si riporta quella parte del codice della funzione queue_up_skb che si
occupa di leggere il campo ToS e a seconda del valore rilevato, associare un
livello di priorità al relativo pacchetto.
166
Configurazione di nodi wireless con supporto della qualità del servizio
tos=( *((u8 *)(skb->data + ETH_HLEN + 1) ) & 0xE0) >> 5;
switch (tos)
{
case 0: queue=0; break;
case 1: queue=0; break;
case 2: queue=1; break;
case 3: queue=1; break;
case 4: queue=2; break;
case 5: queue=2; break;
case 6: queue = -1; break;
case 7: queue = -1; break;
}
La suddetta parte di codice sarà l’oggetto delle variazioni, volendo effettuare
una differenziazione basata non sulla tipologia di traffico ma su una priorità
intrinseca dell’utente.
167
Configurazione di nodi wireless con supporto della qualità del servizio
6.1 Modifica del codice di Queue Manager
La modifiche da effettuare al codice sorgente di Queue Manager deve solo
considerare il cambiamento della politica di accodamento dei pacchetti: invece
che distinguerli a seconda del ToS, si vuole che la differenziazione e
l’ordinamento nelle code avvengano in base al valore degli indirizzi IP.
In questo modo la distinzione non sarà tra classi di traffico bensì da
identificatori dei utente!
Perciò in accordo con l’idea iniziale, gli utenti verranno disposti come segue:
•
nella coda con priorità più alta andranno gli utenti aventi un indirizzo IP
particolare: nel nostro studio quelli che vanno da X.X.X.1 a X.X.X.10;
•
nella coda con priorità intermedia andranno gli utenti associati agli
indirizzi IP da X.X.X.11 a X.X.X.30;
•
la coda con l’ultimo livello di priorità conterrà tutti gli utenti identificati
con indirizzi che vanno da X.X.X.31 a X.X.X.60.
Le tre classi possono contenere rispettivamente 10, 20 e 30 utenti giacché si
immagina che gli utenti con priorità alta siano pochi mentre quelli con priorità
bassa siano molto numerosi.
Si ricorda che l’associazione dell’indirizzo IP di categoria alta, media o bassa
avverrà per opera di un DHCP impostato adeguatamente.
168
Configurazione di nodi wireless con supporto della qualità del servizio
Rimane comunque importante dare una priorità massima ai pacchetti dummy:
quindi sfruttando le proprietà della funzione queue_up_skb, si lasceranno
passare tutti quei pacchetti per i quali il valore della variabile queue risulta
negativo. Al contrario, tutti i pacchetti con un valore positivo della variabile
queue verranno imbottigliati nelle 3 code così come precedentemente stabilito:
queue
priorità
Pacchetti dummy
-1
massima
IP X.X.X.1 – X.X.X.10
0
alta
IP X.X.X.11 – X.X.X.30
1
media
IP X.X.X.31 – X.X.X.60
2
bassa
Tabella 6.1: Priorità come funzione dell’indirizzo IP
Si riporta di seguite la parte relativa alla nuova funzione queue_up_skp dopo le
modifiche apportate:
ip_latest_byte=( *((u8 *)(skb->data + ETH_HLEN + 15) ));
tos=( *((u8 *)(skb->data + ETH_HLEN + 1) ) & 0xE0) >> 5;
switch (tos){
case 6: queue = -1; break;
case 7: queue = -1; break;
default: switch(ip_latest_byte){
case((ip_latest_byte>=1)&(ip_latest_byte<=10)): queue=0; break;
case((ip_latest_byte>=11)&(ip_latest_byte<=30)): queue=1; break;
case((ip_latest_byte>=31)&(ip_latest_byte<=60)): queue=2; break;
} /* END switch(ip_latest_byte) */
}/* END switch (tos) */
169
Configurazione di nodi wireless con supporto della qualità del servizio
6.2 Misurazioni
Non potendo effettuare misure su una rete reale, per verificare l’effettivo
funzionamento del montaggio del Queue Manager modificato e per quantizzare
in qualche modo il livello di prestazioni, è stato creato un testbed per la
misurazione composto da un programma Client e da un programma Server.
Il programma Client genera traffico formato da un numero finito di pacchetti
abbastanza grande da poter considerare il raggiungimento di una condizione di
regime.
Da linea di comando si può decidere:
•
a quale indirizzo IP indirizzare il traffico;
•
quale porto utilizzare;
•
quale valore del campo ToS assegnare per quella comunicazione.
Quindi viene aperta una socket che incanala il traffico con le caratteristiche
impostate.
Il programma Client non dà output, se non una conferma di ricezione per ogni
pacchetto inviato.
Il programma Server viene lanciato indicando da linea di comando
170
Configurazione di nodi wireless con supporto della qualità del servizio
•
l’indirizzo IP;
•
il porto utilizzato;
dopodiché rimane semplicemente in ascolto.
Nel momento in cui viene lanciato il programma Client, del traffico comincia ad
arrivare all’indirizzo del programma Server che quindi può iniziare delle
misurazioni statistiche sui tempi di interarrivo di ogni singolo pacchetto.
Per la misurazione sono necessarie almeno due macchine: per la prima è
necessaria una scheda wireless basata su tecnologia Intersil Prism e l’utilizzo del
sistema operativo Linux su cui risulti montato sia HostAP che il Queue Manager
modificato.
Per la seconda macchina è necessaria solo una scheda wireless; la tecnologia di
base non è importante.
Lanciando sulla prima macchina il programma Server e utilizzando la seconda
macchina per inviare contemporaneamente 3 processi del programma Client,
tutti con lo stesso indirizzo IP e porto del Server ma con tre diversi valori di
impostazione del ToS, il programma Server riceverà tre flussi di traffico
concorrenti e per ognuno opererà le misurazioni.
Poiché il programma Server lavora a valle del blocco Queue Manager, le
misurazioni sui tempi di interarrivo rispecchierà lo schema delle priorità.
Figura 6.4: Passaggio di controllo tra HostAP e Queue Manager
171
Configurazione di nodi wireless con supporto della qualità del servizio
6.2.1 Studio dei parametri statistici
I parametri che maggiormente caratterizzano le elaborazioni statistiche sono
rappresentati dalla media aritmetica e dalla varianza.
Il programma Server opera uno studio della media utilizzando un ciclo iterativo
in cui ad ogni arrivo di un pacchetto, si rileva il tempo trascorso dall’ultimo
pacchetto ricevuto e si aggiorna la media.
Per quanto riguarda lo studio dell’altro parametro, non è possibile implementare
un processo iterativo semplice che dia il valore esatto della varianza. Tuttavia
poiché l’interesse del presente lavoro di tesi è incentrato su altri obiettivi, ci si
accontenta di un valore approssimato della varianza purché l’implementazione
del processo di calcolo sia semplice e veloce.
6.2.2 Calcolo della varianza approssimata
La varianza di una serie di misurazioni è un parametro che rappresenta lo
scostamento quadratico medio rispetto al valore medio.
La sua formula è
( xi − xn ) 2
σ =∑
n −1
i =1
n
2
dove
•
xi è la singola misurazione;
•
xn è la media considerata su n valori.
172
Configurazione di nodi wireless con supporto della qualità del servizio
Risulta perciò:
σ 2 (1) = 0
( x1 − x2 ) 2 + ( x2 − x2 ) 2
σ (2) =
1
2
( x1 − x3 ) 2 + ( x2 − x3 ) 2 + ( x3 − x3 ) 2
σ (3) =
2
2
…
( x1 − xn−1 ) 2 + ( x2 − xn−1 ) 2 + ... + ( xn−1 − xn−1 ) 2
σ (n − 1) =
n−2
2
Dalla composizione delle reazioni precedenti si evince che non è possibile
realizzare un algoritmo iterativo semplice per la varianza giacché ad ogni passo
bisognerebbe calcolare ex novo tutti i termini quadratici che dipendono dal
valore di una media aggiornata.
Ad esempio mentre nel calcolo di σ 2 (2 ) , il primo termine tra parentesi al
numeratore
( x1 − x2 ) 2
dipende da una media calcolata su 2 valori, nel calcolo successivo di σ 2 (3) , il
termine analogo
( x1 − x3 ) 2
dipende da una media calcolata su 3 valori.
173
Configurazione di nodi wireless con supporto della qualità del servizio
Sarebbe perciò necessaria la memorizzazione di tutte le singole misurazioni xi
e di tutti i valori medi xn e ciò rende evidentemente impossibile il calcolo in
tempo reale del valore della varianza.
Tuttavia se il numero delle misurazioni è molto grande, si può assumere:
xn−1 ≅ xn
e con tale approssimazione si può scrivere:
( x1 − xn−1 ) 2 + ( x2 − xn−1 ) 2 + ... + ( xn−1 − xn−1 ) 2 n − 2 ( xn − xn ) 2
⋅
+
σ (n ) ≅
n−2
n −1
n −1
2
in altre parole si giunge alla formula:
n − 2 ( xn − xn ) 2
+
σ (n ) ≅ σ (n − 1) ⋅
n −1
n −1
2
2
che potrebbe essere usata in un algoritmo iterativo.
Ma questo ancora non è possibile perché il termine additivo
( x n − xn ) 2
n −1
tende ad annullarsi al crescere di n, mentre il primo termine contenente il
fattore moltiplicativo
n−2
<1
n −1
174
Configurazione di nodi wireless con supporto della qualità del servizio
tende a decrescere, cosa inaccettabile per il calcolo della varianza che può
solamente aumentare.
Ora supponendo che il numero di misurazioni sia molto elevato, si può
considerare la varianza approssimata nel seguente modo:
( xn − xn ) 2
σ (n ) ≅ σ (n − 1) +
n −1
2
2
Questo valore assunto per σ 2 (n ) porta con sé una quantità additiva di errore
accumulata soprattutto nella fase iniziale del calcolo quando l’approssimazione
xn−1 ≅ xn
non è una operazione lecita a causa di un valore non ancora sufficientemente
elevato di n.
In conclusione, poiché il presente studio si focalizza su obiettivi diversi dal
calcolo esatto dei parametri statistici e i relativi errori, il valore della varianza
così approssimato può essere considerato tollerabile perché comunque dà
un’idea della variazione media di parametri relativi al traffico.
175
Configurazione di nodi wireless con supporto della qualità del servizio
Appendice A
Codici dei programmi
A.1 Codice del programma Server
#include “client_lat.h”
void uso();
int main(int argc, char *argv[]){
int
i,n,num,iter;
int
clilen,childpd;
int
sockfd,newsockfd;
char
newpk[dimpack];
timeval timestart,timestop;
timeval arrivestart,arrivestop;
long
interarr,media=0,varianza;
/* prototipo di utilizzo */
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
variabili di appoggio */
identificatori di processo */
identificatori di socket */
buffer di ricezione */
contatori temporali */
dell’intero processo*/
contatori temporali degli */
interarrivi */
media e deviazione standard */
degli interarrivi */
if(argc!=2){
uso();
exit(1);
}
/* lettura dei parametri di ingresso */
if(sscanf(argv[1],”%i”,&port_num)!=1){
uso();
exit(1);
}
/*porto del server */
/* apertura di una socket TCP (SOCKET STREAM) */
if((sockfd=socket(AF_INET,SOCK_STREAM,0))<0){
perror(“socket open error\n”);
exit(1);
}
/* riempimento della struttura serv_addr */
bzero((char*)&serv_addr,sizeof(serv_addr));
serv_addr.sin_family=AF_INET;
serv_addr.sin_addr.s_addr=htonl(INADDR_ANY);
176
Configurazione di nodi wireless con supporto della qualità del servizio
serv_addr.sin_port=htons(port_num);
/* bind all’indirizzo locale del server */
/* in modo che il client possa trasmettere dati */
if(bind(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr))<0){
perror(“Impossibile eseguire la bind\n”);
exit(1);
}
/*attesa di una connessione da un processo client */
listen(sockfd,7);
/* server concorrente attivo */
printf(“il server è pronto!\n\n”);
for(;;){
clilen=sizeof(cli_addr);
if((newsockfd=accept(sockfd,(struct
sockaddr*)&cli_addr,(unsigned*)&clilen))<0){
perror(“server:errore di accept\n”);
exit(0);
}
/* inizio processo figlio */
if((childpd=fork())<0){
perror(“server: errore di fork!\n”);
exit(0);
}
if(childpd==0){
close(sockfd);
/* chiude la socket padre */
/* lettura dei messaggii del client */
if((nbytes=recvfrom(newsockfd,pacch,dimpack,0,ptrcli_addr,(unsigned*)&
clilen))<0){
perror(“errore nella read!\n”);
exit(0);
} /* END if */
else{
gettimeofday(&timestart,NULL);
/* inizio misurazione temporale */
/* dell’intero processo */
totalnbytes=nbytes;
printf(“inizio ricezione di %d pacchetti\n”,numpack);
printf(“all’istante%d\n\n”,(timestart.tv_sec*1000000+
timestart.tv_usec));
for(iter=1;iter<=numpack;iter++){
gettimeofday(&arrivestart,NULL);
/* inizio misurazione del */
/* tempo dell’interarrivo */
if((nbytes=recvfrom(newsockfd,newpk,dimpack,0,ptrcli_addr,
(unsigned*)&clilen))<0){
perror(“errore nella read!\n”);
exit(0);
} /* END if */
else{
gettimeofday(&arrivestop,NULL);
/* fine misurazione del */
177
Configurazione di nodi wireless con supporto della qualità del servizio
/* tempo dell’interarrivo */
totalnbytes=totalnbytes+nbytes;
interarr=(arrivestop.tv_sec-arrivestart.tv_sec)*1000000+
(arrivestop.tv_usec-arrivestart.tv_usec);
printf(“pacchetto %d ricevuto in %d us\n”,iter,interarr);
/* calcolo della media */
media=((media*(iter-1))+interarr)/iter;
printf(“media degli interarrivi %d us\n”,media);
/* calcolo della varianza APPROSSIMATA */
if(iter==1)
varianza=0;
else{
varianza=varianza+(interarr-media)*(interarr-media)/(iter-1);
printf(“varianza degli interarrivi %d us2 \n”,varianza);
} /* END else */
printf(“byte ricevuti finora %d \n”,totalnbytes);
} /* END else */
} /* END for */
gettimeofday(&timestop,NULL);
/* fine misurazione temporale */
/* dell’intero processo */
printf(“\ntempo totale di trasmissione %d
us\n\n”,(timestop.tv_sectimestart.tv_sec)*1000000+(timestop.tv_usectimestart.tv_usec));
} /* END else */
/* decommentare nel caso si voglia anche l’invio di un ack
if((num=sendto(newsockfd,ack,sizeof(ack),0,(struct
sockaddr*)ptrcli_addr,clilen))<0){
perror(“errore nella write \n”);
exit(0);
} */
/* chiusura della socket figlio */
close(newsockfd);
exit(0);
} /*END if processo figlio */
} /*END processo padre */
printf(“fine ciclo server \n\n”);
exit(0);
} /* END main */
/* prototipo di comando da dare da terminale */
void uso(){
printf(“Uso: server port_number \n”);
printf(“
port_number : numero del porto del server \n”);
}
178
Configurazione di nodi wireless con supporto della qualità del servizio
A.2 Codice del programma Client
#include <iostream.h>
#include <stdlib.h>
#include “client_lat.h”
void uso();
/* prototipo di utilizzo */
int main(int argc, char *argv[]){
char
ack[4];
int
i,j,iter;
int
nbytes;
int
sockfd;
int
servlen;
int
tosval;
int
optlen=sizeof(char);
char
*target;
/*
/*
/*
/*
/*
/*
/*
/*
buffer per ricezione dell’ack */
variabili di ciclo */
byte ricevuti */
descrittore della socket */
lunghezza indirizzo server */
valore del tos */
lunghezza variabile optval */
indirizzo del server */
/* inizializzazione della stringa */
for(j=0;j<dimpack;j++)
pacch[j]=‘x’;
/* se il comando dato da terminale non prevede tre argomenti */
/* viene visualizzato il prototipo di chiamata
*/
if(argc!=4){
uso();
exit(1);
}
/* lettura dei parametri di ingresso */
/* indirizzo del server */
target=argv[1];
/*porto del server e valore del tos */
if(((sscanf(argv[2],”%i”,&port_num))&&(sscanf(argv[3],”%i”,&tosval)))!=1){
uso();
exit(1);
}
printf(“il client è pronto!\n\n”);
/* riempimento della struttura serv_addr */
bzero((char*)&serv_addr,sizeof(serv_addr));
serv_addr.sin_family=AF_INET;
serv_addr.sin_addr.s_addr=inet_addr(target);
serv_addr.sin_port=htons(port_num);
/* apertura di una socket TCP (SOCKET STREAM) */
if((sockfd=socket(AF_INET,SOCK_STREAM,0))<0)
perror(“client: impossibile aprire la socket di stream\n”);
/* connessione al server */
if(connect(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr))<0){
perror(“client: impossibile connettersi al server\n”);
exit(1);
}
179
Configurazione di nodi wireless con supporto della qualità del servizio
/* costruzione del pacchetto */
servlen=sizeof(serv_addr);
memset(pacch,35,dimpack);
/* settaggio del tos */
if((setsockopt(sockfd,IPPROTO_IP,IP_TOS,&tosval,optlen))<0){
perror(“errore nel settaggio del tos: “);
exit(0);
}
else{
/* inizio invio pacchetti */
for(iter=1;iter<=numpack;iter++){
if((num=sendto(sockfd,pacch,dimpack,0,(struct
sockaddr*)&serv_addr,sizeof(serv_addr)))<0){
perror(“errore nella write\n”);
exit(0);
} /* END if */
} /* END for */
} /* END else */
/* decommentare nel caso si voglia anche la ricezione di un ack
if((nbytes=recv(sockfd,ack,sizeof(ack),0))<0){
perror(“socket red failed\n”);
exit(0);
} */
}/*END main*/
/* prototipo di
void uso(){
printf(“Uso:
printf(“
printf(“
printf(“
}
comando da dare da terminale */
client ip_dot_address port_number tosval\n”);
ip_dot_address : indirizzo IP del server\n”);
port_num : numbero del porto server\n”);
tosval: valore del tos \n”);
A.3 Codice della libreria di servizio
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
<arpa/inet.h>
<sys/time.h>
<sys/types.h>
<sys/param.h>
<sys/socket.h>
<sys/signal.h>
<stropts.h>
<netinet/in_systm.h>
<netinet/in.h>
<netinet/ip.h>
<unistd.h>
<stdio.h>
<ctype.h>
<errno.h>
180
Configurazione di nodi wireless con supporto della qualità del servizio
#include <string.h>
#include <malloc.h>
/* definizioni comuni per client-server */
#define dimpack 1200
/* dimensione del messaggio */
#define numpack 15000
/* numero di pacchetti inviati */
char ack[]=“ack”;
/* buffer per l’invio di ack */
int port_num;
/* porto del server */
int nbytes,totalnbytes,num;
/* bytes trasmessi e ricevuti */
char pacch[dimpack];
/* puntatore buffer di ricezione */
/* strutture per gli indirizzi */
struct sockaddr_in serv_addr,cli_addr;
struct sockaddr
*ptrcli_addr;
A.4 Il Makefile
CFLAGS= -lnsl
CC=g++
PROGS= clean client server
all:$(PROGS)
client: client.c
$(CC) -o client client.c $(CFLAGS)
server: server.c
$(CC) -o server server.c $(CFLAGS)
clean:
rm -f $(PROGS) *.o core *.core *.bak
181
Configurazione di nodi wireless con supporto della qualità del servizio
Appendice B
How-to di installazione
La macchina sulla quale è stato testato il sistema HostQs ha le seguenti
caratteristiche:
•
Pentium III 650 MHz;
•
256 Mbyte Ram;
•
3 Gbyte HDD (per la partizione utilizzata);
•
scheda wireless Compaq WL100;
•
sistema operativo Linux, versione del kernel 2.4.26, distribuzione Debian.
B.1 Installazione del sistema base
Il primo passo da eseguire dopo aver installato il sistema operativo di base è
caricare una serie di pacchetti necessari al funzionamento dell’Access Point.
Per questo motivo aggiornare il file /etc/apt/sources.list e selezionare
uno o più mirror attraverso i quali sia possibile scaricare le ultime versioni dei
prodotti software desiderati. Di seguito si riportano i mirror della macchina test:
deb http://debian.fastweb.it/debian stable main contrib non-free
182
Configurazione di nodi wireless con supporto della qualità del servizio
deb http://debian.fastweb.it/debian-non-US stable/non-US main contrib
non-free
Utilizzare quindi il comando apt-get per installare i seguenti pacchetti:
apt-get install wireless-tools
apt-get install iptables
apt-get install dhcpd
B.2 Compilazione del kernel
Si è pronti ora per ricompilare un nuovo kernel; si consigli di utilizzare una
versione stabile, preferibilmente 2.4.24 o 2.4.26:
make mrproper
make dep
make menuconfig (o make xconfig per la versione grafica)
e impostare le seguenti configurazioni:
Code maturity level options
[*] Prompt for development and/or incomplete code/drivers
183
Configurazione di nodi wireless con supporto della qualità del servizio
Processor type and features
(Pentium-MMX) Processor family
General setup
PCMCIA/CardBus support --->
<*> PCMCIA/CardBus support
[*] CardBus support
Networking options
<*> Packet socket
[*] Network packet filtering
[*] Socket Filtering
[*] TCP/IP Networking
[*] IP: multicasting
[*] IP: advanced router
quindi attivare tutte le sotto-opzioni
<*> IP: tunneling
All’interno di: Netfilter Configuration
Attivare tutte le opzioni come modulo
<*> 802.1d Ethernet Bridging --> bridge-utils
Network device support
<*> Universal TUN/TAP device driver support
<*> Ethertap network tap (OBSOLETE) (NEW)
Ethernet (10 or 100Mbit)
attivare l’opzione relativa alla propria scheda ethernet
184
Configurazione di nodi wireless con supporto della qualità del servizio
Wireless LAN (non-hamradio)
[*] Wireless LAN (non-hamradio)
salvare le impostazioni, uscire e continuare:
make dep
make clean
make bzImage
make modules
make modules_install
cp –i /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.26
cp –i /usr/src/linux/System.map /boot/System.map-2.4.26
rm /vmlinuz
ln –s /boot/vmlinuz-2.4.20 /vmlinuz
quindi editare il file lilo.conf e lanciare:
lilo –t
e sperando che il tutto sia andato a buon fine, eseguire
finalmente:
185
Configurazione di nodi wireless con supporto della qualità del servizio
lilo
reboot
B.3 Installazione di HostAP e HostQs
Adesso il sistema è pronto per l’installazione di HostAP
file queue_mgr-0.16.7
9
8
e HostQs: scaricare il
o se possibile la versione più aggiornata e seguire le
istruzioni di installazione consigliate dal file README di cui si riportano
brevemente i passi principali:
•
decompattare la cartella di HostAP:
tar -xzf hostap-driver-0.2.0.tar.gz
•
patchare l’HostAP per farlo funzionare con il supporto della qualità del
servizio:
patch -p0 <hostap-add-queue_mgr-support.patch
8
9
http://hostap.epitest.fi/
da http://www.inlab.csp.it/tools/wireless/hostqs/
186
Configurazione di nodi wireless con supporto della qualità del servizio
•
selezionare la cartella e installare HostAP:
cd hostap-driver-0.2.0
make pccard
make install_pccard
•
a questo punto ritornare nella cartella precedente e installare HostQs:
cd..
make
make install
B.4 Configurazione delle interfacce
Editare il file /etc/network/interfaces nel seguente modo:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto wlan0
187
Configurazione di nodi wireless con supporto della qualità del servizio
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
Una volta cambiato il file, riavviare i servizi wireless:
/etc/init.d/networking restart
Adesso si possono controllare le impostazioni con i comandi ifconfig e
iwconfig che restituiscono i seguenti output rispettivamente:
wifi0
Link encap:UNSPEC
HWaddr 00-50-8B-99-B7-FF
UP BROADCAST RUNNING MULTICAST
MTU:1500
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b)
TX bytes:0 (0.0 b)
Interrupt:5 Base address:0x100
wlan0
Link encap:Ethernet
HWaddr 00:50:8B:99:B7:FF
inet addr:192.168.1.0 Bcast:192.168.1.255
UP BROADCAST RUNNING MULTICAST
MTU:1500
Mask:255.255.255.0
Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
188
Configurazione di nodi wireless con supporto della qualità del servizio
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b)
TX bytes:0 (0.0 b)
Interrupt:5 Base address:0x100
e
wlan0
IEEE 802.11b
ESSID:”test”
Mode:Master Frequency:2.422GHz
Bit Rate:11Mb/s
Access Point: 00:50:8B:99:B7:FF
Tx-Power:11 dBm
Retry min limit:8
RTS thr:off
Sensitivity=1/0
Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0
Signal level:0
Rx invalid nwid:0
Noise level:0
Rx invalid crypt:0
Tx excessive retries:0
Rx invalid frag:0
Invalid misc:284
Missed beacon:0
B.5 Impostazione del DHCP
Finalmente l’Access Point è perfettamente funzionante ma non permette ancora
la condivisione della connessione: tutto ciò che rimane da fare è configurare il
DHCP editando il file /etc/dhcpd.conf nel seguente modo:
#ddns-update-style none;
subnet 192.168.1.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
189
Configurazione di nodi wireless con supporto della qualità del servizio
option domain-name-servers 217.9.64.220, 217.9.64.3, 217.9.64.71;
option domain-name “napoli.consorzio-cini.it”;
host hostqs {
range 192.168.1.1 192.168.1.254;
}
E quindi rilanciare il servizio DHCP:
/etc/init.d/dhcp restart
B.6 Impostazione del NAT
Il NAT (Network Address Translation) verrà realizzato utilizzando le iptables:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
a questo punto dovrebbe essere possibile un ping a un qualunque sito web.
Così impostate, le funzioni delle iptables non si conservano e per renderle
definitivamente operative si crea uno script nel seguente modo:
190
Configurazione di nodi wireless con supporto della qualità del servizio
vi /etc/init.d/iptables-rules
e all’interno del relativo file si editano le seguenti linee:
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Quindi per rendere questo script automaticamente eseguibile all’avvio e per
dargli tutti i permessi di cui ha bisogno:
cp iptables-rules /etc/init.d/
update-rc.d iptables-rules defaults
chmod 775 /etc/init.d/ iptables-rules
191
Configurazione di nodi wireless con supporto della qualità del servizio
Bibliografia
[1] R. Braden, D. Clark, S. Shenker, “Integrated Services in the Internet
Atchitecture: an Overview”, RFC1633, Giugno 1994
[2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource Reservation
Protocol”. RFC2205, Settembre 1997
[3] S. Shenker, J. Wroclawsky, “General Characterization Parametres for
Integrated Service Network Elements” RFC2215, Settembre 1997
[4] D. Hoffman, “Implementation Report on the LBL/UCL/Sun CBQ kernel”,
Presentation to the RSVP Working Group of the IETF, Luglio 1994
[5] J. Wroclawski, “Specification of the Controlled-Load Network Element
Service”, RFC 2211, Settembre 1997
[6] S. Shenker, C. Partridge and R. Guerin, “Specification of Guaranteed Quality
of Service”, RFC2212, Settembre 1997
[7] Y. Bernet, R. Yavaktar, P. Ford, F. Baker, L. Zhang, K. Nichols, M. Speer, “A
Framework for use of RSVP with DiffServ Networks”, Internet drafts, IETF,
Novembre 1998, draft-ietf-diffserv-rsvp-01.txt
[8] S. Shenken, C. Patridge, R. Guerin, “Specification of Garanteed Quality of
Service”, Technical Report rfc2212, Settembre 1997
[9] S.P. Romano, J.F. de Rezende, C. Deleuze, S. Fdida, “Integrated QoS
Architecture for IP Switching” in proc. of 7th Workshop of High Speed Networks
(HSH’97), Stoccarda (D), Ottobre 1997
192
Configurazione di nodi wireless con supporto della qualità del servizio
[10] S. Blanke, D. Blanck, M. Clarlson, E. Davies. Z. Wang. W. Weiss, “An
Architecture of Differentiated Service”, RFC2475, Dicembre 1998
[11] Y. Bernet, J. BInder, S. Blanke, M. Carlson, S. Keshav, E.Davies, B.
Ohlman, D. Verma, W. Weiss, “A Framework for Differentiated Services”,
Internet drafts, Differentiated Service, Ottobre 1998, drafts-ietf-diffservframework-01.txt
[12] K. Nahrstedt, J. Smith, “A Service Kernel in Multimedia End-Stations”,
Distributed System Lab, University of Pennsylvania, 1998
[13] S. Quarterman, M.J. Karels, K. Bostic, M.K. McKusick, “The Design and
Implementation of the 4.4BSD Operating System”, Addision-Wesley Publishing
Company, Inc., 1996
[14] H. Frank Cervone, “SOLARIS Performance Administration”, McGraw Hill,
1998
[15] K. Wall, M. Watson, M. Whitis, “Linux Programming Unleashed”, Macmillan
Computing Publishinh, 1999
[16] S. Mangold, S. Choi, P. May, O. Klein, G. Hiertz, L. Stibor, “IEEE 802.11e
Wireless LAN for Quality of Service”
[17] S. Park, D. Kim, K. Kim, S. Choi, S. Hong, “ Collaborative QoS Architecture
between DiffServ and 802.11e Wireless LAN. In IEEE VTC’03-Spring, 2003”
[18] D. Gu, J. Zhang, “QoS Enhancement in IEEE802.11 Wireless Local Area
Networks” IEEE Communications Magazine, 2003.
[19] Project IST 1999-10469 SUITED, Deliverable D4, “Mobility Management
Specification Document”
[20] V. Marziale, P. Conforto, G. Lo Squadro, F. Delli Priscoli, “Inter-Segment
Handover (ISHO) in a integrated terrestrial-satelite mobile communication
sysyem: scenario and proposal”
[21] Floyd Wilder, “A guide to the TCP/IP Protocol suite”, Wilder
[22] O. Kolesnikov, R. Kurane, “Mobile IP”, Giugno 2000
193
Configurazione di nodi wireless con supporto della qualità del servizio
[23] C. Perkins, RFC 2002: IP Mobility Support, Ottobre 1996
[24] Andrew S. Tanenbaum, “Comuter Networks”, Prentice Hall
[25] Fumio Teraoka, Yasuhiko Yokote, Mario Tokoro, “A Network Architecture
Providing Host Migration Transparency, “ Proc. ACM SIGCOMM’91, pp. 209-220,
Settembre 1991
[26] John Ioannidis, Dan Duchamp, Gerald Q. Maguire Jr, “IP-Based Protocols
for Mobile Interworking,” Proc ACM SIGCOMM’91, pp. 235-245, Settembre 1991
[27] Charles Perkins, Andrew Myles, David B. Johnson, “IHMP: A Mobile Host
Protocol for the Internet,” Computer Networks and ISDN Systems, 27(3),
Dicembre 1994
[28] Ramon Caceres, Venkata N. Padmanabhan, “Fast and Scalable Handoffs
for Wireless Internetworks,” Proc. ACM Conference on Mobile Computing and
Networking (Mobicom’96), pp. 56-66, 1996
[29] Andrew Myles, David Skellern, “Comparing Four IP Based Mobile Host
Protocols,” Computer Networks and ISDN Systems, pp. 349-356, Novembre
1993
[30] Pravin Bhagwat, Charles Perkins, Satish Tripathi, “Network Layer Mobility:
an Architecture and Survey,” IEEE Personal Communications Magazine, Vol. 3,
No. 3, pp. 54-64, Giugno 1996
[31] Charles Perkins, editor, “IP Mobility Support,” Internet RFC 2002, Ottobre
1996
[32] David B. Johnson, Charles Perkins, “Route Optimization in Mobile IP,”
Internet Draft, draft-ietf-mobileip-optim-07.txt, Novembre 1998, Work in
Progress
[33] David B. Johnson, Charles Perkins, “Mobility Support in IPv6,” Internet
Draft, draft-ietf-mobileipipv6-07.txt, Novembre 1998, Work in Progress
[34] M. Mouly, M-B. Pautet, “The GSM System for Mobile Communications”,
ISBN 2-9507190-0-7, 1992
194
Configurazione di nodi wireless con supporto della qualità del servizio
[35] IEEE 802.11 WG, Supplemento alla Parte II dedicata al livello Wireless
Medium Access Control (MAC) e al livello Fisico (PHY) Specifications: MAC
Enhancements for Quality of Service, IEEE 802.11e Draft 5.0, Luglio 2003
[36] G. Bianchi, I. Tinnirello, “Analysis of Priority Mechanisms Based on
Differentiated Inter Frame Spacing in CSMA-CA,” IEEE VTC-Fall, Orlando, FL,
Ottobre 2003
[37] S. Mangold, S. Choi, G. R. Hiertz, O. Klein, B. Walke, “Analysis of IEEE
802.11e for QoS Support in Wireless LANs,” IEEE Wireless Communications
Mag., Dicembre 2003, pp. 40–50.
[38] A. Grilo, M. Nunes, “Performance evaluation of IEEE 802.11e,” IEEE
PIMRC’02, Lisboa, Portugal, Settembre 2002
[39] S. Choi, J. del Prado, S. Shankar N, S. Mangold, “IEEE 802.11e ContentionBased Channel Access (EDCF) Performance Evaluation,” IEEE ICC 2003,
Anchorage, Alaska, Maggio 2003
[40] A. Lindgren, A. Almquist, O. Schel´en, “Quality of Service Schemes for
IEEE 802.11 Wireless LANs - An Evaluation,” MONET, Special Issue on
Performance Evaluation of Qos Architectures in Mobile Networks, Vol 8, No 3,
Giugno 2003, pp. 223–35.
[41] http://hostap.epitest.fi/
[42] http://www.inlab.csp.it/tools/wireless/hostqs/
[43] http://streaming.polito.it/fenice.shtml
[44] ITU-T Recommendation P.862
195