Network Working Group Mike O'Dell Internet-Draft UUNET Technologies October 1996 The Simple Record Framing Protocol 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract The Simple Record Framing Protocol (SRFP) is designed to provide a common, light-weight protocol for sending record-structured data of possibly indeterminate size over a reliable (TCP) connection. It is designed to be a "nickel's worth of presentation layer" which can be incorporated into a simple library to prevent reinvention of wheels. 3. Introduction The Simple Record Framing Protocol is intended to fill a void in the current Internet architecture - the need for a common, light-weight protocol for sending record-structured data on a single reliable connection such as that provided by TCP. To be sure, other schemes for exchanging record-oriented data are used presently used in the Internet. For example, FTP has a record mode, SNMP uses ASN.1, NFS uses XDR, and any number of private protocols have been invented for applications requiring this service. The goal of SFRP is to provide a common, interoperable record framing protocol which is flexible enough to solve a useful set of common O'Dell [Page 1] Internet-Draft Simple Record Framing Protocol March 1995 problems (but certainly not all of them) while remaining simple and light-weight enough that alternatives will be developed only in the face of genuine functional need. As a wise man once said, "It is sometimes more important to know what you are not than it is to know what you are." The requirements for SRFP bear this in mind. 4. Overview The job of SRFP is to frame the transfer of records over a reliable connection such as that provided by TCP. It is *not* intended to describe those records in any manner other than their length. It especially does not describe the structure of the records, nor does it arrange for any kind of representation conversion. To this end, SRFP has no negotiation mechanism. Any agreements about non-default sizes or limits needed by the application must be made by the application before initiating SRFP on the channel. When SRFP is running on a channel, the data stream consists of segments, each of which is a block of payload data described by a 4- byte header. The SRFP header marks the beginning of a segment and carries the size of the payload block in bytes so that the header of the next segment may be located. When the record size is equal to or less-than the maximum operating payload block size, a record goes in one segment. If the record exceeds the maximum payload block size, especially if the application needs to demark boundaries in streams of indeterminate length, the "record" is fragmented into multiple segments for transmission. Note that the fragments need not be of equal or maximal size, and a payload block size of zero is explicitly allowed. Any segment carries data for at most one record - records never span segment boundaries. One example of an indeterminate-length stream is a printer jobstream being created in real-time. The size of such a "record" can only be known at the end after it has finished. Another example might be interleaving control and file transfers over a single TCP connection. The control information is one "record" while the file contents following it is another "record". To handle records fragmented into multiple segments, SRFP provides both a segment payload byte count and a separate End-Of-Record (EOR) indication. EOR is set in the last segment of a record and indicates that the last payload byte of the block is the last byte of the record. EOR is always set in the last segment of a record, even when it is also the first segment. If the payload length is zero, then O'Dell [Page 2] Internet-Draft Simple Record Framing Protocol March 1995 EOR is effective immediately, ie, it is equivalent to the previous block containing the EOR indicator. SRFP provides a baseline convention for the default maximum segment size which all implementations must be prepared to accept. Applications are free to use a larger block size if agreed upon before starting SRFP, but any such negotiation is the province of the application. SRFP does not assist, but it will oblige. SRFP also carries an End-Of-Session marker which can be used to provide a robust "clean close" without dealing with half-closed TCP channels. 5. Header Structure The SRFP segment header consists of 4 bytes. The first two bytes contain control information and the second two are an unsigned 16 bit number sent in Network Standard Byte Order. Byte 1: 1....... Must be one .vvv.... Version - 001b is version 1 ....rr.. Reserved - Must be zero ......S. End-of-Session marker .......R End-of-Record marker Byte 2: rrrrrrrr Reserved - must be zero Byte 3: Most significant byte of unsigned Length Byte 4: Least significant byte of unsigned Length Operation of SRFP is simple. Records are sent as one or more segments with the unsigned 16-bit Length field in the header indicating the length of the segment payload block. The record terminates with the segment where the EOR bit is set, with the end coming AFTER the bytes indicated by the Length field in the header. The most common case is a record sent as a single segment. In this case EOR and the total record size are indicated in the same segment with the complete payload. The other case is transfer of multi-segment records which consist of some number of segments with the last segment showing EOR. Note that O'Dell [Page 3] Internet-Draft Simple Record Framing Protocol March 1995 a segment payload length of Zero is explicitly allowed, thereby providing for transmission of a bare EOR bit with no additional record payload in that segment. There is no essential difference between the treatment of an indeterminate-length record and one which is simply larger than the maximum payload size of one segment. In both cases, you just keep sending "more segments" until the last one which carries the EOR marker. 6. Limitations and Conventions SRFP contains no mechanism to negotiate the maximum size segments which can be used; such mechanisms are deemed application-specific. However, to assure a usable baseline of interoperability, all SRFP implementations are required to allow segments containing 4096 bytes of payload without prior arrangement. This means the segment is actually 4100 bytes long including the header. How a maximum-size negotiation might be made is out of the scope of this protocol. 7. Applications and Conclusion SFRP was designed with two broad uses in mind. The first is tunneling UDP-based protocols over TCP sessions. A number of useful protocols are specified as running over UDP only but are, alas, equipped with reliable transport machinery hopelessly tuned for small LAN environments and not the global Internet. Carrying the packets over a TCP connection can solve a number of operational problems without requiring wholesale replumbing of the protocol. The other broad usage is to make it easy to host "file transfer" type protocols on a single TCP connection by making it possible to reliably alternate between "control" and "transfer" modes even when the transferring server cannot pre-discover the length of the "file" to be transferred. While SRFP makes no attempt at the general presentation problem, adding just a touch of Record-boundary marking and clean session close capability in a common protocol can prevent a lot of needless reinvention and gratuitous incompatibility. That is precisely the niche of SRFP. 8. Author's Address Mike O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031 O'Dell [Page 4] Internet-Draft Simple Record Framing Protocol March 1995 voice: 703-206-5890 fax: 703-206-5471 email: mo@uu.net O'Dell [Page 5]