RFC 1989
PPP Link Quality Monitoring
RFC 1989: PPP Link Quality Monitoring 🎀
Okay bestie, the header is giving us everything we need 📜. This is RFC 1989, titled PPP Link Quality Monitoring, written by W. Simpson of Daydreamer in August 1996. It's a Standards Track doc in the Network Working Group series 🌸, and it obsoletes RFC 1333, so 1333 is officially retired 💅. The header doesn't list any RFCs that it updates.
Part 1 of 3, more coming bestie 💖
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌍.
Abstract 💖
Okay so the Point-to-Point Protocol (PPP) [1] is the standard way to carry multi-protocol datagrams over point-to-point links 🚀. PPP also defines an extensible Link Control Protocol, which lets you negotiate a Quality Protocol to keep checking, continuously, whether the link is still viable 🫶. And this doc defines a protocol for generating Link-Quality-Reports 📝.
Table of Contents 📑
1. Introduction .......................................... 2
2. Link Quality Monitoring ............................... 2
2.1 Design Motivation ............................... 2
2.2 Counters ........................................ 3
2.3 Counting Packets and Octets ..................... 4
2.4 Processes ....................................... 5
2.5 Configuration Option Format ..................... 6
2.6 Packet Format ................................... 8
2.7 Transmission of Reports ......................... 12
2.8 Calculations .................................... 12
2.9 Failure Detection ............................... 13
2.10 Policy Suggestions .............................. 14
SECURITY CONSIDERATIONS ...................................... 15
ACKNOWLEDGEMENTS ............................................. 15
REFERENCES ................................................... 15
CHAIR'S ADDRESS .............................................. 16
AUTHOR'S ADDRESS ............................................. 161. Introduction ✨
To get chatting over a point-to-point link, each end of the PPP link has to send LCP packets first, to set up the data link during the Link Establishment phase 💅. Then, during the Authentication and Network-Layer Protocol phases, the link can get tested to check whether its quality is good enough to run on. And honestly? That testing is totally optional, no pressure 🫶.
Say an implementation wants its peer to use a particular link quality monitoring protocol. Then it MUST negotiate that protocol using the Quality-Protocol Configuration Option during the Link Establishment phase, no skipping 💅.
The negotiation works separately in each direction, so the two directions are independent 🦋. BUT, if the peer agrees to send Quality-Protocol packets, then it MUST correctly process those packets when they arrive, even if it never asked for them or doesn't have a monitoring policy of its own 😭.
2. Link Quality Monitoring 📡
Real talk, data links are rarely perfect 💀. Packets can get dropped or corrupted for all kinds of reasons: line noise, equipment failure, buffer overruns, and so on. Sometimes you want to figure out when the link is dropping data, and how often. Routers, for example, might want to temporarily let another route take the lead. An implementation can also choose to disconnect and hop over to an alternate link. Figuring out how much data is getting lost is called "Link Quality Monitoring" ✨.
2.1. Design Motivation 🧠
There are loads of ways to measure link quality, and even more ways to react to it 🌈. Instead of picking one scheme, Link Quality Monitoring is split into a "mechanism" and a "policy". PPP fully nails down the "mechanism" by defining the Link-Quality-Report (LQR) packet and spelling out a procedure for using it 💖.
PPP does not specify a Link Quality Monitoring "policy" 🙈. That means it doesn't tell you how to judge link quality or what to do when the quality isn't good enough. That's an implementation decision, and each end of the link can make its own call. Implementations are allowed, and even encouraged, to play around with different link quality policies 🧪. The mechanism spec makes sure two implementations with different policies can still talk to each other and interoperate 🫶.
So flexible policies are possible, the mechanism measures data loss in units of packets, octets, and Link-Quality-Reports 📦. Every measurement is taken separately for each half of the link, inbound and outbound. All the measurements get shared with both ends, so each end can run its own link quality policy for both its outbound and inbound links 🎀.
Last but not least, Link Quality Monitoring is built to be implementable on lots of different kinds of systems 🌸. It's pretty common to do PPP (especially Link Quality Monitoring) as one single software process, but multi-process setups with hardware support are also on the vision board 👑. The mechanism carefully defines the Link-Quality-Report packet format and sets reference points for all the data transmission and reception measurements 📏.
2.2. Counters 🔢
Every Link Quality Monitoring implementation keeps count of the packets and octets it transmits and successfully receives, and it periodically sends that info to its peer inside a Link-Quality-Report packet.
These counters are kinda like sequence numbers 🧠. They keep going up, giving a "relative" sense of how many packets and octets have crossed the outbound link. If an LQR receiver compares the values in successive Link-Quality-Reports, it can work out the "delta" of packets and octets that were successfully communicated across the link. Comparing those absolute numbers then tells you something about the link's quality. Relative numbers get sent instead of absolute ones because they make link synchronization way easier 💅.
The Link-Quality-Report uses the Interface counters defined by SNMP MIB-II [2] 📊. These counters don't get set to any particular value when the LCP enters the Establishment phase.
On top of that, the Link-Quality-Report requires three more counters 🎀. They're unsigned, monotonically increasing, and they have to conform to the type and size requirements for SNMP MIB Counters [3].
OutLQRs
OutLQRs is a 32-bit counter that goes up by one for every transmitted Link-Quality-Report packet 🔼. This counter MUST be set to zero when the LCP enters the Establishment phase, and it MUST NOT be reset until the LCP leaves the Termination phase. It gets incremented before it's inserted into the LQR packet ✨.
InLQRs
InLQRs is a 32-bit counter that goes up by one for each received Link-Quality-Report packet 📥. This counter MUST be set to zero when the LCP enters the Establishment phase, and it MUST NOT be reset until the LCP leaves the Termination phase. It gets incremented before it is inserted (in an implementation dependent fashion) into the LQR packet 🤷.
InGoodOctets
InGoodOctets is a 32-bit counter that goes up by the number of octets in each successfully received Data Link Layer packet 🌊. Unlike the MIB ifInOctets, octets for frames that are counted in ifInDiscards and ifInErrors MUST NOT be counted 🚫. This counter MAY be set to any initial value when the LCP enters the Establishment phase, but it MUST NOT be reset until the LCP leaves the Termination phase.
2.3. Counting Packets and Octets 🧮
The counters are meant to show how much information is passing over the link 📬, not to actually measure the total bandwidth used. This spec is designed to give the same count in different situations. For example, when a separate device handles the framing and escaping invisibly to the implementation, or when a synchronous-to-asynchronous converter in the link switches between mechanisms 🔁.
Every octet that goes into the FCS calculation MUST be counted, including the packet header, the information field, and any padding. The FCS octets MUST also be counted, and one flag octet per frame MUST be counted. Every other octet, like extra flag sequences and escape bits or octets, MUST NOT be counted 🙅.
When you pop the packet and octet counts into the LQR, those counts MUST include the expected values for the LQR itself 💅.
2.4. Processes 🧩
The mechanism is described using a "logical process" model. As shown below, there are five logical processes, duplicated at each end of the duplex link.
+---------+ +-------+ +----+ Outbound
| |-->| Mux |-->| Tx |=========>
| Link- | +-------+ +----+
| Manager |
| | +-------+ +----+ Inbound
| |<--| Demux |<--| Rx |<=========
+---------+ +-------+ +----+Link-Manager 👑
This one sends and receives Link-Quality-Reports, and it's where the desired link quality policy gets implemented. LQR packets go out at a constant rate, which gets negotiated through the LCP Quality-Protocol Configuration Option.
Mux 🎀
This one squishes packets from all the various protocols (e.g., LCP, IP, XNS, and so on) into a single, sequential, prioritized stream of packets. Link-Quality-Report packets MUST be given the highest possible priority, so the link quality info gets communicated in a timely manner ⏰.
Tx 📤
This one keeps the MIB counters ifOutUniPackets and ifOutOctets, plus the internal counter OutLQRs, which measure how much data gets transmitted on the outbound link. When Tx processes a Link-Quality-Report packet, it pops the values of these counters into the corresponding PeerOut... fields of the packet. The Tx process MUST follow the Mux process, so packets get counted in the order they're transmitted to the link.
Rx 📥
This one maintains the MIB counters ifInUniPackets, ifInDiscards, ifInErrors and IfInOctets, plus the internal counters InLQRs and InGoodOctets, which measure how much data comes in over the inbound link. When Rx processes a Link-Quality-Report packet, it tucks the values of these counters into the matching SaveIn... fields of the packet (in an implementation dependent manner).
Demux 🧃
This one demultiplexes packets back out for the various protocols. The Demux process MUST follow the Rx process, so packets get counted in the order they were received from the link 🌈.
2.5. Configuration Option Format 🎀
Description
okay bestie, first things first 💅 Implementations MUST be prepared to receive the Quality-Protocol Configuration Option for the Link-Quality-Report. 🫶 but actually negotiating it? not required ✨ You only need negotiation when you want one of these things: making sure the peer sends Link-Quality-Reports instead of some other Quality-Protocol, stopping the peer from running its own timer, or setting a maximum time between Link-Quality-Report transmissions. 💜
A quick look at the Quality-Protocol Configuration Option format used to negotiate the Link-Quality-Report is below. Fields go left to right 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Quality-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporting-Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
the Type is 4 🌸
Length
the Length is 8 🌸
Quality-Protocol
the Quality-Protocol value is c025 (hex) for the Link-Quality-Report 💖
Reporting-Period
okay this one is a whole vibe 🔥 The Reporting-Period field is four octets, and it's the maximum time in hundredths of seconds between packet transmissions. The peer MAY transmit packets faster than the rate that was negotiated ✨
A value of zero means the peer doesn't need to keep its own timer. Instead, it generates a LQR right away whenever it receives a LQR 🧚 Now the tea: a 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 packet containing the Quality-Protocol Configuration Option for the Link-Quality-Report with a zero Reporting-Period. 💀 zero is NOT allowed to just slide through, periodt 👑
2.6. Packet Format 🦋
Exactly one Link-Quality-Report packet gets encapsulated in the Information field of PPP Data Link Layer frames where the protocol field says type hex c025 (Link-Quality-Report). ✨ The field names are relative to the packet receiver, because the receiver is the one who asked for the packet in the Configuration Option 💅 Here's the LQR packet format, left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LastOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInDiscards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInErrors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PeerOutOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the plot twist 😭 these next fields are NOT actually sent over the inbound link. Instead, they get logically tacked onto the packet by the implementation's Rx process, in an implementation dependent way 🫶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInDiscards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInErrors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Magic-Number
the Magic-Number field is four octets and helps spot links that are in the looped-back condition 🔄 Unless a Configuration Option changes it, the Magic-Number MUST be transmitted as zero and MUST be ignored on reception. If Magic-Numbers have been negotiated, incoming LQR packets SHOULD be checked to make sure the local end isn't seeing its own Magic-Number, which would mean it's looped back 👀 Check the Magic-Number Configuration Option for the full explanation 💜
LastOutLQRs
the LastOutLQRs field is four octets, copied from the most recently received PeerOutLQRs on transmission 🌈
LastOutPackets
the LastOutPackets field is four octets, copied from the most recently received PeerOutPackets on transmission 🌈
LastOutOctets
the LastOutOctets field is four octets, copied from the most recently received PeerOutOctets on transmission 🌈
PeerInLQRs
the PeerInLQRs field is four octets, copied from the most recently received SaveInLQRs on transmission 🍓
Whenever PeerInLQRs is discovered to be zero, the LastOut... fields are indeterminate, and the PeerIn... fields hold the peer's initial values 🧁
PeerInPackets
the PeerInPackets field is four octets, copied from the most recently received SaveInPackets on transmission 🍓
PeerInDiscards
the PeerInDiscards field is four octets, copied from the most recently received SaveInDiscards on transmission 🍓
PeerInErrors
the PeerInErrors field is four octets, copied from the most recently received SaveInErrors on transmission 🍓
PeerInOctets
the PeerInOctets field is four octets, copied from the most recently received SaveInOctets on transmission 🍓
PeerOutLQRs
the PeerOutLQRs field is four octets, copied from OutLQRs on transmission. This number MUST include this LQR 💅
PeerOutPackets
the PeerOutPackets field is four octets, copied from the current MIB ifOutUniPackets and ifOutNUniPackets on transmission. This number MUST include this LQR 💅
PeerOutOctets
the PeerOutOctets field is four octets, copied from the current MIB ifOutOctets on transmission. This number MUST include this LQR 💅
SaveInLQRs
the SaveInLQRs field is four octets, copied from InLQRs on reception. This number MUST include this LQR 🦋
SaveInPackets
the SaveInPackets field is four octets, copied from the current MIB ifInUniPackets and ifInNUniPackets on reception. This number MUST include this LQR 🦋
SaveInDiscards
the SaveInDiscards field is four octets, copied from the current MIB ifInDiscards on reception. This number MUST include this LQR 🦋
SaveInErrors
the SaveInErrors field is four octets, copied from the current MIB ifInErrors on reception. This number MUST include this LQR 🦋
SaveInOctets
the SaveInOctets field is four octets, copied from the current InGoodOctets on reception. This number MUST include this LQR 🦋
Heads up, this one is easy to mix up 🙈 InGoodOctets is NOT the same as the MIB ifInOctets counter, because InGoodOctets doesn't count octets from packets that are discards or errors.
2.7. Transmission of Reports 🌸
When the PPP Link Control Protocol hits the Opened state, the Link Quality Monitoring process MAY start sending Link-Quality-Reports ✨ But if a Protocol-Reject comes in specifying a LQR packet, the LQM process MUST cease sending LQRs 🛑
Usually, a LQR goes out when the LQR timer for the link expires. If there's no LQR timer, a LQR gets generated as soon as an incoming LQR arrives. Negotiation makes sure at least one side of the link is using a LQR timer 🫶
Also, a LQR gets generated whenever two successive LQRs come in with the same PeerInLQRs value 👀 That could mean a LQR got lost, or that the implementation is sending way slower than its peer, or that the peer sped up LQR generation to get a better read on link errors. 🔍
Whenever a LQR is sent, the LQR timer MUST be restarted ⏰
2.8. Calculations 🧮
Every time a Link-Quality-Report packet comes in from the inbound link, the Link-Manager can compare the matching fields. Subtract the fields of the previous LQR from the current LQR values to get an absolute "delta", which lets you compare how much each end of the link saw things change 💜
If the received PeerInLQRs field is zero, the LastOut... fields are indeterminate, and the PeerIn... fields hold the initial values for the peer. No calculations using these fields can happen at this point 🙅♀️
Implementation Note: The following counters wrap to zero when they hit their maximum value 🌀 Be extra careful to make sure correct "delta" calculations happen at that moment.
The LastOutLQRs field can be compared directly with the PeerInLQRs field to figure out how many outbound LQRs got lost 📉
The LastOutLQRs field can be compared directly with the OutLQRs counter to figure out how many outbound LQRs are still in the pipeline 🚰
The change in PeerInPackets can be compared with the change in LastOutPackets to find the number of lost packets over the outgoing link 📦
The change in PeerInOctets can be compared with the change in LastOutOctets to find the number of lost octets over the outgoing link 🧃
The change in SaveInPackets can be compared with the change in PeerOutPackets to find the number of lost packets over the incoming link 📦
The change in SaveInOctets can be compared with the change in PeerOutOctets to find the number of lost octets over the incoming link 🧃
The change in the PeerInDiscards and PeerInErrors fields can be used to tell whether packet loss is caused by congestion in the peer, rather than a physical link failure 🚦
2.9. Failure Detection 🦋
okay so when the link is running well in both directions, the LQR is kinda superfluous 💅 The maximum time interval for transmitting LQRs SHOULD be chosen to minimally interfere with active traffic, because nobody wants their bestie's download getting bullied by status updates 🙈
when there's a measurable loss of data in either direction but the overall throughput is still adequate, the conditions aren't bad enough to justify dropping the link 🫶 Sending LQRs faster gains nothing here, except maybe catching peaks in the loss rate. The time interval MUST be long enough to smooth out the data, but short enough to respond fast enough to a complete failure. It's giving balance ⚖️✨
when the link is good incoming but very bad outgoing, the incoming LQRs are showing a high loss on the outgoing side 😭 Sending LQRs faster won't help, because they're probably getting lost on the way to the peer. so sad, no cap 💀
when the link is good outgoing but very bad incoming, the incoming LRQs will be frequently lost 🥺 In this case, LQRs SHOULD be sent at a faster rate. This mostly leans on the peer to make an informed policy decision, and the peer will also send LQRs back in response (thanks to the duplicate PeerInLQRs field 🌈). Some of those responses may actually make it through, which is iconic of them 👑
when a LQR doesn't arrive in the time expected, or the LQR that did arrive shows the links are truly bad, at least one additional LQR SHOULD be sent 🔥 An algorithmic decision needs at least 2 round trip intervals, because one bad moment isn't a whole personality. The loss rate could be transient (a heavily loaded link, or just a lost outgoing LQR), so don't panic yet, bestie 🌸
2.10. Policy Suggestions 💜
LQR packets give you a mechanism to figure out the link quality, but it's up to each implementation to decide when the link is usable 🧚 It is recommended that this policy have some amount of hysteresis so the link doesn't bounce up and down like a bad group chat mood 🍓 One policy is a K out of N algorithm. In that algorithm, there must be K successes out of the last N periods for the link to be considered of good quality ✨
procedures for recovering from poor quality links are unspecified and may vary from implementation to implementation 🎀 A suggested approach is to immediately close all the other Network-Layer protocols (basically, cause IPCP to transmit a Terminate-Request), but keep transmitting Link-Quality-Reports 💖 Once the link quality gets back to an acceptable level, the Network-Layer protocols can be reconfigured. main character comeback arc 🦋👑
Security Considerations 🔐
Security issues are not discussed in this memo. 😶 Yes, this document is going in with zero security talk, so keep your guard up out there, bestie 🙈
Acknowledgements 🫶
Some of the text in this document is taken from RFC 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis 🌈
Special thanks to Craig Fox (Network Systems), and Karl Fox (Morning Star Technologies), for design suggestions based on implementation experience 🌟 The real ones, honestly 💅
References 📚
- [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
- [2] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
- [3] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
Chair's Address 🎀
The working group can be contacted via the current chair 💌
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.comAuthor's Address 🌸
Questions about this memo can also be directed to: 💬
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com (prefered)📦 where this page comes from
- ietf: rfc1989 1996-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms