Section 4. 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-Started
   Close= administrative Close              tlf = This-Layer-Finished
   TO+  = Timeout with counter > 0          irc = Initialize-Restart-Count
   TO-  = Timeout with counter expired      zrc = Zero-Restart-Count
   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
4.1.  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; multiple actions may be implemented in any
   convenient order.  The state may be followed by a letter, which
   indicates an explanatory footnote.  The dash ('-') indicates an
   illegal transition.
      | 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       tlf/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
 RCN  |    -         -       sta/2     sta/3       4         5
      |
 RTR  |    -         -       sta/2     sta/3     sta/4     sta/5
 RTA  |    -         -         2         3       tlf/2     tlf/3
      |
 RUC  |    -         -       scj/2     scj/3     scj/4     scj/5
 RXJ+ |    -         -         2         3         4         5
 RXJ- |    -         -       tlf/2     tlf/3     tlf/2     tlf/3
      |
 RXR  |    -         -         2         3         4         5
      | State
      |    6         7         8           9
Events| Req-Sent  Ack-Rcvd  Ack-Sent    Opened
------+-----------------------------------------
 Up   |    -         -         -           -
 Down |    1         1         1         tld/1
 Open |    6         7         8           9r
 Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
      |
  TO+ |  scr/6     scr/6     scr/8         -
  TO- |  tlf/3p    tlf/3p    tlf/3p        -
      |
 RCR+ |  sca/8   sca,tlu/9   sca/8   tld,scr,sca/8
 RCR- |  scn/6     scn/7     scn/6   tld,scr,scn/6
 RCA  |  irc/7     scr/6x  irc,tlu/9   tld,scr/6x
 RCN  |irc,scr/6   scr/6x  irc,scr/8   tld,scr/6x
      |
 RTR  |  sta/6     sta/6     sta/6   tld,zrc,sta/5
 RTA  |    6         6         8       tld,scr/6
      |
 RUC  |  scj/6     scj/7     scj/8       scj/9
 RXJ+ |    6         6         8           9
 RXJ- |  tlf/3     tlf/3     tlf/3   tld,irc,str/5
      |
 RXR  |    6         7         8         ser/9
   The states in which the Restart timer is running are identifiable by
   the presence of TO events.  Only the Send-Configure-Request, Send-
   Terminate-Request and Zero-Restart-Count actions start or re-start
   the Restart timer.  The Restart timer is stopped when transitioning
   from any state where the timer is running to a state where the timer
   is not running.
   The events and actions are defined according to a message passing
   architecture, rather than a signalling architecture.  If an action is
   desired to control specific signals (such as DTR), additional actions
   are likely to be required.
   [p]   Passive option; see Stopped state discussion.
   [r]   Restart option; see Open event discussion.
   [x]   Crossed connection; see RCA event discussion.
