idnits 2.17.1 draft-hamid-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 Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 8) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 10 instances of lines with control characters in the document. 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) == Outdated reference: A later version (-04) exists of draft-ietf-seamoby-context-transfer-problem-stat-00 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-context-transfer-problem-stat (ref. '2') == Outdated reference: A later version (-01) exists of draft-ietf-seamoby-mm-problem-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 3 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-hamid-seamoby-ct-reqs-01.txt Nortel Networks 4 Expires: September 2001 March, 2001 6 General Requirements for a Context Transfer Framework 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2001). All Rights Reserved. 31 Abstract 33 This document captures the set of general requirements for context 34 transfer. These requirements are provided for the replication and 35 synchronization of the context associated with a mobile node's 36 traffic between access routers. 38 1 Introduction 40 In networks where hosts are mobile, the success of real-time 41 sensitive services like VoIP telephony, video, etc. depends 42 heavily on the ability of the network to support seamless handover. 43 Ideally, seamless means that the handoff will not introduce any 44 degradation in the quality of the service provided to the user. At 45 the very least, the user should not perceive any degradation in 46 service quality during handoff. 48 The service quality offered at an access router is embodied in the 49 context of the support provided to the IP traffic. The ability of 51 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 53 a new access router to support the same service quality after handoff 54 is determined by the router's built-in capabilities, by the 55 availability of the necessary router resources, by the availability 56 of unused bandwidth on the links that the traffic must traverse to 57 and from the router, and, by the timely available of the service 58 support context at the router. 60 The support context referred to here is comprised of the information 61 necessary to support the all the committed service features, such as 62 AAA, header compression, Differentiated Services, Integrated Services, 63 policy enforcement, etc. [2]. This context is initially established 64 when the service is set-up between the mobile node and the network, 65 and changes over time as the components supporting the service 66 features change state. 68 In order for this context to be available at a new access router 69 after handoff, it must be replicated from the access router 70 currently supporting the mobile modes traffic. The replicated context 71 must represent the most recent support state, if the service is not 72 to be interrupted or degraded. Thus, when the mobile node's traffic 73 arrives at a new access router, the replicated context must be 74 synchronized with the context at the previous access router just 75 prior to the handoff. For seamless reactive context transfer, the 76 time scale of this synchronization is roughly on the order of the 77 allowable incremental delay for forwarding the next packet. For 78 proactive context transfer, the synchronization latency is on the 79 order of the average packet inter-arrival time for the mobile node's 80 traffic. 82 This document captures the requirements this context transfer in 83 Support of seamless mobility. 85 2 Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC-2119 [1]. 91 3 Terminology 93 The terminology and the definitions used in the document are for the 94 most part taken from [2]. This document defines additional 95 terminology needed to explain the requirements for the transfer of 96 context. This section presents the new general definitions. 98 3.1 Coverage Area (CA) 100 The coverage area for a given AR is defined in terms of the access 101 points (APs) that are connected to that AR. Each AP forwards traffic 102 between AR and a given MN. 104 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 106 For the purpose of describing Context Transfer, there is no need to 107 assume a given cardinality between ARs and APs. Thus, an AP may be 108 connected to multiple ARs, and an AR may be connected to multiple 109 APs. Each AP must be connected to at least one AR, and each AR must 110 be connected to at least one AP. 112 3.2 Forwarding Path Handover Scenarios 114 3.2.1 Break-before-make 116 Break-before-make is a term used to describe a discontinuity in 117 connectivity between MN and the access network during a handoff. 118 With a break-before-make handoff, the forwarding of an MN's traffic 119 along the current path is discontinued before forwarding of that 120 traffic is initated along the new path through the network. The old 121 connection for the traffic flow is "broken" before the new 122 connection is "made". 124 For example: an MN moves between the CAs of two ARs. In a 125 break-before-make scenario, the MN's traffic through the old AR, 126 and old AP, is stoppe before being redirected through 127 the new AR/AP pair. 129 In break-before-make, there is exists some interval where the MN's 130 traffic cannot be forwarded. The extent of this interval, and the 131 impact on the IP packets (additional packet drops or buffering 132 delay) is dependent upon the details of the break-before-make 133 alogorithm. 135 This definition of break-before-make is independent of the method 136 used for or the timing of the context transfer. The context 137 transfer may still be "proactive" or "reactive" (c.f. below). 139 3.2.2 Make-before-break 141 Make-before-break is a term used to describe the continuity of 142 connectivity between MN and the access network during a handoff. 143 With a make-before-break handoff, the MN's traffic flow is 144 established along the new path through the network, before the 145 old path is released. The new connection for the traffic flow is 146 "made" before the new connection is "broken". 148 For example, an MN moves between the CAs of two ARs. In a 149 make-before-break scenario, the MN's traffic will be forwarded to 150 the new AR, and the new AP, while the old AR/AP pair continues to 151 forward traffic. In make-before-break, there is exists some 152 interval where the MN's traffic traverses both paths. Whether 153 these two flows contain duplicated packets is dependent upon the 154 details of the make-before-break alogorithm. 156 This definition of make-before-break is independent of the method 157 used for or the timing of the context transfer. The context transfer 158 may still be "proactive" or "reactive" (c.f. below). 160 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 162 3.3 Context Transfer Scenarios 164 3.3.1 Mobile Arrival-Departure Event (MADE) 166 The MADE is an notification delivered to an AR when the MN enters 167 its CA. Reception of a MADE indicates that connectivity exists 168 between the AR and the MN through at least one AP. 170 3.3.2 Reactive Context Transfer 172 The context information required to completely supporting an IP 173 micro-flow is replicated to the access router at the instant when a 174 packet from that micro-flow arrives at the new access router. 176 A reactive context transfer can be performed for a make-before-break 177 or for a break-before-make handoff. 179 3.3.3 Proactive Context Transfer 181 The context information required to completely support an IP micro- 182 flow is replicated to the access router(s), that detect the presence 183 of MN in its coverage area, in advance of the first packet arrival 184 to one or any of the ARs. 186 A proactive context transfer can be performed for a make-before-break 187 or for a break-before-make handoff. 189 4 General Requirements for a Context Transfer Framework 191 This section captures the general requirements for context transfer. 192 The general requirements cover two functional areas. 193 - Distributed framework approach 194 - Context transfer mechanism 196 4.1 Distributed Framework Approach 198 An MN may have connectivity to the access network through more 199 than one access points (AP) at one time. The determination of which 200 APs are able to communicate with an MN is dependent entirely on the 201 link characteristics and the layer 2 protocols and services. 203 The APs able to communicate with an MN may be linked with one or 204 more ARs. In the scenario where two or more ARs are candidates for 205 fowarding an MN's traffic, the context for the MN's active 206 micro-flows must be replicated at every AR. 208 - The framework MUST support one-to-many context transfer. 210 To achieve seamless handover, the introduction of additional packet 211 delays and drops must be avoided. Context transfer will require 212 some exchange of information and since the context needs to be 214 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 216 established before an AR can provide the appropriate forwarding 217 treatment, it is necessary to initiate the transfer well before 218 forwarding is required to begin. 220 - The framework MUST support proactive context transfer. 222 The unpredictability of some channels, and the vagaries of layer 2 223 handoff mechanism ensure that a proactive approach may not always 224 be possible. There will be situations where there is no warning, 225 and an AR requires the context needed to forward traffic 226 immediately. 228 - The framework SHOULD support reactive context transfer. 230 There are various alternative approaches to context transfer, some 231 of which were reviewed in [2]. The main distinction between these 232 alternatives begins with the choice of the functional entity or 233 entities that orchestrate the context transfer (e.g. MN driven 234 versus network driven, centralized versus distributed. 236 A single entity or centralized approach to context transfer will 237 likely suffer from scalability difficulties as the number MN's or 238 the rate of handovers increases. Moreover, the most current context 239 information will only be available at the access router(s) actively 240 supporting an MN's flows. Thus, a centralized approach will first 241 require retrieving context from an AR before distributing it to 242 other ARs. 244 - The framework MUST support a distributed transfer approach 245 in which the access routers are responsible for transferring 246 context. 248 The actual context associated with an MN reflects the service 249 parameters that were agreed upon between the MN and the access 250 network when each microflow was established, and the state 251 variables for the service facilities supporting each microflow. 252 Various protocols participate in setting up the service support 253 for a given micro-flow, and many may require state be maintained 254 for the duration of the session. A few examples of context types 255 are captured in [2]. 257 It is likely that more than one network entity will be involved in 258 updating the context due to the interaction of the various 259 protocols with different network services. The the most relevant 260 instantiation of the context, however, is that which is local to 261 the AR and maintained for the purpose of suppor supporting a 262 microflow. A context transfer approach that uses the active AR as 263 the source of the context, and delivers the context directly to the 264 new AR would be the most efficient. The number of entities involved 265 in the context transfer would simply the number of ARs requiring 266 the context for a particular microflow. In addition, by implication, 267 the number of protocol exchanges would be less, as the number of 268 communicating entities is limited to those same ARs. 270 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 272 4.2 Context Transfer Protocol 274 The context transfer protocol is the mechanism for transporting 275 context information from one AR to another AR. The outcome of a 276 context transfer will be an up-to-date replication of the 277 configuration and state information from the source AR at the new 278 AR. 280 - The context transfer protocol MUST provide 100% reliable 281 transfer of the context information. 100% reliable 282 information transfer means no loss of information and no 283 induced errors. 285 - The context transfer protocol MUST deliver the context 286 without duplication or re-ordering of the information. 288 - The context transfer protocol MUST transfer the context fast 289 enough for the information to be meaningful at the receiving 290 AR. 292 The context at the AR actually supporting traffic from the MN will 293 change over time. In addition to the progression of the various 294 state information, the MN may initiate new microflow(s) or 295 discontinue existing microflows. The timing of these changes in 296 context is on the order of the intervals between packet arrivals 297 in the MN's traffic flow. 299 - The context transfer protocol MUST provide method for 300 synchronizing context information when it changes. 302 - The synchronization of context MUST preserve the integrity, 303 and thus the meaning, of the context at each AR who has 304 received the context. 306 As a corollary, any signaling exchanges required by the context 307 transfer protocol will introduce additional delay. Protocols such 308 as TCP [4] and COPS [5] require signalling exchanges, or 309 "handshakes" between the communicating entities at various stages 310 of the protocol session. 312 - The context transfer meachanism SHOULD minimize signaling 313 overhead when performing an actual context transfer. 315 The time taken to replicate context depends greatly upon the number 316 of packet exchanges required to complete a transfer of the context 317 information. In many situations, such as with a reactive 318 break-before-make scenario, the context transfer delay becomes a 319 critical factor in determining whether the service is disrupted or 320 not. 322 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 324 - The context transfer MUST complete with minimum number of 325 protocol exchanges between the source AR and the rest of the 326 ARs. 328 - The context transfer protocol MUST sustain the security of 329 context information. 331 Similarly, if the context transfer protocol delivers the information 332 in a form that requires significant processing at the AR before the 333 context is useable - for example, if the information has to be 334 re-ordered, then significant delay may be introduced in establishing 335 the replicated context. 337 - The context transfer protocol MUST minimize any processing 338 at the ARs. 340 A seamless handover of an MN's active sessions requires that there 341 be at least one AR capable of supporting the MN's traffic. In order 342 for the handoff to be targetted to the ARs capable of supporting the 343 MN's traffic, each AR must be able to return the admission status of 344 the context transfer. 346 - The context transfer protocol MUST provide for feedback from 347 each candidate AR of the admission status for each context 348 transfer attempt. 350 - The context transfer protocol MUST interwork with the 351 micro-mobility mechanism [3]. 353 In a situation where a single AR is not available to support the 354 whole context associated with an MN's traffic, a mechanism could 355 be provided to negotiate the handover of each of the active 356 sessions to different ARs. 358 Similarly, when complete support for a particular micro-flow is not 359 possible at any AR, it may be perferred that a degraded service be 360 negotiated over dropping the micro-flow at the time of handoff. 362 - The context transfer protocol MAY provide a mechanism for 363 negotiating partial context transfer. 365 - Any mechanism for partial context transfer MUST interwork 366 with the micro-mobility mechanism [3]. 368 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 370 5 References 372 [1] S. Bradner, "keywords for use in RFCs to Indicate Requirement 373 Levels", RFC2119 (BCP), IETF, March 1997. 375 [2] The seamoby CT design team, "Context transfer: problem 376 statement", draft-ietf-seamoby-context-transfer-problem- 377 stat-00.txt. 379 [3] The seamoby MM design team, "Micro-mobility: problem 380 statement", draft-ietf-seamoby-mm-problem-00.txt. 382 [4] "Transmission Control Protocol", RFC 793, September 1981. 384 [5] D.Durham et. al, "The COPS (Common open Policy Services) 385 protocol", RFC2748, January 2000. 387 6 Acknowledgments 389 The contents of this draft are a result of the discussions within the 390 Nortel Networks Advanced Wireless Network Technology Lab and we would 391 like to thank all the members who contributed in these discussions. 393 7 Author's Address 395 Syed, Hamid 396 100-Constellation Crescent 397 Nepean, Ontario. K2G 6J8 Phone: 1-613-763-6553 398 Canada Email: hmsyed@nortelnetworks.com 400 Kenward, Gary 401 100-Constellation Crescent 402 Nepean, Ontario. K2G 6J8 Phone: 1-613-765-1437 403 Canada Email: gkenward@nortelnetworks.com 405 8 Full Copyright Statement 407 "Copyright (C) The Internet Society (date). All Rights Reserved. 408 This document and translations of it may be copied and furnished to 409 others, and derivative works that comment on or otherwise explain it 410 or assist in its implementation may be prepared, copied, published 411 and distributed, in whole or in part, without restriction of any 412 kind, provided that the above copyright notice and this paragraph 413 are included on all such copies and derivative works. However, this 414 document itself may not be modified in any way, such as by removing 415 the copyright notice or references to the Internet Society or other 416 Internet organisations, except as needed for the purpose of 417 developing Internet standards in which case the procedures for 418 copyrights defined in the Internet Standards process must be 419 followed, or as required to translate it into languages other than 420 English. 422 draft-hamid-seamoby-ct-reqs-01.txt March, 2001 424 The limited permissions granted above are perpetual and will not be 425 revoked by the Internet Society or its successors or assigns. 427 This document and the information contained herein is provided on an 428 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 429 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 430 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 431 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 432 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 434 draft-hamid-seamoby-ct-reqs-01.txt March, 2001