Isode’s Messaging and Directory Server software is used by Government, Militaries, Intelligence Services, Aviation Authorities and Commercial organizations worldwide. Isode is an Open Standards company that excels in providing robust, scaleable products and excellent support. Isode products are most often delivered as part of a larger system implemented by our network of solutions partners.

In the military arena, Isode products conform to all of the relevant military messaging and directory standards including:

STANAG 4406: The NATO standard for Military Messaging based on X.400

STANAG 4406 Annex E: Support for very low bandwidth links such as HF Radio ACP 133: The military directory standard

STANAG 5066 SIS protocol: Enabling an application to connect to a HF Modem through a STANAG 5066 server over TCP/IP

Military Messages often need to be transferred over low bandwidth networks, in particular HF Radio and Satellite Networks. The two military specifications for this type of messaging environment are NATO's STANAG 4406 Annex E and ACP 142 developed by the CCEB (Combined Communications-Electronics Board – AU, CA, NZ, U.S., U.K.). There are a number of basic technical challenges that arise from military messaging deployments, some of which are particularly relevant to constrained communications channels.

• Low bandwidth. Many of the communication channels used are very slow, down to as little as 75 bits per second. With bandwidth this constrained, it is imperative that protocols make efficient use of it


• High latency. Very often, slow links have long round trip times. Satellite links are usually faster, but have very high latency. To work well in high latency environments, protocols should be “non-blocking” as much as possible.


• High error rates. Typical communication channels will often have high error rates, and applications must be robust to this


• Multicast. Many of the communication channels used are 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. To some extent, this can compensate for low bandwidth


• 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


• Priority. 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

Scenarios
This section considers a number of scenarios where the technologies described here are important and is not intended to be an exhaustive list.

Surface Fleet Communication
Naval communication is a major target. Although communication could flow from the strategic environment directly to task force ships using broadcast radio, this is not generally the approach used.

When ships are deployed as part of a task force, communication will generally go to the designated command ship (usually a larger surface unit with the necessary command, control and communication equipment).

At the strategic level, messages may come from a COMCEN (Communications Centre) on shore or directly from originators in the strategic environment. Maximum support of messages direct from originators is desirable. Messages are then relayed onwards to the other ships in the task force, often using the same communications technology as in ship to shore.

The illustrated scenario above depicts use of satellite to reach the command ship and broadcast HF (high frequency) radio for communication with the other units in the task force. Multicast can be used for communication from the command ship to the other ships. In EMCON (Emissions Control), messages can be received from shore or from other vessels, but not transmitted between ships or back to shore. More complex situations may arise with individual vessels in EMCON.

In general, a ship would have a number of potential internal message recipients, and the external message communication needs to be connected with the internal messaging infrastructure.

Submarine Communication
Communication with submarines introduces a number of special requirements. Submarines may make use of higher bandwidth channels when they are on the surface. They will also use VLF (very low frequency) radio, which has a data rate of around 300 bits per second. VLF radio has the advantage that it will penetrate below the surface for a moderate distance, and so can be used by a submarine without surfacing.

When submarines dive below the level of VLF penetration, they will be out of all communication, and so this leads to three basic states: full communication; EMCON; no communication. These need to be managed, and shore systems will be most effective if they understand the current state of communication, a situation also relevant to the previous scenario. This is achieved by planned timing of communication status, which is shared between submarine and shore.

Army Deployment
The army has similar requirements. Typically, there will be high bandwidth communication to field HQ. Communication to field units may be bandwidth constrained, and there may be requirement for EMCON. In some situations, store and forward messaging is useful, for example to send key information (e.g., map data) or to send a formal message in preference to voice communication.

In the scenario illustrated above, there is no direct communication from field HQ to a second field unit, but messages can be relayed by use of the messaging system in the first field unit. This relay needs to be fully automated, and not require manual intervention at the first field unit.

Special Forces
Another requirement is to support special forces operatives, illustrated to the right. It will often be desirable or essential to have radio silence (EMCON), but to retain the ability to listen and to receive messages.


The next diagram reveals a STANAG 4406 Annex E messaging architecture, with protocols down to the ACP 142 level. Mappings below ACP 142 to support Satellite and HF Radio are described later.

STANAG 4406 Messaging
STANAG 4406 defines a family of protocols to support military messaging, based on the ITU X.400 Standards.

