Review of draft-ietf-mipshop-pfmipv6-03.txt

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Review of draft-ietf-mipshop-pfmipv6-03.txt

Sri Gundavelli (sgundave)

Some comments on the draft.


1. Too many functional elements. P-AR, PAN, PMAG. What should
one imply, PAN sending a message to PMAG ? We dont have that
interface in Proxy Mobile IPv6 and so that interface should
be hidden. From PMIP perspective, we just have a MAG, LMA,
MN and events from the network. You may want to get rid of all
the other jargon or functions. The call flows have to be between
3 functional elements.

2. The protocol is very loosely specified and is ambiguous
w.r.t the protocol operation. I'd rewrite Section 4.0,
which is more an explanation of a call flow, rather than a
specification one can implement. I'd try to specify it in a
bit more logical manner. It might be better to specify
it from the order of sequence of events:

     a.) A new trigger from the network, for MN's attachment to the
     new link.

        - Specify the MAG operation from both sending/receiving end
        - Specify the MN states (layer-2, layer-3), before and after
        - Specify the forwarding rules on both the MAG's
        - State that LMA is immunte
        - Cover error cases for HI/HACK failures, MN detachment at
          any of the links during various stages of this protocol

3. The tunnel between the MAG's is a shared tunnel for all
the mobile flows, I assume ? If so, in most cast cases its
a predictive mode. Since, the difference here for the
predictive and reactive mode is just the order of steps
(#c and #e), may be its better to merge and avoid the text
duplication.

4. There is very limited text on the encap type or the
life-cycle management of the tunnel between the MAG's.
When they come and go.

5. When the transport network is IPv4 or IPv6, so the type
of tunnel and the encap needs to be specified.

6. The spec introduces a new security relation between the
MAG's, which is not there in 5213. This new requirement needs
to be properly specified. There are just 2 lines in Security
Considerations, which ideally for covering residual security
aspects.

7. Buffering requirements at MAG, may be few lines of text might
help.

8. AP-Id ? Has no relevance in this document. MN-AR is a point to
point link, the radio link should be hidden from this spec.

9. Section 4.2, if the above structure is followed.

10. Section 5, 2nd paragraph, assumes MN will perform NUD after
a handoff. We are getting into the DNA space. MN will perform
RS/RA and not NUD. Also, NUD takes on average 53 secs to detect
a neighbor loss, so has no relevance here.

11. MN-AN connection establishment: Needs proper explanation on what
this is. If it is a link-layer setup, or a layer-3 setup. There is
lot of text in 5213 on the assumption around inter-tech handoff.
Some pointers to the affect that those assumptions are still valid.
Secondly, need to emphasise that after MN-AN connection implies the
prefix movement from the MN perspective. But, from Fig 3, how can
this happen in Reactive handoff, where the prefix is not known by
N-MAG till HI-HACK signaling is complete ?

12. State that how MN-MN traffic is handled at P-MAG and N-MAG, if
EnableMAGLocalRouting is ON.

Regards
Sri















>
> 2.  Introduction
>
>    Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>    that does not possess Mobile IPv6 [RFC3775] mobile node
>    functionality.  A proxy agent in the network performs the mobility
>    management signaling on behalf of the mobile node.  This model
>    transparently provides mobility for mobile nodes within a PMIPv6
>    domain.  Nevertheless, the basic performance of PMIPv6 in terms of
>    handover latency and packet loss is considered not any different from
>    that of Mobile IPv6.
>
>    Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the
>    protocol to reduce the handover latency for Mobile IPv6 by allowing a
>    mobile node to send packets as soon as it detects a new subnet link
>    and by delivering packets to the mobile node as soon as its
>    attachment is detected by the new access router.  This document
>    describes necessary extensions to FMIPv6 for operations in the PMIPv6
>    domain in order to minimize handover delay and packet loss as well as
>    to transfer network-resident contexts.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 4]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 3.  Terminology
>
>    This document refers to [RFC5213][RFC5268bis][RFC3775] for
>    terminology.  The following terms and abbreviations are additionally
>    used in this document.  The reference network is illustrated in
>    Figure 1.
>
>    Access Network (AN):
>         A network composed of link-layer access devices such as access
>         points or base stations providing access to the Access Router
>         (AR) connected to it.
>
>    Previous Access Network (P-AN):
>         The access network to which the MN is attached before handover.
>
>    New Access Network (N-AN):
>         The access network to which the MN is attached after handover.
>
>    Previous Mobile Access Gateway (PMAG):
>         The MAG that manages mobility related signaling for the MN
>         before handover.  In this document, the MAG and the Access
>         Router are collocated.
>
>    New Mobile Access Gateway (NMAG):
>         The MAG that manages mobility related signaling for the MN after
>         handover.  In this document, the MAG and the Access Router (AR)
>         are collocated.
>
>    HO-Initiate:
>         A generic signaling that indicates the handover of the MN sent
>         from the P-AN to the PMAG.  While this signaling is dependent on
>         the access technology, it is assumed that HO-Initiate can carry
>         the information to identify the MN and to assist the PAR resolve
>         the NAR (e.g., the new access point or base station to which the
>         MN is moving).  Detailed definition of this message is outside
>         the scope of this document.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 5]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>                                   +----------+
>                                  |    LMA    |
>                                  | |
>                                   +----------+
>                                    /      \
>                                   /        \
>                                   /          \
>                       +........../..+      +..\..........+
>                       . +-------+-+ .______. +-+-------+ .
>                       . |   PAR   |()_______)|   NAR   | .
>                       . |  (PMAG) | .      . |  (NMAG) | .
>                       . +----+----+ .      . +----+----+ .
>                       .      |      .      .      |      .
>                       .   ___|___   .      .   ___|___   .
>                       .  /       \  .      .  /       \  .
>                       . (  P-AN   ) .      . (  N-AN   ) .
>                       .  \_______/  .      .  \_______/  .
>                       .      |      .      .      |      .
>                       .   +----+    .      .   +----+    .
>                       .   | MN |  ---------->  | MN |    .
>                       .   +----+    .      .   +----+    .
>                       +.............+      +.............+
>
>               Figure 1: Reference network for fast handover
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 6]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 4.  Proxy-based FMIPv6 Protocol Overview
>
>    In order to improve the performance during handover (when operations
>    such as attachment to a new network and signaling between mobility
>    agents are involved), the PFMIPv6 protocol in this document specifies
>    a bi-directional tunnel between the Previous MAG (PMAG) and the New
>    MAG (NMAG).  In order to enable the NMAG to send the Proxy Binding
>    Update (PBU), the Handover Initiate (HI) and Handover Acknowledge
>    (HAck) messages in [RFC5268bis] are used for context transfer, in
>    which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4
>    Home Address, are transferred from the PMAG.
>
>    In this document, the Previous Access Router (PAR) and New Access
>    Router (NAR) are interchangeable with the PMAG and NMAG,
>    respectively.
>
>    Since a MN is not directly involved with IP mobility protocol
>    operations, it follows that the MN is not directly involved with fast
>    handover procedures either.  Hence, the messages involving the MN in
>    [RFC5268bis] are not used when PMIPv6 is in use.  Such messages are
>    the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy
>    Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast
>    Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement
>    (UNA).
>
> 4.1.  Protocol Operation
>
>    There are two modes of operation in FMIPv6 [RFC5268bis].  In the
>    predictive mode of fast handover, a bi-directional tunnel between the
>    PAR and NAR is established prior to the MN's attachment to the NAR.
>    In the reactive mode, this tunnel establishment takes place after the
>    MN attaches to the NAR.  Since the MN is not involved in IP mobility
>    signaling in PMIPv6, the sequence of events illustrating the
>    predictive fast handover are shown in Figure 2.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 7]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>                                             PMAG        NMAG
>           MN         P-AN       N-AN        (PAR)       (NAR)     LMA
>          | | | | | |
>          |   Report   |          |            |           |        |
>      (a)  |-(MN ID,-->|          |            |           |        |
>          |  New AP ID)|          |            |           |        |
>          | |      HO Initiate       |           |        |
>      (b)  |           |--(MN ID, New AP ID)-->|           |        |
>          | | | | | |
>          | | | |     HI     |        |
>      (c)  |           |          |            |-(MN ID, ->|        |
>          | | | |  MN IID, LMAA)      |
>          | | | | | |
>      (d)  |           |          |            |<---HAck---|        |
>          | | | |   (MN ID)  |        |
>          | | | | | |
>          | | | | HI/HAck(optional)   |
>     (e)  |           |          |            |<- - - - ->|        |
>          | | |           #=|<===================|
>      (f)  |           |          |          #====DL data=>|        |
>          | | | | | |
>      (g) ~~~          |          |            |           |        |
>         ~ ~ ~ | | | | |
>          |    MN-AN connection   |    AN-MAG connection   |        |
>      (h)  |<---establishment---->|<----establishment----->|        |
>          | | |   (substitute for UNA)  |        |
>          | | | | | |
>      (i)  |<==================DL data=====================|<=======|
>          | | | | | |
>     (j)  |===================UL data====================>|=#      |
>          | | | # =|<============#      |
>          | | | # =====================>|
>      /    |           |          |            |           |        | \
>     | (k) |           |          |            |           |--PBU-->| |
>     | | | | | | | |
>     | (l) |           |          |            |           |<--PBA--| |
>      \    |           |          |            |           |        | /
>
>       Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
>
>   The detailed descriptions are as follows:
>
>    (a)  The MN detects that a handover is imminent and reports the
>         identifications of itself (MN ID) and the access point (New AP
>         ID) to which the MN is most likely to move.  The MN ID could be
>         the NAI or a Link Layer Address (LLA), or any other suitable
>         identifier.  This step is access technology specific.  In some
>         cases, the P-AN will determine which AP ID the MN is moving to.
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 8]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>    (b)  The previous access network (P-AN), to which the MN is currently
>         attached, indicates the handover of the MN to the PAR (PMAG).
>         Detailed definition and specification of this message are
>         outside the scope of this document.
>
>    (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>         the MN ID and SHOULD include the MN-HNP, the MN-IID and the
>         address of the LMA that is currently serving the MN.
>
>   (d)  The NAR sends the HAck back to the PAR.
>
>    (e)  If it is preferred that the timing of buffering or forwarding
>         should be later than step (c), the NAR may optionally request
>         the PAR at a later and appropriate time to buffer or forward
>         packets by setting U or F flags in the HI message, respectively.
>
>    (f)  If the F flag is set in the previous step, a bi-directional
>         tunnel is established between the PAR and NAR and packets
>         destined for the MN are forwarded from the PAR to the NAR over
>         this tunnel.  After decapsulation, those packets may be buffered
>         at the NAR.  If the connection between the N-AN and NAR has
>         already been established, those packet may be forwarded towards
>         the N-AN; this is access technology specific.
>
>   (g)  The MN undergoes handover to the New Access Network (N-AN).
>
>    (h)  The MN establishes a connection (e.g., radio channel) with the
>         N-AN, which in turn triggers the establishment of the connection
>         between the N-AN and NAR if it has not been established already
>         (access technology specific).  This can be regarded as a
>         substitute for the UNA.
>
>    (i)  The NAR starts to forward packets destined for the MN via the
>         N-AN.
>
>    (j)  The uplink packets from the MN are sent to the NAR via the N-AN
>         and the NAR forwards them to the PAR.  The PAR then sends the
>         packets to the LMA that is currently serving the MN.
>
>    (k)  The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
>         whose address is provided in (c).  Steps (k) and (l) are not
>         part of the fast handover procedure, but shown for reference.
>
>    (l)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
>         NAR (NMAG).  From this time on, the packets to/from the MN go
>         through the NAR instead of the PAR.
>
>   According to Section 4 of [RFC5268bis], the PAR establishes a binding
>
>
>
> Yokota, et al.         Expires September 10, 2009               [Page 9]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>    between the PCoA and NCoA to forward packets for the MN to the NAR,
>    and the NAR creates a proxy NCE to receive those packets for the NCoA
>    before the MN arrives.  In the case of PMIPv6, however, the only
>    address that is used by the MN is MN-HoA.  Hence the PAR forwards
>    MN's packets to the NAR instead of the NCoA.  FMIPv4 [RFC4988]
>    specifies forwarding when the MN uses HoA as its on-link address
>    rather than the care-of address.  The usage in PMIPv6 is similar to
>    that in FMIPv4, where the address is used by the MN is based on Home
>    Network Prefix.  Hence the PAR forwards MN's packets to the NAR
>    instead of the NCoA.  The NAR then simply decapsulates those packets
>    and delivers them to the MN.  Since the NAR obtains the LLA (MN IID)
>    and MN-HNP by the HI, it can create the NCE for the MN and deliver
>    packets to it even before the MN can perform Neighbor Discovery.  For
>    the uplink packets from the MN after handover in (j), the NAR
>    forwards the packets to the PAR through the tunnel established in
>    step (f).  The PAR then decapsulates and sends them to the LMA.
>
>    The timing of the context transfer and that of packet forwarding may
>    be different.  Thus, a new flag 'F' and the Option Code values for it
>    in the HI message are defined to request forwarding.  To request
>    buffering, 'U' flag has already been defined in [RFC5268bis].  If the
>    PAR receives the HI message with F flag set and the Option Code value
>    being 2, it starts forwarding packets for the MN.  The HI message
>    with U flag set may be sent earlier if the timing of buffering is
>    different from that of forwarding.  If packet forwarding is
>    completed, the PAR MAY send the HI message with F flag set and the
>    Option Code value being 3.  By this message, the ARs on both ends can
>    tear down the forwarding tunnel synchronously.
>
>    The IP addresses in the headers of those user packets are summarized
>    below:
>
>   In (f),
>
>        Inner source address: IP address of the CN
>
>        Inner destination address: HNP or IPv4-MN-HoA
>
>        Outer source address: IP address of the PAR (PMAG)
>
>        Outer destination address: IP address of the NAR (NMAG)
>
>   In (i),
>
>        Source address: IP address of the CN
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 10]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>        Destination address: HNP or IPv4-MN-HoA
>
>   In (j),
>
>   - from the MN to the NMAG,
>
>        Source address: HNP or IPv4-MN-HoA
>
>        Destination address: IP address of the CN
>
>   - from the NMAG to the PMAG,
>
>        Inner source address: HNP or IPv4-MN-HoA
>
>        Inner destination address: IP address of the CN
>
>        Outer source address: IP address of the NAR (NMAG)
>
>        Outer destination address: IP address of the PAR (PMAG)
>
>   - from the PMAG to the LMA,
>
>        Inner source address: HNP or IPv4-MN-HoA
>
>        Inner destination address: IP address of the CN
>
>        Outer source address: IP address of the PAR (PMAG)
>
>        Outer destination address: IP address of the LMA
>
>    In the case of the reactive handover for PMIPv6, since the MN does
>    not send either the FBU or UNA, it would be more natural that the NAR
>    sends the HI to the PAR after the MN has moved to the new link.  The
>    NAR then needs to obtain the information of the PAR beforehand.  Such
>    information could be provided, for example, by the MN sending the
>    AP-ID on the old link and/or by the lower-layer procedures between
>    the P-AN and N-AN.  The exact method is not specified in this
>    document.  Figure 3 illustrates the reactive fast handover procedures
>    for PMIPv6, where the bi-directional tunnel establishment is
>    initiated by the NAR.
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 11]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>                                          PMAG            NMAG
>           MN       P-AN      N-AN        (PAR)           (NAR)     LMA
>          | | | | | |
>      (a) ~~~        |         |            |               |        |
>         ~ ~ ~ | | | | |
>          |   MN-AN connection |       AN-MAG connection    |        |
>      (b)  |<--establishment-->|<-------establishment------>|        |
>          | (MN ID, Old AP ID) |     (MN ID, Old AP ID)     |        |
>          | | | (substitute for UNA and FBU)|        |
>          | | | | | |
>          | | | |       HI       |        |
>      (c)  |         |         |            |<---(MN ID) ---|        |
>          | | | | | |
>          | | | |      HAck      |        |
>      (d)  |         |         |            |---(MN ID, --->|        |
>          | | | |  MN IID, LMAA) |        |
>          | | | | | |
>     (e)  |         |         |          #=|<=======================|
>          | | |           #================>|=#      |
>          | <====================DL data======================#      |
>          | | | | | |
>     (f)  |=====================UL data===================>|=#      |
>          | | | # =|<================#      |
>          | | | # =========================>|
>          | | | | | |
>      /    |         |         |            |               |        | \
>     | (g) |         |         |            |               |--PBU-->| |
>     | | | | | | | |
>     | (h) |         |         |            |               |<--PBA--| |
>      \    |         |         |            |               |        | /
>
>        Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
>
>   The detailed descriptions are as follows:
>
>    (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
>         on the old link may be provided by the MN to help identify the
>         PMAG on the new link.
>
>    (b)  The MN establishes a connection (e.g., radio channel) with the
>         N-AN, which triggers the establishment of the connection between
>         the N-AN and NAR.  The MN ID is transferred to the NAR for the
>         subsequent procedures.  The AP-ID on the old link may also be
>         provided by the MN to help identify the PMAG on the new link.
>         This can be regarded as a substitute for the UNA and FBU.
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 12]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>    (c)  The NAR sends the HI to the PAR.  The HI message MUST include
>         the MN ID.  The Context Request Option MAY be included to
>         request additional context information on the MN to the PAR.
>
>    (d)  The PAR sends the HAck back to the NAR.  The HAck message MUST
>         include the HNP and/or IPv4-MN-HoA that is corresponding to the
>         MN ID in the HI message and SHOULD include the MN-IID and the
>         LMA address that is currently serving the MN.  The context
>         information requested by the NAR MUST be included.
>
>    (e)  If F flag in the HI is set, a bi-directional tunnel is
>         established between the PAR and NAR and packets destined for the
>         MN are forwarded from the PAR to the NAR over this tunnel.
>         After decapsulation, those packets are delivered to the MN via
>         the N-AN.
>
>    (f)  The uplink packets from the MN are sent to the NAR via the N-AN
>         and the NAR forwards them to the PAR.  The PAR then sends the
>         packets to the LMA that is currently serving the MN.
>
>    Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover
>    procedures.
>
>    In step (c), The IP address of the PAR needs to be resolved by the
>    NAR to send the HI to the PAR.  This information may come from the
>    N-AN or some database that the NAR can access.
>
> 4.2.  IPv4 Support Considerations
>
>    The motivation and usage scenarios of IPv4 protocol support by PMIPv6
>    are described in [IPv4PMIPv6].  The scope of IPv4 support covers the
>    following two features:
>
>   o  IPv4 Home Address Mobility Support, and
>
>   o  IPv4 Transport Support.
>
>    As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
>    Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
>    transfer IPv4-MN-HoA to the NMAG, which is the inner destination
>    address of the packets forwarded on the downlink.  In order to
>    support IPv4-MN-HoA, a new option called IPv4 Address Option is
>    defined in this document.  In order to provide IPv4 Transport
>    Support, the NMAG needs to know the IPv4 address of the LMA (IPv4-
>    LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4
>    transport network.  The above IPv4 Address Option is defined so as to
>    be able to convey IPv4-LMAA.  The details of this option are
>    described in [IPv4PMIPv6].
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 13]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 5.  Other Considerations
>
>    The protocol specified in this document enables the NMAG to obtain
>    parameters which would otherwise be available only by communicating
>    with the LMA.  For instance, the HNP and/or IPv4-MN-HoA of a MN are
>    made available to the NMAG through context transfer.  This allows the
>    NMAG to perform some procedures which may be beneficial.  For
>    instance, the NMAG could send a Router Advertisement (RA) with the
>    HNP option to the MN as soon as it's link attachment is detected
>    (e.g., via receipt of a Router Solicitation message).  Such an RA is
>    recommended, for example, in scenarios where the MN uses a new radio
>    interface while attaching to the NMAG; since the MN does not have
>    information regarding the new interface, it will not be able to
>    immediately send packets without first receiving an RA with HNP.
>    However, if the subsequent PMIPv6 binding registration for the HNP
>    fails for some reason, then the NMAG MUST withdraw the advertised HNP
>    by sending another RA with zero prefix lifetime for the HNP in
>    question.  This operation is the same as that described in Section
>    6.12 of [RFC5213].
>
>    The protocol specified in this document is applicable regardless of
>    whether link-layer addresses are used between a MN and its access
>    router.  A MN should be able to continue sending packets on the
>    uplink even when it changes link.  When link-layer addresses are
>    used, the MN performs Neighbor Unreachability Detection (NUD)
>    [RFC4861], after attaching to a new link, probing the reachability of
>    its default router.  If the new router's interface is configured to
>    respond to queries sent to link-layer addresses than its own (e.g.,
>    set to promiscuous mode), then it can respond to the NUD probe,
>    providing its link-layer address in the solicited Neighbor
>    Advertisement.  While the MN is performing NUD, it can continue to
>    send uplink packets.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 14]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 6.  Message Formats
>
>    This document defines new Mobility Header messages for the extended
>    HI and Hack and new mobility options for conveying context
>    information.
>
> 6.1.  Mobility Header
>
> 6.1.1.  Handover Initiate (HI)
>
>    This section defines extensions to the HI message in [RFC5268bis].
>    The format of the Message Data field in the Mobility Header is as
>    follows:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +-------------------------------+
>                                     |            Sequence #          |
>     +-+-+-+-----------+-------------+-------------------------------+
>     | S|U|F|  Reserved |     Code    |                               |
>      +-+-+-+-----------+-------------+                               |
>     | |
>      .                                                               .
>      .                       Mobility options                        .
>      .                                                               .
>     | |
>      +---------------------------------------------------------------+
>
>   IP Fields:
>
>   Source Address
>
>                       The IP address of PMAG or NMAG
>
>   Destination Address
>
>                       The IP address of the peer MAG
>
>   Message Data:
>
>   Sequence #  Same as [RFC5268bis].
>
>    S flag      Defined in [RFC5268bis] and MUST be set to zero in this
>                specification.
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 15]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>   U flag      Buffer flag.  Same as [RFC5268bis].
>
>    F flag      Forwarding flag.  Used to request to forward the packets
>                for the MN.
>
>   Reserved    Same as [RFC5268bis].
>
>    Code        [RFC5268bis] defines this field and its values 0 and 1.
>                In this specification, if F flag is not set, this field
>                MUST be set to zero.  Otherwise, it has the following
>                meaning:
>
>                         2: Forwarding is not requested
>
>                         3: Request forwarding
>
>                         4: Indicate the completion of forwarding
>
>   Mobility options:
>
>    This field contains one or more mobility options, whose encoding and
>    formats are defined in [RFC3775].  At least one mobility option MUST
>    uniquely identify the target MN (e.g., the Mobile Node Identifier
>    Option defined in RFC4283) and the transferred context MUST be for
>    one MN per message.  In addition, the NAR can request necessary
>    mobility options by the Context Request Option defined in this
>    document.
>
>   Context Request Option
>
>             This option MAY be present to request context information
>             typically by the NAR to the PAR in the NAR-initiated fast
>             handover.
>
> 6.1.2.  Handover Acknowledge (HAck)
>
>    This section defines extensions to the HAck message in[RFC5268bis].
>    The format of the Message Data field in the Mobility Header is as
>    follows:
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 16]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +-------------------------------+
>                                     |            Sequence #          |
>     +-+-+-----------+---------------+-------------------------------+
>     | U|F| Reserved  |     Code      |                               |
>      +-+-+-----------+---------------+                               |
>     | |
>      .                                                               .
>      .                       Mobility options                        .
>      .                                                               .
>     | |
>      +---------------------------------------------------------------+
>
>   IP Fields:
>
>   Source Address
>
>                        Copied from the destination address of the
>                        Handover Initiate message to which this message
>                        is a response.
>
>   Destination Address
>
>                        Copied from the source address of the Handover
>                        Initiate message to which this message is a
>                        response.
>
>   Message Data:
>
>    The usages of Sequence # and Reserved fields are exactly the same as
>    those in [RFC5268bis].
>
>   U, F flags  Same as defined in Section 6.1.1.
>
>    Code
>                Code values 0 through 4 and 128 through 130 are defined
>                in [RFC5268bis].  In this specification, the meaning of
>                Code value 0 is modified, 128 through 130 are reused, and
>                5, 6, 131 and 132 are newly defined.
>
>                       0: Handover Accepted
>
>                       5: Context Transfer Successful or Accepted
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 17]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>                       6: All available Context Transferred
>
>                       128: Handover Not Accepted, reason unspecified
>
>                       129: Administratively prohibited
>
>                       130: Insufficient resources
>
>                       131: Requested Context Not Available
>
>                       132: Forwarding Not Available
>
>   Mobility options:
>
>    This field contains one or more mobility options, whose encoding and
>    formats are defined in [RFC3775].  The mobility option that uniquely
>    identifies the target MN MUST be copied from the corresponding HI
>    message and the transferred context MUST be for one MN per message.
>
>    Requested option(s)  All the context information requested by the
>              Context Request Option in the HI message SHOULD be present
>              in the HAck message.  The other cases are described below.
>
>    In the case of the PAR-initiated fast handover, when the PAR sends
>    the HI message to the NAR with the context information and the NAR
>    successfully receives it, the NAR returns the HAck message with Code
>    value 5.  In the case of the NAR-initiated fast handover, when the
>    NAR sends the HI message to the PAR with or without Context Request
>    Option, the PAR returns the HAck message with the requested or
>    default context information (if any).  If all available context
>    information is transferred, the PAR sets the Code value in the HAck
>    message to 6.  If more context information is available, the PAR sets
>    the Code value in the HAck to 5 and the NAR MAY send new HI
>    message(s) to retrieve the rest of the available context information.
>    If none of the requested context information is available, the PAR
>    returns the HAck message with Code value 131 without any context
>    information.
>
> 6.2.  Mobility Options
>
> 6.2.1.  Context Request Option
>
>    This option is sent in the HI message to request context information
>    on the MN.  If a default set of context information is defined and
>    always sufficient, this option is not mandatory.  This option is more
>    useful to retrieve additional or dynamically selected context
>    information.
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 18]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>    Context Request Option is typically used for the reactive (NAR-
>    initiated) fast handover mode to retrieve the context information
>    from the PAR.  When this option is included in the HI message, all
>    the requested context information SHOULD be included in the HAck
>    message in the corresponding mobility option(s) (e.g., HNP, LMAA or
>    MN-IID mobility options).
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +---------------+---------------+---------------+---------------+
>     |   Option-Type  | Option-Length |           Reserved            |
>      +---------------+---------------+-------------------------------+
>     |   Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
>      +---------------------------------------------------------------+
>     |                               ...                              |
>
>   Option-Type    TBD1
>
>    Option-Length  The length in octets of this option, not including the
>                   Option Type and Option Length fields.
>
>    Reserved       This field is unused.  It MUST be initialized to zero
>                   by the sender and MUST be ignored by the receiver.
>
>   Req-type-n     The type value for the n'th requested option.
>
>    Req-length-n   The length of the n'th requested option excluding the
>                   Req-type-n and Req-length-n fields.
>
>    In the case where there are only Req-type-n and Req-length-n fields,
>    the value of the Req-length-n is set to zero.  If additional
>    information besides the Req-type-n is necessary to uniquely specify
>    the requested context, such information follows after the
>    Req-length-n.  For example, when the requested context is the Vendor-
>    Specific Option described in Section 6.2.8, the requested option
>    format looks as follows:
>
>     |                               ...                              |
>      +---------------+---------------+-------------------------------+
>     |  Req-type-N=19 | Req-length-N=5|           Vendor-ID           |
>      +-------------------------------+---------------+---------------+
>     |            Vendor-ID           |   Sub-Type    |               |
>      +-----------------------------------------------+               |
>     |                               ...                              |
>
>    The exact values in the Vendor-ID and Sub-Type are outside the scope
>    of this document.
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 19]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>
>    This option is used to transfer the Local Mobility Anchor IPv6
>    Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is
>    currently registered.  The detailed definition of the LMAA is
>    described in [RFC5213].
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Option-Type  | Option-Length |  Option-Code  |   Reserved    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |               Local Mobility Anchor Address ...                |
>
>   Option-Type    TBD2
>
>   Option-Length  18 or 6
>
>   Option-Code
>
>                  0  Reserved
>
>                  1  IPv6 address of the LMA (LMAA)
>
>                  2  IPv4 address of the LMA (IPv4-LMAA)
>
>    Reserved       This field is unused.  It MUST be initialized to zero
>                   by the sender and MUST be ignored by the receiver.
>
>    Local Mobility Anchor Address
>                   If Option-Code is 1, the LMA IPv6 address (LMAA) is
>                   inserted.  If Option-Code is 2, the LMA IPv4 address
>                   (IPv4-LMA) is inserted.
>
> 6.2.3.  IPv4 Address Option
>
>    As described in Section 4.2, if the MN is IPv4-only mode or dual-
>    stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
>    option has alignment requirement of 4n.
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |  Option-Type   | Option-Length |  Option-Code  |    Reserved   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                       IPv4 Address                             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 20]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
>   Option-Type    TBD3
>
>   Option-Length  6
>
>   Option-Code
>
>                  0  Reserved
>
>                  1  IPv4-MN-HoA
>
>    Reserved       This field is unused.  It MUST be initialized to zero
>                   by the sender and MUST be ignored by the receiver.
>
>   IPv4 Address   IPv4 address specified in Option-Code
>
> 6.2.4.  Home Network Prefix Option
>
>    This option is used to transfer the home network prefix that is
>    assigned to the MN in the P-AN.  The Home Network Prefix Option
>    defined in [RFC5213] is used for this.
>
> 6.2.5.  Mobile Node Interface Identifier (MN IID) Option
>
>    This option is used to transfer the interface identifier of the MN
>    that is used in the P-AN.  The Mobile Node Interface Identifier
>    Option defined in [RFC5213] is used for this.
>
> 6.2.6.  Link-local Address Option
>
>    This option is used to transfer the link-local address of the PAR
>    (PMAG).  The Link-local Address Option defined in [RFC5213] is used
>    for this.
>
> 6.2.7.  GRE Key Option
>
>    This option is used to transfer the GRE Key for the MN's data flow
>    over the bi-directional tunnel between the PAR and NAR.  The message
>    format of this option follows the GRE Key Option defined in [GREKEY].
>    The GRE Key value uniquely identifies each flow and the sender of
>    this option expects to receive packets of the flow from the peer AR
>    with this value.
>
> 6.2.8.  Vendor-Specific Mobility Option
>
>    This option is used to transfer any other information defined in this
>    document.  The format of this option follows the Vendor-Specific
>    Mobility Option defined in [RFC5094].  The exact values in the Vendor
>    ID, Sub-Type and Data fields are outside the scope of this document.
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 21]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 7.  Security Considerations
>
>    Security issues for this document follow those for PMIPv6[RFC5213]
>    and FMIPv6[RFC5268bis].  In PMIPv6, MAG and LMA are assumed to share
>    security association.  In FMIPv6, the access routers (i.e., the PMAG
>    and NMAG in this document) are assumed to share security association.
>    No new security risks are identified.  Support for integrity
>    protection using IPsec is required and confidentiality protection
>    SHOULD be used if sensitive context related to the mobile node is
>    being transferred.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yokota, et al.         Expires September 10, 2009              [Page 22]
>
> Internet-Draft          Proxy-based Fast Handover             March 2009
>
>
> 8.  IANA Considerations
>
>    This document defines two new mobility options, which are described
>    in Section 6.2.  The Type value for these options are assigned from
>    the same numbering space as allocated for the other mobility options,
>    as defined in [RFC3775].
>
>     Mobility Options
>     Value  Description                            Reference
>     -----  -------------------------------------  -------------
>     TBD1   Context Request Option                 Section 6.2.1
>     TBD2   Local Nobility Anchor Address Option   Section 6.2.2
>     TBD3   IPv4 Address Option                    Section 6.2.3
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Rajeev Koodli-4
Hi Sri,

