This document provides an overview of data distribution service (DDS) and security considerations for DDS. It discusses the data-centric publish-subscribe model of DDS, how data is identified in the global data space, and approaches to software integration like point-to-point and broker-based that DDS improves upon. The document also touches on key aspects of the DDS security specification and next steps.
5. Data-‐Centric
Qos-‐Aware
Pub-‐Sub
Model
Persistence
Service
Recording
Service
Virtual,
decentralized
global
data
space
CRUD
opera:ons
Source
(Key)
Speed Power Phase
WPT1 37.4 122.0 -12.20
WPT2 10.7 74.0 -12.23
WPTN 50.2 150.07 -11.98
6. Data
Reader
“Alarm”
Domain
Par:cipant
Data
Writer
“Alarm”
Domain
Par:cipant
Data-‐Centric
Communica:ons
Model
• ParDcipants
scope
the
global
data
space
(domain)
• Topics
define
the
data-‐objects
(collec:ons
of
subjects)
• DataWriters
publish
data
on
Topics
• DataReaders
subscribe
to
data
on
Topics
• QoS
Policies
are
used
configure
the
system
• Listeners
are
used
to
no:fy
the
applica:on
of
events
Listener
Offered
QoS Listener
Got new
data
Requested
QoS
New
subscriber
!
example
7. Data-‐Object
Iden:ty
in
the
Global
Data
Space
• Domain:
world
you’re
talking
about
• Topic:
group
of
similar
objects
– Similar
structure
(“type”)
what
– Similar
way
they
change
when
over
:me
(“QoS”)
how
• Instance:
individual
object
– Like
the
“key”
fields
in
a
database
table
• DataWriter:
source
of
observa:ons
about
a
set
of
data-‐objects
(Topic)
• DataReader:
observer
of
a
set
of
data-‐objects
(Topic)
Domain
(e.g.
Yellowstone
Park)
Topic
(e.g.
bears
in
the
park)
Topic
Snow
Depth
Sensors
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
ID
GPS
value
Instance
(e.g.
Yogi
the
bear)
Instance
Object
Address
==
Object
Iden:ty
8. Sample
Iden:fica:on
need
• DataReaders
must
be
able
to
combine
the
samples
from
mul7ple
physical
data
sources
publishing
from
related
logical
data
source(s).
• Example:
MulD-‐Path
Delivery
• Example:
Cross-‐Topic
Ordering
8
DataReader
Durability
Service
DDS
Domain
“PosiDon”
DataReader
“PosiDon”
DataWriter
“Velocity”
DataWriter
DDS
Domain
“Velocity”
DataReader
Subscriber
Publisher
9. Global
Sample
Iden:fica:on
Each
sample
within
a
Domain
and
a
Topic
is
uniquely
iden:fied
by
a
virtual
iden:ty:
the
tuple
(Virtual
GUID,
Virtual
SequenceNumber)
– Virtual
GUID
(VGUID):
16-‐byte
iden:fier
iden:fying
the
data
source.
– Virtual
Sequence
Number
(VSN):
monotonically
increasing
64-‐bit
integer
that
iden:fies
the
sample
in
the
data
source.
DataWriter
DataWriter
DataWriter
DataBus
Domain
DataReader
(1,1)
(1,1)
(1,1)
(1,1)
(2,1)
(2,1)
(1,1)
(2,1)
A
DataReader
only
delivers
a
single
copy
of
a
sample
to
the
applica:on.
Duplicates
are
filtered
out.
(2,1)
Sample
with
VGUID
2
and
VSN1
10. Approaches
to
Sogware
Integra:on
App
App
App
App
App
App
Point-‐to-‐point
Not
maintainable:
-‐
Number
of
interfaces
grows
as
Modules^2
-‐
Add
hoc
integra:on
makes
reuse
difficult
-‐
Addi:on
of
new
modules
affects
exis:ng
ones
11. Approaches
to
Sogware
Integra:on
App
App
App
App
App
App
Point-‐to-‐point
App
App
App
App
App
App
Server/
Broker/
ESB
Inefficient,
not-‐robust,
and
expensive:
-‐
Centralized
server
becomes
boFleneck
-‐
Server
or
server-‐comm
failure
compromises
system
-‐
Server
is
hard
to
deploy,
power,
hide
12. Approaches
to
Sogware
Integra:on
DDS
Data-‐Centric
Bus
App
App
App
App
App
App
App
App
App
App
App
App
Point-‐to-‐point
App
App
App
App
App
App
Server/
Broker/
ESB
Superior
approach:
-‐
Number
of
interfaces
can
be
constant
or
linear
-‐
No
servers
=>
performance
&
availability
-‐
Lower
cost
in
hardware
&
soMware
maintenance
17. Security
Terms:
a
Safe-‐Deposit
Box
• Authen:ca:on:
The
bank
knows
who
you
are;
you
must
show
ID.
• Access
Control:
The
bank
only
lets
those
on
an
access
list
into
your
box.
• Confiden:ality:
You
are
alone
in
the
room
Nobody
can
see
the
contents
of
the
box.
• Integrity:
The
box
is
sealed.
If
anybody
touches
it
you
will
know.
• Non
repudia:on:
You
sign
when
you
come
in
and
out
so
you
can’t
claim
that
you
weren’t
there.
• Availability:
The
bank
is
always
open.
1717
29. 29
(D)TLS
Transport
for
DDS
• DTLS:
Datagram
version
of
the
TLS
protocol
• Like
TLS
provides:
AuthenDcaDon,
encrypDon,
integrity
• Requires:
– A
Cer:ficate
Authority
(CA)
– An
applica:on
must
be
configured
with
an
iden:fying
cer:ficate
assigned
by
the
CA
– An
applica:on
must
have
a
private
key
associated
with
the
public
key
in
the
cer:ficate
• Standard
protocol
(
with
open
source:
OpenSSL
)
– The
protocol
is
highly
scru:nized
– No
mulDcast
support
This
transport
is
available
in
Connext
DDS
4.5
and
5.0
32. 1.
Secure
Channel
between
Systems
3/17/14
32
System
1
Rou:ng
Service
Gateway
acts
as
security
point
System
2
Rou:ng
Service
TLS
This
solu7on
is
available
in
Connext
DDS
4.5
and
5.0
33. Secure
Channel
with
Firewall
3/17/14
33
System
1
Rou:ng
Service
System
2
Rou:ng
Service
TLS
Can
use
firewall
as
added
protec:on
This
solu7on
is
available
in
Connext
DDS
4.5
and
5.0
34. DDS
Rou:ng
Service
with
Secure
Asymmetric
TCP
• WAN
clients
access
DDS
data
within
LAN
– Clients
communicate
with
par:cipants
in
LAN
not
between
each
other
– Clients
behind
fire-‐walls
– Only
one
public
address
required.
Only
one
firewall
configured
• Example:
Exposing
a
service
to
end-‐user
clients
Remote
App
System
1
Rou:ng
Service
Remote
App
Remote
App
This
solu7on
is
available
in
Connext
DDS
4.5
and
5.0
Assymetric
TLS