Comments on draft-ietf-mipshop-pfmipv6-02.txt

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

Comments on draft-ietf-mipshop-pfmipv6-02.txt

Devarapalli, Vijay
Hello,

I reviewed the document. It still needs a fair amount of work before we
can start a WG last call.

>    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.

Perhaps you should briefly mention what FMIPv6 does.

> 2.  Introduction
>
>    Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>    that does not possess Mobile IPv6 [RFC3775] functionality.  

s/Mobile IPv6 [RFC3775] functionality/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.  

You have used "mobile node" earlier in the paragraph.

> 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 is specified in [RFC5268bis].  This
>    document applies the same Fast Handovers protocol for Proxy Mobile
>    IPv6 (PFMIPv6), in order to provide handover delay, packet loss and
>    transfer of network-resident contexts.  

You should use "minimize handover delay, reduce packet loss, etc...". It
would be bad if the protocol provides handover delay and packet loss. :)

>    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).

Need to explicitly mention that this message is not being defined in
this document.

>
>                                   +----------+
>                                   |   LMA    |
>                                   |          |
>                                   +----------+
>                                     /      \
>                                    /        \
>                                   /          \
>                       +........../..+      +..\..........+
>                       . +-------+-+ .______. +-+-------+ .
>                       . |   PAR   |()_______)|   NAR   | .
>                       . |  (PMAG) | .      . |  (NMAG) | .
>                       . +----+----+ .      . +----+----+ .
>                       .      |      .      .      |      .
>                       .   ___|___   .      .   ___|___   .
>                       .  /       \  .      .  /       \  .
>                       . (  P-AN   ) .      . (  N-AN   ) .
>                       .  \_______/  .      .  \_______/  .
>                       .      |      .      .      |      .
>                       .   +----+    .      .   +----+    .
>                       .   | MN |  ---------->  | MN |    .
>                       .   +----+    .      .   +----+    .
>                       +.............+      +.............+
>
>                Figure 1: Reference network for fast handover

You have to mention somewhere that "P-AN" and "N-AN" refer to the radio
elements of the access network. The PAR and the NAR are the first hop
routers for the mobile node. So when you say there is a network between
the MN and the PAR/NAR, it is confusing.

>                                             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)  |           |          |            |<- - - - ->|        |

What is this HI/HACK for? Later in the text you say

    (e)  The NAR may optionally request the PAR to buffer or forward
         packets by setting U or F flags in the HI message, respectively.

Is this exchange just for indicating the two flags, 'U' and 'F'? Is
there anything else sent in this HI/HACK exchange?

         This step may be combined with steps (c) and (d).

How? In step (c), the HI goes from PAR to NAR. In step (e), the HI goes
from NAR to PAR. How can you combine the two? Or did you mean, the NAR
can send a HI as soon as it receives a HI from the PAR before responding
with a HACK? It is confusing.

>      (f)  |           |          |            |==DL data=>|        |

Don't you have to show the "DL data" from the LMA to the PAR before
showing the "DL data" from the PAR to the NAR?

>           |           |          |            |           |        |
>      (g) ~~~          |          |            |           |        |
>          ~~~          |          |            |           |        |
>           |   MN-AN connection   |    AN-MAG connection   |        |
>      (h)  |<---establishment---->|<----establishment----->|        |
>           |           |          |  (substitute for UNA)  |        |
>           |           |          |            |           |        |
>      (i)  |<==================DL data=====================|        |
>           |           |          |            |           |        |
>      (j)  |===================UL data====================>|#       |
>           |           |          |           #|<==========|#       |
>           |           |          |           #|===================>|
>           |           |          |            |HI/HAck(optional)   |
>      (k)  |           |          |            |<- - - - ->|        |

I did not understand the purpose of this HI/HACK at all.

>    (b)  The previous access network (P-AN), to which the MN is currently
>         attached, indicates the handover of the MN to the PAR (PMAG).

Again, mention that this message is out of scope.

>    (k)  The PAR MAY send the HI message to indicate that the packet
>         forwarding is completed.

When does the PAR send this message? The PAR has no idea that the
binding cache entry at the LMA has been updated with the NAR's address
and therefore no more traffic meant for the MN will come to the PAR. I
suggest removing this.

>    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
>    in steps (j) and (k).  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 step (c), the MN can retrieve it
>    at or after step (g) by e.g. the authentication or DHCP procedure
>    (not shown in the figure).

Perhaps this paragraph should be moved to an appendix that explains what
happens when the mobile node moves out of a PMIPv6 domain. It is
distracting in the current position.

>    (g)  The PAR MAY send the HI message to indicate that the packet
>         forwarding is completed.

Same issue as before. How does the PAR figure out when to send the HI
message?

>    Also, in step (c), the NAR could send an unsolicited HAck message to
>    the PAR, which then triggers the HI message from the PAR.  By doing
>    so, the directions of HI/HAck messages are aligned with the
>    predictive (PAR-initiated) fast handover.  Further study is needed if
>    this call flow is more appropriate than the current one.

Why have two mechanisms for the same? The NAR could just send a HI and
get the response in a HACK message. Why bother sending an unsolicited
HACK message? And what do you mean by "Further Study"? Are you saying we
don't enough to say whether the NAR should send a HI message or an
unsolicited HACK message for a reactive handover? So both options are
allowed. (?)

> 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      Must be set to zero (defined in [RFC5268bis]).
>
>    U flag      Buffer flag.  Same as [RFC5268bis].
>
>    F flag      Forwarding flag.  Used to request to forward the packets
>                for the MN.

You should describe the 'F' flag here and refer to 5268bis for all other
  fields.

>    Code        If F flag is not set, the Code MUST be set to zero.
>                Otherwise, the Code value has the following meaning:
>
>                          0: Reserved
>
>                          1: Forwarding is not requested
>
>                          2: Request forwarding
>
>                          3: Indicate the completion of forwarding

There is an issue here. 5268bis already has semantics for code set to
'0' and '1'. I think you should start at '2' in this document.

> 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:
>
>
>       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 #          |
>      +-------------------------------+---------------+---------------+
>      |                       Reserved                |     Code      |
>      +-----------------------------------------------+---------------+
>      |                                                               |
>      .                                                               .
>      .                       Mobility options                        .
>      .                                                               .
>      |                                                               |
>      +---------------------------------------------------------------+

Since this document is not making any change to the HACK message format,
do you need to show the message here? Perhaps you can just refer to 5268bis.

>                        5: Context Transferred successfully, more context
>                        available

What does this mean? Is it saying there will be more unsolicited HACK
messages that follow with more context? If so, how are they all
correlated at the NAR? If not, does it mean the NAR has to send more HI
messages to get more context from the PAR?

> 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.
>
>       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  |
>      +---------------------------------------------------------------+
>      |                              ...                              |

What does the above format mean? Where is the data in each request? Is
it just request type and request length? Does Req-type use the same name
space as mobility options? If so, this creates a problem. Mobility
options are supposed to be carried in a mobility header message. Here
you carrying the mobility options in another mobility option (Context
Request Option).

If you are not using the same name space as mobility options, are you
creating a new name space for the "Req-type" field?

>    Context Request Option is typically used for the reactive (NAR-

How come there is no "Context Response option" defined?

>    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 defined in Section 6.2.8, the requested option format
>    looks as follows:
>
>      |                              ...                              |
>      +---------------+---------------+-------------------------------+
>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>      +-------------------------------+-------------------------------+
>      |           Vendor-ID           |           Sub-Type            |
>      +---------------------------------------------------------------+
>      |                              ...                              |

I don't think a Vendor Specific Mobility Option can be a sub-option of
the Context Request Mobility Option.

> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>
>    This option is used to transfer the Local Mobility Anchor Address
>    (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 |          Reserved             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +                 Local Mobility Anchor Address                 +
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Why don't you add a field here that indicates whether you are carrying
the IPv4 address or the IPv6 address of the LMA? I don't like the fact
that you have a LMA address option for carrying the IPv6 address of the
LMA, and another IPv4 address option that can carry either the IPv4
address of the LMA or the mobile node.

> 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 format of this option follows
>    the Home Network Prefix Option defined in [RFC5213].

Re-word the last sentence to

   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 format of this option follows the
>    Mobile Node Interface Identifier Option defined in [RFC5213].

Re-word the last sentence as

   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 format of this option follows the Link-local Address
>    Option defined in [RFC5213].

Same as above.

> 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, but support for confidentiality
>    is not necessary.

I think you need support for confidentiality protection if there is some
sensitive MN context is being transfered. You should say
"Confidentiality protection SHOULD be used if sensitive context related
to the mobile node is being transferred".

> 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

This would need revision if we conclude that existing mobility options
cannot become sub-options of the Context Request mobility option.

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

Re: Comments on draft-ietf-mipshop-pfmipv6-02.txt

Hidetoshi Yokota
Hi Vijay,

Thanks a lot for your detailed review and very sorry for this late
response. A tentatively revised version is attached and the responses to
your comments are in line:

Vijay Devarapalli wrote:

> Hello,
>
> I reviewed the document. It still needs a fair amount of work before we
> can start a WG last call.
>
>>    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.
>
> Perhaps you should briefly mention what FMIPv6 does.
The following paragraph is added:

   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.

>> 2.  Introduction
>>
>>    Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>>    that does not possess Mobile IPv6 [RFC3775] functionality.  
>
> s/Mobile IPv6 [RFC3775] functionality/Mobile IPv6 [RFC3775] mobile node
> functionality/

Revised.

>> 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.  
>
> You have used "mobile node" earlier in the paragraph.

Revised.

>> 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 is specified in [RFC5268bis].  This
>>    document applies the same Fast Handovers protocol for Proxy Mobile
>>    IPv6 (PFMIPv6), in order to provide handover delay, packet loss and
>>    transfer of network-resident contexts.  
>
> You should use "minimize handover delay, reduce packet loss, etc...". It
> would be bad if the protocol provides handover delay and packet loss. :)
Revised.

>>    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).
>
> Need to explicitly mention that this message is not being defined in
> this document.
The following sentence is added:

Detailed definition of this message is outside the scope of this document.

>>
>>                                   +----------+
>>                                   |   LMA    |
>>                                   |          |
>>                                   +----------+
>>                                     /      \
>>                                    /        \
>>                                   /          \
>>                       +........../..+      +..\..........+
>>                       . +-------+-+ .______. +-+-------+ .
>>                       . |   PAR   |()_______)|   NAR   | .
>>                       . |  (PMAG) | .      . |  (NMAG) | .
>>                       . +----+----+ .      . +----+----+ .
>>                       .      |      .      .      |      .
>>                       .   ___|___   .      .   ___|___   .
>>                       .  /       \  .      .  /       \  .
>>                       . (  P-AN   ) .      . (  N-AN   ) .
>>                       .  \_______/  .      .  \_______/  .
>>                       .      |      .      .      |      .
>>                       .   +----+    .      .   +----+    .
>>                       .   | MN |  ---------->  | MN |    .
>>                       .   +----+    .      .   +----+    .
>>                       +.............+      +.............+
>>
>>                Figure 1: Reference network for fast handover
>
> You have to mention somewhere that "P-AN" and "N-AN" refer to the radio
> elements of the access network. The PAR and the NAR are the first hop
> routers for the mobile node. So when you say there is a network between
> the MN and the PAR/NAR, it is confusing.
The following definition is added in the Terminology section:

   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.

>>                                             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)  |           |          |            |<- - - - ->|        |
>
> What is this HI/HACK for? Later in the text you say
>
>    (e)  The NAR may optionally request the PAR to buffer or forward
>         packets by setting U or F flags in the HI message, respectively.
>
> Is this exchange just for indicating the two flags, 'U' and 'F'? Is
> there anything else sent in this HI/HACK exchange?
The later the timing of buffering becomes, the shorter the handover
latency will be, so now the spec clarifies that HI/HAck exchanges could
happen multiple times: one for the context transfer, another for the
trigger for buffering.

>         This step may be combined with steps (c) and (d).

The above sentence was deleted.

> How? In step (c), the HI goes from PAR to NAR. In step (e), the HI goes
> from NAR to PAR. How can you combine the two? Or did you mean, the NAR
> can send a HI as soon as it receives a HI from the PAR before responding
> with a HACK? It is confusing.

Step (e) now has the following sentences:

   (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)  |           |          |            |==DL data=>|        |
>
> Don't you have to show the "DL data" from the LMA to the PAR before
> showing the "DL data" from the PAR to the NAR?

Revised.

>>           |           |          |            |           |        |
>>      (g) ~~~          |          |            |           |        |
>>          ~~~          |          |            |           |        |
>>           |   MN-AN connection   |    AN-MAG connection   |        |
>>      (h)  |<---establishment---->|<----establishment----->|        |
>>           |           |          |  (substitute for UNA)  |        |
>>           |           |          |            |           |        |
>>      (i)  |<==================DL data=====================|        |
>>           |           |          |            |           |        |
>>      (j)  |===================UL data====================>|#       |
>>           |           |          |           #|<==========|#       |
>>           |           |          |           #|===================>|
>>           |           |          |            |HI/HAck(optional)   |
>>      (k)  |           |          |            |<- - - - ->|        |
>
> I did not understand the purpose of this HI/HACK at all.
The intention of this step is to send a trigger to the PAR to tear down
the forwarding tunnel. But, it should happen after the PBU/PBA. This
step was removed.

>>    (b)  The previous access network (P-AN), to which the MN is currently
>>         attached, indicates the handover of the MN to the PAR (PMAG).
>
> Again, mention that this message is out of scope.

The following sentence is added:

        Detailed definition and specification of this message are
        outside the scope of this document.

>>    (k)  The PAR MAY send the HI message to indicate that the packet
>>         forwarding is completed.
>
> When does the PAR send this message? The PAR has no idea that the
> binding cache entry at the LMA has been updated with the NAR's address
> and therefore no more traffic meant for the MN will come to the PAR. I
> suggest removing this.

Removed.

>>    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
>>    in steps (j) and (k).  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 step (c), the MN can retrieve it
>>    at or after step (g) by e.g. the authentication or DHCP procedure
>>    (not shown in the figure).
>
> Perhaps this paragraph should be moved to an appendix that explains what
> happens when the mobile node moves out of a PMIPv6 domain. It is
> distracting in the current position.
This paragraph was moved to Appendix A.2.

>>    (g)  The PAR MAY send the HI message to indicate that the packet
>>         forwarding is completed.
>
> Same issue as before. How does the PAR figure out when to send the HI
> message?

Removed.

>>    Also, in step (c), the NAR could send an unsolicited HAck message to
>>    the PAR, which then triggers the HI message from the PAR.  By doing
>>    so, the directions of HI/HAck messages are aligned with the
>>    predictive (PAR-initiated) fast handover.  Further study is needed if
>>    this call flow is more appropriate than the current one.
>
> Why have two mechanisms for the same? The NAR could just send a HI and
> get the response in a HACK message. Why bother sending an unsolicited
> HACK message? And what do you mean by "Further Study"? Are you saying we
> don't enough to say whether the NAR should send a HI message or an
> unsolicited HACK message for a reactive handover? So both options are
> allowed. (?)
There was a debate with Rajeev whether the direction of the HI should
always be the same (from PAR to NAR) and not the other way. FFS was put
for that moment, but now it's time to resolve it:-) I don't mind
deleting this sentence, but let's discuss it beforehand.

>> 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      Must be set to zero (defined in [RFC5268bis]).
>>
>>    U flag      Buffer flag.  Same as [RFC5268bis].
>>
>>    F flag      Forwarding flag.  Used to request to forward the packets
>>                for the MN.
>
> You should describe the 'F' flag here and refer to 5268bis for all other
>  fields.
I put the reference to 5268bis at all the relevant fields.

>>    Code        If F flag is not set, the Code MUST be set to zero.
>>                Otherwise, the Code value has the following meaning:
>>
>>                          0: Reserved
>>
>>                          1: Forwarding is not requested
>>
>>                          2: Request forwarding
>>
>>                          3: Indicate the completion of forwarding
>
> There is an issue here. 5268bis already has semantics for code set to
> '0' and '1'. I think you should start at '2' in this document.
Revised.

>> 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:
>>
>>
>>       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 #          |
>>      +-------------------------------+---------------+---------------+
>>      |                       Reserved                |     Code      |
>>      +-----------------------------------------------+---------------+
>>      |                                                               |
>>      .                                                               .
>>      .                       Mobility options                        .
>>      .                                                               .
>>      |                                                               |
>>      +---------------------------------------------------------------+
>
> Since this document is not making any change to the HACK message format,
> do you need to show the message here? Perhaps you can just refer to
> 5268bis.
Revised.

>>                        5: Context Transferred successfully, more context
>>                        available
>
> What does this mean? Is it saying there will be more unsolicited HACK
> messages that follow with more context? If so, how are they all
> correlated at the NAR? If not, does it mean the NAR has to send more HI
> messages to get more context from the PAR?

The intention here is that the amount of the context to transfer could
be very large, so it is allowed to send the HI messages multiple times.

>> 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.
>>
>>       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  |
>>      +---------------------------------------------------------------+
>>      |                              ...                              |
>
> What does the above format mean? Where is the data in each request? Is
> it just request type and request length? Does Req-type use the same name
> space as mobility options? If so, this creates a problem. Mobility
> options are supposed to be carried in a mobility header message. Here
> you carrying the mobility options in another mobility option (Context
> Request Option).
>
> If you are not using the same name space as mobility options, are you
> creating a new name space for the "Req-type" field?
>
>>    Context Request Option is typically used for the reactive (NAR-
>
> How come there is no "Context Response option" defined?
>
>>    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 defined in Section 6.2.8, the requested option format
>>    looks as follows:
>>
>>      |                              ...                              |
>>      +---------------+---------------+-------------------------------+
>>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>>      +-------------------------------+-------------------------------+
>>      |           Vendor-ID           |           Sub-Type            |
>>      +---------------------------------------------------------------+
>>      |                              ...                              |
>
> I don't think a Vendor Specific Mobility Option can be a sub-option of
> the Context Request Mobility Option.
This option is to request necessary contexts typically from the NAR, so
this doesn't include any values, which are supposed to be transferred
later from the PAR. This is similar to the DHCP Option Request Option.

>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>
>>    This option is used to transfer the Local Mobility Anchor Address
>>    (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 |          Reserved             |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                                                               |
>>      +                                                               +
>>      |                                                               |
>>      +                 Local Mobility Anchor Address                 +
>>      |                                                               |
>>      +                                                               +
>>      |                                                               |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Why don't you add a field here that indicates whether you are carrying
> the IPv4 address or the IPv6 address of the LMA? I don't like the fact
> that you have a LMA address option for carrying the IPv6 address of the
> LMA, and another IPv4 address option that can carry either the IPv4
> address of the LMA or the mobile node.
I see your point, but the "IPv4 Address Option" defined in 6.2.3 has the
Option-code to carry the IPv4 address of the LMA. Do you still prefer to
carry it by the LMAA option?

>> 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 format of this option follows
>>    the Home Network Prefix Option defined in [RFC5213].
>
> Re-word the last sentence to
>
>   The Home Network Prefix Option defined in [RFC5213] is used for this.

Revised.

>> 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 format of this option follows the
>>    Mobile Node Interface Identifier Option defined in [RFC5213].
>
> Re-word the last sentence as

Revised.

>   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 format of this option follows the Link-local Address
>>    Option defined in [RFC5213].
>
> Same as above.
Revised.

>> 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, but support for confidentiality
>>    is not necessary.
>
> I think you need support for confidentiality protection if there is some
> sensitive MN context is being transfered. You should say
> "Confidentiality protection SHOULD be used if sensitive context related
> to the mobile node is being transferred".
Revised.

>> 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
>
> This would need revision if we conclude that existing mobility options
> cannot become sub-options of the Context Request mobility option.
I haven't changed this part, yet. Let us hear your opinion about the
usage of this option.

Thanks again for your time and appreciate your further comments.

Regards,
--
Hidetoshi

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




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


            Fast Handovers for Proxy Mobile IPv6 (tentative)
                   draft-ietf-mipshop-pfmipv6-03.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 August 31, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Yokota, et al.           Expires August 31, 2009                [Page 1]

Internet-Draft          Proxy-based Fast Handover          February 2009


   to this document.


















































Yokota, et al.           Expires August 31, 2009                [Page 2]

Internet-Draft          Proxy-based Fast Handover          February 2009


Abstract

   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.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . .  8
     4.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  8
     4.2.  IPv4 Support Considerations  . . . . . . . . . . . . . . . 14
   5.  Other Considerations . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 19
       6.2.1.  Context Request Option . . . . . . . . . . . . . . . . 20
       6.2.2.  Local Mobility Anchor Address (LMAA) Option  . . . . . 21
       6.2.3.  IPv4 Address Option  . . . . . . . . . . . . . . . . . 21
       6.2.4.  Home Network Prefix Option . . . . . . . . . . . . . . 22
       6.2.5.  Mobile Node Interface Identifier (MN IID) Option . . . 22
       6.2.6.  Link-local Address Option  . . . . . . . . . . . . . . 22
       6.2.7.  GRE Key Option . . . . . . . . . . . . . . . . . . . . 22
       6.2.8.  Vendor-Specific Mobility Option  . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Other Considerations  . . . . . . . . . . . . . . . . 26
     A.1.  Handoff Indication . . . . . . . . . . . . . . . . . . . . 26
     A.2.  Handling of PMIPv6/MIPv6 switching . . . . . . . . . . . . 26
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29










Yokota, et al.           Expires August 31, 2009                [Page 3]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009                [Page 4]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009                [Page 5]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009                [Page 6]

Internet-Draft          Proxy-based Fast Handover          February 2009


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

               Figure 1: Reference network for fast handover



























Yokota, et al.           Expires August 31, 2009                [Page 7]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009                [Page 8]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009                [Page 9]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 10]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 11]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 12]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 13]

Internet-Draft          Proxy-based Fast Handover          February 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.

   Also, in step (c), the NAR could send an unsolicited HAck message to
   the PAR, which then triggers the HI message from the PAR.  By doing
   so, the directions of HI/HAck messages are aligned with the
   predictive (PAR-initiated) fast handover.  Further study is needed if
   this call flow is more appropriate than the current one.

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



Yokota, et al.           Expires August 31, 2009               [Page 14]

Internet-Draft          Proxy-based Fast Handover          February 2009


   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 August 31, 2009               [Page 15]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 16]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 17]

Internet-Draft          Proxy-based Fast Handover          February 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        Defined in [RFC5268bis].  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 is used 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.  The format of
   the Message Data field in the Mobility Header is the same as that in
   [RFC5268bis].

   IP Fields:

   Source Address

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






Yokota, et al.           Expires August 31, 2009               [Page 18]

Internet-Draft          Proxy-based Fast Handover          February 2009


   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].

   Code:

                       0: Handover Accepted

                       5: Context Transferred successfully, more context
                       available

                       6: Context Transferred successfully, no more
                       context available

                       128: Handover Not Accepted

                       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 MUST be present in
             the HAck message.  Otherwise, the Code value MUST be set to
             131.

6.2.  Mobility Options







Yokota, et al.           Expires August 31, 2009               [Page 19]

Internet-Draft          Proxy-based Fast Handover          February 2009


6.2.1.  Context Request Option

   This option is sent in the HI message to request context information
   on the MN.

      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  |
     +---------------------------------------------------------------+
     |                              ...                              |

   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, the
   requested option(s) MUST be included in the HAck message.

   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 defined in Section 6.2.8, the requested option format
   looks as follows:

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




Yokota, et al.           Expires August 31, 2009               [Page 20]

Internet-Draft          Proxy-based Fast Handover          February 2009


6.2.2.  Local Mobility Anchor Address (LMAA) Option

   This option is used to transfer the Local Mobility Anchor Address
   (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 |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                 Local Mobility Anchor Address                 +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option-Type    TBD2

   Option-Length  18

   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
                  The LMA address, with which the MN is currently
                  registered.

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).  The
   IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP
   signaling messages when the ARs and LMA are in an IPv4 transport
   network.  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 August 31, 2009               [Page 21]

Internet-Draft          Proxy-based Fast Handover          February 2009


   Option-Type    TBD3

   Option-Length  6

   Option-Code

                  0  IPv4-MN-HoA

                  1  IPv4-LMAA

   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 August 31, 2009               [Page 22]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 23]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 24]

Internet-Draft          Proxy-based Fast Handover          February 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-00.txt, February 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.

   [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 August 31, 2009               [Page 25]

Internet-Draft          Proxy-based Fast Handover          February 2009


Appendix A.  Other Considerations

A.1.  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.  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



Yokota, et al.           Expires August 31, 2009               [Page 26]

Internet-Draft          Proxy-based Fast Handover          February 2009


   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 August 31, 2009               [Page 27]

Internet-Draft          Proxy-based Fast Handover          February 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].

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

   Changes from -02 to -03

      *  T.B.D.







Yokota, et al.           Expires August 31, 2009               [Page 28]

Internet-Draft          Proxy-based Fast Handover          February 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 August 31, 2009               [Page 29]


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

Re: Comments on draft-ietf-mipshop-pfmipv6-02.txt

Devarapalli, Vijay
Hidetoshi Yokota wrote:

>>>                                             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)  |           |          |            |<- - - - ->|        |
>> What is this HI/HACK for? Later in the text you say
>>
>>    (e)  The NAR may optionally request the PAR to buffer or forward
>>         packets by setting U or F flags in the HI message, respectively.
>>
>> Is this exchange just for indicating the two flags, 'U' and 'F'? Is
>> there anything else sent in this HI/HACK exchange?
>
> The later the timing of buffering becomes, the shorter the handover
> latency will be, so now the spec clarifies that HI/HAck exchanges could
> happen multiple times: one for the context transfer, another for the
> trigger for buffering.
>
> Step (e) now has the following sentences:
>
>    (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.

Ok, but another question. If the NAR sends a HI message with only the
'U' flag set, then when it does it request the PAR to start forwarding
the packets? Does it need to send yet another HI message with the 'F'
flag set? So you could potentially end up with two HI messages from the
NAR to the PAR once the PAR sends the initial HI message.

>>>    Also, in step (c), the NAR could send an unsolicited HAck message to
>>>    the PAR, which then triggers the HI message from the PAR.  By doing
>>>    so, the directions of HI/HAck messages are aligned with the
>>>    predictive (PAR-initiated) fast handover.  Further study is needed if
>>>    this call flow is more appropriate than the current one.
>> Why have two mechanisms for the same? The NAR could just send a HI and
>> get the response in a HACK message. Why bother sending an unsolicited
>> HACK message? And what do you mean by "Further Study"? Are you saying we
>> don't enough to say whether the NAR should send a HI message or an
>> unsolicited HACK message for a reactive handover? So both options are
>> allowed. (?)
>
> There was a debate with Rajeev whether the direction of the HI should
> always be the same (from PAR to NAR) and not the other way. FFS was put
> for that moment, but now it's time to resolve it:-) I don't mind
> deleting this sentence, but let's discuss it beforehand.

This is a reactive handover. According to 5268bis, a HI is never sent
from the NAR to the PAR. So step (c) in figure 3 is new behavior. Either
of the solutions, 1) NAR sending a HI message 2) NAR sending an
unsolicited HACK message to trigger the PAR to send a HI, would work for
me. We have to pick one though.


>>>    Code        If F flag is not set, the Code MUST be set to zero.
>>>                Otherwise, the Code value has the following meaning:
>>>
>>>                          0: Reserved
>>>
>>>                          1: Forwarding is not requested
>>>
>>>                          2: Request forwarding
>>>
>>>                          3: Indicate the completion of forwarding
>> There is an issue here. 5268bis already has semantics for code set to
>> '0' and '1'. I think you should start at '2' in this document.
>
> Revised.

Can you add a sentence that says values '0' and '1' are defined in 5268bis?

>>>                        5: Context Transferred successfully, more context
>>>                        available
>> What does this mean? Is it saying there will be more unsolicited HACK
>> messages that follow with more context? If so, how are they all
>> correlated at the NAR? If not, does it mean the NAR has to send more HI
>> messages to get more context from the PAR?
>
> The intention here is that the amount of the context to transfer could
> be very large, so it is allowed to send the HI messages multiple times.

Does it mean that the NAR has to send more 'HI' messages to get the
additional context? Or does it mean the PAR would be sending more HACK
messages with the additional context?

>>> 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.
>>>
>>>       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  |
>>>      +---------------------------------------------------------------+
>>>      |                              ...                              |
>> What does the above format mean? Where is the data in each request? Is
>> it just request type and request length? Does Req-type use the same name
>> space as mobility options? If so, this creates a problem. Mobility
>> options are supposed to be carried in a mobility header message. Here
>> you carrying the mobility options in another mobility option (Context
>> Request Option).
>>
>> If you are not using the same name space as mobility options, are you
>> creating a new name space for the "Req-type" field?
>>
>>>    Context Request Option is typically used for the reactive (NAR-
>> How come there is no "Context Response option" defined?

You didn't respond to this. What is the mobility option that carries the
MN context? This mobility option would be carried in the HI message in
case of a predictive handover and the HACK message in case of a reactive
handover. Is it also called the "Context Request Option"?

>>>    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 defined in Section 6.2.8, the requested option format
>>>    looks as follows:
>>>
>>>      |                              ...                              |
>>>      +---------------+---------------+-------------------------------+
>>>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>>>      +-------------------------------+-------------------------------+
>>>      |           Vendor-ID           |           Sub-Type            |
>>>      +---------------------------------------------------------------+
>>>      |                              ...                              |
>> I don't think a Vendor Specific Mobility Option can be a sub-option of
>> the Context Request Mobility Option.
>
> This option is to request necessary contexts typically from the NAR, so
> this doesn't include any values, which are supposed to be transferred
> later from the PAR. This is similar to the DHCP Option Request Option.

So that means you don't need the length field in the following message,
since there is no data that is being transferred....

      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  |
     +---------------------------------------------------------------+
     |                              ...                              |

Are these just fixed fields in the Context Request Mobility Option? They
aren't mobility options themselves, but the Req-type field re-uses the
mobility option type namespace? That would be odd.

>>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>>
>>>    This option is used to transfer the Local Mobility Anchor Address
>>>    (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 |          Reserved             |
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>      |                                                               |
>>>      +                                                               +
>>>      |                                                               |
>>>      +                 Local Mobility Anchor Address                 +
>>>      |                                                               |
>>>      +                                                               +
>>>      |                                                               |
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Why don't you add a field here that indicates whether you are carrying
>> the IPv4 address or the IPv6 address of the LMA? I don't like the fact
>> that you have a LMA address option for carrying the IPv6 address of the
>> LMA, and another IPv4 address option that can carry either the IPv4
>> address of the LMA or the mobile node.
>
> I see your point, but the "IPv4 Address Option" defined in 6.2.3 has the
> Option-code to carry the IPv4 address of the LMA. Do you still prefer to
> carry it by the LMAA option?

I think the same option should carry both the IPv4 address and the IPv6
address of the LMA. We should not split the LMA information across two
different mobility options.

>>> 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
>> This would need revision if we conclude that existing mobility options
>> cannot become sub-options of the Context Request mobility option.
>
> I haven't changed this part, yet. Let us hear your opinion about the
> usage of this option.

I am totally confused by the "Context Request Option". I assume it goes
in the HI message from the NAR to the PAR in a reactive handover. Its
not clear what is used to carry the context from the PAR to the NAR. The
message format needs to be fixed too. Are we making existing mobility
options as sub-options of the Context Request option? Or we are defining
new sub-options but re-using the mobility options name space? (this
would be a bad idea).

> Thanks again for your time and appreciate your further comments.

No problem.

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

Re: Comments on draft-ietf-mipshop-pfmipv6-02.txt

Hidetoshi Yokota
Hi Vijay,

I'm working on the revision of document now and I'll try to answer what
I can now...

Vijay Devarapalli wrote:

> Hidetoshi Yokota wrote:
>
>>>>                                             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)  |           |          |            |<- - - - ->|        |
>>> What is this HI/HACK for? Later in the text you say
>>>
>>>    (e)  The NAR may optionally request the PAR to buffer or forward
>>>         packets by setting U or F flags in the HI message, respectively.
>>>
>>> Is this exchange just for indicating the two flags, 'U' and 'F'? Is
>>> there anything else sent in this HI/HACK exchange?
>> The later the timing of buffering becomes, the shorter the handover
>> latency will be, so now the spec clarifies that HI/HAck exchanges could
>> happen multiple times: one for the context transfer, another for the
>> trigger for buffering.
>>
>> Step (e) now has the following sentences:
>>
>>    (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.
>
> Ok, but another question. If the NAR sends a HI message with only the
> 'U' flag set, then when it does it request the PAR to start forwarding
> the packets? Does it need to send yet another HI message with the 'F'
> flag set? So you could potentially end up with two HI messages from the
> NAR to the PAR once the PAR sends the initial HI message.

Yes, now the spec allows for multiple HI/Hack exchanges if appropriate.

>>>>    Also, in step (c), the NAR could send an unsolicited HAck message to
>>>>    the PAR, which then triggers the HI message from the PAR.  By doing
>>>>    so, the directions of HI/HAck messages are aligned with the
>>>>    predictive (PAR-initiated) fast handover.  Further study is needed if
>>>>    this call flow is more appropriate than the current one.
>>> Why have two mechanisms for the same? The NAR could just send a HI and
>>> get the response in a HACK message. Why bother sending an unsolicited
>>> HACK message? And what do you mean by "Further Study"? Are you saying we
>>> don't enough to say whether the NAR should send a HI message or an
>>> unsolicited HACK message for a reactive handover? So both options are
>>> allowed. (?)
>> There was a debate with Rajeev whether the direction of the HI should
>> always be the same (from PAR to NAR) and not the other way. FFS was put
>> for that moment, but now it's time to resolve it:-) I don't mind
>> deleting this sentence, but let's discuss it beforehand.
>
> This is a reactive handover. According to 5268bis, a HI is never sent
> from the NAR to the PAR. So step (c) in figure 3 is new behavior. Either
> of the solutions, 1) NAR sending a HI message 2) NAR sending an
> unsolicited HACK message to trigger the PAR to send a HI, would work for
> me. We have to pick one though.

Above paragraph ("Also, ... the current one.") was removed from the
document.

>
>>>>    Code        If F flag is not set, the Code MUST be set to zero.
>>>>                Otherwise, the Code value has the following meaning:
>>>>
>>>>                          0: Reserved
>>>>
>>>>                          1: Forwarding is not requested
>>>>
>>>>                          2: Request forwarding
>>>>
>>>>                          3: Indicate the completion of forwarding
>>> There is an issue here. 5268bis already has semantics for code set to
>>> '0' and '1'. I think you should start at '2' in this document.
>> Revised.
>
> Can you add a sentence that says values '0' and '1' are defined in 5268bis?

I was too lazy... the update document has the following:


   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

>>>>                        5: Context Transferred successfully, more context
>>>>                        available
>>> What does this mean? Is it saying there will be more unsolicited HACK
>>> messages that follow with more context? If so, how are they all
>>> correlated at the NAR? If not, does it mean the NAR has to send more HI
>>> messages to get more context from the PAR?
>> The intention here is that the amount of the context to transfer could
>> be very large, so it is allowed to send the HI messages multiple times.
>
> Does it mean that the NAR has to send more 'HI' messages to get the
> additional context? Or does it mean the PAR would be sending more HACK
> messages with the additional context?

I see. It's not very clear about it. I presumed the former scenario, but
the latter scenario is another possibility. I'll add some text to
describe the former scenario, but I can revise it any time later.

>>>> 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.
>>>>
>>>>       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  |
>>>>      +---------------------------------------------------------------+
>>>>      |                              ...                              |
>>> What does the above format mean? Where is the data in each request? Is
>>> it just request type and request length? Does Req-type use the same name
>>> space as mobility options? If so, this creates a problem. Mobility
>>> options are supposed to be carried in a mobility header message. Here
>>> you carrying the mobility options in another mobility option (Context
>>> Request Option).
>>>
>>> If you are not using the same name space as mobility options, are you
>>> creating a new name space for the "Req-type" field?
>>>
>>>>    Context Request Option is typically used for the reactive (NAR-
>>> How come there is no "Context Response option" defined?
>
> You didn't respond to this. What is the mobility option that carries the
> MN context? This mobility option would be carried in the HI message in
> case of a predictive handover and the HACK message in case of a reactive
> handover. Is it also called the "Context Request Option"?

Sorry for not having responded to this part. The Context Request Option
in the HI message carries only the requests, and the actual context
values are carried by the corresponding mobility options in the HAck
message.

>>>>    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 defined in Section 6.2.8, the requested option format
>>>>    looks as follows:
>>>>
>>>>      |                              ...                              |
>>>>      +---------------+---------------+-------------------------------+
>>>>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>>>>      +-------------------------------+-------------------------------+
>>>>      |           Vendor-ID           |           Sub-Type            |
>>>>      +---------------------------------------------------------------+
>>>>      |                              ...                              |
>>> I don't think a Vendor Specific Mobility Option can be a sub-option of
>>> the Context Request Mobility Option.
>> This option is to request necessary contexts typically from the NAR, so
>> this doesn't include any values, which are supposed to be transferred
>> later from the PAR. This is similar to the DHCP Option Request Option.
>
> So that means you don't need the length field in the following message,
> since there is no data that is being transferred....

"Req-length" is not the length of the requested context, but that of
each request format. If all mobility options have a simple TLV format,
then only "Req-type" would be enough; however, some mobility options
have more structured formats with the sub-type field. One example is
Vendor Specific Option (RFC5094) and another is Mobile Node Identifier
Option (RFC4283).

When you want to request some vendor-specific context information, you
would need to specify the Vendor-ID (e.g., 3GPP2, WiMAX,...) and the
sub-type (e.g., the header compression algorithm in use), so the request
format could become more than just the type. In case where the AR that
received this option didn't understand this particular request part, it
could skip that part by knowing its length. It would be more efficient
to skip only unknown part than to drop the whole request.

I think we need more discussion on it, so I will leave it open for the
time being.

>       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  |
>      +---------------------------------------------------------------+
>      |                              ...                              |
>
> Are these just fixed fields in the Context Request Mobility Option? They
> aren't mobility options themselves, but the Req-type field re-uses the
> mobility option type namespace? That would be odd.
>
>>>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>>>
>>>>    This option is used to transfer the Local Mobility Anchor Address
>>>>    (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 |          Reserved             |
>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>      |                                                               |
>>>>      +                                                               +
>>>>      |                                                               |
>>>>      +                 Local Mobility Anchor Address                 +
>>>>      |                                                               |
>>>>      +                                                               +
>>>>      |                                                               |
>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> Why don't you add a field here that indicates whether you are carrying
>>> the IPv4 address or the IPv6 address of the LMA? I don't like the fact
>>> that you have a LMA address option for carrying the IPv6 address of the
>>> LMA, and another IPv4 address option that can carry either the IPv4
>>> address of the LMA or the mobile node.
>> I see your point, but the "IPv4 Address Option" defined in 6.2.3 has the
>> Option-code to carry the IPv4 address of the LMA. Do you still prefer to
>> carry it by the LMAA option?
>
> I think the same option should carry both the IPv4 address and the IPv6
> address of the LMA. We should not split the LMA information across two
> different mobility options.

Ok. the revised LMAA Option will have the following format, where the
Option-Code specifies the IP version of the LMA address:

 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                 +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also, Option-Code (1) "IPv4-LMAA" will be removed from the IPv4 Address
Option in Section 6.3.3.

Regards,
--
Hidetoshi

>>>> 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
>>> This would need revision if we conclude that existing mobility options
>>> cannot become sub-options of the Context Request mobility option.
>> I haven't changed this part, yet. Let us hear your opinion about the
>> usage of this option.
>
> I am totally confused by the "Context Request Option". I assume it goes
> in the HI message from the NAR to the PAR in a reactive handover. Its
> not clear what is used to carry the context from the PAR to the NAR. The
> message format needs to be fixed too. Are we making existing mobility
> options as sub-options of the Context Request option? Or we are defining
> new sub-options but re-using the mobility options name space? (this
> would be a bad idea).
>
>> Thanks again for your time and appreciate your further comments.
>
> No problem.
>
> Vijay
>
>
>

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