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]