Using a Model-Driven Architecture for Technology ... - Semantic Scholar

GALÁN MÁRQUEZ LAYOUT

11/18/10

11:13 AM

Page 132

TOPICS IN NETWORK AND SERVICE MANAGEMENT

Using a Model-Driven Architecture for Technology-Independent Scenario Configuration in Networking Testbeds Fermín Galán, Telefónica Investigación y Desarrollo David Fernández, Universidad Politécnica de Madrid Jorge E. López de Vergara, Universidad Autónoma de Madrid Ramon Casellas, Centre Tecnològic de Telecomunicacions de Catalunya

ABSTRACT Networking testbeds are a key tool to design and experiment with new protocols, architectures, and services being proposed for future networks. The scenario-based configuration approach is a state-of-the-art testbed configuration mechanism that maximizes productivity in reconfigurable testbeds. However, commonly used scenario specification languages are highly coupled with the underlying testbed technologies. This fact precludes either the reusability of scenarios among different testbeds, or experimentation with complex test scenarios implemented over federated infrastructures proposed in projects like GENI, which comprise a combination of heterogeneous testbeds. In this article these issues are addressed by proposing a novel technology-independent scenario-based testbed configuration management architecture based on model-driven architecture principles. Our proposal takes into account general applicability and extensibility requirements, as well as seamless integration with existing testbeds. Furthermore, it has been experimentally validated with tests performed on actual testbeds.

INTRODUCTION

1

http://www.emulab.net

2

http://www.planetlab.org

132

A networking testbed can be defined as an infrastructure platform used to experiment with networking systems and technologies under controlled conditions that often resemble those found in production networks. Testbeds are very valuable tools for designing and experimenting with the protocols, architectures, and services that will shape our networks in the future, in both academic and industrial environments. Networking testbeds can be roughly divided into two categories: flexible/reconfigurable testbeds and inflexible testbeds. The latter are those built for specific experimentation scenarios, and they cannot be used for other purposes, at least without major changes that are beyond the testbed

0163-6804/10/$25.00 © 2010 IEEE

user’s scope (e.g., changes in the physical layout of the testbed). Our focus is on flexible testbeds: those that can be changed by the user to provide different experimentation scenarios by means of some well defined and usually automated testbed configuration procedures. We define an experimentation scenario as a specific networking context for the testbed, consisting of a network topology (nodes and links) together with the associated configuration for the processes and services running on the nodes. The term experimentation stresses the purpose of the scenario, which is to be used to conduct a concrete experiment in a given testbed. Experimentation scenarios follow a lifecycle: they start with their deployment, when the testbed resources are assigned to the scenario; and they finish with their undeployment, when the experiment ends and the testbed resources are freed to make them available for new uses. In order to avoid issues related to manual operation, state-of-the-art testbeds use a scenario-based management approach to cope with testbed configuration. This paradigm is based on the specification of the desired scenario using a specification language, which is later processed by a testbed management tool that translates the scenario description into the testbed infrastructure configuration commands required for deployment. This is the way in which several state-of-theart testbeds work. For example, Emulab1 scenarios are specified in ns2; the ADRENALINE testbed® [1] uses XML; and different tools allow building virtualized testbeds (VNUML, NetKit, MLN, or vBET) [2], which use different variants of text file formats. Other testbeds, such as PlanetLab,2 are not truly scenario-based, but provide open management application programming interfaces (APIs) on top of which such a management approach can be built. In the present context, where a huge variety of testbed management tools are available, it would be desirable to have a common scenario

IEEE Communications Magazine • December 2010


11/18/10

11:13 AM

Page 133

Desired scenario

Testbed 1 parameters Scenario-based management tool in testbed 1

TIM to TSM1 transformation

Testbed 1 (e.g., Emulab)

Testbed 2 parameters Scenario design tool

Testbed 2 (e.g., ADRENALINE)

Scenario-based management tool in testbed 2

