Roadmap

Work with other GENI projects providing security services to GENI. The security services will be integrated into the GMOC framework as they become available. Ongoing work in months 1-6.

Produce a reference design showing how a planned Spiral 1 project(s) opt‐in can be implemented with Spiral 1 end‐to‐end connections. Demonstrate how the design meets opt‐in requirements from the initial requirements document. Submit results to Opt-in, Control Framework, and OMIS working groups.

Provide a survey of research and education experiments of interest to 4 year colleges, and the substrate resources required to enable them.

Present the opt-in prototype to the local Computer Science communities to encourage them to explore its capabilities. Solicit some real networking experiments from the community to gain real field experience with these opt-in techniques. (Work is ongoing from month 9-12).

Focus on spiral-1 substrate technologies and identify which experiments from the survey could be supported on spiral-1

Since there is not significant field experience with wholesale opt-in already available, develop a local opt-in prototype that permits local researchers to interpose experimental networking equipment in the path to the public Internet. Make the scripts and configurations available to interested GENI participants via download.

Begin integrating existing University of Kentucky tools in the prototype testbed. Produce a document describing the architecture/design of the instrumentation toolset along with a description of some of the proposed tools. (Ongoing in months 10-12.)

Describe the network connections between specific external test equipment identified/recommended above and spiral-1 substrate components.

Deploy component and clearinghouse packages v0.2 in GENI testbed, and assist other groups and projects to *complete* integration with the following:

  • federation with other PlanetLab-related testbeds;
  • PlanetLab programmable host clusters;
  • VINI network;
  • specialized network nodes, paired with VINI PoPs;
  • enterprise access networks;
  • other enterprise elements, including host clusters, network nodes
  • and wireless access nodes;
  • researcher helper tools;
  • researcher helper tools;
  • extended programmable host nodes;
  • aggregate of optical networks, including connections to Internet2;
  • regional optical network, with programmable optical nodes;
  • overlay hosting network nodes;

Participate in NSF TRUST Science and Technology (S&T) Center's Summer, 2009 Teacher Education program to familiarize TRUST's pool of undergraduate and underrepresented community institution faculty with educational use and potential of TIED/GENI facilities. (Exact timing depends on dates of program, but should be completed by September 1, 2009.)

Deploy the Aggregate Manager in the Kentucky GENI prototype, and support limited operations to allow experimental use of the testbed through the ProtoGENI clearinghouse. (This work in ongoing in months 11 and 12.)

Software release. Make BGP mux and tunnel software available for download by other GENI prototype projects.

  • This will be a bare-bones release: A user at ProtoGENI will be able to specify tunnels and BGP sessions through the management interface
  • This will produce an RSpec that our scripts can read and:

o Produce tunnels on ProtoGENI nodes

o Produce BGP sessions between the BGP mux and protoGENI clients

This due date of this milestone was changed from 6/1/09 to 9/30/09. See Ticket #183 for details.

Help develop GENI Concept of Operations. Coordinate with GENI projects and the OMIS working group to develop a draft GENI Concept of Operations framework. Work ongoing in months 1-12.

The initial GMOC framework implementation will include an Operational Dataset translator. This will be software used to convert data in existing formats from existing projects that would be of operational interest into the GMOC Native Operational Data Format. Work ongoing in months 6-12.

Exact timing of GEC demonstration depends on particulars of GEC schedules.

The initial GMOC framework implementation will include a Data Exchanger. This is the software implementation and protocol used to receive and transmit operational datasets among GMOC partner projects and with the GMOC. Work ongoing in months 6-12.

The working prototype GMOC is a documented suite of systems and processes working to share operational data among all the partner projects. Work ongoing in months 6-12.

Actively provide “emergency stop” functionality to participating projects to isolate or turn down disruptive experiments, and actively notify partner projects of operational issues, as they want

Develop a demonstration based on the reference Spiral 1 prototype design, and present the demonstration at a GENI Engineering Conference. Make demonstration scripts and configurations available to interested GENI participants via download. (Exact timing of demonstration will depend on GEC schedules.)

Demonstrate extended clearinghouse/component functionalities key to outreach communities (e.g., extended security model access).

Demonstrate and support running federated experiments by owner(s) outside the development team by the end of year 1.

1g

Make a working and tested prototype of BEN and GENI (substrate and control framework) available for limited external research

Only to researchers who have access to NLR either directly or in the form of tunnels.

Make the GENI control framework available to universities for use in student projects and coursework.

Open testbed to GENI researchers, to utilize aggregates and components in combination to complete experiments, and maintain use records.

Provide use-case scenarios (at least 1) of an experiment identified for spiral-1, this will include the specifics of one of the GENI prototype control frameworks and is limited to the substrate resources in that cluster.

Delivery of SPP component manager interface documentation to GPO

Launch the DSL messaging/application to the public FB community (CyrusDSL)

Produce draft detailed outline of Spiral 2 Security Design Report and list of security Points of Contact providing input for each project. Release to GENI community.

Create federated slice using SFA machinery across PLC, PLE, and PLJ. Assume minimal peering policy based on sliver count. Users interact with system using SFI command-line tool. Assume pair-wise peering among these three organizations

Document describing design and operation of the system running on ProtoGENI. Document should include expected ProtoGENI resource usage (computing, network, storage), availability targets for the application and approach to meeting them, instrumentation plans and privacy plans.

Initial user guide for ProtoGENI experimenter tools.

Release Spiral 2 Security Design Report on Spiral 2 projects to the GENI community. This report will be based on analysis of security designs from each Spiral 2 project, as represented by the software and documentation they contribute to the December 15 GENI Integration release. Release to GENI community and present at GEC if requested by the GPO.

Launch suite of online social networking/Facebook games based on the DSL Facebook Kernel (CyrusDSL). Enhance existing games for usability.

This feature will allow DSL/FB users to utilize Facebook for their SMTP email traffic. This indicates that their regular email traffic will be routed through GENI.

The DSL/Facebook application has been ported to ProtoGENI and is being used by select users at UC Davis.

Updates to document in Milestone S2.b. Plans must be reviewed and approved by the GPO and ProtoGENI before public launch of DSL/FB apps on ProtoGENI.

Playbook for international research projects that want to connect with GENI at Layers 2 & 3

Produce draft detailed outline of revised Spiral 2 Security Design Report and list of security Points of Contact providing input for each project. Release to GENI community.

Demonstrate connections from Kansei and NetEye testbeds to Internet2 network; contingent upon availability and additional support of potential cost associated with VLAN transport service by backbone network, demonstrate VLAN connections from Kansei and NetEye to backbone network. (3/16/10, GEC7)

Implement access to BEN testbed from experiment control tools and service manager(s) that are located at a site remote from your testbed, and demonstrate. (3/16/10, GEC7)

Work with the ORBIT project, to integrate your testbed with their testbed(s) (all utilizing OMF interfaces and software) to from an environment of federated wireless testbeds, and demo main functionality of your base station in this environment. (3/16/10, GEC7)

Report on the use of modern federated technologies within their control plane approaches: (1) Application of federated identity to the authentication and authorization needs of ORCA, (2) Adaptation of federated identity technologies to other elements under ORCA control – slices, routers, etc.

Demo using regular Duke IT infrastructure to permit appropriate academic classes to access ORCA capabilities.

IRB approval is required to give users (both CMU users using CMUlab and non-CMU users through federation) access to Homenet nodes, since they nodes are placed in residential areas and can be used to sniff and disrupt regular user traffic. Will work with the CMU IRB to define how and under what constraints Homenet can be used by non-CMU users. Will report back and collaborate with the GENI community on solving this problem in a general sense.

Work with Planetlab on an assessment of the value of federated identity within their activities.

Demonstrate new policy engine (based on sfa_tables) by introducing richer peering policies; e.g., white-lists and black-lists.

Playbook review by GPO, GENI projects related to operations and security, and other interested parties.

Milestone: CompSec: S2.c

9 years late (04/30/10 00:00:00)

Telephone review of Report by GPO, other security projects, control frameworks and other interested parties.

Install GENI software with AM API implementation.

Install GENI software with AM API implementation.

Lab test OpenFlow 1.0 capable switch and controller with Internet2 Aggregate Manager for year one deployment.

Install GENI software with AM API implementation.

Install GENI software with AM API implementation.

Install GENI software with AM API implementation.

Install GENI software with AM API implementation.

Install GENI software with AM API implementation.

Start software to enhance WORKIT nodes with WiMax clients.

Launch of DSL/FB instance on ProtoGENI with new applications:

DSL/FB applications publicly available. Recommendations from review of Milestone 6 document must be implemented before launch.

Document describing basic ProtoGENI metrics and the mechanisms via which the core model can be extended.

Notes: Combined with milestone S2.b (Prospectus on integration of perfSonar with other monitoring efforts). New due date for combined milestone: 21 May 2010. [Approved by Henry on 4/14/10.

Use tagged VLANs to support multiplexing of control and data planes across the same physical Ethernet infrastructure (such as the private network used by CMUlab). This will eliminate the requirement that testbed nodes be multi-homed. Evaluate and document the performance difference between the VLAN and VPN based solutions, as seen from the perspective of users (running experiments).

Complete revised Concept of Operations document. Revise the Concept of Operations document drafted in Spiral 1 based on lessons learned from exemplar interactions, emergency shutdown, and visualization prototypes. May also include any new drafts for Common Operational Data set document and Operational data format documents. Document will be reviewed and discussed at GEC8.

Deploy OpenFlow switches to five Internet2 Points of Presence. Deploy controller and Internet2 Aggregate Manager. The exact timing for these deployments will depend on the plan delivered in milestone OFI2: S2.a, at which point the due date for full completion of this milestone should be revised. Deployment schedule should support limited integration testing between at least one OpenFlow site and the Internet2 OpenFlow capable network in May 2010.

Collaborate with the ORCA Augmentation project to develop and document an initial ontology for substrate measurement capabilities. (6/1/10)

Milestone: CRON: S2.e

9 years late (06/25/10 00:00:00)

Installing a slice authority and a component manager; and design interfaces for viewing operational resources at the federated CRON testbed.

Milestone: GpENI: S2.c tools -

9 years late (06/30/10 00:00:00)

Identify user helper tools developed within other GENI projects and integrate them into GpENI. Document in a short technical note the list of tools that were integrated (and how), and the list of tools that were not (and why). 12/31/09

Milestone due date change from 12/31/09 to 06/30/10 approved by Henry Yeh on 4/14/10.

Solicit comments on initial version of prospectus from GPO, other measurement projects, ProtoGENI project, and other interested parties. Update prospectus based on comments and any new information gathered since initial version of prospectus.

Notes: Milestone date changed to be after Measurement Workshop in early June. Document update will incorporate feedback/information from the measurement workshop. [Approved by Henry on 4/14/10]

White paper that examines the numerous ways federation is applied inside the GENI framework and suggests possible alignments of federated concepts within GENI. Possibly present this paper at GEC 8 .

Add support for multiple OpenFlow protocols (specifically 0.9 and 1.0) within the same build.

f) Add support for better transfer mechanism (e.g. SET). (June 31, 2010)

Demonstrate hierarchical (not pair-wise) peering by including VINI, M-Lab, and G-Lab in the federation

Make PrimoGENI Aggregate 1.0 available to early experimenters. Deliver aggregate manager software. Identify point of contact (PoC) for the GENI Prototype Response and Escalation Group.

Implement and document second release (v2.0) of Linux-based GENI base station node software, to be used in first campus WiMAX kits. (7/15/10)

Make stand-alone cognitive radio system available for use by selected GENI researchers. (7/20/10, GEC8)

Collaborate with other GENI projects and GPO to develop and document a v1.0 common GENI instrumentation and measurement architecture. (7/20/10, GEC8)

Complete initial integration of the LEARN network into the ORCA control framework (GENI Cluster D), to enable GENI researchers to utilize the LEARN network for L2 (VLAN) transport between a limited number of sites, e.g., University of Houston and Rice University. (7/20/10, GEC8)

Complete a detailed technical plan for integrating robotic nodes into GENI using the ORCA control framework, , for sharing by multiple researchers, including an experiment control portal; the abstraction of components in the robots will be designed to cover microcontrollers, communication, dozens of sensors, actors, power, and attached sensor nodes. (7/20/10, GEC8)

Demonstrate ability to query a broker about resources available, and total delegated. (7/20/10, GEC8)

Demonstrate integration of GUSH with Service Manager. (7/20/10, GEC8)

Demonstrate ProtoGENI experiment that uses PrimoGENI resources. Deliver software, scripts and documentation necessary to repeat experiment.

Demonstrate VICI cluster integration to control framework. Demonstrate continued compatibility with current ProtoGENI naming and credentials and current OpenFlow aggregate manager. Further revision of sfatable mechanisms for policy expression mechanisms.

Demonstration of perfSONAR on ProtoGENI at GEC

Work with at least one GENI measurement project to have that measurement project output it's measurement data using the perfSONAR project's schema proposal. The perfSonar project will provide libraries, etc. needed to make this happen. This will be demonstrated at GEC8.

New milestone. Approved by Henry on 4/14/10.

Establish connections with relevant projects in Control Plane and Measurement Plane such as the following. Produce plan for working with Control Plane and Measurement Plane projects.

A decentralized version of DSL running, simultaneously, over both Cryus and ProtoGENI. I.e., some of the data and activities will take place on either one of the platforms.

Prototype perfSONAR deployment on ProtoGENI infrastructure. Deliver software, documentation and user manual.

Notes: Moved to after GEC8. Project will demonstrate this prototype at the GEC8 and make this software (cleaned up and documented) after the GEC. [Approved by Henry on 4/14/10.]

Milestone: CompSec: S2.g

9 years late (08/13/10 00:00:00)

Telephone review Aggregate Provider Agreement by GPO, other security projects, control frameworks and other interested parties.

Release revised Spiral 2 Security Design Report to the GENI community. This report will be based on analysis of security designs from each Spiral 2 project as represented by the software and documentation they contribute to the July 15 GENI Integration release. This report will incorporate feedback from early Spiral 2 development, deployment and prototyping activities. Release to GENI community and present at GEC if requested by the GPO.

Playbook updated based on completed GMOC-dvNOC interoperability trials, review of Version 1.0 of Playbook

Version to include interfaces for storage of measurement data and metadata. Define metadata extensions to capture data provenance. Deliver software, documentation and user manual. Make perfSONAR available to experimenters on GENI and support use of perfSONAR by experimenters.

Notes: Public release of s/w demonstrated at GEC. [Milestone date change approved by Henry on 4/14/10.]

Collaborate with O&M team on methods to share O&M data with other GENI groups for Spiral 2.

Collaborate with GMOC operations group on providing access to OMF operating data. (11/1/09-8/31/10)

Begin work on teaching modules to explore wide area wireless network issues and applications.

Collaborate with GMOC operations group on providing access to WiMAX base station operating data. (11/1/09-8/31/10)

Specific contribution to GENI outreach plan required for Spiral 2: (9/1/09-8/31/10)

PrimoGENI Aggregate 2.0 design and development plan.

Provide an implementation plan for PrimoGENI aggregate 2.0, with extended virtualization capabilities supporting multiple simultaneous large-scale high-fidelity network experiments, and necessary tools for streamlining experiment workflow (including configuring, deploying, monitoring and controlling network experiments).

Report on experiences with DSL/FB apps on ProtoGENI.

Report on usage statistics, resource utilization, type and amount of data collected, experiences with supporting these apps on a GENI testbed, etc.

Milestone: CRON: S2.f

9 years late (09/17/10 00:00:00)

Perform experiment over the beta version of federation among CRON, LONI, ProtoGENI sites. Report to describe experiences with tools, desired improvements/features, etc. Deliver software, scripts and documentation necessary to repeat experiment.

Release a full set of design information for stand-alone cognitive radio system “kit”, including hardware and v0.1 software. (9/30/10)

Specific contribution to GENI outreach plan for Spiral 2. (9/30/10)

Complete Spiral 2 prototype data sharing system. Complete implementation and testing and put prototype data sharing in place for all projects identified in milestone S2.a Prototyping Plan. Data collected will include either the full set of required data in the Common Operational Dataset document or a subset of critical data, depending on each project's capabilities, and the discussions in milestone S2.a.

Prototype multi-cluster GENI-wide visualization. Generate a prototype GENI map that visualizes multiple clusters at a time, in order to show integration within and between clusters, and the activity of slices across clusters.

Purchase second Ciena switch and integrate into GpENI. 03/31/10

Milestone date change from 3/31/10 to 9/30/10 approved by Henry Yeh on 4/14/10.

Finish development and deliver a v1.0 version of the IMF and SILO software. (9/30/10)

Specific contribution to GENI outreach plan for Spiral 2. (9/30/10)

Playbook review by GPO, GENI projects related to operations and security, and other interested parties

Evaluate perfSONAR on ProtoGENI (ease of use, measurement system overhead, etc).

Complete LAMP framework prototype released. Deliver software, documentation and user manual.

Move broker to Cluster D clearinghouse, and make control of L2 (VLAN) connections in LEARN available via the ORCA control framework to other GENI users. (9/30/10)

Provide POC to GENI Prototype Response and Escalation team. (9/30/10)

Provide POC to Security team. (9/30/10)

Specific contribution to GENI outreach plan for Spiral 2. (/30/10)

A final report that includes discussion of (1) how to best expand GpENI internationally, given that it does not have international optical connectivity; (2) how to use international research networks (including JANET, GEANT2, and NORDUnet) to run GpENI infrastructure, as well as what is feasible beyond tunneling; and (3) the possibility of getting optical (or virtual optical) connectivity into selected international GpENI node clusters with the assistance of Internet2, DANTE, GEANT2, JANET, and SWITCH. The work will be done coordinating and sharing information with the other GENI projects that are studying federation.

Provide access to OpenFlow slivers in NLR for testing (by BBN, Stanford, and perhaps others).

Conduct end-to-end demonstrations and early experiments with other GENI sites. A November 2010 demonstration at the GENI Engineering Conference will be defined, integrated, and tested. NLR functions used in the demo should be demonstrated and stable by September 2010.

Improve system and regression test support in NOX software.

Publish NOX feature list with technical descriptions for software releases planned for 2011.

Move ORCA broker to the RENCI clearinghouse. (9/30/10)

Specific contribution to GENI outreach plan required for Spiral 2. (9/30/10)

