Naval XMPP Road Map

Naval Communication Requirements

Naval XMPP requirements are driven by underlying communications capabilities, illustrated in the diagram that follows.

Characteristics include:

• Satcom is the primary link between shore and ships. This will be varying speed (dependent on the bearer) and high latency.
• HF may be used ship/shore, in Satcom Denied environments or when operational requirements lead to HF preference.
• Ships in a task group sailing close together (35 miles or less) will use UHF links.
• Ships sailing within a few hundred miles will use HF Surface Wave communication. These links are particularly suitable for WBHF (Wideband HF) communication.
• Links will not always be available, so it is important that local communications on a ship are not dependent on any external communications links.

This is a demanding environment for any application.

Current Isode Naval XMPP Capabilities

This section looks at capabilities in Isode’s M-Link products to support Naval deployments, including general military capabilities.
XMPP was primarily designed to operate in modern high speed Internet environments. Basic open source implementations of XMPP do not address the requirements of Naval XMPP. Isode has provided the following capabilities (these are summarized, with references to detailed descriptions):

1. Low Latency Support. General XMPP operation is asynchronous and works well over high latency networks. However, connection initiation is synchronous with many handshakes that lead to long startup delays. M-Link Constrained Network products address this using “XEP-0361: Zero Handshake Server to Server Protocol”. This is described in detail in the white paper [Operating XMPP over HF Radio and Constrained Networks].
2. XMPP Trunking. Standard XMPP assumes that each XMPP server can talk directly to any other XMPP server. Sensible use of Naval communications requires indirect communication, which is supported by all of Isode’s M-Link products. Further information is given in the Isode white paper [Providing XMPP Trunking with M-Link Peer Controls].
3. HF Radio support. To provide efficient operation over HF Radio, M-Link Constrained Network products implement  “XEP-0365: Server to Server communication over STANAG 5066 ARQ”. This enables efficient operation over HF down to 75bps. This is also described in detail in the white paper [Operating XMPP over HF Radio and Constrained Networks].
4. Task Group HF Channel Sharing. When HF Radio is used, it is impractical (particularly for smaller ships) to use more than one frequency. So it is often desirable to share a single frequency (HF Channel) between multiple ships. This can be achieved with Isode’s Icon-5066 product using STANAG 5066 Annex K.
5. Federated MUC (FMUC). While XMPP basic service is fully federated, the MUC (Multi User Chat) service, which is key for Naval group communication, is centralized. This leads to inefficient link utilization, and communication cannot work when a link is down. Isode XMPP server products use “XEP-0289: Federated MUC for Constrained Environments” (FMUC) to address this. Detailed information is provided in Isode white paper [Federated Multi-User Chat: Efficient and Resilient Operation over Slow and Unreliable Networks].
6. Clustering. In a mission critical environment, it is important that XMPP servers are protected from node failure. All M-Link products provide a clustering capability, to enable a single service to be operated on multiple nodes. This is particularly important for a shore site, which should ideally be deployed at multiple location.
7. Security Labels. M-Link products support security labels following “XEP-0258: Security Labels in XMPP”, which enables security labels in clients that support XEP-0258, such as Isode’s Swift client or NATO JChat. Further information is given in the Isode white paper [Using Security Labels to Control Message Flow in XMPP Services].
8. Archiving.  M-Link products provide short term archiving using “XEP-0313: Message Archive Management” and long term archiving using PDF/A. This is key for military operation. Further information is provided in the M-Link Archive and Search product page.
9. Forms.  Support is provided for (military) forms using “XEP-0346: Form Discovery and Publishing”. There is client support in NATO JCHAT client and Isode Web client.  Further information is provided in the Isode white paper [Military Forms using XMPP].
10. IRC Gateway. IRC (Internet Relay Chat) is widely used in Naval deployments. The M-Link IRC Gateway provides a MUC-oriented gateway which provides flexible functionality and enable migration from IRC to XMPP.

This unique combination of capabilities makes M-Link products the ideal choice for Naval XMPP deployments. The rest of this white paper looks at capabilities planned for M-Link products that will improve use for Naval deployments.

New HF Capabilities

Currently, XEP-0365 is used to communicate efficiently over HF Radio using STANAG 5066. XEP-0365 maps each XMPP stanza onto a single STANAG 5066 RCOP (Reliable Communication Oriented Protocol) datagram. This approach works reasonably well.

XMPP server to server communication is defined using a stream, with messages transmitted in order. The RCOP approach can cause problems in some advanced XMPP scenarios, as order is not always preserved. It also means that compression cannot be used.

Isode has published SIS Layer Extension Protocol (SLEP) (S5066-APP3) which defines a stream layer over STANAG 5066, including a mapping for XMPP with XEP-0361. This approach will give improved XMPP function over STANAG 5066, and will enable use of compression which is highly desirable.

Isode’s current Icon-5066 option for Task Group HF Channel sharing is STANAG 5066 Annex K which uses a CSMA (Channel Sense Multiple Access) approach. This is extended by use of Slotted Option for STANAG 5066 Annex K (S5066-EP6) which improves performance and resilience for networks with a small number of nodes.

For networks (Task Groups) with high traffic load, STANAG 5066 Annex L, which uses a Token Ring approach is expected to give better performance. Further information is given in [Isode Strategy for HF, STANAG 5066 and Applications over HF].

