Coherent File Distribution Protocol
RFC 1235

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                       J. Ioannidis
Request for Comments:  1235                              G. Maguire, Jr.
                                                     Columbia University
                                          Department of Computer Science
                                                               June 1991

                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.

Introduction

   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 [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