Implement and provide release 2.3 of ORCA code to other Cluster D projects, including the following features: (9/30/10) 1) Computational substrate ontology 3: Resource description mechanisms and policies. Ontology-based resource description mechanisms integrated into ORCA core. Initial ontology for edge computational substrates. 2) Measurement substrate ontology 3: Resource description mechanisms and policies. Ontology-based resource description mechanisms integrated into ORCA core. Initial ontology for substrate measurement capabilities. 3) Ontology integration 3: Resource description mechanisms and policies. Ontology-based resource description mechanisms integrated into ORCA core. Integration of ontology resource handling mechanisms into ORCA core. 4) Policy development 3: Resource description mechanisms and policies. Ontology-based resource description mechanisms integrated into ORCA core. Development of resource provisioning policies based on ontologies. 5) In-depth Shibboleth integration 3: Identity management. Establish use of identity management system to authenticate principals and portals. Integrate with Shibboleth at the level of service manager and user tools. 6) Note: Additional release 2.3 features will be provided by ORCA/BEN project.

Now named: Bella 2.2

Deliver release 2.x ORCA code and documentation to GPO. (9/30/10)

Implement and provide release 2.3 of ORCA code to other Cluster D projects, including the following features: (9/30/10) 1) Better packaging 3: Simplified installation, config script auto-configuration, simple usability extensions, simplified certificate management. 2) Lease feature extensions 3: Enable fully implemented cancellations of leases prior to their expiration. 3) Note: Additional release 2.3 features will be provided by ORCA augmentation project.

Now named: Bella 2.2

Deliver release 2.x ORCA code and documentation to GPO (9/30/10)

Demonstrate GUI-based interface as alternative to SFI command-line interface.

Complete review of PrimoGENI 2.0 design document by ProtoGENI, GPO and any other interested parties.

Milestone: SPP: S2.b rspec

9 years late (09/30/10 00:00:00)

Develop RSpec for SPPs, enabling users to reserve fast paths and SPP interface bandwidth across nodes in an integrated way. 9/30/10

Purchase four Juniper M7i routers and install three of them at ProtoGENI sites on Internet 2 (9 mo). (Internet 2)

Develop standalone control software to virtualize the Juniper platform

(9 mo). (AT&T)

Demo TIED/GENIAPI Experiment (experiment spanning resources in DETER and aggregates(s) that are accessed through the GENIAPI).

WiMax base station installed and operational using ORBIT Management Framework (OMF), dependent on timely receipt of WiMAX base station and software from Rutgers. (9/30/10)

Redesign remote management/power system at Boulder to support WiMax equipment. (9/30/10)

WiMax base station installed and operational using ORBIT Management Framework (OMF), dependent on timely receipt of WiMAX base station and software from Rutgers. (9/30/10)

Install the WiMax base station kit and antennas, if available. (9/30/10)

Implementation and deployment of user trial nodes enhanced with Mobile Access Router (MAR).

Provide space and power for, and help support, the nodes recently installed in Salt Lake City, Kansas City, and Washington DC.

Review GMOC design documents and contribute to security designs for GMOC Spiral 2. GMOC deliverables are currently forecast for months 15, 18, 20 and 24, so review/contribution deadlines are months 13. 16, 18, and 22. Review/contribution summary for each deliverable should be posted on the GENI wiki. (October 31, January 31, March 31, and July 31)

Provide POC to GENI Prototype Response and Escalation team. (11/1/09)

Provide POC to Security team and provide input for security review in Spiral 2. (11/1/09-3/1/10)

  • Demonstrate distributed DSL core social routing services and FAITH social network transformation service.
  • Demonstrate perfSONAR on ProtoGENI with the goal of getting experimenters to use it.
  • Promote use of perfSONAR by experimenters
  • Capabilities to demonstrate include complete deployment of ORCA container at the University of Houston, including service manager, broker(s), and site authorities.
  • Enhance the iGems robotics testbed (and its associated sensor testbed) with better design and video streaming. Make them available for internal testing across two sites at UF and OSU.
  • Demonstration of PrimoGENI capabilities, which include the new infrastructure supporting large-scale network simulation and emulation on ProtoGENI clusters, the experimenter support that features a new integrated graphical interface for configuring, launching and visualizing PrimoGENI experiments.
  • Present plans for a mobility demo using basic WiMAX base station kit, including the ASN Gateway, and a Linux PC with Intel WiMAX modem card, or an upgraded WORKIT node with WiMAX modem card.
  • Present ParkNet mobility demo using WiMAX base station node, including the ASN Gateway, and a mobile ORBIT node, with WiMAX modem card.
  • Present plans for a mobility demo using WiMAX base station node, including the ASN Gateway, a Linux PC with Intel WiMAX modem card, or a WiMAX server/modem arrangement designed for your experiments.
  • Explain how to conduct a WiMAX site survey, to provide a WiMAX signal quality map, and build statistical models of the coverage of WiMax signals, based on local topology and building structure.
  • Present plans for a mobility demo using GENI (NEC) WiMAX base station node, including the ASN Gateway, and the user trial nodes enhanced with Mobile Access Router (MAR). In particular, explain plans for:
    • User trial nodes enhanced with Mobile Access Router (MAR), supporting WiMAX and other radio interfaces.
  • Document testbed and sample experiments
  • Includes updated OMF/OML code release and documentation through mytestbed.net, ParkNet code samples interfacing with OMF/OML
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Release of GBSN controller software including RF AggrMgr, ASN Gateway, ASNGW AggrMgr, virtual Base Station (vBS), and vBS AggMgr modules. Documentation to be updated and posted on GENI site.
  • Produce draft detailed outlines of Spiral 3 Security Design Reports, and list of security Points of Contact providing input for each project. Release to GENI community.

Develop a plan to incorporate the virtualized Juniper routers into ProtoGENI (11 mo). (AT&T and Kentucky -- with assistance of Utah)

  • Release a full set of design information for stand-alone cognitive radio system kit, including hardware and v0.1 software.
  • Design, manufacturing, testing and integration of infrastructure-class Phase II radio card featuring wideband operation, for use in stand-alone and infrastructure class cognitive radio platforms.
  • Initial version with monthly updates to software and documentation until Dec. 10. Will prioritize functionality provided based on needs of Keren and Ilia.
  • Tutorials/user guides and example programs for GENI experimenters wanting to use perfSONAR.
  • Export operational status information to the GMOC
  • Design modifications to GENI API 1.0 to support ABAC authorization credentials, and implement an integration of the BBN GENI API code with the ISI/Sparta ABAC library (current version) using this design. (Deliverables: a short design document describing the API modifications, and patches or a modified version of the GENI API reference code).

(Continues development of ABAC (Attribute Based Access Control) and integrate into the GENI API, emphasizing both function and usability.)

This consists of: '-Continuously running (to the extent possible) aggregate manager that supports the GENI API ,

  • Help pages for experimenters wishing to use GpENI resources,
  • Accept experimenter credentials from at least one GENI clearinghouse,
  • Provide operational status information to GMOC,
  • Participate in GENI operations as it pertains to the GpENI aggregate

Develop and demonstrate software tools to collect measurement data from virtual

Juniper routers (12 mo). (Kentucky and AT&T)

  • Automate key functions of setting up VLANs using the OpenVPN server. This includes:
    • Starting the OpenVPN server on the ops control machine at CMU
    • Registering the relevant nodes in the testbeds (private testbeds at CMU or public testsbeds elsewhere)
    • Transfering the OpenVPN information to the nodes
    • Having the nodes set up the VLANs and enable IPv4 connectivity. Ideally this would be done using a single command that takes as input the nodes that were allocated as a result of separate swap-ins of experiments on each testbed involved, i.e. the user would first swap in experiments on each testbed, and then set up the VLAN infrastructure to connect them.
  • Complete engineering plan for supporting GENI L2 and L3 connections for ProtoGENI, OpenFlow, SPP and ShadowNet using the 8 new 10Gbps and 5 existing 1 Gbps Internet2 connections in Internet2 Router PoPs
  • Guides and example code for developers of other I&M projects on exporting I&M data using the perfSONAR schema for data and meta-data.
  • Position paper on schema (esp. topology schema) for meta-data and Rspecs.
  • Show where you are in the I&M system architecture. If you span multiple parts of the I&M architecture, what are the interfaces between these parts?
  • Measurement data produced by your system conforms to the data/meta-data format agreed upon by the GENI I&M WG.
  • Buy, install and connect 10 Gbps interfaces at Juniper routers to GENI equipment in 4 Internet2 router PoPs. Support GENI testing and integration for new interfaces.

Complete GENI production deployment on Stanford campus and document per the GENI Aggregate Provider Agreement. Pursue signing agreement, subject to approval by Stanford IT department.

  • Purchase and distribute Quanta switches to all selected GENI campus participants.
  • Develop, test and release the reference implementation of the OpenFlow 1.1 draft specification.
  • Implement, test, and release a major Spiral 3 release to address existing Spiral 2 and Spiral 3 known bugs and requested features for Stanford-supported software in GENI campus deployments. This includes software provided by Stanford and by Stanfords GENI subcontractors. Currently this list includes FlowVisor, NOX and any other Stanford-recommended controllers, Indigo, SNAC, Expedient and Opt-In Manager.
  • Complete final report on The Quilt workshop and share results with the GENI community and Quilt members.
  • Install the fourth Juniper M7i router at the fourth ProtoGENI siteon Internet2 (Joint with Internet 2)
  • Release a package of ABAC rules and attributes usable with the above code that implements the current GENI API identity based authorization model within ABAC, for simple transition. . (Deliverable: a machine-readable file of rules and attributes usable with the code of milestone S3.a, with instructions for use).

(Continues development of ABAC (Attribute Based Access Control) and integrate into the GENI API, emphasizing both function and usability.)

  • A document describing the data and/or properties attributed to entities, and how that attribution is used, by other GENI projects.
  • Building on TIED Spiral 2 milestones S2.d and S2.f, and working with BBN engineers and the CFWG, develop and document a strawman specification for a GENI API that addresses integration and CF-independence issues identified in Spiral 2.

(Deliverable: a strawman specification for GEC10 discussion that is released to the control framework working group mailing list at least two weeks prior to GEC10 ).

  • More or less continuously operating aggregate manager, provide operational status information to the GMOC, support GENI operations as it relates to the BGPMux aggregate, user support available (e.g. web pages with documentation, tutorials, examples).
  • Deliver Aggregate Manager software.
  • More or less continuously operating aggregate manager that implements the GENI API
  • Recognize GENI credentials from at least 2 clearinghouses.
  • Export operational status information to the GMOC
  • GENI experimenter guide (web pages or document) for using CRON resources.
  • More or less continuously operating aggregate manager that implements the GENI API
  • Trust at least two GENI clearinghouses
  • Export operational status information to the GMOC
  • Tutorials, user guides, sample experiments for GENI experimenters using PrimoGENI resources
  • Release Spiral 3 Security Design Report on Spiral 3 project to the GENI community. This report will be based on analysis of security designs and operational issues from each Spiral 2 project or campus deployment, as represented by the software and documentation they contribute to demos and available GENI testbed resources as of November 2010 (GEC9). This review will include standard GENI APIs, such as the GENI AM API. Release to GENI community.
  • Buy, install and connect 4 additional 10 Gbps interfaces on Juniper routers to GENI equipment in Internet2 router PoPs. The GPO and I2 will determine PoP locations jointly. Support GENI testing and integration for new interfaces. (Depends on remaining ProtoGENI equipment being ready to install.)

Become familiar with the perfSONAR data models and representation.

Produce a document describing an approach for using the perfSONAR representation to store and archive measurement data (12 mo). (Kentucky)

  • Organize a workshop that brings together members of the GENI community working with attribution. Relevant projects include: NetKarma (GENI Provenance Registry), LEFA (Shibboleth) and ABAC (Attribute Based Access Control). The goal of the workshop is to start towards a path of a common set of terminology and principles related to attribution in GENI.
  • Demonstration of an experiment that highlights creation of the VLANs (as automated in Milestonea) with the operation of the individual testbeds. This uses the functionality in Milestonea as a baseline, extended to enabling the setup tool to automatically retrieve relevant information from the ops database for each of the testbeds.
  • Promote the CMU lab aggregate: Try to get experimenters to use it.
  • Integration of Phase II radio card with off-the-shelf components to develop infrastructure-class cognitive radio platform, including implementation of device drivers; validation with basic tests; and demonstration.
  • Integration of updated v0.5 software into stand-alone cognitive radio platform, and demonstration.
  • Demonstration of a GENI experiment that uses resources from CRON
  • Try to find GENI experimenters who would benefit from CRON resources
  • Demonstrate new DSL FAITH capabilities and usage on GENI. For example, demonstrate the ability to interactively replay social traffic over GENI with anonymity.
  • Demonstration of the entire workflow for using perfSONAR in GENI experiments
  • Promote perfSONAR on ProtoGENI---try to find at least one experimenter to use it and provide reasonable support.
  • Demonstration of the entire workflow of a GENI experimenter acquiring measurement resources, configuring them for the experiment, collecting and storing measurements, retrieving them for data analysis
  • Document/web page with instructions for experimenters on acquiring and using measurement devices. Include examples.
  • Measurement system deployed at least one backbone site and at BBN (deliver software and usable instructions for deploying at BBN)
  • Enhance iGems with Hyper-V server to support multiple sessions and simple sensor-actuator networks integrating sensors and robots.
  • Provide OMF features that support experiments which concurrently use resources from more than one testbed, and thus allow multiple WiMAX testbeds to be federated and used simultaneously by one experimenter.
  • Providing a good definition of the GENI AM API, and a reference implementation of the GENI AM, implement a version of the GENI AM API on the OMF AM, and demonstrate a researcher using it to gain access to OMF-Controlled resources.
  • Demonstration of a GENI experiment that uses PrimoGENI resources and resources from at least one other GENI aggregate
  • Workshop/tutorial on using PrimoGENI resources in GENI experiments
  • Promote use of PrimoGENI by experimenters
  • Present mobility demo/experiment using WiMAX base station node, including the ASN Gateway, a Linux PC with Intel WiMAX modem card (and/or upgraded WORKIT node, with WiMAX modem card), and a local instance of OMF/OML.
  • Present range and capacity measurement results of WiMAX base station node and Linux PC with Intel WiMAX modem card, and (if available) compare with calculated range and capacity.
  • Present mobility demo/experiment using WiMAX base station node, including the ASN Gateway, a Linux PC with Intel WiMAX modem card (and/or the mobile ORBIT node, with WiMAX modem card), and a local instance of OMF/OML.
  • Present range and capacity measurement results of WiMAX base station node and Linux PC with Intel WiMAX modem card, and (if available) compare with calculated range and capacity.
  • Capabilities to be demonstrated include all 7 operational WiMAX campus deployments with features shown in GEC9. A complex multi-site clean-slate mobility protocol demo will be shown at GEC10 highlighting the experimental capabilities of these sites. A full description of the demo, sample demo scripts, etc. will be posted on the ORBIT and GENI websites as part of experimental outreach.
  • Present a mobility demo using WiMAX base station node, including the ASN Gateway, a Linux PC with Intel WiMAX modem card, or the dual-mode vehicular nodes, supporting both WiFi and WiMAX, required for your experiments, and a local instance of OMF/OML.
  • Present results using tools to estimate WiMAX coverage in your Campus Vehicular Testbed (C-VeT), and compare with measurements of range and capacity in your testbed.
  • Present mobility demo/experiment using WiMAX base station node, including the ASN Gateway, a Linux PC with Intel WiMAX modem card, or a WiMAX server/modem arrangement designed for your experiments, and a local instance of OMF/OML.
  • Present results from your WiMAX site survey, and compare with measurements of range and capacity of WiMAX base station kit and Linux PC with Intel WiMAX modem card.
  • Present a mobility demo using GENI (NEC) WiMAX base station node, including the ASN Gateway and user trial nodes enhanced with Mobile Access Router (MAR), supporting WiMAX and other radio interfaces, and a local instance of OMF/OML.
  • Present range and capacity measurement results of WiMAX base station node and a Linux PC with Intel WiMAX modem card, or the user trial nodes enhanced with Mobile Access Router (MAR), supporting WiMAX and other radio interfaces, and (if available) compare with calculated range and capacity.
  • Capabilities to be demonstrated include those shown at GEC9 along with prototype-level operations and management interface for the WiMAX base station. Experimenter outreach will include support of specific projects resulting from the GENI Experimenters workshop held in June 2010.
  • Capabilities to be demonstrated include current status of GpENI sub-aggregates and plans for OpenFlow and ProtoGENI integration.
  • Accept experimenter credentials from a second GENI clearinghouse, subject to availability and operational status.
  • Initial release and demonstration of GpENI courseware: laboratory experiment developed for KU EECS 780 Communication Networks.
  • Continue outreach to find more experimenters and educators who might be interested in using GpENI resources for research/education via GpENI wiki.
  • Initial development of GpENI tutorial suitable for GEC10 or GEC11.
  • Release low-level command-line tools for a) creating and managing ABAC attributes in X.509 certificate format and b) interpreting ABAC authorization decisions in human-readable format. (Deliverable: release of code implementing these tools with notification to the control framework working group mailing list two weeks before GEC10 and demonstration of the system at GEC 10).

