Context and Micro-mobility Routing Working Group O. H. Levkowetz Internet Draft ABNW draft-ietf-seamoby-context-transfer-problem- P. R. Calhoun stat-02.txt Sun MicroSystems, Inc Expires: December 2001 G. Kenward H. M. Syed Nortel Networks J. Manner University of Helsinki M. Nakhjiri Motorola G. Krishnamurthi R. Koodli Nokia K. S. Atwal Zucotto Wireless M. Thomas Cisco M. Horan COM DEV P. Neumiller 3Com June 2001 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network 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. Levkowetz et al. [Page 1] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Abstract There are a large number of IP access networks that support mobility of 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 changes frequently and rapidly. This Internet-Draft describes the problem encountered during mobility that requires the exchange of IP context between different forwarding nodes in an access network. Table of Contents 1 Introduction...................................................2 2 Reference Definitions..........................................3 3 The Need for Context Transfer..................................4 3.1 Scope of the Context Transfer Solution .....................5 3.2 Reference Architectures ....................................6 4 A Description of Context.......................................6 4.1 Feature ....................................................6 4.2 Feature Context ............................................7 4.3 Microflow Context ..........................................7 4.4 Common Context .............................................7 4.5 Examples of Feature Context ................................8 5 Context Transfer and Mobility..................................8 6 Forwarding Node Capabilities...................................8 7 Inter-technology Context Transfers.............................8 8 Applicability..................................................9 9 Performance Considerations.....................................9 10 Security Considerations.......................................9 11 Recommendations..............................................10 1 Introduction There are a large number of IP access networks that support hosts that are mobile. 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 a 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 a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of 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. Levkowetz et al. [Page 2] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt The information required in support of a specific forwarding treatment provided to IP traffic is part of the context for that traffic. This context is comprised of configuration and state information. To minimize the impact of a path change on an IP flow, the context used at the forwarding nodes along the original path, must be replicated at 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. Context transfer at a minimum will be used to replicate the configuration information needed to establish the respective protocols and services. In addition, it may also provide the capability to replicate state information, allowing stateful protocols and services at the new node to be activated along the new path with less delay and less signalling overhead. 2 Reference Definitions Mobile Node An IP node capable of changing its point of attachment to the network. The mobile node is usually an end user host, but may be a forwarding node for a network that is itself mobile. Forwarding Node A node that supports IP forwarding within the access network. This includes all routers, gateways, servers and other nodes within the network that have IP protocol stacks and forward IP traffic to and from a mobile node. A forwarding node will be connected to one or more other forwarding nodes. Some forwarding nodes will be connected to zero or more mobile nodes. The forwarding nodes that connect to mobile nodes will do so through a layer two entity that supports wireless communications. Microflow One useful definition for the fundamental unit of IP service is the microflow. RFC 2475 [1] defines a microflow as: A single instance of an application-to application flow of packets destined to or originated from a mobile device (MN or MH), which is identified by source address, source port, destination address, destination port and protocol id. Levkowetz et al. [Page 3] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt RFC 2207 [2] provides a definition of a microflow that applies to IPSec packets. It is based on the IPSec SPI found in the AH or ESP headers. Other methods for identifying for IP microflows may be defined in the future, e.g. the Ipv6 flow label. 3 The Need for Context Transfer 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 a time sensitive service such as VoIP telephony, video, etc., in a mobile environment depends heavily upon the minimization of 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. Figure 1 and 2 below illustrate an example of a handover scenario. A mobile node, MN7, is shown attached to the Internet via an access network. The forwarding nodes, FN1 through to FN7 comprise a portion of this access network. FN1 and FN7 are the last forwarding nodes before the untethered link to MN7. This last link allows the nodes to move while maintaining connectivity to the edge of the access network - e.g. the last link is wireless. For simplicity, many details of a real access network topology have been left out of the diagrams. Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. It is presumable that FN1 and FN2 have been configured to provide specific forwarding services for MN7's traffic, and that some of these services may require state information to be maintained. MN7's traffic <------------------> ------- ------- [ MN7 ]<= = = =>| FN1 |=================| FN2 |======== ------- /------- / -------/ | FN4 | /-------\ / \ / \ -------/ \------- - - -| FN7 | | FN6 |---- ------- ------- Figure 1: Path Prior to Handover Levkowetz et al. [Page 4] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt When MN7's movement results in the link to FN1 to be replaced by a link to FN7, MN7's traffic must be re-directed along a new forwarding path, illustrated in Figure 2 as the path through FN7, FN4 and FN2. In many mobile networks, this handover can occur frequently, and sometimes with little or no warning. ------- ------- - - -| FN1 |----------------| FN2 |======== ------- //------- // MN7's traffic -------/ <-----------> | FN4 | //------\ MN7's traffic // \ <-----------> // \ -------/ \------- [ MN7 ]<= = = =>| FN7 | | FN6 |---- ------- ------- Figure 2: Path Re-Directed After Handover If the forwarding treatment provided to MN7's traffic is to be sustained, the support conditions at FN1 and FN2 must be reproduced at FN7 and FN4. At the very least, this requires that FN7 and FN4 be configured to provide the appropriate support to the traffic flow. However, establishing forwarding support along the new path through the use of IP signalling protocols would be relatively time consuming. In addition, given that some forwarding services may maintain state information, simply configuring FN7 and FN4 would not circumvent disruption of the services. Given that FN7 and FN4 support the same functionality as FN1, it should be possible to reproduce the needed support along the new forwarding path by capturing the salient information at FN1 as it exists just prior to the handover, and then use that information to replicate the state of FN1 at FN7 and FN4. 3.1 Scope of the Context Transfer Solution The information required to produce the necessary forwarding treatments at a node is referred to as the support "context". In order to replicate the context of one forwarding node at another forwarding node, an open, standard solution for context transfer must be developed. Levkowetz et al. [Page 5] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In addition, for a forwarding node to be able to interpret the transferred context, both the syntax and the semantics of the context information must be defined. Definition of the actual context information will be specific to the support feature being replicated, however, a generic container format of the payload of context transfer messages is required for inter-operability. 3.2 Reference Architectures The concept of the "forwarding node" is used here to describe the general context transfer problem. In different networks, the actual context transfer may take place between different entities within the network. In some cases the preferred context transfer peers might be the routers at the edge of the access network. In other situations, it may be more appropriate to transfer context between wireless access points that also support forwarding of IP packets. The context transfer solution will be applicable to any nodes that support forwarding of a mobile nodes IP traffic. 4 A Description of Context The term ` `context' ' pertains to all information required by a forwarding node specific to supporting the IP traffic for a particular mobile node. The context for a mobile node can be partitioned into three categories: - information required to provide generally support to the mobile node; - information required to provide common support to the mobile node's traffic; - information required to support specific features of the forwarding treatment for an IP microflow. 4.1 Feature A feature is an aspect of the IP forwarding treatment that is instantiated for each mobile node, and which may support one or more of the mobile nodes microflows. A feature must include associated configuration information: at the very least, some identification information for the mobile node, such as the mobile node's IP address. A feature may have associated state information. Levkowetz et al. [Page 6] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt In other words, for the purpose of supporting mobility the features of interest all have context pertinent to the forwarding of a specific mobile nodes IP packets. Examples of features include: header compression, security, subscriber policy, and quality of service. Each feature is, in general, supported by an amalgamation of one or more protocols and associated local support mechanisms. As an example, header compression is a feature that consists of various "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP header compression, operating according to well-defined "protocols". Thus, an instance of a feature reflects the state associated with protocols and the corresponding mechanisms. 4.2 Feature Context Feature context is the condition or state of an instance of a particular feature. It represents the current evolution of the behaviour of that feature instance. At a given instant in time, feature context is represented by the values of the associated data elements. Some of the data elements associated with a feature are time invariant and, thus, represent the configuration of the feature instance. Other data elements, which are often referred to as the "state variables" for the feature instance, change value over time as a consequence of the various operations performed in support of the feature instance. A feature context is believed to be the smallest indivisible unit of context that can be transferred between forwarding nodes. 4.3 Microflow Context A microflow context is the collection of the various feature contexts associated with a single IP microflow. It is the smallest unit of context that must be transferred in order to re-establish support for the microflow at a forwarding node. 4.4 Common Context Some of the associated feature contexts may be applicable to more then one of the IP microflows comprising the mobile node's traffic. An example of this might be the authentication state for the mobile. This type of feature context is also required to support each microflow, but because of the multiplicity of the relationship to the mobile node's microflows, it would seem prudent to transfer one instance of the context, independent of the microflow context. Levkowetz et al. [Page 7] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt 4.5 Examples of Feature Context Some examples of feature contexts that are candidates for context transfer are given below. This list is provided solely to illustrate the nature of the context transfer problem domain. - encryption context; - authentication context; - authorization context; - accounting context; - header compression context; - quality of service context; - policy enforcement context; - multicast group membership; - buffer state; - sub-network layer context (e.g. PPP context). 5 Context Transfer and Mobility Context transfer is an enhancement to a mobility solution that is clearly most effective when used on a local scale between forwarding nodes within a subnetwork. However, with due consideration to the nature of the context and the requirements for transfer of that context, context transfer should be applicable between any two similar forwarding nodes. 6 Forwarding Node Capabilities Context transfer between two forwarding nodes is worthwhile only if the receiving node's capabilities are similar enough to those of the sending node that the received context can be utilized. This does not mean that the two nodes are identical in their implementation, nor does it even imply that they must have identical capabilities. A forwarding node that cannot make use of received context could, and should, refuse the transfer. This would result in a situation no different then mobile handover without context transfer. 7 Inter-technology Context Transfers The context transfer described here operates at the IP layer, and should be applicable to situations where the forwarding nodes are supporting different wireless link technologies. Levkowetz et al. [Page 8] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt An exception to this would be where sub-IP layer context is an intrinsic part of the forwarding treatment. In this situation, an interworking solution must be developed for sub-IP context transfer between the two technologies. This issue is outside the scope of the Seamoby working group. 8 Applicability The primary motivation for developing an IP context transfer assumes that service sustainment during handover is desirable. And yet, there may be situations where either the user or the access network would prefer to re-establish or re-negotiate a service or a service feature. For example, if the mobile node crosses administration domains where the operational policies change, negotiation of a different level of service may be required by the respective operators. More important, the concept of context transfer also assumes that the service is worth sustaining through a variety of handover scenarios, and that context transfer is the best approach. The former may not be true for certain types of service - for example, multicast, "push" information services. In addition, even if service level sustainment is desirable, context transfer may not be the most cost efficient solution. Alternatives to context transfer for sustaining services during handover are out of scope for the Seamoby working group. The possibility of other solutions is only noted here to emphasize that context transfer is but one of possibly many approaches. Finally, context transfer is an enhancement at the IP level to improve upon the performance of a handover between IP forwarding nodes. Many networks provide support for handover at the link layer, within and between subnetworks, and context transfer may not provide a significant improvement over the these link layer solutions. 9 Performance Considerations The purpose of context transfer is to sustain the services being provided to a mobile node's traffic during handover. It is essentially an enhancement to a mobility solution that ultimately must result in an improvement in handover performance. The various aspects of performance must be a prime consideration in the development of the context transfer solution. 10 Security Considerations Some of the considerations for context transfer security include: Levkowetz et al. [Page 9] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt - information privacy: the context may contain information which the end user would prefer to keep hidden from unauthorized viewers. - transfer legitimacy: a false or purposely corrupted context transfer could have a severe impact upon the operation of the receiving forwarding node, and therefore could potentially affect the operation of the access network itself; the potential threats include denial of service and theft of service attacks; context transfer must only occur between forwarding nodes that have an established trust relationship. - security preservation: part of the context transfer may include information pertinent to a security association established between the mobile node and another entity on the network; for this security association to be preserved during handover, the transfer of the security context must include the appropriate security measures. It is expected that the measures used to secure the transport of information between peers in an IP network should be sufficient for context transfer. However, given the above considerations, there may be reason to provide for additional security measures beyond the available IETF solutions. The context transfer investigation must identify any novel security measures required for context transfer that exceed the capabilities of the existing or emerging IETF solutions. 11 Recommendations The Seamoby context transfer design team recommends the following: - investigation into candidates for context transfer - in particular, feature context transfer, and an analysis of the transfer requirements for each candidate; - the development of a framework and protocol(s) that will support the transfer of configuration and state context between the forwarding nodes of an IP network. The context transfer solution must interwork with existing and emerging IP protocols, in particular, those protocols supporting mobility in an IP network. References Levkowetz et al. [Page 10] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt [1] Blake, et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. Authors' Addresses O. Henrik Levkowetz A Brand New World Osterogatan 1 S-164 28 Kista SWEDEN Phone: +46 8 477 9942 EMail: henrik@levkowetz.com Pat R. Calhoun Network and Security Research Center, Sun Labs 15 Network Circle Menlo Park CA 94025 USA Phone: +1 650-786-7733 EMail: pcalhoun@eng.sun.com Gary Kenward Nortel Networks 3500 Carling Avenue Nepean, Ontario K2G 6J8 CANADA Phone: +1 613-765-1437 EMail: gkenward@nortelnetworks.com Hamid Syed Nortel Networks 100 Constellation Crescent Nepean Ontario K2G 6J8 CANADA Phone: +1 613 763-6553 EMail: hmsyed@nortelnetworks.com Jukka Manner Department of Computer Science, University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND Levkowetz et al. [Page 11] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Phone: +358-9-191-44210 EMail: jmanner@cs.helsinki.fi Madjid Nakhjiri Motorola 1501 West Shure Drive Arlington Heights IL 60004 USA Phone: +1 847-632-5030 EMail: madjid.nakhjiri@motorola.com Govind Krishnamurthi Communications Systems Laboratory, Nokia Research Center 5 Wayside Road Burlington MA 01803 USA Phone: +1 781 993 3627 EMail: govind.krishnamurthi@nokia.com Rajeev Koodli Communications Systems Lab, Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA Phone: +1 650 625 2359 EMail: rajeev.koodli@nokia.com Kulwinder S. Atwal Zucotto Wireless Inc. Ottawa Ontario K1P 6E2 CANADA Phone: +1 613 789 0090 EMail: kulwinder.atwal@zucotto.com Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA Phone: +1 408 525 5386 Levkowetz et al. [Page 12] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt EMail: mat@cisco.com Mat Horan COM DEV Wireless Group San Luis Obispo CA 93401 USA Phone: +1 805 544 1089 EMail: mat.horan@comdev.cc Phillip Neumiller 3Com Corporation 1800 W. Central Road Mount Prospect IL 60056 USA EMail: phil_neumiller@3com.com 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. Acknowledgement Levkowetz et al. [Page 13] Internet Draft June 2001 draft-ietf-seamoby-context-transfer-problem-02.txt Funding for the RFC editor function is currently provided by the Internet Society. Levkowetz et al. [Page 14]