wiki:GeniDesign

Version 11 (modified by Aaron Helsinger, 12 years ago) (diff)

--

GENI Design Activities

Introduction

The GENI design and prototyping community is working together to agree on the key functions and interfaces needed to meet GENI's requirements. This page collects pointers to GENI design collaborations organized around GEC meetings.

Online discussion of these topics should be directed to dev@geni.net. (Only subscribers may post to this list. Subscribe here.)

Active Efforts

Instrumentation and Measurement
Develop architectural framework, build and deploy prototypes for GENI instrumentation and measurement infrastructure.
GENI API
The GENI API is an effort to enable interoperability between Control Frameworks/Clearinghouses and Aggregates. It includes the GENI Aggregate Manager API.
Identity and Attributes
GENI requires a way of positively identifying experimenters and granting them access to tools and resources. Current control frameworks either maintain their own database of users or explicitly outsource this task to an identity provider. In addition to identifying experimenters, GENI needs information about attributes like institutional affiliation, project role, etc. This includes discussion of Shibboleth.
Authorization
GENI requires an authorization solution that will allow architectural components (Clearinghouse, Aggregates) to determine the privileges of an experimenter. Experimenters can be granted privileges based on institutional affiliation, project role or membership attributes, for instance. Aggregates are expected to have local policies regarding resource access and use. This includes discussion of ABAC as the long term authorization logic for GENI.
Resource Specification
In order to truly allow interoperability among multiple control frameworks and aggregates, GENI requires a common language for describing resources, resource requests, and reservations - a single, well defined RSpec schema. GENI uses XML documents with a defined schema.
Network Stitching
A key architectural question for GENI has been how to connect the resources provided by multiple aggregates into a coherent network. The key objective is to enable automated and realtime network stitching for slices which span multiple aggregates. Ethernet VLANs have been identified as the initial network technology to provide slice level inter-aggregate connections and isolation. GENI has identified several services, and an RSpec schema for communicating key information, which together constitute the GENI network stitching architecture.
Monitoring & Management
Monitoring and management focuses on the ability to perceive what is happening within GENI in order to debug and troubleshoot problems.
GENI Racks
Common requirements and functions of GENI racks.
GENI Clearinghouse
Architecture and design for a clearinghouse for the GENI federation.
GENI Architect Team
Documents prepared and ratified by the GENI Architect Team regarding the GENI Federation Software Architecture.

Inactive & Past Efforts

GENI Workflow and Services
What do experimenter-users need from GENI? Consider planning, scheduling, running, debugging, analyzing experiments; long running experiments & how they grow; archiving data.
Control Framework
What is universal across GENI components? How will evolution be accommodated with or without a full transition of all GENI nodes at once?
End-User Opt-in
How do end-users (including Internet users) participate in GENI experiments? What are the various aspects including user interfaces, scheduling, debugging, measurement, archiving data, sandboxes, etc? What are the privacy and legal issues involved in user opt-in?
Substrate
What is the framework for evolution of substrate technologies? What technologies should be in GENI? How will they be used?