Routing

This section discusses the capabilities of RELOAD’s routing layer and the protocol features used to implement the capabilities, and

provides a brief overview of how they are used. Appendix A discusses some alternative designs and the trade-offs that would be necessary to support them.

RELOAD’s routing provides the following capabilities:

Resource-based Routing: RELOAD supports routing messages based solely on the name of the resource. Such messages are delivered to a node that is responsible for that resource. Both structured and unstructured overlays are supported, so the route may not be deterministic for all Topology Plug-ins.

Node-based Routing: RELOAD supports routing messages to a specific node in the overlay.

Clients: RELOAD supports requests from and to clients that do not participate in overlay routing. The clients are located via either of the mechanisms described above.

NAT Traversal: RELOAD supports establishing and using connections between nodes separated by one or more NATs, including locating peers behind NATs for those overlays allowing/requiring it.

Low State: RELOAD’s routing algorithms do not require significant state (i.e., state linear or greater in the number of outstanding messages that have passed through it) to be stored on intermediate peers.

Routability in Unstable Topologies: Overlay topology changes constantly in an overlay of moderate size due to the failure of individual nodes and links in the system. RELOAD’s routing allows peers to reroute messages when a failure is detected, and replies can be returned to the requesting node as long as the peers that originally forwarded the successful request do not fail before the response is returned.

RELOAD’s routing utilizes three basic mechanisms:

Destination Lists: While, in principle, it is possible to just inject a message into the overlay with a single Node-ID as the destination, RELOAD provides a source-routing capability in the form of "Destination Lists". A Destination List provides a list of the nodes through which a message flows in order (i.e., it is loose source routed). The minimal Destination List contains just a single value.

Via Lists: In order to allow responses to follow the same path as requests, each message also contains a "Via List", which is appended to by each node a message traverses. This Via List can then be inverted and used as a Destination List for the response.

RouteQuery: The RouteQuery method allows a node to query a peer for the next hop it will use to route a message. This method is

useful for diagnostics and for iterative routing (see Section 6.4.2.4).

The basic routing mechanism that RELOAD uses is symmetric recursive.

We will first describe symmetric recursive routing and then discuss its advantages in terms of the requirements discussed above.

Symmetric recursive routing requires that a request message follow a path through the overlay to the destination: each peer forwards the message closer to its destination. The return path of the response goes through the same nodes as the request (though it may also go through some new intermediate nodes due to topology changes). Note that a failure on the reverse path caused by a topology change after the request was sent will be handled by the end-to-end retransmission of the response as described in Section 6.2.1. For example, the following figure shows a message following a route from A to Z through B and X:

A B X Z --->

Dest=Z

--->

Via=A Dest=Z

--->

Via=A,B Dest=Z Dest=X,B,A

Dest=B,A

Dest=A

Note that this figure does not indicate whether A is a client or peer. A forwards its request to B, and the response is returned to A in the same manner regardless of A’s role in the overlay.

This figure shows use of full Via Lists by intermediate peers B and X. However, if B and/or X are willing to store state, then they may elect to truncate the lists and save the truncated information

internally using the transaction ID as a key to allow it to be

transaction ID would be used to recover the truncated information and return the response message along the path from which the request arrived. This option requires a greater amount of state to be stored on intermediate peers, but saves a small amount of bandwidth and reduces the need for modifying the message en route. Selection of this mode of operation is a choice for the individual peer; the techniques are interoperable even on a single message. The figure below shows B using full Via Lists, but X truncating them to X1 and saving the state internally.

A B X Z --->

Dest=Z

--->

Via=A Dest=Z

--->

Via=X1 Dest=Z Dest=X,X1

Dest=B,A

Dest=A

As before, when B receives the message, B creates a Via List

consisting of [A]. However, instead of sending [A, B], X creates an opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B]) and then forwards to Z with only X1 as the Via List. When the response arrives at X, it maps X1 back to [A, B], then inverts it to produce the new Destination List [B, A], and finally routes it to B.

RELOAD also supports a basic iterative "routing" mode, in which the intermediate peers merely return a response indicating the next hop, but do not actually forward the message to that next hop themselves.

Iterative routing is implemented using the RouteQuery method (see Section 6.4.2.4), which requests this behavior. Note that iterative routing is selected only by the initiating node.