1. US Army Tactical C2 Interoperability Services: Publish and Subscribe Server (PASS) and Data Dissemination Service (DDS)
Sam Easterling
Army PM Battle Command
2 DEC 09

2. Outline What are PASS/DDS in a nutshell? Operational Context
Technical Detail
Summary

3. Army Battle Command Systems
TBC
(CPOF, MCS)
GCCS-A/NECC
EAC C2
Shared SA
Net-Ready
Interoperability
Automatic Database Replication
Maneuver
Display and disseminate COP
Disseminate Orders
Tactical Collaboration
Interoperability between
Tactical and Theater levels
Chem-Bio Rad-Nuc (CBRN)
FBCB2/ JBC-P
Functional Capabilities
Battle Command Common Services
Blue Force/SA
MANUEVER
PLI/SA
MEDEVAC
Orders
NBC
ENGINEER
AFATDS
FIRE SUPPORT
AMDWS
Fire Support
AIR DEFENSE
Synchronized Fires, Effects,
& Maneuver
Execute Responsive Fires
JADOCSHand helds
Target Locations
Radar/Observer Locations
ENEMY
Air Defense
AIR PICTURE
Air Defense to Maneuver Units
Positive Aircraft ID
Weapon Coverage
LOGISTICS
TAIS
WEATHER
BCS3
Logistics
Airspace
Combat Power
In-transit Visibility
Joint Automated Air Space
Control with the JFACC
Air Support Request
DCGS-A
Maps
Weather
DTSS
IMETS
Intelligence
ASAS
Local Terrain
“Go/No-Go” Areas
Weather Effects Matrix
Battle Scale Forecast Model
Secondary Imagery
Intelligence Summary
Enemy Locations
Enemy Geometries 3

4. PASS/DDS (in a nutshell)
Built to support many-to-many data exchange requirements emerging from stovepiped architectures
Publication/ Subscription mechanism
Does not impose a model on the way the application conducts the Business of War.
Not a database, but published data is stored for future subscriptions with a time-to-live
Flexible methodology allowing for insertion of new schemas and message exchange
Web Services/SOAP and XML
Runs over HTTP(s).
Internet protocol
Protocol knows how to deal with latent and ‘dirty’ networks
Data agnostic
But…. ABCS message exchange is based on PASS schemas

5. Data that Battle Command Exchanges via PASS / DDS
Friendly Position Reports (ground and air)
Enemy Situation Reports
Sensor tracks
Military C2 Graphics / Battlespace Geometries
Significant Activities (SIGACTS)
Targets
Airspace Control Orders (ACO)
Weather
Task Organization Information
Addressbook Change Notification
Indicators and Warnings

6. Each US Army unit in OEF has a PASS node at CJTF, BCT, BN HQ
Also in 57th SIG, MEB-A
Co-located with every CPOF Master Repository to enable exchange
Also planned installation in IJC HQ to enable interoperability services with NATO apps

7. UK/US Information Exchanges
TRACKS
TRACKS
GCCS-J
GCCS-A
ICS
WISEWeb -> Sharepoint
Document/File Exchange and Collaboration
(Read, download, post, contribute)
SharePoint
Jchat
VoIP Phone
MEDEVAC/CASEVAC, Personnel Recovery,
FMV coordination, CAS coordination, TIC
Transverse, Jchat, mIRC
VoIP Phone
SIGACTS
CIDNE
CIDNE
PASS
PASS / DDS
US BC Systems CPOF
TAIS
GCCS-A
AFATDS
FBCB2
BCS3
DCGS-A
JADOCS
AMDWS
CIDNE
JOCWATCH
SIGACTS
PASS
PASS / DDS
JADOCS
- SIGACTS
- BATTLESPACE GEOMETRIES
- TARGETS
- POSITION REPORTS
-INDICATORS/ WARNINGS
AIR TRACKS
ENEMY SITUATION
ACO
Fire Support Coordination Measures
Coalition Fires / Effects
JADOCS
JADOCS
TIGR
TIGR
Patrol Reporting
MIP
Other Coalition Forces

8. IJC COP Flow (as of 15 Nov) GCCS-J RM GCCS-J CPOF MR/DB PASS GCCS-A
SA Tracks only
GCCS-J
NIRIS
iGeoSit Viewer
SA Tracks only
In theatre Link-16
feed
SA Tracks only ?
CPOF Client
SA Tracks only
Full COP (CST)
GCCS-A
CPOF MR/DB
JADOCS
GEO, Full COP
iGeoSIT
Server
Full COP
Full COP
SIGACTS (+)
Full COP
CIDNE
SIGACTS (-)
Graphics, non-track POS-RPT
SIGACTS (+)
SIGACTS (+)
PASS
COP LM (formerly BOM)
SIGACTS (+)
JOCWATCH
Graphics, non-track POS-RPT
Graphics, non-track POS-RPT
MIP GW
MIP GW