TIM to TSM2 transformation TIM scenario Testbed N parameters

Scenario repository

Scenario-based management tool in testbed N

TIM to TSMN transformation

Testbed N

TSM scenario

Figure 1. The MDA approach to scenario-based management. specification language that allows reusing the same scenario over different testbeds. This is a common situation researchers have to deal with when the same experiment has to be conducted in several complementary testbeds. For example, the development of a new distributed protocol could require a first testbed based on virtual machines to debug the software implementation; a second testbed using a hardware platform to stress the system under near-to-real conditions; and finally, a third testbed in a globally distributed experimentation infrastructure such as the future Internet (e.g., GENI)3 to test the system over the real network. Currently, if the same scenario has to be used over different testbeds, users need to manually carry out time-consuming and error-prone conversions among the different specification formats, which are in general highly coupled to the particular testbeds in which they have been developed. Only a few initiatives have tried to define a general scenario specification mechanism, such as AnyBed [3] and the Network Description Language (NDL) [4]. Nonetheless, they show some limitations in their respective models derived from the omission of important scenario attributes. In addition, AnyBed and NDL impose their own management tools instead of using the tools already existing in the testbeds, so they cannot be integrated into existing testbeds in general. In this article, the challenge described above is addressed by proposing a new configuration management approach based on a common testbed-independent metamodel, which is seamlessly integrated with existing management tools using model-driven principles. The article describes the general applicability and future extensibility of the proposal, as well as the validation tests made over real testbeds. Considering that the management systems of future Internet testbed infrastructures such as the aforementioned GENI are being defined at the moment, our proposal is very timely as a


common specification and management mechanism to define scenarios that expand across a set of federated testbeds of different technological nature.

A MODEL-DRIVEN APPROACH TO SCENARIO-BASED CONFIGURATION MANAGEMENT ARCHITECTURE Our goal is to design a configuration management system for networking testbeds, achieving technological independence between scenario and testbed. We look for reusability of scenarios over heterogeneous testbeds that can be very different from a technological point of view, at the same time avoiding the modification of existing testbed management tools. The model-driven architecture shown in Fig. 1 is proposed for such purpose. It has been named model-driven because it is based on scenario modeling: each given scenario is represented by a refinement of models, from the scenario definition to its final deployment in a given testbed. Two modeling layers are considered: Testbed Independent Metamodel (TIM), which defines the testbed-independent concepts for scenario modeling, considering that each scenario is composed of a topology along with all its intrinsic properties (e.g., IP addressing). The TIM does not specify how the scenario will be deployed in testbeds (e.g., which physical device will host each topology node). A TIM scenario (model) is formally a representation of the scenario expressed in TIM (metamodel). Testbed Specific Metamodel (TSM), which provides the modeling concepts that complement the scenario description with all the required information to deploy the scenario in a given testbed (e.g., which particular testbed physical node will host each scenario node). Each TSM is conceived for a particular testbed,

3

http://www.geni.net

133


11/18/10

The TIM has been designed according to several requirements. First, it must be rich enough to model all the information that any general networking testbed scenario might require. Second, it must implement a modular design to support future extensibility.

11:13 AM

Page 134

because the deployment information is highly coupled to its technological implementation and different from the deployment approach used by other testbeds. For example, mapping scenario links to virtual LANs (VLANs) is only meaningful if the testbed is using VLAN-capable switches. A TSM scenario (model) is formally a representation of the scenario expressed in TSM (metamodel). As shown in Fig. 1, several per-testbed TSM scenarios are derived from the same TIM scenario through automatic transformation procedures, taking the model of the scenario as input and adding information about the actual deployment on the testbed. This deployment information is also considered a model, shown as testbed parameters in the figure. Thus, the transformation process can be seen as a merge of two input models into an output one. The particular parameters depend on the testbed nature, and should model the testbed infrastructure with the appropriate richness and granularity level to allow the transformation process to produce optimal TSM scenarios. TSM scenarios are the input used by scenario-based management tools, which perform configuration management operations executed on the testbed’s physical elements via the proper interfaces (NetConf, SSH/telnet, etc.). Each tool defines its own scenario specification format aligned with the TSM, such as an extended version of ns2 in Emulab or XML documents constrained by a given set of document type definitions (DTDs) in ADRENALINE. In the following sections the model-driven architecture is described as the technological foundation on which our proposal is based; then we continue with a description of the main elements of this approach: TIM and TIM-to-TSM transformation. Note that the focus of our research is not to define new TSMs or scenariobased management tools, but to apply our approach to existing ones.

MODEL-DRIVEN ARCHITECTURE

4

CIM Schema 2.22.0 was used.

134

Introduced by the Object Management Group (OMG) several years ago, the model-driven architecture (MDA) originated as a paradigm shift in the software engineering field, consisting of the use of models to drive analysis and implementation [5]. In MDA models are used to represent software components, making high-level specification of the software system (the platform-independent model [PIM]) independent of the actual implementation language (the platform-specific model [PSM]), thus decoupling functionality from implementation details. The transformation from PIM to PSM is carried out using manual, semiautomatic, or fully automated procedures. The novelty of our approach lies in the application of MDA software engineering principles to scenario-based testbed configuration management. This approach starts by focusing on models; therefore, any configuration procedure (e.g., scenario deployment or undeployment) is based on using or transforming models; and it is followed by the separation of concerns, clearly applied between scenario specification (TIM level) and implementation (TSM level) to achieve technological independence.

In the context of our work, we are interested in MDA technological aspects. Regarding the MDA technology, the OMG has aligned this approach with its existing modeling standards, such as the Unified Modeling Language (UML) and the Meta-Object Facility (MOF). UML is currently the de facto standard for specifying, visualizing, and documenting software systems. MOF provides the minimal set of concepts needed to define models of modeling languages (i.e., metamodels), and in our context, it can be a simpler alternative for defining TSMs than UML. Furthermore, OMG has also standardized the Query/Views/Transformations (QVT) language to formally specify model-to-model transformations, in both declarative and imperative way (model-to-text is covered in a different specification [6]). Those mappings are specified between metamodel elements, so that the complete set of mappings defines a transformation specification. However transformation based on metamodeling is at present a novel technology and QVT lacks mature software implementations. Moreover, some pre-existing QVT-like alternatives, such as the ATLAS Transformation Language (ATL) [7], have proved to be more widely supported and extended. ATL follows the MDA principles, as it is able to define transformations at the metamodel level that determine how source metamodel elements should be transformed into target metamodel elements. Both QVT and ATL use the Object Constraints Language (OCL) to query model elements by navigating their associations.

THE TESTBED-INDEPENDENT METAMODEL TIM is the cornerstone of our proposed management architecture. The TIM has been designed according to several requirements. First, it must be rich enough to model all the information that any general networking testbed scenario might require. Second, considering the large and growing number of different services and functionalities in the field of networking, it must implement a modular design to support future extensibility. The existing management information models have been found to meet the aforementioned requirements, so we have opted for reusing them rather than defining an entirely new TIM from scratch. In particular, the TIM is based on a subset of the Distributed Management Task Force (DMTF) Common Information Model (CIM) Schema [8], leveraging its expressiveness and richness. The CIM Schema 4 is very broad and includes a comprehensive set of management objects commonly found in networking systems, as well as several data formats to encode them. Furthermore, its object-oriented nature provides great flexibility and simplicity. Considering the fact that TIM addresses network modeling, we have preferred the CIM over other alternatives that are more focused on software distribution and deployment, such as the Configuration Description, Deployment and Lifecycle Management (CDDLM) language [9]. The TIM modular structure consists of two parts. The first is a TIM core, common to all use cases, which defines basic networking concepts (topology, addressing, static routing, etc.). The



11/18/10

11:13 AM

Page 135

TIM Core

TIM OSPF Module TIM_NextHopAddressedIPRoute InstanceID: string {key} OSPFArea DestinationMask: string OSPFService Name: string {key} DestinationAddress: string CreationClassName: string {key} TIM_TestbedScenario PrefixLength: uint8 AreaID: uint32 AddressType: uint16 {enum} 1 1 Name: string {key} Service NextHopAddress: string 0..1 OSPFServiceConfiguration Name: string {key} 1 * * AreaOfConfiguration CreationClassName: string {key} OSPFAreaConfiguration HostedRoute * w * SystemComponent InstanceID: string {key} HostedCollection 1..* 1 * ComputerSystem RangesOfConfiguration Name: string {key} * CreationClassName: string {key} TIM_LinkConnectivityCollection RangeOfIPAddresses * InstanceID : string {key} 1 1 InstanceID: string {key} MaxConnections: uint16 AddressType: uint16 {enum} 0..1 HostedService StartAddress: string 1 EndAddress: string ForwardingService * HostedAccessPoint TIM_LinkTransmissionElement ProtocolType: uint16 {enum} TIM_MemberOfLink ForwardsAmong w * TIM_TransmissionCharacteristics ElementSettingData w * * InstanceID: string {key} * IPProtocolEndpoint DelayMean: uint64 {units} 0..1 * * DelayDeviation: real32 Name: string {key} IPAssignmentSettingData DelayDistributionFunction: uint16 {enum} CreationClassName: string {key} LossProbabilityValue: real32 InstanceID: string {key} 0..1 0..1 TIM_LinkOrigin Loss ProbabilityCorrelation: real32 CorruptionProbability: real32 CorruptionProbabilityCorrelation: real32 DuplicationProbabilityValue: real32 0..1 DuplicationProbabilityCorrelation: real32 StaticIPAssignmentSettingData TIM_StaticIPv6AssignmentSettingData TIM_LinkDestination DisorderingProbabilityValue: real32 SubnetMask: string IPv6Address: string DisorderingProbabilityCorrelation: real32 IPv4Address: string PrefixLength: uint8 Throughput: uint64 {units} MTU: uint64 {units}

Figure 2. Testbed indepent metamodel (TIM) class diagram (core and sample OSPF module). second part is made up of optional user-defined TIM modules, which provide a coherent set of network functionalities related to IP and upper layers that are executed by the nodes (e.g., processes associated with dynamic routing). Figure 2 shows the TIM core along with a sample TIM module for OSPF routing used for the validation experiments described below. The TIM core includes 12 classes and associations from the CIM Core, Network, and System Common models, while the TIM OSPF module includes seven classes and associations from the Network Common Model. However, despite being a very comprehensive management information base, the CIM Schema lacks some concepts required for scenario modeling. Those concepts have been developed in an ad hoc TIM extension including nine new classes and associations, named with a TIM_ prefix from now on. Special effort has been invested to ensure that all the scenarios in the testbeds analyzed so far (Emulab, ADRENALINE, virtualized, PlanetLab, etc.) can be modeled either using the TIM Core or by means of additional TIM modules, which constitute the natural mechanism to extend the TIM to new network technologies. The main classes in the TIM core are ComputerSystem (modeling scenario nodes), TIM_LinkConnectivityCollection (modeling scenario links), and Service (the association between the TIM core and TIM modules is done through this class). By using association with other classes, network interfaces (IPProtocolEndpoint), both IPv4 and IPv6 addresses (StaticIPAssignmentSettingData and


TIM_StaticIPv6AssignmentSettingData), static routes (TIM_NextHopAddressedIPRoute), forwarding (ForwardingService), and link QoS constraints (TIM_TransmissionCharacteristics) can be modeled.5

GENERAL TIM-TO-TSM DESIGN METHODOLOGY In this section a systematic methodology to define TIM-to-TSM transformations based on the MDA approach is defined. Unlike the TIM, which is unique in our architecture, there are as many TIM-to-TSM transformations as existing or future scenario-based testbeds. However, note that, once defined, the TIM-to-TSM transformation can be considered as part of the testbed management tools, and no further change (except for maintenance) is required. The methodology is composed of four steps to be performed by the transformation developer: 1 TSM formalization: This step consists of deriving the specification of the TSM implicitly used by the scenario-based configuration tool in the given testbed, using OMG’s modeling standards, typically an MOF-based metamodel consisting of different classes and associations. If the TSM is already explicitly defined, the process is considerably simplified. For example, in the case of using DTD or XSD in XML-based TSMs, the formalization can be done considering each XML element in the

5

A detailed description of the different classes and associations shown in Fig. 2 is out of the scope of this article. Please refer to the official DMTF CIM Schema and ad hoc TIM Extension Model, which can be found at http://www.dit.upm.es/gal an/TIMTransforms/tim.m of.

135


11/18/10

All scenarios have been modeled using instances of the TIM classes. Note that some cases, in particular the rediris one, include around 1000 instances of those classes, with nodes, links, IP addresses, associations among objects, etc.

136

11:13 AM

Page 136

DTD/XSD as a class whose properties are the attributes in the XML element, and the child-parent relations as composition relationships among classes. 2 TIM-to-TSM associations definition, which consists of finding, for each class in the TSM, the pieces of information in the TIM that are required to fulfill it. For example, if the TSM includes an IP class property, which configures IPv4 interface addresses, it might correspond to the IPv4Address property in StaticIPAssignmentSettingData class in the TIM core. It might occur that no suitable information element is found for some TSM class, or, in other words, the TSM calls for a feature the TIM does not provide. This can arise from two different causes: • The element is related to the scenario deployment process and therefore has to be included in the testbed parameters set that will be merged with the TIM scenario in the transformation step. • The element is used internally in the scenario, typically related to the processes running in the nodes, and the solution is to expand the TIM with a new module. The opposite situation is also possible, that is, some of the classes or properties in TIM are not required to fulfill the TSM. This means that the testbed is not implementing some of the features included in TIM. In this case the TIM-to-TSM transformation simply prunes the TIM elements that do not apply to that particular testbed. For example, if the testbed is not able to emulate node links due to technological reasons, the TIM_TransmissionCharacteristics are filtered out. Thus, the output of this step is a definition of the TIM-to-TSM transformation rules in natural language and the parameters that need to be merged to the TIM in that process. Note that, depending on the testbed, the structure of the parameters could be complex, so the transformation process cannot generally be based on defining annotations to TIM. 3 Construction of TIM-to-TSM rules: It stands for the codification of the model-to-model transformation based on the rules developed in the previous step. One input is the scenario model expressed in terms of the TIM formalized using the UML profile for CIM (DMTF’s DSP0219 [10]). The other input is the set of testbed parameters. The output is the TSM. This methodology is not bound to any specific language, so QVT, ATL, or any other language can be used. 4 Format adaptation: This step is required to adapt the TSM models to the actual format the configuration management tool is able to process (typically text). This can be done either directly by designing a model-to-text transformation, or indirectly by using an intermediate model-to-model transformation that converts the TSM model to a wellknown model for which the model-to-text is straightforward or already available in transformation libraries (e.g., XML). The same language chosen in the previous step should

also be used to define these transformations. Note that the CIM can be represented not only in UML for an MDA-based transformation, but using other modeling approaches, such as XML with standard encodings like CIM-XML or WS-CIM, or ontologies as shown by some authors [11]. Therefore, XML or ontology-based transformations might also be considered. After taking into account the different transformation technologies involved in those modeling approaches, such as XSLT [12] and XQuery [13] for XML and ontological mappings, we concluded that MDA is the most convenient alternative for our configuration management architecture. The detailed analysis is not included here for the sake of briefness (more detailed information can be found in [14]).

SCENARIO TRANSFORMATION PROCESS DETAIL This section describes the TIM-to-TSM transformation process detail from a general point of view for XML-based TSMs (Fig. 3). Note that XML-based TSMs are widespread in present-day testbeds. A particular realization of this process in the context of our validation experiment is provided in the next section. First, a text-to-model transformation imports the different CIM information pieces encoded in the CIM native textual format (named Managed Object Format) to UML, based on the mapping rules described in DMTF’s DSP0219: (1) the TIM definition based on DMTF’s CIM Schema and the TIM ad hoc extension; (2) the TIM models; and (3) testbed parameters (only when those parameters are based on the CIM). The UML instances corresponding to scenarios and parameters are transformed applying the first model-to-model transformation to get an output model that conforms to TSM (4). A second chained model-to-model transformation does the format adaptation (5), producing the XML models conforming to the XML metamodel that, after a final model-to-text step (6), lead to the XML documents.

USING MODEL-DRIVEN CONFIGURATION MANAGEMENT IN REAL CASES In order to illustrate the use of our approach in real cases, a validation test has been performed. Three different scenarios have been modeled using the TIM (including both the Core and the OSPF Module), automatically transformed to the TSM models of two rather different testbeds, and properly deployed using the scenario-based management tool specific to each of them. The first testbed is the ADRENALINE (AllOptical Dynamic Reliable Network Handling IP/Ethernet Gigabit Traffic with quality of service [QoS]) testbed, a generalized multiprotocol label switching (GMPLS)-based intelligent optical network (ION) developed at CTTC laboratories [1]. The second testbed is a virtualized type, based on the User Mode Linux virtualization technology running on one physical host [2]. Regarding management tools, ADNETCONF (Adrenaline Network Configuration) is in charge



11/18/10

11:13 AM

Page 137

Managed Object Format documents scope UML metamodel

CIM schema + TIM ad hoc extension (CIM classes)

CIM schema

ATL metamodel

UML profile for CIM (DSP0219)

(1) T2M

CIM schema TIM ext

XML documents scope

Modeling tool scope

ECore

XML metamodel

TSM

TIM-to-TSM transformation

TSM adaptation transformation

(UML classes)

TIM ext

Transformation rules (4)

(2) T2M TIM scenarios (CIM instances)

Transformation rules (5)

TIM scenario

Input

Trans. Engine

(UML instances)

Output

TSM scenario

Input

(3)* T2M Testbed parameters (CIM instances)

Testbed parameters (UML instances)

(6) XML Trans. document M2T Engine Output Input TSM scenarios (XML) Data flow (injection transformation, extraction) Instantation or model-conforms-tometamodel relationship

T2M

Text-to-model (injection)

M2T

Model-to-text (extraction)

(*) Optional (see text)

Figure 3. Scenario transformation process.

of scenario-based management in ADRENALINE, while the virtualized testbed is configured with Virtual Network User Mode Linux (VNUML)6. In both cases, each scenario is specified as a set of XML documents (using different DTDs). Note that neither ADNETCONF nor VNUML nor the testbeds they manage were modified to run our experimental validation.

VALIDATION SCENARIOS The validation set consists of three scenarios (Fig. 4): basic, a simple five-node IP network; nsfnet, resembling the NSFNET topology; and rediris, modeling RedIRIS, the Spanish national research and education network. Note that nsfnet and rediris use OSPF, while basic uses static routing. In addition, nsfnet and rediris model long distance links, so a specification of the link delays is also included as QoS constraints. All scenarios have been modeled using instances of the TIM classes. Note that some cases, particularly the rediris one, include around 1000 instances of those classes, with nodes, links, IP addresses, associations among objects, and so on. Thus, this validation illustrates that our proposed configuration management architecture can cope with nontrivial scenarios used in real experiments.

DESIGNING TIM-TO-TSM TRANSFORMATIONS The general methodology previously described has been applied to design the TIM-to-TSM transformations. Regarding the TSM formaliza-


tion (step 1), both ADNETCONF and VNUML use DTDs to validate scenarios. Thus, TSMs can easily be formalized as described above. Regarding TIM-to-TSM associations (step 2), the correspondences design leads to 23 transformation rules and 9 testbed parameters for TIMto-ADNETCONF, and 27 transformation rules and 14 testbed parameters for TIM-to-VNUML. Testbed parameters for ADNETCONF include physical node IP addresses and VLAN information, while for VNUML they include the configuration parameters needed for virtual machine creation (kernel, filesystem, etc.). In both cases, parameters also include information related to the specific software installation of the OSPF suite (e.g., path names for the binary files). Regarding pruning of unnecessary elements, the TIM-to-ADENTCONF transformation omits (i.e., does not transform) TIM elements related to IPv6 configuration, because ADRENALINE only supports IPv4; static routing, not configured by ADNETCONF; and links with MaxConnections greater than 2, since experiments conducted within ADRENALINE always consider point-to-point links. In the case of TIM-toVNUML, only QoS constraints are omitted. The transformation programming (step 3) is based on ATL. Due to practical and technology maturity reasons, it has been preferred over QVT. Finally, regarding format adaptation (step 4), an indirect approach has been adopted, as both VNUML and ADNETCONF are based on XML, and both the XML metamodel and its

6

To avoid confusion, note that the VNUML acronym is not related at all with Unified Modeling Language.

137


11/18/10

11:13 AM

Page 138

CAN

AST

2

2

PVC NAV

2

2 4

GAL

CYL

3

RIO 3

Basic scenario (5 nodes, 3 multipoint links, static routing)

2 3

EXT 10

4

IX

3

CAT

2

2

3

1

MAD

ARA

3

2

2

5

3 3

3

CLM 4

2

2

TEF

3 3

2

BAL

VAL

MUR

AND 2

10

PAL

WA

CA1

NY MI

15

3 6

3 3.75

15 UT

3

Rediris scenario (19 nodes, 31 PPP links, OSPF routing)

3 6

6 3

3

3 NE

PA

3.75 7.5

The numbers shown next to the links are the delays (in milliseconds) to use in each link. NJ

3

IL

CO CA2

6 6

15

5.25 DC

TX 7.5

GA

nsfnet scenario (14 nodes, 21 PPP links, OSPF routing)

Figure 4. Validation scenarios. associated model-to-text transformation are well known and can be reused [14]. Furthermore, the model-to-model transformation to map both TSMs to XML is quite simple, also coded in ATL; it is based on a straightforward top-down algorithm to navigate the TSM composition relationships in the TSM class-trees generating the corresponding elements in the XML model for each tree node. The next section shows simplified examples of mapping and adaptation rules for the TIM-toVNUML case, corresponding to steps 3 and 4. The complete software and scenarios used to develop the experimental validation are publicly available7 (under GPL license), including TSM formal definitions, validation scenarios in TIM, and all the needed ATL transformations (including the XML metamodel and its associated model-to-text transformation).

EXPERIMENT SET UP AND RESULTS 7

http://www.dit.upm.es/gal an/TIMTransforms 8

Eclipse 3.3.2 and ATL 2.0 were used.

138

The validation experiment (outlined in Fig. 5) consists of applying the two TIM-to-TSM transformations to the three scenarios in the validation set in order to generate the six TSM scenarios, which are finally deployed in the corresponding testbeds using VNUML or ADNETCONF. The main part of the process is the TIM-to-

TSM transformation. Figure 6 outlines this process for the basic scenario in the TIM-toVNUML case, showing particular fragment examples of Managed Object Format (initial input), XML (final output), and ATL (in both transformation and adaptation). For the sake of briefness, the figure focuses on the transformation of network objects. As can be seen, compared with Fig. 3, this is a particular case for the general case described before. All the transformations are executed using the ATL plug-in for Eclipse.8 Both VNUML and ADNETCONF have been checked to be able to deploy the different scenarios in the corresponding testbed based on the XML produced by the transformation. Also, the transformation times have been observed to be always under 2.1 s, less than 3 percent in the worst case of the time VNUML/ADNETCONF takes to deploy the scenario on the testbed. We conclude that our proposal does not introduce any significant overhead in the management of the testbed even for large scenarios. Note that the only manual procedures the users need to follow to deploy their scenarios are to model them using TIM instances and define the testbed parameters needed for the transformation step. Once this is done, the remaining steps toward final deployment of the



11/18/10

11:13 AM

Page 139

rediris

basic

nsfnet TIM layer

TIM-to-ADNETCONF parameters

TIM-to-VNUML parameters defaultKernel defaultFilesystem ospfdBinPath ... (11 more)

TIM-to-VNUML 27 transformation rules (detail in figure 6)

Basic VNUML

RedIris NSFNET VNUML VNUML

baseMgtAddress baseVlan ... (7 more)

TIM-to-ADNETCONF 23 transformation rules

Basic ADNETCONF

VNUML

RedIris ADNETCONF

NSFNET ADNETCONF

TSM layer

ADNETCONF

filesystem

OCC1

ospfd kernel Physical host

OCC72

OCC stands for Optical connection controller, the physical nodes in ADRENALINE

The ADRENALINE testbed ® (simplified)

Figure 5. Validation experiment setup. scenario in the testbed are completely automatic.

CONCLUSIONS In this article three main contributions to the current state of the art in scenario-based testbed configuration management are described. First, a novel model-driven management architecture has been presented. Second, we have introduced the Testbed Independent Metamodel (TIM), which provides a high-level vocabulary testbed users can use to define any desired scenario in a deployment-agnostic way. Third, we have described a general and systematic methodology to design automatic transformation from TIM scenarios to the actual scenario descriptions needed by management tools for deployment. The three contributions provide a solution to achieve technological independence between scenarios and testbeds, enabling the reusability of scenarios over different testbeds, and avoiding time-consuming and error-prone manual conversions. The expressiveness of the TIM to describe scenarios in existing testbeds has been demonstrated through experimentation. Apart from assessing that the TIM is able to describe large and complex scenarios, and the methodology can cope with the transformations required, we have shown that our management architecture seamlessly integrates with existing testbeds without


noticeable overhead or requiring any modification in their management tools. Neither ADRENALINE, ADNETCONF, nor VNUML were modified to perform the validation. Our approach is based on two key standards: DMTF’s CIM Schema and OMG’s MDA. Regarding the CIM Schema, it provides the semantic core for the networking concepts on which the TIM is based. Furthermore, the TIM can take advantage of the evolution of the CIM Schema, which is enriched periodically by DMTF. Regarding MDA, UML is used to express TIM scenarios, although a general lack of maturity in current transformation tools has been observed as they do not support all the QVT features and are not stable enough for professional use at this time. We foresee that these issues will be fixed by software implementers as MDA gains more industrial acceptance. Regarding future lines of research, our aim is to follow two different directions: to provide TIM enhancements, such as the modeling of dynamic behavior or validation constraints that can be checked before starting the transformation; and to explore new ways to use the architecture. For example, it can be applied to federated testbeds like the ones considered in the future Internet wave (GENI, FIRE, etc.): TIM scenarios can be split into several parts before starting the transformation, each one assigned to a different federated testbed. Moreover, application to

139


11/18/10

11:13 AM

Page 140

Net2 Net1

Net0

instance of TIM_LinkConnectivityCollection { InstanceID = “net0”; }; instance of TIM_LinkConnectivityCollection { InstanceID = “net1”; }; [...] Managed object format

rule NetMap { from i: TIM!TIM_LinkConnectivityCollection to Net: VNUML!Net ( -- Name property in Net is set using -- InstanceID property in -- TIM LinkConnectivityConnection name