Mobility Optimizations Group Nick 'Sharkey' Moore, Monash CTIE INTERNET-DRAFT JinHyeock Choi, Samsung SAIT Brett Pentland, Monash CTIE 09 July 2004 Edge Handovers for Mobile IPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Moore, Choi, Pentland Expires: 09 January 2005 [Page 1] INTERNET-DRAFT Edge Handovers 09 July 2004 Abstract Edge Handovers (EH) is an interoperable enhancement to Mobile IPv6 to reduce handover latency for movement within an edge network, and to reduce handover signalling outside the edge network. EH does this by tunnelling traffic within the edge network, allowing a mobile node to maintain a stable Care-of Address while moving. Table of Contents Status of this Memo ......................................... 1 Abstract .................................................... 2 Table of Contents ........................................... 2 1. Introduction ............................................. 3 1.1 Versions of EH .................................. 3 1.2 History ......................................... 4 1.3 Terminology ..................................... 4 1.4 Comparison to HMIPv6 ............................ 5 2. Messages ................................................. 6 2.1 MAP option on RA ................................ 6 2.2 Local Binding Update ............................ 6 3. Requirements ............................................. 7 3.1 Mobile Node ..................................... 7 3.2 Access Router ................................... 8 3.3 Home Agent & Correspondent Nodes ................ 8 4. Operation ................................................ 9 4.1 Handover Operation .............................. 9 4.1.1 Movement .............................. 9 4.1.2 Obtaining a new RCoA .................. 10 4.1.3 Binding Update ........................ 10 4.2 Interoperation with an HMIP MAP ................. 11 4.3 Use of Dummy RCoA ............................... 11 5. Heuristics ............................................... 12 6. Security Considerations .................................. 13 7. IANA Considerations ...................................... 13 8. Alternative Version ...................................... 14 9. References ............................................... 15 Author's Addresses .......................................... 16 Acknowledgements ............................................ 16 Full Copyright Statement .................................... 17 Intellectual Property Statement ............................. 17 Disclaimer of Validity ...................................... 17 Moore, Choi, Pentland Expires: 09 January 2005 [Page 2] INTERNET-DRAFT Edge Handovers 09 July 2004 1. Introduction Edge Handovers (EH) is an interoperable enhancement to Mobile IPv6 [RFC3775] to reduce handover latency for movement within an edge network, and to reduce handover signalling outside the edge network. Handover latency must be reduced to allow real-time services such as telephony to be carried over Mobile IPv6. The handover latency can be divided into several separate delays[MOORE-NPH], and solutions exist to combat these delays individually. EH is designed to reduce the time taken for a Mobile Node (MN) to bind to a new location, thus reducing the traffic loss during handover. EH does this by tunnelling traffic within the edge network, so that connections using a particular Care-of Address can be continued when the MN has claimed a new Care-of Address on a new network. Multiple handovers per Home Agent BU are also allowed, and EH introduces the concept of the 'Bound MAP' and 'Bound Care-of Address' in order to track the address which has most recently been acknowledged by the HA. This allows a great deal of flexibility in the heuristic used to decide when to send a Binding Update to the HA. 1.1 Versions of EH This draft describes a version of EH built by expanding upon the techniques described in Hierarchical Mobile IPv6 [HMIPv6], particularly sections 8 ('Updating previous Anchor Points') and 10.2 ('MAP selection in a flat mobility management architecture'). MAP functionality is distributed to the edge of the Internet, and traffic is tunnelled through the edge network in order to maintain connectivity and remove BU latency. By using signalling and concepts introduced by HMIPv6, we hope to avoid introducing new security pitfalls. In addition, Section 8 of this draft outlines an alternative version of EH which uses many of the same concepts but which does not derive from HMIPv6 and which may prove more efficient. Moore, Choi, Pentland Expires: 09 January 2005 [Page 3] INTERNET-DRAFT Edge Handovers 09 July 2004 1.2 History The Tunnel Buffering functionality which was part of version -00 of this draft is quite separate from the core EH functionality, and has been moved into its own draft. This version of Edge Handovers has been implemented as an experimental patch to Linux 2.4.22 / Mipl-1.0. See for further information on our work. 1.3 Terminology Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current Practice - RFC2119 [RFC2119] Rather than introducing a new set of terminology, this draft uses the terminology introduced by HMIPv6. This section provides an overview of the terminology, for more details see [HMIPv6]. Care-of Addresses are subdivided into Local Care-of Addresses (LCoAs), which are specific to an Access Router (AR), and Regional Care-of Addresses (RCOAs), which are specific to a Mobility Anchor Point (MAP) and usable across a number of ARs. A Mobile Node (MN) moves between an Old Access Router (OAR) and a New Access Router (NAR). Before the move, it had an Old Local Care-of Address (OLCoA) and after, it forms a New Local Care-of Address (NLCoA). A MN can also request an RCoA from a MAP, and by keeping the MAP informed of its LCoA, this RCoA can be maintained while the MN moves within the coverage of that MAP. In addition, the MN keeps track of the CoA for which it has most recently received a BAck from its HA, referred to as the 'Bound RCoA' (BRCoA), and which MAP assigned this address, the 'Bound MAP' (BMAP). Moore, Choi, Pentland Expires: 09 January 2005 [Page 4] INTERNET-DRAFT Edge Handovers 09 July 2004 1.4 Comparison to HMIPv6 In HMIPv6, one or more MAPs are placed within the provider network, so that they can provide coverage to multiple ARs: +--------------------------+ | INTERNET CORE | +--------------------------+ | <--- Connection to the Internet. +------+ +------| MAP |-----+ <--- MAP in telco exchange. | +------+ | | | | <--- Backhauls to the exchange. +------+ +------+ +------+ | AR1 | | AR2 | | AR3 | +------+ +------+ +------+ | | | In EH, the MAP functionality is moved to the Edge Network. A single physical device may include both MAP and AR functionality. Fast Edge Network connections between access routers allow MAP coverage to be shared between ARs: +--------------------------+ | INTERNET CORE | +--------------------------+ | | | <--- Slow backhauls to +------+ +------+ +------+ the Internet. | MAP1 | | MAP2 | | MAP3 | +------+ +------+ +------+ | AR1 |--| AR2 |--| AR3 | <--- Fast Edge Network +------+ +------+ +------+ cross-connects the ARs. | | | Moore, Choi, Pentland Expires: 09 January 2005 [Page 5] INTERNET-DRAFT Edge Handovers 09 July 2004 2. Messages The following signals, defined in [HMIPv6] are used in this version of EH. No new messages or flags are required. 2.1 MAP option on RA. Just as in HMIPv6. An AR including MAP functionality advertises itself as a MAP with Dist=1, to indicate that it is on the edge network. In this case, the MAP address may be the same as the AR address. 2.2 Local Binding Update. The Local Binding Update (LBU) message is also used as it is in HMIPv6. In the following text, an LBU which requests that traffic for an address A be tunnelled to/from an address B is represented as LBU(A -> B). Moore, Choi, Pentland Expires: 09 January 2005 [Page 6] INTERNET-DRAFT Edge Handovers 09 July 2004 3. Requirements 3.1 Mobile Node * Upon arriving at a NAR, the MN receives a Router Advertisement, and thus learns its new prefix and the address of the MAP(s) available on the NAR. Using this information, the MN: 1. MUST determine its NLCoA from the AR prefix. 2. MUST send an LBU(BCoA -> NLCoA) to its Bound MAP. 3. If there is an advertised MAP with the same address as the AR address, the MN SHOULD use that MAP an assume EH support is available. If there is no such MAP, the MN SHOULD NOT assume that the AR supports EH, and SHOULD instead fall back to HMIP behaviour for MAP selection and handover for MAP selection and handover for MAP selection and handover for MAP selection and handover for MAP selection and handover for MAP selection and handover for MAP selection and handover for MAP selection and handover. * At any time, the MN may wish to obtain a new RCoA from the MAP advertised by its current AR. 1. MUST determine its NRCoA from the MAP prefix. 2. MUST send an LBU(NRCoA -> LCoA) to the MAP address. * When it decides to update its HA and CNs, according to a heuristic as per section 5 below, the MN: 1. MUST determine which MAP it is moving to. 2. MUST determine its NRCoA and send an LBU(NRCoA -> LCoA) to this MAP if it has not done so already. 3. MUST send a BU(HAddr -> NRCoA) to its HA. 4. SHOULD send a BU(HAddr -> NRCoA) to its CNs. 5. When it receives a BAck from its HA, it MUST set BMAP and BRCoA accordingly, to record the most recent MAP/BRCoA that the HA has acknowledged. Moore, Choi, Pentland Expires: 09 January 2005 [Page 7] INTERNET-DRAFT Edge Handovers 09 July 2004 3.2 MAP * The MAP functionality SHOULD be built into the AR. If it is, the MAP SHOULD use the same global address as the AR, and the MAP Option in the Router Advertisement MUST have Distance = 1. * The MAP SHOULD, on reception of an LBU with a valid RCoA, tunnel traffic for that RCoA to the new LCoA. 3.3 Home Agent & Correspondent Nodes As with HMIPv6, there are no requirements for Home Agents or for Correspondent Nodes beyond that specified in [RFC3775] and [NODEREQS]. Moore, Choi, Pentland Expires: 09 January 2005 [Page 8] INTERNET-DRAFT Edge Handovers 09 July 2004 4. Operations The following sections outline the operation of EH according to the rules above. 4.1 Handover Operation The following diagrams consider a handover from OAR to NAR, where a binding exists for BAR. Note that the BAR and the OAR may be one and the same. 4.1.1 Movement The MN sends an LBU informing the Bound MAP of its new location at the NAR and requesting tunnelling of packets to NLCoA. No Binding Update is sent to the HA or CNs, so traffic continues to be delivered to the Bound MAP, which redirects it across the edge network to the NLCoA. +-----+ ************< | HA | * +-----+ * | * Edge | Network * +--------------+--------------+ * | | | * | *********************** | * | * | * | V | ^ | * | | | * | +-----+ +-----+ * +-----+ |BMAP | | MAP | * | MAP | +-----+ +-----+ * +-----+ | BAR | | OAR | * | NAR | +-----+ +-----+ * +-----+ | | V | ^ | \.................... +-----+ | MN | +-----+ Moore, Choi, Pentland Expires: 09 January 2005 [Page 9] INTERNET-DRAFT Edge Handovers 09 July 2004 4.1.2 Obtaining a new RCoA To obtain a new RCoA, the MN sends an LBU to the MAP on the current AR. The MAP will reply with a LBAck. This RCoA is not used immediately, but is needed for the next step. 4.1.3 Binding Update At a time decided by the heuristic in section 5, but after local movement signalling has completed, the MN sends a BU(HAddr->NRCoA) to its HA (and CNs). Traffic already in flight will be redirected by the MAP on the BAR, and new traffic coming via the HA will be delivered directly to the NAR. +-----+ <................. | HA | : +-----+ >*********** : | * : Edge | Network * : +--------------+--------------+ * : | | | * : | | | * : | | | * : | | | V : | | | : +-----+ +-----+ +-----+ : |BMAP | | MAP | | MAP | : +-----+ +-----+ +-----+ : | BAR | | OAR | | NAR | : +-----+ +-----+ +-----+ : | | | : | : +-----+ ...: | MN | +-----+ Moore, Choi, Pentland Expires: 09 January 2005 [Page 10] INTERNET-DRAFT Edge Handovers 09 July 2004 4.2 Interoperation with an HMIP MAP hierarchy EH maintains interoperability with HMIPv6. A MN moving from EH coverage to HMIPv6 MAP coverage performs MAP-to-MAP handovers correctly, and an AR may advertise both HMIPv6 MAPs and EH MAPs without confusion, allowing the MN to pick between them according to its own MAP selection heuristics. 4.3 Use of Dummy RCoA Another potential improvement which applies to HMIPv6 MAP as well as EH-ARs is the use of a dummy network for provisioning the RCoA. If the advertised MAP prefix describes a dummy network that only exists inside the MAP, then the MAP must be aware of all of the addresses in use on the network. This eliminates the need for the MAP to perform DAD for RCoAs before acknowledging Local Binding Updates. Since there are no devices physically connected to the dummy network, the need for the MAP to perform proxy neighbour discovery on behalf of the MNs is also eliminated. Moore, Choi, Pentland Expires: 09 January 2005 [Page 11] INTERNET-DRAFT Edge Handovers 09 July 2004 5. Heuristics By using Edge Handovers, the BU to the HA is removed from the critical path for a handover, and can be performed after the handover is complete. Possible heuristics for determining when a BU should be sent include: * ... as soon as the critical path of the handover is complete. * ... every N handovers. * ... once the MN has remained on the same AR for N seconds. * ... if a handover has crossed administrative domains. * ... if the number of routing hops taken by the LBAck from the BAR > N hops. The choice of heuristic is not critical to the operation of EH, and is beyond the scope of this draft. The ideal heuristic is likely to be different on different networks, and is a topic for further research. However, the MN MUST update its BAR before the end of the Valid Lifetime of the BCoA, as determined by the 'Valid Lifetime' field of the MAP option of the RA received from the BAR. Moore, Choi, Pentland Expires: 09 January 2005 [Page 12] INTERNET-DRAFT Edge Handovers 09 July 2004 6. Security Considerations The version of EH presented above uses HMIPv6 signalling throughout, and is subject to all the security precautions of HMIPv6, and thus it has similar security considerations to HMIPv6. We do not believe that the changes to the operation of the protocol will introduce new security flaws. 7. IANA Considerations None beyond the additions specified in [HMIPv6]. No new signalling is introduced by this draft. Moore, Choi, Pentland Expires: 09 January 2005 [Page 13] INTERNET-DRAFT Edge Handovers 09 July 2004 8. Alternative Version The version of Edge Handovers as presented above is based on HMIPv6, and this results in the traffic always being tunnelled from MAP to MN. This is not the most efficient way. An alternative method, more akin to [FAST-MIPv6], is outlined here and will be expanded upon in a later version of this draft. Rather than regarding each AR as 'including' a MAP, we simply allow ARs to interpret Local Binding Updates as redirections. The MN keeps track of a Bound Care-of Address (BCoA), which is the address the MN most recently received a BAck from its HA for, and a Bound Access Router (BAR) which is the router which provides the prefix used to generate this address. Rather than having separate LCoA and RCoA, the MN has only a CoA (on its current AR) and a Bound CoA (BCoA) on its BAR. The BAR may be the current AR, the BCoA may be equal to the CoA. * The MN obtains a prefix and configures a CoA. * The MN sends a BU to its HA. When the MN receives a BAck for the CoA, it regards it as its BCoA and the access router its prefix is obtained from as its BAR. * When the MN moves, it sends an LBU(BCoA -> NCoA) to the BAR, to request the tunnelling of traffic for the BCoA to NCoA. * When the BAR receives this LBU, it redirects traffic directed to the BCoA to the NCoA. * After some delay (as per the heuristic discussed in section 5) the MN sends BUs to the HA (and CNs if applicable) and when it receives a BAck from the HA, it updates its notion of the BAR and BCoA. * If the MN returns to its BCoA, it reconfigures the BCoA (thus overriding the BAR's proxy use of the BCoA) and sends the BAR an LBU(BCoA -> BCoA) with Lifetime=0 to request the cessation of the tunnelling service. Moore, Choi, Pentland Expires: 09 January 2005 [Page 14] INTERNET-DRAFT Edge Handovers 09 July 2004 9.1 RFC References [RFC2119] S. Bradner, "Keywords to use in RFCs to Indicate Requirement Levels". Request for Comments (Best Current Practice) 2119 (BCP 14). [RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for IP version 6". Request for Comments (Draft Standard) 2461. [RFC3775] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6". Request for Comments (Proposed Standard) 3775. 9.2 Internet Draft References [HMIPv6] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)". [FAST-MIPV6] R. Koodli (ed) "Fast Handovers for Mobile IPv6". [NODEREQS] J. Loughney (ed) "IPv6 Node Requirements". 9.3 Other References [MOORE-NPH] N. Moore, "Non-Predictive Handovers". (Presentation at IETF 56 in MobileIP WG) Moore, Choi, Pentland Expires: 09 January 2005 [Page 15] INTERNET-DRAFT Edge Handovers 09 July 2004 Authors' Addresses: Nick 'Sharkey' Moore or Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia JinHyeock Choi Samsung Advanced Institute of Technology P.O. Box 111, Suwon 440-600 Korea Brett Pentland Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia Acknowledgments This work has been supported by the Australian Telecommunications Cooperative Research Centre (AT-CRC) Funding for the RFC Editor function is currently provided by the Internet Society. Moore, Choi, Pentland Expires: 09 January 2005 [Page 16] INTERNET-DRAFT Edge Handovers 09 July 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOS Moore, Choi, Pentland Expires: 09 January 2005 [Page 17]