idnits 2.17.1 draft-koodli-seamoby-ct-04.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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Background' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11.4. Security' ) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 503: '...the CTIN message MAY respond using CTI...' RFC 2119 keyword, line 598: '...the CTIN message MAY respond to the se...' RFC 2119 keyword, line 600: '... from the MN, it MAY send a CTIN-Ack m...' RFC 2119 keyword, line 604: '... the mobile node MUST be prepared to p...' RFC 2119 keyword, line 752: '... SHOULD be enumerated ...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2463 (ref. '2') (Obsoleted by RFC 4443) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Normative reference to a draft: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-context-transfer-problem-stat-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '9') ** Obsolete normative reference: RFC 2960 (ref. '10') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Seamoby Working Group Rajeev Koodli 2 INTERNET DRAFT Charles E. Perkins 3 30 August 2002 Communication Systems Laboratory 4 Nokia Research Center 6 A Context Transfer Protocol for Seamless Mobility 7 draft-koodli-seamoby-ct-04.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at 21 any time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard of any kind. Distribution of 31 this memo is unlimited. 33 Abstract 35 Mobile nodes enhance the performance of their connections 36 across wireless media by establishing various kinds of state 37 (context), in order to use the available bandwidth securely and 38 economically. During handover from one access router to another, a 39 bandwidth-constrained mobile node needs to have state information 40 passed from the previous router to the new one. This document 41 proposes a framework for control structures that enable authorized 42 context transfers. We demonstrate how the proposed framework could 43 be applied during handovers so that the applications running on 44 the mobile node could operate with minimal disruption, by reducing 45 latency and packet losses. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 3 55 2. Terminology 4 57 3. Background 5 59 4. Protocol Overview 7 61 5. Protocol Messages and Message Formats 10 62 5.1. Context Transfer Initiate (CTIN) Message . . . . . . . . 11 63 5.2. Context Transfer Initiate Ack (CTIN-Ack) Message . . . . 13 64 5.3. Context Transfer Request (CT-Req) Message . . . . . . . . 14 65 5.4. Context Transfer Reply (CT-Rep) Message . . . . . . . . . 16 66 5.5. Predictive Context Transfer (PCT) Message . . . . . . . . 17 67 5.6. Context Transfer Reply Acknowledgment (CT-Ack) Message . 19 69 6. Protocol Behavior with IP Handovers 20 70 6.1. Basic Handover Signaling . . . . . . . . . . . . . . . . 21 71 6.2. Fast Handover Signaling . . . . . . . . . . . . . . . . . 21 73 7. Transport Considerations 23 74 7.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 7.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 8. Configurable Parameters 26 79 9. Security Considerations 26 81 10. IANA Considerations 26 83 11. Comparison with the Requirements 27 84 11.1. General Requirements . . . . . . . . . . . . . . . . . . 27 85 11.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 29 86 11.3. Transport Reliability . . . . . . . . . . . . . . . . . . 30 87 11.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 30 88 11.5. Timing Requirements . . . . . . . . . . . . . . . . . . . 31 89 11.6. Context Update and Synchronization . . . . . . . . . . . 32 90 11.7. Interworking with handover mechanisms . . . . . . . . . . 32 91 11.8. Partial Handover . . . . . . . . . . . . . . . . . . . . 33 93 Addresses 35 94 1. Introduction 96 Access Routers typically establish state in order to effect 97 certain forwarding treatments to packet streams belonging to nodes 98 sharing the access router. For instance, an access router may 99 establish a AAA session state and a QoS state for a node's packet 100 streams. When the link connecting the node and the access router is 101 bandwidth-constrained, the access router typically also maintains 102 header compression state. When such a node moves to a different 103 access router, this state or context relocation during handover 104 provides many important benefits, including 106 - seamless operation of application streams. The handover node 107 (i.e., the Mobile Node) does not need to re-establish its 108 contexts at the new access router 110 - performance benefits. When contexts need to be re-established, 111 performance of transport protocols would suffer until the 112 contexts are in place. For instance, when the required QoS state 113 is not present, a stream's packets would not receive the desired 114 per-hop behavior treatment, subjecting them to higher likelihood 115 of unacceptable delays and packet losses. 117 - bandwidth savings. Re-establishing multiple contexts over an 118 expensive, low-speed link can be avoided by relocating contexts 119 over a potentially higher-speed wire. 121 - Reduced susceptibility to errors, since much more of the protocol 122 operates over reliable networks, replacing renegotiations over a 123 potentially error-prone link. 125 In [7], a detailed description of motivation, the need and benefits 126 of context transfer are outlined. In this document, we describe a 127 generic context transfer protocol which provides 129 - representation for feature contexts 131 - messages to initiate and authorize context transfer, and notify a 132 MN of the status of the transfer, and 134 - messages for transferring contexts prior to, during and after 135 handovers 137 The protocol is transport and IP version independent. We show how it 138 can be carried using ICMP and SCTP. The protocol can carry both IPv4 139 and IPv6 contexts. 141 The proposed protocol is designed to work in conjunction with other 142 [seamoby] and [mobile-ip] protocols in order to provide ``seamless 143 mobility''. For example, the messages defined in this protocol are 144 closely synchronized with Mobile IP fast handover protocols [5] 145 to achieve improved handover results. Furthermore, the proposed 146 protocol would make use of the Candidate Access Router selection 147 protocol [12] to obtain the IP address of the target router to which 148 the MN will attach to during handover. The protocol described here 149 satisfies the requirements set forth in [11] in Section 11. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 154 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and 155 "silently ignore" in this document are to be interpreted as described 156 in RFC 2119 [1]. 158 We define the following terms for use in this document. We also use 159 Figure 1 as the basis for our handover discussion. 161 CPT Context Profile Type: a general way to lay out context 162 parameters, which constitute a particular context, for 163 use when describing various feature contexts. 165 ICMP Internet Control Message Protocol 167 IP Access Address 168 An IP address used for routing packets to a mobile node 169 while it is attached to an access network. 171 Microflow A communication stream of related packets, considered as 172 a separable and identifiable sequence of packets within 173 the entire aggregate data communications between two 174 endpoints. 176 New Access Router (NAR) 177 The router to which the MN attaches after handover 179 Predictive Same as proactive. 181 Previous Access Router (PAR) 182 The MN's default router prior to handover 184 New access address (Naddr) The IP Access address of the Mobile 185 Node (MN) when attached to the link served by the New 186 Router 188 Previous access address (Paddr) 189 The IP Access Address of the Mobile Node (MN) when 190 attached to the link served by the Previous Router 192 v +------------+ 193 +-+ | Previous | < 194 | | ---------- | Router | ------ > ----\ 195 +-+ | (PAR) | < \ 196 MN | | \ 197 | +------------+ +---------------+ 198 | ^ IP | Correspondent | 199 | | Network | Node | 200 V | +---------------+ 201 v / 202 v +------------+ / 203 +-+ | New | < / 204 | | ---------- | Router | ------ > ----/ 205 +-+ | (NAR) | < 206 MN | | 207 +------------+ 209 Figure 1: Reference Scenario for Handover 211 3. Background 213 There may be multiple features associated with each unidirectional 214 packet stream (also known as a microflow). Examples are QoS, 215 security and header compression. Note that each feature itself 216 may be supported by multiple, co-existing mechanisms, for various 217 microflows. As an example, a header compression feature may 218 have separate contexts for IPv6/UDP/RTP and IPv6/TCP compression 219 mechanisms at the same router. Generally, a feature context 220 typically needs to identify and refer to the mechanism for which its 221 state is relevant. One or more feature contexts may belong to a 222 microflow context, and contexts for several features together form 223 the overall context for a mobile node. This overall context may also 224 include contexts that are not microflow-specific; for example, it may 225 include session-specific contexts such as AAA state. The context 226 hierarchy, consistent with the nomenclature in [7], is illustrated in 227 Figure 2 (where feature realizations through one or more mechanisms 228 are not shown for clarity). This hierarchy indicates the need for a 229 representation that organizes the diversity of features and feature 230 realizations. It is also clear from Figure 2 that a feature context 231 is the unit of data representation for context transfer purposes. 233 A context transfer protocol operates along with other protocols to 234 enhance handover experience. One such important protocol is IP 235 +--------------+ 236 | | 237 | Context | 238 | | 239 | | 240 +--------------+ 241 | 242 | 243 +-----------------------------------------+ 244 | | | 245 +------------+ +------------+ +------------+ 246 | | | | | | 247 |Microflow-1 | |Microflow-2 | ... |Microflow-n | 248 | context | | context | | context | 249 | | | | | | 250 +------------+ +------------+ +------------+ 251 | | | 252 +----------+ +----------------+ 253 | | | | 254 | Feature | +----------+ +----------+ 255 |context X | | | | | 256 | | | Feature | | Feature | 257 +----------+ |context Y | |context X | 258 | | | | 259 +----------+ +----------+ 261 Figure 2: Context Hierarchy for a Mobile Node 263 handover protocol which establishes a routing path to the mobile 264 node's new location, allowing the MN to send and receive IP packets, 265 including the packets that make up its identified microflows. 266 As soon as IP connectivity is available, a MN can resume packet 267 transmission and reception. Each microflow needs to be treated 268 with appropriate contexts to ensure smooth continuation of the MN's 269 packet streams. In some networks, an access router may require 270 authentication from the MN before making connectivity available. 271 In such networks, the MN's new access router needs appropriate 272 context to avoid reinitiating time-consuming elaborate authentication 273 protocol operations. 275 Context transfer with respect to handover is complementary and very 276 natural; handover establishes IP connectivity (a routing issue), 277 while context transfer allows uninterrupted connectivity and smooth 278 operation of packet streams (a transport issue). Since routing 279 and transport issues are closely related, handover and context 280 transfer must also interwork closely. If handover fails due to 281 context transfer protocol, connectivity cannot be established. On 282 the other hand, if contexts cannot be relocated, they can always 283 be re-established. This illustrates that handover is a more basic 284 operation than context transfer. 286 A context transfer protocol must be capable of carrying all the 287 feature contexts relevant to a MN. The protocol message data must 288 accommodate different feature contexts, and be able to aggregate 289 multiple such contexts. We propose that message data is structured 290 according to a ``framework'' for carrying individual feature 291 contexts. Each individual feature context must define its structure 292 and format for interpreting the context unambiguously. Successful 293 processing of transferred contexts must produce a result that is 294 equally useful as establishing the contexts from first principles, 295 and, from the point of view of the mobile node, just as if it had 296 stayed at the previous access router. 298 4. Protocol Overview 300 Given the diversity of various features and their associated 301 contexts (See Figure 2), we propose a simple representation that 302 provides a generic structure, allowing each feature to define its 303 own context parameters. We define a Context Profile Type (CPT) as 304 an object that uniquely identifies the type of a feature context. 305 An instance of a CPT defines the context parameters associated with 306 the corresponding feature context to facilitate inter-operability. 307 For example, a QoS Profile Type (QPT) for Diffserv has to identify 308 the control parameters associated with the QoS feature, and a Header 309 Compression Profile Type (HPT) for IPv6 has to identify the IPv6 310 header compression control parameters. Each instance of a CPT can 311 also be used as a standard object in feature context requests, 312 feature negotiation etc, which are beyond the scope of this document. 313 Nevertheless, each feature context itself then consists of the [CPT, 314 context parameters] tuple along with some generally useful parameters 315 (such as a filter that identifies the packet stream). 317 The Context Transfer protocol typically operates between a source 318 node and a target node. In the future, there may be multiple target 319 nodes involved; the protocol described here would work with multiple 320 target nodes. For simplicity, we describe the protocol assuming a 321 single receiver or target node. 323 Typically, the source node is a MN's Previous Access Router (PAR) 324 and the target node is MN's New Access Router (NAR). We assume 325 that PAR and NAR share an appropriate security association, set 326 up independently and prior to context transfer. Any appropriate 327 mechanism may be used in setting up this security association; it 328 enables the CT peers to utilize a secure channel for transferring 329 contexts, providing authentication, integrity, and (if needed) 330 confidentiality. 332 There are two messages associated with initiating the context 333 transfer, and four messages associated with the actual context 334 transfer protocol. The context transfer protocol messages use 335 Context Profile Types that identify the relevant feature contexts. 336 The Context Profile Types (CPTs) are standard identifiers (with 337 IANA Type Numbers) that allow a node to unambiguously determine the 338 type of context and the context parameters present in the protocol 339 messages. In addition to the CPT, each message contains a list of 340 feature contexts each in (Type, Length) format, as well as any IP 341 addresses necessary to associate the contexts to a particular MN. The 342 context transfer initiation messages contain parameters that identify 343 the source and target nodes, the desired list of feature contexts and 344 IP addresses to identify the contexts. Some of the messages contain 345 an appropriate token to authorize context transfer. 347 The Previous Access Router transfers feature contexts under two 348 general scenarios. First, it may receive a Context Transfer Initiate 349 (CTIN) message from a trusted entity, which could be the MN whose 350 feature contexts are to be transferred, a network server overseeing 351 the MN's handover, or an internally generated trigger (e.g., a 352 link-layer trigger on the interface to which the MN is connected), 353 etc. The CTIN message, described in Section 5.1, provides the IP 354 address of NAR, the IP address of MN on PAR, the list of feature 355 contexts to be transferred (by default requesting all contexts to 356 be transferred), and a token authorizing the transfer. It also 357 includes the MN's new IP address (valid on NAR) whenever it is known. 358 In response to a CTIN message, PAR transmits a Predictive Context 359 Transfer (PCT) message that contains feature contexts. The PCT 360 message, described in Section 5.5, contains the MN's previous IP 361 address and its new IP address (whenever known). It also includes a 362 key, and an indication to use a particular algorithm to assist NAR in 363 computing a token that it could use to check authorization prior to 364 making the contexts available to the MN. 366 In the second scenario, PAR receives a Context Transfer Request 367 (``CT-Req'', described in Section 5.3), message from NAR. In the 368 CT-Req message, NAR supplies the MN's previous IP address, the 369 feature contexts to be transferred, and a token (typically generated 370 by the MN) authorizing context transfer. In response to CT-Req 371 message, PAR transmits a Context Transfer Reply (CT-Rep) message that 372 includes the MN's previous IP address and feature contexts. In this 373 ``reactive'' transfer of contexts, PAR verifies authorization token 374 before transmitting the contexts, and hence does not include the key 375 and the name of algorithm in CT-Rep message. 377 When context transfer takes place without NAR requesting it (scenario 378 one above), NAR should require MN to present its authorization 379 token. Doing this locally at NAR when the MN attaches to it improves 380 performance, since the contexts may already be present. When context 381 transfer happens with an explicit request from NAR (scenario two 382 above), PAR performs such a verification since the contexts are still 383 present at PAR. In either case, token verification takes place at the 384 node possessing the contexts. 386 The New Access Router requests feature contexts when it receives 387 a CTIN message from, for instance a newly attached MN, a server 388 overseeing the handover of MN, or a link-layer indication from the 389 interface to which the MN attaches to. In response to the CTIN 390 message, NAR generates a CT-Req message to PAR. When it receives 391 a corresponding CT-Rep message, NAR may generate a CT-Ack message 392 (See Section 5.6) to report the status of processing the received 393 contexts. 395 The node that receives a CTIN message may reply back with Context 396 Transfer Initiate Ack (CTIN-Ack) message. This message is intended 397 to report the status resulting from processing the CTIN message. 398 Furthermore, this message is used to notify the MN if there are 399 changes to certain feature contexts as a result of context transfer. 400 The CTIN-Ack message is described in Section 5.2. 402 Performing context transfer in advance of the MN attaching to NAR 403 clearly has potential for better performance. For this to take 404 place, certain conditions must be met. For example, PAR must have 405 sufficient time and knowledge about the impending handover. This is 406 feasible for instance in Mobile IP fast handovers; we describe how 407 in Section 6.2. However, when the advance knowledge of impending 408 handover is not available, or if a mechanism such as fast handover 409 fails, retrieving feature contexts after the MN attaches to NAR 410 is the only available means for context transfer. Performing 411 context transfer after handover might still better than having to 412 re-establish all the contexts from scratch. We describe this type 413 of context transfer that can be employed in conjunction with basic 414 Mobile IP further in Section 6.1. Finally, some contexts may simply 415 need to be transferred during handover signaling. For instance, 416 any context that gets updated on a per-packet basis must clearly be 417 transferred only after packet forwarding to the MN on its previous 418 link is terminated. Transfer of such contexts must be properly 419 synchronized with appropriate handover messages, such as Mobile IP 420 (Fast) Binding Update. We describe this in Section 6.2. 422 The context transfer protocol messages described in this document 423 provide the basic structure necessary for context transfer to work 424 with other mechanisms, most notably IP handovers. The messages 425 can carry either IPv4 contexts or IPv6 contexts or both kinds of 426 contexts. The messages are transport protocol independent; we show 427 how they can be formulated with ICMP or SCTP as examples. They work 428 just as well with IPv4 and IPv6, as long as the relevant address 429 fields are sized appropriately. 431 5. Protocol Messages and Message Formats 433 In this document, we propose the following messages. 435 1. Context Transfer Request (CT-Req). A node uses this message to 436 request feature contexts from another node. 438 2. Context Transfer Reply (CT-Rep). A node uses this message to 439 respond to Context Transfer Request or CT-Req message. 441 3. Predictive Context Transfer (PCT). A node uses this message to 442 transfer feature contexts without having the CT-Req message 443 received. 445 4. Context Transfer Acknowledgment (CT-Ack). A node uses this 446 message to report status after processing either CT-Rep or PCT 447 messages. This message is not mandatory. 449 These messages can be carried over appropriate transport protocol; 450 we describe ICMP and SCTP as specific examples. See Sections 7.1 451 and 7.2. The messages can carry IPv4 or IPv6 or both types of 452 contexts (for dual stack nodes for example). These messages are 453 also IP version independent, i.e., they work with IPv4 and IPv6. 454 Furthermore, these messages are independent of the IP version used in 455 interconnecting the access routers. 457 In addition to the above messages, we define the following which may 458 be used to initiate context transfer. 460 1. Context Transfer Initiate (CTIN) Message. This message serves 461 as a general-purpose trigger to initiate context transfer. In 462 response to this message, either CT-Req or PCT messages could be 463 transmitted. 465 2. Context Transfer Initiate Ack (CTIN-Ack) Message. This message 466 is an acknowledgment to CTIN message. This message does not 467 always have to occur after CTIN. However, when CTIN contains 468 request for specific feature context transfer, such a request may 469 require an acknowledgment; in those cases, CTIN-Ack would not be 470 optional. 472 We first explain the CTIN and CTIN-Ack messages. Note, however, that 473 in some systems these messages may not be needed, if other triggers 474 are available to initiate context transfer. 476 5.1. Context Transfer Initiate (CTIN) Message 478 The CTIN message contains feature context transfer requests. Each 479 feature context request is represented in the ``Type, Length, Value'' 480 (TLV) format as a suboption to the CTIN message. The envelope of 481 these suboptions is prefixed by some fields that are generally 482 expected to be useful for all suboptions. Finally, this message 483 contains a token representing the authorization to effect context 484 transfers. 486 The CTIN message can be used either by a MN or by some other entity 487 to initiate context transfer. The message may be generated in 488 response to specific events such as a link-layer trigger indicating 489 handover, discovery of a new default router by MN etc. When CTIN is 490 delivered to the source of the context transfer, the message contains 491 the new IP addresses of the MN and its New Access Router. When this 492 message is delivered to the target of the context transfer, the 493 message contains the previous IP addresses of the MN and its Previous 494 Access Router. In either case, the authorization token is intended 495 for the node that currently possesses the feature contexts. For 496 instance, when CTIN arrives, NAR could verify the authorization token 497 if it already possesses the feature contexts. When CTIN arrives, 498 but NAR does not yet possess feature contexts, then NAR includes the 499 authorization token in CT-Req message for PAR to perform verification 500 of the authorization token. We rely on a secured data path between 501 PAR and NAR to insure integrity of the CT-Rep. 503 The node receiving the CTIN message MAY respond using CTIN-Ack 504 message. A MN however, must be able to operate its microflows 505 without necessarily having to wait for the CTIN-Ack message. 507 The format of CTIN message is shown in Figure 3. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type=CTIN | Length | V |T| Reserved | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Previous (New) IP Access Address of MN 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Previous (New) Router Address 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 |Sub-Option Type| Sub-Option Len| CT Data for Target Router... 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |SOType = Auth | Sub-Option Len| Reserved | Replay | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | 32-bit Authorization Token | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |Sub-Option Type| Sub-Option Len| CT Data for Source Router... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 3: Context Transfer Initiate (CTIN) Message Format 529 Option Type Context Transfer Initiate (CTIN). 531 Option Length Variable 533 Reserved Reserved for future use. Must be set to zero 534 by the MN. 536 `V' bits When set to `00', indicate presence of IPv6 537 Previous (New) address only. 538 When set to `01' indicate presence of IPv4 539 Previous (New) Address only. 540 When set to `10' indicate presence of both 541 IPv6 and IPv4 Previous (New) addresses. 543 `T' bit When set to 1 (one), indicates that suboptions 544 for the target node of CT are present. 546 Replay A value used to make sure that each use of the 547 CTIN message is uniquely identifiable. 549 Authorization Token 550 An unforgeable value calculated as discussed 551 below. This authorizes the receiver of CTIN 552 to perform context transfer. 554 Suboptions Feature suboptions requesting context transfer 555 included as selected by the requesting node. 556 A default suboption could include request 557 for all contexts present. Each suboption 558 corresponds to one feature context, and is 559 assigned a unique integer value. So, for each 560 IP address listed, a maximum of 255 feature 561 contexts can be requested for transfer. Each 562 feature context defines its own parameters in 563 the data field. 564 These requests are typically meant for the 565 node possessing the feature contexts. In 566 some cases however, the node that would be 567 receiving the feature contexts may be supplied 568 with additional information to process 569 feature contexts. In order to facilitate this 570 programmability, an option is made available 571 for suboptions addressed to the target node of 572 context transfer. 574 In order to make sure that contexts are not transferred or lost 575 in response to a malicious request, authorization is required for 576 the context transfer request. The Authorization Token (Auth) is 577 calculated as follows: 578 Auth = HMAC (Key, input_data) mod 2^32 580 where HMAC (Key, Data) is defined (see RFC 2104 [6] for details) 581 roughly as follows: 582 HMAC (Key, Data) = MD5 (Key, MD5 (Key || Data)) 584 and MD5 is defined as given in RFC 1321 [9]. The input_data is 585 defined as follows: 586 input_data = CT_features || Replay || Paddr 588 where CT_features includes all the feature suboption data to the node 589 possessing MN's feature contexts, and Paddr is the mobile node's IP 590 access address while attached to the network served by PAR. When all 591 the contexts are already present at the New Access Router, the New 592 Access Router itself can verify authorization token if it has the 593 session key (and the knowledge of the algorithm) used in computing 594 the token. 596 5.2. Context Transfer Initiate Ack (CTIN-Ack) Message 598 A CT node receiving the CTIN message MAY respond to the sender of the 599 CTIN message with CTIN-Ack message. As an example, if NAR receives 600 CTIN from the MN, it MAY send a CTIN-Ack message to MN containing 601 status reports for each relevant feature for which context transfer 602 was requested. However, unless a failure has occurred, or else 603 otherwise required by a specific feature, CTIN-Ack is optional. 604 On the other hand, the mobile node MUST be prepared to process a 605 CTIN-Ack even when no error has occurred. The format of CTIN-Ack 606 message is shown in Figure 4. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type=CTIN | Length | Reserved | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |Sub-Option Type| Sub-Option Len|Response from receiver of CTIN.. 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 4: Context Transfer Initiate Acknowledgment 617 (CTIN-Ack) Message Format 619 5.3. Context Transfer Request (CT-Req) Message 621 A MN's New Access Router (NAR) sends this message to retrieve feature 622 contexts from the MN's Previous Access Router (PAR). The message 623 contains the MN's IP address on PAR and optionally a token from the 624 MN authorizing the transfer of contexts. The authorization token 625 allows PAR to verify if context transfer was actually authorized by 626 the MN. The format of CT-Req message is shown in 5. 628 The IP header contains NAR as the Source Address, and PAR as the 629 Destination Address. These can be either IPv4 of IPv6 addresses. 631 Option Type Context Transfer Request (CT-Req) 633 Option Length Variable 635 Reserved Reserved for future use, set to zero by New 636 Router. 638 Previous IP Address The MN's IP (IPv4 or IPv6 or both) address 639 valid on Previous Router. This address is used as 640 a key in retrieving the MN's feature contexts. 642 `V' bits When set to `00', indicate presence of IPv6 643 Previous address only. 644 When set to `01' indicate presence of IPv4 645 Previous Address only. 646 When set to `10' indicate presence of both IPv6 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type=CTREQ | Length | V | Reserved | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Previous IP Address of MN (Paddr) ... 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | New IP Address of MN (Naddr) ... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Suboption Type| Subopt.Length | Context Profile Type | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Context Transfer Options Data... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Additional context transfer suboptions as needed... 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |SuboptType=Auth| Ctxt Length | Reserved | Replay | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | 32-bit Authorization Token from MN | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 5: Context Transfer Request (CT-Req) Message Format 670 and IPv4 Previous addresses. 672 Context Transfer Options Data (optional) 673 Feature context requests included as selected 674 by the mobile node and the New Router, in the 675 order specified. These are encoded in Sub-Option 676 Type and Sub-Option Length format, as in the 677 structure of CTIN message (See Figure 3). These 678 are present in the non default scenarios. Each 679 feature context, following the Context Profile 680 Type, supplies its own data which could include 681 parameters that identify the microflow. 683 Context Profile Type (CPT) 684 This is a standard identifier for the type of 685 context whose transfer is desired. Each CPT is 686 assigned an IANA type number. 688 Replay A value used to make sure that each context 689 transfer request by the MN is uniquely 690 identifiable. 692 Authorization Token 693 An unforgeable value calculated as discussed 694 in 5.1. 696 5.4. Context Transfer Reply (CT-Rep) Message 698 The MN's Previous Access Router uses this message to respond to 699 CT-Req message. In this message, providing CT-Req processing is 700 successful, PAR transmits the requested feature contexts matching the 701 MN's previous IP address(es). Each feature context is formatted in 702 the TLV format, and the context data is preceded by a corresponding 703 Context Profile Type. The format of CT-Rep message is shown in 704 Figure 6. 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type=CTREP | Length | V | Reserved | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Previous IP Address of MN (Paddr) 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Suboption Type| Subopt.Length | Context Profile Type | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Context Transfer Options Data... 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Suboption Type| Subopt.Length | Context Profile Type | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Context Transfer Options Data... 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Figure 6: Context Reply Message Format 724 Option Type Context Transfer Reply (CT-Rep) 726 Option Length Variable 728 Previous IP Address The MN's IP (IPv4 or IPv6) address valid on 729 Previous Router. This address is used as a key in 730 retrieving the MN's feature contexts. 732 `V' bits When set to `00', indicate presence of IPv6 733 Previous address only. 734 When set to `01' indicate presence of IPv4 Previous 735 Address only. 736 When set to `10' indicate presence of both IPv6 and 737 IPv4 Previous addresses. 739 Context Profile Type 740 This is a standard object that identifies the type 741 of context whose transfer desired. Each CPT is 742 assigned an IANA type number. 744 Context Transfer Options Data 745 Feature contexts (enumerated as suboptions) for 746 each corresponding suboption present in CT-Req 747 in the order specified. These are encoded in 748 Sub-Option Type and Sub-Option Length format, as in 749 the structure of CTIN message (See Figure 3). When 750 both IPv4 and IPv6 contexts are present, all the 751 IPv4 contexts (identified by their respective CPTs) 752 SHOULD be enumerated before the IPv6 contexts. 754 Because of retransmissions, the New Router may receive the same 755 CT-Rep message and suboptions several times as part of the same 756 seamless handover. Therefore, all context suboptions are required 757 to be specified in such a way that the effect is the same whether 758 the New Router receives them one time or several times in a CT-Rep 759 message as part of the same seamless handover. 761 5.5. Predictive Context Transfer (PCT) Message 763 The Previous Access Router uses this message to transfer (typically 764 all) feature contexts when it has not received a CT-Req message. In 765 order to do so, PAR must be aware of the New Access Router to which 766 the MN will attach, and should preferably use this message prior to 767 the completion of MN's IP connectivity establishment with NAR. 769 The format of PCT message is similar to that of CT-Rep with the 770 addition of fields necessary that would allow NAR to verify whether 771 the MN is authorized to make use of transferred feature contexts. 772 The Previous Access Router supplies a key and indicates the algorithm 773 to use in computing a token that NAR could demand from the MN prior 774 to making the feature contexts available. 776 Option Type Predictive Context Transfer (PCT) 778 Option Length Variable 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type=PCT | Length | V | Reserved | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | New IP Address of MN (Naddr) 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Previous IP Address of MN (Paddr) 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Context Transfer Options Data... 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 |Ctxt Type=Auth | Ctxt Length | Algorithm | Key Length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Key... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Figure 7: Predictive Context Transfer Message Format 797 Previous IP Address The MN's IP (IPv4 or IPv6) address valid on 798 Previous Router. This address is used as a key in 799 retrieving the MN's feature contexts. 801 New IP Address The MN's IP (IPv4 or IPv6) address valid on 802 New Router. This address is used to update the 803 received feature contexts. 805 `V' bits When set to `00', indicate presence of IPv6 806 Previous address only. 807 When set to `01' indicate presence of IPv4 Previous 808 Address only. 809 When set to `10' indicate presence of both IPv6 and 810 IPv4 Previous addresses. 812 Context Profile Type 813 This is a standard object that identifies the type 814 of context whose transfer is intended. Each CPT is 815 assigned an IANA type number. 817 Context Transfer Options Data 818 Individual feature contexts in the form of sub 819 options. These are encoded in Sub-Option Type and 820 Sub-Option Length format, as in the structure of 821 CTIN message (See Figure 3). When both IPv4 and 822 IPv6 contexts are present, all the IPv4 contexts 823 (identified by their respective CPTs) SHOULD be 824 enumerated before the IPv6 contexts. 826 Algorithm 827 8-bit algorithm indication for computing the 828 Authorization Token (See Section 5.1). Default is 829 HMAC with MD5. 831 Key Length 833 8-bit unsigned integer. The length of the key in 834 units of 4 octets. 836 Key Encrypted key. The Key is encrypted using a 837 pre-existing shared key between the Previous Access 838 Router and New Access Router. 840 5.6. Context Transfer Reply Acknowledgment (CT-Ack) Message 842 The New Access Router MAY use this message to acknowledge receipt of 843 feature contexts in CT-Rep, and MUST use this message to acknowledge 844 receipt of feature contexts in PCT message. The format of this 845 message is shown in Figure 8. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type=CT-Ack | Length | V |S| Reserved | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Previous IP Address of MN (Paddr) 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Context Transfer Acknowledgment Data... 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 8: Context Transfer Reply Ack Message Format 859 Option Type Context Transfer Reply Ack (CT-Ack). 861 Option Length Variable 863 Previous IP Address 864 The MN's IP (IPv4 or IPv6 or both) address valid on 865 Previous Router. This address is used as a key in 866 retrieving the MN's feature contexts. 868 `V' bits When set to `00', indicate presence of IPv6 869 Previous address only. 870 When set to `01' indicate presence of IPv4 Previous 871 Address only. 872 When set to `10' indicate presence of both IPv6 and 873 IPv4 Previous addresses. 875 `S' bit When set to one, this bit indicates that all 876 the feature contexts sent in CT-Rep or PCT were 877 received successfully. 879 Reserved Set to zero. 881 Context Transfer Options Data 882 Feature suboptions acknowledgments appropriate 883 for each suboption present in CT-Rep or PCT. Each 884 suboption is an 8-bit integer that indicates 885 an error code corresponding to (successful or 886 otherwise) receipt of a feature context. The order 887 of the suboptions must be the same as the order in 888 which the feature contexts are enumerated in CT-Rep 889 or PCT message. These suboptions are only present 890 when the "S" bit is not set to one. 892 6. Protocol Behavior with IP Handovers 894 This section specifies the use of protocol messages described in 895 the previous sections with handover signaling. There are two types 896 of signaling for context transfer purposes. Sometimes, the context 897 transfer takes place without being requested by the New Access 898 Router. In this ``predictive context transfer'' scenario, the 899 Previous Access Router, perhaps in response to a request from the 900 mobile node (or some other network entity), transfers contexts to the 901 New Access Router without explicit request from the latter. Such a 902 transfer could take place before the mobile node attaches to the New 903 Router, so that the desired context could be utilized as soon as the 904 mobile node obtains new IP connectivity. The New Access Router MUST 905 acknowledge this predictive context transfer, by sending CT-Ack. 907 Other times, the context transfer takes place as a reaction to 908 explicit signaling after the MN attaches to its New Router. In this 909 ``reactive context transfer'' case, the New Access Router sends a 910 CT-req to the Previous Router. This scenario can be considered as an 911 extension to the basic handover signaling [3]. This also provides a 912 fallback approach when the fast handover signaling (or the predictive 913 approach) experiences a failure. 915 6.1. Basic Handover Signaling 917 Suppose the MN originates the CTIN message after it establishes link 918 connectivity with NAR. After the mobile node acquires or formulates 919 a new IP access address, it sends a CTIN message shown in Figure 3 920 to NAR. When NAR receives this CTIN message, it identifies the 921 suboptions and constructs a CT-Req message for the Previous Access 922 Router to request context relocation. In the default case, there 923 would be no suboptions present, indicating the MN's desire to request 924 all the contexts. The CT-Req message is described in section 5.3 and 925 MUST use IPsec AH to assure integrity and authorization. 927 When the Previous Access Router (PAR) receives the CT-Req message, it 928 MUST check to see whether it has a security association with NAR. If 929 so, PAR MUST check for the presence and validity of an Authentication 930 Option [4]. Then the Previous Access Router MUST check for the 931 presence and validity of the Authorization Token supplied by 932 the mobile node to make sure that the context transfer has been 933 authorized by the mobile node. The Previous Access Router then 934 constructs a Context Transfer Reply (CT-Rep) message containing the 935 requested or all feature contexts. These operations are illustrated 936 in Figure 9. 938 It is important that context for the mobile node be not destroyed 939 at the Previous Access Router without authorization. Hence, after 940 sending the requested state to the New Access Router in the CT-Rep 941 message, PAR MUST keep the context data for the mobile node intact 942 for CONTEXT_SAVE_TIME. This allows recovery in case a CT-Rep message 943 is not received by the router sending the CT-Req message. The 944 Previous Access Router SHOULD NOT perform garbage collection of 945 context data until CONTEXT_PURGE_TIME. 947 6.2. Fast Handover Signaling 949 In the predictive context transfer scenario, PAR sends a PCT message. 950 The trigger for this predictive transfer MAY arrive from the mobile 951 node in a CTIN message. The trigger may also arrive from any other 952 entity that PAR trusts. See Figure 10. 954 The PCT message may be embedded in a suitable handover message, such 955 as the HI message [5] (see sections 7.1, 7.2). 957 When the New Access Router receives a valid PCT message, it MUST 958 maintain the contents for at least PRED_CT_TIME, or until it receives 959 the corresponding CTIN message from the mobile node whichever event 960 occurs first. In order for the predictive context transfer operation 961 to be secure, the Previous Access Router MUST have a security 962 association with the New Access Router, and it MUST include an IPsec 963 +----------+ 2. CT-Req +----------+ 964 | | <--------- | | 965 | | | | 966 | PAR |-----------------| NAR | 967 | | | | 968 | | ---------> | | 969 +----------+ 3. CT-Rep +----------+ 971 | ^ | 972 | | | 973 ~~ 1. CTIN | ~~ 974 | 975 V V 976 +-+ +-+ 977 | | movement | | 978 +-+ -------> +-+ 980 Figure 9: Context Transfer with Basic Handover Signaling 982 +----------+ 3. CT-Ack +----------+ 983 | | <--------- | | 984 | | | | 985 1. CTIN | PAR |-----------------| NAR | 986 -------> | | | | 987 | | ---------> | | 988 +----------+ 2. PCT +----------+ 990 | ^ | 991 | | | 992 ~~ | ~~ 993 4. CTIN | 994 V V 995 +-+ +-+ 996 | | movement | | 997 +-+ -------> +-+ 999 Figure 10: Context Transfer with Fast Handover Signaling 1001 Authentication Header (AH) in the packet containing the PCT message. 1002 For instance, when the New Access Router receives a HI message with 1003 PCT option, it MUST check for the presence and validity of AH using 1004 the security association it has with the Previous Router. 1006 After a NAR has received contexts in PCT, it may not not activate all 1007 necessary contexts until it can verifiably establish the presence 1008 of the MN by processing a CTIN message. The MN SHOULD send a CTIN 1009 message when it connects to NAR in order to present its context 1010 authorization token. The New Access Router MUST compute its own 1011 token using the key supplied in the PCT message and compare it 1012 against that supplied by the MN prior to activating the contexts. 1013 If, due to failure, context is not present at NAR, the CTIN message 1014 triggers context transfer by requiring the New Access Router to send 1015 a CT-Req message. 1017 Subsequent to processing the CTIN message, the New Access Router MAY 1018 send a CTIN-Ack message to the MN. The New Access Router MUST send a 1019 CTIN-Ack if any or all of the feature contexts cannot be established 1020 appropriately. 1022 7. Transport Considerations 1024 7.1. ICMP 1026 The basic ICMP message format is shown in Figure 11. 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type | Code | Checksum | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Data .. 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Figure 11: ICMP Message Format 1038 The context transfer protocol messages (CT-Req, CT-Rep, PCT, CT-Ack) 1039 as well as context transfer initiation (CTIN) and notification 1040 (CTIN-Ack) messages are encapsulated within the Data portion. 1041 Appropriate Type and Code values (TBD) are assigned to each message. 1042 For the checksum field, see [2] and [8]. 1044 7.2. SCTP 1046 We use SCTP Payload Data Chunk to carry the context transfer protocol 1047 messages [10]. The User Data part of each SCTP message contains 1048 an appropriate context transfer protocol message defined in this 1049 document. For instance, the CT-Rep message with all the feature 1050 contexts belonging to a MN is encapsulated within the User Data part 1051 of an SCTP message. In general, each SCTP message can carry feature 1052 contexts belonging to any MN. 1054 We propose a single stream for context transfer without in-sequence 1055 delivery of SCTP messages. Each message, unless fragmented, 1056 corresponds to a disparate MN's feature context. A single stream 1057 provides simplicity. Having un-ordered delivery allows the receiver 1058 to not block for in-sequence delivery of messages that belong to 1059 different Mobile Nodes. The Payload Protocol Identifier is set to 1060 ``Context Transfer Protocol'', and serves as a means to identify 1061 the contents of the data chunk as belonging to the context transfer 1062 protocol. 1064 The format of Payload Data Chunk taken from [10] is shown in 1065 Figure 12. The fields of interest to context transfer protocol are 1066 described below. 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type = 0 | Reserved|U|B|E| Length | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | TSN | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Stream Identifier S | Stream Sequence Number n | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Payload Protocol Identifier | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 \ \ 1080 / User Data (seq n of Stream S) / 1081 \ \ 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Figure 12: SCTP Payload Data Chunk 1086 `U' bit The Unordered bit. MUST be set to 1 (one). 1088 `B' bit The Beginning fragment bit. See [10]. 1090 `E' bit The Ending fragment bit. See [10]. 1092 TSN Transmission Sequence Number. See [10]. 1094 Stream Identifier S 1095 Identifies the context transfer protocol stream. 1097 Stream Sequence Number n 1098 Since the `U' bit is set to one, the receiver ignores 1099 this number. See [10]. 1101 Payload Protocol Identifier 1102 Set to an unsigned integer corresponding to ``Context 1103 Transfer Protocol''. 1105 User Data Contains the context transfer protocol messages 1106 CT-Req, CT-Rep, PCT and CT-Ack. 1108 8. Configurable Parameters 1110 Every access router supporting the mobility extensions defined 1111 in this document SHOULD be able to configure each parameter in 1112 the following table. Each table entry contains the name of the 1113 parameter, the default value, and the section of the document in 1114 which the parameter first appears. 1116 Parameter Name Default Value Definition 1117 ------------------- ---------------------- ------- 1118 CT-Req_RETRIES 3 Section 5.3 1119 CT-Req_REXMIT_TIME 1 seconds Section 5.3 1120 CONTEXT_SAVE_TIME 2 * CT-Req_REXMIT_TIME Section 6.1 1121 CONTEXT_PURGE_TIME 5 * CT-Req_REXMIT_TIME Section 6.1 1122 PRED_CT_TIME 3 seconds Section 6.2 1124 9. Security Considerations 1126 The Previous Router and the New Router MUST use authentication for 1127 messages carrying CT-Req, CT-Rep and PCT; the exact algorithms 1128 employed will depend on their security association. In addition, 1129 when Previous Router uses PCT option, it MUST encrypt the Key using a 1130 pre-existing shared secret with the New Router. 1132 Since authentication data is supplied by the mobile node along with 1133 its smooth handover requests, there is substantially no danger of 1134 loss of handover context due to malicious attacks. If a node uses 1135 the same features and Previous_IP_Address (see section 5.1) more than 1136 255 times, then it SHOULD establish a new security association with 1137 the Previous Router (Prtr) (i.e., the mobile node's default router at 1138 the Previous IP Access Address (Paddr)). However, if the mobile node 1139 fails to change its security association with the Previous Router in 1140 this situation, an attacker could keep track of all 256 available 1141 replay protection values and cause a future disconnection the next 1142 time the mobile node acquires the same care-of address at the same 1143 Previous Router. 1145 10. IANA Considerations 1147 The Context Profile Type introduced in this document requires IANA 1148 Type Numbers for each set of feature contexts that make use of 1149 Profile Types. 1151 11. Comparison with the Requirements 1153 In this section, we compare the solution we have proposed against the 1154 requirements specified in [11]. 1156 11.1. General Requirements 1158 1. ``The context transfer solution MUST define the characteristics 1159 of the IP level trigger mechanisms that initiate the transfer of 1160 context.'' 1162 The CTIN message specified in Section 5.1 can be used as a 1163 general-purpose IP trigger to initiate context transfer. 1164 For instance, when the MN's access router recognizes that 1165 the MN has terminated the link connection (through a link 1166 layer specific mechanism for example), an ``upcall'' 1167 containing essentially the CTIN structure can be made to 1168 the context transfer process that then begins the actual 1169 transfer process. The essential elements of the IP trigger 1170 would include the IP address of the MN's target access 1171 router, the MN's new IP address and an enumeration of 1172 various feature contexts that need to be transferred. The 1173 default case, that needs no enumeration, allows transfer of 1174 all feature contexts. The authorization token need not be 1175 present for an ``internal'' trigger. 1177 2. ``The IP level context transfer triggers MAY be initiated by a 1178 link level (layer two) event.'' 1180 The proposal in this document would inter-work with link 1181 layer triggers (if and when used). 1183 3. ``The IP level trigger mechanisms for context transfer MUST hide 1184 the specifics of any layer 2 trigger mechanisms.'' 1186 The CTIN option specified is independent of any link layer 1187 trigger. 1189 4. ``The IP level context transfer triggers MAY be initiated by IP 1190 level (layer three) signaling.'' 1192 The CTIN message specified in this document can be carried 1193 in any appropriate IP signaling message, such as a Fast 1194 Binding Update [5], or in an IP message of its own. 1196 5. ``Any IP level signalling for Context Transfer MUST be separated 1197 from the actual transfer of context.'' 1198 The CT-Rep and PCT messages, which carry the feature 1199 contexts, are different from CTIN. 1201 6. ``The context transfer solution SHOULD support one-to-many 1202 context transfer.'' 1204 The source access router can use the CT-Rep or PCT envelope 1205 to send multiple unicast messages or a single multicast 1206 message when there are multiple receivers for the feature 1207 contexts. 1209 7. ``The context transfer solution MUST support context transfer 1210 before, during and after handover.'' 1212 In this document, we specifically describe how context 1213 transfer can be performed during and after handovers. The 1214 ``Predictive Context Transfer'' message can be used prior 1215 to actual handover. 1217 8. ``The context transfer solution MUST support a distributed 1218 approach in which the Access Routers act as peers during the 1219 context transfer.'' 1221 In this document, the access routers transfer appropriate 1222 contexts. These contexts are typically those that are 1223 created locally on the access router. If contexts present 1224 elsewhere need to be transferred by using the access 1225 routers, a separate protocol outside the scope of this 1226 document would be needed to glean all the relevant contexts 1227 and make them available to the source access router. 1229 9. ``The entities transferring context MUST have completed a mutual 1230 authentication process prior to initiating the transfer.'' 1232 Our protocol does not propose dynamically establishing 1233 mutual authentication between the context transfer 1234 entities. Mechanisms outside the scope of this document 1235 would be needed to establish the necessary security 1236 associations between the context transfer peers. 1238 10. ``The context transfer solution SHOULD provide mechanisms to 1239 selectively enable or disable context transfer for particular IP 1240 microflows or groups of IP microflows.'' 1242 The CTIN structure allows enumeration of only those feature 1243 contexts for which transfer is desired. 1245 11. ``Context information MAY be transferred in phases.'' 1246 The ``CT-Rep'' or ``PCT'' message can be used multiple 1247 times to effect transfer in phases. 1249 12. ``The context information to be transferred MUST be available 1250 at the AR performing the transfer, prior to the initiation of a 1251 given phase of the context transfer.'' 1253 Since we only consider all contexts to be local to the AR, 1254 we expect it to be available during all phases of context 1255 transfer. 1257 13. ``The context information provided for transfer MUST be 1258 reliable.'' 1260 Since an access router creates the context, we expect it to 1261 be genuine and reliable. Since it is reasonable to expect 1262 that the MN was making use of the feature (e.g., QoS, 1263 header compression etc), the context itself on the access 1264 router must be useful. Furthermore, since our protocol 1265 does not introduce any operations on the context itself, 1266 we anticipate no scenarios that would malform an otherwise 1267 genuine, useful and reliable context. 1269 14. ``The context transfer solution MUST include methods for 1270 interworking with any IETF IP mobility solutions.'' 1272 The proposed protocol readily interworks with Fast 1273 Handovers proposed in Mobile IP working group. See 1274 Section 6.2. The proposed protocol also interworks with 1275 base Mobile IP protocol itself. See Section 6.1. 1277 15. ``The context transfer solution MAY include methods for 1278 interworking with non-IETF mobility solutions.'' 1280 While this should be possible, we do not have experiences 1281 to report here. 1283 11.2. Protocol Requirements 1285 1. ``The context transfer protocol MUST be capable of transferring 1286 all of the different types of feature context necessary to 1287 support the MN's traffic at a receiving AR.'' 1289 The proposed protocol allows for sending all or a subset 1290 of feature contexts necessary to support the MN's traffic. 1291 Specifically, the sub option structure allows for one 1292 or more feature contexts to be uniquely identified and 1293 included in context transfer. 1295 2. ``The context transfer protocol design MUST define a standard 1296 representation for conveying context information that will 1297 be interpreted uniformly and perspicuously by different 1298 implementations.'' 1300 The concept of ``Context Profile Types'' introduced in 1301 this proposal is powerful and versatile in capturing the 1302 meaning of context information to enable inter-operability. 1303 We expect each feature to define its own set of Feature 1304 Profile Types that uniquely define the content and 1305 interpretation of individual feature contexts. 1307 3. ``The context transfer protocol MUST operate autonomously from 1308 the content of the context information being transferred.'' 1310 There is nothing proposed in this document that would 1311 contradict the above requirement. In other words, the 1312 proposed protocol does not operate in any context-specific 1313 manner. 1315 4. ``The context transfer protocol design MUST define a standard 1316 method for labeling each feature context being transferred.'' 1318 Each feature would define a set of ``Feature Profile 1319 Types''. A ``Feature Profile Type'', such as a QoS Profile 1320 Type (QPT) would define the unique characteristics of each 1321 instance of the feature. For instance, a Compression 1322 Profile Type for IPv6/UDP/RTP-voice-G.723.1 would define 1323 all the necessary and sufficient context parameters for 1324 the associated feature. This CPT, which would be an IANA 1325 assigned type number, would precede the associated context 1326 parameters in each transferred context. 1328 5. ``The context transfer protocol design MUST provide for the 1329 future definition of new feature contexts.'' 1331 New ``Feature Profile Types'' can be defined as necessary. 1333 11.3. Transport Reliability 1335 11.4. Security 1337 1. ``The protocol MUST provide for "security provisioning".'' 1339 We expect the ARs involved in context transfer to 1340 share appropriate security associations. Such security 1341 associations may be set up by means outside the scope of 1342 the context transfer protocol. However, our protocol 1343 provides for context authorization mechanism so that only 1344 an authorized MN is allowed to make use of the transferred 1345 contexts. 1347 2. ``The security provisioning for context transfer MUST NOT require 1348 the creation of application layer security.'' 1350 We do not propose application layer security. 1352 3. ``The protocol MUST provide for the security provisioning to be 1353 disabled.'' 1355 It is up to an appropriate authority to decide whether 1356 security provisioning should be enabled or disabled. The 1357 protocol does not specifically require the presence or 1358 absence of security provisioning. 1360 11.5. Timing Requirements 1362 1. ``A context transfer MUST complete with a minimum number of 1363 protocol exchanges between the source AR and the rest of the 1364 ARs.'' 1366 Our protocol proposes two messages to accomplish context 1367 transfer. When contexts are transferred before the MN 1368 attaches to the new AR, there is a predictive transfer and 1369 acknowledge message sequence. When context transfer takes 1370 place after the MN attaches to the new AR, there is context 1371 request and context reply message pair. 1373 2. ``The context transfer protocol design MUST minimize the amount 1374 of processing required at the sending and receiving Access 1375 Routers.'' 1377 The amount of processing needed at the sending router 1378 is limited to collecting all the relevant contexts for 1379 transfer and labeling each context with an appropriate 1380 Profile Type, and computing authentication data. The 1381 amount of processing at the receiving router is limited 1382 to parsing the received contexts using the Profile Types, 1383 verifying authentication data and installing the contexts 1384 in local memory. 1386 3. ``The Context Transfer protocol MUST meet the timing constraints 1387 required by all the feature contexts.'' 1389 It is important to recognize that the context state 1390 refers to a MN's packet flows. When the packet flows 1391 change network path due to handover, it is important to 1392 synchronize context transfer with handover epoch. This 1393 would ensure not only that the contexts would be present 1394 when needed, but also guarantee that the transferred state 1395 is not stale. Our context transfer protocol is designed to 1396 operate together with handover signaling. This allows for 1397 contexts to be present ``in-time''. 1399 4. ``The context transfer solution MUST provide for the aggregation 1400 of multiple contexts.'' 1402 The proposed sub option structure is meant for collecting 1403 all the possible feature contexts to be transferred in a 1404 single message. The sending AR scans and collects all the 1405 feature contexts associated with the MN while constructing 1406 the CT-Rep or PCT option. This ensures the most feature 1407 context aggregation prior to transferring the message. 1409 11.6. Context Update and Synchronization 1411 1. ``The context transfer protocol MUST be capable of updating 1412 context information when it changes.'' 1414 The PCT message can be used at any appropriate time to 1415 accomplish context updates. 1417 2. ``A context update MUST preserve the integrity, and thus the 1418 meaning, of the context at each receiving AR.'' 1420 We do not propose replicating the contexts at multiple ARs 1421 when the MN is connected to a single AR. Thus, we do not 1422 have to address this requirement. 1424 11.7. Interworking with handover mechanisms 1426 1. ``The context transfer protocol MAY provide input to the handover 1427 process.'' 1429 We do not provide such an input in our current proposal. 1431 2. ``The context transfer protocol MUST include methods for 1432 exchanging information with the handover process.'' 1434 We expect a separate Candidate Access Router discovery 1435 protocol to assist the context transfer protocol in 1436 determining the target AR. We expect such a discovery 1437 protocol to also assist the handover process. 1439 11.8. Partial Handover 1441 1. ``The context transfer protocol MAY provide a mechanism for 1442 supporting partial handovers.'' 1444 We do not propose distributing the subsets of contexts 1445 to multiple ARs. However, if a Candidate Access Router 1446 discovery protocol provides more than one target and the 1447 required contexts for each target AR, our protocol does not 1448 inhibit such a transfer. 1450 References 1452 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1453 Levels. Request for Comments (Best Current Practice) 2119, 1454 Internet Engineering Task Force, March 1997. 1456 [2] A. Conta and S. Deering. Internet Control Message Protocol 1457 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1458 Specification. Request for Comments (Draft Standard) 2463, 1459 Internet Engineering Task Force, December 1998. 1461 [3] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6 1462 (work in progress). Internet Draft, Internet Engineering Task 1463 Force, 2002. 1465 [4] S. Kent and R. Atkinson. IP Authentication Header. Request for 1466 Comments (Proposed Standard) 2402, Internet Engineering Task 1467 Force, November 1998. 1469 [5] R. Koodli and (Editor). Fast Handovers for Mobile IPv6(work in 1470 progress). Internet Draft, Internet Engineering Task Force. 1471 draft-designteam-fast-mipv6-01.txt, February 2001. 1473 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 1474 for Message Authentication. Request for Comments 1475 (Informational) 2104, Internet Engineering Task Force, 1476 February 1997. 1478 [7] O. Levkowetz and et al. Problem Description: Reasons For Doing 1479 Context Transfers Between Nodes in an IP Access Network (work in 1480 progress). Internet Draft, Internet Engineering Task Force. 1481 draft-ietf-seamoby-context-transfer-problem-stat-00.txt, 1482 February 2001. 1484 [8] J. Postel. Internet Control Message Protocol. Request for 1485 Comments (Standard) 792, Internet Engineering Task Force, 1486 September 1981. 1488 [9] R. Rivest. The MD5 Message-Digest Algorithm. Request for 1489 Comments (Informational) 1321, Internet Engineering Task Force, 1490 April 1992. 1492 [10] R. Stewart and et al. Stream Control Transmission Protocol. 1493 Request for Comments (Proposed Standard) 2960, Internet 1494 Engineering Task Force, October 2000. 1496 [11] H. Syed and et al. General Requirements for Context 1497 Transfer(work in progress). Internet Draft, Internet 1498 Engineering Task Force, March 2001. 1500 [12] D. Trossen and et al. Issues in candidate access router 1501 discovery for seamless IP-level handoffs (work in progress). 1502 Internet Draft, Internet Engineering Task Force, January 2002. 1504 Addresses 1506 Questions about this memo can be directed to the authors: 1508 Rajeev Koodli Charles E. Perkins 1509 Communications Systems Lab Communications Systems Lab 1510 Nokia Research Center Nokia Research Center 1511 313 Fairchild Drive 313 Fairchild Drive 1512 Mountain View, California 94043 Mountain View, California 94043 1513 USA USA 1514 Phone: +1-650 625-2359 Phone: +1-650 625-2986 1515 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com 1516 Fax: +1 650 625-2502 Fax: +1 650 625-2502