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: [[BR]] [[Image(geni-network-architecture.png, 30%, nolink)]] 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. An example diagram is presented on Figure 2 below. [[BR]] [[Image(network-stitching.png, 20%, nolink)]] [[BR]] In the example above, in order to connect a host on Rack A to a host on Rack B, different portions of the network need to be provisioned by different organizations (organizations hosting Rack A and Rack B, the regional networks that connect Rack A and Rack and the provider of the GENI core network which is Internet2) and at the peering points the organizations need to coordinate to ensure that they establish a working end-to-end Layer 2 path. [wiki:GeniNetworkStitching Click here] for more information on GENI stitching. GENI stitching is a generic capability for providing network federation between different organizations and has also been used when federating with other testbeds as described here. === Wireless Networking in GENI === The main wireless resources in GENI are through 3G and 4G base stations that are offering a GENI networking at the selected sites. The first generation of base stations were using the WiMAX technology, while the second generation that is being deployed as of 2015 are using LTE technology. The GENI base stations have a backhaul connection to a local GENI rack and through the rack connecting back to the GENI backbone network. In this way a user can put together a multi-site wireless experiment using the GENI dataplane. === Connecting resources to GENI === The best way to connect unique resources to a GENI experiment is through a GENI rack. As noted in the architecture Figure 1, a campus can connect different resources (e.g. resources at a specific lab) through the dataplane switch of their local GENI Rack. == 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. [[Image(GENI Architecture Entities.pdf)]]