OCALA

From RAD Lab

Jump to: navigation, search

Contents

OCALA: An Architecture for Supporting Legacy Applications over Overlays

Students

  • D. Joseph
  • J. Kannan
  • A. Kubota
  • K. Lakshminarayanan

Faculty

  • I. Stoica
  • K. Wehrle

Summary

The Internet works well. The Internet does not work well. To tackle the scenarios where the Internet does not work well, many new network architectures have been proposed. Given the impossibility of modifying routers today, overlay networks are used to implement such architectures in the hope of gaining a large user base. Despite sustained efforts to test and deploy new network architectures, few of these efforts have attracted a significant number of users. We believe that chances of user acceptance of overlays, and eventually new network architectures, will be substantially improved by enabling users to leverage their functionality without any modifications to their applications and operating systems.

We have designed and implemented OCALA, an Overlay Convergence Architecture for Legacy Applications, that enables existing applications (eg: Firefox, IE, ssh) to leverage the functionality provided by new network architectures. OCALA re-factors the protocol stack by imposing an Overlay Convergence (OC) layer below the transport layer in the IP stack. The OC layer is decomposed into the overlay-independent (OC-I) sub-layer, which interacts with the legacy applications by presenting an IP-like interface, and the overlay-dependent (OC-D) sub-layer, which tunnels the traffic of applications over overlays. OCALA differs from existing solutions in that it enables (1) applications running on the same machine to access different overlays simultaneously, (2) stitching of multiple overlays so that users residing in different overlays can communicate with each other, (3) hosts to communicate through an overlay even if the other end-point understands only IP, and (4) extensibility so that a new overlay can be incorporated into OCALA with minimal effort.

We envision the following usage scenario for OCALA. Researchers who develop new network architectures, write an OCALA plugin for their architecture. The functionality of the new architecture is advertised to real users via an Internet Architecture Plugins webpage. Users download the OCALA plugins of the network architectures they wish to take advantage of. A graphical user interface allows the user to select the connections that will use the new network architecture. For example, the user can specify that all ssh connections should use RON (Resilient Overlay Networks) for increased robustness. The same user, while accessing ssh over an unsecure wireless connection at a cafe, can use the indirection feature of i3 (Internet Indirection Infrastructure) to force all packets to go through his company's firewall. Users can use a publicly available OCALA gateway service to stitch together the functionality offered by different overlays and to communicate across multiple overlays. For example, a user on the move can use i3 on the first hop to the OCALA gateway and then RON to the final destination. In this way, the user obtains the mobility benefit of i3 on the first hop and the robustness of RON on the second hop.

We currently support two overlays - i3 and RON. OCALA plugins for HIP (Host Identity Protocol, Helsinki Institute for Information Technology), DOA (Delegation Oriented Architecture, MIT) and OverDoSe DDoS prevention overlay (CMU) have been developed by the respective research groups. More details about the design of OCALA and our implementation (Linux and Windows) are available at http://ocala.cs.berkeley.edu.

Personal tools