SCAFFOLD Project Status Report

Period: Jan-Mar 2011

I. Major accomplishments

1. Redesigned our architecture to work on top of IP. New architecture name: Serval (Service Access Layer)
2. Started on a second prototype reflecting changes in our design and to remove third-party software dependencies
3. Demonstrated new stack on Android phones with ad-hoc (infrastructure-less) service discovery

A. Milestones achieved

Achieved all the milestones on time

1. Demoed new Serval stack on Android phones at GEC10 (see poster)
2. Plan for initial deployment on GENI resources (using VICCI). VICCI cluster up and running with special SCAFFOLD slice for running our new network stack.

B. Deliverables made

Delivered the source code for Serval stack with datagram support.

II. Description of work performed during last quarter

A. Activities and findings

The main activity in this quarter was centered around redesigning the SCAFFOLD architecture to run on top of IP rather than using its own network layer. This redesign came about for two main reasons: deployability and third-party software dependencies. Obviously, designing a new network layer (as our initial SCAFFOLD proposal aimed to) comes at great costs in terms of deployment. Although a "clean-slate" design gives great opportunities for innovation, every router in the network needs to be updated. Our approach around this problem was to leverage the proliferation of programmable OpenFlow-based networks and routers. However, despite allowing great flexibility in the control plane, OpenFlow did not give us the flexibility needed in the data plane (e.g., to match on new network layer headers), and updates to the OpenFlow specification that would address these shortcomings were slow to reach actual hardware. The limitations of the OpenFlow platform therefore forced us to make our own modifications to the OpenVSwitch software router, while still not addressing the significant trade-offs we had to make in our stack implementation (e.g., we had to rely on repurposed IPv4 headers for our network layer format, and this simply didn't give us enough bits for our needs). This gave us the worst of two worlds: a significant deployment hurdle, and a dependency on third-party software that was slow to update. After having re-assessed our situation and architecture design, we came to realize that we could meet most of the goals setup for our architecture while retaining IP compatibility. Some loss of functionality (e.g., network-layer anycast service resolution) could be regained by alternative mechanism in a layer 3.5, sitting in-between the network and transport layers. Our new architecture, Serval (for Service Access Layer), retains the basic principles initially set out for SCAFFOLD, while running on top of IP and without the need for third-party software or a particular network router configuration. Serval puts greater emphasis on multiplicity than our initial design; we aim to make use of a multiplicity of service instances, network interfaces (multi-homing) and network paths (multi-path).

We have successfully completed an initial design of our new Serval architecture. The new stack implementation was demoed at GEC10, running on Android phones.

B. Project participants

1. The PI (Mike Freedman) and the co-PI (Jen Rexford) led the redesign of the architecture and its protocols.
2. A postdoc (Erik Nordstrom) designed and implemented the the new stack and demo.
3. A Master's student (Matvey Arye) verified Serval protocols.
4. A Ph.D. student (Dave Shue) designed and implemented a new service router for service resolution.
5. A Ph.D. student (Prem Gopalan) participated in both the design and implementation of Serval.

C. Publications (individual and organizational)

Technical report pending.

D. Outreach activities

Ongoing discussions with companies on how Serval can be of used in their organizations (e.g., Qualcomm, Cisco, Yahoo!).

E. Collaborations

F. Other Contributions