CoAp Management Interfaces
draft-vanderstok-core-comi-04

Abstract

The draft describes an interface based on CoAP to manage constrained devices via MIBs. The proposed integration of CoAP with SNMP reduces the code- and application development complexity by accessing MIBs via a standard CoAP server. The payload of the MIB request is CBOR based on JSON. The mapping from SMI to CBOR is specified. The introduction motivates the choices of CoMI with respect to utilization of YANG, NETCONF, SMI, CBOR, CoAP, and URI structure.

Note

Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 09, 2014.

Copyright Notice

Copyright (c) 2014 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 (http://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
• 1.1. Design considerations
• 1.2. Terminology
• 2. CoAP Interface
• 3. MIB Function Set
• 3.1. SNMP/MIB architecture
• 3.1.1. SNMP functions
• 3.1.2. MIB structure
• 3.2. CoMI Function Set
• 3.2.1. Single MIB values
• 3.2.2. multi MIB values
• 3.2.3. Table row
• 3.2.4. MIB discovery
• 3.2.5. Error returns
• 4. Mapping SMI to CoMI payload
• 4.1. CBOR format for MIB data
• 4.2. Table generation
• 4.3. Mapping SMI to CBOR
• 4.3.1. General overview
• 4.3.2. Conversion from YANG datatypes to CBOR datatypes
• 4.3.3. Examples
• 4.3.4. 6LoWPAN MIB
• 5. Trap functions
• 6. MIB access management
• 6.1. Notify destinations
• 6.2. Conversion table management
• 7. Error handling
• 8. Security Considerations
• 9. IANA Considerations
• 10. Acknowledgements
• 11. Changelog
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Appendix A. Notational Convention for CBOR data
• Appendix B. Example conversion table and instance for the LOWPAN MIB
• B.1. Generating the convTableId
• B.2. Generating the string numbers
• B.3. Example instance
• Authors' Addresses

1. Introduction

The Constrained RESTful Environments (CoRE) working group aims at Machine to Machine (M2M) applications such as smart energy and building control.

Small M2M devices need to be managed in an automatic fashion to handle the large quantities of devices that are expected to be installed in future installations. The management protocol of choice for Internet is SNMP [RFC3410] as is testified by the large number of Management Information Base (MIB) [RFC3418] specifications currently published [STD0001]. More recently, the NETCONF protocol [RFC6241] was developed with an extended set of messages using XML [XML] as data format. The data syntax is specified with YANG [RFC6020] and a mapping from Yang to XML is specified. In [RFC6643] SMIv2 syntax is expressed in Yang. Contrary to SNMP and also CoAP, NETCONF assumes persistent connections for example provided by SSH. The NETCONF protocol provides operations to retrieve, configure, copy, and delete configuration data-stores. Configuring data-stores distinguishes NETCONF from SNMP which operates on standardized MIBs.

The CoRE Management Interface (CoMI) is intended to work on standardized data-sets in a stateless client-server fashion and is thus closer to SNMP than to NETCONF. Standardized data sets promote interoperability between small devices and applications from different manufacturers. Stateless communication is encouraged to keep communications simple and the amount of state information small in line with the design objectives of 6lowpan [RFC4944] [RFC6775], RPL [RFC6650], and CoAP [I-D.ietf-core-coap].

The draft [I-D.bierman-netconf-restconf] describes a restful interface to NETCONF data stores and approaches the CoMI approach. CoMI uses SMI encoded in CBOR, and CoAP/UDP to access MIBs, whereas RESTCONF uses YANG encoded in JSON and HTTP/TCP to access NETCONF data stores. CoMI is more low resource oriented than RESTCONF is, and only supports the methods GET, PUT, POST and DELETE. RESTCONF also uses uses the HTTP methods HEAD, OPTIONS and PATCH, which are not available in CoAP.

Given the automatic conversion from SMI to YANG, from YANG to JSON, from YANG to XML and from JSON to CBOR, the transported data format is not strongly related to the chosen management protocol.

Currently, managed devices need to support two protocols: CoAP and SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP protocol can be replaced with the CoAP protocol. This arrangement reduces the code complexity of the stack in the constrained device, and harmonizes applications development.

The objective of CoMI is to provide a CoAP based Function Set that reads and sets values of MIB variables in devices to (1) initialize parameter values at start-up, (2) acquire statistics during operation, and (3) maintain nodes by adjusting parameter values during operation.

The payload of CoMI is encoded in CBOR [RFC7049] which is similar to JSON [JSON], but has a binary format and hence has more coding efficiency. CoMI is intended for small devices. The JSON overhead can be prohibitive. It is therefore chosen to transport CBOR in the payload. CBOR, like BER used for SNMP, transports the data type in the payload.

The end goal of CoMI is to provide information exchange over the CoAP transport protocol in a uniform manner as a first step to the full management functionality as specified in [I-D.ersue-constrained-mgmt].

1.1. Design considerations

COMI supports discovery of resources, accompanied by reading, writing and notification of resource values. As such it is close to the device management of the Open Mobile Alliance described in [OMA]. However, the structure of the MIB does not reflect the structure of the OMA management objects. It is assumed that the structure and semantics of the management data are the most important aspect of a standard like the MIB. The right path forward to integrate OMA management with COMI is the adapatation of the MIB structure by OMA.

COMI supports the conversion of SMIv2 via YANG to CBOR. Assuming that CBOR is used for the tanport of NETCONF data, the utilization of the CBOR conversion table to reduce payload size can be envisaged for NETCONF data as well.

COMI uses a simple URI to access the MIB resources. Complexity introduced by module name, context specification, or row selection, is expressed with uri-query attributes. The choice for uri-query attributes makes the uri structure less context dependent.

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Readers of this specification are required to be familiar with all the terms and concepts discussed in [RFC3410], [RFC3416], and [RFC2578].

Core Management Interface (CoMI) specifies the profile of Function Sets which access MIBs with the purpose of managing the operation of constrained devices in a network.

The following list defines the terms used in this document:

Managing Entity:

An entity that manages one or more managed devices. Within the CoMI framework, the managing entity acts as a CoAP client for CoMI.

Managed Device:

An entity that is being managed. The managed device acts as a CoAP server for CoMI.

NOTE: It is assumed that the managed device is the most constrained entity. The managing entity might be more capable, however this is not necessarily the case.

The following list contains the abbreviations used in this document.

OID:

ASN.1 OBJECT-IDENTIFIER, which is used to uniquely identify MIB objects in the managed device.

2. CoAP Interface

In CoRE a group of links can constitute a Function Set. The format of the links is specified in [I-D.ietf-core-interfaces]. This note specifies a Management Function Set. CoMI end-points that implement the CoMI management protocol support at least one discoverable management resource of resource type (rt): core.mg, with path: /mg, where mg is short-hand for management. The mg resource has two sub-resources accessible with the paths: Section 3.2. The conv resource provides access to a table that maps a string to CBOR identifier, as described in Section 4.1. The mib and conv resources are introduced as sub resources to mg to permit later additions to CoMI mg resource.

• MIB with path /mg/mib and a CBOR content format.
• conv with path /mg/conv and CBOR content format.

The mib resource provides access to the MIBs as described in

The profile of the management function set, with IF=core.mg.mib, is shown in the table below, following the guidelines of [I-D.ietf-core-interfaces]:

3. MIB Function Set

The MIB Function Set provides a CoAP interface to perform equivalent functions to the ones provided by SNMP. Section 3.1 explains the structure of SNMP Protocol Data Units (PDU), their transport, and the structure of the MIB modules. An excellent overview of the documents describing the SNMP/MIB architecture is provided in section 7 of [RFC3410].

3.1. SNMP/MIB architecture

The architecture of the Internet Standard management framework consists of: [RFC4088] describes a URI scheme to refer to a specific MIB instance.

• A data definition language that is referred to as Structure of Management Information (SMI)[RFC2578].
• The Management Information Base (MIB) which contains the information to be managed and is defined for each specific function to be managed [RFC3418].
• A protocol definition referred to as Simple Network Management Protocol (SNMP) [RFC3416].
• Security and administration that provides SNMP message based security on the basis of the user-based security model [RFC3414].
• A management domain definition where a SNMP entity has access to a collection of management information called a "context" [RFC3411].

In addition

Separation in modules was motivated by the wish to respond to the evolution of Internet. The protocol part (SNMP) and data definition part (MIB) are independent of each other. The separation has enabled the progressive passage from SNMPv1 via SNMPv2 to SNMPv3. This draft leverages this separation to replace the SNMP protocol with a CoAP based protocol.

3.1.1. SNMP functions

The SNMP protocol supports seven types of access supported by as many Protocol Data Unit (PDU) types:

• Get Request, transmits a list of OBJECT-IDENTIFIERs to be paired with values.
• GetNext Request, transmits a list of OBJECT-IDENTIFIERs to which lexicographic successors are returned for table traversal.
• GetBulk Request, transmits a list of OBJECT-IDENTIFIERs and the maximum number of expected paired values.
• Response, returns an error or the (OBJECT-IDENTIFIER, value) pairs for the OBJECT-IDENTIFIERs specified in Get, GetNext, GetBulk, Set, or Inform Requests.
• Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs to be set in the specified MIB object.
• Trap, sends an unconfirmed message with a list of (OBJECT-IDENTIFIERs, value) pairs to a notification requesting end-point.
• Inform Request, sends a confirmed message with a list of (OBJECT-IDENTIFIERs, value) pairs to a notification requesting end-point.

3.1.2. MIB structure

A MIB module is composed of MIB objects. MIB objects are standardized by the IETF or by other relevant Standards Developing Organizations (SDO).

MIB objects have a descriptor and an identifier: OBJECT-IDENTIFIER (OID). The identifier, following the OSI hierarchy, is an ordered list of non-negative numbers [RFC2578]. OID values are unique. Each number in the list is referred as a sub-identifier. The descriptor is unique within a module. Different modules may contain the same descriptor. Consequently, a descriptor can be related to several OIDs.

Many instances of an object type exist within a management domain. Each instance can be identified within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical or logical device. A context is always defined as a subset of a single SNMP entity. To identify an individual item of management information within the management domain, its contextName and contextEngineID must be identified in addition to its object type and its instance. A default context is assumed when no context is specified.

A MIB object is usually a scalar object. A MIB object may have a tabular form with rows and columns. Such an object is composed of a sequence of rows, with each row composed of a sequence of typed values. The index is a subset (1-2 items) of the typed values in the row. An index value identifies the row in the table.

In SMI, a table is constructed as a SEQUENCE OF its entries. For example, the IpAddrTable from [RFC4293] has the following definition:

ipv6InterfaceTable OBJECT-TYPE
  SYNTAX                      SEQUENCE OF Ipv6InterfaceEntry
  MAX-ACCESS                  not-accessible
  STATUS                      current
  DESCRIPTION
    "The table containing per-interface IPv6-specific
    information."
::= { ip 30 }

ipv6InterfaceEntry OBJECT-TYPE
  SYNTAX                      Ipv6InterfaceEntry
  MAX-ACCESS                  not-accessible
  STATUS current
  DESCRIPTION
    "An entry containing IPv6-specific information for a given
    interface."
  INDEX { ipv6InterfaceIfIndex }
::= { ipv6InterfaceTable 1 }

Ipv6InterfaceEntry ::= SEQUENCE {
  ipv6InterfaceIfIndex        InterfaceIndex,
  ipv6InterfaceReasmMaxSize   Unsigned32,
  ipv6InterfaceIdentifier     Ipv6AddressIfIdentifierTC,
  ipv6InterfaceEnableStatus   INTEGER,
  ipv6InterfaceReachableTime  Unsigned32,
  ipv6InterfaceRetransmitTime Unsigned32,
  ipv6InterfaceForwarding     INTEGER
}

The descriptor (name) of the MIB table is used for the name of the CoMI variable. However, there is no explicit mention of the names "ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of the main CoMI variable, ipv6InterfaceTable, consists of an array, each element of which contains 7 CoMI variables: one element for "ipv6InterfaceIfIndex", one for "ipv6InterfaceReasmMaxSize" and so on until "ipv6InterfaceForwarding".

3.2. CoMI Function Set

Three types of interfaces are supported by CoMI: Section 4.

Single value:

Reading/Writing one MIB variable, specified in the URI with path /mg/mib/descriptor or with path /mg/mib/OID.

Multiple values:

Reading writing arrays or multiple MIB variables, specified in the payload.

Discovery:

Discovery of MIB descriptors as specified in [RFC6690].

The examples in this section use a JSON payload with one or more entries describing the pair (descriptor, value), or (OID, value). CoMI transports the CBOR format to transport the equivalent contents. The CBOR syntax of the payloads is specified in

3.2.1. Single MIB values

A request to read the value of a MIB variable is sent with a confirmable CoAP GET message. The single MIB variable is specified in the URI path with the OID or descriptor suffixing the /mg/mib/ path name. When the descriptor is used to specify the MIB value, the same descriptor may be present in multiple module. To disambiguate the descriptor the "mod" uri-query attribute specifies the enveloping modules. A request to set the value of a MIB variable is sent with a confirmable CoAP PUT message. The Response is piggybacked to the CoAP ACK message corresponding with the Request.

TODO: for multicast send unconfirmed PUT

Using for example the same MIB from [RFC1213] as used in [RFC3416], a request is sent to retrieve the value of sysUpTime specified in module SNMPv2-MIB. The answer to the request returns a (descriptor, value) pair.

As announced, in all examples the payload is expressed in JSON, although the operational payload is specified to be in CBOR.

REQ: GET example.com/mg/mib/sysUpTime?mod=SNMPv2-MIB

RES: 2.05 Content (Content-Format: application/json)
{
    "sysUpTime" : 123456
}

Another way to express the descriptor of the required value is by specifying the pair (descriptor or oid, null value) in the payload of the request message.

REQ: GET example.com/mg/mib/(Content-Format: application/json)
{
    "SNMPv2-MIB.sysUpTime" : "null"
}

RES: 2.05 Content (Content-Format: application/json)
{
    "SNMPv2-MIB.sysUpTime" : 123456
}

The module name SNMPv2-MIB can be omitted when there is no possibility of ambiguity. The module.descriptor can of course be replaced with the corresponding oid.

In some cases it is necessary to determine the "context" by specifying a context name and a contextEngine identifier. The context can be specified in the URI with the uri-query attribute "con". Based on the example of figure 3 in section 3.3 of [RFC3411], the context name, bridge1, and the context Engine Identifier, 800002b804616263, separated by an underscore, are specified in the following example:

REQ: GET example.com/mg/mib/sysUPTime?con=bridge1_800002b804616263

RES: 2.05 Content (Content-Format: application/json)
{
    "sysUpTime" : 123456
}

The specified object can be a table. The returned payload is composed of all the rows associated with the table. Each row is returned as a set of (column name, value) pairs. For example the GET of the ipNetToMediaTable, sent by the managing entity, results in the following returned payload sent by the managed entity:

REQ: GET example.com/mg/mib/ipNetToMediaTable

RES: 2.05 Content (Content-Format: application/json)
{
   "ipNetTOMediaTable" : [
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
	"ipNetToMediaNetAddress" : "10.0.0.51",
	"ipNetToMediaType" : "static"
	},
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:54:32:10",
	"ipNetToMediaNetAddress" : "9.2.3.4",
	"ipNetToMediaType" : "dynamic"
      },
      {
	"ipNetToMediaIfIndex" : 2,
	"ipNetToMediaPhysAddress" : "00:00::10:98:76:54",
	"ipNetToMediaNetAddress" : "10.0.0.15",
	"ipNetToMediaType" : "dynamic"
      }
    ]
}

