Internet Engineering Task Force Hamid Syed Internet Draft Gary Kenward draft-hamid-seamoby-ct-reqs-00.txt Nortel Networks Expires: September 2001 March, 2001 General Requirements for a Context Transfer Framework 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document attempts to capture a set of general requirements for a context transfer framework to replicate and synchronize the context associated with a mobile node's traffic (as it moves) from one access router to any potential candidate access router(s). 1 Introduction In an IP network that supports mobile nodes, it is preferred that the service provided to the user be maintained. This means that the user experiences no perceptible degradation in service capability or service quality, as the mobile node is moved between points of attachment to the network. In order to provide both service capability and service quality, the routing/switching elements of the IP access network must establish and maintain configuration and state information in support of the traffic to and from the mobile. This information is referred to as the "context" associated with a Syed, Kenward Expires September, 2001 [Page 1] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 mobile's traffic. Context may include features like authentication, authorization and accounting state, security state, header compression state, quality of service state, multicast group membership state, buffer state, etc [2]. The context associated with the mobile node's active micro-flows needs to be transferred or replicated between the access routers to enable the seamless handover of the micro-flows. This document attempts to capture a set of general requirements for a context transfer framework to replicate and synchronize the context associated with a mobile node's traffic (as it moves) from one access router to a group of potential candidate access routers. The requirement analysis in this document considers the reference architecture described in [2] as a baseline. 2 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]. 3 Terminology The terminology and the definitions used in the document are mostly taken from [2]. The few additional terms used in this document are defined as follows; 3.1 Coverage Area (CA) The coverage area for an AR can be defined in terms of the access points (APs) that the AR may serve due to network topology or configuration. An access router may have one or more APs in its coverage area. 3.2 Forwarding Path Handover Scenarios 3.2.1 Make-before-break This is a term used for handover cases where the new access router can see the actual micro-flows from the MN and enough time is made available before the MN breaks its attachment from the current access router. In such cases, the forwarding path for the packets of an IP micro-flow changes gradually and the new access router establishes the forwarding support in parallel with the active access router. In essence, separate forwarding paths are created for the IP micro-flow and subsequent packets are forwarded either by the current or the new AR or by both of them. The later situation is possible when copies of packet are forwarded to both the ARs. Syed, Kenward Expires September, 2001 [Page 2] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 3.2.2 Break-before-make In this scenario, the MN detaches itself from the current access router before it finds a new access router for its flows. In this situation, the forwarding path of an IP micro-flow changes abruptly: the active access router (current point of attachment for mobile node) stops supporting the micro-flow before any new AR has established the forwarding support. 3.3 Context Transfer Scenarios 3.3.1 Proactive Context Transfer The context information required to completely support an IP micro- flow is replicated to the access router(s), that detect the presence of MN in its coverage area, in advance of the first packet arrival to one or any of the ARs. A proactive context transfer can be performed in each of the handover scenarios described above. 3.3.2 Reactive Context Transfer The context information required to completely supporting an IP micro-flow is replicated to the access router at the instant when a packet from that micro-flow arrives at the new access router. The reactive context transfer is applicable to make-before-break as well as to break-before-make forwarding scenario. 4 General Requirements for a Context Transfer Framework In this section, we attempt to capture the general requirements for the transfer of context to help seamless handover of MN's traffic. The general requirements can be categorized in to two functional areas - Generic architectural approach - Context transfer protocol 4.1 Generic Architectural Approach A MN may have connectivity through more than one access points (AP) at any time. The determination of which APs are communicating with the MN is dependent entirely on the link characteristics and the layer 2 protocol and services. If the APs that can detect the arrival of the MN in the coverage area are connected to the same AR for IP connectivity, no context transfer is required. However, if the APs in contact with the MN are connected to two or more ARs, then the MN may choose to have its bearer connectivity through any of the ARs. In this situation, the ARs that detect a new arrival of a MN in their coverage area, become candidates for forwarding the MNs traffic. To prepare for a seamless handover, all of these ARs must be prepared to support the traffic by a replication of the context associated with the active micro-flow(s) of the MN. - The framework MUST support one-to-many context transfer Syed, Kenward Expires September, 2001 [Page 3] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 The access router requires an event when a mobile node is found in its coverage area. This event will trigger a notification to layer 3 of any arrival/departure of a mobile node to/from the coverage area of the AR. - The framework MUST consider defining the characteristics of the mobile arrival or departure notification or event to the access router - The mobile arrival/departure event MUST be independent of the layer 2 mechanism A seamless handover of the MN's micro-flows could be supported by performing an advance replication of the context associated with the MN to one or more access routers before the actual micro-flow(s) are re-directed to either of the access routers. - The framework MUST support proactive context transfer The vagaries of layer 2 handoff mechanism ensure that a proactive transfer may not always be possible and there may be cases where conditions do not allow to transfer the context before the actual traffic starts to flow through the access router - The framework SHOULD support reactive context transfer There could be various possible alternatives for context transfer in terms of the network entities that may participate in the context transfer process. Some of the approaches are captured in [2] with the pros and cons of each. The main distinction being a single entity driving the context transfer (e.g. MN driven, a central repository or any functional entity in the network) versus a distributed approach where the access routers control and perform the context transfer between each other. Any single or central entity approach may face severe scalability problems as the number MNs or the number of handovers increases. Moreover, the most updated context information (specially the operational context information) could only be available at the access router(s). - The framework MUST support a distributed transfer approach in which the access routers perform the actual transfer of context. The actual context associated with a MN's active micro-flow(s) reflects the service treatment parameters that were agreed upon between the requesting application and the network. Various protocols participate in setting up, for example, a QoS session and some or all of them may require to maintain a state for that session. A few examples of the context types are captured in [2]. Looking at the types of the context, it is quite possible that more than one physical or functional network entity may be involved maintaining pieces of the context due to the interaction of Syed, Kenward Expires September, 2001 [Page 4] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 different protocols with different network entities. A real-time distributed context transfer approach requires that only one functional entity is responsible for collection and transfer of the context between the access routers. - The framework MAY consider the definition of a mechanism for collection of context to a single functional entity residing at the access router. - The framework MUST define a single mechanism to transfer various types of context. 4.2 Context Transfer Protocol The context transfer protocol is the mechanism to transport the context information from the source of context information to any new access router identified as potential candidate for the context. The process will end up with a replication of the context information from the source access router to the candidate access router. There could be a number of requirements for such a protocol: - The protocol MUST be reliable. This means a 100% reliable transfer of information to the intended destination(s) with zero loss, no duplication, no mis-ordering of the information. - Considering a scenario of reactive context transfer, the protocol MUST be fast enough to transfer the context information in a time frame so that the transferred still remains meaningful at the candidate access router. The context available at the any of the potential candidates at any given time may not reflect the real-time changes occurred to the conetxt since the last transfer/update. Example of such changes may include addition of any new micro-flow(s) or deletion of the existing micro-flow(s). - The protocol MUST provide a synchronization mechanism to keep the context updated within the potential candidates of the context. The update include any micro-flow(s) added or deleted since the last update. The context information contains pieces of the information which is calculated or updated on a per packet basis. Such an information is defined as real-time or operational context in [2]. It is important to consider the synchronization of real-time information within the access routers. However, there could be certain tradeoffs in considering the synchronization of real-time information. For example, in a proactive context transfer scenario, the transferred real-time information may become irrelevant or obsolete at the new access router. This is because the instant of time it was last updated and Syed, Kenward Expires September, 2001 [Page 5] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 the time when the access router receives the first packet of the actual micro-flow(s) (to which the information belongs) could be large enough and the information may not represent the latest update occurred for the micro-flow(s). Even for a reactive transfer mode, by the time the information is transferred to the new access router, it may become obsolete or irrelevant. - The update SHOULD include the synchronization of the real-time or operational context information (see [2] for definition of real-time context) The amount of signaling required initiating a context transfer will add to the delay in the actual transfer. The protocols like TCP [4] and COPS [5] requires initial handshake mechanism between the entities involved. - The context transfer protocol SHOULD NOT introduce extra signaling overhead to initiate the actual transfer. The total time taken to replicate context to the candidates of the context depends mainly on the number of protocol exchange to complete a context transfer. In a reactive context transfer scenario, this time becomes crucial as the context transfer must complete in a minimum time to keep service disruption to a minimum. - The transfer SHOULD complete with minimum number of protocol exchange between the source and the candidate (access routers) of the context data. - The protocol SHOULD have minimum complexity in terms of buffering or re-ordering mechanism - The protocol MUST sustain the security of data transfer. The intent of the pro-active context transfer is mainly to allow the context candidates to process the information against their capabilities and determine whether the current set of capabilities can afford to "admit" the MN's traffic. If any of the potential candidates of the context cannot admit one or more micro-flow(s), the context transfer to that access router has obviously failed. In a heterogeneous network, it is very likely that one or more of the context receiving access routers will not be able to support the whole context associated with the MN's traffic due to different set of available capabilities. However, a seamless handover of the mobile node's active sessions require an intelligent decision to be made at the access router about selecting one access router within the potential candidates. A feedback of the admission control result from each context candidate to an entity responsible for the making a handover decision could support a seamless handover process. Syed, Kenward Expires September, 2001 [Page 6] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 - The context transfer protocol MUST support a feedback mechanism of the admission decision result on each transfer for an intelligent handover decision to be made - The context transfer protocol MUST define interface with the micro-mobility mechanism [3]. In a situation where a single access router is not available to support the whole context associated with a MN's traffic, a mechanism could be required to negotiate the handover of the active sessions to more than one new access router. - The context transfer protocol MAY provide a negotiation mechanism to deal with the failed admission 5. References [1] S. Bradner, "keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. [2] The seamoby CT design team, "Context transfer: problem statement", draft-ietf-seamoby-context-transfer-problem-stat-00.txt, Feb 2001. [3] The seamoby MM design team, "Micro-mobility: problem statement", draft-ietf-seamoby-mm-problem-00.txt, Feb 2001. [4] "Transmission Control Protocol", RFC 793, September 1981. [5] D.Durham et. al, "The COPS (Common open Policy Services) protocol", RFC2748, January 2000. 6. Acknowledgments The contents of this draft are a result of the discussions within the Nortel Networks Advanced Wireless Network Technology Lab and we would like to thank all the members who contributed in the discussions 7. Author's Address Hamid Mahmmod Syed 100-Constellation Crescent Nepean, Ontario. K2G 6J8 Phone: 1-613-763-6553 Canada Email: hmsyed@nortelnetworks.com Gary Kenward 100-Constellation Crescent Nepean, Ontario. K2G 6J8 Phone: 1-613-765-1437 Canada Email: gkenward@nortelnetworks.com 8. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Syed, Kenward Expires September, 2001 [Page 7] draft-hamid-seamoby-ct-reqs-00.txt March, 2001 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 PURPOSE. Syed, Kenward Expires September, 2001 [Page 8] draft-hamid-seamoby-ct-framewk-reqs-00.txt March, 2001