|
|
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.
|
