rfc1331.txt

RFC 的详细文档！

2.  Physical Layer Requirements

   The Point-to-Point Protocol is capable of operating across any
   DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
   CCITT V.35).  The only absolute requirement imposed by PPP is the
   provision of a full-duplex circuit, either dedicated or circuit-
   switched, which can operate in either an asynchronous (start/stop) or
   synchronous bit-serial mode, transparent to PPP Data Link Layer
   frames.  PPP does not impose any restrictions regarding transmission
   rate, other than those imposed by the particular DTE/DCE interface in
   use.

   PPP does not require any particular synchronous encoding, such as FM,
   NRZ, or NRZI.

   Implementation Note:

      NRZ is currently most widely available, and on that basis is
      recommended as a default.  When configuration of the encoding is
      allowed, NRZI is recommended as an alternative, because of its
      relative immunity to signal inversion configuration errors.

   PPP does not require the use of modem control signals, such as
   Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
   (DCD), and Data Terminal Ready (DTR).

   Implementation Note:

      When available, using such signals can allow greater functionality
      and performance.  In particular, such signals SHOULD be used to
      signal the Up and Down events in the Option Negotiation Automaton
      (described below).



















Simpson                                                         [Page 4]

RFC 1331                Point-to-Point Protocol                 May 1992


3.  The Data Link Layer

   The Point-to-Point Protocol uses the principles, terminology, and
   frame structure of the International Organization For
   Standardization's (ISO) High-level Data Link Control (HDLC)
   procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
   "Addendum 1: Start/stop transmission" [5].  ISO 3309-1979 specifies
   the HDLC frame structure for use in synchronous environments.  ISO
   3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
   allow its use in asynchronous environments.

   The PPP control procedures use the definitions and Control field
   encodings standardized in ISO 4335-1979 [3] and ISO 4335-
   1979/Addendum 1-1979 [4].  The PPP frame structure is also consistent
   with CCITT Recommendation X.25 LAPB [6], since that too is based on
   HDLC.

   The purpose of this memo is not to document what is already
   standardized in ISO 3309.  We assume that the reader is already
   familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
   this paper attempts to give a concise summary and point out specific
   options and features used by PPP.  Since "Addendum 1: Start/stop
   transmission", is not yet standardized and widely available, it is
   summarized in Appendix A.

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (i.e., network bit order).
   Keep this in mind when comparing this document with the international
   standards documents.


















Simpson                                                         [Page 5]

RFC 1331                Point-to-Point Protocol                 May 1992


3.1.  Frame Format

   A summary of the standard PPP frame structure is shown below.  This
   figure does not include start/stop bits (for asynchronous links), nor
   any bits or octets inserted for transparency.  The fields are
   transmitted from left to right.

           +----------+----------+----------+----------+------------
           |   Flag   | Address  | Control  | Protocol | Information
           | 01111110 | 11111111 | 00000011 | 16 bits  |      *
           +----------+----------+----------+----------+------------
                   ---+----------+----------+-----------------
                      |   FCS    |   Flag   | Inter-frame Fill
                      | 16 bits  | 01111110 | or next Address
                   ---+----------+----------+-----------------

   Inter-frame Time Fill

   For asynchronous links, inter-frame time fill SHOULD be accomplished
   in the same manner as inter-octet time fill, by transmitting
   continuous "1" bits (mark-hold state).

   For synchronous links, the Flag Sequence SHOULD be transmitted during
   inter-frame time fill.  There is no provision for inter-octet time
   fill.

   Implementation Note:

      Mark idle (continuous ones) SHOULD NOT be used for idle
      synchronous inter-frame time fill.  However, certain types of
      circuit-switched links require the use of mark idle, particularly
      those that calculate accounting based on bit activity.  When mark
      idle is used on a synchronous link, the implementation MUST ensure
      at least 15 consecutive "1" bits between Flags, and that the Flag
      Sequence is generated at the beginning and end of a frame.

Flag Sequence

   The Flag Sequence is a single octet and indicates the beginning or
   end of a frame.  The Flag Sequence consists of the binary sequence
   01111110 (hexadecimal 0x7e).

   The Flag is a frame separator.  Only one Flag is required between two
   frames.  Two consecutive Flags constitute an empty frame, which is
   ignored.






Simpson                                                         [Page 6]

RFC 1331                Point-to-Point Protocol                 May 1992


   Implementation Note:

      The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
      be used.  When not avoidable, such an implementation MUST ensure
      that the first Flag Sequence detected (the end of the frame) is
      promptly communicated to the link layer.

Address Field

   The Address field is a single octet and contains the binary sequence
   11111111 (hexadecimal 0xff), the All-Stations address.  PPP does not
   assign individual station addresses.  The All-Stations address MUST
   always be recognized and received.  The use of other address lengths
   and values may be defined at a later time, or by prior agreement.
   Frames with unrecognized Addresses SHOULD be silently discarded, and
   reported through the normal network management facility.

