rfc1331.txt

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

   +------+        +-----------+           +--------------+
   |      | UP     |           | OPENED    |              | SUCCESS/NONE
   | Dead |------->| Establish |---------->| Authenticate |--+
   |      |        |           |           |              |  |
   +------+        +-----------+           +--------------+  |
      ^          FAIL |                   FAIL |             |
      +<--------------+             +----------+             |
      |                             |                        |
      |            +-----------+    |           +---------+  |
      |       DOWN |           |    |   CLOSING |         |  |
      +------------| Terminate |<---+<----------| Network |<-+
                   |           |                |         |
                   +-----------+                +---------+

4.3.  Link Dead (physical-layer not ready)

   The link necessarily begins and ends with this phase.  When an
   external event (such as carrier detection or network administrator
   configuration) indicates that the physical-layer is ready to be used,
   PPP will proceed to the Link Establishment phase.

   During this phase, the LCP automaton (described below) will be in the
   Initial or Starting states.  The transition to the Link Establishment
   phase will signal an Up event to the automaton.




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


   Implementation Note:

      Typically, a link will return to this phase automatically after
      the disconnection of a modem.  In the case of a hard-wired line,
      this phase may be extremely short -- merely long enough to detect
      the presence of the device.

4.4.  Link Establishment Phase

   The Link Control Protocol (LCP) is used to establish the connection
   through an exchange of Configure packets.  This exchange is complete,
   and the LCP Opened state entered, once a Configure-Ack packet
   (described below) has been both sent and received.  Any non-LCP
   packets received during this phase MUST be silently discarded.

   All Configuration Options are assumed to be at default values unless
   altered by the configuration exchange.  See the section on LCP
   Configuration Options for further discussion.

   It is important to note that only Configuration Options which are
   independent of particular network-layer protocols are configured by
   LCP.  Configuration of individual network-layer protocols is handled
   by separate Network Control Protocols (NCPs) during the Network-Layer
   Protocol phase.

4.5.  Authentication Phase

   On some links it may be desirable to require a peer to authenticate
   itself before allowing network-layer protocol packets to be
   exchanged.

   By default, authentication is not necessary.  If an implementation
   requires that the peer authenticate with some specific authentication
   protocol, then it MUST negotiate the use of that authentication
   protocol during Link Establishment phase.

   Authentication SHOULD take place as soon as possible after link
   establishment.  However, link quality determination MAY occur
   concurrently.  An implementation MUST NOT allow the exchange of link
   quality determination packets to delay authentication indefinitely.

   Advancement from the Authentication phase to the Network-Layer
   Protocol phase MUST NOT occur until the peer is successfully
   authenticated using the negotiated authentication protocol.  In the
   event of failure to authenticate, PPP SHOULD proceed instead to the
   Link Termination phase.





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


4.6.  Network-Layer Protocol Phase

   Once PPP has finished the previous phases, each network-layer
   protocol (such as IP) MUST be separately configured by the
   appropriate Network Control Protocol (NCP).

   Each NCP may be Opened and Closed at any time.

   Implementation Note:

      Because an implementation may initially use a significant amount
      of time for link quality determination, implementations SHOULD
      avoid fixed timeouts when waiting for their peers to configure a
      NCP.

   After a NCP has reached the Opened state, PPP will carry the
   corresponding network-layer protocol packets.  Any network-layer
   protocol packets received when the corresponding NCP is not in the
   Opened state SHOULD be silently discarded.

   During this phase, link traffic consists of any possible combinations
   of LCP, NCP, and network-layer protocol packets.  Any NCP or
   network-layer protocol packets received during any other phase SHOULD
   be silently discarded.

   Implementation Note:

      There is an exception to the preceding paragraphs, due to the
      availability of the LCP Protocol-Reject (described below).  While
      LCP is in the Opened state, any protocol packet which is
      unsupported by the implementation MUST be returned in a Protocol-
      Reject.  Only supported protocols are silently discarded.

4.7.  Link Termination Phase

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

   LCP is used to close the link through an exchange of Terminate
   packets.  When the link is closing, PPP informs the network-layer
   protocols so that they may take appropriate action.

   After the exchange of Terminate packets, the implementation SHOULD
   signal the physical-layer to disconnect in order to enforce the
   termination of the link, particularly in the case of an
   authentication failure.  The sender of the Terminate-Request SHOULD



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


   disconnect after receiving a Terminate-Ack, or after the Restart
   counter expires.  The receiver of a Terminate-Request SHOULD wait for
   the peer to disconnect, and MUST NOT disconnect until at least one
   Restart time has passed after sending a Terminate-Ack.  PPP SHOULD
   proceed to the Link Dead phase.

   Implementation Note:

      The closing of the link by LCP is sufficient.  There is no need
      for each NCP to send a flurry of Terminate packets.  Conversely,
      the fact that a NCP has Closed is not sufficient reason to cause
      the termination of the PPP link, even if that NCP was the only
      currently NCP in the Opened state.






































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


5.  The Option Negotiation Automaton

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

   Some types of packets -- Configure-Naks and Configure-Rejects, or
   Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
   Discard-Requests -- are not differentiated in the automaton
   descriptions.  As will be described later, these packets do indeed
   serve different functions.  However, they always cause the same
   transitions.

   Events                                   Actions

   Up   = lower layer is Up                 tlu = This-Layer-Up
   Down = lower layer is Down               tld = This-Layer-Down
   Open = administrative Open               tls = This-Layer-Start
   Close= administrative Close              tlf = This-Layer-Finished

   TO+  = Timeout with counter > 0          irc = initialize restart
                                                  counter
   TO-  = Timeout with counter expired      zrc = zero restart counter

   RCR+ = Receive-Configure-Request (Good)  scr = Send-Configure-Request
   RCR- = Receive-Configure-Request (Bad)
   RCA  = Receive-Configure-Ack             sca = Send-Configure-Ack
   RCN  = Receive-Configure-Nak/Rej         scn = Send-Configure-Nak/Rej

   RTR  = Receive-Terminate-Request         str = Send-Terminate-Request
   RTA  = Receive-Terminate-Ack             sta = Send-Terminate-Ack

   RUC  = Receive-Unknown-Code              scj = Send-Code-Reject
   RXJ+ = Receive-Code-Reject (permitted)
       or Receive-Protocol-Reject
   RXJ- = Receive-Code-Reject (catastrophic)
       or Receive-Protocol-Reject
   RXR  = Receive-Echo-Request              ser = Send-Echo-Reply
       or Receive-Echo-Reply
       or Receive-Discard-Request
                                             -  = illegal action








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


5.1.  State Diagram

   The simplified state diagram which follows describes the sequence of
   events for reaching agreement on Configuration Options (opening the
   PPP link) and for later termination of the link.

      This diagram is not a complete representation of the automaton.
      Implementation MUST be done by consulting the actual state
      transition table.

   Events are in upper case.  Actions are in lower case.  For these
   purposes, the state machine is initially in the Closed state.  Once
   the Opened state has been reached, both ends of the link have met the
   requirement of having both sent and received a Configure-Ack packet.

                  RCR                    TO+
                +--sta-->+             +------->+
                |        |             |        |
          +-------+      |   RTA +-------+      | Close +-------+
          |       |<-----+<------|       |<-str-+<------|       |
          |Closed |              |Closing|              |Opened |
          |       | Open         |       |              |       |
          |       |------+       |       |              |       |
          +-------+      |       +-------+              +-------+
                         |                                ^
                         |                                |
                         |         +-sca----------------->+
                         |         |                      ^
                 RCN,TO+ V    RCR+ |     RCR-         RCA |    RCN,TO+
                +------->+         |   +------->+         |   +--scr-->+
                |        |         |   |        |         |   |        |
          +-------+      |   TO+ +-------+      |       +-------+      |
          |       |<-scr-+<------|       |<-scn-+       |       |<-----+
          | Req-  |              | Ack-  |              | Ack-  |
          | Sent  | RCA          | Rcvd  |              | Sent  |
   +-scn->|       |------------->|       |       +-sca->|       |
   |      +-------+              +-------+       |      +-------+
   |   RCR- |   | RCR+                           |   RCR+ |   | RCR-
   |        |   +------------------------------->+<-------+   |
   |        |                                                 |
   +<-------+<------------------------------------------------+










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


5.2.  State Transition Table

   The complete state transition table follows.  States are indicated
   horizontally, and events are read vertically.  State transitions and
   actions are represented in the form action/new-state.  Multiple
   actions are separated by commas, and may continue on succeeding lines
   as space requires.  The state may be followed by a letter, which
   indicates an explanatory footnote.

   Rationale:

      In previous versions of this table, a simplified non-deterministic
      finite-state automaton was used, with considerable detailed
      information specified in the semantics.  This lead to
      interoperability problems from differing interpretations.

      This table functions similarly to the previous versions, with the
      up/down flags expanded to explicit states, and the active/passive
      paradigm eliminated.  It is believed that this table interoperates
      with previous versions better than those versions themselves.

      | State
      |    0         1         2         3         4         5
Events| Initial   Starting  Closed    Stopped   Closing   Stopping
------+-----------------------------------------------------------
 Up   |    2     irc,scr/6     -         -         -         -
 Down |    -         -         0       tls/1       0         1
 Open |  tls/1       1     irc,scr/6     3r        5r        5r
 Close|    0         0         2         2         4         4
      |
  TO+ |    -         -         -         -       str/4     str/5
  TO- |    -         -         -         -       tlf/2     tlf/3
      |
 RCR+ |    -         -       sta/2 irc,scr,sca/8   4         5
 RCR- |    -         -       sta/2 irc,scr,scn/6   4         5
 RCA  |    -         -       sta/2     sta/3       4         5