CHAT RFI - Q-A RESPONSES PM MC-final.pdf

INDUSTRY QUESTION GOVNT RESPONSE

I’m reaching out to gain a clearer understanding of the Army’s Command and Control (C2) systems—specifically TAK (Tactical Assault Kit) and CPCE (Command Post Computing Environment). Could you kindly provide some insight into the operating systems these platforms run on, as well as any environment-specific considerations relevant to integration or interoperability?

The current systems utilize the following:

Operating systems:

-Android 5.0 (API 21) or later -Windows (any) -Windows 10 – one system requires this -Ubuntu Linux 20.04 LTS – one system requires this -Linux Networks (IPv4 based network enabled by VPN):

-Terrestrial Radio such as TSM or HNR – throughput limited mesh network -Commercial such as 5G -Sat Comm Tactical Networks such as BFT2 or NCW Domains:

-Multiple security enclaves such as NIPR and SIPR Server Deployment:

-Virtual machine is an option. A container application image is preferred.

Client Deployment:

-Binary executable that is native to the operating system

Identity Federation/Provisioning: Regarding "common identities across platforms" and "mission specific role identities," does PM Mission Command envision the chat solution integrating with an existing Army enterprise identity provider (IdP) or Public Key Infrastructure (PKI), or should the solution incorporate its own identity management capabilities?

The solution can incorporate its own identity management, and integration with Microsoft’s Active Directory Federation Services (ADFS) is a plus.

Authentication Mechanisms: Are there preferences for user authentication methods (e.g., passwordless, multi-factor authentication, biometrics, integration with existing credentials like CAC/PIV for command post environments, or other methods suitable for tactical/dismounted users)?

Current authentication uses usernames and passwords, with a planned migration to PKI.

Beyond this, no additional authentication methods are currently planned.

Peer Resilience Scope: Concerning "peer-to-peer communication to maintain messaging functionality in the absence of backend server connectivity" (below):

○ What is the envisioned scale (e.g., number of users, geographic dispersion) for these P2P chat operations?

○ Are there specific performance expectations (e.g., message delivery success rates, latency) for P2P mode under varying DDIL conditions?

○ What are the expectations for authentication, key management, and session continuity when operating in a fully server-disconnected P2P mode?

What is the envisioned scale (e.g., number of users, geographic dispersion) for these P2P chat operations?

-The system should support a minimum of 16, with a maximum of 30 users, within a single chat group. Users are expected to be at command posts that may not be co-located but still connected via network links spanning tens of miles.

Are there specific performance expectations (e.g., message delivery success rates, latency) for P2P mode under varying DDIL conditions?

-A minimum completion rate of 90%, with a maximum latency of 5 minutes on tactical networks, is expected.

What are the expectations for authentication, key management, and session continuity when operating in a fully server-disconnected P2P mode?

-Once server connection re-established session data should sync back to server.

Presence in DDIL: Could you provide further details on the acceptable latency for presence status updates in DDIL environments and any specific types of "available network information" that should be utilized for determining user status?

No specific recommendation exists. Reference industry best practices.

DDIL Fallback Mechanisms: For fallback mechanisms like "store-and-forward," what are the expectations concerning data synchronization strategies, conflict resolution (if any), and message prioritization once connectivity is restored?

Data synchronization strategies – Messages get restored in chronological order, if message is editable, the latest revision of the message is what gets forwarded.

Conflict resolution (if any) – Users should not be able to create the same chat group names or have the same username.

Message prioritization – All Chat messages are generally considered routine traffic -- no prioritization (unless a capability is provided to mark traffic individually as important).

Policy-Based Data Exchange: The RFI mentions leveraging "available network health/availability data to make policy-based decisions (PACE/precedence) on data exchange." Could PM Mission Command provide further insight into the anticipated sources of network health data and the desired level of sophistication or types of policies for managing data exchange under these conditions?

The implementation is at the discretion of the vendor. Possible implementation suggestions:

-Manual Bandwidth setting on devices.

-If Chat Solution leverages a Server /Client architecture, status of Server-to-Server connections, and status of Client to Server Connection (do not leverage ping as a mechanism to validate connectivity).

-Ability to Support QOS markings through at least port filtering.

PEO_C3T_MC_SCIENCE_PLATFORM_20230707 - RFI - INDUSTRY QUESTIONS - GOVERNMENT RESPONSE

Q-Q-final