Version 8 (modified by 13 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.
- 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.
- 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.
- 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.
- 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. However, there are many architecture and design decisions still required. These include, how do you select the VLAN IDs to use and inform all necessary aggregates? How do you handle external networks which may be in between two GENI Aggregates of interest? Is the network stitching service a shared service which coordinates across aggregates, or are aggregates responsible for coordinating amongst themselves, or a hybrid model? How is stitching related information described and shared ?
- Monitoring & Management
- Monitoring and management focuses on the ability to perceive what's 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.
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?