As per Relevance of the word monitoring, we have this rfc below:
Network Working Group W.
Request for Comments: 1989
Obsoletes: 1333 August 1996
Category: Standards
PPP Link Quality
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
PPP also defines an extensible Link Control Protocol, which
negotiation of a Quality Protocol for continuous monitoring of
viability of the link
This document defines a protocol for generating Link-Quality-Reports
Table of
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.
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure the
link during Link Establishment phase. During the Authentication
Network-Layer Protocol phases, the link may be tested to determine
quality is sufficient for operation. This testing is
optional
If an implementation desires that the peer use some specific
quality monitoring protocol, then it MUST negotiate the use of
protocol using the Quality-Protocol Configuration Option during
Establishment phase
The negotiation mechanism is independent in each direction. However
if the peer agrees to send Quality-Protocol packets, it
correctly process such packets on reception, even if it does
request such packets or implement a monitoring policy
2. Link Quality
Data communications links are rarely perfect. Packets can be
or corrupted for various reasons (line noise, equipment failure
buffer overruns, etc.). Sometimes, it is desirable to
when, and how often, the link is dropping data. For example,
may want to temporarily allow another route to take precedence.
implementation may also have the option of disconnecting
switching to an alternate link. The process of determining data
is called "Link Quality Monitoring".
2.1. Design
There are many different ways to measure link quality, and even
ways to react to it. Rather than specifying a single scheme,
Quality Monitoring is divided into a "mechanism" and a "policy".
fully specifies the "mechanism" for Link Quality Monitoring
defining the Link-Quality-Report (LQR) packet and specifying
procedure for its use
PPP does NOT specify a Link Quality Monitoring "policy" -- how
judge link quality or what to do when it is inadequate. That is
as an implementation decision, and can be different at each end
the link. Implementations are allowed, and even encouraged,
experiment with various link quality policies. The Link
Monitoring mechanism specification ensures that two
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
Monitoring mechanism measures data loss in units of packets, octets
and Link-Quality-Reports. Each measurement is made separately
each half of the link, both inbound and outbound. All
are communicated to both ends of the link, so that each end of
link can implement its own link quality policy for both its
and inbound links
Finally, the Link Quality Monitoring protocol is designed to
implementable on many different kinds of systems. Although it may
common to implement PPP (and especially Link Quality Monitoring) as
single software process, multi-process implementations with
support are also envisioned. The PPP Link Quality
mechanism provides for careful definition of the Link-Quality-
packet format, and specifies reference points for all
transmission and reception measurements
2.2.
Each Link Quality Monitoring implementation maintains counts of
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
increasing to give a "relative" indication of the number of
and octets communicated across the outbound link. By comparing
values in successive Link-Quality-Reports, an LQR receiver
compute the "delta" number of packets and octets
communicated across the link. Comparing these absolute numbers
gives an indication of a link's quality. Relative numbers,
than absolute, are transmitted because they greatly simplify
synchronization
The Link-Quality-Report uses the Interface counters defined by
MIB-II [2]. These counters are not initialized to any
value when the LCP enters the Establishment phase
In addition, the Link-Quality-Report requires the implementation
the following three unsigned, monotonically increasing counters
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 is a 32-bit counter which increases by one for
tranmitted Link-Quality-Report packet. This counter MUST be
to zero when the LCP enters the Establishment phase, and MUST
be reset until the LCP leaves the Termination phase. This
is incremented before it is inserted into the LQR packet
InLQRs is a 32-bit counter which increases by one for
received Link-Quality-Report packet. This counter MUST be set
zero when the LCP enters the Establishment phase, and MUST NOT
reset until the LCP leaves the Termination phase. This counter
incremented before it is inserted (in an implementation
fashion) into the LQR packet
InGoodOctets is a 32-bit counter which increases by the number
octets in each successfully received Data Link Layer packet
Unlike the MIB ifInOctets, octets for frames which are counted
ifInDiscards and ifInErrors MUST NOT be counted. This counter
be set to any initial value when the LCP enters the
phase, but MUST NOT be reset until the LCP leaves the
phase
2.3. Counting Packets and
The intent of the counters is to provide an indication of the
of information passing over the link, rather than an
measurement of the total bandwidth used. This specification
designed to yield the same count in various circumstances, such
when a separate device provides the framing and escaping
invisibly to the implementation, or a synchronous-to-
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
MUST be counted. All other octets (such as additional
sequences, and escape bits or octets) MUST NOT be counted
When inserting the packet and octet counts in the LQR, the
MUST include the expected values for the LQR itself
Simpson Standards Track [Page 4]
RFC 1989 PPP Link Quality Monitoring August 1996
2.4.
The PPP Link Quality Monitoring mechanism is described using
"logical process" model. As shown below, there are five
processes duplicated at each end of the duplex link
+---------+ +-------+ +----+
| |-->| Mux |-->| Tx |=========>
| Link- | +-------+ +----+
| Manager |
| | +-------+ +----+
| |<--| Demux |<--| Rx |<=========
+---------+ +-------+ +----+
Link-
The Link-Manager process transmits and receives Link-Quality
Reports, and implements the desired link quality policy.
packets are transmitted at a constant rate, which is negotiated
the LCP Quality-Protocol Configuration Option
The Mux process multiplexes packets from the various
(e.g., LCP, IP, XNS, etc.) into a single, sequential,
prioritized stream of packets. Link-Quality-Report packets
be given the highest possible priority to insure that link
information is communicated in a timely manner
The Tx process maintains the MIB counters ifOutUniPackets
ifOutOctets, and the internal counter OutLQRs, which are used
measure the amount of data which is transmitted on the
link. When Tx processes a Link-Quality-Report packet, it
the values of these counters into the corresponding PeerOut...
fields of the packet. The Tx process MUST follow the Mux
so that packets are counted in the order transmitted to the link
The Rx process maintains the MIB counters ifInUniPackets
ifInDiscards, ifInErrors and IfInOctets, and the internal
InLQRs and InGoodOctets, which are used to measure the amount
data which is received by the inbound link. When Rx processes
Link-Quality-Report packet, it inserts the values of
counters into the corresponding SaveIn... fields of the packet (
Simpson Standards Track [Page 5]
RFC 1989 PPP Link Quality Monitoring August 1996
an implementation dependent manner).
The Demux process demultiplexes packets for the various protocols
The Demux process MUST follow the Rx process so that packets
counted in the order received from the link
2.5. Configuration Option
Implementations MUST be prepared to receive the Quality-
Configuration Option for the Link-Quality-Report. However
negotiation is not required. Negotiation is only necessary
the implementation wishes to ensure that the peer transmits Link
Quality-Reports as opposed to some other Quality-Protocol, or
to prevent the peer from maintaining its own timer, or else
establish a maximum time between transmissions of Link-Quality
Reports
A summary of the Quality-Protocol Configuration Option format
negotiate the Link-Quality-Report is shown below. The fields
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4
8
Quality-
c025 (hex) for Link-Quality-
Simpson Standards Track [Page 6]
RFC 1989 PPP Link Quality Monitoring August 1996
Reporting-
The Reporting-Period field is four octets and indicates
maximum time in hundredths of seconds between transmission
packets. The peer MAY transmit packets at a faster rate than
which was negotiated
A value of zero indicates that the peer does not need to
a timer. Instead, the peer generates a LQR immediately
receiving a LQR. A value of zero MUST be Nak'd by the peer
an appropriate non-zero value when that peer has sent or will
a Configure-Request packet containing the Quality-
Configuration Option for the Link-Quality-Report with a
Reporting-Period
Simpson Standards Track [Page 7]
RFC 1989 PPP Link Quality Monitoring August 1996
2.6. Packet
Exactly one Link-Quality-Report packet is encapsulated in
Information field of PPP Data Link Layer frames where the
field indicates type hex c025 (Link-Quality-Report). A summary
the LQR packet format is shown below. The names of the fields
relative to the packet receiver, since it is the receiver
requested the packet in the Configuration Option. The fields
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
link. Rather, they are logically appended (in an
dependent manner) to the packet by the implementation's Rx process
Simpson Standards Track [Page 8]
RFC 1989 PPP Link Quality Monitoring August 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInDiscards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInErrors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInOctets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-
The Magic-Number field is four octets and aids in detecting
which are in the looped-back condition. Unless modified by
Configuration Option, the Magic-Number MUST be transmitted as
and MUST be ignored on reception. If Magic-Numbers have
negotiated, incoming LQR packets SHOULD be checked to ensure
the local end is not seeing its own Magic-Number and thus
looped-back link. See the Magic-Number Configuration Option
further explanation
The LastOutLQRs field is four octets, and is copied from the
recently received PeerOutLQRs on transmission
The LastOutPackets field is four octets, and is copied from
most recently received PeerOutPackets on transmission
The LastOutOctets field is four octets, and is copied from
most recently received PeerOutOctets on transmission
The PeerInLQRs field is four octets, and is copied from the
recently received SaveInLQRs on transmission
Whenever the PeerInLQRs field is discovered to be zero,
LastOut... fields are indeterminate, and the PeerIn...
contain the initial values for the peer
Simpson Standards Track [Page 9]
RFC 1989 PPP Link Quality Monitoring August 1996
The PeerInPackets field is four octets, and is copied from
most recently received SaveInPackets on transmission
The PeerInDiscards field is four octets, and is copied from
most recently received SaveInDiscards on transmission
The PeerInErrors field is four octets, and is copied from the
recently received SaveInErrors on transmission
The PeerInOctets field is four octets, and is copied from the
recently received SaveInOctets on transmission
The PeerOutLQRs field is four octets, and is copied from
on transmission. This number MUST include this LQR
The PeerOutPackets field is four octets, and is copied from
current MIB ifOutUniPackets and ifOutNUniPackets on transmission
This number MUST include this LQR
The PeerOutOctets field is four octets, and is copied from
current MIB ifOutOctets on transmission. This number MUST
this LQR
The SaveInLQRs field is four octets, and is copied from InLQRs
reception. This number MUST include this LQR
The SaveInPackets field is four octets, and is copied from
current MIB ifInUniPackets and ifInNUniPackets on reception.
number MUST include this LQR
Simpson Standards Track [Page 10]
RFC 1989 PPP Link Quality Monitoring August 1996
The SaveInDiscards field is four octets, and is copied from
current MIB ifInDiscards on reception. This number MUST
this LQR
The SaveInErrors field is four octets, and is copied from
current MIB ifInErrors on reception. This number MUST
this LQR
The SaveInOctets field is four octets, and is copied from
current InGoodOctets on reception. This number MUST include
LQR
Note that InGoodOctets is not the same as the MIB
counter, as InGoodOctets does not include octets for packets
are discards or errors
Simpson Standards Track [Page 11]
RFC 1989 PPP Link Quality Monitoring August 1996
2.7. Transmission of
When the PPP Link Control Protocol has reached the Opened state,
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
expires. If no LQR timer is used, a LQR is generated upon receipt
an incoming LQR. The negotiation process ensures that at least
side of the link is using a LQR timer
In addition, a LQR is generated whenever two successive LQRs
received which have the same PeerInLQRs value. This may
that a LQR has been missed, or that the implementation is sending
a significantly slower rate than the peer, or that the peer
accelerated LQR generation to better quantify errors on the link
Whenever a LQR is sent, the LQR timer MUST be restarted
2.8.
Each time a Link-Quality-Report packet is received from the
link, the Link-Manager can compare the associated fields. The
of the previous LQR can be subtracted from the current LQR values
obtain an absolute "delta", which allows comparision of the
seen by each end of the link
If the received PeerInLQRs field is zero, the LastOut... fields
indeterminate, and the PeerIn... fields contain the initial
for the peer. No calculations using these fields can be performed
this time
Implementation Note
The following counters wrap to zero when their maximum value
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
field to determine how many outbound LQRs have been lost
The LastOutLQRs field may be directly compared with the
counter to determine how many outbound LQRs are still in
pipeline
Simpson Standards Track [Page 12]
RFC 1989 PPP Link Quality Monitoring August 1996
The change in PeerInPackets may be compared with the change
LastOutPackets to determine the number of lost packets over
outgoing link
The change in PeerInOctets may be compared with the change
LastOutOctets to determine the number of lost octets over
outgoing link
The change in SaveInPackets may be compared with the change
PeerOutPackets to determine the number of lost packets over
incoming link
The change in SaveInOctets may be compared with the change
PeerOutOctets to determine the number of lost octets over
incoming link
The change in the PeerInDiscards and PeerInErrors fields may be
to determine whether packet loss is due to congestion in the
rather than physical link failure
2.9. Failure
When the link is operating well in both directions of the link,
LQR is superfluous. The maximum time interval for transmitting
SHOULD be chosen to minimally interfere with active traffic
When there is a measurable loss of data in either direction, if
overall throughput is adequate, conditions are not severe enough
warrant dropping the link. Sending LQRs faster will gain nothing
except to measure peaks in the loss rate. The time interval MUST
chosen to be long enough to have a good smoothing effect on the data
while short enough to ensure fast enough response to
failure
When the link is good incoming, but very bad outgoing, incoming
indicate a high loss on the outgoing side of the link. Sending
faster won't help, because they are probably lost on the way to
peer
When the link is good outgoing, but very bad incoming, incoming
will be frequently lost. In this case, LQRs SHOULD be sent at
faster rate. This primarily relies on the peer to make an
policy decision. The peer will also send LQRs in response (due
the duplicate PeerInLQRs field), and some of those LQRs
successfully arrive
Simpson Standards Track [Page 13]
RFC 1989 PPP Link Quality Monitoring August 1996
When a LQR does not arrive within the time expected, or the
received indicates that the links are truly bad, at least
additional LQR SHOULD be sent. An algorithmic decision requires
least 2 round trip intervals. The loss rate could be transient,
to a heavily loaded link, or a lost outgoing LQR
2.10. Policy
Link-Quality-Report packets provide a mechanism to determine the
quality, but it is up to each implementation to decide when the
is usable. It is recommended that this policy implement some
of hysteresis so that the link does not bounce up and down.
policy is to use a K out of N algorithm. In such an algorithm,
must be K successes out of the last N periods for the link to
considered of good quality
Procedures for recovery from poor quality links are unspecified
may vary from implementation to implementation. A suggested
is to immediately close all other Network-Layer protocols (i.e.,
cause IPCP to transmit a Terminate-Request), but to
transmitting Link-Quality-Reports. Once the link quality
reaches an acceptable level, Network-Layer protocols can
reconfigured
Simpson Standards Track [Page 14]
RFC 1989 PPP Link Quality Monitoring August 1996
Security
Security issues are not discussed in this memo
Some of the text in this document is taken from RFC 1172, by
Perkins of Carnegie Mellon University, and by Russ Hobby of
University of California at Davis
Special thanks to Craig Fox (Network Systems), and Karl Fox (
Star Technologies), for design suggestions based on
experience
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, Daydreamer, July 1994.
[2] McCloghrie, K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets: MIB-II",
17, RFC 1213, March 1991.
[3] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", STD 16,
RFC 1155, May 1990.
Simpson Standards Track [Page 15]
RFC 1989 PPP Link Quality Monitoring August 1996
Chair's
The working group can be contacted via the current chair
Karl
Ascend
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.com (prefered
Simpson Standards Track [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
