HF File Transfer Protocol (HFFTP) (S5066-APP8)

This protocol specifies a simple file transfer protocol operating over SIS Layer Extension Protocol (SLEP) Streaming Service, specified in S5066-APP3.   This provides a simple, flexible and highly robust file transfer protocol.  The protocol is loosely modeled in Internet FTP (RFC 959).

This initial version is primarily useful for testing and demonstration.  If there is interest, this can easily be extended to be a general purpose file transfer capability.

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)
Creative Commons License
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Motivation

This protocol was designed as a simple protocol for testing SLEP Streaming Services. It is very useful for this, and can clearly be useful for this purpose when testing SLEP interoperability between different implementations. It seems useful to publish and possibly standardize this protocol, simply for this purpose.

Possible Evolution

The HFFTP protocol provides two advantages over the older BFTP protocol specified in STANAG 5066 Ed3:

  1. It does not rely on “in order” delivery, which provides better performance and resilience.
  2. It will be robust over CAS-1 soft link breaks.
  3. Small files can be pushed in a single HF transmission using SLEP Immediate Connect.  For pulling a small file, there is a small initial transfer and the file data is then transferred in a single second transmission.

It may be that the protocol is useful as is.

A possible enhancement is to allow browsing of the remote file system, in the manner permitted by RFC 959.  This will allow retrieval of arbitrary files and allow remote filenames to be determined. It will also files to be placed in a specified location on the remote file system.

This change would be straightforward.

Although file transfer is of lower priority than it used to be, it may be desirable to have a decent protocol in the STANAG 5066 suite.

HFFTP Model

The model is that an HFFTP receiver will listen on a known SAP. The HFFTP sender (which may also be an HFFTP receiver) will connect on the same SAP. It has two options:

  1. To push a file to the receiver.
  2. To pull a named file from the receiver.

There is optional communication of:

  1. File length, to facilitate monitoring.
  2. File checksum, to validate correct transfer.

HFFTP operates over a SLEP Stream. The following options may be selected:

  1. Priority.
  2. Compression.

HFFTP Protocol

The HFFTP protocol is specified using a simple BNF. Information is encoded using UTF-8, unless specified otherwise. The following terminals are noted:

<CRLF>  - Carriage Return followed by Linefeed
<SP> - Space Character
<EOF>  - End of SLEP Stream
<filename> - The name of the file (sequence of UTF-8 characters). Spaces is the filename must be escaped. “\ ” is interpreted as space and “\\” as single backslash.
<length> - A sequence of digits, specifying the length of file in bytes
<checksum> - CRC-32C checksum of the raw file byte data encoded as  8 hex digits
<data> - The raw file data

Pushing a File

A SLEP Stream is opened and the following sequence is used:

  • Initiator: “HFFTP” <CRLF>
  • Initiator: “PUSH” <SP> <filename> [ <SP> <length> [ <SP> <checksum> ]] <CRLF>  <data> <EOF>
  • Responder: <EOF>

The Initiator always sends a simple greeting. Then the file is sent with a “PUSH” command, with name of file and optional length and checksum.   When all the data is sent, initiator initiates clean close of the stream.   When responder has received all the data, it responds to the close and closes the stream.

All initial data is pushed without handshake making use of SLEP Immediate Connect, to optimize latency.

Pulling a File

A SLEP Stream is opened and the following sequence is used:

  • Initiator: “HFFTP” <CRLF>
  • Initiator: “PULL” <SP>  <filename> <CRLF>
  • Responder: “NONE” <CRLF> <EOF>
    / “DATA”  [<SP>  <length> [ <SP>  <checksum> ]] <CRLF>  <data> <EOF>
  • Initiator: <EOF>

TheInitiator always sends a simple greeting. Then the initiator sends the name of the requested file with a “PULL” command.   The responder  responds either with “NONE” if the file does not exist or “DATA” to send the  file with optional length and checksum.  In both cases the responder will initiate clean close of the stream.   The initiator will close the stream when all data is received.

Recommended SAP ID

Its is recommended to run this protocol over SAP ID 14, which is not assigned in STANAG 5066 Ed4 (draft).