Control Field

   The Control field is a single octet and contains the binary sequence
   00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command
   with the P/F bit set to zero.  Frames with other Control field values
   SHOULD be silently discarded.

Protocol Field

   The Protocol field is two octets and its value identifies the
   protocol encapsulated in the Information field of the frame.

   This Protocol field is defined by PPP and is not a field defined by
   HDLC.  However, the Protocol field is consistent with the ISO 3309
   extension mechanism for Address fields.  All Protocols MUST be odd;
   the least significant bit of the least significant octet MUST equal
   "1".  Also, all Protocols MUST be assigned such that the least
   significant bit of the most significant octet equals "0".  Frames
   received which don't comply with these rules MUST be considered as
   having an unrecognized Protocol, and handled as specified by the LCP.
   The Protocol field is transmitted and received most significant octet
   first.

   Protocol field values in the "0---" to "3---" range identify the
   network-layer protocol of specific datagrams, and values in the "8--
   -" to "b---" range identify datagrams belonging to the associated
   Network Control Protocols (NCPs), if any.

   Protocol field values in the "4---" to "7---" range are used for
   protocols with low volume traffic which have no associated NCP.
   Protocol field values in the "c---" to "f---" range identify



Simpson                                                         [Page 7]

RFC 1331                Point-to-Point Protocol                 May 1992


   datagrams as link-layer Control Protocols (such as LCP).

   The most up-to-date values of the Protocol field are specified in the
   most recent "Assigned Numbers" RFC [11].  Current values are assigned
   as follows:

      Value (in hex)  Protocol Name

      0001 to 001f    reserved (transparency inefficient)
      0021            Internet Protocol
      0023            OSI Network Layer
      0025            Xerox NS IDP
      0027            DECnet Phase IV
      0029            Appletalk
      002b            Novell IPX
      002d            Van Jacobson Compressed TCP/IP
      002f            Van Jacobson Uncompressed TCP/IP
      0031            Bridging PDU
      0033            Stream Protocol (ST-II)
      0035            Banyan Vines
      0037            reserved (until 1993)
      00ff            reserved (compression inefficient)

      0201            802.1d Hello Packets
      0231            Luxcom
      0233            Sigma Network Systems

      8021            Internet Protocol Control Protocol
      8023            OSI Network Layer Control Protocol
      8025            Xerox NS IDP Control Protocol
      8027            DECnet Phase IV Control Protocol
      8029            Appletalk Control Protocol
      802b            Novell IPX Control Protocol
      802d            Reserved
      802f            Reserved
      8031            Bridging NCP
      8033            Stream Protocol Control Protocol
      8035            Banyan Vines Control Protocol

      c021            Link Control Protocol
      c023            Password Authentication Protocol
      c025            Link Quality Report
      c223            Challenge Handshake Authentication Protocol

   Developers of new protocols MUST obtain a number from the Internet
   Assigned Numbers Authority (IANA), at [e-mail].





Simpson                                                         [Page 8]

RFC 1331                Point-to-Point Protocol                 May 1992


Information Field

   The Information field is zero or more octets.  The Information field
   contains the datagram for the protocol specified in the Protocol
   field.  The end of the Information field is found by locating the
   closing Flag Sequence and allowing two octets for the Frame Check
   Sequence field.  The default maximum length of the Information field
   is 1500 octets.  By negotiation, consenting PPP implementations may
   use other values for the maximum Information field length.

   On transmission, the Information field may be padded with an
   arbitrary number of octets up to the maximum length.  It is the
   responsibility of each protocol to disambiguate padding octets from
   real information.

Frame Check Sequence (FCS) Field

   The Frame Check Sequence field is normally 16 bits (two octets).  The
   use of other FCS lengths may be defined at a later time, or by prior
   agreement.

   The FCS field is calculated over all bits of the Address, Control,
   Protocol and Information fields not including any start and stop bits
   (asynchronous) and any bits (synchronous) or octets (asynchronous)
   inserted for transparency.  This does not include the Flag Sequences
   or the FCS field itself.  The FCS is transmitted with the coefficient
   of the highest term first.

      Note: When octets are received which are flagged in the Async-
      Control-Character-Map, they are discarded before calculating the
      FCS.  See the description in Appendix A.

   For more information on the specification of the FCS, see ISO 3309
   [2] or CCITT X.25 [6].

      Note: A fast, table-driven implementation of the 16-bit FCS
      algorithm is shown in Appendix B.  This implementation is based on
      [7], [8], and [9].

Modifications to the Basic Frame Format

   The Link Control Protocol can negotiate modifications to the standard
   PPP frame structure.  However, modified frames will always be clearly
   distinguishable from standard frames.







Simpson                                                         [Page 9]

RFC 1331                Point-to-Point Protocol                 May 1992


4.  PPP Link Operation

4.1.  Overview

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure and test