idnits 2.17.1 draft-ietf-pppext-lqm-ds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 59: '...rotocol, then it MUST negotiate the us...' RFC 2119 keyword, line 64: '...send Quality-Protocol packets, it MUST...' RFC 2119 keyword, line 142: '...port packet. This counter MUST be set...' RFC 2119 keyword, line 143: '... the Establishment phase, and MUST NOT...' RFC 2119 keyword, line 150: '...t packet. This counter MUST be set to...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson 3 Internet Draft Daydreamer 4 expires in six months November 1995 6 PPP Link Quality Monitoring 7 draft-ietf-pppext-lqm-ds-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Abstract 40 The Point-to-Point Protocol (PPP) [1] provides a standard method for 41 transporting multi-protocol datagrams over point-to-point links. 43 PPP also defines an extensible Link Control Protocol, which allows 44 negotiation of a Quality Protocol for continuous monitoring of the 45 viability of the link. 47 This document defines a protocol for generating Link-Quality-Reports. 49 1. Introduction 51 In order to establish communications over a point-to-point link, each 52 end of the PPP link must first send LCP packets to configure the data 53 link during Link Establishment phase. During the Authentication and 54 Network-Layer Protocol phases, the link may be tested to determine if 55 quality is sufficient for operation. This testing is completely 56 optional. 58 If an implementation desires that the peer use some specific link 59 quality monitoring protocol, then it MUST negotiate the use of that 60 protocol using the Quality-Protocol Configuration Option during Link 61 Establishment phase. 63 The negotiation mechanism is independent in each direction. However, 64 if the peer agrees to send Quality-Protocol packets, it MUST 65 correctly process such packets on reception, even if it does not 66 request such packets or implement a monitoring policy. 68 2. Link Quality Monitoring 70 Data communications links are rarely perfect. Packets can be dropped 71 or corrupted for various reasons (line noise, equipment failure, 72 buffer overruns, etc.). Sometimes, it is desirable to determine 73 when, and how often, the link is dropping data. For example, routers 74 may want to temporarily allow another route to take precedence. An 75 implementation may also have the option of disconnecting and 76 switching to an alternate link. The process of determining data loss 77 is called "Link Quality Monitoring". 79 2.1. Design Motivation 81 There are many different ways to measure link quality, and even more 82 ways to react to it. Rather than specifying a single scheme, Link 83 Quality Monitoring is divided into a "mechanism" and a "policy". 85 PPP fully specifies the "mechanism" for Link Quality Monitoring by 86 defining the Link-Quality-Report (LQR) packet and specifying a 87 procedure for its use. 89 PPP does NOT specify a Link Quality Monitoring "policy" -- how to 90 judge link quality or what to do when it is inadequate. That is left 91 as an implementation decision, and can be different at each end of 92 the link. Implementations are allowed, and even encouraged, to 93 experiment with various link quality policies. The Link Quality 94 Monitoring mechanism specification ensures that two implementations 95 with different policies may communicate and interoperate. 97 To allow flexible policies to be implemented, the PPP Link Quality 98 Monitoring mechanism measures data loss in units of packets, octets, 99 and Link-Quality-Reports. Each measurement is made separately for 100 each half of the link, both inbound and outbound. All measurements 101 are communicated to both ends of the link, so that each end of the 102 link can implement its own link quality policy for both its outbound 103 and inbound links. 105 Finally, the Link Quality Monitoring protocol is designed to be 106 implementable on many different kinds of systems. Although it may be 107 common to implement PPP (and especially Link Quality Monitoring) as a 108 single software process, multi-process implementations with hardware 109 support are also envisioned. The PPP Link Quality Monitoring 110 mechanism provides for careful definition of the Link-Quality-Report 111 packet format, and specifies reference points for all data 112 transmission and reception measurements. 114 2.2. Counters 116 Each Link Quality Monitoring implementation maintains counts of the 117 number of packets and octets transmitted and successfully received, 118 and periodically transmits this information to its peer in a Link- 119 Quality-Report packet. 121 These counters are similar to sequence numbers; they are constantly 122 increasing to give a "relative" indication of the number of packets 123 and octets communicated across the outbound link. By comparing the 124 values in successive Link-Quality-Reports, an LQR receiver can 125 compute the "delta" number of packets and octets successfully 126 communicated across the link. Comparing these absolute numbers then 127 gives an indication of a link's quality. Relative numbers, rather 128 than absolute, are transmitted because they greatly simplify link 129 synchronization. 131 The Link-Quality-Report uses the Interface counters defined by SNMP 132 MIB-II [2]. These counters are not initialized to any particular 133 value when the LCP enters the Establishment phase. 135 In addition, the Link-Quality-Report requires the implementation of 136 the following three unsigned, monotonically increasing counters which 137 conform to the type and size requirements for SNMP MIB Counters [3]. 139 OutLQRs 141 OutLQRs is a 32-bit counter which increases by one for each 142 tranmitted Link-Quality-Report packet. This counter MUST be set 143 to zero when the LCP enters the Establishment phase, and MUST NOT 144 be reset until the LCP leaves the Termination phase. This counter 145 is incremented before it is inserted into the LQR packet. 147 InLQRs 149 InLQRs is a 32-bit counter which increases by one for each 150 received Link-Quality-Report packet. This counter MUST be set to 151 zero when the LCP enters the Establishment phase, and MUST NOT be 152 reset until the LCP leaves the Termination phase. This counter is 153 incremented before it is inserted (in an implementation dependent 154 fashion) into the LQR packet. 156 InGoodOctets 158 InGoodOctets is a 32-bit counter which increases by the number of 159 octets in each successfully received Data Link Layer packet. 160 Unlike the MIB ifInOctets, octets for frames which are counted in 161 ifInDiscards and ifInErrors MUST NOT be counted. This counter MAY 162 be set to any initial value when the LCP enters the Establishment 163 phase, but MUST NOT be reset until the LCP leaves the Termination 164 phase. 166 2.3. Counting Packets and Octets 168 The intent of the counters is to provide an indication of the amount 169 of information passing over the link, rather than an actual 170 measurement of the total bandwidth used. This specification is 171 designed to yield the same count in various circumstances, such as 172 when a separate device provides the framing and escaping mechanisms 173 invisibly to the implementation, or a synchronous-to-asynchronous 174 converter in the link changes between mechanisms. 176 All octets which are included in the FCS calculation MUST be counted, 177 including the packet header, the information field, and any padding. 178 The FCS octets MUST also be counted, and one flag octet per frame 179 MUST be counted. All other octets (such as additional flag 180 sequences, and escape bits or octets) MUST NOT be counted. 182 When inserting the packet and octet counts in the LQR, the counts 183 MUST include the expected values for the LQR itself. 185 2.4. Processes 187 The PPP Link Quality Monitoring mechanism is described using a 188 "logical process" model. As shown below, there are five logical 189 processes duplicated at each end of the duplex link. 191 +---------+ +-------+ +----+ Outbound 192 | |-->| Mux |-->| Tx |=========> 193 | Link- | +-------+ +----+ 194 | Manager | 195 | | +-------+ +----+ Inbound 196 | |<--| Demux |<--| Rx |<========= 197 +---------+ +-------+ +----+ 199 Link-Manager 201 The Link-Manager process transmits and receives Link-Quality- 202 Reports, and implements the desired link quality policy. LQR 203 packets are transmitted at a constant rate, which is negotiated by 204 the LCP Quality-Protocol Configuration Option. 206 Mux 208 The Mux process multiplexes packets from the various protocols 209 (e.g., LCP, IP, XNS, etc.) into a single, sequential, and 210 prioritized stream of packets. Link-Quality-Report packets MUST 211 be given the highest possible priority to insure that link quality 212 information is communicated in a timely manner. 214 Tx 216 The Tx process maintains the MIB counters ifOutUniPackets and 217 ifOutOctets, and the internal counter OutLQRs, which are used to 218 measure the amount of data which is transmitted on the outbound 219 link. When Tx processes a Link-Quality-Report packet, it inserts 220 the values of these counters into the corresponding PeerOut... 221 fields of the packet. The Tx process MUST follow the Mux process 222 so that packets are counted in the order transmitted to the link. 224 Rx 226 The Rx process maintains the MIB counters ifInUniPackets, 227 ifInDiscards, ifInErrors and IfInOctets, and the internal counters 228 InLQRs and InGoodOctets, which are used to measure the amount of 229 data which is received by the inbound link. When Rx processes a 230 Link-Quality-Report packet, it inserts the values of these 231 counters into the corresponding SaveIn... fields of the packet (in 232 an implementation dependent manner). 234 Demux 236 The Demux process demultiplexes packets for the various protocols. 237 The Demux process MUST follow the Rx process so that packets are 238 counted in the order received from the link. 240 2.5. Configuration Option Format 242 Description 244 Implementations MUST be prepared to receive the Quality-Protocol 245 Configuration Option for the Link-Quality-Report. However, 246 negotiation is not required. Negotiation is only necessary when 247 the implementation wishes to ensure that the peer transmits Link- 248 Quality-Reports as opposed to some other Quality-Protocol, or else 249 to prevent the peer from maintaining its own timer, or else to 250 establish a maximum time between transmissions of Link-Quality- 251 Reports. 253 A summary of the Quality-Protocol Configuration Option format to 254 negotiate the Link-Quality-Report is shown below. The fields are 255 transmitted from left to right. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | Quality-Protocol | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reporting-Period | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Type 267 4 269 Length 271 8 273 Quality-Protocol 275 c025 (hex) for Link-Quality-Report 277 Reporting-Period 279 The Reporting-Period field is four octets and indicates the 280 maximum time in hundredths of seconds between transmission of 281 packets. The peer MAY transmit packets at a faster rate than that 282 which was negotiated. 284 A value of zero indicates that the peer does not need to maintain 285 a timer. Instead, the peer generates a LQR immediately upon 286 receiving a LQR. A value of zero MUST be Nak'd by the peer with 287 an appropriate non-zero value when that peer has sent or will send 288 a Configure-Request packet containing the Quality-Protocol 289 Configuration Option for the Link-Quality-Report with a zero 290 Reporting-Period. 292 2.6. Packet Format 294 Exactly one Link-Quality-Report packet is encapsulated in the 295 Information field of PPP Data Link Layer frames where the protocol 296 field indicates type hex c025 (Link-Quality-Report). A summary of 297 the LQR packet format is shown below. The names of the fields are 298 relative to the packet receiver, since it is the receiver who 299 requested the packet in the Configuration Option. The fields are 300 transmitted from left to right. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Magic-Number | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | LastOutLQRs | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | LastOutPackets | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | LastOutOctets | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | PeerInLQRs | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | PeerInPackets | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | PeerInDiscards | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | PeerInErrors | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | PeerInOctets | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | PeerOutLQRs | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | PeerOutPackets | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | PeerOutOctets | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 The following fields are not actually transmitted over the inbound 331 link. Rather, they are logically appended (in an implementation 332 dependent manner) to the packet by the implementation's Rx process. 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | SaveInLQRs | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | SaveInPackets | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | SaveInDiscards | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | SaveInErrors | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | SaveInOctets | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Magic-Number 348 The Magic-Number field is four octets and aids in detecting links 349 which are in the looped-back condition. Unless modified by a 350 Configuration Option, the Magic-Number MUST be transmitted as zero 351 and MUST be ignored on reception. If Magic-Numbers have been 352 negotiated, incoming LQR packets SHOULD be checked to ensure that 353 the local end is not seeing its own Magic-Number and thus a 354 looped-back link. See the Magic-Number Configuration Option for 355 further explanation. 357 LastOutLQRs 359 The LastOutLQRs field is four octets, and is copied from the most 360 recently received PeerOutLQRs on transmission. 362 LastOutPackets 364 The LastOutPackets field is four octets, and is copied from the 365 most recently received PeerOutPackets on transmission. 367 LastOutOctets 369 The LastOutOctets field is four octets, and is copied from the 370 most recently received PeerOutOctets on transmission. 372 PeerInLQRs 374 The PeerInLQRs field is four octets, and is copied from the most 375 recently received SaveInLQRs on transmission. 377 Whenever the PeerInLQRs field is discovered to be zero, the 378 LastOut... fields are indeterminate, and the PeerIn... fields 379 contain the initial values for the peer. 381 PeerInPackets 383 The PeerInPackets field is four octets, and is copied from the 384 most recently received SaveInPackets on transmission. 386 PeerInDiscards 388 The PeerInDiscards field is four octets, and is copied from the 389 most recently received SaveInDiscards on transmission. 391 PeerInErrors 393 The PeerInErrors field is four octets, and is copied from the most 394 recently received SaveInErrors on transmission. 396 PeerInOctets 398 The PeerInOctets field is four octets, and is copied from the most 399 recently received SaveInOctets on transmission. 401 PeerOutLQRs 403 The PeerOutLQRs field is four octets, and is copied from OutLQRs 404 on transmission. This number MUST include this LQR. 406 PeerOutPackets 408 The PeerOutPackets field is four octets, and is copied from the 409 current MIB ifOutUniPackets and ifOutNUniPackets on transmission. 410 This number MUST include this LQR. 412 PeerOutOctets 414 The PeerOutOctets field is four octets, and is copied from the 415 current MIB ifOutOctets on transmission. This number MUST include 416 this LQR. 418 SaveInLQRs 420 The SaveInLQRs field is four octets, and is copied from InLQRs on 421 reception. This number MUST include this LQR. 423 SaveInPackets 425 The SaveInPackets field is four octets, and is copied from the 426 current MIB ifInUniPackets and ifInNUniPackets on reception. This 427 number MUST include this LQR. 429 SaveInDiscards 431 The SaveInDiscards field is four octets, and is copied from the 432 current MIB ifInDiscards on reception. This number MUST include 433 this LQR. 435 SaveInErrors 437 The SaveInErrors field is four octets, and is copied from the 438 current MIB ifInErrors on reception. This number MUST include 439 this LQR. 441 SaveInOctets 443 The SaveInOctets field is four octets, and is copied from the 444 current InGoodOctets on reception. This number MUST include this 445 LQR. 447 Note that InGoodOctets is not the same as the MIB ifInOctets 448 counter, as InGoodOctets does not include octets for packets which 449 are discards or errors. 451 2.7. Transmission of Reports 453 When the PPP Link Control Protocol has reached the Opened state, the 454 Link Quality Monitoring process MAY commence sending Link-Quality- 455 Reports. If a Protocol-Reject is received specifying a LQR packet, 456 the LQM process MUST cease sending LQRs. 458 Usually, the LQR is transmitted when the LQR timer for the link 459 expires. If no LQR timer is used, a LQR is generated upon receipt of 460 an incoming LQR. The negotiation process ensures that at least one 461 side of the link is using a LQR timer. 463 In addition, a LQR is generated whenever two successive LQRs are 464 received which have the same PeerInLQRs value. This may indicate 465 that a LQR has been missed, or that the implementation is sending at 466 a significantly slower rate than the peer, or that the peer has 467 accelerated LQR generation to better quantify errors on the link. 469 Whenever a LQR is sent, the LQR timer MUST be restarted. 471 2.8. Calculations 473 Each time a Link-Quality-Report packet is received from the inbound 474 link, the Link-Manager can compare the associated fields. The fields 475 of the previous LQR can be subtracted from the current LQR values to 476 obtain an absolute "delta", which allows comparision of the changes 477 seen by each end of the link. 479 If the received PeerInLQRs field is zero, the LastOut... fields are 480 indeterminate, and the PeerIn... fields contain the initial values 481 for the peer. No calculations using these fields can be performed at 482 this time. 484 Implementation Note: 486 The following counters wrap to zero when their maximum value is 487 reached. Care must be taken to ensure that correct "delta" 488 calculations are performed at that time. 490 The LastOutLQRs field may be directly compared with the PeerInLQRs 491 field to determine how many outbound LQRs have been lost. 493 The LastOutLQRs field may be directly compared with the OutLQRs 494 counter to determine how many outbound LQRs are still in the 495 pipeline. 497 The change in PeerInPackets may be compared with the change in 498 LastOutPackets to determine the number of lost packets over the 499 outgoing link. 501 The change in PeerInOctets may be compared with the change in 502 LastOutOctets to determine the number of lost octets over the 503 outgoing link. 505 The change in SaveInPackets may be compared with the change in 506 PeerOutPackets to determine the number of lost packets over the 507 incoming link. 509 The change in SaveInOctets may be compared with the change in 510 PeerOutOctets to determine the number of lost octets over the 511 incoming link. 513 The change in the PeerInDiscards and PeerInErrors fields may be used 514 to determine whether packet loss is due to congestion in the peer 515 rather than physical link failure. 517 2.9. Failure Detection 519 When the link is operating well in both directions of the link, the 520 LQR is superfluous. The maximum time interval for transmitting LQRs 521 SHOULD be chosen to minimally interfere with active traffic. 523 When there is a measurable loss of data in either direction, if the 524 overall throughput is adequate, conditions are not severe enough to 525 warrant dropping the link. Sending LQRs faster will gain nothing, 526 except to measure peaks in the loss rate. The time interval MUST be 527 chosen to be long enough to have a good smoothing effect on the data, 528 while short enough to ensure fast enough response to complete 529 failure. 531 When the link is good incoming, but very bad outgoing, incoming LQRs 532 indicate a high loss on the outgoing side of the link. Sending LQRs 533 faster won't help, because they are probably lost on the way to the 534 peer. 536 When the link is good outgoing, but very bad incoming, incoming LRQs 537 will be frequently lost. In this case, LQRs SHOULD be sent at a 538 faster rate. This primarily relies on the peer to make an informed 539 policy decision. The peer will also send LQRs in response (due to 540 the duplicate PeerInLQRs field), and some of those LQRs may 541 successfully arrive. 543 When a LQR does not arrive within the time expected, or the LQR 544 received indicates that the links are truly bad, at least one 545 additional LQR SHOULD be sent. An algorithmic decision requires at 546 least 2 round trip intervals. The loss rate could be transient, due 547 to a heavily loaded link, or a lost outgoing LQR. 549 2.10. Policy Suggestions 551 Link-Quality-Report packets provide a mechanism to determine the link 552 quality, but it is up to each implementation to decide when the link 553 is usable. It is recommended that this policy implement some amount 554 of hysteresis so that the link does not bounce up and down. One 555 policy is to use a K out of N algorithm. In such an algorithm, there 556 must be K successes out of the last N periods for the link to be 557 considered of good quality. 559 Procedures for recovery from poor quality links are unspecified and 560 may vary from implementation to implementation. A suggested approach 561 is to immediately close all other Network-Layer protocols (i.e., 562 cause IPCP to transmit a Terminate-Request), but to continue 563 transmitting Link-Quality-Reports. Once the link quality again 564 reaches an acceptable level, Network-Layer protocols can be 565 reconfigured. 567 Security Considerations 569 Security issues are not discussed in this memo. 571 Acknowledgements 573 Some of the text in this document is taken from RFC 1172, by Drew 574 Perkins of Carnegie Mellon University, and by Russ Hobby of the 575 University of California at Davis. 577 Special thanks to Craig Fox (Network Systems), and Karl Fox (Morning 578 Star Technologies), for design suggestions based on implementation 579 experience. 581 References 583 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 584 51, RFC 1661, Daydreamer, July 1994. 586 [2] McCloghrie, K., and M. Rose, "Management Information Base for 587 Network Management of TCP/IP-based internets: MIB-II", RFC 588 1213, March 1991. 590 [3] Rose, M., and K. McCloghrie, "Structure and Identification of 591 Management Information for TCP/IP-based Internets", RFC 1155, 592 May 1990. 594 Chair's Address 596 The working group can be contacted via the current chair: 598 Fred Baker 599 Cisco Systems 600 519 Lado Drive 601 Santa Barbara, California 93111 603 EMail: fred@cisco.com 605 Author's Address 607 Questions about this memo can also be directed to: 609 William Allen Simpson 610 Daydreamer 611 Computer Systems Consulting Services 612 1384 Fontaine 613 Madison Heights, Michigan 48071 615 Bill.Simpson@um.cc.umich.edu 616 bsimpson@MorningStar.com (prefered) 617 Table of Contents 619 1. Introduction .......................................... 1 621 2. Link Quality Monitoring ............................... 2 622 2.1 Design Motivation ............................... 2 623 2.2 Counters ........................................ 3 624 2.3 Counting Packets and Octets ..................... 4 625 2.4 Processes ....................................... 4 626 2.5 Configuration Option Format ..................... 6 627 2.6 Packet Format ................................... 8 628 2.7 Transmission of Reports ......................... 12 629 2.8 Calculations .................................... 12 630 2.9 Failure Detection ............................... 13 631 2.10 Policy Suggestions .............................. 14 633 SECURITY CONSIDERATIONS ...................................... 15 635 ACKNOWLEDGEMENTS ............................................. 15 637 REFERENCES ................................................... 15 639 CHAIR'S ADDRESS .............................................. 16 641 AUTHOR'S ADDRESS ............................................. 16