rfc935.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 774 行 · 第 1/3 页

Network Working Group                                        J. Robinson
Request for Comments: 935                                            BBN
                                                            January 1985

                     RELIABLE LINK LAYER PROTOCOLS


Status of This Memo

   This RFC discusses protocols proposed recently in RFCs 914 and 916,
   and suggests a proposed protocol that could meet the same needs
   addressed in those memos.  The stated need is reliable communication
   between two programs over a full-duplex, point-to-point communication
   link, and in particular the RFCs address the need for such
   communication over an asynchronous link at relatively low speeds.
   The suggested protocol uses the methods of existing national and
   international data link layer standards.  This RFC suggests a
   proposed protocol for the ARPA-Internet community, and requests
   discussion and suggestions for improvements.  Distribution of this
   memo is unlimited.

Introduction

   This RFC is motivated by recent RFCs 914 and 916, which propose new
   standards for protocols that transfer serial data reliably over
   asynchronous communication lines.  In this note, I summarize
   widely-used standards that have been in existence for some time that
   might be appropriate for this environment.  I hope that the existing
   standards will be found to meet the needs the new proposals seek to
   address.

   In both the US and international standards areas, there are two major
   categories of serial data communication standards for the link layer.
   These categories are character-oriented and bit-oriented.  The first
   is the older class; it is standardized in the US standard ANSI
   X3.28-1976 (which superseded the original version of 1971), and in
   the ISO standards IS 1745, IS 2111, IS 2628 and IS 2629.  Although
   frequently used in synchronous environments, wherein the name binary
   synchronous (or bisynch) is used, these standards use the term "basic
   mode" to describe their procedures.  The latter class is standardized
   in the US standard ADCCP (Advanced Data Communication Control
   Procedures), ANSI X3.66- 1979, and in the ISO standard HDLC
   (High-level Data Link Control procedures), in IS 3309, IS 4335 and IS
   7809.

   Other international standards, draft standards and vendor standards
   follow the ADCCP/HDLC procedures.  Among these are SDLC (IBM), X.25
   LAPB (CCITT), IEEE 802.2/ISO 8802.2 LLC (LAN Logical Link Control)
   and ISDN LAPD (CCITT).  Many vendors have built equipment which meets




Robinson                                                        [Page 1]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   the character-oriented standards, in both synchronous and
   asynchronous environments, including all the major US mainframe
   manufacturers.

   The only other serial link layer protocol known to the author in as
   wide use as these is DEC's DDCMP (Digital Data Communications Message
   Protocol).  This protocol uses a character count instead of framing
   characters, but is in other respects a character-oriented protocol.

   The next sections of this note will compare the three protocols above
   on several bases, paying particular attention to the characteristics
   that make particular aspects of the protocol appropriate to the
   low-speed, asynchronous, serial environment.

Frame Structure

   All serial protocols divide the data to be transmitted into units
   known as frames.  A frame is typically one to several hundred
   characters in length.  The frame structure is the major difference
   used above to divide the protocols into three classes.

Character-Oriented Framing

   Character-oriented protocols use two techniques for defining a frame.
   First, it is necessary to determine where characters start and stop.
   The technique used for this purpose is to transmit a number of unique
   characters prior to the start of a frame.  The character generally
   used for this is the SYN character.

   Note that this is not required when using asynchronous transmission.
   Since each character is itself framed by start and stop bits, there
   is never a question of where characters begin and end.

   The main technique for structuring a frame is the use of special
   framing characters to delineate the start and end of a frame, and to
   delineate portions of the frame (such as header and text).  Some uses
   of character-oriented protocols require that these characters never
   appear in the header or text of the frame, while others allow
   "transparent" transmission.  Transparency is obtained by preceding
   each framing character by a unique control character, typically DLE.
   In this way, all characters may be sent as header or text, except for
   DLE.  In order to allow DLE to be sent in the header or text, the DLE
   is doubled.






Robinson                                                        [Page 2]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


