Hello Michel I published a 04 addressing your comments. Please let us know if you find more improvements to be made on the draft.
A new version of I-D, draft-thubert-6lo-forwarding-fragments-04.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository. Name: draft-thubert-6lo-forwarding-fragments Revision: 04 Title: LLN Fragment Forwarding and Recovery Document date: 2017-01-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-04.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments/ Htmlized: https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-04 Abstract: In order to be routed, a fragmented 6LoWPAN packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints Happy new year! Pascal From: 6lo [mailto:[email protected]] On Behalf Of Pascal Thubert (pthubert) Sent: vendredi 23 décembre 2016 19:34 To: Michel Veillette <[email protected]>; [email protected] Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Thanks a bunch for your review, Michel! I'll update the doc accordingly early next year. The fragmentation and the forwarding of fragments are finally getting a hot topic, and was discussed at the last 6TiSCH interim. I'll probably present on the draft and the rationale behind some of the technical choices therein at the next interim on Jan 6th, 7AM pacific, if you can attend? Take care, Pascal From: 6lo [mailto:[email protected]] On Behalf Of Michel Veillette Sent: jeudi 22 décembre 2016 18:21 To: [email protected]<mailto:[email protected]> Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fragments] is very appreciated. This draft addresses multiple issues associated to the transfer of large payloads. - Minimize frame overhead. - Increase efficiency and reduce latency compared to a reassembly at each router. - Complementary to the concept of TSCH tracks. - Guaranty a fix routing during the transfer which often result in a more deterministic performance. The following properties defined in this draft are important to us and need to be preserved. - End to end transfer of 6lo fragment without reassembly at each router - Optional use of acknowledgment and retries - Support of multiple fragments in transit - Label based routing These are my comments on the current version. 1) datagram tag I recommend that you globally replace "datagram tag" with a space by "datagram_tag" with an underscore to clearly indicate that you refer to the field within RFRAG. 2) Typo Section 8.1, second line, replace "adnd" by "and" 3) Reference to ND In section 8.1, I recommend that you remove the reference to ND in "a ND resolution to get the MAC address associated to IP_nxt". Some stacks don't use ND to perform this function. 4) label routing Is it possible to extend the concept of label based routing to subsequent IP packets part of the same flow in both directions (upstream and downstream)? The issue I want to resolve is the following. In an RPL non storing mode network, the 6LBR can create an alternate source route to go around a non functional router. This approach forces a route downstream, but not upstream unless the source route is replayed on the reverse direction. Can we define a new field (label), distinct from the datagram_tag, with a lifespan longer than a single IP packet transfer and used to perform this label based routing? Any suggestions to resolve this issue is appreciated. Regards, [cid:[email protected]] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
