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?
If so, I can prepare a new version of the doc with the above change
as well as some typo and editorial fixes (e.g., delete an outdated "NOTE")
in preparation for IESG.
-gabriel
----- Original Message ----
From: Carsten Bormann <[EMAIL PROTECTED]>
To: gabriel montenegro <[EMAIL PROTECTED]>
Cc: Carsten Bormann <[EMAIL PROTECTED]>; Schumacher Christian Peter Pii <[EMAIL
PROTECTED]>; Philip Levis <[EMAIL PROTECTED]>; Geoff Mulligan <[EMAIL
PROTECTED]>; [email protected]
Sent: Sunday, January 7, 2007 12:09:08 PM
Subject: Re: SV: [6lowpan] WG last call on Format document
> I'd suggest capturing Phil's issue in the writeup used by the
> chairs to advance the document as per:
>
> http://www.ietf.org/IESG/content/Doc-Writeup.html
>
> That way we can invite discussion from the IESG on this item.
While it is always a good thing to obtain input from the IESG, I
don't think delegating this issue to the IESG during document
submission is the right approach here.
The WG is the domain expert on the kind of network we are discussing
here.
The WG should come to a conclusion.
The IESG can then check that we followed process and that the
document fits into the wider IETF picture (which is *not* dominated
by the relevant considerations here).
<wg-chair hat="off">
On the reassembly issue, I see two approaches:
1) keep with the reassembly at destination
2) open up the sequence such that reassembly-before-forwarding
becomes an alternative, chosen by the sender.
3) only allow reassembly before forwarding, i.e. forward only full
datagrams.
(As far as I can see, nobody argues for 3, that's why I see *two*
approaches.)
The advantage of 2 is more options (Philip has explained why this
can be a good thing).
The obvious disadvantage of 2 is more options (i.e., increased
burden on an implementation).
With 2, the sender gets to decide whether a forwarder has to
reassemble before forwarding; the forwarder has to play with that
decision.
(Reassembly at the forwarder also means different fragments cannot
choose different paths; maybe a more theoretical consideration.)
</wg-chair>
I'd like to hear more people taking sides on 1 or 2 before we declare
consensus.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
