[Tinyos-devel] net2 goals/timeline for 2.1.1

[Omprakash Gnawali]

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.

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...

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
>
>