(Continue development of ABAC (Attribute Based Access Control) and integrate into the GENI API, emphasizing both function and usability.)

  • Produce draft detailed outlines of Spiral 3 Security Design Reports, and list of security Points of Contact providing input for each project. Release to GENI community
  • Obtain and install third Ciena CoreDirector for UMKC, based on Ciena commitment to obtain CoreDirector from I2.
  • Expand the scale of OpenFlow networks deployed at Clemson, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some Clemson campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Clemson run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Clemsons operational requirements for Spiral 3.
  • Expand the scale of OpenFlow networks deployed at Georgia Tech, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some Georgia Tech campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Clemson run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Georgia Techs operational requirements for Spiral 3.
  • Expand access to Internet2s backbone OpenFlow network by supporting site connections to and through the existing deployed switches. Internet2 will upgrade the Atlanta switch to match the other I2 deployed switches. OpenFlow connections may be made via ION, via dedicated interfaces, or via the GENI cross-connect(s) between Internet2 and NLR core OpenFlow networks. Internet2 will provide engineering support for new GENI sites that become active during Spiral 3, and will continue to support the OpenFlow sites that were active in Spiral 2. (Sites are responsible for their own circuits to reach the Internet2 OpenFlow core.)
  • Further integrate Internet2s network with GENI so that GENI users can request and use Internet2 OpenFlow networks for research. This goal requires that Internet2 run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at NLR and at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Internet2's operational requirements for Spiral 3.
  • Expand the scale of OpenFlow networks deployed at Indiana University, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some Indiana University campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Indiana Universitys operational requirements for Spiral 3.
  • Expand the scale of OpenFlow networks deployed at Rutgers University, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some Rutgers University campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Rutgers' operational requirements for Spiral 3.
  • Continue to integrate campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Stanford run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab)
  • Expand the scale of OpenFlow networks deployed at University of Washington, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some University of Washington campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets the Univeristy of Washingtons operational requirements for Spiral 3.
  • Expand the scale of OpenFlow networks deployed at University of Wisconsin Madison, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Integrate some University of Wisconsin Madison campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets University of Wisconsin Madisons operational requirements for Spiral 3.
  • Currently, they lack some features, calling conventions, etc. used by our V2 CM API (and the GENI AM API)
  • Integrate the virtualized Juniper router control software into the ProtoGENI control framework. (Joint AT&T and Kentucky -- with assistance from Utah)
  • Export operational status of your ORCA instance to the GMOC
  • Document describing how you can integrate with one other control framework (preferably ORCA). This means deployed GIMS systems are accessible by users of one other control framework.
  • Deploy and operate switches and PCs in 2 more Internet2 backbone POPs
  • Software modifications to ProtoGENI to support the upgrade from 1Gbps to 10Gbps interfaces in I2 at six ProtoGENI backbone sites.
  • Amazon Images with builds of Orca for the community and operational virtual machines with OpenVPN support for researchers. Documentation on how to use these AMIs will be provided.
  • Add support for user-level quotas and accounting for EC2, S3 and EBS.
  • Participate in developing a plan for monitoring and troubleshooting the L2 connectivity from NLR, through LEARN, and to each campus, utilizing the evolving commercial protocols and capabilities.
  • Update testbed documents and sample experiments
  • Updated OMF/OML code release and documentation through mytestbed.net
  • Documentation for running the enhanced alpha demonstration. Amazon images with builds of Orca for the community and operational virtual machines with OpenVPN support for researchers. Documentation on how to use these AMIs will be provided.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • 2-4 WiMAX campus sites released to external GENI experimenters, and corresponding web portals and end-user documentation posted/updated.
  • OMF/OML control and measurement support at each campus site
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Release of GBSN controller software including RF AggrMgr, ASN Gateway, ASNGW AggrMgr, virtual Base Station (vBS), vBS AggMgr, Switch AggMgr, and operations/management modules. Documentation to be updated and posted on GENI site.
  • Identify experiment and provide experiment with reasonable support related to use of instrumentation tools from this project.
  • Web site with documentation/tutorials/examples that will help experimenters using the instrumentation tools from this project.

Transition MAX GENI to an operational aggregate status. This should include:

  • Implementation of the latest GENI AM API
  • Trust at least two GENI clearinghouses
  • Export status information to GMOC
  • Operations support to GMOC as it relates to MAX GENI aggregate
  • More or less continuously operating aggregate manager, provide operational status information to the GMOC, support GENI operations as it relates to the MNG aggregate, user support available (e.g. web pages with documentation, tutorials, examples).
  • Deliver code and documentation
  • More or less continuously operating aggregate manager that implements the GENI API
  • Trust at least two GENI clearinghouses
  • Export operational status information to the GMOC
  • Tutorials, user guides, sample experiments for GENI experimenters us
  • Plan how this integration will be done, how the measurements will be setup and accessed by experiments that spans resources across these control frameworks.. Lead: HP Labs
  • Review plan with GPO and ProtoGENI PI (or designate)
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Document and implement procedures and provide support contacts that allow each OpenFlow site to support its GENI resources as outlined in the GENI Aggregate Providers agreement (URL provided in this section), while also complying with Internet2s security and network policies. Work with the GMOC to provide for multi-site support in GENI (e.g. Emergency Stop)

