Elaborato Napolano Mirko N46000442

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Protocolli per Reti Mobili
Low-Latency Handoffs in Mobile IPv4
Anno Accademico 2011/2012
Candidato:
MIRKO NAPOLANO
matr. N46000442
Indice
Introduzione
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
1 Mobile IP
1.1 Il funzionamento standard . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Le modifiche al protocollo . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
2 L’handoff e le soluzioni proposte dall’IETF
2.1 Il problema dell’handoff . . . . . . . . . . . .
2.2 Pre-Registrazione . . . . . . . . . . . . . . . .
2.2.1 Funzionamento . . . . . . . . . . . . .
2.2.2 Considerazioni . . . . . . . . . . . . . .
2.3 Post-Registrazione . . . . . . . . . . . . . . .
2.3.1 Primo scenario: Two Party Handoff . .
2.3.2 Secondo scenario: Three Party Handoff
2.3.3 Considerazioni . . . . . . . . . . . . . .
2.4 Metodo combinato . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
10
15
16
17
24
27
28
3 Altre tecniche proposte
29
4 Conclusioni
31
II
Introduzione
Negli ultimi anni le reti WLAN dello standard IEEE 802.11 si sono diffuse enormemente permettendo la creazione di numerosi punti d’accesso wireless alla rete
Internet. Il principale vantaggio delle WLAN è la mobilità concessa agli utenti, che
possono spostarsi all’interno dell’Extended Service Set (ESS), definito tramite gli
Access Point dei vari Basic Service Set (BSS), semplicemente deassociandosi e associandosi ai vari AP, senza dover effettuare modifiche dal punto di vista del livello
rete; ciò consente ad un nodo di poter conservare il proprio indirizzo IP e, quindi, di
mantenere attive le connessioni a livello trasporto. Nel caso in cui, invece, il nodo
si sposti in una nuova sottorete è necessario che ad esso venga assegnato un nuovo
indirizzo di livello rete per poter comunicare con altri nodi della rete Internet, dal
momento che il protocollo IPv4 prevede di utilizzare l’indirizzo IP non solo come
identificativo ma anche come informazione d’instradamento. Ciò comporta, in seguito all’handoff di livello rete, cioè allo spostamento da una sottorete ad un’altra, che
i nodi in comunicazione con il nodo mobile non saranno più in grado di localizzarlo,
a causa del cambiamento dell’indirizzo IP, e che quindi le eventuali connessioni TCP
aperte verranno chiuse. Una soluzione valida per questo problema è Mobile IPv4:
esso fornisce una serie di meccanismi basati sul preesistente protocollo IPv4 per
permettere ad un nodo mobile di essere rintracciato anche al di fuori della propria
sottorete. Il problema che sorge in questo contesto è che durante l’handoff subentra
un ritardo di comunicazione tra il nodo mobile e gli altri nodi con cui esso era in
contatto precedentemente. Quest’aumento della latenza rappresenta un aspetto critico nel caso di applicazioni multimediali in rete come la telefonia VoIP, lo streaming
video o il gaming online. Ciò che viene mostrato in quest’elaborato, dopo aver presentato brevemente la problematica introdotta dallo standard Mobile IP, sono due
meccanismi proposti successivamente ad esso dall’IETF (Internet Engineering Task
Force) per ridurre la latenza durante l’handoff del nodo mobile.
4
Capitolo 1
Mobile IP
1.1
Il funzionamento standard
La soluzione del Mobile IPv4 cominciò ad essere studiata nei primi anni Duemila, ovvero nel momento in cui i terminali mobili che usufruivano della rete Internet cominciavano ad essere sempre più. Più precisamente, tale soluzione è stata
standardizzata nella RFC 3344 del 2002 [1].
L’elemento che sta alla base del Mobile IP è il Mobility Agent: esso non è altro
che un router della sottorete, che solitamente fa anche da gateway per la stessa, che
ha il compito di tenere traccia degli spostamenti dei nodi mobili nella propria sottorete e di fare da tramite per le loro comunicazioni. In particolare, l’Home Agent
mantiene informazioni sulla posizione di un dato nodo mobile, e quando il nodo non si
troverà nella sottorete originaria (Home Network) avrà il compito d’inoltrargli i pacchetti ad esso destinati. Analogamente, l’agente della rete visitata dal nodo (Foreign
Agent) riceverà i pacchetti destinati al nodo mobile e avrà il compito di consegnarglieli. Per realizzare questo meccanismo è necessario che il nodo mobile comunichi
all’Home Agent il Care-Of-Address (COA), ovvero l’indirizzo IP assegnatogli dalla
Foreign Network in cui il nodo si trova; dopodichè i pacchetti inviati all’indirizzo
originario del nodo mobile, l’Home Address, dovranno essere redirezionati verso il
nuovo COA del nodo.
La prima fase, quindi, è quella dell’Agent Discovery, in cui il nodo mobile deve
verificare, a partire dalla comunicazione con un determinato agent, se è giunto in
una nuova Foreign Network. Ciò avviene solitamente tramite un messaggio di Agent
Advertisement inviato dall’agent, che rappresenta un messaggio ICMP di Router
Advertisement con l’aggiunta di alcuni campi per il Mobile IP; in particolare in
tale messaggio sono indicati l’indirizzo IP dell’agent, una lifetime di validità del
messaggio e un COA disponibile per la sottorete. In base al valore di una lifetime
scaduta o dell’indirizzo di un agente diverso da quello noto il nodo si accorge di
trovarsi in una nuova rete.
La seconda fase è la Registration, che consente al nodo di identificarsi tramite
il COA e di comunicare tale informazione al proprio Home Agent. La registrazione
avviene tramite uno scambio di due messaggi con il Foreign Agent, uno di richiesta e uno di risposta. La Registration Request viene inviata dal nodo mobile ed è
indirizzata all’Home Agent: con essa il nodo comunica l’Home Address e il COA.
Dualmente, l’Home Agent risponde con un messaggio di Registration Reply indiriz5
Facoltà di Ingegneria - Corso di Studi in Ingegneria Informatica
zato al nodo mobile in cui ricomunica l’Home Address e il suo indirizzo IP. Questo
scambio di messaggi può avvenire tramite il Foreign Agent oppure direttamente tra
il nodo mobile e l’Home Agent, a seconda che il nodo utilizzi il COA comunicatogli nell’Agent Advertisement oppure un COA ottenuto con una richiesta DHCP. In
ogni caso, dopo tale comunicazone l’Home Agent possiede una binding list con l’associazione, per ogni nodo mobile, {Home Address, COA} mentre il Foreign Agent
mantiene una visitor list con l’associazione {Home Address, Home Agent, MAC
Address}.
L’ultima fase è il Tunneling, ovvero l’instaurazione di un canale di comunicazione tra l’Home Agent e il Foreign Agent che permetta di recapitare i messaggi
indirizzati originariamente all’Home Address del nodo mobile presso il nuovo COA.
E’ necessario introdurre questo meccanismo in quanto i nodi della rete che stavano
comunicando con il nodo mobile, i corrispondenti, conosceranno solo l’Home Address
e non il COA; questo perchè il protocollo prevede che la mobilità dei nodi sia trasparente per i corrispondenti, per cui si adotta un approccio d’instradamento indiretto,
per consentire ad un nodo di spostarsi presso più reti, senza dover conservare un
numero d’informazioni d’instradamento sempre crescente. La tecnica utilizzata per
effettuare l’instradamento indiretto è il Tunneling IP-in-IP: un nodo corrispondente
invia pacchetti al nodo mobile verso l’Home Address; l’Home Agent fa da proxy
per il nodo mobile, ovvero intercetta i pacchetti ad esso indirizzati (o essendo un
gateway per la sottorete oppure comunicando ai nodi della sottorete tramite un
messaggio ARP gratuito un’associazione {Home Address, Home Agent MAC Address}, in modo da ricevere tutti i pacchetti indirizzati al nodo mobile); incapsula
i pacchetti come payload di datagrammi IP, in cui il sorgente è l’Home Agent e la
destinazione è il Foreign Agent. Presso la Foreign Network, quindi, il Foreign Agent
consulta la visitor list, verificando la corrispondenza {Home Agent, Home Address},
e recapiterà i pacchetti tramite l’indirizzo MAC associato.
1.2
Le modifiche al protocollo
In seguito all’evolversi delle reti Internet e al sorgere di alcuni problemi di sicurezza
sono state apportate delle modifiche al protocollo originario. Una di esse riguarda il
Reverse Tunneling, specificato nell’RFC 3024 [2]. Di base Mobile IP prevede che i
pacchetti del nodo mobile indirizzati verso un nodo corrispondente vengano inviati
direttamente ad esso utilizzando l’Home Address. Ciò rappresenta un problema
nel caso frequente in cui nella sottorete viene adottato un meccanismo d’Ingress
Filtering, che permetta di evitare attacchi IP spoofing, cioè di cambio dell’indirizzo
IP; tale approccio prevede di scartare i pacchetti ricevuti da un indirizzo IP su
un’interfaccia di rete differente da quella usata per inviare i pacchetti con lo stesso
indirizzo, che è ciò che avverrebbe nel caso del Mobile IP nativo, in quanto i pacchetti
inviati dal nodo mobile con l’Home Address dalla Foreign Network avranno lo stesso
indirizzo IP usato dal corrispondente verso la Home Network. Per evitare ciò si
può creare un Reverse Tunneling dal nodo mobile all’Home Agent, che funziona
allo stesso modo del forward tunnel instaurato di base; di fatto, quindi, esiste un
tunnel bidirezionale tra le due entità. In questo modo, se gli agenti supportano tale
6
modalità, i pacchetti indirizzati ai corrispondenti dovranno dapprima passare per la
Home Network e da qui essere instradati verso i nodi finali; quest’approccio aggira
completamente il meccanismo d’Ingress Filtering a scapito del ritardo introdotto da
un percorso di rete più lungo.
Un’altra modifica apportata al Mobile IP è il Tunneling IP-in-UDP, soluzione
proposta nell’RFC 3519 [3]. Questa tecnica è stata progettata in seguito all’introduzione del meccanismo del NAT (Network Address Translation). Esso è un protocollo
che permette ad un certo numero di nodi di una rete locale di avere indirizzi IP privati per essere indirizzati all’interno della sottorete, ma di utilizzare un unico indirizzo
IP pubblico per comunicare con l’esterno; questo meccanismo si è reso necessario nel
momento in cui lo spazio d’indirizzamento a 32 bit del protocollo IP andava esaurendosi. Il router NAT ha quindi il compito di associare ad ogni coppia d’indirizzi
{IP privato, porto privato} la coppia {IP pubblico, porto pubblico}. Il problema
con Mobile IP è che se un nodo mobile si è spostato in una sottorete che utilizza
il NAT non potrà essere individuato solo tramite l’indirizzo IP del NAT. Con l’utilizzo del Tunneling IP-in-UDP, invece, il datagramma viene incapsulato tramite un
header UDP contenente informazioni sui porti sorgente e destinazione. Ciò permette al NAT, cui sono indirizzati i nuovi datagrammi, di risolvere la corrispondenza
utilizzando il porto UDP destinazione e l’Home Address contenuto nel datagramma.
7
Capitolo 2
L’handoff e le soluzioni proposte dall’IETF
2.1
Il problema dell’handoff
In Mobile IP l’handoff rappresenta l’intero processo durante il quale il nodo mobile
passa dalla registrazione presso un Mobility Agent ad un altro e, quindi, durante il
quale non è in grado di ricevere pacchetti dati. La latenza introdotta dall’handoff di
rete dipende anche dall’handoff realizzato a livello datalink, ovvero allo spostamento da una rete d’accesso ad un’altra. Poichè Mobile IP è stato realizzato in modo
indipendente dai protocolli di livello datalink e poichè ciascuno di essi implementa
tecniche di riduzione dell’handoff a livello 2 differenti, è necessario introdurre meccanismi a livello rete che compensino la distanza tra i due livelli. In particolare,
nel caso delle reti WLAN ad infrastruttura, i problemi sono due: in primo luogo,
poichè l’handoff di livello 2 è trasparente ai livelli superiori la sua rilevazione non è
immediata per Mobile IP; in secondo luogo, poichè un nodo può ricevere pacchetti
solo da un access point per volta, potrà comunicare con un nuovo Foreign Agent
solo dopo che sia avvenuto l’handoff di livello 2. Inoltre, il Mobile IP prevede che la
procedura di registrazione avvenga attraverso lo scambio di una coppia di messaggi
tra nodo mobile e agenti; tali pacchetti dovranno essere trasmessi attraverso la rete
in un tempo comunque non trascurabile e variabile, a seconda della congestione della
rete stessa. Durante tutto quest’intervallo di tempo, quindi, il nodo mobile non sarà
in grado di comunicare con altri nodi.
In origine il protocollo Mobile IP non è stato progettato per ridurre la latenza
introdotta dall’handoff in quanto all’epoca non erano ancora presenti applicazioni
real-time che usufruivano della rete Internet come, ad esempio, le audioconferenze
e lo streaming video. Nel caso di applicazioni non dipendenti fortemente dal tempo, come il trasferimento file e il web browsing, la latenza introdotta non ha un
forte impatto sulla qualità della comunicazione. Nel caso, invece, delle suddette
applicazioni real-time il ritardo con cui giungono sui dispositivi i dati richiesti deve
essere minimizzato per far sì che le informazioni ricevute non siano obsolete, e quindi
inutili.
Per venire incontro alle esigenze di riduzione della latenza durante l’handoff IP e
mantenere l’indipendenza dal tipo di tecnologia wireless usata a livello datalink, l’unico aspetto del Mobile IP che può essere modificato riguarda la fase di registrazione
di un nodo presso un Foreign Agent.
8
L’IETF ha proposto a riguardo due tecniche di gestione dell’handoff IP, specificate nell’RFC 4881 [4], che adottano due approcci diametralmente opposti, più una
loro combinazione:
• Pre-Registrazione
• Post-Registrazione
• Metodo combinato
Tali meccanismi si basano sull’utilizzo di trigger di livello 2 , dove per trigger
s’intende un generico segnale che viene inviato dal livello datalink al livello rete in
seguito ad un dato evento di handoff del livello 2. Dal momento che non tutti i protocolli del livello collegamento dispongono nativamente dei trigger, come nel caso
delle reti WLAN 802.11, per poter realizzare queste tecniche di gestione dell’handoff
IP è necessario che venga fornito tale supporto di segnalazione a tutte le reti, indipendentemente dal livello datalink. In particolare, è di utilità alle tecniche esposte
in quest’elaborato il lavoro del working group IEEE 802.21: esso si occupa, infatti,
dello sviluppo di standard per permettere l’interoperabilità tra tipi di reti differenti,
sia 802 sia non 802. Tra gli altri, uno degli obiettivi è proprio la ricerca di un sistema di trigger per i livelli superiori tramite i quali comunicare un imminente handoff
datalink; tale sistema viene realizzato tramite software, in modo da permetterne
l’utilizzo anche a quei protocolli che non prevedono meccanismi nativi di trigger.
Tramite il lavoro dell’802.21, quindi, che esula dalla trattazione di quest’elaborato,
è possibile realizzare i meccanismi di riduzione della latenza proposti dall’IETF su
reti d’accesso differenti tra loro e che non supportano nativamente i trigger L2.
2.2
Pre-Registrazione
Il metodo della pre-registrazione permette ad un nodo mobile di cominciare a registrarsi presso il new Foreign Agent mentre è ancora associato al Foreign Agent della
precedente sottorete. La pre-registrazione presso un Foreign Agent deve avvenire durante l’handoff di livello 2, prima che questo venga completato. Per realizzare ciò è
necessario, come detto, l’uso di trigger a livello datalink che comunichino un handoff
L2 in corso. I trigger di livello 2 saranno generati da eventi differenti, come l’imminente cambiamento di un punto d’accesso di un nodo oppure il completamento di
uno spostamento, e con modalità diverse a seconda dell’implementazione del livello
collegamento; inoltre possono manifestarsi presso il nodo mobile (mobile-initiated)
oppure presso la rete di uno dei due agent (network-initiated), differenziando il caso
in cui sia generato presso l’old Foreign Agent (Source Trigger) oppure presso il new
Foreign Agent (Target Trigger). Per quanto riguarda invece il protocollo Mobile IP
originario, esso non necessita l’introduzione di nuovi messaggi, ma modifica solo in
piccola parte i messaggi di Advertisement e Solicitation aggiungendo delle estensioni.
9
2.2.1 Funzionamento
Il primo passo di questo meccanismo prevede un’interazione tra gli agenti delle due
sottoreti prima che si verifichi l’handoff del nodo mobile. L’old Foreign Agent invia al
new Foreign Agent un messaggio di Agent Solicitation modificato, un Proxy Router
Agent Solicitation (PrRtSol), che contiene un identificativo per il new Foreign Agent.
Quando quest’ultimo riceve il messaggio, invia un messaggio di Agent Advertisement
modificato, un Proxy Router Agent Advertisement (PrRtAdv), in cui comunica il
proprio indirizzo L2.
Per poter rendere subito disponibili al nodo mobile le informazioni sul new Foreign Agent è necessario che ogni Mobility Agent invii periodicamente messaggi di
Solicitation ai suoi Mobility Agent vicini, in modo da creare una tabella degli agenti
vicini (Neighbouring Agents) da cui attingere le informazioni d’indirizzamento
(Fig. 2.1). Tra un messaggio ed un altro l’agent attende un intervallo di tempo pari
ad un valore MIN_SOLICITATION_INTERVAL, che non può essere scelto troppo
piccolo; questo perchè un numero elevato di messaggi comporterebbe uno spreco di
banda per l’invio di messaggi che sono statisticamente ridondanti. Il valore minimo
di default è 1 secondo, anche se è opportuno far variare dinamicamente tale valore in
base alla Lifetime di validità dell’ultimo messaggio di Agent Advertisement ricevuto.
Figura 2.1: Scambio di messaggi tra Neighbouring Agents
10
Premesso ciò, la pre-registrazione avviene come segue:
1. Scambio di messaggi tra l’old Foreign Agent e il nodo mobile:
l’inizio dell”handoff di livello 2 viene segnalato da un segnale di trigger. Nel
caso di un handoff di livello 2 mobile-initiated, il nodo mobile invia all’old
Foreign Agent un messaggio di Proxy Router Solicitation, in cui richiede informazioni riguardo al new Foreign Agent; l’indirizzo IP e quello L2 destinazione
saranno quelli dell’old Foreign Agent. Quest’ultimo ha l’obbligo di rispondere
con un messaggio di Proxy Router Advertisement, in cui comunica al nodo
mobile nell’estensione l’indirizzo L2 del new Foreign Agent; da notare che in
questo caso l’indirizzo L2 sorgente è ovviamente quello dell’old Foreign Agent
mentre l’indirizzo IP è quello del new Foreign Agent.
Nel caso, invece, di un handoff di livello 2 network-initiated, il nodo mobile
riceverà senza sollecitazioni il messaggio di Proxy Router Advertisement, da
parte dell’old Foreign Agent nel caso di un Source Trigger, oppure dal new
Foreign Agent sempre tramite l’old Foreign Agent nel caso di un Target Trigger;
2. Rilevazione del movimento e registrazione attraverso l’old Foreign Agent:
ricevendo il messaggio di Proxy Router Agent Advertisement con le informazioni di un new Foreign Agent, il nodo mobile rileva il movimento presso una
nuova sottorete ed invia un messaggio di Registration Request (RegReq) verso
il new Foreign Agent. Dal momento che l’handoff di livello 2 non è ancora
completato, il messaggio non può essere inviato direttamente al new Foreign
Agent, ma dovrà passare attraverso l’old Foreign Agent. Poichè, però, il new
Foreign Agent riceverà la frame a livello datalink da un’interfaccia dell’old
Foreign Agent, in questo modo non verrebbe a conoscenza dell’indirizzo L2
del nodo mobile; per risolvere questo problema, nel messaggio di registrazione
viene usata un’estensione per inserire l’indirizzo di livello 2 del nodo mobile.
3. Registrazione classica del Mobile IP:
il new Foreign Agent inoltrerà la richiesta di registrazione del nodo mobile
verso l’Home Agent, il cui indirizzo è trasportato come previsto dal Mobile IP
nella Registration Request; l’Home Agent, poi, invierà al new Foreign Agent il
messaggio di Registration Reply (RegRep), da recapitare al nodo mobile. Nel
caso in cui alla ricezione della Registration Reply il nodo mobile non abbia
ancora terminato l’handoff di livello 2, il new Foreign Agent dovrà memorizzare
in un buffer il messaggio inviandoglielo non appena sarà connesso alla rete.
Quest’evento viene reso noto tramite un ulteriore messaggio di trigger L2 presso
il new Foreign Agent. Non appena sarà disponibile, il new Foreign Agent
consegnerà il messaggio di Registration Reply, dopodichè potranno cominciare
ad essere inoltrati i pacchetti dati.
11
Figura 2.2: Metodo della pre-registrazione con trigger mobile-initiated
Figura 2.3: Diagramma temporale con trigger mobile-initiated
12
Figura 2.4: Metodo della pre-registrazione con trigger network-initiated,
caso Source Trigger
Figura 2.5: Diagramma temporale con trigger network-initiated, caso
Source Trigger
13
Figura 2.6: Metodo della pre-registrazione con trigger network-initiated,
caso Target Trigger
Figura 2.7: Diagramma temporale con trigger network-initiated, caso
Target Trigger
14
2.2.2 Considerazioni
Con il metodo della pre-registrazione la latenza introdotta dall’handoff IP viene effettivamente ridotta, in quanto il nodo mobile riceverà il messaggio di Registration
Reply in anticipo rispetto all’approccio di registrazione classico previsto dal Mobile
IP. Dallo scenario si evince che un ruolo importante nella riduzione della latenza
viene giocato dal trigger di livello 2, che rappresenta un prerequisito per la preregistrazione, senza il quale non sarebbe possibile realizzare tale meccanismo. Nel
caso migliore il trigger viene attivato prima che cominci la fase di registrazione classica Mobile IP, in modo che al completamento dell’handoff di livello 2 il nodo mobile
possa ricevere il messaggio di Registration Reply inoltrato dal Foreign Agent. Nel
caso peggiore, invece, il trigger viene scatenato dopo che il messaggio di Registration Reply sia pronto per essergli inviato. E’ importante, quindi, che il messaggio di
Registration Reply venga bufferizzato per un intervallo di tempo quanto più piccolo
è possibile, altrimenti i vantaggi di quest’approccio svaniscono.
Come tutti i pacchetti, anche i messaggi utilizzati per gestire l’handoff possono
essere soggetti a ritardi o a perdite. Nel caso della pre-registrazione, cause di errori
possono essere:
• la perdita del messaggio Proxy Router Solicitation o Proxy Router Advertisement tra nodo mobile e old Foreign Agent;
• la perdita dei medesimi messaggi tra Neighbouring Agents;
• il fallimento della registrazione Mobile IP standard.
In particolare, l’evento più probabile è il primo, visto che sul collegamento wireless
gli errori sono più frequenti di quelli sul collegamento cablato. Per evitare che i
messaggi di Solicitation o di Advertisement possano essere persi nella trasmissione
con il nodo mobile vanificando di fatto i vantaggi di riduzione della latenza della
pre-registrazione, è necessario che su collegamenti poco affidabili vengano inviate più
copie di tali messaggi; se anche questi dovessero andare perduti, il nodo mobile dovrà
inviare, una volta terminato l’handoff L2, un messaggio di Agent Advertisement al
new Foreign Agent effettuando la registrazione standard Mobile IP, eliminando di
fatto il meccanismo di pre-registrazione. Analogamente, nel caso più raro in cui
vengano perduti i messaggi tra Neighbouring Agents verranno inviate copie multiple
di tali messaggi prima che cominci l’handoff.
Un aspetto non trascurabile riguarda il tunneling dei messaggi tra new Foreign
Agent e old Foreign Agent: tali messaggi, se non autenticati tramite protocolli di
sicurezza, possono subire impersonation attack che causerebbero la registrazione di
un nodo mobile presso un agente malevolo. Per evitare ciò è fondamentale che i
messaggi inviati tra i due agenti siano autenticati tramite chiavi condivise previste
da precedenti Security Association.
Una situazione particolare da gestire, inoltre, è il passaggio di un nodo mobile
da una rete in cui è implementata la pre-registrazione ad una in cui è utilizzato il
meccanismo base del Mobile IP. In questo caso, il nodo mobile, in seguito all’inizio
dell’handoff di livello 2, invierà un messaggio di Proxy Router Solicitation all’old
15
Foreign Agent, ricevendo come risposta un semplice messaggio di Agent Advertisement. Per cui il nodo mobile invierà ulteriori messaggi di Proxy Solicitation, con un
periodo d’attesa crescente l’uno dall’altro, attendendo di ricevere come risposta un
Proxy Advertisement, fino a un massimo di volte pari a PRE_SOL_ATTEMPTS,
dopodichè effettuerà la registrazione con il Foreign Agent in modo classico. Nel caso
contrario in cui il nodo mobile si sposti da una rete classica Mobile IP ad una con
pre-registrazione, riceverà un messaggio di Proxy Advertisement che gli permetterà
di attuare la procedura della pre-registrazione.
2.3
Post-Registrazione
Il metodo della post-registrazione permette al nodo mobile di continuare a ricevere dati anche quando si trova nella nuova rete e non è stato ancora completato il processo di registrazione. Tale metodo fa instaurare un tunnel bidirezionale
(Bidirectional Edge Tunnel, BET) tra old Foreign Agent e new Foreign Agent
attraverso cui vengono redirezionati i pacchetti verso il nodo mobile, in modo da
renderli subito disponibili non appena esso termina l’handoff di livello 2. La registrazione classica del Mobile IP viene completata solo dopo che il nodo mobile ha
stabilito la comunicazione con il nuovo Foreign Agent a livello datalink. Come nel
caso della pre-registrazione, anche la post-registrazione fa uso di trigger di livello 2
che possono essere invocati in questo caso solo dagli agenti. A differenza, però, del
primo metodo proposto, è necessario aggiungere nuovi messaggi al protocollo Mobile
IP per la gestione del tunnel BET.
All’atto della registrazione classica Mobile IP, il nodo mobile utilizza il Foreign
Agent come tramite verso l’Home Agent ma può anche utilizzarlo come punto d’ancoraggio nei suoi successivi spostamenti; si parla, quindi, anche di anchor Foreign
Agent. Nel momento in cui il nodo mobile si sposta in una nuova sottorete, il nodo
mobile, invece di effettuare subito l’handoff IP registrandosi presso un new Foreign Agent, continua ad utilizzare l’old Foreign Agent (ovvero il suo anchor Foreign
Agent) e riceverà i pacchetti tramite il tunnel BET che dovrà instaurarsi tra gli
agenti. Nel caso di spostamenti brevi successivi, i Foreign Agent coinvolti contatteranno l’anchor Foreign Agent in modo da redirezionare il tunnel verso di essi; è
necessario, quindi, che i messaggi di gestione del BET tra gli agenti siano autenticati tramite Security Association. Questo meccanismo di ancoraggio del nodo mobile
continuerà fin quando esso non effettuerà la registrazione classica Mobile IP, caso in
cui si suppone che il nodo non si sia spostato nella nuova sottorete solo per un breve
intervallo di tempo; per gestire ciò si può pensare d’impostare un timeout riguardo
all’ultimo pacchetto ricevuto dall’attuale sottorete, dopodichè si dovrà effettuare la
registrazione Mobile IP.
16
2.3.1 Primo scenario: Two Party Handoff
La prima situazione considerata è quella in cui sono coinvolte solo due entità, l’anchor
Foreign Agent e il new Foreign Agent. Il funzionamento del protocollo è leggermente
differente a seconda che l’handoff di livello 2 sia rilevato dall’anchor Foreign Agent
(tramite Source Trigger) o dal new Foreign Agent (tramite Target Trigger).
Consideriamo il caso in cui si verifica un Source Trigger:
1. l’anchor Foreign Agent riceve il trigger L2 che lo informa che un certo nodo
mobile si sta muovendo verso una nuova sottorete. Il trigger contiene l’indirizzo
L2 del nodo mobile e l’indirizzo IP del new Foreign Agent;
2. l’anchor Foreign Agent invia un messaggio di Handoff Request (HRequest) al
new Foreign Agent per settare il tunnel BET. In questo caso, nell’header del
messaggio il bit H è settato ad 1 per indicare che è stato generato a causa
di un Source Trigger. Tale messaggio contiene: una lifetime per il tunnel che
l’anchor Foreign Agent è disponibile a supportare, l’indirizzo IP e l’indirizzo
L2 del nodo mobile, l’indirizzo IP del suo Home Agent. Se il bit T è settato a
1 indica che l’agente è disponibile a gestire il tunnel anche in modalità inversa
per la lifetime indicata; se invece il bit T è settato a 0 così come la lifetime,
vuol dire che l’agente non è disponibile ad aprire il tunnel BET;
3. il new Foreign Agent riceve il messaggio HRequest e ne invia uno di Handoff Reply (HReply) all’anchor Foreign Agent; in questo caso, nell’header del
messaggio il bit H è settato a 1. Se il bit T è settato a 1, vuol dire che il
new Foreign Agent chiede di aprire un reverse tunnel per una durata minore o
uguale a quella massima indicata nell’HRequest; questo può essere fatto solo
se nella richiesta il bit T era settato a 1 oppure se è presente un meccanismo
di ingress filtering nella nuova sottorete che determina l’uso obbligatorio del
tunnel bidirezionale. Questo scambio di messaggi con bit T alti crea di fatto
il tunnel BET;
4. l’inizio dell’handoff di livello 2 del nodo mobile viene segnalato da un messaggio di trigger L2 presso l’anchor Foreign Agent; quando ciò avviene, l’agente
inoltra i pacchetti indirizzati al nodo mobile verso il new Foreign Agent attraverso il tunnel. La fine dell’handoff di livello 2 viene segnalata da un ulteriore
messaggio di trigger L2 presso il new Foreign Agent; per cui, quest’ultimo consegna i pacchetti al nodo mobile, conoscendo il suo indirizzo L2 dall’HRequest.
Poichè, però, il new Foreign Agent non è un gateway per il nodo mobile, non
potranno essere mandati in automatico i pacchetti dal nodo mobile verso il new
Foreign Agent; per risolvere ciò, in modo simile al meccanismo del Gratuitous
ARP, il new Foreign Agent invia un messaggio di ARP Reply al nodo mobile,
inserendo la corrispondenza {indirizzo IP old Foreign Agent, indirizzo L2 new
Foreign Agent}. La fine dell’handoff L2 viene segnalata contemporaneamente
da un altro messaggio di trigger L2 anche sul nodo mobile; in seguito a ciò
il nodo mobile può cominciare la registrazione classica Mobile IP oppure può
decidere di posticipare la registrazione e continuare ad utilizzare l’old Foreign
Agent come àncora.
17
Figura 2.8: Metodo della post-registrazione two party con Source Trigger
Figura 2.9: Diagramma temporale della post-registrazione two party con
Source Trigger
18
Consideriamo, ora, il caso in cui si verifica un Target Trigger:
1. il new Foreign Agent riceve il trigger L2 che lo informa che un certo nodo mobile
si sta muovendo verso la propria sottorete. Il trigger contiene l’indirizzo L2
del nodo mobile e l’indirizzo IP dell’anchor Foreign Agent;
2. il new Foreign Agent invia un messaggio di Handoff Request (HRequest) all’anchor Foreign Agent per settare il tunnel BET. In questo caso, nell’header
del messaggio il bit N è settato ad 1 per indicare che è stato generato a causa
di un Target Trigger. Se il bit T è settato a 1 indica che l’agente richiede la
creazione di un reverse tunnel, per il quale viene indicata la lifetime. All’interno del messaggio viene inviato l’indirizzo L2 del nodo mobile per il quale si
crea il tunnel;
3. l’anchor Foreign Agent riceve il messaggio di HRequest e ne invia uno di Handoff Reply (HReply) al new Foreign Agent; in questo caso, nell’header del
messaggio il bit N è settato a 1. Se il bit T è settato ad 1, il valore di lifetime
allegato indica la lifetime del tunnel che l’agente è disponibile ad aprire; se il
bit T era 1 anche nella richiesta, allora viene stabilito di fatto un tunnel BET;
4. la fase di gestione dell’handoff di livello 2, essendo indipendente dai trigger L2
iniziali, è analoga a quella del caso Source Trigger.
19
Figura 2.10: Metodo della post-registrazione two party con Target Trigger
Figura 2.11: Diagramma temporale della post-registrazione two party con
Target Trigger
20
Di seguito viene riportato il formato del messaggio Handoff Request; la trasmissione del messaggio, così come per quello di Handoff Reply, sfrutta lo stesso porto
UDP usato per i messaggi di registrazione Mobile IP, ovvero il porto 434;
Figura 2.12: Messaggio di Handoff Request
in particolare si ha:
• ’Tipo’ indica che si tratta di un Handoff Request;
• ’H’ indica, se alto ed N è basso, che è stato generato da un Source Trigger;
• ’N’ indica, se alto ed H è basso, che è stato generato da un Target Trigger;
• ’R’ indica, se alto con H e N bassi, che è una richiesta di rinnovo del tunnel;
• ’M’ indica che l’agente che invia il messaggio usa il protocollo d’incapsulamento
Minimal Encapsulation, che riduce l’overhead dell’header IP riducendo alcuni
suoi campi;
• ’G’ indica che l’agente che invia il messaggio usa il protocollo di rete GRE (Generic Routing Encapsulation) che permette d’includere al suo interno protocolli
differenti;
• ’T’ indica, se inviato dall’anchor Foreign Agent, che esso è disponibile a supportare anche un tunnel inverso mentre se inviato dal new Foreign Agent che
esso ha richiesto l’uso di un tunnel inverso;
• ’B’ indica che il nodo mobile utilizza un tunnel inverso per la comunicazione
con l’Home Agent e che, quindi, se l’anchor Foreign Agent non è disponibile ad
aprire un tunnel inverso con il new Foreign Agent, questo dovrà aprirne uno
direttamente con l’Home Agent tramite l’utilizzo di una preesistente Security
Asssociation;
21
• ’Lifetime’ indica l’intervallo di tempo in secondi per cui è concesso l’apertura
del tunnel da parte del anchor Foreign Agent oppure per cui è richiesta l’apertura del tunnel inverso da parte del new Foreign Agent. Un valore Lifetime=0
indica che non c’è la disponibilità o la richiesta di un tunnel;
• ’Mobile Node Home Address’ valido solo se generato da un Source Trigger;
• ’Home Agent Address’ valido solo se generato da un Source Trigger;
• ’Identification’ è usato, come nei messaggi di registrazione del Mobile IP, per
associare una richiesta ad una risposta evitando replay attack;
• ’Estensioni’ contiene l’indirizzo L2 del nodo mobile e la FA Authentication
Extension per garantire la sicurezza del messaggio.
Il formato del messaggio Handoff Reply è simile a quello dell’Handoff Request:
Figura 2.13: Messaggio di Handoff Reply
• ’Tipo’ indica che si tratta di un Handoff Reply;
• ’Codice’ indica il risultato in seguito all’HRequest: i valori attualmente previsti
sono solo 0 per una richiesta accettata e 1 per un rifiuto;
• ’H’ indica, se alto ed N è basso, che è la risposta per un messaggio HRequest
generato da un Source Trigger;
• ’N’ indica, se alto ed H è basso, che è la risposta per un messaggio HRequest
generato da un Target Trigger;
• ’R’ indica se alto che è la risposta per un messaggio di rinnovo del tunnel;
• ’M’ indica che l’agente che invia il messaggio usa il protocollo d’incapsulamento
Minimal Encapsulation;
• ’G’ indica che l’agente che invia il messaggio usa il protocollo di rete GRE
(Generic Routing Encapsulation);
22
• ’T’ indica, se inviato dall’anchor Foreign Agent, che esso aprirà come richiesto
anche un tunnel inverso mentre se inviato dal new Foreign Agent che esso ha
richiesto l’uso di un tunnel inverso;
• ’B’ indica che il nodo mobile utilizza un tunnel inverso per la comunicazione
con l’Home Agent e che, quindi, se l’anchor Foreign Agent non è disponibile ad
aprire un tunnel inverso con il new Foreign Agent, questo dovrà aprirne uno
direttamente con l’Home Agent tramite l’utilizzo di una preesistente Security
Asssociation;
• ’Lifetime’ indica l’intervallo di tempo in secondi per cui è concesso l’apertura
del tunnel da parte del anchor Foreign Agent oppure per cui è richiesta l’apertura del tunnel inverso da parte del new Foreign Agent. Un valore Lifetime=0
indica che non c’è la disponibilità o la richiesta di un tunnel;
• ’Mobile Node Home Address’ valido solo se generato da un Target Trigger;
• ’Home Agent Address’ valido solo se generato da un Target Trigger;
• ’Identification’ è usato, come nei messaggi di registrazione del Mobile IP, per
associare una richiesta ad una risposta evitando replay attack;
• ’Estensioni’ contiene la FA Authentication Extension per garantire la sicurezza
del messaggio.
Per quanto concerne il tunnel BET, esso viene creato con le tecniche di tunneling
forward e reverse già previste dal protocollo nativo Mobile IP, ovvero Tunneling IPin-IP e Tunneling IP-in-UDP nel caso di meccanismo del NAT. La sua disattivazione,
invece, può essere causata dalla fine della lifetime decisa precedentemente e non
rinnovata, dal completamento di registrazione classica Mobile IP da parte del nodo
mobile oppure dallo spostamento del nodo verso un’ulteriore Foreign Network.
23
2.3.2 Secondo scenario: Three Party Handoff
La seconda situazione che viene considerata è quella in cui un nodo mobile, che
già utilizza un anchor Foreign Agent attraverso l’attuale Foreign Agent, si sposti in
un’altra sottorete gestita da un altro Foreign Agent e non effettui la registrazione
Mobile IP. Tale meccanismo può essere utilizzato solo se il livello 2 sottostante lo
permette; ciò viene consentito solitamente da protocolli, come quelli cellulari, in cui
si suppone che il nodo mobile possa spostarsi velocemente e di continuo presso più
sottoreti.
L’idea di base della procedura è che l’old Foreign Agent informi il new Foreign
Agent affinchè contatti l’anchor Foreign Agent per spostare il tunnel precedentemente creato. Una volta terminato da parte del nodo mobile l’handoff di livello 2,
l’old Foreign Agent dovrà mandare un messaggio di terminazione all’anchor Foreign Agent per il tunnel BET. Come nel caso del Two Party Handoff, il trigger di
segnalazione può essere un Source Trigger o un Target Trigger.
Consideriamo il caso di un Source Trigger:
1. l’old Foreign Agent riceve il trigger L2 che lo informa che un certo nodo mobile
si sta muovendo verso una nuova sottorete. Il trigger contiene l’indirizzo L2
del nodo mobile e l’indirizzo IP del new Foreign Agent;
2. l’old Foreign Agent invia un messaggio di HRequest/HTT (Handoff To Third)
ottenuto dal messaggio HRequest settando sia il bit H che N a 1. Esso contiene
l’indirizzo IP e l’indirizzo L2 del nodo mobile, l’indirizzo IP dell’Home Agent
e l’indirizzo IP dell’anchor Foreign Agent. Il new Foreign Agent risponde con
un messaggio di HReply/HTT ;
3. il new Foreign Agent verifica nella propria Visitor List se è già presente un’associazione con il nodo mobile; se è così, ovvero che il new Foreign Agent è
l’anchor Foreign Agent, una volta che il nodo mobile abbia terminato l’handoff di livello 2, l’agente comincia ad inviare i pacchetti al nodo mobile. Se,
invece, il new Foreign Agent è una nuova entità dello scenario, invia un messaggio di HRequest all’anchor Foreign Agent per negoziare l’apertura del tunnel
BET; l’anchor Foreign Agent invia un messaggio di HReply dopo il quale apre
il tunnel verso il new Foreign Agent.
4. l’inizio dell’handoff L2 è segnalato presso l’old Foreign Agent da un trigger di
livello 2; in seguito a ciò, l’old Foreign Agent invia un messaggio di HRequest
all’anchor Foreign Agent con Lifetime=0, ad indicare la volontà di chiudere
il tunnel preesistente. L’anchor Foreign Agent risponde con un messaggio di
HReply dopo il quale, se non ancora fatto, stabilisce il tunnel verso il new
Foreign Agent.
5. il completamento dell’handoff L2 è segnalato da un trigger L2 presso il new
Foreign Agent e presso il nodo mobile; in seguito a ciò, il new Foreign Agent
consegna i pacchetti al nodo mobile mentre il nodo mobile può decidere se
iniziare la procedura di registrazione classica Mobile IP oppure se posticiparla
a causa di successivi spostamenti brevi.
24
Figura 2.14: Metodo della post-registrazione three party con Source
Trigger
Figura 2.15: Diagramma temporale della post-registrazione three party
con Source Trigger
25
Il caso di un Target Trigger è analogo al caso precedente, con la differenza che
il trigger L2 iniziale si manifesta presso il new Foreign Agent, che invierà per primo
il messaggio HRequest/HTT; dal messaggio di risposta HReply/HTT riceverà le
informazioni sul nodo mobile e sull’anchor Foreign Agent, dopodichè il protocollo è
identico al caso Source Trigger.
Figura 2.16: Metodo della post-registrazione three party con Target
Trigger
Figura 2.17: Diagramma temporale della post-registrazione three party
con Target Trigger
26
2.3.3 Considerazioni
Il meccanismo della post-registrazione permette di ridurre la latenza delle trasmissioni, in quanto non appena sarà terminato l’handoff di livello 2 il nodo riceverà
tramite il collegamento datalink con il new Foreign Agent i pacchetti reindirizzati
dall’anchor Foreign Agent; nel caso del Mobile IP classico, invece, il nodo dovrà
attendere che venga completata la procedura di registrazione a livello IP prima di
ricevere i pacchetti. E’ necessario, però, effettuare dopo un certo intervallo di tempo la registazione classica Mobile IP, in quanto tale percorso prevede l’uso di un
intermediario ulteriore (l’anchor Foreign Agent) verso l’Home Agent, che nel lungo periodo rende la trasmissione dati più lenta. In ogni caso, visto che i pacchetti
saranno consegnati non appena sarà stata rilevata la terminazione dell’handoff di
livello 2, si ha che la bontà del meccanismo si basa anche in questo caso sull’utilizzo
di trigger L2 performanti. Tuttavia, nello scenario Three Party Handoff il tempo per
stabilire il nuovo tunnel tra anchor Foreign Agent e new Foreign Agent non dipende
dalla rapidità dei trigger L2, visto che questi non si manifestano presso l’anchor
Foreign Agent, ma dalla congestione della rete. Nel caso migliore il tunnel verrà
stabilito in seguito al messaggio di HReply inviato al new Foreign Agent mentre nel
caso peggiore verrà inviato in seguito al messaggio di HReply inviato all’old Foreign
Agent per chiudere il precedente tunnel BET.
Per quanto riguarda la registrazione Mobile IP, come detto, il nodo mobile può
posticiparla in seguito al completamento dell’handoff L2. In questo caso sarà necessario, alla scadenza della lifetime per il tunnel, che i due agenti coinvolti lo rinnovino
tramite uno scambio di messaggi HRequest/HReply con bit R settato a 1. Ci sono,
però, delle situazioni in cui il nodo mobile è obbligato a completare la registrazione
Mobile IP classica: una di esse è il caso in cui uno dei due agenti coinvolti nel tunnel
decida di non rinnovare il tunnel BET esistente; un’altra è quella in cui l’old Foreign
Agent non riesce a disattivare il tunnel BET preesistente.
La post-registrazione è utile quando il nodo mobile si sposta di continuo presso
reti diverse al cui interno sono utilizzate le stesse tecnologie wireless: in questo caso,
la natura dei trigger L2 sarà la stessa e quindi il meccanismo d’interazione del nodo
mobile con la rete sarà più rapido. E’ necessario, però, che all’interno delle sottoreti
siano previsti meccanismi di autenticazione a livello datalink che rendano sicure le
trasmissioni tra il nodo mobile e i Foreign Agent.
Per quanto riguarda la gestione degli errori, essi possono essere causati dal ritardo
di ricezione del messaggio HRequest o del messaggio HReply; tuttavia, dato che lo
scambio di tali messaggi avviene tra gli agenti su collegamenti cablati, la probabilità
che ciò avvenga è bassa. In ogni caso, se ciò dovesse avvenire, si avrebbe che nel
momento in cui l’HRequest non viene ricevuta da uno dei due agenti, l’altro non
invierà mai l’HReply; in tal modo il new Foreign Agent, non appena noterà la
presenza del nodo mobile tramite il trigger L2, invierà un Agent Advertisement
per cominciare la registrazione standard. Se, invece, è l’HReply ad essere perduto,
nel caso in cui sia stata inviato dall’anchor Foreign Agent quest’ultimo inoltrerà
comunque i pacchetti, supponendo che l’handoff sia comunque avvenuto, mentre
nel caso in cui sia stato inviato dal new Foreign Agent l’anchor Foreign Agent non
riceverà riscontri e non invierà pacchetti; per risolvere questa situazione, l’anchor
27
Foreign Agent invierà HRequest successivi fin quando non otterrà un HReply, in
modo da annullare la post-registrazione e permettere al nodo mobile di cominciare
una registrazione standard presso il new Foreign Agent.
Per quanto concerne, invece, la sicurezza delle trasmissioni, poichè nella postregistrazione il nodo mobile riceve messaggi da un new Foreign Agent presso cui non
ha effettuato ancora un meccanismo sicuro di registrazione Mobile IP, è fondamentale che l’anchor Foreign Agent e il new Foreign Agent condividano una Security
Association preesistente prima d’inoltrare i pacchetti di HRequest e HReply.
2.4
Metodo combinato
Il metodo combinato usa sia la pre-registrazione sia la post-registrazione. Tale meccanismo prevede di adoperare un timer presso il new Foreign Agent in modo da
rilevare se la pre-registrazione è andata a buon fine o no; si suppone che la preregistrazione sia stata completata quando il messaggio di Registration Reply proveniente dall’Home Agent sia giunto al new Foreign Agent. Quando il timer scade, il
new Foreign Agent dovrà iniziare la procedura di post-registrazione come nel caso
Target Trigger per aprire un tunnel BET verso l’old Foreign Agent. Il timer verrà
settato per un valore di un secondo non appena il new Foreign Agent riceve un Target Trigger oppure non appena riceve il messaggio di Registration Request nel caso
venga utilizzato un Source Trigger o un Mobile Trigger; per questo motivo, nella
Registration Request dovrà essere trasportato in un’estensione l’indirizzo IP dell’old
Foreign Agent, in modo da renderlo noto al new Foreign Agent nel caso in cui il
timer dovesse scadere e, quindi, si dovesse iniziare la post-registrazione.
28
Capitolo 3
Altre tecniche proposte
Nel corso degli anni, parallelamente al lavoro svolto dall’IETF, sono stati studiati
altri meccanismi che permettano di ridurre la latenza introdotta dall’handoff IP;
alcuni di essi propongono un radicale cambiamento del Mobile IP, altri invece ne
riutilizzano la maggior parte dei concetti.
Shim e Gitlin, della Columbia University di New York, hanno proposto un meccanismo simile alla pre-registrazione basato sull’uso di agenti ”vicini”, il NeighborCasting [5]. Durante l’handoff, ogni nodo mobile informa il nuovo Mobility Agent
riguardo al vecchio Mobility Agent, in modo tale da permettere al Mobility Agent
di costruire una mappa dei suoi vicini. Così come i meccanismi proposti dall’IETF,
anche il NeighbourCasting presuppone l’uso di trigger di livello 2 che comunichino un handoff datalink in corso. In questo modo, quando si manifesta un trigger
presso il vecchio Mobility Agent, quest’ultimo provvederà ad inviare dati a tutti i
suoi vicini, noti tramite precedenti spostamenti di altri nodi mobili. Il vantaggio
di tale approccio è che il nodo mobile riceverà i dati non appena sarà giunto nella
nuova sottorete vicina, qualunque essa sia, riducendo quindi la latenza dell’handoff
IP; d’altro canto, lo svantaggio è lo spreco di banda nell’invio iniziale dei pacchetti
verso sottoreti che non verranno mai visitate dal nodo mobile, anche se il numero di
dati inviati non sarà mai troppo elevato, visto che si presuppone che il collegamento
datalink del nodo mobile presso la nuova sottorete sarà stabilito in breve tempo.
Mary Baker e il suo team nel 1996 presentarono un progetto per la mobilità
delle reti denominato MosquitoNet [6]. In tale soluzione i nodi mobili non hanno
bisogno di un’infrastruttura di Mobilty Agent nelle varie sottoreti visitate, in quanto
sono loro stessi a recuperare le informazioni necessarie per il Mobile IP. Ciò viene
reso possibile in quanto all’interno del nodo mobile è presente un modulo che fa da
Mobility Agent che acquisisce, in vece del nodo mobile, un indirizzo IP utile da usare
nella nuova sottorete; il modulo Foreign Agent comunica, poi, con l’interfaccia di
rete standard del nodo mobile che è presente di fatto sullo stesso dispositivo. Questo
meccanismo elimina, quindi, il bisogno di un’infrastruttura preesistente di Mobility
Agent e riduce il ritardo di comunicazione dati tra il nodo mobile e gli agenti, dal
momento che coesistono sullo stesso dispositivo. Tuttavia, viene introdotto un nuovo
ritardo, dovuto all’acquisizione dell’indirizzo IP da parte del modulo Foreign Agent,
che avviene solitamente tramite il protocollo DHCP; tale ritardo non è trascurabile
nè tantomeno prevedibile a priori, e, aggiungendosi al ritardo dell’handoff di livello 2,
29
può rendere la latenza dell’handoff IP di questa soluzione simile a quella del Mobile
IP standard.
Un’ulteriore tecnica basata su un approccio opposto al MosquitoNet è stata descritta da Van den Wijnagert e Blondia dell’Università di Antwerp [7]. Essi hanno
proposto uno schema predittivo per l’handoff di un nodo mobile riutilizzando lo
schema del Hierarchical Mobile IP (HMIP), che rappresenta una delle modifiche
apportate al Mobile IP e ufficialmente riconosciuta. HMIP introduce una struttura ad albero per la gestione della posizione dei Foreign Agent, ciascuno dei quali
fa capo ad un Gateway Foreign Agent, che gestisce quindi una determinata area.
Nel momento in cui il nodo mobile si sposta tra domini differenti, esso effettua la
classica registrazione Mobile IP; tuttavia, il Care of Address che utilizza è quello
del Gateway Foreign Agent. In tal modo ogni successivo spostamento all’interno del
dominio verrà gestito localmente dai vari agenti di quell’area, senza che avvenga tale
segnalazione all’Home Agent, riducendo quindi il percorso effettuato dai pacchetti
di Registration Request e Registration Reply. Il modello proposto, quindi, si basa
sulla costruzione di un modello urbano di mobilità basato sulla cronologia delle visite
effettuate da un nodo mobile presso le differenti sottoreti. La posizione di un nodo
mobile viene tracciata tramite il polling di messaggi di ping da parte del Foreign
Agent ad esso associato; nel momento in cui il nodo mobile non è più raggiungibile,
i pacchetti vengono spediti al Foreign Agent previsto dal modello urbano tramite un
tunnel. Il vantaggio di quest’approccio è quello di ridurre effettivamente la latenza
nel caso di spostamenti multipli all’interno di un grande dominio e quello di non
utilizzare trigger di livello 2, i quali non sono previsti da tutte le tecnologie datalink. Di contro, gli svantaggi principali sono l’utilizzo di un meccanismo di calcolo
probabilistico sofisticato e l’invio di parecchi messaggi ridondanti di ping.
30
Capitolo 4
Conclusioni
Per quanto visto, i modelli della pre-registrazione e della post-registrazione proposti dall’IETF nell’RFC 4881 rappresentano due soluzioni vantaggiose al problema
della latenza dell’handoff IP che non stravolgono il preesistente protocollo Mobile
IP, ma ne rappresentano un upgrade. Il principale vantaggio delle soluzioni dell’IETF rispetto ad altre proposte è proprio il fatto di poter integrare il meccanismo
di pre-registrazione o post-registrazione in un protocollo già ampiamente testato e
funzionante come quello del Mobile IP nativo; in questo modo non si rende necessario l’utilizzo di un’ulteriore infrastruttura di agenti di supporto e si garantisce
una semplice gestione nel passaggio da una rete in cui è presente il protocollo standard Mobile IP ad una in cui è utilizzato uno dei due meccanismi proposti. Questi
aspetti sono di gran lunga più rilevanti rispetto ad un’ulteriore, seppur piccola, riduzione della latenza nell’handoff IP che si potrebbe ottenere con altre soluzioni di
fast handoff.
31
Bibliografia
[1] IETF, ”IP Mobility Support for IPv4”, RFC 3344, August 2002
http://www.ietf.org/rfc/rfc3344
[2] IETF, ”Reverse Tunneling for Mobile IP, revised”, RFC 3024, January
2001 http://www.ietf.org/rfc/rfc3024
[3] IETF, ”Mobile IP Traversal of Network Address Translation (NAT)
Devices”, RFC 3519, April 2003 http://www.ietf.org/rfc/rfc3519
[4] IETF, ”Low-Latency Handoffs in Mobile IPv4”, IETF RFC 4881, June
2007 http://www.ietf.org/rfc/rfc4881
[5] E.Shim, H.Wei, Y.Chang, R.Gitlin, Columbia University ”NeighborCasting:
A fast handoff mechanism in wireless IP using neighboring foreign
agent information” ”New York Metro Area Networking Workshop”, 2001
[6] M.Baker, X.Zhao, S.Cheshire, J.Stone, Stanford University ”Supporting Mobility in MosquitoNet”, ”USENIX Technical Conference”, San Diego, CA,
January 1996
[7] N.Van den Wijnagaert, C.Blondia, University of Antwerp ”A Predictive
Low Latency Handover Scheme for Mobile IP”, ”ICMU: Second International Conference on Mobile Computing and Ubiquitous Networking”, Osaka
University Convention Center, Osaka, Japan , April 2005
32

Elaborato Napolano Mirko N46000442

Transcript

Documenti analoghi

30.10.2015 - Giorgio Roverato

Mobilità su reti IP

WürthPhoenix neteye 2011 – 2012

Nuova tratta Alta Velocità Norimberga-Berlino

INDICE - Dipartimento di Matematica e Informatica

seaconsult.eu - SEA Consulting

Guida introduttiva

VELA vele e velerie ago:BM Pratica Depuratore R

Sistemi peer-to-peer Sistemi peer-to-peer (P2P)

4pp

Gianfelice Rocca - Mobility Conference Exhibition

cAMPANiA - Intertrade

(JLSP) – 2nd Issue – March 2015 - The Journal of Languages for

McAfee Agent 5.0.0 Guida del prodotto