thanks for the detailed review. Some comments inline.

> 1. Too many functional elements. P-AR, PAN, PMAG. What should
> one imply, PAN sending a message to PMAG ? We dont have that
> interface in Proxy Mobile IPv6 and so that interface should
> be hidden. From PMIP perspective, we just have a MAG, LMA,
> MN and events from the network. You may want to get rid of all
> the other jargon or functions. The call flows have to be between
> 3 functional elements.

Tha PAN and NAN are for illustration and completeness. Yes, PAN may
send a message to PMAG, but that is outside the scope of the document.
Having it in the diagram makes it clear as to how the protocol is
used.

>
> 2. The protocol is very loosely specified and is ambiguous
> w.r.t the protocol operation. I'd rewrite Section 4.0,
> which is more an explanation of a call flow, rather than a
> specification one can implement. I'd try to specify it in a
> bit more logical manner. It might be better to specify
> it from the order of sequence of events:

Well, this is not a brand new protocol per se, but an application of
FMIPv6 (RFC 5268bis) to PMIPv6-only networks. So, the call flow makes
sense to show when HI (from RFC 5268bis) is triggered (as an access
network trigger). Agree with you that it needs to be sequenced, and
hence the call flow.

>
>    a.) A new trigger from the network, for MN's attachment to the
>    new link.
>
>       - Specify the MAG operation from both sending/receiving end
>       - Specify the MN states (layer-2, layer-3), before and after
>       - Specify the forwarding rules on both the MAG's
>       - State that LMA is immunte
>       - Cover error cases for HI/HACK failures, MN detachment at
>         any of the links during various stages of this protocol

This looks okay. But, the processing of HI and HAck messages is
described in detail in RFC 5268bis. Perhaps we should cover the deltas
here (?)


