Network Working Group Mike O'Dell
Internet-Draft UUNET Technologies
October 1996
The Simple Record Framing Protocol
<draft-odell-srfp-00.txt>
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]