[Tinyos-devel] net2 goals/timeline for 2.1.1

[Eric Decker]

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