?? rfc1661.txt
字號:
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
Simpson [Page 18]
RFC 1661 Point-to-Point Protocol July 1994
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
Simpson [Page 19]
RFC 1661 Point-to-Point Protocol July 1994
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.
Simpson [Page 20]
RFC 1661 Point-to-Point Protocol July 1994
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.
Simpson [Page 21]
RFC 1661 Point-to-Point Protocol July 1994
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
Simpson [Page 22]
RFC 1661 Point-to-Point Protocol July 1994
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.
Simpson [Page 23]
RFC 1661 Point-to-Point Protocol July 1994
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.
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -