SeaMoby Working Group O. H. Levkowetz Internet-Draft ABNW Expires: August 20, 2001 P. R. Calhoun Sun Microsystems, Inc 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 February 19, 2001 Problem Description: Reasons For Doing 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. Levkowetz, et. al. Expires August 20, 2001 [Page 1] Internet-Draft Why SeaMoby Context Transfer February 2001 This Internet-Draft will expire on August 20, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract There are a large number of IP access networks that support mobility of hosts. For example, wireless Personal Area Networks (PANs) and LANs, satellite and cellular WANs. The nature of this mobility is such that the communication path to the host changes frequently, and rapidly. This Internet-Draft aims at expressing the problems occurring during such mobility which require the exchange of IP flow context between different nodes in the access network. A reference architecture is described and the central terms "Context" and "Context Transfer" defined. Some explicit problems which benefits from context transfer are listed. Levkowetz, et. al. Expires August 20, 2001 [Page 2] Internet-Draft Why SeaMoby Context Transfer February 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. Reference Architecture . . . . . . . . . . . . . . . . . . 5 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Architectural Diagram . . . . . . . . . . . . . . . . . . 8 3. Context Defined . . . . . . . . . . . . . . . . . . . . . 8 3.1 Basic definitions . . . . . . . . . . . . . . . . . . . . 8 3.1.1 Microflows . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Feature . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3 Feature State . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Feature Context . . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Microflow Context . . . . . . . . . . . . . . . . . . . . 10 3.1.6 Context . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Some Types of Context . . . . . . . . . . . . . . . . . . 10 3.2.1 Security and AAA information . . . . . . . . . . . . . . . 11 3.2.2 Header Compression State . . . . . . . . . . . . . . . . . 11 3.2.2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3 Diffserv / Intserv . . . . . . . . . . . . . . . . . . . . 13 3.2.4 QoS Policy Management . . . . . . . . . . . . . . . . . . 13 3.2.5 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.6 Sub-network layer state . . . . . . . . . . . . . . . . . 15 4. Context Transfer Defined . . . . . . . . . . . . . . . . . 15 4.1 Context Transfer -- Alternative Approaches . . . . . . . . 15 4.1.1 No context transfer . . . . . . . . . . . . . . . . . . . 15 4.1.2 Mobile Updates new Access Router . . . . . . . . . . . . . 15 4.1.3 Access Routers Exchange State . . . . . . . . . . . . . . 16 4.1.4 Central repository . . . . . . . . . . . . . . . . . . . . 16 4.1.5 Each Application is aware of handovers and access routers 17 5. Security Considerations . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 A. Context Transfer Issues to Consider . . . . . . . . . . . 20 A.1 Selection of a generic architecture for context transfer . 20 A.2 Definition of Sender and Receiver . . . . . . . . . . . . 21 A.3 Transferring the context information . . . . . . . . . . . 21 A.4 Knowledge of neighbour capabilities . . . . . . . . . . . 22 A.5 Per packet or real-time context information transfer . . . 22 A.6 Partially Failed Context Transfer . . . . . . . . . . . . 22 A.7 Different security environments . . . . . . . . . . . . . 23 A.8 Dynamic trust relationships . . . . . . . . . . . . . . . 23 A.9 Context Transfer Security Issues . . . . . . . . . . . . . 24 A.10 Mobile Routers . . . . . . . . . . . . . . . . . . . . . . 24 A.11 Characteristics of a Context Transfer Transport Protocol . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . 26 Levkowetz, et. al. Expires August 20, 2001 [Page 3] Internet-Draft Why SeaMoby Context Transfer February 2001 1. Introduction There are a large number of IP access networks that support mobility of hosts. For example, wireless Personal Area Networks (PANs) and LANs, satellite and cellular WANs. The nature of this mobility is such that the communication path to the host changes frequently, and rapidly. In many situations, the change of communications path includes a change in communications media between the host and access networking, including changes from a wireless to a wired connection. This Internet-Draft aims at expressing the problems occurring during such mobility which require the exchange of IP flow context between different nodes in the access network. In networks where hosts are mobile, the success of real-time sensitive services like VoIP telephony, video, and others rests heavily on the matter of how seamless (Section 2.1) a handover can be made. Perfect seamlessness would mean that mobility will not give the user of IP based services any reduction in the quality of service received. There exist a number of impediments to perfectly seamless handovers if only existing protocols and technology are used. Some of these are listed in Section 3.2, and include set-up of AAA, header compression, Diffserv/Intserv, policies, and possibly lower layers, e.g. PPP, to be done after each handover. Context transfers reduce the effect of handovers on real-time applications, by minimizing the time needed to attain the level of service provided to the mobile node at the previous access router. In the rest of the draft, a reference architecture and definitions of the terms "Context" and "Context Transfer" will be given, during this we will list in more detail a number of cases where explicit context transfer would be advantageous, and why. In Appendix A we mention some issues that need to be considered in designing context transfer protocols. 2. Reference Architecture The reference architecture described with definitions and diagrams below is a functional map, and may map in many ways to physical implementations. In particular, one physical container may well include several different functional elements. In general, the definitions of draft-manner-seamoby-terms-00.txt [1] are applicable to this document. In particular, the following terms are useful: Levkowetz, et. al. Expires August 20, 2001 [Page 4] Internet-Draft Why SeaMoby Context Transfer February 2001 2.1 Definitions Seamless The absolute reference definition for a seamless handover is one in which there is no change in service capability, security, or quality. In practice, some degradation in service is to be expected. The definition of a seamless handover in the practical case should be that the end user does not detect any change in service capability, security or quality. Since the user's ability to detect change is subjective and conditioned by many environmental conditions, this definition is extremely difficult to quantify. Characterization of end user perception of seamlessness is beyond the scope of an IETF working group. Thus, the reference definition, although stringent, is the best working definition for Seamless Mobility. Mobile Node (MN) An IP node capable of changing its point of attachment to the network. The MN can be either a mobile end-node or a mobile router serving an arbitrarily complex mobile network. Mobile Router A mobile node can be a router, which is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak. The nodes connected to a network served by the mobile router may themselves be fixed nodes or mobile nodes or routers. In this document, such networks are called "mobile networks". [2] Mobile Host (MH) An IP node capable of changing its point of attachment to the network. The MH only refers to an end-node without further routing support. Access Point (AP) A layer 2 device that is connected to one or more Access Routers and offers the wireless link connection to the MH. Access Points are sometimes called 'base stations'. Note that this usage differs from that used by some Access Router vendors, who call their boxes 'Access Points'. Access Router (AR) An IP router residing in an Access Network and connected to one or more access points. An AR offers connectivity to MNs. Levkowetz, et. al. Expires August 20, 2001 [Page 5] Internet-Draft Why SeaMoby Context Transfer February 2001 The router may include intelligence beyond simple forwarding service offered by ordinary IP routers. An AR communicates with one or more Access Points. Access Network Gateway (ANG) An IP gateway that separates the Access Network from a third party network. Access Network (AN) An IP network that includes one or more ARs and ANGs. Administrative Domain(AD) Administrative Domain: A collection of networks under the same administrative control and grouped together for administrative purposes. [3] Radio Cell An area associated with each AP, where there is radio coverage, i.e. where radio communication between a MN and the specific AP is possible. Levkowetz, et. al. Expires August 20, 2001 [Page 6] Internet-Draft Why SeaMoby Context Transfer February 2001 2.2 Architectural Diagram --- ------ ------- | |<--> | | -------| AR | -------------------| | | [] --- /------ \ /| ANG |--| MN AP / \ / | | | / \ / ------- | ___ / \ / | | |---- X | --- / \ | AP / \ | / \ ------- | --- ------ / \| | | | |-------| AR |---------------------| ANG |--| --- ------ | | | AP ------- | | Administrative Domain (AD) 1 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| - - - - - Administrative Domain (AD) 2 | | | --- ------ ------- | |<--> | | -------| AR | -------------------| | | [] --- /------ /| ANG |--| MH AP / / | | | / / ------- | ___ / / | | |---- / | --- / | AP / | / | --- ------ / | | |-------| AR |------------ | --- \ ------ / | AP \ / | \ / | \ ------ / | --| AR |------- | ------ | | 3. Context Defined 3.1 Basic definitions In this section we define the components of context, and context itself, as used in this document. Levkowetz, et. al. Expires August 20, 2001 [Page 7] Internet-Draft Why SeaMoby Context Transfer February 2001 3.1.1 Microflows The fundamental unit of IP service is the microflow. IP microflows may be bundled, or aggregated, for a variety of reasons. As examples, Differentiated Services are provided to aggregates of IP microflows, and authentication is typically associated with the all the IP microflows with the same source address. However, the smallest component of traffic sent to and from a given MN that may have a distinct context is an IP microflow. RFC 2475[4] defines 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.' RFC 2207[5] also provides a definition of a microflow based on the IPsec SPI found in the AH or ESP header. Other handles for micro flows may be forthcoming in the future, and in particular the use of the IPv6 flow label may be standardized. Two or more IP microflows may be collectively supporting a higher layer application. There is an association or co-dependency between these microflows that should also be preserved during handover. However, this co-dependency relationship between microflows is unknown to the network, and thus cannot be explicitly preserved by the network. It would seem reasonable that higher layer context would be preserved implicitly if seamless handover is achieved. There is cause for concern when a completely seamless handover cannot be achieved: degradation of the context for even one of a set of co-dependent microflows may have a disproportionate impact on the function or performance of the application. 3.1.2 Feature A feature is an IP network functionality offered to a mobile node that is of interest to context transfers. Each feature, in general, is an amalgamation of one or more protocols and the associated mechanisms that support them. It is worthwhile to observe the multiplicity of these "protocol mechanisms" underlying each feature. As an example, header compression is a feature that consists of various "mechanisms", such as IP/TCP compression and IPv6/UDP/RTP compression, operating according to well-defined "protocols". Thus, an instance of a feature reflects the state associated with Levkowetz, et. al. Expires August 20, 2001 [Page 8] Internet-Draft Why SeaMoby Context Transfer February 2001 protocols and the corresponding mechanisms. 3.1.3 Feature State The condition or state of a particular feature instance, representing the current evolution of the behaviour of that feature. At a given instant in time, the state of a feature instance is represented by the values of the data elements associated with the feature instance. Some of these data elements are time invariant and represent the configuration of the feature instance, while others elements, often called "state variables" change value over time in support of various protocol operations related to that feature. 3.1.4 Feature Context This is the state information associated with a particular feature for a microflow. When a feature is supported by multiple protocol mechanisms, the state information has to be specific for each such protocol mechanism. As an example, header compression is a feature that may support IP/TCP compression and IPv6/UDP/RTP compression. The feature context for header compression must clearly specify the state information for each supported mechanism. A feature context is the smallest unit of context transfer. 3.1.5 Microflow Context A Microflow Context is a collection of various feature contexts associated with a microflow. 3.1.6 Context A set of all microflow contexts representing all the microflows associated with a mobile node. Eventual feature state modifications, needed for proper operation or maximizing the utility of a feature at the new network, are outside the scope of the context definition. The same applies to cases where protocols at the original network are not supported at the new network; matching equivalent protocols at different sides of a handover is outside the scope. 3.2 Some Types of Context Some examples of context that might need to be transferred is given below. This does not constitute a complete list of possible context to be transferred. Levkowetz, et. al. Expires August 20, 2001 [Page 9] Internet-Draft Why SeaMoby Context Transfer February 2001 3.2.1 Security and AAA information Examples of security services are those provided to a MH, such as user data encryption, user data integrity protection, and MH location privacy. Examples of network security requirements are network topology and policy protection. Example of AAA mechanisms are MH-to-network authentication, authorization of MH for access to a specific service type, and accounting, including network usage records for billing and traffic engineering purposes. Security and AAA context include the information regarding trust relationships to provide security services and the data to maintain AAA functionality. However, the context only includes the information that already exists at the source AR prior to handover, i.e. the information needed to re-establish the trust of AAA services at the target AR is not part of the context that must be transferred. This is explained in further detail as a security issue in Appendix A. Among the most important security and AAA context data are security associations (SA), which include encryption or authentication keys and algorithms, identification data necessary for authentication , and authorization of usage privileges. For seamless handover, the security and AAA portion of the context, needs to be transferred as part of the context transfer process in order to expedite the resumption of the security and AAA services at the target AR. 3.2.2 Header Compression State Compression of IP and transport layer headers is crucial over low-bandwidth links in order to achieve efficient utilization of the link capacity to deliver useful payload to applications. Header compression requires the maintenance of state information at the network periphery, the AR, and at the MN. When terminal mobility is involved, relocation of the compression context(s) is needed in order to avoid surges in bandwidth consumption associated with compression context re-establishment, which causes interruptions to the smooth delivery of real-time packets. This overhead can be avoided, and thus the seamless operation of header compression facilitated, by a simple transfer of context variables from an access router's compression engine to that of the terminal's new access router. 3.2.2.1 Terminology The following terminology is used in describing the need for header compression context relocation. Levkowetz, et. al. Expires August 20, 2001 [Page 10] Internet-Draft Why SeaMoby Context Transfer February 2001 HC: Header Compression Full Header (FH) packet: Contains the full IP and transport protocol headers, plus the HC-specific fields First Order (FO) [packet]: Contains only those fields that change from packet to packet (e.g. RTP timestamp), and does not contain fields that do not change at all. Second Order (SO): Contains HC-specific header and sequence number. The rest of the fields are constructed from the sequence number info and the information maintained by the decompressor. 3.2.2.2 Discussion The motivation for HC context relocation is best understood by examining the typical header compression operation. A compressor starts by sending Full Header (FH) packets with HC-specific headers in them and waits for few of the FHs to be reliably propagated (e.g., ACK-based or 'n' number of headers transmitted). Note that in bandwidth-constrained links, the link latency as well as higher error probabilities could force the transmission of many FHs before confirming reliable propagation of header information. Similarly, many FO packets are sent before confirming that transition to the SO state is possible. This process of "reference state" establishment is expensive. E.g., on a 60 ms cellular link and with 20 ms packetisation for voice, it would take 6 FHs (assuming no errors and dropped packets) to establish the FH state that allows transition to FO, and 6 more FOs to establish the FH+FO reference state that allows transition to SO state. The total overhead is thus 240 ms plus the processing overhead associated with the header compression operation. Perhaps a value of 300 ms may be deemed typical. Since this context establishment needs to be done for each unidirectional packet stream, the overhead gets worse with multiple packets streams belonging to the same mobile node (approximately 600 ms for bi-directional voice). When Mobile IPv6 is used with Home Address option, FH = 84 bytes (excluding HC-specific fields) for a payload of about 20-30 bytes, and FO could be 8 bytes. In comparison, the overhead is 1 byte when operating in the SO state. The expensive overheads associated with context re-establishment can be avoided by relocating the appropriate context between access Levkowetz, et. al. Expires August 20, 2001 [Page 11] Internet-Draft Why SeaMoby Context Transfer February 2001 routers. For each type of compression mechanism used (e.g.,IPv6/UDP/RTP, IPv6 only, IPv6/TCP wtc), a Compression Profile Type (CPT) identifies the particular type, and defines the state variables. Thus, the combination of CPT, and the associated state variables (along with a suitable identifier) constitutes the context for transfer purpose. This transfer (presumably) occurs synchronously with handover signalling associated with terminal mobility. 3.2.3 Diffserv / Intserv Integrated services and Differentiated services are the two proposed QoS-enabling frameworks in the IP networks. A resource reservation protocol (RSVP) enables the Integrated services framework. Both of the mechanisms (RSVP and Diffserv) are stateful and requires certain information to be maintained at the access router. For example, in a pure RSVP-enabled session, the access router requires the flow classification information and the bandwidth requirements of a particular flow to make a packet forwarding decision. The flow classification state is composed of the 5-tuples that uniquely identifies a flow (source/destination IP address, source/destination port and the protocol ID). Similarly, the Diffserv-enabled routers require the classification, packet forwarding and traffic conditioning information to perform an appropriate scheduling of the flows. In addition to the classification information, a Diffserv code point (DSCP) is also required as a state information at the access router. Meter values for an MN used to police and shape microflows also form part of the MN context. In a handover situation, all candidate access routers will need the QoS context used by the old access router to support an MN's microflows. Once the information is available (via context transfer) at the potential new access router, it can be processed to make any decisions on whether or not the whole (or partial) QoS context can be supported with the available capabilities of the access router. The target capabilities may include support of the QoS mechanism (for example the target router may not have Diffserv support), size of the queues, policy rules at the router, available resources on particular interfaces etc. 3.2.4 QoS Policy Management The authorization of the QoS requests against the user profile can be performed based on the service level agreements set up between the user's applications and the network. These agreements are translated into the network policies and controlled by policy servers responsible for the domain policy control. A policy-based Levkowetz, et. al. Expires August 20, 2001 [Page 12] Internet-Draft Why SeaMoby Context Transfer February 2001 admission control framework has already been defined and standardized at the IETF [3]. The common open policy services (COPS) [6] is the protocol that carries the network policies in the form of device configuration parameters from a policy server to the actual device for enforcement. COPS is a stateful mechanism that keeps a synchronized copy of all decisions at both client and the server. There are two popular flavours of COPS protocol. The outsourcing model of COPS [7] allows the network devices to outsource the policy decisions to the policy server by encapsulating the RSVP message objects into COPS-RSVP protocol. The dynamic admission control decisions are based on a per RSVP request and the decision states are maintained at the client as well as the server. Any change in the decision or the device configuration is propagated to either side in a way that the client and server states are always mirrored. In the provisioning model [8], The Policy server provision the device policies when the device is introduced in its domain. These decisions contain both user and device specific policies. Again, the decision states are maintained at both client and server and any change is propagated to each other. In case of change in access router (due to user mobility), the new serving access router need the policy context created and maintained at the source access router. The new device may or may not reside in the same policy domain. In either case, the policy context would help the new access router or the policy server responsible for it to make any decision on whether the mobile's context can be supported at the device, or a subset of the whole context could be allowed. If the access router belongs to a different policy domain, the mobile's active sessions may need to be re-authorized against its profile in the new policy domain. 3.2.5 Buffers A requirement for seamless handovers is to minimize the packet loss when a MN moves from the old AR to the new AR. Thus, buffered packets must be transferred to provide seamless handovers in mobile networks. A research effort that supports this claim is [9]. The incoming packets to a MN are buffered at the old AR and are transferred to the new AR when the new AR is made known to the old AR. The new AR buffers the packets until they can be forwarded to the MN. A buffering context for the MN would comprise the packets that the MN receives at the old AR. Issues like buffer capacity at the new AR are to be considered to ensure successful buffering context transfer during a handover. The new AR, therefore, would need information about the buffer requirements for the MN. Levkowetz, et. al. Expires August 20, 2001 [Page 13] Internet-Draft Why SeaMoby Context Transfer February 2001 3.2.6 Sub-network layer state Sub-network Layer State information may include PPP state information. To prevent reestablishment of a connection during a handover from one AR to another this information may be transferred. Examples of PPP context are standard LCP parameters including Max Receive Unit, Authentication Protocol, Magic Number, and header compression. Examples of IPCP (NCP) parameters include IP address header compression and DNS information. However, it should be noted that some information, such as DNS, may change when moving to a new access router and therefore transferring this may be less than useful; instead renegotiation may be needed. 4. Context Transfer Defined Context transfer is a mechanism for establishing sufficient conditions at one or more ARs to fully support the microflow(s) of a mobile node. After completion of a context transfer, an AR will be capable of forwarding the IP packets to and from the mobile node without disruption of the established service. 4.1 Context Transfer -- Alternative Approaches There are many alternatives when considering context transfer between two Access Routers. The following sections discusses some of these alternatives and the considerations that need to be addressed. 4.1.1 No context transfer No context transfer is essentially how today's Mobile IP networks operate. When a Mobile Node moves to a New Access Router, it re-establishes any state with the Access Router. Each application will use its own protocol (signalling) to update the New Access Router. - Pro: No changes, no additional protocol. - Con: Long latency (service interruption) during handover - Con: Use of radio channel bandwidth to re-establish context - Con: Every application needs to adapt to changing service levels from the network. 4.1.2 Mobile Updates new Access Router Another alternative would allow a Mobile to update the new Access Router with its state. However, for the Mobile to have an accurate snapshot of the current context, it would be necessary to periodically transfer the AR context to the Mobile (e.g. AAA or QOS state may change periodically on the current Access Router). Levkowetz, et. al. Expires August 20, 2001 [Page 14] Internet-Draft Why SeaMoby Context Transfer February 2001 - Pro: No connectivity required between ARs. - Con: Added state synchronization needed between AR and MN - Con: Long latency (service interruption) during handover if the context transfer cannot be done proactively. - Con: Use of radio channel bandwidth to re-establish context - Con: Security problems, MN may not be a trusted entity - Con: New protocol needed for context transfer 4.1.3 Access Routers Exchange State In this alternative, when Access Routers notice that a handover is occurring or imminent, context information would be sent to the candidate Access Routers. It is assumed that a generalized protocol would carry all of the context for all of the mobile node's microflows. - Pro: No use of radio bandwidth to re-establish context - Pro: A large reduction of latency (service interruption) during handover compared to the case in Section 4.1.1 (assuming radio bandwidth is much less than fixed bandwidth) - Pro: Possibly elimination of latency due to context transfer, as it may be done before and / or during handover - Con: Protocol needed for context transfer - Con: A mechanism to choose candidate ARs and where to finally handover is needed. 4.1.4 Central repository The context transfer between access points/routers is controlled by a central entity in the network. This entity could be a policy server, one of the access network gateways, or one of the access routers. This entity keeps the context information for the mobiles that are registered under the domain of that entity and "re-installs" the context at the new access point/router as the mobile moves. This entity may also "delete" the context from the old access point, if required. - Pro: No use of radio bandwidth to re-establish context - Pro: A large reduction of latency (service interruption) during handover compared to the case in Section 4.1.1 (assuming radio bandwidth is much less than fixed bandwidth) - Pro: Possibly elimination of latency due to context transfer, as it may be done before and / or during handover - Pro: one clear decision point (similar to PDP) and information storage. Knows the state of the whole (sub) network. - Con: New protocol needed for context transfer - Con: As in Section 4.1.2, added synchronization is needed, this time between AR and repository - Con: May have scalability problems in terms of the number of Levkowetz, et. al. Expires August 20, 2001 [Page 15] Internet-Draft Why SeaMoby Context Transfer February 2001 mobiles registered within the domain of the entity and the number of active sessions per mobile. Can be even worse if multiple access networks are involved. - Con: Contract relationship must pre-exist or be established 4.1.5 Each Application is aware of handovers and access routers A last alternative would be to define the requirements for context transfer, and modify all applications to arrange for state to be moved between Access Routers. - Pro: Context transfer more fully under application control - Con: Context transfer additions needed for every single higher protocol -- multiplied complexity - Con: Only applications specifically adapted for context transfer would be able to take advantage of seamless mobility - Con: wasted bandwidth (if all application transfer their context information individually) 5. Security Considerations This type of non-protocol document does not directly affect the security of the Internet. (However, for some comments on possible security issues with the implementation of context transfer, see Appendix A.7, Appendix A.8 and Appendix A.9). References [1] Manner, et al., "Mobility Related Terminology", draft-manner-seamoby-terms-00 (work in progress), January 2001. [2] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [3] Yavatkar, et al., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [4] Blake, et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [5] Berger & O'Malley, , "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [6] Durham, et al., "The COPS Common Open Policy Services protocol", RFC 2748, January 2000. [7] Herzog, et al., "COPS Usage for RSVP", RFC 2749, January 2000. [8] Chan, et al., "COPS Usage for Policy provisioning", draft-ietf-rap-pr-05 (work in progress), October 2000. Levkowetz, et. al. Expires August 20, 2001 [Page 16] Internet-Draft Why SeaMoby Context Transfer February 2001 [9] Caceres, R. and V.N. Padmanabhan, "Fast and scalable wireless handovers in support of mobile Internet audio", Mobile Networks and Applications 3, 1998, pp. 351-363, 1998. Authors' Addresses O. Henrik Levkowetz A Brand New World Ůster÷gatan 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 Levkowetz, et. al. Expires August 20, 2001 [Page 17] Internet-Draft Why SeaMoby Context Transfer February 2001 Jukka Manner Department of Computer Science, University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki FINLAND 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 Levkowetz, et. al. Expires August 20, 2001 [Page 18] Internet-Draft Why SeaMoby Context Transfer February 2001 Michael Thomas Cisco Systems 375 E Tasman Rd San Jose CA 95134 USA Phone: +1 408 525 5386 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 Appendix A. Context Transfer Issues to Consider Context transfer may come in many flavours and implementations. This section lists some issues that have come to light during the formulation of the problem statement for context transfer. A.1 Selection of a generic architecture for context transfer Two architectures can be discussed here: Centralized Vs Distributed The first architecture assumes a single central entity in the network or in a defined domain, which maintains the updated context information on behalf of a set of access routers and is also responsible for distributing it amongst the potential receivers. This role can be applied, for example, to the access network gateway, an entity like a policy server or an elected access router itself. This approach may suffer with scalability issues as the number of microflow information per mobile per access router could be a very large data to process and transfer in real-time with minimum delays. The second architecture distributes the role of context maintenance Levkowetz, et. al. Expires August 20, 2001 [Page 19] Internet-Draft Why SeaMoby Context Transfer February 2001 and distribution to the access routers itself. This approach seems to be more appropriate as the access routers hold most of the context information (QoS, Policy etc). Moreover, the access router is responsible for the context information or the microflows of the mobiles that are connected through them, which is scalable. A.2 Definition of Sender and Receiver Defining the sender and the potential receiver(s) of the context information and "events" that enable access routers become the members of one "context group": A mobile may have radio connectivity (at least it may receive RF signals) from more than a single AP. The case where the APs are connected to the same access router AR, no context transfer is required but when the potential APs are connected to different ARs, the access routers may expect the mobile's QoS sessions to arrive. These access routers, therefore, become the potential receivers of the context information. A "context group" can be defined as the group of potential access routers in the network that have, or need to have, the context information related to a mobile. There are few issues to resolve in the 'dynamic' formation of a context group; - The addition and deletion of the members to a context group: This could be triggered by certain network events. These events may be network policy/configuration conditions that dictate the access routers to join a context group or could be an event generated by the mobile's movement prediction that dictates an access router to become the member of a context group. - How does a (potential) new member identify the context group associated with the mobile?: This requires an 'identifier' for each context group per mobile and the information of the identifier should be propagated to any potential member of the context group A.3 Transferring the context information - How does a new member of a context group know about the sender of the context? The context information of the mobile are maintained by some access router in the network or in other words, there is one potential sender per context group. The new member needs to know who to contact (within the context group) in order to retrieve the current context. - When should the context information be transferred? Two possible approaches are "reactive" and "proactive or make-before-break". In the later approach, the context information is transferred to any new member as soon as it joins the context group irrespective of the fact that the mobile may not choose the access router for data connectivity. - How updates in the context propagate to the members of the Levkowetz, et. al. Expires August 20, 2001 [Page 20] Internet-Draft Why SeaMoby Context Transfer February 2001 context group, and probably any associated events that trigger the context update need to be understood. A.4 Knowledge of neighbour capabilities In some circumstances, knowledge of neighbouring ARs can lead to better handover strategies, as well as help with load balancing, etc. While not necessary, and possibly undesirable in some cases, it would be useful to have the capability to use topology knowledge when helpful. A.5 Per packet or real-time context information transfer There are pieces of information that an access router calculates and maintains on a per packet basis. Metering in a Diffserv-enabled router is one example of such an information. The context transfer solution must address how and when the per packet information could be transferred between the access routers and what are the trade-offs. For example, for a proactive case, the transferred metering information may become irrelevant or obsolete at the new access router because of the instant of it was last updated and the time when the router really needs this information could be large enough. Even for a reactive transfer mode, by the time the information is propagated to the new access router , it may become obsolete or irrelevant. A.6 Partially Failed Context Transfer [Editor: Rajeev had some comments on this text on Jan 18, these have not been taken into consideration here. Hamid or Rajeev, would you like to propose a changed text, please?] A part of the "definition of context transfer: problem statement" is the fact that the "context information" may not be completely supported by one or more of the receivers of the context. The reason could be a different set of capabilities available at the receivers of the context data, due to which one or more of the "sub-contexts" may not be supported. This may likely to happen in a heterogeneous "context group" where the members of the context group have different set of capabilities. One simple example of such a scenario is failure of admission control due to unavailability of resources required by a "sub-context". The impact could be a service disruption/degradation for one or more sessions of the mobile. The capabilities of a receiver cannot be known without actual transfer of context. The receiver may then decide whether a complete support of the requirements indicated by the "context" is available or not. In case the outcome is negative, there is a chance of service degradation for one or more of the mobile's sessions. Levkowetz, et. al. Expires August 20, 2001 [Page 21] Internet-Draft Why SeaMoby Context Transfer February 2001 The question is whether any solution investigation for this problem falls under "context transfer" activity or is beyond the scope of this forum. To explain it better, two possible scenarios can be considered; 1. There could be a mechanism that prevents a handover of bearer traffic to any receiver of context that provides a partial support to the "transferred context". In this scenario, the definition of such a mechanism really goes out of the context transfer activity. Only a feedback on the outcome of the decision on transferred context could be used to trigger such a mechanism. This scenario really based on the assumptions that all the session of mobile's should be handed over to a single receiver. 2. The second scenario may assume that different sub-contexts of the mobile may be supported by different receivers and therefore, the actual handover of the mobile's session would be done to multiple targets. This scenario may require some decisions to be made at the source access router to which sessions are to be moved to which target based on any feedback from the target access routers. This is a complicated situation and may require a substantial amount of work to be done both on context transfer and "partial handover" of sessions Context transfer may also fail due to imperfect transport, over wired or wireless medium. This also need to be considered in a possible solution. A.7 Different security environments Depending on the design of the security provisioning systems and existing trust relationships (e.g. existence of public key infrastructures or AAA administrative domains), in some handover cases, some of data in the security portion of the context might be available at the target network. However, context transfer might not need to consider these (possibly special) cases and will include all the context data in the context transfer procedure in order to cover more general cases. A.8 Dynamic trust relationships According to the mobile IP model, at many instances, when a mobile moves into a new administrative domain, a re-authentication of the mobile to the new foreign network (and at times to the home network) is necessary. In a AAA based authentication, besides the static trust relationships, that already exist prior to the arrival of the mobile at the edge of each network (such as that between the target network AAA and home network AAA authorities and that between a network mobility agent and its AAA authority), there are Levkowetz, et. al. Expires August 20, 2001 [Page 22] Internet-Draft Why SeaMoby Context Transfer February 2001 relationships that have to be created dynamically. One such relationship is the one needed for re-authentication of MH to the target access agent (may or may not be AP/AR?). The delay involved in re-authentication triggered as a result of a handover might cause considerable and unacceptable latency and loss for many mobile applications. Context transfer seeks to provide a faster mechanism for transfer of the STATIC security and AAA data than those transfer mechanism already available. However, due to the need for creation of dynamic trust relationships, a trade off in favour of seamlessness might lead to security and AAA compromises before completion the handover. A.9 Context Transfer Security Issues Context transfer should include a mutual authentication process, by which the party receiving the context and the party transmitting the context, each provides proof of legitimacy to the other side. Data integrity protection should provided, so that the context information is protected from tampering by a third party. Encryption of context data might be necessary, in case MH location privacy and network topology and policy protection are required. The mechanisms for establishing trust between the two parties involved in context transfer in order to transfer context data securely (as described above) should be provided. The mobile node must ultimately retain control over whether it moves or not, and under what conditions it consents to have a network based move done on its behalf. In particular, the mobile node must have the ability to veto a move that could happen transparently, but may result in higher access charges, unexpected service degradation, loss of privacy, or other policy based exclusions. A.10 Mobile Routers In the case where the MN is actually a mobile network, which may contain it's own wireless Access Points, Access Routers and Mobile-IP entities, there may exist unsolved and even undiscovered issues related to Mobile-IP and mobile routers. A.11 Characteristics of a Context Transfer Transport Protocol Assuming that context transfer is needed, the actual protocol used to implement the transport needs to address some problems found in the micro/macro-mobility environments. It is fairly clear that the context transfer will likely need to be extensible since the context examples given in this draft are diverse and subject to change. It is likely that the context transfer will need to be invoked just Levkowetz, et. al. Expires August 20, 2001 [Page 23] Internet-Draft Why SeaMoby Context Transfer February 2001 prior to handoff decisions, if the very latest version of it is desired. This means that it will need to be efficient and offer a standard method for indicating success and/or failure of the transfer to the caller, which is likely to be a MIP mobility agent or a SeaMoby micro-mobility entity. There are methods that COULD be used to decouple context transfer from mobility. One method COULD involve handoff neighbour ARs periodically updating each other irrespective of the mobile traffic that they are carrying. Another method COULD be to perform neighbour AR update whenever a micro-flow is added or dropped from an AR. This subject has not been debated by the SeaMoby WG to any large extent. Another item of interest is the actual transport protocol used for the context transfer. The merits of reliable versus unreliable, and TCP or SCTP have not been debated extensively by the SeaMoby WG yet. Levkowetz, et. al. Expires August 20, 2001 [Page 24] Internet-Draft Why SeaMoby Context Transfer February 2001 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 Funding for the RFC editor function is currently provided by the Internet Society. Levkowetz, et. al. Expires August 20, 2001 [Page 25]