Hi Richard: Upon the first fragment, the trick is to lay an label along the path followed by that fragment (that is IP routed), and all further fragments are label switched along that path. So alternate routes are not possible for fragments. The label game is played by swapping the datagram_tag to make a new locally significant one at each hop. I'm ready to accept such a violation considering the penalty of reassembling at each hop :)
The fragment recovery helps in a number of fashions: - it provides explicit signaling that the reception is complete and thus enables to clean up intermediate states. - it enables the source to swap a path by resending a first fragment that will take a new route - and then the obvious, recovery and flow control. Too bad ECN is gone for the time being. Cheers, Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Richard Kelsey >Sent: mardi 18 août 2009 17:02 >To: Richard Kelsey >Cc: [email protected]; [email protected] >Subject: Re: [6lowpan] making progress on fragmentation > >In responding to Carsten, I wrote: > > 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: > > [... store routing data from the initial fragment for use > in forwarding subsequent ones ...] > > The difficulty is that the various fragments may easily take > different paths through the mesh. Even if no route changes > occur, there may still be multiple paths. The current RPL > draft, for example, allows a router to maintain multiple > next hops for a given DAG root. A router that alternates > between two next hops for load balancing is going to be a > bit of a problem. > >Please ignore all that. I am clearly not skilled in >the art of layer violation and will need to think >about this some more. > -Richard Kelsey >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
