As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group Samuel J.
Request for Comments: 893 Michael J.
University of California at
April 1984
Trailer
Status of this
This RFC discusses the motivation for use of "trailer encapsulations
on local-area networks and describes the implementation of such
encapsulation on various media. This document is for
only. This is NOT an official protocol for the ARPA
community
A trailer encapsulation is a link level packet format employed
4.2BSD UNIX (among others). A trailer encapsulation, or "trailer",
may be generated by a system under certain conditions in an effort
minimize the number and size of memory-to-memory copy
performed by a receiving host when processing a data packet
Trailers are strictly a link level packet format and are not
(when properly implemented) in any higher level protocol processing
This note cites the motivation behind the trailer encapsulation
describes the trailer encapsulation packet formats currently in
on 3 Mb/s Experimental Ethernet, 10 Mb/s Ethernet, and 10 Mb/s V2
ring networks [1].
The use of a trailer encapsulation was suggested by Greg Chesson,
the encapsulation described here was designed by Bill Joy
Trailers are motivated by the overhead which may be incurred
protocol processing when one or more memory to memory copies must
performed. Copying can be required at many levels of processing
from moving data between the network medium and the host's memory,
passing data between the operating system and user address spaces
An optimal network implementation would expect to incur zero
operations between delivery of a data packet into host memory
presentation of the appropriate data to the receiving process.
many packets may not be processed without some copying operations
when the host computer provides suitable memory management support
may often be possible to avoid copying simply by manipulating
appropriate virtual memory hardware
In a page mapped virtual memory environment, two prerequisites
usually required to achieve the goal of zero copy operations
packet processing. Data destined for a receiving agent must
Leffler & Karels [Page 1]
RFC 893 April 1984
aligned on a page boundary and must have a size which is a
of the hardware page size (or filled to a page boundary). The
restriction assumes virtual memory protection is maintained at
page level; different architectures may alter these prerequisites
Data to be transmitted across a network may easily be segmented
the appropriate size, but unless the encapsulating protocol
information is fixed in size, alignment to a page boundary
virtually impossible. Protocol header information may vary in
due to the use of multiple protocols (each with a different header),
or it may vary in size by agreement (for example, when
information is included in the header). To insure page alignment
header information which prefixes data destined for the receiver
be reduced to a fixed size; this is normally the case at the
level of a network. By taking all (possibly) variable length
information and moving it after the data segment a sending host
"do its best" in allowing the receiving host the opportunity
receive data on a page aligned boundary. This rearrangement of
at the link level to force variable length header information
"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
is a link level encapsulation, unless a host to host
is performed (preferably at the link level to avoid
layering principles), only certain hosts will be able to converse
or their communication may be significantly impaired if
packets are mixed with non-trailer packets
2. The cost of receiving data on a page aligned boundary should
comparable to receiving data on a non-page aligned boundary.
the overhead of insuring proper alignment is too high, the
in avoiding copy operations may not be cost effective
3. The size of the variable length header information should
significantly less than that of the data segment
transmitted. It is possible to move trailing information
physically copying it, but often implementation constraints
the characteristics of the underlying network hardware
merely remapping the header(s).
4. The memory to memory copying overhead which is expected to
performed by the receiver must be significant enough to
the added complexity in the both the sending and receiving
software
The first point is well known and the motivation for this note
Leffler & Karels [Page 2]
RFC 893 April 1984
Thought has been given to negotiating the user of trailers on a
host basis using a variant of the Address Resolution Protocol [2]
(actually augmenting the protocol), but at present all systems
trailers require hosts sharing a network medium to uniformly
trailers or never transmit them. (The latter is easily carried
at boot time in 4.2BSD without modifying the operating system
code.)
The second point is (to our knowledge) insignificant. While a
may not be able to take advantage of the alignment and
properties of a trailer packet, it should nonetheless never
it
Regarding the third point, let us assume the trailing
information is copied and not remapped, and consider the
overhead in the TCP/IP protocols as a representative example [3].
we assume both the TCP and IP protocol headers are part of
variable length header information, then the smallest trailer
(generated by a VAX) would have 512 bytes of data and 40+ bytes
header information (plus the trailer header described later).
the trailing header could have IP and/or TCP options included
would normally be rare (one would expect most TCP options,
example, to be included in the initial connection setup exchange)
certainly much smaller than 512 bytes. If the data segment
larger, the ratio decreases and the expected gain due to fewer
on the receiving end increases. Given the relative overheads of
memory to memory copy operation and that of a page map
(including translation buffer invalidation), the advantage
obvious
The fourth issue, we believe, is actually a non-issue. In
implementation the additional code required to support the
encapsulation amounts to about a dozen lines of code in each
level "network interface driver". The resulting
improvement more than warrants this minor investment in software
It should be recognized that modifying the network (and normal link
level format of a packet in the manner described forces the
host to buffer the entire packet before processing.
implementations may parse protocol headers as the packet arrives
find out the actual size (or network level packet type) of
incoming message. This allows these implementations to
preallocating maximum sized buffers to incoming packets which it
recognize as unacceptable. Implementations which parses the
level format on the fly are violating layering principles which
been extolled in design for some time (but often violated
implementation). The problem of postponing link level
Leffler & Karels [Page 3]
RFC 893 April 1984
recognition is a valid criticism. In the case of network
which supports DMA, however, the entire packet is always
before processing begins
Trailer Encapsulation Packet
In this section we describe the link level packet formats used on
3 Mb/s Experimental Ethernet, and 10 Mb/s Ethernet networks as
as the 10 Mb/s V2LNI ring network. The formats used in each
differ only in the format and type field values used in each of
local area network headers
The format of a trailer packet is shown in the following diagram
+----+-------------------------------------------------+----+
| LH | data | TH |
+----+-------------------------------------------------+----+
^ ( ^ ) ^
LH
The fixed-size local network header. For 10 a Mb/s Ethernet
the 16-byte Ethernet header. The type field in the
indicates that both the packet type (trailer) and the length
the data segment
For the 10 Mb/s Ethernet, the types are between 1001 and 1010
hexadecimal (4096 and 4112 decimal). The type is calculated
1000 (hex) plus the number of 512-byte pages of data.
maximum of 16 pages of data may be transmitted in a
trailer packet (8192 bytes).
data
The "data" portion of the packet. This is normally only
to be delivered to the receiving processes (i.e. it contains
TCP or IP header information). Data size is always a
of 512 bytes
TH
The "trailer". This is actually a composition of the
protocol headers and a fixed size trailer prefix which
the type and
of the trailing data. The format of a trailer is shown below
The carats (^) indicate the page boundaries on which the
host would place its input buffer for optimal alignment
Leffler & Karels [Page 4]
RFC 893 April 1984
receiving a trailer packet. The link level receiving routine is
to locate the trailer using the size indicated in the link
header's type field. The receiving routine is expected to
the link level header and trailer prefix, and remap the trailing
segment to the front of the packet to regenerate the original
level packet format
Trailer
+----------------+----------------+------~...~----------+
| TYPE | HEADER LENGTH | ORIGINAL HEADER(S) |
+----------------+----------------+------~...~----------+
Type: 16
The type field encodes the original link level type of
transmitted packet. This is the value which would normally
placed in the link level header if a trailer were not generated
Header length: 16
The header length field of the trailer data segment.
specifies the length in bytes of the following header data
Original headers: <variable length
The header information which logically belongs before the
segment. This is normally the network and transport
protocol headers
A link level encapsulation which promotes alignment
necessary for the efficient use of virtual memory hardware
has been described. This encapsulation format is in use on
systems and is a standard facility in 4.2BSD UNIX. The
provides an efficient mechanism by which cooperating hosts on a
network may obtain significant performance improvements. The use
this encapsulation technique currently requires uniform
from all hosts on a network; hopefully a per host
mechanism may be added to allow consenting hosts to utilize
encapsulation in a non-uniform environment
Leffler & Karels [Page 5]
RFC 893 April 1984
[1] "The Ethernet - A Local Area Network", Version 1.0,
Equipment Corporation, Intel Corporation, Xerox Corporation
September 1980.
[2] Plummer, David C., "An Ethernet Address Resolution Protocol",
RFC-826, Symbolics Cambridge Research Center, November 1982.
[3] Postel, J., "Internet Protocol", RFC-791, USC/
Sciences Institute, September 1981.
Leffler & Karels [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
