Subject: RE: [mobile-ip] FMIPv6: Handover delay and Address reachability

From: Soliman Hesham <[email-masked]>
Date: Sat, 28 Jun 2003 07:50:26 -0400

Rajeev, 

My suggestion (discussed in detail earlier)
is misinterpreted in this summary. Instead
of going into another cycle of debate, I'm
suggesting that the following text gets added
to draft:
"
	In cases where address duplication of the MN's
	new CoA is eliminated or reduced to acceptable
	levels (e.g. as a result of future address configuration
	optimisations or link layer-specific mechanisms), 
	implementing the following messages is considered
	OPTIONAL:
		o HI/HAck
		o FNA/NACK

	Such address configuration optimisations or other
	link layer specific mechanisms for avoiding address
	duplication are outside the scope of this document. 
	Note that the above messages are REQUIRED where such
	address configuration optimisations are not present.
      Note that the above discussion applies to both predictive
      and reactive handovers, as supported by this specification"

Hesham

 > -----Original Message-----
 > From: Rajeev Koodli [mailto:[email-masked]]
 > Sent: Friday, June 27, 2003 6:14 PM
 > To: [email-masked]
 > Subject: [mobile-ip] FMIPv6: Handover delay and Address reachability
 > 
 > 
 > Hello folks,
 > 
 > we have had some good discussion. I would like to
 > bring out some points from the discussion. It is time
 > for the larger WG to progress the draft!
 > 
 > 1. Relevance of HI and HAck.
 > 
 > Their intended purpose is to
 > 
 > - let NAR not invoke ND
 > - buffer incoming packets, and
 > - proxy NCoA
 > 
 > There was also a suggestion that HI and HAck can be used
 > to validate the forwarding for MN: i.e., PAR, with which NAR
 > should have a trust relationship, can validate the forwarding
 > entry at PAR. Perhaps this should be optional ?
 > 
 > There was a proposal (from Hesham Soliman) to make HI and HAck
 > optional. The reasoning, as far as I understand, is as follows.
 > 
 > Assuming that PAR has processed FBU, consider packet
 > arrivals at NAR. Performing address resolution, NAR creates
 > an ND cache entry in INCOMPLETE state and sends NS.
 > If the MN hears this (or a re-transmitted) NS, it responds
 > with a corresponding NA. If it does, NAR immediately
 > moves the ND entry to REACHABLE and starts forwarding
 > packets. Considering the variability in handover delay and
 > packet arrival times, this is less likely to happen.
 > 
 > In the more likely scenario, the MN simply sends an
 > unsolicited NA, which moves the cache entry state to STALE that
 > triggers neighbor reachability detection algorithm. However,
 > this proceeds in parallel with packet forwarding.
 > 
 > 
 > Here are my concerns with the above suggestion.
 > 
 > - It is not clear why NAR should buffer arriving packets
 >     any more than what ND would do for any arriving packets.
 >    A suggestion was to increase the size of the ND queue, for which
 >     RFC 2461 states:
 > 
 >     "While waiting for address resolution to complete, the 
 > sender MUST,
 >    for each neighbor, retain a small queue of packets waiting for
 >    address resolution to complete.  The queue MUST hold at least one
 >    packet, and MAY contain more.  However, the number of 
 > queued packets
 >    per neighbor SHOULD be limited to some small value.  When a queue
 >    overflows, the new arrival SHOULD replace the oldest entry.  Once
 >    address resolution completes, the node transmits any 
 > queued packets."
 > 
 >     Why should this generic queue be made larger because of handover?
 > Or,
 >      what indication NAR has to selectively make this queue 
 > larger for
 > handover
 >      packets ?
 > 
 >      What do others think ?
 > 
 >     Note that keeping the queue size as is, i.e., small 
 > could result in
 > packet
 >     loss, especially that of FBack since the oldest entry is replaced
 > first.
 > 
 > - It is implicit that FBack is received on the old link. 
 > Only then the
 > MN
 >     knows packets would be arriving at NAR. The MN cannot move after
 >     transmitting FBU because if FBU is lost, packets won't 
 > be arriving
 > at
 >     NAR. Hence, NAR will not have any ND cache entry, and 
 > according to
 >     RFC 2461, ignores the unsolicited NA that the MN sends.
 > 
 >      "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."
 > 
 > - Even when NAR has an entry in INCOMPLETE state, moving the
 >     entry to STALE still invokes neighbor reachability detection
 > algorithm
 >     in parallel with packet forwarding. The additional 
 > message exchange
 >     over the air may not be desirable.
 > 
 > 
 > 2) Relevance of FNA
 > 
 > The intended purpose of FNA is to
 > 
 > a) move an existing entry to REACHABLE state directly
 > b) to request creating one taking into consideration 
 > possible conflicts.
 > 
 > Sending unsolicited NA with O=1 accomplishes a) and should be
 > done when MN has received FBack and knows NCoA use is
 > acceptable. However, unsolicited NA won't create an entry
 > if NAR does not have one. If it does have one, there is additional
 > consideration of possible address conflict. So, the semantics of
 > FNA should address these considerations.
 > 
 > FNA is common for both predictive and reactive scenarios.
 > In the reactive scenario when MN sends FBU from the new link,
 > without FNA, router has to spend an additional round-trip performing
 > ND when packets packets arrive. It also serves to verify if 
 > NAR already
 > has an entry for some other node. In the predictive case, 
 > FNA announces
 > to NAR to deliver any buffered packets immediately.
 > 
 > The current format of FNA will be changed to be a Destination
 > Option so that FBU can be sent encapsulated (i.e, the Next Header
 > field in Destination Option points to IPv6) in a single
 > message. Such an encapsulation allows NAR to drop FBU in case
 > if it detects any conflicts for NCoA in its ND cache. It also helps
 > to acquire the radio channel only once.
 > 
 > I sense that this text related to FNA is acceptable for the next
 > version.
 > Let me know otherwise, suggesting alternative "text".
 > 
 > Thanks,
 > 
 > -Rajeev
 > 
 >

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 30 Jun 2003 09:43:51 -0700

Hesham,

we don't seem to share a common reason to
to ask making HI and HAck optional. As I have discussed earlier and
below in the text, the purpose of HI and HAck is not
to do address duplication verification alone. So, I would
ask the WG to recommend them as Optional for the
reason you quote below, i.e., for address duplication verification.

I also do not share your characterization regarding FNA. Again,
this has been discussed and I provide its purpose below in my summary.

Regards,

-Rajeev