(http://groups.geni.net/geni/attachment/wiki/ComprehensiveSecurityPgm/Aggregate%20Provider%20Agreement%20v3.pdf)

  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Continuously available
  • Implements the GENI API
  • Provides experimenter support (web pages, online tutorials, etc)
  • Trusts all four GENI clearinghouses
  • Supports GENI operations as it relates to the UMLPEN aggregate
  • Online documentation/tutorials/examples
  • Deliver software and documentation.
  • Web pages that include sample experiments involving GENI and CRON resources to show the current CRON user community the benefit of becoming GENI experimenters
  • Advertise this web page to the current CRON user community
  • Updated experimenter guide for GENI experimenters using CRON resources
  • Give GMOC a special credential which allows them to view slices, slivers, users at ProtoGENI Clearinghouse, also give GMOC access to results of our daily tests for AM/CM status.
  • Develop instrumentation tools to make the collected information from the Juniper routers available to ProtoGENI users so they can observe the virtualized router behavior of their experiments.(Kentucky)
  • Define candidate procedures and provide support contacts with the intent to allow ShadowNet to support its GENI resources as outlined in the GENI Aggregate Providers agreement in Spiral 3. (Kentucky, AT&T and Internet2)
  • Repository of pre-configured AMIs for researcher experiments including networking support (openVPN) for GENI integration.
  • Preparation for Orca/Gush integration using Orcas management API, which is currently conforming to the ProtoGENI API. Report on the changes necessary for Gush to use this new API. Note: we are taking responsibility for the Gush development efforts as they pertain to our project. Gush PI Albrecht will consult with our project as needed.
  • Roadmap/cookbook on how other GENI clearinghouses could join InCommon. Document to include details on how the clearinghouse will use information from InCommon identity providers (architecture, API, etc.).
  • Plan for integrating TUF with Stork on PlanetLab and Orca (assuming Stork is available on Orca)
  • Description: A systems design paper that incorporates results from Year 1 and criteria from the OMIS working group. Solicit comments from GPO, GENI Operations and the GENI engineering community.
  • Demonstrate SCAFFOLD running on GENI aggregate (e.g., ProtoGENI)
  • Document on how a GENI experimenter/service builder can use SCAFFOLD.
  • GENI API can be used to set up Internet2 connections between the CRON testbed and other ProtoGENI aggregates.
  • Expand the scale of OpenFlow networks deployed at Georgia Tech, both in terms of the number of users able to access the networks and the number of switches deployed.
  • Capabilities to be demonstrated include integration with a control framework, transmission of experimenter attributes to aggregate managers, enforcement of local policy, and definition of attributes and policies using ABAC attribute management and policy editing tools.
  • In conjunction with our GSAT project and the selected control framework, we will participate in a distributed authentication and authorization workshop or tutorial, focused on the current state-of-the-practice of deployed mechanisms within GENI. Our contribution will focus on the status of ABAC mechanisms in GENI.
  • More or less continuously available aggregate manager that supports the GENI API
  • Export operational status to the GMOC
  • Able to stitch an end-to-end data plane in support of experiments that include CMU and non-CMU resources, such as the Utah ProtoGENI testbed,
  • Provide experimenter support (e.g. web pages with tutorials, etc.)
  • Trust all four GENI Clearinghouses and support GENI operations.
  • Use rspecs for definition of multi-aggregate experiment. This requires:
    • Use RSPEC/component manager for swap in on each public testbed, using existing software in ProtoGENI.
    • Use RSPEC/component manager for specifying experiments on CMUlab wireless testbeds, by extending existing software in ProtoGENI as needed.
    • Use RSpec/component manager for specifying the specifying the required inter-testbed connectivity, by extending existing software in ProtoGENI.
  • Demonstration of a GENI experiment and display of provenance information for data collected by experiment. Demonstration should include at least one new source of provenance information.
  • Get feedback from experimenters on the kinds of provenance information that will be useful.
  • Identify at least one other source of provenance information.
  • Demo TIED/GENIAPI Experiment using GENI API specification of milestone S3.e or subsequent refinement, implemented within BBN GENI API reference code. This milestone depends on ongoing collaboration between TIED and GPO developers. This milestone is expected to lead to follow-up work related to further GENI integration during the remainder of Spiral 3

(Deliverable: demonstration of an experiment using multiple GENI resources controlled by TIED through the CF-independent GENI API design of milestone S3.e.)

  • Demonstration of a GENI experiment that uses resources from CRON and at least one other GENI aggregate
  • Try to find GENI experimenters who would benefit from CRON resources
  • Tutorial on CRON

Work with OpenFlow, ORCA, ProtoGENI, and PlanetLab projects to collect and share more operations data on aggregates and clearinghouses. If the ORBIT project fields an aggregate manager based on OMF, collect and share their operations data as well. Display available data on GMOC portal. Maintain and revise portal as needed for integration in Spiral 3. [Document Spiral 3 expected and actual database entries for all 5 projects: March 31, 2011, Demonstrate access to collected data from each of the 4 initial projects: July 29, 2011.]

Work with I&M projects (primarily PerfSONAR related tools such as INSTOOLS, ShadowNet and LAMP) to allow experiments to provide measurement data for their slices to GMOC [Document expected and actual database entries for selected I&M projects: July 29, 2011]

  • Demonstrate updated MAX Aggregate Manager design, functions, and user interface. This should include demonstration of an operational workflow showing how a GENI researcher goes from initial request, to experiment topology instantiation, to operational support functions, to experiment termination.
  • Demonstrate trust of all four GENI clearinghouses
  • Organize workshop on network stitching (if the community feels a need for such a workshop). This workshop would be similar in focus and objectives to the GEC10 workshop.
  • Demonstrate VMI functionality on Alaska AM and one other AM.
  • Promote the Alaska AM for GENI experimentation.
  • Demonstrate new DSL FAITH capabilities and usage on GENI. For example, demonstrate the ability to allow others to repeat/perform DSL experiments.
  • Demonstration to feature a GENI experiment requesting/managing/querying measurements through OnTimeMeasure interfacing with other mature GENI tools/services (e.g., GUSH, ABAC, InsTools, Digital Object Registry)
  • Try to find experimenters who will use OnTimeMeasure
  • We expect to complete and deploy a new version of the software for the SPPs Network Processing Engine. This will more than double the computational resources available for application-specific packet processing, significantly increasing system throughput, and will provide substrate support for multicast.
  • GEC-11 Demonstration. We will demonstrate a new SPP fastpath for Forest, an overlay network designed to support real-time distributed applications, such as large-scale on-line virtual worlds. This will leverage the revised NPE software, specifically the multicast capabilities.
  • SPP Tutorial at GEC-11. We will provide a tutorial at GEC-11 for researchers interested in using the SPPs in experimental overlay networks. This will include background material on the system architecture, a detailed description of the user tools available for configuring SPPs, demonstrations of applications using the SPPs and a hands-on session.
  • Demonstration of initial OpenFlow deployment at UML
  • Tutorial on PEN for GENI experimenters
  • Find more users
  • Updated to document from Milestone a that incorporates:

(1) Information gathered at the workshop in Milestone b and (2) an examination of how these attributions might affect privacy, and other confidentiality or integrity properties, of the GENI entities involved.

  • Workshop on Attribution in GENI at GEC11 if the community feels it will be useful.
  • Demonstrate interoperability with all four GENI clearinghouses.
  • Bring at least one more BGP Mux site online.
  • Final software release of BGP Mux and aggregate manager. Deliver software.
  • Deliver tutorial.
  • Demonstration of a GENI experiment that uses CMU Lab wireless resources and resources from one other GENI aggregate. Demonstrate the experimenter workflow from requesting resources using rspecs to setting up and running an experiment.
  • Documents/web pages with tutorials/help pages and examples for GENI experimenters wishing to include CMU Lab resources in their experiments.
  • Promote the CMU lab aggregate: Try to get experimenters to use it. Piggyback on ProtoGENI tutorial to show how CMU Lab resources may be used by ProtoGENI experimenters.
  • Integration of multi-FPGA infrastructure-class cognitive radio platform; validation with basic tests; demonstration.
  • Integration of stand-alone cognitive radio system with v1.0 software; integration into ORBIT Management Framework; and demonstration.
  • Make your stand-alone cognitive radio system available for use by other GENI researchers
  • Initial integration of Gush to deploy coordinated experiments on Orca substrates through the Orca clearinghouse.
  • Deploy multiple ERM boxes (between 2 to 4) within suitable GENI infrastructures that can most take advantage of real-time optical layer measurement and cross-layer control. Potential GENI infrastructures include the BEN network located in North Carolina (where we have already been working during spiral 2) and the DRAGON/MAX network located in the greater Washington D.C. area.
  • Demonstrate the deployment of multiple ERM boxes (between 2 to 4) within suitable GENI infrastructures that can most take advantage of real-time optical layer measurement and cross-layer control.
  • Conduct an experiment using this ERM-enabled network involving non-GENI researchers. We have already initiated these projects with collaborators at AT&T Research and Lucent/Alcatel. Potential issues that ERM could address are:
    • Restoration and Protection: IP-layer restoration is becoming an important issue for the networking community. We can utilize the ERM box to monitor the IP traffic on the WDM network. ERM box can be enabled with functionalities to restore and protect IP router failures, by intelligently rerouting the traffic on the optical layer.
    • Energy Efficiency: The increasing number of networking devices in the present day Internet is causing a significant rise in the energy consumption. The ERM box can be used to enable traffic engineering (TE) based on energy-efficient routing. For example, the routing algorithm could minimize the number of IP ports used by enabling optical bypass.
  • Present a demo of an experiment using this ERM-enabled network involving non-GENI researchers. We have already initiated these projects with collaborators at AT&T Research and Lucent/Alcatel.
  • GENICloud aggregate is operational:
  • More or less continuously running aggregate manager that implements the GENI API
  • Recognize GENI credentials issued by all four clearinghouses
  • Export operational status to GMOC
  • Participate in GENI operations as it relates to the GENICloud aggregate.
  • Demonstration of a GENI experiment that uses resources from GENICloud and at least one other GENI aggregate.
  • Tutorial or workshop at the GEC for GENI experimenters wanting to use GENICloud resources. Appropriate experimenter guides/tutorials available online.
  • Outline or description of student assignments/coursework based on GENI and GENICloud.
  • Deliver software, documentation and experimenter guides.
  • Capabilities to be demonstrated include current status of GpENI sub-aggregates, status of NSF GENI resilience experiments, and OpenFlow subject to feasibility and availability from Ciena, Stanford, and GpENI.S3.d.
  • Accept experimenter credentials from all four GENI clearinghouse, subject to their availability and operational status.
  • Publication via wiki and demonstration of GpENI courseware -- laboratory experiment developed for KU EECS 780 Communication Networks
  • Continue outreach to find more experimenters and educators who might be interested in using GpENI resources for research/education via GpENI wiki.
  • Development of GpENI tutorial proposed for offering at GEC11
  • Obtain and install KSU CoreDirector, subject to availability and based on Ciena commitment to obtain CoreDirector from I2.
  • Demonstration at GEC10 or GEC11 of the distributed Hive Mind security system detecting and reporting a potential threat.
  • Workshop on Security Experimentation with GENI.
  • Promote Hive Mind: Engage with security projects such as GENI Security (Sparta) and Comprehensive Security for GENI (NCSA) projects and control framework projects.
  • Using existing driving case (IMF Year 1 experiment), integrate pS MP polling into IMF and demonstrate.
  • Create standard OS images that include IMF with pS integration deployable on ORCA (Eucalyptus) and ProtoGENI.
  • If a standard interface for managing measurement points from within the slice becomes available from perfSonar, demonstrate capability to manage measurement capabilities (e.g. modify frequency of measurements) from within the slice (from SILO).
  • Identify one or several networking researchers currently not funded by GPO whose research relates to cross-layer operation and could benefit from the experimental capabilities produced by the IMF project, and invite them to attend and possibly speak at GECs, with approval and coordination by GPO.
  • Only one of the following. Either:
  1. A demonstration of initial integration with a Solicitation 3 I&M project, or
  2. An Instrumentation Tools tutorial at the GEC for GENI experimenters and/or educators.
  • Capabilities to be demonstrated include:
    • Advanced WSNDL-based resource management (e.g., WSNDL-based embedding)
    • KanseiGenie experiment specification and control
    • ORCA-based identity management
  • Support OKGEMS in using KanseiGenie installer
  • Operational support for experimenters using Kansei and NetEye
  • Assist GMOC in accessing KanseiGenie operational status
  • Demonstration of the entire workflow for using perfSONAR in GENI experiments.
  • Demonstrate coordination of intra- and extra- experiment measurements.
  • Promote perfSONAR on ProtoGENI to GENI experimenters.
  • Operate the ORCA instance at Univ Houston to provide Eucalyptus cluster resources and connectivity, on any of the four campuses, on demand, to GENI experimenters.
  • Provide operational support, and export operational status to the GMOC
  • Implement the GENI AM API, and authenticate users via InCommon/Shibboleth identity providers, when these capabilities are provided by enhanced ORCA code
  • Demonstration of one of the GENI clearinghouses granting GENI experimenter credentials based on information provided by an InCommon identity provider.
  • Try to convince the other clearinghouses of the importance of federated identity. Organize workshop on federated identity management if there is a perceived need.
  • Demonstrate new MNG capabilities such as virtual namespaces within repy, and tab completion for seash. The MNG aggregate manager will recognize credentials from all four GENI clearinghouses.
  • Tutorial at the GEC with emphasis on GENI experimenters using MNG resources (in addition to other GENI resources) in their experiments.
  • Demonstration of the entire workflow of a GENI experimenter acquiring measurement resources, configuring them for the experiment, collecting and storing measurements, retrieving them for data analysis. If possible the experiment would include a measurement system at a backbone location.
  • Updated document/web page with instructions for experimenters on acquiring and using measurement devices. Include examples.
  • Measurement system available at Utah, Wisconsin, BBN, and at least one backbone site. If feasible, the measurement system will be accessible from a control framework other than ProtoGENI (preferably ORCA). [Of course deployment at more sites is preferred, e.g. at U. of KY.]
  • Integrate some Clemson campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Clemson run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Clemsons operational requirements for Spiral 3.
  • Integrate some Georgia Tech campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Clemson run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Georgia Techs operational requirements for Spiral 3.
  • Further integrate Internet2s network with GENI so that GENI users can request and use Internet2 OpenFlow networks for research. This goal requires that Internet2 run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at NLR and at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Internet2's operational requirements for Spiral 3.
  • Integrate some Indiana University campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Indiana Universitys operational requirements for Spiral 3.
  • Integrate some Rutgers University campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets Rutgers' operational requirements for Spiral 3.
  • Integrate some University of Washington campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets the Univeristy of Washingtons operational requirements for Spiral 3.
  • Integrate some University of Wisconsin Madison campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires that Indiana University run Aggregate Manager software (e.g. Expedient and Opt-In manager) that is integrated with software at other GENI campuses for both OpenFlow and other GENI aggregates (e.g. ProtoGENI and PlanetLab). This milestone is conditional on Stanford or the GPO providing Aggregate Manager software that meets University of Wisconsin Madisons operational requirements for Spiral 3.
  • Performance evaluation and analysis for cross-site experiments.
  • Make the robotics testbed accessible to other universities for education and training.
  • Capabilities to be demonstrated include a standardized operational interface on an OMF-controlled testbed for use in exporting operational status to the GMOC.
  • Demo experiment where Cluster D researchers get resources from protoGENI aggregates via GENI AM API v1.0 (or possibly protoGENI AM API) (using RSpec resource description)
  • Demo experiment where Cluster D researchers stitch L2 connectivity across Cluster C (protoGENI), and Cluster D sites
  • Demo experiment where Cluster D researchers include tools (e.g., GUSH) to help authorize, reserve and assign resources via ORCA SM API v1.0 XMLRPC interface to their SM (similar to protoGENI AM API, or possibly same as GENI AM API v2.0 )
  • Demo experiment where Cluster D researchers get resources from protoGENI aggregates via GENI AM API v1.0 (or possibly protoGENI AM API) (using RSpec resource description).
  • Demo experiment where Cluster D researchers stitch L2 connectivity across Cluster C (protoGENI), and Cluster D sites.
  • Demo experiment where Cluster D researchers include tools (e.g., GUSH) to help authorize, reserve and assign resources via ORCA SM API v1.0 XMLRPC interface to their SM (similar to protoGENI AM API, or possibly same as GENI AM API v2.0 )
  • Demonstration and tutorial on ProtoGENI experimenter tools.
  • Enforce mature set of policy rules for VICCI.
  • Document/web page on VICCI federation, resource allocation policies and mechanisms used to enforce these policies. Report at GEC.
  • PlanetLab Clearinghouse GUI live on PLC Web site.
  • Desktop GUI supports non-PlanetLab aggregates. Guide for aggregate providers on adding aggregate specific features to the GUI.
  • Demonstration of a GENI experiment that uses PrimoGENI Florida and PrimoGENI Brazil resources and resources from at least one other GENI aggregate.
  • Updated tutorials, user guides, sample experiments. Include experiments that may be used by an instructor in a class on networking/distributed systems
  • Workshop/tutorial on using PrimoGENI resources in GENI experiments
  • Promote use of PrimoGENI by experimenters.
  • More fine-grained resource controls to AM. As use of the aggregate starts to get heavy, more complicated policies will be needed to deal with resource contention.
  • Revisit CA model: Our current model has every federate acting as its own CA; this has a number of advantages, but has some disadvantages as well. We will study and report on (at the GEC) the benefits and drawbacks of using a hierarchical model with fewer roots.
  • Demonstration of use of ProtoGENI for experimentation.
  • Tutorial/workshop on experimentation with ProtoGENI.
  • Demonstrate: Raven with co-experiment #1 (Milestone b)
  • Demonstrate: DigDug notification service, OWL time series support.
  • Find a second GENI experiment that could benefit from one or of the Raven tools and try to get the project to use Raven (co-experiment #2)
  • Demonstrate the use of S3 by an experiment that spans multiple control frameworks. This includes admission control mechanisms. Lead: Purdue University
  • Promote S3MONITOR---try to find users for the S3MONITOR system Lead: Purdue University
  • Demonstration of a wide-area-accessible service running on a SCAFFOLD network, taking advantage of SCAFFOLD's load balancing and failover support. SCAFFOLD itself will be deployed on GENI, provided that appropriate GENI infrastructure (e.g., GENI racks) and GENI aggregates running on them (e.g., ProtoGENI) are available. (This milestone will not demonstrate support for multiple, separately-managed services running concurrently on a single SCAFFOLD instance, however, which will be addressed in year 3.)
  • Promote SCAFFOLD: Try to get experimenters interested in GENI)
  • Demonstration of TUF with Stork on PlanetLab and ORCA. Show how an experiment using vanilla Stork is vulnerable and then show how an experiment that uses Stork with TUF is no longer vulnerable to the same exploit.
  • New TUF features implemented: Client library implementation with selective trust delegation and key management; repository library and developer push mechanism with selective trust delegation and key management.
  • Promote TUF to GENI software developers
  • Work with Delaware to utilize the perfSONAR model and representation to store and archive the measurement data. (Kentucky with assistance from Delaware)
  • Incorporate latest Orca release using Shibboleth and/or additional experimental workflow tools and demonstrate them with our radar workflows.
  • Present mobility and/or application demos/experiments, showing support for multiple simultaneous experiments (slicing) of the GENI WiMAX base station node, and remote access by GENI users, utilizing experiment-controlled L2 (or OpenFlow) switch, and Virtual Base Station (vBS) server.
  • Present mobility and/or application demos/experiments, showing support for multiple simultaneous experiments (slicing) of the GENI WiMAX base station node, and remote access by GENI users, utilizing experiment-controlled L2 (or OpenFlow) switch, and Virtual Base Station (vBS) server.
  • Capabilities to be demonstrated include those shown at GEC10 for all WiMAX campus sites. Additional features to be shown at GEC11 are virtual base station and layer 2 OpenFlow access network programmability with GENI backbone access, where available. An illustrative multi-campus demo (features TBD) will be shown at GEC11.
  • All 7 WiMAX campus sites released to external GENI experimenters, and corresponding web portals and end-user documentation posted/updated.
  • Present mobility and/or application demos/experiments, showing support for multiple simultaneous experiments (slicing) of the GENI WiMAX base station node, and remote access by GENI users, utilizing experiment-controlled L2 (or OpenFlow) switch, and Virtual Base Station (vBS) server.
  • Present mobility and/or application demos/experiments, showing support for multiple simultaneous experiments (slicing) of the GENI WiMAX base station node, and remote access by GENI users, utilizing experiment-controlled L2 (or OpenFlow) switch, and Virtual Base Station (vBS) server.
  • Present a mobility demo using an additional WiMAX base station node, and user trial nodes enhanced with Mobile Access Router (MAR), supporting WiMAX and other radio interfaces, and a local instance of OMF/OML.
  • Present mobility and/or application demos/experiments, showing support for multiple simultaneous experiments (slicing) of the GENI (NEC) WiMAX base station node, and remote access by GENI users, utilizing experiment-controlled L2 (or OpenFlow) switch, and Virtual Base Station (vBS) server.
  • Full set of capabilities developed in the project to be demonstrated. This includes features shown at GEC10 along with more comprehensive operations/management capabilities and GENI control interface options including OMF, protoGENI, GENI API.
  • Demonstrate the real-time setup by GENI researchers of L2 (VLAN) connections between aggregates in Clusters C and D, via coordinated setups that include several sets of GENI resources within other networks, e.g., iGENI, C-Wave, Internet 2, NLR, BEN and/or CENIC networks, and/or the aggregates themselves.
  • Demonstrate the real-time setup by GENI researchers of L2 (VLAN) connections between a GENI aggregate and an aggregate within another research networks (e.g. FIRE).
  • Software with documentation
  • Installation guides
  • Experimenter guides
  • Release of Gush changes for Orca integration and related documentation.
  • DOME updated to allocation of WiMAX on buses, scheduling and execution of experiments that access the WiMAX link. (milestone shared with WiMAX project 1731).
  • Documentation for DOME updated.
  • Code snapshot of IMF, with documentation, used in above demonstration, as above.
  • Deliver latest stable version of this projects software, documentation and tutorial exercises including software demonstrated at GEC11.
  • Includes:
    • Final project report summarizing KanseiGenie design and capabilities as well as findings
    • V2.0 of KanseiGenie installer
  • Includes applicable handlers, ORCA task/resource assignment code, and guidelines for the GENI community towards creating a similar infrastructure integration using Cisco 3400s.
  • Latest stable version of MNG software and tutorial exercises including software demonstrated at GEC11.
  • Finish documentation and tutorial. Publish some preliminary results.
  • Updated OMF/OML code release and documentation through mytestbed.net
  • Updated online documentation/tutorials/examples
  • Deliver software and documentation.
  • Release demonstration code to community.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Final report including technical details of WiMAX base station kit and related software features. Updated code release corresponding to capabilities demonstrated at GEC11.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • WiMAX deployed on up to 4 buses
  • DOME updated to allocate WiMAX on buses, scheduling and execution of experiments that access the WiMAX link. (milestone shared with DOME project 1599)
  • Acquire and deploy the Wisconsin Mobility Services Engine into MadBed testbed, and document exposed API.
  • Update documentation of your WiMAX base station site
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Final report on GENI WiMAX base station including architecture, design details and performance validation results. Full code release and documentation with all major software features demonstrated at GEC11.
  • Implement the GENI AM API on ORCA aggregate, when these capabilities are provided by enhanced ORCA code
  • Deliver stable version software with documentation
  • Deliver user guides, tutorials, sample experiments
  • Provide an updated white paper on network stitching
  • Document via web pages the various options and techniques for network stitching
  • Participate in review discussion of this information via telecon.
  • Provide assistance to others who are interested in applying or using network stitching as part of their activities.
  • Deliver software with documentation
  • Deliver user guides, tutorials, sample experiments
  • Deliver software with documentation
  • Deliver updated guide for software developers planning on using TUF as their updater
  • Building on Task 2, the tool would automate swap in (of a predefined experiment) on each of the testbeds. This requires programmatic swap in and swap out of experiments on each testbed, based on user input on the experiment definition. Need to deal with timing of the activities on the different systems.
  • Deliver software with documentation
  • Deliver user guides, tutorials, sample experiments
  • Documentation for experimenters on how to collect and use provenance information.
  • NetKarma software and documentation.
  • Description of how additional source of provenance information identified in Milestone e will be used.
  • Software with documentation including instructions for installation and use. Lead: HP Labs
  • Document/web page describing how S3MONITOR can fit into at least one of the Sol. 3 I&M framework projects. Lead: HP Labs
  • Deliver latest stable version of Emulab software and documentation, containing all ProtoGENI software developed under this contract.
  • Deliver help documents/tutorials developed under this contract.
  • Release Spiral 3 Security Design Report on Spiral 3 projects to the GENI community. This report will be based on analysis of security designs and operational issues from all Spiral 3 projects or campus deployments, as represented by the software and documentation they contribute to demos and available GENI testbed resources as of July, 2010 (GEC11). This review will include standard GENI APIs, such as the GENI AM API, as well as other APIs that may be at various stages of maturity. This final release under the GSAT project will include guidelines for maintaining and evolving the developer community and operational community GENI security architecture to support the GENI testbed as national research infrastructure. Release to GENI community.
  • Review GMOC design documents and contribute to security designs for GMOC Spiral 3. Milestones to coincide roughly with GEC9, GEC10, GEC11. The milestones will be prior to the GEC where there is a need to coordinate and review a GMOC deliverable, or two weeks after the GEC to coordinate on action items and feedback gather by both projects during the GEC meeting. The overall goal of these milestones will be to ensure cross collaboration between GMOC and GSAT projects.
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Document and implement procedures and provide support contacts that allow each OpenFlow site to support its GENI resources as outlined in the GENI Aggregate Providers agreement (URL provided in this section), while also complying with Internet2s security and network policies. Work with the GMOC to provide for multi-site support in GENI (e.g. Emergency Stop)

(http://groups.geni.net/geni/attachment/wiki/ComprehensiveSecurityPgm/Aggregate%20Provider%20Agreement%20v3.pdf)

  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement, test, and release a second major release of software to address additional Spiral 3 known bugs and requested features for Stanford-supported software in GENI campus deployments. This includes software provided by Stanford and by Stanfords GENI subcontractors. Currently this list includes FlowVisor, NOX and any other Stanford-recommended controllers, Indigo, SNAC, Expedient and Opt-In Manager.
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Implement procedures and provide support contacts that allow each campus to support its GENI resources as outlined in the GENI Aggregate Providers agreement, while also complying with local campus IT policies. Work with the GMOC to provide for multi-campus support in GENI (e.g. Emergency Stop).
  • Paper laying out considerations for GENI designers, GENI operations, experimenters, aggregate providers and other stakeholders for supporting security experiments on GENI.
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings
  • Support multi-site GENI experiments over the course of Spiral 3. (Each OpenFlow campus that uses Internet2 will be conducting at least 4 experiments during Spiral 3.) Share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings. Meet regularly with the GPO to forecast and plan combined usage on the GENI networks
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings.
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings.
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings.
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings.
  • Support at least four multi-site GENI experiments over the course of Spiral 3, and share experiences and lessons learned with other GENI OpenFlow sites via the OpenFlow mailing list and GEC OpenFlow Campus meetings.
  • Updated version of document from Milestone c.
  • Hive Mind source code and documentation.
  • Report on the efficacy of the Hive Mind system including types of threats it is able to detect and a characterization of false positives/negatives generated.
  • Updated paper on Security Experimentation with GENI.
  • SCAFFOLD source code and documentation
  • Software and documentation for a service built on ""SCAFFOLD on GENI""
  • Updated guides/tutorials/scripts for GENI experimenters/service builders wishing to deploy own SCAFFOLD network on which to build/deploy own services.
  • Deliver VMI software and documentation for GENI experimenters.
  • AM is continuous availability, to the extent possible.
  • Experimenter help available (e.g. web pages and mailing list)
  • Operational status exported to GMOC
  • Support GENI operations as it relates to this aggregate.
  • Deliver working ABAC software and documentation. ABAC fully integrated with control framework software and is part of the control frameworks default distribution.
  • Updated plan based on feedback from the GECs and subsequent reviews with relevant stakeholders and the GPO.
  • Deliver working software and documentation of DSL FAITH over GENI so that other researchers can develop similar experiments.
  • Deliver software and documentation
  • Deliver documents/web pages tutorials/help pages and examples (updated since Milestone d if necessary) for GENI experimenters wishing to include CMU Lab resources in their experiments.

'-Interact with the ProtoGENI team to get feedback on the improvements suggested in Milestone c.

  • Study the new GENI Spiral 3 development and results, considering areas such as federation, additional ProtoGENI functions, etc.
  • Run initial experiments to exploit potential vulnerabilities in the selected area. Develop an initial experimentation plan for further vulnerability investigations following GENI Spiral 3 development.
  • Deliver a report on feedback, initial experiment results and a plan for further investigations, and possible software/scripts/documentation needed to repeat experiment.
  • Description: Updated version of document that incorporates comments on previous version and new issues discovered since publication of the previous version.
  • Release a full set of design information for stand-alone cognitive radio system kit, including hardware, v1.0 software and reference software implementations.
  • Release a full set of design information for multi-FPGA infrastructure-class cognitive radio platform kit hardware, and Phase II radio card hardware.

Build and populate a GENI operational contact database for each operational GENI aggregate. This database will be used for emergency stop and security incident response, which the GMOC will be providing in Spiral 3 (following OMIS procedure approvals). It may be used for other functions as well. Update and support the database throughout Spiral 3. [First database completed and Emergency Stop Procedure supported by GMOC: March 31 2011, Ongoing database and procedural support: September 31, 2011]

Support limited operations functions for specific projects during Spiral 3, in order to support their transition to the GMOC ConOps. Internet2 OpenFlow, NLR OpenFlow, and INSTOOLs have requested this support. Three anticipated functions are 1) Emergency Stop help desk [March 31, 2011], 2) Engineering Support Coordination (provisioning, demo readiness and operations) for I2 and NLR OpenFlow [July 31, 2011]; and 3) Pilot Project operations support for INSTOOLS. [September 30, 2011]

  • Make OpenFlow sub-aggregate capabilities available to experimenters, subject to feasibility plan from GpENI.S3.d and subject to availability of operational code from Ciena and Stanford and subject to OpenFlow GENI control framework capabilities from the GPO or GENI/OpenFlow community. Help documents on GpENI wiki as appropriate.
  • Expand access to Internet2s backbone OpenFlow network by supporting site connections to and through the existing deployed switches. Internet2 will upgrade the Atlanta switch to match the other I2 deployed switches. OpenFlow connections may be made via ION, via dedicated interfaces, or via the GENI cross-connect(s) between Internet2 and NLR core OpenFlow networks. Internet2 will provide engineering support for new GENI sites that become active during Spiral 3, and will continue to support the OpenFlow sites that were active in Spiral 2. (Sites are responsible for their own circuits to reach the Internet2 OpenFlow core.)
  • Support OpenFlow software used in GENI campus OpenFlow deployments through Spiral 3. Participate in Spiral 3 GEC demos with other OpenFlow sites and provide support to experimenters using Stanford OpenFlow resources and software.
  • Software package with detailed documentation for setup and operation with other mature sets of GENI software tools/services pertaining to Experiment Workflow, Security, Measurement, and Operations.

General availability of WDR wideband transceiver card

Tutorial featuring DiCloud software. The tutorial will demonstrate how to install and use DiCloud software to track billing for Amazon cloud resources. The tutorial will show experimenters how they can incorporate their own Amazon resources in GENI slices. We will also show DiCloud in operation as part of Orca experiments.

  • Work with GENI I&M projects to demonstrate integration of user-workspace features of version 1 MDA service with their tools.
  • Demonstrate long-term archive features of the version 1 MDA service.
  • Lead I&M discussion to complete definition of metadata schema for archived objects, including sharing policy.
  • Lead discussion with GENI I&M projects/experimenters using the version 1 MDA prototype, to identify and define a set of new and/or modified MDA capabilities/features desired for a version 2 MDA service.
  • a decentralized version of DSL FAITH, leveraging the GENI networking capability, to support social P2P applications such as Bit torrent
  • the Social-aware search engine on GENI (comparing to the page-rank approach of Google).
  • Participate in the GENI I&M effort, focusing on providing basic capabilities, and on extending the architecture to include messaging and pub/sub mechanisms.
  • Define, prototype, demonstrate and operate a GENI Messaging service, that operates in public IP space, to provide XML message routing services utilizing an XMPP server, plus pub/sub services following XEP-0060; show how multiple servers could be federated. (Goal 2-a,b)
  • Include an administrative and management interface to the GENI Messaging service. (Goal 3)
  • Define a GENI I&M Orchestration capability to manage I&M services/slivers all within one slice; use ORBIT Management Framework (OMF) software modules provided by NICTA, including the Experiment Controller (EC) and the Resource Controller (RC), that communicate using the GENI Messaging service. As proof of concept, develop OMF-style RC modules for one or more optical substrate devices. (Goal 6-a)
  • Define a GENI I&M Measurement Pub/Sub capability to transport event (or measurement) records; include software modules that collect the records, communicate using the pub/sub services in the GENI Messaging service, archive the records in a repository, search the records, and display the records.

  • Help plan ORCA Cluster roadmap with other projects, and define ORCA Cluster configuration including: sites, connectivity and services
  • Help plan ORCA Cluster connectivity with other projects
  • Continue to maintain plan for connectivity from LEARN ORCA clusters through LEARN to NLR backbone
  • Continue to operate the ORCA instance at UH to control clusters connected to LEARN
  • LEARN ORCA cluster capability demo: obtain a slice within the ORCA Cluster using resources stitched from ORCA sites at UH and RENCI, connected by NLR backbone, using GENI AM API, and run an application that exercises all resources.
  • Continue to provide outreach to experimenters at LEARN campuses

