Seamoby WG J. Loughney (editor) Internet Draft M. Nakhjiri Category: Standards Track C. Perkins
<draft-ietf-seamoby-ctp-01.txt>draft-ietf-seamoby-ctp-02.txt R. Koodli Expires: SeptemberDecember 2003 MarchJune 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 allows better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reducing latency, packet losses and avoid re-initiation of signaling to and from the mobile node. Table of Contents 1. Introduction 1.1 Conventions Used in This Document 1.2 AbbreviationAbbreviations Used in the Document 2. Protocol Overview 2.1 Context Transfer Packet FormatFormats 2.2 Context Types 2.3 Context Data Block 2.4 Messages 3. Transport Considerations 3.1 Congestion Control 3.2 Transport ProtocolsTransport, Reliability and Retransmission of Feature Data 4. Open Issues 4.1 Reliability 4.2 Transport 4.3Failure Handling 4.4 Zone of Operationti -5 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 5.4 Mobile controlled, Reactive CT 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. Simplified Example Context Type Specification Appendix B. Timing and Trigger Considerations Appendix C. Congestion Control Appendix D. Zone of Operation Author's Addresses 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. 2) An additional motivation is to provide an interoperable solution that works for any Layer 2 radio access technology. Access Routers typically establish state in order to effect certain forwarding treatments to packet streams belonging to nodes sharing the access router. For instance, an access router may establish an AAA session state and a QoS state for a node's packet streams. When the link connecting a mobile node and the access router is bandwidth-constrained,bandwidth- constrained, the access router may maintain header compression state on behalf of the mobile node. When such a node moves to a different access router, this state or context relocation during handover provides many important benefits, including: * Seamless operation of application streams. The handover node (i.e.,i.e., the Mobile Node) does not need to re-establish its contexts from scratch at the new access router * Performance benefits. When contexts need to be reestablished, performance of transport protocols would suffer until the contexts are in place. For instance, when the required QoS state is not present, a stream's packets would not receive the desired per-hop behavior treatment, subjecting them to higher likelihood of unacceptable delays and packet losses. * Bandwidth savings. Re-establishing multiple contexts over an expensive, low-speed link can be avoided by relocating contexts over a potentially higher-speed wire. * Reduced susceptibility to errors, since much more of the protocol operates over reliable networks, replacing renegotiations over a potentially error-prone link. In ,[RFC3374], a detailed description of motivation, the need and benefits of context transfer are outlined. In this document, we describe 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. 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 .RFC 2119 [RFC2119]. 1.2 AbbreviationAbbreviations Used in the Document AR Access Router CT Context Transfer CTP Context Transfer Protocol DoS Denial-of-Service FPT Feature Profile Types MIP Mobile IP MN Mobile Node nAR New Access Router pAR Previous Access Router SA Security Association 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 can sendsends the CT start requestActivate Request to old or new AR. The former is preferredAR whenever possible. Sendingpossible to initiate predictive context transfer. In any case, the requestMN always sends the CTAR message to new AR. If the contexts are already present, nAR would add extra latency sinceverify the new AR, itself, after processingauthorization token present in CTAR with its own computation (using the MN's request will needparameters supplied by pAR), and subsequently activate those contexts. If the contexts are not present, nAR requests pAR to request context transmission from pAR.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 MN will send a context transfer request to the pAR (including proper authentication material). After checking authentication, pAR starts the context transfer procedure. TheContext 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). We assume that pAR and nAR share an appropriate security association, set up independently and prior to context transfer. Any appropriate mechanism may be used in setting up this security association; it enables the CT peers to utilize a secure channel for transferring contexts, providing authentication, integrity, and (if needed) confidentiality. 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 NARnAR may request contextscontexts; and the MN may send a message to the PARrouters 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 ContextFeature Profile Types that identify the way that data is organized for the particular feature contexts. The ContextFeature Profile Types (CPTs)(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 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 actuallyrequest 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 StartActivate Request (CTSR)(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 CTSRCTAR message, described in Section 2.4.1, provides the IP address of NAR,nAR, the IP address of MN on PAR,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)nAR) whenever it is known. In response to a CT-StartCT-Activate Request message or to the CT trigger, PARpAR 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 (whenever(if known). It also includes a key, and an indicationcontains parameters for nAR to use a particular algorithmcompute an authorization token to assist NAR in computing averify the MN's token present in CTAR message. Recall that the MN always sends CTAR message to nAR regardless of whether it could usesent the CTAR message to check authorization priorpAR. The reason for this is that there is no means for the MN to makingascertain that context transfer reliably took place. By always sending the contexts availableCTAR message to nAR, the MN.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 CTSRCTAR 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 (typically generated(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. In this "reactive" transfer of contexts, PAR verifies authorization token before transmitting the contexts, and hence does not include the key and the name of algorithm in the CTD message.When context transfer takes place without the nAR requesting it (scenario one above), nAR should require MN to present its authorization token. Doing this locally at nAR when the MN attaches to it improves performance, since the contexts are highly likely to be present already. When context transfer happens with an explicit request from NARnAR (scenario two above), pAR performs such verification since the contexts are still present at pAR. In either case, token verification takes place at the noderouter possessing the contexts. Performing context transfer in advance of the MN attaching to NARnAR clearly has potential for better performance. For this to take place, certain conditions must be met. For example, PARpAR must have sufficient time and knowledge about the impending handover. This is feasible for instance in Mobile IP fast handovers. 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 NARnAR 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. Transfer of such contexts must be properly synchronized with appropriate handover messages, such as Mobile IP (Fast) Binding Update. 2.1 Context Transfer Packet FormatThe packet consistsmessages (CTD and CTDR) which 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. This is especially true since there is no requirement that the access routers be attached to any common network link, so that they can be more than one hop apart in the access network. This requires that the access routers have an established security association. Establishing such security associations is much easier within a single network domain, but this document does not restrict the context transfer signaling to happen only within a single domain. Instead, the requirement it places is that the access routers need to have a security association. 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 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 Contexts are identified by context type, which is a 32-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. Appendix A contains an example context type specification for UDP/RDPUDP/RTP header compression context. 2.3 Context Data Block 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V| Context Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Presence Vector (if V = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / context type-dependent data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'V' bit specifies whether or not the "presence vector" is used. When the presence vector is in use, the next 32 bits are interpreted to indicate whether particular data fields are 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. 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 'V' 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: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |reserve| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of AddressIP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / message data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Mobile Node, for which context transfer protocol operations are undertaken, is always identified by its previous care-ofIP access address. At any one time, only one context transfer operation may be in progress so that the CTDR message unambigously identifies which CTD message is acknowledged simply by including the mobile node's identifying previous care-ofIP address. 2.4.1 Context Transfer StartActivate Request (CTSR)(CTAR) Message SentAlways sent by MN to nAR to request start ofcontext transfer.transfer activation. It is for further to study to see if when the CTSRCTAR message is sent by the MN to the nAR, it should also be relayed to pAR. Acknowledgement is optional, since the MN may have already moved and may not receive the reply. This message may include a list of FPT (feature profile types) that require transfer. It may include flags to request secure and/or 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). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |reserve| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-ofIP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Router IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=Auth-Token| Type Len | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Type (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Type (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message data for CTSRCTAR is the Mobile Node's Previous Care-ofIP Address, Previous Router's IP address, MN Authorization Token, followed by a list of context types. If no context types are specified, then all contexts for the mobile node are requested. 2.4.2 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 required by nAR. This message SHOULD be protected by use of IPsec Authentication Header (AH)[RFC2402] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |C|R|rsv| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization TokenElapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's New Care-of Address, if C=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Auth | Type Length | Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First Context Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Context Block | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MNAuthorization Tokentoken type field is computed over the binary data representedpresent in the Context Data BLockspredictive scenario only. The supplied parameters, algorithm, key length and the key itself, allow nAR to compute a token locally depending on the contents of the CTDCTAR message. The binary data is laidalgorithm for carrying out asthe fully specified ordered sequencecomputation of the MN Authorization Token is HMAC_SHA1. The input data fields according tofor computing the defining context specification, as if there were no presence vectortoken are: the MN's Previous IP address, the FPT objects and therefore no implicitly supplied default values. Sincethe mobile nodeReplay field. When support for transferring all contexts is expected to knowrequested, a default FPT is used. The Authorization Token is obtained by truncating the precise contentsresults of the context dataHMAC_SHA1 computation to be transferred, andretain only the pAR is expected to know the security parameters and algorithm used by the mobile node to compute the authorization token, the token can be supplied by pAR on behalf of the mobile node.leading 32 bits. 2.4.3 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. This message SHOULD be protected by use of IPsec Authentication Header (AH)[RFC2402] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |C| rsv | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The OverallStatus is used for reporting overall success or failure, which could be based on verification of the MN authorization token for instance. For certain values of the overall status, it may be that some contexts were successfully transferred and some failed to be transferred. In this case, then for each context another status code MUST be provided to indicate to pAR which contexts have failed and which have succeeded, along with the reason. 2.4.4 Context Transfer Cancel (CTC) Message If transfering a context requires an ongoing process (i.e., is not short-lived), 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | rsv | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4.5 Context Transfer Request (CT Request) Message Sent by nAR to pAR request start of context transfer. This message is sent as a response to CTSRCTAR message by the MN. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |reserve| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node's Previous Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=Auth-Token| Type Len | Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Context Type (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Requested Context Type (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message data for CT Request is the Mobile Node's Previous Care-of Address, MN Authorization Token, followed by a list of context types. If no context types are specified, then all contexts for the mobile node are requested. The MNfields including and following the Authorization Token Type are inserted from the CTAR message. The algorithm for carrying out the computation is HMAC_SHA1. The Authorization token is computedobtained by laying out alltruncating the context data accordingresults of the HMAC_SHA1 computation to retain only the specifications given withinleading 32 bits. The input data for computing the Context Type document, without any abbreviation or implicit specification astoken are: the MN's Previous IP address, the FPT objects and the Replay field. When support for default values. 3. Transport Considerations Ittransferring all contexts is not the intention of this work to definerequested, a new general-purpose transport protocol. In this section we outline the issuesdefault FPT is used. 3. Transport, Reliability and Retransmission of runningFeature Data CTP runs over well-known protocols. ICMP andUDP do not provide congestion control, while TCP/SCTP do provide congestion control. The connection setup for those congestion control transport protocolsusing port number <TBD>. Some feature contexts may introduce delays in start of data transfer, but do protectspecify a reliability factor, MAX_RETRY_INTERVAL, which is the network from becoming overloaded. This trade off needs to be further studied in terms of applicabilitylength of context transfer. Sincetime that the datapAR is allowed to be handled byperform retransmissions before giving up on the context transfer protocol is typically transmitted locally only, between access routers, the dangerfor congestion inthat feature context. The longer the network at largeallowed retry interval, the more retransmissions will be possible for that feature context. It is substantially reduced or eliminated. Some issues affecting thisexpected that retransmission will be a rare event, because of the typephysical proximity of signaling - for example, intra-domain vs. inter-domain. Ofthe existing transport mechanisms, both TCPaccess routers and SCTP provide checksums. UDP provides only an optional checksum. In order to enable use of multiplexing functionalitylikely characteristics of context transfer protocol,the UDP checksum MAY be de-activated to provide flexibility in inserting checksums within context information as needed.network media connecting the access routers. For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD retransmit an unacknowledged CTD message after waiting for RETRANSMISSION_DELAY milliseconds. This time value is configurable based on the type of network interface; slower network media naturally will decreasebe configured with longer values for the likelihood thatRETRANSMISSION_DELAY. Except for the entire context datavalue of the elapsed time field, the payload of each retransmitted CTD packet is dropped dueidentical to individual feature data corruptions. 3.1 Congestion Control Context transfer enables smooth handovers and preventsthe needpayload of re-initializing signalingthe initially transmitted CTD packet, in order to and from amaintain the ability of the mobile node after handover. Context transfer takes place between access routers.device to present a correctly calculated authentication token. The goalnumber of congestion control is to prevent congestionretransmissions, each delayed by noting packet loss atRETRANSMISSION_DELAY, depends on the transport layer and reducingmaximum value for MAX_RETRY_INTERVAL as specified by any of the congestion control window when packet loss occurs, thus effectively restrictingcontexts. The value of the available in-flight window for packet sending. Additionally, TCP & SCTP deploy slow-start mechanisms at start-up, in order to prevent congestion problems atElapsed Time field is the startnumber of milliseconds since the transmission of the first CTD message UDP provides a new TCP/SCTP session. As some contextoptional checksum, which SHOULD be checked. If the checksum is time-critical, delays dueincorrect, nAR SHOULD return a CTDR packet to congestion control may reducepAR with the performancestatus value BAD_UDP_CHECKSUM, even if the 'R' bit is not set in the CTD. 4. Open Issues This section lists some open issues that need further discussion. 4.1 Failure Handling Failure 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 or 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 contexts that are "too late" should not be included as part of the retransmitted CTD data. 3.2 Transport Protocols 3.2.1 ICMP Pros * No explicit connection setup needed. * Reliability handled at the upper layer. * Co-ordination with mobility solutions easier to implement. Cons * No transport level signaling * No reliability * No ability to fragment data. * Upper Size limits on packets. * ICMP messages have low priority in case of congestion 3.2.2 UDP Pros * No explicit connection setup needed. * Reliability handled at the upper layer. * Co-ordination with mobility solutions easier to implement. Cons * No transport level signaling * No reliability * No ability to fragment data. 3.2.3 TCP Pros * Supports TLS * Built in reliability Cons * 3-way handshake, mitigated if TCP connections are re-used. Open issues * Single TCP connection or multiple TCP connections? Per transfer or per neighbor? 3.3.4 SCTP Pros * Supports TLS * Built in reliability * Message-oriented * Multiple streams prevent head-of-line blocking for multiple users. Cons * 3-way handshake, mitigated if STCP connections are re-used. Open issues * Partial Reliability SCTP may be interesting, as it allows selective retransmission. 4. Open Issues This section lists some open issues that need further discussion. 4.1 Reliability Should reliability be handled at the transport layer? Should the reliability needs of contexts be handled at the CTP data level or CTP message level? 4.2 Transport Currently, the issue of which transport protocol should be supported is open. 4.3 Failure Handling Failure of Context Transfer should at least cause no harm to the network or to the user session. Failure reporting toContext Transfer should at least cause no harm to the network or to the user session. Failure reporting to the mobile node may be needed. The details about how failure can be reported for some individual contexts but not requiring retransmission of all contexts should be straightforward but remain to be worked out. 4.4 Zone of Operation Currently, the authors are restricting discussion of CTP to intra- domain signaling. Discussion of inter-domain signaling left for later discussions. Inter-domain signaling places additional requirements on establishing security relationships that may not be relevant for intra-domain. Besides, physically adjacent routers may be more than several IP hops away. Additionally, provisioning inter-domain signaling links may be much more complicated. Restricting CTP to intra-domain signaling simplifies security, transport and provision concerns. Additionally, a restriction to intra-domain signaling may help to ensure CT completes in sufficient time to meet time sensitive requirements.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 MN nAR pAR | | | T | CT trigger | I | | | M | |----- CT requestRequest ----->| E | | | : | |<------- CTD ----------| | | | | V |--------CTAR--------->| | | |----- CTDR (opt) ----->| | | | Is a new message CT request needed?5.3 Mobile controlled, Predictive New L2 up/old L2 down CTSRCTAR request to nAR (nAR must be able to authenticate MN for CT, security details later) MN nAR pAR | | | new L2 link up | | | | | CT trigger | | | | | T |--------CTSR|--------CTAR ------->| | I | |---- CT requestRequest ------>| M | | | E | |<-------- CTD ---------| : | | | | | | | V | | | | | | Is a new message CT request needed?In case CT cannot be supported, a CTSRCTAR reject (TBD) may be sent to the MN by nAR. 5.4 Mobile controlled, Reactive CT New L2 up/old L2 down CTSR requestCTAR relay to pAR through nAR (the pAR needs to authenticate the CTSR)CTAR) MN nAR pAR | | | new L2 link up | | | | | CT trigger | | | | | T |------- CTSRCTAR -------->|===== CTSRCTAR relay =====>| I | | | M | |<------- CTD --------- | E | | | : | | | | | | | V | | | | | | The CTSRCTAR relay is the CTSRCTAR message that is destined to pAR and is routed through nAR (routing details later). In case CT cannot be supported, a CTSRCTAR reject maybe sent to the MN through nAR. 6. Security Considerations The Context Transfer Protocol essentiallytransfers state between access routers. If the mobile nodes are not authenticated and authorized before moving on the network, there is a potential for DoS-style attacks to shift state between ARs, causing network disruptions. In general, CTP relies on IETF standardized security mechanisms for protecting traffic between access routers, as opposed to creating application security mechanisms. Both IPsec and TLS [TLS] may be reasonable mechanisms for securing the context transfer between access routers. Inorder 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 ARaccess routers need to engage in a key exchange mechanisms such as IKE [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 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 MSUT be provided so that requests are authenticated (regardless of the security of context transfer itself) to prevent the possibility of rougerogue MNs launching DoS attacks by sending large number of CT requests as well as cause large number of context transfers between ARs.AnotherARs. 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. 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]. 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. 8. Acknowledgements 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. The working group chairs are Pat Calhoun and James Kempf, whose comments have been very helpful during the creating of this specification. 9. References 9.1 Normative References S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. S. Bradner, "Key words for use in RFCs to Indicate Require- mentRequirement Levels", BCP 14, RFC 2119, March 1997. [CT-REQ]S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 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. [IANA]IP [RFC2434] Narten, Alvestrand, "Guidelines for Writing an IANA Con- siderationsConsiderations Section in RFCs", BCP 26, RFC 2434, October 1998. [IKE]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. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.9.2 Non-Normative References 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. 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. T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Appendix A. Simplified Example Context Type Specification This diagram illustrates the methodmethod for specifying context type data to be associated with a particular context type for Header Compression. Context Type: Header Compression Data fields: IP header fields Current IP Source Address 32bits Change recipe Current IP Destination Address 32bits Change recipe UDP header fields RTP header fields Appendix B. 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 services. 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 conjunction 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 protocols 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 C. 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 control window when packet loss occurs, thus effectively restricting the available in-flight window for specifyingpacket 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. As some context type datais time-critical, delays due to congestion control may reduce the performance of mobile nodes; additionally, signaling from the mobile node may be associated with a particularincreased if the context type for Header Compres- sion. TBA Context Type: Header Compression Data fields: IP header fields Current IP Source Address 32bits Change recipe Current IP Destination Address 32bits Change recipe UDP header fields RTP header fields Appendix B. Timingtransfer of time critical data fails. Therefore, some analysis is needed on the role of congestion control and Trigger Considerations Basic Mobile IP handovercontext transfer. Important considerations should be network-provisioning, intra-domain vs. inter-domain signaling can introduce disruptions to the services runningas 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 topexisting implementation of Mobile IP, which may introduce unwanted latenciessome context transfer solutions. Contexts that practically prohibit its use for certain typesare significantly larger are assumed not so time critical. For a larger number of services. Mobile IP latency and packet lossusers, 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 or frame relay or ATM link between access routers. So even bursty traffic is being optimized through several alternative procedures, such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP]. Feature re-establishment through context transferunlikely to introduce local congestion. Furthermore, physically adjacent access routers should contribute zero (optimally)be within one or minimal extra disruptiontwo IP hops of services in conjunction to handovers. This means thateach other, so the timingeffects of context transfer SHOULDshould be carefully aligned with basic Mobile IP handover events, andlocalized. 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 optimized Mobile IP handover signaling mechanisms, asdiffering 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 protocols become available. Furthermore, somecontexts that are "too late" are included anyway as part of those optimized mobilethe retransmitted CTD data, in order to ease the ability to verify the Mobile Authorization Token. Appendix D. Zone of Operation Inter-domain signaling places additional requirements on establishing security relationships that may not be relevant for intra-domain. Besides, physically adjacent routers may be more than several IP handover mechanisms (such as BETH)hops away. Additionally, provisioning inter-domain signaling links may providebe much more flexibility is choosing the timingcomplicated. Restricting CTP to intra-domain signaling simplifies security, transport and order for transfer of various context information.provision concerns. Additionally, a restriction to intra-domain signaling may help to ensure CT completes in sufficient time to meet time sensitive requirements. Author's Addresses Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Rajeev.firstname.lastname@example.org John Loughney Nokia Itdmerenkatu 11-13 00180 Espoo Finland email@example.com Madjid F. Nakhjiri Motorola Labs 1031 East Algonquin Rd., Room 2240 Schaumburg, IL, 60196 USA firstname.lastname@example.org Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA email@example.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- tainpertain 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- relatedstandards-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.