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]