idnits 2.17.1 draft-ietf-seamoby-ct-reqs-00.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 583 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 47 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.) -- 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) -- No information found for draft-ietf-seamoby-context-transfer-problem - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Hamid Syed 2 Internet Draft Gary Kenward 3 draft-ietf-seamoby-ct-reqs-00.txt Nortel Networks 4 Expires: November 2001 Pat Calhoun 5 SUN Microsystems, Inc 6 Madjid Nakhjiri 7 Motorola 8 Rajeev Koodli 9 Nokia 10 Kulwinder Atwal 11 Zucotto Wireless 12 Mark Smith 13 COM DEV Wireless 14 Govind Krishnamurthi 15 Nokia 17 May, 2001 19 General Requirements for a Context Transfer Framework 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time It is inappropriate to use Internet-Drafts as reference material 34 or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2001). All Rights Reserved. 45 Abstract 47 The success of time sensitive services like VoIP telephony, video, 48 etc., in a mobile environment depends heavily on the ability to 49 minimize the impact of the traffic redirection during a change of 50 packet forwarding path. In the process of establishing the new 51 forwarding path, the nodes along the new path must be prepared to 52 provide similar forwarding treatment to the IP packets. The transfer 53 of context information may be advantageous in minimizing the impact 54 of host mobility on IP services. This document captures the set of 55 requirements for a context transfer framework and the requirements 56 for a generic context transfer protocol to carry the context between 57 the context transfer peers. 59 1 Introduction 61 There are a large number of IP access networks that support mobile 62 hosts. For example, wireless Personal Area Networks (PANs), wireless 63 LANs, satellite WANs and cellular WANs. The nature of this mobility 64 is such that the communication path to the host may change frequently 65 and rapidly. 67 In networks where the hosts are mobile, the forwarding path through 68 the access network must often be redirected in order to deliver the 69 host's IP traffic to the new point of access. The success of time 70 sensitive services like VoIP telephony, video, etc., in a mobile 71 environment depends heavily upon the ability to minimize the impact 72 of this traffic redirection. In the process of establishing the new 73 forwarding path, the nodes along the new path must be prepared to 74 provide similar forwarding treatment to the IP packets. 76 The information required to support a specific forwarding treatment 77 provided to an IP flow is part of the context for that flow. To 78 minimize the impact of a path change on an IP flow, the context must 79 be replicated from the forwarding nodes along the existing path to 80 the forwarding nodes along the new path. The transfer of context 81 information may be advantageous in minimizing the impact of host 82 mobility on, for example, AAA, header compression, QoS, Policy, and 83 possibly sub-IP protocols and services such as PPP. 85 An analysis of the context transfer problem is captured in [2]. This 86 document captures the requirements for a context transfer framework 87 and the requirements for a generic context transfer protocol to 88 carry the context between the context transfer peers. 90 2 Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC-2119 [1]. 96 3 Terminology 98 Most of the terms used in this document are defined in [2]. 100 Access Router (AR) 101 An IP router residing in an Access Network and connected to one or 102 more points of access. An AR offers connectivity to MNs. 104 4 General Requirements 106 This section addresses the facilities and services required in the access 107 network to properly support context transfer. The context transfer 108 solution will have to assume certain characteristics of the access network 109 and the mobility solution, and the availability of certain triggering events, 110 transport options, and so forth. These support capabilities are not 111 necessarily part of context transfer, per se, but are needed for context 112 transfer to operate as defined and effect the expected enhancements to MN 113 traffic handover. For convenience, this collection of support capabilities 114 are referred to as the "context transfer framework". 116 4.1 The context transfer framework MUST define the characteristics of the IP 117 level trigger mechanisms that initiate the transfer of context. 119 4.2 The IP level trigger mechanisms for context transfer MUST hide the 120 specifics of the layer 2 trigger mechanisms. 122 Handover at the IP level is a consequence of a change in the physical 123 path used to communicate between the MN and the access network. The 124 mechanisms utilized to change the communications path at layer 2 are 125 specific to the physical characteristics of the medium, and often 126 specific to the layer 2 transmission technology being used (e.g. TIA 127 IS 2000, ETSI UMTS R4, IEEE 802.11). 129 In order for any action to be taken at the IP level to maintain IP 130 sessions during a layer 2 path change, some indication of the path 131 change must be made available to the IP level. One example of an 132 indicator would be the trigger event that initiates context transfer. 134 Since it is expected that IP handover, and thus context transfer will 135 work irrespective of the layer 2 technology, the IP level solutions 136 must not utilize specific layer 2 information. The conditions and 137 events that caused the generation of an IP level trigger must be 138 opaque to the IP level. This implies that there are general 139 characteristics of an IP level trigger that need to be defined so 140 that the triggers generated by different layer 2 solutions will have 141 identical semantics at the IP level. 143 4.3 The context transfer framework SHOULD support one-to-many context 144 transfer. 146 An MN may have connectivity to the access network through more than 147 one physical path at any given time, depending upon the 148 characteristics of the physical medium, and the layer 1 and 2 149 protocols and services. 151 The different physical paths may connect into the network via 152 different ARs. In this scenario, two or more ARs may be candidates 153 for handover of the MN's traffic and each will require the 154 appropriate IP context when forwarding commences. Exactly which AR 155 will be the target of the handover is often not known until the 156 handover is initiated, and providing the necessary context to all the 157 candidate ARs can only accelerate the handover process. 159 A one-to-many context transfer may be achieved using either a series 160 of point-to-point transfers, or a point-to-multipoint (multicast) 161 transfer. 163 4.4 The context transfer framework MUST support proactive context transfer. 165 4.5 The context transfer framework MUST support reactive context transfer 167 It is useful to consider two modes of operation for context transfer: 168 proactive and reactive. 170 With proactive context transfer, the context is made available 171 to an AR before it is needed. This means that the context is 172 available at the AR before it is required to forward the first 173 packet arrival in the MN's traffic. Proactive context transfer is 174 coupled to mobile handover only by the requirement that the context 175 be in place before the handover of the MN's traffic is complete. 177 With reactive context transfer, the context is made available to 178 an AR when the need is imminent. The implication here is that the 179 initiation of a handover, or some event soon after initiation, 180 triggers a reactive context transfer. Depending upon the network 181 configuration, the MN's velocity and the behavior of the mobility 182 solution, a reactive context transfer may or may not complete quickly 183 enough for the new forwarding AR to provide a consistent service to 184 the first packets of the re-directed traffic. 186 The proactive mode of context transfer is an attempt to further 187 reduce any disruption of the service provided to the MN's traffic by 188 making the context available to an AR prior to it being needed for 189 forwarding. This implies that some network event will occur at the IP 190 level to indicate the potential for a handover, prior to the handover 191 being initiated (c.f. requirements 4.1 and 4.2). This event would 192 trigger a proactive context transfer. There can be no guarantee that 193 this event will occur, and thus, a reactive context transfer is 194 always required as a contingency. 196 In many situations there is no forewarning available of a handover 197 and context transfer must be initiated simply because the 198 re-direction of the MN's traffic is in progress and the AR needs the 199 forwarding context immediately. Because of the real world physics of 200 MN movement and wireless coverage patterns, these situations can 201 never be completely avoided. Thus, if context transfer is to be 202 performed at all, the fundamental mode of operation must be reactive. 204 This also means that a context transfer that begins in proactive mode 205 may, as a result of the MN moving or other changes to the wireless 206 environment, be required to complete in reactive mode. In this scenario, 207 proactive and reactive context transfer are really two possible phases of 208 a single attempted context transfer. 210 As the proactive mode of context transfer is an enhancement, there may be 211 situations where the reactive mode is considered a sufficient solution. 212 While it is required that the context transfer protocol support proactive 213 mode, its use is optional. 215 4.6 The context transfer framework MUST support a distributed approach in 216 which the Access Routers act as peers during the context transfer. 218 One main distinction between the various alternative approaches to context 219 transfer is the choice of the functional entity or entities that orchestrate 220 the transfer. A context transfer solution that relies upon the ARs to effect 221 a context transfer should be the most efficient approach, as it involves the 222 fewest possible entities. At the very least, the number of protocol exchanges 223 should be less when there are fewer entities involved. 225 4.7 The entities transferring context MUST have completed a mutual 226 authentication process prior to initiating the transfer. 228 4.8 The context transfer framework SHOULD provide mechanisms to 229 selectively enable or disable context transfer for particular 230 IP microflows or groups of IP microflows. 232 The context associated with an MN's microflows is normally to be 233 transferred whenever it is required to support forwarding. However, 234 there may be conditions where it is desirable to selectively disable 235 context transfer for specific microflows. 237 For example, it may be desirable to provide an MN with the capability 238 to disallow the transfer of the context associated with one or more 239 of its microflows when handover occurs between networks administered 240 by different operators. 242 Local mechanisms for allowing context transfer to be disabled on a per 243 microflow basis have to be provided for in the context transfer solution. 244 These mechanisms will most likely be captured as part of the CT MIB, and 245 possibly, as part of a PIB, if policy based management is considered 246 desirable. 248 There are other mechanisms and protocols required to manage or control 249 the per microflow disabling of context transfer. These are clearly 250 out of the scope of the context transfer work. 252 4.9 All context information to be transferred MUST be available at the 253 AR performing the transfer, prior to the initiation of the context 254 transfer. 256 The total context associated with the MN's traffic is composed of 257 various types of feature context. To effect a rapid transfer, the 258 context information has to be readily available when the AR begins 259 the transfer. 261 4.10 The context information provided for transfer MUST be reliable. 263 The context to be transferred must not only be readily available for 264 transfer, but the sending AR must ensure that the information is sound. 266 The context transfer solution may provide mechanisms to support reliable 267 transfer of context, but the effectiveness of context transfer in enhancing 268 handover between ARs would very likely be compromised by attempts to 269 transfer malformed context. 271 4.11 The context transfer framework MUST include methods for interworking 272 with any IETF IP mobility solutions. 274 4.12 The context transfer framework MAY include methods for interworking 275 with non-IETF mobility solutions. 277 5. Protocol Requirements 279 This section captures the general requirements for the context 280 transfer protocol. 282 5.1 General Protocol Requirements 284 5.1.1 The context transfer protocol MUST be capable of transferring all 285 of the different types of feature context necessary to support the 286 MN's traffic at a receiving AR. 288 5.1.2 The context transfer protocol design MUST define a standard 289 representation for conveying context information that will be 290 interpreted uniformly and perspicuously by different 291 implementations. 293 5.1.3 The context transfer protocol MUST operate autonomously from the 294 content of the context information being transferred. 296 5.1.4 The context transfer protocol design MUST define a standard method 297 for labeling each feature context being transferred. 299 Various protocols participate in setting up the service support for 300 any given microflow, and many of these protocols require feature 301 specific state to be maintained for the life of the IP session. The 302 context transfer protocol should provide a generic mechanism to carry 303 context information to an AR, irrespective of the context type. 305 Given that the desired context transfer protocol is a single, generic 306 protocol for transferring all feature context, the collection of 307 information representing the context for a given feature must be 308 encapsulated into a standard representation and labeled. 309 Encapsulation is necessary to keep the context for different features 310 separated. The receiving AR will use the label on an encapsulated 311 context to associate it with the appropriate service feature and 312 process the content appropriately. 314 The context transfer protocol does not need to know the contents of 315 these nuggets of encapsulated information. Indeed, for the protocol 316 to be independent from the type of context being transferred, it must 317 be oblivious the actual context. 319 5.1.5 The context transfer protocol design MUST provide for the future 320 definition of new feature contexts. 322 The context transfer solution must not attempt to define all possible 323 feature contexts to be transferred. Instead, it must provide for the 324 definition of new contexts in support of future service features, or 325 feature evolution. Guidance should be provided to future users of context 326 transfer on the best approach to defining feature context. 328 5.2 Transport Reliability 330 This section is intentionally left blank as the working group is 331 waiting for a questionnaire from the transport directorate. The result 332 of the questionnaire will create requirements that will be added in this 333 section in a later revision of this specification. 335 5.3 Security 337 5.3.1 The protocol MUST provide for "security provisioning". 339 The security of the context information being exchanged between ARs 340 must be ensured. Security provisioning includes protecting the 341 integrity, confidentiality, and authenticity of the transfer, as well 342 as protecting the ARs against replay attacks. 344 5.3.2 The security provisioning for context transfer MUST NOT 345 require the creation of application layer security. 347 5.3.3 The protocol MUST provide for the security provisioning to be 348 disabled. 350 In some environments, the security provisioning provided for by the 351 context transfer protocol may not be necessary, or it may be 352 preferred to minimize the context transfer protocol overhead. 354 5.4 Timing Requirements 356 5.4.1 Proactive context transfer MUST be completed before the handover 357 of the Mobile Node's traffic to the receiving AR completes. 359 When an MN's traffic is handed over to a new AR, that AR will 360 usually require the associated context in order to provide service 361 contiguous with the service provide by the old AR. For there to be 362 no disruption in service, the associated context needs to be 363 installed at the new AR in time for the forwarding of the first packet 364 of the MN's traffic. 366 5.4.2 The context transfer protocol SHOULD NOT introduce additional 367 delay into the handover completion. 369 The purpose of context transfer is to enhance the performance of traffic 370 handover between ARs. While incurring additional delay may be acceptable 371 in some situations, as a general solution, it is preferable that the context 372 transfer protocol be capable of operating without impacting handover 373 completion. 375 For proactive context transfer, meeting requirement 5.4.2 will ensure that 376 requirement 5.4.1 is not achieved by explicitly delaying the handover 377 completion. 379 For reactive context transfer, the requirement has to be less stringent. 380 By definition, reactive context transfer is invoked when a handover to the 381 receiving AR is either in progress or impending. Completing a reactive 382 context transfer within any time constraint will depend heavily on the 383 handover solution being used, and situational factors such as the topology 384 of the network, or networks, local to the handover. Regardless, it is still 385 useful to require that reactive context transfer not delay handover, if at 386 all possible. If additional delay is unavoidable, then the reactive context 387 transfer solution must be designed to minimize the incremental delay that is 388 introduced. 390 5.4.3 A context transfer MUST complete with a minimum number of protocol 391 exchanges between the source AR and the rest of the ARs. 393 The number of protocol exchanges required to perform a peer to peer 394 interaction is directly related to the unreliability, resource 395 consumption, and completion time of that interaction. A context 396 transfer will require signaling and data exchanges, but, as a general 397 rule, by keeping the number of these exchanges to a minimum, the 398 reliability, resource utilization and completion delay of the 399 transfer should improve. 401 5.4.4 The context transfer protocol design MUST minimize the amount of 402 processing required at the sending and receiving Access Routers. 404 If the context transfer protocol requires the context information to 405 be transferred in a form that requires significant additional 406 processing at each AR, delays may be incurred that impact the 407 reliability of the context. In other words, the context may become 408 obsolete before it can be reconstructed at the receiving AR. 410 Also, AR processing delay contributes to the overall context transfer 411 delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. 413 An example of a protocol design that would increase the processing 414 delay at the receiver is where the context information is segmented, 415 and the ordering of the segments is not preserved during transfer; 416 segmenting at the sender, and more likely, re-ordering of the 417 segments at the receiver could introduce significant additional 418 AR processing delays. 420 5.4.5 The Context Transfer protocol MUST meet the timing constraints 421 required by all the feature contexts. 423 A given feature context may have timing constraints imposed by the 424 nature of the service being support. The delivered context must 425 always comply with the requirements of the service if it is to be 426 useable. 428 5.4.6 The context transfer protocol MUST support the aggregation of 429 multiple contexts. 431 There may be instances where there are multiple context transfers 432 pending. To reduce the overall transfer time, as well as transport 433 overhead that might be incurred by separately transferring each 434 context, the sending AR may choose to aggregate the contexts and 435 execute one transfer operation. 437 Note that if contexts are aggregated, the labeling method required 438 by 5.1.4 must include an identifier that allows the contexts to be 439 separated at the receiving AR. 441 5.5 Context Update and Synchronization 443 5.5.1 The context transfer protocol MUST be capable of updating 444 context information when it changes. 446 5.5.2 A context update MUST preserve the integrity, and thus the 447 meaning, of the context at each receiving AR. 449 The context at the AR actually supporting an MN's traffic will 450 change with time. For example, the MN may initiate new microflow(s), 451 or discontinue existing microflows. Any change of context at the 452 supporting AR must be replicated at those ARs that have already 453 received context for that MN. 455 5.6 Interworking with handover mechanisms 457 5.6.1 The context transfer protocol MAY provide input to the 458 handover process. 460 5.6.2 The context transfer protocol MUST include methods for exchanging 461 information with the handover process. 463 Both context transfer and handover require information on the 464 AR candidates for handover. The context transfer entities may, in the 465 process of establishing and supporting context transfer, acquire 466 information that would be useful to the handover process in 467 determining the new forwarding path: for example, the outcome of an 468 admission control decision at a receiving AR. 470 5.7 Partial Handover 472 5.7.1 The context transfer protocol MAY provide a mechanism for 473 supporting partial handovers. 475 In a situation where no single AR is capable of receiving a handover 476 of all of an MN's traffic, a mechanism could be provided that would 477 allow different IP microflows to be handed over to different ARs. 478 The information transferred to each AR must be limited to only the 479 context required to support the microflows that are actually handed 480 over. Thus, the context transfer protocol would need a mechanism for 481 partitioning the context and transferring each portion to the 482 appropriate AR. 484 6 References 486 [1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement 487 Levels", RFC2119 (BCP), IETF, March 1997. 489 [2] Levkowetz et al., "Problem Description: Reasons For Performing 490 Context Transfers Between Nodes in an IP Access Network ", 491 draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. 493 7 Acknowledgements 495 Thank you to all who participated in the Seamoby working group context 496 transfer design team. 498 8 Author's Addresses 500 Hamid Syed 501 100 Constellation Crescent 502 Nepean, Ontario. K2G 6J8 Phone: 1 613 763 6553 503 Canada Email: hmsyed@nortelnetworks.com 505 Gary Kenward 506 100 Constellation Crescent 507 Nepean, Ontario. K2G 6J8 Phone: 1 613 765 1437 508 Canada Email: gkenward@nortelnetworks.com 510 Pat R. Calhoun 511 Network and Security Research Center, Sun Labs 512 15 Network Circle 513 Menlo Park CA 94025 Phone: +1 650 786 7733 514 USA Email: pcalhoun@eng.sun.com 516 Madjid Nakhjiri 517 Motorola 518 1501 West Shure Drive 519 Arlington Heights IL 60004 Phone: +1 847 632 5030 520 USA Email: madjid.nakhjiri@motorola.com 522 Rajeev Koodli 523 Communications Systems Laboratory, Nokia Research Center 524 313 Fairchild Drive 525 Mountain View CA 94043 Phone: +1 650 625 2359 526 USA Email: rajeev.koodli@nokia.com 528 Kulwinder S. Atwal 529 Zucotto Wireless Inc. 530 Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090 531 CANADA EMail: kulwinder.atwal@zucotto.com 533 Mark Smith 534 COM DEV Wireless 535 3450 Broad Street, Suite 107 536 San Luis Obispo, CA 93401 Phone: +1 805 544 1089 537 USA Email: mark.smith@comdev.cc 539 Govind Krishnamurthi 540 Communications Systems Laboratory, Nokia Research Center 541 5 Wayside Road 542 Burlington MA 01803 Phone: +1 781 993 3627 543 USA EMail: govind.krishnamurthi@nokia.com 545 9 Full Copyright Statement 547 "Copyright (C) The Internet Society (2001). All Rights Reserved. 548 This document and translations of it may be copied and furnished to 549 others, and derivative works that comment on or otherwise explain it 550 or assist in its implementation may be prepared, copied, published 551 and distributed, in whole or in part, without restriction of any 552 kind, provided that the above copyright notice and this paragraph 553 are included on all such copies and derivative works. However, this 554 document itself may not be modified in any way, such as by removing 555 the copyright notice or references to the Internet Society or other 556 Internet organizations, except as needed for the purpose of 557 developing Internet standards in which case the procedures for 558 copyrights defined in the Internet Standards process must be 559 followed, or as required to translate it into languages other than 560 English. 562 The limited permissions granted above are perpetual and will not be 563 revoked by the Internet Society or its successors or assigns. 565 This document and the information contained herein is provided on an 566 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 567 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 568 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 569 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 570 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.