Subject: RE: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: F BUtransmission text)

From: Soliman Hesham <[email-masked]>
Date: Tue, 24 Jun 2003 22:00:01 -0400

> > => I don't think it needs to. If it had
 > > solicited for the MN's address it will update
 > > the cache based on the reception of the NA.
 > >
 > 
 > NAR won't solicit unless packets are arriving. Packets
 > don't arrive until FBU is processed by the PAR. 

=> Ok so far you have described the predictive case. 
So before we start going around again, do you agree
that it works for the predictive case? 

   In the
 > reactive case, PAR only receives FBU _after_ the MN
 > attaches to NAR. In the reactive case, when packets do arrive,
 > we can avoid a round-trip (NS/NA) by already having an entry
 > in the ND cache during the time FBU is sent to PAR.

=> Frankly, I don't think you even need to worry
about reactive cases. If there is no anticipation
all you need to do is send a BU to a MAP. I see
no point in creating all these messages for the reactive
case to save one RTT on a WLAN. 
To save the NS/NA exchange we are introducing 3 other 
messages. Does anyone else think it's an overkill?

 > So, imagine the MN connecting to NAR and NAR has
 > no ND cache entry nor are any packets arriving (because
 > FBU has not been processed by PAR yet). The MN sends
 > message M, which creates a ND cache entry for the MN and
 > forwards the inner FBU packet to PAR. When packets arrive
 > at NAR, there is already an ND cache entry for the MN.
 > 
 > Now, contrast this with the MN sending the NA after
 > attaching to NAR. Since there is no ND cache entry at NAR,
 > unsolicited NA does not create an entry.

=> How will the MN send a BU in the reactive case before
discovering the NAR's address? Or are you assuming 
that it's half reactive, i.e. the MN received the Pradv
but sent nothing before it moved? Now we're
narrowing the case down even more. Is this what HI/Hack
and FNA, with all their complex processing, are needed
for? If so please make sure they are optional. 

 > 
 > When NAR does solicit, if the MN is not there, it will send
 > Destination Unreachable. 

=> No, it will try more than once before it does that.

   Given the variability in link switching
 > delays, it is hard to imagine that the MN will be at NAR by the
 > time packets arrive, and hence NAR will solicit and the MN will
 > respond.

=> See above.

 > But, when there is no ND cache entry, NAR won't create
 > one unless NA is solicited or unless you specify new
 > behavior. 

=> So if you want to specify a new behaviour for 
this extremely odd case, perhaps you could add 
a flag to the NA, let's say F, so we have R, S, O
and F. 

So far there is no reason for the NCOA option
in the FNA. All we're discussing now is the creation of 
a Neighbour cache entry. 

 > 
 > From Nick's response, in oDAD, NAR is "expecting"
 > MN through prediction. 

=> No, he said that oDAD can interoperate with prediction
but does not require it. It's pretty clear in the draft.

   This is one of the cases in FMIPv6.
 > The other case is when the MN moves without sending
 > FBU on the old link, in which case NAR does not have
 > _any_ ND cache entry in for the MN.

=> Before it moved did it get an RA for the NAR? 

 > 
 > Well, from what I can understand,
 > 
 > i) if there is already an ND entry at NAR, unsolicited NA will
 >    update the LLA according to ND. And, this is the premise for
 >    scenario 1) in the text I sent. So, we are in agreement (?).

=> On this point, yes.

 > 
 >    For NAR to have any entry before the MN attaches, it must
 >    receive some "prediction". HI-HAck provide that.
 >    This covers the predictive case in FMIPv6.

=> No, normal traffic can provide that too in the predictive
case.

 > 
 > ii) when there is no ND cache entry for the MN at NAR,
 >      you can either
 >     a) allow FBU to go through and let NAR do NS/NA for arriving
 >        packets, or
 >     b) create the ND cache entry at NAR _while_ FBU is being sent
 >       to PAR.

=> How was the F-BU sent, where did the default router
info come from? 

 > 
 > ii.a)
 >          * incurrs a round-trip when packets arrive
 >          * allows FBU to go through when there is conflict

=> Conflict in DAD? I'm suggesting we ignore that.

 > 
 > ii.b)
 >          * does not incur a round-trip when packets arrive.
 >          * avoids FBU transmission when NAR detects an existing entry
 >          * a message ((F)NA) is anyway needed for i)
=>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Wrong. I obviously
failed to make you understand what I'm saying. You do not
need this message in 

=> Also:
            *mandates HI/Hack unnecessarily

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2003 08:14:15 -0700

Hesham,

> messages. Does anyone else think it's an overkill?

We're discussing FMIP here, not HMIP. While there may be cases where the two
can be used together, I don't think we want the design of one to depend on
the other. Some network operators might not want to deploy both.

As for the number of messages, the real issue is the number of messages sent
over the air. We've done lots of simulation work and measurement on WLAN,
and, given the baseline FMIP design, Rajeev's proposal to allow piggybacking
(I dislike calling it encapsulation) has the potential to achieve the best
performance, because it reduces the number of over the air messages required
to start getting traffic down to one.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 09:48:53 -0700

James Kempf wrote:

> (I dislike calling it encapsulation) 

I dont want to start a long discussion, but...

I normally use the term piggybacking when both payloads are
for the same node. this is not the case here. the right word
would be encapsulation. :) and it would be better to stick to
one word.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Jun 2003 11:04:37 -0700

Hi Hesham,

> that it works for the predictive case?

I already mentioned this below (in i))..
The bottomline is whether NAR has an ND cache
entry for NCoA. For the predictive case, HI and HAck
exchange indicates to NAR to create the entry in Proxy
state. I agree to this.

> all you need to do is send a BU to a MAP. I see

umm.. I won't get into HMIP - FMIP issues.

> but sent nothing before it moved? Now we're

We ran a set of issues after Yokohama. One of them was
separating PrRtSol/PrRtAdv from the actual handover signaling.
See, for instance, the presentation at Atlanta IETF and the ML
discussion prior to that.
The current version (and version 05) states that these are done
ahead of handover. So, the assumption is that a MN undergoing
fast handover has exchanged PrRtSol/PrRtAdv messages so that
it knows NAR's prefix and addresses.
I think it is difficult to make progress if we have to re-open issues
again.. :-(

> => No, it will try more than once before it does that.

Ok. In any case, you have to worry about it given the variability
of the link switching delay.

>  > time packets arrive, and hence NAR will solicit and the MN will

We also need to specify that the ND queue be made larger because
some nodes might be undergoing fast handover. Requiring buffering
only after processing HI ensures that only those needs undergoing
fast handover will need additional buffering.

> a flag to the NA, let's say F, so we have R, S, O

First, this is not an extremely odd case. In fact, it is
not an odd case at all. I wonder why NAR will have an
ND cache entry for the MN when PAR didn't even see
the FBU.

Second, adding a flag is fine. I proposed something like
this (the "T" bit) over two years ago.. Anyway, we seem
to agree that some change is needed to the NA.

> in the FNA. All we're discussing now is the creation of

This is fair. But, NCoA has to be visible to NAR somewhere,
for instance in src addr.
However, there is a related issue. Let's say we send FNA alone
so that NAR could create an ND cache entry. The MN then
has to send FBU behind it. Sending them separately means

- MN has to successfully grab the channel twice
- in the event that NAR already has an ND cache entry for
   some other node, processing becomes complicated to capture
   and drop FBU subsequently (in order not to cause misidrection of packets
   to an unintended nose)

If we can encapsulate FBU within FNA, the

- MN only needs to acquire the channel once
- NAR can process outer FNA packet, and drop FBU
    in case it notices a conflict for the [NCoA, LLA]
   tuple. Otherwise, it creates an entry and let FBU
   go through.

To do this, the structure of FNA, which is currently
an ICMP option needs to revised. Specifically, I am
proposing that the NCoA and LLA be carried as
Destination option. It is possible that we can omit
NCoA from the Destination option if we think it is
fine to use NCoA as src address (even before the router
confirms it use).

> but does not require it. It's pretty clear in the draft.

May be my question was not clear. NAR "expects" MN's
attachment by creating an ND cache entry in the INCOMPLETE
state. Anyway, may be we should take the oDAD nits to a separate
thread..

> => Before it moved did it get an RA for the NAR?

A PrRtAdv, yes.

> => No, normal traffic can provide that too in the predictive

But, we disagree on timing. Without HI and Hack, Destination
Unreachable is a concern. Requiring ND cache queue size to be
larger because some nodes might be undergoing fast handover
is another concern.

> => How was the F-BU sent, where did the default router

See above.

> => Conflict in DAD? I'm suggesting we ignore that.

Some folks might be interested however. Between completely
ignoring it and providing conflict-free addresses, what FMIPv6 is
proposing is in the middle.

> failed to make you understand what I'm saying. You do not

Some message is needed so that the router can upgrade the entry
and start forwarding incoming, buffered packets. However, for the case
the MN has not received FBack, it still has to treat NCoA as
tentative.

- For NA with O=0, the proxy cache entry will not be updated.
    Note that NAR has to be able to send proxy NAs for NCoA
    in case some node sends NS for NCoA. Thus, it is imperative that
    it maintains a proxy cache entry for NCoA as a result of HI processing.
    If NA is sent with O=1, it could incorrectly update an existing
    entry. I believe that's why oDAD sets O=0.

- Sending FNA avoids the above ambiguity. The router will move
   proxy entry to REACHABLE upon processing FNA. On the other
   hand, if there is an existing entry for some other node, FNA should
   not update it.

>             *mandates HI/Hack unnecessarily

I would say HI and HAck for the reactive case need not be
mandated. What do others think ?
They are needed for the predictive case.

-Rajeev

ps: we are using predictive and reactive in a colloquial sense. We
should be careful in recognizing that even in the predictive case,
if the MN has not received FBack on the old link, it still does not
know a) whether NAR has ND cache entry, and b) whether NCoA
is acceptable.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jun 2003 11:53:30 -0700

> to start getting traffic down to one.

and ofcourse I agree with this.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2003 13:08:52 -0700

> They are needed for the predictive case.

I think they could be useful for allowing the nAR to confirm willingness to
tunnel, and as a vehicle for context transfer.

Note that confirming willingness to tunnel does not solve the security
problem with the nAR installing a neighbor cache entry for a node with which
it does not have a trust relationship, however. This should be noted in the
Security Considerations section. L2 auth would be required for this.

            jak