Subject: RE: [pilc] L2 views

From: Eric Whitehill <[email-masked]>
Date: Tue, 7 May 2002 10:51:48 -0400

Phil,

Perhaps I didn't see it, but did everyone agree to the problem statement
that you included in 
your 4/30 e-mail?

Eric

-----Original Message-----
From: Phil Neumiller [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 7:11 AM
To: Scott Corson; [email-masked]; [email-masked];
Rex Buddenberg; [email-masked]; Dr. Chane L. Fullmer;
[email-masked]; Eric Whitehill; 'William Ivancic';
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Anders Lindgren; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: [pilc] L2 views

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
[email-masked] - Scott Corson

University of Newcastle upon Tyne
[email-masked] - Einar Vollset

Univeristy of Bonn, Germany
[email-masked] - Michael Gerharz

U.S. Navy
[email-masked] - Rex Buddenberg

Motorola, Inc.
[email-masked] - Mike Sasuta

Univeristy of California, Santa Cruz
[email-masked] - Dr. Chane Fullmer

Samsung Advanced Institute of Technology
[email-masked] Dr. Jinhyuk Choi 
<No Email> Jihoon Lee

MeshNetworks, Inc.
[email-masked] Phil Neumiller
[email-masked] Eric Whitehill

Nasa Folks
[email-masked] William Ivancic
[email-masked] [email-masked] 

Cisco Systems, Inc.
[email-masked]

[email-masked] Eric Brunner-Williams

University of Salzburg
 [email-masked] 

 Lulia Technical University
[email-masked] Anders Lindgren

<?>
Marie-Jose Montpetit [email-masked]

Ohio University
[email-masked]

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures. 

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

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 7 May 2002 11:27:04 -0400

Hi Eric,

I am reluctant to carry on discussions on the pilc list, since I would like confirmation
from an AD whether they want this discussion here or someplace else.  I assume they
do, since they relocated the L2 triggers BOF to PILC.   I believe at this point we are
discussing things within the scope of that planned BOF.  

AD Request,

Scott and/or Allison can probably provide clarity here.  I want to express that my 
desired "perspective" is to position ourselves as link layer designers that want to
see some standardization on the IP underbelly, i.e. an API if you will, to IPs darker
side, and a standardized way for IP to send events (at the millisecond time scale)
"up" to the IP layer.  This means adding standardization to IP, not link layers.  It
means we want to standardize the way link layers "talk to" IP in the upward
direction.   The first proposal is a high performance queue for event notification offered
by the IP layer to bound link layers.  The simplest use of this queue is simply to buffer
the notifications and forward them to the transport layer if not "hooked" by the IP
layer.

With respect to your question Eric, several people have sent comments on the problem
statement and everything at this point is work-in-progress and everybody is welcome to
contribute whatever they whenever they can.  Before getting to a formal problem 
statement, it may prove fruitful to first entertain some philosophical discussions regarding
the under-specified IP underbelly.  Perhaps many feel that the current underbelly mechanisms
of arp, rarp, icmp, etc are sufficient for wireless devices???   Maybe the definition of a 
host/gateway just needs some sprucing up (RFC 1122 / RFC 1123)?

Best Regards,

Phil

----- Original Message ----- 
From: "Eric Whitehill" <[email-masked]>