rfc1333.txt

RFC 的详细文档！

   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.















































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


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.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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