rfc1171.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

           |   Flag   | Address  | Control  | Protocol | Information
           | 01111110 | 11111111 | 00000011 | 16 bits  |      *
           +----------+----------+----------+----------+------------
                   ---+---------+----------+
                      |   FCS   |   Flag   |
                      | 16 bits | 01111110 |
                   ---+---------+----------+

   This figure does not include start/stop bits (for asynchronous links)
   or any bits or octets inserted for transparency.  When asynchronous
   links are used, all octets are transmitted with one start bit, eight
   bits of data, and one stop bit.  There is no provision in either PPP
   or ISO 3309:1984/PDAD1 for seven bit asynchronous links.

   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.

   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).

   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 should 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 reported through the normal network management facility.

   Control Field

      The Control field is a single octet and contains the binary



Perkins                                                         [Page 5]

RFC 1171                Point-to-Point Protocol                July 1990


      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.  The
      most up-to-date values of the Protocol field are specified in the
      most recent "Assigned Numbers" RFC [12]. Initial values are also
      listed below.

      Protocol field values in the "cxxx" range identify datagrams as
      belonging to the Link Control Protocol (LCP) or associated
      protocols. Values in the "8xxx" range identify datagrams belonging
      to the family of Network Control Protocols (NCP).  Values in the
      "0xxx" range identify the network protocol of specific datagrams.

      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 should be
      considered as having an unrecognized Protocol, and should be
      handled as specified by the LCP.  The Protocol field is
      transmitted and received most significant octet first.























Perkins                                                         [Page 6]

RFC 1171                Point-to-Point Protocol                July 1990


      The Protocol field is initially assigned as follows:

         Value (in hex)          Protocol

         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 1
         002f                  * Van Jacobson Compressed TCP/IP 2

         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

         c021                    Link Control Protocol
         c023                  * User/Password Authentication Protocol

            * Reserved for future use; not described in this document.

   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 prior agreement, 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).
      By prior agreement, consenting PPP implementations may use a 32-



Perkins                                                         [Page 7]

RFC 1171                Point-to-Point Protocol                July 1990


      bit (four-octet) FCS for improved error detection.

      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 FCS field.  The FCS is transmitted with the
      coefficient of the highest term first.

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

         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.






























Perkins                                                         [Page 8]

RFC 1171                Point-to-Point Protocol                July 1990


4.  The PPP Link Control Protocol (LCP)

   The Link Control Protocol (LCP) provides a method of establishing,
   configuring, maintaining and terminating the point-to-point
   connection.  LCP goes through four distinct phases:

   Phase 1: Link Establishment and Configuration Negotiation

      Before any network-layer datagrams (e.g., IP) may be exchanged,
      LCP must first open the connection through an exchange of
      Configure packets.  This exchange is complete, and the Open state
      entered, once a Configure-Ack packet (described below) has been
      both sent and received.  Any non-LCP packets received before this
      exchange is complete are silently discarded.

      It is important to note that LCP handles configuration only of the
      link; LCP does not handle configuration of individual network-
      layer protocols.  In particular, all Configuration Parameters
      which are independent of particular network-layer protocols are
      configured by LCP.  All Configuration Options are assumed to be at
      default values unless altered by the configuration exchange.

   Phase 2: Link Quality Determination

      LCP allows an optional Link Quality Determination phase following
      transition to the LCP Open state.  In this phase, the link is
      tested to determine if the link quality is sufficient to bring up
      network-layer protocols.  This phase is completely optional.  LCP
      may delay transmission of network-layer protocol information until
      this phase is completed.

      The procedure for Link Quality Determination is unspecified and
      may vary from implementation to implementation, or because of
      user-configured parameters, but only so long as the procedure
      doesn't violate other aspects of LCP.  One suggested method is to
      use LCP Echo-Request and Echo-Reply packets.

      What is important is that this phase may persist for any length of
      time.  Therefore, implementations should avoid fixed timeouts when
      waiting for their peers to advance to phase 3.

   Phase 3: Network-Layer Protocol Configuration Negotiation

      Once LCP has finished the Link Quality Determination phase,
      network-layer protocols may be separately configured by the
      appropriate Network Control Protocols (NCP), and may be brought up
      and taken down at any time.  If LCP closes the link, it informs
      the network-layer protocols so that they may take appropriate



Perkins                                                         [Page 9]

RFC 1171                Point-to-Point Protocol                July 1990


      action.

   Phase 4: Link Termination

      LCP may terminate the link at any time.  This will usually be done
      at the request of a human user, but may happen because of a
      physical event such as the loss of carrier, or the expiration of
      an idle-period timer.











































Perkins                                                        [Page 10]

RFC 1171                Point-to-Point Protocol                July 1990


4.1.  The LCP Automaton

4.1.1.  Overview

   LCP is specified by a number of packet formats and a finite-state
   automaton.  This section presents an overview of the LCP automaton,
   followed by a representation of it as both a state diagram and a
   state transition table.

   There are three classes of LCP packets:

      1. Link Establishment packets used to establish and configure a
         link, (e.g., Configure-Request, Configure-Ack, Configure-Nak
         and Configure-Reject)

      2. Link Termination packets used to terminate a link, (e.g.,
         Terminate-Request and Terminate-Ack)

      3. Link Maintenance packets used to manage and debug a link,
         (e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply
         and Discard-Request)

   The finite-state automaton is defined by events, state transitions
   and actions.  Events include receipt of external commands such as
   Open and Close, expiration of the Restart timer, and receipt of
   packets from a LCP peer.  Actions include the starting of the Restart
   timer and transmission of packets.


4.1.2.  State Diagram

   The state diagram which follows describes the sequence of events for
   reaching agreement on Configuration Options (opening the PPP
   connection) and for later closing of the connection.  The state
   machine is initially in the Closed state (1).  Once the Open state
   (6) has been reached, both ends of the link have met the requirement
   of having both sent and received a Configure-Ack packet.

   In the state diagram, events are shown above horizontal lines.
   Actions are shown below horizontal lines.  Two types of LCP packets -
   Configure-Naks and Configure-Rejects - are not differentiated in the
   state diagram.  As will be described later, these packets do indeed
   serve different, though similar, functions.  However, at the level of
   detail of this state diagram, they always cause the same transition.

   Since a more detailed specification of the LCP automaton is given in
   a state transition table in the following section, implementation
   should be done by consulting it rather than this state diagram.



Perkins                                                        [Page 11]

RFC 1171                Point-to-Point Protocol                July 1990


                                    +------------------------------+
                                    |                              |
                                    V                              |
        +---2---+           PO +---1---+        RTA +---7---+      |
        |       |<-------------|       |<-----------|       |      |
        |Listen |              |Closed |            |Closing|      |
    RCR |       | C            |       | PLD        |       |      |
   +----|       |----->+------>|       |<---Any     |       |<--+  |
   |scr +-------+      ^       +-------+    State   +-------+   |  |
   |                   |     AO  |   ^                    | TO  |  |
   |       +-----------+     --- |   |                    +---->+  |
   |       |                 SCR |   |                      str ^  |
   |   C   |   RCN/TO            |   | C                        |  |
   |   --- | +-------->+<--------+   | ---                      |  |
   |       | | scr     |             |                          |  |
   |    +---3---+      V   TO  +---4---+            +-------+   |  |
   |    |       |<-----+<------|       |<-----------|       |   |  |
   |    | Req-  |          scr | Ack-  |        scn | Good  |   |  |