One document matched: draft-korhonen-mobopts-link-characteristics-ps-00.txt
Network Working Group J. Korhonen
Internet-Draft TeliaSonera
Expires: March 5, 2006 S. Park
SAMSUNG Electronics
J. Zhang
University of York
September 2005
Link Characteristic Information for IP Mobility Problem Statement
draft-korhonen-mobopts-link-characteristics-ps-00.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 March 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses the problems related to the link
characteristic information delivery from the mobile node to other
relevant network nodes. The purpose of this document is to set the
scope and goals for possible future work on generic link
characteristic information delivery for optimizing IP mobility
Korhonen, et al. Expires March 5, 2006 [Page 1]
Internet-Draft Link Characteristic Information September 2005
performance.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background and Motivations . . . . . . . . . . . . . . . . . . 5
3.1 Multimode Wireless Terminals . . . . . . . . . . . . . . . 5
3.2 Heterogeneous Networks and Terminal Mobility . . . . . . . 5
3.3 Adaptive Application and Services . . . . . . . . . . . . 6
3.4 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . 6
3.5 Network-Initiated Handover . . . . . . . . . . . . . . . . 6
3.6 Signaling Support . . . . . . . . . . . . . . . . . . . . 7
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 7
4.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Scenario 1 - peer to mobility anchor node link
characteristic delivery . . . . . . . . . . . . . . . . . 9
5.2 Scenario 2 - peer to peer link characteristic delivery . . 9
5.3 Scenario 3 - multiple-destination link characteristic
delivery . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Scenario 4 - link characteristic delivery delegation . . . 9
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1 Normative References . . . . . . . . . . . . . . . . . . . 10
9.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Korhonen, et al. Expires March 5, 2006 [Page 2]
Internet-Draft Link Characteristic Information September 2005
1. Introduction
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. Existing IP mobility solutions, such as Mobile IP
[RFC3344] [RFC3775], HIP [I-D.ietf-hip-arch] and MOBIKE [I-D.ietf-
mobike-design], do not provide a mechanism to indicate which type of
link the mobile node is currently 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
traffics 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 those on vertical handovers.
This document discusses the problems related to the link
characteristic information delivery from the mobile node to other
relevant network nodes (i.e. correspondent nodes, Mobile IP home
agent and any other network nodes that may consider the link
characteristic information useful). The purpose of this document is
to set the scope and goals for possible future work on generic link
characteristic information delivery for optimizing IP mobility
performance.
1.1 Overview of the Problem
The fundamental problem or rather the fundamental feature of all
widely accepted and standardized IP mobility enabling technologies is
that they are mobile node centric, operating on top of the link layer
and lacking proper dialogues about the access link characteristics
with the relevant remote network nodes. With the emergence of
multimode mobile terminals and the roaming capability between
Korhonen, et al. Expires March 5, 2006 [Page 3]
Internet-Draft Link Characteristic Information September 2005
different access technologies, there is a need of sharing accurate
link characteristic information with the remote communicating nodes,
due to the fact that wireless access links are most likely the
bottleneck of the communication path. This is expected to reduce or
even avoid possible complications to the IP transport and service
quality when the access link characteristics change considerably.
Currently there is no standardized protocol for such link
characteristic information delivery. Therefore, some new signaling
mechanism is needed. At the same time, the new signaling mechanism
to be defined SHOULD avoid significantly increasing the amount of
signaling traffic load, especially over wireless links. Moreover,
examining the tradeoff between the added delivery and computation
load of the new mechanism and gained advantage is also an issue that
needs serious considerations.
1.2 Terminology
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].
2. Assumptions
This document has a few fundamental assumptions concerning the
general networking environment and certain capabilities supported by
the mobile node in the case that the link characteristics delivery
functionality is to be deployed. These assumptions are listed as
follows:
o There exists a security relationship between the mobile node and
the remote nodes that participate in the link characteristic
information communications. This security relationship has been
set up before the mobile node and the remote nodes can make use of
the link characteristic information.
o Link characteristic information messages are piggybacked on top of
mobility protocol or signaling protocol that is used between the
mobile node and the remote nodes.
o All mobile nodes, correspondent nodes, mobility management nodes
and other network entities are not expected to understand or
support link characteristic information notification if they do
not need this particular feature. Legacy nodes and network
entities also fall into this category.
Korhonen, et al. Expires March 5, 2006 [Page 4]
Internet-Draft Link Characteristic Information September 2005
o The mobile node has the required capabilities to gather relevant
link information on those links it is connected to or is about to
connect, or name and identify these links uniquely. This means
the link characteristic information may not only be tied to those
links the mobile node is currently actively using.
3. Background and Motivations
In this section we discuss the background and motivations for
developing a link characteristic information delivery mechanism.
3.1 Multimode Wireless Terminals
Recently multimode wireless terminals have become more and more
common. For example, most modern mobile terminals are equipped with
a selection of cellular radios, various IEEE 802.11 family radios and
Bluetooth radios. It is possible that more than one of these radios
are activated to attach to network alternatively or simultaneously.
Also, the idea of always on-line via wireless is not far fetched
anymore.
3.2 Heterogeneous Networks and Terminal Mobility
Due to the impressive growth of various wireless technologies,
different access radios overlap, providing mobile users a
heterogeneous wireless access environment. Mobile terminals are
increasingly expected to be able to seamless handover between these
different access technologies in order to maintain connections and
achieve best QoS while moving.
However, the characteristics and capabilities of these different
access networks differ considerably for example in available
bandwidth, roundtrip times, bit error rates and queue management,
though in most cases wireless access links remain as the bottleneck
of the whole communication path. Therefore, vertical handovers may
lead to abrupt changes on the link performance.
Link characteristics may also change considerably when the mobile
node handovers between the same type of link, due to the different
traffic loads on the old and the new link. Furthermore, even when
the mobile node connects to the same link and no handover occurs,
link performance can change abruptly (for example when radio
conditions change) especially in some cellular networks.
However, these are at least initially unknown to upper layer
mechanisms due to the current IP mobility management protocols. Some
upper layer transport protocols and services can adapt to the changed
connection condition, however reactively until the network capacity
Korhonen, et al. Expires March 5, 2006 [Page 5]
Internet-Draft Link Characteristic Information September 2005
misuse (over-utilization or under-utilization) event has occurred and
been detected some time later. Thus those upper layer protocols,
applications and services may experience unnecessarily unoptimal
performance during this period. Unfortunately there is currently no
way of signaling this kind of information from the mobile node to the
remote network nodes in communications.
3.3 Adaptive Application and Services
Adaptive applications and services can greatly benefit from a
standardized mechanism that notifies abrupt changes of the link
characteristics in a proactively manner. That would allow
applications and services to adapt to the new connection conditions
immediately instead of through some generally conservative adapting
and error handling mechanisms. After all, these mechanisms were not
designed to handle the situation discussed in this document, so that
they are not efficient in the scenarios in question.
One possible example of an adaptive application benefiting from the
link characteristics information would be streaming services for
mobile vehicles. Assume a certain mobile vehicle can connect to the
network using various access technologies -- using macro cellular
access when the vehicle is on move and using 802.11 WLAN access when
the vehicle is not moving and within a hotspot coverage. The
adaptive application could then immediately scale the streaming
service content based on the mobile node's reported link capabilities
-- without waiting for the possible streaming protocol feedback
mechanism to discover the increased or decreased bandwidth of the
link.
3.4 Traffic Shaping
In the case that some or all traffic destined to the mobile node goes
through a mobility anchor node (e.g. the home agent in Mobile IPv6
bi-directional tunneling mode or previous access router in Mobile IP
fast handover protocols), it would be useful for the mobility anchor
node to shape the traffic towards the mobile node according to the
current link characteristic information provided by the mobile node.
For example, if the mobile node has announced its current link
capacity as 64kbps, the mobility anchor node has no point forwarding
more traffic than the announced data rate to overflow the mobile
node's access link. Instead, the mobility anchor node may limit the
forwarding rate itself or notify the remote peers (e.g. the
correspondent nodes) to reduce their traffic by some means.
3.5 Network-Initiated Handover
In some future circumstances, remote network nodes, such as the
Korhonen, et al. Expires March 5, 2006 [Page 6]
Internet-Draft Link Characteristic Information September 2005
Mobile IP home agent, may wish to suggest the mobile node to handover
to another access network possibly based on the required service
quality or certain administrative policies. With a link
characteristics information delivery mechanism, the remote nodes
would have more knowledge to be used for such decision makings.
3.6 Signaling Support
Currently there is no existing standardized or IP mobility solution
independent mechanism to signal link characteristic information from
the mobile node to the relevant remote network nodes. The relevant
remote network nodes include mobility management nodes (e.g. Mobile
IP home agent), correspondent nodes, and any other network nodes that
may consider the link characteristic information useful.
4. Design Considerations
4.1 Goals
This section lists the general goals for the link characteristic
information delivery mechanism design. The link characteristic
information delivery solution MUST fulfill all the goals listed
below:
G1 Mobility solution independent -- The link characteristic
information delivery solution MUST not be tied to a specific IP
mobility solution such as Mobile IP or HIP.
G2 Transport protocol independent -- The transport of the link
characteristic information MUST not be dependant on any particular
transport protocol.
G3 Link technology independent -- The transport of the link
characteristic information MUST not be dependant on some
particular link technology and link technology specific way of
carrying information.
G4 Applicable when the mobile node is either multi-homed or not -- In
the multi-homed case, multiple interfaces of the mobile node may
be activated to send and receive traffic. The solution MUST be
able to handle the link characteristic information for each link
separately. The solution SHOULD also support combining the
knowledge of all its available access links.
Korhonen, et al. Expires March 5, 2006 [Page 7]
Internet-Draft Link Characteristic Information September 2005
G5 Applicable when the remote peers are also mobiles -- In this case
the peers of both sides may support the link characteristics
information delivery, and the solution MUST be able to handle the
"double jump" situations.
G6 Applicable when multiple communicating nodes are present on one
interface of the mobile node -- The mobile node SHOULD support an
algorithm to assign the link capacity and notify the share to each
communicating node separately.
G7 The link characteristic information encapsulation format MUST be
applicable to any existing and future link technology -- This goal
basically means that the actual contents and encapsulation format
of the link characteristic information MUST be extendable to new
link types and new link characteristics data.
G8 The mobile node SHOULD be able to delegate its link characteristic
information delivery to other mobility management node and undo
the delegation when applicable and desired.
4.2 Non-Goals
This section lists the issues that are considered as strictly out of
scope of this problem statement document.
o Defining a new transport protocol or mechanism to carry the link
characteristic information.
o Defining any new security mechanisms or requirements.
o Placing any requirements on the cross layer communications about
the link characteristic information.
o Unidirectional links.
o Non-IP-capable links.
o Defining how the link characteristic information delivery
initiator (usually the mobile node) gathers its access link
characteristic information.
o Defining how the link characteristic information delivery
responder (the relevant remote network nodes) actually make use of
the link characteristic information. For example the remote peer
may use the link characteristic information to optimize the
transport layer protocols by some specific algorithm particularly
tied to the transport layer protocols in question.
Korhonen, et al. Expires March 5, 2006 [Page 8]
Internet-Draft Link Characteristic Information September 2005
o Defining the link capacity assignment algorithm when multiple
communicating nodes are present on one interface of the mobile
node. The assignment algorithms are left for the specific
applications and protocols that actually utilize the link
characteristic information.
5. Usage Scenarios
This section discusses some possible usage scenarios that could
benefit from the link characteristics information delivery in more
detail.
5.1 Scenario 1 - peer to mobility anchor node link characteristic
delivery
In this scenario the mobile node delivers the link characteristics
information only to the mobility anchor node. This scenario is valid
for example for Mobile IP without route optimization. Correspondent
nodes are completely left outside of the link characteristic
information delivery.
5.2 Scenario 2 - peer to peer link characteristic delivery
In this scenario the mobile node delivers link characteristic
information to one or more correspondent nodes. The protocol used to
encapsulate and deliver the link characteristic information MUST
allow communicating directly with correspondent nodes. This scenario
applies for example to HIP or route optimized Mobile IPv6 where both
peers could be mobile and are using peer to peer communications. In
this scenario it is possible that the mobile node acts as the role of
both the sender and receiver of the link characteristic information.
5.3 Scenario 3 - multiple-destination link characteristic delivery
This scenario is the generalization of scenarios 1 and 2. The mobile
node delivers link characteristic information to the mobility anchor
node as well as some correspondent nodes. This scenario applies for
example to the case that in Mobile IPv6 the mobile node communicates
with some of the correspondent nodes using the route optimization
mode while the others using the bi-directional tunneling mode.
5.4 Scenario 4 - link characteristic delivery delegation
In this scenario the mobile node purposely delegates its link
characteristic information delivery to some other network node. The
node taking care of the delegated link characteristic information
delivery MUST be able to capture all traffic coming from and going to
the mobile node. For example this scenario is applicable for access
Korhonen, et al. Expires March 5, 2006 [Page 9]
Internet-Draft Link Characteristic Information September 2005
systems with centralized radio resource management, where the
management node monitors the connected mobile nodes and their access
link resources continuously. The link characteristic information
delivery delegation can allow reducing the signaling overhead on
links where the link conditions vary frequently.
6. IANA considerations
This particular document does not define any new name spaces to be
managed by IANA. This document does not either reserve any new
numbers or names under any existing name space managed by IANA.
7. Security Considerations
Potentially, the model proposed in this document may be misused by an
attacker to indicate fabricated link characteristic information to
the mobility management nodes or correspondent nodes. However, the
link characteristic information is always intended to be carried as
part of the existing mobility-related signaling. In this case the
link characteristic information rely on the used transport mechanism
to guarantee the security for the message delivery. The used
mechanism for the link characteristic information transport MUST
provide the data origin authentication, integrity and replay
protection, and SHOULD provide confidentiality protection when there
is a need.
Attackers who have the capability of fabricating valid transport
messages of the link characteristic information are able to launch
more serious attacks than those potentially caused by the link
characteristic delivery model. Therefore, it is believed that the
deployment of the link characteristic information delivery does not
introduce new security vulnerabilities to the mobility solution of
choice.
8. Acknowledgments
The authors would like to thank Rajeev Koodli and Koshiro Mitsuya for
their valuable comments and suggestions.
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.
Korhonen, et al. Expires March 5, 2006 [Page 10]
Internet-Draft Link Characteristic Information September 2005
9.2 Informative References
[I-D.ietf-hip-arch]
Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-mobike-design]
Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
Protocol", draft-ietf-mobike-design-03 (work in progress),
July 2005.
[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
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
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
Korhonen, et al. Expires March 5, 2006 [Page 11]
Internet-Draft Link Characteristic Information September 2005
Ji Zhang
Communications Research Group, University of York.
Heslington
York YO10 5DD
United Kingdom
Phone: +44 1904 432310
Email: jz105@ohm.york.ac.uk
Korhonen, et al. Expires March 5, 2006 [Page 12]
Internet-Draft Link Characteristic Information September 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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
Korhonen, et al. Expires March 5, 2006 [Page 13]
Internet-Draft Link Characteristic Information September 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Korhonen, et al. Expires March 5, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 07:40:27 |