• STANAG 4406 specifies an end to end message protocol for communicating between a pair of messaging clients, which are referred to as User Agents (UA). This end to end protocol is based on the X.400 P2 Interpersonal Messaging Protocol, extended by the P772 protocol defined in STANAG 4406 that provides enhancements for military service capabilities and military body parts


• STANAG 4406 messages are switched by store and forward message switches, which are referred to as Message Transfer Agents (MTA). When MTAs communicate over a high speed network they use the X.400 P1 Protocol, which has a mapping onto TCP/IP referred to as “full stack”. The TIA and LMTA are special types of MTA, which are described in more detail later. The diagram above shows two of the MTAs communicating using X.400 P1


• A UA may communicate directly with an MTA using X.400 P3, or indirectly by a Message Store (MS) using X.400 P7. Both options are shown above. Further information on use of a Message Store is given in the Isode Whitepaper Why X.400 is good for high reliability messaging

STANAG 4406 Annex E
STANAG 4406 Annex E defines a light weight alternative to (full stack) X.400 P1 for communicating between a pair of mail transfer agents (MTAs). This is shown in the diagram above, communicating between the MTA (TIA) and MTA (LMTA).

STANAG 4406 Annex E specifies operation over ACP 142, which is described below. Annex E uses the core format of X.400 P1, but replaces the “full stack” mapping with a light weight mapping that comprises:

• A simple protocol that provides the necessary services over ACP 142, and minimizes overhead. This provides a block of data to ACP 142 that encapsulates the X.400 P1 information


• Annex E provides general purpose data compression, that helps reduce data transfer volume for protocol, addressing information, and general data transferred (e.g., text). This compression complements application specific compression techniques (e.g., map and image compression)
  Distributed operation procedures for an X.400 MTA, to correctly integrate with EMCON and multicast


• The key functions of Annex E are to reduce to a minimum the amount of data transmitted, and to integrate ACP 142 multicast and EMCON functionality into an X.400 MTA

ACP 142
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, specifically designed to support NATO’s STANAG 4406 Annex E.

ACP 142 is an end to end protocol, that can map onto various underlying transport mechanisms described later. It works to transfer data reliably from one system, to one or more recipient systems. A brief summary of how it works is as follows:

1. It works out the address to use for the set of intended recipients. There are three options:

• Single recipient (Unicast). ACP 142 is fundamentally a multicast protocol, and unicast is a special case. For Unicast, the standard address of the recipient is used.


• Static multicast. Here a multicast address is assigned to a fixed set of recipients. 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.


• 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

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.

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. This will allow the sender to retransmit lost packets, and to efficiently complete transfer of the data to all recipients.

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.

6. ACP 142 is aware of STANAG 4406 (six level) message priority. Higher priority packets are always sent first by ACP 142. This means that a higher level 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.

LMTA and TIA
Annex E defines protocols and procedures for integrating an X.400 MTA with ACP 142. Annex E defines two basic configurations of MTA.


1. 1. LMTA (Lightweight MTA). This is an MTA where the only external communication makes use of P1/Annex E. An LMTA is appropriate for a ship where all internal communication goes direct to the LMTA.


2. 2. TIA (Tactical Interface Agent). This is an MTA which makes use of P1/Annex E to communicate with LMTAs (or other TIAs). It will also communicate with “full stack” P1 to other MTAs, to enable LMTAs to be interconnected to a general X.400 network.


3. Isode’s M-Switch X.400 can act either as an LMTA or as a TIA. This is a configuration choice, and there is no product difference between TIA and LMTA.


Supporting Small Systems
For a large unit, such as a ship that has multiple users, it is natural for the system to contain an MTA (LMTA or TIA). The MTA will enable local message distribution and give a natural external interface. For small systems, typically supporting only one user, Isode recommends the architecture as illustrated in the diagram at the bottom of the previous column:

This approach uses an LMTA on the same machine as the mail client. The LMTA would have a very simple local and routing configuration. The benefits of this approach are:


1. There are no changes to the mail client needed to support a bandwidth constrained environment.


2. The LMTA is optimized to handle the constrained communication channel, and can efficiently manage retransmission and other procedures.


3. For a modern platform, and efficient MTA such as Isode M-Switch X.400, there is little functional or system overhead in having an MTA on the local system.

Supporting Different Networks
ACP 142 and STANAG 4406 Annex E can be used over multiple network technologies — this article looks at use of Satellite Networks and HF Radio.

Satellite Networks
Satellite networks provide IP, and so full stack P1 could be used over TCP/IP. This may be done, but in many situations there are the following advantages to using STANAG 4406 Annex E and ACP 142:


1. Satellite networks are often quite slow, and the performance advantages of Annex E to reduce data volumes can be beneficial.


2. Satellites have high latency, and ACP 142 is optimized for high latency networks.


3. For messages sent to multiple destinations, ACP 142 allows the broadcast capability of the satellite to be used, which is desirable to optimize overall network use.


4. ACP 142 supports recipients in EMCON, which is not possible with protocols operating over TCP.


ACP 142 makes use of UDP (User Datagram Protocol) to operate directly over IP. This configuration can work over any IP network, making use of IP multicast. To support multicast, multicast support is necessary in all of the routers used. The example here shows a satellite connection between a pair of routers. This reflects a typical configuration, as in general the MTA will not be connected directly to a satellite router.

HF Radio
HF Radio is important for military communications, because of its effectively unlimited range. Applications running over HF Radio use STANAG 5066.
The diagram to the right shows the protocol stack used over HF Radio. The protocol architecture has ACP 142 operating directly over STANAG 5066. This direct mapping is optimized, and handles priority, as the priority of each ACP 142 packet is mapped on STANAG 5066 priority. This is important if multiple applications are operation over one modem/radio.

A key capability of STANAG 5066 (illustration above) is that it enables multiple applications to share a single modem/radio. STANAG 5066 applications connect by a STANAG 5066 standard protocol to a single STANAG 5066 server associated with the modem/radio. This also allows the application to run on a different computer and connect to the STANAG 5066 server over TCP/IP. This is convenient for large deployments. For small deployments, all components may run on a single system.

Handling Multiple Communication Channels
The article so far has primarily considered use of a single constrained bandwidth communication channel. This section shows that many real deployments have multiple communication channels.

A ship will typically have two or more communication channels (illustration below): HF Radio and Satellite. The combinations in use will depend on threats:


• Both channels in EMCON


• Both channels active.


• One channel in EMCON. Typically Satellite channel will be in EMCON, because it has a stronger signal and is more visible. However, the “pencil beam” nature of the satellite and location of threat may lead to HF channel in EMCON and satellite active


• When both channels are open, use of Satellite may be preferred (higher bandwidth) or use of HF radio (lower cost), or a more complex preference dependent on messaging load



With a headquarters unit, the EMCON status is simpler (as it would never be in EMCON), but there may be many more channels, for example to support multiple satellites with different ships reached through different satellite services. Other shore based systems, such as Special Operations could be in EMCON. It can be seen that these multi-channel scenarios add some significant complexity.

Multi-Hop Routing
The initial scenarios showed situations where a message needs to be sent from TIA to LMTA and then on to another LMTA. This multi-hop routing can be important where there is not direct connectivity from TIA to an LMTA. A good STANAG 4406 Annex E solution should support multi-hop routing.



Measuring MMHS Performance over HF Radio and Satellite — STANAG 4406 Annex E Encoding/Compression

This section of the article looks at the encoding and compression of STANAG 4406 Annex E messages, which is common to both HF Radio and Satellite transmission. The information shows that the encoding of messages is reasonably efficient, and that effective compression can be achieved.

What is Being Measured
The diagram at the top of the next column shows the protocol layers for MMHS over HF Radio and Satellite. This paper looks at the Message Format, which is the static format common to both HF Radio and Satellite.

Network Bandwidth
Constrained bandwidth covers a range of speeds, and the numbers in this article have differing impact across this range of speeds. Table 1 on Page 84 gives notes on different speeds. The implications of the analysis in this paper and its companions will have quite different impact across this range of speeds.

Why Measure?
When communicating over constrained networks such as HF Radio and Satellite, it is important to optimize use of the link. In order to do this, an understanding of the operation of the underlying protocols and the applied load is important. For most scenarios, these measurements need to be interpreted in the context of anticipated traffic load, network configuration and network speed. Outcome of this interpretation may be one or more of:


1. Information on the best approach to configuration and option selection for the applied load.


2. An understanding that the protocols are performing well, and where the limits of performance are.


3. Information on how protocols may be adapted to improve performance.
   There are many ways that protocols can be modified. We have observed attempts and suggestions for change that we suspect will make little difference to performance for real traffic. This analysis aims to help determine the most effective points for protocol change to address real operational problems.


How Measurements Were Made
Messages were created using Isode’s test User Agent XUXA, and sent over STANAG 4406 Annex E. The size of three things was measured:

