INTERNET DRAFT Gopal Dommety Category: Standards Track cisco Systems Title: draft-dommety-mobileip-anchor-handoff-02.txt Tao Ye July 2001 RPI Expires December 2001 Local and Indirect Registration for Anchoring Handoffs draft-dommety-mobileip-anchor-handoff-03.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). The FA remembers the difference between local time and HA time if the timestamp replay protection method is used. This is to be used in future possible local registrations of this MN with another FA. 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 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. 7. Check the Identification field. If the timestamp replay protection is used, the Anchor will automatically correct the timestamp in the request with the time difference between local time and HA and do the invalidation with the compensated timestamp. If the the check fails, Registration Reject is sent with an MN_BADID and the corresonding time discrepancy. 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 6. 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. 7. Differences between Anchor Handoffs and Regionalized Tunnels Anchoring 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 Anchoring 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, Anchoring 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, Anchoring 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, Anchoring 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 Anchoring 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. 8. 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. 9. Relation to Fast Handoff Work This work can be put in the context of Low Latency handoff work being done it IETF. 10. Implementation Status The anchoring handoff scheme has been partially implemented and tested in Cisco IOS system. The handoff delay and packet loss are greatly improved in the test when the link delay between HA and anchor FA is long. The current implementation supports local registration and global registration, but still doesn't include global indirect registration support. Dynamical Security Association acquiration is also to be included in future. 10. 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. 11. 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+