Network Working Group                                         W. SimpsonRequest for Comments: 1333                                    Daydreamer                                                                May 1992                      PPP Link Quality MonitoringStatus 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 1992Table 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 .............................................   15Simpson                                                        [Page ii]RFC 1333              PPP Link Quality Monitoring               May 19921.  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 packets 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 19922.  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 communicated 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 increasing 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 19922.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 19922.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 withSimpson                                                         [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.