RE: [pilc] L2 views

From: Eric Whitehill (ewhitehill@MeshNetworks.com)
Date: Tue May 07 2002 - 10:51:48 EDT

  • Next message: Aaron Falk: "[pilc] pilc list has moved to ietf.org"

    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:pneumiller@meshnetworks.com]
    Sent: Tuesday, May 07, 2002 7:11 AM
    To: Scott Corson; Einar.Vollset@newcastle.ac.uk; gerharz@cs.uni-bonn.de;
    Rex Buddenberg; M.Sasuta@motorola.com; Dr. Chane L. Fullmer;
    athene@sait.samsung.co.kr; Eric Whitehill; 'William Ivancic';
    tbell@grc.nasa.gov; David.H.Stewart@grc.nasa.gov; brunner@nic-naa.net;
    h.d.clausen@ieee.org; Anders Lindgren; vze2prqh@verizon.net;
    kruse@ohio.edu
    Cc: pilc@ietf.org
    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
    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 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
    pilc@ietf.org
    https://www1.ietf.org/mailman/listinfo/pilc



    This archive was generated by hypermail 2b29 : Tue May 07 2002 - 10:56:50 EDT