Gestione della mobilità in ambiente misto Internet

Transcript

Università degli studi Roma Tre
Facoltà di Ingegneria Elettronica
Anno Accademico 2001/2002
“Gestione della mobilità in ambiente misto
Internet-WLAN-UMTS”
Mauro Cerboni
Relatore:
Ch.mo Prof. A. Neri
Co-Relatore:
Ing. G. Cinque
(ELIS Lab – Consorzio ELIS)
2° Relatore:
Ch.mo Prof. P. Di Rosa
Ai miei genitori
Indice
Indice
Capitolo 1 - Introduzione ........................................................................................ 2
Capitolo 2 – Stato dell’arte UMTS, WLAN e mobilità in IPv6 ........................... 5
2.1 – UMTS: mobilità totale .................................................................................. 6
2.1.1 – Tecnologia UMTS.................................................................................. 7
2.1.2 – Gestione della mobilità in UMTS ........................................................ 14
2.1.3 – Limiti di UMTS.................................................................................... 16
2.2 – WLAN: nomadismo a larga banda ............................................................. 17
2.2.1 – IEEE 802.11 ......................................................................................... 18
2.2.1.1 – Architettura IEEE 802.11 ......................................................................................19
2.2.1.2 – Lo standard IEEE 802.11 ......................................................................................21
2.2.1.3 – Power Management...............................................................................................23
2.2.1.4 – Autenticazione e sicurezza ....................................................................................23
2.2.1.5 – IEEE 802.11b ........................................................................................................25
2.2.1.6 - IEEE 802.11a ........................................................................................................26
2.2.1.7 – IEEE 802.11g ........................................................................................................26
2.2.1.8 - QoS in 802.11 ........................................................................................................27
2.2.1.9 – Cenni su altri standard WLAN ..............................................................................27
2.2.2 – Gestione della mobilità in 802.11b ...................................................... 29
2.2.3 – Limiti di WLAN................................................................................... 31
2.3 – Mobilità in IPv6 .......................................................................................... 33
2.3.1 – Gestione della macromobilità .............................................................. 34
2.3.1.1 – Differenze tra Mobile IPv4 e Mobile IPv6 ............................................................38
2.3.1.2 - Il Nodo Mobile ed i suoi indirizzi ..........................................................................39
2.3.1.3 – Strutture dati degli Host. .......................................................................................42
2.3.1.4 – Extension Header ed Opzioni di Binding. .............................................................44
2.3.1.5 – Ingress Filtering ed Home Address Destination Option........................................48
2.3.1.6 – Compiti dell'Home Agent......................................................................................48
2.3.1.7 – Dynamic Home Agent Address Discovery............................................................49
2.3.1.8 – Ricezione di pacchetti da un Nodo Mobile............................................................50
Mauro Cerboni - Gestione della mobilità in ambiente misto Internet-WLAN-UMTS
I
Indice
2.3.1.9 – Invio di un pacchetto ad un Nodo Mobile. ............................................................50
2.3.1.10 – Invio di pacchetti da un Nodo Mobile. ................................................................52
2.3.1.11 – Rilevazione del movimento.................................................................................53
2.3.1.12 – Formazione ed uso del Care of Address. .............................................................54
2.3.1.13 – Ritorno a casa. .....................................................................................................56
2.3.1.14 – Interazione con Outbound IPsec Processing........................................................57
2.3.2 – Gestione della micromobilità ............................................................... 58
2.3.2.1 – Hierarchical Mobile IPv6 ......................................................................................58
2.3.2.2 – Fast Handover Mobile IPv6...................................................................................59
Capitolo 3 – Integrazione WLAN-UMTS ............................................................ 60
3.1 – I vantaggi di una soluzione integrata .......................................................... 61
3.1.1 – Sinergia per WLAN ............................................................................. 62
3.1.2 – Sinergia per UMTS .............................................................................. 63
3.2 – Verso una rete All-IP .................................................................................. 65
3.2.1 – Il 3.5G .................................................................................................. 65
3.3 – Modelli di integrazione ............................................................................... 66
3.3.1 - Loose Interworking (No Interworking) ................................................ 70
3.3.2 – Loose Interworking (Mobile IP) .......................................................... 71
3.3.3 - Tight Interworking................................................................................ 73
3.4 – Security, Authentication, Authorization, Accounting (AAA)
nelle reti integrate WLAN-UMTS ............................................................... 75
3.4.1 – Insecurity nelle Wireless LAN............................................................. 76
3.4.1.1 – Sniffing..................................................................................................................76
3.4.1.2 – Furto di risorse ......................................................................................................76
3.4.1.3 – Ridirezione del traffico..........................................................................................77
3.4.1.4 – Negazione del servizio ..........................................................................................77
3.4.1.5 – Reti fasulle e ridirezione della stazione.................................................................77
3.4.2 – Strumenti standard 802.11 per il controllo d’accesso .......................... 78
3.4.2.1 – SSID (Service Set Identifier).................................................................................78
3.4.2.2 – Filtri sul MAC Address .........................................................................................78
3.4.2.3 – Chiavi statiche WEP..............................................................................................78
3.4.3 – Strumenti non-standard 802.11 per il controllo d’accesso................... 79
3.4.3.1 – IEEE 802.11i .........................................................................................................79
3.4.3.2 – Wireless Protected Access (WPA) ........................................................................80
3.4.3.2.1 IEEE 802.1x – Scambio dinamico della chiave................................................82
II
Indice
3.4.3.2.1.1 – Nomenclatura.........................................................................................82
3.4.3.2.1.2 – Extensible Authentication Protocol (EAP) ............................................83
3.4.3.2.1.3 – Extensible Authentication Protocol Over LAN (EAPOL) .....................83
3.4.3.2.1.4 – RADIUS ................................................................................................83
3.4.3.2.1.5 – Architettura di autenticazione di 802.1x ................................................84
3.4.3.2.1.6 - 802.1x nelle Wireless LAN 802.11 .......................................................84
3.4.3.2.2 – TKIP ..............................................................................................................88
3.4.3.3 – Virtual Private Networks (VPN) ...........................................................................88
3.4.4 – Architettura per il controllo d’accesso alla rete
integrata WLAN-UMTS ..................................................................... 90
3.4.4.1 – Architettura WLAN dell’operatore mobile ...........................................................92
Capitolo 4 – Prove sperimentali di mobilità con Mobile IPv6 ........................... 96
4.1 – Testbed WLAN ........................................................................................... 97
4.1.1 – Prove di throughput.............................................................................. 98
4.1.2 – Prove di handover L2 ........................................................................... 99
4.1.3 – Prove di handover L3 ......................................................................... 101
4.2 – Testbed WLAN integrato Roma-Strasburgo ............................................ 105
4.3 – Testbed integrato WLAN-GPRS .............................................................. 111
4.4 – Testbed integrato WLAN-GPRS Roma-Strasburgo ................................. 116
4.4.1 - Prove di handover L3.......................................................................... 117
4.5 – Prestazioni limite di Mobile IPv6 ............................................................. 119
Capitolo 5 – Conclusioni e sviluppi futuri ......................................................... 121
5.1 - Conclusioni ................................................................................................ 122
5.2 – Sviluppi futuri ........................................................................................... 124
Appendice A – Procedure di installazione e configurazione
Testbed Mobile IPv6 ................................................................. 125
A.1 – Procedure d’installazione Mobile IPv6................................................... 126
A.1.1 - Installazione del modulo Mobile IPv6............................................... 126
A.1.2 - Configurazione di un Nodo Mobile................................................... 128
III
Indice
A.1.3 - Configurazione di un Home Agent .................................................... 129
A.1.4 - Configurazione di un Correspondent Node ....................................... 132
A.1.5 – Creazione di un tunnel GRE IPv6 in IPv4 ........................................ 133
A.2 – Procedura di installazione e configurazione scheda GPRS Nokia D211 134
A.2.1 – Script di configurazione della scheda e attivazione del GPRS ......... 135
A.2.2 – Script di configurazione per l’attivazione del tunnel sulla
connessione PPP0 ............................................................................. 135
A.2.3 – Parti essenziali del file /root/GPRS/wvdial.conf............................... 136
Ringraziamenti ................................................................................................... 138
Abbreviazioni..................................................................................................... 139
Bibliografia ........................................................................................................ 141
IV
Gestione della mobilità in ambiente misto
Internet-WLAN-UMTS
Capitolo 1 - Introduzione
Capitolo 1
Introduzione
2
L’accesso ubiquitario ai dati e agli strumenti dell’ufficio è una delle più importanti
conquiste dei professionisti di oggi. La maggior parte delle informazioni e dei
sistemi aziendali sono raggiungibili da ogni parte del mondo attraverso le reti
Internet IP. Gli utenti mobili hanno bisogno di una rete di accesso pubblico
efficiente in termini di banda che dia la possibilità di accedere alle risorse remote
senza soluzione di continuità nel tempo e nello spazio.
La larga banda richiesta da applicazioni come l’uso remoto del desktop di un PC, il
download di grossi allegati nella e-mail, oppure applicazioni multimediali, il
broadcast televisivo, spesso supera la capacità di trasmissione delle moderne reti
cellulari. La tecnologia di accesso radio delle reti wireless locali (WLAN), fornisce
una larghezza di banda superiore a qualsiasi rete cellulare.
Le reti WLAN standard IEEE 802.11b offrono una throughput di 11Mbps nella
banda di 2,4 GHz e già sono stati definiti nuovi standards a 54 Mbps denominati
IEEE 802.11a e g. Il data rate massimo di un singolo utente in una rete pubblica
WLAN è 11Mbps (tipicamente 6.5 Mbps), mentre un terminale General Radio
Racket Service (GPRS), offre un data rate fino a 172 kbps (tipicamente 32 kbps), un
terminale di terza generazione arriva fino a 2 Mbps (tipicamente 144 kbps).
Dal punto di vista dell’utente finale la differenza è notevole, il che rende WLAN
una tecnologia complementare alla rete cellulare negli spazi indoor. Anche la rapida
penetrazione nel mercato dei terminali WLAN, ed il loro basso costo, rappresenta
un’interessante opportunità di business per gli operatori mobili che intendono
allargare il loro portafoglio servizi coprendo anche l’accesso WLAN. Oggi ci sono
oltre 90 milioni di possessori di laptop computer nel mondo, dei quali circa la metà
sono anche utenti della rete GSM/GPRS. WLAN può completare l’offerta 2,5/3G
degli operatori mobili, fornendo una soluzione economica e a larga banda per gli
spazi indoor. I luoghi ideali candidati all’installazione di punti di accesso Wireless
3
LAN sono aeroporti, treni e stazioni ferroviarie, hotel, autogrill, centri direzionali e
fiere.
Le problematiche chiave dell’integrazione riguardano principalmente la gestione
della mobilità e del roaming tra le reti eterogenee sia per gli aspetti relativi
all’autenticazione autorizzazione e accounting, sia per quanto riguarda l’handover
verticale, e cioè il passaggio tra rete cellulare e WLAN e viceversa.
In questo lavoro di tesi verranno affrontate queste problematiche, con maggior
riferimento a quella dell’handover verticale tra le reti WLAN ed UMTS/GPRS.
Nel capitolo 2 analizzerò lo stato dell’arte delle tecnologie WLAN ed UMTS, con
particolare riferimento alla gestione della mobilità; in questo capitolo analizzerò
anche i protocolli di gestione della mobilità tra reti IP ed in particolare Mobile IPv6.
Nel capitolo 3 verrà approfondito il concetto di integrazione evidenziandone i
vantaggi per gli operatori cellulari e WLAN; verranno quindi presentati i vari
scenari, le varie modalità di integrazione e le problematiche di sicurezza ed
autenticazione in WLAN per un’architettura di rete integrata.
Nel capitolo 4 verrà analizzato in via sperimentale il problema dell’handover tra reti
di accesso differenti; tale problema trova una soluzione con il supporto del
protocollo Mobile IPv6. Verranno presentati i diversi testbed da me progettati ed
implementati al fine di testare l’efficienza e le prestazioni di Mobile IPv6: un
testbed WLAN, un testbed WLAN integrato con l’Università di Strasburgo, un
testbed WLAN-GPRS ed infine un testbed WLAN-GPRS con agenti Mobile IPv6 a
distanza. Per ognuno di questi testbed presenterò le prove sperimentali effettuate ed
i relativi risultati.
Nel capitolo 5 verranno analizzate le conclusioni alle quali sono giunto sulla base
dei risultati sperimentali ottenuti; presenterò anche una linea guida per lo sviluppo
futuro del presente lavoro di tesi.
Per concludere nell’Appendice A ho riportato le principali procedure di
installazione
e
configurazione
dei
vari
testbed
Mobile
IPv6.
4
Capitolo 2 – Stato dell’arte UMTS, WLAN e mobilità in IPv6
Capitolo 2
Stato dell’arte UMTS, WLAN e mobilità in IPv6
5
2.1 – UMTS: mobilità totale
Nel corso degli ultimi anni l’enorme diffusione
della telefonia mobile e della trasmissione di dati
tramite Internet sono stati i fenomeni di maggior
rilievo nel mondo delle telecomunicazioni.
Numerose ricerche di mercato indicano che il
tasso di crescita di questi due sistemi di
comunicazione
continuerà
ad
aumentare
notevolmente anche nei prossimi anni.
Figura 2.1 – Telefono cellulare UMTS
Seguendo queste chiare indicazioni lo sviluppo tecnologico si è diretto verso un
sistema che potesse conciliare la mobilità dell’utente con la crescente esigenza di
comunicazione multimediale.
Fu così che l’ITU (International Telecommunication Union) avviò il processo di
standardizzazione FPLMTS (Future Public Land Mobile Telecommunication
System),
rinominato
nel
1997
IMT-2000
(International
Mobile
Telecommunications-2000), al fine di definire uno standard completo per la
telefonia mobile di terza generazione.
In Europa l’ETSI (European Telecommunications Standard Institute) ha definito
l’UMTS (Universal Mobile Telecommunications System) operando sulla base
delle indicazione dell’ITU. Sebbene lo scopo dell’ITU fosse stato quello di definire
uno standard di sistema di terza generazione unico a livello mondiale, la presenza di
molte parti in gioco, con interessi anche molto differenti tra loro, ha reso
impossibile raggiungere pienamente questo obiettivo: IMT-2000 è costituito da una
famiglia di sistemi (UMTS per l’Europa) caratterizzati da un buon grado di
6
compatibilità, ed idonei ad assicurare il roaming mondiale attraverso terminali
multimodo.
Il sistema UMTS è progettato in modo altamente flessibile, per fornire un’ampia
gamma di applicazioni in una molteplicità di ambienti e, più in generale, per
estendere all’utenza mobile gran parte dei servizi offerti all’utenza fissa.
2.1.1 – Tecnologia UMTS
La WARC (World Administrative Radio Conference), responsabile mondiale
dell’assegnazione delle frequenze radio, ha assegnato ai sistemi di terza generazione
una banda compresa tra 1885-2025 MHz e 2110-2200 MHz. In Europa i primi 15
MHz della banda coincidono con parte della banda attualmente utilizzata dal
sistema DECT. La parte restante dello spettro relativa al segmento terrestre è stata
suddivisa in parte appaiata (60+60 MHZ, da 1920 a 1980 MHz in up-link e da 2110
a 2170 MHz in down-link), dove cioè c’è simmetria tra la tratta in salita e quella in
discesa, e in parte non appaiata (35 MHz, da 1900 a 1920 MHz e da 2010 a 2025
MHz), dove non c’è una distinzione a priori tra le porzioni assegnate all’up e al
down-link rispettivamente. Questo fa si che in Europa la banda disponibile per la
componente terrestre dei sistemi mobili di terza generazione sia pari a 155 MHz. Le
bande appaiate 1980-2010 MHz e 2170-2200 MHz sono state assegnate al
segmento satellitare per la Regione 1 (MSS).
La necessità di dover fornire un’ampia gamma di servizi ha portato a definire dei
requisiti di ritmo binario, variabili a seconda dell’ambiente di servizio e delle
caratteristiche di mobilità:
-
ambiente indoor: fino a 2 Mbit/s
-
ambiente outdoor pedonale (fino a 10 km/h): fino a 144 kbit/s
-
ambiente outdoor veicolare (fino a 200 km/h): fino a 64 kbit/s
7
Per quanto riguarda la tecnica di accesso radio per l’UMTS, nel 1998 l’ETSI
propose una soluzione identificata come UTRA (UMTS Terrestrial Radio Access):
-
nelle bande appaiate (con duplexing FDD) il sistema adotta la tecnica di
accesso W-CDMA (Wideband-Code Division Multiple Access)
-
nelle bande non appaiate (con duplexing TDD) il sistema adotta la tecnica di
accesso TD-CDMA (Time Division-Code Division Multiple Access)
La tecnica CDMA si differenzia dalle precedenti tecniche di accesso multiplo
perché permette agli utenti di trasmettere alla stessa frequenza e nello stesso istante.
La separazione dei vari utenti è ottenuta assegnando a ciascun utente un “codice”
diverso: tale codice, tramite un’operazione detta di spreading, viene utilizzato per
codificare in modo univoco l’informazione d’utente da trasmettere, in modo da
poterla distinguere da quella degli altri utenti. L’operazione di spreading prevede
che a ciascun segnale da trasmettere sul canale radio sia associata, con
un’operazione di moltiplicazione, una sequenza numerica (codice) con velocità di
trasmissione (chip rate) molto maggiore della velocità dell’informazione da
trasmettere. I bit ottenuti dopo questa operazione sono detti chip. Le sequenze di
codice assegnate agli utenti che condividono lo stesso canale sono tra loro diverse e
sono scelte in modo che siano poco correlate tra loro; ciò fa sì che, in condizioni
ideali, l’operazione duale (despreading) effettuata in ricezione annulli l’effetto delle
interferenze mutue e consenta di estrarre il segnale desiderato.
In un sistema CDMA il numero di utenti che è possibile servire non è determinato a
priori (numero di portanti o numero di time-slot) come nei sistemi di prima e
seconda generazione; ogni qual volta viene servito un nuovo utente, la qualità di
tutti gli utenti presenti nel sistema è degradata leggermente (soft degradation). E’
quindi possibile servire nuovi utenti fino a quando il livello dell’interferenza sarà
tale da non garantire più il requisito di qualità desiderato.
L’architettura di rete UMTS può essere suddivisa in due parti principali:
-
l’interfaccia radio UTRAN (UTRA Network), definita dal 3GPP (3rd
Generation Partnership Project) da parte del comitato tecnico RAN [3].
8
-
l’infrastruttura di commutazione e routing o Core Network (CN), suddivisa
a sua volta in CN a commutazione di circuito (CS – Circuit Switched) e CN
a commutazione di pacchetto (PS – Packet Switched).
Questa tabella riassume le principali caratteristiche dell’interfaccia radio:
Tecnica di accesso
UTRA-FDD
UTRA-TDD
W-CDMA
TD-CDMA
Chip rate
3.84 Mchip/s
Canalizzazione
4.4 - 5 MHz
Durata di trama
10 ms
15
Numero di slot per trama
Tecnica di modulazione
Down-link: QPSK
QPSK
up-link: dual-code BPSK
Velocità di trasmissione
dell’informazione
Variabile (ogni 10ms)
Velocità diverse possono essere ottenute variando lo
spreading factor, oppure assegnando più codici al
segnale da trasmettere, oppure (solo nel caso TDD)
affasciando più time-slot
L’UTRAN è costituito da un insieme di Radio Network Subsystem (RNS), connessi
alla CN tramite l’interfaccia Iu. Ogni RNS è composto da un controllore (RNC –
Radio Network Controller) e da uno o più Node B, connessi all’RNC tramite
l’interfaccia Iub. Ogni Node B sovrintende ad un’insieme di celle. Gli RNC
possono essere collegati tra loro tramite l’interfaccia Iur.
9
Figura 2.2 – Architettura di rete UMTS [1]
Il Core Network UMTS consiste di due domini di rete separati: quello a
commutazione di circuito e quello a commutazione di pacchetto. Il primo, derivato
dal GSM, trasporta il traffico voce, mentre il secondo, ereditato dal GPRS, trasporta
il traffico dati. Questi due domini sono collegati all’UTRAN tramite le due
interfacce IuCS e IuPS.
Qui di seguito vengono presentati i vari apparati di rete del Core Network:
-
MSC (Mobile Switching Center): controlla la segnalazione delle chiamate e
coordina le procedure di handover.
-
VLR (Visitor Location Register): gestisce informazioni dettagliate sulla
posizione del terminale, mantenendo traccia dei suoi spostamenti a livello di
Location Area; memorizza localmente i parametri di autenticazione ed
identificazione. Si trova solitamente in un unico apparato integrato con
l’MSC.
-
HLR (Home Location Register): contiene ed aggiorna le informazioni
relative alla posizione dei terminali mobili in termini di
area VLR;
memorizza le informazioni relative ai profili d’utente e di parametri di
autenticazione ed identificazione.
-
SGSN (Serving GPRS Support Node): è connesso alla rete di accesso e
serve il terminale mobile conservando le informazioni di posizione ed
10
eseguendo funzioni relative alla sicurezza della comunicazione e al controllo
di accesso.
-
GGSN (Gateway GPRS Support Node): opera come unità di interlavoro
verso le reti esterne a commutazione di pacchetto; è collegato all’SGSN
tramite una rete di trasporto basata su IP.
In un progetto di integrazione UMTS-WLAN, la parte del Core Network a
commutazione di pacchetto riveste un’importanza primaria. Analizziamo quindi con
maggior dettaglio le procedure che intervengono a gestire il trasferimento dati in un
sistema di terza generazione.
La procedura di GPRS Attach [5] serve a far conoscere alla rete la presenza del
terminale; terminata la registrazione del terminale, la rete conosce la sua posizione a
livello di Routing Area e le sue caratteristiche di servizio; questa procedura si
compone dei seguenti passi:
-
il terminale mobile attiva una richiesta di Attach all’SGSN indicando: la sua
capacità di gestire velocità di trasmissione elevate, l’algoritmo di cifratura
utilizzato ed il tipo di modalità per cui si richiede la registrazione
-
viene eseguita la procedura di autenticazione
-
i dati di sottoscrizione sono trasferiti dall’HLR ai nodi SGSN e MSC/VLR
-
l’SGSN informa il terminale che la procedura è stata completata con
successo.
11
Figura 2.3 – Procedura di GPRS Attach
Terminata la procedura di Attach, un utente, per poter scambiare dati, deve attivare
un contesto PDP (Packet Data Protocol); tale contesto descrive le caratteristiche
della connessione verso la rete dati esterna e la sua attivazione consta dei seguenti
passi:
-
il terminale mobile richiede l’attivazione del contesto PDP, specificando
alcuni parametri come l’assegnazione di un indirizzo IP statico o dinamico e
la QoS richiesta
-
l’SGSN convalida la richiesta in base ai dati di sottoscrizione ricevuti
dall’HLR al momento della registrazione
-
l’SGSN determina l’indirizzo del GGSN in base alle informazioni ricevute
dal terminale e ai dati di sottoscrizione
-
viene creato un tunnel GTP [6] (GPRS Tunneling Protocol) tra GGSN ed
RNC
-
l’SGSN chiede al GGSN di allocare un indirizzo IP e quindi lo trasferisce al
terminale mobile
12
Figura 2.4 – Procedura di Attivazione del Contesto PDP
Conclusasi questa procedura, può cominciare la comunicazione tra il terminale
mobile e la rete dati esterna.
Ogni servizio di rete tra due terminali può essere caratterizzato da una certa Qualità
del Servizio (QoS) che viene fornita all’utente. Definendo le classi di QoS per il
sistema UMTS si deve tenere conto delle restrizioni e delle limitazioni derivate
dalla presenza dell’interfaccia radio; risulta quindi ragionevole non definire
meccanismi complessi, bensì studiare procedure robuste e adatte al tipo di sistema
considerato.
Le classi di QoS previste per l’UMTS sono le seguenti:
-
Conversazionale: per conversazioni real-time come servizi voce, voce su
IP, videoconferenza. Il tempo di trasferimento deve essere mantenuto basso
e la relazione temporale tra le varie componenti del flusso informativo deve
essere mantenuta costante.
-
Streaming: per servizi trasmessivi video o audio real-time unidirezionali, da
un server verso il terminale mobile; non sono necessari requisiti di basso
ritardo di trasferimento.
13
-
Interattiva: navigazione in Internet, interrogazione di banche dati, accesso a
server di rete; i requisiti principali sono il ritardo round-trip e un basso tasso
di errore.
-
Background: invio o ricezione di dati come processo secondario rispetto ad
altri a più alta priorità; esempi sono SMS, e-mail; l’unico requisito
importante è un basso tasso di errore.
2.1.2 – Gestione della mobilità in UMTS
In ogni sistema radiomobile è di fondamentale importanza garantire la continuità
della connessione al di là della frammentazione cellulare: questo processo viene
comunemente chiamato handover.
In un sistema CDMA, in cui la distanza di riuso frequenziale è pari a 1, l’handover
può essere realizzato in maniera molto differente rispetto a ciò che avviene nelle reti
di seconda generazione. In UMTS si parla di soft handover [4], reso possibile dal
meccanismo della macrodiversità: ciò consente al terminale mobile di mantenere
una connessione attiva tramite più cammini radio, attivabili anche attraverso
differenti stazioni radio base; l’insieme delle stazioni attive che si fanno carico della
connessione
è
detto
active
set.
In
down-link
il
terminale
riceve
contemporaneamente da tutte le stazioni appartenenti all’active set, beneficiando di
una migliore qualità del segnale ricostruito; anche in up-link la qualità migliora in
quanto il nodo che ricostruisce l’informazione (il Node B se le celle dell’active set
appartengono ad un unico Node B; l’RNC se le celle appartengono a Node B
differenti) può operare con tassi di errore più bassi grazie alla ridondanza. In UMTS
l’handover viene gestito per buona parte all’interno dell’UTRAN, evitando in
questo modo di coinvolgere in questa procedura il Core Network.
Nella fase di handover la continuità della connessione è garantita dalla molteplicità
dei cammini; non si ha quindi un salto tra i canali come avviene nel GSM e proprio
per questo motivo si parla di “soft” handover. Un’importanza particolare nella
procedura di soft handover è rivestita dall’interfaccia Iur, che collega RNC
differenti: in questo modo, se il terminale passa da un RNC ad un altro, i dati
14
possono continuare a fluire tramite questa interfaccia verso il nuovo RNC; solo
successivamente, tramite un’operazione detta di streamlining, i dati fluiranno
direttamente verso il nuovo RNC.
Figura 2.5 – Streamlining UMTS
L’altra procedura legata alla mobilità è quella di localizzazione del mobile [4]; è
importante infatti che la rete conosca, istante per istante, dove il mobile sia situato.
Le celle sono raggruppate in aree di localizzazione (Location Area, LA); ogni volta
che il terminale attraversa il bordo di una di queste aree, la rete registra il
cambiamento nelle basi di dati (VLR – HLR). In caso di chiamata diretta ad un
terminale mobile è importante un giusto dimensionamento dell’area a cui verrà
inviato l’avviso di chiamata in arrivo (area di paging).
In analogia alle Location Area utilizzate dal backbone a commutazione di circuito,
la rete a commutazione di pacchetto utilizza le Routing Area (RA) (di estensione
inferiore alle LA). Se il terminale mobile non ha connessioni dati attive, la rete
segue i suoi spostamenti a livello di RA; quando invece è in corso un trasferimento
dati gli spostamenti del mobile vengono seguiti a livello di cella. L’instradamento
dei dati nella rete a commutazione di pacchetto è basato su IP che necessita però di
meccanismi di supporto per gestire la mobilità dell’utente; al momento
dell’attivazione del contesto PDP viene creato un tunnel tra l’RNC, che controlla la
cella in cui si trova in quel momento il mobile, e il GGSN di riferimento; se l’utente
cambia RNC o SGSN di appartenenza, verranno aggiornati i registri (tramite una
15
procedura detta di Routing Area Update) ed anche il GGSN ne terrà conto
modificando la destinazione verso cui incapsulare i pacchetti in arrivo destinati al
mobile.
2.1.3 – Limiti di UMTS
Lo standard UMTS, ancora oggi in fase di evoluzione, sulla base anche
dell’esperienza delle reti di prima e seconda generazione, rappresenta un sistema di
comunicazione mobile solido ed affidabile. I meccanismi di autenticazione,
crittazione dei dati, accounting e billing degli utenti sono giunti ad un livello di
ottimo.
I sistemi di terza generazione sono però nati con l’obiettivo primario di soddisfare
un bisogno di servizi a larga banda per utenti mobili. Al giorno d’oggi ancora in
nessun paese europeo è partita ufficialmente l’offerta di servizi e non è quindi
possibile vedere se nella realtà queste aspettative sono state mantenute. Sembra però
che la banda messa a disposizione da UMTS non sia poi così larga; i 2 Mbit/s
difficilmente verranno raggiunti, se non in microcelle indoor serventi un unico
terminale. Senza dubbio più realistici saranno data rate nell’ordine di 144-384
kbit/s, quanto è possibile ottenere oggi con i modem di casa; considerando anche il
problema della soft degradation forse non sarà possibile fruire veramente di servizi
video real-time a larga banda.
Un ulteriore problema che potrà rallentare la diffusione del sistema UMTS è
rappresentato dai costi del servizio: gli operatori hanno speso decine di miliardi di
euro per le licenze; hanno dovuto creare l’infrastruttura di rete (tutta o in parte) e
sviluppare un notevole know-how. Anche pianificando un punto di pareggio tra
diversi anni, a causa del suo costo il servizio, almeno nei primi tempi, sarà senza
dubbio destinato ad un’utenza prettamente business.
16
2.2 – WLAN: nomadismo a larga banda
Le
Wireless
LAN
nascono
come
estensione wireless delle LAN aziendali:
con il diffondersi dei computer portatili
prima e dei PDA negli ultimi tempi, si è
fatto sempre più pressante il bisogno di
poter essere connessi alla rete aziendale ad
anche ad Internet senza la limitazione
spaziale imposta dal tradizionale desktop.
Figura 2.6 – Apparati WLAN
Dagli inizi degli anni novanta gli enti di standardizzazione (ETSI ed IEEE in
primis) definirono standard per sistemi di tipo Wireless LAN.
Quello che in una prima fase era visto solamente come un’estensione delle LAN
aziendali, non tardò ad attirare l’attenzione di diverse società fornitrici di
connettività Internet, le quali intravidero le possibilità che queste tecnologie
possedevano nel poter fornire servizi di connessione a larga banda in zone dedicate:
iniziarono così a prendere piede i nuovi concetti di Public WLAN e WISP (Wireless
Internet Service Provider).
Le WLAN incarnano alla perfezione il concetto di nomadismo: un utente WLAN,
nei suoi spostamenti quotidiani, può accedere in certe zone (es. aeroporti, hotel,
centri commerciali, stazioni), dette Hot Spot, per usufruire del servizio di
connettività wireless, poi nuovamente spostarsi per accedere successivamente in un
altro Hot Spot. Questa visione è particolarmente calzante se si pensa che la maggior
parte dei servizi a larga banda (video streaming, video conferenza, ecc…) è
pensabile sia acceduta da postazioni statiche o comunque a mobilità limitata.
Proprio per queste loro caratteristiche le WLAN furono inizialmente viste come una
minaccia da parte degli operatori UMTS; con il passare dei mesi si è però capito che
queste tecnologie, sia per alcuni limiti che analizzerò in seguito, sia per le loro
17
peculiari caratteristiche, possono invece essere una grande opportunità di
convergenza per le società detentrici delle licenze per i sistemi cellulari di terza
generazione.
Al momento attuale esistono diversi standard WLAN: la famiglia IEEE 802.11,
Hiperlan/2 dell’ETSI e, in un ambito più propriamente WPAN (Wireless Personal
Area Network), Bluetooth.
Nel paragrafo seguente verrà trattato principalmente lo standard IEEE 802.11b, il
più diffuso e quello che ho utilizzato per le prove sperimentali. Verranno dati anche
brevi cenni sulle altre tecnologie WLAN e sugli sviluppi futuri.
2.2.1 – IEEE 802.11
Negli ultimi anni l’Istituto dell’Ingegneria Elettrica ed Elettronica (IEEE) ha
sviluppato una famiglia di standard per le reti locali con tecnologia wireless note
con la sigla IEEE 802.11.
Il primo standard fu sviluppato a partire dal 1991 e pubblicato nel giugno del 1997.
Noto con la sigla IEEE 802.11 (std. 802.11-1997) definisce le specifiche sui
parametri dello strato fisico (PHY) e dello strato di controllo dell’accesso (MAC) in
modo da poter connettere dei dispositivi all’interno di reti locali di tipo wireless.
Lo standard di base iniziale è stato successivamente aggiornato in una nuova
versione del 1999 [8]. Nella trattazione seguente si farà riferimento a questa
versione del protocollo.
Sempre nel 1999 la IEEE pubblica altre due versioni dello standard 802.11: definiti
come 802.11a [9] e l’802.11b [10]. Il primo, IEEE 802.11a, nasce con l’esigenza
di sviluppare un nuovo livello fisico per WLAN in grado di operare in una nuova
banda di frequenze e consentire una velocità di flusso superiore a quella prevista
dallo standard di base. Il secondo standard, IEEE 802.11b, può essere considerato
la naturale evoluzione dello standard iniziale e consente di raggiungere delle
velocità di flusso più elevate sfruttando la stessa banda di frequenze (higher rate).
18
In prima approssimazione tutte queste reti sono paragonabili a quelle Ethernet, con
in più tutto quell’insieme di vantaggi che sono derivanti dalla natura wireless dei
collegamenti utilizzati.
2.2.1.1 – Architettura IEEE 802.11
Una Wireless LAN può essere impiegata per sostituire interamente una rete locale
fissa oppure può essere utilizzata in modo efficiente per estendere una infrastruttura
di rete già esistente. Nella tipica configurazione di una Wireless LAN gli utenti,
provvisti di terminali mobili (STA) dotati di una scheda di rete conforme al
protocollo 802.11 possono accedere ai servizi della rete fissa o cablata passando
attraverso i dispositivi di accesso (Access Point, AP).
In generale una WLAN è costituita da un insieme di dispositivi in grado di
comunicare tra loro sfruttando l’etere come mezzo fisico di comunicazione.
Quella rappresentata in figura è definita in modo specifico come architettura
wireless strutturata.
Figura 2.7 – WLAN, configurazione Infrastructure
Gli Access Point costituiscono l’interfaccia tra la rete cablata e la rete Wireless.
Sono dispositivi che funzionano come nodi di riferimento per la trasmissione e
ricezione dei flussi informativi tra i vari utenti. Attraverso la loro combinazione con
un sistema di distribuzione (ad esempio Ethernet) sono in grado di supportare la
creazione di celle radio multiple e permettere la funzione di roaming tra le stesse.
19
Le schede wireless rappresentano l’interfaccia dei dispositivi mobili, quali portatili,
laptop e palmari, con la rete locale wireless. L’insieme di una di queste schede e
del dispositivo che la ospita costituisce una “stazione wireless” indicata
generalmente con la sigla abbreviata STA. Lo standard IEEE 802.11 prevede la
possibilità di configurare la rete secondo due modalità: modalità “Ad-Hoc” e
modalità “Strutturata”.
Prima di tutto definiamo come BSS (Basic Service Set) o set di Stazioni Base, un
insieme di almeno due stazioni wireless conformi allo standard IEEE 802.11 che
sono operanti all’interno di una rete WLAN. Il BSS determina l’area all’interno
della quale le stazioni ad esso associate rimangono connesse e sono in grado di
muoversi liberamente (BSA Basic Service Area : area di copertura radio).
Una stazione non può comunicare direttamente con le altre stazioni se esce dal BSS.
Una configurazione wireless Ad-Hoc si realizza quando un insieme di stazioni STA
che costituiscono un BSS operano in modo indipendente senza la presenza di alcun
Punto di Accesso e quindi senza la struttura di una dorsale (backbone). Questa
configurazione viene anche definita come sistema di rete IBSS (Independent Basic
Service Set Network).
Praticamente i terminali mobili sono riuniti insieme per formare una rete
indipendente "on the fly", che non richiede di essere pre-configurata apparendo così
la soluzione più semplice ed economica per realizzare WLAN.
Figura 2.8 – WLAN, configurazione ad-hoc
20
Una
topologia
Strutturata
viene
invece
definita
quando
sono
presenti
nell’architettura degli Access Point con i quali le stazioni wireless possono
comunicare. In questa modalità di connessione viene definito come Sistema di
Distribuzione DS (Distribution System) l’elemento attraverso il quale è possibile
connettere le stazioni di una BSS, con quelle appartenenti ad altre BSS, utilizzando
più Punti di Accesso.
In questo caso viene costituita una rete di servizi estesa definita come ESS
(Extended Service Set), grazie alla quale è possibile creare una configurazione di
rete di dimensioni e complessità arbitrarie, caratterizzate dalla presenza di un
backbone, a sua volta wireless o wired. Attraverso il Sistema di Distribuzione è
anche possibile connettere le diverse BSS con altre reti locali che non siano
necessariamente wireless, con il fine di sfruttare la rete cablata o di usufruire dei
servizi della rete Internet.
2.2.1.2 – Lo standard IEEE 802.11
Lo standard IEEE 802.11 riguarda, come accennato in precedenza, il livello fisico
(PHY) e quello di accesso al mezzo (MAC).
In particolare definisce un unico MAC per tutte le famiglie 802.11, mentre prevede
tre differenti livelli fisici: radio (all’interno di una banda che varia da 2,400 a 2,485
MHz, corrispondente ad una porzione della banda ISM Industrial, Scientific e
Medical) basato su FHSS o su DSSS, infrarossi.
Un sistema basato su FHSS (Frequency Hopping Spread Spectrum) funziona
trasmettendo dati su un certo numero limitato di frequenze, tra le quali salta
continuamente.
Utilizzando la modalità DSSS (Direct Sequence Spread Spectrum), i dati vengono
trasmessi occupando in maniera fissa una certa banda di frequenze; in questo modo
si riescono ad ottenere data rate maggiori a scapito di alcune limitazioni di
interferenza.
Il sistema basata su raggi Infrarossi, a causa del suo range di trasmissione
estremamente limitato, è stato pressoché abbandonato.
21
Il meccanismo base di accesso per la famiglia 802.11 è il CSMA/CA (Carrier Sense
Multiple Access with Collision Avoidance) con algoritmo di backoff di tipo
esponenziale. Questo meccanismo si differenzia da quello CSMA/CD (Carrier
Sense Multiple Access with Collision Detection) utilizzato in Ethernet per alcune
caratteristiche: mentre una stazione Ethernet trasmette fino a che non rileva una
collisione, una stazione operante con CSMA/CA ascolta la rete e trasmette solo se
altre stazioni non stanno scambiando dati in quel momento; se viene rilevata una
trasmissione dati in corso la stazione determina un tempo random di attesa,
trascorso il quale ascolta nuovamente al fine di poter iniziare la trasmissione.
Al fine di minimizzare il rischio di collisioni per interfacce preziose come quelle
radio, lo standard prevede due modalità (DCF e PCF) che possono impiegare un
meccanismo detto Request To Send/Clear To Send (RTS/CTS).
La modalità DCF (Distributed Coordination Function) è utilizzata da ogni
componente del BSS per determinare quando, all’interno del periodo di contesa del
mezzo, può trasmettere i propri dati. Se la stazione avverte che il canale è libero,
lascia passare un certo tempo di attesa ed inizia a trasmettere.
In modalità PCF (Point Coordination Function), un nodo del BSS (solitamente un
AP) controlla il traffico, chiedendo in sequenza alle varie stazioni di trasmettere i
loro dati (se ne hanno); questa funzionalità è molto importante per applicazioni realtime in modo da ottenere per la durata della trasmissione data-rate costanti ed
affidabili.
Il meccanismo RTS/CTS prevede che, quando un AP riceve dati da trasmettere ad
una stazione, invii un frame RTS chiedendo alla stazione di riservare un tempo
sufficiente alla ricezione dei dati; la stazione risponde positivamente all’AP con un
frame CTS. Le altre stazioni ascoltano questo scambio di frame e aspettano
anch’esse lo stesso tempo prima di provare a trasmettere i loro dati. L’RTS/CTS
risolve anche il problema dell’hidden node, in quanto una stazione che non conosce
l’esistenza di qualcuna delle altre stazioni interne al BSS, può ricevere informazioni
sulla loro presenza tramite i frame RTS trasmessi nell’etere dall’AP.
A causa dell’intrinseca inaffidabilità del mezzo radio, è prevista, a livello MAC,
una funzionalità di acknowledgment (ACK). Quando la stazione di destinazione
riceve un pacchetto manda un ACK al mittente; se il mittente, dopo un tempo
22
prefissato, non riceve un ACK dal destinatario, invia nuovamente il pacchetto; tutto
questo avviene in maniera del tutto trasparente all’utente.
Lo standard 802.11, al fine di ovviare al problema di pacchetti corrotti a causa
dell’interferenza, prevede la possibilità di frammentare i pacchetti trasmessi in
pacchetti più piccoli, in modo da ridurre la quantità di dati da dover ritrasmettere in
caso di errore; questa modalità è configurabile, permettendo così di scegliere il
valore ottimale di frammentazione in base alla quantità di interferenza
nell’ambiente.
2.2.1.3 – Power Management
Il problema del consumo delle batterie è vitale per ogni terminale wireless: per
ridurre tale consumo lo standard 802.11 ha previsto per il livello MAC, quando non
svolge l’attività di trasmissione dati, una funzione di Power Management; il
dispositivo radio viene posto in uno stato “idle” per un periodo di tempo specifico o
selezionabile dall’utente. Può sorgere il problema che la stazione perda i dati ad
essa destinati quando si trova in questo stato. Lo standard lo risolve prevedendo
l’incorporazione nell’AP di un buffer per accodare i messaggi. La stazione si
sveglia periodicamente e preleva i messaggi contenuti nel buffer.
2.2.1.4 – Autenticazione e sicurezza
Con lo scopo di limitare gli accessi non autorizzati alla rete e salvaguardare il
contenuto delle informazioni trasmesse attraverso una Wireless LAN, lo standard
IEEE 802.11 prevede due meccanismi principali per garantire un certo livello di
sicurezza: un servizio di autenticazione e l’implementazione del protocollo WEP
(Wired Equivalent Protocol). Attraverso l’autenticazione bisogna cercare di
permettere l’accesso alla rete soltanto a quei dispositivi che sono “autorizzati”,
impedendo così delle intrusioni non lecite. Il protocollo WEP deve garantire sia
l’autenticazione che la privacy delle informazioni scambiate, poiché bisogna cercare
di impedire che degli utenti indiscreti in ascolto siano in grado di captare i dati
trasmessi.
Sono definiti due diversi servizi di autenticazione con lo scopo di controllare gli
accessi alla rete: Sistema di Autenticazione Aperto e un sistema con Chiave di
23
Autenticazione Pubblica. La scelta tra i due viene indicata attraverso un campo del
frame di gestione di autenticazione il quale consente anche di indicare il
corrispondente algoritmo di autenticazione scelto. Il protocollo non consente
autenticazione multicast ma questa può avvenire solo tra due stazioni .

