SLRP Slave

The responsibilities of a SLRP slave are twofold. Firstly, it provides a basic routing service

which maps an ultimate destination host to the neighboring host which is the next hop. Secondly, the slave is required to participate in a dynamic network topology monitoring scheme so that changes to the network may be detected and accommodated.

To provide the routing service, a SLRP slave simply maintains a hash table mapping hosts to hosts such that the domain is the set of possible destinations in the network and the range is the set of possible next hops towards those destinations. This routing table is updated only by receiving a replacement from the master node. However, such an update must be accompanied by an identifying ``cookie'' integer which should only be known by the master and is assigned when the slave receives its first routing table. New routing tables without the proper cookie are simply ignored.

The dynamic topology monitoring scheme consists of having every node send a packet to each of its neighbors periodically. These packets invoke a PLAN service on the neighbors which essentially allows the originating node to check in as being alive. In turn, each slave maintains a liveness table of its neighbors which indicates how many reporting periods have elapsed since each neighbor last checked in.

When a neighbor fails to report for a fixed number of periods in a row, the node sends a packet to the master node (assuming the failed node is not itself the master) indicating that the neighbor has gone down. Such ``host down'' messages are routed to the master using the default SLRP routing. The master node will then presumably update the routing graph and send out new routing tables, as detailed in the following section.

If the master node is detected as down, the slave node goes into a failure state. Its actions are:

• Send a message to the master asking it if it is down. If the master responds, then normal processing resumes.
• If a response is not received within a certain period, the master is assumed down, and the node sends ``master down'' messages to all of its neighbors. A node that receives a ``master down'' message also enters the failure state.
• Finally, the node repeatedly sends requests to the master to add the node to the network. These requests are sent at a fixed interval, and for a fixed number of times. If the master comes up, the add request should be processed and the node is re-entered in the network. If the master never comes up, then the node halts.

Note here that because ``master down'' messages are always confirmed, a pathological node cannot halt the entire network by flooding it with ``master down'' messages. Also note that while a node is in a failure state, it maintains its current routing table rather than halting service altogether. Thus, nodes reachable through the master will be unavailable, while the remaining nodes can be contacted.