[net2-wg] header format changes (?)

[Stephen Dawson-Haggerty]

Oops, that last message got sent before I was ready.

Currently, the cc2420 header sits inside the header region of a message_t,
and the application payload starts with the first byte of the data region.

We will not change this for active messages.  However, we will consider
packets where the "network" byte of an I-frame is not
TINYOS_6LOWPAN_NETWORK_ID to be 802.15.4 packets.  Therefore, the payload
region of these packets will start with the network byte of the header.
Note that this will NOT be aligned with the data region of the message_t; it
will start two bytes earlier.

This is an issue for bridging these packets to serial, but as long as the
person doing the forwarding is aware of it, it's not a big deal.  I have a
patch that makes these change and both AM and non-AM modes work fine.  This
approach has the virtue of it being the one that seems least likely to break
existing code.

Here's what the interfaces would do.

>     interface Receive as IEEE154Receive;


Receive packets where the cc2420header->network is not
TINYOS_6LOWPAN_NETWORK_ID.  The "Payload: would point to
&(cc2420header->network) and then length will include the network and type
bytes.

>
>     interface IEEE154Send;


Send a 15.4 packet.  Basically the same as regular send but don't reference
active message ids.  The length value passed in does not include the network
and type fields of the cc2420 header.

>
>     interface IEEE154Packet;


More or less an AMPacket interface with the type-related commands removed.


>
>     interface Packet as SubAMPacket;


A Packet, which considers the payload to start at the network byte, not
after the am type byte.





>
>
>
>
> 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/e77157aa/attachment.htm