[Tinyos-devel] net2 goals/timeline for 2.1.1

[Eric Decker]

On Tue, Jun 16, 2009 at 3:52 PM, Omprakash Gnawali <gnawali at usc.edu> wrote:

> Hi Eric,
>
> Is your effort part of core effort? We would like to write network
> protocols based on the APIs that are supported by core.


That is the intent but so far I haven't had a lot of interaction with the
core
folks.


> Steve has a parallel stack (private copy) due to the requirements we
> have been discussing and we are trying to see if we can avoid
> releasing this private copy of the stack as part of blip. That would
> require that we run blip on top of "standard" messaging API but the
> standard API does not satisfy the requirements yet...


Could I get a look at that stack.  I'd like see what kind of instantiated
APIs interfaces, etc.  your implementation would like.

I am currently teasing AM apart from its hard coded hooks into Serial and
the Radio.  This is giving a flexible encapsulation mechanism.  It loosly
looks
like what Jan Hauer proposed.

At some point I'd welcome you folks looking at what I've done.

eric


> Thanks.
>
> - om_p
>
> On Mon, Jun 15, 2009 at 8:29 PM, Eric Decker<cire831 at gmail.com> wrote:
> > anyone have any thoughts on my missives?
> >
> > eric
> >
> > On Fri, Jun 12, 2009 at 1:38 PM, Eric Decker <cire831 at gmail.com> wrote:
> >>
> >> On Fri, Jun 12, 2009 at 12:47 PM, Philip Levis <pal at cs.stanford.edu>
> >> wrote:
> >>>
> >>> On Jun 12, 2009, at 12:08 PM, Stephen Dawson-Haggerty wrote:
> >>>
> >>> > The major issue for core is the frame format.  The 6lowpan standard
> >>> > when used over 802.15.4 requires the 6lowpan payload to start
> >>> > immediately following the 802.15.4 frame header; the first byte is an
> >>> > IANA assigned dispatch value.
> >>> >
> >>> > This dispatch value is the same as the "network" field when I-frames
> >>> > are enabled, and so it is possible to have a radio stack which
> >>> > supports both Active Messages and other network protocols.  This is
> >>> > pretty much the same as the dispatching of packets base on the
> >>> > ethernet header in other systems-- IP and non-IP protocols can
> >>> > coexist.
> >>
> >> There should in general be a well defined dispatch byte for AM
> regardless
> >> of
> >> what layer is below AM.
> >>
> >>>
> >>> >
> >>> > Conceptually, the layering would be (for AM)
> >>> > --------------------------
> >>> > | 802.15.4 | network (6LOWPAN_NALP) | AM  | ...
> >>> > --------------------------
> >>> >
> >>> > What is needed is an interface to intercept the non-NALP network
> >>> > values and feed them into blip, and an interface to allow blip to
> send
> >>> > packets with its own (arbitrary) network ids.
> >>>
> >>> Well, as I said, it's important to remain radio-chip independent. We
> >>> want to think about blip working on all kinds of link layers, not
> >>> just 802.15.4. So while we definitely have to handle that case, the
> >>> solution should not be constrained to that case.
> >>
> >> What ever layer is at the lowest layer, there should be a well defined
> >> mechanism to specify what layer is next.
> >>
> >>>
> >>> Would it make sense for <RadioChip>ActiveMessageP to have
> >>>
> >>> provides interface Receive as NotAMReceive;
> >>
> >> I realize that the current T2 implementation is AM centric.  I would
> >> suggest
> >> moving away from this centricity and that begs the question of how do we
> >> specify a
> >> static connection that denotes how the protocol stack is put together.
> >> I would propose the following:
> >> At the top level the application explicitly  connects to the layer it
> >> expects to
> >> send and receive from, AM, BLIP, etc.
> >> As the wiring desends the stack each layer has explicitly wired into it
> >> those
> >> upper layers that are willing to send and to accept received packets.
> >> I'm not sure how to wire all this up but it seems to me to be the way to
> >> go
> >> with specifing in a static fashion what protocols are being supported in
> >> the stack and how to dispatch them.
> >> AM becomes just another protocol that sits on top of stuff.  I have a
> >> mechanism
> >> for doing this with the current serial and radio implementations that
> >> preserves
> >> the current packet formats.
> >> In this scheme there wouldn't be any explicit NotAMReceive.
> >> eric
> >>>
> >>> then have a MessageC which exports this?
> >>>
> >>> My one major concern is detecting at compile-time whether you're
> >>> expecting non-AM packets but the link layer doesn't support them. I
> >>> suppose this could be handled by whether the above interface exists.
> >>>
> >>> Phil
> >>> _______________________________________________
> >>> Tinyos-devel mailing list
> >>> Tinyos-devel at millennium.berkeley.edu
> >>>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >>
> >>
> >>
> >> --
> >> Eric B. Decker
> >> Senior (over 50 :-) Researcher
> >> Autonomous Systems Lab
> >> Jack Baskin School of Engineering
> >> UCSC
> >>
> >
> >
> >
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
> > Autonomous Systems Lab
> > Jack Baskin School of Engineering
> > UCSC
> >
> >
>



-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090616/77fbd684/attachment.htm