Network Working Group S. Park Internet-Draft M. Lee Expires: December 10, 2005 SAMSUNG Electronics J. Korhonen TeliaSonera J. Zhang University of York June 8, 2005 Link Characteristics Information for Mobile IP draft-daniel-mip-link-characteristic-02.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 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document introduces a model for link characteristic information delivery from the mobile node to the home agent and correspondent Park, et al. Expires December 10, 2005 [Page 1] Internet-Draft Link Characteristics Information June 2005 node(s). This model allows the home agent and correspondent node(s) to know the characteristics of the link the mobile node is currently attached to. Based on this information, the home agent and correspondent node(s) may shape ongoing traffics 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 . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Appendix A (Informative) - Option Usage Examples . . . . . . . 7 8.1 Vertical Handover from a GPRS Link to an 802.11b Link . . 7 8.2 Vertical Handover from an 802.11b Link to a GPRS Link . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 11 Park, et al. Expires December 10, 2005 [Page 2] Internet-Draft Link Characteristics Information June 2005 1. Introduction Mobile IP [RFC3344], [RFC3775] 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 correspondent node(s) (optionally) with the assistance of the mobile node's notifications of its current location. Since more and more mobile nodes are equipped with multiple interfaces for different L2 techonologies, they 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) is invoked some time later when it senses a misuse of the network capacity. This can cause undesirable disruptions to the ongoing connections. For example, when the mobile node performs a handover from an IEEE 802.11b Wireless LAN link (high bandwidth link) to a CDMA link (low bandwidth link), the home agent and correspondent node(s) 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 be increased. 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 traffics to the mobile node according to the mobile node's current access link characteristics. This model can be applicable for both Mobile IPv6 [RFC3775] and Mobile IPv4 [RFC3344]. 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 information to be extended if required) to the home agent and correspondent node(s). This option SHOULD be included in the Binding Update message on vertical handovers or when the Park, et al. Expires December 10, 2005 [Page 3] Internet-Draft Link Characteristics Information June 2005 mobile node senses a significant link characteristic change by some means 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 [RFC2119]. 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, current estimated available bandwidth of the link, and possibly other link information to be defined. 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. 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Park, et al. Expires December 10, 2005 [Page 4] Internet-Draft Link Characteristics Information June 2005 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-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" info-label = ALPHA / DIGIT The "ALPHA" and "DIGIT" rules are defined in [RFC2234]. 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 Park, et al. Expires December 10, 2005 [Page 5] Internet-Draft Link Characteristics Information June 2005 binding cache for each mobility binding. 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 traffics to the mobile node. 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) MAY implement an interface for communications between IP layer and upper layer mechanisms. 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 the correspondent node does not receive Binding Update messages and traffics 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, but the available bandwidth specified in the Link Characteristic Information Option is 1Mbps, and then the home agent or correspondent node receiving this option SHOULD reduce its forwarding traffic amount. 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 traffics. 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 correspondent Binding Update message. The total capacity (i.e. bandwidth as currently defined) specified in all concurrent Link Characteristic Information Options SHOULD not exceed Park, et al. Expires December 10, 2005 [Page 6] Internet-Draft Link Characteristics Information June 2005 the maximum capacity available to the mobile node on the current access link. However, 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. 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 [RFC3776] or the binding management key (Kbm) [RFC3775] 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. 6. IANA Considerations IANA should record a value for the Link Characteristic Option. Also, IANA needs to allocate a new namespace for the subtype field. 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 advantage of the reported increased bandwidth. Park, et al. Expires December 10, 2005 [Page 7] Internet-Draft Link Characteristics Information June 2005 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) | |<----------------------------------------------| | | 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. 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) | |<----------------------------------------------| | | Park, et al. Expires December 10, 2005 [Page 8] Internet-Draft Link Characteristics Information June 2005 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. 9.2 Informative References [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [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 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 Park, et al. Expires December 10, 2005 [Page 9] Internet-Draft Link Characteristics Information June 2005 Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.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 Park, et al. Expires December 10, 2005 [Page 10] Internet-Draft Link Characteristics Information June 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Park, et al. Expires December 10, 2005 [Page 11]