[Tinyos-devel] net2 goals/timeline for 2.1.1

[Miklos Maroti]

Eric,

You can look at the RF230 code, which could be a generic solution. It
already supports BLIP, but since there is no consensus on the 64/16
bit addresses it currently support 16 bit addresses only.

Miklos

On Wed, Jun 17, 2009 at 4:51 AM, Eric Decker<cire831 at gmail.com> wrote:
>
>
> 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
>
>