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. > >I did eventually realize that Carsten was describing >using datagram tags as labels. In more words: In route over the L2 source changes at each hop. The datagram tag is associated to the source MAC and only valid (and unique) for that source MAC. Upon a first fragment: ---------------------- Source IPv6 address = IP_A (maybe hops away) Destination IPv6 address = IP_B (maybe hops away) Source MAC = MAC_prv Datagram_tag= DT_prv - do a route lookup and get Next hop IPv6 to B = IP_nxt - do a ND resolution and get IP_nxt MAC = MAC_nxt Since it is a first fragment of a packet from that source MAC MAC_prv for that tag DT_prv: - clean up any leftover resource associated to the tupple (MAC_prv, DT_prv) - allocate a new label for that flow, DT_nxt, from a LRU pool or something. - allocate a Label swap structure for (MAC_prv, DT_prv) that contains (MAC_nxt, DT_nxt) - allocate a Label swap structure for (MAC_nxt, DT_nxt) that contains (MAC_prv, DT_prv) - swap the MAC info to "from me to MAC_nxt"; Swap the datagram_tag to DT_nxt; Forward. Upon next fragments (that are not first fragments) -------------------------------------------------- - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) - If not found drop fragment. (ICMP error back could be possible) - else swap mac and tag and forward, as before Upon fr-acks: ---------- - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) - If not found drop. - else swap mac and tag and forward, as before - if the bitmap is acks all (could change the draft to make it all ones) or errors (all zeroes) cleanup resource Add some aging stuff to clean up stale states and there you are :) >You could get end-to-end ACKs in this scheme by having >only the destination intiate ACKs and only the source >initiate retries. Intermediate nodes would only relay >fragments and ACKs. This would require an explicit >description of the process, rather than leaving it up >to implementors. Sure > > The label game is played by swapping the datagram_tag to > make a new locally significant one at each hop. > >This works only if all fragments take the same path. >Fragments that took different paths would arrive at >the destination with different datagram_tags and not >be associated with one another. On the other hand, >if you don't swap the datagram_tags you are vulnerable >to collisions. Agreed; They have to since the first fragment sets the path. The key consequence is that we cannot benefit from rerouting along a DAG. So we end up with the loss statistics of one link times the number of hops. IOW the fragment recovery is badly needed if we play this game. > I'm ready to accept such a violation considering the > penalty of reassembling at each hop :) > >I would prefer to have explicit labelling, both for >clarity and because it could be used for sequences of >short packets as well as for fragmented long packets. Makes sense. Ideally both would look and feel the same to the intermediate nodes. At the end of day the difference could be subtle, like a type or something. I'm also interested in cleanly removing the states when all done. It appears that with the local operation above any node can play the game or not without knowledge that the peers also do. In other words, we could reassemble along the way and only nodes that wish/know_how_to skip the process would do so. > 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 > >For a packet that doesn't fit evenly into N fragments you >could make the first fragment shorter and have all >subsequent fragments be of maximal size. > Neat. I also like the idea of enabling fragments not to be fragments but a series of packets. Cheers, Pascal > -Richard Kelsey _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
