INTERNET DRAFT Satish Jamadagni 08 February 2002 Satish D Shiva Raman Pandey Sasken Communication Technologies Ltd A Context Transfer Framework for supporting fast handover draft-satish-contexttransfer-framework-00.txt 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 This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments SHOULD Be submitted to the seamoby@cdma_2000.org mailing list. Distribution of this memo is unlimited. Abstract Mobile nodes enhance their connections across wireless media by establishing specific parameters at the FA/AR/AP in order to facilitate optimal usage of the resources as well as enhance the QoS as seen by a MN. During handover from one access router to another, a bandwidth-constrained mobile node MAY need to have state information passed from the previous router to the new one. This document proposes a context transfer framework that makes use of existing fast handoff signaling for context transfer as well as provide a mechanism for QoS negotiation and renegotiations. We also cover CT under CAR discovery. The suggested mechanism provides for context transfer so that the applications running on the mobile node could operate with minimal disruption. Satish et Al [Page i] Internet Draft CT Framework supporting Fast Handover Feb 2002 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 3. Data Structure 3 4. Context transfer Options with Handover Signaling 5 4.1. Basic Handover Signaling: Reactive CT 6 4.2. Context transfer under Fast Handover Signaling 6 4.2.1 Proactive before 8 4.2.1.1. CT bound to the CAR discovery process 9 4.2.2 Proactive with 9 4.2.3 Proactive after 10 5. Timing Requirements for context transfer 10 6. Partial Handover 10 7. Context (re) negotiation 10 8. References 11 9. Author's Addresses 12 1. Introduction When a mobile node undergoes handover from an access router to another, context information pertaining to the mobile node's packet streams needs to be transferred in order to maintain the same QoS feel at the mobile node. This operation ensures that the mobile node does not have to re-establish the contexts associated with various features, such as QoS, header compression, security etc. When the mobile node is attached to its access router through a low- bandwidth wireless link the seamless operation also provides performance benefits, since context establishment typically involves transmission of a considerable amount of data. In this document, we describe a context transfer framework, which provides a mechanism for the specific case of fast handoff and we enumerate the different options for CT under fast handoff scenario. The CT mechanism suggests the use of both the messages as defined in [13] as well as a CT mechanism that uses only the handoff signaling messages. This document also describes how the CT can affect target router selection and it also explains context transfer (re)negotiation issues. Mobility management protocols outside the scope of this specification could consider the ability of an access router to support desired features when selecting a target router. For our purposes, we assume that the IP address of the target router is supplied to the context transfer framework. Furthermore, it is crucial that context transfers are appropriately aligned with the IP layer handover protocols that determine routing changes for packet forwarding to the MN. Failure to do so results in context state quickly becoming inconsistent. To this end the CT mechanism "CAN" use Satish et Al [Page 1] Internet Draft CT Framework supporting Fast Handover Feb 2002 L2 triggers or layer 3 triggers, which are evolving. While this is important, context transfers SHOULD NOT depend upon any particular handover mechanism. This can be achieved by separating context definitions from the handover messages. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" and "silently ignore" in this document are to be interpreted as described in RFC 2119 [2]. We define the following terms for use in this document. We also use Figure 1 as the basis for our handover discussion. GPT Generic Profile Type: a general way to lay out context parameters, which constitute a particular context, for use when describing various feature contexts. ICMP Internet Control Message Protocol IP Access Address An IP address useful for routing packets to a mobile node while it is attached to an access network. New Router The router to which the MN attaches after handover Predictive Same as proactive. Previous Router The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router Satish et Al [Page 2] Internet Draft CT Framework supporting Fast Handover Feb 2002 v +------------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ MN | | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < MN | | +------------+ Figure 1: Reference Scenario for Handover 3. Data Structure There MAY be multiple features associated with each unidirectional packet stream (also known as a microflow). Examples are QoS, security and header compression. In this document we assume that there is a feature context that is specific for each packet stream as defined in [13]. Each feature MAY itself be supported by multiple, co-existing mechanisms. A feature context MAY need to specifically refer to the particular mechanism it realizes. One or more feature contexts MAY belong to a microflow context and multiple microflow contexts together form the overall context for a mobile node. The overall context MAY also include contexts that are not microflow- specific; e.g., it MAY include session-specific contexts (such as AAA state) as well. The context hierarchy, consistent with the nomenclature in [9], is illustrated in Figure 2 (where feature realizations through one or more mechanisms are not shown for clarity). From this hierarchy, it is clear that a representation is needed to capture the diversity of features and feature realizations. It is also clear from Figure 2 that a feature context is the unit of data representation for context transfer purposes. The data representation SHOULD also capture those features that are absolutely important for the smooth functioning of an application and other features or parameters that can be compromised. This helps optimize QoS negotiation operations. Based on the non-negotiable parameters or features the new FA can reject or accept the handover. Negotiable and non-negotiable parameters SHOULD be identified. Given the diversity of various features and their associated Satish et Al [Page 3] Internet Draft CT Framework supporting Fast Handover Feb 2002 contexts, we recognize the need for a simple representation that provides a generic structure, while allowing each feature to define its own context parameters. The Generic Profile Type (GPT) [13] is an object that uniquely identifies the type of a feature context. The GPT also should capture negotiable and non-negotiable parameters or features. +--------------+ | | | Context | | | | | +--------------+ | | +-----------------------------------------+ | | | +------------+ +------------+ +------------+ | | | | | | |Microflow-1 | |Microflow-2 | ... |Microflow-n | | context | | context | | context | | | | | | | +------------+ +------------+ +------------+ | | | +----------+ +----------------+ | | | | | Feature | +----------+ +----------+ |context X | | | | | | | | Feature | | Feature | +----------+ |context Y | |context X | | | | | +----------+ +----------+ | +----------------+ | | +----------+ +----------+ |negotiable| | Non | | context | |negotiable| |parameter | |parameter | | | | | +----------+ +----------+ Figure 2: Context Hierarchy for a Mobile Node One example of a negotiable parameter is buffer requirement in the NFA where as support for multicast can be an absolute requirement. The GPT provides a definition for each feature (and the Associated mechanism that is standardized) a feature context that can Satish et Al [Page 4] Internet Draft CT Framework supporting Fast Handover Feb 2002 be used during handovers. The structure MAY include - Administrative parameters such as ISP, Organization and policy information; Cost of access parameters; Information about radio interface; Information about usage of any application logic such as multicast support, header compression capability, playout buffer hosting in nFA for streaming applications, TCP PEPs and media transcoding functionality etc; Internet connectivity parameters such as need for NAT traversal; This context would have the necessary and sufficient parameters so that the node receiving the context would be able to immediately (seamlessly) offer the feature subsequent to handover. In other words, the context state captured by each instance of GPT would facilitate feature inter-operability across access routers during handovers. Second, a GPT provides a standard programming object that can be used, e.g., to request context transfer for a feature, or to initialize feature support. In other words, this object can be used by a mobile node in appropriate programming API and signals. Standardization effort will be needed for the definition of new GPTs. Each feature context itself, then consists of the [GPT, context parameters] tuple along with some generally useful parameters (such as a filter that identifies the packet stream and a handle that allows indexing into the correct feature context). 4. Context transfer Options with Handover Signaling This section describes a CT mechanism for both the conventional And fast handover mechanisms. There are two types of signaling for context transfer purposes. Context transfer can take place with or without being requested by the New Router. The context transfer could take place before the mobile node even attaches to the New Router or after the mobile node attaches to the new access router. In the former case the desired context could be utilized as soon as the mobile node obtains new IP connectivity and is termed predictive context transfer. The New Router MUST acknowledge this predictive context transfer. In the case when the CT takes place after the mobile node attaches with the new access router, the context transfer takes place as a reaction to explicit signaling from the mobile node. In this case, the New Router explicitly sends a context transfer request to the Previous Router. This scenario can be considered as an extension to the basic handover signaling. This can also be considered as a fallback approach when the fast handover signaling (or the predictive approach) experiences a failure, as explained in the next section. Satish et Al [Page 5] Internet Draft CT Framework supporting Fast Handover Feb 2002 4.1. Basic Handover Signaling: Reactive CT The CT mechanism for the reactive case when the CT happens after the mobile node attaches with the new access router will be the same as that suggested in [13]. After the mobile node formulates a new IPaccess address, it sends a message containing the Seamless Handover Initiate Option (SHIN) as described in [13]. Apart from the messages provided in [13] for reactive CT, we Suggest that an option to convey the context information along with the handoff registration messages SHOULD be provided. The reactive CT options SHOULD also provide for a negotiation mechanism. Negotiation in the case of reactive signaling is important as the nFA might not support the MN context fully and the MN has already moved in. The negotiation can be achieved using existing messages or over the messages described in [13] as shown below. The negotiation is facilitated through the identification of negotiable and non- negotiable features in the GPT. +----------+ 2. SHREQ +----------+ | |<---------| | | | | | | oFA | | nFA | | | | | | |--------->| | +----------+ 3. SHREP +----------+ ^ | 1. SHIN| | | | +-+ +-+ | | movement | | +-+ ---------------> +-+ Figure 3: Context Transfer with Basic Handover Signaling 4.2. Context transfer under Fast Handover Signaling CT under fast handover has been termed as proactive (or predictive) CT in [13]. Within the scope of fast handover, CT can be achieved either "proactively before" the initiation of fast handover or "proactively with" the fast handover signaling or "proactively after" the fast handover signaling has taken place. The scope of proactive CT is always before the actual L2 handover of the mobile node. Satish et Al [Page 6] Internet Draft CT Framework supporting Fast Handover Feb 2002 It is visualized that choice of a new AR for handover itself can be motivated by the support to the context as seen by the mobile node. Under such condition the CT can be visualized within the scope of a candidate access router discovery [14]. Further the CT within the scope of the fast handover can be reactive when the actual CT occurs only after the MN has physically moved to the new access router domain. Under this condition the scope for a CT negotiation is narrow and as such SHOULD be invoked only when the MN or the oFA is "Confident" of the new access router in supporting the CT as required by the MN. In the case of fast handover signaling CT can be combined with pre-registration and post-registration signaling as illustrated in the following figures. +---------+ | HA (GFA)|<---------+ +---------+ | 4. (Reg)RegReq | 5. (Reg)RegReply 1a. RtSol v +-------+ ----------------------> +-------+ | | 1b. RtAdv | | | | <---------------------- | | | | CT Negotiations | | | oFA | ----------------------> | nFA | | | Negotiation Response | | | | <---------------------- | | | | Context Transfer | | +-------+ ----------------------> +-------+ ^ | ^ | | 2b / (2a. ProxyRtSol) | | ProxyRtAdv / 3. (Reg)RegReq | | / | v ------------------------- +-----+ / | MN | - - - - - - - - - -> +-----+ Movement Figure 4: PRE-REGISTRATION Handoff Protocol with Context Transfer Satish et Al [Page 7] Internet Draft CT Framework supporting Fast Handover Feb 2002 1. Handoff Request +-------+ ----------------------> +-------+ | | 2. Handoff Reply | | | | <---------------------- | | | | CT Negotiations | | Source ~~~>| oFA | ----------------------> | nFA | Trigger | | Negotiation Response | | | | <---------------------- | | | | Context Transfer | | +-------+ ----------------------> +-------+ ^ | 3. Reg Request | | 4. Reg Reply | v +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 5: Source Triggered POST-REGISTRATION Handoff with Context Transfer 1. Handoff Request +-------+ <---------------------- +-------+ | | 2. Handoff Reply | | | | ----------------------> | | | | CT Negotiations | | | oFA | ----------------------> | nFA |<~~~~ Target | | Negotiation Response | | Trigger | | <---------------------- | | | | Context Transfer | | +-------+ ----------------------> +-------+ ^ | 3. Reg Request | | 4. Reg Reply | v +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 6: Target Triggered POST-REGISTRATION Handoff with Context Transfer 4.2.1 Proactive before A "proactive before" CT can take place as soon as a CAR [14] discovery has been done and before the fast handover signaling starts. Such a transfer SHOULD be guided by an association with the CAR process or through a proper association with the L2 trigger information for fast handover. The messages described in [13] can be used or the CT can occur on CAR discovery messages. Satish et Al [Page 8] Internet Draft CT Framework supporting Fast Handover Feb 2002 +-------+ +-------+ | | 2. PCT | | | oFA | --------------> | nFA | | | | | +-------+ +-------+ | ^ ^ | | | | | | |1."Trigger" | | | | 3. SHIN| | V V +--+ +--+ | | movement | | +--+ --------------> +--+ Figure 7: "proactive before" Context Transfer using PCT message 4.2.1.1. CT bound to the CAR discovery process Candidate access router (CAR) discovery as defined in [14] Consists of finding Geographically Adjacent AR (GAAR) GAARs have Aps whose coverage areas are geographically adjacent or overlap. The next step is to find a set of Candidate ARs from which a Target AR (TAR) is identified. The process of finding a TAR it self can be biased by the availability or support for the existing context as seen by the MN. CT can be achieved immediately after a TAR identification or during the process of TAR identification when some negotiation is involved. In this case the CT messages can be used with the CAR discovery process providing the triggers for a CT initiation or the CT can be achieved in the process of TAR identification when some form of negotiation may be involved. This case falls within the scope of the ôproactive beforeö case as mentioned above. 4.2.2 Proactive with A "proactive with" CT can take place along with the fast handover signaling either on top of the fast handover signaling or concurrently with the use of messages described in [13]. The CT messages can also be Piggy backed on fast handover signaling in this case. Piggy-backing CT advertisements on L3 fast handoff messaging involves utilizing the L3 messaging. Satish et Al [Page 9] Internet Draft CT Framework supporting Fast Handover Feb 2002 4.2.3 Proactive after This is a case when a CT can be taken up immediately after a fast handover signaling completion but before the actual L2 handoff. Normal scenarios would not permit the use of this case quite often as fast handover itself is bound by tight timing considerations. To support successful "proactive after" CT where in a CT cannot be completed before an L2 handoff, provision SHOULD be provided to complete the CT after the MN moves to the new domain in the MN initiated CT. Such a partial CT can also be supported by the oFA and the nFA where in the MN initiates the CT and the oFA completes the same when it finds out that the CT transfer initiated by the MN has not been completed. In case when a complete CT is not possible the context transfer protocol MAY use a provided mechanism for partial handovers [13]. Such a partial CT mechanism SHOULD be restarted once the MN L2 handover is complete. 5. Timing Requirements for context transfer Timing requirements for the CT under fast handover scenarios are very critical. As mentioned in the previous sections the CT process can go before, along with or after a layer 3 handover. In this document the CT mechanism has been assumed to be either bound to the layer 3 handover mechanism or can be independent of the layer 3 handover mechanism. If the CT is bound to a layer 3 handover mechanism the triggers as specified for the layer 3 handover mechanism could be used. The CT can also be accomplished along with the actual layer 3 handover mechanism. 6. Partial Handover In the case when the CT mechanism is associated with the CAR discovery process and when a Target AR has not yet been identified, subsets of the context profiles can be distributed to multiple ARs. A complete transfer can be affected when the TAR has been identified. 7. Context (re) negotiation Context negotiation can take place with the CAR discovery process itself in the case of ôproactive beforeö context transfer. In other cases the CT messages can be used with the GPT identifying the negotiation clause. In case of a mobile node not getting a satisfactory QoS in the nFA, the MN can renegotiate for a better QoS after some time. The renegotiation can be initiated by the MN or can be initiated by the nFA. The nFA SHOULD maintain a copy of the context as obtained from Satish et Al [Page 10] Internet Draft CT Framework supporting Fast Handover Feb 2002 the MN or the oFA so that it can try and meet these requirements as and when resources become available. It is preferable that a renegotiation mechanism initiated by the nFA is adopted to minimize the number of message transfers over the air in bandwidth limited wireless networks. 8. References [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [4] R. Koodli and Malinen J. Idle Mode Handover Support in IPv6 Networks(work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-idle-mode-ct-00.txt, July 2001. [5] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-fastv6-01.txt, October 2000. [6] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. [7] R Koodli, C.E. Perkins, and M. Tiwari. Context Relocation for Seamless Header Compression in IP Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-hc-relocate-01.txt, July 2001. [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [9] O. Levkowetz and et al. Problem Description: Reasons For Doing Context Transfers Between Nodes in an IP Access Network (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-context-transfer-problem-stat-00.txt, February 2001. Satish et Al [Page 11] Internet Draft CT Framework supporting Fast Handover Feb 2002 [10] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. [11] H. Syed and et al. General Requirements for Context Transfer (work in progress). Internet Draft, Internet Engineering Task Force, March 2001. [12] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. [13] R Koodli, C.E. Perkins. A Context Transfer Framework for Seamless Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-ctv6-02.txt, November 2001. [14] Dirk Trossen et al, Issues in candidate access router discovery for seamless IP-level handoffs, (work in progress). Internet Draft, Internet Engineering Task Force, September 2001. draft-ietf-seamoby-cardiscovery-issues-01.txt 9. Author's Addresses Satish Jamadagni, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Satish D, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3164 Fax: +91 80 5351133 Email: satishd@sasken.com Shiva Raman Pandey, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone: +91 80 5355501 Ext:3296 Fax: +91 80 5351133 Email: shiva@sasken.com Satish et Al [Page 12]