Internet Engineering Task Force Hamid Syed Internet Draft Gary Kenward draft-ietf-seamoby-ct-reqs-00.txt Nortel Networks Expires: November 2001 Pat Calhoun SUN Microsystems, Inc Madjid Nakhjiri Motorola Rajeev Koodli Nokia Kulwinder Atwal Zucotto Wireless Mark Smith COM DEV Wireless Govind Krishnamurthi Nokia May, 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 The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily on the ability to minimize the impact of the traffic redirection during a change of packet forwarding path. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The transfer of context information may be advantageous in minimizing the impact of host mobility on IP services. This document captures the set of requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. 1 Introduction There are a large number of IP access networks that support mobile hosts. For example, wireless Personal Area Networks (PANs), wireless LANs, satellite WANs and cellular WANs. The nature of this mobility is such that the communication path to the host may change frequently and rapidly. In networks where the hosts are mobile, the forwarding path through the access network must often be redirected in order to deliver the host's IP traffic to the new point of access. The success of time sensitive services like VoIP telephony, video, etc., in a mobile environment depends heavily upon the ability to minimize the impact of this traffic redirection. In the process of establishing the new forwarding path, the nodes along the new path must be prepared to provide similar forwarding treatment to the IP packets. The information required to support a specific forwarding treatment provided to an IP flow is part of the context for that flow. To minimize the impact of a path change on an IP flow, the context must be replicated from the forwarding nodes along the existing path to the forwarding nodes along the new path. The transfer of context information may be advantageous in minimizing the impact of host mobility on, for example, AAA, header compression, QoS, Policy, and possibly sub-IP protocols and services such as PPP. An analysis of the context transfer problem is captured in [2]. This document captures the requirements for a context transfer framework and the requirements for a generic context transfer protocol to carry the context between the context transfer peers. 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 Most of the terms used in this document are defined in [2]. Access Router (AR) An IP router residing in an Access Network and connected to one or more points of access. An AR offers connectivity to MNs. 4 General Requirements This section addresses the facilities and services required in the access network to properly support context transfer. The context transfer solution will have to assume certain characteristics of the access network and the mobility solution, and the availability of certain triggering events, transport options, and so forth. These support capabilities are not necessarily part of context transfer, per se, but are needed for context transfer to operate as defined and effect the expected enhancements to MN traffic handover. For convenience, this collection of support capabilities are referred to as the "context transfer framework". 4.1 The context transfer framework MUST define the characteristics of the IP level trigger mechanisms that initiate the transfer of context. 4.2 The IP level trigger mechanisms for context transfer MUST hide the specifics of the layer 2 trigger mechanisms. Handover at the IP level is a consequence of a change in the physical path used to communicate between the MN and the access network. The mechanisms utilized to change the communications path at layer 2 are specific to the physical characteristics of the medium, and often specific to the layer 2 transmission technology being used (e.g. TIA IS 2000, ETSI UMTS R4, IEEE 802.11). In order for any action to be taken at the IP level to maintain IP sessions during a layer 2 path change, some indication of the path change must be made available to the IP level. One example of an indicator would be the trigger event that initiates context transfer. Since it is expected that IP handover, and thus context transfer will work irrespective of the layer 2 technology, the IP level solutions must not utilize specific layer 2 information. The conditions and events that caused the generation of an IP level trigger must be opaque to the IP level. This implies that there are general characteristics of an IP level trigger that need to be defined so that the triggers generated by different layer 2 solutions will have identical semantics at the IP level. 4.3 The context transfer framework SHOULD support one-to-many context transfer. An MN may have connectivity to the access network through more than one physical path at any given time, depending upon the characteristics of the physical medium, and the layer 1 and 2 protocols and services. The different physical paths may connect into the network via different ARs. In this scenario, two or more ARs may be candidates for handover of the MN's traffic and each will require the appropriate IP context when forwarding commences. Exactly which AR will be the target of the handover is often not known until the handover is initiated, and providing the necessary context to all the candidate ARs can only accelerate the handover process. A one-to-many context transfer may be achieved using either a series of point-to-point transfers, or a point-to-multipoint (multicast) transfer. 4.4 The context transfer framework MUST support proactive context transfer. 4.5 The context transfer framework MUST support reactive context transfer It is useful to consider two modes of operation for context transfer: proactive and reactive. With proactive context transfer, the context is made available to an AR before it is needed. This means that the context is available at the AR before it is required to forward the first packet arrival in the MN's traffic. Proactive context transfer is coupled to mobile handover only by the requirement that the context be in place before the handover of the MN's traffic is complete. With reactive context transfer, the context is made available to an AR when the need is imminent. The implication here is that the initiation of a handover, or some event soon after initiation, triggers a reactive context transfer. Depending upon the network configuration, the MN's velocity and the behavior of the mobility solution, a reactive context transfer may or may not complete quickly enough for the new forwarding AR to provide a consistent service to the first packets of the re-directed traffic. The proactive mode of context transfer is an attempt to further reduce any disruption of the service provided to the MN's traffic by making the context available to an AR prior to it being needed for forwarding. This implies that some network event will occur at the IP level to indicate the potential for a handover, prior to the handover being initiated (c.f. requirements 4.1 and 4.2). This event would trigger a proactive context transfer. There can be no guarantee that this event will occur, and thus, a reactive context transfer is always required as a contingency. In many situations there is no forewarning available of a handover and context transfer must be initiated simply because the re-direction of the MN's traffic is in progress and the AR needs the forwarding context immediately. Because of the real world physics of MN movement and wireless coverage patterns, these situations can never be completely avoided. Thus, if context transfer is to be performed at all, the fundamental mode of operation must be reactive. This also means that a context transfer that begins in proactive mode may, as a result of the MN moving or other changes to the wireless environment, be required to complete in reactive mode. In this scenario, proactive and reactive context transfer are really two possible phases of a single attempted context transfer. As the proactive mode of context transfer is an enhancement, there may be situations where the reactive mode is considered a sufficient solution. While it is required that the context transfer protocol support proactive mode, its use is optional. 4.6 The context transfer framework MUST support a distributed approach in which the Access Routers act as peers during the context transfer. One main distinction between the various alternative approaches to context transfer is the choice of the functional entity or entities that orchestrate the transfer. A context transfer solution that relies upon the ARs to effect a context transfer should be the most efficient approach, as it involves the fewest possible entities. At the very least, the number of protocol exchanges should be less when there are fewer entities involved. 4.7 The entities transferring context MUST have completed a mutual authentication process prior to initiating the transfer. 4.8 The context transfer framework SHOULD provide mechanisms to selectively enable or disable context transfer for particular IP microflows or groups of IP microflows. The context associated with an MN's microflows is normally to be transferred whenever it is required to support forwarding. However, there may be conditions where it is desirable to selectively disable context transfer for specific microflows. For example, it may be desirable to provide an MN with the capability to disallow the transfer of the context associated with one or more of its microflows when handover occurs between networks administered by different operators. Local mechanisms for allowing context transfer to be disabled on a per microflow basis have to be provided for in the context transfer solution. These mechanisms will most likely be captured as part of the CT MIB, and possibly, as part of a PIB, if policy based management is considered desirable. There are other mechanisms and protocols required to manage or control the per microflow disabling of context transfer. These are clearly out of the scope of the context transfer work. 4.9 All context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of the context transfer. The total context associated with the MN's traffic is composed of various types of feature context. To effect a rapid transfer, the context information has to be readily available when the AR begins the transfer. 4.10 The context information provided for transfer MUST be reliable. The context to be transferred must not only be readily available for transfer, but the sending AR must ensure that the information is sound. The context transfer solution may provide mechanisms to support reliable transfer of context, but the effectiveness of context transfer in enhancing handover between ARs would very likely be compromised by attempts to transfer malformed context. 4.11 The context transfer framework MUST include methods for interworking with any IETF IP mobility solutions. 4.12 The context transfer framework MAY include methods for interworking with non-IETF mobility solutions. 5. Protocol Requirements This section captures the general requirements for the context transfer protocol. 5.1 General Protocol Requirements 5.1.1 The context transfer protocol MUST be capable of transferring all of the different types of feature context necessary to support the MN's traffic at a receiving AR. 5.1.2 The context transfer protocol design MUST define a standard representation for conveying context information that will be interpreted uniformly and perspicuously by different implementations. 5.1.3 The context transfer protocol MUST operate autonomously from the content of the context information being transferred. 5.1.4 The context transfer protocol design MUST define a standard method for labeling each feature context being transferred. Various protocols participate in setting up the service support for any given microflow, and many of these protocols require feature specific state to be maintained for the life of the IP session. The context transfer protocol should provide a generic mechanism to carry context information to an AR, irrespective of the context type. Given that the desired context transfer protocol is a single, generic protocol for transferring all feature context, the collection of information representing the context for a given feature must be encapsulated into a standard representation and labeled. Encapsulation is necessary to keep the context for different features separated. The receiving AR will use the label on an encapsulated context to associate it with the appropriate service feature and process the content appropriately. The context transfer protocol does not need to know the contents of these nuggets of encapsulated information. Indeed, for the protocol to be independent from the type of context being transferred, it must be oblivious the actual context. 5.1.5 The context transfer protocol design MUST provide for the future definition of new feature contexts. The context transfer solution must not attempt to define all possible feature contexts to be transferred. Instead, it must provide for the definition of new contexts in support of future service features, or feature evolution. Guidance should be provided to future users of context transfer on the best approach to defining feature context. 5.2 Transport Reliability This section is intentionally left blank as the working group is waiting for a questionnaire from the transport directorate. The result of the questionnaire will create requirements that will be added in this section in a later revision of this specification. 5.3 Security 5.3.1 The protocol MUST provide for "security provisioning". The security of the context information being exchanged between ARs must be ensured. Security provisioning includes protecting the integrity, confidentiality, and authenticity of the transfer, as well as protecting the ARs against replay attacks. 5.3.2 The security provisioning for context transfer MUST NOT require the creation of application layer security. 5.3.3 The protocol MUST provide for the security provisioning to be disabled. In some environments, the security provisioning provided for by the context transfer protocol may not be necessary, or it may be preferred to minimize the context transfer protocol overhead. 5.4 Timing Requirements 5.4.1 Proactive context transfer MUST be completed before the handover of the Mobile Node's traffic to the receiving AR completes. When an MN's traffic is handed over to a new AR, that AR will usually require the associated context in order to provide service contiguous with the service provide by the old AR. For there to be no disruption in service, the associated context needs to be installed at the new AR in time for the forwarding of the first packet of the MN's traffic. 5.4.2 The context transfer protocol SHOULD NOT introduce additional delay into the handover completion. The purpose of context transfer is to enhance the performance of traffic handover between ARs. While incurring additional delay may be acceptable in some situations, as a general solution, it is preferable that the context transfer protocol be capable of operating without impacting handover completion. For proactive context transfer, meeting requirement 5.4.2 will ensure that requirement 5.4.1 is not achieved by explicitly delaying the handover completion. For reactive context transfer, the requirement has to be less stringent. By definition, reactive context transfer is invoked when a handover to the receiving AR is either in progress or impending. Completing a reactive context transfer within any time constraint will depend heavily on the handover solution being used, and situational factors such as the topology of the network, or networks, local to the handover. Regardless, it is still useful to require that reactive context transfer not delay handover, if at all possible. If additional delay is unavoidable, then the reactive context transfer solution must be designed to minimize the incremental delay that is introduced. 5.4.3 A context transfer MUST complete with a minimum number of protocol exchanges between the source AR and the rest of the ARs. The number of protocol exchanges required to perform a peer to peer interaction is directly related to the unreliability, resource consumption, and completion time of that interaction. A context transfer will require signaling and data exchanges, but, as a general rule, by keeping the number of these exchanges to a minimum, the reliability, resource utilization and completion delay of the transfer should improve. 5.4.4 The context transfer protocol design MUST minimize the amount of processing required at the sending and receiving Access Routers. If the context transfer protocol requires the context information to be transferred in a form that requires significant additional processing at each AR, delays may be incurred that impact the reliability of the context. In other words, the context may become obsolete before it can be reconstructed at the receiving AR. Also, AR processing delay contributes to the overall context transfer delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. An example of a protocol design that would increase the processing delay at the receiver is where the context information is segmented, and the ordering of the segments is not preserved during transfer; segmenting at the sender, and more likely, re-ordering of the segments at the receiver could introduce significant additional AR processing delays. 5.4.5 The Context Transfer protocol MUST meet the timing constraints required by all the feature contexts. A given feature context may have timing constraints imposed by the nature of the service being support. The delivered context must always comply with the requirements of the service if it is to be useable. 5.4.6 The context transfer protocol MUST support the aggregation of multiple contexts. There may be instances where there are multiple context transfers pending. To reduce the overall transfer time, as well as transport overhead that might be incurred by separately transferring each context, the sending AR may choose to aggregate the contexts and execute one transfer operation. Note that if contexts are aggregated, the labeling method required by 5.1.4 must include an identifier that allows the contexts to be separated at the receiving AR. 5.5 Context Update and Synchronization 5.5.1 The context transfer protocol MUST be capable of updating context information when it changes. 5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN. 5.6 Interworking with handover mechanisms 5.6.1 The context transfer protocol MAY provide input to the handover process. 5.6.2 The context transfer protocol MUST include methods for exchanging information with the handover process. Both context transfer and handover require information on the AR candidates for handover. The context transfer entities may, in the process of establishing and supporting context transfer, acquire information that would be useful to the handover process in determining the new forwarding path: for example, the outcome of an admission control decision at a receiving AR. 5.7 Partial Handover 5.7.1 The context transfer protocol MAY provide a mechanism for supporting partial handovers. In a situation where no single AR is capable of receiving a handover of all of an MN's traffic, a mechanism could be provided that would allow different IP microflows to be handed over to different ARs. The information transferred to each AR must be limited to only the context required to support the microflows that are actually handed over. Thus, the context transfer protocol would need a mechanism for partitioning the context and transferring each portion to the appropriate AR. 6 References [1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. [2] Levkowetz et al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network ", draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. 7 Acknowledgements Thank you to all who participated in the Seamoby working group context transfer design team. 8 Author's Addresses Hamid 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 Pat R. Calhoun Network and Security Research Center, Sun Labs 15 Network Circle Menlo Park CA 94025 Phone: +1 650 786 7733 USA Email: pcalhoun@eng.sun.com Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 Phone: +1 847 632 5030 USA Email: madjid.nakhjiri@motorola.com Rajeev Koodli Communications Systems Laboratory, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 Phone: +1 650 625 2359 USA Email: rajeev.koodli@nokia.com Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090 CANADA EMail: kulwinder.atwal@zucotto.com Mark Smith COM DEV Wireless 3450 Broad Street, Suite 107 San Luis Obispo, CA 93401 Phone: +1 805 544 1089 USA Email: mark.smith@comdev.cc Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 Phone: +1 781 993 3627 USA EMail: govind.krishnamurthi@nokia.com 9 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 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.
Datatracker
Report a datatracker bug
draft-ietf-seamoby-ct-reqs-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |