-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna at nortel.com]
Sent: Tuesday, September 22, 2009 10:58 PM
To: Hidetoshi Yokota
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
Hi Hidetoshi,
Thanks for your thoughts on this.
I expected a little more serious ones:), but please see some
more of the same thoughts inline! :)
Regards,
Ahmad
-----Original Message-----
From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
Sent: Tuesday, September 22, 2009 6:20 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
Hi Ahmad,
Thanks for your detailed thoughts. Below, we try to answer your
questions as best we can.
Ahmad Muhanna wrote:
Hi Hidetoshi,
Looking one more time into the draft I found the following under
section
4.1:
"
The encapsulation type for these user packets SHOULD
follow that used
in the tunnel between the LMA and MAG (IPv6-in-IPv6 as
specified in
[RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
[IPv4PMIPv6], TLV-header UDP tunneling as specified in
[GREKEY] or
any new method defined in the future).
"
The intention here is that the inter-MAG tunnel should
support all the
encapsulation types that are mentioned in RFC5213.
[Ahmad]
Well, whatever it is this document supports, it needs to make
it clear and ensure that it works. My question is the
following: Does this document support ONLY IPv6-in-IPv6
tunneling between the MAG and the LMA? or it also supports
the different tunneling that the document claims to support
as quoted above?
If it only supports IPv6-in-IPv6, this document MUST document
that clearly. On the other hand, if it supports the above
listed tunneling protocols, it MUST document how forwarding
these packets over the inter-MAG tunnel works.
IMO, this is a very broad statement that underestimates its
content.
It is way underspecified how these tunneling protocols will
be used to
successfully map the traffic from the MAG-LMA tunnel to
the MAG-MAG
tunnel. In this regard, I have the following questions:
1. Is it documented any where how this mapping would work
for all of
these tunneling/encapsulation mechanisms?
It seems that the mapping of these flows is rather implementation
specific. Is there anything that should be considered in
addition to
RFC5568?
[Ahmad]
Of course. I guess you need to get out of the mode that this
document is nothing but few tweaks to make FMIP6 works for
PMIPv6. In RFC5568, it clearly assumes that protocol is used
for fast handover when IP Mobility based on MIP6 as described
in RFC3775. In that sense, only IPv6-in-IPv6 is assumed.
Again, the above claim of supporting all these tunneling
mechanisms should either be removed and clearly document that
this protocol works ONLY when the tunneling between the MAG
and LMA is IPv6-in-IPv6 or explain how they will work.....
2. Is the tunneling mode (between the PMAG and the LMA)
negotiated/communicated between the PMAG-MAGs?
If the tunneling mode is determined between the LMA and
PMAG, which is
in the scope of RFC5213, that of the inter-MAG tunnel should follow
it.
It is also assumed that the same type of tunneling will be used
between the LMA and NMAG.
[Ahmad]
Sure, but your document claim that it supports all of these
tunneling mechanisms (as per the quoted text from section
4.1) and at the same time documents nothing about how these
should work across the inter-MAG tunnel.
3. If the tunneling between the PMAG-LMA is
IPv6-in-IPv4-UDP, Does it
mean the tunneling between the PMAG-NMAG is also going to
use the same
encapsulation?
Yes, that is the basic idea.
[Ahmad]
Good. Then How that should work?
Is there anything in your document which specify that? I am
all ears, just point me to the text.
4. If the UDP tunneling between the two MAGs is not needed,
what kind
of tunneling will be used between the two MAGs to correctly
map the MN
traffic and successfully deliver it to the MN?
That mode has not been considered. It will be possible, but
is there
any reason that a different type of tunneling should be used?
[Ahmad]
I am not suggesting to use a different tunneling mechanism
between the PMAG and the NMAG; However, You are saying that,
e.g., IPv6-in-IPv4-UDP is naturally extended over the
PMAG-NMAG tunnel without saying how it should work. That what
I was speculating that you probably use a specific tunneling,
of course, other than IPv6-in-IPv6 to make it work.
So, again, if PMAG-NMAG interface does support all these
tunneling mechanisms, then we need to know how it works? That is all.
5. Do these tunneling mechanisms include plain GRE
Encapsulation with
GRE keys or only GRE with TLV-header UDP tunneling?
<draft-ietf-netlmm-grekey-option> supports both modes, so
PFMIPv6 should also support them.
[Ahmad]
That is a clear answer. Thanks.
Could you please make sure that your document clarify and
clearly document it.
5.1. If plain GRE encapsulation with keys is used, then the
document
needs to clearly specify if there are two sets of GRE
keys for the
same mobility session or only one set? i.e., GRE Keys between the
PMAG-LMA, GRE Keys for PMAG-NMAG or one set is used. It is
not clear
in the current document.
PFMIPv6 describes only GRE keys for the inter-MAG tunnel
(PMAG-NMAG),
which I think is clarified in Section 4.2. As far as GRE
Key Option is
used, it is difficult to transport multiple sets of keys at
one time.
[Ahmad]
Well,
1. It is not clarified nor clear under section 4.2. but,
could you please point me to the text you are talking about?
2. As far as of multiple GRE keys exchange, currently that is
a limitation of the PMIPv6 protocol. Right? Then, when you
need multiple GRE keys, how these GRE keys are communicated?
Is that explained in the document?
5.2. same question as in 4, if there is GRE with TLV-header UDP
tunneling between the PMAG and the LMA, Is that needed
between the
PMAG-NMAG? If NOT, what encapsulation mechanism is being
used and how
is the mapping works?
The working assumption is "yes".
[Ahmad]
That is a huge CLAIM that is NOT backed by any technical
data! How that should work? Can you document that some where
in the specification? If it is already document, please point
me to the text.
6. Is the assumption here that the NMAG and the PMAG have
the same
transport with the LMA?
For the sake of simplicity, the answer should be "yes".
If not, the network between MAGs should provide the transparent
environment (e.g., by another tunneling).
7. with respect to "any new method defined in the future"
what is the
constraints on this statement? It seems to me an
overstatement of the
capabilities of this protocol and an underestimate of the future
tunneling mechanism. May be you need to make sure that the
wording is
correct by having some conditional restrictions.
The intention here is that if a new tunneling mechanism is
specified
for PMIPv6, PFMIPv6 should also support it. If this is too
vague, it
could be removed.
[Ahmad]
Sure, please remove it. Unless, you propose a dynamic
tunneling mechanism that is forward compatible and capable to
address future tunneling between the PMAG and LMA.
In addition,
============
IMO and based on a quick review of this draft, I find it
very vague
and does not have the details for an Interoperable
protocol. I believe
the draft SHOULD CLEARLY address the following points:
Decide whether it needs to specify/support a single tunneling
encapsulation mechanism between the PMAG-NMAG or more than one.
SINGLE tunneling and encapsulation mechanism between PMAG-NMAG:
===============================================================
1. This *protocol* needs to specify the exact details of how this
tunneling mechanism is dynamically established to address
the nature
of the problem being address in this *handover optimization
protocol*.
The nature of the specification and its performance is based on
RFC5568.
[Ahmad]
That is part of the problem not to be sited here as a
supporting argument!
As I said earlier, RFC5568 assumes that there is always
IPv6-in-IPv6 tunneling between the mobile node and the home
agent. In the case of
PMIPv6 that assumption is INVALID.
Whether the establishment of the tunneling mechanism is dynamic or
static is operation-specific.
[Ahmad]
That is NOT true. This document is supposedly offering a fast
handover mechanism for PMIPv6 which dynamically does
(implicitly or explicitly) negotiates tunneling between the
MAG and the LMA. So, how a statically configured tunnel
between the PMAG and the NMAG tunnels a mobile node traffics
when the mobile node traffic between the PMAG and LMA for the
same mobile node was dynamically negotiated?
1.1. for example, if GRE with Keys is being used, then it MUST be
clear how the GRE keys are exchanged between the PMAG-NMGA,
similar to PMIPv6.
The current text proposal for Section 4.2 tries to clarify it
regarding who selects the key and how it is transferred.
[Ahmad]
Hmmm.. Tries to clarify ... I guess we need a clear
specification that documents an Interoperable solution. We
can not just propose a standard track document that is some
what clear in the mind of some. Right?
2. How the chosen PMAG-NMAG tunneling protocol is able to
interwork
with all tunneling mechanisms that are currently supported
by PMIPv6,
e.g., IPv6-in-IPv6, IPv6-in-IPv4, IPv6-in-IPv4 UDP, etc.
between the
PMAG-LMA as is being claimed under section 4.2 of this draft.
Basically, it is supposed that the same tunneling protocol as that
between the LMA and MAG is used. The tunneling type between the LMA
and MAG should be determined in advance.
[Ahmad]
I guess this answer is more confusing .... One time you said
that the tunnel can be static and can be dynamic. Now, you
just said that the tunnel should be STATIC? I mean what is
it? It needs clarification......
3. This *protocol* needs to clearly specify how the
different mobility
sessions are being mapped between the PMAG-LMA tunneling to the
PMAG-NMAG tunneling? Somewhat similar to 2 above.
The basic mechanism is the same as in RFC5568.
[Ahmad]
Again, in the case of RFC5568 it is straight forward. Only
IPv6-in-IPv6 is supported as per RFC3775. Not the case for PMIPv6.
If a GRE
tunnel further differentiates the session, the GRE key will be used.
[Ahmad]
Good. Which GRE Key then?
1. Is that a statically configured GRE key?
2. Is it the same set of GRE keys between the PMAG and LMA?
3. If none of the above, how these GRE keys are generated and
exchanged between the PMAG and the NMAG?
Multiple Tunneling and encapsulation mechanisms between the
PMAG-NMAG:
======================================================================
If the choice as being claimed under section 4.1, is to
support all of
the current tunneling mechanisms between PMAG-LMA on the
PMAG-NMAG
interface, then the protocol needs to address the following:
1. Provide a good analysis why that option is the best
option? What
are the advantages and the disadvantages?
I think that is the most workable solution.
{Ahmad]
What do you have to technically back up this statement.
Otherwise, it is just another statement.
Since the
tunneling mechanism selected for the PMIPv6 tunnel is supported by
both the PMAG and NMAG, no extra capability is required for the
inter-MAG tunnel.
[Ahmad]
OK. I am not disputing that the PMAG and the NMAG supports
the same sets of tunneling mechanisms or not. It is more of
which tunnel to use for which mobile node session and what
parameter is needed for this inter-MAG tunnel to correctly
tunnel the mobile node traffic and deliver it to the end of
the tunnel in a non ambiguous way.
For example:
Tunneling Case 1:
=================
1. PMAG and the LMA negotiates the GRE encapsulation and the
GRE keys using the PBU and PBA for each applicable mobility session.
2. It is very well understood that both the PMAG and the NMAG
support GRE tunneling with GRE keys + GRE keys exchange using
PMIPv6 signaling with the LMA.
3. Now: for the inter-MAG tunnel and for the same mobility
session, how GRE tunneling and GRE keys are negotiated
between the PMAG and NMAG? Of course, using HI and HAck, right?
4. Okay, we need the exact details for this specific case.
Tunneling Case 2:
=================
1. Let us assume IPv6-in-IPv4 UDP is used for MN1. Okay 2.
That tunneling is implicitly negotiated between the PMAG and
LMA during the PBU/PBA exchange, right?
3. How that is negotiated between the PMAG and the NMAG? We
need the details..
And so on....
Also, I don't see any specific reason to use a special tunneling
mechanism for the inter-MAG tunnel.
[Ahmad]
Good. This means you would use the same tunneling between the
PMAG and LMA over inter-MAG tunneling. In this case, we need
the details for negotiating that tunneling mechanism between
the PMAG and the NMAG.
2. How this *protocol* dynamically negotiates the tunneling
mechanism
type?
If the tunneling mechanism between the LMA and MAG is determined in
advance, the same mechanism is used for the inter-MAG
tunnel. So, it
is not on-demand and no negotiation is assumed. If the tunneling
mechanism between the LMA and MAG is determined on demand,
then that
is a different story...
[Ahmad]
Well, what do you mean? The tunneling between the PMAG and
the LMA is NOT on demand?
I believe IPv4 support for PMIPv6 and GRE key for PMIPv6
drafts will be helpful in answering this question.
3. How that should work, for example if the tunneling mechanism
between the PMAG-LMA is IPv6 in IPv4 UDP, how that
tunneling will be
extended to go over the PMAG-NMAG interface and how it is
supposed to work.
In this case, both the PMAG and NMAG should be dual-stack
and the IP
addresses in the IPv4 outer header are those of the PMAG and NMAG.
IPv6 inner header should be kept intact.
Okay..... Then if the NMAG sends the first packet over the
NMAG-PMAG tunnel! Which encapsulation mechanism is going to
use to encapsulate that packet?
Also, Do you agree that there is a specific reason for the
traffic between the PMAG and the LMA to be IPv6-in-IPv4-UDP.
Right? That reason may NOT be VALID between the PMAG and the
NMAG. Right?
Then why to use the same tunneling here? Just out of curiosity!
Finally, the draft could have some restrictions and define the
PMAG-NMAG tunneling/encapsulation mechanism and could
define a set of
PMAG-LMA tunneling mechanism that are being
supported/interwork over
the PMAG-NMAG tunneling/encapsulation.
What kind of restrictions do you foresee? Do you also have any
specific mechanism for the inter-MAG tunnel in mind?
[Ahmad]
I guess, you need to answer many of the above comments before
we talk about this. A clear understanding of this tunneling
is needed and I do not see it documented in this draft.
BTW: Under section 4, this specification says:
"
In order to further improve the performance during the
handover, the
PFMIPv6 protocol in this document specifies a bi-directional tunnel
between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel
packets meant for the mobile node.
"
Which bi-directional tunnel? Where? What are the details?
One more note: I found defining and describing a protocol
based on a
call flow, is not the most easy to follow. But, that could
just be me.
What do you think could improve the readability of the document?
[Ahmad]
Quite some of them... But I gave up after a while....
Regards,
--
Hidetoshi
Regards,
Ahmad
-----Original Message-----
From: mipshop-bounces at ietf.org
[mailto:mipshop-bounces at ietf.org] On Behalf Of Muhanna, Ahmad
(RICH1:2H10)
Sent: Thursday, September 17, 2009 9:23 PM
To: Hidetoshi Yokota
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
Hi Hidetoshi,
Please see inline.
Regards,
Ahmad
-----Original Message-----
From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
Sent: Thursday, September 17, 2009 4:48 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org;
Jari Arkko
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
Hi Ahmad,
Here is the proposed revision:
In Section 4.2:
[... message with the same sequence number.] The necessary
information MUST be transferred in the HI/HAck messages to
distinguish MN's packets for forwarding in advance or at
this time.
Such information includes the MN ID and/or GRE key(s).
Typically,
the NMAG selects the GRE key for the downlink packets
and the PMAG
selects that for the uplink packets. Each key is
conveyed in
either
the HI or HAck message separately when GRE Key Option
[GREKEY] is
used. [For the downlink ...]
[Ahmad]
In addition to what Vijay mentioned with respect to
Typically (which
should be removed), I believe the draft needs to be clear on the
mechanism that is used for exchanging the GRE keys. When you say
"...when the GRE Key Option [GREKEY] is used." What
happens if the
GRE key option is NOT used. Is there another mechanism?
Since the GRE keys are necessary to establish the lateral
tunnel and
identify the MN traffic, the draft must specify a default
mechanism.
Other mechanisms can be used or specified some where else
if needed,
but we need a default one here. Right?
Also, you replaced the **HoA of the MN** with the **MN ID**.
What is the reason for this change?
And how this should work NOW while you have ".. and/or GRE Keys"?
If the above description is acceptable, I will submit
the revised
version by the end of the week.
Regards,
--
Hidetoshi
Ahmad Muhanna wrote:
Hi Hidetoshi,
-----Original Message-----
From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
Sent: Monday, September 14, 2009 7:37 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org;
Jari Arkko
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
Hi Ahmad,
Thanks for your comment. I'm glad to hear an opinion from
a GRE key
expert. Please see inline:
Ahmad Muhanna wrote:
Hi Hidetoshi,
I just have one quick comment and question.
Reading the draft, it seems to me that the GRE keys are
somehow sent
from the NAR to PAR in the HI (section 4.2). Is that the
case? This
means both the DL and UP GRE keys for the bilateral
tunnels between
the two AR(s). Is my understanding correct? It also
mentions that the
format
In terms of the GRE keys for the bilateral tunnel,
the working
assumption is that the DL key is selected by the NAR and
the UL key
is selected by the PAR. Depending on the fast handover
mode, those
keys are transferred to the other MAG via either the
HI or Hack.
of these keys are based on the GRE keys for PMIPv6
draft (section
6.2.6).
Correct.
It seems to me that there should be more text to define
which keys
exchange in the HI and which in the HaCK
If the above assumption works, I would like to add more
text along
that line.
[Ahmad]
That is great. Please add some clarification text to
clearly indicate
that only one key in the HI and the other in the HACK.
Since some specification in 3GPP2 depends on this draft, I
appreciate
if you can publish an updated version before the end of
the week.
Thanks in advance!
If both keys are exchanged in the same HI, How these
keys are
identified at the pAR?
In GRE keys for PMIPv6 draft, downlink GRE key is included
in the PBU
and the uplink GRE key in included in the PBA. They never
exist in the
same message and that way there is no confusing.
So far, each key is conveyed by either the HI or HAck.
However, I haven't explored all of the possibilities.
If you can
think of any case that two keys must be conveyed in one
message,
please let me know.
[Ahmad]
I do not see any reason for this case (one key per
message) not to
work for all implementation.
In addition, DL and UP GRE keys are generated by NAR and
sent inside
the HI, my question: Is there any specific reason for
the NAR to
specify both GRE keys for the bilateral tunnels?
It would be more problematic that the NAR determines the
both keys
and I would rather like to avoid it.
Sorry for this comment to be so late but hope that you have
the chance
to take a look at it.
That's ok. The draft is under the review process. Your
comment is
highly appreciated.
Regards,
--
Hidetoshi
Thanks!
Regards,
Ahmad
-----Original Message-----
From: mipshop-bounces at ietf.org
[mailto:mipshop-bounces at ietf.org] On Behalf Of
Hidetoshi Yokota
Sent: Wednesday, September 02, 2009 11:12 PM
To: Jari Arkko
Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
Subject: Re: [Mipshop] AD review of
draft-ietf-mipshop-pfmipv6
Hi Jari,
Thanks for your patience. The attached revised document is
supposed to
reflect the rest of your comments. Please also see inline,
where the
revised part is explained item by item. If there is no
outstanding
issue there, we will upload it shortly.
[Apologize if you received it twice. Since the size just
exceeded the
limit of this ML, this mail is reposted without the
attachment.]
Hidetoshi Yokota wrote:
Hi Jari,
Appreciate your detailed review. The editorial corrections
are mostly
done and the revised version is attached to this mail.
Regarding the
technical comments, only the policies for the correction
are listed for
now. The complete correction will be posted as soon as
possible. Please
see inline for the responses to your questions and
comments:
Jari Arkko wrote:
I have reviewed this document. It was generally in good
shape and easy
to read. I did find a number of issues though. Please
discuss them with
me on this thread and/or revise the draft accordingly.
Technical:
I do not understand the IP host aspects of the
handover. For an
unmodified host, what kind of interfaces exist on the
host, what
addresses they have, and at what time are interfaces
removed or added?
Is this exactly the same as in RFC 5213, or does PFMIPv6
introduce some
change here?
The basic principle would be that this specification does
not require
any additional IP-level function to the MN running in the
PMIPv6 domain.
This MN should therefore be the same as defined in RFC5213.
A typical network interface would be one with the
cellular network,
where the network basically controls the movement of the
MN. Different
types of interfaces could be involved such as different
generations (3G
and 3.9G) or different radio access systems. Any type of
IP address
could be assigned (IPv4/v6 or global/private), but the
assigned address
must be preserved before and after the handover. PFMIPv6
should be able
to handle the single radio situation, where only one
interface is active
at any given time. This is a tougher situation in terms of
packet loss
and delay.
I would like to see a new section on manageability
considerations. For
instance, Section 5 talks about some
configuration issues.
These should
be mentioned, and there should be a description of what
the operator
needs to configure in order to set up a PFMIPv6 network.
We will add a new section for manageability considerations
to clarify
the above and to reflect your suggestion.
A new subsection is added in Section 5 describing the
above aspects:
-------------------
5. PMIPv6-related Fast Handover Issues
5.1. Manageability Considerations
This specification does not require any
additional IP-level
functionality on the LMA and the MN running in
the PMIPv6
domain. A
typical network interface that the MN could be
assumed to have
is one
with the cellular network, where the network
controls the
movement of
the MN. Different types of interfaces could be
involved such as
different generations (3G and 3.9G) or different
radio access
systems. This specification supports a MN with the
single radio
mode, where only one interface is active at any given
time. The
assigned IP address is preserved whether the physical
interface
changes or not and the MN can identify which
interface should be
used
if there are multiple ones.
--------------------
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.
Is this according to RFC 5213? I seem to recall that RFC
5213 operated
on the same link layer addresses.
I think your observation is correct... I'll check with the
other authors
to see if it is ok to rewrite it.
The new text doesn't mention the promiscuous mode and
emphasizes the
common link-layer address among all MAGs in the
PMIPv6 domain:
---------------
5.2. Expedited Packet Transmission
[...]
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. The new router should respond
to the NUD
probe,
providing its link-layer address in the
solicited Neighbor
Advertisement, which is common in the PMIPv6 domain.
Implementations
should allow the MN to continue to send uplink packets
while it is
performing NUD.
----------------
At least one mobility option MUST uniquely identify
the target
MN (e.g., the Mobile Node
Identifier
Option defined in RFC4283
<http://tools.ietf.org/html/rfc4283>) and
the transferred context MUST be for one MN per message.
I would like the required options to be specified in more
detail. Which
identity options are sufficient to satisfy the MUST?
The required option should be the MN Identifier in the
Mobile Node
Identifier Option.
The above description is added in Section 6.1.1:
---------
Requested option
In order to uniquely identify the target
MN, the MN
Identifier MUST be contained in the
Mobile Node
Identifier
Option.
---------
If a default set of context information is defined
and always
sufficient, this option is not mandatory. This
option is more
useful to retrieve additional or dynamically
selected context
information.
Context Request Option is typically used for the
reactive (NAR-
initiated) fast handover mode to retrieve the context
information
from the PAR. When this option is included in the HI
message, all
the requested context information SHOULD be included
in the HAck
message in the corresponding mobility option(s) (e.g.,
HNP, LMAA or
MN-IID mobility options).
Please specify what the default set of context
information is, by
listing the required options when the CRO is not present.
The default context information to request is the Home
Network Prefix
Option. If the Mobile Node link-layer is available and
used, the Mobile
Node Link-layer Identifier Option MUST also be requested.
With these two
options and the MN identifier, the NMAG can
construct the PBU.
The above description is added in Section 6.2.1:
----------
The default context information to request is the
Home Network
Prefix
Option. If the Mobile Node link-layer is available and
used, the
Mobile Node Link-layer Identifier Option MUST also be
requested.
----------
Editorial:
HO-Initiate:
A generic signaling message, sent from the P-AN
to the PMAG that
indicates a MN handover. 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 PMAG
resolve the NMAG and the new access point or the
base station to
which the MN is moving to. The details of this
message are
outside the scope of this document.
4. Proxy-based FMIPv6 Protocol Overview
Section 4 would probably benefit from an additional
paragraph at the
beginning to explain what assumptions there exist about
lower layer
functionality.
Yes, the predictive fast handover relies on the
lower layer
functionality to trigger to send the HI. A new paragraph
will be added
to clarify it.
-------------
4. Proxy-based FMIPv6 Protocol Overview
If the MAGs can be informed of the detachment and/or
attachment of
the MN in a timely manner via e.g. the lower layer
signaling, it
will
become possible to optimize the handover procedure,
which involves
establishing a connection on the new link and
signaling between
mobility agents, compared to the baseline specification
of PMIPv6.
[...]
-------------
All the other corrections pointed out below have also been
reflected in the revised document.
Regards,
--
Hidetoshi
A new flag 'P' is defined for the HI and HAck
messages to
distinguish from those in [RFC5268bis
<http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-08#ref-
RFC5268bis>]
and thus MUST
be set in the entire document.
This would be more readable as " ... those in
[RFC5268bis]. This flag
MUST be ..."
Revised.
and the NAR creates a proxy NCE to receive those
packets for the NCoA
The term NCE has not been introduced at this stage yet.
Spelled out as "Neighbor Cache Entry".
address that is used by the MN is MN-HoA. Hence the
PAR forwards
The term MN-HOA has not been introduced before.
Added the unabbreviated form "Mobile Node's Home Address"
before it.
The access network to which the MN is attached
after handover.
New term MN, not introduced before.
Added "Mobile Node" before it.
specifies forwarding when the MN uses HoA as its
on-link address
New term HoA...
Changed to "Home Address".
as MN's NAI, Home Network Prefix (HNP), IPv4 Home
Address, are
New term NAI...
Added "Network Access Identifier" before it.
flag set and include the MN ID, the MN-HNP, the
MN-IID and the
New terms MN-HNP and MN-IID (or at least they do not
appear in their
MN-XXX form before this point).
Modified "MN-HNP" to "HNP" for consistency.
Inner destination address: HNP or IPv4-MN-HoA
IPv4-MN-HoA not defined earlier...
Added "Mobile Node's IPv4 Home" before it.
between the PCoA and NCoA to forward packets for the
MN to the NAR,
New terms PCoA and NCoA... there's probably more undefined
terms in the
document, please check!
Added "Previous Care-of Address" and "New Care-of
Address".
Will read
through it to see if there is any other undefined acronym.
In (i),
In Step (i),
Revised including other parts.
|(MN ID, Old AP ID) | (MN ID, Old
AP ID)
| |
Old AP ID? AN ID? AR ID?
AP ID stands for "Access Point Identifier", which is
defined in RFC5568.
Added the unabbreviated form and citation.
The rest of the part will be revised soon.
Regards,
--------------------------------------------------------------
----------
_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
--
Hidetoshi Yokota
Mobile Network Lab
KDDI R&D Laboratories, Inc.
e-mail:yokota at kddilabs.jp
_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
