Control Framework Working Group System Engineering Report October 29, 2008 Harry Mussman

1. Control Framework Working Group System Engineering Report October 29, 2008 Harry Mussman CF WG System Engineer hmussman@bbn.com groups.geni.net GENI working group wiki www.geni.net

2. What is the GENI control framework? Control framework includes: Clearinghouse Registries, each Aggregate Manager and users such as Researchers with their Experiment Control Tools, communicating via the Control Plane. www.geni.net

3. Who am I? • Harry Mussman • Current: Senior Systems Engineer in the GPO at BBN • Last: Voice-over-IP architect at BridgePort Networks (a startup) and GTE Internetworking/Genuity • BSEE Univ Michigan, MSEE Northwestern Univ, PhD Stanford Univ • hmussman@bbn.com • GENI roles: • Control Framework WG SE • Opt-in WG SE • GPO coordinator for six Spiral 1 projects www.geni.net

4. Goals(for this talk) • Understand WG SE roles • Learn about effort to formulate CF HLD, and current status • Discuss documentation plan for coming year, and make suggestions • Recommend reviewers, collaborators and authors www.geni.net

5. Agenda • Introduction to WG SE and roles • Relevant Spiral 1 projects • Control Framework High-Level Design (CF-HLD) • DRAFT document • Common choices • Current differences • Identified issues • Planned CF documents • Next… www.geni.net

6. Role of the Control Framework WG SE • Frame technical issues from top-down • Collect issues from WG, organize and revise • Use to identify and structure WG documents • Synthesize input from bottom-up • Collect input from WG, compile and distribute • Look for and summarize consensus (or lack of it) • Draft WG documents… • Manage process to completion • Assist WG communications • Take and distribute notes • Maintain wiki www.geni.net

7. How WG Creates a Document • SE drafts document, with input from WG • GPO does internal review • SE posts first draft • On wiki (to start); repository TBD • WG discusses document on WG list • Possible one-on-one follow-ups • SE assembles changes, revises and posts revision • (Repeat, until document completed) www.geni.net

8. Agenda • Introduction to WG SE and roles • Relevant Spiral 1 projects • Control Framework High-Level Design (CF-HLD) • DRAFT document • Common choices • Current differences • Identified issues • Planned CF documents • Next… www.geni.net

9. GENI Spiral 1 Integration: Five Control Framework Clusters Cluster A Cluster B Cluster C Cluster D Cluster E 1609 DETER Trial Integ 1600 PlanetLab 1579 ProtoGENI 1582 ORCA/BEN 1660 ORBIT Framework 1613 Enterprise GENI 1601 Virtual Tunnels 1599 Vehicular Mobile Network 1657 WIMAX 1621 GUSH Tools 1646 CMU Testbeds 1602 Sensor/Actuator Network STUDY ALL PICK ONE 1604 GENI Meta Operations 1643 Programmable Edge Node 1622 Provisioning Service 1642 Instrumentation Tools 1633 Kansei Sensor Network 1632 Security Architecture 1645 Million- Node GENI 1658 Mid-Atlantic Crossroads 1628 Measurement System 1631 Embedded Real-time Measurements 1650 Regional Opt-In 1595 Great Plains Environment for Ntwk Innovation 1663 Digital Object Registry 1619 Optical Access Networks 1578 Overlay Hosting Nodes Highlighted Spiral 1 projects are central or highly relevant to Control Framework 1610 GENI at 4-Year Colleges Key: Column labels show common control framework 1653 Data Plane Measurements Projects with active Spiral 1 clearinghouse interfaces www.geni.net

10. Spiral 1 Projects • Five Spiral 1 projects are focused on control frameworks for different clusters of projects: • 1609 DETER (Cluster A) • 1600 Planetlab (Cluster B) • 1579 ProtoGENI (Cluster C) • 1582 ORCA (Cluster D) • 1660 ORBIT (Cluster E) • Four Spiral 1 projects are highly relevant to the CFs: • 1621 GUSH tools • 1622 Provisioning Service • 1632 Security Architecture • 1663 Digital Object Registry www.geni.net

11. continued (2) • CF is highest risk item for Spiral 1. • Having five CFs: • Will bring unique contributions to the table. • Prevents the loss of good ideas. • Will mitigate risks. • Expect consolidation over time, but no “sudden death”. • How do we: • Clearly describe each CF, with a common vocabulary? • Understand common choices, and differences? • Identify common issues, and get them resolved? • Work towards defining a “final” CF? (or possibly multiple CFs) www.geni.net

12. Agenda • Introduction to WG SE and roles • Relevant Spiral 1 projects • Control Framework High-Level Design (CF-HLD) • DRAFT document • Common choices • Current differences • Identified issues • Planned CF documents • CF WG action items www.geni.net

13. Control Framework HLD DRAFT Document • Now ready for review by CF WG: http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkArchitecture/102008_GENI-ARCH-CP-01.4.pdf • Intent: • Clearly describe each CF, with a common vocabulary. • Understand common choices, and differences. • Identify common issues. • A way towards defining a “final” CF-HLD, but a long way to go…. • Approach: • Utilize a “linear” structure to decompose the CF-HLD. • Describe the CF-HLD as one design, focusing on common choices, but noting differences. • Provide multiple “worked examples” for clarity. www.geni.net

