RFC 8348
A YANG Data Model for Hardware Management
Pages: 60
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 8
Internet Engineering Task Force (IETF) A. Bierman Request for Comments: 8348 YumaWorks Category: Standards Track M. Bjorklund ISSN: 2070-1721 Tail-f Systems J. Dong Huawei Technologies D. Romascanu March 2018 A YANG Data Model for Hardware ManagementAbstract
This document defines a YANG data model for the management of hardware on a single server. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8348. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
Table of Contents
1. Introduction ....................................................3 1.1. Terminology ................................................3 1.2. Tree Diagrams ..............................................3 2. Objectives ......................................................4 3. Hardware Data Model .............................................4 3.1. The Components Lists .......................................5 4. Relationship to ENTITY-MIB ......................................6 5. Relationship to ENTITY-SENSOR-MIB ...............................8 6. Relationship to ENTITY-STATE-MIB ................................8 7. Hardware YANG Modules ...........................................9 7.1. "ietf-hardware" Module .....................................9 7.2. "iana-hardware" Module ....................................34 8. IANA Considerations ............................................38 8.1. URI Registrations .........................................38 8.2. YANG Module Registrations .................................39 9. Security Considerations ........................................39 10. References ....................................................40 10.1. Normative References .....................................40 10.2. Informative References ...................................41 Appendix A. Hardware State Data Model ............................42 A.1. Hardware State YANG Module ................................43 Acknowledgments ...................................................60 Authors' Addresses ................................................60
1. Introduction
This document defines a YANG data model [RFC7950] for the management of hardware on a single server. The data model includes configuration and system state (status information and counters for the collection of statistics). The data model in this document is designed to be compliant with the Network Management Datastore Architecture (NMDA) [RFC8342]. For implementations that do not yet support NMDA, a temporary module with system state data only is defined in Appendix A.1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined in [RFC8342] and are not redefined here: o client o server o configuration o system state o operational state o intended configuration1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in [RFC8340].
2. Objectives
This section describes some of the design objectives for the hardware data model. o The hardware data model needs to support many common properties used to identify hardware components. o Important information and states about hardware components need to be collected from devices that support the hardware data model. o The hardware data model should be suitable for new implementations to use as is. o The hardware data model defined in this document can be implemented on a system that also implements ENTITY-MIB; thus, the mapping between the hardware data model and ENTITY-MIB should be clear. o The data model should support pre-provisioning of hardware components.3. Hardware Data Model
This document defines the YANG module "ietf-hardware", which has the following structure: module: ietf-hardware +--rw hardware +--ro last-change? yang:date-and-time +--rw component* [name] +--rw name string +--rw class identityref +--ro physical-index? int32 {entity-mib}? +--ro description? string +--rw parent? -> ../../component/name +--rw parent-rel-pos? int32 +--ro contains-child* -> ../../component/name +--ro hardware-rev? string +--ro firmware-rev? string +--ro software-rev? string +--ro serial-num? string +--ro mfg-name? string +--ro model-name? string +--rw alias? string +--rw asset-id? string +--ro is-fru? boolean +--ro mfg-date? yang:date-and-time
+--rw uri* inet:uri
+--ro uuid? yang:uuid
+--rw state {hardware-state}?
| +--ro state-last-changed? yang:date-and-time
| +--rw admin-state? admin-state
| +--ro oper-state? oper-state
| +--ro usage-state? usage-state
| +--ro alarm-state? alarm-state
| +--ro standby-state? standby-state
+--ro sensor-data {hardware-sensor}?
+--ro value? sensor-value
+--ro value-type? sensor-value-type
+--ro value-scale? sensor-value-scale
+--ro value-precision? sensor-value-precision
+--ro oper-status? sensor-status
+--ro units-display? string
+--ro value-timestamp? yang:date-and-time
+--ro value-update-rate? uint32
notifications:
+---n hardware-state-change
+---n hardware-state-oper-enabled {hardware-state}?
| +--ro name? -> /hardware/component/name
| +--ro admin-state? -> /hardware/component/state/admin-state
| +--ro alarm-state? -> /hardware/component/state/alarm-state
+---n hardware-state-oper-disabled {hardware-state}?
+--ro name? -> /hardware/component/name
+--ro admin-state? -> /hardware/component/state/admin-state
+--ro alarm-state? -> /hardware/component/state/alarm-state
3.1. The Components Lists
The data model for hardware presented in this document uses a flat
list of components. Each component in the list is identified by its
name. Furthermore, each component has a mandatory "class" leaf.
The "iana-hardware" module defines YANG identities for the hardware
types in the IANA-maintained "IANA-ENTITY-MIB" registry.
The "class" leaf is a YANG identity that describes the type of the
hardware. Vendors are encouraged to either directly use one of the
common IANA-defined identities or derive a more specific identity
from one of them.
4. Relationship to ENTITY-MIB
If the device implements the ENTITY-MIB [RFC6933], each entry in the "/hardware/component" list in the operational state is mapped to one EntPhysicalEntry. Objects that are writable in the MIB are mapped to "config true" nodes in the "/hardware/component" list, except entPhysicalSerialNum, which is writable in the MIB but "config false" in the YANG module. The "physical-index" leaf MUST contain the value of the corresponding entPhysicalEntry's entPhysicalIndex. The "class" leaf is mapped to both entPhysicalClass and entPhysicalVendorType. If the value of the "class" leaf is an identity that either is derived from or is one of the identities in the "iana-hardware" module, then entPhysicalClass contains the corresponding IANAPhysicalClass enumeration value. Otherwise, entPhysicalClass contains the IANAPhysicalClass value "other(1)". Vendors are encouraged to define an identity (derived from an identity in "iana-hardware" if possible) for each enterprise-specific registration identifier used for entPhysicalVendorType and use that identity for the "class" leaf. The following table lists the YANG data nodes with corresponding objects in the ENTITY-MIB.
+--------------------------------+----------------------------------+
| YANG data node in | ENTITY-MIB object |
| /hardware/component | |
+--------------------------------+----------------------------------+
| name | entPhysicalName |
| class | entPhysicalClass |
| | entPhysicalVendorType |
| physical-index | entPhysicalIndex |
| description | entPhysicalDescr |
| parent | entPhysicalContainedIn |
| parent-rel-pos | entPhysicalParentRelPos |
| contains-child | entPhysicalChildIndex |
| hardware-rev | entPhysicalHardwareRev |
| firmware-rev | entPhysicalFirmwareRev |
| software-rev | entPhysicalSoftwareRev |
| serial-num | entPhysicalSerialNum |
| mfg-name | entPhysicalMfgName |
| model-name | entPhysicalModelName |
| alias | entPhysicalAlias |
| asset-id | entPhysicalAssetID |
| is-fru | entPhysicalIsFRU |
| mfg-date | entPhysicalMfgDate |
| uri | entPhysicalUris |
| uuid | entPhysicalUUID |
+--------------------------------+----------------------------------+
YANG Data Nodes and Related ENTITY-MIB Objects
5. Relationship to ENTITY-SENSOR-MIB
If the device implements the ENTITY-SENSOR-MIB [RFC3433], each entry in the "/hardware/component" list where the container "sensor-data" exists is mapped to one EntPhySensorEntry. The following table lists the YANG data nodes with corresponding objects in the ENTITY-SENSOR-MIB. +-------------------------------------+-----------------------------+ | YANG data node in | ENTITY-SENSOR-MIB object | | /hardware/component/sensor-data | | +-------------------------------------+-----------------------------+ | value | entPhySensorValue | | value-type | entPhySensorType | | value-scale | entPhySensorScale | | value-precision | entPhySensorPrecision | | oper-status | entPhySensorOperStatus | | units-display | entPhySensorUnitsDisplay | | value-timestamp | entPhySensorValueTimeStamp | | value-update-rate | entPhySensorValueUpdateRate | +-------------------------------------+-----------------------------+ YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects6. Relationship to ENTITY-STATE-MIB
If the device implements the ENTITY-STATE-MIB [RFC4268], each entry in the "/hardware/component" list where the container "state" exists is mapped to one EntStateEntry. The following table lists the YANG data nodes with corresponding objects in the ENTITY-STATE-MIB. +------------------------------------------+------------------------+ | YANG data node in | ENTITY-STATE-MIB | | /hardware/component/state | object | +------------------------------------------+------------------------+ | state-last-changed | entStateLastChanged | | admin-state | entStateAdmin | | oper-state | entStateOper | | usage-state | entStateUsage | | alarm-state | entStateAlarm | | standby-state | entStateStandby | +------------------------------------------+------------------------+ YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects
(next page on part 2)