From: The IESG <email@example.com>
To: IETF-Announce <firstname.lastname@example.org>
Cc: Internet Architecture Board <email@example.com>,
RFC Editor <firstname.lastname@example.org>,
mipshop mailing list <email@example.com>,
mipshop chair <firstname.lastname@example.org>
Subject: Protocol Action: 'Mobile IPv6 Fast Handovers' to
The IESG has approved the following document:
- 'Mobile IPv6 Fast Handovers '
<draft-ietf-mipshop-fmipv6-rfc4068bis-08.txt> as a Proposed Standard
This document is the product of the Mobility for IP: Performance,
Signaling and Handoff Optimization Working Group.
The IESG contact persons are Jari Arkko and Mark Townsley.
A URL of this Internet-Draft is:
Mobile IPv6 enables a Mobile Node to maintain its connectivity to
the Internet when moving from an Access Router to another, a
process referred to as handover. During this time, the Mobile
Node is unable to send or receive packets due to both link
switching delay and IP protocol operations. The "handover
latency" resulting from standard Mobile IPv6 procedures, namely,
movement detection, new Care of Address configuration and Binding
Update, is often unacceptable to real-time traffic such as Voice
over IP. Reducing the handover latency could be beneficial to
non real-time, throughput-sensitive applications as well. This
document specifies a protocol to improve handover latency due
to Mobile IPv6 procedures.
Working Group Summary
The document has gone through WGLC in MIPSHOP WG.
This is a revision of an existing Experimental specification,
There are a few implementations of the proposed protocol available
already. There has also been one interop event where two
implementations were tested.
This specification has been reviewed by Jari Arkko for the IESG.
Note to RFC Editor
Please insert "Obsoletes: 4068" to the header.
Change this text in Section 5.4:
Whereas buffering can enable a smooth handover, the buffer size and
the rate at which buffered packets are eventually forwarded are
important considerations when providing buffering support. For
instance, an application such as Voice over IP typically needs
smaller buffers compared to high-resolution streamig video, which has
larger packet sizes and higher arrival rates. This specification
does not restrict implementations to providing buffering support for
any specific application. However, the implementations should
recognize that the buffer size requirements are dependent on the
application characteristics (including the arrival rate, arrival
process, perceived performance loss in the event buffering is not
offered, and so on), and arrive at their own policy decisions.
Particular attention must be paid to the rate at which buffered
packets are forwarded to the MN once attachment is complete. Just as
in any network event where a router buffers packets, forwarding
buffered packets in a handover at a rate inconsistent with the policy
governing the outbound interface can cause performance degradation to
the existing sessions and connections. Implementations must take
care to prevent such occurances, just as routers do with buffered
packets on the Internet.
Whereas buffering can enable a smooth handover, the buffer size
and the rate at which buffered packets are eventually forwarded
are important considerations when providing buffering support.
There are a number of aspects to consider:
o Some applications transmit less data over a given period of
data than others, and this implies different buffering
requirements. For instance, Voice over IP typically needs
smaller buffers compared to high-resolution streaming video,
as the latter has larger packet sizes and higher arrival rates.
o When the mobile node re-appears on the new link, having the
buffering router send a large number of packets in quick
succession may overtax the resources of the router, the mobile
node itself, or the path between these two.
In particular, if a large number of packets are buffered,
sending them out one after another may cause some of them to be
dropped by routers on the path. Or they may stand in queue,
blocking new packets reaching the mobile node. This would be
problematic for real-time communications.
o The routers are not one of the parties in the end-to-end
communication, so they has no knowledge of transport layer
o The wireless connectivity of the mobile node may vary over
time. It may achieve a smaller or higher bandwidth on the new
link, signal strength may be weak at the time it just entered
the area of this access point, and so on.
As a result, it is hard to design an algorithm that would send
the packets out from the buffer properly spaced under all
circumstances. Note that running out of resources due to too fast
draining of the buffer can be harmful to both the mobile node
itself or other nodes using the same path. The purpose of fast
handovers is to avoid packet loss. Yet, too fast draining can by
itself cause loss of the buffered packets as well as blocking or
losing other packets also trying to reach the mobile node.
This specification does not restrict implementations from
providing specialized rules buffering support for any specific
situation. However, attention must be paid to the rate at which
buffered packets are forwarded to the MN once attachment is
complete. Routers implementing this specification MUST implement
at least the default algorithm, which is based on the original
arrival rates of the buffered packets. A maximum of 5 packets MAY
be sent one after another, but all subsequent packets SHOULD
use a sending rate that is determined by metering the rate at
which packets have entered the buffer, potentially using smoothing
techniques such as recent activity over a sliding time window and
weighted averages [RFC 3290].
It should be noted, however, that this default algorithm is crude
and may not be suitable for all situations. Future revisions of
this specification may provide additional algorithms, once enough
experience of the various conditions in deployed networks is
Also, add a new informative reference RFC 3290.