>
> 3. The tunnel between the MAG's is a shared tunnel for all
> the mobile flows, I assume ? If so, in most cast cases its
> a predictive mode. Since, the difference here for the
> predictive and reactive mode is just the order of steps
> (#c and #e), may be its better to merge and avoid the text
> duplication.

No, the tunnel is not required to be shared (although it might be
possible to do that with some twists). And, the protocol is not in
most cases predictive. In fact, the eHRPD handovers in X.P0057 (which
is using this protocol) is mostly reactive.


>
> 4. There is very limited text on the encap type or the
> life-cycle management of the tunnel between the MAG's.
> When they come and go.

Something specific here needs to be drawn out. But, otherwise it is
from RFC 5268bis.

>
> 5. When the transport network is IPv4 or IPv6, so the type
> of tunnel and the encap needs to be specified.
>

Why? Deployments will have to handle transport of *all* IPv6 traffic
(including signaling, data) anyway. Wh should there be special
considerations here? I would prefer to leave it out.


> 6. The spec introduces a new security relation between the
> MAG's, which is not there in 5213. This new requirement needs
> to be properly specified. There are just 2 lines in Security
> Considerations, which ideally for covering residual security
> aspects.

Again, please see 5268bis, which describes this in detail. Perhaps we
need to make it clear that this spec re-uses Security, Encapsulation,
Processing (of messages) from 5268bis more clearly.


>
> 7. Buffering requirements at MAG, may be few lines of text might
> help.

Okay.

>
> 8. AP-Id ? Has no relevance in this document. MN-AR is a point to
> point link, the radio link should be hidden from this spec.
>

AP-ID is again for illustrating how the protocol fits in where it is
used. No normative description.

> 9. Section 4.2, if the above structure is followed.
>
> 10. Section 5, 2nd paragraph, assumes MN will perform NUD after
> a handoff. We are getting into the DNA space. MN will perform
> RS/RA and not NUD. Also, NUD takes on average 53 secs to detect
> a neighbor loss, so has no relevance here.

umm.. This is not DNA, but plain ND *when link-layer addresses are
used* (we had a long discussion on the ML on this, and the text simply
reflects that). Yes, MN does RS/RA as well, but it cannot reliably
detect loss of reachability of its default router without NUD. In
other words, it does not switch router just because it saw a new
prefix advertised (based on standard IPv6).

Agree that NUD takes time. The point here is to state that the new
router should be able to accept packets when link-layer addresses are
used.

>
> 11. MN-AN connection establishment: Needs proper explanation on what
> this is. If it is a link-layer setup, or a layer-3 setup. There is
> lot of text in 5213 on the assumption around inter-tech handoff.
> Some pointers to the affect that those assumptions are still valid.

Will look into it.

> Secondly, need to emphasise that after MN-AN connection implies the
> prefix movement from the MN perspective. But, from Fig 3, how can
> this happen in Reactive handoff, where the prefix is not known by
> N-MAG till HI-HACK signaling is complete ?
>

MN continues to think that it can use the assigned HNP. NMAG, e.g.,
cannot sent RA with this HNP until it receives it from PMAG.

> 12. State that how MN-MN traffic is handled at P-MAG and N-MAG, if
> EnableMAGLocalRouting is ON.

This is important to capture. From this spec's point, it is providing
uplink and downlink packet forwarding for an MN during its handover,
regardless of how the traffic is originated. For downlink traffic (to
the MN undergoing handover), PMAG just updates forwarding to point to
NMAG (with encapsulation). For uplink traffic, the NMAG is sending it
back to the PMAG. One thing I see is the lifetime of the PMAG - NMAG
tunnel. When local forwarding is ON, it may need to be longer than
otherwise.

Thanks again for the good review.

-Rajeev

>
> Regards
> Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> 2.  Introduction
>>
>>   Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>>   that does not possess Mobile IPv6 [RFC3775] mobile node
>>   functionality.  A proxy agent in the network performs the mobility
>>   management signaling on behalf of the mobile node.  This model
>>   transparently provides mobility for mobile nodes within a PMIPv6
>>   domain.  Nevertheless, the basic performance of PMIPv6 in terms of
>>   handover latency and packet loss is considered not any different from
>>   that of Mobile IPv6.
>>
>>   Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the
>>   protocol to reduce the handover latency for Mobile IPv6 by allowing a
>>   mobile node to send packets as soon as it detects a new subnet link
>>   and by delivering packets to the mobile node as soon as its
>>   attachment is detected by the new access router.  This document
>>   describes necessary extensions to FMIPv6 for operations in the PMIPv6
>>   domain in order to minimize handover delay and packet loss as well as
>>   to transfer network-resident contexts.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 4]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 3.  Terminology
>>
>>   This document refers to [RFC5213][RFC5268bis][RFC3775] for
>>   terminology.  The following terms and abbreviations are additionally
>>   used in this document.  The reference network is illustrated in
>>   Figure 1.
>>
>>   Access Network (AN):
>>        A network composed of link-layer access devices such as access
>>        points or base stations providing access to the Access Router
>>        (AR) connected to it.
>>
>>   Previous Access Network (P-AN):
>>        The access network to which the MN is attached before handover.
>>
>>   New Access Network (N-AN):
>>        The access network to which the MN is attached after handover.
>>
>>   Previous Mobile Access Gateway (PMAG):
>>        The MAG that manages mobility related signaling for the MN
>>        before handover.  In this document, the MAG and the Access
>>        Router are collocated.
>>
>>   New Mobile Access Gateway (NMAG):
>>        The MAG that manages mobility related signaling for the MN after
>>        handover.  In this document, the MAG and the Access Router (AR)
>>        are collocated.
>>
>>   HO-Initiate:
>>        A generic signaling that indicates the handover of the MN sent
>>        from the P-AN to the PMAG.  While this signaling is dependent on
>>        the access technology, it is assumed that HO-Initiate can carry
>>        the information to identify the MN and to assist the PAR resolve
>>        the NAR (e.g., the new access point or base station to which the
>>        MN is moving).  Detailed definition of this message is outside
>>        the scope of this document.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 5]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>                                  +----------+
>>                                 |    LMA    |
>>                                 | |
>>                                  +----------+
>>                                   /      \
>>                                  /        \
>>                                  /          \
>>                      +........../..+      +..\..........+
>>                      . +-------+-+ .______. +-+-------+ .
>>                      . |   PAR   |()_______)|   NAR   | .
>>                      . |  (PMAG) | .      . |  (NMAG) | .
>>                      . +----+----+ .      . +----+----+ .
>>                      .      |      .      .      |      .
>>                      .   ___|___   .      .   ___|___   .
>>                      .  /       \  .      .  /       \  .
>>                      . (  P-AN   ) .      . (  N-AN   ) .
>>                      .  \_______/  .      .  \_______/  .
>>                      .      |      .      .      |      .
>>                      .   +----+    .      .   +----+    .
>>                      .   | MN |  ---------->  | MN |    .
>>                      .   +----+    .      .   +----+    .
>>                      +.............+      +.............+
>>
>>              Figure 1: Reference network for fast handover
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 6]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 4.  Proxy-based FMIPv6 Protocol Overview
>>
>>   In order to improve the performance during handover (when operations
>>   such as attachment to a new network and signaling between mobility
>>   agents are involved), the PFMIPv6 protocol in this document specifies
>>   a bi-directional tunnel between the Previous MAG (PMAG) and the New
>>   MAG (NMAG).  In order to enable the NMAG to send the Proxy Binding
>>   Update (PBU), the Handover Initiate (HI) and Handover Acknowledge
>>   (HAck) messages in [RFC5268bis] are used for context transfer, in
>>   which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4
>>   Home Address, are transferred from the PMAG.
>>
>>   In this document, the Previous Access Router (PAR) and New Access
>>   Router (NAR) are interchangeable with the PMAG and NMAG,
>>   respectively.
>>
>>   Since a MN is not directly involved with IP mobility protocol
>>   operations, it follows that the MN is not directly involved with fast
>>   handover procedures either.  Hence, the messages involving the MN in
>>   [RFC5268bis] are not used when PMIPv6 is in use.  Such messages are
>>   the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy
>>   Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast
>>   Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement
>>   (UNA).
>>
>> 4.1.  Protocol Operation
>>
>>   There are two modes of operation in FMIPv6 [RFC5268bis].  In the
>>   predictive mode of fast handover, a bi-directional tunnel between the
>>   PAR and NAR is established prior to the MN's attachment to the NAR.
>>   In the reactive mode, this tunnel establishment takes place after the
>>   MN attaches to the NAR.  Since the MN is not involved in IP mobility
>>   signaling in PMIPv6, the sequence of events illustrating the
>>   predictive fast handover are shown in Figure 2.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 7]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>                                            PMAG        NMAG
>>          MN         P-AN       N-AN        (PAR)       (NAR)     LMA
>>         | | | | | |
>>         |   Report   |          |            |           |        |
>>     (a)  |-(MN ID,-->|          |            |           |        |
>>         |  New AP ID)|          |            |           |        |
>>         | |      HO Initiate       |           |        |
>>     (b)  |           |--(MN ID, New AP ID)-->|           |        |
>>         | | | | | |
>>         | | | |     HI     |        |
>>     (c)  |           |          |            |-(MN ID, ->|        |
>>         | | | |  MN IID, LMAA)      |
>>         | | | | | |
>>     (d)  |           |          |            |<---HAck---|        |
>>         | | | |   (MN ID)  |        |
>>         | | | | | |
>>         | | | | HI/HAck(optional)   |
>>    (e)  |           |          |            |<- - - - ->|        |
>>         | | |           #=|<===================|
>>     (f)  |           |          |          #====DL data=>|        |
>>         | | | | | |
>>     (g) ~~~          |          |            |           |        |
>>        ~ ~ ~ | | | | |
>>         |    MN-AN connection   |    AN-MAG connection   |        |
>>     (h)  |<---establishment---->|<----establishment----->|        |
>>         | | |   (substitute for UNA)  |        |
>>         | | | | | |
>>     (i)  |<==================DL data=====================|<=======|
>>         | | | | | |
>>    (j)  |===================UL data====================>|=#      |
>>         | | | # =|<============#      |
>>         | | | # =====================>|
>>     /    |           |          |            |           |        | \
>>    | (k) |           |          |            |           |--PBU-->| |
>>    | | | | | | | |
>>    | (l) |           |          |            |           |<--PBA--| |
>>     \    |           |          |            |           |        | /
>>
>>      Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
>>
>>  The detailed descriptions are as follows:
>>
>>   (a)  The MN detects that a handover is imminent and reports the
>>        identifications of itself (MN ID) and the access point (New AP
>>        ID) to which the MN is most likely to move.  The MN ID could be
>>        the NAI or a Link Layer Address (LLA), or any other suitable
>>        identifier.  This step is access technology specific.  In some
>>        cases, the P-AN will determine which AP ID the MN is moving to.
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 8]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>   (b)  The previous access network (P-AN), to which the MN is currently
>>        attached, indicates the handover of the MN to the PAR (PMAG).
>>        Detailed definition and specification of this message are
>>        outside the scope of this document.
>>
>>   (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>>        the MN ID and SHOULD include the MN-HNP, the MN-IID and the
>>        address of the LMA that is currently serving the MN.
>>
>>  (d)  The NAR sends the HAck back to the PAR.
>>
>>   (e)  If it is preferred that the timing of buffering or forwarding
>>        should be later than step (c), the NAR may optionally request
>>        the PAR at a later and appropriate time to buffer or forward
>>        packets by setting U or F flags in the HI message, respectively.
>>
>>   (f)  If the F flag is set in the previous step, a bi-directional
>>        tunnel is established between the PAR and NAR and packets
>>        destined for the MN are forwarded from the PAR to the NAR over
>>        this tunnel.  After decapsulation, those packets may be buffered
>>        at the NAR.  If the connection between the N-AN and NAR has
>>        already been established, those packet may be forwarded towards
>>        the N-AN; this is access technology specific.
>>
>>  (g)  The MN undergoes handover to the New Access Network (N-AN).
>>
>>   (h)  The MN establishes a connection (e.g., radio channel) with the
>>        N-AN, which in turn triggers the establishment of the connection
>>        between the N-AN and NAR if it has not been established already
>>        (access technology specific).  This can be regarded as a
>>        substitute for the UNA.
>>
>>   (i)  The NAR starts to forward packets destined for the MN via the
>>        N-AN.
>>
>>   (j)  The uplink packets from the MN are sent to the NAR via the N-AN
>>        and the NAR forwards them to the PAR.  The PAR then sends the
>>        packets to the LMA that is currently serving the MN.
>>
>>   (k)  The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
>>        whose address is provided in (c).  Steps (k) and (l) are not
>>        part of the fast handover procedure, but shown for reference.
>>
>>   (l)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
>>        NAR (NMAG).  From this time on, the packets to/from the MN go
>>        through the NAR instead of the PAR.
>>
>>  According to Section 4 of [RFC5268bis], the PAR establishes a binding
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009               [Page 9]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>   between the PCoA and NCoA to forward packets for the MN to the NAR,
>>   and the NAR creates a proxy NCE to receive those packets for the NCoA
>>   before the MN arrives.  In the case of PMIPv6, however, the only
>>   address that is used by the MN is MN-HoA.  Hence the PAR forwards
>>   MN's packets to the NAR instead of the NCoA.  FMIPv4 [RFC4988]
>>   specifies forwarding when the MN uses HoA as its on-link address
>>   rather than the care-of address.  The usage in PMIPv6 is similar to
>>   that in FMIPv4, where the address is used by the MN is based on Home
>>   Network Prefix.  Hence the PAR forwards MN's packets to the NAR
>>   instead of the NCoA.  The NAR then simply decapsulates those packets
>>   and delivers them to the MN.  Since the NAR obtains the LLA (MN IID)
>>   and MN-HNP by the HI, it can create the NCE for the MN and deliver
>>   packets to it even before the MN can perform Neighbor Discovery.  For
>>   the uplink packets from the MN after handover in (j), the NAR
>>   forwards the packets to the PAR through the tunnel established in
>>   step (f).  The PAR then decapsulates and sends them to the LMA.
>>
>>   The timing of the context transfer and that of packet forwarding may
>>   be different.  Thus, a new flag 'F' and the Option Code values for it
>>   in the HI message are defined to request forwarding.  To request
>>   buffering, 'U' flag has already been defined in [RFC5268bis].  If the
>>   PAR receives the HI message with F flag set and the Option Code value
>>   being 2, it starts forwarding packets for the MN.  The HI message
>>   with U flag set may be sent earlier if the timing of buffering is
>>   different from that of forwarding.  If packet forwarding is
>>   completed, the PAR MAY send the HI message with F flag set and the
>>   Option Code value being 3.  By this message, the ARs on both ends can
>>   tear down the forwarding tunnel synchronously.
>>
>>   The IP addresses in the headers of those user packets are summarized
>>   below:
>>
>>  In (f),
>>
>>       Inner source address: IP address of the CN
>>
>>       Inner destination address: HNP or IPv4-MN-HoA
>>
>>       Outer source address: IP address of the PAR (PMAG)
>>
>>       Outer destination address: IP address of the NAR (NMAG)
>>
>>  In (i),
>>
>>       Source address: IP address of the CN
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 10]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>       Destination address: HNP or IPv4-MN-HoA
>>
>>  In (j),
>>
>>  - from the MN to the NMAG,
>>
>>       Source address: HNP or IPv4-MN-HoA
>>
>>       Destination address: IP address of the CN
>>
>>  - from the NMAG to the PMAG,
>>
>>       Inner source address: HNP or IPv4-MN-HoA
>>
>>       Inner destination address: IP address of the CN
>>
>>       Outer source address: IP address of the NAR (NMAG)
>>
>>       Outer destination address: IP address of the PAR (PMAG)
>>
>>  - from the PMAG to the LMA,
>>
>>       Inner source address: HNP or IPv4-MN-HoA
>>
>>       Inner destination address: IP address of the CN
>>
>>       Outer source address: IP address of the PAR (PMAG)
>>
>>       Outer destination address: IP address of the LMA
>>
>>   In the case of the reactive handover for PMIPv6, since the MN does
>>   not send either the FBU or UNA, it would be more natural that the NAR
>>   sends the HI to the PAR after the MN has moved to the new link.  The
>>   NAR then needs to obtain the information of the PAR beforehand.  Such
>>   information could be provided, for example, by the MN sending the
>>   AP-ID on the old link and/or by the lower-layer procedures between
>>   the P-AN and N-AN.  The exact method is not specified in this
>>   document.  Figure 3 illustrates the reactive fast handover procedures
>>   for PMIPv6, where the bi-directional tunnel establishment is
>>   initiated by the NAR.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 11]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>                                         PMAG            NMAG
>>          MN       P-AN      N-AN        (PAR)           (NAR)     LMA
>>         | | | | | |
>>     (a) ~~~        |         |            |               |        |
>>        ~ ~ ~ | | | | |
>>         |   MN-AN connection |       AN-MAG connection    |        |
>>     (b)  |<--establishment-->|<-------establishment------>|        |
>>         | (MN ID, Old AP ID) |     (MN ID, Old AP ID)     |        |
>>         | | | (substitute for UNA and FBU)|        |
>>         | | | | | |
>>         | | | |       HI       |        |
>>     (c)  |         |         |            |<---(MN ID) ---|        |
>>         | | | | | |
>>         | | | |      HAck      |        |
>>     (d)  |         |         |            |---(MN ID, --->|        |
>>         | | | |  MN IID, LMAA) |        |
>>         | | | | | |
>>    (e)  |         |         |          #=|<=======================|
>>         | | |           #================>|=#      |
>>         | <====================DL data======================#      |
>>         | | | | | |
>>    (f)  |=====================UL data===================>|=#      |
>>         | | | # =|<================#      |
>>         | | | # =========================>|
>>         | | | | | |
>>     /    |         |         |            |               |        | \
>>    | (g) |         |         |            |               |--PBU-->| |
>>    | | | | | | | |
>>    | (h) |         |         |            |               |<--PBA--| |
>>     \    |         |         |            |               |        | /
>>
>>       Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
>>
>>  The detailed descriptions are as follows:
>>
>>   (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
>>        on the old link may be provided by the MN to help identify the
>>        PMAG on the new link.
>>
>>   (b)  The MN establishes a connection (e.g., radio channel) with the
>>        N-AN, which triggers the establishment of the connection between
>>        the N-AN and NAR.  The MN ID is transferred to the NAR for the
>>        subsequent procedures.  The AP-ID on the old link may also be
>>        provided by the MN to help identify the PMAG on the new link.
>>        This can be regarded as a substitute for the UNA and FBU.
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 12]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>   (c)  The NAR sends the HI to the PAR.  The HI message MUST include
>>        the MN ID.  The Context Request Option MAY be included to
>>        request additional context information on the MN to the PAR.
>>
>>   (d)  The PAR sends the HAck back to the NAR.  The HAck message MUST
>>        include the HNP and/or IPv4-MN-HoA that is corresponding to the
>>        MN ID in the HI message and SHOULD include the MN-IID and the
>>        LMA address that is currently serving the MN.  The context
>>        information requested by the NAR MUST be included.
>>
>>   (e)  If F flag in the HI is set, a bi-directional tunnel is
>>        established between the PAR and NAR and packets destined for the
>>        MN are forwarded from the PAR to the NAR over this tunnel.
>>        After decapsulation, those packets are delivered to the MN via
>>        the N-AN.
>>
>>   (f)  The uplink packets from the MN are sent to the NAR via the N-AN
>>        and the NAR forwards them to the PAR.  The PAR then sends the
>>        packets to the LMA that is currently serving the MN.
>>
>>   Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover
>>   procedures.
>>
>>   In step (c), The IP address of the PAR needs to be resolved by the
>>   NAR to send the HI to the PAR.  This information may come from the
>>   N-AN or some database that the NAR can access.
>>
>> 4.2.  IPv4 Support Considerations
>>
>>   The motivation and usage scenarios of IPv4 protocol support by PMIPv6
>>   are described in [IPv4PMIPv6].  The scope of IPv4 support covers the
>>   following two features:
>>
>>  o  IPv4 Home Address Mobility Support, and
>>
>>  o  IPv4 Transport Support.
>>
>>   As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
>>   Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
>>   transfer IPv4-MN-HoA to the NMAG, which is the inner destination
>>   address of the packets forwarded on the downlink.  In order to
>>   support IPv4-MN-HoA, a new option called IPv4 Address Option is
>>   defined in this document.  In order to provide IPv4 Transport
>>   Support, the NMAG needs to know the IPv4 address of the LMA (IPv4-
>>   LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4
>>   transport network.  The above IPv4 Address Option is defined so as to
>>   be able to convey IPv4-LMAA.  The details of this option are
>>   described in [IPv4PMIPv6].
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 13]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 5.  Other Considerations
>>
>>   The protocol specified in this document enables the NMAG to obtain
>>   parameters which would otherwise be available only by communicating
>>   with the LMA.  For instance, the HNP and/or IPv4-MN-HoA of a MN are
>>   made available to the NMAG through context transfer.  This allows the
>>   NMAG to perform some procedures which may be beneficial.  For
>>   instance, the NMAG could send a Router Advertisement (RA) with the
>>   HNP option to the MN as soon as it's link attachment is detected
>>   (e.g., via receipt of a Router Solicitation message).  Such an RA is
>>   recommended, for example, in scenarios where the MN uses a new radio
>>   interface while attaching to the NMAG; since the MN does not have
>>   information regarding the new interface, it will not be able to
>>   immediately send packets without first receiving an RA with HNP.
>>   However, if the subsequent PMIPv6 binding registration for the HNP
>>   fails for some reason, then the NMAG MUST withdraw the advertised HNP
>>   by sending another RA with zero prefix lifetime for the HNP in
>>   question.  This operation is the same as that described in Section
>>   6.12 of [RFC5213].
>>
>>   The protocol specified in this document is applicable regardless of
>>   whether link-layer addresses are used between a MN and its access
>>   router.  A MN should be able to continue sending packets on the
>>   uplink even when it changes link.  When link-layer addresses are
>>   used, the MN performs Neighbor Unreachability Detection (NUD)
>>   [RFC4861], after attaching to a new link, probing the reachability of
>>   its default router.  If the new router's interface is configured to
>>   respond to queries sent to link-layer addresses than its own (e.g.,
>>   set to promiscuous mode), then it can respond to the NUD probe,
>>   providing its link-layer address in the solicited Neighbor
>>   Advertisement.  While the MN is performing NUD, it can continue to
>>   send uplink packets.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 14]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 6.  Message Formats
>>
>>   This document defines new Mobility Header messages for the extended
>>   HI and Hack and new mobility options for conveying context
>>   information.
>>
>> 6.1.  Mobility Header
>>
>> 6.1.1.  Handover Initiate (HI)
>>
>>   This section defines extensions to the HI message in [RFC5268bis].
>>   The format of the Message Data field in the Mobility Header is as
>>   follows:
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                     +-------------------------------+
>>                                    |            Sequence #          |
>>    +-+-+-+-----------+-------------+-------------------------------+
>>    | S|U|F|  Reserved |     Code    |                               |
>>     +-+-+-+-----------+-------------+                               |
>>    | |
>>     .                                                               .
>>     .                       Mobility options                        .
>>     .                                                               .
>>    | |
>>     +---------------------------------------------------------------+
>>
>>  IP Fields:
>>
>>  Source Address
>>
>>                      The IP address of PMAG or NMAG
>>
>>  Destination Address
>>
>>                      The IP address of the peer MAG
>>
>>  Message Data:
>>
>>  Sequence #  Same as [RFC5268bis].
>>
>>   S flag      Defined in [RFC5268bis] and MUST be set to zero in this
>>               specification.
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 15]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>  U flag      Buffer flag.  Same as [RFC5268bis].
>>
>>   F flag      Forwarding flag.  Used to request to forward the packets
>>               for the MN.
>>
>>  Reserved    Same as [RFC5268bis].
>>
>>   Code        [RFC5268bis] defines this field and its values 0 and 1.
>>               In this specification, if F flag is not set, this field
>>               MUST be set to zero.  Otherwise, it has the following
>>               meaning:
>>
>>                        2: Forwarding is not requested
>>
>>                        3: Request forwarding
>>
>>                        4: Indicate the completion of forwarding
>>
>>  Mobility options:
>>
>>   This field contains one or more mobility options, whose encoding and
>>   formats are defined in [RFC3775].  At least one mobility option MUST
>>   uniquely identify the target MN (e.g., the Mobile Node Identifier
>>   Option defined in RFC4283) and the transferred context MUST be for
>>   one MN per message.  In addition, the NAR can request necessary
>>   mobility options by the Context Request Option defined in this
>>   document.
>>
>>  Context Request Option
>>
>>            This option MAY be present to request context information
>>            typically by the NAR to the PAR in the NAR-initiated fast
>>            handover.
>>
>> 6.1.2.  Handover Acknowledge (HAck)
>>
>>   This section defines extensions to the HAck message in[RFC5268bis].
>>   The format of the Message Data field in the Mobility Header is as
>>   follows:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 16]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                     +-------------------------------+
>>                                    |            Sequence #          |
>>    +-+-+-----------+---------------+-------------------------------+
>>    | U|F| Reserved  |     Code      |                               |
>>     +-+-+-----------+---------------+                               |
>>    | |
>>     .                                                               .
>>     .                       Mobility options                        .
>>     .                                                               .
>>    | |
>>     +---------------------------------------------------------------+
>>
>>  IP Fields:
>>
>>  Source Address
>>
>>                       Copied from the destination address of the
>>                       Handover Initiate message to which this message
>>                       is a response.
>>
>>  Destination Address
>>
>>                       Copied from the source address of the Handover
>>                       Initiate message to which this message is a
>>                       response.
>>
>>  Message Data:
>>
>>   The usages of Sequence # and Reserved fields are exactly the same as
>>   those in [RFC5268bis].
>>
>>  U, F flags  Same as defined in Section 6.1.1.
>>
>>   Code
>>               Code values 0 through 4 and 128 through 130 are defined
>>               in [RFC5268bis].  In this specification, the meaning of
>>               Code value 0 is modified, 128 through 130 are reused, and
>>               5, 6, 131 and 132 are newly defined.
>>
>>                      0: Handover Accepted
>>
>>                      5: Context Transfer Successful or Accepted
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 17]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>                      6: All available Context Transferred
>>
>>                      128: Handover Not Accepted, reason unspecified
>>
>>                      129: Administratively prohibited
>>
>>                      130: Insufficient resources
>>
>>                      131: Requested Context Not Available
>>
>>                      132: Forwarding Not Available
>>
>>  Mobility options:
>>
>>   This field contains one or more mobility options, whose encoding and
>>   formats are defined in [RFC3775].  The mobility option that uniquely
>>   identifies the target MN MUST be copied from the corresponding HI
>>   message and the transferred context MUST be for one MN per message.
>>
>>   Requested option(s)  All the context information requested by the
>>             Context Request Option in the HI message SHOULD be present
>>             in the HAck message.  The other cases are described below.
>>
>>   In the case of the PAR-initiated fast handover, when the PAR sends
>>   the HI message to the NAR with the context information and the NAR
>>   successfully receives it, the NAR returns the HAck message with Code
>>   value 5.  In the case of the NAR-initiated fast handover, when the
>>   NAR sends the HI message to the PAR with or without Context Request
>>   Option, the PAR returns the HAck message with the requested or
>>   default context information (if any).  If all available context
>>   information is transferred, the PAR sets the Code value in the HAck
>>   message to 6.  If more context information is available, the PAR sets
>>   the Code value in the HAck to 5 and the NAR MAY send new HI
>>   message(s) to retrieve the rest of the available context information.
>>   If none of the requested context information is available, the PAR
>>   returns the HAck message with Code value 131 without any context
>>   information.
>>
>> 6.2.  Mobility Options
>>
>> 6.2.1.  Context Request Option
>>
>>   This option is sent in the HI message to request context information
>>   on the MN.  If a default set of context information is defined and
>>   always sufficient, this option is not mandatory.  This option is more
>>   useful to retrieve additional or dynamically selected context
>>   information.
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 18]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>   Context Request Option is typically used for the reactive (NAR-
>>   initiated) fast handover mode to retrieve the context information
>>   from the PAR.  When this option is included in the HI message, all
>>   the requested context information SHOULD be included in the HAck
>>   message in the corresponding mobility option(s) (e.g., HNP, LMAA or
>>   MN-IID mobility options).
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +---------------+---------------+---------------+---------------+
>>    |   Option-Type  | Option-Length |           Reserved            |
>>     +---------------+---------------+-------------------------------+
>>    |   Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
>>     +---------------------------------------------------------------+
>>    |                               ...                              |
>>
>>  Option-Type    TBD1
>>
>>   Option-Length  The length in octets of this option, not including the
>>                  Option Type and Option Length fields.
>>
>>   Reserved       This field is unused.  It MUST be initialized to zero
>>                  by the sender and MUST be ignored by the receiver.
>>
>>  Req-type-n     The type value for the n'th requested option.
>>
>>   Req-length-n   The length of the n'th requested option excluding the
>>                  Req-type-n and Req-length-n fields.
>>
>>   In the case where there are only Req-type-n and Req-length-n fields,
>>   the value of the Req-length-n is set to zero.  If additional
>>   information besides the Req-type-n is necessary to uniquely specify
>>   the requested context, such information follows after the
>>   Req-length-n.  For example, when the requested context is the Vendor-
>>   Specific Option described in Section 6.2.8, the requested option
>>   format looks as follows:
>>
>>    |                               ...                              |
>>     +---------------+---------------+-------------------------------+
>>    |  Req-type-N=19 | Req-length-N=5|           Vendor-ID           |
>>     +-------------------------------+---------------+---------------+
>>    |            Vendor-ID           |   Sub-Type    |               |
>>     +-----------------------------------------------+               |
>>    |                               ...                              |
>>
>>   The exact values in the Vendor-ID and Sub-Type are outside the scope
>>   of this document.
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 19]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>
>>   This option is used to transfer the Local Mobility Anchor IPv6
>>   Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is
>>   currently registered.  The detailed definition of the LMAA is
>>   described in [RFC5213].
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |   Option-Type  | Option-Length |  Option-Code  |   Reserved    |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |               Local Mobility Anchor Address ...                |
>>
>>  Option-Type    TBD2
>>
>>  Option-Length  18 or 6
>>
>>  Option-Code
>>
>>                 0  Reserved
>>
>>                 1  IPv6 address of the LMA (LMAA)
>>
>>                 2  IPv4 address of the LMA (IPv4-LMAA)
>>
>>   Reserved       This field is unused.  It MUST be initialized to zero
>>                  by the sender and MUST be ignored by the receiver.
>>
>>   Local Mobility Anchor Address
>>                  If Option-Code is 1, the LMA IPv6 address (LMAA) is
>>                  inserted.  If Option-Code is 2, the LMA IPv4 address
>>                  (IPv4-LMA) is inserted.
>>
>> 6.2.3.  IPv4 Address Option
>>
>>   As described in Section 4.2, if the MN is IPv4-only mode or dual-
>>   stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
>>   option has alignment requirement of 4n.
>>
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Option-Type   | Option-Length |  Option-Code  |    Reserved   |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                       IPv4 Address                             |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 20]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>>  Option-Type    TBD3
>>
>>  Option-Length  6
>>
>>  Option-Code
>>
>>                 0  Reserved
>>
>>                 1  IPv4-MN-HoA
>>
>>   Reserved       This field is unused.  It MUST be initialized to zero
>>                  by the sender and MUST be ignored by the receiver.
>>
>>  IPv4 Address   IPv4 address specified in Option-Code
>>
>> 6.2.4.  Home Network Prefix Option
>>
>>   This option is used to transfer the home network prefix that is
>>   assigned to the MN in the P-AN.  The Home Network Prefix Option
>>   defined in [RFC5213] is used for this.
>>
>> 6.2.5.  Mobile Node Interface Identifier (MN IID) Option
>>
>>   This option is used to transfer the interface identifier of the MN
>>   that is used in the P-AN.  The Mobile Node Interface Identifier
>>   Option defined in [RFC5213] is used for this.
>>
>> 6.2.6.  Link-local Address Option
>>
>>   This option is used to transfer the link-local address of the PAR
>>   (PMAG).  The Link-local Address Option defined in [RFC5213] is used
>>   for this.
>>
>> 6.2.7.  GRE Key Option
>>
>>   This option is used to transfer the GRE Key for the MN's data flow
>>   over the bi-directional tunnel between the PAR and NAR.  The message
>>   format of this option follows the GRE Key Option defined in [GREKEY].
>>   The GRE Key value uniquely identifies each flow and the sender of
>>   this option expects to receive packets of the flow from the peer AR
>>   with this value.
>>
>> 6.2.8.  Vendor-Specific Mobility Option
>>
>>   This option is used to transfer any other information defined in this
>>   document.  The format of this option follows the Vendor-Specific
>>   Mobility Option defined in [RFC5094].  The exact values in the Vendor
>>   ID, Sub-Type and Data fields are outside the scope of this document.
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 21]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 7.  Security Considerations
>>
>>   Security issues for this document follow those for PMIPv6[RFC5213]
>>   and FMIPv6[RFC5268bis].  In PMIPv6, MAG and LMA are assumed to share
>>   security association.  In FMIPv6, the access routers (i.e., the PMAG
>>   and NMAG in this document) are assumed to share security association.
>>   No new security risks are identified.  Support for integrity
>>   protection using IPsec is required and confidentiality protection
>>   SHOULD be used if sensitive context related to the mobile node is
>>   being transferred.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yokota, et al.         Expires September 10, 2009              [Page 22]
>>
>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>
>>
>> 8.  IANA Considerations
>>
>>   This document defines two new mobility options, which are described
>>   in Section 6.2.  The Type value for these options are assigned from
>>   the same numbering space as allocated for the other mobility options,
>>   as defined in [RFC3775].
>>
>>    Mobility Options
>>    Value  Description                            Reference
>>    -----  -------------------------------------  -------------
>>    TBD1   Context Request Option                 Section 6.2.1
>>    TBD2   Local Nobility Anchor Address Option   Section 6.2.2
>>    TBD3   IPv4 Address Option                    Section 6.2.3
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
>
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Sri Gundavelli (sgundave)

