MIP6 Working Group Soohong Daniel Park Internet-Draft M. Lee Intended status: Best Current Samsung Electronics Practice J. Korhonen Expires: August 1, 2007 TeliaSonera J. Zhang Cambridge Silicon Radio January 28, 2007 Link Characteristics Information for Mobile IP draft-daniel-mip-link-characteristic-03.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 August 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document introduces a model for link characteristic information delivery from the mobile node to the home agent and correspondent node(s). This model allows the home agent and correspondent node(s) to know the characteristics of the link the mobile node is currently Park, et al. Expires August 1, 2007 [Page 1] Internet-Draft Link Characteristics Information January 2007 attached to. Based on this information, the home agent and correspondent node(s) may shape ongoing traffic according to the current available link capacity (e.g. bandwidth) to the mobile node. This model can be applicable for Mobile IPv4 as well as Mobile IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Link Characteristic Information Option for Mobile IPv6 . . . . 4 4. Operational Considerations . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Appendix A (Informative) - Option Usage Examples . . . . . . . 8 8.1. Vertical Handover from a GPRS Link to an 802.11b Link . . 8 8.2. Vertical Handover from an 802.11b Link to a GPRS Link . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Park, et al. Expires August 1, 2007 [Page 2] Internet-Draft Link Characteristics Information January 2007 1. Introduction Mobile IP [2], [3] allows a mobile node to maintain its existing connections while changing its access link. This is achieved through the mechnism of mobility binding management at the home agent and optionally correspondent node(s) with the assistance of the mobile node's notifications of its current location. 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. Mobile IP, however, does not provide a mechanism to indicate which type of link the mobile node is 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 traffic 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 vertical handovers. This document introduces a new model for link characteristic information delivery from the mobile node to the home agent and correspondent node(s). The purpose of this model is to let the home agent and correspondent node(s) properly shape their traffic to the mobile node according to the mobile node's current access link characteristics. This model can be applicable for both Mobile IPv6 [3] and Mobile IPv4 [2]. However, to illustrate this model concisely, only Mobile IPv6 is considered in this document. A new mobility option called Link Characteristic Information Option is defined to carry link characteristics (e.g., current link bandwidth, link type, and other relevant information to be extended) to the home agent and correspondent node(s). This option SHOULD be included in Park, et al. Expires August 1, 2007 [Page 3] Internet-Draft Link Characteristics Information January 2007 the Binding Update message on vertical handovers or when the mobile node senses a significant link characteristic change. The method used by the mobile node to obtain the current link characteristic information is implementation dependent (e.g. enhancing the wireless access device driver functions or using the 802.21 utility), and is therefore out of the scope of this document. For Mobile IPv4, the option can be defined following the Type-Length-Value extension format, and can be carried by the Registration Request message. 2. Requirements 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 [1]. 3. Link Characteristic Information Option for Mobile IPv6 The Link Characteristic Information Option is a new mobility option that MAY be carried in the Mobile IPv6 Binding Update message. Various link types and characteristic information (e.g. bandwidth) can be delivered to the home agent and correspondent node(s) from the mobile node. The subtype field in the option defines the specific link type. Other link information such as the current estimated available bandwidth is encoded in the Link Characteristic Information field. This option SHOULD be carried in the Binding Update message on vertical handovers or when the mobile node senses a significant link characteristic change by some means out of the scope of this document. The trigger of sending the option by the mobile node is an implementation issue. For example, a bandwidth change threshold could be defined. Only when the available bandwidth change exceeds the threshold, should the mobile node initiate a Link Characteristic Information option to be delivered. Further study is required to determine the optimal threshold for different link types and ongoing applications. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Characteristic Information... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Park, et al. Expires August 1, 2007 [Page 4] Internet-Draft Link Characteristics Information January 2007 Link Characteristic Information Option for Mobile IPv6 o Option Type: 8-bit identifier of the type of the mobility option. To be defined by IANA. o Option Length: 8-bit unsigned integer, representing the length of the Link Characteristic Information Option in octets, excluding the Option Type and Option Length fields. o Subtype: 8-bit identifier (as shown in the following table), indicating the type of the link the mobile node currently accesses. Subtype Link Type ---------------------------------------------- 0 LAN (802.3) 1 WLAN (802.11b) 2 WLAN (802.11a) 3 WLAN (802.11g) 4 WLAN (802.11n) 5-15 Reserved for (W)LAN Extensions 16 CDMA 17 GPRS 18 UMTS 19-31 Reserved for Cellular Networks 32-47 802.15 Family Networks 48-63 802.16 Family Networks 64 Bluetooth 65 Virtual (the physical link type is irrelevant) 66-255 Reserved ---------------------------------------------- o Reserved: MUST be set to zero when sending this option and ignored when receiving this option. o Link Characteristic Information: A variable length field that contains the current available bandwidth information and possibly other to-be-defined link information for a specific link type as specified in the subtype field. The ABNF below describes how the Link Characteristic Information field MUST be constructed: link-info = link-info-data link-info =/ link-info-data "," 1*info-label link-info =/ 1*info-label "," link-info-data link-info-data = "bw=" 1*DIGIT bandwidth = "kbps" / "Mbps" / "kB" / "Gbps" Park, et al. Expires August 1, 2007 [Page 5] Internet-Draft Link Characteristics Information January 2007 info-label = ALPHA / DIGIT The "ALPHA" and "DIGIT" rules are defined in [4]. This option does not have any alignment requirements. 4. Operational Considerations The binding cache is a table maintained by the home agent and each correspondent node that contains the current mobility bindings for mobile nodes. To store link characteristic information at the home agent and correspondent node(s), one entry MUST be contained in the binding cache for each mobility binding. Similarly the mobile node MUST have one entry in every item in its binding update list to store the link characteristic information the mobile node has sent to other network nodes (i.e. home again, correspondent nodes). The home agent and correspondent node(s) MUST recognize the Link Characteristic Information Option in the Binding Update message in order for them to properly shape their traffic to the mobile node or dynamically adjust their services. Otherwise, this option is silently discarded by the home agent and correspondent node(s). Moreover, this option MUST be silently discarded if the Binding Update message fails to be authenticated. On receipt of a Binding Update message with the Link Characteristic Information Option, correspondent node(s) SHOULD control their traffic amount or pattern sent to the mobile node according to the link characteristics (i.e. available bandwidth as currently defined) specified in the option. To perform traffic controls, correspondent node(s) SHOULD implement an interface for communications between IP layer and upper layer mechanisms (e.g. TCP, media application codec, etc.). However, the specific control method is out of the scope of this document. On receipt of a Binding Update message with the Link Characteristic Information Option, the home agent SHOULD control its traffic amount or pattern sent to the mobile node according to the link characteristics. This is helpful when the mobile node is communicating with any of its correspondent node(s) in non-route- optimization mode (i.e. the bi-directional tunneling mode, in which case the correspondent node does not receive Binding Update messages and traffic go through the home agent). However, the specific control method is out of the scope of this document. For example, an ongoing connection is using a bandwidth of 10Mbps, while the available bandwidth specified in the Link Characteristic Park, et al. Expires August 1, 2007 [Page 6] Internet-Draft Link Characteristics Information January 2007 Information Option is 1Mbps. The home agent or correspondent node receiving this option SHOULD reduce its traffic forwarding rate. Link characteristic information SHOULD be provided by the mobile node in the Binding Update message on vertical handovers or when the mobile node senses a significant link characteristic change by some means out of the scope of this document, in order to guide the home agent and correspondent node(s) to shape their traffic. The trigger of sending the option by the mobile node is an implementation issue. In the case that the mobile node has multiple correspondent nodes, in order for the model defined in this document to work well, the mobile node SHOULD have a certain capacity (i.e. bandwidth as currently defined) assignment algorithm to determine the share for each of them, and specify it (the share) in the Link Characteristic Information Option in the corresponding Binding Update message. The total capacity (i.e. bandwidth as currently defined) specified in all concurrent Link Characteristic Information Options SHOULD not exceed the maximum capacity available to the mobile node on the current access link. The capacity assignment algorithm is out of the scope of this document. This document only defines the available bandwidth as link characteristic information. However, there is no restriction to add other available link information in the Link Characteristic Information Option if required. Furthermore, the Link Characteristic Information Option as such is also applicable when Mobile IPv6 is used in proxy mode [5]. In this particular case the source of the information is the local proxy node representing the mobile node. The use case could be the access network signaling the allowed capacity to the mobile node to the correspondent nodes along with the Mobile IP signaling. 5. Security Considerations Potentially, the model proposed in this document may be misused by an attacker to indicate fabricated available bandwidth information to the home agent or correspondent node(s). However, the Link Characteristic Information Option is carried by the Binding Update message, which are always supposed to be protected by IPsec [6] or the binding management key (Kbm) [3] established beforehand. Attackers who have the capability of fabricating a valid Binding Update message are able to launch more serious attacks than those potentially caused by this model. Therefore, it is believed that the use of the Link Characteristic Information Option does not bring new security vulnerabilities to Mobile IP. Park, et al. Expires August 1, 2007 [Page 7] Internet-Draft Link Characteristics Information January 2007 6. IANA Considerations A new Mobile IPv6 Mobility Option type is required for the following new mobility option described in section Section 3: Link Characteristic Information Option is set to TBD Also, IANA needs to allocate a new Link Characteristic Information Option (TBD) namespace for the subtype field described in section Section 3: Subtype Link Type ---------------------------------------------- 0 LAN (802.3) 1 WLAN (802.11b) 2 WLAN (802.11a) 3 WLAN (802.11g) 4 WLAN (802.11n) 5-15 Reserved for (W)LAN Extensions 16 CDMA 17 GPRS 18 UMTS 19-31 Reserved for Cellular Networks 32-47 802.15 Family Networks 48-63 802.16 Family Networks 64 Bluetooth 65 Virtual 66-255 Reserved 7. Acknowledgements The authors would like to acknowledge Rajeev Koodli, Bongkyo Moon, Pyungsoo Kim and Junghoon Jee for their useful comments. 8. Appendix A (Informative) - Option Usage Examples 8.1. Vertical Handover from a GPRS Link to an 802.11b Link The example below shows the link characteristic information notification when the mobile node performs a vertical handover from a 46kbps GPRS link to an 11Mbps 802.11b link. During the Binding Update procedure the mobile node deliveries its new access link bandwidth to the home agent (in bi-directional tunneling mode) or the correspondent node (in route optimization mode). After receiving the Binding Update message, the home agent or the correspondent node adjusts its traffic sending rate towards the mobile node to take Park, et al. Expires August 1, 2007 [Page 8] Internet-Draft Link Characteristics Information January 2007 advantage of the reported increased bandwidth. mobile node home agent / correspondent node | | attach to GPRS link | | data (with GPRS bandwidth) | |<----------------------------------------------| handover to 802.11b link | | Binding Update | |---------------------------------------------->| | (subtype: 802.11b; info: bandwidth=11Mbps) | | | | Binding Acknowledgement (if sent) | |<----------------------------------------------| | adjust traffic sending rate | data (with 802.11b bandwidth) | |<----------------------------------------------| | | Example 1 8.2. Vertical Handover from an 802.11b Link to a GPRS Link The following example shows the link characteristic information notification when the mobile node performs a vertical handover from an 11Mbps 802.11b link to a 46kbps GPRS link. During the Binding Update procedure the mobile node delieveries its new access link bandwidth to the home agent (in bi-directional tunneling mode) or the correspondent node (in route optimization mode). After receiving the Binding Update message the home agent or the correspondent node reduces its traffic sending rate towards the mobile node to match the reported decreased bandwidth. Park, et al. Expires August 1, 2007 [Page 9] Internet-Draft Link Characteristics Information January 2007 mobile node home agent / correspondent node | | attach to 802.11b link | | data (with 802.11b bandwidth) | |<----------------------------------------------| handover to GPRS link | | Binding Update | |---------------------------------------------->| | (subtype: GPRS; info: bandwidth=46kbps) | | | | Binding Acknowledgement (if sent) | |<----------------------------------------------| | adjust traffic sending rate | data (with GPRS bandwidth) | |<----------------------------------------------| | | Example 2 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [5] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-01 (work in progress), January 2007. [6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [7] Haley, B., "Mobility Header Home Agent Switch Message", draft-ietf-mip6-ha-switch-02 (work in progress), December 2006. Park, et al. Expires August 1, 2007 [Page 10] Internet-Draft Link Characteristics Information January 2007 Authors' Addresses 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 Minho Lee Mobile Platform Laboratory, SAMSUNG Electronics. 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 3697 Email: minho03.lee@samsung.com Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Ji Zhang Fix Mobile Convergence Solutions, Cambridge Silicon Radio Ltd. Cambridge Business Park, Cowley Road Cambridge CB4 0WZ United Kingdom Phone: +44 1223 692906 Email: ji.zhang@csr.com Park, et al. Expires August 1, 2007 [Page 11] Internet-Draft Link Characteristics Information January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Park, et al. Expires August 1, 2007 [Page 12]