It is possible that the size of the returned payload is too large to fit in a single message.

CoMI gives the possibility to send the contents of the objects in several fragments with a maximum size. The "sz" link-format attribute [RFC6690] can be used to specify the expected maximum size of the mib resource in (identifier, value) pairs. The returned data MUST terminate with a complete (identifier, value) pair.

In the case that management data is bigger than the maximum supported payload size, the Block mechanism from [I-D.ietf-core-block] is used. Notice that the Block mechanism splits the data at fixed positions, such that individual data fields may become fragmented. Therefore, assembly of multiple blocks may be required to process the complete data field.

3.2.2. multi MIB values

A request to read multiple MIB variables is done by expressing the pairs (MIB descriptor, null) in the payload of the GET request message. A request to set multiple MIB variables is done by expressing the pairs (MIB descriptor, value) in the payload of the PUT request message. The key word _multiMIB is used as array name to signal that the payload contains multiple MIB values as separate _multiMIB array entries.

The following example shows a request that specifies to return the values of sysUpTime and ipNetToMediaTable:

REQ: GET example.com/mg/mib (Content-Format: application/json)
{
   "_multiMIB" : [
     { "sysUpTime" : "null"},
     { "ipNetToMediaTable" : "null" }
    ]
}

RES: 2.05 Content (Content-Format: application/json)
{
   "_multiMIB" : [
   { "sysUpTime" : 123456},
   { "ipNetTOMediaTable" : [
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
	"ipNetToMediaNetAddress" : "10.0.0.51",
	"ipNetToMediaType" : "static"
	},
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:54:32:10",
	"ipNetToMediaNetAddress" : "9.2.3.4",
	"ipNetToMediaType" : "dynamic"
      },
      {
	"ipNetToMediaIfIndex" : 2,
	"ipNetToMediaPhysAddress" : "00:00::10:98:76:54",
	"ipNetToMediaNetAddress" : "10.0.0.15",
	"ipNetToMediaType" : "dynamic"
      }
    ]
    }
   ]
}

3.2.3. Table row

The managing entity MAY be interested only in certain table entries. One way to specify a row is to specify its row number in the URI with the "row" uri-query attribute. The specification of row=1 returns row 1 values of the ipNetToMediaTable in the example:

REQ: GET example.com/mg/mib/ipNetToMediaTable?row=1

RES: 2.05 Content (Content-Format: application/json)
{ "ipNetTOMediaTable" : [
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
	"ipNetToMediaNetAddress" : "10.0.0.51",
	"ipNetToMediaType" : "static"
	}
    ]
}

An alternative mode of selection is by specifying the value of the INDEX attributes. Towards this end, the managing entity can include the required entries in the payload of its "GET" request by specifying the values of the index attributes. The key word _indexMIB is used to specify the index value.

For example, to obtain a table entry from ipNetToMediaTable, the rows are specified by specifying the index attributes: ipNetToMediaIfIndex and ipNetToMediaNetAddress. The managing entity could have sent a GET with the following payload:

REQ: GET example.com/mg/mib/ipNetToMediaTable(Content-Format: application/json)

{ "_indexMIB" :
     {
      "ipNetToMediaIfIndex" : 1,
      "ipNetToMediaNetAddress" : "9.2.3.4"
     }
}

RES: 2.05 Content (Content-Format: application/json)
{ "ipNetTOMediaTable" : [
     {
	"ipNetToMediaIfIndex" : 1,
	"ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
	"ipNetToMediaNetAddress" : "9.2.3.4",
	"ipNetToMediaType" : "static"
	}
    ]
}

Constrained devices MAY support this kind of filtering. However, if they don't support it, they MUST ignore the payload in the GET request and handle the message as if the payload was empty.

It is advised to keep MIBs for constrained entities as simple as possible, and therefore it would be best to avoid extensive tables.

TODO: Describe how the contents of the next lexicographical row can be returned.

3.2.4. MIB discovery

MIB objects are discovered like resources with the standard CoAP resource discovery. Performing a GET on "/.well-known/core" with rt=core.mg.mib returns all MIB descriptors and all OIDs which are available on this device. For table objects there is no further possibility to discover the row descriptors. For example, consider there are two MIB objects with descriptors "sysUpTime" and "ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and 1.3.6.1.2.1.4.22

REQ: GET example.com/.well-known/core?rt=core.mg.mib

RES: 2.05 Content (Content-Format: application/text)
</mg/mib/sysUpTime>;rt="core.mg.mib";oid="1.3.6.1.2.1.1.3";
  mod="SNMPv2-MIB"
</mg/mib/ipNetToMediaTable>;rt="core.mg.mib";oid="1.3.6.1.2.1.4.22";
  mod="ipMIB"

The link format attribute 'oid' is used to associate the name of the MIB resource with its OID. The OID is written as a string in its conventional form.

Notice that a MIB variable normally is associated with a descriptor and an OID. The OID is unique, whereas the descriptor is unique in combination with the module name.

The "mod", "con", and "rt" attributes can be used to filter resource queries as specified in [RFC6690].

3.2.5. Error returns

When a variable with the specified name cannot be processed, CoAP Error code 5.01 is returned. In addition, a MIB specific error can be returned in the payload as specified in Section 7.

4. Mapping SMI to CoMI payload

The SMI syntax is mapped to CBOR necessary for the transport of MIB data in the CoAP payload. This section first describes an additional data reduction technique by creating a table that maps string values to numbers used in CBOR encoded data.

The section continues by describing the mapping from SMI to CBOR. The mapping is inspired by the mapping from SMI to JSON via YANG [RFC6020], as described in [RFC6643] defining a mapping from SMI to YANG, and [I-D.lhotka-netmod-yang-json] defining a mapping from YANG to JSON.

Notice that such conversion chain MAY be virtual only, as SMI could be converted directly to JSON by combining the rules from the above documents.

4.1. CBOR format for MIB data

Because descriptors may be rather long and may occur repeatedly, CoMI allows for association of a given string value with an integer, henceforth called "string number". The association between string value and string number is done through a conversion table, leveraging CBOR encoding. Section 4.2 defines how the conversion table is generated.

Using the notational convention from Appendix A, the CBOR data has the following syntax:

cBorMIB       : CBorMIB;