Hi Rajeev,


On Sat, 4 Apr 2009, Rajeev Koodli wrote:

>>
>> 3. The tunnel between the MAG's is a shared tunnel for all
>> the mobile flows, I assume ? If so, in most cast cases its
>> a predictive mode. Since, the difference here for the
>> predictive and reactive mode is just the order of steps
>> (#c and #e), may be its better to merge and avoid the text
>> duplication.
>
> No, the tunnel is not required to be shared (although it might be
> possible to do that with some twists). And, the protocol is not in
> most cases predictive. In fact, the eHRPD handovers in X.P0057 (which
> is using this protocol) is mostly reactive.
>

Assuming the tunnel type is IPv6-over-IPv6, in all cases the
tunnel is identified by tunnel src, tunnel dst, encap type.
Logically, there is only one tunnel. I've no semantics to
differentiate from one tunnel to the other, unless we are using
a GRE encap with the key seq number extension.

On that note, I dont see any extensions to the conceptual data
structures to support this feature.



>
>>
>> 4. There is very limited text on the encap type or the
>> life-cycle management of the tunnel between the MAG's.
>> When they come and go.
>
> Something specific here needs to be drawn out. But, otherwise it is
> from RFC 5268bis.
>

Looking at 5268bis or from this spec, its not clear what is this
tunnel, encap type, transport addresses. 5268bis just requires
"a tunnel". It needs to be stated if this is a GRE tunnel or IPv6-IPv6
tunnel or a L2TP tunnel, offcourse I know its IPv6-IPv6. There is
no reference to 2473 in either of the specs.



>>
>> 5. When the transport network is IPv4 or IPv6, so the type
>> of tunnel and the encap needs to be specified.
>>
>
> Why? Deployments will have to handle transport of *all* IPv6 traffic
> (including signaling, data) anyway. Wh should there be special
> considerations here? I would prefer to leave it out.
>

Proxy Mobile IPv6 allows the transport network to be IPv4 only. Now,
this implies the two MAG's are reachable over IPv4 network, the
tunnel type can be now, IPv6-over-IPv4, IPv6-over-IPv4-UDP ...
This needs to be specified, on the assumed tunnel type under each
consideration. This is again not present in 5268 or in this spec.


>
>> 6. The spec introduces a new security relation between the
>> MAG's, which is not there in 5213. This new requirement needs
>> to be properly specified. There are just 2 lines in Security
>> Considerations, which ideally for covering residual security
>> aspects.
>
> Again, please see 5268bis, which describes this in detail. Perhaps we
> need to make it clear that this spec re-uses Security, Encapsulation,
> Processing (of messages) from 5268bis more clearly.
>

If we read 5268bis and 5213 independantly, its hard to guess that
requirement for this spec. Since, the operating environment is bound by
5213, it might help re-stating the MAG to MAG security requirements,
or simple pointers to 5268.


>> 9. Section 4.2, if the above structure is followed.
>>
>> 10. Section 5, 2nd paragraph, assumes MN will perform NUD after
>> a handoff. We are getting into the DNA space. MN will perform
>> RS/RA and not NUD. Also, NUD takes on average 53 secs to detect
>> a neighbor loss, so has no relevance here.
>
> umm.. This is not DNA, but plain ND *when link-layer addresses are
> used* (we had a long discussion on the ML on this, and the text simply
> reflects that). Yes, MN does RS/RA as well, but it cannot reliably
> detect loss of reachability of its default router without NUD. In
> other words, it does not switch router just because it saw a new
> prefix advertised (based on standard IPv6).
>
> Agree that NUD takes time. The point here is to state that the new
> router should be able to accept packets when link-layer addresses are
> used.
>


In Proxy Mobile IPv6, we required the link-layer and the link-local
address of all the MAG's on the p2p link to the mobile to be a fixed
address. So, the mobile node does not have to detect a new
default-router after each handoff. Thus spec is bound to this
requirement, or, is this spec changing that requirement ?

Also, given the slow NUD process, its practically un usable.



Sri
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Rajeev Koodli-4
Hi Sri,

I will see how to clarify the tunnel usage. Remaining comments:


On Sun, Apr 5, 2009 at 11:27 AM, Sri Gundavelli <[hidden email]> wrote:

>>
>>> 6. The spec introduces a new security relation between the
>>> MAG's, which is not there in 5213. This new requirement needs
>>> to be properly specified. There are just 2 lines in Security
>>> Considerations, which ideally for covering residual security
>>> aspects.
>>
>> Again, please see 5268bis, which describes this in detail. Perhaps we
>> need to make it clear that this spec re-uses Security, Encapsulation,
>> Processing (of messages) from 5268bis more clearly.
>>
>
> If we read 5268bis and 5213 independantly, its hard to guess that
> requirement for this spec. Since, the operating environment is bound by
> 5213, it might help re-stating the MAG to MAG security requirements,
> or simple pointers to 5268.
>

Sure, we can state clearly that MAG - MAG security is specified in 5268.

>>
>> Agree that NUD takes time. The point here is to state that the new
>> router should be able to accept packets when link-layer addresses are
>> used.
>>
>
>
> In Proxy Mobile IPv6, we required the link-layer and the link-local
> address of all the MAG's on the p2p link to the mobile to be a fixed
> address. So, the mobile node does not have to detect a new
> default-router after each handoff. Thus spec is bound to this
> requirement, or, is this spec changing that requirement ?
>

The protocol operates in a PMIP6 environment, which means the MN
should not detect a router change.

The text is about when link-layer addresses are used. If PMIPv6
already specifies that the new MAG must be able to accept packets sent
to the link-layer address of the old MAG, then I don't see an issue
here.

> Also, given the slow NUD process, its practically un usable.
>

Oh, we are not proposing to use NUD here :-)

Thanks,

-Rajeev

>
>
> Sri
>
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Hidetoshi Yokota
Hi Sri and Rajeev,

Apologize for the late response. Please see inline:

Rajeev Koodli wrote:

> Hi Sri,
>
> I will see how to clarify the tunnel usage. Remaining comments:
>
>
> On Sun, Apr 5, 2009 at 11:27 AM, Sri Gundavelli <[hidden email]> wrote:
>>>> 6. The spec introduces a new security relation between the
>>>> MAG's, which is not there in 5213. This new requirement needs
>>>> to be properly specified. There are just 2 lines in Security
>>>> Considerations, which ideally for covering residual security
>>>> aspects.
>>> Again, please see 5268bis, which describes this in detail. Perhaps we
>>> need to make it clear that this spec re-uses Security, Encapsulation,
>>> Processing (of messages) from 5268bis more clearly.
>>>
>> If we read 5268bis and 5213 independantly, its hard to guess that
>> requirement for this spec. Since, the operating environment is bound by
>> 5213, it might help re-stating the MAG to MAG security requirements,
>> or simple pointers to 5268.
>>
>
> Sure, we can state clearly that MAG - MAG security is specified in 5268.

The latest version (tentative -04), which captured Raj's comments and
was posted yesterday, has the following text:

---
7.  Security Considerations

   Security issues for this document follow those for PMIPv6 [RFC5213]
   and FMIPv6 [RFC5268bis].  In PMIPv6, the MAG and LMA are assumed to
   share security associations.  In FMIPv6, the access routers (i.e.,
   the PMAG and NMAG in this document) are assumed to share security
   associations.

   The Handover Initiate (HI) and Handover Acknowledgement (HAck)
   messages exchanged between the PMAG and NMAG MUST be protected using
   end-to-end security association(s) offering integrity and data origin
   authentication.  The PMAG and the NMAG MUST implement IPsec [RFC4301]
   for protecting the HI and HAck messages.  IPsec Encapsulating
   Security Payload (ESP) [RFC4303] in transport mode with mandatory
   integrity protection SHOULD be used for protecting the signaling
   messages.  Confidentiality protection SHOULD be used if sensitive
   context related to the mobile node is transferred.

   IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's
   packets at the time of forwarding if protection of data traffic is
   required.
---

The above basically follows the guidelines in RFC5213 and RFC5268bis,
but the major difference is that the support of confidentiality for
HI/HAck is "SHOULD" rather than "not necessary", which is based on
Vijay's comment. Is the above enough?

>>> Agree that NUD takes time. The point here is to state that the new
>>> router should be able to accept packets when link-layer addresses are
>>> used.
>>>
>>
>> In Proxy Mobile IPv6, we required the link-layer and the link-local
>> address of all the MAG's on the p2p link to the mobile to be a fixed
>> address. So, the mobile node does not have to detect a new
>> default-router after each handoff. Thus spec is bound to this
>> requirement, or, is this spec changing that requirement ?
>>
>
> The protocol operates in a PMIP6 environment, which means the MN
> should not detect a router change.
>
> The text is about when link-layer addresses are used. If PMIPv6
> already specifies that the new MAG must be able to accept packets sent
> to the link-layer address of the old MAG, then I don't see an issue
> here.
>
>> Also, given the slow NUD process, its practically un usable.
>>
>
> Oh, we are not proposing to use NUD here :-)

But we cannot always assume that the MN supports DNA. What this section
says is even if the MN goes into RFC4861-based NUD process, it should be
able to keep sending and receiving packets and the NMAG should also
respond to a query from the MN as best it can. So, this is sort of a
guideline for the MN and MAG behaviors.

Of course, we can mention DNA here if it will help.

Regards,
--
Hidetoshi

> Thanks,
>
> -Rajeev
>
>>
>> Sri
>>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
>
>
>

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Hidetoshi Yokota
In reply to this post by Rajeev Koodli-4
Hi Sri and Rajeev,

Many thanks to Sri for the detailed review.

Rajeev Koodli wrote:

> Hi Sri,
>
> thanks for the detailed review. Some comments inline.
>
>> 1. Too many functional elements. P-AR, PAN, PMAG. What should
>> one imply, PAN sending a message to PMAG ? We dont have that
>> interface in Proxy Mobile IPv6 and so that interface should
>> be hidden. From PMIP perspective, we just have a MAG, LMA,
>> MN and events from the network. You may want to get rid of all
>> the other jargon or functions. The call flows have to be between
>> 3 functional elements.
>
> Tha PAN and NAN are for illustration and completeness. Yes, PAN may
> send a message to PMAG, but that is outside the scope of the document.
> Having it in the diagram makes it clear as to how the protocol is
> used.

We have received a lot of questions about how PMAG or NMAG detects MN's
handover in such a timely manner. We always answer them saying one
possible approach is to get necessary information and trigger from the
access network. By illustrating ANs in the figure and call flows, we can
disambiguate what triggers the fast handover process. But at the same
time, we try to generalize this trigger as much as possible and state
that that is outside the scope of this document.

>> 2. The protocol is very loosely specified and is ambiguous
>> w.r.t the protocol operation. I'd rewrite Section 4.0,
>> which is more an explanation of a call flow, rather than a
>> specification one can implement. I'd try to specify it in a
>> bit more logical manner. It might be better to specify
>> it from the order of sequence of events:
>
> Well, this is not a brand new protocol per se, but an application of
> FMIPv6 (RFC 5268bis) to PMIPv6-only networks. So, the call flow makes
> sense to show when HI (from RFC 5268bis) is triggered (as an access
> network trigger). Agree with you that it needs to be sequenced, and
> hence the call flow.
>
>>    a.) A new trigger from the network, for MN's attachment to the
>>    new link.
>>
>>       - Specify the MAG operation from both sending/receiving end
>>       - Specify the MN states (layer-2, layer-3), before and after
>>       - Specify the forwarding rules on both the MAG's
>>       - State that LMA is immunte
>>       - Cover error cases for HI/HACK failures, MN detachment at
>>         any of the links during various stages of this protocol
>
> This looks okay. But, the processing of HI and HAck messages is
> described in detail in RFC 5268bis. Perhaps we should cover the deltas
> here (?)

The forwarding rules and error cases will be common to FMIPv6 and
PFMIPv6, so they can be described in RFC5268bis. The rest of them,
namely, the MAG operation, MN states, LMA's immunity will fall into PFMIPv6.

