[net2-wg] header format changes (?)

Stephen Dawson-Haggerty stevedh at eecs.berkeley.edu
Mon Feb 9 15:29:41 PST 2009


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/20090209/79bfdddf/attachment.htm 


More information about the net2-wg mailing list