Discovery and Signaling Enhancements for Data-Centric Publish-Subscribe Environments

Size: px
Start display at page:

Download "Discovery and Signaling Enhancements for Data-Centric Publish-Subscribe Environments"

Transcription

1 Official Graduate Program in Multimedia Systems Signal Theory, Telematics and Communications Department University of Granada Ph.D. Thesis Dissertation: Discovery and Signaling Enhancements for Data-Centric Publish-Subscribe Environments Written by: Jose Maria Lopez-Vega Supervised by: PhD. Juan Manuel Lopez-Soler PhD. Gerardo Pardo-Castellote

2 Editor: Editorial de la Universidad de Granada Autor: José María López Vega D.L.: GR ISBN:

3

4 Programa Oficial de Posgrado en Sistemas Multimedia Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada TESIS DOCTORAL Mejoras de Descubrimiento y Señalización para Entornos Publicación-Suscripción Centrada en Datos Realizada por: José María López Vega Dirigida por: Dr. Juan Manuel López Soler Dr. Gerardo Pardo Castellote

5

6 El doctorando D. José María López Vega y los directores de la tesis D. Juan Manuel López Soler, Profesor Titular de Universidad del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, y D. Gerardo Pardo Castellote, CTO. de Real-Time Innovations Inc. GARANTIZAMOS AL FIRMAR ESTA TESIS DOCTORAL que el trabajo ha sido realizado por el doctorando bajo la dirección de los directores de la tesis y hasta donde nuestro conocimiento alcanza, en la realización del trabajo se han respetado los derechos de otros autores a ser citados, cuando se han utilizado sus resultados o publicaciones. Granada, a 08 de abril de 2013 Directores de la Tesis D. Juan Manuel López Soler D. Gerardo Pardo Castellote Doctorando D. José María López Vega

7

8 Agradecimientos En primer lugar, querría agradecer a mis directores, Juanma y Gerardo, por su labor de supervisión de este trabajo, así como por su continuo apoyo. En especial, agradecerle a Juanma que durante estos 6 años no sólo ha sido un director, sino un compañero de trabajo y amigo. En segundo lugar, a mi grupo de investigación, Wireless and Multimedia Networking Lab (WMNL), cuyos miembros han sido compañeros de batallas en pos de la concesión de proyecto definitiva. En especial, agradecerles a Pove y Juanjo el buen humor con el que se enfrentan a deadlines y cruasanes. Asimismo quiero agradecer al Departamento de Teoría de la Señal, Telemática, y Comunicaciones por haberme acogido como un miembro más y por haberme ayudado en todo lo que he necesitado. Estoy muy agradecido a todos aquellos que han contribuido a este trabajo con sus ideas y sugerencias. En especial, a Javier Sanchez-Monedero por sus estupendas figuras de SDP y a Luca Foschini por sus valiosos comentarios, que han contribuido a hacer de éste un mejor documento. No me puedo olvidar de mis compañeros la comunidad del becario, que se adaptan igual de bien a unas mazmorras sin ventanas que al frío de más allá del Mur... digo, orquídea. Y es que cuatro años de becario dan para mucho: tres mudanzas de despacho, algún pequeño incendio, dos o tres reformas, etc.. Por todo este tiempo juntos, muchas gracias a mis compis de despacho (Alberto, Didi, Lluvia, Rita, Rosa, Santi), de despacho anexo (Joaquín, Leopomodoro-breaker, Miriam, Plata, Roberto), de mazmorras (Fran, Juanra, Víctor), de máster (Miguel y Pablo), de almuerzo (Ruben) y bitstamineros (Fergu y Javi). Y muchas, muchas, muchas gracias adelantadas Carlos y Rafa por todos los ensayos de la defensa de esta Tesis a los que vais a asistir. A toda la gente que me ayudó en mi periplo por las dos estancias. Agradecer a RTI, y en especial a Álex, Fernando y Gerardo, su confianza y apoyo durante mi estancia en EE.UU.. A Gonzalo, por brindarme la oportunidad de la estancia en Finlandia, que fue una experiencia increíble. Y no puedo olvidarme de Jaime y Ella, que fueron un apoyo constante y son unos verdaderos amigos. A mis amigos del mundo exterior (a la investigación), que me han ayudado a llevar este retorno del deadline adelante: unos, con su paciencia infinita (Dewidh), otros, con un poco de cultura oriental (Bea, pinxaja, anubis, Juanma), y otros, con un toque musical (Goriwiiii & Master Baena). Como no, agradecer a mi familia su apoyo continuo, si hoy puedo escribir estas líneas es gracias a ellos. Y por último, pero no menos importante, a Adela, por ser mi compañera en este viaje que es la vida. GRACIAS A TODOS!

9 ii Este trabajo ha sido parcialmente financiado por el programa Formación de Profesorado Universitario 2008 del Ministerio de Educación.

10 Abstract Current uses of the Internet are mostly built on request-response exchanges between pairs of computers. This model has been very successful at providing shared remote access to resources and point-to-point communications for applications including , remote file and database access, web access, etc. The advent of ubiquitous Internet connectivity and cheap network-connected devices has greatly expanded the communication needs of applications using the Internet. For these new kinds of applications the request-response communications model, which is highly coupled to the location of the information, is cumbersome and limited whereas other communication models, such as publish-subscribe, provide a more natural fit. In contrast to the request-response interaction model, in which a client sends a request and a server returns a response, in the publish-subscribe model information producers (publishers) are decoupled from information consumers (subscribers) via the publish-subscribe service. One of these services is Data Distribution Service (DDS), an standardized solution for data-centric publish-subscribe data distribution. This Thesis describes the design and evaluation of a set of discovery and signaling enhancements for Data-Centric Publish-Subscribe (DCPS) systems. In particular, this Thesis focus on solving the following open issues of DDS: data-spaces interconnection, data transformation, Quality of Service (QoS) adaptation, universal DCPS entity and data-content naming, end-to-end session establishment, and discovery scalability in large deployments. We have divided our solution in three parts. First, we propose the DDS data-space Interconnection Service (DDS-IS), a fully DDS-compliant service for DDS data-spaces interconnection which also provides transparent data transformation and QoS adaptation. We demonstrate that the DDS-IS can improve the scalability of DDS systems by reducing the network traffic load between the interconnected data-spaces. Secondly, we define a mechanism for universal identification of DCPS entities and data-content, and we propose the rationale and design of a protocol for session signaling in DCPS environments. This protocol allows applications to perform DCPS entity and data-content discovery in medium-scale environments. It also allows the creation of sessions between nodes, which eases the creation of DCPS routes and enables the enforcement of QoS at end-to-end level. Finally, we propose a scalable Peer-to-Peer (P2P) solution for performing content discovery and data transfer. This solution is based on the REsource LOcation And Discovery (RELOAD) framework, one of the latest standards of the Internet Engineering Task Force (IETF). This solution provides rendezvous function for locating sensors, actuators, and applications that share a common data-space or topic

11 ii of interest using a DCPS approach. Once the rendezvous is complete, nodes use existing RELOAD features for exchanging information. We demonstrate the proposed solution scales well for large deployments and it is robust against node failures.

12 Resumen En la actualidad, las aplicaciones distribuidas en Internet interaccionan e intercambian información usando mayoritariamente relaciones del tipo solicitud-respuesta. Este modelo de interacción ha demostrado ser adecuado para comunicaciones punto a punto y más concretamente, para aplicaciones tales como el correo electrónico, la descarga de archivos, el acceso a bases de datos y los servicios web, entre otras. Sin embargo, la proliferación de múltiples dispositivos dotados de conectividad permanente a Internet y la aparición de nuevas aplicaciones, con diferentes necesidades, han motivado la consideración de otros modelos de interacción, ya que no siempre el modelo solicitud-respuesta tiene que ser el más adecuado. En este sentido, más recientemente han surgido otros modelos de interacción alternativos, como el de publicación-suscripción. A diferencia del modelo solicitud-respuesta, en el que un cliente envía una solicitud, y un servidor devuelve una respuesta, en el modelo publicación-suscripción los productores de información (publicadores) están desacoplados de los consumidores de información (suscriptores) mediante un servicio publicación-suscripción. Uno de estos servicios es Data Distribution Service (DDS), una solución estandarizada para la distribución de datos mediante un paradigma publicación-suscrición centrada en datos. Esta Tesis describe el diseño y evaluación de un conjunto de mejoras de descubrimiento y señalización para sistemas Data-Centric Publish-Subscribe (DCPS). En concreto, esta Tesis se centra en resolver los siguientes problemas de DDS: interconexión de dominios, transformación de datos, adaptación de Quality of Service (QoS), identificación universal de contenidos y entidades DCPS, establecimiento de sesión extremo a extremo y escalabilidad del descubrimiento en sistemas de gran escala. Nuestra solución ha sido dividida en tres partes. En primer lugar, se propone el DDS data-space Interconnection Service (DDS-IS), un servicio para la interconexión de dominios DDS que soporta la transformación transparente de datos y la adaptación de QoS, todo ello manteniendo la compatibilidad con el estándar. Además, se demuestra experimentalmente que el DDS-IS puede mejorar la escalabilidad de los sistemas DDS mediante la reducción del tráfico de red existente entre los dominios interconectados. En segundo lugar, se define un mecanismo para la identificación universal de contenidos y entidades DCPS, y se propone el diseño y lógica subyacente de un protocolo para la señalización de sesión en entornos DCPS. Este protocolo permite a las aplicaciones descubrir contenidos y entidades DCPS en entornos de escala media. Además, permite la creación de sesiones entre nodos, lo que facilita la creación de rutas DCPS y permite la provisión de QoS extremo a extremo. Por último, se propone una solución Peer-to-Peer (P2P) escalable para el descu-

13 ii brimiento de contenidos y la transferencia de información. Esta solución se basa en el framework REsource LOcation And Discovery (RELOAD), uno de los últimos estándares de la Internet Engineering Task Force (IETF). La solución propuesta proporciona la función de rendezvous para localizar mediante una aproximación DCPS sensores, actuadores y aplicaciones que comparten un espacio de datos común o un tópico de interés. Una vez se completa el rendezvous, los nodos utilizan la funcionalidad de RELOAD para intercambiar información. Por último, se demuestra experimentalmente que la solución propuesta es escalable y robusta.

14 Contents 1 Introducción Motivación Interconexión de dominios Señalización Objetivos Resumen de la solución propuesta Estado del arte y trabajo relacionado Modelo de interacción publicación-suscripción Escalabilidad de los sistemas publicación-suscripción Descubrimiento de recursos y RELOAD DDS y SIP Contribuciones principales Trabajos publicados Estructura del documento Introduction Motivation Domain interconnection Signaling

15 ii Contents 1.2 Goals Solution overview State of the art and related work Publish-subscribe interaction model Scalability in publish-subscribe systems Resource discovery and RELOAD DDS and SIP Main contributions Published works Document structure Background Publish-subscribe interaction model Data Distribution Service (DDS) Data Centric Publish Subscribe layer (DCPS) Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) SDP Bloom Extensible Topic Types Session Initiation Protocol (SIP) Overview of SIP functionality Basic concepts of SIP User location Session setup and management REsource LOcation And Discovery (RELOAD) Main features Architecture and types of nodes Operations

16 Contents iii Data storage Usages Constrained Application Protocol (CoAP) DDS data-space Interconnection Service (DDS-IS) Motivation Motivating use case example Requirements Internal architecture Application layer Routing layer Pub/Sub and network layers System operation Discovery of new DDS entities Data bridging Implementation Dynamic types DDS middleware implementation DDS signaling propagation Propagating DataWriter information Quality of Service XML configuration format Validation and performance evaluation Experimental set-up DDS-IS Impact in N to N communications Performance impact in simple 1 to 1 communications Performance impact of data transformation and filtering features

17 iv Contents Performance impact in N to N communications with multiple topics DDS-IS impact in M to N communications DDS-IS performance impact DDS-IS scalability impact Impact on DDS QoS policies Conclusions Data-Centric SIP (DCSIP) Motivation Motivating use case example New required features Limitations of DDS and DDS-IS Solution requirements Design decisions Information management Signaling Routing DCSIP fundamentals Realm Scope, scope-label, and scope-path Full Qualified Data-space and Topic Names DCPS Entity Group and DCPS Entity Name DCPS session Resource naming format Node roles DCSIP messages Joining and registration

18 Contents v Resource location Session establishment and maintenance DCSIP operation Joining and registration Resource location and session establishment SIP and DCSIP comparison DDS and DCSIP features comparison Conclusions DDS usage for RELOAD Motivation Motivating use case examples User data-space N permanent stock-shares publishers, M variable stock-shares subscribers N variable temperature sensors, 1 permanent temperature monitor N variable planes (entering and leaving the airspace), M variable air traffic controllers New required features System design A DCPS approach A RELOAD based architecture Discovery-and-Data node roles DCPS Entity Groups RELOAD Kinds for DCPS TopicPublisher and TopicSubscriber Registrations DataSpaceParticipant Registration Resource naming format

19 vi Contents 5.5 System operation Joining the overlay Registering entities Registering a new publisher using TopicPublisher Registering a new subscriber using TopicSubscriber Registering a new data-participant using DataSpaceParticipant Entity Discovery Publisher discovery Subscriber discovery Data-participant discovery Data transfer Data transfer using CoAP Data transfer using DDS-RTPS Prototype and experimental setup Experimental setup Experimental results Conclusions Related Work System federation and domain bridging in DDS DDS and SIP RELOAD and publish-subscribe scalability CoAP usage for RELOAD Named Data Networking (NDN) Conclusions Conclusions and future work 161

20 Contents vii 7.1 Conclusions Future work Conclusiones y trabajo futuro Conclusiones Trabajo futuro Bibliography 173

21

22 List of Figures 2.1 Request-response and publish-subscribe interaction models DDS concepts and entities DCPS built-in entities for discovery purposes SDP sequence diagram SDP-Bloom sequence diagram SIP registration and invitation example SIP invitation dialog Trivial example of RELOAD overlay Example of data stored in RELOAD Example deployment scenario Layered DDS-IS architecture DDS-IS Routing Engine Discovery sequence diagram Data bridging sequence diagram XML configuration file example DDS-IS scenario for 1 to 1 performance experiments. In the N to N case, lab01 and lab03 run multiple publishers and subscribers DDS-IS impact for different data types in 1 to 1 communications

23 x List of Figures 3.9 DDS-IS performance for filtering and transforming data Average latency for different payloads and number of routes (topics) active Total average throughput for different payloads and number of routes (topics) active CPU impact for different payloads and number of routes (topics) active System topology used in 1 to N performance experiments Average latency for different payloads when demultiplexing data from 1 to N Throughput per subscriber for different payloads when demultiplexing data from 1 to N System topology used in M to N scalability experiments DDS traffic load on LAN C for both no-dds-is and DDS-IS scenarios Topology of the Health Service use-case DDS-IS are able to integrate incompatible information data-bases Current solutions provoke unnecessary and redundant traffic in the higher levels of the DDS-IS hierarchy Our solution allows for a better usage of the resources Node joining and content registering Session creation diagram Architecture layers Example of overlay prior to any DataRegister Example of overlay after several DataRegister A) Average latency for storing DCPS entities discovery information. B) Average latency for obtaining all the discovery information of a particular DCPS-Entity-Group Average latency for obtaining the discovery information for a particular DCPS-Entity-Group and start exchanging data with a node of that group

24 List of Figures xi 5.6 Percentages of lookup failures per different churn levels

25

26 List of Tables 2.1 Correspondence DDS and DDS-RTPS entities Study of the level impact of DDS-IS on DDS QoS policies Comparison of SIP and DCSIP features Comparison of current DDS and DCSIP features

27

28 List of Abbreviations and Acronyms AMQP Advanced Message Queuing Protocol API Application Programming Interface ATC Air Traffic Controller B-DR Built-in DataReader B-DW Built-in DataWriter CDN Content Distribution Network CoAP Constrained Application Protocol CoRE WG Constrained RESTful Environments working group CPU Central Processing Unit DCPS Data-Centric Publish-Subscribe DCSIP Data-Centric SIP DDS Data Distribution Service DDS-IS DDS data-space Interconnection Service DDS-RTPS Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol DDS-XTypes Extensible And Dynamic Topic Types For DDS DHT Distributed Hash Table DLRL Data Local Reconstruction Layer

29 xvi List of Abbreviations and Acronyms DNS Domain Name System DR DataReader DW DataWriter EDP Endpoint Discovery Protocol ESB Enterprise Service Bus FIR Flight Information Region FQDN Full Qualified Domain Name FQTN Full Qualified Topic Name HTTP HyperText Transfer Protocol IANA Internet Assigned Numbers Authority ICE Interactive Connectivity Establishment ID IDentifier IEC International Electrotechnical Commission IETF Internet Engineering Task Force IoT Internet of Things IP Internet Protocol JMS Java Messaging Service LAN Local Area Network M2M Machine-to-Machine MANET Mobile ad hoc network MMUSIC WG Multiparty MUltimedia SessIon Control working group MOM Message Oriented Middleware NAT Network Address Translation NDN Named Data Networking NTP Network Time Protocol OMG Object Management Group

30 List of Abbreviations and Acronyms xvii P2P Peer-to-Peer P2PSIP WG Peer-to-Peer Session Initiation Protocol working group P2P-SIP Peer-to-Peer Session Initiation Protocol PDP Participant Discovery Protocol PSIRP Publish-Subscribe Internet Routing Paradigm PURSUIT Publish Subscribe Internet Technology QoS Quality of Service RELOAD REsource LOcation And Discovery REVENGE REliable and VErsatile News delivery support for agencies RFC Request For Comments RTI Real Time Innovations Inc. RTP Real-time Transport Protocol RTPS Real-Time Publish-Subscribe SDP Simple Discovery Protocol sdp Session Description Protocol SEDP Simple Endpoint Discovery Protocol SPDP Simple Participant Discovery Protocol SIP Session Initiation Protocol SIP WG Session Initiation Protocol working group SIPCore WG Session Initiation Protocol Core working group SIPPING WG Session Initiation Protocol Project INvestiGation working group SNMP Simple Network Management Protocol SPHS Spanish Public Health Service TCP Transmission Control Protocol TLS Transport Layer Security UA User Agent

31 xviii List of Abbreviations and Acronyms UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Uniform Resource Identifier VLAN Virtual Local Area Network WAN Wide Area Network XML extensible Markup Language

32 Capítulo 1 Introducción En la actualidad, las aplicaciones distribuidas en Internet interaccionan e intercambian información usando mayoritariamente relaciones del tipo solicitud-respuesta. Este modelo de interacción ha demostrado ser adecuado para comunicaciones punto a punto y más concretamente, para aplicaciones tales como el correo electrónico, la descarga de archivos, el acceso a bases de datos y los servicios web, entre otras. La arquitectura de Internet, caracterizada por la sencillez y eficacia de su diseño, se concibió para facilitar la interconexión de redes independientemente de las tecnologías subyacentes y para permitir así el intercambio de información entre las aplicaciones finales, como las anteriormente citadas. Para proporcionar comunicaciones fiables (sin errores), con control de flujo y con mecanismos de control de congestión, se especificó el protocolo de transporte Transmission Control Protocol (TCP), el cual provee estos servicios exclusivamente para comunicaciones punto a punto. TCP adopta una aproximación orientada a conexión (full-duplex) que implica un fuerte acoplamiento temporal y espacial entre el emisor y el receptor de la información. La proliferación de múltiples dispositivos dotados de conectividad permanente a Internet y la aparición de nuevas aplicaciones, con diferentes necesidades, han motivado la consideración de otros modelos de interacción, ya que no siempre el modelo solicitud-respuesta tiene que ser el más adecuado. En este sentido, más recientemente han surgido otros modelos de interacción alternativos, como el de publicación-suscripción [21].

33 2 Capítulo 1. Introducción La naturaleza y el contexto histórico de la cuestión aquí planteada quedan claramente expresados en el trabajo pionero de Van Jacobson et al. [41], que traducido al español dice: Los principios de ingeniería y la arquitectura de Internet tal y como la conocemos hoy fueron creados en los años 60 y 70, cuando la compartición de recursos era el problema que las redes de ordenadores pretendían resolver [...]. El modelo de comunicación que se concibió entonces consistía en una conversación entre dos máquinas, una solicitando un recurso y otra facilitándolo. Consecuentemente, los paquetes IP contienen dos identificadores (direcciones), uno para el equipo origen y otro para el equipo destino, y casi todo el tráfico de Internet consiste en conversaciones (TCP) entre pares de equipos. En los 50 años que han pasado desde la creación de las primeras redes de paquetes, los ordenadores y otros dispositivos relacionados se han abaratado y se han convertido en productos de uso cotidiano. La conectividad que ofrece Internet y el coste reducido del almacenamiento permiten el acceso a una cantidad de contenido asombrosa solo en 2008 se han generado 500 exabytes de información [24]. La gente valora Internet por qué contenido le ofrece, no por dónde se encuentra dicho contenido. Hemos identificado una serie de problemas que afectan a los usuarios y cuyo origen se encuentra en la incompatibilidad entre estos dos modelos: Disponibilidad: El acceso rápido y fiable al contenido requiere mecanismos específicos de aplicación incómodos y preplanificados como pueden ser las redes CDNs y P2P, así como imponer costes de ancho de banda excesivos. Seguridad: Dado que los equipos confían en la información de localización y conexión para identificar los contenidos, es fácil suplantar dichos contenidos. Dependencia espacial: Asociar contenido a la localización de los equipos complica la configuración y la implementación de servicios en red. La forma directa y unificada de resolver estos problemas es reemplazar el dónde con el qué. Las conversaciones equipo a equipo son una abstracción que se ajustaba a los problemas que existían en los años 60. Creemos que para los problemas de comunicación de actuales nombrar los datos es una mejor abstracción que nombrar los equipos. A diferencia del modelo solicitud-respuesta, en el que la entidad denominada cliente envía una solicitud y la entidad denominada servidor le devuelve la respuesta, esta Tesis en este sentido alineada con la visión de Jacobson se centra en el modelo de interacción publicación-suscripción. En este modelo, unas entidades denominadas publicadores generan eventos o actualizan un espacio de datos compartido, mientras que otras, los suscriptores expresan su interés en ciertos patrones de eventos o partes del espacio de datos. Además, un servicio de publicación-suscripción se encarga de entregar la información desde los publicadores a los suscriptores.

34 1.1. Motivación 3 Esta misma visión es igualmente compartida por varios proyectos de investigación recientes encuadrados en la denominada Internet del futuro cuyo objetivo es sustituir al actual modelo de Internet adoptando el paradigma de publicaciónsuscripción. En concreto, por su relevancia son dignos de mención los proyectos Publish-Subscribe Internet Routing Paradigm (PSIRP) [20] [22] y Publish Subscribe Internet Technology (PURSUIT) [82]. 1.1 Motivación En 2004, el Object Management Group (OMG) [73] adoptó Data Distribution Service (DDS) [67], una especificación que estandariza el modelo de comunicación publicación-suscripción centrado en datos (DCPS). Esta especificación define una Interfaz de Programación de Aplicación (API) estandarizada para intercambiar información siguiendo una aproximación DCPS. Bajo este modelo, los publicadores y suscriptores intercambian datos a través de una caché distribuida conocida como espacio de datos (también conocida como dominio DDS). Otra característica significativa de DCPS es que los datos intercambiados no son ajenos al middleware. En este sentido, DDS es capaz de proporcionar funciones avanzadas tales como caching de los datos o filtrado basado en contenido. El estándar DDS está todavía en expansión. En particular, y como prueba de la actividad existente en el estándar, en los últimos dos años el OMG ha publicado cuatro de los seis documentos que conforman la familia de estándares DDS. Una consecuencia de la relativa novedad de DDS es que como se explicará más adelante aún quedan varios problemas por resolver. DDS fue originalmente concebido para su uso en redes de área local (LANs) aisladas, de tal forma que publicadores y suscriptores comparten una infraestructura de red común. Si un suscriptor desea acceder a datos que se originan en un espacio de datos diferente, especialmente si dicho espacio de datos está separado por una red en desventaja, si hay implícito un servicio de traducción de nombres (NAT) o si un cortafuegos está presente, surgen nuevos problemas Interconexión de dominios A modo de escenario de ejemplo sea una empresa que utiliza DDS para la distribución interna de contenidos. Supóngase que esta empresa ofrece ciertos servicios que requieren el acceso parcial a dichos contenidos por parte de otra compañía.

35 4 Capítulo 1. Introducción Una solución simplista al caso de uso anterior consistiría en interconectar los dos espacios de datos (el de la empresa proveedora y el de la empresa consumidora) directamente. Es decir, los administradores de la empresa proveedora podrían implementar un servicio que publique y anuncie todos los tópicos de su espacio de datos al otro. Sin embargo, el hecho de unir los dos espacios de datos sin más, generaría los siguientes problemas no desdeñables. El primer problema estaría relacionado con la escalabilidad, ya que cada publicación disponible en un espacio de datos sería anunciada indiscriminadamente en el otro espacio de datos. Este comportamiento puede malgastar recursos en situaciones donde no haya consumidores de dicha información en el segundo espacio de datos. Otros problemas estarían relacionados con la compatibilidad de datos. Cada espacio podría tener definido su propio (y quizás diferente) modelo de datos (i.e., nombres de datos, tipos, y/o definiciones). Estos modelos podrían ser incompatibles incluso si se refieren a la misma información. Por ejemplo, la temperatura podría estar expresada en grados centígrados en un espacio de datos y en Fahrenheit en el otro. Por tanto, para no tener que cambiar la lógica extremo a extremo de las aplicaciones implicadas, los datos deberían ser transformados automáticamente por la infraestructura publicación-subscripción durante su transmisión entre los dos dominios. Como ventaja adicional, esto facilitaría la integración de aplicaciones DDS nuevas con otras ya existentes. El control de acceso y la confidencialidad de la información añaden otra dimensión al problema: cierta información debería mantenerse como exclusiva de un dominio, mientras que cierta información debería ser pública. Otro problema significativo está relacionado con hacer compatibles los diferentes requerimientos de los distintos flujos de información entre los dominios interconectados. En concreto, los administradores deberían disponer de mecanismos para establecer los requerimientos de calidad de servicio (QoS) que los dominios deben cumplir para ser interconectados. La especificaciones de DDS actuales no abordan todos estos problemas. Consecuentemente, parte de nuestra investigación se centra en el diseño de un servicio que conecte espacios de datos DDS disjuntos (i.e., un servicio de bridging) y que a su vez resuelva los problemas anteriormente descritos Señalización DDS modela el intercambio de información mediante seis entidades diferentes: DomainParticipant, Tópico, Publicador, Suscriptor, DataWriter (DW), y DataReader

36 1.1. Motivación 5 (DR). DomainParticipant representa la conexión entre una aplicación y un espacio de datos compartido. Tópic representa un flujo de información de interés, tiene asociados un nombre de tópico y un tipo de datos. Publicador es el objeto encargado de enviar información. Suscriptor es el objeto encargado de recibir información. DataWriter (DW) es el objeto que utiliza la aplicación para escribir datos en un tópico. Cada DW está vinculado a un tópico concreto (y por tanto, a un tipo de datos) y pertenece a un publicador. DataReader (DR) es el objeto que utiliza la aplicación para recibir datos de un tópico. Cada DR está vinculado a un tópico concreto (y por tanto, a un tipo de datos) y pertenece a un suscriptor. Todas estas entidades DDS tienen QoS asociadas que especifican los aspectos no funcionales del intercambio de información. Antes de intercambiar contenidos, las entidades DDS deben completar el discovery. En DDS, discovery es el procedimiento por el que el servicio de publicaciónsuscripción descubre las entidades que comparten un tópico y que además cumplen una serie de requerimientos de QoS. Una vez que un DW descubre un DR compatible, las aplicaciones asociadas pueden comenzar a intercambiar información. La especificación original de DDS estandarizaba un modelo de programación y una API para desarrollar aplicaciones DCPS. Pese a que DDS definía las entidades necesarias para intercambiar la información de discovery, ésta no especificaba el protocolo de red que las diferentes implementaciones de DDS debían usar para poder interoperar. El OMG abordó este problema con la especificación del protocolo Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) [69]. Para realizar el discovery la especificación DDS-RTPS define el denominado DDS Simple Discovery Protocol (SDP). Este protocolo fue concebido para entornos relativamente pequeños (hasta algunos miles de nodos conectados a través de una LAN). Además, un hecho relevante es que las actuales especificaciones de DDS no definen una metodología de identificación universal de entidades ni de datos.

37 6 Capítulo 1. Introducción Otro problema existente afecta a la escalabilidad. Para llevar a cabo el discovery la mayor parte de las implementaciones de DDS actuales se basan en usar comunicaciones multicast o alternativamente, usan un servidor centralizado. En este sentido, DDS-RTPS no aborda el problema del descubrimiento de entidades o contenidos en escenarios de gran escala, ni tampoco proporciona ningún mecanismo para atravesar NATs (siempre presentes en la interconexión de redes con direccionamiento público y privado). Afortunadamente, la especificación DDS-RTPS permite a las implementaciones de DDS definir sus propios protocolos de discovery, y por tanto es posible definir nuevos protocolos que solucionen los problemas planteados. La introducción de un servicio de bridging entre dos entidades DDS (como el propuesto en esta Tesis) origina nuevos problemas. En concreto, las actuales políticas de QoS de DDS fueron diseñadas para escenarios basados en un único dominio, y quizá no tengan el comportamiento esperado en entornos en los que hay un servicio de bridging presente. Además, las aplicaciones requieren de nuevos mecanismos para negociar qué contenidos se propagan entre los espacios de datos interconectados. En definitiva, la introducción de nodos intermediarios en DDS crea la necesidad de nuevos mecanismos que soporten la negociación de políticas de QoS entre nodos remotos, así como la creación de publicaciones y suscripciones a través de servicios de bridging para DDS. Con objeto de abordar estas cuestiones, esta Tesis define y propone el uso de un protocolo de señalización para DDS. 1.2 Objetivos Para una mayor claridad, los objetivos de esta Tesis se han dividido en dos bloques: interconexión de espacios de datos DDS y señalización de sesión en DDS. Interconexión de espacios de datos DDS: Objetivo: Diseñar un servicio de interconexión de espacios de datos DDS. Objetivo: Incrementar la extensibilidad y flexibilidad de los sistemas DDS, facilitando la evolución de los sistemas basados en dicho estándar. Objetivo: Implementar y evaluar el servicio diseñado. Objetivo: Estudiar el impacto del servicio propuesto sobre las políticas de QoS de DDS. Señalización de sesión en DDS: Objetivo: Diseñar un formato de identificación universal de entidades y contenidos en entornos DCPS.

38 1.3. Resumen de la solución propuesta 7 Objetivo: Diseñar un protocolo para el descubrimiento de entidades DCPS y para el establecimiento de sesiones en DDS. Objetivo: Evaluar la escalabilidad y robustez de la solución propuesta. 1.3 Resumen de la solución propuesta La solución que se propone en esta Tesis consta de tres partes: 1. Servicio de Interconexión de Dominios DDS (DDS-IS): Proponemos una solución para la interconexión de dominios DDS que satisfaga el estándar DDS. Tras la evaluación realizada, se demuestra experimentalmente que la solución propuesta soporta la transformación de datos entre dominios y el filtrado basado en contenido, a la vez que aumenta la escalabilidad de DDS y adapta los requisitos de QoS entre las entidades comunicadas. 2. SIP Centrado en Datos(DCSIP): Proponemos las bases y lógica subyacente de un protocolo para la señalización de sesiones en entornos DCPS. Este protocolo resuelve el descubrimiento de contenidos y entidades DCPS en escenarios basados en DDS-IS. Además, permite la creación de sesiones entre nodos, lo que facilita la creación de rutas DCPS y el cumplimiento de QoS extremo a extremo. También proponemos un mecanismo para la identificación universal de contenidos y entidades DCPS. 3. Uso DCPS para REsource LOcation And Discovery (RELOAD): Proponemos una solución Peer-to-Peer (P2P) para el descubrimiento y acceso a contenidos mediante una aproximación DCPS. La solución propuesta se basa en el framework RELOAD, uno de los últimos estándares de la Internet Engineering Task Force (IETF). Nuestra solución no está limitada a escenarios basados en DDS, sino que es válida incluso si sólo algunos nodos (o incluso ningún nodo) del overlay soporta DDS. Se demuestra experimentalmente que nuestra solución, basada en una arquitectura P2P, proporciona una gran escalabilidad y robustez para desplegar sistemas basados en DCPS. 1.4 Estado del arte y trabajo relacionado Esta sección estudia el estado del arte que define el contexto en el que se ha desarrollado la Tesis.

39 8 Capítulo 1. Introducción Modelo de interacción publicación-suscripción La característica principal de las arquitecturas basadas en publicación-suscripción es que los consumidores de información (suscriptores) y los productores de información (publicadores) están desacoplados en tiempo, espacio y sincronización [65] [21]. Basados en el modelo de publicación-suscripción existen varios ejemplos relevantes de implementaciones de Message Oriented Middleware (MOM) [7] como Java Messaging Service (JMS) [74] y Advanced Message Queuing Protocol (AMQP) [3]. Otros ejemplos destacables son [96] y [95], trabajos en los que se propone una arquitectura publicación-suscripción para sistemas distribuidos de tiempo real basada en el middleware CORBA [68]. En [107] se propone una solución para el despliegue de sistemas publicación-suscripción basada en XML. Otra contribución destacable es SIENA [12], un servicio de notificación de eventos mediante publicaciónsuscripción basado en una arquitectura P2P. En la siguiente sección se describirán las características de éste y otros trabajos basados en P2P. Directamente relacionado con nuestro trabajo, los autores de [75] [93] proponen DDS, un middleware que proporciona distribución de contenidos DCPS. Como se ha comentado previamente, DDS fue adoptado en 2004 por el OMG [73] [67] como middleware estándar de comunicaciones DCPS. Desde la estandarización de la especificación original en 2004, han aparecido más de ocho implementaciones diferentes del estándar [72]. DDS está en continua evolución, y en los últimos años se han adoptado varias extensiones a la especificación original. Por ejemplo, DDS-RTPS [69] define el protocolo que permite la interoperabilidad de diferentes implementaciones DDS. Otro ejemplo destacable es la especificación Extensible And Dynamic Topic Types For DDS (DDS-XTypes) [71], que permite a las aplicaciones DDS definir nuevos tipos en tiempo de ejecución Escalabilidad de los sistemas publicación-suscripción Las tecnologías de publicación-suscripción se implementan normalmente como servicios basados en brokers, lo que conlleva una serie de problemas asociados a las arquitecturas centralizadas, tales como la aparición de cuellos de botella o la falta de robustez frente a errores. Con objeto de superar estos problemas, se han propuesto muchas soluciones en la literatura. Por ejemplo, [23] propone una solución jerárquica multinivel (clusters

40 1.4. Estado del arte y trabajo relacionado 9 y super-clusters) basada en el estándar JMS para interconectar grids. Esta solución distribuye la carga entre los distintos clusters, con lo que consigue una federación de clusters escalable y robusta frente a fallos. Sin embargo, esta aproximación no soporta la transformación de datos, que es uno de los objetivos de nuestro trabajo. Además, esta solución no aborda el problema de la provisión de QoS, lo que dificulta su implantación en escenarios con requisitos críticos. Los autores de [12] proponen SIENA, un servicio publicación-suscripción de notificación de eventos que utiliza dos arquitecturas para la distribución de notificaciones: cliente-servidor jerárquica y P2P. Con respecto al esquema de encaminamiento utilizado, (i.e., el criterio que aplica el sistema en cada salto para tomar la decisión de transmitir los eventos desde los publicadores a los suscriptores), SIENA utiliza una aproximación basada en filtros (i.e., toma la decisión de encaminamiento mediante un filtro basado en contenido situado en cada nodo). Sin embargo, este trabajo no soporta encaminamiento basado en multicast, que es uno de los esquemas de comunicación que soporta DDS. Además, este trabajo no considera la transformación de datos ni la provisión de QoS. Los autores de SIENA en [13] proponen un esquema de encaminamiento que combina broadcast y filtrado basado en contenido para mejorar la escalabilidad del sistema. Como ocurría en el anterior trabajo, en este último tampoco se considera la transformación de los datos ni la provisión de QoS. De forma similar, [11] propone Kyra, un esquema de encaminamiento que utiliza filtros basados en contenido y que aplica mecanismos de distribución de carga. Nuevamente, este trabajo no soporta encaminamiento basado en multicast, ni transformación de datos, ni provisión de QoS. Todos los trabajos anteriormente citados utilizan filtros basados en contenido para el encaminamiento de los eventos. A continuación se comentan otros trabajos que se basan en multicast para realizar el encaminamiento. Los autores de [15] proponen HOMED, un overlay P2P para soportar sistemas distribuidos de publicación-suscripción. HOMED organiza a los participantes de acuerdo a sus intereses con objeto de construir un árbol de distribución de eventos flexible y eficiente. Otra alternativa es [98], en la que se propone asociar suscripciones y eventos a nodos de rendezvous. Esta asociación se realiza en base a una combinación del identificador de dominio con el número de atributos en las suscripciones y eventos. Sin embargo, ninguna de las dos soluciones anteriores considera el problema de la transformación de datos o la provisión de QoS. Los autores de [104] proponen particionar el espacio de eventos entre los peers en el sistema, y enviar los eventos y suscripciones mediante broadcast a todos los nodos. El coste de estos broadcast se reduce mediante la instalación en los nodos de filtros

41 10 Capítulo 1. Introducción asociados a las suscripciones. Como contrapartida, esta aproximación requiere en ciertos casos que todos los nodos del sistema sean contactados para instalar una suscripción. Con objeto de reducir el número de peers contactados, [25] propone Meghdoot, un sistema de publicación-suscripción basado en contenido basado en una infraestructura Content Addressable Network (CAN). Nuevamente ninguna de estas dos soluciones considera el problema de la transformación de datos ni la provisión de QoS. Más recientemente, el proyecto Apache QPiD [4] propone un mecanismo de federación para AMQP [3] que incrementa la escalabilidad del sistema mediante el establecimiento de rutas dedicadas entre brokers. También relacionado con AMQP, [60] propone un método sistemático para configurar federaciones de brokers basadas en AMQP. Una aproximación diferente es propuesta en [108], donde los autores combinan clustering, encaminamiento basado en contenido e inundación para conseguir un sistema escalable de publicación-suscripción para MANETs. Todos los casos anteriores cubren únicamente el problema de la escalabilidad, dejando abiertas cuestiones tales como la transformación de datos. Relacionado con DDS, los autores de [16] y [17] presentan REliable and VErsatile News delivery support for agencies (REVENGE). REVENGE es un middleware para la distribución de noticias entre clientes heterogéneos, a la vez que garantiza QoS, disponibilidad y fiabilidad. Este trabajo consta de dos contribuciones principales: un sustrato de encaminamiento P2P auto-organizable para facilitar la entrega fiable de datos entre nodos móviles, y una infraestructura de soporte DDS basada en relays. Esta infraestructura de soporte se caracteriza por un overhead reducido que permite la distribución de datos escalable en Internet. Los nodos relay de REVENGE permiten el intercambio de información entre distintos dominios DDS. Sin embargo, este intercambio está limitado a tópicos y tipos de datos específicos, lo que limita la flexibilidad del sistema. Finalmente, en [77] los autores proponen una arquitectura para interconectar dominios DDS con Enterprise Service Bus (ESB), permitiendo el intercambio de información entre el mundo de los equipos empotrados y el mundo empresarial. Este trabajo se centra principalmente en incrementar la interoperabilidad de DDS mediante un sustrato de encaminamiento entre ESB y DDS. Sin embargo, no proporciona ningún mecanismo para incrementar la escalabilidad de DDS (tal como la agregación de datos propuesta en esta Tesis), ni proporciona mecanismos para la transformación de datos DDS (salvo los estrictamente necesarios para integrar ESB y DDS).

42 1.4. Estado del arte y trabajo relacionado Descubrimiento de recursos y RELOAD Uno de los problemas existentes de DDS es la escalabilidad de su protocolo de discovery en escenarios de gran escala (escenarios con miles de nodos). En la literatura se pueden encontrar múltiples propuestas que se aprovechan de arquitecturas basadas en P2P para llevar a cabo el descubrimiento de recursos. Por ejemplo, [90] propone Spider, un framework para el descubrimiento de servicios Web que soporta la localización de servicios utilizando palabras clave, ontologías y patrones de comportamiento. También relacionado con el descubrimiento de servicios Web, los autores de [94] proponen un sistema de indexado escalable que incorpora mecanismos de distribución de carga para arquitecturas basadas en P2P. Sin embargo, estos dos trabajos se centran en descubrimiento de servicios Web, y por tanto no son adecuados para soportar los requerimientos específicos de los middleware de publicación-suscripción (por ejemplo, DDS requiere tratar a los publicadores, suscriptores y participantes de forma diferente). SOLAR [14] propone el concepto de Descubrimiento de Recursos Sensible al Contexto (CSRD). Este trabajo, principalmente centrado en arquitecturas de tipo context-aware, no aborda la provisión de QoS, lo que dificulta su implantación en escenarios con requisitos críticos. Con respecto al discovery de DDS, la publicación [92] propone utilizar filtros de Bloom para solucionar el problema de la escalabilidad del discovery en entornos DDS. Sin embargo, este trabajo no aborda otras cuestiones como el mantenimiento de un overlay para lograr una mayor robustez frente a fallos, o el paso a través de NATs. En el momento de escritura de estas líneas, RELOAD [44] se encuentra en proceso de aprobación como estándar por la IETF. RELOAD es un protocolo de la IETF para el despliegue y mantenimiento de sistemas P2P en Internet. En concreto, este protocolo facilita mecanismos para el descubrimiento de recursos y el almacenamiento y obtención de contenidos. Con el fin de demostrar la viabilidad de RELOAD como una arquitectura P2P estable y fiable, varios trabajos han sido publicados. Por ejemplo, las prestaciones de RELOAD en entornos inalámbricos han sido evaluadas en [58], mientras que en [56] se lleva a cabo un estudio de las prestaciones de RELOAD en entornos basados en Interactive Connectivity Establishment (ICE) para el paso a través de NATs. Otra contribución es [28], que aborda el problema del descubrimiento de recursos y notificaciones en entornos Constrained Application Protocol (CoAP). Por último, y estrechamente relacionado con nuestro trabajo, los autores de [2] proponen un protocolo de publicación-suscripción basado en RELOAD. Aunque

43 12 Capítulo 1. Introducción este trabajo proporciona las características básicas que requiere un sistema de publicación-suscripción, está totalmente basado en el tunneling de las muestras, lo que limita su flexibilidad y extensibilidad. Además, este trabajo no cubre el descubrimiento de entidades específicas de DDS, tales como son los participants DDS y SIP Con objeto de proveer DDS de un protocolo de señalización, inicialmente se consideró la posibilidad de usar Session Initiation Protocol (SIP). SIP [83] es un protocolo especificado por la IETF [39] para la señalización de sesiones en arquitecturas cliente-servidor. Al inicio de esta Tesis, no existían otras publicaciones que integrasen SIP y DDS. En [51] propusimos un gateway básico DDS-SIP para la conexión de dominios DDS. Ésta fue la primera publicación en definir el concepto de sesión DDS. En concreto, este trabajo definía una sesión DDS como un canal lógico que conecta dos dominios DDS remotos. Sin embargo, finalmente decidimos usar RELOAD una aproximación P2P en lugar de SIP una aproximación cliente-servidor porque aportaba una mayor escalabilidad al sistema. En [26] se encuentra otro ejemplo de integración entre SIP y DDS. Este trabajo propone un sistema que integra el protocolo SIP y DDS para desplegar aplicaciones basadas en DDS sobre redes de área amplia (WANs) IP con soporte de QoS. Además, define una extensión a Session Description Protocol (sdp) que soporta la descripción de medios asociados a sesiones DDS. Como punto negativo, esta solución está limitada por la arquitectura cliente-servidor a la que SIP está ligado. 1.5 Contribuciones principales Las principales contribuciones de esta Tesis son: 1. El diseño, implementación y evaluación de prestaciones de DDS data-space Interconnection Service (DDS-IS). 2. Un estudio del impacto de DDS-IS en la provisión de QoS. 3. La definición de identificadores universales para los dominios y tópicos DDS. 4. El diseño de un protocolo orientado a DCPS para el establecimiento de sesiones, denominado Data-Centric SIP (DCSIP).

44 1.5. Contribuciones principales El diseño, implementación y evaluación de una extensión (un usage) de RELOAD para proveer el descubrimiento de contenidos y entidades DCPS. Consideramos que estas contribuciones constituyen un paso importante en la dirección de convertir DDS en una tecnología madura y sin fisuras, alineada con la visión de una Internet basada en nombres Trabajos publicados Parte de nuestro trabajo se encuentra ya disponible para la comunidad científica a través de varias comunicaciones y publicaciones en revistas indexadas en el JCR. Adicionalmente, y como resultado del trabajo realizado, se ha solicitado una patente que se encuentra actualmente en explotación por Real-Time Innovations Inc.. Contribuciones directamente relacionadas con esta Tesis: 1. G. Pardo-Castellote, F. Sanchez, and J. M. Lopez-Vega, Deploying DDS on a WAN and the GIG: The DDS router, in Real-time and Embedded Systems Workshop. OMG, Jul [Online]. Disponible: meetings/gov-ws/pr/rte.htm [76] 2. J. M. Lopez-Vega, J. Povedano-Molina, and J. M. Lopez-Soler, DDS/SIP interworking: A DDS-SIP gateway, in Real-time and Embedded Systems Workshop, May [Online]. Disponible: pr/pdf/lopez-vegapovedano-molinalopez-soler_dds-sip.pdf [51] 3. A. De-Campos-Ruiz, G. Pardo-Castellote, J. M. Lopez-Vega, and F. Crespo- Sanchez, Patent US bridging data distribution services domains based on discovery data,, May [Online]. Disponible: http: // [18]. 4. J. M. Lopez-Vega, J. Povedano-Molina, G. Pardo-Castellote, and J. M. Lopez- Soler, A content-aware bridging service for publish/subscribe environments, Journal of Systems and Software, vol. 86, no. 1, pp , Jan [Online]. Disponible: [53] 5. J. Jimenez, J. M. Lopez-Vega, J. Maenpaa, and G. Camarillo, A constrained application protocol (CoAP) usage for REsource LOcation and discovery (RE- LOAD), Working Draft, IETF Secretariat, Fremont, CA, USA, Feb [Online]. Disponible: [45] Otras contribuciones parcialmente relacionadas con esta Tesis:

