rfc1548.txt

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

   Transitions and actions in the automaton are caused by events.

    Up

      The Up event occurs when a lower layer indicates that it is ready
      to carry packets.

      Typically, this event is used by a modem handling or calling
      process, or by some other coupling of the PPP link to the physical
      media, to signal LCP that the link is entering Link Establishment
      phase.

      It also can be used by LCP to signal each NCP that the link is
      entering Network-Layer Protocol phase.  That is, the This-Layer-Up
      action from LCP triggers the Up event in the NCP.

    Down

      The Down event occurs when a lower layer indicates that it is no
      longer ready to carry packets.

      Typically, this event is used by a modem handling or calling
      process, or by some other coupling of the PPP link to the physical
      media, to signal LCP that the link is entering Link Dead phase.

      It also can be used by LCP to signal each NCP that the link is
      leaving Network-Layer Protocol phase.  That is, the This-Layer-
      Down action from LCP triggers the Down event in the NCP.

    Open

      The Open event indicates that the link is administratively
      available for traffic; that is, the network administrator (human
      or program) has indicated that the link is allowed to be Opened.
      When this event occurs, and the link is not in the Opened state,
      the automaton attempts to send configuration packets to the peer.

      If the automaton is not able to begin configuration (the lower
      layer is Down, or a previous Close event has not completed), the
      establishment of the link is automatically delayed.




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


      When a Terminate-Request is received, or other events occur which
      cause the link to become unavailable, the automaton will progress
      to a state where the link is ready to re-open.  No additional
      administrative intervention is necessary.

    Implementation Option:

      Experience has shown that users will execute an additional Open
      command when they want to renegotiate the link.  This might
      indicate that new values are to be negotiated.

      Since this is not the meaning of the Open event, it is suggested
      that when an Open user command is executed in the Opened, Closing,
      Stopping, or Stopped states, the implementation issue a Down
      event, immediately followed by an Up event.  This will cause the
      renegotiation of the link, without any harmful side effects.

    Close

      The Close event indicates that the link is not available for
      traffic; that is, the network administrator (human or program) has
      indicated that the link is not allowed to be Opened.  When this
      event occurs, and the link is not in the Closed state, the
      automaton attempts to terminate the connection.  Futher attempts
      to re-configure the link are denied until a new Open event occurs.

    Implementation Note:

      When authentication fails, the link SHOULD be terminated, to
      prevent attack by repetition and denial of service to other users.
      Since the link is administratively available (by definition), this
      can be accomplished by simulating a Close event to the LCP,
      immediately followed by an Open event.

      The Close followed by an Open will cause an orderly termination of
      the link, by progressing from the Closing to the Stopping state,
      and the This-Layer-Finished action can disconnect the link.  The
      automaton waits in the Stopped or Starting states for the next
      connection attempt.

    Timeout (TO+,TO-)

      This event indicates the expiration of the Restart timer.  The
      Restart timer is used to time responses to Configure-Request and
      Terminate-Request packets.

      The TO+ event indicates that the Restart counter continues to be
      greater than zero, which triggers the corresponding Configure-



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


      Request or Terminate-Request packet to be retransmitted.

      The TO- event indicates that the Restart counter is not greater
      than zero, and no more packets need to be retransmitted.

    Receive-Configure-Request (RCR+,RCR-)

      This event occurs when a Configure-Request packet is received from
      the peer.  The Configure-Request packet indicates the desire to
      open a connection and may specify Configuration Options.  The
      Configure-Request packet is more fully described in a later
      section.

      The RCR+ event indicates that the Configure-Request was
      acceptable, and triggers the transmission of a corresponding
      Configure-Ack.

      The RCR- event indicates that the Configure-Request was
      unacceptable, and triggers the transmission of a corresponding
      Configure-Nak or Configure-Reject.

    Implementation Note:

      These events may occur on a connection which is already in the
      Opened state.  The implementation MUST be prepared to immediately
      renegotiate the Configuration Options.

    Receive-Configure-Ack (RCA)

      The Receive-Configure-Ack event occurs when a valid Configure-Ack
      packet is received from the peer.  The Configure-Ack packet is a
      positive response to a Configure-Request packet.  An out of
      sequence or otherwise invalid packet is silently discarded.

    Implementation Note:

      Since the correct packet has already been received before reaching
      the Ack-Rcvd or Opened states, it is extremely unlikely that
      another such packet will arrive.  As specified, all invalid
      Ack/Nak/Rej packets are silently discarded, and do not affect the
      transitions of the automaton.

      However, it is not impossible that a correctly formed packet will
      arrive through a coincidentally-timed cross-connection.  It is
      more likely to be the result of an implementation error.  At the
      very least, this occurance SHOULD be logged.





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


    Receive-Configure-Nak/Rej (RCN)

      This event occurs when a valid Configure-Nak or Configure-Reject
      packet is received from the peer.  The Configure-Nak and
      Configure-Reject packets are negative responses to a Configure-
      Request packet.  An out of sequence or otherwise invalid packet is
      silently discarded.

    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



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


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

4.6 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 cannot occur in a properly
      implemented automaton.  The implementation has an internal error,
      which should be reported and logged.  No transition is taken, and
      the implementation SHOULD NOT reset or freeze.

    This-Layer-Up (tlu)

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

      Typically, this action is 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 network layer traffic.

    This-Layer-Down (tld)

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

      Typically, this action is 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



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


      available for its network layer traffic.

    This-Layer-Started (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.

    Implementation Note:

      This results of this action are highly implementation dependent.

      The transitions where this event is indicated are defined
      according to a message passing architecture, rather than a
      signalling architecture.  If the action is desired to control
      specific signals (such as DTR), other transitions for the action
      are likely to be required (Open in Closed, RCR in Stopped).

    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.

    Implementation Note:

      This results of this action are highly implementation dependent.

      The transitions where this event is indicated are defined
      according to a message passing architecture, rather than a
      signalling architecture.  If the action is desired to control
      specific signals (such as DTR), other transitions for the action
      are likely to be required (Close in Starting, Down in Closing).

    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.






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


    Implementation Note:

      In addition to setting the Restart counter, the implementation
      MUST set the timeout period to the initial value when Restart
      timer backoff is used.

    Zero-Restart-Counter (zrc)

      This action sets the Restart counter to zero.