idnits 2.17.1 draft-ietf-seamoby-ctp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 19) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7711 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 14, but not defined == Unused Reference: '2026' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'CT-REQ' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'CTF' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 842, but no explicit reference was found in the text == Unused Reference: '2401' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'TERM' is defined on line 864, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CT-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'CTF' -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPv6' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'LLMIP' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Seamoby WG J. Loughney (editor) 3 Internet Draft M. Nakhjiri 4 Category: Standards Track C. Perkins 5 R. Koodli 6 Expires: September 2003 March 2003 8 Context Transfer Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright (C) The Internet Society 2003. All Rights Reserved. 35 Abstract 37 This document presents a context transfer protocol that enables 38 authorized context transfers. Context transfers allows better 39 support for node based mobility so that the applications running on 40 mobile nodes can operate with minimal disruption. Key objectives are 41 to reducing latency, packet losses and avoid re-initiation of 42 signaling to and from the mobile node. 44 Table of Contents 46 1. Introduction 47 1.1 Conventions Used in This Document 48 1.2 Abbreviation Used in the Document 49 2. Protocol Overview 50 2.1 Context Transfer Packet Format 51 2.2 Context Types 52 2.3 Context Data Block 53 2.4 Messages 54 3. Transport Considerations 55 3.1 Congestion Control 56 3.2 Transport Protocols 57 4. Open Issues 58 4.1 Reliability 59 4.2 Transport 60 4.3 Failure Handling 61 4.4 Zone of Operation 62 5. Examples and Signaling Flows 63 5.1 Network controlled, Initiated by pAR 64 5.2 Network controlled, Initiated by nAR 65 5.3 Mobile controlled, Predictive New L2 up/old L2 down 66 5.4 Mobile controlled, Reactive CT New L2 up/old L2 down 67 6. Security Considerations 68 7. IANA Considerations 69 8. Acknowledgements 70 9. References 71 9.1 Normative References 72 9.2 Non-Normative References 73 Appendix A. Simplified Example Context Type Specification 74 Appendix B. Timing and Trigger Considerations 75 Author's Addresses 77 1. Introduction 79 "Problem Description: Reasons For Performing Context Transfers 80 between Nodes in an IP Access Network" [3374] defines the following 81 main reasons why Context Transfer procedures may be useful in IP 82 networks. 84 1) The primary motivation, as mentioned in the introduction, is the 85 need to quickly re-establish context transfer-candidate services 86 without requiring the mobile host to explicitly perform all 87 protocol flows for those services from scratch. 88 2) An additional motivation is to provide an interoperable solution 89 that works for any Layer 2 radio access technology. 91 Access Routers typically establish state in order to effect certain 92 forwarding treatments to packet streams belonging to nodes sharing 93 the access router. For instance, an access router may establish an 94 AAA session state and a QoS state for a node's packet streams. When 95 the link connecting a mobile node and the access router is 96 bandwidth-constrained, the access router may maintain header 97 compression state on behalf of the mobile node. When such a node 98 moves to a different access router, this state or context relocation 99 during handover provides many important benefits, including: 101 * Seamless operation of application streams. The handover node 102 (i.e., the Mobile Node) does not need to re-establish its 103 contexts at the new access router 104 * Performance benefits. When contexts need to be reestablished, 105 performance of transport protocols would suffer until the 106 contexts are in place. For instance, when the required QoS 107 state is not present, a stream's packets would not receive the 108 desired per-hop behavior treatment, subjecting them to higher 109 likelihood of unacceptable delays and packet losses. 110 * Bandwidth savings. Re-establishing multiple contexts over an 111 expensive, low-speed link can be avoided by relocating contexts 112 over a potentially higher-speed wire. 113 * Reduced susceptibility to errors, since much more of the 114 protocol operates over reliable networks, replacing 115 renegotiations over a potentially error-prone link. 117 In [3374], a detailed description of motivation, the need and 118 benefits of context transfer are outlined. In this document, we 119 describe a generic context transfer protocol, which provides: 121 * Representation for feature contexts. 122 * Messages to initiate and authorize context transfer, and notify 123 a mobile node of the status of the transfer. 124 * Messages for transferring contexts prior to, during and after 125 handovers. 127 The proposed protocol is designed to work in conjunction with other 128 protocols in order to provide seamless mobility. 130 1.1 Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC-2119 [2119]. 136 1.2 Abbreviation Used in the Document 138 AR Access Router 140 CT Context Transfer 142 CTP Context Transfer Protocol 144 DoS Denial-of-Service 146 FPT Feature Profile Types 148 MIP Mobile IP 150 MN Mobile Node 152 nAR New Access Router 154 pAR Previous Access Router 156 SA Security Association 158 2. Protocol Overview 160 This section provides a protocol overview. A context transfer can be 161 either started by a request from the mobile node ("mobile 162 controlled") or at the initiative of either the new or the previous 163 access router ("network controlled"). 165 * The mobile node can send the CT start request to old or new AR. 166 The former is preferred whenever possible. Sending the request to 167 nAR would add extra latency since the new AR, itself, after 168 processing the MN's request will need to request context 169 transmission from pAR. 170 * Either nAR or pAR may request or start (respectively) context 171 transfer based on internal or network triggers (see Appendix B). 173 The MN will send a context transfer request to the pAR (including 174 proper authentication material). After checking authentication, pAR 175 starts the context transfer procedure. 177 The Context Transfer protocol typically operates between a source 178 node and a target node. In the future, there may be multiple target 179 nodes involved; the protocol described here would work with multiple 180 target nodes. For simplicity, we describe the protocol assuming a 181 single receiver or target node. 183 Typically, the source node is a MN's Previous Access Router (pAR) and 184 the target node is MN's New Access Router (nAR). We assume that pAR 185 and nAR share an appropriate security association, set up 186 independently and prior to context transfer. Any appropriate 187 mechanism may be used in setting up this security association; it 188 enables the CT peers to utilize a secure channel for transferring 189 contexts, providing authentication, integrity, and (if needed) 190 confidentiality. 192 Context Transfer takes place when an event, such as a handover, takes 193 place. We call such an event as a Context Transfer Trigger. In 194 response to such a trigger, the pAR may transfer the contexts; the 195 NAR may request contexts and the MN may send a message to the PAR to 196 transfer contexts. Such a trigger must be capable of providing the 197 necessary information, such as the MN's IP address with which the 198 contexts are associated, the IP addresses of the access routers, and 199 authorization to transfer context. 201 Context transfer protocol messages use Context Types that identify 202 the way that data is organized for the particular feature contexts. 203 The Context Types (CPTs) are registered in a number space (with IANA 204 Type Numbers) that allows a node to unambiguously determine the type 205 of context and the context parameters present in the protocol 206 messages. Contexts are transferred by laying out the appropriate 207 feature data within Context Data Blocks according to the format in 208 section 2.3, as well as any IP addresses necessary to associate the 209 contexts to a particular MN. The context transfer initiation 210 messages contain parameters that identify the source and target 211 nodes, the desired list of feature contexts and IP addresses to 212 identify the contexts. The messages that actually transfer context 213 data also contain an appropriate token to authorize the context 214 transfer. 216 The Previous Access Router transfers feature contexts under two 217 general scenarios. First, it may receive a Context Transfer Start 218 Request (CTSR) message from the MN whose feature contexts are to be 219 transferred, or it receives an internally generated trigger (e.g., a 220 link-layer trigger on the interface to which the MN is connected). 222 The CTSR message, described in Section 2.4.1, provides the IP address 223 of NAR, the IP address of MN on PAR, the list of feature contexts to 224 be transferred (by default requesting all contexts to be 225 transferred), and a token authorizing the transfer. It also includes 226 the MN's new IP address (valid on NAR) whenever it is known. In 227 response to a CT-Start Request message or to the CT trigger, PAR 228 predictively transmits a Context Transfer Data (CTD) message that 229 contains feature contexts. This message, described in Section 2.4.2, 230 contains the MN's previous IP address and its new IP address 231 (whenever known). It also includes a key, and an indication to use a 232 particular algorithm to assist NAR in computing a token that it could 233 use to check authorization prior to making the contexts available to 234 the MN. 236 In the second scenario, pAR receives a Context Transfer Request (CT 237 Request) described in Section 2.4.5, message from nAR. The nAR 238 itself generates the CT Request message either as a result of 239 receiving the CTSR message or as a response to an internal trigger 240 (that indicates the MN's attachment). In the CT-Req message, nAR 241 supplies the MN's previous IP address, the feature contexts to be 242 transferred, and a token (typically generated by the MN) authorizing 243 context transfer. In response to CT Request message, pAR transmits a 244 Context Transfer Data (CTD) message that includes the MN's previous 245 IP address and feature contexts. When it receives a corresponding 246 CTD message, nAR may generate a CTD Reply message (See Section 2.4.3) 247 to report the status of processing the received contexts. In this 248 "reactive" transfer of contexts, PAR verifies authorization token 249 before transmitting the contexts, and hence does not include the key 250 and the name of algorithm in the CTD message. 252 When context transfer takes place without the nAR requesting it 253 (scenario one above), nAR should require MN to present its 254 authorization token. Doing this locally at nAR when the MN attaches 255 to it improves performance, since the contexts highly likely to be 256 present already. When context transfer happens with an explicit 257 request from NAR (scenario two above), pAR performs such verification 258 since the contexts are still present at pAR. In either case, token 259 verification takes place at the node possessing the contexts. 261 Performing context transfer in advance of the MN attaching to NAR 262 clearly has potential for better performance. For this to take 263 place, certain conditions must be met. For example, PAR must have 264 sufficient time and knowledge about the impending handover. This is 265 feasible for instance in Mobile IP fast handovers. However, when the 266 advance knowledge of impending handover is not available, or if a 267 mechanism such as fast handover fails, retrieving feature contexts 268 after the MN attaches to NAR is the only available means for context 269 transfer. Performing context transfer after handover might still be 270 better than having to re-establish all the contexts from scratch. 271 Finally, some contexts may simply need to be transferred during 272 handover signaling. For instance, any context that gets updated on a 273 per-packet basis must clearly be transferred only after packet 274 forwarding to the MN on its previous link is terminated. Transfer of 275 such contexts must be properly synchronized with appropriate handover 276 messages, such as Mobile IP (Fast) Binding Update. 278 2.1 Context Transfer Packet Format 280 The packet consists of a common header, message specific header and 281 one or more data packets. Data packets may be bundled together in 282 order ensure a more efficient transfer. The total packet size, 283 including transport protocol and IP protocol headers SHOULD be less 284 than the path MTU, in order to avoid packet fragmentation. 286 +----------------------+ 287 | CTP Header | 288 +----------------------+ 289 | Message Header | 290 +----------------------+ 291 | CTP Data 1 | 292 +----------------------+ 293 | CTP Data 2 | 294 +----------------------+ 295 | ... | 297 2.2 Context Types 299 Contexts are identified by context type, which is a 32-bit number. 300 The meaning of each context type is determined by a specification 301 document and the context type numbers are to be tabulated in a 302 registry maintained by IANA, and handled according to the message 303 specifications in this document. The instantiation of each context 304 by nAR is determined by the messages in this document along with the 305 specification associated with the particular context type. Each such 306 context type specification contains the following details: 308 - Number, size (in bits), and ordering of data fields in the 309 state variable vector which embodies the context. 310 - Default values (if any) for each individual datum of the 311 context state vector. 312 - Procedures and requirements for creating a context at a new 313 access router, given the data transferred from a previous 314 access router, and formatted according to the ordering rules 315 and date field sizes presented in the specification. 316 - If possible, status codes for success or failure related to the 317 context transfer. For instance, a QoS context transfer might 318 have different status codes depending on which elements of the 319 context data failed to be instantiated at nAR. 321 Appendix A contains an example context type specification for UDP/RDP 322 header compression context. 324 2.3 Context Data Block 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |V| Context Type | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Presence Vector (if V = 1) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 / context type-dependent data / 334 \ \ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 The 'V' bit specifies whether or not the "presence vector" is used. 338 When the presence vector is in use, the next 32 bits are interpreted 339 to indicate whether particular data fields are present (and, thus, 340 containing non-default values). The ordering of the bits in the 341 presence vector is the same as the ordering of the data fields 342 according to the context type specification, one bit per data field 343 regardless of the size of the data field. Notice that the length of 344 the context data block is defined by the sum of lengths of each data 345 field specified by the context type specification, plus 4 bytes if 346 the 'V' bit is set, minus the accumulated size of all the context 347 data that is implicitly given as a default value. 349 2.4 Messages 351 In this section, a list of the available context transfer message 352 types is given, along with a brief description of their functions. 353 Generally, messages use the following generic message header format: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Message Type |reserve| Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Mobile Node's Previous Care-of Address | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 / message data / 363 \ \ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 The Mobile Node, for which context transfer protocol operations are 367 undertaken, is always identified by its previous care-of address. At 368 any one time, only one context transfer operation may be in progress 369 so that the CTDR message unambigously identifies which CTD message is 370 acknowledged simply by including the mobile node's identifying 371 previous care-of address. 373 2.4.1 Context Transfer Start Request (CTSR) Message 375 Sent by MN to nAR to request start of context transfer. It is for 376 further to study to see if when the CTSR message is sent by the MN to 377 the nAR, it should also be relayed to pAR. Acknowledgement is 378 optional, since the MN may have already moved and may not receive the 379 reply. This message may include a list of FPT (feature profile types) 380 that require transfer. It may include flags to request secure and/or 381 reliable transfer. 383 The MN may also send this message to pAR while still connected to 384 pAR. In such a case, the MN includes the nAR's IP address and its new 385 IP address (if known). 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Message Type |reserve| Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Mobile Node's Previous Care-of Address | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Previous Router IP Address | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | MN Authorization Token | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Requested Context Type (if present) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Next Requested Context Type (if present) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | ........ | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 The message data for CTSR is the Mobile Node's Previous Care-of 406 Address, Previous Router's IP address, MN Authorization Token, 407 followed by a list of context types. If no context types are 408 specified, then all contexts for the mobile node are requested. 410 2.4.2 Context Transfer Data (CTD) Message 412 Sent by pAR to nAR, and includes feature data (CTP data). This 413 message should handle predictive as well as normal CT. A reliability 414 flag, R, included in this message indicates whether a reply is 415 required by nAR. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Message Type |C|R|rsv| Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | MN Authorization Token | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Mobile Node's Previous Care-of Address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Mobile Node's New Care-of Address, if C=1 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | First Context Block | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Next Context Block | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | ........ | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 The MN Authorization Token is computed over the binary data 436 represented in the Context Data BLocks of the CTD message. The 437 binary data is laid out as the fully specified ordered sequence of 438 data fields according to the defining context specification, as if 439 there were no presence vector and therefore no implicitly supplied 440 default values. Since the mobile node is expected to know the 441 precise contents of the context data to be transferred, and the pAR 442 is expected to know the security parameters and algorithm used by the 443 mobile node to compute the authorization token, the token can be 444 supplied by pAR on behalf of the mobile node. 446 2.4.3 Context Transfer Data Reply (CTDR) Message 448 This message is sent by nAR to pAR depending on the value of the 449 reliability flag in CTD. Indicates success or failure. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Message Type |C| rsv | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Mobile Node's Previous Care-of Address | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | OverallStatus | Ctx-1 Status | Ctx-2 Status | ...... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 The OverallStatus is used for reporting overall success or failure, 462 which could be based on verification of the MN authorization token 463 for instance. For certain values of the overall status, it may be 464 that some contexts were successfully transferred and some failed to 465 be transferred. In this case, then for each context another status 466 code MUST be provided to indicate to pAR which contexts have failed 467 and which have succeeded, along with the reason. 469 2.4.4 Context Transfer Cancel (CTC) Message 471 If transfering a context requires an ongoing process (i.e., is not 472 short-lived), then nAR may send CTC to pAR to cancel an ongoing CT 473 process. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Message Type | rsv | Length = 4 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Mobile Node's Previous Care-of Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 2.4.5 Context Transfer Request (CT Request) Message 485 Sent by nAR to pAR request start of context transfer. This message is 486 sent as a response to CTSR message by the MN. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Message Type |reserve| Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Mobile Node's Previous Care-of Address | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | MN Authorization Token | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Requested Context Type (if present) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Next Requested Context Type (if present) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | ........ | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 The message data for CT Request is the Mobile Node's Previous Care-of 505 Address, MN Authorization Token, followed by a list of context types. 506 If no context types are specified, then all contexts for the mobile 507 node are requested. The MN Authorization Token is computed by laying 508 out all the context data according to the specifications given within 509 the Context Type document, without any abbreviation or implicit 510 specification as for default values. 512 3. Transport Considerations 514 It is not the intention of this work to define a new general-purpose 515 transport protocol. In this section we outline the issues of running 516 CTP over well-known protocols. 518 ICMP and UDP do not provide congestion control, while TCP/SCTP do 519 provide congestion control. The connection setup for those 520 congestion control transport protocols may introduce delays in start 521 of data transfer, but do protect the network from becoming 522 overloaded. This trade off needs to be further studied in terms of 523 applicability of context transfer. Since the data to be handled by 524 the context transfer protocol is typically transmitted locally only, 525 between access routers, the danger for congestion in the network at 526 large is substantially reduced or eliminated. Some issues affecting 527 this will be the type of signaling - for example, intra-domain vs. 528 inter-domain. 530 Of the existing transport mechanisms, both TCP and SCTP provide 531 checksums. UDP provides only an optional checksum. In order to 532 enable use of multiplexing functionality of context transfer 533 protocol, the UDP checksum MAY be de-activated to provide flexibility 534 in inserting checksums within context information as needed. This 535 will decrease the likelihood that the entire context data packet is 536 dropped due to individual feature data corruptions. 538 3.1 Congestion Control 540 Context transfer enables smooth handovers and prevents the need of 541 re-initializing signaling to and from a mobile node after handover. 542 Context transfer takes place between access routers. 544 The goal of congestion control is to prevent congestion by noting 545 packet loss at the transport layer and reducing the congestion 546 control window when packet loss occurs, thus effectively restricting 547 the available in-flight window for packet sending. Additionally, TCP 548 & SCTP deploy slow-start mechanisms at start-up, in order to prevent 549 congestion problems at the start of a new TCP/SCTP session. 551 As some context is time-critical, delays due to congestion control 552 may reduce the performance of mobile nodes; additionally, signaling 553 from the mobile node may be increased if the context transfer of time 554 critical data fails. 556 Therefore, some analysis is needed on the role of congestion control 557 and context transfer. Important considerations should be network- 558 provisioning, intra-domain vs. inter-domain signaling as well as 559 other considerations. A quick analysis follows. 561 It is assumed that intra-domain time-critical context transfer should 562 take no more than one kilobyte, based on existing implementation of 563 some context transfer solutions. Contexts that are significantly 564 larger are assumed not so time critical. For a larger number of 565 users, say one thousand users requesting a smooth handover all in the 566 same second, the total bandwidth needed is still a small fraction of 567 a typical Ethernet or frame relay or ATM link between access routers. 568 So even bursty traffic is unlikely to introduce local congestion. 569 Furthermore, physically adjacent access routers should be within one 570 or two IP hops of each other, so the effects of context transfer 571 should be localized. If transferring real-time contexts triggers 572 congestive errors, the access network may be seriously under- 573 provisioned. 575 In order to handle multiple contexts to be transferred with differing 576 reliability needs, each context has to be considered separately by 577 the sending access router nAR. If a CTD message is retransmitted 578 because the CTDR message was not received in time, then those 579 contexts that are "too late" should not be included as part of the 580 retransmitted CTD data. 582 3.2 Transport Protocols 584 3.2.1 ICMP 586 Pros 587 * No explicit connection setup needed. 588 * Reliability handled at the upper layer. 589 * Co-ordination with mobility solutions easier to implement. 591 Cons 592 * No transport level signaling 593 * No reliability 594 * No ability to fragment data. 595 * Upper Size limits on packets. 596 * ICMP messages have low priority in case of congestion 598 3.2.2 UDP 600 Pros 601 * No explicit connection setup needed. 602 * Reliability handled at the upper layer. 603 * Co-ordination with mobility solutions easier to implement. 605 Cons 606 * No transport level signaling 607 * No reliability 608 * No ability to fragment data. 610 3.2.3 TCP 612 Pros 613 * Supports TLS 614 * Built in reliability 616 Cons 617 * 3-way handshake, mitigated if TCP connections are re-used. 619 Open issues 620 * Single TCP connection or multiple TCP connections? Per transfer 621 or per neighbor? 623 3.3.4 SCTP 625 Pros 626 * Supports TLS 627 * Built in reliability 628 * Message-oriented 629 * Multiple streams prevent head-of-line blocking for multiple users. 631 Cons 632 * 3-way handshake, mitigated if STCP connections are re-used. 634 Open issues 635 * Partial Reliability SCTP may be interesting, as it allows 636 selective retransmission. 638 4. Open Issues 640 This section lists some open issues that need further discussion. 642 4.1 Reliability 644 Should reliability be handled at the transport layer? Should the 645 reliability needs of contexts be handled at the CTP data level or CTP 646 message level? 648 4.2 Transport 650 Currently, the issue of which transport protocol should be supported 651 is open. 653 4.3 Failure Handling 655 Failure of Context Transfer should at least cause no harm to the 656 network or to the user session. Failure reporting to the mobile node 657 may be needed. The details about how failure can be reported for 658 some individual contexts but not requiring retransmission of all 659 contexts should be straightforward but remain to be worked out. 661 4.4 Zone of Operation 663 Currently, the authors are restricting discussion of CTP to intra- 664 domain signaling. Discussion of inter-domain signaling left for 665 later discussions. 667 Inter-domain signaling places additional requirements on establishing 668 security relationships that may not be relevant for intra-domain. 669 Besides, physically adjacent routers may be more than several IP hops 670 away. Additionally, provisioning inter-domain signaling links may be 671 much more complicated. 673 Restricting CTP to intra-domain signaling simplifies security, 674 transport and provision concerns. Additionally, a restriction to 675 intra-domain signaling may help to ensure CT completes in sufficient 676 time to meet time sensitive requirements. 678 5. Examples and Signaling Flows 680 5.1 Network controlled, Initiated by pAR 682 MN nAR pAR 683 | | | 684 T | | CT trigger 685 I | | | 686 M | |<------- CTD ----------| 687 E | | | 688 : | | | 689 | | |-------- CTDR -------->| 690 V | | | 691 | | | 693 5.2 Network controlled, initiated by nAR 695 MN nAR pAR 696 | | | 697 T | CT trigger | 698 I | | | 699 M | |----- CT request ----->| 700 E | | | 701 : | |<------- CTD ----------| 702 | | | | 703 V | |----- CTDR (opt) ----->| 704 | | | 706 Is a new message CT request needed? 708 5.3 Mobile controlled, Predictive New L2 up/old L2 down 710 CTSR request to nAR (nAR must be able to authenticate MN for CT, 711 security details later) 713 MN nAR pAR 714 | | | 715 new L2 link up | | 716 | | | 717 CT trigger | | 718 | | | 719 T |--------CTSR ------->| | 720 I | |---- CT request ------>| 721 M | | | 722 E | |<-------- CTD ---------| 723 : | | | 724 | | | | 725 V | | | 726 | | | 728 Is a new message CT request needed? 730 In case CT cannot be supported, a CTSR reject may be sent to the MN 731 by nAR. 733 5.4 Mobile controlled, Reactive CT New L2 up/old L2 down 735 CTSR request to pAR through nAR (the pAR needs to authenticate the 736 CTSR) 738 MN nAR pAR 739 | | | 740 new L2 link up | | 741 | | | 742 CT trigger | | 743 | | | 744 T |------- CTSR -------->|===== CTSR relay =====>| 745 I | | | 746 M | |<------- CTD --------- | 747 E | | | 748 : | | | 749 | | | | 750 V | | | 751 | | | 753 The CTSR relay is the CTSR message that is destined to pAR and is 754 routed through nAR (routing details later). In case CT cannot be 755 supported, a CTSR reject maybe sent to the MN through nAR. 757 6. Security Considerations 759 The Context Transfer Protocol essentially transfers state between 760 access routers. If the mobile nodes are not authenticated and 761 authorized before moving on the network, there is a potential for 762 DoS-style attacks to shift state between ARs, causing network 763 disruptions. 765 In general, CTP relies on IETF standardized security mechanisms for 766 protecting traffic between access routers, as opposed to creating 767 application security mechanisms. Both IPsec and TLS [TLS] may be 768 reasonable mechanisms for securing the context transfer between 769 access routers. 771 In order to avoid the introduction of additional latency to context 772 transfer due to the need for establishment of secure channel between 773 the context transfer peers (ARs), the two ARs SHOULD establish such 774 secure channel in advance. If IPSec is used, for example, the two AR 775 need to engage in a key exchange mechanisms such as IKE [IKE], 776 establish IPSec SAs, defining the keys, algorithms and IPSec 777 protocols (such as ESP) in anticipation for any upcoming context 778 transfer. This will save time during handovers that require secure 779 transfer of mobile node's context(s). Such SAs can be maintained and 780 used for all upcoming context transfers between the two ARs. 781 Security should be negotiated prior to the sending of context. 783 Furthermore, either one or both of the pAR and nAR need to be able 784 authenticate the mobile and authorize mobile's credential before 785 authorizing the context transfer and release of context to the 786 mobile. In case the context transfer is request by the MN, a 787 mechanism MSUT be provided so that requests are authenticated 788 (regardless of the security of context transfer itself) to prevent 789 the possibility of rouge MNs launching DoS attacks by sending large 790 number of CT requests as well as cause large number of context 791 transfers between ARs.Another important consideration is that the 792 mobile node should claim it's own context, and not some other 793 masquerader. One method to achieve this is to provide an 794 authentication cookie to be included with the context transfer 795 message sent from the pAR to the nAR and confirmed by the mobile node 796 at the nAR. 798 7. IANA Considerations 800 This document authorized IANA to create a registry for Context 801 Profile Types, introduced in this document. For future Context 802 Profile Types, it is recommended that allocations be done on the 803 basis of Designated Expert. 805 The Context Profile Type introduced in this document requires IANA 806 Type Numbers for each set of feature contexts that make use of 807 Profile Types. 809 For registration requests where a Designated Expert should be 810 consulted, the responsible IESG area director should appoint the 811 Designated Expert. 813 8. Acknowledgements 815 This document is the result of a design team formed by the Working 816 Group chairs of the SeaMoby working group. The team included John 817 Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. The 818 working group chairs are Pat Calhoun and James Kempf, whose comments 819 have been very helpful during the creating of this specification. 821 9. References 823 9.1 Normative References 825 [2026] S. Bradner, "The Internet Standards Process -- Revision 3", 826 BCP 9, RFC 2026, October 1996. 828 [2119] S. Bradner, "Key words for use in RFCs to Indicate Require- 829 ment Levels", BCP 14, RFC 2119, March 1997. 831 [CT-REQ] G. Kenward et al., "General Requirements for Context 832 Transfer", Internet Draft, Internet Engineering Task Force, 833 Work in Progress. 835 [CTF] R. Koodli, C.E. Perkins, "Context Transfer Framework for 836 Seamless Mobility", Internet Draft, Internet Engineering 837 Task Force, Work in Progress. 839 [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet 840 Engineering Task Force. Work in Progress. 842 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Con- 843 siderations Section in RFCs", BCP 26, RFC 2434, October 844 1998. 846 [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 847 RFC 2409, November 1998. 849 [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", 850 Internet Engineering Task Force. Work in Progress. 852 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 853 2246, January 1999. 855 9.2 Non-Normative References 857 [3374] J. Kempf et al., "Problem Description: Reasons For Performing 858 Context Transfers Between Nodes in an IP Access Network", RFC 859 3374, Internet Engineering Task Force, RFC 3374, May 2001. 861 [2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 862 Protocol", RFC 2401, November 1998. 864 [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet 865 Engineering Task Force, Work in Progress. 867 Appendix A. Simplified Example Context Type Specification 869 This diagram illustrates the method for specifying context type data 870 to be associated with a particular context type for Header Compres- 871 sion. 873 TBA 875 Context Type: Header Compression 877 Data fields: 878 IP header fields 879 Current IP Source Address 32bits Change recipe 880 Current IP Destination Address 32bits Change recipe 882 UDP header fields 884 RTP header fields 886 Appendix B. Timing and Trigger Considerations 888 Basic Mobile IP handover signaling can introduce disruptions to the services 889 running on top of Mobile IP, which may introduce unwanted latencies that 890 practically prohibit its use for certain types of services. Mobile IP latency 891 and packet loss is being optimized through several alternative procedures, 892 such as Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP]. 894 Feature re-establishment through context transfer should contribute zero 895 (optimally) or minimal extra disruption of services in conjunction to 896 handovers. This means that the timing of context transfer SHOULD be carefully 897 aligned with basic Mobile IP handover events, and with optimized Mobile IP 898 handover signaling mechanisms, as those protocols become available. 900 Furthermore, some of those optimized mobile IP handover mechanisms (such as 901 BETH) may provide more flexibility is choosing the timing and order for 902 transfer of various context information. 904 Author's Addresses 906 Rajeev Koodli 907 Nokia Research Center 908 313 Fairchild Drive 909 Mountain View, California 94043 910 USA 911 Rajeev.koodli@nokia.com 913 John Loughney 914 Nokia 915 Itdmerenkatu 11-13 916 00180 Espoo 917 Finland 918 john.loughney@nokia.com 920 Madjid F. Nakhjiri 921 Motorola Labs 922 1031 East Algonquin Rd., Room 2240 923 Schaumburg, IL, 60196 924 USA 925 madjid.nakhjiri@motorola.com 927 Charles E. Perkins 928 Nokia Research Center 929 313 Fairchild Drive 930 Mountain View, California 94043 931 USA 932 charliep@iprg.nokia.com 934 Intellectual Property Considerations 936 The IETF takes no position regarding the validity or scope of any 937 intellectual property or other rights that might be claimed to per- 938 tain to the implementation or use of the technology described in this 939 document or the extent to which any license under such rights might 940 or might not be available; neither does it represent that it has made 941 any effort to identify any such rights. Information on the IETF's 942 procedures with respect to rights in standards-track and standards- 943 related documentation can be found in BCP-11. Copies of claims of 944 rights made available for publication and any assurances of licenses 945 to be made available, or the result of an attempt made to obtain a 946 general license or permission for the use of such proprietary rights 947 by implementers or users of this specification can be obtained from 948 the IETF Secretariat. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary 952 rights which may cover technology that may be required to practice 953 this standard. Please address the information to the IETF Executive 954 Director.