Sponsored by the National Science Foundation

CMUlabSpiral 2 Year-end Project Review

Carnegie Mellon UniversityPI: Dave Andersen

Staff: Pat GunnStudents:

Aug 25, 2010

CMUlab

Sponsored by the National Science Foundation 2

Project Summary:A Tale of Three Testbeds

HomeNet Residential Wireless

ProtoGENI

Wireless Network Emulator Wired Emulab Cluster

CMUlabBoss& Ops

Sponsored by the National Science Foundation 3

Project Summary:A Picture is a Thousand Words

GigE

IP-IP

VLAN

GigE

CMUlabBoss/Ops

UtahProtoGENI

VLAN

Sponsored by the National Science Foundation 4

Milestone & QSR StatusID Milestone Status On

Time?On

Wiki?GPO

signoff?

Automate CMUlab-emulator coordination on swap in/out

Completed and extensions committed to ProtoGeni

Yes Yes

VLAN-based control and data plane over Ethernet

Implementation completed and final testing for robustness in progress

No

Automate VPN management and broading VPN use for experiments

Completed and committed into ProtoGeni Yes Yes

Expand Homenet Deployment Resolved IRB issues, identified apartment building, deployment scheduled for late August

No

Protogeni access to wireless testbed Defined Rspecs for channels and using Rspec for CMUlab-emulator coordination

Yes No No

Better support for testing and upgrades To be done

CMUlab – Aug 25, 2010

Sponsored by the National Science Foundation 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

Sponsored by the National Science Foundation 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”

Sponsored by the National Science Foundation 7

A ProtoGeni View

7

Boss/Ops

1. ExperimentProtoGeni interface

Exp Control

3. Start emulatorexperiment

2. Swap-in:Configure nodesUpdate databaseTransfer RSpecsNotify user

Node Info

Channel info

Node Info

Channel info

Equivalent to RSpec manifest

Sponsored by the National Science Foundation 8

Switch-Supported VLANs

• Our environment: standard emulab testbed 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

Sponsored by the National Science Foundation 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)

Sponsored by the National Science Foundation 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

Sponsored by the National Science Foundation 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

Sponsored by the National Science Foundation 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