Links with Multiple Communication Options

M-Link products currently allow static configuration of links between peer XMPP servers, that can use different protocols or communication routes. This enables switching protocol used to communicate between a pair of XMPP servers (e.g., between XEP-0361 over Satcom, or XEP-0361 over UHF link, or XEP-0365 over HF Radio). However, this switching has to be done manually as a configuration change on each server. This manual approach can work for simple deployments but is not manageable on a large scale.

The planned approach is to allow configuration of all link options. The server will then continuously check each link, to determine which links are working and quality of link. The operator will be disable any links that are not appropriate for the current operational requirements.

The server will then choose to route traffic over the best working link between a pair of servers. This will enable links to automatically adapt and failover between alternate options.

Link Topology Change

Messages can be routed through another server to transfer messages indirectly. This is a key XMPP Trunking capability. Consider three ships in a straight line, each 400 miles apart. This is too far for UHF, but the middle ship can communicate over HF to both of the other ships. However, the two end ships cannot communicate directly, as they are too far apart. XMPP messages need to be routed through the middle ship. Currently, this XMPP Trunking configuration needs to be manually configured and updated by an operator.

Changes are planned to make topology change dynamic. Links between servers will have an associated “link quality”. This may change, as two servers may be linked by different protocols (e.g., UHF or HF) which have different configured quality. The current link quality will depend on which link is working. The link quality will be represented by the quality of the best working link option.

M-Link servers will share with peer servers information on connectivity. This is an XMPP level application routing protocol. An M-Link server will use this information to route messages using the lowest cost route to the target server. This routing will adapt to link failures and changing link quality.

FMUC Graph Dynamic Adaption

Federated MUC operates by having servers connected in an acyclic graph. This enables efficient data synchronization between servers. This approach will generally not utilize all configured links. A protocol which allowed fuller connectivity is possible, but it would necessarily be less efficient. At the system level, acyclic graph gives the best performance. Currently, an FMUC deployment will statically configure the acyclic graph.

Link topology changes can cause the current acyclic graph to break or to be sub-optimal. FMUC will be enhanced so that the graph will adapt to topology changes. Graph changes will be applied conservatively (slowly) as graph topology change will lead to synchronization traffic. This will also allow for the acyclic graph to fragment into multiple graphs, which will join later when the topology allows.

Large Federation FMUC Management

The current FMUC implementation in M-Link products works by configuration of each participating MUC room as part of an acyclic graph. This works well for a small number of nodes and a small number of (F)MUC rooms. However, it does not scale well to a large number of nodes (ships) and MUC rooms.

The planned approach is to configure FMUC domains. Each FMUC domain will apply to a set of nodes. For each node, the set of available FMUC rooms will be the same and the FMUC room names will be the same for each node. Where different coverage is needed, multiple FMUC domains can be configured. Nodes (ships) can be added to an FMUC domain and all of the FMUC rooms will be immediately available. If an FMUC room is created on one node, it will be propagated to all ships. A special procedure will be available to delete FMUC rooms. Where there are no local active FMUC room users on a node (ship) there will not be any synchronization traffic to that node.

This approach will make it straightforward to manage FMUC rooms with large numbers of nodes and will make it easy to add new FMUC rooms.

Hats and User Status

In XMPP, users have presence information defined by the user. This information is available 1:1 in user rosters and as participant information in MUC rooms. There are situations where it is desirable for servers to add additional per-user information. This has been discussed in the XMPP community for a number of years and the generic approach is referred to as “Hats”, reflecting the idea that the server provides additional information that can be displayed. Isode plans to add three uses of Hats to M-Link products which will benefit Naval users:

1. Where a user accesses an XMPP service via the M-Link IRC Gateway, a special Hat will be assigned that identifies the IRC gateway. This is important, as IRC users are generally not authenticated and so level of trust is lower.
2. FMUC users will be assigned a Hat that identifies their node (ship). This will make it straightforward for users to see which node each user is on.
3. The local FMUC node for a connected user will maintain routing information for other nodes and know which nodes are available. This information will be presented to local users as additional hats for remote users. This will enable users in FMUC rooms to see when recipients cannot be reached and how long they have been unreachable for.

Other FMUC Improvements

Four additional improvements are planned.

1. IRC with FMUC. Currently FMUC cannot be used with IRC. This restriction will be lifted.
2. Submission Timestamps. Standard XMPP works primarily on message arrival time. For FMUC, a timestamp will always be added when a message is submitted. This will enable a recipient to see clearly when a message has been delayed. It will also enable presentation of messages in “global order” (based on submission time stamp) as an alternative to delivery order. This “global order” will be the same for all FMUC users.
3. Long outages. When there is a long link outage (e.g., a day) there may be a large number of messages to synchronize, which will take some time. Currently messages are synchronized in chronological order. It is planned to synchronize recent messages first, as these may be of immediate operational importance and subsequently to synchronize the historical backlog.
4. MIX. Isode is actively working on the XEP-0369: Mediated Information eXchange (MIX) standard, which will be a replacement for MUC. This will impact FMUC, which is expected to involve to FMIX.

Conclusions

This paper has set out the current differentiating capabilities in M-Link products for Naval XMPP deployment. A number of planned features are described here.