Mobility Optimizations Group Nick 'Sharkey' Moore, Monash CTIE INTERNET-DRAFT JinHyeock Choi, Samsung SAIT Brett Pentland, Monash CTIE 09 Feb 2004 Edge Handovers for Mobile IPv6 Status of this Memo 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 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the author. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - RFC2119 [RFC2119] Moore, Choi, Pentland Expires: 09 August 2004 [Page 1] INTERNET-DRAFT Edge Handovers 09 Feb 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. Multiple handovers per Home Agent are also allowed, and EH also considers the situation where a MN anticipates that it is about to move but does not know where it is about to move to. Table of Contents Status of this Memo ......................................... 1 Abstract .................................................... 1 Table of Contents ........................................... 2 1. Introduction ............................................. 3 1.1 Versions of EH .................................. 3 1.2 Terminology ..................................... 4 2. Messages ................................................. 4 2.1 MAP option on RA ................................ 4 2.2 Local Binding Update ............................ 4 3. Requirements ............................................. 5 3.1 Mobile Node ..................................... 5 3.2 Access Router ................................... 5 3.3 Home Agent & Correspondent Nodes ................ 6 4. Operation ................................................ 6 4.1 Handover Operation .............................. 6 4.1.1 Anticipation .......................... 7 4.1.2 Movement .............................. 8 4.1.3 Binding Update ........................ 9 4.2 Buffering Operation ............................. 10 4.2.1 Interoperation with an HMIP MAP ....... 10 4.3 Use of Dummy RCoA ............................... 11 5. Heuristics ............................................... 11 6. Security Considerations .................................. 12 7. Alternative Version ...................................... 12 8. References ............................................... 13 Author's Addresses .......................................... 14 Moore, Choi, Pentland Expires: 09 August 2004 [Page 2] INTERNET-DRAFT Edge Handovers 09 Feb 2004 1. Introduction 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. 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 four separate delays[MOORE-NPH], and solutions exist to combat these delays individually. This draft focuses on reducing the Binding Update Round-Trip Time Delay (BU-RTT), eg: the time taken for a Binding Update (BU) to reach the Home Agent (HA) and for traffic to be redirected to the mobile node's new location. 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 update are also allowed, and EH introduces the concept of the 'Bound Access Router' 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. EH also considers the situation where a MN anticipates that it is about to move, but does not know where it is about to move to. In this case, it sends a special LBU requesting that its traffic be buffered until it has determined its new link CoA and can send another LBU. 1.1 Versions of EH This draft describes a version of EH built by expanding upon the techniques mentioned 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 potential security pitfalls. In addition, this draft outlines an alternative version of EH which uses many of the same concepts but which may prove slightly more efficient. Moore, Choi, Pentland Expires: 09 August 2004 [Page 3] INTERNET-DRAFT Edge Handovers 09 Feb 2004 1.2 Terminology For the sake of brevity, an Access Router capable of supporting Edge Handovers is referred to as an 'EH-AR'. 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). When an MN requests EH service from an EH-capable access router, it is also assigned a 'Regional Care-of Address' (RCoA). The RCoA assigned by the OAR is the ORCoA, and that assigned by the NAR is the NRCoA. 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 Care- of Address' (BCoA), and which AR assigned this address, the 'Bound Access Router' (BAR). 2. Messages The following signals, defined in [HMIPv6] are used in this version of EH: 2.1 MAP option on RA. Just as in HMIPv6. An EH capable AR advertises itself as a MAP with Dist=1, to indicate that it is on the edge network. 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 August 2004 [Page 4] INTERNET-DRAFT Edge Handovers 09 Feb 2004 3. Requirements 3.1 Mobile Node * The MN, if it determines that it is about to move to an unknown location, MAY send an LBU(BCoA -> ::) to its BAR to request buffering. * Upon arriving at a NAR, the MN: 1. MUST determine its NLCoA. 2. MUST send an LBU(BCoA -> NLCoA) to its BAR. 3. MAY send an LBU(NRCoA -> NLCoA) to its NAR. * When it decides to update its HA and CNs, according to a heuristic as per section 5 below, the MN: 1. MUST send an LBU(NRCoA -> NLCoA) to its NAR if it has not done so already 2. MUST send a BU(HAddr -> NRCoA) to its HA 3. MAY send a BU(HAddr -> NRCoA) to its CNs. 4. When it receives BAck from its HA, it MUST set BAR and BCoA accordingly. 3.2 Access Router * The AR SHOULD, on reception of an LBU with a valid RCoA, tunnel traffic for that RCoA to the new LCoA. * The AR SHOULD, on reception of an LBU with a valid, currently active RCoA and an LCoA of '::' (the unspecified address), buffer a number of packets for that RCoA to be sent when an LBU directing that RCoA to a new LCoA is received. Moore, Choi, Pentland Expires: 09 August 2004 [Page 5] INTERNET-DRAFT Edge Handovers 09 Feb 2004 3.3 Home Agent & Correspondent Nodes As in HMIPv6, there are no requirements for Home Agents or for Correspondent Nodes beyond that specified in [MIPv6] and [NODEREQS]. 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. Moore, Choi, Pentland Expires: 09 August 2004 [Page 6] INTERNET-DRAFT Edge Handovers 09 Feb 2004 4.1.1 Anticipation If the MN anticipates movement, it can request that its EH-capable BAR buffer traffic for it, in the hope that this will reduce the number of packets lost during handover. +-----+ ************< | HA | * +-----+ * | * Edge | Network * +--------------+--------------+ * | | | * | ...... | | * | : : | | V | v : | | | : | | +-----+ : +-----+ +-----+ | BAR | : | OAR | | NAR | +-----+ : +-----+ +-----+ | : | : | :.. +-----+ | MN | +-----+ (1) The MN sends an LBU(BCoA -> ::) to its BAR (2) The BAR begins buffering packets for the MN. Moore, Choi, Pentland Expires: 09 August 2004 [Page 7] INTERNET-DRAFT Edge Handovers 09 Feb 2004 4.1.2 Movement The MN sends an LBU informing the BAR 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 BAR, which redirects it across the edge network to the NAR. +-----+ (3) Traffic from HA ************< | HA | and RO CNs continues * +-----+ to be delivered to BCoA * | (and BAR tunnels it to * Edge | Network NCoA) * +--------------+--------------+ * | | | * | *********************** | (2) Traffic for BCoA * | * | * | is tunneled to NCoA V | ^ | * | | | * | +-----+ +-----+ * +-----+ | BAR | | OAR | * | NAR | +-----+ +-----+ * +-----+ | | V | ^ | \.................. +-----+ | MN | (1) LBU packets are +-----+ sent to BAR. Moore, Choi, Pentland Expires: 09 August 2004 [Page 8] INTERNET-DRAFT Edge Handovers 09 Feb 2004 4.1.3 Binding Update At a time decided by the heuristic in section 5, but after local movement signalling has completed, the mobile node also sends a BU to its HA and CNs. Traffic already in flight will be redirected by the BAR, and new traffic coming via the HA will be delivered directly to the NAR. +-----+ <................. | HA | : +-----+ >*********** : | * : Edge | Network * : +--------------+--------------+ * : | | | * : | | | * : | | | * : (5) Traffic is | | | V : directed to NCoA | | | : +-----+ +-----+ +-----+ : | BAR | | OAR | | NAR | : +-----+ +-----+ +-----+ : (4) BU is sent to | | | : HA, and any RO CNs. | : +-----+ ...: | MN | +-----+ (6) Once the BAck is received from the HA, the MN updates its record of the BAR. Moore, Choi, Pentland Expires: 09 August 2004 [Page 9] INTERNET-DRAFT Edge Handovers 09 Feb 2004 4.2 Buffering Operation If an MN obtains an indication that it is about to move to another link, it MAY request that its BAR suspend delivery of its packets until it arrives on that link. To trigger packet buffering the MN sends an LBU to the BAR with an Alternate Care-of Address option with the address set to the unspecified address, '::'. Upon reception of this null Alternate CoA, the BAR should cease tunnelling packets to the MN and commence buffering packets. The number of packets buffered is implementation dependent (possibly zero), as is the procedure for handling overflow (drop new packets or drop the oldest packet). Upon arrival at a new link, the MN sends an LBU to the BAR to create a binding to the new LCoA. The BAR MUST then restart tunnelling of packets for the MN's RCoA, beginning with those packets held in its buffer. 4.2.1 Interoperation with an HMIP MAP When a MAP receives an LBU, it processes it in the same way as an HA would process a BU in MIPv6. Section 6.1.7 of [MIPv6], "Binding Update Message", states: "The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. IPv6 Source Address MUST be a topologically correct source address. Binding Updates for a care-of address which is not a unicast routable address MUST be silently discarded." If this is carried out by a MAP then packets destined for the RCoA of the MN will be lost after the MN leaves the link until it arrives at the new link and updates its binding to the BAR with its new LCoA. It is worth noting that section 9.5.1 of [MIPv6], "Receiving Binding Updates", does not appear to specify any particular handling for Binding Updates with any particular Alternate Care-of Addresses. If the text of section 6.1.7 of [MIPv6] shown above is not heeded by an implementor, then a MAP might attempt to create a binding to the unspecified address with unexpected results. Moore, Choi, Pentland Expires: 09 August 2004 [Page 10] INTERNET-DRAFT Edge Handovers 09 Feb 2004 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 prefix advertised in the MAP option sent by an EH-capable AR describes a dummy network that only exists inside the AR, then the AR must be aware of all of the addresses in use on the network. This eliminates the need for the EH-AR/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 EH-AR/MAP to perform proxy neighbour discovery on behalf of the MNs is also eliminated. 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. 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 August 2004 [Page 11] INTERNET-DRAFT Edge Handovers 09 Feb 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 the same security considerations as HMIPv6. We do not believe that the changes to the operation of the protocol will introduce new security flaws. 7. Alternative Version The version of Edge Handovers as presented above is largely based on HMIPv6, and this results in the traffic always being tunnelled from AR to MN. This is not necessarily 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. * 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. * If the MN anticipates movement, it sends an LBU(BCoA -> ::) to the BAR. The BAR will commence proxy neighbour discovery for the BCoA, sending a single unsolicited NA with O=1 to override the previous entry (allowed by [RFC2461] section 7.2.6) and then falling back to O=0 as per usual proxy behaviour. * When the MN moves, it sends an LBU(BCoA -> NCoA) to the BAR, to request the tunnelling of traffic for the BCoA to 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 August 2004 [Page 12] INTERNET-DRAFT Edge Handovers 09 Feb 2004 8.1 RFC References [RFC2119] S. Bradner, "Keywords to use in RFCs to Indicate Requirement Levels". RFC2119. [RFC2461] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for IP version 6". RFC 2461. 8.2 Internet Draft References [HMIPv6] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)". [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6". [FAST-MIPV6] R. Koodli (ed) "Fast Handovers for Mobile IPv6". [NODEREQS] J. Loughney (ed) "IPv6 Node Requirements". 8.3 Other References [MOORE-NPH] N. Moore, "Non-Predictive Handovers". (Presentation at IETF 56) Moore, Choi, Pentland Expires: 09 August 2004 [Page 13] INTERNET-DRAFT Edge Handovers 09 Feb 2004 Authors' Addresses: Nick 'Sharkey' Moore 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 Moore, Choi, Pentland Expires: 09 August 2004 [Page 14]