SeaMoby Working Group Hamid Syed Internet Draft Gary Kenward Document: draft-hamid-seamoby-ct-fwk-00.txt Nortel Networks June 4, 2001 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 [1]. 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 The distribution of this memo is unlimited. This memo is filed as , and expires November 2001. Please send comments to the authors. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes a framework for context transfer between the access routers. The framework identifies the various functional elements that participate in the process of context transfer and the protocols required to exchange information between the functional entities. Included are a few samples of context transfer scenarios to assist in explaining the interactions of the entities in the framework. 1 Introduction In networks where hosts are mobile, the success of real-time sensitive services like VoIP telephony, video, etc. depends heavily on the ability of the network to support handover of the MN's traffic from one access router to the other as the MN moves with minimum or no service disruption. The ability of a new access router to support the same service quality after handoff is determined by the router's built-in capabilities, by the availability of the Syed Expires November 2001 [Page 1] Internet Draft Context transfer Framework necessary router resources, by the availability of unused bandwidth on the links that the traffic must traverse to and from the router, and, by the timely available of the service support context at the router. The support context referred to here is comprised of the information necessary to support the all the committed service features, such as AAA, header compression, Differentiated Services, Integrated Services, policy enforcement, etc. Each context is initially established when the corresponding service is set-up between the mobile node and the network, and changes over time as the components supporting the service features change state. In order for this context to be available at a new access router after handoff, it must be replicated from the access router currently supporting the MN's traffic. The replicated context must represent the most recent support state. The general requirements for a framework for context transfer are captured in [3]. This document proposes a framework for context transfer between the access routers. The framework identifies the various functional elements that participate in the process of context transfer and the protocols required to exchange information between the functional entities. 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 for the most part taken from [3]. This section defines few additional terms that are used in this document to explain the context transfer framework. - Context Group (CG): A logical grouping of access routers. The context group is comprised of the AR currently supporting a given MN's microflows, and those ARs maintaining an updated replica of the context associated with the MN's active microflows. These latter members may never be required to forward the MN's microflows. - Context Transfer Source (CTS): is an AR that is actively supporting one or more active microflows of a MN. It transfers the context of the microflows it is supporting to one or more context group candidates. - Context Group Candidate (CGC): is an AR that receives a notification of a MN arriving in its communication area. The AR thus becomes a candidate for transfer of the context associated with the MN's active microflows. - Configuration Context: represents the part of the over all context information (for each of the sub-context associated with the MN's active sessions) that remains unchanged throughout the life of the session. Examples of such information could be the bandwidth requirements for each session between the MN and the Access Network, the QoS parameters such as the DSCP and user authentication information that is determined for the MN at the time of its attachment to the network. Syed Expires November 2001 [Page 2] Internet Draft Context transfer Framework - State Context: represents the part of the over all context (for each active microflow) that is updated on each packet arrival. Examples of such information include the metering and header compression states. 4 Requirements for context Transfer framework The proposed framework covers three functional areas: - context group management mechanism - distributed context transfer approach - context transfer protocol The requirements that lead to a distributed approach to context transfer and the context transfer protocol are captured in [3]. The following sub-section presents a discussion of the requirements for the context group management mechanism. 4.1 Additional Requirements for Context Group Management Performing context transfer proactively provides for the preparation of the ARs in anticipation of a context transfer. The notion of a context group is introduced in support of the proactive context transfer. Each member of the context group maintains an updated replica of the context associated with the MN's traffic. In a reactive context transfer mode, the source of the context changes and this information needs to be propagated to the group members. Moreover, forming of a context group, the addition of ARs that become candidates for a possible handoff, and the removal of ARs that are no longer candidates require a management mechanism. Context group management is a dynamic process, with some requirements, as described below. 4.1.1 The context group management mechanism MUST define the events for inclusion and removal of the ARs from the context group. 4.1.2 The context group management mechanism MUST support collection and distribution of the AR's group membership information. 4.1.3 The context group management mechanism MUST define how to Identify the context source AR for the newly joined AR. 5 Framework Discussion This section provides the details of a framework to replicate the context associated with a MN's traffic flows to one or more receiving ARs. The proposed framework identifies the functional entities participating in the context transfer and describes the role of each functional entity. The context transfer framework includes definition of one key network event and two protocols. 5.1 Functional Elements of the Framework The major functional elements of the context transfer framework are the context transfer agent (CTA), and the membership collection and distribution function (MCDF). Figure 1 shows a simple configuration involving these two functional elements and the protocols required. Syed Expires November 2001 [Page 3] Internet Draft Context transfer Framework +--------+ | | +-------------->| MCDF |<------------+ | | | | | +--------+ | | | |MDP MDP | | | | | | | | | +----|----+ +----|----+ | v | | v | | +----+ | CTP | +----+ | | |CTA |<------------------------------>| CTA| | | +----+ | | +----+ | | | | | | AR | | AR | +---------+ +---------+ Figure 1: The CT framework entities and the protocols 5.1.1 Context Transfer Agent (CTA) The context transfer agent (CTA) is the functional entity that actively participates in the process of context transfer. Residing at the peers of the context transfer, the CTA is responsible for collection of all of the information required to support the active microflow associated with the MN to create the overall context that needs to be transferred. The CTA stores this context information in a form required by the context transfer protocol to carry between the peers of the context transfer. The CTA also communicates with the membership collection and distribution function (MCDF) assisting MCDF in context group management. The CTA exchanges the membership information with MCDF through a standardized membership distribution protocol (MDP). The CTA residing at the receiver of the context information distributes the received information to the relevant entities for processing. The first operation to be invoked at the receiver on reception of context is the admission control. The CTA may help in intelligent handover decision making by relaying the outcome of the admission control decision to the handover decision point (c.f section 6). 5.1.2 Membership Collection and Distribution Function (MCDF) The membership collection and distribution function (MCDF) is a functional entity that administers the formation of context groups. It creates and maintains one context group per active MN. The MCDF also collects the identification of the ARs that are supporting the active microflows of the MN and stores them as potential sources of the context for the MN. When an AR receives the notification of the MN's arrival in its communication area (thus becomes a context group candidate), it communicates with the MCDF (through MDP) to get the information of the source of the context (CTS) for the MN. Syed Expires November 2001 [Page 4] Internet Draft Context transfer Framework The MCDF function MAY be mapped to a single physical entity in the network or may be distributed throughout the network. If the MCDF is distributed, a standardized protocol MUST be defined to support the distribution and coordination of the membership information. Definition of this protocol is outside the scope of this document. 5.2 Protocols/Events The context transfer framework includes the definition of one key network event and two protocols. 5.2.1 Mobile Arrival/Departure Event (MADE) The MADE is a notification delivered to an AR when the MN enters or leaves its communication area. The requirements for such an event definition have been captured in [3]. The arrival or departure event enables the AR to join or leave a context group. The AR reacts to the arrival event by initiating a communication with the MCDF (as the context group candidate) for the identification of the source of the context. Similarly, a departure event initiates the removal of the AR from the context group associated with the MN. 5.2.2 Membership Distribution Protocol (MDP) The membership distribution protocol (MDP) enables the MCDF to effectively manage the context groups. It exchanges the context group membership with the CTA. The MDP carries the following information: - identification of the mobile node - context group information - identification of the AR (or ARs) that is to act as the source of the context transfer (CTS) 5.2.3 Context Transfer Protocol (CTP) The context transfer protocol (CTP) provides mechanisms to transfer context information for a MN's traffic from the source (CTS) to the receiver, the CGC. The requirements for such a protocol are captured in [3]. 6 Interworking with the Mobility Framework The goal of reducing the effect of mobility on the service level received by the MN through context transfer cannot be achieved without providing a close interworking between the context transfer process and any mechanism that is responsible for the actual traffic re-direction from one AR to the other. For this reason, discussion of an interface between the context transfer and the mobility framework would help clarifying the interaction between the two frameworks. The context transfer framework discusses the roles of one functional entity in the mobility framework and an interface with the mobility framework. This entity in the mobility framework Syed Expires November 2001 [Page 5] Internet Draft Context transfer Framework may have different names for different mobility mechanisms. The context transfer framework, however, is a generic framework that should interwork with any mobility mechanism. 6.1 HandOver Decision Point (HODP) The HandOver Decision Point (HODP) represents the functional capability that is provided by the mobility framework. For a given mobility solution, it will likely have a different name and may be effected by a collection of network elements. The HODP is the entity that determines which of the ARs would be the best candidates for supporting an imminent handoff of a MN's traffic. This determination should be based upon the admission control status provided by the CTA associated with each AR in the context group. Since the HODP is a functional element that deals primarily with the Handoff of micro-flows, it is not a part of the context transfer framework, per se. However, it is a primary collaborator in context transfer, and it is required to describe how the various context transfer scenarios would transpire. 6.2 CTA-HODP Interface A few transactions between the CTA and the HODP functions are necessary to discover a suitable handover candidate for the MN's traffic. This requires an interface definition between the two entities. The entity HODP can be co-located with the CTA in which case the CTA-HODP interface could have different implementations. However, if the HODP is an entity that is not located in the same physical entity as the CTA then the CTA-HODP interface would require the standardized handover candidate discovery protocol. Since HODP is an entity outside context transfer (lies within the mobility framework), the details of this interface are outside the scope of this document. 7 Additional Features Supported by the Framework 7.1 Progressive Context Transfer The proactive context transfer allows the transfer of the context for the MN to the context group members before an actual handover is required. During the time period from when the context is transferred proactively and the actual handover of the MN's microflows to any of the context group members occurs, the context at the context transfer source (CTS) may get changed. These changes may include the addition or deletion of one or more microflows from the MN. The context information for the MN is composed of the configuration and state components (see section 3). The intent of the proactive transfer is to prepare the potential context group candidates by replicating the information required to perform an admission control at each of the candidates. The state component, information that is updated on each packet arrival at the source, plays no role in the admission decision. By separating the context into configuration and state components, context transfer can be performed in a progressive way. For a proactive context transfer mode, the information required to perform Syed Expires November 2001 [Page 6] Internet Draft Context transfer Framework the admission decision (i.e. the configuration components) should be transferred proactively. Moreover, since this information changes infrequently, it should be kept synchronized between the CTS and the rest of the context group members. The events to trigger an update from the CTS to the rest of the context group members are simply the addition and deletion of microflows to the overall context associated with the MN's traffic at the CTS. The second stage of the context transfer, updating the state components, should be coupled with the actual handover. The context transfer here carries the information that is updated on each packet arrival and is now required at the new AR supporting the MN's traffic. This is effectively a one-to-one transfer, as only the new serving AR requires this information. 7.2 Demand and Reservation states in the proactive context transfer The proactive transfer of configuration context and the outcome of the admission control on this context determines the level of support for the MN's traffic if the MN's traffic is re-directed to the AR. Since the transfer of the context to an AR and actual handover of the traffic to the AR may not happen at the same time, the resource availability at the AR may not be the same as it was reported after the admission control process on transferred context. The framework provides concepts by which the mobility mechanism can make effective use of the admission control information and the reported status of the resource availability. This is accomplished by allowing the mobility mechanism to put the AR into one of the two states in terms of resources: the demand and the reservation states. In the demand state, the AR has essentially acknowledged that it has the capability to support the MN's traffic, but no attempt is made to reserve resources. Thus, when the handover is finally attempted, the necessary resources may not be available and the handover to the AR may fail partially or completely. This option minimizes resource use, and requires some level of over-provisioning to ensure an acceptably low level of failed handovers. This could be used for the services that may not require immediate resource availability. Examples could be http sessions etc. In the reservation state, an AR not only acknowledges that it has the capability to support the MN's traffic, it also reserves the necessary resources. In this case, when the handover is finally attempted, it should succeed. This option minimizes handover failures, at the expense of having resources allocated for potential handovers that may never occur. This could be useful for services that cannot tolerate disruptions like VoIP etc. The reservation mode guarantees the availability of resources for such services immediately after the handover. 8 Example Scenarios based on the context transfer framework This section provides some scenarios to explain the interworking of the various functional entities and the corresponding protocols of the framework. Some mnemonics are used for the sake of brevity: - MN54 is a moving mobile node in the access network. Initially, MN54 does not have any active microflows through any of the access routers but is within the coverage area of AR1. - AR1 is an access router in the network and CTA1 is the context transfer agent at the AR1. Syed Expires November 2001 [Page 7] Internet Draft Context transfer Framework - AR7 is another access router in the same access network and CTA7 is the context transfer agent at AR7. At some point in time, AR7 receives a MADE notification of the presence of the MN54 in its coverage area due to the MN's mobility. - MCDF is the membership collection and distribution function. - HODP is an entity within the mobility framework that interacts with the CTA within context transfer framework. 8.1 Context Group Management Scenarios The addition and deletion of ARs to the context group, tracking the source(s) of the context group associated with each active MN in the network requires a context group management mechanism in place. This mechanism also distributes the identity of the context source to the CGCs, which helps the CGCs initiating a context transfer to send a request directly to the source of the context. The following scenarios explain CG management in the context transfer framework. 8.1.1 Joining the CG 1. AR1 receives a mobile arrival notification (MADE) for MN54. AR1 now becomes the context group candidate for MN54's context; 2. CTA1 informs the MCDF that AR1 is the CGC for MN54's context group, using MDP; 3. Assuming that MCDF does not have any existing CG information for MN54, it informs CTA1 that no context transfer source is available, using MDP; 8.1.2 Context and Context Group Creation 4. MN54 establishes one or more microflows through AR1; 5. CTA1 collects and stores the context associated with MN54's active microflows; 6. CTA1 informs the MCDF that it is supporting the active microflows for MN54 (and thus becomes the source of the MN54's context),using MDP; 7. MCDF creates a context group 'CG54' for the MN54's context with AR1 as the context transfer source (CTS); 8.1.3 Membership Distribution 8. AR7 receives a mobile arrival notification (MADE) for MN54. AR7 now becomes a context group candidate for MN54's context; 9. CTA7 informs the MCDF that AR7 is a CGC for MN54's context group, using MDP; OR MCDF receives a request from CTA7 for joining the CG associated with MN54, using MDP; 10. The MCDF informs CTA7 with the following information, using MDP; - list of sources (CTS IDs) for the MN's microflows (only CTA1 in this case) - context group information such as context group identification 8.1.4 Updating the MCDF as the source for a CG changes 11. AR7 receives a change of forwarding path for MN54's traffic from HODP; Syed Expires November 2001 [Page 8] Internet Draft Context transfer Framework 12. Being the new source for MN54's context, CTA7 informs the MCDF that it is supporting the active microflows for MN54, using MDP; 13. CTA1 informs the MCDF that it is no longer the source of the context for MN54's traffic, using MDP; - If CTA1 still supports one or more microflows associated with the MN54's traffic, it will continue as one of the sources for the context within the CG associated with MN54; 8.1.5 Leaving the context group 14. AR1 determines that the MN54 is leaving its communication area through a mobile departure event (MADE); 15. Since AR1 is not the source of the context within the context group but just a context group member (replicating the context), it will only have to inform the source of the context to discontinue any updates. No update to the MCDF is required in this case. The Figure 2 below combines the context group management (CGM) scenarios in a single message flow diagram. +------+ +------+ +------+ | CTA1 | | CTA7 | | MCDF | +------+ +------+ +------+ | | | |---+ | | | |(1) | | |<--+ | (2) | |------------------------|------------------------->| | (3) | | |<-----------------------|--------------------------| | | | |---+ | | | |(4) & (5) | | |<--+ | | | | (6) | |------------------------|------------------------->| | | +------+ | | | (7) | | | +------+ | | | | |---+ | | | | (8) | | |<--+ (9) | | |------------------------->| | | (10) | | |<-------------------------| | | | | |---+ | | | | (11) | | |<--+ | | | (12) | | |------------------------->| | | (13) | |------------------------|------------------------->| Syed Expires November 2001 [Page 9] Internet Draft Context transfer Framework | | +------+ | | | (14) | | | +------+ |---+ | | | |(15) | | |<--+ | | Figure 2: Message Flow Diagram for the CGM Scenarios 8.2 Context Transfer Scenarios The context transfer is initiated from the CGC to the CTS when the newly joined context group member has already retrieved the CTS information through the context group management mechanism. - CTA1 is supporting the MN54's microflows and hence is the CTS within the CG for MN54. - CTA7 is a CGC and has already retrieved the CTS information from the MCDF. 8.2.1 Proactive Context Transfer Mode 8.2.1.1 Configuration Context Transfer 1. CTA7 sends a context transfer request to CTA1 for MN54's configuration context, using CTP; 2. CTA1 transfers the configuration context for MN54, using CTP; 8.2.1.2 Context Processing and Interworking with Mobility Mechanism 3. CTA7 processes the configuration context and determines the available support for MN54's traffic; 4. CTA7 informs the HODP about the available support for the MN54's traffic, using the CTA-HODP interface; - if CTA7 is unable to admit MN54's traffic, it may opt to remain as a CGC and continue receiving the context updates from the source, using CTP; - OR CTA7 may choose to leave the context group, using MDP; (in this case it will no longer be the CGC and will not receive any context updates for MN54). 5. The HODP determines demand and reservation states for the MN54's microflows. It may choose all the microflows for either demand or reservation states OR it may select some microflows under demand state and others in reservation state. 8.2.1.2.1 Demand state 6. In demand mode, the HODP only acknowledges the CTA7's response, using the CTA-HODP interface. The CTA7, in this case, makes no attempt to reserve the resources for MN54's traffic; 8.2.1.2.2 Reservation State 7. In reservation mode, HODP requests CTA7 to reserve the resources to support MN's microflows, using the CTA-HODP interface; 8. CTA7 reserves the resources and sends the confirmation to the HODP, using the CTA-HODP interface; Syed Expires November 2001 [Page 10] Internet Draft Context transfer Framework 8.2.1.3 Configuration Context Update 9. MN54 initiates a new microflow through CTA1 at some time while handover of the MN54's traffic has not yet performed to any of the context group members. The new microflow is added to the MN's context at the CTA1; 10. CTA1 sends an update on the configuration context of the new microflow to the context group members (only CTA7 in this case), using CTP; 8.2.1.4 State Context Transfer 11. CTA7 receives a handover notification for MN54's traffic from the HODP. 12. CTA7 initiates a state context transfer request to the CTA1, using CTP; 13. CTA1 transfers the state context associated with the MN54's traffic to the CTA7, using CTP; 14. For demand state microflows, the CTA7 processes the current configuration context and determines the available support for MN54's microflows in demand state. 15. CTA7 informs the HODP about the available support for the MN54's traffic in demand state, using the CTA-HODP interface; 16. For a complete support available at the CTA7, the HODP acknowledges the information, using the CTA-HODP interface - For a scenario where partial or no support was available at the CTA7 or CGC, the HODP must take necessary actions to redirect the MN54's traffic to a suitable handover candidate. Since HODP belongs to mobility mechanism, the discussion of partial or complete failure of the admission control is out of the scope of this document. Figure 3 below shows the message flow between the functional entities in a proactive mode context transfer +------+ +------+ +------+ | CTA1 | | CTA7 | | HODP | +------+ +------+ +------+ | (1) | | |<-----------------------| | | | | | (2) | | |----------------------->| | | | | |---+ | | | |(3) | | |<--+ | | | | (4) | | |------------------------->| | | | | | +------+ | | | (5) | | | +------+ | | | | | (6) | | |<-------------------------| Syed Expires November 2001 [Page 11] Internet Draft Context transfer Framework | | (7) | | |<-------------------------| | | | | | (8) | | |------------------------->| |---+ | | | |(9) | | |---+ | | | (10) | | |----------------------->| | | | (11) | | |<-------------------------| | (12) | | |<-----------------------| | | | | |----------------------->| | | (13) |---+ | | | |(14) | | |<--+ | | | (15) | | |------------------------->| | | (16) | | |<-------------------------| Figure 3: Context Transfer (Proactive Mode) 8.2.2 Reactive Context Transfer Mode 1. The CTA7 receives a trigger for reactive context transfer. The trigger for reactive context transfer should be different from the proactive context. 2. The CTA7 retrieves the CTS information from the MCDF using the context group management mechanism; 3. The CTA7 initiates a context transfer request to the CTA1, using CTP. The context transfer request in a reactive context transfer indicates the transfer of both configuration and state context; 4. CTA1 transfers the complete context associated with the MN54's traffic to the CTA7, using CTP; 5. CTA7 processes the configuration context and determines the available support for MN54's traffic; 6. CTA7 informs the HODP about the available support for the MN54's traffic, using the CTA-HODP interface; 7. For a complete support available at the CTA7, the HODP acknowledges the information, using the CTA-HODP interface - For a scenario where partial or no support was available at the CTA7 or CGC, the HODP must take necessary actions to redirect the MN54's traffic to a suitable handover candidate. Since HODP belongs to mobility mechanism, the discussion of partial or complete failure of the admission control is out of the scope of this document. The figure 4 below shows the interactions in the reactive context transfer mode. Syed Expires November 2001 [Page 12] Internet Draft Context transfer Framework +------+ +------+ +------+ | CTA1 | | CTA7 | | HODP | +------+ +------+ +------+ | | | | | | | |---+ | | | |(1) | | |<--+ | | | | | |---+ | | | |(2) | | |<--+ | | (3) | | |<-----------------------| | | (4) | | |----------------------->| | | |---+ | | | |(5) | | |<--+ | | | (6) | | |------------------------->| | | (7) | | |<-------------------------| Figure 4: Context Transfer (Reactive Mode) 9 Recommendations for Future Work The general requirements for the context transfer framework are captured in [3]. This draft proposes the context transfer framework that identifies the major functional entities, their roles, and the supporting protocols. The next step in this work is the definition of the context transfer protocol (CTP) and the Membership Distribution Protocol (MDP). It would also be useful to define the characteristics of the Mobile Arrival-Departure Event (MADE), the requirements for the HandOver Decision Point (HODP) and the CTA-HODP interface (required for the handover candidate discovery). 10 Intellectual Property Rights Considerations This is to inform you that Nortel Networks has applied for and/or has patent(s) that relates to some of the concepts used in this document. See http://www.ietf.org/ietf/IPR/NORTEL-GENERAL. This submission is being made pursuant to the provisions of IETF IPR Policy, RFC 2026, Sections 10.3.1 and 10.3.2. 11 References [1] S. Bradner, "keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. Syed Expires November 2001 [Page 13] Internet Draft Context transfer Framework [2] The seamoby CT design team, "Context transfer: problem statement", draft-ietf-seamoby-context-transfer-problem- stat-00.txt. [3] The seamoby CT design team, " General requirements for a context transfer framework", May 2001 (work in progress). draft-ietf- seamoby-ct-req.00.txt. 12 Acknowledgments We would like to thank the following for their useful input: Bill Gage, Louis Hamer. 13 Author's Address Syed, Hamid 100-Constellation Crescent Nepean, Ontario. K2G 6J8 Phone: 1-613-763-6553 Canada Email: hmsyed@nortelnetworks.com Kenward, Gary 100-Constellation Crescent Nepean, Ontario. K2G 6J8 Phone: 1-613-765-1437 Canada Email: gkenward@nortelnetworks.com 14 Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 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 organisations, 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 Expires November 2001 [Page 14] Internet Draft Context transfer Framework