rfc1989.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/2 页

Network Working Group                                         W. Simpson
Request for Comments: 1989                                    Daydreamer
Obsoletes: 1333                                              August 1996
Category: Standards Track


                      PPP Link Quality Monitoring

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) 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 for
   transporting multi-protocol datagrams 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.

Table of Contents

     1.     Introduction ..........................................    2
     2.     Link Quality Monitoring ...............................    2
        2.1       Design Motivation ...............................    2
        2.2       Counters ........................................    3
        2.3       Counting Packets and Octets .....................    4
        2.4       Processes .......................................    5
        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 ......................................   15
     ACKNOWLEDGEMENTS .............................................   15
     REFERENCES ...................................................   15
     CHAIR'S ADDRESS ..............................................   16
     AUTHOR'S ADDRESS .............................................   16





Simpson                     Standards Track                     [Page 1]

RFC 1989              PPP Link Quality Monitoring            August 1996


1.  Introduction

   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 Link 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.

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.  For example, routers
   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 ensures that two implementations
   with different policies may communicate and interoperate.





Simpson                     Standards Track                     [Page 2]

RFC 1989              PPP Link Quality Monitoring            August 1996


   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 careful definition of the Link-Quality-Report
   packet format, and specifies 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,
   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].










Simpson                     Standards Track                     [Page 3]

RFC 1989              PPP Link Quality Monitoring            August 1996


   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.

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.






Simpson                     Standards Track                     [Page 4]

RFC 1989              PPP Link Quality Monitoring            August 1996


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.

   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



Simpson                     Standards Track                     [Page 5]

RFC 1989              PPP Link Quality Monitoring            August 1996


      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.

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





Simpson                     Standards Track                     [Page 6]

RFC 1989              PPP Link Quality Monitoring            August 1996


   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
      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                     Standards Track                     [Page 7]

RFC 1989              PPP Link Quality Monitoring            August 1996


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.










Simpson                     Standards Track                     [Page 8]