Hello,
I have included a participants list below along with affiliations. Please let me know if I have
forgotten anybody. Since the group is getting large it may be time to move the discussion to
a list. If someone has a mail list they want to use please let me know. I am not sure if we
can keep this discussion on the pilc list??? Maybe an AD can advice us on this?
Preliminaries
Before I release my drafty draft, or other folks do, I want to clear up some confusion I saw on
the list. This group is taking the "perspective" of a link layer "looking up" at the network layer.
Historically, the layered design used to partition the Internet protocol stack has been designed
in a top down / client-server manner. With most of us having been exposed to MANETs
and object oriented technology, and most likely design patterns, we can see the limitations of
the strictly top down approach. As link people "looking up", we see that it would be nice to have
something analogous to the Berkley sockets layer, but on the bottom half of the IP stack!
First Things First
It seem that one of the most important things we can do is send notifications to the IP layer from
the link layer. I suggest that we support a ring buffer (of implementation dependent size) at the
IP layer that is used for accepting link layer notifications, signals, triggers, events or whatever these
things have been called. An optional linkable library would be created much analogous to the
BSD sockets (or Winsock) layer that now supports IP underbelly access. A group of functions will
be necessary for managing the IP input queue. This queue could be designed as a balking
ring buffer or an overwrite ring buffer. The access functions would be used to place events into
the IP underbelly. This buffer could also be implemented as a priority queue. I imagine there
would be a separate queue for each link layer that is bound to the IP layer. Also, the socket
layer tie-in is crucial. It is necessary that in some cases these notifications just pass through
the IP layer to the transport layer, or the application layer. The events in some cases may just
be considered out-of-band meta data/data.
The link layer will need to be able to pass an "event record" up to the IP stack. This record
would probably need to include source/destination link address, source/dest IP address (could
be pointer to list of "known neighbors/bindings"), an event type, a version identifier, and set of
event qualifiers. For example, Event=RSSI0, Qualifier=<some value>, etc.
Please pile on and all comments/questions are welcome!
Thanks, Phil Neumiller
Participants List
Flarion
Corson@flarion.com - Scott Corson
University of Newcastle upon Tyne
Einar.Vollset@newcastle.ac.uk - Einar Vollset
Univeristy of Bonn, Germany
gerharz@cs.uni-bonn.de - Michael Gerharz
U.S. Navy
budden@nps.navy.mil - Rex Buddenberg
Motorola, Inc.
M.Sasuta@motorola.com - Mike Sasuta
Univeristy of California, Santa Cruz
chane@cse.ucsc.edu - Dr. Chane Fullmer
Samsung Advanced Institute of Technology
athene@sait.samsung.co.kr Dr. Jinhyuk Choi
<No Email> Jihoon Lee
MeshNetworks, Inc.
pneumiller@meshnetworks.com Phil Neumiller
ewhitehill@meshnetworks.com Eric Whitehill
Nasa Folks
wivancic@grc.nasa.gov William Ivancic
tbell@grc.nasa.gov David.H.Stewart@grc.nasa.gov
Cisco Systems, Inc.
dshell@cisco.com
brunner@nic-naa.net Eric Brunner-Williams
University of Salzburg
h.d.clausen@ieee.org
Lulia Technical University
dugdale@sm.luth.se Anders Lindgren
<?>
Marie-Jose Montpetit vze2prqh@verizon.net
Ohio University
kruse@ohio.edu
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 10:36:55 EDT