Changes between Initial Version and Version 1 of SCAFFOLD-qsr-1Q2010

05/12/10 13:58:45 (12 years ago)
Vic Thomas



  • SCAFFOLD-qsr-1Q2010

    v1 v1  
     3= SCAFFOLD Project Status Report =
     5Period: Jan-Mar 2010
     7== I. Major accomplishments ==
     9 1. Completed the first prototype including the network protocol and the end-host stack
     10 2. Ported a few applications (iperf, TFTP, and PowerDNS)
     11 3. Demonstrated migration and failover functionalities of the prototype
     13=== A. Milestones achieved ===
     15Achieved all the milestones on time
     16 1. Implemented the NOX-based rendezvous server and the end-host stack
     17 2. Demoed a multi-server multi-switch SCAFFOLD network within the same L2 domain
     20=== B. Deliverables made ===
     21Delivered the source code for SCAFFOLD datagram socket API
     23== II. Description of work performed during last quarter ==
     25=== A. Activities and findings ===
     27The main activity in this quarter was centered around designing and
     28implementing the SCAFFOLD protocol in the local area network. This can
     29be roughly divided into two parts.
     30  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.
     32  2. 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.
     34=== B. Project participants ===
     35 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.
     36 2. A postdoc (Steve Ko) implemented the protocol for migration and failover.
     37 3. A Ph.D. student (Dave Shue) implemented the SCAFFOLD network elements.
     38 4. A Ph.D. student (Prem Gopalan) implemented the end-host stack.
     41=== C. Publications (individual and organizational) ===
     43=== D. Outreach activities ===
     45=== E. Collaborations ===
     46Discussions with Stanford University about OpenFlow v2 specification, as well as Nicira Networks given our use of NOX and Open VSwitch, both developed by them.
     48=== F. Other Contributions ===