4.2.  States
   Following is a more detailed description of each automaton state.
   Initial
      In the Initial state, the lower layer is unavailable (Down), and
      no Open has occurred.  The Restart timer is not running in the
      Initial state.
   Starting
      The Starting state is the Open counterpart to the Initial state.
      An administrative Open has been initiated, but the lower layer is
      still unavailable (Down).  The Restart timer is not running in the
      Starting state.
      When the lower layer becomes available (Up), a Configure-Request
      is sent.
   Closed
      In the Closed state, the link is available (Up), but no Open has
      occurred.  The Restart timer is not running in the Closed state.
      Upon reception of Configure-Request packets, a Terminate-Ack is
      sent.  Terminate-Acks are silently discarded to avoid creating a
      loop.
   Stopped
      The Stopped state is the Open counterpart to the Closed state.  It
      is entered when the automaton is waiting for a Down event after
      the This-Layer-Finished action, or after sending a Terminate-Ack.
      The Restart timer is not running in the Stopped state.
      Upon reception of Configure-Request packets, an appropriate
      response is sent.  Upon reception of other packets, a Terminate-
      Ack is sent.  Terminate-Acks are silently discarded to avoid
      creating a loop.
      Rationale:
         The Stopped state is a junction state for link termination,
         link configuration failure, and other automaton failure modes.
         These potentially separate states have been combined.
         There is a race condition between the Down event response (from
         the This-Layer-Finished action) and the Receive-Configure-
         Request event.  When a Configure-Request arrives before the
         Down event, the Down event will supercede by returning the
         automaton to the Starting state.  This prevents attack by
         repetition.
      Implementation Option:
         After the peer fails to respond to Configure-Requests, an
         implementation MAY wait passively for the peer to send
         Configure-Requests.  In this case, the This-Layer-Finished
         action is not used for the TO- event in states Req-Sent, Ack-
         Rcvd and Ack-Sent.
         This option is useful for dedicated circuits, or circuits which
         have no status signals available, but SHOULD NOT be used for
         switched circuits.
   Closing
      In the Closing state, an attempt is made to terminate the
      connection.  A Terminate-Request has been sent and the Restart
      timer is running, but a Terminate-Ack has not yet been received.
      Upon reception of a Terminate-Ack, the Closed state is entered.
      Upon the expiration of the Restart timer, a new Terminate-Request
      is transmitted, and the Restart timer is restarted.  After the
      Restart timer has expired Max-Terminate times, the Closed state is
      entered.
   Stopping
      The Stopping state is the Open counterpart to the Closing state.
      A Terminate-Request has been sent and the Restart timer is
      running, but a Terminate-Ack has not yet been received.
      Rationale:
         The Stopping state provides a well defined opportunity to
         terminate a link before allowing new traffic.  After the link
         has terminated, a new configuration may occur via the Stopped
         or Starting states.
   Request-Sent
      In the Request-Sent state an attempt is made to configure the
      connection.  A Configure-Request has been sent and the Restart
      timer is running, but a Configure-Ack has not yet been received
      nor has one been sent.
   Ack-Received
      In the Ack-Received state, a Configure-Request has been sent and a
      Configure-Ack has been received.  The Restart timer is still
      running, since a Configure-Ack has not yet been sent.
   Ack-Sent
      In the Ack-Sent state, a Configure-Request and a Configure-Ack
      have both been sent, but a Configure-Ack has not yet been
      received.  The Restart timer is running, since a Configure-Ack has
      not yet been received.
   Opened
      In the Opened state, a Configure-Ack has been both sent and
      received.  The Restart timer is not running.
      When entering the Opened state, the implementation SHOULD signal
      the upper layers that it is now Up.  Conversely, when leaving the
      Opened state, the implementation SHOULD signal the upper layers
      that it is now Down.
4.3.  Events
   Transitions and actions in the automaton are caused by events.
   Up
      This 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
      This 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
      This 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.
      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.  Care must be taken that an intervening Down event
         cannot occur from another source.
         The Down followed by an Up will cause an orderly renegotiation
         of the link, by progressing through the Starting to the
         Request-Sent state.  This will cause the renegotiation of the
         link, without any harmful side effects.
   Close
      This 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.  Care
         must be taken that an intervening Close event cannot occur from
         another source.
         The Close followed by an Open will cause an orderly termination
         of the link, by progressing through 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-
      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)
      This 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.
   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)
      This 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)
      This 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)
      This 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
      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 an Echo-Request packet.  There is no reply to an
      Echo-Reply or Discard-Request packet.
4.4.  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
      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.
      This results of this action are highly implementation dependent.
   This-Layer-Finished (tlf)
      This action indicates to the lower layers that the automaton is
      entering the Initial, Closed or Stopped 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 results of this action are highly implementation dependent.
   Initialize-Restart-Count (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.
      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-Count (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, 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)
      A Configure-Request packet is transmitted.  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)
      A Configure-Ack packet is transmitted.  This acknowledges the
      reception of a Configure-Request packet with an acceptable set of
      Configuration Options.
   Send-Configure-Nak (scn)
      A Configure-Nak or Configure-Reject packet is transmitted, 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 chapter on LCP Packet Formats.
   Send-Terminate-Request (str)
      A Terminate-Request packet is transmitted.  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)
      A Terminate-Ack packet is transmitted.  This acknowledges the
      reception of a Terminate-Request packet or otherwise serves to
      synchronize the automatons.
   Send-Code-Reject (scj)
      A Code-Reject packet is transmitted.  This indicates the reception
      of an unknown type of packet.
   Send-Echo-Reply (ser)
      An Echo-Reply packet is transmitted.  This acknowledges the
      reception of an Echo-Request packet.
4.5.  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.6.  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 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 for peer requested
      options are converted to Configure-Reject packets, and locally
      desired options are no longer appended.  Max-Failure MUST be
      configurable, but SHOULD default to five (5) transmissions.