Military Messaging. Over Low. Bandwidth. Connections

Transcription

1 Military Messaging Over Low Bandwidth Connections White Paper

2 Contents Paper Overview 3 The Technical Challenges 4 Low Bandwidth 4 High Latency 4 High Error Rates 4 Multicast 4 Emission Control (EMCON) 4 Priority 4 Scenarios 5 Surface Fleet Communication 5 Submarine Communication 6 Army Deployment Communication 6 Special Services Communication 7 Drivers for Change 8 Technology Summary 9 Radio and Satellite Networks 9 IP Integration and Routers 11 ACP STANAG4406 Annex E 12 LMTA an TIA 13 Annex E Server Solution 14 Solution Overview 14 ACP142 Channel Operation 14 Configuration Management 15 Operational Management 15 Audit, Tracking and Statistics 16 Communication Channel Integration Points 16 Handling Multiple Communication Channels 17 Scenarios and Requirements 17 Network Level Configuration 18 MTA Level Configuration 19 About Boldon James 20 Further Information Boldon James Ltd. All rights reserved. The copyright of this paper is solely vested in Boldon James Ltd. The contents must not be reproduced, used, distributed or disclosed (wholly or in part) without the prior written permission of Boldon James Ltd. The Boldon James logo and all product names are trademarks of Boldon James Ltd. All other trademarks are the property of their respective owners and are acknowledged. Boldon James Ltd. (registered number ) is registered in Great Britain with registered offices at Berkshire SL6 1SQ.

3 Paper Overview Military messages often need to be transferred over low bandwidth networks such as High Frequency (HF) radio and other constrained communication channels. Two military communication standards have evolved to deal with these messaging environments, the Combined Communications Electronics Board (CCEB) of AU, CA, NZ, US, and the UK, has developed ACP142, and NATO s STANAG4406 Annex E. This paper describes how the STANAG4406 Annex E and ACP142 technology standards are used to support military messaging through different deployed scenarios. It then describes our approach to implementing these technologies through our Annex E Server and how basic and advanced operational problems, management and integration with other components, as part of a larger solution are addressed.

4 The Technical Challenges There are a number of basic technical challenges that arise from military messaging deployments, some of which are particularly relevant to constrained communications channels and are summarised below. These challenges will be illustrated through scenarios. Low Bandwidth Many of the communication channels used are very slow, down to as little as 300 bits per second. With bandwidth this constrained, it s imperative that protocols make the most efficient use of it. High Latency Very often, slow links have long round trip times. Satellite links are faster, however they have a very high latency. To work well in high latency environments, protocols should be as non-blocking as possible. High Error Rates Typical communication channels often have high error rates and applications must be robust enough to cater for them. Multicast Many of the communication channels used are inherently multicast, for example, radio and satellite. Messages are often sent to multiple destinations and it s desirable that protocols can take advantage of the multicast nature of the underlying media. To some extent, this can compensate for low bandwidth. Emission Control (EMCON) In many situations, deployed units don t want to broadcast signals in order to help hide their location. The situation where signals can be received and not sent is referred to as EMCON. It s important to be able to send messages to a unit in EMCON. Priority Formal military communications have an associated priority i.e. precedence. In a low bandwidth environment it s easy for message queues to build up, so it s critical to have mechanisms that ensure the highest priority messages get through first.

5 Scenarios This section considers a number of scenarios where the technologies are important. It s not intended to be an exhaustive list. Surface Fleet Communication Naval communication is a major target. Although communication can flow from the strategic environment directly to taskforce ships using broadcast radio, this is not generally the approach used. When ships are deployed as part of a taskforce, communications generally go to the designated command ship which is usually a larger surface unit with the necessary command, control and communication equipment. At the strategic level, messages may come from a Communications Centre (COMCEN) located on shore or directly from originators in the strategic environment. Therefore maximum support of messages direct from originators is desirable. Messages are then relayed onwards to the other ships in the taskforce, often using the same communications technology as in ship-to-shore. Figure 1 shows the use of satellite communication to reach the command ship and broadcast HF radio for communication with the other units in the taskforce. Multicast can be used for communication from the command ship to the other ships. In EMCON, messages can be received from shore or from other vessels, rather than transmitted between ships or back to shore. More complex situations may arise with individual vessels in EMCON. In general, a ship would have quite a number of potential internal message recipients, and the external message communication needs to be connected with the internal messaging infrastructure. Figure 1 Surface Fleet Communication

