On the Design & Evolution of an Architecture for Testbed Federation

1. On the Design & Evolution of an Architecture for Testbed Federation Stephen Soltesz, David Eisenstat, Marc Fiuczynski, Larry Peterson

2. The Original Problem • Give User access to an Owner’s Nodes

3. princeton_codeen nyu_d cornell_beehive att_mcash cmu_esm harvard_ice hplabs_donutlab idsl_psepr irb_phi paris6_landmarks mit_dht mcgill_card huji_ender arizona_stork ucb_bamboo ucsd_share umd_scriptroute … Contribution of PLC Owners Users Princeton Berkeley Washington MIT Brown CMU NYU EPFL Harvard HP Labs Intel NEC Labs Purdue UCSD SICS Cambridge Cornell … Trusted Intermediary (PLC) N x N

4. 2 4 User PLC 1 3 Trust in PLC Owner 1) PLC expresses trust in a user by issuing it credentials to access a slice 2) Users trust PLC to create slices on their behalf and respect credentials 3) Owner trusts PLC to vet users and map network activity to right user 4) PLC trusts owner to keep nodes physically secure and running

5. Testbed 1 Testbed 2 Testbed 3 The New Problem Users Owners ? Users Owners ? Users Owners

6. Outline • Federation Design • Tension in a Central Implementation • Two Authorities • Federation between Authorities • Evolution during the last year • Delegation of Slice Creation • Federation With OneLab • How to address Scale and Isolation

7. princeton_codeen nyu_d cornell_beehive att_mcash cmu_esm harvard_ice hplabs_donutlab idsl_psepr irb_phi paris6_landmarks mit_dht mcgill_card huji_ender arizona_stork ucb_bamboo ucsd_share umd_scriptroute … PLC is Centralized Owners Users Princeton Berkeley Washington MIT Brown CMU NYU EPFL Harvard HP Labs Intel NEC Labs Purdue UCSD SICS Cambridge Cornell … Trusted Intermediary (PLC)

8. MA SA Two Authorities of PLC PLC • SA = Slice Authority • Represents Users • Names Slices • MA = Management Authority • Represents Owners • Creates Slices on Nodes User Owner

9. User User User User User User User Node User Node Node Node Node Node Node Node Node Node User MA SA Narrow Waist • The New Narrow Waist • SA exports Slices • MA exports Nodes • The Simplest form of Federation • Between Users and Node owners Slices Nodes

10. Federation with a Management Authority • SA users benefit, access to more nodes • MAs control policy on its nodes

11. Federation with a Slice Authority • MA has a single infrastructure • SAs represent different user groups • Shared namespace • Agreement between SA1 & SA2

12. Federation In Combination • Slice & Management Federation • This is the goal with Onelab

13. Outline • Federation Design • Tension in a Central Design • Two Authorities • Federation between Authorities • Evolution during the last year • Delegation of Slice Creation • Federation With OneLab • How to address Scale and Isolation

14. Delegation as a Slice User • PLC is default Slice Creation Service (SCS) • User A delegates Slice Creation • User B calls Node Manager to create slice • User B could be a Slice Authority

15. Federation with OneLab • PLC1 caches PLC2, and vice versa • Concerns • How to limit slices, or nodes? • Where to place policy? • How many peers can we maintain? • Who enforces namespaces?

16. MA SA 1 SA 2 Addressing Scale & Isolation • What if… • The SA exports one slice to the MA Node MA - Node Manager SA2_one SA1_foo SA1_bar SA2_one SA2_one_a SA2_one_b

17. Conclusion • PLC addresses disparate concerns • Pulls at the centralized implementation • Proposed a general approach • Decouples PLC design into MA & SA • Development efforts during the last year • Delegation and Federation

19. PLC Today

20. Recursive MA and SA User privilege from position in tree Any MA or SA may be autonomous PLC with MA and SA

23. User to VM • MA and SA cache Owner and User info • SA is an authority for Slice names • MA is an authority for Node software

24. PLC with State on Nodes • Node Owner Management • Hard state in a volatile environment • PLC state conflicts with Owner preference • Solve by central policy management

25. Four Scenarios |Users| >> Size(node) O(N2) O(N)