Subject: RE: [Mipshop] Questions about implementation of FMIPv6

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 11 Oct 2004 22:10:05 -0400

> > 2. In the draft, when NAR receive FNA, if NCoA is not 
 > valid, NAR will
 > > send out RA containing NAACK option. I think a new ICMPv6 message
 > > should be defined as the acknowledgement to FNA, and 
 > whether the NCoA
 > > is valid or not, the acknowledgement should be sent out. 
 > Because RA is
 > > sent out by a user space daemon program (radvd), not 
 > kernel protocol,
 > > so it is not suitable to act as the acknowledgement to 
 > FNA. Considering
 > > FNA may be lost because of the unstable signal strength, 
 > an acknowledge
 > > to FNA is always needed.
 > >
 > 
 > I thought the new MIPL version had MIPv6 in user space except for
 > per-packet processing (routing header, home address option 
 > processing).
 > So, FNA processing would also be in user space..
 > In any case, the point of not sending an RA for every FNA is 
 > that you do
 > not
 > need to send them unless there is a conflict or the router 
 > wants to supply
 > an address. If FNA processing is in kernel, you need raw sockets or
 > something
 > like that to trigger the routing daemon to send an RA in 
 > rare instances.

=> In my experience it's  very hard to do this, at least in
BSD. Having a kernel event to trigger a user space event is 
not trivial, it's much easier to communicate from user space to
the kernel than the other way around.

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: "Charles E. Perkins" <[email-masked]>
Date: Tue, 12 Oct 2004 07:15:30 -0700

Hello Hesham,

You bring back pleasant memories.

Doesn't one typically arrange to select() on
input from a file descriptor opened from,
say, /dev/trigger?  I reckon the value of the
data retrieved from the device driver could
provide any details about the kind of trigger
fulfilling the select().

If I'm remembering it all wrong, please
forgive.

Regards,
Charlie P.

---

From: "Donald W. Gillies" <[email-masked]>
Date: Tue, 12 Oct 2004 09:56:29 -0700

With select(), you give it a bitmap of file descriptors to poll.  If you program the kernel I/O system to perform asynchronous I/O, then select() returns immediately with new bitmaps indicating which devices are ready for read() and which ones are ready for write().  If doing synchronous I/O (normal case when you start a process) then select() blocks until at least one bit is set.

It is not too terribly difficult to do this with BSD UNIX, however, for efficiency what you really want to do is to put your source code into the kernel, where your asynchronous events can trigger "upcalls" that perform actions immediately, rather than having to wait for a high-overhead context switch (on the order of 1 millisecond with today's UNIX kernels, i believe), in order to process the asynchronous event.  These upcalls are typically invoked from either drivers (a la Ethernet driver upcalls into TCP) or from the expiry of a kernel timer.

- Don "Remembering my port of IIJ PPP to BSDI" Gillies
San Diego, CA

At 07:15 AM 10/12/2004, Charles E. Perkins wrote:

>>> > 2. In the draft, when NAR receive FNA, if NCoA is not > valid, NAR will
>>> > should be defined as the acknowledgement to FNA, and > whether the NCoA
>>> > is valid or not, the acknowledgement should be sent out. > Because RA is
>>> > sent out by a user space daemon program (radvd), not > kernel protocol,
>>> > so it is not suitable to act as the acknowledgement to > FNA. Considering
>>> > FNA may be lost because of the unstable signal strength, > an acknowledge
>>> > to FNA is always needed.
>>> >
>>> per-packet processing (routing header, home address option > processing).
>>> In any case, the point of not sending an RA for every FNA is > that you do
>>> not
>>> need to send them unless there is a conflict or the router > wants to supply
>>> like that to trigger the routing daemon to send an RA in > rare instances.
>>
>>BSD. Having a kernel event to trigger a user space event is not trivial, it's much easier to communicate from user space to