(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
