X-Bone Architecture

The X-Bone is a system for the automated deployment, management, coodination, and monitoring of IP overlay networks. Its core is composed of Overlay Managers (OM) which deploy and coordinate the overlay itself, and Resource Daemons (RD), which coordinate the resources of individual network components. It also includes support for a graphical user interface (GUI) and a more direct API (shown in the figure below)

The GUI/API requests the overlay, and monitors its progress. The OM advertizes an invitation to create a new overlay, then configures the components, and monitors the result. The Resource Daemon coordinates resource use on the individual components, and translates generic configuration into machine-specific form.

TCP/SSL is used for secure configuration to take advantage of TCP's reliable channel, and reduce the number of different security schemes required in X-Bone [14]. X-Bone uses a web-based GUI for user request of an overlay deployment. Web browsers already support SSL, so the user's request is secure on the path to the OM. For simplicity, we use the same mechanism between the OMs and RDs. Alternate schemes, such as PGP, would require multiple mechanisms within the OM, and different protocols between different pairs of components.

This architecture utilizes a single, well-known multicast channel for invitation announcements, and separate reliable channels for configuration and monitoring. It is based on the multicast announcements in M-Bone teleconferencing; in fact, X-Bone effects an overlay as if it were a teleconference among its OM and the RDs of its router and host components.

Overlay Managers

Overlay managers (OMs) deploy overlays. A user creates an overlay deployment by sending a high-level request to an OM, either via a web-based GUI or by running a program that emits the request to the OM’s API. Each overlay is coordinated by a single OM; large overlays are created by divide-and-conquer, where a single OM forks sub-overlay requests to other OMs. Fault tolerance is achieved by replicating overlay coordination state in multiple backup OMs.

Figure 1. Resource discovery using increasing-TTL multicast invitations

An OM creates an overlay in phases, using multicast to discover available resources and TCP/SSL to configure and monitor those resources [14]. The overlay request is translated to an invitation, and the invitation is multicast using UDP. An invitation indicates the user requesting the overlay and a set of simple conditions, such as a specific operating system, bandwidth requirements, etc. Invitations currently fit in a single UDP packet; where larger messages are required, multiple copies of each component packet can be emitted and cached for reassembly. Invitations are repeated with increasing TTLs until a sufficient number of invitees respond, or until a preset search limit is exceeded: i.e., an expanding ring search [17].

Resource Daemons

Resource daemons (RDs) are daemons that configure and monitor the resources of routers and hosts. The RDs listen for multicast invitations, and respond when their available resources and permissions match the incoming request. Responses are in the form of TCP/SSL (X.509 encrypted) connections back to the source OM, where each RD indicates its particular capabilities. The OM selects from among the responding RDs, and picks an appropriate subset. Once the set of RDs is selected, the OM determines configuration information, such as tunnel endpoint addresses, routing table entries, etc., and sends specific configuration information to each RD. Once an overlay is thus deployed, the TCP/SSL connections are released and the overlay is up. Subsequent overlay actions are initiated by the OM, such as keep-alive pings, liveness and status requests, and modifying or dismantling configurations.

Figure 2. Responding to invites, selecting, and configuring the overlay.

The OM emits heartbeat pings to refresh the state of the RD components. When a RD no longer hears from an OM, all overlays of that OM are released from the RD state. Both RD and OM state are kept on disk, and reloaded after reboots or restarts.

X-Bone Protocols

The X-Bone protocols include the following:

X-Bone API

X-Bone CTL

X-Bone API

The XBone API protocol allows a user process or graphical interface to request the deployment of an IP overlay, and to monitor that overlay once deployed. It is used for messages between the user interface or an external program and an Overlay Manager.
Initially, the API requests that an overlay be created, and is returned the result of that action. Subsequent request/response explicitly monitor the depoyed overlay. Alarm messages act as alarms from the overlay to the user side of the API, to indicate an urgent change of status.

This protocol typically uses unicast UDP and TCP, though there are plans for multicast UDP for monitoring.

X-Bone Control

The X-Bone Control protocol is used for exchanges between the Overlay Manager and the Resource Daemons. This protocol operates in several phases: