Sounds good. By the way, Phil, I thought you meant changing the fragmentation/reassembly algorithm outright, it was not clear to me that you just wished to relax the order of the headers.
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. This concern (and perhaps the one related to extension dispatch headers as well) could be mentioned in 1.d or in 1.k ("working group summary") in the Doc-Writeup. -gabriel ----- Original Message ---- From: Schumacher Christian Peter Pii <[EMAIL PROTECTED]> To: Philip Levis <[EMAIL PROTECTED]>; gabriel montenegro <[EMAIL PROTECTED]>; [EMAIL PROTECTED]; Geoff Mulligan <[EMAIL PROTECTED]> Cc: [email protected] Sent: Sunday, January 7, 2007 2:52:15 AM Subject: SV: [6lowpan] WG last call on Format document SV: [6lowpan] WG last call on Format document Given the feedback, I believe the chairs can submit the documents for IESG review. Regards Christian -----Oprindelig meddelelse----- Fra: Philip Levis [mailto:[EMAIL PROTECTED] Sendt: lø 1/6/2007 10:17 Til: gabriel montenegro Cc: Schumacher Christian Peter Pii; [email protected] Emne: Re: [6lowpan] WG last call on Format document 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
