Network Working Group J. Korhonen Internet-Draft TeliaSonera Expires: March 5, 2006 S. Park SAMSUNG Electronics J. Zhang University of York September 2005 Link Characteristic Information for IP Mobility Problem Statement draft-korhonen-mobopts-link-characteristics-ps-00.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 March 5, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document discusses the problems related to the link characteristic information delivery from the mobile node to other relevant network nodes. The purpose of this document is to set the scope and goals for possible future work on generic link characteristic information delivery for optimizing IP mobility Korhonen, et al. Expires March 5, 2006 [Page 1] Internet-Draft Link Characteristic Information September 2005 performance. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background and Motivations . . . . . . . . . . . . . . . . . . 5 3.1 Multimode Wireless Terminals . . . . . . . . . . . . . . . 5 3.2 Heterogeneous Networks and Terminal Mobility . . . . . . . 5 3.3 Adaptive Application and Services . . . . . . . . . . . . 6 3.4 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . 6 3.5 Network-Initiated Handover . . . . . . . . . . . . . . . . 6 3.6 Signaling Support . . . . . . . . . . . . . . . . . . . . 7 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 4.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Scenario 1 - peer to mobility anchor node link characteristic delivery . . . . . . . . . . . . . . . . . 9 5.2 Scenario 2 - peer to peer link characteristic delivery . . 9 5.3 Scenario 3 - multiple-destination link characteristic delivery . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Scenario 4 - link characteristic delivery delegation . . . 9 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Korhonen, et al. Expires March 5, 2006 [Page 2] Internet-Draft Link Characteristic Information September 2005 1. Introduction Recently more and more mobile nodes are equipped with multiple interfaces for different L2 technologies. These mobile nodes may be reachable through different links at the same time or use each interface alternately depending on the network environment. In the latter case, transitions between heterogeneous links (vertical handovers) occur. Existing IP mobility solutions, such as Mobile IP [RFC3344] [RFC3775], HIP [I-D.ietf-hip-arch] and MOBIKE [I-D.ietf- mobike-design], do not provide a mechanism to indicate which type of link the mobile node is currently attached to. Therefore, sudden changes of access link characteristics caused by vertical handovers are usually not quickly observed by higher layer applications until a certain mechanism (e.g. congestion control or error recovery mechanism) is invoked some time later when it senses a misuse of the network capacity. This can cause undesirable disruptions or performance degradation to the ongoing connections. For example, when the 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 send their traffics to the mobile node as if the 802.11b bandwidth is still available. Thus, the ratio of packet loss will eventually increase. In some cases, the mobile node's available bandwidth may also vary considerably on handovers between the same type of links (horizontal handovers) due to the different traffic loads on the old and the new link. Moreover, even the mobile node stays on the same link, the available bandwidth may change significantly due to the variations of the traffic load on current link. Both of these situations may lead to similar adverse effects as those on vertical handovers. This document discusses the problems related to the link characteristic information delivery from the mobile node to other relevant network nodes (i.e. correspondent nodes, Mobile IP home agent and any other network nodes that may consider the link characteristic information useful). The purpose of this document is to set the scope and goals for possible future work on generic link characteristic information delivery for optimizing IP mobility performance. 1.1 Overview of the Problem 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 link characteristics with the relevant remote network nodes. With the emergence of multimode mobile terminals and the roaming capability between Korhonen, et al. Expires March 5, 2006 [Page 3] Internet-Draft Link Characteristic Information September 2005 different access technologies, there is a need of sharing accurate link characteristic information with the remote communicating nodes, due to the fact that wireless access links are most likely the bottleneck of the communication path. This is expected to reduce or even avoid possible complications to the IP transport and service quality when the access link characteristics change considerably. Currently there is no standardized protocol for such link characteristic information delivery. Therefore, some new signaling mechanism is needed. 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. 1.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]. 2. Assumptions This document has a few fundamental assumptions concerning the general networking environment and certain capabilities supported by the mobile node in the case that the link characteristics delivery functionality is to be deployed. These assumptions are listed as follows: o There exists a security relationship between the mobile node and the remote nodes that participate in the link characteristic information communications. This security relationship has been set up before the mobile node and the remote nodes can make use of the link characteristic information. o Link characteristic information messages are piggybacked on top of mobility protocol or signaling protocol that is used between the mobile node and the remote nodes. o All mobile nodes, correspondent nodes, mobility management nodes and other network entities are not expected to understand or support link characteristic information notification if they do not need this particular feature. Legacy nodes and network entities also fall into this category. Korhonen, et al. Expires March 5, 2006 [Page 4] Internet-Draft Link Characteristic Information September 2005 o The mobile node has the required capabilities to gather relevant link information on those links it is connected to or is about to connect, or name and identify these links uniquely. This means the link characteristic information may not only be tied to those links the mobile node is currently actively using. 3. Background and Motivations In this section we discuss the background and motivations for developing a link characteristic information delivery mechanism. 3.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 and Bluetooth radios. It is possible that more than one of these radios are activated to attach to network alternatively or simultaneously. Also, the idea of always on-line via wireless is not far fetched anymore. 3.2 Heterogeneous Networks and Terminal Mobility Due to the impressive 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 seamless handover between these different access technologies in order to maintain connections and achieve best QoS while moving. However, the characteristics and capabilities of these different access networks differ considerably for example in available bandwidth, roundtrip times, 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 on the link performance. Link characteristics may also change considerably when the mobile node handovers between the same type of link, due to the different traffic loads on the old and the new link. Furthermore, even when the mobile node connects to the same link and no handover occurs, link performance can change abruptly (for example when radio conditions change) especially in some cellular networks. However, these are at least initially unknown to upper layer mechanisms due to the current IP mobility management protocols. Some upper layer transport protocols and services can adapt to the changed connection condition, however reactively until the network capacity Korhonen, et al. Expires March 5, 2006 [Page 5] Internet-Draft Link Characteristic Information September 2005 misuse (over-utilization or under-utilization) event has occurred and been detected some time later. Thus those upper layer protocols, applications and services may experience unnecessarily unoptimal performance during this period. Unfortunately there is currently no way of signaling this kind of information from the mobile node to the remote network nodes in communications. 3.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 were not designed to handle the situation discussed in this document, so that they are not efficient in the scenarios in question. One possible example of an adaptive application benefiting from the 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 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. 3.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. 3.5 Network-Initiated Handover In some future circumstances, remote network nodes, such as the Korhonen, et al. Expires March 5, 2006 [Page 6] Internet-Draft Link Characteristic Information September 2005 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 a link characteristics information delivery mechanism, the remote nodes would have more knowledge to be used for such decision makings. 3.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 the link characteristic information useful. 4. Design Considerations 4.1 Goals This section lists the general goals for the link characteristic information delivery mechanism design. The link characteristic information delivery solution MUST fulfill all the goals listed below: G1 Mobility solution independent -- The link characteristic information delivery solution MUST not be tied to a specific IP mobility solution such as Mobile IP or HIP. G2 Transport protocol independent -- The transport of the link characteristic information MUST not be dependant on any particular transport protocol. G3 Link technology independent -- The transport of the link characteristic information MUST not be dependant on some particular link technology and link technology specific way of carrying information. G4 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 the link characteristic information for each link separately. The solution SHOULD also support combining the knowledge of all its available access links. Korhonen, et al. Expires March 5, 2006 [Page 7] Internet-Draft Link Characteristic Information September 2005 G5 Applicable when the remote peers are also mobiles -- In this case the peers of both sides may support the link characteristics information delivery, and the solution MUST be able to handle the "double jump" situations. G6 Applicable when multiple communicating nodes are present on one interface of the mobile node -- The mobile node SHOULD support an algorithm to assign the link capacity and notify the share to each communicating node separately. G7 The link characteristic information encapsulation format MUST be applicable to any existing and future link technology -- This goal basically means that the actual contents and encapsulation format of the link characteristic information MUST be extendable to new link types and new link characteristics data. G8 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. 4.2 Non-Goals This section lists the issues that are considered as strictly out of scope of this problem statement document. o Defining a new transport protocol or mechanism to carry the link characteristic information. o Defining any new security mechanisms or requirements. o Placing any requirements on the cross layer communications about the link characteristic information. o Unidirectional links. o Non-IP-capable links. o Defining how the link characteristic information delivery initiator (usually the mobile node) gathers its access link characteristic information. o Defining how the link characteristic information delivery responder (the relevant remote network nodes) actually make use of the link characteristic information. For example the remote peer may use the link characteristic information to optimize the transport layer protocols by some specific algorithm particularly tied to the transport layer protocols in question. Korhonen, et al. Expires March 5, 2006 [Page 8] Internet-Draft Link Characteristic Information September 2005 o Defining the 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 the link characteristic information. 5. Usage Scenarios This section discusses some possible usage scenarios that could benefit from the link characteristics information delivery in more detail. 5.1 Scenario 1 - peer to mobility anchor node link characteristic delivery In this scenario the mobile node delivers the link characteristics information only to the mobility anchor node. This scenario is valid for example for Mobile IP without route optimization. Correspondent nodes are completely left outside of the link characteristic information delivery. 5.2 Scenario 2 - peer to peer link characteristic delivery In this scenario the mobile node delivers link characteristic information to one or more correspondent nodes. The protocol used to encapsulate and deliver the link characteristic information MUST allow communicating directly with correspondent nodes. This scenario applies for example to HIP or route optimized Mobile IPv6 where both peers could be mobile and are using peer to peer communications. In this scenario it is possible that the mobile node acts as the role of both the sender and receiver of the link characteristic information. 5.3 Scenario 3 - multiple-destination link characteristic delivery This scenario is the generalization of scenarios 1 and 2. The mobile node delivers link characteristic information to the mobility anchor node as well as some correspondent nodes. This scenario applies for example to the case that in Mobile IPv6 the mobile node communicates with some of the correspondent nodes using the route optimization mode while the others using the bi-directional tunneling mode. 5.4 Scenario 4 - link characteristic delivery delegation In this scenario the mobile node purposely delegates its link characteristic information delivery to some other network node. The node taking care of the delegated link characteristic information delivery MUST be able to capture all traffic coming from and going to the mobile node. For example this scenario is applicable for access Korhonen, et al. Expires March 5, 2006 [Page 9] Internet-Draft Link Characteristic Information September 2005 systems with centralized radio resource management, where the management node monitors the connected mobile nodes and their access link resources continuously. The link characteristic information delivery delegation can allow reducing the signaling overhead on links where the link conditions vary frequently. 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 Potentially, the model proposed in this document may be misused by an attacker to indicate fabricated link characteristic information to the mobility management nodes or correspondent nodes. However, the link characteristic information is always intended to be carried as part of the existing mobility-related signaling. In this case the link characteristic information rely on the used transport mechanism to guarantee the security for the message delivery. The used mechanism for the link characteristic information transport MUST provide the data origin authentication, integrity and replay protection, and SHOULD provide confidentiality protection when there is a need. Attackers who have the capability of fabricating valid transport messages of the link characteristic information are able to launch more serious attacks than those potentially caused by the link characteristic delivery model. Therefore, it is believed that the deployment of the link characteristic information delivery does not introduce new security vulnerabilities to the mobility solution of choice. 8. Acknowledgments The authors would like to thank Rajeev Koodli and Koshiro Mitsuya for their valuable comments and suggestions. 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. Korhonen, et al. Expires March 5, 2006 [Page 10] Internet-Draft Link Characteristic Information September 2005 9.2 Informative References [I-D.ietf-hip-arch] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. [I-D.ietf-mobike-design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE Protocol", draft-ietf-mobike-design-03 (work in progress), July 2005. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. Authors' Addresses Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Korhonen, et al. Expires March 5, 2006 [Page 11] Internet-Draft Link Characteristic Information September 2005 Ji Zhang Communications Research Group, University of York. Heslington York YO10 5DD United Kingdom Phone: +44 1904 432310 Email: jz105@ohm.york.ac.uk Korhonen, et al. Expires March 5, 2006 [Page 12] Internet-Draft Link Characteristic Information September 2005 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 (2005). 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 March 5, 2006 [Page 13] Internet-Draft Link Characteristic Information September 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Korhonen, et al. Expires March 5, 2006 [Page 14]