The GENI Meta-Operations Center (GMOC)

If it’s research, why do we care about operations?

•Project to Build

•Infrastructure to support greenfield network science

•NOT Research in itself

•The Test Track, not the car

GENI

GENI Summary

• Funded by NSF• BBN Technologies serves as the GENI Project Office (GPO)• 2 Solicitations so far

• Solicitation #1 had 29 funded projects• Solicitation #2 had 33 funded projects

GENI Control Frameworks

• GPO grouped projects into control framework clusters• each cluster is anchored by a project to develop a control plane

for the facility• 5 clusters initially:

• PlanetLab• TIED• ProtoGENI• ORCA/BEN• ORBIT

GENI Early Focus: “Slicing”

• In GENI, a slice means a set of virtualized resources connected together to provide a single virtual testbed for a scientist

• “slicing” across parts of a control framework cluster is main thrust now

• future will mean inter-cluster slicing & federation with other facilities & networks

GENI Meta-Operations Center

What’s “Meta” mean?

• GENI is made up of many loosely affiliated projects

• Many projects have existing means to provide operations

• But what about operating GENI as a whole? What’s needed?

• Option 1/NOTHING - each part can operate independently without additional effort for GENI as a whole

• Option 2/Central GENI Operations Center - all GENI resources should be centrally managed & operated by a GENI operations center

• Option 3/Meta-operations - GENI projects can best handle most operational tasks. For GENI as a whole, someone should coordinate operations across projects to present a single interface to operators and users.

Cluster 2

Project D

Project C

Project A

Project B

Option 1 - Completely Distributed

Option 2 - Centralized

Cluster 1 Cluster 2

Project D

Project C

Project A

Project B

Cluster 2

Project D

Project C

Project A

Project B

Option 3 - Meta-Operations

Cluster 1

GMOC Architecture

GMOC Translator - Translates information from other formats into consistent data format

GMOC Translator - Translates information from other formats into consistent data format

GMOC Repository - Central datastore for operational data from all GENI parts

GMOC Repository - Central datastore for operational data from all GENI parts

Operations - Watches Data to provide useful functions like Emergency Shutdown

Operations - Watches Data to provide useful functions like Emergency Shutdown

GMOC Exchanger - Polls and/or receives operational data from aggregates

GMOC Exchanger - Polls and/or receives operational data from aggregates

GENI Meta-Operations Center

Early GMOC Functions

GENI View of Operational Status

• Give GENI-wide view of operational status

• maps & graphs

• prototype other views, such as slice-by-slice views

• Give Scientists access to their data

• “What was going on during these 2 weeks I ran my test?”

Emergency StopEmergency Stop

Identify & Shut down Misbehaving Slices

Protect Other Slices

Ensure Stability

in Phase1, Emergency Stop will consist of a process for manual contact of projects

Emergency Stop Demonstration To be performed in 2010

Challenges for GENI Operations

Challenge #1: Federation

• GENI has many projects

• doing different kinds of things

• with different abilities to provide operational data

• with different requirements for operational data

• GMOC depends on cooperation from them all

• Balance between central visibility and decentralized autonomy will need to evolve (and continue evolving)

Challenge #2: Layers of VisibilityGENI

Aggregates

Challenge #2: Layers of Visibility

GENI Components

Challenge #2: Layers of Visibility

Challenge #3: Virtualized Operations

• Everything is more temporary

• what “slices” are out there (NOW, 3 weeks ago)?

• How do we correlate current slices to future slices for repeatability

• Everything is more complex

• Many different groups to serve: Operators, Researchers, “Opt-in” Users

• Everything is more concurrent

• How do researchers setting up “slices” know the state of them(and not everything else)?

• How do we “shut down” the problem parts (and not everything else)?

Challenge #3: Virtualized Operations

• Everything is more temporary

• what “slices” are out there (NOW, 3 weeks ago)?

• How do we correlate current slices to future slices for repeatability

• Everything is more complex

• Many different groups to serve: Operators, Researchers, “Opt-in” Users

• Everything is more concurrent

• How do researchers setting up “slices” know the state of them(and not everything else)?

• How do we “shut down” the problem parts (and not everything else)?

Solicitation 2: K-GENI ETRI/KISTI-GENI Collaboration• Scope:

• Investigate international operational sharing and federation strategies

• Look into interoperability between GMOC and dvNOC

• for example: should GMOC conform to dvNOC data formats? vice versa? maybe a international “broker” to translate between them?

Does GENI have any relation to “normal” networks?

GENI Other R&E Networks (Geant, etc)

Federation

• End-to-end performance (perfSONAR)

• Multiple-domain Information sharing

Virtualized Testbed Operating Dynamic Circuits

Multiple LayersWhat Layers are operationally

significant?

GMOC PI: Jon-Paul Herron jpherron@indiana.edu

GMOC Team: gmoc@grnoc.iu.edu

GMOC Website: http://gmoc.grnoc.iu.edu/