[net2-wg] Fwd: Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

---------- Forwarded message ----------
From: Miklos Maroti <mmaroti at math.u-szeged.hu>
Date: Tue, Jun 30, 2009 at 10:03 AM
Subject: Re: [net2-wg] Incremental Radio Interface Update for 2.1.1
To: Stephen Dawson-Haggerty <stevedh at eecs.berkeley.edu>
Cc: Philip Levis <pal at cs.stanford.edu>, net2-wg
<net2-wg at millennium.berkeley.edu>, David Moss <dmm at rincon.com>


Hi Stephen,

This sounds great for the RF2xx codebase, and a good starting point to
migrate away when we introduce 64-bit addresses. A few comments and
questions:

- From my experiences with supporting BLIP on the RF2xx, PacketLink is
automatically enabled for the Ieee802154C, but it is off by default
for the ActiveMessageC. How are we going to merge these two since they
are compile time switches.

- I assume that CC2420RadioC will do the fanout, so it will provide
parametrized Send and Receive interfaces, right? However, what if we
want to enable TFRAMES, then this fanout will disappear and only
Receive[TINYOS_6LOWPAN_NETWORK_ID ] will be called?

- Will it be possible to use Ieee802154C without the 6lowpan network
id, so is there going the be an IEEE802154FRAMES switch similar to
TFRAMES?

- Can we name all components with 154 instead of 802154? It is getting
rather long. The current code base has both usage, at least we should
converge them to the same.

Miklos

On Tue, Jun 30, 2009 at 6:53 AM, Stephen
Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
> Here's a more detailed proposal for system-wide link abstractions,
> reflecting an implementation that supports blip and AM simultaneously,
> and also works with AM when using TFRAMES.  I've tried to make things
> as clean as I can without breaking any backwards compatibility-- ie,
> no struct or interface changes.  Please let me know what you all
> think-- I'm going to do some more testing in the next day or so and
> try to get a patch then.  Phil-- does this need to be vetted by core?
>
> Network stacks: System-wide link abstractions
> ---------------
>  AM Stack: HIL is at ActiveMessageC.  Wires platform-specific code.
>           network ID is TINYOS_6LOWPAN_NETWORK_ID (0x3f) if IFRAMEs used.
>  802.15.4 Stack: HIL is Ieee802154C.  Wires platform-specific code.
>           provides receive parameterized on network ID for convenience.
>           [this is what's required for blip operation]
>           [this will be replaced in the future by WG stack]
>
> cc2420 implementation
> -----------------
>  The two system-wide abstractions are provided on top of a new
> component, CC2420RadioC, which wires together the lower-layers in one
> place.
>
>  CC2420ActiveMessageC continues to provide AM support
>    - Requests/releases resource at every send to preserve current semantics
>
>  Ieee802154C       -> provides hardware-agnostic pass-through like
> ActiveMessageC -- chip independent
>  CC2420Ieee802154C -> required to be radio stack specific because of
> packet formats
>    - Resource            - get the radio lock to send packets
>    - Ieee154Send         - send 802.15.4 packets with 16-bit short
> IDs.  basically a renamed AMSend.
>    - Receive[networkId]  - receive packets with a specific networkId.
>  parameterized to avoid fanout problems
>    - Packet
>    - Ieee154Packet       - Basically a renamed AMPacket
>
>    Because IEEE802154 doesn't have a dispatch field, these interfaces
>    are not parameterized (except for network id).
>
>
> And here's how it plays for apps.  Although adding additional networks
> is possible, below the queuing layer is device-specific.
>
>   ---------------------------------------
>   | CTP             |    TCP     |          <- Transport
>   ---------------------------------------
>   | AMQueue         |    BLIP    |          <- Queuing
>   ---------------------------------------
>   | ActiveMessage   |  802.15.4  | ...      <- "Resource" arbitrated
> sharing, chip specific
>   ---------------------------------------
>     CC2420RadioC                            <- Shared radio stack wiring
>     CC2420TinyosNetworkC
>     LplC
>     CsmaC
>
>
> On Sun, Jun 28, 2009 at 6:40 PM, Stephen
> Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
>>>
>>> I think it boils down to a code size vs. RAM size issue. Queueing has a
>>> larger RAM cost than locking. I'd like to see what the code size costs are.
>>> I'm not sure what would be more, the locking or the queue management. One
>>> issue there is that locking scales pretty linearly with clients, while
>>> virtualization has only a small incremental cost per client. But I'd expect
>>> we're not talking about tons of clients, so this is less of a concern than
>>> the constant factors.
>>
>> I'm also very very concerned about the code size issue, especially in
>> the common case where there is only one client (network).  In fact,
>> the patch I sent it includes tests for the case where there is only
>> one client and uses simplified logic-- this saves about 300 bytes ROM
>> over the more general case.  The queuing is about as simple as I can
>> make it, and it uses FcfsResourceQueue to actually do the queuing.
>>
>> Steve
>>
>