9. Proposed CXI Architecture with C2 Interoperability Bus
CIDNE
JADOCS
ISRIS
Intel FS
JOCWatchB
NIRIS
C2PC
CPOF
FBCB2
GCCS
BOM
JOIIS
COP
ICC
US Integration Solutions
Based on PASS / DDS Server
C2 Interoperability Bus (CUR 355)
JC3IEDM / NIIA Canonical Form
By installing an ISAF interoperability bus on the ISAF Secret network, we can significantly simplify our connection to the US systems. This will enable us to significantly reduce the scope of work required of the CENTRIXS ISAF Phase II project and will result in a solution that is both more flexible and is also easier to maintain.
The ISAF interoperability bus will be based on existing NATO standards, including the JC3IEDM standard that has arisen from the MIP community, and also the NIIA standards for ISR interoperability that have been developed by the MAJIIC community.
EVE
CIED
IFTS
JISR 1
Others
CORSOM
GEO ü
JADOCS
NATO UNCLASSIFIED Releasable to ISAF 9

10. IJC MIP Architecture ISAF Secret CENTRIX ISAF Router
PASS / DDS
MIP
COP LM
IGEOSIT
Battle field Geometry
NATO and ANA Boundaries
FOBS
COPS
UNITS (not tracks)
NGO/IO Locations
Road (Planned, under construction and completed)
CPOF

11. DDS Uses a Pub-Sub Approach
1. Providers Advertise
(the data they will publish)
2. Consumers Subscribe
(to their server for data)
4. Servers match advertisement, subscription and publish metadata
3. Providers Publish
(push data to their server)
There are multiple collaborating servers within the DDS network
5. Servers Publish
(push data to consumers)
Clients only communicate with a single server

12. DDS and advertisements
DDS uses advertisements to “tell everyone on the network” that data exists at a certain node
DoD Discover Metadata Specification (DDMS) version 1.3 is the standard for the advertisement
What type of data
Data description
Who has access to the data
Clients subscribe to advertisements
Clients provide the “call back protocol” method to deliver data
HTPP(s), UDP(s) (DDS version 2.0)
Publishers, publish data for an advertisement
Once a publisher, injects data, and a match occurs against the subscription, data is delivered to the client

13. DDS versus PASS Data is global PASS compatibility
Unlike PASS which was a application for data dissemination within the TOC, DDS was developed with global data as the main paradigm.
PASS compatibility
Will keep compatibility with current PASS
Usage of a PASS/DDS bridge to mach advertisement to topic
Not tied to any software baseline because of backward compatibility
Better security model than PASS
Complies with NCES security policies
Meets DOD guidelines for security.

14. PASS to DDS Evolution DDS – Federated Service PASS – Local Service
SOA / SOAP Interface
Payload independent
Data Caching
Publish and Subscribe
Advertise, Publish & Subscribe, Query
Limited Metadata filtering
(Topic, AOI, Time)
Enhanced metadata and Content filtering
(Keywords, Content, AOI, Time)
Local interchange
Net-Centric Interchanges
Hand-Jammed static PASS forwarding relationships
Dynamic Peer node Discovery

15. Sample metadata
<advertise commandDateTime=" T11:04: :00" userID="mcsuser" xmlns="
- <metadata>
  <ns1:title ns2:classification="U" ns2:ownerProducer="USA" xmlns:ns1="
xmlns:ns2="urn:us:gov:ic:ism:v2">MCS_DEMO</ns1:title>
  <ns3:description ns4:classification="U" ns4:ownerProducer="USA" xmlns:ns4="urn:us:gov:ic:ism:v2"
xmlns:ns3="
<ns5:creator ns6:classification="U" ns6:ownerProducer="USA" xmlns:ns5="
xmlns:ns6="urn:us:gov:ic:ism:v2">
- <ns5:Organization>  <ns5:name>MCS</ns5:name>   </ns5:Organization>
  </ns5:creator>
- <ns7:subjectCoverage xmlns:ns7="
- <ns7:Subject>
  <ns7:category ns7:label="Ground" />
  <ns7:keyword ns7:value=“FBCB2" />
  </ns7:Subject>
  </ns7:subjectCoverage>
- <ns8:temporalCoverage xmlns:ns8="
  <ns8:start> T11:03:55-05:00</ns8:start>
  <ns8:end> T16:03:55-05:00</ns8:end>
  </ns8:temporalCoverage>
