This protocol defines a protocol operating over STANAG 5066 SIS to provide three services to facilitate operation and analysis of STANAG 5066 networks:

  1. To enable STANAG 5066 nodes to discover each other.
  2. To provide a “ping” service to measure availability and latency.
  3. A Traffic Load capability to help measure network performance.

This document is part of the STANAG 5066 Application Protocol (S5066-APP) series. The complete set of documents in the series are:

  1. STANAG 5066 Application Protocol Index (S5066-APP1)
  2. HF Discovery, Ping and Traffic Load (S5066-APP2)
  3. SIS Layer Extension Protocol (SLEP) (S5066-APP3)
  4. Providing STANAG 5066 services over UDP/IP (S5066-APP4)
  5. Implicit IP Client over STANAG 5066 (S5066-APP5)
  6. Providing Control Parameters for STANAG 5066 over UDP/IP through IP Crypto (S5066-APP6)
  7. XML Control Messages for STANAG 5066 over UDP/IP through a Data Diode (S5066-APP7)
  8. HF File Transfer Protocol (HFFTP) (S5066-APP8)
  9. HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9)

1. Node Discovery

A STANAG 5066 client connects to a node needs to address data to other STANAG 5066 nodes using the STANAG 5066 Address of that node.

Sometimes the client will know the address of the remote node or it will be explicitly configured. However, this is not always ideal:

  • There may be administrative overhead in working out and/or configuring the remote address.
  • The remote addresses may not be known
  • Nodes on the network vary with time.

This specification provides a simple way to find other nodes on the network. It works with a simple message format that gives a descriptive name of the node making the transmission that is broadcast to all nodes. Nodes receiving this message broadcast a response of same format. This simple protocol can be used in a number of ways, including:

  • On node initialization, to find other active nodes.
  • At intervals to discover new nodes on the network.

2. Ping & Traffic Load

It is often helpful to test and measure HF Networks using a STANAG 5066 link layer. Some analysis can be achieved by monitoring applications running over STANAG 5066. However, it is convenient to use a special protocol where specific analysis or testing is needed. This protocol offers two capabilities:

  1. A “ping” capability, analogous to ICMP Ping (RFC 792) which is used to determine if a peer is reachable and record delay information.
  2. A “traffic load” capability, which can send test data to apply load to a network so that throughput and latency can be measured.

The protocol is designed so that a human operator can sit at one end of the link only, with remote systems mechanically following the protocol defined here, and returning information to the operator.

3. Protocol Specification

This protocol operates on a mutually agreed SAP for the network. In lieu of a formal assignment, it is recommended to use SAP 15 (currently unassigned).

Messages are sent using the S_UNIDATA_REQUEST service with the message data in the U_PDU element. Each of the message formats uses by this specification starts with a one-byte integer encoded type. The type identifies the format to be used.

3.1. Discovery & Ping

Discovery and Ping use a common encoding is specified below.

  MSB
7
6 5 4 3 2 1 LSB
0
0
Type
1
2
MessageID
3
8
Date - Time
9
n
Description

The Type field encodes an Integer in a single byte. The value is interpreted as in the following table

Type Encoding Description
Discovery Request 0 Discover Request, indicating that all nodes receiving this are requested to send a response
Discovery Response 1 This is a response to a Discovery Request. No action needed by receiver.
Discovery Information 2 This is sent to provide other nodes information on the node sending the message. No action needed by receiver.
Ping Request 3 A Ping Request.
Ping Response 4 A Ping Response to a received Ping Request.

Message ID is a two-byte integer, identifying a message. Senders of Discovery Request, Discovery information, and Ping Request should choose a new value, incremented from the value previously used. For Discovery Response and Ping Response, the Message ID should match that of the of the message being responded to.

Date-Time is a six-byte unsigned integer, representing time in milliseconds since January 1st 1970. This is set to the time that the message is sent.

The optional Description is encoded as a sequence of IA5 characters, with one character per byte. This value describes the node sending the message. It shall be included for Discovery Request, Discovery Response and Discovery Information. It shall not be included in Ping Request and Ping Response.

3.1.1 Discovery

Discovery messages are sent to the default broadcast address (31.255.255.255) in non-ARQ mode. It is recommended that “minimum transmission count” is set to at least 3, to reduce risk of transmission corruption or loss.

3.1.2 Ping

A ping request may be sent ARQ or non-ARQ. A non-ARQ ping may be sent to a single node address or to a broadcast address. For non-ARQ, minimum retransmissions shall be set to 0. It will generally be sensible to send multiple messages over non-ARQ. This should be done by sending multiple messages each with a unique ID, which enables responses to be correlated with the specific message.

Responses shall be sent unicast to the sender and shall use the same ARQ/non-ARQ choice as the request.

The date-time values enable a sender to calculate transmission time in both directions.

3.2 Traffic Load

The Traffic load capability uses the following format

  MSB
7
6 5 4 3 2 1 LSB
0
0
Type = 5
1
2
SequenceID
3
8
Date - Time
9
12
Messages to be sent
13
16
Message number
17
n
Data

The fields used are as follows:

  • Type=5
  • Sequence ID is unique ID for a sequence of messages. This will be incremented from the previous ID used.
  • Date-Time is same as for Ping messages.
  • “Messages to be Sent” is a four-byte integer representing the total number of messages for the ID. If this is set to zero, the number of messages is not known.
  • “Message Number” is a four-byte integer identifying the number of the current message in the sequence.
  • “Data” is random data of arbitrary length, up to maximum UPDU data size.

Traffic Load Data may be sent ARQ or non-ARQ. Non-ARQ Traffic Load may be sent to a single node address or to a broadcast address. For non-ARQ, minimum retransmissions may be set to 0 or to a higher number.

A data report PDU is sent back by receivers of Traffic Load Data to report performance to the sender. The following format is used.

  MSB
7
6 5 4 3 2 1 LSB
0
0
Type = 6
1
2
SequenceID
3
8
Date - Time
9
12
Last received
13
Percentage Missing
14
15
Average Delay

Fields as follows:

  • Type is set to 6.
  • Sequence ID identifies the sequence of messages being reported on.
  • Date-Time is when the packet is sent.
  • Last Received is the latest message in the stream received.
  • Percentage missing is a one-byte integer, encoding the percentage of messages not received. This is calculated based on the number of messages received, as a percentage of the number of messages up to the Last Received Message Number
  • Average Delay is a two-byte integer, encoding in milliseconds the mean delay of messages received in the sequence.

This message shall be sent ARQ or non-ARQ to match Traffic Data. For non-ARQ, it is recommended that minimum retransmission is set to 3. A receiver should transmit considering that data levels should be kept low so that they do not impact measurements and that the sender could be interested in reasonably frequent updates.