Supporting SIP-based End-to-End Data Distribution Service QoS in WANs

Akram Hakiria,b, Pascal Berthoua,b, Aniruddha Gokhalec, Douglas C. Schmidtc, Gayraud Thierrya,b

aCNRS, LAAS, 7 avenue du colonel Roche, F-31400 Toulouse, FrancebUniv de Toulouse, UPS, LAAS, F-31400 Toulouse, FrancecInstitute for Software Integrated Systems, Dept of EECS

Vanderbilt University, Nashville, TN 37212, USA

Abstract

Assuring end-to-end QoS in enterprise distributed real-time and embedded (DRE) systems is hard due tothe heterogeneity and transient behavior of communication networks, the lack of integrated mechanisms thatschedule communication and computing resources holistically, and the scalability limits of IP multicast inwide-area networks (WANs). This paper makes three contributions to research on overcoming these problemsin the context of enterprise DRE systems that use the OMG Data Distribution Service (DDS) quality-of-service (QoS)-enabled publish/subscribe (pub/sub) middleware over WANs. First, it codifies the limitationsof conventional DDS implementations deployed over WANs. Second, it describes a middleware componentcalled Proxy DDS that bridges multiple, isolated DDS domains deployed over WANs. Third, it describesthe NetQSIP framework that combines multi-layer, standards-based technologies including the OMG-DDS,Session Initiation Protocol (SIP), and IP DiffServ to support end-to-end QoS in a WAN and shield pub/subapplications from tedious and error-prone details of network QoS mechanisms. The results of experimentsusing Proxy DDS and NetQSIP show how combining DDS with SIP in DiffServ networks significantlyimproves dynamic resource reservation in WANs and provides effective end-to-end QoS management.

Keywords: Bridge-Federate model; Proxy DDS; SIP; NetQSIP; QoS Framework; DiffServ;Common Open Policy Service (COPS).

1. Introduction

Current trends and challenges. Regionalsmart power grids or air traffic management systemsare examples of enterprise distributed real-time andembedded (DRE) systems that disseminate high vol-umes of data with low end-to-end latency and jit-ter. These types of systems often comprise mul-

Email addresses: hakiri@laas.fr (Akram Hakiri),berthou@laas.fr (Pascal Berthou),a.gokhale@vanderbilt.edu (Aniruddha Gokhale),d.schmidt@vanderbilt.edu (Douglas C. Schmidt),gayraud@laas.fr (Gayraud Thierry)

tiple end-to-end application flows that may requirevarious quality-of-service (QoS) properties affectingCPU, memory, and network resources. They also op-erate in distributed and heterogeneous environmentsthat process data from large number of terminals,media sources, and real-time data feeds [15] that orig-inate over diverse geographic locations connected viawide-area networks (WANs).

In enterprise DRE systems the right answer deliv-ered too late becomes the wrong answer [61]. Keychallenges faced when fielding these systems thus in-clude distributing a high volume of messages persecond while simultaneously meeting requirements

Preprint submitted to Elsevier November 24, 2015

for scalability and low/predictable latency, control-ling trade-offs between latency and throughput, andmaintaining stability during bandwidth fluctuations.Moreover, end-system mechanisms must work withinand across different communication access points,network domains, and inter-domain links to ensureend-to-end QoS requirements are met.

Over the past decade, standards-based middlewarehas emerged that addresses many enterprise DREsystem challenges, including distributing high volumedata scalably/predictably and minimizing end-to-endlatency/jitter. In particular, the OMG Data Distri-bution Service (DDS) [44] defines a standard archi-tecture for real-time, data-centric publish/subscribe(pub/sub) middleware capabilities that are used inmany DRE systems to provide efficient and pre-dictable dissemination of time-critical data [36]. Dueto its flexible programming abstractions and rich sup-port for QoS policies/mechanisms capable of con-trolling the end-to-end properties of data distribu-tion [27], DDS is a popular technology for buildingenterprise DRE systems [2].

For example, DDS defines a set of network schedul-ing policies (e.g., end-to-end network latency bud-gets), timeliness policies (e.g., time-based filters tocontrol data delivery rate), temporal policies to de-termine the rate at which periodic data is refreshed(e.g., deadline between data samples), network pri-ority policies (e.g., transport priority can be used toset the DSCP field for DiffServ in the underlying datatransport), and other policies that affect how data istreated in transit with respect to its reliability, ur-gency, importance, and durability.

Although standards-based DDS implementationshave been used to develop many efficient and depend-able DRE systems in local-area networks (LANs),conventional implementations of the DDS standardincur the following limitations that impede their usefor enterprise DRE systems that run in wide-areanetworks (WANs) that comprise multiple network do-mains.

Limitation 1: Lack of communication be-tween isolated DDS domains. ConventionalDDS implementations run within an isolated DDS

domain1 traditionally deployed within a singlemulticast-enabled LAN. For example, individualpower stations and power distribution plants of asmart grid could operate within their own DDS do-mains that are isolated from each other. As DREsystems expand into enterprise DRE systems (suchas a regional smart power grid or air traffic manage-ment system) there is a need to interconnect theseindependent and isolated DDS domains.

The DDS standard, however, makes no mentionabout interconnectivity among isolated DDS do-mains. In fact, DDS domains were devised to iso-late the individual communications within domainsfrom each other, which was necessary if multiple inde-pendent domains operate within overlapping networkboundaries. In enterprise DRE systems, these DDSdomains are often distributed across WANs. Com-munication between isolated DDS domainseven ifwere addressed by the DDS standardis hard dueto the challenge of delivering the topics along withtheir expected end-to-end QoS requirements to par-ticipants across a WAN and between isolated DDSdomains.

Limitation 2: Lack of IP multicast supportin WANs. Conventional DDS implementations areoriented towards LANs and virtual LANs (VLANs).2

For example, in a regional smart grid, DDS will tryto discover various publisher (e.g., sources of anomalyevents at power generation facilities) and subscriber(e.g., power distribution facilities) participants usingconventional IP multicast [21], where the networkequipment supports Ethernet multicast prefixes re-served for IP multicast groups [20].

IP multicast is often not deployed in multi-domainWANs, however, so conventional DDS implementa-tions may be unable to distribute topics betweenparticipants running in isolated DDS domains overWANs. In particular, when DDS discovery messagesare blocked by edge routers for security and/or per-

1A DDS is a data-space consisting of publishers and sub-scribers that communicate asynchronously and anonymouslywith each other via typed messages called topics.

2A VLAN is a single layer-2 network that may be parti-tioned to create multiple distinct domains that are mutuallyisolated.

2

formance reasons they do not reach subscribers in re-mote networks in a WAN. In the smart grid example,for instance, topics published by a publisher in oneLAN may not reach subscribers in a geographicallydistributed LAN.

Limitation 3: Lack of DDS QoS provision-ing mechanisms in WANs. The DDS standardonly defines QoS mechanisms that control end-systemproperties, such as OS-level parameters and tuningnetwork parameters for the connecting link. DDSimplementations tend to support these features wellonly in the context of LANs/VLANs, and are limitedin their support of key QoS policies over WANs. Forexample, events generated in one air traffic manage-ment domain may require real-time dissemination toanother geographically distributed air traffic manage-ment domain. In conventional DDS implementations,however, it is hard to achieve these effects since theyprovide proprietaryand often incomplete and inef-ficient solutionsfor provisioning/controlling end-to-end QoS over WANs, which impedes QoS assurancewhen participants span multiple network domains.

Overcoming the three limitations outlined above isessential to assure the end-to-end QoS of DDS-basedenterprise DRE systems running over WANs.

Solution approach Non-invasive DDS Ex-tensions that Leverage IP Multimedia CoreNetwork Subsystem (IMS) [64] technologiesto ensure end-to-end QoS. To address Limita-tion 1 (lack of communication between isolated DDSdomains) we developed Proxy DDS, which is a setof cooperating software components that enable effi-cient and seamless communication between DDS par-ticipants in isolated domains, and provides signal-ing. Proxy DDS components scalably decouple DDSparticipants in time/space and minimize traffic ex-changed between these participants.

To address Limitation 2 (lack of multicast supportin WANs), the Proxy DDS provides proxy-to-proxycommunication over WANs, thereby supporting scal-able multicast. Likewise, to address Limitation 3(lack of QoS provisioning mechanisms in WANs),we integrated the Proxy DDS with NetQSIP, whichis a Session Initiation Protocol (SIP)-based [32, 10]QoS framework that uses Differentiated Service (Diff-Serv) [7] policies to enforce network-level differenti-

ated QoS for each DDS application data flow in aWAN.

Our prior work [30] presented a framework calledVelox that conducted QoS negotiation and resourcereservations across network elements in a WAN tomeet scheduling requirements of DDS applications.Velox incurs several reliability and maintainabilitylimitations, however, e.g., it cannot recover from fail-ures dynamically and must be manually reconfiguredby human operators whenever a failure occurs. More-over, Velox does not support dynamic QoS reconfig-urations in DDS over WANs.

To overcome these limitations, this paper describeshow combining Proxy DDS and NetQSIP providesan alternate strategy for supporting DDS QoS poli-cies over WANs that does not introduce new capabil-ities at the network layer (as Velox did), but insteadleverages standard SIP to achieve these goals. Al-though SIP has traditionally been used to supportdynamic QoS-enabled IMS applications, this paperdemonstrates how it can be used to support dynamicQoS management for DDS applications running inenterprise DRE systems. In particular, this papermakes the following contributions to research on as-suring end-to-end QoS of enterprise DRE systems us-ing DDS over a SIP-based WAN:

It elaborates upon the limitations outlined aboveof deploying conventional DDS implementationsover WANs.