*CBorMIB {
  convTableId : tstr;
  mibData     : map( uint, . );
}

The main structure consist of an array of two elements: "convTableId" and "mibData".

The conversion table identifier "convTableId" is constructed from the LAST_UPDATED attribute and module name as defined in Section 4.2.

The values of the MIB variables are stored in the "mibData" field. This field consist of integer-value pairs. The integers correspond to the string numbers, whereas the values contain the actual value of the associated MIB variable. Section 4.3 elaborates on the mapping from SMI to CBOR.

4.2. Table generation

The conversion table contents MUST be automatically generated from the MIB module as specified in this section. Automatic generation in the managed device removes the need to transport the tables and subsequently store them in the nodes, and avoids a cumbersome management of the conversion tables.

The conversion table identifier "convTableId" is generated from the LAST-UPDATED field in the MODULE IDENTITY macro, and the module name as follows:

convTableId = moduleName UNDERSCORE lastUpdateTimestamp
UNDERSCORE  = %x5F

where moduleName is the module name, and lastUpdateTimestamp is the value of the related LAST-UPDATED field in the MODULE-IDENTITY macro, using the format with four year digits as defined in [RFC2578].

The conversion table is generated using the following algorithm:

1. Collect all used OIDs/descriptors defined in the MIB object, and as well as those imported using IMPORTS.
2. Sort the collection of OIDs according to the following rules:
   1. x.y.z < x.y.z.k
   2. x.y.z... < x.y.k... if z<k

3. Assign the string numbers to the sorted list of OIDs, in numerical order starting with 1.

Note that variables imported with IMPORTS could be tables, such that the OIDs of the table entries need to be included in the collection of OIDs as well.

4.3. Mapping SMI to CBOR

4.3.1. General overview

Starting from the intermediate conversion from SMI to YANG as defined in [RFC6643], This section defines how to convert the resulting YANG structure to CBOR [RFC7049]. The actual conversion code from SMI to CBOR MAY be direct conversion code from SMI to CBOR or a sequence of existing SMI to YANG conversion code followed by YANG to CBOR conversion code.

4.3.2. Conversion from YANG datatypes to CBOR datatypes

Table 1 defines the mapping between YANG datatypes and CBOR datatypes.

Elements of types not in this table, and of which the type cannot be inferred from a type in this table, are ignored in the CBOR encoding by default. Examples include the "description" and "key" elements. However, conversion rules for some elements to CBOR MAY be defined elsewhere.

container ipNetToMediaTable {
    list ipNetToMediaEntry {
       leaf ipNetToMediaIfIndex {
          type: int32;
       }
       leaf ipNetToPhysAddress {
          type: phys-address;
       }
       leaf ipNetToMediaNetAddress {
          type: ipv4-address;
       }
       leaf ipNetToMediaType {
          type: int32;
       }
    }
 }

{ 
"ipNetToMediaTable" : {
	"ipNetToMediaEntry" : [
		{
		"ipNetToMediaIfIndex" : 1.
		"ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
		"ipNetToMediaNetAddress" : "10.0.0.51",
		"ipNetToMediaType" : "static"
		},
		{
		"ipNetToMediaIfIndex " : 1,
		"ipNetToMediaPhysAddress " : "00:00::10:54:32:10",
		"ipNetToMediaNetAddress" : "9.2.3.4",
		"ipNetToMediaType " : "dynamic"
		}
	]
	}
}

82                         # two element array
   74 49 50 2d 4d 49 42 5f 
   32 30 30 36 30 32 30 32
   30 30 30 30 5a          # "IP-MIB_200602020000Z"
   BF                      # indefinite length map
     00                    # descriptor number related to 
                           # ipNetToMediaTable
     BF                    # indefinite length map related to
                           # ipNetToMediaTable
        01                 # descriptor number related to
                           # ipNetToMediaEntry
        BF                 # map related to ipNetToMediaEntry
           02              # descriptor number associated with
                           # ipNetToMediaIfIndex
           1A 00 00 00 01  # associated value as 32-bit integer
           # ...
        FF
     FF
   FF

