Coherent File Distribution Protocol
Network Working Group J. Ioannidis
Request for Comments: 1235 G. Maguire, Jr.
Department of Computer Science
The Coherent File Distribution Protocol
Status of this Memo
This memo describes the Coherent File Distribution Protocol (CFDP).
This is an Experimental Protocol for the Internet community.
Discussion and suggestions for improvement are requested. Please
refer to the current edition of the "IAB Official Protocol Standards"
for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
The Coherent File Distribution Protocol (CFDP) has been designed to
speed up one-to-many file transfer operations that exhibit traffic
coherence on media with broadcast capability. Examples of such
coherent file transfers are identical diskless workstations booting
simultaneously, software upgrades being distributed to more than one
machines at a site, a certain "object" (bitmap, graph, plain text,
etc.) that is being discussed in a real-time electronic conference or
class being sent to all participants, and so on.
In all these cases, we have a limited number of servers, usually only
one, and <n> clients (where <n> can be large) that are being sent the
same file. If these files are sent via multiple one-to-one
transfers, the load on both the server and the network is greatly
increased, as the same data are sent <n> times.
We propose a file distribution protocol that takes advantage of the
broadcast nature of the communications medium (e.g., fiber, ethernet,
packet radio) to drastically reduce the time needed for file transfer
and the impact on the file server and the network. While this
protocol was developed to allow the simultaneous booting of diskless
workstations over our experimental packet-radio network, it can be
used in any situation where coherent transfers take place.
CFDP was originally designed as a back-end protocol; a front-end
interface (to convert file names and requests for them to file
handles) is still needed, but a number of existing protocols can be
adapted to use with CFDP. Two such reference applications have been
developed; one is for diskless booting of workstations, a simplified
Ioannidis & Maguire, Jr. [Page 1]
RFC 1235 CFDP June 1991
BOOTP  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
(126.96.36.199) in directory pub/cfdp/. Also, a companion document
("BOOTP extensions to support CFDP") lists the "vendor extensions"
for BOOTP (a-la RFC-1084 ) that apply here.
CFDP is implemented as a protocol on top of UDP , but it can be
implemented on top of any protocol that supports broadcast datagrams.
Moreover, when IP multicast  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-
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 .
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 .
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
Show full document text