[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

Okay, here's a patch for this paragraph.  If some particular needs to
be clarified, let me know...

Incoming packets must be dispatched either to the AM stack or the
Ieee154 stack, depending on the value of the "network" byte.  After a
packet is received, the radio stack must inspect the value of the
network byte.  If the value is TINYOS_6LOWPAN_NETWORK_ID (= 3f), the
packet is treated as an AM packet and dispatched through the AMReceive
interface based on the next byte, "type".  The payload pointer is
updated to point to the byte after the type byte: this will be the
address of the msg->data field.

Otherwise, the packet is not an AM packet, and dispatched through the
Ieee154Receive interface.  The payload pointer continues to point at
the "network" byte, and further dispatching is left to higher layers.

On Thu, Jul 2, 2009 at 12:00 PM, Philip Levis<pal at cs.stanford.edu> wrote:
>
> On Jul 2, 2009, at 11:29 AM, Stephen Dawson-Haggerty wrote:
>
>> In order to correctly dispatch AM packets, radio stacks with IFRAMES
>> enabled must snoop on the payload-- if the first byte is
>> "TINYOS_6LOWPAN_NETWORK_ID", the packet must be dispatched to the AM
>> stack.  Otherwise, it is dispatched through the above interfaces.  The
>> AM interface semantics and offsets do not change, and when IFRAMES or
>> TFRAMES are enabled, the AM payload is aligned on (message_t).data.
>> (This means the Ieee154 payload _isn't_ aligned there).
>
> Can you talk a little bit about how this dispatch will work?
>
> The rest of the proposal looks good to me.
>
> Phil
>