idnits 2.17.1 draft-ietf-vgmib-interfaces-mib-00.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-23) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (June 30, 1995) is 10525 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) == Unused Reference: '1' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1174, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '2') ** Obsolete normative reference: RFC 1448 (ref. '3') (Obsoleted by RFC 1905) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1573 (ref. '7') (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1443 (ref. '8') (Obsoleted by RFC 1903) ** Downref: Normative reference to an Historic RFC: RFC 1749 (ref. '9') Summary: 17 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft IEEE 802.12 Interface MIB June 30 1995 4 Definitions of Managed Objects for IEEE 802.12 Interfaces 6 June 30, 1995 8 John Flick 10 Hewlett Packard Company 11 8000 Foothills Blvd. M/S 5556 12 Roseville, CA 95747-5556 14 johnf@hprnd.rose.hp.com 16 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 1. Abstract 38 This memo defines an experimental portion of the Management 39 Information Base (MIB) for use with network management protocols in 40 TCP/IP-based internets. In particular, it defines objects for 41 managing network interfaces based on IEEE 802.12. 43 This memo does not specify a standard for the Internet community. 45 2. The SNMPv2 Network Management Framework 47 The SNMPv2 Network Management Framework consists of four major 48 components. They are: 50 o RFC 1442 which defines the SMI, the mechanisms used for 51 describing and naming objects for the purpose of management. 53 o STD 17, RFC 1213 defines MIB-II, the core set of managed 54 objects for the Internet suite of protocols. 56 o RFC 1445 which defines the administrative and other 57 architectural aspects of the framework. 59 o RFC 1448 which defines the protocol used for network access 60 to managed objects. 62 The Framework permits new objects to be defined for the purpose of 63 experimentation and evaluation. 65 2.1. Object Definitions 67 Managed objects are accessed via a virtual information store, termed 68 the Management Information Base or MIB. Objects in the MIB are 69 defined using the subset of Abstract Syntax Notation One (ASN.1) 70 defined in the SMI. In particular, each object object type is named 71 by an OBJECT IDENTIFIER, an administratively assigned name. The 72 object type together with an object instance serves to uniquely 73 identify a specific instantiation of the object. For human 74 convenience, we often use a textual string, termed the descriptor, to 75 refer to the object type. 77 3. Overview 79 Instances of these object types represent attributes of an interface 80 to a 100VG-AnyLAN communications medium. At present, 100VG-AnyLAN 81 media are identified by one value of the ifType object in the 82 Internet-standard MIB: 84 ieee80212(55) 86 For this interface, the value of the ifSpecific variable in the MIB- 87 II [4] has the OBJECT IDENTIFIER value: 89 dot12MIB OBJECT IDENTIFIER ::= { experimental 63 } 91 The definitions presented here are based on the IEEE Standard802.12, 92 [6] Clause 13 "Layer Management Functions And Services", and Annex E 93 "GDMO Specifications for Demand Priority Managed Objects". 94 Implementors of these MIB objects should note that the IEEE document 95 explicitly describes (in the form of Pascal pseudocode) when, where, 96 and how various MAC attributes are measured. The IEEE document also 97 describes the effects of MAC actions that may be invoked by 98 manipulating instances of the MIB objects defined here. 100 To the extent that some of the attributes defined in [6] are 101 represented by previously defined objects in the Internet-standard 102 MIB or in the Evolution of the Interfaces Group of MIB-II [7], such 103 attributes are not redundantly represented by objects defined in this 104 memo. Among the attributes represented by objects defined in other 105 memos are the number of octets transmitted or received on a 106 particular interface, the MAC address of an interface, and multicast 107 information associated with an interface. 109 3.1. MAC Addresses 111 All representations of MAC addresses in this MIB module, and in other 112 related MIB modules (like RFC 1573), are in "canonical" order defined 113 by 802.1a, i.e., as if it were transmitted least significant bit 114 first. This is true even if the interface is operating in token ring 115 framing mode, which requires MAC addresses to be transmitted most 116 significant bit first. 118 3.2. Relation to RFC 1213 120 This section applies only when this MIB is used in conjunction with 121 the "old" (i.e., pre-RFC 1573) interface group. 123 The relationship between a 100VG-AnyLAN interface and an interface in 124 the context of the Internet-standard MIB is one-to-one. As such, the 125 value of an ifIndex object instance can be directly used to identify 126 corresponding instances of the objects defined herein. 128 3.3. Relation to RFC 1573 130 RFC 1573, the Interface MIB Evolution, requires that any MIB which is 131 an adjunct of the Interface MIB, clarify specific areas within the 132 Interface MIB. These areas are intentionally left vague in RFC 1573 133 to avoid over constraining the MIB, thereby precluding management of 134 certain media-types. 136 Section 3.3 of RFC 1573 enumerates several areas which a media- 137 specific MIB must clarify. In addition, there are some objects in 138 RFC 1573 for which additional clarification of how to apply them to a 139 100VG-AnyLAN interface woule be helpful. Each of these areas is 140 addressed in a following subsection. The implementor is referred to 141 RFC 1573 in order to understand the general intent of these areas. 143 3.3.1. Layering Model 145 This MIB does not provide for layering. There are no sublayers. 147 3.3.2. Virtual Circuits 149 This medium does not support virtual circuits and this area is not 150 applicable to this MIB. 152 3.3.3. ifTestTable 154 This MIB does not define any tests for media instrumented by this 155 MIB. Implementation of the ifTestTable is not required. 157 3.3.4. ifRcvAddressTable 159 This table contains all IEEE addresses, unicast, multicast, and 160 broadcast, for which this interface will receive packets and forward 161 them up to a higher layer entity for consumption. In addition, when 162 the interface is using 802.5 framing mode, the ifRcvAddressTable will 163 contain the functional address mask. 165 In the event that the interface is part of a MAC bridge, this table 166 does not include unicast addresses which are accepted for possible 167 forwarding out some other port. This table is explicitly not 168 intended to provide a bridge address filtering mechanism. 170 3.3.5. ifPhysAddress 171 This object contains the IEEE 802.12 address which is placed in the 172 source-address field of any frames that originate at this interface. 173 Usually this will be kept in ROM on the interface hardware. Some 174 systems may set this address via software. 176 In a system where there are several such addresses the designer has a 177 tougher choice. The address chosen should be the one most likely to 178 be of use to network management (e.g. the address placed in ARP 179 responses for systems which are primarily IP systems). 181 If the designer truly can not choose, use of the factory-provided ROM 182 address is suggested. 184 If the address can not be determined, an octet string of zero length 185 should be returned. 187 The address is stored in binary in this object. The address is 188 stored in "canonical" bit order, that is, the Group Bit is positioned 189 as the low-order bit of the first octet. Thus, the first byte of a 190 multicast address would have the bit 0x01 set. This is true even 191 when the interface is using token ring framing mode, which transmits 192 addresses high-order bit first. 194 3.3.6. ifType 196 This MIB applies to interfaces which have the following ifType value: 198 ieee80212(55) 200 3.3.7. ifMtu 202 The value of ifMtu on a 100VG-AnyLAN interface will depend on the 203 type of framing that is in use on that interface. Changing the 204 dot12DesiredFramingType may have the effect of changing ifMtu after 205 the next time that the interface trains. 207 3.3.8. ifInErrors 209 On a 100VG-AnyLAN interface, ifInErrors will be the sum of 210 dot12InIPMErrors, dot12InOversizeFrameErrors, dot12InDataErrors, and 211 any additional internal errors that may occur in an implementation. 213 3.3.9. ifOutErrors 214 On a 100VG-AnyLAN interface, ifOutErrors will be equal to the number 215 of implementation-specific internal transmit errors on this 216 interface. 218 3.3.10. ifPromiscuousMode 220 ifPromiscuousMode reflects whether the interface has successfully 221 trained and is currently operating in promiscuous mode. 222 dot12DesiredPromiscStatus is used to select the promiscuous mode to 223 be requested in the next training attempt. Setting ifPromiscuousMode 224 will update dot12DesiredPromiscStatus and cause the interface to 225 attempt to retrain using the new promiscuous mode. After the 226 interface has retrained, ifPromiscuousMode will reflect the mode that 227 is in use, not the mode that was requested. 229 3.4. Relation to RFC 1749 231 When an IEEE 802.12 interface is operating in token ring framing 232 mode, and the end node supports token ring source routing, the agent 233 should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB 234 [9] for those interfaces. 236 3.5. Normal and High Priority Counters 238 The 100VG-AnyLAN interface MIB does not provide normal priority 239 transmit counters. Standardization of normal priority transmit 240 counters could not be justified -- ifOutUcastPkts, 241 ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, 242 dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should 243 suffice. Since 100VG-AnyLAN uses point-to-point links, this 244 information is available at the repeater end of the link if needed. 246 dot12InNormPriorityOctets includes octets of unreadable frames and 247 can be combined with dot12InHighPriorityOctets and ifOutOctets to 248 accurately calculate network utilization. 250 3.6. Mapping of IEEE 802.12 Managed Objects 252 IEEE 802.12 Managed Object Corresponding SNMP Object 254 oEndNode 255 .aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts 256 .aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts 257 .aDataErrorFramesReceived dot12InDataErrors 258 .aDesiredFramingType dot12DesiredFramingType 259 .aDesiredPromiscuousStatus dot12DesiredPromiscStatus 260 .aFramesTransmitted IF-MIB - ifOutUCastPkts + 261 ifOutMulticastPkts + 262 ifOutBroadcastPkts 263 .aFramingCapability dot12FramingCapability 264 .aFunctionalAddresses IF-MIB - ifRcvAddressTable 265 .aHighPriorityFramesReceived dot12InHighPriorityFrames 266 .aHighPriorityFramesTransmitted dot12OutHighPriorityFrames 267 .aHighPriorityOctetsReceived dot12InHighPriorityOctets 268 dot12InHCHighPriorityOctets 269 .aHighPriorityOctetsTransmitted dot12OutHighPriorityOctets 270 dot12OutHCHighPriorityOctets 271 .aIPMFramesReceived dot12InIPMErrors 272 .aLastTrainingConfig dot12LastTrainingConfig 273 .aMACID IF-MIB - ifIndex 274 .aMACStatus dot12Status 275 .aMACVersion dot12TrainingVersion 276 .aMediaType dot12PMDType 277 .aMulticastFramesReceived IF-MIB - ifInMulticastPkts 278 .aMulticastFramesTransmitted IF-MIB - ifOutMulticastPkts 279 .aMulticastReceiveStatus IF-MIB - ifRcvAddressTable 280 .aNormalPriorityFramesReceived dot12InNormPriorityFrames 281 .aNormalPriorityOctetsReceived dot12InNormPriorityOctets 282 dot12InHCNormPriorityOctets 283 .aNullAddressedFramesReceived dot12InNullAddressedFrames 284 .aOctetsTransmitted IF-MIB - ifOutOctets 285 ifHCOutOctets 286 .aOversizeFramesReceived dot12InOversizeFrameErrors 287 .aReadableFramesReceived IF-MIB - ifInUcastPkts + 288 ifInMulticastPkts + 289 ifInBroadcastPkts 290 .aReadableOctetsReceived IF-MIB - ifInOctets 291 ifHCInOctets 292 .aReadMulticastList IF-MIB - ifRcvAddressTable 293 .aReadWriteMACAddress IF-MIB - ifPhysAddress 294 .aTransitionsIntoTraining dot12TransitionIntoTrainings 295 .acAddGroupAddress IF-MIB - ifRcvAddressTable 296 .acClose dot12Commands: 'close' 297 .acDeleteGroupAddress IF-MIB - ifRcvAddressTable 298 .acExecuteSelftest IF-MIB - ifAdminStatus 299 .acInitializeMAC dot12Commands: 'reset' 300 .acOpen dot12Commands: 'open' 302 4. Definitions 304 DOT12-IF-MIB DEFINITIONS ::= BEGIN 306 IMPORTS 307 experimental, Counter32, Counter64, OBJECT-TYPE, 308 MODULE-IDENTITY, OBJECT-IDENTITY 309 FROM SNMPv2-SMI 310 MODULE-COMPLIANCE, OBJECT-GROUP 311 FROM SNMPv2-CONF 312 ifIndex 313 FROM IF-MIB; 315 dot12MIB MODULE-IDENTITY 316 LAST-UPDATED "9506280207Z" 317 ORGANIZATION "Hewlett Packard Company, 318 Roseville Networks Division" 319 CONTACT-INFO 320 " John Flick 322 Postal: Hewlett Packard Company 323 8000 Foothills Blvd. M/S 5556 324 Roseville, CA 95747-5556 325 Tel: +1 916 785 4018 326 Fax: +1 916 785 3583 328 E-mail: johnf@hprnd.rose.hp.com" 329 DESCRIPTION 330 "This MIB module describes objects for 331 managing 100VG-AnyLAN interfaces." 332 ::= { experimental 63 } 333 -- move to { transmission 55 } 335 dot12MIBObjects OBJECT IDENTIFIER ::= { dot12MIB 1 } 337 -- object identifiers for tranceiver types 338 -- See dot12PMDType and vgRptrPMDType in the 802.12 Repeater 339 -- MIB for usage. 341 dot12XcvrTypes OBJECT IDENTIFIER ::= { dot12MIB 3 } 343 dot12XcvrTypeUTP4 OBJECT-IDENTITY 344 STATUS current 345 DESCRIPTION 346 "Object identifier for a 4-pair unshielded twisted 347 pair 802.12 tranceiver" 348 ::= { dot12XcvrTypes 1 } 350 dot12XcvrTypeSTP2 OBJECT-IDENTITY 351 STATUS current 352 DESCRIPTION 353 "Object identifier for a 2-pair shielded twisted 354 pair 802.12 tranceiver." 355 ::= { dot12XcvrTypes 2 } 357 dot12XcvrTypeFibre OBJECT-IDENTITY 358 STATUS current 359 DESCRIPTION 360 "Object identifier for a 802.12 fibre optic 361 tranceiver." 362 ::= { dot12XcvrTypes 3 } 364 dot12ConfigTable OBJECT-TYPE 365 SYNTAX SEQUENCE OF Dot12ConfigEntry 366 MAX-ACCESS not-accessible 367 STATUS current 368 DESCRIPTION 369 "Configuration information for a collection of 370 802.12 interfaces attached to a particular 371 system." 372 ::= { dot12MIBObjects 1 } 374 dot12ConfigEntry OBJECT-TYPE 375 SYNTAX Dot12ConfigEntry 376 MAX-ACCESS not-accessible 377 STATUS current 378 DESCRIPTION 379 "Configuration for a particular interface to an 380 802.12 medium." 381 INDEX { ifIndex } 382 ::= { dot12ConfigTable 1 } 384 Dot12ConfigEntry ::= 385 SEQUENCE { 386 dot12DesiredFramingType INTEGER, 387 dot12FramingCapability INTEGER, 388 dot12DesiredPromiscStatus INTEGER, 389 dot12TrainingVersion INTEGER, 390 dot12LastTrainingConfig OCTET STRING, 391 dot12Commands INTEGER, 392 dot12Status INTEGER 393 } 395 dot12DesiredFramingType OBJECT-TYPE 396 SYNTAX INTEGER { 397 frameType88023(1), 398 frameType88025(2), 399 frameTypeEither(3) 400 } 401 MAX-ACCESS read-write 402 STATUS current 403 DESCRIPTION 404 "The type of framing which will be requested by 405 the interface during the next interface MAC 406 initialization or open action." 407 REFERENCE 408 "IEEE 802.12, Layer Management, 13.2.5.2.1, 409 aDesiredFramingType." 410 ::= { dot12ConfigEntry 1 } 412 dot12FramingCapability OBJECT-TYPE 413 SYNTAX INTEGER { 414 frameType88023(1), 415 frameType88025(2), 416 frameTypeEither(3) 417 } 418 MAX-ACCESS read-only 419 STATUS current 420 DESCRIPTION 421 "The type of framing this interface is capable of 422 supporting." 423 REFERENCE 424 "IEEE 802.12, Layer Management, 13.2.5.2.1, 425 aFramingCapability." 426 ::= { dot12ConfigEntry 2 } 428 dot12DesiredPromiscStatus OBJECT-TYPE 429 SYNTAX INTEGER { 430 singleAddressMode(1), 431 promiscuousMode(2) 432 } 433 MAX-ACCESS read-write 434 STATUS current 435 DESCRIPTION 436 "This object is used to select the promiscuous 437 mode that this interface will request in the next 438 training packet issued on this interface. 439 Whether the repeater grants the requested mode 440 must be verified by examining the state of the PP 441 bits in the corresponding instance of 442 dot12LastTrainingConfig. 444 Note that this object indicates the desired mode 445 for the next time the interface trains. The 446 currently active mode will be reflected in 447 dot12LastTrainingConfig and in ifPromiscuousMode." 448 REFERENCE 449 "IEEE 802.12, Layer Management, 13.2.5.2.1, 450 aDesiredPromiscuousStatus." 451 ::= { dot12ConfigEntry 3 } 453 dot12TrainingVersion OBJECT-TYPE 454 SYNTAX INTEGER (0..7) 455 MAX-ACCESS read-only 456 STATUS current 457 DESCRIPTION 458 "The value that will be used in the version bits 459 (vvv bits) in training request frames on this 460 interface. This is the highest version number 461 supported by this MAC." 462 REFERENCE 463 "IEEE 802.12, Layer Management, 13.2.5.2.1, 464 aMACVersion." 465 ::= { dot12ConfigEntry 4 } 467 dot12LastTrainingConfig OBJECT-TYPE 468 SYNTAX OCTET STRING (SIZE(2)) 469 MAX-ACCESS read-only 470 STATUS current 471 DESCRIPTION 472 "This 16 bit field contains the configuration 473 bits from the most recent error-free training 474 response frame received in response to training 475 initiated by this interface. 477 First Octet: Second Octet: 479 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 480 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 481 |v|v|v|D|C|N|0|0| |0|0|0|F|F|P|P|R| 482 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 484 vvv: The version of the 802.12 training 485 protocol with which the training 486 responder is compliant 487 D: 0 = no duplicate address has been 488 detected 489 1 = duplicate address has been detected 490 C: 0 = the requested configuration is 491 compatible with the port 492 1 = the requested configuration is not 493 compatible with the port. The FF, 494 PP and R bits indicate the 495 configuration which would be 496 allowed (providing N = 0). 497 N: 0 = access will be allowed, providing 498 the configuration is compatible (C 499 = 0). 500 1 = access not allowed because of 501 security restrictions 502 FF: 00 = frameType88023 will be used 503 01 = frameType88025 will be used 504 10 = reserved 505 11 = reserved 506 PP: 00 = singleAddressMode will be used 507 01 = promiscuousMode will be used 508 10 = reserved 509 11 = reserved 510 R: 0 = requested access as an end node is 511 allowed 512 1 = requested access as a repeater is 513 allowed 515 Note that dot12Status must be examined to see if 516 any error-free training frames have been 517 received." 518 REFERENCE 519 "IEEE 802.12, Layer Management, 13.2.5.2.1, 520 aLastTrainingConfig." 521 ::= { dot12ConfigEntry 5 } 523 -- { dot12ConfigEntry 6 } is unassigned 525 dot12Commands OBJECT-TYPE 526 SYNTAX INTEGER { 527 noOp(1), 528 open(2), 529 reset(3), 530 close(4) 531 } 532 MAX-ACCESS read-write 533 STATUS current 534 DESCRIPTION 535 "If the current value of dot12Status is 'closed', 536 setting the value of this object to 'open' will 537 cause this interface to enter the 'opening' 538 state, and initiate training on this interface. 539 The progress and success of the open is given by 540 the values of the dot12Status object. Setting 541 this object to 'open' when dot12Status has a value 542 other than 'closed' has no effect. 544 Setting the value of this object to 'close' will 545 move this interface into the 'closed' state and 546 cause all transmit and receive actions to stop. 547 This object will then have to be set to 'open' in 548 order to reinitiate training. 550 Setting the value of this object to 'reset' will 551 reset the interface. On a reset, all MIB 552 counters should retain their values. This will 553 cause the MAC to initiate an acInitializeMAC 554 action as specified in IEEE 802.12. The MAC will 555 then initiate training. 557 Setting the value of this object to 'noOp' has no 558 effect. 560 When read, this object will always have a value 561 of 'noOp'. 563 The 'open' and 'close' values correspond to the 564 'up' and 'down' values of MIB-II's ifAdminStatus 565 and ifOperStatus, i.e., the setting of 566 ifAdminStatus and dot12Commands affects the values 567 of both ifOperStatus and dot12Status." 568 REFERENCE 569 "IEEE 802.12, Layer Management, 13.2.5.2.2, 570 acOpen, acClose, acInitializeMAC. 571 Also, RFC1231 IEEE802.5 Token Ring MIB, 572 dot5Commands." 573 ::= { dot12ConfigEntry 7 } 575 dot12Status OBJECT-TYPE 576 SYNTAX INTEGER { 577 opened(1), 578 closed(2), 579 opening(3), 580 openFailure(5), 581 linkFailure(6) 582 } 583 MAX-ACCESS read-only 584 STATUS current 585 DESCRIPTION 586 "The current interface status with respect to 587 training. One of the following values: 589 opened - Training has completed 590 successfully. 591 closed - MAC has been disabled by 592 setting dot12Commands to 593 'close'. 594 opening - MAC is in training. 595 Training_Down has been received 596 from the repeater. 597 openFailure - Passed 24 error-free packets, 598 but there is a problem, noted 599 in the training configuration 600 bits (dot12LastTrainingConfig). 601 linkFailure - Training_Down not received, or 602 could not pass 24 error-free 603 packets. 605 Whenever the dot12Commands object is set to 606 'close', the MAC will go silent, dot12Status will 607 be 'closed', and ifOperStatus will be 'down'. 609 When the dot12Commands object is set to 'open', 610 the MAC will send Training_Up to the repeater and 611 initially go to the 'linkFailure' state. When 612 the repeater sends back Training_Down, dot12Status 613 will change to the 'opening' state and training 614 packets will be transferred. 616 After all of the training packets have been 617 passed, dot12Status will change to 'linkFailure' 618 if 24 consecutive error-free packets were not 619 passed, 'opened' if 24 consecutive error-free 620 packets were passed and the training 621 configuration bits were OK, or 'openFailure' if 622 there were 24 consecutive error-free packets, but 623 there was a problem with the training 624 configuration bits. 626 When in the 'openFailure' state, the 627 dot12LastTrainingConfig object will contain the 628 configuration bits from the last training 629 response packet which can be examined to 630 determine the exact reason for the training 631 configuration failure. 633 If training did not succeed (dot12Status is 634 'linkFailure' or 'openFailure), the entire 635 process will be restarted after 636 MAC_Retraining_Delay_Timer seconds. 638 If training does succeed (dot12Status is 639 'opened'), ifOperStatus will be 'up'." 640 REFERENCE 641 "IEEE 802.12, Layer Management, 13.2.5.2.1, 642 aMACStatus." 643 ::= { dot12ConfigEntry 8 } 645 dot12StatTable OBJECT-TYPE 646 SYNTAX SEQUENCE OF Dot12StatEntry 647 MAX-ACCESS not-accessible 648 STATUS current 649 DESCRIPTION 650 "Statistics for a collection of 802.12 interfaces 651 attached to a particular system." 652 ::= { dot12MIBObjects 2 } 654 dot12StatEntry OBJECT-TYPE 655 SYNTAX Dot12StatEntry 656 MAX-ACCESS not-accessible 657 STATUS current 658 DESCRIPTION 659 "Statistics for a particular interface to an 660 802.12 medium. The receive statistics in this 661 table apply only to packets received by this 662 station (i.e., packets whose destination address 663 is either the local station address, the 664 broadcast address, or a multicast address that 665 this station is receiving, unless the station is 666 in promiscuous mode)." 667 INDEX { ifIndex } 668 ::= { dot12StatTable 1 } 670 Dot12StatEntry ::= 671 SEQUENCE { 672 dot12InHighPriorityFrames Counter32, 673 dot12InHighPriorityOctets Counter32, 674 dot12InNormPriorityFrames Counter32, 675 dot12InNormPriorityOctets Counter32, 676 dot12InIPMErrors Counter32, 677 dot12InOversizeFrameErrors Counter32, 678 dot12InDataErrors Counter32, 679 dot12InNullAddressedFrames Counter32, 680 dot12OutHighPriorityFrames Counter32, 681 dot12OutHighPriorityOctets Counter32, 682 dot12TransitionIntoTrainings Counter32, 683 dot12HCInHighPriorityOctets Counter64, 684 dot12HCInNormPriorityOctets Counter64, 685 dot12HCOutHighPriorityOctets Counter64 687 } 689 dot12InHighPriorityFrames OBJECT-TYPE 690 SYNTAX Counter32 691 MAX-ACCESS read-only 692 STATUS current 693 DESCRIPTION 694 "This object is a count of high priority frames 695 that have been received on this interface. 696 Includes both good and bad high priority frames, 697 as well as high priority training frames. Does 698 not include normal priority frames which were 699 priority promoted." 700 REFERENCE 701 "IEEE 802.12, Layer Management, 13.2.5.2.1, 702 aHighPriorityFramesReceived." 703 ::= { dot12StatEntry 1 } 705 dot12InHighPriorityOctets OBJECT-TYPE 706 SYNTAX Counter32 707 MAX-ACCESS read-only 708 STATUS current 709 DESCRIPTION 710 "This object is a count of the number of octets 711 contained in high priority frames that have been 712 received on this interface. This counter is 713 incremented by OctetCount for each frame received 714 on this interface which is counted by 715 dot12InHighPriorityFrames. 717 Note that this counter will roll over very 718 quickly. It is provided for backward 719 compatibility for Network Management protocols 720 that do not support 64 bit counters (e.g. SNMP 721 version 1)." 722 REFERENCE 723 "IEEE 802.12, Layer Management, 13.2.5.2.1, 724 aHighPriorityOctetsReceived." 725 ::= { dot12StatEntry 2 } 727 dot12InNormPriorityFrames OBJECT-TYPE 728 SYNTAX Counter32 729 MAX-ACCESS read-only 730 STATUS current 731 DESCRIPTION 732 "This object is a count of normal priority frames 733 that have been received on this interface. 734 Includes both good and bad normal priority 735 frames, as well as normal priority training 736 frames and normal priority frames which were 737 priority promoted." 738 REFERENCE 739 "IEEE 802.12, Layer Management, 13.2.5.2.1, 740 aNormalPriorityFramesReceived." 741 ::= { dot12StatEntry 3 } 743 dot12InNormPriorityOctets OBJECT-TYPE 744 SYNTAX Counter32 745 MAX-ACCESS read-only 746 STATUS current 747 DESCRIPTION 748 "This object is a count of the number of octets 749 contained in normal priority frames that have 750 been received on this interface. This counter is 751 incremented by OctetCount for each frame received 752 on this interface which is counted by 753 dot12InNormPriorityFrames. 755 Note that this counter will roll over very 756 quickly. It is provided for backward 757 compatibility for Network Management protocols 758 that do not support 64 bit counters (e.g. SNMP 759 version 1)." 760 REFERENCE 761 "IEEE 802.12, Layer Management, 13.2.5.2.1, 762 aNormalPriorityOctetsReceived." 763 ::= { dot12StatEntry 4 } 765 dot12InIPMErrors OBJECT-TYPE 766 SYNTAX Counter32 767 MAX-ACCESS read-only 768 STATUS current 769 DESCRIPTION 770 "This object is a count of the number of frames 771 that have been received on this interface with an 772 invalid packet marker and no PMI errors. A 773 repeater will write an invalid packet marker to 774 the end of a frame containing errors as it is 775 forwarded through the repeater to the other 776 ports. This counter is incremented by one for 777 each frame received on this interface which has 778 had an invalid packet marker added to the end of 779 the frame." 780 REFERENCE 781 "IEEE 802.12, Layer Management, 13.2.5.2.1, 782 aIPMFramesReceived." 784 ::= { dot12StatEntry 5 } 786 dot12InOversizeFrameErrors OBJECT-TYPE 787 SYNTAX Counter32 788 MAX-ACCESS read-only 789 STATUS current 790 DESCRIPTION 791 "This object is a count of oversize frames 792 received on this interface. This counter is 793 incremented by one for each frame received on 794 this interface whose OctetCount is larger than 795 the maximum legal frame size. The frame size 796 which causes this counter to increment is 797 dependent on the current framing type." 798 REFERENCE 799 "IEEE 802.12, Layer Management, 13.2.5.2.1, 800 aOversizeFramesReceived." 801 ::= { dot12StatEntry 6 } 803 dot12InDataErrors OBJECT-TYPE 804 SYNTAX Counter32 805 MAX-ACCESS read-only 806 STATUS current 807 DESCRIPTION 808 "This object is a count of errored frames 809 received on this interface. This counter is 810 incremented by one for each frame received on 811 this interface with any of the following errors: 812 bad FCS (with no IPM), PMI errors (excluding 813 frames with an IPM as the only PMI error), 814 undersize, bad start of frame delimiter, or bad 815 end of packet marker. Does not include frames 816 counted by dot12InIPMErrors, 817 dot12InNullAddressedFrames, or 818 dot12InOversizeFrameErrors. 820 This counter indicates problems with the cable 821 directly attached to this interface, while 822 dot12InIPMErrors indicates problems with remote 823 cables." 824 REFERENCE 825 "IEEE 802.12, Layer Management, 13.2.5.2.1, 826 aDataErrorFramesReceived." 827 ::= { dot12StatEntry 7 } 829 dot12InNullAddressedFrames OBJECT-TYPE 830 SYNTAX Counter32 831 MAX-ACCESS read-only 832 STATUS current 833 DESCRIPTION 834 "This object is a count of null addressed frames 835 received on this interface. This counter is 836 incremented by one for each frame received on 837 this interface with a destination MAC address 838 consisting of all zero bits. Both void and 839 training frames are included in this counter. 841 Note that since this station would normally not 842 receive null addressed frames, this counter is 843 only incremented when this station is operating 844 in promiscuous mode." 845 REFERENCE 846 "IEEE 802.12, Layer Management, 13.2.5.2.1, 847 aNullAddressedFramesReceived." 848 ::= { dot12StatEntry 8 } 850 dot12OutHighPriorityFrames OBJECT-TYPE 851 SYNTAX Counter32 852 MAX-ACCESS read-only 853 STATUS current 854 DESCRIPTION 855 "This counter is incremented by one for each high 856 priority frame successfully transmitted out this 857 interface." 858 REFERENCE 859 "IEEE 802.12, Layer Management, 13.2.5.2.1, 860 aHighPriorityFramesTransmitted." 861 ::= { dot12StatEntry 9 } 863 dot12OutHighPriorityOctets OBJECT-TYPE 864 SYNTAX Counter32 865 MAX-ACCESS read-only 866 STATUS current 867 DESCRIPTION 868 "This counter is incremented by OctetCount for 869 each frame counted by dot12OutHighPriorityFrames. 871 Note that this counter will roll over very 872 quickly. It is provided for backward 873 compatibility for Network Management protocols 874 that do not support 64 bit counters (e.g. SNMP 875 version 1)." 876 REFERENCE 877 "IEEE 802.12, Layer Management, 13.2.5.2.1, 878 aHighPriorityOctetsTransmitted." 879 ::= { dot12StatEntry 10 } 881 dot12TransitionIntoTrainings OBJECT-TYPE 882 SYNTAX Counter32 883 MAX-ACCESS read-only 884 STATUS current 885 DESCRIPTION 886 "This object is a count of the number of times 887 this interface has entered the training state. 888 This counter is incremented by one each time 889 dot12Status transitions to 'linkFailure' from any 890 state other than 'opening' or 'openFailure'." 891 REFERENCE 892 "IEEE 802.12, Layer Management, 13.2.5.2.1, 893 aTransitionsIntoTraining." 894 ::= { dot12StatEntry 11 } 896 dot12HCInHighPriorityOctets OBJECT-TYPE 897 SYNTAX Counter64 898 MAX-ACCESS read-only 899 STATUS current 900 DESCRIPTION 901 "This object is a count of the number of octets 902 contained in high priority frames that have been 903 received on this interface. This counter is 904 incremented by OctetCount for each frame received 905 on this interface which is counted by 906 dot12InHighPriorityFrames. 908 This counter is a 64 bit version of 909 dot12InHighPriorityOctets. It should be used by 910 Network Management protocols which support 64 bit 911 counters (e.g. SNMPv2)." 912 REFERENCE 913 "IEEE 802.12, Layer Management, 13.2.5.2.1, 914 aHighPriorityOctetsReceived." 915 ::= { dot12StatEntry 12 } 917 dot12HCInNormPriorityOctets OBJECT-TYPE 918 SYNTAX Counter64 919 MAX-ACCESS read-only 920 STATUS current 921 DESCRIPTION 922 "This object is a count of the number of octets 923 contained in normal priority frames that have 924 been received on this interface. This counter is 925 incremented by OctetCount for each frame received 926 on this interface which is counted by 927 dot12InNormPriorityFrames. 929 This counter is a 64 bit version of 930 dot12InNormPriorityOctets. It should be used by 931 Network Management protocols which support 64 bit 932 counters (e.g. SNMPv2)." 933 REFERENCE 934 "IEEE 802.12, Layer Management, 13.2.5.2.1, 935 aNormalPriorityOctetsReceived." 936 ::= { dot12StatEntry 13 } 938 dot12HCOutHighPriorityOctets OBJECT-TYPE 939 SYNTAX Counter64 940 MAX-ACCESS read-only 941 STATUS current 942 DESCRIPTION 943 "This counter is incremented by OctetCount for 944 each frame counted by dot12OutHighPriorityFrames. 946 This counter is a 64 bit version of 947 dot12OutHighPriorityOctets. It should be used by 948 Network Management protocols which support 64 bit 949 counters (e.g. SNMPv2)." 950 REFERENCE 951 "IEEE 802.12, Layer Management, 13.2.5.2.1, 952 aHighPriorityOctetsTransmitted." 953 ::= { dot12StatEntry 14 } 955 dot12PMDTable OBJECT-TYPE 956 SYNTAX SEQUENCE OF Dot12PMDEntry 957 MAX-ACCESS not-accessible 958 STATUS current 959 DESCRIPTION 960 "Table of information about physical media dependent 961 connectors attached to interfaces." 962 ::= { dot12MIBObjects 3 } 964 dot12PMDEntry OBJECT-TYPE 965 SYNTAX Dot12PMDEntry 966 MAX-ACCESS not-accessible 967 STATUS current 968 DESCRIPTION 969 "An entry in the table, containing information about 970 a single physical media connector." 971 INDEX { ifIndex, dot12PMDIndex } 972 ::= { dot12PMDTable 1 } 974 Dot12PMDEntry ::= 975 SEQUENCE { 976 dot12PMDIndex INTEGER, 977 dot12PMDType OBJECT IDENTIFIER, 978 dot12PMDStatus INTEGER 979 } 981 dot12PMDIndex OBJECT-TYPE 982 SYNTAX INTEGER (1..9) 983 MAX-ACCESS not-accessible 984 STATUS current 985 DESCRIPTION 986 "This variable uniquely identifies the physical 987 media connector attached to this interface that is 988 described by this entry." 989 ::= { dot12PMDEntry 1 } 991 dot12PMDType OBJECT-TYPE 992 SYNTAX OBJECT IDENTIFIER 993 MAX-ACCESS read-only 994 STATUS current 995 DESCRIPTION 996 "The object identifies the type of physical media 997 in use. An initial set of tranceiver types is 998 defined above. The assignment of new types of 999 tranceivers is managed by the IANA. If the 1000 tranceiver type is unknown, the object identifier 1002 dot12XcvrTypeUnknown 1003 OBJECT IDENTIFIER ::= { 0 0 } 1005 is returned." 1006 REFERENCE 1007 "IEEE 802.12, Layer Management, 13.2.5.2.1, 1008 aMediaType." 1009 ::= { dot12PMDEntry 2 } 1011 dot12PMDStatus OBJECT-TYPE 1012 SYNTAX INTEGER { 1013 other(1), 1014 unknown(2), 1015 operational(3), 1016 standby(4), 1017 notPresent(5) 1018 } 1019 MAX-ACCESS read-write 1020 STATUS current 1021 DESCRIPTION 1022 "The current state of the tranceiver. This object 1023 may be implemented as a read-only object by those 1024 agents that do not implement software control of 1025 the tranceiver state. Some agents may not support 1026 setting the value of this object to some of the 1027 enumerated values. 1029 The value other(1) is returned if the tranceiver 1030 is in a state other than one of the states 2 1031 through 5. 1033 The value unknown(2) is returned when the 1034 tranceiver's true state is unknown; for example, 1035 when it is being initialized. 1037 A tranceiver in the operational(3) state is fully 1038 functional, operates, and passes signals to the 1039 media independent interface of its attached DTE or 1040 repeater port. 1042 A tranceiver in standby(4) state is not passing 1043 network or training frames, and is not passing 1044 signals to the media independent interface of its 1045 attached DTE or repeater port. 1047 The value notPresent(5) is used to indicate that 1048 the media independent interface has detected that 1049 there is no tranceiver present." 1050 ::= { dot12PMDEntry 3 } 1052 -- conformance information 1054 dot12Conformance OBJECT IDENTIFIER ::= { dot12MIB 2 } 1056 dot12Compliances OBJECT IDENTIFIER ::= { dot12Conformance 1 } 1057 dot12Groups OBJECT IDENTIFIER ::= { dot12Conformance 2 } 1059 -- compliance statements 1061 dot12Compliance MODULE-COMPLIANCE 1062 STATUS current 1063 DESCRIPTION 1064 "The compliance statement for managed network 1065 entities that have 802.12 interfaces." 1067 MODULE -- this module 1068 MANDATORY-GROUPS { dot12ConfigGroup, dot12StatsGroup, 1069 dot12PMDGroup } 1071 OBJECT dot12PMDStatus 1072 SYNTAX INTEGER { 1073 operational(3) 1074 } 1075 WRITE-SYNTAX INTEGER { 1076 operational(3), 1077 standby(4) 1078 } 1079 MIN-ACCESS read-only 1080 DESCRIPTION 1081 "Write access to this object is not required. 1082 The only value that an agent must support is 1083 operational(3). Only the operational(3) and 1084 standby(4) values make sense in a set 1085 operation." 1086 ::= { dot12Compliances 1 } 1088 -- units of conformance 1090 dot12ConfigGroup OBJECT-GROUP 1091 OBJECTS { dot12DesiredFramingType, 1092 dot12FramingCapability, 1093 dot12DesiredPromiscStatus, 1094 dot12TrainingVersion, 1095 dot12LastTrainingConfig, 1096 dot12Commands, dot12Status } 1097 STATUS current 1098 DESCRIPTION 1099 "A collection of objects for managing the status 1100 and configuration of IEEE 802.12 interfaces." 1101 ::= { dot12Groups 1 } 1103 dot12StatsGroup OBJECT-GROUP 1104 OBJECTS { dot12InHighPriorityFrames, 1105 dot12InHighPriorityOctets, 1106 dot12InNormPriorityFrames, 1107 dot12InNormPriorityOctets, 1108 dot12InIPMErrors, 1109 dot12InOversizeFrameErrors, 1110 dot12InDataErrors, 1111 dot12InNullAddressedFrames, 1112 dot12OutHighPriorityFrames, 1113 dot12OutHighPriorityOctets, 1114 dot12TransitionIntoTrainings, 1115 dot12HCInHighPriorityOctets, 1116 dot12HCInNormPriorityOctets, 1117 dot12HCOutHighPriorityOctets } 1118 STATUS current 1119 DESCRIPTION 1120 "A collection of objects providing statistics for 1121 IEEE 802.12 interfaces." 1122 ::= { dot12Groups 2 } 1124 dot12PMDGroup OBJECT-GROUP 1125 OBJECTS { dot12PMDType, dot12PMDStatus } 1126 STATUS current 1127 DESCRIPTION 1128 "A collection of objects for managing the physical 1129 media dependent layer of an IEEE 802.12 interface." 1130 ::= { dot12Groups 3 } 1132 END 1134 5. Acknowledgements 1136 This document was produced by the IETF 100VG-AnyLAN Working Group. 1137 It is based on the work of IEEE 802.12. 1139 6. References 1141 [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1142 of Management Information for version 2 of the Simple Network 1143 Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., 1144 Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1145 University, April 1993. 1147 [2] Galvin, J., and K. McCloghrie, "Administrative Model for version 1148 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, 1149 Trusted Information Systems, Hughes LAN Systems, April 1993. 1151 [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1152 Operations for version 2 of the Simple Network Management 1153 Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN 1154 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1155 University, April 1993. 1157 [4] McCloghrie, K., and M. Rose, "Management Information Base for 1158 Network Management of TCP/IP-based internets - MIB-II", STD 17, 1159 RFC 1213, Hughes LAN Systems, Performance Systems International, 1160 March 1991. 1162 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1163 Network Management Protocol", RFC 1157, SNMP Research, 1164 Performance Systems International, Performance Systems 1165 International, MIT Laboratory for Computer Science, May 1990. 1167 [6] IEEE, "Demand Priority Access Method, Physical Layer and Repeater 1168 Specifications for 100 Mb/s Operation", IEEE Standard 802.12" 1170 [7] McCloghrie, K., and Kastenholz, F., "Evolution of the Interfaces 1171 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 1172 January 1994. 1174 [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1175 Conventions for version 2 of the Simple Network Management 1176 Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN 1177 Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1178 University, April 1993. 1180 [9] McCloghrie, K., Baker, F., and Decker, E., "IEEE 802.5 Station 1181 Source Routing MIB using SMIv2", RFC 1749, cisco Systems, Inc., 1182 December, 1994. 1184 7. Security Considerations 1186 Security issues are not discussed in this memo. 1188 8. Author's Address 1190 John Flick 1191 Hewlett Packard Company 1192 8000 Foothills Blvd. M/S 5556 1193 Roseville, CA 95747-5556 1195 Phone: +1 916 785 4018 1196 Email: johnf@hprnd.rose.hp.com 1198 Table of Contents 1200 1. Abstract ................................................... 2 1201 2. The SNMPv2 Network Management Framework .................... 2 1202 2.1. Object Definitions ....................................... 2 1203 3. Overview ................................................... 2 1204 3.1. MAC Addresses ............................................ 3 1205 3.2. Relation to RFC 1213 ..................................... 3 1206 3.3. Relation to RFC 1573 ..................................... 4 1207 3.3.1. Layering Model ......................................... 4 1208 3.3.2. Virtual Circuits ....................................... 4 1209 3.3.3. ifTestTable ............................................ 4 1210 3.3.4. ifRcvAddressTable ...................................... 4 1211 3.3.5. ifPhysAddress .......................................... 4 1212 3.3.6. ifType ................................................. 5 1213 3.3.7. ifMtu .................................................. 5 1214 3.3.8. ifInErrors ............................................. 5 1215 3.3.9. ifOutErrors ............................................ 5 1216 3.3.10. ifPromiscuousMode ..................................... 6 1217 3.4. Relation to RFC 1749 ..................................... 6 1218 3.5. Normal and High Priority Counters ........................ 6 1219 3.6. Mapping of IEEE 802.12 Managed Objects ................... 6 1220 4. Definitions ................................................ 8 1221 5. Acknowledgements ........................................... 25 1222 6. References ................................................. 25 1223 7. Security Considerations .................................... 26 1224 8. Author's Address ........................................... 26