Complete on-campus experimental and production deployment plans for Spiral 4. All deployment, integration, and transition to production should finish in Spiral 4. Deployment plan should include information on types of GENI aggregates that will be supported and policies for access to those aggregates

  • Help plan ORCA Cluster services, operations, testing, capability demos and experiments with other projects
  • Begin plan for ORCA/GENI capability demos
  • Continue active participation in GENI design community, especially activities focused on interoperability, authorization and stitching
  • Plan ORCA Cluster roadmap with other projects, and define ORCA Cluster configuration including: sites, connectivity and services
  • Plan ORCA Cluster connectivity with other projects
  • Plan ORCA Cluster services, operations, testing, capability demos and experiments with other projects
  • Continue technical assistance to other ORCA Cluster projects (e.g., site setup; network control (e.g., bridging the LEARN network); actor registry maintenance enhancements for security and ease of use)
  • Demonstrate available ORCA site and service features, through Camano 3.1 release.
  • Demonstrate current ORCA GENI interoperability features using Omni client (At GENI AM API interface, support: use of GENI format credential issued from all current authorities; use of RSpecv2 in REQUEST message; use of RSpecv2 in MANIFEST return message)
  • Complete basic deployment plan for 1 additional WiMAX base station in Year 1, including access facilities and switches, plus associated servers, to realize a multi-cell/multi-sector MadBed WiMAX network testbed with a total of four sectors, in Madison, WI.
  • Apply to the FCC for experimental license, or utilize existing campus Educational Broadband Services (EBS) license. [Note: Rutgers needs to know the frequency band you will be using by 11/30/11 so that they can pace the order for Airspan base station hardware; you should receive Airspan base station hardware from Rutgers by 1/31/12. (2510 Lo: 2496MHz to 2570MHz) OR (2510 Mid: 2560MHz to 2630MHz) OR (2510 Hi: 2620MHz to 2690MHz)]
  • Complete basic deployment plan for 3 WiMAX base stations in Year 1, including access facilities and switches, plus associated servers.
  • Apply to the FCC for experimental license, or utilize existing campus Educational Broadband Services (EBS) license. [Note: Rutgers needs to know the frequency band you will be using by 11/30/11 so that they can pace the order for Airspan base station hardware; you should receive Airspan base station hardware from Rutgers by 1/31/12. (2510 Lo: 2496MHz to 2570MHz) OR (2510 Mid: 2560MHz to 2630MHz) OR (2510 Hi: 2620MHz to 2690MHz)]
  • Install and bring up an instance of OMF/OML in WiMAX base station/mobile station, and use for an experiment.
  • Install NetServ switch/router, to provide connectivity from the WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone
  • Complete basic deployment plan for 1 WiMAX base station in Year 1, including access facilities and switches, plus associated servers.
  • Apply to the FCC for experimental license, or utilize existing campus Educational Broadband Services (EBS) license. [Note: Rutgers needs to know the frequency band you will be using by 11/30/11 so that they can pace the order for Airspan base station hardware; you should receive Airspan base station hardware from Rutgers by 1/31/12. (2510 Lo: 2496MHz to 2570MHz) OR (2510 Mid: 2560MHz to 2630MHz) OR (2510 Hi: 2620MHz to 2690MHz)]
  • Complete range and throughput measurements using OMF/OML and bit torrent in WiMAX base station/mobile station, and share with other projects/experimenters.
  • Install L2 switch, to provide connectivity from the WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone
  • Demonstrate latest WiMAX base station software fixes and additions, including: ASN-GW code modified to be compatible with ubuntu 10.04; BTS parameter sets to optimize range and throughput; Mobile Station access list and data path destination in DB that is part of WiMAX RF AggMgr, with specified VLAN tag per mobile station; OGS login server, with scheduler.
  • Review list of planned WiMAX base station software fixes or additions with campus projects and experimenters.
  • Work with campus projects, GPO and experimenters to help define and implement advanced WiMAX experiments/applications, including GENI-wide experiments/applications, e.g., MobilityFirst
  • Complete basic deployment plan for 1 additional (3 total) WiMAX base stations in Year 1 at Rutgers, including access facilities and switches, plus associated servers, to support multi-cell/multi-sector operation.
  • Complete basic deployment plan for 1 additional (2 total) WiMAX base stations in Year 1 at UCLA, including access facilities and switches, plus associated servers, to support multi-cell/multi-sector operation.
  • Apply to the FCC for experimental licenses as needed at Rutgers and UCLA, to support multi-cell/multi-sector operation. [Note: Rutgers needs to know the frequency band you will be using by 11/30/11 so that they can pace the order for Airspan base station hardware; you should receive Airspan base station hardware from Rutgers by 1/31/12. (2510 Lo: 2496MHz to 2570MHz) OR (2510 Mid: 2560MHz to 2630MHz) OR (2510 Hi: 2620MHz to 2690MHz)]
  • Complete plan for updating NEC base station software to support the Airspan base station, developed under GENI projects 1657 and 1793, particularly the WiMAX RF AggMgr
  • Install and bring up an instance of OMF/OML in WiMAX base station/mobile station, and use for an experiment.
  • Install L2 switch, to provide connectivity from the WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone.
  • Install and bring up an instance of OMF/OML in WiMAX base station/mobile station, and use for an experiment.
  • Install L2 switch, to provide connectivity from the WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone
  • Install and bring up an instance of OMF/OML in WiMAX base station/mobile station, and use for an experiment.
  • Install L2 switch, to provide connectivity from the WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone
  • Complete basic deployment plan for 3 WiMAX base stations in Year 1, including access facilities and switches, plus associated servers, to provide a multi-sector WiMAX network (three sectors total) in Metro Detroit.
  • Apply to the FCC for experimental license, or utilize existing campus Educational Broadband Services (EBS) license. [Note: Rutgers needs to know the frequency band you will be using by 11/30/11 so that they can pace the order for Airspan base station hardware; you should receive Airspan base station hardware from Rutgers by 1/31/12. (2510 Lo: 2496MHz to 2570MHz) OR (2510 Mid: 2560MHz to 2630MHz) OR (2510 Hi: 2620MHz to 2690MHz) OR (3650: 3650MHz to 3700MHz)]
  • Help plan ORCA Cluster roadmap with other projects, and define ORCA Cluster configuration including: sites, connectivity and services
  • Help plan ORCA Cluster connectivity with other projects
  • Continue to operate the ORCA instance at Northwestern to control dedicated iGENI/GENI switches in real-time to provide L2 (VLAN) connections between GENI transport resources or aggregates, via L2 connections or tunnels.
  • Begin plan for the design, configuration, implementation, operation and monitoring of long-term iGENI infrastructure, including dedicated iGENI switches with appropriate functionality (e.g., equipped with features for VLAN tag mapping an L2 tunnel termination and/or OpenFlow features) and long-term (or scheduled) links, for transport between: current GENI backbone transport resources (e.g., Internet2 and NLR layer 2/Ethernet VLANs); current and planned GENI regional transport resources (e.g., BEN, CENIC, MREN, I-WIRE, and others); and/or other research networks (e.g. FIRE or JIST). This should be designed to serve current and planned GENI aggregates, who will typically be connected by GENI regional transport resources.
  • Help plan ORCA Cluster services, operations, testing, capability demos and experiments with other projects
  • Support TransCloud demonstration
  • Document/web page with 3-4 use cases for the GENI attribution framework
  • Organize a workshop on Clouds on GENI at GEC12.
  • Demonstration of GENICloud
  • Plan for developing coursework/exercises based on using GENICloud resources and GENI: Schedule for developing coursework, level of coursework (graduate class, undergrad class, pre-school, etc), schedule for trying out coursework in a class, etc
  • Support the use of Gush for the DiCloud demo and tutorial at the GEC.
  • Gush distribution includes Gush source with instructions for building and installing on Ubuntu and MacOS; binary distribution for Ubuntu.
  • Federation: Evaluate the design of the GENI clearinghouse and the implications of federating with this clearinghouse. Present evaluation at GEC.
  • ABAC: Evaluate ABAC as the authorization mechanism for GENI. Present evaluation at GEC.
  • Track and implement changes to the GENI AM API.
  • Start dialog with GENI rack teams to understand their needs related to integration with the ProtoGENI CF.
  • Demonstration of Serval.
  • Initial version of Serval running on GENI resources accessible by most GENI experimenters.
  • Written plan for integrating VMI into Eucalyptus cluster software being developed by RENCI.
  • At least one of the Alaska resources federated with GENI: Aggregate manager running the GENI AM API available and help pages for experimenter using the resource published. Agree to the GENI Aggregate Provider agreement for the federated resource. An email to the GPO saying you agree to follow this agreement with respect to this resource will suffice.
  • Demo of a GENI experiment that uses this Alaska resource and resources from at least one other GENI aggregate. Demo to emphasize what about the resource makes it interesting for experimenters (resources connected by low-bandwidth links or high-latency links or something else).
  • Work with the GENI I&M community and the NetKarma project to define the schema for the ""measurement data object descriptor"". Map this schema to the perfSONAR metadata that is registered with the I&M Lookup Service. Present design at GEC12.
  • Support the OnTimeMeasure project's task of understanding LAMP/perfSONAR tools and developing a proposal for implementing infrastructure measurement slices in GENI backbone and access networks. Provide LAMP images for creating infrastructure measurement slices in the protoGENI environment.
  • Participate in the discussions at the GEC on the use of ABAC as the authorization mechanism for GENI.
  • Demonstrate perfSONAR at GEC 12
  • Participate in the GENI I&M effort. Support the definition of the schema for the GENI ""measurement data object descriptor"".
  • Develop a written proposal for implementing infrastructure measurement slices in GENI backbone and access networks. Work with the LAMP project to understand the LAMP/perfSONAR tools and show how they may be used for infrastructure measurement. Present proposal at GEC.
  • Demonstrate the capability of custom metric integration via web services for GENI experimenters
  • Support GENI experimenters using OnTimeMeasure (ongoing).
  • Tutorial based on Flack for experimenters new to GENI.
  • Demonstration of the use of ProtoGENI tools (command line and/or Flack) to set up and run experiments on GENI.
  • Flack enhancements such as undo/redo functions, UI improvements such as placement of buttons to better reflect workflow, icons that are self-explanatory, etc.
  • Plan for making Flack extensible

The code release and documentation will document the tutorial for other users that could not attend in person.

Document definition of version 2 MDA service; include: assignment to experimenters via GENI AM API; enforcement of metadata schema on archived objects; access to archived objects controlled by policy included in metadata.

  • Publish documentation on GENI Messaging service, plus GENI I&M Orchestration and GENI I&M Measurement Pub/Sub capabilities.
  • Provide an up-to-date installation, configuration and feature guide to all available software
  • Update documentation of LEARN ORCA clusters
  • Update GENI research plan by experimenters at LEARN campuses
  • Document procedure and scripts, etc., for LEARN ORCA cluster capability demo

Publish requirements and sketch of plan for ORCA/GENI capability demos

Provide up-to-date installation, configuration and feature guides to all available ORCA software

Update software and documentation of your WiMAX network testbed.

Update software and documentation of your WiMAX base station site.

  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base station and a Linux PC with Intel WiMAX modem card as the mobile station.
  • Document API of NetServ switch/router, and its use in WiMAX base station.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository

Update software and documentation of your WiMAX base station site.

  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base station and a Linux PC with Intel WiMAX modem card as the mobile station.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Release latest WiMAX software and documentation.
  • Document planned WiMAX base station software fixes or additions.
  • Provide support to help WiMAX campus sites meet their Spiral 4 goals, and identify fixes or additions needed in WIMAX base station software.
  • Provide support to help WiMAX experimenters meet their goals, and identify fixes or additions needed in WiMAX base station software
  • Update software and documentation of your WiMAX base station sites.
  • Order 10 Airspan Profile C base station kits (one sector each), including base station, antenna and network management system, and deliver (by 1/30/12) to existing and new campus sites, including: 1 to Rutgers; 1 to UCLA; 3 to Clemson; 3 to Wayne State; 1 to Wisconsin; and 1 to Michigan
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base station and a Linux PC with Intel WiMAX modem card as the mobile station.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base station and a Linux PC with Intel WiMAX modem card as the mobile station, and compare with Airspan installation run by university IT department.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site as required.
  • Document range and throughput measurement results of WiMAX base station and your brick node equipped with Intel WiMAX modem as the mobile station.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base station and a Linux PC with Intel WiMAX modem card (or Mobile Access Router (MAR)) as the mobile station.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site
  • Publish requirements and sketch of plan for design, configuration, implementation, operation and monitoring of long-term iGENI infrastructure
  • Continue to use the GENI wiki to report current status (requested, scheduled, active, disconnected..) of long term (or scheduled) connections by iGENI staff between GENI transport resources or aggregates, or between aggregates or transport resources and dedicated switches.

Complete rack design, software specification and implementation documents. Review design with GPO and other interested GENI participants and finalize for initial deployment. Ensure that initial deployment design will support experiments that include compute and OpenFlow network resources locally and in other existing GENI AM API compliant aggregates. Establish and maintain shared software repositories, configuration and release management, and deployment support resources for the distributed team members

Upgrade to the latest stable Orca release. Maintain operational Orca site authority with 5 Eucalyptus servers.

Discuss and clear plan for integrating TUF with identified project(s) with the project and the GPO. Integration to be in a test/demo branch (not production branch) of the project unless explicitly agreed to by the project and the GPO.

Host one workshop in partnership with the Internet2 Joint Techs Workshop

Complete configuration, installation and test of alpha rack software and hardware. The GPO will provide a GENI test suite consistent with the finalized design, but the general expectations for this rack include the following items: The alpha rack should support the GENI AM API, GENI standard RSpecs, federation with pgeni.gpolab.bbn.com as a slice authority/clearinghouse, basic shared monitoring and log support for GMOC, basic OpenFlow network control for layer 2 and layer 3, and one or more basic OS images for compute resources in the rack. Support remote access to alpha rack for development partners and GPO

Update topology model to Rspec version 3 and AM API

Identify use cases / concept of operations, in cooperation with the GIMI project

Identify use cases and concept of operations, in cooperation with the IMF and GIMI projects

Active IP network performance measurements, made between nodes within the slice

A persistent infrastructure measurement slice, that provides active and/or passive measurements of the infrastructure included within the slice

Define v0.5 I&M use cases for experiments and infrastructure monitoring, in collaboration with I&M teams, the GPO, experimenters and operators/GMOC

Description of ontology extensions to cover measurement point resources (software and hardware). This will be integrated into ORCA per the ORCA-AUG SOW

Identify use cases and concept of operations for GENI messaging services, in cooperation with the IMF and GEMINI projects

Deliver v0.5 definition of GIMI architecture and software modules for year 1, documented on GIMI web page

  • Fixing of current bugs affecting client apps or user's interpretation of data
  • Fixing of current deployment and user development issues
  • New features to improve measurement reporting and future analysis
  • New features to ease current usage and enable future features
  • Improved documentation

Finalize cross-control-framework vocabulary based on feedback from GEC12 and ongoing discussions. Deliverable is a document describing the vocabulary and semantics of attributes that federations will accept.

Present two (or more) standard authorization policies in ABAC that can act as a basis for control framework federation. Integrate ABAC policy generation and enforcement into two slice authorities and two aggregates. Demonstrate the generation of assertions by Slice Authority that match the policy finalized in S4.d. Deliverable is a document and machine-readable representation (and customization instructions) for the standard policies.

Demonstrate prototype policy management tools that enable system managers, resource owners, and other stakeholders to define and understand GENI authorization policies. These policies will be presented graphically in terms of high-level objectives and shared cross-framework vocabulary. The policies will then be instantiated as ABAC credentials and used directly by services. Deliverable is a demonstration of the tools at GEC13 and access to the code.

  • Vet use cases with select stakeholders and revise if necessary.
  • Define requirements for the framework based on discussions with stake holders

Demonstrate personalized Nowcasting experiments via DiCloud. Nowcasts are highly accurate forecasts 2-30 minutes into the future. Demonstrate on-demand Nowcasts using GENI resources for the Amherst area.

Demonstrate both user-workspace and long-term archive features of a prototype version 2 MDA service

  • Publish first version of quick start guide completed
  • Publish first set of at least three model experiments

Define MeasurementDataObjectDescriptor (MDOD) schema, plus naming of objects and object registry, in collaboration with I&M teams and the GPO

Develop reference v1.0 experiment control tools based on OMF and Gush (including OMNI) and document the interfaces, protocols, and APIs of these tools, in collaboration with I&M teams and the GPO

  • WiMax
  • LEARN/BEN layer 0,1 or 2 real-time measurements
  • Sensor network (radars, power monitors)
  • Measure DiCloud workflow

Compare available technology and prototypes for GENI messaging services, in cooperation with the IMF and GEMINI projects

Decide whether GENI Event Messaging Service being developed for GEMINI project could be used by GIMI tools

Agree on v1.0 definition of GIMI architecture and software modules for year 1 with the GPO, and document on GIMI web page

Identify necessary mappings between iRods metadata catalog information and MDOD

MDOD will be created and edited as part of measurement orchestration, to be completed in Year 2

  • Nominal v1.0 target aggregate is ORCA and ExoGENI racks; both servers and VMs; when VMs have private IP addresses, make use of RENCIs proxy mechanism, which basically works like an automated NAT.
  • GIMI tools will come with an image; create template images with a basic configuration of tools which can be used and modified by other experimenters.
  • GIMI tools will be configured via OMF.

Develop use cases and best practices for Experimenter Portal Service, and document (based on LabWiki, Maxs portal)

In cooperation with the GEMINI project

