Simpson                                                         [Page 7]RFC 1333              PPP Link Quality Monitoring               May 19922.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 discovered 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]RFC 1333              PPP Link Quality Monitoring               May 1992   SaveInErrors      The SaveInErrors field is four octets, and is copied from the      current MIB ifInErrors on reception.  This number MUST include      this LQR.   SaveInOctets      The SaveInOctets field is four octets, and is copied from the      current InGoodOctets on reception.  This number MUST include this      LQR.      Note that InGoodOctets is not the same as the MIB ifInOctets      counter, as InGoodOctets does not include octets for packets which      are discards or errors.Simpson                                                        [Page 11]RFC 1333              PPP Link Quality Monitoring               May 19922.7.  Transmission of Reports   When the PPP Link Control Protocol has reached the Opened state, the   Link Quality Monitoring process MAY commence sending Link-Quality-   Reports.  If a Protocol-Reject is received specifying a LQR packet,   the LQM process MUST cease sending LQRs.   Usually, the LQR is transmitted when the LQR timer for the link   expires.  If no LQR timer is used, a LQR is generated upon receipt of   an incoming LQR.  The negotiation process ensures that at least one   side of the link is using a LQR timer.   In addition, a LQR is generated whenever two successive LQRs are   received which have the same PeerInLQRs value.  This may indicate   that a LQR has been missed, or that the implementation is sending at   a significantly slower rate than the peer, or that the peer has   accelerated LQR generation to better quantify errors on the link.   Whenever a LQR is sent, the LQR timer MUST be restarted.2.8.  Calculations   Each time a Link-Quality-Report packet is received from the inbound   link, the Link-Manager can compare the associated fields.  The fields   of the previous LQR can be subtracted from the current LQR values to   obtain an absolute "delta", which allows comparision of the changes   seen by each end of the link.   If the received PeerInLQRs field is zero, the LastOut... fields are   indeterminate, and the PeerIn... fields contain the initial values   for the peer.  No calculations using these fields can be performed at   this time.   Implementation Note:      The following counters wrap to zero when their maximum value is      reached.  Care must be taken to ensure that correct "delta"      calculations are performed at that time.   The LastOutLQRs field may be directly compared with the PeerInLQRs   field to determine how many outbound LQRs have been lost.   The LastOutLQRs field may be directly compared with the OutLQRs   counter to determine how many outbound LQRs are still in the   pipeline.   The change in PeerInPackets may be compared with the change in   LastOutPackets to determine the number of lost packets over theSimpson                                                        [Page 12]RFC 1333              PPP Link Quality Monitoring               May 1992   outgoing link.   The change in PeerInOctets may be compared with the change in   LastOutOctets to determine the number of lost octets over the   outgoing link.   The change in SaveInPackets may be compared with the change in   PeerOutPackets to determine the number of lost packets over the   incoming link.   The change in SaveInOctets may be compared with the change in   PeerOutOctets to determine the number of lost octets over the   incoming link.   The change in the PeerInDiscards and PeerInErrors fields may be used   to determine whether packet loss is due to congestion in the peer   rather than physical link failure.2.9.  Failure Detection   When the link is operating well in both directions of the link, the   LQR is superfluous.  The maximum time interval for transmitting LQRs   SHOULD be chosen to minimally interfere with active traffic.   When there is a measurable loss of data in either direction, if the   overall throughput is adequate, conditions are not severe enough to   warrant dropping the link.  Sending LQRs faster will gain nothing,   except to measure peaks in the loss rate.  The time interval MUST be   chosen to be long enough to have a good smoothing effect on the data,   while short enough to ensure fast enough response to complete   failure.   When the link is good incoming, but very bad outgoing, incoming LQRs   indicate a high loss on the outgoing side of the link.  Sending LQRs   faster won't help, because they are probably lost on the way to the   peer.   When the link is good outgoing, but very bad incoming, incoming LRQs   will be frequently lost.  In this case, LQRs SHOULD be sent at a   faster rate.  This primarily relies on the peer to make an informed   policy decision.  The peer will also send LQRs in response (due to   the duplicate PeerInLQRs field), and some of those LQRs may   successfully arrive.   When a LQR does not arrive within the time expected, or the LQR   received indicates that the links are truly bad, at least one   additional LQR SHOULD be sent.  An algorithmic decision requires at   least 2 round trip intervals.  The loss rate could be transient, dueSimpson                                                        [Page 13]RFC 1333              PPP Link Quality Monitoring               May 1992   to a heavily loaded link, or a lost outgoing LQR.2.10.  Policy Suggestions   Link-Quality-Report packets provide a mechanism to determine the link   quality, but it is up to each implementation to decide when the link   is usable.  It is recommended that this policy implement some amount   of hysteresis so that the link does not bounce up and down.  One   policy is to use a K out of N algorithm.  In such an algorithm, there   must be K successes out of the last N periods for the link to be   considered of good quality.   Procedures for recovery from poor quality links are unspecified and   may vary from implementation to implementation.  A suggested approach   is to immediately close all other Network-Layer protocols (i.e.,   cause IPCP to transmit a Terminate-Request), but to continue   transmitting Link-Quality-Reports.  Once the link quality again   reaches an acceptable level, Network-Layer protocols can be   reconfigured.Security Considerations   Security issues are not discussed in this memo.References   [1]   Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.   [2]   McCloghrie, K., and M. Rose, "Management Information Base for         Network Management of TCP/IP-based internets: MIB-II", RFC         1213, March 1991.   [3]   Rose, M., and K. McCloghrie, "Structure and Identification of         Management Information for TCP/IP-based Internets", RFC 1155,         May 1990.Acknowledgments   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.Simpson                                                        [Page 14]RFC 1333              PPP Link Quality Monitoring               May 1992Chair's Address   The working group can be contacted via the current chair:      Brian Lloyd      Lloyd & Associates      3420 Sudbury Road      Cameron Park, California 95682      Phone: (916) 676-1147      EMail: brian@ray.lloyd.comAuthor's Address   Questions about this memo can also be directed to:      William Allen Simpson      Daydreamer      Computer Systems Consulting Services      P O Box 6205      East Lansing, MI  48826-6025      EMail: bsimpson@ray.lloyd.comSimpson                                                        [Page 15]