- <ns9:geospatialCoverage xmlns:ns9="
  <ns9:lowerCorner> </ns9:lowerCorner>
  <ns9:upperCorner> </ns9:upperCorner>
  </ns9:geospatialCoverage>
  <ns10:security ns11:classification="U" ns11:ownerProducer="USA"
ns11:releasableTo=“MCSGroup FBCB2Group"
xmlns:ns11="urn:us:gov:ic:ism:v2" xmlns:ns10=" />
  </metadata>
  </advertise>

16. How DDS Works
DDS client, discovers DDS node location through the use of discovery services
Publisher
Advertise their data, DDS server to server protocol propagates advertisements to other nodes
Publish data to local DDS node. DDS node merges subscribers of published data from save DDS node and send data to node then DDS nodes stores based on TTL
Subscribers
Subscriber, specify advertisement and data filters
DDS node will match subscriptions to advertisements and forward subscription to owning DDS nodes
When DDS node receives published data, it sends to subscribers
NCES Security
Authenticates and authorizes DDS nodes, publishers & subscribers
NCES Services
Security
Discovery
Sub 1
DDS Nodes
Sub 2
DDS
Subscribe
Advertise
Key
Advertisements
Subscriptions
Published data
DDS
Advertise
Publish
Publisher
Sub 1
Overlap in subscriptions from same DDS node are only sent once
Sub 2

17. ABCS Data Dissemination Service (DDS) Security Model Tactical Services Security System (TS3)
Cert
Validation
Service
User
Auth.
Service
Principal
Attribute
Service
Policy
Decision
Service
User Directory
(AD / LDAP / etc.)
(roles, clearances,
citizenship)
(2) Client App Digital Sig.
(7) User Attributes (e.g. Role/Groups) returned
(8) Present User Role
(9) User is authorized
(4) Present UN/PW
(5) User DN received
(6) Present User DN
(3) Cert validated
(0) User provides credentials (Username/PW)
(1) Digitally Signed SOAP Request with SAML Assertion
DDS
Client
Security
Header
Handler
Signature
Handler
Cert
Validation
Handler
User
Authentication
Handler
Principal
Attribute
Handler
Policy
Decision
Handler
SAML
Cert
Validation
Handler
Signature
Handler
Security
Header
Handler
Certification Validation Service (CVS) which serves as a domain’s trust anchor for establishing the authenticity and validity of certificates. (authenticating the request)
Policy Decision Service (PDS) - authorize the request. PDS makes a decision (permit / deny / indeterminate) based on the evidence and the access control policies of this trust domain.
(10) Digitally Signed SOAP Response with filtered data
DDS Web Service
NOTES:
All connections are SSL using HTTPS
All transactions are digitally signed and validated
Client Cert Validation Handler connects to the Cert Validation Service (not shown)
NCES Component
SEC Developed Component

18. Summary
PASS / DDS are used by US Army Battle Command systems to share ‘common operational picture’ data at tactical echelons
XML payloads with metadata to enable appropriate AOI/temporal queries and identify releasability
HTTPS-based with soft certificate-based security model
Supporting initial coalition interoperability with UK (JADOCS) and ISAF (CPOF, JOCWATCH, COP LM)

19. Backup

20. Security policy DDS has a comprehensive security model
Functional Validation
Users have privileges to functionality based on their group membership
Clearance Classification
Users have privileges to publish or subscribe based on their security classification and releasibility for data.
Users have privileges to publish or subscribe based on the rights associated with the advertisements.
Advertisements carry security classification
Need to know
All functionality for access is based on users being members of groups
Advertisements carry need to know
Advertisement is only available to subscribers who are in the groups which are specified in ‘Releasable To’ field of the Advertisement
Single Sign On under Windows (clients)

21. MIP Deployment Summary
MIP Ver 09_4_4_22 is installed on the BCS server at IJC HQ. MIP is receiving data from CPO LM (formally BOM) and publishing it to PASS. We have tested it with CPOF and CPOF is subscribing to PASS and displaying the data. There is one issue with Road graphics they are a point to point line, but they are displaying as an icon. Joel Varanda is sending Venis the unclass PDU for the road.
COPLM is sending the following data through MIP:
Battle field Geometry
NATO and ANA Boundaries
FOBS
COPS
UNITS (not tracks)
NGO/IO Locations
Road (Planned, under construction and completed)
COP LM is not sending the following data
SIGACTS (JOC Watch)
Ground Tracks (GCCS-J)
Air Tracks (TBMCS)
Fires (JADOCS)
LOG (NIRIS)