Hello Ralph: A label switching technique to properly forward fragments to destination at L3 without recomposing the full packet at each hop is discussed in https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments . Arguably, the technique that is proposed there could work with RFC 4944 datagram tags as well, and as Carsten says, that can be done by any 6LoPWAN node in the path independently of what other nodes do.
And IMHO keeping it at that and washing our hands would be incredibly short-sighted in the light of the other problems that we face with 6LoWPAN fragments as they exist today. Examples of such problems are handling of fragment loss and lack of capability to abort a transmission and clean up state in the network, but there's more, like handling of congestion in the mesh network and so on. I presented the issues I'm aware of at 6lo at IETF 98, and hopefully the slides are self-explanatory enough so that people who did not follow the presentation can still derive enough information to make their own mind: https://www.ietf.org/proceedings/98/slides/slides-98-6lo-fragmentation-forwarding-issues-in-6lowpan-00.pdf IEEE 802.5.4 understood and started addressing those issues in their protocols years ago, consider for instance how this is done at PHY layer in 802.15.4K LECIM - LP-WAN (cc'ing Pat). In the light of that art, the legacy 6LoWPAN technique is shamefully inadequate. My suggestion to the group is to take a holistic view of these issues, and redesign or fragment support. This is what my draft does. Else we'd better be very clear to the world that our fragment support is only for the show, and that any link layer that expects a working IPv6 (leveraging 6LoWPAN) over it should have its own well-designed support for large frames and present MTU of 1280 or above to the upper layer. The IEEE appears to be taking that path anyway, generalizing MTUs of 2048. Take care, Pascal -----Original Message----- From: 6lo [mailto:[email protected]] On Behalf Of Ralph Droms Sent: mercredi 5 avril 2017 19:21 To: Carsten Bormann <[email protected]> Cc: [email protected]; Thomas Watteyne <[email protected]>; [email protected] Subject: Re: [6lo] [6tisch] Thomas' review of draft-thubert-6lo-forwarding-fragments-04 Carsten... > On Apr 5, 2017, at 11:55 AM, Carsten Bormann <[email protected]> wrote: > > >> The major rationale IMO for this draft is that it doesn't require >> intermediary nodes to reassemble! > > As I said in the WG meeting (and pointed out in the 6LoWPAN book), this has > not really been necessary even in the original 6LoWPAN. However, to make > “virtual reassembly buffers” work in multi-track environments, the first > fragment (which provides the routing info) has to be sent on all tracks. I think I understand the technique you are describing. Is there a written guideline or specification for the technique somewhere? I don't recognize the term "multi-track environment". Can you define it for me? > >> The label switching mechanism is elegant as the labels are locally >> significant only, with no need to maintain a network-wide label registry. >> The document should state so. > > Yes, that is the idea behind datagram tags in RFC 4944 — they are local to > the hop. Viewing the set of “virtual reassembly buffers” as a label > switching table is certainly one way to describe it. Still, this is an > implementation technique for RFC 4944 6LoWPAN fragmentation, not a new > protocol. In particular, I think I can infer how datagram tags would be used in a hop-scoped way with virtual reassembly buffers. It would be good to have text to work through the details. - Ralph > > Grüße, Carsten > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
