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

2/17 The Original Problem Give User access to an Owner’s Nodes

3/17 Contribution of PLC 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 … N x N Trusted Intermediary (PLC) Users Princeton Berkeley Washington MIT Brown CMU NYU EPFL Harvard HP Labs Intel NEC Labs Purdue UCSD SICS Cambridge Cornell … Owners

4/17 Trust in PLC Owner PLC User ) 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/17 The New Problem Owners Testbed 1 Users Owners Testbed 2 Users Owners Testbed 3 Users ? ?

6/17 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/17 PLC is Centralized 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 … Trusted Intermediary (PLC) Users Princeton Berkeley Washington MIT Brown CMU NYU EPFL Harvard HP Labs Intel NEC Labs Purdue UCSD SICS Cambridge Cornell … Owners

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

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

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

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

12/17 Federation In Combination Slice & Management Federation This is the goal with Onelab

13/17 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/17 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/17 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/17 Addressing Scale & Isolation What if… The SA exports one slice to the MA SA 1MA MA - Node Manager SA1_fooSA1_bar Node SA2_one SA2_one_aSA2_one_b SA 2 SA2_one

17/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

18/17

19/17 PLC Today

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

21/17

22/17

23/17 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/17 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/17 Four Scenarios | Users | >> Size(node) O(N 2 ) O(N)