Hi Carsten You right. But please also include mesh under in your reasoning; I initially crafted this work in the light of the work at ISA100.11a, that is mesh under and thus needs end to end recovery.
Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Carsten Bormann >Sent: mardi 18 août 2009 15:54 >To: Richard Kelsey >Cc: [email protected] >Subject: Re: [6lowpan] making progress on fragmentation > >> (Sending fragments multiple hops in a route-over network >> will require some kind of label switching. That will need >> to be discussed over in ROLL.) > >To document what everyone has been saying on the hallway: > >If you think strictly in layers, you have to reassemble the packet on >each L2/L3 boundary, and then re-fragment on each L3/L2 boundary. >However, the following optimization is obvious to anyone skilled in >the art of layer violation: > >1) Upon receiving an initial fragment for a tuple (SA, DA, datagram >size, datagram tag), if there is no reassembly buffer, do not create >an actual full reassembly buffer, but just a rump data structure that >records the IP addresses in that first fragment as well as the >coverage of the packet space by actual data forwarded. Forward (or >deliver locally) the fragment based on the IP addresses. >2) Upon receiving a non-initial fragment, if there already is a rump >reassembly buffer for the tuple, forward based on that, and record >coverage. Otherwise, create a full reassembly buffer with the data >received -- it might be for you! >3) Upon receiving an initial fragment for a tuple that has a full >reassembly buffer, (if not for local delivery) forward the initial >fragment, record the IP addresses (and the coverage). Then pump out >the data in the reassembly buffer as bandwidth permits. > >Each time a (full or rump) reassembly buffer gets full coverage, drop >it (or keep it some short additional amount of time to account for >late-coming duplicates). > >Of course, the uncertainty when to drop reassembly buffers remains, >but at least you don't have to keep the actual data (as soon as you >have the initial fragment). The way the (lack of) information works >resequences on every hop, so the likelihood of initial fragments >missing is limited. > >What we didn't provide in 4944 was a way to indicate "It's for you" in >each fragment. The last-hop sender may not always know, but when it >does, having that information might help with buffer management. > >Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
