M-Switch can be configured to support ACP127 and the related text messaging protocols of ACP126, ACP128, DOI 103S and JANAP 128.

In such a configuration M-Switch can act as gateway to other messaging protocols supported by M-Switch (including SMTP, STANAG 4406 and other X.400 varients), act as an ACP127 relay, provide a service to ACP127 end user systems and be used in support of NATO BRASS (Broadcast and Ship to Shore) and BRE1TA (BRASS Enhancement 1 Technical Architecture) deployments.

Organizational Messaging is used by the military and other organizations. It is historically known as "signals" and also described as "formal messaging" and "high grade messaging". Prior to STANAG 4406 and SMTP, organizational messaging was provided by simple text messaging protocols, of which ACP127 is the best known. A list of text based organizational messaging protocols that M-Switch supports, and which we collectively refer to as ACP127, is provided in the conformance section.

ACP127 Capability Overview

M-Switch provides full support for the ACP127 protocol and for the related ACP126, ACP128, JANAP128 and DOI103S protocols, as well as some national variants. The core formats are supported by M-Switch with conversion to other ACP127 variants, SMTP and STANAG 4406. A more detailed description of M-Switch ACP127 capabilities is provided in the whitepaper [M-Switch ACP127 Gateway to STANAG 4406 & MMHS over SMTP].

M-Switch's ACP127 capability can be configured to address various deployment modes, which may be used in combination:

  • ACP127 End User System
  • ACP127 Relay
  • BRASS/BRE1TA
  • SMTP Gateway
  • STANAG 4406 Gateway

ACP127 End User System

ACP127 End Users can be supported by Isode’s Harrier military messaging client, a web interface to military messaging.

Harrier is an SMTP/IMAP client which includes an ACP127 mode and connects to ACP127 systems using the ACP127/SMTP gateway capability within M-Switch. In ACP127 mode Harrier provides all of the capabilities needed in ACP127 including user addresses in ACP127 format (Routing Indicator (RI) and Plain Language Address (PLA)).as well as a choice of IA5 and ATA2 character sets. Email capabilites not suported by ACP127 (such as long lines and attachments) are removed when not in ACP127 mode.

ACP127 Relay

M-Switch can also be configured as an ACP127 relay. Routing between ACP127 peers is configured use Routing Indicator (RI) prefix. This allows for completely flexible routing, with the prefix approach allowing for succinct specification of routing in common relay setups. This can perform protocol conversion (e.g., between ACP 127 and ACP 128).

For each ACP 127 circuit configured the RI of the peer is configured (except for broadcast circuits, which do not have a single peer). Messages will always be routed to this peer. A circuit may also configure a list of RIs and RI prefixes. When a message is routed the RI will be evaluated against all circuits and the longest match will be used to select the circuit to be used. This mechanism provides flexible RI based routing.

For received messages there is also configuration of which RIs will be handled. This is particularly important for "broadcast receive" circuits, to control handling of messages which may be handled by other receivers of the broadcast. An ACP127 Address view is provided in MConsole to give an overall analysis of RI and PLA configuration and routing.

BRASS/BRE1TA

M-Switch may be used in support of NATO BRASS (Broadcast and Ship to Shore) and BRE1TA (BRASS Enhancement 1 Technical Architecture) deployments. This capability includes RECAP Messages, OTAM (Off The Air Monitoring) and other elements important for these deployments. A detailed description is given in the whitepaper [Isode's Solution for BRASS (Broadcast and Ship to Shore)].

SMTP Gateway

M-Switch supports SMTP extensions for military messaging as described in the whitepaper [Military Messaging (MMHS) over SMTP], and in particular RFC 6477 and RFC 7444. These SMTP extensions can be used to ensure all ACP127 service elements are mapped with SMTP. Where appropriate, the rules of STANAG 4406 Annex D are applied to the mappings between ACP127 and SMTP.

STANAG 4406 Gateway

M-Switch can be deployed as a gateway between ACP127 and STANAG 4406 (the NATO standard for organizational messaging). This gateway follows the specifications set out in STANAG 4406 Annex D.

Message Transport

M-Switch supports the three primary approaches used for connecting ACP127 systems:

  1. Serial Line
  2. HF Radio
  3. TCP

ACP127 was initially deisgned for operation over serial lines to communicate with teletypes and operation directly over serial ports is still important for many deployments, including direct operation over HF Radio modems without sue of STANAG 5066 ARQ. M-Switch supports the following serial interfaces:

  • Windows COM Port
  • Digiport TS Server Asynchronous serial hub
  • MoRaSky

MoRaSky is Isode's HF Simulator, which provides serial line over HF Radio simulation, enabling software based testing with serial lines (including simulated data and link loss).

ACP127 is widely deployed over HF Radio using STANAG 5066, particularly in Naval environments. This is done using the Character-Oriented (COSS) protocol defined in Appendix F of STANAG 5066. COSS support is included in the M-Switch ACP127 channel which can be selected by configuring a circuit to use a STANAG 5066 server such as Isode's Icon 5066.

Address Mapping

The preferred approach for address mapping between ACP127 and SMTP and/or STANAG 4406 is to have a directory entry for each user supported at the gateway. The directory entry will include:

  • ACP127 Plain Language Address (PLA).
  • ACP127 Routing Indicator (RI).
  • SMTP address and/or X.400 O/R Address.

Directory search can then be used to identify the entry and map between addresses at the gateway.

This directory entry is essential for any SMTP or X.400 user who communicates with ACP127, as there is no mechanism to encode SMTP and X.400 addressing information in ACP127 and so for messages coming from ACP127 to SMTP or X.400 the destination addresses have to be mapped.

For ACP127 users communicating across the gateway, use of a mapping entry is recommended. This enables ACP127 users to have "clean" addresses for use in SMTP or STANAG 4406 systems. ACP127 addresses may be encoded in SMTP addresses or O/R Addresses. STANAG 4406 Annex D defines how to use domain defined attributes (DDAs) to encode PLA and routing indicator. An example encoded address is:

/c=US/a=DMS/p=DMS+GOV+SIPR/o=MD3/ou=HEFL10/DD.ACP-PLAD=4 FTRASCH VALLEY/

This can be used to generate an encoding following MIXER, so you would see an encoded address of the form:

"/DD.ACP-PLAD=4 FTRASCH VALLEY/"@hefl10.mil

This encoding approach will enable communication with ACP127 users without a configured directory mapping. These directory mapping are configured in the directory using the MConsole management GUI.

Collation of Large Messages

ACP127 messages are small and do not have attachments. A typical M-Switch SCP127 configuration will use authorization to prevent messages with attachments or very large messages being sent over ACP127 (and an appropriate error message sent to the sender).

Some variants of ACP127 (e.g., DOI-103S) have a mechanism for splitting large messages into small messages, which M-Switch supports. M-Switch will also re-assemble such messages so that message splittting is transparent to SMTP and STANAG 4406 users.

In most situations, the will provide a reliable service for sending large messages, and use of service messages to request retransmission (based on channel sequence number) will ensure no message loss. In the event of a message being received with missing fragments and the missing fragments not arriving in response to a service message request, the message will be sent with clearly marked "gaps" at a timeout interval configurable according to message priority. For very high precedence, only minimal time can be waited for collation, so they will typically be sent as fragments without collation.

Security Labels and Access Control

ACP127 provides two security label mechanisms. A few basic labels are in the core ACP127 protocol and extended labels may be used (field F12a). Mapping of these security labels is integrated with M-Switch Security Label handling . This enables security label based access control for inbound ACP127 messages and flexible security label mappings, for example to facilitate integration with ACP145 gateways.

ACP127 Service Messages & Reliability

ACP127 sends messages over a TCP connection or serial line. There is no protocol acknowledgement and there are no end to end delivery reports as in X.400 and SMTP.

ACP127 achieves reliability by sequentially numbering each message sent to a peer, which enables the receiver to detect if any messages are missing. ACP127 can send a special service message to request retransmission of any missing messages. M-Switch will detect missing ACP127 messages and request retransmission. The ACP127 sending channel holds all recently sent messages in a local database in order to facilitate this automatic transmission.

M-Switch also provides a configuration option to use ZIC/ZID service messages at intervals to automatically verify that a link is correctly working in both directions. ACP127 also defines special reliability options for FLASH messages which has special acknowledgement protocol. This can be selected for circuits where this is needed.

Management

Full GUI management for ACP127 is provided in the MConsole management GUI, including configuration of ACP127 peers and gateway mappings. General information on MConsole can be found on seperate pages covering MConsole for configuration management and MConsole for operational management. Specific capabilities relevant to ACP127 deployments of M-Switch include:

  • Error Handling: Operator Correction
  • Error Handling: ACP127 Repair
  • ACP127 Circuit Monitoring & Control

Error Handling: Operator Correction

M-Switch supports a model of operation where selected or all errors are handled by a local operator. This is particularly important in support of "fire and forget" operation where message senders expect any errors to be handled by operators.

Where a message is syntactically valid, but fails a policy check (e.g., message too large; missing SIC; invalid recipient address) it may be handled by M-Switch message correction which is a Web interface that allows easy message correction. Operators can:

  • Correct message recipients.
  • Remove message attachments.
  • Add or remove SICs.
  • Add or modify Security Label.

Error Handling: ACP127 Repair

ACP127 is sometimes used over links where data errors occurs, and this gives rise to a class of error not generally seen with modern messaging protocols. Such errors may lead to inbound ACP127 messages failing to parse. M-Switch has two options for addressing this:

  1. Send the message with parse error as "garble" in an SMTP message to an operator. This will allow the operator to take appropriate action. This is a useful option in systems where such errors are very rare.
  2. Send the message to an operator Message Repair View in MConsole. This will allow a skilled operator to repair a damaged message and then pass back to M-Switch.

ACP127 Circuit Monitoring & Control

Operational monitoring and control of ACP127 circuits is provided by the ACP127 View. Operator control is by circuit, and each managed circuit is given a tab in the view. This approach enables a system with multiple operators to assign management of groups of circuits to individual operators.

Each circuit tab is divided into a number of sub-tabs to provide a variety of functions to the ACP 127 operator. The primary sub-tab shown below provides a circuit monitoring view. This shows the queue of messages to be transmitted with information on each message and expected finish time.

There is also a screen showing inbound and/or outbound traffic on the link. This traffic window may be "popped out" into a separate window. This is to support a mode of operation where operators have many small windows looking at traffic on multiple links.

The monitoring view shows current traffic on the link. There are also sub-tabs to access historical traffic stored in a file for each day. This allows the operator to look at data that is not in the active monitor.

There are also sub-tabs to give easy access to messages sent and received on the circuit, with default display of messages for the current day. This gives easy per-circuit access to messages handled. There are four specialized sub-tabs that may be configured on a per-circuit basis for circuits that receive messages:

  • Display of duplicate messages. This is primarily for broadcast receive circuits where messages may be sent multiple times. This gives the operator control over onward sending of the messages.
  • CODRESS (encrypted) messages. This allows the operator to manually handle CODRESS messages and pass them using files to an offline device.
  • Repair. This is the interface described above for operator repair of damaged ACP 127 messages.
  • Intercept. This is a capability primarily of interest to broadcast receivers. It allows the operator to view inbound messages that are not routed automatically. It allows the operator to intercept messages of local interest that are being sent to other destinations.

Outbound queues have three modes:

  1. Automatic. Here messages are sent automatically by M-Switch.
  2. Manual. Here messages are sent under operator control.
  3. Mixed. Here a circuit can be changed between modes. This is most commonly used for circuits which are usually automatic, but are sometimes taken under manual control.

There is operator control available for automatic circuits, which is particularly important for slow links which have high levels of traffic:

  • Delete message from queue.
  • Hold message. This allows an operator to hold a queued message for a selected time while other messages are processed. The operator may delete a held message or return to automatic processing ("let pass").
  • Process Next. This allows an operator to select the message to be processed next, after the current message has finished.
  • Abort. The message being transferred may be aborted, and then either deleted or returned to the queue. This can be helpful for a large message that is taking a long time to transmit. Note that if a FLASH message arrives, pre-emtion will lead to automatic abort of the message currently being transmitted.

There is also special handling of message that expire while in the queue, controlled by the ZPW OPSIG that specified this time. Such messages may be automatically expired or always transmitted. It is also possible to give operator control of ZPW handling on a per-message basis.

Manual control is needed for older unreliable circuits. In manual mode, the operator is presented with a list of the queued messages in priority order. The operator can choose to send messages as many times as desired and the transmission count is recorded. When the operator has determined that a message has been received (e.g, by phone call, ACP127 service message, or FAB (broadcast), the operator can mark that a message has been received. This allows reliable manual sending of messages.

The operator may also send ACP127 service messages and MConsole provides easy selection of common OPSIGs needed for such messages. This capability is likely to be most useful for operator to operator communication over manual links.

The ACP127 view also allows communication of templated messages over the link. This can be used to easily send standard test messages, which MConsole provides as default templates. MConsole also allows creation of custom templates and the ability to send arbitrary data. This can be useful when initializing ACP126 communication or following RATT procedures.

Conformance

M-Switch ACP127 conforms to the following standards:

  • ACP127 "Communication Instructions – Tape Relay Procedures" (November 1998).
  • ACP126 "Communications Instructions Teletypewriter (Teleprinter) Procedures" (May 1989). An older protocol very similar to ACP127, but used only for point to point communication.
  • ACP128 "Allied Telecommunications Record System (ALTERS) Operating Procedures - ACP128(A)" (May 2005). A newer protocol based on ACP127.
  • DOI 103S (Defense Operating Instructions DSSCS Messages). An intelligence community protocol that has many similarities to ACP127.
  • JANAP 128 "AUTODIN Operating Procedures JANAP 128(I)" (March 1983).
  • STANAG 4406, Edition 2. "Military Message Handling System", March 2005 Annexe D: "MMHS APS/ACP127 Gateway"
  • STANAG 5506 Edition 2. "Profile for High Frequency (HF) Radio Data Communications", December 2008. Annex F.3 "Character-Oriented Serial Stream (COSS) Client"