14. continued (2) • Structure of document: • Start with system design overview to understand structure and concepts. (Section 3) • List features and functions that must be included. (Section 4) • Present control framework structure, including entities, interfaces, principals, services and objects. (Section 5) • Consider each interface, plus major concepts, and present examples of usage that walks through key scenarios. (Sections 6 – 11) • Include sections to summarize five current control frameworks being implemented for Spiral 1. (Sections 12 – 16) www.geni.net

15. CF Structure www.geni.net

16. CF Structure with Distributed Slice Registry www.geni.net

17. Common CF-HLD Choices • Common to all current CF implementations. • Some exceptions? • Choice 1: Control interfaces include APIs that follow a web services model, using SOAP and https (for a secure channel). • Plus separate interfaces for loading software, etc. • Choice 2: Principals (and services) have global identities. • Are identified and authenticated with certificates from a PKI • Choice 3: Authorization is handled with signed tokens (certificates) • Passed from registry, to researcher, to aggregate, etc. • Based on an underlying trust management system. www.geni.net

18. Current CF-HLD Differences • Difference 4: Current CF implementations have clearinghouse registries (and related authority services) that vary: • From centralized to distributed. • With different arrangements of registries and related authority services. • How can one CF-HLD accommodate them all? • Ongoing discussions with each CF project to resolve. www.geni.net

19. continued (2) • Difference 5: Current CF implementations have different token flows for requesting resources, etc. • Is there a way to evaluate the differences? • Can we have a flexible arrangement for future extensions? • How does this interact with the resource description approach? • Is the current approach to an RSpec sufficient, or does it need to be extended? • This overlaps with work in the Substrate WG on RSpec definition. • Who in this WG is interested in contributing? www.geni.net

20. Identified CF-HLD Issues • Issue 6: CF-HLD includes authentication and authorization techniques that are strongly dependent on security architecture. • Are current choices reasonable? • What changes will have to be made as security architecture is formulated? • 1632 Security Architecture project will address this issue. • Who in this WG is interested in contributing? www.geni.net

21. continued (2) • Issue 7: Identity and authentication should include use of existing identity management systems, to permit easier federation • Which system(s)? InCommon? Others? • How can this best be done? • Who in this WG is interested in contributing? www.geni.net

22. continued (3) • Issue 8: CF-HLD includes authorization techniques that are based on signed tokens. • This is fundamental to current CF-HLD. • What needs to be done to properly verify signed tokens? • What needs to be done to properly verify the identity of offering principal (service), particularly when tokens have been delegated to an Experiment Control Service. • Can we be sure that this will work securely in a large scale system? • Who in this WG is interested in contributing? www.geni.net

23. continued (4) • Issue 9: CF-HLD authorization mechanism is based on a trust management system. • Principals have a “credential” (“trust assertion” signed by authority). • Aggregate Manager accepts credential, and uses a local “policy checker” to decide whether (or not) to authorize resource assignment. • How does Policy Checker work? • Can it be extended to flexibly utilize new parameters and approaches? • How can trust management reflect global (e.g., NSF) as well as local policies? • How can trust management be established over diverse entities, to permit wide-ranging federation? • Who in this WG is interested in contributing? www.geni.net

24. continued (5) • Issue 10: The CF-HLD needs to include logs and other forensic information. • To enable essential operations functions, i.e., “emergency shutdown”. • To enable desired operations functions, i.e., “help desk” for researchers. • To enable routine operations functions, i.e., usage summaries and audits. • How can this be done in a very distributed system? • Is there a need for a subscribe/publish mechanisms to distribute the information? • Who in this WG is interested in contributing? www.geni.net

25. Next Steps for CF-HLD Document • Continue to identify and address issues. • Fold solutions back into CF-HLD document. • Summarize the structure/features of each current CF implementation. • Use the “linear” structure from the CF-HLD. • Continue reviews of CF-HLD document, revise, and repeat until complete. • Who in WG is interested in reviewing? • Work toward v2 of CFA document, as we learn from Spiral 1 implementations. www.geni.net

26. Agenda • Goals • Introduction to WG SE and roles • Relevant Spiral 1 projects • Control Framework High-Level Design (CF-HLD) • DRAFT document • Current choices • Current differences • Identified issues • Planned CF documents • Next… www.geni.net

27. Planned Control Framework Documents • Architecture: • CF Architecture, v1 DRAFT compete 10/17/08 • CF Architecture, v2 DRAFT due 6/16/09 • Subsystems: • Clearinghouse Subsystem Technical Description, v1 DRAFT due 2/15/09 • Clearinghouse Subsystem Technical Description, v2 DRAFT due 7/16/09 • Clearinghouse Subsystem Intfc Cntrl Doc, v1 DRAFT due 3/1/09 • Clearinghouse Subsystem Intfc Cntrl Doc, v2 DRAFT due 8/1/09 www.geni.net

28. Next… • Notes, slides, action items, etc will be sent to the working group mail list and posted on the wiki page: http://groups.geni.net/geni/wiki/GeniControl www.geni.net