Architecture and Services
A major premise for this HPDMnet research program is its basic architecture should be developed within a service oriented architecture (SOA) design framework, which will allow for service implementations that are significantly more flexible and customizable than traditional communication services. Using such a framework, completely revolutionizes the way in which networks are used. Today, networks must be used as they are initially implemented. They are expected to remain fairly static for long periods of time. Using this new approach, networks and their services can be created dynamically. For example, instead of a manual months-long process to implement a topology, it is possible to create packaged topologies that can be invoked immediately on-demand. Also, because of its SOA context, The HPDMnet environment can be integrated with other environments that are dynamically allocated by other SOA processes, such as APIs that allow for integration into other GLIF SOA compliant frameworks.
HPDMnet supports general and specialized services. The primary general service is an L1/L2 capability optimized for large scale high volume streams. All services are media protocol coding/decoding agnostic. This unique global communication service allows for discovery of resources, signaling for services, managing and controlling streams, receiving streams, providing specialized transport for streams (allowing for transport characteristics to be defined), and dynamically allocating lightpaths and L2 paths. Although the service is not addressing the requirements of low volume streams, the architecture is sufficiently flexibile to accommodate those types of streams. In general the services are based on several key components. Application and/or client processes signal for services. Using policy considerations, these requests can be fulfilled immediately or they can be scheduled for future use using advanced reservations. In either case, the resources allocated are governed by a Resource Management Center (RMC), a set of processes that matches requests with required resources. A separate set of processes governs the actual use of the services when they are active.
HPDMLive: HPDMLive is a client that can be used to access HPDM services. The client: supports signaling high level processes that can invoke those at lower levels, including dynamic topology creation and instantiation. Such processes can also be used to create icons that can contain complete “Packaged” Topologies – global network instantiations that can be invoked by selecting a desktop icon. The icon “encapsulates” the required network instantiation. This capability can also be integrated into applications and other digital processes.
Continuous Test Beacon: The HPDMnet test beacon is being established to allow for research participants to test capabilities independently of assistance from those at other sites.
Optical Multicast: An important research focus has been investigating new methods for Global Dynamic Optical Multicast (GDOM). A GDOM testbed has been established within the HPDMnet testbed. GDOM was demonstrated at several international conferences in 2007.
L2 Multicast: Capabilities for L2 multicast will be the focus of a future extension of the HPDMnet testbed.
Loop Back Objects: Services based on end to end L2 paths can be difficult to troubleshoot using standard techniques. HPDMnet provides for a method of establishing Loop Back Objects to assist with implementing, managing and testing these paths.
Monitoring: HPDMnet will soon have a basic monitoring service.
Core Services: HPDMnet uses an integrated set of services for core path provisioning created within the framework of the GLIF architecture (High Performance Network Services System, HPNSS).
The HPDMnet architecture is based on multiple service modules, using as a foundation the concept of Infrastructure as a Service Framework (IaaS). This IaaS Framework is structured within the context of resources as services. It allows for the provision of tools and utilities for resources without regard to the specifics of their internal processes. The Framework is built on a set of core modules that comprise service utilities and resource data structures (schemas) for the different technologies. At the lowest levels, resources correspond to physical objects, such as the devices, ports, or channels that are being virtualized. Today, physical infrastructure such as optical switches, Ethernet switches, routers, and instruments are only accessible through their own control and management channels. Some may be integrated into a central management system. This approach makes the infrastructure extremely rigid and inflexible. Within the HPDMnet architecture, such physical objects are virtualized, and they can be shared and controlled by the software based services. This allows for significantly more flexibility.
High Level Service Modules
HPDMnet architecture provides for multiple layers of virtualization. In accordance with other architecture efforts that are being designed to provide for close integration of applications and resources, the highest layers are those that are closest to the application. These layers allow applications to find and use virtualized services. Because this initiative is focused on network services virtualization, it provides capabilities for applications to directly interact with virtualized network services. Therefore, application services can find and use Network Virtualization Services (NVS). For example, one such service provides for Scenario Resources, which is based on the Articulated Private Network (APN) concept. An APN is created by administrators for those who use the service. They are able to use it only by invoking predefined configurations established by those administrators. Another related service provides Resources Lists, which are itemized resources and the relationships among those resources that allows for display information exchanged among sites. Traditionally, network topologies have been extremely rigid, deployed for static configurations usually lasting for years. This technique allows applications to find and use pre-configured topologies. Also, using other virtualization services and techniques it is possible to create and use topologies on-demand.
Lower Level Service Modules
High level virtualization capabilities are made possible by lower layer virtualization services. Traditionally, network equipment is fairly statically configured and can be changed only through direct access using control and management planes supported by their proprietary internal systems. Often such systems are integrated into proprietary centralized management and operations systems. The HPDMnet architecture provides for virtualization for both control and management processes and for network devices. The Device Controller Services (DCS) provide for proxy controllers for network elements (NEs). The controllers are also used to create virtual resources out of physical devices. Also virtualized are the physical devices which constitute the basic network infrastructure. Device Virtualization Services can be used to create software object equivalents of persistent physical resources that must be configured, reconfigured, and monitored. These software objects are intermediaries between control processes and actual physical devices, such as routers, switches, optical devices, and their individual components, such as ports. Using these objects allows any changes to resources to be reflected on the controllers and any changes to the controllers to be reflected in the resource information. There are many advantages to this approach. Traditionally, high level services are based on statically configured physical resources, and changes or enhancements require difficult, time-consuming processes. By virtualizing capabilities, such changes and enhancements are much simpler and easier. Also, such capabilities can be distributed among multiple physical devices providing for both provisioning flexibility and redundancy. In addition, it allows for resource sharing among multiple organizations and domains.
Support utilities are used to provide common interfaces to all core module service tasks. For example, one utility service is the Permissions Provider, which can be used to set permission properties for using and integrating resources or services. For the use of any important resource, it is necessary to verify the request and validate specific types and levels of uses within a policy context. An important aspect of this architecture is that it provides not only for the distributed use of network resources but also for the distributed management and control of those resources. This is a powerful capability, and a mechanism is required to ensure its appropriate use. Using these utilities, it is possible to allow for such distributed use while ensuring the security, utilization, and reliability of all components. Another utility service is the Appliance Service, which provides information on resource utilization and related information, such as the available memory, resources, and software license for specific appliances.
HPDMnet is being designed as an open system architecture, with all APIs provided to allow for interoperability with other services, processes, and systems. The primary APIs are described in the HPDMnet documentation. Currently, the API that is exposed to third party applications is the Scenario Web Service (SWS).
The initial instantiation of HPDMnet uses several software components. Client processes can be any high level processes that can find and invokes HPDMnet services, web services, web clients, system processes, applications, etc. One experimental client, HPDMLive enables topology discovery, and it can be used for dynamic topology creation and for generating selectable viewing clients, icons that can encapsulate a “packaged” topology – a specific network instantiation that can be implemented on-demand.
HPDMnet is media client agnostic. Media clients used with HPDMnet include the VLC Media Player, DVTS (Digital Video Transport System) and UltraGrid. A design goal for HPDMnet is to provide basic capabilities that are independent of specific media technologies.
The primary foundation engine used for HPDMnet is Argia, which was developed by Inocybe. Argia is a production grade version of UCLPv2 (User Controlled Light Path), initially developed by CANARIE. As indicated by its label, UCLP was developed to provide direct control of lightpaths to end users. However, subsequently, the architecture has been extended so that other types of resources can also be controlled, e.g., L2 paths. Argia is a collection of middleware that allows applications or individuals to use network resources as software objects that can be manipulated to provision and re-configure paths within a single domain or across multiple, independently managed domains. This process is fairly straightforward. Argia can be used to discover resources associated with a physical network. The discovered resources are presented as logical resources (virtualized resources displayed by the Logical Network Editor). Next an Articulated Private Network (APN) is created with these resources and the resulting APN topology is configured and displayed, represent the network that will be instantiated when the APN Is is executed. This instantiation provides management and control of the APN to the edge process that owns the resources provided. These instantiations can be subdivided and provided to other organizational entities or processes. These processes provide the foundation for a set of core network service provisioning capabilities, the High Performance Network Service System (HPNSS).