Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 Aug 2005 23:38:08 -0400

Hey Greg, 

 > Soliman, Hesham wrote:
 > >  > I think, atleast to notify NAR about MN arrival, so that
 > >  > NAR can forward the buffered packets, we need
 > >  > some message(FNA). This may be done by some
 > >  > other means like L2 trigger at NAR, if available.
 > > 
 > > => This was discussed for a very long time late 2003. 
 > > You can do that by sending a standard NA. It works fine 
 > > according to 2461 and 2461bis.
 > 
 > I'd guess that creation of any valid neighbour cache
 > entry on the router could work for this purpose.
 > As soon as the NCE is created, forwarding would occur.
 > So even an NS would do the job.

=> An NS might be useful but it might not, depending on 
whether the NAR solicited the MN before it moved. But I think
the NA would always work. 

Hesham

 > 
 > This should even be applicable if the cache policy was
 > modified through FMIPv6 signalling previously.
 > 
 > Greg
 > 

===========================================================
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: Greg Daley <[email-masked]>
Date: Wed, 10 Aug 2005 13:55:46 +1000

Hi Hesham,

> the NA would always work. 

An NS containing an SLLAO always creates an NCE in STALE state.
This is a valid NCE for packet delivery.

It doesn't matter if there's an existing solicitation outstanding.

So I think that the focus should probably be on valid NCEs,
with some mention of how to create one in a way compatible with
FMIPv6 (with ODAD, NA is fine), rather than on which packets
should be sent (and no mention of the NCE).

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 07:58:16 -0700

> should be sent (and no mention of the NCE).

Since the MN must multicast an NS anyway for oDAD, the SLLAO can be used for
routing packets back to the MN, and the router will get it if its an MLDv2
router, what's the problem with using it?

I thought the intent was to minimize the amount of traffic a MN must send to
get up on a link.

        jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 11 Aug 2005 12:09:49 +1000

Hi James,

> I thought the intent was to minimize the amount of traffic a MN must send to

The DAD NS comes from the unspecified source address, and cannot contain
an SLLAO.

It could contain a tentative option though, as in:
draft-daley-ipv6-tsllao-02.txt

This would have the same properties, but wouldn't necessarily
violate 2461.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Aug 2005 15:17:12 -0700

Greg,

I guess I've lost track of exactly what we are trying to achieve here.

Here is what the RFC 4068 says about FNA:

   The MN sends a Fast Neighbor Advertisement to the NAR, as soon as it
   regains connectivity on the new link.  Arriving or buffered packets
   can be immediately forwarded.  If NAR is proxying NCoA, it creates a
   neighbor cache entry in REACHABLE state.  If there is no entry, it
   creates one and sets it to REACHABLE.  If there is an entry in the
   INCOMPLETE state without a Link-Layer Address, it sets it to
   REACHABLE.  During the process of creating a neighbor cache entry,
   NAR can also detect if NCoA is in use, thus avoiding address
   collisions.  Since the FBU is encapsulated within the FNA when sent
   from NAR's link, NAR drops the FBU if it detects a collision.

What the FNA is expected to achieve is to get the router a NC entry that it
can use to route the buffered packets to the host immediately.

Regarding:

>It has previously been argued that the DAD NS isn't time critical
>for optimistic hosts.   Does it make sense to tie this to the
>critical path for FMIPv6 hosts (since they'd have to do DAD anyway,
>and it would be nice to have a single link seizure for both
>announcement and DAD initiation - apart from MLD reports that is)?

unfortunately, for FMIPv6 hosts (or any hosts moving to a new link for that
matter), oDAD *is* time critical since the router needs to be able to get
packets to the host immediately. Of course, the host has to get packets to
the router too but that does not require the router's NC cache to be
modified. The oDAD draft has an assumption in it the the router will use
standard address resolution to find the mobile's link address, but that is
likely to be too slow for FMIP.

So, I think if we are going to use oDAD with FMIPv6 and drop FNA, some
changes will be needed. I think we could use TSLLAO with the oDAD NS, this
would allow the router to get packets back to the MN. If the address was in
conflict, then oDAD would resolve it. Also, the FMIP spec would have to
require the oDAD NS to be sent out immediately.

            jak

----- Original Message -----
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>; "Koshiro
MITSUYA" <[email-masked]>; "Alexandru Petrescu"
<[email-masked]>; "Junghoon Jee" <[email-masked]>
Sent: Wednesday, August 10, 2005 7:09 PM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

---

From: Greg Daley <[email-masked]>
Date: Fri, 12 Aug 2005 10:12:07 +1000

Hi James,

I think we wandered far, but you've brought things back and
articulated a good path forward.

> require the oDAD NS to be sent out immediately.

OK. So long as we've got these assumptions mapped out, it may be a good
way to go.

AFAICS, it's not more difficult to do the oDAD snooping than to process
an FNA.

Greg