idnits 2.17.1 draft-ietf-hubmib-power-ethernet-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages 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 are 36 instances of too long lines in the document, the longest one being 25 characters in excess of 72. ** The abstract seems to contain references ([RFC2665]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 806 has weird spacing: '...Port is deliv...' == Line 834 has weird spacing: '...reshold usage...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC2863], but that reference does not seem to mention RFC 2119 either. -- 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 (25 June 2001) is 8340 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: 'RFC2863' is mentioned on line 73, but not defined == Missing Reference: 'RFC2274' is mentioned on line 1045, but not defined ** Obsolete undefined reference: RFC 2274 (Obsoleted by RFC 2574) == Missing Reference: 'RFC2275' is mentioned on line 1046, but not defined ** Obsolete undefined reference: RFC 2275 (Obsoleted by RFC 2575) == Unused Reference: 'RFC2119' is defined on line 984, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2665 (Obsoleted by RFC 3635) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.3af' -- Possible downref: Normative reference to a draft: ref. 'PWR-MIB' Summary: 23 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Avi Berger 3 PowerDsine Inc. 4 Dan Romascanu 5 Avaya Inc. 6 25 June 2001 8 Power Ethernet (DTE Power via MDI) MIB 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This memo defines a portion of the Management Information Base (MIB) 38 for use with network management protocols in the Internet community. 39 The document proposes an extension to the Ethernet-like Interfaces 40 MIB [RFC2665] with a set of objects for managing a power Ethernet 41 Powered Device (PD) and/or Power Source Equipment (PSE). 43 Distribution of this memo is unlimited. 45 Table of Contents 47 Status of this Memo 1 48 Abstract 1 49 1 Introduction 2 50 2 The SNMP Management Framework 2 51 3 Overview 3 52 4 MIB Structure 4 53 5 Evolution of the Document, Limitations and Future Work 4 54 6 Changes log 4 55 7 Definitions 5 56 8 References 20 57 9 Intellectual Property 22 58 10 Security Considerations 22 59 11 Authors Addresses 23 60 A Full Copyright Statement 23 62 1. Introduction 64 This memo defines a portion of the Management Information Base (MIB) 65 for use with network management protocols in the Internet community. 66 In particular, it defines a set of MIB objects to manage a Power 67 Ethernet (DTE Power via MDI)Powered Device (PD) and/or power Source 68 Equipment (PSE). 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2863]. 74 2. The SNMP Management Framework 76 The SNMP Management Framework presently consists of five major 77 components: 79 o An overall architecture, described in RFC 2571 [RFC2571]. 81 o Mechanisms for describing and naming objects and events for the 82 purpose of management. The first version of this Structure of 83 Management Information (SMI) is called SMIv1 and described in 84 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 85 1215 [RFC1215]. The second version, called SMIv2, is described 86 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 87 STD 58, RFC 2580 [RFC2580]. 89 o Message protocols for transferring management information. The 90 first version of the SNMP message protocol is called SNMPv1 and 91 described in STD 15, RFC 1157 [RFC1157]. A second version of 92 the SNMP message protocol, which is not an Internet standards 93 track protocol, is called SNMPv2c and described in RFC 1901 94 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 95 message protocol is called SNMPv3 and described in RFC 1906 96 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 98 o Protocol operations for accessing management information. The 99 first set of protocol operations and associated PDU formats is 100 described in STD 15, RFC 1157 [RFC1157]. A second set of 101 protocol operations and associated PDU formats is described in 102 RFC 1905 [RFC1905]. 104 o A set of fundamental applications described in RFC 2573 105 [RFC2573] and the view-based access control mechanism described 106 in RFC 2575 [RFC2575]. 108 A more detailed introduction to the current SNMP Management Framework 109 can be found in RFC 2570 [RFC2570]. 111 Managed objects are accessed via a virtual information store, termed 112 the Management Information Base or MIB. Objects in the MIB are 113 defined using the mechanisms defined in the SMI. 115 This memo specifies a MIB module that is compliant to the SMIv2. A 116 MIB conforming to the SMIv1 can be produced through the appropriate 117 translations. The resulting translated MIB must be semantically 118 equivalent, except where objects or events are omitted because no 119 translation is possible (use of Counter64). Some machine readable 120 information in SMIv2 will be converted into textual descriptions in 121 SMIv1 during the translation process. However, this loss of machine 122 readable information is not considered to change the semantics of the 123 MIB. 125 3. Overview 127 The emergence of IP telephony as an application that allows for voice 128 applications to be run over the same infrastructure as data 129 applications led to the emergence of Ethernet IP phones, with similar 130 functions and characteristics as the traditional phones. Powering a 131 phone is one of these functions that are being taken as granted. The 132 IEEE 802.3 Working Group initiated a standard work on this subject, 133 currently known as the IEEE 802.3af work [IEEE-802.3af]. 135 The IEEE 802.3af WG will not define a full management interface, but 136 only the hardware registers that will allow for a management 137 interfaces to be built for a powered Ethernet device. The MIB module 138 defined in this document extends the Ethernet-like Interfaces MIB 139 [RFC2665] with the management objects required for the management of 140 the powered Ethernet devices and ports. 142 The following abbreviations are defined in [IEEE-802.3af] and will be 143 used with the same significance in this document: PSE - Power 144 Sourcing Equipment; PD - Powered Device 146 4. MIB Structure 148 This MIB objects are included in four MIB groups - three of them 149 include MIB tables, and the fourth scalar objects 151 The pethPsePortTable defines the objects used for the configuration 152 and describing the status of ports on a PSE device. Examples of PSE 153 devices are Ethernet switches that support power Ethernet and mid- 154 span boxes. 156 The pethPdPortTable defines the objects used for the configuration 157 and describing the status of ports on a PD device. Examples of PD 158 devices are Ethernet phones. 160 The pethMainPseObjects MIB group defines the management objects for a 161 managed main power source in a PSE device. Ethernet switches are one 162 example of boxes that would support these objects. 164 The pethTrapsControlTable includes objects that control the 165 transmission of traps by the agent to a management application. 167 5. Evolution of the Document, Limitations and Future Work 169 The IEEE 802.3af is at this stage work in progress. The scope of this 170 document is to initiate standards work in the IETF in order to allow 171 for the publication of a standard track document containing an SNMP 172 MIB simultaneously or close to the date of the publication of the 173 IEEE revised standard. It is expected that changes may be brought to 174 the IEEE proposal, and the Ethernet MIB Working Group will work in 175 order to ensure consistency between the two standards proposals. 177 6. Changes Log 179 The following changes were introduced relative to the first proposal 180 for a Power Ethernet MIB [PWR-MIB] 182 a. pethPsePortTable has to index pethPsePortGroupIndex & 183 pethPsePortIndex 185 b. pethPsePortIndex INTEGER instead of InterfaceIndex 187 c. Name change pethPsePortStatus insted of pethPsePortFaultError 189 d. Name change pethPsePortStatusClear instead of 190 pethPsePortFaultErrorClear 192 e. DESCRIPTION update for pethPsePortPowerDetectionStatus test(3) 193 f. DESCRIPTION update pethPsePortDetectionOperStatus off(2) 195 g. Adding to pethPsePortStatus one more item both(4) 197 h. Adding pethMainPseTable with a pethMainPseGroupIndex 199 i. Deletting to objects pethMainPseMaxVoltage & pethMainPseMinVoltage 201 j. Change SYNTAX of pethMainPseUsagePower form INTEGER to Gauge32 203 k. Change SYNTAX of pethMainPseUsageCurrent form INTEGER to Gauge32 205 l. Adding pethMainPseBackupActivated & pethMainPseBackupPresent 207 m. Adding Traps Control Objects 209 n. Adding Notifications Section (5 notifications ) 211 o. Adding pethTrapsControlGroup to Conformance Section 213 p. Adding pethPsePortPowerClassifications to pethPsePortTable Class 214 1-5 216 q. Adding pethPsePortPowerClassifications to pethPsePortGroup 218 r. Change in pethPsePortStatus none(1) to ok(1) 220 s. Change in DESCRIPTION of pethMainPseUsagePower from mW to Watt 222 t. Change pethMainPseUsagePower to pethMainPseConsumptionPower 224 u. Delete of pethMainPseUsageCurrent 226 7. Definitions 228 PETH-MIB DEFINITIONS ::= BEGIN 230 IMPORTS 231 MODULE-IDENTITY, OBJECT-TYPE, Integer32 , Gauge32,NOTIFICATION-TYPE 232 FROM SNMPv2-SMI 233 dot3 234 FROM EtherLike-MIB 235 TruthValue 236 FROM SNMPv2-TC 237 MODULE-COMPLIANCE, OBJECT-GROUP ,NOTIFICATION-GROUP 238 FROM SNMPv2-CONF; 240 powerEthernetMIB MODULE-IDENTITY 241 LAST-UPDATED "200106200000Z" -- June 20, 2001 242 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB 243 Working Group" 244 CONTACT-INFO 245 " 247 Chair: Dan Romascanu 248 Avaya Inc. 249 Tel: +972-3-645-8414 250 Email: dromasca@avaya.com 252 Editor: Avi Berger 253 PowerDsine Inc. 254 Tel: 972-9-7755100 Ext 307 255 Fax: 972-9-7755120 256 E-mail: avib@PowerDsine.com 257 " 259 DESCRIPTION 260 "The MIB module for for managing Powered Devices (PD) or 261 Power Source Equipment (PSE) working according to the IEEE 262 802.af Powere Ethernet (DTE Power via MDI) standard." 263 ::= { dot3 20 } 265 pethObjects OBJECT IDENTIFIER ::= { powerEthernetMIB 1 } 266 pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 2 } 267 pethConformance OBJECT IDENTIFIER ::= { powerEthernetMIB 3 } 269 -- pethAgentControl MIB group defines the control objects for the power 270 -- Ethernet Agent 272 pethPsePortTable OBJECT-TYPE 273 SYNTAX SEQUENCE OF PethPsePortEntry 274 MAX-ACCESS not-accessible 275 STATUS current 276 DESCRIPTION 277 "A table of objects that display and control the power 278 characteristics power Ethernet ports on a Power Source 279 Entity (PSE) device. This group will be implemented in 280 managed power Ethernet switches and mid-span devices." 281 ::= { pethObjects 1 } 283 pethPsePortEntry OBJECT-TYPE 284 SYNTAX PethPsePortEntry 285 MAX-ACCESS not-accessible 286 STATUS current 287 DESCRIPTION 288 "A set of objects that display and control the power 289 characteristics of a power Ethernet PSE port." 290 INDEX { pethPsePortGroupIndex , pethPsePortIndex } 291 ::= { pethPsePortTable 1 } 293 PethPsePortEntry ::= SEQUENCE { 294 pethPsePortGroupIndex 295 INTEGER, 296 pethPsePortIndex 297 INTEGER, 298 pethPsePortPowerEnable 299 INTEGER, 300 pethPsePortPowerIdPairsControl 301 TruthValue, 302 pethPsePortPowerIdPairs 303 INTEGER, 304 pethPsePortPowerDetectionStatus 305 INTEGER, 306 pethPsePortDetectionOperStatus 307 INTEGER, 308 pethPsePortPowerPriority 309 INTEGER, 310 pethPsePortDenyError 311 INTEGER, 312 pethPsePortStatus 313 INTEGER, 314 pethPsePortStatusClear 315 INTEGER, 316 pethPsePortType 317 INTEGER, 318 pethPsePortPowerClassifications 319 INTEGER 320 } 322 pethPsePortGroupIndex OBJECT-TYPE 323 SYNTAX INTEGER (1..2147483647) 324 MAX-ACCESS not-accessible 325 STATUS current 326 DESCRIPTION 327 "This variable uniquely identifies the group 328 containing the port to which power Ethernet PSE is connected. 329 Group means a box in the stack, or a module in a rack. 330 For non-modular devices the value 1 is recommended." 331 ::= { pethPsePortEntry 1 } 333 pethPsePortIndex OBJECT-TYPE 334 SYNTAX INTEGER(1..2147483647) 335 MAX-ACCESS not-accessible 336 STATUS current 337 DESCRIPTION 338 "This variable uniquely identifies the power Ethernet PSE 339 port within group pethPseGroupIndex to which the 340 power Ethernet PSE entry is connected." 341 ::= { pethPsePortEntry 2 } 343 pethPsePortPowerEnable OBJECT-TYPE 344 SYNTAX INTEGER { 345 auto(1), 346 off(2) 347 } 348 MAX-ACCESS read-write 349 STATUS current 350 DESCRIPTION 351 "Enables power supply on this port. 352 Setting this object at a value auto(1) enables power 353 and detection mechanism for this port. 354 Setting this object at a value off(2) disables power 355 and detection mechanism for this port." 356 ::= { pethPsePortEntry 3 } 358 pethPsePortPowerIdPairsControl OBJECT-TYPE 359 SYNTAX TruthValue 360 MAX-ACCESS read-only 361 STATUS current 362 DESCRIPTION 363 "Describes the capability of controlling the power 364 pairs functionality to switch pins for sourcing power." 365 ::= { pethPsePortEntry 4 } 367 pethPsePortPowerIdPairs OBJECT-TYPE 368 SYNTAX INTEGER { 369 signal(1), 370 spare(2), 371 both(3) 372 } 373 MAX-ACCESS read-write 374 STATUS current 375 DESCRIPTION 376 "Describes or controls the pairs in use. If the value of 377 pethPsePortPowerIdpairsControl is true, thisobject is 378 writable. 379 A value of signal(1) menas that the signal pairs 380 only are in use. 382 A value of spare(2) means that the spare pairs 383 only are in use. 384 A value of both(3) means that both the signal 385 and the spare pairs are in use." 386 ::= { pethPsePortEntry 5 } 388 pethPsePortPowerDetectionStatus OBJECT-TYPE 389 SYNTAX INTEGER { 390 auto(1), 391 off(2), 392 test(3) 393 } 394 MAX-ACCESS read-write 395 STATUS current 396 DESCRIPTION 397 "Controls the power detection mechanism of the port. 398 Setting the value auto(1) enables the power detection 399 mechanism of the port. 400 Setting the value off(2) disables the power detection 401 mechanism of the port. 402 Setting the value test(3) puts the port in a 403 test mode forcing continuous discovery without applying 404 power regardless of whether PD detected." 405 ::= { pethPsePortEntry 6 } 407 pethPsePortDetectionOperStatus OBJECT-TYPE 408 SYNTAX INTEGER { 409 deliveringPower(1), 410 off(2), 411 searching(3), 412 fault(4) 413 } 414 MAX-ACCESS read-only 415 STATUS current 416 DESCRIPTION 417 "Describes the operational status of the port detection. 418 A value of deliveringPower(1) indicates that the port 419 executed the detection algorithm, found a PD connection 420 and is currently delivering power. 421 A value of off(2) indicates that the port did not find 422 a PD connection and is not in serching mode. 423 A value of searching(3) indicates that the detection 424 algorithm is in work, and did not detect a valid PD. No 425 power is currently provided. 426 A value of fault(4) indicates that a fault was detected 427 on the port . " 428 ::= { pethPsePortEntry 7 } 429 pethPsePortPowerPriority OBJECT-TYPE 430 SYNTAX INTEGER { 431 critical(1), 432 high(2), 433 low(3) 434 } 435 MAX-ACCESS read-write 436 STATUS current 437 DESCRIPTION 438 "This object controls the priority of the port from the point 439 of view of a power management algorithm. The priority that 440 is set by this variable could be used by a control mechanism 441 that prevents over current situations by disconnecting first 442 ports with lower power priority. Ports that connect devices 443 critical to the operation of the network - like the E911 444 telephones ports - should be set to higher priority." 445 ::= { pethPsePortEntry 8 } 447 pethPsePortDenyError OBJECT-TYPE 448 SYNTAX INTEGER { 449 other(1), 450 lowPriority(2) 451 } 452 MAX-ACCESS read-only 453 STATUS current 454 DESCRIPTION 455 "This object describes an error resulted from an action of the 456 power management mechanism. The value lowPriority(2) indicates 457 that the port was disabled by the power management system, in 458 order to keep active higher priority ports." 459 ::= { pethPsePortEntry 9 } 461 pethPsePortStatus OBJECT-TYPE 462 SYNTAX INTEGER { 463 ok(1), 464 underCurrent(2), 465 overCurrent(3), 466 both(4) 467 } 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "Describes a current port status related to the power generation 472 The value underCurrent(2) indicates that the port current 473 is below the minimal value. 474 The value overCurrent(3) indicates that the port current 475 exceeds the maximal value. 476 The value both(4) indicates that both underCurrent and overCurrent 477 status happend from the lase Clear." 478 ::= { pethPsePortEntry 10 } 480 pethPsePortStatusClear OBJECT-TYPE 481 SYNTAX INTEGER { 482 clear(1), 483 off(2) 484 } 485 MAX-ACCESS read-write 486 STATUS current 487 DESCRIPTION 488 "Setting the value of this object to clear(1) clears the value 489 of the pethPsePortStatus to none(1)." 490 ::= { pethPsePortEntry 11 } 492 pethPsePortType OBJECT-TYPE 493 SYNTAX INTEGER { 494 other(1), 495 telephone(2), 496 webcam(3), 497 wireless(4) 498 } 499 MAX-ACCESS read-write 500 STATUS current 501 DESCRIPTION 502 "A manager will set the value of this variable to a value 503 that indicates the type of the device that is connected 504 to theport. This value can be the result of the mapping 505 the address of the station connected to the port and of 506 the value of the pethPdPortType of the respective PD port." 507 ::= { pethPsePortEntry 12 } 509 pethPsePortPowerClassifications OBJECT-TYPE 510 SYNTAX INTEGER { 511 class0(1), 512 class1(2), 513 class2(3), 514 class3(4), 515 class4(5), 516 class5(6) 517 } 518 MAX-ACCESS read-only 519 STATUS current 520 DESCRIPTION 521 "Classification is a way to tag different terminals on the 522 power over LAN network according to their power consumption. 523 Devices such as IP telephones, WLAN access points and others, 524 will be classified according to their power requirements. 526 Class Usage Maximum Power 527 0 Default 0.5 - 15.0 W 528 1 Optional 0.5 - 4.0 W 529 2 Optional 4.0 - 7.0 W 530 3 Optional 7.0 - 15.0 W 531 4 Optional Future Use 532 5 Optional Future Use 533 " 534 ::= { pethPsePortEntry 13 } 536 -- PD Port table 538 pethPdPortTable OBJECT-TYPE 539 SYNTAX SEQUENCE OF PethPdPortEntry 540 MAX-ACCESS not-accessible 541 STATUS current 542 DESCRIPTION 543 "A table of objects that display and control the power 544 characteristics power Ethernet ports on a Powered 545 Device(PD) device. This group will be implemented in 546 managed powered and mid-span devices." 547 ::= { pethObjects 2 } 549 pethPdPortEntry OBJECT-TYPE 550 SYNTAX PethPdPortEntry 551 MAX-ACCESS not-accessible 552 STATUS current 553 DESCRIPTION 554 "A set of objects that display and control the power 555 characteristics of a Powered Device port." 556 INDEX { pethPdPortIndex } 557 ::= { pethPdPortTable 1 } 559 PethPdPortEntry ::= SEQUENCE { 560 pethPdPortIndex 561 INTEGER, 562 pethPdPortPowerPairs 563 INTEGER, 564 pethPdPortDetectionOperStatus 565 INTEGER, 566 pethPdPortType 567 INTEGER 568 } 570 pethPdPortIndex OBJECT-TYPE 571 SYNTAX INTEGER (0..65535) 572 MAX-ACCESS not-accessible 573 STATUS current 574 DESCRIPTION 575 "An index value that uniquely identifies an 576 interface to a PD device. The 577 interface identified by a particular value of 578 this index is the same interface as identified 579 by the same value of ifIndex. The mapping 580 between the ifIndex values and the numbering of 581 the port on the device is an implementation 582 issue." 583 ::= { pethPdPortEntry 1 } 585 pethPdPortPowerPairs OBJECT-TYPE 586 SYNTAX INTEGER { 587 signal(1), 588 spare(2), 589 both(3) 590 } 591 MAX-ACCESS read-only 592 STATUS current 593 DESCRIPTION 594 "Describes the pairs in use. 595 A value of signal(1) menas that the signal pairs 596 only are in use. 597 A value of spare(2) means that the spare pairs 598 only are in use. 599 A value of both(3) means that both the signal 600 and the spare pairs are inuse." 601 ::= { pethPdPortEntry 2 } 603 pethPdPortDetectionOperStatus OBJECT-TYPE 604 SYNTAX INTEGER { 605 off(1), 606 receivingPower(2) 607 } 608 MAX-ACCESS read-only 609 STATUS current 610 DESCRIPTION 611 "Describes the operational status of the port detection. 612 The value off(1) means that the port does not receive 613 power and the detection algorithm might still be operating. 614 The value receivingPower(2) means that the port is 615 receiving power. " 616 ::= { pethPdPortEntry 3 } 618 pethPdPortType OBJECT-TYPE 619 SYNTAX INTEGER { 620 other(1), 621 telephone(2), 622 webcam(3), 623 wireless(4) 624 } 625 MAX-ACCESS read-only 626 STATUS current 627 DESCRIPTION 628 "The type of the device. A management application may read 629 the value of this variable and use it for setting the 630 corresponding value of pethPsePortType of the port that 631 connects the device." 632 ::= { pethPdPortEntry 4 } 634 -- Main PSE Objects 636 pethMainPseObjects OBJECT IDENTIFIER ::= { pethObjects 3 } 638 pethMainPseTable OBJECT-TYPE 639 SYNTAX SEQUENCE OF PethMainPseEntry 640 MAX-ACCESS not-accessible 641 STATUS current 642 DESCRIPTION 643 "A table of objects that display and control the Main power 644 on a PSE device." 645 ::= { pethMainPseObjects 1 } 647 pethMainPseEntry OBJECT-TYPE 648 SYNTAX PethMainPseEntry 649 MAX-ACCESS not-accessible 650 STATUS current 651 DESCRIPTION 652 "A set of objects that display and control the Main power 653 of a PSE." 654 INDEX { pethMainPseGroupIndex } 655 ::= { pethMainPseTable 1 } 657 PethMainPseEntry ::= SEQUENCE { 658 pethMainPseGroupIndex 659 INTEGER, 660 pethMainPsePower 661 Integer32, 662 pethMainPseOperStatus 663 INTEGER, 664 pethMainPseConsumptionPower 665 Gauge32, 666 pethMainPseBackupPresent 667 INTEGER, 668 pethMainPseBackupActivated 669 INTEGER, 671 pethMainPseUsageThreshold 672 INTEGER 673 } 674 pethMainPseGroupIndex OBJECT-TYPE 675 SYNTAX INTEGER (0..65535) 676 MAX-ACCESS not-accessible 677 STATUS current 678 DESCRIPTION 679 "This variable uniquely identifies the group to which 680 power Ethernet PSE is connected. Group means box in the stack, 681 module in a rack. It is recommended that the value 1 be 682 used for non-modular devices " 683 ::= { pethMainPseEntry 1 } 685 pethMainPsePower OBJECT-TYPE 686 SYNTAX Integer32 (0..65535) 687 MAX-ACCESS read-write 688 STATUS current 689 DESCRIPTION 690 "The nominal power of the PSE expressed in Watts." 691 ::= { pethMainPseEntry 2 } 693 pethMainPseOperStatus OBJECT-TYPE 694 SYNTAX INTEGER { 695 on(1), 696 off(2), 697 faulty(3) 698 } 699 MAX-ACCESS read-only 700 STATUS current 701 DESCRIPTION 702 "The operational status of the main PSE." 703 ::= { pethMainPseEntry 3 } 705 pethMainPseConsumptionPower OBJECT-TYPE 706 SYNTAX Gauge32 707 MAX-ACCESS read-only 708 STATUS current 709 DESCRIPTION 710 "Measured usage power expressed in Watts." 711 ::= { pethMainPseEntry 4 } 713 pethMainPseBackupPresent OBJECT-TYPE 714 SYNTAX INTEGER { 715 present(1), 716 notPresent(2), 717 faulty(3) 718 } 719 MAX-ACCESS read-only 720 STATUS current 721 DESCRIPTION 722 "This value reflects the presence and status 723 of a backup PSE ." 724 ::= { pethMainPseEntry 5 } 726 pethMainPseBackupActivated OBJECT-TYPE 727 SYNTAX INTEGER { 728 activated(1), 729 notActivated(2) 730 } 731 MAX-ACCESS read-only 732 STATUS current 733 DESCRIPTION 734 "This variable reflects the activation status 735 of the backup PSE" 736 ::= { pethMainPseEntry 6 } 738 pethMainPseUsageThreshold OBJECT-TYPE 739 SYNTAX INTEGER (1..99) 740 MAX-ACCESS read-write 741 STATUS current 742 DESCRIPTION 743 "The usage threshold expressed in percents for 744 comparing the measured power and initiating 745 an alarm if the threshold is exceeded." 746 ::= { pethMainPseEntry 7 } 748 -- Traps Control Objects 750 pethTrapsControl OBJECT IDENTIFIER ::= { pethObjects 4 } 752 pethTrapsControlTable OBJECT-TYPE 753 SYNTAX SEQUENCE OF PethTrapsControlEntry 754 MAX-ACCESS not-accessible 755 STATUS current 756 DESCRIPTION 757 "A table of objects that display and control the Main power 758 on a PSE device." 759 ::= { pethTrapsControl 1 } 761 pethTrapsControlEntry OBJECT-TYPE 762 SYNTAX PethTrapsControlEntry 763 MAX-ACCESS not-accessible 764 STATUS current 765 DESCRIPTION 766 "A set of objects that control the Trap events." 767 INDEX { pethTrapsControlGroupIndex } 768 ::= { pethTrapsControlTable 1 } 770 PethTrapsControlEntry ::= SEQUENCE { 771 pethTrapsControlGroupIndex 772 INTEGER, 773 pethTrapsControlEnable 774 INTEGER 775 } 776 pethTrapsControlGroupIndex OBJECT-TYPE 777 SYNTAX INTEGER (0..65535) 778 MAX-ACCESS not-accessible 779 STATUS current 780 DESCRIPTION 781 "This variable uniquely identifies the group. Group means 782 box in the stack, or module in a rack. It is recommended 783 that the value 1 is used for non-modular devices." 784 ::= { pethTrapsControlEntry 1 } 786 pethTrapsControlEnable OBJECT-TYPE 787 SYNTAX INTEGER 788 { 789 enable(1), 790 disable(2) 791 } 792 MAX-ACCESS read-write 793 STATUS current 794 DESCRIPTION 795 "Enable Traps from Agent" 796 ::= { pethTrapsControlEntry 2 } 798 -- 799 -- Notifications Section 800 -- 801 -- 803 pethPsePortOnOffTrap NOTIFICATION-TYPE 804 OBJECTS { pethPsePortGroupIndex,pethPsePortIndex,pethPsePortDetectionOperStatus } 805 STATUS current 806 DESCRIPTION " This trap indicate if Pse Port is delivering or not power to the PD." 807 ::= { pethNotifications 1 } 809 pethPsePortDenyTrap NOTIFICATION-TYPE 810 OBJECTS { pethPsePortGroupIndex,pethPsePortIndex,pethPsePortDenyError } 811 STATUS current 812 DESCRIPTION 813 " This trap indicate Port Deny service." 814 ::= { pethNotifications 2 } 816 pethPsePortStatusTrap NOTIFICATION-TYPE 817 OBJECTS { pethPsePortGroupIndex,pethPsePortIndex,pethPsePortStatus } 818 STATUS current 819 DESCRIPTION 820 " This trap indicate Port Change Status." 821 ::= { pethNotifications 3 } 823 pethMainPseBackUpActivatedTrap NOTIFICATION-TYPE 824 OBJECTS { pethPsePortGroupIndex,pethMainPseBackupActivated } 825 STATUS current 826 DESCRIPTION 827 " This trap indicates that BackUp PSE is Activated ." 828 ::= { pethNotifications 4 } 830 pethMainPowerUsageTrap NOTIFICATION-TYPE 831 OBJECTS { pethPsePortGroupIndex } 832 STATUS current 833 DESCRIPTION 834 " This trap indicate PSE Threshold usage indication ." 835 ::= { pethNotifications 5 } 837 -- 838 -- Conformance Section 839 -- 840 pethCompliances OBJECT IDENTIFIER ::= { pethConformance 1 } 841 pethGroups OBJECT IDENTIFIER ::= { pethConformance 2 } 843 pethCompliance MODULE-COMPLIANCE 844 STATUS current 845 DESCRIPTION 846 "Describes the requirements for conformance to the 847 Power Ethernet MIB." 848 MODULE -- this module 849 GROUP pethPsePortGroup 850 DESCRIPTION 851 "The pethPsePortGroup is mandatory for systems which 852 implement PSE ports." 853 GROUP pethPdPortGroup 854 DESCRIPTION 855 "The pethPdPortGroup is mandatory for systems which 856 implement PD Ports." 857 GROUP pethMainPseGroup 858 DESCRIPTION 859 "The pethMainPseGroup is mandatory for systems which 860 implement main power supply within a PSE Device." 861 GROUP pethTrapsControlGroup 862 DESCRIPTION 863 "The pethTrapsControlGroup is mandatory for systems which 864 implement PSE ports." 865 ::= { pethCompliances 1 } 867 pethPsePortGroup OBJECT-GROUP 868 OBJECTS { 869 pethPsePortPowerEnable, 870 pethPsePortPowerIdPairsControl, 871 pethPsePortPowerIdPairs, 872 pethPsePortPowerDetectionStatus, 873 pethPsePortDetectionOperStatus, 874 pethPsePortPowerPriority, 875 pethPsePortDenyError, 876 pethPsePortStatus, 877 pethPsePortStatusClear, 878 pethPsePortType, 879 pethPsePortPowerClassifications 880 } 881 STATUS current 882 DESCRIPTION 883 "PSE Port Objects." 884 ::= { pethGroups 1 } 886 pethPdPortGroup OBJECT-GROUP 887 OBJECTS { 888 pethPdPortPowerPairs, 889 pethPdPortDetectionOperStatus, 890 pethPdPortType 891 } 892 STATUS current 893 DESCRIPTION 894 "PD Port Objects." 895 ::= { pethGroups 2 } 897 pethMainPseGroup OBJECT-GROUP 898 OBJECTS { 899 pethMainPsePower, 900 pethMainPseOperStatus, 901 pethMainPseConsumptionPower, 902 pethMainPseBackupPresent, 903 pethMainPseBackupActivated, 904 pethMainPseUsageThreshold 905 } 906 STATUS current 907 DESCRIPTION 908 "Main PSE Objects. " 909 ::= { pethGroups 3 } 911 pethTrapsControlGroup OBJECT-GROUP 912 OBJECTS { 913 pethTrapsControlEnable 914 } 915 STATUS current 916 DESCRIPTION 917 "Trap Control Objects. " 918 ::= { pethGroups 4 } 919 END 921 8. References 923 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 924 for Describing SNMP Management Frameworks", RFC 2571, April 925 1999. 927 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 928 of Management Information for TCP/IP-based Internets", STD 929 16, RFC 1155, May 1990. 931 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 932 16, RFC 1212, March 1991. 934 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 935 SNMP", RFC 1215, March 1991. 937 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 938 Rose, M., and S. Waldbusser, "Structure of Management 939 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 940 1999. 942 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 943 Rose, M., and S. Waldbusser, "Textual Conventions for 944 SMIv2", STD 58, RFC 2579, April 1999. 946 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 947 Rose, M., and S. Waldbusser, "Conformance Statements for 948 SMIv2", STD 58, RFC 2580, April 1999. 950 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 951 Network Management Protocol", STD 15, RFC 1157, May 1990. 953 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 954 "Introduction to Community-based SNMPv2", RFC 1901, January 955 1996. 957 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 958 "Transport Mappings for Version 2 of the Simple Network 959 Management Protocol (SNMPv2)", RFC 1906, January 1996. 961 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 962 Processing and Dispatching for the Simple Network Management 963 Protocol (SNMP)", RFC 2572, April 1999. 965 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 966 (USM) for version 3 of the Simple Network Management 967 Protocol (SNMPv3)", RFC 2574, April 1999. 969 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 970 "Protocol Operations for Version 2 of the Simple Network 971 Management Protocol (SNMPv2)", RFC 1905, January 1996. 973 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 974 RFC 2573, April 1999. 976 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 977 Access Control Model (VACM) for the Simple Network 978 Management Protocol (SNMP)", RFC 2575, April 1999. 980 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 981 "Introduction to Version 3 of the Internet-standard Network 982 Management Framework", RFC 2570, April 1999. 984 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 985 Requirement Levels", BCP 14, RFC 2119, March 1997. 987 [RFC2665] Flick, J., and J. Johnson, "Definitions of Managed Objects 988 for the Ethernet-like Interface Types", RFC 2665, August 1999. 990 [IEEE-802.3af] IEEE 802.3af Working Group, "Data Terminal Equipment (DTE) 991 Power via Media Dependent Interface (MDI)", Draft D1.1, 992 January 2001. 994 [PWR-MIB] Romascanu, D., " Power Ethernet (DTE Power via MDI) MIB", 995 Internet-Draft, draft-romascanu-hubmib-power-ethernet-mib-00.txt, 996 February 2001. 998 9.Intellectual Property 1000 The IETF takes no position regarding the validity or scope of any 1001 intellectual property or other rights that might be claimed to 1002 pertain to the implementation or use of the technology described in 1003 this document or the extent to which any license under such rights 1004 might or might not be available; neither does it represent that it 1005 has made any effort to identify any such rights. Information on the 1006 IETF's procedures with respect to rights in standards-track and 1007 standards-related documentation can be found in BCP-11. Copies of 1008 claims of rights made available for publication and any assurances of 1009 licenses to be made available, or the result of an attempt made to 1010 obtain a general license or permission for the use of such 1011 proprietary rights by implementors or users of this specification can 1012 be obtained from the IETF Secretariat. 1014 The IETF invites any interested party to bring to its attention any 1015 copyrights, patents or patent applications, or other proprietary 1016 rights which may cover technology that may be required to practice 1017 this standard. Please address the information to the IETF Executive 1018 Director. 1020 10. Security Considerations 1022 There are a number of management objects defined in this MIB 1023 that have a MAX-ACCESS clause of read-write and/or read-create. 1024 Such objects may be considered sensitive or vulnerable in some 1025 network environments. The support for SET operations in a 1026 non-secure environment without proper protection can have a 1027 negative effect on network operations. 1029 There are a number of managed objects in this MIB that may 1030 contain sensitive information. These are: 1032 It is thus important to control even GET access to these objects 1033 and possibly to even encrypt the values of these object when 1034 sending them over the network via SNMP. Not all versions of 1035 SNMP provide features for such a secure environment. 1037 SNMPv1 by itself is not a secure environment. Even if the 1038 network itself is secure (for example by using IPSec), even then, 1039 there is no control as to who on the secure network is allowed 1040 to access and GET/SET (read/change/create/delete) the objects in 1041 this MIB. 1043 It is RECOMMENDED that the implementers consider the security 1044 features as provided by the SNMPv3 framework. Specifically, the 1045 use of the User-based Security Model [RFC2274] and the 1046 View-based Access Control Model [RFC2275] is RECOMMENDED. 1048 It is then a customer/user responsibility to ensure that the SNMP 1049 entity giving access to an instance of this MIB, is properly 1050 configured to give access to the objects only to those 1051 principals (users) that have legitimate rights to indeed GET or 1052 SET (change/create/delete) them. 1054 11. Authors Addresses 1056 Avi Berger 1057 PowerDsine Inc. 1058 1, Hanagar St., P.O. Box 7220 1059 Hod Hasharon 45421, 1060 Israel 1061 Tel: 972-9-7755100 Ext 307 1062 Fax: 972-9-7755120 1063 E-mail: avib@PowerDsine.com 1065 Dan Romascanu 1066 Avaya Inc. 1067 Atidim Technology Park, Bldg. #3 1068 Tel Aviv, 61131 1069 Israel 1070 Tel: +972-3-645-8414 1071 Email: dromasca@avaya.com 1073 A. Full Copyright Statement 1075 This document and translations of it may be copied and furnished to 1076 others, and derivative works that comment on or otherwise explain it 1077 or assist in its implementation may be prepared, copied, published 1078 and distributed, in whole or in part, without restriction of any 1079 kind, provided that the above copyright notice and this paragraph are 1080 included on all such copies and derivative works. However, this 1081 document itself may not be modified in any way, such as by removing 1082 the copyright notice or references to the Internet Society or other 1083 Internet organizations, except as needed for the purpose of 1084 developing Internet standards in which case the procedures for 1085 copyrights defined in the Internet Standards process must be 1086 followed, or as required to translate it into languages other than 1087 English. 1089 The limited permissions granted above are perpetual and will not be 1090 revoked by the Internet Society or its successors or assigns. 1092 This document and the information contained herein is provided on an 1093 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1094 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1095 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1096 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1097 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.