OCALA is implemented as a proxy that captures IP packets sent/received by legacy applications and relays them over the desired overlay network. This implementation currently works on Windows 2000/XP, Linux and Mac OS X, requiring no changes to the operating system.
Legacy applications identify overlay end-hosts using DNS-like names. These names usually consist of three parts: (1) the suffix which specifies the overlay type, (2) the middle part which identifies the overlay instance, and (3) the prefix which specifies the overlay-specific name. For example, foo.planetlab.i3, represents the host foo on the PlanetLab instance of i3 while bar.planetlab.ron represents the host bar running on the PlanetLab instance of RON. Provided with an overlay name ov_name.ov_inst.ov_type, the OC-I layer selects the OC-D module based on the overlay type (ov_type) and instance (ov_inst), and sends the overlay-specific name to (ov_name) to the OC-D module. The OC-D module resolves the overlay-specific name to an overlay identifier/address such as an i3 id. The OC-D layer can associate overlay-specific information to the overlay-specific name through a configuration file. For example, in an OverQoS overlay, we can use the configuration file to associate a target loss rate along the path to a given end-host.
1. Control Plane
The following figure illustrates the steps involved in establishing a new connection to an overlay host in OCALA.
Step 1 The legacy application issues a DNS request for foo.inst.ov, i.e., for host foo that resides on the instance inst of overlay ov.
Step 2 The OC-I layer captures this request and uses suffix inst.ov to identify the corresponding OC-D module. The OC-I layer then issues a tunnel setup request to the OC-D layer for the overlay-specific name, foo.
Step 3-4 The OC-D layer resolves foo to an overlay-specific identifier (IDB) using an overlay-specific resolution mechanism. For example, the i3 OC-D layer simply hashes the name to obtain the corresponding i3 id, while the RON OC-D uses DNS to resolve the name to an IP address.
Step 5 The OC-D layer initiates an overlay-specific protocol to set up a tunnel to the end-host identified by IDB. For example, in i3, setting up a tunnel involves negotiating and inserting a pair of private triggers by the two end-hosts. Similarly, in the case of HIP, setting up a tunnel involves authentication and establishing a secure channel between the two end-hosts.
Step 6 After setting up a tunnel, the OC-D layer returns a tunnel handle (tunnelAB) to the OC-I layer. This handle will be used by the OC-I layer to send packets via the tunnel.
Step 7-8 The OC-I layer now runs a path setup protocol. On successful completion, it returns a virtual (fake) IP address (IPAB) to the legacy application. This IP address belongs to an unallocated address space, e.g., 1.x.x.x. From the legacy application's point of view, this IP address represents the remote end point. From the OC-I layer's point of view, this IP address represents a handle to the state associated with the path to host B.
2. Data Plane
After the setup protocol described above is completed, the legacy application starts sending packets to the fake IP address returned in the DNS reply (IPAB). The following figure illustrates the data path operations.
Upon receiving a packet with destination IPAB, the OC-I layer on host A uses IPAB to identify the corresponding path (pathAB), and the tunnel to the next hop (tunnelAB). The OC-I layer adds the path identifier, pathAB to the packet header and sends the packet via tunnelAB.
On receiving the packet from the OC-I layer, the OC-D module at host A uses tunnel handle tunnelAB to retrieve the identifier of the destination, IDAB, and sends the packet over the overlay.
This packet is received by the corresponding OC-D layer at host B. The OC-D layer passes the packet to the OC-I layer. The OC-I layer uses the path identifier in the packet header to find the local handle (i.e., the IP fake address IPBA), strips off the OC-I header, and sends the packet to the legacy application at host B.