home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-odell-srfp-00.txt < prev    next >
Text File  |  1996-10-21  |  10KB  |  279 lines
  1.  
  2.  
  3. Network Working Group                                        Mike O'Dell
  4. Internet-Draft                                        UUNET Technologies
  5.                                                             October 1996
  6.  
  7.                    The Simple Record Framing Protocol
  8.  
  9.                        <draft-odell-srfp-00.txt>
  10.  
  11. 1. Status of this Memo
  12.  
  13.    This document is an Internet-Draft. Internet-Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its areas,
  15.    and its working groups.  Note that other groups may also distribute
  16.    working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six months
  19.    and may be updated, replaced, or obsoleted by other documents at any
  20.    time.  It is inappropriate to use Internet-Drafts as reference
  21.    material or to cite them other than as ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check the
  24.    1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  25.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  26.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  27.    ftp.isi.edu (US West Coast).
  28.  
  29. 2. Abstract
  30.  
  31.    The Simple Record Framing Protocol (SRFP) is designed to provide a
  32.    common, light-weight protocol for sending record-structured data of
  33.    possibly indeterminate size over a reliable (TCP) connection.  It is
  34.    designed to be a "nickel's worth of presentation layer" which can be
  35.    incorporated into a simple library to prevent reinvention of wheels.
  36.  
  37. 3. Introduction
  38.  
  39.    The Simple Record Framing Protocol is intended to fill a void in the
  40.    current Internet architecture - the need for a common, light-weight
  41.    protocol for sending record-structured data on a single reliable
  42.    connection such as that provided by TCP.
  43.  
  44.    To be sure, other schemes for exchanging record-oriented data are
  45.    used presently used in the Internet.  For example, FTP has a record
  46.    mode, SNMP uses ASN.1, NFS uses XDR, and any number of private
  47.    protocols have been invented for applications requiring this service.
  48.  
  49.    The goal of SFRP is to provide a common, interoperable record framing
  50.    protocol which is flexible enough to solve a useful set of common
  51.  
  52.  
  53.  
  54. O'Dell                                                          [Page 1]
  55.  
  56. Internet-Draft       Simple Record Framing Protocol           March 1995
  57.  
  58.  
  59.    problems (but certainly not all of them) while remaining simple and
  60.    light-weight enough that alternatives will be developed only in the
  61.    face of genuine functional need.
  62.  
  63.    As a wise man once said, "It is sometimes more important to know what
  64.    you are not than it is to know what you are." The requirements for
  65.    SRFP bear this in mind.
  66.  
  67. 4. Overview
  68.  
  69.    The job of SRFP is to frame the transfer of records over a reliable
  70.    connection such as that provided by TCP.  It is *not* intended to
  71.    describe those records in any manner other than their length.  It
  72.    especially does not describe the structure of the records, nor does
  73.    it arrange for any kind of representation conversion.  To this end,
  74.    SRFP has no negotiation mechanism. Any agreements about non-default
  75.    sizes or limits needed by the application must be made by the
  76.    application before initiating SRFP on the channel.
  77.  
  78.    When SRFP is running on a channel, the data stream consists of
  79.    segments, each of which is a block of payload data described by a 4-
  80.    byte header.  The SRFP header marks the beginning of a segment and
  81.    carries the size of the payload block in bytes so that the header of
  82.    the next segment may be located.
  83.  
  84.    When the record size is equal to or less-than the maximum operating
  85.    payload block size, a record goes in one segment.  If the record
  86.    exceeds the maximum payload block size, especially if the application
  87.    needs to demark boundaries in streams of indeterminate length, the
  88.    "record" is fragmented into multiple segments for transmission.  Note
  89.    that the fragments need not be of equal or maximal size, and a
  90.    payload block size of zero is explicitly allowed.  Any segment
  91.    carries data for at most one record - records never span segment
  92.    boundaries.
  93.  
  94.    One example of an indeterminate-length stream is a printer jobstream
  95.    being created in real-time.  The size of such a "record" can only be
  96.    known at the end after it has finished.  Another example might be
  97.    interleaving control and file transfers over a single TCP connection.
  98.    The control information is one "record" while the file contents
  99.    following it is another "record".
  100.  
  101.    To handle records fragmented into multiple segments, SRFP provides
  102.    both a segment payload byte count and a separate End-Of-Record (EOR)
  103.    indication.  EOR is set in the last segment of a record and indicates
  104.    that the last payload byte of the block is the last byte of the
  105.    record.  EOR is always set in the last segment of a record, even when
  106.    it is also the first segment.  If the payload length is zero, then
  107.  
  108.  
  109.  
  110. O'Dell                                                          [Page 2]
  111.  
  112. Internet-Draft       Simple Record Framing Protocol           March 1995
  113.  
  114.  
  115.    EOR is effective immediately, ie, it is equivalent to the previous
  116.    block containing the EOR indicator.
  117.  
  118.    SRFP provides a baseline convention for the default maximum segment
  119.    size which all implementations must be prepared to accept.
  120.    Applications are free to use a larger block size if agreed upon
  121.    before starting SRFP, but any such negotiation is the province of the
  122.    application. SRFP does not assist, but it will oblige.
  123.  
  124.    SRFP also carries an End-Of-Session marker which can be used to
  125.    provide a robust "clean close" without dealing with half-closed TCP
  126.    channels.
  127.  
  128. 5. Header Structure
  129.  
  130.    The SRFP segment header consists of 4 bytes. The first two bytes
  131.    contain control information and the second two are an unsigned 16 bit
  132.    number sent in Network Standard Byte Order.
  133.  
  134.    Byte 1:
  135.            1.......        Must be one
  136.            .vvv....        Version - 001b is version 1
  137.            ....rr..        Reserved - Must be zero
  138.            ......S.        End-of-Session marker
  139.            .......R        End-of-Record marker
  140.  
  141.    Byte 2:
  142.            rrrrrrrr        Reserved - must be zero
  143.  
  144.    Byte 3:
  145.            Most significant byte of unsigned Length
  146.  
  147.    Byte 4:
  148.            Least significant byte of unsigned Length
  149.  
  150.  
  151.    Operation of SRFP is simple. Records are sent as one or more segments
  152.    with the unsigned 16-bit Length field in the header indicating the
  153.    length of the segment payload block. The record terminates with the
  154.    segment where the EOR bit is set, with the end coming AFTER the bytes
  155.    indicated by the Length field in the header.
  156.  
  157.    The most common case is a record sent as a single segment. In this
  158.    case EOR and the total record size are indicated in the same segment
  159.    with the complete payload.
  160.  
  161.    The other case is transfer of multi-segment records which consist of
  162.    some number of segments with the last segment showing EOR.  Note that
  163.  
  164.  
  165.  
  166. O'Dell                                                          [Page 3]
  167.  
  168. Internet-Draft       Simple Record Framing Protocol           March 1995
  169.  
  170.  
  171.    a segment payload length of Zero is explicitly allowed, thereby
  172.    providing for transmission of a bare EOR bit with no additional
  173.    record payload in that segment.
  174.  
  175.    There is no essential difference between the treatment of an
  176.    indeterminate-length record and one which is simply larger than the
  177.    maximum payload size of one segment.  In both cases, you just keep
  178.    sending "more segments" until the last one which carries the EOR
  179.    marker.
  180.  
  181. 6. Limitations and Conventions
  182.  
  183.    SRFP contains no mechanism to negotiate the maximum size segments
  184.    which can be used; such mechanisms are deemed application-specific.
  185.    However, to assure a usable baseline of interoperability, all SRFP
  186.    implementations are required to allow segments containing 4096 bytes
  187.    of payload without prior arrangement. This means the segment is
  188.    actually 4100 bytes long including the header. How a maximum-size
  189.    negotiation might be made is out of the scope of this protocol.
  190.  
  191. 7. Applications and Conclusion
  192.  
  193.    SFRP was designed with two broad uses in mind. The first is tunneling
  194.    UDP-based protocols over TCP sessions.  A number of useful protocols
  195.    are specified as running over UDP only but are, alas, equipped with
  196.    reliable transport machinery hopelessly tuned for small LAN
  197.    environments and not the global Internet. Carrying the packets over a
  198.    TCP connection can solve a number of operational problems without
  199.    requiring wholesale replumbing of the protocol.
  200.  
  201.    The other broad usage is to make it easy to host "file transfer" type
  202.    protocols on a single TCP connection by making it possible to
  203.    reliably alternate between "control" and "transfer" modes even when
  204.    the transferring server cannot pre-discover the length of the "file"
  205.    to be transferred.
  206.  
  207.    While SRFP makes no attempt at the general presentation problem,
  208.    adding just a touch of Record-boundary marking and clean session
  209.    close capability in a common protocol can prevent a lot of needless
  210.    reinvention and gratuitous incompatibility.  That is precisely the
  211.    niche of SRFP.
  212.  
  213. 8. Author's Address
  214.  
  215.    Mike O'Dell
  216.    UUNET Technologies, Inc.
  217.    3060 Williams Drive
  218.    Fairfax, VA 22031
  219.  
  220.  
  221.  
  222. O'Dell                                                          [Page 4]
  223.  
  224. Internet-Draft       Simple Record Framing Protocol           March 1995
  225.  
  226.  
  227.    voice: 703-206-5890
  228.    fax:   703-206-5471
  229.    email: mo@uu.net
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. O'Dell                                                          [Page 5]
  279.