PPP Link Quality Monitoring
obsoleted by
- rfc-1989 — PPP Link Quality Monitoring
Extracted elements (27)
A LQR is also generated whenever two successive received LQRs have the same PeerInLQRs value. This handles the case where a LQR was missed, the sender is much slower than the peer, or the peer has accelerated generation to better quantify errors.
Counters are transmitted as relative (monotonically increasing) sequence-style numbers rather than absolute loss counts. Relative numbers greatly simplify link synchronization; receivers compute deltas by subtracting successive LQR values.
Link Quality Monitoring is deliberately divided into a 'mechanism' (fully specified by PPP via LQR packets and procedures) and a 'policy' (how to judge quality and react, left to each implementation). This separation allows two implementations with different policies to interoperate.
Policy suggestions include using hysteresis to prevent the link from bouncing up and down, and a K-out-of-N algorithm where the link is considered good only when K of the last N periods succeed. Recovery may involve closing NCPs (e.g., sending IPCP Terminate-Request) while continuing to send LQRs.
The LQR packet format and reference-point model explicitly accommodate multi-process and hardware-assisted implementations where framing, transmit, and receive may be separate processes or devices. The SaveIn... fields are logically appended by the Rx process in an implementation-dependent manner.
LQR negotiation is independent in each direction; one peer may request LQRs while the other does not. The negotiation process guarantees that at least one side uses a LQR timer so the protocol does not deadlock when both sides set Reporting-Period to zero.
When the received PeerInLQRs field is zero, the LastOut... fields are indeterminate and the PeerIn... fields contain only initial peer values; no delta calculations can be performed until a subsequent LQR is received with a non-zero PeerInLQRs.
A Reporting-Period value of zero MUST be Nak'd by a peer that has sent or will send a Configure-Request with a zero Reporting-Period, replacing it with an appropriate non-zero value. A zero value means the peer generates LQRs immediately upon receiving one rather than maintaining a timer.
All octets included in the FCS calculation MUST be counted (header, information, padding, and FCS itself), and exactly one flag octet per frame MUST be counted. Additional flag sequences and escape bits or octets MUST NOT be counted.
If a Protocol-Reject is received specifying an LQR packet, the LQM process MUST cease sending LQRs. Whenever a LQR is sent, the LQR timer MUST be restarted.
If an implementation desires that the peer use a specific link quality monitoring protocol, it MUST negotiate that protocol using the Quality-Protocol Configuration Option during the LCP Establishment phase.
If the peer agrees to send Quality-Protocol packets, it MUST correctly process such packets on reception, even if it does not itself request such packets or implement a monitoring policy.
Implementations MUST be prepared to receive the Quality-Protocol Configuration Option for the Link-Quality-Report, even if they do not wish to negotiate it themselves.
InGoodOctets MUST NOT count octets for frames that are counted in ifInDiscards or ifInErrors. It MAY be initialized to any value at LCP Establishment but MUST NOT be reset until the LCP leaves the Termination phase.
LQR packets MUST be given the highest possible priority in the Mux process to ensure link quality information is communicated in a timely manner.
OutLQRs and InLQRs MUST each be set to zero when the LCP enters the Establishment phase, and MUST NOT be reset until the LCP leaves the Termination phase.
PeerOutLQRs, PeerOutPackets, and PeerOutOctets MUST each include the current LQR being transmitted. Similarly, all SaveIn... fields MUST include the current LQR being received.
The LQR timer interval MUST be chosen to be long enough for a good smoothing effect on the data, while short enough to ensure fast enough response to complete failure. The maximum interval SHOULD be chosen to minimally interfere with active traffic.
The Tx process MUST follow the Mux process so packets are counted in transmission order; the Demux process MUST follow the Rx process so packets are counted in reception order.
Unless Magic-Numbers have been negotiated via Configuration Option, the Magic-Number field MUST be transmitted as zero and MUST be ignored on reception. When negotiated, incoming LQR packets SHOULD be checked for loopback detection.
When inserting packet and octet counts into an LQR, the counts MUST include the expected values for the LQR packet itself (i.e., the LQR counts itself).
When the incoming link is good but outgoing is very bad, LQRs SHOULD be sent at a faster rate. When a LQR does not arrive within the expected time or received LQRs indicate the link is truly bad, at least one additional LQR SHOULD be sent.
Five logical processes are defined at each end of the link: Link-Manager (transmits/receives LQRs and enforces policy), Mux (prioritizes outbound packet stream), Tx (maintains outbound counters and fills PeerOut... fields), Rx (maintains inbound counters and fills SaveIn... fields), and Demux (demultiplexes inbound packets). Process ordering is load-bearing for correct counting.
Three implementation-specific counters supplement the SNMP MIB-II interface counters: OutLQRs (32-bit, incremented before insertion into each transmitted LQR), InLQRs (32-bit, incremented before insertion into each received LQR), and InGoodOctets (32-bit, counts octets of successfully received frames only, excluding discards and errors).
Security issues are not discussed in this memo.
The LQR packet contains 12 transmitted 32-bit fields: Magic-Number, LastOutLQRs, LastOutPackets, LastOutOctets, PeerInLQRs, PeerInPackets, PeerInDiscards, PeerInErrors, PeerInOctets, PeerOutLQRs, PeerOutPackets, PeerOutOctets. Five additional 32-bit SaveIn... fields (SaveInLQRs, SaveInPackets, SaveInDiscards, SaveInErrors, SaveInOctets) are appended locally by the Rx process and are not transmitted over the link.
The Quality-Protocol Configuration Option is 8 octets: Type (1 octet, value 4), Length (1 octet, value 8), Quality-Protocol (2 octets, value 0xc025 for LQR), and Reporting-Period (4 octets, maximum interval in hundredths of seconds between LQR transmissions).