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

The IESG <iesg-secretary@ietf.org> Mon, 11 May 2009 18:04 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id D0E3D3A6B45; Mon, 11 May 2009 11:04:45 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Mobile IPv6 Fast Handovers' to Proposed Standard
Message-Id: <20090511180445.D0E3D3A6B45@core3.amsl.com>
Date: Mon, 11 May 2009 11:04:45 -0700
Cc: mipshop mailing list <mipshop@ietf.org>, Internet Architecture Board <iab@iab.org>, mipshop chair <mipshop-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2009 18:04:45 -0000

The IESG has approved the following document:

- 'Mobile IPv6 Fast Handovers '
   <draft-ietf-mipshop-rfc5268bis-01.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 Ralph Droms.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-rfc5268bis-01.txt

Technical Summary

  This document specifies a protocol to improve handover latency
  due to Mobile IPv6 procedures. During handover, there is a period
  during which the Mobile Node is unable to send or receive packets
  because of link switching delay and IP protocol operations.  This
  "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 (VoIP).

  This documents updates the packet formats for the Handover 
  Initiate (HI) and Handover Acknowledgement (HAck) messages to 
  Mobility Header Type.

Working Group Summary

  This is a quick re-issue of the RFC for FMIP, based on discussion
  in the WG that resulted in the desire to change the carrier protocol
  from ICMP to MH. The change was initiated by the 3GPP2 community
  who are the primary users of this protocol. It was viewed as a possible
  change given the current deployment situation; later this change might
  have been impossible.

Document Quality

  There are multiple implementations of the FMIPv6 protocol. There
  are also some folks wanting to deploy this protocol for fast 
  PMIPv6 handovers.

Personnel

  Document shepherd: Vijay Devarapalli
  Responsible AD: Jari Arkko

RFC Editor Note

  New text to be added to the current last paragraph in Introduction:
  NEW:
  Implementations of this specification MUST NOT send ICMPv6 HI and HAck
  messages as defined in [RFC5268]. If implementations of this
  specification receive ICMPv6 HI and HAck messages as defined in 
  [RFC5268], they MAY interpret the messages as defined in [RFC5268].

  Please change in Section 3.3:

  OLD:
  The MN MUST process this PrRtAdv to configure a new Care-of Address on
  the new subnet, and MUST send an FBU to PAR prior to switching to the 
  new link.
  NEW:
  The MN MUST process this PrRtAdv to configure a new Care-of Address on
  the new subnet, and MUST send an FBU to the PAR prior to switching to
  the new link.

  And in Section 6.2.1.2
  OLD:
  Finally, the New Access Router can always refuse handover, in which 
  case it should indicate the reason in one of the available Code
  values.
  NEW:
  Finally, the New Access Router can always refuse handover, in which
  case it MUST indicate the reason in one of the available Code values.

  In Section 11:
  OLD:
  The Subtype values 4 and 5 are deprecated and are marked as unassigned
  for future allocations.
  NEW:
  The Subtype values 4 and 5 are deprecated but marked as unavailable
  for future allocations.