idnits 2.17.1 draft-ietf-seamoby-context-transfer-problem-stat-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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-seamoby-context-transfer-problem-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-seamoby-context-transfer-problem-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-seamoby-context-transfer-problem-', but the file name used is 'draft-ietf-seamoby-context-transfer-problem-stat-01' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.1 Scope of the Context Transfer Solution' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9 Security Considerations' ) ** 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.) ** There are 165 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 2001) is 8375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 423 looks like a reference -- Missing reference section? '2' on line 426 looks like a reference Summary: 7 errors (**), 1 flaw (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Context and Micro-mobility Routing Working Group O. H. Levkowetz 3 Internet Draft ABNW 4 draft-ietf-seamoby-context-transfer-problem- P. R. Calhoun 5 stat-01.doc Sun MicroSystems, Inc 6 Expires: November 2001 G. Kenward 7 H. M. Syed 8 Nortel Networks 9 J. Manner 10 University of Helsinki 11 M. Nakhjiri 12 Motorola 13 G. Krishnamurthi 14 R. Koodli 15 Nokia 16 K. S. Atwal 17 Zucotto Wireless 18 M. Thomas 19 Cisco 20 M. Horan 21 COM DEV 22 P. Neumiller 23 3Com 24 May 2001 26 Problem Description: Reasons For Performing Context Transfers 27 Between Nodes in an IP Access Network 29 Status of This Memo 31 This document is an Internet-Draft and is in full conformance with 32 all provisions of Section 10 of RFC2026. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Copyright Notice 52 Copyright (C) The Internet Society (2001). All Rights Reserved. 54 Abstract 56 There are a large number of IP access networks that support mobility 57 of hosts. For example, wireless Personal Area Networks (PANs), 58 wireless LANs, satellite WANs and cellular WANs. The nature of this 59 mobility is such that the communication path to the host changes 60 frequently and rapidly. 62 This Internet-Draft describes the problem encountered during 63 mobility that requires the exchange of IP context between different 64 forwarding nodes in an access network. 66 Table of Contents 68 1 Introduction...................................................2 69 2 Reference Definitions..........................................3 70 3 The Need for Context Transfer..................................4 71 3.1 Scope of the Context Transfer Solution .....................5 72 3.2 Reference Architectures ....................................6 73 4 A Description of Context.......................................6 74 4.1 Feature ....................................................6 75 4.2 Feature Context ............................................7 76 4.3 Microflow Context ..........................................7 77 4.4 Common Context .............................................7 78 4.5 Examples of Feature Context ................................7 79 5 Context Transfer and Mobility..................................8 80 6 Forwarding Node Capabilities...................................8 81 7 Inter-technology Context Transfers.............................8 82 8 Performance Considerations.....................................8 83 9 Security Considerations........................................9 84 10 Recommendations...............................................9 86 1 Introduction 88 There are a large number of IP access networks that support hosts 89 that are mobile. For example, wireless Personal Area Networks 90 (PANs), wireless LANs, satellite WANs and cellular WANs. The nature 91 of this mobility is such that the communication path to a host may 92 change frequently and rapidly. 94 In networks where the hosts are mobile, the forwarding path through 95 the access network must often be redirected in order to deliver the 96 host's IP traffic to the new point of access. The success of a time 97 sensitive service such as VoIP telephony, video, etc., in a mobile 98 environment depends heavily upon the minimization of the impact of 99 this traffic redirection. In the process of establishing the new 100 forwarding path, the nodes along the new path must be prepared to 101 provide similar forwarding treatment to the IP packets. 103 The information required in support of a specific forwarding 104 treatment provided to IP traffic is part of the context for that 105 traffic. This context is comprised of configuration and state 106 information. To minimize the impact of a path change on an IP flow, 107 the context used at the forwarding nodes along the original path, 108 must be replicated at the forwarding nodes along the new path. 110 The transfer of context information may be advantageous in 111 minimizing the impact of host mobility on, for example, AAA, header 112 compression, QoS, Policy, and possibly sub-IP protocols and services 113 such as PPP. Context transfer at a minimum will be used to replicate 114 the configuration information needed to establish the respective 115 protocols and services. In addition, it may also provide the 116 capability to replicate state information, allowing stateful 117 protocols and services at the new node to be activated along the new 118 path with less delay and less signalling overhead. 120 2 Reference Definitions 122 Mobile Node 124 An IP node capable of changing its point of attachment to the 125 network. The mobile node is usually an end user host, but may be a 126 forwarding node for a network that is itself mobile. 128 Forwarding Node 130 A node that supports IP forwarding within the access network. This 131 includes all routers, gateways, servers and other nodes within the 132 network that have IP protocol stacks and forward IP traffic to and 133 from a mobile node. 135 A forwarding node will be connected to one or more other forwarding 136 nodes. Some forwarding nodes will be connected to zero or more 137 mobile nodes. The forwarding nodes that connect to mobile nodes will 138 do so through a layer two entity that supports wireless 139 communications. 141 Microflow 143 One useful definition for the fundamental unit of IP service is the 144 microflow. RFC 2475 [1] defines a microflow as: 146 A single instance of an application-to application flow of packets 147 destined to or originated from a mobile device (MN or MH), which is 148 identified by source address, source port, destination address, 149 destination port and protocol id. 151 RFC 2207 [2] provides a definition of a microflow that applies to 152 IPSec packets. It is based on the IPSec SPI found in the AH or ESP 153 headers. Other methods for identifying for IP microflows may be 154 defined in the future, e.g. the Ipv6 flow label. 156 3 The Need for Context Transfer 158 In networks where the hosts are mobile, the forwarding path through 159 the access network must often be redirected in order to deliver the 160 host's IP traffic to the new point of access. The success of a time 161 sensitive service such as VoIP telephony, video, etc., in a mobile 162 environment depends heavily upon the minimization of the impact of 163 this traffic redirection. In the process of establishing the new 164 forwarding path, the nodes along the new path must be prepared to 165 provide similar forwarding treatment to the IP packets. 167 Figure 1 and 2 below illustrate an example of a handover scenario. A 168 mobile node, MN7, is shown attached to the Internet via an access 169 network. The forwarding nodes, FN1 through to FN7 comprise a portion 170 of this access network. FN1 and FN7 are the last forwarding nodes 171 before the untethered link to MN7. This last link allows the nodes 172 to move while maintaining connectivity to the edge of the access 173 network - e.g. the last link is wireless. For simplicity, many 174 details of a real access network topology have been left out of the 175 diagrams. 177 Prior to handoff, the path for MN7's traffic traverses FN1 and FN2. 178 It is presumable that FN1 and FN2 have been configured to provide 179 specific forwarding services for MN7's traffic, and that some of 180 these services may require state information to be maintained. 182 MN7's traffic 183 <------------------> 184 ------- ------- 185 [ MN7 ]<= = = =>| FN1 |=================| FN2 |======== 186 ------- /------- 187 / 188 -------/ 189 | FN4 | 190 /-------\ 191 / \ 192 / \ 193 -------/ \------- 194 - - -| FN7 | | FN6 |---- 195 ------- ------- 197 Figure 1: Path Prior to Handover 198 When MN7's movement results in the link to FN1 to be replaced by a 199 link to FN7, MN7's traffic must be re-directed along a new 200 forwarding path, illustrated in Figure 2 as the path through FN7, 201 FN4 and FN2. In many mobile networks, this handover can occur 202 frequently, and sometimes with little or no warning. 203 ------- ------- 204 - - -| FN1 |----------------| FN2 |======== 205 ------- //------- 206 // MN7's traffic 207 -------/ <-----------> 208 | FN4 | 209 //------\ 210 MN7's traffic // \ 211 <-----------> // \ 212 -------/ \------- 213 [ MN7 ]<= = = =>| FN7 | | FN6 |---- 214 ------- ------- 216 Figure 2: Path Re-Directed After Handover 218 If the forwarding treatment provided to MN7's traffic is to be 219 sustained, the support conditions at FN1 and FN2 must be reproduced 220 at FN7 and FN4. At the very least, this requires that FN7 and FN4 be 221 configured to provide the appropriate support to the traffic flow. 222 However, establishing forwarding support along the new path through 223 the use of IP signalling protocols would be relatively time 224 consuming. In addition, given that some forwarding services may 225 maintain state information, simply configuring FN7 and FN4 would not 226 circumvent disruption of the services. 228 Given that FN7 and FN4 support the same functionality as FN1, it 229 should be possible to reproduce the needed support along the new 230 forwarding path by capturing the salient information at FN1 as it 231 exists just prior to the handover, and then use that information to 232 replicate the state of FN1 at FN7 and FN4. 234 3.1 Scope of the Context Transfer Solution 236 The information required to produce the necessary forwarding 237 treatments at a node is referred to as the support "context". In 238 order to replicate the context of one forwarding node at another 239 forwarding node, an open, standard solution for context transfer 240 must be developed. 242 In addition, for a forwarding node to be able to interpret the 243 transferred context, both the syntax and the semantics of the 244 context information must be defined. Definition of the actual 245 context information will be specific to the support feature being 246 replicated, however, a generic container format of the payload of 247 context transfer messages is required for inter-operability. 249 3.2 Reference Architectures 251 The concept of the "forwarding node" is used here to describe the 252 general context transfer problem. In different networks, the actual 253 context transfer may take place between different entities within 254 the network. In some cases the preferred context transfer peers 255 might be the routers at the edge of the access network. In other 256 situations, it may be more appropriate to transfer context between 257 wireless access points that also support forwarding of IP packets. 259 The context transfer solution will be applicable to any nodes that 260 support forwarding of a mobile nodes IP traffic. 262 4 A Description of Context 264 The term _context_ pertains to all information required by a 265 forwarding node specific to supporting the IP traffic for a 266 particular mobile node. 268 The context for a mobile node can be partitioned into three 269 categories: 271 - information required to provide generaly support to the 272 mobile node; 274 - information required to provide common support to the 275 mobile node's traffic; 277 - information required to support specific features of the 278 forwarding treatment for an IP microflow. 280 4.1 Feature 282 A feature is an aspect of the IP forwarding treatment that is 283 instantiated for each mobile node, and which may support one or more 284 of the mobile nodes microflows. A feature must include associated 285 configuration information: at the very least, some identification 286 information for the mobile node, such as the mobile node's IP 287 address. A feature may have associated state information. 289 In other words, for the purpose of supporting mobility the features 290 of interest all have context pertinent to the forwarding of a 291 specific mobile nodes IP packets. Examples of features include: 292 header compression, security, subscriber policy, and quality of 293 service. 295 Each feature is, in general, supported by an amalgamation of one or 296 more protocols and associated local support mechanisms. As an 297 example, header compression is a feature that consists of various 298 "mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP 299 header compression, operating according to well-defined "protocols". 300 Thus, an instance of a feature reflects the state associated with 301 protocols and the corresponding mechanisms. 303 4.2 Feature Context 305 Feature context is the condition or state of an instance of a 306 particular feature. It represents the current evolution of the 307 behaviour of that feature instance. At a given instant in time, 308 feature context is represented by the values of the associated data 309 elements. 311 Some of the data elements associated with a feature are time 312 invariant and, thus, represent the configuration of the feature 313 instance. Other data elements, which are often referred to as the 314 "state variables" for the feature instance, change value over time 315 as a consequence of the various operations performed in support of 316 the feature instance. 318 A feature context is believed to be the smallest indivisible unit of 319 context that can be transferred between forwarding nodes. 321 4.3 Microflow Context 323 A microflow context is the collection of the various feature 324 contexts associated with a single IP microflow. It is the smallest 325 unit of context that must be transferred in order to re-establish 326 support for the microflow at a forwarding node. 328 4.4 Common Context 330 Some of the associated feature contexts may be applicable to more 331 then one of the IP microflows comprising the mobile node's traffic. 332 An example of this might be the authentication state for the mobile. 333 This type of feature context is also required to support each 334 microflow, but because of the multiplicity of the relationship to 335 the mobile node's microflows, it would seem prudent to transfer one 336 instance of the context, independent of the microflow context. 338 4.5 Examples of Feature Context 340 Some examples of feature contexts that are candidates for context 341 transfer are given below. This list is provided solely to illustrate 342 the nature of the context transfer problem domain. 344 - encryption context; 345 - authentication context; 346 - authorization context; 347 - accounting context; 348 - header compression context; 349 - quality of service context; 350 - policy enforcement context; 351 - multicast group membership; 352 - buffer state; 353 - sub-network layer context (e.g. PPP context). 355 5 Context Transfer and Mobility 357 Context transfer is an enhancement to a mobility solution that is 358 clearly most effective when used on a local scale between forwarding 359 nodes within a subnetwork. However, with due consideration to the 360 nature of the context and the requirements for transfer of that 361 context, context transfer should be applicable between any two 362 similar forwarding nodes. 364 6 Forwarding Node Capabilities 366 Context transfer between two forwarding nodes is worthwhile only if 367 the receiving node's capabilities are similar enough to those of the 368 sending node that the received context can be utilized. This does 369 not mean that the two nodes are identical in their implementation, 370 nor does it even imply that they must have identical capabilities. 372 A forwarding node that cannot make use of received context could, 373 and should, refuse the transfer. This would result in a situation no 374 different then mobile handover without context transfer. 376 7 Inter-technology Context Transfers 378 The context transfer described here operates at the IP layer, and 379 should be applicable to situations where the forwarding nodes are 380 supporting different wireless link technologies. 382 An exception to this would be where sub-IP layer context is an 383 intrinsic part of the forwarding treatment. In this situation, an 384 interworking solution must be developed for sub-IP context transfer 385 between the two technologies. This issue is outside the scope of the 386 Seamoby working group. 388 8 Performance Considerations 390 The purpose of context transfer is to sustain the services being 391 provided to a mobile node's traffic during handover. It is 392 essentially an enhancement to a mobility solution that ultimately 393 must result in an improvement in handover performance. The various 394 aspects of performance must be a prime consideration in the 395 development of the context transfer solution. 397 9 Security Considerations 399 Context transfer does not introduce any new types of threats to the 400 security of an IP network. The context itself may contain sensitive 401 information; in which case security measures applied to its transfer 402 should be the same as those measures applied to the transport of 403 information between peers in an IP network. 405 10 Recommendations 407 The Seamoby context transfer design team recommends the following: 409 - investigation into candidates for context transfer - in 410 particular, feature context transfer, and an analysis 411 of the transfer requirements for each candidate; 413 - the development of a framework and protocol(s) that will 414 support the transfer of configuration and state context 415 between the forwarding nodes of an IP network. 417 The context transfer solution must interwork with existing and 418 emerging IP protocols, in particular, those protocols supporting 419 mobility in an IP network. 421 References 423 [1] Blake, et al., "An Architecture for Differentiated Services", 424 RFC 2475, December 1998. 426 [2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows", 427 RFC 2207, September 1997. 429 Authors' Addresses 430 O. Henrik Levkowetz 431 A Brand New World 432 Osterogatan 1 433 S-164 28 Kista 434 SWEDEN 436 Phone: +46 8 477 9942 437 EMail: henrik@levkowetz.com 439 Pat R. Calhoun 440 Network and Security Research Center, Sun Labs 441 15 Network Circle 442 Menlo Park CA 94025 443 USA 445 Phone: +1 650-786-7733 446 EMail: pcalhoun@eng.sun.com 447 Gary Kenward 448 Nortel Networks 449 3500 Carling Avenue 450 Nepean, Ontario K2G 6J8 451 CANADA 453 Phone: +1 613-765-1437 454 EMail: gkenward@nortelnetworks.com 456 Hamid Syed 457 Nortel Networks 458 100 Constellation Crescent 459 Nepean Ontario K2G 6J8 460 CANADA 462 Phone: +1 613 763-6553 463 EMail: hmsyed@nortelnetworks.com 465 Jukka Manner 466 Department of Computer Science, University of Helsinki 467 P.O. Box 26 (Teollisuuskatu 23) 468 FIN-00014 Helsinki 469 FINLAND 471 Phone: +358-9-191-44210 472 EMail: jmanner@cs.helsinki.fi 474 Madjid Nakhjiri 475 Motorola 476 1501 West Shure Drive 477 Arlington Heights IL 60004 478 USA 480 Phone: +1 847-632-5030 481 EMail: madjid.nakhjiri@motorola.com 483 Govind Krishnamurthi 484 Communications Systems Laboratory, Nokia Research Center 485 5 Wayside Road 486 Burlington MA 01803 487 USA 489 Phone: +1 781 993 3627 490 EMail: govind.krishnamurthi@nokia.com 491 Rajeev Koodli 492 Communications Systems Lab, Nokia Research Center 493 313 Fairchild Drive 494 Mountain View CA 94043 495 USA 497 Phone: +1 650 625 2359 498 EMail: rajeev.koodli@nokia.com 500 Kulwinder S. Atwal 501 Zucotto Wireless Inc. 502 Ottawa Ontario K1P 6E2 503 CANADA 505 Phone: +1 613 789 0090 506 EMail: kulwinder.atwal@zucotto.com 508 Michael Thomas 509 Cisco Systems 510 375 E Tasman Rd 511 San Jose CA 95134 512 USA 514 Phone: +1 408 525 5386 515 EMail: mat@cisco.com 517 Mat Horan 518 COM DEV Wireless Group 519 San Luis Obispo CA 93401 520 USA 522 Phone: +1 805 544 1089 523 EMail: mat.horan@comdev.cc 525 Phillip Neumiller 526 3Com Corporation 527 1800 W. Central Road 528 Mount Prospect IL 60056 529 USA 531 EMail: phil_neumiller@3com.com 533 Full Copyright Statement 535 Copyright (C) The Internet Society (2001). All Rights Reserved. 537 This document and translations of it may be copied and furnished to 538 others, and derivative works that comment on or otherwise explain it 539 or assist in its implementation may be prepared, copied, published 540 and distributed, in whole or in part, without restriction of any 541 kind, provided that the above copyright notice and this paragraph 542 are included on all such copies and derivative works. However, this 543 document itself may not be modified in any way, such as by removing 544 the copyright notice or references to the Internet Society or other 545 Internet organizations, except as needed for the purpose of 546 developing Internet standards in which case the procedures for 547 copyrights defined in the Internet Standards process must be 548 followed, or as required to translate it into languages other than 549 English. 551 The limited permissions granted above are perpetual and will not be 552 revoked by the Internet Society or its successors or assigns. 554 This document and the information contained herein is provided on an 555 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 556 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 557 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 558 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 559 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Acknowledgement 563 Funding for the RFC editor function is currently provided by the 564 Internet Society.