Goal is to have one portal service support both GIMI and GEMINI tools.

  • Ideally across at least two GIMI institutions
  • Identify/document the critical iRods microservices needed to support GENI.
  • Identify/document mechanisms to map GENI authorization onto iRods datagrid.
  • Share with GEMINI project
  • Incorporate Gush into a class taught at Williams College.
  • Gush demo at GEC13.
  • Gush updated to Omni Version 1.4 or later. (Current Omni release is v. 1.4.)
  • Nebula updated to track changes to Gush.
  • Include entity authentication for entities registered to your GENI Messaging service (XMPP server), using SASL and certificates; public key certificates for each entity can be stored locally, or retrieved from a registry. Generating certificates, or certifying, is not within the scope; the scope includes the capability to receive such certificates and store/retrieve in/from a registry. (Goal 4)
  • Define the issues related to the need for providing a resource assignment mechanism (using the GENI AM API) for users (experimenters and operators) to add pub/sub nodes within the GENI Messaging service, and manage them. Such issues include considerations of authority to create, modify and delete such nodes, to publish and subscribe to them, articulating what managing implies, relative merits of providing such a service as part of GENI Messaging Service or asking users to provide it themselves on their own slice, etc. (Goal 5)
  • Prototype and demonstrate a GENI I&M Orchestration capability to manage I&M services/slivers all within one slice; use ORBIT Management Framework (OMF) software modules provided by NICTA, including the Experiment Controller (EC) and the Resource Controller (RC), that communicate using the GENI Messaging service. As proof of concept, develop OMF-style RC modules for one or more optical substrate devices. (Goal 6-b)
  • Prototype and demonstrate a GENI I&M Measurement Pub/Sub capability to transport event (or measurement) records; include software modules that collect the records, communicate using the pub/sub services in the GENI Messaging service, archive the records in a repository, search the records, and display the records. (Goal 9-b)
  • LEARN ORCA cluster capability demo: obtain a slice within the ORCA Cluster using resources stitched from ORCA sites at UH, Rice and RENCI, connected by NLR backbone, using GENI AM API, and run an application that exercises all resources.
  • Continue to provide outreach to experimenters at campuses connected to LEARN
  • Add traffic monitoring to the switches that provide L2 (VLAN) connections between GENI backbone and local clusters, and forward monitoring information for display to the local operator (LEARN) and to the GMOC.

ORCA cluster capability demo: obtain a slice within the ORCA Cluster using resources stitched from multiple ORCA sites, connected by backbone domain, via GENI AM API, configure using GUSH, and run application that exercises all resources.

  • Continue active participation in GENI design community, especially activities focused on interoperability.
  • Review planning decisions with other ORCA Cluster projects
  • Continue technical assistance to other ORCA Cluster projects
  • Demonstrate available ORCA site features, through Dungeness 4.0 release
  • Demonstrate current ORCA GENI interoperability features using FLACK, GUSH and OMNI clients (At GENI AM API, support use of RSpecv2 in ADVERTISEMENT return message)

Complete installation plan for 1 additional WiMAX base station, including access facilities and switches, plus associated servers, and begin installation, in your WiMAX network testbed.

Complete installation plan for 3 WiMAX base stations, including access facilities and switches, plus associated servers, and begin installation

  • Operate the WiMAX base station using OMF, and demonstrate access by users at multiple sites to experiments/applications over the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station/mobile station using OMF/OML, to provide login access to local (and optionally remote) GENI experimenters.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Complete installation plan for 1 WiMAX base station, including access facilities and switches, plus associated servers, and begin installation.
  • Deploy basic Infinity framework on GENI resources, and evaluate performance of storage options.
  • Operate the WiMAX base station using OMF, and demonstrate access by users at multiple sites to experiments/applications over the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station/mobile station using OMF/OML, to provide login access to local (and optionally remote) GENI experimenters.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Demonstrate latest WiMAX base station software fixes and additions, including: support for GENI AM API as an adjunct to the OMF login server (in cooperation with GPO)
  • Review list planned WiMAX base station software fixes or additions with campus projects and experimenters.
  • Work with campus projects, GPO and experimenters to help define and implement advanced WiMAX experiments/applications, including GENI-wide experiments/applications, e.g., MobilityFirst
  • Complete installation plan for 1 additional (3 total) WiMAX base stations at Rutgers, including access facilities and switches, plus associated servers, and begin installation.
  • Complete installation plan for 1 additional (2 total) WiMAX base stations at UCLA, including access facilities and switches, plus associated servers, and begin installation.
  • Demonstrate WiMAX RF AggMgr software that supports Airspan base station, including these functions: ability to set and restore base station parameters; Mobile Station access list and data path destination in DB, with specified VLAN tag per mobile station.
  • Operate the WiMAX base station using OMF, and demonstrate access by users at multiple sites to experiments/applications over the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station/mobile station using OMF/OML, to provide login access to local and remote GENI experimenters. -
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Operate the WiMAX base station using OMF, and demonstrate access by users at multiple sites to experiments/applications over the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station/mobile station using OMF/OML, to provide login access to local (and optionally remote) GENI experimenters.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Install L2 switch, to provide connectivity from the WiMAX base station to the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications as required.
  • Operate the WiMAX base station/mobile station using DOME, to provide login access to local (and optionally remote) GENI experimenters.
  • Complete and demonstrate an advanced mobility and/or application experiment using DOME, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Operate the WiMAX base station using OMF, and demonstrate access by users at multiple sites to experiments/applications over the GENI Internet 2 backbone.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station/mobile station using OMF/OML, to provide login access to local (and optionally remote) GENI experimenters.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station capabilities, plus the Mobile Access Router (MAR) as mobile station, and share with other projects/experimenters

Complete installation plan for 3 WiMAX base stations, including access facilities and switches, plus associated servers, and begin installation

  • Lead the planning with other GENI WIMAX projects that will require handover, or can contribute handover technology, on how to realize handover at GENI WIMAX sites, and report at the GENI WiMAX deployment meeting. Those projects requiring handover include: Clemson, Wayne State and Wisconsin. Those projects that can contribute handover technology include: Rutgers WINLAB and Wisconsin
  • Add traffic monitoring to dedicated iGENI/GENI switches that provide L2 (VLAN) connections between GENI transport resources or aggregates, and forward monitoring information for display to the local operator (Northwestern) and to the GMOC. Consider approaches currently used by other networks, e.g. GLORIAD.
  • Review the first draft of a plan for the design, configuration, implementation and operation of long-term iGENI infrastructure
  • ORCA infrastructure performance monitoring demo: obtain a slice within the ORCA Cluster using resources stitched from multiple ORCA sites, install LAMP/perfSONAR network performance monitoring software in the slice, evaluate network performance, and register data for use by operators and experimenters.

Demonstrate stitching with the CRON aggregate using the ION service.

  • Demonstrate the use of LAMP/perfSONAR tools for making measurements in the GENI backbone and access networks.
  • Propose and deliver a plan for evaluating the performance of GENIs backbone and access networks that may be carrying non-IP traffic. Present plan at the GEC.
  • Deliver a plan for INSTOOLS-Flack software integration of OnTimeMeasure. Plan must be reviewed by the INSTOOLS and Flack projects by this milestone date.
  • Support GENI experimenters using OnTimeMeasure (ongoing).
  • Demonstration of the use of ProtoGENI tools (command line and/or Flack) to set up and run experiments on GENI.
  • Demonstration of Flack extended with a service/aggregate specific PlugIns. Documentation for PlugIn developers.
  • Additional Emulab frontend features ported to ProtoGENI including dynamic control of delay nodes and the Emulab event system
  • Federation: Evaluate the design of the GENI clearinghouse and the implications of federating with this clearinghouse. Present evaluation at GEC.
  • ABAC: Evaluate ABAC as the authorization mechanism for GENI and the implications of implementing ABAC in PlanetLab.. Present evaluation at GEC. Participate in decision about whether ABAC should go forward as the authorization mechanism for GENI.
  • Track and implement changes to the GENI AM API.
  • Sface: Demonstration and/or tutorial at the GEC that illustrates the use of Sface to support the experimenter workflow. Demonstration/tutorial will include experiments that use resources from PlanetLab, ProtoGENI and GENICloud. (Or other resources in consultation with the GPO.)
  • Support GENI Rack demos that integrate with the ProtoGENI control framework
  • PrimoGENI demo at GEC 13 that shows an experiment spanning PrimoGENI resources in Florida and Brazil. Experiment in demo will be set up and managed using one of the GENI experimenter control tools: Flack, Omni, Gush or Sface.
  • PrimoGENI aggregates in Brazil implement the GENI AM API
  • Identification of additional resources in Brazil that might be candidates for federation with GENI.
  • Purchase all necessary hardware acquired for set up OpenFlow
  • Federation: Evaluate the design of the GENI clearinghouse and the implications of federating with this clearinghouse. Present evaluation at GEC.
  • ABAC: Evaluate ABAC as the authorization mechanism for GENI. Present evaluation at GEC. Participate in decision about whether ABAC should go forward as the authorization mechanism for GENI.
  • Track and implement changes to the GENI AM API. Release updated Reference Component Manager implementation that implements this API.
  • Support GENI Rack demos that integrate with the ProtoGENI control framework
  • Serval running on GENI resources accessible by most GENI experimenters.
  • Serval user guides/examples published online.
  • Demonstration and/or tutorial on the use of Serval by GENI experimenters.
  • Demonstration of TUF integrated into an updater used by at least one GENI project identified in Milestone 2.
  • Demonstrate private update retrieval feature of TUF.
  • Find other GENI projects that could benefit from TUF.
  • Initial demonstration of VMI in a Eucalyptus cluster environment. This does not have to be integrated with ORCA nor does the information collected have to be reported using perfSONAR compatible interfaces.
  • Second Alaska resource federated with GENI: Aggregate manager running the GENI AM API available and help pages for experimenter using the resource published. Agree to the GENI Aggregate Provider agreement for the federated resource. An email to the GPO saying you agree to follow this agreement with respect to this second resource will suffice.
  • Publish status of resources to the GMOC.
  • Demo and/or tutorial directed towards GENI Experimenters on using Alaska resources for experimentation. Emphasize unique nature of resources that would make them attractive to experimenters

Integration of stand-alone cognitive radio system with v1.0 software; integration into ORBIT Management Framework; and demonstration

  • Tutorial for GENI experimenters on the use of the CRON testbed.
  • Help pages and user guides for GENI experimenters using CRON resources.
  • Prototype of tree-mode VLAN stitching using the API defined by ISI
  • Virtualization model for GENICloud resolved (containers vs. para-virtualization vs. hybrid)
  • GENICloud is an operational aggregate: It implements the GENI AM API, recognizes GENI credentials issued by a GENI slice authority, appropriate experimenter help pages/user guides are available, publish status information to the GMOC, agree to the GENI aggregate provider agreement (email agreement is sufficient).
  • Outline of coursework that includes a description of each exercise based on GENI and GENICloud and the objective of the exercise.
  • TransCloud established and operational. Documentation online for Transcloud users and for cloud operators wishing to participate in TransCloud.
  • Demonstration of a GENI experiment that uses GENICloud resources
  • Develop a written plan for using ABAC to authorize access to data collected by PerfSONAR MPs.
  • Participate in the discussions at the GEC related to deciding if ABAC will go forward as the authorization mechanism for GENI.
  • Work with the GENI I&M community and the NetKarma project on the definition of GENI ""event records"".
  • Support the efforts of the I&M working group and the GPO to define I&M use cases for experiments.
  • Support the efforts of the I&M working group and the GPO to define I&M use cases for infrastructure monitoring
  • Support the efforts of the I&M working group and the GPO to define the requirements for a messaging service to be used by GENI I&M systems.
  • Provide LAMP images for creating infrastructure measurement slices in the ORCA environment.
  • Support the OnTimeMeasure project in its demonstration of the use of LAMP/perfSONAR tools for making measurements in the GENI backbone and access networks. Provide necessary LAMP images needed for this demonstration

The documentation and code release will detail how to run the on-demand Nowcasting experiment in our demonstration for external GENI users.

Release prototype version 2 MDA service for integration and use by projects/experimenters, resources permitting.

  • Work with I&M teams and the GPO to define and document a defined range of GENI environments, into which I&M tools can be successfully deployed, including: a selected set of aggregates, accessed by specified interfaces/protocols/APIs, using a selected set of experiment management and measurement orchestration tools
  • Define and document v1.0 GEMINI architecture, service components, interfaces and measurement data schemas, in cooperation with I&M teams and the GPO.

Modifications to allow local UNIS to register with global UNIS

To support deployment into a defined range of GENI environments

To support the flexible deployment of I&M services onto selected nodes, and the flexible configuration of I&M measurement points, including those for basic active network measurements, at each measurement node

Compare available technologies and prototypes, in cooperation with the IMF and GIMI projects

  • Update documentation on GENI Messaging service, plus GENI I&M Orchestration and GENI I&M Measurement Pub/Sub capabilities.
  • Provide an up-to-date installation, configuration and feature guide to all available software
  • Update documentation of LEARN ORCA clusters
  • Update GENI research plan by experimenters at LEARN campuses
  • Document procedure and scripts, etc., for LEARN ORCA cluster capability demo

