[net2-wg] header format changes (?)

[Stephen Dawson-Haggerty]

Phil and I had some offline discussion, but this is still an issue so I'd
like to ping the group again.  If you recall, the issue is in supporting
both active messages and bare IEEE802.15.4 messages which do not include the
active message dispatch (this is worth doing for eventual interop, and
saving the byte in lowpan packets.)

I'm proposing adding four interfaces to CC2420ActiveMessageC (And eventually
other radios, I suppose):
    interface Receive as IEEE154Receive;


    interface IEEE154Send;
    interface IEEE154Packet;
    interface Packet as SubAMPacket;



On Sun, Jan 18, 2009 at 2:48 PM, Stephen Dawson-Haggerty <
stevedh at eecs.berkeley.edu> wrote:

> Hmm, good point.  This actually could be an issue no matter how we do the
> packet layout.  Will do some more thinking...
>
> Steve
>
>
> On Sun, Jan 18, 2009 at 2:27 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
>> The problem with this is it means you can't pass packets between link
>> layers. E.g., you have to do a payload copy between the CC2420 and serial
>> stack. This is why the am type is in the CC2420 header.
>>
>> Phil
>>
>>
>> On Jan 18, 2009, at 2:00 PM, Stephen Dawson-Haggerty wrote:
>>
>>  The cc2420 radio stack will need a few small patches to accommodate both
>>> tinyos active messages and non-tinyos 6lowpan messages.
>>>
>>> The goal is to provide standard tinyos AM dispatch when the network byte
>>> in a packet is TINYOS_6LOWPAN_NETWORK_ID, and a more low level 802.14.5-ish
>>> interface when it is not.  That way IP stacks can wire to the 802.15.4
>>> interface and get the packets they need, while other tinyos code using the
>>> AM interface will still work.  My thought is that we should provide both of
>>> these interfaces from ActiveMessageC, although we could potentially also
>>> split them apart.
>>>
>>> My proposal: change cc2420_header_t: remove the 'network' and 'type'
>>> fields, and create a new
>>> typedef struct {
>>>  nxle_uint8_t network;
>>>  nxle_uint8_t type;
>>> } am_header_t;
>>>
>>> The active message layer is now a dispatch layer on top of the
>>> lower-level 802.15.4-ish interface.
>>>  pros: this is clean, and layering-wise the right thing to do
>>>  cons: (1) this means that the 2-byte AM header is part of the payload
>>> region of the message_t therefore, getMaximumPayload() will return
>>> TOSH_DATA_LENGTH -2 , not TOSH_DATA_LENGTH
>>>       also, (2) components attempting to access these two fields from the
>>> cc2420 header struct will no longer compile.
>>>
>>> grepping for code doing (2) didn't turn up anything in core; component's
>>> __shouldn't__ be doing this...  (2) shouldn't matter so long as applications
>>> are using getMaximumPayload and not just assuming it's TOSH_DATA_LENGTH,
>>> although if they've optimized memory use to set TOSH_DATA_LENGTH to be
>>> __exactly__ right it will break.
>>>
>>> We could clearly also do this without changing the header; what I'm
>>> trying to feel out here is how much this will really break, and how much we
>>> care since code-wise this does feel like the right thing to do.
>>>
>>> Steve
>>> _______________________________________________
>>> net2-wg mailing list
>>> net2-wg at millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/net2-wg/attachments/20090209/fc507b87/attachment.htm