Trailer encapsulations
RFC 893

Document Type RFC - Unknown (April 1984; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 893 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                  Samuel J. Leffler
Request for Comments: 893                              Michael J. Karels
                                    University of California at Berkeley
                                                              April 1984

                         Trailer Encapsulations

Status of this Memo

   This RFC discusses the motivation for use of "trailer encapsulations"
   on local-area networks and describes the implementation of such an
   encapsulation on various media.  This document is for information
   only.  This is NOT an official protocol for the ARPA Internet
   community.

Introduction

   A trailer encapsulation is a link level packet format employed by
   4.2BSD UNIX (among others).  A trailer encapsulation, or "trailer",
   may be generated by a system under certain conditions in an effort to
   minimize the number and size of memory-to-memory copy operations
   performed by a receiving host when processing a data packet.
   Trailers are strictly a link level packet format and are not visible
   (when properly implemented) in any higher level protocol processing.
   This note cites the motivation behind the trailer encapsulation and
   describes the trailer encapsulation packet formats currently in use
   on 3 Mb/s Experimental Ethernet, 10 Mb/s Ethernet, and 10 Mb/s V2LNI
   ring networks [1].

   The use of a trailer encapsulation was suggested by Greg Chesson, and
   the encapsulation described here was designed by Bill Joy.

Motivation

   Trailers are motivated by the overhead which may be incurred during
   protocol processing when one or more memory to memory copies must be
   performed.  Copying can be required at many levels of processing,
   from moving data between the network medium and the host's memory, to
   passing data between the operating system and user address spaces.
   An optimal network implementation would expect to incur zero copy
   operations between delivery of a data packet into host memory and
   presentation of the appropriate data to the receiving process.  While
   many packets may not be processed without some copying operations,
   when the host computer provides suitable memory management support it
   may often be possible to avoid copying simply by manipulating the
   appropriate virtual memory hardware.

   In a page mapped virtual memory environment, two prerequisites are
   usually required to achieve the goal of zero copy operations during
   packet processing.  Data destined for a receiving agent must be

Leffler & Karels                                                [Page 1]



RFC 893                                                       April 1984

   aligned on a page boundary and must have a size which is a multiple
   of the hardware page size (or filled to a page boundary).  The latter
   restriction assumes virtual memory protection is maintained at the
   page level; different architectures may alter these prerequisites.

   Data to be transmitted across a network may easily be segmented in
   the appropriate size, but unless the encapsulating protocol header
   information is fixed in size, alignment to a page boundary is
   virtually impossible.  Protocol header information may vary in size
   due to the use of multiple protocols (each with a different header),
   or it may vary in size by agreement (for example, when optional
   information is included in the header).  To insure page alignment the
   header information which prefixes data destined for the receiver must
   be reduced to a fixed size; this is normally the case at the link
   level of a network.  By taking all (possibly) variable length header
   information and moving it after the data segment a sending host may
   "do its best" in allowing the receiving host the opportunity to
   receive data on a page aligned boundary.  This rearrangement of data
   at the link level to force variable length header information to
   "trail" the data is the substance of the trailer encapsulation.

   There are several implicit assumptions in the above argument.

      1. The receiving host must be willing to accept trailers.  As this
      is a link level encapsulation, unless a host to host negotiation
      is performed (preferably at the link level to avoid violating
      layering principles), only certain hosts will be able to converse,
      or their communication may be significantly impaired if trailer
      packets are mixed with non-trailer packets.

      2. The cost of receiving data on a page aligned boundary should be
      comparable to receiving data on a non-page aligned boundary.  If
      the overhead of insuring proper alignment is too high, the savings
      in avoiding copy operations may not be cost effective.

      3. The size of the variable length header information should be
      significantly less than that of the data segment being
      transmitted. It is possible to move trailing information without
Show full document text