Low-Latency Handoffs in Mobile IPv4

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili Anno Accademico 2011/2012 Candidato: MIRKO NAPOLANO matr. N

2 Indice Introduzione Mobile IP Il funzionamento standard Le modifiche al protocollo L handoff e le soluzioni proposte dall IETF Il problema dell handoff Pre-Registrazione Funzionamento Considerazioni Post-Registrazione Primo scenario: Two Party Handoff Secondo scenario: Three Party Handoff Considerazioni Metodo combinato Altre tecniche proposte 29 4 Conclusioni 31 II

3 Introduzione Negli ultimi anni le reti WLAN dello standard IEEE 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

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 indiriz- 5

5 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

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

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

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 , 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 : 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 , 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 L 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

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

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

11 Figura 2.2: Metodo della pre-registrazione con trigger mobile-initiated Figura 2.3: Diagramma temporale con trigger mobile-initiated 12

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

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

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

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

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

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

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

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

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; in particolare si ha: Figura 2.12: Messaggio di Handoff Request 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

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

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

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

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

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

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

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

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 Neighbor- Casting [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

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

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