Defensa de Tesis Doctoral

Presentación del tema: "Defensa de Tesis Doctoral"— Transcripción de la presentación:

1 Defensa de Tesis Doctoral
Contribución a la Gestión de Configuraciones de Infraestructuras Flexibles de Experimentación de Red mediante Modelos Basados en Escenarios Defensa de Tesis Doctoral 13 de abril de 2010 Autor: Fermín Galán Márquez Tutor: David Fernández Cambronero Defensa: Salón de Grados, Edificio A, ETSIT UPM, Madrid Si bien la memoria de tesis doctoral está escrita en inglés (por el motivo de maximizar su difusión internacionalmente), la presentación se realiza en castellano (ya que todos los miembros del tribunal pertenecen a universidades españolas).

2 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Conclusiones y Trabajos Futuros

3 Contexto Infraestructuras de experimentación de redes (testbeds)
Una infraestructura, sistema de pre-producción o prototipo controlado, compuesto de nodos (pe. sistemas finales, routers, etc.) usada para la experimentación en sistema de red (protocolos, arquitecturas, etc.) bajo condiciones que asemejan las de los entornos reales Herramienta clave en distintos ámbitos Investigación: nuevas ideas Industrial: desarrollo, pruebas y depuración Educación: proporcionan experiencia práctica

4 Problema La tendencia actual en configuración de testbed se basa en la definición de escenarios Pe. Emulab, ADRENALINE®, herramientas de construcción de testbeds virtualizados, etc. … pero el problema de la dependencia tecnológica de los escenarios no ha sido resuelto Las especificaciones de escenario son específicas de testbed No existe un mecanismo común de especificación de escenarios Reutilizar escenarios entre distintos testbeds es costoso Destacar: Por qué es la tendencia actual (esbozar rápidamente lo que luego se dice en transparencia 10)

5 Solución a la dependencia tecnológica de escenarios
Solución Propuesta una única especificación independiente de testbed Solución a la dependencia tecnológica de escenarios Testbed 1 Testbed 2 Testbed N … Nuestra solución Arquitectura dirigida por modelos basada en escenarios Modelo Independiente de Testbed Metodología de transformación múltiples especificaciones de escenario específicas de testbed Escenario deseado Testbed 1 Testbed 2 Testbed N … Estado del arte

6 Objetivo Solucionar el problema de la dependencia tecnológica de escenarios en las infraestructuras de experimentación (testbeds) Arquitectura de gestión de configuración dirigida por modelos basada en escenarios Modelo Independiente de Testbed, lenguaje común para la definición de escenarios Metodología de transformación, para cubrir el “hueco” entre el lenguaje común y los testbeds específicos

7 Metodología y Estructura
Estado del arte en gestión de configuración para testbeds Introducción y taxonomía de testbeds Lenguajes Transformaciones DMTF CIM Definición del problema Tecnologías habilitadoras Arquitectura dirigida por modelos basada en escenarios Modelo Independiente de Testbed Metodología de transformación CONTRIBUCIÓN Especificación detallada del modelo Validación experimental Casos de aplicación Convencional Internet del Futuro Testbed basado en WBEM Entornos de producción Gestión dirigida por modelos en VNUML y ADRENALINE

8 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Taxonomía y Gestión de Testbeds Estado del arte Contribuciones Conclusiones y Trabajos Futuros

9 Una Taxonomía de Testbeds
Escenario de experimentación Contexto de red proporcionado por el testbed en el cual un experimento es realizado en un intervalo de tiempo dado Flexibilidad de testbed Capacidad del testbed de reconfigurar su infraestructura para implementar diferentes escenarios de experimentación Escenario (acoplado a la infraestructura) Infraestructura física del testbed Testbed no flexible Infraestructura física de testbed Tecnologías habilitadoras de escenario (virtualización, VLAN, emulación de enlace, etc.) Escenario Gestión de configuración Topología de red Propiedades/configuraciones Testbed flexible

10 Alternativas de Gestión de Configuración
No basadas en escenario Procedimientos manuales para configurar escenarios Múltiples desventajas Alto consumo de tiempo en tareas de gestión Requiere conocimientos específicos de la tecnología del testbed a bajo nivel Propensa a errores Mala escalabilidad Basada en escenario (estado del arte) Procedimientos automáticos (herramientas) para configurar escenarios Especificaciones de escenario

11 Ciclo de Vida del Escenario
Diseño Despliegue Operaciones en ejecución Repliegue Testbed Herramienta de gestión basada en escenario Especificación de escenario Destacar: El caso de deploy (es esencial, cualquier de los otros es prescindible pero no este). Otras notas: Interacciones de la herramienta con el testbed: SSH, SNMP, WBEM, RPC Deploy: Explicit allocation or automatic allocation Operations on runtime: events execution, scenario monitoring, others

12 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Infraestructuras de experimentación Gestión de testbeds Aproximaciones genéricas Modelado y transformación de información de gestión Contribuciones Conclusiones y Trabajos Futuros

13 Arquitectura de Emulab
[WSL+02] Emulab DB Servidores de control Internet Usuario de Emulab Switch de control Cluster de PCs PC PC PC … Destacar: Mencionar arquitecturas de otros testbeds Otras notas: PCs “vacios” Backbone de switches programable

14 Gestión de Configuración en Emulab
Repliegue (swap-out) diseño de experimento interacción con el experimento Realización Especificación (ns) Proceso (parsing) Asignación Auto- configuración Despliegue (swap-in) configuración objetivo correspondencia de recursos Otras notas: puebla: introduce configuración independiente de despliegue Asignación: algoritmo Autoconfiguración: scripts para hacer pulling de la DB Emulab DB información de configuración puebla

15 Otros Testbeds ADRENALINE [MPM+05] ModelNet [VYW+02]
Especificación de escenario basada en XML (red + 6 procesos GMPLS) ModelNet [VYW+02] Especificación de escenario basada en XML (grafo) Descripción en XML de los nodos físicos del testbed (core y edge) Herramientas de testbed basadas en virtualización Formatos de texto para describir escenarios (XML y otros) VNUML/EDIV [GGF+09], NetKit [PR08], MLN [Beg06], vBET [JX03], Dynagen [Anu09] Testbeds globalmente distribuidos Uso incipiente de gestión basada en escenarios PlanetLab [PACR03][BBC+04], GX-BONE [TWP+05], DRAGON [LSJ06], GENI [GEN08c], FEDERICA [FED09a], PII [PII09] Otras notas: Virtualización -> reducción de costes

16 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Infraestructuras de experimentación Gestión de testbeds Aproximaciones genéricas Modelado y transformación de información de gestión Contribuciones Conclusiones y Trabajos Futuros

17 Aproximaciones Genéricas
Weevil [WRCW05] Centrado en dispositivo, no configura la red Sacrifica riqueza de escenario para conseguir flexibilidad, pe. propiedades de nodo arbitrarias (opaco) Pone gran parte del esfuerzo en el usuario AnyBed [SHK06] Limitaciones en el modelo de escenario, pe. direcciones IP Network Description Language [vdHDG+08] Se centra en redes ópticas No existe aplicación (documentada) a la definición de escenarios de red para testbeds Muy orientado a capa física, limitaciones en el modelo de escenario, pe. redes multi-punto (estilo Ethernet) Otras notas: Tools: Weevil, Anybed Lenguaje: NDL NDL en producción: SURFNet y GLIF

18 Resumen (1) Lenguaje Topología básica Direcciones IP Rutas Estáticas
Nodos Enlaces IPv4 IPv6 Emulab   ADRENALINE ModelNet VNUML NetKit MLN vBET Dynagen PlanetLab (VINI) GX-Bone DRAGON (AST) Weevil AnyBed NDL Conclusiones principales a mencionar: Todos los sistemas analizados usan especificaciones de escenario Los únicos casos raros son PlanetLab y Future Internet (en definición), pero incluso así se apunta por ahí (VINI y 3/5 clusters en GENI) Intra-slice vs. extra-slice management

19 Ninguno alcanza las 10 características
Resumen (y 2) Lenguaje Modelo de enlace Procesos de nodo Lenguage represent. Conf. dinámica Suma (10) PPP Multi QoS Emulab   ns2 8 ADRENALINE GMPLS XML 6 ModelNet 4 VNUML Plugins NetKit NetML Texto 5 MLN vBET Dynagen PlanetLab (VINI) Ruby GX-Bone DRAGON (AST) Weevil Prop. Arb. UML/m4 2 AnyBed 3 NDL RDF(S) Ninguno alcanza las 10 características Conclusión Muchos casos están basados en XML (importante para el tema de la validación) No hay ningún escenario común: ligados a testbed Emulab->ADRENALINE ? Ninguno se puede “promover” como escenario común (insuficientes) Emulab es el lenguaje más completo, pero no es perfecto. Su mayor defecto es relativo a los procesos de nodo y su sintaxis ns. Usar Weevil o AnyBed como escenario común implicaría modificar testbed (interactúan directamente con el testbed)

20 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Infraestructuras de experimentación Modelado y transformación de información de gestión Contribuciones Conclusiones y Trabajos Futuros Well-defined language Abstract syntax Concrete syntax -> (Formal) grammar -> Formal languages

21 Estándares de Modelado de OMG
[OMG09a][AK03] MOF M3: Meta-metamodelo conforme a instancia de UML … M2: Metamodelo Profile Perfil QVT OCL Modelo de clases Modelo de instancias representa M1: Modelo Definición de transformación Metamodelo = modelo de un lenguaje de modelado Modelado de sistemas (no de software exclusivamente) M0 -> M1 -> M2 ->M3 MOF, conceptos básicos de modelado (EMOF) UML, lenguaje de facto desde hace años para el modelado de sistemas software. Clase, relaciones, instancia, paquete. Extensibilidad. Perfiles. OCL, restricciones para modelos basados en MOF (cualquier nivel) QVT, se ve en la siguiente “conforme a” “instancia de” Sistema físico o lógico M0: Sistema

22 OMG Model Driven Architecture (MDA)
[MDA03][KWB03] Metamodelo PIM Metamodelo de definición de transformaciones Metamodelo PSM M2 conforme a Pe. Perfil UML OMG QVT, ATLAS ATL Pe. UML + OCL basado en Definición de transformación basado en conforme a conforme a M1 PIM Herramienta de transformación PSM Destacar Grado de madurez de MDA Otras notas: PIM -> PSM -> plataforma (.NET, J2EE) Model2Model Model2Text Automation representa (alta abstracción) representa (baja abstracción) Sistema M0

23 Otras Aproximaciones de Modelado y Transformación
XML [BPSM+08] Transformaciones basadas en XSLT [Kay07], XQuery [BCF+07] o procesado directo (SAX/DOM) Ontologías (pe. OWL [DSB+04]) Transformaciones basadas en (meta)ontologías de correspondencia (varias) [LVAB03] se centra en la correspondencia de información de gestión Otros SGML [ISO86], (A/E)BNF [BBG+60][CO05][ISO96], Entity-Relationship Diagram [Che76] XML: Muy apropiado para describir relaciones basadas en árbol No tan bueno para describir relaciones arbitrarías Aunque es posible, pe. OMG XMI [OMG07] XMI: sintaxis concreta para los modelos de OMG (cualquier nivel) Ontologías: Def ontología: especificación formal y explícita de una conceptualización compartida Se centran en la representación del conocimiento (semántica) Relaciones con XML Relaciones con UML

24 DMTF Common Information Model
Lenguaje de información de gestión usado en la arquitectura WBEM Especificación formal en la CIM Infrastructure [DMT08a] Orientado a objetos Modelo de información de gestión muy amplio y completo (CIM Schema) Modelo de Extensión Device Physical Core Appli- cation System + restricciones Perfil DMTF Network Orientación a objetos: Abstracción Especialización Asociación Métodos para caracterizar comportamiento CIM Schema: Core -> Common Models -> Extension Models -> Perfiles DMTF CIM Schema

25 Alternativas de Representación para CIM
Managed Object Format (MOF) [DMT08a] Basado en texto Especificación ABNF Representación “nativa” La DMTF define los modelos de información usando MOF XML, usado en los protocolos de transporte de WBEM CIM-XML, basada en DTD [DMT09c] WS-CIM, basada en XSD [DMT09f] Perfil UML para CIM (DSP0219) [DMT07e] DMTF MOF  modelos UML Ontologías, varios trabajos [LDR03][QAW+04][LVB04] [LDR03] -> OKBC [QAW+04] -> OWL [dVVB04] -> RDF(S) y OWL

26 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Arquitectura Modelo Independiente de Testbed Transformación TIM-a-TSM Validación Aplicaciones Conclusiones y Trabajos Futuros

27 Arquitectura Dirigida por Modelos Basada en Escenarios
Parámetros testbed 1 Testbed 1 Escenario deseado Herramienta de gestión basada en escenarios en testbed 1 Transformación TIM a TSM2 TIM a TSMN TIM a TSM1 Parámetros testbed 2 Testbed 2 Herramienta de gestión basada en escenarios en testbed 2 Escenario en el Modelo Independiente de Testbed (TIM) Parámetros testbed N … … Testbed N Herramienta de gestión basada en escenarios en testbed N Escenarios en el Modelo Específico de Testbed (TSM)

28 Principios de Diseño Para la arquitectura
Conseguir la independencia tecnológica de los escenarios Evitar cualquier modificación en los testbeds y herramientas de gestión existentes Para el Modelo Independiente de Testbed (TIM) Cobertura Modularidad Extensibilidad futura Orientación al nivel de red Simplicidad TIM desing principles (from 4.3.1): Modularity. The design of a TIM achieving the completeness requirement described in the previous bullet would be overwhelming considering the huge (and ever growing) number of different services and functionalities that a testbed may include. Therefore, a modular approach is needed. Network-layer orientation. On one hand, although networking testbeds could include systems for application management, e.g. SmartFrog, SDD, etc., this is considered a solved problem. On the other hand physical layer and link layer specification have no sense in TIM, because of its high-level deployment-independent nature. Therefore, the TIM scope will be focused on network layer, IP at the time being, considering the both major versions existing nowadays (IPv4 and IPv6). Future extensibility. Networking is a very active field and new technologies are continuously arisen, e.g. protocols, architectures, services, etc. Given that TIM and its associated architecture are indeed a configuration management approach for testbed where these new technologies are going to be tested and experimented with, its design has to take into account future extensibility to avoid obsolescence.This includes the application of the model to clean-slate testbeds proposed in Future Internet initiates, in which IP protocol is not used at all. Thus, although the TIM is IP-layer oriented, as described in the previous bullet, it must not preclude their utilization in no-IP testbeds. Simplicity. In order to be easily understandable by users and implementable in software tools, etc., the resulting TIM must be as simple as possible to fulfill the principles described above, that is without including any unneeded or irrelevant feature or functionality.

29 Estructura básica del TIM Fundamentos CIM
El TIM está basado en CIM Reutilización del CIM Schema (modelo Core y Comunes estándar) Incluye un Modelo de Extensión ad hoc para el TIM Modular TIM Core, conceptos principales de redes TIM Modules, funcionalidades de red asociadas a nodos TIM como un conjunto de pseudo-perfiles DMTF Conjunto restringido de propiedades y ausencia de métodos Pero no usado en un contexto de gestión WBEM

30 Estructura Básica del TIM Relación a Alto Nivel con el CIM Schema
Modelo de Extensión ad hoc TIM Core (perfil autónomo) TIM Module (perfil de componente) Network System Core

31 Comprobación de Cobertura (1)
Lenguaje Topología básica Direcciones IP Rutas Estáticas Nodos Enlaces IPv4 IPv6 Emulab   ADRENALINE ModelNet VNUML NetKit MLN vBET Dynagen PlanetLab (VINI) GX-Bone DRAGON (AST) Weevil AnyBed NDL TIM

32 Comprobación de Cobertura (y 2)
Lenguaje Modelo de enlace Procesos de nodo Lenguage represent. Conf. dinámica Suma (10) PPP Multi QoS Emulab   Ns2 8 ADRENALINE GMPLS XML 6 ModelNet 4 VNUML Plugins NetKit NetML Texto 5 MLN vBET Dynagen PlanetLab (VINI) Ruby GX-Bone DRAGON (AST) Weevil Prop. Arb. UML/m4 2 AnyBed 3 NDL RDF(S) TIM Modules CIM 9 El TIM cubre todas las características estáticas

33 Modelo Independiente de Testbed (TIM) Diagrama de Clases
Forwarding Rutas estáticas Asociadas a nodos Escenario Enlace Nodo Interfaz Direcciones IPv4 y IPv6 Asociadas a interfaces

34 Modelo Independiente de Testbed (TIM) Características de Enlace
Basado en los modelos de NISTNet/netem

35 Modelo Independiente de Testbed (TIM) OSPF Module
Procesos OSPF asociados a nodos TIM Core TIM OSPF Module

36 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Arquitectura Modelo Independiente de Testbed Transformación TIM-a-TSM Validación Aplicaciones Conclusiones y Trabajos Futuros

37 Transformación TIM a TSM: Principios de Diseño
Dos entradas Neutralidad con respecto al TSM Consideraciones especiales para XML Independencia con respecto a la tecnología de transformación Simplicidad From 4.4.1: Two inputs. The TIM-to-TSM transformation have to take into account two inputs: the TIM and the parameters used for the particular testbed to which the TSM is addressed. TSM neutrality. The methodology has to be general and not focused on any particular TSM modeling technology, although special consideration could be made for specially relevant cases. In particular, the analysis done in Chapter 2 shows that XML is very extended in TSM scenario modeling, so we pay special attention to it. Flexibility. The methodology should be as flexible as possible. This is a key requirement in a context in which there is a high and growing diversity of networking testbeds (thus, diversity of target TSM) to which the methodology could be applied. Simplicity. Similar to the simplicity principle for the TIM design, the transformation should be as simple as possible without including unnecessary steps.

38 Transformación TIM a TSM: Alternativas
Candidatos Codificación DMTF MOF Parser basado en texto (Lex/Yacc) Codificación basada en XML para CIM XSLT XQuery Ontologías ([LDR03][QAW+04][LVB04]) Ontología de correspondencia [LVAB03] Perfil UML para CIM (DSP0219) OMG MDA (QVT/ATL)

39 Transformación TIM a TSM: Correspondencia ontológica vs. MDA
MDA es la mejor alternativa debido a Lenguajes de reglas de ontologías (pe. SWRL) son menos expresivos que QVT/ATL en MDA El perfil de UML para CIM es un estándar, las ontologías que representan CIM no lo son (actualmente) MDA no impide la utilización de ontologías de correspondencia [LVAB03] puede usarse Formula = “ATL” o “QVT” Expression = “<la regla efectiva>” Otras razones: Dificultad para definir procesos “Ontology2Text” Model2Text está definido en MDA Directo cuando Text = XML

40 Transformación TIM a TSM: Metodología
Premisas Escenarios representados como modelos de instancias del TIM en el perfil UML para CIM TIM Core, Mod 1, Mod 2,… Mod N TSM

41 Transformación TIM a TSM: Paso 1: Formalización del TSM
Definir el TSM como un metamodelo basado en la arquitectura MOF de la OMG Algoritmo predefinido para TSMs basados en XML (contribución de la tesis) (Algoritmo) DTD/ XSD Algoritmo descrito en la memoria de tesis en Sección TSM formalizado

42 Transformación TIM a TSM: Paso 2: Definición de Asociaciones TIM-a-TSM
Mod 1 Mod 2 Mod N+1 … Core ? Mod N Parámetros de testbed ? TSM formalizado

43 Transformación TIM a TSM: Paso 3: Construcción de Reglas TIM-a-TSM
Lenguaje natural  reglas formales Preferibles las aproximaciones declarativas Criterios prácticos guían la elección del lenguaje de transformación, no la metodología Estabilidad, grado de mantenimiento y soporte, base de usuarios, conocimiento del desarrollador Actualmente, QVTr y ATL son los mejores candidatos

44 Transformación TIM a TSM: Paso 4: Adaptación de Formato
Necesario para aquellas herramientas basadas en escenarios que no basadas en MDA En la práctica, siempre (actualmente) Alternativas Directa: Model2Text Indirecta: Model2(bien-conocido)Model + Model2Text directa Para TSMs basados en XML, indirecta Model2(XML)Model: algoritmo predefinido (contribución de la tesis) (XML)Model2Text: algoritmo descendente (top-down) directo

45 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Arquitectura Modelo Independiente de Testbed Transformación TIM-a-TSM Validación Aplicaciones Conclusiones y Trabajos Futuros

46 Objetivo Demostrar la viabilidad de la arquitectura dirigida por modelos basada en escenarios con su utilización en un caso real Dos testbeds de validación Basado en VNUML Virtual Gestionado por VNUML TSM basado en XML VNUML DTD y VNUML OSPF DTD ADRENALINE Físico Gestionado por ADNETCONF ADNETCONF DTD y ADNETCONF OSPF DTD

47 Conjunto de Validación
84 instancias del TIM 968 instancias del TIM AST CAN PVC 2 2 NAV 2 2 4 GAL CYL RIO 3 3 2 3 ARA 5 2 2 CAT 3 2 1 4 MAD IX 2 3 3 3 3 CLM BAL escenario basic (5 nodos, 3 enlaces multipunto, rutas estáticas) 3 3 4 EXT 2 3 VAL 10 2 TEF 2 MUR escenario rediris (19 nodos, 31 enlaces PPP, routing OSPF) AND 673 instancias del TIM 2 10 PAL WA MI NY 3 3 En conjunto, todas las clases definidas en el TIM Core y OSPF Module son utilizadas 15 6 CA1 UT 15 3.75 6 6 6 3 3 NJ 3 3 3 6 3 PA NE IL DC CO 5.25 3.75 15 CA2 7.5 7.5 GA escenario nsfnet (14 nodos, 21 enlaces PPP, routing OSPF) TX

48 Validación Desarrollo Transformaciones TIM-a-TSM
Basado en la metodología sistemática Ambos TSMs basados en XML, se utiliza el algoritmo de formalización Asociaciones resultantes Para TIM-a-VNUML, 27 reglas y 14 parámetros de testbed Para TIM-a-ADNETCONF, 23 reglas y 9 parámetros de testbed Filtrado TIM-a-VNUML filtra elementos de QoS de enlace TIM-a-ADNETCONF filtra IPv6, rutas estáticas y enlaces multi punto Implementación en ATL debido a razones prácticas (madurez y disponibilidad de software) El detalle de las asociaciones resultantes se encuentra en la memoria de tesis, Secciones y 6.4.2, para VNUML y ADNETCONF respectivamente.

49 Validación Flujo de Validación
Flujos de generación de escenarios TIM rediris basic nsfnet parámetros de testbed ADNETCONF parámetros de testbed VNUML Flujos de generación de escenarios TSM baseMgtAddress baseVlan … (7 más) defaultKernel defaultFilesystem ospfdBinPath … (11 más) TIM-a-VNUML (27 reglas) TIM-a-ADNETCONF (23 reglas) Flujos de despliegue de escenarios Basic VNUML TSM RedIris VNUML TSM NSFNET VNUML TSM Basic ADNETCONF TSM RedIris ADNETCONF TSM NSFNET ADNETCONF TSM VNUML ADNETCONF … filesystem OCC0 ospfd kernel … … … host físico OCC73 ADRENALINE testbed ® (simplificado)

50 Validación Flujo de Generación de Escenarios TSM
Paso preparatorio ECore CIM Schema (reducido) TIM Metamodelo UML Perfil UML para CIM CIM Schema TIM Ext (UML classes) Desarrollos producidos como resultado de la metodología VNUML/ADNETCONF TSM Metamodelo XML Metamodelo ATL Transformación TIM-a-TSM Transformación de adaptación del TSM CIM Schema (Clases ECore) TIM Ext T2M reglas de transformación reglas de transformación (Clases ECore) Escenario TIM Escenario TSM Doc. XML Trans. Trans. TSM (XML) T2M M2T entrada salida input salida Escenario TIM (Instancias CIM) (Instancias ECore) (Instancias UML) entrada Parámetros de testbed T2M Parámetros de testbed (Instancias CIM) (Instancias UML) (Instancias ECore)

51 Validación Flujo de Despliegue de Escenarios
Alimentar VNUML y ADNETCONF con los correspondientes escenarios (en XML) generados en el paso anterior Todos los escenarios son desplegados correctamente en el testbed basado en VNUML y en ADRENALINE Escenario Transformación (s) Despliegue (s) VNUML ADNETCONF basic 0.297 0.285 15.166 - nsfnet 1.258 1.585 52.307 83.006 rediris 2.073 2.022 74.875 Las otras operaciones de gestión de escenario también funcionan, pe. monitorización en ADRENALINE Para todos los casos, el overhead del paso de transformación es menor al 3% del tiempo total que le lleva a la herramienta de gestión realizar el despliegue

52 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Arquitectura Modelo Independiente de Testbed Transformación TIM-a-TSM Validación Aplicaciones Conclusiones y Trabajos Futuros

53 Testbed Convencionales Interrelacionados Basados en Escenarios
Coste inicial = T×N Coste unitario sinc. = T Diseño preliminar (analítico, simulación de red, etc.) Coste inicial = N Coste unitario sinc. = 1 Diseño de escenarios de experimentación (sc1, sc2, … scN) para el testbed 1 Diseño de escenarios de experimentación (sc1, sc2, … scN) para el testbed 3 Diseño de escenarios de experimentación (sc1, sc2, … scN) usando TIM Diseño de escenarios de experimentación (sc1, sc2, … scN) para el testbed 2 Diseño preliminar (analítico, simulación de red, etc.) Sincronización manual feedback feedback feedback feedback feedback feedback Despliegue Repliegue Ejecución de experimento varias veces Despliegue Repliegue Ejecución de experimento varias vaces Despliegue Repliegue Ejecución de experimento varias veces Testbed basado en virtualización Testbed distribuido (pe. PlanetLab) Testbed cercano a despliegue final Solución final

54 Otras Aplicaciones Testbeds de la Internet del Futuro (Future Internet) Testbed basado en WBEM Entornos de producción Simulación, pe. TIM-a-ns2

55 Contenidos Motivación y Objetivos Estado del arte Contribuciones
Conclusiones y Trabajos Futuros Conclusiones Trabajos futuros Publicaciones

56 Conclusiones Solución al problema de la dependencia tecnológica de escenarios, con varios casos de aplicación (5 casos) y validado experimentalmente (2 testbeds) Arquitectura de gestión de configuración dirigida por modelos Principios de MDA, PIM  TIM y PSM  TSM Evitar cualquier modificación en testbeds y herramientas existentes Modelo Independiente de Testbed (TIM) Cobertura, orientación al nivel de red, modularidad, extensibilidad, simplicidad Basado en el CIM Schema de la DMTF Metodología de diseño TIM-a-TSM Genérica y sistemática, optimizada para TSMs basados en XML (caso habitual) Basada en MDA de la OMG, combinable con ontologías de correspondencia

57 Trabajos Futuros Nuevos usos de la arquitectura
Aplicación a los testbeds de la Internet del Futuro (GENI, FEDERICA, etc.) Testbeds basados en WBEM Mejorar la arquitectura (principalmente el TIM), en orden de mayor a menor dificultad Modelo Común de Testbed Aplicar la idea del TIM a los parámetros de testbed Transformaciones inversas TSM-a-TIM Regeneración de información Modelado de dinámica de experimentos TIM Dynamics Module Modelado de restricciones (constraints) Varias alternativas (perfil DMTF, OCL, ontologías) Comentar grado de dificultad de los distintos items. From 8.3 (Future Work): Regarding future working lines for research, our aim is to follow two different directions. One of them is to explore new ways to use the architecture. This includes bringing into reality the novel testbed approaches. One case are Future Internet federated testbeds (GENI, FEDERICA, etc.). In this line, scenario split capabilities at TIM layer would be introduced and the Subscenario Interconnection Model developed. The other novel approach is WBEM-based testbeds (Section~\ref{sec:ch7:wbem}) as new paradigm to implement scenario-based management. Note that some of thse works can imply extensions to the TIM, i.e. to specialize node and link semantics to describe specific resources for federated testbed or adding scenario-oriented methods to TIM classes for WBEM-based methods. Another different line, which is discussed more in detail in the following subsections, is on enhancements in the model-driven architecture independently of its application to particular testbed kinds. These enhancement are mainly related with the TIM. From (Experiment Dynamics Modeling): Although TIM aims at completeness, and in fact this is one of its design principles, the current model has focused on structural aspects of networking scenarios. Dynamic behavior modeling has been left out up to now. In particular, the ability to describe a sequence of event changing the status of scenario nodes and links and taking place at precise moments of time, using as t=0 reference the moment in which the experiment starts. For example, to describe that a given link goes down at t=2s, then goes up 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 dynamic routing protocol reacts to changes in the topology. As can be observed in Table~\ref{tab:ch5:tim-analysis}, some of the existing testbeds and tools (Emulab and Weevil) are actually implementing this kind of experiment dynamics modeling. Thus, this line of work addresses the definition of a TIM Module to describe dynamic behavior based on sequences of events. In order to do so, the CIM Schema should be reviewed in order to find whether some semantically close classes could be reused. In negative case, the needed functionality would have to be defined in a ad hoc Extension Model. Once this Module has been developed, the validation test should be expanded to show how a TIM-to-TSM transformation uses this information to generate the corresponding specific event sequences description for a testbed supporting this feature (e.g. Emulab). From (Constraints Modeling): Currently, the only restrictions that are associated to the TIM regarding the base CIM Schema classes and associations in which it is based are on are a limited set of properties and the total removal of methods. However, additional constrains could be very interesting in two context. First, to define well-formedness restrictions, e.g. that a TIM_LinkConnectivityCollection with MaxConnections equals to 3 must have no more than three associated IPProtocolEndpoints. Second, to specify user-defined constraints adapted to some experimentation contexts, e.g. all IP addresses connected to the same subnet must be different (The experimentation context associated to this constraint corresponds to the normal behavior of an IP network. 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 context this constraint will not be used, e.g. to experiment with tools able to detect IP duplication problems and react to them.). Currently, the only way of ensuring these constraints is implementing the checking in the TIM-to-TSM transformation code. However, this is not the proper place, because of constraints should be intrinsic to TIM scenarios themselves. Constraint evaluation could be integrated in the scenario design tools, that 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 profiles approach but its main drawback is that constraints expressed this way can not automatically checked by software tools. Therefore, it should be complemented with one of the following approaches. Use OCL constraints. Actually, in CIM specification there are two qualifiers (ClassConstraint and PropertyConstraint) that enable to define OCL constraints within class scope (There is also a MethodConstraint) qualifier but, given that the TIM does not use methods, it is useless in our case.). However, they seem to have a limited intra-class scope and it is not clear how to use to express constraints involving several classes. Use ontologies. As TIM is based on CIM and CIM can be expressed in ontology languages, providing an ontological overlay for TIM should be easy. Constraints would be expressed in terms of this ontology. Note that an onthological approach to TIM could have additional advantages, e.g. to find which networks comply with concrete equirements [Sanchez08]. From (The Common Testbed Model) One of the functional components of our model-driven architecture are the testbed parameters, defined as “a description of the testbed environment, [which] depends on the testbed nature”. They are merged to the TIM scenario as second input for the TIM-to-TSM transformation to produce the final TSM. However, the problem of how to represent testbed parameters has not been addressed as part of this work. In the current version of the model-driven architecture, parameters can be freely structured as TIM-to-TSM designer desires. In particular, the testbed parameters for the VNUML-based testbed and the ADRENALINE testbed considered in the experimental validation are flat tables encapsulated within CIM_SettingData instances. Although this is a simple and straightforward approach which fits for VNUML and ADNETCONFF, it lack formalisms and could be limiting when the parameters are complex, e.g. a transformation requiring as “parameter” the physical topology of the testbed (including maximum bandwidth associated to each links) because a scenario-matching algorithm is used to produce the TSM. Therefore, it would be interesting to develop a common model to represent testbed parameters, in the same way TIM provides a common representation for scenarios. Actually, the best way of modeling testbed parameters is modeling the testbed itself, it could be named the Common Testbed Model (CTM). In fact, some of the tools analyzed in Chapter 2propose models for the underlying testbed, e.g. ModelNet or AnyBed, but they are very limited and technology dependent. Using a common representation will ease the development of TIM-to-TSM transformations, because not only a vocabulary for the TIM is fixed, but also for the testbed parameters. In order to develop this CTM, an analysis of the existing testbed has to be done in order to get modeling requirements. The analysis done in Chapter 2 could be useful for this purpose. Then, it should be desirable to use CIM to implement the CTM, to be aligned with TIM.

58 Alineamiento con Estándares
Gestión de configuración dirigida por modelos basada en escenarios DMTF CIM OMG MDA La evolución del CIM Schema enriquece el TIM Madurez tecnológica (software) debida a aceptación industrial

59 Resumen de Publicaciones
Veintitrés publicaciones 2 de ellas en revistas JCR (una más en revisión en una revista JCR) 1 patente pendiente de concesión (esperada en 2010) en Europa, Japón y Estados Unidos, propiedad del CTTC Resumen Dos publicaciones principales sobre el núcleo de contribuciones del doctorado Dieciocho publicaciones secundarias sobre VNUML Tres publicaciones secundarias sobre ADNETCONF From 8.2 (Publications) As a result of this Ph.D work a total of twenty four publications have been produced, three main and twenty one secondary ones. It is worth mentioning that two of them are JCR publications and one is a patent request. In the time being, one more publication to a JCR magazine is under review and the patent request is in the last steps 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 architecture to achieve scenario description technological independence, the Testbed Independent Model and the TIM-to-TSM design methodology. Secondary publications are related with the VNUML and ADNETCONF scenario-based tools that are used for the experimental validation. Actually, the work on these tools and the definition of the respective scenario definition languages have provided us with an understanding of the scenario technological dependency problem. The experience and ideas with these lines have been very valuable in the development of our main Ph.D contributions.

60 Gracias por su atención

61 Materiales Adicionales

62 Arquitectura de ADRENALINE
OCC1 (optical) Dispositivos cliente (broadband tester) Herramienta de configuración de gestión (ADNETCONF) … Switch#1 OCC2 (optical) … Switch#5 Switch#6 Switch#7 Switch#12 OCC0 (emul) Switch#4 Switch#2 OCC4 (optical) OCC1 (emul) … … OCC3 (optical) 78 OCCs VLANs ADNETCONF 6 procesos del plano GMPLS en cada XML Switch#3 [MPM+05] OCC73 (emul) OCCs Emulados (74)

63 Arquitectura de PlanetLab
slivers (astilla,loncha) slices (rodaja) Usuario de PlanetLab VMM VMM No privilegiada MV No privilegiada MV Privilegiada MV Privilegiada MV XML-RPC Manager Node Internet MVs Proper Proper VMM VMM VMM (Virtual Machine Monitor) PLC = Database (sites, nodes, users, management informatation) PLC management API (XML-RPC) MV privilegiada -> servicios de infraestructura Creación de slices (directa o delegada) Intermediación y descubrimientos de recursos Mantenimiento de entornos Monitorización Auditoria MV no provilegiada -> experimentos de usuario -> escenarios (con VINI o VIOLIN) (PoC) PlanetLab Central PLC [PACR03][BBC+04]

64 Creación de Slices en PlanetLab
petición de ticket PLC PLC XML-RPC XML-RPC pl_conf XML-RPC NM nueva MV pl_conf /otro XML-RPC NM nueva MV VMM VMM Directo Delegado

65 Otros Testbeds Globalmente Distribuidos
GX-Bone [TWP+05] Lenguaje basado en XML para especificar recubrimientos (overlays), equivalentes a escenarios Testbeds de la Internet del Futuro (Future Internet) GENI [GEN08c], FEDERICA [FED09a], PII [PII09], PASITO [PAS09] Características básicas (influencias del PlanetLab) Federación con red de interconexión dedicada Heterogeneidad de recursos (no solo PCs comodity) Infraestructuras particionables (sliceable) multi usuario Sus sistemas de gestión de configuración están aún bajo definición Programas de subvenciones: FIND (USA) -> GENI FIRE (EC) (dentro del 7PM)-> FEDERICA, PII GENI Spiral 1 40 Gbps links en NLR/Internet2 5 Entornos de Gestión compitiendo basados en preexistentes FEDERICA 1Gbps links en GEANT2 Centrados en la creación de slices, pero aún no han abordado la creación de escenarios (citan PL-VINI)

66 Arquitectura y Gestión de GENI
Investigador Administración y operacion de GENI Repositorio (clearinghouse) Herramientas de experimentación locales Estructura de Control (Control Framework) Usuarios finales Substrato de GENI Servicio de Soporte a experimento Manager Agregado A Manager Agregado N … Experiment plane Measurements plane Control plane O&M plane slice componente particionable

67 Arquitectura de PASITO
CESGA, UVIGO EHU ? UPC, I2CAT, CESCA UPV UAM Equipo de red RedIRIS PASITO Switch (VLANs) UMU UPM UC3M Servidores de virtualización (Xen, VMware ESX) PASITO NODE

68 eXtensible Markup Language
<vnuml> <vm name="uml1"> <if id="1" net="net0"> <ipv4> </ipv4> </if> <if id="2" net="net1"> <ipv4> </ipv4> </vm> </vnuml> vnuml document root vm if if name uml1 ipv4 ipv4 id 2 net net1 id 1 net net0

69 Ejemplo de los Estándares de Modelado de OMG
Classifier InstanceSpecification M2: Metamodelo Class instancia de instancia de City <<snapshot>> :Madrid M1: Modelo UML representa representa M0: Sistema (la ciudad real de Madrid) (el concepto general de ciudad)

70 Transformación Encadenada en MDA
PIM PSM T = {T1, T2, T3} PIM T1 PSM1 T2 PSM2 T3 PSM

71 Estructura del Lenguaje QVT
Imperativo Declarativo Imperativo Operational Mappings (QVTo) extiende Relations (QVTr) extiende Black Box Relations-to-Core Transformation extiende Core (QVTo) extiende

72 CIM Schema + instancias (ficheros MOF)
Arquitectura WBEM Cliente CIM HTTP/XML (CIM-XML) WS-Man (WS-CIM) Telnet/SSH (SM-CLP) Repositorio CIM (CIM Schema + instancias) Servidor WBEM CIMOM Provider A Provider B Provider C Compilador MOF Managed device A Managed device B Managed device C CIM Schema + instancias (ficheros MOF)

73 CIM Schema y Perfiles DMTF
Subconjunto CIM Schema nivel de requisitos restricciones Perfil DMTF Dominio de gestión 1 + = Autónomo 1 Componente A Core Componente B clase de alcance Componente C Autónomo 2 clase central Dominio de gestión 2

74 Otros Lenguajes y Modelos para Información de Gestión
Alternativas a CIM SMIv2/SMIng [MPS99][SS04a], MIF [DMT03c] Basados en tablas (excepto SMIng) Centrados en dispositivo, difícil capturar relaciones ITU GDMO [ITU92] Complejo Muy orientado al dominio telco, el nivel IP no es tenido en cuenta CIM los supera en términos de expresividad, riqueza, flexibilidad, apertura y simplicidad TMF SID [TMF08b] Conceptos de negocio, no necesarios para gestión Acceso restringido, solo a compañías del TMF

75 Roles y Flujos Desarrollo de transformación TIM-a-TSM Flujo de
Desarrollador de transformaciones Flujo de generación de escenario TIM Flujo de generación de escenario TSM Flujo de despliegue de escenario El “flujo” de desarrollo de la transformación TIM-a-TSM es ortogonal al flujo de escenarios (se hace una única vez en tiempo de creación del testbed). Diseñador de escenarios Administrador de testbed

76 Estructura Básica del TIM CIM Schema para Core y OSPF Module
Clases (5): TIM_TestbedScenario TIM_LinkConnectivityCollection TIM_TransmissionCharacteristics TIM_StaticIPv6AssignmentSettingData TIM_NextHopAddressedIPRoute Asociaciones (4): TIM_LinkTransmissionElement TIM_MemberOfLink TIM_LinkOrigin TIM_LinkDestination Clases (1): ComputerSystem TIM Core System Network Core TIM OSPF Module Clases (1): Service Asociaciones (6): SystemComponent HostedCollection HostedAccessPoint HostedRoute ElementSettingData HostedService Clases (4): OSPFService OSPFArea OSPFAreaConfiguration RangeOfIPAddresses Asociaciones (3): OSPFServiceConfiguration AreaOfConfiguration RangesOfConfiguration Clases (3): IPProtocolEndPoint StaticIPAssignmentSettingData ForwardingService Asociaciones (1): ForwardsAmong

77 Modelo Independiente de Testbed (TIM) Conceptos Topológicos Básicos
Escenario Nodo Enlace Interfaces

78 Modelo Independiente de Testbed (TIM) Direccionamiento
Direcciones IPv4 y IPv6 Asociadas a interfaces

79 Modelo Independiente de Testbed (TIM) Forwarding y Routing
Rutas estáticas Asociadas a nodos

80 Transformación TIM a TSM: Resumen del Proceso
Core Core Core Core Mod N TSM (paso 1) Model2Model (paso 4) Escenario (texto XML) XML Doc. Model2Text (directa) Escenario Model2Model (pasos 2 y 3) Escenario Model2Text (paso 4) Escenario (texto) Herramienta de gestión basadas en escenarios Parámetros de testbed (paso 2) Transformación TIM-a-TSM

81 Validación Validación a Nivel de MOF
Basado en WBEM (CIMOM y mofcomp) Garantiza el alineamiento la extensión ad hoc del TIM con el CIM Schema de la DMTF Garantiza la corrección de los escenarios TIM (flujo de generación de escenarios TIM) CIMOM mofcomp CIM-XML cim_schema_ mof tim.mof 1 CIM Schema TIM ad hoc Extension Model basic nsfnet redIris 2 basic.mof rediris.mof nsfnet.mof

82 Otras Aplicaciones (Completa)
Testbeds de la Internet del Futuro (Future Internet) Partición (splitting) del escenario objetivo entre varios testbeds federados debido a su tamaño o necesidad de recursos heterogéneos Partición + despliegue = TIM-a-TIM + TIM-a-TSM Evita proceso manual (costosos en tiempo y propensos a errores) en el particionado y la sincronización de sub-escenarios Puede necesitar especialización de las clases del TIM, pe. routers inalámbricos, enlaces ópticos Testbed basado en WBEM Método añadidos a TIM_TestbedScenario, pe. Deploy() Transformación TIM-a-TSM  WBEM provider Entornos de producción Entornos producción basados en escenarios, pe. TIM-a-OVF Red de producción gestionada por WBEM Como evolución del caso de testbed basado en WBEMs Simulación, pe. TIM-a-ns2

83 Testbed Federado de la Internet del Futuro Grandes Escenarios
Conocimiento de testbed Particionado de escenario Red gran tamaño (3000 nodes) Parte 1 (1000 nodos) Parte 2 (1000 nodos) Parte 3 (1000 nodos) TIM Transformación TIM a TSM1 Herramienta basada en escenarios 1 TSM1 TIM Transformación TIM a TSM2 Herramienta basada en escenarios 2 TSM2 TIM Transformación TIM a TSM3 Herramienta basada en escenarios 3 TSM3 TIM Modelo de Interconexión de Sub-escenarios Configurador de red Evita proceso manual (costosos en tiempo y propensos a errores) en el particionado y la sincronización de sub-escenarios Testbed 1 Testbed 2 Testbed 3 Red de federación (pe. backbone dedicado)

84 Testbed Federado de la Internet del Futuro Recursos Heterogéneos
Conocimiento de testbed Particionado de escenario TIM TIM TIM TIM TIM Transformación TIM a TSM1 Herramienta basada en escenarios 1 TSM1 (especializando las clases del TIM) Transformación TIM a TSM2 Herramienta basada en escenarios 2 TSM2 Transformación TIM a TSM3 Herramienta basada en escenarios 3 TSM3 Modelo de Interconexión de Sub-escenarios Configurador de red Evita proceso manual (costosos en tiempo y propensos a errores) en el particionado y la sincronización de sub-escenarios Red de federación (pe. backbone dedicado)

85 TIM_TestbedScenario)
Testbed Basado en WBEM Cliente CIM Servidor WBEM CIMOM CIM Schema Modelo de Extension ad hoc del TIM Provider de Gestión de Escenarios (métodos de TIM_TestbedScenario) Proveedor elemento de Testbed Testbed redIris

86 Entornos de Producción
Entornos de producción basados en escenario Pe. TIM-a-OVF Red de producción basada en WBEM Como evolución del caso de testbed basado en WBEM Escenarios TIM Cliente CIM CIMOM CIMOM Provider de Gestión de Escenarios Provider de Gestión de Escenarios Providers Provider modelo de los dispositivos del testbed Testbed modelo de los dispositivos de la red de producción Red de producción

87 Resumen de Beneficios Reutilización de especificaciones de escenario entre testbeds Modelo común (TIM) para particionado de escenarios (testbeds federados de la Internet del Futuro) Permitir gestión basada en escenarios en WBEM (basada en el TIM) Herramientas orientadas al TIM, pe. editores, validadores, repositorios Escenarios de red de referencia compartidos Separación de roles (diseñadores de escenarios y administradores de testbeds)

88 Principales Publicaciones
Fermín Galán, Jorge E. López de Vergara, David Fernández and Ramon Casellas, “Using the Model Driven Architecture for Technology-Independent Scenario Configuration in Networking Testbeds”, submitted to IEEE Communications Magazine special issue on Network and Services Management, 2010, under review (JCR). Fermín Galán, Jorge E. López de Vergara, David Fernández and Raül Muñoz, “Scenario-based Configuration Management for Flexible Experimentation Infrastructures”, Proc. of the 5th IEEE Int'l Conf. on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom 2009), Washington DC (USA), April 2009. Fermín Galán, David Fernández, Walter Fuertes and Miguel Gómez, Jorge López de Vergara, “Scenario-based Virtual Network Infrastructure Management in Research and Educational Testbeds with VNUML: Application Cases and Current Challenges”, in Annals of Telecommunications, special issue on Virtualization: a path for the Future Internet, vol. 64(5), pp , May (JCR). Fermín Galán, Raül Muñoz, “Method For Logical Deployment, Undeployment and Monitoring of a Target IP Network”, request (PCT/EP2006/009960) October 2006, WIPO Publication with ISR (WO2008/046429) April (Patent). From (Main Publications): Our first description of the general methodology and architecture addressed in this proposal was introduced in M3. That brief paper states the problems currently existing in configuration management for flexible experimentation infrastructures and provides a preliminary version of TIM. It is extended and enhanced in M2 with more details on the application to actual testbeds (VNUML-based and ADRENALINE). Finally, M1 is our most complete work so far, including all the Ph.D contributions and describing in detail their experimental validation.

89 Lista Completa de Publicaciones Principales
Fermín Galán, Jorge E. López de Vergara, David Fernández and Ramon Casellas, “Using the Model Driven Architecture for Technology-Independent Scenario Configuration in Networking Testbeds”, submitted to IEEE Communications Magazine special issue on Network and Services Management, 2010, under review (JCR). Fermín Galán, Jorge E. López de Vergara, David Fernández and Raül Muñoz, “Scenario-based Configuration Management for Flexible Experimentation Infrastructures”, Proc. of the 5th IEEE Int'l Conf. on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom 2009), Washington DC (USA), April 2009. Fermín Galán, Jorge E. López de Vergara, David Fernández and Raül Muñoz, “A Model-driven Configuration Management Methodology for Testbed Infrastructures}, Proc. of the 11th IEEE/IFIP Int'l Conf. on Network Operations and Management Symposium (NOMS 08), Salvador da Bahia (Brazil), pp , April 2008. From (Main Publications): Our first description of the general methodology and architecture addressed in this proposal was introduced in M3. That brief paper states the problems currently existing in configuration management for flexible experimentation infrastructures and provides a preliminary version of TIM. It is extended and enhanced in M2 with more details on the application to actual testbeds (VNUML-based and ADRENALINE). Finally, M1 is our most complete work so far, including all the Ph.D contributions and describing in detail their experimental validation.

90 Lista Completa de Publicaciones VNUML (1)
Fermín Galán, David Fernández, Walter Fuertes and Miguel Gómez, Jorge López de Vergara, “Scenario-based Virtual Network Infrastructure Management in Research and Educational Testbeds with VNUML: Application Cases and Current Challenges”, in Annals of Telecommunications, special issue on Virtualization: a path for the Future Internet, vol. 64(5), pp , May (JCR). Fermín Galán, David Fernández, Jorge E. López de Vergara and Francisco Monserrat, “Demo of EDIV: Building and managing distributed virtualization scenarios in federated testbed infrastructures”, Proc. of the 5th IEEE Int'l Conf. on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom 2009), Washington DC (USA), April 2009. Fermín Galán, David Fernández, Miguel Ferrer and Francisco J. Martín, “Scenario-based Distributed Virtualization Management Architecture for Multi-host Environments”, Proc. of the 2nd DMTF System and Virtualization Management Workshop (SVM 2008), CCIS 18, pp , Munich (Germany), October 2008. From (VNUML Publications): The most relevant publication in this category is V1, which provides a description of the tool and its most relevant use cases along its history. The tool description is also addressed in V9 and V17. 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 described in V3, V5 and V8, and the EDIV PASITO experiments in V2.

91 Lista Completa de Publicaciones VNUML (2)
Francisco Rúiz, David Fernández, Fermín Galán and Luis Bellido, “Modelo de Laboratorio Docente de Telemática basado en Virtualización Distribuida”, VII Jornadas de Ingeniería Telemática (JITEL 2008), Alcalá de Henares (Spain), September 2008. Walter Fuertes, Jorge E. López de Vergara, Fermín Galán and David Fernández, “Propuesta para el Despliegue de Escenarios de Red Virtuales en Entornos Distribuidos”, VII Jornadas de Ingeniería Telemática (JITEL 2008), Alcalá de Henares (Spain), September 2008. David Fernández, Fermín Galán, Francisco J. Ruiz, Luis Bellido and Omar Walid, “Uso de técnicas de virtualización en laboratorios docentes de redes”, Boletín de RedIRIS, vol , pp , April 2008. Miguel Gómez, Fermín Galán and Emilio J. Torres, “A 3GPP System Architecture Evolution Virtualized Experimentation Infrastructure for Mobility Prototyping (Invited Paper)”, Proc. of the 4th Int'l Conf. on Testbeds and Research Infrastructures for the Development of Networks Communities (TridentCom 2008), Innsbruck (Austria), March 2008. From (VNUML Publications): The most relevant publication in this category is V1, which provides a description of the tool and its most relevant use cases along its history. The tool description is also addressed in V9 and V17. 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 described in V3, V5 and V8, and the EDIV PASITO experiments in V2.

92 Lista Completa de Publicaciones VNUML (3)
Fermín Galán and David Fernández, “Distributed Virtualization Scenarios Using VNUML”, Proc. of the 1th DMTF System and Virtualization Management Workshop (SVM 2008), Toulouse (France), October 2007. Fermín Galán and David Fernández, “Experiencias de uso de la herramienta VNUML en la creación de escenarios de red virtuales”, invited speech at Grupos de Trabajo RedIRIS 2007 RTIRIS-23, ETSIT UPM, Madrid (Spain), June 2007. Fermín Galán, Raül Muñoz and Ricardo Martínez, “Control plane virtual extension for GMPLS-based optical networking testbeds”, VI Workshop in MPLS/GMPLS networks, Girona (Spain), April 2007. Fermín Galán, Raül Muñoz and Ricardo Martínez, “Uso de técnicas de virtualización para la experimentación en redes ópticas basadas en GMPLS y DWDM”, XVI Jornadas Telecom I+D, Madrid (Spain), November 2006. Fermín Galán and David Fernández, “Use of VNUML in Virtual Honeynets Deployment”, IX Reunión Española sobre Criptología y Seguridad de la Información (RECSI), Barcelona (Spain), September 2006. From (VNUML Publications): The most relevant publication in this category is V1, which provides a description of the tool and its most relevant use cases along its history. The tool description is also addressed in V9 and V17. 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 described in V3, V5 and V8, and the EDIV PASITO experiments in V2.

93 Lista Completa de Publicaciones VNUML (4)
Fermín Galán, Emilio García, Carlos Chávarri, Miguel Gómez and David Fernández, “Design and Implementation of an IP Multimedia Subsystem (IMS) Emulator Using Virtualization Techniques”, Proc. of the 13th HP OpenView University Association (HP-OVUA) Workshop, pp , Nice (France), May 2006. David Fernández, F. Javier Ruiz Piñar, Fermín Galán, Vicente Burillo and Tomás de Miguel, “Mejorando el aprendizaje en los laboratorios de redes y servicios mediante el uso de herramientas de virtualización”, Primeras Jornadas de Innovación Educativa ETSIT-UPM, Madrid (Spain), December 2005. David Fernández, F. Javier Ruiz Piñar, Fermín Galán, Vicente Burillo and Tomás de Miguel, “Uso de técnicas de virtualización para mejorar la docencia en laboratorios de redes de comunicaciones”, V Jornadas de Ingeniería Telemática (JITEL 2005), Vigo (Spain), September 2005. From (VNUML Publications): The most relevant publication in this category is V1, which provides a description of the tool and its most relevant use cases along its history. The tool description is also addressed in V9 and V17. 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 described in V3, V5 and V8, and the EDIV PASITO experiments in V2.

94 Lista Completa de Publicaciones VNUML (y 5)
Fermín Galán, David Fernández, Javier Rúiz, Omar Walid and Tomás de Miguel, “A Virtualization Tool in Computer Network Laboratories”, Proc. of the 5th Int'l Conf. on Information Technology Based Higher Education and Training (ITHET'04), Istanbul (Turkey), May 2004. Fermín Galán and David Fernández, “VNUML: Una herramienta de virtualización de redes basada en Software Libre”, Open Software World Conference (OSWC’04), Málaga (Spain), February 2004. David Fernández, Fermín Galán and Tomás de Miguel, “Study and Emulation of IPv6 Internet Exchange (IX) based Addressing Models”, in IEEE Communications Magazine, vol. 42(1), pp , January (JCR). From (VNUML Publications): The most relevant publication in this category is V1, which provides a description of the tool and its most relevant use cases along its history. The tool description is also addressed in V9 and V17. 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 described in V3, V5 and V8, and the EDIV PASITO experiments in V2.

95 Lista Completa de Publicaciones ADNETCONF
Fermín Galán, Raül Muñoz, “Method For Logical Deployment, Undeployment and Monitoring of a Target IP Network”, request (PCT/EP2006/009960) October 2006, WIPO Publication with ISR (WO2008/046429) April (Patent). Fermín Galán and Raül Muñoz, “An Automatic Model-based Reconfiguration and Monitoring 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 , Springer, May 2007. Fermín Galán, Raül Muñoz and Ricardo Martínez, “Demo of ADNETCONF: ADRENALINE'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 Development of Networks & Communities (TridentCom 2006), Barcelona (Spain), March 2006. From 8.2.3: The patent request in A1 discloses a model-based method for deployment, undeployment and monitoring of IP logical networks on top existing physical networking infrastructures. Thus, the patent request can be applied to the experimentation infrastructures field, being a scenario-based configuration management methodology for three particular operations (deployment, undeployment and monitoring) for a particular kind of testbeds (distributed and IP-based). An early description of ADNETCONF is provided in A3, then evolved in A2, which can be considered the application of the general method described in the patent request A1 to the particular case of ADRENALINE testbed.