Protocol Action: 'Mobile IPv6 Fast Handovers' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Mobile IPv6 Fast Handovers '
   <draft-ietf-mipshop-fmipv6-rfc4068bis-07.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:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

Technical Summary
 
  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.

Document Quality

  This is a revision of an existing Experimental specification,
  RFC 4068.

  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:

OLD:
   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.

NEW:
   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 
      conditions.

   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
   attained. 

  Also, add a new informative reference RFC 3290.

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce