RFC 1235 (rfc1235) - Page 2 of 12

Coherent File Distribution Protocol

RFC 1235                          CFDP                         June 1991


   BOOTP [3] daemon (which we call sbootpd) and a simple, TFTP-like
   front end (which we call vtftp).  In addition, our CFDP server has
   been extended to provide this front-end interface.  We do not
   consider this front-end part of the CFDP protocol, however, we
   present it in this document to provide a complete example.

   The two clients and the CFDP server are available as reference
   implementations for anonymous ftp from the site CS.COLUMBIA.EDU
   (128.59.16.20) in directory pub/cfdp/.  Also, a companion document
   ("BOOTP extensions to support CFDP") lists the "vendor extensions"
   for BOOTP (a-la RFC-1084 [4]) that apply here.

Overview

   CFDP is implemented as a protocol on top of UDP [5], but it can be
   implemented on top of any protocol that supports broadcast datagrams.
   Moreover, when IP multicast [6] implementations become more
   widespread, it would make more sense to use a multicast address to
   distribute CFDP packets, in order to reduce the overhead of non-
   participating machines.

   A CFDP client that wants to receive a file first contacts a server to
   acquire a "ticket" for the file in question.  This server could be a
   suitably modified BOOTP server, the equivalent of the tftpd daemon,
   etc. The server responds with a 32-bit ticket that will be used in
   the actual file transfers, the block size sent with each packet
   (which we shall call "BLKSZ" from now on), and the size (in bytes) of
   the file being transferred ("FILSZ").  BLKSZ should be a power of
   two.  A good value for BLKSZ is 512. This way the total packet size
   (IPheader+UDPheader+CFDPheader+data=20+8+12+512=552), is kept well
   under the magic number 576, the minimum MTU for IP networks [7].
   Note that this choice of BLKSZ supports transfers of files that are
   up to 32 Mbytes in size.  At this point, the client should allocate
   enough buffer space (in memory, or on disk) so that received packets
   can be placed directly where they belong, in a way similar to the
   NetBLT protocol [8].

   It is assumed that the CFDP server will also be informed about the
   ticket so that it can respond to requests.  This can be done, for
   example, by having the CFDP server and the ticket server keep the
   table of ticket-to-filename mappings in shared memory, or having the
   CFDP server listening on a socket for this information.  To reduce
   overhead, it is recommended that the CFDP server be the same process
   as the front-end (ticket) server.

   After the client has received the ticket for the file, it starts
   listening for (broadcast) packets with the same ticket, that may
   exist due to an in-progress transfer of the same file.  If it cannot



Ioannidis & Maguire, Jr.