1. The Message Content (P2 or P772) size.


2. The size of the uncompressed message envelope (including message content) in P1 format.


3. The size of the compressed output of STANAG 4406 Annex E, which is passed to the ACP 142 layer.


The first two measurements show the ASN.1 encoded size of the data to be transferred, and the third measurement shows the effect of the STANAG 4406 Annex E encoding and compression. Annex E allows a choice of compression algorithm, but only one (zlib) is currently mandated.

These tests use zlib compression. An initial “base” test was done, which comprised a message with an absolute minimum of features, and short (but reasonable) X.400 addresses. Subsequent tests added one or more items relative to the “base”, to show the effect of different services and attachments.

The Measurements
This table is far too large to comfortably fit within the confines of MilsatMagazine. Should you wish to view the data in this highly informative table, please either select the following link, or copy and paste the URL into your Internet browser application...

http://www.isode.com/whitepapers/mmhs-hfradio-satellite.html

Analysis & Conclusions
Looking at the data at the linked table above, the following conclusions can be drawn:


1. The basic ASN.1 encoding used in X.400 and STANAG 4406 is a reasonably compact and efficient encoding (unlike Text and XML encodings) and the data sizes are reasonable for the information carried.



2. The “base” size of data transferred of 233 bytes represents an approximate minimum data size. For most environments, this overhead will be quite acceptable. A future white paper will consider situations where this size may be too large.


3. Addition of features appears to give a sensible “per feature” overhead for a range of different extensions. Where it is necessary or desirable to go beyond basic capabilities, the encoding cost of these additional features is acceptable.


4. The standard zlib compression achieves 35-40 percent compression with the core message and message features. This seems reasonable. It is likely that some of this compression is due to regularity of the ASN.1 encoding.


5. Body part compression is very much dependent on the compression achieved for the body part in question, and for larger messages compression will be dominated by body part compression. Compressed data types such as JPEG give almost no compression, whereas text documents and formats such as Word compress well. Where heavy use is made of a special body part type, it may be appropriate to use compression algorithms optimized for that sort of data.

The broad summary is that for most deployments and configurations that the STANAG 4406 Annex E encoding is appropriately compact and that the compression will work well, providing clear benefit.

Isode we builds high performance messaging and directory server products, using Open Standard protocols. The Company’s M-Vault (LDAP/X.500 Directory Server), M-Switch (SMTP and X.400 Message Switch), M-Box (POP/IMAP Message Store) and M-Store X.400 (X.400 Message Store) products are used around the world by Aviation Authorities, Government Departments, Military & Intelligence Services, Financial Institutions, Internet Service Providers as well as a host of other businesses in areas where secure and robust directory and messaging servers are vital. You can locate additional information at their website... either select the graphic below or enter http://www.isode.com into your Internet browser.

Further Information
This article has described STANAG 4406 Annex E from a scenario and protocol architecture perspective. Packaging Military Messaging for HF Radio and other Low Bandwidth Links, provides a different perspective, looking at hardware and how component products are grouped together.

Isode’s military messaging solution is summarized on the web page :

Military Message Handling Systems (MMHS)

About the author
Steve Kille is the CEO of Isode, which he founded in 1992 and re-launched in 2002. Steve is an Internet pioneer and visionary, who has been closely involved with many key Internet technologies since 1980, and has brought several of them to market with Isode Steve led the original Isode business of high end messaging and directory server products. In 1999, he merged Isode to found MessagingDirect. MessagingDirect developed the e-Courier electronic Document Delivery Product using the Isode products. MessagingDirect was sold to ACI Worldwide in 2001 and Steve negotiated a deal with ACI to re-launch Isode in 2002.

Steve is a well known speaker and recognized industry visionary. He has 20 years of experience with messaging, directory, security, and e-commerce, and has been responsible for a range of widely deployed products and standards. He has written more than 40 RFCs (Internet Standards) and is one of the authors of LDAP (Lightweight Directory Access Protocol).

From 1981 to 1992, he was a Senior Research Fellow at University College London and led US and European funded research projects on messaging, directory, networking and distributed systems. He has worked with the Internet and Internet standardization since 1981. He has published a book and numerous papers and articles. Steve has BA and MA honors degrees in Physics from Oxford University, and Masters degrees in Electrical Engineering from University of Manchester Institute of Science and Technology and Stanford University, where he was a Fulbright scholar.