One document matched: draft-korhonen-mobopts-delivery-analysis-01.txt
Differences from draft-korhonen-mobopts-delivery-analysis-00.txt
Network Working Group J. Korhonen
Internet-Draft A. Makela
Intended status: Informational TeliaSonera
Expires: April 26, 2007 S. Park
SAMSUNG Electronics
H. Tschofenig
Siemens
October 23, 2006
Link and Path Characteristic Information Delivery Analysis
draft-korhonen-mobopts-delivery-analysis-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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document analyses capabilities and applicability of various IP
Mobility, signaling and transport protocols for delivering Link and
Path Characteristic Information between communicating end points.
Korhonen, et al. Expires April 26, 2007 [Page 1]
Internet-Draft LPCI Delivery Analysis October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3. Candidate Protocols . . . . . . . . . . . . . . . . . . . . . 4
3.1. IP protocol . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. CTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. NSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9. RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.10. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Table of results . . . . . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Results of the Analysis . . . . . . . . . . . . . . . . . 13
5.2. Recommendations for the Information Delivery . . . . . . . 14
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 April 26, 2007 [Page 2]
Internet-Draft LPCI Delivery Analysis October 2006
1. Introduction
Recently mobile nodes are increasingly being equipped with multiple
interfaces for different L2 technologies. These mobile nodes may be
reachable via different links at the same time or use each interface
independently depending on the network environment. In the latter
case, transitions between heterogeneous links (vertical handovers)
occur. Existing IP mobility solutions do not provide a mechanism to
indicate which type of link the mobile node is currently attached to
or what kind of characteristics the link has. Therefore, sudden
changes of access link characteristics are not observed quickly
enough by higher layer protocols and applications. Usually nothing
is done until a certain protocol or application dependent mechanism
(e.g., congestion control or error recovery mechanism) is invoked
some time later when a misuse of the network capacity has been
detected. Link Characteristic Information delivery mechanism
provides a mechanism to communicate link and path characteristic
changes to the remote peer node.
This documents lists and analyses various IP Mobility, signaling and
transport layer protocols in order to evaluate their suitability for
delivering link and path characteristic information between two
communicating end points. The analysis should determine whether
existing IP Mobility, signaling or transport player protocols can be
reused for delivering the LPCI Link and Path Characteristic
Information between the communicating end nodes. If existing
protocols are not applicable or there is not possible to achieve the
information delivery in a reasonable way then the development of a
generic protocol should be considered.
1.1. 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].
Link and Path Characteristic Information (LPCI):
An object delivered between communicating end points that contains
information about the link or path characteristics.
2. Scope
This document concentrates on a limited set of existing candidate
protocols for Link Characteristic Information (LPCI) delivery. The
suitability of these protocols is evaluated.
Korhonen, et al. Expires April 26, 2007 [Page 3]
Internet-Draft LPCI Delivery Analysis October 2006
2.1. In Scope
Within the scope of this analysis is going through all IP Mobility,
signaling and transport protocols listed in Section 3 and carefully
verifying whether the protocols are suitable for delivering LPCI
between end points. This basically means studying whether each
protocol is able to be extended to carry additional payloads related
to LPCI.
The analysis should also study whether the studied protocol allows
delivering the LPCI sporadically without a handover to taking place.
This could a useful feature when the link characteristics change
considerably mid session even without mobility. An abrupt change,
e.g., at the wireless link could justify delivering LPCI to the other
peer.
For each studied protocol the security aspects must also be taken
into account. The LPCI delivery mechanism must not offer off-path
adversaries the possibility to inject LPCI. Furthermore, the ability
to modify the content by an on-path attacker has to be considered.
Finally, a malicious end host must not be able to disturb the
behavior of other end hosts.
2.2. Out of Scope
Clearly out of scope this analysis document are the mechanisms how
the mobile node gathers the LPCI.
This document does not describe extensions for carrying LPCI nor does
it describe the content of the LPCI. This task is subject for
separate documents.
3. Candidate Protocols
This section discusses some possible candidate protocols to carry a
"container" format that could be used with all protocols.
o IPv4 - Analyze LPCI delivery using IPv4 header options. There is
the risk that IPv4 packets with IP options are dropped by routers.
o IPv6 - Analyze LPCI delivery using IPv6 header options. This
analysis should also study which option type is the most
appropriate to use.
Korhonen, et al. Expires April 26, 2007 [Page 4]
Internet-Draft LPCI Delivery Analysis October 2006
o SIP - Analyze LPCI delivery using SIP headers
o Mobile IPv4 - Analyze LPCI delivery as part of the Mobile IP
registration messages options. One of the important aspects is to
analyze possible mid-session usage where there is no need to do a
registration of new care-of address.
o Mobile IPv6 - Analyze LPCI delivery as part of the Mobile IP
binding update messages options. One of the important aspects is
to analyse possible mid-session usage where there is no need to do
a registration of new care-of address.
o HIP - Analyze LPCI delivery as part of the HIP base exchange and
UPDATE messages after a handover using for example NOTIFY
payloads.
o NSIS - Analyze LPCI delivery using NSIS mobility signaling with
possible required changes to support LPCI.
o CTP - Analyze whether CTP could be used for LPCI delivery.
o TCP - Analyze LPCI delivery using TCP options. Also take a look
into TCP Quick-Start as one possible user of the LPCI information.
o DCCP - Analyze LPCI delivery using DCCP options.
o SCTP - Analyze LPCI delivery using SCTP chunks. The multi-homing
aspect is considered important in case of SCTP.
o RTP/RTCP. - Analyze LPCI delivery using RTP and/or RTCP header
options.
3.1. IP protocol
IP protocol versions 4 [RFC0791] and 6 [RFC2460] are the basic
network layer protocols used on The Internet. Both IPv4 and IPv6
provide an "options" field where a single option has a limitation of
256 octets total length. IPv6 provides more flexibility in option
handling, as separate option classes exist for options that need to
be examined by all intermediate nodes on a path or only at the
destination. IPv4 options have no such classification, and options
are checked at all nodes. Because there is no separate class for
end-to-end options, all intermediate nodes have to examine all
options; Due to performance reasons such options are often filtered
and do not reliably reach destination. Furthermore, intermediate
nodes tend to drop IPv4 packets with options they do not understand
[MAF04].
Korhonen, et al. Expires April 26, 2007 [Page 5]
Internet-Draft LPCI Delivery Analysis October 2006
3.2. SIP
Session initiation protocol [RFC3261] is a protocol with the explicit
purpose of setting up sessions. The actual data protocol
communication is separate from the set-up. As such, any LPCI
information transferred over SIP would be used as initial parameters
for the session and, if applicable, subsequently as updates to the
session.
Sessions that are set up are described using Session description
protocol, or SDP [RFC2327]. The SDP parameters are pure text, and
include such variables as the session protocol to be used, protocol
ports, IP addresses, session participants and so on. LPCI
information for a session can be carried inside SDP as an extra
parameter.
SIP information can be transferred via several proxies, and
information about specific potential participant can be registered to
SIP registrars, allowing for delegation of LPCI information.
3.3. Mobile IP
Mobile IPv4 [RFC3344] provides a general protocol support for a IPv4
mobile node to register its current location with the Home Agent and
in that way create or update the mobility binding between mobile
node's current care-of-address and the Home Agent. The used Mobile
IPv4 registration messages offer a general extensibility mechanism.
Extension parameters are also integrity protected.
The mobile node may also send the registration request at any time
even if there is no handover taking place. The recent addition of
the NAT traversal allows mobile nodes communicating behind NATs. The
same NAT traversal mechanism also allows mobile nodes to communicate
fluently through statefull firewalls even if the original goal was to
allow NATs in visited networks.
Unfortunately, base Mobile IPv4 only provides a mechanism to exchange
Mobile IPv4 control messages between the mobile node and the foreign
agent or between the mobile node and the home agent. The lack of
route optimization in base Mobile IPv4 prevents mobile nodes
exchanging any control messages directly between the mobile node and
the correspondent node or even between the home agent and the
correspondent node.
In contrast to Mobile IPv4, Mobile IPv6 [RFC3775] provides a route
optimization feature as an integral feature of the base specification
that allows the mobile node to send its mobility binding directly to
the correspondent node. After a successful route optimization
Korhonen, et al. Expires April 26, 2007 [Page 6]
Internet-Draft LPCI Delivery Analysis October 2006
binding update the mobile node and the correspondent node start
communicating directly end-to-end with each other. The route
optimization is an optional feature and mobile nodes are not
obligated to use it.
3.4. CTP
Context transfer protocol [RFC4067] is a protocol designed to
expedite handovers for a mobile node. It allows "contexts" to be
transferred from the mobile node's current access router to new
access router before the handover. If a break-before-make handover
occurs, the new access router can also request the context transfer
from the previous one afterwards.
An example of "context" is multicast listener information, where
transferring the information lowers the cost of the handover
considerably.
CTP uses ICMP messages between the mobile node and the access router,
and SCTP between access routers. Because CTP is always a separate
message, LPCI messages could be bundled inside a CTP message that is
going to be sent anyway (i.e. when changing access routers).
However, when link information changes without access router
changing, (Such as when roaming from 3G to GPRS), every CTP message
is causing significant load on the network. Thus it may fail
requirement R5 for lightweight operation.
3.5. HIP
The Host Identity Protocol [RFC4423] creates a new cryptographic
namespace placed between the transport and the network layer. One of
the extensions defined for HIP concerns mobility and multi-homing
[I-D.ietf-hip-mm].
When a host moves to another address, it notifies its peer of the new
address by sending a HIP UPDATE packet containing a LOCATOR
parameter. This UPDATE packet is then acknowledged by the peer.
LPCI can be exchanged as part of the UPDATE packet.
3.6. NSIS
Next Steps in Signaling protocol suite (see GIST
[I-D.ietf-nsis-ntlp], QoS NSLP [I-D.ietf-nsis-qos-nslp], NATFW NSLP
[I-D.ietf-nsis-nslp-natfw] and an overview of the framework in
[RFC4080]) aims to provide a generic signaling protocol. One of the
applications, such as the QoS NSLP, allows QoS signaling message to
be carried between two end points and to let intermediate routers to
participate along the path. NSIS offers functionality similar to
Korhonen, et al. Expires April 26, 2007 [Page 7]
Internet-Draft LPCI Delivery Analysis October 2006
RSVP, but aims to be more generic and covers more usage environments.
When designing a solution using NSIS three cases need to be
considered. If the data sender moves (or switches to a different
link layer interface) then the impact will most likely be at the side
of the data sender. If the data receiver moves (or switches to a
different link layer interface) then the impact will most likely be
at the side of the data receiver. In some cases (e.g., due to
network mobility or rerouting events) the impact might be somewhere
along the path independent from the end points.
If NSIS is used for E2E QoS signaling then the additional
functionality is minimal since NSIS inter-working with mobility and
multi-homing is required for NSIS and already provided. For a
discussion of the problems and the solutions the reader is referred
to [I-D.ietf-nsis-applicability-mobility-signaling]. For a data
sender there is no problem to trigger a new NSIS signaling exchange.
The exchange is shown in the subsequent figure whereby only a single
intermediate node is depicted for editorial reasons:
MN Node CN
(Sender) (Receiver)
| | |
| LPCI - QUERY | |
+------------------------------->| QUERY |
| +--------->|
| | RESPONSE |
| RESPONSE |<---------+
|<-------------------------------+ |
| | |
When the data sender (MN) roams or changes the interface then a LPCI
QUERY message is sent to collect path characteristics. When the data
receiver (CN) receives the message it returns a RESPONSE message and
thereby provides the learned path characteristics back to the MN.
Due to routing asymmetry the same approach cannot be used by the data
receiver when the problem is detected there first. The message
exchange then has to start with a trigger based on MIP or NSIS as
shown in the following figure:
Korhonen, et al. Expires April 26, 2007 [Page 8]
Internet-Draft LPCI Delivery Analysis October 2006
MN Node CN
(Receiver) (Sender)
| | |
| NOTIFICATION | |
|------------------------------------------>|
| | |
| | QUERY |
| LPCI - QUERY |<---------+
|<-------------------------------+ |
| | |
| RESPONSE | |
+------------------------------->| RESPONSE |
| +--------->|
| | |
| | |
The first message aims to show a notification message that causes the
data sender to initiate a LPCI QUERY message as shown in the previous
message.
Problems within the middle of the network are detected with period
QUERY/RESPONSE message exchange.
When QoS signaling is not desired, as in the case of LPCI exchange,
then a new NSLP is needed. The support for LPCI nodes can be
incrementally deployed, starting in environments such as access
networks and moving networks. Such an NSIS LPCI NSLP can therefore
consider path instead of only link characteristics resulting in a
more robust solution. Note that the LPCI QUERY / RESPONSE message
exchange does not need to create state to be allocated at
intermediate devices.
3.7. TCP
Transmission control protocol [RFC0793] guarantees reliable and in-
order delivery of sender to receiver data.
TCP session is set up via a three-way handshake, and packet order and
reliability is maintained by sequence numbers and sliding window
acknowledgements. Congestion is handled via mechanisms such as slow
start and explicit notifications.
Since it's original introduction, TCP has been extended on multiple
occasions, as the protocol provides a variable-length "options"
field. The options have been used to transmit such information as
window scaling factor and timestamps for RTT measurements. Adding a
new option for LPCI is trivial.
Korhonen, et al. Expires April 26, 2007 [Page 9]
Internet-Draft LPCI Delivery Analysis October 2006
To lower information traversal, TCP's URG flag should be set for
packets containing LPCI data, so that applications can react
accordingly with minimal delay.
3.8. DCCP
The Datagram Congestion Control Protocol (DCCP) [RFC4340]is a
transport protocol that provides bidirectional unicast connections of
congestion-controlled unreliable datagrams. DCCP is intended for
applications such as streaming media that can benefit from control
over the tradeoffs between delay and reliable in-order delivery.
DCCP does not contain support for mobility or multihoming anymore.
Mobility and multihoming are now defined as an option in a separate
document [I-D.kohler-dccp-mobility]. Each DCCP connection was
associated with exactly two network-level addresses over its
lifetime, one per endpoint. There is one potential design for DCCP
mobility and multihoming support.
DCCP mobility and multihoming support is based on generalized
connections. A generalized connection groups one or more transport
connections, called component connections, into a single application-
level entity. To move addresses, a host attaches a new component
connection, then detaches the old component connection. The first
connection handshake in a generalized connection must register the
intention to set up a generalized connection. The generalized
connection's identifier is then agreed upon by the two endpoints
(assuming they both support mobility). Thereafter, new component
connections specify the intended generalized connection in their
handshakes.
Even though there is one potential mechanism for DCCP Mobility which
makes a new component connection and destroys a old component
connection with congestion control, it has many problems to guarantee
quality-of-service, such as packet loss, jitter ,out of sequence
packets and so on. Mobile networks with many participants and poor
network resources cause a DCCP packet delays. This fact indicates
that DCCP may not be satisfactory for LPCI delivery.
DCCP is not currently in wide use.
3.9. RTP/RTCP
RTP protocol [RFC3550] provides end-to-end transport functions
suitable for applications transmitting real-time data, such as audio
and video, over multicast or unicast network services. RTP does not
address resource reservation and does not guarantee quality-of-
service for real-time services. RTP is augmented by a control
protocol (RTCP) to monitor data delivery and network statistics.
Korhonen, et al. Expires April 26, 2007 [Page 10]
Internet-Draft LPCI Delivery Analysis October 2006
RTCP packets are transmitted periodically to all participants in the
session to provide feedback on the quality of the data distribution
as the form of Sender Report (SR) or Receiver Report (RR). All
participants send RTCP packets, therefore the interval of sending
RTCP packet must be controlled in order for RTP to scale up to a
large number of participants. This is an integral part of the RTP's
role as a transport protocol and is related to the flow and
congestion control.
Although RTCP resolves many of the problems in UDP network
environment, such as lost packets, jitter, and out of sequence
packets, it that reports conditions of session periodically may have
difficulty to guarantee quality-of-service immediately. Mobile
environments with many participants and low bandwidth may cause the
long interval of RTCP transmission (e.g., five, six seconds or more).
Although there is more immediate RTCP feedback (defined in 'Extended
RTP profile for RTCP-based Feedback'), RTCP feedback message is heavy
to send LPCI. As RTCP feedback message is added the end of normal
RTCP packet, it may send unnecessary information in addition to the
LPCI. Moreover, RTCP feedback message is hard to respond immediately
when the receiver is in the large group. The previously discussed
issues are more a problem of RTP itself with a large receiver group
than a LPCI specific issue. Therefore, RTP and RTCP might not be
appropriate for the LPCI delivery without resolving above problems
first, late and inefficient Link and Path Characteristic Information
delivery.
3.10. SCTP
SCTP [RFC2960] is a general-purpose transport layer protocol. SCTP
provides features such as multi-streaming and multi-homing that may
be helpful in mobility environment.
SCTP's current multi-homing allows two end-points to set up an
association with multiple IP address for each endpoint.
Retransmission of lost packets can be done over the secondary path.
Mobile SCTP is able to provide a solution for limited mobility
scenarios as well. A multi-access user would be able to roam between
heterogeneous access networks without breaking any existing
connections. A new connection for the same session can be
initialized with separate parameters (congestion window size, MTU
,etc.)
As SCTP originally does not provide QoS support, extensions may be
needed for expedited LPCI delivery. It should be able to implement
LPCI delivery by extending ASCONF chunk message for dynamic address
configuration or by making suggestion of new chunk. SCTP is not
currently in wide use.
Korhonen, et al. Expires April 26, 2007 [Page 11]
Internet-Draft LPCI Delivery Analysis October 2006
4. Table of results
Results are presented in the following tables:
+-----------+-----+-----+-----+-----+---------+---------+-----+
| Protocol | R1 | R2 | R3 | R4 | R5 | R6 | R7 |
+-----------+-----+-----+-----+-----+---------+---------+-----+
| IP | N/A | N/A | Yes | Yes | Var [1] | yes | N/A |
| SIP | N/A | N/A | Yes | Yes | Yes | N/A | N/A |
| Mobile IP | Yes | Yes | Yes | Yes | Var [7] | Yes [5] | Yes |
| CTP | Yes | Yes | Yes | Yes | Var [7] | N/A | N/A |
| HIP | Yes | Yes | Yes | Yes | Var [7] | Yes | Yes |
| NSIS | Yes | Yes | Yes | Yes | Var[10] | Yes | Yes |
| TCP | N/A | N/A | Yes | Yes | Yes | No | Yes |
| DCCP | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| RTP/RTCP | N/A | N/A | Yes | Yes | Var [7] | Yes | Yes |
| SCTP | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
+-----------+-----+-----+-----+-----+---------+---------+-----+
Table 1
+-----------+-----+-----+-----+---------+----------+---------+-----+
| Protocol | R8 | R9 | R10 | R11 | R12 | R13 | R14 |
+-----------+-----+-----+-----+---------+----------+---------+-----+
| IP | Yes | Yes | Yes | See [2] | N/A | N/A | N/A |
| SIP | Yes | Yes | Yes | Yes [3] | Yes [4] | N/A | N/A |
| Mobile IP | N/A | Yes | Yes | Yes | Yes | Yes [6] | Yes |
| CTP | N/A | Yes | Yes | Yes | Yes | Yes | Yes |
| HIP | N/A | Yes | Yes | Yes | Yes(RVS) | Yes | Yes |
| NSIS | Yes | Yes | Yes | Yes | Yes | Yes[11] | Yes |
| TCP | Yes | Yes | Yes | Yes | No | Yes | Yes |
| DCCP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes |
| RTP/RTCP | Yes | Yes | Yes | Yes | No [4] | No [8] | Yes |
| SCTP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes |
+-----------+-----+-----+-----+---------+----------+---------+-----+
Table 2
[1] Load depends of implementation option handling. Options have to
be examined at every node on the path, except in the case of IPv6
Destination Options.
[2] NAT's and firewalls generally handle traversal based on 4-tuple
of IP addresses and source and destination ports. Also, IPv4 headers
may be removed at the intermediate nodes due to lack of
classification between end-to-end and hop-by-hop options.
[3] SIP traverses through firewalls, but the session that will be set
Korhonen, et al. Expires April 26, 2007 [Page 12]
Internet-Draft LPCI Delivery Analysis October 2006
up as a follow-up requires explicit support from the firewall (SIP
ALG) or other mechanisms, such as STUN.
[4] Delegation via SIP proxies or other mechanisms possible.
[5] MIP supports multiple care-of-addresses.
[6] Preregistering new care-of-address before deregistering the next
allows for seamless handovers. The new care-of-address registration
can contain new LPCI values.
[7] Explicit messages for ONLY the LPCI data increases signaling
load; If LPCI data can be bundled with other (necessary) signaling,
load increase is minimal.
[8] RTCP message sending delay may grow too large for the information
to lose it's significance. Using explicit notifications contradicts
R5.
[9] Protocol is relatively new, so support in firewalls and NAT
equipment is still emerging and not widely available.
[10] NSIS as an out-of-band mechanism is naturally more heavy-weight
than an in-band mechanism. The total amount of overhead depends,
however, on a number of factors. Details can be determined from
[nsis-performance-paper].
[11] NSIS needs to be triggered at the new point of attachment while
the mobile node is still at the old point of attachment. This is
possible in a mobility environment but introduces complexity.
5. Conclusions
5.1. Results of the Analysis
The results of the analysis are that most of the protocols can
technically transport the LPCI attributes; i.e. they have a freely-
definable option-field or similar structure. However, other
constraints may impact feasibility of individual protocols.
The primary concern is that the LCI information should not cause too
much additional signaling load to the network, and the information
should still be of value upon reaching destination. Most transport
protocols implement some sort of congestion and flow control, which
will cause delay in sending LPCI information 'bundled' with normal
flow of information. On the other hand, explicit notification
mechanisms will increase load significantly. For example, a single
Korhonen, et al. Expires April 26, 2007 [Page 13]
Internet-Draft LPCI Delivery Analysis October 2006
option field in a TCP acknowledgement packet increases the load with
a few bytes; but an explicit notification in a separate IP packet
(such as the RTP notification mechanism) will require an entire
additional packet to be constructed and sent.
5.2. Recommendations for the Information Delivery
The most problematic situation is a break-before-make handover from a
high-speed link to low-speed link. If high bandwidth is available,
the additional load caused by explicit notifications are not such a
significant issue; even in a make-before-break situation (predictive
handover) most of the additional load can be sent on the high-speed
link before the handover occurs.
After such a handover, the following recommendations can be made:
o Use a delegation mechanism, if possible, such as Mobile IP Home
agent to make the notifications to peer nodes, to avoid extra load
on the final link.
o If delegation is not possible, include the LCI data inside
standard session packets, such as TCP acknowledgements (packets
that would be sent regardless) or Mobile IP path optimization
binding update.
o Have peers reuse the information; If having multiple sessions with
a single host, send the LCI information only once and have it
concern all the sessions.
The LPCI delivery solution SHOULD be a generic container that can be
transferred over any transport protocol. Individual transport
protocols MAY use protocol-specific derivations for eg. data
compression, but such specifics are beyond the scope of this
document.
6. IANA Considerations
This document does not require actions by IANA.
7. Security Considerations
Security requirements for the delivery of LPCI have been mentioned in
[I-D.korhonen-mobopts-link-characteristics-ps]. This document lists
a number of candidate protocols whereby each protocol offers
different security properties. A security analysis has to be
provided for each protocol.
Korhonen, et al. Expires April 26, 2007 [Page 14]
Internet-Draft LPCI Delivery Analysis October 2006
8. Acknowledgments
Special thanks to Yunju Choe (contributor of RTP section), Jeongrok
Jang (contributor of DCCP section) and Minho Lee (contributor of SCTP
section) for their valuable contributions.
9. References
9.1. Normative References
[I-D.korhonen-mobopts-link-characteristics-ps]
Korhonen, J., "Link Characteristic Information for IP
Mobility Problem Statement",
draft-korhonen-mobopts-link-characteristics-ps-01 (work in
progress), June 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-04 (work in
progress), June 2006.
[I-D.ietf-nsis-applicability-mobility-signaling]
Lee, S., "Applicability Statement of NSIS Protocols in
Mobile Environments",
draft-ietf-nsis-applicability-mobility-signaling-05 (work
in progress), June 2006.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in
progress), June 2006.
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-11 (work in
progress), August 2006.
[I-D.ietf-nsis-qos-nslp]
Manner, J., "NSLP for Quality-of-Service Signaling",
draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006.
[I-D.kohler-dccp-mobility]
Korhonen, et al. Expires April 26, 2007 [Page 15]
Internet-Draft LPCI Delivery Analysis October 2006
Kohler, E., "Generalized Connections in the Datagram
Congestion Control Protocol",
draft-kohler-dccp-mobility-02 (work in progress),
June 2006.
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes,
in Internet Measurement Conference 2004", August 2004.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, 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.
[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.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
Korhonen, et al. Expires April 26, 2007 [Page 16]
Internet-Draft LPCI Delivery Analysis October 2006
[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.
[nsis-performance-paper]
Fu, X., Hogrefe, D., Schulzrinne, H., Tschofenig, H., and
C. Dickmann, "Overhead and Performance Study of the
General Internet Signaling Transport (GIST) Protocol, in
IEEE INFOCOM 2006, Bacelona, Spain, IEEE", April 2006.
Authors' Addresses
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Antti Makela
TeliaSonera Corporation.
P.O.Box 777
FIN-33101 Tampere
FINLAND
Phone: +358 40 824 4170
Email: antti.makela@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 April 26, 2007 [Page 17]
Internet-Draft LPCI Delivery Analysis October 2006
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Korhonen, et al. Expires April 26, 2007 [Page 18]
Internet-Draft LPCI Delivery Analysis October 2006
Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Korhonen, et al. Expires April 26, 2007 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 07:38:51 |