On Scenario-based Model-driven Con guration Management...

Universidad Politecnica de Madrid

Escuela Tecnica Superior de Ingenieros de Telecomunicacion

On Scenario-based Model-drivenConfiguration Management for

Flexible NetworkingExperimentation Infrastructures

Tesis Doctoral

Fermın Galan Marquez

Ingeniero de Telecomunicacion

2010

Departamento de Ingenierıa de Sistemas Telematicos

Escuela Tecnica Superior de Ingenieros de Telecomunicacion

On Scenario-based Model-drivenConfiguration Management for

Flexible NetworkingExperimentation Infrastructures

Author:

Fermın Galan Marquez

Ingeniero de Telecomunicacion

Advisor:

David Fernandez Cambronero

Doctor Ingeniero de Telecomunicacion

2010

Tribunal Calificador

Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Politecnica de Madridel dıa 29 de Enero de 2010.

Presidente

D. Julio Berrocal ColmenarejoCatedratico de Universidad - Universidad Politecnica de Madrid

Vocales

D. Antonio F. Gomez SkarmetaCatedratico de Universidad - Universidad de Murcia

D. Juan Ignacio Asensio PerezProfesor Titular de Universidad - Univerdad de Valladolid

D. Jorge Enrique Lopez de Vergara MendezProfesor Titular de Universidad - Universidad Autonoma de Madrid

Secretario

D. Juan Carlos Duenas LopezProfesor Titular de Universidad - Universidad Politecnica de Madrid

Suplentes

D. Jose Ignacio Moreno NovellaProfesor Titular de Universidad - Universidad Carlos III de Madrid

D. Alberto Garcıa MartınezProfesor Titular de Universidad - Universidad Carlos III de Madrid

FECHA DE LECTURA:

CALIFICACION:

Caminante, son tus huellasel camino y nada mas;

Caminante, no hay camino,se hace camino al andar.

Al andar se hace el camino,y al volver la vista atrasse ve la senda que nunca

se ha de volver a pisar.Caminante no hay camino

sino estelas en la mar.

–Antonio Machado

5

Abstract

The goal of the present dissertation is to improve the current state of the art in configurationmanagement in networking experimentation infrastructures (testbeds). In particular, our goalis to solve the scenario technology-dependency problem, so the same scenarios can be reused indifferent testbeds.

In order to achieve this goal, three objectives have to be addressed. First, to develop a model-driven configuration management architecture that decouples scenario specifications from thetestbeds in which they will be finally deployed. This has to be done without modifying existingtestbeds or their management tools. Secondly, a Testbed Independent Model (TIM), based onDMTF’s CIM, used as main architectural component in order to provide scenario technology-independency. Finally, a generic and systematic methodology to transform TIM scenarios tothe specification formats used in the different current or future testbeds.

In order to achieve these objectives, our work includes an extensive analysis of the mostsalient experimentation infrastructures existing today, paying special attention to their con-figuration management systems. In addition, different technologies to model and transformmanagement information are analyzed, in order to find the best one to base our architecture on.

This dissertation also includes an experimental validation to assess the feasibility of ourarchitecture, which is applied to two different testbeds used for real world experimentation.Additionally, several application cases are described, both for novel testbed architectures (suchas the ones defined in Future Internet initiatives) and production environments.

Keywords

Networking testbed, configuration management, scenario specification, Model Driven Architec-ture, Common Information Model, VNUML, ADRENALINE, ADNETCONF

R© Fermın Galan Marquez 2010. This document is licensed under a Creative Commons Attribution-Noncommercial-

Share Alike 3.0 Spain License (http://creativecommons.org/licenses/by-nc-sa/3.0/es/)

7

Resumen

La presente tesis doctoral contribuye al estado del arte en gestion de configuracion de escenariospara infraestructuras de experimentacion flexible (testbeds). El objetivo es resolver el problemade la dependencia tecnologica de los sistemas actuales de especificacion de escenarios y que, deeste modo, se posibilite la reutilizacion de escenarios entre testbeds de distinta naturaleza.

Este objetivo se materializa en tres contribuciones concretas. En primer lugar, el desarrollode una arquitectura de gestion de configuracion basada en modelos que independice la descripcionde escenarios de los testbeds en los que estos se despliegan y que, al mismo tiempo, no impliqueningun tipo de modificacion en las herramientas de gestion o testbeds actuales. En segundo lugar,el Modelo Independiente de Testbed (o Testbed Independent Model, TIM), basado en el ModeloComun de Informacion (Common Information Model, CIM) de la DMTF, que es utilizado en elcorazon de esta arquitectura para proporcionar descripciones de escenario independientes de latecnologıa de implementacion del testbed. Finalmente, una metodologıa sistematica y general detransformacion desde el TIM a los distintos sistemas de especificacion de configuraciones usadosen cada uno de los distintos testbeds actuales o futuros.

Para conseguir estos objetivos, se realiza un extensivo analisis de las infraestructuras deexperimentacion mas relevantes en la actualizad, prestando especial atencion a la forma en laque implementan la gestion de configuracion. Tambien se analizan las distintas tecnologıas demodelado y transformacion de informacion de gestion, a fin de encontrar la mas adecuada en laque basar la arquitectura.

La tesis incluye una validacion experimental, que demuestra la viabilidad de la arquitectura,al ser aplicada a dos casos de testbeds concretos usados para experimentacion real. Adicional-mente, se describen distintos casos de aplicacion, tanto para nuevas arquitecturas de testbeds(como por ejemplo las que estan siendo definidas en las iniciativas de la Internet del Futuro,Future Internet) como para entornos de produccion.

Palabras clave

Infraestructuras de experimentacion de red, gestion de configuracion, especificacion de escenario,Arquitectura Orientada a Modelos, Modelo Comun de Informacion, VNUML, ADRENALINE,ADNETCONF

R© Fermın Galan Marquez 2010. Este documento se distribuye bajo una licencia Creative Commons Reconocimiento-

No comercial-Compartir Espana (http://creativecommons.org/licenses/by-nc-sa/3.0/es/)

9

Acknowledgements

Let’s start in English. I would like to strongly thank all the people that have provided mewith valuable help, insights and feedback, specially David Andersen, David Lopez, Jorge Lopezde Vergara, Marc Portoles, Jose Luis Marzo, Jose Luis Ruiz, Ken-ichi Chinen, Pierre Zelnicek,Sebastian Wahle, Toshiyuki Miyachi, Vicente Olmedo and Waiki Wright.

Dado que hay ciertas cosas que solo pueden expresarse con total precision en la lengua natal,cambiare ahora al castellano. La presente tesis doctoral no hubiera sido posible sin la inter-vencion de varias personas e instituciones. En primer lugar, he de agradecer a David Fernandez,mi director de tesis, excelente profesional y mejor persona, su acertada guıa y buenos consejos alo largo de todos estos anos, con el que espero seguir colaborando (y aprendiendo) en el futuro.Hago extensible este agradecimiento al Departamento de Ingenierıa de Sistemas Telematicos dela Universidad Politecnica de Madrid, en el que siempre he encontrado un excepcional ambientede trabajo y equipo humano, especialmente a Angelines Villar, Francisco Javier Ruiz Pinar,Juan Carlos Duenas, Luis Bellido, Omar Walid, Tomas de Miguel y Victor Villagra.

Este doctorado se asienta en dos pilares fundamentales, sobre los que se han desarrolladolas ideas fundamentales que, finalmente, han cristalizado en la tesis presente. En primero deellos es VNUML, a cuyos usuarios y desarrolladores he de agradecer todo el esfuerzo dedicadoa nutrir la herramienta original por mı creada con nuevas ideas, mejoras y funcionalidades a lolargo del tiempo. La lista serıa demasiado larga para atreverse a enumerarla aquı, pero quieroagradecer muy especialmente a Francisco Jose Martın y a Miguel Ferrer su excelente trabajo enel plugin de OSPF, sin el cual la validacion experimental de la tesis no hubiera sido posible.

El segundo pilar sobre el que se asienta la tesis es la experiencia en gestion de testbedsdesarrollada en ADRENALINE en el Centre Tecnologic de Telecomunicacions de Catalunyaen Barcelona. Quiero agradecer a esta institucion haber puesto a mi alcance esta magnıficainfraestructura, no solo durante mi periodo profesional en el Centre, sino tambien una vezfinalizado este en los anos sucesivos. Extiendo el agradecimiento, ya en el plano personal, a misex-companeros del Optical Networking Area: Carolina Pinart, Ivan Martınez, Jordi Sorribes,Ramon Casellas, Raul Munoz y Ricardo Martınez.

Tambien me gustarıa agradecer a Miguel Gomez toda la asistencia prestada solucionando misdudas sobre los tramites administrativos de la tesis, siempre con la mejor de las predisposicionesy voluntad de ayuda.

Finalmente, no puedo olvidarme de todos los que habeis estado siempre a mi lado a lo largo deeste azaroso doctorado, incluso en los anos en los que estuve lejos de vosotros, por vuestro apoyoincondicional y por confiar siempre en mı. A todos vosotros, gracias de corazon. Especialmente,a mi familia mas cercana (mis padres y mis tıos Amparo y Manolo) que siempre me ha apoyadoen todos mis proyectos vitales; a Sergio, por espolearme continuamente para que acabara latesis; y a Raquel, por estar a mi lado y darme fortaleza en los peores momentos de debilidad yduda.

11

Contents

1 Introduction 21

1.1 Context and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.3 Application Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.3.1 Interrelated Testbeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.3.2 Future Internet Testbeds . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4 Dissertation Methodology and Structure of the Document . . . . . . . . . . . . . 25

2 Experimentation Infrastructures 27

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Definitions and Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Classification Based on Flexibility . . . . . . . . . . . . . . . . . . . . . . 28

2.2.2 Classification Based on Geographical Distribution . . . . . . . . . . . . . 32

2.3 Locally Distributed Experimentation Infrastructures . . . . . . . . . . . . . . . . 33

2.3.1 Emulab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.2 ADRENALINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.3 ModelNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.4 Virtual-based Testbed Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4 Globally Distributed Experimentation Infrastructures . . . . . . . . . . . . . . . 43

2.4.1 PlanetLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.2 GX-Bone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.4.3 DRAGON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4.4 Future Internet Testbeds . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.5 Generic Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.5.1 Weevil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.5.2 AnyBed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.3 Network Description Language . . . . . . . . . . . . . . . . . . . . . . . . 55

2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 Modeling and Transforming Management Information 61

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2 Modeling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.1 W3C’s eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . 62

3.2.2 OMG’s Modeling Standards . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.3 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.2.4 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.3 Model Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

13

14 CONTENTS

3.3.1 Based on XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.3.2 OMG’s Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . 743.3.3 Ontology mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4 DMTF’s Common Information Model . . . . . . . . . . . . . . . . . . . . . . . . 813.4.1 Web Based Enterprise Management . . . . . . . . . . . . . . . . . . . . . 813.4.2 CIM Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.4.3 CIM Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.4.4 DMTF Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.4.5 UML Profile for CIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.4.6 CIM Representation Alternatives . . . . . . . . . . . . . . . . . . . . . . . 893.4.7 Other Management Information Languages and Models . . . . . . . . . . 89

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4 Model Driven Scenario Configuration Management 934.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.3 The Testbed Independent Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.3.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.3.2 CIM-based TIM Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.3.3 Completeness Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.3.4 TIM as DMTF pseudo-profile . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.4 TIM-to-TSM Transformation Design Methodology . . . . . . . . . . . . . . . . . 1004.4.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014.4.2 Transformation Alternatives Discussion . . . . . . . . . . . . . . . . . . . 1014.4.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.4.4 Transformation Not Based on Modeling . . . . . . . . . . . . . . . . . . . 106

4.5 Model-Driven Configuration Management Roles . . . . . . . . . . . . . . . . . . . 1084.5.1 Scenario Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.5.2 Testbed Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.5.3 Other Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5 Testbed Independent Model Detailed Description 1115.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.2 TIM Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.2.1 TIM Core Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.2.2 TIM Core Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.3 TIM OSPF Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.3.1 TIM OSPF Module Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.3.2 TIM OSPF Module Associations . . . . . . . . . . . . . . . . . . . . . . . 122

5.4 TIM ad hoc Extension Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6 Experimental Validation 1256.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.2 Testbeds Used for the Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.2.1 VNUML-based Testbed TSM . . . . . . . . . . . . . . . . . . . . . . . . . 1266.2.2 The ADRENALINE Testbed TSM . . . . . . . . . . . . . . . . . . . . . . 127

CONTENTS 15

6.3 Validation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.4 Validation Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.4.1 TIM-to-VNUML Transformation . . . . . . . . . . . . . . . . . . . . . . . 1326.4.2 TIM-to-ADNETCONF Transformation . . . . . . . . . . . . . . . . . . . 1376.4.3 TIM Scenario Generation Workflow . . . . . . . . . . . . . . . . . . . . . 1426.4.4 TSM Scenario Generation Workflow . . . . . . . . . . . . . . . . . . . . . 1436.4.5 Scenario Deployment Workflow . . . . . . . . . . . . . . . . . . . . . . . . 147

6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7 Application 1517.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517.2 Conventional Scenario-based Interrelated Testbeds . . . . . . . . . . . . . . . . . 1517.3 Future Internet Federated Testbeds . . . . . . . . . . . . . . . . . . . . . . . . . . 153

7.3.1 Federation to Support Very Large Scenarios . . . . . . . . . . . . . . . . . 1547.3.2 Federation to Support Scenarios Mixing Specialized Resources . . . . . . 156

7.4 WBEM-based Testbeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577.5 Production Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

8 Conclusions and Future Work 1638.1 Main Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.2 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

8.2.1 Main Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678.2.2 VNUML Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678.2.3 ADNETCONF Publications . . . . . . . . . . . . . . . . . . . . . . . . . . 169

8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698.3.1 Experiment Dynamics Modeling . . . . . . . . . . . . . . . . . . . . . . . 1708.3.2 Constrains Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708.3.3 The Common Testbed Model . . . . . . . . . . . . . . . . . . . . . . . . . 1718.3.4 Inverse Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

A Conventions 173A.1 Font Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173A.2 UML Graphical Notation Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

B TIM ad hoc Extension Model 175

C Experimental Validation ATL Transformations 179C.1 TIM-to-VNUML Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

C.1.1 TIM2VNUML.atl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179C.1.2 TIM2VNUMLOspf.atl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

C.2 TIM-to-ADNETCONF Transformation . . . . . . . . . . . . . . . . . . . . . . . . 185C.2.1 TIM2ADNETCONF.atl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185C.2.2 TIM2ADNETCONFOspf.atl . . . . . . . . . . . . . . . . . . . . . . . . . 189

C.3 Common Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191C.3.1 TIMHelpers.atl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

D Acronyms 195

16 CONTENTS

List of Figures

1.1 Current (left) and target (right) scenario-based configuration management in test-beds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1 Testbeds classification based on flexibility . . . . . . . . . . . . . . . . . . . . . . 282.2 Typical scenario lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3 Emulab architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4 Emulab experimentation scenario lifecycle . . . . . . . . . . . . . . . . . . . . . . 352.5 ADRENALINE testbed data communication network . . . . . . . . . . . . . . . 372.6 PlanetLab architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.7 PlanetLab slice creation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.8 GENI architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.9 PASITO architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1 XML document and associated tree (example) . . . . . . . . . . . . . . . . . . . . 623.2 OMG’s Modeling Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.3 EMOF metamodel (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.4 Classes and instances as M1 elements in UML 2.x . . . . . . . . . . . . . . . . . . 683.5 UML metamodel (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.6 Example of chained transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 763.7 MDA transformation (one input and one output) . . . . . . . . . . . . . . . . . . 773.8 MDA transformation (QVT sub-languages and their relationships) . . . . . . . . 783.9 Simple mapping ontology (from [LVAB03]) . . . . . . . . . . . . . . . . . . . . . . 813.10 WBEM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.11 CIM metamodel (as defined in [DMT08a]) . . . . . . . . . . . . . . . . . . . . . . 843.12 CIM Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.13 CIM Core (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.14 DMTF profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.1 Model-driven architecture for scenario-based management . . . . . . . . . . . . . 944.2 Integrated scenario-based testbed configuration management approach . . . . . . 964.3 TIM as DMTF pseudo-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.4 XML metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.5 TIM-to-TSM transformation detail: direct (top) and indirect for XML (bottom) 1074.6 Scenario designer and testbed administrator roles . . . . . . . . . . . . . . . . . . 108

5.1 TIM classes regarding to CIM Schema . . . . . . . . . . . . . . . . . . . . . . . . 1125.2 Testbed Independent Model (TIM) class diagram . . . . . . . . . . . . . . . . . . 112

17

18 LIST OF FIGURES

5.3 Linking between TIM Modules and TIM Core . . . . . . . . . . . . . . . . . . . . 1215.4 TIM ad hoc Extension validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.1 VNUML and ADNETCONF TSMs as functionality subsets . . . . . . . . . . . . 1266.2 ADRENALINE PPP implementation detail . . . . . . . . . . . . . . . . . . . . . 1286.3 Validation set scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.4 Validation experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316.5 VNUML TSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336.6 ADNETCONF TSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.7 Scenario MOF validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426.8 Transformation execution workflow (ideal) . . . . . . . . . . . . . . . . . . . . . . 1446.9 Transformation execution workflow (actual) . . . . . . . . . . . . . . . . . . . . . 146

7.1 Conventional scenario-based configuration management in interrelated testbeds . 1527.2 Model-driven scenario-based configuration management in interrelated testbeds . 1537.3 Using federated testbeds to cope with large scenarios . . . . . . . . . . . . . . . . 1557.4 Using federated testbeds to cope with specialized resources requirements . . . . . 1567.5 TIM TestbedScenario including methods . . . . . . . . . . . . . . . . . . . . . . . 1577.6 WBEM-based architecture for scenario oriented management . . . . . . . . . . . 1587.7 From WBEM-based testbed to WBEM-based production network . . . . . . . . . 160

8.1 Alignment with standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

A.1 UML class notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173A.2 UML relationship notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

List of Tables

2.1 Flexible testbeds infrastructures and tools analysis summary . . . . . . . . . . . 57

3.1 CIM metaschema to UML metaclasses mapping . . . . . . . . . . . . . . . . . . . 88

4.1 TIM completeness evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.1 Validation testbeds summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1256.2 Validation set summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.3 Testbed parameters for TIM-to-VNUML transformation . . . . . . . . . . . . . . 1356.4 Testbed parameters for TIM-to-ADNETCONF transformation . . . . . . . . . . 1416.5 Transformation and deployment times . . . . . . . . . . . . . . . . . . . . . . . . 148

19

20 LIST OF TABLES

Chapter 1

Introduction

1.1 Context and Motivation

A networking testbed can be defined as a controlled infrastructure, a pre-production system ora prototype, used either to experiment with networking systems under conditions that resemblethose in production networks or to test a given technology1. They play a key role in research,industrial and educational environments. In research, testbeds have been used from the verybeginning and they are valuable tools in the current hot topics, such as optical and wirelessnetworking. It is worth noting that the Internet itself was in its origin at 1960s a testbed to assessthe feasibility of packet switching technology [NSF02]. In fact, testbeds are nowadays utilizedfor designing and experimenting with the protocols, architectures and services that will shapethe networks of the future, gaining momentum within the Future Internet initiatives [Rob09].From an industrial point of view, testbeds are very useful platforms to test and debug networkservices and software implementations before using them in a real production environment.Finally, a testbed can be very suitable for students in colleges and engineering schools, so theycomplement what they have learnt in theoretical lessons with practical skills, working in (almost)real networking environments.

Networking testbeds can be roughly divided into two categories: flexible and inflexible (alsonamed configurable and unconfigurable). The latter are those that require changes in theirphysical layout to be used for different experiments. This might be the case of a physical layertestbed, e.g. a radio testbed. In the context of this work we will focus on the former, flexibletestbeds whose main challenge is how to maximize testbed usefulness, i.e. being able to setup the infrastructure in as many experimentation scenarios as possible without changes to thephysical infrastructure. An experimentation scenario can be defined as a networking context,i.e. network topology and associated configuration for processes and services, in which someexperiment is conducted within a given timeframe2.

In order to avoid issues related to manual operation, scenario-based management is an ef-fective way to implement testbed configuration. This paradigm is based on specifying thedesired scenario in a formal way using a given language. Then, the scenario specification isprocessed by a management tool in charge of interacting with the testbed infrastructure to setup and manage the desired scenario. This is the way in which several state of the art test-beds work, e.g. Emulab [WLS+02] whose scenarios are specified in ns2; the ADRENALINEtestbed R© [MPM+05] which uses XML, and the different tools that allow to build virtualized

1A more precise definition for networking testbed will be provided in Section 2.2.2A more precise definition for experimentation scenario will be provided in Section 2.2.1.2.

21

22 CHAPTER 1. INTRODUCTION

testbeds (VNUML [GFF+09], NetKit [PR08], MLN [Beg06] or vBET [JX03]), which use differ-ent variants of text file formats. Other testbeds, such as PlanetLab [PACR03], are not trulyscenario-based, but provide open management APIs on top of which such management approachcan be built.

In this context, it is desirable to have a common scenario specification mechanism. Thiswould allow the reuse of the same scenarios in different testbeds, a common situation with com-plex problems that require either the same experiment to be conducted in several complementarytestbeds or experiments to be shared among peer researchers working on the same topic in theirrespective testbeds. Currently, if a scenario needs to be used on different testbeds, the userswould need to manually carry out time-consuming error-prone conversions.

However, current languages are completely coupled to the particular testbeds in which theyhave been developed. Only a few initiatives have tried to define a general scenario specificationmechanism, such as Weevil [WRCW05] or AnyBed [SHK06]. Nonetheless, in addition to somelimitations in their respective models derived from the omission of important scenario attributes,their integration with existing testbeds is not clearly defined.

In this dissertation that challenge is addressed by proposing a new configuration manage-ment approach based on a common and testbed-independent model. Our proposal seamlesslyintegrates with existing scenario-based management tools using model-driven principles. It isscenario-based as is using scenario specifications as first class management entities, while model-driven indicates that the same scenario is transformed between abstraction levels, from oneindependent of the testbed to one specific to it.

It is worth noting that although our scope is configuration management in flexible networkingexperimentation infrastructures, the context is similar to the one in networking simulation andin some production environments, e.g. virtualized networks belonging to telecommunicationoperators. Thus, our contribution could also be applied to those cases, keeping in mind thedifferences to the main focus in this dissertation.

Regarding simulation models running within network simulators, such as ns2 [ns10] or OP-NET [Cha99], they are very useful in order to study the feasibility of new network systems ina quick and inexpensive way during the first stages of development. Actually, these systemsusually employ specifications in which the details of the simulation (e.g. topology, events, trafficloads, etc.) are described in a similar way to experimentation scenarios in scenario-based flexibletestbeds. The difference is that simulations are processed by network simulator engines, involv-ing strong abstractions (e.g. simplified mathematical models for traffic load generation, use ofsimulated-time instead of real-time, inability of running actual implementation code, etc.) andproducing results (in the form of numerical values, statistical data, graphs, etc.), while scenariosare processed by configuration management systems, producing interactions with the testbedphysical equipment. However, the notion of scenario specification as a formal description of anetworking environment is much the same in both cases.

Regarding production environments, some of them also consider formal specifications. Forexample, service architectures that are described using the OVF (Open Virtualization For-mat [DMT09b]) to be deployed on cloud computing platforms such as Amazon EC2 [GSRM+09].In this case, an OVF descriptor would be equivalent to a scenario specification in flexible net-working testbeds and could be produced from a technology-independent model as considered inour proposed configuration management architecture.

1.2. OBJECTIVES 23

1.2 Objectives

The main goal of this dissertation is the development of a configuration management ar-chitecture for flexible experimentation infrastructures that solves the problem ofscenario technological dependency, so a scenario can be specified using a commonlanguage independent of the different testbeds on which it will be finally deployed.Basically, we are addressing the current problem in state of the art testbed management, inwhich the different scenario-based tools used in each testbed use scenario specifications basedon different formats (Figure 1.1, left). Our goal is to improve this situation with a solutionwhich decouples scenario specifications from testbeds (Figure 1.1, right).

Testbed 1 Testbed 2 Testbed N…

Desired scenario

many testbed-specific scenario specifications

Testbed 1 Testbed 2 Testbed N…

just one testbed independent specification

Scenario-based Model-driven Architecture

The Testbed Independent Model

TransformationMethodology

Scenario technological independence solution

Figure 1.1: Current (left) and target (right) scenario-based configuration management in test-beds

In order to achieve this goal, three different elements have to be addressed as separated butrelated contributions of this dissertation:

• The configuration management architecture that processes the common and technologi-cal independent scenario specifications in order to adapt them to the different testbeds.The main design requirements for this architecture are to be generally applicable to anyscenario-based testbed and to be seamlessly integrable with existing testbeds and theirmanagement tools, i.e. without involving any modification on them.

• The Testbed Independent Model (TIM) to specify scenarios in a common and technologyindependent way. On the core of the management architecture described in the previousbullet is the language that enables the description of experimentation scenarios in a com-mon and testbed agnostic way. As design principles we consider completeness, modularity,network layer orientation, extensibility and simplicity. An analysis of the different scenariospecification mechanisms used in the state of the art testbeds will drive the design of thistestbed independent model.


• Finally, the adaptation mechanism to fill the “gap” between the common scenario specifi-cation and the different testbed-specific scenario specifications, which are the ones actuallyprocessed by testbed scenario-based management tools. In this case, our goal is not design-ing particular adaptation mechanisms, but to define the general methodology to producethem.

1.3 Application Cases

In order to provide a clearer idea of the problem this dissertation is addressing and the motivationof our solution, this section illustrates how the scenario technology-dependency imposes actuallimitations in different cases. Note that the two cases herein introduced are later expanded inChapter 7, showing there the advantages of applying our contribution.

1.3.1 Interrelated Testbeds

Usually, the complexity of the state of the art problems in which networking researchers work(e.g. development or improvements of new protocols, analysis of existing systems, etc.) requiresthe use of several interrelated testbeds, but using the same set of scenarios to get coherent results.Each testbed is addressed to a particular aspect of the experiment the researcher is performing.For example, a first testbed based on virtual machines to test the software implementing a givendynamic routing algorithm in order to debug the code, then a second test in globally distributedexperimentation infrastructure such as PlanetLab, and finally a testbed composed of a hardwareplatform where the final version of the software is stressed and tuned in near-to-real conditions.

Considering a set of N scenarios to be used in T interrelated testbeds, the researchershave to face several problems. First, the N scenarios have to be designed for each differenttestbed in parallel, so the manual designing effort multiplies by a factor equal to the numberof interrelated testbeds (T ). Secondly, the N scenarios are rarely a static set, as during thedifferent experimentation cycles in the different testbeds some issues may arise that involvescenarios modification before running new tests using them, e.g. the researchers finds out that aparticular topology is useless and need to change it to test again. This feedback may happen ineach one of the testbeds, however not only the scenario for the given testbed has to be modified,but also the parallel ones in the other testbeds. This manual synchronization process is very timeconsuming and error prone. It is also hardly scalable, because each single scenario modificationinvolves T-1 derived additional modifications.

There are additional challenges in the case of testbeds belonging to different organizationsand operated by different researchers. In this context, synchronizing scenario modifications canbe even harder, as each researcher knows the testbed it operates but usually does not knowtestbeds run by other organizations. Researchers first need to synchronize their knowledge (i.e.how scenarios are specified in each testbed) before synchronizing scenarios themselves.

1.3.2 Future Internet Testbeds

The so called Future Internet infrastructures emerging nowadays, such as GENI [EF09] or FED-ERICA [FED10], are based on the federation of different testbeds that are independently man-aged, i.e. each one using its specific scenario specification language and management tools.Thus, one of the challenges in Future Internet testbeds is how to split and deploy a global targetscenario (very large and/or using specific network resources) into several subscenarios, each oneaddressed to one of the different federated testbeds.

1.4. DISSERTATION METHODOLOGY AND STRUCTURE OF THE DOCUMENT 25

The absence of a common language to specify the large target scenario would force the re-searchers to produce directly the subscenario specifications to be processed by the managementtools in each federated testbed, so the splitting process has to be done manually. This can behighly inconvenient, as the optimal splitting algorithm can be very complex and, in addition,may require a real time snapshot of the testbed status difficult to get without automatic pro-cedures. Moreover, potential changes in the scenario due to feedback during the experimentsneeds manual synchronization among subscenarios, being a similar problem to the one describedfor interrelated testbeds in Section 1.3.1.

1.4 Dissertation Methodology and Structure of the Document

In order to accomplish the objectives described in Section 1.2, the following stepped method-ological process has been carried out. First, a comprehensive enough state of the art has beenperformed in order to have a clear understanding of the problem domain (i.e. configuration ma-nagement in networking testbeds) and the dissertation objectives derived from it. This analysisis extended to technologies that, although do not belong to the problem domain, are neededto develop the solution. Once the problem is clearly defined, its solution has been developed,corresponding to the dissertation contributions, and assessed by an experimental validation ina real utilization case. In addition, the application of the solution to other use cases has beenstudied. Finally, the main conclusions of the dissertation and its possible continuations in futureworking lines have been described.

This document has been structured according to the methodology described in the previousparagraph (see Figure 1.2). In particular:

• Chapter 2 provides a testbed taxonomy used as reference along the document and, then,an analysis of the most relevant testbeds existing nowadays. Special attention is paid totestbed configuration management systems, as the aim of this chapter is to provide a stateof the art on them and discover the problems in the current approaches.

• Chapter 3 addresses a description of technologies to model and transform managementinformation. As modeling and transformation technologies W3C’s XML, OMG’s standardsand ontologies are considered, while the analysis on management information is focusedon DMTF’s CIM. The technologies described in this chapter are the foundation used inthe model-driven management architecture developed in this work.

• Chapter 4 describes the core of our contribution. In particular the novel scenario-basedmodel-driven management architecture, along with the Testbed Independent Model (TIM)as its main piece. In addition, the methodology to define transformations to specific testbedscenario models is described.

• Chapter 5 provides a more detailed description of the Testbed Independent Model (whichin the previous chapter is described from a high level point of view).

• Chapter 6 is devoted to the experimental validation that assesses the feasibility of ourapproach. This chapter describes how the scenario-based model-driven architecture iseffectively used to deploy scenarios on two real world testbeds.

• Chapter 7 describes different applications in which our contributions can be used, with theaim of showing the flexibility and applicability of the management solution to different use


cases. In particular, conventional interrelated testbeds, Future Internet federated testbedsand WBEM-based testbeds are considered. We also briefly deal with the application ofour contribution to production environments, going one step further than our central focuson experimentation infrastructures.

• Finally, Chapter 8 provides the main conclusions of our work, including a summary ofcontributions and the publications resulted from this dissertation. It also includes somefuture working lines that could be followed to extend our work.

State of the art on testbed configuration

management

Testbeds introduction& taxonomy

Scenario-based Model-driven Architecture

The Testbed Independent Model

TransformationMethodology

Model-driven management forVNUML and ADRENALINE

Ch 2

CONTRIBUTION

Languages

Transformation

DMTF’s CIM

Ch 3

Problem statement Enabling technologies

Ch 4

TIM detailedspecification

Ch 5

Ch 7Ch 6

Experimental validation Application cases

Conventional

Future Internet

WBEM-based testbedProduction environments

Figure 1.2: Document structure

The document also includes several annexes that complement the above chapters. In particu-lar, Appendix A describes the notation conventions used along this document. Next, Appendix Bprovides the formal specification of the TIM ad hoc Extension (a part of the TIM). Appendix Cincludes the formal specification for the transformations used by the experimental validationdescribed in Chapter 6. Finally, Appendix D provides a list of the acronyms used along thedocument.

Chapter 2

Experimentation Infrastructures

2.1 Introduction

As stated in Section 1.1, the scope of this dissertation is the management of flexible networkingexperimentation infrastructures. Therefore, this chapter provides a thoughtful state of the artanalysis on the most relevant testbeds existing nowadays, considering stable well-known long-running infrastructures (such as Emulab or PlanetLab) and the main tools that are used tobuild testbeds.

There are several points of view that can guide the analysis of networking testbeds. Consi-dering the scope of our work, we are not interested in architecture technological details, whichcan be very complex and very tied to the specific networking field the testbed is addressing orrelated with low-level operational details. Although high-level testbed architectural descriptionswill be provided, our focus is configuration management, i.e. which mechanisms the testbedprovides in order the user can configure and manage his or her desired scenarios. In particular,the following issues will be addressed:

• Basic operation of the configuration management system.

• Scenario lifecycle, paying special attention to how scenario elements are mapped to thephysical infrastructure and whether the testbed supports special scenario managementoperations or just the basic deploy-undeploy cycle.

• The ability of the testbed to support multiple concurrent scenarios (shareability).

Before starting with the actual state of the art analysis, a testbed taxonomy is introduced(Section 2.2) to provide a reference classification. Then, the most salient cases of flexible testbedsand tools to build them in the two major categories in this classification, locally distributedand globally distributed, are analyzed in Sections 2.3 and Section 2.4, respectively. In addition,Section 2.5 considers some early generic approaches that have been proposed as limited solutionsto the problem of scenario testbed technology dependency. Finally, the main conclusions of theanalysis performed in this chapter are provided in Section 2.6.

2.2 Definitions and Taxonomy

As introduced in Section 1.1, a networking experimentation infrastructure (or networking test-bed) can be defined as a controlled networking system, a pre-production system or a prototype,

27

28 CHAPTER 2. EXPERIMENTATION INFRASTRUCTURES

composed of node devices (e.g. end systems, switches, routers, etc.) used to experiment withnetworking systems (e.g. new architectures or protocols, software implementations, etc.) underconditions that resemble the ones in real networks or to test a given technology1.

There are several ways of classifying networking testbeds. For example, they can be catego-rized according to their physical extension, distinguishing, in one end, locally deployed testbedsrunning in a laboratory room and interconnected through local area networks, and, in the otherend, global planetary testbeds interconnected through Internet. Another classification could beaccording to the specific field in which the testbed is focused, e.g. wireless or optical networking,including the case of general purpose infrastructures suitable for a wide range of experimentationtopics. They can be also classified according to the implementation technology, e.g. testbedscomposed of physical nodes or implemented using some virtualization technique.

Among the different criteria, two of them are specially important in the context of our workdue to they are related with configuration management aspects. In particular, flexibility andgeographical distribution, which will be tackled in the next sections, respectively.

2.2.1 Classification Based on Flexibility

Flexibility can be defined as the testbed capability of reconfiguring its infrastructure in orderto implement different networking scenarios, without requiring changes in the physical layout.Given that our work is related with configuration management, flexibility is one of the maincriteria, thus resulting in the following classification (see Figure 2.1), which we detail in the nextsubsections.

Testbed physical infrastructure

Scenario enabling technologies(virtualization, VLAN, link emulation, etc.)

Scenario Scenario Scenario Scenario

network topology,node/link properties/configurations,event sequences

Con

figur

atio

n m

anag

emen

tscenario-based ornot scenario-based

Scenario(coupled with

the infrastructure)

Testbed physicalinfrastructure

Flexible testbedInflexible testbed

Figure 2.1: Testbeds classification based on flexibility

1To the best of our knowledge, there is not any widely accepted definition for networking testbed. On theone hand, the Merriam-Webster dictionary broadly defines a testbed as “any device, facility, or means for testingsomething in development” [Dic10b]. Other sources introduce the aim of resembling the real world, as the oneprovided by WordNet “a place equipped with instruments for testing under working conditions” [Dic10c]. On theother hand, networking is defined as “the establishment or use of a computer network” [Dic10a], so by using thisterm in “networking testbed” we mean that the purpose of the testbed is experimentation related with computernetworks. Thus, in conclusion, the definition we provide in this document (based in the one proposed in ourrecent work [GLFM09]) is a sum of the previous ones and fits very well in the context of this dissertation as itincludes all the relevant elements that we need to define the problem statement and its solution.

2.2. DEFINITIONS AND TAXONOMY 29

2.2.1.1 Inflexible Testbeds

Inflexible testbeds, such as WHYNET [TBG+05] or the PRIME project [LMVH07] are focusedon just one experimentation setup, built to test a very specific system. Reconfiguration is notpossible without altering the physical layout. Therefore, each time a reconfiguration operationis done the testbed has to be physically rebuilt.

As a consequence, infrastructure and operational costs are very high, so this kind of testbedsis usually set up only when no other alternative is possible, typically in the context of physicallayer technologies, e.g. to study radio propagation issues of a new wireless hardware, or whentheir planned lifetime is so short that it does not worth the time to develop a managementsystem for them.

As stated in Section 1.1, this kind of testbed lies out of the scope of this work, so we are notconsidering them any further in our state of the art analysis.

2.2.1.2 Flexible Testbeds

Flexible testbeds are able to configure different experimentation scenarios (i.e. network topolo-gies, service configurations, etc.) using the same physical infrastructure. Therefore, once thetestbed physical layout has been set up, it does not need to be changed except in very rareexceptions, such as hardware upgrades or to replace broken equipment. The more scenarios atestbed can implement, the more flexible and useful the testbed is. Given the high investmenta flexible testbed implies, they tend to be long-lived infrastructures, sometimes shared amongseveral users, either individuals or collective (research groups, company department, etc.).

An experimentation scenario can be defined from a high-level point of view as a networkingcontext provided by the testbed in which some experiment is conducted in a given timeframe(hours, days or even months). The particular elements included in the aforementioned net-working context will depend on the particular testbed2. However, some elements are commonlyincluded:

• Firstly, a scenario involves a network topology , i.e. the set of nodes in which the experimentswill be conducted, along with the interconnections among them.

• Next, properties or configurations for nodes (e.g. capacities as memory or storage, operat-ing system, software packages, dynamic routing configuration, running services and theirconfigurations, etc.) and links (e.g. bandwidth, delay, loss probability and other QoSconstrains parameters) are also specified.

• Finally, although many testbeds only allow static setups, so any dynamic change has tobe introduced by the experimenter himself or herself, in some cases sequences of eventsare also included to be reproduced once the scenario has been set up, e.g. links goingdown and up in scheduled moments in order to study how some routing algorithm reactsto changes.

In order to be flexible, a testbed needs to decouple the provision of experimentation scena-rios from the physical infrastructure supporting them. Moreover, scenario provisioning should

2Testbeds use different terms to refer to the experimentation scenario concept. For example, Emulab (descri-bed in Section 2.3.1) simply employs experiment, while ModelNet (Section 2.3.3) uses model network and MLN(Section 2.3.4.3) uses project. Moreover, some testbeds even do not define the concept and use it in an implicitway. In order to avoid confusion, we unify terms using always experimentation scenario (or simply scenario forbriefness) along this document.


be done in a way that enabling technologies, e.g. link emulation software, virtual networksuch as VLAN (Virtual Local Area Network [IEE01]) or MPLS (Multi-Protocol Label Switch-ing [RVC01]), virtualization software to create nodes, etc., impact with a minimal footprint(ideally none) in the experiment realization. Otherwise, the experiment results and the conclu-sions derived from them could be wrong, or at least inaccurate, making the testbed an uselessexperimentation tool. This could be even more challenging in the case of large multi-user test-beds supporting concurrent scenarios execution, because each experiment needs to be conductedwithout interference with others, thus imposing severe isolation requirements.

Configuration management is a functionality required in flexible networking testbeds, giventhat the network equipment composing the testbed needs to be set properly in order to providescenarios. The International Telecommunication Union (ITU) has defined configuration mana-gement as the functions to “exercise control over, identify, collect data from and provide datato NEs” [ITU00b]. This is a general definition that, applied to the the scenario provisioningcontext, push special relevance in the sub-topics of provisioning (“procedures which are neces-sary to bring an equipment into service, not including [physical] installation”) and status andcontrol (“capability to monitor and control certain aspects of the NE on demand”). In our case,the “service” is the experimentation scenario set up and the “aspects of the NE”, the aspectsrelated with scenario provisioning.

Flexible networking testbeds can be further classified according to how they implementconfiguration management:

• Not scenario-based configuration management. The configuration management systemlacks of an integrated view of experimentation scenarios. In other words, scenarios arenot considered first class entities in the management system, so their provision is based ona decoupled set of individual configuration operations. These operations can be manual,i.e. the experimenter remotely access to each piece of equipment and introduce com-mands in its local execution environment, or semi-automatized, typically through the useof scripts. They can be also based on services provided by the testbed infrastructure itself.Alternatively, conventional network management systems, either standard ones (such asSNMP [HPW02] or WBEM [DMT09e]) or vendor-specific, can be used to implement theseoperations, given that, after all, testbed equipment is not different from any other networkequipment from the point of view of management.

The problem with management not based on scenarios is that the more complex thedesired scenario is, in terms of network size, element properties, etc., the more difficult isto configure it because of it involves more individual management operations.

• Scenario-based configuration management. The configuration management system is basedon operations performed on scenarios, or more precisely on scenario specifications whichare formal representations of the experimentation scenarios. The basic operations canbe arranged in a workflow usually named experimentation scenario lifecycle (shown inFigure 2.2):

– Firstly, an user designs a networking scenario where the tests will be performed. Thisscenario usually includes a specification of the network topology (number of nodes,its properties and its interconnections) and a specification of the configuration of theprocesses (i.e. programs, services, etc.) to be run in each node.

– Next step is to deploy the scenario in the testbed infrastructure, configuring its phys-ical elements in the proper way.

2.2. DEFINITIONS AND TAXONOMY 31

– Once the scenario is set up and ready, user can conduct experiments, e.g. launchingcommands, executing programmed tests, collecting results, etc.

– Finally, when tests are over, the scenario is undeployed, releasing assigned testbedresources (i.e. physical nodes, network addressing space, etc.) so they get free todeploy new scenarios or the same in a later time.

Regarding deployment, some testbeds (such ADRENALINE, described in Section 2.3.2)need scenario specifications to include the detail of how the elements in the scenario (e.g.nodes in the scenario topology) are mapped to testbed physical resources (e.g. actualphysical nodes), so the user of the management system needs to be aware about theavailability of resources. On the contrary, other testbeds (such as Emulab, described inSection 2.3.1) provide automatic resource allocation, so deployment information is notincluded in scenario specifications and, thus, the user can work at high-level when definingexperiments. We name both cases explicit allocation and automatic allocation, respectively.

Deploy and undeploy are the basic operations in scenario-based testbeds. However, otherauxiliary operations can be considered during the experiment execution step. For example,monitoring in order to check whether the scenario is properly deployed or not. Otherpossibilities are schedule-related operations (e.g. play, pause, stop, etc.) in order tomanage sequences of events included in scenarios, in the case that dynamic behavior hasbeen included as part of the scenario specification. The particular set of operations dependson the capabilities of the particular testbed.

Deploy UndeployDesign Operationsat runtime

explicit allocation orautomatic allocation

events executionscenario monitoringothers

Figure 2.2: Typical scenario lifecycle

Note that using a scenario-based approach does not necessarily exclude conventional ma-nagement (SNMP, WBEM, vendor-specific, etc.). The scenario-based configuration toolcould be based on it, so when a high-level operation (as deploy) is issued it is auto-matically broken down in a set of atomic management operations (e.g. SNMP-based orWBEM-based messages) issued to the physical testbed devices. However, from the pointof view of testbed user, this complexity is hidden by the scenario-based configuration tool.

2.2.1.3 Scenario-based Configuration Management Advantages

As many of the testbeds analyzed in this chapter implement a scenario-based configuration ma-nagement approach (as it will be seen in Table 2.1), this section summarizes the main advantagesthat this management approach involves.

The configuration operations to deploy and undeploy scenarios are the most critical stepsduring testbed management. This is especially significant in the case of heavily used testbeds


that need to be quickly reconfigured between experiments in order to maximize its usage. Manualreconfiguration is the simplest procedure because it does not require special tools. However,introducing commands and configurations manually in the different testbed devices has severalimportant drawbacks:

• It is a very time-consuming task due to the effort spent performing tedious and mechanicsoperations.

• Reconfiguration needs specific knowledge regarding the testbed technology not relatedwith the goal of the testbed itself. Testbed users are supposed to be experts in theexperimentation field the testbed addresses but not necessarily in the low-level testbedenabling technologies.

• Humans tend to make errors typing commands, writing configurations or operating ma-nagement interfaces. Those errors are usually very subtle and difficult to detect and mayproduce a wrong deployed scenario without notice, thus corrupting the experimentationresults. For multi-user testbeds, errors can be even more problematic. In this case, awrong deployment could conflict with already deployed scenarios, maybe even belongingto a different user.

• Manual reconfiguration is poorly scalable because the bigger the scenario to be deployedis, the more time it takes to get it configured and more likely to introduce errors.

The use of the scenario-based approach can relieve this situation, enabling the developmentof automatic tools and procedures and overcoming all the aforementioned problems:

• The utilisation of automatic configuration management procedures solves the problem oftime-wasting because of the work is done by the tool on behalf of the user.

• The scenario specification provides a first level of isolation for specific low-level details ofthe testbed. Although it includes details regarding the deployment (specially in the case ofexplicit allocation), the difficult low-level configuration management actions are performedby the deployment tool processing them.

• Human error occurrence is dramatically reduced since human interaction is avoided.

• Scalability is achieved, because the processing logic implemented by the software tool isthe same no matter the size of the networking scenario.

Thus, scenario-based approaches are clearly better than not scenario-based ones and, in fact,they can be considered the state of the art in configuration management for testbeds. Theironly drawback is the implementation cost of the scenario-based configuration tools.

2.2.2 Classification Based on Geographical Distribution

From a high level architectural point of view two kinds of testbeds can be considered: locallydistributed and globally distributed .

A locally distributed testbed can be defined as one which physical elements are locatedin the same site, e.g. a laboratory room. A significant consequence of this fact is that theinterconnection (usually a backbone of LAN switches) can be completely controlled by the

2.3. LOCALLY DISTRIBUTED EXPERIMENTATION INFRASTRUCTURES 33

testbed management system. The local nature of this kind of testbed does not preclude externalconnections (e.g. Internet), usually used for remote access and operation. These testbeds useto be controlled by a single organization, e.g. a research center or an university department.

On the contrary, in globally distributed infrastructures, the testbed elements are spreadover a wide area (a country or the entire world) and interconnected using some global network,Internet or dedicated backbones. In this case, not only the interconnection network is usually outof control of the testbed management system but also it could be shared with traffic not belongingto the testbed, even production traffic. In the case of using Internet as interconnecting networkboth statements are true and the transmission parameters (bandwidth, delay, etc.) cannot beguaranteed for experiments running in the testbed. These testbeds use to need the cooperationof several organizations in order to provide the distributed infrastructure.

Next sections analyze the most salient testbeds and tools considering locally and globallydistributed categories. Actually, both classes are the two extremes of the classification and sometestbeds could not be purely classified under any of them, e.g. a locally distributed testbed whichalso includes some remote nodes connected through Internet or the case of a globally distributedtestbed which does not connect individual nodes but locally-aggregated clusters. However, eachtestbed analyzed in this chapter is closer to one end than to the other, and so it can be classifiedunder the appropriate section.

2.3 Locally Distributed Experimentation Infrastructures

The following testbeds are analysed in this section: Emulab (Section 2.3.1), the ADRENA-LINE testbed (Section 2.3.2) and ModelNet (Section 2.3.3). In addition, given the specialrelevance that virtualization is gaining as testbed enabling technology, a set of virtualizationtools (VNUML, NetKit, MLN, vBET and Dynagen) are described in Section 2.3.4.

2.3.1 Emulab

Emulab [WLS+02] provides researchers with an environment to develop, debug and evaluatesystems in the fields of networking and distributed systems in general. It integrates the threemain experimentation domains (simulation, emulation and live-network) in the same facility.The utilisation of the testbed is extensively documented in the existing literature. Around1,500 users from 220 institutions throughout the world conduct more than 18,000 experimentsyearly [ESL07].

2.3.1.1 Architecture

The testbed architecture is shown in Figure 2.3. There is a cluster composed of commodity PCs(currently, more than 350), some of them with specific hardware profiles, e.g. sensors. Theycan be seen as bare nodes with volatile disk and memory. Their particular configuration, e.g.operating system, network connections, etc., is defined at scenario deployment time and changedfrom scenario to scenario. The PCs in the cluster are interconnected through a programmablepatch panel using Ethernet, each PC having 4 or 5 physical interfaces. The programmable patchpanel, composed of several interconnected switches, enables building arbitrary topologies inter-connecting the PCs based on VLAN. This provides isolation from a logical and a performancepoint of view, so different scenarios can be set up and run in Emulab without interfering eachother. PCs in the cluster can play different roles during an experiment:


• Scenario nodes. Different operating system options available, e.g. GNU/Linux, FreeBSD,Windows XP or custom.

• Transparent link node. A node that is transparently inserted between scenario nodes(using bridging) in order to provide network emulation (e.g. bandwidth, delay, loss-ratio,etc.) and/or traffic monitoring based on libpcap [lib10b].

• Simulation host. Based on the ns emulation facility (NSE [Fal99]), which allows realapplication traffic to interact with a simulation (composed of simulated nodes, links andtraffic generators/sinks).

• Virtual machines host. Provides virtual-based emulation that complements physical-basedone, enhancing scalability with the minimal impact in experiment results. A lightweightvirtualization technique (based on FreeBSD jails [KW01]) is used (Xen [BDF+03] is beingconsidered for GNU/Linux virtual machines).

Switch-based programmable patch panel

PC

Controlservers

PC PC

Control switch

Internet

EmulabUser

…

Emulab architecture (without RON/PlanetLabnodes)

EmulabDB

PC cluster

Figure 2.3: Emulab architecture

The configuration management function is implemented in a set of control servers (hostingthe web interface, the control engine and disk user accounts) interconnected to the clusterthrough a control switch. Each PC connects to the control switch using a dedicated physicalinterface apart of the ones used for the programmable patch panel.

2.3.1.2 Configuration Management

Emulab users interact with the testbed specifying scenarios and performing several managementoperations upon them, from creation to finish, thus conducting a complete experiment lifecycle.Several users can deploy scenarios at the same time as Emulab is a shareable testbed. Scenariospecifications include [AHS+06]:


• Set of nodes, either physical (i.e. a dedicated PC), virtual or simulated.

• Operating systems and software running on those nodes.

• Links interconnecting nodes, either point-to-point or multipoint (i.e. LAN). IP addressingcan be automatic or explicit.

• Traffic shaping attributes of those links, based on QoS constraints: bandwidth, latency,queue type and loss-ratio.

• Network routing information, either automatic (static or dynamic) or explicit.

• Runtime dynamics (i.e. scheduled events), among the following: traffic generation events(start, stop, etc.), link events (changes in bandwidth, delay, etc.) or programmed shellcommands.

The scenario lifecycle is as follows (Figure 2.4):

Parsing

EmulabDB

Self-ConfigurationAllocation

populates

resource mapping configuration

information

Swap-in

targetconfiguration

experimentdesign

Realization

Specification(ns)

Swap-out

experimentinteraction

Emulab experiment lifecycle

Figure 2.4: Emulab experimentation scenario lifecycle

1. Specification. User defines all the scenario parameters specified above. Scenarios aredescribed in ns language [ns10] with some Emulab-specific extensions. On the one hand,this allows an easy migration from scenarios written for ns network simulator to Emulab.In addition, the usual constructs in procedural languages (e.g. loops) can be used. Onthe other hand, ns syntax can be awkward for users not familiar with it and it lackssyntactical structure. Users can write specifications directly using text editors or througha GUI (named NetBuild).

2. Parsing. User uploads the scenario specification using the Emulab web interface, so it isparsed by the management engine. The resources required by the scenario (nodes, links,


etc.) and other scenario related data (i.e. sequence of ns-specified events to being executedduring the experiment) are stored in the Emulab central database in a deployment-agnosticway, i.e. not tied with specific physical elements.

3. Swap-in (i.e. deploy the scenario into the testbed infrastructure). Includes two substeps:

(a) Allocation. Abstract resources stored in database are assigned to concrete physicalentities, i.e. PC nodes. The main mapping algorithm is based on simulated annealingand tries to minimize the inter-switch bandwidth utilisation in order to make anefficient use of the cluster [RAL03]. There is also a variant of the algorithm formany-to-one mapping cases used for simulated and virtual nodes [HRS+04][GRL05]which considers other optimization metrics. Additionally, IP addresses are assignedduring allocation substep using the algorithm described in [DRBL06] (except whenexplicit assignment is set in the scenario specification).

(b) Self-configuration. Each physical PC involved in the scenario starts a scriptedself-configuration process that pulls the database for the needed information andperforms the required actions, e.g. load and boot a specific operating system image.Upon completion a link validation test is performed (named linktest) and, finally, thescenario is ready to use. The user is notified through an automatically generatedemail.

4. Experiment realization. If the scenario includes events (which are described in ns-stylein the specification), they are issued by the scheduler at the right moments. The timereference is the moment in which all nodes have reported to be ready. Additionally, usershave root-level access to their scenario nodes and can interact with the experiment directlyusing conventional shell commands or Emulab-specific tools installed in the experimentnodes and supporting server. These tools allow issuing new events (i.e. the event scheduleis dynamic) and barrier-based synchronized command execution (i.e. several nodes doingthe same action at the same time).

5. Swap-out (i.e. release the testbed infrastructure allocated to the scenario). Usually it isuser-driven, i.e. user chooses to tear down the scenario in the Emulab web-based interface.However, it can be also automatic, as Emulab prevents abuses periodically swapping-outidle scenarios in order to avoid wasting resources allocated but not actually used.

2.3.2 ADRENALINE

ADRENALINE testbed R© (All-optical Dynamic REliable Net-work hAndLINg IP/Ethernet Gi-gabit traffic with QoS) testbed [MPM+05][Wik10a] is a GMPLS-based Intelligent Optical Net-work developed at CTTC (Centre Tecnologic de Telecomunicacions de Catalunya).


The ADRENALINE testbed data communication network is shown in Figure 2.5. Apart from anall-optical and Ethernet connection-oriented transport planes and the circuit provisioning ma-nagement plane that lie out of the scope of this work, the testbed implements a GMPLS-baseddistributed control plane [Mai04]. The control plane is responsible for handling dynamically


and in real-time optical node’s resources in order to manage automatic provisioning and surviv-ability of lightpaths, i.e. end-to-end optical connections, allowing traffic engineering algorithmswith QoS. The control plane is based on RSVP-TE (Resource Reservation Protocol Traffic En-gineering [Ber03]) for lightpath establishment, and OSPF-TE (Open Shortest Path First TrafficEngineering [KR05]) for topology and optical resources dissemination.

Switch#4Test

…

Switch#6Switch#5

Switch#3

Switch#2

Switch#1

Switch#7

OCC1 (optical)

OCC2 (optical)

OCC3 (optical)

…Client devices

(broadband tester)

OCC4 (optical)

Switch#8 Switch#9

OCC0 (emul)

OCC1 (emul)

… …

Emulated OCCs (74)

Optical OCCs (4)

All-optical transport plane

Ethernet connection-oriented transport plane

…

Switch#10 Switch#11 Switch#12

… …

OCC73 (emul)

Configurationmanagement tools

(ADNETCONF)

Figure 2.5: ADRENALINE testbed data communication network

The control plane is composed of OCC (Optical Connection Controller) nodes, each onemade on a GNU/Linux-based router, and client devices provided through a broadband testerthat emulates an UNI (User Network Interface)-enabled IP router. There are currently 78 OCCsin total in two categories: optical OCCs (with actual optical hardware associated) and emulatedOCC (emulating optical hardware) although, from a control plane point of view, they are allequivalent. OCCs are interconnected through a backplane of VLAN-capable switches (currentlytwelve) which allows implementing any desired topology for the control plane, absolutely decou-pled of the physical infrastructure. It is also possible to set up QoS constraints in the controllinks (fixed and variable packet delays, packet losses, bandwidth limitations, etc.), thanks to anemulation package installed in the OCCs. These abilities make ADRENALINE a flexible test-bed which allows the deployment of experimentation scenarios implementing different networktopologies and configurations, e.g. rings, mesh, etc.

All OCCs run the same set of protocols and processes: RSVP-TE and OSPF-TE (both al-ready named above), Link Resource Manager (LRM) for management of node’s optical resources, a SNMP management daemon implementing a management agent, and eventually3, OLRM(Optical Link Resource Manager) for optical hardware control.


Until early 2006, only manual configuration procedures were possible in ADRENALINE. Thischanged with the development of ADNETCONF (ADrenaline NETwork CONFigurator [GMM06]

3OLRM only runs in optical OCCs, but not in emulated ones.


[GM07]), which is the software tool in charge of scenario management in the ADRENALINEtestbed. It is composed of two main modules, a graphic user interface, providing the scenarioeditor, in addition to the interface to launch operations, and a processing engine, implementingthe actual operations and interacting with ADRENALINE physical equipment. Scenarios arecreated just “drawing” the network topology, using a palette of items that includes the differentnetwork nodes allowed in the ADRENALINE testbed and configuring links (including its QoSconstrains) among them. The properties of each node (i.e. configuration of the different OCCprocesses enumerated in Section 2.3.2.1) are also specified.

ADNETCONF implements three different operations by clicking in a corresponding buttonon the GUI for each one: deploy (to set up the experimentation scenario in the testbed, allocatingphysical resources to it), undeploy (to unset the scenario, releasing physical resources assignedto it) and monitor (auxiliary operation that allows checking if the scenario is properly deployed).The scenario is then serialized to a set of XML files that correspond to the formal representationthat the processing engine will understand4. Up to six different XML files are produced; onedescribing the logical OCC topology (mandatory), the other five describing the configurationof the different processes (LRM, OSPF-TE, RSVP-TE, SNMP, OLRM), only needed when theparticular process has been included in the scenario.

The ADNETCONF engine interacts with ADRENALINE equipment using different inter-faces for each device: SSH (Secure Shell) for OCCs, Telnet for Ethernet switches in the inter-connection backbone and an RPC (Remote Procedure Call)-based vendor-specific proprietaryAPI for the broadband tester implementing client devices. The commands issued in the mostcomplete case (deploy) include:

• VLANs set up for OCCs, client devices and switches.

• Processes start-up (LRM, OSPF-TE, RSVP-TE, SNMP and OLRM). Two configurationsfiles are generated and installed for OSPF-TE in each OCC before starting the process,one configuration file for LRM.

• Configuration of client devices in the broadband tester for connection requests, trafficgeneration and traffic analysis in the configured network topology.

ADRENALINE supports shareability. In fact, in the time being, up to five 14-node scena-rios (the size of the reference network used for the most of the ADRENALINE experiments,NSFNet [NSF10]) can be deployed at the same time, apart from the 4 optical OCCs used forthe transport plane experimentation, maximizing testbed usage.

2.3.3 ModelNet

ModelNet [VYW+02] is a testbed devoted to large-scale network emulation, used to evaluatedistributed networked systems in realistic Internet-like environments. It enables the testing ofunmodified prototypes running over unmodified operating systems across various networkingscenarios.


ModelNet includes two kinds of nodes: edge nodes and core nodes. Edge nodes are intended forend systems emulation (packet generators and sinks) and execute unmodified network applica-tions on unmodified operating systems. Each edge node is connected to one core node through a

4XML is described as part of the state of the art in modeling technologies in this document (see Section 3.2.1).


physical interface. For the sake of scalability, each edge node multiplexes a set of virtual nodes(VN) using IP aliasing, although with some limitations (VN are not isolated one each other andmultihoming is not allowed).

Core nodes (interconnected conforming the so-called emulation core) are responsible of emu-lating the characteristics of the desired topology, in a link-by-link basic. Links are emulatedthrough pipes, each one with its own packet queue, queue discipline and additional parame-ters (bandwidth, latency and losses). The pipes in the topology are distributed among corenodes and the same core node can host several pipes. Finally, link emulation parameters can bedynamically changed, in order to resemble cross-traffic effects and dynamic network changes.

Packets are sent from VNs to the emulation core. The inbound core lookups the route forthe packet based on source and destination, getting an ordered list of pipes that the packet hasto go through (explicit routing is used). Then, a packet descriptor is created and scheduled onthe appropriate pipes. Physical bandwidth in the emulation core is optimized using payloadcaching, i.e. packets are moved between pipes by reference and actual packet data is only copiedwhen the packet leaves the emulation core towards the final destination VN.


Testbed configuration is based on XML-based files describing the experimentation scenario anda set of tools that process these files in several steps towards the actual deployment in the phys-ical infrastructure. Firstly, the user describes the desired topology (a graph) and the physicalmachines in which it would be implemented (core and edge nodes). The allocation file (whichspecifies VN-to-edge and link-to-core assignments) is generated using a simple greedy assignmentalgorithm. This file is used as input in order to perform the actual deployment.

2.3.4 Virtual-based Testbed Tools

Virtualization enables decoupling logical resources (computing, network, storage, etc.) from thephysical infrastructure supporting them. Applied to networking testbeds, machine virtualiza-tion enables to run experimentation scenarios composed of a set of virtual nodes interconnectedusing virtual networks, all of them inside a reduced set of physical hosts and, optionally, in-terconnected with other external nodes or networks. Compared to a physical-based testbed,this approach involves a dramatic reduction in the cost of deploying and managing experimen-tation scenarios, both in infrastructure (basically due to server consolidation) and operationalexpenditures (flexibility, quick provisioning, etc.).

There are several virtualization management tools, implementing management and moni-toring functions for virtualized infrastructure, including some advanced features, e.g. virtualmachine live migration between hosts, snapshots of running systems, etc., usually oriented to aparticular technology (e.g. VMware or Xen)5. Examples of such tools are VirtualCenter [Vir10],SmartDomains [Gre07], XenServer [Xen10] or Enomalism [Eno10].

However, there is a significant difference between virtualization used in conventional pro-duction environments and testbeds. In virtual networking testbeds not only virtual machineshave to be provided, but also virtual networks interconnecting them. Note that in the case ofproduction environments arbitrary topologies are not usually needed. Thus, the aforementionedtools are not well suited for scenario-based management as they are not focused in providing

5Only a few interoperable virtualization management approaches, such as libvirt [lib10a] or DMTF’s vir-tualization profiles [DMT07d], are now starting to emerge. DMTF profiles are described in this document inSection 3.4.4.


complex topologies and associated configurations, so using them to configure scenarios is a com-plex and time consuming task. Therefore, a different type of tools that provides a scenario-basedmanagement has been developed in the recent years [GFF+09], hiding low level virtualizationdetails and supporting complex user-defined topologies. This section is devoted to them.

The different tools analysed in this section share some common characteristics:

• First, the physical testbed infrastructure consists of just a single host. Therefore, thesetools are particular cases of locally distributed experimentation infrastructure in which anexternal network is not needed.

• Secondly, although virtual machines provide separate execution environments, they allcompete for the physical host resources, so isolation from a performance point of viewis not usually addressed. Therefore, these testbeds are more suitable for functional andqualitative tests than for experiments requiring quantitative accuracy.

• Finally, all of these tools are oriented to statically deploy the scenario, but not to theexecution of scheduled event sequences (except otherwise noted).

Note that virtualization technologies themselves (Xen [BDF+03], UML6 [Dik06], KVM[KKL+07], VMware ESX/ESXi [ESX10], VirtualBox [Wat08], QEMU [Bel05], Dynamips [Dyn10],etc.) are out of our scope. Finally, note that although globally distributed networking test-beds may use virtualization in order to achieve shareability of resources through slice-basedapproaches (such as PlanetLab, Section 2.4.1) in those cases the virtualization is an intrinsicpart of the testbed architecture and not a scenario enabling technology that can be flexiblyconfigured by tools as the ones described in this section.

Some of the tools that we have analyzed have not been included in the present description.For the sake of briefness we have focused on the most relevant ones, leaving out others due tothey are abandoned efforts (such as VNE [vdHV04] which has evolved to the NDL described inSection 2.5.3), to be similar to the ones already described but too focused on their GUIs (asNoSE [SGH+05], GINI [MMN+09] or Marionnet [LS08]) or to be based in closed and proprietarytechnology difficult to analyze (VMware VirtualLab [VLA06]).

2.3.4.1 VNUML

VNUML (Virtual Network User Mode Linux) [GFF+09] is a general purpose open source tooldesigned to help building virtual networking scenarios automatically. Basically, VNUML is afront-end to UML that enables an user to define, start and interact with virtual scenarios madeof GNU/Linux virtual machines interconnected through virtual networks. Virtual scenarioscreated with VNUML can be interconnected with external equipment and networks, openingthe possibility to create mixed virtual/real testbeds.

To use VNUML, first, the user writes the specification of the scenario using the XML-based VNUML language by means of a standard XML based editor or, alternatively, using theVNUMLGUI tool [VNU10]. Then, it invokes VNUML parser to process the specification andstart the virtual networking scenario (scenario building mode). Finally, the user interacts withthe scenario to achieve his or her goals. Interaction with virtual machines can be achievedaccessing them through their consoles or by executing programmed command sequences on

6Note that in Section 2.3.4 and all its subsections UML stands for User Mode Linux, and should not beconfused with Unified Modeling Language.


them with the help of the VNUML tool (execution mode). This can be seen as a limited formof event sequence execution procedure, but without implementing scheduling, i.e. the instant inwhich each command is executed cannot be specified. Eventually, user dismantles the scenario,releasing the host resources, running VNUML in scenario releasing mode.

A VNUML specification is made of two main sections: virtual networks and virtual ma-chines. The former describes the virtual networks that interconnect virtual machines, and thelatter the virtual machines themselves, including their configuration in terms of kernel, filesys-tem, interfaces, packet forwarding capability, static routes, command sequences and addressing.Virtual networks can be implemented through user space processes or virtual bridge devices inthe host operating system.

It is worth to mention that VNUML has been recently enhanced to manage multi-hostenvironments. This evolution is described more in detail in Section 2.4.4.4.

2.3.4.2 NetKit

NetKit [PR08] enables managing scenarios composed of virtual machines running on a singlephysical host and interconnected in arbitrary topologies. It is based on two layers of tools: ahigh-level set (ltools), which deals with scenarios as a whole; and a low-level set (vtools), whichinterfaces with the virtualization back-end (UML) to actually create, configure and destroyvirtual machines. Virtual networks are based on virtual bridges (implemented as user spaceprocesses) between the virtual machine network interfaces.

Each NetKit scenario is based on a directory (namely laboratory directory) in which eachsubdirectory represents a virtual machine. The contents of this subdirectory will be installedon the corresponding virtual machine at scenario deployment time. A common text-basedfile in the laboratory directory root describes the interconnections among virtual machines.Virtual machine configuration (including addressing, etc.) is performed in an opaque way asthe user specifies a configuration script per virtual machine that NetKit blindly runs at scenariodeployment time. Thus, NetKit does not provide actual virtual machine configuration featuresas VNUML does, they are delegated to the scripts located in the laboratory directory.

Other initiatives related with NetKit are NetLab [CdlHCC06] and NetML [Net10b]. NetLabis a graphical user interface for NetKit focused on education. It provides scenario monitoringand diagnosing. NetML improves the opaque configuration mechanism provided by NetKitfor dynamic routing processes, mainly RIP (Routing Information Protocol [Mal98]) and BGP(Border Gateway Protocol [RLH06]). It allows the definition of the network topology in an XML-based language which enables describing both AS peering and link layer connections, includingIP addressing aspects, then deriving specific configurations for dynamic routing process in thevirtual machines using XSLT transformations7. Moreover, NetML can also be applied outsidethe scope of NetKit and virtualization, because it can produce configurations for some vendor-specific syntaxes, in particular Cisco and Juniper.

2.3.4.3 MLN

MLN (Manage Large Networks) [Beg06] is a management tool designed to build and run virtualnetworking scenarios based on Xen and UML. Virtual networks are based on virtual bridges,either running as processes in user space (for UML) or implemented as special devices in kernelspace (for Xen).

7XSLT is described as part of the state of the art in transformation technologies in this document (Sec-tion 3.3.1.1)


Scenario specifications are based in a structured text-based language which is used to describethe topology, i.e. virtual machines and networks interconnecting them. The MLN languageis quite rich regarding the properties that can be configured in the scenario elements (e.g.quite detailed network interface configuration, user accounts, etc.) and supports some advancedfeatures (variable substitution, inheritance and file inclusion), in order to ease the maintenanceof large scenarios. However, the MLN language does not provide a complete abstraction fromthe virtualization back-end because of some properties of nodes and networks depend on thetechnology (UML or Xen).

MLN is extensible, so the language has not got a strict syntax (such Schemas for XML-based languages) and new elements can be added. Additionally, the MLN parser architectureenables to incorporate plugins to process those new extension elements in the language. Pluginsare developed using an API which consists of some functions (with a closed name) which areimplemented by the user and invoked automatically by the MLN parser in specific momentsto provide a particular function. The scenario specification can be accessed from the pluginfunctions using the same API.

The MLN parser implements scenario building and releasing operations. Once the scenariohas been defined in the MLN file, the build operation prepares the virtual machines to becreated by particularization of virtual machines templates pre-defined in the MLN software.Thus, MLN is quite strict regarding virtual machine filesystems support. Actual deployment isperformed after building. Next, after performing the desired experimentation tasks, the scenariois released using the corresponding operation. MLN does not allow event sequences, althoughthis functionality could be included using the plugin mechanism integrated with a scheduler.

2.3.4.4 vBET

vBET [JX03] enables building virtual scenarios based on an enhanced version of UML. In orderto do so, the user firstly describes the scenario using a text-based specification language whichhas a procedural nature, less intuitive and difficult to use than declarative approaches in thecase of large scenarios. It enables to define network devices, i.e. nodes which are implementedas virtual machines, and networks, which are implemented as user space processed.

A parser processes the specification and generates a script than, upon execution, leads tovirtual node creation, i.e. creating the virtual machines that map to nodes in the scenariospecification, and virtual topology creation, i.e. creating the virtual networks that interconnectthe nodes. Thus, vBET relies on external manual operations, i.e. the execution of the deploy-ment scripts. Finally, the scenario can be undeployed when the experiments are finished, alsomanually invoking scripts.

2.3.4.5 Dynagen

Dynagen [Anu10] allows the creation of scenarios composed of Cisco routers emulated usingDynamips technology. It is based on a simple text-based language which allows specifying thenumber and characteristics (e.g. ports) of the emulated routers along with their interconnectiontopology. Additionally, it includes a management interface to start and stop the routers.

The great advantage of Dynagen is the high realism achieved in the scenario (since actualIOS images are used), but it lacks the ability to specify other kind of nodes (e.g. end-systems,servers, etc.). However heterogeneous scenarios are possible, e.g. using VNUML virtual machinesconnected to Dynamips emulated routers by means of VNUML’s capability to interconnect withexternal entities.

2.4. GLOBALLY DISTRIBUTED EXPERIMENTATION INFRASTRUCTURES 43

2.4 Globally Distributed Experimentation Infrastructures

The following testbeds are described in this section: PlanetLab (Section 2.4.1), GX-Bone (Sec-tion 2.4.2), DRAGON (Section 2.4.3) and Future Internet testbeds (Section 2.4.4). The latterincludes a set of on-going experimentation infrastructures which have emerged recently withinpublicly funded programs for networking research in Europe and United States, in particular:GENI, FEDERICA, PII and PASITO.

2.4.1 PlanetLab

PlanetLab is an open global (i.e. world-wide) overlaid infrastructure built ontop the publicInternet, devoted to network services development, deployment and testing in near-to-real worldcondition at large scale [PACR03][BBC+04]. It is not aimed to any particular kind of serviceor network architecture, being successfully used in several fields (such as distributed storage,scalable location services or peer-to-peer architectures).


PlanetLab is composed of a set of nodes (currently more than 1,000 ones in more than 480 siteson 35 countries) directly connected to Internet (Figure 2.6 left). Sometimes, several nodes runsin the same geographical location or site. Note that no particular overlay topology is imposed(e.g. tunnels connecting sites), it is up to the services running on the testbed to configure suchtopology if they need it, e.g. using some of the approaches described in Section 2.4.1.3. Apartfrom nodes, there is also a PLC (PlanetLab Central) node which maintains a central databasestoring information about sites, nodes, users, etc. and management information. The PLCimplements the PLC management API (described in Section 2.4.1.2).

PrivilegedV

M

Internet

VMM VMM

VMM VMM

PLC

slivers slices

VMM

NM VMs

PrivilegedV

M

Unprivileged

VM

PlanetLabUser

XML-RPC

ProperProper

Unprivileged

VM

PlanetLab architecture

Figure 2.6: PlanetLab architecture

Although nodes are located on each participating site, nodes are managed remotely by thePlanetLab staff through the PLC. A shared cryptographic secret is generated at node installationtime which secures PLC-node communications. Local manual intervention is only requiredoccasionally, e.g. initial installation or hardware upgrades.


Nodes run a GNU/Linux-based operating system (PlanetLab OS). It implements a virtualmachine monitor (VMM) in charge of providing virtual machines (VM) based on VServer tech-nology [vse10]. A slice is defined as a distributed network-wide service container composed of aset of VMs that span several nodes. Each VM composing the slice is named sliver . As capacityfigure, [BBC+04] reports that a single PlanetLab node can cope with up to 1000 slivers.

PlanetLab OS enforces VM isolation, i.e. VM machines running in the same node shouldbehave as close as possible as if they were running in different physical devices. In particular,it provides isolation from a performance point of view, so each sliver has allocated a share ofthe total resources on the hosting node: CPU cycles, memory, storage and bandwidth. It alsoprovides namespace isolation: slivers cannot access directly to resources in other slivers, e.g.files or packets send/receieved. Intra-node VM communication has to use the network as theywere in different nodes. However, one main drawback of PlanetLab namespace isolation is thatVMs in the same node share the same public IP so different VMs cannot run services bound tothe same port at the same time.

There are three types of VMs (Figure 2.6, right):

• The Node Manager (NM). One per node, acting as a “root VM”. It monitors and managesall the other VMs in the node, e.g. VM creation and releasing, resource allocation, etc.The NM is only accessible by other VMs (privileged) in the same node, using a XML-RPC [Dav99] based API. It is worth noting that the NM only considers local (per-node)abstractions, high level (network-wide) ones are provided by infrastructure services, whichare described in Section 2.4.1.2.

• Privileged VM. They are either able to use the NM API and/or to break the names-pace isolation accessing to other VMs (using a mechanism named Proper [MPF+06]).Typically, these VMs conform the slices used by the PlanetLab infrastructure services inSection 2.4.1.2.

• Unprivileged VM. Typically used by slices implementing end-user services not needing anyspecial privilege.

This slice-based architecture provides distributed virtualization, thus achieving space share-ability, i.e. the nodes of the testbed are able to run several services concurrently.

Finally, note that the PlanetLab software is publicly available, so it is possible for anyindividual or organization to set up a “private PlanetLab” based on the same technology thatthe official one and implementing its own PLC entity. In fact, several such testbeds have emergedsuch as OneLab [One10] and EverLab [JBK07] (usually jointly referred as PlanetLab Europe) orPlanetLab Japan [Pla10]. In addition, the federation of such private PlanetLab-based testbeds(coordinating different PLC entities) is currently being discussed and worked out.


PlanetLab operation and proper working is based on a set of infrastructure services, usually run-ning in privileged slices. Users access these services to set up slices, allocate resources to them(bandwidth, etc.) and deploy other services and monitor them during their lifecycle. Infrastruc-ture services are not isolated entities, and some services are supported by others, existing loosebinding between them. Some operations (such as slice creation) are triggered through PLC,


using the so-called PLC API (XML-RPC based) or its web front-end8. Moreover, several infra-structure services that provide the same functionality could be simultaneously running. This isa convenient way of evolving the testbed functionality.

The different infrastructure service categories are analyzed as follows:

• Slice creation. The basic slice creation service is pl conf, running in a bootstrap slicein all nodes. The pl conf service can access to the NM interface, which provides virtualmachine creation in the PlanetLab OS. There are two slice creation methods (shown inFigure 2.7): direct and delegated. In the direct case, user requests the slice to PLC whichin sequence asks pl conf in a set of nodes to create the corresponding slivers associated tothe slice. In the delegated case, user asks for a ticket to PLC granting the right to createa slice, then the ticket is delivered to pl conf (or any other service able to access NM)for sliver creation. Eventually, the slivers associated to the slice are instantiated in thecorresponding node. The just created slice is a “bare” environment, providing just basicfunctionality but not any service.

VMM

NMpl_conf

PLC

XML-RPCXML-RPC

newVM

VMM

NMpl_conf/other

XML-RPCXML-RPC

newVM

ticket request

Direct Delegated

PlanetLab slice creation methods

PLC

Figure 2.7: PlanetLab slice creation methods

• Brokerage and resource discovery services. Brokerage services are used to acquire(i.e. allocate) resources and bound them to slices. Usually, they are coupled with slicecreation services (delegated based ones) to assign resources to just created slices, so cre-ation and resource allocation can be performed in the same operation. Some of them areSirius [Sir10], SHARP [FCC+03], Bellagio [ACSV04] or Tycoon [LHF04]. Discovery re-source services (such as SWORD [OAPV04]) are used by some brokerage services (such as

8PLC API is also the PlanetLab database interface, including some operations for database administrationnot direclty related with slice management, e.g. sites, individuals, etc.


Bellagio) to select the most appropriate nodes, i.e. the ones that best match the requiredresource allocation.

• Environment services. To create and maintain slice execution environments, mainlysoftware package deployment (download, installation, etc.) and maintenance (removal,upgrade, etc.). Some of them are: Stork [CH05], AppManager [Hue10] or Plush [ATSV06].

• Monitoring services. To monitor slices and the nodes where they run. The basicservice is CoStat, a low-level monitoring mechanism, in which other more advanced mo-nitoring services are based on, such as: CoMon [PP06], PsEPR [BKB+04], PSAD [Lar05]or MON [LKGN05]. Other monitoring services are PlanetSeer [ZZP+04] or S3 [YSB+06].

• Auditing services. Services running in slices are audited, which is important from asecurity point of view, so exploited PlanetLab services could not be used to attack theInternet. The main infrastructure service to do this is PlanetFlow [HBP06] which logsslice flows and helps to trace suspicious activity originated in PlanetLab nodes.

Given that PlanetLab can be accessed through Internet, PLC API utilization needs certificate-based authentication. Certificates are generated at user account creation time. Regarding sliceaccess, the SSH key of the owner user is installed in slivers at slice creation time, thus avoidingunauthorized users to access.

In addition to the infrastructure services described so far, there are also a set of tools thathelp users to interact with the testbed, some of them contributed by PlanetLab users themselves,such as PlMan (a tool to set up and control experiments deployed in PlanetLab slices through itslifecycle), PLDeploy (a script-based front-end of the PLC API to create slices), pShell (commandcenter), plDist (file distribution), Nixes (RPM packages distribution), pssh (parallelized SSHshell) and vxargs (parallelized commands).

2.4.1.3 Overlay Building Tools

Although PlanetLab is based on Internet (a layer-3 network) as interconnection mechanism,there are some approaches that have achieved layer-2 overlay networks ontop of PlanetLab.They have not been described in the previous subsection due to the fact that they are actuallyproof of concept approaches run by researchers in the PlanetLab rather than stable generally-available infrastructure services.

• VINI (Virtual Network Infrastructure) introduces the ability of building network topolo-gies and controlled network changes injection ontop of PlanetLab. There are two ver-sions of VINI, differing in the technology used to implement scenario topology nodes andlinks. The old VINI version is based on User Mode Linux and UDP-over-tunnels (PL-VINI [BFH+06]), while the current one (Trellis [BMM+08]) is based on the conventionalPlanetLab VServers, and Ethernet-over-GRE tunnels9. Changes in the topology can beinjected bringing down and up tunnels, which is seen by the nodes as an actual change inthe link, e.g. dynamic routes will be recalculated. The topology to be created is describedin a text file using Ruby syntax.

9Actually, PL-VINI runs on original PlanetLab, while Trellis runs on a private PlanetLab mainly supported bythe NLR (National Lambda Rail [NLR10]) and Internet2 [Int10] infrastructures as a Future Internet infrastructure(see Section 2.4.4).


• VIOLIN (Virtual Internetworking on OverLay INfrastructure) [Jia04] provides isolatedoverlays which include three types of entities: end systems, switches and routers. Endsystems and routers are basically the same, the only difference is that routers includeadditional features such as packet forwarding and dynamic route calculation. They areimplemented as virtual machines using an enhanced version of User Mode Linux (imple-menting inter-host links through an UDP tunnelling mechanism) in the hosting node inthe base overlay. Switches, implemented as virtual bridge user space daemons (namelyVIOLIN daemons), provide link-layer interconnection for end systems and routers.

Nodes (end systems, routers and switches) can be added, removed or migrated from onephysical host to another dynamically. Additionally, virtual links provided by switches canbe created and removed on demand. However, these reconfiguration operations have to bedone manually.

The original PlanetLab does not consider scenarios as experimentation units because, al-though the slivers (i.e. scenario nodes) configuration could be defined, slices have a topology-freesemantic, as they are interconnected using the public Internet. However, proofs of concept suchas VINI and VIOLIN (described in the previous section) enable layer-2 overlay configuration.Thus, arbitrary topologies can be defined within slices, implementing the scenario concept asdefined in Section 2.2.1.2.

Regarding these particular tools, although VIOLIN is based in manual operation, VINIprovides a primitive description language based in Ruby. This way, PlanetLab can reach somedegree of scenario-based management.

2.4.2 GX-Bone

The Global X-Bone (GX-Bone) [TWP+05] is a global Internet overlay testbed based on theX-Bone software tool [Tou01]. Testbeds nodes (connected to Internet) can participate in one orseveral overlays which are automatically configured and monitored by the testbed managementsystem.


There are two main architectural components: resource daemons (RD) and overlay managers(OM). RDs run on each node and are in charge of configuring and monitoring the node partic-ipation in overlays. OMs are in charge of receiving user overlay requests and configuring themon the nodes, selecting the proper ones and contacting their respective RDs to perform localconfiguration operations.

Each node willing to participate in GX-Bone overlays publishes its address in a global registrythat OM uses in order to select nodes to create new overlays. In order a node can participate inGX-Bone testbed no special operating system functionality is required apart from basic IP-on-IPtunneling. GX-Bone provides a standard networking interface (e.g. network interfaces, routingtables, etc.) so applications can run unmodified in testbed nodes. Each application can be asso-ciated with a different overlay. Nevertheless, different from other globally distributed testbeds(such as PlanetLab, described in Section 2.4.1), GX-Bone does not provide strict performanceor namespace isolation features. This implies that if an application does not support a parti-tioned view of network resources (e.g. a dynamic routing protocol listening only to the interfacescorresponding to the overlay it belongs but not to others) or it is not properly configured theisolation between overlays may be broken.


From a network point of view, GX-Bone overlays are based on tunnels between nodes on topInternet. This provides the testbed with the following features: concurrence (the same node canbe included in different isolated overlays), revisitation (the same node can participate severaltimes in the same overlay as different logical entities), recursion (an overlay can be build on topanother overlay).


Experimentation scenarios in GX-Bone consists of network overlays. The desired scenario isspecified in the so named X-Bone Overlay Language (XOL) [YTF05] which is basically an XMLsyntax to describe a topology of nodes linked by point-to-point links. Then, a deploymentoperation is issued to the OM using the scenario specification as parameter. Then, the OMselects the proper nodes and interacts which their RDs in order to properly configure the overlay,as described in Section 2.4.2.1. The allocation algorithm that OM employs in order to selectthe nodes to build the overlay is currently based on arbitrary selection. Once the overlay isdeployed experimentation can be performed on it as desired by the user. Subsequent actionson the scenario consists of monitoring (based on keep-alive pings, liveness and status requestsissued by OM to RD on overlay nodes) and undeployment.

The user issues the aforementioned operations using an interface towards OM (based onXML over TCP) either directly or through a web based front-end.

2.4.3 DRAGON

DRAGON (Dynamic Resource Allocation in GMPLS Optical Networks) [LSJ06] is an architec-tural framework which provides a control plane for the creation of switched paths (LSPs) inheterogeneous networks.


The DRAGON architecture is mainly based on GMPLS (although it also support no-GMPLSnetworks), complementing it with several additional functional elements. Details can be foundin [LSJ06]. Apart from the elements and interfaces so end systems can provision LSPs by themeans of conventional GMPLS procedures (i.e. RSVP-TE), DRAGON includes an Application-Specific Topology Builder (ASTB) node which accepts topology requests and interacts with theother architecture elements to create them.

It is worth mentioning that DRAGON is designed as a control plane for production networks.In fact, it has been originally used in Grid context to create the connections required in e-scienceapplications. It is not intended as a control plane for networking testbeds.


A topology is defined as an Application-Specific Topology (AST) by the end user as a set ofLSP’s which an application domain desires to be set up as a group. AST requests are issuedusing the ASTB API, which is based on SOAP [GHM+07].

AST specifications are defined in the AST Description Language (ASTDL), which is basedon XML. Each AST defines the nodes that take part in the topology and the links (i.e. LSPs)between them. Link properties can be specified as traffic engineering parameters, e.g. requiredbandwidth. Note that DRAGON is very focused on the network, so properties for nodes (apartfrom the IP address) are not included.


2.4.4 Future Internet Testbeds

Future Internet global research initiatives focused on the evolution of Internet actually involvethe creation of large and globally distributed multi-user experimentation facilities in which newarchitectures and protocols will be worked out and tested. These infrastructures assume bothincremental approaches, built on top current Internet technologies, and clean-slate approaches,in which, in order to avoid the technological legacy, the Internet protocols are redesigned fromscratch and backward compatibility is not maintained.

Currently, research initiatives in this area are being organized in United States and Europe,in particular the NSF-funded FIND (Future InterNet Design) and the EC-funded FIRE (FutureInternet Research and Experimentation)10 programs respectively. A detailed description of thedifferent Future Internet initiatives funded by both programs (and some similar ones in Japanand Korea) can be found at [Rob09].

Although these initiatives develop diverse testbed approaches, all them share the same char-acteristics:

• The global infrastructure consists in the federation of testbeds, each one potentially be-longing to a different organization and exposing a different set of resources to the globalinfrastructure.

• The different federated testbeds expose heterogeneous resources. For example, one testbedcan be specialized in wireless technology, while other is focused in optical networks .

• The network interconnecting the different federated testbeds is dedicated. This enablescomplete control of the link transmission characteristics and differs from pre-existing glob-ally distributed infrastructures (such as the PlanetLab), in which Internet (an uncontrollednetwork) is used for those interconnections.

• They are designed as multi-users facilities so they are based on slices of resources (nodesand network) along all the federated testbeds. Each slice is assigned to a given user runninga given experiment and isolated from other users’ slices. Virtualization is the usual enablerof infrastructure sharing and isolation.

It is worth noting that PlanetLab (described in Section 2.4.1) has inspired the principlesabove, specially the one regarding slice-ability. However, the differences are also clear, as Pla-netLab uses homogenous resources (actually, commodity PCs) and Internet is its interconnectionmechanism. In addition, PlanetLab control is centralized (all the sites governed by the samePLC) and not truly a federation of sites.

The most significant international initiates in this area (and the ones described in the fol-lowing subsections) are GENI, FEDERICA and PII. At a national scale (Spanish), PASITO hasbeen also considered. It is worth mentioning that Future Internet testbeds continue evolving, soprogress is expected in the near future. Actually, some cases have been left out of the analysisbecause although very promising, they have not produced yet significant results regarding con-figuration management. In particular, the OneLab2 testbed [One10], an evolution of previousEuropean efforts related with the PlanetLab Europe platform.

10FIRE is actually included within the wider EC Seventh Framework Program (FP7).


2.4.4.1 GENI

GENI (Global Environment for Network Innovations [GEN08c][EF09]) is a NSF funded initiativewhose ambitious objective is “to enable the research community to invent and demonstratea global communications network and related services that is qualitatively better than today’sInternet” [Fal07]. The GENI testbed was conceived in 2005 as the first of the Future Internetinfrastructures, for a 15-20 year lifetime, after a construction phase of 5-7.

GENI addresses a rich set of node and link technological components, including devices inthe wireless, mobile, sensor and optical networking fields. Individual components are grouped inaggregates, each one managed by an aggregate manager, which, in addition, can be federated inthe case they belong to different organizations. All the aggregates conforms together the so calledGENI substrate in which slices are created, governed by an overall control framework. GENIalso considers experiment support services, such as storage, measurement platforms, gatewaysto the Internet, etc. Four logical planes have been considered to logically interconnect resourcesin these entities: experiment, measurements, control and O&M (Operations and Management).Finally, GENI implements a global logical database (named clearinghouse) including registriesfor organization and individual using the testbed, available components and slices. Note thatthe clearinghouse concept is close to the PlanetLab PLC database described in Section 2.4.1.1.The GENI architecture is illustrated in Figure 2.8.

Experiment planeMeasurements plane

Control planeO&M plane

Manager

Aggregate A

Manager

Aggregate N

…Experiment

SupportService 1

Control Framework

GENI substrate

Clearinghouse Local experiment tools

Researcher

slice sliceable component

GENI Admin andoperations

End users

Figure 2.8: GENI architecture overview

Currently, the project is in the first prototyping phase, called GENI Spiral 1 [GEN08b],on 29 sites in United States interconnected with 40Gbps circuits using the NLR and Internet2backbones. The Spiral 1 control framework development is addressed by the GENI ControlFramework Working Group. Five competing control frameworks are being considered, each onemanaging a cluster consisting of one prototype clearinghouse plus some number of prototypeaggregates controlled by the framework [GEN08a]:


• Cluster A: TIED Control Framework, using DETER, an Emulab clone focused on net-working security research [BBJ+06].

• Cluster B: based on the PlanetLab control system (described in Section 2.4.1.2), focusedon Internet scale distributed experimentation.

• Cluster C: ProtoGENI, based on Emulab (described in Section 2.3.1), focused on networkcontrol and measurement.

• Cluster D: based on ORCA (Open Resource Control Architecture [CGI+07]), focused onsensor networks. Actually, the GENI utilization of ORCA is as resource control systembased on PlanetLab.

• Cluster E: based on ORBIT (Open Access Research Testbed for Next-Generation WirelessNetworks [OSSS05]), focused on wireless networks. ORBIT is based on a basic scenario life-cycle with events execution. Scenario specifications are written in Ruby language includingboth static (topological) and dynamic information (experiment conditions changing alongtime, specially the parameters related with the wireless links).

Therefore, given that the GENI strategy for control frameworks in its first prototypingphase is to leverage existing systems, the scenario-based management capabilities will be theones derived of those systems. In particular, as DETER, Emulab and ORBIT use scenario-basedmanagement, cluster A, C and E will also do so. On the contrary, PlanetLab does not implementscenario-based management (and ORCA is also based on PlanetLab), so cluster B and D willnot do so.

2.4.4.2 FEDERICA

FEDERICA (Federated E-Infrastructure Dedicated to European Researchers Innovating in Com-puting Network Architectures [FED10]) addresses the federated interconnection of different Eu-ropean NRENs (National Research and Education Network) for disruptive networking experi-mentation using GEANT2 [GEA10] 1Gbps Ethernet circuits as backbone.

The FEDERICA testbed implements a layered approach, composed of physical, link andnetwork layer substrates [FED09]. A FEDERICA slice is defined as a network overlay builton top the substrate. Thus, a slice contains a set of virtual nodes interconnected by virtualnetworks assigned to a given user. VMware ESXi [ESX10] is used as virtualization technology.Virtual nodes interconnection can be done using IPv4/IPv6 circuits, VLAN or MPLS. Thus,FEDERICA suits to networking experimentation at any networking layer.

Several tools have been considered to implement configuration management in FEDER-ICA [FED08], being PL-VINI and MANTICORE the most relevant ones to build network over-lays. PL-VINI has been already described in Section 2.4.1.3. Regarding MANTICORE [GHF+08],it is basically a framework to provide logical IP networks, based on a Web Services interfacesexposed to the users requesting those networks. However, the project has focused up to nowin resource partitioning to create slices and the configurability of the resource once the slice iscreated has not been yet addressed in the publicly available deliverables at the project web-site [FED10]. It is worth mentioning that the virtual nodes in a slice are provided unconfigured,so the user is responsible of providing such configuration. Therefore, FEDERICA at the presentmoment is not implementing scenario-based configuration.


2.4.4.3 PII

PII (Panlab2 [PII10]) addresses the development of a federation framework for pre-existing Eu-ropean testbeds. This federation is based on the coordination between Panlab Partners (whichowns testbed infrastructure and offer their resources to the federation) and Panlab Customers(which make use of federated resources). A central entity (named Panlab Office) maintainsthe Panlab Repository storing the resources that Partners offer and their utilization conditions,e.g. price, allowed operations, etc. By means of a search and orchestration engine namedTeagle [WMG+09], the Customer can allocate resources in the federated testbed conforming aVirtual Customer Testbed (VCT). Note that the VCT concept is equivalent to slice in otherFuture Internet testbeds.

In order to provide an uniform description of the resources in the Repository, a proprietarymodel is being used although standard alternatives, such as DENng [SSC+08]11, are being con-sidered to evolve this model. Regarding the mechanism used by Customers to request VCTusing Teagle, a GUI enables to define the required resources in the different federated testbeds,including the interconnections among different components (using VLANs) and specific con-figurations for each component. Teagle implements scenario-based configuration approach, asthe different configurations associated to VCT are actually implemented, but the specificationmodel is implicitly hidden by the GUI.

2.4.4.4 PASITO

The PASITO (Plataforma de Analisis de Servicios de Telecomunicaciones, TelecommunicationsService Analysis Platform in English [PAS10]) experimentation infrastructure aims at providinga distributed experimentation networking platform to test next generation telecommunicationservices. It has been created and coordinated by RedIRIS, the Spanish NREN, with the cooper-ation of several Spanish specialized research groups hosting the platform physical infrastructure,e.g. servers. Additionally, RedIRIS provides the interconnecting network backbone, part of theinfrastructure and the supporting services, based on middleware which eases the use of the plat-form, whereas the research groups provide the rest of the testbed infrastructure, composed ofservers and network equipment.

The PASITO architecture (shown in Figure 2.9) consists on a wide-area network, composedof different interconnected nodes deployed in several administrative domains. Each node isconnected to a layer-2 backbone network through a router or switch interface. Internally, eachnode involves several subnets (maybe implemented using VLANs) and one or more physicalservers connected to such subnets.

Regarding the virtualization capabilities, each node in PASITO provides one or more virtu-alization servers running virtualization solutions like Xen [BDF+03] or VMware ESX [ESX10].In this way, the servers can be easily shared among researchers without having to reinstall themfor each experiment. In order to make experiments, researchers have to create their own virtualmachines and deploy them to the servers.

Although the step of allocating virtual machines to experiments and interconnecting them(i.e. the building of slices) is done manually, once the slice is defined, scenario-based mana-gement tools can be used on it. In fact, EDIV (an evolution of the VNUML tool describedin Section 2.3.4.1 adapted to multi-host environments [GFFM08]) has been successfully used

11Actually, DENng is based on the TMF’s SID (described in this document in Section 3.4.7) and focused onsemantic-oriented modeling of context and policy for autonomic networking.

2.5. GENERIC APPROACHES 53

EHU

?

UMUUPM

UC3M

RedIRIS

CESGA, UVIGO

UAMUPV

UPC, I2CAT, CESCA

Networkingequipment

VirtualizationServers

(Xen, VMware ESX)PASITO NODE

PASITO Switch

(VLANs)

Figure 2.9: PASITO architecture

in PASITO [GFLM09]. An EDIV controller enables users to deploy and interact with virtualnetworking scenarios in slices involving several PASITO nodes.

2.5 Generic Approaches

Differently from the previous sections, in the present one we consider configuration managementtools and approaches that are not tied with any testbed kind in particular, aimed at generalapplicability in any experimentation platform. In particular, two scenario-based configurationmanagement tools are analyzed, Weevil (Section 2.5.1) and AnyBed (Section 2.5.2), along witha network description language, NDL (Section 2.5.3).

2.5.1 Weevil

Weevil [WRCW05] is a management tool designed to automate the deployment and execution ofexperiments in distributed testbeds. The tool is also able to generate and schedule service calls(e.g. HTTP transactions) to the experiment components accordingly to synthetically generatedworkloads, simulating the behavior of actors (e.g. the human user using the browser thatgenerate the HTTP transactions).

In order to define an experimentation scenario, the user has to specify the following infor-mation using GNU m4 macro files [Sei04], conforming to an abstract syntax defined in UMLin [WRCW05]:

• Workload. For each actor, user specifies behavior (as a set of files in C++ implementing it,based on a workload-generation library) and associated configuration. They are inputs forthe weevilgen tool to generate a workload specification consisting basically in an integratedset of events performed by the different actors.

• System Under Evaluation (SUE). The SUE models the nodes in the scenario as a set ofComponents. Each Component belongs to a given ComponentType, which can be used tomodel the different types of scenario nodes, e.g. routers, web servers, etc. User can define


an arbitrary set of properties for each Component. The user also defines start and stopscripts associated to each ComponentType, which are the actual processes issued by Weevilto start and stop the scenario at deployment and undeployment time respectively. It isworth mentioning that interconnection cannot be explicitly specified in the SUE model.

• Testbed representation. Basically, a testbed is modeled as a set of Hosts identified bytheir IP addresses, used by Weevil to access the hosts during the scenario managementoperations. Note that this simple model fits with any distributed testbed and providesWeevil its generality.

• Host mapping. Mapping each one of the Components in the scenario to the actual Hostin the testbed which will allocate it.

• Actor mapping. Mapping each actor in the workload definition to the Component to whichthe actor’s events have to be issued.

Once the user has defined his or her scenario, the weevil tool “compiles” the different infor-mation pieces to generate a master automatization script for the experiment, with three basicoperations: setup, execute and clean up. First, the setup command installs the user-definedproperties and scripts in the testbed hosts, then runs starting scripts to prepare the scenariofor execution. Next, the execution command starts the scheduler to issue the events defined inthe workload specification. When the experiment finishes, stop scripts are invoked to performtermination actions, e.g. collect experiment measures in a central repository. Finally, the cleanup command resets the testbed hosts to their predefined states, removing all artifacts generatedin the previous processes.

As it can be deduced, Weevil is actually more an automatization framework with a flexiblebut poor and device-oriented scenario model rather than a full fledged management tool basedon a rich networking scenario specification mechanism. Note that Weevil defines Componentproperties in an opaque way, just offering them to start and stop script as m4 macros, butwithout doing an actual processing. Thus, its main drawback is that the user needs to model theproperties and implement the scripts to configure them on scenario components. For example,if the user needs to configure the IP address for nodes, he or she has to define an IP propertyconfigured with the proper value in each Component and write the corresponding start scriptto set it up at scenario deployment time.

In addition, defining actor behavior in C++ is very low-level and introduces additionalcomplexity, compared to just selecting the workloads types an associated parameters, e.g. inter-arrival time distribution function along with the probabilistic parameters that characterized it.The use of m4 syntax can be also complex, compared to more readable alternatives such asXML.

2.5.2 AnyBed

AnyBed [SHK06] is a testbed-independent tool to configure experimentation scenarios. Giventhat AnyBed is testbed agnostic, the same scenario specification can be deployed in differentAnyBed-compliant experimentation infrastructures, achieving reusability. The tool is orientedto PC cluster based testbeds.

The tool is made of three components working in sequence in order to deploy a given scenario:dispatcher, configuration generator and configuration injector. The user has to provide twodifferent specification files (both based on XML). The first one is the physical network file,

2.5. GENERIC APPROACHES 55

consisting of a description of the physical testbed layout, i.e. physical nodes, managementIP, connection to ports in physical switches, etc. This file is testbed-dependent and does notvary among experiments, assuming that the physical structure of the testbed does not change.The other file is the actual scenario specification and describes the topology as a set of logicalnodes and interconnections, although it does not model other relevant information such asIP addressing, static routes or the configuration or arbitrary processes running on nodes. Inparticular, IP addresses are assigned as a part of the dispatcher algorithm described in the nextparagraph.

The dispatcher reads both files and performs the assignment, i.e. which physical node im-plements which logical node, using a simple iterative algorithm trying to optimize physical linkbandwidth. A new XML-based file is generated describing the assignment, including VLANIDs and IP addresses. Next, the configuration generator reads that file and generates specificconfigurations for each physical node and switch, maybe using vendor-specific syntaxes. Finally,the configuration injector installs the configurations in the testbed physical devices using thesuitable method for each one (e.g. remote shell, FTP, etc.). Both configuration generator andinjector are quite testbed-dependent, because of each testbed element uses its own configurationformats and management interfaces.

Scenario specifications in AnyBed are focused on describing network topologies exclusively.Dynamic aspects (i.e. event sequences) are not addressed. Finally, given that the physicalnetwork file does not include information regarding which nodes are being used by alreadydeployed experimentation scenarios, AnyBed is difficult to use to provide concurrent scenariossupport.

2.5.3 Network Description Language

NDL (Network Description Language) [vdHDG+08] is a vocabulary designed as a lightweightontology based on RDF(S)12 to provide a common semantic for applications, network and serviceregarding the topology of hybrid optical networks. The current version of NDL (v2.5) implementsa modular approach, based on five core schemas:

• Topology schema, describing devices, interfaces and interconnecting links between themon a single layer.

• Layer schema, describing specific network technologies and the relation between networklayers, based on the formal model described in ITU-T G.805 [ITU00a] and the label conceptdescribed in GMPLS [Mai04].

Different technology layer technologies have been defined in additional schemas (nine upto now): Ethernet, ATM, TDM, WDM, copper (UTP and STP connections), bundle (offibers), IP, VPN (for technologies such as MPLS and PPP) and wireless.

• Capability schema, describing device capabilities, e.g. ability to perform wavelength con-version.

• Domain schema, describing administrative domains, services within a domain, and how togive an abstracted view of the network in a domain.

• Physical schema, describing the physical aspects of network elements, the layout of deviceswith blades and chassis, and additional properties related with location.

12RDF(S) is described as part of the state of the art in modeling technologies in this document (Section 3.2.3).


NDL was originally designed as a network description language for optical network and theirapplications are in that scope. In particular, it has been user for on demand provisioning oflightpaths in SURFNet [SUR10] and GLIF [GLI10] networks, as alterative to a conventionalGMPLS control plane when this technology is not supported in all the optical domains of thenetwork. However, there is no practical experience on how to apply NDL to other environmentsout of optical networking and, in particular, how to use it to define generic scenarios to bedeployed in experimentation infrastructures.

Moreover, although some efforts have been done to generalize NDL to other technologies(e.g. wireless) introducing a multi-layered approach, the model is still highly tied to low levelnetworking layers. Note that eight of the nine technological schemas belong to link layer tech-nologies. Regarding the IP schema, it models addresses (IPv4 and IPv6) but the definition ofroutes is incomplete. The ability to represent configuration for arbitrary processes running onscenario nodes seems also beyond the scope of NDL, e.g. dynamic routing processes configura-tion based on OSPF [Moy98]. Additionally, it is not clear how to represent multi-point links(such a classical Ethernet networks) as NDL is addressed to circuit-switched networks. Finally,QoS constrains in links, such as delay or loss probability, cannot be specified.

Finally, it is worth mentioning that NDL is contributing to the OGF’s NML-WG (NetworkMarkup Language Working Group [OGF10]) which addresses the definition of a “standardizednetwork description ontology and schema”. NML-WG has agreed in defining their model inUML, allowing representations in RDF and XML.

2.6 Conclusions

After setting up the framework for our research with an introduction to testbeds and theirtaxonomy, this chapter has performed an analysis of the most salient testbed infrastructures,both locally and globally distributed, and the tools used to build them, paying special attentionto their configuration management aspects. Table 2.1 summarizes this analysis, highlighting themost relevant characteristics in each testbed or tool. The only case not included in this tableis NDL, because it is not actually a testbed or a tool used to configure testbeds but a networkdescription language.

In has been found that scenario-based management is very consolidated in locally distributedtestbeds. This approach has been used in physical-based infrastructures such as Emulab, ADRE-NALINE or ModelNet for years. Most recently, it is also being used by the virtualized testbedbuilding tools which have emerged as a sound alternative to build inexpensive testbeds, e.g.VNUML, NetKit, MLN, vBET or Dynagen. This trend makes sense due to the fact thatscenario-based management involves significant advantages compared to manual approaches, asdetailed in Section 2.2.1.3. Even for testbeds that originally were based on manual configura-tion management (as ADRENALINE), its natural evolution has been towards scenario-basedapproaches. Only in the rare case of very short lived proof of concept testbeds, in which theimplementation or adaptation of a scenario-based tool could be costly compared to the lifetimeof the testbed, manual approaches could make sense. Among the different scenario specificationlanguages analyzed, the one used by Emulab is probably the most complete from a semanticpoint of view, including aspects usually not found in others, such as routing specification, QoSconstraints and dynamic events. However, it can be complex for users not familiar with networksimulation, as the ns syntax in which Emulab is based comes from that field. It is also worthmentioning that many of the analysed approaches are based on XML languages.

On the other end, globally distributed testbeds are a hot topic and many of them are being

2.6. CONCLUSIONS 57

Testbed Configuration Concurrent Scenario Scenarioinfrastructure management scenario lifecycle specificationor tool typea supportb operationsc languaged

Locally DistributedEmulab Scenario-based, Yes, Basic, ns-based

automatic allocation dedicated resources event sequences(simulated annealing)

ADRENALINE Scenario-based, Yes, Basic, XML-basedexplicit allocation dedicated resources monitoring (DTD)

ModelNet Scenario-based, Yes (theoretically), Basic XML-basedautomatic allocation dedicated resources

(greedy)VNUML Scenario-based, Yes, Basic, XML-based

mono-host allocation virtualized (UML) sequences execution (DTD)NetKit Scenario-based, Yes, Basic Text-based

mono-host allocation virtualized (UML) (directorystructure)

MLN Scenario-based, Yes, Basic, Text-basedmono-host allocation virtualized (UML and Xen) others (plugins) (declarative)

vBET Scenario-based, Yes, Basic Text-basedmono-host allocation virtualized (UML) (procedural)

Dynagen Scenario-based, Yes, Basic Text-basedmono-host allocation virtualized (Dynamips) (declarative)

Globally DistributedPlanetLab Scenario-based, Yes, slice-based Basic, Ruby-based(with VINI) explicit allocation eventsGX-Bone Scenario-based, Yes, node Basic, XML-based

automatic allocation concurrence monitoring (DTD)(arbitrary selection)

DRAGON Scenario-based, Partial Topology ASTDL,(AST) automatic allocation (network focused) request XML-based

(path computation)GENI Scenario-based Yes, slice-based Depend on the cluster ns (cluster A, C) or(spiral 1) (clusters A, C, E), Ruby (cluster E)

not scenario-based based(clusters B, D)

FEDERICA Not scenario-based Yes, slice-based – –(currently)

PII Scenario-based, Yes, VCT-based Basic Hidden by GUIautomatic allocation(orchestrator logic)

PASITO Scenario-based, Yes, slice-based As in VNUML As in VNUMLautomatic allocation (XML-based DTD)

(EDIV plugins)Generic Approaches

Weevil Scenario-based, Depends on Basic, UML (abstract),explicit allocation the testbed event sequences GNU m4 (concrete)

AnyBed Scenario-based, Depends on Basic XML-basedautomatic allocation the testbed(simple iterative)

aTestbeds type can be either scenario based or not scenario based. In the former case, the distinction betweenautomatic and explicit allocation (see Section 2.2.1.2) is specified. For automatic allocation, the name of thealgorithm is given. The mono-host allocation case (for virtualization based testbeds) can be seen as a trivial caseof automatic allocation in which all the scenario is assigned to the same physical host (the only one existing) inthe testbed infrastructure.

bReferring to the ability of the testbed to support concurrent scenarios running at the same time withoutmutual interference (shareability).

cFor scenario-based testbeds, basic refers to the essential scenario oriented configuration management opera-tions that any scenario-based testbed has to implement, i.e. design, deploy and undeploy. Additional operations(e.g. event sequences execution, monitoring of running scenarios, etc.) are also specified if the testbed supportsthem.

dFor scenario-based testbeds, it refers to the language used to specify scenarios. In the case of XML-basedlanguages with a defined schema, DTD or XSD is specified.

Table 2.1: Flexible testbeds infrastructures and tools analysis summary


designed nowadays within the publicly funded Future Internet initiatives. We have analyzed thecurrent status of GENI, PII, FEDERICA and PASITO. These testbeds are highly inspired inthe PlanetLab design which relies on infrastructure services instead of scenario-based approach.As a consequence, the main management focus in this kind of testbeds is how to provide slicesto testbed users addressing user resource requirements and guaranteing at the same time sliceisolation and stability. However, how the user creates an experimentation scenario in his or herslice is not addressed by the testbed management system and is up to the user. Among thedifferent cases of highly distributed testbed, only GX-Bone can be considered truly scenario-based.

However, it has been proved that scenario-based management is feasible in Future Internettestbeds slices (see EDIV experiments in PASITO described in Section 2.4.4.4) and even someGENI clusters (the ones based on Emulab technologies or ORBIT) are addressing it. In thissense, scenario-based management, already consolidated in locally distributed infrastructures asmentioned above, has now a great opportunity in Future Internet infrastructure to become theintra-slice management paradigm, aligned with the extra-slice provisioning mechanisms in thetestbed.

Therefore it can be concluded that scenario-based is the state of the art for the configura-tion management of experimentation scenarios in networking testbeds, already consolidated inlocally distributed infrastructures and a possible and very probable trend in globally distributedinfrastructures. In this context, it is desirable to have a common scenario specification mecha-nism. This would allow to reuse the same scenarios in different testbeds, a common situationwith complex problems that require either the same experiment to be conducted in severalcomplementary testbeds or experiments to be shared among peer researchers working on thesame topic in their respective testbeds. Currently, if the same scenario requires to be used indifferent testbeds, the users would need to manually carry out time-consuming error-prone con-versions. Additionally, this limitation introduced barriers to the design of generic configurationtools addressed to any testbed, e.g. editors, consistency checkers, scenario repositories, etc.

However, it can be found as a conclusion of our analysis that current formats are completelycoupled to the particular testbeds in which they have been developed, e.g. a scenario writtenfor Emulab is not directly usable in ADRENALINE. Only a few initiatives have tried to providea generic solution to scenario-based management in testbeds. In particular, Weevil is a veryflexible and powerful experiment configuration framework for testbeds; but to achieve generalityit relies on a poor scenario model and put in the user the effort of actually defining and processingthe scenario specifications. Regarding AnyBed, its scenario model is also limited and it is notclear how its configuration injectors are actually integrated with the testbed. Neither Weevil orAnyBed specification mechanism takes extensibility into account and it is difficult to use themto define configurations for arbitrary processes running in the nodes. We have also analyzedNDL and, although its modular approach is quite interesting, it is very focused in the lowernetworking layers and not actually addressed to testbed utilization.

Note that a technology-independent scenario specification language is just part of the so-lution. It is also needed a mechanism to translate scenarios defined using that format to theone used by scenario-based management tools in existing testbeds. In other words, the commonspecification mechanism has to integrate with existing testbeds and tools without needing anymodification on them. Neither Weevil nor AnyBed address that requirement because althoughthey are very flexible regarding the kind of testbed they are able to manage (and, as a conse-quence, they have been classified as generic approaches in our analysis) they still being actuallyscenario-based management tools that directly interact with the testbed infrastructure.

2.6. CONCLUSIONS 59

Therefore, the problem of testbed-independent specification and its seamlessly integrationwith existing infrastructures has not been successfully solved up to now. Our proposed solutionis based on a model-driven approach and described as contribution to the state of the art inChapter 4. Previously, in order to choose the technological enablers to develop our solution, ananalysis of the different approaches to model and transform management information is providedin Chapter 3.

Chapter 3

Modeling and TransformingManagement Information

3.1 Introduction

This chapter provides a state of the art analysis of modeling technologies used to build andtransform models in the context of configuration management for networking testbeds. Basi-cally, a model is a representation or specification of some system (physical or logical, existing orplanned) and a modeling language is the mechanism used to express that model [Sei03]. In ourcase, the systems to be modeled are the experimentation scenarios, introduced in Section 2.2.1.2as topologies of nodes and associated configurations that are deployed in networking testbedsto perform some kind of experiment. Modeling is based on abstraction, which consists in sup-pressing structural or behavioral details that are not relevant in the domain of application ofthe model in order to get a simplified representation of the system.

Among all the possible modeling mechanisms (e.g. paper drawings for the scenario topo-logy or its description in natural language), our main focus are the ones based on well-definedlanguages. A well-defined language can be defined as “a language with a well-defined form(syntax) and meaning (semantics), which is suitable for automated interpretation by a com-puter” [KWB03]. A language can be well-defined providing its abstract syntax independent ofany coding or representation (in which case the actual representation format is left out to thetool implementing or processing the language) or a concrete syntax (usually in the form of aformal grammar) or a combination of both. A grammar can be defined as “a set of formationrules that describe which strings formed from the alphabet of a formal language are syntacticallyvalid within the language” [Wik10b]. Languages defined using a formal grammar are usuallynamed formal languages.

Modeling based on well-defined languages is as old as computer science itself and it wouldbe overwhelming to consider each particular technique ever defined. Therefore, we are focusingthe scope of the present analysis in Section 3.2 on the most relevant and extended languagefamilies existing today. To this end we consider the W3C’s eXtensible Markup Language (Sec-tion 3.2.1) and the OMG’s modeling standards (Section 3.2.2). We also briefly analyze ontologies(Section 3.2.3) and other alternatives that can be used for modeling (Section 3.2.4).

Considering that the solution to the problem of configuration management interoperability inexperimentation infrastructures is based on transforming a scenario expressed in a testbed inde-pendent model to a scenario expressed in a testbed specific model (as elaborated in Chapter 4),special attention is paid to model transformation in Section 3.3. In particular, XML-based trans-

61

62 CHAPTER 3. MODELING AND TRANSFORMING MANAGEMENT INFORMATION

formations (Section 3.3.1) and the OMG’s Model Driven Architecture framework (Section 3.3.2)are analyzed. Additionally, model transformations based on ontologies are briefly analyzed inSection 3.3.3.

The modeling language will provide the means to define experimentation scenarios modelsin a formal way, but the concepts to be used in those models in our domain of application(e.g. network, link, node, etc.) also need to be defined. Instead of building such conceptbase from scratch and considering that our context is configuration management in networkingtestbeds this chapter also analyzes the DMTF’s Common Information Model in Section 3.4.We have focused on CIM considering its advantages regarding other alternative approaches formanagement information specification, which are briefly discussed in Section 3.4.7.

3.2 Modeling Languages

3.2.1 W3C’s eXtensible Markup Language

The XML (eXtensible Markup Language [BPSM+08]) is a W3C standard based on a subset ofSGML (described in Section 3.2.4). Its main characteristics are simplicity, human-readabilityand flexility, which make it adaptable to many applications domains. In addition, XML ishighly supported by the industry and there are many available software tools to generate andprocess XML-based documents. Note that several scenario-based configuration managementtools analyzed in Chapter 2 are based on XML (as shown in Table 2.1), which can be seen as aproof of the wide utilization of this language for scenario modeling in testbeds.

3.2.1.1 XML Documents

XML documents are text-based (Unicode). They consist in a tree structure composed by ele-ments (Figure 3.1). An element is defined by:

<vnuml><vm name="uml1"><if id="1" net="net0"><ipv4>10.0.0.1</ipv4></if><if id="2" net="net1"><ipv4>10.0.1.1</ipv4></if></vm></vnuml>

vnuml

vm

if

ipv4ipv4 net net0

name uml1

id 2id 1 net net1

10.0.0.1 10.0.1.2

root element

if

Figure 3.1: XML document and associated tree (example)

3.2. MODELING LANGUAGES 63

• Start-tag, between brackets (e.g. <vm>). A list of attributes (consisting in key-valuepairs) can be defined in the starting tag to characterize the element.

• Content. Either a string of text (that can be empty) or a sequence of one or more elements.Therefore it is possible to include elements (children) within another element (parent) thusproviding the tree structure that characterizes any XML document. Each element hasexactly one parent, except the root element (the first one in the XML document), whichhas no parent.

The specification also allows mixed-content, composed of text strings mixed with chil-dren elements. This is usually the case in XML documents representing formatted text(sometime named narrative-oriented XML documents), e.g. XHTML. It is not so commonin XML documents for data processing and interchange (sometime named data-orientedXML documents). The latter uses to be the case for XML documents representing models.

• End-tag, which name must match with the one used for the start-tag plus a slash prefix(e.g. </vm>). Both starting and closing tag delimit the element.

Apart from elements, an XML document can include additional constructs (e.g. XML decla-ration, preprocessing instructions, comments, entities, etc.) which are not described here for thesake of briefness. A XML document conforming to all the syntactic rules defined in the XMLSpecification at [BPSM+08] is said well-formed.

XML allows tags and attributes to be associated with one (and no more than one) names-pace [BHLT06], identified by a given URI. This allows to split tags and attributes into disjointsets belonging to different non overlapping domains, each domain identified by the given names-pace. Namespaces represent application domains (usually referred as XML applications) andsometimes are standarized1. Namespace URIs are bound to arbitrary prefixes used in the XMLdocument (e.g. ns) meaning that tags or attribute using that prefix belong to that namespace(eg. <ns:tagname>). A given XML document can use tags and attributes in many differentnamespaces.

As shown in Figure 3.1, XML is very good to describe containment relationships (e.g. a treeof objects, where each child is contained by the parent) but not arbitrary associations (e.g. tomodel an association between one node in one tree branch to other node in another branch).Although XML has some mechanisms to represent such arbitrary relationships between elements(e.g. ID and IDREF attributes types in DTD or key and keyref elements in XML Schema) usedin some XML application domains (e.g. the XMI language described in Section 3.2.2.5) it usesto be complex to deal with them directly.

3.2.1.2 XML Schema Languages

As long as the well-formedness rules are fulfilled, the element names, multiplicity, structure andattributes are not constrained by the XML specification. However, there are several schemalanguages that can be used to add additional syntactic restrictions with different expressivenesslevels. Among the different exiting schema languages (RELAX NG [CM01], Schematron [ISO06],etc.), we have analyzed DTD and XML Schema due to they are the most extended ones.

• DTD (Document Type Definition, included as part of the XML specification [BPSM+08])is a formal syntax based in SGML to precisely define the structure of XML documents.

1In this case, the host part in the URI is used to mean the organization which owns the standard, e.g.www.w3.org for W3C.


It contains element declarations (<!ELEMENT>) to define element names, multiplicityand structure. It also contains attribute declarations (<!ATTLIST>) to specify allowedattributes in elements, either if the attribute is mandatory or optional, allowed values (e.g.free text, enumerations, etc.) and default value. In fact, DTD is more than a validationschema, since it can include entities (<!ENTITY>) which are substituted with actual textwhen refereed from the XML document.

Although it is a simple schema language, DTD has limited expressiveness and is quiteoriented to narrative-oriented XMLs, e.g. it does not allow to specify complex data typesor the precise multiplicity of elements in sequences. In addition, DTD does not supportnamespaces so it is quite inflexible when used to validate XML documents with namespaceprefixes.

• W3C’s XML Schema [TBMM04][BM04] defines a XML application2 to describe valid XMLdocuments (named instance documents). It allows to define complex type contents struc-tures and attributes, based on a set of simple data types (e.g. integer, string, etc.) which inaddition can have additional restrictions (e.g. maximum and minimum values for integers,regular expression patterns for strings, etc.). It is also possible to define precise elementoccurrence constraints. XML Schema enables the definition of new types from existingones through refinement or extension mechanisms.

XML Schema is more complex than DTD. However, XML Schema is more expressiveand can define constraints that cannot be defined with DTD. In addition XML Schemasupports namespaces and even several XML Schemas can be combined to validate instancedocuments that use different namespaces.

Schema languages (DTD, XML Schema or others) enable to define the set of valid XMLdocuments conforming with a given schema specification, i.e. matching all the rules defined inthe schema. This set of valid XML documents actually defines a XML-based sublanguage, morespecialized and restricted than plain XML, usually associated to a XML application associatedto a given namespace. This is useful to define models addressed to a particular domain. However,all schema languages have a declarative nature so imperative calculations are not considered.This makes very difficult (or even impossible) to express some constraints (e.g. to check thatthe sum of two attributes is equal to a third one).

3.2.2 OMG’s Modeling Standards

The OMG (Object Management Group) has defined an architecture (and a set of associatedlanguages) for the modeling of software systems, providing a generic framework for model in-tegration, management, extensibility and interoperability. The architecture is based on meta-models, which are models of modeling languages [Sei03] (i.e. a given modeling language canbe defined as a model expressed in another higher level modeling language). Our aim in thefollowing subsections is to provide an overview of OMG’s architecture and its key languages andstandards.

3.2.2.1 Modeling Layers

The OMG’s architecture [OMG09a][AK03] is composed by four layers (Figure 3.2). From bottomto top:

2XML Schema namespace is http://www.w3.org/2001/XMLSchema.


• System layer (M0). The bottom layer include the “real” system (logical or physical) beingmodeled with M1 models.

• Model layer (M1). This layer contains models, specified using some of the M2 modelinglanguages. For example, class models or instance models expressed in UML belong to M1.

• Metamodel layer (M2). This layer contains metamodels corresponding to the differentmodeling languages (either standardized by OMG or defined by other organizations andindividuals) specified using the M3 meta-metamodel (i.e. MOF). The most significantmetamodels in the context of our work are UML (Section 3.2.2.3), OCL (Section 3.2.2.4),QVT (Section 3.3.2.4) and ATL (Section 3.3.2.5).

• Meta-metamodel layer (M3). This layer contains one metamodeling language, named MetaObject Facility (MOF) (Section 3.2.2.2), used to specify the metamodels in M2 layer. MOFis a reflective language (i.e. MOF is expressed using MOF itself) so no additional upperlayer languages are required in the architecture.

MOF

UML …

ClassModel

InstanceModel

Physical or logical systems

representsrepresents

M3: Meta-metamodel

M2: Metamodel

M1: Model

M0: System

conformsTo

conformsTo

UMLProfileUML

ProfileUML

Profile

conformsTo

QVT

TransformationDefinition

conformsTo

represents

OCL

instanceOf

instanceOf

instanceOf

Figure 3.2: OMG’s Modeling Architecture

In this architecture, a model (defined at M layer) expressed in a given metamodel language(defined at M + 1 layer) is said to conform to that metamodel. Equivalently, every element inthe model is an instance of a (meta)element in the metamodel or, in other words, elements inthe metamodel characterize all the elements in the model. The only exception to that rule isthe model at the topmost layer (i.e. M = 3) which conforms to itself.

Next subsections detail the most relevant OMG’s standards in this architecture (MOF, UML,OCL and XMI). Along these specifications, OCL itself is usually used to define well-formednessrules (static semantic). The dynamic semantic (i.e. the meaning of the well formed constructs)is specified in natural language (English), although in a precise non-ambiguous way, for the sakeof understandability.


There are several releases of each one of the languages and some particular versions havebeen even promoted to ISO/IEC standards. Except explicitly noted, the last available releasesat the time of this writing are the ones analyzed in this document. However, note that OMG’sspecifications are large and complex documents (specially for the current 2.x family) but inthe context of our work we only need a subset of the modeling functionality provided by theselanguages. Therefore, we provide a high-level description of the different standards, focused onthe aspects relevant for experimentation scenario modeling. As an in-deep description is out ofscope of this document, please refer to the corresponding OMG’s specifications cited along thissection for more details.

3.2.2.2 Meta Object Facility

The MOF3 (Meta Object Facility, which most recent version is 2.0 [OMG06a]) is the root of theOMG modeling architecture, providing the minimal set of concepts which are needed to definemetamodels for modeling languages, including MOF itself.

Actually, two meta-metamodels are defined: Essential MOF or EMOF (shown in Figure 3.3),which provides the minimal set of elements required to model object-oriented systems, andComplete MOF or CMOF, which merges EMOF with other additional packages to provideextended capabilities. Comparing EMOF and CMOF, the former is simpler so it is easierto implement but it lacks expressiveness, while the latter is more expressive but harder toimplement. EMOF allows simple metamodels to be defined using simple concepts. However,complex metamodels (such as UML) require CMOF.

Related with MOF, the Eclipse Modeling Project (EMF) provides a Java implementation of acore subset of the MOF API for the Eclipse IDE. This implementation is based on a metamodel(named ECore [ECo10]) that, except for minor differences, actually corresponds to EMOF.The main differences (apart from naming) are that ECore refines the EStructuralFeature class(equivalent to Property in EMOF) into two more specific subclasses (for regular properties andfor properties that are references to classes) and does not include primitive types as part of themetamodel (Java types are assumed implicitly). A more detailed analysis of differences betweenMOF version 1.4 and the EMF meta-metamodel can be found in [GR03], which also defines asyntax translation between both domains (based on XMI and XSLT, described in Sections 3.2.2.5and 3.3.1.1 respectively) thus proving their semantic closeness. In summary, ECore can be usedas the root meta-metamodel to define a four layer architecture analogous to the one describedin Section 3.2.2.1. Therefore, ECore can be considered a “pragmatic” implementation of theEMOF standard.

3.2.2.3 Unified Modeling Language

The UML (Unified Modeling Language, which most recent version is 2.2 [OMG09b]) is the defacto standard for specifying, visualizing and documenting software system nowadays4. TheUML metamodel is specified in CMOF, each modeling concept in the UML metamodel beingan instance of some CMOF metaclass.

3In this document MOF acronym is use to refer to two different standards: the OMG’s Meta Object Facility andthe DMTF’s Managed Object Format. If the particular meaning is not derived from the context, the organizationname will be attached: OMG’s MOF or DMTF’s MOF.

4UML popularity has extended even to the modeling of non-software systems (e.g. automobiles) with theSysML profile, specifically adapted for that kind of systems [OMG08c].


TypeTypedElement

Class

isAbstract: Boolean

Operation

Property

isReadOnly: Booleandefault: StringisComposite: BooleanisDerived: BooleanisID: Boolean

Parameter

DataType

PrimitiveType

EnumerationLiteral

Element

NamedElement

name: StringComment

body: String 0..*annotatedElement

0..1

0..*ownedComment

0..1

Package

url: String0..*

0..* 0..1

0..1

nestingPackagenestedPackage

ownedType

Enumeration

0..1

0..* ownedLiteral{ordered}

0..1

0..10..*

ownedAttribute{ordered}

0..*ownedOperation

{ordered}

0..*superclass

ownedParameter{ordered}

0..*

0..1

Object

Figure 3.3: EMOF metamodel (simplified)

UML is structured in language units, which are collections of tightly-coupled modeling con-cepts according to a particular modeling paradigm (e.g. use cases, state machines, etc.). Fourcompliance levels have been defined (L0, L1, L2 and L3), each one extending the preceding one.UML tools must specify the compliance level they support to enable interoperability betweenmodels generated by different tools.

The complete UML language (L3) is very large and complex (the complete standard isdescribed in more than 1,000 pages)5. However, only a reduced set uses to be required forexperimentation scenario modeling, in particular the structural features mainly included in theClasses::Kernel package at L1 level. That package includes the basic elements needed in class,object and package diagrams. The following are the main constructs:

• Class. This metaclass (derived from Classifier) is used to model conceptual entities withstructure and behavior. It may own Properties and Operations. Property metaclass(derived from StructuralFeature) models properties or associations ends of the conceptualentities, while Operation metaclass (derived from BehavioralFeature) is used to representthe behavior associated to a given invocation signature (including parameters and returntype).

• Relationship. This metaclass is used to represent links between concepts. It has differ-ent subclasses, in order to represent more specific semantics: Generalization (to modelinheritance), Association (to express relations between Classifiers) and Dependency (toassert some degree of dependency between concepts). N-ary relationships are allowed,

5A quite comprehensive and clear introduction to the UML 2.x specification can be found in the Chapter 4in [Min07].


although not too much used. The AssociationClass metaclass (belonging to L3) combinesthe semantics of Association and Class.

• InstanceSpecification. This metaclass is used to model concrete entities or instances “par-ticipating” in the semantics of a given conceptual entity (i.e. Classifier), either a Class(in which case the instance is called object) or Association (in which case the instance iscalled link). The Slot metaclass is used to model the particular values for the structuralproperties of the instance (which correspond to the Properties of the associated Classifier).

It is worth mentioning that, while in UML 1.x instances were considered elements at theM0 level, UML2.x considers them within the M1 (at the same level than the concepts theyinstantiate), as shown in Figure 3.4. The relationship between the instance an the classifierit belongs to can be represented by the <<snapshot>> stereotyped dependency6.

Classifier

City :Madrid

representsrepresents

M2: UML Metamodel

M1: UML Model

M0: System

InstanceSpecification

instanceOf

<<snapshot>>

instanceOf

Class

(the actual cityof Madrid)

(the generalconcept of city)

Figure 3.4: Classes and instances as M1 elements in UML 2.x

• Packages. This metaclass is used to structure models. A package is a grouping unit towhich model elements (e.g. classes) can belong. Specific relationships can be applied toPackages (e.g. PackageMerge, PackageImport, etc.).

Regarding extensibility, new dialects of UML can be defined by using the AuxiliaryCon-structs::Profiles package (included in L2) to customize the language to particular platforms (e.g.specific programming paradigms or languages) and domains (e.g. finance, telecommunications,etc). Profiles can be considered as a lightweight extension mechanism because they do not al-low to remove constraints in the adapted metamodel (only specifying new ones) and will besupported by any UML compliant tool7.

A Profile (which metaclass is derived from Package) is basically a set of Stereotype elements.Each Stereotype (which metaclass is derived from Class) is associated to the metaclass in the

6Some authors (e.g. [Min07]) use <<instanceOf>> instead. However, this could be confused with the relation-ship between elements in a modeling layer and its metamodel elements, shown in Figure 3.2 and 3.4. In addition,OMG’s specifications (in particular [OMG09a]) tend to use <<snapshot>>.

7OMG documents (e.g. [OMG09b]) refers to profiles as a “second-class” extension mechanism given its limi-tations, being the creation of new M2 models in MOF the more powerful and “first-class” extension mechanism.


UML metamodel which is being extended. The stereotype can define Properties (named tagdefinitions) which extend the ones in the referred metaclass (the values of the tag definitions inthe M1 model stereotyped elements in the M1 models are named tagged values). Thus, Stereo-types can be seen as extensions of existing UML metaclasses while tag definitions can be seenas attributes of such new metaclasses. In addition, constraints can be attached to stereotypes(either in OCL or natural language) in terms of the UML metamodel. Finally, a stereotypecan also define new presentation options (e.g. a new icon to represent the extended class indiagrams). The use of stereotypes in M1 models is denoted with the <<stereotype name>>label. Note that the UML specification defines some standard stereotypes in pre-defined profiles(see Annex C in [OMG09b] for details).

A simplified subset of the UML metamodel including all the aforementioned concepts isshown in Figure 3.5.

Element

NamedElement

name: String

Relationship

Slot

PackageMerge

PackageImport

DirectedRelationship

Generalization

Dependency

Association

AssociationClass

Class

Classifier

isAbstract: boolean

PackageableElement

InstanceSpecification

Constraint

Package

StructuralFeature

Property

BehavioralFeature

Operation

Profile

Stereotype

Parameter

0..1

0..* attribute

general0..*

ownedOperation0..*

0..1

0..*0..*

definingFeature

1

ownedMember0..*

0..1

nestingPackage

0..10..*

1

ownedParameter

0..1

0..*

Image

ExtensionEnd

Extension0..10..* Classes::Kernel (L1)

metaclass

icon1

0..*

type

1

0..*

1

1

ownedEnd

Classes::Dependencies (L1)AuxiliaryConstructs::Profiles (L2)Classes::AssociationClasses (L3)

1

0..*

constrainedElement0..*

0..*

content: Stringlocation: Stringformat: String

Figure 3.5: UML metamodel (simplified)

3.2.2.4 Object Constraints Language

The OCL (Object Constrains Language, which most recent version is 2.0 [OMG06b]) is a formallanguage to specify constraints to be hold on MOF-based models. These constraints are basedon queries over the objects included in the model. OCL expression evaluation is consideredinstantaneous and cannot modify the state of the model (i.e. it does not have side effects). OCLis not a programming language.

OCL is defined using a M2 MOF-based metamodel which defines the language types andexpressions. OCL types include basic ones (e.g. integer, string, etc.), model elements and severalkinds of collections (e.g. sequences, bags, sets, etc.). OCL expressions (which use those types)


are defined using a concrete syntax in EBNF. There is an OCL subset aligned with EMOF(called Essential OCL).

A OCL expression is applicable to a given context (class, operation, etc. referred with thekeyword self ) among the following cases:

• Invariants (class context). They specify constraints that must be always true, for everyclass instance at every time.

• Pre and post conditions (operation context). They specify constraints that must be truebefore and after executing the operation (respectively). The parameters of the operationcan be used in the OCL expression.

• Body (operation context). They are used to define the result of the operation (as a query onthe model elements). The parameters of the operation can be used in the OCL expression.

• Initial and derived values (attribute and association ends context). They are used toprovide the initial or derived value of such attribute or association end.

• Definitions (all contexts). They define variables and functions (helpers) reusable by theOCL expressions within the context in which the variable or helper is defined.

OCL expressions used in constraints can be quite complex, including variable definitions(let), conditional statements (if/then/else), association navigation (requires the proper namingof association ends and navigability in the constrained model) and operations on collections(filters, iterators, etc.). See the OCL specification [OMG06b] for details.

3.2.2.5 XML Metadata Interchange

OMG’s standards described so far (MOF, UML, etc.) specify abstract syntaxes to which themodels specified using them have to conform. Although how this abstract syntax is mapped to aconcrete representation of the model uses to be hidden by the tool implementing these standards,a standard concrete syntax is needed at least for storing and interchanging models and metamod-els between tools implemented by different vendors. In order to do so, OMG has defined XMI(XML Metadata Interchange) as an encoding format based on XML (Section 3.2.1) for modelsdefined using MOF-based metamodels8. The most recent version of XMI is 2.1.1 [OMG07]. Itis worth noting that OMG’s standards are not the only ones using XMI, given that it is alsoused by EMF.

XMI specification describes how to create XMI documents (a subset of the XML documentsuniverse) containing instances. It also describes how to create XMI Schemas (a subset of allXML Schemas) to validate XMI documents9. Each instance encoded with XMI is representedwith an XML element which tag name matches the name of the class to which the instancebelongs. Namespaces are used to define to which model the instances belong. Instances canbe univocally identified locally or globally, using the id and uuid attributes respectively, bothdefined within the XMI namespace. In the XMI Schema, each class in mapped to a complextype declaration built using a set of predefined rules (described in [OMG07]) to represent theinstances in the XMI documents validated by that XMI Schema.

8XMI is defined as an XML application which namespace is http://www.omg.org/XMI or http://schema.omg.org/spec/XMI/2.1 (the former is used for XMI in general, the latter is specifically for the current version).

9In XMI 1.x, DTD were used instead of XML Schemas.


Depending the level in which instances and classes are considered, XMI is not only suitableto represent M1 instances of M1 class models, but also M1 models (as instances of M2 models)and M2 metamodels (as instances of M3) and even the MOF itself. Actually, there is a XMIrepresentation for EMOF and another for CMOF. OMG has standardized namespaces for theirmetamodels.

3.2.3 Ontologies

Ontologies are a modeling technique emerged in the Artificial Intelligence field whose maindifference compared with the other modeling approaches analyzed in this chapter is their focuson knowledge representation to deal with the semantics of the information in a formal way.Among the different definitions for ontology, one of the most commonly used is “an explicit andformal specification of a shared conceptualization” [SBF98].

There are several ontology paradigms: semantics networks, frame-based representation anddescription logic are the usual ones. However, all they use the same elements (some timeusing different terms): concepts (basic semantic unit), attributes (properties characterizing theconcepts), facets (properties of attributes), relationships (among concepts), instances (particularrealizations of concepts), axioms and constraints or restrictions.

Ontologies can be classified in two types:

• Lightweight ontologies. They formally describe a set of concepts, their properties andrelationships but do not include axioms or restrictions. Therefore, they are basically usedto define taxonomies.

• Heavy ontologies. Apart from the elements described before, they add axioms and restric-tions, in the form of logical rules. This enables the utilization of inference techniques inorder to check the validity of statements or to derive new information from existing facts.

Ontologies are encoded using an ontology language. Currently, in the last two decades abroad number of alternatives have arisen, being the most representative ones: LOOM [Mac91],Ontolingua [Gru93], FLogic [MRBV95], OKBC [CFF+98], OCML [Mot98], SHOE [HHL99],XOL [PDKT00], RDF(S) [KC04] [Bec04][BG04], OIL [FvHH+01], DAML+OIL [CvHH+01] andOWL [DSB+04]. Each one has different features, expressiveness level and support degree inexisting tools. A detailed analysis is out of scope of this documents, please see Chapter 4 in[GFLC04].

Is is worth mentioning that with the application of ontologies to the Semantic Web in late90s, the most recent ontology languages defined (RDF(S), OIL, DAML+OIL and OWL) useXML as encoding mechanism. Each one of the formers can be considered a sequential step inthe path to a definitive ontology language for the Semantic Web, that currently has resulted inOWL. SWRL [HPSB+04] complements it, addressing the OWL original limitation to expressproduction rules.

In is worth mentioning that a subset of UML (Section 3.2.2.3) has been proposed as ontologylanguage [KCH+]. Thus, ontologies would be defined as UML models using UML classes and in-stances. Actually, not all the features in these modeling constructs are required, e.g. operationsor visibility. The main advantages of this approach is that UML is quite extended and its graph-ical representation notation. However, although UML fits perfectly to define lightweight ontolo-gies, it does not allow including axioms or logical restrictions natively. OCL (Section 3.2.2.4)could help to introduce those axioms and logical restrictions in UML models.


3.2.4 Others

Apart from the languages analyzed so far, there are another alternatives for modeling that aredescribed briefly for completeness in the present section. Note that in general they are quite old(created from 60s to 80s) but still used nowadays.

• The SGML (Standard Generalized Markup Language [ISO86]). It is the tag-based lan-guage from which XML (Section 3.2.1) derives. Although it is more expressive than XML,it is significantly more complex and, in practise, the most of the features included in SGMLbut not in XML are for unlikely scenarios and not actually needed for modeling. Moreover,SGML is less restrictive than XML which is problematic from the point of view of well-formedness, e.g. SGML allows unclosed start-tags and overlapping tags. For a detailedcomparison of both languages see [Cla97].

• BNF/ABNF/EBNF. BNF [BBG+60] and its modern extensions (ABNF [CO05] or EBNF[ISO96]) are meta-grammars used to define languages grammars, e.g. programming lan-guages. Actually, the different concrete syntaxes analyzed in this chapter have a represen-tation in EBNF or ABNF, either directly (such as XML or the concrete syntaxis for QVTand OCL described in Sections 3.2.2.4 and 3.3.2.4 respectively) or indirectly (such XMIor OWL which are based on XML, which in sequence is defined in EBNF as mentionedabove). Therefore, (A/E)BNF could be considered as the foundational grammar definitionmechanism in which other modeling languages are based on instead of a modeling languageitself.

• Entity Relationships Model (ERM) [Che76]. ERM is the modeling language used to defineEntity Relationship Diagrams (ERD), which are models for relational databases (tablesand relationships between tables). However, complex relationships (such inheritance) arenot directly supported. Actually, ERMs can be seen as a subset of UML class diagramsas explained in [Ou98].

3.3 Model Transformation

3.3.1 Based on XML

The different approaches to XML document transformation (XSLT, XQuery and programmatictransformations based on DOM/SAX) are described in this section.

3.3.1.1 W3C’s eXtensible Stylesheets Language Transformations

The XSLT (eXtensible Stylesheets Language Transformations [Kay07]) is a W3C standard con-sisting in a XML application10 to define transformations from an input XML document into anoutput XML document.

The XSLT document is a XML document itself, containing a list of rules. A rule is composedby a pattern and a template. The pattern specifies which elements in the input XML triggersthe rule, in which case the template is used to generate the corresponding output for thatelement. XPath [BBC+07] is extensively used in XSLT, both in the pattern to specify theelement matching the rule and in the template to identify elements which value is used tobuild the output. A XSLT processor acts as transformation engine, reading the rules defined

10XSLT namespace is http://www.w3.org/1999/XSL/Transform.

3.3. MODEL TRANSFORMATION 73

in the XSLT document and checking them in the input XML document from beginning to end.Rules are triggered in the order in which they match elements in this traversal, generatingthe corresponding output XML. XSLT processors only require input to be a well-formes XMLdocument, schema validation is neither checked nor needed.

Although XSLT only enables to produce XML documents, it is also possible to use it in com-bination with XSL-FO to generate other document types. The eXtensible Stylesheet LanguageFormatting Objects (XSL-FO) [Ber06] is an XML application11 which allows to describe thedocument layout (e.g. positioning) as a series of nested boxes to be placed in one or more pages.Then, a rendering application can use the XSL-FO description to produce the final document(e.g. PDF). However, it implies a second transformation step after the XSLT one.

XSLT was designed to render narrative-oriented XML documents into visual representationformats (e.g. XHTML [Pem02]) in which a multi-input scenario does not make too much sense.Therefore, one of its limitations is that only allows one XML input document. In addition,transformations not oriented to formatting documents use to be complex to define, on the onehand, given the XSLT execution semantics based on navigating the input sequentially and, onthe other hand, due to the XPath matching mechanism used for patterns.

3.3.1.2 XQuery

XQuery [BCF+07] is a W3C standard defining a query language for extracting information thatmatches specific criteria from one or more XML documents. Compared with the XSLT languagedescribed in the previous section, XQuery is simpler although more limited.

Although actually designed as a query language conceptually similar to classical query lan-guages for relational databases (such as the Standard Query Language, SQL [ISO08]), it is alsopossible to embed XQuery expressions in XML templates to produce one output XML documentfrom a set of input XML documents (the ones to which the queries are addressed). An XQueryprocessor reads the template, resolving the queries to generate the final document. In this way,XQuery can be used as a transformation language for data-oriented input XML documents.

XQuery uses XPath in order to address specific parts of the XML document, along withFLOWR (For, Let, Order By, Where and Return) clauses to combine and restructure informa-tion (similar to relational SELECT-FROM-WHERE joins in SQL). FLOWR can use if/then/elsesentences to implement conditional results. XQuery can also use built-in and user-defined func-tions12 in XPath predicates or to process query results. XQuery is flexible enough to work withuntyped data, strongly typed data (the basic types defined in XML Schema are supported) orcombinations of both. Moreover, XQuery declarations can import XML Schemas and associatethem to namespaces, thus ensuring validation in the generated XML output.

3.3.1.3 XML Direct Processing

Another possibility to implement transformation is processing the XML document directly toproduce the desired output, in XML or other format. The three basic processing approaches arethe following ones:

• Event-based. In this case, the XML document is considered a sequence of events. A parserimplementing this approach reads the XML sequentially, triggering different events (e.g.start element, content, end element, etc.) and invoking handler functions (which implement

11XSL-FO namespace is http://www.w3.org/1999/XSL/Format.12The former are defined in [MMW07].


the actual processing logic) to deal with them. The main limitation of the event-basedapproach is that it forces to adapt the processing logic to a sequential processing, forbiddingarbitrary access to elements in the XML document tree, which involves more complexity.The main advantage of event-based approach is that is very resource efficient, even for verylarge XML documents. The most common implementation of the event-based processingapproach is the Simple API for XML (SAX) [SAX10].

• Tree-based. In this case, the parser reads the XML (maybe using an event-based parser)and builds a persistent data tree in memory to represent its contents (which likes verymuch to the one shown in Figure 3.1). The processing logic can then navigate this treeto access to the required information. It is also possible to modify the nodes and thenserialize the tree to a XML document again. The tree-based approach enables arbitraryaccess to the elements, so it is more flexible than event-based. However, for large XMLdocuments the building time of the tree and the runtime resources this dynamic struc-ture consumes (mainly memory) are drawbacks to take into account. The most commonimplementation of the tree-based processing approach is the Document Object Model(DOM) [WHA+00][HHW+00][HHW+04].

• Text-based. As described in Section 3.2.1.1, XML documents are text files, so they canalso be processed using general text based techniques (e.g. regular expressions). However,except for very basic casess (e.g. replace an attribute value for another), this is generallynot recommendable because using a text perspective is very difficult to deal with XMLfeatures such as namespaces, entities or attribute defaults.

3.3.2 OMG’s Model Driven Architecture

The Model-Driven Architecture [MDA03][KWB03] paradigm, also known as Model Driven En-gineering (MDE) and Model Driven Development (MDD), is based on considering models of thesystem as the main elements along all the steps of the software lifecycle (design, implementa-tion, deployment, test and maintenance). MDA describes certain kinds of models, how they arecreated and used and the relationships among them.

3.3.2.1 Model Types

The basic principle in MDA is the separation of concerns between software system specificationand its implementation on particular platforms. This leads to models in two levels of abstrac-tion13:

• Platform Independent Model (PIM). Provides a model of the software system structureand functionality, avoiding technical details of the specific platforms where the systemwould be deployed.

• Platform Specific Model (PSM). Provides a way to represent the system, combining thePIM elements with the specific details for the platform where the system is deployed (i.e.how the system makes use of the platform).

13Some MDA literature also cites a third one, the Computation Independent Model, focused on requirementscapture, but not actually describing the software system.


A platform is defined in [MDA03] as “a set of subsystems and technologies that provide acoherent set of functionality through interfaces and specified usage patterns, which any applica-tion supported by that platform can use without concern for the details of how the functionalityprovided by the platform is implemented”, e.g. J2EE [J2E10], .NET [NET10a], etc. MDA alsodefines a platform model representing the different kinds of parts that make up a platform andthe services provided by that platform from a technical perspective.

The separation between PIM and PSM is a way to cope with technological evolution. Newplatforms can arise or existing ones can get obsolete, so new PSMs arise and old ones are thrownaway. However, the PIM remains the same along all the time.

3.3.2.2 Model Transformations

A key concept in MDA is model-to-model (i.e. Model2Model) transformation, defined as theprocess in which an input (or source) model is automatically converted to an output (or tar-get) model of the same system according to a specific transformation definition executed by atransformation tool . A transformation definition is composed by a set of transformation rulesor by a set of sub-transformation definitions to be applied in sequence. A transformation ruleis a (possible parameterized) specification of how one or more elements in the input model haveto be transformed or mapped to one or more elements in the output model.

There are several types of Model2Model (M2M) transformation:

• PIM-to-PSM. This is the most significant case, being the PSM the result (output) ofapplying a platform-specific transformation definition to the elements in the PIM (input).

There are different cases of PIM-to-PSM transformation:

– Multiple inputs, one output. This is the case of using a merge between the PIM anan addition model (e.g. a platform model) to produce the PSM. It is also the casein which several PIM models, each one focusing on a particular concern within thesystem, are combined to generate a PSM model closer to the implementation.

– One input, multiple outputs. It is the case when the system modeled by PIM iscomposed of several parts (e.g. a front-end and a back-end) each one to be deployedin a different platform (e.g. front-end in J2EE and back-end in .NET). In order tosolve the interoperability problem, e.g. how the front-end interacts with the back-end, the transformation step can also generate the software bridges between PSMs,e.g. the communication layer used for message passing between front-end and back-end. In fact, this case can be considered as a multi-output transformation or a set ofrelated single-output transformations (as many as output models).

– Multiple inputs, multiple outputs. A combination of both cases above.

• PSM-to-PSM. A PIM-to-PSM transformation definition can be expressed as a sequence ofintermediate transformations definitions, specially in the case of complex transformationvery difficult (or impossible) to express as just a set of transformation rules to apply in asingle step. This can be seen as a chain of model transformations PIM-to-PSM1-to-PSM2-to. . . -PSM in which each sub-PSM in the chain is closer to the final deployment platformthan the previous, e.g. PSM1 is a coarse model and PSM2 a fine-grained model closer tothe code implementations (Figure 3.6). This illustrates how platform independency canbe considered a gradual property, e.g. PSM1 is “more” platform independent than PSM2.


TPIM

T1 T2 T3

T = {T1, T2, T3}

PIM PSM1

PSM

PSMPSM2

Figure 3.6: Example of chained transformation

• PSM-to-PIM. It consists in reversing the PIM-to-PSM transformation to be able of gen-erating the PIM (output) from PSM (input). However, this is usually very difficult (orimpossible) to achieve, because PIM-to-PSM does not use to be reversible due to informa-tion gets usually lost in this transformation (e.g. the PIM includes both structural anddynamical features, but the PSM only includes the structural ones so dynamic featurescannot be regenerated from it), so only partial regenerations of PIM would be possible(e.g. the structural part).

Transformations are provided by automatic tools and the transformation definition can bebased on hardwired algorithms (i.e. the transformation definition is coded in the tool itself) orin a formal language. The former is a very inflexible possibility that we will leave out of ourscope. Using a transformation language is better, given that it decouples the transformationdefinition from the general engine that applies it to models. Standard alternatives are preferred,because they enable portability between standard-compliant tools, avoiding tool vendor lock-in.

Although any modeling technology could be used in theory to play the PIM and PSM roles,in practise the MDA is combined with the OMG’s architecture described in Section 3.2.2. Inparticular, PIM and PSM use to be defined as M1 models and the transformation rules aredescribed in terms of their respective M2 metamodels (Figure 3.7), i.e. transformations are alsoM1 models themselves. Many transformation mappings are based in UML, e.g. from UML toa specific UML Profile suited to a particular platform such as J2EE. UML combined with OCLis very suitable to build PIMs, specially when structural aspects are important. Given that inUML 2.x both classes and instances of those classes are defined at the M1 layer (see Figure 3.4),it is possible to transform both entities using the same approach. Regarding the transformationdefinition language, OMG has defined the Queries/Views/Transformations language (detailed inSection 3.3.2.4), although other alternatives are possible (specially, the ATL language, describedin Section 3.3.2.5).

3.3.2.3 Other Transformations

Apart from Model2Model transformation, there are other kinds of transformation relevant forMDA14:

14Actually, although Model2Text and Text2Model transformations could be also be considered within theModel2Model type, it could be argued if text is a kind of model or a concrete syntax to represent models, so weprefer describe them separately.


Transformationtool

System

represents(higher abstraction)

represents(lower abstraction)

PIM PSM

conformsTo conformsTo

executedBy

Transformationdefinition

metamodel

conformsTo

Transformationdefinition

PIMmetamodel

PSMmetamodel

basedOnbasedOn

M2

M1

M0

input output

Figure 3.7: MDA transformation (one input and one output)

• Model2Text (M2T). Typically, PSM-to-code transformations are used to generate pro-gram code. Given that PSM fits the platform technology, these transformation use to bequite straightforward and many tools have partially supported them a decade before theformalization of the MDA paradigm, e.g. setter and getter methods autogenerated code.

• Text2Model (T2M). Not so common, this kind of transformation can eventually be usedto create a model in a modeling tool from text-based format (e.g. generate PSM fromcode or PIM from text-based specifications).

3.3.2.4 The Queries/Views/Transformations Language

The QVT language (Queries/Views/Transformations, which most recent version is 1.0 [OMG08a][Kur08]) is the OMG standard to specify queries (expressions that are evaluated over a model toproduce a given result), views (models which are completely derived from another base modelto which a direct connection exists) and transformations (already defined in Section 3.3.2)15.The transformation functionality is the most relevant one in the context of our work.

QVT is an hybrid language (with declarative and imperative elements) defined as a M2MOF-based metamodel. It is composed by three sub-languages (Figure 3.8), whose abstractsyntax is provided, to transform instances of MOF based metamodels (i.e. M1 models). QVTalso defines a concrete syntax for each sublanguage in EBNF, which heavily relies on OCL tonavigate and query on models.

• Relations language (QVTr). A high-level declarative language to express relations betweenmodel elements, based on complex object patterns to match instances in input models tocreate, delete or modify instances in the output models. These relations can includean arbitrary number of models belonging each one to different metamodels. Directionis not specified as part of the transformation, the actual tool engine interpreting the

15Actually, QVT does not hour the “V” in its name, due to the current specification does not include the viewsfunctionality.


OperationalMappings(QVTo)

Black Box

Core (QVTo)

Relations-to-CoreTransformation

Relations (QVTr)

Declarative ImperativeImperative

extends

extends

extends

extends

Figure 3.8: MDA transformation (QVT sub-languages and their relationships)

transformation definition will choose which one to take. A graphical notation has beendefined to express relations in QVTr.

• Core language (QVTc). A minimal low-level declarative language (defined in EMOF andOCL) to express relations between model elements in metamodels using simple objectpattern matching. It is equally expressive than QVTr, but the equivalent functionalityis achieved with much more verbosity. Although QVTc is useful as semantic referencepoint for QVTr (QVT specification includes a Relations-to-Core mapping) and tools mayimplement QVTc internally instead of QVTr, the syntax of QVTr is usually preferred towrite transformation definitions because it is high level and user friendly.

• Operational Mappings language (QVTo). It implements an imperative transformationslanguage that extends QVTr and QVTc using imperative constructs to instantiate objectspatterns. It is based on an OCL extension with side effects (named Imperative OCL),allowing a more procedural style (note that conventional OCL, as defined in Section 3.2.2.4,does not have side effects). Therefore, it includes constructs usually found in imperativelanguages (e.g. loops, execution control, exceptions, etc.). Transformations defined usingQVTo have an entry point which invokes in sequence another mappings (so the order ofexecution can be imperatively defined).

Imperative transformations are useful when a transformation is difficult (or impossible) todefine using just declarative languages. Apart from the Operational Mapping language,imperative transformations can also be defined as black-box operations which extendsRelations and Core in the same way. This is useful when Imperative OCL is not expressiveenough, e.g. to express complex algorithms already implemented in external libraries, orto hide details of the transformation.

QVT enables defining helpers as auxiliary functions to factorize navigation operations onmodels. It also allows to package transformation definitions (i.e to build libraries) and to definenew transformation definitions extending others. All these characteristics enable modularityand reutilization.

QVT is specialized in the Model2Model transformations, so OMG has defined a complemen-tary standard for the Model2Text case, named MOF2Text (which current version is 1.0 [OMG08b])to transform a model into a linearized text representation based on a template-based approach.


3.3.2.5 The ATLAS Transformation Language

The ATLAS Transformation Language (ATL) [JAB+06][ATL06] was one of the submissions tothe OMG’s Request for Proposals (RFP) for QVT. As with QVT, ATL uses an hybrid approach,combining both a declarative and imperative nature. The specification consists on a metamodel(which can be defined either in EMOF or ECore, see Section 3.2.2.2) and a textual concretesyntax which considers three different language unit types (each unit is encoded in a separate.atl file):

• Modules, to define Model2Model transformations. ATL allows multiple inputs and multi-ple outputs models in transformations. Each module is composed by a set of transformationrules and (optionally) helper functions (which are analogous to QVT helpers). There aretwo execution modes for modules:

– Normal execution mode (default). The creation of every element in the target modelis produced by some rule.

– Refinement mode. The rules produce target elements by modification of source ele-ments but the elements not modified are also included in the target model throughdirect copy. This mode is designed to save programming work when source and targetmodel are quite similar (in fact, they have to conform to the same metamodel).

Rules can be either matches rules (for declarative programming) or called rules (for imper-ative programming) corresponding to the two approaches that the ATL language supports.Matched rules specify which kind of source element (type and filtering condition specifiedby an ATL expression) triggers the generation of target elements and the way in whichsuch target elements must be initialized. Called rules (that can be called from matchedrules or another called rules) can be seen as a special type of helper able to generate targetelements.

• Queries, to compute primitive values (e.g. integers, strings, etc.) based on a set of sourcemodel elements. When the output primitive type is a string, it can be used to implementModel2Text transformations.

• Libraries. They package sets of helpers that can be reused from modules, queries or otherlibraries. Differently from modules and queries, libraries cannot be executed independently.

The ATL expressions used in rules and helpers are based on the OCL language (Sec-tion 3.2.2.4) both in data types and declarative expressions. However, both languages arenot fully equivalent, as some OCL operations are not implemented in ATL and ATL introducessome additional types and operations to the ones originally existing in OCL. In addition, ATLdefines imperative constructs for called rules. See [ATL06] for a detailed description of the ATLlanguage.

Although ATL is not fully equivalent to the QVT final version adopted by OMG and des-cribed in [OMG08a], it gets very close. In fact, the same design requirements were taken intoaccount. In addition, ATL also uses OCL for model navigation. Therefore, it can be stated thatATL is a QVT-like language. Moreover, there are some works on the comparison and alignmentof both languages [JK06].


3.3.2.6 Implementations Maturity

Regarding QVT and MOF2Text implementations, [Kur08] provides an analysis whose generalconclusion is that the maturity level of the existing QVT tools is not too high. This canbe explained due to the fact that the standard is very recent (published in April 2008) butcomplex at the same time. Most tools currently existing does not support all the features of thelanguage. They use to be beta versions and in some cases they have not been updated in thelast year. Therefore, their maintenance and stability level can be an obstacle to QVT adoptionfor professional use.

Regarding ATL implementations, the Eclipse M2M initiative has developed a plugin forEclipse IDE which has become the reference [Ecl10]. It includes an editor (providing advancesfeatures such as code highlighting, error reporting, debugging, etc.) and the ATL transformationengine, which is the component that actually performs the model transformations. In fact, acomparative analysis between QVTr and ATL implementations shows that the latter one is moremature and stable in general than the main implementations for QVTr, ModelMorf and MediniQVT. In particular, regarding ModelMorf [Mod10b], it has only released four versions in thelast 5 years (first versions dated in April 2006, last version in April 2009) and it has also otherdrawbacks such as limited OCL expressivity and complex command line operation. RegardingMedini QVT [med10], eight versions have been released, but the latest one at the time beingin quite old (October 2008). On the contrary, ATL development is quite active since 2005 andits last version at the time being (January 2010) was released in December 2009. Another factssupporting ATL maturity are its wide developers and users community and the extensive set ofdocumented transformations available16.

3.3.3 Ontology mapping

Several approaches have been proposed to translate concepts from one ontology to another, asthe mapping ontology [PGM98], the semantic translation ontology [ECI01] or the bridging on-tology [MMSV02]. They are actually meta-ontologies, because the instances of those ontologiesare in fact constructs of the mapped ontologies. However, they use to be limited providingmapping only on a reduced set of constructs (e.g. classes or properties), or too complex and notspecially focused on the field of network management.

Based on those, some authors have proposed a more simplified mapping ontology to specifi-cally map management information between a common management ontology, defined throughmerging and aligning several management domains, and specific management ontologies in thecontext of interoperability of management information models [LVAB03]. As shown in Fig-ure 3.9, each translation is specified using a Formula instance (the particular language has tobe specified), which is associated with the source and target Element instances to be mapped.

Other more recent approaches are based on using SWRL to specify translation rules betweenconcepts belonging to different ontologies. For example, [GVL+06] uses SWRL rules to translatebetween high-level and low-level policy ontologies defined in OWL in the context of policy-basednetwork management.

16More than a hundred sample documented transformations are available at http://www.eclipse.org/m2m/

atl/atlTransformations/.

3.4. DMTF’S COMMON INFORMATION MODEL 81

Formula

language: Stringexpression: String

Element

type: Stringreference: String

target elements

1..*

source elements

1..*

mapped elements1..*

1..*

inverse formula

Figure 3.9: Simple mapping ontology (from [LVAB03])

3.4 DMTF’s Common Information Model

The DMTF (Distributed Management Task Force) has standardized the WBEM (Web BasedEnterprise Management) architecture to unify the management of distributed computing en-vironments. As any other integrated management system, it is composed by a managementcommunication protocol (actually several ones), a language to define management information(the CIM, Common Information Model) and a set of management information models specifiedusing that language (the CIM Schema). DMTF’s standards aim at technology neutrality andthe integration of preexisting management systems.

3.4.1 Web Based Enterprise Management

Although the focus of this section is CIM and the CIM Schema specified using it, this subsectionprovides a brief description of the WBEM management architecture in which CIM is used.WBEM defines several communications protocols between the management client (CIM client)and the WBEM server, composed by a CIMOM (CIM Object Manager) and a set of providersmodules, all sharing the same generic operations set [DMT08b]:

• XML over HTTP [DMT09e] using the CIM-XML mapping based on DTD describedin [DMT09c]. This was the communication protocol originally defined by DMTF.

• WS-Management [DMT08c][DMT09g], a Web Service approach based on the SOAP pro-tocol [GHM+07]. It uses the WS-CIM binding described in [DMT09f], which describesthe algorithm to map CIM to the XML Schemas and WSDL (Web Service DescriptionLanguage [CMRW]) used in a Web Services framework. This is a more recent and evolvedalternative than the one based on the XML over HTTP protocol and the CIM-XML en-coding previously mentioned.

• SM-CLP [DMT07c], a lightweight human-oriented command line protocol based on Telnet,SSH or any other character-oriented transport. It uses the CLP-to-CIM mapping describedin [DMT09d] but only covers a subset of the CIM Schema, in particular, operational controlof the server hardware and rudimentary control of the operating system.

These communication protocols enable to access, modify and operate CIM objects in arepository managed by the CIMOM. The CIMOM acts as a technology neutral managementfront-end, relaying the management operation to the proper provider module which performsthe actual operation on the managed device (Figure 3.10).

Note that the interface between the provider and the managed device is not specified inthe WBEM architecture and may rely in another management system, e.g. SNMP [HPW02].


CIMrepository

(CIM Schema+

instances)

CIMOM

CIM Schema +instances(MOF files)

MOF Compiler Provider A

Manageddevice A

Provider B

Manageddevice B

Provider C

Manageddevice C

CIM Client

HTTP/XML(CIM-XML)

WS-Man(WS-CIM)

Telnet/SSH(SM-CLP)

WBEM server

Figure 3.10: WBEM Architecture

In addition, the interface between the CIMOM and the providers is not defined by DMTF.However, the Open Group is leading an attempt to standardize a CIMOM-to-provider interface,namely CMPI (Common Manageability Programming Interface [CMP06]).

Regarding the CIM repository shown in Figure 3.10, it contains a static and a dynamic part.The static part is compiled from MOF files using a compiler, consisting in the CIM Schema and(optionally) static instances. The dynamic part consists on dynamic instances, that are createdthrough management operations, e.g. the creation of a new static route in a managed devicewould create an instance object to represent that route. The MOF format and the CIM Schemaare described in Sections 3.4.2 and 3.4.3 respectively.

3.4.2 CIM Infrastructure

The CIM Infrastructure [DMT08a] is the metamodel for CIM, also referred as metaschema inDMTF documents, describing all the constructs that can be used to define management infor-mation in CIM and a list of constraints expressed in natural language17, e.g. multi-inheritanceis forbidden, association must inherit from associations, etc. The metamodel is shown in Fig-ure 3.11 using UML graphical notation. Its main elements are described following18:

• Class. Classes are abstractions of items that share the same characteristics (expressed withProperties) and behavior (expressed with Methods). They are structured hierarchically,based on mono-inheritance relationships. Multi-inheritance is not allowed. Classes canhave instances.

• Property. Properties model the state of the instances of a class. A derived class is allowedto redefine the properties of the parent class (i.e. properties overriding) and to add new

17Some authors has provided formal constrains in OCL, finding some inconsistencies and redundancies. SeeAppendix A in [Lop03].

18Note that neither Instance or DataType are include included in Figure 3.11, although actually they are definedin [DMT08a] and consequently they have been described here.


properties.

• Method. Methods model the behavior of instances of a class. The method signatureincludes a name, parameters and a returning value. A derived class is allowed to redefinethe method of the parent class (i.e. method overriding) and to add new methods.

• Instance. Instances are particular realizations of a class, providing actual values for itsproperties.

• Association. A special kind of class, containing two or more references. Associations areused to model the relationship between classes.

• Reference. A special kind of property, modeling the role that a class plays in an association.

• DataType. Different primitive datatypes are defined: signed and unsigned integers, real,strings, boolean, datetime and class references. Arrays which elements belong to primitivedatatypes are also allowed.

• Qualifier. Characterizes classes, properties, methods and method parameters, e.g. theMaxValue qualifier is used to characterize the maximum value of a numeric property. TheCIM Infrastructure document includes an extensive list of qualifiers. In addition, this set isvendor-extensible. Thus, it is possible to have user-defined qualifiers in Extensions Models(Section 3.4.3.3).

A qualifier has name (that identifies univocally the qualifier), type (e.g. integer, boolean,etc.), scope (the list of elements in the metaschema to which it can be applied), value (theactual value), flavor (describing propagation and overriding rules) and a default value (theimplicit value for elements which does not specify an explicit value for the qualifier).

Three qualifiers are specially relevant:

– The Key qualifier marks properties as keys. The combination of all the key propertiesunivocally identifies an instance within a class.

– The Propagated qualifier is used to mark key properties (i.e. properties also qualifiedwith Key) to mean that these keys are used also as “foreign keys” in other associatedclasses marked as weak (see Weak qualifier next).

– The Weak qualifier marks a reference corresponding to an association end as weak,meaning that the keys used by that class are propagated from the keys in the classin the other end.

The propagated-weak mechanism is typically used when the semantic of an associationinvolves some degree of dependence of one of the classes (the weak one) to the other (theone which provide the keys).

• Trigger. Models a change of state in the instance of a class, such as creation, delete, accessor update.

• Indication. A special kind of class, which instances are created as the result of a trigger.

• Schema. A group of classes. Schema is the basic packaging unit to build the CIM infor-mation model, as described in Section 3.4.3.

84 CHAPTER 3. MODELING AND TRANSFORMING MANAGEMENT INFORMATIONDSP0004 Common Information Model (CIM) Infrastructure

605

606

607 608 609

610 611 612

613 614 615 616 617

618 619 620

621

622 623

624

625

626

627

628

629 630 631

Figure 2 – Meta Schema Structure

6) A qualifier is a named element and has a name, a type (intrinsic data type), a value of this type, a scope, a flavor, and a default value. The type of the qualifier value must agree with the type of the qualifier type.

7) A property is a named element with exactly one domain: the class that owns the property. The property can apply to instances of the domain (including instances of subclasses of the domain) and not to any other instances.

8) A property can override another property from a different class. The domain of the overridden property must be a supertype of the domain of the overriding property. For non-reference properties, the type of the overriding property shall be the same as the type of the overridden property. For References, the range of the overriding Reference shall be the same as, or a subclass of, the range of the overridden Reference.

9) The class referenced by the range association (Figure 5) of an overriding reference must be the same as, or a subtype of, the class referenced by the range associations of the overridden reference.

10) The domain of a reference must be an association.

11) A class is a type of named element. A class can have instances (not shown on the diagram) and is the domain for zero or more properties. A class is the domain for zero or more methods.

12) A class can have zero or one supertype and zero or more subtypes.

13) An association is a type of class. Associations are classes with an association qualifier.

14) An association must have two or more references.

15) An association cannot inherit from a non-association class.

16) Any subclass of an association is an association.

17) A method is a named element with exactly one domain: the class that owns the method. The method can apply to instances of the domain (including instances of subclasses of the domain) and not to any other instances.

Version 2.5.0 DMTF Standard 19

Figure 3.11: CIM metamodel (as defined in [DMT08a])

One of the key characteristic that differences CIM from other more conventional languagesto define management information is its object orientation, which involves some important ad-vantages. Firstly, enables abstraction and the grouping of manageable objects in semanticallyconsistent classes to cope with the inherent complexity of networking systems. Secondly, it en-ables concepts specialization as new classes can be created extending others with new propertiesand methods. Next, associations enable to express conceptual relationships between manageableelements, making management information more consistent and easing manageability throughassociation navigation. Finally, class methods enable to model the behavior of manageableobjects.

The CIM Infrastructure also defines the MOF (Managed Object Format), a grammar (definedin ABNF) to specify CIM models conforming to the CIM metaschema. It is a fairly expressivelanguage that provides a complete syntax for describing classes and instances in a textual way,aiming at human-readability and formalization (i.e. compilers can interpret it) at the same time.In fact, the CIM Infrastructure defines some MOF elements (#pragma) which are compilationdirectives (e.g. to include a MOF file from another MOF file) and do not actually model CIMelements.

The first public version of the CIM Infrastructure (v2.0) was launched in 1999. At the timeof this writing (January 2010), the current version is v2.5 (released in May 2008).

3.4.3 CIM Schema

The CIM Schema is the management information model for WBEM-based systems. It is definedin CIM using the metamodel provided by the CIM Infrastructure (Section 3.4.2) in order todescribe the set of classes and associations that actually model manageable systems. An encodingin MOF is provided as formal specification.

Considering that CIM is aimed at modeling information systems in as complete as possibleway, the CIM Schema is divided in several modules, each one addressing a particular managementdomain. Its structure (that is normally presented with the “daisy diagram” shown in Figure 3.12)is described in the following subsections.


Device

System

Application

CoreNetwork

Physical Interop

Extension Models

Figure 3.12: CIM Schema

The first public version of the CIM Schema (v2.0) was launched in 1998. At the time ofthis writing (January 2010) the current version was v2.23 (released in October 2009) [DMT09a].It is work noting that the CIM Schema is updated frequently (including new elements anddeprecating others), around 3 minor versions are produced every year.

3.4.3.1 Core Model

The Core Model [DMT00] (Figure 3.13) contains a basic set of classes and associations, whichdefine concepts that are common to any management domain. The most relevant classes (allthem abstract) are:

• ManagedElement is the root of CIM Schema hierarchy and represents any manageableentity.

• ManagedSystemElement is the general representation of a system element. There are twobroad kind of system components, PhysicalElement (for components with physical iden-tity) and LogicalElement (for abstracts components). A specially relevant subclass of Logi-calElement is EnabledLogicalElement (modeling logical elements that can be either enabledor disabled). Additionally, there are two kinds of EnabledLogicalElements: LogicalDevice(abstraction of physical hardware) and System (entity describing the aggregation of Man-agedSystemElement component parts, using the SystemComponent aggregation, into asingle manageable whole).

• Setting (used to represent configuration and operational parameters for ManagedSys-temElements) and SettingData (used to represent configuration and operational parame-ters for ManagedElements). The latter is preferred given it is more general, although theformer is still used for backward compatibility with old versions of the CIM Schema.

• Collection models an arbitrary group of ManagedElements, which members are specifiedusing the MemberOfCollection aggregation.


ManagedElement

ManagedSystemElement

PhysicalElement LogicalElement

SystemLogicalDevice

Setting SettingDataCollection

Realices

SystemDevice1

EnabledLogicalElement

w

MemberOfCollection

DependencyComponent

LogicalIdentity

ElementSettingDefaultSetting 0..1

SystemComponent

Synchronized

ElementSettingData

SettingDefineState

Figure 3.13: CIM Core (simplified)

3.4.3.2 CIM Common Models

Each Common Model is focused on a specific management domain, defining the classes andassociations that are relevant to that domain, but independently from any implementation tech-nology. They are constructed by specialization of the classes in the Core Model. In addition,the different Common Models can be related to each other (by associations between classes).

There are many Common Models (currently, fifteen), being the most significative ones fromthe point of view of this document, the following ones:

• Network [DMT03a]. Models networks and communication connectivity, as well as theindividual networking services and protocols. It is divided into multiple parts, each oneaddressing different fields: systems, collections, protocol endpoints, pipes, filtering, buffers,routing, switching and bridging, forwarding, OSPF (Open Shortest Path First [Moy98]),BGP (Border Gateway Protocol [RLH06]) and SNMP.

• System [DMT03b]. Models computer system related abstractions. Many of the conceptsrelated to computer systems derive from the System abstraction in the Core Model. Italso addresses components and functionality associated with most computer systems, e.g.file systems and files, operating systems, processes and threads, etc.

3.4.3.3 Extension Models

Extension Models are extensions of the Common Models for specific technologies (for example,a specific operating system) using also the class specialization mechanism. They are usually


defined by vendors instead of by the DMTF. Technically speaking, Extensions Models do notbelongs to the CIM Schema, they are considered disjoint Schemas19.

3.4.4 DMTF Profiles

A DMTF profile is a specification that defines the “CIM model and associated behavior for amanagement domain” [DMT06]. In this context, management domain means a set of relatedmanagement tasks and CIM model the particular set, generally small and focused, of classes,associations, indications, methods and properties of the CIM Schema that make sense for thegiven management domain (Figure 3.14, left).

For each one of these elements, a requirement level is specified (mandatory, optional orconditional). In addition, the profile also specifies constrains on the CIM Schema (e.g. rangevalues for properties, allowed methods, etc.). Each profile defines a central class, which is “thefocal point for identifying conformance with that profile” [DMT07b].

The aim of DMTF profiles is to guarantee interoperability in the use of WBEM for a specificmanagement field covered by the CIM Schema, given that the specification of the CIM Schemaitself lacks this kind of information.

central class

Core

CIM Schemasubset + requirement level,

constraints = DMTFprofile

Autonomous 1

Autonomous 2

Component B

Component C

Component A

Management Domain 1

Management Domain 2

scoping class

Figure 3.14: DMTF profiles

Actually, a complex management domain can be defined by a set of management profiles.To this end, DMTF defines two kinds of profiles (Figure 3.14, right):

• Autonomous profiles. They define an autonomous and self-contained management do-main, either standalone or composed (complemented by component profiles).

• Component profiles. They cannot be used by themselves, only when combined with anautonomous profile. The elements of the component profiles are associated to a scopinginstance (of a scoping class, usually a System) in an autonomous profile, which is referredto as the scoping profile. Multiple autonomous profiles can share the same componentprofile.

19So classes in Core and Common Models are prefixed by CIM , accordingly to the naming rules in CIMInfrastructure, but Extension models must use a different prefix (e.g. Win32 ).


Furthermore, an orthogonal classification defines abstract and specialized profiles:

• Abstract profiles. They define common elements that provide a base for specializedprofiles. They cannot be implemented directly.

• Specialized profiles. Based upon another profile (either abstract or specialized) addingadditional constraints.

3.4.5 UML Profile for CIM

DMTF has defined an UML profile for CIM20 in DSP0219 [DMT07e], using the UML exten-sion mechanism described in Section 3.2.2.3 in order to take advantage of the existing UMLtechnology (e.g. tools, knowhow, user communities, etc.). The CIM profile requires UML L3compliance21.

Basically, the profile describes how to transform CIM models encoded in DMTF’s MOF toUML models and the reverse transformation from UML models to CIM models in DMTF’s MOF.The mapping between CIM metaschema elements described in [DMT08a] (Section 3.4.2) to UMLmetaclasses is summarized in Table 3.1. The profile specification also describes compliance valuesfor metaclass attributes and associations that do not have a meaningful correspondence in CIM,e.g. visibility, which is defined in UML but not used in CIM.

CIM metaschema element UML metaclass instance

Class Class

Property Property (used as normal attribute)

Method An Operation and as many Parameters asparameters in the Method signature plus onefor the return value

Instance An InstanceSpecification and as many Slots asproperties in the Class to which the Instance belongs

Association AssociationClass

Reference Property (used as association end)

DataType DataType

Qualifier Stereotype (except for direct mappings)

Trigger -

Indication Class

Schema Packages (one-to-many mapping depending ofthe UMLPackagePath qualifiers values in theClasses belonging to the Schema)

Table 3.1: CIM metaschema to UML metaclasses mapping

The most complex mapping is regarding qualifiers. Some of them has direct mapping to someUML metamodel constructs (e.g. the Abstract qualifier maps to the isAbstract attribute in UMLClass metaclass) or are mapped to specific stereotypes (e.g. Key, Experimental or Deprecated

20Not to be confused with the DMTF profiles described in Section 3.4.4.21[DMT07e] describes this as L2 plus an additional package in L3 (Classes::AsociationClasses). Actually, from

a formal point of view, this implies L3.


qualifiers, which have even a special graphic icons representation associated). However, for themost of them (including user-defined qualifiers) there is no equivalence and a generic mappingmechanism has be defined, please see [DMT07e] for details.

The specification also takes into account the information associated to MOF files, e.g. file-name, #pragma directives, etc. Although they are not part of the CIM metaschema in a strictsense, a mapping to UML is provided, using a specific stereotypes for them. The profile alsodefines an extensive set of constraints (mostly in OCL) to be satisfied by UML models in orderto be valid CIM model representations, i.e. the UML model can be mapped to DMTF’s MOFwithout loss of information. Finally, the mapping has some limitations, e.g. there is no UMLcorrespondence for Triggers.

Regarding implementations of the UML profile for CIM, there is not any one currentlyavailable to the best of our knowledge, being the closest approaches SBLIM ECUTE Modeler 2.x(under development [ECU10]) and ModelWizard (not updated since December 2005 [Mod10a]).Both are based on earlier versions representing CIM models in UML so they are not actuallycompliant with [DMT07e]22.

3.4.6 CIM Representation Alternatives

This section summarizes the different alternatives to represent modeling information in CIM:

• MOF language (Section 3.4.2). This is the “native” way of representing CIM information.The official releases of the CIM Schema are written in MOF and this is also the languageused in compilers to build CIMOM repositories (as shown in Figure 3.10).

• XML. Two XML encodings have been defined (CIM-XML and WS-CIM), mainly used forthe management protocol in the WBEM architecture, as described in Section 3.4.1.

• UML. Using the UML profile for CIM described in 3.4.5. This representation is based inan abstract syntax, although XMI (Section 3.2.2.5) could be used as concrete syntax23.

• Ontologies. There are also some works that deal with the representation of CIM in ontologylanguages, in particular [LDR03] (using OKBC), [LVB04] (OWL) and [QAW+04] (RDF(S)and OWL).

Therefore, CIM representation is very flexible, as all the major approaches considered inSection 3.2 are being considered. Consequently, any of the associated transformation mechanismdescribed in Section 3.3 could be used to transform CIM models.

3.4.7 Other Management Information Languages and Models

This section briefly describes in a comparative way alternatives to CIM as management informa-tion language. The analysis is partially based on the work performed in [LVAB03], which analysesthe semantic expressiveness of GDMO [ITU92], SMIv2 [MPS99], SMIng [SS04a], MIF [DMT03c],IDL [OMG02] and CIM. However, in the context of our work, which aims at finding the mostcomplete and suitable model to represent experimentation scenarios, not only the characteris-tics of the representation language have been taken into account, but also the richness of the

22However, support for [DMT07e] is in the SBLIM ECUTE Modeler roadmap for 3.x (without launching date).23This can be considered a third XML representation mechanism, in addition to the two ones mentioned in the

previous bullet.


standard information models expressed with it already produced and available, i.e. the CIMSchema in the case of CIM.

Some of the aforementioned approaches, SMIv2 and MIF, are table-based so they lack ofthe advantages described in Section 3.4.2 associated to object-orientation. In particular, theability to explicitly define relationships between management information pieces, given that therelationships between the items being managed are “hidden” in a set of scattered tables. Theirdesign is very device-oriented, so information about the device itself can be easily modeledbut the relations with other devices are difficult to capture. Therefore, it is complicated forthe manager to provide a comprehensive vision of the network of managed systems or, in ourcontext, the experimentation scenario.

On the contrary, GDMO and IDL are object-oriented languages. Regarding GDMO, CIM issimpler without losing any of the key advantages of the object-orientation paradigm, e.g. MOFtext-based codification in CIM is simpler than ASN.1 [ASN02] binary codification in GDMO. Acomparison between CIM and GDMO can be found in [FFAY99]. In addition, comparing theCIM Schema with the equivalent management information model defined using GDMO, whichis defined in the M.3100 recommendation [ITU05]24, the former is more comprehensive andevolves more dynamically to address new requirements in the IT management field, an averageof three revisions of the CIM Schema are produced by DMTF each year. Additionally, M.3100is very focused on the telecommunication operators domain (e.g. switching and transmissiondevices, circuits, etc.), so its scope is limited and potentially unsuitable for generic modeling ofexperimentation scenarios for networking testbeds. For example, M.3100 does not take IP layerinto account so it is unable to model IP addresses or routes.

SMIng is also an object-oriented language. In addition, it is similar to CIM in the sense itconsiders an XML encoding. However, SMIng management information is largely based on trans-lation from preexisting SMIv2 management information bases (i.e. MIBs) using the extensiondefined in [SS04b], so it inherits the device-oriented nature and difficulty to express relationshipsof SMIv2. On the contrary, CIM Schema has been defined using the object-orientation paradigmand provides an interrelated view of the managed network or experimentation scenario.

Similar to CIM is the TMF’s Shared Information/Data Model (SID) [TMF08b], part of theNGOSS (Next Generation Operation Support Systems) framework [TMF08c]. SID is defined in“pure” UML, so it also uses an object-oriented approach. Moreover, SID is sometimes describedas a federation of models rather than a stand alone model. In fact, CIM is usually included inthis federation and there are some works that show how a CIM-to-SID mapping can be done forspecific technical areas [TMF05a][TMF05b]. However, SID is strongly orientated to NGOSS andaimed at be used in combination with eTOM business process framework [TMF08a] as “termsvocabulary”. Thus, SID is very focussed in the business level, including the modeling of conceptsthat make little sense in a networking testbed scenario, e.g. such as customer, competitor or bill.Moreover, SID defines just taxonomy, while CIM defines a model that can be implemented asdefined without further extension, as explained in Section 4.1.1 in [TMF05b]. Another importantSID drawback is that only TMF members have free access to all its documentation, so itsutilization is quite reduced to the telecommunication enterprise scope while CIM can be freelyaccessed in the DMTF’s website. Therefore, given all the aforementioned reasons, in our contextCIM is preferred to SID.

Another characteristic in which CIM clearly advantages the others is in its representationalternatives flexibility. As described in Section 3.4.6, CIM can be expressed using its native text

24IDL uses a different specification for the management information model (M.3120 [ITU01]) but which is builttranslating manually from a set of M.3100.

3.5. CONCLUSION 91

format (MOF), XML, UML or ontology languages. The same level of flexibility is not achievedby any other of the management information languages considered in this section.

In conclusion, among the most relevant information management languages in the state ofthe art, CIM is the most appropriated choice in terms of expressiveness, richness, flexibility,openness and simplicity. A similar conclusion is achieved in [LVAB03], which states that CIM“defines information for the most management domains, including a subset of other managementmodels” an uses it as master model to define a common ontology for information management.

3.5 Conclusion

In this chapter the most relevant alternatives for general modeling have been analyzed, including:XML, the OMG’s modeling languages, ontologies and others (SGML, BNF grammars and ERD).Several model transformation techniques associated with each one of these approaches have beenalso considered. In particular, XSLT, XQuery and direct precessing for XML, the Model DrivenArchitecture (QVT, ATL and MOF2Text) for the OMG’s MOF-based languages and ontologymappings.

It is worth mentioning that modeling language technologies are not completely orthogo-nal. For example, XML can be considered as a basic encoding technology that enables toexpress grammars for other modeling technologies, such as the XMI language to encode OMG’sMOF-based models and ontologies languages in the scope of the Semantic Web (e.g. OWL).Additionally, UML models complemented with OCL constrains can define ontologies.

Regarding MDA, although OMG’s standards for modeling (specially UML) are well sup-ported in software engineering tools, it does not happen the same with the transformationstandards (as detailed in Section 3.3.2.6). Currently, only a reduced set of tools implementtransformation languages such as ATL and QVT. Moreover, the term “MDA-compliant” thatseveral tools claim to be is obscure because it could refer just to modeling standards but notto transformation. Even in the latter case, the QVT or ATL support degree, including even nosupport at all if only hardwired transformations are possible, and the stability of the tool canbe difficulty known without actually testing it.

The analysis of information management models has focused on CIM considering that it isone of the most expressive languages to define management information, its alignment with themodeling and transformation approaches analyzed in Sections 3.2 and 3.3 and the richness ofthe management information model specified using it (the CIM Schema), which combined area clear advantage over other alternatives (GDMO, SMIv2, SMIng, MIF, IDL or SID). As willbe seen in Chapter 4, CIM is the technological foundation to solve the scenario technologicaldependency problem in networking testbeds through the definition of a Testbed IndependentModel based on it.

CIM provides a great freedom degree to choose the modeling approach to express and trans-form management information models. In general, each one of the modeling and transformationtechnologies analyzed in this chapter have its advantages and drawbacks and they have to becarefully analyzed in the context of the particular application domain. So, an analysis of the rightsolution in the scope of configuration management for networking testbeds is also performed inChapter 4.

Chapter 4

Model Driven ScenarioConfiguration Management

4.1 Introduction

As introduced in Section 1.2, the goal of this dissertation is to solve the problem of scenariotechnological dependency in flexible experimentation infrastructures with the development ofa new configuration management architecture that seamlessly integrates with existing testbedsand tools. In particular, a model-driven approach is used in order to decouple the desiredscenario from the testbed in which it will be physically deployed.

One of the main conclusions shown in Chapter 2 is that the scenario-based paradigm is thestate of the art in configuration management for existing flexible experimentation infrastructu-res, specially for the locally distributed testbeds, and the trend in new Future Internet testbeds.Scenario-based management involves several advantages, in particular, the utilization of auto-matic procedures solves the problem of time-wasting (because of the work is done by the tool onbehalf 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 thenetworking scenario).

However, the specification mechanism used to describe the scenarios to be deployed is coupledwith the testbed in which it has been developed. In other words, there is no a common high-level scenario specification language and the scenarios written for a testbed cannot be usedby the scenario-based configuration management tools of a second testbed, although much ofthe specification is the same from a conceptual point of view (e.g. topology, addressing, etc.)so it could be directly reused. As mentioned in Section 2.6 this avoids inter-testbed scenarioreutilisation, the existence of generic scenario configuration tools and the sharing of knowledgeamong experimenters working on the same scenarios but in different testbeds.

The objective of this chapter is to describe the model-driven configuration managementarchitecture that addresses those problems (Section 4.2). Next, the common scenario specifi-cation language in which the architecture is based and the general methodology to transformthe scenarios specified using this common language to specifications for the different testbeds inwhich they will be finally deployed are detailed in Sections 4.3 and Section 4.4 respectively. Fi-nally, a description of the different roles involved in the model-driven configuration managementarchitecture is provided in Section 4.5.

93

94 CHAPTER 4. MODEL DRIVEN SCENARIO CONFIGURATION MANAGEMENT

4.2 Architecture

Our objective is to design a configuration management system for networking testbeds achievingscenario-technological independence, that is, to enable the use of the same topology and associ-ated configuration in testbeds that can be very different from a technological point of view. Atthe same time, this system needs to avoid the modification of testbeds and tools, as it has to fitinto existing testbeds without any re-engineering effort.

The model-driven architecture shown in Figure 4.1 is proposed for such purpose. It hasbeen named model-driven because it is based on scenario modeling, so each given scenario isrepresented by a refinement of models: from the scenario definition to its final deployment ina given testbed. In fact scenario specifications are considered at two modeling layers, testbed-independent and testbed-specific, which are detailed below.

Testbed 1parameters

TIM to TSM1Transformation

Testbed N

Testbed 2

Testbed 1


Testbed 2parameters

Testbed Nparameters

TIM to TSMNTransformation

Desired scenario

Testbed-independentscenario model

(TIM)

Testbed specific scenario models

(TSM)

Scenario-basedmanagement tool

In testbed N


In testbed 2


In testbed 1

… …

Scenario design

tool

Scenariorepository

Figure 4.1: Model-driven architecture for scenario-based management

The different elements of this architecture are described as follows:

• Testbed-independent scenario model. The first modeling level corresponds to a Test-bed Independent Model1 (TIM), which describes the scenario from a testbed-agnostic per-spective, without considering its deployment aspects, e.g. which physical device will hosteach node. Given that TIM is not focused in any particular testbed, it can be used todescribe scenarios in a general way, not tied to any specific testbed technology.

• Testbed-specific scenario model. The second level is a Testbed Specific Model (TSM),which completes the testbed-agnostic model with those deployment details for the specifictestbed.

• TIM-to-TSM transformation (testbed specific). TIM scenarios are not directlyusable by scenario-based management tools in testbeds, because they lack deploymentrelated concepts, e.g. what particular physical node and VLAN are assigned to each

1Actually, experimentation scenarios are instance models conforming to TIM/TSM models in the same wayUML instance models conform to UML class models. We are using the same terminology than in the OMG’slayered meta-modeling architecture (Section 3.2.2.1).

4.2. ARCHITECTURE 95

node and link in TIM respectively. The TSM is derived from TIM through automatictransformation tools integrated in the configuration management system. These toolstake the scenarios specified using the TIM as input and add information regarding howthey have to be actually deployed in the testbed.

• Scenario-based management tool (testbed specific). The actual management op-eration (e.g. deployment) is performed by testbed specific scenario-based configurationmanagement tools. The tool takes the TSM as input and performs automatically thecorresponding actions, interacting with the testbed physical elements using the propermechanism, e.g. SNMP, vendor-specific command line interfaces, etc. Thus, the set ofmanual operations is replaced by just one high level operation, and the scenario-based ma-nagement tool will deal with the testbed infrastructure configuration. Once deployed, thescenario-based management tool can provide additional management operations dependingon the testbed nature and its scenario lifecycle (see Section 2.2.1.2), e.g. monitoring, run-ning sequence of events, etc. Examples of scenario-based management tools are providedin Sections 2.3, 2.4 and 2.5.

As detailed in Section 2.2.1.3, the scenario-based approach solves the drawbacks associatedto manual procedures: it saves time, as the main work is made by the scenario-based tool;eliminates human errors, as human intervention is avoided during the deploy operation;and allows to perform automatic coherence checks on the scenario deployed, checking itscorrectness and simplifying debugging tasks. Besides, the approach provides isolation fromlow-level testbed technologies management (e.g. the scenario-based tool deals with VLANconfigurations in the desired way) and scalability (the processing logic implemented by thesoftware tool is the same no matter the size of the networking scenario).

• Testbed parameters. Transformation tools require a description of the testbed envi-ronment, e.g. number and attributes of physical nodes, etc. The particular parametersdepend on the testbed nature, and could be quite static, e.g. they only change when a newphysical element is added to the testbed infrastructure, or dynamic, representing in eachgiven moment the current availability of resources in the testbed. In addition, parameterscan be either simple, e.g. single-value attributes, or complex, e.g. the graph describing thetestbed physical topology in order to select the physical nodes that resemble more closelythe scenario topology.

• Testbed. The actual flexible experimentation infrastructure in which the scenarios aredeployed and managed. Sections 2.3 and 2.4 provide an analysis of different representativetestbeds existing nowadays.

• Scenario design tool. In order to define the desired scenario, the testbed users are aidedby a tool which provides an easy and intuitive way of designing scenario models. Giventhat this tool focuses on TIM scenarios, it provides a high-level perspective. This toolcould be based on a GUI editor, e.g. to just “draw” the network topology using a paletteof items that includes the different network nodes and configuring links among them. Thisis a successful approach used nowadays at TSM level, but GUIs to design scenarios forone testbed cannot be used in other testbeds. In addition, the design tool could includevalidation and sanity-check features, e.g. warning the user when he or she tries to use thesame IP address in two different node interfaces connected to the same subnet.


• Scenario repository. In order to store the scenarios developed at TIM level, a repositoryis integrated with the scenario design tool. It can be as simple or complex as required,implementing document management features such as versioning, backup, etc.

This approach, based on two modeling abstraction levels and automatic transformationsbetween them, is quite similar to the one proposed in the Model-Driven Architecture (MDA)(described in Section 3.3.2 in the context of software engineering). The Testbed IndependentModel (TIM) plays the role of Platform Independent Model (PIM) and the Testbed SpecificModel (TSM) plays the role of Platform Specific Model (PSM). As a matter of fact, our workcan be considered as an application of the model-driven engineering principles to improve con-figuration management in flexible networking testbeds which, to the best of our knowledge, hasnot be done so far.

Note that, from a functional point of view, scenario design, transformation and scenario-based configuration management are interdependent processes. Actual implementation of con-figuration management systems for testbeds could combine all these functionalities in the sametool (as shown in Figure 4.2) providing the user an integrated view. However, this kind of inte-grated tools is out of the scope of our architectural considerations. Moreover, the scenario designtool and the scenario repository are supporting elements in the architecture, but not actuallyrelated with the configuration management problem we are addressing, so they will be also leftout of our scope from now on.



In testbed 1


In testbed 1


in testbed N



Integrated testbed configuration management tool

Scenario design

tool

TIM TSM

Scenariorepository

Testbed Nparameters

Figure 4.2: Integrated scenario-based testbed configuration management approach

The cornerstone of this configuration management architecture is the TIM, which definesthe set of concepts that are needed by scenarios and their relations among them. Therefore,using TIM as “vocabulary” the testbed users can define any desired scenario in a deployment-agnostic way, i.e. not tied to any testbed in particular. The rest of this chapter is devoted tothe TIM definition (Section 4.3) and to the general transformation methodology to be used withscenarios modeled in TIM to produce the particular TSM scenarios (Section 4.4). Note that inthis chapter we focus mainly on the requirements and design decisions, for the TIM detaileddescription please see Chapter 5.

4.3 The Testbed Independent Model

4.3.1 Design Principles

This section describes the main design principles that have been taken into account to designthe TIM:

4.3. THE TESTBED INDEPENDENT MODEL 97

• Completeness. Given that the TIM aims to provide a common scenario definition modelgenerally applicable to any flexible networking testbed, it must be rich enough to modelthe information that any scenario may include. In other words, it has to consider theinformation elements used by the scenarios in the most relevant testbeds existing today,analyzed in the state of art in Chapter 2. We focus in scenario static aspects, dynamicaspects have been left out for future work (see Section 8.3.1).

• Modularity. The design of a monolithic TIM achieving the completeness requirement des-cribed in the previous bullet would be overwhelming considering the huge (and ever grow-ing) number of different services and functionalities that a testbed may include. Therefore,a modular approach is needed.

• Network-layer orientation. On the one hand, although networking testbeds couldinclude systems for application management, they use to be based on already existingmodels and tools, e.g. SmartFrog [GGLM03], SDD [OAS08], etc. On the other handphysical layer and link layer specification have no sense in TIM, because of its high-leveldeployment-independent nature. Therefore, the TIM scope will be focused on the networklayer, IP at the time being, considering the both major versions existing nowadays (IPv4and IPv6).

• Future extensibility. Networking is a very active field and new technologies are continu-ously arisen, e.g. protocols, architectures, services, etc. Given that TIM and its associatedarchitecture are indeed a configuration management approach for testbed where these newtechnologies are going to be tested and experimented with, its design has to take intoaccount future extensibility to avoid obsolescence.

This includes the application of the model to clean-slate testbeds proposed in FutureInternet initiates, in which IP protocol is not used at all. Thus, although the TIM isIP-layer oriented, as described in the previous bullet, it must not preclude its utilizationin no-IP testbeds.

• Simplicity. In order to be easily understandable by users and implementable in softwaretools, etc., the resulting TIM must be as simple as possible to fulfill the principles describedabove, but without including any unneeded or irrelevant feature or functionality.

4.3.2 CIM-based TIM Design

Although one possibility will be to define the TIM from scratch, we have found that existingmanagement information models meet the requirements included in the previous section, so itmakes much sense to reuse them instead of defining an enterally new TIM.

In particular, the analysis performed in Section 3.4.7 concluded that, among the mostsalient management information languages (CIM, GDMO, SMIv2, SMIng, MIF, IDL or SID)the DMTF’s Common Information Model (CIM) is the most appropriated choice to model ex-perimentation scenarios in testbeds, due to its expressiveness, richness, flexibility, openness andsimplicity. Therefore, the TIM will be based on CIM.

Actually, the CIM Schema (described in Section 3.4.3) is too broad and, instead of consi-dering it completely, the TIM is based only on a subset of relevant concepts. Firstly, becauseit could be overwhelming to consider and include every management object from each Com-mon Model. Secondly, because only a subset of concepts is needed to solve the problem ofscenario-based deployment in flexible testbeds and the inclusion of more than necessary would


be overengineering the problem, so breaking the simplicity requirement. Moreover, as new func-tionality is required due to the evolution of networking technologies, new subsets of the CIMSchema can be packaged and added as modules.

In order to cope with this complexity in a modular way, the envisioned TIM structureis composed of two parts. First, a TIM Core which is common to all use cases and definesbasic networking concepts, like topology, addressing, static routing, etc. Second, optional user-defined TIM Modules that provide a coherent set of network functionalities (services, processes,applications, etc.) executed by the nodes in the network, e.g. a TIM GMPLS Module forGMPLS networking testbeds such as the ADRENALINE testbed (described in Section 2.3.2).The association between the TIM Core and its TIM Modules is done through extension of theService class. We have exemplified this mechanism with the definition of a TIM OSPF Modulein Section 5.3.1.

Therefore, the TIM Core will include basic topological concepts and IP-networking concepts,e.g. addressing, static routing, etc., while further TIM Modules will develop specific functionalityrelated with IP layer like dynamic routing packages (e.g. TIM OSPF Module), lightpath provi-sioning (e.g. TIM GMPLS Module), IP multimedia systems (e.g. TIM IMS Module [CGM06])or any other functionality. It is also possible to use Modules to replace the IP protocol, asrequired by clean-slate Future Internet testbeds, in which case only the topological aspects onTIM Core, nodes and link interconnections, are needed.

The TIM Core is defined using classes and associations from Core Model, Network and Sys-tem Common Models and some classes included in an ad hoc Extension Model outside the CIMSchema (CIM Extension models are described in Section 3.4.3.3)2. For a detailed description ofthe different classes and associations included in the TIM Core, see Section 5.2. Regarding theclasses and associations in TIM Modules, it would depend on the particular module. However,given that the most of the network functionality is included in the Network Common Model, inis foreseeable that the most of the possible TIM Modules will base their classes and associationson it, maybe complemented by some ad hoc Extension Model. In particular, for the case ofthe TIM OSPF Module mentioned before, all the classes and associations belong to NetworkCommon Model, given that OSPF is a quite consolidated protocol in the dynamic routing field(see detail in Section 5.3).

Note also that the TIM Modules mechanism enables to cope with the evolution of networkingtechnologies. As new networking technologies (e.g. new protocols) are created, the new func-tionality can be encapsulated into new TIM Modules in an harmonious way, without breakingthe TIM Core (assuming that core networking concepts will keep very stable along the time) andexisting TIM Modules. That new TIM Extensions could be based on part of the CIM Schema,if the new networking technology has been already standardized by DMTF, or in ad hoc CIMExtension Models, taking advantage of CIM extensibility itself.

Note that although the requirement is to focus on network layer, the modular approach doesnot preclude the integration of software management tools. As a matter of fact, the integrationof this kind of tools should be performed through TIM Modules, e.g. TIM SmartFrog Module,TIM SDD Module, etc. filling the gap between the application management (which specifiesthe software components to manage) and the TIM Core (which defines the nodes where thoseapplications will be deployed, along with the IP layer parameters that ensure connectivity in thenetwork). However, the actual development of this kind of software management TIM Modulesis not considered within the scope of our work.

2By “ad hoc” we mean that this Extension Model has been explicitly built to address specific needs in theTIM, not covered by the existing models in the CIM Schema.

4.3. THE TESTBED INDEPENDENT MODEL 99

4.3.3 Completeness Evaluation

Table 4.1 compares the TIM to the different specification languages analyzed in Chapter 2,showing its completeness as it is able to model all the information needed in scenarios for stateof the art testbeds3.

Language Basic topology IP addressing Link modeling Static Arbitrary DynamicNodes Links IPv4 IPv6 PPP Multi- QoS routes node conf.

point constr. process behaviourEmulab X X X • X X X X • XADRENALINE X X X • X • X • GMPLS •

processesModelNet X X • • X • X • • •VNUML X X X X X X • X Plugins •NetKit X X • • X X • • NetML •MLN X X X • X X • • Plugins •vBET X X • • X X • • • •Dynagen X X • • X X • • • •PlanetLab X X • • X • X • • •(VINI)GX-Bone X X X X X • • • • •DRAGON X X X • X • X • • •(AST)Weevil X • • • • • • • Arbitrary X

propertiesAnyBed X X • • X • • • • •NDL X X X X X • • • • •TIM X X X X X X X X TIM •

Modules

Table 4.1: TIM completeness evaluation

The TIM class descriptions provided in Chapter 5 show in detail how TIM covers the differentinformation elements included in Table 4.1.

4.3.4 TIM as DMTF pseudo-profile

In the previous section, we have defined the TIM as a Core of basic networking functionalityand a set of Modules, each as a set of classes and associations belonging to the CIM Schemaand Extension Models. In Section 3.4.4, DMTF profiles are introduced as specifications thatdefine a subset of the CIM Schema with an associated behavior for a given management domain.Considering in our case scenario-based testbed management as the management domain, thenthe TIM could be considered a DMTF profile. In this sense, the TIM is similar to the IPinterface profile described in [DMT07a], but focused on scenario models for networking testbeds.Consequently, the TIM considers interconnection links (not only interfaces) and a more completenode model including forwarding, static routes and extensible network-related functionality.

Actually, not only one but several profiles can be defined. In particular, the TIM Core wouldplay the role of autonomous profile and the TIM Modules would be component profiles, as shownin Figure 4.3, which is a particular case of Figure 3.14 for the TIM case. For details of whichones would be the central and scoping classes in this case, see Sections 5.2 and 5.3.

There is a major difference between conventional DMTF profiles (such as the IP interfaceprofile mentioned above) and the TIM. On the one hand DMTF profiles are aimed at WBEM-

3The only exception is dynamic behaviour, a functionality included in Emulab and Weevil but not in TIM.However, this has been identified as one of the future work lines, in Section 8.3.1.


Core

System

Network

TIM Core profile(autonomous)

CIM Extension Model forTIM Core exclusive

classes and associations(ad hoc Extension Model)

TIM Module profiles(component)

Figure 4.3: TIM as DMTF pseudo-profile

based management in an architecture as the one defined in Section 3.4.1. On the other hand,the TIM is not intended to be used in WBEM context4, but to be used in transformationsso TIM scenarios can be transformed to TSM scenarios to be actually deployed by scenario-based management tools in each testbed. In fact, none of the testbed management systemsconsidered in the state of the art in Chapter 2, either scenario-based or not, is using WBEM. Thismakes sense as WBEM is more focused on production environments than in experimentationinfrastructures.

However, TIM is introducing restrictions in the CIM Schema, as DMTF profiles do. Inparticular, those restrictions consist of the set of properties utilized in the CIM Schema classes,given that many of them are not actually necessary if WBEM management is not considered,and the total removal of methods, because methods are to be implemented in a WBEM Serverwhich actually is not used in the context of utilization of the TIM.

Given the above discussion, we do not consider TIM a full-fledged DMTF profile, but apseudo-profile given that, although it meets the basic DMTF profile definition (a CIM Schemasubset plus restrictions on that subset) it is not addressed to WBEM based management and ithas not been defined accordingly to the formal standard specified in [DMT06].

4.4 TIM-to-TSM Transformation Design Methodology

Given that each testbed involves a different TIM-to-TSM transformation, it is not feasible tospecificy all possible TIM-to-TSM transformation in this work, as is done with the TIM (whichis common an unique) in Section 4.3 and Chapter 5. However, we have defined a generalmethodology to design such TIM-to-TSM transformations, described in this section.

4Using TIM in a WBEM-based testbed is addressed as future application in Section 7.4.

4.4. TIM-TO-TSM TRANSFORMATION DESIGN METHODOLOGY 101

4.4.1 Design Principles

This section describes the main design principles that have been taken into account to definethe TIM-to-TSM transformations methodology:

• Two inputs. As described in Section 4.2, the TIM-to-TSM transformation has to takeinto account two inputs: the TIM and the parameters used for the particular testbed towhich the TSM is addressed.

• TSM neutrality. The methodology has to be general and not focused on any particularTSM modeling technology. This is a key requirement in a context in which there is a highand growing diversity of networking testbeds (thus, diversity of target TSM) to which themethodology could be applied.

However, special consideration could be made for specially relevant cases. In particular, theanalysis done in Chapter 2 shows that XML is very extended in TSM scenario modeling5,so we pay special attention proposing specific algorithms for it as contribution.

• Transformation language neutrality. Neutrality is important no only from a TSMpoint of view, but also considering the language used to express the transformation rules.Note that transformation languages (QVT/ATL, ontologies, etc.) are still evolving, so themethodology should not adhere to any particular one in order to not become obsolete inthe future.

• Simplicity. Similar to the simplicity principle for the TIM design mentioned in Sec-tion 4.3.1, the transformation should be as simple as possible without including unneces-sary steps.

4.4.2 Transformation Alternatives Discussion

One of the main conclusions in Chapter 3 is that each different transformation technique isassociated to a particular paradigm for the input and output models. That is, XSLT andXQuery transformation are based on XML models, while OMG’s MDA is suited for MOF-basedmodels. Finally, ontology mappings consider ontologies as modeling approach.

As detailed in Section 4.3.2, the TIM is based on DMTF’s CIM. But, as argued in Sec-tion 3.4.6, the same CIM management information can be expressed using several alternatives:“native” text-based representation in DMTF’s MOF, XML, UML models (which are OMG’sMOF based) or ontologies. Therefore, this flexibility in the representation alternatives for TIMinvolves a great freedom degree to choose the transformation technology to use for our method-ology. However, it also impels us to do a careful analysis of the different alternatives, which isthe purpose of the present section.

In the case of using the “native” CIM text-based format using MOF, the transformationwould be based on an engine able to read MOF encoded information. The engine would becoupled with the particular TIM-to-TSM transformation, so different engines would have tobe implemented for different testbeds. Although there are some helper technologies such asLex/Yacc [LTM92] to build parsers for BNF-based grammars (as MOF is defined in [DMT08a]using ABNF), the solution is much more complex than the approaches that decouple transforma-tion definition and transformation engine. This is due to it is always more complex to implement

5As specific figure, note that 7 of the 17 cases in Table 2.1 (i.e. 41.17%) use a scenario specification languagebased on XML.


a complete transformation tool at this very low-level than a high-level transformation definitionto be used on already implemented general purpose engines. Thus, text-based transformationis discarded considering the simplicity principle and this analysis continues with the techniquesbased on high-level and decoupled transformation definitions.

Considering the different XML-based transformation alternatives (described in detail in Sec-tion 3.3.1), XSLT has two main drawbacks. First, given its transformation semantics (i.e.sequential processing of input) it is not very suitable for data-oriented XML documents, as theCIM representations are. Secondly, it does not allow to use more than one input. RegardingXQuery, it overcomes XSLT allowing multiple inputs and suits better to data-oriented XMLdocuments. However, the access to the input XML tree elements is still based on XPath, withis quite inconvenient for cross-subtree references, i.e. references in a subtree of elements rep-resenting one CIM instance to elements in another subtree representing another CIM instance.Finally, the direct processing of XML would reduce the complexity of implementing a coupledtransformation tool compared to a “pure” text orientation based on Lex/Yacc, but it has inessence the same problem described in the paragraph above.

Then, once XML is discarded, the discussion focuses on the MDA transformation standardsand the ontology mappings. The alternative is basically either considering UML to expressTIM scenarios based on the UML profile for CIM (described in Section 3.4.5) and QVT orATL as language to specify transformation rules; or considering ontology representations forTIM scenarios in OWL or RDF(S) based on existing works [LDR03][QAW+04][LVB04] and anontology rule language (e.g. SWRL) to specify the transformations rules.

The final decision is to use MDA, given the following arguments:

• Considering ontology mapping, the output model will be expressed using some ontologylanguage (OWL or RDF(S)). However, none of the scenario-based configuration manage-ment tools for testbeds analyzed in Chapter 2 is based on ontologies. Actually, the mostof them are based on text-based formats. Therefore, an additional step to transform themodel expressed using the ontology language into text is needed and it is more difficult todefine “Ontology2Text” procedures than the equivalent Model2Text in MDA, as the latteris already considered in QVT/ATL.

• MDA defines Model2Text transformations, that could be used to produce the text-basedscenario specification that existing scenario-based management tools use. This transfor-mation is quite easy and direct for the case of XML, that has a well-known metamodeland straightforward Model2Text rules (as detailed in Section 4.4.3).

• The use of MDA does not preclude the utilization of ontology mappings to relate trans-formed elements at a higher knowledge-based layer. In particular, the mapping ontologydefined in [LVAB03] can be used.

• Ontology rule languages (e.g. SWRL) are less expressive than QVT/ATL in MDA. On theone hand, SWRL does not include operators for or and not and it is quite limited regardingobject navigation. On the other hand, the OCL basement in QVT/ATL provides theselanguages with a rich set of operators and quite flexible object navigation capabilities.

• The MDA alternative is based on the UML profile for CIM, which is a standard (DSP0219[DMT07e]) backed by the DMTF. On the contrary, there is no unique standard way torepresent the CIM Schema as an ontology but many proposals from different authors, noneof them backed (yet) by DMTF or any other standardization body.


In conclusion, among the different possible alternatives for TIM-to-TSM transformationconsidering the flexible CIM representability capabilities, the OMG’s MDA approach is the mostconvenient and the chosen one to base our transformation methodology. MDA also considerstraceability, incremental transformation and bidirectionally as optional features that, althoughare not part of the design principles stated in Section 4.4.1, could be an added value for ourscenario-based model-driven configuration management architecture. In addition, it is worthmentioning that using MDA does not preclude the utilization of ontologies to relate elements inTIM and TSM at knowledge level, as will be elaborated in Section 4.4.3.

4.4.3 Methodology

This section describes the systematic methodology to implement TIM-to-TSM transformationsbased on the MDA approach. Consider a given testbed, in which scenarios are defined as TIMinstance models based on the UML profile for CIM using the TIM Core and a set of TIMModules (TIM Mod1, TIM Mod2, . . . , TIM ModN ). The testbed configuration management isperformed by a particular scenario-based configuration management tool defining a given TSM,or by a set of management tools, all using the same TSM.

Based in the assumptions above, the procedure is as follows:

1. TSM formalization. For those tools whose TSM has been explicitly defined as OMG’sMOF-based metamodel, this step can be skipped. However, considering the analysis ofscenario-based tools in existing testbeds performed in Chapter 2, this uses not be the caseand the TSM is implicitly “hidden” by the operation of the tool.

In order to formalize the TSM, the different concepts utilized in the scenario specificationlanguage have to be formally defined in a MOF-based metamodel, using classes, proper-ties, relationships, etc. For some language families the procedure can be generalized. Inparticular, considering XML-based TSMs, which is a relevant language family (as arguedin Section 4.4.1) we propose the following algorithm as contribution:

• Each element allowed in the XML scenario specification based on the DTD or XMLSchema (if any) is modeled using a class.

• The element attributes are modeled as class properties of the class associated to theelement.

• For non-empty elements, its content can be represented using a special property (e.g.text) which value is set to the text content.

• The children of a given element are modeled using a composition association (aggre-gation). The multiplicity in the part end is set using the cardinality specification inthe DTD or XML Schema (if any).

• The TSM metamodel can be composed by several separated un-related root classes,in the case the TSM is based on different separated XML documents (as for exam-ple happens with VNUML and ADNETCONF tools are, which TSMs are shown inSection 6.2.1 and 6.2.2 respectively).

2. TIM-to-TSM associations definition. For each one of the elements defined in theTSM, find which pieces of information need to be used from TIM Core and the N TIMModules. Actually, this step defines a set of transformation rules which relate elementsin TSM with the ones in TIM and the testbed parameters. At this level, the set of rules


can be specified informally using natural language. Doing this process, some“gaps” in theTSM could possibly arise, i.e. elements in the TSM that need pieces of information notincluded in the TIM. This can be due to two different reasons:

• The set of TIM Core and the N Extensions is not covering the TSM needs. Thiswould be the case of information not related with the deployment of the scenario inthe testbed, but used internally within the scenario nodes (typically, related with aservice or application run by the scenario nodes, e.g. a dynamic routing protocol).In this case, a new TIM Module (or several Modules) has (have) to be developedfor this particular testbed beyond the N initially considered, among two differentpossibilities:

– Reusing an existing TIM Module addressing the required functionality. In thatcase, just simply include and use that Module for the modeling of TIM scenariosaddressed to that testbed and consider its elements to fill the gaps in the TSM.

– No suitable TIM Module can be reused to address the required functionality. Inthat case, a new TIM Module has to be defined, considering the observations inSection 4.3.2 about TIM extensibility.

• It is information related with the deployment aspects of the scenario. This infor-mation cannot be part of the TIM by definition, so the different “gaps” found ofthis kind define the set of testbed parameters to be used as second input for thetransformation.

Note that, after performing this step, some elements in the TIM Core and even completeTIM Modules (in the N TIM Modules set) could not be used. This illustrates an interestingproperty of the transformation, because it can be used to “prune” or filter elements in theTIM not supported by a particular testbed, providing a “clean” TSM to the scenario-basedconfiguration tools. Pruning is illustrated in the case of VNUML and ADNETCONF inSections 6.4.1 and 6.4.2.

3. Construction of the TIM-to-TSM rules. Once the transformation rules have beendefined in the previous step in natural language, they have to be formalized using someof the languages considered in the MDA approach. Relational languages such as QVTr orATL, described in Sections 3.3.2.4 and 3.3.2.5 respectively, are highly recommended giventhat the rules defined in the previous section are actually relations between elements inTIM and TSM. Actually, using a relational approach the formulation of the rules can bededucted easily from the statements in natural language.

Due to the fact that the MDA standards and their implementations may evolve, the trans-formation methodology should not be dependent on the particular chosen transforma-tion language (transformation language neutrality design principle), so enabling to chooseamong the different options in a given moment (i.e. when the methodology is used) andlimiting the impact of that choice to this (and maybe the next) step. Note that the de-cision could be highly dependent on the status of the existing software implementations,e.g. stability, maintenance and support degree, tool users base, developer knowledge, etc.The status of the software is time dependent, as implementations generally mature as timepasses, whereas this methodology aims to be valid now and in the future.

Transformation rules can be grouped into one or more two-inputs Model2Model trans-formation definitions. Using several transformation definitions allows modularity, but it


depends on the structure of the TSM. For example, if the TSM is composed by differentXML documents, one transformation definition can be associated to each one, includingall the rules needed to produce that particular XML document.

4. Format adaptation. Except in the case of model-driven tools able to directly process theMOF-based model used in MDA that is the output of the Model2Model transformationdefined in the previous step, an adaptation step is required to produce the scenario in theformat that the tool is using. Note that none of the tools analyzed in Chapter 2 is model-driven, so in practice this step will be always required considering the existing testbedstoday. In fact, existing scenario-based tools use text-based formats.

There are two alternatives to implement the adaptation step to text-based formats:

• Direct. Consisting in applying a Model2Text transformation step after the Model2Modeltransformation defined in step 3. Depending on the TSM complexity and structure,this step could involve some complexity.

• Indirect. Consisting in a second one-input Model2Model transformation after thestep 3 Model2Model transformation to a well-known model which conversion to text(through a Model2Text) is straightforward. Indirect transformation is preferablewhen the complexity of this second Model2Model transformation is lower than thecomplexity of a direct Model2Text transformation.

Considering a TSM based on XML built as described in step 1, this second Model2Mo-del transformation is a transformation between the TSM instance model and an XMLinstance model conforming to the XML metamodel shown in Figure 4.4, as detailedin the following algorithm (proposed as contribution):

name: stringvalue: string

Node

Element Attribute TextNode

Root

0..1

0..*

parent

children

Figure 4.4: XML metamodel

– The instance of the class in the TSM corresponding to the root element is mappedto an instance of Root in the XML model, which name is the name of the class.

– The instances of each class in the TSM not corresponding to the root element aremapped to instances of Element in the XML model, which name is the name ofthe class. The Element (as Node) is associated to its parent Element.


– Instance class properties in the TSM are mapped to instances of Attribute in theXML model, which name is the name of the class property and which valueis the value of the class property. The Attribute (as Node) is associated to itsparent Element.

– As exception to the previous rule, the special property used for elements content(e.g. text) is mapped to a TextNode in the XML model, which value is the valueof the property. The TextNode (as Node) is associated to its parent Element.

The transformation from an XML model to a text XML document is straightforward,as it is based on a top-down algorithm using the parent-child relationship to navigatethe model and generate the text token corresponding to the syntax of a well-formedXML document.

Another possibility to perform the TSM format adaptation to XML is taking ad-vantage of the high similarity between the XMI codification and the actual XMLdocument it represents. Basically, the only difference is that elements content are rep-resented in XMI with text. An XSLT transformation (described in Section 3.3.1.1)could be use to “flatten” the text attribute to actual tag content. This approachdoes not adhere formally to the MDA methodology, although could be an alterna-tive method used by the modeling tool to implement the straightforward Model2Texttransformation mentioned in the previous paragraph.

Figure 4.5 shows the schema for a TIM-to-TSM transformation designed accordingly to thismethodology, including annotations about which blocks are considered in each step. The figureshows both alternatives for the format adaptation step, either direct (top) and indirect for theXML case (bottom).

As told in Section 4.4.2, this methodology is compatible with ontology mappings. In par-ticular, considering the management information mapping proposed in [LVAB03] (Figure 3.9),the associations between TIM and TSM elements defined in steps 2 and 3 could be used tobuild those mappings. The language to be used in the Formula instances would be set to theparticular mapping language used (e.g. ATL, QVTr, etc.) and the expression would be setto the transformation rule expressed in that language. This way, ontology mappings can com-plement the basic TIM-to-TSM transformation based on MDA described so far, allowing to usethis information by knowledge based tools able to process this kind of information. However, afurther discussion on the applications of ontologies to model-driven scenario-based configurationmanagement in testbeds is out of the scope of our work and left out as future work.

4.4.4 Transformation Not Based on Modeling

As alternative to the MDA methodology, TIM scenarios to be transformed could be stored in aWBEM CIMOM (see Section 3.4.1) and the transformation be based on a processing logic ableto query the CIMOM to get the TIM objects belonging to a given scenario model, then performthe transformation to generate the TSM.

However, this would be more complex in general than the proposed MDA based methodologydescribed in the subsections above, given it would not take advantage neither of modelingapproaches nor a systematic procedure. In addition, it would involve setting up and maintain aWBEM infrastructure for tasks that are not actually related with WBEM-based management.Finally, it is not an efficient solution, as the overhead introduced by the querying protocolmakes the transformation process much slower than when using MDA. We have performed


Core

CoreCoreCoreModN

Scenario Model2Model(step 2 & 3)

TIM

Scenario

TSM(step 1)

Model2Text(step 4)

Testbed parameters

(step 2)

Scenario(text)

Scenario-basedmanagement

tool

TIM-to-TSM transformation

Core

CoreCoreCoreModN

Scenario Model2Model(step 2 & 3)

TIM

Scenario

TSM(step 1)

Model2Model(step 4)

Testbed parameters

(step 2)

Scenario(XMLtext)

Scenario-basedmanagement

tool

TIM-to-TSM transformation

XML(Fig. 4.4)

XMLdocument

Model2Text(straightforward)

Possible XSLT-basedadaptation

Figure 4.5: TIM-to-TSM transformation detail: direct (top) and indirect for XML (bottom)


comparative experiments (based on the validation case described in Chapter 6) which show thatthe transformation times for CIMOM-querying transformations are much greater than the oneswith the MDA based methodology, i.e. between 345% to 706% greater depending on the scenariobeing transformed.

4.5 Model-Driven Configuration Management Roles

Two main roles can be defined in the model-driven scenario-based architecture described inSection 4.2: scenario designers and testbed administrators, each one with different activities inthe testbed configuration management. The formers are in charge of designing TIM scenarioand do not need to know the testbeds technological details. On the other side, the testbedadministrators are in charge on testbed administration. The scope of the two different roles inthe reference architecture is shown Figure 4.6.

Testbed 1parameters


Testbed N

Testbed 2

Testbed 1


Testbed 2parameters

Testbed Nparameters


Desired scenario

Testbed-independentscenario model

(TIM)


In testbed N


In testbed 2


In testbed 1

… …

Scenario design

tool

Scenariorepository

Scenario Designers Scope Testbed 1 Admin Scope

Testbed 2 Admin Scope

Testbed N Admin Scope

TSM1

TSM2

TSMN

Figure 4.6: Scenario designer and testbed administrator roles

These roles (along with some secondary ones) are described in the following subsections. Itis worth noting that for real cases, several roles may converge in the same particular person,specially for testbeds supported by small teams.

4.5.1 Scenario Designer

The specific activities for the scenario designer role are:

• Create the TIM scenarios, either from scratch or based in existing ones, ensuring that theyare valid ones (TIM scenario generation workflow). This task can be done manually orassisted by editing tools.

This role requires knowledge basically on TIM (described in Section 4.3 and Chapter 5).

4.6. CONCLUSIONS 109

4.5.2 Testbed Administrator

The specific activities for the testbed administrator role are:

• Control the testbeds parameter used by the TIM-to-TSM transformation.

• Execute the TIM-to-TSM transformation on TIM scenarios in order to get TSM scenarios(TSM scenario generation workflow).

• Operate the scenario-based tools to provide scenario lifecycle management (see Section 2.2.1.2),which main operation is deployment (scenario deployment workflow).

This role requires knowledge in the transformation tool in which the TIM-to-TSM trans-formation is based (but not in how it is actually implemented), the relation between testbedoperation and parameters (to being able of setting properly the latter) and the scenario-basedmanagement tools (from an user perspective).

4.5.3 Other Roles

Apart from these two main roles, additional ones (not shown in Figure 4.6) can be defined notdirectly involving configuration management tasks, but related with them:

• Developers. Actually, there are two subroles, each one specialized in providing differentelements of the configuration management architecture:

– TIM-to-TSM transformation developer, who implements and maintains the TIM-to-TSM transformation. This role requires knowledge in TIM and TSM, the methodol-ogy described in Section 4.4 and the specific transformation language used to buildthe transformation rules, e.g. QVTr or ATL.

– Scenario-based management tool developer, who implements and maintains the toolsthat actually deploy and manage scenarios in the testbed. This role requires knowl-edge in the TSM and the specific technologies (e.g. programming languages) usedto implement these tools, along with the configuration interfaces provided by thedevices conforming the testbed infrastructure. However, note that knowledge in themodel-driven configuration architecture in which the scenario-based management toolis integrated is not required.

The developer of the testbed itself is out of the scope of our work, as it is not directlyrelated with configuration management.

• Experimenter. This role is in charge of conducting the experiments to which the sce-nario is addressed, once it has been deployed by the testbed administrator. This includesinteracting with the scenario nodes, collecting results, etc.

4.6 Conclusions

In this chapter we have proposed a solution to the problem of scenario technological dependencyin flexible networking testbeds introduced in Chapter 2, using the modeling and transformationtechnologies that were analyzed in Chapter 3. This is achieved through our main contribution


in this dissertation: a model-driven architecture which provides a common configuration ma-nagement approach for scenario-based networking testbeds. Using the proposed approach, thedesired scenario (unique) can be defined in a high-level and deployment agnostic way using theso called Testbed Independent Model (TIM). TIM can be automatically transformed to (several)specific scenario representations in Testbed Specific Models (TSMs) suited to the scenario-basedmanagement tools used in each particular testbed. Several roles conduct different configurationmanagement activities in this architecture, being the main ones the scenario designer and thetestbed administrator. They are in charge of several workflows: TIM scenario generation, TSMscenario generation and scenario deployment.

The key element in the architecture is the Testbed Independent Model, which is basedon DMTF’s CIM and can be even considered a DMTF pseudo-profile. The present chapterhas described the TIM from a high level point of view, introducing its design principles oncompleteness, modularity, network-layer orientation, future extensibility and simplicity. TheTIM is structured in a Core and Modules covering different networking functionality and fulfillingall the aforementioned requirements. It is also worth mentioning that, although network-orientedmeans IP-oriented in today networking so the TIM Core has been designed focusing on thatprotocol, TIM modular design enables the evolution to different network protocols in clean-slate Future Internet testbed, through the development of the corresponding Module. For adetailed description of the different classes and associations composing the TIM, please refer toChapter 5.

It is worth to mention that the aim of our proposal is not to replace current configurationmanagement approaches. In fact, the architecture main design principle is to be compatiblewith existing scenario-based testbeds, without requiring modifications of present managementtools. On the contrary, our architecture tries to strengthen these systems adding a high-levelspecification layer that will integrate with existing configuration management systems.

It would not make sense to define each possible TIM-to-TSM transformation, because thenumber of scenario-based testbed is large, unknown and ever growing. However, we providethe description of a general TIM-to-TSM transformation design methodology, paying specialattention to the cases in which the TSM is XML-based, because it has been found in the stateof the art analysis performed in Chapter 2 that this case is specially relevant. Although theutilization of CIM as foundational model for TIM is quite straightforward, given the advantagesof CIM regarding other possible management information models (analyzed in Section 3.4.7), thischoice enables different representation possibilities and associated transformation approaches.After a discussion of the different alternatives, OMG’s MDA has been chosen as the most suitabletransformation technology.

Chapter 6 describes the experimental validation performed in order to asses the feasibilityof the proposed architecture and uses the aforementioned methodology in order to design twospecific TIM-to-TSM transformations.

Chapter 5

Testbed Independent ModelDetailed Description

5.1 Introduction

Chapter 4 describes the Testbed Independent Model (TIM) as a set of related DMTF pseudo-profiles combining several CIM Common Models belonging to the CIM Schema and ad hocExtension Models when necessary. In this chapter the details of such models are provided,describing the different classes and associations that are included in the TIM Core (Section 5.2)and an example of TIM Module modeling the OSPF dynamic routing protocol [Moy98] (TIMOSPF Module, in Section 5.3).

Figure 5.1 shows the different classes and associations described in this chapter, in the contextof the CIM Schema.

5.2 TIM Core

Figure 5.2 shows the class diagram for the TIM Core1. A brief description follows. Detaileddescription of each class an association can be found in Sections 5.2.1 and 5.2.2 respectively.

• The central classes are ComputerSystem and TIM LinkConnectivityCollection to modelnodes and links respectively, thus describing the topology.

• ComputerSystems belong to a TIM TestbedScenario, which models the scenario as a whole.

• The ComputerSystem interfaces are modeled through the IPProtocolEndpoint class, whichIP addresses are described with IPAssignmentSettingData instances. As a matter of fact,there are two subclasses, one for IPv4 addresses (StaticIPAssignmentSettingData) and onefor IPv6 ones (TIM StaticIPv6AssignmentSettingData). So, the network-layer orientationrequirement described in Section 4.3.1 is fully achieved.

Note that these classes include properties to model other IP related parameters not di-rectly associated to the interface, e.g. GatewayIPv4Address in StaticIPAssignmentSet-tingData, that could be introduced also as in TIM StaticIPv6AssignmentSettingData asGatewayIPv6Address. However, in TIM the utilization of these classes is restricted to

1CIM prefix has been taken out from CIM Schema classes for brevity.

111

112 CHAPTER 5. TESTBED INDEPENDENT MODEL DETAILED DESCRIPTION

Network

System

Core

Classes:TIM_TestbedScenarioTIM_LinkConnectivityCollectionTIM_TransmissionCharacteristicsTIM_StaticIPv6AssignmentSettingDataTIM_NextHopAddressedIPRouteAssociations:TIM_LinkTransmissionElementTIM_MemberOfLinkTIM_LinkOriginTIM_LinkDestination

Classes:ComputerSystem

Classes:IPProtocolEndPointStaticIPAssignmentSettingDataForwardingServiceAssociations:ForwardsAmong

Classes:ServiceAssociations:SystemComponentHostedCollectionHostedAccessPointHostedRouteElementSettingDataHostedService

TIMCore

TIM OSPFModule

Classes:OSPFServiceOSPFAreaOSPFAreaConfigurationRangeOfIPAddressesAssociations:OSPFServiceConfigurationAreaOfConfigurationRangesOfConfiguration

Figure 5.1: TIM classes regarding to CIM Schema

Name: string {key}

TIM_TestbedScenario

Name: string {key}CreationClassName: string {key}

IPProtocolEndpoint

InstanceID: string {key}

IPAssignmentSettingData

SubnetMask: stringIPv4Address: string

StaticIPAssignmentSettingData

IPv6Address: stringPrefixLength: uint8

TIM_StaticIPv6AssignmentSettingData

ElementSettingData

ComputerSystem


SystemComponent

1

HostedAccessPointProtocolType: uint16 {enum}

ForwardingService

ForwardsAmong

InstanceID: string {key}DestinationMask: stringDestinationAddress: stringPrefixLength: uint8AddressType: uint16 {enum}NextHopAddress: string

TIM_NextHopAddressedIPRoute

1

HostedRoute

1

Service


HostedService

HostedCollection

1

InstanceID: string {key}MaxConnections: uint16

TIM_LinkConnectivityCollection

TIM_MemberOfLink

InstanceID: string {key}DelayMean: uint64 {units}DelayDeviation: real32DelayDistributionFunction: uint16 {enum}LossProbabilityValue: real32LossProbabilityCorrelation: real32CorruptionProbability: real32CorruptionProbabilityCorrelation: real32DuplicationProbabilityValue: real32DuplicationProbabilityCorrelation: real32DisorderingProbabilityValue: real32DisorderingProbabilityCorrelation: real32Throughput: uinit64 {units}MTU: uint64 {units}

TIM_TransmissionCharacteristics

TIM_LinkOrigin

TIM_LinkDestination

0..1

TIM_LinkTransmissionElement

w

1

0..1 0..1

0..1

0..1

OSPFService

1

TIM Core TIM OSPF ModuleOSPFArea

Name: string {key}CreationClassName: string {key}AreaID: uint32

RangeOfIPAddresses

InstanceID: string {key}AddressType: uint16 {enum}StartAddress: stringEndAddress: string

OSPFAreaConfiguration

InstanceID: string {key}

OSPFServiceConfigurationAreaOfConfiguration

RangesOfConfiguration

0..1

w

Figure 5.2: Testbed Independent Model (TIM) class diagram

5.2. TIM CORE 113

the IP interface, using other mechanisms to model the rest of IP related parameters (e.g.the gateway is modeled using a default static route with TIM NextHopAddressesIPRoute).

Although these classes are oriented to IP as today fundamental network layer protocol,this does not preclude to use the TIM Core in Future Internet clean-slate testbeds, inspite of they could not be using IP at all. In this case the scenario modeling is focusedon the topological elements (ComputerSytstem and TIM LinkConnectivityCollection) andthe new protocols replacing IP could be developed as TIM Modules.

• A ComputerSystem may have static routes, modeled with TIM NextHopAddressesIPRoute.Dynamic routes are not directly modeled in TIM Core, but using TIM Modules to modelthe configuration required by the node processes implementing them, as the TIM OSPFModule defined in Section 5.3. Note that new dynamic routing protocols can arise soconsidering them in Modules is preferable, given that TIM Core should be as stable aspossible.

• The forwarding feature that some nodes may have, typically nodes with more than oneinterface acting as IP routers, is modeled using ForwardingService. It is assumed thatnodes not hosting a ForwardingService will not forward packages, as corresponds to end-systems.

• Each IPProtocolEndpoint is associated through the TIM MemberOfLink aggregation tothe link to which it belongs. An interface belongs to exactly one link, except for loop-back interfaces, that are not associated to any link. The MaxConnections property inTIM LinkConnectivityCollection can be used to specify a maximum number of allowedinterfaces, e.g. two to model a PPP link.

• Optionally, link QoS characteristics can also be specified, which is needed in some cases,e.g. link emulation using software packages, through TIM TransmissionCharacteristicsobjects associated to the link. Each instance of this class encapsulates a set of QoSconstraints, e.g. delay, loss probability, etc., for interfaces belonging to the link. The linkis specified through the TIM LinkTransmissionElement and, optionally, TIM LinkOriginand TIM LinkDestination if the characteristics are asymmetrical.

Several classes have been defined as weak to other classes, see Section 3.4.2 for details onweak classes and key propagation. In particular, TIM TransmissionCharacteristics is weak toTIM LinkConnectivityCollection, because QoS characteristics specification make no sense if theyare not associated to a given link. In addition, the CIM Schema specifies that IPProtocolEnd-Point and Service are weak to ComputerSystem, because of computer systems host particular in-stances of interfaces and services, respectively. It is worth noting that TIM NextHopAddressedIP-Route is not weak to ComputerSystem considering that the same route could be host in differentcomputer systems, e.g. the same default route.

The classes and relationships prefixed with TIM are not in the original CIM Schema andcorrespond to an ad hoc Extension Model, which MOF definition is provided in Appendix B:

• TIM TestbedScenario. Although CIM Schema includes a Network class, the TIM TestbedScenario(derived from the former) has been introduced in order to model the specialized semanticof a scenario in the networking testbed as a particular kind of network.


• TIM StaticIPv6AssignmentSettingData, due to the existing StaticIPAssignmentSetting-Data does not consider IPv6 addresses. Compared to that class, the IPv6Address prop-erty is used instead of IPv4Address and the PrefixLength is used (as an integer type)instead of SubnetMask (which is a string type).

• TIM NextHopAddressedIPRoute, because of the existing NextHopIpRoute from it derivesdoes not allow a direct specification of the route destination. It uses the AssociatedNext-Hop association to a RemoteServiceAccessPoint which use is not clear in available DMTFprofiles. Therefore, the direct specification of the route destination using the Next-HopAddress property introduced by TIM NextHopAddressedIPRoute is a simpler andmore direct approach.

• TIM LinkConnectivityCollection. CIM Schema does not include an interconnection link(logical) model, although the ConnectivityCollection (from this class is derived) has a closesemantic as “group of protocol endpoints of the same type”.

• TIM TransmissionCharacteristics. In this case, no similar QoS modeling concept has beenfound in the CIM Schema, so this class derives directly from LogicalElement, a ratherabstract class part of CIM Core Model described in Section 3.4.3.1.

Considered as DMTF autonomous pseudo-profile (see Section 4.3.4), the central class forTIM Core is TIM TestbedScenario. Finally, considering the CIM Infrastructure metamodeldescribed in Section 3.4.2, it is worth noting that TIM is not using any trigger, indication ormethod. Those are related with WBEM-based management and, as argued in Section 4.3.4, theTIM-to-TSM transformation is a process not based on WBEM.

5.2.1 TIM Core Classes

The TIM Core includes 10 classes, 1 from the Core Model, 1 from the System Common Model, 3for the Network Common Model and 5 outside of the CIM Schema, defined in an ad hoc Exten-sion Model which MOF representation is shown in Appendix B. As explained in Section 4.3.4,these classes have several properties, inherited across the subclassing hierarchy, that are notneeded for the TIM. Therefore, only the needed properties, i.e. the ones shown in Figure 5.2,are described.

5.2.1.1 TIM TestbedScenario

It models the testbed scenario as a whole. It derives from Network and does not belongs to thestandard CIM Schema.

Relevant properties:

• Name (key, inherited from System), a string that identifies the scenario.

5.2.1.2 ComputerSystem

It models the network nodes in the scenario. It derives from System and belongs to the SystemCommon Model.


• Name (key, inherited from System), a string that identifies the node.

5.2. TIM CORE 115

• CreationClassName (key, inherited from System), a string that specifies the name ofthe class used in the creation of its instances. In this case, it is “CIM ComputerSystem”.

5.2.1.3 TIM LinkConnectivityCollection

It models the network links in the scenario. It derives from ConnectivityCollection and it doesnot belong to the standard CIM Schema.


• InstanceID (key, inherited from SystemSpecificCollection), a string that identifies thelink.

• MaxConnections (local class property), an integer that specifies the maximum numberof nodes connected through the link, e.g. a PPP link is modeled with MaxConnectionsequals to two. If omitted, there is no limit to the number of nodes.

5.2.1.4 TIM TransmissionCharacteristics

It models the link transmission characteristics, as a set of transmission parameters (delay, lossprobability, etc.) to be applied to each IP package crossing the link. It derives from LogicalEle-ment and it does not belong to the standard CIM Schema.

Transmission characteristics can be associated globally to a given link using TIM LinkTrans-missionElement (see Section 5.2.2.6). This is used to model symmetric links in which case allthe interconnection among node pairs in the link share the same characteristics. However,characteristics can be defined in a per node pair basic, even specifying different parameters ineach direction using TIM LinkOrigin and TIM LinkDestination (see Sections 5.2.2.8 and 5.2.2.9respectively). This is useful to model asymmetric links, e.g. an ADSL line.

This class is weak to the TIM LinkConnectivityCollection through the TIM LinkTrans-missionElement association (see Section 5.2.2.6). That means that the key of TIM LinkConnecti-vityCollection, the InstanceID property, is propagated using the name LinkInstanceID andcomplements the keys defined in TIM TransmissionCharacteristics.

It is worth noting that in the link characteristics design we have chosen a suitable trade-off between statistical richness and simplicity. In fact, the model is based on the capabilitiesof network emulation packages currently available in state of the art testbeds, such as NIST-Net [CS03] or Netem [Hem05], because implementing a highly complex statistical link model,e.g. a more complete model of probability distribution functions, makes no sense if there is nosoftware actually able to implement it.


• InstanceID (key, local class property), a string that identifies the transmission charac-teristics instance.

• DelayMean (local class property), an integer that specifies the mean transmission delayin milliseconds.

• DelayDeviation (local class property), a real value that specifies the transmission delaydeviation.

• DelayDistributionFunction (local class property), an enumeration that identifies thedelay distribution function. The following ones have been defined in the TIM releaseproposed in this document: normal, uniform and pareto.


• LossProbabilityValue (local class property), a real value (in the 0 to 1 range) thatspecifies the loss probability.

• LossProbabilityValueCorrelation (local class property), a real value that specifies theloss probability correlation.

• CorruptionProbabilityValue (local class property), a real value (in the 0 to 1 range)that specifies the corruption probability.

• CorruptionProbabilityCorrelation (local class property), a real value that specifiesthe corruption probability correlation.

• DuplicationProbabilityValue (local class property), a real value (in the 0 to 1 range)that specifies the duplication probability.

• DuplicationProbabilityCorrelation (local class property), a real value that specifiesthe duplication probability correlation.

• DisorderingProbabilityValue (local class property), a real value (in the 0 to 1 range)that specifies the disordering probability.

• DisorderingProbabilityCorrelation (local class property), a real value that specifiesthe disordering probability correlation.

• Throughput (local class property), an integer that specifies the link throughput in bps.

• MTU (local class property), an integer that specifies the Maximum Transfer Unit (MTU)for the link, in bytes.

5.2.1.5 IPProtocolEndPoint

It models the network interfaces in nodes. It derives from ProtocolEndpoint and belongs to theNetwork Common Model.

This class is weak to ComputerSystem through the HostedAccessPoint association (see Sec-tion 5.2.2.3). That means that the keys of ComputerSystem, Name and CreationClassNameproperties, are propagated using the names SystemName and SystemCreationClassNamerespectively and complement the keys defined in IPProtocolEndPoint.


• Name (key, inherited from ProtocolEndpoint), a string that identifies the interface.

• CreationClassName (key, inherited from ProtocolEndpoint), a string that indicates thename of the class used in the creation of its instances. In this case, it is “CIM IPProtocol-Endpoint”.

5.2.1.6 StaticIPAssignmentSettingData

It models IPv4 configuration for node interfaces. It derives from IPAssignmentSettingData andbelongs to the Network Common Model.


5.2. TIM CORE 117

• InstanceID (key, inherited from IPAssignmentSettingData), a string that identifies theIPv4 settings instance.

• IPv4Address (local class property), a string in IPv4 dotted format specifying the IPv4address for the interface.

• SubnetMask (local class property), a string in IPv4 dotted format specifying the maskto for the interface.

5.2.1.7 TIM StaticIPv6AssignmentSettingData

It models IPv6 configuration for node interfaces. It derives from IPAssignmentSettingData anddoes not belong to the CIM Schema.


• InstanceID (key, inherited from IPAssignmentSettingData), a string that identifies theIPv6 settings instance.

• IPv6Address (local class property), a string in IPv6 format specifying the address forthe interface.

• PrefixLength (local class property), an integer (in the 0 to 128 range) specifying thelength of the prefix.

5.2.1.8 Service

It models services and applications that the nodes in the scenario are running, e.g. dynamicprotocol daemons. It derives from EnabledLogicalElement and belongs to the CIM Core Model.

This class is weak to ComputerSystem (through the HostedService association, see Sec-tion 5.2.2.3). That means that the keys of ComputerSystem, Name and CreationClassNameproperties, are propagated using the names SystemName and SystemCreationClassNamerespectively and complement the keys defined in Service.

Service is not used in the TIM Core directly, except for the ForwadingService describedin Section 5.2.1.9. Actually, it is used to “link” the TIM Modules to the TIM Core throughinheritance (see Section 5.3 for details).


• Name (key, local class property), a string that identifies the service instance.

• CreationClassName (key, local class property), a string that indicates the name of theclass used in the creation of its instances. Service is an abstract class, so the value of thisproperty is set by its subclasses.

5.2.1.9 ForwardingService

It models node forwarding capabilities. It derives from NetworkService and belongs to theNetwork Common Model. This class inherits from Service the weakness to ComputerSystem(see Section 5.2.1.8).


• Name (key, inherited from Service), a string that identifies the forwarding service instance.


• CreationClassName (key, inherited from Service), a string that indicates the name ofthe class used in the creation of its instances. In this case, it is “CIM Forwarding”.

• ProtocolType (local class property), an enumeration that specifies which protocols isthe node able to forward, among IPv4, IPv6 and IPv4/IPv6.

5.2.1.10 TIM NextHopAddressedIPRoute

It models node static routes. It derives from NextHopIPRoute and does not belong to thestandard CIM Schema.


• InstanceID (key, inherited from NextHopRoute), a string that identifies the static routeinstance.

• AddressType (inherited from NextHopIPRoute), an enumeration specifying the routetype (either IPv4 or IPv6).

• DestinationAddress (inherited from NextHopRoute), a string specifying the route des-tination, formatted either in IPv4 or IPv6, depending on AddressType.

• DestinationMask (inherited from NextHopIPRoute), a string in IPv4 dotted format that,when AddressType corresponds to IPv4, is applied to DestinationAddress to specify thedestination subnet.

• PrefixLength (inherited from NextHopIPRoute), an integer (in the 0 to 128 range) that,when AddressType corresponds to IPv6, is applied to DestinationAddress to specify thedestination subnet.

• NextHopAddress (local class property), a string specifying the next hop address, eitherin IPv4 or IPv6, depending on AddressType.

5.2.2 TIM Core Associations

The TIM Core includes 11 associations, 5 from the Core Model, 2 from the Network CommonModel and 4 outside of the CIM Schema, defined in an ad hoc Extension Model which MOFrepresentation is shown in Appendix B.

5.2.2.1 SystemComponent

This association (derived from Component and belonging to the CIM Core Model) connects anode (ComputerSystem) and the testbed scenario (TIM TestbedScenario) to which it belongs.

5.2.2.2 HostedCollection

This association (derived from HostedDependency and belonging to the CIM Core Model) con-nects a link (TIM LinkConnectivityCollection) and the testbed scenario (TIM TestbedScenario)to which it belongs.

5.2. TIM CORE 119

5.2.2.3 HostedAccessPoint

This association (derived from HostedDependency and belonging to the CIM Core Model) con-nects an interface (IPProtocolEndpoint) and the node (ComputerSystem) to which it belongs.In this association, the IPProtocolEndpoint class is defined as weak to ComputerSystem (seeSection 5.2.1.5).

5.2.2.4 HostedRoute

This association (derived from HostedDependency and belonging to the Network Common Modelconnects a static route (TIM NextHopAddressedIPRoute) and the node (ComputerSystem) towhich it belongs.

5.2.2.5 ElementSettingData

This association (a root class belonging to the CIM Core Model) connects an IP address configu-ration (either StaticIPAlignmentSettingData or TIM StaticIPv6-AlignmentSettingData for IPv4and IPv6, respectively) and the interface (IPProtocolEndpoint) to which it belongs.

5.2.2.6 TIM LinkTransmissionElement

This association (derived from HostedDependency and not belonging to the standard CIMSchema) connects a transmission characteristics object (TIM TransmissionCharacteristics) andthe link (TIM LinkConnectivityCollection) to which it is applied. In this association, theTIM TransmissionCharacteristics class is defined as weak to TIM LinkConnectivityCollection(see Section 5.2.1.4).

5.2.2.7 TIM MemberOfLink

This association (derived from MemberOfCollection and not belonging to the standard CIMSchema) connects an interface (IPProtocolEndpoint) and the link (TIM LinkConnectivityCollec-tion) to which it belongs.

Note that, considering the multiplicity ranges in the association ends, an interface could notbelong to any link, which is valid to model loopback interfaces.

5.2.2.8 TIM LinkOrigin

This association (derived from Dependency and not beloning to the standard CIM Schema) spec-ifies the interface (IPProtocolEndpoint) playing the origin role for a transmission characteristicsobject (TIM TransmissionCharacteristics).

Note that, considering the multiplicity in the association ends, the transmission character-istics object could not have an origin, which perfectly makes sense when the associated linkis symmetric. In that case, the TIM LinkTransmissionElement (Section 5.2.2.6) is used, asdescribed in Section 5.2.

5.2.2.9 TIM LinkDestination

This association (derived from Dependency and not belonging to the standard CIM Schema)specifies the interface (IPProtocolEndpoint) playing the destination role for a transmission char-acteristics object (TIM TransmissionCharacteristics).


Note that, considering the multiplicity in the association ends, the transmission character-istics object could not have a destination, which perfectly makes sense when the associatedlink is symmetric. In that case, the TIM LinkTransmissionElement (Section 5.2.2.6) is used, asdescribed in Section 5.2.

5.2.2.10 HostedService

This association (derived from HostedDependency and belonging to CIM Core Model) connectsa service instance (either the ForwardingService included in TIM Core or any of the derivedservices included in TIM Modules, such as the OSPFService described in Section 5.3) and thenode (ComputerSystem) which runs that service instance. In this association, the Service classis defined as weak to ComputerSystem (see Section 5.2.1.8).

5.2.2.11 ForwardsAmong

This association (derived from ServiceSAPDependency and belonging to the Network CommonModel) connects a forwarding service instance (ForwardingService) and the interfaces (IPInter-faces) among which the forwarding function is provided.

5.3 TIM OSPF Module

TIM Modules define set of services which scenario nodes may run as subclasses of the CIM Serviceclass (Figure 5.3). Except for the simplest cases, such as the ForwardingService included in theTIM Core, services have an associated configuration which can be quite complex, includinga number of other associated classes. Considered as DMTF component pseudo-profiles (seeSection 4.3.4), the central class is the class derived from Service and the scoping class in theTIM Core autonomous pseudo-profile is the ComputerSystem to which the service is associated.

To illustrate the Modules mechanism, this section details the TIM OSPF Module. Figure 5.2shows it and its relation with the TIM Core as a particular case of Figure 5.3. From a high-levelperspective, TIM OSPF Module defines a OSPFService that models an OSPF dynamic routingprocess running on a node. The several different configuration elements related with OSPFprotocol, such as routes to distribute, area configuration, etc., are modeled with standard CIMclasses: OSPFAreaConfiguration, OSPFArea and RangeOfIPAddresses.

5.3.1 TIM OSPF Module Classes

The TIM OSPF Module includes 4 classes, all them belonging to the Network Common Model.As explained in Section 4.3.4, these classes have several properties, inherited across the sub-classing hierarchy, that are not needed for the TIM. Therefore, only the needed properties, i.e.the ones shown in Figure 5.2, are described.

5.3.1.1 OSPFService

It models the OSPF routing daemon service running in a given node. It derives from Serviceand belongs to the Network Common Model. This class inherits from Service the weakness toComputerSystem (see Section 5.2.1.8).


• Name (key, inherited from Service), a string that identifies the OSPF service instance.

5.3. TIM OSPF MODULE 121

Service

TIM Core

Service2

Conf21 ... Conf2N

Service1

Conf11...

Conf1N

ServiceM

ConfM1 ... ConfMN

TIM Module 1 TIM Module 2

...

TIM Module M

Figure 5.3: Linking between TIM Modules and TIM Core

• CreationClassName (key, inherited from Service), a string that indicates the name ofthe class used in the creation of its instances. In this case, it is “CIM OSPFService”.

5.3.1.2 OSPFArea

It models the information associated to an OSPF area, being the area ID the most importantparameter. It derives from RoutingProtocolDomain and belongs to the Network Common Model.


• Name (key, inherited from System), a string that identifies the OSPF area instance.

• CreationClassName (key, inherited from System), a string that indicates the name ofthe class used in the creation of its instances. In this case, it is “CIM OSPFArea”.

• AreaID (local class property), the area ID of this OSPF area, as defined in [Moy98].

5.3.1.3 OSPFAreaConfiguration

It models the OSPF area configuration associated to an OSPF service instance. To do so,it integrates area and range objects through AreaOfConfiguration and RangesOfConfigurationassociations (Section 5.3.2.2 and 5.3.2.3). It derives from LogicalElement and belongs to theNetwork Common Model.


• InstanceID (key, local class property), a string that identifies the OSPF configurationinstance.

5.3.1.4 RangeOfIPAddresses

It models the network range associated to an OSPF area to be advertised using the routingprotocol. It derives from SystemSpecificCollection and belongs to the Network Common Model.



• InstanceID (key, inherited from SystemSpecificCollection), a string that identifies therange of IPs instance.

• AddressType (local class property), an enumeration specifying wether the range refersto IPv4 or IPv6 addresses.

• StartAddress (local class property), the first address in the IP range.

• StopAddress (local class property), the last address in the IP range.

5.3.2 TIM OSPF Module Associations

The TIM OSPF Module includes 3 associations, all them belonging to the Network CommonModel.

5.3.2.1 OSPFServiceConfiguration

This association (derived from Dependency and belonging to the Network Common Model)connects an OSPF service instance (OSPFService) and its area configuration objects (OSPF-AreaConfiguration).

5.3.2.2 AreaOfConfiguration

This association (derived from Dependency and belonging to the Network Common Model)connects an OSPF area configuration object (OSPFAreaConfiguration) and the area information(OSPFArea).

5.3.2.3 RangesOfConfiguration

This association (derived from Dependency and belonging to the Network Common Model)connects an OSPF area configuration object (OSPFAreaConfiguration) and the IP ranges infor-mation (RangeOfIPAddresses).

This association uses a boolean property named EnableAdvertise (locally class property)which is aimed at switching on and off the advertisement of the IP range in a runtime WBEM-based management context. In our context, given that the TIM-to-TSM transformation is notbased on WBEM (as explained in Section 4.3.4), we can assume that the value of this propertyis always “true”.

5.4 TIM ad hoc Extension Validation

As introduced in Section 4.3.2 and detailed along this chapter, the TIM is composed by a subsetof classes in the CIM Schema (in particular, from the Core Model, Network and System CommonModels) and some additional ones in an ad hoc Extension Model.

CIM Schema part does not need validation because the DMTF ensures of it in each releaseof the CIM Schema. However, the ad hoc Extension Model, which definition in MOF is includedin Appendix B, needs to be validated in order to check it is formally correct and fits with theCIM Schema2.

2CIM Schema version 2.22.0 (released in June 2009) has been used to perform the tests herein described,although newer versions could be used without any problem given that DMTF ensures backward compatibilityin the 2.x branch.


In order to do so, a CIMOM (WBEM architectural component described in Section 3.4.1)has been set up, including the CIM-based repository. In order to implement this component,the publicly available WBEMServices3 CIMOM has been used. Then, the CIM Schema andthe ad hoc Extension Model have been successfully compiled using the mofcomp compiler thatcomes along with the CIMOM so assessing the correctness of implementation. This correspondsto steps 1 and 2 in Figure 5.4, the TIM ad hoc Extension included in the tim.mof file.

CIM-XMLCIMOM

CIM Schema2.22.0

conformsTotim.mof

mofcomp

TIM ad hocExtension

Model

cim_schema_2.22.0.mof

(1) (2)

Figure 5.4: TIM ad hoc Extension validation

5.5 Conclusions

This chapter has detailed the TIM Core model introduced in Chapter 4, describing all theircomposing classes and associations. In addition, it also describes one example of TIM Module:the TIM OSPF Module.

Note that instead of considering the complete CIM Schema, the TIM, defined as a DMTFpseudo-profile, is based on a subset of relevant concepts. Firstly, because it could be overwhelm-ing to consider and include every management object from each Common Model. Secondly,because only a subset of concepts is needed to solve the problem of automatic deploymentin reconfigurable testbeds and the inclusion of more than necessary would be overengineeringthe problem. In addition, the TIM conformance has been ensured checking with conventionalWBEM/CIM technology that the ah hoc Extension is completely aligned with standard DMTF’sCIM Schema.

It is worth mentioning that one of the keys of using CIM is that, given its broad coverage ofnetwork management information, it has been relatively easy to find equivalent (or semanticallyclose enough) CIM classes or associations for each concept needed in our problem domain. Onlyfor a very few concepts it has not been possible, considering in this case the derivation from CIMclasses with a close semantic and grouping all them in an ad hoc Extension Model, which MOFdefinition is provided in Appendix B. Actually, for the TIM OSPF Module no additional classor association have been needed, given that the existing CIM OSPF model in Network CommonModel suits perfectly.

Finally, in Chapter 4 several TIM Modules are mentioned as possible examples, some ofthem can be rather complex, e.g. TIM IMS Module, TIM GMPLS Module, TIM SmartFrog

3WBEMServices can be obtained from http://wbemservices.sourceforge.net.


Module, etc. However, it is out of the scope of this work modeling each imaginable extension,because that would be overwhelming. Instead, this chapter has illustrated how the mechanismworks and, to that end, the TIM OSPF Module has been defined. It is relatively simple (4classes and 3 associations), which is good for exposition purposes. It is also simple to implementand use, thus easing the validation performed in Chapter 6, but not so trivial to invalidate themodularity feasibility demonstrated which its development.

Chapter 6

Experimental Validation

6.1 Introduction

In order to check the feasibility of the scenario-based model-driven management architecturedescribed in Chapter 4 as main contribution of this dissertation and in order to assess itsapplicability to testbed configuration management in real cases, a validation test has beenperformed. Different scenarios have been modeled using the TIM (Core and OSPF Module)described in Chapter 5, to be deployed in two different testbeds, a VNUML-based testbedand the ADRENALINE testbed R©, using the scenario-based management tools specific for eachone. The two corresponding TIM-to-TSM transformations have been designed and implementedfollowing the general methodology described in Section 4.4.3.

6.2 Testbeds Used for the Validation

The two testbeds used for the validation tests are a VNUML-based one (implementing in just onephysical host) and the ADRENALINE testbed at CTTC premises. Both have been previouslydescribed in Sections 2.3.4.1 and 2.3.2 respectively, the present section focuses on their respectiveTSMs.

Considering Table 6.1, which summarizes the characteristics of both testbeds, it can beobserved that they are rather different in all the parameters. This fact has deliberately driventhe election of these particular testbeds for the validation, in order to assess the generality ofour approach. The only exception is that both TSMs are based on XML, but even so, they usedifferent syntaxis in their respective DTDs.

Testbed Implementation TSM type Managementtechnology tool

VNUML-based Virtualization XML VNUML(based on VNUML DTD

and VNUML OSPF DTD)

ADRENALINE Physical XML ADNETCONFinfrastructure (based on ADNETCONF DTD

and ADNETCONF OSPF-TE DTD)

Table 6.1: Validation testbeds summary

125

126 CHAPTER 6. EXPERIMENTAL VALIDATION

It is also worth noting that neither the VNUML-based testbed, the ADRENALINE test-bed, VNUML or ADNETCONF have been specifically developed for this validation. This isimportant, as our goal is to show how existing scenario-based testbeds can fit in the proposedconfiguration management architecture, without needing the development of new tools or mod-ifying the testbeds themselves.

In fact, VNUML and ADNETCONF are both two consolidated and rather complex tools,and the TSMs considered in this chapter are a subset of their complete functionality for thesake of simplicity (as shown in Figure 6.1). For example, developing a TIM Module for all theprocesses involved in the GMPLS control plane that ADNETCONF configures (currently seven)would involve a significant effort, without any valuable addition to the conclusions derived ofthe present validation.

TIM

VNUMLTSM

(Sect. 6.2.1)

VNUML complete functionality

ADNETCONF TSM

(Sect 6.2.2)

ADNETCONF complete functionality

Host configuration (<host>),automated execution andinstallation (<exec>, <filetree>)

Configuration of processesothers than OSPF (LRM,SNMP agents, RSVP-TE, etc.)

TIM-to-VNUML

TIM-to-ADNETCONF

Figure 6.1: VNUML and ADNETCONF TSMs as functionality subsets

6.2.1 VNUML-based Testbed TSM

The network topology is defined in a XML document, conforming to the VNUML DTD. Adetailed description of the language can be found at [GFF+09]. The topology XML documentis composed of three main sections: global, virtual networks and virtual machines.

• The global section (<global>) defines configuration elements that apply to the scenarioas a whole, such as the <version> tag (the particular version of the VNUML languagethat has been used to write the specification) or the <simulation name> tag (naming thescenario). It also includes default values to apply to every virtual machine, except whenoverridden in the corresponding virtual machine definition, using the same <console>,<filesystem> and <kernel> tags described below in the virtual machines section bullet.

• The virtual networks section defines the networks that interconnect virtual machinesamong them or with the host network interfaces by means of the <net> tag. Virtualnetworks are implemented by means of software virtual bridges running on the host ma-chine.

• The virtual machines section describes by means of the <vm> tag each virtual machineincluded in the scenario. The language enables describing their main characteristics interms of the kernel and the filesystem they run (<kernel> and <filesystem> tags) and theway virtual machines are accessed (<console> tag). It also defines the network interfaces

6.2. TESTBEDS USED FOR THE VALIDATION 127

of the virtual machine (<if> tag) and the addresses associated with them, either IPv4 orIPv6 (<ipv4> and <ipv6> tags). Finally, it includes the definition of IP routes (<route>tag) and forwarding capabilities (<forwarding> tag).

Apart from the topology description, a second XML document describes the OSPF configu-ration, conforming to VNUML OSPF DTD). It is structured in as many <vm> tags as virtualmachines are executing OSPF processes. Within each <vm>, a set of <network> tags definethe different network prefixes to be announced (using the <ip> tag) and their correspondingOSPF area (using the <area> tag). Additional information can be included for each <vm>:the location of the binary files implementing the processes (using <zebra bin> and <ospfd bin>tags); and some general attributes related with the configuration of the daemon (<zebra> tag),e.g. access password for the interactive console. As can be deduced by the tag names, the OSPFimplementation used by VNUML is based in Zebra/Quagga1.

6.2.2 The ADRENALINE Testbed TSM

The TSM is composed of two XML documents that correspond to the formal representation ofthe scenario that is understandable by the ADNETCONF processing engine.

One of the XML documents, conforming to ADNETCONF DTD, describes the logical net-work topology. It has two main sections, for the description of nodes (<nodes>) and links(<links>) respectively.

• Each node within the <nodes> section, specified with a <node> tag, includes the followinginformation: IP address for the ADRENALINE management network (<m ip>), loopbacknode IP address (<lo ip>) and pathnames for the binaries that implement the processesin the control plane (e.g. <ospfd bin>). The ADRENALINE management network isan O&M network which connects the management node in which ADNETCONF runs toanyone of the testbed OCCs. This network is considered preconfigured and independentto the scenario deployment process.

• Each link within the <links> section, specified using a <link> tag, describes the two linkpeers (<peer>) and the QoS constraints that ADNETCONF has to set for that link whenthe scenario is deployed (<qos>). Each link in ADRENALINE is implementation on a/30 subnet (shown as A network in Figure 6.2) ontop a GRE tunnel [HLFT94] that usesalso a /30 subnet (shown as B network in Figure 6.2). The GRE is in sequence mapped toa per-link VLAN2. Both IP ranges never overlap, e.g. if scenario nodes are using subnetswithin the 10.0.0.0/16 range then GRE subnets could be in the 10.10.0.0/16 range.

Note that ADRENALINE only allows PPP links, which make sense considering the kindof experiments to which the testbed is addressed. Each <peer> includes the node andIP to use in that end. In addition, the first <peer>, includes the information regardingthe underlaying GRE subnet (net attribute in <vlan connection>) and the VLAN to use(<vlan>). Regarding QoS constraints, the delay (<delay>), loss probability (<drop>)and duplication probability (<dup>) can be specified.

1http://www.zebra.org/ and http://www.quagga.net/ respectively.2GRE was used in the past to implement QoS emulation through an inline NISTNet [CS03] emulation node.

Currently, QoS emulation is implemented using Netem [Hem05] in the peer nodes directly, i.e. inline emulationnode is no longer used. Thus, the tunnel is not necessary and the PPP link (i.e. A network in Figure 6.2) could beestablished on the VLAN directly. However, GRE approach has been preserved to keep backward compatibilityin the ADNETCONF tool.


VLAN (ID V)

ADRENALINE physicalinterconnection layer-2 backbone

IP(IP A1)

IP(IP B1)

Routingprocess

IP(IP A2)

IP(IP B2)

OCC O1 OCC O2

Routingprocess

GRE

OSPF session

IP connectivity

Scenario scope

Scenariounderlying

implementation

A1 and A2 belong the same /30 subnetB1 and B2 belong the same /30 subnetAX and BY do not overlap for any X and Y

Figure 6.2: ADRENALINE PPP implementation detail

• Each node includes an unique identifier (id attribute in <node>) used to match to thenode attribute in <peer> within the links in which the node takes part.

The other XML document, conforming to ADNETCONF OSPF-TE DTD, describes theconfiguration of the OSPF processes. It is structured in as many <ospf> tags as nodes inthe scenario, the node attribute in <ospf> identifies to which one the configuration belongs.Within each <ospf>, a set of <network> tags define network prefixes (in the tags content)and area (area attribute in <network>). Additional information can be included to configurethe routing process in each node. As ADNETCONF OSPF-TE implementation is based onZebra, this information includes the path of the log files (<zebra log> and <ospf log>) and thepassword for the interactive console (<password>).

It is worth mentioning that, although the routing process running in ADRENALINE isGMPLS OSPF-TE and it is able to distribute specific information on wavelengths, this validationdoes not consider this functionality as it is based on basic OSPF. Note that the TIM OSPFModule being used and described in Section 5.3 does not considers GMPLS, as explained inSection 5.5.

6.3 Validation Set

The validation set consists of three scenarios: basic, a simple 5-node IP network; nsfnet, re-sembling the NSFNet topology [NSF10]; and rediris, modeling RedIRIS, the Spanish nationalresearch and education network [Red10]. The different scenarios are shown in Figure 6.3.

Note that nsfnet and rediris are large networks in which static routes would be very hardto configure and maintain, so dynamic routing is used. In particular, OSPF is being used. Onthe contrary, basic scenario is small and aimed at simplicity, so a static routing approach ispreferred. In addition, nsfnet and rediris model long distance links so a specification of the linkQoS (transmission delays) is also included, e.g. the IL-WA link in nsfnet models a distance ofabout 2800 km, while IX-CAT in rediris is around 500 km. The numbers shown close to thelinks in Figure 6.3 are the delays (in milliseconds) to use in each one.

6.4. VALIDATION EXPERIMENT 129

nsfnet scenario(14 nodes, 21 PPP links,

OSPF routing)

WA

CA1

CA2

UT

CO

TX

NE IL

GA

DC

NJ

NY

MI

PA

GAL

AST CAN PVCNAV

CATARA

MAD IX

EXT

AND

CLM

CYL

MURTEF

PAL

VAL

BAL

RIO

basic scenario(5 nodes, 3 multipoint links,

static routing)

rediris scenario(19 nodes, 31 PPP links,

OSPF routing)

3

3

156

3.757.5

3

15

3

15

36

7.5

35.25

363.75

6

2 10

10

3

22

33

33

4

3

1 45

2

3 23

22

224

3

3

2

3

2

2

3

6

2

Figure 6.3: Validation set scenarios

The validation set characteristics are summarized in Table 6.2 including the number of in-stances in each TIM class that each scenario is using. Scenarios not using link QoS modelingdo not include TIM TransmissionCharacteristics. Scenarios not using OSPF do not include anyclass in the TIM OSPF Module and those using static routing include TIM NextHopAddressedIPRoute.However, although no scenario includes the complete set of classes an associations in the TIMCore and TIM OSPF Module shown in Figure 5.2 at a time, it is worth noting that every classor association is included in at least one of the scenarios. Thus, the scenario set utilized providesthe complete validation of the TIM.

Considering that some of the scenarios are quite large (in particular, the rediris scenariohas approximately 1,000 instances), it can also be shown with this validation that TIM and themodel-driven configuration management architecture built around it can cope with non trivialscenarios addressed to actual experimentation.

6.4 Validation Experiment

The validation experiment (outlined in Figure 6.4) consists in generating the TSMs correspond-ing to the three scenarios in the validation set for the two testbeds, five TSMs in total3. Itinvolves several activities performed by the different roles related with model-driven configura-tion management described in Section 4.5:

1. Initially, the TIM-to-TSM transformation developer implements the TIM-to-VNUML and

3It makes no sense to deploy the basic scenario in ADRENALINE, as explained in Section 6.4.5.


basic nsfnet rediris

Nodes 5 14 19

PPP Links 0 21 31

Multipoint links 4 0 0

Loopback interfaces 0 14 19

TIM Core classesTIM TestbedScenario 1 1 1ComputerSystem 5 14 19TIM LinkConnectivityCollection 3 21 31TIM TransmissionCharacteristics - 21 31IPProtocolEndPoint 7 56 81StaticIPAssignmentSettingData 7 56 81StaticIPv6AssignmentSettingData 7 - -ForwardingService 2 14 19TIM NextHopAddressedIPRoute 10 - -

TIM Core associationsSystemComponent 5 14 19HostedCollection 3 21 31HostedAccessPoint 7 56 81HostedRoute 10 - -ElementSettingData 14 56 81TIM LinkTransmissionElement - 21 31TIM MemberOfLink 7 42 62TIM LinkOrigin - 21 31TIM LinkDestination - 21 31HostedService 2 14 19ForwardsAmong 4 42 62

TIM OSPF classesOSPFService - 14 19OSPFAreaConfiguration - 14 19OSPFArea - 14 19RangeOfIPAddresses - 56 81

TIM OSPF associationsOSPFServiceConfiguration - 14 19AreaOfConfiguration - 14 19RangesOfConfiguration - 56 81

TOTAL INSTANCES 84 673 968

Table 6.2: Validation set summary


nsfnetbasic

BasicVNUML

TSM

NSFNETVNUML

TSM

BasicADNETCONF

TSM

NSFNETADNETCONF

TSM

rediris

RedIrisVNUML

TSM

RedIrisADNETCONF

TSM

TIM-to-ADNETCONF23 transformation rules(detailed in Figure 6.8)

TIM-to-VNUML27 transformation rules(detailed in Figure 6.8)

VNUML ADNETCONF

physicalhost

baseMgtAddressbaseVlan…(7 more)

ADNETCONFtestbed parameters

(Table 6.4)

kernel

ospfd

filesystem

defaultKerneldefaultFilesystemospfdBinPath…(11 more)

VNUML testbeds parameters (Table 6.3)

… … …

The ADRENALINE testbed ® (simplified)

…OCC0

OCC73

Figure 6.4: Validation experiment


TIM-to-ADNETCONF transformations (described in Section 6.4.1 and 6.4.2 respectively).

2. Then, the scenario designer creates the different scenarios in the validation set, accordingto the TIM scenario generation workflow (Section 6.4.3).

3. Next, the testbed administrator executes the transformation in order to produce TSMscenarios, according to the TSM scenario generation workflow (Section 6.4.4)

4. Finally, the testbed administrator deploys the scenarios, according to the scenario deploy-ment workflow (Section 6.4.5)

6.4.1 TIM-to-VNUML Transformation

This section describes the design of the TIM-to-TSM transformation for the VNUML case,applying the methodology described in Section 4.4.3:

1. TSM formalization. The VNUML TSM is defined in natural language, summarized inSection 6.2.1. It is based on XML, so the algorithm described in Section 4.4.3 to formalizeXML-based TSMs can be applied, considering VNUML DTD and VNUML OSPF DTD,producing the result shown in Figure 6.54. Note that there are two separate root classes,Vnuml and OspfConf, each one corresponding to root elements in the two different XMLdocuments considered in the VNUML TSM.

2. TIM-to-TSM associations definition. In this step, the different classes in the TSMformalized in the previous step are analyzed, to find the corresponding classes in TIM Coreand TIM OSPF Module and which information has to be considered as testbed parameters.

Considering the Vnuml root:

• There is one Vnuml and one Global instance for each given TIM TestbedScenario(Rule #1). Actually, both are structural classes, used to compose other classes.

• The SimulationName text property is set using Name in TIM TestbedScenario(Rule #2). The other classes within Global are highly related with the deploymentplatform (i.e. the virtualized testbed) so they are not produced from TIM and actuallyare derived from testbed parameters in the following way:

– The text property in Version is set with the particular version of the VNUMLtool installed in the testbed.

– The exec mode property in VmDefaults will depend on the capabilities of thedeployment platform. In some cases, the virtual machine kernel in the VNUMLinstallation could forbid some execution mode possibilities.

– The kernel, filesystem and console mode for virtual machines (configured withthe properties in Kernel, Filesystem and Console) depend on the VNUML in-stallation, e.g. different installations could use different kernel versions. In orderto simplify in the validation experiment, we consider the same kernel, filesystem

4In order to follow the usual UML style in class names some slight modifications to the algorithm have beendone. In particular, the first letter in each class name has been capitalized although VNUML uses lowercase tagnames, e.g. Vnuml instead of vnuml. Additionally, underscores have been removed, e.g. SimulationName insteadof simulation name. Finally, given that “if” is a reserved word in the transformation language we will use (ATL)the <if> tag in VNUML is modeled with the Intf class.


Vnuml

Global

name: Stringmode: String

Net

name: String

Vm_text: String

Version

_text: String

SimulationName

Automac

type: String

VmMgmt

exec_mode: String

VmDefaults

_text: Stringtype: String

Filesystem

_text: String

Kernel

_text: Stringid: String

Console

_text: Stringtype: Stringgw: String

Route

type: String

Forwarding

1

*

id: Stringnet: String

Intf

_text: Stringmask: String

Ipv4


Ipv6

1

*

11

1

1

111

1

1

0..1

0..1

0..1

0..1

0..1

0..1

0..1

0..1

*

0..1

*

11

*

*

* *

0..1

OspfConf

_text: String

ZebraBin

name: Stringtype: Stringsubtype: String

Vm

_text: String

OspfdBin

hostname: Stringpassword: String

ZebraNetwork


Ip

_text: String

Area

1

1

1

1

1 1

0..1 0..1

VNUML DTD VNUML OSPF DTD

*1..

*1..

Figure 6.5: VNUML TSM

and console mode will be used by all virtual machines, thus considering Kernel,Filesystem and Console aggregated by VmDefaults5. Alternatively, these test-bed parameters could be used on a per virtual machine basic, as the TSM inFigure 6.2.1 allows that possibility, e.g. structuring them within a hash table sofor each different virtual machine a different configuration set is assigned. In thatcase, Kernel, Filesystem and Console would be aggregated by the correspondingVm.

– The Automac class is related with the creation of virtualized infrastructure inthe deployment platform. When an instance of this class exists, MAC addresseshave to be automatically assigned by VNUML at deployment time.

– The type property in VmMgmt is configured with the network used by VNUMLto manage virtual machines. Therefore, is a deployment related configurationwhich is set using a testbed parameter6.

• Each Vm instance corresponds to one instance of ComputerSystem in TIM (Rule #3).Similarly, each Net instance corresponds to one TIM LinkConnectivityConnectioninstance (Rule #4).

• Regarding Net properties, name is set using InstanceID property in TIM Link-ConnectivityCollection (Rule #5). The Net mode is a testbed parameter, due to itdepends on the testbed configuration, e.g. some VNUML-based testbeds are basedin user processes implementing virtual networks, other in kernel-level devices.

5An additional simplification is to use just one console mode, which automatically sets the id property inConsole to 0.

6Note in Figure 6.5 that VmMgmt is optional so the instance of this class is created only when the parameterhas been defined.


• The name property in Vm is set using the Name property in ComputerSystem (Rule#6). Regarding the classes within Vm:

– Each Forwarding instance corresponds to one instance of ForwardingService inTIM (Rule #7), mapping ProtocolType to type (Rule #8).

– Each Route instance corresponds to one instance of TIM NextHopAddressedIP-Route (Rule #9). The type property is set using AddressType (Rule #10), gwusing NextHopAddress (Rule #11). Finally, the text property is composedby a combined mapping of DestinationAddress and DestinationMask orPrefixLength (for IPv4 or IPv6 respectively) (Rule #12).

– Each Intf instance corresponds to one instance of IPProtocolEndpoing (Rule#13). The id property is structural, i.e. each Intf within the same Vm has adifferent id, starting from 1. The net property is set using the InstanceID prop-erty of the TIM LinkConnectivityCollection associated to the interface throughthe TIM MemberOfLink association, except when that association does not ex-ists (i.e. the case of a loopback interface) in which case the “lo” string is assigned(Rule #14). Within the interface, each Ipv4 instance corresponds to one in-stance of StaticIPAssignmentSettingData (Rule #15), mapping IPv4Address totext (Rule #16) and SubnetMask to mask (Rule #17). Similarly, each Ipv6

instance corresponds to one instance of TIM StaticIPv6AssignmentSettingData(Rule #18), mapping IPv6Address to text (Rule #19) and PrefixLength tomask (Rule #20).

Considering the OspfConf root:

• There is one OspfConf instance for each given TIM TestbedScenario (Rule #21).Actually, it is a structural class, used to compose other classes.

• Each Vm instance corresponds to one instance of OSPFService in TIM (Rule #22),which name property is set using the Name of the ComputerSystem associated toOSPF service through the HostedService association) (Rule #23). Regarding, thetype and subtype properties, they correspond to the particular software routingsuite implementing the OSPF daemons, which depends on the software installationin the virtual machine filesystem, so they are considered testbed parameters.

Aggregated by Vm:

– The text properties in ZebraBin and OspfdBin also depend on the softwarerouting suite, so they are testbed parameters7.

– The hostname in zebra is set using the Name of the ComputerSystem associ-ated to the OSPFService through the HostedService (Rule #24). Regarding thepassword property, it depends on the local configuration of the software, so itis a testbed parameter.

– Each pair of Ip and Area (aggregated by Network, which is actually a structuralclass) corresponds to a combination of OSPFArea and RangeOfIPAddresses asso-ciated through an OSPFAreaConfiguration instance through the AreaOfConfig-uration and RangesOfConfiguration associations, respectively (Rule #25). The

7Note in Figure 6.5 that ZebraBin and OspfdBin are optional so the instances of these classes are created onlyif the corresponding parameters have been defined.


text and mask properties in Ip are derived from the AddressType, Star-tAddress and EndAddress in the RangeOfIPAddresses instance (Rule #26),while the text property in Area is derived from the AreaID property in theOSPFArea instance (Rule #27).

After this analysis, it can be seen that some TIM classes are not used by VNUML. In partic-ular, VNUML is not capable of modifying the transmission characteristics of networks, soTIM TransmissionCharacteristic and all its associations (TIM Link-TransmissionElement,TIM LinkOrigin and TIM LinkDestination) are not considered. Therefore, instances ofthose classes are “pruned” in scenarios using them, i.e. rediris and nsfnet. In addition,note that the MaxConnections property in TIM LinkConnectivity-Collection is not used,given that VNUML does not give any special semantics to networks with a limited numberof interfaces, e.g. PPP links.

A summary of the testbeds parameters to use in the TIM-to-VNUML transformation isshown in Table 6.3.

Testbed parameter Type Mapping

version String Version text

defaultExecMode String VmDefaults exec mode

defaultFilesystemType String Filesystem type

defaultFilesystem String Filesystem text

defaultKernel String Kernel text

defaultConsole String Console text (id is always set to 0)

automac Boolean If true, include an Automac instance

mgmtType String VmMgmt type (instance of VmMgmt createdonly if the parameter is defined)

netMode String Net mode

ospfType String Vm (in VNUML OSPF DTD tree) type

ospfSubType String Vm (in VNUML OSPF DTD tree) subtype

zebraBinPath String ZebraBin text (instance of ZebraBin createdonly if this parameter is defined)

ospfdBinPath String OspfdBin text (instance of OspfdBin createdonly if this parameter is defined)

ospfPassword String Zebra password

Table 6.3: Testbed parameters for TIM-to-VNUML transformation

3. Construction of the TIM-to-TSM rules. The transformation rules have been spec-ified using the ATL language (described in Section 3.3.2.5). In order to simplify theimplementation, two ATL modules have been created, implementing the correspondingModel2Model transformations:

• Transformation definition including Rules #1 to #20 (TIM2VNUML.atl in AppendixC.1.1) to produce the TSM part corresponding to the XML document conforming toVNUML DTD (Vnuml root).


• Transformation definition including Rules #21 to #27 (TIM2VNUMLOspf.atl in Ap-pendix C.1.2) to produce the TSM part corresponding to the XML document con-forming to VNUML OSPF DTD (OspfConf root).

Both transformations are based on a set of helpers (TIMHelper.atl in Appendix C.3.1)implementing functions to ease the navigation on the TIM objects. These helpers are alsoused by the TIM-to-ADNETCONF transformation described in Section 6.4.2.

Regarding the modeling of the testbed parameters, the set specified in Table 6.3 is con-sidered the second model that merges the TIM scenario to produce the TSM. They aremodeled using CIM in order to not increase the complexity adding an additional meta-model, considering that the CIM Schema will be already injected to support TIM, asexplained in Section 6.4.4.1. In particular, the SettingData class is extended with theVNUML TestbedParameters subclass which to include all the parameters in Table 6.3 asproperties.

The methodology described in Section 4.4.3 states that a relational transformation lan-guage should be used, either QVTr or ATL. Considering the maturity and stability level ofthe current software implementations (see Section 3.3.2.6), we have chosen ATL. However,it should be stressed that although in the moment of this writing this is the best imple-mentation option, it could change in the future without affecting neither the model-drivenconfiguration management architecture nor the TIM-to-TSM transformation methodologybecause both are independent of the particular transformation language used.

4. Format adaptation. VNUML is not able to process MOF-based models directly, so aformat adaptation step is required. Given that the Model2Text transformation based onthe XML metamodel (shown in Figure 4.4) can be easily implemented with a well-knownATL query, indirect adaptation is used, using a Model2Model transformation. This isimplemented in the VNUML2XML.atl and VNUMLOspf2XML.atl modules to convertVNUML TSM scenarios to instance models representing XML documents.

Actually, the design of this transformation is simple, using the following ATL pattern,which implements a quite straightforward top-down algorithm to navigate the TSM com-position relationships in the TSM class-trees generating the corresponding elements in theXML model for each tree node8:

rule C-Rule {

from

i: VNUML!C

to

C: XML!Element (

name <- ’C_name’,

children <- Sequence {CAtt_1,...,CAtt_M,CText,

VNUML!CPart1.allInstances()->select(filter_1)->collect (e | thisModule.resolveTemp(e,’CPart1’)),

...

[a similar line is included for each class aggregated by C; CPart_i names the aggregated class.

’filter_i := e | i.cpart_i->includes(e)’ when cpart_i aggregation multiplicity is greater than 1;

or ’filter_i := e | i.cpart_i = e’ when cpart_i aggregation multiplicity is one]

...

VNUML!CPartM.allInstances()->select(filter_M)->collect (e | thisModule.resolveTemp(e,’CPartM’))

8Two remarks have to be make on this fragment. First, for classes representing the root in the XML document,i.e. Vnuml and OspfConf, XML!Root is used instead of XML!Element. Second, “C name” does not correspondto the exact name of the class, but with the inverse application of the algorithm described in Footnote 4 in thischapter, e.g. the “C name” for SimulationName is “simulation name”.


}

),

[one clause as the following for each attribute]

CAtt_1: XML!Attribute (

name <- ’att_1’,

value <- i.att_1

),

...

[one clause as the following if C has an associated _text property]

CText: XML!TextNode (

value <- i._text

)

}

[recursively include a similar transformation rule for CPart1 to CPartN classes]

rule CPart_1-Rule {

from

i: VNUML!CPart_1

to

...

}

Without going into deeper OCL or ATL details (see [ATL06]), this pattern creates an XMLelement in the output XML document model for each class (named C in the fragmentabove) in the input VNUML TSM. The children of the XML element are set with theattributes corresponding to that tag, taking the proper values from the VNUML TSM,and, eventually, the text content in the case of not empty tags. In addition, OCL collectorsare set to gather all the tags corresponding to the classes aggregated by C, i.e. CPart1to CPartM. The resolveTemp ATL function provides all the references to XML elements(tags) generated by the corresponding VNUML TSM elements (classes). Actually, thisresult is filtered with an OCL expressions that ensures that only the right tags (i.e. theactual instances aggregated by the given instance of C being transformed) are included.

6.4.2 TIM-to-ADNETCONF Transformation

This section describes the design of the TIM-to-TSM transformation for the ADNETCONFcase, applying the methodology described in Section 4.4.3:

1. TSM formalization. The ADNETCONF TSM is defined in natural language, sum-marized in Section 6.2.2. As with VNUML, it is based on XML, so the algorithm des-cribed in Section 4.4.3 to formalize XML-based TSMs can be also applied, consideringADNETCONF DTD and ADNETCONF OSPF-TE DTD, producing the result shown inFigure 6.69. Note that there are two separate root classes, AdrenalineNetconf and Ospf-Conf, corresponding to root elements in the two different XML documents considered inthe ADNETCONF TSM.

2. TIM-to-TSM associations definition. In this step, the different classes in the TSMformalized in the previous step are analyzed, to find the corresponding classes in TIM Coreand TIM OSPF Module and which information has to be considered as testbed parameters.

Considering the AdrenalineNetconf root:

9The same observations mentioned in Footnote 4 in this chapter also applies.


name: String

AdrenalineNetconf

Nodes Links

id: String

Node

_text: String

MIp

_text: String

LoIp

_text: String

ZebraBin

_text: String

OspfdBin

Link

node: Stringvlan_dev: String

Peer Qos

_text: String

VlanGre

_text: String

Name

_text: String

Ip

_text: String

Delay

_text: String

Drop_text: String

Dup

1

1 1

* *

1 1

1

1 1

1

1 1

0..1

0..1

0..1

0..1

1

1

net: String

VlanConnection0..1

1

1

1 1

1

1

OspfConf

node: String

Ospf

_text: String

Password_text: String

OspfLog

_text: String

ZebraLog

_text: Stringarea: String

Network

1

*

0..1

1

0..1 0..1 *

ADNETCONF DTD ADNETCONF OSPF-TE DTD

*1..

Figure 6.6: ADNETCONF TSM


• There is one instance of AdrenalineNetconf, Links and Nodes for each given TIM Test-bedScenario (Rule #1). The name property in AdrenalineNetconf is set using Namein TIM TestbedScenario (Rule #2). Links and Nodes are actually structural classes,used to compose other classes (Link and Node respectively)

• Each Node instance corresponds to one instance of ComputerSystem in TIM (Rule#3). The id property in Node is set using the Name property in ComputerSystem(Rule #4). Regarding the classes within Node:

– The text property in MIp is an address in the ADRENALINE managementnetwork. Therefore, it is a testbed parameter.

– The text property in LIp is set using IPv4Address in StaticIPAssignmentSet-tingData associated to the loopback IPProtocolEndpoint10 through the Element-SettingData association, which, in sequence, is associated to the ComputerSystemthrough the HostedAccessPoint association; if there is no associated loopback in-terface, text gets empty (Rule #5).

– The text properties in ZebraBin and OspfdBin are set with the pathnamesof the binaries implementing the OSPF routing software. They depend on thesoftware installation in ADRENALINE OCCs, so they are testbed parameters.

• Each Link instance corresponds to one instance of TIM LinkConnectivityCollectionin TIM with MaxConnections equal to 2, that is PPP links (Rule #6). Therefore,there are exactly two IPProtocolEndpoint instances associated to the TIM LinkCon-nectivityCollection through the TIM MemberOfLink association. Regarding the classesaggregated by Link :

– A first instance of Peer sets its node property using Name in the ComputerSys-tem associated with the first IPProtocolEndPoint through the HostedAccessPointassociation (Rule #7).The VlanConnection aggregated by this Peer has a net property which is setusing a /30 network address to implement the GRE tunnel supporting the sce-nario PPP link (see Section 6.2.2 regarding how PPP links are implemented inADRENALINE). This network address is not related with the scenario IPs usedin the PPP link ends and specified with StaticIPAssignmentData. Actually, itdepends on IP ranges available in the testbeds, so it is a testbed parameters.VlanConnection aggregates in sequence two classes:

∗ Vlan, which text property depends on the VLAN actually used to implementthe scenario PPP link. Given it depends of the available VLANs in thetestbed infrastructure, it is a testbed parameter.

∗ Gre, which is a structural class composed by Name and Ip. The text prop-erty in Name is a globally unique identifier for the GRE generated by AD-NETCONF internally (following the format “greN ”, where N is a monotoni-cally increasing counter). The text property in Ip is set using IPv4Addressin the StaticIPAssignmentSettingData associated to the first IPProtocolEnd-point through the ElementSettingData association (Rule #8).

10Defined in this case as the interface which is not associated with any TIM LinkConnectivityCollection throughthe TIM MemberOfLink association. As much as one loopback interface can be defined per ComputerSystem inADRENALINE.


– A second instance of Peer11 sets its node property using Name in the Comput-erSystem associated with the second IPProtocolEndPoint through the HostedAc-cessPoint) association (Rule #9).The VlanConnection aggregated by this Peer does not set the net property.It aggregates in sequence a Gre class, composed by Name and Ip. The textproperty in Name is set as described above for the first Peer. The text propertyin Ip is set using IPv4Address in the StaticIPAssignmentSettingData associatedto the second IPProtocolEndpoint through the ElementSettingData association(Rule #10).

– The vlan dev property in both first and second Peer instances depends on thephysical device used in OCCs to build the VLAN that supports the link. Itdepends on the OCC operating system, so it is a testbed parameter.

– Each Qos instance corresponds to one instance of TIM TransmissionCharacteris-tics (Rule #11). The different classes that can appear aggregated by Qos are:

∗ Delay if the DelayMean in the TIM TransmissionCharacteristics instancehas been set (Rule #12). In that case, text is set using DelayMean (Rule#13).

∗ Dup if the DuplicationProbabilityValue in the TIM TransmissionCha-racteristics instance has been set (Rule #14). In that case, text is set usingDuplicationProbabilityValue (Rule #15).

∗ Drop if the LossProbabilityValue in the TIM TransmissionCharacteristicsinstance has been set (Rule #16). In that case, text is set using LossProb-abilityValue (Rule #17).

Considering the OspfConf root:

• There is one OspfConf instance for each given TIM TestbedScenario (Rule #18).Actually, it is a structural class, used to compose other classes.

• Each Ospf instance corresponds to one instance of OSPFService in TIM (Rule #19),which node property is set using Name in the ComputerSystem associated to OSPFservice through the HostedService association (Rule #20).

Aggregated by Ospf :

– text in ZebraLog and OspfLog are set using the pathname to the log files for theprocesses implementing the OSPF-TE protocol. They depend on the softwareinstallation in ADRENALINE OCCs, so they are testbed parameters. Regardingthe text property in Password, it depends of the local configuration of thissoftware, so it is a testbed parameter.

– Each Network corresponds to a combination of OSPFArea and RangeOfIPAd-dresses associated through an OSPFAreaConfiguration instance through the Area-OfConfiguration and RangesOfConfiguration associations, respectively (Rule #21).The text property in Network is derived from the AddressType, StartAd-dress and EndAddress in the RangeOfIPAddresses instance (Rule #22), whilethe area property in Area is derived from the AreaID property in the OSPFAreainstance (Rule #23).

11Note that, due to the semantics behind the ADNETCONF TSM there are two differences regarding the firstPeer instance: VlanConnection does not set the net property and the Vlan instance (aggregated by VlanCon-nection) is not used.


After considering this mapping, it can be seen that some TIM classes and properties are notused by ADNETCONF. In particular, the following are ignored: TIM NextHopAddressed-IPRoute, because ADRENALINE scenarios always rely on OSPF-TE dynamic routing;Forwarding, as OCCs always have forwarding enabled, so there is no need to explicitlyuse that class; and TIM StaticIPv6AssignmentSettingData, due to ADRENALINE onlyuses IPv4. In addition, some of the properties in TIM TransmissionCharacteristics arenot used (e.g. DisorderingProbabilityValue, MTU, etc.) given that the networkemulation implemented in the testbed does not consider them due to experiments carriedout in ADRENALINE does not require them. Finally, experiments in ADRENALINEalways consider PPP links, so if the value of MaxConnections is greater than two (andthe omission of the property means no limits implicitly, as mentioned in Section 5.2.1.3)the link is removed. This make the basic scenario useless for ADRENALINE.

Compared to the VNUML transformation described in Section 6.4.1, the pruning done byTIM-to-ADNETCONF is stricter. However, this is a consequence of the nature of bothtestbeds. While ADRENALINE is very focused in some kind of experiments, VNUML isa general purpose tool that has to support a wider range of networking scenarios.

A summary of the testbeds parameters to use in the TIM-to-ADNETCONF transformationis shown in Table 6.4.

Testbed parameter Type Mapping

baseMgtAddress Integer (32 bits) Starting address to set MIp text(increasing it for each Node, in sequence)

zebraBinPath String ZebraBin text

ospfdBinPath String OspfdBin text

baseConnectAddress Integer (32 bits) Starting /30 network address used to setVlanConnection net in the first Peer(increasing it for each Link, in sequence)

baseVlan Integer Starting VLAN ID used to set Vlan textin the first Peer (increasing it for eachLink, in sequence)

vlanDev String Peer vlan dev

zebraLogPath String ZebraLog text

ospfLogPath String OspfLog text

password String Password text

Table 6.4: Testbed parameters for TIM-to-ADNETCONF transformation

3. Construction of the TIM-to-TSM rules. As with VNUML, the transformation ruleshave been specified using the ATL language. The arguments supporting that decision arethe same than the ones exposed in Section 6.4.1. In order to simplify the implementa-tion, two ATL modules have been created, implementing the corresponding Model2Modeltransformations:

• Transformation definition including Rules #1 to #17 (TIM2ADNETCONF.atl inAppendix C.2.1) to produce the TSM part corresponding to the XML documentconforming to ADNETCONF DTD (AdrenalineNetconf root).


• Transformation definition including Rules #18 to #23 (TIM2ADNETCONFOspf.atlin Appendix C.2.2) to produce the TSM part corresponding to the XML documentconforming to ADNETCONF OSPF-TE DTD (OspfConf root).

Both transformations are based on a set of helpers (defined in TIMHelper.atl in Ap-pendix C.3.1) implementing functions to ease the navigation on the TIM objects. Thesehelpers are also used by the TIM-to-VNUML transformation described in Section 6.4.1.

Regarding the modeling of the testbed parameters, the set of testbed parameters specifiedin Table 6.4 is considered the second model that merges the TIM scenario to produce theTSM. The same approach than in the TIM-to-VNUML case has been used, deriving a AD-NETCONF TestbedParameters class from CIM SettingData to include all the parametersin Table 6.4 as properties.

4. Format adaptation. ADNETCONF is not able to process MOF-based models directly,so the same indirect transformation approach used in the TIM-to-VNUML case (describedin Section 6.4.1) has been considered here. In this case, the Model2Model transformationto convert from ADNETCONF TSM to XML documents is implemented in the ADNET-CONF2XML.atl and ADNETCONFOspf2XML.atl ATL modules.

6.4.3 TIM Scenario Generation Workflow

The three scenarios in the validation set have been designed in DMTF’s MOF. Then, they havebeen compiled into the CIMOM in order to check they conform with the TIM. In order todo so, the setup for the TIM ad hoc Extension described in Section 5.4 can be reused. Eachscenario is modeled separately in a file (basic.mof, nsfnet.mof and rediris.mof ), then compiledwith mofcomp, as shown in Figure 6.7.

CIM-XMLCIMOM

nsfnetbasic

CIM Schema2.22.0

conformsTo

redIris

mofcomp

TIM ad hocExtension

Model

rediris.mofbasic.mof

nsfnet.mof

Figure 6.7: Scenario MOF validation


Note that designing scenarios is actually the only step that the designer has to care about,because once the scenarios have validated all the other steps are performed automatically. Al-though for this experimental validation the scenarios have been coded directly in MOF usinga text editor, in a real case the user could be aided by scenario designs tools, as mentioned inSection 4.2.

6.4.4 TSM Scenario Generation Workflow

Both TIM-to-VNUML and TIM-to-ADNETCONF transformations are defined in ATL and areexecuted using Eclipse IDE with the ATL plugin installed12. Following subsections describe theideal case and the one actually used due to some limitations in the software tools.

6.4.4.1 Ideal Case

Previously to the TSM scenario generation workflow, several elements have to be prepared in themodeling tool. However, this preparation needs to be done just one time, as once the elementsare installed in the modeling tool they can be used as many times as required in transformationscorresponding to different TSM scenario generation workflows. This includes build-in metamod-els (e.g. ATL, UML, ECore, etc.) that actually are provided by the modeling tool itself, the TSMmetamodels and transformation definitions models designed in Sections 6.4.1 and 6.4.2, and theCIM Schema and TIM ad hoc Extension Model. The latter is done injecting their correspondingMOF documents (cim schema 2.22.0.mof and tim.mof in Figure 5.4) into an UML class model,according to the UML profile for CIM standardized in DSP0219 (described in Section 3.4.5).From a MDA point of view, this injection is considered a Text2Model transformation.

All metamodels used in the TSM scenario generation workflow (including the ATL one)conforms to ECore, given that it is the one included by the modeling tool used for the validation(Eclipse). Note that ECore is aligned with EMOF (as explained in Section 3.2.2.2). VNUMLand ADRENALINE TSMs have been implemented manually in ECore. Regarding XML, it hasa well-known metamodel available in documented transformations publicly available13.

The transformation execution workflow is shown in Figure 6.8, including four steps in cas-cade that are described next: injection, TIM-to-TSM transformation, TSM adaptation andextraction.

• Injection. This Text2Model transformation is needed to transform the MOF documentsfor scenarios and parameters (i.e. .mof files) to UML instance models, in the internalrepresentation format that the modeling tool is using, conforming to the UML profile forCIM standardized in DSP0219. Injection is applied to two different elements:

– The TIM scenarios, basic, nsfnet and rediris, corresponding to basic.mof, nsfnet.mofand rediris.mof in Figure 6.7, are injected to sets of instances of the UML class modelcorresponding to TIM.

– The testbed parameters (settings.mof ) are injected to sets of instances of the VNUML -TestbedParameters or ADNETCONF TestbedParameters UML classes.

• TIM-to-TSM transformation. This is the main transformation process, performed by atransformation engine. Two separate Model2Model transformations need to be imple-mented to feed that engine, one to produce the VNUML TSM, another for ADNETCONF

12As reference, we have used Eclipse 3.3.2 with the ATL 2.0.0 and AM3 0.2.0 plugins installed.13For example, at http://www.eclipse.org/m2m/atl/atlTransformations/.


TIM scenarios(CIM instances)

TIMscenario

ATLMetamodel

TIM-to-TSMtransformation

Trans. Engine

VNUML/ADNETCONFTSM

(Fig 6.5 & 6.6)

TSMscenarioinput output

TSM (XML)

Testbedparameters

(CIM instances)

Testbedparameters

input

ECore

UMLMetamodel

UML Profile for CIM

(DSP0219)

CIM Schema

TIM Ext

transformation rules

Managed Object Format

documentsscope

Modeling tool scope(Eclipse IDE)

XML documents

scope

Trans.Engine

XMLMetamodel(Fig. 4.4)

XMLdocumentoutput

TSM adaptationtransformation


input

data flow (injection, transformation, extraction)

model instantiationrelationship

T2M text-to-model (injection)

M2T model-to-text (extraction)

T2M

T2M M2T

(UML classes)

(UML instances)

(UML instances)

Figure 6.8: Transformation execution workflow (ideal)


TSM. Each one consists in the declarative set of rules in ATL developed as result of thestep 3 in the transformation designs (Sections 6.4.1 and 6.4.2).

There are two input models: the TIM scenario (instances of TIM UML classes) and thetestbed parameters (instances of the VNUML TestbedParameters and ADNETCONF Test-bedParameters UML classes). There is one output model, that conforms to the correspond-ing TSM metamodel (i.e. VNUML and ADNETCONF). The transformation can be seenas a merge operation of two input models into one output model, although actually in bothcases they are implemented as two subtransformations, each one focused on producing anon overlapping part of the output TSM model.

• TSM adaptation. This is an additional Model2Model transformation used to adapt theTSM to the format used by the management tool in the testbeds. Two separate Model2Mo-del transformations need to be implemented, one to produce the VNUML TSM, anotherfor ADNETCONF TSM. Each one consists in the declarative set of rules in ATL developedas result of step 4 in the transformation design (Sections 6.4.1 and 6.4.2).

There is one input model (the TSM scenario) and one output model, that in both cases(i.e, VNUML and ADNETCONF) conforms to the XML metamodel.

• Extraction. This is a Model2Text transformation, which transforms the XML model intoan actual XML document that can be used by VNUML or ADNETCONF. It is imple-mented using the same ATL query in both cases. Only one query is needed given that,differently from TIM-to-TSM or adaptation transformations, the XML document transfor-mation is the same no matter if the XML model comes from VNUML or ADRENALINETSMs.

Note that although the modeling tools use to be able of exporting directly XMI, as concreterepresentation of MOF-based models, and XMI is XML-based, this representation does notconform to VNUML or ADNETCONF DTDs. In other words, neither ADNETCONF norVNUML are able to read and process the models representing XML documents expressedin XMI. Therefore, the extraction step is needed.

6.4.4.2 Actual Case

Problems were found due to the lack of maturity of UML modeling tools for CIM. In particular,there is a lack of modeling tool supporting the UML profile for CIM. The closest one at thetime being is ECUTE Modeler 2.x, but it is based in a pre-DSP0219 UML profile. In addition,this tool lacks of suitable injection features, e.g. it is unable of injecting instances, in our casebasic.mof, nsfnet.mof, rediris.mof and settings.mof.

Thus, given that CIM cannot be directly injected into UML with the currently availabletools, we have chosen to model directly the TIM and the small part of the CIM Schema neededto implement testbed parameters (actually, the SettingData class, along with their childrenVNUML TestbedParameters and ADNETCONF TestbedParameters) in ECore with Eclipse.Therefore, the workflow actually implemented is shown in Figure 6.9. Changes regarding theideal workflow in Figure 6.8 are marked in dark.

The injection process is performed manually, creating the XMI files that Eclipse uses asconcrete format for ECore-based models. This includes:

• The TIM and the reduced CIM Schema, in the general preparation step.


TIM scenarios(CIM instances)

TIMscenario

ATLMetamodel

TIM-to-TSMtransformation

Trans. Engine

VNUML/ADNETCONFTSM

(Fig 6.5 & 6.6)

TSMscenarioinput output

TSM (XML)

Testbedparameters

(CIM instances)

Testbedparameters

input

ECore


Managed Object Format

documentsscope

Modeling tool scope(Eclipse IDE)

XML documents

scope

Trans.Engine

XMLMetamodel(Fig. 4.4)

XMLdocumentoutput

TSM adaptationtransformation


input

data flow (injection, transformation, extraction)

model instantiationrelationship

T2M text-to-model (injection)

M2T model-to-text (extraction)

T2M

T2M M2T

(ECore classes)

(ECore instances)

(ECore instances)

TIM

CIMSchema

(reduced)(ECore classes)

Figure 6.9: Transformation execution workflow (actual)


• The instance models representing basic, nsfnet and rediris and their testbed parameters,in the TIM injection step. However, once the scenarios have been injected, all the othersteps in the workflow are performed automatically.

Although the ideal design described in Section 6.4.4.1 has not been actually implemented,note that all the changes are motivated due to limitations in currently existing tools, not in themodel-based configuration management architecture or the TIM themselves. Actually, it can beseen that Figures 6.8 and 6.9 are basically the same and that the TSM generation workflow isnot altered (the main change is in the preparation step).

6.4.5 Scenario Deployment Workflow

After applying the transformation as described in Section 6.4.4, the XML documents correspond-ing to the TSMs shown in Figure 6.4 are generated. Next step is to actually use them with thecorresponding scenario-based management tools in each testbed to check that the correspondingscenario gets deployed properly.

It has been tested that VNUML in building mode is able to produce proper deploymentsusing the TSMs for the basic, nsfnet and rediris scenarios. All the virtual machines get bootedproperly and have subnet direct connectivity. In addition, for the rediris and nsfnet casesthe OSPF processes converges after a while, so end-to-end connectivity can be testbed usingconventional tools such as ping and traceroute.

In a similar manner, it has been also checked that ADNETCONF is able to rightly deploythe nsfnet and rediris scenarios using the ADNETCONF TSMs in the ADRENALINE test-bed infrastructure at CTTC premises. The OSPF is also able to converge in those scenarios.Regarding basic, although a formally correct XML file gets generated conforming to the AD-NETCONF DTD, it cannot be deployed, because it is not using PPP links, i.e. the <links>section gets empty. This has not to be considered a problem of the management architecture orthe transformation steps; it is just due to basic is not modeling a scenario which correspond toa valid experiment setup for ADRENALINE.

Apart from deployment, both tools are able to perform the other available operations (seeSections 2.3.4.1 and 2.3.2.2) in the scenario. In particular, VNUML is able to undeploy (usingthe releasing mode; execution mode is not used because the TSMs are not defining any commandsequence) and ADNETCONF is able to monitor and undeploy.

In order to check that the transformation process is not involving any significant overheadregarding conventional scenario-based approach, an analysis has been performed14. The resultsare summarized in Table 6.5 and show that transformation times are always under 2.1 seconds,i.e. less than 3% in the worst case of the time that VNUML/ADNETCONF takes to deploythe scenario on the testbed. In consequence, our proposal is not introducing any significantoverhead in the management of the testbed even for large scenarios.

14As reference, we have run the transformations using Eclipse 3.3.2 (on JVM 1.6.0) with ATL 2.0.0 and AM30.2.0 plugin, running on Ubuntu 9.04. VNUML-based testbed is implemented on an Intel Core 2 Duo T7300 2GHz2GB RAM running VNUML 1.9.0beta8 in an Ubuntu 9.04 system. Regarding ADNETCONF, the deploymentplatform are the ADRENALINE emulated OCCs, implemented on Intel Xeon 3.0GHz, Core 2 Duo E6550 2.33GHzand Intel Core 2 Duo E8200 2.66GHz systems with 4GB RAM and running Debian 4.0.


Scenario MDA Transformation DeploymentVNUML ADNETCONF VNUML ADRENALINE

basic 297ms 285ms 15166ms -

nsfnet 1258ms 1585ms 52307ms 83006ms

rediris 2073ms 2022ms 74875ms 121935ms

Table 6.5: Transformation and deployment times

6.5 Conclusions

Based on the results achieved with the experimental validation described in this chapter, themain conclusion is that the model-driven configuration management architecture described asmain contribution of this work can be effectively used to configure complex networking scenariosin real-world experimentation testbeds, thus assessing the feasibility of our proposal.

The TIM has been used to implement three validation scenarios and, as some of them arequite large and complex, the completeness and flexibility of TIM is assessed. This validationhas also shown how the TIM-to-TSM transformation design relies in a systematic procedure,i.e. the methodology described in Section 4.4.3, reducing the complexity compared to an ar-bitrary design. Once the TIM-to-TSM transformation is implemented, all the procedures toproduce the TSM scenarios are performed in a strictly automatic way. The same scenariosmodeled at TIM layer are automatically transformed to representations or “views” addressedto different deployment environments, processing the same TIM elements in different ways, e.g.ComputerSytems are associated to physical OCCs in ADRENALINE and to virtual machinesin VNUML-based. The transformation step ensures that the information that does not makesense in a given testbeds is removed, e.g. QoS constraints in VNUML-based or multi-point linksin ADRENALINE.

Considering complexity, although the workflow in Figure 6.8 or 6.9 shows many functionalblocks, actually only three of them have to be developed as a result of our TIM-to-TSM designmethodology: the TSM formal model, the TIM-to-TSM transformation definition and the TSMadaptation. In the case of XML-based TSMs, we have developed algorithms that can be appliedto ease the development of the first and third ones. The remaining blocks are provided by existingtools. In addition, with a suitable knowledge of the transformation language, designing an MDAtransformation is even simpler than a traditional approach to process .mof files (e.g. script-basedprogram) because the designer works at concept-relation level and all the complex parsing worknot related to the transformation itself is avoided. The script approach has additional drawbacks,such as the impossibility of checking model conformance.

We have also shown that the final TSM scenarios (in their XML format) are processable byVNUML and ADNETCONF. This shows how testbed parameters have been properly mergedwith TIM to produce the TSM in the transformation step. Our proposed management archi-tecture not only leads to scenarios actually deployable and usable for real experimentation inthe testbeds, but also do it with a not meaningful transformation overhead time (Table 6.5). Itis worth mentioning that neither VNUML or ADNETCONF are “validation artifacts”, as theyexisted before our architecture was designed, and are currently used to configure scenarios intheir respective testbeds to perform actual experiments. Therefore, the fulfilment of our maindesign principle is proved: the implementation of our management architecture is not requiringthe modification of existing testbed or their management tools.


Finally, the only complexity we have found in the validation experiments is the low maturitydegree of the existing software to support MDA transformation technologies (QVT and ATL)and UML profile for CIM. Regarding MDA transformation technologies, we have found thatATL, although still under development, fulfills our requirements and fits for our purposes. Onthe contrary, regarding the UML profile for CIM we have not found a completely suitable tool, sowe have implemented a slight deviation of the ideal transformation execution. In any case, thisdoes not alter the essence of the experimental validation and the assessment it provides on ourproposal, as described in Section 6.4.4.2. It should be taken into account that the UML profilefor CIM and MDA still being recent technologies, so we consider this a transitory situationand, as the software evolves, these immaturity problems will eventually disappear, while thefoundations in which our model-based configuration management architecture is based on willremain.

Chapter 7

Application

7.1 Introduction

The previous chapters have described our proposed configuration management architecture,based on model-driven principles, that solves the problem of technological dependency in scenario-based networking experimentation infrastructures, along with an experimental validation thatassesses its feasibility in real testbeds.

This chapter goes one step further, describing three utilization cases in which the architecturecould be used in testbeds. In particular, we consider conventional scenario-based interrelatedtestbeds (Section 7.2), Future Internet federated testbeds (Section 7.3) and WBEM-based test-beds (Section 7.4). In addition to testbeds, we also briefly consider applications to productionenvironments in Section 7.5.

The description is done from the user perspective (e.g. researchers, developer, etc.), focusingon how he or she would be using the architecture in each case and which benefits will be achieveddoing so.

7.2 Conventional Scenario-based Interrelated Testbeds

Consider the case of a researcher (or group of researchers) working on state of the art problems inany field of networking, e.g. dynamic routing algorithm, P2P architectures, content distributionnetworks, etc. The nature of the problem to solve in each testbed will be of very different nature(e.g. analyze the performance of existing systems, develop a new protocol or feature in existingprotocols, etc.) but the basic working cycle is more or less the same for all cases. First, theresearcher solves the problem from a theoretical point of view maybe using some mathematicalformalisms (e.g. graph theory) and network simulators, such as ns2 [ns10] or OPNET [Cha99].But, sooner or later, the approach needs to be tested in order to assess its feasibility under realutilization conditions.

Testbeds resemble the conditions of actual utilization environments with a varying degree offidelity depending on the testbed design. However, researchers need to consider a large numberof different scenarios, seeking for the completeness of their experiments, i.e. be able to checkall the conditions needed to reach profitable conclusions about the system under test. Forexample, in order to test the stability and scalability of a given dynamic routing algorithm,several topologies sizes, layouts (e.g. ring, start, mesh, etc.) and configurations (e.g. algorithmparameters) have to be considered.

151

152 CHAPTER 7. APPLICATION

In addition, consider that a set of interrelated testbeds are required. By interrelated testbedswe mean the set of different testbeds, maybe implemented by different technologies and evenbelonging to different organizations in different geographical locations, to be used for jointexperimentation. That is, the set of experimentation scenarios is the same for all the interrelatedtestbeds. Interrelated testbeds could be needed if the researcher needs several complementarytestbeds, each one devoted to a particular aspect of the idea under test but needing the sameset of scenarios to get coherent results. For example, consider that three testbeds are needed:virtual-based, globally distributed and close to real. It can also happen when due to collaborativework or to contrast results, other researchers need to reproduce the results of the experimentsin their own testbeds, which can be completely different from a technological point of view.

Figure 7.1 illustrates this case with the conventional management approach, i.e. not using ourproposed model-driven architecture, considering a set of N scenarios to be used in T interrelatedtestbed (T equals to 3 in the figure).

Deployment

Undeployment

Experimentexecution

many times

Virtualization-based testbed

Distributed testbed(e.g. PlanetLab)

Final solution

Close-to-realtestbed

Deployment

Undeployment

Experimentexecution

many times

Deployment

Undeployment

Experimentexecution

many times

Experimentationscenarios design(sc1, sc2, … scN)

for testbed #1


for testbed #2


for testbed #3

feedback

Preliminary design(analytical, network

simulation, etc.)

feedback feedback

manual synchronization

Figure 7.1: Conventional scenario-based configuration management in interrelated testbeds

Accordingly the complexity analysis using the conventional scenario-based configuration ma-nagement approach done in Section 1.3.1, the researcher has to develop an initial set of N ×T scenario specifications. In addition, each single scenario modification due to feedback duringexperimentation involves T-1 additional ones to keep the scenario set synchronized among thedifferent testbeds. Both processes are done manually, so they are time consuming and errorprone.

We can consider now how our model-driven proposal can be applied to the same environment.This is shown in Figure 7.21. In this case, the researcher creates N TIM scenarios so the designeffort is independent of the number of interrelated testbeds. In addition, if modifications are

1Actually, the experimental validation in Chapter 6 resembles this case with N and T equals to 3 and 2respectively.

7.3. FUTURE INTERNET FEDERATED TESTBEDS 153

required due to feedback gathered during the experiments, they need to be done only at TIMlevel because all TSM scenarios in every testbed are easily regenerated thanks to the TIM-to-TSM automatic transformations. In other words, the T-1 penalty disappears. Finally, as faras different researchers in different organizations have implicitly agreed in the TIM semanticsspecified in Chapter 5 when they use our architecture, there is not any scenario synchronizationproblem even if researchers are in different organizations and operate technologically differenttestbeds.

Preliminary design(analytical, network

simulation, etc.)

Deployment

Undeployment

Experimentexecution

many times

Virtualization-based testbed

Distributed testbed(e.g. PlanetLab)

Final solution

Close-to-realtestbed

Deployment

Undeployment

Experimentexecution

many times

Deployment

Undeployment

Experimentexecution

many times

feedback


using TIM

feedback feedback

Figure 7.2: Model-driven scenario-based configuration management in interrelated testbeds

In conclusion, using our model-driven architecture simplifies the researchers work. Theadvantage is higher when the number of scenarios and testbeds increases, i.e. large N and T. Inexisting testbeds, the only price to pay is the development of the TIM-to-TSM transformationsbut it gets largely compensated with the configuration management benefits. For new testbeds,the TIM-to-TSM transformation is a cost associated with testbed building, as the installationof the testbed hosts or the development of the scenario-based management tools is. In addition,note that this development is eased by the existence of a systematic procedures: the methodologydescribed in Section 4.4.3. In any case, the cost in developing the transformation is only incurredone time along all the testbed lifetime.

Finally, note that, as outlined in the introduction chapter (Section 1.1), this approach canalso be applied to cases in which there is not actually a testbed infrastructure involved butin which the scenario concept stills making sense. In particular, in can be applied to thesimulation steps that use to precede to actual experimentation, improving the synchronizationbetween simulation and experimentation scenarios, e.g. through the means of a TIM-to-ns2transformation.

7.3 Future Internet Federated Testbeds

As analyzed in Section 2.4.4, Future Internet experimentation infrastructures are not imple-mented yet using scenario-based approaches, although this is the current trend. In the present


section, we describe a possible application of our model-driven configuration management archi-tecture to these environments, showing how our contribution could improve the “conventional”scenario-based approach in this case. Our proposal is very timely as a common specificationand management mechanism to define scenarios that expand across a set of federated testbedof different technological nature.

Although there are differences between the different Future Internet testbeds, all of themshare two basic characteristics. Firstly, they are based on the federation of different experi-mentation environments usually implemented using also different technologies, e.g. wireless,optical, etc. They can actually be considered as independent aggregated testbeds, resulting ina globally distributed infrastructure. Secondly, Future Internet federated testbeds implementmulti-user facilities to support concurrent experimentation, so the scenarios belonging to differ-ent researchers do not interfere each other. In order to achieve this shareability and isolation,slices are used, defined as isolated partitions of the testbed resources assigned to a given re-searcher to run their experiments. Slices can be implemented using virtualization techniques(virtual machines and networks) or exclusive physical assignment for resources which are difficultor impossible to virtualize, e.g. optical lightpaths at wavelength level.

A Future Internet federated testbed is typically required in two different cases, in whicha conventional testbed could be hardly used. First, when the scenario to be deployed is solarge that does not fit in any single conventional testbed, so federation is required to aggregateresources. Secondly, when the scenario mixes the utilization of heterogeneous resources, i.e.optical, wireless, etc., to perform complex experiments that are not provided by single testbedsspecialized each one in a given resource type or in generic technologies such as commodity PCclusters. It is also possible to consider a combination of both cases, i.e. very large scenariousing heterogeneous resources. The application of our model-driven configuration managementarchitecture to both cases is described in the following subsections.

7.3.1 Federation to Support Very Large Scenarios

Consider the case of a very large scenario to be deployed in a federated infrastructure composedby three different testbeds (Figure 7.3). This large scenario will be specified using the TIM andprocessed by the following workflow, provided by the configuration management system:

1. Scenario segmentation. Using the target scenario as input, this process splits it intoseveral subscenarios, each one addressed to a different testbed in the federation. Thesesubscenarios are also specified using TIM, the process can be seen as a TIM-to-TIM mul-tioutput transformation. In Figure 7.3, it is shown how the 3000-nodes scenario is dividedinto three 1000-nodes subscenarios.

The algorithm used to perform the segmentation is out of the scope of this discussion,although it is supposed to take into account the testbed information stored in a knowledgebase to ensure that the splitting process is coherent, i.e. the different testbeds have enoughcapacity to cope with their corresponding subscenarios. Considering the multi-user natureof the testbeds, the segmentation module should work with real time snapshots of theavailable capability. In this example, is supposed that at the moment of deploying thetarget scenario, each one of the testbeds is able to cope with at least one thousand nodes.

As an additional result of this process a Subscenario Interconnection Model is also pro-duced, specifying how subscenarios have to be interconnected. This model is close to thePSM bridge concept to interconnect PSMs in MDA (see Section 3.3.2.2).

7.3. FUTURE INTERNET FEDERATED TESTBEDS 155

Very large network(3000 nodes)

Scenario segmentation

Part #1(1000 nodes)

Part #2(1000 nodes)

Part #3(1000 nodes)





in testbed 1


in testbed 2


in testbed 3

Testbed 3Testbed 2Testbed 1

Federation network(e.g. dedicated backbone)

TIM TIM TIM TIM

TSM1 TSM2 TSM3

Testbedknowledge

(1)

(3) Network configurator

SubscenarioInterconnection

Model(2)

Figure 7.3: Using federated testbeds to cope with large scenarios

2. Model-driven deployment. The configuration management architecture proposed inthis work is used to deploy each one of the subscenarios in the respective testbed. At theend of this process a slice is created across the federated infrastructure, so each part is holdin the corresponding testbed in an isolated way. Each subscenario is configured properlywithin each testbed.

3. Configure interconnections. This step corresponds to the configuration of the intercon-nection among deployed subscenarios through the network interconnecting the federatedtestbeds. This process is done by a Network Configurator element using the SubscenarioInterconnection Model as input. Usually, tunneling technologies are used, maybe usingencryption if the connections are made through a public network such as the Internet.

Note that each solid line interconnecting subscenarios in Figure 7.3 represents actuallyan undetermined number of multiplexed node-to-node connections. The particular node-to-node connections (specified in the Subscenario Interconnection Model) depend on thetarget scenario topology and the segmentation process. In fact, the segmentation algorithmin step 1 should try to minimize the number of inter-subscenario node-to-node connectionsand provide the proper mapping between scenario links and tunnels, e.g. ensure that theQoS associated to the tunnel is greater than the aggregated QoS constraints specified inthe multiplexed scenario links.

Compared to the case of using conventional configuration management instead of our model-driven architecture, the absence of a TIM to specify the large target scenario would force the


researchers to use manual procedures to produce the subscenario specifications. This has manydrawbacks, as described in Section 1.3.2.

In is worth noting that, although we have neither provided yet a solution aligned withTIM nor defined in detail the Subscenario Interconnection Model, the problem of large scenariodistribution in federated testbed has been addressed at TSM level as part of our research, usingPASITO (described in Section 2.4.4.4) as a federated infrastructure [GFLM09].

7.3.2 Federation to Support Scenarios Mixing Specialized Resources

As can be seen in Figure 7.4, the architecture and associated workflow is very similar to the onedescribed in the previous subsection. However, the splitting algorithm is different, as in this casethe objective is to match the required resources in the scenario specification with the availableones in the testbeds which resource description and status is stored in the knowledge base.

Scenario segmentation





in testbed 1


in testbed 2

Testbed 2Testbed 1

Federation network(e.g. dedicated backbone)

TIM TIM TIM TIM

TSM1 TSM2 TSM3

Testbedknowledge

(1)

(2)

(3)


in testbed 1

Network configurator

SubscenarioInterconnection

Model

Figure 7.4: Using federated testbeds to cope with specialized resources requirements

In the example, we consider a federated infrastructure composed of two testbeds, specializedin wireless and optical communications respectively, and one scenario to be deployed imple-menting a topology using the two different kinds of resources. The segmentation module willsplit the scenario into three subscenarios, two modeling the wireless links to be deployed in thewireless testbed and one including the optical link to be deployed in the optical testbed. Then,at deployment time, the resources are reserved implementing the corresponding experimentationslice (circled in red in the figure) and the interconnection is done in the federation network.

The problems that would happen using conventional configuration management are the same

7.4. WBEM-BASED TESTBEDS 157

that the ones described in the previous section, that is, time consuming error-prone manual splitand subscenario synchronization.

However, note that the TIM as described in Chapter 4 is not able to express resource types.In other words, it is not possible to specify that a ComputerSystem is modeling a wireless nodeor that a TIM LinkConnectivityCollection has to be implemented using an optical link. A pos-sible way of cope with this limitation is extending TIM classes specializing their semantic todescribe the desired resources, e.g. TIM WirelessComputerSystem extending ComputerSystemand TIM OpticalLinkConnectivityCollection extending TIM LinkConnectivityCollection. Thissemantics are only interpreted by the segmentation module, not by the TIM-to-TSM transfor-mation in each testbed. Therefore, the segmentation module is able to know which resourcesare required by the scenario specification without breaking TIM-to-TSM transformations inthe federated testbeds, due to for example a TIM WirelessComputerSystem instance is also aComputerSytem instance.

7.4 WBEM-based Testbeds

The management architecture described in Section 4.2 relies in scenario-based tools to performthe actual configuration management operations in the testbed infrastructure. In fact, the mainarchitectural design principle is to be able to seamlessly integrate with these tools withoutany modification in existing software or testbeds. This implicitly assumes that scenario-basedmanagement tools is the state of the art in existing testbeds, as has been proved by the analysisdone in Chapter 2.

Note that, as explained in Section 4.3.4, although we are using a CIM-based informationmodel to define the TIM, our architecture is not actually WBEM-based. However, designinga WBEM-based management approach around the existing TIM would be interesting to fosterWBEM-based management for testbeds (currently not used in anyone) leveraging software tra-ditionally addressed for production environments. In particular, we can leverage existing CIM-based management models (stored using a CIMOM repository) and their associated providersto perform the management operations.

In order to implement WBEM-based management using the TIM, it should be extended tointroduce management methods for testbed scenarios. In particular, the TIM TestbedScenariohas to be extended considering the different methods to manage scenarios. The two basic onesare deploy() and undeploy() corresponding to the deployment and undeployment steps describedin Section 2.2.1.2 respectively, but others could be added e.g. a monitor() method to get thestatus of a deployed scenario. This is illustrated in Figure 7.5. The other classes and associationsin TIM remains as usual, i.e. as shown in Figure 5.2.

Name: string {key}

Deploy(): uint32Undeploy(): uint32Monitor(): uint32[…]

TIM_TestbedScenario

Figure 7.5: TIM TestbedScenario including methods

In order to implement these methods, a provider is used, integrated in a WBEM serverand replacing the scenario-based management tool to perform the operations. It is actually a


method provider, associated with deploy(), undeploy() and the other scenario oriented methodsin TIM TestbedScenario.

The CIMOM repository in the WBEM server includes the TIM and the scenarios conformingto TIM, i.e. set of instances belonging to TIM classes and associations. From a CIMOM pointof view, this set up is similar to the one shown in Section 6.4.3, but in this case it also includesthe CIM model to manage testbed devices, e.g. the subclass of ComputerSystem representingthe actual physical hosts (e.g. Linux ComputerSystem). In addition, the WBEM server includesthe providers associated to these manageable testbed elements.

The WBEM-based architecture including all those elements is shown in Figure 7.6 as aparticular case of the general WBEM architecture (shown in Figure 3.10) aimed at scenario-based management. The figure also shows a workflow example for a typical scenario orientedoperation (e.g. deploy), described as follows:

CIMOM

CIM Client

WBEM server

Testbed

Testbed deviceprovider

Scenario Management Provider

(TIM_TestbedScenariomethods)

redIris

TIM ad hocExtension

Model

TIM_TestbedScenario instance

(1)

(2)(4a)

(4b)

(3)

(5)

other TIM classes/associations instance

CIM Schema

testbed manageable devices instance

Figure 7.6: WBEM-based architecture for scenario oriented management

1. The user locates in the CIMOM repository the desired scenario to deploy, using the brows-ing capabilities of a CIM client (out of our scope). Then, the deploy() method is invokedin the corresponding TIM TestbedScenario instance.

2. Upon invoking the operation, the CIMOM looks for the provider associated to the deploy()method in TIM TestbedScenario and the operation is forwarded to it through the CIMOM-provider interface.

3. The provider uses the TIM TestbedScenario associations to query all the instances con-forming the scenario. Then, the provider processing logic matches scenario instances with

7.5. PRODUCTION ENVIRONMENTS 159

CIM instances (representing the manageable devices in the testbed) and actual operationson them. Note that this step is equivalent to the TIM-to-TSM transformation functionalitythat associates TIM elements to TSM elements. This provider is not directly managing anyinfrastructure physical device; it is managing the testbed itself as a composed aggregateddevice.

4. The provider invokes operations in the CIM instances representing the manageable devices(4a), e.g. to assign the IP address used in the scenario for a particular node to an actualphysical host. The CIMOM forwards each operation to the provider associated with themanageable object (4b) using the CIMOM-provider interface.

5. The providers associated to each manageable object interact with the infrastructure toconfigure the testbed in the proper way, as required by the scenario.

Although this architecture provides a WBEM solution based on TIM to provide scenario-based management in testbeds, several issues need to be clarified in order to implement itactually:

• Browsing capabilities in the CIM client to locate the scenario to be deployed, typicallyimplemented as tool features, e.g. a “Browse” button in a GUI-based CIM client able tolocate the right TIM TestbedScenario by Name.

• Although the interfaces between CIMOM and CIM clients and CIMOM and providers havebeen defined by DMTF or other standardization bodies, it is not clear how to implementthe upcall interface so a provider can query the CIMOM (required in step 3) or invokingmethods in other providers (required in step 4a). This could depend on the particularCIMOM implementation.

7.5 Production Environments

The main focus of our dissertation is configuration management in flexible experimentation in-frastructures and the use cases considered up to now in this chapter are in fact based on differentkinds of testbeds. However, as introduced in Section 1.1, our contribution can be also appliedto some production environments. This section briefly describes two different possibilities.

• WBEM-based production networks. In Section 7.4 we have analyzed how a slightly mod-ified version of the TIM could be used to define and manage scenarios in WBEM-basedtestbeds. In order to do so, a special type of provider has to be integrated in the CIMOMmanaging the testbed infrastructure. This approach is also possible in conventional produc-tion networks managed using WBEM. In fact, considering standard-compliant CIMOMsand providers (e.g. based on CMPI [CMP06]), the scenario management provider couldbe the same in both cases. The main difference would be in the management informationstored in the CIMOM repository, modeling different kinds of devices, e.g. low-profile PCsin the testbed and carrier grade equipment in the production network. It is worth notingthat the evolution from a WBEM-based testbed to a WBEM-based production networkalso involves reusability in both CIM clients and the set of scenarios developed conformingto the TIM (Figure 7.7).


CIM Client

Testbed

Providers

ScenarioManagement

Provider

CIMOM

model for testbed devices

Productionnetwork

Providers

ScenarioManagement

Provider

CIMOM

model for production

network devices

TIM scenarios

Figure 7.7: From WBEM-based testbed to WBEM-based production network

• Scenario-based production environments. Although not so extended in production plat-forms, the scenario-based configuration approach is gaining momentum in those environ-ments. For example, DMTF has recently standardized the OVF (Open VirtualizationFormat [DMT09b]), which enables describing a set of virtual machines interconnectedusing virtual networks to be deployed in conventional virtualized infrastructure or cloudcomputing platforms [GSRM+09]. OVF can be actually considered a TSM, so our model-driven approach can be used to derive OVF descriptors from TIM scenario specifications.

It is worth noting that the main motivation of applying the model-driven scenario-basedconfiguration management approach in this case is to ease the migration of scenariosbetween pre-production and production environments. For example, if a service has beendeveloped and debugged in a given testbed based on a TIM scenario specification, thenmoving it to production would consist in just generating the proper TSM specification (e.g.an OVF descriptor) in order to perform the final deployment. In this case, a TIM-to-OVFtransformation has to be developed.

7.6 Conclusions

In the present chapter we have described the utilization of our model-driven scenario-basedconfiguration architecture in three different testbed use cases from user perspective. Althoughactually only the first case (conventional scenario-based interrelated testbeds, described in Sec-tion 7.2) can be carried out today because this is the kind of testbed currently existing, theanalysis performed in this chapter shows the potential of our proposal to fulfil the configurationmanagement gap in novel testbed approaches. Regarding Future Internet federated testbeds(Section 7.3), it is clear that they will need to be managed but, to the best of our knowledge, no


technology independent solutions based on scenarios has taken into account the requirementsof federation. Regarding WBEM-based testbeds (Section 7.4), we have shown that the TIM isa way of achieving scenario-based management without needing tools external to the WBEMarchitecture.

In addition to testbeds, production environments are also considered in Section 7.5. Weaddress both WBEM-based networks, as an evolutional application of the WBEM-based testbedcase, and production environments in which a scenario concept equivalent to TSM can be defined,e.g. OVF-based platforms, such virtualized datacenters and clouds.

In conclusion, our proposal is not only valid for conventional testbeds existing today, but alsocan pave the way to the development of novel testbed approaches and the evolution towardsscenario-based approaches in production environments. Note that one of the main problemsthat testbed designers face is how to implement configuration management systems which makethe testbed an efficient and productive tool. In this sense, this chapter shows how our proposalis flexible enough to adapt to several situations.

Although developing the corresponding TIM-to-TSM transformation (or testbed scenariomanagement WBEM provider) would imply an additional effort, this is only performed onceduring the testbed lifetime so it can be considered part of the testbed setup process as, forexample, the wiring of the equipment and the installation of operating systems are. It is worthnoting that only one TIM-to-TSM transformation module is developed for each testbed. Thistransformation is able to process whichever TIM scenario used as input, within the technologicallimitations of the testbed.

Chapter 8

Conclusions and Future Work

8.1 Main Findings

The scope of our work is configuration management in experimentation infrastructures. This isnowadays an important field which is gaining momentum considering its strong public supportin the emerging Future Internet initiatives. These initiatives put testbeds in the center of theresearch activities, as they are considered the key enablers in the evolution and invention ofnetworking technologies, which, at the end, will bring to fruition new commercial services andapplications for the final users. Our dissertation identifies one important problem in testbedconfiguration management and provides a convenient solution to it. In particular, the problemwe have addressed along this document is the technological dependency of scenario specifications.

In order to clearly identify the problem and contextualize it in the scope of configurationmanagement in networking testbeds, Chapter 2 has done an extensive analysis of the mostsalient experimentation infrastructures and testbed building tools existing nowadays, after abrief introduction to testbeds and its categorization. As conclusion of this analysis, we havefound that the scenario-based approach is the state of the art in configuration management,as it is the most extended one in locally distributed infrastructures and a promising trend inglobally distributed infrastructures. However, each scenario specification language is completelytied to the testbed or tool in which it has been defined and there is not any common scenariospecification mechanism widely applicable to any testbed. This is an important problem, becausethe existence of such common approach would enable scenario reutilization among testbeds tosolve complex problems and scenario shareability between researchers working in the same fieldin their respective testbeds.

To solve this problem, we have developed three main contributions, introduced in Chapter 4and summarized below.

• Firstly, a novel model-driven management architecture, leveraging all the advantages thatthis paradigm has brought to software development. The novelty of our approach lies inthe application of OMG’s MDA software engineering principles to scenario-based testbedconfiguration management. This approach starts by the focus on models so that any con-figuration procedure, such as scenario deployment or undeployment, is based on using ortransforming models. It is followed by the “separation of concerns”, clearly applied be-tween scenario specification and implementation at two different abstraction layers (calledrespectively the Testbed Independent Model or TIM and the Testbed Specific Model orTSM) to achieve technological independence. The main design principle for the archi-

163

164 CHAPTER 8. CONCLUSIONS AND FUTURE WORK

tecture is to be seamlessly integrable with existing testbeds or, in other words, to fit inexisting testbeds without any re-engineering effort. The architecture provides a functionalframework where the other two contributions fit.

• Secondly, the Testbed Independent Model (TIM), which provides a high level “vocabu-lary” that the testbed users can use to define any desired scenario in a deployment-agnosticway. This model has been designed to address requirements on completeness, network-layer orientation, modularity, extensibility and simplicity. In order to do so, we have deeplyanalyzed in Chapter 3 existing modeling and transformation technologies, along with ex-isting management information models in which TIM could be based. The final solutionis a modular design, composed of a TIM Core and TIM Modules, based on the DMTF’sCIM Schema and in an ad hoc Extension Model. The TIM is detailed in Chapter 5, boththe TIM Core and an example of TIM Module for OSPF modeling.

• Thirdly, given that developing each particular TIM-to-TSM transformation makes no sensebecause they are testbed-dependant, we provide a general and systematic methodology todesign them. TIM inherits from CIM a flexible range of representation alternatives (text,XML, UML or ontologies), each one associated with different transformation techniques.We have found that OMG’s MDA and ontology mapping are the best alternatives. Aftera careful analysis, we have decided to base our methodology in the former but withoutprecluding the use of the latter, as ontologies can be used to specified knowledge-levelrelationships among the mapped elements in TIM and TSM. Considering the high numberof scenario specification languages based on XML in the analysis done in Chapter 2, wehave proposed as contribution specific algorithms to adapt the methodology to XML-basedTSMs.

In addition, the state of the art analysis in Chapter 2 can be considered also a contribution,because although there are some surveys analyzing testbeds they are too old (such as [NSF02])or focused on the purpose of the testbed but not in configuration management aspects of thetestbed itself (such as [Rob09]). On the contrary, our survey considers the point of view oftheir configuration management, taking into account the recent and evolving efforts in FutureInternet initiatives.

The expressiveness of TIM to describe scenarios in existing testbeds has been proved byexperimental validation in Chapter 6. This validation does not only assesses that TIM is able todescribe large and complex scenarios used for real experimentation and that the TIM-to-TSMmethodology can develop actual transformations, but also that our management architectureseamlessly integrates with existing systems without noticeable overhead and that does not re-quire any modification on existing testbeds or their management tools. Neither ADRENALINE,ADNETCONF or VNUML were modified to perform the validation.

We have gone a step further in Chapter 7 in which we define four general application casesof our solution. First, the conventional interrelated testbeds case, which is actually the oneassessed by the validation experiment in Chapter 6. The other cases have not been assessedexperimentally but they are environments which could take advantage of our contributions tosolve configuration management gaps not solved up to now. They are Future Internet federatedtestbeds, WBEM-based testbeds and production environments.

Our approach is based on two key standards: DMTF’s CIM Schema and OMG’s MDA (asshown in Figure 8.1). Regarding CIM Schema, it provides the core of networking concepts inwhich TIM is based on. Furthermore TIM can take advantage of the evolution of the CIM

8.1. MAIN FINDINGS 165

Schema, which is enriched periodically by DMTF. Regarding MDA, UML is used to expressTIM scenarios, although a general lack of maturity in current transformation tools has beenobserved. Our vision is that these issues will be fixed by software implementers as MDA gainsmore industrial acceptance through time.

OMG’sMDA

DMTF’sCIM

Model-drivenscenario-basedconfigurationmanagement

Technological maturity (software) due to

industrial acceptance

Evolution of the CIM Schema feeds

the TIM

Figure 8.1: Alignment with standards

In conclusion, we provide a solution to the scenario technological dependency problem whichallows the use of the same topologies and configurations in different testbeds by different users,avoiding time-consuming and error-prone manual conversions. A summary of the different ad-vantages that this approach brings follows:

• Inter-testbed scenario specification reutilization to solve complex experiments that needseveral complementary testbeds. In this case, which is analyzed in detail in Section 7.2,the complexity of designing and maintaining the scenarios is highly reduced and madeindependent of the number of involved testbeds.

• Providing a common model (the TIM) for Scenario Segmentation tools in federated test-beds, which avoids manual and suboptional scenario splitting procedures.

• Enabling WBEM scenario-based management (based on the TIM), which currently hasnot been achieved with other means in testbeds.

• Fostering the creation of an ecosystem of TIM-based tools. Apart from TIM-to-TSMtransformations, that are as coupled to the testbed as TSM itself, other generic tools canbe built around TIM. These tools would be highly valuable, as they are not addressed toany given particular testbed, but usable in anyone. They include:

– Editors to build and modify TIM scenarios.

– Validators to check that the scenario is consistent regarding a set of constraints,maybe user-defined1.

1These tools are related with the future working line identified in Section 8.3.2.


– Scenario repositories that, apart from basic storage capabilities, could implement con-trol version features usually available in code repositories, e.g. versioning, branching,merging, etc. They also can include advanced querying capabilities, e.g. the abilityto get fragments of a large network scenario matching a given property.

• Enabling shareability of reference networking scenarios. It could be interesting in somecommunities of researchers and educators working on the same networking field to developa common scenarios base to run a wide range of experiments, sharing scenario knowledgein this way. Examples of reference scenarios are the ones described in [HBB+04]. Thiswould enable a high degree of reutilization of existing scenarios in newly built testbedsor that scenarios can survive the testbed where they were originally designed. A scenariorepository as the one described in the previous bullet could be used, making it availableto a restricted community or to the overall public (e.g. through the Internet).

• Providing a high isolation degree to scenario designers of the testbeds technological low-level details. A first level of isolation is provided by scenario-based management itself(as explained in Section 2.2.1.3) but the TSM scenario stills including deployment-relatedinformation that is avoided only when the scenario is designed at TIM level. In fact,this high degree of isolation enables the definition of the two roles (scenario designer andtestbed administrator) described in Section 4.5.

8.2 Publications

As a result of this dissertation a total of twenty three publications have been produced, twomain and twenty one secondary ones. It is worth mentioning that two of them are indexed andlisted in JCR and one is a patent request. In the time being, the patent request is in the laststeps to be ratified in the three regions where it has been submitted (Europe, USA and Japan),which is expected by 2010.

The main publications address the core of our contribution, that is, the model-driven ar-chitecture to achieve scenario description technological independency, the Testbed IndependentModel and the TIM-to-TSM design methodology. Secondary publications are related with theVNUML and ADNETCONF scenario-based tools that are used for the experimental validationin Chapter 6. Actually, the work on these tools and the definition of the respective scenariodefinition languages have provided us with an understanding of the scenario technological de-pendency problem. The experience and ideas with these lines have been very valuable in thedevelopment of our main contributions.

More detail on the different publications is provided in the following subsections. Notethat some of those publications, in particular the ones related with the state of the art onexperimentation infrastructures, are also included in the Bibliography section of this document.However, we are including them also here in order to provide a comprehensive vision of thepublications resulted of our dissertation. Regarding how these publications relate with thecontents on this document, the main publications are derived from the contents in Chapter 4, 5and 6; while the VNUML and ADNETCONF publications are related with specific sections inChapter 2 and 6.

8.2. PUBLICATIONS 167

8.2.1 Main Publications

Our first description of the general methodology and architecture addressed in this proposalwas introduced in M2. That brief paper states the problems currently existing in configurationmanagement for flexible experimentation infrastructures and provides a preliminary version ofthe TIM. It is extended and enhanced in M1 with more details on the application to actualtestbeds (VNUML-based and ADRENALINE).

M1 Fermın Galan, Jorge E. Lopez de Vergara, David Fernandez and Raul Munoz, Scenario-based Configuration Management for Flexible Experimentation Infrastructures, Proc. ofthe 5th IEEE Int’l Conf. on Testbeds and Research Infrastructures for the Developmentof Networks & Communities (TridentCom 2009), Washington DC (USA), April 2009.

M2 Fermın Galan, Jorge E. Lopez de Vergara, David Fernandez and Raul Munoz, A Model-driven Configuration Management Methodology for Testbed Infrastructures, Proc. of the11th IEEE/IFIP Int’l Conf. on Network Operations and Management Symposium (NOMS08), Salvador da Bahia (Brazil), pp. 747-750, April 2008.

8.2.2 VNUML Publications

The most relevant publication in this category is V1, which provides a description of the tooland its most relevant use cases along its history. The tool description is also addressed in V9 andV17. Other publications describe in detail use cases in different fields: IPv6 routing architectures(V18), multimedia service platforms (V7 and V13), optical networking testbeds (V10 and V11),networking educational laboratories (V4, V6, V14, V15 and V16) and logical security (V12).Finally, the evolution of VNUML to multi-host deployment environments (EDIV) is describedin V3, V5 and V8, and the EDIV PASITO experiments in V2.

V1 Fermın Galan, David Fernandez, Walter Fuertes, Miguel Gomez and Jorge Lopez de Ver-gara, Scenario-based Virtual Network Infrastructure Management in Research and Edu-cational Testbeds with VNUML: Application Cases and Current Challenges, in Annalsof Telecommunications, special issue on Virtualization: a path for the Future Internet,vol. 64(5), pp. 305-323, May 2009. http://dx.doi.org/10.1007/s12243-009-0104-3.(JCR).

V2 Fermın Galan, David Fernandez, Jorge E. Lopez de Vergara and Francisco Monserrat,Demo of EDIV: Building and managing distributed virtualization scenarios in federatedtestbed infrastructures, Proc. of the 5th IEEE Int’l Conf. on Testbeds and Research Infra-structures for the Development of Networks & Communities (TridentCom 2009), Wash-ington DC (USA), April 2009.

V3 Fermın Galan, David Fernandez, Miguel Ferrer and Francisco J. Martın, Scenario-basedDistributed Virtualization Management Architecture for Multi-host Environments, Proc.of the 2nd DMTF System and Virtualization Management Workshop (SVM 2008), CCIS18, pp. 49-60, Munich (Germany), October 2008.

V4 Francisco Ruiz, David Fernandez, Fermın Galan and Luis Bellido, Modelo de LaboratorioDocente de Telematica basado en Virtualizacion Distribuida, VII Jornadas de IngenierıaTelematica (JITEL 2008), Alcala de Henares (Spain), September 2008.


V5 Walter Fuertes, Jorge E. Lopez de Vergara, Fermın Galan and David Fernandez, Propuestapara el Despliegue de Escenarios de Red Virtuales en Entornos Distribuidos, VII Jornadasde Ingenierıa Telematica (JITEL 2008), Alcala de Henares (Spain), September 2008.

V6 David Fernandez, Fermın Galan, Francisco J. Ruiz, Luis Bellido and Omar Walid, Usode tecnicas de virtualizacion en laboratorios docentes de redes, Boletın de RedIRIS, vol.82-83, pp. 70-75, April 2008.

V7 Miguel Gomez Rodrıguez, Fermın Galan Marquez and Emilio J. Torres Mateos, A 3GPPSystem Architecture Evolution Virtualized Experimentation Infrastructure for Mobility Pro-totyping (Invited Paper), Proc. of the 4th Int’l Conf. on Testbeds and Research Infrastruc-tures for the Development of Networks & Communities (TridentCom 2008), Innsbruck(Austria), March 2008.

V8 Fermın Galan and David Fernandez, Distributed Virtualization Scenarios Using VNUML,Proc. of the 1st DMTF System and Virtualization Management Workshop (SVM 2007),Toulouse (France), October 2007.

V9 Fermın Galan and David Fernandez, Experiencias de uso de la herramienta VNUML enla creacion de escenarios de red virtuales, invited speech at Grupos de Trabajo RedIRIS2007 RTIRIS-23, ETSIT UPM, Madrid (Spain), June 2007.

V10 Fermın Galan, Raul Munoz and Ricardo Martınez, Control plane virtual extension forGMPLS-based optical networking testbeds, VI Workshop in MPLS/GMPLS networks, Giro-na (Spain), April 2007.

V11 Fermın Galan, Raul Munoz and Ricardo Martınez, Uso de tecnicas de virtualizacion parala experimentacion en redes opticas basadas en GMPLS y DWDM, XVI Jornadas TelecomI+D, Madrid (Spain), November 2006.

V12 Fermın Galan and David Fernandez, Use of VNUML in Virtual Honeynets Deployment,IX Reunion Espanola sobre Criptologıa y Seguridad de la Informacion (RECSI), Barcelona(Spain), September 2006.

V13 Fermın Galan, Emilio Garcıa, Carlos Chavarri, Miguel Gomez and David Fernandez, De-sign and Implementation of an IP Multimedia Subsystem (IMS) Emulator Using Virtual-ization Techniques, Proc. of the 13th HP OpenView University Association (HP-OVUA)Workshop, pp. 213-224, Nice (France), May 2006.

V14 David Fernandez, F. Javier Ruiz Pinar, Fermın Galan, Vicente Burillo and Tomas deMiguel, Mejorando el aprendizaje en los laboratorios de redes y servicios mediante el usode herramientas de virtualizacion, Primeras Jornadas de Innovacion Educativa ETSIT-UPM, Madrid (Spain), December 2005.

V15 David Fernandez, F. Javier Ruiz Pinar, Fermın Galan, Vicente Burillo and Tomas deMiguel, Uso de tecnicas de virtualizacion para mejorar la docencia en laboratorios de redesde comunicaciones, V Jornadas de Ingenierıa Telematica (JITEL 2005), Vigo (Spain),September 2005.

8.3. FUTURE WORK 169

V16 Fermın Galan, David Fernandez, Javier Ruiz, Omar Walid and Tomas de Miguel, A Vir-tualization Tool in Computer Network Laboratories, Proc. of the 5th Int’l Conf. on Infor-mation Technology Based Higher Education and Training (ITHET’04), Istanbul (Turkey),May 2004.

V17 Fermın Galan and David Fernandez, VNUML: Una herramienta de virtualizacion de redesbasada en Software Libre, Open Software World Conference (OSWC’04), Malaga (Spain),February 2004.

V18 David Fernandez, Fermın Galan and Tomas de Miguel, Study and Emulation of IPv6Internet Exchange (IX) based Addressing Models, in IEEE Communications Magazine,vol. 42(1), pp. 105-112, January 2004. (JCR).

8.2.3 ADNETCONF Publications

The patent request in A1 discloses a model-based method for deployment, undeployment andmonitoring of IP logical networks on top existing physical networking infrastructures. Thus, thepatent request can be applied to the experimentation infrastructures field, being a scenario-basedconfiguration management methodology for three particular operations (deployment, undeploy-ment and monitoring) for a particular kind of testbeds (distributed and IP-based). An earlydescription of ADNETCONF is provided in A3, then evolved in A2. The latter can be conside-red the application of the general method described in the patent request A1 to the particularcase of the ADRENALINE testbed.

A1 Fermın Galan, Raul Munoz, Method For Logical Deployment, Undeployment and Mo-nitoring of a Target IP Network, request (PCT/EP2006/009960) October 2006, WIPOPublication with ISR (WO2008/046429) April 2008. (Patent).

A2 Fermın Galan and Raul Munoz, An Automatic Model-based Reconfiguration and Monito-ring Mechanism for Flexible GMPLS-based Optical Networking Testbeds, Proc. of the 11th

Int’l Conf. on Optical Network Design and Management (ONDM 2007), Athens (Greece),LNCS 4534, pp. 239-248, Springer, May 2007.

A3 Fermın Galan, Raul Munoz and Ricardo Martınez, Demo of ADNETCONF: ADRENA-LINE’s tool for dynamic configuration of GMPLS-based all optical transport networks,Proc. of the 2nd IEEE Int’l Conf. on Testbeds and Research Infrastructures for the De-velopment of Networks & Communities (TridentCom 2006), Barcelona (Spain), March2006.

8.3 Future Work

Regarding future working lines for research, our aim is to follow two different directions. Oneof them is to explore new ways to use the architecture. This includes bringing into realitythe novel testbed approaches described in Chapter 7. One case are Future Internet federatedtestbeds (GENI, FEDERICA, etc.) (Sections 7.3). In this line, scenario splitting capabilitiesat TIM layer would be introduced and the Subscenario Interconnection Model developed. Theother novel approach is WBEM-based testbeds (Section 7.4) as new paradigm to implement


scenario-based management. Note that some of these works can imply extensions to the TIM,i.e. to specialize node and link semantics to describe specific resources for federated testbed oradding scenario-oriented methods to TIM classes for WBEM-based methods.

Another different line, which is discussed more in detail in the following subsections, is onenhancements in the model-driven architecture independently of its application to particulartestbed kinds.

8.3.1 Experiment Dynamics Modeling

Although TIM aims at completeness, and in fact this is one of its design principles described inSection 4.3.1, the current model (as described in Chapter 5 in detail) has focused on structuralaspects of networking scenarios. Dynamic behavior modeling has been left out up to now. Inparticular, the ability to describe a sequence of events changing the status of scenario nodes andlinks and taking place at precise moments of time, using as t = 0 reference the moment in whichthe experiment starts. For example, to describe that a given link goes down at t = 2s, then goesup again at t = 5s or that a given process in a node has to be stopped at t = 9s.

This capability is very useful in some experimentation contexts, e.g. to test how a dynamicrouting protocol reacts to changes in the topology. As can be observed in Table 4.1, some ofthe existing testbeds and tools (Emulab and Weevil) are actually implementing this kind ofexperiment dynamics modeling.

Thus, this line of work addresses the definition of a TIM Module to describe dynamic behaviorbased on sequences of events. In order to do so, the CIM Schema should be reviewed in orderto find whether some semantically close classes could be reused. In negative case, the neededfunctionality would have to be defined in an ad hoc Extension Model. Additional works toreview would be the ongoing ones currently developed by DMTF related with CIM State andBehaviour [Sch07], and behavioral modeling provided by UML, e.g. sequence diagrams. Oncethis Module has been developed, the validation test in Chapter 6 should be expanded to showhow a TIM-to-TSM transformation uses this information to generate the corresponding specificevents sequence description for a testbed supporting this feature (e.g. Emulab).

8.3.2 Constrains Modeling

Currently, the only restrictions that are associated to the TIM regarding the base CIM Schemaclasses and associations in which it is based on are a limited set of properties and the to-tal removal of methods (as explained in Section 4.3.4). However, additional constrains couldbe very interesting in two contexts. First, to define well-formedness restrictions, e.g. that aTIM LinkConnectivityCollection with MaxConnections equals to 3 must have no more thanthree associated IPProtocolEndpoints. Second, to specify user-defined constraints adapted tosome experimentation contexts, e.g. all IP addresses connected to the same subnet must bedifferent2.

Currently, the only way of ensuring these constraints is implementing the checking in theTIM-to-TSM transformation code. However, this is not the proper place, because of constraints

2The experimentation context associated to this constraint corresponds to the normal behavior of an IPnetwork. However, although in a production environment it is expected that all the IPs in a subnet are different,it should not be considered a well-formedness TIM restriction because in some experimentation contexts thisconstraint will not be necessarily used, e.g. to experiment with tools able to detect IP duplication problems andreact to them.

8.3. FUTURE WORK 171

should be intrinsic to TIM scenarios themselves. Constraint evaluation could be integrated inthe scenario design tools, which actually will become in design and validation tools.

In order to develop TIM constrains, several possibilities should be analyzed:

• Describe the constraints in natural language. This would be close to the DMTF profilesapproach (see Section 3.4.4) but its main drawback is that constraints expressed this waycannot automatically be checked by software tools. Therefore, it should be complementedwith one of the following approaches.

• Use OCL constraints (Section 3.2.2.4). Actually, in CIM specification [DMT08a] thereare two qualifiers (ClassConstraint and PropertyConstraint) that enable to define OCLconstraints within class scope3. However, they seem to have a limited intra-class scopeand it is not clear how to use them to express constraints involving several classes.

• Use ontologies (Section 3.2.3). As TIM is based on CIM and CIM can be expressed inontology languages (see Section 3.4.6), providing an ontological overlay for TIM shouldbe affordable. Constraints would be expressed in terms of this ontology. Note that anontological approach to TIM could have additional advantages, e.g. to find which networkscomply with concrete requirements [SMLPB08].

8.3.3 The Common Testbed Model

One of the functional components of our model-driven architecture are the testbed parameters,defined in Section 4.2 as “a description of the testbed environment, [which] depends on thetestbed nature”. They are merged to the TIM scenario as second input for the TIM-to-TSMtransformation to produce the final TSM.

However, the problem of how to represent testbed parameters has not been addressed as partof this work. In the current version of the model-driven architecture, parameters can be freelystructured as the TIM-to-TSM transformation designer desires. In particular, the testbed pa-rameters for the VNUML-based testbed and the ADRENALINE testbed considered in the exper-imental validation performed in Chapter 6 are flat tables encapsulated within CIM SettingDatainstances (as shown in Tables 6.3 and 6.4). Although this is a simple and straightforward ap-proach which fits for VNUML and ADNETCONF, it lacks formalisms and could be limitingwhen the parameters are complex. For example, it could be required as “parameter” a graphrepresenting the physical topology of the testbed (including maximum available bandwidth as-sociated to each physical link) because the transformation tries to produce the TSM that moreclosely resembles the scenario topology in the scenario-to-physical nodes mapping.

Therefore, it would be interesting to develop a common model to represent testbed param-eters, in the same way TIM provides a common representation for scenarios. Actually, thebest way of modeling testbed parameters is modeling the testbed itself, so it could be namedthe Common Testbed Model (CTM). In fact, some of the tools analyzed in Chapter 2 proposemodels for the underlying testbed, e.g. ModelNet (Section 2.3.3) or AnyBed (Section 2.5.2),but they are very limited and technology dependent. Using a common representation will easethe development of TIM-to-TSM transformations, because not only a vocabulary for the TIMis fixed, but also for the testbed parameters.

3There is also a MethodConstraint qualifier but, given that the TIM does not use methods, it is useless in ourcase.


In order to develop this CTM, an analysis of the existing testbed has to be done in order toget modeling requirements. Then, it should be desirable to use CIM to implement the CTM,to be aligned with TIM. As validation, the different testbeds described in Chapter 2 should bemoldable using the CTM.

8.3.4 Inverse Transformations

As shown in Figure 4.1, our model-driven configuration management approach is highly unidi-rectional. Starting with the TIM scenario, the TSM scenario is obtained through a TIM-to-TSMtransformation, but the TSM-to-TIM case has not been considered. Note that MDA is conside-ring inverse transformation (the PSM-to-PIM case described in Section 3.3.2.2).

TSM-to-TIM transformations can be useful to reuse existing scenarios defined for a testbedin a second testbed, without needing to manually define them at TIM layer. For example, theextensive set of scenarios already available for Emulab could be transformed to TIM applyingan inverse Emulab-to-TIM transformation, then transformed to be used with VNUML withthe direct TIM-to-VNUML transformation. It is worth noting that both steps would be doneautomatically.

The objective of this future work line is to evaluate which modifications are required in theconfiguration management architecture and associated elements (the TIM and the transforma-tion design methodology) in order to implement inverse transformation. A problem to solve ishow to “regenerate” the information that is lost in TSM due to TIM filtering, e.g. link QoScharacteristics are filtered in the TIM-to-VNUML transformation.

Appendix A

Conventions

A.1 Font Styles

Along this document, the following font style conventions are used:

• Italic style is used to highlight important concepts or terms. It is also used to mean filenames and console commands.

• Specially in Section 4.4.3 and Chapters 4 and 6, bold style is used for class propertiesand XML tags attributes. In addition, italic style is used for class, associations and XMLtag names.

• Specially in Chapter 6, Appendix B and Appendix C, monospaced style is used for ATLcode and Managed Object Format (MOF) fragments.

A.2 UML Graphical Notation Basics

This section provides a simplified description of the UML graphical notation used along thisdocument in several figures.

• Classes are represented using boxes. A class box is composed of two or three distinct areas(Figure A.1):

Prop1: stringProp2: uint16

Oper1(arg: string): uint32Oper2(): void

Name

Properties list

Operations list

Class name

Property typeProperty name

Parameters list

Operation nameReturned value type

Figure A.1: UML class notation

173

174 APPENDIX A. CONVENTIONS

– Class name. If the name appears in italics it represents an abstract class, i.e. a classthat can not be instantiated.

– Class properties1 list. Each property has a name and a type.

– Class operations2 list. It is not represented if the class does not include any operation.Each operation is defined by a name, a parameter lists (each one with name and type)and a return value type.

• Relationships are represented using lines with different decorations. There are three basicrelationships (Figure A.2):

ClassA

ClassB

ClassA

ClassB

ClassA

ClassB

ClassA

ClassB

0..1 0..1

endB endB

endA endA

InheritanceBidirectionalassociation

Unidirectionalassociation

Aggregation

Figure A.2: UML relationship notation

– Inheritance (solid arrow), to represent that one class derives from other. The arrowend is at the parent class, e.g. class B derives from class A.

– Association (straight line or clear arrow), to represent a given relationship betweentwo classes. Each association end has name (optional), multiplicity and navigation.

∗ Multiplicity is a range that specifies the number of objects of the class at thatend that can participate in the relationship. The asterisk symbol (‘*’) meansunbounded. The omission of multiplicity means and implicit 0..* or just *.

∗ Navigability is expressed with an empty arrow, meaning that the class at theend without the arrow can reach or navigate to the class at the end with thearrow. In the case of navigability in both directions, the association appears asa straight line between the two classes.

– Aggregation (clear diamond), to represent a container-part relationship. The dia-mond end is at the class representing the container, e.g. class A is the containerand class B the part. As with associations, multiplicity can be also specified at theaggregation ends.

1Also named attributes.2Also named methods.

Appendix B

TIM ad hoc Extension Model

This annex contains the MOF code corresponding to the TIM ad hoc Extension Model, i.e. allthe classes included in TIM but not in the standard DMTF’s CIM Schema.

// Testbed Independent Model (TIM) MOF specification, v0.2009_09_02

//

// This file can be mofified/distributed under the terms of

// Creative Commons Attribution-Share Alike 2.5 Spain License.

// See details at: http://creativecommons.org/licenses/by-sa/2.5/es/deed.en

//

// Copyright (C) 2008, 2009 Fermin Galan Marquez

// This is the Testbed Independent Model (TIM) specification

// conventional classes

[Version("2.22.0"),

Description(

"TIM_TestbedScenario models the scenario itself, as a specialization of CIM_Network." )]

class TIM_TestbedScenario : CIM_Network {

// No new information is yet required

};

[Version("2.22.0"),

Description(

"TIM_LinkConnectivityCollection models the scenario links (i.e. node"

"interconnections)." )]

class TIM_LinkConnectivityCollection : CIM_ConnectivityCollection {

[Description(

"The max number of connection allowed in the TIM_LinkConnectivityCollection. "

"For example, MaxConnections=2 implies a point-to-point connection." )]

uint16 MaxConnections;

};

[Version("2.22.0"),

Description(

"TIM_TransmissionCharacteristics objects encapsulate a"

"set of QoS constraints (delay, loss probability, etc.) for a pair of"

"interfaces belonging to the link (specified through the"

"TIM_LinkOrigin and TIM_LinkDestination)."

"It could be considered to model the TIM_TransmissionCharacteristics"

"as CIM_SettingData child. However, doing so would avoid to define new"

"key properties (because of, once keys has been defined in one level of the"

"inheritance hierarchy, no new ones can be added). Therefore, we are using"

"CIM_LogicalElements as parent." )]

class TIM_TransmissionCharacteristics : CIM_LogicalElement {

175

176 APPENDIX B. TIM AD HOC EXTENSION MODEL

[Key, Description (

"A string identifying the TIM_TransmissionCharacteristics object" )]

string InstanceID;

[Key, Description (

"The InstanceID propagated from the TIM_LinkConnectivityCollection"

"to which this TIM_TransmissionCharacteristics object is associated,"

"considering that TIM_TransmissionCharacteristics is weak to"

"TIM_LinkConnectivityCollection through the IM_LinkTransmissionElement"

"association." ),

Propagated ( "TIM_LinkConnectivityCollection.InstanceID" )]

string LinkInstanceID;

[Description("The mean transmission delay."),

Units ( "MilliSeconds" )]

uint64 DelayMean;

[Description("The transmission delay deviation.")]

real32 DelayDeviation;

[Description("The transmission delay distribution function (normal, uniform, etc.)." ),

ValueMap {"0","1","2"},

Values {"Normal","Uniform","Pareto"}]

uint16 DelayDistributionFunction;

[Description("The package loss probability value (0..1)." )]

real32 LossProbabilityValue;

[Description("The package loss probability correlation." )]

real32 LossProbabilityCorrelation;

[Description("The package corruption probability (0..1)." )]

real32 CorruptionProbabilityValue;

[Description("The package corruption probability correlation." )]

real32 CorruptionProbabilityCorrelation;

[Description("The package duplication probability value (0..1)." )]

real32 DuplicationProbabilityValue;

[Description("The package duplication probability correlation." )]

real32 DuplicationProbabilityCorrelation;

[Description("The package disordering probability value (0..1)." )]

real32 DisorderingProbabilityValue;

[Description("The package disordering probability correlation." )]

real32 DisorderingProbabilityCorrelation;

[Description("The link throughput." ),

Units ( "bps" )]

uint64 Throughput;

[Description("The maximum tranfer unit (MTU) in the link." ),

Units ( "bytes" )]

uint64 MTU;

};

[Version("2.22.0"),

Description(

"TIM_NextHopAddressIPRoute models static routes in scenario"

"nodes (CIM_ComputerSystem objects actually). It is needed because"

"of the existing CIM_NextHopIpRoute from it derives does not allow a"

"direct specification of the route destination (it uses the"

"CIM_AssociatedNextHop, which is not appropriated in some"

"situations) so the NextHopAddress field needs to be"

177

"introduced." )]

class TIM_NextHopAddressedIPRoute : CIM_NextHopIPRoute {

[Description("A IP value, specifying the next hop in the route.)" )]

string NextHopAddress;

};

[Version("2.22.0"),

Description(

"TIM_StaticIPv6AssignemntSettingData objects model network interface"

"IPv6 addresses. It is needed due to the existing CIM_StaticIPAssignmentSettingData"

"only considers IPv4 addresses." )]

class TIM_StaticIPv6AssignmentSettingData :

CIM_IPAssignmentSettingData {

[Description ("The IPv6 address that will be assigned to the ProtocolEndpoint.")]

string IPv6Address;

[Description ("The prefix lenght for the IPv6 address of this ProtocolEndpoint.")]

uint8 PrefixLength;

};

// association classes

// WARNING: some implementations of MOF compilers (at least the mofcomp that comes

// with WBEM Services) doesn’t work if ’Association’ qualifier is put the very first

// (before ’Version’).

[Association, Version("2.22.0"),

Description(

"TIM_LinkTransmissionElement associate TIM_TransmissionCharacteristics"

"objects to TIM_LinkConnectivityCollection." )]

class TIM_LinkTransmissionElement : CIM_HostedDependency {

[Description("The LinkConnectivityCollection modeling the link." ),

Override ("Antecedent"),

Max(1),

Min(1)]

TIM_LinkConnectivityCollection REF Antecedent;

[Description("The TransmissionCharacteristic associated to the link."),

Override ("Dependent"),

Weak]

TIM_TransmissionCharacteristics REF Dependent;

};


Description(

"TIM_MemberOfLink associate a TIM_LinkConnectivityConnection to"

"the CIM_IPProtocolEndPoints belonging to it." )]

class TIM_MemberOfLink : CIM_MemberOfCollection {

[Description("The LinkConnectivityCollection modeling the link." ),

Override ("Collection")]

TIM_LinkConnectivityCollection REF Collection;

[Description("The IPProtocolEndPoint member of the link."),

Override ("Member")]

CIM_IPProtocolEndPoint REF Member;

};


Description(

"TIM_LinkOrigin associates the origin CIM_IPProtocolEndPoint to"

178 APPENDIX B. TIM AD HOC EXTENSION MODEL

"the TIM_TransmissionCharacteristic object.")]

class TIM_LinkOrigin : CIM_Dependency {

[Description("The link origin IPProtocolEndPoint." ),


Max(1),

Min(1)]

CIM_IPProtocolEndPoint REF Antecedent;

[Description("The TransmissionCharacteristic."),


Min(0),

Max(1)]


};


Description(

"TIM_LinkDestination associates the destination CIM_IPProtocolEndPoint to"

"the TIM_TransmissionCharacteristic object.")]

class TIM_LinkDestination : CIM_Dependency {

[Description("The link destination IPProtocolEndPoint." ),


Max(1),

Min(1)]

CIM_IPProtocolEndPoint REF Antecedent;

[Description("The TransmissionCharacteristic."),


Min(0),

Max(1)]


};

Appendix C

Experimental Validation ATLTransformations

C.1 TIM-to-VNUML Transformation

C.1.1 TIM2VNUML.atl

-- This program is free software; you can redistribute it and/or

-- modify it under the terms of the GNU General Public License

-- as published by the Free Software Foundation; either version 2

-- of the License, or (at your option) any later version.

--

-- This program is distributed in the hope that it will be useful,

-- but WITHOUT ANY WARRANTY; without even the implied warranty of

-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

-- GNU General Public License for more details.

--

-- You should have received a copy of the GNU General Public License

-- along with this program; if not, write to the Free Software

-- Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

--

-- An online copy of the licence can be found at http://www.gnu.org/copyleft/gpl.html

--

-- Copyright (C) 2009 Fermin Galan Marquez

module TIM2VNUML; create OUT : VNUML from IN : TIM, SETTINGS : TestbedParameters;

uses TIMHelpers;

-------------

-- Helpers --

-------------

-- Return the VNUML setting object

helper def: settings : TestbedParameters!VNUMLTestbedParameters =

TestbedParameters!VNUMLTestbedParameters.allInstances()->first()

;

-- Calculates the id associated to a given interface

helper def: idForIntf(intf: TIM!CIM_IPProtocolEndpoint) : Integer =

if not intf.isLoopback()

then

(intf.associatedVm()).vmInterfaces()->select(e | not e.isLoopback())->indexOf(intf)

else

(intf.associatedVm()).vmInterfaces()->select(e | e.isLoopback())->indexOf(intf)

endif

;

179

180 APPENDIX C. EXPERIMENTAL VALIDATION ATL TRANSFORMATIONS

-- Calculates the net name associated to a given interface (or

-- loopback, if the interface is not) associated to any net

helper def: netNameForIntf(intf : TIM!CIM_IPProtocolEndpoint) : String =

if not intf.isLoopback()

then

TIM!TIM_MemberOfLink.allInstances()->select(e | e.Member->first() = intf)->first().Collection->first().InstanceID

else

’lo’

endif

;

-----------

-- Rules --

-----------

rule MasterRule {

from

i: TIM!TIM_TestbedScenario

to

-- Rule #1a: one Vnuml instance for each given TIM_TestbedScenario

Vnuml: VNUML!Vnuml (

global <- Global,

net <- TIM!TIM_LinkConnectivityCollection.allInstances()->collect (e | thisModule.resolveTemp(e,’Net’)),

vm <- TIM!CIM_ComputerSystem.allInstances()->collect (e | thisModule.resolveTemp(e,’Vm’))

),

-- Rule #1b: one Global instance for each given TIM_TestbedScenario

Global: VNUML!Global (

simulationName <- SimulationName,

version <- Version,

vmDefaults <- VmDefaults

),

SimulationName: VNUML!SimulationName (

-- Rule #2: The SimulationName _text property is set using Name in TIM_TestbedScenario

_text <- i.Name

),

Version: VNUML!Version (

-- Use of parameter: version

_text <- thisModule.settings.specVersion

),

VmDefaults: VNUML!VmDefaults (

-- Use of parameter: defaultExecMode

execMode <- thisModule.settings.defaultExecMode,

filesystem <- Filesystem,

kernel <- Kernel,

console <- Console

),

Filesystem: VNUML!Filesystem (

-- Use of parameters: defaultFilesystemType and defaultFilesystem

type <- thisModule.settings.defaultFilesystemType,

_text <- thisModule.settings.defaultFilesystem

),

Kernel: VNUML!Kernel (

-- Use of parameter: defaultKernel

_text <- thisModule.settings.defaultKernel

),

Console: VNUML!Console (

-- Use of parameter: defaultConsole

id <- ’0’,

_text <- thisModule.settings.defaultConsole

)

do {

-- Use of parameter: automac

-- We need do this after the execution of the rule, otherwise, Global object would not

-- exists. The SetAutomac is an imperative rule, called from a relation rule

if(thisModule.settings.automac)

thisModule.SetAutomac(Global);

C.1. TIM-TO-VNUML TRANSFORMATION 181

-- Use of parameter: mgmtType

-- We need do this after the execution of the rule, otherwise, Global object would not

-- exists. The SetMgmtType is an imperative rule, called from a relation rule

if(not thisModule.settings.mgmtType.oclIsUndefined())

thisModule.SetMgmtType(Global);

}

}

rule SetAutomac(g : VNUML!Global) {

to

Automac: VNUML!Automac

do {

g.automac <- Automac;

}

}

rule SetMgmtType(g : VNUML!Global) {

to

VmMgmt: VNUML!VmMgmt (

type <- thisModule.settings.mgmtType

)

do {

g.vmMgmt <- VmMgmt;

}

}

-- Rule #3: each Vm instance corresponds to one ComputerSystem instance

rule VmMap {

from

i: TIM!CIM_ComputerSystem

to

Vm: VNUML!Vm (

-- Rule #6: the name property in Vm is set using the Name property in ComputerSystem

name <- i.Name,

forwarding <- i.vmForwarding()->collect(e | thisModule.resolveTemp(e,’Forwarding’))->first(),

route <- i.vmRoutes()->collect (e | thisModule.resolveTemp(e,’Route’)),

intf <- i.vmInterfaces()->collect (e | thisModule.resolveTemp(e,’Intf’))

)

}

-- Rule #4: each Net instance corresponds to one TIM_LinkConnectivityConnection instance

rule NetMap {

from

i: TIM!TIM_LinkConnectivityCollection

to

Net: VNUML!Net (

-- Rule #5: name property in Net is set using InstanceID property

-- in TIM LinkConnectivityConnection

name <- i.InstanceID,

-- Use of parameter: netMode

mode <- thisModule.settings.netMode

)

}

-- Rule #7: each Forwarding instance corresponds to one instance of ForwardingService in TIM

rule ForwardingMap {

from

i: TIM!CIM_ForwardingService

to

Forwarding: VNUML!Forwarding (

-- Rule #8: mapping ProtocolType to type

type <- (if i.ProtocolType = 2 then

’ipv4’

else

if i.ProtocolType = 3 then


’ipv6’

else

-- i.ProtocolType = 4

’ip’

endif

endif )

)

}

-- Rule #9: Each Route instance corresponds to one instance of TIM_NextHopAddressedIPRoute

rule RouteMap {

from

i: TIM!TIM_NextHopAddressedIPRoute

to

Route: VNUML!Route (

-- Rule #10: the type property is set using AddressType

type <- (if i.AddressType = 1 then ’ipv4’ else ’ipv6’ endif),

-- Rule #11: the gw property is set using NextHopAddress

gw <- i.NextHopAddress,

-- Rule #12: the _text property is composed by a combined mapping of DestinationAddress and

-- DestinationMask or PrefixLength (for IPv4 or IPv6 respectively)

_text <- (if i.AddressType = 1 then

-- IPv4

i.DestinationAddress + ’/’ + i.DestinationMask.TranslateMask()

else

-- IPv6

i.DestinationAddress + ’/’ + i.PrefixLength.toString()

endif)

)

}

-- Rule #13: each Intf instance corresponds to one instance of IPProtocolEndpoing

rule IntfMap {

from

i: TIM!CIM_IPProtocolEndpoint

to

Intf: VNUML!Intf (

id <- thisModule.idForIntf(i).toString(),

-- Rule #14: The net property is set using the InstanceID name of the

-- TIM_LinkConnectivityCollection associated to the interface (through the TIM_MemberOfLink

-- association) except when that association does not exists (i.e. loopback interface)

-- in which case the "lo" string is assigned (see netNameForIntf helper)

net <- thisModule.netNameForIntf(i),

ipv4 <- i.intfIpv4()->collect (e | thisModule.resolveTemp(e,’Ipv4’)),

ipv6 <- i.intfIpv6()->collect (e | thisModule.resolveTemp(e,’Ipv6’))

)

}

-- Rule #15: each Ipv4 instance corresponds to one instance of StaticIPAssignmentSettingData

rule Ipv4Map {

from

i: TIM!CIM_StaticIPAssignmentSettingData

to

Ipv4: VNUML!Ipv4 (

-- Rule #16 mapping IPv4Address to text

_text <- i.IPv4Address,

-- Rule #17 mapping SubnetMask to mask

mask <- i.SubnetMask

)

}

-- Rule #18: Each Ipv6 instance corresponds to one instance of TIM StaticIPv6AssignmentSettingData

rule Ipv6Map {

from

i: TIM!TIM_StaticIPv6AssignmentSettingData

to

Ipv6: VNUML!Ipv6 (

C.1. TIM-TO-VNUML TRANSFORMATION 183

-- Rule #19: mapping IPv6Address to text

_text <- i.IPv6Address,

-- Rule #20: mapping PrefixLength to mask

mask <- ’/’ + i.PrefixLength.toString()

)

C.1.2 TIM2VNUMLOspf.atl





--





--




--


--


module TIM2VNUMLOspf;

create OUT : VNUMLOspf from IN : TIMOspf, SETTINGS : TestbedParameters;

uses TIMHelpers;

-------------

-- Helpers --

-------------

-- Return the VNUML setting object

helper def: settings : TestbedParameters!VNUMLTestbedParameters =

TestbedParameters!VNUMLTestbedParameters.allInstances()->first()

;

-----------

-- Rules --

-----------

rule MasterRule {

from

i: TIMOspf!TIM_TestbedScenario

to

-- Rule #21: There is one OspfConf instance for each given TIM_TestbedScenario

OspfConf: VNUMLOspf!OspfConf (

vm <- TIMOspf!CIM_OSPFService.allInstances()->collect (e | thisModule.resolveTemp(e,’Vm’))

)

}

-- Rule #22: Each Vm instance corresponds to one instance of OSPFService in TIM

rule VmMap {

from

i: TIMOspf!CIM_OSPFService

to

Vm: VNUMLOspf!Vm (

-- Rule #23: name is set using the Name of the ComputerSystem associated to OSPF service

-- (through the HostedService association, see associatedComputerSystem helper)

name <- i.associatedComputerSystem().Name,

-- Use of parameters: ospfType and ospfSubType

type <- thisModule.settings.ospfType,

subtype <- thisModule.settings.ospfSubType,


zebra <- Zebra,

network <- i.allServiceIPRanges()->collect (e | thisModule.resolveTemp(e,’Network’))

),

Zebra: VNUMLOspf!Zebra (

-- Rule #24 The hostname in Zebra is set using the Name of the ComputerSystem associated

-- to the OSPFService (through the HostedService, see associatedComputerSystem helper)

hostname <- i.associatedComputerSystem().Name,

-- Use of parameter: ospfPassword

password <- thisModule.settings.ospfPassword

)

do {

-- Use of parameter: zebraBinPath

-- We need do this after the execution of the rule, otherwise, Vm object would not

-- exists. The SetZebraBin is an imperative rule, called from a relation rule

if(not thisModule.settings.zebraBinPath.oclIsUndefined())

thisModule.SetZebraBin(Vm);

-- Use of parameter: ospfdBinPath

-- We need do this after the execution of the rule, otherwise, Vm object would not

-- exists. The SetOspfdBin is an imperative rule, called from a relation rule

if(not thisModule.settings.ospfdBinPath.oclIsUndefined())

thisModule.SetOspfdBin(Vm);

}

}

rule SetZebraBin(v : VNUMLOspf!Vm) {

to

ZebraBin: VNUMLOspf!ZebraBin (

_text <- thisModule.settings.zebraBinPath

)

do {

v.zebraBin <- ZebraBin;

}

}

rule SetOspfdBin(v : VNUMLOspf!Vm) {

to

OspfdBin: VNUMLOspf!OspfdBin (

_text <- thisModule.settings.ospfdBinPath

)

do {

v.ospfdBin <- OspfdBin;

}

}

-- Rule #25: Each pair of Ip and Area (within Network, which is actually

-- a structural class) corresponds to a combination of OSPFArea

-- and RangeOfIPAddresses associated through an OSPFAreaConfiguration instance

-- (through the AreaOfConfiguration and RangesOfConfiguration associations

-- respectively). The mapping is based on CIM_RangeOfIpAddress, which associated

-- area is calculated using the areaID helper (it could have be done in the opposite

-- way).

rule Network {

from

i: TIMOspf!CIM_RangeOfIPAddresses

to

Network: VNUMLOspf!Network (

ip <- Ip,

area <- Area

),

-- Rule #26: The _text and mask properties in Ip are derived from the

-- AddressType, StartAddress and EndAddress in the RangeOfIPAddresses

-- instance (see commonMask helper)

Ip: VNUMLOspf!Ip (

mask <- i.commomMask().toString(),

_text <- i.StartAddress

C.2. TIM-TO-ADNETCONF TRANSFORMATION 185

),

-- Rule #27: the _text property in Area is derived from the AreaID property

-- in the OSPFArea instance (see areaID helper)

Area: VNUMLOspf!Area (

_text <- i.areaID().translateIp()

)

}

C.2 TIM-to-ADNETCONF Transformation

C.2.1 TIM2ADNETCONF.atl





--





--




--


--


module TIM2ADNETCONF;

create OUT : ADNETCONF from IN : TIM, SETTINGS : TestbedParameters;

uses TIMHelpers;

-------------

-- Helpers --

-------------

-- Return the ADNETCONF setting object

helper def: settings : TestbedParameters!ADRENALINETestbedParameters =

TestbedParameters!ADRENALINETestbedParameters.allInstances()->first()

;

-- Use of parameter: baseMgtAddress

helper def: managementIp : Integer = thisModule.settings.baseMgtAddress;

-- Use of parameter: baseVlan

helper def: currentVlan : Integer = thisModule.settings.baseVlan;

-- Use of parameter: baseConnectAddress

helper def: currentConnectIp: Integer = thisModule.settings.baseConnectAddress;

helper def: gre: Integer = 0;

-----------

-- Rules --

-----------

rule MasterRule {

from

i: TIM!TIM_TestbedScenario

to

-- Rule #1: There is one instance of AdrenalineNetconf, Links and Nodes for


-- each given TIM_TestbedScenario

AdrenalineNetconf: ADNETCONF!AdrenalineNetconf (

-- Rule #2: The name property in AdrenalineNetconf is set with Name

-- property from TIM_TestbedScenario

name <- i.Name,

nodes <- Nodes,

links <- Links

),

Nodes: ADNETCONF!Nodes (

node <- TIM!CIM_ComputerSystem.allInstances()->collect (e | thisModule.resolveTemp(e,’Node’))

),

Links: ADNETCONF!Links (

-- The ->select is needed to not break when there is no suitable link (eg. basic scenario)

link <- TIM!TIM_LinkConnectivityCollection.allInstances()->select(e | e.MaxConnections = 2)->collect (e |

thisModule.resolveTemp(e,’Link’))

)

}

-- Rule #3: Each Node instance corresponds to one instance of ComputerSystem in TIM

rule NodeMap {

from

i: TIM!CIM_ComputerSystem

to

Node: ADNETCONF!Node (

-- Rule #4: The id property in Node is set using the Name property in ComputerSystem

id <- i.Name,

loIp <- LoIp,

mIp <- MIp,

zebraBin <- ZebraBin,

ospfdBin <- OspfdBin

),

LoIp: ADNETCONF!LoIp (

-- Rule #5: The text property in LIp is set with the IPv4Address property in

-- StaticIPAssignmentSettingData associated to the loopback IPProtocolEndpoint9 (through

-- the ElementSettingData association) which, in sequence, is associated to the

-- ComputerSystem (through the HostedAccessPoint association); if there is no associated

-- loopback interface, _text gets empty (see isLoopback helper)

_text <- if i.vmInterfaces()->select(e | e.isLoopback())->size() > 0

then

(i.vmInterfaces()->select(e | e.isLoopback())->first()).intfIpv4()->first().IPv4Address

else

’’

endif

),

MIp: ADNETCONF!MIp (

-- managementIp originally set with baseMgtAddress parameter, then

-- increased in sequence (see do block at rule end)

_text <- thisModule.managementIp.translateIp()

),

ZebraBin: ADNETCONF!ZebraBin (

-- Use of parameter: zebraBinPath

_text <- thisModule.settings.zebraBinPath

),

OspfdBin: ADNETCONF!OspfdBin (

-- Use of parameter: ospfdBinPath

_text <- thisModule.settings.ospfdBinPath

)

do {

thisModule.managementIp <- thisModule.managementIp +1;

}

}

-- Rule #6: Each Link instance corresponds to one instance of TIM_LinkConnectivityCollection

-- in TIM with MaxConnections equal to 2 (others are ignored), that is PPP links

rule LinkMap {

from


i: TIM!TIM_LinkConnectivityCollection (

i.MaxConnections = 2

)

to

Link: ADNETCONF!Link (

peer <- Sequence { Peer1, Peer2 },

qos <- i.linkQoS()->collect (e | thisModule.resolveTemp(e,’Qos’))->first()

),

-- Rule #7: A first instance of Peer sets its node property with

-- the Name property in the ComputerSystem associated with the

-- first IPProtocolEndPoint (through the HostedAccessPoint) association (see

-- associatedVm helper)

Peer1: ADNETCONF!Peer (

node <- (i.linkInterfaces()->at(1)).associatedVm().Name,

-- Use of testbed parameter:

vlan_dev <- thisModule.settings.vlanDev,

vlanConnection <- VlanConnection1

),

VlanConnection1: ADNETCONF!VlanConnection (

-- currentConnectIp originally set with baseConnectAddress, then increased in sequence

-- (see do block at rule end)

net <- thisModule.currentConnectIp.translateIp(),

gre <- Gre0,

vlan <- Vlan0

),

Vlan0: ADNETCONF!Vlan (

-- currentVlan originally set with baseVlan, then increased in sequence (see do

-- block at rule end)

_text <- thisModule.currentVlan.toString()

) ,

Gre0: ADNETCONF!Gre (

name <- Name0,

ip <- Ip0

),

Name0: ADNETCONF!Name (

_text <- ’gre’.concat(thisModule.gre.toString())

),

Ip0: ADNETCONF!Ip (

-- Rule #8: The _text property in Ip is set with the IPv4Address property

-- in the StaticIPAssignmentSettingData associated to the first

-- IPProtocolEndpoint (through the ElementSettingData association)

_text <- (i.linkInterfaces()->at(1)).intfIpv4()->first().IPv4Address

),

-- Rule #9: A second instance of Peer sets its node property with the

-- Name property in the ComputerSystem associated with the second

-- IPProtocolEndPoint (through the HostedAccessPoint) association)

-- (see associatedVm helper)

Peer2: ADNETCONF!Peer (

node <- (i.linkInterfaces()->at(2)).associatedVm().Name,

-- Use of testbed parameter:

vlan_dev <- thisModule.settings.vlanDev,

vlanConnection <- VlanConnection2

),

VlanConnection2: ADNETCONF!VlanConnection (

gre <- Gre1

),

Gre1: ADNETCONF!Gre (

name <- Name1,

ip <- Ip1

),

Name1: ADNETCONF!Name (

_text <- ’gre’.concat((thisModule.gre + 1).toString())

),

Ip1: ADNETCONF!Ip (

-- Rule #10: The _text property in Ip is set with the IPv4Address property

-- in the StaticIPAssignmentSettingData associated to the second

-- IPProtocolEndpoint (through the ElementSettingData association)


_text <- (i.linkInterfaces()->at(2)).intfIpv4()->first().IPv4Address

)

do {

thisModule.gre <- thisModule.gre + 2;

thisModule.currentVlan <- thisModule.currentVlan + 1;

thisModule.currentConnectIp <- thisModule.currentConnectIp + 4;

}

}

-- Rule #11: Each Qos instance corresponds to one instance of TIM_TransmissionCharacteristics

rule QosMap {

from

i: TIM!TIM_TransmissionCharacteristics

to

Qos: ADNETCONF!Qos

do {

-- Rule #12: Delay if the DelayMean in the TIM_TransmissionCharacteristics instance

-- has been set

-- We need do this after the execution of the rule, otherwise, Delay object would not

-- exists. The SetDelay is an imperative rule, called from a relation rule

if (not i.DelayMean.oclIsUndefined())

thisModule.SetDelay(Qos, i.DelayMean.toString());

-- Rule #14: Dup if the DuplicationProbabilityValue in the TIM_TransmissionCharacteristics

-- instance has been set

-- We need do this after the execution of the rule, otherwise, Dup object would not

-- exists. The SetDup is an imperative rule, called from a relation rule

if (not i.DuplicationProbabilityValue.oclIsUndefined())

thisModule.SetDup(Qos, i.DuplicationProbabilityValue.toString());

-- Rule #16: Drop if the LossProbabilityValue in the TIM_TransmissionCharacteristics

-- instance has been set

-- We need do this after the execution of the rule, otherwise, Drop object would not

-- exists. The SetDrop is an imperative rule, called from a relation rule

if (not i.LossProbabilityValue.oclIsUndefined())

thisModule.SetDrop(Qos, i.LossProbabilityValue.toString());

}

}

rule SetDelay(q : ADNETCONF!Qos, t: String) {

to

Delay: ADNETCONF!Delay (

-- Rule #13: _text is set with DelayMean

_text <- t

)

do {

q.delay <- Delay;

}

}

rule SetDup(q : ADNETCONF!Qos, t: String) {

to

Dup: ADNETCONF!Dup (

-- Rule #15: _text is set with DuplicationProbabilityValue

_text <- t

)

do {

q.dup <- Dup;

}

}

rule SetDrop(q : ADNETCONF!Qos, t: String) {

to

Drop: ADNETCONF!Drop (

-- Rule #17: _text is set with LossProbabilityValue


_text <- t

)

do {

q.drop <- Drop;

}

}

C.2.2 TIM2ADNETCONFOspf.atl





--





--




--


--


module TIM2ADNETCONFOspf;

create OUT : ADNETCONFOspf from IN : TIMOspf, SETTINGS : TestbedParameters;

uses TIMHelpers;

-------------

-- Helpers --

-------------

-- Return the ADNETCONF setting object

helper def: settings : TestbedParameters!ADRENALINETestbedParameters =

TestbedParameters!ADRENALINETestbedParameters.allInstances()->first()

;

-----------

-- Rules --

-----------

rule MasterRule {

from

i: TIMOspf!TIM_TestbedScenario

to

-- Rule #18: There is one OspfConf instance for each given TIM TestbedScenario

OspfConf: ADNETCONFOspf!OspfConf (

ospf <- TIMOspf!CIM_OSPFService.allInstances()->collect (e | thisModule.resolveTemp(e,’Ospf’))

)

}

-- Rule #19: Each Ospf instance corresponds to one instance of OSPFService in TIM

rule OspfMap {

from

i: TIMOspf!CIM_OSPFService

to

Ospf: ADNETCONFOspf!Ospf (

-- Rule #20: node property is set using the Name of the ComputerSystem associated

-- to OSPF service (through the HostedService association, see associatedComputerSystem

-- helper)

node <- i.associatedComputerSystem().Name,

network <- i.allServiceIPRanges()->collect (e | thisModule.resolveTemp(e,’Network’))


)

do {

-- Use of parameter: zebraLogPath

-- We need do this after the execution of the rule, otherwise, Ospf object would not

-- exists. The SetZebraLog is an imperative rule, called from a relation rule

if(not thisModule.settings.zebraLogPath.oclIsUndefined())

thisModule.SetZebraLog(Ospf);

-- Use of parameter: ospfLogPath


-- exists. The SetOspfdLog is an imperative rule, called from a relation rule

if(not thisModule.settings.ospfLogPath.oclIsUndefined())

thisModule.SetOspfLog(Ospf);

-- Use of parameter: password


-- exists. The SetPassword is an imperative rule, called from a relation rule

if(not thisModule.settings.password.oclIsUndefined())

thisModule.SetPassword(Ospf);

}

}

rule SetZebraLog(o : ANETCONFOspf!Ospf) {

to

ZebraLog: ADNETCONFOspf!ZebraLog (

_text <- thisModule.settings.zebraLogPath

)

do {

o.zebraLog <- ZebraLog;

}

}

rule SetOspfLog(o : ADNETCONFOspf!Ospf) {

to

OspfLog: ADNETCONFOspf!OspfLog (

_text <- thisModule.settings.ospfLogPath

)

do {

o.ospfLog <- OspfLog;

}

}

rule SetPassword(o : ADNETCONFOspf!Ospf) {

to

Password: ADNETCONFOspf!Password (

_text <- thisModule.settings.password

)

do {

o.password <- Password;

}

}

-- Rule #21: Each Network corresponds to a combination of OSPFArea and RangeOfIPAddresses

-- associated through an OSPFAreaConfiguration instance (through the

-- AreaOfConfiguration and RangesOfConfiguration associations, respectively). The mapping

-- is based on CIM_RangeOfIpAddress, which associated area is calculated using the areaID

-- helper (it could have be done in the opposite way).

rule Network {

from

i: TIMOspf!CIM_RangeOfIPAddresses

to

Network: ADNETCONFOspf!Network (

-- Rule #22: The text property in Network is derived from the AddressType, StartAddress

-- and EndAddress in the RangeOfIPAddresses instance

_text <- i.StartAddress + ’/’ + i.commomMask().toString(),

-- Rule #23: the area property in Area is derived from the AreaID property in the

-- OSPFArea instance

C.3. COMMON HELPERS 191

area <- i.areaID().translateIp()

)

}

C.3 Common Helpers

C.3.1 TIMHelpers.atl





--





--




--


--


library TIMHelpers;

-------------------------------

-- Helpers to manipulate IPs --

-------------------------------

helper context String def: TranslateMask() : String =

if (self = ’255.255.255.0’) then

’24’

else

if (self = ’255.255.0.0’) then

’16’

else

if (self = ’255.0.0.0’) then

’8’

else

’0’

endif

endif

endif

;

helper context Integer def: translateIp() : String =

self.div(256*256*256).toString() + ’.’

+ self.mod(256*256*256).div(256*256).toString() + ’.’

+ self.mod(256*256*256).mod(256*256).div(256).toString() + ’.’

+ self.mod(256*256*256).mod(256*256).mod(256).toString()

;

-- Returns the common mask between StartAddress and EndAddress in the

-- scoping CIM_RangeOfIPAddresses (0 if there is no common mask). This

-- method is hardwired to return 32 if both addresses are equal, covering

-- the current use cases (nsfnet, rediris). However, it should be improved

-- to a more functional implementation trying to use the following

-- Java code in ATL.

--

-- public static int commonMask(int startIp, int endIp) {

-- /* Perform a sequential bit shift until there is some diference */


-- for (int i = 1; i <= 32 ; i++) {

-- if ( startIp >> 32-i != endIp >> 32-i)

-- return i-1;

-- }

-- return 32;

-- }

helper context TIMOspf!CIM_RangeOfIPAddresses def: commomMask() : Integer =

if (self.StartAddress = self.EndAddress)

then

32

else

30

endif

;

----------------------------------------

-- Helpers to check object properties --

----------------------------------------

helper context TIM!CIM_IPProtocolEndpoint def: isLoopback () :

Boolean =

not TIM!TIM_MemberOfLink.allInstances()->exists(e | e.Member->first() = self)

;

------------------------------------------------------

-- Helpers to navigate through object relationships --

------------------------------------------------------

-- Returns all the CIM_StaticIPAssignmentSettingData associated

-- to a given CIM_IPProtocolEndpoint, navigating through

-- the CIM_ElementSettingData association

helper context TIM!CIM_IPProtocolEndpoint def: intfIpv4() : Sequence(TIM!CIM_StaticIPAssignmentSettingData) =

-- We have to use ->first() in the ManagemedElement because it is defined as "to-many" reference in the

-- TIM metamodel

TIM!CIM_ElementSettingData.allInstances()->iterate(e; res : Sequence(TIM!CIM_StaticIPAssignmentSettingData) =

Sequence {} |

if e.ManagedElement->first() = self

then

if e.SettingData->first().oclIsTypeOf(TIM!CIM_StaticIPAssignmentSettingData)

then

res->including(e.SettingData->first())

else

res

endif

else

res

endif

);

-- Returns all the TIM_StaticIPv6AssignmentSettingData associated

-- to a given CIM_IPProtocolEndpoint, navigating through

-- the CIM_ElementSettingData association

helper context TIM!CIM_IPProtocolEndpoint def: intfIpv6() : Sequence(TIM!TIM_StaticIPv6AssignmentSettingData) =

-- We have to use ->first() in the ManagemedElement because it is defined as "to-many" reference in the

-- TIM metamodel

TIM!CIM_ElementSettingData.allInstances()->iterate(e; res : Sequence(TIM!TIM_StaticIPv6AssignmentSettingData) =

Sequence {} |

if e.ManagedElement->first() = self

then

if e.SettingData->first().oclIsTypeOf(TIM!TIM_StaticIPv6AssignmentSettingData)

then

res->including(e.SettingData->first())

else

res

endif

else

res

endif

C.3. COMMON HELPERS 193

);

-- Returns all the CIM_IPProtocolEndpoint associated to a

-- given CIM_ComputerSystem, navigating through

-- the CIM_HostedAccessPoint association

helper context TIM!CIM_ComputerSystem def: vmInterfaces() : Sequence(TIM!CIM_IPProtocolEndpoint) =

TIM!CIM_HostedAccessPoint.allInstances()->iterate(e; res : Sequence(TIM!CIM_IPProtocolEndpoint) = Sequence {} |

if e.Antecedent = self

then

res->including(e.Dependent)

else

res

endif

);

-- Returns all the TIM_NextHopAddressedIPRoute associated

-- to a given CIM_ComputerSystem, navigating through

-- the CIM_HostedRoute association

helper context TIM!CIM_ComputerSystem def: vmRoutes() : Sequence(TIM!TIM_NextHopAddressedIPRoute) =

TIM!CIM_HostedRoute.allInstances()->iterate(e; res : Sequence(TIM!TIM_NextHopAddressedIPRoute) = Sequence {} |


then


else

res

endif

);

-- Returns all the CIM_ForwardingService associated to

-- a given CIM_ComputerSystem, navigating through

-- the CIM_HostedService association

helper context TIM!CIM_ComputerSystem def: vmForwarding() : Sequence(TIM!CIM_ForwardingService) =

TIM!CIM_HostedService.allInstances()->iterate(e; res : Sequence(TIM!CIM_ForwardingService) = Sequence {} |


then


else

res

endif

);

-- Returns all the CIM_IPProtocolEndpoint associated to

-- a given TIM_LinkConnectivityCollection, navigating through

-- the TIM_MemberOfLink association

helper context TIM!TIM_LinkConnectivityCollection def: linkInterfaces() :

Sequence(TIM!CIM_IPProtocolEndpoint) =

TIM!TIM_MemberOfLink.allInstances()->iterate(e; res : Sequence(TIM!CIM_IPProtocolEndpoint) = Sequence {} |

if e.Collection->first() = self

then

res->including(e.Member->first())

else

res

endif

);

-- Returns all the TIM_TransmissionCharacteristics associated to

-- a given TIM_LinkConnectivityCollection, navigating through

-- the TIM_LinkTransmissionElement association

helper context TIM!TIM_LinkConnectivityCollection def: linkQoS() :

Sequence(TIM!TIM_TransmissionCharacteristics) =

TIM!TIM_LinkTransmissionElement.allInstances()->iterate(e; res : Sequence(TIM!TIM_TransmissionCharacteristics)

= Sequence {} |


then

res->including(e.Dependent->first())

else

res


endif

);

-- Returns the CIM_ComputerSystem associated to a given

-- CIM_IPProtocolEndpoint, navigating through

-- the CIM_HostedAccessPoint association

helper context TIM!CIM_IPProtocolEndpoint def: associatedVm() :

TIM!CIM_ComputerSystem =

TIM!CIM_HostedAccessPoint.allInstances()->select(e | e.Dependent = self)->first().Antecedent

;

-- Returns the CIM_ComputerSystem associated to a

-- given CIM_OSPFService, navigating through

-- the CIM_HostedService association

helper context TIMOspf!CIM_OSPFService def: associatedComputerSystem() : TIMOspf!CIM_ComputerSystem =

TIMOspf!CIM_HostedService.allInstances()->select(e | e.Dependent = self)->first().Antecedent

;

-- Returns the CIM_RangeOfIPAddresses associated

-- to a given CIM_OSPFAreaConfiguration, navigating

-- through theCIM_RangesOfConfiguration association

helper context TIMOspf!CIM_OSPFAreaConfiguration def: allAreaConfIPRanges() :

Sequence(TIMOspf!CIM_RangeOfIPAddresses) =

TIMOspf!CIM_RangesOfConfiguration.allInstances()->iterate(e; res : Sequence(TIMOspf!CIM_RangeOfIPAddresses) =

Sequence {} |

if e.Dependent = self

then

res->including(e.Antecedent)

else

res

endif

);

-- Returns the CIM_RangeOfIPAddresses associated

-- to a given CIM_OSPFService, navigating

-- through the CIM_OSPFServiceConfiguration association

helper context TIMOspf!CIM_OSPFService def: allServiceIPRanges() : Sequence(TIMOspf!CIM_RangeOfIPAddresses) =

TIMOspf!CIM_OSPFServiceConfiguration.allInstances()->select(e | e.Antecedent =

self)->first().Dependent->allAreaConfIPRanges()

;

-- Returns the CIM_OSPFArea associated to a given

-- CIM_OSPFAreaConfiguration, navigating through the

-- CIM_AreaOfConfiguration association (note that

-- for each CIM_OSPFAreaConfiguration

-- there is only one CIM_OSPFArea)

helper context TIMOspf!CIM_OSPFAreaConfiguration def: ospfArea() : TIM!CIM_OSPFArea =

TIMOspf!CIM_AreaOfConfiguration.allInstances()->select(e | e.Dependent = self)->first().Antecedent

;

-- Returns the area ID associated to a given CIM_RangeOfIPAddresses (navigating through the CIM classes)

helper context TIMOspf!CIM_RangeOfIPAddresses def: areaID() : Integer =

TIMOspf!CIM_RangesOfConfiguration.allInstances()->select(e | e.Antecedent =

self)->first().Dependent->ospfArea().AreaID

;

Appendix D

Acronyms

ABNF Augmented Backus-Naur Form

ADNETCONF ADrenaline NETwork CONFigurator

ADRENALINE All-optical Dynamic REliable Net-work hAndLINg IP/Ethernet Gigabit traf-fic with QoS

ADSL Asymmetric Digital Subscriber Line

AM3 ATLAS MegaModel Management

API Application Programming Interface

AS Autonomous System

ASN Abstract Syntax Notation

AST Application Specific Topology (DRAGON)

ASTB Application Specific Topology Builder (DRAGON)

ASTDL AST Description Language (DRAGON)

ATL ATLAS Transformation Language

ATM Asynchronous Transfer Mode

BGP Borger Gateway Protocol

BNF Backus-Naur Form

bps bits per second

CIM Common Information Model

CIMOM Common Information Model Object Manager

CLP Command Line Protocol

195

196 APPENDIX D. ACRONYMS

CMOF Complete MOF

CMPI Common Management Provider Interface

CPU Central Processing Unit

CTM Common Testbed Model

CTTC Centre Tecnologic de Telecomunicacions de Catalunya

DAML DARPA Agent Markup Language

DARPA Defense Advanced Research Projects Agency

DETER DEfense Technology Experimental Research

DMTF Distributed Management Task Force

DOM Document Object Model

DRAGON Dynamic Resource Allocation via GMPLS Optical Networks

DTD Document Type Definition

DWDM Dense Wavelength Division Multiplexer

EBNF Extended Backus-Naur Form

EC European Comission

EC2 Elastic Compute Cloud

ECUTE Extensible CIM UML Tooling Environment

EDIV Escenarios DIstribuidos con VNUML (Spanish)

EMF Eclipse Modeling Project

EMOF Essential MOF

ERD Entity Relationship Diagram

ERM Entity Relationships Model

eTOM Enhanced Telecom Operations Map

FEDERICA Federated E-Infrastructure Dedicated to European Researchers Innovating inComputing Network Architectures

FIND Future InterNet Design

FIRE Future Internet Research and Experimentation

197

FLOWR For, Let, Order By, Where and Return

FP7 Framework Program 7

FTP File Transfer Protocol

GB GigaByte

Gbps Gibabits per second

GDMO Guidelines for the Definition of Managed Objects

GENI Global Environment for Network Innovations

GHz Gigahertz

GINI GINI is not Internet

GLIF Global Lambda Integrated Facility

GMPLS Generalized Multi-Protocol Label Switching

GNU GNU is Not Unix

GRE Generic Routing Encapsulation

GUI Graphic User Interface

HTTP HyperText Transfer Protocol

ID IDentifier

IDE Integrated Development Environment

IDL Interface Definition Language

IEC International Electrotechnical Commission

IMS IP Multimedia Subsystem

IOS Internetwork Operating System (Cisco)

IP Internet Protocol

IPv4 IP version 4

IPv6 IP version 6

ISO International Organization for Standardization

ISR International Search Report

IT Information Technology


ITU International Telecommunication Union

J2EE Java 2 Enterprise Edition

JCR Journal Citation Reports

JVM Java Virtual Machine

KVM Kernel Virtual Machine

LAN Local Area Network

LRM Link Resource Manager (ADRENALINE)

LSP Label Switched Path

M2M Model-to-Model (transformation)

M2T Mode-to-Text (transformation)

MAC Media Access Control

MDA Model Driven Architecture

MDD Model Driven Development

MDE Model Driven Engineering

MIB Management Information Base

MIF Management Information Format

MLN Manage Large Networks

MOF Managed Object Format (DMTF)

MOF Meta Object Facility (OMG)

MPLS Multi-Protocol Label Switching

MTU Maximum Transmission Unit

NDL Network Description Language

NE Network Equipment

NGOSS New Generation Operations Systems and Software

NLR National Lambda Rail

NM Node Manager (PlanetLab)

199

NML Network Markup Language

NREN National Research & Education Network

NSF National Science Foundation

NoSE Network Simulation Environment

OCC Optical Connection Controller (ADRENALINE)

OCL Object Constraint Language

OCML Operational Conceptual Modeling Language

OGF Open Grid Forum

OIL Ontology Inference Layer

OKBC Open Knoledge Base Connectivity

OLRM Optical Link Resource Manager (ADRENALINE)

OM Overlay Managers (GX-Bone)

OMG Object Management Group

ORBIT Open Access Research Testbed for Next-Generation Wireless Networks

ORCA Open Resource Control Architecture

OS Operating System

OSPF Open Shortest Path First

OSPF-TE OSPF Traffic Enginering

OVF Open Virtualization Format

OWL Web Ontology Language

P2P Peer-to-Peer

PASITO Plataforma de Analisis de Servicios de Telecomunicaciones (Spanish)

PC Personal Computer

PCT Patent Cooperation Treaty

PDF Portable Document Format

PII Panlab II

PIM Platform Independent Model

PL PlanetLab


PLC PlanetLab Central

PPP Point-to-Point Protocol

PRIME Parallel Real-time Immersive network Modeling Environment

PSM Platform Specific Model

QVT Queries/Views/Transformations

QVTc QVT Core

QVTo QVT Operational

QVTr QVT Relations

QoS Quality of Service

RAM Random-Access Memory

RD Resource Daemons (GX-Bone)

RDF Resource Description Framework

RDF(S) Resource Description Framework Schema

RFP Request for Proposals

RIP Routing Information Protocol

RPC Remote Procedure Call

RPM RPM Package Manager

RSVP Resource ReSerVation Protocol

RSVP-TE RSVP Traffic Engineering

SAX Simple API for XML

SBLIM Standards-Based Linux Instrumentation for Manageability

SDD Solution Deployment Descriptor

SGML Standard Generalized Markup Language

SHARP Secure Highly Available Resource Peering (PlanetLab)

SHOE Simple HTML Ontology Extensions

SID Shared Information/Data Model

SM Server Management

201

SMI Structure of Management Information

SMIng SMI Next Generation

SMIv2 SMI version 2

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SQL Structured/Standard Query Language

SSH Secure Shell

STP Shielded Twisted Pair

SUE System Under Evaluation

SWORD Scalable Wide-Area Resource Discovery (PlanetLab)

SWRL Semantic Web Rule Language

SysML System Modeling Language

T2M Text-to-Model (transformation)

TCP Transmission Control Protocol

TDM Time Division Multiplexing

TIED Trial Integration Environment in DETER (GENI)

TIM Testbed Independent Model

TMF TeleManagement Forum

TSM Testbed Specific Model

UDP User Datagram Protocol

UML User Mode Linux (virtualization technology)

UML Unified Modeling Language (OMG)

UNI User Network Interface

URI Uniform Resource Identifier

UTP Unshielded Twisted Pair

vBET VM-Based Emulation Testbed

VCT Virtual Customer Testbed (PII)


VINI Virtual Network Infrastructure

VIOLIN Virtual Internetworking on OverLay INfrastructure

VLAN Virtual Local Area Network

VM Virtual Machine

VMM Virtual Machine Monitor

VN Virtual Node (ModelNet)

VNE Virtual Network Experiment

VNUML Virtual Network User Mode Linux

VNUMLGUI VNUML Graphic User Interface

VPN Virtual Private Network

W3C World Wide Web Consortium

WBEM Web-Based Enterprise Management

WDM Wavelength Division Multiplexing

WSDL Web Service Description Language

WHYNET Wireless Hybrid NETwork

WIPO World Intellectual Property Organization

WS Web Service

XHTML Extensible Hypertext Markup Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

XOL X-Bone Overlay Language (GX-Bone)

XOL XML Ontology exchange Language (ontology)

XSD XML Schema Definition

XSL eXtensible Stylesheets Language

XSLT XSL Transformations

Bibliography

[ACSV04] A. AuYoung, B. N. Chun, A. C. Snoeren, and A. Vahdat, Resource Allocation inFederated Distributed Computing Infrastructures, Proc. of the First Workshop onOperating System and Architectural Support (OASIS’04), October 2004.

[AHS+06] D. S. Anderson, M. Hibler, L. Stoller, T. Stack, and J. Lepreau, Automatic OnlineValidation of Network Configuration in the Emulab Network Testbed, Proc. of theThird Int’l Conf. on Autonomic Computing (ICAC’06), IEEE, June 2006, pp. 134–142.

[AK03] C. Atkinson and T. Kuhne, Model-Driven Development: A Metamodeling Foun-dation, IEEE Software Magazine 20 (2003), no. 5, 36–41.

[Anu10] Greg Anuzelli, Dynagen: The network configuration generator for Dynamips, Jan-uary 2010, [Online, checked on January 2010] http://dynagen.org.

[ASN02] Information technology – Abstract Syntax Notation One (ASN.1): Specificationof basic notation, Recommendation X.680, ITU-T, July 2002.

[ATL06] ATL User Manual, Manual v0.7, ATLAS, February 2006.

[ATSV06] J. Albrecht, C. Tuttle, A. C. Snoeren, and A. Vahdat, PlanetLab ApplicationManagement Using Plush, ACM SIGOPS Operating Systems Review 40 (2006),no. 1, 33–40.

[BBC+04] A. Bavier, M. Bowman, B. Chun, D. Culler, S. Karlin, S. Muir, L. Peter-son, T. Roscoe, T. Spalink, and M. Wawrzoniak, Operating System Support forPlanetary-Scale Network Services, Proc. of the First Symposium on NetworkedSystems Design and Implementation (NSDI’04), USENIX Association, March2004.

[BBC+07] A. Berglund, S. Boag, D. Chamberlin, M. Fernandez, M. Kay, J. Robie, andJ. Simeon, XML Path Language (XPath) 2.0, W3C Recommendation, W3C, Jan-uary 2007.

[BBG+60] J. W. Backus, F. L. Bauer, J. Green, C. Katz, J. McCarthy, P. Naur A. J. Perlis,H. Rutishauser, K. Samelson, B. Vauquois, J. H. Wegstein, A. van WijnGaar-den, and M. Woodger, Revised report on the algorithmic language Algol 60, ACMCommunications 3 (1960), 299–314.

[BBJ+06] T. Benzel, R. Braden, A. Joseph, D. Kim, C. Neuman, and K. Sklower, Experiencewith DETER: A Testbed for Security Research, Proc. of the Second Int’l Conf

203

204 BIBLIOGRAPHY

on Testbeds and Research Infrastructures for the Development of Networks andCommunities (TridentCom’06), IEEE, March 2006.

[BCF+07] S. Boag, D. Chamberlin, M. Fernandez, D. Florescu, J. Robie, and J. Simeon,XQuery 1.0: An XML Query Language, W3C Recommendation version 1.0, W3C,January 2007.

[BDF+03] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer,I. Pratt, and A. Warfield, Xen and the art of virtualization, Proc. of the 19th

ACM Symposium on Operating Systems Principles (SOSP’03), ACM, October2003, pp. 164–177.

[Bec04] D. Beckett, RDF/XML Syntax Specification (Revised), W3C Recommendation,W3C, February 2004.

[Beg06] Kyrre M Begnum, Managing Large Networks of Virtual Machines, Tech. report,December 2006.

[Bel05] F. Bellard, QEMU, a Fast and Portable Dynamic Translator, Proc. of the 2005USENIX Annual Technical Conference, USENIX Association, April 2005, pp. 41–46.

[Ber03] L. Berger, Generalized Muti-Protocol Label Switching (GMPLS) Signalling Func-tional Description, RFC 3471, IETF, January 2003.

[Ber06] A. Berglund, Extensible Stylesheet Language (XSL) Version 1.1, W3C Recom-mendation, W3C, December 2006.

[BFH+06] A. Bavier, N. Feamster, M. Huang, L. Peterson, and J. Rexford, In VINI Veritas:Realistic and Controlled Network Experimentation, Proc. of the 2006 SIGCOMMworkshop on Internet Network Management (SIGCOMM’06), ACM, September2006, pp. 3–14.

[BG04] D. Brickley and R. V. Guha, RDF Vocabulary Description Language 1.0: RDFSchema, W3C Recommendation, W3C, February 2004.

[BHLT06] T. Bray, D. Hollander, A. Layman, and R. Tobin, Namespaces in XML 1.0 (SecondEdition)), W3C Recommendation, W3C, August 2006.

[BKB+04] P. Brett, R. Knauerhase, M. Bowman, R. Adams, A. Nataraj, J. Sedayao, andM. Spindel, A Shared Global Event Propagation System to Enable Next GenerationDistributed Services, Proc. of First Workshop on Real Large Distributed Systems(WORLDS’04), USENIX Association, December 2004.

[BM04] P. Biron and A. Malhotra, XML Schema Part 2: Datatypes Second Edition, W3CRecommendation, W3C, October 2004.

[BMM+08] Sapan Bhatia, Murtaza Motiwala, Wolfgang Muhlbauer, Yogesh Mundada, Vy-tautas Valancius, Andy Bavier, Nick Feamster, Larry Peterson, and Jennifer Rex-ford, Trellis: A Platform for Building Flexible, Fast Virtual Networks on Com-modity Hardware, Proc. of the Int’l Conf. On Emerging Networking ExperimentsAnd Technologies (CoNEXT 2008), ACM, December 2008.

BIBLIOGRAPHY 205

[BPSM+08] T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, and F. Yergeau, Extensi-ble Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, W3C,November 2008.

[CdlHCC06] S. Carot, P. de las Heras, E. Castro, and J. Centeno, Early Experiences withNetGUI Laboratories, Proc. of the 8th Int’l Symposium on Educational ComputerScience (SIIE’06), October 2006.

[CFF+98] V. Chaudhri, A. Farquhar, R. Fikes, P. D. Karp, and J. P. Rice, OKBC: Aprogrammatic foundation for knowledge base interoperability, Proc. of the 15th

National Conference on Artificial Intelligence (AAAI-98), July 1998.

[CGI+07] Jeff Chase, Laura Grit, David Irwin, Varun Marupadi, Piyush Shivam, and AydanYumerefendi, Beyond Virtual Data Centers: Toward an Open Resource ControlArchitecture, Proc. of Int’l Conf. on the Virtual Computing Initiative, ACM, May2007.

[CGM06] Gonzalo Camarillo and Miguel-Angel Garcıa-Martın, The 3G IP Multimedia Sub-system (IMS): Merging the Internet and the Cellular Worlds, John Wiley & Sons,2006.

[CH05] J. Cappos and J. Hartman, Why it is hard to build a long-running serviceon PlanetLab, Proc. of Second Workshop on Real Large Distributed Systems(WORLDS’05), USENIX Association, December 2005.

[Cha99] Xinjie Chang, Network Simulations with OPNET, Proc. of the 31st Winter Sim-ulation Conference (WSC’99), July 1999, pp. 307–314.

[Che76] Peter Chen, The Entity-Relationship Model - Toward a Unified View of Data,ACM Transactions on Database Systems 1 (1976), no. 1, 9–36.

[Cla97] James Clark, Comparison of SGML and XML, W3C Note, W3C, De-cember 1997, [Online, checked on January 2010] http://www.w3.org/TR/

NOTE-sgml-xml-971215.

[CM01] James Clark and Murata Makoto, RELAX NG Specification, Committee Spec-ification, OASIS, December 2001, [Online, checked on January 2010] http:

//www.oasis-open.org/committees/relax-ng/spec-20011203.html.

[CMP06] Systems Management: Common Manageability Programming Interface (CMPI)Issue 2.0, Technical Standard C061, The Open Group, December 2006, [Online,checked on January 2010] http://www.opengroup.org/bookstore/catalog/

c061.htm.

[CMRW] R. Chinnici, J. Moreau, A. Ryman, and S. Weerawarana, Web Services Descrip-tion Language (WSDL) Version 2.0 Part 1: Core Language), Tech. report.

[CO05] D. Crocker and P. Overell, Augmented BNF for Syntax Specifications: ABNF,RFC RFC2234, IETF, October 2005, [Online, checked on January 2010] http://www.faqs.org/rfcs/rfc4234.html.

206 BIBLIOGRAPHY

[CS03] M. Carson and D. Santay, NIST Net: a Linux-based network emulation tool, ACMSIGCOMM Computer Communication Review 33 (2003), no. 3, 111–126.

[CvHH+01] D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein, DAML+OIL Reference Description, W3C Recom-mendation, W3C, March 2001.

[Dav99] Dave Winer, XML-RPC Specification, UserLand Software, Inc., June 1999.

[Dic10a] Merriam-Webster Dictionary, Networking, [Online, checked on January 2010]http://m-w.com/dictionary/networking, January 2010.

[Dic10b] Merriam-Webster Dictionary, Testbed, [Online, checked on January 2010] http://m-w.com/dictionary/testbed, January 2010.

[Dic10c] WordNet Dictionary, Testbed, [Online, checked on January 2010] http://

wordnetweb.princeton.edu/perl/webwn?s=test\%20bed, January 2010.

[Dik06] J. Dike, User Mode Linux (UML), Prentice Hall, 2006.

[DMT00] DMTF, CIM Core Model White Paper, DMTF Document DSP0111, v.2.4, August2000.

[DMT03a] DMTF, CIM Network Model Whitepaper, DMTF Document DSP0152, v. 1.1,2003.

[DMT03b] DMTF, CIM User and Security Model White Paper, DMTF Document DSP0139,v2.7, June 2003.

[DMT03c] DMTF, Desktop Management Interface Specification, DMTF Document DSP0005v2.0.1s, January 2003.

[DMT06] DMTF, Management Profile Specification Usage Guide, DMTF DocumentDSP1001 v1.0.0, June 2006.

[DMT07a] DMTF, IP Interface Profile, DMTF Document DSP1036 v1.0.0a, July 2007.

[DMT07b] DMTF, Profile Registration, DMTF Document DSP1033, v1.0.0, July 2007.

[DMT07c] DMTF, Server Management Command Line Protocol (SM CLP) Specification,DMTF Document DSP0214 v1.0.2, March 2007.

[DMT07d] DMTF, System Virtualization Profile, DMTF Document DSP1042, v1.0.0a, Au-gust 2007.

[DMT07e] DMTF, UML profile for CIM, DMTF Document DSP0219 v1.0, June 2007.

[DMT08a] DMTF, CIM Infrastructure Specification, DMTF Document DSP0004 v2.5.0a,May 2008.

[DMT08b] DMTF, Generic Operations, DMTF Document DSP0223 v1.0.0c, 2008.

[DMT08c] DMTF, Web Services for Management (WS-Management) Specification, DMTFDocument DSP0226 v1.0.0, February 2008.

BIBLIOGRAPHY 207

[DMT09a] DMTF, CIM Schema, November 2009, [Online, checked on January 2010] http://www.dmtf.org/standards/cim/cim_schema_v2230.

[DMT09b] DMTF, Open Virtualization Format Specification, DMTF Document DSP0243v1.0.0, February 2009.

[DMT09c] DMTF, Representation of CIM in XML, DMTF Document DSP0201 v2.3.1, July2009.

[DMT09d] DMTF, SM CLP-to-CIM Common Mapping Specification, DMTF DocumentDSP0216 v1.0.0, April 2009.

[DMT09e] DMTF, Specification for CIM Operations over HTTP, DMTF Document DSP0200v1.3.1, July 2009.

[DMT09f] DMTF, WS-CIM Mapping Specification, DMTF Document DSP0230 v1.0.0, April2009.

[DMT09g] DMTF, WS-Management CIM Binding Specification, DMTF Document DSP0227v1.0.0, June 2009.

[DRBL06] J. Duerig, R. Ricci, J. Byers, and J. Lepreau, Automatic {IP} Address Assign-ment on Network Topologies, Technical Note FTN200602, University of Utah FluxGroup, February 2006.

[DSB+04] M. Dean, G. Schreiber, S. Bechhofer, Frank van Harmelen, J. Hendler, I. Hor-rocks, D. L. McGuinness, P. F. Patel-Schneider, and L. Andrea Stein, OWL WebOntology Language Reference, W3C Recommendation, W3C, February 2004.

[Dyn10] Dynamips CISCO 7200 Simulator, January 2010, [Online, checked on January2010] http://www.ipflow.utc.fr/blog.

[ECI01] ECIMF, E-Commerce Integration Meta-Framework - General Methodology (EC-IMFGM), CEN/ISSS/WS-EC/ECIMF Draft Version 0.3, November 2001, [On-line, checked on January 2010] http://www.getopt.org/ecimf/doc/CWA/GM/

ECIMF-GM-03.pdf.

[Ecl10] Eclipse M2M ATL Project, January 2010, [Online, checked on January 2010]http://www.eclipse.org/m2m/atl/.

[ECo10] ECore Documentation, January 2010, [Online, checked on January 2010]http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/

eclipse/emf/ecore/package-summary.html.

[ECU10] SBLIM ECUTE, January 2010, [Online, checked on January 2010] http://sblim.wiki.sourceforge.net/Ecute.

[EF09] Chip Elliott and Aaron Falk, An Update on the GENI Project, ACM SIGCOMMComputer Communication Review 39 (2009), no. 3, 28–34.

[Eno10] Enomalism, [Online, checked on January 2010] http://www.enomalism.com, Jan-uary 2010.

208 BIBLIOGRAPHY

[ESL07] E. Eide, L. Stoller, and J. Lepreau, An Experimentation Workbench for ReplayableNetworking Research, Proc. of the 4th Symposium on Networked Systems Designand Implementation (NSDI’07), USENIX Association, April 2007, pp. 215–228.

[ESX10] VMware ESX and ESXi hypervisors, January 2010, [Online, checked on January2010] http://www.vmware.com/products/esx/.

[Fal99] K. Fall, Network Emulation in the Vint/NS Simulator, Proc. of the 4th IEEESymposium on Computers and Communications (ISCC’99), IEEE, July 1999,pp. 244–251.

[Fal07] A. Falk, GENI System Requirements Document (SRD), GENI Design DocumentGDD-07-46, GENI, April 2007.

[FCC+03] Y. Fu, J. Chase, B. Chun, S. Schwab, and A. Vahdat, SHARP: An Architecture forSecure Resource Peering, ACM SIGOPS Operating Systems Review 37 (2003),no. 5, 133–148.

[FED08] Evaluation of current network control and management planes for multi-domainnetwork infrastructure, Deliverable DJRA1.1 v1.7, Federica Project, 2008.

[FED09] FEDERICA Infrastructure, Deliverable DSA1.1 v7.0, Federica Project, February2009.

[FED10] Federated E-infrastructure Dedicated to European Researchers Innovating in Com-puting network Architectures, [Online, checked on January 2010]. http://www.fp7-federica.eu/, January 2010.

[FFAY99] O. Festor, P. Festor, L. Andrey, and N. Ben Youssef, Integration of WBEM-basedManagement Agents in the OSI Framework, Proc. of the 6th IFIP/IEEE Int’lSymposium on Integrated Network Management (IM’99), IEEE, May 1999.

[FvHH+01] D. Fensel, F. van Harmelen, I. Horrocks, D. L. McGuinness, and P. F. Patel-Schneider, OIL: an Ontology Infrastructure for the Semantic Web, IEEE Intelli-gent Systems 16 (2001), 38–45.

[GLFM09] Fermın Galan, Jorge E. Lopez de Vergara, David Fernandez, and Raul Munoz,Scenario-based Configuration Management for Flexible Experimentation Infra-structures, Proc. of the 5th Int’l Conf on Testbeds and Research Infrastructuresfor the Development of Networks and Communities (TridentCom’09), April 2009.

[GEA10] GEANT2, [Online, checked on January 2010]. http://www.geant2.net/, January2010.

[GEN08a] GENI Control Framework Architecture, Document GENI-ARCH-CP-01.4, GENIProject Office, October 2008.

[GEN08b] GENI Spiral 1 Overview, Document GENI-FAC-PRO-S1-OV-1.12, GENI ProjectOffice, September 2008.

[GEN08c] GENI System Overview, Document GENI-SE-SY-SO-02.0, GENI Project Office,September 2008.

BIBLIOGRAPHY 209

[GFLM09] Fermın Galan, David Fernandez, Jorge E. Lopez de Vergara, and Francisco Mon-serrat, Demo of EDIV: Building and managing distributed virtualization scenariosin federated testbed infrastructures, Proc. of the 5th Int’l Conf on Testbeds andResearch Infrastructures for the Development of Networks and Communities (Tri-dentCom’09), April 2009.

[GFF+09] F. Galan, D. Fernandez, W. Fuertes, M. Gomez, and J. E. Lopez de Vergara,Scenario-based Virtual Network Infrastructure Management in Research and Edu-cational Testbeds with VNUML: Application Cases and Current Challenges, An-nals of telecommunications 64 (2009), no. 5, 305–323.

[GFFM08] Fermın Galan, David Fernandez, Miguel Ferrer, and Fransico J. Martın, Scenario-based Distributed Virtualization Management Architecture for Multi-host Envi-ronments, Proc. of the 2nd System and Virtualization Management Workshop(SVM’08), DMTF, October 2008, pp. 49–60.

[GFLC04] A. Gomez, M. Fernandez-Lopez, and O. Corcho, Ongological Engineering,Springer, 2004.

[GGLM03] P. Goldsack, J. Guijarro, A. Lain, and G. Mecheneau, SmartFrog: Configurationand Automatic Ignition of Distributed Applications, Proc. of the 10th HP Open-View University Association Workshop (HP-OVUA’03), HP-OVUA, July 2003.

[GHF+08] Eduard Grasa, Xavier Hesselbach, Sergi Figuerola, Victor Reijs, Dave Wilson,Jean-Marc Uze, Lars Fischer, and Tomas de Miguel, The MANTICORE project:Providing users with a Logical IP Network Service, TERENA Networking Confer-ence (TNC2008), TERENA, May 2008.

[GHM+07] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, H. Frystyk, A. Karmarkar, andY. Lafon, SOAP Messaging Framework (Second Edition), W3C Recommendationversion 1.2, W3C, April 2007.

[GLI10] Global Lambda Integrated Facility, [Online, checked on January 2010]. http://www.glif.is, January 2010.

[GM07] F. Galan and R. Munoz, An Automatic Model-based reconfiguration and moni-toring mechanism for flexible GMPLS-based optical networking testbeds, LectureNotes in Computer Science (LNCS) 4534 (2007), 239–248.

[GMM06] F. Galan, R. Munoz, and R. Martınez, Demo of ADNETCONF: ADRENALINE’stool for dynamic configuration of GMPLS-based all-optical transport networks,Proc. of the Second Int’l Conf on Testbeds and Research Infrastructures for theDevelopment of Networks and Communities (TridentCom’06), IEEE, March 2006.

[GR03] A. Gerber and K. Raymond, MOF to EMF: There and Back Again, Proc. ofOOPSL Workshop on Eclipse Technology eXchange, 2003, pp. 60–64.

[Gre07] X. Grehant, SmartDomains deploys Xen VMs, CERN Computer Newsletter(2007), 10–11.

210 BIBLIOGRAPHY

[GRL05] S. Guruprasad, R. Ricci, and J. Lepreau, Integrated Network Experimentationusing Simulation and Emulation, Proc. of the First Int’l Conf on Testbeds andResearch Infrastructures for the Development of Networks and Communities (Tri-dentCom’05), IEEE, February 2005, pp. 204–212.

[Gru93] T. R. Gruber, A Translation Approach to Portable Ontology Specification, Knowl-edge Acquisition 5 (1993), no. 3, 199–220.

[GSRM+09] Fermın Galan, Americo Sampaio, Luis Rodero-Merino, Irit Loy, Victor Gil,Luis M. Vaquero, and Mark Wusthoff, Service Specification in Cloud Environ-ments Based on Extensions to Open Standards, Proc. of the Fourth Interna-tional Conference on COMmunication System softWAre and middlewaRE (COM-SWARE 2009), ACM, June 2009.

[GVL+06] A. Guerrero, V. A. Villagra, J. E. Lopez de Vergara, A. Sanchez-Macian, andJ. Berrocal, Ontology-based policy refinement using SWRL rules for manage-ment information definitions in OWL, Lecture Notes in Computer Science) 4269(2006), 227–232.

[HBB+04] R. Hulsermann, S. Bodamer, M. Barry, A. Betker, C. Gauger, M. Jager, M. Kohn,and J. Spath, A Set of Typical Transport Network Scenarios for Network Mod-elling, Proc. of the 5th ITG-Workshop on Photonic Networks, USENIX Associa-tion, April 2004.

[HBP06] M. Huang, A. Bavier, and L. Peterson, PlanetFlow: Maintaining Accountabilityor Network Services, ACM SIGOPS Operating Systems Review 40 (2006), no. 1,89–94.

[Hem05] S. Hemminger, Network Emulation with NetEm, Proc. of the Linux ConferenceAU, April 2005.

[HHL99] J. Heflin, J. Hendler, and S. Luke, S. SHOE: A Knowledge Representation Lan-guage for Internet Applications, Technical Report CS-TR-4078 (UMIACS TR-99-71), Dept. of Computer Science, University of Maryland at College Park, 1999.

[HHW+00] A. Le Hors, P. Le Hegaret, L. Wood, G. Nicol, J. Robie, M. Champion, andS. Byrne, Document Object Model (DOM) Level 2 Core Specification, W3C Rec-ommendation, W3C, November 2000.

[HHW+04] A. Le Hors, P. Le Hegaret, L. Wood, G. Nicol, J. Robie, M. Champion, andS. Byrne, Document Object Model (DOM) Level 3 Core Specification, W3C Rec-ommendation, W3C, April 2004.

[HLFT94] S. Hanks, T. Li, D. Farinacci, and P. Traina, Generic Routing Encapsulation overIPv4 networks, RFC 1702, IETF, October 1994.

[HPSB+04] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean,SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3CMember Submission, W3C, May 2004.

BIBLIOGRAPHY 211

[HPW02] D. Harrington, R. Presuhn, and B. Wijnen, An Architecture for Describing SimpleNetwork Management Protocol (SNMP) Management Frameworks, RFC 3411,IETF, December 2002.

[HRS+04] M. Hibler, R. Ricci, L. Stoller, J. Duerig, S. Guruprasad, T. Stack, K. Webb,and J. Lepreau, Feedback-directed Virtualization Techniques for Scalable NetworkExperimentation, no. FTN200402, May 2004.

[Hue10] R. Huebsch, PlanetLab Application Manager, [Online, checked on January 2010].http://appmanager.berkeley.intel-research.net, January 2010.

[IEE01] Virtual LANs, Standard 802.1q, IEEE, 2001.

[Int10] Internet2, [Online, checked on January 2010]. http://www.internet2.edu/, Jan-uary 2010.

[ISO86] Standard Generalized Markup Language (SGML), ISO/IEC standard ISO8879:1986, ISO, 1986.

[ISO96] Extended BNF, ISO/IEC standard ISO/IEC 14997:1996(E), ISO, December 1996.

[ISO06] Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation- Schematron, ISO/IEC standard ISO/IEC 19757-3:2006, ISO, May 2006.

[ISO08] Standard Query Language (SQL), ISO/IEC standard ISO 9075:2008, ISO, 2008.

[ITU92] Information technology - Open Systems Interconnection - Structure of manage-ment information: Guidelines for the definition of managed objects, Recommen-dation X.722, ITU-T, January 1992.

[ITU00a] Generic Functional Architecture of Transport Networks, Recommendation G.805,ITU-T, March 2000.

[ITU00b] TMN management functions, Recommendation M.3400, ITU-T, February 2000.

[ITU01] CORBA generic network and network element level information model, Recom-mendation M.3120, ITU-T, October 2001.

[ITU05] Generic network information model, Recommendation M.3100, ITU-T, April2005.

[J2E10] J2EE Platform, [Online, checked on January 2010]. http://java.sun.com/

javaee/, January 2010.

[JAB+06] F. Jouault, F. Allilaire, Jean. Bezivin, I. Kurtev, and P. Valduriez, ATL: aQVT-like transformation language, Proc. of the 21st ACM SIGPLAN symposiumon Object-oriented programming systems, languages, and applications (OOP-SLA’06), ACM Association, October 2006, pp. 719–720.

[JBK07] E. Jaffe, D. Bickson, and S. Kirkpatrick, Everlab - A Production Platform forResearch in Network Experimentation and Computation, Proc. of the 21st LargeInstallation System Administration Conference (LISA’07), USENIX Association,November 2007, pp. 203–213.

212 BIBLIOGRAPHY

[Jia04] VIOLIN: Virtual Internetworking on Overlay Infrastructure, Lecture Notes inComputer Science (LNCS) 3358 (2004), 937–946.

[JK06] F. Jouault and I. Kurtev, On the architectural alignment of ATL and QVT, Proc.of the 21st ACM symposium on Applied computing (SAC’06), ACM Association,April 2006, pp. 1188–1195.

[JX03] X. Jiang and D. Xu, vBET: a VM-based emulation testbed, Proc. of the ACMWorkshop on Models, Methods and Tools for Reproducible Network Research(MoMeTools’03), ACM Association, August 2003.

[Kay07] M. Kay, XSL Transformations (XSLT) Version 2.0, W3C Recommendation,W3C, January 2007.

[KC04] G. Klyne and J. J. Carroll, Resource Description Framework (RDF): Conceptsand Abstract Syntax, W3C Recommendation, W3C, February 2004.

[KCH+] P. Kogut, S. Cranefield, L. Hart, M. Dutra, K. Baclawski, M. Kokar, and J. Smith,UML for ontology development.

[KKL+07] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, kvm: the Linux VirtualMachine Monitor, Proc. of the 2007 Linux Symposium, June 2007, pp. 225–230.

[KR05] K. Kompella and Y. Rekhter, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPL), RFC 4203, IETF, October 2005.

[Kur08] I. Kurtev, State of the Art of QVT: A Model Transformation Language Standard, Lecture Notes in Computer Science (LNCS) 5088 (2008), 377–393.

[KW01] P. Kamp and R. Watson, Jails: Confining the Omnipotent Root, Proc. of theSecond System Administration and Network Engineering Conference (SANE’01),ACM Association, May 2001.

[KWB03] Anneke Kleppe, Jos Warmer, and Wim Bast, The Model Driven Architecture:Practise and Promise, Addison-Wesley, 2003.

[Lar05] H. Larsen, PSAD: PlanetLab Slice Anomaly Detection, Internal note, PrincentonUniversity, January 2005.

[LDR03] E. Lavinal, T. Desprats, and Y. Raynaud, A conceptual framework for buildingCIM-based ontologies, Proc. of the 8th IFIP/IEEE Symposium on Integrated Net-work Management (IM’03), GUUG, March 2003, pp. 135–138.

[LHF04] K. Lai, B. A. Huberman, and L. Fine, Tycoon: a Distributed Market-based Re-source allocation system, Tech Report arXiv:cs.DC/0412038, HP Labs Palo AltoUSA, December 2004.

[lib10a] libvirt, January 2010, [Online, checked on January 2010] http://libvirt.org/.

[lib10b] TCPDUMP Public Repository, [Online, checked on January 2010]. http://www.tcpdump.org, January 2010.

BIBLIOGRAPHY 213

[LKGN05] J. Liang, S. Ko, I. Gupta, and K. Nahrstedt, MON: On-demand Overlays forDistributed System Management, Proc. of Second Workshop on Real Large Dis-tributed Systems (WORLDS’05), USENIX Association, December 2005.

[LMVH07] J. Liu, S. Man, N. Van Vorst, and K. Hellman, An Open and Scalable EmulationInfrastructure for Large-Scale Real-Time Network Simulations, Proc. of the 26ndAnnual Joint Conference of the IEEE Computer and Communications Societies(INFOCOM’07), IEEE, May 2007, pp. 2476–2480.

[Lop03] J. E. Lopez de Vergara, Especificacion de Modelos de Informacion de Gestion deRed Integrada Mediante el Uso de Ontologıas y Tecnicas de Representacion delConocimiento (Integrated Network Management Information Model Specificationby Means of the Use of Ontologies and Knowledge Representation Techniques),Ph.D Thesis, June 2003.

[LS08] Jean-Vincent Loddo and Luca Saiu, Marionnet: a virtual network laboratory andsimulation tool, Proc. of the First Int’l Conf. on Simulation Tools and Techniquesfor Communications, Networks and Systems (SIMUTools 2008), March 2008.

[LSJ06] Thomas Lehman, Jerry Sobieski, and Bijan Jabbari, DRAGON: a Frameworkfor Service Provisioning in Heterogeneous Grid Networks, IEEE CommunicationsMagazine 44 (2006), no. 3, 84–90.

[LTM92] John R. Levine and Doug Brown Tony Mason, Lex & Yacc, O’Reilly, 1992.

[LVAB03] J. E. Lopez de Vergara, V. A. Villagra, J. I. Asensio, and J. Berrocal, Ontologies:giving semantics to network management models, IEEE Network 17 (2003), no. 3,15–21.

[LVB04] J. Lopez de Vergara, V. Villagra, and J. Berrocal, Applying the web ontology lan-guage to management information definitions, IEEE Communications Magazine42 (2004), no. 7, 68–74.

[Mac91] R. M. MacGregor, Inside the LOOM Description Classifier, ACM SIGART Bul-letin 2 (1991), no. 3, 99–92.

[Mai04] E. Maine, Generalized Multi-Protocol Label Switching (GMPLS) Architecture,RFC 3945, IETF, October 2004.

[Mal98] G. Malkin, RIP Version 2, RFC 2453, IETF, November 1998.

[MDA03] MDA guide, OMG Document omg/03-06-01 v1.0.1, Object Management Group,June 2003.

[med10] medini QVT, January 2010, [Online, checked on January 2010] http://projects.ikv.de/qvt.

[Min07] B. Minh, Real-Time Object Uniform Design Methodology with UML, Springer,2007.

214 BIBLIOGRAPHY

[MMN+09] Muthucumaru Maheswaran, Alexis Malozemoff, Daniel Ng, Sheng Liao, Song Gu,Balasubramaniyam Maniymaran, Julie Raymond, Reehan Shaikh, and YuanyuanGao, GINI: A User-Level Toolkit for Creating Micro Internets for Teaching andLearning Computer Networking, Proc. of the 40th ACM technical symposium onComputer science education (SIGCSE’09), ACM, March 2009, pp. 39–43.

[MMSV02] A. Maedche, B. Motik, N. Silva, and R. Volz, MAFRA - A MApping FRAme-work for Distributed Ontologies, Lecture Notes in Computer Science (LNCS) 2473(2002), 69–75.

[MMW07] A. Malhotra, J. Melton, and N. Walsh, XQuery 1.0 and XPath 2.0 Functions andOperators), W3C Recommendation version 1.0, W3C, January 2007.

[Mod10a] Model Wizard, January 2010, [Online, checked on January 2010] http://

modelwizard.sourceforge.net/.

[Mod10b] ModelMorf: A model transformer, January 2010, [Online, checked on January2010] http://www.tcs-trddc.com/ModelMorf/ModelMorf.htm.

[Mot98] E. Motta, An Overview of the OCML Modelling Language, Proc. of the 8th Work-shop on Knowledge Engeneering Methods and Languages (KEML’98), 1998.

[Moy98] J. Moy, OSPF Version 2, RFC RFC2328, IETF, April 1998, [Online, checked onJanuary 2010] http://www.ietf.org/rfc/rfc2328.txt.

[MPF+06] S. Muir, L. Peterson, M. Fiuczynski, J. Cappos, and J. Hartman, Privileged Opera-tions in the PlanetLab Virtualised Enviroment, ACM SIGOPS Operating SystemsReview 40 (2006), no. 1, 75–88.

[MPS99] K. McCloghrie, D. Perkins, and J. Schoenwaelder, Structure of Management In-formation Version 2 (SMIv2), RFC RFC2578, IETF, April 1999, [Online, checkedon January 2010] http://www.ietf.org/rfc/rfc2578.txt.

[MRBV95] P. Mahadevan, A. Rodrıguez, D. Becker, and A. Vahdat, Logical Foundationsof Object-Oriented and Frame-Based Languages, Journal of the ACM 42 (1995),no. 4, 741–843.

[NET10a] Microsoft .NET Framework, [Online, checked on January 2010]. http://www.

microsoft.com/NET/, January 2010.

[Net10b] NetML, [Online, checked on January 2010]. http://www.dia.uniroma3.it/

~compunet/netml/, January 2010.

[NLR10] National Lambda Rail, [Online, checked on January 2010]. http://www.nlr.net,January 2010.

[MPM+05] R. Munoz, C. Pinart, R. Martınez, J. Sorribes, G. Junyent, and A. Amrani, TheADRENALINE Testbed: Integrating GMPLS, XML, and SNMP in TransparentDWDM Networks, IEEE Communications Magazine 43 (2005), no. 8, s40–s48.

[ns10] The Network Simulator ns2, [Online, checked on January 2010]. http://www.

isi.edu/nsnam/ns, January 2010.

BIBLIOGRAPHY 215

[NSF02] Report of NSF Workshop on Network Research Testbeds, Tech. report, NSF,November 2002.

[NSF10] National Science Foundation, [Online, checked on January 2010]. http://www.nsf.gov, January 2010.

[OAPV04] D. Oppenheimer, J. Albrecht, D. Patterson, and A. Vahdat, Distributed ResourceDiscovery on PlanetLab with Sword, Proc. of First Workshop on Real Large Dis-tributed Systems (WORLDS’04), USENIX Association, December 2004.

[OAS08] OASIS, Solution Deployment Descriptor, OASIS Standard SDD v1.0, OASIS,September 2008.

[OGF10] Network Mark-up Language Working Group (NML-WG), [Online, checked onJanuary 2010] https://forge.gridforum.org/sf/projects/nml-wg, January2010.

[OMG02] OMG, CORBA 3.0 - OMG IDL Syntax and Semantics chapter, OMG Documentformal/02-06-39, June 2002, [Online, checked on January 2010] http://www.omg.org/docs/formal/02-06-39.pdf.

[OMG06a] OMG, Meta Object Facility (MOF) Core Specification v2.0, OMG Documentformal/06-01-01, January 2006, [Online, checked on January 2010] http://www.omg.org/docs/formal/06-01-01.pdf.

[OMG06b] OMG, Object Constraint Language v2.0, Specification formal/06-05-01, May2006, [Online, checked on January 2010] http://www.omg.org/docs/formal/

06-05-01.pdf.

[OMG07] OMG, MOF 2.0/XMI Mapping v2.1.1, Specification formal/2007-12-01, Decem-ber 2007, [Online, checked on January 2010] http://www.omg.org/docs/formal/07-12-01.pdf.

[OMG08a] OMG, Meta Object Facility (MOF) 2.0 Query/View/Transformation Specificationv1.0, Specification formal/2008-04-03, April 2008, [Online, checked on January2010] http://www.omg.org/docs/formal/08-04-03.pdf.

[OMG08b] OMG, MOF Model to Text Transformation Language, v1.0, OMG Documentformal/08-01-06, January 2008, [Online, checked on January 2010] http://www.omg.org/docs/formal/08-01-16.pdf.

[OMG08c] OMG, OMG Systems Modeling Language (OMG SysML), OMG Documentformal/08-11-02, November 2008, [Online, checked on January 2010] http://www.omg.org/docs/formal/08-11-02.pdf.

[OMG09a] OMG, Unified Modeling Language Infrastructure v2.2, Specification formal/2009-02-04, February 2009, [Online, checked on January 2010] http://www.omg.org/docs/formal/09-02-04.pdf.

[OMG09b] OMG, Unified Modeling Language Superstructure v2.2, Specification formal/2009-02-02, February 2009, [Online, checked on January 2010] http://www.omg.org/docs/formal/09-02-02.pdf.

216 BIBLIOGRAPHY

[One10] OneLab/OneLab2, [Online, checked on January 2010]. http://www.onelab.eu/,January 2010.

[OSSS05] M. Ott, I. Seskar, R. Siraccusa, and M. Singh, ORBIT Testbed Software Ar-chitecture: Supporting Experiments as a Service, Proc. of the First Int’l Confon Testbeds and Research Infrastructures for the Development of Networks andCommunities (TridentCom’05), IEEE, February 2005, pp. 136–145.

[Ou98] Y. Ou, On Mapping Between UML and Entity-Relationship Model, The UnifiedModeling Language - Technical Aspects and Applications (1998), 45–57.

[PACR03] L. Peterson, T. Anderson, D. Culler, and T. Roscoe, A Blueprint for IntroducingDisruptive Technology into Internet, ACM SIGCOMM Computer CommunicationReview 33 (2003), no. 1, 59–64.

[PAS10] RedIRIS PASITO, [Online, checked on January 2010]. http://www.rediris.es/proyectos/pasito/, January 2010.

[PDKT00] V. K. Chaudhri P. D. Karp and J. Thomere, XOL: An XML-Based OntologyExchange Language, Technical Report, Artificial Intelligence Center SRI Interna-tional, February 2000.

[Pem02] S. Pemberton, XHTML 1.0 The Extensible HyperText Markup Language (SecondEdition), W3C Recommendation, W3C, 2002.

[PGM98] J. Y. Park, J. H. Gennari, and M. A. Musen, Mappings for Reuse in Knowledge-Based Systems, Proc. of the 11th Workshop on Knowledge Acquisition, Modelingand Management (KAW’98), 1998.

[PII10] Panlab: Pan European Laboratory Infrastructure Imlementation, [Online, checkedon January 2010]. http://www.panlab.net/, January 2010.

[Pla10] PlanetLab Japan, January 2010, [Online, checked on January 2010] http://www.planet-lab.jp/.

[PP06] K. S. Park and V. S. Pai, CoMon: A Mostly-Scalable Monitoring System forPlanetLab, ACM SIGOPS Operating Systems Review 40 (2006), no. 1, 65–74.

[PR08] M. Pizzonia and M. Rimondini, Netkit: easy emulatiton of complex networks oninexpensive hardware, Tech. report, March 2008.

[QAW+04] S. Quirolgico, P. Assis, A. Westerinen, M. Baskey, and E. Stokes, Toward a formalcommon information model ontology, Lecture Notes in Computer Science (LNCS)3307 (2004), 11–21.

[RAL03] R. Ricci, C. Alfeld, and J. Lepreau, A solver for the Network Testbed MappingProblem, ACM SIGCOMM Computer Communication Review 33 (2003), no. 2,65–81.

[Red10] RedIRIS: Network Infrastructure, [Online, checked on January 2010]. http://

www.rediris.es/red/index.en.html, January 2010.

BIBLIOGRAPHY 217

[RLH06] Y. Rekhter, T. Li, and S. Hares, A Border Gateway Protocol 4 (BGP-4), RFC4271, IETF, January 2006.

[Rob09] James Roberts, The clean-slate approach to future Internet desing: a survey ofresearch initiatives, Annals of telecommunications 64 (2009), no. 5, 271–276.

[RVC01] E. Rosen, A. Viswanathan, and R. Callon, Multiprotocol Label Switching Archi-tecture, RFC 3031, IETF, January 2001.

[SAX10] Simple API for XML (SAX), [Online, checked on January 2010]. http://www.saxproject.org/, January 2010.

[SBF98] R. Studer, R. Benjamins, and D. Fensel, Knowledge engineering: principles andmethods, IEEE Transactions on Data and Knoledge Engineering 25 (1998), no. 1–2, 161–197.

[Sch07] Karl Schopmeyer, State/Behavior and the CIM Model, Proc. of the First Systemand Virtualization Management Workshop (SVM’07), DMTF, October 2007.

[Sei03] Ed Seidewitz, What models mean, Software 20 (2003), no. 5, 26–32.

[Sei04] Rene Seindal, GNU M4 Manual, GNU Press, 2004.

[SGH+05] F. Stumpf, A. Gorlach, F. Homann, , and L. Bruckner, NoSE – building virtualhoneynets made easy, Proc. of the 12th Int’l Linux System Technology Conference(Linux-Kongress’05), GUUG, October 2005, pp. 1664–1669.

[SHK06] M. Suzuki, H. Hazeyama, and Y. Kadobayashi, Expediting experiments across test-beds with AnyBed: a testbed-independent topology configuration tool, Proc. of theSecond Int’l Conf on Testbeds and Research Infrastructures for the Developmentof Networks and Communities (TridentCom’06), IEEE, March 2006.

[Sir10] PlanetLab Sirius Scheduler, [Online, checked on January 2010]. https://

snowball.cs.uga.edu/~dkl/pslogin.php, January 2010.

[SMLPB08] A. Sanchez-Macian, J. E. Lopez de Vergara, E. Pastor, and L. Bellido, A systemfor monitoring, assessing and certifying quality of service in telematics services,Knowledge-based systems 21 (2008), no. 2.

[SS04a] F. Strauss and J. Schoenwaelder, SMIng - Next Generation Structure of Manage-ment Information, RFC 3780, IETF, May 2004.

[SS04b] F. Strauss and J. Schoenwaelder, SMIng Mappings to SNMP, RFC 3781, IETF,May 2004.

[SSC+08] John Strassner, Srini Samudrala, Greg Cox, Yan Liu, Michael Jiang, Jing Zhang,Sven van der Meer2, Mıcheal O Foghlu, and Willie Donnelly, The Design of aNew Context-Aware Policy Model for Autonomic Networking, Proc. of the 5th

Int’l Conf on Autonomic Computing (ICAC’08), June 2008, pp. 119–128.

[SUR10] SURFNet, [Online, checked on January 2010]. http://www.surfnet.nl/info/en,January 2010.

218 BIBLIOGRAPHY

[TBG+05] M. Takai, R. Bagrodia, M. Gerla, B. Daneshrad, M. Fitz, M. Srivastava,E. Belding-Royer, S. Krishnamurthy, M. Molle, P. Mohapatra, R. Rao, U. Mitra,C. Shen, and J. Evans, Scalable Testbed for Next-Generation Wireless NetworkingTechnologies, Proc. of the First Int’l Conf on Testbeds and Research Infrastructu-res for the Development of Networks and Communities (TridentCom’05), IEEE,February 2005, pp. 162–171.

[TBMM04] H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, XML Schema Part 1:Structures Second Edition, W3C Recommendation, W3C, October 2004.

[TMF05a] DMTF/TMF Model Alignment. Physical Sub-model, Tech. ReportDSP2004/GB932 v0.1.14, DMTF/TMF, June 2005.

[TMF05b] DMTF/TMF Model Alignment. SID Logical Resources and CIM Networks Sub-Models, Tech. Report DSP2009/GB933 v0.6, DMTF/TMF, November 2005.

[TMF08a] Business Process Framework, Tech. Report GB921 Release 8.0, TMF, November2008.

[TMF08b] Information Framework (SID) Solution Suite, Tech. Report GB922 Release 8.0,TMF, July 2008.

[TMF08c] NGOSS lifecycle and Methodology, Tech. Report GB927 Release 9.0, TMF, April2008.

[Tou01] J. Touch, Dynamic Internet Overlay Deployment and Management Using the X-Bone, Computer Networks 33 (2001), no. 2, 117–135.

[TWP+05] J. Touch, Y. Wang, V. Pingali, L. Eggert, R. Zhou, and G. Finn, A Global X-Bone for Network Experiments, Proc. of the First Int’l Conf on Testbeds andResearch Infrastructures for the Development of Networks and Communities (Tri-dentCom’05), IEEE, February 2005, pp. 194–203.

[vdHDG+08] Jeroen van der Ham, Freek Dijkstra, Paola Grosso, Ronald van der Pol, AndreeToonk, and Cees de Laat, A Distributed Topology Information System for Opti-cal Networks Based on the Semantic Web, Optical Switching and Networking 5(2008), no. 2–3, 85–93.

[vdHV04] J. van der Ham and G. Jan Verhoog, Virtual environments for networking exper-iments, Internal report, University of Amsterdam, July 2004.

[Vir10] VMware VirtualCenter, [Online, checked on January 2010] http://www.vmware.com/products/vi/vc, January 2010.

[VLA06] Virtual Lab Automation, Whitepaper, VMware, 2006.

[VNU10] VNUML Graphic User Interface, [Online, checked on January 2010] http://

pagesperso.erasme.org/michel/vnumlgui/, January 2010.

[vse10] Linux VServers Project, [Online, checked on January 2010]. http://

linux-vserver.org, January 2010.

BIBLIOGRAPHY 219

[VYW+02] A. Vahdat, K. Yocum, K. Walsh, P. Mahadevan, D. Kostic, J. Chase, andD. Becker, Scalability and Accuracy in a Large-Scale Network Emulator, Proc. ofthe 5th Symposium on Operating Systems Design and Implementation (OSDI’02),USENIX Association, December 2002.

[Wat08] J. Watson, VirtualBox: Bits and Bytes Masquerading as Machines, Linux Journal2008 (2008), no. 166.

[WHA+00] L. Wood, A. Le Hors, V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs,G. Nicol, J. Robie, R. Sutor, and C. Wilson, Document Object Model (DOM)Level 1 Specification (Second Edition), W3C Recommendation, W3C, September2000.

[Wik10a] CTTC Optical Networking Area - ADRENALINE testbed R©, [Online, checkedon January 2010]. http://wikiona.cttc.es/ona/index.php/ADRENALINE_

testbed%C2%AE, January 2010.

[Wik10b] Wikipedia, Formal grammar — Wikipedia, The Free Encyclopedia, [Online,checked on January 2010]. http://en.wikipedia.org/w/index.php?title=

Formal_grammar&oldid=299823799, January 2010.

[WLS+02] B. White, J. Lepreau, L. Stoller, R. Ricci, S. Guruprasad, M. Newbold, M. Hibler,C. Barb, and A. Joglekar, An Integrated Experimental Environment for DistributedSystems and Networks, Proc. of the 5th Symposium on Operating Systems Designand Implementation (OSDI’02), USENIX Association, December 2002, pp. 255–270.

[WMG+09] Sebastian Wahle, Thomas Magedanz, Anastasius Gavras, Halid Hrasnica, andSpyros Denazis, Technical Infrastructure for a Pan-European Federation of Test-beds, Proc. of the 5th Int’l Conf on Testbeds and Research Infrastructures for theDevelopment of Networks and Communities (TridentCom’09), April 2009.

[WRCW05] Yanyan Wang, Matthew J. Rutherford, Antonio Carzaniga, and Alexander L.Wolf, Automating Experimentation on Distributed Testbeds, Proc. of the 20th Int’lConf on Automated Software Engineering (ASE’05), November 2005, pp. 164–173.

[Xen10] XenServer, [Online, checked on January 2010] http://www.xensource.com/

products/xen_server, January 2010.

[YSB+06] P. Yalagandula, P. Sharma, S. Barnejee, S. Basu, and S. Lee, S3: A Scal-able Sensing Service for Monitoring Large Networked Systems, Proc. of the 2006SIGCOMM workshop on Internet Network Management (SIGCOMM’06), ACM,September 2006, pp. 71–76.

[YTF05] Y. E. Yang, J. Touch, and G. Finn, The X-Bone API, ISI Technical Report ISI-TR-2005-611, ISI, December 2005.

[ZZP+04] M. Zhang, C. Zhang, V. Pai, L. Peterson, and R. Wang, PlanetSeer: InternetPath Failure Monitoring and Characterization in Wide-Area Services, Proc. ofthe 6th Symposium on Operating Systems Design and Implementation (OSDI’04),USENIX Association, December 2004.

Index

.NET, 75

ABNF, 72, 84, 101abstract syntax, see syntaxADNETCONF, 37, 38, 103, 104, 125–128, 137,

139, 141, 142, 145, 147, 148, 164, 166,169, 171

ADNETCONF DTD, 125, 127, 137, 141,145, 147

ADNETCONF OSPF-TE DTD, 125, 128,137, 142

TSM, 126–128, 137, 138, 140, 142, 145, 147ADRENALINE, 21, 31, 33, 36–38, 56–58, 98,

99, 125–129, 139–141, 143, 145, 147,148, 164, 167, 169, 171

LRM, 37, 38management network, 127, 139OCC, 37, 38, 127, 139–141, 147, 148OLRM, 37, 38OSPF-TE, 37, 38, 128, 140, 141RSVP-TE, 37, 38SNMP, 37, 38

ADSL, 115algorithm

arbitraty selection, 48automatic allocation, 57CIM mapping, 81dynamic routing, 24, 29, 151greedy assignment, 39iterative, 55segmentation, 25, 154, 156simulated annealing, 36traffic engineering, 37transformation, 76, 78XML-based TSM, 101, 103, 105, 106, 132,

136, 137, 148, 164AM3, 143, 147Amazon EC2, 22AnyBed, 22, 53–55, 57, 58, 99, 171AS, 41

ASN.1, 90AST, 48, 57, 99ASTB, 48ASTDL, 48ATL, 65, 76, 79–80, 91, 101, 102, 104, 106, 109,

132, 135–137, 141–143, 145, 147, 149,173, 179–194

ATM, 55automatic allocation, 31, 57

bandwidth, 29, 33–37, 39, 44, 48, 55, 171BGP, 41, 86BNF, 72, 91, 101broadband tester, 37, 38

CIM, 25, 62, 81–91, 97–98, 101, 102, 110, 120,123, 136, 145, 157, 158, 164, 165, 172

CIMOM, 81, 82, 89, 106, 108, 123, 142,157–159

client, 81, 158, 159Common Model, 86–87, 97, 98, 111, 114,

116–123Core Model, 85–87, 98, 114, 117–120, 122Extension Model, 86–87, 98, 99, 175Infrastructure, 82–84, 87, 114instance, 102, 159Schema, 81, 82, 84–87, 89–91, 97–100, 102,

111–115, 117–119, 122, 123, 136, 143,145, 164, 165, 170, 175

State and Behaviour, 170CIM-XML, 81, 89, 123CIMOM, see CIMclean-slate, 49, 97, 98, 110, 113cloud computing, 22, 160, 161CLP, 81CMOF, see MOFCMPI, 82, 159concrete syntax, see syntaxcontent distribution network, 151control plane, 36, 37, 48, 56, 126, 127

220

INDEX 221

CTM, 171–172CTTC, 36, 125, 147

DAML, 71data-oriented XML, see XMLdatacenter, 161Debian, 147declarative language, 64, 77–79, 145delay, 29, 33–35, 37, 56, 113, 115, 127, 128, 140DENng, 52design tool, 95, 96, 171DETER, 51DMTF, 25, 39, 62, 66, 81, 82, 87–90, 97, 98,

101, 102, 110, 122, 123, 142, 159, 160,164, 165, 170, 175

profile, 39, 87–88, 99–100, 110, 111, 114,120, 123, 171

pseudo-profile, 99–100DOM, see XMLDRAGON, 43, 48, 57, 99DSP0219, 88, 89, 102, 143, 145DTD, see XMLDTMF

pseudo-profile, 110, 111, 114, 120, 123duplication probability, 116, 127, 140Dynagen, 33, 42, 56, 57, 99dynamic routing, 24, 29, 41, 46, 47, 56, 98, 104,

111, 113, 120, 128, 141, 151, 170dynamic semantic, see semanticDynamips, 40, 42, 57

EBNF, 70, 72, 77EC, 49EC2, see Amazon EC2Eclipse, 66, 80, 143, 145, 147ECore, 66, 79, 143, 145ECUTE, 89, 145EDIV, 52, 57, 58, 167EMF, 66, 70EMOF, see MOFEmulab, 21, 27, 29, 31, 33–36, 51, 56–58, 99,

170, 172emulation, 34ERD, 72, 91ERM, 72Essential OCL, see OCLEthernet, 33, 36, 38, 46, 51, 55, 56eTOM, 90

event sequence, 22, 29, 31, 35, 36, 40–42, 51,53–57, 73, 95, 170

experimentation infrastructure, 24, 26, 27, 40,52, 54, 56, 61, 100, 151, 153, 163, 166,169

flexible, 22, 23, 27, 93, 95, 159, 167experimentation scenario, 21–23, 29, 30, 37–39,

48, 53–55, 58, 61, 62, 66, 67, 89, 90, 94,97, 152, 153

deployment workflow, 109lifecycle, 27, 30, 31, 34, 35, 44, 46, 51, 57,

95, 109specification, 21–25, 30–32, 34–36, 42, 48,

51, 54–56, 58, 93, 94, 101–103, 152,156, 157, 163–165

explicit allocation, 31, 32, 57

federated testbed, see networking testbedFEDERICA, 24, 43, 49, 51, 57, 58, 169filesystem, 41, 42, 126, 132, 134FIND, 49FIRE, 49flexible experimentation infrastructure, see ex-

perimentation infrastructureflexible networking testbed, see networking test-

bedFLOWR, 73formal grammar, 61FP7, 49FreeBSD, 34

jails, 34FTP, 55Future Internet, 21, 24–26, 43, 46, 49–53, 58,

93, 97, 98, 110, 113, 151, 153–157, 160,163, 164, 169

GEANT2, 51GDMO, 89–91, 97GENI, 24, 43, 49–51, 57, 58, 169GINI, 40GLIF, 56globally distributed infrastructure, see network-

ing testbedglobally distributed testbed, see networking test-

bedGMPLS, 36, 48, 55, 56, 98, 99, 123, 126, 128GNU/Linux, 34, 37, 40, 44GRE, 46, 127, 139

222 INDEX

Grid, 48GX-Bone, 43, 47–48, 57, 58, 99

OM, 47, 48RD, 47, 48

heavy ontologies, see ontologyHTTP, 53, 81hybrid

language, 77, 79optical networks, see optical networks

IDL, 89–91, 97IEC, 66imperative language, 77–79Imperative OCL, see OCLIMS, 98, 123inflexible networking testbed, see networking

testbedinfrastructure service, 44–46, 58Internet, 21, 28, 33, 38, 43, 46–51, 155, 166Internet2, 46, 50interrelated testbed, see networking testbedIOS, 42IP, 55, 56, 90, 97, 98, 110, 111, 113, 115

address, 36, 41, 44, 48, 54, 55, 90, 95, 99,111, 119, 127, 159, 170

aliasing, 39interface profile (DMTF), 99IP-on-IP, 47IPv4, 51, 56, 97, 99, 111, 116–119, 122,

127, 134, 141IPv6, 51, 56, 97, 99, 111, 114, 117–119,

122, 127, 134, 167mask, 117network, 51, 128, 169, 170range, 122, 127, 139route, 39, 47, 82, 113, 114, 118, 119, 127router, 37, 90, 113

IP-on-IP, see IPISO, 66isolation, 30, 32, 33, 40, 44, 47, 49, 58, 95, 154,

166IT, 90ITU, 30

J2EE, 75, 76Java, 66JCR, 166, 167, 169

JVM, 147

kernel, 41, 126, 132, 133KVM, 40

LAN, 32, 35latency, 35, 39Lex, 101, 102libpcap, 34libvirt, 39lightpath, 37, 56, 98, 154lightweight ontologies, see ontologylink emulation, 30, 39, 113locally distributed infrastructure, see network-

ing testbedlocally distributed testbed, see networking test-

bedlogical security, 167loopback interface, 113, 119, 127, 130, 134, 139loss probability, 29, 35, 37, 39, 56, 113, 115,

116, 127, 140LSP, 48

M2M, see Model2ModelM2T, see Model2Textm4, 53, 54MAC, 133machine virtualization, see virtualizationMANTICORE, 51MDA, 74–80, 91, 96, 101–106, 108, 110, 143,

148, 149, 154, 163–165, 172PIM, 74–77, 96PIM-to-PSM, 75, 76platform, 74–76PSM, 74–77, 96, 154PSM bridge, 75, 154PSM-to-code, 77PSM-to-PIM, 76, 172PSM-to-PSM, 75

MDD, 74MDE, 74meta-metamodel, 65, 66metamodel, 64–71, 76–79, 82, 84, 88, 102, 103,

114, 136, 143MIB, 90MIF, 89–91, 97MLN, 22, 29, 33, 41–42, 56, 57, 99model-to-model, see Model2Model

INDEX 223

model-to-text, see Model2Text

Model2Model, 75, 76, 78, 79, 104, 105, 135,136, 141–143, 145

Model2Text, 77–79, 102, 105, 106, 136, 145

modeling language, 61, 62, 64, 72, 91

ModelNet, 29, 33, 38–39, 56, 57, 99, 171

MOF (DMTF), 82, 84, 88–91, 101, 113, 114,118, 122, 123, 142, 143

MOF (OMG), 65–66, 68–71, 77, 91, 101, 103,105, 136, 142, 145

CMOF, 66, 71

EMOF, 66, 67, 70, 71, 78, 79, 143

MOF2Text, 78, 80, 91

mofcomp, 123, 142

MPLS, 30, 51, 55

MTU, 116, 141

multi-point link, 56, 148

multi-user testbed, see networking testbed

multimedia service platform, 167

namespace, 44, 47

narrative-oriented XML, see XML

NDL, 40, 53, 55–56, 58, 99

NE, 30

NetBuild, 35

Netem, 115, 127

NetKit, 33, 41, 56, 57, 99

NetLab, 41

NetML, 41, 99

network emulation, 38, 115, 141

networking networks, 49

networking testbed, 21, 25, 27, 28, 30, 39, 48,58, 61, 62, 90, 91, 94, 97–99, 101, 109,110, 113, 163

configurable, 21

educational, 167

federated, 24–26, 49, 52, 151, 153–157, 160,164, 165, 169

flexible, 21, 22, 27–31, 37, 55, 96, 97

globally distributed, 24, 27, 32, 33, 40, 43–53, 56–58, 152, 154, 163

inflexible, 21, 28–29

interrelated, 24, 26, 151–153, 160, 164

locally distributed, 27, 32–42, 56–58, 93,163

multi-user, 30, 32, 49, 154

optical, 28, 154, 156, 167

reconfigurable, 123

unconfigurable, 21

virtual, 39

wireless, 28, 154, 156

NGOSS, 90

NISTNet, 115, 127

Nixes, 46

NLR, 46, 50

NML, 56

NoSE, 40

NREN, 51, 52

ns, 21, 22, 34–36, 56, 57, 151, 153

ns2, see ns

NSE, 34

NSF, 49, 50

O&M, 50, 127

OCC, see ADRENALINE

OCL, 65, 69–72, 76–80, 82, 89, 91, 102, 137,171

Essential, 70

Imperative, 78

OCML, 71

OGF, 56

OIL, 71

OKBC, 71, 89

OLRM, see ADRENALINE

OM, see GX-Bone

OMG, 25, 61, 62, 64–66, 68, 70, 71, 76–79, 91,94, 101, 103, 110, 163–165

ontology, 25, 56, 61, 62, 71, 89, 91, 101–103,164, 171

heavy, 71

lightweight, 55, 71

mapping, 80, 91, 101, 102, 106, 164

OPNET, 22, 151

optical

connection, see optical link

hybrid network, 55

lightpath, see lightpath

link, 37, 156, 157

network, 21, 49, 50, 56

resources, 37

testbed, see networking testbed

ORBIT, 51, 58

ORCA, 51

224 INDEX

OSPF, 56, 86, 98, 120–122, 127–129, 134, 139,147

OSPF-TE, see ADRENALINE

overlay, 43, 46–48, 51, 171

OVF, 22, 160, 161

OWL, 71, 72, 80, 89, 91, 102

P2P, 151

Panlab2, see PII

PASITO, 43, 49, 52–53, 57, 58, 156, 167

PC, 33–36, 49, 54, 154, 159

PDF, 73

PII, 43, 49, 52, 57, 58

PIM, see MDA

PlanetLab, 22, 24, 27, 40, 43–47, 49, 51, 57, 58,99

AppManager, 46

Bellagio, 45

CoMon, 46

CoStat, 46

MON, 46

NM, 44, 45

OS, 44, 45

PlanetFlow, 46

PlanetSeer, 46

PLC, 43–46, 49, 50

Plush, 46

PSAD, 46

PsEPR, 46

S3, 46

Sharp, 45

Sirius, 45

Stork, 46

SWORD, 45

Tycoon, 45

PLC, see PlanetLab

PLDeploy, 46

plDist, 46

PlMan, 46

PPP, 55, 99, 113, 115, 127, 128, 130, 135, 139,141, 147

PRIME, 29

production environment, 21, 22, 26, 39, 48, 100,151, 157, 159–161, 164, 170

production network, see production environ-ment

provider, see WBEM

pShell, 46PSM, see MDApssh, 46

QEMU, 40QoS, 29, 35, 37, 38, 56, 99, 113, 114, 127, 128,

148, 155, 172QVT, 72, 77–80, 91, 101, 102, 149

QVTc, 78QVTo, 78QVTr, 77, 80, 104, 106, 109, 136

RDF, 56RDF(S), 55, 71, 89, 102RedIRIS, 52, 128reflective language, 65relational

database, 72, 73language, 104, 136

RIP, 41RPC, see XML-RPC, 38RPM, 46RSVP-TE, see ADRENALINE, 48Ruby, 46, 47, 51, 57

SAX, see XMLSBLIM, 89scalability, 34, 39, 93, 95, 151scenario, see experimentation scenario

designer, 108, 110, 132, 166repository, 96, 166segmentation, 154, 165

schema language, 63–64SDD, 97, 98semantic

dynamic, 65static, 65

SGML, 62, 63, 72, 91shareability, 27, 34, 38, 40, 44, 49, 52, 57, 154,

163, 166SHOE, 71SID, 52, 90, 91, 97simulation, 22, 33, 34, 56, 153slice, 40, 44–47, 49–52, 57, 58, 154–156sliver, 44–47SM, 81SmartFrog, 97, 98, 123SMI, 89–91

INDEX 225

SNMP, see ADRENALINE, 30, 31, 81, 86, 95

SOAP, 48, 81

software lifecycle, 74

SQL, 73

SSH, 38, 46, 81

static semantic, see semantic

STP, 55

subscenario, 24, 25, 154–157, 169

SUE, 53, 54

SURFNet, 56

SWRL, 71, 80, 102

syntax

abstract, 53, 61, 70, 77, 89

concrete, 61, 70, 72, 76, 77, 79, 89

SysML, see UML (language)

T2M, see Text2Model

tag definition, 69

tagged value, 69

TDM, 55

Teagle, 52

Telnet, 38, 81


administrator, 108–110, 132, 166

parameters, 95, 101, 103, 104, 109, 132–137, 139–143, 145, 147, 148, 171

text-to-model, see Text2Model

Text2Model, 76, 77, 143

TIED, 51

TIM, 23, 25, 94–104, 106, 108–112, 114, 115,120, 122, 123, 129, 132–136, 139–142,145, 147, 148, 153–159, 161, 163–167,169–172

ad hoc Extension Model, 26, 98, 111, 113,114, 118, 122–123, 142, 143, 164, 170,175–178

Core, 98, 99, 103, 104, 110–121, 123, 125,129, 130, 132, 137, 164

Module, 98, 99, 103, 104, 113, 117, 120,121, 123, 126, 164, 170

OSPF Module, 111, 113, 120–125, 128–130,132, 137, 164

scenario, 94, 100, 102, 104, 108–110, 132,136, 142, 143, 145, 152, 160, 161, 165,171, 172

scenario generation workflow, 108, 142–143

TIM-to-ADNETCONF, 132, 136–143, 185–191

TIM-to-TSM, 94, 100–110, 114, 122, 125, 129,132, 135–137, 141, 143, 145, 148, 153,157, 159, 161, 164–166, 170–172

TIM-to-VNUML, 129, 132–137, 142, 143, 172,179–185

TMF, 52, 90topology, 21, 22, 24, 29–31, 33, 37–43, 46–48,

55, 57, 61, 93–95, 98, 99, 111, 126–128,151, 155, 156, 165, 170, 171

traffic engineering, 37, 48transformation

definition, 75, 76, 78, 101, 104, 135, 136,141–143, 148

engine, 72, 80, 101, 143rule, 75, 76, 79, 101–104, 106, 109, 135, 141tool, 75, 95, 102, 109, 165

TSM, 94–96, 101, 103–106, 109, 110, 125, 126,129, 133, 135–137, 141, 142, 145, 147,156, 159–161, 163, 164, 171, 172

scenario, 96, 101, 110, 132, 136, 143, 145,148, 153, 166, 172

scenario generation workflow, 109, 143–147TSM-to-TIM, 172

Ubuntu, 147UDP tunnelling, 46, 47UML (language), 53, 56, 57, 65–72, 76, 82, 89–

91, 94, 101, 102, 132, 143, 145, 164,165, 170

CIM profile, 88–89, 102, 103, 143, 145, 149language units, 67notation, 173–174SysML profile, 66

UML (virtualization), 40–42, 57UML profile for CIM, see UMLURI, 63UTP, 55

vBET, 22, 33, 42, 56, 57, 99VCT, 52, 57VINI, 46, 47, 51, 57, 99VIOLIN, 47virtual

bridge, 41, 47machine, 24, 34, 39–42, 44, 45, 47, 52, 126,

127, 132–134, 147, 148, 154, 160network, 30, 39–42, 51, 126, 133, 154, 160networking scenario, 40, 41, 53

226 INDEX

node, 36, 39, 42, 51

VirtualBox, 40

virtualization, 22, 28, 30, 33, 34, 39–42, 44, 49,51, 52, 57, 125, 154, 160

machine, 39

VLAN, 30, 33, 37, 38, 51, 52, 55, 94, 95, 127,139–141

VM, 44

VMM, 44

VMware, 39

ESX, 40, 52

ESXi, 40, 51

VirtualLab, 40

VN, 39

VNE, 40

VNUML, 22, 33, 40–42, 52, 56, 57, 99, 103,104, 125, 126, 132, 133, 135–137, 141,143, 145, 147, 148, 164, 166–169, 171,172

DTD, 145

OSPF DTD, 127

TSM, 126–127, 132, 133, 136, 137, 143, 145

VNUML DTD, 125, 126, 132, 135

VNUML OSPF DTD, 125, 132, 136

VNUMLGUI, 40

VPN, 55

VServer, 44, 46

vxargs, 46

W3C, 25, 61, 62, 64, 72, 73

wavelength, 55, 128, 154

WBEM, 26, 30, 31, 81–82, 84, 87, 89, 100, 106,114, 122, 123, 151, 157–161, 164, 165,169, 170

provider, 81, 82, 157–159, 161

WBEMServices, 123

WDM, 55

Weevil, 22, 53–54, 57, 58, 99, 170

well-defined language, 61

WHYNET, 29

Windows XP, 34

wireless

hardware, 29

link, 51, 55, 156

networks, 21, 50, 51

node, 157


WS, 81WS-CIM, 81, 89WSDL, 81

Xen, 34, 39–42, 52, 57XHTML, 63, 73XMI, 63, 65, 66, 70–72, 89, 91, 106, 145XML, 21, 25, 38–42, 48, 54–57, 61–64, 70–74,

81, 89–91, 101–103, 105–107, 110, 125–128, 132, 135–137, 141, 142, 145, 147,148, 164

application, 63, 64, 70, 73data-oriented, 63, 73, 102DOM, 72, 74DTD, 57, 63, 64, 70, 81, 103, 125instance document, 64metamodel, 105, 136, 143, 145namespace, 63, 64, 70–74narrative-oriented, 63, 64, 73RPC, 44, 45SAX, 72, 74Schema, 57, 63, 64, 73, 103

XML Schema, see XMLXML-RPC, see XMLXOL (GX-Bone), 48XOL (ontology), 71XPath, 72, 73, 102XQuery, 72–73, 91, 101, 102XSD, see XML SchemaXSL, 73XSLT, 41, 66, 72–73, 91, 101, 102, 106

Yacc, 101, 102

On Scenario-based Model-driven Con guration Management...

Documents

Transcript of On Scenario-based Model-driven Con guration Management...