> Date: Fri, 19 Feb 2010 16:06:37 +0100
> From: "Pascal Thubert (pthubert)" <[email protected]>
>
> But on your example you had the datagram_size over a DWORD barrier
> and I think that can be an issue.
The alternative would be to put the length and offset first,
and the tag second:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment (TBD)|A| datagram_size |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A = ack requested
R = reserved
Personally, I would prefer the tag first and not worry about
the DWORD barrier, but it isn't something I feel strongly
about.
> > The ack is its own dispatch type, distinct from the fragment dispatch.
>
> I see. So you'd use a new dispatch to make any packet ackable. Looks
> good to me. Do you have details on problems that this solves?
The 802.15.4 ack is basically a phy ack. It tells you that
the bits were received, but that is all. It doesn't tell
you that the incoming message passed any security checks or
if the receiver has space to buffer it. The 802.15.4 ack
has no security and no source address.
A 6LoWPAN ack could be secured and would indicate that the
routing layer actually received the packet.
> As I had before, we need the capability to inform of congestion and
> error.
Doing this would raise a lot of questions that I was trying
to avoid. Handling congestion can get quite complicated,
and seems only marginally related to the handling of any
particular message.
-Richard
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
