idnits 2.17.1 draft-korhonen-mobopts-link-characteristics-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 816. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 55 has weird spacing: '...obility perfo...' == Line 296 has weird spacing: '...rmation could...' == Line 541 has weird spacing: '...elivery mecha...' == Line 659 has weird spacing: '...elivery mecha...' -- 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.) -- The document date (June 9, 2006) is 6530 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) == Outdated reference: A later version (-10) exists of draft-iab-link-indications-04 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-quickstart-03 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft TeliaSonera 4 Expires: December 11, 2006 S. Park 5 SAMSUNG Electronics 6 J. Zhang 7 University of York 8 C. Hwang 9 SAMSUNG Electronics 10 P. Sarolahti 11 Nokia Research Center 12 June 9, 2006 14 Link Characteristic Information for IP Mobility Problem Statement 15 draft-korhonen-mobopts-link-characteristics-ps-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 11, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document discusses the problem space related to frequent changes 49 in the local link or sub-path characteristics of a mobile node due to 50 various reasons such as vertical handovers and the delivery of the 51 sub-path characteristic information from a mobile node to its peer 52 nodes. The purpose of this document is to define the scope and 53 requirements for possible future work on a generic sub-path 54 characteristic information delivery mechanism for optimizing IP 55 mobility performance and reducing the implications that significant 56 changes in the local link or sub-path characteristics tend to create 57 to the transport and application protocol behaviour by altering the 58 end-to-end path properties. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Assumptions and Observations . . . . . . . . . . . . . . . . . 5 66 4. Background and Motivations . . . . . . . . . . . . . . . . . . 6 67 4.1 Multimode Wireless Terminals . . . . . . . . . . . . . . . 6 68 4.2 Heterogeneous Networks and Terminal Mobility . . . . . . . 6 69 4.3 Adaptive Application and Services . . . . . . . . . . . . 7 70 4.4 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . 8 71 4.5 Network-Initiated Handover . . . . . . . . . . . . . . . . 8 72 4.6 Signaling Support . . . . . . . . . . . . . . . . . . . . 8 73 4.7 Link Information Facility . . . . . . . . . . . . . . . . 9 74 4.8 Classification of Explicit Notification Mechanisms . . . . 9 75 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 76 5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2 Out of Scope Issues . . . . . . . . . . . . . . . . . . . 13 78 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 83 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 85 Intellectual Property and Copyright Statements . . . . . . . . 19 87 1. Introduction 89 Multi-radio mobile nodes (MN) are becoming common and consequently 90 the frequency of handovers between different access technologies 91 increases. These mobile nodes, for example mobile phones or PDAs, 92 may be reachable through multiple interfaces, even simultaneously. 93 The possibility of using a single or multiple interfaces at a time 94 for sending and receiving IP packets depends on the mobile node 95 capabilities. In both cases, roaming between heterogeneous links 96 (vertical handovers) can occur. A significant change in the access 97 link characteristic as a result of a handover may also affect end-to- 98 end path properties. These changes in the local link characteristics 99 and consequently in the end-to-end path properties are usually not 100 detected nor reacted quickly enough by higher layer transport 101 protocols and applications. Typically higher layers do not react to 102 the changes in path properties until certain mechanisms, such as 103 congestion control or error recovery, eventually get invoked at some 104 point later. This may cause undesirable disruptions, performance 105 degradation to the ongoing connections, unnecessary underutilization 106 of the available network capacity, or sudden overloading of the new 107 access link. For example, when a mobile node performs a handover 108 from an IEEE 802.11b WLAN link (high bandwidth link) to a CDMA 109 Cellular link (low bandwidth link), the home agent and correspondent 110 nodes may still continue transmitting at the rate adapted to the 111 802.11b bandwidth. Because the actual path capacity is now smaller, 112 a packet loss burst will occur and often result in inefficient loss 113 recovery at the transport protocol level. The situation could be 114 resolved by explicitly informing the other connection peer about the 115 significant changes in the local access link characteristics. 116 Unfortunately, existing IP mobility, transport and application layer 117 protocols do not provide any facility to indicate which type of link 118 the mobile node is currently attached to or what kind of changes 119 there were on the local access link. 121 The local access link characteristic may also vary significantly as a 122 result of a handover between links of the same type (horizontal 123 handovers). For example the new link may have significantly more 124 traffic load that the old link had or the new route the IP traffic 125 now takes has different end-to-end path properties. Moreover, even 126 if the mobile node stays on the same link, the local access link 127 characteristics may change significantly due to various reasons, for 128 example because of sudden variations of the traffic load on the 129 current link. All of these situations may lead to similar adverse 130 effects as those with vertical handovers. 132 This document discusses the problems related to the changes in the 133 local access link or sub-path characteristics that may also lead to 134 changes in the end-to-end path properties. This document also 135 discusses the actual problems or the lack of delivering the link 136 characteristic information between a mobile node and relevant nodes 137 along the end-to-end path. The purpose of this document is to define 138 the scope and requirements for generic link or sub-path 139 characteristic information delivery for: 1) optimizing mobility 140 performance and 2) enhancing transport protocol adaptation to the 141 changes end-to-end path properties that are a result of significant 142 local access link characteristics. 144 1.1 Problem Statement 146 The fundamental problem or rather the fundamental feature of all 147 widely accepted and standardized IP mobility enabling technologies is 148 that they are mobile node centric, operating on top of the link layer 149 and lacking proper dialogues about the access network characteristics 150 with the relevant remote network nodes. With the emergence of 151 multimode mobile terminals and the roaming capability between 152 different access technologies, there is a need of sharing the local 153 sub-path characteristic information with the remote communicating 154 nodes, due to the fact that a wireless access link is most likely the 155 bottleneck on the end-to-end communication path and often represent a 156 significant portion of the end-to-end delay. Sharing the local sub- 157 path characteristics information with the remote end allows the other 158 end to detect and react much faster to the significant changes in the 159 end-to-end path properties. This is expected to reduce or even 160 completely avoid possible complications to the IP transport and 161 service quality as many applications and the congestion control 162 algorithms of the transport layer may often fail to respond fast 163 enough to such changes or may react in a wrong way when the path 164 characteristics suddenly change. 166 Sometimes the bottleneck of the end-to-end communication can be 167 elsewhere on the connection path (e.g., in WLAN+ADSL combination the 168 ADSL link can be the bottleneck, not the WLAN), and the sub-path 169 characteristics may need to be considered in conjunction with mobile 170 node's link characteristic itself. 172 Currently there is no standardized protocol for such link 173 characteristic information delivery. It is because existing mobility 174 protocols do not provide a mechanism to indicate which type of link 175 the mobile node is currently attached to. Therefore, some new 176 signaling mechanism is needed in terms of peer-to-peer communication. 177 At the same time, the new signaling mechanism to be defined should 178 avoid significantly increasing the amount of signaling traffic load, 179 especially over wireless links. Moreover, examining the tradeoff 180 between the added delivery and computation load of the new mechanism 181 and gained advantage is also an issue that needs serious 182 considerations. 184 For the multiple wireless interfaces on the mobile node, there is a 185 possibility that the link characteristic information exchange can be 186 carried over multiple links simultaneously. It may be necessary for 187 the new signaling mechanism to support multiple connections per 188 application as multi-homing scenarios. 190 Protocols like Mobile IP [RFC3344][RFC3775], SCTP [RFC2960], DCCP 191 [RFC4340], RT(C)P [RFC3550], SIP [RFC3261], etc can be used for 192 carrying link characteristic information in their own extensions as 193 new options or fields. It might be more time consuming and complex 194 to extend each of these protocols instead of developing a generic 195 signaling solution. 197 2. Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in [RFC2119]. 203 3. Assumptions and Observations 205 This document has a few fundamental assumptions concerning the 206 general networking environment and certain capabilities supported by 207 the mobile node and the remote nodes in the case that link 208 characteristics delivery functionality is to be deployed. These 209 assumptions are listed as follows: 211 o When multiple wireless interfaces are active on the mobile node, 212 link characteristic information exchanges can be carried over 213 multiple links simultaneously. It implies link characteristic 214 information delivery to support multiple connections per 215 application as multi-homing scenarios. 217 o In case the mobile node's handover is in progress, link 218 characteristic information delivery can be exchanged between the 219 mobile node and the remote nodes regardless of mobility signaling. 221 o Given link characteristic information from the mobile node, the 222 remote sender can adjust its sending rate and other communication 223 parameters dynamically within the limitations of the congestion 224 control principles [RFC2914] by using the received information as 225 a (strong) hint about changes in path properties. 227 o The mobile node has the required capabilities to gather relevant 228 characteristics information from its access links and/or access 229 network. Currently, some link characteristic information is in 230 use in an proprietary manner. 232 o When the bottleneck of the end-to-end communication is not in the 233 local access network, neither the mobile node nor any of its peers 234 have a robust way to determine the problem. The mobile node may 235 be able to gather some end-to-end path characteristics 236 information, for example when exchanging mobility related 237 signaling with the remote node. A node is assumed to act 238 conservatively with the link characteristic information due to the 239 lack of properly measured path characteristic information. 241 o The mobile node invokes link characteristic information 242 notification message based on its management policy (e.g., 243 measured information threshold, periodic delivery, event driven, 244 etc.) and the required values and parameters are configured on the 245 mobile node (and the remote nodes if any). These policies are 246 outside the scope of the IETF. 248 o Mobile nodes, correspondent nodes, mobility management nodes and 249 other network entities are not expected to understand or support 250 link characteristic information exchange if they do not need this 251 particular feature. Legacy nodes and network entities also fall 252 into this category. 254 4. Background and Motivations 256 In this section we discuss the background and motivation for 257 developing link characteristic information delivery mechanism based 258 on scenarios. 260 4.1 Multimode Wireless Terminals 262 Recently multimode wireless terminals have become more and more 263 common. For example, most modern mobile terminals are equipped with 264 a selection of cellular radios, various IEEE 802.11 family radios, 265 Bluetooth radios and IEEE 802.16e Broadband Wireless (called mobile 266 WiMAX or WiBro. It is possible that multiple of these radios are 267 simultaneously activated to attach to network instead of just one 268 single radio. In addition, the idea of being always on-line via 269 wireless access is not far-fetched anymore. 271 4.2 Heterogeneous Networks and Terminal Mobility 273 Due to the growth of various wireless technologies, different access 274 radios overlap, providing mobile users a heterogeneous wireless 275 access environment. Mobile terminals are increasingly expected to be 276 able to perform a seamless handover between these different access 277 technologies in order to maintain connections and achieve best QoS 278 while moving. 280 However, the characteristics and capabilities of these different 281 access networks differ considerably, for example in terms of 282 available bandwidth, latency, bit-error rates and queue management, 283 though in most cases wireless access links remain as the bottleneck 284 of the whole communication path. Therefore, vertical handovers may 285 lead to abrupt changes in the link performance. 287 Link characteristics may also change considerably when the mobile 288 node handovers between links of the same type, due to the different 289 traffic loads on the old and the new link. Furthermore, even when 290 the mobile node remains connected to the same link and no handover 291 occurs, path characteristics can change abruptly (for example when 292 radio conditions change on the local link). 294 Another local link related information that could be of use for 295 mobile nodes is the utilization of the link or the number of 296 potential users on the link. This kind of information could help 297 mobile nodes or rather the transport protocols to estimate the fair 298 share of the link capacity. 300 Current IP mobility management protocols do not deliver link related 301 information or indications locally to upper layers. Furthermore, 302 there is currently no way of signaling link characteristic related 303 information from the mobile node to the remote network nodes. Some 304 upper layer transport protocols and services can adapt to the changed 305 connection condition, however reactively only after the network 306 capacity misuse (over-utilization or under-utilization) has taken 307 place and has possibly been detected by e.g. some upper layer 308 congestion control mechanism. Thus those upper layer protocols, 309 applications and services may experience unnecessarily suboptimal 310 performance during this period, and often for a relatively long- 311 lasting period even after detecting and responding to the misuse. 313 4.3 Adaptive Application and Services 315 Adaptive applications and services can greatly benefit from a 316 standardized mechanism that notifies abrupt changes of the link 317 characteristics in a proactively manner. That would allow 318 applications and services to adapt to the new connection conditions 319 immediately instead of through some generally conservative adapting 320 and error handling mechanisms. After all, these mechanisms are not 321 capable of reacting efficiently in the scenarios in question as they 322 were not designed to handle the situation discussed in this document. 324 One possible example of an adaptive application benefiting from link 325 characteristics information would be streaming services for mobile 326 vehicles. Assume a certain mobile vehicle can connect to the network 327 using various access technologies -- using macro cellular access when 328 the vehicle is on move and using 802.11 WLAN access when the vehicle 329 is not moving and within a hotspot coverage. The adaptive 330 application could then immediately scale the streaming service 331 content based on the mobile node's reported link capabilities -- 332 without waiting for the possible streaming protocol feedback 333 mechanism to discover the increased or decreased bandwidth of the 334 link. 336 There are several scalable-coding algorithms such as SVC (Scalable 337 Video Coding), H.264 Scalable Extension, BSAC (Bit Sliced Arithmetic 338 Coding), etc. to support a flexible control in terms of audio as well 339 as video. There are, however, some limitations to adjust its ongoing 340 traffic volumes from the sender because of lack of dynamic signaling 341 from the receiver while changing its link characteristics. 343 4.4 Traffic Shaping 345 In the case that some or all traffic destined to the mobile node goes 346 through a mobility anchor node (e.g., the home agent in Mobile IPv6 347 bi-directional tunneling mode or previous access router in Mobile IP 348 fast handover protocols), it would be useful for the mobility anchor 349 node to shape the traffic towards the mobile node according to the 350 current link characteristic information provided by the mobile node. 351 For example, if the mobile node has announced its current link 352 capacity as 64kbps, the mobility anchor node has no point forwarding 353 more traffic than the announced data rate to overflow the mobile 354 node's access link. Instead, the mobility anchor node may limit the 355 forwarding rate itself or notify the remote peers (e.g. the 356 correspondent nodes) to reduce their traffic by some means. 358 4.5 Network-Initiated Handover 360 In some future circumstances, remote network nodes, such as the 361 Mobile IP home agent, may wish to suggest the mobile node to handover 362 to another access network possibly based on the required service 363 quality or certain administrative policies. With link 364 characteristics information delivery mechanism, the remote nodes 365 would have more knowledge to be used for such decision makings. 367 4.6 Signaling Support 369 Currently there is no existing standardized or IP mobility solution 370 independent mechanism to signal link characteristic information from 371 the mobile node to the relevant remote network nodes. The relevant 372 remote network nodes include mobility management nodes (e.g. Mobile 373 IP home agent), correspondent nodes, and any other network nodes that 374 may consider link characteristic information useful. 376 4.7 Link Information Facility 378 To deliver link characteristic information, the mobile node has to 379 get its access link characteristics dynamically. IEEE 802.21 is 380 working for the MIHS (Media Independent Handover Services) composed 381 of MIES (Media Independent Event Service), MICS (Media Independent 382 Command Service) and MIIS (Media Independent Information Service). 383 Both MIES and MICS are for the local stack operations. MIES provides 384 event classification, event filtering and event reporting 385 corresponding to dynamic changes in link characteristics, link 386 status, and link quality. MICS enables the mobile node to manage and 387 control link behavior relevant to handovers and mobility. In 388 addition, implications of link indications are well described by 389 [I-D.iab-link-indications]. Consequently, the link information is 390 not vague and trivial facilities in IETF. How the mobile node 391 acquires its link characteristics dynamically and accurately is 392 beyond the scope of the link characteristic information delivery. 394 Even if the link information is delivered end-to-end, the mobile node 395 retrieving and sending the information cannot usually have more than 396 a good guess of the actual end-to-end path characteristics. However, 397 if the mobile node knows that the local link characteristics have 398 changed by some magnitude, it can inform the other end to trigger the 399 upper layer congestion control mechanisms to determine the effective 400 end-to-end path characteristics. Similarly the mobile node may base 401 some of its path characteristic information reasoning on the known 402 bounds of the local link. For example if the local link is known to 403 have 600ms roundtrip time and maximum bandwidth of 48kbps then the 404 end-to-end path characteristics cannot be better. Furthermore, some 405 initial measurement results on the end-to-end path can, for example, 406 be gathered by monitoring possible mobility related signaling that 407 takes place between the end hosts. 409 4.8 Classification of Explicit Notification Mechanisms 411 Based on the past work on explicit notification and communication 412 mechanisms, the following types of signaling between the end hosts 413 and the network can be identified. Signaling can be separated into 414 in-band and out-of-band mechanisms, based on whether the information 415 is piggy-backed along with the transport protocol traffic, or whether 416 the signaling is done by means of separate control packets, 417 respectively. 419 Benefit of using in-band signaling is that the signaling can be 420 better assumed to take the same network path as the protocol data. 421 Out-of-band mechanisms could take a different path due to different 422 policy actions: An IPsec policy might not aggregate the signaling 423 protocol to same security association as the data protocol, or a 424 policy-based routing system could select a different path for the 425 out-of-band signaling than for the protocol data. Sometimes a packet 426 with unrecognized content can cause the whole IP packet to be dropped 427 in the network due to NAT or firewall policy, or because of defective 428 router. When the message is transferred in-band, the loss 429 notification usually comes naturally with the protocol's own 430 acknowledgment mechanisms. For an out-of-band mechanism there might 431 not be any direct mechanisms to inform about the loss. Out-of-band 432 messages are also generally more susceptible for security problems 433 caused by a third party generating malicious messages. The drawback 434 of an in-band mechanism is that a loss due to additional content in 435 the IP packet disturbs also the data transfer. 437 In the following we discuss and evaluate various in-band and out-of- 438 band signaling mechanisms that could potentially be used to deliver 439 link characteristic information messages. 441 o In-band message processed by end hosts -- When a message is 442 attached to the transport protocol header, only the communication 443 end hosts can be assumed to see the message. Also IPv6 has 444 extension headers that are only processed by the end hosts. The 445 routers along the network path are not typically capable of 446 processing this kind of message, and if the packet is encrypted 447 with IPsec [RFC2401], it is impossible by other nodes than the end 448 hosts to read the message. The benefit of using transport header 449 is that it can be expected that the legacy routers and different 450 flavour of network middle boxes are not likely to take unexpected 451 actions on the packet, such as dropping a packet with unknown 452 option. An example of this kind of notification type is LMDR 453 [I-D.swami-tcp-lmdr] that uses a TCP option to allow a mobile end 454 host to notify the other end that it has moved. 456 o In-band message processed by some routers -- If a message uses 457 some of the reserved bits in the IP header, or is an IP hop-by-hop 458 option, routers along the network path are able to process it and 459 take appropriate actions. There can be two types of messages: 460 those that are only read by a router, and those that can also be 461 altered by the router. The options that are to be altered by the 462 router should not be covered by IPsec [RFC2402]. In case of IPv4 463 this means that such an option should be explicitly marked as a 464 mutable field for IPsec. An IPv6 option includes a bit that tells 465 IPsec whether the option is mutable or non-mutable. IPsec does 466 not cover the reserved bits in the IP header, either. Problem 467 with the use of IP options is that as of today, network is known 468 to drop the majority of packets with unknown IP options. Some 469 explicit notifications are such that they can be of benefit even 470 if a single router along the network path supports them. Explicit 471 Congestion Notification [RFC3168] is one such mechanism. 473 o In-band message processed by all routers -- Some message types 474 need to be processed by all routers in order to have effect. For 475 example Quick-Start [I-D.ietf-tsvwg-quickstart] is one such 476 mechanism. This is a hard requirement for any mechanism to be 477 used in the Internet, and this kind of schemes are likely to 478 remain in limited controlled portions of the network. These 479 messages would also utilize the reserved bits in the IP header or 480 IP options, with the same challenges as listed above. In 481 addition, usually the sender must be able to verify that all 482 routers have processed the message. One way to do this is by the 483 means of a separate TTL field in the message that is compared to 484 the IPv4 TTL or IPv6 hop count. If the two fields do not give 485 matching information about the number of hops on the connection 486 path, it can be concluded that there were routers that did not 487 process the notification message. IP tunnels are also a 488 considerable challenge to this kind of message, as they can hide 489 the inner IP header with the in-band message from the routers. 490 Sometimes the TTL field comparison does not reveal the presence of 491 such tunnels on the path. 493 o Out-of-band message processed by end hosts -- Sending ICMP 494 messages from the receiver to the sender of packet has been a 495 traditional way of reporting an error condition or other 496 information about the data transfer [RFC0792][RFC2463]. Usually 497 the transport header, or a part of it, is included in the message 498 to help the receiver of the ICMP message to identify the transport 499 connection the ICMP message concerns, and to conduct some 500 primitive security screening. 502 o Out-of-band message processed by routers -- Resource Reservation 503 Protocol (RSVP) [RFC2205] uses a specific protocol type for QoS 504 signaling between the sender and the receiver. RSVP requires that 505 every router processes the messages, so it includes a similar kind 506 of TTL-based hop tracking mechanism as Quick-Start does. In order 507 to have out-of-band messages processed at routers, they need to be 508 set to monitor the given protocol type inside the IP packets, or 509 the IP packets need to use an router alert option to trigger 510 further processing at the router. As with the in-band messages, 511 IP tunnels and layer 2 switching system may prevent the signaling 512 from working, or cause the signaling to work defectively. An out- 513 of-band message could also be sent from one of the router along 514 the network path, of which some of the ICMP error messages are a 515 common example. Taking strong actions based on such signaling is 516 not generally encouraged, though, because there would be many 517 security issues in the validity and authenticity of such messages. 519 To summarize, when designing a new signaling mechanism, a number of 520 issues should be considered based on the experiences from past 521 proposals. To mention two of the important issues, it should be 522 established whether some or all nodes along the path are required to 523 process the message. For example, short-cutting the usual congestion 524 or rate control mechanisms to get an increased sending rate requires 525 a permission from each node along the network path. Second, it 526 should be evaluated whether it is feasible to embed the signaling 527 into the protocol data traffic, or whether a separate signaling flow 528 is more appropriate, either as embedded to some existing signaling 529 such as Mobile IP binding updates, or using an entirely new protocol. 530 It is also possible that a combination of different mechanisms is 531 used: for example, a mobile host could use an end-to-end method to 532 tell the corresponding node about change in its status. In response, 533 corresponding node could trigger a hop-by-hop QoS request in the 534 changed environment. 536 5. Design Considerations 538 5.1 Requirements 540 This section lists the general requirements for a link or sub-path 541 characteristic information delivery mechanism design. The link 542 characteristic information delivery solution MUST fulfill all the 543 'MUST and MUST NOT requirements' listed below: 545 R1 Mobility solution independent -- Link characteristic information 546 encoding and encapsulation MUST NOT be specific to a certain IP 547 mobility solution (such as Mobile IP or HIP [RFC4423]). 549 R2 Link characteristic information delivery SHOULD be applicable to 550 existing mobility mechanisms (e.g., MIP, SIP, etc.), as well as to 551 transport-layer multi-homing mechanisms such as SCTP [RFC2960] 553 R3 Transport protocol independent -- The delivery of the link 554 characteristic information MUST support multiple transport 555 solutions and protocols. 557 R4 Link technology independent -- The transport of link 558 characteristic information MUST NOT be dependant on some 559 particular link technology and link technology specific way of 560 carrying information. 562 R5 Lightweight delivery mechanism MUST be designed to avoid 563 significantly increasing the amount of signaling traffic load, 564 especially over wireless links. 566 R6 Applicable when the mobile node is either multi-homed or not -- In 567 the multi-homed case, multiple interfaces of the mobile node may 568 be activated to send and receive traffic. The solution MUST be 569 able to handle link characteristic information for each link 570 separately. The solution SHOULD also support combining the 571 knowledge of all its available access links. 573 R7 Applicable when the remote peers are also mobiles -- In this case 574 the peers of both sides may support link characteristics 575 information delivery, and the solution MUST be able to handle the 576 "double jump" situations. 578 R8 Applicable when the mobile node is communicating with multiple 579 nodes over a single link -- The mobile node SHOULD be able to 580 support an algorithm for the link capacity allocation and notify 581 each node of its share. 583 R9 Link characteristic information encapsulation format MUST be 584 applicable to any existing and future link technology -- This 585 requirement basically means that the actual contents and 586 encapsulation format of link characteristic information MUST be 587 extendable to new link types and new link characteristics data. 589 R10 Link characteristic information delivery solution MUST NOT 590 introduce new security vulnerabilities to the environment it is 591 applied to. 593 R11 Link characteristic information MUST support middlebox traversal. 595 R12 The mobile node SHOULD be able to delegate its link 596 characteristic information delivery to other mobility management 597 node and undo the delegation when applicable and desired. 599 R13 Link Characteristic Information SHOULD be exchanged between the 600 mobile and remote node prior the handover, if just possible. This 601 would allow remote node to react proactively and utilize the link 602 characteristic information immediately when the handover takes 603 place. 605 R14 Link Characteristic Information SHOULD follow the congestion 606 control principles as described in [RFC2914]. 608 5.2 Out of Scope Issues 610 This section lists the issues that are considered as strictly out of 611 scope of this problem statement and requirements document. 613 o Placing any requirements on the cross layer communications about 614 link characteristic information. 616 o Unidirectional links. 618 o Non-IP-capable links. 620 o Defining a new mobility framework. 622 o Defining how link characteristic information delivery initiator 623 (usually the mobile node) gathers its access link characteristic 624 information. 626 o Defining how link characteristic information delivery responder 627 (the relevant remote network nodes) actually make use of link 628 characteristic information. For example the remote peer may use 629 link characteristic information to optimize the transport layer 630 protocols by some specific algorithm particularly tied to the 631 transport layer protocols in question. 633 o Defining link capacity assignment algorithm when multiple 634 communicating nodes are present on one interface of the mobile 635 node. The assignment algorithms are left for the specific 636 applications and protocols that actually utilize link 637 characteristic information. 639 6. IANA considerations 641 This particular document does not define any new name spaces to be 642 managed by IANA. This document does not either reserve any new 643 numbers or names under any existing name space managed by IANA. 645 7. Security Considerations 647 This document provides a problem statement and requirements for the 648 link characteristic information delivery when deployed used along 649 with IP mobility management. The link characteristic information 650 delivery signaling SHOULD be secured. Intermediating network nodes 651 between the link characteristic information sender and the receiver 652 MUST NOT be able to modify the contents of the link characteristic 653 information delivery messages. The strength of the applied security 654 mechanism for the link characteristic information delivery MUST NOT 655 weaken the existing security solution on the environment where the 656 link characteristic information delivery is applied to. 658 Potentially, malicious hosts may misuse the link characteristic 659 information delivery mechanism(s) to deliver erroneous link 660 characteristic information to the receiving hosts. However, a 661 malicious hosts who have the capability of fabricating and delivering 662 valid looking link characteristic information messages with erroneous 663 content are supposed to be easier to launch more serious attacks 664 using other mechanisms. 666 8. Acknowledgments 668 The authors would like to thank Rajeev Koodli and Koshiro Mitsuya for 669 their valuable comments and suggestions. The authors would also like 670 to thank Markku Kojo and Hannes Tschofenig for their detailed 671 comments, corrections and text contributions. 673 9. References 675 9.1 Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 681 RFC 2914, September 2000. 683 9.2 Informative References 685 [I-D.iab-link-indications] 686 Aboba, B., "Architectural Implications of Link 687 Indications", draft-iab-link-indications-04 (work in 688 progress), December 2005. 690 [I-D.ietf-tsvwg-quickstart] 691 Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 692 Start for TCP and IP", 693 draft-ietf-tsvwg-quickstart-03 (work in progress), 694 October 2006. 696 [I-D.swami-tcp-lmdr] 697 Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility 698 Detection and Response (LMDR) Algorithm for TCP", 699 draft-swami-tcp-lmdr-07 (work in progress), February 2006. 701 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 702 RFC 792, September 1981. 704 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 705 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 706 Functional Specification", RFC 2205, September 1997. 708 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 709 Internet Protocol", RFC 2401, November 1998. 711 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 712 RFC 2402, November 1998. 714 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 715 Protocol (ICMPv6) for the Internet Protocol Version 6 716 (IPv6) Specification", RFC 2463, December 1998. 718 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 719 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 720 Zhang, L., and V. Paxson, "Stream Control Transmission 721 Protocol", RFC 2960, October 2000. 723 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 724 of Explicit Congestion Notification (ECN) to IP", 725 RFC 3168, September 2001. 727 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 728 A., Peterson, J., Sparks, R., Handley, M., and E. 729 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 730 June 2002. 732 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 733 August 2002. 735 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 736 Jacobson, "RTP: A Transport Protocol for Real-Time 737 Applications", STD 64, RFC 3550, July 2003. 739 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 740 in IPv6", RFC 3775, June 2004. 742 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 743 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 745 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 746 (HIP) Architecture", RFC 4423, May 2006. 748 Authors' Addresses 750 Jouni Korhonen 751 TeliaSonera Corporation. 752 P.O.Box 970 753 FI-00051 Sonera 754 FINLAND 756 Phone: +358 40 534 4455 757 Email: jouni.korhonen@teliasonera.com 759 Soohong Daniel Park 760 Mobile Convergence Laboratory, SAMSUNG Electronics. 761 416 Maetan-3dong, Yeongtong-gu 762 Suwon, Gyeonggi-do 443-742 763 KOREA 765 Phone: +82 31 200 4508 766 Email: soohong.park@samsung.com 768 Ji Zhang 769 Communications Research Group, University of York. 770 Heslington 771 York YO10 5DD 772 United Kingdom 774 Phone: +44 1904 432310 775 Email: jz105@ohm.york.ac.uk 777 Cheulju Hwang 778 Mobile Convergence Laboratory, SAMSUNG Electronics. 779 416 Maetan-3dong, Yeongtong-gu 780 Suwon, Gyeonggi-do 443-742 781 KOREA 783 Phone: +82 31 200 4508 784 Email: cheolju.hwang@samsung.com 785 Pasi Sarolahti 786 Nokia Research Center 787 P.O.Box 407 788 Helsinki FI-00045 789 FINLAND 791 Phone: +358 50 4876607 792 Email: pasi.sarolahti@iki.fi 794 Intellectual Property Statement 796 The IETF takes no position regarding the validity or scope of any 797 Intellectual Property Rights or other rights that might be claimed to 798 pertain to the implementation or use of the technology described in 799 this document or the extent to which any license under such rights 800 might or might not be available; nor does it represent that it has 801 made any independent effort to identify any such rights. Information 802 on the procedures with respect to rights in RFC documents can be 803 found in BCP 78 and BCP 79. 805 Copies of IPR disclosures made to the IETF Secretariat and any 806 assurances of licenses to be made available, or the result of an 807 attempt made to obtain a general license or permission for the use of 808 such proprietary rights by implementers or users of this 809 specification can be obtained from the IETF on-line IPR repository at 810 http://www.ietf.org/ipr. 812 The IETF invites any interested party to bring to its attention any 813 copyrights, patents or patent applications, or other proprietary 814 rights that may cover technology that may be required to implement 815 this standard. Please address the information to the IETF at 816 ietf-ipr@ietf.org. 818 The IETF has been notified of intellectual property rights claimed in 819 regard to some or all of the specification contained in this 820 document. For more information consult the online list of claimed 821 rights. 823 Disclaimer of Validity 825 This document and the information contained herein are provided on an 826 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 827 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 828 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 829 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 830 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 831 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 833 Copyright Statement 835 Copyright (C) The Internet Society (2006). This document is subject 836 to the rights, licenses and restrictions contained in BCP 78, and 837 except as set forth therein, the authors retain all their rights. 839 Acknowledgment 841 Funding for the RFC Editor function is currently provided by the 842 Internet Society.