>
>> 3. The tunnel between the MAG's is a shared tunnel for all
>> the mobile flows, I assume ? If so, in most cast cases its
>> a predictive mode. Since, the difference here for the
>> predictive and reactive mode is just the order of steps
>> (#c and #e), may be its better to merge and avoid the text
>> duplication.
>
> No, the tunnel is not required to be shared (although it might be
> possible to do that with some twists). And, the protocol is not in
> most cases predictive. In fact, the eHRPD handovers in X.P0057 (which
> is using this protocol) is mostly reactive.

I would like the document to follow RFC5268bis as much as possible...

>
>> 4. There is very limited text on the encap type or the
>> life-cycle management of the tunnel between the MAG's.
>> When they come and go.
>
> Something specific here needs to be drawn out. But, otherwise it is
> from RFC 5268bis.

I presume that Sri thinks something like Section 6.10.2 in RFC5213. If
so, we can add text to clarify this part in a similar way.

>> 5. When the transport network is IPv4 or IPv6, so the type
>> of tunnel and the encap needs to be specified.
>>
>
> Why? Deployments will have to handle transport of *all* IPv6 traffic
> (including signaling, data) anyway. Wh should there be special
> considerations here? I would prefer to leave it out.
>

I think this is related to #4.

>> 6. The spec introduces a new security relation between the
>> MAG's, which is not there in 5213. This new requirement needs
>> to be properly specified. There are just 2 lines in Security
>> Considerations, which ideally for covering residual security
>> aspects.
>
> Again, please see 5268bis, which describes this in detail. Perhaps we
> need to make it clear that this spec re-uses Security, Encapsulation,
> Processing (of messages) from 5268bis more clearly.
>

The latest version has more description about it. Please refer to my
previous mail.

>> 7. Buffering requirements at MAG, may be few lines of text might
>> help.
>
> Okay.

Well revise it.

>> 8. AP-Id ? Has no relevance in this document. MN-AR is a point to
>> point link, the radio link should be hidden from this spec.
>>
>
> AP-ID is again for illustrating how the protocol fits in where it is
> used. No normative description.

The predictive mode needs a hint for the new link, which leads to the
NMAG. This can be any form and not specified in this document.

>> 9. Section 4.2, if the above structure is followed.
>>
>> 10. Section 5, 2nd paragraph, assumes MN will perform NUD after
>> a handoff. We are getting into the DNA space. MN will perform
>> RS/RA and not NUD. Also, NUD takes on average 53 secs to detect
>> a neighbor loss, so has no relevance here.
>
> umm.. This is not DNA, but plain ND *when link-layer addresses are
> used* (we had a long discussion on the ML on this, and the text simply
> reflects that). Yes, MN does RS/RA as well, but it cannot reliably
> detect loss of reachability of its default router without NUD. In
> other words, it does not switch router just because it saw a new
> prefix advertised (based on standard IPv6).
>
> Agree that NUD takes time. The point here is to state that the new
> router should be able to accept packets when link-layer addresses are
> used.

This part describes the MN attachment not its detachment. it describes
how the MN and NMAG should behave to reduce the communication disruption
time. This is sort of a guideline for it and avoids mandating anything.

>> 11. MN-AN connection establishment: Needs proper explanation on what
>> this is. If it is a link-layer setup, or a layer-3 setup. There is
>> lot of text in 5213 on the assumption around inter-tech handoff.
>> Some pointers to the affect that those assumptions are still valid.
>
> Will look into it.

The MN-AN connection refers to the link-layer connection. I'll also look
into RFC5213 to align with it.

>> Secondly, need to emphasise that after MN-AN connection implies the
>> prefix movement from the MN perspective. But, from Fig 3, how can
>> this happen in Reactive handoff, where the prefix is not known by
>> N-MAG till HI-HACK signaling is complete ?
>>
>
> MN continues to think that it can use the assigned HNP. NMAG, e.g.,
> cannot sent RA with this HNP until it receives it from PMAG.

The timing of the address configuration is not written in the document
because there will be multiple cases depending on the access type. But I
agree that we should mention it in some way.

>> 12. State that how MN-MN traffic is handled at P-MAG and N-MAG, if
>> EnableMAGLocalRouting is ON.
>
> This is important to capture. From this spec's point, it is providing
> uplink and downlink packet forwarding for an MN during its handover,
> regardless of how the traffic is originated. For downlink traffic (to
> the MN undergoing handover), PMAG just updates forwarding to point to
> NMAG (with encapsulation). For uplink traffic, the NMAG is sending it
> back to the PMAG. One thing I see is the lifetime of the PMAG - NMAG
> tunnel. When local forwarding is ON, it may need to be longer than
> otherwise.

I also think this is very interesting from a different viewpoint.

Suppose two MNs are attached to one MAG and packets are forwarded
locally. Then one MN moves from this MAG (PMAG) to another MAG (NMAG).
If PMAG does not detect the MN's detachment, which often happens in WLAN
access, it would continue to forward packets locally forever... Even if
the NMAG and LMA exchange the PBU/PBA, the PMAG still does not know
about the MN's movement. Then, it occurred to me that this document will
be useful to solve this issue by notifying the PMAG of the MN's
detachment with HI/HAck.

If this is a correct observation, I'll add some text along this line.

> Thanks again for the good review.

Thanks again from me, too.
--
Hidetoshi

> -Rajeev
>
>> Regards
>> Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> 2.  Introduction
>>>
>>>   Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>>>   that does not possess Mobile IPv6 [RFC3775] mobile node
>>>   functionality.  A proxy agent in the network performs the mobility
>>>   management signaling on behalf of the mobile node.  This model
>>>   transparently provides mobility for mobile nodes within a PMIPv6
>>>   domain.  Nevertheless, the basic performance of PMIPv6 in terms of
>>>   handover latency and packet loss is considered not any different from
>>>   that of Mobile IPv6.
>>>
>>>   Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the
>>>   protocol to reduce the handover latency for Mobile IPv6 by allowing a
>>>   mobile node to send packets as soon as it detects a new subnet link
>>>   and by delivering packets to the mobile node as soon as its
>>>   attachment is detected by the new access router.  This document
>>>   describes necessary extensions to FMIPv6 for operations in the PMIPv6
>>>   domain in order to minimize handover delay and packet loss as well as
>>>   to transfer network-resident contexts.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 4]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 3.  Terminology
>>>
>>>   This document refers to [RFC5213][RFC5268bis][RFC3775] for
>>>   terminology.  The following terms and abbreviations are additionally
>>>   used in this document.  The reference network is illustrated in
>>>   Figure 1.
>>>
>>>   Access Network (AN):
>>>        A network composed of link-layer access devices such as access
>>>        points or base stations providing access to the Access Router
>>>        (AR) connected to it.
>>>
>>>   Previous Access Network (P-AN):
>>>        The access network to which the MN is attached before handover.
>>>
>>>   New Access Network (N-AN):
>>>        The access network to which the MN is attached after handover.
>>>
>>>   Previous Mobile Access Gateway (PMAG):
>>>        The MAG that manages mobility related signaling for the MN
>>>        before handover.  In this document, the MAG and the Access
>>>        Router are collocated.
>>>
>>>   New Mobile Access Gateway (NMAG):
>>>        The MAG that manages mobility related signaling for the MN after
>>>        handover.  In this document, the MAG and the Access Router (AR)
>>>        are collocated.
>>>
>>>   HO-Initiate:
>>>        A generic signaling that indicates the handover of the MN sent
>>>        from the P-AN to the PMAG.  While this signaling is dependent on
>>>        the access technology, it is assumed that HO-Initiate can carry
>>>        the information to identify the MN and to assist the PAR resolve
>>>        the NAR (e.g., the new access point or base station to which the
>>>        MN is moving).  Detailed definition of this message is outside
>>>        the scope of this document.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 5]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>                                  +----------+
>>>                                 |    LMA    |
>>>                                 | |
>>>                                  +----------+
>>>                                   /      \
>>>                                  /        \
>>>                                  /          \
>>>                      +........../..+      +..\..........+
>>>                      . +-------+-+ .______. +-+-------+ .
>>>                      . |   PAR   |()_______)|   NAR   | .
>>>                      . |  (PMAG) | .      . |  (NMAG) | .
>>>                      . +----+----+ .      . +----+----+ .
>>>                      .      |      .      .      |      .
>>>                      .   ___|___   .      .   ___|___   .
>>>                      .  /       \  .      .  /       \  .
>>>                      . (  P-AN   ) .      . (  N-AN   ) .
>>>                      .  \_______/  .      .  \_______/  .
>>>                      .      |      .      .      |      .
>>>                      .   +----+    .      .   +----+    .
>>>                      .   | MN |  ---------->  | MN |    .
>>>                      .   +----+    .      .   +----+    .
>>>                      +.............+      +.............+
>>>
>>>              Figure 1: Reference network for fast handover
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 6]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 4.  Proxy-based FMIPv6 Protocol Overview
>>>
>>>   In order to improve the performance during handover (when operations
>>>   such as attachment to a new network and signaling between mobility
>>>   agents are involved), the PFMIPv6 protocol in this document specifies
>>>   a bi-directional tunnel between the Previous MAG (PMAG) and the New
>>>   MAG (NMAG).  In order to enable the NMAG to send the Proxy Binding
>>>   Update (PBU), the Handover Initiate (HI) and Handover Acknowledge
>>>   (HAck) messages in [RFC5268bis] are used for context transfer, in
>>>   which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4
>>>   Home Address, are transferred from the PMAG.
>>>
>>>   In this document, the Previous Access Router (PAR) and New Access
>>>   Router (NAR) are interchangeable with the PMAG and NMAG,
>>>   respectively.
>>>
>>>   Since a MN is not directly involved with IP mobility protocol
>>>   operations, it follows that the MN is not directly involved with fast
>>>   handover procedures either.  Hence, the messages involving the MN in
>>>   [RFC5268bis] are not used when PMIPv6 is in use.  Such messages are
>>>   the Router Solicitation for Proxy Advertisement (RtSolPr), Proxy
>>>   Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast
>>>   Binding Acknowledgment (FBack) and Unsolicited Neighbor Advertisement
>>>   (UNA).
>>>
>>> 4.1.  Protocol Operation
>>>
>>>   There are two modes of operation in FMIPv6 [RFC5268bis].  In the
>>>   predictive mode of fast handover, a bi-directional tunnel between the
>>>   PAR and NAR is established prior to the MN's attachment to the NAR.
>>>   In the reactive mode, this tunnel establishment takes place after the
>>>   MN attaches to the NAR.  Since the MN is not involved in IP mobility
>>>   signaling in PMIPv6, the sequence of events illustrating the
>>>   predictive fast handover are shown in Figure 2.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 7]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>                                            PMAG        NMAG
>>>          MN         P-AN       N-AN        (PAR)       (NAR)     LMA
>>>         | | | | | |
>>>         |   Report   |          |            |           |        |
>>>     (a)  |-(MN ID,-->|          |            |           |        |
>>>         |  New AP ID)|          |            |           |        |
>>>         | |      HO Initiate       |           |        |
>>>     (b)  |           |--(MN ID, New AP ID)-->|           |        |
>>>         | | | | | |
>>>         | | | |     HI     |        |
>>>     (c)  |           |          |            |-(MN ID, ->|        |
>>>         | | | |  MN IID, LMAA)      |
>>>         | | | | | |
>>>     (d)  |           |          |            |<---HAck---|        |
>>>         | | | |   (MN ID)  |        |
>>>         | | | | | |
>>>         | | | | HI/HAck(optional)   |
>>>    (e)  |           |          |            |<- - - - ->|        |
>>>         | | |           #=|<===================|
>>>     (f)  |           |          |          #====DL data=>|        |
>>>         | | | | | |
>>>     (g) ~~~          |          |            |           |        |
>>>        ~ ~ ~ | | | | |
>>>         |    MN-AN connection   |    AN-MAG connection   |        |
>>>     (h)  |<---establishment---->|<----establishment----->|        |
>>>         | | |   (substitute for UNA)  |        |
>>>         | | | | | |
>>>     (i)  |<==================DL data=====================|<=======|
>>>         | | | | | |
>>>    (j)  |===================UL data====================>|=#      |
>>>         | | | # =|<============#      |
>>>         | | | # =====================>|
>>>     /    |           |          |            |           |        | \
>>>    | (k) |           |          |            |           |--PBU-->| |
>>>    | | | | | | | |
>>>    | (l) |           |          |            |           |<--PBA--| |
>>>     \    |           |          |            |           |        | /
>>>
>>>      Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
>>>
>>>  The detailed descriptions are as follows:
>>>
>>>   (a)  The MN detects that a handover is imminent and reports the
>>>        identifications of itself (MN ID) and the access point (New AP
>>>        ID) to which the MN is most likely to move.  The MN ID could be
>>>        the NAI or a Link Layer Address (LLA), or any other suitable
>>>        identifier.  This step is access technology specific.  In some
>>>        cases, the P-AN will determine which AP ID the MN is moving to.
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 8]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>   (b)  The previous access network (P-AN), to which the MN is currently
>>>        attached, indicates the handover of the MN to the PAR (PMAG).
>>>        Detailed definition and specification of this message are
>>>        outside the scope of this document.
>>>
>>>   (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>>>        the MN ID and SHOULD include the MN-HNP, the MN-IID and the
>>>        address of the LMA that is currently serving the MN.
>>>
>>>  (d)  The NAR sends the HAck back to the PAR.
>>>
>>>   (e)  If it is preferred that the timing of buffering or forwarding
>>>        should be later than step (c), the NAR may optionally request
>>>        the PAR at a later and appropriate time to buffer or forward
>>>        packets by setting U or F flags in the HI message, respectively.
>>>
>>>   (f)  If the F flag is set in the previous step, a bi-directional
>>>        tunnel is established between the PAR and NAR and packets
>>>        destined for the MN are forwarded from the PAR to the NAR over
>>>        this tunnel.  After decapsulation, those packets may be buffered
>>>        at the NAR.  If the connection between the N-AN and NAR has
>>>        already been established, those packet may be forwarded towards
>>>        the N-AN; this is access technology specific.
>>>
>>>  (g)  The MN undergoes handover to the New Access Network (N-AN).
>>>
>>>   (h)  The MN establishes a connection (e.g., radio channel) with the
>>>        N-AN, which in turn triggers the establishment of the connection
>>>        between the N-AN and NAR if it has not been established already
>>>        (access technology specific).  This can be regarded as a
>>>        substitute for the UNA.
>>>
>>>   (i)  The NAR starts to forward packets destined for the MN via the
>>>        N-AN.
>>>
>>>   (j)  The uplink packets from the MN are sent to the NAR via the N-AN
>>>        and the NAR forwards them to the PAR.  The PAR then sends the
>>>        packets to the LMA that is currently serving the MN.
>>>
>>>   (k)  The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
>>>        whose address is provided in (c).  Steps (k) and (l) are not
>>>        part of the fast handover procedure, but shown for reference.
>>>
>>>   (l)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
>>>        NAR (NMAG).  From this time on, the packets to/from the MN go
>>>        through the NAR instead of the PAR.
>>>
>>>  According to Section 4 of [RFC5268bis], the PAR establishes a binding
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009               [Page 9]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>   between the PCoA and NCoA to forward packets for the MN to the NAR,
>>>   and the NAR creates a proxy NCE to receive those packets for the NCoA
>>>   before the MN arrives.  In the case of PMIPv6, however, the only
>>>   address that is used by the MN is MN-HoA.  Hence the PAR forwards
>>>   MN's packets to the NAR instead of the NCoA.  FMIPv4 [RFC4988]
>>>   specifies forwarding when the MN uses HoA as its on-link address
>>>   rather than the care-of address.  The usage in PMIPv6 is similar to
>>>   that in FMIPv4, where the address is used by the MN is based on Home
>>>   Network Prefix.  Hence the PAR forwards MN's packets to the NAR
>>>   instead of the NCoA.  The NAR then simply decapsulates those packets
>>>   and delivers them to the MN.  Since the NAR obtains the LLA (MN IID)
>>>   and MN-HNP by the HI, it can create the NCE for the MN and deliver
>>>   packets to it even before the MN can perform Neighbor Discovery.  For
>>>   the uplink packets from the MN after handover in (j), the NAR
>>>   forwards the packets to the PAR through the tunnel established in
>>>   step (f).  The PAR then decapsulates and sends them to the LMA.
>>>
>>>   The timing of the context transfer and that of packet forwarding may
>>>   be different.  Thus, a new flag 'F' and the Option Code values for it
>>>   in the HI message are defined to request forwarding.  To request
>>>   buffering, 'U' flag has already been defined in [RFC5268bis].  If the
>>>   PAR receives the HI message with F flag set and the Option Code value
>>>   being 2, it starts forwarding packets for the MN.  The HI message
>>>   with U flag set may be sent earlier if the timing of buffering is
>>>   different from that of forwarding.  If packet forwarding is
>>>   completed, the PAR MAY send the HI message with F flag set and the
>>>   Option Code value being 3.  By this message, the ARs on both ends can
>>>   tear down the forwarding tunnel synchronously.
>>>
>>>   The IP addresses in the headers of those user packets are summarized
>>>   below:
>>>
>>>  In (f),
>>>
>>>       Inner source address: IP address of the CN
>>>
>>>       Inner destination address: HNP or IPv4-MN-HoA
>>>
>>>       Outer source address: IP address of the PAR (PMAG)
>>>
>>>       Outer destination address: IP address of the NAR (NMAG)
>>>
>>>  In (i),
>>>
>>>       Source address: IP address of the CN
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 10]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>       Destination address: HNP or IPv4-MN-HoA
>>>
>>>  In (j),
>>>
>>>  - from the MN to the NMAG,
>>>
>>>       Source address: HNP or IPv4-MN-HoA
>>>
>>>       Destination address: IP address of the CN
>>>
>>>  - from the NMAG to the PMAG,
>>>
>>>       Inner source address: HNP or IPv4-MN-HoA
>>>
>>>       Inner destination address: IP address of the CN
>>>
>>>       Outer source address: IP address of the NAR (NMAG)
>>>
>>>       Outer destination address: IP address of the PAR (PMAG)
>>>
>>>  - from the PMAG to the LMA,
>>>
>>>       Inner source address: HNP or IPv4-MN-HoA
>>>
>>>       Inner destination address: IP address of the CN
>>>
>>>       Outer source address: IP address of the PAR (PMAG)
>>>
>>>       Outer destination address: IP address of the LMA
>>>
>>>   In the case of the reactive handover for PMIPv6, since the MN does
>>>   not send either the FBU or UNA, it would be more natural that the NAR
>>>   sends the HI to the PAR after the MN has moved to the new link.  The
>>>   NAR then needs to obtain the information of the PAR beforehand.  Such
>>>   information could be provided, for example, by the MN sending the
>>>   AP-ID on the old link and/or by the lower-layer procedures between
>>>   the P-AN and N-AN.  The exact method is not specified in this
>>>   document.  Figure 3 illustrates the reactive fast handover procedures
>>>   for PMIPv6, where the bi-directional tunnel establishment is
>>>   initiated by the NAR.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 11]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>                                         PMAG            NMAG
>>>          MN       P-AN      N-AN        (PAR)           (NAR)     LMA
>>>         | | | | | |
>>>     (a) ~~~        |         |            |               |        |
>>>        ~ ~ ~ | | | | |
>>>         |   MN-AN connection |       AN-MAG connection    |        |
>>>     (b)  |<--establishment-->|<-------establishment------>|        |
>>>         | (MN ID, Old AP ID) |     (MN ID, Old AP ID)     |        |
>>>         | | | (substitute for UNA and FBU)|        |
>>>         | | | | | |
>>>         | | | |       HI       |        |
>>>     (c)  |         |         |            |<---(MN ID) ---|        |
>>>         | | | | | |
>>>         | | | |      HAck      |        |
>>>     (d)  |         |         |            |---(MN ID, --->|        |
>>>         | | | |  MN IID, LMAA) |        |
>>>         | | | | | |
>>>    (e)  |         |         |          #=|<=======================|
>>>         | | |           #================>|=#      |
>>>         | <====================DL data======================#      |
>>>         | | | | | |
>>>    (f)  |=====================UL data===================>|=#      |
>>>         | | | # =|<================#      |
>>>         | | | # =========================>|
>>>         | | | | | |
>>>     /    |         |         |            |               |        | \
>>>    | (g) |         |         |            |               |--PBU-->| |
>>>    | | | | | | | |
>>>    | (h) |         |         |            |               |<--PBA--| |
>>>     \    |         |         |            |               |        | /
>>>
>>>       Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
>>>
>>>  The detailed descriptions are as follows:
>>>
>>>   (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
>>>        on the old link may be provided by the MN to help identify the
>>>        PMAG on the new link.
>>>
>>>   (b)  The MN establishes a connection (e.g., radio channel) with the
>>>        N-AN, which triggers the establishment of the connection between
>>>        the N-AN and NAR.  The MN ID is transferred to the NAR for the
>>>        subsequent procedures.  The AP-ID on the old link may also be
>>>        provided by the MN to help identify the PMAG on the new link.
>>>        This can be regarded as a substitute for the UNA and FBU.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 12]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>   (c)  The NAR sends the HI to the PAR.  The HI message MUST include
>>>        the MN ID.  The Context Request Option MAY be included to
>>>        request additional context information on the MN to the PAR.
>>>
>>>   (d)  The PAR sends the HAck back to the NAR.  The HAck message MUST
>>>        include the HNP and/or IPv4-MN-HoA that is corresponding to the
>>>        MN ID in the HI message and SHOULD include the MN-IID and the
>>>        LMA address that is currently serving the MN.  The context
>>>        information requested by the NAR MUST be included.
>>>
>>>   (e)  If F flag in the HI is set, a bi-directional tunnel is
>>>        established between the PAR and NAR and packets destined for the
>>>        MN are forwarded from the PAR to the NAR over this tunnel.
>>>        After decapsulation, those packets are delivered to the MN via
>>>        the N-AN.
>>>
>>>   (f)  The uplink packets from the MN are sent to the NAR via the N-AN
>>>        and the NAR forwards them to the PAR.  The PAR then sends the
>>>        packets to the LMA that is currently serving the MN.
>>>
>>>   Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover
>>>   procedures.
>>>
>>>   In step (c), The IP address of the PAR needs to be resolved by the
>>>   NAR to send the HI to the PAR.  This information may come from the
>>>   N-AN or some database that the NAR can access.
>>>
>>> 4.2.  IPv4 Support Considerations
>>>
>>>   The motivation and usage scenarios of IPv4 protocol support by PMIPv6
>>>   are described in [IPv4PMIPv6].  The scope of IPv4 support covers the
>>>   following two features:
>>>
>>>  o  IPv4 Home Address Mobility Support, and
>>>
>>>  o  IPv4 Transport Support.
>>>
>>>   As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
>>>   Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
>>>   transfer IPv4-MN-HoA to the NMAG, which is the inner destination
>>>   address of the packets forwarded on the downlink.  In order to
>>>   support IPv4-MN-HoA, a new option called IPv4 Address Option is
>>>   defined in this document.  In order to provide IPv4 Transport
>>>   Support, the NMAG needs to know the IPv4 address of the LMA (IPv4-
>>>   LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4
>>>   transport network.  The above IPv4 Address Option is defined so as to
>>>   be able to convey IPv4-LMAA.  The details of this option are
>>>   described in [IPv4PMIPv6].
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 13]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 5.  Other Considerations
>>>
>>>   The protocol specified in this document enables the NMAG to obtain
>>>   parameters which would otherwise be available only by communicating
>>>   with the LMA.  For instance, the HNP and/or IPv4-MN-HoA of a MN are
>>>   made available to the NMAG through context transfer.  This allows the
>>>   NMAG to perform some procedures which may be beneficial.  For
>>>   instance, the NMAG could send a Router Advertisement (RA) with the
>>>   HNP option to the MN as soon as it's link attachment is detected
>>>   (e.g., via receipt of a Router Solicitation message).  Such an RA is
>>>   recommended, for example, in scenarios where the MN uses a new radio
>>>   interface while attaching to the NMAG; since the MN does not have
>>>   information regarding the new interface, it will not be able to
>>>   immediately send packets without first receiving an RA with HNP.
>>>   However, if the subsequent PMIPv6 binding registration for the HNP
>>>   fails for some reason, then the NMAG MUST withdraw the advertised HNP
>>>   by sending another RA with zero prefix lifetime for the HNP in
>>>   question.  This operation is the same as that described in Section
>>>   6.12 of [RFC5213].
>>>
>>>   The protocol specified in this document is applicable regardless of
>>>   whether link-layer addresses are used between a MN and its access
>>>   router.  A MN should be able to continue sending packets on the
>>>   uplink even when it changes link.  When link-layer addresses are
>>>   used, the MN performs Neighbor Unreachability Detection (NUD)
>>>   [RFC4861], after attaching to a new link, probing the reachability of
>>>   its default router.  If the new router's interface is configured to
>>>   respond to queries sent to link-layer addresses than its own (e.g.,
>>>   set to promiscuous mode), then it can respond to the NUD probe,
>>>   providing its link-layer address in the solicited Neighbor
>>>   Advertisement.  While the MN is performing NUD, it can continue to
>>>   send uplink packets.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 14]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 6.  Message Formats
>>>
>>>   This document defines new Mobility Header messages for the extended
>>>   HI and Hack and new mobility options for conveying context
>>>   information.
>>>
>>> 6.1.  Mobility Header
>>>
>>> 6.1.1.  Handover Initiate (HI)
>>>
>>>   This section defines extensions to the HI message in [RFC5268bis].
>>>   The format of the Message Data field in the Mobility Header is as
>>>   follows:
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>                                     +-------------------------------+
>>>                                    |            Sequence #          |
>>>    +-+-+-+-----------+-------------+-------------------------------+
>>>    | S|U|F|  Reserved |     Code    |                               |
>>>     +-+-+-+-----------+-------------+                               |
>>>    | |
>>>     .                                                               .
>>>     .                       Mobility options                        .
>>>     .                                                               .
>>>    | |
>>>     +---------------------------------------------------------------+
>>>
>>>  IP Fields:
>>>
>>>  Source Address
>>>
>>>                      The IP address of PMAG or NMAG
>>>
>>>  Destination Address
>>>
>>>                      The IP address of the peer MAG
>>>
>>>  Message Data:
>>>
>>>  Sequence #  Same as [RFC5268bis].
>>>
>>>   S flag      Defined in [RFC5268bis] and MUST be set to zero in this
>>>               specification.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 15]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>  U flag      Buffer flag.  Same as [RFC5268bis].
>>>
>>>   F flag      Forwarding flag.  Used to request to forward the packets
>>>               for the MN.
>>>
>>>  Reserved    Same as [RFC5268bis].
>>>
>>>   Code        [RFC5268bis] defines this field and its values 0 and 1.
>>>               In this specification, if F flag is not set, this field
>>>               MUST be set to zero.  Otherwise, it has the following
>>>               meaning:
>>>
>>>                        2: Forwarding is not requested
>>>
>>>                        3: Request forwarding
>>>
>>>                        4: Indicate the completion of forwarding
>>>
>>>  Mobility options:
>>>
>>>   This field contains one or more mobility options, whose encoding and
>>>   formats are defined in [RFC3775].  At least one mobility option MUST
>>>   uniquely identify the target MN (e.g., the Mobile Node Identifier
>>>   Option defined in RFC4283) and the transferred context MUST be for
>>>   one MN per message.  In addition, the NAR can request necessary
>>>   mobility options by the Context Request Option defined in this
>>>   document.
>>>
>>>  Context Request Option
>>>
>>>            This option MAY be present to request context information
>>>            typically by the NAR to the PAR in the NAR-initiated fast
>>>            handover.
>>>
>>> 6.1.2.  Handover Acknowledge (HAck)
>>>
>>>   This section defines extensions to the HAck message in[RFC5268bis].
>>>   The format of the Message Data field in the Mobility Header is as
>>>   follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 16]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>                                     +-------------------------------+
>>>                                    |            Sequence #          |
>>>    +-+-+-----------+---------------+-------------------------------+
>>>    | U|F| Reserved  |     Code      |                               |
>>>     +-+-+-----------+---------------+                               |
>>>    | |
>>>     .                                                               .
>>>     .                       Mobility options                        .
>>>     .                                                               .
>>>    | |
>>>     +---------------------------------------------------------------+
>>>
>>>  IP Fields:
>>>
>>>  Source Address
>>>
>>>                       Copied from the destination address of the
>>>                       Handover Initiate message to which this message
>>>                       is a response.
>>>
>>>  Destination Address
>>>
>>>                       Copied from the source address of the Handover
>>>                       Initiate message to which this message is a
>>>                       response.
>>>
>>>  Message Data:
>>>
>>>   The usages of Sequence # and Reserved fields are exactly the same as
>>>   those in [RFC5268bis].
>>>
>>>  U, F flags  Same as defined in Section 6.1.1.
>>>
>>>   Code
>>>               Code values 0 through 4 and 128 through 130 are defined
>>>               in [RFC5268bis].  In this specification, the meaning of
>>>               Code value 0 is modified, 128 through 130 are reused, and
>>>               5, 6, 131 and 132 are newly defined.
>>>
>>>                      0: Handover Accepted
>>>
>>>                      5: Context Transfer Successful or Accepted
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 17]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>                      6: All available Context Transferred
>>>
>>>                      128: Handover Not Accepted, reason unspecified
>>>
>>>                      129: Administratively prohibited
>>>
>>>                      130: Insufficient resources
>>>
>>>                      131: Requested Context Not Available
>>>
>>>                      132: Forwarding Not Available
>>>
>>>  Mobility options:
>>>
>>>   This field contains one or more mobility options, whose encoding and
>>>   formats are defined in [RFC3775].  The mobility option that uniquely
>>>   identifies the target MN MUST be copied from the corresponding HI
>>>   message and the transferred context MUST be for one MN per message.
>>>
>>>   Requested option(s)  All the context information requested by the
>>>             Context Request Option in the HI message SHOULD be present
>>>             in the HAck message.  The other cases are described below.
>>>
>>>   In the case of the PAR-initiated fast handover, when the PAR sends
>>>   the HI message to the NAR with the context information and the NAR
>>>   successfully receives it, the NAR returns the HAck message with Code
>>>   value 5.  In the case of the NAR-initiated fast handover, when the
>>>   NAR sends the HI message to the PAR with or without Context Request
>>>   Option, the PAR returns the HAck message with the requested or
>>>   default context information (if any).  If all available context
>>>   information is transferred, the PAR sets the Code value in the HAck
>>>   message to 6.  If more context information is available, the PAR sets
>>>   the Code value in the HAck to 5 and the NAR MAY send new HI
>>>   message(s) to retrieve the rest of the available context information.
>>>   If none of the requested context information is available, the PAR
>>>   returns the HAck message with Code value 131 without any context
>>>   information.
>>>
>>> 6.2.  Mobility Options
>>>
>>> 6.2.1.  Context Request Option
>>>
>>>   This option is sent in the HI message to request context information
>>>   on the MN.  If a default set of context information is defined and
>>>   always sufficient, this option is not mandatory.  This option is more
>>>   useful to retrieve additional or dynamically selected context
>>>   information.
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 18]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>   Context Request Option is typically used for the reactive (NAR-
>>>   initiated) fast handover mode to retrieve the context information
>>>   from the PAR.  When this option is included in the HI message, all
>>>   the requested context information SHOULD be included in the HAck
>>>   message in the corresponding mobility option(s) (e.g., HNP, LMAA or
>>>   MN-IID mobility options).
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     +---------------+---------------+---------------+---------------+
>>>    |   Option-Type  | Option-Length |           Reserved            |
>>>     +---------------+---------------+-------------------------------+
>>>    |   Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
>>>     +---------------------------------------------------------------+
>>>    |                               ...                              |
>>>
>>>  Option-Type    TBD1
>>>
>>>   Option-Length  The length in octets of this option, not including the
>>>                  Option Type and Option Length fields.
>>>
>>>   Reserved       This field is unused.  It MUST be initialized to zero
>>>                  by the sender and MUST be ignored by the receiver.
>>>
>>>  Req-type-n     The type value for the n'th requested option.
>>>
>>>   Req-length-n   The length of the n'th requested option excluding the
>>>                  Req-type-n and Req-length-n fields.
>>>
>>>   In the case where there are only Req-type-n and Req-length-n fields,
>>>   the value of the Req-length-n is set to zero.  If additional
>>>   information besides the Req-type-n is necessary to uniquely specify
>>>   the requested context, such information follows after the
>>>   Req-length-n.  For example, when the requested context is the Vendor-
>>>   Specific Option described in Section 6.2.8, the requested option
>>>   format looks as follows:
>>>
>>>    |                               ...                              |
>>>     +---------------+---------------+-------------------------------+
>>>    |  Req-type-N=19 | Req-length-N=5|           Vendor-ID           |
>>>     +-------------------------------+---------------+---------------+
>>>    |            Vendor-ID           |   Sub-Type    |               |
>>>     +-----------------------------------------------+               |
>>>    |                               ...                              |
>>>
>>>   The exact values in the Vendor-ID and Sub-Type are outside the scope
>>>   of this document.
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 19]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>>
>>>   This option is used to transfer the Local Mobility Anchor IPv6
>>>   Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is
>>>   currently registered.  The detailed definition of the LMAA is
>>>   described in [RFC5213].
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |   Option-Type  | Option-Length |  Option-Code  |   Reserved    |
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |               Local Mobility Anchor Address ...                |
>>>
>>>  Option-Type    TBD2
>>>
>>>  Option-Length  18 or 6
>>>
>>>  Option-Code
>>>
>>>                 0  Reserved
>>>
>>>                 1  IPv6 address of the LMA (LMAA)
>>>
>>>                 2  IPv4 address of the LMA (IPv4-LMAA)
>>>
>>>   Reserved       This field is unused.  It MUST be initialized to zero
>>>                  by the sender and MUST be ignored by the receiver.
>>>
>>>   Local Mobility Anchor Address
>>>                  If Option-Code is 1, the LMA IPv6 address (LMAA) is
>>>                  inserted.  If Option-Code is 2, the LMA IPv4 address
>>>                  (IPv4-LMA) is inserted.
>>>
>>> 6.2.3.  IPv4 Address Option
>>>
>>>   As described in Section 4.2, if the MN is IPv4-only mode or dual-
>>>   stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
>>>   option has alignment requirement of 4n.
>>>
>>>      0                   1                   2                   3
>>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |  Option-Type   | Option-Length |  Option-Code  |    Reserved   |
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |                       IPv4 Address                             |
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 20]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>>  Option-Type    TBD3
>>>
>>>  Option-Length  6
>>>
>>>  Option-Code
>>>
>>>                 0  Reserved
>>>
>>>                 1  IPv4-MN-HoA
>>>
>>>   Reserved       This field is unused.  It MUST be initialized to zero
>>>                  by the sender and MUST be ignored by the receiver.
>>>
>>>  IPv4 Address   IPv4 address specified in Option-Code
>>>
>>> 6.2.4.  Home Network Prefix Option
>>>
>>>   This option is used to transfer the home network prefix that is
>>>   assigned to the MN in the P-AN.  The Home Network Prefix Option
>>>   defined in [RFC5213] is used for this.
>>>
>>> 6.2.5.  Mobile Node Interface Identifier (MN IID) Option
>>>
>>>   This option is used to transfer the interface identifier of the MN
>>>   that is used in the P-AN.  The Mobile Node Interface Identifier
>>>   Option defined in [RFC5213] is used for this.
>>>
>>> 6.2.6.  Link-local Address Option
>>>
>>>   This option is used to transfer the link-local address of the PAR
>>>   (PMAG).  The Link-local Address Option defined in [RFC5213] is used
>>>   for this.
>>>
>>> 6.2.7.  GRE Key Option
>>>
>>>   This option is used to transfer the GRE Key for the MN's data flow
>>>   over the bi-directional tunnel between the PAR and NAR.  The message
>>>   format of this option follows the GRE Key Option defined in [GREKEY].
>>>   The GRE Key value uniquely identifies each flow and the sender of
>>>   this option expects to receive packets of the flow from the peer AR
>>>   with this value.
>>>
>>> 6.2.8.  Vendor-Specific Mobility Option
>>>
>>>   This option is used to transfer any other information defined in this
>>>   document.  The format of this option follows the Vendor-Specific
>>>   Mobility Option defined in [RFC5094].  The exact values in the Vendor
>>>   ID, Sub-Type and Data fields are outside the scope of this document.
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 21]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 7.  Security Considerations
>>>
>>>   Security issues for this document follow those for PMIPv6[RFC5213]
>>>   and FMIPv6[RFC5268bis].  In PMIPv6, MAG and LMA are assumed to share
>>>   security association.  In FMIPv6, the access routers (i.e., the PMAG
>>>   and NMAG in this document) are assumed to share security association.
>>>   No new security risks are identified.  Support for integrity
>>>   protection using IPsec is required and confidentiality protection
>>>   SHOULD be used if sensitive context related to the mobile node is
>>>   being transferred.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yokota, et al.         Expires September 10, 2009              [Page 22]
>>>
>>> Internet-Draft          Proxy-based Fast Handover             March 2009
>>>
>>>
>>> 8.  IANA Considerations
>>>
>>>   This document defines two new mobility options, which are described
>>>   in Section 6.2.  The Type value for these options are assigned from
>>>   the same numbering space as allocated for the other mobility options,
>>>   as defined in [RFC3775].
>>>
>>>    Mobility Options
>>>    Value  Description                            Reference
>>>    -----  -------------------------------------  -------------
>>>    TBD1   Context Request Option                 Section 6.2.1
>>>    TBD2   Local Nobility Anchor Address Option   Section 6.2.2
>>>    TBD3   IPv4 Address Option                    Section 6.2.3
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Mipshop mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/mipshop
>>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
>
>
>

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Review of draft-ietf-mipshop-pfmipv6-03.txt

