[net2-wg] [Tinyos-devel] net2 goals/timeline for 2.1.1

[Stephen Dawson-Haggerty]

No other platforms that I know of.  Then again, I'm not sure I even
knew it worked on the RF230 so I may not be the best person to ask
:-).  Hopefully once I start doing integration for the release
everything will fall out.

Also, I wouldn't say that I have a "private copy".  It's more like two
shadowed files: I don't want to make it seem like there's more
divergence then there is.  Those are in contrib the rest of the blip
release (contrib/berkeley/blip/tos/chips/cc2420).

Steve

On Wed, Jun 17, 2009 at 11:56 AM, Eric Decker<cire831 at gmail.com> wrote:
> that should work well for what I'm doing.
> Is there any other stack that blip sits on top of that i should be aware of?
> eric
>
> On Wed, Jun 17, 2009 at 7:22 AM, Miklos Maroti <mmaroti at math.u-szeged.hu>
> wrote:
>>
>> 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
>> >
>> >
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
>