Bit-Oriented Framing

   Bit-oriented protocols also use a unique character (technically, it
   is just an arbitrary bit-string) for frame delineation, which is the
   FLAG.  This character provides frame synchronization.  All bits
   between two occurrences of FLAGs constitute a frame.  The FLAG is a 0
   bit, followed by six 1 bits, followed by another 0 bit.  In order
   that the FLAG character not appear mistakenly in the data of the
   message, the sender inserts (and the receiver removes) an extra 0 bit
   after any five successive 1 bits in the data stream.

   Because this insertion of bits ("stuffing") results in arbitrary
   frame bit-lengths, bit-oriented protocols are generally useful only
   in synchronous transmission environments.  Although it has never been
   attempted, however, one could imagine an asynchronous environment
   where each FLAG character that appears in the data is translated into
   a two- character sequence that avoids FLAGs, and at least one other
   character is similarly translated.  For example, one could frame data
   with FLAGS, and send DLE-F to mean FLAG and DLE-DLE to mean DLE when
   these characters occur within the frame.

   Note that bit-oriented procedures do not require that the number of
   bits between FLAGs be an exact number of 8-bit characters, in
   distinction to character-oriented protocols and DDCMP.  The necessity
   for character-alignment may be imposed at higher layers, as it is,
   for example, in X.25 Network Layer.

Frame Structure in DDCMP

   DDCMP uses a third approach to frame structure.  Like
   character-oriented protocols, it uses a SYN character to achieve
   character synchronization prior to starting a frame, but one cannot
   dispense with this over asynchronous lines (see below).  Contained
   within the fixed-length header portion of the frame is a count field,
   which reports how many characters are contained in the
   variable-length text portion.  Since no framing characters are
   required at all, transparency is not a problem.  However, because the
   count must be received properly for the sender and receiver to stay
   in frame synchronization, the header is protected with a separate
   error control checksum, which is typically two characters long (see
   below). Also, once a header error has been detected, the count field
   must be assumed to be invalid, and so there must be a unique
   character sequence that introduces the next header in order that the
   receiver can regain synchronization with the sender.

   Therefore, the SYN characters preceding a frame are required even on
   asynch lines.


Robinson                                                        [Page 3]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


Error Detection

   Several types of error control may be used, and the various protocols
   above are similar.  Most synchronous uses require a cyclic redundancy
   check sequence be attached to each frame.  This is a 16-bit sequence
   which can be easily generated and checked in hardware using a shift
   register, and can be somewhat more tediously done in software with
   about 5-6 instructions per character sent or received, and a 256 by
   16-bit lookup table.  DDCMP and Bit-oriented protocols all require
   use of such a sequence.  As noted above, DDCMP uses a check sequence
   twice, once for the header and once for the data.

   In some environments, weaker checks are used on character-oriented
   links.  These take two forms.  If the the number of significant bits
   per character is only 7, then the parity bit can be set to achieve
   either odd or even parity.  ANSI standard X3.16-1976 specifies that
   odd parity should be used on synchronous links and even parity on
   asynchronous links.  The second type of check is "longitudinal
   parity", wherein one character is added to the frame so that the
   number of 1 bits in each bit position summed over all the characters
   of the message and the check character is even.  In other words, the
   exclusive-or of all the characters is 0.  Character parity and
   longitudinal parity may be used together.

   Note also that most character-oriented control messages, such as
   those that poll, select, and acknowledge, are sent with only parity
   for error control.

Sequence Control

   All these protocol provide reliable transmission by sequencing the
   frames and providing positive and (in some cases) negative
   acknowledgments.  Senders can ask the receiver for status if a reply
   is late.

   In character-oriented protocols, frames are implicitly numbered
   (typically) and only one may be outstanding at a time.
   Acknowledgments are explicitly numbered.  One variant allows each
   block (frame) to be explicitly numbered as well; in this case up to 7
   may be outstanding.

   In bit-oriented protocols, frames are explicitly numbered and up to 7
   may be outstanding at a time.  Optional control field extension
   allows for up to 127 outstanding.  An alternate procedure that has
   been defined for use both in the ISDN LAPD environment and in IEEE




Robinson                                                        [Page 4]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   802 LAN environments uses, in effect, a one-bit sequence number and
   one outstanding frame.  Also, unsequenced, unacknowledged information
   frames can be used when frames need not be sent reliably.

   In DDCMP, the frames are explicitly numbered and up to 255 may be
   outstanding.

Addressing

   All of these protocols allow for addressing stations on a multipoint
   link separately.  In LAN environments, both a sending and receiving
   address are required, whereas multipoint environments use a single
   address and assume one master station communicating with multiple
   addressed slave stations.  In bit-oriented protocols, the address
   provides extra information in that frames can be categorized as
   commands or responses; in this sense, the address provides another
   control bit per frame.  However, it is possible to operate without
   needing this distinction.

   Addresses are typically one character long; bit-oriented protocols
   allow for extension of this field to arbitrary length.
   Character-oriented protocols use two-character (controller and
   terminal) addresses.