> From: Jonathan Hui <[email protected]>
> Date: Fri, 19 Feb 2010 07:55:17 -0800
>
> Since we are going down this path, I'd like to agree on what the
> 6lowpan ack/frag mechanism should provide before we get into the
> details of bits/bytes. Let me throw out my preferences:
>
> - Ability to ACK/NACK and 6lowpan packet, whether or not it is
> fragmented. The NACK is really useful to explicitly indicate that the
> receiver does not currently have the buffer space to store the 6lowpan
> packet.
>
> - Ability to carry arbitrary payloads in the ACK/NACK. There have
> been many times in the past where being able to piggyback information
> on the ACK/NACK can be helpful. We would probably initially define a
> SNACK option, but I'd really like to keep it general enough so that we
> aren't stuck with whatever we define immediately.
>
> - Carry a 6lowpan packet sequence number/tag separate from the MAC
> header to assist in identifying 6lowpan fragments/packets as well as
> suppressing dups.
>
> - Maintain backwards compatibility with the existing RFC 4944 fragment
> header.
Jonathan,
That seems like a good list of goals, as long as nothing
too complicated results.
For arbitrary payloads, would it be enough to allow the
ACK/NACK to be followed by additional LoWPAN frames? The
piggybacked data could then be defined completely separately.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
