[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

I put some more comments below.  I think we're not actually so far
apart.  I do want to emphasize that the network byte is technically
part of the 802.15.4 payload, and so needs to follow any other
link-layer (ie, security) headers and immediately precede the payload.

I think what we're talking about is:

We could have an interface which provides the following to 802.15.4 clients
Resource as SendResource[client]
Send;  - networkId is the first byte of the payload
Receive[networkId]

Alternatively, we could have
Resource as SendResource[client]
Send[networkId];  - networkid is not part of the payload
Receive[networkId]

I prefer the first because I believe it hues more closely to the
standard, although we are still dispatching on a non-standard field.
Payloads are treated identically from send and receive, though: both
include the network byte.

On Tue, Jun 30, 2009 at 12:33 PM, Miklos Maroti<mmaroti at math.u-szeged.hu> wrote:
> Hi Stephen,
>
>>> Maybe I completely misunderstand the use of the network byte, maybe
>>> you do not want to use a single network (like for TFRAMES) for TCP.
>>
>> This actually gets at a secret motivation of mine :)  The current
>> 6lowpan draft I implement (draft-hui-6lowpan-hc-01) uses two network
>> ids, one for link-local and one for global scope communication.  More
>> recent drafts have used a larger number of network ids as they try to
>> find some extra bits.  Now, we can certainly argue about whether or
>> not this is okay, but looking forward it's would be nice if we didn't
>> have to change a bunch of stuff to make this work cleanly, and just
>> leaving the network byte as part of the payload does this.
>
> Then I am lost. It does not seem right to leave the network id in the
> payload if you do dispatch on it. I see only two clean solutions:
>
> 1. Remove the network id from the payload, do full dispatch on the
> 8-bit network id, (and maybe provide a NetworkPacket interface to
> query the network id of the received packet)
>
> 2. Leave the network id in the payload, dispatch only between
> ActiveMessage (by peeking inside the payload) and Ieee154MessageC. The
> Ieee154MessageC could provide a single Send/Receive interface where
> the network id can be read and set as the first byte of the payload.

This doesn't seem any less broken the leaving the network id in the payload.

>
> Maybe you anticipate several components on the same mote to use
> different network ids?

We already have this, right?  AM uses one, and 802154 uses some other
ones.  When we talked about this a while back, there was strong
push-back from Om and Phil that we must support AM and 802.15.4/IP on
the same mote.  That's why we have some of these issues.

>
> Now thinking more about the send side I also have some problems. Do
> you want the payload to contain the network id when passed to the Send
> interface? If no, then the receive/send will be asymmetric, if yes,
> then you do not do fanout with send, only with receive. By the way, I
> think there should NOT be a built in fanout based on client id. The
> radio stack should simply provide a resource arbiter, and the
> AMSenderC and Ieee154SenderC should take care of the locking.

Doesn't this mean that they will receive sendDone events for messages
they did not send?  They could filter these, I just thought it would
be cleaner not to do it this way.

You're correct about the fanout only happening on receive; we can't
wire multiple components to the same receive interface because if we
do, we get multiple message_ts returned for the buffer swap.

>
> Miklos
>