One document matched: draft-dommety-mobileip-anchor-handoff-01.txt
Differences from draft-dommety-mobileip-anchor-handoff-00.txt
INTERNET DRAFT Gopal Dommety
Category: Standards Track cisco Systems
Title: draft-dommety-mobileip-anchor-handoff-01.txt Tao Ye
July 2000 RPI
Expires December 2000
Local and Indirect Registration for Anchoring Handoffs
draft-dommety-mobileip-anchor-handoff-01.txt
Status of this Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In wide area deployment, the handoff latencies due to latencies in
Mobile IP registrations, delay incurred due to setting up of dynamic
keys, and latencies in setting up secure Tunnels could be high. This
document proposes enhancements to reduce the latencies involved in
such handoffs. It proposes enhancements to facilitate local
registration, anchoring, and global indirect registration.
1. Introduction
In wide area deployment, the handoff latencies of the current mobileip
could be high. In a mobile environment, it is very important to limit
the delay experienced in communication when a mobile moves from base
station\access point to another. This document proposes enhancements
to reduce the latencies involved in a handoff. It proposes
enhancements to facilitate local registration, anchoring, and global
indirect registration.
1.1 Problem Description
Handoff latencies could involve delays due to the following:
1. Message Exchange Between HA and FA: Mobile IP Message
traversal from FA to the HA and back.
2. Establishment of Secure Tunnels between FA and HA: In order
to secure traffic destined to/generated by a mobile, encryption of
data is being considered. Typically, this encryption is will be done
by setting up an IP Sec Tunnel using IKE. Latency in performing IKE
and creating an IP Sec Tunnel contributes to the latency experianced
by the user during handoffs.
3. Establishment of security keys between FA and HA: For the
HA and FA to authenticate each other, a shared key is used to compute
FA-HA AE (Authentication Extension). Also a shared key (a different or
the same as one used for FA-HA AE) might need to be established if IKE
with shared Key is being used to establish IP Sec Tunnel. These Keys
can be statically configured or dynamically established. If the Keys
are established dynamically, these keys have to be established before
the handoff can be completed (Keys can be generated using some form of
KDC). The key generation involves considerable delays during
handoffs. Another alternative is to use PKI authenticating Mobile IP
entities or during IKE negotiations, this also introduces considerable
delay. These delays also contribute to the latency experianced by the
user.
It is desirable to reduce or eliminate these latencies during
handoffs. In order to reduce or eliminate the above mentioned
latencies, this draft proposes Anchoring of tunnels at the old FA
(Anchor FA). To facilitate anchoring, this document introduces two
types of registrations Local Registration and Indirect Global
Registration. These mechanisms can be used to quickly perform a
handoff and later perform a global registration if required.
2. Overview
2.1 Network Model
The network model being considered is illustrated in Fig 1.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| +------+ +-------+ | | +------+ |
| | | | | | | | | |
| | MN |-------------| FA1 |-------------------------| HA | |
| | | | | | | | | |
| +------+ +-------+ | | +------+ |
| | | |
| | +----------------+
| +-------+ |
| | FA2 | |
| | | |
| | | |
| +-------+ |
+----------------------------------+
Fig 1: Network Model
2.2. Mobile IP Registration (referred to as Global Registration in this draft)
The Current Mobile IP registration[1] is illustrate in Fig 2. It is
referred to as Global Registration.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| +------+ +-------+ | | +------+ |
| | | 1 | |************************ | | |
| | MN |------------>| FA1 |----------2------------->| HA | |
| | |<------------| |<---------3--------------| | |
| +------+ 4 +-------+*************************+------+ |
| | Secure | |
| | Tunnel +----------------+
| +-------+ |
| | FA2 | |
| | | |
| | | |
| +-------+ |
+----------------------------------+
Fig 2. Global Registration
Messages 1,2: Registration Request
Messages 3,4: Registration Reply
2.3 Local Registration
During the Global Registration process, the MN authenticates to the
HA. During this process IPsec tunnel could be established between the
HA and FA to secure the users data. It is possible by the use of a KDC
or other mechanisims to establish a shared Key between MN-FA.
After a successful Global Registration, the FA acts as an AnchorFA for
future registrations. If during the global registration a shared-key
is established between MN and FA or there exists another mechanisim
(e.g. using PKI) for the FA to authenticate the MN, a local
registration can be performed when the MN moves within the same
domain. Local Registration is authenticated by the AnchorFA as
illustrated in Figure 3. On successful registration, a tunnel is
established between the AnchorFA and the New Visiting FA to tunnel
packets to and from the Mobile. Note that the assumption here is that
there is a mechanisim for the AnchorFA to authenticate the MN.
By performing Local Registration latencies due to components 1, 2 and 3
described in Section 1.1 are avoided.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| Anchor | | |
| +-------+ | | +------+ |
| | |*************************| | |
| | FA1 | | | | HA | |
| | |*************************| | |
| +-------+ | Secure Tunnel | +------+ |
| ^ | | | |
| 2| 3| | +----------------+
| | V |
| +------+ +-------+ |
| | | 1 | | |
| | MN |------------>| FA2 | |
| | |<------------| | |
| +------+ 4 +-------+ |
+----------------------------------+
Fig 3: Local Registration
Messages 1,2: Registration Request
Messages 3,4: Registration Reply
Note that after performing a Local Registration (or multiple local
registrations), the mobile node can choose to perform a global
registration (or the AFA can force the global registration), thereby
having the tunnel setup as illustrated in Fig 2.
2.4 Global Indirect Registration
If there does not exist a direct way for the AnchorFA to authenticate
the MN (For Example, a Shared Key between the MN and AnchorFA was not
established), an Indirect Global Registration as illustrated in Fig 4
can be performed to avoid the latencies due to components 2 and 3
mentioned in Section 1.1.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| Anchor | | |
| +-------+ | | +------+ |
| | |************************ | | |
| | FA1 |----------3------------->| HA | |
| | |<---------4--------------| | |
| +-------+************************ +------+ |
| ^ | |Secure Tunnel | |
| 2| |5 | +----------------+
| | V |
| +------+ +-------+ |
| | | 1 | | |
| | MN |------------>| FA2 | |
| | |<------------| | |
| +------+ 6 +-------+ |
+----------------------------------+
Fig 4: Global Indirect Registration
Messages 1,2,3: Registration Request
Messages 4,5,6: Registration Reply
3. Extensions
3.1 Anchor Advertisement Extension
This section defines a new extension to the Router Discovery
Protocol [2] for use by foreign agents in a domain to advertise the
Zone ID to which the FA belongs to. The Zone ID Information is used by
Mobile (MN) to determine if it has changed Zones.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reg-Type | Zone ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Anchor Advertisement Extension
Type TBD (Skippable Extension)
Length Length in bytes of this extension, not including the
Type and Length bytes.
Reg-Type
GLOBAL_REG 0x1
LOCAL_REG 0x2
GLOBAL_INDIRECT_REG 0x4
Zone ID A Globally unique value used to identify the Zone.
If an FA has a Zone ID in the IRDP message, then it MUST support at
least one of local registration or Indirect Global
registration. NULL Zone ID and multiple overlapping Zone IDs will
be described in future versions of this document.
3.2 Anchor Registration Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reg-Type | Resrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AnchorFA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Anchor Registration Extension
Type TBD (Non-skippable Extension)
Length Length in bytes of this extension, not including the
Type and Length bytes.
Reg-Type
GLOBAL_REG 0x1
LOCAL_REG 0x2
GLOBAL_INDIRECT_REG 0x4
Resrvd Currently set to 0. To be used for future enhancements.
Zone ID A Globally unique value used to identify the Zone.
3.3 Authentication Extensions
The procedures described in this document require two new
authentication extensions, FA-AnchorFA Authentication Extension and
MN-AnchorFA Authentication Extension. Generalized Mobile IP
Authentication Extension as defined in [3] is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Generalized Mobile IP Authentication Extension
Type 36 (not skippable) (see [1])
Subtype a number assigned to identify the kind of
endpoints or characteristics of the particular
authentication strategy
Length 4 plus the number of bytes in the Authenticator;
MUST be at least 20.
SPI Security Parameters Index
Authenticator The variable length Authenticator field
In this document, two subtypes are defined:
2 (TBD) FA-AnchorFA Authentication Extension
3 (TBD) MN-AnchorFA Authentication Extension
4. Processing Considerations
4.1 Initial Registration
The Initial registration when a MN enter a different Zone, it preforms
a registration as specified in RFC 2002[1](referred to as Global
Registration). Additionally, in order to perform Local or Indirect
registration in the future, Foreign Agent CoA option should be used
[1]. The MN remembers the FA (to be used as the AnchorFA) and
the Zone ID, and the lifetime (also referred to as global registration
lifetime)
4.2 Local Registration
Local registration is illustrated in Fig 3. This section give the
details of processing by the mobile IP entities.
4.2.1 MN processing
The MN is allowed to perform a Local Registration if it has previously
performed a Global Registration with a FA in the current Zone and
global lifetime that was granted has not expired. The MN sends a
Mobile IP registration to the FA with the following fields:
-Lifetime is set to the lesser of the remaining lifetime of
the last global registration and the one advertised by this FA.
-Currently only timestamp-based reply protection is supported
and timestamp-based replay protection is followed as specified in RFC
2002.
-CoA field set to the address of the Foreign Agent CoA or
Collocated CoA and sets the D bit appropriately. Home Agent and Home
Address fields are set according to RFC 2002 [1].
-MN-AnchorFA AE (Authentication Extension) is mandatory and is
used in place of MN-HA AE.
-Anchor Registration Extension is included before the
MH-AnchorFA AE. The Reg_Type field is set to LOCAL_REG. Other Fields are
set appropriately.
4.2.2 FA processing
FA on receipt of the Registration Request from the MN processes the
Request as Specified in RFC 2002[1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
Mobile.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not advertised by the FA, a registration
reject with UNSUPPORTED_REG_TYPE is sent to the Mobile.
3. For Local Registration FA-AnchorFA AE can be used. It is
computed in place of the FA-HA AE.
4. Sends the Registration Message to AnchorFA (instead of HA
as in a Global Registration [1] ).
On receiving a successful Registration Reply from the AnchorFA, if
the MN is using Foreign Agent CoA, the appropriate tunnel is created
to the AnchorFA (instead of to HA as in the Global Registration). The
FA also updates the lifetime as specified in RFC 2002[1]. In case of a
Registration Reject the FA performs processing as specified in
RFC 2002[1] and also relays the error codes for INVALID_ZONEID and
UNSUPPORTED_REG_TYPE.
4.2.3 AnchorFA processing
AnchorFA on receipt of the Registration Request from the FA processes
the Request as a HA as specified in RFC 2002[1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
FA.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not supported, a registration reject with
UNSUPPORTED_REG_TYPE is sent to the FA.
3. If FA-AnchorFA AE is missing or fails authentication then
Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION
Code.
4. If MN-AnchorFA AE is missing or fails authentication then
Registration is Rejected with MN_FAILED_AUTHNETICATION Code.
5. Registration Lifetime requested has to be less than the
remaining global registration lifetime, other wise the lifetime is
field is updated to the remaining global registration lifetime.
6. If the MN has not previously performed global registration
with the AnchorFA with global registered lifetime remaining, the
registration is rejected with MN_UNKNOWN error code.
On successful registration, the AnchorFA sends a registration reply.
The reply is formed similar to how a HA would [1]. Additionally:
1. Anchor Registration Extension is included before the
MN-AnchorFA AE. This extension is copied from the Registration Request.
2. Lifetime field is set to be lesser of the the remaining
global registration lifetime, the requested value, and a configured
value (for providing the option of forcing global registration within a
given time).
3. For Registration Reply in a Local Registration, FA-AnchorFA
AE could be used. It is computed in place of the FA-HA AE [1].
4. MN-AnchorFA AE is mandatory and is used in place of MN-HA
AE [1].
On successful registration the AnchorFA creates an appropriate tunnel
to the CoA and sets up routing such that datagrams that arrive
destined to this mobile from HA-AnchorFA tunnel is tunneled to the
via the AnchorFA-FA tunnel. If reverse tunneling is set, then the
datagrams that come from the FA-AnchorFA tunnel and generated by this
mobile (source address of the Mobile) are tunneled to the HA.
4.3 Global Indirect Registration
Global Indirect Registration is illustrated in Fig 4. This section
give the details of processing by the mobile IP entities.
4.3.1 MN processing
The MN is allowed to perform a Global Indirect Registration if it has
previously performed a Global Registration with a FA in the current
Zone. The registration request considerations are similar to the
considerations in the case of Local Registrations. The differences
with the Local Registrations are as follows:
- Only Foreign Agent CoA option is valid with Global Indirect
Registration. and CoA is set to AnchorFA.
- MN-HA AE is mandatory
- AnchorFA-MN Authentication Extension is optional
- Lifetime is chosen a recommended in RFC 2002 [1].
- Both timestamp-based and nonce based reply protection is supported.
-Anchor Registration Extension is included before the
MN-AnchorFA AE (MN-HA AE?). The Reg_Type field is set to GLOBAL_INDIRECT_REG.
4.3.2 FA processing
The processing performed is similar to the processing done during
Local Registration. Note that in this case only Foreign Agent CoA
option is chosen and the AnchorFA is set as the CoA. In this
registration option the also AnchorFA-FA AE is mandatory.
4.3.3 AnchorFA processing
AnchorFA on receipt of the Registration Request from the FA processes
the Request as a FA would process according to RFC 2002 [1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
FA.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not supported, a registration reject with
UNSUPPORTED_REG_TYPE is sent to the FA.
3. If FA-AnchorFA AE is missing or fails authentication then
Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION
Code.
4. MN-AnchorFA AE is optional and if present and fails
authentication then Registration is Rejected with
MN_FAILED_AUTHNETICATION Code.
5. If the MN has not previously performed global registration
with the AnchorFA with global registered lifetime remaining, the
registration is rejected with MN_UNKNOWN error code.
If the Registration Request is not denied it is sent to the HA with
the following:
1. FA-HA AE can be used optionally
On receipt of a registration reply. If the registration is rejected
the reject is relayed with mandatory AnchorFA-FA AE and optional
MN-AnchorFA AE.
If registration was accepted by the HA, the Anchor updates the Global
Registration lifetime for this mobile and ,sends a registration reply.
The reply is relayed to the FA with the following additions:
1. Anchor Registration Extension is included before the
FA-AnchorFA AE. This extension is copied from the Registration
Request. (Do we want to put this before MN-HA)
2. HA_FA AE in the reply message from the HA if present is
authenticated and removed.
3. FA-AnchorFA AE could be used. It is computed in place of the
FA-HA AE [1].
4. MN-AnchorFA AE is optional.
On successful registration the AnchorFA creates an appropriate tunnel
to the CoA and sets up routing such that datagrams that arrive
destined to this mobile from HA-AnchorFA tunnel is tunneled to the
via the AnchorFA-FA tunnel. If reverse tunneling is set, then the
datagrams that come from the FA-AnchorFA tunnel and generated by this
mobile (source address of the Mobile) are tunneled to the HA.
4.3.4 HA processing
Does regular HA processing.
5. Error Codes
The Following error codes are to be defined:
INVALID_ZONEID TBD
UNSUPPORTED_REG_TYPE TBD
MN_UNKNOWN TBD
7. Anchor FA Failover Recovery
When a Anchor FA Fails, the mobile node or the Foreign Agent might not
be aware of the failure. During the Failure the Anchor FA could loose
the Mobile Node registration. So, on recovery when a tunneled packet
arrives at the Anchor FA, it does not know how to forward this
packet. Several possible solutions can be implemented (This problem is
similar to the problem of HA Failure). Three possible alternatives are
described briefly and futher details will be provided in the future:
1. The AFA and the FA periodically exchange keepalive
message. When AFA Fails the FA informs the MN. By this
method the FA realizes of the failure quickly and requests
re-registration.
2. When the Anchor FA comesback up it unicasts/multicasts
packets to all the FA in its Zone to request mobiles to
re-register if the mobile is registered via this AFA. In this
method until the AFA recovers or the timer expires the mobile
does not perform re-registration.
3. Stateful redundancy of Anchor FAs can be maintained. This
method essentially reduces the probability of failure of
the Anchor FA.
6. Differences between Anchor Handoffs and Regionalized Tunnels
Anchor Handoffs and Regionalized Tunnels [4] are similar in principle
to realize the fast handoff, i.e., both of them try to eliminate the
signaling exchange between the HA and the FA. Here the assumption is
that the home network is usually far away from the visited network.
The most important difference between two handoff schemes is how to
implement the hierarchical FA infrastructure. In Anchor Handoffs, the
initiative is to keep it simple and flexible. The simplicity of the
scheme is not only easier to implement but also more scalable and
robust. Based on this principle, Anchor Handoff doesn't deploy any
prefdefined, complex static hierarchy, instead a dynamical hierarchy
is automatically formed in the runtime and continuously adapted to the
current mobility enviroment. By using the dynamical hierarchy, Anchor
Handoffs automatically spread the work load over the FAs in the same
region, and eliminates the need of a centralized bottleneck
router/expensive router. With no exsitence of a single point of
failure, Anchor Handoffs is also more robust. The dynamical hierarchy
also introduces extra advatanges. For example, the MN can eliminate
the FA hierarchy and simplify the indirect route anytime through a
global registration. This is especially useful when the MN is not
moving frequently. By executing the global registration after each
local registration, the smooth handoff can be automatically realized
in Anchor Handoffs. When the MN moves back and forth between the
anchor FA and another FA, the handoff only need to create or remove a
tunnel between the two FA's. This will reduce the handoff time
further. In Regionalized Tunnels, a static infrastructure is deployed,
and indirect multi-level tunnel aggregration always has to be done for
all mobiles irrespective of whether they moved or not. If more than
one level of hierarchy is employed, complicated security key
management is required.
It is possbile for the Anchoring Handoff and the Reagionalized Tunnel
Scheme to work together. The Anchoring Handoff can help in fast
handoff when a GFA has to be changed.
7. IANA Considerations
The Anchor Registration Extension defined in Section 3.2 is Mobile IP
registration extension as defined in RFC 2002 [1]. IANA should
assign a Type value consistent with this number space.
The Mobile IP Anchor Advertisement extension defined in section 3.1 is
taken from the numbering space defined for Mobile IP [1]
extensions to the ICMP Router Advertisements [2]. The numbers, 36 and
132, for the Generalized Authentication extension
The Code values defined in Section 5 are error codes as defined in
RFC 2002 [1]. IANA should assign values to these codes consistent
with this number space.
A new number space is being created for enumerating subtypes of the
Generalized Authentication extension [3]. The AnchorFA-FA AE and
AnchorFA-MN AE Subtypes are to be taken from this numbering space.
8. Acknowledgments
The author would like to thank Kent Leung for his suggestions and
helpful discussion. During the IETF presentation Authors realized that
the enhancements proposed in this document are very similar to the
enhancements proposed by David Johnson and Manoj Kashichainula of CMU.
9. References
[1] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
[2] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension.
draft-ietf-mobileip-challenge-09.txt, Feb 2000. (work in
progress).
[4] Eva Gustafsson, et. al. Mobile IP Regional Tunnel Management.
draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
[5] K. El Malki, et. al. Fast Handoff Method for Real-Time Traffic
over Scaleable Mobile IP Networks.
draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
Dommety [Page 4]
Internet Draft
Authors Information
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: gdommety@cisco.com
Tao Ye
ECSE Department
Rensselaer Polytechnic Institute
110 8th Street
Troy, NY 12180
e-mail: yet@rpi.edu
Dommety Local and Indirect Registration for Anchoring Handoffs Dec 2000
Appendix
The following enhancements will be considered in the future:
1. Option of Forcing Global Registration
Perform Global Registration Immediately
Perform Global Registration Next time.
2. Buffering issues during handoffs
3. Simultaneous Bindings at HA and AnchorFA
4. Private addressing: For private addressing GRE with Key has to be used.
5. Authorization from HA for performing Local Registrations
6. Overlapping Zones
7. Different Registration Options
8. Time offset enhancement extensions -This gives a hint of the
time offset between the FA and the MN to the mobile during global
registration. This can be used to successfully register at the
AnchorFA for Local Registration.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reservd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Difference +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAFTECH AB 2003-2026 | 2026-04-24 06:06:40 |