On Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote:
On Comment 1: Reassembly: I don't think we should delay the draft
because of this.
I think this is an interesting research topic. I notice that there
are similarities with
the folks applying DTN to sensor networks (projects at UCLA's LECS,
SICS, Trinity College, etc).
DTN is itself a research group in the IRTF, so similarly, I see
such extensions to LoWPAN
as possible alternatives once the basic draft in its current form
is done. One possible
avenue is to reuse AODV to do the discovery of the DTN-capable
devices, and integrate with
the routing layer such that the proper tradeoffs (end-to-end, hop-
by-hop or anything in the
middle) are possible. Such an approach was discussed recently at
the CHANTS workshop and
IRTF DTNRG:
paper: http://doi.acm.org/10.1145/1162654.1162659
slides: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf
Such functionality should be worked on subsequent to the base spec.
My point isn't take the document should specify single-hop
reassembly. It's that, as written, it precludes single-hop
reassembly. If the spec were, for example, to say that the two
headers could be in either order, then there would be no problem. My
concern is that the document -- without any technical justification
for the decision -- is digging itself into a hole where producing
efficient (in terms of energy, RAM, and code space) implementations
will be difficult. It might be that a new mesh2 header emerges that
reverses the order, with the cost of a few extra bits in each packet.
That being said, there is the point to be made that large packets in
6lowpan are expected to be very rare and mostly present for complete
interoperability than for core use cases. So this might in the end be
entirely irrelevant. Given the lateness in the process and lack of
forward progress, having something is better than nothing. So I'll
shelve my concern and am happy to agree on the document.
I note that there is one remaining item which fell through the cracks:
we need to define the format of future dispatch headers. The length
of the
dispatch headers defined in the base spec is known, so protocol
parsing can
proceed. For future dispatch headers, we need to include a length
field in
a well-known place in the header, otherwise proper parsing is not
possible.
This needs to be in the base spec.
I had thought that the discussion went down the road of "if you don't
know the header type, drop the packet," keeping packet processing
simple.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
