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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
