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

From: Soliman Hesham <[email-masked]>
Date: Mon, 23 Jun 2003 22:21:39 -0400

> 
 > I have read optDAD. I don't understand how NAR can
 > distinguish between an NA that should create an ND cache
 > entry and the one that should not.

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

 > >  > Even when DAD optimization is used,
 > >  >
 > >  > - HI and Hack are needed so that the NAR can proxy
 > >  >    the address (and not invoke NS) and buffer packets
 > >  >    (instead of sending Destination Unreachble) for
 > >  >    the predictive case
 > >
 > > => Proxy for what purpose?? You must be assuming that the
 > > handover will take an extremely long period of time so
 > > that the NAR would have to avoid NSs for the MN's
 > > new CoA.
 > >
 > 
 > What is extremely long/short ? Without pre-scanning,
 > WLAN link swithching is at least few hundred milliseconds.
 > Even with pre-scanning, it is about 100 milliseconds.
 > So, if the FBU has been sent to PAR, and voice packets with
 > 20 ms inter-packet separation are arriving, then there are at least
 > 5 packets at NAR. What should NAR do ?

=> RFC 2461 says that it should queue the messages and
solicit. The queue length is an implementation issue.

 > It is hard to assume that handover delay will always be
 > smaller than the inter-packet separation..

=> Agreed, that's why you need a reasonable size
queue.

 > Ofcourse when it is a solicited NA.

=> Let's call it: When there is an INCOMPLETE
state associated with the MN's address.

 > Section 7.2.6.  Sending Unsolicited Neighbor Advertisements.
 > 
 > ".. If the Override flag is set to
 >    one, neighboring nodes will install the new link-layer address in
 >    their caches.  Otherwise, they will ignore the new link-layer
 >    address, choosing instead to probe the cached address."
 > 
 > 
 > > the MN didn't receive it (because it hadn't made
 > > it to the new link yet), the unsolicited NA from the
 > > MN will fix that. If you agree with this, it seems
 > >
 > 
 > 7.2.5.  Receipt of Neighbor Advertisements
 > 
 > "When a valid Neighbor Advertisement is received (either solicited or
 >    unsolicited), the Neighbor Cache is searched for the 
 > target's entry.
 >    If no entry exists, the advertisement SHOULD be silently 
 > discarded.
 >    There is no need to create an entry if none exists, since the
 >    recipient has apparently not initiated any communication with the
 >    target."

=> You didn't complete the quote :( see the 
rest below:

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happens.  If the
   link layer has addresses and no Target Link-Layer address option is
   included, the receiving node SHOULD silently discard the received
   advertisement.  Otherwise, the receiving node performs the following
   steps:

    - It records the link-layer address in the Neighbor Cache entry.

    - If the advertisement's Solicited flag is set, the state of the
      entry is set to REACHABLE, otherwise it is set to STALE.

    - It sets the IsRouter flag in the cache entry based on the Router
      flag in the received advertisement.

    - It sends any packets queued for the neighbor awaiting address
      resolution.

   Note that the Override flag is ignored if the entry is in the
   INCOMPLETE state.

=> Please note the last line. Note the word "ignored".

 > I am still trying to figure out how we can leave ND unmodified
 > using only NA.

=> Hope this helps.

Hesham

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 24 Jun 2003 17:46:31 +0900

> => Agreed, that's why you need a reasonable size

AFAIK, FMIPv6 is supporting three buffers(or queues):

 Buffer 1 (at PAR):
          for packets of which destination address is PCoA. 
          (They are sent from other CNs)
          Start buffering - when PAR sends HI
          Ending buffering - when PAR receives HAck

 Buffer 2 (at NAR):
          for packets of which destination address is PCoA.
          (They are sent from PAR through the tunnel)
          Start buffering - when NAR receives HI
          Ending buffering - when NAR receives FNA

 Buffer 3 (at NAR):
          for packets of which source address is PCoA.
          (They are sent from MN at new link)
          Start buffering - when NAR receives FNA
          Ending buffering - when NAR receives HI

Maybe, Buffer 3 does not receive any packets if predictive scenario
is performed and HI message is well sent before MN moves to new link. 
However, we cannot ignore the case that the HI message is delayed 
(e.g., network congestion, multihop between PAR and NAR, etc.)
Can we create Buffer 3 using normal ND without proxy neighbor cache?

Youn-Hee Han

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Jun 2003 08:38:18 -0700

One thing I have found helpful in the past to avoid long, rambling,
inconclusive email discussions about specific issues is for the draft editor
to construct an issues list on the draft, and then work with the issues.
Email messages targeted at specific issues, outlining a collection of
alternative proposals, which are then discussed on the list, are extremely
useful in reaching conclusion quickly on those issues where everybody
agrees, or there are one or two dissenting opinions. If no obvious concensus
comes out of the discussion, the editor or WG chairs can then make a WG
concensus call on the issue after a reasonable discussion period.

Could we maybe consider doing that with this draft?

            jak

----- Original Message ----- 
From: "Soliman Hesham" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>
Cc: <[email-masked]>; "Seok Joo Koh" <[email-masked]>;
"Youn-Hee Han" <[email-masked]>; <[email-masked]>;
"James Kempf" <[email-masked]>
Sent: Monday, June 23, 2003 7:21 PM
Subject: RE: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6:
FBUtransmission text)

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Jun 2003 11:50:11 -0700

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

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.

> solicit. The queue length is an implementation issue.

When NAR does solicit, if the MN is not there, it will send
Destination Unreachable. 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.

> state associated with the MN's address.

When there is already an ND cache entry for the MN,
yes.
But, when there is no ND cache entry, NAR won't create
one unless NA is solicited or unless you specify new
behavior. So, my question is how does NAR distinguish
between a vanilla NA and an NA that needs to create an
ND cache entry _when there is no ND cache entry_.

From Nick's response, in oDAD, NAR is "expecting"
MN through prediction. 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.

> => Please note the last line. Note the word "ignored".

So, you are assuming that there is already an entry at NAR. This can
only happen if NAR has received any indication that MN is arriving.
HI-Hack exchange does that in the predictive case.
However, there could not be any entry in the reactive case. Then, the
unsolicited NA won't create an entry.

>  > I am still trying to figure out how we can leave ND unmodified

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

   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.

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.

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

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)

I will try to send out a summary separately.

-Rajeev