It describes how the Proxy DDS and NetQSIPframework resolve limitations with conventionalDDS implementations over WANs by using SIPand DiffServ to optimize pub/sub communica-tion and assure end-to-end DDS application QoSrequirements. In addition to bridging isolatedDDS domains and ensuring the propagation ofthe DDS QoS to different network domains,NetQSIP enables self-network reconfiguration af-ter failures by adapting applications to networkload.

It empirically evaluates the capabilities of ourenhanced DDS implementation in a WAN to de-termine how well (1) Proxy DDS optimizes thebandwidth between remote participants and (2)

3

the NetQSIP framework can achieve lower end-to-end delay.

Our solution preserves the DDS programmingmodel so developers can seamlessly use the new capa-bilities of Proxy DDS and NetQSIP without chang-ing their application designs. Moreover, since SIP isa standard and universally available, our solution caneasily be adopted by different DDS implementationsand support interoperability.

Paper organization. The remainder of this pa-per is organized as follows: Section 2 compares ourresearch on the Proxy DDS and NetQSIP with re-lated work; Section 3 describes how Proxy DDS andNetQSIP support effective and scalable inter-DDS-domain communication, end-to-end QoS signaling,and resource management in WANs; Section 4 ana-lyzes the results of experiments that evaluate the ca-pabilities of the Proxy DDS and NetQSIP in a WANtestbed; and Section 5 presents concluding remarksand lessons learned.

2. Background and Related Work

Conventional techniques for providing networkQoS to applications incur several key limitations, in-cluding a lack of mechanisms to (1) specify deploy-ment context-specific network QoS requirements and(2) integrate functionality from network QoS mech-anisms at runtime. This section evaluates limita-tions with existing attempts to resolve these prob-lems and outlines how our research on Proxy DDSand NetQSIP address them.

To clarify the specific challenges (i.e., integrat-ing DiffServ-based QoS provisioning mechanisms intoDDS middleware) addressed in this paper, this sec-tion first provides an overview of OMG DDS and thendescribes the limitations of the DDS Routing Service(DDS-RS) [55], which is a content-aware middlewareservice designed to bridge DDS data spaces. We thencompare and contrast Proxy DDS and NetQSIP withrelated work on general middleware-based QoS man-agement and network-level QoS management.

2.1. Overview of the OMG Data Distribution Service(DDS)

The OMG DDS specification [44] defines a stan-dard pub/sub architecture and runtime capabili-ties that enable applications to exchange data asyn-chronously, anonymously, and dependably in data-centric DRE systems. DDS provides efficient, scal-able, predictable, and resource-aware data distribu-tion via its Data-Centric Publish/Subscribe (DCPS)layer, which supports a global data store where pub-lishers write and subscribers read data, respectively.DDS modular structure and flexibility stems from itssupport for

Location-independence, via anonymous pub/sub,

Redundancy, by allowing any numbers of readersand writers,

Real-time QoS, via its 22 QoS policies summa-rized in Table 1,

Platform-independence, by supporting aplatform-independent model for data definitionthat can be mapped to different platform-specific models (e.g., C++ running on VxWorksor Java running on Real-time Linux), and

Interoperability, by specifying a standardizedprotocol [43] that allows implementations fromdifferent DDS vendors to exchange data betweendistributed publishers and subscribers.

DDS specifies several types of DCPS entities. Adomain represents the set of applications that com-municate with each other. A domain acts like a vir-tual private network [3, 57], allowing DDS entitiesin different domains to communicate anonymously,regardless of whether they reside on the same ma-chine, in the same process, or on another host in thenetwork. A domain participant factory creates anddestroys domain participants, each of which provide

A container for all DDS entities for an applica-tion within a single domain,

A factory for creating publisher, subscriber, andtopic entities, and

4

Table 1: DDS QoS Policies

DDS QoS Policy DescriptionUser Data Attaches application data to DDS

entitiesTopic Data Attaches application data to topicsGroup Data Attaches application data to

publishers, subscribersDurability Determines if data outlives the time

when written or readDurabilityService

Details how durable data is stored

Presentation Delivers data as group and/or inorder

Deadline Determines rate at which periodicdata is refreshed

LatencyBudget

Sets guidelines for acceptableend-to-end delays

Ownership Controls writer(s) of dataOwnershipStrength

Sets ownership of data

Liveliness Sets liveness properties of topics,data readers, data writers

Time BasedFilter

Mediates exchanges between slowconsumers and fast producers

Partition Controls logical partition of datadissemination

Reliability Controls reliability of datatransmission

TransportPriority

Sets priority of data transport

Lifespan Sets time bound for stale dataDestinationOrder

Sets whether data sender or receiverdetermines order

History Sets how much data is kept to beread

ResourceLimits

Controls resources used to meetrequirements

EntityFactory

Sets enabling of DDS entities whencreated

Writer DataLifecycle

Controls data and data writerlifecycles

Reader DataLifecycle

Controls data and data readerlifecycles

A domains administration services, such asallowing an application to ignore informationabout particular DDS entities.

DDS is topic-based, which allows strongly-typeddata dissemination since the type of the data isknown throughout the DRE system. A DDS topicdescribes the type and structure of the data to reador write, a data reader subscribes to the data of par-ticular topics, and a data writer publishes data forparticular topics. Publishers manage one or moredata writers, whereas subscribers manage one or moredata readers. Publishers and subscribers can ag-gregate data from multiple data writers and readers

for efficient transmission of data across a network.Topic types are defined via the OMG Interface Def-inition Language (IDL) [45] that enables platform-independent type definitions.

DDS provides a rich set of QoS policies (listed inTable 1) and various properties of DDS entities canbe configured using combinations of these policies.Each QoS policy has 2 attributes, with most at-tributes having an unbounded number of potentialvalues (e.g., an attribute of type character string orinteger). The DDS specification defines which QoSpolicies are applicable for certain entities, as well aswhich combinations of QoS policy values are semanti-cally compatible. DDS thus provides a wide range ofQoS capabilities that can be configured flexibly [34]to meet the needs of topic-based DRE systems thathave diverse QoS requirements.

For communication between DDS participants tooccur efficiently, QoS policies on a publisher mustbe compatible with corresponding policies on a sub-scriber. DDS ensures this compatibility via itsRequested/Offered (RxO) contract model, where asubscriber can specify a requested value for a par-ticular QoS policy to be set in compatible mannerbetween the corresponding participants. If the RxOcontract matches, that QoS policy must be set bothat the publishing and subscribing sides.

In the DDS RxO model the publisher declares in-formation it has and specifies the topic and the of-fered QoS contract for that topic; its associated lis-tener is then alerted of any significant status changes.The subscriber declares information it wants andspecifies the topic and requested QoS contract; itsassociated listener is then alerted of any significantstatus changes. For example, if the subscriber re-quests to receive data reliably while publisher definesa best-effort policy, communication will not happenas requested. If the RxO does not match, the com-pliance of QoS policy on both sides is not requested.

2.2. DDS Routing Service

A notable earlier effort aimed at spatially decou-pling DDS entities in the context of WANs is theDDS Routing Service [55, 37] (DDS-RS). DDS-RSestablishes a content-aware interconnection service

5

Figure 1: Layered Bridge-Federate Architecture

to enable deploying existing application in transpar-ent manner. It allows DDS-to-DDS bridging be-tween different DDS domains using transparent datatransformation mechanisms (i.e., applications can bereused without source code changes, even if they weredeveloped using incompatible interface definitions).

DDS-RS also provides features (such as domain-bridging and topic-bridging) to allow data modelcompatibility by enabling seamless communicationbetween data-spaces. Its domain-bridging mode en-ables an application running in one data-space to ac-cess a different data-space. It creates a bridge be-tween data writers and data readers in two distinctDDS domains, even with incompatible topics; thetopic-bridging allows sharing of distinct topics (withdifferent keys, names and data types) between DDSparticipants. It can also act as a filter by transform-ing data content in topic A to topic B.

One solution to match distinct DDS-domains is toleverage existing capabilities of the DDS-RS and en-hance them. We therefore implemented a Bridge-Federate using the DDS-RS API that performs bothdomain-bridging and topic-bridging. As described inFigure 1, the bridge-federate is a software componentthat adopts a layered architecture to make it possiblethe interconnection of disjoint DDS domains. It actsas a single federate that differs from other DDS par-ticipants to forward DDS messages between disjointDDS domains.

Although the Bridge-Federate enables forwardingdata from one domain to the other, it has several lim-itations that preclude it from fulfilling the bandwidth

and the data-delivery requirements of enterprise DREsystems in WANs, as described in Section 4.2.1. Inparticular, the Bridge-Federate does not optimizebandwidth utilization between DDS participants, soit can incur scalability problems if the number ofDDS participants increases significantly (as is oftenthe case in WAN-based enterprise DRE systems).

In addition, the Bridge-Federate enables afederation-like communication model, where a centralfederate matches remote participants and forces allthe traffic to pass through it, thus it does not provideany mechanism for failover from failure. Moreover,since DDS topics in a WAN may be routed over aninternet, which is composed of different network tech-nologies (e.g., wired and wireless) with different linkcapacities (e.g., satellite channel, mobile antenna, op-tical carrier, etc.), providing QoS end-to-end betweendifferent network domains is hard to be achieved andcannot be resolved with the bridge-federate based onthe DDS-RS.

In contrast, our Proxy DDS approach providesmore scalable and QoS-aware communication be-tween isolated DDS domains. Proxy DDS also op-timizes the utilization of network resources and en-hances the scalability, as shown in Section 4.2.2. Inaddition, Proxy DDS incurs no single point of fail-ure, i.e., if one proxy fails all other proxies continueworking correctly, and a notification is sent to alterapplication participants about this failure.

2.3. Related Work on DDS-based and Pub/Sub QoSManagement

Enterprise DRE systems increasingly use DDSmiddleware to disseminate data over large-scale net-works [2, 12]. To ensure end-to-end interoperabil-ity without requiring proprietary bridges [38], theOMG defined a DDS Interoperability (DDSI) proto-col [43] that enables seamless QoS-enabled communi-cation between DDS implementations from differentsuppliers. DDSI was designed to operate in stableand controllable environments (such as LANs andon-board embedded systems) since it enables plug-and-play connectivity to simplify discovery of par-ticipants. The DDSI discovery may be sufficient forsmall to medium networks, but not for less determin-istic environments, such as WANs, where the DDSI

6

multicast discovery packets will be dropped by theedge networks and hence will not reach participantson remote end-systems.

Mechanisms for matching DDS domains usingDDS-ESB (Enterprise Service Bus) integration archi-tecture was proposed in [47]. Their approach enabledan integrated architecture between DDS middlewareand ESB to allow exchanging information betweenDRE systems and the enterprise system. AlthoughDDS-ESB focused on using DDS as a web servicetransport to increase interoperability between DDSimplementations, it did not increase the scalabilityof DDS-based enterprise DRE systems. In contrast,the work we present in this paper does not use webservices as a transport mechanism between disjointDDS domains, but instead enhances the standard SIPprotocol to ensure interoperability of DDS implemen-tations and increase scalability in WANs.

The Instant Message framework [49] was proposedto integrate DDS with instant messaging services andto enable publishing DDS topics across existing IMSnetworks. This approach, however, uses a best-effortbased point-to-point architecture that is not well-suited for the many-to-many communication modelof DDS. In contrast, the work presented in this pa-per provides a QoS-enabled distributed architecture,which enables dynamic resource management undernetwork load for many-to-many communication, i.e.,all Proxy DDS components communicate with eachother at the same time.

Finally, many pub/sub standards and technologies(e.g., Web Services Brokered Notification [42] and theCORBA Event Service [17]) have been developed tosupport distributed event-based systems [22]. Thesestandards and technologies, however, do not providefine-grained and robust QoS support, but instead fo-cus on issues related to monitoring run-time applica-tion behavior in a scalable manner. They thereforedo not address key open issues, such as end-systemQoS policies for reserving the network resources andsimplifying the control of the network behavior [28].

In contrast, the work presented in this paper en-ables more effective control of applications in en-terprise DRE systems via the Proxy DDS (whichmaps the bandwidth, latency, and jitter QoS require-ments to the underlying WAN as described in Sec-

tion 3.2.2) and NetQSIP (which allocates the networkresources as required by DRE applications withoutover-provisioning the network equipments).

2.4. Related Work on Other Middleware andNetwork-level QoS Management

Most applications of DDS in DRE systems eitheruse LANs or small-scale WANs whose QoS proper-ties are relatively stable. In these environments, DDSmiddleware uses IP multicast to allow publishers andsubscribers to operate in a scalable peer-to-peer fash-ion. In large-scale WANs (such as the Internet orenterprise intranets), however, IP multicast is oftendisabled for performance and security reasons.

Overlay networks have been studied as an alternateapproach to shield applications from the heterogene-ity present in WANs. For example, [29] propose in-tegrating an open-overlay framework as part of themiddleware, thereby enabling end-systems to sup-port multiple overlays running composite protocolsto allow dynamic reconfigurability. Hermes [48] pro-vides an overlay broker for event-based middleware toperform the content-based routing. Likewise, TinyDDS [8] is a pub/sub middleware that operates ontop of an Overlay Event Routing Protocols (OERP)layer for event routing. Moreover, [14] propose a dis-tributed hash table (DHT)-based overlay network toperform scalable and efficient discovery scheme forDDS entities over WANs.

In this related work, however, discovery messagesare sent to a limited number of remote nodes, evencommunicating in peer-to-peer fashion. This workalso has a several limitations with enabling end-to-end QoS provisioning, scalability, and performanceof the communication. In contrast, the work pre-sented in this paper does not modify the middlewarelayer to add an overlay network. Instead, the ProxyDDS components provide diverse DDS QoS profilesfor LANs and WANs and provides proxy-to-proxycommunication over WANs, thereby supporting scal-able multicast, as described in Section 3.2.1.

Authors in [33] proposed to adopt an overlay net-work that allows Application-Level Multicast (ALM).Members belonging to the same multicast groupare interconnected through an overlay network [35],

7

where end-systems rather than routers are responsi-ble for replicating messages that are dispatched overseveral distinct out-going links [26]. ALM over over-lay networks has several drawbacks, however, includ-ing lower performance than IP multicast, scaling lim-itations, and degraded network resources caused byincreasing traffic load.

Prior middleware solutions for network QoS man-agement focus on how to add network QoS servicesfor CORBA-based communication [19, 18]. A large-scale event notification infrastructure for topic-basedpub/sub applications has been suggested for peer-to-peer routing overlaid on the Internet [54]. Thoseapproaches can be deployed only in a single-domainnetwork, however, where one administrative domainmanages the whole network.

Extending network QoS solutions to the Internetcan result in traffic specified at each end-system be-ing dropped by the transit network infrastructure ofother domains [6]. For example, [63] presented a net-work communication broker to enable per-class QoSfor multimedia collaborative applications. Even ifthis network broker enhanced the QoS allocation bydifferentiating the traffic processing at the networkedges, it supported neither mobility service manage-ment nor scalability since it adds complicated inter-faces to both applications and middleware for theQoS notification.

The peer-to-peer architecture described in [4, 16]is designed to ensure data delivery with expectedQoS-levels to reliably disseminate events and bal-ance data distribution load in non-multicast-enabledWAN deployments. Likewise, [62] proposes a service-oriented architecture to integrate remote DRE sys-tems over the Internet based on the data-centricpublish-subscribe model. These prior efforts, how-ever, do not support network resource provisioningrequired to ensure end-to-end QoS. Finally, [23] fo-cused on priority reservation and QoS managementmechanisms that can be coupled with CORBA at theOS level to provide flexible and dynamic QoS provi-sioning for applications running in DRE systems.

The work reported in this paper enhances priorresearch on QoS management at the network layerby integrating QoS along two key dimensions: (1) thehorizontal direction, i.e., between different adjacent

layers in the application, middleware, and network,and (2) the vertical direction, i.e., within a particularlayer. In particular, our NetQSIP framework mapsapplication flow requirements into the DDS layer toallow end-to-end QoS provisioning.

Our prior work [30] on Velox used an MPLS tunnel-ing mechanism to propagate DDS QoS over an over-lay model. Velox statically created a logical tunnelbetween remote DDS participants to conduct QoS ne-gotiation and resource reservations. Any time com-munication failed, however, the user had to recon-figure the network manually. Moreover, applicationrequirements could not change during runtime com-munication between participants.

This current paper enhances our prior work onVelox and overcomes its limitations by defining theProxy DDS, which communicates with the otherproxies without using any tunneling mechanisms. Asdescribed in Section 3.2.1, our Proxy DDS compo-nents do not require an overlay model to match dis-tributed participants through the network. More-over, our NetQSIP framework provides dynamic QoSmanagement and simplifies resource management byusing SIP to automate end-to-end QoS provisioning,which described in Section 3.2.3.

3. Supporting DDS QoS Policies over WANs

This section focuses on the following two capabili-ties we developed to support DDS QoS policies overWANs:

Interconnecting isolated DDS domains viathe Proxy DDS, which matches isolated DDSdomains to distribute topics and reduce the traf-fic exchanged between remote DDS participantsin a WAN.

Simplify network resource managementvia the NetQSIP policy-driven QoS frame-work, which leverages the Proxy DDS, SIP, andthe Common Open Policy Service (COPS) pro-tocol for Diffserv Resource Allocation (COPS-DRA) [56] to automate end-to-end QoS provi-sioning and mapping DDS sessions from appli-cation participants to the underlying WAN.

8

3.1. Supporting DDS QoS Policies Efficiently andScalably in WANs

Below we describe several challenges that arisewhen attempting to use conventional DDS implemen-tations for enterprise DRE systems running in WANs.

3.1.1. Challenge 1: Mapping DDS domains tonetwork-level mechanisms

Context. DDS middleware provides QoS policies andmechanisms for DRE systems that run in stable andcontrollable LANs. As these environments grow incomplexity and scale, it becomes necessary to deployDDS-based DRE systems in WANs. End-to-end QoSrequirements for these enterprise DRE systems stillrequire bandwidth, lossless delivery, and interoper-ability even among disjoint DDS domains. In partic-ular, DDS implementations should disseminate mes-sages from publishers to subscribers under bandwidthfluctuations without overloading the capacity of theWAN, even between disjoint DDS domains.

Problem. The DDS domains of enterprise DRE sys-tems are deployed over different network-domains,where each one is administrated only by a singleprovider, on which the policies and administrationcan differ, i.e., one provider may not have the fullcontrol over the network. It is hard to obtain the ex-pected QoS at the overlay level, and they may havevarious restrictions (such as not allowing multicasttraffic, using different protocols and policies that de-pend on how routing tables are created, etc.) thatmay affect QoS.

The DDS standard does not specify how to dis-tribute topics between independent data spaces. Forexample, OpenSplice DDS (www.prismtech.com/opensplice) provides network partitions that en-able WAN communications, but does not propagateQoS across a WAN. Likewise, RTI Connext DDS(www.rti.com/products/dds/) provides a unicastservice for propagating QoS policies across a WAN,but does not provide a mapping of these policies inedge routers, which require advanced APIs for queuemanagement. In both cases, multiple DDS domainsare not supported unless custom gateways/bridgesare used, which still does not resolve WAN-level QoS

