idnits 2.17.1 draft-ietf-pppext-lcpmib-03.txt: ** The Abstract section seems to be numbered 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-19) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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 Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [5,6], [10], [11], [12], [13], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (11 May 1993) is 11301 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) -- Missing reference section? '3' on line 1113 looks like a reference -- Missing reference section? '5' on line 1125 looks like a reference -- Missing reference section? '6' on line 1129 looks like a reference -- Missing reference section? '2' on line 1107 looks like a reference -- Missing reference section? '7' on line 1133 looks like a reference -- Missing reference section? '8' on line 1136 looks like a reference -- Missing reference section? '13' on line 1152 looks like a reference -- Missing reference section? '1' on line 1101 looks like a reference -- Missing reference section? '4' on line 1119 looks like a reference -- Missing reference section? '9' on line 1140 looks like a reference -- Missing reference section? '10' on line 1143 looks like a reference -- Missing reference section? '11' on line 1146 looks like a reference -- Missing reference section? '12' on line 1149 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 4 The Definitions of Managed Objects for 5 the Link Control Protocol of 6 the Point-to-Point Protocol 8 11 May 1993 10 Frank Kastenholz 11 FTP Software, Inc 12 2 High Street 13 North Andover, Mass 01845 USA 15 kasten@ftp.com 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are 20 working documents of the Internet Engineering Task Force 21 (IETF), its Areas, and its Working Groups. Note that other 22 groups may also distribute working documents as Internet 23 Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or 27 obsoleted by other documents at any time. It is not 28 appropriate to use Internet Drafts as reference material or to 29 cite them other than as a ``working draft'' or ``work in 30 progress.'' Please check the 1id-abstracts.txt listing 31 contained in the internet-drafts Shadow Directories on 32 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 33 munnari.oz.au to learn the current status of any Internet 34 Draft. 36 This document will be submitted to the Internet Activities 37 Board as a Proposed Standard. This document defines an 38 experimental extension to the SNMP MIB. Upon publication as a 39 Proposed Standard, a new MIB number will be assigned. This is 40 a working document only, it should neither be cited nor quoted 41 in any formal document. 43 This document will expire before 16 Nov. 1993. 45 Distribution of this document is unlimited. 47 Please send comments to the author. 49 1. Abstract 51 This memo defines an experimental portion of the Management 52 Information Base (MIB) for use with network management 53 protocols in TCP/IP-based internets. In particular, it 54 describes managed objects used for managing the Link Control 55 Protocol and Link Quality Monitoring on subnetwork interfaces 56 that use the family of Point-to-Point Protocols[8, 9, 10, 11, 57 & 12]. 59 This memo does not specify a standard for the Internet 60 community. 62 2. The Network Management Framework 64 The Internet-standard Network Management Framework consists of 65 three components. They are: 67 RFC 1155 which defines the SMI, the mechanisms used for 68 describing and naming objects for the purpose of 69 management. RFC 1212 defines a more concise description 70 mechanism, which is wholly consistent with the SMI. 72 RFC 1213 defines MIB-II, the core set of managed objects 73 for the Internet suite of protocols. 75 RFC 1157 which defines the SNMP, the protocol used for 76 network access to managed objects. 78 The Framework permits new objects to be defined for the 79 purpose of experimentation and evaluation. 81 3. Objects 83 Managed objects are accessed via a virtual information store, 84 termed the Management Information Base or MIB. Objects in the 85 MIB are defined using the subset of Abstract Syntax Notation 86 One (ASN.1) [3] defined in the SMI. In particular, each 87 object type is named by an OBJECT IDENTIFIER, an 88 administratively assigned name. The object type together with 89 an object instance serves to uniquely identify a specific 90 instantiation of the object. For human convenience, we often 91 use a textual string, termed the descriptor, to refer to the 92 object type. 94 3.1. Format of Definitions 96 Section 5 contains the specification of all object types 97 contained in this MIB module. The object types are defined 98 using the conventions defined in the SMI, as amended by the 99 extensions specified in [5,6]. 101 4. Overview 103 4.1. Object Selection Criteria 105 To be consistent with IAB directives and good engineering 106 practice, an explicit attempt was made to keep this MIB as 107 simple as possible. This was accomplished by applying the 108 following criteria to objects proposed for inclusion: 110 (1) Require objects be essential for either fault or 111 configuration management. In particular, objects for 112 which the sole purpose was to debug implementations were 113 explicitly excluded from the MIB. 115 (2) Consider evidence of current use and/or utility. 117 (3) Limit the total number of objects. 119 (4) Exclude objects which are simply derivable from others in 120 this or other MIBs. 122 4.2. Structure of the PPP 124 This section describes the basic model of PPP used in 125 developing the PPP MIB. This information should be useful to 126 the implementor in understanding some of the basic design 127 decisions of the MIB. 129 The PPP is not one single protocol but a large family of 130 protocols. Each of these is, in itself, a fairly complex 131 protocol. The PPP protocols may be divided into three rough 132 categories: 134 Control Protocols 135 The Control Protocols are used to control the operation 136 of the PPP. The Control Protocols include the Link 137 Control Protocol (LCP), the Password Authentication 138 Protocol (PAP), the Link Quality Report (LQR), and the 139 Challenge Handshake Authentication Protocol (CHAP). 141 Network Protocols 142 The Network Protocols are used to move the network 143 traffic over the PPP interface. A Network Protocol 144 encapsulates the datagrams of a specific higher-layer 145 protocol that is using the PPP as a data link. Note that 146 within the context of PPP, the term "Network Protocol" 147 does not imply an OSI Layer-3 protocol; for instance, 148 there is a Bridging network protocol. 150 Network Control Protocols (NCPs) 151 The NCPs are used to control the operation of the Network 152 Protocols. Generally, each Network Protocol has its own 153 Network Control Protocol; thus, the IP Network Protocol 154 has its IP Control Protocol, the Bridging Network 155 Protocol has its Bridging Network Control Protocol and so 156 on. 158 This document specifies the objects used in managing one of 159 these protocols, namely the Link Control Protocol and Link 160 Quality Monitoring Protocol. 162 4.3. MIB Groups 164 Objects in this MIB are arranged into several MIB groups. 165 Each group is organized as a set of related objects. 167 These groups are the basic unit of conformance: if the 168 semantics of a group are applicable to an implementation then 169 all objects in the group must be implemented. 171 The PPP MIB is organized into several MIB Groups, including, 172 but not limited to, the following groups: 173 o The PPP Link Group 174 o The PPP LQR Group 175 o The PPP LQR Extensions Group 176 o The PPP IP Group 177 o The PPP Bridge Group 178 o The PPP Security Group 180 This document specifies the following groups: 182 The PPP Link Group 183 This group represents the lowest "level" of the PPP 184 protocol. 186 This group contains two tables, one containing status 187 information and the other configuration information. The 188 configuration table is split off of the status so that it 189 may be placed in a separate MIB View for security 190 purposes. 192 Implementation of this group is mandatory for all PPP 193 implementations. 195 The PPP LQR Group 196 This group provides the basic MIB variables that apply to 197 the PPP LQR Protocol. This group provides MIB access to 198 the information required for LQR processing. This group 199 contains two tables, one containing status information 200 and the other configuration information. The 201 configuration table is split off of the status so that it 202 may be placed in a separate MIB View for security 203 purposes. 205 Implementation of the PPP LQR Group is mandatory for all 206 PPP implementations that implement LQR. 208 The PPP LQR Extensions Group 209 The PPP LQR Extensions group contains the most recently 210 received LQR packet, as well as the "save" fields that 211 are "logically appended"[12] to received LQR packets. 212 This is done in order to facilitate external 213 implementations of the Link Quality Monitoring policies. 215 It is not practical to examine the relevant MIB objects 216 which are used to generate LQR packets since LQR policies 217 may require synchronization of the values of all data 218 used to determine Link Quality; i.e., the values of the 219 relevant counters must all be taken at the same instant 220 in time. Thus, by recording the last received LQR 221 packet, a synchronized record of the relevant data is 222 available. 224 As this information may not be efficiently maintained on 225 all PPP implementations, implementation of this group is 226 optional. 228 4.4. Relationship to Interface and Interface Extensions 229 Groups 231 The PPP Mib is a medium-specific extension to the standard 232 MIB-2 interface group[2] and to the Interface Extensions MIB 233 [7]. This section discusses certain components of these 234 groups when the interface is a PPP interface. 236 The PPP interface represents a single interface in the sense 237 used in [2] and thus has a single entry in the ifTable. 239 Furthermore, the PPP interface may be operating over a lower 240 layer hardware interface (such as an RS-232 port). It is 241 important to capture the relationship between the PPP 242 interface and the lower-layer interface over which it 243 operates. This MIB presumes that the lower-layer interface 244 has an ifEntry associated with it. The lower-layer ifEntry is 245 identified via the pppLinkStatusPhysicalIndex object, which 246 contains the value of ifIndex for the lower-layer ifEntry. 248 For example, suppose that you run PPP over a RS-232 port. 249 This would use two entries in the ifTable. Let's suppose that 250 entry number 123 is for the PPP "interface" and entry number 251 987 is for the RS-232 port. So, ifSpecific.123 would contain 252 the ppp OBJECT IDENTIFIER, pppLinkStatusPhysicalIndex.123 253 would contain 987, and ifSpecific.987 would contain the rs_232 254 OBJECT IDENTIFIER (or whatever it is). 256 All PPP packets are defined in [8] as being broadcast packets. 257 Thus, the packets are counted as non-unicast packets in the 258 ifTable (ifInNUcastPkts and ifOutNUCastPkts) and as broadcasts 259 in the ifExtnsTable (ifExtnsBroadcastsReceivedOks and 260 ifExtnsBroadcastsTransmittedOks). 262 ifSpecific 263 Contains the OBJECT IDENTIFIER ppp. 265 ifAdminStatus 266 Setting this object to up will inject an administrative 267 open event into the LCP's finite state machine. Setting 268 this object to down will inject an administrative close 269 event into the LCP's finite state machine. 271 The use of the testing value is beyond the scope of this 272 document. 274 ifOperStatus 275 Represents the state of the LCP Finite State Machine. If 276 the Finite State Machine is in the Opened state then the 277 value of ifOperStatus is up, otherwise the value of 278 ifOperStatus is down. 280 The meaning of the testing value is beyond the scope of 281 this document. 283 Per the SNMP Protocol Specification, [13], the linkUp and 284 linkDown traps apply to the PPP Protocol entity. When the 285 LCP's Finite State Machine attains the Opened state, a linkUp 286 trap should be sent. When the Finite State Machine leaves the 287 Opened state, a linkDown trap should be sent. 289 Some tests for the link are defined in this document. 290 Execution of these tests does not place the link's 291 ifOperStatus in the testing state as these tests do not 292 prevent normal data transmission from occuring over the link. 294 5. Definitions 296 PPP-LCP-MIB DEFINITIONS ::= BEGIN 298 IMPORTS 299 experimental, Counter 300 FROM RFC1155-SMI 301 ifIndex 302 FROM RFC1213-MIB 303 OBJECT-TYPE 304 FROM RFC-1212; 306 -- PPP MIB 308 ppp OBJECT IDENTIFIER ::= { experimental 18 } 310 pppLcp OBJECT IDENTIFIER ::= { ppp 1 } 312 -- The individual groups within the PPP-LCP-MIB 314 pppLink OBJECT IDENTIFIER ::= { pppLcp 1 } 315 pppLqr OBJECT IDENTIFIER ::= { pppLcp 2 } 316 pppTests OBJECT IDENTIFIER ::= { pppLcp 3 } 318 -- 5.1. PPP Link Group 320 -- 321 -- The PPP Link Group. Implementation of this 322 -- group is mandatory for all PPP entities. 323 -- 325 -- The following object reflect the values of the option 326 -- parameters used in the PPP Link Control Protocol 327 -- pppLinkStatusLocalMRU 328 -- pppLinkStatusRemoteMRU 329 -- pppLinkStatusLocalToPeerACCMap 330 -- pppLinkStatusPeerToLocalACCMap 331 -- pppLinkStatusLocalToRemoteProtocolCompression 332 -- pppLinkStatusRemoteToLocalProtocolCompression 333 -- pppLinkStatusLocalToRemoteACCompression 334 -- pppLinkStatusRemoteToLocalACCompression 335 -- pppLinkStatusTransmitFcsSize 336 -- pppLinkStatusReceiveFcsSize 337 -- 338 -- These values are not available until after the PPP Option 339 -- negotiation has completed, which is indicated by the link 340 -- reaching the open state (i.e. ifOperStatus is set to 341 -- up). 342 -- 343 -- Therefore, when ifOperStatus is not up 344 -- the contents of these objects is undefined. The value 345 -- returned when accessing the objects is an implementation 346 -- dependent issue. 348 pppLinkStatusTable OBJECT-TYPE 349 SYNTAX SEQUENCE OF PppLinkStatusEntry 350 ACCESS not-accessible 351 STATUS mandatory 352 DESCRIPTION 353 "A table containing PPP-link specific variables 354 for this PPP implementation." 355 ::= { pppLink 1 } 357 pppLinkStatusEntry OBJECT-TYPE 358 SYNTAX PppLinkStatusEntry 359 ACCESS not-accessible 360 STATUS mandatory 361 DESCRIPTION 362 "Management information about a particular PPP 363 Link." 364 INDEX { ifIndex } 365 ::= { pppLinkStatusTable 1 } 367 PppLinkStatusEntry ::= SEQUENCE { 368 pppLinkStatusPhysicalIndex 369 INTEGER, 370 pppLinkStatusBadAddresses 371 Counter, 372 pppLinkStatusBadControls 373 Counter, 374 pppLinkStatusPacketTooLongs 375 Counter, 376 pppLinkStatusBadFCSs 377 Counter, 378 pppLinkStatusLocalMRU 379 INTEGER, 380 pppLinkStatusRemoteMRU 381 INTEGER, 382 pppLinkStatusLocalToPeerACCMap 383 OCTET STRING, 384 pppLinkStatusPeerToLocalACCMap 385 OCTET STRING, 386 pppLinkStatusLocalToRemoteProtocolCompression 387 INTEGER, 388 pppLinkStatusRemoteToLocalProtocolCompression 389 INTEGER, 390 pppLinkStatusLocalToRemoteACCompression 391 INTEGER, 392 pppLinkStatusRemoteToLocalACCompression 393 INTEGER, 394 pppLinkStatusTransmitFcsSize 395 INTEGER, 396 pppLinkStatusReceiveFcsSize 397 INTEGER 398 } 399 pppLinkStatusPhysicalIndex OBJECT-TYPE 400 SYNTAX INTEGER(0..2147483648) 401 ACCESS read-only 402 STATUS mandatory 403 DESCRIPTION 404 "The value of ifIndex that identifies the 405 lower-level interface over which this PPP Link 406 is operating. This interface would usually be 407 an HDLC or RS-232 type of interface. If there 408 is no lower-layer interface element, or there 409 is no ifEntry for the element, or the element 410 can not be identified, then the value of this 411 object is 0. For example, suppose that PPP is 412 operating over a serial port. This would use 413 two entries in the ifTable. The PPP could be 414 running over `interface' number 123 and the 415 serial port could be running over `interface' 416 number 987. Therefore, ifSpecific.123 would 417 contain the OBJECT IDENTIFIER ppp 418 pppLinkStatusPhysicalIndex.123 would contain 419 987, and ifSpecific.987 would contain the 420 OBJECT IDENTIFIER for the serial-port's media- 421 specific MIB." 422 ::= { pppLinkStatusEntry 1 } 424 pppLinkStatusBadAddresses OBJECT-TYPE 425 SYNTAX Counter 426 ACCESS read-only 427 STATUS mandatory 428 DESCRIPTION 429 "The number of packets received with an 430 incorrect Address Field. This counter is a 431 component of the ifInErrors variable that is 432 associated with the interface that represents 433 this PPP Link." 434 REFERENCE 435 "Section 3.1, Address Field, of RFC1331." 436 ::= { pppLinkStatusEntry 2 } 438 pppLinkStatusBadControls OBJECT-TYPE 439 SYNTAX Counter 440 ACCESS read-only 441 STATUS mandatory 442 DESCRIPTION 443 "The number of packets received on this link 444 with an incorrect Control Field. This counter 445 is a component of the ifInErrors variable that 446 is associated with the interface that 447 represents this PPP Link." 448 REFERENCE 449 "Section 3.1, Control Field, of RFC1331." 450 ::= { pppLinkStatusEntry 3 } 452 pppLinkStatusPacketTooLongs OBJECT-TYPE 453 SYNTAX Counter 454 ACCESS read-only 455 STATUS mandatory 456 DESCRIPTION 457 "The number of received packets that have been 458 discarded because their length exceeded the 459 MRU. This counter is a component of the 460 ifInErrors variable that is associated with the 461 interface that represents this PPP Link. NOTE, 462 packets which are longer than the MRU but which 463 are successfully received and processed are NOT 464 included in this count." 465 ::= { pppLinkStatusEntry 4 } 467 pppLinkStatusBadFCSs OBJECT-TYPE 468 SYNTAX Counter 469 ACCESS read-only 470 STATUS mandatory 471 DESCRIPTION 472 "The number of received packets that have been 473 discarded due to having an incorrect FCS. This 474 counter is a component of the ifInErrors 475 variable that is associated with the interface 476 that represents this PPP Link." 477 ::= { pppLinkStatusEntry 5 } 479 pppLinkStatusLocalMRU OBJECT-TYPE 480 SYNTAX INTEGER(1..2147483648) 481 ACCESS read-only 482 STATUS mandatory 483 DESCRIPTION 484 "The current value of the MRU for the local PPP 485 Entity. This value is the MRU that the remote 486 entity is using when sending packets to the 487 local PPP entity. The value of this object is 488 meaningful only when the link has reached the 489 open state (ifOperStatus is up)." 490 ::= { pppLinkStatusEntry 6 } 492 pppLinkStatusRemoteMRU OBJECT-TYPE 493 SYNTAX INTEGER(1..2147483648) 494 ACCESS read-only 495 STATUS mandatory 496 DESCRIPTION 497 "The current value of the MRU for the remote 498 PPP Entity. This value is the MRU that the 499 local entity is using when sending packets to 500 the remote PPP entity. The value of this object 501 is meaningful only when the link has reached 502 the open state (ifOperStatus is up)." 503 ::= { pppLinkStatusEntry 7 } 505 pppLinkStatusLocalToPeerACCMap OBJECT-TYPE 506 SYNTAX OCTET STRING (SIZE (4)) 507 ACCESS read-only 508 STATUS mandatory 509 DESCRIPTION 510 "The current value of the ACC Map used for 511 sending packets from the local PPP entity to 512 the remote PPP entity. The value of this object 513 is meaningful only when the link has reached 514 the open state (ifOperStatus is up)." 515 ::= { pppLinkStatusEntry 8 } 517 pppLinkStatusPeerToLocalACCMap OBJECT-TYPE 518 SYNTAX OCTET STRING (SIZE (4)) 519 ACCESS read-only 520 STATUS mandatory 521 DESCRIPTION 522 "The ACC Map used by the remote PPP entity when 523 transmitting packets to the local PPP entity. 524 The value of this object is meaningful only 525 when the link has reached the open state 526 (ifOperStatus is up)." 527 ::= { pppLinkStatusEntry 9 } 529 pppLinkStatusLocalToRemoteProtocolCompression 530 OBJECT-TYPE 531 SYNTAX INTEGER { 532 enabled(1), 533 disabled(2) 534 } 535 ACCESS read-only 536 STATUS mandatory 537 DESCRIPTION 538 "Indicates whether the local PPP entity will 539 use Protocol Compression when transmitting 540 packets to the remote PPP entity. The value of 541 this object is meaningful only when the link 542 has reached the open state (ifOperStatus is 543 up)." 544 ::= { pppLinkStatusEntry 10 } 546 pppLinkStatusRemoteToLocalProtocolCompression 547 OBJECT-TYPE 548 SYNTAX INTEGER { 549 enabled(1), 550 disabled(2) 551 } 552 ACCESS read-only 553 STATUS mandatory 554 DESCRIPTION 555 "Indicates whether the remote PPP entity will 556 use Protocol Compression when transmitting 557 packets to the local PPP entity. The value of 558 this object is meaningful only when the link 559 has reached the open state (ifOperStatus is 560 up)." 561 ::= { pppLinkStatusEntry 11 } 563 pppLinkStatusLocalToRemoteACCompression OBJECT-TYPE 564 SYNTAX INTEGER { 565 enabled(1), 566 disabled(2) 568 } 569 ACCESS read-only 570 STATUS mandatory 571 DESCRIPTION 572 "Indicates whether the local PPP entity will 573 use Address and Control Compression when 574 transmitting packets to the remote PPP entity. 575 The value of this object is meaningful only 576 when the link has reached the open state 577 (ifOperStatus is up)." 578 ::= { pppLinkStatusEntry 12 } 580 pppLinkStatusRemoteToLocalACCompression OBJECT-TYPE 581 SYNTAX INTEGER { 582 enabled(1), 583 disabled(2) 584 } 585 ACCESS read-only 586 STATUS mandatory 587 DESCRIPTION 588 "Indicates whether the remote PPP entity will 589 use Address and Control Compression when 590 transmitting packets to the local PPP entity. 591 The value of this object is meaningful only 592 when the link has reached the open state 593 (ifOperStatus is up)." 594 ::= { pppLinkStatusEntry 13 } 596 pppLinkStatusTransmitFcsSize OBJECT-TYPE 597 SYNTAX INTEGER (0..128) 598 ACCESS read-only 599 STATUS mandatory 600 DESCRIPTION 601 "The size of the Frame Check Sequence (FCS) in 602 bits that the local node will generate when 603 sending packets to the remote node. The value 604 of this object is meaningful only when the link 605 has reached the open state (ifOperStatus is 606 up)." 607 ::= { pppLinkStatusEntry 14 } 609 pppLinkStatusReceiveFcsSize OBJECT-TYPE 610 SYNTAX INTEGER (0..128) 611 ACCESS read-only 612 STATUS mandatory 613 DESCRIPTION 614 "The size of the Frame Check Sequence (FCS) in 615 bits that the remote node will generate when 616 sending packets to the local node. The value of 617 this object is meaningful only when the link 618 has reached the open state (ifOperStatus is 619 up)." 620 ::= { pppLinkStatusEntry 15 } 622 pppLinkConfigTable OBJECT-TYPE 623 SYNTAX SEQUENCE OF PppLinkConfigEntry 624 ACCESS not-accessible 625 STATUS mandatory 626 DESCRIPTION 627 "A table containing the LCP configuration 628 parameters for this PPP Link. These variables 629 represent the initial configuration of the PPP 630 Link. The actual values of the parameters may 631 be changed when the link is brought up via the 632 LCP options negotiation mechanism." 633 ::= { pppLink 2 } 635 pppLinkConfigEntry OBJECT-TYPE 636 SYNTAX PppLinkConfigEntry 637 ACCESS not-accessible 638 STATUS mandatory 639 DESCRIPTION 640 "Configuration information about a particular 641 PPP Link." 642 INDEX { ifIndex } 643 ::= { pppLinkConfigTable 1 } 645 PppLinkConfigEntry ::= SEQUENCE { 646 pppLinkConfigInitialMRU 647 INTEGER, 648 pppLinkConfigReceiveACCMap 649 OCTET STRING, 650 pppLinkConfigTransmitACCMap 651 OCTET STRING, 652 pppLinkConfigMagicNumber 653 INTEGER, 654 pppLinkConfigFcsSize 655 INTEGER 656 } 658 pppLinkConfigInitialMRU OBJECT-TYPE 659 SYNTAX INTEGER(0..2147483648) 660 ACCESS read-write 661 STATUS mandatory 662 DESCRIPTION 663 "The initial Maximum Receive Unit (MRU) that 664 the local PPP entity will advertise to the 665 remote entity. If the value of this variable is 666 0 then the local PPP entity will not advertise 667 any MRU to the remote entity and the default 668 MRU will be assumed. Changing this object will 669 have effect when the link is next restarted." 670 REFERENCE 671 "Section 7.2, Maximum Receive Unit of RFC1331." 672 DEFVAL { 1500 } 673 ::= { pppLinkConfigEntry 1 } 675 pppLinkConfigReceiveACCMap OBJECT-TYPE 676 SYNTAX OCTET STRING (SIZE (4)) 677 ACCESS read-write 678 STATUS mandatory 679 DESCRIPTION 680 "The Asynchronous-Control-Character-Map (ACC) 681 that the local PPP entity requires for use on 682 its receive side. In effect, this is the ACC 683 Map that is required in order to ensure that 684 the local modem will successfully receive all 685 characters. The actual ACC map used on the 686 receive side of the link will be a combination 687 of the local node's pppLinkConfigReceiveACCMap 688 and the remote node's 689 pppLinkConfigTransmitACCMap. Changing this 690 object will have effect when the link is next 691 restarted." 693 REFERENCE 694 "Section 7.3, page 4, Async-Control-Character- 695 Map of RFC1331." 696 DEFVAL { 'ffffffff'h } 697 ::= { pppLinkConfigEntry 2 } 699 pppLinkConfigTransmitACCMap OBJECT-TYPE 700 SYNTAX OCTET STRING (SIZE (4)) 701 ACCESS read-write 702 STATUS mandatory 703 DESCRIPTION 704 "The Asynchronous-Control-Character-Map (ACC) 705 that the local PPP entity requires for use on 706 its transmit side. In effect, this is the ACC 707 Map that is required in order to ensure that 708 all characters can be successfully transmitted 709 through the local modem. The actual ACC map 710 used on the transmit side of the link will be a 711 combination of the local node's 712 pppLinkConfigTransmitACCMap and the remote 713 node's pppLinkConfigReceiveACCMap. Changing 714 this object will have effect when the link is 715 next restarted." 716 REFERENCE 717 "Section 7.3, page 4, Async-Control-Character- 718 Map of RFC1331." 719 DEFVAL { 'ffffffff'h } 720 ::= { pppLinkConfigEntry 3 } 722 pppLinkConfigMagicNumber OBJECT-TYPE 723 SYNTAX INTEGER {false (1), true (2)} 724 ACCESS read-write 725 STATUS mandatory 726 DESCRIPTION 727 "If true(2) then the local node will attempt to 728 perform Magic Number negotiation with the 729 remote node. If false(1) then this negotiation 730 is not performed. In any event, the local node 731 will comply with any magic number negotiations 732 attempted by the remote node, per the PPP 733 specification. Changing this object will have 734 effect when the link is next restarted." 736 REFERENCE 737 "Section 7.6, Magic Number, of RFC1331." 738 DEFVAL { false } 739 ::= { pppLinkConfigEntry 4 } 741 pppLinkConfigFcsSize OBJECT-TYPE 742 SYNTAX INTEGER (0..128) 743 ACCESS read-write 744 STATUS mandatory 745 DESCRIPTION 746 "The size of the FCS, in bits, the local node 747 will attempt to negotiate for use with the 748 remote node. Regardless of the value of this 749 object, the local node will comply with any FCS 750 size negotiations initiated by the remote node, 751 per the PPP specification. Changing this object 752 will have effect when the link is next 753 restarted." 754 DEFVAL { 16 } 755 ::= { pppLinkConfigEntry 5 } 757 -- 5.2. PPP LQR Group 759 -- 760 -- The PPP LQR Group. 761 -- Implementation of this group is mandatory for all 762 -- PPP implementations that implement LQR. 763 -- 765 pppLqrTable OBJECT-TYPE 766 SYNTAX SEQUENCE OF PppLqrEntry 767 ACCESS not-accessible 768 STATUS mandatory 769 DESCRIPTION 770 "Table containing the LQR parameters and 771 statistics for the local PPP entity." 772 ::= { pppLqr 1 } 774 pppLqrEntry OBJECT-TYPE 775 SYNTAX PppLqrEntry 776 ACCESS not-accessible 777 STATUS mandatory 778 DESCRIPTION 779 "LQR information for a particular PPP link. A 780 PPP link will have an entry in this table if 781 and only if LQR Quality Monitoring has been 782 successfully negotiated for said link." 783 INDEX { ifIndex } 784 ::= { pppLqrTable 1 } 786 PppLqrEntry ::= SEQUENCE { 787 pppLqrQuality 788 INTEGER, 789 pppLqrInGoodOctets 790 Counter, 791 pppLqrLocalPeriod 792 INTEGER, 793 pppLqrRemotePeriod 794 INTEGER, 795 pppLqrOutLQRs 796 Counter, 797 pppLqrInLQRs 798 Counter 799 } 801 pppLqrQuality OBJECT-TYPE 802 SYNTAX INTEGER { 803 good(1), 804 bad(2), 805 not-determined(3) 806 } 807 ACCESS read-only 808 STATUS mandatory 809 DESCRIPTION 810 "The current quality of the link as declared by 811 the local PPP entity's Link-Quality Management 812 modules. No effort is made to define good or 813 bad, nor the policy used to determine it. The 814 not-determined value indicates that the entity 815 does not actually evaluate the link's quality. 816 This value is used to disambiguate the 817 `determined to be good' case from the `no 818 determination made and presumed to be good' 819 case." 820 ::= { pppLqrEntry 1 } 822 pppLqrInGoodOctets OBJECT-TYPE 823 SYNTAX Counter 824 ACCESS read-only 825 STATUS mandatory 826 DESCRIPTION 827 "The LQR InGoodOctets counter for this link." 828 REFERENCE 829 "Section 2.2, Counters, of RFC1333." 830 ::= { pppLqrEntry 2 } 832 pppLqrLocalPeriod OBJECT-TYPE 833 SYNTAX INTEGER(1..2147483648) 834 ACCESS read-only 835 STATUS mandatory 836 DESCRIPTION 837 "The LQR reporting period, in hundredths of a 838 second that is in effect for the local PPP 839 entity." 841 REFERENCE 842 "Section 2.5, Configuration Option Format, of 843 RFC1333." 844 ::= { pppLqrEntry 3 } 846 pppLqrRemotePeriod OBJECT-TYPE 847 SYNTAX INTEGER(1..2147483648) 848 ACCESS read-only 849 STATUS mandatory 850 DESCRIPTION 851 "The LQR reporting period, in hundredths of a 852 second, that is in effect for the remote PPP 853 entity." 854 REFERENCE 855 "Section 2.5, Configuration Option Format, of 856 RFC1333." 857 ::= { pppLqrEntry 4 } 859 pppLqrOutLQRs OBJECT-TYPE 860 SYNTAX Counter 861 ACCESS read-only 862 STATUS mandatory 863 DESCRIPTION 864 "The value of the OutLQRs counter on the local 865 node for the link identified by ifIndex." 866 REFERENCE 867 "Section 2.2, Counters, of RFC1333." 868 ::= { pppLqrEntry 5 } 870 pppLqrInLQRs OBJECT-TYPE 871 SYNTAX Counter 872 ACCESS read-only 873 STATUS mandatory 874 DESCRIPTION 875 "The value of the InLQRs counter on the local 876 node for the link identified by ifIndex." 877 REFERENCE 878 "Section 2.2, Counters, of RFC1333." 879 ::= { pppLqrEntry 6 } 881 -- 882 -- The PPP LQR Configuration table. 883 -- 885 pppLqrConfigTable OBJECT-TYPE 886 SYNTAX SEQUENCE OF PppLqrConfigEntry 887 ACCESS not-accessible 888 STATUS mandatory 889 DESCRIPTION 890 "Table containing the LQR Configuration 891 parameters for the local PPP entity." 892 ::= { pppLqr 2 } 894 pppLqrConfigEntry OBJECT-TYPE 895 SYNTAX PppLqrConfigEntry 896 ACCESS not-accessible 897 STATUS mandatory 898 DESCRIPTION 899 "LQR configuration information for a particular 900 PPP link." 901 INDEX { ifIndex } 902 ::= { pppLqrConfigTable 1 } 904 PppLqrConfigEntry ::= SEQUENCE { 905 pppLqrConfigPeriod 906 INTEGER, 907 pppLqrConfigStatus 908 INTEGER 909 } 911 pppLqrConfigPeriod OBJECT-TYPE 912 SYNTAX INTEGER(0..2147483648) 913 ACCESS read-write 914 STATUS mandatory 915 DESCRIPTION 916 "The LQR Reporting Period that the local PPP 917 entity will attempt to negotiate with the 918 remote entity, in units of hundredths of a 919 second. Changing this object will have effect 920 when the link is next restarted." 921 REFERENCE 922 "Section 2.5, Configuration Option Format, of 923 RFC1333." 924 DEFVAL { 0 } 925 ::= { pppLqrConfigEntry 1 } 927 pppLqrConfigStatus OBJECT-TYPE 928 SYNTAX INTEGER {disabled (1), enabled (2)} 929 ACCESS read-write 930 STATUS mandatory 931 DESCRIPTION 932 "If enabled(2) then the local node will attempt 933 to perform LQR negotiation with the remote 934 node. If disabled(1) then this negotiation is 935 not performed. In any event, the local node 936 will comply with any magic number negotiations 937 attempted by the remote node, per the PPP 938 specification. Changing this object will have 939 effect when the link is next restarted. 940 Setting this object to the value disabled(1) 941 has the effect of invalidating the 942 corresponding entry in the pppLqrConfigTable 943 object. It is an implementation-specific matter 944 as to whether the agent removes an invalidated 945 entry from the table. Accordingly, management 946 stations must be prepared to receive tabular 947 information from agents that corresponds to 948 entries not currently in use." 949 REFERENCE 950 "Section 7.6, Magic Number, of RFC1331." 951 DEFVAL { enabled } 952 ::= { pppLqrConfigEntry 2 } 954 -- 5.3. PPP LQR Extensions Group 956 -- 957 -- The PPP LQR Extensions Group. 958 -- Implementation of this group is optional. 959 -- 960 -- The intent of this group is to allow external 961 -- implementation of the policy mechanisms that 962 -- are used to declare a link to be "bad" or not. 963 -- 964 -- It is not practical to examine the MIB objects 965 -- which are used to generate LQR packets since 966 -- LQR policies tend to require synchronization of 967 -- the values of all data used to determine Link 968 -- Quality; i.e. the values of the relevant counters 969 -- must all be taken at the same instant in time. 970 -- 972 pppLqrExtnsTable OBJECT-TYPE 973 SYNTAX SEQUENCE OF PppLqrExtnsEntry 974 ACCESS not-accessible 975 STATUS mandatory 976 DESCRIPTION 977 "Table containing additional LQR information 978 for the local PPP entity." 979 ::= { pppLqr 3 } 981 pppLqrExtnsEntry OBJECT-TYPE 982 SYNTAX PppLqrExtnsEntry 983 ACCESS not-accessible 984 STATUS mandatory 985 DESCRIPTION 986 "Extended LQR information for a particular PPP 987 link. Assuming that this group has been 988 implemented, a PPP link will have an entry in 989 this table if and only if LQR Quality 990 Monitoring has been successfully negotiated for 991 said link." 992 INDEX { ifIndex } 993 ::= { pppLqrExtnsTable 1 } 995 PppLqrExtnsEntry ::= SEQUENCE { 996 pppLqrExtnsLastReceivedLqrPacket 997 OCTET STRING(SIZE(68)) 998 } 1000 pppLqrExtnsLastReceivedLqrPacket OBJECT-TYPE 1001 SYNTAX OCTET STRING(SIZE(68)) 1002 ACCESS read-only 1003 STATUS mandatory 1004 DESCRIPTION 1005 "This object contains the most recently 1006 received LQR packet. The format of the packet 1007 is as described in the LQM Protocol 1008 specificiation. All fields of the packet, 1009 including the `save' fields, are stored in this 1010 object. 1012 The LQR packet is stored in network byte order. 1013 The LAP-B and PPP headers are not stored in 1014 this object; the first four octets of this 1015 variable contain the Magic-Number field, the 1016 second four octets contain the LastOutLQRs 1017 field and so on. The last four octets of this 1018 object contain the SaveInOctets field of the 1019 LQR packet." 1020 REFERENCE 1021 "Section 2.6, Packet Format, of RFC1333" 1022 ::= { pppLqrExtnsEntry 1 } 1024 -- 5.4. PPP Tests 1026 -- The extensions to the interface table in RFC1229 define a 1027 -- table through which the network manager can instruct the 1028 -- managed object to perform various tests of the interface. This 1029 -- is the ifExtnsTestTable. 1031 -- The PPP MIB defines two such tests. 1033 -- 5.4.1. PPP Echo Test 1035 -- The PPP Echo Test is defined as 1037 pppEchoTest OBJECT IDENTIFIER ::= { pppTests 1 } 1039 -- Invoking this test causes a PPP Echo Packet to be sent on the 1040 -- line. ifExtnsTestResult returns success(2) if the echo 1041 -- response came back properly. It returns failed(7) if the 1042 -- response did not properly return. The definition of "proper" 1043 -- in this context is left to the discretion of the implementor. 1045 -- 5.4.2. PPP Discard Test 1047 -- The PPP Discard Test is defined as 1049 pppDiscardTest OBJECT IDENTIFIER ::= { pppTests 2 } 1051 -- Invoking this test causes a PPP Discard Packet to be sent on 1052 -- the line. ifExtnsTestResult returns success(2) if the discard 1053 -- packet was successfully transmitted and failed(7) if an error 1054 -- was detected on transmission. The definition of "transmission 1055 -- error" in this context is left to the discretion of the 1056 -- implementor. 1058 END 1059 6. Acknowledgements 1061 This document was produced by the PPP working group. In 1062 addition to the working group, the author wishes to thank the 1063 following individuals for their comments and contributions: 1065 Bill Simpson -- Daydreamer 1066 Glenn McGregor -- Merit 1067 Jesse Walker -- DEC 1068 Chris Gunner -- DEC 1069 7. Security Considerations 1071 The PPP MIB affords the network operator the ability to 1072 configure and control the PPP links of a particular system. 1073 This represents a security risk. 1075 These risks are addressed in the following manners: 1077 (1) All variables which represent a significant security risk 1078 are placed in separate, optional, MIB Groups. As the MIB 1079 Group is the quantum of implementation within a MIB, the 1080 implementor of the MIB may elect not to implement these 1081 groups. 1083 (2) The implementor may choose to implement the variables 1084 which present a security risk so that they may not be 1085 written, i.e., the variables are READ-ONLY. This method 1086 still presents a security risk, and is not recommended, 1087 in that the variables, specifically the PPP 1088 Authentication Protocols' variables, may be easily read. 1090 (3) Using SNMPv2, the operator can place the variables into 1091 MIB views which are protected in that the parties which 1092 have access to those MIB views use authentication and 1093 privacy protocols, or the operator may elect to make 1094 these views not accessible to any party. In order to 1095 facilitate this placement, all security-related variables 1096 are placed in separate MIB Tables. This eases the 1097 identification of the necessary MIB View Subtree. 1099 8. References 1101 [1] M.T. Rose and K. McCloghrie, Structure and Identification 1102 of Management Information for TCP/IP-based internets, 1103 Internet Working Group Request for Comments 1155. 1104 Network Information Center, SRI International, Menlo 1105 Park, California, (May, 1990). 1107 [2] K. McCloghrie and M.T. Rose, Management Information Base 1108 for Network Management of TCP/IP-based internets - MIB-2, 1109 Internet Working Group Request for Comments 1213. 1110 Network Information Center, SRI International, Menlo 1111 Park, California, (March, 1991). 1113 [3] Information processing systems - Open Systems 1114 Interconnection - Specification of Abstract Syntax 1115 Notation One (ASN.1), International Organization for 1116 Standardization. International Standard 8824, (December, 1117 1987). 1119 [4] Information processing systems - Open Systems 1120 Interconnection - Specification of Basic Encoding Rules 1121 for Abstract Notation One (ASN.1), International 1122 Organization for Standardization. International Standard 1123 8825, (December, 1987). 1125 [5] Rose, M., and K. McCloghrie, Editors, Concise MIB 1126 Definitions, RFC 1212, Performance Systems International, 1127 Hughes LAN Systems, March 1991. 1129 [6] Rose, M., Editor, A Convention for Defining Traps for use 1130 with the SNMP, RFC 1215, Performance Systems 1131 International, March 1991. 1133 [7] K. McCloghrie, Extensions to the Generic-Interface MIB, 1134 RFC1229, Hughes LAN Systems, May 1991. 1136 [8] W. Simpson, The Point-to-Point Protocol for the 1137 Transmission of Multi-protocol Datagrams over Point-to- 1138 Point Links, RFC 1331, May 1992. 1140 [9] G. McGregor, The PPP Internet Protocol Control Protocol, 1141 RFC 1332, Merit, May 1992. 1143 [10] F. Baker, Point-to-Point Protocol Extensions for 1144 Bridging, RFC1220, ACC, April 1991. 1146 [11] B. Lloyd, and Simpson, W., PPP Authentication Protocols 1147 RFC1334, October 1992. 1149 [12] W. Simpson, PPP Link Quality Monitoring, RFC 1333, May 1150 1992. 1152 [13] J. Case, Fedor, M., Schoffstall, M., and Davin, J., A 1153 Simple Network Management Protocol, RFC1157, May 1990. 1155 Table of Contents 1157 Status of this Memo .................................... 1 1158 1 Abstract .............................................. 2 1159 2 The Network Management Framework ...................... 3 1160 3 Objects ............................................... 4 1161 3.1 Format of Definitions ............................... 4 1162 4 Overview .............................................. 5 1163 4.1 Object Selection Criteria ........................... 5 1164 4.2 Structure of the PPP ................................ 5 1165 4.3 MIB Groups .......................................... 6 1166 4.4 Relationship to Interface and Interface Extensions 1167 Groups ............................................. 8 1168 5 Definitions ........................................... 10 1169 5.1 PPP Link Group ...................................... 11 1170 5.2 PPP LQR Group ....................................... 22 1171 5.3 PPP LQR Extensions Group ............................ 27 1172 5.4 PPP Tests ........................................... 29 1173 5.4.1 PPP Echo Test ..................................... 29 1174 5.4.2 PPP Discard Test .................................. 29 1175 6 Acknowledgements ...................................... 30 1176 7 Security Considerations ............................... 31 1177 8 References ............................................ 32