230 likes | 686 Views
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 samuel.easterling@us.army.mil. Outline. What are PASS/DDS in a nutshell? Operational Context Technical Detail Summary.
E N D
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 samuel.easterling@us.army.mil
Outline • What are PASS/DDS in a nutshell? • Operational Context • Technical Detail • Summary
Army Battle Command Systems TBC (CPOF, MCS) GCCS-A/NECC Maneuver • Shared SA • Net-Ready • Interoperability • Automatic Database Replication EAC C2 • 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 MANUEVER Blue Force/SA NBC • PLI/SA • MEDEVAC • Orders 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 Intelligence ASAS IMETS • Secondary Imagery • Intelligence Summary • Enemy Locations • Enemy Geometries • Local Terrain • “Go/No-Go” Areas • Weather Effects Matrix • Battle Scale Forecast Model
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
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
Each US Army unit in OEF has a PASS node at CJTF, BCT, BN HQ • Also in RC(S) @ 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
UK/US Information Exchanges UK US TRACKS TRACKS GCCS-J GCCS-A ICS Document/File Exchange and Collaboration (Read, download, post, contribute) WISEWeb -> Sharepoint SharePoint MEDEVAC/CASEVAC, Personnel Recovery, FMV coordination, CAS coordination, TIC Jchat VoIP Phone Transverse, Jchat, mIRC VoIP Phone SIGACTS CIDNE CIDNE US BC Systems CPOF TAIS GCCS-A AFATDS FBCB2 PASS PASS / DDS BCS3 DCGS-A JADOCS AMDWS CIDNE - SIGACTS - BATTLESPACE GEOMETRIES - TARGETS - POSITION REPORTS • -INDICATORS/ WARNINGS • AIR TRACKS • ENEMY SITUATION • ACO JOCWATCH SIGACTS PASS PASS / DDS JADOCS Fire Support Coordination Measures Coalition Fires / Effects JADOCS JADOCS TIGR TIGR Patrol Reporting MIP Other Coalition Forces
IJC COP Flow (as of 15 Nov) GCCS-J RM 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
Proposed CXI Architecturewith 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 EVE CIED IFTS JISR 1 Others CORSOM GEO ü JADOCS 9 NATO UNCLASSIFIED Releasable to ISAF
IJC MIP Architecture ISAF Secret CENTRIX ISAF Router MIP PASS / DDS IGEOSIT COP LM • Battle field Geometry • NATO and ANA Boundaries • FOBS • COPS • UNITS (not tracks) • NGO/IO Locations • Road (Planned, under construction and completed) CPOF
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
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
DDS versus PASS • Data is global • 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.
Sample metadata • <advertise commandDateTime="2006-02-15T11:04:16.765-05:00" userID="mcsuser" xmlns="http://mitre.org/DDS"> • - <metadata> • <ns1:title ns2:classification="U" ns2:ownerProducer="USA" xmlns:ns1="http://metadata.dod.mil/mdr/ns/DDMS/1.3/" • 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="http://metadata.dod.mil/mdr/ns/DDMS/1.2/">MCS_Desc</ns3:description> • <ns5:creator ns6:classification="U" ns6:ownerProducer="USA" xmlns:ns5="http://metadata.dod.mil/mdr/ns/DDMS/1.3/" • xmlns:ns6="urn:us:gov:ic:ism:v2"> • -<ns5:Organization> <ns5:name>MCS</ns5:name> </ns5:Organization> • </ns5:creator> • - <ns7:subjectCoverage xmlns:ns7="http://metadata.dod.mil/mdr/ns/DDMS/1.3/"> • - <ns7:Subject> • <ns7:category ns7:label="Ground" /> • <ns7:keyword ns7:value=“FBCB2" /> • </ns7:Subject> • </ns7:subjectCoverage> • - <ns8:temporalCoverage xmlns:ns8="http://mitre.org/DDS/metadata"> • <ns8:start>2006-02-15T11:03:55-05:00</ns8:start> • <ns8:end>2006-02-15T16:03:55-05:00</ns8:end> • </ns8:temporalCoverage> • - <ns9:geospatialCoverage xmlns:ns9="http://mitre.org/DDS/metadata"> • <ns9:lowerCorner>-170.0 16.0</ns9:lowerCorner> • <ns9:upperCorner>-169.0 17.0</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="http://metadata.dod.mil/mdr/ns/DDMS/1.3/" /> • </metadata> • </advertise>
Key Advertisements Subscriptions Published data 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 Sub 1 Discovery • DDS Nodes Sub 2 DDS Subscribe Advertise DDS Advertise Publish Publisher Sub 1 Overlap in subscriptions from same DDS node are only sent once Sub 2
ABCS Data Dissemination Service (DDS) Security ModelTactical Services Security System(TS3) Cert Validation Service User Auth. Service Principal Attribute Service Policy Decision Service User Directory (AD / LDAP / etc.) (roles, clearances, citizenship) (7) User Attributes (e.g. Role/Groups) returned (8) Present User Role (2) Client App Digital Sig. (9) User is authorized (6) Present User DN (5) User DN received (4) Present UN/PW (3) Cert validated (0) User provides credentials (Username/PW) (1) Digitally Signed SOAP Request with SAML Assertion User Authentication Handler Principal Attribute Handler Cert Validation Handler Policy Decision Handler Security Header Handler Signature Handler DDS Client SAML Signature Handler Security Header Handler Cert Validation Handler (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
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)
Security policyDDS 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)
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)