Download - CMUlab Spiral 2 Year-end Project Review
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