Seamoby WG J. Loughney (editor) Internet Draft M. Nakhjiri Category: Experimental C. Perkins <draft-ietf-seamoby-ctp-04.txt> R. Koodli Expires: April 7, 2004 September 8, 2003 Context Transfer Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2003. All Rights Reserved. Abstract This document presents a context transfer protocol that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency, packet losses and avoiding re-initiation of signaling to and from the mobile node. Loughney et al. expires March 22, 2004 [Page 1]
Internet-Draft September 23, 2003 Table of Contents 1. Introduction 1.1 Conventions Used in This Document 1.2 Abbreviations Used in the Document 2. Protocol Overview 2.1 Context Transfer Packet Formats 2.2 Context Types 2.3 Context Data Block 2.4 Messages 3. Transport, Reliability and Retransmission of Feature Data 4. Open Issues 4.1 Failure Handling 5. Examples and Signaling Flows 5.1 Network controlled, Initiated by pAR 5.2 Network controlled, Initiated by nAR 5.3 Mobile controlled, Predictive New L2 up/old L2 down 6. Security Considerations 7. IANA Considerations 8. Acknowledgements 9. References 9.1 Normative References 9.2 Non-Normative References Appendix A. Timing and Trigger Considerations Appendix B. Congestion Control Appendix C. Multicast Listener Context Transfer Author's Addresses Loughney et al. expires March 22, 2004 [Page 2]
Internet-Draft September 23, 2003 1. Introduction "Problem Description: Reasons For Performing Context Transfers between Nodes in an IP Access Network" [RFC3374] defines the following main reasons why Context Transfer procedures may be useful in IP networks. 1) The primary motivation, as mentioned in the introduction, is the need to quickly re-establish context transfer-candidate services without requiring the mobile host to explicitly perform all protocol flows for those services from scratch. An example of a service is Context Relocation for Seamless Header Compression in IP Networks [CTHC]. 2) An additional motivation is to provide an interoperable solution that supports various Layer 2 radio access technologies. This document describes a generic context transfer protocol, which provides: * Representation for feature contexts. * Messages to initiate and authorize context transfer, and notify a mobile node of the status of the transfer. * Messages for transferring contexts prior to, during and after handovers. The proposed protocol is designed to work in conjunction with other protocols in order to provide seamless mobility. The protocol supports both IPv4 and IPv6, though support for IPv4 private addresses is for future study. 1.1 Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Abbreviations Used in the Document Mobility Related Terminology [TERM] defines basic mobility terminology. In addition to the material in that document, we use the following terms and abbreviation in this document. CTP Context Transfer Protocol DoS Denial-of-Service Loughney et al. expires March 22, 2004 [Page 3]
Internet-Draft September 23, 2003 FPT Feature Profile Types 2. Protocol Overview This section provides a protocol overview. A context transfer can be either started by a request from the mobile node ("mobile controlled") or at the initiative of either the new or the previous access router ("network controlled"). * The mobile node sends the CT Activate Request to old AR whenever possible to initiate predictive context transfer. In any case, the MN always sends the CTAR message to new AR. If the contexts are already present, nAR would verify the authorization token present in CTAR with its own computation (using the parameters supplied by pAR), and subsequently activate those contexts. If the contexts are not present, nAR requests pAR to supply them using the Context Transfer Request message, in which it supplies the authorization token present in CTAR. * Either nAR or pAR may request or start (respectively) context * transfer based on internal or network triggers (see Appendix B). The Context Transfer protocol typically operates between a source node and a target node. In the future, there may be multiple target nodes involved; the protocol described here would work with multiple target nodes. For simplicity, we describe the protocol assuming a single receiver or target node. Typically, the source node is a MN's Previous Access Router (pAR) and the target node is MN's New Access Router (nAR). Context Transfer takes place when an event, such as a handover, takes place. We call such an event as a Context Transfer Trigger. In response to such a trigger, the pAR may transfer the contexts; the nAR may request contexts; and the MN may send a message to the routers to transfer contexts. Such a trigger must be capable of providing the necessary information, such as the MN's IP address with which the contexts are associated, the IP addresses of the access routers, and authorization to transfer context. Context transfer protocol messages use Feature Profile Types that identify the way that data is organized for the particular feature contexts. The Feature Profile Types (FPTs) are registered in a number space (with IANA Type Numbers) that allows a node to unambiguously determine the type of context and the context parameters present in the protocol messages. Contexts are transferred by laying out the appropriate feature data within Context Data Blocks according to the format in section 2.3, as well as any IP addresses necessary to associate the contexts to a particular MN. The context transfer Loughney et al. expires March 22, 2004 [Page 4]
Internet-Draft September 23, 2003 initiation messages contain parameters that identify the source and target nodes, the desired list of feature contexts and IP addresses to identify the contexts. The messages that request transfer of context data also contain an appropriate token to authorize the context transfer. The Previous Access Router transfers feature contexts under two general scenarios. First, it may receive a Context Transfer Activate Request (CTAR) message from the MN whose feature contexts are to be transferred, or it receives an internally generated trigger (e.g., a link-layer trigger on the interface to which the MN is connected). The CTAR message, described in Section 2.4.1, provides the IP address of nAR, the IP address of MN on pAR, the list of feature contexts to be transferred (by default requesting all contexts to be transferred), and a token authorizing the transfer. It also includes the MN's new IP address (valid on nAR) whenever it is known. In response to a CT-Activate Request message or to the CT trigger, pAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts. This message, described in Section 2.4.2, contains the MN's previous IP address and its new IP address (if known). It also contains parameters for nAR to compute an authorization token to verify the MN's token present in CTAR message. Recall that the MN always sends CTAR message to nAR regardless of whether it sent the CTAR message to pAR. The reason for this is that there is no means for the MN to ascertain that context transfer reliably took place. By always sending the CTAR message to nAR, the Context Transfer Request (see below) can be sent to pAR whenever necessary. In the second scenario, pAR receives a Context Transfer Request (CT Request) described in Section 2.4.5, message from nAR. The nAR itself generates the CT Request message either as a result of receiving the CTAR message or as a response to an internal trigger (that indicates the MN's attachment). In the CT-Req message, nAR supplies the MN's previous IP address, the feature contexts to be transferred, and a token (generated by the MN) authorizing context transfer. In response to CT Request message, pAR transmits a Context Transfer Data (CTD) message that includes the MN's previous IP address and feature contexts. When it receives a corresponding CTD message, nAR may generate a CTD Reply message (See Section 2.4.3) to report the status of processing the received contexts. [1].* contexts, pAR verifies authorization token before transmitting the [2]algorithm [3] When context transfer takes place without the nAR requesting it (scenario one above), nAR requires MN to present its authorization token. Doing this locally at nAR when the MN attaches to it improves performance and increases security, since the contexts are highly likely to be present already. When context Loughney et al. expires March 22, 2004 [Page 5]
Internet-Draft September 23, 2003 transfer happens with an explicit request from nAR (scenario two above), pAR performs such verification since the contexts are still present at pAR. In either case, token verification takes place at the router possessing the contexts. Performing context transfer in advance of the MN attaching to nAR can increase handover performance. For this to take place, certain conditions must be met. For example, pAR must have sufficient time and knowledge about the impending handover. This is feasible, for instance, in Mobile IP fast handovers. Additially, many cellular networks have mechanisms to detect handovers in advance. However, when the advance knowledge of impending handover is not available, or if a mechanism such as fast handover fails, retrieving feature contexts after the MN attaches to nAR is the only available means for context transfer. Performing context transfer after handover might still be better than having to re-establish all the contexts from scratch. Finally, some contexts may simply need to be transferred during handover signaling. For instance, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link is terminated. The messages (CTD and CTDR) that perform the context transfer between the access routers need to be authenticated, so that the access routers can be certain that the data has not been tampered with during delivery. 2.1 Context Transfer Packet Format The packet consists of a common header, message specific header and one or more data packets. Data packets may be bundled together in order to ensure a more efficient transfer. The total packet size, including transport protocol and IP protocol headers SHOULD be less than the path MTU, in order to avoid packet fragmentation. +----------------------+ | CTP Header | +----------------------+ | Message Header | +----------------------+ | CTP Data 1 | +----------------------+ | CTP Data 2 | +----------------------+ | ... | 2.2 Context Types Loughney et al. expires March 22, 2004 [Page 6]
Internet-Draft September 23, 2003 Contexts are identified by context type of Feature Profile Type (FPT), which is a 15-bit number. The meaning of each context type is determined by a specification document and the context type numbers are to be tabulated in a registry maintained by IANA, and handled according to the message specifications in this document. The instantiation of each context by nAR is determined by the messages in this document along with the specification associated with the particular context type. Each such context type specification contains the following details: - Number, size (in bits), and ordering of data fields in the state variable vector which embodies the context. - Default values (if any) for each individual datum of the context state vector. - Procedures and requirements for creating a context at a new access router, given the data transferred from a previous access router, and formatted according to the ordering rules and date field sizes presented in the specification. - If possible, status codes for success or failure related to the context transfer. For instance, a QoS context transfer might have different status codes depending on which elements of the context data failed to be instantiated at nAR. 2.3 Context Data Block The Context Data Block is used both for request and response operation. When a particular feature request is constructed, only the first 4 bytes are typically necessary (See CTAR below). When used for the actual feature context itself, the context data is present, and sometimes the presence vector is present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cxt-Type | Length |P| Feature Profile Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Presence Vector (if P = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / context type-dependent data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Cxt-Type indicates the type of the feature context message itself (such as QoS Context Request, QoS Context Transfer etc.), and Feature Profile Type (FPT) identifies the way the particular feature context is organized. The 'P' bit specifies whether or not the "presence vector" is used. When the presence vector is in use, the Presentation Vector is interpreted to indicate whether particular data fields are Loughney et al. expires March 22, 2004 [Page 7]
Internet-Draft September 23, 2003 present (and, thus, containing non-default values). The ordering of the bits in the presence vector is the same as the ordering of the data fields according to the context type specification, one bit per data field regardless of the size of the data field. The Length field indicates the size of the CDB in 8 octets including the first 4 bytes starting from Cxt-Type. %Notice that the length of %the context data block is defined by the sum of lengths of each data %field specified by the context type specification, plus 4 bytes if the %'P' bit is set, minus the accumulated size of all the context data %that is implicitly given as a default value. 2.4 Messages In this section, a list of the available context transfer message types is given, along with a brief description of their functions. Generally, messages use the following generic message header format. In addition, the CTAR message also contains either the Previous Router's IP address or the New Router's IP address. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Length | V | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Context Data Block (variable size, Section 2.3) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Mobile Node, for which context transfer protocol operations are undertaken, is always identified by its previous IP access address. At any one time, only one context transfer operation per MN may be in progress so that the CTDR message unambiguously identifies which CTD message is acknowledged simply by including the mobile node's identifying previous IP address. The 'V' flag indicates whether the MN's previous address is IPv4 only, IPv6 only or both addresses are present. See below. 2.4.1 Context Transfer Activate Request (CTAR) Message This message is always sent by MN to nAR to request context transfer activation. Even when the MN does not know whether or not contexts are present, the MN sends CTAR message to gain access with nAR. If an Loughney et al. expires March 22, 2004 [Page 8]
Internet-Draft September 23, 2003 acknowledgement for this message is needed, the MN sets the A flag to 1, otherwise the MN does not expect an acknowledgement. This message may include a list of FPT (feature profile types) that require transfer. It may include flags to request reliable transfer. The MN may also send this message to pAR while still connected to pAR. In such a case, the MN includes the nAR's IP address and its new IP address (if known) rather than previous IP address and pAR's IP address. 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=CTAR | Length | V |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous (New) IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous (New) Router IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=Auth-Token| Type Len | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Context Transfer Activate Request (CTAR). Length Variable Reserved Reserved for future use. Must be set to zero by the MN. 'V' flag When set to '00', indicate presence of IPv6 Previous (New) address only. When set to '01' indicate presence of IPv4 Previous (New) Address only. When set to '10' indicate presence of both IPv6 and IPv4 Previous (New) addresses. 'R' bit The MN requests reliable transfer. Replay A value used to make sure that each use of the CTAR message is uniquely identifiable. Loughney et al. expires March 22, 2004 [Page 9]
Internet-Draft September 23, 2003 Authorization Token An unforgeable value calculated as discussed below. This authorizes the receiver of CTAR to perform context transfer. If no context types are specified, then all contexts for the mobile node are requested. When 'V' is 10, the IPv4 address MUST preceed the IPv6 address both for the MN and the access router. Since Context Types clearly define the context including the IP version, context enumeration need not be in any strict order, although it might be natural to outline all the IPv4 contexts followed by IPv6 contexts. The Authorization Token is calculated as: First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context Types))), where Key is the shared secret between the MN and pAR, and Context Types includes all the desired contexts for which the transfer is desired. In the default scenario, the MN implicitly (i.e., even without the knowledge of contexts being present) or explicitly requests transfer of all contexts. 2.4.2 Context Transfer Activate Acknowledge (CTAA) Message This is an informative message sent by the receiver of CTAR to the MN to acknowledge a CTAR message. Acknowledgement is optional, depending on whether the MN requested it. This message may include a list of FPT (feature profile types) that were not transferred successfully. 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=CTAA | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Failed FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4.3 Context Transfer Data (CTD) Message Sent by pAR to nAR, and includes feature data (CTP data). This message should handle predictive as well as normal CT. A reliability flag, R, included in this message indicates whether a reply is Loughney et al. expires March 22, 2004 [Page 10]
Internet-Draft September 23, 2003 required by nAR. Note that the new AR must defend the new Care-of- Address using proxy ARP or Neighbor Discovery. 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=(P)CTD | Length | V |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's New Care-of Address, when Type=PCTD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | Type=Auth | Type Length | Algorithm | Key Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD | Key... | only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V | First Context Data Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Context Data Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When CTD is sent predictively, the supplied parameters including the algorithm, key length and the key itself, allow nAR to compute a token locally and verify against the token present in the CTAR message. As described previously, the algorithm for carrying out the computation of the MN Authorization Token is HMAC_SHA1. The input data for computing the token are: the MN's Previous IP address, the FPT objects and the Replay field. When support for transferring all contexts is requested, a default FPT is used. The Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits. 2.4.4 Context Transfer Data Reply (CTDR) Message This message is sent by nAR to pAR depending on the value of the reliability flag in CTD. Indicates success or failure. 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=CTDR | Length | V |S| Reserved | Loughney et al. expires March 22, 2004 [Page 11]
Internet-Draft September 23, 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ....... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'V' flag When set to '00', indicate presence of IPv6 Previous address only. When set to '01' indicate presence of IPv4 Previous Address only. When set to '10' indicate presence of both IPv6 and IPv4 Previous addresses. 'S' bit When set to one, this bit indicates that all the feature contexts sent in CTD or PCTD were received successfully. Status Code A context-specific return value, present when 'S' is not set to one. 2.4.5 Context Transfer Cancel (CTC) Message If transferring a context cannot be completed in a timely fashion, then nAR may send CTC to pAR to cancel an ongoing CT process. 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=CTC | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4.6 Context Transfer Request (CT Request) Message Sent by nAR to pAR request start of context transfer. This message is sent as a response to CTAR message by the MN. The fields following the Previous IP address of the MN are included verbatim from the CTAR message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Loughney et al. expires March 22, 2004 [Page 12]
Internet-Draft September 23, 2003 | Type=CTREQ | Length | V | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=Auth-Token| Type Len | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Data Block (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'V' bits When set to '00', indicate presence of IPv6 Previous (New) address only. When set to '01' indicate presence of IPv4 Previous (New) Address only. When set to '10' indicate presence of both IPv6 and IPv4 Previous (New) addresses. Replay A value used to make sure that each use of the CTAR message is uniquely identifiable. Copied from CTAR. Authorization Token An unforgeable value calculated as discussed above. This authorizes the receiver of CTAR to perform context transfer. Copied from CTAR. 3. Transport, Reliability and Retransmission of Feature Data CTP runs over UDP using port number <TBD>. Some feature contexts may specify a reliability factor, MAX_RETRY_INTERVAL, which is the length of time that the pAR is allowed to perform retransmissions before giving up on the context transfer for that feature context. The longer the allowed retry interval, the more retransmissions will be possible for that feature context. For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD retransmit an unacknowledged CTD message after waiting for Loughney et al. expires March 22, 2004 [Page 13]
Internet-Draft September 23, 2003 RETRANSMISSION_DELAY milliseconds. This time value is configurable based on the type of network interface; slower network media naturally will be configured with longer values for the RETRANSMISSION_DELAY. Except for the value of the elapsed time field, the payload of each retransmitted CTD packet is identical to the payload of the initially transmitted CTD packet, in order to maintain the ability of the mobile device to present a correctly calculated authentication token. The number of retransmissions, each delayed by RETRANSMISSION_DELAY, depends on the maximum value for MAX_RETRY_INTERVAL as specified by any of the contexts. The value of the Elapsed Time field is the number of milliseconds since the transmission of the first CTD message UDP provides an optional checksum, which SHOULD be checked. If the checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with the status value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in the CTD. 4. Error Codes This section lists error codes used by UDP BAD_UDP_CHECKSUM 0x01 5. Examples and Signaling Flows 5.1 Network controlled, Initiated by pAR MN nAR pAR | | | T | | CT trigger I | | | M | |<------- CTD ----------| E |--------CTAR--------->| | : | | | | | |-------- CTDR -------->| V | | | | | | 5.2 Network controlled, initiated by nAR in 6 MN nAR pAR | | | T | CT trigger | I | | | M | |----- CT Request ----->| Loughney et al. expires March 22, 2004 [Page 14]
Internet-Draft September 23, 2003 E | | | : | |<------- CTD ----------| | | | | V |--------CTAR--------->| | | |----- CTDR (opt) ----->| | | | 5.3 Mobile controlled, Predictive New L2 up/old L2 down CTAR request to nAR MN nAR pAR | | | new L2 link up | | | | | CT trigger | | | | | T |--------CTAR ------->| | I | |---- CT Request ------>| M | | | E | |<-------- CTD ---------| : | | | | | | | V | | | | | | In case CT cannot be supported, a CTAR reject (TBD) may be sent to the MN by nAR. 6. Security Considerations 6.1. Threats. The Context Transfer Protocol transfers state between access routers. If the mobile nodes are not authenticated and authorized before moving on the network, there is a potential for DoS attacks to shift state between ARs, causing network disruptions. Additionally, DoS attacks can be launched from mobile nodes towards the access routers by requesting multiple context transfers and then disappearing. Additionally, a rogue access router could flood mobile nodes with packets, attempting DoS attacks. 6.2. Security Details CTP relies on IETF standardized security mechanisms for protecting traffic between access routers, as opposed to creating application Loughney et al. expires March 22, 2004 [Page 15]
Internet-Draft September 23, 2003 security mechanisms. IPsec MUST be supported between access routers. In order to avoid the introduction of additional latency to context transfer due to the need for establishment of secure channel between the context transfer peers (ARs), the two ARs SHOULD establish such secure channel in advance. If IPSec is used, for example, the two access routers need to engage in a key exchange mechanisms such as IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and IPSec protocols (such as ESP) in anticipation for any upcoming context transfer. This will save time during handovers that require secure transfer of mobile node's context(s). Such SAs can be maintained and used for all upcoming context transfers between the two ARs. Security should be negotiated prior to the sending of context. Furthermore, either one or both of the pAR and nAR need to be able to authenticate the mobile and authorize mobile's credential before authorizing the context transfer and release of context to the mobile. In case the context transfer is request by the MN, a mechanism MUST be provided so that requests are authenticated (regardless of the security of context transfer itself) to prevent the possibility of rogue MNs launching DoS attacks by sending large number of CT requests as well as cause large number of context transfers between ARs. Another important consideration is that the mobile node should claim it's own context, and not some other masquerader. One method to achieve this is to provide an authentication cookie to be included with the context transfer message sent from the pAR to the nAR and confirmed by the mobile node at the nAR. 6.3. IPsec Considerations Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithms to provide per- packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. 7. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the context transfer protocol, in accordance with BCP 26 [RFC2434]. 7.1 Context Profile Types Registry Loughney et al. expires March 22, 2004 [Page 16]
Internet-Draft September 23, 2003 This document authorized IANA to create a registry for Context Profile Types, introduced in this document. For future Context Profile Types, it is recommended that allocations be done on the basis of Designated Expert. The Context Profile Type introduced in this document requires IANA Type Numbers for each set of feature contexts that make use of Profile Types. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. 7.2 UDP Port CTP requires a UDP port assignment. 8. Acknowledgements & Contributors This document is the result of a design team formed by the Working Group chairs of the SeaMoby working group. The team included John Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. Contributors to the Context Transfer Protocol review are Basavaraj Patil, Pekka Savola, and Antti Tuominen. The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful during the creation of this specification. The authors would also like to thank Julien Bournelle, Vijay Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their help and suggestions with this document. 9. References 9.1 Normative References [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- ment Levels", BCP 14, RFC 2119, March 1997. [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 Loughney et al. expires March 22, 2004 [Page 17]
Internet-Draft September 23, 2003 [CT-REQ] G. Kenward et al., "General Requirements for Context Transfer", Internet Draft, Internet Engineering Task Force, Work in Progress. [CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for Seamless Mobility", Internet Draft, Internet Engineering Task Force, Work in Progress. [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet Engineering Task Force. Work in Progress. IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", Internet Engineering Task Force. Work in Progress. [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- load (ESP)", RFC 2406, November 1998. 9.2 Non-Normative References [CTHC] R. Koodli et al., "Context Relocation for Seamless Header Compression in IP Networks", Internet Draft, Internet Engineering Task Force, Work in Progress. [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, Internet Engineering Task Force, RFC 3374, May 2001. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet Engineering Task Force, Work in Progress. Loughney et al. expires March 22, 2004 [Page 18]
Internet-Draft September 23, 2003 [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December, 1998. [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfigura- tion," RFC 2462, December, 1998. Appendix A. Timing and Trigger Considerations Basic Mobile IP handover signaling can introduce disruptions to the services running on top of Mobile IP, which may introduce unwanted latencies that practically prohibit its use for certain types of ser- vices. Mobile IP latency and packet loss is being optimized through several alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP]. Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunc- tion to handovers. This means that the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those pro- tocols become available. Furthermore, some of those optimized mobile IP handover mechanisms (such as BETH) may provide more flexibility is choosing the timing and order for transfer of various context information. Appendix B. Congestion Control Context transfer enables smooth handovers and prevents the need of re-initializing signaling to and from a mobile node after handover. Context transfer takes place between access routers. The goal of congestion control is to prevent congestion by noting packet loss at the transport layer and reducing the congestion con- trol window when packet loss occurs, thus effectively restricting the available in-flight window for packet sending. Additionally, TCP & SCTP deploy slow-start mechanisms at start-up, in order to prevent congestion problems at the start of a new TCP/SCTP session. Loughney et al. expires March 22, 2004 [Page 19]
Internet-Draft September 23, 2003 As some context is time-critical, delays due to congestion control may reduce the performance of mobile nodes; additionally, signaling from the mobile node may be increased if the context transfer of time critical data fails. Therefore, some analysis is needed on the role of congestion control and context transfer. Important considerations should be network- provisioning, intra-domain vs. inter-domain signaling as well as other considerations. A quick analysis follows. It is assumed that intra-domain time-critical context transfer should take no more than one kilobyte, based on existing implementation of some context transfer solutions. Contexts that are significantly larger are assumed not so time critical. For a larger number of users, say one thousand users requesting a smooth handover all in the same second, the total bandwidth needed is still a small fraction of a typical Ethernet, frame relay or ATM link between access routers. So even bursty traffic is unlikely to introduce local congestion. Furthermore, physically adjacent access routers should be within one or two IP hops of each other, so the effects of context transfer should be localized. If transferring real-time contexts triggers congestive errors, the access network may be seriously under- provisioned. In order to handle multiple contexts to be transferred with differing reliability needs, each context has to be considered separately by the sending access router nAR. If a CTD message is retransmitted because the CTDR message was not received in time, then those con- texts that are "too late" are included anyway as part of the retransmitted CTD data, in order to ease the ability to verify the Mobile Authorization Token. Appendix C. Multicast Listener Context Transfer Introduction As an example of how context transfer can improve the performance of IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. MLD state is a particularly good example because every IPv6 node must perform two MLD messaging sequences on the wireless link to establish itself as an MLD listener prior to performing router discovery [RFC2461] or duplicate address detection [RFC2462] or before sending/receiving any application-specific traffic (including Mobile IP handover signaling, if any). The node must subscribe to the All Nodes Multicast Address and the Solicited Node Multicast Address as soon as it comes up on the link. In addition, any application- specific multicast addresses must be re-established as well. Context transfer can significantly speed up re-establishing multicast state Loughney et al. expires March 22, 2004 [Page 20]
Internet-Draft September 23, 2003 by allowing the nAR to initialize MLD for a node that just completed handover; without any MLD signaling on the new wireless link. The same approach could be used for transferring multicast context in IPv4. An approximate qualitative estimate for the amount of savings in handover time can be obtained as follows. MLD messages are 24 bytes, to which the IPv6 header, 40 bytes, and a required Routing Header Type 0, 24 bytes, must be added (because there will be no header compression on the new link), for a total MLD message size of 88 bytes per message per subscribed address. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages per address subscription, since the Report message is unacknowledged. Assuming 2 MLD messages sent per address subscription, the mobile node would need to send a total of 4 MLD messages for the two pre-router discovery multicast addresses (All Nodes Multicast Address and Solicited Node Multicast Address for the link local address). This gives a total of 176 bytes per subscribed address or 352 bytes over the wireless link for both the pre-router discovery multicast addresses. The amount of time saved will, of course, depend on the wireless link bandwidth, but some representative numbers can be obtained by assuming bandwidths of 20 kbps or 100 kbps. The former is approximate for a narrowband 3G cellular link and the latter for a moderately utilized 802.11b WLAN link, both running Voice over IP (VoIP). With these two bit rates, the savings from not having to perform the pre-router discovery mes- sages are 140.8 msec. and 28.2 msec., respectively. If any application-specific multicast addresses were subscribed, the amount of time saved could be substantially more. Considering most ATM-based 3G voice cellular protocols try to keep total voice handover delay less than 40-80 msec., MLD signaling could have a large impact on the performance of inter-subnet VoIP handover. The Protocol The context-specific data field for MLD context transfer included in the CTP Context Data Block message for a single IPv6 multicast address has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix on nAR Wireless Interface + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Loughney et al. expires March 22, 2004 [Page 21]
Internet-Draft September 23, 2003 + Subscribed IPv6 Multicast Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Subnet Prefix on nAR Wireless Interface field contains a subnet prefix that identifies the interface on which multicast routing should be established. The Subscribed IPv6 Multicast Address field contains the multicast address for which multicast routing should be established. The pAR sends one MLD context block per subscribed IPv6 multicast address. Router MLD State Machine Interactions No changes are required in the MLD state machine for the routers. Upon receipt of a CTP Context Data Block for MLD, if the router is in the No Listeners Present state, it transitions to the Listeners Present state for the Subscribed IPv6 Multicast Address on the wire- less interface specified by the Subnet Prefix on nAR Wireless Inter- face and starts its timer, as if it had received a Report message in the No Listeners Present state. If the router is in the Listeners Present state for the multicast address, it remains in that state but restarts the timer, as if it had received a Report message in that state. If more than one MLD router is on the link, a router receiving a MLD context data block SHOULD send a CTP Context Data Block for the Sub- scribed IPv6 Multicast Address and the Subnet Prefix on nAR Wireless Interface to other MLD routers on the link. A router receiving an MLD context data block MAY send a proxy MLD Report message instead, if wireless bandwidth is not an issue. Since MLD routers do not keep track of which nodes are listening to multicast addresses, only whether a particular multicast address is being listened to, proxying the subscription should cause no difficulty. Authors' Addresses Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Rajeev.koodli@nokia.com Loughney et al. expires March 22, 2004 [Page 22]
Internet-Draft September 23, 2003 John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland john.loughney@nokia.com Madjid F. Nakhjiri Motorola Labs 1031 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA madjid.nakhjiri@motorola.com Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA charliep@iprg.nokia.com Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per- tain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Loughney et al. expires March 22, 2004 [Page 23]
