RFC relevance of monitoring

As per Relevance of the word monitoring, we have this rfc below:

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

PPP Link Quality

Status of this

This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited

The Point-to-Point Protocol (PPP) [1] provides a standard method
encapsulating Network Layer protocol information over point-to-
links. PPP also defines an extensible Link Control Protocol,
allows negotiation of a Quality Protocol for continuous monitoring
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
the Internet Engineering Task Force (IETF). Comments on this
should be submitted to the ietf-ppp@ucdavis.edu mailing list

Simpson [Page i

RFC 1333 PPP Link Quality Monitoring May 1992

Table of

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.

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
and configuring different network-layer protocols

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

Simpson [Page 1]

RFC 1333 PPP Link Quality Monitoring May 1992

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. Routers,
example, may want to temporarily allow another route to
precedence. An implementation may also have the option
disconnecting and switching to an alternate link. The process
determining data loss 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
Monitoring "policy" -- how to judge link quality or what to do
it is inadequate. That is left as an implementation decision,
can be different at each end of the link. Implementations
allowed, and even encouraged, to experiment with various link
policies. The Link Quality Monitoring mechanism
insures that two implementations with different policies
communicate and interoperate

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 this by careful definition of the Link
Quality-Report packet format, and by specifying reference points
all data transmission and reception measurements

2.2.

Each Link Quality Monitoring implementation maintains counts of
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
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].

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

Simpson [Page 3]

RFC 1333 PPP Link Quality Monitoring May 1992

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

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

Simpson [Page 4]

RFC 1333 PPP Link Quality Monitoring May 1992

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

Simpson [Page 5]

RFC 1333 PPP Link Quality Monitoring May 1992

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-

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

Simpson [Page 6]

RFC 1333 PPP Link Quality Monitoring May 1992

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 [Page 7]

RFC 1333 PPP Link Quality Monitoring May 1992

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInLQRs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInPackets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SaveInDiscards |

Simpson [Page 8]

RFC 1333 PPP Link Quality Monitoring May 1992

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

The PeerInPackets field is four octets, and is copied from
most recently received SaveInPackets on transmission

Simpson [Page 9]

RFC 1333 PPP Link Quality Monitoring May 1992

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

The SaveInDiscards field is four octets, and is copied from
current MIB ifInDiscards on reception. This number MUST
this LQR

Simpson [Page 10]

RFC 1333 PPP Link Quality Monitoring May 1992

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 [Page 11]

RFC 1333 PPP Link Quality Monitoring May 1992

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

The change in PeerInPackets may be compared with the change
LastOutPackets to determine the number of lost packets over

Simpson [Page 12]

RFC 1333 PPP Link Quality Monitoring May 1992

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

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,

Simpson [Page 13]

RFC 1333 PPP Link Quality Monitoring May 1992

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

Security

Security issues are not discussed in this memo

[1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.

[2] McCloghrie, K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets: MIB-II",
1213, March 1991.

[3] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", RFC 1155,
May 1990.

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

Simpson [Page 14]

RFC 1333 PPP Link Quality Monitoring May 1992

Chair's

The working group can be contacted via the current chair

Brian
Lloyd &
3420 Sudbury
Cameron Park, California 95682

Phone: (916) 676-1147

EMail: brian@ray.lloyd.

Author's

Questions about this memo can also be directed to

William Allen

Computer Systems Consulting
P O Box 6205
East Lansing, MI 48826-6025

EMail: bsimpson@ray.lloyd.

Simpson [Page 15]

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