Hi:
I'm just back fro vacations so I jump in late in this discussion. We discussed this already in the "[6lowpan] Mesh-header, do we need it anymore?" thread. Please review what was discussed there. My understanding Is that today, we need to expand the packets at each L3 hop, which includes recomposing when there are fragments but is costly even when the packet is not fragmented. I'd wish to actually work on forwarding the compressed form when we can, fragmented or not. This is not possible today but could be done if we had a (compressed) routing header and/or could use 16bit addresses as labels. Pascal ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Hui Sent: mercredi 20 août 2008 17:02 To: Julien Abeille (jabeille) Cc: [email protected] Subject: Re: [6lowpan] fragmentation and HC2 Hi Julien, On Aug 19, 2008, at 12:57 AM, Julien Abeille (jabeille) wrote: However, reassembly at every hop in a route over topology is really bad. Is it? From a network-layer perspective, yes. But from a whole system perspective, it is much less clear. Sending fragments for a datagram along a single path can be advantageous for many reasons. There are a number of dynamic link-layer optimizations that reduce transmit costs, increase throughput, and decrease latency, but, those mechanisms often assume that they can amortize the initial setup costs over multiple subsequent frames. You get to take advantage of the temporal properties of a link. It is feasible to perform hop-by-hop fragment recovery. Fragments arrive in order, making reassembly simpler at the receiver. We should think about a solution to the issue, or at least document it somewhere if we cannot find a way around it. Agreed. -- Jonathan Hui Best, Julien ________________________________ From: Jonathan Hui [mailto:[EMAIL PROTECTED] Sent: lundi 18 août 2008 21:38 To: Jean Philippe Vasseur (jvasseur) Cc: Julien Abeille (jabeille); [email protected] Subject: Re: [6lowpan] fragmentation and HC2 Hi JP, I don't think your statement is entirely true. L3 forwarding at each radio hop only requires fragmentation/reassembly at each radio hop. I guess you could argue this is 1-hop mesh under (subsequent fragments know the next-hop destination based on forwarding information from the first fragment), but if you're doing L2 fragmentation, I don't see any way around it. Maybe I'm not understanding your model, so let me try to reiterate it and you can tell me where I'm wrong - you have datagrams fragmented at L2 and you want to forward those fragments at L2 using L3 information. That model seems a bit strange to me and I'm not sure how it would work if you have an IPv6 HBH Options header to process. It would seem cleaner just to say that we're fragmenting at L3. At that point I'd rather just stick a fragmentation header after the L3 addressing information, but then that's starting to look awfully like an IPv6 + fragment header. I know you're trying to find a middle ground so that we can forward fragments using L3 information so that we can avoid hop-by-hop fragmentation/reassembly and not violate the IPv6 min MTU requirement. I'd like to see that too. Is it okay to say that, yes, we are doing L3 fragmentation but that those fragments must be reassembled before exiting the 6lowpan network? -- Jonathan Hui On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote: Hi, On 8/18/08 7:45 PM, "Jonathan Hui" <[EMAIL PROTECTED]> wrote: There are multiple implementations (route-over and mesh-under) that successfully utilize the current format today. If you want addressing information in each L2 fragment, then forward at L2. If you want to forward everything at L3, then fragment hop-by-hop. L3 routing is agnostic to the specific layer that forwarding occurs. JP> this was not Julien's point: depending on how you fragment you may or you may not (in this case) be able to route at each hop of course. Without addressing info in each fragment, this implies L2 forwarding and thus a mesh-under solution. Thanks. JP. -- Jonathan Hui On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote: Which requires a mesh under solution and does not work with route over .... Thanks. JP. On 8/11/08 6:39 PM, "Jonathan Hui" <[EMAIL PROTECTED]> wrote: On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote: Does fragment 2 look like: FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed source and dest UDP port | UDP checksum | rest of UDP payload or FRAGN dispatch, datagram size, tag and offset | HC1 dispatch | HC1 encoding =0x FA | IPv6 hop limit | rest of UDP payload Neither. Everything after the frag header is considered part of the fragmented payload. -- Jonathan Hui ________________________________ _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
