The SLRP master node manages the entire PLAN network. When a new slave is added or a current slave is removed, the master is responsible for determining a routing graph and updating all of the slaves' routing tables accordingly. The master creates and distributes special ``cookies'' (random integers) to add a small amount of security to this process.
Slave nodes join the network by sending a request message to the master which indicates their (desired) interfaces; throughout operation, the master maintains a list of each node's interfaces. The process of creating a routing graph simply involves constructing a graph whose edges are the indicated interfaces, and then removed edges that create cycles. New edges are then added to connect the trees thus produced, resulting in a spanning tree of the network. These new edges have the result of extending the interfaces of the requestor (this is explained in more detail below).
When a new node is added, the master computes a new cookie and delivers it to the node. This cookie is used for identification purposes in a number of SLRP messages. In the period of time between the node's request and the arrival of the cookie, the node could be susceptible to having someone else provide a cookie, but since the node has not yet been added to the PLAN network, this subversion must come from a layer outside of the PLAN domain.
Once the graph is computed, the master can determine the routing tables for each of the slaves. A PLAN packet is sent directly to each slave (and not through the imposed SLRP topology) via UDP containing the new routing table and the identifying cookie. This direct administrative connection is used both for its simplicity and for reaching nodes which were disconnected by some other node's failure. Similarly, when a node is reported down, the master removes all stored information involving that node, as well as its cookie, and then updates the network.
All routing in the SLRP network occurs along the spanning tree, so even
though node m might have indicated that node n is an interface, traffic
between them may have to flow through one or more intermediate nodes. This
was done initially to simplify network rearrangement. Since the PLAN network
uses UDP/IP to simulate link-layer connections
, there is no
straightforward relation between nodes' actual physical locations and
connectivity and the resulting PLAN network topology, thus allowing SLRP to
extend a node's interfaces, as mentioned. More on this issue will be
addressed further in Section 5.
SLRP also makes use of default routing, such that a message destined for a node not present in domain of the routing table is directed toward the master. This is to enable communication between different PLAN networks. When such a message reaches the master, it has the option of using some other routing protocol to deliver the message to another PLAN network. The current PLAN implementation uses ANON (Active Network Overlay Network) [1] for this purpose. If ANON, or some other scheme, is not known to the master when the message arrives, it is simply dropped.
Finally, as noted in the previous section, the master node may be sent messages from slaves to query whether it is alive, or to indicate that another node is down. The master responds iff it has a record of the slave in its topology. If it has no record, then this most likely means that the master has gone down and come back up (minus its old routing table). By not responding to the message, the master forces the slave to eventually send an add request to the master so that it may be gracefully re-entered into the network.