Changes between Initial Version and Version 1 of GeniDesign


Ignore:
Timestamp:
03/07/11 14:30:03 (8 years ago)
Author:
Aaron Falk
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GeniDesign

    v1 v1  
     1= GENI Design Activities =
     2
     3=== Introduction ===
     4
     5The 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.
     6
     7=== Active Efforts ===
     8
     9 [wiki:GeniInstMeas Instrumentation and Measurement]::
     10  Develop architectural framework, build and deploy prototypes for GENI instrumentation and measurement infrastructure.
     11
     12 [wiki:GeniApi GENI API]::
     13  The GENI API is an effort to enable interoperability between Control Frameworks/Clearinghouses and Aggregates.
     14
     15 Identity and Attributes::
     16  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.
     17
     18 Authorization::
     19  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.
     20
     21 Resource Specification::
     22  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.
     23
     24 Network Stitching::
     25  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 ?
     26
     27
     28----
     29
     30
     31=== Inactive & Past Efforts ===
     32
     33 [wiki:GeniServices GENI Workflow and Services]::
     34  What do experimenter-users need from GENI? Consider planning, scheduling, running, debugging, analyzing experiments; long running experiments & how they grow; archiving data.
     35
     36 [wiki:GeniControl Control Framework]::
     37  What is universal across GENI components? How will evolution be accommodated with or without a full transition of all GENI nodes at once?
     38
     39 [wiki:GeniOptIn End-User Opt-in]::
     40  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?
     41
     42 [wiki:GeniSubstrate Substrate]::
     43  What is the framework for evolution of substrate technologies? What technologies should be in GENI? How will they be used?