home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1989.txt < prev    next >
Text File  |  1996-08-14  |  29KB  |  900 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 1989                                    Daydreamer
  9. Obsoletes: 1333                                              August 1996
  10. Category: Standards Track
  11.  
  12.  
  13.                       PPP Link Quality Monitoring
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  26.    transporting multi-protocol datagrams over point-to-point links.
  27.  
  28.    PPP also defines an extensible Link Control Protocol, which allows
  29.    negotiation of a Quality Protocol for continuous monitoring of the
  30.    viability of the link.
  31.  
  32.    This document defines a protocol for generating Link-Quality-Reports.
  33.  
  34. Table of Contents
  35.  
  36.      1.     Introduction ..........................................    2
  37.      2.     Link Quality Monitoring ...............................    2
  38.         2.1       Design Motivation ...............................    2
  39.         2.2       Counters ........................................    3
  40.         2.3       Counting Packets and Octets .....................    4
  41.         2.4       Processes .......................................    5
  42.         2.5       Configuration Option Format .....................    6
  43.         2.6       Packet Format ...................................    8
  44.         2.7       Transmission of Reports .........................   12
  45.         2.8       Calculations ....................................   12
  46.         2.9       Failure Detection ...............................   13
  47.         2.10      Policy Suggestions ..............................   14
  48.      SECURITY CONSIDERATIONS ......................................   15
  49.      ACKNOWLEDGEMENTS .............................................   15
  50.      REFERENCES ...................................................   15
  51.      CHAIR'S ADDRESS ..............................................   16
  52.      AUTHOR'S ADDRESS .............................................   16
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                     Standards Track                     [Page 1]
  59.  
  60. RFC 1989              PPP Link Quality Monitoring            August 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    In order to establish communications over a point-to-point link, each
  66.    end of the PPP link must first send LCP packets to configure the data
  67.    link during Link Establishment phase.  During the Authentication and
  68.    Network-Layer Protocol phases, the link may be tested to determine if
  69.    quality is sufficient for operation.  This testing is completely
  70.    optional.
  71.  
  72.    If an implementation desires that the peer use some specific link
  73.    quality monitoring protocol, then it MUST negotiate the use of that
  74.    protocol using the Quality-Protocol Configuration Option during Link
  75.    Establishment phase.
  76.  
  77.    The negotiation mechanism is independent in each direction.  However,
  78.    if the peer agrees to send Quality-Protocol packets, it MUST
  79.    correctly process such packets on reception, even if it does not
  80.    request such packets or implement a monitoring policy.
  81.  
  82. 2.  Link Quality Monitoring
  83.  
  84.    Data communications links are rarely perfect.  Packets can be dropped
  85.    or corrupted for various reasons (line noise, equipment failure,
  86.    buffer overruns, etc.).  Sometimes, it is desirable to determine
  87.    when, and how often, the link is dropping data.  For example, routers
  88.    may want to temporarily allow another route to take precedence.  An
  89.    implementation may also have the option of disconnecting and
  90.    switching to an alternate link.  The process of determining data loss
  91.    is called "Link Quality Monitoring".
  92.  
  93. 2.1.  Design Motivation
  94.  
  95.    There are many different ways to measure link quality, and even more
  96.    ways to react to it.  Rather than specifying a single scheme, Link
  97.    Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
  98.    fully specifies the "mechanism" for Link Quality Monitoring by
  99.    defining the Link-Quality-Report (LQR) packet and specifying a
  100.    procedure for its use.
  101.  
  102.    PPP does NOT specify a Link Quality Monitoring "policy" -- how to
  103.    judge link quality or what to do when it is inadequate.  That is left
  104.    as an implementation decision, and can be different at each end of
  105.    the link.  Implementations are allowed, and even encouraged, to
  106.    experiment with various link quality policies.  The Link Quality
  107.    Monitoring mechanism specification ensures that two implementations
  108.    with different policies may communicate and interoperate.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Simpson                     Standards Track                     [Page 2]
  115.  
  116. RFC 1989              PPP Link Quality Monitoring            August 1996
  117.  
  118.  
  119.    To allow flexible policies to be implemented, the PPP Link Quality
  120.    Monitoring mechanism measures data loss in units of packets, octets,
  121.    and Link-Quality-Reports.  Each measurement is made separately for
  122.    each half of the link, both inbound and outbound.  All measurements
  123.    are communicated to both ends of the link, so that each end of the
  124.    link can implement its own link quality policy for both its outbound
  125.    and inbound links.
  126.  
  127.    Finally, the Link Quality Monitoring protocol is designed to be
  128.    implementable on many different kinds of systems.  Although it may be
  129.    common to implement PPP (and especially Link Quality Monitoring) as a
  130.    single software process, multi-process implementations with hardware
  131.    support are also envisioned.  The PPP Link Quality Monitoring
  132.    mechanism provides for careful definition of the Link-Quality-Report
  133.    packet format, and specifies reference points for all data
  134.    transmission and reception measurements.
  135.  
  136. 2.2.  Counters
  137.  
  138.    Each Link Quality Monitoring implementation maintains counts of the
  139.    number of packets and octets transmitted and successfully received,
  140.    and periodically transmits this information to its peer in a Link-
  141.    Quality-Report packet.
  142.  
  143.    These counters are similar to sequence numbers; they are constantly
  144.    increasing to give a "relative" indication of the number of packets
  145.    and octets communicated across the outbound link.  By comparing the
  146.    values in successive Link-Quality-Reports, an LQR receiver can
  147.    compute the "delta" number of packets and octets successfully
  148.    communicated across the link.  Comparing these absolute numbers then
  149.    gives an indication of a link's quality.  Relative numbers, rather
  150.    than absolute, are transmitted because they greatly simplify link
  151.    synchronization.
  152.  
  153.    The Link-Quality-Report uses the Interface counters defined by SNMP
  154.    MIB-II [2].  These counters are not initialized to any particular
  155.    value when the LCP enters the Establishment phase.
  156.  
  157.    In addition, the Link-Quality-Report requires the implementation of
  158.    the following three unsigned, monotonically increasing counters which
  159.    conform to the type and size requirements for SNMP MIB Counters [3].
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Simpson                     Standards Track                     [Page 3]
  171.  
  172. RFC 1989              PPP Link Quality Monitoring            August 1996
  173.  
  174.  
  175.    OutLQRs
  176.  
  177.       OutLQRs is a 32-bit counter which increases by one for each
  178.       tranmitted Link-Quality-Report packet.  This counter MUST be set
  179.       to zero when the LCP enters the Establishment phase, and MUST NOT
  180.       be reset until the LCP leaves the Termination phase.  This counter
  181.       is incremented before it is inserted into the LQR packet.
  182.  
  183.    InLQRs
  184.  
  185.       InLQRs is a 32-bit counter which increases by one for each
  186.       received Link-Quality-Report packet.  This counter MUST be set to
  187.       zero when the LCP enters the Establishment phase, and MUST NOT be
  188.       reset until the LCP leaves the Termination phase.  This counter is
  189.       incremented before it is inserted (in an implementation dependent
  190.       fashion) into the LQR packet.
  191.  
  192.    InGoodOctets
  193.  
  194.       InGoodOctets is a 32-bit counter which increases by the number of
  195.       octets in each successfully received Data Link Layer packet.
  196.       Unlike the MIB ifInOctets, octets for frames which are counted in
  197.       ifInDiscards and ifInErrors MUST NOT be counted.  This counter MAY
  198.       be set to any initial value when the LCP enters the Establishment
  199.       phase, but MUST NOT be reset until the LCP leaves the Termination
  200.       phase.
  201.  
  202. 2.3.  Counting Packets and Octets
  203.  
  204.    The intent of the counters is to provide an indication of the amount
  205.    of information passing over the link, rather than an actual
  206.    measurement of the total bandwidth used.  This specification is
  207.    designed to yield the same count in various circumstances, such as
  208.    when a separate device provides the framing and escaping mechanisms
  209.    invisibly to the implementation, or a synchronous-to-asynchronous
  210.    converter in the link changes between mechanisms.
  211.  
  212.    All octets which are included in the FCS calculation MUST be counted,
  213.    including the packet header, the information field, and any padding.
  214.    The FCS octets MUST also be counted, and one flag octet per frame
  215.    MUST be counted.  All other octets (such as additional flag
  216.    sequences, and escape bits or octets) MUST NOT be counted.
  217.  
  218.    When inserting the packet and octet counts in the LQR, the counts
  219.    MUST include the expected values for the LQR itself.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Simpson                     Standards Track                     [Page 4]
  227.  
  228. RFC 1989              PPP Link Quality Monitoring            August 1996
  229.  
  230.  
  231. 2.4.  Processes
  232.  
  233.    The PPP Link Quality Monitoring mechanism is described using a
  234.    "logical process" model.  As shown below, there are five logical
  235.    processes duplicated at each end of the duplex link.
  236.  
  237.    +---------+   +-------+   +----+ Outbound
  238.    |         |-->|  Mux  |-->| Tx |=========>
  239.    | Link-   |   +-------+   +----+
  240.    | Manager |
  241.    |         |   +-------+   +----+ Inbound
  242.    |         |<--| Demux |<--| Rx |<=========
  243.    +---------+   +-------+   +----+
  244.  
  245.  
  246.    Link-Manager
  247.  
  248.       The Link-Manager process transmits and receives Link-Quality-
  249.       Reports, and implements the desired link quality policy.  LQR
  250.       packets are transmitted at a constant rate, which is negotiated by
  251.       the LCP Quality-Protocol Configuration Option.
  252.  
  253.    Mux
  254.  
  255.       The Mux process multiplexes packets from the various protocols
  256.       (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
  257.       prioritized stream of packets.  Link-Quality-Report packets MUST
  258.       be given the highest possible priority to insure that link quality
  259.       information is communicated in a timely manner.
  260.  
  261.    Tx
  262.  
  263.       The Tx process maintains the MIB counters ifOutUniPackets and
  264.       ifOutOctets, and the internal counter OutLQRs, which are used to
  265.       measure the amount of data which is transmitted on the outbound
  266.       link.  When Tx processes a Link-Quality-Report packet, it inserts
  267.       the values of these counters into the corresponding PeerOut...
  268.       fields of the packet.  The Tx process MUST follow the Mux process
  269.       so that packets are counted in the order transmitted to the link.
  270.  
  271.    Rx
  272.  
  273.       The Rx process maintains the MIB counters ifInUniPackets,
  274.       ifInDiscards, ifInErrors and IfInOctets, and the internal counters
  275.       InLQRs and InGoodOctets, which are used to measure the amount of
  276.       data which is received by the inbound link.  When Rx processes a
  277.       Link-Quality-Report packet, it inserts the values of these
  278.       counters into the corresponding SaveIn... fields of the packet (in
  279.  
  280.  
  281.  
  282. Simpson                     Standards Track                     [Page 5]
  283.  
  284. RFC 1989              PPP Link Quality Monitoring            August 1996
  285.  
  286.  
  287.       an implementation dependent manner).
  288.  
  289.    Demux
  290.  
  291.       The Demux process demultiplexes packets for the various protocols.
  292.       The Demux process MUST follow the Rx process so that packets are
  293.       counted in the order received from the link.
  294.  
  295. 2.5.  Configuration Option Format
  296.  
  297.  
  298.    Description
  299.  
  300.       Implementations MUST be prepared to receive the Quality-Protocol
  301.       Configuration Option for the Link-Quality-Report.  However,
  302.       negotiation is not required.  Negotiation is only necessary when
  303.       the implementation wishes to ensure that the peer transmits Link-
  304.       Quality-Reports as opposed to some other Quality-Protocol, or else
  305.       to prevent the peer from maintaining its own timer, or else to
  306.       establish a maximum time between transmissions of Link-Quality-
  307.       Reports.
  308.  
  309.    A summary of the Quality-Protocol Configuration Option format to
  310.    negotiate the Link-Quality-Report is shown below.  The fields are
  311.    transmitted from left to right.
  312.  
  313.     0                   1                   2                   3
  314.     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
  315.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  316.    |     Type      |    Length     |        Quality-Protocol       |
  317.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  318.    |                      Reporting-Period                         |
  319.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  320.  
  321.  
  322.    Type
  323.  
  324.       4
  325.  
  326.    Length
  327.  
  328.       8
  329.  
  330.    Quality-Protocol
  331.  
  332.       c025 (hex) for Link-Quality-Report
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Simpson                     Standards Track                     [Page 6]
  339.  
  340. RFC 1989              PPP Link Quality Monitoring            August 1996
  341.  
  342.  
  343.    Reporting-Period
  344.  
  345.       The Reporting-Period field is four octets and indicates the
  346.       maximum time in hundredths of seconds between transmission of
  347.       packets.  The peer MAY transmit packets at a faster rate than that
  348.       which was negotiated.
  349.  
  350.       A value of zero indicates that the peer does not need to maintain
  351.       a timer.  Instead, the peer generates a LQR immediately upon
  352.       receiving a LQR.  A value of zero MUST be Nak'd by the peer with
  353.       an appropriate non-zero value when that peer has sent or will send
  354.       a Configure-Request packet containing the Quality-Protocol
  355.       Configuration Option for the Link-Quality-Report with a zero
  356.       Reporting-Period.
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Simpson                     Standards Track                     [Page 7]
  395.  
  396. RFC 1989              PPP Link Quality Monitoring            August 1996
  397.  
  398.  
  399. 2.6.  Packet Format
  400.  
  401.    Exactly one Link-Quality-Report packet is encapsulated in the
  402.    Information field of PPP Data Link Layer frames where the protocol
  403.    field indicates type hex c025 (Link-Quality-Report).  A summary of
  404.    the LQR packet format is shown below.  The names of the fields are
  405.    relative to the packet receiver, since it is the receiver who
  406.    requested the packet in the Configuration Option.  The fields are
  407.    transmitted from left to right.
  408.  
  409.     0                   1                   2                   3
  410.     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
  411.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  412.    |                         Magic-Number                          |
  413.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414.    |                         LastOutLQRs                           |
  415.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416.    |                        LastOutPackets                         |
  417.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  418.    |                        LastOutOctets                          |
  419.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  420.    |                         PeerInLQRs                            |
  421.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  422.    |                        PeerInPackets                          |
  423.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  424.    |                        PeerInDiscards                         |
  425.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  426.    |                        PeerInErrors                           |
  427.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  428.    |                        PeerInOctets                           |
  429.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  430.    |                         PeerOutLQRs                           |
  431.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  432.    |                        PeerOutPackets                         |
  433.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  434.    |                        PeerOutOctets                          |
  435.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  436.  
  437.    The following fields are not actually transmitted over the inbound
  438.    link.  Rather, they are logically appended (in an implementation
  439.    dependent manner) to the packet by the implementation's Rx process.
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Simpson                     Standards Track                     [Page 8]
  451.  
  452. RFC 1989              PPP Link Quality Monitoring            August 1996
  453.  
  454.  
  455.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  456.    |                         SaveInLQRs                            |
  457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.    |                        SaveInPackets                          |
  459.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.    |                        SaveInDiscards                         |
  461.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  462.    |                        SaveInErrors                           |
  463.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  464.    |                        SaveInOctets                           |
  465.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  466.  
  467.  
  468.    Magic-Number
  469.  
  470.       The Magic-Number field is four octets and aids in detecting links
  471.       which are in the looped-back condition.  Unless modified by a
  472.       Configuration Option, the Magic-Number MUST be transmitted as zero
  473.       and MUST be ignored on reception.  If Magic-Numbers have been
  474.       negotiated, incoming LQR packets SHOULD be checked to ensure that
  475.       the local end is not seeing its own Magic-Number and thus a
  476.       looped-back link.  See the Magic-Number Configuration Option for
  477.       further explanation.
  478.  
  479.    LastOutLQRs
  480.  
  481.       The LastOutLQRs field is four octets, and is copied from the most
  482.       recently received PeerOutLQRs on transmission.
  483.  
  484.    LastOutPackets
  485.  
  486.       The LastOutPackets field is four octets, and is copied from the
  487.       most recently received PeerOutPackets on transmission.
  488.  
  489.    LastOutOctets
  490.  
  491.       The LastOutOctets field is four octets, and is copied from the
  492.       most recently received PeerOutOctets on transmission.
  493.  
  494.    PeerInLQRs
  495.  
  496.       The PeerInLQRs field is four octets, and is copied from the most
  497.       recently received SaveInLQRs on transmission.
  498.  
  499.       Whenever the PeerInLQRs field is discovered to be zero, the
  500.       LastOut... fields are indeterminate, and the PeerIn... fields
  501.       contain the initial values for the peer.
  502.  
  503.  
  504.  
  505.  
  506. Simpson                     Standards Track                     [Page 9]
  507.  
  508. RFC 1989              PPP Link Quality Monitoring            August 1996
  509.  
  510.  
  511.    PeerInPackets
  512.  
  513.       The PeerInPackets field is four octets, and is copied from the
  514.       most recently received SaveInPackets on transmission.
  515.  
  516.    PeerInDiscards
  517.  
  518.       The PeerInDiscards field is four octets, and is copied from the
  519.       most recently received SaveInDiscards on transmission.
  520.  
  521.    PeerInErrors
  522.  
  523.       The PeerInErrors field is four octets, and is copied from the most
  524.       recently received SaveInErrors on transmission.
  525.  
  526.    PeerInOctets
  527.  
  528.       The PeerInOctets field is four octets, and is copied from the most
  529.       recently received SaveInOctets on transmission.
  530.  
  531.    PeerOutLQRs
  532.  
  533.       The PeerOutLQRs field is four octets, and is copied from OutLQRs
  534.       on transmission.  This number MUST include this LQR.
  535.  
  536.    PeerOutPackets
  537.  
  538.       The PeerOutPackets field is four octets, and is copied from the
  539.       current MIB ifOutUniPackets and ifOutNUniPackets on transmission.
  540.       This number MUST include this LQR.
  541.  
  542.    PeerOutOctets
  543.  
  544.       The PeerOutOctets field is four octets, and is copied from the
  545.       current MIB ifOutOctets on transmission.  This number MUST include
  546.       this LQR.
  547.  
  548.    SaveInLQRs
  549.  
  550.       The SaveInLQRs field is four octets, and is copied from InLQRs on
  551.       reception.  This number MUST include this LQR.
  552.  
  553.    SaveInPackets
  554.  
  555.       The SaveInPackets field is four octets, and is copied from the
  556.       current MIB ifInUniPackets and ifInNUniPackets on reception.  This
  557.       number MUST include this LQR.
  558.  
  559.  
  560.  
  561.  
  562. Simpson                     Standards Track                    [Page 10]
  563.  
  564. RFC 1989              PPP Link Quality Monitoring            August 1996
  565.  
  566.  
  567.    SaveInDiscards
  568.  
  569.       The SaveInDiscards field is four octets, and is copied from the
  570.       current MIB ifInDiscards on reception.  This number MUST include
  571.       this LQR.
  572.  
  573.    SaveInErrors
  574.  
  575.       The SaveInErrors field is four octets, and is copied from the
  576.       current MIB ifInErrors on reception.  This number MUST include
  577.       this LQR.
  578.  
  579.    SaveInOctets
  580.  
  581.       The SaveInOctets field is four octets, and is copied from the
  582.       current InGoodOctets on reception.  This number MUST include this
  583.       LQR.
  584.  
  585.       Note that InGoodOctets is not the same as the MIB ifInOctets
  586.       counter, as InGoodOctets does not include octets for packets which
  587.       are discards or errors.
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Simpson                     Standards Track                    [Page 11]
  619.  
  620. RFC 1989              PPP Link Quality Monitoring            August 1996
  621.  
  622.  
  623. 2.7.  Transmission of Reports
  624.  
  625.    When the PPP Link Control Protocol has reached the Opened state, the
  626.    Link Quality Monitoring process MAY commence sending Link-Quality-
  627.    Reports.  If a Protocol-Reject is received specifying a LQR packet,
  628.    the LQM process MUST cease sending LQRs.
  629.  
  630.    Usually, the LQR is transmitted when the LQR timer for the link
  631.    expires.  If no LQR timer is used, a LQR is generated upon receipt of
  632.    an incoming LQR.  The negotiation process ensures that at least one
  633.    side of the link is using a LQR timer.
  634.  
  635.    In addition, a LQR is generated whenever two successive LQRs are
  636.    received which have the same PeerInLQRs value.  This may indicate
  637.    that a LQR has been missed, or that the implementation is sending at
  638.    a significantly slower rate than the peer, or that the peer has
  639.    accelerated LQR generation to better quantify errors on the link.
  640.  
  641.    Whenever a LQR is sent, the LQR timer MUST be restarted.
  642.  
  643. 2.8.  Calculations
  644.  
  645.    Each time a Link-Quality-Report packet is received from the inbound
  646.    link, the Link-Manager can compare the associated fields.  The fields
  647.    of the previous LQR can be subtracted from the current LQR values to
  648.    obtain an absolute "delta", which allows comparision of the changes
  649.    seen by each end of the link.
  650.  
  651.    If the received PeerInLQRs field is zero, the LastOut... fields are
  652.    indeterminate, and the PeerIn... fields contain the initial values
  653.    for the peer.  No calculations using these fields can be performed at
  654.    this time.
  655.  
  656.    Implementation Note:
  657.  
  658.       The following counters wrap to zero when their maximum value is
  659.       reached.  Care must be taken to ensure that correct "delta"
  660.       calculations are performed at that time.
  661.  
  662.    The LastOutLQRs field may be directly compared with the PeerInLQRs
  663.    field to determine how many outbound LQRs have been lost.
  664.  
  665.    The LastOutLQRs field may be directly compared with the OutLQRs
  666.    counter to determine how many outbound LQRs are still in the
  667.    pipeline.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Simpson                     Standards Track                    [Page 12]
  675.  
  676. RFC 1989              PPP Link Quality Monitoring            August 1996
  677.  
  678.  
  679.    The change in PeerInPackets may be compared with the change in
  680.    LastOutPackets to determine the number of lost packets over the
  681.    outgoing link.
  682.  
  683.    The change in PeerInOctets may be compared with the change in
  684.    LastOutOctets to determine the number of lost octets over the
  685.    outgoing link.
  686.  
  687.    The change in SaveInPackets may be compared with the change in
  688.    PeerOutPackets to determine the number of lost packets over the
  689.    incoming link.
  690.  
  691.    The change in SaveInOctets may be compared with the change in
  692.    PeerOutOctets to determine the number of lost octets over the
  693.    incoming link.
  694.  
  695.    The change in the PeerInDiscards and PeerInErrors fields may be used
  696.    to determine whether packet loss is due to congestion in the peer
  697.    rather than physical link failure.
  698.  
  699. 2.9.  Failure Detection
  700.  
  701.    When the link is operating well in both directions of the link, the
  702.    LQR is superfluous.  The maximum time interval for transmitting LQRs
  703.    SHOULD be chosen to minimally interfere with active traffic.
  704.  
  705.    When there is a measurable loss of data in either direction, if the
  706.    overall throughput is adequate, conditions are not severe enough to
  707.    warrant dropping the link.  Sending LQRs faster will gain nothing,
  708.    except to measure peaks in the loss rate.  The time interval MUST be
  709.    chosen to be long enough to have a good smoothing effect on the data,
  710.    while short enough to ensure fast enough response to complete
  711.    failure.
  712.  
  713.    When the link is good incoming, but very bad outgoing, incoming LQRs
  714.    indicate a high loss on the outgoing side of the link.  Sending LQRs
  715.    faster won't help, because they are probably lost on the way to the
  716.    peer.
  717.  
  718.    When the link is good outgoing, but very bad incoming, incoming LRQs
  719.    will be frequently lost.  In this case, LQRs SHOULD be sent at a
  720.    faster rate.  This primarily relies on the peer to make an informed
  721.    policy decision.  The peer will also send LQRs in response (due to
  722.    the duplicate PeerInLQRs field), and some of those LQRs may
  723.    successfully arrive.
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Simpson                     Standards Track                    [Page 13]
  731.  
  732. RFC 1989              PPP Link Quality Monitoring            August 1996
  733.  
  734.  
  735.    When a LQR does not arrive within the time expected, or the LQR
  736.    received indicates that the links are truly bad, at least one
  737.    additional LQR SHOULD be sent.  An algorithmic decision requires at
  738.    least 2 round trip intervals.  The loss rate could be transient, due
  739.    to a heavily loaded link, or a lost outgoing LQR.
  740.  
  741. 2.10.  Policy Suggestions
  742.  
  743.    Link-Quality-Report packets provide a mechanism to determine the link
  744.    quality, but it is up to each implementation to decide when the link
  745.    is usable.  It is recommended that this policy implement some amount
  746.    of hysteresis so that the link does not bounce up and down.  One
  747.    policy is to use a K out of N algorithm.  In such an algorithm, there
  748.    must be K successes out of the last N periods for the link to be
  749.    considered of good quality.
  750.  
  751.    Procedures for recovery from poor quality links are unspecified and
  752.    may vary from implementation to implementation.  A suggested approach
  753.    is to immediately close all other Network-Layer protocols (i.e.,
  754.    cause IPCP to transmit a Terminate-Request), but to continue
  755.    transmitting Link-Quality-Reports.  Once the link quality again
  756.    reaches an acceptable level, Network-Layer protocols can be
  757.    reconfigured.
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Simpson                     Standards Track                    [Page 14]
  787.  
  788. RFC 1989              PPP Link Quality Monitoring            August 1996
  789.  
  790.  
  791. Security Considerations
  792.  
  793.    Security issues are not discussed in this memo.
  794.  
  795. Acknowledgements
  796.  
  797.    Some of the text in this document is taken from RFC 1172, by Drew
  798.    Perkins of Carnegie Mellon University, and by Russ Hobby of the
  799.    University of California at Davis.
  800.  
  801.    Special thanks to Craig Fox (Network Systems), and Karl Fox (Morning
  802.    Star Technologies), for design suggestions based on implementation
  803.    experience.
  804.  
  805. References
  806.  
  807.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  808.          51, RFC 1661, Daydreamer, July 1994.
  809.  
  810.    [2]   McCloghrie, K., and M. Rose, "Management Information Base for
  811.          Network Management of TCP/IP-based internets: MIB-II", STD
  812.          17, RFC 1213, March 1991.
  813.  
  814.    [3]   Rose, M., and K. McCloghrie, "Structure and Identification of
  815.          Management Information for TCP/IP-based Internets", STD 16,
  816.          RFC 1155, May 1990.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Simpson                     Standards Track                    [Page 15]
  843.  
  844. RFC 1989              PPP Link Quality Monitoring            August 1996
  845.  
  846.  
  847. Chair's Address
  848.  
  849.    The working group can be contacted via the current chair:
  850.  
  851.    Karl Fox
  852.    Ascend Communications
  853.    3518 Riverside Drive, Suite 101
  854.    Columbus, Ohio 43221
  855.  
  856.    EMail: karl@ascend.com
  857.  
  858. Author's Address
  859.  
  860.    Questions about this memo can also be directed to:
  861.  
  862.    William Allen Simpson
  863.    Daydreamer
  864.    Computer Systems Consulting Services
  865.    1384 Fontaine
  866.    Madison Heights, Michigan  48071
  867.  
  868.    Bill.Simpson@um.cc.umich.edu
  869.       bsimpson@MorningStar.com (prefered)
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Simpson                     Standards Track                    [Page 16]
  899.  
  900.