PPP Link Quality Monitoring
obsoletes
- rfc-1333 — PPP Link Quality Monitoring
Extracted elements (29)
Counters in LQR packets are relative (monotonically increasing sequence numbers) rather than absolute loss counts. Comparing values in successive LQRs yields a 'delta' measurement; relative numbers greatly simplify link synchronization.
InGoodOctets is defined separately from the SNMP MIB ifInOctets because ifInOctets includes octets for discarded and errored frames, which would skew loss calculations; InGoodOctets counts only octets from successfully received frames.
LQM is deliberately divided into a fully-specified 'mechanism' (the LQR packet and procedures) and an unspecified 'policy' (how to judge quality and react). This allows two implementations with different policies to interoperate, and encourages experimentation.
Measurements are made separately for each direction (inbound and outbound) and communicated to both ends, so each end can independently implement its own quality policy for both its outbound and inbound links.
Policy suggestions include a K-out-of-N hysteresis algorithm to prevent link bouncing. When quality is poor, closing Network-Layer protocols (e.g., sending IPCP Terminate-Request) while continuing to send LQRs is a suggested recovery approach.
LQR uses SNMP MIB-II interface counters (ifOutUniPackets, ifOutOctets, ifInUniPackets, ifInDiscards, ifInErrors, ifInOctets) as defined in RFC 1213. These counters are not reset when LCP enters Establishment phase.
The negotiation of Quality-Protocol is independent in each direction of the link. An implementation must be prepared to receive and process LQR packets even if it has not negotiated to send them itself.
A Reporting-Period value of zero MUST be Nak'd by the peer with an appropriate non-zero value when that peer has sent or will send a Configure-Request containing the Quality-Protocol Configuration Option with a zero Reporting-Period.
All octets included in the FCS calculation MUST be counted (packet header, information field, padding, FCS octets), plus one flag octet per frame. Additional flag sequences and escape bits or octets MUST NOT be counted.
If a Protocol-Reject is received specifying a LQR packet, the LQM process MUST cease sending LQRs.
If an implementation desires that the peer use a specific link quality monitoring protocol, it MUST negotiate that protocol via the Quality-Protocol Configuration Option during LCP Link Establishment phase.
If the peer agrees to send Quality-Protocol packets, it MUST correctly process such packets on reception, even if it did not request them or implement a monitoring policy.
LQR packets MUST be given the highest possible priority in the Mux process to ensure link quality information is communicated in a timely manner.
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 transmission time interval SHOULD be chosen to be long enough to smooth data while short enough to ensure fast response to complete failure; implementations SHOULD send at least one additional LQR when a LQR does not arrive within the expected time or indicates truly bad links.
The Magic-Number field MUST be transmitted as zero and MUST be ignored on reception unless modified by a Configuration Option. If Magic-Numbers are negotiated, incoming LQRs SHOULD be checked to detect a looped-back link.
The Tx process MUST follow the Mux process, and the Demux process MUST follow the Rx process, so that packets are counted in the order they are transmitted or received from the link.
When inserting packet and octet counts in the LQR, the counts MUST include the expected values for the LQR packet itself, ensuring the report is self-consistent.
When the link is good outgoing but very bad incoming, LQRs SHOULD be sent at a faster rate to help the peer make an informed policy decision about the degraded inbound path.
Whenever a LQR is sent, the LQR timer MUST be restarted.
Five logical processes are defined at each end of the duplex link: Link-Manager (transmits/receives LQRs, enforces policy), Mux (prioritized multiplexer), Tx (maintains OutLQRs and inserts PeerOut fields), Rx (maintains InLQRs/InGoodOctets and inserts SaveIn fields), and Demux (demultiplexer following Rx).
InGoodOctets is a 32-bit counter that counts octets in each successfully received Data Link Layer packet. Unlike ifInOctets, octets for frames counted in ifInDiscards and ifInErrors MUST NOT be counted; this counter MAY be set to any initial value at LCP Establishment.
InLQRs is a 32-bit unsigned monotonically increasing counter incremented by one for each received LQR packet. It MUST be set to zero when LCP enters Establishment phase and MUST NOT be reset until LCP leaves Termination phase.
OutLQRs is a 32-bit unsigned monotonically increasing counter incremented by one for each transmitted LQR packet. It MUST be set to zero when LCP enters Establishment phase and MUST NOT be reset until LCP leaves Termination phase; it is incremented before being inserted into the LQR.
The Link-Quality-Report (LQR) packet (protocol type 0xc025) carries counters for transmitted and received packets, octets, and LQR counts. Twelve fields are transmitted over the wire; five SaveIn fields are appended locally by the Rx process and never transmitted.
Security issues are not discussed in this memo. The document explicitly defers all security considerations.
LQR transmission is triggered by three events: (1) expiry of the LQR timer (normal case), (2) receipt of an incoming LQR when no timer is in use, or (3) receipt of two successive LQRs with the same PeerInLQRs value indicating a missed LQR. LQM MAY commence only after LCP reaches Opened state.
The LQR packet consists of twelve 32-bit fields transmitted on-wire: Magic-Number, LastOutLQRs, LastOutPackets, LastOutOctets, PeerInLQRs, PeerInPackets, PeerInDiscards, PeerInErrors, PeerInOctets, PeerOutLQRs, PeerOutPackets, PeerOutOctets. An additional five 32-bit SaveIn fields (SaveInLQRs, SaveInPackets, SaveInDiscards, SaveInErrors, SaveInOctets) are appended by the Rx process in an implementation-dependent manner and not transmitted.
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 time in hundredths of seconds between LQR transmissions).