Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 17 Aug 2005 18:50:24 -0400

Rajeev, 

See section 5 for detail on sending packets in different states. 

     STALE       The neighbor is no longer known to be reachable but
                  until traffic is sent to the neighbor, no attempt
                  should be made to verify its reachability.

And here is an excerpt from 5.2:

 Once the IP address of the next-hop node is known, the sender
   examines the Neighbor Cache for link-layer information about that
   neighbor.  If no entry exists, the sender creates one, sets its state
   to INCOMPLETE, initiates Address Resolution, and then queues the data
   packet pending completion of address resolution.  For multicast-
   capable interfaces Address Resolution consists of sending a Neighbor
   Solicitation message and waiting for a Neighbor Advertisement.  When
   a Neighbor Advertisement response is received, the link-layer
   addresses is entered in the Neighbor Cache entry and the queued
   packet is transmitted.  The address resolution mechanism is described
   in detail in Section 7.2.

Also see the state machine. 
I don't know of any implementation that restricts sending traffic 
to reachable neighbours. If you know any please let us know.

      (NOTE: it is not clear to me whether an
 > >  >     unsolicited NA immediately prompts a new NS or the 
 > state machine
 > >  >     waits until the next NS is triggered since address 
 > resolution is
 > >  >     in progress). This means either active probing (sending
 > >  >     NS, expecting solicited NA) or "forward progress" 
 > determination.
 > > 
 > > => It doesn't matter, there is no disruption of service. 
 > 
 > What does happen? I am curious.

=> Packets continue to be sent, while doing NUD. 

 > > => There are several unstated assumptions here:
 > >   a. You're assuming that either the BU is lost or that
 > >      the transition to the new link was quicker than the 1/2 RTT
 > >      between the MN and the PAR plus 1/2 RTT between the 
 > PAR and NAR.
 > >      The second case is extremely unlikely. But even if it happens
 > >      this would be a normal ND transaction. Note that it 
 > is very unlikely
 > >      that this happens. 
 > >   b. If the BU is lost, you're assuming that the MN would 
 > resend the
 > >      BU to the PAR. Even if this is the MN's fallback, by 
 > that time, 
 > >      the NS/NA is not a big issue because FMIP has 
 > basically failed. 
 > 
 > The assumption is that this is the FMIP reactive handover :-)
 > I don't see why FMIP has failed. It's just that FBU is sent 
 > from the new
 > link.

=> But in this case there is nothing to worry about, the MN
will send the BU while doing DAD (e.g. oDAD) and when
packets are received normal ND will take place. a normal
NS could install a NCE. Alternatively, address resolution
could be done by the AR. This can't possibly be a significant
delay component given the amount of packet loss experienced
during the L2 switch. Note that all this is only relevant to
L2s that need address resolution, i.e. ethernet-like. The delay
of address resolution is insignificant in this case. 

 > 
 > > => You MUST NOT set the state to REACHABLE until you know that 
 > > bidirectional reachbility is available. The FNA does not do that. 
 > > It seems like an ill-defined shortcut to me.
 > 
 > If you could forward packets "optimistically" when in STALE 
 > state, why 
 > not make it "official" for FMIP purposes? Note that this is an FMIP 
 > optimization, and not baseline ND operation.
 > 

=> REACHABLE is not an "official" statement for the existence of 
a node. It means that bidirectional reachability was confirmed. 
So sending and receiving packets is not tied to a node being 
reachable. In fact, you can't even set a NCE to REACHABLE based 
on sending an RS and receiving an RA. You have to do NUD or rely
on forward progress from upper layers. 

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 18 Aug 2005 10:03:08 -0700

didn't see this..

Thanks for the reference.

>    in detail in Section 7.2.

This really does not say what happens in STALE state, but there is the 
other e-mail exchange.

> packets are received normal ND will take place. a normal

Actually in the reactive mode, you don't do DAD. It is just that FBU is 
sent from the NAR's link, as soon as the attachment occurs.

> during the L2 switch. Note that all this is only relevant to

Not sure about the packet loss.. It is highly dependent on the 
application. With the VoIP experiments we have done, it is dependent on 
whether there is a talkspurt (and its duration etc.) coinciding with 
handover.

> of address resolution is insignificant in this case. 

There is L2 switching delay and then the RTT over the air itself. In 
addition, there is processing delay at the nodes. I would still like to 
minimize any signaling independent of particular L2 switching and RTT 
values. That way, the protocol will be independent of them.

> a node. It means that bidirectional reachability was confirmed. 

I meant if the state is REACHABLE, then you know you can deliver packets 
without requiring reachability confirmation (which eliminates the need 
for any signaling even if it happens in parallel in an implementation).

-Rajeev