ACP 142: SMTP & STANAG 4406 Messaging for Constrained Networks

ACP 142 (“P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments”) can be used with two messaging families:

• STANAG 4406. STANAG 4406 Annex E defines operation of STANAG 4406 military messaging over ACP 142, and is the NATO standard for operation over networks of 20 kbps or slower. Because of this, STANAG 4406 Annex E is more widely referenced than ACP 142, although it is ACP 142 that provides the majority of the necessary functionality.
• SMTP. SMTP based messaging, both standard commercial messaging and military messaging using RFC 6477 can be operated over ACP 142 using MULE (“Multicast Email”) specified in RFC 8494.

Although ACP 142 can be used for general purpose environments, it is of particular interest for military deployments and so this paper will primarily use military examples and consider military requirements.

Requirements for Messaging over Constrained Networks

What is a Constrained Network?

Constrained networks show at least one and often all of the following characteristics:

• Low bandwidth. Communication channels are slow, down to as little as 75 bits per second. With bandwidth this constrained, it is imperative that protocols make efficient use of it. NATO defines a constrained link as having a speed of less than 20 kilobits/second.
• High latency. Slow links typically have long round trip times measured in seconds or tens of seconds. Faster links, particularly over Satellite, can also have high latency.
• High error rates. Constrained links will often have high error rates.

Problems with General Purpose Messaging Protocols

Fast links will typically exchange messages using SMTP over TCP/IP or STANAG 4406 Annex A over TCP/IP. These work well for faster networks, but have a number of issues for use on constrained links:

• No compression. When bandwidth is limited, it is highly desirable to use compression to maximize data transfer over a link.
• Handshaking. TCP and SMTP handshaking can lead to significant delays in message transfer over a high latency network.
• In a network with high error rate and high latency, TCP performance can be very poor.
• No Priority support. Formal military communications have an associated priority (precedence). In a low bandwidth environment, it is easy for message queues to build up, and so it is critical to have mechanisms which will ensure that the highest priority messages get through first.
• Point to point communication only. Constrained communication channels are often inherently multicast (e.g., radio, satellite). Messages are often sent to multiple destinations, and it is desirable that protocols can take advantage of the multicast nature of the underlying media.
• No EMCON (Emission Control). Deployed units will in many situations wish to not broadcast signals, in order to help hide their location. The situation where signals can be received but not sent is referred to as EMCON. It is important to be able to send messages to a unit in EMCON.

Where to use ACP 142

ACP 142 is primarily used for communication between MTAs (Message Transfer Agents). The above diagram shows three MTAs communicating over a constrained network using ACP 142 multicast and unicast. MTAs supporting ACP 142 will generally be able to also communicate with other MTAs using standard protocols such as SMTP.

An ACP 142 deployment is likely to include MTAs which relay to other protocols and other MTAs which only support local users. This can include single user systems. ACP 142 is going to be useful in any networking situation where network links are constrained. Particular consideration should be given to:

• Speed. NATO recommends using ACP 142 at less than 20 kilobits/second. ACP 142 will transfer messages over  a link efficiently. At 20 kilobits/second a 5 Mbyte photograph will take 30 minutes to transfer. Significantly improved performance relative to SMTP (primarily from compression) is a key benefit.
• Latency. TCP based protocols such as SMTP make poor use of link capacity over high latency links, particularly where there is packet loss. ACP 142 will give better performance.
• Multicast IP networks. Where multicast IP is available,  ACP 142 multicast will enable significantly improved messaging performance.
• HF Radio. HF has particularly awkward characteristics that mean standard messaging protocols are unsuitable. ACP 142 is an ideal protocol for messaging over HF.

The choice to use a specialized messaging protocol is primarily driven by networking communications. This includes scenarios where high speed networks are normally used, but there are failover considerations to constrained networks. It may be sensible to use ACP 142 as the standard communication, in order to provide good support in the failover scenario.
Constrained links are used in many scenarios, including:

• Reach back links for naval and army groups.
• Beyond Line of Sight communication for Naval Task Groups using HF Radio.
• Mesh networks where concatenation of links leads to high latency.
• HF Communication where Satcom is not appropriate or too expensive.

How ACP 142 Works

ACP 142 “P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments” is a CCEB standard for multicast and EMCON support. It was originally designed to support STANAG 4406 Annex E and can also be used with MULE. ACP 142 provides a content-agnostic approach to sharing data using reliable multicast.

ACP 142 is a MTA to MTA protocol, that can map onto various underlying network mechanisms described later. ACP 142 transfer data reliably from one MTA, to one or more recipient MTAs using an unreliable network layer. A brief summary of how it works is as follows:

1. The sender determines the address to use for the set of intended recipient servers. There are three options:
   1. Single recipient (Unicast). ACP 142 is fundamentally a multicast protocol and unicast is a special case. For Unicast, the standard address of the recipient server is used.
   2. Static multicast. Here a multicast address is assigned to a fixed set of recipient servers. This is useful for very small networks, and for frequently used combinations of recipients in larger networks. A static multicast address can be used without any special negotiation.
   3. Dynamic multicast. Each sender has a set of multicast addresses reserved for dynamic multicast. ACP 142 allows the sender to negotiate a specific set of recipients to be associated with one of these addresses. This allows dynamic multicast to be used for an arbitrary set of recipients. This approach is less common than the first two.
