Project Development Plan: Readiness Stage



Similar documents
GENI Work Breakdown Structure

Facility Usage Scenarios

GENI Network Virtualization Concepts

GENI Architecture: Transition

Clean-slate Internet Reinvention Initiative. CIRI GENI Global Environment for Network Investigation

Conceptual Design Project Execution Plan

Network Science and Engineering at NSF

OPTICAL TRANSPORT NETWORKS

White Paper. Requirements of Network Virtualization

Managing a Fibre Channel Storage Area Network

State of Minnesota IT Governance Framework

White Paper Case Study: How Collaboration Platforms Support the ITIL Best Practices Standard

Technical Document on Wireless Virtualization

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

CYBERINFRASTRUCTURE FRAMEWORK FOR 21 st CENTURY SCIENCE AND ENGINEERING (CIF21)

State of California Department of Transportation. Transportation System Data Business Plan

Sensing, monitoring and actuating on the UNderwater world through a federated Research InfraStructure Extending the Future Internet SUNRISE

System/Data Requirements Definition Analysis and Design

The Future of Network Marketing Research

This webinar covers solicitation NSF , The NSF Cloud infrastructure, and its re-issuance.

Big Workflow: More than Just Intelligent Workload Management for Big Data

WHITEPAPER. Managing Design Changes in Enterprise SBM Installations

Scope of Work Microsoft Infrastructure Upgrade

ITU-T Future Networks and Its Framework of Virtualization

Cisco Network Optimization Service

Network Virtualization: A Tutorial

U.S. DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT. Issued: September 6, 2002

Network Virtualization

VA ICJIS. Program Management Plan

Cisco Unified Communications and Collaboration technology is changing the way we go about the business of the University.

Quarterly Performance Review of the Arizona Education Learning and Assessment System: AELAS

Project Management Plan for

Designing a Cloud Storage System

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

VULNERABILITY ASSESSMENT AND SURVEY PROGRAM. Overview of Assessment Methodology. U.S. Department of Energy Office of Energy Assurance

CDC UNIFIED PROCESS JOB AID

Assessment of NCTD Program Management Framework for Positive Train Control Program

Exhibit F. VA CAI - Staff Aug Job Titles and Descriptions Effective 2015

SDR Architecture. Introduction. Figure 1.1 SDR Forum High Level Functional Model. Contributed by Lee Pucker, Spectrum Signal Processing

Penn State University IT Assessment. Opportunity Analysis - Advisory Committee March 30, 2011

Manag. Roles. Novemb. ber 20122

Develop Project Charter. Develop Project Management Plan

Extending the Internet of Things to IPv6 with Software Defined Networking

VEHICLE INFRASTRUCTURE INTEGRATION (VII) U.S. DOT DAY-1 APPLICATION DEVELOPMENT PLANS

Software Defined Exchange (SDX) and Software Defined Infrastructure Exchange (SDIX) Vision and Architecture

SENIOR INFORMATION SYSTEMS MANAGER

A very short history of networking

Stakeholder management and. communication PROJECT ADVISORY. Leadership Series 3

New Program Development on Networking Information Technology

a new sdn-based control plane architecture for 5G

Enhanced Enterprise SIP Communication Solutions

The FEDERICA Project: creating cloud infrastructures

International Workshop on Field Programmable Logic and Applications, FPL '99

Statement of Objectives. Special Notice D15PS00295 Nationwide Public Safety Broadband Network (NPSBN)

SOA and API Management

User-Centric Client Management with System Center 2012 Configuration Manager in Microsoft IT

Overview of Routing between Virtual LANs

Rethinking Small Cell Backhaul

Cloud RAN. ericsson White paper Uen September 2015

Voice Over IP Network Solution Design, Testing, Integration and Implementation Program Overview

MNLARS Project Audit Checklist

Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects

Bio-Inspired Anomaly Detection

How To Build A Virtualized Network On A Cloud On A Microsoft Server On A Linux (Openstack) System

Making the Case for Satellite: Ensuring Business Continuity and Beyond. July 2008

Section 2: Overview of Wireless Broadband Networks

Software Development Life Cycle (SDLC)

Transmission Function Employees Job Titles and Descriptions 18 C.F.R 358.7(f)(1)

Department of Administration Portfolio Management System 1.3 June 30, 2010

SAN Conceptual and Design Basics

Low-Cost Multi-Service Home Gateway Creates New Business Opportunities

HEP Software Consortium

Monitoring GENI Networks

Positive Train Control (PTC) Program Management Plan

Children s Bureau Child and Family Services Reviews Program Improvement Plan Instructions and Matrix

MRV EMPOWERS THE OPTICAL EDGE.

A survey on Spectrum Management in Cognitive Radio Networks

Cisco Change Management: Best Practices White Paper

Partnering for Project Success: Project Manager and Business Analyst Collaboration

XSEDE Overview John Towns

ANI Network Testbed Update

Mobile and Wireless ATM (WATM)

Smarter Balanced Assessment Consortium. Recommendation

Three Year District Technology Plan. Pasco School District #1 July 1, 2013 to June 30, 2016

CHAPTER 1 INTRODUCTION

Tutorial: OpenFlow in GENI

How To Build A Network For Mining

State of Texas. TEX-AN Next Generation. NNI Plan

G E N I. Global Environment for Network Innovations. GENI Spiral 1 Overview. Document ID: GENI-FAC-PRO-S1-OV September 29, 2008

Innovation in Networking

References and Requirements for CPE Architectures for Data Access

Information- Centric Networks. Section # 13.2: Alternatives Instructor: George Xylomenos Department: Informatics

ORGANIZED FOR BUSINESS: BUILDING A CONTEMPORARY IT OPERATING MODEL

---Information Technology (IT) Specialist (GS-2210) IT Security Competency Model---

Supporting Municipal Business Models with Cisco Outdoor Wireless Solutions

SACWIS PLANNING FOR DEPARTMENT OF HUMAN SERVICES DRAFT - STRATEGIC IMPLEMENTATION PLAN: MILESTONES & TIMELINES FOR A FULL IMPLEMENTATION

INTERNATIONAL JOURNAL OF PURE AND APPLIED RESEARCH IN ENGINEERING AND TECHNOLOGY

Networking Research: Trends and Issues

Software Defined Network Application in Hospital

CONECT - Cooperative Networking for High Capacity Transport Architectures Overview. Leandros Tassiulas CERTH

Transcription:

Project Development Plan: Readiness Stage GDD-06-33 GENI: Global Environment for Network Innovations February 15, 2006 1 This document's content is out-of-date. Its structure may serve as an example. Page: 1

This document was prepared by the GENI Planning Group. Editors: Larry Peterson, Princeton University Dean Casey, Ngenet Research Contributing workgroup members: Tom Anderson, University of Washington Dan Blumenthal, University of California Santa Barbara Dean Casey, Ngenet Research David Clark, Massachusetts Institute of Technology Deborah Estrin, University of California Los Angeles Larry Peterson, Princeton University (Chair) Dipankar Raychaudhuri, Rutgers University Jennifer Rexford, Princeton University Scott Shenker, University of California Berkeley John Wroclawski, Information Sciences Institute 2 This document's content is out-of-date. Its structure may serve as an example. Page: 2

Table of Contents Executive Summary...5 1 Introduction...7 1.1 Scope of Work...7 1.2 Processes and Procedures...8 1.3 Documentation and Reporting...8 1.4 Project Teams & Personnel...9 2 Execution of Readiness Stage Tasks...11 2.1 Facility Design...12 2.1.1 Research Requirements & Rationale...12 2.1.2 Facility Architecture...13 2.1.3 Distributed Services...15 2.1.4 Backbone Network...16 2.1.5 Wireless Subnets...18 2.2 Management Plan...19 2.2.1 Organizational Structure...20 2.2.2 GENI Project Office...21 2.2.3 Management Processes and Procedures...25 2.2.4 Transitions to Operations and Commissioning...25 2.3 CCC and GPO Establishment...26 2.3.1 NSF Solicitations...26 2.3.2 Transition...26 2.4 Community Engagement...27 2.5 GENI for Education...28 2.5.1 GENI in the Classroom...28 2.5.2 Education of the General Public...29 2.5.3 Training for GENI Users...29 2.6 Prototyping GENI Design Concepts...29 2.6.1 Defining and Validating Core Capabilities...30 2.6.2 Validating Critical System Components...30 2.6.3 Integration and Leveraging of Existing Research Facilities...30 3 Deliverables...31 3.1 Definitions of Deliverable Types...31 3 This document's content is out-of-date. Its structure may serve as an example. Page: 3

3.1.1 Preliminary Design Document...31 3.1.2 Facility Design Requirements & Specification Documents...32 3.1.3 Management Requirements & Specifications Documents...32 3.1.4 Work Breakdown Structure (WBS)...33 3.1.5 Bottom-up Construction Budget...33 3.1.6 Management Plans...33 3.1.7 Meetings and Reports...33 3.2 Deliverables Components...34 3.2.1 Reporting and Meetings...34 3.2.2 Preliminary Design Compilation...34 3.2.3 Facility Design Research...35 3.2.4 Facility Design Architecture...35 3.2.5 Facility Design Distributed Services...36 3.2.6 Facility Design Backbone Network...36 3.2.7 Facility Design Wireless Subnets...36 3.2.8 Management Organization CCC...37 3.2.9 Management Organization GPO...37 3.2.10 Management Organization Processes and Procedures...38 3.2.11 Management Organization Transitioning to Operations...38 3.2.12 CCC and GPO Implementation...38 3.2.13 Community Engagement...39 3.2.14 GENI for Education...39 3.2.15 GENI Prototyping...39 3.3 Summary of Deliverables...39 3.4 Budget Breakdown...42 3.5 Schedule Chart...43 4 This document's content is out-of-date. Its structure may serve as an example. Page: 4

Executive Summary This document describes work that will be undertaken during the MREFC Readiness Stage to bring the GENI project to Preliminary Design completion. A companion Project Execution Plan describes the GENI project in much greater detail. This document assumes the reader is familiar with the Project Execution Plan. During the Readiness Stage, the GENI Planning Group will focus its attention on six tasks: (1) producing a Preliminary Design for the GENI facility; (2) producing a detailed management plan, including organizational structure and management processes needed by the project; (3) developing a plan to transition responsibility for project management to a Consortium and Project Office that will oversee GENI during its construction; (4) broadening and further engaging the community that GENI will serve; (5) planning for use of GENI in education, and (6) prototyping key design concepts and technologies needed by the GENI facility. Facility Design: The GENI facility, currently defined at a conceptual level, will be brought to Preliminary Design completion, including the full integration of its core elements: system architecture, backbone, connectivity to edge devices and subnets, network management, user services, and security. This work will be carried out by several Working Groups each responsible for a particular component of the design and will include documenting requirements and specifications for the construction of each facility component, a work breakdown structure for each component, strategies to mitigate risk, a detailed construction budget (including contingencies), and a sensitivity analysis. Project Management: The project management plan will be brought to Preliminary Design. This will involve (1) developing a detailed process for a bottom-up budget, including risk management, work breakdown, and contingency budgeting; (2) defining the scope of the management office s legal responsibilities and incorporating these into the office s definition; (3) developing a scheduling and tracking process and selection of a Project Management Control System (PMCS) for GENI construction; (4) defining a formal Change Control Management process; (5) defining the role of business and industry in GENI; and (6) defining a Systems Engineering Office and its interactions with a Technical Advisory Board and its Working Groups. These tasks will be undertaken by the GENI Planning Group during the first half of the Readiness Stage, resulting in a detailed plan that will be implemented by a permanent GENI Project Office (GPO) in the second half of the Readiness Stage. Consortium and Project Office: Early in the Readiness Stage, NSF will solicit bids for a Computing Community Consortium (CCC) and for a GENI Project Office (GPO). Both of these entities will be established and operational including the appointment of an Executive Council and Technical Advisory Board, and the hiring of a Project Director and Project Manager early in the second half of the Readiness Stage. The newly established GPO will then fully implement the management plans developed by the Planning Group. Community Engagement: Community engagement was started in the Conceptual Design stage with several NSF-sponsored Workshops. This effort will continue in the Readiness Stage, with several additional workshops and town hall meetings already planned. The Planning Group 5 This document's content is out-of-date. Its structure may serve as an example. Page: 5

and its Working Groups will also be expanded to include additional communities, including representatives from industry, education, and international partners. These communities will contribute to the definition and design of GENI. Education: One area of particular importance during the Readiness Stage will be to carefully plan for the use of GENI in education in the classroom, for the general public, and for training of researchers who will use GENI for their work. The Planning Group will form a new working group for this purpose. This group is expected to be composed of senior educators and scientists with special interest and expertise in the use of facilities such as GENI to further education. Prototyping: During the Readiness Stage, work will proceed to leverage existing testbeds (e.g., PlanetLab, ORBIT, DETER, Emulab, and others) to experimentally evaluate key concepts, technologies, and designs that may become a part of the overall GENI facility. The purpose of this activity is to reduce the overall risk in designing and deploying GENI by early evaluation of technologies and designs that are being considered. NSF will develop the processes for selecting promising designs and technologies to be further prototyped, in consultation with the GENI Planning Group. 6 This document's content is out-of-date. Its structure may serve as an example. Page: 6

1 Introduction GENI is an ambitious project. Its goal is to provide a global facility that will revolutionize the research process in global communications networks, potentially leading to a Future Internet that is more secure and robust, easier to use and manage, and better able to support innovative technologies and applications. The reader is referred to the Project Execution Plan (PEP) for a detailed description of the entire project. This Project Development Plan (PDP) describes work to be undertaken in the MREFC Readiness Stage to bring GENI to the completion of Preliminary Design. 1.1 Scope of Work During the Conceptual Design Stage, the GENI Planning Group representing a cross-section of the Computer Science research community worked for a year to develop the fundamental concepts of GENI. The group was informed by a series of NSF workshops that explored various research challenges faced by the community. The Planning Group identified the basic architecture of the facility, the types of network elements required by researchers, the means by which it could be shared among a large community of researchers, the means by which the network would be managed, and in broad terms, many of the project management issues that would need to be addressed in future planning periods. In the Readiness Stage, these basic concepts will be re-examined and brought to the next level of definition. This effort, scheduled over the next 12 months, will be organized around six principle tasks: Producing a Preliminary Design for the GENI facility, including its overall architecture, engineering, principal platforms, network management, and distributed services. The Preliminary Design will also include a detailed work breakdown structure, bottom-up budget, risk analysis, and contingency plans. Producing a Preliminary Design for the management of the GENI project, including the further definition of the management team s organizational structure, a detailed plan for defining a work breakdown structure and bottom-up budget, comprehensive risk analysis and contingency plans, and selection of an appropriate project management control system. Supporting the establishment of a permanent Computing Community Consortium (CCC) and GENI Project Office (GPO) that will oversee GENI during its construction. Responsibility for GENI s definition and management plan will be transitioned to the CCC and GPO during the Readiness Stage. Broadening the community that GENI will serve, and further engaging this community in the definition of GENI. Including more people with security expertise in the planning process is of the highest priority. Planning for use of GENI in education, including the classroom, communicating the goals and value of GENI to the public, and training the user community. 7 This document's content is out-of-date. Its structure may serve as an example. Page: 7

Prototyping key design concepts and technologies needed by the GENI facility, thereby reducing the risk of the less mature concepts. 1.2 Processes and Procedures The Readiness Stage will consist of two distinct phases. The first phase will be carried out by the current Planning Group (and its Working Groups), augmented by full-time staff with additional management expertise. Additional technical experts will be added to the working groups, as needed. The second stage will begin with the establishment of a Computing Community Consortium (CCC), the appointment of a Project Director (PD) and Project Manager (PM), and the establishment of the GENI Project Office (GPO). The transition from the first to second phase is expected to occur at approximately the midpoint of the Readiness Stage (August 2006). During the first phase of the Readiness Stage, the project will continue to be led by the Planning Group, with its Chair overseeing and directing the effort. The Working Groups convened during conceptual design stage will continue to work on the definition of the GENI facility, with the Planning Group conducting internal reviews to ensure that all design issues outlined in this document are being addressed. It is expected that additional working groups (and subgroups) will be formed as needed to address emerging issues (e.g., education). The Planning Group also expects to make judicious use of external experts to address issues where the group does not have the requisite expertise, particularly in the definition of a comprehensive management plan. Overall, the Planning Group will work to ensure that a broad community contributes to the design of and planning for GENI. In the second phase of the Readiness Stage, the Planning Group will support the transition of responsibility for the GENI project to a CCC and GPO. The CCC will provide community oversight for the project, including the establishment of an Executive Committee (EC) and Technical Advisory Board (TAB). The TAB will then subsume the Planning Group s role of reviewing and directing Working Group activity, and the GPO will take responsibility for implementing the management plan developed by the Planning Group. Finally, the Project Director and Project Manager, in consultation with the TAB and GPO, will compile and reconcile the work breakdown structures, schedules, risk analyses, and construction budgets across the set of Working Groups to produce a Preliminary Design for GENI. 1.3 Documentation and Reporting Requirements, specifications, and management processes developed during the Readiness Stage will be documented and shared with the National Science Foundation, experts in the broad technical and management communities, and the broader research and education community. This includes a series of regular project reviews, reports to interested communities, workshops, and presentations at technical conferences. All requirement and specification documents that are appropriate for community review and comment will be published in a GENI Design Documents (GDD) series modeled after Request for Comments (RFC) series published for today s Internet. 8 This document's content is out-of-date. Its structure may serve as an example. Page: 8

In addition to publishing the GDD series, reporting to the NSF will include: (1) weekly conference calls for project updates, (2) written monthly progress reports; (3) face-to-face quarterly reviews; (4) monthly prototyping status reports; (5) timely sharing of information from Town Hall meetings, including how meeting results will be used to update facility design; and (6) collaboration with NSF s Cyber Security Working Group related to security designs for GENI. During the final three months of the Readiness Stage, the individual documents and reports identified in this PDP will be compiled into a complete MREFC Readiness Stage Preliminary Design for GENI. The specific elements are identified in Section 3, and include (1) Facility Design Requirements and Specifications, (2) Management Requirements and Specifications, (3) Bottom-up Construction Budgets, (4) Work Breakdown Structures for Construction, and (5) assorted Management Plans. 1.4 Project Teams & Personnel Readiness Stage tasks will be undertaken by a combination of project teams and personnel, which we now summarize: Planning Group: The set of researchers and management experts responsible for this PDP and the companion PEP. This group will oversee and direct further development of GENI during the first phase of the Readiness Stage, including external review of documents produced by the Working Groups and Project Management Team. The responsibilities of the Planning Group will transition to various entities within the Computing Community Consortium and GENI Project Office once they are established. The Planning Group Chair is responsible for coordinating the group s work. Working Groups (WG): A set of focused groups responsible for various aspects of GENI s design. These groups report into the Planning Group today, but will report to the Technical Advisory Board (TAB) of the Consortium once it is formed. These groups will be augmented with professional staff that will assist the Working Groups in achieving their deliverables. Working Groups include: Research Coordination Working Group (RCWG) Facility Architecture Working Group (FAWG) Distributed Services Working Group (DSWG) Backbone Network Working Group (BNWG) Wireless Subnet Working Group (WSWG) Education & Outreach Working Group (EOWG; to be established) Project Management Team (PMT): A new team to be formed during the Readiness Stage to focus on developing a management plan for GENI. The PMT will consist of members of the current Planning Group, augmented by full-time staff with the necessary management expertise. The PMT will primarily define the requirements for project management during the first phase of the Readiness Stage, with the actual implementation left to the GPO during the second phase. 9 This document's content is out-of-date. Its structure may serve as an example. Page: 9

Computing Community Consortium (CCC): A community consortium that will provide community oversight for the project, including the establishment of an Executive Committee (EC) and Technical Advisory Board (TAB). The EC will be responsible for appointing a Project Director (PD) and Project Manager (PM). We expected the CCC to be created near the midpoint of the Readiness Stage and subsume responsibility for GENI during the second phase of Readiness. Technical Advisory Board (TAB): Is responsible for the technical design of the GENI facility, with members appointed by the CCC s Executive Committee. Includes leaders of the various Working Groups. The TAB subsumes responsibility for GENI s design from the Planning Group near the midpoint of the Readiness Stage. The chair of the TAB serves as Chief Architect for the facility. GENI Project Office (GPO): Is responsible for the management of GENI during construction, and subsumes responsibility for implementing the management plan developed by the PMT near the midpoint of the Readiness Stage. Project Director & Manager (PD/PM): Appointed by the CCC, the Project Director and Project Manager direct the construction of GENI, assuming responsibility from the chairs of the Planning Group and PMT near the midpoint of the Readiness Stage. The PD and PM, in consultation with the TAB and GPO, will compile and reconcile the work breakdown structures, schedules, risk analyses, and construction budgets across the set of Working Groups to produce a Preliminary Design for GENI. Figure 1.1 Team relationships and responsibilities during the Readiness Stage Figure 1.1 portrays the transition in team relationships and responsibilities that will take place midway through the Readiness Stage. In phase 1, each WG includes one or more staff members 10 This document's content is out-of-date. Its structure may serve as an example. Page: 10

that are responsible for writing specifications, WBS, creating schedules, and interfacing with the PMT; in phase 2, these duties are subsumed by the PD and PM. The CCC and GPO in phase 2 are essentially peer organizations, with the TAB and WGs serving as links between them. 2 Execution of Readiness Stage Tasks Several tasks make up the Readiness Stage work. Tasks relating to the technical design of the GENI facility will be assigned to one or more Working Groups (WG), with some groups still to be established during the Readiness Stage. The leader of each WG is responsible for its deliverables. During the first phase of the Readiness Stage, WG leaders will serve on the Planning Group. The Chair of the Planning Group will be responsible for directing progress on the development plan, and the Planning Group as a whole will internally review all designs, requirements, and specifications produced by the individual Working Groups to ensure that they are consistent and sufficiently detailed. During the second phase of the Readiness Stage once the CCC, TAB, and EC have been established and a PD appointed the Working Groups will report into the TAB, which will then internally review all documents. Tasks relating to a management plan for GENI will be carried out by a Project Management Team (PMT) during the first phase of Readiness, and transitioned to the GPO once it is established. The PMT will consist of members of the current Planning Group, augmented by full-time staff with the necessary management expertise. The PMT will primarily define the requirements for project management, with the actual implementation left to the GPO during the second phase of the Readiness Stage. The tasks are described in more detail in the following sections. Table 2.1 summarizes how tasks are associated with Working Groups, the Project Management Team, and the National Science Foundation. All of these tasks culminate in the Preliminary Design for GENI. A precise statement of the deliverables described in this section is presented in Section 3.2, and a corresponding timeline is given in Section 3.3. Task Readiness Stage Sub-Tasks Responsible Groups 1 Research Requirements & Rationale Architecture Distributed Services Backbone Network Wireless Subnets 2 Organizational Structure GENI Project Office Definition Management Processes & Procedures Transition to Operations Plan GENI Project Office Transition 3 Computing Community Consortium GENI Project Office Research Coordination WG Facilities Architecture WG Distributed Services WG Backbone Network WG Wireless Subnets WG Project Management Team National Science Foundation 11 This document's content is out-of-date. Its structure may serve as an example. Page: 11

4 Broad Community Engagement Research Coordination WG 5 GENI for Education Education & Outreach WG 6 Prototyping GENI Design Concepts National Science Foundation & Selected Project Teams 2.1 Facility Design Table 2.1 Working Groups associated with Readiness Stage Tasks The GENI facility includes: (1) a backbone network and all of its network elements (e.g., programmable routers and dynamic optical switches), as well as connections to edge devices, the legacy Internet, and wireless subnets; (2) management software that provides an overall control structure for GENI; (3) a diverse collection of wireless subnets that connect to the GENI backbone; and (4) distributed services that facilitate the use of GENI for research and education. In addition to these components, there is an overall facility architecture that defines how the individual components connect to form a coherent whole. During the conceptual design stage, the Planning Group developed the basic concepts for GENI, including its future use, what features and functions it had to have in order to be useful to the research community, and what fundamental technologies would be required for it to work. In the Readiness Stage, the Planning Group through the efforts of several Working Groups will complete the Preliminary Design of the facility, including the development of specifications for all of the hardware and software components (including those that might be added during the Readiness Stage in order to fulfill facility use requirements). This information will be documented in a set of GDDs. The Working Groups will also provide detailed work breakdowns, budgeting information (including sensitivity analysis), risk analysis, and contingency plans for inclusion in project s overall management plan (see Section 2.2). Developing a sound risk management plan for the software development process will be a major focus of this effort. 2.1.1 Research Requirements & Rationale The principal capabilities of the GENI facility were identified during the Conceptual Design stage by the GENI Planning Group, based on a synthesis of requirements that came out of a series of NSF-sponsored workshops. While this group tried to ensure that the architecture met the needs of the entire research community, one of the critical tasks during the Readiness Stage will be to further refine the requirements and corresponding facility capabilities based on community feedback. The Research Coordination WG will be primarily responsible for these tasks, where a precise list of deliverables corresponding to the following narrative is given in Section 3.2.3. 12 This document's content is out-of-date. Its structure may serve as an example. Page: 12

A series of town hall meetings, plus a community web page and mailing list have been established to provide a forum for collecting community feedback. These forums are important not only to ensure that a larger community has an opportunity to influence and contribute to GENI s design, but also to gain a better understanding of the projected needs of research on the GENI facility. A key role of the Research Coordination WG is to synthesize the community s feedback into a concrete set of required capabilities. The individual working groups will use the resulting set of requirements to refine the definition of the facility, as enumerated in following sections. One specific requirement that we call out for attention is that of instrumentation. From the beginning of the project, it has been an architectural principle that a measurement capability be an integral part of the GENI design. During the Readiness Stage, we will need to determine which measurements are most important to include in GENI, what physical components should incorporate this capability, and how will experimenters (or network operators) access and control the measurement sensors? We will also need to define a process for aggregating, archiving, and analyzing data that is collected. Aspects of this problem fall across all of the working groups, although the Research Coordination WG has oversight responsibility to ensure that the right data is being collected and archived. Finally, a critical aspect of defining the research community s requirements is to further refine the scientific rationale for GENI. This will involve identifying representative experiments that researchers want to run on GENI, articulating the broader research questions that the community hopes to address, and explaining how a large-scale experimental facility like GENI has the potential to qualitatively change the research modality of the networking systems community. 2.1.2 Facility Architecture GENI is defined by a diverse and extensible collection of physical network resources, collectively called the physical substrate. A core set of software, called the GENI Management Core (GMC) knits these components together to form a coherent experimental facility. The GMC adheres to a well-defined architecture that specifies how physical components, user-level services, system-wide security, and a federation of similar facilities owned by organizations fit together. To construct GENI, it will be necessary to completely specify this architecture, which corresponds to sets of principals, abstractions, software modules, and object interfaces. These specifications will be fully documented in a set of GDDs. The following summarizes the key requirements and specifications that must be completed during the Readiness Stage. In addition to these specifications, it will also be necessary to define a work breakdown structure, prepare a bottomup budget (including sensitivity and contingency analysis), and complete a risk management plan for the software management framework that embodies this architecture. The Facility Architecture Working Group will be primarily responsible for these tasks, where a precise list of deliverables corresponding to the following narrative is given in Section 3.2.4. Management Core: The GENI Management Core (GMC) defines name spaces for users, slices, and physical components. It is, in many respects, at the heart of the GENI architecture. The 13 This document's content is out-of-date. Its structure may serve as an example. Page: 13

interfaces by which the GMC interacts with individual components are therefore critical to the ability of the operations team to manage GENI, as well as the ability of researchers to create slices that span all of GENI s physical substrate. During the Readiness Stage, the Facility Architecture WG is primarily responsible for defining these interfaces, and ensuring that they are sufficiently general to accommodate a wide range of component devices. Virtualization: Virtualization is a technique that allows a resource to be sliced into many parts, each one of which can then be assigned to a single (or group of) researcher(s) to use. During the Readiness Stage, several issues regarding virtualization will be resolved: How deep does virtualization need to penetrate into the components, and what capabilities are lost if devices are virtualized at too high of a level? What are the implications for complexity, cost, performance, and interoperability of alternative levels of virtualization? We plan to evaluate these and similar questions during the Readiness Stage to reach a preliminary architecture design. Answers to these and related questions will impact the complexity of the design, its cost, and the overall performance anticipated from the facility. This question will be addressed for each physical component by the working group responsible for that component, with the Facility Architecture WG responsible for the overall design. Extensibility & Modularity: Extensibility is a feature of GENI that allows it to easily accommodate changes in technology as they emerge, before, during and after construction. This feature is very closely tied to the modularity of the architecture. The central question to be addressed is: What modularization and interfaces make it possible for one component to be substituted for another as new technologies emerge? This issue is at the heart of the architectural specification produced by the Facility Architecture WG. Programmability: Programmability of network elements is an important architectural capability of GENI. Components must expose capabilities that researchers can program (control) in an experiment-specific way. Most commercial network elements are not yet fully programmable, or do not provide open interfaces, although there is a trend in this direction. The question is, what level of programmability should a network element provide, and in what ways is the answer different for each component of the system. Questions such as these will be reviewed and answered during the Readiness Stage in collaboration with Backbone and Wireless WGs responsible for defining the technology of the various network elements, with the Facility Architecture WG responsible for the overall design. Controlled Interconnectivity: The concept of controlled interconnectivity has two parts: one refers to the ability of a researcher to determine the network topology and the selection of nodes that his or her experiment will span; the other refers to the interconnection between slices that run different network architectures or services. The questions to be addressed during Readiness will focus on the degree of interconnectivity and to what extent connectivity should be in the hands of the user versus under some sort of centralized control. All of the working groups must address these questions relative to their respective components, with the Facility Architecture WG responsible for the overall design. Federation: GENI will support federation, meaning that it will be possible to plug other communities (and their resources) into a common, shared infrastructure. This feature helps to sustain GENI over time as new research communities opt-in to GENI and bring with them 14 This document's content is out-of-date. Its structure may serve as an example. Page: 14

new resources, and as international partners want to contribute resources to a world-wide effort. The question that needs to be addressed in the Readiness Stage deals with the details of federation, including both mechanisms (i.e., interfaces) and policies (i.e., establishing peering agreements among partners). The Facility Architecture WG group has overall responsibility for federation. Security: The security of the GENI facility must be assured as part of the GENI Facility Design. This requires addressing a set of issues, starting from first principles. What should GENI components and central management provide as building blocks for security? What is the GENI security architecture, and how far can we move this from current user practices? The Facility Architecture WG, in collaboration with the Distributed Services WG will consider these questions. In addition, the National Science Foundation is well aware of its facilities being hacked (and the consequences thereof). The GENI working groups will work with the NSF security team during the Readiness Stage to ensure that the recommendations of this group are carefully considered in a secure design. Additional security experts will be added to the Working Groups to help specify security for the facility. 2.1.3 Distributed Services GENI is expected to be used by a broad spectrum of researchers, educators, and students, many of whom will have had little experience using large shared network facilities for their work. It will be important, therefore, to make GENI as user-friendly as possible, so that new work is not stymied by the complexities of accessing the facility. To this end, developing a set of distributed (user) services is a critical part of GENI s design. In the Readiness Stage, the task is to completely describe in terms of requirements and specifications how these services provide value to the user (researcher, educator, student) communities. The task also includes defining a work breakdown structure, preparing a bottom-up budget (including sensitivity and contingency analysis), and completing a risk management plan for the set of distributed services. The Distributed Services Working Group will be charged to carry out this work. A precise list of deliverables corresponding to the following narrative is given in Section 3.2.5. In GENI, distributed services serve two key roles. First, they include a set of infrastructure services that researchers use as a portal to create and access slices of the GENI substrate, and network operators use to monitor, configure and diagnose the system. Second, they include a set of underlay services that serve as building blocks for researchers as they design and implement their experimental network architectures, allowing them to focus on new functionality rather than having to recreate a network architecture, service or application from scratch. The key steps to more fully defining these services during the Readiness Stage include: (1) identifying the essential facilities that the GENI Management Core (GMC) must provide to enable the distributed services; (2) fully specifying the baseline set of distributed services to be constructed for the GENI facility; and (3) defining a timeline over which the distributed services will make new capabilities available. We also envision that the set of services will eventually be contracted to multiple teams (e.g., one per service area), and thus we will carefully define the specific requirements of each and the inter-relationship between each of those service areas. To the maximal extent possible, we will expect each development team to leverage the efforts of other development teams. 15 This document's content is out-of-date. Its structure may serve as an example. Page: 15

To date, we have identified eight broad focus areas for distributed services. Each of these will be considered in detail during the Readiness Stage and (assuming each survives this scrutiny) specifications will be written for its implementation, including cost, and related items as described above. Provisioning Service: Used by researchers and students to create, initialize and manage a slice on a set of GENI resources; Information Plane: Used by researchers and the GENI operations team to monitor the health of nodes and the slices running on them; Resource Broker: Used by researchers and students to acquire and schedule GENI resources, and by the GENI governing board to set resource policy; Development Tools: Used by researchers and students to develop and debug their experiments; Security Service: Provides a set of security mechanisms to provide strong authentication and authorization; Topology Service: Provides information about which neighbors exist in the network and the properties of the links that connect them; File and Naming Service: Implements a core set of distributed storage and rendezvous services to enable experiments to load code onto the system and log output to a persistent virtual disk ; and Legacy Internet Service: Implements the data and control plane of today s Internet in a slice on top of the GENI substrate to allow GENI to bootstrap itself. By the end of the Readiness Stage, we will compose a final list of focus areas, and for each focus area, a list of requirements, a design meeting those requirements, high-level interfaces between focus areas and the GENI Management Core, a Work Breakdown Structure and schedule, a construction budget (including a sensitivity analysis), and a risk analysis along with contingency plans. All these elements will address the dependencies between deliverables of individual implementation teams to be tasked with each focus area. 2.1.4 Backbone Network The GENI backbone consists of a nation-wide fiber plant, a collection of customizable routers and dynamically controllable switches, peering connectivity to the commodity Internet, and tail circuits to edge sites around the world. During the Readiness Stage, the task is to bring the elements of the GENI backbone to Preliminary Design completion. The focus will be to create a complete set of design requirements and specifications for construction of the backbone, including its connections to edge devices, subnets (wired and wireless), and the legacy Internet. In addition to these specifications, it will also be necessary to define a work breakdown structure, prepare a bottom-up budget (including sensitivity and contingency analysis), and complete a 16 This document's content is out-of-date. Its structure may serve as an example. Page: 16

risk management plan related to backbone construction. The Backbone Network WG will be primarily responsible for these tasks, where a precise list of deliverables corresponding to the following narrative is given in Section 3.2.6. To accomplish the Readiness Stage work, the Backbone Working Group has identified several issues that it will resolve, as discussed below. Completion of each of these work items is important to the development of requirements for the backbone, and for preparation of specifications that could be used to construct the backbone (e.g., by an external contractor). Network Elements: During the Conceptual Design Stage, three main types of backbone equipment were identified for use in the GENI backbone: (1) high-speed programmable routers that can support multiple simultaneous experiments with new network architectures, (2) crossconnects to allow experiments to establish circuits with dedicated bandwidth between GENI nodes, and (3) reconfigurable optical add-drop multiplexers and dynamic optical switches to allow multiple experiments to share control of optical components. Each of these elements is expected to require performance at a level that is not expected to be available commercially and, therefore, will be designed and constructed as part of the overall backbone work. During the Readiness Stage, each of these network elements will be considered in detail, both in terms of the requirements for their individual performance and features, and in terms of their interworking with other elements in the network. Thus, the WG will be required to develop specifications for the individual network elements and for the interfaces between/among them. To accomplish this, the working group will assess the capabilities of existing commercial equipment and industry trends to determine which components might serve as hardware building blocks. For example, the group will investigate the availability and features of components (such as network processors and field-programmable gate arrays) that are compliant with the ATCA standard for telecommunications equipment. The group will study existing cross-connect equipment, and the associated element management systems, to determine the extra features necessary to provide each experiment with the abstraction of a virtual cross-connect for creating end-to-end circuits between sites. The group will also explore the unique capabilities needed from the optical components to make efficient use of the widearea bandwidth and enable researchers to experiment with dynamic control over optical components. During the Readiness Phase, the working group will assess the availability, functionality, and cost of these three classes of network elements to specify the hardware components needed in the more-advanced, customized GENI nodes. The benefit of this work will be to identify those components, or classes of components, that will be available and suitable for the design of construction of the GENI custom network elements. Such conclusions will be incorporated in the specifications for the design of GENI network elements. Timeline for Technology Insertion: Researchers will begin using GENI for experiments as the facility is being constructed and deployed. This is a unique feature of GENI. As such, GENI will start with a simplified node architecture, such as software routers built out of conventional computing platforms, and evolve toward a sophisticated design with hardware routers, crossconnects, and optical components. In addition, the GENI software running in the nodes will evolve over time to provide a finer granularity of control over the underlying equipment. During the Conceptual Design stage, we outlined a high-level timeline for adding new 17 This document's content is out-of-date. Its structure may serve as an example. Page: 17

hardware and software components to the node, motivated by the cost and availability of commercial hardware and the functionality required by the majority of potential research experiments. During the Readiness Phase, the Backbone WG will construct a detailed timeline for technology insertion, based on component availability, cost and the complexity of the new functionality. The results of this work will be important to the management of the GENI facility during construction, where both construction and operations will be taking place simultaneously (see Section 2.2.4). Trade-offs between Flexibility and Complexity: To support a wide range of research experiments, GENI needs to provide researchers with programmable control over the operation of the underlying equipment and sub-divide physical resources (e.g., CPU, disk, bandwidth, and circuits) at a fine level of granularity. However, there is an inherent tension between the desire for such flexibility and the potential complexity of the underlying hardware and software in the infrastructure. During the Readiness Phase, the Backbone WG will evaluate these trade-offs by means of a sensitivity analysis to help make an informed decision about how to strike the right balance, and how to increase the sophistication of the GENI node over time. Connecting Edge Sites and the Legacy Internet: A key feature of the GENI infrastructure is the ability to carry real user traffic and provide novel services to end-users. It will be important to evaluate a variety of options for high-bandwidth connectivity to end users and the legacy Internet. For example, direct tail circuits could provide high-bandwidth connections to the sites where flexible edge devices and wireless subnets are located. Existing regional exchange points and education-and-research backbone networks may provide a way to contain the costs of reaching these end-user sites. Connections to legacy Internet Service Providers, at major colocation sites and public exchange points, can provide a way to reach the legacy Internet and GENI-like facilities in other countries. During the Readiness Phase, the Backbone WG will produce accurate cost estimates for the various options and explore ways to reduce the cost by exploiting existing network infrastructures and carefully identifying possible locations for GENI backbone nodes. 2.1.5 Wireless Subnets Wireless devices and networks are a critical part of any future global network. During the conceptual stage of planning for GENI a series of community workshops produced reports outlining the network architecture challenges related to wireless, mobile and sensor scenarios, and proposed a set of specific wireless subnet implementations for GENI. The workshops recommended the construction of five types of wireless subnets: (1) large-scale wireless emulators; (2) Open API urban deployment using short-range radios (such as 802.11x); (3) Open API suburban wide-area deployment using long-range radios (such as WiMax or 3G); (4) cognitive radio demonstrator networks for suburban wide-area scenarios; and (5) sensor networks for dense urban and vehicular scenarios. High-level wireless subnet architectures and hardware platforms were specified for each case. Critical path technology components for each of these projects were listed and, in many cases, existing NSF-supported results to mitigate technical risk and improve readiness were identified. During the Readiness Stage, the main task is to identify the requirements for all subnet components and their connections, both within the subnet and to the GENI backbone, and to prepare design specifications for each of these components and their interfaces. It will also be 18 This document's content is out-of-date. Its structure may serve as an example. Page: 18

necessary to define a work breakdown structure, prepare a bottom-up budget (including sensitivity and contingency analysis), and complete a risk management plan for each major wireless subnet component. The Wireless Subnet Working Group will be charged to carry out this work. A precise list of deliverables corresponding to the following narrative is given in Section 3.2.7. There are three overriding questions to be addressed to bring the wireless components of GENI to Preliminary Design. They include: Platform Evaluation: This task involves aggregation of applicable experimental platform results from the wireless research community and conducting small incremental projects to extend features (such as soft MAC or virtualization) and validate feasibility for GENI. Incremental short-term projects for development of critical platform technologies and open interface radios may be proposed to NSF during the course of this task. During the Readiness Stage, the Wireless WG will specify the wireless platforms and radio techniques to be deployed in GENI. Virtualization Evaluation: All wireless components planned for GENI are fully programmable, with capabilities for remote code downloading, reboot and remote monitoring and measurement. This makes it feasible to extend GENI s uniform slice abstraction (and management framework) across the wireless components of GENI. The open question to be addressed by the Wireless WG during the Readiness Stage is how to implement slicing on different technologies. Specifically, virtualizing the underlying hardware is one way to slice a resource, but other techniques e.g., spatial sharing can also be used to multiplex resources among multiple experiments. By choosing slicing strategies appropriate to experimenter requirements and technology capabilities, GENI will be able to integrate and unify an extremely heterogeneous physical resource base. The current consensus is that virtualization suitable for certain long-term service experiments is indeed possible, but virtualization can interfere with the accuracy of protocol experiments that involve short-term performance. For these cases, alternative slicing techniques will be required. For example, since wireless deployments will have numerous radio nodes and sensors, it is feasible to use spatial sharing, in which physically disjoint nodes are used to connect to different long-running slices in the wired network. Also, for radios with a reasonable number of orthogonal channels in the band (for example, 802.11a in the 5 Ghz band), frequency domain slicing with multiple radio platforms is also an option. Integration: An aspect for wired-wireless integration in GENI is the unification of the control protocols used to manage slices in a way that provides support for various radio specific requirements and multiple slicing techniques. During the Readiness Stage, collaboration between the wired and wireless network communities will be needed to ensure a broad enough definition for the GENI Management Core, and to define the management protocols needed to unify all of GENI under the common slice abstraction. 2.2 Management Plan The management structure for GENI was developed during the Conceptual Design stage. The reader is referred to the PEP for a detailed discussion of GENI management. 19 This document's content is out-of-date. Its structure may serve as an example. Page: 19

In way of an overview, the management structure of GENI consists of the following elements. A Computing Community Consortium (CCC) provides broad community representation, and establishes an Executive Committee (EC) to provide oversight for the project. The EC appoints the Project Director and Project Manager, and establishes a Technical Advisory Board (TAB), the latter of which provides technical leadership for the project and has overall responsibility for the facility s design. A GENI Project Office (GPO) 1 oversees the construction of the facility, managing the sub-contractors, defining milestones, and ensuring that work is completed on schedule. This section focuses on the GPO-related work items that must be completed during the Readiness Stage. These include developing the requirements for each function of the management organization and preparing specifications for these functions; developing a detailed bottom-up budget for the management functions that define the GPO; developing a work breakdown structure (WBS) for the management structure; developing an implementation plan for the GPO functions; carrying out a sensitivity analysis that explores alternative methods for implementing management functions; creating a risk analysis for the GENI project, and developing a contingency plan for the project budgeting process. As a permanent GPO does not yet exist, we will proceed through the Readiness Stage in two phases. In the first phase, we will assemble a Project Management Team (PMT) to develop requirements for each element of the management plan and to prepare written specifications for these elements. This PMT will complement the Working Group efforts outlined in Section 2.1. The PMT will consist of members of the current Planning Group, augmented by full-time staff with the necessary management expertise. In parallel with this effort, NSF will solicit bids to establish a permanent CCC and GPO, with both expected to come on-line at the midpoint of the Readiness Stage (approximately August 2006). At that time, responsibility for the management plan will transition from the PMT to the GPO. It is expected that the GPO will then implement the project management functions specified during the first phase. This section focuses on the management-related tasks to be undertaken by the PMT/GPO during the Readiness Stage. Section 2.3 discusses the process of establishing the CCC and GPO. 2.2.1 Organizational Structure The first major task is to more thoroughly define the organizational structure of GENI s management. This involves identifying the essential roles and defining the relationships among them. They include: Computing Community Consortium: Planning for specification of a CCC will be undertaken starting soon after the Readiness Stage commences. There will be four focal points: (1) understanding of the role and responsibilities of the CCC; (2) developing of high-level job descriptions for future CCC members and committees; (3) defining the responsibilities of other components of the GENI management structure, including the Project Director, the Project 1 We use the term GENI Project Office (GPO) in this document in place of Project Management Office (PMO) used in the Project Execution Plan. 20 This document's content is out-of-date. Its structure may serve as an example. Page: 20