Sistema di Autenticazione Aperto: questo sistema si compone di due
passaggi fondamentali. Prima una stazione richiede l’autenticazione a un’altra
stazione o ad un Access Point attraverso l’invio di un frame di richiesta di
autenticazione. Successivamente la stessa stazione si mette in attesa di un
secondo frame in cui è contenuto l’esito dell’autenticazione. Se questo
procedimento avrà successo allora le due stazioni saranno mutuamente
autenticate. Il sistema di autenticazione aperto è considerato di default nello
standard IEEE 802.11.

Sistema di Autenticazione a Chiave Condivisa : questo sistema supporta
l’autenticazione tra stazioni che non conoscono l’una la chiave segreta dell’altra
e senza la necessità che questa sia trasmessa in chiaro; i vari utenti conoscono
invece la chiave pubblica della stazione con la quale vogliono comunicare.
Questa modalità necessita dell’implementazione del meccanismo di sicurezza
WEP. Quest’ultimo è necessario per la creazione di un canale sicuro e
indipendente attraverso il quale avviene lo scambio della chiave pubblica che
sarà poi memorizzata da ogni stazione. Questo sistema si basa sui seguenti
quattro passaggi corrispondenti ognuno all’invio di un frame:
1.
La stazione A invia alla stazione B un messaggio di richiesta di
autenticazione.
2.
Dopo aver ricevuto il messaggio di richiesta, la stazione B utilizza il
protocollo di sicurezza WEP per generare un frame di 128 ottetti che sarà
definito come Challenge Text e inviato al richiedente. Nel caso in cui questa
fase non ha successo il contenuto del Challenge Text rimane non specificato ed
il processo di autenticazione si interrompe, in caso contrario si continua.
3.
La stazione A che riceve il Challenge Text con il secondo frame lo
copia in un terzo frame che sarà trasmesso nuovamente alla stazione B dopo
essere stato crittografato con la chiave pubblica attraverso l’algoritmo WEP.
4.
La stazione B decodifica il contenuto del terzo frame che ha ricevuto
utilizzando la sua chiave. Quindi confronta il risultato con il messaggio inviato
24
in precedenza nel secondo frame. Se i due testi risultano uguali allora
l’autenticazione ha avuto successo e la stazione B comunica questo risultato alla
stazione A, altrimenti gli comunica che la sua richiesta è stata rifiutata.
Per risolvere il problema delle intercettazioni indesiderate da parte di utenti esterni,
lo standard prevede l’implementazione di un protocollo di sicurezza equivalente a
quello specificato nelle reti fisse definito appunto WEP (Wired Equivalent
Protocol). Attraverso questo protocollo è possibile effettuare una codifica
crittografata delle unità dati garantendo così un livello iniziale di riservatezza sulle
trasmissioni. E’ anche possibile provvedere ad un servizio di autenticazione e
integrità per tutto il traffico che attraversa la WLAN.
Questo protocollo, con riferimento al modello OSI può essere collocato tra i due
livelli più bassi (data link e fisico), e non fornisce quindi una sicurezza del tipo endto-end.
2.2.1.5 – IEEE 802.11b
Nel 1999 la IEEE definisce un nuovo standard specificato come IEEE 802.11b che
può essere considerato come una naturale evoluzione dello standard di base per le
reti wireless locali IEEE 802.11 con il quale è compatibile. Ad oggi questo risulta
essere lo standard implementato nella maggior parte delle Wireless LAN. Opera
utilizzando una modalità di trasmissione a diffusione di spettro ad alta velocità,
definita come HR-DSSS (High Rate Direct Sequence Spread Spectrum) che
rappresenta una estensione dello standard DSSS, all’interno di una banda fissata
intorno ai 2,4 GHz. Utilizza una tecnica di modulazione conosciuta come CCK
(Complementary Code Keying) e può raggiungere un data rate che può variare da 1
Mbit/s, 2 Mbit/s, 5.5 Mbit/s fino a 11 Mbit/s a seconda della distanza tra le stazioni
STA (client) e gli Access Points: maggiore è il data rate e minore sarà l’area di
copertura di una cella.
Tramite il protocollo IEEE 802.11b è possibile:
− variare la velocità di trasmissione dati per adattarsi al canale;
− un data rate fino a 11 Mbit/s;
25
− scegliere automaticamente la banda di trasmissione meno occupata;
− scegliere automaticamente l’Access Point in funzione della potenza del
segnale e del traffico di rete;
− creare un numero arbitrario di celle parzialmente sovrapposte permettendo il
roaming in modo trasparente.
Lo standard IEEE 802.11b è conosciuto anche come Wi-Fi ed è stato approvato dal
WECA (Wireless Ethernet Compatibility Alliance) che garantisce l’interoperabilità
tra dispositivi di produttori diversi.
2.2.1.6 - IEEE 802.11a
Standard operante nella banda dei 5 GHz con data rate fino a 54 Mbit/s grazie alla
tecnica OFDM (Orthogonal Frequency Division Multiplexing) utilizzata a livello
fisico. Gli standard 802.11b e 802.11a sono caratterizzati dallo stesso livello MAC,
questo fa sì che dal punto di vista dell’utente i prodotti dei diversi standard possano
essere interconnessi tra di loro mediante Access Point Dual Slot (devono cioè
possedere due interfacce) per rendere possibile l’interoperabilità tra dispositivi
mobili di standard diversi.
2.2.1.7 – IEEE 802.11g
E’ il nuovo standard in arrivo per le reti wireless. Può trasferire i dati a 54 Mbps
operando alla frequenza di 2,4 GHz, ma il suo punto di forza è quello di essere
compatibile con gli standard già affermati sul mercato come 802.11b. Il gruppo di
lavoro della IEEE che sta portando avanti questo progetto ha lo scopo di sviluppare
una estensione ad alta velocità per il livello fisico come definito nello standard
802.11b. Questo nuovo standard sarà comunque compatibile con il livello MAC di
802.11, e dovrà poter supportare le diverse velocità di trasmissione consentite in
una specifica area di copertura.
26
E’ lecito pensare che questo standard conquisterà nel prossimo futuro il mercato, in
attesa che siano commercializzate le schede, che siano creati nuovi punti d’accesso
e potenziata la sicurezza del servizio. Ad oggi è disponibile una Draft su IEEE
802.11g [11] mentre la sua definitiva approvazione dovrebbe essere prevista per
metà 2003.
2.2.1.8 - QoS in 802.11
Con questo termine, che significa “Qualità del Servizio”, si vuole intendere la
capacità di un sistema di controllare e rilevare i valori del data-rate (throughput) ed
il tasso di errore percentuale in fase di trasmissione. Una specifica accurata del
QoS è di fondamentale importanza quando si devono sviluppare delle applicazioni
multimediali a carattere audio e video.
Inizialmente nelle reti wireless LAN, pensate soprattutto per applicazioni aziendali,
questo particolare non è stato preso in considerazione e non sono state adottate
particolari specifiche al riguardo. Oggi però con l’intenzione di allargare l’uso di
queste tecnologie anche all’ambito domestico e pensando ad altri possibili utilizzi
nello stesso mondo business (video-conferenza, voce su IP, etc.), diventa molto
importante poter garantire un certo livello di QoS.
Ad oggi il problema del QoS nelle reti WLAN è in fase di risoluzione e si sta
cercando di gestirlo basandosi soprattutto su una politica di controllo dell’accesso al
canale, che dovrà essere il più possibile garantito. Con questo scopo è stato definito
dalla IEEE 802.11 un Task Group (IEEE 802.11 TGe) che ha il compito di definire
uno standard per modificare il livello MAC in modo da migliorare e gestire il
Quality Of Service, e aumentare i meccanismi di sicurezza e autenticazione.
Verranno portati dei cambiamenti soprattutto per quello che riguarda le modalità di
accesso, sia distribuito (DCF) che centralizzato (PCF).
2.2.1.9 – Cenni su altri standard WLAN
Le soluzioni per reti wireless standardizzate nel protocollo 802.11 e relative
estensioni non esauriscono lo spazio delle possibilità per le WLAN. Sono possibili
anche implementazioni di tecnologie senza filo anche in ambiti più ristretti, come
27
per le reti WPAN (Personal Area Network), ossia quelle reti tra PC, dispositivi
palmari, etc. caratterizzate da ambiti molto più limitati, con aree interessate che di
norma non superano i 2-3 metri. Le tecnologie wireless possono anche essere
utilizzate per realizzare reti su scala metropolitana.
Bluetooth
Lo standard Bluetooth è stato progettato come sistema di trasmissione wireless a
corto raggio, da inserire nei dispositivi mobili per operare ad una frequenza di 2,45
GHz senza la necessità di alcuna licenza. Le reti Bluetooth fanno riferimento ad una
wireless PAN (Personal Area Network) e sono state pubblicate dal Bluetooth
Special Interest Group (SIG) insieme a 3Com, Ericsson, IBM, Intel, Lucent,
Microsoft, Motorola, Nokia e Toshiba.
Bluethooth è caratterizzato da un data rate di 1 Mbit/s, bassa potenza, e utilizza la
tecnica FSSH (con hopping-rate di 1600 hops/sec, molto più elevato rispetto a
802.11) intorno alla banda di 2.4 GHz. Un attuale problema è rappresentato dal fatto
che i prodotti Bluetooth e quelli conformi allo standard 802.11 operano nella stessa
banda, aumentando la probabilità che si verifichino interferenze tra le varie
comunicazioni. Mentre un terminale 802.11 sta trasmettendo ad una particolare
frequenza, il vicino dispositivo Bluetooth molto probabilmente interferirà con la
trasmissione prima che il dispositivo 802.11 passi alla frequenza successiva.
Questa interferenza creata dai segnali radio inviati dai prodotti Bluetooth può
degradare notevolmente le trasmissioni della rete 802.11. Bluetooth potrebbe essere
considerata una alternativa alle trasmissioni ad infrarossi, superando così la
necessità di avere necessariamente dei collegamenti a “vista” anche se bisogna
comunque dire che questa tecnologia oggi sembra avere minor futuro rispetto alle
WLAN 802.11.
Hiperlan/2
Standard Broadband Radio Access Network (BRAN) sviluppato dall’ European
Telecommunications Standards Institute (ETSI); definisce le specifiche dei livelli
MAC e PHY per reti Wireless operanti nella banda intorno ai 5 GHz. La prima
28
versione Hiperlan/1 non ha riscosso molto successo principalmente a causa
dell’utilizzo di un protocollo connectionless per l’accesso al mezzo. Hiperlan/2,
sviluppato dall’organizzazione Hiperlan/2 Global Forum (H2GF), opera nella banda
dei 5 GHz con un data date fino a 54 Mbps, utilizzando un protocollo orientato alla
connessione per l’accesso al mezzo wireless. Includerà QoS, e sarà in grado di
trasportare frame Ethernet, celle ATM, e pacchetti IP.
2.2.2 – Gestione della mobilità in 802.11b
Nel caso in cui si abbia la necessità di estendere l’area di copertura di una WLAN o
di aumentare il numero di terminali che possono connettersi ad essa, bisogna
ricorrere all’utilizzo di diversi Access Point ognuno dei quali diventa responsabile
della comunicazione in una specifica area. Si crea una topologia di tipo cellulare
paragonabile (ad un livello locale) a quella del sistema GSM in cui diventa molto
importante garantire una continuità di connessione alla rete per gli utenti che si
spostano da una cella all’altra (handover). Lo standard IEEE 802.11 non definisce
dei meccanismi specifici per questa funzione, ma lascia ai costruttori l’onere di
definire i protocolli di gestione dell’handover.
Lo standard definisce però tre modalità di transizione diverse:
No-transition: viene utilizzato per quelle stazioni che si muovono rimanendo
all’interno di un BSS o che non si muovono.
BSS-transition: mobilità realizzata dalle stazioni che si muovono da un BSS
a un altro BSS restando sempre nello stesso ESS.
ESS-transition: mobilità realizzata dalle stazioni che si muovono da un BSS
di un ESS a un altro BSS di un differente ESS. In questo caso non è garantita la
continuità.
Ogni modalità di transizione è supportata da una diversa funzionalità definita di
associazione, attraverso le quali è possibile per esempio individuare quale sia l’AP
al quale una stazione in movimento deve accedere.
29
Si definiscono così i seguenti servizi:
•
Servizio di Associazione: attraverso tale servizio viene abilitata la
mappatura di una stazione wireless all’interno della rete di distribuzione tramite
un Access Point; praticamente ogni stazione deve associarsi con un Access
Point prima di poter inviare dei dati attraverso quello che viene definito un
“Sistema di Distribuzione”. E’ sufficiente per supportare una mobilità NoTransition.
•
Servizio di Riassociazione: funzionalità che abilita una stazione a cambiare
il suo stato di associazione da un Access Point ad un altro, consentendo il
roaming tra celle differenti all’interno della stessa ESS. E’ sufficiente per
supportare una mobilità BSS-Transition .
•
Servizio di Disassociazione: processo utilizzato da una stazione o da un
Access Point per comunicare al sistema di distribuzione che sta per essere
terminata una associazione esistente. E’ la notifica effettuata da una stazione
quando lascia la rete.
Per risolvere il problema del roaming è stato sviluppato un protocollo distinto dallo
standard IEEE, l’IAPP (Inter-Access Point Protocol); vengono specificate le
modalità attraverso le quali i vari punti di accesso comunicano tra loro per gestire e
scambiarsi il controllo dei vari utenti mobili all’interno di una rete locale Wireless.
Questo è un vero e proprio protocollo di roaming ed utilizza il protocollo di
trasporto UDP e quello IP per il livello di rete. Viene implementato dagli stessi
Access Point in modo tale da consentire agli utenti wireless di muoversi liberamente
tra le varie celle che costituiscono lo spazio fisico all’interno del quale è garantita la
connettività senza perdere la continuità del collegamento stesso. Nella figura
seguente viene evidenziato come un utente wireless in movimento (rappresentato da
un PC portatile con una scheda 802.11 integrata), passi dalla regione di copertura
dell’AP1 alla regione di copertura dell’AP2 rimanendo “agganciato” alla rete.
30
Figura 2.9 – IAPP
Nel momento in cui il terminale wireless entra nella regione di copertura comune
tra i due Access Point, questi comunicano tra di loro attraverso il sistema di rete
fisso, sfruttando il protocollo IAPP in modo tale che lo stesso terminale rimanga
connesso con il dispositivo dal quale riceve il segnale migliore. La connessione sarà
rivolta verso il dispositivo che emette un segnale migliore o più forte, in
corrispondenza della posizione che si sta occupando istantaneamente (nella figura è
ancora AP1).
2.2.3 – Limiti di WLAN
Sebbene le WLAN (802.11b in particolare) rappresentino una tecnologia ormai
matura per offrire connettività negli hot spot dedicati, altrettanto non si può dire se
le si considera come tecnologia di accesso complementare all’UMTS.
Nei prossimi capitoli verranno analizzati in maggior dettaglio i limiti attuali delle
WLAN: meccanismi di AAA (Authentication, Authorizing and Accounting), di
sicurezza e di roaming; verranno anche discusse possibili soluzioni per superarli in
modo da poter fattivamente pensare ad una integrazione con i sistemi radiomobili di
terza generazione.
31
Un ulteriore problema che limita ancora la diffusione delle WLAN in Europa è
l’assenza di una regolamentazione in materia; la tendenza è una “liberalizzazione
controllata” come sta accadendo in questi tempi in Italia, dove il Ministero per le
Comunicazioni ha avviato un periodo di sperimentazione durante il quale non sarà
possibile offrire servizi di connettività WLAN a pagamento. Una regolamentazione
è comunque necessaria in quanto, a causa della tecnica DSSS utilizzata in 802.11b,
non è possibile avere contemporaneamente più di tre canali non sovrapposti; è
quindi molto probabile che, per ogni hot spot, ci sia un unico Access Provider che
fornirà connettività a vari Service Provider.
32
2.3 – Mobilità in IPv6
In un progetto che si propone di studiare una soluzione integrata WLAN-UMTS e
di gestire la mobilità tra le due reti di accesso in maniera trasparente all’utente, è
fondamentale conoscere i protocolli di gestione della mobilità esistenti.
Lo scenario immaginato è quello di un utente dotato di terminale multi-modo
WLAN-UMTS; ciò che si vuole ottenere è che il passaggio da una rete di accesso
WLAN ad una UMTS avvenga in maniera del tutto trasparente per l’utente e che le
connessioni in corso vengano mantenute durante questi passaggi.
Ciò che accade quando un utente effettua un handover tra due reti eterogenee è che
viene a trovarsi in una rete IP con prefisso di rete differente rispetto a quello di
provenienza. Questo comporta che le connessioni aperte cadono a causa
dell’inconsistenza dell’indirizzo con quello della nuova rete.
In uno studio sperimentale della mobilità tra reti eterogenee è bene distinguere tra
gestione della macromobilità e gestione della micromobilità
Per macromobilità si intende il passaggio di un terminale mobile tra macrocelle; è
un termine usato per indicare handover tra reti di accesso differenti, quindi poco
frequenti, che hanno esigenze di bassa latenza dell’handover non troppo stressanti.
In questa ricerca con il termine di macromobilità si indica quella che avviene al
passaggio da un’area di copertura UMTS ad una di copertura WLAN e viceversa.
La micromobilità riguarda invece handover molto frequenti, solitamente tra
microcelle; tali handover avvengono all’interno di una stessa rete di accesso e
necessitano di bassa latenza.. In questo progetto la micromobilità riguarderà
fondamentalmente gli handover che occorrono internamente ad una rete WLAN,
visto che UMTS già prevede meccanismi avanzati per la gestione della
micromobilità.
33
2.3.1 – Gestione della macromobilità
Nel recente passato si è cercato di risolvere il problema della gestione della
macromobilità tramite Mobile IPv4 [15].
Mobile IPv4 estende il protocollo IPv4 attribuendo simultaneamente ad ogni Nodo
Mobile due indirizzi IP, uno che lo identifica (stabile), l'altro per essere raggiunto
quando si trova lontano dalla sua Home-Network (dinamico).
La procedura seguita è la seguente:
I Mobility Agent, notificano la loro presenza mandando dei messaggi di
Advertisement. Un Nodo Mobile può opzionalmente sollecitare un messaggio di
advertisement.
Dopo aver ricevuto un messaggio di advertisement, un Nodo Mobile determina se è
collegato alla sua Home Network o si trovi invece presso una Foreign Network. Nel
primo caso riceve ed invia dati come un normale nodo IP.
Quando un Nodo Mobile si trova in visita presso una Foreign Network, può seguire
due modalità alternative:
-
ottenere un Co-located CoA tipicamente mediante DHCP o PPP
e quindi registrarsi (direttamente o tramite il Foreign Agent)
presso il suo Home Agent comunicando il suo Co-located CoA, e
quindi la sua posizione;
-
in seguito all'ascolto (o alla sollecitazione) degli Agent
Advertisement del Foreign Agent, registrarsi presso quest'ultimo,
comunicandogli quindi la sua presenza; il Foreign Agent
comunica quindi all'Home Agent del Nodo Mobile la presenza di
quest’ultimo presso la sua Foreign Network, insieme al Foreign
Agent CoA (ovvero uno dei suoi indirizzi, a cui riceverà il
traffico destinato al Nodo Mobile).
I pacchetti IP inviati al Nodo Mobile, da parte di nodi corrispondenti, seguono
l'instradamento classico e quindi pervengono all'Home Network; quando questo si
34
trova presso una Foreign Network, i pacchetti sono intercettati dall'Home Agent e
inoltrati al Nodo Mobile mediante un tunnel che parte dall'Home Agent e termina
nella Foreign Network (esattamente al Co-located CoA, nel caso il Nodo Mobile ne
abbia uno o in alternativa al Foreign Agent che provvederà poi ad inoltrare il
traffico al Nodo Mobile).
Figura 2.10 – Instradamento dati in Mobile IPv4
Nella direzione opposta, i pacchetti IP inviati dal Nodo Mobile sono consegnati alla
loro destinazione usando i meccanismi standard di instradamento di IP e non
passano attraverso l'Home Agent.
Per il funzionamento di Mobile IP vengono scambiati una grande varietà di
messaggi di segnalazione; a questo scopo Mobile IP sfrutta sia messaggi ICMP []
(RFC 1256), inviati periodicamente dai Mobile Agents sui link a cui sono collegati,
sia pacchetti UDP inviati alla porta 434 dei Mobility Agents.
Per svolgere le procedure di registrazione vengono invece inviati degli opportuni
pacchetti IP, usando il protocollo di trasporto UDP.
Il problema principale in una situazione del genere è la velocità con cui avviene
l’handover a livello 3 della pila OSI. Più veloce sarà questo processo, meno
pacchetti andranno persi o dovranno essere ritrasmessi e più tipi di applicazioni
potranno essere supportate, comprese quelle con esigenze più stringenti in termini
35
di latenza e di perdita di pacchetti come streaming video, video conferenza, voce su
IP.
Con Mobile IPv4 la latenza nell’handover L3 si aggira intorno agli 8 secondi [24],
un tempo troppo alto per diverse applicazioni. Inoltre MIPv4, per poter funzionare,
prevede l’introduzione di un Foreign Agent in ogni rete visitata.
Mobile Internet sta ormai diventando una realtà e sempre di più lo sarà nei prossimi
anni. La necessità di dover assegnare nuovi indirizzi IP ai nodi mobili oltre alle
sempre maggiori esigenze di supporto alla mobilità stanno spingendo l’introduzione
del protocollo IPv6 [14].
0
4
Version
12
16
24
Traffic Class
31
Flow Label
Payload Lenght
Next Header
Hop Limit
Source Address
(128 bit)
Destination Address
(128 bit)
Figura 2.11 – Struttura dell’ Header IPv6
36
0
4
Version
8
IHL
16
Type-of-Service
Identification
TTL
19
31
Total Lenght
Flag
Protocol
Fragment Offset
Header Checksum
Source Address (32 bit)
Destination Address (32 bit)
Figura 2.12 – Struttura dell’Header IPv4
Lo spazio di indirizzamento di 128 bit consente una disponibilità pressoché
illimitata di indirizzi; IPv6 è stato inoltre pensato per supportare la mobilità, tramite
una serie di meccanismi nativi, come il Neighbor Discovery e l’autoconfigurazione
stateless dell’indirizzo di rete. Quest’ultimo meccanismo è forse il più importante,
in quanto permette al nodo che si attacca ad una rete IPv6 di formare il proprio
indirizzo sulla base del prefisso di rete mandato con regolarità in multicast da un
router della rete; la parte host dell’indirizzo viene formata sulla base dell’indirizzo
MAC della scheda di rete, consentendo quindi la creazione di un indirizzo IPv6
unico. Questo meccanismo è senza dubbio più performante rispetto al tradizionale
DHCP in quanto l’indirizzo non deve essere negoziato tra il nodo e il server, ma
viene formato direttamente ed autonomamente dal nodo stesso.
Sulla base di queste premesse, la scelta del protocollo per la gestione della
macromobilità tra reti di accesso eterogenee è caduta su Mobile IPv6 (MIPv6) [17].
Con l’adozione di MIPv6 non vi è più bisogno dei Foreign Agent. Ne segue che la
Visited Network non deve essere necessariamente a conoscenza del fatto che al suo
interno si trovano in visita dei terminali mobili, poiché la mobilità è gestita dai
terminali mobili stessi.
Un altro punto a favore di Mobile IPv6 è la possibilità di sfruttare efficientemente le
cosiddette “Destination Option” incluse nel protocollo IPv6. Tali informazioni
possono essere incluse alla fine di ogni pacchetto IPv6 e vengono esaminate
solamente dal destinatario del pacchetto. Quindi non c'è bisogno di inviare degli
37
appositi pacchetti ai nodi interlocutori per trasmettere i “Binding Update”, ma le
stesse informazioni possono essere incluse alla fine di un qualsiasi pacchetto
scambiato tra i due nodi (ad esempio quello relativo ad un pacchetto di
Acknowledgment del protocollo TCP).
2.3.1.1 – Differenze tra Mobile IPv4 e Mobile IPv6
Per valutare la reale efficienza e i benefici legati all’utilizzo di MIPv6, a seguire
sono schematizzate le differenze che esistono tra questo e MIPv4:
• Mobile IPv4 fa uso del Foreign Agent (FA) per inoltrare il traffico richiedendo
un Care of Address per stazioni mobili multiple, o più semplicemente utilizza il CoLocated Care of Address. Mobile IPv6 supporta solo Co-Located Care of Address.
Ciò rende MIPv6 molto poco invasivo; una sua diffusione potrà quindi risultare più
semplice.
• Route optimization è un’aggiunta su Mobile ipv4, mentre è nativo di Mobile
IPv6.
• La route optimization in MIPv4 richiede ancora che il traffico sia tunnelato tra
Correspondent Node e Mobile Node passando attraverso l’Home Agent; in MIPv6 i
pacchetti possono essere inoltrati senza tunnel, con la sola aggiunta del routing
header. La route optimization in MIPv4 aumenta la complessità dell’HA.
• Il Nodo Mobile in MIPv6, inoltre, ha più controllo sulla route optimization
dell’HA, rendendo questo più semplice.
• In MIPv4 il Care of Address è ottenibile dal Foreign Agent o attraverso un
DHCPv4. In MIPv6 l’indirizzo può essere ottenuto attraverso i meccanismi di
configurazione stateless o stateful.
• In MIPv4, sono necessari specifici messaggi mobile IP per comunicare con FA,
HA o CN. In MIPv6 i suddetti messaggi sono integrati nei pacchetti dati
(piggybacking).
38
• Il supporto smooth handover in MIPv4 è un’aggiunta nel protocollo di route
optimization. In MIPv6 il supporto è una parte integrante delle specifiche.
• MIPv4 fornisce i suoi meccanismi di sicurezza mentre MIPv6 utilizza il
protocollo IPsec [20].
2.3.1.2 - Il Nodo Mobile ed i suoi indirizzi
Ogni nodo è sempre identificabile dal suo Home Address, a prescindere dal suo
attuale punto d’accesso ad Internet, sia esso sul proprio Home Link, che in uno
Visited.
Quando il Nodo Mobile si trova nell’Home Link, i pacchetti a lui indirizzati sono
consegnati mediante i normali meccanismi di routing. Quando il Nodo Mobile si
trova in un Visited Link, è identificabile tramite uno o più CoA (CoA), oltre che dal
suo Home Address.
Figura 2.13 – Il Nodo Mobile si trova nella Home Network
Un CoA è un indirizzo IP associato al Nodo Mobile quando si trova in una
particolare Visited Link. Il Subnet Prefix del CoA del Nodo Mobile è quello (o sono
quelli) della rete Visited che ospitata il Nodo Mobile.
39
Quando il Nodo Mobile si trova lontano da casa, i pacchetti a lui indirizzati
verranno incapsulati e correttamente recapitati tramite il CoA sul Visited Link.
La novità rispetto ad IPv4 consiste nel fatto che il CoA, necessario all'instradamento
verso una Visited Network, è stato pensato in modo tale da non far percepire la
mobilità ai livelli più alti: il movimento del Nodo Mobile risulta così trasparente ad
i protocolli di strato superiore ed alle applicazioni. I pacchetti indirizzati al Nodo
Mobile tramite l’Home Address, sono incapsulati al CoA in maniera trasparente.
L'associazione tra Home Address e CoA primario di un Nodo Mobile è detta
“Binding”. Il Nodo Mobile acquisisce il suo CoA mediante Autoconfigurazione
Stateless o Stateful (a seconda del metodo di Neighbor Discovery utilizzato), o
anche con Pre-Assegnazione Statica da parte del proprietario o del gestore della rete
visitata.
Quando si trova in una rete “Visited”, il Nodo Mobile registra uno dei suoi CoA su
di un router del suo Home Link, chiedendogli di funzionare da proprio Home
Agent. Tale registrazione è effettuata dal Nodo Mobile spedendo all’Home Agent
un pacchetto contenente una Binding Update Destination Option, richiedendone un
ack.
Figura 2.14 – Il Nodo Mobile si sposta nella rete Visited e manda la Binding Update all’Home Agent
L’Home Agent risponde al Nodo Mobile mandando a sua volta un pacchetto,
contenente una Binding Acknowledgement Destination Option. Il CoA registrato
40
presso il proprio Home Agent è detto “Primary”. Da questo momento in poi,
l’Home Agent del Nodo Mobile usa “Proxy Neighbor Discovery” per intercettare
qualunque pacchetto indirizzato all’Home Address (o agli Home Address) del Nodo
Mobile nel proprio Home Link, per instradarli al Primary CoA del Nodo Mobile
usando l’incapsulamento IPv6 con l’Header più esterno indirizzato al Primary CoA
del Nodo Mobile.
Figura 2.15 – Il traffico inviato al MN nella Home Network viene inoltrato dall’HA al CoA
Prima di spedire un pacchetto ad un Nodo Mobile, il nodo interlocutore controlla se
nella sua Binding Cache c’è una “Entry” (ovvero una riga di registrazione) per la
destinazione del pacchetto. Se la trova, il nodo mittente usa IPv6 Routing Header
(invece dell’incapsulamento IPv6) per instradare il pacchetto al Nodo Mobile
mediante il CoA indicato nel Binding. Se il nodo sorgente non ha la Binding
memorizzata per quella destinazione, invia il pacchetto normalmente (senza
Routing Header). Successivamente il pacchetto viene intercettato e instradato
dall’Home Agent del Nodo Mobile come descritto.
Quando il pacchetto, triangolato dall’Home Agent,
arriva al Nodo Mobile,
quest’ultimo invia una Binding Update anche al Correspondent Node. Il CN, se ha
funzionalità Mobile IPv6, inserirà nella sua cache il Binding Home Address-CoA
per quel Nodo Mobile e trasmetterà i dati successivi direttamente al CoA.
41
Figura 2.16 – Il MN invia una BU al CN; il trasferimento dati prosegue nella rete Visited
Grazie al Binding con i CoA del Nodo Mobile, si ottiene un instradamento
efficiente tra il nodo interlocutore ed il Nodo Mobile. Inoltre, indirizzando i
pacchetti direttamente al CoA, si eliminano i problemi di congestione nell’Home
Agent e nell’Home Link del Nodo Mobile.
Inoltre l’impatto di possibili fallimenti dell’Home Agent, o dell’Home Link, o di
altre reti coinvolte nell’ invio o ricezione da o verso l’Home Link, è ridotto proprio
perché tali nodi non sono coinvolti nella consegna di gran parte dei pacchetti
destinati al Nodo Mobile.
2.3.1.3 – Strutture dati degli Host.
Uno dei principi alla base di IPv6 è che gli host devono poter funzionare
correttamente pur avendo una visione molto limitata della rete (infatti, a differenza
dei router, non sono sede di Tabelle di Instradamento).
Questo vuol dire che al momento dell'avvio del sistema essi devono
autoconfigurarsi e quindi apprendere un insieme minimo d’informazioni relative
alle destinazioni con cui scambiano dati.
Tali informazioni vengono memorizzate all'interno di Cache le cui Entry hanno una
validità temporale limitata: la Binding Cache, la Binding Update List e l’Home
Agent List.
42
-
La “Binding Cache” è mantenuta da ogni nodo IPv6 e contiene Binding per
altri nodi.
Home Address
Care of Address Lifetime
Prefix Lenght
Max Seq Number
Figura 2.17 – Struttura della Binding Cache
Quando si invia un pacchetto, il mittente ricerca l'indirizzo IP del
destinatario prima nella Binding Cache e successivamente nella Destination
Cache. Questo perché qualsiasi riga della prima dovrebbe avere precedenza
su qualsiasi altra riga della seconda per la stessa destinazione.
Una Entry nella Binding Cache di un nodo per il quale il router sta
funzionando da Home Agent è segnata come riga “Home Registration" e
non dovrebbe essere cancellata dall' Home Agent per tutto il suo ciclo di
vita.
Ogni Entry contiene l’Home Address ed il CoA del Nodo Mobile, il Lifetime
ed altri campi. In generale, qualsiasi Binding Cache può contenere al
massimo una riga per ogni Home Address.
-
La “Binding Update List” è propria di ogni Nodo Mobile e contiene
informazioni relative alle Binding Update inviate.
IPv6 dest.
Home
addr.
Addr.
CoA
Lifetime
Max Seq
Tempo invio
Stato di
Num
ultima BU
ritrasmiss
Err.
Figura 2.18 – Struttura della Binding Update List
In particolare se un Nodo Mobile riceve un messaggio di errore in risposta
ad una Binding Update inviata, setta il flag nella corrispondente riga della
lista delle Binding Update.
43
Ogni Entry contiene l’Indirizzo IP di destinazione, l’Home Address, il CoA
del Nodo Mobile ed altri campi.
-
L' “Home Agent List” è mantenuta da ogni router funzionante da Home
Agent, e contiene informazioni relative a tutti gli altri Home Agent presenti
nel Link.
IPv6 Addr.
Link layer
on-link
Addr.
Flag Router
Puntatore a pacchetti in
Info di stato
coda di trasmissione
Figura 2.19 – Struttura dell’ Home Agent List
In particolare viene utilizzata per la “Scoperta Dinamica dell'indirizzo IP
dell'Home Agent” e viene determinata tramite la ricezione periodica di
Router Advertisement nel quale l'Home Agent Bit è settato ad “1”.
La priorità degli Home Agent nella lista è ottenuta tramite il valore del
campo “Preference” nell'Home Agent Information Option, ricevuta con il
Router Advertisement.
2.3.1.4 – Extension Header ed Opzioni di Binding.
Le informazioni necessarie al supporto della mobilità degli host IPv6 vengono
scambiate tramite quattro nuove opzioni, espressamente definite per MobileIPv6,
che vengono inserite in un Extension Header di tipo Destination Option. Poiché un
Extension Header di tipo Destination Option può far parte di qualsiasi pacchetto
IPv6, le opzioni per la mobilità possono essere associate sia a normali pacchetti
IPv6 contenenti payload quali TCP o UDP, sia a pacchetti indipendenti, contenenti
unicamente le opzioni. In questo secondo caso, il campo Next Header del
Destination Option Header deve essere posto uguale a “59”, per indicare l’assenza
di ulteriori Header.
Le opzioni sono tutte codificate secondo il formato TLV (Type, Lenght, Value).
I pacchetti che includono queste opzioni, devono anche includere come Extension
Header, l’Encrypted Security Payload (ESP) o l’Authentication Header (AH) per
44
provvedere all'autenticazione del mittente, alla protezione, all'integrità dei dati e alla
protezione della risposta.
Le opzioni aggiuntive per la gestione della mobilità in IPv6 sono:
•
La “Binding Update Option” è utilizzata dal Nodo Mobile per notificare al
suo interlocutore, oppure all'Home Agent, il proprio CoA. Il campo Option
Type è grande 8 bit e contiene la lunghezza, in Byte, dell’opzione (esclusi i
campi Option Type e Lenght).
Il flag “A”, di Acknowledgment, esplicita la richiesta dell’invio di una
Binding Acknowledgement da parte del nodo interlocutore.
0
1
A H
2
C
3
7
Reserved
Prefix
15
23
Option Type
Option Lenght
31
Sequence Number
Lenght
Lifetime
Care of Address
(presente solo se il bit C è settato ad 1)
Sub-Option
Figura 2.20 – Binding Update Option
Il flag “H”, di Home Registration, esplicita la richiesta di funzionamento da
proprio Home Agent verso un Router del proprio Home Link. La Binding
Update inviata dall’Home Agent del Nodo Mobile per registrare il suo
Primary CoA, viene marcata come “Home Registration”.
Il campo Lifetime contiene l’intervallo di validità, in numeri di salti,
dell’informazione di Binding.
Il campo CoA contiene l’indirizzo a 128 bit acquisito dal Nodo Mobile sulla
Foreign Network. Se tale campo è uguale all’Home Address, vuol dire che il
45
Nodo Mobile è rientrato nel proprio Home Network per cui dovranno essere
cancellate le informazioni per quel Binding presenti nella Binding Cache.
Tutti i pacchetti che includono una Binding Update Option devono essere
protetti da IPsec.
•
La “Binding Acknowledgement Option ” (in figura) è utilizzata
per
confermare la ricezione di una Binding Update, se il riconoscimento era
stato richiesto esplicitamente settando il bit “A”. Il campo Refresh contiene
il periodo di tempo trascorso il quale il Nodo Mobile deve inviare un
messaggio di Binding Update per aggiornare, appunto, l’informazione nella
Binding Cache.
0
8
16
24
31
Option Type
Option Lenght
Status
Sequence Number
Lifetime
Refresh
Sub-Option
Figura 2.21 – Binding Acknowledgment Option
Il campo Status, a seconda del valore che assume, indica se l’opzione è stata
accettata o rifiutata, ed eventualmente perché.
Anche i pacchetti che includono una Binding Acknowledgement Option
devono essere protetti da IPsec.
•
La “Binding Request Option” è usata da un nodo interlocutore per
richiedere al Nodo Mobile di inviargli una Binding Update contenente il
proprio attuale Binding.
46
0
8
16
Option Type
Option Lenght
Sub Option
24
31
Figura 2.22 – Binding Request Option
Con questa opzione il nodo interlocutore aggiorna, nella propria Binding
Cache, la Entry relativa al Nodo Mobile, prima che termini il Binding
Lifetime. Non è richiesta autenticazione in questa opzione.
•
La “Home Address Option” è usata nei pacchetti spediti dal Nodo Mobile
per informare il destinatario del pacchetto, del proprio Home Address. Per
pacchetti inviati quando si trova lontano da casa, il Nodo Mobile
generalmente usa uno dei suoi CoA come Source Address nell’Header del
pacchetto. Inserendo questa opzione nel pacchetto, il nodo destinatario è in
grado di sostituire quel CoA con l’Home Address del Nodo Mobile,
rendendo l’uso del CoA trasparente al nodo destinatario.
0
16
24
Option Type
Option Lenght
31
Home Address
Sub-Option
Figura 2.23 – Home Address Option
L’autenticazione è richiesta solo se anche l’Header del pacchetto contenente
l’Home Address Option è protetto.
47
2.3.1.5 – Ingress Filtering ed Home Address Destination Option.
Quando un Nodo Mobile che si trova lontano da casa spedisce un pacchetto,
generalmente setta il Source Address nell’Header IPv6 con uno dei suoi CoA, ma
include anche una Home Address Destination Option, specificando l’Home Address
del Nodo Mobile, così da poter essere identificato con il suo indirizzo originale.
Sarà il nodo destinatario (e solo lui) a processare tale opzione e ricostruire
l’indirizzo del mittente sul suo Home Link.
Infatti molti router implementano politiche di sicurezza come “Ingress Filtering,”
che impediscono l’inoltro di pacchetti con un Source Address non topologicamente
corretto.
Usando il CoA come IPv6 Header Source Address, il pacchetto potrà passare anche
attraverso questo tipo di router, mentre l’Ingress Filtering consente la localizzazione
della vera origine topologica del pacchetto, come se il pacchetto non fosse
provenuto da un nodo in movimento.
Includendo in ciascun pacchetto l’Home Address Option, il Nodo Mobile mittente
può comunicare il proprio Home Address al nodo destinatario, rendendo l’uso del
CoA trasparente agli strati di trasporto ed ai livelli superiori.
2.3.1.6 – Compiti dell'Home Agent.
Quando un router sta svolgendo la funzione di Home Agent per un Nodo Mobile,
deve tentare di intercettare i pacchetti sull'Home Link a lui indirizzati (se in
movimento) e deve inoltrarli al Nodo Mobile usando l'Incapsulamento IPv6.
L'Home Agent, infatti, non può utilizzare semplicemente un Routing Header perché
non può modificare il pacchetto “in volo” senza invalidare gli Header ESP o AH.
Il punto di entrata del tunnel è l'Home Agent e quello di uscita il Primary CoA.
Quando un Home Agent incapsula un pacchetto per inviarlo al Nodo Mobile,
aggiorna l'indirizzo IP sorgente nell'Header del pacchetto col proprio indirizzo IP di
Home Agent e l'indirizzo IP di destinazione dell'Header con il CoA primario del
Nodo Mobile. All'arrivo, il pacchetto verrà decapsulato e successivamente
processato.
48
2.3.1.7 – Dynamic Home Agent Address Discovery.
Mobile Ipv6 definisce due nuovi tipi di messaggi ICMP IPv6 da usare nel
meccanismo di Dynamic Home Agent Address Discovery (ovvero Scoperta
Dinamica dell’Indirizzo IP dell'Home Agent):
•
Home Agent Address Discovery Request: viene usato dal Nodo Mobile per
avviare il meccanismo di Scoperta Dinamica dell’Indirizzo dell’Home
Agent. Quando deve effettuare la registrazione nel suo Home Link, il Nodo
Mobile può usare questo meccanismo per scoprire l’indirizzo di uno o più
router, che in quel momento stanno funzionando come Home Agent su quel
Link, con cui registrarsi mentre è lontano da casa;
•
Home Agent Address Discovery Reply: viene usato dall’Home Agent per
rispondere al messaggio di richiesta del Nodo Mobile. Contiene una lista dei
router presenti nel Home Link del Nodo Mobile, che funzionano da Home
Agent.
Potrebbe capitare che mentre il Nodo Mobile si trova lontano da casa, alcuni nodi
sul suo Home Link vengano riconfigurati, cosicché il router che stava funzionando
da Home Agent per il Nodo Mobile venga rimpiazzato da un router differente, che
lo sostituisce. In questo caso, il Nodo Mobile potrebbe non conoscere l’indirizzo IP
del suo Home Agent.
Tramite il meccanismo di Dynamic Home Agent Address Discovery il Nodo Mobile
riesce a scoprire dinamicamente l’indirizzo IP, sul proprio Home Link, dell’Home
Agent con il quale è registrato il proprio CoA.
Il meccanismo prevede l'invio, da parte del Nodo Mobile, della “Home
Registration” all’interno della Binding Update, indirizzata in maniera anycast agli
Home Agent con l’Home Subnet Prefix IPv6 del nodo.
La Binding Update raggiunge uno dei possibili router sull’Home Link che funziona
da Home Agent, il quale rifiuta la richiesta, e rispondere inserendo nella Binding
Acknowledgment una lista di tutti gli Home Agent attivi su quel Link.
49
Il Nodo Mobile può allora scegliere se rinviare la Binding Update all'indirizzo IP
dell’Home Agent che ha risposto, oppure verso uno qualsiasi degli indirizzi unicast
presenti nella lista degli Home Agent.
L'operazione viene ripetuta fino a quando uno degli Home Agent non accetta
l’“Home Registration” per quel Nodo Mobile, dedicandogli una nuova riga nella
Binding Cache e diventando suo Home Agent. L'Home Agent, per indicare che sta
funzionando da Home Agent per quel nodo, dovrà settare il bit “H”, di Home
Registration nei messaggi di Router Advertisement inviati in maniera multicast.
2.3.1.8 – Ricezione di pacchetti da un Nodo Mobile.
I pacchetti spediti dal Nodo Mobile quando si trova lontano da casa, generalmente
contengono una Home Address Option.
Il nodo destinatario, ricevuto il pacchetto, deve processare tale opzione copiando il
valore del campo Home Address Option nell’Header IPv6, sostituendo il valore
originale del campo Source Address. Qualunque altra opzione contenuta nella stessa
Destination Option nell’Extension Header deve essere completata prima di
qualunque modifica al campo Source Address. Infatti, successivi processamenti del
pacchetto, per esempio a livello di strato di trasporto, non necessitano di sapere che
il valore iniziale del Source Address era un CoA oppure che nel pacchetto era stata
usata l’Home Address Option.
2.3.1.9 – Invio di un pacchetto ad un Nodo Mobile.
Quando un pacchetto deve essere inviato ad un Nodo Mobile, il nodo mittente deve
prima verificare se esiste una Entry, con l'indirizzo IP di destinazione di quel nodo,
all’interno della propria Binding Cache.
Si possono verificare le seguenti casistiche:
Se questa Entry già esiste, il nodo mittente può usare direttamente una Routing
Header per instradare il pacchetto al Nodo Mobile, utilizzando come indirizzo IP di
destinazione il CoA indicato nella Entry.
50
0
8
Next Header
16
Hdr Ext Lenght
Reserved
24
Router Type
31
Segment Left
Strict/Loose Bit Map
Home Address
Figura 2.24 – Routing Header
Per esempio, ipotizziamo di usare una Routing Header di tipo 0; se non è richiesto
altro uso della Routing Header per il routing del pacchetto, il nodo mittente setta i
campi dell’Header IPv6 del pacchetto in questa maniera:
Il campo Destination Address dell’Header IPv6 del pacchetto viene riempito con il
valore del CoA del Nodo Mobile presente nella corrispondente Entry della Binding
Cache;
Il Routing Header viene inizializzato per contenere un singolo Route Segment, con
un indirizzo corrispondente all’Home Address del Nodo Mobile (ovvero l’indirizzo
originale a cui il pacchetto doveva essere spedito).
A questo punto, il pacchetto viene instradato al CoA del Nodo Mobile.
Quando il pacchetto arriva a destinazione, il Nodo Mobile procede al normale
processamento del Routing Header e determina che il pacchetto è indirizzato
proprio a lui, tramite l’Home Address.
Il Nodo Mobile scambia l’indirizzo IP di destinazione nell’Header IPv6 del
pacchetto con l’indirizzo IP specificato nel Routing Header (in questo modo il CoA
rimane trasparente ai livelli superiori, che così non percepiscono la mobilità).
Il Nodo Mobile ripropone continuamente (“Looping Back”) il pacchetto al proprio
modulo IPv6 per ulteriori processamenti. Quando riconosce il proprio Home
Address come uno dei suoi indirizzi IP, il pacchetto viene processato nuovamente,
esattamente come se si trovasse a casa nell’Home Link.
Se il nodo mittente non ha una Entry nella Binding Cache per l'indirizzo IP di
destinazione del pacchetto, allora il pacchetto viene spedito normalmente, senza
Routing Header, all'Home Address del Nodo Mobile. Se il destinatario è un Nodo
51
Mobile lontano da casa, in un Visited Link, allora il pacchetto sarà intercettato,
sull’Home Link del Nodo Mobile, dal suo Home Agent e quindi inoltrato
(utilizzando l’Incapsulamento IPv6) al Primary CoA corrente. Il Nodo Mobile, a
ricezione avvenuta, invierà una Binding Update al nodo mittente per creare una riga
nella sua Binding Cache da utilizzare per indirizzare i pacchetti successivi destinati
a quel Nodo Mobile.
Se la destinazione è un nodo normale oppure un Nodo Mobile che si trova a casa,
nell’Home Link, il pacchetto verrà consegnato direttamente e processato
normalmente.
2.3.1.10 – Invio di pacchetti da un Nodo Mobile.
Quando un Nodo Mobile è lontano da casa, in un Visited Link, continua ad usare il
proprio Home Address assieme ad uno o più CoA.
Il Nodo Mobile generalmente usa il proprio Home Address come indirizzo sorgente
del pacchetto, anche se si trova in una rete visited, proprio perché Mobile IPv6 è
strutturato per rendere la mobilità trasparente alle applicazioni ed ai nodi
interlocutori, con i quali deve scambiare traffico; esattamente come per i pacchetti
spediti per l’instaurazione della connessione a livello superiore di trasporto.
In alcuni casi particolari, soprattutto per comunicazioni che possono facilmente
essere ritrasmesse in caso di fallimento, il Nodo Mobile può scegliere di usare
direttamente il proprio CoA come indirizzo sorgente del pacchetto.
Per pacchetti spediti dal Nodo Mobile quando si trova a casa, nell’Home Link, non
sono richiesti particolari processamenti Mobile IPv6.
Analogamente, se il Nodo Mobile, quando si trova lontano da casa, utilizza indirizzi
diversi dal proprio Home Address come indirizzo sorgente, non sono richiesti
particolari processamenti Mobile IPv6 per l’invio di pacchetti.
In tutti gli altri casi (per esempio pacchetti spediti dal Nodo Mobile quando si trova
lontano da casa con l’Home Address, visto dai protocolli di strato superiori, come
indirizzo sorgente) è richiesto un particolare processamento Mobile IP del pacchetto
per l’inserimento dell’Home Address Option.
In particolare:
52
•
il pacchetto viene costruito usando l’Home Address del Nodo Mobile come
Source Address;
•
viene inserita nel pacchetto una Home Address Option con il campo Home
Address copiato dal valore originale del campo Source Address;
•
viene sostituito il campo Source Address nell’Header IPv6 del pacchetto con
uno dei CoA del Nodo Mobile.
Usando il CoA come Source Address nell’Header IPv6 con l’Home Address del
Nodo Mobile invece dell’Home Address Option, il pacchetto sarà in grado di
superare qualunque filtro di ingresso implementato dai router.
2.3.1.11 – Rilevazione del movimento.
Un Nodo Mobile può utilizzare tutti i meccanismi a sua disposizione per rilevare il
suo stesso spostamento da un Link ad un altro.
Il meccanismo principale, specifico per Mobile IPv6, usa le semplificazioni di IPv6
Neighbor Discovery, incluso Router Discovery e Neighbor Unreachability
Detection, sebbene il Nodo Mobile possa supplire a questi meccanismi con altre
informazioni disponibili (per esempio dai protocolli di strato inferiore).
I nodi mobili usano Router Discovery per scoprire nuovi router e Subnet Prefix che
sono on-Link. Un Nodo Mobile può inviare messaggi di Router Solicitation oppure
attendere i periodici messaggi di Router Advertisement indirizzati in maniera
multicast. Basandosi sul ricevimento di tali messaggi, un Nodo Mobile, come un
qualunque altro nodo non mobile, conserva una Entry nella sua Default List Router
per ogni router, ed un’altra Entry nella Prefix List per ogni Subnet Prefix che si
trova attualmente su quel Link. Ciascuna di queste Entry ha associato un intervallo
di validità (“Lifetime”), specificato nei Router Advertisement e nei Prefix
Information Option
Quando il Nodo Mobile si trova lontano da casa seleziona uno tra i router presenti
nella sua Default Router List, da usare come Default Router, ed un Subnet Prefix,
scelto dalla Prefix List di quel router, da usare come Subnet Prefix per il suo
Primary CoA.
Ad un Nodo Mobile possono anche essere associati altri CoA aggiuntivi, con altri
Subnet Prefix.
53
Infatti, quando un Nodo Mobile si trova lontano da casa e sta usando un Default
Router, è importante che sia in grado di riconoscere velocemente quando questo
router diventa irraggiungibile, così da spostarsi su un altro Default Router ed
ottenere un nuovo Primary CoA.
Fintanto che il router spedisce periodicamente, senza richiesta, messaggi multicast
di Router Advertisement, il Nodo Mobile avrà modo di controllare se è ancora
raggiungibile dal suo Default Router, anche in mancanza di altri pacchetti a lui
esplicitamente indirizzati. Se tale procedura non riuscisse ad indicare che il Nodo
Mobile è ancora raggiungibile dal suo Default Router (cioè il Nodo Mobile non
riceve pacchetti dal router per un certo periodo di tempo), allora il Nodo Mobile
potrebbe tentare di trovare il router mediante messaggi di Neighbor Solicitation.
2.3.1.12 – Formazione ed uso del Care of Address.
Quando il Nodo Mobile ha rivelato il suo spostamento da un link ad un altro (il suo
Default Router è diventato irraggiungibile ed il Nodo Mobile ne ha identificato uno
nuovo), forma un nuovo Primary CoA usando uno dei Subnet Prefix, segnalati dal
nuovo router, su quel link.
Il Nodo Mobile può formare in qualunque momento un nuovo Primary CoA, ma
non troppo frequentemente. Inoltre, dopo aver scoperto un nuovo Subnet Prefix su
quel link, il Nodo Mobile può formare anche un altro CoA (non primario) usando
quel Subnet Prefix, anche se non ha ancora cambiato Default Router. Un Nodo
Mobile può avere un solo Primary CoA per volta, registrato con il suo Home Agent,
ma, in aggiunta, può avere un altro CoA per ciascun prefisso del link in cui si trova.
Siccome un’interfaccia di rete wireless può consentire al Nodo Mobile di essere
raggiungibile su più di un link per volta, il Nodo Mobile può anche avere più di un
CoA per link contemporaneamente.
Per poter formare un nuovo CoA, un Nodo Mobile può utilizzare entrambi i
meccanismi di Autoconfigurazione degli indirizzi, sia quello Stateless che Stateful
(per esempio DHCPv6).
54
Dopo aver formato un nuovo CoA, il Nodo Mobile verifica, tramite Duplicate
Address Detection, che il nuovo indirizzo sia effettivamente unico. Ciò rappresenta
un compromesso tra sicurezza, perché garantisce che il nuovo indirizzo non sia già
assegnato, e overhead, perché richiede l’invio di uno o più pacchetti aggiuntivi.
Inoltre, l’impiego di Duplicate Address Detection in generale, ritarda la
disponibilità del nuovo CoA, causando una potenziale impossibilità per il Nodo
Mobile di proseguire la comunicazione con il nodo interlocutore per un certo
intervallo di tempo. Per tutte queste ragioni, il Nodo Mobile può iniziare ad
utilizzare il nuovo CoA senza effettuare Duplicate Address Detection.
Altri CoA precedentemente acquisiti possono essere conservati per permettere al
Nodo Mobile di continuare a ricevere pacchetti indirizzati ad i precedenti CoA,
ovvero a precedenti posizioni.
Inoltre, l’uso di più CoA può essere utile per migliorare lo “Smooth Handoff”
(passaggio morbido) del Nodo Mobile quando si sposta da una rete wireless ad
un’altra, in cui il Nodo Mobile può decidere di configurarsi sulla cella da cui riceve
il segnale alla massima potenza, ma continuare a ricevere i segnali anche da altre
cella che precedentemente lo avevano servito.
Se delle reti wireless sono collegate ad Internet attraverso Stazioni Base diverse, ma
con copertura comune, il Nodo Mobile potrebbe non essere in grado di rimanere
connesso ad entrambe le reti all’interno della area di copertura. In questo caso, il
Nodo Mobile può acquisire un nuovo CoA nel nuovo link prima di uscire dalla
copertura del vecchio Link (e quindi venire disconnesso). Il Nodo Mobile può
quindi accettare pacchetti dai suoi vecchi CoA mentre aggiorna il suo Home Agent,
notificando ai nodi interlocutori il nuovo CoA sul nuovo Link.
Il Nodo Mobile seleziona un Primary CoA tra quelli che ha creato con questi Subnet
Prefix, basati sull’uso del meccanismo di rivelazione del movimento. Quando un
Nodo Mobile sceglie il nuovo Primary CoA, lo registra presso il suo Home Agent
spedendogli una Binding Update Option con settati i bit “A” di Acknowledgment e
quello “H” di Home Registration.
Per facilitare lo Smooth Handoff, il Nodo Mobile conserva il precedente Primary
CoA come CoA, non più Primario, e continua ad accettare i pacchetti con
quell’indirizzo di destinazione, anche dopo aver registrato il nuovo Primary CoA
con il suo Home Agent. Se il precedente Primary CoA era stato assegnato tramite
55
Auto-Configurazione degli indirizzi di tipo Stateful, il Nodo Mobile potrebbe non
voler rilasciare subito l’indirizzo quando cambia Primary CoA.
2.3.1.13 – Ritorno a casa.
Un Nodo Mobile riconosce che è tornato al suo Home Link attraverso l'Algoritmo
di riconoscimento del movimento in uso, in quanto riconosce che l’Home Subnet
Prefix è nuovamente on-Link.
Allora, il Nodo Mobile invia una Binding Update al suo Home Agent per avvertirlo
di non funzionare più da proprio Home Agent, ovvero di non intercettare e
“tunnellare” più pacchetti per suo conto.
In questa Binding Update il Nodo Mobile:
o setta il Care of Address per il Binding con il proprio Home address
(ovvero riempie il campo Source Address nell’Header del pacchetto
IPv6 con il proprio Home Address), in modo da indicare all’Home
Agent di essere ritornato a casa;
o setta il bit “A”, di richiesta di Acknowledgement, e quello “H” di
Home Registration, come con le analoghe Binding Update inviate
per registrarsi con il proprio Home Agent. Il Nodo Mobile ripete
l’invio di Binding Update finché non riceve una Binding
Acknowledgment dall’Home Agent.
Il Nodo Mobile spedisce la sua Binding Update usando l’indirizzo di strato di
collegamento dell’Home Agent, comunicando all’Home Agent di non svolgere più
questo compito.
L’Home Agent, una volta processata questa Binding Update Option, smette di
proteggere l’Home Address del Nodo Mobile da Duplicate Address Detection e non
risponderà più ai messaggi di Neighbor Solicitation per l’Home Address del Nodo
Mobile. Il Nodo Mobile è il solo su quel link con quel Home Address. Inoltre, una
volta tornato a casa ed aver configurato il proprio Home Address su
quell’interfaccia di rete nel proprio Home Link, il Nodo Mobile non dovrà più
effettuare Duplicate Address Detection sul proprio Home Address, per evitare
56
confusione o conflitti con l’uso, da parte del proprio Home Agent, dello stesso
indirizzo.
Dopo aver ricevuto la Binding Acknowledgement di risposta alla sua Binding
Update, il Nodo Mobile invia un messaggio, indirizzato multicast, di Neighbor
Advertisement con il bit “O” di Override settato ad 1, per indicare a tutti i nodi
registrati nel gruppo multicast su quel Link di aggiornare le informazioni di
neighbor nelle proprie cache. L’operazione deve essere ripetuta per l’Home Address
e per l’indirizzo Link Local.
2.3.1.14 – Interazione con Outbound IPsec Processing.
Il pacchetto viene sempre creato dai protocolli di strato superiore e dalle
applicazioni (come TCP) come se il Nodo Mobile si trovasse a casa, nell’Home
Link e non si utilizzasse Mobile IPv6.
Come caso particolare, se una Binding Update o una Binding Acknowledgement
viene inclusa nel pacchetto, a questo viene applicata l’autenticazione IPsec, la
protezione dell’integrità e la protezione della risposta.
Se viene richiesto il processamento IPsec [20], il pacchetto viene mappato in una
Security Association (SA) già esistente oppure ne viene creata una nuova, a seconda
della procedura definita per IPsec.
Fintanto che il Nodo Mobile si trova lontano da casa, questi inserisce nel pacchetto
una Home Address Option sostituendo il Source Address nell’Header IP con il CoA
riferito al link dal quale il pacchetto è spedito.
L’Header della Destination Option nel quale l’Home Address Option viene inserita,
viene prima, all’interno del pacchetto, del processamento dell’Header AH o ESP,
cosicché l’Home Address Option viene processata dal nodo destinatario prima di
quella AH o ESP.
Una volta assemblato completamente il pacchetto, viene effettuato il necessario
processamento di autenticazione IPsec, inizializzando l’Authentication Data
nell’Header AH o ESP.
57
2.3.2 – Gestione della micromobilità
Tramite il protocollo MIPv6 è possibile abbassare notevolmente il tempo di
handover.
Tuttavia alcune applicazioni, in particolare quelle real time a larga banda,
richiedono tempi di handover L3 molto bassi. A questo scopo negli ultimi tempi
sono allo studio dei protocolli che possono ulteriormente migliorare le prestazioni
del MIPv6, diventando quindi adatti a supportare appieno la micromobilità.
I due principali sono Hierarchical Mobile IPv6 [18] e Fast Handover Mobile IPv6
[19].
2.3.2.1 – Hierarchical Mobile IPv6
HMIPv6 è progettato per minimizzare la segnalazione del mobile verso i CN e
l’HA. L’idea è quella di sfruttare la divisione di Internet in domini amministrativi:
ogni dominio amministrativo si connette ad Internet tramite un MAP (Mobility
Anchor Point). Il MAP è un access-router che si trova al vertice della piramide
gerarchica composta dagli altri access-router per quel dominio.
Figura 2.25 – Hierarchical Mobile IPv6, architettura tipo
58
Quando il MN entra nel dominio effettua una registrazione regionale (ottenendo un
Regional-CoA) mandando i BU ad HA e CN; effettua quindi una registrazione
locale (ottenendo un Local-CoA) utilizzata per gli spostamenti tra AR interni al
dominio. In questo modo tutti gli spostamenti interni al dominio saranno gestiti dal
MAP in maniera totalmente trasparente a HA e CN; questi ultimi continueranno
infatti ad inviare il traffico verso il Regional-CoA, sarà poi il MAP ad inoltrarlo
verso il Local-CoA.
Il protocollo HMIPv6 permette di abbassare i tempi di handover L3 ed è inoltre
scalabile in maniera molto semplice, introducendo più MAP all’interno di un
dominio a differenti livelli gerarchici.
2.3.2.2 – Fast Handover Mobile IPv6
Il protocollo Fast Handover prevede che l’AR attuale offra dei servizi al MN al fine
di avviare l’L3 handover prima che finisca quello L2; esistono due modalità,
anticipated handover e tunnel based handover. Nell’anticipated handover, quando
l’AR riceve un trigger L2 indicante che il MN sta per effettuare un handover, invia
un indirizzo IPv6 valido sia al MN che all’AR della nuova subnet. Se tale indirizzo
è valido, l’AR manderà una conferma al MN. Per minimizzare la perdita di
pacchetti il vecchio AR triangolerà eventuali pacchetti destinati al MN verso il
nuovo AR.
Nel tunnel based handover sono i due AR a creare un tunnel bidirezionale, mentre il
MN effettua solamente un handover L2, continuando ad usare nella nuova subnet il
suo vecchio CoA; solo successivamente, ed in parallelo con la comunicazione,
porterà a termine anche l’handover L3.
59
Capitolo 3 – Integrazione WLAN-UMTS
Capitolo 3
Integrazione WLAN-UMTS
60
3.1 – I vantaggi di una soluzione integrata
L’analisi svolta nel capitolo precedente ha messo in luce i punti deboli delle
tecnologie WLAN ed UMTS, considerate come reti di accesso separate ed
indipendenti.
Sebbene UMTS sia tra le due la tecnologia più matura e possa già di per sé garantire
un accesso mobile a servizi a banda più o meno larga, è proprio per gli operatori 3G
che un’integrazione tra UMTS e WLAN potrebbe essere maggiormente
interessante. Offrire ai propri clienti un accesso a banda larga in zone dedicate
potrebbe essere un valore aggiunto estremamente prezioso, ancor di più in una fase
di lancio che sembra essere più problematica del previsto.
Figura 3.1 – Idea di integrazione WLAN-UMTS
Anche per l’utente i vantaggi sono innegabili: tramite un unico terminale
multimodo potrà spostarsi tra le due reti di accesso, beneficiando della mobilità
globale offerta dall’UMTS e della velocità di trasferimento dati offerta negli hot
spot WLAN. In quest’ottica risulta fondamentale poter offrire agli utenti un
61
passaggio seamless tra le due reti, in modo da non abbattere la connessione nel
momento dell’handover verticale.
Il grande interesse mostrato negli ultimi tempi da parte di tutti gli operatori 3G e
dalle aziende costruttrici di apparati (sia terminali che hardware di rete) per una
soluzione integrata WLAN-UMTS, ha prodotto una serie di studi preliminari di
fattibilità per un’architettura integrata. Anche gli enti di standardizzazione (IEEE,
ETSI BRAN, 3GPP, IETF) si stanno occupando della questione, cercando di
definire modalità comuni per operare l’integrazione.
Nell’analisi dell’integrazione WLAN-UMTS, gli studi di fattibilità tecnica vanno di
pari passo con quelli di opportunità di mercato per una tale soluzione; poiché le due
realtà sono inscindibili, durante questo progetto si è cercato di proporre delle
soluzioni che, sebbene innovative, siano anche effettivamente realizzabili nel breve
periodo, senza rimanere una ricerca tecnologia fine a se stessa.
3.1.1 – Sinergia per WLAN
Un hot spot WLAN, come descritto nel precedente capitolo, può fornire servizi di
connettività a banda larga. Un operatore WLAN (o WISP - Wireless Internet
Service Provider) può beneficiare notevolmente di un’integrazione con le reti 3G, al
fine di superare alcune delle limitazioni insite negli standard WLAN.
Dal nomadismo alla mobilità totale
Un WISP può attrarre nuovi clienti offrendo loro non soltanto connettività di tipo
nomadico negli hot spot, ma anche una mobilità totale tramite un accordo di
roaming con un operatore 3G.
62
Funzionalità di AAA
Gli standard WLAN non prevedono meccanismi nativi di AAA (Authorizing
Authentication Accounting): è pensabile che in uno scenario integrato WLANUMTS si possano sfruttare le solide funzionalità di AAA della rete UMTS.
Load balancing
Poter usufruire di due reti di accesso su cui convogliare i dati da trasmettere ai
propri utenti, potrebbe essere un’opportunità per gestire al meglio il carico delle due
reti, prevedendo funzionalità di load balancing. Nel momento in cui la qualità del
segnale nella rete WLAN stia scendendo sotto una soglia prefissata, si possono
deviare le successive richieste di accesso sulla rete UMTS. Realizzare questa
funzionalità richiede però che ci sia un’entità architetturale che abbia capacità di
gestione su entrambe le reti.
3.1.2 – Sinergia per UMTS
Diverse soluzioni di aumento del bit rate in UMTS sono allo studio in ambito
3GPP; in attesa che diventino realmente implementabili, le reti cellulari di terza
generazione sembrano non poter garantire un vero accesso a banda larga,
specialmente per servizi di tipo real-time.
Studi recenti hanno evidenziato che la spesa aggiuntiva per un operatore 3G relativa
all’adozione di una soluzione integrata, specie se paragonata a quanto è stato speso
per le licenze, è quasi irrisoria e di contro porterebbe entrate notevoli.
63
La vera larga banda
Poter offrire servizi a banda realmente larga negli hot spot WLAN può essere un
valore aggiunto preziosissimo per tutti gli operatori 3G. Già oggi le reti wireless
IEEE 802.11b offrono velocità fino a 11 Mbit/s (throughput reale massimo intorno
ai 5 Mbit/s); nel prossimo futuro offriranno velocità ancora maggiori (54 Mbit/s).
Copertura indoor ed inquinamento elettromagnetico
Le reti WLAN sono senza dubbio più adatte della rete UMTS a coprire gli spazi
indoor; inoltre grazie alla loro bassa potenza irradiata (intorno ai 100mW) possono
fattivamente contribuire all’abbattimento delle emissioni elettromagnetiche in
luoghi ad alta densità di persone.
Servizi locali ed aziendali
L’omogeneità ad Ethernet permette alle WLAN di integrarsi perfettamente con le
reti LAN; ciò consente di diffondere facilmente servizi locali (le ultime offerte in un
centro commerciale, orari dei voli negli aeroporti, etc.) negli hot spot, ulteriore
possibile valore aggiunto per UMTS.
Molte aziende si stanno già in questi mesi dotando di WLAN al loro interno; poter
accedere in maniera wireless alla propria Intranet aziendale sarà un’esigenza sempre
più forte da qui in avanti.
64
3.2 – Verso una rete All-IP
3.2.1 – Il 3.5G
La terza generazione deve ancora partire ufficialmente e già ci sono un certo
numero di studi relativi al 3.5G. La visione predominante è quella di una futura rete
di accesso costituita da varie tecnologie eterogenee; un utente, tramite un terminale
multimodo, potrà rimanere collegato nel passaggio da una rete all’altra.
Proprio prevedendo una molteplicità di reti eterogenee, stanno prendendo piede
interessanti progetti come il MIRAI (Multimedia Integrated network by Radio
Access Innovation) [21] promosso dal governo giapponese. Le soluzioni più
interessanti riguardano l’adozione di una Basic Access Network (BAN) per gestire
tutta la segnalazione e l’handover tra le reti, e l’introduzione di Software Defined
Radio (SDR), ossia di terminali utente dotati di un’unica antenna che, tramite
software, possa operare conformemente ai vari standard di trasmissione.
Il grande successo del protocollo IP e delle reti di trasporto su di esso basate,
porterà con tutta probabilità ad una rete globale All-IP. In questo senso la rete
UMTS, con il suo backbone a commutazione di pacchetto basato su IP, è già
proiettata verso il futuro; quello che accadrà è che anche servizi che al momento
transitano nel Core Network a commutazione di circuito, domani verranno
trasportati su IP, come ad esempio le chiamate vocali tramite il protocollo VoIP
(Voice over IP).
In questo progetto non si poteva non tener conto di questi sviluppi futuri, ed è stato
infatti identificato in IP il livello di integrazione tra le due tecnologie. In questo
modo lo scenario integrato WLAN-UMTS si pone come ponte di collegamento tra
il 3G ed il futuro 3.5G.
65
3.3 – Modelli di integrazione
Le reti mobili future non consisteranno di un’unica semplice tecnologia di accesso
radio, ma ne conterranno diverse. Questo permetterà a ciascuna rete di beneficiare
della capacità e della copertura di ogni altra, ottenendo come risultato alti livelli di
servizio con bassi costi.
Le capacità delle attuali infrastrutture degli operatori di rete si svilupperanno e
saranno parte di questa rete multi-radio, massimizzando l‘uso dei loro investimenti.
Le differenti tecnologie dovranno essere integrate a formare un’unica rete di
accesso, così che l’utente non abbia percezione della tecnologia in uso.
Lo sviluppo delle reti di terza generazione è attualmente in corso. Queste offriranno
un data rate di 2 Mbps a pieno regime. Le WLAN stanno diventando sempre più
popolari e quindi maggiormente utilizzate.
Ad oggi lo standard maggiormente utilizzato è IEEE 802.11b che fornisce un bit
rate di 11 Mbps.
Il largo uso della tecnologia WLAN può essere visto come una minaccia alle reti di
terza generazione. Tuttavia, fornendo alti bit rate negli hot spot, essa può
considerarsi a tutti gli effetti un complemento del 3G. I servizi sono stati sviluppati
per far uso di questi alti data rate.
Molti operatori e industrie pianificano di complementare i propri dispositivi 3G con
soluzioni di accesso WLAN.
UMTS fornisce copertura globale e QoS, perfino ad alte velocità, mentre WLAN
può fornire alti data rate localmente. La migrazione da una tecnologia all’altra è
tecnicamente possibile. I differenti costi per la creazione delle infrastrutture delle
due tecnologie incidono sulla valutazione della
modalità da scegliere e della
fattibilità del sistema integrato.
66
Negli hot spot, es. luoghi dove la richiesta di banda è estremamente alta (stazioni,
aeroporti, centri commerciali,ecc..), un sistema integrato WLAN-3G può essere
visto come un’opportunità per gli operatori per aggiungere valore (alto data rate) ai
servizi offerti al cliente. Quindi non un’alternativa, ma piuttosto un complemento.
Sulla base di quest’idea, l’intento dell’ integrazione UMTS-WLAN è quello di
estendere i servizi e le funzionalità UMTS negli ambienti di accesso WLAN.
Le reti future trasporteranno una vasta gamma di servizi, ognuno con una differente
richiesta di Quality of Service (QoS).
Sono stati proposti diversi modelli d’integrazione WLAN-2.5/3G.
Il
3rd
Generation
Partnership
Project
(3GPP),
un’organizzazione
di
standardizzazione che si occupa dello sviluppo delle specifiche che riguardano
UMTS e GSM, ha recentemente ratificato un documento d’integrazione
WLAN/UMTS, che mira a specificare una o più tecniche d’interworking. Nel
contesto di questo lavoro, sono stati specificati diversi requisiti d’integrazione
organizzati in sei scenari [13].
Scenario 1: gestione utente comune tra le due tecnologie. Questa è la più
semplice forma d’integrazione che fornisce solo una gestione della tariffazione e dei
dati che riguardano l’utente, mettendo in evidenza il fatto che non si può parlare di
un vero e proprio modello d’integrazione. Per questo motivo, questo scenario non
richiede nessun tipo di attività di standardizzazione.
Scenario
2:
controllo
di
accesso
basato
sull’UTRAN.
La
gestione
dell’autenticazione, autorizzazione e accounting (AAA) è fornita dal sistema 3G.
questo scenario sostanzialmente consente connettività IP via WLAN per i clienti
2.5/3G.
Scenario 3: accesso ai servizi di terza generazione. Lo scopo di questo scenario è
permettere all’operatore di estendere, ai propri clienti, l’accesso ai servizi
GPRS/UMTS in un ambiente WLAN.
67
Scenario 4: continuità del servizio. Ai servizi offerti nel precedente scenario, qui
si aggiunge il mantenimento del servizio nel passaggio tra i due sistemi anche se
non in maniera seamless.
Scenario 5: servizi seamless. Prevede la continuità del servizio seamless
nell’handover, minimizzando i dati persi e l’interruzione del servizio nel passaggio
da UMTS e WLAN.
Scenario 6: accesso ai servizi a commutazione di circuito di 3G. Lo scopo è
permettere all’operatore di offrire accesso ai servizi a commutazione di circuito (es.
normali chiamate telefoniche) dal sistema WLAN. Dovrebbe inoltre essere
garantita, per i suddetti servizi, una mobilità seamless.
Ci sono differenti possibili ambienti in cui l’interworking UMTS-WLAN è
estremamente conveniente.
Dal punto di vista 3GPP, la tecnologia 3G opera universalmente in ambienti Public,
Corporate, Residential. [13]
Gli ambienti e alcune caratteristiche sono riassunte di seguito:
Public:
include tutte le aree in cui non ci sono restrizioni, incluse aree all’aperto, strade,
centri commerciali, hotel, ristoranti, luoghi pubblici, atri in edifici pubblici.
Corporate:
include uffici ed industrie dove il numero di utenti è limitato agli impiegati.
In questi ambienti le WLAN sono utilizzate per uso interno, e l’accesso ad altre reti
è gestito tramite firewall. L’interworking tra reti corporate WLAN e la rete 3G
comporterà il cambiamento di diverse politiche e tecniche rispetto ad altri ambienti.
Residential:
Include case e appartamenti dove gli utenti sono i residenti.
68
La tabella descrive gli scenari con le rispettive caratteristiche.
Scenari:
Scenario 1:
Scenario 2:
Scenario 3:
Scenario 4:
Scenario 5:
Scenario
gestione
controllo di
accesso ai
continuità del
servizi
6:
utente
accesso
servizi di
servizio
seamless
accesso ai
comune tra
basato
terza
servizi cs
le due
sull’UTRAN
generazione
di 3G
tecnologie
Servizi:
Billing comune
X
X
X
X
X
X
Customer care
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
comune
Controllo di accesso
basato sull’Utran
Accesso da WLAN ai
Servizi AAA di 3G
accesso ai servizi a
commutazione di
pacchetto di 3G
Continuità del
servizio
Continuità seamless
del servizio
accesso ai servizi a
X
commutazione di
circuito di 3G
Tabella 3.1 – Scenari e servizi nella visione di integrazione 3GPP
Visione ETSI
La European Telecommunications Standards Institute (ETSI) specifica tre modelli
d’interworking: così denominati:
− loose interworking (no interworking)
− loose interworking (con supporto Mobile IP)
− tight interworking
69
Separatamente alle attività di standardizzazione svolte da ETSI, che sono discusse
nel in [12], e che saranno accennate successivamente, altre organizzazioni si sono
recentemente interessate alla possibile integrazione WLAN-3G. Molte di queste
attività sono state promosse da operatori mobili, i quali vedono il rapido sviluppo
della tecnologia WLAN come un’opportunità proporre ai propri clienti, con un
unico abbonamento, servizi avanzati ad alti data rate.
Ciò che inciderà, nella scelta tra una delle modalità, è sicuramente il grado di
modifica che subirà l’esistente standard.
Di particolare interesse è la continuità del servizio seamless.
ETSI BRAN e 3GPP convergono nelle scelte di integrazione UMTS-WLAN.
La visione 3GPP rispecchia quella ETSI. Le tre modalità di integrazione proposte le
ritroviamo a grandi linee negli scenari 1-4-5 descritti da 3GPP.
3.3.1 - Loose Interworking (No Interworking)
UMTS e WLAN sono usate come reti di accesso totalmente indipendenti. Gli utenti
hanno contratti separati per ogni rete. Questo è lo schema più semplice
d’integrazione.
Le reti UMTS e WLAN rimangono indipendenti e non subiscono alcuna modifica,
l’unico punto d’unione tra i due sistemi è la gestione utente.
Possono, infatti, condividere le informazioni utente per consentire l’accesso alla rete
e gestire il profilo utente anche in roaming.
70
Applicazioni
Applicazioni
TCP/UDP
TCP/UDP
IP
IP
UMTS
WLAN
Figura 3.2 – Stack protocollare terminale mobile nella visione Loose Interworking – No
Interworking
Il cliente riceve una tariffazione dall’operatore mobile per l’utilizzo dei servizi
UMTS e WLAN.
Passando da una rete all’altra l’utente cambia il proprio IP Address, con una
conseguente caduta della sessione corrente. L’handover quindi è inesistente.
3.3.2 – Loose Interworking (Mobile IP)
E’ introdotto Mobile IP per consentire all’utente di conservare l’indirizzo IP e la
sessione nel passaggio da una tecnologia all’altra. E’ necessario l’inserimento del
Foreign Agent (Mobile IPv4) e dell’Home Agent.
Il supporto Mobile IP permette ad un nodo mobile di mantenere connettività ad
Internet e/o ad una rete locale usando un unico e indirizzo, il suo home address,
perfino quando il punto di accesso alla rete è cambiato.
71
Applicazioni
TCP/UDP
Mobile IP
IP
IP
UMTS
WLAN
Figura 3.3 – Stack protocollare terminale mobile nella visione Loose Interworking – Mobile IP
UMTS e WLAN sono reti peer-to-peer. Nella rete UMTS, il terminal (o user
equipment, UE) utilizza il GPRS mobility management (GMM) per garantire
roaming tra reti con accesso radio WCDMA. Per gestire la mobilità nelle WLAN
viene implementato Mobile IP. Se un MN decide di spostarsi da un’area a copertura
UMTS ad una a copertura WLAN, disabilita semplicemente i suoi protocolli UMTS
ed utilizza lo stack IP. Con l’aggiunta del protocollo MIP il MN può utilizzare lo
stesso indirizzo IP al passaggio da UMTS a WLAN.
Da quanto si evince, la modalità d’integrazione con supporto Mobile IP è da
considerarsi una soluzione applicabile, in quanto risulta essere un ottimo
compromesso tra facilità d’implementazione e prestazioni offerte.
72
3.3.3 - Tight Interworking
Figura 3.4 – Tight Interworking, visione ETSI [12]
Le reti sono fortemente integrate.
L’architettura di rete si complica ed è richiesta la modifica degli standard attuali.
Dal punto di vista UMTS, la rete WLAN ha le funzioni di una cella. L’utente non
può accedere direttamente a internet attraverso le WLAN, i pacchetti quindi passano
attraverso il GGSN, fulcro dell’integrazione. Il vantaggio di questo approccio è che
la latenza nell’handover è pressoché assente rispetto ai precedenti modelli
d’integrazione.
Poiché le WLAN vengono utilizzate come strato di accesso dell’UMTS, l’handover
tra i due sistemi risulta essere un handover a livello di RNC. La rete WLAN infatti è
connessa alla core network come l’UTRAN attraverso una nuova interfaccia
(Iuhl2), simile all’interfaccia Iu. Il principale vantaggio del tight interworking è che
vengono ereditati dall’UMTS i meccanismi di mobilità, la Quality of Service, la
sicurezza.
73
Per far questo vengono introdotti nuovi apparati di rete:
-
IWU (Inter Working Unit), esplica funzionalità simili all’ RNC UMTS
nella rete WLAN
-
CRRM (Common Radio Resource Manager), che sulla base di vari
parametri (traffico sulle reti, intensità del segnale, etc.) decide e gestisce
l’Handover.
L’attenzione comunque non è rivolta verso questa soluzione in quanto ad essa sono
legati ingenti costi d’implementazione.
74
3.4
–
Security,
Authentication,
Authorization,
Accounting (AAA) nelle reti integrate WLANUMTS
Le problematiche connesse alla mancanza di supporto per la security nelle reti IEEE
802.11 appaiono evidenti non appena ci si appresta ad analizzare il problema
dell’integrazione tra WLAN ed UMTS:
UMTS nasce sulla scorta dell’esperienza maturata con l’offerta dei servizi di
telefonia mobile di seconda generazione GSM. L’obiettivo di UMTS è estendere le
potenzialità delle reti cellulari di seconda generazione (tipicamente a commutazione
di circuito), per supportare anche la commutazione di pacchetto a larga banda. E’
ovvio, quindi che UMTS nasce ben strutturato per offrire servizio pubblico di
accesso radio mobile cellulare.
Come tale esso gestisce nativamente:
•
Autenticazione dell’utente
•
Autorizzazione dell’utente
•
Raccolta dei dati di Accounting necessari per la tariffazione
•
Security
•
Handover di livello 2 tra le celle
•
Qualità del Servizio (QoS)
Viceversa le tecnologie WLAN nascono per integrare e/o sostituire le reti locali
Wired-LAN all’interno di uffici, aziende, abitazioni private. E’ evidente, quindi,
che le Wireless-LAN non sono strutturate, nativamente, per offrire servizi di
accesso al pubblico.
Nel corso del capitolo si metteranno in luce le deficienze delle reti WLAN nello
standard 802.11 [32] in materia di security e AAA. Successivamente si
introdurranno le soluzioni non-standard 802.11 ed attualmente in via di definizione.
75
Infine si proporrà un’architettura completa per la gestione degli accessi alla rete
integrata WLAN-UMTS.
3.4.1 – Insecurity nelle Wireless LAN
Tra tutti i problemi connessi all’offerta di servizi di accesso pubblico su piattaforma
IEEE 802.11b [10], forse il può sentito è la mancanza di sistemi efficaci che
garantiscano sicurezza e privacy sulle reti WLAN.
3.4.1.1 – Sniffing
La natura di una rete ad onde radio lascia la possibilità di intercettare i pacchetti da
parte di ogni radio che si trovi nel range del trasmettitore.
L’intercettazione può avvenire anche molto lontano rispetto al raggio di lavoro della
rete, ciò è possibile tramite antenne ad alto guadagno, molte delle quali sono già
commercializzate. Il rischio è che non solo qualcuno possa raccogliere i dati ed
analizzarli, ma che addirittura si possano replicare le sessioni e guadagnare accesso
a risorse e servizi con l’uso di user ID e password intercettati.
3.4.1.2 – Furto di risorse
Quando una STA che tenta l’attacco viene a conoscenza del funzionamento del
controllo di accesso alla rete WLAN, essa può essere in grado di accedere alla rete
come se stessa o rubando l’identità di un’altra STA. Il furto dell’identità di un’altra
STA consiste nel replicare il MAC address e appropriarsi dell’indirizzo IP di quella
stazione. La STA che attacca aspetta finché la vittima prescelta si disassocia dalla
rete e si sostituisce ad essa. In questo modo l’attacker ha libero accesso a tutte le
risorse della rete locale e di Internet apparendo in tutto e per tutto un utente
autorizzato della rete.
76
3.4.1.3 – Ridirezione del traffico
Una STA attaccante può corrompere le tabelle ARP negli switch della rete wired
attraverso l’AP, facendo in modo che i pacchetti destinati ad una specifica stazione
vengano instradati verso di se. L’attacker può sia catturare passivamente i pacchetti
prima di instradarli verso la stazione attaccata della rete wired oppure tentare
l’attacco detto man-in-the-middle.
3.4.1.4 – Negazione del servizio
Le tecniche di negazione del servizio nelle reti WLAN possono essere le più
disparate, a partire dalla semplice interferenza sul canale radio tramite un qualsiasi
apparato cordless, fino a un attacco selettivo verso una o più stazioni. Potrebbe ad
esempio essere catturato un messaggio 802.11 di disassociazione. Successivamente
replicando questo messaggio si ottiene la disassociazione della specifica STA dalla
WLAN.
3.4.1.5 – Reti fasulle e ridirezione della stazione
La rete Wireless 802.11 è molto soggetta all’attacco del falso AP. Un AP falso
accetta le richieste di associazione delle STA, dopodiché intercetta il traffico o,
addirittura, effettua l’attacco man-in-the-middle, prima di spedire i pacchetti alla
destinazione. Il problema è che l’installazione di un AP fasullo risulta estremamente
semplice in ambienti pubblici e nelle aree condivise degli uffici.
77
3.4.2 – Strumenti standard 802.11 per il controllo d’accesso
3.4.2.1 – SSID (Service Set Identifier)
Ogni AP ha un SSID che usa per identificare se stesso. Un modo comune di
configurare una rete è richiedere che ogni STA conosca l’SSID dell’AP al quale si
vuole connettere.
L’SSID fornisce un metodo di controllo estremamente modesto. Più che altro esso
evita che una stazione si possa connettere accidentalmente ad un AP vicino diverso.
Esso non rappresenta un vero aiuto per la sicurezza della rete, e inoltre non vieta ad
un attacker di installare un falso AP con lo stesso SSID.
3.4.2.2 – Filtri sul MAC Address
Alcuni AP hanno capacità di controllare il MAC address della stazione prima di
autorizzare l’associazione. Questo fornisce una certa garanzia di sicurezza nella
misura in cui solo i MAC address autorizzati possono connettersi alla rete. Sono
possibili due soluzioni. Una in cui la lista di MAC Address viene conservata nella
memoria dell’AP, l’altra in cui la lista si trova in un server RADIUS, e ad ogni
accesso l’AP manda il MAC address come user ID (con password vuota) al server
RADIUS per richiedere l’autenticazione. L’approccio del server RADIUS è
maggiormente indicato quando gli AP sono molti.
Anche la soluzione del filtro sul MAC address è molto debole, in quanto ogni
stazione mobile può sniffare i MAC address autorizzati e utilizzare uno di questi
(usando una scheda con il MAC address configurabile) per accedere alla rete.
3.4.2.3 – Chiavi statiche WEP
Wired Equivalent Privacy (WEP) è parte dello standard 802.11. L’uso delle chiavi
statiche WEP richiede che vi siano delle chiavi nella STA e AP che vengono usate
per criptare i dati inviati tra loro.
78
STA e AP vengono configurati manualmente con un insieme di quattro chiavi; in
fase di decriptazione ognuna viene utilizzata a turno finché non si ottiene la
decriptazione. Questo permette di cambiare le 4 chiavi dinamicamente.
Con la criptazione WEP, lo sniffing dovrebbe essere eliminato e gli attacchi durante
la sessione dovrebbero essere difficili o impossibili.
Per molte reti l’uso delle chiavi statiche WEP, che vengono inserite manualmente
su client ed AP, dove rimangono identiche spesso per settimane, non è sufficiente.
Infatti l’802.11 Working Group ha definito il WEP come un semplice protocollo di
criptazione dei frames, per portare la sicurezza delle comunicazioni wireless allo
stesso livello delle reti wired non provviste di meccanismi di sicurezza. Sebbene il
WEP usi una stringa simmetrica RC4 per la criptazione, le chiavi statiche WEP
sono relativamente semplici da individuare se rimangono invariate a lungo. E’
quindi necessario un meccanismo più evoluto di autenticazione con generazione
dinamica delle chiavi WEP, in tal modo ripetendo periodicamente l’autenticazione
vengono generate chiavi sempre diverse che rimangono in uso per un periodo di
tempo troppo breve per poter essere individuate.
3.4.3 – Strumenti non-standard 802.11 per il controllo d’accesso
3.4.3.1 – IEEE 802.11i
802.11i [26] è un nuovo standard in via di sviluppo da parte del IEEE Task Group i
(TGi). Lo standard 802.11i affronta e risolve il problema della debolezza/mancanza
di meccanismi di autenticazione e criptazione dei dati nello standard nativo 802.11
basati sul WEP.
I componenti fondamentali dello standard 802.11i sono già stati rilasciati, o almeno
annunciati e i primi prodotti iniziano ad apparire sul mercato. Tra questi vi è IEEE
802.1x [25] (descritto nel seguito) che è stato già rilasciato da tempo, ed è
un’architettura per l’autenticazione funzionante sul controllo di accesso ai punti di
ingresso alla rete. L’802.11i si occupa anche del Temporal Key Integrity Protocol
79
(TKIP), dell’algoritmo di criptazione Advanced Encryption Standard (AES) che
sostituirà il vecchio RC4 del WEP, delle funzionalità di gestione e gerarchia della
chiave, e della negoziazione dei metodi di cifratura e autenticazione.
3.4.3.2 – Wireless Protected Access (WPA)
Lo standard definitivo dell’ IEEE TGi e atteso non prima della seconda metà del
2003, nel frattempo, data l’importanza dei problemi di sicurezza nelle reti wireless
802.11, un sottoinsieme dello standard 802.11i è stato rilasciato su consiglio della
Wi-Fi
Alliance.
Wi-Fi
Alliance,
precedentemente
detta
WECA,
è
un’organizzazione che certifica l’interoperabilità dei prodotti 802.11 e promuove
802.11 come standard globale per le Wireless LAN.
Figura 3.5 - Cronologia di WPA & 802.11i
Nel novembre 2002, la Wi-Fi Alliance ha annunciato l’inizio dei test di
interoperabilità delle procedure WPA tra gli apparati conformi allo standard Wi-Fi.
WPA è basato sui componenti stabili di 802.11i, e può essere supportato dagli
apparati di rete 802.11 Wi-Fi compliant e sui client con un semplice upgrade del
software. Quando verrà rilasciato, l’802.11i (si chiamerà WPA version 2) sarà
80
compatibile con WPA. Wi-Fi ha iniziato la certificazione degli apparati WPAcompliant nel febbraio 2003 e i primi dispositivi funzionanti saranno presto
disponibili sul mercato.
Tra i componenti dell’802.11i inclusi nel WPA vi sono:
•
Autenticazione 802.1x
•
TKIP
•
Gerarchia e gestione delle chiavi
•
Negoziazione della cifratura e dell’autenticazione
Figura 3.6 – Elementi dello standard IEEE 802.11i integrati in WPA
81
3.4.3.2.1 IEEE 802.1x – Scambio dinamico della chiave
3.4.3.2.1.1 – Nomenclatura
Port
Una porta in questo contesto è un punto di ingresso per l’infrastruttura LAN. Nel
caso di una LAN 802.11, l’AP gestisce tutte le porte logiche. Ognuna di queste
porte logiche comunica con una sola porta fisica della STA.
Figura 3.7 – Architettura 802.1x
Authenticator System
L’Authenticator
System
controlla
l’accesso
alle
porte.
Esso
richiede
l’autenticazione prima di permettere l’accesso ai servizi che sono disponibili tramite
l’uso di quella porta. L’Authenticator System è responsabile della richiesta delle
credenziali al supplicant e del passaggio delle stesse all’Authentication Server. Ciò
permette la verifica delle autorizzazioni per quell’utente, e conseguentemente
l’apertura o meno della porta. E’ importante notare che la funzionalità
dell’Authenticator System è indipendente dall’effettivo metodo di autenticazione.
Infatti durante l’autenticazione esso agisce come tramite per il passaggio dei relativi
messaggi.
82
Supplicant
Il supplicant è colui il quale richiede l’accesso ai servizi disponibili su una certa
porta logica. Esso deve semplicemente rispondere alla richiesta di credenziali da
parte dell’Authenticator.
3.4.3.2.1.2 – Extensible Authentication Protocol (EAP)
L’Extensible Authentication Protocol (EAP) è un metodo per gestire il passaggio di
messaggi (conversazione) tra il Supplicant e l’Authentication Server. Dispositivi
intermedi come Access Points e Proxy Servers non prendono parte alla
conversazione. Il loro ruolo è semplicemente di passare le informazioni tra le parti
impegnate
nell’autenticazione.
802.1X
impiega
l’EAP
come
trama
per
l’autenticazione.
3.4.3.2.1.3 – Extensible Authentication Protocol Over LAN (EAPOL)
802.1X definisce uno standard per l’incapsulamento dei messaggi EAP in modo che
possano essere gestiti direttamente da un servizio LAN MAC. Questa modalità di
incapsulamento in frame EAP è noto come EAPOL. Oltre a portare pacchetti EAP,
EAPOL fornisce anche funzionalità di controllo come start, logoff, e la
distribuzione delle chiavi.
3.4.3.2.1.4 – RADIUS
RADIUS è il Remote Access Dial In User Service. E’ la modalità standard per
fornire alla rete servizi di Authentication, Authorization e Accounting. Sebbene il
supporto per il protocollo RADIUS è opzionale in IEEE 802.1X, ci si aspetta che
molti Authenticators funzioneranno usando RADIUS. Infatti allo stato attuale la
maggior parte degli AP che supportano 802.1x, utilizzano RADIUS.
83
3.4.3.2.1.5 – Architettura di autenticazione di 802.1x
Il controllo d’accesso 802.1X e basato sul controllo delle porte. L’Authenticator
system ha due distinti punti d’accesso detti porte. Una porta è non controllata e
permette solo lo scambio di messaggi di autenticazione (messaggi EAP) tra
l’Authenticator System e i supplicant sulla Wireless LAN. L’altra porta è
controllata, nel senso che permette lo scambio di frames solo se il supplicant è stato
autorizzato in seguito all’autenticazione avvenuta sulla porta non controllata.
Nell’802.11x quando un host si connette ad una porta LAN di uno switch (o AP)
802.1x, l’accesso alla porta controllata diventa disponibile solo dopo che
l’autenticità dell’host viene determinata. Prima di questo momento possono essere
scambiati solo frames EAPOL.
3.4.3.2.1.6 - 802.1x nelle Wireless LAN 802.11
Le specifiche 802.1x includono due funzionalità principali che permettono l’uso del
Controllo di accesso basato sulle porte nelle LAN IEEE 802.11:
Porte logiche. La capacità di usare il MAC address della STA e dell’AP come
indirizzo di destinazione negli scambi del protocollo EAPOL.
Gestione della chiave. La capacità dell’AP di distribuire ed ottenere informazioni
globali sulla chiave verso/da le STA, per mezzo dei messaggi EAPOL-key, che
seguono ogni autenticazione con successo.
Corrispondenza tra porte logiche e MAC address
Nelle LAN 802.11, le STA non sono fisicamente connesse alla rete. Inoltre, più
stazioni connesse condividono lo stesso mezzo di accesso alla rete (l’etere). Un caso
speciale di accesso condiviso al mezzo esiste nelle wireless LAN IEEE 802.11 nel
quale una STA deve associarsi ad un AP per poter usare la LAN. Il protocollo che
stabilisce l’associazione, permette alla STA e all’AP di conoscere i reciproci
indirizzi MAC. Questa informazione permette di creare una “porta logica” che la
STA può usare per comunicare con l’AP. Gli AP sono configurati per usare
l’Autenticazione Aperta. Ciò permette al supplicant di associarsi all’AP prima che
84
siano disponibili le chiavi WEP, che verranno poi ricavate in modo dinamico. Dopo
aver stabilito l’associazione, la STA si può autenticare usando l’EAP.
Gestione delle chiavi WEP
Per definizione il protocollo 802.1x non richiede, né esclude, l’uso del WEP o di
altri algoritmi di criptazione. Esso fornisce un meccanismo per la distribuzione delle
chiavi di codifica dall’AP al client usando i messaggi EAPOL-Key. La generazione
e distribuzione della chiave può essere ripetuto una volta per sessione o anche più, il
che impedisce che si possa ricavare la chiave WEP. Per fare ciò, infatti, è necessario
sniffare un certo numero di pacchetti codificati con la stessa chiave WEP.
Associazione e procedura di autenticazione EAP
Come già detto, una STA deve prima associarsi ad un dato AP, poi deve scambiare
messaggi EAP con l’Authentication Server al fine di ottenere l’autorizzazione della
porta. La Figura 2 mostra i dettagli di un tipico scambio di messaggi tra STA e
Authentication Server.
85
Figura 3.8 - Passi necessari per l'associazione, l'autenticazione e la distribuzione della chiave
Notare che il dialogo EAP viene trasportato da EAPOL tra STA e AP. Il dialogo
viene trasportato da EAP over RADIUS tra AP e Authentication Server. L’insieme
dei due passaggi costruisce una conversazione EAP tra STA e Authentication
Server che permette l’autenticazione dell’utente. Una volta che l’utente si è
autenticato, un messaggio EAP-Key viene mandato per passare la chiave alla STA.
Associazione e procedura di autenticazione LEAP (CISCO)
Vi sono molti algoritmi di autenticazione derivati dall’EAP, uno di questi è stato
proposto da CISCO e denominato LEAP (Lightweight Extensible Authentication
Protocol).
Le raccomandazioni CISCO prevedono la mutua autenticazione tra STA e AP; ciò
significa che non solo l’utente viene autenticato dall’AP, ma anche il viceversa. Il
LEAP supporta tutte le caratteristiche di sicurezza raccomandate, incluso
86
username/password, autenticazione mutua, chiavi WEP dinamiche. Il meccanismo
di autenticazione LEAP secondo CISCO è sinteticamente esposto nella Figura 6.
Figura 3.9 – Meccanismo di autenticazione LEAP.
Basso overhead
802.1X non modifica l’incapsulamento, quindi non aggiunge overhead ai pacchetti
e può essere implementato sugli switch ed AP esistenti con basso impatto sulle
performance. Esso può essere applicato agli AP esistenti semplicemente con un
upgrade del firmware. Anche dal lato client, il supporto dell’802.1X può essere
inserito nei driver della STA, senza richiedere alcuna modifica al sistema operativo;
è infine da notare che i più recenti sistemi operativi, incluso Windows XP, lo
supportano nativamente.
87
3.4.3.2.2 – TKIP
TKIP permette la generazione e lo scambio dinamico delle chiavi. TKIP usa ancora
lo stesso motore di criptazione RC4 del WEP ma fornisce le seguenti significative
migliorie rispetto al WEP:
•
Chiavi dinamiche – Permette chiavi di cifratura dinamiche per pacchetto o
per sessione.
•
Message Integrity Cecking (MIC) per assicurare che i messaggi non siano
stati modificati durante il trasporto.
•
IV hashing a 48 bit – un IV più lungo riduce la debolezza della chiave a
WEP RC4 a 24 bit.
•
Correzione del problema di vulnerabilità del WEP che manda l’IV in chiaro
sul link wireless.
Recentemente un nuovo algoritmo di criptazione basato sulle AES di nuova
generazione viene ritenuto una valida alternativa all’RC4 e verrà introdotto in
futuro nel TKIP.
Gerarchia e gestione delle chiavi
WPA fornisce una migliore e più sicura gestione e creazione delle chiavi. Queste
funzionalità aiutano a difendersi dai ben noti attacchi sulle chiavi. Le chiavi master,
ricevute attraverso il passaggio di messaggi 802.1x, sono utilizzate per ricavare le
chiavi base che, a loro volta, vengono usate per ricavare le chiavi per-pacchetto. Le
chiavi master e base non vengono usate direttamente per criptare il traffico.
Negoziazione della cifratura e dell’autenticazione
WPA migliora l’interoperabilità richiedendo che gli AP “annuncino” i meccanismi
di criptazione e autenticazione che supportano. I client che desiderano autenticarsi
presso un AP tramite il WPA, ricevono questo announcement e rispondono in
maniera appropriata. In questo modo il client può scegliere il metodo più sicuro di
autenticazione supportato da lui e dall’AP.
3.4.3.3 – Virtual Private Networks (VPN)
Le reti VPN vengono molto usate per fornire, ai dipendenti che si trovano fuori
sede, un accesso sicuro attraverso Internet ai dati della rete aziendale. In questa
88
applicazione remota, la VPN stabilisce un percorso dedicato (tunnel) e sicuro su reti
non sicure in Internet. Possono essere utilizzati diversi tipi di protocolli di
tunnelling tipo Point-to-Point Tunnelling Protocol (PPTP) o Layer 2 Tunnelling
Protocol (L2TP) uniti a soluzioni di autenticazione centralizzate, come RADIUS
server.
La tecnologia VPN può essere utilizzata per rendere sicuro l’accesso alle reti senza
fili, in questo scenario la rete insicura è la Wireless LAN. Gli AP devono essere
configurati per permettere l’accesso senza chiavi WEP, ma l’accesso wireless è
isolato dalla rete aziendale per mezzo di un server VPN. L’autenticazione e la
crittografia dei dati sulla rete wireless è fornita dai server VPN che funzionano
anche da firewall/gateway per la rete privata interna. Contrariamente alla soluzione
con chiavi statiche WEP, questa soluzione è scalabile su un grosso numero di utenti.
In questo modo i dipendenti possono utilizzare connessioni dial-up, DSL, GPRS o
le reti pubbliche Wireless LAN, dislocate ad esempio in aeroporti da cui
stabiliscono una connessione VPN alla rete privata aziendale. Allo stesso modo si
può utilizzare VPN in una rete wireless di campus, l’interfaccia utente sarebbe la
stessa in ognuno di questi casi, con grossa semplificazione per l’utilizzatore.
L’approccio VPN ha diversi vantaggi:
•
E’ già predisposto in molte reti aziendali
•
E’ scalabile su un grosso numero di utenti
•
E’ facilmente amministrabile, in quanto non richiede di mettere chiavi sui
client e sugli AP. Può essere gestito in maniera centralizzata
•
Il traffico da Internet non è permesso se non viene instaurata una
connessione VPN
•
Non è richiesta la gestione delle chiavi WEP o dei filtri sui MAC address
•
Utilizza sempre la stessa interfaccia utente da qualsiasi locazione si cerchi di
accedere
La controparte alle soluzioni VPN attualmente implementate sono la mancanza di
supporto per il muticasting, utile per spedire stream multimediali efficientemente ed
in tempo reale a più utenti su una rete (video-conferenze, insegnamento a distanza,
multicast televisivo). Ancora più grave è la mancanza di meccanismi trasparenti di
89
roaming tra le reti, il che significa che l’utente che cambia rete deve ripetere il
login, il che è insostenibile nel caso di utenti mobili.
3.4.4 – Architettura per il controllo d’accesso alla rete integrata WLANUMTS
In questo paragrafo verrà presentata un’architettura completa e realizzabile per un
operatore mobile che voglia offrire servizi di accesso WLAN. L’architettura
proposta riutilizza gli stessi meccanismi di autenticazione, controllo di accesso,
gestione del profilo utente, roaming e billing, usato nelle attuali reti di telefonia
mobile, ed è compatibile con i protocolli IEEE (RADIUS, EAP, 802.1x, 802.11i)
che utilizzano i Wireless ISP.
Stato dell’arte, confronto tra le soluzioni
Come visto precedentemente gli standard WLAN sono in via di ridefinizione per
rispondere meglio alla necessità di offrire servizi di accesso pubblico. Il TGi
dell’IEEE 802.11 Working Group sta definendo un architettura scalabile per il
controllo d’accesso e per risolvere i problemi di security insiti nello standard
802.11. Quando sarà disponibile, l’802.11i sarà adatto anche per le Wireless LAN
pubbliche.
90
IEEE 802.1x con EAP/SIM
Protocollo
Compatibilità
Credenziali
Produttore
utente
con 802.11i
richieste
IEEE 802.1x
SI
SIM
Nokia, Cisco
HTTP su SSL
NO
SIM, chiave
Ericsson ed altri
(descritto di seguito)
SMS One Time Password
con Login HTTP
Pubblica
SMS One Time Password
IEEE 802.1x
SI
con IEEE 802.1x
SIM, chiave
Cisco
Pubblica
IEEE 802.1x con gestione
IEEE 802.1x
SI
della mobilità GPRS
SIM, chiave
Transat
Pubblica
Tabella 3.2 – Soluzioni Wireless LAN per l’operatore
Per il momento vi sono diverse proposte di soluzioni complete non standard per il
controllo d’accesso. La tabella 3.1 mette a confronto le più affermate soluzioni
WLAN per operatori mobili:
La prima riga mostra la soluzione proposta in questo paragrafo, che è basata sui
protocolli IEEE 802.1x ed EAP SIM. L’architettura è stata presentata
pubblicamente per la prima volta in un contributo IEEE [27] nel gennaio 2001, e la
prima versione del protocollo EAP SIM, che è il cuore della soluzione, è stata
pubblicata come Internet draft nel marzo 2001 [28]. La soluzione è stata
successivamente adottata da diversi produttori, ed è in via di standardizzazione da
parte del 3GPP per la Release 6.
La seconda riga, una soluzione supportata da Ericsson, fa uso delle one-time
password trasportate attraverso Short Message Service (SMS) [29]. Sebbene questa
soluzione possa sembrare scomoda da usare, essa ha la grossa convenienza di aver
bisogno solo di un telefono GSM, e non comporta aggiunte software sul laptop.
Poiché l’autenticazione è affidata al Secure Socket Layer (SSL), oltre alla SIM, è
richiesta una chiave pubblica sul terminale.
La terza e la quarta soluzione sono basate sulle Protected EAP (PEAP), per la
distribuzione della chiave di sessione e per l’autenticazione di rete [30]. Anche
PEAP ha bisogno della chiave pubblica. La soluzione basata sulla one-time
password (terza riga), proposta in [31], incapsula il protocollo della OTP in EAP.
L’ultima proposta, (quinta riga) riusa i messaggi per la gestione della mobilità
GPRS [32]. L’idea di quest’ultimo sistema è riutilizzare l’implementazione della
91
macchina a stati GPRS. D’altra parte questa soluzione, sposta i dati utente della
sessione GPRS sulla sessione WLAN, il che non permette di avere una sessione
parallela che supporta contemporaneamente sia la rete cellulare che quella WLAN.
3.4.4.1 – Architettura WLAN dell’operatore mobile
Componenti del sistema
La figura x e y illustrano l’architettura dell’operatore mobile descritta in queste
pagine. Dal momento che è necessario supportare sia l’infrastruttura di roaming
mobile, che quella Internet di AAA, l’architettura include una rete di accesso
Wireless LAN compatibile con IEEE 802.11i, con Access Point (AP) compatibili
802.11i, una rete per il roaming secondo lo standard RADIUS, con RADIUS Proxy
(AAA Prx), ed un’infrastruttura standard per il roaming mobile.
Figura 3.10 - Roaming con la rete mobile 2,5/3G
Le funzioni di roaming sono specificate in diversi in diversi standard dell’ European
Telecommunications Standards Institute (ETSI) e del 3rd Generation Partenership
92
Project (3GPP). Le operazioni e i protocolli di AAA in Internet sono definiti nei
documenti dell’Internet Engineering Task Force (IETF) [9-14].
Figura 3.11 - Roaming con la rete mobile Internet AAA
Questi due mondi sono collegati tra loro attraverso l’authentication server (AS). AS
si presenta come un AAA server per gli operatori della rete IP. Al contrario appare
come una Visitor Location Register (VLR) verso la rete di roaming cellulare. Come
illustrato nella figura 3.10 la rete di roaming include i Signalling Transfer Point
(STP) e i Signalling Connection Control Part Gateway (SCCP GW), che instradano
le richieste degli AS verso la giusta rete pubblica mobile (PLMN).
L’autenticazione e l’autorizzazione sono basate sulle informazioni disponibili
presso l’Home Location Register (HLR) e Authentication Center (AuC). Il sistema
WLAN deve inoltre includere un Charging Gateway (CG) che si occupa di
raccogliere ed inoltrare al billing system dell’operatore i record di accounting
generati nella rete WLAN. Nel roaming AAA, il protocollo di interfacciamento tra
gli operatori è il RADIUS.
Lo stack protocollare di autenticazione
La figura 3 mostra lo stack protocollare di autenticazione usato nella rete WLAN. Il
terminale implementa normali protocolli di autenticazione 802.1x. Il SIM enhanced
93
authentication protocol è implementato come un tipo EAP [37] chiamato EAP/SIM
[28]. Nell’ IEEE 802.1x, i pacchetti EAP sono incapsulati in frames EAPOL. La
notazione L2/L1 usata in figura, denota i due livelli più bassi dello stack
protocollare. Nel terminale questi livelli sono i protocolli IEEE 802.2 e 802.11 data
link e physical layer. Virtualmente qualsiasi metodo di autenticazione può essere
supportato da EAP, il campo Type nel pacchetto EAP distingue il metodo utilizzato
in quella specifica sessione.
EAP/SIM
---------------------------
EAP
EAPOL
L2/L1
Terminal
---
EAPOL
L2/L1
EAP/SIM
MAP
---
MAP
EAP
TCAP
TCAP
Radius
Radius
UDP
UDP
SCCP
SCCP
IP
IP
MTP3
MTP3
L2/L1
L2/L1
L2/L1
L2/L1
Access Point
Authentication
HLR
server
Figura 3.12 – Stack protocollare dell’autenticazione
L’AP comunica con il server corrispondente utilizzando protocolli AAA. Oltre
all’autenticazione, autorizzazione ed accounting, i protocolli di AAA supportano
anche operazione di roaming tra ISP, che permettono ad un cliente di un ISP di fare
roaming sulla rete di accesso di un altro ISP esattamente come accade per le reti
mobili. Al momento il protocollo di AAA Internet più utilizzato è RADIUS;
DIAMETER, successore di RADIUS, è in via di standardizzazione IETF.
In figura 3.12 l’AP comprende un client RADIUS che passa i pacchetti EAP verso
la rete AAA. Radium gira su UDP/IP. Tra AP e AS possono essere impiegati proxy
server AAA e server di roaming AAA standard senza funzionalità specifiche per le
reti cellulari. L’AS può anche passare all’AP le chiavi derivate dallo scambio di
messaggi EAP, che verranno poi utilizzate per la criptazione dei dati tra il terminale
94
e l’AP. L’AS è un server RADIUS che implementa funzionalità di autenticazione
secondo il metodo EAP/SIM. Dal lato della rete UMTS l’AS supporta lo stack
protocollare standard necessario per scambiare informazioni di autenticazione e
autorizzazione con la rete cellulare. L’HLR è il server nella rete home (in cui il
cliente ha sottoscritto il contratto per i servizi di accesso), con cui l’AS scambia
informazioni di registrazione e dati del profilo utente.
Identificazione dell’utente
Nelle reti cellulari e in quelle di accesso Internet, l’identità dell’utente ha un
formato composto che contiene sia l’identità dell’utente nella rete attuale, sia un
identificatore della rete home, che è usato per il roaming. Nelle reti Internet,
l’identificatore dell’utente è chiamato Network Access Identifier (NAI) [38], Quindi
NAI consiste di una parte detta username seguita da un @ e poi da una parte detta
realm. Per esempio [email protected] è un NAI valido. Le reti per il
roaming Internet, instradano le comunicazioni AAA verso il giusto server AAA
sulla base della parte de NAI detta realm.
D’altra parte, i clienti delle reti cellulari vengono identificati da un numero detto
International Mobile Subscriber Identity (IMSI) registrato sulla SIM card. A partire
dal numero IMSI, ogni rete cellulari può ricavare il relativo HLR di competenza e
quindi sa instradare verso il giusto server HLR le richieste di autenticazione. Per
creare un sistema di identificazione dell’utente che fosse compatibile ad entrambe le
reti, si è scelto di mappare l’IMSI nel NAI, ed in particolare di inserire l’IMSI come
username del NAI, per esempio [email protected]. Si è scelto di far precedere
l’IMSI dal numero 1 per permettere ulteriori sviluppi nel formato del NAI.
95
Capitolo 4 – Prove sperimentali di mobilità con Mobile IPv6
Capitolo 4
Prove sperimentali di mobilità con Mobile IPv6
96
4.1 – Testbed WLAN
Al fine di testare sperimentalmente le prestazioni di Mobile IPv6 in previsione di un
suo utilizzo in un ambiente integrato WLAN-UMTS, ho realizzato, presso il centro
di ricerca ELIS LAB, un testbed Mobile IPv6.
Il testbed è stato realizzato su piattaforma Linux, unico sistema operativo che al
momento ha un’implementazione funzionante di Mobile IPv6. Nell’Appendice A
ho riportato le configurazioni utilizzate per rendere il testbed funzionante.
Quelli che nell’immagine appaiono come tre router sono in realtà tre PC Pentium II
con funzionalità di routing.
Figura 4.1- Il testbed WLAN implementato in ELIS LAB
97
Descrizione del testbed:
-
4 reti IPv6: le due reti in basso nella figura sono quelle alle quali
afferiscono i due AP.
-
AR-Home: Access Router ed Home Agent MIPv6.
-
AR-Visited: Access Router, senza funzionalità MIPv6; si può infatti
presupporre che la rete visitata non abbia supporto MIPv6 senza che ciò
abbia alcuna conseguenza (tranne Router Advertisement leggermente meno
frequenti) sul funzionamento di Mobile IPv6. Come detto in precedenza in
Mobile IPv4 era prevista l’introduzione di un Foreign Agent in ogni rete
visitata, complicando notevolmente la diffusione del protocollo di mobilità.
-
C-Node: Correspondent Node MIPv6 e router;
-
M-Node: Mobile Node MIPv6, è un PC laptop dotato di scheda Wi-Fi Cisco
Aironet 350
-
AP: i due Access Point sono dei Cisco Aironet 350
Nel testbed sono state eseguite diverse prove sperimentali; nei paragrafi seguenti
illustrerò le varie prove svolte ed i risultati ottenuti. Un’analisi complessiva delle
prestazioni verrà effettuata nel prossimo capitolo, insieme alle proposte di
miglioramento ed agli sviluppi futuri del presente progetto.
4.1.1 – Prove di throughput
Prima di procedere alle prove di mobilità è importante avere un quadro chiaro della
banda a disposizione in un hot spot WLAN. Proprio per dimensionare questo
parametro e comprendere quali tipi di applicazioni potranno essere supportati, sono
state effettuate alcune prove di throughput.
98
Descrizione: download FTP da CN ad MN
Parametri variati: bandwidth dell’Access Point (11, 5.5, 2 Mbps)
Sorgenti di traffico: 1 nodo wireless in download
Ripetizioni: 10 volte per ogni configurazione
Ecco un grafico dei risultati ottenuti:
Figura 4.2 – Throughput IEEE 802.11b al variare del badwidth dell’AP.
Ciò che è importante notare è l’aumentare del rapporto throughput/bandwidth, al
diminuire del bandwidth. Ritornerò su questo concetto più avanti nell’analisi del
tempo di handover.
4.1.2 – Prove di handover L2
Questa prova consiste nel misurare il tempo di riassociazione di un MN nel
passaggio da un AP ad un altro appartenenti allo stesso SSID.
99
Tramite un secondo nodo mobile è possibile, configurando la scheda wireless in
modalità promiscua, sniffare i frame 802.11 e misurare il tempo di handover L2.
Descrizione: passaggio del MN dalla zona di copertura di AP1 a quella di AP2
Parametri variati: bandwidth dell’Access Point (11, 5.5, 2 Mbps)
Questi sono i risultati ottenuti ed il relativo grafico:
11 Mbps
5,5 Mbps
2 Mbps
Media
0,154194
0,145645
0,146441
Deviazone standard
0,024991
0,019479
0,021221
0,2
L2 Handover delay
0,18
0,16
0,14
0,12
11 Mbps
5,5 Mbps
2 Mbps
0,1
0,08
0,06
0,04
0,02
0
Bandwidth
Figura 4.3 – Tempi di latenza nell’handover L2
Come si vede, la latenza per l’handover L2 ha, al variare del bandwidth, un
andamento piuttosto costante. Fino a meno di un anno fa non era così, ma grazie ad
un miglioramento del firmware dei dispositivi 802.11b, si è riusciti a rendere questo
tempo piuttosto costante.
100
Poiché Mobile IPv6 è un protocollo di livello 3, questa prova è la più
caratterizzante, in quanto il tempo di latenza per l’handover L3 è il tempo di
inattività del MN nel passaggio tra due reti. Questo tempo deve essere il minore
possibile, in quanto da questo dipende la capacità del protocollo Mobile IPv6 di
supportare il maggior numero di applicazioni possibili durante l’handover, incluse
quelle più critiche come streaming video e audio/video real time.
Il traffico streaming video utilizza UDP come protocollo di trasporto; risulta molto
interessante valutare la quantità di dati persi durante un handover L3 effettuato con
uno streaming video in corso. Per misurare tale valore ho utilizzato il software
freeware MGEN: è un generatore di traffico UDP, in cui è possibile variare il data
rate, la dimensione dei pacchetti e temporizzare le prove da effettuare. Ho
configurato il CN come generatore ed il MN come ricevitore. MGEN, in fase di
generazione dei segmenti, inserisce un numero di sequenza, utile per misurare la
quantità di pacchetti persi. Per ogni prova viene generato, lato ricezione, un file di
log nel quale sono riportati orario (precisione al milionesimo di secondo) e numero
di sequenza per ogni pacchetto arrivato. Ho quindi realizzato un programma in C++
per estrarre le informazioni di tempo e di numero di sequenza dal file di log e
salvarle in un file di tipo .xls, al fine di generare dei grafici che fossero
rappresentativi dell’andamento dell’handover durante ogni prova.
Descrizione: CN invia traffico UDP al MN; passaggio del MN dalla zona di
copertura di AP1 a quella di AP2 e ritorno (AP1 e AP2 afferiscono a reti differenti)
Parametri variati:
-
bandwidth dell’Access Point: 11, 2 Mbps
-
data rate di trasmissione: 784 kbps, 384 kbps, 64 kbps
-
dimensione dei segmenti UDP: 1024 byte, 512 byte, 256 byte
I grafici seguenti rappresentano la sequenza di ricezione dei pacchetti UDP da parte
del MN. Ho riportato alcune delle varie prove fatte, rappresentative dell’andamento
generale ad 11 e a 2 Mbps.
101
Figura 4.4 – Prova a 11 Mbps, 96 pacchetti al secondo, 512 bytes ciascuno (384 kbps)
102
Figura 4.6 – Prova a 11 Mbps, 48 pacchetti al secondo,1024 bytes ciascuno (384 kbps)
Figura 4.7 – Prova a 2 Mbps, 48 pacchetti al secondo,1024 bytes ciascuno (384 kbps)
103
Ciò che si è notato, analizzando i risultati, è che il tempo di handover è
indipendente dal data rate e dalla dimensione dei pacchetti UDP.
Questo sono i risultati medi ottenuti ed il grafico relativo:
L3 Handover delay medio
Deviazione Standard
11 Mbps
2 Mbps
1,623239
0,300876
0,41344
0,17593
Figura 4.8 – Tempi di handover a 2 ed 11 Mbps nel testbed WLAN presso ELIS LAB
Con i valori ottenuti è possibile supportare quasi tutte le tipologie di applicazioni;
anche uno streaming video, con un opportuno pre-buffering, verrà gestito nel
migliore dei modi. Per applicazioni di tipo real-time, tempi superiori al secondo non
sono accettabili; di ciò parlerò più diffusamente nel prossimo capitolo.
Come si evince dall’analisi dei grafici, al diminuire del bandwidth diminuisce il
tempo di handover; ciò si evince molto chiaramente dal grafico del test di
throughput, ed è una conseguenza della tecnica di codifica del segnale sul link
wireless.
Nelle prove effettuate è stato anche analizzato il numero di pacchetti persi durante
gli handover. Ho rilevato che tale valore è, ovviamente, direttamente proporzionale
al tempo di handover, infatti è circa pari al numero di pacchetti trasmessi al secondo
per il tempo dell’handover espresso in secondi.
104
4.2 – Testbed WLAN integrato Roma-Strasburgo
Le prove svolte nel testbed presso il centro di ricerca ELIS LAB sono un ottimo
punto di partenza per approfondire la sperimentazione e portarla verso
configurazioni maggiormente realistiche. Ho quindi ritenuto importante poter
realizzare un testbed a distanza che permettesse di inserire la rete Internet tra MN ed
agenti MIPv6. Ho così intrapreso una ricerca in rete per trovare ricercatori
nell’ambito Mobile IPv6, che avessero un testbed funzionante e la disponibilità ad
effettuare simili prove. Il contatto più proficuo è stato con il prof. Nicolas
Montavont dell’Università Louis Pasteur di Strasburgo in Francia.
Figura 4.9 – Testbed WLAN integrato Roma-Strasburgo
105
La prova è stata effettuata in analogia con quanto fatto nel paragrafo 4.1.3.
In questo caso però MN e agent MIPv6 (HA e CN) sono a distanza.
Le prove sono state ripetute andando a variare la posizione di MN e agent al fine di
ottenere una caratterizzazione della prova la più completa possibile.
Con questo tipo di prova intendo valutare come influisce la rete Internet sulla
segnalazione Mobile IPv6.
Descrizione: il CN invia traffico UDP al MN; due handover del MN tra reti WLAN
(Rete Visitata 1 -> Rete Visitata 2 e ritorno) realizzati variando l’ESSID.
Parametri variati:
-
bandwidth dell’Access Point: 11, 2 Mbps
-
data rate di trasmissione: 784 kbps, 384 kbps, 64 kbps
-
dimensione dei segmenti UDP: 1024 byte, 512 byte, 256 byte
Di seguito ho riportato alcuni grafici rappresentativi dell’andamento temporale ad
11 e 2 Mbps. Confrontati con quelli ottenuti nel testbed presso ELIS LAB si nota un
aumento del tempo di handover dovuto alla distanza tra MN (a Roma) e CN ed HA
(a Strasburgo) ed alla variabilità delle condizioni di carico della rete Internet.
106
107
108
109
Nella tabella che segue ho riportato i valori medi per il tempo di handover a 11 e 2
Mbps (bandwidth WLAN). Rispetto ai valori ottenuti nel testbed WLAN realizzato
in locale, si nota, come previsto, un aumento del valore medio e della deviazione
standard. Questo è comunque un risultato che mi aspettavo a causa dell’intrinseca
variabilità di carico della rete Internet, nella quale ora viaggiano le segnalazioni
Mobile IPv6.
L3 Handover delay medio
Deviazione Standard
11 Mbps
2 Mbps
1,742358
1,417619
0,546
0,38398
Figura 4.16 – Tempi di handover a 2 ed 11 Mbps nel testbed WLAN integrato Roma-Strasburgo
110
4.3 – Testbed integrato WLAN-GPRS
Le prove fin qui descritte hanno permesso di valutare le prestazioni di Mobile IPv6
nell’handover tra reti di accesso omogenee. Come accennato in precedenza MIPv6 è
un protocollo di livello 3, quindi il suo funzionamento prescinde dalle tecnologie di
accesso sottostanti.
Al momento della scrittura di questo lavoro di tesi la rete pubblica UMTS in Europa
non è ancora partita. Il lancio, più volte rimandato negli ultimi mesi, sembra però
ormai essere imminente.
Poiché la rete pubblica GPRS [5], per quanto riguarda il backbone a commutazione
di pacchetto, è del tutto analoga a quella UMTS, ho pensato di implementare un
testbed integrato WLAN-GPRS utilizzando, per la parte GPRS, la rete pubblica di
Telecom Italia Mobile (TIM). Ciò ha il vantaggio di essere una prova del tutto
realistica, grazie all’utilizzo di una rete pubblica e non di un ambiente di test.
Per effettuare queste prove il MN è stato equipaggiato con due schede pcmcia, una
GPRS (Nokia D211) ed una IEEE 802.11b (Cisco Aironet 350).
Al momento della connessione GPRS l’operatore cellulare assegna all’utente un
indirizzo dinamico IPv4 pubblico.
Al fine di garantire il funzionamento di MIPv6 in un siffatto testbed, è stato
necessario creare un tunnel GRE IPv6-in-IPv4 tra il MN (lato GPRS) e la rete IPv6
del testbed in ELIS LAB. L’Access Router dove termina il tunnel invia dei Router
Advertisement sul tunnel in modo che il MN possa creare uno stateless CoA sul lato
GPRS.
111
Figura 4.17 – Testbed integrato WLAN-GPRS
I risultati che verranno mostrati nei prossimi paragrafi devono essere analizzati alla
luce della non ottimalità della rete GPRS: il Round-Trip-Time medio dal MN verso
la rete IPv4 ELIS LAB è dell’ordine di 1.1 s, con deviazione standard piuttosto
elevata.
Il data rate da utilizzare nelle prove WLAN-GPRS deve essere dimensionato in base
alla capacità trasmissiva del canale GPRS. Sono disponibili 4 tipi di codifica di
canale per i canali logici di traffico GPRS; la codifica scelta dipende dalla bontà del
canale in uso, mentre il numero di time-slot assegnate per la trasmissione dati può
variare tra 1 e 8. Tale scelta è effettuata dall’operatore e il numero di time-slot può
anche essere variato dinamicamente.
112
Schema di
Rate di codifica
Data rate per slot
codifica
kbit/s
CS-1
1/2
9.05
CS-2
~ 2/3
13.4
CS-3
~ 3/4
15.6
CS-4
1
21.4
Figura 4.x – Schemi di codifica di canale per i canali logici di traffico in GPRS [7]
Le prove preliminari da me effettuate per testare il throughput del GPRS hanno
mostrato valori variabili tra 15.6 e 40.2 kbit/s.
Descrizione: il MN ha due interfacce WLAN e GPRS, associate rispettivamente
presso una Visited Network WLAN ed una Visited Network GPRS; la priorità
iniziale è in favore della sit1 (tunnel ppp0). Il CN invia traffico UDP al MN nella
Visited Network GPRS; segue il passaggio del MN dalla Visited GPRS alla Visited
WLAN e ritorno. Tale passaggio è effettuato variando la priorità delle due
interfacce.
Parametri variati:
-
data rate di trasmissione: 32 kbps, 24 kbps
-
dimensione dei segmenti UDP: 128 byte, 256 byte
Il bandwidth dell’AP è stato fissato ad 11 Mbps; il data rate di 32 kbps è stato scelto
come limite fisico del GPRS; quello a 24 kbps è stato preso in considerazione per
analizzare dei risultati in una trasmissione meno probante.
113
Figura 4.18 - Prova con 15 pacchetti al secondo, 256 bytes ciascuno (32 kbps)
I risultati ottenuti in queste prove sono di assoluto rilevo: nel 95% delle prove
effettuate non vengono persi pacchetti durante gli handover, grazie ad un
meccanismo di simultaneità che viene ad instaurarsi sulle due interfacce.
Infatti, considerando il primo handover GPRS->WLAN, nel momento in cui il
Nodo Mobile entra nell’hot spot WLAN, mantiene l’interfaccia GPRS attiva e su
114
questa continua a ricevere il traffico che già era stato instradato prima del
completamento della procedura di Update Mobile IPv6. Nel secondo handover,
WLAN->GPRS, tale meccanismo è meno visibile solamente perché, ai data rate
scelti, la rete WLAN riesce, grazie alla sua grande velocità di trasmissione, a
smaltire in fretta il traffico destinato al Nodo Mobile.
Grazie a questo meccanismo di simultaneità il passaggio tra le reti GPRS e WLAN
è totalmente trasparente per l’utente.
115
4.4
–
Testbed
integrato
WLAN-GPRS
Roma-
Strasburgo
Nei paragrafi precedenti sono stati analizzati i test effettuati in un testbed WLAN
tra Roma e Strasburgo e quelli nel testbed WLAN-GPRS.
La prova finale consiste nell’analisi di handover verticali WLAN-GPRS, avendo gli
agents MIPv6 a distanza.
Figura 4.20 – Testbed WLAN-GPRS integrato Roma-Strasburgo
116
4.4.1 - Prove di handover L3
In queste prove CN ed HA sono a Strasburgo, il MN a Roma.
Descrizione: il MN ha due interfacce WLAN e GPRS, associate rispettivamente
presso una Visited Network WLAN ed una Visited Network GPRS; la priorità
iniziale è in favore della sit1 (tunnel ppp0). Il CN invia traffico UDP al MN nella
Visited Network GPRS; segue il passaggio del MN dalla Visited GPRS alla Visited
WLAN e ritorno. Tale passaggio è effettuato variando la priorità delle due
interfacce.
Parametri variati:
-
-
dimensione dei segmenti UDP: 128 byte, 256 byte
-
117
Queste prove confermano l’andamento visto nel paragrafo precedente; la perdita di
pacchetti inizia ad essere misurabile ma gli handover non producono una perdita
maggiore rispetto a quella che si ha normalmente nel corso della trasmissione dati.
118
4.5 – Prestazioni limite di Mobile IPv6
I risultati ottenuti nelle prove WLAN-GPRS mostrano come Mobile IPv6 riesca a
gestire un handover tra reti di accesso eterogenee in maniera ottimale, molto spesso
senza perdere alcun pacchetto nel passaggio tra le reti.
Si può supporre che con un’interfaccia con prestazioni migliori di quella GPRS si
possano ottenere tali risultati anche a data rate maggiori, riuscendo quindi a
supportare ogni tipo di applicazione, incluse quelle real-time.
E’ quindi molto interessante andare ad analizzare le prestazioni limite di Mobile
IPv6, in presenza di due interfacce ad alte prestazioni.
Descrizione: il MN ha due interfacce WLAN, associate rispettivamente presso la
Home e la Visited Network; la priorità iniziale è in favore dell’interfaccia associata
alla Home Network. Il CN invia traffico UDP al MN nella Home Network; segue il
passaggio del MN dalla Home alla Visited Network e ritorno. Tale passaggio è
effettuato variando la priorità delle due interfacce.
Parametri variati:
-
bandwidth dell’Access Point: 11 Mbps
-
-
dimensione dei segmenti UDP: 1024 byte
119
Come si può vedere dalla figura la ricezione dei dati è continua anche durante gli
handover e non si perde neanche un pacchetto.
Da queste prove risulta l’importanza di avere due interfacce ad alte prestazioni per
garantire un handover realmente trasparente all’utente; sicuramente è poco
realistico pensare che le due interfacce siano omogenee, ma anche con due
interfacce eterogenee (WLAN-GPRS o WLAN-UMTS) le prestazioni di Mobile
IPv6 consentono di arrivare a non perdere neanche un pacchetto di dati durante il
passaggio tra le reti.
120
Capitolo 5 –Conclusioni e sviluppi futuri
Capitolo 5
Conclusioni e sviluppi futuri
121
5.1 - Conclusioni
L’analisi delle prove sperimentali effettuate nei vari Testbed illustrati nel capitolo
precedente consente di affermare che Mobile IPv6 è il protocollo ottimale per
gestire la mobilità tra reti eterogenee.
Le sue prestazioni in termini di tempo di handover e pacchetti persi, la sua facilità
di implementazione, l’ottimizzazione dell’instradamento dei dati sono tutti fattori
che evidenziano l’opportunità della sua scelta in un progetto di integrazione
WLAN-UMTS.
Le prove effettuate con interfaccia singola WLAN per il Nodo Mobile hanno
mostrato tempi medi di handover inferiori ai 2 secondi. Il numero di pacchetti persi
durante l’handover è direttamente proporzionale alla durata del tempo di handover.
Tali prove hanno inoltre mostrato che il tempo di handover è, per i data rate presi in
considerazione, indipendente dal data rate e dalla dimensione dei pacchetti, mentre
risulta dipendente dal bandwidth 802.11b scelto.
Con queste prestazioni è possibile supportare la quasi totalità delle applicazioni;
anche uno streaming video, con un opportuno pre-buffering, viene gestito in
maniera ottimale, senza che l’utente percepisca l’avvenuto passaggio tra reti di
accesso differenti.
I risultati di maggiore interesse sono senz’altro quelli che fanno riferimento alle
prove con interfacce multiple. Nonostante la rete pubblica GPRS non abbia
prestazioni ottimali (Round Trip Time medio superiore al secondo, con deviazione
standard molto elevata), le prove di handover WLAN-GPRS hanno mostrato
l’efficacia di Mobile IPv6 nel gestire interfacce multiple. Durante l’handover si
instaura un meccanismo di simultaneità in ricezione/trasmissione sulle due
interfacce che risulta in una perdita di pacchetti uguale a zero nella quasi totalità
delle prove fatte. Con queste prestazioni gli handover avvengono in maniera del
122
tutto trasparente per l’utente ed è pensabile che si possano supportare anche
applicazioni real-time.
Le prove effettuate con agenti Mobile IPv6 a Strasburgo, con segnalazione MIPv6
instradata dalla rete Internet, hanno mostrato un aumento contenuto del tempo di
handover e del numero di pacchetti persi e, soprattutto, una maggiore variabilità dei
risultati; ciò del tutto in accordo con la variabilità intrinseca delle condizioni di
carico della rete Internet.
Le prestazioni ottenute negli handover WLAN-GPRS fanno supporre che
disponendo di una seconda interfaccia con prestazioni migliori di quella GPRS, ad
esempio un’interfaccia UMTS, si possa arrivare a non perdere mai dati durante gli
handover. Tale ipotesi sembra trovare conferma nell’ultima delle prove effettuate,
con due interfacce WLAN 802.11b; tale prova mira a valutare le prestazioni limite
di Mobile IPv6. Ciò che è stato ottenuto è che anche durante gli handover la
ricezione dei dati è continua e non viene perso alcun pacchetto.
123
5.2 – Sviluppi futuri
Gli sviluppi futuri più plausibili per questo progetto sono i seguenti:
•
Testbed integrato WLAN-UMTS: ciò non appena sarà disponibile una
rete pubblica UMTS sul territorio europeo.
•
Handover verticale tra differenti tipi di reti eterogenee: Mobile IPv6
prescinde dalle reti di accesso tra le quali deve gestire gli handover; può
essere di interesse valutare le sue prestazioni con differenti tipi di reti
eterogenee.
•
Gestione della micromobilità: esistono dei protocolli sperimentali che
estendono le funzionalità Mobile IPv6 al fine di migliorarne ulteriormente
le prestazioni; progettare e realizzare un testbed per misurarne le prestazioni
è un’ulteriore direzione di sviluppo del presente progetto.
124
Appendice A – Procedure di installazione e configurazione Testbed Mobile IPv6
Appendice A
Procedure di installazione e configurazione
Testbed Mobile IPv6
125
Di seguito sono riportate le caratteristiche essenziali affinché i nodi ipv6, siano essi
router o host, abbiano le funzioni necessarie a supportare la mobilità.
Oltre le suddette caratteristiche sono descritte le procedure d’installazione e
configurazione da seguire per poter creare un Test Bed WLAN con supporto
Mobile IPv6……
A.1 – Procedure d’installazione Mobile IPv6
Le seguenti procedure sono essenziali per ogni successiva configurazione.
Per ottenere un risultato positivo, accertarsi che le procedure seguite siano tutte
andate a buon fine.
Per creare il Testbed Mobile IPv6 ho utilizzato macchine Linux con funzionalità di
routing.
La distribuzione Linux da me installata è Red Hat 8.0 (kernel 2.4.18-14)
La versione di MIPL (Mobile IPv6 for Linux) che ho utilizzato è la 0.9.4.
Le procedure da seguire sono le seguenti:
1. Durante l’installazione di Red Hat 8.0 selezionare (per le macchine con
funzionalità di Access Router) radvd tra i servizi.
2. A sistema avviato caricare il modulo ipv6 con il comando modprobe ipv6
3. Modificare il file ‘/etc/sysconfig/network’ aggiungendo
‘NETWORKING_IPV6=yes’
4. Modificare in ‘/etc/sysconfig/network-scripts/’ i file ‘ifcfg-eth0’ e ‘ifcfgeth1’ (e per ogni altra interfaccia su cui volete abilitare IPv6) aggiungendo
IPV6ADDR=<indirizzo ipv6 dell’interfaccia> (non serve se è ricvato in
modalità stateless)
5. Nello stesso file aggiungere IPV6INIT=yes
6. Verificare il corretto funzionamento del networking IPv6 (es. ping6 ::1)
A.1.1 - Installazione del modulo Mobile IPv6
1. Scaricare l’ultima versione di MIPL da www.mipl.mediapoli.com
126
2. Copiare il file .patch in /usr/src/linux
3. In usr/src/linux fare:
a.
patch -p1 --dry-run < mipv6-0.9.4-v2.4.19.patch (prova la patch,
non deve dare “failed hunks”)
b.
patch -p1 < mipv6-0.9.4-v2.4.19.patch (applica la patch)
c.
make mrproper
d.
make ./config
-devi settare: CONFIG_IPV6_IPV6_TUNNEL =m
CONFIG_IPV6_MOBILITY= m
4. copia il file ipv6_tunnel.h da /usr/src/linux-2.4/include/linux in
/usr/include/linux (a meno che già non sia presente nella directory di
destinazione)
5. Ritorna in usr/src/linux
a. make xconfig (Controllare nelle opzioni di networking che le voci
riguardanti Mobile IPv6 siano settate come indicato in precedenza,
quindi fare “Save and exit”)
b.
make dep (Controlla le dipendenze tra i moduli)
c.
make clean
6. Apri con gedit il file /usr/src/linux-2.4/Makefile e metti mipv6 al
posto di custom (E’ il nome dell’immagine del kernel che apparirà
all’avvio)
6. make bzImage (Crea la nuova immagine del kernel)
7. make modules (Compila i moduli precedentemente selezionati,
procedura che dura qualche ora)
8. make modules_install (Installa i moduli)
9. make install
10. apri con Gedit /boot/grub/grub.conf : modifica l’ordine di avvio
11. torna nella directory dove hai spacchettato MIPL ed esegui:
a. ./configure
b. apri con Gedit il Makefile e modifica la directory del “man” in
/usr/share/man
c. make
d. make install
e. mknod /dev/mipv6_dev c 0xf9 0
127
A.1.2 - Configurazione di un Nodo Mobile
I seguenti requisiti fanno di qualunque nodo ipv6 un nodo mobile:
• Deve utilizzare il meccanismo dinamico di scoperta dell’indirizzo ip dell’Home
Agent.
• Deve supportare l’invio di Binding Update Option e il processamento di Binding
Ack ricevute.
• Deve mantenere una lista di Binding Update.
Questo è un esempio del file di configurazione Mobile IPv6 per un Nodo Mobile:
---------------------------------------------------------------#/etc/sysconfig/network-mip6.conf
# MIPL Mobile IPv6 Configuration file
# Per dargli la funzionalità di Correspondent node
FUNCTIONALITY=mn
# questo parametro aumenta il numero di informazioni di cosa
# succede nelle situazioni d’errore.
DEBUGLEVEL=5
# Should unicasts to node's site-local address be tunneled when
# mobile node is not in its home network (default: yes).
TUNNEL_SITELOCAL=yes
# Minimum number of free tunnel devices kept in cache on MN or HA
# Must be set to at least 1 for MN and HA. To ensure successful
# bindings even during high work loads it could be set to a bigger
# value on the HA.
MIN_TUNNEL_NR=5
# Maximum number of free tunnel devices kept in cache on MN or HA
# Must be set to at least 1 for MN and HA. To improve performance
# set it higher than MIN_TUNNEL_NR
MAX_TUNNEL_NR=20
128
# Should MN use reverse tunnel for communication with CN (default:
# no)
#USE_REVERSE_TUNNEL=no
# L’Home address del nodo mobile con la lunghezza del prefisso di
# rete
HOMEADDRESS=2001:660:220:112::4/64
# L’indirizzo dell’access router che ha funzionalità di Home Agent
per il mobile node.
HOMEAGENT=2001:660:220:112::4/64
----------------------------------------------------------------------------------------------Tutto ciò che segue nel file può essere commentato, poichè non è indispensabile al
funzionamento della procedura.
A.1.3 - Configurazione di un Home Agent
Un router Ipv6 per funzionare da Home Agent deve possedere i seguenti requisiti:
• Deve essere capace di inviare ad intervalli regolari i suoi router advertisement.
• Deve mantenere una riga nella sua Binding Cache per qualsiasi nodo mobile,
lontano da casa, per cui sta svolgendo il ruolo di Home Agent (vedi comando
mipdiag -c).
• Utilizzando il Proxy Neighbor Discovery, deve essere in grado di intercettare
tutti quei pacchetti che sono indirizzati all’Home Address del nodo mobile lontano
da casa per cui sta svolgendo la funzione di HA.
• Deve poter incapsulare i suddetti pacchetti per inoltrarli al Care of Address del
nodo mobile.
• Deve infine mandare Binding Ack se è richiesta nella Binding Update ricevuta.
Questo è un esempio del file di configurazione Mobile IPv6 per un Home Agent:
129
FUNCTIONALITY=ha
# questo paramentro aumenta il numero di informazioni di cosa
DEBUGLEVEL=5
# Può essere commentato
#TUNNEL_SITELOCAL=yes
# value on the HA.
#MIN_TUNNEL_NR=5
#MAX_TUNNEL_NR=20
no)
# Home address for mobile node with prefix length. Example:
# 3FFE:2620:6:1234:ABCD::1/48 (Don't use the example value!)
#HOMEADDRESS=fec0::1/10
# Home agent's address for mobile node with prefix length.
#HOMEAGENT=fec0::2/10
-------------------------------------------------------------------
Tutto ciò che segue nel file può essere commentato, poiché non è indispensabile al
130
Il radvd deve essere lanciato come modulo nelle machine con funzionalità Home
Agent e in tutti gli Access router.
Di seguito sono evidenziate le modifiche apportate al file di configurazione:
---------------------------------------------------------------------------------------------------# /etc/radvd.conf
# questo script è stato fatto per far prendere lo stateless CoA al
# mobile node sull'interfaccia GPRS, che ha un tunnel, vedi il
# testbed per chiarimento
# inserire l’identificativo di interfaccia sulla quale si vogliono
#inviare router advertisements
interface eth1
{
AdvSendAdvert on;
);
# These settings cause advertisements to be sent every 3-10
seconds.
This
# range is good for 6to4 with a dynamic IPv4 address, but can be
greatly
# increased when not using 6to4 prefixes.
# I valori indicate sotto sono consigliati per Mobile IPv6
MinRtrAdvInterval 0.05;
MaxRtrAdvInterval 1.5;
#
# Disable Mobile IPv6 support
#
AdvHomeAgentFlag off;
#
# Esempio di prefisso di rete mandato dall’ access router con i
# RAs in modo che il MN crei l’indirizzo stateless
#
prefix 2001:660:220:108::/64
{
AdvOnLink on;
AdvAutonomous on;
131
AdvRouterAddr on;
};
-------------------------------------------------------------------------------------------------
A.1.4 - Configurazione di un Correspondent Node
Qualsiasi nodo IPv6, sia esso mobile o fisso può essere un correspondent node a
patto che possegga i seguenti requisiti:
•
Deve saper processare un Home Adress Option ricevuto da qualsiasi nodo IPv6,
in modo da rendere trasparente la mobilità ai livelli superiori.
•
Deve saper processare una Binding Update e ritornare una Binding Ack se è
richiesta.
•
Deve mantenere una Binding Cache.
Questo è un esempio del file di configurazione Mobile IPv6 per un Correspondent
Node:
FUNCTIONALITY=cn
# questo paramentro aumenta il numero di informazioni di cosa
DEBUGLEVEL=5
# Può essere commentato
#TUNNEL_SITELOCAL=yes
# value on the HA.
#MIN_TUNNEL_NR=5
132
#MAX_TUNNEL_NR=20
no)
# Home address for mobile node with prefix length. Example:
# 3FFE:2620:6:1234:ABCD::1/48 (Don't use the example value!)
#HOMEADDRESS=fec0::1/10
# Home agent's address for mobile node with prefix length.
#HOMEAGENT=fec0::2/10
Tutto ciò che segue nel file può essere commentato, poiché non è indispensabile al
-------------------------------------------------------------------
A.1.5 – Creazione di un tunnel GRE IPv6 in IPv4
Nelle prove che ho svolto ho avuto la necessità di collegare il Testbed realizzato
presso ELIS LAB sia con quello dell’Univeristà di Strasburgo, sia con la rete GPRS
di TIM. Per collegare due “isole” IPv6 attraverso Internet è necessario creare un
tunnel tra queste due isole, incapsulando i pacchetti IPv6 in pacchetti IPv4.
Questi sono i comandi da eseguire per creare un tunnel GRE IPv6 in IPv4
iptunnel add tunnelgprs remote 217.201.8.12 local 62.110.204.29
mode sit ttl 128
ifconfig tunnelgprs up
ifconfig tunnelgprs inet6 add 2001:660:220:108::3/64
ip -6 r a default dev tunnelgprs
133
A.2
– Procedura di installazione e configurazione
scheda GPRS Nokia D211
Nel Testbed integrato WLAN-GPRS ho utilizzato, per la parte GPRS, una scheda
pcmcia Nokia D211.
I driver installati per la scheda Nokia D211 sono la versione 1.04 per Linux con
kernel 2.4.18-14
Le procedure da seguire sono le seguenti:
1. esplodere i due files drivers src e binari nella cartella
/usr/src/d211/
2. modificare il file config.mk.orig come segue e rinominarlo config.mk
a. LINUX = /usr/src/linux-2.4.18-14
b. OS_RELEASE= 2.4.18-14version
3. entrare nella cartella /usr/src/d211/
4. digitare 'make clean' se non si sta installando i drivers per la prima volta
5. digitare 'make all' per copiare lo script di default nokia_cs. Questo
comando sovrascriverà la configurazione precedente. E’ conveniente
lanciarlo solo alla prima installazione dei drivers.
6. digitare 'make install'
7. copiare il modulo 'memory_cs.o' nella cartella
/lib/modules/2.4.18-14custom/pcmcia/ perché purtroppo il driver
non lo fa.
8. riavviare il sistema e verificare che all'avvio faccia i toni di
inizializzazione della carta alti 'beep beep'
134
A.2.1 – Script di configurazione della scheda e attivazione del GPRS
------------------------------------------------------------------# disattiva la modalità WLAN della scheda NOKIA D211
nokia_ctl disable_wlan
# attiva la modalità
GSM della scheda NOKIA D211
nokia_ctl enable_gsm
# accende il terminale GSM e si registra in rete TIM
nokia_ctl gsm enableGSMradio
# copia un file di configurazione GPRS nella posizione opportuna in
# quanto a causa di un malfunzionamento del programma wvdial quando
# cade la linea GPRS il file viene modificato con errori
cp -f /root/GPRS/wvdial.conf /etc/
# attende 9 secondi per far registrare il terminale in rete
sleep 9
# lancia il programma per attivare la connessione ppp GPRS di TIM
# (vedi il file wvdial.conf)
wvdial gprs tim
# cancella il tunnel eventualmente rimasto attivo dalla precedente
# connessione
iptunnel del sit1
-------------------------------------------------------------------
A.2.2 – Script di configurazione per l’attivazione del tunnel sulla
connessione PPP0
------------------------------------------------------------------# Abbassa l'interfaccia eth1
ifdown eth1
# aggiunge il tunnel ipv6-in-ipv4 (l'indirizzo locale viene
# assegnato dinamicamente con DHCP)
iptunnel add sit1 remote 130.79.90.178 local 217.201.3.33 mode sit
ttl 128
ifconfig sit1 up
# attiva il mobile IPv6
/etc/init.d/mobile-ip6 stop
/etc/init.d/mobile-ip6 start
# setta le priorità delle interfacce in Mobile IPv6 (sit1 ha
135
# priorità maggiore)
mipdiag -i sit1 -P6
mipdiag -i eth2 -P5
-------------------------------------------------------------------
A.2.3 – Parti essenziali del file /root/GPRS/wvdial.conf
------------------------------------------------------------------#general configurations for GPRS connections [Dialer gprs]
#starts ppp immediately after connect (used always with GPRS!!!!)
Stupid Mode = yes
#another GPRS configuration
[Dialer tim]
Init4 = AT+CGDCONT=1,"IP","uni.tim.it"
Phone = *99#
Username = 338XXXXXX
password = xxxxxxxxx
#
# FILE /etc/ppp/options
#
lock
/dev/ttyNC0
crtscts
57600
noipdefault
noauth
ttyNC0
debug
kdebug 1
novj
novjccomp
-------------------------------------------------------------------
136
Alcuni comandi utili:
Nel caso in cui la scheda GPRS non dovesse funzionare dopo un collegamento ppp
non andato a buon fine, per resettare le schede PCMCIA digitare:
/etc/init.d/pcmcia stop
/etc/init.d/pcmcia start
137
Ringraziamenti
Ringraziamenti
Intendo ringraziare tutti coloro che hanno dato piccoli e grandi contributi a questo
lavoro di tesi.
In primo luogo Roberto e Mario con i quali ho condiviso momenti esaltanti e
superato periodi di difficoltà nei sette mesi passati in ELIS per completare questo
progetto.
Poter contare su un relatore con una grande esperienza ed una grande affabilità è un
privilegio che auguro a tutti; per questo ringrazio sentitamente il professor
Alessandro Neri.
Ringrazio Giuseppe Cinque per avermi fornito un supporto continuo durante tutta la
mia permanenza presso il Consorzio ELIS ed avermi stimolato con suggerimenti
preziosi.
Nell’ultimo periodo del progetto ha seguito il mio lavoro con assiduità,
revisionandolo anche mentre si trovava all’altro capo del mondo; un sentito
ringraziamento all’ing. Carli.
Un grazie anche a tutti i miei amici più cari per aver sopportato la mia latitanza,
specialmente nell’ultimo periodo. Sono comunque sicuro che mi hanno già
perdonato…
La mia famiglia è stata fondamentale per avermi permesso di concludere nel
migliore dei modi la mia carriera universitaria, mi è sempre stata vicina dandomi
affetto e sicurezza in ogni momento: un grazie di cuore.
Ringrazio infine Irene, che illumina ogni mio giorno con il suo splendido sorriso,
regalandomi sempre felicità vera.
138
Abbreviazioni
Abbreviazioni
AAA
Authentication Authorizing Accounting
ACK
Acknowledgment
AES
Advanced Encryption Standard
AP
Access Point
AR
Access Router
AuC
Authentication Center
BSS
Basic Service Set
BU
Binding Update
CCK
Complementary Code Keying
CN
Correspondent Node
CoA
Care of Address
CRRM
Common Radio Resource Manager
CSMA/CA
Carrier Sense Multiple Access / Collision Avoidance
CSMA/CD
Carrier Sense Multiple Access / Collision Detection
DCF
Distributed Coordination Function
DSSS
Direct Sequence Spread Spectrum
EAP
Extensible Authentication Protocol
EAPOL
Extensible Authentication Protocol Over LAN
ESS
Extended Service Set
FHSS
Frequency Hopping Spread Spectrum
GGSN
Gateway GPRS Support Node
GTP
GPRS Tunneling Protocol
HA
Home Agent
HLR
Home Location Register
IAPP
Inter Access Point Protocol
IMSI
International Mobile Subscriber Identity
IWU
Inter Working Unit
LEAP
Lightweight Extensible Authentication Protocol
MAC
Medium Access Control
MAP
Mobility Anchor Point
139
Abbreviazioni
MIP
Mobile IP
MN
Mobile Node
NAI
Network Access Identifier
OFDM
Orthogonal Frequency Division Multiplexing
PAN
Personal Area Network
PCF
Point Coordination Function
PDP
Packet Data Protocol
RA
Router Advertisement
RADIUS
Remote Access Dial In User Service
RNC
Radio Network Controller
RNS
Radio Network Subsystem
RTS/CTS
Request To Send / Clear To Send
SGSN
Serving GPRS Support Node
SIM
Subscriber Identity Module
SSID
Service Set ID
STA
Wireless Station
TKIP
Temporal Key Integrity Protocol
UE
User Equipment
UTRAN
UMTS Terrestrial Radio Access Network
VLR
Visitor Location Register
VPN
Virtual Private Networks
WCDMA
Wideband Code Division Multiple Access
WEP
Wired Equivalent Privacy
WLAN
Wireless Local Area Network
WPA
Wireless Protected Access
140
Bibliografia
Bibliografia
[1]
3GPP – “Network architecture (Release 5)”, 3GPP TS 23.002, 2002
[2]
3GPP – “General UMTS architecture (Release 4)”, 3GPP TS 23.101, 2001
[3]
3GPP – “UTRAN overall description (Release 5)”, 3GPP TS 25.401, 2001
[4]
3GPP – “Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3; (Release 5)”, 3GPP TS 24.008, 2002
[5]
ETSI – “Digital cellular telecommunications system (Phase 2+); General
Packet Radio Service (GPRS); Service description; Stage 2”, ETSI EN
301.344, v7.4.1, September 2000
[6]
ETSI – “Digital cellular telecommunications system (Phase 2+); General
Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the
Gn and Gp Interface”, ETSI EN 301.347, v7.5.1, December 2000
[7]
Christian Bettstetter, Hans-Jorg Vogel, Jorg Eberspacher – “GSM Phase 2+
General Packet Radio Service GPRS: Architecture, Protocols, and Air
Interface”, IEEE Communications Surveys, 1999
[8]
IEEE – “Standard for Information Technology - Telecommunications and
information exchange between systems - Local and Metropolitan Area
networks - Specific requirements - Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications”, IEEE Std
802.11, 1999
141
Bibliografia
[9]
Control (MAC) and Physical Layer (PHY) specifications - High-speed
Physical Layer in the 5 GHz Band”, IEEE Std 802.11a, 1999
[10]
Control (MAC) and Physical Layer (PHY) specifications - High-speed
Physical Layer Extension in the 2.4 GHz Band”, IEEE Std 802.11b, 1999
[11]
IEEE - “Draft Supplement to ANSI/IEEE Std 802.11-1999 - Further HigherSpeed Physical Layer Extension in the 2.4 GHz Band 2003”, IEEE Std
802.11g/D6.1, 2003
[12]
ETSI – “Requirements and Architecture for Interworking between
HIPERLAN/2 and 3rd Generation Cellular systems”, ETSI TR 101.957, 2001
[13]
3GPP – “Feasibility study on 3GPP system to Wireless Local Area Network
(WLAN) interworking (Release 6)”, 3GPP TR 22.934, 2002
[14]
S. Deering, R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”,
Internet Standard IETF RFC 2460, December 1998
[15]
C. Perkins – “IP Mobility Support for IPv4”, Internet Standard IETF RFC
3344, August 2002
[16]
J.Manner, M. Kojo – “Mobility Related Terminology”, Internet Draft IETF
draft-ietf-seamoby-mobility-terminology-01.txt, November 2002
[17]
David B. Johnson, Charles E. Perkins, Jari Arkko – “Mobility Support in
IPv6”, Internet Draft IETF draft-ietf-mobileip-ipv6-20.txt, January 2003
142
Bibliografia
[18]
Hesham Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier –
“Hierarchical Mobile IPv6 mobility management (HMIPv6)”, Internet Draft
IETF draft-ietf-mobileip-hmipv6-07.txt, October 2002
[19]
Rajeev Koodli – “Fast Handovers for Mobile IPv6”, Internet Draft IETF
draft-ietf-mobileip-fast-mipv6-05.txt, September 2002
[20]
J. Arkko, V. Devarapalli, F. Dupont – “Using IPsec to Protect Mobile IPv6
Signaling between Mobile Node and Home Agents”, Internet Draft IETF
draft-ietf-mobileip-mipv6-ha-ipsec-03.txt, February 2003
[21]
G. Wu, P. Havinga, M. Mizuno – “MIRAI Architecture for Heterogeneous
Network”, IEEE Communications Magazine, February 2002
[22]
Nicolas Montavont, Thomas Noel – “Handover management for Mobile
Nodes in IPv6 Networks”, IEEE Communications Magazine, August 2002
[23]
Juha Wiljakka - “Transition to IPv6 in GPRS and WCDMA Mobile
Networks”, IEEE Communications Magazine, April 2002
[24]
N. A. Fikouras, K. El Malki, S. R. Cvetkovic, C. Smythe – “Performance of
TCP and UDP during Mobile IP Handoffs in Single-Agent Subnetworks”,
1999
[25]
IEEE, “Standard for Local and Metropolitan Area Networks – Port-Based
Network Access Control,” IEEE std 802.1X-2001, June 2001
[26]
IEEE, “Draft Supplement to Standard for Telecommunications and
Information Exchange Between Systems—LAN/MAN Specific
Requirements—Part 11: Wireless Medium Access Control (MAC) and
physical layer (PHY) specifications: Specification for Enhanced Security,"
IEEE Std 802.11i/D3.0, Draft supplement to IEEE std 802.11, 2002 Edition,
work in progress
143
Bibliografia
[27]
H. Haverinen and J. P. Edney, “Use of GSM SIM Authentication in IEEE
802.11 System,” IEEE cont., 01/039 Task Group E, January 2001.
[28]
H. Haverinen and J. Salowey , “EAP SIM Authentication,” Internet draft
draft-haverinen-pppext-eap-sim-09.txt, IETF, January 2003, work in
progress.
[29]
T. Boström, T. Goldbeck-Löwe and R. Keller, “Ericsson Mobile Operator
WLAN solution,”Ericsson Rev., no. 1/2002, pp. 36-43.
[30]
H. Andersson et al., “Protected EAP Protocol (PEAP),” Internet draft draftjosefsson-pppext-eap-tls-eap-05.txt, IETF, September 2002, work in
progress
[31]
Cisco Systems, “802.11i Secure SMS based One Time Password
Authentication,” 3GPP TSG-SA WG2 meeting #26, 3GPP doc no. S2022149, August 2002, Toronto, Canada.
[32]
A. Buckley et al., “EAP SIM GMM Authentication” Internet draft draftbuckley-pppext-eap-sim-gmm-00.txt, IETF, August 2002, work in progress.
[33]
C. Rigney et al., “Remote Autenthication Dial In User Service (RADIUS),”
ietf rfc 2865, June 2000.
[34]
C. Rigney, “Radius Accounting,” IETF RFC 2866, June 2000.
[35]
C. Rigney, W. Williat, and P. Calhoun, “RADIUS Extension,” IETF RFC
2869.
144
Bibliografia
[36]
B. Aboba et al., “Review of Roaming Implementations,” IETF RFC 2194,
September 1997.
[37]
L. Blunk and J. Vollbrecht, “PPP Extensible Authentication Protocol
(EAP),” IETF RFC 2284, March 1998.
[38]
B. Aboba and M. Beadles, “The Network Access Identifier,” IETF RFC
2486, January 1999.
145

Gestione della mobilità in ambiente misto Internet

Transcript

Documenti analoghi

IPv6, qui si dorme - The New Blog Times

30.10.2015 - Giorgio Roverato

I` TG C Cerboni

Titel IPv6 nella tua rete: esperienze di vita reale con FRITZ!Box

A3 PUBBLICITA` PON FSE 2015 LAN WLAN

Rapporto sullo stato di Internet | Infografica sull`Europa Q1

Enrico - Associazione Grande Mauro