On Jan 15, 2007, at 1:05 PM, gabriel montenegro wrote:
Going back to Carsten's 3 options. Now that it's clear that nobody
was asking for option 3
below perhaps we can move forward. As I see it, relaxing the order
of the headers
as per Option 2 by itself does not help much. How does this next
hop know if it is the
sole recipient of all the fragments? Kris eloquently points out
that this is a real
problem in a mesh. Perhaps what is needed is some negotiation in
addition to merely
relaxing the ordering of the headers (as done, for example, with
DTN). If so, I
could change the text as follows:
AFTER:
When more than one LoWPAN header is used in the same packet, they
MUST appear in the following order:
Mesh Addressing Header
Broadcast Header
Fragmentation HeaderADD:
Future revisions of these processes may relax the above header
ordering.
So whereas this ordering is currently mandated, we would keep the
door open
for future variations to be specified separately.
And to answer Phil's question: this does not contravene
IPv6. Even though the current header format may have been inspired
by IPv6,
IPv6 itself is impervious to it as this is hidden under IP.
Does this work?
Give that the current proposal allows for new headers to be
introduced along with their ordering, I think the "may relax"
statement is not necessary. We can always introduce a new
fragmentation (or routing) header that switches the order around.
That being said, if you want to hedge your bets, then best to be more
precise: MUST the ordering on transmit and SHOULD the fact that you
need to accept either. But of course this is going to make the whole
thing harder to implement.
I think it's better to leave out the addendum.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