45 14 Capítulo 1. Introducción 1. J. M. Lopez-Vega, J. Sanchez-Monedero, J. Povedano-Molina, and J. M. Lopez- Soler, QoS policies for Audio/Video distribution over DDS middleware, in Workshop on Distributed Object Computing for Real-time and Embedded Systems, Jul [Online]. Disponible: rt_embedded_2008.htm [50] 2. J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, An XML-based approach to the configuration and deployment of DDS applications, in Workshop on Distributed Object Computing for Realtime and Embedded Systems, Jul workshops/real-time_ws_final_presentations_2008/session2/02-03_monedero_et_al.pdf [91] 3. J. M. Lopez-Vega, J. Povedano-Molina, J. Sanchez-Monedero, and J. M. Lopez- Soler, Políticas de QoS en una plataforma de trabajo colaborativo sobre middleware DDS, in XIII Jornadas de Tiempo Real, Feb [52] 4. J. Povedano-Molina, J. M. Lopez-Vega, J. Sanchez-Monedero, and J. M. Lopez- Soler, Instant messaging based interface for data distribution service, in XIII Jornadas de Tiempo Real, [79] 5. J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, EMDS: an extensible multimedia distribution service, in Real-time and Embedded Systems Workshop, May [Online]. Disponible: SMCS/rt/pr/pdf/Povedano-MolinaLopez-VegaLopez-Soler_EMDS.pdf [78] 6. J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez- Soler, Bloom filter based discovery protocol for DDS middleware, Journal of Parallel and Distributed Computing, vol. 71, no. 10, pp , May [Online]. Disponible: [92] 7. J. M. Lopez-Soler, J. M. Lopez-Vega, J. Povedano-Molina, and J. J. Ramos- Munoz, Performance evaluation of Publish/Subscribe middleware technologies for ATM (air traffic management) systems, in Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems, [49] 1.6 Estructura del documento A continuación se describe como se ha estructurado el presente documento. En el Capítulo 2 se estudian las tecnologías que supusieron el punto de partida de esta Tesis.

46 1.6. Estructura del documento 15 La solución propuesta ha sido dividida en tres capítulos que se corresponden a la división descrita en la Sección 1.3. Cada uno de dichos capítulos incluye su propia introducción, casos de uso, diseño, experimentos, resultados, discusión de los resultados y conclusiones. Esta estructura facilita la lectura del documento, ya que cada capítulo está autocontenido y puede ser leído de forma independiente. En concreto, el Capítulo 3 incluye el diseño, implementación y evaluación de prestaciones de un servicio de interconexión de dominios DDS; asimismo incluye un estudio del impacto del servicio en la provisión de QoS. En el Capítulo 4 se presenta el diseño de un protocolo orientado a DCPS para el establecimiento de sesiones, llamado DCSIP. En el Capítulo 5 se presenta el diseño, implementación, y evaluación de una nueva extensión (usage) para RELOAD que proporciona mecanismos para el descubrimiento de contenidos y entidades DCPS. Por último, en el Capítulo 6 se discuten trabajos relacionados, y en el Capítulo 7 se resumen las principales conclusiones de nuestro trabajo.

47

48 Chapter 1 Introduction Current uses of the Internet are mostly built on request-response exchanges between pairs of computers. This model has been very successful at providing shared remote access to resources and point-to-point communications for applications including , remote file and database access, web access, etc. Transmission Control Protocol (TCP), the most widely used Internet protocol, is also geared towards provided reliable point-to-point communications, to the extent that each TCP message embeds the location of the sending and receiving endpoints. The advent of ubiquitous Internet connectivity and cheap network-connected devices has greatly expanded the communication needs of applications using the Internet. For these new kinds of applications the request-response communications model is cumbersome and limited whereas other communication models, such as publish-subscribe [21], provide a more natural fit. The nature and historical context of this problem is well described in Van Jacobson et al. seminal work [41]: The engineering principles and architecture of today s Internet were created in the 1960s and 70s. The problem networking aimed to solve was resource sharing [...]. The communication model that resulted is a conversation between exactly two machines, one wishing to use the resource and one providing access to it. Thus IP packets contain two identifiers (addresses), one for the source and one for the destination host, and almost all the traffic on the Internet consists of (TCP) conversations between pairs of hosts. In the 50 years since the creation of packet networking, computers and their attachments have become cheap, ubiquitous commodities. The connectivity offered by the Internet and low storage costs enable access to a staggering amount of new content 500

49 18 Chapter 1. Introduction exabytes created in 2008 alone [24]. People value the Internet for what content it contains, but communication is still in terms of where. We see a number of issues that affect users arising from this incompatibility between models. Availability: Fast, reliable content access requires awkward, pre-planned, applicationspecific mechanisms like CDNs and P2P networks, and/or imposes excessive bandwidth costs. Security: Trust in content is easily misplaced, relying on untrustworthy location and connection information. Location-dependence: Mapping content to host locations complicates configuration as well as implementation of network services. The direct, unified way to solve these problems is to replace where with what. Host-to-host conversations are a networking abstraction chosen to fit the problems of the 60s. We argue that named data is a better abstraction for today s communication problems than named hosts. In contrasts to the request-response interaction model, in which a client sends a request and a server returns a response, this Thesis that in a sense is aligned with Jacobson s vision focuses on the publish-subscribe interaction model. In the publish-subscribe model information producers (publishers) are decoupled from information consumers (subscribers) via the publish-subscribe service. Publishers generate events or update a shared information space, subscribers express their interest in certain patterns of events or parts of the information space, and the publish-subscribe service delivers the desired information from publishers to subscribers. This vision is well aligned with recent projects aimed at defining a future publishsubscribe-based Internet that substitutes the current Internet design, in particular Publish-Subscribe Internet Routing Paradigm (PSIRP) [20] [22] and Publish Subscribe Internet Technology (PURSUIT) [82]. 1.1 Motivation In 2004, the Object Management Group (OMG) [73] adopted Data Distribution Service (DDS) [67], a specification that standardizes data-centric publish-subscribe communications. This specification defines a standardized Application Programming Interface (API) for exchanging information following a Data-Centric Publish- Subscribe (DCPS) model. In this model, publishers and subscribers exchange information through a distributed cache known as data-space (also known as DDS domain). Another relevant characteristic of DCPS is that exchanged information

50 1.1. Motivation 19 is not opaque to the middleware. In this way, DDS is able to provide advanced functionalities such as data-caching or content-based-filtering. The DDS standard is still growing. Proof of the activity around this standard is the fact that just in the last two years the OMG has published four of the six documents currently constituting the DDS standard family. As a consequence of the relative novelty of DDS, there are still several problems to solve. DDS was originally designed for isolated Local Area Networks (LANs) in which data sources (publishers) and data consumers (subscribers) are located in the same geographical location. Problems arise if a subscriber has interest in data being originated in a different data-space, especially if that data-space is separated by a bandwidth-constrained network, or if a Network Address Translation (NAT) or firewall service is present Domain interconnection Consider an example scenario with a company that relies on DDS for delivering some data-content internally. In addition, this company provides certain services that require to expose a subset of that data-content to another company. A simplistic solution to the previous use case would be to merge the two dataspaces. That is, to implement a service that publishes and announces all the topics from one data-space to the other. However, the direct merging of the data-spaces would create some significant problems. The first problem is related to scalability. Every publication available in one data-space will be indiscriminately announced in the other data-space. This may be wasteful in resources in situations where there are no consumers to that information on the second data-space. Other problems are concerned to data compatibility. For instance, each dataspace may have its own (possibly different) data model (i.e., data names, types, and/or definitions). These models could be incompatible even if they refer to the same data items. For example, temperature data might be expressed in Celsius in one data-space and in Fahrenheit in the other one. Therefore, in order to keep the end-to-end application logic unchanged, data should be automatically transformed by the publish-subscribe infrastructure when bridging data-spaces with different data models. As an additional benefit, this will ease the integration between new and legacy DDS applications. Access control and information confidentiality adds another dimension to this problem: Some parts of the data should be confined in a data-space whereas other

51 20 Chapter 1. Introduction data should be public. Another relevant issue is related to the possibility of having different delivery requirements for the information that flows between and within the different interconnected data-spaces. For example, system administrators should be able to establish the Quality of Service (QoS) requirements that domains must meet in order to be bridged. The current DDS specifications do not address any of these domain interconnection issues. Consequently, one aspect of this research focused on the design of a service that connects disjoint DDS data-spaces (i.e., a bridging service) while also solving the problems stated above Signaling DDS models information exchange using six different entities: DomainParticipant, Topic, Publisher, Subscriber, DataWriter (DW), and DataReader (DR). DomainParticipant represents the connection from an application to a shared dataspace. Topic represents a stream of information of interest, it has an associated topic name and data-type. Publisher is the object responsible for sending information. Subscriber is the object responsible for receiving information. DataWriter (DW) is the object the application uses to write data to a specific topic. Each DW is bound to a specific topic (and therefore data-type) and belongs to a publisher. DataReader (DR) is the object the application uses to receive data on a specific topic. Each DR is bound to a topic (and therefore data-type) and belongs to a subscriber. All these DDS entities have QoS attached to them specifying non-functional aspects of the information exchange. In order to exchange data-content, DDS entities must discover each other. DDS includes a discovery mechanism. DDS discovery is the process used by the publishsubscribe service to find the entities which share a particular topic and meet a set of QoS requirements.

52 1.2. Goals 21 Once a DW discovers a matching DR the corresponding applications can start exchanging data. Originally, the DDS specification standardized the programming model and API for developing DCPS applications. Despite of the fact that it defined the entities for exchanging discovery information, it did not specify the network protocol used by DDS implementations in a way that would allow different implementations to interoperate. The OMG addressed this issue by specifying the Real-time Publish- Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) [69]. The DDS-RTPS specification defines the so called DDS Simple Discovery Protocol (SDP) to perform the discovery. This discovery protocol was designed for relatively small environments (up to a few thousands nodes connected through a LAN). In this regard, the current DDS specifications do not address the problem of universal entity identification and universal data-content identification. Another existing limitation impacts scalability. Most of current DDS implementations rely on using multicast or a centralized server for discovery. In this sense, DDS-RTPS does not address the problem of entity or data-content discovery in large-scale deployments, nor provides any mechanism for performing NAT traversal. Fortunately, the DDS-RTPS specification allows DDS implementations to define their own discovery protocols, therefore is possible to define new protocols that address these issues. The introduction of a bridging service between DDS entities (as the one proposed in this Thesis) creates new problems. In particular, current DDS QoS policies were designed for single-domain-based scenarios, and they may behave unexpectedly in environments were a bridging service is present. In addition, applications need new mechanisms for negotiating what contents are propagated through different data-spaces. In short, the introduction of intermediate nodes in DDS creates the need of new mechanisms that support the negotiation of QoS policies among remote nodes, along with the creation of publications and subscriptions across DDS bridging services. In order to address these issues, this Thesis defines and proposes the use of a signaling protocol for DDS. 1.2 Goals The main objectives of the Thesis are organized in two categories: DDS data-space interconnection and session signaling. DDS data-space interconnection: Objective: To design a data-space bridging service for DDS.

53 22 Chapter 1. Introduction Objective: To increase the extensibility and flexibility of DDS systems, easing DDS systems evolution. Objective: To implement and evaluate the designed data-space bridging service for DDS. Objective: To study the impact of the proposed service in DDS QoS. Session signaling in DDS: Objective: To design an universal entity and data-content naming format for DCPS environments. Objective: To design a protocol for DCPS entities discovery and session establishment in DDS. Objective: To evaluate the scalability and robustness of the proposed solution. 1.3 Solution overview The solution proposed in this Thesis consists of three parts: 1. DDS data-space Interconnection Service (DDS-IS): We propose a solution for the interconnection of DDS data-spaces that is compliant with DDS specification. We experimentally demonstrate that it provides data transformation between data-spaces, performs content-based filtering, increases DDS scalability, and provides QoS adaptation between remote entities. 2. Data-Centric SIP (DCSIP): We propose the fundamentals and rationale of a protocol for session signaling in DCPS environments. This protocol solves DCPS entity and data-content discovery in DDS-IS-based deployments. It also allows the creation of sessions between nodes, which eases the creation of DCPS routes and the enforcement of QoS at end-to-end level. We also propose a mechanism for universal identification of DCPS entities and data-content. 3. DCPS usage for REsource LOcation And Discovery (RELOAD): We propose a Peer-to-Peer (P2P) solution for discovering and accessing to content using a DCPS approach. Our solution is based on the RELOAD framework, one of the latest standards of the Internet Engineering Task Force (IETF). Our solution is not limited to DDS-based scenarios, and it is valid even if only a few (or none) of the nodes in the overlay supports DDS. We experimentally demonstrate that our solution, based on a P2P architecture, features great scalability and robustness for deploying DCPS-based systems.

54 1.4. State of the art and related work State of the art and related work This section studies the state of the art that provides the context for the research carried out in this Thesis Publish-subscribe interaction model The key feature of publish-subscribe-based architectures is that information consumers (subscribers) and information producers (publishers) are decoupled in time, space, and synchronization [65] [21]. Several Message Oriented Middleware (MOM) [7] implementations, which are based on asynchronous message-passing, use the publish-subscribe model for exchanging data. For example, Java Messaging Service (JMS) [74] and Advanced Message Queuing Protocol (AMQP) [3] are MOM-based technologies that allow applications to deliver messages using a publish-subscribe approach. Other relevant approaches are also remarkable. For instance, [96] and [95] propose a publisher-subscriber architecture for distributed real-time systems based on CORBA middleware [68], and [107] proposes an XML-based solution for deploying publish-subscribe systems. Another interesting solution is SIENA [12], a publishsubscribe event notification service that takes advantage of a P2P architecture. We will study this and other P2P-based approaches in the next section. Directly related to our work, the authors of [75] [93] propose DDS, a middleware that provides data-centric publish-subscribe content distribution. DDS was adopted in 2004 by the OMG [73] [67] as the standard middleware for DCPS communications. Since the original DDS specification in 2004, more than eight different implementations of the standard have appeared [72]. The DDS standard is still growing, and several extensions to the original specification have been adopted over the last years. For example, DDS-RTPS [69] defines a protocol that allows different DDS implementations to interoperate. Another noteworthy example is the Extensible And Dynamic Topic Types For DDS (DDS-XTypes) [71] specification, which allows DDS applications to define new types in runtime. However, and due to the novelty of the standard, several problems, such as the interconnection of disjoint domains, remain unsolved.

55 24 Chapter 1. Introduction Scalability in publish-subscribe systems Publish-subscribe technologies are usually implemented as brokered services. This leads to well known issues that derive from centralized architectures such as single point of failure and bottlenecks. To cope with these issues, many solutions have been proposed in the literature. For instance, [23] proposes a hierarchical multi level (clusters and super-clusters) JMS compliant approach for interconnecting grids. It features scalability, loadbalancing, and fault-tolerant federation. However, this approach does not support data transformation, which is one of our initial objectives. Moreover, it does not take into account QoS related issues, making difficult its usage in critical scenarios. The authors of [12] propose SIENA, a publish-subscribe event notification service that utilizes two different architectures for distributing event notifications: hierarchical client-server and P2P. Regarding the routing scheme (i.e., the criteria that the system follows in each hop to decide how forward samples from publishers to subscribers), SIENA uses a filter-based approach (i.e., it makes routing decisions via successive content-based filtering at all nodes from source to destination). However, this work does not support multicast-based routing, which is one of the communication schemes that DDS supports. Moreover, this work does not consider data transformation nor QoS enforcement. From the authors of SIENA, [13] proposes a routing schema that combines broadcast and content-based filtering for improving the scalability of the system. As in the previous work, it does not consider data transformation nor QoS enforcement. Similarly, [11] proposes Kyra, a routing scheme based on content-based filtering that applies load balancing mechanisms. Again, this work does not support multicast-based routing, data transformation, nor QoS enforcement. All the above-mentioned work utilize a content-based filtering approach. There are also existing approaches that use a multicast-based routing scheme. For example, the authors of [15] propose HOMED, a P2P overlay for supporting distributed publish-subscribe systems. It constructs a flexible and efficient event dissemination tree by organizing participants based on their interest. Another interesting work is [98], which proposes an alternative for creating the multicast dissemination tree. In particular, it proposes to map subscriptions and events to rendezvous nodes; for that, it uses a combination of the domain schema identifier and the numbers of attributes in the subscriptions or the events. None of the above two solutions considers the problem of data transformation nor QoS enforcement. The authors of [104] propose to partition the event space among the peers in the system, and to broadcast events and subscriptions to all nodes in the system.

56 1.4. State of the art and related work 25 These broadcasts are attenuated by filters installed at peer nodes depending on the subscriptions stored in the system. However, this approach may require all peers in the system to be contacted to install a subscription. To reduce the number of peers to be contacted, [25] proposes Meghdoot, a content-based publish-subscribe system built on top of Content Addressable Network (CAN) infrastructure. Again, none of these two solutions considers the problem of data transformation nor QoS enforcement. More recently, the Apache QPiD project [4] includes a federation mechanism for AMQP [3] that increases the scalability of the system by establishing dedicated routes between brokers. Also related to AMQP, [60] provides a systematic method for configuring broker federation in AMQP-based systems. A different approach is included in [108], where the authors combine clustering, content-based routing, and document flooding for providing scalable publish-subscribe communications for MANETs. In all these cases, they deal only with scalability problem, leaving open issues such as data transformation. Related to DDS, the authors of [16] and [17] present REliable and VErsatile News delivery support for agencies (REVENGE). REVENGE is a middleware used to distribute breaking news among heterogeneous clients while guaranteeing QoS, availability, and reliability. This work has two main contributions: a self-organizing P2P routing substrate to facilitate reliable data delivery between mobile nodes, and a relay-based DDS support infrastructure with limited overhead to enable scalable, Internet-wide data dissemination. REVENGE relay nodes allow for the exchange of information among different DDS domains. However, this communication is bound to a specific topic/data-type, which limits the flexibility of the system. Finally, in [77] the authors propose an architecture to interconnect DDS dataspaces with Enterprise Service Bus (ESB), thus allowing to exchange information between the embedded world and the enterprise system. This work is mainly focused on increasing the interoperability of DDS by providing a routing substrate between ESB and DDS. However, it does not provide any mechanism to increase the scalability on the DDS system (like the data aggregation proposed in this Thesis), and does not provide mechanisms for performing DDS data transformations (except the strictly necessary for integrating ESB and DDS) Resource discovery and RELOAD One of the current issues of DDS is the scalability of its discovery protocol in largescale deployments (deployments with thousands of nodes). In the literature we can find several proposals that take advantage of P2P-based architectures for performing resource discovery. For example, [90] proposes Spi-

57 26 Chapter 1. Introduction der, a framework for Web Service discovery. It supports the lookup of Web Services based on keywords, ontologies, or behavior. Also related to Web Service discovery, the authors of [94] propose a scalable indexing system for P2P-based architectures that incorporates load-balancing mechanisms. However, these two works are focused in Web Service discovery, and therefore they are not suited to support the specific requirements of a publish-subscribe middleware (for example, DDS requires to treat publishers, subscribers, and participants differently). SOLAR [14] proposes the Context-Sensitive Resource Discovery (CSRD). This work, mainly focused on context-aware architectures, does not take into account QoS related issues, making it difficult to be used in more critical scenarios. Regarding discovery in DDS, the paper [92] addresses the problem of scalable discovery in DDS environments by applying Bloom filters. However, this work only focuses on the discovery problem itself, not addressing other issues such as maintaining an overlay to provide fault-tolerance, or NAT-traversal. In the time of writing, the IETF is in the process of approving RELOAD [44] as standard. RELOAD is an IETF protocol for building and maintaining P2P systems on the Internet. In particular, it provides mechanisms for resource discovery and for data-content storage and retrieval. A number of papers have aimed to demonstrate the feasibility of RELOAD as an stable and reliable P2P architecture. For instance, RELOAD performance in wireless environments has been studied in [58]. In [56], a study of the performance of RELOAD on an Interactive Connectivity Establishment (ICE)-based environment for NAT traversal is done. Another contribution is [28], which addresses the problem of resource discovery and notification in Constrained Application Protocol (CoAP) environments. Finally, and very close to our work, the authors of [2] propose a publish-subscribe protocol built atop of RELOAD. Although it provides the basic features needed for a publish-subscribe system, it relies completely on tunneling publish-subscribe samples, which hinders its flexibility and extensibility. Moreover, this work does not cover the discovery of specific DDS entities, such as participants DDS and SIP In order to provide DDS of a signaling protocol, we initially consider using Session Initiation Protocol (SIP). SIP [83] is an IETF [39] protocol specification for session signaling in client-server-based architectures. At the beginning of this Thesis, there were no other publications that integrated SIP and DDS. In [51] we proposed a basic DDS-SIP gateway to connect remote DDS

58 1.5. Main contributions 27 domains. This was the first publication that defined the concept of DDS session. This work defined DDS session as a logical channel that connects two remote DDS domains. However, we finally decided to use RELOAD a P2P approach instead of SIP a client-server approach because it provides greater scalability. We can find another example of SIP-DDS integration in [26]. This paper proposes a system that integrates SIP and DDS for supporting DDS-based applications over QoS-enabled IP WANs. It also defines an extension to Session Description Protocol (sdp) that supports the media description of DDS sessions. As a downside, this solution is limited by the client-server architecture SIP is bound to. 1.5 Main contributions The main contributions of the Thesis are: 1. The design, implementation, and performance evaluation of a DDS data-space Interconnection Service (DDS-IS). 2. A study of the impact of DDS-IS in QoS enforcement. 3. The definition of universal identifiers for DDS domains and topics. 4. The design of a DCPS-oriented protocol for session establishment, Data-Centric SIP (DCSIP). 5. The design, implementation, and evaluation of a new RELOAD usage for providing DCPS entity and data-content discovery. We definitively believe these contributions constitute an important step toward making DDS a mature and seamless technology, aligned with the envisaged namedbased Internet Published works Part of our work is already available to the research community through several publications in indexed journals and conference proceedings. In addition, as a result of the conducted work we have applied for a patent that is currently being pursued by Real-Time Innovations Inc. Contributions directly related to this Thesis:

