#49 prevent routing loops

[Scott Burleigh]

1. "imc" BP multicast relies on management of a spanning tree that (a) is an overly on the network and (b) is overlaid by the individual distribution trees for any number of BP multicast groups. Because the network may be characterized by transient partitions, it is possible that the spanning tree may be partitioned into two or more disconnected subtrees at times. The tree management protocol will reconnect the subtrees eventually. However, because signal propagation delays in the network may be long, it's possible that the subtrees would be reconnected at two different points (i.e., would temporarily NOT form a spanning tree) pending resolution by the management protocol. In this event, the forwarding of multicast bundles could potentially arrive at the same point from two different directions, resulting in a routing loop. To prevent this, the time a which a node most recently joined the network's spanning tree (as identified by the prevailing root node ID) must be recorded. When a node receives a multicast bundle whose creation time precedes the time at which the node most recently joined the spanning tree, the node must simply discard the bundle: functionally, it was not part of the destination multicast group at the time the bundle was multicast.
2. Routing loops must be avoided in "critical" bundle forwarding as well. To achieve this, we can simply leverage the imc spanning tree: critical bundles may only be forwarded to topologically adjacent nodes that are among its "relatives" in the spanning tree.

[Scott Burleigh]

Definitely worth doing, but there's no time to implement it before the (accelerated) 3.5.0 release. Slipping it into 3.5.1.

[Scott Burleigh]

Still a really good idea, but no time to get it into version 3.6.0; slipping to 3.6.1.

[Scott Burleigh]

Still a cool idea, but no time to implement before the 3.6.2 release. Slipping to 3.6.3.

[Scott Burleigh]

The original requirement here is overtaken by events: the new CGR-based multicast obviates the problem, since there is no spanning tree to manage.

But what this exposes is the desirability of using a concept similar to CGR multicast to prevent routing loops in critical bundle forwarding . It is not yet clear how to do this, so I'm slipping this feature into version 3.7.1.

[Scott Burleigh]

CGR-based multicast obviates the need for a spanning tree, so this feature request becomes moot.