Version 10 (modified by, 5 years ago) (diff)


The GENI Architecture is composed of two fundamental pieces, each seeking to address different issues:

  • Network Architecture: How can we establish topologies of computation and network resources in an isolated deeply programmable context?
  • Federation Architecture: How can we establish trust among broad sets of users and contributors of independently owned and operated resources?

Network Architecture

The GENI Network Architecture was designed around three fundamentals principles of GENI:

  1. GENI is a sliceable testbed that can support multiple concurrent experiments running in isolation.
  2. GENI is deeply programmable, and allows experiments to control packet forwarding within the network.
  3. GENI is a federation that is comprised of several autonomous organizations providing resources to GENI. From the point of view of the user GENI appears like a unified testbed.

Figure 1, shows a high level overview of the GENI Network Architecture:

As also in the above picture GENI has two clearly separated network planes:

  1. Control/Management Plane : These are the networking connections that are used in GENI in order to control and manage the resources (login, install software, etc). GENI uses the regular Internet as its Control Plane. This plane is represented by the blue lines in the above diagram.
  2. Data Plane: These are the networking connections to the private GENI backbone that are used for experimental data exchange, either within one site or between sites. This is the plane that needs to be sliceable, deeply programmable and federated (i.e. no one organization owns the whole of the GENI dataplane network, but different organizations provide different parts of the connectivity.

All GENI resources are designed so that they can cleanly separate when possible the above to network planes. E.g. racks have two different switches: the management and the data plane switch, each compute server has a dedicated network interface to connect to the control plane. This is essential so that any problems on the data plane do not affect the ability to control and manage the resources.

Network Sliceability in GENI

In GENI the network is sliced based on VLAN ids. This ensures a Layer 2 network for all experiments and provide a clean separation of traffic between different slices. Slicing by VLAN guarantees traffic isolation between different experiments (i.e. one slice in GENI can not see packets that belong to another slice) and also provides a best effort guarantees in terms of performance.

Network Deep Programmability in GENI

In order to allow users to control the forwarding of their traffic in the middle of the network, GENI has deployed computation and storage not only at the edges but also within different network providers that are participating in the formation of the GENI backbone. This way as packets traverse through the network the users have the capability to do arbitrary packet processing within the network and instantiate software switches and routers. Some network providers that are hosting GENI racks include SOX, CENIC, MOXI, MAX and others.

Another way that GENI is providing deep programmability is by deploying programmable network devices in the network. Currently this programmability is provided by OpenFlow capable switches as an experimental feature.

Network Federation

GENI is a federation of resources that are provided from different organizations. This makes network provisioning between sites challenging since there is no one organization that is responsible for provisioning the networking for a single slice. In the Internet we know very well how to achieve this and we have different federation protocols so that different network providers can peer and provide end-to-end connectivity to users. However, the GENI backbone provides Layer 2 connectivity between different organizations and Layer 2 peering is not as well explored in the Internet. To achieve this and to enable dynamic provisioning of networking connection per experiment, GENI has developed a mechanism called stitching that allows different organizations to provision parts of a Layer 2 link between two compute resources in a way that it guarantees end-to-end connectivity.

Connection resources to GENI

Federation Architecture

GENI is composed of a broad set of heterogeneous resources, each owned and operated by different entities. They wish these entities to participate in GENI and allow these resources to be made available to researches. But they want to maintain a degree of control and trust that these resources will be used in a responsible and secure manner. In addition to these resource owners, GENI has a broad community of experimenters and researchers who wish to build topologies from these resources on which to perform reseach and experimentation.

The question of trust becomes critical for establishing this exchange of resources. There are simply too many resource providers and potential customers to allow everyone to know everyone and approve of every resource-related translation.

What is needed is a trusted third party who can vouch for the proper operations of resources (for the experimenters) and for the credentials of the experimenters (for the resource owners). This trusted third party is the GENI Federation. It establishes common notions of identity, authentication, authorization and accountability to allow all participations in the GENI federation to enter into resource exchange in a trusted manner.

Resource owners and experimenters and federations are real people or groups: GENI establishes software services to represent their interests in these transactions.

The following figure shows these real-world entities and their virtual representatives in the GENI Federation Architecture.

Real and Virtual entities comprising the GENI Federation Architecture

Attachments (3)

Download all attachments as: .zip