rfc1333.txt

RFC 的详细文档！

      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 1992


2.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 the



Simpson                                                        [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, due



Simpson                                                        [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 1992


Chair's Address

   The working group can be contacted via the current chair:

      Brian Lloyd
      Lloyd & Associates
      3420 Sudbury Road
      Cameron Park, California 95682

      Phone: [phone]

      EMail: [e-mail]



Author'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: [e-mail]

























Simpson                                                        [Page 15]