Network Working Group J. Korhonen Internet-Draft TeliaSonera Expires: December 11, 2006 S. Park SAMSUNG Electronics J. Zhang University of York C. Hwang SAMSUNG Electronics P. Sarolahti Nokia Research Center June 9, 2006 Link Characteristic Information for IP Mobility Problem Statement draft-korhonen-mobopts-link-characteristics-ps-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 11, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses the problem space related to frequent changes Korhonen, et al. Expires December 11, 2006 [Page 1] Internet-Draft Link Characteristic Information June 2006 in the local link or sub-path characteristics of a mobile node due to various reasons such as vertical handovers and the delivery of the sub-path characteristic information from a mobile node to its peer nodes. The purpose of this document is to define the scope and requirements for possible future work on a generic sub-path characteristic information delivery mechanism for optimizing IP mobility performance and reducing the implications that significant changes in the local link or sub-path characteristics tend to create to the transport and application protocol behaviour by altering the end-to-end path properties. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assumptions and Observations . . . . . . . . . . . . . . . . . 5 4. Background and Motivations . . . . . . . . . . . . . . . . . . 6 4.1 Multimode Wireless Terminals . . . . . . . . . . . . . . . 6 4.2 Heterogeneous Networks and Terminal Mobility . . . . . . . 6 4.3 Adaptive Application and Services . . . . . . . . . . . . 7 4.4 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . 8 4.5 Network-Initiated Handover . . . . . . . . . . . . . . . . 8 4.6 Signaling Support . . . . . . . . . . . . . . . . . . . . 8 4.7 Link Information Facility . . . . . . . . . . . . . . . . 9 4.8 Classification of Explicit Notification Mechanisms . . . . 9 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Out of Scope Issues . . . . . . . . . . . . . . . . . . . 13 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Korhonen, et al. Expires December 11, 2006 [Page 2] Internet-Draft Link Characteristic Information June 2006 1. Introduction Multi-radio mobile nodes (MN) are becoming common and consequently the frequency of handovers between different access technologies increases. These mobile nodes, for example mobile phones or PDAs, may be reachable through multiple interfaces, even simultaneously. The possibility of using a single or multiple interfaces at a time for sending and receiving IP packets depends on the mobile node capabilities. In both cases, roaming between heterogeneous links (vertical handovers) can occur. A significant change in the access link characteristic as a result of a handover may also affect end-to- end path properties. These changes in the local link characteristics and consequently in the end-to-end path properties are usually not detected nor reacted quickly enough by higher layer transport protocols and applications. Typically higher layers do not react to the changes in path properties until certain mechanisms, such as congestion control or error recovery, eventually get invoked at some point later. This may cause undesirable disruptions, performance degradation to the ongoing connections, unnecessary underutilization of the available network capacity, or sudden overloading of the new access link. For example, when a mobile node performs a handover from an IEEE 802.11b WLAN link (high bandwidth link) to a CDMA Cellular link (low bandwidth link), the home agent and correspondent nodes may still continue transmitting at the rate adapted to the 802.11b bandwidth. Because the actual path capacity is now smaller, a packet loss burst will occur and often result in inefficient loss recovery at the transport protocol level. The situation could be resolved by explicitly informing the other connection peer about the significant changes in the local access link characteristics. Unfortunately, existing IP mobility, transport and application layer protocols do not provide any facility to indicate which type of link the mobile node is currently attached to or what kind of changes there were on the local access link. The local access link characteristic may also vary significantly as a result of a handover between links of the same type (horizontal handovers). For example the new link may have significantly more traffic load that the old link had or the new route the IP traffic now takes has different end-to-end path properties. Moreover, even if the mobile node stays on the same link, the local access link characteristics may change significantly due to various reasons, for example because of sudden variations of the traffic load on the current link. All of these situations may lead to similar adverse effects as those with vertical handovers. This document discusses the problems related to the changes in the local access link or sub-path characteristics that may also lead to changes in the end-to-end path properties. This document also Korhonen, et al. Expires December 11, 2006 [Page 3] Internet-Draft Link Characteristic Information June 2006 discusses the actual problems or the lack of delivering the link characteristic information between a mobile node and relevant nodes along the end-to-end path. The purpose of this document is to define the scope and requirements for generic link or sub-path characteristic information delivery for: 1) optimizing mobility performance and 2) enhancing transport protocol adaptation to the changes end-to-end path properties that are a result of significant local access link characteristics. 1.1 Problem Statement The fundamental problem or rather the fundamental feature of all widely accepted and standardized IP mobility enabling technologies is that they are mobile node centric, operating on top of the link layer and lacking proper dialogues about the access network characteristics with the relevant remote network nodes. With the emergence of multimode mobile terminals and the roaming capability between different access technologies, there is a need of sharing the local sub-path characteristic information with the remote communicating nodes, due to the fact that a wireless access link is most likely the bottleneck on the end-to-end communication path and often represent a significant portion of the end-to-end delay. Sharing the local sub- path characteristics information with the remote end allows the other end to detect and react much faster to the significant changes in the end-to-end path properties. This is expected to reduce or even completely avoid possible complications to the IP transport and service quality as many applications and the congestion control algorithms of the transport layer may often fail to respond fast enough to such changes or may react in a wrong way when the path characteristics suddenly change. Sometimes the bottleneck of the end-to-end communication can be elsewhere on the connection path (e.g., in WLAN+ADSL combination the ADSL link can be the bottleneck, not the WLAN), and the sub-path characteristics may need to be considered in conjunction with mobile node's link characteristic itself. Currently there is no standardized protocol for such link characteristic information delivery. It is because existing mobility protocols do not provide a mechanism to indicate which type of link the mobile node is currently attached to. Therefore, some new signaling mechanism is needed in terms of peer-to-peer communication. At the same time, the new signaling mechanism to be defined should avoid significantly increasing the amount of signaling traffic load, especially over wireless links. Moreover, examining the tradeoff between the added delivery and computation load of the new mechanism and gained advantage is also an issue that needs serious considerations. Korhonen, et al. Expires December 11, 2006 [Page 4] Internet-Draft Link Characteristic Information June 2006 For the multiple wireless interfaces on the mobile node, there is a possibility that the link characteristic information exchange can be carried over multiple links simultaneously. It may be necessary for the new signaling mechanism to support multiple connections per application as multi-homing scenarios. Protocols like Mobile IP [RFC3344][RFC3775], SCTP [RFC2960], DCCP [RFC4340], RT(C)P [RFC3550], SIP [RFC3261], etc can be used for carrying link characteristic information in their own extensions as new options or fields. It might be more time consuming and complex to extend each of these protocols instead of developing a generic signaling solution. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Assumptions and Observations This document has a few fundamental assumptions concerning the general networking environment and certain capabilities supported by the mobile node and the remote nodes in the case that link characteristics delivery functionality is to be deployed. These assumptions are listed as follows: o When multiple wireless interfaces are active on the mobile node, link characteristic information exchanges can be carried over multiple links simultaneously. It implies link characteristic information delivery to support multiple connections per application as multi-homing scenarios. o In case the mobile node's handover is in progress, link characteristic information delivery can be exchanged between the mobile node and the remote nodes regardless of mobility signaling. o Given link characteristic information from the mobile node, the remote sender can adjust its sending rate and other communication parameters dynamically within the limitations of the congestion control principles [RFC2914] by using the received information as a (strong) hint about changes in path properties. o The mobile node has the required capabilities to gather relevant characteristics information from its access links and/or access network. Currently, some link characteristic information is in use in an proprietary manner. Korhonen, et al. Expires December 11, 2006 [Page 5] Internet-Draft Link Characteristic Information June 2006 o When the bottleneck of the end-to-end communication is not in the local access network, neither the mobile node nor any of its peers have a robust way to determine the problem. The mobile node may be able to gather some end-to-end path characteristics information, for example when exchanging mobility related signaling with the remote node. A node is assumed to act conservatively with the link characteristic information due to the lack of properly measured path characteristic information. o The mobile node invokes link characteristic information notification message based on its management policy (e.g., measured information threshold, periodic delivery, event driven, etc.) and the required values and parameters are configured on the mobile node (and the remote nodes if any). These policies are outside the scope of the IETF. o Mobile nodes, correspondent nodes, mobility management nodes and other network entities are not expected to understand or support link characteristic information exchange if they do not need this particular feature. Legacy nodes and network entities also fall into this category. 4. Background and Motivations In this section we discuss the background and motivation for developing link characteristic information delivery mechanism based on scenarios. 4.1 Multimode Wireless Terminals Recently multimode wireless terminals have become more and more common. For example, most modern mobile terminals are equipped with a selection of cellular radios, various IEEE 802.11 family radios, Bluetooth radios and IEEE 802.16e Broadband Wireless (called mobile WiMAX or WiBro. It is possible that multiple of these radios are simultaneously activated to attach to network instead of just one single radio. In addition, the idea of being always on-line via wireless access is not far-fetched anymore. 4.2 Heterogeneous Networks and Terminal Mobility Due to the growth of various wireless technologies, different access radios overlap, providing mobile users a heterogeneous wireless access environment. Mobile terminals are increasingly expected to be able to perform a seamless handover between these different access technologies in order to maintain connections and achieve best QoS while moving. Korhonen, et al. Expires December 11, 2006 [Page 6] Internet-Draft Link Characteristic Information June 2006 However, the characteristics and capabilities of these different access networks differ considerably, for example in terms of available bandwidth, latency, bit-error rates and queue management, though in most cases wireless access links remain as the bottleneck of the whole communication path. Therefore, vertical handovers may lead to abrupt changes in the link performance. Link characteristics may also change considerably when the mobile node handovers between links of the same type, due to the different traffic loads on the old and the new link. Furthermore, even when the mobile node remains connected to the same link and no handover occurs, path characteristics can change abruptly (for example when radio conditions change on the local link). Another local link related information that could be of use for mobile nodes is the utilization of the link or the number of potential users on the link. This kind of information could help mobile nodes or rather the transport protocols to estimate the fair share of the link capacity. Current IP mobility management protocols do not deliver link related information or indications locally to upper layers. Furthermore, there is currently no way of signaling link characteristic related information from the mobile node to the remote network nodes. Some upper layer transport protocols and services can adapt to the changed connection condition, however reactively only after the network capacity misuse (over-utilization or under-utilization) has taken place and has possibly been detected by e.g. some upper layer congestion control mechanism. Thus those upper layer protocols, applications and services may experience unnecessarily suboptimal performance during this period, and often for a relatively long- lasting period even after detecting and responding to the misuse. 4.3 Adaptive Application and Services Adaptive applications and services can greatly benefit from a standardized mechanism that notifies abrupt changes of the link characteristics in a proactively manner. That would allow applications and services to adapt to the new connection conditions immediately instead of through some generally conservative adapting and error handling mechanisms. After all, these mechanisms are not capable of reacting efficiently in the scenarios in question as they were not designed to handle the situation discussed in this document. One possible example of an adaptive application benefiting from link characteristics information would be streaming services for mobile vehicles. Assume a certain mobile vehicle can connect to the network using various access technologies -- using macro cellular access when Korhonen, et al. Expires December 11, 2006 [Page 7] Internet-Draft Link Characteristic Information June 2006 the vehicle is on move and using 802.11 WLAN access when the vehicle is not moving and within a hotspot coverage. The adaptive application could then immediately scale the streaming service content based on the mobile node's reported link capabilities -- without waiting for the possible streaming protocol feedback mechanism to discover the increased or decreased bandwidth of the link. There are several scalable-coding algorithms such as SVC (Scalable Video Coding), H.264 Scalable Extension, BSAC (Bit Sliced Arithmetic Coding), etc. to support a flexible control in terms of audio as well as video. There are, however, some limitations to adjust its ongoing traffic volumes from the sender because of lack of dynamic signaling from the receiver while changing its link characteristics. 4.4 Traffic Shaping In the case that some or all traffic destined to the mobile node goes through a mobility anchor node (e.g., the home agent in Mobile IPv6 bi-directional tunneling mode or previous access router in Mobile IP fast handover protocols), it would be useful for the mobility anchor node to shape the traffic towards the mobile node according to the current link characteristic information provided by the mobile node. For example, if the mobile node has announced its current link capacity as 64kbps, the mobility anchor node has no point forwarding more traffic than the announced data rate to overflow the mobile node's access link. Instead, the mobility anchor node may limit the forwarding rate itself or notify the remote peers (e.g. the correspondent nodes) to reduce their traffic by some means. 4.5 Network-Initiated Handover In some future circumstances, remote network nodes, such as the Mobile IP home agent, may wish to suggest the mobile node to handover to another access network possibly based on the required service quality or certain administrative policies. With link characteristics information delivery mechanism, the remote nodes would have more knowledge to be used for such decision makings. 4.6 Signaling Support Currently there is no existing standardized or IP mobility solution independent mechanism to signal link characteristic information from the mobile node to the relevant remote network nodes. The relevant remote network nodes include mobility management nodes (e.g. Mobile IP home agent), correspondent nodes, and any other network nodes that may consider link characteristic information useful. Korhonen, et al. Expires December 11, 2006 [Page 8] Internet-Draft Link Characteristic Information June 2006 4.7 Link Information Facility To deliver link characteristic information, the mobile node has to get its access link characteristics dynamically. IEEE 802.21 is working for the MIHS (Media Independent Handover Services) composed of MIES (Media Independent Event Service), MICS (Media Independent Command Service) and MIIS (Media Independent Information Service). Both MIES and MICS are for the local stack operations. MIES provides event classification, event filtering and event reporting corresponding to dynamic changes in link characteristics, link status, and link quality. MICS enables the mobile node to manage and control link behavior relevant to handovers and mobility. In addition, implications of link indications are well described by [I-D.iab-link-indications]. Consequently, the link information is not vague and trivial facilities in IETF. How the mobile node acquires its link characteristics dynamically and accurately is beyond the scope of the link characteristic information delivery. Even if the link information is delivered end-to-end, the mobile node retrieving and sending the information cannot usually have more than a good guess of the actual end-to-end path characteristics. However, if the mobile node knows that the local link characteristics have changed by some magnitude, it can inform the other end to trigger the upper layer congestion control mechanisms to determine the effective end-to-end path characteristics. Similarly the mobile node may base some of its path characteristic information reasoning on the known bounds of the local link. For example if the local link is known to have 600ms roundtrip time and maximum bandwidth of 48kbps then the end-to-end path characteristics cannot be better. Furthermore, some initial measurement results on the end-to-end path can, for example, be gathered by monitoring possible mobility related signaling that takes place between the end hosts. 4.8 Classification of Explicit Notification Mechanisms Based on the past work on explicit notification and communication mechanisms, the following types of signaling between the end hosts and the network can be identified. Signaling can be separated into in-band and out-of-band mechanisms, based on whether the information is piggy-backed along with the transport protocol traffic, or whether the signaling is done by means of separate control packets, respectively. Benefit of using in-band signaling is that the signaling can be better assumed to take the same network path as the protocol data. Out-of-band mechanisms could take a different path due to different policy actions: An IPsec policy might not aggregate the signaling protocol to same security association as the data protocol, or a Korhonen, et al. Expires December 11, 2006 [Page 9] Internet-Draft Link Characteristic Information June 2006 policy-based routing system could select a different path for the out-of-band signaling than for the protocol data. Sometimes a packet with unrecognized content can cause the whole IP packet to be dropped in the network due to NAT or firewall policy, or because of defective router. When the message is transferred in-band, the loss notification usually comes naturally with the protocol's own acknowledgment mechanisms. For an out-of-band mechanism there might not be any direct mechanisms to inform about the loss. Out-of-band messages are also generally more susceptible for security problems caused by a third party generating malicious messages. The drawback of an in-band mechanism is that a loss due to additional content in the IP packet disturbs also the data transfer. In the following we discuss and evaluate various in-band and out-of- band signaling mechanisms that could potentially be used to deliver link characteristic information messages. o In-band message processed by end hosts -- When a message is attached to the transport protocol header, only the communication end hosts can be assumed to see the message. Also IPv6 has extension headers that are only processed by the end hosts. The routers along the network path are not typically capable of processing this kind of message, and if the packet is encrypted with IPsec [RFC2401], it is impossible by other nodes than the end hosts to read the message. The benefit of using transport header is that it can be expected that the legacy routers and different flavour of network middle boxes are not likely to take unexpected actions on the packet, such as dropping a packet with unknown option. An example of this kind of notification type is LMDR [I-D.swami-tcp-lmdr] that uses a TCP option to allow a mobile end host to notify the other end that it has moved. o In-band message processed by some routers -- If a message uses some of the reserved bits in the IP header, or is an IP hop-by-hop option, routers along the network path are able to process it and take appropriate actions. There can be two types of messages: those that are only read by a router, and those that can also be altered by the router. The options that are to be altered by the router should not be covered by IPsec [RFC2402]. In case of IPv4 this means that such an option should be explicitly marked as a mutable field for IPsec. An IPv6 option includes a bit that tells IPsec whether the option is mutable or non-mutable. IPsec does not cover the reserved bits in the IP header, either. Problem with the use of IP options is that as of today, network is known to drop the majority of packets with unknown IP options. Some explicit notifications are such that they can be of benefit even if a single router along the network path supports them. Explicit Congestion Notification [RFC3168] is one such mechanism. Korhonen, et al. Expires December 11, 2006 [Page 10] Internet-Draft Link Characteristic Information June 2006 o In-band message processed by all routers -- Some message types need to be processed by all routers in order to have effect. For example Quick-Start [I-D.ietf-tsvwg-quickstart] is one such mechanism. This is a hard requirement for any mechanism to be used in the Internet, and this kind of schemes are likely to remain in limited controlled portions of the network. These messages would also utilize the reserved bits in the IP header or IP options, with the same challenges as listed above. In addition, usually the sender must be able to verify that all routers have processed the message. One way to do this is by the means of a separate TTL field in the message that is compared to the IPv4 TTL or IPv6 hop count. If the two fields do not give matching information about the number of hops on the connection path, it can be concluded that there were routers that did not process the notification message. IP tunnels are also a considerable challenge to this kind of message, as they can hide the inner IP header with the in-band message from the routers. Sometimes the TTL field comparison does not reveal the presence of such tunnels on the path. o Out-of-band message processed by end hosts -- Sending ICMP messages from the receiver to the sender of packet has been a traditional way of reporting an error condition or other information about the data transfer [RFC0792][RFC2463]. Usually the transport header, or a part of it, is included in the message to help the receiver of the ICMP message to identify the transport connection the ICMP message concerns, and to conduct some primitive security screening. o Out-of-band message processed by routers -- Resource Reservation Protocol (RSVP) [RFC2205] uses a specific protocol type for QoS signaling between the sender and the receiver. RSVP requires that every router processes the messages, so it includes a similar kind of TTL-based hop tracking mechanism as Quick-Start does. In order to have out-of-band messages processed at routers, they need to be set to monitor the given protocol type inside the IP packets, or the IP packets need to use an router alert option to trigger further processing at the router. As with the in-band messages, IP tunnels and layer 2 switching system may prevent the signaling from working, or cause the signaling to work defectively. An out- of-band message could also be sent from one of the router along the network path, of which some of the ICMP error messages are a common example. Taking strong actions based on such signaling is not generally encouraged, though, because there would be many security issues in the validity and authenticity of such messages. To summarize, when designing a new signaling mechanism, a number of Korhonen, et al. Expires December 11, 2006 [Page 11] Internet-Draft Link Characteristic Information June 2006 issues should be considered based on the experiences from past proposals. To mention two of the important issues, it should be established whether some or all nodes along the path are required to process the message. For example, short-cutting the usual congestion or rate control mechanisms to get an increased sending rate requires a permission from each node along the network path. Second, it should be evaluated whether it is feasible to embed the signaling into the protocol data traffic, or whether a separate signaling flow is more appropriate, either as embedded to some existing signaling such as Mobile IP binding updates, or using an entirely new protocol. It is also possible that a combination of different mechanisms is used: for example, a mobile host could use an end-to-end method to tell the corresponding node about change in its status. In response, corresponding node could trigger a hop-by-hop QoS request in the changed environment. 5. Design Considerations 5.1 Requirements This section lists the general requirements for a link or sub-path characteristic information delivery mechanism design. The link characteristic information delivery solution MUST fulfill all the 'MUST and MUST NOT requirements' listed below: R1 Mobility solution independent -- Link characteristic information encoding and encapsulation MUST NOT be specific to a certain IP mobility solution (such as Mobile IP or HIP [RFC4423]). R2 Link characteristic information delivery SHOULD be applicable to existing mobility mechanisms (e.g., MIP, SIP, etc.), as well as to transport-layer multi-homing mechanisms such as SCTP [RFC2960] R3 Transport protocol independent -- The delivery of the link characteristic information MUST support multiple transport solutions and protocols. R4 Link technology independent -- The transport of link characteristic information MUST NOT be dependant on some particular link technology and link technology specific way of carrying information. R5 Lightweight delivery mechanism MUST be designed to avoid significantly increasing the amount of signaling traffic load, especially over wireless links. Korhonen, et al. Expires December 11, 2006 [Page 12] Internet-Draft Link Characteristic Information June 2006 R6 Applicable when the mobile node is either multi-homed or not -- In the multi-homed case, multiple interfaces of the mobile node may be activated to send and receive traffic. The solution MUST be able to handle link characteristic information for each link separately. The solution SHOULD also support combining the knowledge of all its available access links. R7 Applicable when the remote peers are also mobiles -- In this case the peers of both sides may support link characteristics information delivery, and the solution MUST be able to handle the "double jump" situations. R8 Applicable when the mobile node is communicating with multiple nodes over a single link -- The mobile node SHOULD be able to support an algorithm for the link capacity allocation and notify each node of its share. R9 Link characteristic information encapsulation format MUST be applicable to any existing and future link technology -- This requirement basically means that the actual contents and encapsulation format of link characteristic information MUST be extendable to new link types and new link characteristics data. R10 Link characteristic information delivery solution MUST NOT introduce new security vulnerabilities to the environment it is applied to. R11 Link characteristic information MUST support middlebox traversal. R12 The mobile node SHOULD be able to delegate its link characteristic information delivery to other mobility management node and undo the delegation when applicable and desired. R13 Link Characteristic Information SHOULD be exchanged between the mobile and remote node prior the handover, if just possible. This would allow remote node to react proactively and utilize the link characteristic information immediately when the handover takes place. R14 Link Characteristic Information SHOULD follow the congestion control principles as described in [RFC2914]. 5.2 Out of Scope Issues This section lists the issues that are considered as strictly out of scope of this problem statement and requirements document. Korhonen, et al. Expires December 11, 2006 [Page 13] Internet-Draft Link Characteristic Information June 2006 o Placing any requirements on the cross layer communications about link characteristic information. o Unidirectional links. o Non-IP-capable links. o Defining a new mobility framework. o Defining how link characteristic information delivery initiator (usually the mobile node) gathers its access link characteristic information. o Defining how link characteristic information delivery responder (the relevant remote network nodes) actually make use of link characteristic information. For example the remote peer may use link characteristic information to optimize the transport layer protocols by some specific algorithm particularly tied to the transport layer protocols in question. o Defining link capacity assignment algorithm when multiple communicating nodes are present on one interface of the mobile node. The assignment algorithms are left for the specific applications and protocols that actually utilize link characteristic information. 6. IANA considerations This particular document does not define any new name spaces to be managed by IANA. This document does not either reserve any new numbers or names under any existing name space managed by IANA. 7. Security Considerations This document provides a problem statement and requirements for the link characteristic information delivery when deployed used along with IP mobility management. The link characteristic information delivery signaling SHOULD be secured. Intermediating network nodes between the link characteristic information sender and the receiver MUST NOT be able to modify the contents of the link characteristic information delivery messages. The strength of the applied security mechanism for the link characteristic information delivery MUST NOT weaken the existing security solution on the environment where the link characteristic information delivery is applied to. Potentially, malicious hosts may misuse the link characteristic information delivery mechanism(s) to deliver erroneous link characteristic information to the receiving hosts. However, a Korhonen, et al. Expires December 11, 2006 [Page 14] Internet-Draft Link Characteristic Information June 2006 malicious hosts who have the capability of fabricating and delivering valid looking link characteristic information messages with erroneous content are supposed to be easier to launch more serious attacks using other mechanisms. 8. Acknowledgments The authors would like to thank Rajeev Koodli and Koshiro Mitsuya for their valuable comments and suggestions. The authors would also like to thank Markku Kojo and Hannes Tschofenig for their detailed comments, corrections and text contributions. 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. 9.2 Informative References [I-D.iab-link-indications] Aboba, B., "Architectural Implications of Link Indications", draft-iab-link-indications-04 (work in progress), December 2005. [I-D.ietf-tsvwg-quickstart] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", draft-ietf-tsvwg-quickstart-03 (work in progress), October 2006. [I-D.swami-tcp-lmdr] Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility Detection and Response (LMDR) Algorithm for TCP", draft-swami-tcp-lmdr-07 (work in progress), February 2006. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Korhonen, et al. Expires December 11, 2006 [Page 15] Internet-Draft Link Characteristic Information June 2006 Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. Korhonen, et al. Expires December 11, 2006 [Page 16] Internet-Draft Link Characteristic Information June 2006 Authors' Addresses Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FI-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Soohong Daniel Park Mobile Convergence Laboratory, SAMSUNG Electronics. 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Ji Zhang Communications Research Group, University of York. Heslington York YO10 5DD United Kingdom Phone: +44 1904 432310 Email: jz105@ohm.york.ac.uk Cheulju Hwang Mobile Convergence Laboratory, SAMSUNG Electronics. 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 Email: cheolju.hwang@samsung.com Korhonen, et al. Expires December 11, 2006 [Page 17] Internet-Draft Link Characteristic Information June 2006 Pasi Sarolahti Nokia Research Center P.O.Box 407 Helsinki FI-00045 FINLAND Phone: +358 50 4876607 Email: pasi.sarolahti@iki.fi Korhonen, et al. Expires December 11, 2006 [Page 18] Internet-Draft Link Characteristic Information June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Korhonen, et al. Expires December 11, 2006 [Page 19] Internet-Draft Link Characteristic Information June 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Korhonen, et al. Expires December 11, 2006 [Page 20]