Document procedure and scripts, etc., for ORCA cluster capability demo

  • Provide up-to-date installation, configuration and feature guide to all available ORCA software
  • 4.0 ORCA core features (Robust error handling with error reporting to users; Group allocations; Multi-point vlans; Improved advance reservations; Robust slice modify support; Lightweight image repository)
  • 4.0 ORCA GENI interoperability features (Obtain/use user credentials issued by GENI portal; Robust handling of cross-CF slice requests (early capability demo @GEC12 pending); Interoperability with additional GENI AM API clients (FLACK and GUSH); as needed, to reflect any changes in GENI AM API; Continue developing connectivity)
  • 4.0 ORCA substrate enhancements (XCAT/Perceus support (NDL, handler, policy); Host types and sizes)
  • 4.0 ORCA NDL enhancements (as needed)
  • 4.0 ORCA ABAC features (GENI-ABAC standard attribute set; Declarative ABAC trust structure within the ORCA federation; Integration of ABAC into ORCA release for slice authorization; External credential repository; Attribute-based resource sharing policy (similar to summer 2010 proof-of-concept demo)
  • 4.0 ORCA management and monitoring features ( GENI AM API for slice data; GENI AM API for kill switch; Enhancements for manageability and monitoring (e.g., nagios/puppet integration); Publish slice, resource availability and resource usage records)

Update software and documentation of your WiMAX network testbed.

Update software and documentation of your WiMAX base station site.

  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository

Update software and documentation of your WiMAX base station site.

  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Release latest WiMAX software and documentation.
  • Document planned WiMAX base station software fixes or additions.
  • Provide support to help WiMAX campus sites meet their Spiral 4 goals, and identify fixes or additions needed in WIMAX base station software.
  • Provide support to help WiMAX experimenters meet their goals, and identify fixes or additions needed in WiMAX base station software
  • Update software and documentation of your WiMAX base station sites.
  • Release WiMAX RF AggMgr software that supports Airspan base station, including these functions: ability to set and restore base station parameters; Mobile Station access list and data path destination in DB, with specified VLAN tag per mobile station.
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update software and documentation of your WiMAX base station site as required.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Deploy the Wisconsin Mobility Services Engine into MadBed testbed, and document exposed API
  • Update software and documentation of your WiMAX base station site.
  • Publish first draft of plan for design, configuration, implementation and operation of long-term iGENI infrastructure
  • Document procedure and scripts, etc., for ORCA infrastructure performance monitoring demo

Deploy and operate at initial integration (beta) sites (2 or more, these are expected to be development partner sites or the GPO lab). Revise software for campus release and deliver to IBM.

Deploy first switch and bring new connections to Georgia Tech and Clemson online

Changed due date due to contract issues. NLR requested and received approval from GPO for vendor change from HP in original SOW to Brocade.

Deploy switches and bring up test connections to NLR, Internet2 and two early deployment CENIC research universities for testing of physical connectivity .

Date revised due to contract issues.

Initial deployment of persistent GENI Global I&M Registry (GGR) service, based on UNIS

  • Workshop/meeting at TBD location of representatives from PrimoGENI Florida, PrimoGENI, the GPO and possibly other interested parties. Topics to be covered in the workshop include: Experiences with federating with Brazil (technical and non-technical challenges); lessons learned that might apply to other international federations; sharing of resources across international federations; coordinating operations across international federations (sharing of information across national testbeds); potential federation of additional Brazilian resources with GENI.
  • Milestone due date may change depending on venue selected for this meeting.
  • Coordinate with Orca Cluster D project to package DiCloud as part of the standard Orca release.
  • Upgrade to the latest stable Orca release and maintain an operational Orca site authority.

Complete initial GEMS prototype

Authentication, and basic Authorization support, for collection and presentation in another slice

  • Utilize XML messaging service based on XMPP
  • Utilize OML servers that are part of the software release, and are run as part of the slice.
  • Visualization is provided by a standalone tool, that is run as part of the slice.
  • Demonstrate GIMI working on target aggregates, including ORCA and ExoGENI racks (if available), both servers and VMs.
  • Demonstrate some WiMAX measurement capabilities.
  • Demonstrate Layer 0,1 or 2 measurement capabilities (potentially a combined LEARN/CASA measurement depending on radar deployment in DFW)
  • If installed, demonstrate initial capabilities to monitor racks.
  • Fixing of new bugs from previous release 2.7.0
  • Fixing of user development issues
  • New features to improve data analysis
  • New features to improve filtering capabilities and re-design of filter handling system
  • New binding for additional languages (Python)
  • New OML application to collect measurements from SNMP agent (NICTA); should provide measurements equivalent to INSTOOLS
  • Improved documentation
  • Allows users to keep a persistent log of their experiments
  • Includes OML server
  • May push measurement data to the iRODS archive
  • May retrieve measurement data stored in iRODs archive, and visualize it. (requires sql query support in iRODS, where an sql database can be actively hosted in iRODS, and someone can run queries against it.
  • Provision of a set of visualization tools to graphically present measurement data
  • Share with GEMINI project

Demonstrate and release high-level policy tools based on the prototypes deliveredin S4.g. Deliverable is code release and documentation as well as the demonstration.

  • Complete first tutorial at a non-GENI venue
  • Deliver tutorial materials and draft schedule of future tutorials

Make your stand-alone cognitive radio system available for use by other GENI researchers

Release a full set of design information for multi-FPGA infrastructure-class cognitive radio platform kit hardware, and Phase II radio card hardware

  • 10Gb NetFPGA switch connected to CRON and managed by an OpenFlow controller.
  • Prototype of chain-mode VLAN stitching using the API defined by ISI
  • Clearinghouse Provider agreement achieves recommended status.
  • Updated aggregate provider and LLR achieve ""recommended"" status if discussed at GEC13. If not, present to COMIS at GEC14.
  • Review GENI rack functional specifications and designs for operational security and campus/network security and provide inputs as needed for team documents and reviews.
  • Present drafts of any new policies/procedures identified in Milestone 2
  • Participate in discussions relate to authorization and authentication in GENI.
  • Serve as the GENI LLR (ongoing)..
  • Report on security experiments using cloud resources in GENI.
  • Plan for additional security experiments
  • GENI coursework fleshed out with details for at least one GENI and GENI Cloud based exercise: Include complete description of the exercise and all software and configuration files needed to do the exercise. Exercise must have been tested by somebody other than the author of the exercise.
  • TransCloud demonstration: Demonstration of a cross-site Hadoop service
  • Demonstration and/or tutorial on using Gush to set up, execute and manage experiments in GENI.
  • Gush distribution includes Gush source with instructions for building and installing on Ubuntu, MacOS, and RedHat; Gush binary distribution for Ubuntu and RedHat; VirtualBox VM running an open-source VM with Gush installed. Verify VirtualBox VM with Gush works on a computer running a Windows OS.
  • Support the OnTimeMeasure project in its demonstration of the performance measurement of GENI backbone and access networks that may be carrying non-IP traffic.
  • Support the efforts of the I&M working group and the GPO to define persistent operational service, particularly those shared by the GEMINI and GIMI projects
  • Demonstrate stitching between GENI resources at MAX and CRON using the prototype GENI stitching AMs for MAX, CRON and Internet2. Demonstrate GENI slices using stitched layer2 connections between MAX and CRON over Internet2. We anticipate that MAX will use the DYNES rack that should be installed in MAX before this demo, and that CRON will use traditional ION services provided by their LONI regional connection to Internet2, which will use appropriate services to interconnect them.
  • Evaluate modifications required to PerfSonar Topology Service to build a GENI Topology Service. Share design on GENI wiki and review at a GENI teleconference. Assumptions: This is design work; no implementation is expected. However design will be to the level of detail where implementation could begin.
  • Demonstration of the updated provenance system (based on Milestone 2 report) being used with the GENI experiments identified in Milestones 1 & 2. Written evaluation (document or web page) of NetKarma: What worked well and how it can be improved. We may have a person from the GPO repeat these experiment and evaluate NetKarma in the context of these experiments; provide reasonable support to this person.
  • Show how your tools may be used to automatically create and populate event records.
  • Demonstrate the measurement of performance of GENI backbone and access networks that may be carrying non-IP traffic.
  • Propose and deliver a plan for evaluating the performance of GENI's backbone and access networks when using OpenFlow (e.g. GENI ""Plastic Slices""). Consider how to monitor the performance of OpenFlow networks and suggest new tools needed for monitoring such networks. Present plan at GEC.
  • Demonstrate INSTOOLS-Flack software integration of OnTimeMeasure within a GENI experiment.
  • OnTimeMeasure tutorial at GEC14.
  • Support GENI experimenters using OnTimeMeasure (ongoing).
  • Tutorial based on Flack for experimenters new to GENI.
  • Demonstration of the use of ProtoGENI tools (command line and/or Flack) to set up and run experiments on GENI.
  • ProtoGENI experimenter tools can be used to discover and allocate GENI Rack resources (assuming the Rack projects are ready).
  • Federation: Demonstration of PlanetLab federated with the GENI clearinghouse.
  • ABAC: Implementation of ABAC in the PlanetLab CF in progress (assuming the community decides at GEC13 to use ABAC as the GENI authorization mechanism)
  • Track and implement changes to the GENI AM API.
  • Sface: Demonstration and/or tutorial at the GEC that illustrates the use of Sface to support the experimenter workflow. Demonstration/tutorial will include experiments that use resources from PlanetLab, ProtoGENI and GENICloud. (Or other resources such as GENI Rack resources in consultation with the GPO.)
  • Support GENI Rack demos that integrate with the ProtoGENI control framework
  • PrimoGENI tutorial and/or demo at GEC14 that shows experimenters how to use PrimoGENI resources in Florida and Brazil their experiments. Tutorial and demo will use one of the GENI experimenter control tools: Flack, Omni, Gush or Sface.
  • Connect to the GENI OpenFlow backbone
  • Federation: Demonstration of ProtoGENI federated with the GENI clearinghouse.
  • ABAC: Demonstration of ABAC integrated into the ProtoGENI CF (assuming the community decides at GEC13 to use ABAC as the GENI authorization mechanism).
  • Track and implement changes to the GENI AM API.
  • Support GENI Rack demos that integrate with the ProtoGENI control framework
  • Courseware available on line with 2-3 assignments and associated solutions published. Courseware will have two components: Hands-on exercises for student assignments and instructor material that includes solutions to the assignments.
  • Advertise coursework at GEC with demo and/or tutorial.
  • Serval running on GENI resources accessible by most GENI experimenters.
  • Usability and functional enhancements to Serval. Some of these enhancements may be based on feedback from demos and tutorials at GECs 12 and 13.
  • Updated Serval user guides/examples/tutorials published online.
  • Demonstration and/or tutorial on the use of Serval by GENI experimenters.
  • Demonstration of TUF integrated into the test/demo branch of at least one GENI project identified in Milestone 2.
  • Find other GENI projects that could benefit from TUF.
  • VMI integrated into the Eucalyptus cluster software being developed by RENCI. Demonstration of the monitoring of VMs in this environment and the reporting of data using perfSONAR compatible interfaces.
  • Third Alaska resource federated with GENI: Aggregate manager running the GENI AM API available and help pages for experimenter using the resource published. Agree to the GENI Aggregate Provider agreement for the federated resource. An email to the GPO saying you agree to follow this agreement with respect to this second resource will suffice.
  • Publish status of resources to the GMOC.
  • Demo and/or tutorial directed towards GENI Experimenters on using Alaska resources for experimentation. Emphasize unique nature of resources that would make them attractive to experimenters
  • Document/web page with a detailed design of the GENI attribution framework. Framework design (which may be a combination of software, policies and procedures) must meet requirements defined in Milestone 2 and must be validated using use cases from Milestone 2.
  • Detailed plan for implementing the framework (or portions thereof). Review plan with GPO (and possibly other stakeholders).

Support multi-campus demo that includes new resources from this deployment and existing meso-scale resources

Demonstrate Nowcasting experiment workflow using Gush-Orca-DiCloud GENI stack.

  • Work with GENI I&M projects to demonstrate integration of user-workspace features of version 2 MDA service with their tools.
  • Demonstrate long-term archive features of version 2 of MDA service.

To support dynamic deployment of I&M services, after an application has been deployed on a node

To collect measurement data provided by an experimenters application

To efficiently collect measurement data from MIBs in the local node

Integrate initial GEMS for GEMINI 1.0

Initial deployment of GENI Event Messaging Service (GEMS)

  • Fully integrated, and tested for functionality and robustness
  • Documented
  • For operation in defined range of GENI environments
  • Deployment configurable for use by experimenters and for infrastructure measurement
  • With capabilities and features as noted
  1. Measurement data provided by the experimenters application

Tutorial for infrastructure operators at GEC14

  • Document on GIMI web page
  • Provide support to early users
  • Can push measurement data from OML server run as part of the slice, to the iRODS archive.
  • Feedback on use of v1.0 software by GPO and early users
  • Tutorial on v1.0 software for all users
  • Agree on definition of V1.1 release
  • Define, prototype and demonstrate an authorization mechanism for your I&M Orchestration capability; consider the message signing being proposed by NICTA. This goal relates to the authority (end-to-end) of a given entity to perform a given actuation action. Scope includes ensuring that there is a provision for messages to be injected into the messaging system with accompanying signatures, and that messages with signatures are carried through the messaging service without damaging or altering the signature so they can be verified by and endpoint. Scope includes generating or verifying signatures. (Goal 7)
  • Modify, prototype and demonstrate the GENI I&M Orchestration capability to manage I&M services/slivers within a separate slice or within an aggregate; this can be used to actuate a function. Scope includes defining, prototyping and demonstrating any additional layers of functionality that are needed for authorization or other issues when (i) messages source and target are different slices, or one is a slice and the other is a substrate, (ii) when the messages are intended to actuate resources, like the OMF EC and RC (i.e. it is a verification of the integration of Goals 2,4,6). (Goal 8)
  • Include an authorization mechanism for your Measurement Pub/Sub capability that is based on XEP-0060 Authorize Access Model. . Scope includes authorization related issues related to the pub/sub records, and repositories (thus going beyond GEC13 prototype). (Goal 10)
  • Demonstrate your Measurement Pub/Sub capability by transporting and distributing standardized GENI resource event records, as defined by the NetKarma project; these records could describe events such as assignments, faults or errors. (Goal 11)
  • Include a data repository associated with your Measurement Pub/Sub capability, that could subscribe to a node and archive all event messages. Scope includes internalizing into the GENI Messaging Service an instance of the type of repository showcased in GEC13. (Goal 12)
  • Demo research experiment by LEARN-associated experimenter that uses ORCA Cluster resources.

Deploy systems and software at OmniPoP and first 2 RONs, with layer 2 VLAN interconnections to GENI meso-scale infrastructure. Begin GMOC operations support.

Date changed due to contract issues.

Support multi-campus demo that includes new resources from phase 1 and existing meso-scale resources

Demonstrate at least one unique Rutgers contribution to managing, monitoring, or experimenting with the GENI mesoscale infrastructure. Ideally, this demonstration should be conducted for an organization other than GENI (e.g. a regional network meeting, visit to another interested campus, technical conference etc.).

Support OpenFlow software used in GENI campus OpenFlow deployments through Spiral 4. Participate in Spiral 3 and Spiral 4 GEC demos with other OpenFlow sites and provide debugging and support to experimenters using Stanford OpenFlow resources and software. Offer hands-on tutorials at public venues like GECs

Host workshop at Indiana University in partnership with the GlobalNOC Network Education Lab

Demonstrate at least one unique University of Washington contribution to managing, monitoring, or experimenting with the GENI mesoscale infrastructure. Ideally, this demonstration should be conducted for an organization other than GENI (e.g. a regional network meeting, visit to another interested campus, technical conference etc.)

Demonstrate at least one unique University of Wisconsin contribution to managing, monitoring, or experimenting with the GENI mesoscale infrastructure. Ideally, this demonstration should be conducted for an organization other than GENI (e.g. a regional network meeting, visit to another interested campus, technical conference etc.).

GENI capability demo: obtain a slice spanning the ORCA Cluster and the protoGENI Cluster, using resources stitched from multiple ORCA and protoGENI sites, connected by backbone domain, via GENI AM API, configure using GUSH, and run application that exercises all resources.

  • Continue active participation in GENI design community, especially activities focused on interoperability.
  • Review planning decisions with other ORCA Cluster projects
  • Continue technical assistance to other ORCA Cluster projects
  • Demonstrate available ORCA site features, through Dungeness 4.1 release
  • Demonstrate current ORCA GENI interoperability features using FLACK, GUSH and OMNI clients (At GENI AM API, support use of RSpecv2 in ADVERTISEMENT return message)

Support multi-campus demo that includes new resources from this deployment and existing meso-scale resources

  • Complete installation of 1 additional WiMAX base station, plus associated servers and services, in your WiMAX network testbed.
  • Complete installation of access facilities and switches, to provide connectivity from all of the WiMAX base stations in your WiMAX network testbed, through campus OpenFlow switches where available, to the GENI Internet 2 backbone.
  • Configure all of your WiMAX base stations using OMF, and demonstrate connectivity to the GENI Internet 2 backbone.
  • Complete basic range and throughput tests for all of the WiMAX base stations in your WiMAX network testbed using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete extended deployment plan for Year 2 in your WiMAX network testbed, including any additional WiMAX base stations, and associated software.
  • Complete installation of 3 WiMAX base stations, plus associated servers and services.
  • Complete installation of access facilities and switches, to provide connectivity from your WiMAX base stations, through campus OpenFlow switches where available, to the GENI Internet 2 backbone.
  • Configure the WiMAX base stations using OMF, and demonstrate connectivity to the GENI Internet 2 backbone.
  • Complete basic range and throughput tests of your WiMAX base stations using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete extended deployment plan for Year 2, including any additional WiMAX base stations, and associated software.
  • Operate the WiMAX base station using OMF equipped with GENI AM API to provide access to GENI experimenters.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station, using OML equipped to forward status information to the GMOC.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Complete installation of 1 WiMAX base station, plus associated servers and services.
  • Complete installation of access facilities and switches, to provide connectivity from your WiMAX base station, through campus OpenFlow switches where available, to the GENI Internet 2 backbone.
  • Configure the WiMAX base station using OMF, and demonstrate connectivity to the GENI Internet 2 backbone and to the Infinity framework for content delivery.
  • Complete basic range and throughput tests of your WiMAX base station using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete extended deployment plan for Year 2.
  • Operate the WiMAX base station using OMF equipped with GENI AM API to provide access to GENI experimenters.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station, using OML equipped to forward status information to the GMOC.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Demonstrate latest WiMAX base station software fixes and additions.
  • Review list planned WiMAX base station software fixes or additions with campus projects and experimenters.
  • Work with campus projects, GPO and experimenters to help define and implement advanced WiMAX experiments/applications, including GENI-wide experiments/applications, e.g., MobilityFirst
  • Complete installation of 1 additional (3 total) WiMAX base stations at Rutgers WINLAB to support multi-cell/multi-sector, plus associated servers and services.
  • Complete installation of 1 additional (2 total) WiMAX base stations at UCLA to support multi-cell/multi-sector, plus associated servers and services.
  • Complete installation of access facilities and switches at Rutgers, to provide connectivity from your WiMAX base stations, through campus OpenFlow switches, to the GENI Internet 2 backbone.
  • Complete installation of access facilities and switches at UCLA, to provide connectivity from your WiMAX base stations, through campus OpenFlow switches, to the GENI Internet 2 backbone.
  • Configure the WiMAX base stations at Rutgers using OMF, and demonstrate connectivity to the GENI Internet 2 backbone using OpenFlow.
  • Configure the WiMAX base stations at UCLA using OMF, and demonstrate connectivity to the GENI Internet 2 backbone using OpenFlow.
  • Complete basic range and throughput tests of WiMAX base stations at Rutgers using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete basic range and throughput tests of WiMAX base stations at UCLA using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete extended deployment plan for Year 2 at Rutgers, including any additional WiMAX base stations, and associated software.
  • Complete extended deployment plan for Year 2 at UCLA, including any additional WiMAX base stations, and associated software.
  • Complete a plan for providing ASN GW and AA Server software to support authentication and handover at multi-cell/multi-sector base station sites using Airspan base stations.
  • Complete a plan for extending the OGS Login Service so that it supports access via the GENI AM API.
  • Operate the WiMAX base station using OMF equipped with GENI AM API to provide access to GENI experimenters.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station, using OML equipped to forward status information to the GMOC.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters.
  • Operate the WiMAX base station using OMF equipped with GENI AM API to provide access to GENI experimenters.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station, using OML equipped to forward status information to the GMOC.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Participate in GENI-wide experiments/applications as required.
  • Complete and demonstrate an advanced mobility and/or application experiment using DOME, that fully utilizes WiMAX base station/mobile station capabilities, and share with other projects/experimenters
  • Operate the WiMAX base station using OMF equipped with GENI AM API to provide access to GENI experimenters.
  • Participate in GENI-wide experiments/applications, e.g, MobilityFirst.
  • Operate the WiMAX base station, using OML equipped to forward status information to the GMOC.
  • Complete and demonstrate an advanced mobility and/or application experiment using OMF/OML, that fully utilizes WiMAX base station capabilities, plus the Mobile Access Router (MAR) as mobile station, with the Wisconsin Mobility Services Engine, and share with other projects/experimenters
  • Complete installation of one WiMAX base station, plus associated servers and services; should enough fund be available, install the remaining one or two WiMAX base stations.
  • Complete installation of access facilities and switches, to provide connectivity from your WiMAX base station(s), through campus OpenFlow switches where available, to the GENI Internet 2 backbone.
  • Configure the WiMAX base stations using OMF, and demonstrate connectivity to the GENI Internet 2 backbone.
  • Complete basic range and throughput tests of your WiMAX base stations using reference OMF/OML throughput experiment and a reference mobile station.
  • Complete extended deployment plan for Year 2, including any additional WiMAX base stations, and associated software
  • Report to the GENI WiMAX deployment meeting on a development plan for handover software for GENI WiMAX sites and on a recommended deployment plan for Year 2.
  • Finalize the plan for the design, configuration, implementation and operation of long-term iGENI infrastructure
  • GENI infrastructure performance monitoring demo: obtain a slice spanning the ORCA Cluster and the protoGENI Cluster, using resources stitched from multiple ORCA and protoGENI sites, install LAMP/perfSONAR network performance monitoring software in the slice, evaluate network performance, and register data for use by operators and experimenters.
  • The documentation and code release will detail how to run the experiment in our demonstration for external GENI users.
  • Post updated DiCloud code with documentation on how to use as courseware in classes, e.g., to set quotas for students using Amazon resources in courses.
  • Document version 2 MDA service, and release all code.
  • Based upon working with GENI I&M projects/experimenters using both user-workspace and long-term archive features of version 2 MDA service, assemble recommendations for future versions of MDA service.
  • Update documentation on GENI Messaging service, plus GENI I&M Orchestration and GENI I&M Measurement Pub/Sub capabilities.
  • Provide an up-to-date installation, configuration and feature guide to all available software
  • Update documentation of LEARN ORCA clusters
  • Update GENI research plan by experimenters at LEARN campuses

Document procedure and scripts, etc., for ORCA cluster capability demo

  • Provide up-to-date installation, configuration and feature guides to all available ORCA software
  • 4.1 ORCA core features (as needed)
  • 4.1 ORCA GENI interoperability features (as needed, to reflect any changes in GENI AM API)
  • 4.1 ORCA substrate enhancements (Storage handling (permanent, EBS))
  • 4.1 ORCA NDL enhancements (as needed)
  • 4.1 ORCA management and monitoring features ( as needed)
  • 4.1 ORCA OpenFlow features (FlowVisor-in-a-slice launch, with suitable authorization (FlowVisor instance per site); OpenFlow-based service launch: AM stitches OpenFlow experiment slice into local FlowVisor; OpenFlow customer launch: a slice allows a third-party OpenFlow service to interpose on its flowspace; NDL extensions for flow specs and OpenFlow substrates; Demo: slices opt-in to the packet transit service (inter-slice stitching for OpenFlow-based services))
  • 4.1 Cloud enhancements (DiCloud integration as production service; Amazon VPC-as-a-service integration as production service) (DICLOUD)
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of your WiMAX base stations and a reference mobile station.
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base stations and a reference mobile station.
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base stations and a reference mobile station
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Release latest WiMAX software and documentation.
  • Document planned WiMAX base station software fixes or additions.
  • Provide support to help WiMAX campus sites meet their Spiral 4 goals, and identify fixes or additions needed in WIMAX base station software.
  • Provide support to help WiMAX experimenters meet their goals, and identify fixes or additions needed in WiMAX base station software.
  • Update software and documentation of your WiMAX base station sites.
  • Document range and throughput measurement results of WiMAX base station sites, using a reference mobile station.
  • Release updates to WiMAX RF AggMgr software that supports Airspan base station, including these functions: ability to set and restore base station parameters; Mobile Station access list and data path destination in DB, with specified VLAN tag per mobile station.
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository.
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site as required.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • For WiMAX experiments/demos, place description and any required code in the WiMAX experiment repository
  • Update software and documentation of your WiMAX base station site.
  • Document range and throughput measurement results of WiMAX base stations and a reference mobile station.
  • Publish v1 of plan for design, configuration, implementation and operation of long-term iGENI infrastructure
  • Document procedure and scripts, etc., for GENI infrastructure performance monitoring demo

Integrate and test with other existing Internet2 and NLR OpenFlow meso-scale deployments and GENI racks

Integrate and test with other existing Internet2 and NLR OpenFlow meso-scale deployments and GENI racks

Support for multiple storage arrangements, including a continuum of durations

Extensions to support infrastructure resources in racks

Work with the other GENI mesoscale campuses and GMOC to document, monitor and support the Clemson aggregates as described in the GENI approved policies (e.g. recommended use, aggregate providers agreement) and GMOC Concept of Operations. Develop and publish campus operational policies and procedures to support the Clemson aggregates as needed on the GENI wiki (e.g. the campus aggregate information pages currently located at http://groups.geni.net/geni/wiki/GeniAggregate). Review and provide feedback on proposed new GENI policies and procedures at GECs

Work with the other GENI mesoscale campuses and GMOC to document, monitor and support the Georgia Tech aggregates as described in the GENI approved policies (e.g. recommended use, aggregate providers agreement) and GMOC Concept of Operations. Develop and publish campus operational policies and procedures to support the Georgia Tech aggregates as needed on the GENI wiki (e.g. the campus aggregate information pages currently located at http://groups.geni.net/geni/wiki/GeniAggregate). Review and provide feedback on proposed new GENI policies and procedures at GECs

Work with the other GENI mesoscale campuses and GMOC to document, monitor and support the Indiana University aggregates as described in the GENI approved policies (e.g. recommended use, aggregate providers agreement) and GMOC Concept of Operations. Develop and publish campus operational policies and procedures to support the Indiana University aggregates as needed on the GENI wiki (e.g. the campus aggregate information pages currently located at http://groups.geni.net/geni/wiki/GeniAggregate). Review and provide feedback on proposed new GENI policies and procedures at GECs.

Work with the other GENI mesoscale campuses and GMOC to document, monitor and support the Rutgers aggregates as described in the GENI approved policies (e.g. recommended use, aggregate providers agreement) and GMOC Concept of Operations. Develop and publish campus operational policies and procedures to support the Clemson aggregates as needed on the GENI wiki (e.g. the campus aggregate information pages currently located at http://groups.geni.net/geni/wiki/GeniAggregate). Review and provide feedback on proposed new GENI policies and procedures at GECs

Integrate new OpenFlow control software with other GENI control software as defined in the architecture and software development GENI working group documents published and discussed at each GENI Engineering Conference. (Expected integration areas for Spiral 4 include GENI racks, GENI clearinghouse, federation, authorization, identity, RSPECs and stitching. There will also be a period where GENI rack teams and mesoscale aggregates work together with the GPO to clarify requirements and make sure the selected implementations are designed to interoperate before rack deployments start.) Demonstrate the success of GENI rack integration by participating in ongoing deployment tests and experiments with all Spiral 4 deployed GENI racks. Demonstrate development and integration success in other areas with focused integration demos. (Integration demos may be smaller scale and can use prototype software in select locations, rather than full production GENI campus deployed software.)

Revise and update training material based on experiences at the workshops

Work with the other GENI mesoscale campuses and GMOC to document, monitor and support the University of Washington aggregates as described in the GENI approved policies (e.g. recommended use, aggregate providers agreement) and GMOC Concept of Operations. Develop and publish campus operational policies and procedures to support the University of Washington aggregates as needed on the GENI wiki (e.g. the campus aggregate information pages currently located at http://groups.geni.net/geni/wiki/GeniAggregate). Review and provide feedback on proposed new GENI policies and procedures at GECs

  • CRON Aggregate Manager updated with the latest release of the ProtoGENI Reference Component Manager that implements the GENI AM API
  • Deliver updates to proposals from Milestones 1, 2 and 3 based on experiences with implementing these proposals and/or feedback from the GENI community.
  • Deliver an assessment of OnTimeMeasure's unique capabilities for integration into the GENI I&M frameworks selected in Solicitation 3
  • Support GENI experimenters using OnTimeMeasure (ongoing).
  • Stable release of Flack and other ProtoGENI experimenter tools
  • Documentation for experimenters using tools and developers wanting to extend these tools
  • Stable release of software that includes federation with the GENI CH, ABAC for authorization and the version 2.0 of the GENI AM API.
  • Associated documentation for use by CF users (aggregate providers, experimenters, operations)
  • Additional Brazilian resources (if any identified in Milestones 2 & 3) federated with GENI.
  • Stable release of aggregate managers for Florida and Brazilian PrimoGENI resources.
  • Documents/help pages for GENI experimenters wishing to use PrimoGENI.

Courseware delivered with 3-4 hands-on assignments. At least one assignment must be based on non-IP networking. All assignments must be tested by at least one person other than the person developing them.

  • Deliver latest stable version of Serval with associated user guides and documentation
  • Portions of the framework to implemented will be selected by the P.I.s, in consultation with the GPO
  • For policies/procedures: Deliver written policies and procedures
  • For software: Demonstrate s/w to GPO (any any interested parties), possibly using tools such as WebEx. Deliver software
  • Review operational procedures and documents from GENI operations and help desk teams (GMOC) for security implications, and provide inputs as needed by email.
  • Updated drafts of agreements/procedures identified in Milestone 2 that incorporate comments from GEC14 and telephone/email discussions. All major concerns must be addressed and these drafts must be at the point where they will likely be recommended at GEC15.
  • Report on findings of security experiments identified in Milestone C.
  • Report summarizing findings of the project based on security experiments including suggestions for improving GENI security
  • GENI coursework fleshed out with details for at least three GENI and GENI Cloud based exercise (two beyond the GEC14 exercise): Include complete description of the exercises and all software and configuration files needed to do the exercises. Exercises must have been tested by somebody other than the author of the exercises
  • Deliver NetKarma software and user documentation. Prefer user docs in the form of publicly available web pages.
  • Publish event records created and populated by your tools using the pub/sub service provided by the GENI IMF project (http://groups.geni.net/geni/wiki/IMF).
  • Stable release of software that includes federation with the GENI CH, ABAC for authorization and Reference Component Manager that implements version 2.0 of the GENI AM API.
  • Associated documentation for use by CF users (aggregate providers, experimenters, operations)
  • Deliver TUF software
  • Deliver guide(s) for software developers wishing to use TUF as an updater for their software.
  • Work with RENCI to deploy VMI at operational Eucalyptus clusters deployed by RENCI for use by GENI experimenters. Deployment completed by this milestone due date
  • Deliver working software and documentation of DSL FAITH over GENI so that other researchers can develop similar experiments
  • Gush updated to use GENI AM API/Omni version as of GEC14 (or later version) and GENI authentication mechanisms current as of GEC14 or later.
  • Enhancements to Gush and Nebula, and associated documentation/user guides based on experiences with coursework and GEC tutorial/demo.
  • Gush distribution includes Gush source with instructions for building and installing on Ubuntu, MacOS, and RedHat; Gush binary distribution for Ubuntu, RedHat and MacOS; VirtualBox VM running an open-source VM with Gush installed. Verify VirtualBox VM with Gush works on a computer running a Windows OS.
  • Release a full set of design information for stand-alone cognitive radio system kit, including hardware, 0.5 software and reference software implementations. This specification is based on the VITA interface, U. Colorado OFDM library and sample spectrum sensing application

Deploy and operate racks at first interested campus sites (these are not expected to be partner sites). Deploy a combined total of 4 sites by years end. Campuses must be able to operate consistently with GENI operations standards such as Emergency Stop and the GENI Aggregate Provider Agreement

Support early experimental users who will demonstrate at GEC14. Support demonstrations of GENI VLAN stitching

Refactor UNIS (combined Lookup and Topology Services) to support hierarchical operation with local and global instances

Support movement of measurement data objects from an MS to an iRODS-based Measurement Data Archive service, including the associated MDOD

Include ability to create and edit Measurement Data Object Descriptors (MDODs)

Demonstrate, document and support the use of GEMINI I&M services to collect, analyze and present measurement data satisfying the defined use cases for instrumenting an experimenters slice

Continuing support and bug fixes to experimenters using GEMINI I&M services

Demonstrate, document and support the use of GEMINI I&M services to collect, analyze and present measurement data satisfying the defined infrastructure monitoring use cases

Continuing support and bug fixes to infrastructure operators using GEMINI I&M services

Integrate and test with existing GENI OpenFlow meso-scale deployment and make switch resources available to NSF experimenters

Original date in SOW was somewhere in the period Sept-Dec 2012. Trac doesn't handle ranges for due dates, so picked a target date.

Original date in SOW was somewhere in the period Sept-Dec 2012. Track doesn't handle ranges for due dates, so picked a target date.

Continue to integrate campus networks with GENI so that GENI users can request and use campus OpenFlow networks for research. This goal requires ON.Lab to further develop, integrate and support an Aggregate Manager that continues to support the GENI AM API and enables integrated experiments with other mesoscale aggregates (e.g. ProtoGENI and PlanetLab)

Continue to address known bugs and requested GENI features for ON.Lab supported software in GENI campus deployments. This includes software provided by Stanford, UC Berkeley, and ON.Lab subcontractors. As of 09/2011, this list includes FlowVisor, NOX and any other Stanford-recommended controllers, Indigo, FOAM, Expedient, Opt-In Manager and OpenVSwitch

Operate a campus GENI aggregate that includes both OpenFlow and compute resources that are available to researchers via the GENI AM API control framework and connected to other GENI aggregates at layer2. Support GENI experiments using this aggregate. Work with the GMOC to monitor and support this aggregate as described in the GMOC Concept of Operations and operational procedures, and GENI approved policies (e.g. recommended use, aggregate providers agreement). (This aggregate, which is physically located on the Stanford campus, began operating in Spiral 3

Update the Shadownet web page to reflect changes and conform to GENI Aggregate Providers Agreement (Kentucky)

Provide consultation on ABAC integration into various code frameworks, including control frameworks, identity providers and portals, and GENI racks, based on experience and sample code. Support and extend ABAC infrastructure as reasonable and necessary to support ongoing GENI development and deployment.

  • Fully integrated and tested
  • Documented
  • Containing all bug fixes since v1.0, and some enhancements
  • Fixing of new bugs from previous release 2.8.0, stress test disconnection mode
  • New features to improve data analysis
  • New features to support IPv6 and IPv4/v6 address in databases
  • New features to improve filtering capabilities: filter composition/stacking
  • New binding for additional languages (Java/JNI)
  • New platform support: Android (experimental)
  • Improved documentation
  • Work with Internet2 and MAX to deploy a stitching prototype ION/DYNES AM and a stitching prototype MAX AM that provides appropriate functions for an end-to-end stitching demo between MAX and CRON. (CRON AM is covered under CRON SOW.) Assumptions: This deployment will be of ION/DYNES AM based on MAX AM.
  • Evaluate modifications required to OSCARS Path Computation to build a GENI Computation Service. Share design on GENI wiki and review at a GENI teleconference. Assumptions: This is design work; no implementation is expected. However design will be to the level of detail where implementation could begin.

Date and description changed due to contract issues.

Support multi-campus demo that includes new resources from phase 1 and existing meso-scale resources

Milestone: IDMS: S6.a GEC18

6 years late (10/01/13 00:00:00)

  • Packaging of the existing IBP depot software
  • Poster presentation at the GEC18 demo session
  • Project overview presentation

Milestone: IDMS: S6.b GEC19

5 years late (04/01/14 00:00:00)

  • Benchmark storage performance on GENI resources to determine baselines.
  • Configure and optimize IBP storage depot software accordingly per resource.
  • Package XSP and Phoebus software.
  • Begin integration with UNIS for service registration and discovery of all active components. Demonstrate service functionality at GEC19.
  • Produce requirements document for data management service (DMS).
  • Demonstrate early appliance images for the IDMS deployment on GENI resources with existing software components.
  • Demonstrate component testing across available GENI resources.
  • Start deployment of Experiment A.
    • Deploy multi-domain OpenFlow management/control experiment in GENI, using at least one GENI Rack.
    • Live demonstration of the multi-domain experiment
    • Decide which Big Data application is going to used and have a detailed plan for incorporating the application to the multi-domain control experiment.
    • Expand control plane to incorporate more than two domains
  • Detailed plan for deploying a second experiment in GENI
  • Provide feedback to the community

Milestone: IDMS: S6.c GEC20

5 years late (07/15/14 00:00:00)

  • Deliver and demonstrate prototype DMS software that integrates with IBP, XSP, Phoebus, and UNIS to manage data distribution. The initial DMS will be a skeleton service with pre-configured distribution logic while more intelligent algorithms are developed.
  • Create specialized storage and acceleration appliance images to be created on-demand by the DMS based on resource utilization. Evaluate and benchmark appliance creation on available GENI resources (e.g., GENI racks).
  • Deliver configuration and management scripts for prototype services.
  • Deliver AuthN/AuthZ design document. Will leverage existing AA mechanisms in XSP/Phoebus and UNIS. AA mechanisms will be compatible with current GENI approaches, meaning the support for user client certificates and credentials.
  • Demonstrate I&M tools in collecting and measuring prototype services running in GENI slices.
  • Live demonstration of Experiment A running in GENI
    • Using more than two domains
  • Incorporated a Big Data application preferably from another domain science.
  • Provide feedback to the community
  • Live demonstration of experiment showcasing GENI multi-domain capabilities and limitations.
  • Preliminary results from the second experiment.
  • Documentation on how to repeat the two experiments in GENI
  • Identify one live streaming site each on the UW-Madison and Clemson campuses.
  • Identify prototype hardware to be installed at each live streaming site.
  • Develop an overall software architecture for the prototype implementation.
  • Develop software architecture Streaming Relay (SR) server
  • Develop the software architecture of Connect & Select (C&S) server and deliver an architecture document for C&S server
  • Develop alpha version of SR server ready for deployment and testing
  • Develop alpha version of the C&S server ready for deployment and testing
  • Integrate SR and C&S servers and demonstrate the system at the GEC
  • Develop preliminary approaches to integrate C&S and SR servers with other GENI software for authentication, instrumentation, and measurement.
  • Software components are developed and initial deployment of the service demonstrated using live video streams from UW and Clemson University.
  • Benefits of GENI capabilities (deep programmability, SDN) demonstrated through experiments based on live video streams from UW-Madison and Clemson.
  • Start integrating with other GENI software for instrumentation and measurement (e.g., GIMI).
  • Report on experiences deploying this service in GENI and make suggestions for improvements in the GENI infrastructure and tools
  • Public-Private (Hybrid) cloud testbed setup requirements and GENI integration plan
  • Talk on experiment requirements and plans at GEC18
  • Depending on network availability at the City of Dublin, setup a hybrid cloud testbed with GENI Rack connected over the City of Dublin network to the GENI infrastructure
  • Demonstration of a simple simulation-as-a-service app with any available GENI Rack
  • Plan for recruiting opt-in users for the hybrid-cloud services
  • IRB Protocol application approval for opt-in user recruitment and usability studies
  • Report on experiences implementing simple app services on GENI and obtaining IRB approval, along with suggestions for improving GENI tools and services
  • Simulation-as-a-service apps for manufacturing professionals
  • Report on case studies of user productivity, performance and experiences using these simulation-as-a-service apps
  • Updated report on experiences implementing these app related services on GENI along with suggestions for improving GENI tools and services
  • Update GENI project wiki page with detailed log of experiment experiences
  • Present poster/presentation to GENI community about the new GENI Science Shakedown experiment.
  • Port at least one domain science application to InstaGENI and ExoGENI. Each application will use GENI AM API to instantiate slices on both types of racks.
  • Demonstrate ported applications at GEC.
    • Show running applications.
    • Present base-line performance measurements.
  • Present initial results of shakedown experiments. It is difficult to predict what the experiments will reveal about the racks. Initial experiments will likely reveal low-hanging fruit such as simple infrastructure configuration errors. Progress in this area will depend on the speed of software development iterations with rack developers.
    • Identify the most important performance bottleneck for each application on each rack type.
    • Where possible, make recommendations to remedy performance bottlenecks.
  • Deliver a presentation about the goals and plan of the project during the new project session of GEC18.
  • Start developing plans for a winter camp.
  • Outbrief on winter camp.
  • Arrange basic logistics (date, rough schedule, location) and circulate call for participation for the first winter or summer camp in January or August 2014.
  • Develop curriculum and identify instructional staff for the camp.
  • Hold the first camp with pre- and post-evaluations in January if it is a winter camp.
  • Start developing plans for the first workshop, co-located with a major conference if possible.
  • Start developing plans for the first poster at GEC20. (The poster will be held with GEC poster and demo night and its logistics expense will be covered by GPO. The presenters will be supported through GPO travel grants.)
  • Hold the first 1-week camp with pre- and post-evaluations if it is a summer camp.
  • Arrange basic logistics and invite a keynote for the first workshop in the late year of 2014 or the early of 2015.
  • Hold the first poster session at GEC20. (The poster presenters will be supported through GPO travel grants.)
  • Start developing plans for the second camp in 2015.
Note: See TracRoadmap for help on using the roadmap.