6 Submarine Communication Communication with submarines introduces a number of special requirements. Submarines may use higher bandwidth channels when they are on the surface and also use Very Low Frequency (VLF) radio, which has a data rate of around 300 bits per second. VLF radio has the advantage that it can penetrate below the surface for a moderate distance and be used without surfacing. When submarines dive below the level of VLF penetration, they are out of all communication. There are therefore in one of three states: 1. full communication 2. EMCON 3. no communication. These need to be managed and shore systems will be most effective if they understand the current communication status. This is achieved by the planned timing of communication status shared between the submarine and the shore. This is also relevant to the previous scenario. Army Deployment Communication Figure 2 Submarine Communication The army has similar requirements. Typically, there will be high bandwidth communication to the field HQ and communication to field units may be bandwidth constrained. Therefore, there may be a requirement for EMCON. In some situations, store and forward messaging is useful, for example to send key information such as map data or to send a formal message in preference to voice communication. In Figure 3 below, there is no direct communication from field HQ to a second field unit. Instead messages are relayed using the messaging system in the first field unit. This relay needs to be fully automated rather than requiring manual intervention at the first field unit. Figure 3 Army Deployment Communication

7 Special Services Communication Another requirement is to support special services operatives. It will often be desirable or essential to have radio silence (EMCON) as well as retain the ability to listen and receive messages. Figure 4 Special Services Communication

8 Drivers for Change Military formal messages over low bandwidth networks are generally sent using ACP127, which is a text based protocol. There are two main reasons why formal messaging is moving on from this older technology: 1. NATO nations are moving to an Microsoft Exchange / X.400 (ACP123 & STANAG4406) based system for formal messaging, and all components need to be migrated to become part of this new system 2. ACP127 is text only. There is now a requirement to send other types of information such as images, maps, photos and documents.

9 Technology Summary The overall layered architecture for the new solution is illustrated in Figure 5 below. The components and layers are described in more detail in the following sections. Figure 5 Layered Architecture Solution Radio and Satellite Networks It s beyond the scope of this whitepaper to discuss in detail radio and satellite networks i.e. the typical constrained communication channels, and their related technologies. The focus is therefore on the messaging applications that use them. The characteristics of these underlying communication channels and their integration are critical to the overall solution. A common underlying standard is STANAG5066 Profile for Maritime High Frequency Radio Data Communications and is used as an example communications technology in this paper. Other underlying technologies utilised include: different protocols to support different underlying technologies vendor proprietary protocols and vendor extensions to STANAG5066 future NATO standards. There are two basic approaches to support applications over the underlying communications channels 1) with Internet Protocol (IP), and 2) without IP. STANAG5066 defines how to support IP (Annex F.10) as shown in Figure 6 below.

10 Figure 6 - STANAG5066 Supporting IP (Annex F.10) Direct use of STANAG5066 without IP for military messaging is defined in Appendix A of Annex E of STANAG4406, and has the advantage of removing a protocol layer. This only improves bandwidth utilisation by a small amount. Using IP however, has a number of advantages: 1. the application is decoupled from the router using a standard protocol interface, therefore the application and router components can be decoupled. This leads to the other advantages described below 2. procurement is simplified, as the application and channel can be selected separately i.e. mixed and matched 3. multicast can be supported which generally requires the IP layer 4. EMCON can be supported, however, direct application binding does not always support this 5. multiple applications can easily share the underlying channel 6. migration of applications to new channels is easy 7. application support of multiple communication channels is straightforward. Because of these advantages, this paper is focused on using IP. Our products support the use of and enable the direct use of the underlying protocol to be supported as illustrated in Figure 7 below. Here the resulting product is a close integration between a communication channel and our Annex E solution. Annex E MTA ACP 142 Communications Channel (eg STANNAG 5066) (Radio Vendor) API to Communication Channel (defined by Vendor) Figure 7 Underlying Protocol Support from Boldon James

11 IP Integration and Routers The approach to integrate an application with two communication channels using IP is illustrated in Figure 8 below. All of the components talk IP and will typically be connected by a local network such as Ethernet when the components are not operating on the same system. The application will be an IP end point. The communication channels interconnect with other systems and a router will be integrated with the communication channel so that appropriate packets will be correctly routed over it. In order to support multicast applications, it s necessary to support multicast at the IP level. Where multicast is needed, the routers must be capable of multicast. Figure 8 Application Integration with Two Communication Channels Using IP ACP142 ACP142 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 STANAG4406 Annex E. P_Mul is an end-to-end protocol that makes use of the Internet Standard User Datagram Protocol (UDP) over IP. It works to transfer data reliably from one system to one or more recipient systems. In summary it works as follows: 1. it works out which IP address to use for the set of intended recipients from three options: - Single Recipient (Unicast) ACP142 is fundamentally a multicast standard. Unicast is a special case and the standard IP address of the recipient is used - Static Multicast Here a multicast IP address is assigned to a fixed set of recipients. This is useful for very small networks and for frequently used combinations of recipients in large networks. A static multicast address can be used without any special negotiation

12 - Dynamic Multicast Each sender has a set of IP multicast addresses reserved for dynamic multicast. ACP142 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 allows the sender to re-transmit any lost packets and to efficiently complete the 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. The sender will simply re-transmit the entire message at intervals, to maximise the likelihood that all packets are correctly received 6. ACP142 is aware of STANAG4406 (six level) message priority. The priority is passed down to the packet level and higher priority packets are always sent first. 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 ACP142 works is quite straightforward and it therefore provides the core EMCON and multicast functionality needed. STANAG4406 Annex E STANAG4406 Annex E specifies operation over ACP142. It uses P1 and still uses X.400 P1, however replaces the full stack. Annex E provides a number of capabilities: 1. the full stack between P1 and IP is replaced with a simple protocol that provides the necessary services over ACP142, and minimises overheads. This provides a block of data to ACP142 that encapsulates the X.400 P1 information 2. it provides general purpose data compression to help reduce data transfer volume for the protocol, addressing information and general data transferred (e.g. text). This compression complements application specific compression techniques for map and image compression for example 3. it adapts to distributed operation procedures for a Microsoft Exchange or an X.400 Message Transfer Agent (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 ACP142 multicast and EMCON functionality into an X.400 MTA.

13 LMTA and TIA Annex E defines protocols and procedures for integrating an X.400 MTA with ACP142, and defines two basic configurations of MTA: 1. Lightweight MTA (LMTA) This is where the only external communication makes use of P1 / Annex E. It s appropriate for a ship where all internal communication goes direct to the LMTA 2. Tactical Interface Agent (TIA) This makes use of P1 / Annex E to communicate with LMTAs (or other TIAs). It will also communicate with the full stack P1 to other MTAs enabling LMTAs to be interconnected to a general X.400 network. Our Annex E Server can act either as an LMTA or as a TIA. This is a configuration choice only as there is no product difference between TIA and LMTA. Figure 9

14 Annex E Server Solution Our Annex E Server provides for both ACP142 and STANAG4406 Annex E. This section provides a high level overview of the implementation and the key design features. Solution Overview Figure 10 Boldon James Annex E Server Components Figure 10 above illustrates how the relevant core components of our Annex E Server operate. The central part of an MTA is the queue of messages in disk. The messages can then be sent onwards or delivered locally and are then removed from the queue. Even when a message is only held for a few hundred milliseconds, this reliable storage is central to MTA function. The Annex E Server has a queue manager process (QMGR) responsible for scheduling and controlling MTA operations. QMGR interacts with the communication channels that send and receive messages. The X.400 channel is used for handling the full stack X.400 P1 communication over high bandwidth channels. ACP142 and Annex E support are provided by a new ACP142 / X.400 channel that provides support for transferring X.400 P1 over ACP142. ACP142 Channel Operation The ACP142 channel is a static process that listens in on a UDP port for incoming packets. This is essential as incoming data may arrive at any time. It can access the MTA queue and has its own disk cache that contains information that will optimise performance and allow the correct operation in the event of a system restart. In particular: status of all transfers (send and receive) pre-computed data packets to send received data packets from partial transfers. The ACP142 channel will gather incoming packets and report transfer status to the QMGR. When a complete message is received, it s submitted into the M- Switch queue. When a message is to be routed over ACP142, the QMGR will

15 instruct the ACP142 channel to process the message in the MTA queue. It then pre-computes the data packets and sends the message. It also will inform QMGR of the transfer status and update information in the MTA queue when needed. Configuration Management Our approach to configuration management is to hold information in a directory. In most deployments a directory server will be operated on the same server as the Annex E Server. Directory based configuration allows for secure client / server configuration management and facilitates sharing configuration information between multiple mail servers. The Annex E Server and the ACP142 channel both access the directory using Lightweight Directory Access Protocol (LDAP). Operational Management The QMGR process is at the centre of operational control. It interacts with the ACP142 channel for both incoming and outgoing messages. When a message needs to be sent over ACP142, it requests a start transfer to the ACP142 channel, which then begins to process the message. QMGR has the option to pause or abort the transfer of messages. This can be in response to specific operator control, as a consequence of QMGR intelligent scheduling, or in support of general events such as a minimise where only messages above a certain priority are processed. The ACP142 channel will periodically report to the QMGR the transfer status of both inbound and outbound messages. This ensures that QMGR is aware of the status of all partially complete inbound and outbound transfers. Management applications interact with the QMGR using a Switch Operational Management (SOM) protocol. This is a management interface that allows operators to view message and queue status and perform control operations such as pausing transfer, requesting non-delivery, and the re-direction of messages.

16 Audit, Tracking and Statistics The Annex E Server records its activity into an audit log that is processed and placed into an ODBC audit database. It publishes the schema of this audit database, in order that third party applications can analyse the data, for example, to generate reports. It also provides a number of applications based on the audit database, in particular to enable message tracking and provide statistics. Communication Channel Integration Points The Annex E Server will generally be part of a larger system, therefore good integration is critical. The basic integration approach with communication channel components is via IP. However, this could be replaced with direct integration with the communication channel. Moving a system into EMCON requires changes to both the communication channel and the Annex E Server. By holding EMCON status as a directory attribute, it s straightforward to integrate control into a separate application. This enables the integrator to provide a simple EMCON control allowing the operator to switch both components from one place. Bandwidth and retransmission parameters are also externally configurable. In a Transport Control Protocol (TCP) system, a good TCP implementation will automatically adapt its parameters to the performance of the underlying channels. This is not so easy for ACP142, as it doesn t receive information to enable this to happen, particularly in EMCON mode. Changes in the underlying communication channel may lead to an increase or decrease of available bandwidth, as would other applications sharing the same underlying channel. It s therefore desirable to integrate this control with the underlying communication channel and directory based configuration enables this.

17 Handling Multiple Communication Channels The paper has primarily considered using a single constrained bandwidth communication channel. This section shows that many deployments have multiple communication channels and explains how our Annex E manages this. Scenarios and Requirements Figure 11 A ship will typically have two or more communication channels: HF radio and satellite as shown in Figure 11 above. The combinations in use will depend on the type of threat, for example: both channels are in EMCON both channels are active one channel is in EMCON, typically the satellite channel as it has a stronger signal and is more visible. However, the pencil beam nature of the satellite and the location of the threat may lead to using an HF channel in EMCON and the satellite in active. When both channels are open, the use of satellite may be preferred for higher bandwidth or HF radio as it s lower cost, or a more complex preference depending on the messaging load. With a HQ unit, the EMCON status is simpler as it would never be in EMCON. However, 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. Therefore, multi-channel scenarios add significant complexity.

18 Network Level Configuration Figure 12 Network Level Configuration Given the use of IP, a natural approach to handling multiple networks is to use a single ACP142 channel and IP level configuration as shown in Figure 12 above. In this structure, an MTA has a single ACP142 channel connected to the two communication channels. IP routing is then used to control which of the channels are used. This is a clean and simple approach with easy switching between channels and switching channels mid-message. However, it has a number of disadvantages: ACP142 parameters, such as transmission rate and re-transmission timers, cannot be tuned for both communication channels at the same time where messages, or specific classes of message (e.g. high priority), need to be sent over a specific channel, this cannot be configured dealing with multicast i.e. where connectivity of the two channels is different, is likely to be very complex to configure. For these reasons, MTA level configuration as described in the next section, is usually preferable.

19 MTA Level Configuration Figure 13 MTA Level Configuration Configuration can be managed at the MTA level by using one channel for each individual communication channel. ACP142 parameters can be tuned appropriately for each communication channel as shown in Figure 13 above. The Annex E Server routing can be used to select an appropriate channel for each recipient. When channels need to be changed while messages are queued, a routing table modification followed by reprocessing the queue manages this. This will cause transfers on the first channel to be aborted and then the messages will be moved to the other channel and queue.

20 About Boldon James Boldon James has over twenty years experience specialising in message handling solutions tailored to meet the formal messaging requirements of the worldwide Defence, Homeland Security, Aviation and Government sectors. Using extensions to Microsoft commercial off-the-shelf (COTS) software, Boldon James provides the added functionality that customers require, but retains the ease of use and implementation of a COTS solution. This results in solutions with a low total cost of ownership and significantly reduced deployment risk. Boldon James is a Microsoft Certified Partner. Further Information Visit: info@boldonjames.com Tel: +44 (0)