idnits 2.17.1 draft-ietf-seamoby-ct-reqs-05.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 585 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 35 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) ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '2') ** Obsolete normative reference: RFC 896 (ref. '3') (Obsoleted by RFC 7805) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Gary Kenward, editor 2 Internet Draft 3 draft-ietf-seamoby-ct-reqs-05.txt 4 Expires: April 2003 6 October, 2002 8 General Requirements for Context Transfer 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 The success of time sensitive services like VoIP telephony, video, 37 etc., in a mobile environment depends heavily on the ability to 38 minimize the impact of the traffic redirection during a change of 39 packet forwarding path. In the process of establishing the new 40 forwarding path, the nodes along the new path must be prepared to 41 provide similar forwarding treatment to the IP packets. The transfer 42 of context information may be advantageous in minimizing the impact 43 of host mobility on IP services. This document captures the set of 44 requirements for a context transfer solution and the requirements 45 for a generic context transfer protocol to carry the context between 46 the context transfer peers. 48 Table of Contents 50 1 Introduction 51 2 Conventions used in this document 52 3 Terminology 53 4 General Requirements 54 5. Protocol Requirements 55 6 Standardization of Feature Contexts 56 7 References 57 8 Acknowledgements 58 9 Author's Addresses 59 10 Full Copyright Statement 60 11 Funding Acknowledgement 62 1 Introduction 64 There are a large number of IP access networks that support mobile 65 hosts. For example, wireless Personal Area Networks (PANs), wireless 66 LANs, satellite WANs and cellular WANs. The nature of this mobility 67 is such that the communication path to the host may change frequently 68 and rapidly. 70 In networks where the hosts are mobile, the forwarding path through 71 the access network must often be redirected in order to deliver the 72 host's IP traffic to the new point of access. The success of time 73 sensitive services like VoIP telephony, video, etc., in a mobile 74 environment depends heavily upon the ability to minimize the impact 75 of this traffic redirection. In the process of establishing the new 76 forwarding path, the nodes along the new path must be prepared to 77 provide similar forwarding treatment to the IP packets. 79 The information required to support a specific forwarding treatment 80 provided to an IP flow is part of the context for that flow. To 81 minimize the impact of a path change on an IP flow, the context must 82 be replicated from the forwarding nodes along the existing path to 83 the forwarding nodes along the new path. The transfer of context 84 information may be advantageous in minimizing the impact of host 85 mobility on, for example, AAA, header compression, QoS, Policy, and 86 possibly sub-IP protocols and services such as PPP. 88 An analysis of the context transfer problem is captured in [2]. This 89 document captures the requirements for a context transfer solution 90 and the requirements for a generic context transfer protocol to 91 carry the context between the context transfer peers. 93 2 Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [1]. 99 3 Terminology 101 Most of the terms used in this document are defined in [2]. 103 Access Router (AR) 104 An IP router residing in an Access Network and connected to one or 105 more points of access. An AR offers connectivity to MNs. 107 4 General Requirements 109 This section addresses the facilities and services required in the access 110 network to properly support context transfer. The context transfer 111 solution will have to assume certain characteristics of the access network 112 and the mobility solution, and the availability of certain triggering events, 113 transport options, and so forth. These support capabilities are not 114 necessarily part of context transfer, per se, but are needed for context 115 transfer to operate as defined and effect the expected enhancements to MN 116 traffic handover. For convenience, this collection of support capabilities 117 are referred to as the "context transfer solution". 119 4.1 The context transfer solution MUST define the characteristics of the IP 120 level trigger mechanisms that initiate the transfer of context. 122 4.2 The IP level context transfer triggers MAY be initiated by a link level 123 (layer two) event. 125 4.3 The IP level trigger mechanisms for context transfer MUST hide the 126 specifics of any layer 2 trigger mechanisms. 128 Handover at the IP level is a consequence of a change in the physical 129 path used to communicate between the MN and the access network. The 130 mechanisms utilized to change the communications path at layer 2 are 131 specific to the physical characteristics of the medium, and often 132 specific to the layer 2 transmission technology being used (e.g. TIA 133 IS 2000, ETSI UMTS R4, IEEE 802.11). 135 In order for any action to be taken at the IP level to maintain IP 136 sessions during a layer 2 path change, some indication of the path 137 change must be made available to the IP level. One example of an 138 indicator would be the trigger event that initiates context transfer. 140 Since it is expected that IP handover, and thus context transfer will 141 work irrespective of the layer 2 technology, the IP level solutions 142 must not utilize specific layer 2 information. The conditions and 143 events that caused the generation of an IP level trigger must be 144 opaque to the IP level. This implies that there are general 145 characteristics of an IP level trigger that need to be defined so 146 that the triggers generated by different layer 2 solutions will have 147 identical semantics at the IP level. 149 4.4 The IP level context transfer triggers MAY be initiated by IP level 150 (layer three) signalling. 152 4.5 Any IP level signalling for Context Transfer MUST be separated from 153 the actual transfer of context. 155 4.6 The context transfer solution MAY support one-to-many context 156 transfer. 158 An MN may have connectivity to the access network through more than 159 one physical path at any given time, depending upon the 160 characteristics of the physical medium, and the layer 1 and 2 161 protocols and services. 163 The different physical paths may connect into the network via 164 different ARs. In this scenario, two or more ARs may be candidates 165 for handover of the MN's traffic and each will require the 166 appropriate IP context when forwarding commences. Exactly which AR 167 will be the target of the handover is often not known until the 168 handover is initiated, and providing the necessary context to all the 169 candidate ARs can only accelerate the handover process. 171 A one-to-many context transfer may be achieved using either a series 172 of point-to-point transfers, or a point-to-multipoint (multicast) 173 transfer. 175 4.7 The context transfer solution MUST support context transfer before, 176 during and after handover. 178 4.8 The context transfer solution MUST support a distributed approach in 179 which the Access Routers act as peers during the context transfer. 181 One main distinction between the various alternative approaches to 182 context transfer is the choice of the functional entity or entities that 183 orchestrate the transfer. A context transfer solution that relies upon 184 the ARs to effect a context transfer should be the most efficient approach, 185 as it involves the fewest possible entities. At the very least, the number 186 of protocol exchanges should be less when there are fewer entities involved. 188 4.9 The entities transferring context MUST support a process for mutual 189 authentication prior to initiating the transfer. 191 It is believed that if a formal authentication exchange (e.g. exchanging 192 credentials) were done during the context transfer, the computation 193 overhead for both the sender and the receiver would cause additional and 194 unnecessary latency to the handoff process. Therefore, the CT peers MUST 195 exchange credentials prior to any context transfer. 197 4.10 The context transfer solution SHOULD provide mechanisms to selectively 198 enable or disable context transfer for particular IP microflows or groups 199 of IP microflows. 201 The context associated with an MN's microflows is normally to be 202 transferred whenever it is required to support forwarding. However, 203 there may be conditions where it is desirable to selectively disable 204 context transfer for specific microflows. 206 For example, it may be desirable to provide an MN with the capability 207 to disallow the transfer of the context associated with one or more 208 of its microflows when handover occurs between networks administered 209 by different operators. 211 Local mechanisms for allowing context transfer to be disabled on a per 212 microflow basis have to be provided for in the context transfer solution. 213 These mechanisms will most likely be captured as part of the CT MIB, and 214 possibly, as part of a PIB, if policy based management is considered 215 desirable. 217 There are other mechanisms and protocols required to manage or control 218 the per microflow disabling of context transfer. These are clearly 219 out of the scope of the context transfer work. 221 4.11 Context information MAY be transferred in phases. 223 Providing for phased transfers allows the context acquisition 224 and transfer to be prioritized. 226 4.12 The context information to be transferred MUST be available at the 227 AR performing the transfer, prior to the initiation of a given phase 228 of the context transfer. 230 To effect a rapid transfer, the context information has to be readily 231 available when the AR begins a phase of the transfer. 233 If the context transfer is comprised of a single phase, then all of the 234 context must be available prior to the transfer initiation. 236 4.13 The context transfer solution MUST include methods for interworking 237 with any IETF IP mobility solutions. 239 4.14 The context transfer solution MAY include methods for interworking 240 with non-IETF mobility solutions. 242 4.16 The context transfer solution MUST be scalable. 244 5. Protocol Requirements 246 This section captures the general requirements for the context 247 transfer protocol. 249 5.1 General Protocol Requirements 251 5.1.1 The context transfer protocol MUST be capable of transferring all 252 of the different types of feature context necessary to support the 253 MN's traffic at a receiving AR. 255 5.1.2 The context transfer protocol design MUST define a standard 256 representation for encapsulating context information in the IP packet 257 payload that will be interpreted uniformly and perspicuously by 258 different implementations. 260 5.1.3 The context transfer protocol MUST operate autonomously from the 261 content of the context information being transferred. 263 5.1.4 The context transfer protocol design MUST define a standard method 264 for labelling each feature context being transferred. 266 Various protocols participate in setting up the service support for 267 any given microflow, and many of these protocols require feature 268 specific state to be maintained for the life of the IP session. The 269 context transfer protocol should provide a generic mechanism to carry 270 context information to an AR, irrespective of the context type. 272 Given that the desired context transfer protocol is a single, generic 273 protocol for transferring all feature context, the collection of 274 information representing the context for a given feature must be 275 encapsulated into a standard representation and labelled. 276 Encapsulation is necessary to keep the context for different features 277 separated. The receiving AR will use the label on an encapsulated 278 context to associate it with the appropriate service feature and 279 process the content appropriately. 281 The context transfer protocol does not need to know the contents of 282 these nuggets of encapsulated information. Indeed, for the protocol 283 to be independent from the type of context being transferred, it must 284 be oblivious the actual context. 286 5.1.5 The context transfer protocol design MUST provide for the future 287 definition of new feature contexts. 289 The context transfer solution must not attempt to define all possible 290 feature contexts to be transferred. Instead, it must provide for the 291 definition of new contexts in support of future service features, or 292 feature evolution. Guidance should be provided to future users of context 293 transfer on the best approach to defining feature context. 295 5.2 Transport Requirements 297 This section contains requirements on the context transfer transport. 299 5.2.1 The context transfer protocol MUST be specified so that it is 300 independent of the underlying transport. 302 Recognizing that the transport characteristics for context transfer 303 will depend on the particular application, it should be possible to 304 transfer context directly on top of reliable transports, such as 305 TCP or SCTP, unreliable transports, such as UDP, or as an option or 306 extension on another protocol, such as handover signalling. 308 5.3 Security 310 5.3.1 The protocol MUST provide for "security provisioning". 312 The security of the context information being exchanged between ARs 313 must be ensured. Security provisioning includes protecting the 314 integrity, confidentiality, and authenticity of the transfer, as well 315 as protecting the ARs against replay attacks. 317 5.3.2 The security provisioning for context transfer MUST NOT 318 require the creation of application layer security. 320 5.3.3 The protocol MUST provide for the security provisioning to be 321 disabled. 323 In some environments, the security provisioning provided for by the 324 context transfer protocol may not be necessary, or it may be 325 preferred to minimize the context transfer protocol overhead. 327 5.4 Timing Requirements 329 5.4.1 A context transfer MUST complete with a minimum number of protocol 330 exchanges between the source AR and the rest of the ARs. 332 The number of protocol exchanges required to perform a peer to peer 333 interaction is directly related to the unreliability, resource 334 consumption, and completion time of that interaction. A context 335 transfer will require signalling and data exchanges, but, as a general 336 rule, by keeping the number of these exchanges to a minimum, the 337 reliability, resource utilization and completion delay of the 338 transfer should improve. 340 5.4.2 The context transfer protocol design MUST minimize the amount of 341 processing required at the sending and receiving Access Routers. 343 If the context transfer protocol requires the context information to 344 be transferred in a form that requires significant additional 345 processing at each AR, delays may be incurred that impact the 346 reliability of the context. In other words, the context may become 347 obsolete before it can be reconstructed at the receiving AR. 349 Also, AR processing delay contributes to the overall context transfer 350 delay, and may make fulfilling requirements 5.4.1 and 5.4.2 difficult. 352 An example of a protocol design that would increase the processing 353 delay at the receiver is where the context information is segmented, 354 and the ordering of the segments is not preserved during transfer; 355 segmenting at the sender, and more likely, re-ordering of the 356 segments at the receiver could introduce significant additional 357 AR processing delays. 359 5.4.3 The Context Transfer protocol MUST meet the timing constraints 360 required by all the feature contexts. 362 A given feature context may have timing constraints imposed by the 363 nature of the service being support. The delivered context must 364 always comply with the requirements of the service if it is to be 365 useable. 367 5.4.4 The context transfer solution MUST provide for the aggregation of 368 multiple contexts. 370 5.4.5 If context aggregation is not support by the transport protocol 371 (via the Nagle algorithm [3]) then the context transfer protocol 372 MUST provide it. 374 There may be instances where there are multiple context transfers 375 pending. To reduce the overall transfer time, as well as transport 376 overhead that might be incurred by separately transferring each 377 context, the sending AR may choose to aggregate the contexts and 378 execute one transfer operation. 380 Note that if contexts are aggregated, the labelling method required 381 by 5.1.4 must include an identifier that allows the contexts to be 382 separated at the receiving AR. 384 5.5 Context Update and Synchronization 386 5.5.1 The base context transfer protocol SHOULD NOT provide direct 387 support for synchronization with outside events, since 388 synchronization is not a requirement for all or even most feature 389 contexts. 391 5.5.2 The base context transfer protocol MUST allow individual feature 392 context specifications to define their own synchronization with 393 external events. 395 5.5.3 The base context transfer protocol SHOULD NOT provide support for 396 updating context after it is transferred, since individual feature 397 contexts will differ in their need for update. 399 5.5.4 The base context transfer protocol MUST allow individual feature 400 context specifications to define their own update procedures if 401 required. 403 Most feature contexts will not require synchronization, however 404 there are a few that may. Header compression, for example, may require 405 that the header compressor on the old access router cease and the 406 compressor on the new router start in synchrony with hand over of 407 routing to the new router; otherwise, the compressor on the new 408 router will not be properly synchronized. Since most contexts don't 409 need synchronization support, the general CT solution need not support 410 it, but it should not provide a hindrance to those feature contexts 411 that do. 413 Feature contexts will differ in whether or not they require update. 414 A feature context such as QoS parameters for the service level 415 agreement with a user may not involve dynamically changing information, 416 but it may change during or after context transfer. Such feature 417 contexts may benefit from allowing the context to change after the 418 transfer is completed. Other feature contexts, such as header 419 compression, may be tightly synchronized with external events and 420 changes on the old router need to be discarded since the new router's 421 state may already have been modified. 423 5.6 Interworking with handover mechanisms 425 5.6.1 The context transfer protocol MAY provide input to the 426 handover process. 428 5.6.2 The context transfer protocol MUST include methods for exchanging 429 information with the handover process. 431 Both context transfer and handover require information on the 432 AR candidates for handover. The context transfer entities may, in the 433 process of establishing and supporting context transfer, acquire 434 information that would be useful to the handover process in 435 determining the new forwarding path: for example, the outcome of an 436 admission control decision at a receiving AR. 438 5.7 Partial Handover 440 5.7.1 The context transfer protocol MAY provide a mechanism for 441 supporting partial handovers. 443 In a situation where no single AR is capable of receiving a handover 444 of all of an MN's traffic, a mechanism could be provided that would 445 allow different IP microflows to be handed over to different ARs. 446 The information transferred to each AR must be limited to only the 447 context required to support the microflows that are actually handed 448 over. Thus, the context transfer protocol would need a mechanism for 449 partitioning the context and transferring each portion to the 450 appropriate AR. 452 6 Standardization of Feature Contexts 454 The context transfer protocol provides a basic framework in which 455 feature contexts of varying types can be transferred. Recognizing 456 that the particular feature contexts may have very different needs 457 with regard to update, synchronization, and transport, the base 458 context transfer protocol requirements are designed to not constrain 459 how the context transfer protocol is used for particular feature 460 contexts with respect to these points. In addition, some feature 461 contexts may require additional processing on the target access router 462 before they can be of use. Individual feature contexts will be 463 standardized by the method of IETF standards action. The 464 standardization of a feature context should describe how a feature 465 context utilizes the base context transfer protocol; if update, 466 synchronization, and additional processing are required, and, if so, 467 how they are achieved; and the transport used for the feature context. 469 7 References 471 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 472 Levels", RFC2119 (BCP), IETF, March 1997. 474 [2] Kempf, J., editor, "Problem Description: Reasons For Performing 475 Context Transfers Between Nodes in an IP Access Network", 476 draft-ietf-seamoby-context-transfer-problem-stat-04.txt, May 2002. 478 [3] Nagle, J., "Congestion Control in IP/TCP", RFC 896, January 1984. 480 8 Acknowledgements 482 Thank you to all who participated in the Seamoby working group context 483 transfer design team. 485 9 Author's Addresses 487 Hamid Syed 488 Nortel Networks 489 100 Constellation Crescent 490 Ottawa, Ontario. K2G 6J8 Phone: +1 613 763 6553 491 Canada Email: hmsyed@nortelnetworks.com 493 Gary Kenward 494 Nortel Networks 495 100 Constellation Crescent 496 Ottawa, Ontario. K2G 6J8 Phone: +1 613 765 1437 497 Canada Email: gkenward@nortelnetworks.com 499 Pat R. Calhoun 500 Black Storm Networks 501 250 Cambridge Avenue, Suite 200 502 Palo Alto, CA 94306 Phone: +1 650 617 2932 503 USA Email: pcalhoun@bstormnetworks.com 505 Madjid Nakhjiri 506 Motorola 507 1501 West Shure Drive 508 Arlington Heights IL 60004 Phone: +1 847 632 5030 509 USA Email: madjid.nakhjiri@motorola.com 511 Rajeev Koodli 512 Communications Systems Laboratory, Nokia Research Center 513 313 Fairchild Drive 514 Mountain View CA 94043 Phone: +1 650 625 2359 515 USA Email: rajeev.koodli@nokia.com 517 Kulwinder S. Atwal 518 Zucotto Wireless Inc. 519 Ottawa Ontario K1P 6E2 Phone: +1 613 789 0090 520 CANADA EMail: kulwinder.atwal@zucotto.com 522 Mark Smith 523 COM DEV Wireless 524 3450 Broad Street, Suite 107 525 San Luis Obispo, CA 93401 Phone: +1 805 544 1089 526 USA Email: mark.smith@comdev.cc 528 Govind Krishnamurthi 529 Communications Systems Laboratory, Nokia Research Center 530 5 Wayside Road 531 Burlington MA 01803 Phone: +1 781 993 3627 532 USA EMail: govind.krishnamurthi@nokia.com 534 James Kempf 535 DoCoMo Communication Laboratories USA 536 180 Metro Drive, Suite 300 537 San Jose, CA 95110 Phone: +1 408 451 4711 538 USA EMail: kempf@docomolabs-usa.com 540 10 Full Copyright Statement 542 "Copyright (C) The Internet Society (2002). All Rights Reserved. 543 This document and translations of it may be copied and furnished to 544 others, and derivative works that comment on or otherwise explain it 545 or assist in its implementation may be prepared, copied, published 546 and distributed, in whole or in part, without restriction of any 547 kind, provided that the above copyright notice and this paragraph 548 are included on all such copies and derivative works. However, this 549 document itself may not be modified in any way, such as by removing 550 the copyright notice or references to the Internet Society or other 551 Internet organizations, except as needed for the purpose of 552 developing Internet standards in which case the procedures for 553 copyrights defined in the Internet Standards process must be 554 followed, or as required to translate it into languages other than 555 English. 557 The limited permissions granted above are perpetual and will not be 558 revoked by the Internet Society or its successors or assigns. 560 This document and the information contained herein is provided on an 561 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 562 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 563 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 564 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 565 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 567 11 Funding Acknowledgement 568 Funding for the RFC editor function is currently provided by the 569 Internet Society.