Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 8348

Proposed STD
Pages: 60
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NETMOD

A YANG Data Model for Hardware Management

Part 1 of 3, p. 1 to 8
None       Next Section

 


Top       ToC       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       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       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       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       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       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       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       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 Section