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

Facility Snapshot

[This page summarizes the current snapshot of GENI's design. A more complete description, as of 10-January-2006, is also available.]

GENI must be designed to allow researchers to assemble a widely distributed set of resources into a "virtual network". Researchers do this by acquiring a slice of the GENI substrate, and running the experimental network application, service, or architecture in that slice. Thus, the resources that make up the GENI substrate must span the full spectrum of existing and imagined network technologies, so as to not overly constrain the virtual networks that researchers can build. This requirement introduces a significant complication into the design of GENI, because no single category or class of existing hardware can meet it. Further, as new technologies are developed and mature, the bounds of what constitutes a network are stretched, and any static, rigid deployment of infrastructure for GENI risks becoming obsolete.

To meet this requirement, the basic design of GENI will be divided into two parts: (1) a physical network substrate, and (2) a global management framework. The first part, the GENI substrate, will consist of an expandable collection of building block components. Although no single building block could do so by itself, the set of building blocks chosen for inclusion within GENI at any given time are intended to allow the creation of virtual networks covering the full range needed by the researcher. The second major part of GENI, the management framework, knits the building blocks together into a coherent scientific instrument -- a single global-scale facility that is capable of supporting the complete research cycle. The management framework is primarily implemented in software.

Note that the GENI project development plan requires that GENI be defined with a certain level of specificity, but everyone understands that the underlying technology is likely to change rapidly, and that the requirements the community places on GENI will continue to mature. Therefore, the following should be read as a snapshot of the GENI facility as of January 2006. This site will post future snapshots as they come into focus.

Physical Substrate

While GENI is designed to allow new building blocks to be added over time to reflect changing needs and new technology, we propose an initial set of building blocks that can be divided into three broad categories: one or more node technologies, a variety of wireless subnet technologies, and a mix of link technologies. We expect to configure the GENI substrate to include a nation-wide backbone network with at least one lambda (10Gbps) of capacity available between one to two dozen Points-of-Presence (PoP). Each PoP, in turn, will host a high-speed forwarding node, where we envision two candidate node technologies: one based on customizable high-speed hardware, and a second based on emerging optical switches. Edge sites (e.g., university campuses) will host GENI nodes with significant compute and storage resources (i.e., various-sized clusters of commodity PCs). These edge sites will connect to the nearest backbone PoP using the most appropriate tail circuit technology -- e.g., MPLS or FrameRelay circuits with 45-155Mbps of capacity -- as well as by tunneling through today's Internet. These edge sites will not be limited to the U.S., but will also include international sites, giving GENI global reach. Additional edge sites will host wireless subnets of different types, including urban 802.11-based ad hoc meshes, suburban subnets based on 3G and WiMax, sensor networks, and subnets built around cognitive radios. Finally, the national backbone will be connected to the legacy Internet by connecting the nodes at one or more PoPs to an Internet Exchange (IX), thereby providing connectivity to multiple commercial ISPs.

The following figure gives the perspective of a single !PoP, which might connect to (clockwise, from top right) a sensor network, a traditional wired network of workstations, and a wireless network. Packets flow between GENI nodes located on each network and the high-speed forwarder at the PoP over circuits (fat blue lines) or tunnels (thin black line). The forwarders at various PoPs communicate via the national backbone.

The rationale for this global configuration of building blocks is straightforward. A national backbone of at least 10Gbps capacity is required to support research in network design (e.g., routing, failure recovery, network management, and so on), to validate solutions at realistic forwarding speeds, and to carry traffic between edge systems. The clusters running at edge sites serve two purposes. First, they act as "ingress routers" for local users wishing to take advantage of architectures and services running on GENI. Second, they serve as overlay nodes that host broad-coverage network services and applications that require many points-of-presence through the network. The set of wireless subnets span the spectrum of available and emerging technologies, and connecting these subnets to the backbone permit research on end-to-end connectivity. Finally, we connect the backbone to the commodity Internet to allow users to access legacy content and services via GENI. Without this capability, no users will use the experimental services and architectures deployed on GENI, dramatically limiting its research value.

Management Framework

Perhaps the most important attribute of the mangement framework is its support for decentralized control. Individual building blocks will be laregely autonomous and self-managing, but can be included in a slice by invoking a well-defined interface on each. Collections of building blocks (e.g., complete wireless subnets, regional subsets of edge sites, the composition of components that form the backbone) can be treated as aggregates and managed independently of each other. Similarly, outside organizations that contribute their own resources can federate with GENI, while retaining autonomous control over their components.

In addition to a set of interfaces through which various building blocks and resource aggregates plug into GENI, the management framework also includes a set of independent services that provide useful capabilities to end users. These services will be used to embed a slice in a particular set of resources; monitor the behavior of both slices and building block components; collect, aggregate, and archive measurement data; and so on. All of these services are presented to researchers as a single logical entity, through the use of a unified web interface, but the underlying management framework will be designed to support autonomous and decentralized control.