Hidetoshi Yokota
Hi Sri,

Sorry for the late response. Attached please find the revised version
that I hope captured the received comments. Please also see in line:

Hidetoshi Yokota wrote:

> Hi Sri and Rajeev,
>
> Many thanks to Sri for the detailed review.
>
> Rajeev Koodli wrote:
>> Hi Sri,
>>
>> thanks for the detailed review. Some comments inline.
>>
>>> 1. Too many functional elements. P-AR, PAN, PMAG. What should
>>> one imply, PAN sending a message to PMAG ? We dont have that
>>> interface in Proxy Mobile IPv6 and so that interface should
>>> be hidden. From PMIP perspective, we just have a MAG, LMA,
>>> MN and events from the network. You may want to get rid of all
>>> the other jargon or functions. The call flows have to be between
>>> 3 functional elements.
>> Tha PAN and NAN are for illustration and completeness. Yes, PAN may
>> send a message to PMAG, but that is outside the scope of the document.
>> Having it in the diagram makes it clear as to how the protocol is
>> used.
>
> We have received a lot of questions about how PMAG or NMAG detects MN's
> handover in such a timely manner. We always answer them saying one
> possible approach is to get necessary information and trigger from the
> access network. By illustrating ANs in the figure and call flows, we can
> disambiguate what triggers the fast handover process. But at the same
> time, we try to generalize this trigger as much as possible and state
> that that is outside the scope of this document.
>
>>> 2. The protocol is very loosely specified and is ambiguous
>>> w.r.t the protocol operation. I'd rewrite Section 4.0,
>>> which is more an explanation of a call flow, rather than a
>>> specification one can implement. I'd try to specify it in a
>>> bit more logical manner. It might be better to specify
>>> it from the order of sequence of events:
>> Well, this is not a brand new protocol per se, but an application of
>> FMIPv6 (RFC 5268bis) to PMIPv6-only networks. So, the call flow makes
>> sense to show when HI (from RFC 5268bis) is triggered (as an access
>> network trigger). Agree with you that it needs to be sequenced, and
>> hence the call flow.
>>
>>>    a.) A new trigger from the network, for MN's attachment to the
>>>    new link.
>>>
>>>       - Specify the MAG operation from both sending/receiving end
>>>       - Specify the MN states (layer-2, layer-3), before and after
>>>       - Specify the forwarding rules on both the MAG's
>>>       - State that LMA is immunte
>>>       - Cover error cases for HI/HACK failures, MN detachment at
>>>         any of the links during various stages of this protocol
>> This looks okay. But, the processing of HI and HAck messages is
>> described in detail in RFC 5268bis. Perhaps we should cover the deltas
>> here (?)
>
> The forwarding rules and error cases will be common to FMIPv6 and
> PFMIPv6, so they can be described in RFC5268bis. The rest of them,
> namely, the MAG operation, MN states, LMA's immunity will fall into PFMIPv6.
New section 4.2 "Inter AR Tunneling Operation" is added to capture these
comments. Also, at the end of the first paragraph in Section 4.1, the
following sentence is added:

   Note that the protocol operation specified in the document is
   transparent to the LMA, hence there is no new functional requirement
   or change on the LMA.

>>> 3. The tunnel between the MAG's is a shared tunnel for all
>>> the mobile flows, I assume ? If so, in most cast cases its
>>> a predictive mode. Since, the difference here for the
>>> predictive and reactive mode is just the order of steps
>>> (#c and #e), may be its better to merge and avoid the text
>>> duplication.
>> No, the tunnel is not required to be shared (although it might be
>> possible to do that with some twists). And, the protocol is not in
>> most cases predictive. In fact, the eHRPD handovers in X.P0057 (which
>> is using this protocol) is mostly reactive.
>
> I would like the document to follow RFC5268bis as much as possible...
>
>>> 4. There is very limited text on the encap type or the
>>> life-cycle management of the tunnel between the MAG's.
>>> When they come and go.
>> Something specific here needs to be drawn out. But, otherwise it is
>> from RFC 5268bis.
>
> I presume that Sri thinks something like Section 6.10.2 in RFC5213. If
> so, we can add text to clarify this part in a similar way.
At the end of the description for the predictive fast handover in
Section 4.1 on p.12, the following sentence is added:

The encapsulation type for these user packets SHOULD follow that used in
the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213] or
GRE[GREKEY]).

>>> 5. When the transport network is IPv4 or IPv6, so the type
>>> of tunnel and the encap needs to be specified.
>>>
>> Why? Deployments will have to handle transport of *all* IPv6 traffic
>> (including signaling, data) anyway. Wh should there be special
>> considerations here? I would prefer to leave it out.
>>
>
> I think this is related to #4.

At the end of Section 4.3 (former 4.2), the following sentence is added:

The supported encapsulation type follows Section 6.10.2 of RFC5213, that
is, IPv4, IPv4-UDP and IPv4-UDP-TLV.

>>> 6. The spec introduces a new security relation between the
>>> MAG's, which is not there in 5213. This new requirement needs
>>> to be properly specified. There are just 2 lines in Security
>>> Considerations, which ideally for covering residual security
>>> aspects.
>> Again, please see 5268bis, which describes this in detail. Perhaps we
>> need to make it clear that this spec re-uses Security, Encapsulation,
>> Processing (of messages) from 5268bis more clearly.
>>
>
> The latest version has more description about it. Please refer to my
> previous mail.
More detailed explanations are added in Section 7.

>>> 7. Buffering requirements at MAG, may be few lines of text might
>>> help.
>> Okay.
>
> Well revise it.

The following sentences are added to Section 4.1:

   In order eliminate the packet loss during
   MN's handover (especially when the MN is detached from both links),
   the downlink packets for the MN need to be buffered either at the PAR
   (PMAG) or NAR (NMAG), depending on when the packet forwarding is
   performed.  It is hence required that all MAGs have the capability
   and enough resources to buffer packets for the MNs accommodated by
   them.

>>> 8. AP-Id ? Has no relevance in this document. MN-AR is a point to
>>> point link, the radio link should be hidden from this spec.
>>>
>> AP-ID is again for illustrating how the protocol fits in where it is
>> used. No normative description.
>
> The predictive mode needs a hint for the new link, which leads to the
> NMAG. This can be any form and not specified in this document.
>
>>> 9. Section 4.2, if the above structure is followed.
>>>
>>> 10. Section 5, 2nd paragraph, assumes MN will perform NUD after
>>> a handoff. We are getting into the DNA space. MN will perform
>>> RS/RA and not NUD. Also, NUD takes on average 53 secs to detect
>>> a neighbor loss, so has no relevance here.
>> umm.. This is not DNA, but plain ND *when link-layer addresses are
>> used* (we had a long discussion on the ML on this, and the text simply
>> reflects that). Yes, MN does RS/RA as well, but it cannot reliably
>> detect loss of reachability of its default router without NUD. In
>> other words, it does not switch router just because it saw a new
>> prefix advertised (based on standard IPv6).
>>
>> Agree that NUD takes time. The point here is to state that the new
>> router should be able to accept packets when link-layer addresses are
>> used.
>
> This part describes the MN attachment not its detachment. it describes
> how the MN and NMAG should behave to reduce the communication disruption
> time. This is sort of a guideline for it and avoids mandating anything.
At the end of the Section 5, the following sentence is added:

Implementations should allow the MN to continue to send uplink packets
while it is performing NUD.

>>> 11. MN-AN connection establishment: Needs proper explanation on what
>>> this is. If it is a link-layer setup, or a layer-3 setup. There is
>>> lot of text in 5213 on the assumption around inter-tech handoff.
>>> Some pointers to the affect that those assumptions are still valid.
>> Will look into it.
>
> The MN-AN connection refers to the link-layer connection. I'll also look
> into RFC5213 to align with it.

Step (h) in Section 4.1 is revised as follows:

   (h)  The MN establishes a physical link connection with the N-AN
        (e.g., radio channel assignment), which in turn triggers the
        establishment of a link-layer connection between the N-AN and
        NAR if not yet established.  An IP layer connection setup may be
        performed at this time (e.g., PPP IPv6CP) or at a later time
        (e.g., stateful or stateless auto address configuration).  This
        step can be a substitute for the UNA in [RFC5268bis], but since
        they are all access technology specific, details are outside the
        scope of this document.

The following sentences are added in Section 5:

   Especially, in the reactive fast handover, the NMAG gets to know the
   HNP assigned to the MN on the previous link at step (d) in Figure 3.
   In order to reduce the communication disruption time, the NMAG SHOULD
   accept the MN to keep using the same HNP and to send uplink packets
   before that step upon MN's request.  However, if the HAck from the
   PMAG returns a different HNP or the subsequent PMIPv6 binding
   registration for the HNP fails for some reason, then the NMAG MUST
   withdraw the advertised HNP by sending another RA with zero prefix
   lifetime for the HNP in question.

>>> Secondly, need to emphasise that after MN-AN connection implies the
>>> prefix movement from the MN perspective. But, from Fig 3, how can
>>> this happen in Reactive handoff, where the prefix is not known by
>>> N-MAG till HI-HACK signaling is complete ?
>>>
>> MN continues to think that it can use the assigned HNP. NMAG, e.g.,
>> cannot sent RA with this HNP until it receives it from PMAG.
>
> The timing of the address configuration is not written in the document
> because there will be multiple cases depending on the access type. But I
> agree that we should mention it in some way.
>
>>> 12. State that how MN-MN traffic is handled at P-MAG and N-MAG, if
>>> EnableMAGLocalRouting is ON.
>> This is important to capture. From this spec's point, it is providing
>> uplink and downlink packet forwarding for an MN during its handover,
>> regardless of how the traffic is originated. For downlink traffic (to
>> the MN undergoing handover), PMAG just updates forwarding to point to
>> NMAG (with encapsulation). For uplink traffic, the NMAG is sending it
>> back to the PMAG. One thing I see is the lifetime of the PMAG - NMAG
>> tunnel. When local forwarding is ON, it may need to be longer than
>> otherwise.
>
> I also think this is very interesting from a different viewpoint.
>
> Suppose two MNs are attached to one MAG and packets are forwarded
> locally. Then one MN moves from this MAG (PMAG) to another MAG (NMAG).
> If PMAG does not detect the MN's detachment, which often happens in WLAN
> access, it would continue to forward packets locally forever... Even if
> the NMAG and LMA exchange the PBU/PBA, the PMAG still does not know
> about the MN's movement. Then, it occurred to me that this document will
> be useful to solve this issue by notifying the PMAG of the MN's
> detachment with HI/HAck.
>
> If this is a correct observation, I'll add some text along this line.
Appendix A.2 "Local Routing" is added.

