The IESG has approved the following document: - 'Fast Handovers for Proxy Mobile IPv6 ' <draft-ietf-mipshop-pfmipv6-13.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-pfmipv6-13.txt Technical Summary The document describes a mechanism to provide fast handovers when Proxy Mobile IPv6 is used as the mobility management protocol. It also describes a mechanism to transfer context between two MAGs to assist in the handover. The mobile node is not involved in any Signaling for the fast handovers to work. Working Group Summary This is a product of the MIPSHOP WG. Document Quality There are no known implementations of the specification. It is likely to be implemented by some vendors, since this document is required for fast handovers in 3GPP2 eHPRD network. Personnel Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko RFC Editor Note Change in Section 6.1.2: OLD: In this specification, the meaning of Code value 0 is modified, NEW: When the P flag is set, the meaning of Code value 0 is as defined in this specification, Change in Abstract: OLD: MAG NEW: Mobile Access Gateway (MAG) Change in Abstract and Section 2: OLD: mobility for mobile nodes NEW: mobility for nodes Change in Section 2: OLD: Proxy Mobile IPv6 [RFC5213] NEW: Proxy Mobile IPv6 (PMIPv6) [RFC5213] Change in Section 2: OLD: [RFC5568] should be considered normative for this document, except ... NEW: [RFC5568] is normative for this document, except ... Change in Section 4.1: OLD: It is hence required that all MAGs have the capability NEW: It is hence REQUIRED that all MAGs have the capability Change in Section 4.1: it is required that the mobile node is capable of reporting NEW: it is REQUIRED that the mobile node is capable of reporting Change in Section 4.1: OLD: MAG may optionally request ... NEW: MAG MAY optionally request ... Change in Section 4.2: OLD: This specification recommends the following: NEW: It is RECOMMENDED that: Change in Section 4: OLD: PFMIPv6 protocol in this document NEW: this document Change in Section 4: OLD: More specifically, the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and the Unsolicited Neighbor Advertisement (UNA) messages are not applicable in the PMIPv6 context. NEW: More specifically, the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and the Unsolicited Neighbor Advertisement (UNA) messages are not applicable in the PMIPv6 context. A MAG that receives a RtSolPr or FBU message from a mobile node SHOULD behave as if they do not implement FMIP as defined in [RFC5568] at all, continuing to operate according to this specification within the network, or alternatively, start serving that particular mobile node as specified in [RFC5568]. Change in Section 4.1: OLD: The HI message with the U flag set may be sent earlier if the timing of buffering is different from that of forwarding. NEW: The HI message with the U flag set MAY be sent earlier if the timing of buffering is different from that of forwarding. Change in Section 4.2: OLD: the NMAG should immediately send them towards the N-AN; otherwise it should buffer them until the mobile node is ready. NEW: the NMAG SHOULD immediately send them towards the N-AN; otherwise it SHOULD buffer them until the mobile node is ready. Change in Section 5.2: OLD: This allows the NMAG to perform some procedures that may be beneficial. The NMAG, for example, could send a Router Advertisement (RA) with the HNP option to the mobile node as soon as its link attachment is detected (e.g., via receipt of a Router Solicitation message). NEW: This allows the NMAG to perform some procedures that may be beneficial. The NMAG, for example, SHOULD send a Router Advertisement (RA) with prefix information to the mobile node as soon as its link attachment is detected (e.g., via receipt of a Router Solicitation message). Change in Section A.2: OLD: PFMIPv6 NEW: This specification _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce