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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux