GÉANT GTS Service Description User defined experimental networks to the research community Issue Date: 1 November 2017 GÉANT GTS Service Description GÉANT Testbeds Service (GTS) Overview The “GEANT Testbeds Service” (GTS) offers user defined experimental networks to the research community for the purpose of testing novel networking and telecommunications concepts, at scale, and across a geographically realistic European footprint. GTS provides dynamically provisioned network environments consisting of computational servers, data transport circuits, and switching/forwarding elements. These testbeds can be scheduled in advance to coordinate testbed experiments with other non-GTS activities, and testbed components can be selected from any of the GEANT core points of presence that have GTS services available. Each testbed constitutes an isolated and insulated virtual environment that can function autonomously from other testbeds or other production services. Figure 1 – GTS network graphs GÉANT GTS Service Description Testbeds can be defined and orchestrated by the user through a web based Graphical User Interface or via a Command Line Tool within a Linux shell/script environment. The user is able to access their testbed environment though a standard VPN internet gateway. The testbed itself can communicate with other facilities external to GTS through explicitly defined data flow interfaces incorporated into the testbed data plane itself. GTS networks are not simulations, but are run over isolated parts of the real physical infrastructure so that you can obtain realistic statements on network behavior and network traffic. The GEANT Testbeds Service is a production capability offered by GEANT. As a production service, the testbed facilities are made available on 24x7 basis. The GTS facilities are continuously monitored by the GEANT Network Operations Center and outages of infrastructure generate immediate alerts to the Level 1 support staff. Level 2 support is available during normal business hours to address unusual or more complex service related problems requiring more expertise. Level 2 support is available outside of normal business hours by special prior arrangement. GTS is currently deployed in eight GEANT core sites (Amsterdam, Bratislava, Hamburg, London, Madrid, Milan, Paris and Prague). These facilities make available hundreds of Virtual Machines, and many virtual OpenFlow switching fabrics. These components can be linked via 1Gbps and 10Gps virtual circuits provisioned over the GTS core transport infrastructure with over 140 Gbps of total backbone capacity. The virtual network environments offered by GTS provide a revolutionary new capability for both network researchers as well as for developers of advanced networked applications. GTS networks can offer powerful self-contained networks for simulations and experimentation, or they can be employed as “software defined exchange” fabrics – intelligent service-infused network domains bonding together multiple otherwise isolated research islands into a contiguous user defined service region. Figure 2 - Software Defined eXchange Fabric New service features and capabilities, infrastructure, locations, and resource types will be continuously introduced in response to user requirements. GÉANT GTS Service Description “Testbeds” Purpose and Target User Community The GTS purpose is to provide a facility to the European network research community for testing novel network architectures quickly and easily. The service will offer computational nodes and switching/forwarding nodes as virtual “resources” that the researcher can reserve and incorporate into their own custom testbed environment. The resources allocated to a testbed will be placed under control of the user researcher/team. GTS provides a generic application program interface (API) that allows the researcher to maintain control of their respective testbed resources and which will allow the service administrative and operations staff to assert management control over the entire service facilities. The following describes the GEANT Testbeds Service GÉANT GTS Service Description GTS Features The purpose of a network “testbed” is to provide an environment that has the characteristics of a real world network, yet which is isolated and under sufficient positive control to prevent any unanticipated behavior from causing disruptions to other ongoing production services or that might interfere with other unrelated testbed activities. These testbeds should consists of flexible elements or “resources” that have properties that the researcher can configure to meet their needs. The target customer base the GEANT Testbeds Service is network research, including applications research related to distributed or networked service environments. The “service” provides user-defined virtualized network environments that can be applied to explore a wide range of network research topics. Some of the key features are as follows: 1. Testbeds can be described using an easy to understand high level domain specific language – the “DSL” 2. The GTS Testbed Resource portfolio includes: 2.1. “Host”s - Linux based virtual machines that provide a highly flexible platform for the deployment of new software based services. 2.2. “Link”s – Point-to-point bidirectional data transport circuits that move Ethernet frames transparently and unmodified end to end. Link resources can be provisioned with up to 1 Gbps transport capacity. 2.3. “OFX”s - OpenFlow switching fabrics. These are packet forwarding resources that will be available in GTS. The OpenFlow fabric is based on OpenFlow 1.3. Each OFX has its own controller port and a variable number of data plane ports. 2.4. Virtual External Domains – VEDs are virtual resource classes that represent external domains. These resources contain port(s) specifications map to existing external circuits that connect GTS service domain to the external a specific remote domain 3. GTS networks are not simulations, but are run over isolated parts of the real physical infrastructure so that you can obtain realistic statements on network behavior and network traffic. 4. Testbeds are insulated and isolated from one another. Thus activity within one testbed will not impact other active testbeds. 5. The service allows resources and testbeds to be reserved for use during some window in the future. GTS advanced reservations are mapped to specific infrastructure facilities at reservation time in order to guarantee their availability at the scheduled time. 6. The service provides an API that allows users to develop their own orchestration agents to interact with the GTS core service agent to manage testbeds and resources. 7. The service provides a web based interactive graphical user interface (GUI) to manage a testbed through its entire lifecycle. 8. The service provides a Linux based command line interface (CLI) tool that can be used manually within a shell or within canned scripts to manage testbeds via the service. GÉANT GTS Service Description 9. The service provides Internet access for users to reach and interact with testbed resources. This allows users to easily stage software or data to/from their testbed resources, or allows those resources to access external servers to download data. GÉANT GTS Service Description User Registration and Authorization Policy The GTS allows new users to register to use the service directly from the login splash page https://gts4.geant.net Initially, the service places a very low bar to registration allowing the target research community to easily engage and to begin learning how to use the service. GTS supports four user “classes”: 1) 2) 3) 4) “Basic” users. These are users who wish to trial the service to judge its capabilities prior to undertaking large scale work. Such users will be easily registered and will have rights to build and run relatively simple testbeds. These users will be tracked and authorized just as any other user. However, authentication measures will be minimized in order to allow new users to register easily and then quickly become familiar with using the service. Basic users will have substantial limitations on the overall breadth and depth of the testbeds they will be allowed to instantiate, and the testbed data plane will only be allowed very limited external access to other systems or services. This introductory status is intended to provide an easy learning experience for new or prospective users without imposing strict or convoluted security or accounting policy necessary for more advanced, resource intensive, or sensitive projects. “Intermediate” users. These users will need to provide additional authentication credentials as part of their registration and/or authorization quotas. The ProjectIDs associated with intermediate users will be allowed more privileges in terms of resources of the testbed service. Intermediate user profile allows the user to provision external gateways for the testbed to source or sink traffic across the secure testbed perimeter. Larger testbeds (more resources) will be allowed. It is expected that most network researchers will fall into this category. “Advanced” users will be allowed customized security profiles such as allowing real traffic to transit a testbed, or to insert custom hardware or software into the resource database. The user policy profiles for advanced users may be highly customized to reflect desired capabilities of the research being performed, the demonstrated expertise of the research team, the specifics of the testbed itself, etc. “Operations” personnel will have the greatest privileges. Agents with Operations credentials will effectively have full control privileges over resources associated with that function, and will have ability to step in to halt or otherwise manage testbeds that pose problems to the overall continuous availability of the service. In general, users will be assigned an “allocation” to their account. When this allocation is used up, the user must apply for additional allocations. Each resource will be assigned a “cost” or a rate at which the allocations are consumed over time within the GTS service. This initial accounting process will be reviewed and may be modified as necessary to fit the accounting requirements for GEANT and to meet the community’s needs. Other means of accounting for resource utilization may be proposed and can be considered and/or implemented over the long term. GÉANT GTS Service Description Once the user is registered, the access to and use of the service is intended to be fully automated – requiring no further human intervention except in error conditions. There are obvious issues regarding user authorization profiles when we consider the prospect of large, persistent, or multi-domain testbeds. In GTS v1.0, the simple authorization profiles will be applied. GÉANT GTS Service Description Contact and User Support Processes The GEANT Testbeds Service website provides the primary interface to prospective users. This website is a first stop/one stop nexus for all aspects of GTS within the context of the GEANT Project. The GTS website provides online training tutorials, information found in this Service Description, and all current documentation – GTS Architecture Description, User & Resource Guide, and the Engineering Installation & Configuration Guide. In addition, the GTS provides directions and links to download the GTS software. The GTS website offers a user registration gateway, and trouble ticket system. Phone and email contact information will also be available. Requesting connection to the GÉANT GTS service Interested connectors should address their request to connect to the GÉANT GTS service to the GÉANT Partner Relations team: firstname.lastname@example.org GÉANT GTS Service Description Service Operations and Support The GEANT Testbeds Service is a production service. This means that the ability to create and use testbeds is expected to be available on a 24 by 7 operational basis. Therefore, the facilities that comprise the service infrastructure will be continuously monitored to insure their availability, the virtual resources assigned to testbeds will be monitored to insure these components of the service are functioning properly, and there will be a means for users to contact the GEANT Operations Center at any time to resolve questions about the operational status of the service or a service instance. The GEANT Network Operations Center will be tasked with monitoring the service facilities to ensure their continuous operational readiness Key aspects that will be monitored are: - GTS hardware elements. This includes all GTS “pods” and their constituent hardware components including compute node servers, the OpenFlow switching hardware, MX routers, and control plane switch. The hardware elements of the Central Server Facility will also be monitored to include the CSF hardware servers as well as the virtual machines running on those servers. - GTS Software agents. These are processes that run on one of the hardware elements or VMs. These agents include functions such as OpenNSA daemons, OpenStack processes, database agents, shared file services, etc. - User resource instances. Proper monitoring and evaluation of resource availability depends upon the lifecycle state of a resource and the availability of the underlying infrastructure elements that are used to create the virtual resource instances and support their proper functioning. GTS v1.0 will provide only a very basic monitoring of resources instances to insure they transition properly into the Active state. Later GTS versions will define a comprehensive resource monitoring architecture that considers life cycle state, underlying resource/infrastructure dependencies, and resource specific performance requirements. - The Internet Access Gateway.. The IAGW for each registered GTS Project will be monitored to insure the VPN gateway is operational, and that the key IAGW services (DHCP, NAT, NFS, etc.) are running. - Testbed border I/O activity Monitoring of external data flow ports is important to prevent testbeds from interfering with other testbeds or other non-GTS services. In GTS v1.0 external data plane interfaces are limited to specific destinations and capacities. The IAGW capacity is likewise constrained to insure adequate yet safe access to/from testbeds. In addition to real time monitoring, the GTS service logs all significant events that occur in the functioning of the system. These logs can be used for forensic purposes or may be processed for accounting or periodic service reporting purposes. GÉANT GTS Service Description GTS Documentation The GTS provides a number of documents describing various aspects of the service. These can be found by following the documentation links at https://www.geant.org/Services/Connectivity_and_network/GTS/Pages/Resources.aspxThe key documents are described below: GTS Architecture Guide. This is a detailed description of how the GTS service functions. This covers internal functional modules, data structures, and protocols. GTS Generalised Virtualisation Model This document provides a high-level description of the virtualisation model used by GTS to deliver services to users. GTS Engineering, Installation, and Configuration Guide. This document is intended for network engineers and planners. It provide design and engineering requirements, hardware specifications and tradeoffs, and installation and configuration of the GTS open source software GTS User Guide and Resource Catalog. This document describes how users are able to access and manipulate Testbeds within the service. This describes the GUI and CLI interfaces, the API library, and a description of the current resources available to users. The Resource guide provides usage tips as well as a complete description of attributes and other issues associated with resource classes. GÉANT GTS Service Description Glossary There has been much work within the R&E community pursuant to virtual networks and services. And often, different terms are used referring to very similar concepts, or the same terms are used for different concepts. This glossary will try to define the use of a number of terms in the context of the GEANT Testbeds Service. Resource – An allocatable service unit. Resources are created by virtualizing infrastructure components. For instance, a PC server may be virtualized to provide “Virtual Machine” resources – each such virtual machine instance acts as a standalone PC server. Resource Class – A description of a set of resources that all have the same set of attributes. Each resource instance of this class may have different values for its attributes, but they all share the same attribute set. A class is describes the common characteristics of a group of resources. Resource Instance – An example of a particular resource class description. I.e. a particular resource. Infrastructure – The underlying hardware, software, or services from which the virtualization process will create virtualized allocatable resources. For GTS, the infrastructure consists of the base facilities underlying the virtualization layer such as PC servers, OpenStack agents, manually provisioned circuits, or specialized hardware such as OpenFlow switches or production routers. For example, infrastructure such as a PC server could be virtualized to provide a bare metal “x86 cpu” Resource. Similarly, a server along with a hypervisor software could be configured to provide set of “Virtual Machine” Resources. Network – An arrangement of switching/forwarding nodes interconnected by a set of data transport links. The switching and forwarding elements process data flows arriving from the data transport links. Such processing may include conventional IP forwarding, Ethernet switching, or some more complex application oriented processing of the data. Processing of inbound flows may generate outbound flows destined for other nodes. Transport links simply transport information transparently from the outbound port of one forwarding element to an inbound port of another switching/forwarding element. In this model, end systems are also considered nodes in the network, though they simply process the data flows in a different manner that conventional forwarding or switching elements. Virtual Network - a network (see above) where the transport links and forwarding elements are instantiated from virtualized resources rather than directly upon specific physical hardware infrastructure. The virtual network is described as a graph (nodes and links) consisting of characteristics of the virtual elements rather than the hardware on which it is may be realized. This allows the [virtual] resource allocation process to analyze the network specification and efficiently map each component of the virtual network to appropriate infrastructure according to the stated requirements of the virtual network description. Such GÉANT GTS Service Description virtualization allows hardware resources to be shared in a manner that is [largely] transparent to the virtual network elements. Slice – A virtual network. The term slice evolved from network research activities such as Planet Lab where experiments would acquire resources from various distributed facilities. The intercommunicating agents/resources so allocated were referred to as a “slice” of the overall network facilities. Service – A capability that performs some function on behalf of and at the request of another user, or client, agent. The GTS “Service” therefore creates Testbeds on behalf of and at the request of a user. Testbed – In the context of the GTS, a “Testbed” is a network specifically created to test and evaluate an experimental concept that involves the transport of data between or across a set of distributed agents. A testbed is considered to be “breakable” – i.e. experiments are able to run on the testbed that may cause a component to fail...And this is ok on a testbed.