Hope you will like it.

Any further questions and comments are welcome.

Regards,
--
Hidetoshi

>> Thanks again for the good review.
>
> Thanks again from me, too.




Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Standards Track                            K. Chowdhury
Expires: October 23, 2009                                      R. Koodli
                                                        Starent Networks
                                                                B. Patil
                                                                   Nokia
                                                                  F. Xia
                                                              Huawei USA
                                                          April 21, 2009


            Fast Handovers for Proxy Mobile IPv6 (tentative)
                   draft-ietf-mipshop-pfmipv6-04.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 23, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.



Yokota, et al.          Expires October 23, 2009                [Page 1]

Internet-Draft          Proxy-based Fast Handover             April 2009


Abstract

   Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility
   when it performs a handover from one access router to another and
   fast handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] are specified to
   enhance the handover performance in terms of latency and packet loss.
   While MIPv6 (and FMIPv6 as well) requires the participation of the
   mobile node in the mobility-related signaling, Proxy Mobile IPv6
   (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either
   have or do not have MIPv6 functionality without such involvement.
   Nevertheless, the basic performance of PMIPv6 in terms of handover
   latency and packet loss is considered not any different from that of
   MIPv6.  When the fast handover is considered in such an environment,
   several modifications are needed to FMIPv6 to adapt to the network-
   based mobility management.  This document specifies the usage of Fast
   Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility
   management protocol.  Necessary extensions are specified for FMIPv6
   to support the scenario when the mobile node does not have IP
   mobility functionality and hence is not involved with either MIPv6 or
   FMIPv6 operations.































Yokota, et al.          Expires October 23, 2009                [Page 2]

Internet-Draft          Proxy-based Fast Handover             April 2009


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . .  7
     4.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 14
     4.3.  IPv4 Support Considerations  . . . . . . . . . . . . . . . 15
   5.  PMIPv6-related Fast Handover Issues  . . . . . . . . . . . . . 16
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 17
     6.1.  Mobility Header  . . . . . . . . . . . . . . . . . . . . . 17
       6.1.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . 17
       6.1.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . 18
     6.2.  Mobility Options . . . . . . . . . . . . . . . . . . . . . 20
       6.2.1.  Context Request Option . . . . . . . . . . . . . . . . 20
       6.2.2.  Local Mobility Anchor Address (LMAA) Option  . . . . . 22
       6.2.3.  IPv4 Address Option  . . . . . . . . . . . . . . . . . 22
       6.2.4.  Home Network Prefix Option . . . . . . . . . . . . . . 23
       6.2.5.  Mobile Node Interface Identifier (MN IID) Option . . . 23
       6.2.6.  Link-local Address Option  . . . . . . . . . . . . . . 23
       6.2.7.  GRE Key Option . . . . . . . . . . . . . . . . . . . . 23
       6.2.8.  Vendor-Specific Mobility Option  . . . . . . . . . . . 23
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Applicable Use Cases  . . . . . . . . . . . . . . . . 27
     A.1.  PMIPv6 Handoff Indication  . . . . . . . . . . . . . . . . 27
     A.2.  Local Routing  . . . . . . . . . . . . . . . . . . . . . . 27
     A.3.  Handling of PMIPv6/MIPv6 switching . . . . . . . . . . . . 28
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

















Yokota, et al.          Expires October 23, 2009                [Page 3]

Internet-Draft          Proxy-based Fast Handover             April 2009


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Yokota, et al.          Expires October 23, 2009                [Page 4]

Internet-Draft          Proxy-based Fast Handover             April 2009


2.  Introduction

   Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
   that does not possess Mobile IPv6 [RFC3775] mobile node
   functionality.  A proxy agent in the network performs the mobility
   management signaling on behalf of the mobile node.  This model
   transparently provides mobility for mobile nodes within a PMIPv6
   domain.  Nevertheless, the basic performance of PMIPv6 in terms of
   handover latency and packet loss is considered not any different from
   that of Mobile IPv6.

   Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the
   protocol to reduce the handover latency for Mobile IPv6 by allowing a
   mobile node to send packets as soon as it detects a new subnet link
   and by delivering packets to the mobile node as soon as its
   attachment is detected by the new access router.  This document
   describes necessary extensions to FMIPv6 for operations in the PMIPv6
   domain in order to minimize handover delay and packet loss as well as
   to transfer network-resident contexts.
































Yokota, et al.          Expires October 23, 2009                [Page 5]

Internet-Draft          Proxy-based Fast Handover             April 2009


3.  Terminology

   This document reuses terminology from [RFC5213], [RFC5268bis] and
   [RFC3775].  The following terms and abbreviations are additionally
   used in this document.

   Access Network (AN):
        A network composed of link-layer access devices such as access
        points or base stations providing access to the Access Router
        (AR) connected to it.

   Previous Access Network (P-AN):
        The access network to which the MN is attached before handover.

   New Access Network (N-AN):
        The access network to which the MN is attached after handover.

   Previous Mobile Access Gateway (PMAG):
        The MAG that manages mobility related signaling for the MN
        before handover.  In this document, the MAG and the Access
        Router are collocated.

   New Mobile Access Gateway (NMAG):
        The MAG that manages mobility related signaling for the MN after
        handover.  In this document, the MAG and the Access Router (AR)
        are collocated.

   HO-Initiate:
        A generic signaling message that indicates the handover of the
        MN sent from the P-AN to the PMAG.  While this signaling is
        dependent on the access technology, it is assumed that HO-
        Initiate can carry the information to identify the MN and to
        assist the PAR resolve the NAR (e.g., the new access point or
        base station to which the MN is moving).  Definition of details
        in the specification of this message is outside the scope of
        this document.















Yokota, et al.          Expires October 23, 2009                [Page 6]

Internet-Draft          Proxy-based Fast Handover             April 2009


4.  Proxy-based FMIPv6 Protocol Overview

   In order to improve the performance during handover (when operations
   such as attachment to a new network and signaling between mobility
   agents are involved), the PFMIPv6 protocol in this document specifies
   a bi-directional tunnel between the Previous MAG (PMAG) and the New
   MAG (NMAG).  In order to enable the NMAG to send the Proxy Binding
   Update (PBU), the Handover Initiate (HI) and Handover Acknowledge
   (HAck) messages in [RFC5268bis] are used for context transfer, in
   which parameters such as MN's NAI, Home Network Prefix (HNP), IPv4
   Home Address, are transferred from the PMAG.

   In this document, the Previous Access Router (PAR) and New Access
   Router (NAR) are interchangeable with the PMAG and NMAG,
   respectively.  The reference network is illustrated in Figure 1.

   Since a MN is not directly involved with IP mobility protocol
   operations, it follows that the MN is not directly involved with fast
   handover procedures either.  Hence, the messages involving the MN in
   [RFC5268bis] are not used when PMIPv6 is in use.  The Router
   Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
   Advertisement (PrRtAdv) are exchanged between the MN and PAR for the
   MN to formulate the New Care-of Address (NCoA) in advance.  Fast
   Binding Update (FBU) and Fast Binding Acknowledgment (FBack) are also
   exchanged between these nodes to request the PAR to forward packets
   to the NAR.  The Unsolicited Neighbor Advertisement (UNA) is sent
   from the MN to NAR to forward the packets to the MN.  These messages
   are not applicable in the PMIPv6 context.























Yokota, et al.          Expires October 23, 2009                [Page 7]

Internet-Draft          Proxy-based Fast Handover             April 2009


                                  +----------+
                                  |   LMA    |
                                  |          |
                                  +----------+
                                    /      \
                                   /        \
                                  /          \
                      +........../..+      +..\..........+
                      . +-------+-+ .______. +-+-------+ .
                      . |   PAR   |()_______)|   NAR   | .
                      . |  (PMAG) | .      . |  (NMAG) | .
                      . +----+----+ .      . +----+----+ .
                      .      |      .      .      |      .
                      .   ___|___   .      .   ___|___   .
                      .  /       \  .      .  /       \  .
                      . (  P-AN   ) .      . (  N-AN   ) .
                      .  \_______/  .      .  \_______/  .
                      .      |      .      .      |      .
                      .   +----+    .      .   +----+    .
                      .   | MN |  ---------->  | MN |    .
                      .   +----+    .      .   +----+    .
                      +.............+      +.............+

               Figure 1: Reference network for fast handover

4.1.  Protocol Operation

   There are two modes of operation in FMIPv6 [RFC5268bis].  In the
   predictive mode of fast handover, a bi-directional tunnel between the
   PAR and NAR is established prior to the MN's attachment to the NAR.
   In the reactive mode, this tunnel establishment takes place after the
   MN attaches to the NAR.  In order eliminate the packet loss during
   MN's handover (especially when the MN is detached from both links),
   the downlink packets for the MN need to be buffered either at the PAR
   (PMAG) or NAR (NMAG), depending on when the packet forwarding is
   performed.  It is hence required that all MAGs have the capability
   and enough resources to buffer packets for the MNs accommodated by
   them.  Note that the protocol operation specified in the document is
   transparent to the LMA, hence there is no new functional requirement
   or change on the LMA.

   Since the MN is not involved in IP mobility signaling in PMIPv6, the
   sequence of events illustrating the predictive fast handover are
   shown in Figure 2.







Yokota, et al.          Expires October 23, 2009                [Page 8]

Internet-Draft          Proxy-based Fast Handover             April 2009


                                            PMAG        NMAG
          MN         P-AN       N-AN        (PAR)       (NAR)     LMA
          |           |          |            |           |        |
          |  Report   |          |            |           |        |
     (a)  |-(MN ID,-->|          |            |           |        |
          | New AP ID)|          |            |           |        |
          |           |     HO Initiate       |           |        |
     (b)  |           |--(MN ID, New AP ID)-->|           |        |
          |           |          |            |           |        |
          |           |          |            |    HI     |        |
     (c)  |           |          |            |-(MN ID, ->|        |
          |           |          |            | MN IID, LMAA)      |
          |           |          |            |           |        |
     (d)  |           |          |            |<---HAck---|        |
          |           |          |            |  (MN ID)  |        |
          |           |          |            |           |        |
          |           |          |            |HI/HAck(optional)   |
     (e)  |           |          |            |<- - - - ->|        |
          |           |          |          #=|<===================|
     (f)  |           |          |          #====DL data=>|        |
          |           |          |            |           |        |
     (g) ~~~          |          |            |           |        |
         ~~~          |          |            |           |        |
          |   MN-AN connection   |    AN-MAG connection   |        |
     (h)  |<---establishment---->|<----establishment----->|        |
          |           |          |  (substitute for UNA)  |        |
          |           |          |            |           |        |
     (i)  |<==================DL data=====================|<=======|
          |           |          |            |           |        |
     (j)  |===================UL data====================>|=#      |
          |           |          |          #=|<============#      |
          |           |          |          #=====================>|
     /    |           |          |            |           |        | \
     |(k) |           |          |            |           |--PBU-->| |
     |    |           |          |            |           |        | |
     |(l) |           |          |            |           |<--PBA--| |
     \    |           |          |            |           |        | /

       Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)

   The detailed descriptions are as follows:

   (a)  The MN detects that a handover is imminent and reports the
        identifications of itself (MN ID) and the access point (New AP
        ID) to which the MN is most likely to move.  The MN ID could be
        the NAI or a Link Layer Address (LLA), or any other suitable
        identifier.  This step is access technology specific.  In some
        cases, the P-AN will determine which AP ID the MN is moving to.



Yokota, et al.          Expires October 23, 2009                [Page 9]

Internet-Draft          Proxy-based Fast Handover             April 2009


   (b)  The previous access network (P-AN), to which the MN is currently
        attached, indicates the handover of the MN to the PAR (PMAG).
        Detailed definition and specification of this message are
        outside the scope of this document.

   (c)  The PAR sends the HI to the NAR.  The HI message MUST include
        the MN ID and SHOULD include the MN-HNP, the MN-IID and the
        address of the LMA that is currently serving the MN.

   (d)  The NAR sends the HAck back to the PAR.

   (e)  If it is preferred that the timing of buffering or forwarding
        should be later than step (c), the NAR may optionally request
        the PAR at a later and appropriate time to buffer or forward
        packets by setting U flag [RFC5268bis] or F flag in the HI
        message, respectively.

   (f)  If the F flag is set in the previous step, a bi-directional
        tunnel is established between the PAR and NAR and packets
        destined for the MN are forwarded from the PAR to the NAR over
        this tunnel.  After decapsulation, those packets may be buffered
        at the NAR.  If the connection between the N-AN and NAR has
        already been established, those packet may be forwarded towards
        the N-AN; this is access technology specific.

   (g)  The MN undergoes handover to the New Access Network (N-AN).

   (h)  The MN establishes a physical link connection with the N-AN
        (e.g., radio channel assignment), which in turn triggers the
        establishment of a link-layer connection between the N-AN and
        NAR if not yet established.  An IP layer connection setup may be
        performed at this time (e.g., PPP IPv6CP) or at a later time
        (e.g., stateful or stateless auto address configuration).  This
        step can be a substitute for the UNA in [RFC5268bis], but since
        they are all access technology specific, details are outside the
        scope of this document.

   (i)  The NAR starts to forward packets destined for the MN via the
        N-AN.

   (j)  The uplink packets from the MN are sent to the NAR via the N-AN
        and the NAR forwards them to the PAR.  The PAR then sends the
        packets to the LMA that is currently serving the MN.

   (k)  The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
        whose address is provided in (c).  Steps (k) and (l) are not
        part of the fast handover procedure, but shown for reference.




Yokota, et al.          Expires October 23, 2009               [Page 10]

Internet-Draft          Proxy-based Fast Handover             April 2009


   (l)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
        NAR (NMAG).  From this time on, the packets to/from the MN go
        through the NAR instead of the PAR.

   According to Section 4 of [RFC5268bis], the PAR establishes a binding
   between the PCoA and NCoA to forward packets for the MN to the NAR,
   and the NAR creates a proxy NCE to receive those packets for the NCoA
   before the MN arrives.  In the case of PMIPv6, however, the only
   address that is used by the MN is MN-HoA.  Hence the PAR forwards
   MN's packets to the NAR instead of the NCoA.  FMIPv4 [RFC4988]
   specifies forwarding when the MN uses HoA as its on-link address
   rather than the care-of address.  The usage in PMIPv6 is similar to
   that in FMIPv4, where the address is used by the MN is based on Home
   Network Prefix.  Hence the PAR forwards MN's packets to the NAR
   instead of the NCoA.  The NAR then simply decapsulates those packets
   and delivers them to the MN.  Since the NAR obtains the LLA (MN IID)
   and MN-HNP by the HI, it can create the NCE for the MN and deliver
   packets to it even before the MN can perform Neighbor Discovery.  For
   the uplink packets from the MN after handover in (j), the NAR
   forwards the packets to the PAR through the tunnel established in
   step (f).  The PAR then decapsulates and sends them to the LMA.

   The timing of the context transfer and that of packet forwarding may
   be different.  Thus, a new flag 'F' and the Option Code values for it
   in the HI message are defined to request forwarding.  To request
   buffering, 'U' flag has already been defined in [RFC5268bis].  If the
   PAR receives the HI message with F flag set and the Option Code value
   being 2, it starts forwarding packets for the MN.  The HI message
   with U flag set may be sent earlier if the timing of buffering is
   different from that of forwarding.  If packet forwarding is
   completed, the PAR MAY send the HI message with F flag set and the
   Option Code value being 3.  By this message, the ARs on both ends can
   tear down the forwarding tunnel synchronously.

   The IP addresses in the headers of those user packets are summarized
   below:

   In (f),

        Inner source address: IP address of the CN

        Inner destination address: HNP or IPv4-MN-HoA

        Outer source address: IP address of the PAR (PMAG)







Yokota, et al.          Expires October 23, 2009               [Page 11]

Internet-Draft          Proxy-based Fast Handover             April 2009


        Outer destination address: IP address of the NAR (NMAG)

   In (i),

        Source address: IP address of the CN

        Destination address: HNP or IPv4-MN-HoA

   In (j),

   - from the MN to the NMAG,

        Source address: HNP or IPv4-MN-HoA

        Destination address: IP address of the CN

   - from the NMAG to the PMAG,

        Inner source address: HNP or IPv4-MN-HoA

        Inner destination address: IP address of the CN

        Outer source address: IP address of the NAR (NMAG)

        Outer destination address: IP address of the PAR (PMAG)

   - from the PMAG to the LMA,

        Inner source address: HNP or IPv4-MN-HoA

        Inner destination address: IP address of the CN

        Outer source address: IP address of the PAR (PMAG)

        Outer destination address: IP address of the LMA

   The encapsulation type for these user packets SHOULD follow that used
   in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213]
   or GRE [GREKEY]).

   In the case of the reactive handover for PMIPv6, since the MN does
   not send either the FBU or UNA, it would be more natural that the NAR
   sends the HI to the PAR after the MN has moved to the new link.  The
   NAR then needs to obtain the information of the PAR beforehand.  Such
   information could be provided, for example, by the MN sending the
   AP-ID on the old link and/or by the lower-layer procedures between
   the P-AN and N-AN.  The exact method is not specified in this
   document.  Figure 3 illustrates the reactive fast handover procedures



Yokota, et al.          Expires October 23, 2009               [Page 12]

