idnits 2.17.1 draft-ietf-seamoby-ct-reqs-03.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 518 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 30 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-03.txt Pat Calhoun 4 Expires: July 2002 Madjid Nakhjiri 5 Rajeev Koodli 6 Kulwinder Atwal 7 Mark Smith 8 Govind Krishnamurthi 10 January, 2002 12 General Requirements for Context Transfer 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 The success of time sensitive services like VoIP telephony, video, 41 etc., in a mobile environment depends heavily on the ability to 42 minimize the impact of the traffic redirection during a change of 43 packet forwarding path. In the process of establishing the new 44 forwarding path, the nodes along the new path must be prepared to 45 provide similar forwarding treatment to the IP packets. The transfer 46 of context information may be advantageous in minimizing the impact 47 of host mobility on IP services. This document captures the set of 48 requirements for a context transfer solution and the requirements 49 for a generic context transfer protocol to carry the context between 50 the context transfer peers. 52 1 Introduction 54 There are a large number of IP access networks that support mobile 55 hosts. For example, wireless Personal Area Networks (PANs), wireless 56 LANs, satellite WANs and cellular WANs. The nature of this mobility 57 is such that the communication path to the host may change frequently 58 and rapidly. 60 In networks where the hosts are mobile, the forwarding path through 61 the access network must often be redirected in order to deliver the 62 host's IP traffic to the new point of access. The success of time 63 sensitive services like VoIP telephony, video, etc., in a mobile 64 environment depends heavily upon the ability to minimize the impact 65 of this traffic redirection. In the process of establishing the new 66 forwarding path, the nodes along the new path must be prepared to 67 provide similar forwarding treatment to the IP packets. 69 The information required to support a specific forwarding treatment 70 provided to an IP flow is part of the context for that flow. To 71 minimize the impact of a path change on an IP flow, the context must 72 be replicated from the forwarding nodes along the existing path to 73 the forwarding nodes along the new path. The transfer of context 74 information may be advantageous in minimizing the impact of host 75 mobility on, for example, AAA, header compression, QoS, Policy, and 76 possibly sub-IP protocols and services such as PPP. 78 An analysis of the context transfer problem is captured in [2]. This 79 document captures the requirements for a context transfer solution 80 and the requirements for a generic context transfer protocol to 81 carry the context between the context transfer peers. 83 2 Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [1]. 89 3 Terminology 91 Most of the terms used in this document are defined in [2]. 93 Access Router (AR) 94 An IP router residing in an Access Network and connected to one or 95 more points of access. An AR offers connectivity to MNs. 97 4 General Requirements 99 This section addresses the facilities and services required in the access 100 network to properly support context transfer. The context transfer 101 solution will have to assume certain characteristics of the access network 102 and the mobility solution, and the availability of certain triggering events, 103 transport options, and so forth. These support capabilities are not 104 necessarily part of context transfer, per se, but are needed for context 105 transfer to operate as defined and effect the expected enhancements to MN 106 traffic handover. For convenience, this collection of support capabilities 107 are referred to as the "context transfer solution". 109 4.1 The context transfer solution MUST define the characteristics of the IP 110 level trigger mechanisms that initiate the transfer of context. 112 4.2 The IP level context transfer triggers MAY be initiated by a link level 113 (layer two) event. 115 4.3 The IP level trigger mechanisms for context transfer MUST hide the 116 specifics of any layer 2 trigger mechanisms. 118 Handover at the IP level is a consequence of a change in the physical 119 path used to communicate between the MN and the access network. The 120 mechanisms utilized to change the communications path at layer 2 are 121 specific to the physical characteristics of the medium, and often 122 specific to the layer 2 transmission technology being used (e.g. TIA 123 IS 2000, ETSI UMTS R4, IEEE 802.11). 125 In order for any action to be taken at the IP level to maintain IP 126 sessions during a layer 2 path change, some indication of the path 127 change must be made available to the IP level. One example of an 128 indicator would be the trigger event that initiates context transfer. 130 Since it is expected that IP handover, and thus context transfer will 131 work irrespective of the layer 2 technology, the IP level solutions 132 must not utilize specific layer 2 information. The conditions and 133 events that caused the generation of an IP level trigger must be 134 opaque to the IP level. This implies that there are general 135 characteristics of an IP level trigger that need to be defined so 136 that the triggers generated by different layer 2 solutions will have 137 identical semantics at the IP level. 139 4.4 The IP level context transfer triggers MAY be initiated by IP level 140 (layer three) signalling. 142 4.5 Any IP level signalling for Context Transfer MUST be separated from 143 the actual transfer of context. 145 4.6 The context transfer solution SHOULD support one-to-many context 146 transfer. 148 An MN may have connectivity to the access network through more than 149 one physical path at any given time, depending upon the 150 characteristics of the physical medium, and the layer 1 and 2 151 protocols and services. 153 The different physical paths may connect into the network via 154 different ARs. In this scenario, two or more ARs may be candidates 155 for handover of the MN's traffic and each will require the 156 appropriate IP context when forwarding commences. Exactly which AR 157 will be the target of the handover is often not known until the 158 handover is initiated, and providing the necessary context to all the 159 candidate ARs can only accelerate the handover process. 161 A one-to-many context transfer may be achieved using either a series 162 of point-to-point transfers, or a point-to-multipoint (multicast) 163 transfer. 165 4.7 The context transfer solution MUST support context transfer before, 166 during and after handover. 168 4.8 The context transfer solution MUST support a distributed approach in 169 which the Access Routers act as peers during the context transfer. 171 One main distinction between the various alternative approaches to 172 context transfer is the choice of the functional entity or entities that 173 orchestrate the transfer. A context transfer solution that relies upon 174 the ARs to effect a context transfer should be the most efficient approach, 175 as it involves the fewest possible entities. At the very least, the number 176 of protocol exchanges should be less when there are fewer entities involved. 178 4.9 The entities transferring context MUST support a process for mutual 179 authentication prior to initiating the transfer. 181 It is believed that if a formal authentication exchange (e.g. exchanging 182 credentials) were done during the context transfer, the computation 183 overhead for both the sender and the receiver would cause additional and 184 unnecessary latency to the handoff process. Therefore, the CT peers MUST 185 exchange credentials prior to any context transfer. 187 4.10 The context transfer solution SHOULD provide mechanisms to selectively 188 enable or disable context transfer for particular IP microflows or groups 189 of IP microflows. 191 The context associated with an MN's microflows is normally to be 192 transferred whenever it is required to support forwarding. However, 193 there may be conditions where it is desirable to selectively disable 194 context transfer for specific microflows. 196 For example, it may be desirable to provide an MN with the capability 197 to disallow the transfer of the context associated with one or more 198 of its microflows when handover occurs between networks administered 199 by different operators. 201 Local mechanisms for allowing context transfer to be disabled on a per 202 microflow basis have to be provided for in the context transfer solution. 203 These mechanisms will most likely be captured as part of the CT MIB, and 204 possibly, as part of a PIB, if policy based management is considered 205 desirable. 207 There are other mechanisms and protocols required to manage or control 208 the per microflow disabling of context transfer. These are clearly 209 out of the scope of the context transfer work. 211 4.11 Context information MAY be transferred in phases. 213 Providing for phased transfers allows the context acquisition 214 and transfer to be prioritized. 216 4.12 The context information to be transferred MUST be available at the 217 AR performing the transfer, prior to the initiation of a given phase 218 of the context transfer. 220 To effect a rapid transfer, the context information has to be readily 221 available when the AR begins a phase of the transfer. 223 If the context transfer is comprised of a single phase, then all of the 224 context must be available prior to the transfer initiation. 226 4.13 The context transfer solution MUST include methods for interworking 227 with any IETF IP mobility solutions. 229 4.14 The context transfer solution MAY include methods for interworking 230 with non-IETF mobility solutions. 232 4.16 The context transfer solution MUST be scalable. 234 5. Protocol Requirements 236 This section captures the general requirements for the context 237 transfer protocol. 239 5.1 General Protocol Requirements 241 5.1.1 The context transfer protocol MUST be capable of transferring all 242 of the different types of feature context necessary to support the 243 MN's traffic at a receiving AR. 245 5.1.2 The context transfer protocol design MUST define a standard 246 representation for encapsulating context information in the IP packet 247 payload that will be interpreted uniformly and perspicuously by 248 different implementations. 250 5.1.3 The context transfer protocol MUST operate autonomously from the 251 content of the context information being transferred. 253 5.1.4 The context transfer protocol design MUST define a standard method 254 for labeling each feature context being transferred. 256 Various protocols participate in setting up the service support for 257 any given microflow, and many of these protocols require feature 258 specific state to be maintained for the life of the IP session. The 259 context transfer protocol should provide a generic mechanism to carry 260 context information to an AR, irrespective of the context type. 262 Given that the desired context transfer protocol is a single, generic 263 protocol for transferring all feature context, the collection of 264 information representing the context for a given feature must be 265 encapsulated into a standard representation and labeled. 266 Encapsulation is necessary to keep the context for different features 267 separated. The receiving AR will use the label on an encapsulated 268 context to associate it with the appropriate service feature and 269 process the content appropriately. 271 The context transfer protocol does not need to know the contents of 272 these nuggets of encapsulated information. Indeed, for the protocol 273 to be independent from the type of context being transferred, it must 274 be oblivious the actual context. 276 5.1.5 The context transfer protocol design MUST provide for the future 277 definition of new feature contexts. 279 The context transfer solution must not attempt to define all possible 280 feature contexts to be transferred. Instead, it must provide for the 281 definition of new contexts in support of future service features, or 282 feature evolution. Guidance should be provided to future users of context 283 transfer on the best approach to defining feature context. 285 5.2 Transport Reliability 287 This section is intentionally left blank as the working group is 288 waiting for a questionnaire from the transport directorate. The result 289 of the questionnaire will create requirements that will be added in this 290 section in a later revision of this specification. 292 5.3 Security 294 5.3.1 The protocol MUST provide for "security provisioning". 296 The security of the context information being exchanged between ARs 297 must be ensured. Security provisioning includes protecting the 298 integrity, confidentiality, and authenticity of the transfer, as well 299 as protecting the ARs against replay attacks. 301 5.3.2 The security provisioning for context transfer MUST NOT 302 require the creation of application layer security. 304 5.3.3 The protocol MUST provide for the security provisioning to be 305 disabled. 307 In some environments, the security provisioning provided for by the 308 context transfer protocol may not be necessary, or it may be 309 preferred to minimize the context transfer protocol overhead. 311 5.4 Timing Requirements 313 5.4.1 A context transfer MUST complete with a minimum number of protocol 314 exchanges between the source AR and the rest of the ARs. 316 The number of protocol exchanges required to perform a peer to peer 317 interaction is directly related to the unreliability, resource 318 consumption, and completion time of that interaction. A context 319 transfer will require signaling and data exchanges, but, as a general 320 rule, by keeping the number of these exchanges to a minimum, the 321 reliability, resource utilization and completion delay of the 322 transfer should improve. 324 5.4.2 The context transfer protocol design MUST minimize the amount of 325 processing required at the sending and receiving Access Routers. 327 If the context transfer protocol requires the context information to 328 be transferred in a form that requires significant additional 329 processing at each AR, delays may be incurred that impact the 330 reliability of the context. In other words, the context may become 331 obsolete before it can be reconstructed at the receiving AR. 333 Also, AR processing delay contributes to the overall context transfer 334 delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. 336 An example of a protocol design that would increase the processing 337 delay at the receiver is where the context information is segmented, 338 and the ordering of the segments is not preserved during transfer; 339 segmenting at the sender, and more likely, re-ordering of the 340 segments at the receiver could introduce significant additional 341 AR processing delays. 343 5.4.3 The Context Transfer protocol MUST meet the timing constraints 344 required by all the feature contexts. 346 A given feature context may have timing constraints imposed by the 347 nature of the service being support. The delivered context must 348 always comply with the requirements of the service if it is to be 349 useable. 351 5.4.4 The context transfer solution MUST provide for the aggregation of 352 multiple contexts. 354 5.4.5 If context aggregation is not support by the transport protocol 355 (via the Nagle algorithm [3]) then the context transfer protocol 356 MUST provide it. 358 There may be instances where there are multiple context transfers 359 pending. To reduce the overall transfer time, as well as transport 360 overhead that might be incurred by separately transferring each 361 context, the sending AR may choose to aggregate the contexts and 362 execute one transfer operation. 364 Note that if contexts are aggregated, the labelling method required 365 by 5.1.4 must include an identifier that allows the contexts to be 366 separated at the receiving AR. 368 5.5 Context Update and Synchronization 370 5.5.1 The context transfer protocol MUST be capable of updating 371 context information when it changes. 373 5.5.2 A context update MUST preserve the integrity, and thus the 374 meaning, of the context at each receiving AR. 376 The context at the AR actually supporting an MN's traffic will 377 change with time. For example, the MN may initiate new microflow(s), 378 or discontinue existing microflows. Any change of context at the 379 supporting AR must be replicated at those ARs that have already 380 received context for that MN. 382 5.6 Interworking with handover mechanisms 384 5.6.1 The context transfer protocol MAY provide input to the 385 handover process. 387 5.6.2 The context transfer protocol MUST include methods for exchanging 388 information with the handover process. 390 Both context transfer and handover require information on the 391 AR candidates for handover. The context transfer entities may, in the 392 process of establishing and supporting context transfer, acquire 393 information that would be useful to the handover process in 394 determining the new forwarding path: for example, the outcome of an 395 admission control decision at a receiving AR. 397 5.7 Partial Handover 399 5.7.1 The context transfer protocol MAY provide a mechanism for 400 supporting partial handovers. 402 In a situation where no single AR is capable of receiving a handover 403 of all of an MN's traffic, a mechanism could be provided that would 404 allow different IP microflows to be handed over to different ARs. 405 The information transferred to each AR must be limited to only the 406 context required to support the microflows that are actually handed 407 over. Thus, the context transfer protocol would need a mechanism for 408 partitioning the context and transferring each portion to the 409 appropriate AR. 411 6 References 413 [1] S. Bradner, "Keywords for use in RFCs to Indicate Requirement 414 Levels", RFC2119 (BCP), IETF, March 1997. 416 [2] Levkowetz et al., "Problem Description: Reasons For Performing 417 Context Transfers Between Nodes in an IP Access Network ", 418 draft-ietf-seamoby-context-transfer-problem-01.txt, May 2001. 420 [3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. 422 7 Acknowledgements 424 Thank you to all who participated in the Seamoby working group context 425 transfer design team. 427 8 Author's Addresses 429 Hamid Syed 430 100 Constellation Crescent 431 Ottawa, Ontario. K2G 6J8 Phone: 1 613 763 6553 432 Canada Email: hmsyed@nortelnetworks.com 434 Gary Kenward 435 100 Constellation Crescent 436 Ottawa, Ontario. K2G 6J8 Phone: 1 613 765 1437 437 Canada Email: gkenward@nortelnetworks.com 439 Pat R. Calhoun 440 Black Storm Networks 441 250 Cambridge Avenue, Suite 200 442 Palo Alto, CA 94306 Phone: +1 650 617 2932 443 USA Email: pcalhoun@bstormnetworks.com 445 Madjid Nakhjiri 446 Motorola 447 1501 West Shure Drive 448 Arlington Heights IL 60004 Phone: +1 847 632 5030 449 USA Email: madjid.nakhjiri@motorola.com 451 Rajeev Koodli 452 Communications Systems Laboratory, Nokia Research Center 453 313 Fairchild Drive 454 Mountain View CA 94043 Phone: +1 650 625 2359 455 USA Email: rajeev.koodli@nokia.com 457 Kulwinder S. Atwal 458 Zucotto Wireless Inc. 459 Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090 460 CANADA EMail: kulwinder.atwal@zucotto.com 462 Mark Smith 463 COM DEV Wireless 464 3450 Broad Street, Suite 107 465 San Luis Obispo, CA 93401 Phone: +1 805 544 1089 466 USA Email: mark.smith@comdev.cc 468 Govind Krishnamurthi 469 Communications Systems Laboratory, Nokia Research Center 470 5 Wayside Road 471 Burlington MA 01803 Phone: +1 781 993 3627 472 USA EMail: govind.krishnamurthi@nokia.com 474 9 Full Copyright Statement 476 "Copyright (C) The Internet Society (2001). All Rights Reserved. 477 This document and translations of it may be copied and furnished to 478 others, and derivative works that comment on or otherwise explain it 479 or assist in its implementation may be prepared, copied, published 480 and distributed, in whole or in part, without restriction of any 481 kind, provided that the above copyright notice and this paragraph 482 are included on all such copies and derivative works. However, this 483 document itself may not be modified in any way, such as by removing 484 the copyright notice or references to the Internet Society or other 485 Internet organizations, except as needed for the purpose of 486 developing Internet standards in which case the procedures for 487 copyrights defined in the Internet Standards process must be 488 followed, or as required to translate it into languages other than 489 English. 491 The limited permissions granted above are perpetual and will not be 492 revoked by the Internet Society or its successors or assigns. 494 This document and the information contained herein is provided on an 495 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 496 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 497 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 498 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 499 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.