problems, such as scalability and delivery guaranteesend-to-end.

One approach is to use point-to-point IP encapsu-lated tunnels, such as VPN-MPLS [50, 41, 1]. Ourprior work on the Velox framework [30] used MPLStunneling mechanism to propagate DDS QoS overan overlay model. Although this work demonstratedhow standard DDS QoS policies can be supportedend-to-end in WANs, the Velox framework had thefollowing limitations:

It did not support multiple DDS domains withinter-domain traffic; rather it assumed that allparticipants shared the same global data-spacethrough different IP network domains.

Its QoS management was static, i.e., the networkconfiguration was done only once during systeminitialization and hence it could not support dy-namically changing application requirements.

It used the Multi-Protocol Layer Switching(MPLS) [41] tunneling mechanism to propagateDDS QoS over an overlay, which lacks robustmeans to ensure end-to-end semantic consistencyof QoS policies and requires manual user inter-vention during initial configuration, as well asreconfiguration after failures.

Solution summary. Section 3.2.1 describes how weaddress Challenge 1 by introducing the Proxy DDS,which is a software component for enabling efficientand seamless communication between participants inisolated domains. The Proxy DDS scalably decouplesDDS participants in time/space and minimizes trafficexchanged between these participants.

3.1.2. Challenge 2: Enabling scalablemulticast-based DDS discovery inWANs that cross IP network domainboundaries

Context. The DDS discovery service is used by DDSapplications for automatic publication and subscrip-tion discovery and enables QoS-enabled DRE systemarchitectures without the need for any centralizedbroker. This service periodically sends heartbeat dis-covery messages to remote nodes to check whether

9

www.prismtech.com/opensplicewww.prismtech.com/opensplicewww.rti.com/products/dds/

these nodes are still alive and able to receive data(e.g., processes discovery events generated by un-derlying DDS middleware and notify DDS partici-pants whenever change occurs in the discovery ser-vice). Communication between nodes uses the stan-dard DDS request/offered (RxO) contract in whicheach participant presents compatible QoS parametersto enable sending and/or receiving of data.

Problem. To enhance DDS applications QoS overWANs, DDS discovery mechanisms should enablethe efficient and scalable exchange of topics betweendistinct data spaces. Typical LAN-based implemen-tations of DDS uses IP multicast, which does notscale to WANs. DDS multicast services in WANsmust therefore deal with the following deploymentproblems:

Multicast discovery messages are often blockedin edge routers and do not reach remote networkssince IP multicast is often disabled whether forsafety or performance reasons.

IP multicast forces routers to maintain per-group state (e.g., members to the group) that(1) is highly variable over time and (2) imposesscalability and reliability penalties. IP multicastoften incurs performance limitations on routers(e.g. it fails to filter incoming messages beyonda few dozen multicast groups), so IP multicastdoes not scale to a large number of groups [60].

The deployment of IP multicast requires allrouters to be appropriately configured, whichmakes it quite impractical in large scale or opensettings, i.e., where one does not have full con-trol over the networking environment.

Solution summary. Section 3.2.2 describes how weaddress Challenge 2 by describing NetQSIP, whichis a middleware framework that bridges the gap be-tween DDS applications and SIP to allow communi-cation between distributed participants over isolatedDDS domains. It also supports end-to-end QoS sig-naling to all distributed participants to leverage thelimitations of IP multicast without affecting the dis-covery protocol.

3.1.3. Challenge 3: DDS QoS provisioningwith the DDS domain overlays that sub-sume multiple network domains is hard

Context. To simplify the development and evolu-tion of applications for enterprise DRE systems, thedetails of interacting with low-level network QoSmechanisms for provisioning and resource allocationshould be encapsulated within a middleware signalingservice API. One way to implement such a signalingservice involves using the Session Initiation Protocol(SIP) [53, 10] to request only the desired resources forthe DDS application and avoid the over-provisioningof WAN resources [40].

Problem. The following problems must be addressedto use SIP effectively as the basis for a high-levelsignaling service for DDS:

Semantic gap between SIP and DDS. SIPuses predefined Session Description Protocol [31](SDP) messages to allow the communication be-tween SIP-compliant clients. These messages usespecific media attributes for SIP that do not in-clude any fields for the standard DDS QoS poli-cies.

Respecting the DDS requested/offered(RxO) contract model. DDS QoS policiesshould respect the RxO contract model thatmatches publisher QoS needs to subscriber QoScapabilities. DDS implementations use the DDSRxO contract model described in Section 2.1to ensure that communication only occurs whena QoS policy requested from one participant iscompliant with a QoS policy offered by anotherparticipant. SIP by itself does not support theRxO model.

Choice of the exact DDS QoS policies.Most DDS QoS policy settings are not modifiableat run-time and must therefore be designatedbefore compiling the DDS applications them-selves. Only QoS policies that control simultane-ously topics, data readers, and data writers cantherefore be used to control the end-to-end path.These policies must be generic for all DDS imple-mentations to allow interoperability between dif-

10

ferent middleware vendors. Since SIP does notunderstand the semantics of DDS, it cannot na-tively support such QoS configurations.

Incompatibility of a SIP codec with a DDSsession. SIP allows applications to select theappropriate codec to adapt their bandwidth withthe network load. SIP clients must thereforeagree on the codec they want to use to adapttheir sending rate to fulfill the required QoS. Thecaller sends a codec map as part of its initial in-vite message so the receiving application can se-lect the appropriate codec and adapt their band-width to the network load. In contrast, however,DDS has no notion of a codec to adapt the pub-lish rate. It is therefore necessary to adapt DDSQoS profiles to SIP signaling mechanisms withrespect to their traffic profile. In particular, aDDS signaling service needs to specify the net-work QoS support and the session managementthat can provide the different DDS QoS proper-ties.

Lack of resource reservation mechanismsin edge routers. Although SIP can trans-port the QoS requests (including bandwidth, la-tency, and class of service) sent by DDS appli-cations within their signaling messages to notifythe network about the applications QoS require-ments [59], it cannot reserve the resources to ful-fill these requirements. Advanced QoS provision-ing mechanisms are therefore needed to imple-ment QoS requests in edge routers of each net-work domain.

Solution summary. Section 3.2.3 describes how weaddress Challenge 3 by integrating Proxy DDS andNetQSIP so that Proxy DDS components carry QoSpolicy messages in SIP control messages. NetQSIPsimplifies resource allocation by automating end-to-end QoS provisioning and provides service-level dif-ferentiation required by applications in DRE sys-tems.

3.2. Supporting Enterprise DRE Systems overWANS using Proxy DDS and SIP Signaling

To address the challenges described in Section 3.1,we now describe the structure and functionality ofProxy DDS and NetQSIP. Proxy DDS enables effi-cient and scalable communication between isolateddomains in a WAN. NetQSIP simplifies DDS resourcemanagement by automating end-to-end QoS provi-sioning over WANs. NetQSIP uses Proxy DDS tomatch distinct and isolated DDS domains over dif-ferent IP network domains, SIP to support end-to-end QoS signaling, and the COPS protocol as a QoSmanager for dynamic resource allocation over Diff-Serv infrastructure.

Below we outline how the challenges described inSection 3.1 are addressed in the remainder of thissection:

1. The Proxy DDS matches isolated DDS domainsand optimizes the bandwidth usage between re-mote participants, as described in Section 3.2.1.

2. DDS QoS policies are mapped into SIP messagesto carry the QoS requests from the applicationto the network, as described in Section 3.2.2.

3. NetQSIP uses these SIP messages to reserve QoSmechanisms in edge routers and provide end-to-end resource reservation, as described in Sec-tion 3.2.3.

3.2.1. Resolving Challenge 1: Create a ProxyDDS to Match Isolated DDS Domains

The Bridge-Federate presented in Section 2.2 suc-cessfully interconnects DDS-based DRE systems sit-uated in isolated DDS domains. This solution onlypartially solves Challenge 1, however, due to exces-sive flow duplications when the number of partici-pants increases, as shown by our empirical results inSection 4.2.1. To address this problem, therefore, weenhanced the Bridge-Federate functionality via a newcomponent we called the Proxy DDS, which does notuse the DDS-RS approach (described in 2.2).

The Proxy DDS provides the same functionalityas the Bridge-Federate model (i.e., it matches iso-lated DDS domains). It also optimizes DDS band-width, even if used over heterogenous IP network do-mains. Instead of using a single software component

11

(the DDS-RS-based Bridge-Federate model), ProxyDDS can deploy many proxies in many IP networkdomains, thereby providing the following capabilities:

Capability 1: Matching isolated DDS do-mains over different network domains andoptimizing end-to-end bandwidth utilization.Each Proxy DDS component subscribes to all topicssent by participants in its IP domain, selects those ofinterest (i.e., topics that will be sent to other remoteparticipants in remote DDS domains belonging to re-mote IP network domain), and retransmits them tothe (virtual) global data space, as shown in Figure 2.

To receive DDS data, each proxy subscribes tothose topics from the global data space and publishes(replicas of) them in its IP domain for interested sub-scribers. Each Proxy DDS component performs thedeployment and configuration of the DDS implemen-tation with respect to application requirements (suchas latency, bandwidth, class of service, etc.). It spec-ifies only the topics exchanged in the virtual globaldata space with remote proxies.

Capability 2: Supporting Multiple QoS pro-files for LAN and WAN. Each Proxy DDS com-municates with both the local participants (in its net-work domain) and the other remote proxies over aWAN. It therefore uses the following distinct DDSQoS profiles:

The first QoS profile ensures consistency be-tween DDS participants in the same IP domain,i.e., the QoS profile should be consistent be-tween all the participants and the Proxy DDSin the same DDS domain (LAN QoS-profile inFigure 2),

The second QoS profile enables communica-tion between different DDS proxies to distributedata in an inter-proxies manner (Proxy-to-ProxyQoS-profile shown in Figure 2).

Capability 3: Ensure interoperability be-tween the DDS QoS-Policies and network QoSpolicies. Each Proxy DDS uses the DDS Trans-port Priority QoS to mark the DiffServ DSCP field ofthe packets sent to other remote proxies. For exam-ple, assume that Proxy DDS1 receives a topic A from

the participants that belong to its IP domain withthe DSCP value equal to 46, which is the IP transportpriority that corresponds the Expected Forward Per-Hop Behavior (EF-PHB). Proxy DDS1 then trans-forms and forwards the messages corresponding totopic A with the DSCP value 10, which correspondsto the Per-Hop Behavior Assured Forward (PHB-AF11).

3.2.2. Resolving Challenge 2: Interface Map-ping between DDS and SIP

To bridge the semantic gap between DDS QoSpolicies and SIP control messages, we developedNetQSIP, which is middleware that resides betweenthe DDS application and the underlying network ser-vice plane (SIP session layer). NetQSIP helps resolveChallenge 2 described in Section 3.1.3 by extendingthe semantics of the SIP media flow attribute (the so-called a attributes) included in the SIP/SDP mes-sage (a set of lines of the form < attribute >=), as shown in Figure 3. Both the publisherand the subscriber use the information carried withinthese attributes to negotiate with the underlying net-work on how the QoS reservation should be done us-ing a new predefined precondition.

As discussed in Section 3.1.3, SIP was designed tosupport codec negotiation between clients. DDS doesnot support the notion of codecs, but instead it hasseveral QoS parameters that may change at runtime.Those QoS parameters are adapted in the context ofSIP to enable dynamic publish rates for DDS-basedDRE applications.

For each DDS topic, NetQSIP defines several QoSprofiles (stored in its topic map) that can replace thecodec map used by SIP. As an enhancement to thestandard SDP in [51], we devised new DDS QoS at-tributes and syntax to incorporate into the signalingprocedure. The DDS publisher and the subscriber ex-change SIP messages that include the resource reser-vation demands in the topic map and the current sta-tus to support the QoS demands in each direction.The qos-dds token described in Table 2 specifiesthe QoS policies carried within the SIP/SDP Invitemessage for the dynamic network QoS allocation.

Table 3 also shows the new qos-dds token wecreated to support the specific DDS-based QoS re-

12

Figure 2: Matching Disjoint DDS Domains Over Different Network Domains

Field Description

Dead-line

Data reader expects a new sampleupdating the value of each instance atleast once every deadline period. Datawriter indicates that the applicationcommits to write new value for eachinstance managed by this data writerat least once every deadline period.The Deadline is a duration 0 0.

Latency The delay from data writing until itsdelivery is inserted in the receiversapplication cache and the receivingapplication is notified of the fact. TheLatency Budget is duration 0 0.

Relia-bility

the reliability of the service. Could beReliable (R) or Best Effort (BE).

Priority Transport Priority is a hint to theinfrastructure used to set the priorityof the underlying transport used tosend data in the DSCP field forDiffServ. This value is presented as aninteger.

Table 2: Encoding the DDS QoS policies in the qos-ddsFields

quirements, which contains the Offer/Answer SDPextension specified in RFC3264 [51].

Table 3: SIP Invite Message with the New a Including theqos-dds Token

INVITE sip:ahkiri@laas.org SIP/2.0Via:SIP/2.0/UDP 193.49.97.17Via:SIP/2.0/UDP 193.49.97.81From:sip:ahkiri@iptel.orgTo:sip:ahkiri@laas.orgCSeq: 1 INVITEo = akram 53655765 2353687637 IN IP4 193.49.97.18s = -c = IN IP4 ahkiri@laas.orgt = 0 0b = AS:512a=qos-dds-send: current 0 20000000 0 20000000 R 46 senda=qos-dds-recv: current 0 20000000 0 20000000 R 32 recv

The qos-dds token identifies a QoS mechanismthat is supported by the entity generating the ses-sion description. A token that appears in a qos-dds-send attribute identifies DDS QoS policies sup-ported by data writers to help the resource reser-vation for traffic sent by publishers generating SDPmessages. A token appearing in a qos-dds-recv at-tribute identifies the DDS QoS policies that can be

13

a = status-type SP qos-dds SP direction-tag

status-type = ("desired" "current" "acceptable" "unacceptable")

SP = space

qos-dds = ("deadline" "latency" "reliability" "priority")

direction-tag = ("send" "recv" "send-recv")

status-type:

- desired: DDS participant indicates the DDS QoS he wants to use.

- current: informs the remote DDS participant about the QoS DDS

to be used in the current session.

- acceptable: indicates that the DDS QoS is acceptable and

compliant with the R/O contract.

- unacceptable: indicates that the current DDS QoS policies

are not compliant with the R/O contract (reject the communication).

direction-tag :

- send: DDS participant indicates it desire to send topics (Publish mode).

- recv: DDS participant indicates he wants to receive topics (Subscribe mode).

- send-recv: DDS participant indicates that he wants to send and receive topics

(both Publish mode and Subscribe mode are supported).

Figure 3: The New SDP Attributes for DDS with Preconditions

supported by data readers to reserve the resourcesfor traffic coming from DDS publishers. These ex-tensions remain transparent to the edge router andwork seamlessly in the context of DiffServ networks.

We used the SDP session description attributespresented in Figure 3 to describe the new offer/-answer extension that supports signaling for DiffServ.These attributes describe a DDS communication re-quest for total bandwidth of 512 kbits per second(designated in line b) with the following qos-dds-send and qos-dds-recv attributes of the DDS me-dia session:

Offer/answer behavior. When using qos-dds-send and qos-dds-recv attributes, an offer/answernegotiation is done between the publisher and thesubscriber to allow endpoints to load a list of DDSQoS profiles. Participants negotiate the direction inwhich those profiles are exchanged with respect toboth preconditions [9] and DDS changeable table pa-rameters [44]. Participants also use other QoS pa-rameters (e.g., the bandwidth, jitter, delay param-eters described in RFC3312 [11]) to negotiate per-Class QoS setting for DiffServ.

Offer behavior. The publisher includes qos-dds-send flow information in the publication direction

to inform subscribers about the DDS QoS profilessupported by publishers. Similarly, a participant canuse qos-dds-recv attributes to specify which kindof QoS policies can be supported at subscribers.

Answer behavior. After receiving an offer froma remote participant with the qos-dds-send at-tributes, NetQSIP translates those attributes intonetwork QoS settings for the resource reservation pro-cess. These attributes correspond to the DDS QoSpolicies within the QoS profiles supported in the sub-scriber direction. A participant uses these attributesin a qos-dds-recv attributes in the answer. Forexample, when a participant receives an offer withqos-dds-recv attributes, the answerer uses the cor-responding QoS translation mechanisms it supportsin the publisher direction and then includes them inthe qos-dds-send attributes.

3.2.3. Resolving Challenge 3: SupportingPubSub QoS properties over WAN

To support QoS signaling and resource provision-ing over WANs, the Proxy DDS uses NetQSIP totransport DDS QoS policies within its control mes-sages. These messages include the information (e.g.,bandwidth, latency, priority, etc.) about applica-

14

tion requirements. DDS applications interested inpublishing data can specify the media description bysending SIP control message to the network. If theirrequests are accepted, then the required resourcesare allocated, and they can securely exchange data.These features are part of the NetQSIP framework,which provides:

A resource allocator (defined as a part of theProxy DDS) to use these messages for signalingthe QoS to the network on behalf of an applica-tion;

A policy-based network configurator to enforcethe resource allocation in the network infrastruc-ture.

Enhancing the Proxy DDS for QoS Signaling. In ad-dition to the functionality presented in Section 3.2.1,the Proxy DDS maps DDS sessions between an ap-plication and the underlying network. We enhancedthe Proxy DDS to include the DDS QoS policies us-ing the JAIN SIP [25] [24] proxy. We also extended itto parse the new a attribute that support the QoSpolicies described in Section 3.2.2.

The enhanced Proxy DDS acts as a resource allo-cator that communicates with the DDS participantvia the SIP/DDS interface and intercepts the DDSQoS policies from the SDP message. It also commu-nicates with the QoS configurator to provision keytraffic control, classification, and shaping propertiesof the priority queue. In addition, it infers the ses-sion characteristics (such as bandwidth, the prior-ity level (DSCP), the sender/receiver IP addresses/-Ports) from an XML file (an excerpt of which is shownin listing 1).

Listing 1: QoS Policies Provided by DDS Middleware

193.49.97.81

54100

105544000

185004001024103

1000000

60Realtime

54110

Figure 4: Session Register and Deregister with proxies

For example, since SIP does not allow sending datain multicast, we configured the source and the des-tination IP addresses in the attributes NetworkIn-terfaceAddress and GlobalPartition, respectively.The attribute PortNr specifies the port numberon which each DDS participant receive data. Like-wise, the attribute DiffServField allows specifyingthe value that will be used to mark the DSCP field,which may change at runtime if a participant decidesto change it. The attributes MaxBurstSize (topicsize in bytes) and Resolution (in ms) describe thepublish rate (i.e throughput calculated at runtime

15

by the DDS middleware) at which the publisher cansend DDS topics. The publish rate is defined by therelation: rate = (MaxBurstSize 8 ( 1000Resolution ))(b/s).

The application contacts the Proxy DDS duringthe registration phase to access to the registrar, asshown in Figure 4.

The registrar receives two the QoS requests sentby the publisher and the subscriber. It then forcesall signaling messages to pass across it with theheader record route and intercept those messagesto analyze the information about the session. Af-ter the publisher is configured to make and receivecalls, NetQSIP processing begins with the registra-tion phase in the registrar (user registration in theSIP location database).

We considered the case where the registration isdone by both remote SIP proxies of each network:the publisher sends a register request to the proxybelonging to its network domain which intercepts itand adds the address of record (AddressOfRecord) toenforce messages to pass through the registrar. Afterthe destination address is found in its local database(local database to avoid the usage of a DNS), it redi-rects the message to the destination. The remoteproxy (belonging to the same network domain of thesubscriber) intercepts this message, checks if the sub-scriber belongs to its domain, and forwards the In-vite message to it if it belongs to the domain.

Network QoS configurator for resource reservation.To reserve QoS in the edge-router, we devel-oped a resource configurator based on the COPS-DRA [56] protocol as part of the NetQSIP frame-work. NetQSIP also integrates the resource allocatorin the Proxy DDS to translate the DDS QoS poli-cies in the SIP/SDP messages into network QoS, andnegotiate the DDS QoS policies on behalf of the ap-plication. These translation requests are submittedto the resource configurator which configures the pri-ority queues of the edge-router based on the DSCPmarking for IP packets with the Transport PriorityDDS QoS setting. Below we describe the QoS nego-tiation during the signaling process.

Session initiation. The publisher (shown asDDS participant A in Figure 5) sends the Invitemessage including a list of DDS QoS profiles with thesource/destination IP addresses, the ports number,the DDS QoS attributes, the DSCP field descriptor,and the media descriptor.

This message indicates the direction for exchangingDDS topics between remote participants (forwardingand back to topic flows with qos-dds-sendrecv to-ken). When the publisher wants to change the DDSQoS profile, it sends a message including qos-dds-send token with the desired status. If the pub-lisher wants to receive the DDS QoS profiles, it sendsmessage including qos-dds-recv token also with thedesired status. In this case, the following two sit-uations can occur: Situation 1. The remote DDSparticipant B (subscriber) receives the list of DDSQoS profiles (topic map) and intersects it with its ex-isting profiles. For DDS to match the publisher withthe subscriber, they both need to agree the RxO con-tract, which indicates their QoS profiles are compli-ant. They should find the common parameters in theQoS profiles (i.e., DDS QoS parameters described inTable 2 and carried by SIP invite message). Sinceseveral QoS profiles are grouped in topic map, pub-lishers and subscribers only need to select the compli-ant ones, (i.e., the publisher profile should be com-pliant with the subscriber profile) via the followingsteps:

1. If subscriber B supports at least one DDSQoS profile satisfying the RxO contract, it willcan reply with an acceptable status. It there-fore selects the first DDS QoS profile compliantwith the RxO contract and compares the IP ad-dresses and port numbers on which it can re-ceive DDS topics as described in the XML fileshown in Listing 1. As described in Figure 5,the subscriber then sends the response 183 Ses-sion In Progress with the acceptable status toits Proxy DDS, which forwards the reply to theremote publisher A. The proxy forwards thismessage to the publisher and indicates that thesession has been established in both directions.

2. Proxy DDS next sends a reservation request viathe NetQSIP resource allocator, which triggers

16

Figure 5: QoS Reservation within SIP/DDS Session

the resource reservation process as described inFigure 6. The NetQSIP resource configuratorintercepts this request to negotiate the requiredQoS with the edge router. This informationcalled QoSStateis stored by the proxy DDSto keep track of the session.

3. Proxy DDS then sends a QoS request (embed-ded within the SDP message) to the resource al-locator in the remote domain B to request theQoS in both directions. The publisher subse-quently sends a Prack [52] message to confirmthe 183 Session in Progress has been receivedand waits for subscriber B to send the 200OKmessage (for Prack).

4. The session establishment is confirmed whenboth proxies (for participants A and B) ex-change 200OK and ACK messages. The pub-lisher starts transmitting data to remote sub-scribers and the data path is established.

The qos-dds attributes include the DSCP prior-ity tag the publisher has added to SIP/SDP Invitemessages (described by the Transport Priority DDSQOS policy). The resource allocator sends the re-quest message (REQ message) to the resource config-urator to install the desired QoS. The resource con-figurator analyzes the request (consults its databasefor verification), performs the DiffServ resource allo-cation, and replies to the resource allocator with a

17

Figure 6: Session Establishment with DDS QoS Support

decision message (DEC) message.

The resource configurator uses the DSCP value toclassify DDS traffic regarding their priority in eachedge-router. An XML parser translates the follow-ing QoS settings: latency budget, deadline in thea field into bandwidth, latency, and jitter. The re-source allocator subsequently generates a report mes-sage RPT to indicate the success of the decision.The 183 session in progress message is also sentto the publishers Proxy DDS to indicate successfulresource allocation in its direction.

The DDS discovery protocol performs discovery inboth direction. The neighbor discovery is providedfrom the information (IP addresses) provided by theproxy and registrar near to each DDS participant, sothat the interconnection between distinct DDS do-mains can be easily performed. NetQSIP matchesDDS data writers and data readers by sending pub-/sub declarations embedded within DDS messages,which include a Globally Unique ID (GUID), QoSpolicies, etc.

Situation 2. Two cases must be consideredif the subscriber does not support any DDS QoSprofile satisfying the required QoS (e.g., Trans-port Priority=0). The first case is shown in Fig-

ure 7 where no DDS QoS profile can be used to im-plement the network QoS. This case corresponds tothe default best-effort service without QoS that canbe established at the network level. In the secondcase there is a violation of the DDS requested/of-fered (RxO) contract between the publisher and sub-scriber. Since session establishment cannot occur theNetQSIP proxy thus sends a rejection message backto the first DDS publisher with the status token fixedat Unacceptable to reject the communication.

Session Liberation The session termination isshown in Figure 8. When the publisher wants to fin-ish the session, it sends a Bye message to the remotesubscriber, which replies with a 200OK message (forBye). The deregistration procedure from the prox-ies is performed similarly to the registration phase: aregister message, almost similar to the registrationmessage, is sent with the the Expires field set to 0.When the publisher sends a Bye message to its near-est Proxy DDS component, this component sends theQoS FREE message to the resource allocator to re-quest the liberation of the resources. The resourceconfigurator receives this message and sends an unin-stall message to release the allocated resources at

18

Figure 7: Session establishment without QoS (Best-Effort service)

the end of session. After releasing the resources, thesubscriber sends the 200 OK message to reply to theBye message.

4. Experimental Results and Discussions

This section analyzes the results from experimentswe conducted to evaluate the efficacy of the ProxyDDS components and NetQSIP framework presentedin Section 3.2. Section4.2 evaluates the performanceof the Proxy DDS against the Bridge-Federate inthe best-effort QoS architecture described in Sec-tion 4.2.1. Section4.3 evaluates NetQSIP in termsof its timing behavior, overhead, and end-to-end la-tencies observed in different scenarios.

4.1. Hardware and Software Testbed and Configura-tion Scenario

The performance evaluations reported in this pa-per were conducted in the Laasnetexp testbed shownin Figure 9. Laasnetexp consists of a server and 38dual-core machines that can be configured to run dif-ferent operating systems, such as various versions ofWindows and Linux [46]. Each machine has fournetwork interfaces per machine using multiple trans-port protocols with varying numbers of senders, re-ceivers and 500 GB disks. The testbed also con-tains four Cisco Catalyst 4948-10G switches with 24

10/100/1000 MPS ports per switch and three JuniperM7i edge routers connected to the RENATER net-work 3.

To serve the needs for the emulations and real net-work experiments, two networks have been created inLaasnetexp: a three-domain real network (suited formulti-domain experiments) with public IP addressesbelonging to three different networks, as well as anemulation network.

In our evaluation scenario, a number of real-timeDDS applications sent their monitored data to eachother so that appropriate control actions are per-formed by the military training and Airbus FlightSimulators we used. Figure 9 shows several simu-lators deployed on EuQoS5-EuQoS8 blades commu-nicating based on the Opensplice DDS middlewareimplementation 4. To emulate network traffic behav-ior, we used a traffic generator that sends UDP trafficover the three domains with configurable bandwidthconsumption.

3http:www.renater.fr4http://www.prismtech.com/opensplice

19

http:www.renater.frhttp://www.prismtech.com/opensplice

Figure 8: Session Termination and Resources Release

4.2. Evaluation of the Proxy DDS in a Best-EffortWAN

Below we present the results of experimentsconducted to evaluate the Bridge-federate in Sec-tion 4.2.1 and the proxy DDS in Section4.2.2. Theseresults evaluate the bandwidth and the overhead ofboth solutions and show the impact of using theProxy DDS to replace the Bridge-Federate implemen-tation described in Section 2.2 .

4.2.1. Evaluating the Bridge-Federate Model

Below we describe the results of evaluating the per-formance and overload of using the Bridge-Federatemodel to interconnect disjoint DDS domains inDomain-Bridge model and compare these results withan implementation of the Topic-Bridge model.

Evaluation of the Domain-Bridge Model.

Rationale. The Domain-Bridge model enablesmatching application running in a data space by cre-ating a bridge between data writers and data read-ers in two isolated DDS domains. It ensures that

all events occurring in DDS domain A (with do-main id 0) should be notified to other participantsin remote DDS domain B (with domain id 1). EachDDS participant is described in a global XML-basedconfiguration file, as shown in Listing 2.

Listing 2: Bridge-Federate Configuration as a Domain-Bridge

0 1

true

**

ON_DOMAIN_AND_ROUTE_MATCH

**

ON_DOMAIN_AND_ROUTE_MATCH

20

Figure 9: Laasnetexp testbed

true

**

ON_DOMAIN_AND_ROUTE_MATCH

**

ON_DOMAIN_AND_ROUTE_MATCH

The example in Listing 2 includes the topics to

transfer during the DDS session and the behavior tofollow to route them to different DDS domains.

The Bridge-Federate model creates a virtual net-work link (called a global routing domain) betweenDDS domain A to DDS domain B to transfer all top-ics from one data-space to its neighboring domains.It also allows a bi-directional connection between sev-eral DDS sessions. These DDS sessions contain thefollowing information:

Session 1 includes the input domain (with do-main id 0) as Input, comprising all partici-pants generating topics, and the output domain(with domain id 1) as Output, to which top-ics will be redirected and

Session 2 defines the reverse operations, e.g., thenecessary information to transfer topics from do-main B (with domain id 1) to domain A(with domain id 0).

21

Analysis This test considers a publisher sendingDDS topics (with a key UserID and a Content-type sequence of bytes) to remote subscribers asshown in Figure 10. The experiments described in

Figure 10: Domain-Bridge Deployment Between Disjoint DDSDomains

Figure 11 showed that all topic instances sent by apublisher in DDS domain A) are forwarded to ev-ery subscriber on DDS domain B). As we increasedthe number of subscribers in the DDS domain Bwe found that the traffic transmitted between dis-tributed nodes is proportional to the number of re-mote subscribers. When the number of subscribersincreases, the stream sent by the publisher is also du-plicated proportionally to the number of subscribersidentified by the DDS Discovery service. For N sub-scriber nodes, therefore, the traffic exchanged is mul-tiplied by N .

Although the Domain-Bridge allows matching dis-tinct DDS domains (A and B), topics are dupli-

Figure 11: Traffic Exchanged Using the Domain-Bridge

cated by the Bridge-Federate, which is not manda-tory. The configuration of the Bridge-Federate in theDomain-Bridge model added a new problem of flowduplication. This solution is considered partial sinceit routes the traffic between two different IP networkdomains, but does not optimize bandwidth utiliza-tion.

Evaluation of the Topic-Bridge.

Rationale. In addition the Domain-Bridge de-scribed above, the Bridge-Federate model can be usedas a Topic-Bridge to perform data transformation be-tween distinct DDS domains, transforming topics inthe DDS domain A (with domain id 0) by pub-lishing them to another topics having the same datacontent to the DDS domain B (with domain id1). The Listing 3 depicts how the Topic-Bridgeperforms this operation.

Listing 3: Bridge-Federate Configuration as a Topic-Bridge

0

1

ShapeType

Square

ShapeType

Square

In particular, this figure shows that the Topic-Bridge creates only a single session to take data from

22

participant 1 (as an input participant), reads the reg-istered topic type-names, and transforms them toparticipant 2.

To check whether the bandwidth utilization de-pends on the number of subscribers to these topics,this test consists of publishing topics (e.g., squaresin Figure 12) from participant A and subscribing tothem by DDS subscribers (Participants B and C)in different network domains and different DDS do-mains. The purpose of this configuration is to per-form topic transformation from DDS domain A toDDS domain B (as shown in Figure 12), therebytransforming topics published on domain A to an-other topics having the same data content on do-main B. Figure 12 also shows how the Topic-Bridge

Figure 12: Experiments with the Topic-Bridge Model

model can regenerate the original topics, even whenthe number of exchanged topics between different ma-chines is high.

Analysis Figure 13a shows the traffic flow sentby the publisher in participant A and receivedby the remote subscribers (participant B andC): traffic (1) describes the flow sent by publisherat 20Kbps (distribution of a single topic instance(square)) and traffic (2) shows topic data receivedby the DDS-RS at 40Kbps, which corresponds to asubscriber registering for two topic instances (circleand triangle).

Figure 13b shows the traffic sent and received bythe Topic-Bridge on participant B. In this sce-

(a) Outgoing Bandwidth Captured on Participant A

(b) Data Flow with the Topic-Bridge

Figure 13: Traffic Exchanged Using the Topic-Bridge

nario, traffic (1) describes topics received by partici-pant A which is the same traffic (1) on Figure 13a.Traffic (2) shows topic data published by participantA to the bridge. Traffic (3) shows topic data re-transmitted by the bridge and received by participantC at 80Kbps, which corresponds to the distributionof two and four topics instances. From the expecta-tion of Figure 13a and Figure 13b, the volume ofthe traffic published by participant A on the DDSdomain A to subscribers participant B and partici-pant C on the DDS domain B is independent of thenumber of subscribers and the number of publishersat run-time. Instead, it depends solely on the topictypes being exchanged. The Topic-Bridge model de-creased the bandwidth between remote DDS applica-tions in different network domains and different DDSdomains.

Despite the absence of data replication, however,

23

(a) Deployment of Two Proxy DDS Components

(b) Test Scenario Using Proxy DDS Components

Figure 14: Deployment and Test Scenario with Two Proxy DDS

the bandwidth from participant A to participantB is twice big as when they are in the same DDS do-main. This solution therefore does not offer the sameperformance in the case of a single domain DDS. Inparticular, the flow exchanged between participantsshould be optimized to overcome the limits on its flex-ibility, extensibility and scalability when the numberof participant increase, and hence the number of flowsexchanged increase accordingly.

4.2.2. Evaluation of the Proxy DDS

The goal of these experiments is to evaluate ProxyDDS against the Bridge-Federate model in terms ofoptimizing bandwidth and meeting application com-munication requirements in inter-DDS domains.

Implementation and Deployment of the DDS Proxy.We consider the publisher Pub T1 in IP domain 1and DDS domain A sending topic data T1 to a

subscribers in IP domain 2 in distinct DDS domainB, and two proxies at the edge of each network, asshown in Figure 14a. The scenario to distribute DDStopics is as follows:

Step 1: the publisher produces topic instancesT1 and send them to its local neighbors in DDSdomain A using multicast service.

Step 2: The Proxy DDS1 subscribes to this topicT1 and consumes all its samples (in DDS domainA).

Step 3: The Proxy DDS1 stores the topics com-ing from A in a FIFO queue, redistribute T1topic by transforming it into another topic T1(only the name changed). This transformationavoids the pub/sub loop to the same topic byProxy DDS1 (avoid the subscription to T1).

24

(a) Throughput Between Each Proxy and Its Local Neighbors (b) Throughput Between Two Proxies

Figure 15: Evaluation of the Proxy DDS

Step 4: The Proxy DDS2 subscribes to topic T1using unicast service once it is presented on itsDDS domain B, transforms T1 instances to T1instances, and sends all topic to all participantsusing multicast.

Step 5: Subscribes in DDS domain B receiveall samples of topic T1 published by their proxy.

The deployment of these proxies should also en-sure the coherence of the DDS QoS profiles amongdifferent DDS participants in the same DDS domain(between neighbors) and between proxies in differ-ent DDS domains over WAN. These QoS profiles areencoded on XML configuration file, i.e., ensure eachproxy is compliant with the requested/offered (RxO)contract described on each QoS-profile. In addition,the queuing mechanism enables the proxies to adapttheir publish rate under bandwidth fluctuation andavoid packet loss that can occur in WANs.

For example, if the publish rate of Proxy DDS1is much higher than the subscription capacity of thesubscriber proxy, the publisher proxy stores topics onits FIFO queue. It increases dynamically the capacityof the datawriter cache (uses the Resource LimitsDDS QoS policy to avoid consumption excess andforward them later.

Evaluation of the Proxy DDS.

Rationale. We performed several experimentsto evaluate the bandwidth utilization between eachproxy DDS and its neighbors subscribers and be-tween remote proxies. This scenario is depicted inFigure 14b. This figure shows the following:

A publisher (participant A) in DDS domain Asends UserInfo topic and subscribes to Car-Info topic, and many participants that sub-scribe to the UserInfo topic and publish Car-Info topic, all in the same DDS domain B

At the edge of each network many proxies de-ployed to subscribe to topics sent by their corre-spondent proxies and reflect them to their localDDS participants.

Analysis Figure 15a describes the traffic trans-mitted between the Proxy DDS1 and its neighbors inthe same DDS domain A.

Curve (1) shows the throughput for the User-Info topic sent by Proxy DDS1 and received by thesubscriber machine at 15Kbps. Curve (2) describesthe throughput of the CarInfo topic sent from asubscriber to its neighbor Proxy DDS1 at 2.5Kbpsaverage bit rate. Figure 15b describes the band-

25

(a) Without QoS (b) With QoS

Figure 16: Impact of NetQSIP Signaling on Latency

width utilization between Proxies DDS1 and DDS2,the traffic data sent from Proxy DDS2 to its localsubscriber, and the flow transmitted from the neigh-bor subscriber to Proxy DDS2. Curve (1) shows thetraffic exchanged between Proxy DDS1 and ProxyDDS2, which corresponds to the distribution of thetopics UserInfo at 15Kbps. Curve (2) describesthe throughput which results from sending CarInfotopic data between the remote proxies at 2.5Kbps av-erage.

These results show that the traffic exchanged be-tween proxies does not depend on the number of sub-scribers, but depends on the topic types (topic size).In comparison with the Bridge-Federate, the ProxyDDS reduced the traffic and thereby optimizes band-width utilization.

4.3. Evaluation of the NetQSIP Framework

Below we present the results of experiments con-ducted to evaluate the performance of the NetQSIPframework described in Section 3.2.3. These resultsevaluate NetQSIPs latency performance. In partic-ular, we identified two topic flows sent from the pub-lishing application and used them to evaluate the im-pact of NetQSIP on the time delay by (1) generat-ing real-time traffic containing DDS topic messages

that use the DiffServ expedited forwarding per-hop-behavior (PHB) model [5] (whose characteristics oflow delay, loss, and jitter are suitable for voice, video,and other real-time services) and (2) perturbing UDPbest-effort traffic using the Jperf [58] traffic genera-tor, which is a framework for writing and runningautomated performance and scalability tests.

4.3.1. Evaluation transmission delay

Rationale. To study the impact of the NetQSIPresource provisioning mechanisms on the moving av-erage delay, we consider two variants of tests as fol-lows:

1. DDS traffic is generated by DDS participantpublishing SDP messages, which include theDDS QoS policies. These DDS QoS fields aretranslated by the proxy into control messagesto perform QoS allocation. In this configura-tion, the NetQSIP resource configurator does notprovide any QoS mechanism between the pub-lisher and the subscriber. The default configu-ration therefore uses the Best-Effort (BE) serviceand the DDS traffic goes through the best-effortqueues of the edge routers.

2. This variant of the experiments uses the sameQoS mechanism configurations in all compo-nents, as described in Section 3.2.3. NetQSIP

26

configures the DDS application with the DiffServExpected Forward (EF) network QoS class, con-figures the edge routers queues to support 40%Best-Effort (BE) traffic, 30% EF traffic and 20%DiffServ Assured Forward (AF) traffic, and 5%for network control packets.

Analysis. Figure 16 depicts the moving averagedelay between the publisher and subscriber.

The results in this figure confirm that the averagedelay experienced by the NetQSIP QoS managementmechanism (Figure 16b) performs better results thanthe application without using NetQSIP QoS allocator(Figure 16a). The average delay remains 15ms whenusing NetQSIP QoS mechanisms, but without anyQoS consideration in the network the average delayremains 4 times higher (60ms).

To further validate these results, we considered thedispersion and variability of the delay obtained fromtraces (Figure 17). The minimum value of the latencyis 13ms and its maximum value is 16ms. Theseresults confirm the potential of NetQSIP to performnetwork resource reservation. In addition, Figure 18

Figure 17: Statistical Distribution of the Moving Average De-lay

depicts the results of experiments on the competingUDP background traffic injected from Jperf trafficgenerator.

This figure shows the packet delays (ms) and thepacket lost experienced by the competing UDP flow.The delay experienced for the perturbing UDP flow(curve in Figure 18a) increases dramatically up to500 ms due to the impact of the prioritization of theDDS traffic experienced by NetQSIP. The packet lossrate (Figure 18b) reaches 20% for the UDP best-efforttraffic, which has DSCP value 0. UDP packets are

dropped because the buffers of the router queues areflooded by the DDS traffic that should be processedin priority.

4.3.2. Evaluation Session Establishment Delay

Rationale. The parameter that describes the ef-fectiveness of the signaling system is the setup-releaselatency, which is represented by the average (a similarparameter describes the effectiveness of the signalingsystem in telephony networks). DDS session estab-lishment can only be achieved if the proxy sends the200OK message to the publisher and the resourceallocation is achieved. This scenario involves a setof messages that should be negotiated between thecaller participant and the called during the sessionestablishment, as described in Section 3.2.3.

To evaluate session establishment delay, we an-alyzed the performance of the signaling system,i.e., those components that introduce significant de-lay to setup/release latencies. This scenario in-cludes all messages exchanged by DDS participants(i.e., Start DDS session, Invite, 183 Progress,Prack, 200OK Prack, 200OK, and Ack) and themessages (i.e., Decision, Report, Reserve, andResponse) exchanged between the Proxy DDS, theresource allocator, resource configurator.

The setup procedure starts when a publisher sendsan Invite message and is finished on receiving ACKby the subscriber. The 200OK message that reachesthe remote subscriber, however, already informs itabout successful connection establishment. We there-fore define the setup latency as the time elapsed be-tween sending Invite message and receiving 200OKmessage.

Analysis. Figure 19 shows both the overall setuplatency and time delay for each individual SIP mes-sage.

The cumulative time latency shown in this figurequantifies the potential impact of the addition of QoScontrol mechanisms in session establishment. Theresults in Figure 19 also evaluate the potential ofNetQSIP to support the end-to-end DDS QoS poli-cies in WAN-based enterprise DRE systems.

The cumulative transfer delay of 200ms is suffi-cient to establish real-time communication between

27

(a) Packet Delay

(b) Packet Lost

Figure 18: Impact of DDS QoS Mechanisms on the concurrentUDP Flow

end-points. The setup latency for each transactionis around 30ms, which is the average of the accept-able setup latency for end-to-end connection estab-lishment. The time delay achieved by the Inviteand the 200OK messages is 23.8ms and 21.42ms, re-spectively.

These results underscore another benefit ofNetQSIP: additional network processing delays arenot incurred since messages are not intercepted bythe NetQSIP resource configurator at both edge net-works. The 183 session in progress message, how-ever, had a moving average delay of 46.5ms becausethis message incurs additional delay when the mes-sage should pass through the resource configurator.In addition to the data transfer time delay, the timedelay for session establishment is added by the im-plementation of QoS, so the total time reaches values205ms.

Figure 19: End-to-End Session Establishment Latency

4.3.3. Evaluating the QoS Setup Delay

Rationale. The goal of this experiment is tomeasure the temporal impact incurred by NetQSIPsresource configurator during session establishment.These experiments are based on the COPS-PEP con-figured in provisioning mode and the COPS-PDP,which are described in Figure 6. The experiment thusaims to evaluate the latency incurred when the QoSis configured in edge networks.

Latency has been measured many times with morethan 100 messages exchanged between them. Thesemessages are (1) the Request message (req) per-

28

Message Delay (ms)Message req (peppdp) 1.83Message dec (pdppep) 35.56Message rpt (peppdp) 37.94Total 75.33Min 73.5Max 78.22

Table 4: Transmission Delay and Processing Time of NetQSIPMessages (ms)

formed by the resource allocator to request QoS reser-vation to the resource configurator, (2) the Decisionmessage (dec) sent from the QoS configurator to theresource allocator after checking its policy database,to inform it that the session is established with suc-cess, and (3) the Report message (rpt) transmittedby the resource allocator after the reception of thedec message, setting the QoS.

Analysis. Table 4 shows the transmission delayand processing time of NetQSIP messages. The reqmessage requires less than 2ms to reach the resourceconfigurator because it does not involve any specificprocess on it. The dec message requires 35.56ms tobe received by the pep. The resource configuratorstarts processing req message, refers to its internalpolicy database to select the appropriate elements fortriggering dec message, and then triggers all the de-cision process to the resource allocator.

The resource allocator receives the dec message,analyzes the decision being received to implement theQoS policies required by the media sessions, and sendthe rpt report message to the configurator. This pro-cess incurs an average delay of 38ms. The overallmoving average delay for the QoS negotiation on thecontrol plane is thus 75ms, which is accepted forSIP-based communication as an additional delay tothe session setup.

5. Concluding Remarks

Enterprise distributed real-time and embedded(DRE) systems often span wide area networks

(WANs). Quality-of-service (QoS)-enabled publish/-subscribe (pub/sub) communications, such as thetopic-based model supported by the OMG Data Dis-tribution Service (DDS) standard, is a hallmark ofenterprise DRE systems. Realizing WAN-based en-terprise DRE systems is hard for a variety of reasons,including

Lack of connectivity among isolated DDS do-mains that may be geographically distributedacross the WAN,

Lack of IP multicast at the network level thathinders discovery of publishers and subscribersat the WAN-scale, and

Lack of capabilities to enable DDS QoS policiesend-to-end over WANs.

To overcome these challenges, this paper presentsthe design and evaluation of Proxy DDS andNetQSIP, which are middleware that provides net-work QoS signaling for DDS-based applications inenterprise DRE systems running in WANs. NetQSIPhelps configure the underlying WAN transparentlyon behalf of applications by integrating Proxy DDScomponents with SIP. This integration enables ProxyDDS components to connect isolated data-spaces, op-timize the network resources, and automate the QoSmanagement in QoS-enabled IP networks. The re-sults from experiments we conducted quantify theimpact of Proxy DDS and NetQSIP to deliver as-sured QoS to enterprise DRE systems implementedusing DDS and running over WANs.

We learned following lessons from developing andevaluating our Proxy DDS and NetQSIP framework: Autonomic/Self adapting mechanisms are

needed to automate DDS QoS configurations.This paper describes the design and implementa-tion of NetQSIP, which is middleware frameworkthat allows network QoS signaling for DDS-basedDRE-applications. Experiments show the potentialof NetQSIP to deliver guaranteed and certifiable QoSover the Internet. For certain type of DRE systems,however, NetQSIPs strategy for allocating networkresources may be too limiting. In particular, IP-based cyber-physical systems present a challenging

29

environment for network and service management,which requires a new approach.

We are therefore extending NetQSIP to supportadaptive content delivery using ontologies for hetero-geneous mobile systems [13]. For example, to providea QoS-based service selection, DDS applications willrequire tools to decide which network transport pol-icy and which DiffServ service (AF, EF, etc.) fitsits requirements best. The use of ontologies makes itpossible to detect the Service Level Agreement (SLA)to perform matching between DDS application needsand the network service(s) offered at runtime. Thistool will implemented as an adjacent layer to DDSmiddleware to detect the real behavior of the net-work service. Reliable discovery protocol is needed to

enhance the reliability between remote DDSparticipants. This paper described the integrationof Proxy DDS and SIP for request session establish-ment and installing DDS QoS policies at edge routers.The communication between the DDS participantsis based on the unreliable UDP protocol for and in-stalling DDS QoS policies at edge routers. The co