Providing STANAG 5066 services over UDP/IP (S5066-APP4)

Black Side IP over HF is provided using a black side STANAG 5066 system. To provide the full service, this protocol needs to be used with two other capabilities to communicate service elements with the black side STANAG 5066 system:

1. Some STANAG 5066 service elements needs to be communicated out of band to the black side STANAG 5066. Approaches to achieve this are specified in [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6).
2. Confirmation and Rejects need to be provided from black side, as well as flow control. An approach to achieve this is specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

It is anticipated that the black side STANAG 5066 system will provide TRANSEC using AES and the mechanism defined in [STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)].

1. Architecture

This specification specifies behavior of a SIS server, as shown in the diagram above. Notes:

1. SIS Clients communicate with the SIS Server using standard STANAG 5066 SIS protocol. Applications using SIS will operate in a standard manner.
2. SIS servers communicate end to end using the protocol specified in this document, either over UDP or direct over IP.
3. It is anticipated that this protocol will be sent through IP Crypto to a black side STANAG 5066 system.
4. Some service requirements (ARQ and Priority) need to be communicated out of band to the HF subsystem. This can be achieved by using [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6).
5. Control information from the HF subsystem is needed to provide the SIS service. An approach to this is specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

2. Extended IP Service

The natural and simplest way to deploy IP Crypto is in an environment where all applications run over IP. This is not viable for HF. Many IP applications, particularly bulk applications and HTTP over TCP will not run efficiently when IP is mapped directly only HF as an IP subnet using STANAG 5066 F.12 IP Client. This is discussed in the Isode whitepaper [Measuring and Analysing STANAG 5066 F.12 IP Client].  

A number of applications built for HF have optimized protocols over STANAG 5066 and it is highly desirable to use these protocols.

As a consequence, IP Crypto needs to be used in a special manner.

The architecture described here provides an extended IP service by:

1. Additional control information from red to black side using the mechanisms set out in [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6); and
2. Additional control information from black to red using a data diode as specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

This extended IP service is contrasted to standard IP in the following table.

Capability	Extended IP Service	Standard IP Service
IPv4/IPv6 Source and Destination Addressing	Yes	Yes
Unreliable (non-ARQ) data	Yes	Yes
Reliable (ARQ) data	Yes	No
Handling black side data loss	Yes	No
Priority	Yes	No
Flow Control	Yes	No

 

3. STANAG 5066 Services Provided

The following STANAG 5066 Services are not provided by this specification:

1. Hard Links. These are not used by any SIS applications.
2. Expedited Data. This is not used by any SIS applications.
3. Management Protocol. STANAG 5066 defines framework protocol, but no use of it.
4. Rank.   There is no variation of handling based on Rank.
5. TTL.  It is not possible for the application to set TTL, so default will always be used.

For Unidata, the “Non-ARQ with Errors” service is not provided.

Omitting these services is not expected to have any practical impact.

Only destination SAP is used. There does not appear to be operational benefit of allowing source SAP to be different.

4. Providing Services and Protocol

This STANAG 5066 SIS services are provided as follows.

4.1 Bind

Bind services are provided locally by the SIS server. The server shall enforce a maximum of one connection per SAP.

The MTU will be determined based on constraints of the underlying system. For older systems, it may need to be reduced to ensure no IP fragmentation. Each PDU will need to be included in a U_PDU of max size likely to be 2048 in the black side STANAG 5066 system. There will be overheads from IP transport and IP crypto. As a consequence the MTU is expected to be set to a value slightly less that 2048 to allow for these overheads.

4.2 Keep Alive

The SIS server shall send Keep Alives at intervals.

4.3 Flow Control

Flow control shall be provided to SIS clients based on information from the HF subsystem, provided by a mechanism following S5066-APP7 or equivalent.

4.3 Unidata

Unidata requests and indications and client confirmation are provided by the UDP protocol specified below.

Node confirmation and rejects shall be provided to SIS clients based on information from the HF subsystem, provided by a mechanism such as the one specified in S5066-APP7.

Unidata priority, “in order”, and ARQ/non-ARQ information is included in the protocol defined below, so that this information can be supplied to the receiving system in S_UNIDATA_INDICATION. This information shall also be communicated to the HF subsystem following S5066-APP6 or equivalent procedure.

Unidata is carried in UDP using the following format.

	MSB 7	6	5	4	3	2	1	LSB 0
0	Version = 0		Not Used			ARQ	Client Confirm	Type=0
1	SAP				Priority
2 3	Confirmation ID (optional)
4 n	U_PDU

The PDU is encoded as follows:

1. Version is set to 0 for this version of the Protocol.
2. The Type field is set to 0 for U_PDU
3. If client confirmation is requested, Client Confirm is set to 1, and the optional Confirmation ID is included in the PDU.
4. If ARQ is requested, the ARQ bit is set to 1.
5. SAP is set to the SAP.
6. Priority is set to the STANAG 5066 requested priority.
7. U_PDU is the U_PDU.

Client Confirm/Reject is provided using the following PDU, when client confirmation is requested and the U_PDU is delivered to the client or when the U_PDU is rejected. Note that rejects are only sent when the sender requests client confirmation.

	MSB 7	6	5	4	3	2	1	LSB 0
0	Version = 0		Not Used	Reason				Type=1
2 3	Confirmation ID

Type value is set to 1 for the Client Confirm/Reject.  Confirmation ID shall be the value taken from the arriving U_PDU.  Reason has values according to the following table:

Reason	Code	Description
Confirm	0	Confirmation of passing Data PDU to SIS Client
Not Bound	1	SIS Client not bound on SAP
Version Error	2	Version of protocol in Data PDU not supported
Protocol Error	3	Protocol Error in data PDU

These PDUs shall be sent over UDP.   The UDP destination port shall be 95066 or another value agreed for the deployment.  IP fragmentation shall not be used.

IPv4 or IPv6 may be used.   Note that no STANAG 5066 addressing is used in protocol.  SIS servers must map provided STANAG 5066 source and destination addresses into equivalent IPv4 or IPv6 addresses. 

The provided Rank of Unidata is ignored.

The provided TTL of Unidata is used to set a timer if Node or Client confirmation is requested.   In the event of the timer expiring and no reject or confirmation for the Unidata being received, the SIS server shall reject the Unidata with reason “TTL expired”.