[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

On 6/28/09, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> Dear All,
>
> I think BLIP should use an Ieee154Send interface and not the regular
> Send interface (this is unrelated to having a network id). Quite
> likely we are going to provide 64 bit addresses in the not so distant
> future.

The send interface is address-free, and the idea is that networks will
fill in the fields before sending. 802154, as one possible network
would know how to do this for its packets; I didn't include any
example code in my patch.

>
> Second, if I see correctly, then both BLIP and regular ActiveMessageC
> would use a single network id, so you do not want to dynamically
> change the network id.

No, they will use different ids. AM will continue to use the NALP
network, while 6lowpan specifies several other identifiers.
> Third, I think the "interface Resource as RadioResource[uint8_t
> client]" would be a very good addition, and it should be moved as low
> in the stack as posisble,so it can be shared by all network AND
> active messages. Then we can have a generic AMSenderC and
> Ieee154SenderC components without the extra files such as AMQueue

Exactly my thought; that is what I did in the patch...

Steve

>
> Miklos
>
> On Mon, Jun 29, 2009 at 12:20 AM, Stephen
> Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
>> Hi--  We've been discussing the changes necessary to the radio stack
>> for blip; let me finally provide a concrete proposal.  Is this
>> acceptable to everyone?
>>
>> Goal: add ability to send/receive from multiple "networks", as
>> determined by the "network" dispatch byte in a TinyOS IFRAME.
>> Motivation: the network byte may become assigned by IANA in the
>> future.  We should be able to support new network protocols expecting
>> to receive packets dispatched on this byte.
>> Proposed additions: add three parameterized interfaces as system-wide
>> networking abstractions:
>>
>>    interface Resource[uint8_t clientId];
>>    interface Send as NetworkSend[uint8_t networkId];
>>    interface Receive as NetworkReceive[uint8_t networkId];
>>
>> Sample patch for the cc2420 is attached.  This is not meant to be
>> committed, since it will break if TFRAMES are used and is not
>> well-tested.
>>
>> Just like in the AM layer, we need resource sharing between different
>> senders.  However, I am loathe to add another layer of buffering since
>> most existing code assumes it "owns" the radio and does its own
>> buffering-- both blip and the AM stack do this.  The lightest-weight
>> solution seems to be adding a Resource lock around the radio; with
>> FCFS it will be reasonably fair.
>>
>> Changes to AM: the resource request/release calls are added to
>> CC2420ActiveMessageP, so the semantics of using AMSend do not change.
>> Active Messages become just another "network" but the interface change
>> is encapsulated so there shouldn't be any broken code.
>>
>