[Tinyos-devel] net2 goals/timeline for 2.1.1

[Eric Decker]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090612/d0771f1f/attachment-0001.htm