82                         # two element array
   74 49 50 2d 4d 49 42 5f 
   32 30 30 36 30 32 30 32
   30 30 30 30 5a          # "IP-MIB_200602020000Z"
   BF                      # indefinite length map
      00                   # descriptor number related to 
                           # ipNetToMediaTable
      72 69 70 50 65 74 57
      6F 51 65 64 61 57 61
      62 6C 65             # "ipNetToMediaTable"
      01                   # descriptor number related to
                           # ipNetToMediaEntry
      72 69 70 50 65 74 57
      6F 51 65 64 61 45 6E
      74 72 78 			       # "ipNetToMediaEntry"
      02                   # descriptor number related to
                           # ipNetToMediaIfIndex
      75 69 70 50 65 74 57
      6F 51 65 64 61 61 49
      66 49 6E 64 65 77    # "ipNetToMediaIfIndex"
      # ...
   FF

82                         # two element array
   78 18 4c 4f 57 50 41 4e
   2d 4d 49 42 5f 32 30 31
   34 30 34 30 38 30 30 30
   30 5a                   # conversion table id:
                           # "LOWPAN-MIB_201404080000Z"
   BF                      # indefinite length map
     18 1B                 # "lowpanOutFragFails"
     00                    # 0
   FF

REQ: GET example.com/mg/conv/ident

RES: 2.05 Content (Content-Format: application/json)
{
    "convTableId" : convTableId
}

convTable     : ConvTable;

*ConvTable {
  convTableId : tstr;
  convData    : map( uint, tstr );
} 

errorMsg     : ErrorMsg;

*ErrorMsg {
  errorCode  : uint;
  ?errorText : tstr;
}

   name : datatype;

GET /mg/mib/lowpanIfStatsTable

82                         # two element array
   78 18 4c 4f 57 50 41 4e
   2d 4d 49 42 5f 32 30 31
   34 30 34 30 38 30 30 30
   30 5a                   # conversion table id:
                           # "LOWPAN-MIB_201404080000Z"
   BF                      # indefinite length map
     18 25                 # "lowpanIfStatsTable"
     BF                    # indefinite length map related 
                           # to lowpanIfStatsTable
        18 27              # "lowpanIfReasmTimeout"
        14                 # 20
        18 28              # "lowpanIfInReceives"
        18 2A              # 42
        18 29              # "lowpanIfInHdrErrors"
        00                 # 0
        18 2A              # "lowpanIfInMeshReceives"
        08                 # 8
        18 2B              # "lowpanIfInMeshForwds"
        00                 # 0
        18 2C              # "lowpanIfInMeshDelivers"
        00                 # 0
        18 2D              # "lowpanIfInReasmReqds"
        16                 # 22
        18 2E              # "lowpanIfInReasmFails"
        02                 # 02
        18 2F              # "lowpanIfInReasmOKs"
        14                 # 20
        18 30              # "lowpanIfInCompReqds"
        10                 # 16
        18 31              # "lowpanIfInCompFails"
        02                 # 2
        18 32              # "lowpanIfInCompOKs"
        0E                 # 14
        18 33              # "lowpanIfInDiscards"
        01                 # 01
        18 34              # "lowpanIfInDelivers"
        0C                 # 12
        18 35              # "lowpanIfOutRequests"
        0C                 # 12
        18 36              # "lowpanIfOutCompReqds"
        00                 # 0
        18 37              # "lowpanIfOutCompFails"
        00                 # 0
        18 38              # "lowpanIfOutCompOKs"
        00                 # 0
        18 39              # "lowpanIfOutFragReqds"
        05                 # 5
        18 3A              # "lowpanIfOutFragFails"
        00                 # 0
        18 3B              # "lowpanIfOutFragOKs"
        05                 # 5
        18 3C              # "lowpanIfOutFragCreates"
        08                 # 8
        18 3D              # "lowpanIfOutMeshHopLimitExceeds"
        00                 # 0
        18 3E              # "lowpanIfOutMeshNoRoutes"
        00                 # 0
        18 3F              # "lowpanIfOutMeshRequests"
        00                 # 0
        18 40              # "lowpanIfOutMeshForwds"
        00                 # 0
        18 41              # "lowpanIfOutMeshTransmits"
        00                 # 0
        18 42              # "lowpanIfOutDiscards"
        00                 # 0
        18 43              # "lowpanIfOutTransmits"
        0F                 # 15
     FF
   FF