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

GENI Meta-Operations Center

GMOC Translator - Translates information from other formats into consistent data format GMOC Repository - Central datastore for operational data from all GENI parts Operations - Watches Data to provide useful functions like Emergency Shutdown GMOC Exchanger - Polls and/or receives operational data from aggregates GENI Meta-Operations Center

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

GENI Meta-Operations Center GMOC Translator - Translates information from other formats into consistent data format

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

GENI Meta-Operations Center Operations - Watches Data to provide useful functions like Emergency Shutdown

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 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 Visibility GENI 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? GENIOther R&E Networks (Geant, etc) Federation End-to-end performance (perfSONAR) Multiple-domain Information sharing Virtualized TestbedOperating Dynamic Circuits Multiple LayersWhat Layers are operationally significant?

GMOC PI: Jon-Paul Herron GMOC Team: GMOC Website: