Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8348

A YANG Data Model for Hardware Management

Pages: 60
Proposed Standard
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC8348 - Page 1
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 Management

Abstract

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.
Top   ToC   RFC8348 - Page 2

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
Top   ToC   RFC8348 - Page 3

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 configuration

1.2. Tree Diagrams

Tree diagrams used in this document follow the notation defined in [RFC8340].
Top   ToC   RFC8348 - Page 4

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
Top   ToC   RFC8348 - Page 5
           +--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.
Top   ToC   RFC8348 - Page 6

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.
Top   ToC   RFC8348 - Page 7
   +--------------------------------+----------------------------------+
   | 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
Top   ToC   RFC8348 - Page 8

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 Objects

6. 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)

Next Section