Network Working Group W. Simpson Request for Comments: 1333 Daydreamer May 1992 PPP Link Quality Monitoring Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. This document defines a protocol for generating Link-Quality-Reports. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. Simpson [Page i] RFC 1333 PPP Link Quality Monitoring May 1992 Table of Contents 1. Introduction .......................................... 1 2. Link Quality Monitoring ............................... 2 2.1 Design Motivation ............................... 2 2.2 Counters ........................................ 2 2.3 Counting Packets and Octets ..................... 4 2.4 Processes ....................................... 4 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 ...................................... 14 REFERENCES ................................................... 14 ACKNOWLEDGEMENTS ............................................. 14 CHAIR'S ADDRESS .............................................. 15 AUTHOR'S ADDRESS ............................................. 15 Simpson [Page ii] RFC 1333 PPP Link Quality Monitoring May 1992 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during the Establishment phase. During the Authentication and Network-Layer Protocol phases, the link may be tested to determine if quality is sufficient for operation. This testing is completely optional. If an implementation desires that the peer use some specific link quality monitoring protocol, then it MUST negotiate the use of that protocol using the Quality-Protocol Configuration Option during Link Establishment phase. The negotiation mechanism is independent in each direction. However, if the peer agrees to send Quality-Protocol packets, it MUST correctly process such packet. s on reception, even if it does not request such packets or implement a monitoring policy. Simpson [Page 1] RFC 1333 PPP Link Quality Monitoring May 1992 2. Link Quality Monitoring Data communications links are rarely perfect. Packets can be dropped or corrupted for various reasons (line noise, equipment failure, buffer overruns, etc.). Sometimes, it is desirable to determine when, and how often, the link is dropping data. Routers, for example, may want to temporarily allow another route to take precedence. An implementation may also have the option of disconnecting and switching to an alternate link. The process of determining data loss is called "Link Quality Monitoring". 2.1. Design Motivation There are many different ways to measure link quality, and even more ways to react to it. Rather than specifying a single scheme, Link Quality Monitoring is divided into a "mechanism" and a "policy". PPP fully specifies the "mechanism" for Link Quality Monitoring by defining the Link-Quality-Report (LQR) packet and specifying a procedure for its use. PPP does NOT specify a Link Quality Monitoring "policy" -- how to judge link quality or what to do when it is inadequate. That is left as an implementation decision, and can be different at each end of the link. Implementations are allowed, and even encouraged, to experiment with various link quality policies. The Link Quality Monitoring mechanism specification insures that two implementations with different policies may communicate and interoperate. To allow flexible policies to be implemented, the PPP Link Quality Monitoring mechanism measures data loss in units of packets, octets, and Link-Quality-Reports. Each measurement is made separately for each half of the link, both inbound and outbound. All measurements are com. municated to both ends of the link so that each end of the link can implement its own link quality policy for both its outbound and inbound links. Finally, the Link Quality Monitoring protocol is designed to be implementable on many different kinds of systems. Although it may be common to implement PPP (and especially Link Quality Monitoring) as a single software process, multi-process implementations with hardware support are also envisioned. The PPP Link Quality Monitoring mechanism provides for this by careful definition of the Link- Quality-Report packet format, and by specifying reference points for all data transmission and reception measurements. 2.2. Counters Each Link Quality Monitoring implementation maintains counts of the number of packets and octets transmitted and successfully received, Simpson [Page 2] RFC 1333 PPP Link Quality Monitoring May 1992 and periodically transmits this information to its peer in a Link- Quality-Report packet. These counters are similar to sequence numbers; they are constantly increasing to give a "relative" indication of the number of packets and octets communicated across the outbound link. By comparing the values in successive Link-Quality-Reports, an LQR receiver can compute the "delta" number of packets and octets successfully communicated across the link. Comparing these absolute numbers then gives an indication of a link's quality. Relative numbers, rather than absolute, are transmitted because they greatly simplify link synchronization. The Link-Quality-Report uses the Interface counters defined by SNMP MIB-II [2]. These counters are not initialized to any particular value when the LCP enters the Establishment phase. In addition, the Link-Quality-Report requires the implementation of the following three unsigned, monotonically increas. ing counters which conform to the type and size requirements for SNMP MIB Counters [3]. OutLQRs OutLQRs is a 32-bit counter which increases by one for each tranmitted Link-Quality-Report packet. This counter MUST be set to zero when the LCP enters the Establishment phase, and MUST NOT be reset until the LCP leaves the Termination phase. This counter is incremented before it is inserted into the LQR packet. InLQRs InLQRs is a 32-bit counter which increases by one for each received Link-Quality-Report packet. This counter MUST be set to zero when the LCP enters the Establishment phase, and MUST NOT be reset until the LCP leaves the Termination phase. This counter is incremented before it is inserted (in an implementation dependent fashion) into the LQR packet. InGoodOctets InGoodOctets is a 32-bit counter which increases by the number of octets in each successfully received Data Link Layer packet. Unlike the MIB ifInOctets, octets for frames which 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 MUST NOT be reset until the LCP leaves the Termination phase. Simpson [Page 3] RFC 1333 PPP Link Quality Monitoring May 1992 2.3. Counting Packets and Octets The intent of the counters is to provide an indication of the amount of information passing over the link, rather than an actual measurement of the total bandwidth used. This specification is designed to yield the same count in various circumstances, such as when a separate device provides the framing and escaping mechanisms invisibly to the implementation, or a synchronous-to-asynchronous converter in the link changes between mechanisms. All octets which are included in 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. All other octets (such as additional flag sequences, and escape bits or octets) MUST NOT be counted. When inserting the packet and octet counts in the LQR, the counts MUST include the expected values for the LQR itself. 2.4. Processes The PPP Link Quality Monitoring 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 The Link-Manager process transmits and receives Link-Quality- Reports, and implements the desired link quality policy. LQR packets are transmitted at a constant rate, which is negotiated by the LCP Quality-Protocol Configuration Option. Mux The Mux process multiplexes packets from the various protocols (e.g., LCP, IP, XNS, etc.) into a single, sequential, and prioritized stream of packets. Link-Quality-Report packets MUST be given the highest possible priority to insure that link quality information is communicated in a timely manner. Simpson [Page 4] RFC 1333 PPP Link Quality Monitoring May 1992 Tx The Tx process maintains the MIB counters ifOutUniPackets and ifOutOctets, and the internal counter OutLQRs, which are used to measure the amount of data which is transmitted on the outbound link. When Tx processes a Link-Quality-Report packet, it inserts the values of these counters into the corresponding PeerOut... fields of the packet. The Tx process MUST follow the Mux process so that packets are counted in the order transmitted to the link. Rx The Rx process maintains the MIB counters ifInUniPackets, ifInDiscards, ifInErrors and IfInOctets, and the internal counters InLQRs and InGoodOctets, which are used to measure the amount of data which is received by the inbound link. When Rx processes a Link-Quality-Report packet, it inserts the values of these counters into the corresponding SaveIn... fields of the packet (in an implementation dependent manner). Demux The Demux process demultiplexes packets for the various protocols. The Demux process MUST follow the Rx process so that packets are counted in the order received from the link. Simpson [Page 5] RFC 1333 PPP Link Quality Monitoring May 1992 2.5. Configuration Option Format Description Implementations MUST be prepared to receive the Quality-Protocol Configuration Option for the Link-Quality-Report. However, negotiation is not required. Negotiation is only necessary when the implementation wishes to ensure that the peer transmits Link- Quality-Reports as opposed to some other Quality-Protocol, or else to prevent the peer from maintaining its own timer, or else to establish a maximum time between transmissions of Link-Quality- Reports. A summary of the Quality-Protocol Configuration Option format to negotiate the Link-Quality-Report is shown below. The fields are transmitted from 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 4 Length 8 Quality-Protocol c025 (hex) for Link-Quality-Report Reporting-Period The Reporting-Period field is four octets and indicates the maximum time in hundredths of seconds between transmission of packets. The peer MAY transmit packets at a faster rate than that which was negotiated. A value of zero indicates that the peer does not need to maintain a timer. Instead, the peer generates a LQR immediately upon receiving a LQR. A value of zero MUST be Nak'd by the peer with Simpson [Page 6] RFC 1333 PPP Link Quality Monitoring May 1992 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. Simpson [Page 7] RFC 1333 PPP Link Quality Monitoring May 1992 2.6. Packet Format Exactly one Link-Quality-Report packet is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c025 (Link-Quality-Report). A summary of the LQR packet format is shown below. The names of the fields are relative to the packet receiver, since it is the receiver who requested the packet in the Configuration Option. The fields are transmitted from 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are not actually transmitted over the inbound link. Rather, they are logically appended (in an implementation dependent manner) to the packet by the implementation's Rx process. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | SaveInLQRs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInPackets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInDiscards | Simpson [Page 8] RFC 1333 PPP Link Quality Monitoring May 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInErrors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SaveInOctets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Magic-Number The Magic-Number field is four octets and aids in detecting links which are in the looped-back condition. Unless modified by a Configuration Option, 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 ensure that the local end is not seeing its own Magic-Number and thus a looped-back link. See the Magic-Number Configuration Option for further explanation. LastOutLQRs The LastOutLQRs field is four octets, and is copied from the most recently received PeerOutLQRs on transmission. LastOutPackets The LastOutPackets field is four octets, and is copied from the most recently received PeerOutPackets on transmission. LastOutOctets The LastOutOctets field is four octets, and is copied from the most recently received PeerOutOctets on transmission. PeerInLQRs The PeerInLQRs field is four octets, and is copied from the most recently received SaveInLQRs on transmission. Whenever the PeerInLQRs field is disc. overed to be zero, the LastOut... fields are indeterminate, and the PeerIn... fields contain the initial values for the peer. PeerInPackets The PeerInPackets field is four octets, and is copied from the most recently received SaveInPackets on transmission. Simpson [Page 9] RFC 1333 PPP Link Quality Monitoring May 1992 PeerInDiscards The PeerInDiscards field is four octets, and is copied from the most recently received SaveInDiscards on transmission. PeerInErrors The PeerInErrors field is four octets, and is copied from the most recently received SaveInErrors on transmission. PeerInOctets The PeerInOctets field is four octets, and is copied from the most recently received SaveInOctets on transmission. PeerOutLQRs The PeerOutLQRs field is four octets, and is copied from OutLQRs on transmission. This number MUST include this LQR. PeerOutPackets The PeerOutPackets field is four octets, and is copied from the current MIB ifOutUniPackets and ifOutNUniPackets on transmission. This number MUST include this LQR. PeerOutOctets The PeerOutOctets field is four octets, and is copied from the current MIB ifOutOctets on transmission. This number MUST include this LQR. SaveInLQRs The SaveInLQRs field is four octets, and is copied from InLQRs on reception. This number MUST include this LQR. SaveInPackets The SaveInPackets field is four octets, and is copied from the current MIB ifInUniPackets and ifInNUniPackets on reception. This number MUST include this LQR. SaveInDiscards The SaveInDiscards field is four octets, and is copied from the current MIB ifInDiscards on reception. This number MUST include this LQR. Simpson [Page 10]