HF Multicast

STANAG 5066 provides a non-ARQ service which provides unreliable data transfer that can be used with STANAG 5066 multicast and broadcast addresses. STANAG 5066 networks define a default broadcast address and allow configuration of custom multicast addresses. For most scenarios, it is sensible to use the broadcast address, as there is no possibility of sharing the channel. Basic use of broadcast/multicast is inherently unreliable. The STANAG 5066 non-ARQ allows the requester to specify the number of retransmissions, which gives a mechanism to increase reliability.

ACP 142 is a generic, reliable multicast protocol. STANAG 5066 Annex Q specifies the operation of ACP 142 over STANAG 5066, in particular to support SMTP email and STANAG 4406 military messaging. This is an example of sophisticated use of STANAG 5066 multicast.

HF Operator Chat, specified in STANAG 5066 Annex O, provides a simple chat service operating directly over STANAG 5066, which includes the option to broadcast a message to all nodes on an HF network and utilise multicast. It is a good example of simple, direct use of HF broadcast and multicast.

IP Multicast

Although multicast can be achieved directly over STANAG 5066, this is not a particularly convenient approach for many applications. A more useful approach is to provide an interface to IP using the user Unreliable Datagram Protocol (UDP), which gives a simple interface to applications that can use it to provide a multicast capability.

There are two ways that multicast is used in IP networks.

True IP Multicast

IP addresses are allocated to support multicast. In order to configure a group of nodes to use multicast over a full internet, Internet Group Management Protocol (IGMP) is used by hosts and routers to set up and manage the multicast group.

Although there are many possibilities to use multicast and IGMP, practical deployment is mostly restricted to media broadcast, where one node broadcasts data and other nodes can join the multicast in order to receive the data.

Subnet Multicast

Some applications use multicast on a single IP subnet, which can work without IGMP support. An application can simply listen on the correct multicast address and UDP port, enabling simple sharing of data between a set of such applications on the LAN.

This approach is of use on LANs to locate services, such as printers.

Difficulties of mapping IP Multicast to HF

STANAG 5066 Annex U (“IP Client”) specifies how to map IP onto STANAG 5066. This works cleanly for unicast operation. The annex notes use of multicast but does not address the issues noted in this paper.

Simple use of Subnet Multicast is impractical. When configuring IP over STANAG 5066, it generally makes sense to give each node an IP subnet. Then, simple static routing can be used to route IP traffic over HF. This approach is set out in Annex U and implemented in Isode’s Icon-PEP product. This does not work for multicast addresses, which are not allocated by subnet.

Use of IGRP over HF would lead to performance issues. A discussion of IP routing is set out in the Isode white paper “IP Routing Over HF”. This white paper notes the problems of running standard routing protocols over HF and introduces the HF-RIP protocol for IP routing over HF subnets. It is anticipated that HF-RIP will be standardised in STANAG 5066 Ed5 Annex AB.

Isode Approach and Icon-PEP Support

The basic model proposed, which Isode has implemented in its Icon-PEP product, is to support specific IP Multicast addresses agreed by all connected subnets. Each node will have a routing configuration set for each supported multicast address. This approach enables multicast addresses to be correctly routed over IP without the need for the use of IGRP.

There are two distinct models supported.

Reliable Connection of Two Multicast Networks

The first approach is shown above, where two networks with multicast applications using a single multicast address are connected. IP is transferred reliably using ARQ. The configured multicast address is mapped with the STANAG 5066 address of the peer.

This approach leads to robust interconnection of two multicast application sets over HF.

Non-ARQ Connection of Multiple Multicast Networks

IP

In the second scenario, multiple IP networks are connected over HF using non-ARQ transfer. This gives a natural multicast architecture. This uses Non-ARQ transfer of IP and can support an arbitrary number of nodes. The multicast IP address is mapped with the broadcast STANAG 5066 address.

There is potential for traffic loss over HF. It is recommended to address reliability by resilience approaches at the application level. There are two distinct deployment scenarios.

The first is true multicast, with all clients able to transmit. This will be connected using STANAG 5066 MAC layer with CSMA (STANAG 5066 Annex K) or Wireless Token Ring Protocol (WTRP). The MAC layer will allow each node to transmit as needed.

The second is broadcast, where one node operates as a broadcast sender and all other nodes as broadcast receivers. This supports a model where messages are broadcast without a break to any listening nodes.

Demonstration Scenario: Serverless TAK

TAK is a C2 system; a summary of TAK and its use over HF Radio is described in the Isode white paper “Operating TAK over HF Radio”. TAK can be deployed with clients and servers, which is a focus of the paper. TAK can also be deployed without a server, using UDP and IP Multicast to share messages between clients. The following diagram shows support of this over HF.

TAK Clients have a defined multicast address. This means that TAK clients on a single IP Subnet will see all traffic sent by other clients. The diagram shows how an HF Network providing a STANAG 5066 interface can use two or more Icon-PEP servers to share multicast IP traffic between multiple subnets. The effect is that all TAK clients connected will see all messages.

Conclusion

This white paper has shown how multicast can be supported over HF Radio and the implementation in Isode’s Icon-PEP product.