[net2-wg] header format changes (?)

[Stephen Dawson-Haggerty]

I'm going to go ahead and assume that the lack of discussion means people
are okay with this change since it shouldn't break anything.  Anybody
disagree?

Steve

On Mon, Feb 9, 2009 at 3:29 PM, Stephen Dawson-Haggerty <
stevedh at eecs.berkeley.edu> wrote:

> Yeah, in fact I think that's what I'm doing.
>
>
> On Mon, Feb 9, 2009 at 3:06 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
>>
>> On Feb 9, 2009, at 11:00 PM, Stephen Dawson-Haggerty wrote:
>>
>>  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.
>>>
>>
>> I assume the issue for bridging to serial only occurs if you use AMSend on
>> the serial path? That's the only interface which you're supposed to be able
>> to assume data payload alignment. So why not add a Ieee154Send? (Coding
>> conventions say IEEE should be Ieee.) This was the original intent of having
>> the dispatcher and multiple serial packet formats.
>>
>> Phil
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/net2-wg/attachments/20090211/1060572d/attachment.htm