Hi Jonathan, JP, from a layer perspective, I agree it makes sense in a route over topology to reassemble at every hop. It also makes sense to use the same L3 next hop for all fragments, as IP layer will select the next hop, then ask 6lowpan layer to send, and 6lowpan layer only knows wether fragmentation is needed, and even that fragmentation exists. However, reassembly at every hop in a route over topology is really bad. We should think about a solution to the issue, or at least document it somewhere if we cannot find a way around it. 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
