The CCSDS File Delivery Protocol (CFDP)

The basic idea of CFDP is to convert files of any size into a stream of packets called packet data units (PDU). CFDP has an unacknowledged and acknowledged mode, with the option to request a transaction closure for the unacknowledged mode. Using the unacknowledged mode with no transaction closure is applicable for simplex communication paths, while the unacknowledged mode with closure is the easiest way to get a confirmation of a successful file transfer, including a CRC check on the remote side to verify file integrity. The acknowledged mode is the most complex mode which includes multiple mechanism to ensure successful packet transaction even for unreliable connections, including lost segment detection. As such, it can be compared to a specialized TCP for file transfers with remote systems.

The core of these high-level components are the cfdppy.handler.dest.DestHandler and the cfdppy.handler.source.SourceHandler component. These model the CFDP destination and CFDP source entity respectively.

CFDP source entity

The cfdppy.handler.source.SourceHandler converts a cfdppy.request.PutRequest into all packet data units (PDUs) which need to be sent to a remote CFDP entity to perform a File Copy operation to a remote entity.

The source entity allows freedom of communication by only generating the packets required to be sent, and leaving the actual transmission of those packets to the user. The packets are returned to the user using the cfdppy.handler.source.SourceHandler.get_next_packet() call. It should be noted that for regular file transfers, each state machine call will map to one generated file data PDU. This allows flow control for the user of the state machine.

The state machine of the source entity will generally perform the following steps, after a valid cfdppy.request.PutRequest to perform a File Copy operation was received:

  1. Generate the Metadata PDU to be sent to a remote CFDP entity. The PDU will be returned as a spacepackets.cfdp.pdu.metadata.MetadataPdu instance.

  2. Generate all File Data PDUs to be sent to a remote CFDP entity, if applicable (file not empty). The PDU(s) will be returned as a spacepackets.cfdp.pdu.file_data.FileDataPdu instance(s).

  3. Generate an EOF PDU be sent to a remote CFDP entity. The PDU will be returned as a spacepackets.cfdp.pdu.eof.EofPdu instance.

If this is an unacknowledged transfer with no transaction closure, the file transfer will be done after these steps. In any other case:

Unacknowledged transfer with requested closure

  1. A Finished PDU will be awaited, for example one generated using spacepackets.cfdp.pdu.finished.FinishedPdu.

Acknowledged transfer

  1. A EOF ACK packet will be awaited, for example one generated using spacepackets.cfdp.pdu.ack.AckPdu.

  2. A Finished PDU will be awaited, for example one generated using spacepackets.cfdp.pdu.finished.FinishedPdu.

  3. A Finished PDU ACK packet will be sent to the remote CFDP entity.

CFDP destination entity

The cfdppy.handler.dest.DestHandler can convert the PDUs sent from a remote source entity ID back to a file. A file copy operation on the receiver side is started with the reception of a Metadata PDU, for example one generated by the spacepackets.cfdp.pdu.metadata.MetadataPdu class. After that, file packet PDUs, for example generated by the spacepackets.cfdp.pdu.file_data.FileDataPdu, can be inserted into the destination handler and will be assembled into a file.

A destination entity might still generate packets which need to be sent back to the source entity of the file transfer. However, it allows freedom of communication like the source entity by leaving the actual transmission of generated packets to the user. The packets are returned to the user using the cfdppy.handler.dest.DestHandler.get_next_packet() call.

The transaction will be finished for the following conditions:

  1. A valid EOF PDU, for example generated by the spacepackets.cfdp.pdu.eof.EofPdu class, has been inserted into the class.

  2. All check timers have elapsed. These check timers allow and out-of-order reception of EOF and file data PDUs, provided that the interval between the EOF PDU and the last file data PDUs is not too large.

  3. All confirmation packets like Finished PDUs or the EOF ACK PDU have been sent back and confirmed by the remote side where applicable.

Current List of unimplemented features

The following features have not been implemented yet. PRs or notifications for demand are welcome!

  • Suspending transfers

  • Inactivity handling

  • Start and end of transmission and reception opportunity handling

  • Keep Alive and Prompt PDU handling