idnits 2.17.1 draft-ietf-seamoby-ct-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document 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 539 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 32 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' ** Obsolete normative reference: RFC 896 (ref. '3') (Obsoleted by RFC 7805) Summary: 6 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-01.txt Nortel Networks 4 Expires: March 2001 Pat Calhoun 5 Black Storm Networks 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 September, 2001 19 General Requirements for Context Transfer 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 solution 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 solution 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 solution". 116 4.1 The context transfer solution MUST define the characteristics of the IP 117 level trigger mechanisms that initiate the transfer of context. 119 4.2 The IP level context transfer triggers MAY be initiated by a link level 120 (layer two) event. 122 4.3 The IP level trigger mechanisms for context transfer MUST hide the 123 specifics of any layer 2 trigger mechanisms. 125 Handover at the IP level is a consequence of a change in the physical 126 path used to communicate between the MN and the access network. The 127 mechanisms utilized to change the communications path at layer 2 are 128 specific to the physical characteristics of the medium, and often 129 specific to the layer 2 transmission technology being used (e.g. TIA 130 IS 2000, ETSI UMTS R4, IEEE 802.11). 132 In order for any action to be taken at the IP level to maintain IP 133 sessions during a layer 2 path change, some indication of the path 134 change must be made available to the IP level. One example of an 135 indicator would be the trigger event that initiates context transfer. 137 Since it is expected that IP handover, and thus context transfer will 138 work irrespective of the layer 2 technology, the IP level solutions 139 must not utilize specific layer 2 information. The conditions and 140 events that caused the generation of an IP level trigger must be 141 opaque to the IP level. This implies that there are general 142 characteristics of an IP level trigger that need to be defined so 143 that the triggers generated by different layer 2 solutions will have 144 identical semantics at the IP level. 146 4.4 The IP level context transfer triggers MAY be initiated by IP level 147 (layer three) signalling. 149 4.5 Any IP level signalling for Context Transfer MUST be separated from 150 the actual transfer of context. 152 4.6 The context transfer solution SHOULD support one-to-many context 153 transfer. 155 An MN may have connectivity to the access network through more than 156 one physical path at any given time, depending upon the 157 characteristics of the physical medium, and the layer 1 and 2 158 protocols and services. 160 The different physical paths may connect into the network via 161 different ARs. In this scenario, two or more ARs may be candidates 162 for handover of the MN's traffic and each will require the 163 appropriate IP context when forwarding commences. Exactly which AR 164 will be the target of the handover is often not known until the 165 handover is initiated, and providing the necessary context to all the 166 candidate ARs can only accelerate the handover process. 168 A one-to-many context transfer may be achieved using either a series 169 of point-to-point transfers, or a point-to-multipoint (multicast) 170 transfer. 172 4.7 The context transfer solution MUST support context transfer before, 173 during and after handover. 175 4.8 The context transfer solution MUST support a distributed approach in 176 which the Access Routers act as peers during the context transfer. 178 One main distinction between the various alternative approaches to 179 context transfer is the choice of the functional entity or entities that 180 orchestrate the transfer. A context transfer solution that relies upon 181 the ARs to effect a context transfer should be the most efficient approach, 182 as it involves the fewest possible entities. At the very least, the number 183 of protocol exchanges should be less when there are fewer entities involved. 185 4.9 The entities transferring context MUST have completed a mutual 186 authentication process prior to initiating the transfer. 188 It is believed that if a formal authentication exchange (e.g. exchanging 189 credentials) were done during the context transfer, the computation 190 overhead for both the sender and the receiver would cause additional and 191 unnecessary latency to the handoff process. Therefore, the CT peers MUST 192 exchange credentials prior to any context transfer. 194 4.10 The context transfer solution SHOULD provide mechanisms to selectively 195 enable or disable context transfer for particular IP microflows or groups 196 of IP microflows. 198 The context associated with an MN's microflows is normally to be 199 transferred whenever it is required to support forwarding. However, 200 there may be conditions where it is desirable to selectively disable 201 context transfer for specific microflows. 203 For example, it may be desirable to provide an MN with the capability 204 to disallow the transfer of the context associated with one or more 205 of its microflows when handover occurs between networks administered 206 by different operators. 208 Local mechanisms for allowing context transfer to be disabled on a per 209 microflow basis have to be provided for in the context transfer solution. 210 These mechanisms will most likely be captured as part of the CT MIB, and 211 possibly, as part of a PIB, if policy based management is considered 212 desirable. 214 There are other mechanisms and protocols required to manage or control 215 the per microflow disabling of context transfer. These are clearly 216 out of the scope of the context transfer work. 218 4.11 Context information MAY be transferred in phases. 220 Providing for phased transfers allows the context acquisition 221 and transfer to be prioritized. 223 4.12 The context information to be transferred MUST be available at the 224 AR performing the transfer, prior to the initiation of a given phase 225 of the context transfer. 227 To effect a rapid transfer, the context information has to be readily 228 available when the AR begins a phase of the transfer. 230 If the context transfer is comprised of a single phase, then all of the 231 context must be available prior to the transfer initiation. 233 4.13 The context information provided for transfer MUST be reliable. 235 The context to be transferred must not only be readily available for 236 transfer, but the sending AR must ensure that the information is sound. 238 The context transfer solution may provide mechanisms to support reliable 239 transfer of context, but the effectiveness of context transfer in enhancing 240 handover between ARs would very likely be compromised by attempts to 241 transfer malformed context. 243 4.14 The context transfer solution MUST include methods for interworking 244 with any IETF IP mobility solutions. 246 4.15 The context transfer solution MAY include methods for interworking 247 with non-IETF mobility solutions. 249 5. Protocol Requirements 251 This section captures the general requirements for the context 252 transfer protocol. 254 5.1 General Protocol Requirements 256 5.1.1 The context transfer protocol MUST be capable of transferring all 257 of the different types of feature context necessary to support the 258 MN's traffic at a receiving AR. 260 5.1.2 The context transfer protocol design MUST define a standard 261 representation for conveying context information that will be 262 interpreted uniformly and perspicuously by different 263 implementations. 265 5.1.3 The context transfer protocol MUST operate autonomously from the 266 content of the context information being transferred. 268 5.1.4 The context transfer protocol design MUST define a standard method 269 for labeling each feature context being transferred. 271 Various protocols participate in setting up the service support for 272 any given microflow, and many of these protocols require feature 273 specific state to be maintained for the life of the IP session. The 274 context transfer protocol should provide a generic mechanism to carry 275 context information to an AR, irrespective of the context type. 277 Given that the desired context transfer protocol is a single, generic 278 protocol for transferring all feature context, the collection of 279 information representing the context for a given feature must be 280 encapsulated into a standard representation and labeled. 281 Encapsulation is necessary to keep the context for different features 282 separated. The receiving AR will use the label on an encapsulated 283 context to associate it with the appropriate service feature and 284 process the content appropriately. 286 The context transfer protocol does not need to know the contents of 287 these nuggets of encapsulated information. Indeed, for the protocol 288 to be independent from the type of context being transferred, it must 289 be oblivious the actual context. 291 5.1.5 The context transfer protocol design MUST provide for the future 292 definition of new feature contexts. 294 The context transfer solution must not attempt to define all possible 295 feature contexts to be transferred. Instead, it must provide for the 296 definition of new contexts in support of future service features, or 297 feature evolution. Guidance should be provided to future users of context 298 transfer on the best approach to defining feature context. 300 5.2 Transport Reliability 302 This section is intentionally left blank as the working group is 303 waiting for a questionnaire from the transport directorate. The result 304 of the questionnaire will create requirements that will be added in this 305 section in a later revision of this specification. 307 5.3 Security 309 5.3.1 The protocol MUST provide for "security provisioning". 311 The security of the context information being exchanged between ARs 312 must be ensured. Security provisioning includes protecting the 313 integrity, confidentiality, and authenticity of the transfer, as well 314 as protecting the ARs against replay attacks. 316 5.3.2 The security provisioning for context transfer MUST NOT 317 require the creation of application layer security. 319 5.3.3 The protocol MUST provide for the security provisioning to be 320 disabled. 322 In some environments, the security provisioning provided for by the 323 context transfer protocol may not be necessary, or it may be 324 preferred to minimize the context transfer protocol overhead. 326 5.4 Timing Requirements 328 5.4.1 A context transfer MUST complete with a minimum number of protocol 329 exchanges between the source AR and the rest of the ARs. 331 The number of protocol exchanges required to perform a peer to peer 332 interaction is directly related to the unreliability, resource 333 consumption, and completion time of that interaction. A context 334 transfer will require signaling and data exchanges, but, as a general 335 rule, by keeping the number of these exchanges to a minimum, the 336 reliability, resource utilization and completion delay of the 337 transfer should improve. 339 5.4.2 The context transfer protocol design MUST minimize the amount of 340 processing required at the sending and receiving Access Routers. 342 If the context transfer protocol requires the context information to 343 be transferred in a form that requires significant additional 344 processing at each AR, delays may be incurred that impact the 345 reliability of the context. In other words, the context may become 346 obsolete before it can be reconstructed at the receiving AR. 348 Also, AR processing delay contributes to the overall context transfer 349 delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. 351 An example of a protocol design that would increase the processing 352 delay at the receiver is where the context information is segmented, 353 and the ordering of the segments is not preserved during transfer; 354 segmenting at the sender, and more likely, re-ordering of the 355 segments at the receiver could introduce significant additional 356 AR processing delays. 358 5.4.3 The Context Transfer protocol MUST meet the timing constraints 359 required by all the feature contexts. 361 A given feature context may have timing constraints imposed by the 362 nature of the service being support. The delivered context must 363 always comply with the requirements of the service if it is to be 364 useable. 366 5.4.4 The context transfer solution MUST provide for the aggregation of 367 multiple contexts. 369 5.4.5 If context aggregation is not support by the transport protocol 370 (via the Nagle algorithm [3]) then the context transfer protocol 371 MUST provide it. 373 There may be instances where there are multiple context transfers 374 pending. To reduce the overall transfer time, as well as transport 375 overhead that might be incurred by separately transferring each 376 context, the sending AR may choose to aggregate the contexts and 377 execute one transfer operation. 379 Note that if contexts are aggregated, the labelling method required 380 by 5.1.4 must include an identifier that allows the contexts to be 381 separated at the receiving AR. 383 5.5 Context Update and Synchronization 385 5.5.1 The context transfer protocol MUST be capable of updating 386 context information when it changes. 388 5.5.2 A context update MUST preserve the integrity, and thus the 389 meaning, of the context at each receiving AR. 391 The context at the AR actually supporting an MN's traffic will 392 change with time. For example, the MN may initiate new microflow(s), 393 or discontinue existing microflows. Any change of context at the 394 supporting AR must be replicated at those ARs that have already 395 received context for that MN. 397 5.6 Interworking with handover mechanisms 399 5.6.1 The context transfer protocol MAY provide input to the 400 handover process. 402 5.6.2 The context transfer protocol MUST include methods for exchanging 403 information with the handover process. 405 Both context transfer and handover require information on the 406 AR candidates for handover. The context transfer entities may, in the 407 process of establishing and supporting context transfer, acquire 408 information that would be useful to the handover process in 409 determining the new forwarding path: for example, the outcome of an 410 admission control decision at a receiving AR. 412 5.7 Partial Handover 414 5.7.1 The context transfer protocol MAY provide a mechanism for 415 supporting partial handovers. 417 In a situation where no single AR is capable of receiving a handover 418 of all of an MN's traffic, a mechanism could be provided that would 419 allow different IP microflows to be handed over to different ARs. 420 The information transferred to each AR must be limited to only the 421 context required to support the microflows that are actually handed 422 over. Thus, the context transfer protocol would need a mechanism for 423 partitioning the context and transferring each portion to the 424 appropriate AR. 426 6 References 428 [1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement 429 Levels", RFC2119 (BCP), IETF, March 1997. 431 [2] Levkowetz et al., "Problem Description: Reasons For Performing 432 Context Transfers Between Nodes in an IP Access Network ", 433 draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. 435 [3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. 437 7 Acknowledgements 439 Thank you to all who participated in the Seamoby working group context 440 transfer design team. 442 8 Author's Addresses 444 Hamid Syed 445 100 Constellation Crescent 446 Nepean, Ontario. K2G 6J8 Phone: 1 613 763 6553 447 Canada Email: hmsyed@nortelnetworks.com 449 Gary Kenward 450 100 Constellation Crescent 451 Nepean, Ontario. K2G 6J8 Phone: 1 613 765 1437 452 Canada Email: gkenward@nortelnetworks.com 454 Pat R. Calhoun 455 Black Storm Networks 456 250 Cambridge Avenue, Suite 200 457 Palo Alto, CA 94306 Phone: +1 650 617 2932 458 USA Email: pcalhoun@bstormnetworks.com 460 Madjid Nakhjiri 461 Motorola 462 1501 West Shure Drive 463 Arlington Heights IL 60004 Phone: +1 847 632 5030 464 USA Email: madjid.nakhjiri@motorola.com 466 Rajeev Koodli 467 Communications Systems Laboratory, Nokia Research Center 468 313 Fairchild Drive 469 Mountain View CA 94043 Phone: +1 650 625 2359 470 USA Email: rajeev.koodli@nokia.com 472 Kulwinder S. Atwal 473 Zucotto Wireless Inc. 474 Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090 475 CANADA EMail: kulwinder.atwal@zucotto.com 477 Mark Smith 478 COM DEV Wireless 479 3450 Broad Street, Suite 107 480 San Luis Obispo, CA 93401 Phone: +1 805 544 1089 481 USA Email: mark.smith@comdev.cc 483 Govind Krishnamurthi 484 Communications Systems Laboratory, Nokia Research Center 485 5 Wayside Road 486 Burlington MA 01803 Phone: +1 781 993 3627 487 USA EMail: govind.krishnamurthi@nokia.com 489 9 Full Copyright Statement 491 "Copyright (C) The Internet Society (2001). All Rights Reserved. 492 This document and translations of it may be copied and furnished to 493 others, and derivative works that comment on or otherwise explain it 494 or assist in its implementation may be prepared, copied, published 495 and distributed, in whole or in part, without restriction of any 496 kind, provided that the above copyright notice and this paragraph 497 are included on all such copies and derivative works. However, this 498 document itself may not be modified in any way, such as by removing 499 the copyright notice or references to the Internet Society or other 500 Internet organizations, except as needed for the purpose of 501 developing Internet standards in which case the procedures for 502 copyrights defined in the Internet Standards process must be 503 followed, or as required to translate it into languages other than 504 English. 506 The limited permissions granted above are perpetual and will not be 507 revoked by the Internet Society or its successors or assigns. 509 This document and the information contained herein is provided on an 510 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 511 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 512 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 513 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 514 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.