Internet DRAFT - draft-korhonen-mobopts-link-characteristics-ps
draft-korhonen-mobopts-link-characteristics-ps
Network Working Group J. Korhonen
Internet-Draft TeliaSonera
Expires: December 11, 2006 S. Park
SAMSUNG Electronics
J. Zhang
University of York
C. Hwang
SAMSUNG Electronics
P. Sarolahti
Nokia Research Center
June 9, 2006
Link Characteristic Information for IP Mobility Problem Statement
draft-korhonen-mobopts-link-characteristics-ps-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 December 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses the problem space related to frequent changes
Korhonen, et al. Expires December 11, 2006 [Page 1]
Internet-Draft Link Characteristic Information June 2006
in the local link or sub-path characteristics of a mobile node due to
various reasons such as vertical handovers and the delivery of the
sub-path characteristic information from a mobile node to its peer
nodes. The purpose of this document is to define the scope and
requirements for possible future work on a generic sub-path
characteristic information delivery mechanism for optimizing IP
mobility performance and reducing the implications that significant
changes in the local link or sub-path characteristics tend to create
to the transport and application protocol behaviour by altering the
end-to-end path properties.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions and Observations . . . . . . . . . . . . . . . . . 5
4. Background and Motivations . . . . . . . . . . . . . . . . . . 6
4.1 Multimode Wireless Terminals . . . . . . . . . . . . . . . 6
4.2 Heterogeneous Networks and Terminal Mobility . . . . . . . 6
4.3 Adaptive Application and Services . . . . . . . . . . . . 7
4.4 Traffic Shaping . . . . . . . . . . . . . . . . . . . . . 8
4.5 Network-Initiated Handover . . . . . . . . . . . . . . . . 8
4.6 Signaling Support . . . . . . . . . . . . . . . . . . . . 8
4.7 Link Information Facility . . . . . . . . . . . . . . . . 9
4.8 Classification of Explicit Notification Mechanisms . . . . 9
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Out of Scope Issues . . . . . . . . . . . . . . . . . . . 13
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19
Korhonen, et al. Expires December 11, 2006 [Page 2]
Internet-Draft Link Characteristic Information June 2006
1. Introduction
Multi-radio mobile nodes (MN) are becoming common and consequently
the frequency of handovers between different access technologies
increases. These mobile nodes, for example mobile phones or PDAs,
may be reachable through multiple interfaces, even simultaneously.
The possibility of using a single or multiple interfaces at a time
for sending and receiving IP packets depends on the mobile node
capabilities. In both cases, roaming between heterogeneous links
(vertical handovers) can occur. A significant change in the access
link characteristic as a result of a handover may also affect end-to-
end path properties. These changes in the local link characteristics
and consequently in the end-to-end path properties are usually not
detected nor reacted quickly enough by higher layer transport
protocols and applications. Typically higher layers do not react to
the changes in path properties until certain mechanisms, such as
congestion control or error recovery, eventually get invoked at some
point later. This may cause undesirable disruptions, performance
degradation to the ongoing connections, unnecessary underutilization
of the available network capacity, or sudden overloading of the new
access link. For example, when a 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 continue transmitting at the rate adapted to the
802.11b bandwidth. Because the actual path capacity is now smaller,
a packet loss burst will occur and often result in inefficient loss
recovery at the transport protocol level. The situation could be
resolved by explicitly informing the other connection peer about the
significant changes in the local access link characteristics.
Unfortunately, existing IP mobility, transport and application layer
protocols do not provide any facility to indicate which type of link
the mobile node is currently attached to or what kind of changes
there were on the local access link.
The local access link characteristic may also vary significantly as a
result of a handover between links of the same type (horizontal
handovers). For example the new link may have significantly more
traffic load that the old link had or the new route the IP traffic
now takes has different end-to-end path properties. Moreover, even
if the mobile node stays on the same link, the local access link
characteristics may change significantly due to various reasons, for
example because of sudden variations of the traffic load on the
current link. All of these situations may lead to similar adverse
effects as those with vertical handovers.
This document discusses the problems related to the changes in the
local access link or sub-path characteristics that may also lead to
changes in the end-to-end path properties. This document also
Korhonen, et al. Expires December 11, 2006 [Page 3]
Internet-Draft Link Characteristic Information June 2006
discusses the actual problems or the lack of delivering the link
characteristic information between a mobile node and relevant nodes
along the end-to-end path. The purpose of this document is to define
the scope and requirements for generic link or sub-path
characteristic information delivery for: 1) optimizing mobility
performance and 2) enhancing transport protocol adaptation to the
changes end-to-end path properties that are a result of significant
local access link characteristics.
1.1 Problem Statement
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 network characteristics
with the relevant remote network nodes. With the emergence of
multimode mobile terminals and the roaming capability between
different access technologies, there is a need of sharing the local
sub-path characteristic information with the remote communicating
nodes, due to the fact that a wireless access link is most likely the
bottleneck on the end-to-end communication path and often represent a
significant portion of the end-to-end delay. Sharing the local sub-
path characteristics information with the remote end allows the other
end to detect and react much faster to the significant changes in the
end-to-end path properties. This is expected to reduce or even
completely avoid possible complications to the IP transport and
service quality as many applications and the congestion control
algorithms of the transport layer may often fail to respond fast
enough to such changes or may react in a wrong way when the path
characteristics suddenly change.
Sometimes the bottleneck of the end-to-end communication can be
elsewhere on the connection path (e.g., in WLAN+ADSL combination the
ADSL link can be the bottleneck, not the WLAN), and the sub-path
characteristics may need to be considered in conjunction with mobile
node's link characteristic itself.
Currently there is no standardized protocol for such link
characteristic information delivery. It is because existing mobility
protocols do not provide a mechanism to indicate which type of link
the mobile node is currently attached to. Therefore, some new
signaling mechanism is needed in terms of peer-to-peer communication.
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.
Korhonen, et al. Expires December 11, 2006 [Page 4]
Internet-Draft Link Characteristic Information June 2006
For the multiple wireless interfaces on the mobile node, there is a
possibility that the link characteristic information exchange can be
carried over multiple links simultaneously. It may be necessary for
the new signaling mechanism to support multiple connections per
application as multi-homing scenarios.
Protocols like Mobile IP [RFC3344][RFC3775], SCTP [RFC2960], DCCP
[RFC4340], RT(C)P [RFC3550], SIP [RFC3261], etc can be used for
carrying link characteristic information in their own extensions as
new options or fields. It might be more time consuming and complex
to extend each of these protocols instead of developing a generic
signaling solution.
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].
3. Assumptions and Observations
This document has a few fundamental assumptions concerning the
general networking environment and certain capabilities supported by
the mobile node and the remote nodes in the case that link
characteristics delivery functionality is to be deployed. These
assumptions are listed as follows:
o When multiple wireless interfaces are active on the mobile node,
link characteristic information exchanges can be carried over
multiple links simultaneously. It implies link characteristic
information delivery to support multiple connections per
application as multi-homing scenarios.
o In case the mobile node's handover is in progress, link
characteristic information delivery can be exchanged between the
mobile node and the remote nodes regardless of mobility signaling.
o Given link characteristic information from the mobile node, the
remote sender can adjust its sending rate and other communication
parameters dynamically within the limitations of the congestion
control principles [RFC2914] by using the received information as
a (strong) hint about changes in path properties.
o The mobile node has the required capabilities to gather relevant
characteristics information from its access links and/or access
network. Currently, some link characteristic information is in
use in an proprietary manner.
Korhonen, et al. Expires December 11, 2006 [Page 5]
Internet-Draft Link Characteristic Information June 2006
o When the bottleneck of the end-to-end communication is not in the
local access network, neither the mobile node nor any of its peers
have a robust way to determine the problem. The mobile node may
be able to gather some end-to-end path characteristics
information, for example when exchanging mobility related
signaling with the remote node. A node is assumed to act
conservatively with the link characteristic information due to the
lack of properly measured path characteristic information.
o The mobile node invokes link characteristic information
notification message based on its management policy (e.g.,
measured information threshold, periodic delivery, event driven,
etc.) and the required values and parameters are configured on the
mobile node (and the remote nodes if any). These policies are
outside the scope of the IETF.
o Mobile nodes, correspondent nodes, mobility management nodes and
other network entities are not expected to understand or support
link characteristic information exchange if they do not need this
particular feature. Legacy nodes and network entities also fall
into this category.
4. Background and Motivations
In this section we discuss the background and motivation for
developing link characteristic information delivery mechanism based
on scenarios.
4.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,
Bluetooth radios and IEEE 802.16e Broadband Wireless (called mobile
WiMAX or WiBro. It is possible that multiple of these radios are
simultaneously activated to attach to network instead of just one
single radio. In addition, the idea of being always on-line via
wireless access is not far-fetched anymore.
4.2 Heterogeneous Networks and Terminal Mobility
Due to the 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 perform a seamless handover between these different access
technologies in order to maintain connections and achieve best QoS
while moving.
Korhonen, et al. Expires December 11, 2006 [Page 6]
Internet-Draft Link Characteristic Information June 2006
However, the characteristics and capabilities of these different
access networks differ considerably, for example in terms of
available bandwidth, latency, 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 in the link performance.
Link characteristics may also change considerably when the mobile
node handovers between links of the same type, due to the different
traffic loads on the old and the new link. Furthermore, even when
the mobile node remains connected to the same link and no handover
occurs, path characteristics can change abruptly (for example when
radio conditions change on the local link).
Another local link related information that could be of use for
mobile nodes is the utilization of the link or the number of
potential users on the link. This kind of information could help
mobile nodes or rather the transport protocols to estimate the fair
share of the link capacity.
Current IP mobility management protocols do not deliver link related
information or indications locally to upper layers. Furthermore,
there is currently no way of signaling link characteristic related
information from the mobile node to the remote network nodes. Some
upper layer transport protocols and services can adapt to the changed
connection condition, however reactively only after the network
capacity misuse (over-utilization or under-utilization) has taken
place and has possibly been detected by e.g. some upper layer
congestion control mechanism. Thus those upper layer protocols,
applications and services may experience unnecessarily suboptimal
performance during this period, and often for a relatively long-
lasting period even after detecting and responding to the misuse.
4.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 are not
capable of reacting efficiently in the scenarios in question as they
were not designed to handle the situation discussed in this document.
One possible example of an adaptive application benefiting from 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
Korhonen, et al. Expires December 11, 2006 [Page 7]
Internet-Draft Link Characteristic Information June 2006
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.
There are several scalable-coding algorithms such as SVC (Scalable
Video Coding), H.264 Scalable Extension, BSAC (Bit Sliced Arithmetic
Coding), etc. to support a flexible control in terms of audio as well
as video. There are, however, some limitations to adjust its ongoing
traffic volumes from the sender because of lack of dynamic signaling
from the receiver while changing its link characteristics.
4.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.
4.5 Network-Initiated Handover
In some future circumstances, remote network nodes, such as the
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 link
characteristics information delivery mechanism, the remote nodes
would have more knowledge to be used for such decision makings.
4.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 link characteristic information useful.
Korhonen, et al. Expires December 11, 2006 [Page 8]
Internet-Draft Link Characteristic Information June 2006
4.7 Link Information Facility
To deliver link characteristic information, the mobile node has to
get its access link characteristics dynamically. IEEE 802.21 is
working for the MIHS (Media Independent Handover Services) composed
of MIES (Media Independent Event Service), MICS (Media Independent
Command Service) and MIIS (Media Independent Information Service).
Both MIES and MICS are for the local stack operations. MIES provides
event classification, event filtering and event reporting
corresponding to dynamic changes in link characteristics, link
status, and link quality. MICS enables the mobile node to manage and
control link behavior relevant to handovers and mobility. In
addition, implications of link indications are well described by
[I-D.iab-link-indications]. Consequently, the link information is
not vague and trivial facilities in IETF. How the mobile node
acquires its link characteristics dynamically and accurately is
beyond the scope of the link characteristic information delivery.
Even if the link information is delivered end-to-end, the mobile node
retrieving and sending the information cannot usually have more than
a good guess of the actual end-to-end path characteristics. However,
if the mobile node knows that the local link characteristics have
changed by some magnitude, it can inform the other end to trigger the
upper layer congestion control mechanisms to determine the effective
end-to-end path characteristics. Similarly the mobile node may base
some of its path characteristic information reasoning on the known
bounds of the local link. For example if the local link is known to
have 600ms roundtrip time and maximum bandwidth of 48kbps then the
end-to-end path characteristics cannot be better. Furthermore, some
initial measurement results on the end-to-end path can, for example,
be gathered by monitoring possible mobility related signaling that
takes place between the end hosts.
4.8 Classification of Explicit Notification Mechanisms
Based on the past work on explicit notification and communication
mechanisms, the following types of signaling between the end hosts
and the network can be identified. Signaling can be separated into
in-band and out-of-band mechanisms, based on whether the information
is piggy-backed along with the transport protocol traffic, or whether
the signaling is done by means of separate control packets,
respectively.
Benefit of using in-band signaling is that the signaling can be
better assumed to take the same network path as the protocol data.
Out-of-band mechanisms could take a different path due to different
policy actions: An IPsec policy might not aggregate the signaling
protocol to same security association as the data protocol, or a
Korhonen, et al. Expires December 11, 2006 [Page 9]
Internet-Draft Link Characteristic Information June 2006
policy-based routing system could select a different path for the
out-of-band signaling than for the protocol data. Sometimes a packet
with unrecognized content can cause the whole IP packet to be dropped
in the network due to NAT or firewall policy, or because of defective
router. When the message is transferred in-band, the loss
notification usually comes naturally with the protocol's own
acknowledgment mechanisms. For an out-of-band mechanism there might
not be any direct mechanisms to inform about the loss. Out-of-band
messages are also generally more susceptible for security problems
caused by a third party generating malicious messages. The drawback
of an in-band mechanism is that a loss due to additional content in
the IP packet disturbs also the data transfer.
In the following we discuss and evaluate various in-band and out-of-
band signaling mechanisms that could potentially be used to deliver
link characteristic information messages.
o In-band message processed by end hosts -- When a message is
attached to the transport protocol header, only the communication
end hosts can be assumed to see the message. Also IPv6 has
extension headers that are only processed by the end hosts. The
routers along the network path are not typically capable of
processing this kind of message, and if the packet is encrypted
with IPsec [RFC2401], it is impossible by other nodes than the end
hosts to read the message. The benefit of using transport header
is that it can be expected that the legacy routers and different
flavour of network middle boxes are not likely to take unexpected
actions on the packet, such as dropping a packet with unknown
option. An example of this kind of notification type is LMDR
[I-D.swami-tcp-lmdr] that uses a TCP option to allow a mobile end
host to notify the other end that it has moved.
o In-band message processed by some routers -- If a message uses
some of the reserved bits in the IP header, or is an IP hop-by-hop
option, routers along the network path are able to process it and
take appropriate actions. There can be two types of messages:
those that are only read by a router, and those that can also be
altered by the router. The options that are to be altered by the
router should not be covered by IPsec [RFC2402]. In case of IPv4
this means that such an option should be explicitly marked as a
mutable field for IPsec. An IPv6 option includes a bit that tells
IPsec whether the option is mutable or non-mutable. IPsec does
not cover the reserved bits in the IP header, either. Problem
with the use of IP options is that as of today, network is known
to drop the majority of packets with unknown IP options. Some
explicit notifications are such that they can be of benefit even
if a single router along the network path supports them. Explicit
Congestion Notification [RFC3168] is one such mechanism.
Korhonen, et al. Expires December 11, 2006 [Page 10]
Internet-Draft Link Characteristic Information June 2006
o In-band message processed by all routers -- Some message types
need to be processed by all routers in order to have effect. For
example Quick-Start [I-D.ietf-tsvwg-quickstart] is one such
mechanism. This is a hard requirement for any mechanism to be
used in the Internet, and this kind of schemes are likely to
remain in limited controlled portions of the network. These
messages would also utilize the reserved bits in the IP header or
IP options, with the same challenges as listed above. In
addition, usually the sender must be able to verify that all
routers have processed the message. One way to do this is by the
means of a separate TTL field in the message that is compared to
the IPv4 TTL or IPv6 hop count. If the two fields do not give
matching information about the number of hops on the connection
path, it can be concluded that there were routers that did not
process the notification message. IP tunnels are also a
considerable challenge to this kind of message, as they can hide
the inner IP header with the in-band message from the routers.
Sometimes the TTL field comparison does not reveal the presence of
such tunnels on the path.
o Out-of-band message processed by end hosts -- Sending ICMP
messages from the receiver to the sender of packet has been a
traditional way of reporting an error condition or other
information about the data transfer [RFC0792][RFC2463]. Usually
the transport header, or a part of it, is included in the message
to help the receiver of the ICMP message to identify the transport
connection the ICMP message concerns, and to conduct some
primitive security screening.
o Out-of-band message processed by routers -- Resource Reservation
Protocol (RSVP) [RFC2205] uses a specific protocol type for QoS
signaling between the sender and the receiver. RSVP requires that
every router processes the messages, so it includes a similar kind
of TTL-based hop tracking mechanism as Quick-Start does. In order
to have out-of-band messages processed at routers, they need to be
set to monitor the given protocol type inside the IP packets, or
the IP packets need to use an router alert option to trigger
further processing at the router. As with the in-band messages,
IP tunnels and layer 2 switching system may prevent the signaling
from working, or cause the signaling to work defectively. An out-
of-band message could also be sent from one of the router along
the network path, of which some of the ICMP error messages are a
common example. Taking strong actions based on such signaling is
not generally encouraged, though, because there would be many
security issues in the validity and authenticity of such messages.
To summarize, when designing a new signaling mechanism, a number of
Korhonen, et al. Expires December 11, 2006 [Page 11]
Internet-Draft Link Characteristic Information June 2006
issues should be considered based on the experiences from past
proposals. To mention two of the important issues, it should be
established whether some or all nodes along the path are required to
process the message. For example, short-cutting the usual congestion
or rate control mechanisms to get an increased sending rate requires
a permission from each node along the network path. Second, it
should be evaluated whether it is feasible to embed the signaling
into the protocol data traffic, or whether a separate signaling flow
is more appropriate, either as embedded to some existing signaling
such as Mobile IP binding updates, or using an entirely new protocol.
It is also possible that a combination of different mechanisms is
used: for example, a mobile host could use an end-to-end method to
tell the corresponding node about change in its status. In response,
corresponding node could trigger a hop-by-hop QoS request in the
changed environment.
5. Design Considerations
5.1 Requirements
This section lists the general requirements for a link or sub-path
characteristic information delivery mechanism design. The link
characteristic information delivery solution MUST fulfill all the
'MUST and MUST NOT requirements' listed below:
R1 Mobility solution independent -- Link characteristic information
encoding and encapsulation MUST NOT be specific to a certain IP
mobility solution (such as Mobile IP or HIP [RFC4423]).
R2 Link characteristic information delivery SHOULD be applicable to
existing mobility mechanisms (e.g., MIP, SIP, etc.), as well as to
transport-layer multi-homing mechanisms such as SCTP [RFC2960]
R3 Transport protocol independent -- The delivery of the link
characteristic information MUST support multiple transport
solutions and protocols.
R4 Link technology independent -- The transport of link
characteristic information MUST NOT be dependant on some
particular link technology and link technology specific way of
carrying information.
R5 Lightweight delivery mechanism MUST be designed to avoid
significantly increasing the amount of signaling traffic load,
especially over wireless links.
Korhonen, et al. Expires December 11, 2006 [Page 12]
Internet-Draft Link Characteristic Information June 2006
R6 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 link characteristic information for each link
separately. The solution SHOULD also support combining the
knowledge of all its available access links.
R7 Applicable when the remote peers are also mobiles -- In this case
the peers of both sides may support link characteristics
information delivery, and the solution MUST be able to handle the
"double jump" situations.
R8 Applicable when the mobile node is communicating with multiple
nodes over a single link -- The mobile node SHOULD be able to
support an algorithm for the link capacity allocation and notify
each node of its share.
R9 Link characteristic information encapsulation format MUST be
applicable to any existing and future link technology -- This
requirement basically means that the actual contents and
encapsulation format of link characteristic information MUST be
extendable to new link types and new link characteristics data.
R10 Link characteristic information delivery solution MUST NOT
introduce new security vulnerabilities to the environment it is
applied to.
R11 Link characteristic information MUST support middlebox traversal.
R12 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.
R13 Link Characteristic Information SHOULD be exchanged between the
mobile and remote node prior the handover, if just possible. This
would allow remote node to react proactively and utilize the link
characteristic information immediately when the handover takes
place.
R14 Link Characteristic Information SHOULD follow the congestion
control principles as described in [RFC2914].
5.2 Out of Scope Issues
This section lists the issues that are considered as strictly out of
scope of this problem statement and requirements document.
Korhonen, et al. Expires December 11, 2006 [Page 13]
Internet-Draft Link Characteristic Information June 2006
o Placing any requirements on the cross layer communications about
link characteristic information.
o Unidirectional links.
o Non-IP-capable links.
o Defining a new mobility framework.
o Defining how link characteristic information delivery initiator
(usually the mobile node) gathers its access link characteristic
information.
o Defining how link characteristic information delivery responder
(the relevant remote network nodes) actually make use of link
characteristic information. For example the remote peer may use
link characteristic information to optimize the transport layer
protocols by some specific algorithm particularly tied to the
transport layer protocols in question.
o Defining 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 link
characteristic information.
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
This document provides a problem statement and requirements for the
link characteristic information delivery when deployed used along
with IP mobility management. The link characteristic information
delivery signaling SHOULD be secured. Intermediating network nodes
between the link characteristic information sender and the receiver
MUST NOT be able to modify the contents of the link characteristic
information delivery messages. The strength of the applied security
mechanism for the link characteristic information delivery MUST NOT
weaken the existing security solution on the environment where the
link characteristic information delivery is applied to.
Potentially, malicious hosts may misuse the link characteristic
information delivery mechanism(s) to deliver erroneous link
characteristic information to the receiving hosts. However, a
Korhonen, et al. Expires December 11, 2006 [Page 14]
Internet-Draft Link Characteristic Information June 2006
malicious hosts who have the capability of fabricating and delivering
valid looking link characteristic information messages with erroneous
content are supposed to be easier to launch more serious attacks
using other mechanisms.
8. Acknowledgments
The authors would like to thank Rajeev Koodli and Koshiro Mitsuya for
their valuable comments and suggestions. The authors would also like
to thank Markku Kojo and Hannes Tschofenig for their detailed
comments, corrections and text contributions.
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.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
9.2 Informative References
[I-D.iab-link-indications]
Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-04 (work in
progress), December 2005.
[I-D.ietf-tsvwg-quickstart]
Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
Start for TCP and IP",
draft-ietf-tsvwg-quickstart-03 (work in progress),
October 2006.
[I-D.swami-tcp-lmdr]
Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility
Detection and Response (LMDR) Algorithm for TCP",
draft-swami-tcp-lmdr-07 (work in progress), February 2006.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Korhonen, et al. Expires December 11, 2006 [Page 15]
Internet-Draft Link Characteristic Information June 2006
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
Korhonen, et al. Expires December 11, 2006 [Page 16]
Internet-Draft Link Characteristic Information June 2006
Authors' Addresses
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FI-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Soohong Daniel Park
Mobile Convergence Laboratory, SAMSUNG Electronics.
416 Maetan-3dong, Yeongtong-gu
Suwon, Gyeonggi-do 443-742
KOREA
Phone: +82 31 200 4508
Email: soohong.park@samsung.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
Cheulju Hwang
Mobile Convergence Laboratory, SAMSUNG Electronics.
416 Maetan-3dong, Yeongtong-gu
Suwon, Gyeonggi-do 443-742
KOREA
Phone: +82 31 200 4508
Email: cheolju.hwang@samsung.com
Korhonen, et al. Expires December 11, 2006 [Page 17]
Internet-Draft Link Characteristic Information June 2006
Pasi Sarolahti
Nokia Research Center
P.O.Box 407
Helsinki FI-00045
FINLAND
Phone: +358 50 4876607
Email: pasi.sarolahti@iki.fi
Korhonen, et al. Expires December 11, 2006 [Page 18]
Internet-Draft Link Characteristic Information June 2006
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 (2006). 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 December 11, 2006 [Page 19]
Internet-Draft Link Characteristic Information June 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Korhonen, et al. Expires December 11, 2006 [Page 20]
