CMUlab Spiral 2 Year-end Project Review

1. CMUlab CMUlabSpiral 2 Year-end Project Review Carnegie Mellon University PI: Dave Andersen Staff: Pat GunnStudents: Aug 25, 2010

2. Project Summary:A Tale of Three Testbeds ProtoGENI HomeNet Residential Wireless Wireless Network Emulator Wired Emulab Cluster CMUlab Boss & Ops

3. Project Summary:A Picture is a Thousand Words CMUlab Boss/Ops Utah ProtoGENI VLAN GigE IP-IP GigE VLAN

4. Milestone & QSR Status CMUlab – Aug 25, 2010

5. Summary of Year 2 Accomplishments • Improved user experience, capacity, flexibility for our wireless testbed in the Emulab/ProtoGENI environment • Integration and automation of wireless testbed • Better support for private testbeds, hardware and software VPN automation • Switch-supported VLANs to build data plane over control network • Full OpenVPN/MetaVPN/ProtoGENI automation

6. Wireless Testbed • Added swapin/swapout event support • simplifies the user experience • eliminates problems caused by people making mistakes during their FPGA experiment • Prevents interference between experiments • Significant changes to our management code were needed set emucout [new Program $ns] $emucout set node “ops” $emucout set command “/usr/testbed/ectl out” $ns at swapout “$emucout start” set emucin [new Program $ns] $emucin set node “ops” $emucin set command “/usr/testbed/bin/ectl in” $ns at 0 “$emucin start”

7. A ProtoGeni View Equivalent to RSpec manifest Node Info Node Info Channel info Channel info Exp Control 3. Start emulator experiment Boss/Ops 2. Swap-in: Configure nodes Update database Transfer RSpecs Notify user 1. Experiment ProtoGeni interface

8. Switch-Supported VLANs • Our environment: standard emulabtestbed with dedicated experimental network and another same-site testbed on the same control network but with an FPGA for normal experimental use • How can we build a coherent data plane for experiments including both? • 802.1Q VLAN on control network • Switches do the heavy lifting • Caveat: may interfere with control plane if use is heavy enough • Requires some client-side changes, small configuration changes on switch

9. MetaVPN • MetaVPN allows private testbeds to federate with less hassle. We’ve seen interest in using our testbeds in conjunction with others (particularly Utah’s)

10. MetaVPN • Status: MetaVPN enables programmable OpenVPN usage in testbed • Includes key/config distribution system • Scriptable • Especially useful for private testbeds (where boss/ops are the only directly routable systems) • End goal: support requesting OpenVPNs in an Rspec • Requires some coordination between CMs, elections of coordinating nodes, small Rspec extensions • Will trailblaze future extensions requiring CM coordination

11. Issues • Instability caused by upgrades (and their impact on users) continues to be a concern • Improving this is fundamentally hard • Want to very carefully work out additional dependencies before release • Automating CMUlab-Emulator coordination was a year 1 milestone • Was thought to be a very simple task (< 1 month) but turned out to be a major effort (~4 months) – ripple effect on other tasks • Functionality is critical since other functions rely on it • Additional benefits of fully automating experiment execution – important in federated environments CMUlab – Aug 25, 2010

12. Plans • The CMU effort so far has focused on developing building blocks needed to federate testbed with specific characteristics • Behind NATs, single network interface (need to multiplex control/data), wireless, custom experimental control (emulator), … • The goal of year 3 should be to use these components to make federation a reality for this type of testbeds • Using Homenet and emulator testbeds to drive the development • Federated experiments should be possible for “normal” users, i.e. without knowledge of GENI internals • One user already did CMU-Utah federated experiment using CMU VPN infrastructure, but required some manual setup, hand holding CMUlab – Aug 25, 2010