Network Working Group S. Daniel Park Internet-Draft M. Lee Expires: October 3, 2005 SAMSUNG Electronics J. Korhonen TeliaSonera April 2005 Link Characteristics Information for Mobile IP draft-daniel-mip-link-characteristic-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 October 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document introduces a mechanism for link characteristic information and network information exchange from the mobile node to the home agent and the correspondent node. This model allows the home agent and the correspondent node to know the characteristics of Park, et al. Expires October 3, 2005 [Page 1] Internet-Draft Link Characteristics Information April 2005 the links the mobile node is attached to or could attach to. Based on this information the home agent and the correspondent node may shape ongoing traffic flows for the available bandwidth on the new link after the handover. This functionality also allows the home agent and the correspondent node to indicate preferred links or networks to where the mobile node should move to. 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 . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Appendix A (informative) - Option Usage . . . . . . . . . . . 7 8.1 Handover and bandwidth Link Information example . . . . . 7 8.2 Network initiated handover indication example . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 9.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Park, et al. Expires October 3, 2005 [Page 2] Internet-Draft Link Characteristics Information April 2005 1. Introduction Mobile IP [RFC3344], [RFC3775] allows an IP node to be mobile when changing its location and still maintain existing connections. When the mobile node changes its location, it might also change its link. After attaching to a new link, the mobile node sustains its connection with the previous node (called correspondent node) continuously via specific operation as binding update which sent by the mobile node that is away from home to update another node with its new address (care-of address). Mobile Nodes are more and more equipped with several interfaces of different L2 technologies. As such they may be reachable through multiple links at the same time or alternatively use each interface depending on the network environment. Mobile IP scheme, however, does not provide mechanism to indicate which link is attached to the mobile node or which links the mobile node could be able to attach to, but maintain its existing connection. It means the home agent or the correspondent node recognize that the mobile node is still attached to the same link. It can cause some trouble to communicate between them. For example, in some case (i.e.,vertical handover), if the mobile node is attached to the CDMA (low bandwidth link) from the 802.11b Wireless LAN (high bandwidth link), the mobile node needs to receive a traffic within its limited bandwidth not overwhelmed traffic from the correspondent node, however the correspondent node will send its traffic to the mobile node as if the 802.11b bandwidth is still guranteed. Ratio of packet loss will eventually be increased. Furthermore, the home agent or the correspondent node has no mechanism to indicate to the mobile node that it should perform a handover to a new link or network. The handover indication from the home agent or the correspondent node might not be based on the link quality or characteristics criteria but rather to an administrative or a general service policy criteria. This document introduces a new model for link characteristic and network information sharing. The information is sent by the mobile node to the home agent and to the correspondent node. The purpose of this model is to let the home agent and the correspondent node to know which link is being used and possibly are available for communication between them and the mobile node. A new option called Link Characteristic Information Option is defined in this document to provide link characteristics and network informations (e.g., current link bandwidth, link type, network name and other information will be expanded later if required) to the home agent and to the correspondent node while doing a binding update. This option is recommended to be included in the Binding Update Message as well as Binding Acknowledgement Message when attaching to a new link which is different from the previous link or the link (or network) conditions Park, et al. Expires October 3, 2005 [Page 3] Internet-Draft Link Characteristics Information April 2005 change. In wireless environment, all links are not able to support the same bandwidth to the mobile node after attaching to a new link. If the mobile node is currently attached to the 802.11b link and then performs a handover to a new 802.11b link, the available link bandwidth may still change considerably. So link characteristic and network information is applicable also for the same link type accordingly. To illustrate this model easily, Mobile IPv6 [RFC3775]is only described in this document, Mobile IPv4 [RFC3344] will be able to be defined following the Type-Length-Value format for Mobile IP Extension. 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 Mobile Node Link Characteristic Information Option is a new optional data field that is carried in the Mobile IPv6 defined messages which includes the mobility header (Binding Update and Binding Acknowledgement). Various type and information of link can be delivered to the home agent and the correspondent node from the mobile node. The subtype field in the option defined the specific link type, current estimated bandwidth of the link and optionally network name information. This option is recommendable to be carried in the Binding Update and Binding Acknowledgement message while performing a handover or when the link and network status changes. The subtype field in the option is used to describe the specific link type, link characteristics and network informations of a current link, and possibly other available links and networks the mobile node is aware of. There may be zero or more Link Characteristic Information options in a Binding Update message and at most one option in a Binding Acknowledgement message. Based on the information provided by the Mobile Node both the Home Agent and the Correspondent Node MAY indicate to the mobile node, in the acknowledgement message, that it should perform a handover to a new link or to a network. Park, et al. Expires October 3, 2005 [Page 4] Internet-Draft Link Characteristics Information April 2005 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 |S| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Characteristic Informations... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Option Type: To be defined by IANA o Option Length: 8-bit unsigned integer, representing the length in octets of the Subtype and Link Characteristic Information fields. o Subtype: Subtype field defines the link type of the mobile node included in the Link Characteristic Information field. 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 Extension 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 S(elected): The mobile node sets this bit to one for those links and networks it is currently attached to. The home agent or the correspondent node sets this bit to one for those links and networks they would like the mobile node to be attach to. o Link Characteristic Information: A variable length field containing available bandwidth and network identity information for a specific link type as defined in the subtype field. The network identity interpreation is dependant on link's Subtype. For example in case of 802.11 WLAN networks the network identity could be a network SSID or a BSSID. In case of GPRS or UMTS the network identity could be a PLMN-id [3GPP23003]. The ABNF below Park, et al. Expires October 3, 2005 [Page 5] Internet-Draft Link Characteristics Information April 2005 describes how the Link Characteristic Information field MUST be constructed: link-info = link-info-data link-info =/ link-info-data "," network-id link-info =/ link-info-data "," 1*OCTET link-info-data = "bw=" 1*DIGIT bandwidth bandwidth = "kbps" / "Mbps" / "kB" network-id = "nid=" network-id-list network-id-list = 1*base64 network-id-list =/ 1*base64 ";" network-id-list network-id-list =/ 1*base64 "," 1*OCTET base64 = ALPHA / DIGIT / "+" / "/" / "=" The "ALPHA", "OCTET" and "DIGIT" rules are defined in [RFC2234]. The network identity is always BASE64 [RFC1421] encoded. This option does not have any alignment requirements. 4. Operational Considerations The binding cache is a table maintained by each correspondent node and home agent that contains the current bindings for mobile nodes. To store link characteristic and network information on the home agent and the correspondent node, one entry SHOULD be contained in the binding cache. Also the home agent and the correspondent node MUST recognize this option. Otherwise, this option is silently discarded by the home agent and the correspondent node. Link characteristic and network information MUST be provided by the mobile node while attaching a new link via Binding Update message. It SHOULD be provided when the link characteristics change or the availability of links or networks changes. When the home agent or the correspondent node sends Binding Acknowledgement message, Link Characteristic Information Option which is copied from the Binding Update message MUST be included. However, the home agent or the correspondent node MAY modify the contents of the returned Characteristic Information Option. Once taking the available bandwidth of the mobile node, the home agent or the correspondent node SHOULD guarantee the bandwidth when forwarding the traffics to the mobile node. For example, The ongoing traffic requires 10Mbps bandwidth, but the available bandwidth of the mobile node is at most 1Mbps, then the home agent and the correspondent node SHOULD reduce their forwarding traffic amount. In vertical handover, the mobile node can be moved to various links such as wireless pan area, wireless lan are and cellular area and Park, et al. Expires October 3, 2005 [Page 6] Internet-Draft Link Characteristics Information April 2005 each link has its own specific characteristic information. This option can be more valuable model for vertical handover environment than horizontal handover. Using this option the mobile node is also able to inform the home agent and the correspondent node about links and networks it could attach to. The mobile node does not have to obey the preferred link and network indication received from the home agent or from the correspondent node. This document defines the bandwidth information as link characteristic and network identity as network information. However, there is no restriction to add other available information, which will be newly defined as new subtype and link characteristic information when a specific information is needed. 5. Security Considerations Attacker can use this option to reduce the current bandwidth regardless of link type of the mobile node. Furthermore, the attacker can use this option to suggest unnecessary handovers to the mobile node. Several mechanisms can be adoptable for both vulnerabilities. Encrypting traffic at link layer such that other users on the same link do not see the link characteristic information. This mechanism does not help against attackers on the rest of the path between the mobile node and the correspondent node. Encrypting the whole packet, such as when using IPsec to protect the communications with the correspondent node [RFC3776]. 6. IANA Considerations IANA should record a value for Link Characteristic Option including subtype (Mobile IPv4 Extension and Mobile IPv6 Option. 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 8.1 Handover and bandwidth Link Information example The example below shows the Link Information exchange in a vertical handover case. The mobile node performs a vertical handover from a Park, et al. Expires October 3, 2005 [Page 7] Internet-Draft Link Characteristics Information April 2005 46kbps GPRS network to a 11Mbps 802.11b network. During the Binding Update the mobile node communicates its new link bandwidth to the home agent and possibly to the correspondent node. After receiving the Binding Update the home agent and the correspondent node may adjust their traffic flows towards the mobile node to take advantage of the reported increased bandwidth. -------------------------------------------------------------- MN HA / CN -- ------- BU(Subtype(802.11b), S=1, Info(bw=11Mbps)) ---> <--- BA(Subtype(802.11b), S=1, Info(bw=11Mbps)) -------------------------------------------------------------- The following example shows the Link Information exchange in a vertical handover case, when the mobile node performs a handover from a 11Mbps 802.11b network to a 46kbps GPRS network. During a Binding Update the mobile node communicates its new link bandwidth to the home agent and possibly to the correspondent node. After receiving the Binding Update the home agent and the correspondent node should reduce their traffic flows towards the mobile node to match the reported decreased bandwidth. -------------------------------------------------------------- MN HA / CN -- ------- BU(Subtype(GPRS), S=1, Info(bw=46kbps)) ---> <--- BA(Subtype(GPRS), S=1, Info(bw=46kbps)) -------------------------------------------------------------- 8.2 Network initiated handover indication example In this example the mobile node is surrounded by multiple networks and the mobile node informs the home agent about all those networks. Originally the mobile node has been attached to a 802.11b network Park, et al. Expires October 3, 2005 [Page 8] Internet-Draft Link Characteristics Information April 2005 offering 11Mbps bandwidth. However, the home agent indicates to the mobile node in the Binding Acknowledgement that it should move to another 802.11b network offering just 1Mbps (for example due some existing policy at the home network home agent). The mobile node obeys the indication from the home agent, performs a handover to a new network and repeats the network information procedure in the following Binding Update. ----------------------------------------------------------------- MN HA / CN -- ------- BU(Subtype(802.11b), S=1, Info(bw=11Mbps,nid=foo) Subtype(802.16), S=0, Info(bw=32Mbps,nid=bar) Subtype(802.11b), S=0, Info(bw=1Mbps,nid=buz) Subtype(GPRS), S=0, Info(bw=46kbps,nid=123456)) --> <-- BA(Subtype(802.11b), S=0, Info(bw=11Mbps,nid=foo) Subtype(802.16), S=0, Info(bw=32Mbps,nid=bar) Subtype(802.11b), S=1, Info(bw=1Mbps,nid=buz) Subtype(GPRS), S=0, Info(bw=46kbps,nid=123456)) BU(Subtype(802.11b), S=0, Info(bw=11Mbps,nid=foo) Subtype(802.16), S=0, Info(bw=32Mbps,nid=bar) Subtype(802.11b), S=1, Info(bw=1Mpts,nid=buz) Subtype(GPRS), S=0, Info(bw=46kbps,nid=123456)) --> <-- BA(Subtype(802.11b), S=0, Info(bw=11Mbps,nid=foo) Subtype(802.16), S=0, Info(bw=32Mbps,nid=bar) Subtype(802.11b), S=1, Info(bw=1Mbps,nid=buz) Subtype(GPRS), S=0, Info(bw=46kbps,nid=123456)) ----------------------------------------------------------------- 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. Park, et al. Expires October 3, 2005 [Page 9] Internet-Draft Link Characteristics Information April 2005 9.2 Informative References [3GPP23003] 3GPP, "Numbering, Addressing and Identification", 3GPP TS 23.003, October 2003. [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [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 October 3, 2005 [Page 10] Internet-Draft Link Characteristics Information April 2005 Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Park, et al. Expires October 3, 2005 [Page 11] Internet-Draft Link Characteristics Information April 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 October 3, 2005 [Page 12]