Cross-layer / Cross-domain Infrastructure and Service Management

Rationale / Motivation

Mechanisms that allow to rapidly federate distributed networks and resources like Teagle across administrative domains, together with emerging mechanisms which allow to deploy and provision distributed, cloud-based services, allow to compose and provision federations of infrastructures, resources, and services.

In order to ensure stable infrastructure functioning, such infrastructure and service federations have to be controlled, monitored, and managed across administrative domains and across several network, cloud, session control, service enabling and application layers.

Furthermore, monitoring and management mechanisms are needed to provide meaningful measurements to experimenters, from which a broad range of experiment-related conclusions (feasibility, robustness, performance, etc) can be drawn. This is especially required in the context of Future Internet (FI) experimental facilities (e.g. FIRE/GENI/G-Lab), where FI experimenters utilize testbed and service federations to rapidly carry out network and service related experiments on top of highly distributed infrastructures, with different network topologies and different underlying network capabilities.

Our cross-layer and cross-domain infrastructure and service management approach supports these requirements with two unique, key capabilities: Tight integration into the dynamic federation process and flexible, policy-based self-* capabilities.

Tight integration into the federation process

Dynamic resource federation, as long as not tightly linked to management systems, is only half of the medal. Only if infrastructure and service management capabilities are tightly integrated into the overall federation process, measurements and self-healing capabilities are available instantaneously after resources and infrastructures have been federated (i.e. provisioned and deployed).

In order to meet these requirements, the Network Management System (NMS) was designed in a highly modular fashion, where not only the central NMS exposes open provisioning interfaces towards the network federation system, but also a broad range of network and service monitors (IP, cloud managers, SIP, SOAP, local agents, etc.) are equipped with provisioning adaptors. By doing so, already during the process of resource federation, users can specify a broad range of tests to be carried out on top of the federated infrastructure so that the central NMS as well as required monitors are set up and tests are automatically being triggered.

Policy-based self-* capabilities

Monitoring and displaying network and service performance metrics (across layers and domains) is only one part of the required capabilities. In order to close the control loop, policies can be specified which allow the NMS to trigger certain actions based on incoming measurements. These actions range from sending out alarms to restarting or re-configuring certain network elements and processes. By doing so, the overall management control loop (Monitor -> Analyze -> Plan -> Execute -> Monitor) is closed so that the overall, cross-layer / cross-domain management system provides adaptive, self-regulating capabilities.