rfc1333.txt

改文件中包含了三个协议

Network Working Group                                         W. Simpson
Request for Comments: 1333                                    Daydreamer
                                                                May 1992



                      PPP Link Quality Monitoring



Status 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 [e-mail] mailing list.




















Simpson                                                         [Page i]

RFC 1333              PPP Link Quality Monitoring               May 1992


Table 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 .............................................   15

























Simpson                                                        [Page ii]

RFC 1333              PPP Link Quality Monitoring               May 1992


1.  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 1992


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


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.

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 1992


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

   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



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