Internet-Draft          Proxy-based Fast Handover             April 2009


   for PMIPv6, where the bi-directional tunnel establishment is
   initiated by the NAR.

                                         PMAG            NMAG
          MN       P-AN      N-AN        (PAR)           (NAR)     LMA
          |         |         |            |               |        |
     (a) ~~~        |         |            |               |        |
         ~~~        |         |            |               |        |
          |  MN-AN connection |       AN-MAG connection    |        |
     (b)  |<--establishment-->|<-------establishment------>|        |
          |(MN ID, Old AP ID) |     (MN ID, Old AP ID)     |        |
          |         |         |(substitute for UNA and FBU)|        |
          |         |         |            |               |        |
          |         |         |            |      HI       |        |
     (c)  |         |         |            |<---(MN ID) ---|        |
          |         |         |            |               |        |
          |         |         |            |     HAck      |        |
     (d)  |         |         |            |---(MN ID, --->|        |
          |         |         |            | MN IID, LMAA) |        |
          |         |         |            |               |        |
     (e)  |         |         |          #=|<=======================|
          |         |         |          #================>|=#      |
          |<====================DL data======================#      |
          |         |         |            |               |        |
     (f)  |=====================UL data===================>|=#      |
          |         |         |          #=|<================#      |
          |         |         |          #=========================>|
          |         |         |            |               |        |
     /    |         |         |            |               |        | \
     |(g) |         |         |            |               |--PBU-->| |
     |    |         |         |            |               |        | |
     |(h) |         |         |            |               |<--PBA--| |
     \    |         |         |            |               |        | /

        Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)

   The detailed descriptions are as follows:

   (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
        on the old link may be provided by the MN to help identify the
        PMAG on the new link.

   (b)  The MN establishes a connection (e.g., radio channel) with the
        N-AN, which triggers the establishment of the connection between
        the N-AN and NAR.  The MN ID is transferred to the NAR for the
        subsequent procedures.  The AP-ID on the old link may also be
        provided by the MN to help identify the PMAG on the new link.
        This can be regarded as a substitute for the UNA and FBU.



Yokota, et al.          Expires October 23, 2009               [Page 13]

Internet-Draft          Proxy-based Fast Handover             April 2009


   (c)  The NAR sends the HI to the PAR.  The HI message MUST include
        the MN ID.  The Context Request Option MAY be included to
        request additional context information on the MN to the PAR.

   (d)  The PAR sends the HAck back to the NAR.  The HAck message MUST
        include the HNP and/or IPv4-MN-HoA that is corresponding to the
        MN ID in the HI message and SHOULD include the MN-IID and the
        LMA address that is currently serving the MN.  The context
        information requested by the NAR MUST be included.

   (e)  If F flag in the HI is set, a bi-directional tunnel is
        established between the PAR and NAR and packets destined for the
        MN are forwarded from the PAR to the NAR over this tunnel.
        After decapsulation, those packets are delivered to the MN via
        the N-AN.

   (f)  The uplink packets from the MN are sent to the NAR via the N-AN
        and the NAR forwards them to the PAR.  The PAR then sends the
        packets to the LMA that is currently serving the MN.

   Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover
   procedures.

   In step (c), The IP address of the PAR needs to be resolved by the
   NAR to send the HI to the PAR.  This information may come from the
   N-AN or some database that the NAR can access.

4.2.  Inter-AR Tunneling Operation

   When the PMAG (PAR) or NMAG (NAR), depending on the fast handover
   mode, receives the HI message with the F flag set, it prepares to
   send/receive the MN's packets to/from the other MAG and returns the
   HAck message with the same sequence number.  The necessary
   information MUST be transferred in the HI message to distinguish MN's
   packets for forwarding in advance or at this time.  Such information
   includes the HoA of the MN and/or GRE key(s).  For the downlink
   packets, the PMAG redirects MN's packets from the LMA towards the
   NMAG and if the MN is ready to receive those packets or the N-AN can
   handle them regardless of the state of the MN, the NAR should
   immediately send them towards the N-AN; otherwise it should buffer
   them until the MN is ready.  For the uplink packets, the NMAG SHOULD
   redirect them from the MN towards the PMAG and the PMAG sends them to
   the LMA.  Depending on the implementation, the NMAG MAY send them
   directly to the LMA.

   When the PMAG or NMAG receives the HI message with the U flag set, it
   prepares to buffer the MN's packets and returns the HAck message with
   the same sequence number.  It MUST be followed by another HI message



Yokota, et al.          Expires October 23, 2009               [Page 14]

Internet-Draft          Proxy-based Fast Handover             April 2009


   with the F flag set at an appropriate time to forward the buffered
   packets.

   If the MAG that received the HI message encounters an erroneous
   situation (e.g., insufficient buffer space), it SHOULD immediately
   send the HAck message with the cause of the error and cancel all
   tunneling operation.

4.3.  IPv4 Support Considerations

   The motivation and usage scenarios of IPv4 protocol support by PMIPv6
   are described in [IPv4PMIPv6].  The scope of IPv4 support covers the
   following two features:

   o  IPv4 Home Address Mobility Support, and

   o  IPv4 Transport Support.

   As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
   Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
   transfer IPv4-MN-HoA to the NMAG, which is the inner destination
   address of the packets forwarded on the downlink.  For this purpose,
   a new option called IPv4 Address Option is defined in this document.
   In order to provide IPv4 Transport Support, the NMAG needs to know
   the IPv4 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling
   messages to the LMA in the IPv4 transport network.  In this case, a
   new option called LMA Address (LMAA) option is used so as to convey
   IPv4-LMAA from the PMAG to NMAG.  The supported encapsulation type
   follows Section 6.10.2 in [RFC5213], that is, IPv4, IPv4-UDP and
   IPv4-UDP-TLV.





















Yokota, et al.          Expires October 23, 2009               [Page 15]

Internet-Draft          Proxy-based Fast Handover             April 2009


5.  PMIPv6-related Fast Handover Issues

   The protocol specified in this document enables the NMAG to obtain
   parameters which would otherwise be available only by communicating
   with the LMA.  For instance, the HNP and/or IPv4-MN-HoA of a MN are
   made available to the NMAG through context transfer.  This allows the
   NMAG to perform some procedures that may be beneficial.  For
   instance, the NMAG could send a Router Advertisement (RA) with the
   HNP option to the MN as soon as it's link attachment is detected
   (e.g., via receipt of a Router Solicitation message).  Such an RA is
   recommended, for example, in scenarios where the MN uses a new radio
   interface while attaching to the NMAG; since the MN does not have
   information regarding the new interface, it will not be able to
   immediately send packets without first receiving an RA with HNP.
   Especially, in the reactive fast handover, the NMAG gets to know the
   HNP assigned to the MN on the previous link at step (d) in Figure 3.
   In order to reduce the communication disruption time, the NMAG SHOULD
   accept the MN to keep using the same HNP and to send uplink packets
   before that step upon MN's request.  However, if the HAck from the
   PMAG returns a different HNP or the subsequent PMIPv6 binding
   registration for the HNP fails for some reason, then the NMAG MUST
   withdraw the advertised HNP by sending another RA with zero prefix
   lifetime for the HNP in question.  This operation is the same as
   described in Section 6.12 of [RFC5213].

   The protocol specified in this document is applicable regardless of
   whether link-layer addresses are used between a MN and its access
   router.  A MN should be able to continue sending packets on the
   uplink even when it changes link.  When link-layer addresses are
   used, the MN performs Neighbor Unreachability Detection (NUD)
   [RFC4861], after attaching to a new link, probing the reachability of
   its default router.  If the new router's interface is configured to
   respond to queries sent to link-layer addresses than its own (e.g.,
   set to promiscuous mode), then it can respond to the NUD probe,
   providing its link-layer address in the solicited Neighbor
   Advertisement.  Implementations should allow the MN to continue to
   send uplink packets while it is performing NUD.














Yokota, et al.          Expires October 23, 2009               [Page 16]

Internet-Draft          Proxy-based Fast Handover             April 2009


6.  Message Formats

   This document defines new Mobility Header messages for the extended
   HI and Hack and new mobility options for conveying context
   information.

6.1.  Mobility Header

6.1.1.  Handover Initiate (HI)

   This section defines extensions to the HI message in [RFC5268bis].
   The format of the Message Data field in the Mobility Header is as
   follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-------------------------------+
                                     |           Sequence #          |
     +-+-+-+---------+---------------+-------------------------------+
     |S|U|F|Reserved |      Code     |                               |
     +-+-+-+---------+---------------+                               |
     |                                                               |
     .                                                               .
     .                       Mobility options                        .
     .                                                               .
     |                                                               |
     +---------------------------------------------------------------+

   IP Fields:

   Source Address

                       The IP address of PMAG or NMAG

   Destination Address

                       The IP address of the peer MAG

   Message Data:

   Sequence #  Same as [RFC5268bis].

   S flag      Defined in [RFC5268bis] and MUST be set to zero in this
               specification.







Yokota, et al.          Expires October 23, 2009               [Page 17]

Internet-Draft          Proxy-based Fast Handover             April 2009


   U flag      Buffer flag.  Same as [RFC5268bis].

   F flag      Forwarding flag.  Used to request to forward the packets
               for the MN.

   Reserved    Same as [RFC5268bis].

   Code        [RFC5268bis] defines this field and its values 0 and 1.
               In this specification, if F flag is not set, this field
               MUST be set to zero.  Otherwise, it has the following
               meaning:

                         2: Forwarding is not requested

                         3: Request forwarding

                         4: Indicate the completion of forwarding

   Mobility options:

   This field contains one or more mobility options, whose encoding and
   formats are defined in [RFC3775].  At least one mobility option MUST
   uniquely identify the target MN (e.g., the Mobile Node Identifier
   Option defined in RFC4283) and the transferred context MUST be for
   one MN per message.  In addition, the NAR can request necessary
   mobility options by the Context Request Option defined in this
   document.

   Context Request Option

            This option MAY be present to request context information
            typically by the NAR to the PAR in the NAR-initiated fast
            handover.

6.1.2.  Handover Acknowledge (HAck)

   This section defines extensions to the HAck message in[RFC5268bis].
   The format of the Message Data field in the Mobility Header is as
   follows:












Yokota, et al.          Expires October 23, 2009               [Page 18]

Internet-Draft          Proxy-based Fast Handover             April 2009


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-------------------------------+
                                     |           Sequence #          |
     +-+-+-----------+---------------+-------------------------------+
     |U|F| Reserved  |      Code     |                               |
     +-+-+-----------+---------------+                               |
     |                                                               |
     .                                                               .
     .                       Mobility options                        .
     .                                                               .
     |                                                               |
     +---------------------------------------------------------------+

   IP Fields:

   Source Address

                       Copied from the destination address of the
                       Handover Initiate message to which this message
                       is a response.

   Destination Address

                       Copied from the source address of the Handover
                       Initiate message to which this message is a
                       response.

   Message Data:

   The usages of Sequence # and Reserved fields are exactly the same as
   those in [RFC5268bis].

   U, F flags  Same as defined in Section 6.1.1.

   Code
               Code values 0 through 4 and 128 through 130 are defined
               in [RFC5268bis].  In this specification, the meaning of
               Code value 0 is modified, 128 through 130 are reused, and
               5, 6, 131 and 132 are newly defined.

                       0: Handover Accepted

                       5: Context Transfer Successful or Accepted







Yokota, et al.          Expires October 23, 2009               [Page 19]

Internet-Draft          Proxy-based Fast Handover             April 2009


                       6: All available Context Transferred

                       128: Handover Not Accepted, reason unspecified

                       129: Administratively prohibited

                       130: Insufficient resources

                       131: Requested Context Not Available

                       132: Forwarding Not Available

   Mobility options:

   This field contains one or more mobility options, whose encoding and
   formats are defined in [RFC3775].  The mobility option that uniquely
   identifies the target MN MUST be copied from the corresponding HI
   message and the transferred context MUST be for one MN per message.

   Requested option(s)  All the context information requested by the
             Context Request Option in the HI message SHOULD be present
             in the HAck message.  The other cases are described below.

   In the case of the PAR-initiated fast handover, when the PAR sends
   the HI message to the NAR with the context information and the NAR
   successfully receives it, the NAR returns the HAck message with Code
   value 5.  In the case of the NAR-initiated fast handover, when the
   NAR sends the HI message to the PAR with or without Context Request
   Option, the PAR returns the HAck message with the requested or
   default context information (if any).  If all available context
   information is transferred, the PAR sets the Code value in the HAck
   message to 6.  If more context information is available, the PAR sets
   the Code value in the HAck to 5 and the NAR MAY send new HI
   message(s) to retrieve the rest of the available context information.
   If none of the requested context information is available, the PAR
   returns the HAck message with Code value 131 without any context
   information.

6.2.  Mobility Options

6.2.1.  Context Request Option

   This option is sent in the HI message to request context information
   on the MN.  If a default set of context information is defined and
   always sufficient, this option is not mandatory.  This option is more
   useful to retrieve additional or dynamically selected context
   information.




Yokota, et al.          Expires October 23, 2009               [Page 20]

Internet-Draft          Proxy-based Fast Handover             April 2009


   Context Request Option is typically used for the reactive (NAR-
   initiated) fast handover mode to retrieve the context information
   from the PAR.  When this option is included in the HI message, all
   the requested context information SHOULD be included in the HAck
   message in the corresponding mobility option(s) (e.g., HNP, LMAA or
   MN-IID mobility options).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |  Option-Type  | Option-Length |           Reserved            |
     +---------------+---------------+-------------------------------+
     |  Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
     +---------------------------------------------------------------+
     |                              ...                              |

   Option-Type    TBD1

   Option-Length  The length in octets of this option, not including the
                  Option Type and Option Length fields.

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.

   Req-type-n     The type value for the n'th requested option.

   Req-length-n   The length of the n'th requested option excluding the
                  Req-type-n and Req-length-n fields.

   In the case where there are only Req-type-n and Req-length-n fields,
   the value of the Req-length-n is set to zero.  If additional
   information besides the Req-type-n is necessary to uniquely specify
   the requested context, such information follows after the
   Req-length-n.  For example, when the requested context is the Vendor-
   Specific Option described in Section 6.2.8, the requested option
   format looks as follows:

     |                              ...                              |
     +---------------+---------------+-------------------------------+
     | Req-type-N=19 | Req-length-N=5|           Vendor-ID           |
     +-------------------------------+---------------+---------------+
     |           Vendor-ID           |   Sub-Type    |               |
     +-----------------------------------------------+               |
     |                              ...                              |

   The exact values in the Vendor-ID and Sub-Type are outside the scope
   of this document.




Yokota, et al.          Expires October 23, 2009               [Page 21]

Internet-Draft          Proxy-based Fast Handover             April 2009


6.2.2.  Local Mobility Anchor Address (LMAA) Option

   This option is used to transfer the Local Mobility Anchor IPv6
   Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is
   currently registered.  The detailed definition of the LMAA is
   described in [RFC5213].

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option-Type  | Option-Length |  Option-Code  |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Local Mobility Anchor Address ...                |

   Option-Type    TBD2

   Option-Length  18 or 6

   Option-Code

                  0  Reserved

                  1  IPv6 address of the LMA (LMAA)

                  2  IPv4 address of the LMA (IPv4-LMAA)

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.

   Local Mobility Anchor Address
                  If Option-Code is 1, the LMA IPv6 address (LMAA) is
                  inserted.  If Option-Code is 2, the LMA IPv4 address
                  (IPv4-LMA) is inserted.

6.2.3.  IPv4 Address Option

   As described in Section 4.3, if the MN is IPv4-only mode or dual-
   stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
   option has alignment requirement of 4n.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option-Type   | Option-Length |  Option-Code  |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      IPv4 Address                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Yokota, et al.          Expires October 23, 2009               [Page 22]

Internet-Draft          Proxy-based Fast Handover             April 2009


   Option-Type    TBD3

   Option-Length  6

   Option-Code

                  0  Reserved

                  1  IPv4-MN-HoA

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.

   IPv4 Address   IPv4 address specified in Option-Code

6.2.4.  Home Network Prefix Option

   This option is used to transfer the home network prefix that is
   assigned to the MN in the P-AN.  The Home Network Prefix Option
   defined in [RFC5213] is used for this.

6.2.5.  Mobile Node Interface Identifier (MN IID) Option

   This option is used to transfer the interface identifier of the MN
   that is used in the P-AN.  The Mobile Node Interface Identifier
   Option defined in [RFC5213] is used for this.

6.2.6.  Link-local Address Option

   This option is used to transfer the link-local address of the PAR
   (PMAG).  The Link-local Address Option defined in [RFC5213] is used
   for this.

6.2.7.  GRE Key Option

   This option is used to transfer the GRE Key for the MN's data flow
   over the bi-directional tunnel between the PAR and NAR.  The message
   format of this option follows the GRE Key Option defined in [GREKEY].
   The GRE Key value uniquely identifies each flow and the sender of
   this option expects to receive packets of the flow from the peer AR
   with this value.

6.2.8.  Vendor-Specific Mobility Option

   This option is used to transfer any other information defined in this
   document.  The format of this option follows the Vendor-Specific
   Mobility Option defined in [RFC5094].  The exact values in the Vendor
   ID, Sub-Type and Data fields are outside the scope of this document.



Yokota, et al.          Expires October 23, 2009               [Page 23]

Internet-Draft          Proxy-based Fast Handover             April 2009


7.  Security Considerations

   Security issues for this document follow those for PMIPv6 [RFC5213]
   and FMIPv6 [RFC5268bis].  In PMIPv6, the MAG and LMA are assumed to
   share security associations.  In FMIPv6, the access routers (i.e.,
   the PMAG and NMAG in this document) are assumed to share security
   associations.

   The Handover Initiate (HI) and Handover Acknowledgement (HAck)
   messages exchanged between the PMAG and NMAG MUST be protected using
   end-to-end security association(s) offering integrity and data origin
   authentication.  The PMAG and the NMAG MUST implement IPsec [RFC4301]
   for protecting the HI and HAck messages.  IPsec Encapsulating
   Security Payload (ESP) [RFC4303] in transport mode with mandatory
   integrity protection SHOULD be used for protecting the signaling
   messages.  Confidentiality protection SHOULD be used if sensitive
   context related to the mobile node is transferred.

   IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's
   packets at the time of forwarding if protection of data traffic is
   required.






























Yokota, et al.          Expires October 23, 2009               [Page 24]

Internet-Draft          Proxy-based Fast Handover             April 2009


8.  IANA Considerations

   This document defines two new mobility options, which are described
   in Section 6.2.  The Type value for these options are assigned from
   the same numbering space as allocated for the other mobility options,
   as defined in [RFC3775].

    Mobility Options
    Value  Description                            Reference
    -----  -------------------------------------  -------------
    TBD1   Context Request Option                 Section 6.2.1
    TBD2   Local Nobility Anchor Address Option   Section 6.2.2
    TBD3   IPv4 Address Option                    Section 6.2.3






































Yokota, et al.          Expires October 23, 2009               [Page 25]

Internet-Draft          Proxy-based Fast Handover             April 2009


9.  References

9.1.  Normative References

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5268bis]
              Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
               draft-ietf-mipshop-rfc5268bis-01.txt, March 2009.

   [RFC3775]  Johnson, D., "Mobility Support in IPv6", RFC 3775,
              June 2004.

   [RFC4988]  Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
              RFC 4988, October 2007.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5094]  Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
              Vendor Specific Option", RFC 5094, December 2007.

9.2.  Informative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [IPv4PMIPv6]
              Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for
              Proxy Mobile IPv6",
               draft-ietf-netlmm-pmip6-ipv4-support-09.txt,
              January 2009.

   [GREKEY]   Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6",
               draft-ietf-netlmm-grekey-option-03.txt, January 2009.








Yokota, et al.          Expires October 23, 2009               [Page 26]

Internet-Draft          Proxy-based Fast Handover             April 2009


Appendix A.  Applicable Use Cases

A.1.  PMIPv6 Handoff Indication

   PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes
   the type of the handoff and the values to set to the option.  This
   document proposes one approach to determining the handoff type by the
   NMAG when the handoff of the MN is executed.

   According to [RFC5213], the following handoff types are defined:

      0) Reserved

      1) Attachment over a new interface

      2) Handoff between two different interfaces of the mobile node

      3) Handoff between mobile access gateways for the same interface

      4) Handoff state unknown

      5) Handoff state not changed (Re-registration)

   By using the MN Interface Identifier (MN IID) option, which is
   defined in this document, the following solution can be considered.
   When the NMAG receives the MN IID used in the P-AN from the PMAG via
   the HI or HAck messages, the NMAG compares it with the new MN IID
   that is obtained from the MN in the N-AN.  If these two MN IIDs are
   the same, the handover type falls into 3) and the Handoff Indicator
   value is set to 3.  If these two MN IIDs are different, the handover
   is likely to be 2) since the HI/HAck message exchange implies that
   this is a handover not a multi-homing, therefore the Handoff
   Indicator value can be set to 2.  If there is no HI/Hack exchange
   performed prior to the network attachment of the MN in the new
   network, the NMAG may infer that this is a multi-homing case and set
   the Handoff Indicator value to 1.  In the case of re-registration,
   the MAG, to which the MN is attached, can determine if the handoff
   state is not changed, so the MAG can set the HI value to 5 without
   any additional information.  If none of them can be assumed, the NMAG
   may set the value to 4.

A.2.  Local Routing

   Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting
   flag is set, when two mobile nodes are attached to one MAG, the
   traffic between them may be locally routed.  If one mobile node moves
   from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not
   detect the MN's detachment, it will continue to forward packets



Yokota, et al.          Expires October 23, 2009               [Page 27]

Internet-Draft          Proxy-based Fast Handover             April 2009


   locally forever.  This situation is more likely to happen in the
   reactive fast handover with WLAN access, which does not have the
   capability to detect the detachment of the MN in a timely manner.
   PFMIPv6 can be applied to handle this case.  When the MN attaches to
   the NMAG, it sends the HI message to the PMAG, which makes it realize
   the detachment of the MN.  The PMAG immediately stops the local
   routing and sends the packets for the MN towards the LMA, which in
   turn forwards them to the NMAG over the PMIPv6 tunnel.

A.3.  Handling of PMIPv6/MIPv6 switching

   If the network that the MN has moved to does not support PMIPv6 but
   only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
   at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
   (e.g., at steps (k) and (l) in Figure 2).  If this is the case, the
   LMA and HA will most likely be collocated and the LMA (HA) address
   should be maintained in the new network for communication continuity.
   Since the LMA (HA) address is transferred to the NAR in the HI/HAck
   exchange, the MN can retrieve it at or after the handover by way of,
   e.g., the authentication or DHCP procedure.































Yokota, et al.          Expires October 23, 2009               [Page 28]

Internet-Draft          Proxy-based Fast Handover             April 2009


Appendix B.  Change Log

   Changes at -00

      *  Added separate sections for MH and ICMP.

      *  Clarified usage of HNP and IPv4-MN-HoA throughout the document.

      *  Added IANA Considerations.

      *  Added section on Other Considerations, including operation of
         uplink packets when using link-layer addresses, multiple
         interface usage and transmission of RA to withdraw HNP in the
         event of failure of PMIP6 registration.

      *  Revised Security Considerations.

   Changes from -00 to -01

      *  Removed ICMPv6-based message format.

      *  Clarified HI/HAck exchange in the predictive mode (step (e) in
         Figure 2).

      *  Clarified information retrieval about the PMAG in the reactive
         mode.

      *  Removed the extension to the GRE Key Option.

      *  Clarified the handoff type considerations in Appendix A.

      *  Home Network Prefix Option, Link-local Address Option and
         Vendor-Specific Mobility Option are added.

   Changes from -01 to -02

      *  Aligned HI/HAck message formats with [RFC5268bis]
         (draft-ietf-mipshop-rfc5268bis-00.txt).

      *  Revised Section 8 removing the request for the type assignment
         of HI/HAck Mobility Headers.

   Changes from -02 to -03

      *  Updated HI/HAck message formats according to
         draft-ietf-mipshop-rfc5268bis-01.txt.





Yokota, et al.          Expires October 23, 2009               [Page 29]

Internet-Draft          Proxy-based Fast Handover             April 2009


      *  Cleaned up Figure 2 and Figure 3.

      *  Moved PMIP domain boundary crossing situation in Section 4.1 to
         Appendix A.3.

      *  Removed the alternative protocol operation with an unsolicited
         HAck from Section 4.1.

      *  Modified Code values in the HAck message in order to avoid
         collision with those in [RFC5268bis].

      *  Clarified the usage scenarios of Context Request Option.

      *  Modified the description of Code values in the HAck message.

      *  Changed the container for the IPv4-LMAA from IPv4 Address
         option to the LMAA option.

      *  Made Confidentiality protection "SHOULD" for context transfer.
































Yokota, et al.          Expires October 23, 2009               [Page 30]

Internet-Draft          Proxy-based Fast Handover             April 2009


Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Email: [hidden email]


   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   US

   Email: [hidden email]


   Rajeev Koodli
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   US

   Email: [hidden email]


   Basavaraj Patil
   Nokia
   6000 Connection Drive
   Irving, TX  75039
   US

   Email: [hidden email]


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   US

   Email: [hidden email]






Yokota, et al.          Expires October 23, 2009               [Page 31]


_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop