6Sense: Generating New Possibilities in the New Internet.
Produced by: IPv6 Summit, Inc.

DDS and IPv6
by Joe Schlesselman and Mark Hamilton, Real-Time Innovations (RTI)

Adoption of the Data Distribution Service (DDS) standard and IPv6 will be the two most significant IT infrastructure changes mandated by the DoD this year. This article presents a short overview of how each will benefit from the other. We highlight:

  • The DDS standard and its mandated use as a Global Information Grid (GIG) Core Enterprise Service (CES) across the DoD

  • DDS and the IPv4/6 Transition

  • System design with DDS and IPv6

The DDS Standard and the DISR Mandate

The Data Distribution Service (DDS) for Real-time Systems Specification is an Object Management Group (OMG) standard for data-centric publish-subscribe networking. DDS is a mandated standard for use across the US Department of Defense (DoD). DDS has been adopted for use in multiple programs in all branches of the service, as well as in commercial industry.

DDS is a "middleware" standard, created to facilitate the design of highly complex distributed systems. By using a DDS-enabled infrastructure, distributed-system architects do not have to be concerned about network programming or the location of the each application in the system. DDS technology gives distributed systems the ability to share data without regard for the network topology of the system.

Publish-subscribe (also called "push" or "many-to-many") networks are fundamentally different than traditional client-server networks, and enjoy some significant benefits, such as: simplified programming, low latency, fault tolerance, and central-point-of-failure elimination. More complete information on DDS, including introductory slides and whitepapers, is available at www.rti.com/mk/IPv6.

DDS and the IPv4 to IPv6 Transition

DDS is part of the next-generation of middleware standards positioned to take full advantage of IPv6. The first DDS-compliant product (NDDS 4.0 by RTI) was designed from the ground up to support the notion of a Pluggable Transport Framework. This framework gives system architects the ability to design highly complex distributed systems that can 'bridge' between different networks if so required. By leveraging DDS technology, each application within a distributed system can support the ability to anonymously publish and subscribe to data throughout the entire system. The application developer need not be concerned about which specific socket API call to make in order to affect proper communication. The developer simply uses the standard DDS API, and the ability to publish or subscribe to specific data streams is realized, regardless of which network is used within the system.

To route data between different networks (such as Ethernet and FDDI), a traditional router solution had to use multiple "network blades." A DDS solution can accomplish network-to-network routing of topic data using a single application. This allows system architects to use a higher level of data abstraction.

Each distributed application can either be a publisher or subscriber (or both) of data topics. Each application will either publish or subscribe to data topics as necessary, regardless of which network will ultimately provide access to that data. This is made possible by the anonymous nature of the publish-subscribe model. The role of the DDS middleware is to provide efficient transfer of data between applications, whether they are on the same computing node, separate nodes on the same network, or even across multiple networks.

The result is that by using DDS-enabled technology, an application can seamlessly bridge between IPv4 and IPv6 networks-easing the transition from one network technology to the other-while continuing to design and develop applications at a higher layer of abstraction.

Software developers can write their applications now using the DDS API. They may initially be required to use an IPv4-based network. Through the use of the NDDS Pluggable Transport Framework, the underlying network can be transitioned to IPv6, potentially without modifying the application (particularly if advanced DDS QoS are not initially needed, as noted below). This can result in tremendous savings in software development time and effort, and reduce the risk involved in transitioning to IPv6.

System Design with DDS and IPv6

In conjunction with NDDS's ability to support pluggable transports, one of the most significant aspects of DDS is its rich support of application-level Quality of Service (QoS) policies. The DDS specification calls out over twenty specific QoS policies such as: Reliability, Transport Priority, Deadline, Timed Based Filter, Destination Order, Ownership, Durability, and many more. These policies allow system architects the ability to design systems that can efficiently disseminate vast amounts of data throughout an entire distributed system and scale without negatively impacting system performance. Furthermore, many of these QoS policies are mutable and thus allow the application to be designed to tune individual QoS polices, at runtime, in order to dynamically react and adjust to system stimuli. This provides an extremely powerful capability and raises the QoS abstraction to the application layer vs. the transport layer. DDS allows these QoS policies to be associated with specific data topics (data flows), regardless of the network transport employed. DDS technology also provides the ability to realize reliable communication even when using an unreliable transport.

The concept of an IPv6 pluggable transport yields many use cases whereby the IPv6 header fields Traffic Class (also called "Priority" and "TCLASS") and Flow Label (also called "Flow Identifier") are directly associated with DDS QoS policies. While several DDS QoS policies may benefit from IPv6, one of the most intriguing is the DDS Transport Priority QoS. One classic challenge for the system architect is harnessing available technology and network infrastructure to allow multiple streams of prioritized data-with associated application-level QoS-to be delivered in a timely fashion. An IPv6 pluggable transport would certainly leverage the transport's ability to prioritize message traffic via the Traffic Class IPv6 header field. The Transport Priority QoS allows the application to prioritize data-flows based on the traffic classes supported by the underlying transport. So QoS policies could be associated with the data flow itself, and with the prioritization of that data flow.

As the industry's research continues and the IPv6 Flow Label header field becomes more defined, IPv6 pluggable transport designs will adapt to take advantage of the newly available functionality offered by industry routing solutions.

All in all, it's clear that integrating DDS and IPv6 technologies enables an elegant, straightforward method of prioritizing message flow, allowing QoS to be configured and controlled at a higher level of abstraction, and a host of other long-desired benefits-particularly useful in future dynamic ad hoc distributed systems.

Future Directions

While we have identified some fairly obvious significant benefits from combining the individual advantages of DDS and IPv6, we believe that even more use cases await discovery. It will be intriguing to see how some of the newly available features and transition policies develop. Of particular interest will be:

  • Methods for achieving higher sustained throughput by leveraging a larger MTU and Jumbo Frame size

  • IP compression to reduce bandwidth consumption and overhead (particularly interesting in the wireless space)

  • Emerging profiles targeting Path MTU discovery-particularly beneficial concerning end-to-end messaging and fragmentation inefficiencies

  • Header extensions that address payload security, connectionless integrity, and data-origin authentication

Finally, as the industry settles on the definition and usage models of the newly introduced Flow Labels and the continued maturation of the Traffic Class header fields, the ability to prioritize and control individual data delivery across the Internet will emerge as a very compelling capability.

The issues that arise from customer demands, and the industry's responses, will yield capable carrier-class routing solutions that should propel the design of a new breed of applications. These applications will leverage the power and flexibility of prioritized data flow via the publish-subscribe communications paradigm.

For More Information on DDS

For additional information on the DDS specification and its mandate for use by the DoD, please contact:

Joe Schlesselman
Joe.Schlesselman@rti.com
1.408.734.4200 x123

Mark Hamilton
Mark.Hamilton@rti.com
1.410.740.8789