Internet Draft R.J.Jayabal Document: draft-rjaya-ct-fmip6-l2st-ant-ho-00.txt I2R, A-STAR Expires: October 2002 March 2003 Context Transfer and Fast Mobile IPv6 Interactions in a Layer-2 Source-Triggered Anticipative Handover 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 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 This draft was submitted to obtain comments for an experimental work in progress. It presents Fast Mobile IPv6 and Context Transfer interactions for a specific case of contextful, anticipative, network controlled and Layer-2 source-triggered IPv6 handover where one or more candidate access routers can be identified for selection as target. It is also meant to illustrate a case where it might be useful to: a) have Context Transfer messages as but options in handover negotiation messages (e.g., Fast MIPv6's HI/HACK messages) between Access Routers. b) have an additional flag in the Context Transfer Protocol Context Transfer Data message which indicates whether the new Access Router should install any context at all given that any one context fails to be installed. Jayabal Expires - September 2003 [Page 1] CT-FMIP6 in L2-ST Anticipative Handover March 2003 c) not make the Fast MIPv6 FBU/FBACK message exchanges mandatory where Layer-2 triggers are adequate, and lax the message sequence requirements of PrRtAdv and HI/HACK by the old Access Router in such a situation. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The following abbreviations are used in this document: AP (L2) Access Points AR Access Router BT Bidirectional Tunnel [3] cAR Candidate Access Router CT Context Transfer [4] CTD Context Transfer Data Message [4] CTDR Context Transfer Data Reply Message [4] CTP Context Transfer Protocol [4] FBACK Fast Binding Acknowledgment [3] FBU Fast Binding Update [3] FMIP6 Fast Mobile IPv6 [3] HACK Handover Acknowledge [3] HI Handover Initiate [3] L2 Layer-2 L2-ST Layer-2 Source Trigger [3] L2-LD Layer-2 Link Down [3] L2-LU Layer-2 Link Up [3] L3 Layer-3 L4 Layer-4 MIP6 Mobile IPv6 [2] MN Mobile Node nAR New Access Router NCoA New Care-Of Address [2] oAR Old Access Router PrRtAdv Proxy Router Advertisement [3] Table of Contents 1. Introduction...................................................3 2. Main Scenario and Assumptions..................................3 3. Proposed Interactions for the Main Scenario....................5 4. Modifications to FMIP6 & CTP...................................6 5. Scenarios Involving One or More Than Two cARs..................7 Jayabal Expires - September 2003 [Page 2] CT-FMIP6 in L2-ST Anticipative Handover March 2003 Security Considerations...........................................7 References........................................................7 Acknowledments....................................................8 Author's Address..................................................8 1. Introduction The Mobile-IP protocol [2] define how an IPv6 MN can change its L3 point of attachment to networks and yet maintain ongoing L4 sessions. Related to this protocol is the concept of fast handover [3], where important L3 information is made available to the MN and a tunnel which act as a temporary routing path is setup between ARs so that the handover latency as experienced by the MN can be reduced. Context transfer [4] refers to the transfer of state from an oAR to a nAR as the MN handovers from an old subnet to a new subnet. This state corresponds to L2/L3 security and QoS/resource configurations maintained by the oAR as a policy enforcement point for the MN. In certain handover scenarios over certain L2 technologies, it may be possible for an oAR to know in advance one or more cARs to use as nAR for the impending handover (e.g., via L2 signal strength reports and AP-AR association tables), while at the same time be uncertain as to whether any of these candidates can accomodate the MN. In such a scenario, it may be useful for the oAR to enter into handover negotiations with more than one cAR before providing the MN the handover instruction. During the handover negotiation with any one of these cARs, the oAR can send CT objects to the cAR so that the cAR can determine whether, given its current state of utilisation and/or configured policies, it can support the handover of the MN to its control/subnet and reply to the oAR appropriately. On completing a successful handover negotiation, the oAR can then go about informing the MN of the nAR L3-specific information, so that the MN can perform MIP6/FMIP6 handover in an expedited manner. 2. Main Scenario and Assumptions The following diagram illustrates the main scenario for the specific handover case in question: Jayabal Expires - September 2003 [Page 3] CT-FMIP6 in L2-ST Anticipative Handover March 2003 ` +------+ ` ` | cAR1 | ` ` +------+ ` ` A possible ` ` current . future attachment ` ` attachment movement . point 1 ` ` +------+ point +------+ direction ........ ` ` | oAR |<---------->| MN |..........>. MN . ` ` +------+ +------+ ........ ` ` . possible ` ` . future attachment ` ` V point 2 ` ` +------+ ` ` | cAR2 | ` ` +------+ ` Figure 1: Reference Scenario for a Specific Anticipative Handover Initially, the MN is attached to the oAR, but is moving out of the coverage of the L2 AP(s) attached to the oAR and moving into the coverage of the AP(s) attached to cAR1 and cAR2. Let us permit ourselves to make the following assumptions: thru some mechanisms outside the scope of this document, the oAR a) is aware of cAR1, cAR2 and their capabilities, and have established security associations with them prior to the handover taking place. b) has determined cAR1 and cAR2 to be possible targets for the handover, but is not quite sure which will eventually be the actual target. c) has decided to systematically attempt a handover to cAR1 first, failing which it will attempt a handover to cAR2. For b), the reason behind the uncertainty could be because there is no information available to favour one cAR over the other, or the information need to make the decision could be limited to some degree of confidence, for example due to the time-discrete nature of reports/updates if sent by the cARs. For c), the reason for the order of attempt could be arbitrary, or it could be that the oAR, thru some reporting/updating mechanisms, has some fore-knowledge of the latest-known resource utilisation levels and policy settings configured in the cARs. Jayabal Expires - September 2003 [Page 4] CT-FMIP6 in L2-ST Anticipative Handover March 2003 In actuality however, let us say that, cAR1 is not or no longer the most suitable router to support the MN, and that cAR2 is the most suitable or has since become the most suitable router to support the MN. Ideally, we would like the oAR to handover the MN to cAR2 with as little messaging delay as possible. 3. Proposed Interactions for the Main Scenario Given the above scenario, the following main interactions are proposed. Although initially designed to work within another signalling framework, it is presented now modified to adhere as best as possible to the rules defined in section 4.5 of [3]: `MN oAR cAR1 cAR2 ` ` | L2-ST | | | ` ` |<...............>| | | ` ` | | HI(CTD option) | | ` ` | +---------------->| | ` ` | HACK(CTDR option, -ve reply) | ` ` | |<----------------+ | ` ` | | HI(CTD option) | ` ` | +---------------------------------->|context ` ` | | | |installed` ` | | | +---+ ` ` | | | | | ` ` | | | |<--+ ` ` | | HACK(CTDR option, +ve reply) | ` ` | |<----------------------------------+ ` ` | PrRtAdv()| | | ` ` |<----------------+ | | ` ` | L2-LD | | | ` ` |<...............>| | | ` ` | | packet forwarding | ` ` | |==================================>| ` ` | | L2-LU | | ` ` |<...................................................>| ` ` | | packet delivery | | ` ` |<====================================================+ ` ` . .tunnel lifetime expires, . ` ` | |tunnel & context removed | ` ` | +---+ | | ` ` | | | | | ` ` | |<--+ | | ` Figure 2: Proposed Signalling Jayabal Expires - September 2003 [Page 5] CT-FMIP6 in L2-ST Anticipative Handover March 2003 Initially, an L2 event (L2-ST) happens triggering the handover process. In response, the oAR sends a FMIP6 Handover Initiate (HI) message carrying a Context Transfer Data (CTD) message as an option to cAR1. As per section 4.5 of [FMIP6], this message also carries a tunnel lifetime option. Since cAR1 is not or no longer suitable to support the MN, it replies the oAR with either (depending on the configuration and level of support for FMIP6 and CT of the network): a) an FMIP6 Handover Acknowledged (HACK) message with the code field set to 'Administratively Prohibited' if an unfavourable change in policy has occured, or 'Insufficient Resources' if its unsuitability is due to increase in resouce utilisation. b) an FMIP6 Handover Acknowledged (HACK) message with a 'Handover Accepted' carrying the Context Transfer Data Reply (CTDR) message as an option. The CTDR in this case may indicate aggregate failure or partial failure. On receipt of this negative HACK message, the oAR proceeds to repeat the HI/HACK process with cAR2. In the given scenario, this set of interaction will result in the context successfully transferred and setup in cAR2. When the oAR receives the positive HACK message from cAR2, bi-directional tunnel is setup. In response, the oAR sends a PrRtAdv carrying the L2 identifier associated with and the NCOA to use when attached to cAR2. On receipt of the PrRtAdv message (which acts as a handover instruction), the MN detaches itself from the current link (L2-LD) and re-attaches itself on the new link associated with the L2 identifier carried in the message (L2-LU). Packet forwarding and delivery by the oAR and nAR, respectively, happens as per section 4.5 in [FMIP6]. Finally, when the tunnel lifetime expires, both the tunnel and the context on the oAR is removed. 4. Modifications to FMIP6 & CTP This approach is only possible or greatly simplified if the following changes can be made to [3] and [4]: a) have Context Transfer messages as options in the HI/HACK messages. b) have another flag in the CTD message which indicates whether the nAR should install any context at all given that any one context Jayabal Expires - September 2003 [Page 6] CT-FMIP6 in L2-ST Anticipative Handover March 2003 fails to be installed. This can then be used in networks with over-provisioned radio resource to ensure that no contexts are installed unnecessarily on a cAR that is not the most suitable AR to support the MN. On receipt of a CTD with this flag set, the cAR MUST not install any of the contexts if one or more of the contexts fail to install. c) not make the sending or processing of FBU messages mandatory (see section 4.5 paragraph 4a) where L2 triggers are adequate and mobility of the MN is fully controlled by the network. In such cases, FBU may be quite redundant (IMHO). d) lax the message sequence of PrRtAdv and HI/HACK by the old Access Router. This enables the oAR some flexibility in terms of specifying which AR the MN should handover to when more than one cAR is available, and also allow context transfer to be negotiated and contexts installed on the nAR simultaneously with FMIP6 inter-AR handover signalling. 5. Scenarios Involving One or More Than Two cARs Interactions for these scenarios are similar to the one described above except for the number of HI/HACK exchanges between the oAR and cARs. Security Considerations Given that these interactions are meant to be included in the larger picture of [3,4], all security considerations which apply to [3,4], except for the transport-level security considerations in [4], equally apply here as well. References 1 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 2 D. Johnson, C. Perkins, and J. Arkko. "Mobility Support in IPv6" Internet Draft, Internet Engineering Task Force, 2002. Work in progress. 3 R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet Draft, Internet Engineering Task Force. Work in Progress. Jayabal Expires - September 2003 [Page 7] CT-FMIP6 in L2-ST Anticipative Handover March 2003 4 J. Loughney (Ed), "Context Transfer Protocol", Internet Draft, Internet Engineering Task Force, March 2003. Work in progress. Acknowledgments Thanks to Parijat Mishra (colleague) for suggesting that the sequence of handover attempts could be arbitrarily derived. Author's Address Raymond Jayaraj Jayabal I2R, A-STAR 20 Science Park Road, #02-34/37 Science Park II, Singapore 117674 Phone: +65-68709330 Fax: +65-67745441 Email: jraymond@i2r.a-star.edu.sg Jayabal Expires - September 2003 [Page 8]