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

GEC3 – October 28-30, 2008 www.geni.net 1

Control Framework Working GroupSystem Engineering Report

October 29, 2008

Harry MussmanCF WG System Engineer

[email protected]

groups.geni.netGENI working group wiki

What is the GENI control framework?

October 29, 2008 www.geni.net 2

GENIEnd User

GENI Srvc S3

Visualization Service

GENI Srvc S2GENI Srvc S1

DOE Agg Z(federated aggregate)

Aggr Z

GENI Operations & Management

GENI Aggr A

■ Operator■ Admin

Help Desk & Tools

■ Admin & Account Tools

Host A1

Host Ax

GENI Comp B

Comp B

Measure & Store

Software Storage

● ■Aggr Mgr with Ops Portal

Admin Oper

GENI Clearinghouse

ComponentRegistry

Principal Registry

●■Ticket: Store Query

●■Principal: Register Authen Query

Slice Registry

TicketLog

SoftwareReposit

●■Slice: Register Cred Issue or Tkt Broker Query

●■Soft Mod: Store Get Query

●■Component: Register Query

Research Org A

● Researcher

● ExperimentSupport Tools

Research Org B

● Slice Admin

● PI

LocalPrincipal Registry

EndUser

via Internetor GENI

■ Ops & Mgmt Tools

● ExperimentSupport Tools● Experiment

Control Tools

Experiment Plane

Measurement Plane

● Control Plane

■ Ops and Mgmt Plane

● ■Comp Mgr with Ops Portal

Admin Oper

● ■Aggr Mgr with Ops Portal

Admin Oper

Control framework includes: Clearinghouse Registries, each Aggregate Manager and users such as Researchers with their Experiment Control Tools, communicating via the Control Plane.

Control framework includes: Clearinghouse Registries, each Aggregate Manager and users such as Researchers with their Experiment Control Tools, communicating via the Control Plane.

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– [email protected]

• GENI roles:– Control Framework WG SE– Opt-in WG SE– GPO coordinator for six Spiral 1 projects


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


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…


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


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)


Agenda





www.geni.net 9

GENI Spiral 1 Integration: Five Control Framework Clusters

1578 Overlay Hosting Nodes1578 Overlay

Hosting Nodes

1579 ProtoGENI

1579 ProtoGENI

1595 Great Plains Environment for Ntwk Innovation

1595 Great Plains Environment for Ntwk Innovation

1646 CMU Testbeds

1646 CMU Testbeds

1609 DETERTrial Integ

1609 DETERTrial Integ

1642 Instrumentation

Tools

1642 Instrumentation

Tools

1613 Enterprise

GENI

1613 Enterprise

GENI

1600 PlanetLab

1600 PlanetLab

1658 Mid-Atlantic Crossroads

1658 Mid-Atlantic Crossroads

1602 Sensor/Actuat

or Network

1602 Sensor/Actuat

or Network

1582 ORCA/BEN

1582 ORCA/BEN

1599 Vehicular Mobile

Network

1599 Vehicular Mobile

Network

1660 ORBIT Framework

1660 ORBIT Framework

1601 Virtual Tunnels

1601 Virtual Tunnels

1657WIMAX

1657WIMAX

1663 Digital Object

Registry

1663 Digital Object

Registry

1633 Kansei Sensor Network

1633 Kansei Sensor Network

1628 Measurement

System

1628 Measurement

System

1604 GENI Meta

Operations

1604 GENI Meta

Operations

1643 Programmable

Edge Node

1643 Programmable

Edge Node

1621 GUSH Tools

1621 GUSH Tools

1622 Provisioning

Service

1622 Provisioning

Service

1650 Regional

Opt-In

1650 Regional

Opt-In

1632 Security Architecture

1632 Security Architecture

1645 Million- Node GENI1645 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 1clearinghouse interfaces

STUDY ALL PICK ONE

1619 Optical Access

Networks

1619 Optical Access

Networks

Column labels showcommon control framework

Highlighted Spiral 1 projects are central or highly relevant to Control Framework

Highlighted Spiral 1 projects are central or highly relevant to Control Framework

1653 Data Plane

Measurements

1653 Data Plane

Measurements

1631 Embedded Real-time

Measurements

1631 Embedded Real-time

Measurements

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


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)


Agenda



• Planned CF documents• CF WG action items


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.


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

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)


CF Structure


Component Registry

Aggregate Cluster 001mageni.maprince.clus001

Aggr Mgr

= Slice Intfc< O&M Intfc

Aggr ManagerLog

Experiment Control Service 01...srvc00001

À Experiment Intfc ExperimentCntrl SrvcLog

Slice Auth Srvc XYZSageni.saxyz

Aggr Rec mageni.maprin.clus001

Slice Registry

SliceAuth Rec sageni

SliceAuth Rec Sageni.saxyz

Slice Rec Sageni.saxyz.sl001

Slice Auth Srvc GENIsageni

PI 01 ...alice01

MgmtAuth Rec mageni

MgmtAuth Rec mageni.maprinPI 02

...alice02

Researcher 01 ...fred01


Authority Chain

Sliver Server

z Sliver Intfc

SliverSrvrLog

Mgmt Auth Srvc Princmageni.maprin

Mgmt Auth Srvc GENImageni

Operator 01 ...bob01

Operator 02 ...bob02

Component Host 001...cluster0001.host001

Comp Mgr


Comp ManagerLog

Principal Registry

Prin Auth Srvc BBNpageni.sabbn

PrinAuth Rec pageni

PrinAuth Rec pageni.pabbn

Prin Auth Srvc GENIpageni

Broker Service 001pageni.srvc00002Mageni.broker001


BrokerSrvcLog

Principal Rec pageni.srvc00001

Slice Rec sageni.slbroker01

Associations

Aggr Rec Mageni.broker001

Admin 01 ...mary01

Admin 02 ...mary02

Principal Rec pageni.srvc00002

Component Registry Services

p Registry Intfc

Comp RegistryLog

Principal Registry Services

p Registry Intfc

Principal RegistryLog

Slice Registry Services

p Registry Intfc

Slice RegistryLog

Principal Rec pageni.pabbn.alice01

Principal Rec pageni.pabbn.fred01

Policy Checker

CF Structure with Distributed Slice Registry


Slice Registry for Slice Authority sageni

SliceAuth Rec sageni

Slice Auth Srvc GENIsageni

PI 01 ...alice01

PI 02 ...alice02



Authority Chain

Slice Rec sageni.slbroker01

Associations


p Registry Intfc

Slice RegistryLog

Slice Auth Srvc XYZSageni.saxyz

Slice Registry for Slice Authority sageni.saxyz

SliceAuth Rec Sageni.saxyz

Slice Rec Sageni.saxyz.sl001


p Registry Intfc

Slice RegistryLog

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.


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.


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?


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?


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?


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?


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?


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?


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.


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


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