Version 1 (modified by Vic Thomas, 12 years ago) (diff)


SCAFFOLD Project Status Report

Period: Jan-Mar 2010

I. Major accomplishments

  1. Completed the first prototype including the network protocol and the end-host stack
  2. Ported a few applications (iperf, TFTP, and PowerDNS)
  3. Demonstrated migration and failover functionalities of the prototype

A. Milestones achieved

Achieved all the milestones on time

  1. Implemented the NOX-based rendezvous server and the end-host stack
  2. Demoed a multi-server multi-switch SCAFFOLD network within the same L2 domain

B. Deliverables made

Delivered the source code for SCAFFOLD datagram socket API

II. Description of work performed during last quarter

A. Activities and findings

The main activity in this quarter was centered around designing and implementing the SCAFFOLD protocol in the local area network. This can be roughly divided into two parts.

  1. End-host stack: We have redesigned the end-host socket API in order to support objectID-based naming. The socket API is largely similar to the current BSD socket API to provide a familiar interface to programmers as well as for better portability of legacy applications. We've considered various implementation options. The options were kernel-level implementation, user-level implementation with Ethernet aliases, and user-level implementation with Click. We have chosen the user-level implementation with Click to enable rapid prototyping and easier maintenance. We were initially concerned about Click because it was designed as a router framework. However, it turned out that Click was flexible enough to implement a new end-host network stack. The current implementation only support UDP-style datagrams. Migration and failover support is done entirely by the end-host stack by sending special messages indicating the intent of migration or failover. We've discussed an alternative approach, where the network inserts temporary rules for migration and failover. However, we've dismissed this approach in order to keep the network stateless as much as possible.
  1. The SCAFFOLD network: We implemented our SCAFFOLD network protocol using NOX and OpenFlow switches. As the current OpenFlow specification only supports IPv4, we have repurposed the IP header for the SCAFFOLD header. The SCAFFOLD network implementation includes host-network communication API for object and host management, object router implementation for objectID resolution, and label router implementation for forwarding. We've been using Open vSwitch, which is an OpenFlow switch implementation. We run an unmodified version of Open vSwitch for the label router. However, we have modified Open vSwitch for object routers for round-robin object resolution. These routers are controlled by NOX, an OpenFlow controller. We have extended NOX to implement our host-network communication API. Our current prototype assumes that all hosts and routers are placed within the same L2 network.

B. Project participants

  1. The PI (Mike Freedman) and the co-PI (Jen Rexford) designed the protocols, led design meetings with other participants, and finalized the overall design.
  2. A postdoc (Steve Ko) implemented the protocol for migration and failover.
  3. A Ph.D. student (Dave Shue) implemented the SCAFFOLD network elements.
  4. A Ph.D. student (Prem Gopalan) implemented the end-host stack.

C. Publications (individual and organizational)

D. Outreach activities

E. Collaborations

Discussions with Stanford University about OpenFlow v2 specification, as well as Nicira Networks given our use of NOX and Open VSwitch, both developed by them.

F. Other Contributions