One document matched: draft-daniel-mip-link-characteristic-01.txt
Differences from draft-daniel-mip-link-characteristic-00.txt
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
-- -------
<MN attached to GPRS network at 46kbps>
<handover to 802.11b network at 11Mbps>
BU(Subtype(802.11b), S=1, Info(bw=11Mbps)) --->
<--- BA(Subtype(802.11b), S=1, Info(bw=11Mbps))
<HA & CN adjust their traffic to the new bandwidth>
--------------------------------------------------------------
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
-- -------
<MN attached to 802.11b network at 11Mbps>
<handover to GPRS network at 46kbps>
BU(Subtype(GPRS), S=1, Info(bw=46kbps)) --->
<--- BA(Subtype(GPRS), S=1, Info(bw=46kbps))
<HA & CN adjust their traffic to the new bandwidth>
--------------------------------------------------------------
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
-- -------
<MN attached to 802.11b network 'foo' at 11Mbps>
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))
<handover from 'foo' to 'buz'>
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))
<MN attached to 802.11b network 'buz' at 1Mbps>
-----------------------------------------------------------------
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]
| PAFTECH AB 2003-2026 | 2026-04-21 18:29:07 |