A Model-driven Configuration Management ... - Semantic Scholar

A Model-driven Configuration Management Methodology for Testbed Infrastructures F. Galán, J.E. López de Vergara, D. Fernández, R. Mu˜ noz

Publication: Vol.: No.: Date:

in Proc. IEEE/IFIP Network Operations & Management Symposium (NOMS). April 7-11 2008

This publication has been included here just to facilitate downloads to those people asking for personal use copies. This material may be published at copyrighted journals or conference proceedings, so personal use of the download is required. In particular, publications from IEEE have to be downloaded according to the following IEEE note: c °2008 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

A Model-driven Configuration Management Methodology for Testbed Infrastructures Ferm´ın Galán∗ , Jorge E. López de Vergara† , David Fernández‡ and Raül Muñoz§ ∗ Telef´ onica

I+D (TID) Emilio Vargas 6, 28043 Madrid, Spain † Departamento de Ingenier´ıa Informática, Universidad Aut´ onoma de Madrid (UAM) Av. Francisco Tomás y Valiente 11, 28049 Madrid, Spain ‡ Departamento de Ingenier´ıa de Sistemas Telemáticos, Universidad Politécnica de Madrid (UPM) Av. Complutense s/n, 28040 Madrid, Spain § Centre Tecnol` ogic de Telecomunicacions de Catalunya (CTTC) Av. Canal Ol´ımpic s/n, 08860 Castelldefels (Barcelona), Spain Email: [email protected], jorge.lopez [email protected], [email protected], [email protected] Abstract— Testbeds are controlled experimentation platforms where solutions (software, architectures, etc.) can be developed, deployed and tested in an environment that resembles real utilization conditions. This paper describes a model-driven methodology for automatic testbed reconfiguration which solves the problems of manual interaction and inter-testbed scenario reutilization. It is based in a high-level testbed-independent model of the desired scenario (so it can be applied to any testbed in general) which is particularized to testbed-specific scenario models for automatic deployment and management by model-based tools. The paper also details our practical experiences applying the methodology to two quite different use cases: VNUML-based virtual testbeds R and the GMPLS-enabled optical network of ADRENALINE testbed (each one with its own model-based automatic deployment tools), thus assessing the feasibility and generality of the proposed approach.

I. I NTRODUCTION A testbed can be defined as a controlled infrastructure used to experiment with networking systems and approaches under conditions that resemble the ones in real environments. They play a key role in research, educational and pre-production contexts, such as new approches in business objectives driven infrastructure management. A reconfigurable testbed (like R Emulab [1], PlanetLab [2] or ADRENALINE [3]) can implement different experimentation scenarios (i.e., topologies, configurations, etc.) using the same physical infrastructure. Our work is focused in reconfigurable IP-based testbeds. In order to achieve reconfigurability, many testbeds rely on human interaction, either by directly accesing the equipment (like in ADRENALINE) or using a decoupled bunch or infrastructural services (like in PlanetLab). This fact has severe drawbacks: time consumption, high human error probability, need of specific knowledge on low-level reconfiguration technology and scalability. In addition, although some testbeds (like Emulab) implement reconfiguration systems, they use to lack the proper abstraction level in order to be generalized to other testbeds apart of the one in which they were developed. This paper is being supported by the Business Oriented Infrastructure (BOI) research initiative within the Business Support Systems (BSS) unit at Telefónica I+D.

This paper proposes a model-driven mechanism to reconfigure testbeds, providing automation to overcome the problems of manual interaction and inter-tested integration. In this sense, our work is a contribution to the configuration management for testbed infrastructures. The problem is stated in Sect. II and the proposed solution introduced in Sect. III. Next, Sect. IV describes the practical application of the methodology to two specific use cases and, finally, Sect. V closes the paper with the conclusions and future work lines. II. P ROBLEM S TATEMENT Deployment (to configure the testbed infrastructure according to a given experimentation scenario, including topology, addresing, parameters, etc.) and undeployment (to release the testbed resources –e.g., physical nodes, network addresses space, etc.– allocated during the deployment) are critical steps in testbed reconfiguration, especially in the case of heavily used infrastructures that need to be quickly reconfigured between experiments in order to maximize its usage. Manual deploy/undeployment is the simplest procedure, but it has several important drawbacks. Firstly, it is a high time-consuming task due to much time is spent performing tedious and mechanics operations. Secondly, reconfiguration needs specific knowledge regarding the testbed technology not related with the goal of the testbed itself (testbed users are supposed to be experts in the experimentation field the testbed addresses but not in its low-level enabling technologies). Third, humans tend to make errors typing commands and writing configurations (usually very subtle and difficult to detect), which may produce a wrongly deployed scenario, thus corrupting the experimentation results. Finally, manual reconfiguration is poorly scalable because the bigger the scenario to be deployed is, the more time it takes to be configured and more likely to introduce errors. In addition to these problems, scenario reutilization across testbeds can be very difficult. Inter-testbed scenario reutilization can be interesting in two cases. First, complex experiments can need several complementary testbeds, each one devoted

to a particular aspect of the implementation or idea under test (e.g., a first testbed based on virtual machines to test and debug the software code implementing a given service, and a second testbed composed of a hardware platform where the final version of the software is stressed and tuned in near-to-real conditions previously to using it in a production environment), but needing the same set of scenarios to get coherent results. Second, it could be interesting to develop a set of “reference” network scenarios useful for a wide range of experiments. III. P ROPOSED S OLUTION A. Methodology The proposed methodology is based on modelling the desired scenarios at two abstraction levels, as shown in Fig. 1. The first level corresponds to a Testbed Independent Model (TIM), which describes the desired network topology from a high-level perspective, without considering its deployment aspects (e.g., which physical device will host each node). The second level is a Testbed Specific Model (TSM), which completes the high level model with those deployment details for the specific testbed. The TSM is derived automatically from the TIM, using automatic transformation tools (taking the TIM as input and adding information regarding how it is actually deployed in the testbed). Therefore, transformation tools require a description of the testbed environment (e.g., number and attributes of physical nodes, etc.). The actual scenario deployment is performed by TSM-based configuration management tools. The tool takes the TSM as input and performs automatically the corresponding deployment actions, interacting with the testbed physical elements. Examples of such tools are VNUML (described in Sect. IV-A), ADNETCONF (Sect. IV-B) or the Emulab “swap-in” engine. The proposed approach overcomes all the problems described in Sect. II. First, the utilization of automatic procedures (in model transformation and deployment) solves the problem of time-wasting (because of the work is done by the tool on behalf of the user), human error occurrence (since human interaction is avoided) and scalability (the processing logic implemented by the software tool is the same no matter the size of the networking scenario). Second, the model architecture (TIM and TSM) isolates the user from specific technological details of the testbed, so the user can concentrate in the design of the networking scenario, without bothering about testbed implementation details. Finally, inter-testbed scenario reutilization is achieved, because of the existence of a testbedindependent model (Fig. 1 shows an example considering the same scenario used in three different testbeds). B. Modelling Approaches Three approaches can be used to model the testbed scenarios at two abstraction levels: XML technology, ontologies or MDA (Model Driven Architecture). Currently, many tools usually use XML for the syntax of their configuration files by defining a set of tags. In fact, both VNUML and ADNETCONF configuration files are based on

XML (see Sect. IV). In these cases, deployment parameters are specified with XML tags. One interesting property of XML files is that they can be transformed by means of transformation languages such as eXtensible Stylesheet Language Transformations (XSLT) [4]. With these languages, an input XML document is translated into another document. Then, these transformations could be used to translate from a platform independent testbed configuration file to a platform specific configuration (e.g. VNUML, ADNETCONF). However, XML is not a good language for modelling, because the semantic of the defined tags is hidden. Precisely to deal with the semantics of the information, ontologies provide a way to formally describe a set of concepts and properties and the relationships between these concepts [5]. Many works have provided methods to map information from one ontology to another, even management information models [6]. If this modelling approach is used in our work, a platform independent testbed ontology should be defined, as well as the ontologies and mapping rules for each platform. However, these platform-specific ontologies should be later transformed in the testbed configuration files. Finally, the Model-Driven Architecture [7] provides a framework to model systems that allow the separation of the functional specification and its implementation on a specific platform. For this, two model levels are defined. Platform Independent Model (PIM) provides a model of the system structure and functionality, avoiding technical details of the specific deployment platform. Platform Specific Model (PSM) provides a way to represent the system with elements that are specific of the deployment platform. Both models are defined by leveraging other technologies such as the Unified Modeling Language (UML). Of relevant importance to MDA is the notion of model transformation. A PSM is the result of applying a set of transformation rules on the elements in the PIM, and it represents the system with specific artefacts of the deployment platform. C. CIM-based Testbed-independent Model The testbed-independent model is based on the DMTF’s Common Information Model (CIM). This allows to apply any of the approaches described in the previous subsection (CIM has an XML representation, a UML profile [8] and can also be represented as ontology [9]). Moreover, classes and relationships used to define the TIM could be considered a testbed CIM profile. Thus, the TIM is similar to the IP interface profile [10], but focused in scenario models for networking testbeds. Consequently, the TIM considers interconnection links (not only interfaces) and a more complete node model (including forwarding, static routes and extensible network-related functionality). The TIM is composed of two parts. First, a TIM Core, common to all use cases and defining basic IP networking concepts (topology, addressing, static routing, etc.). Second, optional user-defined TIM Extensions that define a coherent set of network functionalities (services, processes, applications, etc.) executed by the nodes in the network (e.g., a TIM GMPLS

Testbed 1 parameters



TIM to TSM1 Transformation

Desired scenario

TIM to TSM2 Transformation Testbed-independent scenario model (TIM)

Fig. 1.

TIM to TSM3 Transformation

Testbed specific scenario models (TSM)

Deployment tool (e.g., VNUML)

Testbed 1 (e.g. virtual)

Deployment tool (e.g., ADNETCONF)

Testbed 2 (e.g. ADRENALINE)

Deployment tool (e.g. Emulab engine)

Testbed 3 (e.g. Emulab)

Model-based automatic configuration management methodology

Extension for GMPLS networking testbeds). Fig. 2 shows a (simplified) class diagram of the TIM Core and one example of TIM Extension (the TIM GMPLS Extension), although an in-deep description is omitted for the sake of briefness. One of the keys of using CIM is that, given its broad “coverage” of network management information, it has been relatively easy to find equivalent (or semantically close enough) CIM classes or associations for each concept needed in our problem domain. Only for a very few concepts (the ones prefixed with TIM in Fig. 2) it has not been possible. IV. M ODEL - BASED T ESTBED M ANAGEMENT U SE C ASES This section describes the application of the proposed configuration management methodology (Sect. III) to scenario deployment in two testbed cases (particularly, VNUML-based virtual testbeds and the GMPLS-enabled optical network of ADRENALINE testbed). A. VNUML-based Virtual Testbed Virtualization allows building network scenarios composed of a set of nodes and interconnecting links running inside just one (or a set of) physical hosts. VNUML [11] is a general purpose open source front-end to User Mode Linux [12], one of such virtualization techniques) that allows to define, start and interact with virtual scenarios made of Linux virtual machines interconnected through virtual networks. Since its origins, VNUML has been extensively used in research and educational projects [13]. In this case, the testbed parameters to use in the TIM to TSM transformation are a description of the physical host and its associated resources (e.g., virtual bridges to implement internal virtual networks, virtual machine filesystems and virtualization back-end configuration). The transformation process for VNUML-based testbeds consists of two steps. The first one merges the input TIM with the testbed model described by the testbed parameters. Basically, it associates the logical entities in the TIM with the resources in the testbed. For example, each node is associated with a corresponding virtual machine filesystem and the link with a virtual bridge. The second step is to adapt the TSM to the specific format that the deployment tool (i.e., VNUML) uses. This format consists on a XML file with a specific semantic (a complete reference can be found at [11]).

Once the TSM has been generated, the user invokes VNUML (which runs in the physical host) to process it and start the virtual network scenario. During this step, all the virtual machines and virtual networks that made up the scenario are started and interconnected inside the host machine. Then, the user interacts with the scenario to achieve his experimentation goals (e.g., virtual machine consoles). Eventually, user runs VNUML again to dismantle the scenario and releases all the host resources used. B. ADRENALINE Testbed The ADRENALINE (All-optical Dynamic REliable Network hAndLINg IP/Ethernet Gigabit traffic with QoS) testbed [3] is a GMPLS-based intelligent optical network developed at CTTC laboratories. It implements a distributed GMPLS-based control plane [14], which is responsible for handling dynamically and in real-time optical node’s resources in order to manage automatic provisioning and survivability of lightpaths, allowing traffic engineering algorithms with QoS. The control plane is composed of Linux-based Optical Connection Controller (OCC) nodes (currently 32). They are interconnected through a backplane of VLAN-capable switches, able to implement any desired topology. This ability makes ADRENALINE a flexible testbed which allows the deployment of different network topologies and configurations (i.e., experimentation scenarios). ADNETCONF (Adrenaline NETwork CONFigurator) [15] is the deployment tool in charge of scenario model management in ADRENALINE. In this case, the testbed parameters for the TIM to TSM transformation consists on the physical OCCs along the interconnecting switches description. In this case, the merge step associates each node with the physical OCC implementing it. Additionally, it associates the node interfaces to physical interfaces on the OCCs and the link to the VLAN that will implement it in the switches. The adapt step produces the TSM in the specific format for ADNETCONF. The ADNETCONF processing engine runs in a control node that is physically interconnected to the testbed elements. The processing of the TSM (composed of a set of XML files) produces interaction with the OCCs and switches through a dedicated control connection (fixed and based on SSH and Telnet for OCCs and switches respectively) in order to deploy

TIM GMPLS Extension

TIM Core TIM_NextHopAddressedIPRoute * Network

Contained Domain *

1

*

HostedCollection

SystemComponent

RsvpTe

DestinationMask: string PrefixLength: uint8 AddressType: uint16 {enum} NextHopAddress: string *

Service w *

HostedRoute

Olrm

OspfTe *

1 * ComputerSystem

* ConnectivityCollection

SnmpAgent

Lrm

*

1 OspfTeConfiguration

HostedService 1

1

[…] 1

TIM_LinkConnectivityCollection MaxConnections: uint16 1 TIMM_LinkTransmissionElement w *

1 HostedAccessPoint

0..1

*

ForwardingService ProtocolType: uint16 {enum}

w * * IPProtocolEndpoint

TIM_LinkOrigin

1

TIM_LinkDestination

Fig. 2.

[…]

ElementSettingData

* IPAssignmentSettingData

*

1

StaticIPAssignmentSettingData 0..1

LrmConfiguration

ForwardsAmong

TIM_MemberOfLink

TIM_TransmissionCharacteristics DelayMean: uint64{units} DelayDeviation: real32 DelayDistributionFunction: uint16{enum} LossProbabilityValue: real32 LossProbabilityCorrelation: real32 CorruptionProbability: real32 CorruptionProbabilityCorrelation: real32 DuplicationProbabilityValue: real32 DuplicationProbabilityCorrelation: real32 DisorderingProbabilityValue: real32 DisorderingProbabilityCorrelation: real32 Throughput: uinit64 {units} MTU: uint64 {units}

*

AddressOrigin: uint16 SubnetMask: string IPv4Address: string GatewayIPv4Address: string

TIM_StaticIPv6AssignmentSettingData AddressOrigin: uint16 IPv6Address: string PrefixLength: uint8 GatewayIPv6Address: string

Testbed-independent model (TIM) CIM profile

the desired experimentation scenario. Such general modelbased deployment method for IP networks is currently being patented by CTTC1 . V. C ONCLUSIONS AND F UTURE W ORK This paper proposes several contributions to the configuration management field in the context of flexible IP-based networking testbeds. First, it presents the model-driven methodology that solves the problem of manual operation and intertestbed integration and provides a base framework for the other contributions. Secondly, it provides the testbed-independent model (TIM) as a CIM Profile (consisting in a Core of basic networking plus Extensions modelling specific functionalities), after considering several modelling approaches (XML, ontologies and MDA) from the point of view of its transformability. It is worth noting that using a CIM profile to define the TIM provides a great flexibility. Finally, two cases of fully functional model-based deployment tools (VNUML and ADNETCONF) which extensive use in two rather different fields (virtual testbeds and optical networking) assesses the usefulness of the proposed approach. As future working lines, several issues still opened: dymamic behaviour modelling (e.g., links going down and up), incremental (rather than “monolithical”) deployment, configuration validation (correctness and completeness) or performance evaluation. 1 Method for Logical Deployment, Undeployment and Monitoring of a Target IP Network, PCT/EP2006/009960, October 2006.

R EFERENCES [1] B. White et al., “An integrated experimental environment for distributed systems and networks”, OSDI 2002, pp. 255–270, December 2002. [2] L. Peterson et al., “A blueprint for introducing disruptive technology into Internet”, HotNets-I, Princenton, NJ USA, October 2002. [3] R. Muñoz et al., “The ADRENALINE test-bed: integrating GMPLS, XML and SNMP in transparent DWDM networks”, IEEE Communications Magazine, vol. 43(8), pp. s40–s48, August 2005. [4] J. Clark, ed., “XSL Transformations (XSLT), Version 1.0”, W3C Recommendation, November 1999 [5] R. Studer, R. Benjamins, D. Fensel, “Knowledge engineering: principles and methods”, IEEE Transactions on Data and Knoledge Engineering, vol. 25(1-2), pp. 161–197, March 1998. [6] J. E. López de Vergara et al., “Ontologies: giving semantics to network management models”, IEEE Network, vol. 17(3), pp. 15–21, May/June 2003. [7] Object Management Group, “MDA guide version 1.0.1”, OMG Document omg/03-06-01, June 2003. [8] Distrituted Management Task Force, “UML profile for CIM”, version 1.0, DMTF Document, DSP0219, June 2007. [9] S. Quirolgico et al., “Toward a formal common information model ontology”, WISE 2004, Brisbane, Australia, November 2004 (Springer LNCS, vol. 3307, pp. 11–21). [10] Distrituted Management Task Force, “IP Interface Profile”, version 1.0,0a, DMTF Document, DSP1036, July 2007. [11] Virtual Network User Mode Linux (VNUML). [Online]. Available: http://www.dit.upm.es/vnuml [12] J. Dike, “User Mode Linux”, Prentice Hall, 2006. [13] F. Galán et al., “A Virtualization Tool in Computer Network Laboratories”, ITHET’04, Istanbul, Turkey, May 2004. [14] E. Mannie Ed., “Generalize Multi-Protocol Label Switching (GMPLS) Architecture”, IETF RFC 3945, October 2004. [15] F. Galán, R. Muñoz, “An automatic model-based reconfiguration and monitoring mechanism for flexible GMPLS-based optical networking testbeds”, ONDM 2007, Athens, Greece, May 2007 (Springer, LNCS, vol. 4534, pp. 239–248).