59 28 Chapter 1. Introduction 1. G. Pardo-Castellote, F. Sanchez, and J. M. Lopez-Vega, Deploying DDS on a WAN and the GIG: The DDS router, in Real-time and Embedded Systems Workshop. OMG, Jul [Online]. Available: meetings/gov-ws/pr/rte.htm [76] 2. J. M. Lopez-Vega, J. Povedano-Molina, and J. M. Lopez-Soler, DDS/SIP interworking: A DDS-SIP gateway, in Real-time and Embedded Systems Workshop, May [Online]. Available: pr/pdf/lopez-vegapovedano-molinalopez-soler_dds-sip.pdf [51] 3. A. De-Campos-Ruiz, G. Pardo-Castellote, J. M. Lopez-Vega, and F. Crespo- Sanchez, Patent US bridging data distribution services domains based on discovery data,, May [Online]. Available: [18]. 4. J. M. Lopez-Vega, J. Povedano-Molina, G. Pardo-Castellote, and J. M. Lopez- Soler, A content-aware bridging service for publish/subscribe environments, Journal of Systems and Software, vol. 86, no. 1, pp , Jan [Online]. Available: [53] 5. J. Jimenez, J. M. Lopez-Vega, J. Maenpaa, and G. Camarillo, A constrained application protocol (CoAP) usage for REsource LOcation and discovery (RE- LOAD), Working Draft, IETF Secretariat, Fremont, CA, USA, Feb [Online]. Available: [45] Other contributions partially related to this Thesis: 1. J. M. Lopez-Vega, J. Sanchez-Monedero, J. Povedano-Molina, and J. M. Lopez- Soler, QoS policies for Audio/Video distribution over DDS middleware, in Workshop on Distributed Object Computing for Real-time and Embedded Systems, Jul [Online]. Available: rt_embedded_2008.htm [50] 2. J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, An XML-based approach to the configuration and deployment of DDS applications, in Workshop on Distributed Object Computing for Realtime and Embedded Systems, Jul workshops/real-time_ws_final_presentations_2008/session2/02-03_monedero_et_al.pdf [91] 3. J. M. Lopez-Vega, J. Povedano-Molina, J. Sanchez-Monedero, and J. M. Lopez- Soler, Politicas de QoS en una plataforma de trabajo colaborativo sobre middleware DDS, in XIII Jornadas de Tiempo Real, Feb [52]

60 1.6. Document structure J. Povedano-Molina, J. M. Lopez-Vega, J. Sanchez-Monedero, and J. M. Lopez- Soler, Instant messaging based interface for data distribution service, in XIII Jornadas de Tiempo Real, [79] 5. J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez-Soler, EMDS: an extensible multimedia distribution service, in Real-time and Embedded Systems Workshop, May [Online]. Available: SMCS/rt/pr/pdf/Povedano-MolinaLopez-VegaLopez-Soler_EMDS.pdf [78] 6. J. Sanchez-Monedero, J. Povedano-Molina, J. M. Lopez-Vega, and J. M. Lopez- Soler, Bloom filter based discovery protocol for DDS middleware, Journal of Parallel and Distributed Computing, vol. 71, no. 10, pp , May [Online]. Available: [92] 7. J. M. Lopez-Soler, J. M. Lopez-Vega, J. Povedano-Molina, and J. J. Ramos- Munoz, Performance evaluation of Publish/Subscribe middleware technologies for ATM (air traffic management) systems, in Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems, [49] 1.6 Document structure The remainder of the document is organized as follows. In Chapter 2 we study the technologies that provided the starting point of this Thesis. We have divided the proposed solution in three chapters that correspond to the division described in Section 1.3. Each one of these chapters includes its own introduction, motivating use cases, design, experiments, results, discussion of results, and conclusions. This structure eases the reading of the document, as each chapter is self-contained. In particular, Chapter 3 includes the design, implementation, and performance evaluation of a DDS data-space Interconnection Service; it also includes an study of the impact of this service in QoS enforcement. In Chapter 4 we present the design of a DCPS-oriented protocol for session establishment, named DCSIP. In Chapter 5 we present the design, implementation, and evaluation of a new usage for RELOAD that provides DCPS entity and data-content discovery. Finally, in Chapter 6 we discuss related work, and in Chapter 7 we summarize the main conclusions of our work.

61

62 Chapter 2 Background In this chapter we study the technologies that provided the starting point of this Thesis. First, we study the publish-subscribe interaction model, which is an alternative to the request-response model. In particular, we study the DDS specification, which is a standardized publish-subscribe middleware for data dissemination on real-time distributed systems. Regarding signaling and resource discovery, we study SIP, an application protocol for session signaling, and RELOAD, a standardized P2P-based framework for highly scalable resource discovery. Finally, we introduce CoAP, a HTTP-inspired protocol for exchange data-content between highly constrained devices. 2.1 Publish-subscribe interaction model Over the last few years, publish-subscribe communication systems are gaining momentum and popularity, as verified beyond doubt by the existence of successful projects like PSIRP [20] [22], and PURSUIT [82], which is a continuation of PSIRP. These projects are aimed to define a future publish-subscribe-based Internet that substitutes the current Internet design, based on TCP/IP [101]. In contrasts to the request-response interaction model, in which a client sends a request and a server returns a response, in the publish-subscribe interaction model

63 32 Chapter 2. Background producer producer request consumer response consumer consumer publisher publisher Publish-subscribe service subscribe subscriber subscriber subscriber delivery Figure 2.1: Request-response and publish-subscribe interaction models. information producers (publishers) are decoupled from information consumers (subscribers) via the publish-subscribe service. Publishers generate events or update a shared information space, subscribers express their interest in certain patterns of events or parts of the information space, and the publish-subscribe service delivers the desired information from publishers to subscribers. (see Figure 2.1 [48]). The key feature of publish-subscribe-based architectures is that information consumers (subscribers) and information producers (publishers) are triply decoupled [21]. In particular, publish-subscribe applications are decoupled in space (publishers and subscribers can be located anywhere), in time (there is no need of simultaneous end-point availability), and in synchronization/flow (publishers are not blocked while producing events, and subscribers can get notified about the occurrence of some event while performing some concurrent activity). We can classify publish-subscribe systems according to the mechanism that they use for specifying what are the events of interest [21] (i.e., the scheme). The most widely used schemes are topic-based, content-based, and type-based. In topicbased schemes, events are classified according to a label, the topic. In content-based schemes, events are classified using the content of the events. Finally, in type-based schemes, events are distinguished according to their structure. Several MOM [7] implementations, which are based on asynchronous messagepassing, use the publish-subscribe model for exchanging data. For example, JMS [74] and AMQP [3] are MOM-based technologies that allow applications to deliver messages using a publish-subscribe approach. Other relevant approaches are also remarkable. For instance, [96] and [95] propose a publisher-subscriber architecture for distributed real-time systems based on CORBA middleware [68], and [107] proposes an XML-based solution for deploying publish-subscribe systems. Another relevant work is SIENA [12], a publishsubscribe event notification service which was studied in Section Directly related to our work, the authors of [75] [93] propose DDS, a middleware that provides data-centric publish-subscribe content distribution. In the next sec-

64 2.2. Data Distribution Service (DDS) 33 tion we study OMG DDS, which is the standard specification for this middleware. 2.2 Data Distribution Service (DDS) DDS [67] is a specification adopted by the OMG [73]. DDS standardizes DCPS communications in distributed scenarios. For more information about the DCPS model, please refer to Section Since the original DDS specification in 2004, several implementations of the standard have appeared [72]: RTI Connext [89], a COTS implementation of DDS which supports multiple languages and platforms; OpenSplice [81], a partially open implementation of DDS which also supports multiple languages and platforms; OpenDDS [62], an open source C++ implementation; MilSOFT DDS [61], a COTS implementation of DDS; OCERA ORTE [63], an open source implementation of RTPS 1.0.; CoreDX [105], a COTS implementation of the DDS specification; Inter- COM DDS [47], an implementation of the DDS minimum profile; MicroDDS [30], a DDS implementation for small devices, micro-controllers and embedded systems; and BEE-DDS [100], a Java implementation of the OMG DDS standard. Over the last few years, DDS has been deployed in many contexts ranging from mission critical systems to financial environments [85] [86] [19] [87] [80]. All these scenarios have in common that different collocated entities exchange data samples coming from different sources (for example, position sensors, stocks, etc.) in a well controlled environment (i.e., a data-space). In addition, this information is exchanged with certain guarantees such as reliability or deterministic time-delivery. DDS uses a data-centric publish-subscribe model along with a rich set of QoS profiles that can be tuned to fit the communication demands of each specific scenario. DDS specification defines two different interface levels [75] and an interoperability layer [69]: The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) interoperability layer. This layer is based on the Real Time Publish Subscribe (RTPS) protocol, and allows different DDS implementations to interoperate. This layer defines the discovery protocol, data representation format, and message format DDS applications must use in order to interoperate. The mandatory Data-Centric Publish-Subscribe (DCPS) interface level. This defines a programming model and API for developing applications using a data-centric publish-subscribe approach.

65 34 Chapter 2. Background The optional Data Local Reconstruction Layer (DLRL) interface level. This layer acts as an interface between the application layer and the DCPS layer. DLRL is object oriented and was specified to ease the integration of DCPS in user applications. This level allows developers to access to DDS data-content through object attributes. In what follows under this section, we focus on studying the DCPS layer and the DDS-RTPS protocol, which have a key role in our research Data Centric Publish Subscribe layer (DCPS) The DCPS layer specification [67] defines the Data-Centric Publish-Subscribe (DCPS) programming model and its associated API for developing distributed applications. DCPS programming model is based in two main concepts: datacentricity and publish-subscribe. Data-centric oriented middleware, such as DDS, contrasts with MOM in that message content is not opaque to the middleware. Using the functionality provided by the DCPS layer, DDS is able to interpret exchanged data-samples. In this way, DDS is able to provide advanced functionalities such as data-caching or contentbased-filtering. The DCPS programming and communication model is based on the publishsubscribe paradigm, and therefore DCPS-based applications are decoupled in space, time, and synchronization. In addition, DCPS-based applications are also decoupled in platform: DCPS developers can deploy distributed systems using diverse operating systems, hardware architectures, and languages. The DCPS layer defines the following concepts: Data-space: Also known as domain, it is an aggregation of data of different datatypes and sources. More precisely, a data-space is a distributed cache, whose content is accessed and updated by subscribers and publishers. Topic: A portion of a data-space that groups data of the same data-type. Although we could think that DDS uses a topic-based scheme, this is not strictly true, since topics are usually associated to a type, which is typical of type-based schemes. Moreover, DDS supports the use of content-based filtering, which is a typical characteristic of content-based schemes. Publisher: An entity that pushes data-content updates to one or more topics. Subscriber: An entity that is interested in data-content updates from one or

66 2.2. Data Distribution Service (DDS) 35 Application Application Application DomainParticipant DomainParticipant DomainParticipant Publisher Subscriber Publisher Subscriber DW DR DW DW DR DR Reliable transport QoS data-space (domain) Topic A Topic B Best-effort transport QoS Figure 2.2: DDS concepts and entities. more topics. According to DCPS, publishers and subscribers exchange data-content within a particular shared data-space. DDS applications access and update the data-content in this data-space using topic-specific endpoint entities, respectively called DRs and DWs. Applications access to all these entities through DomainParticipants, which are the interface between applications and DDS data-spaces. Under the DCPS model, when a publisher wants to update data-content belonging to certain topic, the middleware assumes responsibility for managing its delivery to the proper interested peers (i.e., to the associated subscribers). As a result, since DDS relieves the application from burden of transmitting and managing the data, the application logic is drastically simplified. Figure 2.2 illustrates main DDS concepts and relationships. DDS states that within a data-space data objects are completely identified by a topic name, a data-type, and optionally by a key. This key is useful to identify different instances of the same topic. In order to exchange data-content, DWs and DRs (referred to as endpoints) have to find compatible endpoints. The process of finding compatible entities is known as discovery. DDS performs discovery using a set of built-in publications (i.e., a set of mandatory-to-implement publications), which are handled using the so-called Built-in DataReaders (B-DRs) and Built-in DataWriters (B-DWs) (see Figure 2.3). The discovery function allows DDS applications to automatically discover available (and compatible) publications and subscriptions. Another feature of DCPS is the support of QoS policies. A QoS policy repre-

67 36 Chapter 2. Background DomainParticipant Participant Discovery Phase Advertises this participant Discovers other participants Builtin DataWriter Builtin DataReader Participant DATA DCPSParticipant builtin topic Participant DATA DCPSParticipant builtin topic Endpoint (Reader/ Writer) Discovery Phase Advertises this Participant's DataWriters and DataReaders Discovers other Participant's DataWriters and DataReaders Builtin DataWriter Builtin DataReader Builtin DataWriter Builtin DataReader Publication DATA DCPSPublication builtin topic Subscription DATA DCPSSubscription builtin topic Publication DATA DCPSPublication builtin topic Subscription DATA DCPSSubscription builtin topic Network Figure 2.3: DCPS built-in entities for discovery purposes. sents an agreement among a group of DDS entities. This agreement determines the behavior of the middleware, and releases the application logic of certain tasks, such as communication reliability. In case of QoS infringement, DDS detects it and optionally triggers proper actions. Each DDS entity has its own QoS policies and data-caching attributes. As an example, a DW and a DR can negotiate the level of reliability of the communications (best effort or reliable delivery) by using the RE- LIABILITY QoS. It is also possible to guarantee a maximum period between data updates (DEADLINE QoS), or to filter samples according to their content or timing Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) The original DDS specification did not enforce any particular lower level implementation requirement or recommendation, such as the use of a particular underlying transport protocol. For the sake of vendors interoperability, the OMG defined the so-called Real-Time Publish-Subscribe Wire Protocol Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol (DDS-RTPS) [69]. DDS-RTPS is based on Real-Time Publish-Subscribe (RTPS), a protocol originally approved by the International Electrotechnical Commission (IEC) [32] as part of the Real-Time Industrial Ethernet Suite IEC-PAS [31]. After applying some modifications, the OMG adopted RTPS as the standard wire protocol for DDS. DDS-RTPS specifies the data representation, message format, and discovery proto-

68 2.2. Data Distribution Service (DDS) 37 col that DDS implementations must use in order to interoperate. In order to exchange data-content, DDS entities must discover each other. DDS includes a discovery mechanism. DDS discovery is the process used by the publishsubscribe service to find the entities which share a particular topic and meet a set of QoS requirements. One of the goals of DDS-RTPS is to allow entities belonging to different DDS implementations to perform discovery. DDS-RTPS discovery reutilizes most of the existing DDS core entities. Specifically, the correspondence between DDS-RTPS and DDS entities is shown in Table 2.1. Table 2.1: Correspondence DDS and DDS-RTPS entities. DDS entity DomainParticipant DataWriter DataReader Built-in DataWriter Built-in DataReader DDS-RTPS entity Participant Writer Reader ENTITYID SPDP BUILTIN * WRITER ENTITYID SPDP BUILTIN * READER According to DDS-RTPS, any discovery protocol must include the following phases: Participant Discovery Protocol (PDP) and Endpoint Discovery Protocol (EDP). The purpose of PDP is to discover new participants in the data-space. Whenever a new participant is discovered, the EDP procedure is triggered to exchange local and remote endpoints information between two participants. Different implementations may choose to support multiple PDPs and EDPs, possibly vendor-specific. As long as two participants have at least one PDP and EDP in common, they can exchange the required discovery information. For the sake of interoperability, every DDS-RTPS implementation must support at least the SDP. This protocol consist of the Simple Participant Discovery Protocol (SPDP) as PDP protocol, and the Simple Endpoint Discovery Protocol (SEDP) as EDP protocol. Figure 2.4 depicts the typical SDP sequence diagram. It consists of the following phases: Bootstrapping: SDP discovery starts using a list of known hosts. This list contains the locators (typically unicast or multicast Internet Protocol (IP) addresses) for which a participant will announce its presence. Alternatively, if there are no specified IP addresses, default addresses will be used. Both options can be used together.

69 38 Chapter 2. Background Participant A created Participant DATA heartbeat period 1 Node A Participant B DATA participant A DATA Participant B DATA Node B Resend Participant B DATA. Wait random time depending of discovery's QoS DataWriter A1 created 1 Publication A1 DATA 2 Participant B heartbeat period DataWriter A1's QoSmodified 1 Modified publication A1 DATA 2 Participant B DATA Participant B DATA (deleted) Participant B deleted Figure 2.4: SDP sequence diagram. Participant Announcement: Using the list of nodes obtained during bootstrapping, participants start the process of discovering other participants. This discovery, restricted to participants in the same DDS domain, is done via SPDP. In SPDP, nodes periodically send a special message called SPDPdiscoveredParticipantData or simply Participant DATA. If multicast is available, each participant sends a unique Participant DATA message. When a participant receives a Participant DATA message, it sends back another Participant DATA with its own information. Then, the participant stores the received participant information locally. Participant DATA contains information for establishing communication between two participants, that is, information related to the protocol version, vendor identification, unicast and multicast locators (transport protocol to use, IP address and port combinations), and information about how to track participant liveliness. Also, the information specifies what EDPs the remote participant supports. Endpoint Announcement: Once a participant checks that the remote participant

70 2.2. Data Distribution Service (DDS) 39 Node A Node B Participant A whish to inform about its Endpoints Participant B whish to mach A2, A4 and F We omit PDP information The HB is the same for both Participants participant A DATA participant B DATA Participant DATA heartbeat / BF Refresh period participant A Bloom filter Network messages SDP SDPBloom filter SDPBloom matched Endpoints DataWriter A1 created DataWriter A2 created DataWriter A3 created... DataWriter An created B can not match any topic Participant DATA heartbeat / BF Refresh period Node B's storage participant A Bloom filter Subscribe A2 Subscribe A4 Subscribe F B creates A2, A4 and F subscriptions B can match A1-N topics, topic F is a false positive B matchs A2, A4, F and tries to subscribe A2,A4,F SDP SDPBloom I have not F participant A BF Participant DATA heartbeat / BF Refresh period B deduces it was a false possitive and annotates it Figure 2.5: SDP-Bloom sequence diagram. supports SEDP, they exchange endpoint information. Endpoint information consists of a topic name, a topic type, and a set of QoS parameters. Using this information, each participant checks if local and remote endpoints are compatible, and if so, they start a publish-subscribe communication SDP Bloom In this section we introduce SDP-Bloom, an alternative SDP that helps to understand the flexibility and potential of the DDS-RTPS specification. Due to the pure distributed nature of SDP, each participant stores information about discovered participants, associated publications, and subscriptions in a local database. According to SEDP, each participant sends the description of its associated endpoints to every discovered remote participant. Therefore, each participant receives all the discovered participants endpoint information, which can generate a high number of messages. In this regard, in [92] we proposed a new discovery protocol for DDS, the SDP- Bloom. Figure 2.5 depicts the typical SDP-Bloom discovery sequence diagram. During PDP phase, participants using SDP-Bloom send a Bloom-filter summarizing

71 40 Chapter 2. Background their associated endpoint information. This allows participants to avoid performing the EDP discovery phase when the received remote participant s Bloom filter does not match with any of the local endpoints. In this way, SDP-Bloom takes advantage of using Bloom-filters for reducing the network overhead in terms of number of messages and total traffic, at the cost of a small false positive endpoint matching rate. For a more in depth study of SDP- Bloom functionality and its impact on DDS performance, please refer to [92] Extensible Topic Types As mentioned before, the DDS specification states that a topic has an associated data-type. However, binding a data-type with a publication: hinders system evolution and backward compatibility makes impossible to use a priori unknown data-types prevents from maintaining different data-types views The OMG has recently standardized the DDS-XTypes specification [71]. This specification, among other features, relaxes the requirement of using compilation time static topic data-types. The use of static topic data-types is simple, efficient, and provides compile-time type-safety. However, it requires types to be known a priori and compiled into the code. This characteristic prevents the implementation of generic bridging services for DDS, such as the one proposed in Chapter 3. In this regard, the main functionality of a bridging service is to subscribe to certain data-content in a data-space and to publish the received data-content to a different data-space. The use of static topic data-types requires developers to declare the data-types that the bridging service will use for each data-space. Consequently, it is not possible to implement a generic DDS bridging service (i.e., one that accepts topics of any data-type) by using static topic data-types. In DDS, type schemas that is, the names and definitions of a type and its fields are represented by TypeObjects. A TypeObject consists of a TypeObjectKind and a list of members. In addition to using locally serialized TypeObjects, the DDS-XTypes specification states that a serialized form of these (called DataRepresentation) must also be published (and therefore can be received) automatically during DDS discovery.

72 2.3. Session Initiation Protocol (SIP) 41 This mechanism allows applications to dynamically discover topic data-types. Once the types have been discovered, participants can use the DDS Dynamic Topic Types API (also defined in the DDS-XTypes specification) to publish and to subscribe to topics of types unknown at compilation time. Since the OMG has recently published the final version of the specification, some of the results presented in this Thesis (in particular, the ones presented in Chapter 3) are based on the current (and preliminary) version of the specification. 2.3 Session Initiation Protocol (SIP) SIP [83] is an IETF [39] protocol specification. SIP was originally specified within the Multiparty MUltimedia SessIon Control working group (MMUSIC WG) [33], and later within the Session Initiation Protocol working group (SIP WG) [34] and the Session Initiation Protocol Project INvestiGation working group (SIPPING WG) [35]. Currently, the Session Initiation Protocol Core working group (SIPCore WG) [37] is maintaining and continuing the development of the core SIP specifications. SIP is an application-layer signaling protocol for creating, modifying, and terminating sessions with one or more participants. These sessions usually include VoIP calls, multimedia streaming, and multimedia conferences. SIP also provides a registration function that allows users to upload their current location. In this section we study the fundamentals of SIP, which is one of the protocols our work is based on. In this regard, in Chapter 4 we propose a protocol for session signaling in data-centric publish-subscribe environments; and in Chapter 5 we propose an extension to RELOAD, which is a specification originally [44] conceived as an evolution of SIP Overview of SIP functionality SIP is an application-layer signaling protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls or videoconferences, among others. In this regard, SIP supports sdp, a protocol for describing the details of the session, such as the type of media, codec, or sampling rate. SIP dynamically manages sessions such as multicast conferences that is, it allows applications to invite participants to already existing sessions. In addition, it allows to negotiate and add (or remove) new media and formats to an existing session. SIP transparently supports name mapping and redirection services, which en-

73 42 Chapter 2. Background ables personal mobility. The SIP architecture originaly designed with a clientserver model also defines application servers to make the session highly configurable. SIP supports five facets of establishing and terminating multimedia communications: User location: determination of the end system to be used for communication. User availability: determination of the willingness of the called party to engage in communications. User capabilities: determination of the media and media parameters to be used. Session setup: ringing, establishment of session parameters at both called and calling party. Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. From the previous facets, in next sections we focus on user location, session setup, and session management; which are the facets this Thesis is focused on Basic concepts of SIP The following terms have special significance for SIP [83]: Address-of-Record: A SIP or SIPS Uniform Resource Identifier (URI) that points to a domain with a location service. It can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An address-of-record is frequently thought of as the public address of the user. Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. INVITE and BYE are SIP method examples. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation.

74 2.3. Session Initiation Protocol (SIP) 43 Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. Session: From the sdp specification [40]: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. SIP URI and SIPS URI: A SIP URI is a URI that identifies a communications resource. SIPS URIs use the same syntax than SIP URIs, but they specify that the resource must be contacted securely using Transport Layer Security (TLS) [6]. User Agent Client (UAC): A logical entity that creates a request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a User Agent Server (UAS) for the processing of that transaction. User Agent Server (UAS): A logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a UAC for the processing of that transaction. User Agent (UA): A logical entity that can act as both a UAC and UAS User location SIP offers a discovery capability [83]. In this regard, whenever a user wants to initiate a multimedia session, SIP discovers the current host(s) at which the target user is reachable. This is similar to the DDS discovery previously studied, where DDS entities (instead of users) discover compatible entities for exchanging DDS datasamples. In this regard, DDS application developers can take advantage of SIP location service for performing DDS discovery as we will see in Chapter 6. According to the Request For Comments (RFC) [83], the discovery process is frequently accomplished by SIP network elements, such as proxy servers and redirect servers, which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user and then sending it there. To do this, SIP network elements consult an abstract service known as location service, which provides address bindings for a particular domain. These address

75 44 Chapter 2. Background bindings map an incoming address-of-record (e.g., to one or more URIs that are somehow closer to the desired user (e.g., biloxi.com). Ultimately, a proxy will consult a location service that maps a received URI to the UA(s) at which the desired recipient is currently residing. Registration creates bindings in a location service for a particular domain. A registration associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. There are many ways for establishing the contents of the location service. One way is administratively. In the above example, an existing corporate database is the source of the information about Bob. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is referred to as registration. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests. The location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. Figure 2.6 illustrates the overall registration process, where a user named carol registers her location. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for the sake of clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. In the figure we can also observe how the proxy sip.chicago.com requests for carol s location upon bob s INVITE request. SIP does not mandate a particular mechanism for implementing the location service. The only requirements are that a registrar for some domain must be able to read and write data to the location service, and a proxy or redirect server for that domain must be capable of reading those data. A registrar may be co-located with a particular SIP proxy server for the same domain. The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs. This information indicates the proxy where to send the request. Registrations are one possible way to create this location information, but not the only one. Alternatively, the administrator can also configure arbitrary mapping functions at his discretion.

76 2.3. Session Initiation Protocol (SIP) 45 bob UA )INVITE chicago.com V )Store Location 4)Query Registrar =======> Service <======= Proxy =======> A 5)Resp sip.chicago.com 1)REGISTER UA < cube2214a 6)INVITE carol@cube2214a.chicago.com carol Figure 2.6: SIP registration and invitation example. In addition, SIP registrations are not limited to only one device per user. For instance, a single user can register to the same URI both his SIP phone at home and the one in the office Session setup and management According to the RFC [83], whenever a UAC desires to initiate a session (for example, audio, video, or a game) it formulates an INVITE request (see Figure 2.7). The INVITE request asks a server for establishing a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. If the UAS accepts the session, it will send a 2xx response (which means success) back to the UAC. If the the invitation is not accepted, the UAS will send a 3xx, 4xx, 5xx or 6xx response (which respectively mean redirection, client error, server error,

77 46 Chapter 2. Background atlanta.com... biloxi.com. proxy proxy... Alice s Bob s softphone SIP Phone INVITE F > INVITE F2 100 Trying F > INVITE F4 < Trying F > < Ringing F6 180 Ringing F7 < Ringing F8 < OK F9 < OK F10 < OK F11 < < ACK F > Media Session <================================================> BYE F13 < OK F > Figure 2.7: SIP invitation dialog. and global failure). For more information about SIP responses, please refer to the RFC [83]. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. The the UAC sends an ACK for every final response it receives. A 2xx response to an INVITE establishes a session. It also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when a UA receives multiple 2xx responses from different remote UAs (because the INVITE forked), each one of these 2xx responses establishes a different dialog. However, all these dialogs are part of the same call. A UA that supports INVITE must also support ACK, CANCEL, and BYE; as they are closely related to the INVITE request.

78 2.4. REsource LOcation And Discovery (RELOAD) 47 ACK confirms the reception of a 2xx response. CANCEL requests for the cancellation of an INVITE request. BYE requests for the finalization of an active session. SIP also provides mechanisms for modifying an existing session. The modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-invite. 2.4 REsource LOcation And Discovery (RELOAD) RELOAD [44] is an IETF protocol for building and maintaining P2P systems on the Internet. It provides a generic, self-organizing overlay network service, allowing nodes to efficiently route messages to other nodes and to efficiently store and retrieve data in the overlay. The working group responsible of the RELOAD specification is the Peer-to-Peer Session Initiation Protocol working group (P2PSIP WG) [36]. The original name of RELOAD was Peer-to-Peer Session Initiation Protocol (P2P-SIP). P2P-SIP was initially conceived as an evolution of SIP that replaced the relatively fixed hierarchy of SIP servers with a P2P overlay network [9]. The main objective of P2P-SIP was to increase the scalability of SIP by taking advantage of using a P2P approach instead of a client-server one. In this regard, the authors of [66] propose a mechanism for eliminating the need for the sign-up process and the servers for this purpose. RELOAD s original usage was focused on providing user registration, call setup, and instant messaging [99] [8]. In subsequent versions of the specification RELOAD was generalized in order to provide a P2P-based resource location and discovery service to any application (instead of only supporting the ones based on SIP) Main features RELOAD provides several features that are critical for a successful P2P protocol for the Internet [44] : - Security framework: P2P networks are often established among untrusted peers. RELOAD leverages a central enrollment server to provide credentials for each peer which can then be used to authenticate each operation. These credentials consist of a certificate assigned to each node that joins the overlay.

79 48 Chapter 2. Background - NAT Traversal: RELOAD is designed to function in environments where many (if not most) of the nodes are behind NATs or firewalls. RELOAD uses ICE [84] for providing NAT traversal functionality. - High Performance Routing: RELOAD has been defined with a simple, lightweight forwarding header, thus minimizing the amount of effort required by intermediate peers. - Pluggable Overlay Algorithms: For the sake of extensibility, RELOAD defines an abstract interface to the overlay layer to simplify implementing a variety of structured and unstructured overlay algorithms. Additionally, RELOAD uses a Chord-based Distributed Hash Table (DHT) [102] [103] as its default overlay algorithm. - Usage Model: RELOAD is designed to support a variety of (existent and future) applications. RELOAD allows the definition of new application usages, each of which can define its own data types, along with the rules for their use. In RELOAD, a Kind is the definition of a data type and its accessing rules. Therefore, new usages must define the Kinds they store in the RELOAD overlay. These properties allow RELOAD to adapt to different scenarios, while providing efficient and secure resource discovery Architecture and types of nodes A RELOAD overlay instance consists of a set of nodes arranged in a partly connected graph. Each node in the overlay is assigned a numeric Node-ID for the lifetime of the node which determines together with the specific overlay algorithm in use its position in the graph and the set of nodes it connects to. The Node-ID is also tightly coupled to a certificate. Figure 2.8 shows a trivial example of RELOAD overlay included in [44]. RELOAD defines two different types of nodes: - Peer: A host that is participating in the overlay. Peers are responsible for holding some portion of the data that has been stored in the overlay and also route messages on behalf of other hosts as required by the overlay algorithm. - Client: A host that is able to store data in and retrieve data from the overlay but does not perform routing or data storage for the overlay.

80 2.4. REsource LOcation And Discovery (RELOAD) Node Node Node Node Node Node Node Node Node Node 85 (Client) Figure 2.8: Trivial example of RELOAD overlay Operations As a P2P protocol, RELOAD defines a set of operations for joining, leaving, and maintaining the overlay. There are also operations for storing and retrieving data. In addition, RELOAD defines two new operations for interacting with other overlay nodes: Attach and AppAttach. Attach allows nodes to establish a direct TCP or User Datagram Protocol (UDP) connection to other overlay nodes. This connection is a direct channel between two Nodes exchanging RELOAD messages. AppAttach is similar to Attach, but in this case nodes use the generated connection for exchanging application data (and not RELOAD traffic). In this sense, one of the parameters of AppAttach is the Application-ID, which identifies connection s target application. RELOAD nodes send both Attach and AppAttach requests using the destination Node-ID (and not the IP address). In this sense, RELOAD allows nodes for establishing direct connections to any member of the overlay. This is feasible even if the target node is behind a NAT.

81 50 Chapter 2. Background Resource-ID Kind 1 Kind Value Value Value Value Value Data storage Figure 2.9: Example of data stored in RELOAD. RELOAD references the location of the data stored in the overlay by using an identifier which is known as Resource-ID, and its format depends on the particular DHT algorithm the overlay uses. Each location in the overlay may contain data elements corresponding to multiple Kinds. In addition, a resource location may contain multiple elements of a given Kind. Each Kind is identified by a Kind-ID, which is a code point either assigned by Internet Assigned Numbers Authority (IANA) or allocated out of a private range. Figure 2.9 depicts an example of resource location [44]. The RELOAD specification defines the following data models for storing data, though developers can define their own structures as part of a new RELOAD usage: single value: There can be at most one item in the set and any value overwrites the previous item. array: Many values can be stored and addressed by a numeric index. dictionary: The values stored are indexed by a key. Often this key is one of the values from the certificate of the peer sending the Store request.

82 2.5. Constrained Application Protocol (CoAP) Usages RELOAD s original usage was focused in providing a rendezvous service for SIP. In this way, communicating peers use RELOAD for establishing a connection, and then they perform the usual SIP negotiation [43]. There are other RELOAD usages like [42], which allows federating different SIP domains; or [27], which enables for managing the RELOAD overlay using Simple Network Management Protocol (SNMP). However, there is still no usage for supporting DDS. 2.5 Constrained Application Protocol (CoAP) CoAP [97] is an ongoing IETF protocol specification. The working group responsible of its specification is the Constrained RESTful Environments working group (CoRE WG) [38]. According to the current IETF draft [97], CoAP is a specialized web transfer protocol for use with constrained nodes and constrained (i.e., low-power, lossy) networks. CoAP provides a request-response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP can be used not only between nodes on the same constrained network, but also between constrained nodes and nodes on the Internet. The latter is possible since CoAP can be translated to HyperText Transfer Protocol (HTTP) for integration with the web. Application areas of CoAP include different forms of Machine-to-Machine (M2M) communication, such as home automation, construction, health care or transportation. Areas with heavy use of sensor and actuator devices that monitor and interact with the surrounding environment. Although CoAP is conceived for using a request-response interaction model, [29] specifies a simple protocol extension for CoAP that enables CoAP clients to subscribe to certain resources. Once a client subscribes to a particular resource, the corresponding server will send notifications upon changes on the subscribed resource.

83

84 Chapter 3 DDS data-space Interconnection Service (DDS-IS) In this chapter, we consider the problem of communicating disjoint data-spaces that may use different schemas to refer to similar information. In this regard, we propose a DDS interconnection service capable of bridging DDS domains as well as adapting between different data schemas. These features constitute a first step for deploying DDS in large-scale deployments. A key benefit of our approach is that is compliant with the latest OMG specifications, thus the proposed service does not require any modifications to DDS applications. The chapter identifies the requirements for DDS data-spaces interconnection, presents an architecture that responds to those requirements, and concludes with experimental results gathered on our prototype implementation. 3.1 Motivation DDS was originally designed for isolated LANs in which data sources (publishers) and data consumers (subscribers) are located in the same geographical location. Problems arise if a subscriber has interest in data being originated in a different data-space, especially if that data-space is separated by a bandwidth-constrained network. This is the case of a company that relies on DDS for delivering some data-

85 54 Chapter 3. DDS data-space Interconnection Service (DDS-IS) content internally, and needs to share a subset of that data-content with another company. A simplistic solution to the previous use case would be to merge the two dataspaces. That is, to implement a service that publishes and announces all the topics from one data-space to the other. However, the direct merging of the data-spaces would create some significant problems. The first problem is related to scalability. Every publication available in one data-space will be indiscriminately announced in the other data-space. This may be wasteful in resources in situations where there are no consumers to that information on the second data-space. Other problems are concerned to data compatibility. For instance, each dataspace may have its own (possibly different) data model (i.e., data names, types, and/or definitions). These models could be incompatible even if they refer to the same data items. For example, temperature data might be expressed in Celsius in one data-space and in Fahrenheit in the other one. Therefore, in order to keep the end-to-end application logic unchanged, data should be automatically transformed by the publish-subscribe infrastructure when bridging data-spaces with different data models. As an additional benefit, this will ease the integration between new and legacy DDS applications. Access control and information confidentiality adds another dimension to this problem: Some parts of the data should be confined in a data-space whereas other data should be public. Finally, another relevant issue is related to the possibility of having different delivery requirements for the information that flows between and within the different interconnected data-spaces. For example, system administrators should be able to establish the QoS requirements that domains must meet in order to be bridged. In this chapter we propose a novel solution for inter-domain entity and data-type signaling, and data-content exchange in DDS environments. Our solution, named DDS-IS, is fully compatible with the current DDS standard specification and allows for advanced content-centric operations, like content-based filtering and data transformations. DDS-IS establishes a content-aware interconnection service between different data-spaces with the following distinctive features: a) Scalability. The overall traffic load is drastically reduced in comparison with direct data-space merging; b) Data model compatibility and confidentiality. The seamless communication between data-spaces with dissimilar data models (topics of different names or data-

86 3.2. Motivating use case example 55 types) was not possible so far. DDS-IS solves this issue by properly transforming and/or isolating topic samples, if necessary. c) Delivery guarantees. DDS-IS establishes QoS requirements for bridged dataspaces; d) Standards compliance. The design of DDS-IS is fully compliant with the OMG DDS specification, hence it is implementation agnostic. e) Performance. Conducted experiments demonstrate that the impact of the proposed service on communications performance is well within the acceptable limits for most real-world uses of DDS. The remainder of the chapter is organized as follows. In Section 3.2 we present a motivating use case scenario for the proposed service. In Section 3.3 we identify the service requirements. In Section 3.4 we describe the proposed DDS-IS architecture. In Section 3.5 we study the interactions among DDS-IS architectural elements. In Section 3.6 we include relevant implementation details. In Section 3.7 we address the conducted experiments and analyze the obtained results. In Section 3.8 we conduct a study of the impact of the service in DDS QoS policies. Finally, in Section 3.9 we summarize the main conclusions of our work and discuss some open issues that are treated in next chapters. 3.2 Motivating use case example DDS is a middleware for solving information sharing and data-exchange on realtime distributed systems. In this sense, DDS-based solutions are often deployed in industrial and mission critical applications. Two problems associated to these deployments are system heterogeneity and scalability. As systems grow in complexity, incompatibility problems arise among different software versions or among applications of different providers. In the same way, the natural evolution of enterprises generates scalability problems, and it is necessary to support bigger scenarios, perhaps even deployed among distant locations. From these problems, it emerges the need of defining DDS bridging service that improves DDS scalability and eases the interoperation of heterogeneous DDS-based applications. To identify the requirements of this service, we now detail a motivating scenario that requires the functionality of a DDS bridging service. Figure 3.1 includes an example deployment scenario for the DDS-IS. Specifically, this example shows how DDS-IS can be used in an olive oil factory. Although

87 56 Chapter 3. DDS data-space Interconnection Service (DDS-IS) Figure 3.1: Example deployment scenario. other scenarios are possible, this example illustrates the functionalities of the proposed service. The olive oil factory in our example generates data-content in two different environments, namely centrifugation system and storage system. In addition, there is a third environment (accounting and general supervision system) that stores the most relevant data-updates. Decanter centrifugation is the part of olive oil production that separates olive oil from vegetation water and solid materials. In order to produce high quality oil, operators must control the centrifugation speed, centrifuge temperature, and oil density. The centrifugation system of our example has three centrifuges. Each one publishes viscosimetric information and temperature information (with a ratio of one update per second). Each centrifuge is also subscribed to two topics: one for controlling centrifugation speed, and other for controlling the input and output valves. A local coordination node controls the decanter centrifugation system, by subscribing to temperature and viscosimetric topics, and controlling centrifuge speed and valves. Storage is the part of olive oil production where the oil is stored until its bottling and distribution. In order to conserve the quality of the oil, the system must monitor

88 3.3. Requirements 57 the pressure, temperature, humidity and light exposure of the storing tanks. In our example, we have assumed three oil tanks. Each one of these tanks publishes pressure, temperature, humidity, and light exposure information (with a rate of one update per second), and subscribes to a valve control topic (i.e., three publishers per topic for a total of 14 publishers, and three subscribers). A local coordination node controls the valve status, and monitors published metrics (using four different subscribers and one publisher). Local coordination node can react to received values if necessary (for example, by activating a refrigeration system). Although the generated data-content is mainly useful within its associated system (centrifugation or storage), the administrators of this factory want to store the most relevant events of each system in a central data-base, generating alerts if certain trigger values are reached. However, administrators do not want to modify either the current sensor deployment or the local coordination nodes logic. Moreover, it is desirable to keep the data-content of each system isolated (in order to avoid overflowing local networks with unnecessary information). Figure 3.1 presents a solution to the described scenario requirements. In particular, this solution is based on deploying two DDS-IS nodes: one for bridging and filtering data-content from the storage system (i.e., from LAN A to LAN C), and the other for bridging and filtering data-content from the centrifugation system (i.e., from LAN B to LAN C). Using this deployment, DDS-IS nodes bridge only relevant data-samples to the accounting and general supervision system, while they avoid overflowing storage and centrifugation systems with unnecessary updates. 3.3 Requirements From the previous example, we identify the following requirements that are not currently covered by DDS, and which the proposed service must fulfill: R1: Domain bridging. DDS-IS must connect different DDS data-spaces. These data-spaces are groups of publishers and subscribers that exchange data using compatible DDS middleware implementations and transport configuration. R2: Topic bridging. DDS-IS must connect different DDS topics. A topic has associated a data-type. Consequently, in order to bridge different topics our service must be able to adapt data-samples between different data-schemas. R3: Type-based transformations. In order to adapt data-samples between different data-schemas, DDS-IS must be able to perform type-based data transformations. As an additional requirement, the service must allow users for defining their own transformations.

89 58 Chapter 3. DDS data-space Interconnection Service (DDS-IS) R4: Content-based filtering. DDS-IS must be able to use samples content for determining if a sample should be bridged, or silently dropped such that it does not flow through the bridge. R5: QoS policies consistence. DDS-IS must be compatible with existent DDS QoS profiles. DDS-IS must allow administrators for establishing what QoS requirements domains must met in order to be bridged. The service must ensure that the QoS policies of the interconnected entities are fully compatible with the ones configured for the DDS-IS. In addition, DDS-IS must allow administrators for integrating dataspaces with different (perhaps even incompatible) sets of QoS. R6: Transparency. DDS-IS must not require modifications to existing DDS applications. This feature will enable legacy and new DDS applications to communicate through the proposed service. In this sense, our service will be an interoperability solution for connecting dissimilar data-spaces. R7: Standards compliance. DDS-IS must be compliant with DDS standards family. This will ensure the interoperability of the service with any DDS-compliant middleware implementation. R8: Performance and scalability. DDS-IS must have a low impact on DDS applications performance, mainly in terms of latency overhead. In addition, the system should improve DDS deployments scalability in terms of overall network traffic load. R9: Information confidentiality. DDS-IS must provide mechanisms for filtering out sensitive information from bridged data-samples. Specifically, DDS-IS must be able to use data-samples content for determining what data-samples should be discarded (this functionality is covered by R4). DDS-IS must also be able to selectively filter specific data-sample fields (instead of the whole sample) using the functionality covered by R3. In the following section we describe the architecture of our system, which satisfies the identified requirements. 3.4 Internal architecture DDS-IS architecture adopts a layered design based on the following motivations. First, it increases system modularity, by allowing the specific implementation of each layer to be changed without impacting the rest of the layers. Second, it allows existing applications to remain independent of new proposed DDS-IS entities while benefiting from the service.

90 3.4. Internal architecture 59 App/User Node 1 App/User Node 2 App1 App2 DDS-IS Node App3 App4 Application Layer Routing Engine Routing Layer Data Distribution Service Middleware Data Distribution Service Middleware Data Distribution Service Middleware Pub/Sub Layer Network Layer Figure 3.2: Layered DDS-IS architecture. And third, it simplifies the overall understanding of the system, because it classifies entities of different functionality in different layers. Figure 3.2 depicts the architecture of our solution. It can be seen as composed of a set of components located on different nodes. The components of each node are arranged in four layers, namely, application, routing, pub/sub, and network layer. In the following subsections we explain the functionality of each layer and its contained components Application layer The application layer is the topmost layer of our architecture, and it is populated by DDS applications. These applications exchange information through DDS dataspaces by means of the underlying DDS middleware. In our design, entities on this layer do not communicate directly with the routing layer. Instead, applications exchange data through the pub/sub layer using the existing standard DDS API (i.e., in the same way as if the DDS-IS was not present). This feature allows applications to remain independent of the DDS-IS, and therefore they do not require any changes. DDS-IS operation is totally transparent to the application layer. From the perspective of application layer entities, the only noticeable change is the increase in the data-content that they can access. This is because the DDS-IS enables the interoperation of applications associated with different data-spaces (i.e., different DDS

91 60 Chapter 3. DDS data-space Interconnection Service (DDS-IS) domains), virtually combining the content of the involved data-spaces. The DDS-IS also enables applications with different data models to exchange data-content. This is provided by the ability of the DDS-IS to transform data on the fly. Again, these transformations are independent of the application layer, and therefore existing applications require no modifications for benefiting from the interconnection service. As we have stated before, our solution does not modify the interactions between applications and DDS data-spaces. This is also valid for DDS compatibility checks. In this sense, if a DW (e.g. an application DW) and a DR (e.g. a DDS-IS DR) determine that they are not fully compatible (by performing the necessary DDS discovery-checks), they will not start exchanging data-content. Consequently, in order to bridge two applications with different data-types, or associated to different data-spaces, the DWs and DRs of the DDS-IS have to be properly configured. In the same way, the QoS profiles associated to bridged entities must be compatible with the QoS profiles configured for the DDS-IS. As we will discuss later in Section 3.6.5, DDS-IS administrators can configure the service for enforcing the same QoS configuration for the two interconnected data-spaces. Alternatively, system administrators can configure DDS-IS for integrating two domains with different (perhaps even incompatible) sets of QoS policies Routing layer The routing layer is the core of our design. This new layer extends the functionality of the DDS specification: it allows for bridging DDS information between different DDS domains (i.e., between DDS data-spaces). It enables information flow across different DDS topics, optionally transforming and filtering the exchanged data. As a result, from the application layer perspective, two different (perhaps even remote) data-spaces appear as a single (and extended) DDS data-space. This functionality is provided by the Routing Engine (see Figure 3.3), which contains the following components: Discovery Monitor: This component processes the discovery events generated by the underlying DDS middleware (i.e., by B-DRs). Whenever a change occurs in the DDS discovery information, the DDS middleware notifies the Discovery Monitor. The Discovery Monitor then retrieves the received discovery information from B-DRs and delivers it to the proper Domain Route. Data Engine: This component controls one or more DRs and DWs in the pub/- sub layer. The Data Engine has two missions. First, it takes received data samples from the pub/sub layer, and pushes those samples to the proper Topic Route. Sec-

92 3.4. Internal architecture 61 Routing Engine Domain Route Transformation Extensions Auto Topic Route Transformation Engine Topic Topic Topic Route Route Route Configuration and QoS Manager Discovery Monitor Data Engine Data Distribution Service Middleware Figure 3.3: DDS-IS Routing Engine. ond, it delivers resulting samples (from Topic Routes) to DWs so that they can be published. There is one Data Engine associated with each Domain Route. Domain Route: A mapping between two different DDS domains (i.e., dataspaces). A Domain Route contains multiple Auto Topic Routes and Topic Routes. The Domain Route interacts with the Discovery Monitor in order to obtain discovery information from a set of B-DRs in the pub/sub layer. After receiving discovery updates from the Discovery Monitor, the Domain Route triggers the creation of DDS and DDS-IS entities according to the service configuration. A DDS-IS instance can contain multiple Domain Route instances, each bridging a pair of DDS domains. Topic Route: A mapping between an input topic (i.e., the topic from where the DDS-IS receives data) and an output topic (i.e., the topic where the DDS-IS pub-

93 62 Chapter 3. DDS data-space Interconnection Service (DDS-IS) lishes data). Therefore, a Topic Route is defined by an input topic name and type, and an output topic name and type. Additionally, a Topic Route can apply transformations to data-samples using the Transformation Engine (explained below). The behavior of a Topic Route is as follows: first, it receives data from its associated Data Engine; then, it applies transformations (if any); and finally, it delivers processed data to the Data Engine for publication. A Domain Route instance can contain multiple Topic Route instances, each one bridging a pair of DDS topics. Transformation Engine: This element receives input data samples from a Topic Route, applies a set of transformations to those samples, and returns the resulting data samples. If a Topic Route requests for multiple transformations, the Transformation Engine processes them in sequence and following a predefined order (this is important because the output of a transformation and the input of the subsequent transformation must be type-compatible). Supported transformations are defined through multiple Transformation Extensions. Transformation Extension: This element receives input data samples, applies a transformation to those samples, and returns the result of the transformation. To be able to process data of any type, Transformation Extensions use DDS Dynamic Topic Types. In order to increase system flexibility, A DDS-IS instance can contain multiple Transformation Extension instances, each one describing a particular data transformation. Transformation Engine can load external Transformation Extensions implemented by DDS-IS users. Auto Topic Route: A generic Topic Route that bridges a range of topics. The topic name and type for bridged topics need not be known a priori, and therefore Auto Topic Route provides auto-configurable topic bridging. Auto Topic Routes are configured with a subset of topic names and/or topic types for which the automatic setup is allowed. A Domain Route instance can contain multiple Auto Topic Route instances, each one covering a different set of topics. Configuration and QoS Manager: Following the philosophy of the DDS standard, our design relies on a set of QoS policies for configuring the behavior of routing layer elements. Indeed, some of these QoS policies also control the configuration of entities belonging to the DDS core layer (for example, Topic Route QoS profiles also control the configuration of the associated DW and DR). The Configuration and QoS Manager is the component that controls the proper configuration of the DDS-IS Pub/Sub and network layers The pub/sub layer (see Figure 3.2) contains the entities associated to the DDS middleware (described in Section 2.2.1), and interacts with system s upper layers using

94 3.5. System operation 63 the standard DDS API. The pub/sub layer allows the DDS-IS to access to DDS data-spaces. In order to provide this functionality, the pub/sub layer perform the following tasks: (1) it notifies the routing layer about changes in discovery information, (2) it receives new data samples and delivers these samples to the routing layer, and (3) it publishes data obtained from the routing layer to DDS data-spaces. In addition to the entities already introduced in Section 2.2.1, this layer includes two DDS WaitSets. A DDS WaitSet is an standard DDS entity that can be used to wait for specific DDS Events. DDS WaitSets are awaken whenever certain predefined trigger conditions are met. Specifically, our system uses the following two DDS WaitSets: Discovery WaitSet: This element receives updates from B-DRs (see Section 2.2.1). It notifies the Discovery Monitor in the routing layer when a change occurs to discovery. This allows the DDS-IS to react to the appearance and disappearance of entities to/from the connected data-spaces. Data WaitSet: This element notifies its associated Data Engine in the routing layer about the reception of new data samples in one of its DRs. This allows the DDS-IS to process DDS samples from the DDS core layer as soon as they are received. The network layer is the lowest layer of the proposed architecture (see Figure 3.2). It represents the platform-dependent components that are necessary for exchanging data-samples (such as the operating system, computer hardware, or communication network). One of the advantages of using a network middleware (such as DDS) is that it decouples the application logic from the particularities of the network layer. Consequently, we do not need to define any requirements for this layer, except that the chosen DDS implementation must be DDS-RTPS-compliant. 3.5 System operation In order to illustrate the interactions among the previously described entities, in this section we provide sequence diagrams for the two main system use cases.

95 64 Chapter 3. DDS data-space Interconnection Service (DDS-IS) Pub/Sub Routing DDS Discovery Monitor Domain Route AutoTopic Route Topic Route Data Engine Notify Discovery Event Get Discovery information Delivery Discovery Samples [New Information] Update Discovered Topics or Entities [MATCH AUTO TOPIC ROUTE] Create Topic Route [MATCH TOPIC ROUTE] Start Topic Route <<create>> Topic Route Create DDS Entities [Not started] Create DDS Entities Figure 3.4: Discovery sequence diagram Discovery of new DDS entities DDS discovery notifies DDS-IS about the creation or deletion of DDS entities in any of the interconnected domains. This information enables DDS-IS to react to the changes in the input and output data-spaces. The sequence diagram of the discovery procedure is depicted in Figure 3.4. Specifically, this sequence diagram describes how the discovery of DDS entities trig-

96 3.5. System operation 65 gers the initialization of a Topic Route and all its associated entities. A B-DR initiates the process when it receives a change in the discovery information of a DDS entity located in the same data-space (but associated to a different node). This event triggers a Discovery WaitSet (studied in Section 3.4.3), which then sends a notification to the Discovery Monitor. Once the Discovery Monitor receives a discovery notification, it retrieves the nature of the originating B-DR (participant, publication or subscription), and the discovery information received by the B-DR. At this point, the Discovery Monitor delivers all the received discovery samples to the Domain Route associated to the originating B-DR. Received samples can contain multiple changes in the discovery, which are processed separately. These changes can refer either to the creation or removal of remote DDS entities. Using the received information, the Domain Route updates an internal register that stores information of previously discovered DDS entities and topics. This register enables the DDS-IS for determining if it is necessary to create new Topic Routes upon the reception of discovery information. Then the Domain Route checks if any of its active Auto Topic Routes matches with the received discovery information. If necessary, the Domain Route creates new Topic Routes according to Auto Topic Routes configuration. Finally, the Domain Route checks the existing Topic Routes, and then determines if the discovered DDS entity is associated to any of them. If the Domain Route finds a matching Topic Route, the Domain Route will check if the Topic Route is already active. If the Topic Route is not active, the Domain Route starts the Topic Route (i.e., the Topic Route requests the Data Engine to create the necessary DR and DW for performing topic bridging) Data bridging Data Bridging is the process of communicating data-samples between two different DDS data-spaces. If the input and output data-spaces share the same topic, the DDS-IS can bridge data-samples without performing any modifications to datasamples structure. However, the DDS-IS can also bridge data-samples between two data-spaces that do not share the same data-model. In this case, the DDS-IS must transform input data-samples for adapting them to the format required at the output data-space. Figure 3.5 depicts the sequence diagram of the data bridging process. A DR (located in the pub/sub layer) initiates the process when it receives a new data-

97 66 Chapter 3. DDS data-space Interconnection Service (DDS-IS) Pub/Sub Routing DDS Data Engine Topic Route Transformation Engine Transformation Extension Notify Data Reception Get Data Deliver Data to proper Topic Route Apply Transformations Apply Transformation Publish Data Publish Data Figure 3.5: Data bridging sequence diagram. sample from a DW located in the same data-space (but in a different node). This event triggers a Data WaitSet, also located in the pub/sub layer, which then sends a notification to the Data Engine associated to the DR. After receiving the notification from DDS, the Data Engine retrieves all of the received samples from the originating DR, and delivers those samples to the Topic Route associated to that DR. At this point, the Topic Route applies configured transformations (if any) to the input data-samples (using the Transformation Engine). Data Bridging then finishes with the publication of resulting data-samples to the output data-space by means of the proper Data Engine s DW (located in the pub/sub layer).

98 3.6. Implementation Implementation After defining the DDS-IS architecture and its design, we have implemented a proofof-concept prototype. This prototype was used to validate the proposed design, to perform field-testing, and to evaluate the performance impact of our service (for further information regarding conducted experiments and obtained results, please refer to Section 3.7). In this section, we explain the most relevant implementation decisions that we have taken during the prototype development Dynamic types As we studied in Section 2.2.4, the DDS-XTypes API allows DDS applications to publish and subscribe topics with types unknown at the time the application was compiled. Since DDS-IS needs to interact with DDS applications not known a priori (including DDS applications to be developed in the future), the DDS-IS makes an extensive use of the DDS-XTypes API in order to discover and manipulate previously unknown data types, including performing any necessary data transformations DDS middleware implementation The DDS-IS prototype was implemented using Real Time Innovations Inc. (RTI) s DDS version 4.4d [88]. We have chosen this implementation because it supports the DDS Dynamic Topic Types extension. This extension is a new API for the DDS standard family that was recently standardized by the OMG [70]. Nevertheless, our design is implementation-independent, as it only uses standardized DDS features plus the DDS Dynamic Topic Types extension. Consequently, the proposed design can be implemented using any other DDS-compliant implementation. Indeed, the implemented prototype is also compliant with the DDS-RTPS [69]. Regarding the used programming language and bindings, we have implemented our prototype in C, and we have compiled the source code using gcc version DDS signaling propagation As we have mentioned, a Topic Route connects an input data-space s topic (i.e., a set of application DWs) with an output data-space s topic (i.e., a set of application

99 68 Chapter 3. DDS data-space Interconnection Service (DDS-IS) DRs). To enable the interoperation of these DWs and DRs, the DDS-IS must create both a DR at the input domain and a DW at the output domain. In this scenario, the question naturally arises: when should the service create the input/output DR/DW? The answer to this question depends on the particular application requirements. If system resources (memory and CPU) are scarce, DDS-IS should not create the paired DW-DR until a match between the input topic and the output topic is found (i.e., both the matched DR and DW have been discovered). However, if we need all of the DDS signaling information (i.e., DDS discovery information) to propagate through the DDS-IS, the service should create both the DR and DW as soon as a matched publication or subscription is discovered. Alternatively, it may be preferable for the system to set up Topic Route s entities as soon as the user configures a Topic Route (even if the DDS-IS does not find any matching DWs or DRs). In order to support scenarios with different requirements and constraints, we decided that the prototype should allow the user to configure the triggering conditions for the creation of Topic Route s entities. In Section 3.6.6, we provide an example of how to configure the creation for the input and output of a Topic Route Propagating DataWriter information By default, DDS middleware generates an unique IDentifier (ID) (using hosting machine information and implementation specific parameters) for each DW. In the early stages of DDS-IS prototype implementation, this was also the behavior of the service. However, after some testing we concluded that this behavior prevents application DRs from distinguishing between original data-samples and replicas of those data-samples. The ability of distinguishing between original data-samples and their replicas is especially critical for deployments with redundant DDS-IS nodes. In these scenarios, this functionality may significantly impact system resources consumption, given that it avoids the delivery of duplicated samples to final applications. Consequently, we decide to enable the DDS-IS to maintain the original DW information, which is contained in input data-samples. The implemented prototype allows configuring if the original DW information is maintained, or if it is replaced by the DDS-IS DW information. In this way, the DDS-IS administrator is able to configure the system behavior according to the specific scenario requirements.

100 3.6. Implementation Quality of Service As we described in Section 3.4.2, DDS-IS relies on DDS QoS profiles for configuring the behavior of the service. Consequently, DDS-IS also relies on DDS built-in compatibility-checking mechanisms for ensuring that QoS profiles of communicating entities are fully compatible. DDS-IS QoS checking is performed on a hop-by-hop basis (i.e., between DDS-IS entities and application entities located within the same domain). This feature allows system administrators for decoupling QoS for different domains, enabling the integration of heterogeneous (and perhaps even incompatible) scenarios. Of course, administrators can configure the same QoS policies for the two interconnected domains, which guarantees that QoS remain invariant across interconnected data-spaces. Regarding QoS enforcement, DDS QoS policies were initially intended for working within single domains. Consequently, the behavior of DDS QoS policies in DDS-IS-based deployments is currently unknown. In this regard, in Section 3.8 we include an analysis of the impact of DDS-IS on each DDS QoS policy XML configuration format The DDS-IS uses extensible Markup Language (XML) files to load its configuration. XML is a set of rules for encoding documents. These rules are defined in the XML 1.0 Specification produced by the W3C [106]. Figure 3.6 provides an example of a basic XML configuration file; specifically, it includes the following XML tags: dds: The root of the XML document; it can also include the definition of QoS policies for the system. dds is: This tag includes the configuration of a DDS-IS instance. every other DDS-IS should be included as a child of the dds is tag. Therefore, domain route: This contains the configuration for a Domain Route and must contain a participant 1, a participant 2, and a session tag. participant 1 and participant 2: These tags define the input and output DDS domain for the service using the domain id tag. session: This contains the configuration for a set of Topic Routes and Auto Topic Routes that share the same Data Engine instance. Session tag can contain multiple topic route and auto topic route tags.

101 70 Chapter 3. DDS data-space Interconnection Service (DDS-IS) <?xml version="1.0"?> <dds xmlns:xsi=" xsi:nonamespaceschemalocation="../schema/dds_is.xsd"> <dds_is> <domain_route name="defaultdomainroute" enabled="true"> <participant_1> <domain_id>0</domain_id> </participant_1> <participant_2> <domain_id>1</domain_id> </participant_2> <session name="defaultsession" enabled="true"> <auto_topic_route name="all" enabled="true"> <publish_with_original_info> true </publish_with_original_info> <publish_with_original_timestamp> true </publish_with_original_timestamp> <input participant="1"> <creation_mode>immediate</creation_mode> </input> <output> <creation_mode>immediate</creation_mode> </output> </auto_topic_route> </session> </domain_route> </dds_is> </dds> Figure 3.6: XML configuration file example.

102 3.7. Validation and performance evaluation 71 auto topic route and topic route: The system uses these tags to set up the Auto Topic Routes and Topic Routes. publish with original info: This determines if the DDS-IS maintains the original DW information for publishing data to the output. publish with original timestamp: This determines if the DDS-IS maintains the original timestamp information for bridged data-samples. input: This defines the configuration of the route input. It allows configuring filters for topic routing, the QoS policies for the input DR, and the creation mode, which is defined below. output: This defines the configuration of the route output. It allows configuring filters for topic discovery at the output, the QoS policies for the output DW, and the creation mode, which is defined below. creation mode: This configures the way discovery information is propagated from the input to the output (or vice versa). In this way, when a DR is discovered at the output, the system can set up the corresponding Topic Route immediately (as in the example) or wait until a DW is discovered at the input. 3.7 Validation and performance evaluation To study the operation and performance of the DDS-IS prototype, we conducted a set of experiments in a controlled LAN environment. Specifically, we measured the impact of the DDS-IS in terms of round-trip latency, throughput, and network traffic load Experimental set-up The test-bed was composed of six Core i5 at 2.40GHz-2.66GHz machines (named lab01, lab02, lab03, lab04, lab05, and lab06) running Linux Kernel x86 64 (Ubuntu 10.04) and the RTI DDS 4.4d middleware. These machines communicate through a 24-port Gigabit switch with Virtual Local Area Network (VLAN) support. In our experiments, these nodes receive one of three possible roles: Source-node: A node that generates DDS samples, receives responses for those samples, and calculates experimental statistics. Echo-node: A node that receives DDS samples from source-nodes and generates responses.

103 72 Chapter 3. DDS data-space Interconnection Service (DDS-IS) Routing-node: A node that bridges two different networks. We developed a benchmarking tool for conducting our experiments. This benchmarking tool consists of two components: PerformanceTest tester: This application runs in the source-nodes. It publishes samples into a topic called Ping and receives them from a subscribed topic, called Pong. Ping samples contain a sequence number, the publication timestamp, and a variable size payload as well. The structure complexity of Ping payload is variable. Pong samples only contain a sequence number and the original Ping publication timestamp. This timestamp is compared with the sample reception time for obtaining samples round trip time. Each Ping and Pong sample is sent in a separate message. PerformanceTest remote: This application runs in echo-nodes. It takes samples from the Ping topic and republishes their sequence number and timestamp field content into the Pong topic. In the conducted tests, published samples performed a round trip between source-nodes and echo-nodes. This approach allows for the precise measurement of the sending and reception times without performing any clock synchronization. Consequently, at least two different routes have to be configured in the DDS-IS: the outgoing route (for bridging Ping samples) and the incoming one (for bridging Pong samples). For all the reported evaluations, our benchmarking tool uses RTPS over UDP protocol, and sends each sample separately (i.e., each UDP datagram contains only one RTPS sample). Regarding sample sizes, Ping samples contain a payload whose size ranges from 256 to 8192 bytes and a protocol overhead of 118 bytes. Pong samples have the same protocol overhead as Ping samples, but their payload has a size of 12 bytes because they only contain a sequence number and a timestamp. We considered the following metrics for the DDS-IS performance evaluation: Throughput: The average number of samples per time interval (seconds) received from the data-space by subscribers. Round-trip Latency: The average end-to-end elapsed time for delivering samples from the original source-node to the echo-node plus the elapsed time for delivering samples back to the original source-node. Our tool measures the latency at application level. In this sense, publishers measure the time before delivering data-samples to DDS middleware, whereas subscribers measure the time after DDS delivers data-samples to the benchmarking tool. Generated traffic load: The total generated traffic (in bytes) for a specific net-

104 3.7. Validation and performance evaluation 73 work segment in a particular scenario. This includes the payload plus all the overheads generated by the whole protocol stack. In order to evaluate the proposed service performance, we conduct all the experiments in two different scenarios. Namely, No-DDS-IS Scenario: Publishers and subscribers associated to source-nodes and echo-nodes were located in the same data-space, but in different networks. DDS entities communicate through one or more Layer-3 Linux Routers. DDS-IS Scenario: Publishers and subscribers associated to source-nodes were located in a different data-space (also in a different network) than the ones associated to echo-nodes. DDS-IS interconnects the involved data-spaces. In both scenarios, samples were published using the DDS Reliability QoS policy set to RELIABLE, which guarantees that the data sent by DWs is received by DRs. Additionally, we have configured the QoS policy KEEP_HISTORY to ALL_HISTORY, which guarantees no sample is dropped from DDS buffers. This configuration will force the DDS middleware to ensure the delivery of all the samples. However, it can cause that few samples have an extremely high latency, potentially biasing the average results. In this respect, the reported results only include the 95th percentile latency. As part of the RELIABLE Reliability QoS configuration, DW send heartbeat messages to their DR. Each heartbeat message contains the sequence number of the most recent sample sent by the DW. We have set DDS DR heartbeats low-period (i.e., the one used when DRs cache has less than 5 samples) to 100 milliseconds, and we have set DDS DR heartbeats high-period (i.e., the one used when DRs cache has more than 15 samples) to 10 milliseconds. We have also configured the DDS middleware for discovering DDS entities only in the interfaces of interest for each particular experiment. In this respect, all the experiments use a secondary network for launching the benchmarking tools without interfering on the tests. As we explained in Section 3.6, the DDS-IS prototype has been implemented using RTI s C API. On the other hand, the benchmarking tool has been implemented using C++. Regarding Linux kernel configuration parameters, we have used the default values associated to Ubuntu for all the machines.

105 74 Chapter 3. DDS data-space Interconnection Service (DDS-IS) ping ping pong pong LAN A LAN B Data Space 1 Data Space 2 Figure 3.7: DDS-IS scenario for 1 to 1 performance experiments. In the N to N case, lab01 and lab03 run multiple publishers and subscribers DDS-IS Impact in N to N communications In this section, we evaluate the impact of the DDS-IS in terms of round-trip latency and throughput for different payload (sample sizes), data types, and DDS-IS configurations when N publishers and N subscribers communicate following a 1 to 1 relationship. To make the results comparable, both no-dds-is and DDS-IS scenarios used the same network topology: two LAN networks (A and B) connected through a computer (lab02) with two Ethernet interfaces. In the no-dds-is scenario, lab02 is a single layer-3 Linux Kernel Router (we use just one data-space), whereas in the DDS-IS scenario, lab02 interconnects two different data-spaces and provides the proposed DDS-IS (see Figure 3.7). Each test consisted of publishing 500,000 samples per topic and using a specific payload size. These samples were published at source-node (lab01) into the Ping topic; after being received by Ping subscriber at echo-node (lab03), they were published back using the Pong topic. To avoid transitory behavior (warm-up) effects, before starting the tests we force some samples to be exchanged after the DDS entities discovery.

106 3.7. Validation and performance evaluation DDS-IS 1 to 1 No DDS-IS 1 to DDS-IS 1 to 1 No DDS-IS 1 to Latency (microseconds) Throughput (samples/s) ST 512B CT 512B CT 1024B ST 1024B CT 1024B ST 1024B CT 512B ST 512B Figure 3.8: DDS-IS impact for different data types in 1 to 1 communications Performance impact in simple 1 to 1 communications This first set of experiments aims at the evaluation of the performance impact for different data types and DDS-IS configurations when only one topic for Ping and one for Pong is active. Although the Pong topic was always the same, this experiment uses the following Ping topic types: SimpleType (ST) 512, 1024 bytes: These contain a sequence of random bytes, a sequence number, and a timestamp. ComplexType (CT) 512 bytes: This structure contains two levels of nesting. It includes a SimpleType (256 bytes) data, four 64byte-string fields (two of them in a nested struct), a long field, and eight Boolean fields. ComplexType (CT) 1024 bytes: This structure contains three levels of nesting. It includes two ComplexType-512 byte structs. Figure 3.8 shows the performance results of both no-dds-is and DDS-IS scenarios. In this experiment neither transformations nor filtering are enabled. The results show that although the DDS-IS introduces approximately a roundtrip latency overhead of 250 microseconds, it has no a significant impact on through-

107 76 Chapter 3. DDS data-space Interconnection Service (DDS-IS) DDS-IS 1 to DDS-IS 1 to Latency (microseconds) Throughput (samples/s) CT 1024B filt. CT 1024B transf. CT 1024B CT 512B filt. CT 512B transf. CT 512B CT 1024B filt. CT 1024B transf. CT 1024B CT 512B filt. CT 512B transf. CT 512B Figure 3.9: DDS-IS performance for filtering and transforming data. put. We can also conclude that in this case data complexity does not have a significant performance impact on DDS-IS scenario in comparison to no-dds-is scenario. Consequently, in the remainder experiments we focus our study on testing different sample sizes Performance impact of data transformation and filtering features The DDS-IS allows loading external data transformations and applying these transformations to the output data. In this sense, the performance degradation is highly dependent on the complexity of the transformation. Therefore, rather than reporting an exhaustive analysis, this section aims to evaluate the cost of using simple data transformations, which will show the overhead introduced by inclusion of an additional function call to the datapath. Figure 3.9 shows the incurred latency and throughput for a simple data trans-

108 3.7. Validation and performance evaluation 77 formation definition (labeled as CT size transf.). In particular, we have set up the DDS-IS for changing a long field and a Boolean field to a specific configured value. In this experiment, we observe that the complexity of the transformed structure degrades the throughput (see the obtained results for labels CT 512B transf. and CT 1024B transf.). However, simple transformations have no significant negative impact on latency. Indeed, for CT512 samples, using transformations reduces the average latency. This behavior is because the additional processing time introduced by transformations reduces the number of context switches in the routing-node Central Processing Unit (CPU), what reduces the average latency overhead. To test impact of data filtering we configured a filter that drops samples according to the content of the samples. Published samples are labeled with a number randomly obtained from a uniform distribution for the interval 0 to 999. The DDS-IS filters the samples according to the following definitions. For CT512 case (labeled in Figure 3.9 as CT 512B filt.) the filter was: (long_cond_00 < 500) or (nested_ping.sequence_number = ) Whereas for CT1024 case (labeled in Figure 3.9 as CT 1024B filt.) it was: (nested_complexping_02.long_cond_00 < 500) or (nested_complexping_01.nested_ping.sequence_number = ) The first condition on each filter drops approximately the 50% of the samples. The second condition ensures the warm-up signaling samples traverse the DDS-IS filter. According to the obtained results (see Figure 3.9), the filter introduces an average overhead of 110 microseconds when it uses a filtering condition on the first level of the type CT512, and 140 microseconds for evaluating the condition in a second level of nesting of the CT1024. In addition, DDS-IS approximately halves the throughput compared to a scheme without filtering, as expected from the fact that this filter drops 50% of the samples. This experiment validates the filtering and data transformation features of the DDS-IS. We can conclude that for the evaluated conditions DDS-IS accomplishes these tasks without a significant degradation of system performance Performance impact in N to N communications with multiple topics In this section, we study how DDS-IS affects performance as the number of concurrent distinct topics (and Topic Routes) increases.

109 78 Chapter 3. DDS data-space Interconnection Service (DDS-IS) In this case, we use the same topology of Figure 3.7 but now we increase the number of bridged topics (up to 16). We always use an even number because our benchmarking tool utilizes two types of topics: Ping for outgoing samples and Pong for incoming ones. This experiment is a worst-case scenario for the DDS-IS operation, as the capabilities of data multiplexing of DDS-IS are not used. Indeed, the DDS-IS has to maintain a pair of DR/DW per route. More particularly, the last case studied in this section creates 16 DWs and 16 DRs in the same DDS-IS. Although this is not an appropriate scenario of DDS-IS operation (multiple 1-1 routes), these experiments provide some insight on the DDS-IS limits. Figure 3.10 depicts the average round-trip latency as a function of the payload size. The results show that the DDS-IS performs reasonably well for samples with a size up to 6144 bytes when 2 to 16 concurrent routes (topics) are active. Specifically, the DDS-IS introduces an overhead from 250 to 400 microseconds for the round-trip latency. For the 8192-sized payload, the scenarios with 8 and 16 concurrent topics reveal a performance degradation. In these cases the round-trip latency overhead introduced by the DDS-IS increases to 450 microseconds and 1.3 ms respectively. Additionally, the standard deviation for round-trip latency reaches 2 ms, which indicates the DDS-IS performance degrades for this load level. Regarding throughput, the results in Figure 3.11 show that DDS-IS has an insignificant impact on the throughput for the scenarios with 2-4 concurrent topics. For the 8 and 16 topics cases, the DDS-IS throughput achieves at most 30,000 samples per second (for the 64-byte payload), whereas the scenario without DDS-IS reaches 50,000 samples per second in the 8-topic case, and almost 75,000 samples per second in the 16-topic case (both for the 64-byte payload). It is important to remark that in the 16-topic case the DDS-IS is publishing 30,000 samples in both directions (Ping samples from source-nodes to echo-nodes and Pong samples from echo-nodes to source-nodes). This is especially relevant in the 64-byte scenario, in which the size of Pong samples is similar to the size of Ping samples. In this scenario, while source-nodes and echo-nodes just manage one DW (for publishing Ping samples or for publishing Pong samples) and one DR (for receiving Pong samples or for receiving Ping samples), the routing-node has to manage a pair of DW/DR per topic. We have also measured the impact on CPU consumption for the routing-node (i.e., for lab02). Figure 3.12 shows that the maximum CPU consumption is obtained for the experiments using small packets, which are the ones with a highest rate of

110 3.7. Validation and performance evaluation 79 Latency (microseconds) No DDS-IS 2 Topics DDS-IS 2 Topics No DDS-IS 4 Topics DDS-IS 4 Topics No DDS-IS 8 Topics DDS-IS 8 Topics No DDS-IS 16 Topics DDS-IS 16 Topics Payload size (bytes) Figure 3.10: Average latency for different payloads and number of routes (topics) active. Throughput (samples/s) No DDS-IS 2 Topics DDS-IS 2 Topics No DDS-IS 4 Topics DDS-IS 4 Topics No DDS-IS 8 Topics DDS-IS 8 Topics No DDS-IS 16 Topics DDS-IS 16 Topics Payload size (bytes) Figure 3.11: Total average throughput for different payloads and number of routes (topics) active.

111 80 Chapter 3. DDS data-space Interconnection Service (DDS-IS) CPU % Data Size (Bytes) 2 Topics 4 Topics 8 Topics 16 Topics Figure 3.12: CPU impact for different payloads and number of routes (topics) active. samples per second. The obtained results also show that the degradation in performance for bigger sizes is not due to CPU saturation. Instead, it is mainly due to synchronization problems between the middleware and the used Ethernet interfaces, along with the increased cost of packet disassembling, assembling, and loss-recovery DDS-IS impact in M to N communications In the previous section, we studied the limits of the DDS-IS in a scenario where no data multiplexing is present. The following experiments analyze the performance of the DDS-IS when it delivers several copies of certain published data to multiple subscribers.

112 3.7. Validation and performance evaluation 81 ping pong pong ping ping LAN A LAN B ping ping Data Space 1 Data Space 2 Figure 3.13: System topology used in 1 to N performance experiments DDS-IS performance impact Figure 3.13 shows the topology used in this set of experiments. Specifically, we run a Ping topic publisher and a Pong topic subscriber on node lab01, a DDS-IS in node lab02 (for the no-dds-is scenario, IP forwarding was enabled at this node), and 0-4 subscribers in each of the nodes lab03, lab04, lab05, lab06. To avoid overloading the DDS-IS with Pong samples, only one Pong publisher at node lab03 publishes Pong samples back to lab01 (for measuring average round-trip latency and throughput on lab01 node). Figure 3.14 depicts average round-trip latency results obtained for this set of experiments. The obtained maximum overhead is 330 microseconds (for the bytes payload, 1 to 1 experiment). For the 4096-bytes, 1 to 4 case, the DDS-IS scenario obtains almost zero round-trip latency overhead (852 and 846 microseconds for the cases with and without DDS-IS respectively). Indeed, for a number of subscribers greater than 4, and a payload greater than 4096 bytes, we have obtained lower round-trip latencies values for the DDS-IS scenario than for the no-dds-is one. This is because the latency overhead introduced by the DDS-IS logic is offset by the reduction of the load on lab01 (the original publisher), the reduction of traffic in LAN A (this will be studied in next section), and

113 82 Chapter 3. DDS data-space Interconnection Service (DDS-IS) Latency (microseconds) No DDS-IS 1 to 1 DDS-IS 1 to 1 No DDS-IS 1 to 4 DDS-IS 1 to 4 No DDS-IS 1 to 8 DDS-IS 1 to 8 No DDS-IS 1 to 16 DDS-IS 1 to Payload size (bytes) Figure 3.14: Average latency for different payloads when demultiplexing data from 1 to N. Throughput (samples/s) No DDS-IS 1 to 1 DDS-IS 1 to 1 No DDS-IS 1 to 4 DDS-IS 1 to 4 No DDS-IS 1 to 8 DDS-IS 1 to 8 No DDS-IS 1 to 16 DDS-IS 1 to Payload size (bytes) Figure 3.15: Throughput per subscriber for different payloads when demultiplexing data from 1 to N.

114 3.7. Validation and performance evaluation 83 ping ping ping ping ping pong pong pong ping LAN A LAN C LAN B ping ping Data Space 1 Data Space 2 Data Space 3 Figure 3.16: System topology used in M to N scalability experiments. the fact that it is more efficient to re-send lost samples from lab02 (in the same LAN) than from lab01 (located at two hops). Regarding throughput, the results in Figure 3.15 show that the DDS-IS scenario beats the no-dds-is scenario for all the experiments with a number of subscribers greater or equal than 4. This is especially relevant for the 64-byte, 1 to 16 scenario, where the DDS-IS maintains a rate of 10,000 samples per second per subscriber, while in the no-dds-is case the rate drops to 5400 samples per subscriber. The explanation for this behavior is the same we stated for latency experiment: network usage reduction on LAN A, reduction of load for original source-node, and the fact that re-sending from lab02 is cheaper than re-sending from lab DDS-IS scalability impact Earlier in this chapter we stated that the DDS-IS can help in reducing the network traffic load. The following experiment (Figure 3.16) supports our claim. The experimental set-up consists of 1-4 Ping publishers (running on lab01), 1-15 Ping subscribers (uniformly distributed among lab04, lab05, and lab06), and two DDS-IS (running on lab02 and lab03). To avoid overloading the DDS-IS with Pong samples, only one Pong publisher at node lab04 publishes Pong samples back to lab01.

LINIO COLOMBIA. Starting-Up & Leading E-Commerce. www.linio.com.co. Luca Ranaldi, CEO. Pedro Freire, VP Marketing and Business Development

LINIO COLOMBIA. Starting-Up & Leading E-Commerce. www.linio.com.co. Luca Ranaldi, CEO. Pedro Freire, VP Marketing and Business Development LINIO COLOMBIA Starting-Up & Leading E-Commerce Luca Ranaldi, CEO Pedro Freire, VP Marketing and Business Development 22 de Agosto 2013 www.linio.com.co QUÉ ES LINIO? Linio es la tienda online #1 en Colombia

More information

INTELIGENCIA DE NEGOCIO CON SQL SERVER

INTELIGENCIA DE NEGOCIO CON SQL SERVER INTELIGENCIA DE NEGOCIO CON SQL SERVER Este curso de Microsoft e-learning está orientado a preparar a los alumnos en el desarrollo de soluciones de Business Intelligence con SQL Server. El curso consta

More information

Manejo Basico del Servidor de Aplicaciones WebSphere Application Server 6.0

Manejo Basico del Servidor de Aplicaciones WebSphere Application Server 6.0 Manejo Basico del Servidor de Aplicaciones WebSphere Application Server 6.0 Ing. Juan Alfonso Salvia Arquitecto de Aplicaciones IBM Uruguay Slide 2 of 45 Slide 3 of 45 Instalacion Basica del Server La

More information

FORMACIÓN E-LEARNING DE MICROSOFT

FORMACIÓN E-LEARNING DE MICROSOFT FORMACIÓN E-LEARNING DE MICROSOFT NANFOR IBÉRICA S.L PARTNER GLOBAL DE E-LEARNING DE MICROSOFT, único en Europa del Sur e Iberoamérica, y uno de los 9 existentes en todo el mundo. NOVEDADES EN LAS CERTIFICACIONES

More information

ICT education and motivating elderly people

ICT education and motivating elderly people Ariadna; cultura, educación y tecnología. Vol. I, núm. 1, jul. 2013 htpp://ariadna.uji.es 3 RD International Conference on Elderly and New Technologies pp. 88-92 DOI: http://dx.doi.org/10.6035/ariadna.2013.1.15

More information

CUSTOMER ENGAGEMENT & COMMERCE PORQUE EL CAMINO & EL RESULTADO IMPORTAN

CUSTOMER ENGAGEMENT & COMMERCE PORQUE EL CAMINO & EL RESULTADO IMPORTAN CUSTOMER ENGAGEMENT & COMMERCE PORQUE EL CAMINO & EL RESULTADO IMPORTAN NAME TITLE 2011 SAP AG. All rights reserved. 1 QUÉ SIGNIFICA CUSTOMER ENGAGEMENT AND COMMERCE? RELACIONARNOS CON NUESTROS CLIENTES

More information

Copyright 2010 EMC Corporation. All rights reserved.

Copyright 2010 EMC Corporation. All rights reserved. 1 Optimización de los sistemas de Backup / Recovery 2 Rediseño del Backup Tiered Build Out Consolidation Technology Refresh Backup Redesign Virtualization Adoption Improving Performance Archiving Improving

More information

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DOMINIOS DE COLISION, SEGMENTACION Y VLAN. Academia Local. Ing. José Martín Calixto Cely

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DOMINIOS DE COLISION, SEGMENTACION Y VLAN. Academia Local. Ing. José Martín Calixto Cely UNIVERSIDAD FRANCISCO DE PAULA SANTANDER DOMINIOS DE COLISION, SEGMENTACION Y VLAN Academia Local Ing. José Martín Calixto Cely COLLISIONS AND COLLISION DOMAINS Types of Networks Shared media environment

More information

Curriculum Reform in Computing in Spain

Curriculum Reform in Computing in Spain Curriculum Reform in Computing in Spain Sergio Luján Mora Deparment of Software and Computing Systems Content Introduction Computing Disciplines i Computer Engineering Computer Science Information Systems

More information

WEB SERVICES WEB SERVICES

WEB SERVICES WEB SERVICES From Chapter 19 of Distributed Systems Concepts and Design,4 th Edition, By G. Coulouris, J. Dollimore and T. Kindberg Published by Addison Wesley/Pearson Education June 2005 1 Topics Introduccion Web

More information

Management effectiveness evaluation: for the CBD and for better parks Principles for MEE Methodologies

Management effectiveness evaluation: for the CBD and for better parks Principles for MEE Methodologies Management effectiveness evaluation: for the CBD and for better parks Principles for MEE Methodologies Key question: How will the evaluation help management? Before choosing a methodology or undertaking

More information

New Server Installation. Revisión: 13/10/2014

New Server Installation. Revisión: 13/10/2014 Revisión: 13/10/2014 I Contenido Parte I Introduction 1 Parte II Opening Ports 3 1 Access to the... 3 Advanced Security Firewall 2 Opening ports... 5 Parte III Create & Share Repositorio folder 8 1 Create

More information

Cuánto se demora una pit stop?

Cuánto se demora una pit stop? Cuánto se demora una pit stop? The Internet of Things Connect Transform Reimagine Edgar Galindo Septiembre 2015 Version 1.0 2 Agenda The IoT Por qué nos debería importar? Optimice su cadena de valor a

More information

SIMO 2006 Sesion Técnica del ATI

SIMO 2006 Sesion Técnica del ATI SIMO 2006 Sesion Técnica del ATI Telelogic: Una compañía en la que puede confiar Financieramente Saludable En el mercado durante los últimos 22 años Crecimiento continuo en 2004/2005 Con beneficios, balance

More information

Resumen de Entrevista: Asociación de Agentes de Aduana del Puerto de Manzanillo

Resumen de Entrevista: Asociación de Agentes de Aduana del Puerto de Manzanillo Resumen de Entrevista: Asociación de Agentes de Aduana del Puerto de Manzanillo 1. To your knowledge, to what extent do customs brokers run into operative inconveniences when it comes to collecting payment

More information

ECCAIRS 5 Instalación

ECCAIRS 5 Instalación ECCAIRS 5 Instalación Paso a paso Preparado por: Arturo Martínez Oficina Regional Sudamericana Uniendo a la Aviación en Seguridad Operacional Seguridad Medioambiente Instalación Paso a paso Escenario Windows

More information

Por qué ExecuTrain? Por qué ExecuTrain? Modalidad de servicio

Por qué ExecuTrain? Por qué ExecuTrain? Modalidad de servicio Por qué ExecuTrain? ExecuTrain es un proveedor de entrenamiento corporativo a nivel internacional y líder mundial en la capacitación empresarial. Contamos con 22 años y más de 62 mil personas capacitadas

More information

Sales Management Main Features

Sales Management Main Features Sales Management Main Features Optional Subject (4 th Businesss Administration) Second Semester 4,5 ECTS Language: English Professor: Noelia Sánchez Casado e-mail: noelia.sanchez@upct.es Objectives Description

More information

What is the Common Problem that Makes most Biological Databases Hard to Work With, if not Useless to most Biologists?

What is the Common Problem that Makes most Biological Databases Hard to Work With, if not Useless to most Biologists? What is the Common Problem that Makes most Biological Databases Hard to Work With, if not Useless to most Biologists? RUNI VILHELM MRAG Americas, Inc. 110 South Hoover Blvd., Suite 212 Tampa, Florida 33609-2458

More information

Videocolaboración en la Nube. Una solución para CUDI

Videocolaboración en la Nube. Una solución para CUDI Videocolaboración en la Nube Una solución para CUDI Agenda 1. Introduction to Cloud Enablement for Video 2. Scopia Product line 3. Design and Deploy 4. Summary 2013 Avaya Inc. All rights reserved. 2 Soluciones

More information

A new MDA approach based on BPM and SOA to improve software development process

A new MDA approach based on BPM and SOA to improve software development process Revista de Estudos Politécnicos Polytechnical Studies Review 2008, Vol VI, nº 9 ISSN: 1645-9911 A new MDA approach based on BPM and SOA to improve software development process Miguel A. Sánchez Vidales

More information

ENVIRONMENT: Collaborative Learning Environment

ENVIRONMENT: Collaborative Learning Environment Guía Integrada de Actividades Contexto de la estrategia de aprendizaje a desarrollar en el curso: The activity focuses on the Task Based Language Learning (TBLL). The task is used by the student in order

More information

REOP. Vol. 15, N o 2, 2 o Semestre, 2004, pp. 5-11 ESTUDIOS FUND UTILISATON FOR GOODS AND SERVICES IN UNIVERSITY PRODUCTION UTILIZACIÓN DE FONDOS ECONÓMICOS DESTINADOS A BIENES Y SERVICIOS DE LA UNIVERSIDAD

More information

CONCEPTS OF INDUSTRIAL AUTOMATION. By: Juan Carlos Mena Adolfo Ortiz Rosas Juan Camilo Acosta

CONCEPTS OF INDUSTRIAL AUTOMATION. By: Juan Carlos Mena Adolfo Ortiz Rosas Juan Camilo Acosta CONCEPTS OF By: Juan Carlos Mena Adolfo Ortiz Rosas Juan Camilo Acosta What is industrial automation? Introduction Implementation of normalized technologies for optimization of industrial process Where

More information

PROCEDIMIENTOPARALAGENERACIÓNDEMODELOS3DPARAMÉTRICOSA PARTIRDEMALLASOBTENIDASPORRELEVAMIENTOCONLÁSERESCÁNER

PROCEDIMIENTOPARALAGENERACIÓNDEMODELOS3DPARAMÉTRICOSA PARTIRDEMALLASOBTENIDASPORRELEVAMIENTOCONLÁSERESCÁNER PROCEDIMIENTOPARALAGENERACIÓNDEMODELOS3DPARAMÉTRICOSA PARTIRDEMALLASOBTENIDASPORRELEVAMIENTOCONLÁSERESCÁNER Lopresti,LauraA.;Lara, Marianela;Gavino,Sergio;Fuertes,LauraL.;Defranco,GabrielH. UnidaddeInvestigación,DesaroloyTransferencia-GrupodeIngenieríaGráficaAplicada

More information

Memorial Health Care System Catholic Health Initiatives Financial Assistance Application Form

Memorial Health Care System Catholic Health Initiatives Financial Assistance Application Form B Please note - Memorial Hospital may access external validation resources to assist in determining whether a full application for assistance is required. Financial Assistance Application 1) Patient Name

More information

Guidelines for Designing Web Maps - An Academic Experience

Guidelines for Designing Web Maps - An Academic Experience Guidelines for Designing Web Maps - An Academic Experience Luz Angela ROCHA SALAMANCA, Colombia Key words: web map, map production, GIS on line, visualization, web cartography SUMMARY Nowadays Internet

More information

What you need TITLE to know about college admission TITLE tests

What you need TITLE to know about college admission TITLE tests Parents What you need to know about college admission tests Your child will want to take a college admission test, such as the SAT or other college entrance exams, when he or she is a junior or senior.

More information

MESSAGE FROM OUR CHAIR

MESSAGE FROM OUR CHAIR Another academic year just started and HETS wishes you success in all your endeavors during this year. This is the time for all our resolutions to take place in producing results for our learners. We have

More information

AP SPANISH LANGUAGE 2011 PRESENTATIONAL WRITING SCORING GUIDELINES

AP SPANISH LANGUAGE 2011 PRESENTATIONAL WRITING SCORING GUIDELINES AP SPANISH LANGUAGE 2011 PRESENTATIONAL WRITING SCORING GUIDELINES SCORE DESCRIPTION TASK COMPLETION TOPIC DEVELOPMENT LANGUAGE USE 5 Demonstrates excellence 4 Demonstrates command 3 Demonstrates competence

More information

IBM Bluemix José Miguel Ordax Cassá ordax@es.ibm.com @jmordax

IBM Bluemix José Miguel Ordax Cassá ordax@es.ibm.com @jmordax Francisco J. Ramos fco_ramos@es.ibm.com IBM Bluemix José Miguel Ordax Cassá ordax@es.ibm.com @jmordax Bluemix ayuda a Transformar ideas en proyectos Cualquier proyecto comienza con una línea de código

More information

magicsbas: A SOUTH-AMERICAN SBAS WITH NTRIP DATA

magicsbas: A SOUTH-AMERICAN SBAS WITH NTRIP DATA magicsbas: A SOUTH-AMERICAN SBAS WITH NTRIP DATA I. Alcantarilla, GMV S.A. J. Caro, GMV S.A. A.Cezón, GMV S.A. J. Ostolaza, GMV S.A. BIOGRAPHY I. Alcantarilla, J. Caro, A. Cezón and J. Ostolaza are part

More information

Fundamentos de Voz sobre el protocolo IP (VoIP)

Fundamentos de Voz sobre el protocolo IP (VoIP) Fundamentos de Voz sobre el protocolo IP (VoIP) OBJETIVO: Comprender el entorno de convergencia de redes de voz, datos y video que se está llevando a cabo en las redes de telefonía, identificando las tecnologías

More information

Versión precedente* Lista productos disponibles** Disponible desde el June 1, 2013

Versión precedente* Lista productos disponibles** Disponible desde el June 1, 2013 Versión precedente* Lista productos disponibles** Disponible desde el June 1, 2013 Las solicitudes de licencias de versión anterior sólo están disponibles para los productos enumerados en este documento.

More information

How To Write An Ontology For Control Engineering

How To Write An Ontology For Control Engineering An Ontology for Control Engineering Francisco Rodríguez, Isaías García, Carmen Benavides, Héctor Aláiz, Javier Alfonso, Ángel Alonso Dept. of Electrical and Systems Engineering, University of León, León,

More information

IBM PureSystems: Familia de Sistemas Expertos Integrados

IBM PureSystems: Familia de Sistemas Expertos Integrados IBM PureSystems: Familia de Sistemas Expertos Integrados Carlos Etchart Sales Support Specialist IBM Está IT listo para el Cambio? New server spending Power & cooling costs Server mgmt & admin costs 2013

More information

Home vol.3 - Bathrooms - Scenes & Shapes

Home vol.3 - Bathrooms - Scenes & Shapes Baños-1 Bathrooms-1 modelos 3D para usuarios Strata 3D models for Strata users Manual de referencia Reference manual Escenas y shapes listos para usar con alto nivel de detalle Scenes & Shapes ready to

More information

NEW TOOLS FOR THE SELECTION OF TECHNOLOGIES; APPLICATION TO SHEET METAL FORMING

NEW TOOLS FOR THE SELECTION OF TECHNOLOGIES; APPLICATION TO SHEET METAL FORMING XI CONGRESO INTERNACIONAL DE INGENIERIA DE PROYECTOS LUGO, 26-28 Septiembre, 2007 NEW TOOLS FOR THE SELECTION OF TECHNOLOGIES; APPLICATION TO SHEET METAL FORMING Abstract David. Cortés Saenz (p), Carles.

More information

Comments on Draft OECD/IOPS Good Practices on Pension Fund s Use of Alternative Investments and Derivatives

Comments on Draft OECD/IOPS Good Practices on Pension Fund s Use of Alternative Investments and Derivatives Comments on Draft OECD/IOPS Good Practices on Pension Fund s Use of Alternative Investments and Derivatives This document includes comments from various FIAP members, belonging to different countries.

More information

Innovation infrastructures assessment through knowledge management models

Innovation infrastructures assessment through knowledge management models Innovation infrastructures assessment through knowledge management models José Teba 1, Luis Onieva 2, Gerardo Jiménez 3, Jesús Muñuzuri 4 Abstract. The design and implementation of innovative infrastructures

More information

Dyna ISSN: 0012-7353 dyna@unalmed.edu.co Universidad Nacional de Colombia Colombia

Dyna ISSN: 0012-7353 dyna@unalmed.edu.co Universidad Nacional de Colombia Colombia Dyna ISSN: 0012-7353 dyna@unalmed.edu.co Universidad Nacional de Colombia Colombia POSADA, ENRIQUE Rational energy use and waste minimization goals based on the use of production data Dyna, vol. 75, núm.

More information

Lotus Foundations Despreocupese de sus problemas de TI, enfoquese en su Negocio Network en una Caja

Lotus Foundations Despreocupese de sus problemas de TI, enfoquese en su Negocio Network en una Caja March 10, 2009 IBM Industry Forum Mexico City, Mexico Lotus Foundations Despreocupese de sus problemas de TI, enfoquese en su Negocio Network en una Caja Dan Kempf Business Development Executive, Latin

More information

Exemplar for Internal Achievement Standard. Spanish Level 1

Exemplar for Internal Achievement Standard. Spanish Level 1 Exemplar for Internal Achievement Standard Spanish Level 1 This exemplar supports assessment against: Achievement Standard 90910 Interact using spoken Spanish to communicate personal information, ideas

More information

DIPLOMADO EN BASE DE DATOS

DIPLOMADO EN BASE DE DATOS DIPLOMADO EN BASE DE DATOS OBJETIVOS Preparan al Estudiante en el uso de las tecnologías de base de datos OLTP y OLAP, con conocimientos generales en todas las bases de datos y especialización en SQL server

More information

Entrenamiento a Embajadores Ambassador training

Entrenamiento a Embajadores Ambassador training Entrenamiento a Embajadores Ambassador training Quiénes somos? Who we are? Levanta la mano si Please raise your hand if a. b. c. d. e. f. g. h. Hablas español You speak spanish Hablas Inglés You speak

More information

SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204

SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204 Part I. Texas Department of Insurance Page 1 of 10 SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204 1. INTRODUCTION. The commissioner of insurance adopts amendments

More information

Skills Development Matrix

Skills Development Matrix Skills Development Matrix For the MBA Programs and MAcc 1. Core Professional Components 2. Accounting 3. Finance 4. Human Resources Management 5. Information and Technology Systems 6. International Business

More information

Open-Ended Responses. Parent Survey for schools. Question 1. What do you like best about our school? Response. Survey Open-Ended Responses.

Open-Ended Responses. Parent Survey for schools. Question 1. What do you like best about our school? Response. Survey Open-Ended Responses. Survey Open-Ended s Open-Ended s Parent Survey for schools Question 1. What do you like best about our school? s. The learning enviroment and the individual care for each child needs IB program the good

More information

PREDICTING THE INTENTION OF USING A TECHNOLOGY PRODUCT OR SERVICE THROUGH A FUZZY CONTROLLER

PREDICTING THE INTENTION OF USING A TECHNOLOGY PRODUCT OR SERVICE THROUGH A FUZZY CONTROLLER PREDICTING THE INTENTION OF USING A TECHNOLOGY PRODUCT OR SERVICE THROUGH A FUZZY CONTROLLER Libertad Caicedo Acosta (District University Francisco José de Caldas, Bogotá, Colombia) licedoa@correo,udistrital.edu.co

More information

Como puede ayudar Security Intelligence a proteger nuestras empresas

Como puede ayudar Security Intelligence a proteger nuestras empresas Como puede ayudar Security Intelligence a proteger nuestras empresas www.ibm.com/security securityintelligence.com Juan Paulo Cabezas, Arquitecto de IBM Security Systems jcabezas@cl.ibm.com 1 Agenda Introducción

More information

Re-broadcasting of bibliographic catalogues in MARC-XML format

Re-broadcasting of bibliographic catalogues in MARC-XML format Re-broadcasting of bibliographic catalogues in MARC-XML format Manuel Blázquez-Ochando * Paper submitted: May 21, 2013. Accepted: August 7, 2013. Abstract By using MARC-XML to modify the RSS code format,

More information

How to Buy Real Estate in Spain

How to Buy Real Estate in Spain BUY REAL ESTATES PROPERTIES IN ANDALUCIA Antonio López Gómez / Economist / Project Manager IMPORTANTE: IN SPANISH LANGUAGE: Espero que el dossier explicativo le resulte interesante y si tienen alguna otra

More information

General Certificate of Education Advanced Level Examination June 2014

General Certificate of Education Advanced Level Examination June 2014 General Certificate of Education Advanced Level Examination June 2014 Spanish Unit 4 Speaking Test Candidate s Material To be conducted by the teacher examiner between 7 March and 15 May 2014 (SPA4T) To

More information

Visión general de la integración con asanetwork

Visión general de la integración con asanetwork Visión general de la integración con asanetwork Este documento se ha preparado parar dar una visión general del flujo de trabajo de asanetwork y de las tareas a realizar por los programadores del Sistema

More information

Marketing. (online) Marketing online y el posicionamiento en buscadores.

Marketing. (online) Marketing online y el posicionamiento en buscadores. Marketing (online) Marketing online y el posicionamiento en buscadores. Jornada " Redes Sociales o Profesionales? Asociación de Empresarias y Profesionales de Valencia Pau Klein González Pau Klein González

More information

When to select APA and other Transfer Pricing options. Challenges and Opportunities for the Maquila Industry. 2014 Galaz, Yamazaki, Ruiz Urquiza, S.C.

When to select APA and other Transfer Pricing options. Challenges and Opportunities for the Maquila Industry. 2014 Galaz, Yamazaki, Ruiz Urquiza, S.C. When to select APA and other Transfer Pricing options Challenges and Opportunities for the Maquila Industry Agenda 1. Background 2. Type of Maquiladoras 3. APA as an option for PE exemption and compliance

More information

En esta guía se encuentran los cursos que se recomiendan los participantes en la implementación de un SGEn en dependencias del Gobierno Federal.

En esta guía se encuentran los cursos que se recomiendan los participantes en la implementación de un SGEn en dependencias del Gobierno Federal. En esta guía se encuentran los cursos que se recomiendan los participantes en la implementación de un SGEn en dependencias del Gobierno Federal. Las lecciones se agrupan en 5 cursos dirigidos cada participante

More information

Identificación y evaluación de los riesgos asociados a la cadena de suministro (CBI).

Identificación y evaluación de los riesgos asociados a la cadena de suministro (CBI). Los Retos de la Industria Aseguradora ante la Globalización de los Mercados Identificación y evaluación de los riesgos asociados a la cadena de suministro (CBI). Las cadenas de suministro son, en la actualidad,

More information

ACTIVITY # Dear Parent, Carta a los Padres. pbskids.org

ACTIVITY # Dear Parent, Carta a los Padres. pbskids.org Dear Parent, Today was the 100th Day of School, and what better way to celebrate than with activities all about the number 100? With the help of Peg and Cat the problem-solving, math-loving duo from PBS

More information

Ingeniería de Software & Ciclos de Vida. Luis Carlos Díaz Miguel Torres Julián Rodriguez

Ingeniería de Software & Ciclos de Vida. Luis Carlos Díaz Miguel Torres Julián Rodriguez Ingeniería de Software & Ciclos de Vida Luis Carlos Díaz Miguel Torres Julián Rodriguez Ingeniería de Software Personas Tecnología Producto Proceso 24-Ene-07 Msc. Luis Carlos Díaz 2 Costos 24-Ene-07 Msc.

More information

Monterey County Behavioral Health Policy and Procedure

Monterey County Behavioral Health Policy and Procedure Monterey County Behavioral Health Policy and Procedure 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Policy Number 144 Policy Title Disclosure of Unlicensed Status for License

More information

R&P Cultural Orientation Model Assessment, Spanish

R&P Cultural Orientation Model Assessment, Spanish R&P Cultural Orientation Model Assessment, Spanish Participant Name Case # Assessor Name Date CO Completed Date of Assessment Additional Notes Reminders for assessors: Locally- or culturally-relevant terms

More information

Understanding Abstraction and Virtualization

Understanding Abstraction and Virtualization Understanding Abstraction and Virtualization VIRTUALIZATION Virtualization is a technology that allows creating an abstraction (a virtual version) of computer resources, such as hardware architecture,

More information

FAMILY INDEPENDENCE ADMINISTRATION Seth W. Diamond, Executive Deputy Commissioner

FAMILY INDEPENDENCE ADMINISTRATION Seth W. Diamond, Executive Deputy Commissioner FAMILY INDEPENDENCE ADMINISTRATION Seth W. Diamond, Executive Deputy Commissioner James K. Whelan, Deputy Commissioner Policy, Procedures and Training Lisa C. Fitzpatrick, Assistant Deputy Commissioner

More information

How To Know If An Ipod Is Compatible With An Ipo Or Ipo 2.1.1 (Sanyo)

How To Know If An Ipod Is Compatible With An Ipo Or Ipo 2.1.1 (Sanyo) IntesisBox PA-RC2-xxx-1 SANYO compatibilities In this document the compatible SANYO models with the following IntesisBox RC2 interfaces are listed: / En éste documento se listan los modelos SANYO compatibles

More information

VMware vsphere with Operations Management: Fast Track

VMware vsphere with Operations Management: Fast Track VMware vsphere with Operations Management: Fast Track Duración: 5 Días Código del Curso: VSOMFT Método de Impartición: Curso Cerrado (In-Company) Temario: Curso impartido directamente por VMware This intensive,

More information

Copyright 2016-123TeachMe.com 4ea67 1

Copyright 2016-123TeachMe.com 4ea67 1 Sentence Match Quiz for Category: hacer_make_do_1 1) Nosotros hacemos todo lo posible para proporcionar un buen servicio. - A: We do our best to provide good service. - B: These chores are done each time.

More information

VISION DEL DATA CENTER SIMPLIFICANDO LA RED DEL DATA CENTER. Javier Grizzuti Enterprise System Engineer CALA Agosto, 2010

VISION DEL DATA CENTER SIMPLIFICANDO LA RED DEL DATA CENTER. Javier Grizzuti Enterprise System Engineer CALA Agosto, 2010 VISION DEL DATA CENTER SIMPLIFICANDO LA RED DEL DATA CENTER Javier Grizzuti Enterprise System Engineer CALA Agosto, 2010 AGENDA 1. Los Desafios del Data Center 2. Evolucion de la Red del Data Center 3.

More information

Range of studies: List of Courses Taught in Spanish CURSO 2014 15

Range of studies: List of Courses Taught in Spanish CURSO 2014 15 Course Title (English) Course Title (Spanish) Degree Year Semester Caracter Speciality Code ECTS Calculus for Infomatics Cálculo para la Computación BCE BSE BCSE 1st 1st Comp. Subjet 101 6 Discrete Mathematics

More information

Propiedades del esquema del Documento XML de envío:

Propiedades del esquema del Documento XML de envío: Web Services Envio y Respuesta DIPS Courier Tipo Operación: 122-DIPS CURRIER/NORMAL 123-DIPS CURRIER/ANTICIP Los datos a considerar para el Servicio Web DIN que se encuentra en aduana son los siguientes:

More information

Development of distributed algorithms for data search and content distribution in structured peer-to-peer networks

Development of distributed algorithms for data search and content distribution in structured peer-to-peer networks Universidad de Murcia Department of Information and Communication Engineering Development of distributed algorithms for data search and content distribution in structured peer-to-peer networks A thesis

More information

David Peña, EMSD Specialist Systems Engineer, EMC. #EMCTour. Copyright 2015 EMC Corporation. All rights reserved.

David Peña, EMSD Specialist Systems Engineer, EMC. #EMCTour. Copyright 2015 EMC Corporation. All rights reserved. David Peña, EMSD Specialist Systems Engineer, EMC #EMCTour CONSTANT RENDIMIENTO= LEY DE MOORE MOORE S LAW: 100X POR DÉCADA FLASH acerca el GAP entre las CPU vs Disks FLASH sigue la ley de Moore y equipara

More information

Application For Employment/Solicitud de Empleo

Application For Employment/Solicitud de Empleo Send complete application to: (Enviar solicitud completa a:) Waltex Construction, Inc. P. O. Box 2440 West Sacramento, CA 95691 or fax/e-mail to: 916-676-7100; yelena@waltexconstruction.com Application

More information

SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204

SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204 Part I. Texas Department of Insurance Page 1 of 11 SUBCHAPTER A. AUTOMOBILE INSURANCE DIVISION 3. MISCELLANEOUS INTERPRETATIONS 28 TAC 5.204 1. INTRODUCTION. The Texas Department of Insurance proposes

More information

ISSAI 1220. Control de calidad en una auditoría de estados financieros. Directriz de auditoría financiera

ISSAI 1220. Control de calidad en una auditoría de estados financieros. Directriz de auditoría financiera Las Normas Internacionales de las Entidades Fiscalizadoras Superiores (ISSAI) son emitidas por la Organización Internacional de Entidades Fiscalizadoras Superiores (INTOSAI). Para más información visite

More information

Spanish Grammar II. Tierra Encantada Charter School. Contact Number: (505) 983-3337

Spanish Grammar II. Tierra Encantada Charter School. Contact Number: (505) 983-3337 Spanish Grammar II Tierra Encantada Charter School Mr. Arruga Contact Number: (505) 983-3337 Course Description/Objectives / Descripcion del curso / Objetivos: La asignatura de Gramatica espanola pretende

More information

DESARROLLO DE UN MÓDULO LED PARA LOS PROTOTIPOS DE FAROS DELANTEROS Y TRASEROS DEL SEAT ALTEA

DESARROLLO DE UN MÓDULO LED PARA LOS PROTOTIPOS DE FAROS DELANTEROS Y TRASEROS DEL SEAT ALTEA XI CONGRESO INTERNACIONAL DE INGENIERIA DE PROYECTOS LUGO, 26-28 Septiembre, 2007 DESARROLLO DE UN MÓDULO LED PARA LOS PROTOTIPOS DE FAROS DELANTEROS Y TRASEROS DEL SEAT ALTEA V. Oliveras Mérida (p), C.

More information

Optimizing the Cellular Network Planning Process for In-Building Coverage using Simulation

Optimizing the Cellular Network Planning Process for In-Building Coverage using Simulation Optimizing the Cellular Network Planning Process for In-Building Coverage using Simulation A. Huerta-Barrientos *, M. Elizondo-Cortés Departamento de Ingeniería de Sistemas, Facultad de Ingeniería Universidad

More information

magicsbas: A SOUTH-AMERICAN SBAS EXPERIMENT WITH NTRIP DATA

magicsbas: A SOUTH-AMERICAN SBAS EXPERIMENT WITH NTRIP DATA magicsbas: A SOUTH-AMERICAN SBAS EXPERIMENT WITH NTRIP DATA I. Alcantarilla, GMV S.A. J. Caro, GMV S.A. A. Cezón, GMV S.A. J. Ostolaza, GMV S.A. F. Azpilicueta, Universidad de La Plata. BIOGRAPHY I. Alcantarilla,

More information

How To Write A Report On A Drug Company

How To Write A Report On A Drug Company Regulatory Quality Forum October 3 and 10, 2014 Four Points Hotel and Casino, Caguas PR Coming to America: Regulatory Opportunities Business Excellence Consulting, Inc. Phone: 787.705.7272 www.calidadpr.com

More information

UNIVERSIDAD POLITÉCNICA DE MADRID

UNIVERSIDAD POLITÉCNICA DE MADRID UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingenieros de Telecomunicación CONTRIBUTION TO PROACTIVITY IN MOBILE CONTEXT-AWARE RECOMMENDER SYSTEMS TESIS DOCTORAL Daniel Gallego Vico Ingeniero

More information

FOR TEACHERS ONLY The University of the State of New York

FOR TEACHERS ONLY The University of the State of New York FOR TEACHERS ONLY The University of the State of New York REGENTS HIGH SCHOOL EXAMINATION S COMPREHENSIVE EXAMINATION IN SPANISH Wednesday, January 24, 2007 9:15 a.m. to 12:15 p.m., only SCORING KEY Updated

More information

OnPremise y en la nube

OnPremise y en la nube La estrategia de Integración Microsoft OnPremise y en la nube Beacon42 - GABRIEL COR Creando valor a través de la integración ESB es antiguo ahora es NoESB SOA Todo es un API EAI es major que Batch

More information

abrir además ahí ahora algo alguno alto amor años

abrir además ahí ahora algo alguno alto amor años abrir además ahí ahora algo alguno alto amor años 2012 2013 Houston Independent School District 1 antes aquello aquí así atención aunque ayudar bailar bajar 2012 2013 Houston Independent School District

More information

BALANCE DUE 10/25/2007 $500.00 STATEMENT DATE BALANCE DUE $500.00 PLEASE DETACH AND RETURN TOP PORTION WITH YOUR PAYMENT

BALANCE DUE 10/25/2007 $500.00 STATEMENT DATE BALANCE DUE $500.00 PLEASE DETACH AND RETURN TOP PORTION WITH YOUR PAYMENT R E M I T T O : IF PAYING BY MASTERCARD, DISCOVER, VISA, OR AMERICAN EXPRESS, FILL OUT BELOW: XYZ Orthopaedics STATEMENT DATE BALANCE DUE 10/25/2007 $500.00 BALANCE DUE $500.00 ACCOUNT NUMBER 1111122222

More information

Revisión general de la tecnología. Funcionalidad del CRTOUCH Calibración Casos de Uso Consideraciones importantes

Revisión general de la tecnología. Funcionalidad del CRTOUCH Calibración Casos de Uso Consideraciones importantes Agosto, 2012 Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t he Energy Efficient Solutions logo, mobilegt, PowerQUICC, QorIQ, StarCore and Symphony are trademarks

More information

How To Teach A Security Manager

How To Teach A Security Manager ISACA: Certified Information Security Manager Certification Training Certified Information Security Manager (CISM) DESCRIPCIÓN: El programa de certificación CISM (Certified Information Security Manager)

More information

Cisco CCNP: Troubleshooting Certification Training with Real Live Practice Labs. Cisco

Cisco CCNP: Troubleshooting Certification Training with Real Live Practice Labs. Cisco Cisco CCNP: Troubleshooting Certification Training with Real Live Practice Labs Cisco Cisco CCNP: Troubleshooting Certification DESCRIPCIÓN: La capacitación para la resolución de problemas y mantenimiento

More information

HPN Product Tools. Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

HPN Product Tools. Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HPN Product Tools Requerimiento: Conozco el numero de parte (3Com,H3C,Procurve) Solución : El lookup Tool 1 Permite convertir el número de parte de un equipo proveniente de 3Com, H3C o Procurve para obtener

More information

PERSONAL INFORMATION / INFORMACIÓN GENERAL Last Name / Apellido Middle Name / Segundo Nombre Name / Nombre

PERSONAL INFORMATION / INFORMACIÓN GENERAL Last Name / Apellido Middle Name / Segundo Nombre Name / Nombre COMPUTER CLASS REGISTRATION FORM (Please Print Clearly Lea con cuidado) To register for the Computer Technology Program, please complete the following form. All fields in this form must be filled out in

More information

Ficha técnica de curso Código: IFCAD111

Ficha técnica de curso Código: IFCAD111 Curso de: Objetivos: Managing Cisco Network Security: Building Rock-Solid Networks Dar a conocer la filosofía CISCO desde el punto de vista de la seguridad y como construir una red solidad. Como hacer

More information

LOS ANGELES UNIFIED SCHOOL DISTRICT REFERENCE GUIDE

LOS ANGELES UNIFIED SCHOOL DISTRICT REFERENCE GUIDE TITLE: NUMBER: ISSUER: Service Completion Criteria for Speech Language Impairment (SLI) Eligibility and Language and Speech (LAS) Services REF-4568.1 DATE: August 24, 2015 Sharyn Howell, Associate Superintendent

More information

Semantic Representation of Raster Spatial Data

Semantic Representation of Raster Spatial Data ABSTRACT of PhD THESIS Semantic Representation of Raster Spatial Data Representación Semántica de Datos Espaciales Raster Rolando Quintero Téllez Graduated on November 08, 2007 Centro de Investigación

More information

DIPLOMADO DE JAVA - OCA

DIPLOMADO DE JAVA - OCA DIPLOMADO DE JAVA - OCA TABLA DE CONTENIDO INTRODUCCION... 3 ESTRUCTURA DEL DIPLOMADO... 4 Nivel I:... 4 Fundamentals of the Java Programming Language Java SE 7... 4 Introducing the Java Technology...

More information

Monitoring, Management and Topological Display Device using wireless network managed clients

Monitoring, Management and Topological Display Device using wireless network managed clients DOI: http:/dx.doi.org/10.18180/tecciencia.2013.15.10 Monitoring, Management and Topological Display Device using wireless network managed clients Monitoreo, gestión y visualización topológica de dispositivos

More information

Horizon 2020 Y emprendedores en la red

Horizon 2020 Y emprendedores en la red Horizon 2020 Y emprendedores en la red 29 November 2011 Oportunidad para el ABI Horizon es el nuevo programa de la UE para la investigación y la innovación con llamadas desde el 2013 EL ABi debe empezar

More information

Global Art: A Sense of Caring Nos Preocupamos por los Demas

Global Art: A Sense of Caring Nos Preocupamos por los Demas Project Starter Kit for Online Collaborations Submitted by Jennifer Geist Bridges to Understanding Seattle, WA December 2006 Global Art: A Sense of Caring Nos Preocupamos por los Demas A Starter Kit for

More information

Project G3: Development of quality specifications applicable to the AIM digital environment (SAM) (Presented by the Secretariat) Summary

Project G3: Development of quality specifications applicable to the AIM digital environment (SAM) (Presented by the Secretariat) Summary International Civil Aviation Organization SAM/AIM/3-WP/05 South American Regional Office 28/02/12 Third Multilateral Meeting of the SAM Region for the Transition of AIS to AIM (SAM/AIM/3) Lima, Peru, 12

More information

Estrategias para la Reducción de Riesgos y Ciber Ataques

Estrategias para la Reducción de Riesgos y Ciber Ataques Estrategias para la Reducción de Riesgos y Ciber Ataques Luis Zamora Consultor en Tecnología 1 This document is for informational purposes. It is not a commitment to deliver any material, code, or functionality,

More information