Instant Messaging is becoming an increasingly important communication option for the modern warfighter, particularly for sharing communication with a large number of users with Multi-User Chat capabilities. Voice and video communications are often impractical due to networking constraints and/or operational characteristics. Email or formal messaging are often too slow and cumbersome where information sharing and associated decision making need to happen very quickly.
XMPP is the Internet Standard for Instant Messaging, Real Time Messaging, and Multi-User Chat. It provides high functionality and good security capabilities. XMPP is being increasingly adopted by NATO and National organizations, as the technology of choice for Instant Messaging.
Two sample scenarios are considered that show ways in which XMPP can be used, and requirements that need to be considered given the mix of communication methods likely to be available during a deployment.
Consider an aircraft on a surveillance mission. Key communication factors:
- Communication links with the aircraft are variable and may be very poor, This may include:
- UHF Radio, providing a fast link when there is line of sight communication.
- HF Radio, providing a slow link without requirement for line of sight.
- Slow SATCOM, which gives an alternative to HF.
- There are several staff on the aircraft involved with surveillance, each with their own terminal and role.
- Multiple ground staff are involved in a mission, some with active and some with observer roles.
Video communication is in general impractical, and use of voice communication is necessarily constrained.
Use of a small number of MUC rooms provides an ideal approach for sharing information. Using multiple rooms allows an effective partition of information. MUC allows many people to see information being shared in real time, while making efficient use of poor communication links.
The second scenario has several ships in a task group, communicating with each other and with staff on shore. Key factors:
- A number of different communication links may be used. The choice will depend on availability and threat conditions that may constrain choice.
- Links may not always be available, and this should not constrain communication. If there are no operational links to shore, communication within the task group should not be impacted.
- Multiple staff on each ship and on shore need to be involved in communications.
- Communication may need to be fast, for example handling to Time Sensitive Targeting to coordinate activity between the ships.
MUC rooms are ideal to support this communication. They allow participation of multiple active users and observers with near real-time communication making efficient use of communication links.
M-Link and M-Link Edge Capabilities
Constrained Network Support
Many military deployments will use network links with poor and variable quality. High latency is a particular problem for XMPP deployment, because of the requirement to avoid handshaking. M-Link Capabilities for constrained networks are described in the M-Link product page and in the whitepaper [M-Link Support for XMPP over Constrained Networks]. They include:
- Stream Compression.
- Roster Versioning.
- Presence Stripping.
- Optimized Server-to-Server Protocol.
Federated Multi-User Chat
In normal operation a multi-user chat (MUC) room is associated with a single XMPP server and can be joined by clients on local or remote servers. This architecture leads to a number of problems in constrained network situations, including users on servers other than the one hosting the MUC room being disconnected from the MUC in the event of a link failure.
Isode's solution to the problems of standardized MUC is to federate the provision of this service, just as the distribution of XMPP servers federates the provision of 1:1 chat and presence.
A Federated MUC (FMUC) room can comprises two or more MUC rooms on seperate servers, as shown below. Participants in each local MUC Room will have the effect of participating in the single Federated Room. For more information, see the Isode whitepaper [Federated Multi-User Chat: Efficient and Resilient Operation over Slow and Unreliable Networks].
IRC (Internet Relay Chat) Gateway
M-Link can be configured to act as a gateway between XMPP Multi-user chat rooms and IRC channels. The M-Link server uses the IRC client to server protocol to connect to IRC, in order to maximise interoperability with different IRC servers. Connections to IRC channels are totally transparent to XMPP MUC users with no downgrade of security for XMPP users. Security label support is retained with translation to IRC users as FLOT (First Line of Text) labels in IRC messages.
For more information, see the Isode whitepaper [Interconnecting XMPP and IRC].
Server and Network Resilience
Resilience is crucial for military deployments. M-Link provides server clustering to provide resilience in the event of server failure and XEP-0198 support to ensure no message loss in the event of network failure. For more information see the M-Link Clustering & Reliability product page and the whitepaper [Reliable XMPP].
Boundary Guard support
Standard XMPP deployment assumes Internet-like direct connectivity with all servers. Military deployments typically need boundary and cross domain protection to work with partners. Isode's M-Link Edge product provides this capability for XMPP either operating on its own or in conjunction with a High Assurance Guard.
Use of PKI and digital signatures is essential for military XMPP deployments. M-Link supports these capabilities. An overview of these and other security capabilities is given in the M-Link Security product page.
Security Labels are used in many military deployments to provide mandatory access control. M-Link provides flexible security label support, as described on the M-Link Security product page and in the whitepaper [Using Security Labels to Control Message Flow in XMPP Services].