2. The sender breaks up the data to be sent into a fixed number of packets and communicates the number of packets to be sent and the addresses using an Address PDU to all recipient servers.
3. The sender then starts sending out data packets, at a rate appropriate to the underlying communication channel.
4. In non-EMCON, each recipient will communicate back to the sender a list of packets that it has not received (a NACK). This will allow the sender to retransmit lost packets, and to efficiently complete transfer of the data to all recipients.  ACP 142 is primarily a NACK based protocol. When the full message is transferred, each recipient server sends an ACK. The sender then sends another Address PDU, so that recipient servers can determine that the ACK has been received.
5. In EMCON mode, a recipient will not be able to send any data back to the sender. In this situation, the sender will simply retransmit the entire message at intervals, to maximize the likelihood that all packets are correctly received. Messages transfer is acknowledged when recipient comes out of EMCON.
6. ACP 142 transfers all have a priority. Higher priority packets are always sent first by ACP 142. This means that a higher priority message will naturally “overtake” a lower priority message that is partially transmitted.

The details are more complex, but the essence of how ACP 142 works is quite straightforward. It can be seen that ACP 142 provides the core EMCON and multicast functionality needed.

Compression

STANAG 4406 Annex E defines a flexible compression layer for use with ACP 142, which is also used by MULE. Compression is vital for constrained networks. This format provides:

• Ability to carry different content, so that different messaging protocols can be supported. Multiple protocols can be mixed.
• Ability to use different compression protocols, with the compression protocol identified. This enables use of compression appropriate to different applications.
• Option to use the standard DEFLATE compression, which is a good general-purpose compression algorithm suitable for messaging applications.

Use with STANAG 4406 Messaging

STANAG 4406 is the NATO Standard for military messaging. STANAG 4406 Annex E defines a file format for use with ACP 142, based on the standard P1 MTA to MTA protocol. This enables use of ACP 142 for communication between STANAG 4406 MTAs.

Use with SMTP Messaging

SMTP (Simple Message Transfer Protocol) is widely used for general purpose messaging.  It can also be used with RFC 6477 to support military messaging as set out in the Isode white paper Military Messaging (MMHS) over SMTP.

Multicast Email (MULE) is specified in RFC 8494. This defines an SMTP-oriented file format that can transfer messages between SMTP MTAs. MULE also enables key SMTP capabilities, in particular ability to request delivery reports (Delivery Status Notifications) and to transfer 8bit encoded messages.

SMTP messages are widely transferred using 7bit encoding with limited line length, to maximize interoperability. Binary attachments (e.g., Images, Word Documents) are base64 encoded to ensure 7bit. When compression is applied to a base64 encoded attachment, the base64 wrapper compresses reasonably well. However, when the attachment itself is compressible (e.g., a PDF document) the base64 encoding effectively prevents this compression. For this reason, it is recommended to use 8bit (BINARYMIME) message encoding to maximize compression with MULE.

HF Radio

HF Radio is important for military communications, because of its effectively unlimited range. Applications running over HF Radio use STANAG 5066, which is described in the Isode whitepaper [STANAG 5066: The Standard for Data Applications over HF Radio].

ACP142 is the major protocol for modern messaging over HF Radio.

The diagram above shows the protocol stack used over HF Radio. STANAG 5066 standardizes ACP 142 operation over STANAG 5066 in STANAG 5066 Annex Q. The mapping uses unreliable transfer for multicast and EMCON. For unicast point to point transfer, performance is optimized using STANAG 5066 ARQ transfer. Priority is mapped to the STANAG 5066 layer following Annex Q, so that higher priority messages can overtake lower priority ones, even after transfer has started.

This architecture provides good flow control integration between STANAG 5066 and ACP 142. This is important because of the highly variable data rates offered by HF. It is possible to use IP with HF Radio and ACP 142, but this results in significantly poorer performance.

IP Networks

ACP 142 operates over IP using the (unreliable) User Datagram Protocol (UDP) as the mechanism to transfer ACP 142 PDUs, as shown in the diagram below.

Standard MTA to MTA protocols (SMTP or STANAG 4406 Annex A) can be used over IP. However, there are situations where due to high latency or low bandwidth, the ACP 142 based communication will perform significantly better.

Multicast IP

Where multicast IP is available, ACP 142 offers order of magnitude performance improvements by only transferring a single copy of each message.

Multicast IP is used much less than its original designers hoped.  It is used on single subnets, which are usually fast, and for broadcast content.  This limits the general utility of this option.

MANETs

Mobile Ad Hoc Networks (MANETs) are IP networks put together for supporting communications with ad hoc point to point links, often with constrained links.   IP addressing is typically “single subnet” thus making multicast addressing available across the MANET.  This means that ACP 142 is very suitable for MANET deployments.Thank

VHF/UHF

VHF and UHF links are generally point to point.   They will often support IP networking, sometimes in conjunction with STANAG 4691 “Multi-hop IP Networking with legacy UHF Radios: Mobile ad hoc relay Line of Sight Networking” (MARLIN).  Such networks will benefit from ACP 142 for two reasons:

1. Compression, as these are generally slow links.
2. Latency, as these are high latency network and protocols, where SMTP will perform poorly.

SATCOM

Modern SATCOM links are generally fast and can operate reasonably with SMTP. However, older SATCOM links and high latency links can benefit from ACP 142.

M-Switch Implementation of ACP 142

Isode’s M-Switch implementation provides a flexible implementation of ACP 142 that can be used over either IP or STANAG 5066. It enables transfer of STANAG 4406 and/or MULE (SMTP) messages. This gives flexible operation and avoids protocol conversion. It also enables use of STANAG 4406 for military messaging and MULE for informal email.

Handling Multiple Communication Links

It is sometimes desirable to have multiple communications links, for example HF and Satcom. Choice of channel will depend on a range of operational factors. M-Switch enables use of ACP 142 over a mix of communication links, by configuration of an M-Switch ACP 142 channel for each link, and use of diversion configuration to select the link to be used.

Conclusions

ACP 142 provides a flexible messaging transfer protocol that provides superior performance to standard messaging protocols over constrained networks.   It can be used over both IP networks and HF Radio using STANAG 5066.