rfc1331.txt

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

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


      Implementation Note:

         Although the Configure-Nak and Configure-Reject cause the same
         state transition in the automaton, these packets have
         significantly different effects on the Configuration Options
         sent in the resulting Configure-Request packet.

   Receive-Terminate-Request (RTR)

      The Receive-Terminate-Request event occurs when a Terminate-
      Request packet is received.  The Terminate-Request packet
      indicates the desire of the peer to close the connection.

      Implementation Note:

         This event is not identical to the Close event (see above), and
         does not override the Open commands of the local network
         administrator.  The implementation MUST be prepared to receive
         a new Configure-Request without network administrator
         intervention.

   Receive-Terminate-Ack (RTA)

      The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
      is received from the peer.  The Terminate-Ack packet is usually a
      response to a Terminate-Request packet.  The Terminate-Ack packet
      may also indicate that the peer is in Closed or Stopped states,
      and serves to re-synchronize the link configuration.

   Receive-Unknown-Code (RUC)

      The Receive-Unknown-Code event occurs when an un-interpretable
      packet is received from the peer.  A Code-Reject packet is sent in
      response.

   Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)

      This event occurs when a Code-Reject or a Protocol-Reject packet
      is received from the peer.

      The RXJ+ event arises when the rejected value is acceptable, such
      as a Code-Reject of an extended code, or a Protocol-Reject of a
      NCP.  These are within the scope of normal operation.  The
      implementation MUST stop sending the offending packet type.

      The RXJ- event arises when the rejected value is catastrophic,
      such as a Code-Reject of Configure-Request, or a Protocol-Reject
      of LCP!  This event communicates an unrecoverable error that



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


      terminates the connection.

   Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
   (RXR)

      This event occurs when an Echo-Request, Echo-Reply or Discard-
      Request packet is received from the peer.  The Echo-Reply packet
      is a response to a Echo-Request packet.  There is no reply to an
      Echo-Reply or Discard-Request packet.

5.5.  Actions

   Actions in the automaton are caused by events and typically indicate
   the transmission of packets and/or the starting or stopping of the
   Restart timer.

   Illegal-Event (-)

      This indicates an event that SHOULD NOT occur.  The implementation
      probably has an internal error.

   This-Layer-Up (tlu)

      This action indicates to the upper layers that the automaton is
      entering the Opened state.

      Typically, this action MAY be used by the LCP to signal the Up
      event to a NCP, Authentication Protocol, or Link Quality Protocol,
      or MAY be used by a NCP to indicate that the link is available for
      its traffic.

   This-Layer-Down (tld)

      This action indicates to the upper layers that the automaton is
      leaving the Opened state.

      Typically, this action MAY be used by the LCP to signal the Down
      event to a NCP, Authentication Protocol, or Link Quality Protocol,
      or MAY be used by a NCP to indicate that the link is no longer
      available for its traffic.

   This-Layer-Start (tls)

      This action indicates to the lower layers that the automaton is
      entering the Starting state, and the lower layer is needed for the
      link.  The lower layer SHOULD respond with an Up event when the
      lower layer is available.




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


      This action is highly implementation dependent.

   This-Layer-Finished (tlf)

      This action indicates to the lower layers that the automaton is
      entering the Stopped or Closed states, and the lower layer is no
      longer needed for the link.  The lower layer SHOULD respond with a
      Down event when the lower layer has terminated.

      Typically, this action MAY be used by the LCP to advance to the
      Link Dead phase, or MAY be used by a NCP to indicate to the LCP
      that the link may terminate when there are no other NCPs open.

      This action is highly implementation dependent.

   Initialize-Restart-Counter (irc)

      This action sets the Restart counter to the appropriate value
      (Max-Terminate or Max-Configure).  The counter is decremented for
      each transmission, including the first.

   Zero-Restart-Counter (zrc)

      This action sets the Restart counter to zero.

      Implementation Note:

         This action enables the FSA to pause before proceeding to the
         desired final state.  In addition to zeroing the Restart
         counter, the implementation MUST set the timeout period to an
         appropriate value.

   Send-Configure-Request (scr)

      The Send-Configure-Request action transmits a Configure-Request
      packet.  This indicates the desire to open a connection with a
      specified set of Configuration Options.  The Restart timer is
      started when the Configure-Request packet is transmitted, to guard
      against packet loss.  The Restart counter is decremented each time
      a Configure-Request is sent.

   Send-Configure-Ack (sca)

      The Send-Configure-Ack action transmits a Configure-Ack packet.
      This acknowledges the reception of a Configure-Request packet with
      an acceptable set of Configuration Options.





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


   Send-Configure-Nak (scn)

      The Send-Configure-Nak action transmits a Configure-Nak or
      Configure-Reject packet, as appropriate.  This negative response
      reports the reception of a Configure-Request packet with an
      unacceptable set of Configuration Options.  Configure-Nak packets
      are used to refuse a Configuration Option value, and to suggest a
      new, acceptable value.  Configure-Reject packets are used to
      refuse all negotiation about a Configuration Option, typically
      because it is not recognized or implemented.  The use of
      Configure-Nak versus Configure-Reject is more fully described in
      the section on LCP Packet Formats.

   Send-Terminate-Request (str)

      The Send-Terminate-Request action transmits a Terminate-Request
      packet.  This indicates the desire to close a connection.  The
      Restart timer is started when the Terminate-Request packet is
      transmitted, to guard against packet loss.  The Restart counter is
      decremented each time a Terminate-Request is sent.

   Send-Terminate-Ack (sta)

      The Send-Terminate-Ack action transmits a Terminate-Ack packet.
      This acknowledges the reception of a Terminate-Request packet or
      otherwise serves to synchronize the state machines.

   Send-Code-Reject (scj)

      The Send-Code-Reject action transmits a Code-Reject packet.  This
      indicates the reception of an unknown type of packet.

   Send-Echo-Reply (ser)

      The Send-Echo-Reply action transmits an Echo-Reply packet.  This
      acknowledges the reception of an Echo-Request packet.

5.6.  Loop Avoidance

   The protocol makes a reasonable attempt at avoiding Configuration
   Option negotiation loops.  However, the protocol does NOT guarantee
   that loops will not happen.  As with any negotiation, it is possible
   to configure two PPP implementations with conflicting policies that
   will never converge.  It is also possible to configure policies which
   do converge, but which take significant time to do so.  Implementors
   should keep this in mind and should implement loop detection
   mechanisms or higher level timeouts.




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


5.7.  Counters and Timers

Restart Timer

   There is one special timer used by the automaton.  The Restart timer
   is used to time transmissions of Configure-Request and Terminate-
   Request packets.  Expiration of the Restart timer causes a Timeout
   event, and retransmission of the corresponding Configure-Request or
   Terminate-Request packet.  The Restart timer MUST be configurable,
   but MAY default to three (3) seconds.

   Implementation Note:

      The Restart timer SHOULD be based on the speed of the link.  The
      default value is designed for low speed (19,200 bps or less), high
      switching latency links (typical telephone lines).  Higher speed
      links, or links with low switching latency, SHOULD have
      correspondingly faster retransmission times.

Max-Terminate

   There is one required restart counter for Terminate-Requests.  Max-
   Terminate indicates the number of Terminate-Request packets sent
   without receiving a Terminate-Ack before assuming that the peer is
   unable to respond.  Max-Terminate MUST be configurable, but should
   default to two (2) transmissions.

Max-Configure

   A similar counter is recommended for Configure-Requests.  Max-
   Configure indicates the number of Configure-Request packets sent
   without receiving a valid Configure-Ack, Configure-Nak or Configure-
   Reject before assuming that the peer is unable to respond.  Max-
   Configure MUST be configurable, but should default to ten (10)
   transmissions.

Max-Failure

   A related counter is recommended for Configure-Nak.  Max-Failure
   indicates the number of Configure-Nak packets sent without sending a
   Configure-Ack before assuming that configuration is not converging.
   Any further Configure-Nak packets are converted to Configure-Reject
   packets.  Max-Failure MUST be configurable, but should default to ten
   (10) transmissions.







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


6.  LCP Packet Formats

   There are three classes of LCP packets:

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

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

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

   This document describes Version 1 of the Link Control Protocol.  In
   the interest of simplicity, there is no version field in the LCP
   packet.  If a new version of LCP is necessary in the future, the
   intention is that a new Data Link Layer Protocol field value will be
   used to differentiate Version 1 LCP from all other versions.  A
   correctly functioning Version 1 LCP implementation will always
   respond to unknown Protocols (including other versions) with an
   easily recognizable Version 1 packet, thus providing a deterministic
   fallback mechanism for implementations of other versions.

   Regardless of which Configuration Options are enabled, all LCP Link
   Configuration, Link Termination, and Code-Reject packets (codes 1
   through 7) are always sent in the full, standard form, as if no
   Configuration Options were enabled.  This ensures that LCP
   Configure-Request packets are always recognizable even when one end
   of the link mistakenly believes the link to be open.

   Exactly one Link Control Protocol packet is encapsulated in the
   Information field of PPP Data Link Layer frames where the Protocol
   field indicates type hex c021 (Link Control Protocol).

   A summary of the Link Control Protocol packet format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+





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


   Code

      The Code field is one octet and identifies the kind of LCP packet.
      When a packet is received with an invalid Code field, a Code-
      Reject packet is transmitted.