rfc1548.txt

<VC++网络游戏建摸与实现>源代码

    Implementation Note:

      This action enables the FSA to pause before proceeding to the
      desired final state, allowing traffic to be processed by the peer.
      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.

    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



Simpson                                                        [Page 25]

RFC 1548              The Point-to-Point Protocol          December 1993


      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.

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


4.8 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 SHOULD 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 (2,400 to 9,600 bps), high



Simpson                                                        [Page 26]

RFC 1548              The Point-to-Point Protocol          December 1993


      switching latency links (typical telephone lines).  Higher speed
      links, or links with low switching latency, SHOULD have
      correspondingly faster retransmission times.

      Instead of a constant value, the Restart timer MAY begin at an
      initial small value and increase to the configured final value.
      Each successive value less than the final value SHOULD be at least
      twice the previous value.  The initial value SHOULD be large
      enough to account for the size of the packets, twice the round
      trip time for transmission at the link speed, and at least an
      additional 100 milliseconds to allow the peer to process the
      packets before responding.  Some circuits add another 200
      milliseconds of satellite delay.  Round trip times for modems
      operating at 14,400 bps have been measured in the range of 160 to
      more than 600 milliseconds.

    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.

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



Simpson                                                        [Page 27]

RFC 1548              The Point-to-Point Protocol          December 1993


         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 PPP 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 as if no Configuration Options were
   enabled.  This ensures that such LCP packets are always recognizable
   even when one end of the link mistakenly believes the link to be
   open.

    Implementation Note:

      In particular, the Async-Control-Character-Map (ACCM) default for
      the type of link is used, and no address, control, or protocol
      field compression is allowed.

      Exactly one LCP packet is encapsulated in the PPP Information
      field, where the PPP 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 1548              The Point-to-Point Protocol          December 1993


   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.

      Up-to-date values of the LCP Code field are specified in the most
      recent "Assigned Numbers" RFC [2].  This specification concerns
      the following values:

            1       Configure-Request
            2       Configure-Ack
            3       Configure-Nak
            4       Configure-Reject
            5       Terminate-Request
            6       Terminate-Ack
            7       Code-Reject
            8       Protocol-Reject
            9       Echo-Request
            10      Echo-Reply
            11      Discard-Request

    Identifier

      The Identifier field is one octet and aids in matching requests
      and replies.  When a packet is received with an invalid Identifier
      field, the packet is silently discarded.

    Length

      The Length field is two octets and indicates the length of the LCP
      packet including the Code, Identifier, Length and Data fields.
      Octets outside the range of the Length field are treated as
      padding and are ignored on reception.  When a packet is received
      with an invalid Length field, the packet is silently discarded.

    Data

      The Data field is zero or more octets as indicated by the Length
      field.  The format of the Data field is determined by the Code
      field.

5.1 Configure-Request

    Description

      An implementation wishing to open a connection MUST transmit a LCP
      packet with the Code field set to 1 (Configure-Request), and the



Simpson                                                        [Page 29]

RFC 1548              The Point-to-Point Protocol          December 1993


      Options field filled with any desired changes to the link
      defaults.  Configuration Options SHOULD NOT be included with
      default values.

      Upon reception of a Configure-Request, an appropriate reply MUST
      be transmitted.

   A summary of the Configure-Request 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             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Options ...
  +-+-+-+-+

   Code

      1 for Configure-Request.

   Identifier

      The Identifier field MUST be changed whenever the content of the
      Options field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.

   Options

      The options field is variable in length and contains the list of
      zero or more Configuration Options that the sender desires to
      negotiate.  All Configuration Options are always negotiated
      simultaneously.  The format of Configuration Options is further
      described in a later section.

5.2 Configure-Ack

   Description

      If every Configuration Option received in a Configure-Request is
      recognizable and all values are acceptable, then the
      implementation MUST transmit a LCP packet with the Code field set
      to 2 (Configure-Ack), the Identifier field copied from the
      received Configure-Request, and the Options field copied from the
      received Configure-Request.  The acknowledged Configuration
      Options MUST NOT be reordered or modified in any way.



Simpson                                                        [Page 30]

RFC 1548              The Point-to-Point Protocol          December 1993


      On reception of a Configure-Ack, the Identifier field MUST match
      that of the last transmitted Configure-Request.  Additionally, the
      Configuration Options in a Configure-Ack MUST exactly match those
      of the last transmitted Configure-Request.  Invalid packets are
      silently discarded.

   A summary of the Configure-Ack 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             |
  +-+-+-+-+-+-+-+-+-+-