Seamoby Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 20 November 2001 Communication Systems Laboratory Nokia Research Center A Context Transfer Framework for Seamless Mobility draft-koodli-seamoby-ctv6-02.txt 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. This document is an individual submission for the seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the seamoby@cdma_2000.org mailing list. Distribution of this memo is unlimited. Abstract Mobile nodes enhance their connections across wireless media by establishing various kinds of state (context), in order to make practicable, secure, and economical use of the available bandwidth. During handover from one access router to another, a bandwidth-constrained mobile node may need to have state information passed from the previous router to the new one. This document proposes a framework for control structures that enable authorized context transfers. We demonstrate how the proposed framework could be applied for use during handovers so that the applications running on the mobile node could operate with reduced latency, minimal disruption, and reduced packet losses. Koodli, Perkins Expires 20 May 2002 [Page i] Internet Draft Context Transfers 20 November 2001 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 3 3. Data Structure 3 4. Option Types and Packet Formats 6 4.1. Seamless Handover Initiate (SHIN) Destination Option . . 8 4.2. Seamless Handover Acknowledgment (SHAck) Option . . . . . 10 4.3. ICMP Seamless Handover Request option (SHREQ) . . . . . . 11 4.4. ICMP Seamless Handover Reply (SHREP) option . . . . . . . 13 4.5. ICMP Predictive Context Transfer (PCT) option . . . . . . 14 4.6. Seamless Handover Reply Acknowledgment option . . . . . . 15 5. Using Options with Handover Signaling 16 5.1. Basic Handover Signaling: Reactive CT . . . . . . . . . 17 5.2. Fast Handover Signaling: Predictive CT . . . . . . . . . 18 6. Configurable Parameters 20 7. Security Considerations 20 8. IANA Considerations 20 9. Comparison with the Requirements 20 9.1. General Requirements . . . . . . . . . . . . . . . . . . 21 9.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 23 9.3. Transport Reliability . . . . . . . . . . . . . . . . . . 24 9.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 24 9.5. Timing Requirements . . . . . . . . . . . . . . . . . . . 25 9.6. Context Update and Synchronization . . . . . . . . . . . 26 9.7. Interworking with handover mechanisms . . . . . . . . . . 26 9.8. Partial Handover . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments 27 Addresses 29 Koodli, Perkins Expires 20 May 2002 [Page 1] Internet Draft Context Transfers 20 November 2001 1. Introduction When a mobile node undergoes handover from an access router to another, context information pertaining to the mobile node's packet streams needs to be transferred in order to maintain transfer of applications. This seamless operation ensures that the mobile node does not have to re-establish the contexts associated with various features, such as QoS, header compression, security etc. In many instances (e.g., when the mobile node is attached to its access router through a low-bandwidth wireless link) the seamless operation also provides performance benefits, since context establishment typically involves transmission of a considerable amount of data. In this document, we describe a generic context transfer framework which provides 1. an efficient data structure for context information 2. packet formats for encapsulating the context data structure for transfer purposes, and 3. a description of how context transfers can be achieved with handover signaling with the packet format definitions Together, these components form the basis for context transfers. This document does not describe how the target router is selected for context transfer, nor does it explain context transfer (re)negotiation issues. Mobility management protocols outside the scope of this specification could consider the ability of an access router to support desired features when selecting a target router. For our purposes, we assume that the IP address of the target router is supplied to the context transfer framework. Furthermore, it is crucial that context transfers are appropriately aligned with the IP layer handover protocols that determine routing changes for packet forwarding to the MN. Failure to do so results in context state quickly becoming inconsistent. While this is important, context transfers should not depend upon any particular handover mechanism. This can be achieved by separating context definitions from the handover messages. In this document, we make use of concepts outlined earlier in [5, 6, 7]. The protocols specified in those documents do not depend in any essential way on the mobile node's home address, nor on the way that the mobile node's local access IP address can be used as a care-of address for Mobile IPv6. Our proposal is independent of Mobile IP and Mobile IPv6. However, we describe the signaling using the Handover Initiate (HI) and Handover Acknowledge (HAck) messages provided as part of the Fast Handover protocol for Mobile IPv6 in the rest of this document. Furthermore, we have made our Koodli, Perkins Expires 20 May 2002 [Page 2] Internet Draft Context Transfers 20 November 2001 protocol specification to readily make use of recent fast handover designs using ICMP messages instead of IPv6 Destination Options. We believe that the most important time for Context Transfer operations will be as part of high-performance handover operations that attempt to minimize the latency and data loss that have sometimes been associated with handovers using unassisted Mobile IP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119 [2]. We define the following terms for use in this document. We also use Figure 1 as the basis for our handover discussion. GPT Generic Profile Type: a general way to lay out context parameters, which constitute a particular context, for use when describing various feature contexts. ICMP Internet Control Message Protocol IP Access Address An IP address useful for routing packets to a mobile node while it is attached to an access network. New Router The router to which the MN attaches after handover Predictive Same as proactive. Previous Router The MN's default router prior to handover New access address (Naddr) The access IP address of the Mobile Node (MN) when attached to the link served by the New Router Previous access address (Paddr) The access IP Address of the Mobile Node (MN) when attached to the link served by the Previous Router 3. Data Structure There may be multiple features associated with each unidirectional packet stream (also known as a microflow). Examples are QoS, Koodli, Perkins Expires 20 May 2002 [Page 3] Internet Draft Context Transfers 20 November 2001 v +------------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ MN | | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < MN | | +------------+ Figure 1: Reference Scenario for Handover security and header compression. We assume that there is a feature context that is specific for each packet stream. Note that each feature itself may be supported by multiple, co-existing mechanisms. As an example, header compression feature may have separate contexts for IPv6/UDP/RTP and IPv6/TCP compression mechanisms at the same router. Therefore, a feature context may need to specifically refer to the particular mechanism it realizes. One or more feature contexts may belong to a microflow context and multiple microflow contexts together form the overall context for a mobile node. The overall context may also include contexts that are not microflow-specific; e.g., it may include session-specific contexts (such as AAA state) as well. The context hierarchy, consistent with the nomenclature in [9], is illustrated in Figure 2 (where feature realizations through one or more mechanisms are not shown for clarity). From this hierarchy, it is clear that a representation is needed to capture the diversity of features and feature realizations. It is also clear from Figure 2 that a feature context is the unit of data representation for context transfer purposes. Given the diversity of various features and their associated contexts, we recognize the need for a simple representation that provides a generic structure, while allowing each feature to define its own context parameters. We define a Generic Profile Type (GPT) as an object that uniquely identifies the type of a feature context. Koodli, Perkins Expires 20 May 2002 [Page 4] Internet Draft Context Transfers 20 November 2001 +--------------+ | | | Context | | | | | +--------------+ | | +-----------------------------------------+ | | | +------------+ +------------+ +------------+ | | | | | | |Microflow-1 | |Microflow-2 | ... |Microflow-n | | context | | context | | context | | | | | | | +------------+ +------------+ +------------+ | | | +----------+ +----------------+ | | | | | Feature | +----------+ +----------+ |context X | | | | | | | | Feature | | Feature | +----------+ |context Y | |context X | | | | | +----------+ +----------+ Figure 2: Context Hierarchy for a Mobile Node An instance of a GPT defines the parameters associated with the corresponding feature context. For example, a QoS Profile Type (QPT) for Diffserv has to identify the control parameters associated with the QoS feature, and a Compression Profile Type (CPT) for IPv6 has to identify the IPv6 header compression control parameters. The purpose of a GPT is as follows. First, for each feature (and the associated mechanism that is standardized), it provides a definition for the feature context that can be used during handovers. This context would have the necessary and sufficient parameters so that the node receiving the context would be able to immediately (seamlessly) offer the feature subsequent to handover. In other words, the context state captured by each instance of GPT would facilitate feature inter-operability across access routers during handovers. Second, a GPT provides a standard programming object that can be used, e.g., to request context transfer for a feature, Koodli, Perkins Expires 20 May 2002 [Page 5] Internet Draft Context Transfers 20 November 2001 or to initialize feature support. In other words, this object can be used by a mobile node in appropriate programming API and signals. Furthermore, some mobility management protocol may use this object to determine whether a target router supports the desired feature. Finally, we note that each profile type (i.e., instance of the the of the GPT for a specific kind of context feature) has to formalize the state for context transfer purposes individually. As an example, the Compression Profile Type (CPT) for ``IPv6/UDP/RTP/voice/G.723.1'' has to specify all the necessary and sufficient parameters for seamless operation of header compression across handovers. Standardization effort will be needed for the definition of new GPTs. Each feature context itself, then consists of the [GPT, context parameters] tuple along with some generally useful parameters (such as a filter that identifies the packet stream and a handle that allows indexing into the correct feature context). 4. Option Types and Packet Formats Once the data structure for the context parameters is available, appropriate packet formats are needed for communication and processing. ICMP options could be used for inter-access router communication, and IPv6 destination options used for mobile node - access router communication. However, the control structures for these options could be used in other forms of messages as well. This will enable context transfer to be applicable to a variety of scenarios, including fast handovers, paging, ad hoc networks etc. The ICMP options can be used with specific signaling messages, e.g., with fast handover signaling messages, to facilitate context transfer between access routers. The destination options facilitate explicit context authorization before an access router makes the feature contexts available to a MN. For example, the Seamless Handover Initiate (SHIN) option (see below) carries a token that the New Router may verify against its own before granting the contexts to the MN. The SHIN also serves the purpose of fetching the contexts when they are not present at the New Router. The mobile node uses SHIN destination option in appropriate signals. When a suitable signaling message is not available for the mobile node, we assume that an IPv6 packet containing the context transfer destination option is used for communication. Separating context options and the signals (i.e., ICMP message or other control message) used to carry those options provides needed flexibility. ICMP is advantageous because it does not depend on pre-existing associations between peer entities participating in context transfers. Koodli, Perkins Expires 20 May 2002 [Page 6] Internet Draft Context Transfers 20 November 2001 The proposed options should cover mobile node - access router communication as well as communication between access routers. Other network entities may make use of the options we define here in their signals to the access routers or the mobile node itself, but such uses are outside the scope of this specification. The following ICMP options are defined for handling context transfer requirements between access routers. 1. Seamless Handover Request (SHREQ) 2. Seamless Handover Reply (SHREP), and 3. (optionally) Seamless Handover Reply Acknowledgment (SHREP-Ack) All of these options are of the form shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ One or more Feature Context sub options... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Feature Context ICMP Option Format The following IPv6 destination options are defined for the mobile node to request context transfers and process the responses. 1. Seamless Handover Initiate (SHIN) 2. Seamless Handover Acknowledgment (SHAck) The SHIN option serves two purposes. First, it facilitates explicit authorization of feature contexts before an access router makes them available to a MN. It carries an authentication token that an access router could securely verify before making the contexts available to a MN. Second, when the context is not present at an access router, it serves as a trigger for reactive context transfer. In its default form, it consists of MN's Previous IP address, its Previous Router and an authentication token. The SHAck option, on the other hand, is optional. These are general-purpose options that need not be present under certain customizations. For example, when the need for explicit Koodli, Perkins Expires 20 May 2002 [Page 7] Internet Draft Context Transfers 20 November 2001 context authorization is not present in predictive context transfers, it is not guaranteed that the MN will send a SHIN message, or that the access router will issue a SHAck message. In general however, since a MN cannot be certain that the context is always present at its New Router (which consequently may be unaware of MN's Previous Router and its Previous IP address), we argue that the benefit (i.e., the robustness) of including a SHIN option outweighs its cost. Each feature context, represented by the appropriate [GPT, Context Parameters] tuple, is enumerated as a sub option in SHREQ and SHREP options. Thus, each SHREQ and SHREP option contains one or more sub options corresponding to one or more feature contexts (or requests for feature contexts). These specific sub options, not specified in this document, may appear multiple times in the same option whenever needed for different instances of the same GPT. These ICMP options and IPv6 Destination Options will be described in the following sections. 4.1. Seamless Handover Initiate (SHIN) Destination Option The Seamless Handover Initiate destination option is an envelope for containing suboptions, prefixed by some fields that are generally expected to be useful for all suboptions. The sub options enumerate various context transfer requests and optionally supply additional parameters for those sub options. A default sub option may be defined to request all the contexts to be transferred, in which case, there is no need for enumerating individual sub options. The mobile node sends SHIN to the New Router after it establishes connectivity. The mobile node MAY also send this option to the Previous Router whenever appropriate. For example, a MN with two network interfaces may configure its new IP address without its default router having to participate in selecting its new default router. In such a case, the MN could inform its current default router to effect context transfer using the SHIN option. When the mobile node sends it to the Previous Router, this option is called Predictive SHIN or simply P-SHIN. When it sends this option to the New Router, the MN supplies its Previous IP Address and Previous Router address, whereas when it sends it to the Previous Router, it supplies its New IP Address and New Router address. Koodli, Perkins Expires 20 May 2002 [Page 8] Internet Draft Context Transfers 20 November 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len |Op-Type=(P)SHIN| Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous (New) IP Access Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous (New) Router Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| (auth) data to Current Rtr ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len|Feature Data for Prtr(Nrtr) only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Seamless Handover Initiate Destination Option Format Option Type Seamless Handover Initiate (SHIN), Predictive SHIN (P-SHIN). Option Length Variable Reserved Reserved for future use. Must be set to zero by the MN. This is not present in P-SHIN. Replay A value used to make sure that each use of the Seamless Handover Initiate destination option is uniquely identifiable. This is not present in P-SHIN. Authentication Token An unforgeable value calculated as discussed below. This not present in P-SHIN. Suboptions Feature suboptions requesting context transfer included as selected by the mobile node. A Koodli, Perkins Expires 20 May 2002 [Page 9] Internet Draft Context Transfers 20 November 2001 default suboption could include request for all contexts present. In order to make sure that context cannot be lost in response to an erroneous action or malicious request not initiated by the mobile node, authentication is required for the context transfer request. The Authentication Token (Auth) is calculated as follows: Auth = HMAC (Key, input_data) mod 2^32 where HMAC (Key, Data) is defined (see RFC 2104 [8] for details) roughly as follows: HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data)) and MD5 is defined as given in RFC 1321 [10]. The input_data is defined as follows: input_data = HO_features || Replay || Paddr where HO_features includes all the suboption data from the MN to the Previous Router (Prtr), and Paddr is the mobile node's previous IP access address while attached to the network served by Prtr. When all the contexts are already present at the New Router, the New Router itself can verify authentication if it either possesses the token counterpart or the session key used in computing the token. If a mobile node uses the same features and Previous_IP_Address more than 255 times, then the mobile node SHOULD establish a new security association with the Previous Router (Prtr) (i.e., the mobile node's default router at the Previous IP Access Address (Paddr)). 4.2. Seamless Handover Acknowledgment (SHAck) Option The Seamless Handover Acknowledgment (SHAck) option is illustrated in Figure 5. This option MAY be sent from the New (Previous) Router to the mobile node to inform the mobile node about the status of its SHIN message. The acknowledgment MAY contain separate status reports for each relevant feature that was requested. However, unless a failure has occurred, or else otherwise required by a specific feature, SHAck is optional. The mobile node MUST be prepared to process a SHAck option even when no error has occurred. The routers use the messages described in 4.3 and 4.4 to request and obtain context state information. Koodli, Perkins Expires 20 May 2002 [Page 10] Internet Draft Context Transfers 20 November 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Header (NH = DestOpts) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NH = NONE | Hdr Ext Len | Op-Type=SHAck | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options response from Nrtr (Prtr) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Seamless Handover Acknowledgment Option Format 4.3. ICMP Seamless Handover Request option (SHREQ) The Seamless Handover Request (SHREQ) option, illustrated in figure 6, enables the New Router to request that some feature context associated with the mobile node at the Previous Router be sent to the New Router as part of a seamless handover. The option contains suboptions prefixed by the previous and new IP addresses of the mobile node. The New Router MUST copy the suboptions supplied by the MN (in the SHIN message) verbatim starting from the suboption type AuthPrtr. IPv6 fields: Source address The IP address of the New Router Destination Address The IP address of the Previous Router Option Type Seamless Handover Request (SHREQ) Option Length Variable Reserved Reserved for future use, set to zero by New Router. Replay A value used to make sure that each context transfer request by the MN is uniquely identifiable. Authentication Token An unforgeable value calculated as discussed above. Koodli, Perkins Expires 20 May 2002 [Page 11] Internet Draft Context Transfers 20 November 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=SHREQ | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit New IP Address (Naddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Authenticated by MN ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthPrtr| Sub-Option Len| Reserved | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Authentication Token from MN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-options feature data for Prtr only from Nrtr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Seamless Handover Request Option Format Context Transfer Options Data Feature context requests included as selected by the mobile node and the New Router, in the order specified. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message (See Figure 4). If a router transmits a message with SHREQ option, and does not receive a message with SHREP option (see below) within SHREQ_REXMIT_TIME, the router SHOULD retransmit the SHREQ option. This retransmission should be attempted until SHREQ_RETRIES is exceeded. For this reason, all context suboptions are required to be specified in such a way that the effect is the same whether the Previous Router receives them one time or several times as part of the same seamless handover (idempotent behavior). Koodli, Perkins Expires 20 May 2002 [Page 12] Internet Draft Context Transfers 20 November 2001 4.4. ICMP Seamless Handover Reply (SHREP) option The Seamless Handover Reply (SHREP) option, illustrated in Figure 7, allows the Previous Router to send context state associated with the mobile node to the New Router as a part of seamless handover. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=SHREP | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit New IP Address (Naddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Seamless Handover Reply Option Format Option Type Seamless Handover Reply (SHREP) Option Length Variable Context Transfer Options Data Feature contexts (enumerated as suboptions) for each corresponding suboption present in the SHREQ option in the order specified. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message (See Figure 4). Because of retransmissions, the New Router may receive the same SHREP option and suboptions several times as part of the same seamless handover. Therefore, all context suboptions are required to be specified in such a way that the effect is the same whether the New Router receives them one time or several times in a SHREP message as part of the same seamless handover. Koodli, Perkins Expires 20 May 2002 [Page 13] Internet Draft Context Transfers 20 November 2001 4.5. ICMP Predictive Context Transfer (PCT) option The Predictive Context Transfer (PCT) option, illustrated in Figure 8, allows the Previous Router to send context state associated with the mobile node to the New Router as a part of seamless handover. The Previous Router uses this option to effect context transfers in a predictive fashion, e,g, during predictive context transfers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=PCT | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit New IP Address (Naddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Options Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SOType=AuthTken| Sub-Option Len| Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Predictive Context Transfer Option Format Option Type Predictive Context Transfer (PCT) Option Length Variable Context Transfer Options Data Individual feature contexts in the form of sub options. These are encoded in Sub-Option Type and Sub-Option Length format, as in the structure of SHIN message (See Figure 4). Algorithm 8-bit algorithm indication for computing the Authentication Token (See Section 4.1). Default is HMAC with MD5. Koodli, Perkins Expires 20 May 2002 [Page 14] Internet Draft Context Transfers 20 November 2001 Key Length 8-bit unsigned integer. The length of the key in units of 4 octets. Key Encrypted key. The Key is encrypted using a pre-existing shared key between the Previous Access Router and New Access Router. The PCT option should be viewed as a variation of the SHREP option, and many of the processing rules are the same. For instance, again because of retransmissions, the New Router may receive the same PCT option and suboptions several times as part of the same seamless handover. Therefore, all context suboptions are required to be specified in such a way that the effect is the same whether the New Router receives them one time or several times in a PCT message as part of the same seamless handover. When the New Router receives PCT option, it obtains the session key that the MN uses in computing the authentication token in the SHIN option. The New Router MUST use this session key in computing its own token to verify the one supplied by the MN in SHIN option. The New Router could also use this key to grant network access authentication itself. This procedure is explained in [4] for IP Paging. 4.6. Seamless Handover Reply Acknowledgment option The New Router MAY use the SHREP-Ack option shown in Figure 9 to acknowledge individual sub options received in SHREP or PCT. Option Type (Unsolicited) Seamless Handover Reply Ack (SHREP-Ack). Option Length Variable `S' bit When set to one, this bit indicates that all the feature contexts sent in SHREP or PCT were received successfully. Reserved Set to zero. Context Transfer Options Data Feature suboptions acknowledgments appropriate for each suboption present in SHREP or PCT. Each suboption is an 8-bit integer that indicates an error code corresponding to (successful or otherwise) receipt of a feature context. The order Koodli, Perkins Expires 20 May 2002 [Page 15] Internet Draft Context Transfers 20 November 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=SHREP-Ack | Length |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit New IP Address (Naddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128-bit Previous IP Address (Paddr) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Transfer Acknowledgment Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Seamless Handover Reply Ack Option Format of the suboptions must be the same as the order in which the feature contexts are enumerated in SHREP or PCT message. These suboptions are only present when the "S" bit is not set to one. 5. Using Options with Handover Signaling This section specifies the use of destination options and ICMP options described in the previous sections with handover signaling. There are two types of signaling for context transfer purposes. Sometimes, the context transfer takes place without being requested by the New Router. In this scenario, the Previous Router, perhaps in response to a request from the mobile node (or some other network entity), sends options containing context information to the New Router without explicit request from the latter. Such a transfer could take place before the mobile node even attaches to the New Router, so that the desired context could be utilized as soon as the mobile node obtains new IP connectivity. The New Router MUST acknowledge this predictive context transfer. Other times, the context transfer takes place as a reaction to explicit signaling from the mobile node after it attaches to its New Router. In this case, the New Router explicitly sends a context transfer request to the Previous Router. This scenario can be considered as an extension to the basic handover signaling. This can also be considered as a fallback approach when the fast handover Koodli, Perkins Expires 20 May 2002 [Page 16] Internet Draft Context Transfers 20 November 2001 signaling (or the predictive approach) experiences a failure, as explained in the next section. 5.1. Basic Handover Signaling: Reactive CT After the mobile node formulates a new IP access address, it sends a message containing SHIN option shown in Figure 4 to the New Router. This message is named by the option it carries, i.e., SHIN. Alternatively, the SHIN option could be carried in any other appropriate message; for example, it could be embedded in a network access authentication message [1]. When the New Router (Nrtr) receives this SHIN message, it identifies the suboptions within the SHIN and constructs a new message for the Previous Router to request context handover. In the default case, there would be no sub options present, indicating the MN's desire to request all the contexts. This message, called the Seamless Handover Request (SHREQ) message (i.e., the message containing the SHREQ option), is described in section 4.3 and MUST use IPsec AH for assurance of integrity and authorization. When the Previous Router (Prtr) receives the SHREQ message, it MUST check to see whether it has a security association with the New Router. If so, the Previous Router MUST check for the presence and validity of an IPv6 Authentication Option [3]. Then the Previous Router MUST check for the presence and validity of the Authentication Token supplied by the mobile node to make sure that the context transfer has been authorized by the mobile node. The Previous Router then constructs a Seamless Handover Reply (SHREP) message that would contain appropriate structures for the context transfer. Indeed, this message would contain enumerated ICMP sub options corresponding to various feature contexts. Furthermore, Previous Router establishes a tunnel, and begins to forward packets arriving at the MN's previous IP address to the MN's new IP address. These operations are illustrated in Figure 10. It is important that context for the mobile node be not destroyed at the Previous Router without authorization. Hence, after sending the requested state to the New Router in the SHREP message, the Previous Router has to keep the context data for the mobile node intact for CONTEXT_SAVE_TIME. This would allow recovery in case a SHREP message is lost and not received by the router sending the SHREQ message. The Previous Router SHOULD not perform garbage collection of context data until CONTEXT_PURGE_TIME. Koodli, Perkins Expires 20 May 2002 [Page 17] Internet Draft Context Transfers 20 November 2001 +----------+ 2. SHREQ +----------+ | | <--------- | | | | | | | Prtr |-----------------| Nrtr | | | | | | | ---------> | | +----------+ 3. SHREP +----------+ | ^ | | | | ~~ 1. SHIN| ~~ | V V +-+ +-+ | | movement | | +-+ -------> +-+ Figure 10: Context Transfer with Basic Handover Signaling 5.2. Fast Handover Signaling: Predictive CT In the predictive context transfer scenario, the Previous Router uses the PCT option along with a suitable signaling message, such as the HI message [12]. The trigger for this predictive option MAY arrive in the form of Predictive SHIN (P-SHIN) that the mobile node sends while still being attached to the Previous Router. However, any other authentic trigger could generate context transfer using the PCT option. For example, the trigger for PCT option could come from some trusted network entity. See Figure 11. If the MN sends a P-SHIN option, it MUST NOT compute the authentication sub option shown in Figure 4. The MN already shares a security association with the Previous Router, making the use of IPSec authentication header for the message containing SHIN option sufficient. In order for the predictive context transfer operation to be secure, the Previous Router MUST have a security association with the New Router, and it MUST include an IPv6 Authentication Header in the message containing PCT option. When the New Router receives a HI message with PCT option, it MUST check for the presence and validity of an IPv6 Authentication Header using the security association it has with the Previous Router. In order to characterize the option as a PCT, a new type is defined for use in the HI message. When the Koodli, Perkins Expires 20 May 2002 [Page 18] Internet Draft Context Transfers 20 November 2001 +----------+ +----------+ | | | | | | | | | Prtr |-----------------| Nrtr | | | | | | | ---------> | | +----------+ 2. PCT +----------+ | ^ ^ | | | | | ~~ | 1.``Trigger'' | ~~ | 3. SHIN| V V +-+ +-+ | | movement | | +-+ -------> +-+ Figure 11: Context Transfer with Fast Handover Signaling New Router receives a valid PCT option, it MUST maintain the contents in the option for at least PRED_CT_TIME, or until it receives the corresponding SHIN message from the mobile node whichever event occurs first. When the mobile node sends a SHIN to a New Router that has received a PCT from the Previous Router, the New Router can immediately complete all necessary context transfers. The MN sends a SHIN to the New Router in order to facilitate the authorization of received contexts. Such a SHIN message, as described earlier, would contain the authentication token covering all the contexts that the mobile node is interested in. The New Router MUST compute its own checksum using the key supplied in the PCT option and compare it against authentication token supplied by the MN prior to activating the contexts. Subsequently, the New Router MAY send a SHAck message to the MN. If, due to failure, context is not present at the New Router, this SHIN message would trigger reactive context transfer by requiring the New Router to send a SHREQ message. Koodli, Perkins Expires 20 May 2002 [Page 19] Internet Draft Context Transfers 20 November 2001 6. Configurable Parameters Every access router supporting the mobility extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears. Parameter Name Default Value Definition ------------------- ---------------------- ------- SHREQ_RETRIES 3 Section 4.3 SHREQ_REXMIT_TIME 1 seconds Section 4.3 CONTEXT_SAVE_TIME 2 * SHREQ_REXMIT_TIME Section 5.1 CONTEXT_PURGE_TIME 5 * SHREQ_REXMIT_TIME Section 5.1 PRED_CT_TIME 3 seconds Section 5.2 7. Security Considerations The Previous Router and the New Router MUST use authentication for messages carrying SHREQ, SHREP and PCT; the exact algorithms employed will depend on their security association. In addition, when Previous Router uses PCT option, it MUST encrypt the Key using a pre-existing shared secret with the New Router. Since authentication data is supplied by the mobile node along with its smooth handover requests, there is substantially no danger of loss of handover context due to malicious attacks. However, if the mobile node fails to change its security association with the Previous Router (as specified in section 4.1), an attacker could keep track of all 256 available replay protection values and cause a future disconnection the next time the mobile node acquires the same care-of address at the same Previous Router. 8. IANA Considerations The Generic Profile Type introduced in this document requires IANA Type Numbers for each set of feature contexts that make use of Profile Types. 9. Comparison with the Requirements In this section, we compare the solution we have proposed against the requirements specified in [11]. Koodli, Perkins Expires 20 May 2002 [Page 20] Internet Draft Context Transfers 20 November 2001 9.1. General Requirements 1. ``The context transfer solution MUST define the characteristics of the IP level trigger mechanisms that initiate the transfer of context.'' The SHIN option specified in Section 4.1 can be used as a general-purpose IP trigger to initiate context transfer. For instance, when the MN's access router recognizes that the MN has terminated the link connection (through a link layer specific mechanism for example), an ``upcall'' containing essentially the SHIN structure can be made to the context transfer process that then begins the actual transfer process. The essential elements of the IP trigger would include the IP address of the MN's target access router, the MN's new IP address and an enumeration of various feature contexts that need to be transferred. The default case, that needs no enumeration, allows transfer of all feature contexts. The authentication sub option need not be present for an ``internal'' trigger. 2. ``The IP level context transfer triggers MAY be initiated by a link level (layer two) event.'' The proposal in this document would inter-work with link layer triggers (if and when used). 3. ``The IP level trigger mechanisms for context transfer MUST hide the specifics of any layer 2 trigger mechanisms.'' The SHIN option specified is independent of any link layer trigger. 4. ``The IP level context transfer triggers MAY be initiated by IP level (layer three) signaling.'' The SHIN option specified in this document can be carried in any appropriate IP signaling message, such as a Fast Binding Update [12], or in an IP message of its own. 5. ``Any IP level signalling for Context Transfer MUST be separated from the actual transfer of context.'' The SHREP and PCT options and messages, which carry the feature contexts, are different from SHIN. 6. ``The context transfer solution SHOULD support one-to-many context transfer.'' Koodli, Perkins Expires 20 May 2002 [Page 21] Internet Draft Context Transfers 20 November 2001 The source access router can use the SHREP or PCT envelope to send multiple unicast messages or a single multicast message when there are multiple receivers for the feature contexts. 7. ``The context transfer solution MUST support context transfer before, during and after handover.'' In this document, we specifically describe how context transfer can be performed during and after handovers. The ``Predictive Context Transfer'' message can be used prior to actual handover. 8. ``The context transfer solution MUST support a distributed approach in which the Access Routers act as peers during the context transfer.'' In this document, the access routers transfer appropriate contexts. These contexts are typically those that are created locally on the access router. If contexts present elsewhere need to be transferred by using the access routers, a separate protocol outside the scope of this document would be needed to glean all the relevant contexts and make them available to the source access router. 9. ``The entities transferring context MUST have completed a mutual authentication process prior to initiating the transfer.'' Our protocol does not propose dynamically establishing mutual authentication between the context transfer entities. Mechanisms outside the scope of this document would be needed to establish the necessary security associations between the context transfer peers. 10. ``The context transfer solution SHOULD provide mechanisms to selectively enable or disable context transfer for particular IP microflows or groups of IP microflows.'' The SHIN structure allows enumeration of only those feature contexts for which transfer is desired. 11. ``Context information MAY be transferred in phases.'' The ``SHREP'' or ``PCT'' message can be used in phases. 12. ``The context information to be transferred MUST be available at the AR performing the transfer, prior to the initiation of a given phase of the context transfer.'' Koodli, Perkins Expires 20 May 2002 [Page 22] Internet Draft Context Transfers 20 November 2001 Since we only consider all contexts to be local to the AR, we expect it to be available during all phases of context transfer. 13. ``The context information provided for transfer MUST be reliable.'' Since an access router creates the context, we expect it to be genuine and reliable. Since it is reasonable to expect that the MN was making use of the feature (e.g., QoS, header compression etc), the context itself on the access router must be useful. Furthermore, since our protocol does not introduce any operations on the context itself, we anticipate no scenarios that would malform an otherwise genuine, useful and reliable context. 14. ``The context transfer solution MUST include methods for interworking with any IETF IP mobility solutions.'' The proposed protocol readily interworks with Fast Handovers proposed in Mobile IP working group. See Section 5.2. The proposed protocol also interworks with base Mobile IP protocol itself. See Section 5.1. 15. ``The context transfer solution MAY include methods for interworking with non-IETF mobility solutions.'' While this should be possible, we do not have experiences to report here. 9.2. Protocol Requirements 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.'' The proposed protocol allows for sending all or a subset of feature contexts necessary to support the MN's traffic. Specifically, the sub option structure allows for one or more feature contexts to be uniquely identified and included in context transfer. 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.'' Koodli, Perkins Expires 20 May 2002 [Page 23] Internet Draft Context Transfers 20 November 2001 The concept of ``Generic Profile Types'' introduced in this proposal is powerful and versatile in capturing the meaning of context information to enable inter-operability. We expect each feature to define its own set of Feature Profile Types that uniquely define the content and interpretation of individual feature contexts. 3. ``The context transfer protocol MUST operate autonomously from the content of the context information being transferred.'' There is nothing proposed in this document that would contradict the above requirement. In other words, the proposed protocol does not operate in any context-specific manner. 4. ``The context transfer protocol design MUST define a standard method for labeling each feature context being transferred.'' Each feature would define a set of ``Feature Profile Types''. A ``Feature Profile Type'', such as a QoS Profile Type (QPT) would define the unique characteristics of each instance of the feature. For instance, a Compression Profile Type for IPv6/UDP/RTP-voice-G.723.1 would define all the necessary and sufficient context parameters for the associated feature. This CPT, which would be an IANA assigned type number, would precede the associated context parameters in each transferred context. 5. ``The context transfer protocol design MUST provide for the future definition of new feature contexts.'' New ``Feature Profile Types'' can be defined as necessary. 9.3. Transport Reliability 9.4. Security 1. ``The protocol MUST provide for "security provisioning".'' We expect the ARs involved in context transfer to share appropriate security associations. Such security associations may be set up by means outside the scope of the context transfer protocol. However, our protocol provides for context authorization mechanism so that only an authorized MN is allowed to make use of the transferred contexts. Koodli, Perkins Expires 20 May 2002 [Page 24] Internet Draft Context Transfers 20 November 2001 2. ``The security provisioning for context transfer MUST NOT require the creation of application layer security.'' We do not propose application layer security. 3. ``The protocol MUST provide for the security provisioning to be disabled.'' It is up to an appropriate authority to decide whether security provisioning should be enabled or disabled. The protocol does not specifically require the presence or absence of security provisioning. 9.5. Timing Requirements 1. ``A context transfer MUST complete with a minimum number of protocol exchanges between the source AR and the rest of the ARs.'' Our protocol proposes two messages to accomplish context transfer. When contexts are transferred before the MN attaches to the new AR, there is a predictive transfer and acknowledge message sequence. When context transfer takes place after the MN attaches to the new AR, there is context request and context reply message pair. 2. ``The context transfer protocol design MUST minimize the amount of processing required at the sending and receiving Access Routers.'' The amount of processing needed at the sending router is limited to collecting all the relevant contexts for transfer and labeling each context with an appropriate Profile Type, and computing authentication data. The amount of processing at the receiving router is limited to parsing the received contexts using the Profile Types, verifying authentication data and installing the contexts in local memory. 3. ``The Context Transfer protocol MUST meet the timing constraints required by all the feature contexts.'' It is important to recognize that the context state refers to a MN's packet flows. When the packet flows change network path due to handover, it is important to synchronize context transfer with handover epoch. This would ensure not only that the contexts would be present when needed, but also guarantee that the transferred state Koodli, Perkins Expires 20 May 2002 [Page 25] Internet Draft Context Transfers 20 November 2001 is not stale. Our context transfer protocol is designed to operate together with handover signaling. This allows for contexts to be present ``in-time''. 4. ``The context transfer solution MUST provide for the aggregation of multiple contexts.'' The proposed sub option structure is meant for collecting all the possible feature contexts to be transferred in a single message. The sending AR scans and collects all the feature contexts associated with the MN while constructing the SHREP or PCT option. This ensures the most feature context aggregation prior to transferring the message. 9.6. Context Update and Synchronization 1. ``The context transfer protocol MUST be capable of updating context information when it changes.'' We do not propose this in our current protocol. However, the PCT message can be used at any appropriate time to accomplish context updates. 2. ``A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR.'' We do not propose replicating the contexts at multiple ARs when the MN is connected to a single AR. Thus, we do not have to address this requirement. 9.7. Interworking with handover mechanisms 1. ``The context transfer protocol MAY provide input to the handover process.'' In our protocol, the context transfer protocol obtains input from the handover process to effect context transfer. 2. ``The context transfer protocol MUST include methods for exchanging information with the handover process.'' We expect a separate Candidate Access Router discovery protocol to assist the context transfer protocol in determining the target AR. We expect such a discovery protocol to also assist the handover process. Koodli, Perkins Expires 20 May 2002 [Page 26] Internet Draft Context Transfers 20 November 2001 9.8. Partial Handover 1. ``The context transfer protocol MAY provide a mechanism for supporting partial handovers.'' We do not propose distributing the subsets of contexts to multiple ARs. However, if a Candidate Access Router discovery protocol provides more than one target and the required contexts for each target AR, our protocol does not inhibit such a transfer. 10. Acknowledgments We thank all our colleagues at Nokia Research Center in Mountain View, CA. Many thanks to John Loughney for reviewing this draft and comparing it against the requirements. References [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [4] R. Koodli and Malinen J. Idle Mode Handover Support in IPv6 Networks(work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-idle-mode-ct-00.txt, July 2001. [5] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-fastv6-01.txt, October 2000. [6] R. Koodli and C. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt, November 2000. Koodli, Perkins Expires 20 May 2002 [Page 27] Internet Draft Context Transfers 20 November 2001 [7] R Koodli, C.E. Perkins, and M. Tiwari. Context Relocation for Seamless Header Compression in IP Networks (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-seamoby-hc-relocate-01.txt, July 2001. [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [9] O. Levkowetz and et al. Problem Description: Reasons For Doing Context Transfers Between Nodes in an IP Access Network (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-seamoby-context-transfer-problem-stat-00.txt, February 2001. [10] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. [11] H. Syed and et al. General Requirements for Context Transfer(work in progress). Internet Draft, Internet Engineering Task Force, March 2001. [12] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in progress). Internet Draft, Internet Engineering Task Force. draft-designteam-fast-mipv6-01.txt, February 2001. Koodli, Perkins Expires 20 May 2002 [Page 28] Internet Draft Context Transfers 20 November 2001 Addresses Questions about this memo can be directed to the authors: Rajeev Koodli Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Perkins Expires 20 May 2002 [Page 29]