[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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

   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

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

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]