1. GEC3 – October 28-30, 2008www.geni.net1 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

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

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 October 29, 2008www.geni.net3

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 October 29, 2008www.geni.net4

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… October 29, 2008www.geni.net5

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 October 29, 2008www.geni.net6

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) October 29, 2008www.geni.net7

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… October 29, 2008www.geni.net8

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

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 October 29, 2008www.geni.net10

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) October 29, 2008www.geni.net11

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 October 29, 2008www.geni.net12

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 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. October 29, 2008www.geni.net13

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) October 29, 2008www.geni.net14

15. CF Structure October 29, 2008www.geni.net15

16. CF Structure with Distributed Slice Registry October 29, 2008www.geni.net16

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. October 29, 2008www.geni.net17

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. October 29, 2008www.geni.net18

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? October 29, 2008www.geni.net19

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? October 29, 2008www.geni.net20

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? October 29, 2008www.geni.net21

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? October 29, 2008www.geni.net22

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? October 29, 2008www.geni.net23

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? October 29, 2008www.geni.net24

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. October 29, 2008www.geni.net25

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… October 29, 2008www.geni.net26

27. Planned Control Framework Documents Architecture: –CF Architecture, v1DRAFT compete 10/17/08 –CF Architecture, v2DRAFT 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 October 29, 2008www.geni.net27

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 http://groups.geni.net/geni/wiki/GeniControl October 29, 2008www.geni.net28