rfc935.txt

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

RFC 935                                                     January 1985
Reliable Link Layer Protocols


   have widespread applicability beyond the TCP/IP environment addressed
   in RFC 914.  The most important gain for this environment is removal
   of the apparent exorbitant overhead that IP and TCP seem to present
   for use over slow links.

Summary

   The link layer protocol I would advocate for asynchronous, dialup
   communication between PCs would use transparent, character-oriented
   framing, a 16-bit CRC error check, and the control procedures of
   LAPB.  The CRC should be either CRC-16 or the CCITT CRC used in X.25,
   with the latter probably being preferred; modern link chips tend to
   support both of these if they support either.

   Evolution of integrated circuits that directly implement all of the
   public standards will dramatically drop the cost and raise the
   reliability of new implementations of standard protocols.  Chip
   manufacturers have little motivation to address standards that are
   not widely used.

   Overhead for the suggested protocol is 8 characters per frame.  Up to
   7 frames may be outstanding at a time in either direction of
   transfer.  Choice of an appropriate maximum frame size is
   application-dependent, and would certainly be influenced by the
   quality of the physical connection; however, I believe that IP
   datagrams are acceptable frames for dialup 1200 baud service.

   Non-standard modifications that would save a little link overhead
   would be to dispense with the one-character address field, and to use
   the RATP count-oriented frame structure.  These are not recommended,
   because they depart from common practice and yield modest
   improvements at best.

Postscript

   Those familiar with the early history of the Telenet Public Data
   Network should recognize that this proposal is essentially the same
   as the original link layer protocol specification for that network,
   circa 1976, except that the control procedures used at that time,
   known as LAP, have now been superseded by the more powerful and
   efficient LAPB, and their access links, as all X.25 access links, are
   synchronous rather than asynchronous.  I did not set out to achieve
   this result, but just note it in passing.

   My personal view of where the world of personal computer access to
   data networks is heading is that X.25 will rapidly become the
   protocol of choice.  One already sees third-party (for IBM PC) and


Robinson                                                       [Page 10]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   vendor (for Wang PC) implementations of X.25. CCITT is circulating a
   proposal for accessing an X.25 data network using a dial-up X.25
   connection, as recommendation X.32.  Thus, I feel that the type of
   communication proposed in this RFC and RFCs 914 and 916 will be used
   for a relatively short period of time.  The future holds, I believe,
   LAN or X.25/X.32 data link layer and access, X.25 and/or ISO IP
   network layer, and TCP and/or ISO TP4 transport layer.

References

   RFC 914, "Thinwire Protocol", Farber, Delp and Conte, 1984.

   RFC 916, "Reliable Asynchronous Transfer Protocol", Finn, 1984.

   "Technical Aspects of Data Communication", McNamara, Digital Press,
   1977.

   ANSI X3.4-1968, "American National Standard Code for Information
   Interchange (ASCII)", American National Standards Institute, Inc.,
   1968.

   ANSI X3.16-1976, "American National Standard Character Structure and
   Character Parity Sense for Serial-by-Bit Data Communication in the
   American National Standard Code for Information Interchange",
   American National Standards Institute, Inc., 1976.

   ANSI X3.28-1976, "American National Standard Procedures for the Use
   of the Communication Control Characters of American National Standard
   Code for Information Interchange in Specified Data Communication
   Links", American National Standards Institute, Inc., 1976.

   ANSI X3.66-1979, "American National Standard for Advanced Data
   Communication Procedures (ADCCP)", American National Standards
   Institute, Inc., 1979.

   International Standard 1745, "Information Processing - Basic mode
   control procedures for data communication systems", International
   Organization for Standardization (ISO), 1975.

   International Standard 2111, "Data Communication - Basic mode control
   procedures - Code independent information transfer", ISO, 1973.

   International Standard 2628, "Basic mode control procedures -
   Complements", ISO, 1973.

   International Standard 2629, "Basic mode control procedures -
   Conversational information message transfer", ISO, 1973.


Robinson                                                       [Page 11]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   International Standard 3309, "Data Communication - High-level data
   link control procedures - Frame structure", ISO, 1982.

   International Standard 4335, "Data Communication - High-level data
   link control procedures - Consolidation of elements of procedures",
   ISO, 1982.

   International Standard 7809, "Data Communication - High-level data
   link control procedures - Consolidation of classes of procedures",
   ISO, 1984.

   Recommendation X.25, "Interface between Data Terminal Equipment (DTE)
   and Data Circuit Terminating Equipment (DCE) for Terminals Operating
   in the Packet Mode and Connected to Public Data Networks by Dedicated
   Circuit", The International Telegraph and Telephone Consultative
   Committee (CCITT), 1980 (to be revised, 1984).

   Recommendation Q.920, "ISDN User-network Interface Data Link Layer -
   General Aspects", CCITT, 1984 (draft E).

   Recommendation Q.921, "ISDN User-network Interface Data Link Layer
   Specification", CCITT, 1984 (draft E).

   Draft International Standard 8802.2, "Local Area Network Standards,
   Logical Link Control", ISO, 1984 (draft).

   Draft Proposed Addendum to DIS 8802.2, "Single Frame Service", IEEE,
   1984 (Eighth Draft).





















Robinson                                                       [Page 12]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


Appendix A - Bit-Oriented Control Field Contents

   There are three control field formats.  The primary one is used for
   data frames (called "information frames" in the standards), and is
   coded as follows:

      8  7  6  5  4  3  2  1  <- bit number,  1 sent first
                           0     (signifies data frame)
                  S  S  S        send seq , bit 2 low-order
              P/F                poll/final bit, for recovery
      R  R  R                    receive seq  (ACK)

   Acknowledgments are cumulative.  Recovery is typically to back up and
   continue from the lost frame.  Use of the poll/final bit is beyond
   the scope of this note.

   Acknowledgments may also be sent in supervisory frames, coded as
   follows:

      8  7  6  5  4  3  2  1  <- bit number,  1 sent first
                        0  1     (signifies supervisory frame)
                  T  T           frame type (see below)
              P/F                poll/final bit, for recovery
      R  R  R                    receive seq  (ACK)

   Up to four frame types are possible; only two are required.  The
   first is called RR, for "receive ready", and indicates acknowledgment
   and that the receiver is prepared to process more frames.  The other,
   RNR for "receive not ready", is used for flow control of the sender.
   If flow control is not necessary, I suppose even this frame could be
   dispensed with.

   The other supervisory frames, "reject" and "selective reject", are
   varieties of negative acknowledgement that ask for retransmission of
   all and one (respectively) of previously transmitted frames.
   Positive acknowledgment and retransmission are the only really
   necessary procedures, however.

   The third frame format is called Unnumbered.  Many possible functions
   are specified in the various standards for these frames, including
   initializing the link, reset sequence numbers, etc.  The basic format
   is:

      8  7  6  5  4  3  2  1  <- bit number,  1 sent first
                        1  1     (signifies unnumbered frame)
            T  T  T     T  T           frame type
                    P/F                poll/final bit, for recovery


Robinson                                                       [Page 13]