*GENI PLANNING GROUP DOCUMENTS ARE NO LONGER CURRENT. See GpoDoc and the GENI project pages for up-to-date documents and specifications.*

Facility Requirements

To support a research process that provides a smooth path from concept to practice, simulation and emulation must be augmented with live systems that can be deployed on a wide-area facility, allowing for real users and real-world experiments at scale. This facility must be heavily instrumented to produce the measurements needed as input to the next round of simulations. Because applications, services, and architectures running on the facility are operating at large scale and in the real world, there is an increased likelihood that successful ones will make the transition to wider deployment, possibly even using the same infrastructure technology as GENI itself. Without such a facility, research ideas will stay in the ephemeral state, never validated to the degree of realism or the scale needed to convince industry or standards bodies.

Toward this end, GENI must provide an environment in which multiple new network architectures and services can be deployed, with as few restrictions as possible on the experiments. GENI must include a diversity of link and node technologies, and permit connection of arbitrary edge devices and networks. GENI must be designed to bridge the gap between production testbeds (which constrain research), and research testbeds (which constrain users). It must be capable of attracting and supporting users of its services beyond the research community. This is essential for allowing new innovations to be evaluated at scale, and for creating a population of users whose demonstrated interest in a new capability can stimulate technology transfer to the commercial sector.

GENI will provide an environment in which a diverse set of experimental archiectures, services, and applications can operate. GENI will consist of a collection substrate resources, including nodes, links, and edge subnets. Each experiment will run in a subset of the GENI resources. We call the resources bound to a particular experiment a slice. GENI slices will constrain the hosted activities to the minimum extent possible, and provide for varying degrees of isolation and interconnection among these activities. The common part of GENI provides the mechanisms for allocating and configuring slices and ensuring the necessary isolation.

GENI should be viewed as a dynamic artifact: the physical resources, management capabilities, implementation, and even the design itself will evolve over time. The physical resources in GENI will include a mix of dedicated physical links and nodes, virtual components contributed on a permanent or temporary, and diverse edge systems such as wireless and sensor networks. The substrate and management infrastructure will incorporate standard service policies and interfaces to enable organic growth, provide incentives to new communities to contribute, and manage dynamic resources available to GENI on a temporary basis under various terms.

In summary, GENI has the following requirements:

• Service/architecture neutrality: What is most important for research in network architecture and services is that the level of abstraction be low enough to permit full experimentation. Different slices of the GENI may support different experiments at the same time.
• Edge diversity: GENI should enable heterogeneity in the end systems that connect to it and participate in the experiments running within it. In particular, it should enable the connection of limited functionality end-systems (such as wireless PDAs and sensors) connected by a variety of technologies (such as wireless and sensor networks).
• Ease of user access: Mechanisms are needed to make it easy for users to join one or more experimental services running in GENI, and to transparently fall back to the legacy Internet whenever the experimental network cannot provide the requested service.
• Instrumentation and data analysis: The GENI substrate, along with all the architectures and services deployed on it, must be heavily instrumented. The generated data must be collected and archived, and analysis tools developed.
• Federation and Sustainability: To ensure the sustainability of GENI, it should be possible for participating institutions to contribute resources in return for access to the resources of the GENI as a whole. In general, it should be possible for other research communities to "opt-in" by connecting their purpose-built networks (including dedicated transmission pipes and sensor networks) into the GENI substrate and running their applications and services in a slice of GENI.
• Inter-slice composition: GENI must enable interconnection among slices by mutual consent, and between slices and the legacy Internet. This permits slices to host network services with external users, and/or to act as transit networks. Nothing should prevent a researcher from inter-connecting a virtual network running within a slice with another network. This other network could be running within another slice of GENI, or it could be the legacy Internet or another custom network (or testbed) that runs over standard IP protocols.
• Policy and governance: Since GENI will comprise shared infrastructure, there must be a governance process to guide allocation of resources to slices, and a software architecture that implements and enforces the policies. Some slices will likely require strong performance isolation, which will make some form of admission control necessary.