< draft-vanderstok-core-comi-01.txt   draft-vanderstok-core-comi-02.txt >
core P. van der Stok core P. van der Stok
Internet-Draft consultant Internet-Draft consultant
Intended status: Informational B. Greevenbosch Intended status: Informational B. Greevenbosch
Expires: April 20, 2014 Huawei Technologies Expires: July 13, 2014 Huawei Technologies
October 17, 2013 January 9, 2014
CoAp Management Interfaces CoAp Management Interfaces
draft-vanderstok-core-comi-01 draft-vanderstok-core-comi-02
Abstract Abstract
The draft describes an interface based on CoAP to manage constrained The draft describes an interface based on CoAP to manage constrained
devices via MIBs. The proposed integration of CoAP with SNMP reduces devices via MIBs. The proposed integration of CoAP with SNMP reduces
the code- and application development complexity by accessing MIBs the code- and application development complexity by accessing MIBs
via a standard CoAP server. The payload of the MIB request is JSON, via a standard CoAP server. The payload of the MIB request is CBOR
CBOR or XML (EXI). The mapping from SMI to XML, JSON and CBOR is based on JSON. The mapping from SMI to CBOR is specified.
specified.
Note Note
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org. be sent to core@ietf.org.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 41 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2014. This Internet-Draft will expire on July 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5 2. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 5
3. MIB Function Set . . . . . . . . . . . . . . . . . . . . . . 6 3. MIB Function Set . . . . . . . . . . . . . . . . . . . . . . 5
3.1. SNMP/MIB architecture . . . . . . . . . . . . . . . . . . 6 3.1. SNMP/MIB architecture . . . . . . . . . . . . . . . . . . 5
3.1.1. SNMP functions . . . . . . . . . . . . . . . . . . . 6 3.1.1. SNMP functions . . . . . . . . . . . . . . . . . . . 6
3.1.2. MIB structure . . . . . . . . . . . . . . . . . . . . 7 3.1.2. MIB structure . . . . . . . . . . . . . . . . . . . . 7
3.2. CoMI Function Set . . . . . . . . . . . . . . . . . . . . 8 3.2. CoMI Function Set . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single MIB values . . . . . . . . . . . . . . . . . . 8 3.2.1. Single MIB values . . . . . . . . . . . . . . . . . . 9
3.2.2. multi MIB values . . . . . . . . . . . . . . . . . . 10 3.2.2. multi MIB values . . . . . . . . . . . . . . . . . . 11
3.2.3. Table row . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Table row . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Error returns . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Error returns . . . . . . . . . . . . . . . . . . . . 14
4. Mapping SMI to CoMI payload . . . . . . . . . . . . . . . . . 11 4. Mapping SMI to CoMI payload . . . . . . . . . . . . . . . . . 14
4.1. Mapping SMI to JSON . . . . . . . . . . . . . . . . . . . 11 4.1. Mapping strings to CBOR . . . . . . . . . . . . . . . . . 15
4.1.1. Tables in JSON . . . . . . . . . . . . . . . . . . . 13 4.2. Mapping SMI to CBOR . . . . . . . . . . . . . . . . . . . 16
4.2. Mapping SMI to CBOR . . . . . . . . . . . . . . . . . . . 14 4.2.1. General overview . . . . . . . . . . . . . . . . . . 16
4.2.1. Tables in CBOR . . . . . . . . . . . . . . . . . . . 15 4.2.2. Conversion from YANG datatypes to CBOR datatypes . . 16
4.3. Mapping SMI to XML . . . . . . . . . . . . . . . . . . . 19 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Tables in XML . . . . . . . . . . . . . . . . . . . . 20 4.2.4. 6LoWPAN MIB . . . . . . . . . . . . . . . . . . . . . 20
5. MIB discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 5. MIB discovery . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Trap functions . . . . . . . . . . . . . . . . . . . . . . . 22 6. Trap functions . . . . . . . . . . . . . . . . . . . . . . . 24
7. MIB access management . . . . . . . . . . . . . . . . . . . . 22 7. MIB access management . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.1. Notify destinations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.2. Conversion tables . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Error handling . . . . . . . . . . . . . . . . . . . . . . . 25
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. XML Schema for MIB . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. XML Schema for CoMI support . . . . . . . . . . . . 29 13.1. Normative References . . . . . . . . . . . . . . . . . . 27
B.1. Schema for CoAP binding . . . . . . . . . . . . . . . . . 29 13.2. Informative References . . . . . . . . . . . . . . . . . 28
B.2. Valid Schemas . . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Notational Convention for CBOR data . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Constrained RESTful Environments (CoRE) working group aims at The Constrained RESTful Environments (CoRE) working group aims at
Machine to Machine (M2M) applications such as smart energy and Machine to Machine (M2M) applications such as smart energy and
building control. building control.
Small M2M devices need to be managed in an automatic fashion to Small M2M devices need to be managed in an automatic fashion to
handle the large quantities of devices that are expected to be handle the large quantities of devices that are expected to be
installed in future installations. The management protocol of choice installed in future installations. The management protocol of choice
for Internet is SNMP [RFC3410] as is testified by the large number of for Internet is SNMP [RFC3410] as is testified by the large number of
Management Information Base (MIB) [RFC3418] specifications currently Management Information Base (MIB) [RFC3418] specifications currently
published [STD0001]. More recently, the NETCONF protocol [RFC6241] published [STD0001]. More recently, the NETCONF protocol [RFC6241]
skipping to change at page 3, line 25 skipping to change at page 3, line 28
data format. The data syntax is specified with YANG [RFC6020] and a data format. The data syntax is specified with YANG [RFC6020] and a
mapping from Yang to XML is specified. In [RFC6643] SMIv2 syntax is mapping from Yang to XML is specified. In [RFC6643] SMIv2 syntax is
expressed in Yang. Contrary to SNMP and also CoAP, NETCONF assumes expressed in Yang. Contrary to SNMP and also CoAP, NETCONF assumes
persistent connections for example provided by SSH. The NETCONF persistent connections for example provided by SSH. The NETCONF
protocol provides operations to retrieve, configure, copy, and delete protocol provides operations to retrieve, configure, copy, and delete
configuration data-stores. Configuring data-stores distinguishes configuration data-stores. Configuring data-stores distinguishes
NETCONF from SNMP which operates on standardized MIBs. NETCONF from SNMP which operates on standardized MIBs.
The CoRE Management Interface (CoMI) is intended to work on The CoRE Management Interface (CoMI) is intended to work on
standardized data-sets in a stateless client-server fashion and is standardized data-sets in a stateless client-server fashion and is
thus closer to SNMP than to NETCONF. Standardized data sets are thus closer to SNMP than to NETCONF. Standardized data sets promote
necessary when small devices from different manufacturers are managed interoperability between small devices and applications from
by applications originating from another set of manufacturers. different manufacturers. Stateless communication is encouraged to
Stateless communication is encouraged to keep communications simple keep communications simple and the amount of state information small
and the amount of state information small in line with the design in line with the design objectives of 6lowpan [RFC4944] [RFC6775],
objectives of 6lowpan [RFC4944] [RFC6775], RPL [RFC6650], and CoAP RPL [RFC6650], and CoAP [I-D.ietf-core-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, where
restconf uses YANG encoded in JSON and HTTP/TCP to access NETCONF
data stores. CoMI is more low resource oriented than restconf is.
Currently, managed devices need to support two protocols: CoAP and Currently, managed devices need to support two protocols: CoAP and
SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP SNMP. When the MIB can be accessed with the CoAP protocol, the SNMP
protocol can be replaced with the CoAP protocol. This arrangement protocol can be replaced with the CoAP protocol. This arrangement
reduces the code complexity of the stack in the constrained device, reduces the code complexity of the stack in the constrained device,
and harmonizes applications development. and harmonizes applications development.
The objective of CoMI is to provide a CoAP based Function Set that 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 reads and sets values of MIB variables in devices to (1) initialize
parameter values at start-up, (2) acquire statistics during parameter values at start-up, (2) acquire statistics during
operation, and (3) maintain nodes by adjusting parameter values operation, and (3) maintain nodes by adjusting parameter values
during operation. during operation.
The payload of CoMI is encoded in JSON [JSON], CBOR The payload of CoMI is encoded in CBOR [RFC7049] which similar to
[I-D.bormann-cbor] or XML [XML]. CoMI is intended for small devices. JSON [JSON], but has a binary format and hence has more coding
The XML or JSON overhead can be prohibitive. It is therefore efficiency. CoMI is intended for small devices. The JSON overhead
recommended to transport CBOR or EXI [EXI] in the payload. CBOR, can be prohibitive. It is therefore chosen to transport CBOR in the
like BER used for SNMP, transports the data type in the payload. EXI payload. CBOR, like BER used for SNMP, transports the data type in
uses a schema file that provides information about transported data the payload.
types.
In [EXI-measurement] it is shown that EXI can be an order of
magnitude smaller than the equivalent XML representation. Actually,
the EXI structure adds the overhead per data unit of an EXI event
(indicates the type of the following XML element) with a size that
depends on the number of EXI event types present in the schema and
its frequency of occurrence. In [JSON-XML] it is shown that memory
and CPU usage for sending JSON encoded or XML encoded objects led on
average to a 50% lower resource usage for JSON. Consequently, from a
resource utilization point of view EXI and CBOR seem the right
choice. CBOR does not need a schema, but EXI requires one for
decoding. Consequently, for EXI different schema versions must be
handled by a versioning scheme.
The end goal of CoMI is to provide information exchange over the CoAP The end goal of CoMI is to provide information exchange over the CoAP
transport protocol in a uniform manner to approach the full transport protocol in a uniform manner to approach the full
management functionality as specified in management functionality as specified in
[I-D.ersue-constrained-mgmt]. [I-D.ersue-constrained-mgmt].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" in this
skipping to change at page 5, line 6 skipping to change at page 4, line 47
Managed Device: An entity that is being managed. The managed device Managed Device: An entity that is being managed. The managed device
acts as a CoAP server for CoMI. acts as a CoAP server for CoMI.
NOTE: It is assumed that the managed device is the most constrained NOTE: It is assumed that the managed device is the most constrained
entity. The managing entity might be more capable, however this is entity. The managing entity might be more capable, however this is
not necessarily the case. not necessarily the case.
The following list contains the abbreviations used in this document. The following list contains the abbreviations used in this document.
OID: ASN.1 OBJECT-IDENTIFIER, which is used to uniquely identify MIB OID: ASN.1 OBJECT-IDENTIFIER, which is used to uniquely identify MIB
objects in the managed device objects in the managed device.
2. CoAP Interface 2. CoAP Interface
In CoRE a group of links can constitute a Function Set. The format of 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 the links is specified in [I-D.ietf-core-interfaces]. This note
specifies a Management Function Set. CoMI end-points that implement specifies a Management Function Set. CoMI end-points that implement
the CoMI management protocol support at least one discoverable the CoMI management protocol support at least one discoverable
management resource of resource type (rt): core.mg, with path: /mg, management resource of resource type (rt): core.mg, with path: /mg,
where mg is short-hand for management. The mg resource has one sub- where mg is short-hand for management. The mg resource has two sub-
resource accessible with the path: resources accessible with the paths:
o MIB with path /mg/mib and an XML (EXI), JSON or CBOR content o MIB with path /mg/mib and a CBOR content format.
format.
The mib resource provides access to the MIBs described in o XLAT with path /mg/xlat and CBOR content format.
Section 3.2. The mib resource is introduced as a sub resource to mg
to permit later additions to CoMI mg resource.
XML and JSON schemas describe the structure of the MIBs. It is The mib resource provides access to the MIBs as described in
expected that given the verbosity of XML and JSON, CoMI messages will Section 3.2. The xlat resource provides access to a string to CBOR
mostly use EXI or CBOR. The profile of the management function set, identifier table as described in Section 4.1. The mib and xlat
with IF=core.mg.mib, is shown in the table below, following the resources are introduced as sub resources to mg to permit later
guidelines of [I-D.ietf-core-interfaces]: additions to CoMI mg resource.
+-----------------+----------+--------------+-------------------+ The profile of the management function set, with IF=core.mg.mib, is
| name | path | RT | Data Type | shown in the table below, following the guidelines of
+-----------------+----------+--------------+-------------------+ [I-D.ietf-core-interfaces]:
| Management | /mg | core.mg | n/a |
| | | | |
| MIB | /mg/mib | core.mg.mib | application/json |
| | | | |
| MIB | /mg/mib | core.mg.mib | application/cbor |
| | | | |
| MIB | /mg/mib | core.mg.mib | application/xml |
| | | | |
| MIB | /mg/mib | core.mg.mib | application/exi |
+-----------------+----------+--------------+-------------------+
The value of the EXI events have a different meaning dependent on the +-----------------+-----------+---------------+-------------------+
accompanying schema file. Schemas are sent to the device at | name | path | RT | Data Type |
initialization such that it can prepare the parsing tables in +-----------------+-----------+---------------+-------------------+
advance. Schema management is discussed in Section 7. No such | Management | /mg | core.mg | n/a |
schema is needed for CBOR. | | | | |
| MIB | /mg/mib | core.mg.mib | application/cbor |
| | | | |
| XLAT | /mg/xlat | core.mg.xlat | application/cbor |
+-----------------+-----------+---------------+-------------------+
3. MIB Function Set 3. MIB Function Set
The MIB Function Set provides a CoAP interface to perform equivalent The MIB Function Set provides a CoAP interface to perform equivalent
functions to the ones provided by SNMP. Section 3.1 explains the functions to the ones provided by SNMP. Section 3.1 explains the
structure of SNMP PDUs and their transport. 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 3.1. SNMP/MIB architecture
The architecture of the Internet Standard management framework The architecture of the Internet Standard management framework
consists of: consists of:
o A data definition language that is referred to as Structure of o A data definition language that is referred to as Structure of
Management Information (SMI)[RFC2578]. Management Information (SMI)[RFC2578].
o The Management Information Base (MIB) which contains the o The Management Information Base (MIB) which contains the
information to be managed and is defined for each specific information to be managed and is defined for each specific
function to be managed [RFC3418]. function to be managed [RFC3418].
o A protocol definition referred to as Simple Network Management o A protocol definition referred to as Simple Network Management
Protocol (SNMP) [RFC3416]. Protocol (SNMP) [RFC3416].
o Security and administration that provides SNMP message based o Security and administration that provides SNMP message based
security on the basis of the user-based security model [RFC3414]. security on the basis of the user-based security model [RFC3414].
o A management domain definition where a SNMP entity has access to a
collection of management information called a "context" [RFC3411].
In addition [RFC4088] describes a URI scheme to refer to a specific
MIB instance.
Separation in modules was motivated by the wish to respond to the Separation in modules was motivated by the wish to respond to the
evolution of Internet. The protocol part (SNMP) and data definition evolution of Internet. The protocol part (SNMP) and data definition
part (MIB) are independent of each other. The separation has enabled part (MIB) are independent of each other. The separation has enabled
the progressive passage from SNMPv1 via SNMPv2 to SNMPv3. This draft the progressive passage from SNMPv1 via SNMPv2 to SNMPv3. This draft
leverages this separation to replace the SNMP protocol with a CoAP leverages this separation to replace the SNMP protocol with a CoAP
based protocol. based protocol.
3.1.1. SNMP functions 3.1.1. SNMP functions
The SNMP protocol supports seven types of access supported by as many The SNMP protocol supports seven types of access supported by as many
skipping to change at page 7, line 19 skipping to change at page 7, line 16
IDENTIFIERs, value) pairs to a notification requesting end-point. IDENTIFIERs, value) pairs to a notification requesting end-point.
o Inform Request, sends a confirmed message with a list of (OBJECT- o Inform Request, sends a confirmed message with a list of (OBJECT-
IDENTIFIERs, value) pairs to a notification requesting end-point. IDENTIFIERs, value) pairs to a notification requesting end-point.
The binding of the notification to a destination is discussed in The binding of the notification to a destination is discussed in
Section 6. Section 6.
3.1.2. MIB structure 3.1.2. MIB structure
A MIB module is composed of MIB objects. MIB objects have a A MIB module is composed of MIB objects. MIB objects are
descriptor and an identifier: OBJECT-IDENTIFIER (OID). The standardized by the IETF or by other relevant Standards Developing
identifier, following the OSI hierarchy, is an ordered list of non- Organizations (SDO).
negative numbers [RFC2578]. OID values are unique. Each number in
the list is referred as a sub-identifier. One descriptor can be MIB objects have a descriptor and an identifier: OBJECT-IDENTIFIER
related to several OIDs. (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 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 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 sequence of rows, with each row composed of a sequence of typed
values. An index value identifies the row in the table. 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 In SMI, a table is constructed as a SEQUENCE OF its entries. For
example, the IpAddrTable from [RFC4293] has the following definition: example, the IpAddrTable from [RFC4293] has the following definition:
ipv6InterfaceTable OBJECT-TYPE ipv6InterfaceTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ipv6InterfaceEntry SYNTAX SEQUENCE OF Ipv6InterfaceEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The table containing per-interface IPv6-specific "The table containing per-interface IPv6-specific
skipping to change at page 8, line 4 skipping to change at page 8, line 23
ipv6InterfaceEntry OBJECT-TYPE ipv6InterfaceEntry OBJECT-TYPE
SYNTAX Ipv6InterfaceEntry SYNTAX Ipv6InterfaceEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An entry containing IPv6-specific information for a given "An entry containing IPv6-specific information for a given
interface." interface."
INDEX { ipv6InterfaceIfIndex } INDEX { ipv6InterfaceIfIndex }
::= { ipv6InterfaceTable 1 } ::= { ipv6InterfaceTable 1 }
Ipv6InterfaceEntry ::= SEQUENCE { Ipv6InterfaceEntry ::= SEQUENCE {
ipv6InterfaceIfIndex InterfaceIndex, ipv6InterfaceIfIndex InterfaceIndex,
ipv6InterfaceReasmMaxSize Unsigned32, ipv6InterfaceReasmMaxSize Unsigned32,
ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC, ipv6InterfaceIdentifier Ipv6AddressIfIdentifierTC,
ipv6InterfaceEnableStatus INTEGER, ipv6InterfaceEnableStatus INTEGER,
ipv6InterfaceReachableTime Unsigned32, ipv6InterfaceReachableTime Unsigned32,
ipv6InterfaceRetransmitTime Unsigned32, ipv6InterfaceRetransmitTime Unsigned32,
ipv6InterfaceForwarding INTEGER ipv6InterfaceForwarding INTEGER
} }
The name of the MIB table is used for the name of the CoMI variable. The descriptor (name) of the MIB table is used for the name of the
However, there is no explicit mention of the names CoMI variable. However, there is no explicit mention of the names
"ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of "ipv6InterfaceEntry" and "Ipv6InterfaceEntry". Instead, the value of
the main CoMI variable consists of an array, each element of which the main CoMI variable consists of an array, each element of which
contains 7 CoMI variables: one element for "ipv6InterfaceIfIndex", contains 7 CoMI variables: one element for "ipv6InterfaceIfIndex",
one for "ipv6InterfaceReasmMaxSize" and so on until one for "ipv6InterfaceReasmMaxSize" and so on until
"ipv6InterfaceForwarding". "ipv6InterfaceForwarding".
3.2. CoMI Function Set 3.2. CoMI Function Set
Two types of interfaces are supported by CoMI: Two types of interfaces are supported by CoMI:
single value Reading/Writing one MIB variable, specified in the URI single value Reading/Writing one MIB variable, specified in the URI
with path /mg/mib/descriptor or with path /mg/mib/OID. with path /mg/mib/descriptor or with path /mg/mib/OID.
multiple values Reading writing arrays or multiple MIB variables, multiple values Reading writing arrays or multiple MIB variables,
specified in the payload. specified in the payload.
A MIB object has a descriptor and an OID that identifies it uniquely The examples in this section use a JSON payload with one or more
within the device. MIB objects are standardized by the IETF or by entries describing the pair (descriptor, value), or (OID, value).
other relevant Standards Developing Organizations (SDO). The CBOR syntax of the payloads is specified in Section 4.
The examples in this section use a payload with one or more entries
describing the pair (descriptor, value), or (OID, value). The syntax
of the payloads is specified in Section 4.
3.2.1. Single MIB values 3.2.1. Single MIB values
A request to read the value of a MIB variable is sent with a A request to read the value of a MIB variable is sent with a
confirmable CoAP GET message. The single MIB variable is specified confirmable CoAP GET message. The single MIB variable is specified
in the URI path with the OID or descriptor suffixing the /mg/mib/ in the URI path with the OID or descriptor suffixing the /mg/mib/
path name. A request to set a value is sent with a confirmable CoAP path name. When the descriptor is used to specify the MIB value, the
PUT message. The Response is piggybacked to the CoAP ACK message same descriptor may be present in multiple module. To disambiguate
corresponding with the Request. 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 Using for example the same MIB from [RFC1213] as used in [RFC3416], a
request is sent to retrieve the value of sysUpTime. The answer to request is sent to retrieve the value of sysUpTime specified in
the request returns a (descriptor, value) pair. The syntax of the module SNMPv2-MIB. The answer to the request returns a (descriptor,
payload is specified in Section 4. value) pair.
REQ: GET example.com/mg/mib/sysUpTime For clarity of the examples, in this and all following examples the
payload is expressed in JSON, although the operational payload is
specified to be in CBOR, as described in Section 4.
RES: 2.05 Content (Content-Format: application/xxxx) REQ: GET example.com/mg/mib/sysUpTime?mod=SNMPv2-MIB
(sysUpTime, "123456")
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 The specified object can be a table. The returned payload is
composed of all the rows associated with the table. Each row 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 a returned as a set of (column name, value) pairs. For example the GET
GET of the ipNetToMediaTable, sent by the managing entity, results in of the ipNetToMediaTable, sent by the managing entity, results in the
the following returned payload sent by the managed entity: following returned payload sent by the managed entity:
REQ: GET example.com/mg/mib/ipNetToMediaTable REQ: GET example.com/mg/mib/ipNetToMediaTable
RES: 2.05 Content (Content-Format: application/xxxx) RES: 2.05 Content (Content-Format: application/json)
((ipNetToMediaIfIndex , 1) {
(ipNetToMediaPhysAddress , "00:00::10:01:23:45") "ipNetTOMediaTable" : [
(ipNetToMediaNetAddress, "10.0.0.51") {
(ipNetToMediaType , "static") "ipNetToMediaIfIndex" : 1,
)( "ipNetToMediaPhysAddress" : "00:00::10:01:23:45",
(ipNetToMediaIfIndex , 1) "ipNetToMediaNetAddress" : "10.0.0.51",
(ipNetToMediaPhysAddress , "00:00::10:54:32:10") "ipNetToMediaType" : "static"
(ipNetToMediaNetAddress, "9.2.3.4") },
(ipNetToMediaType , "dynamic") {
)( "ipNetToMediaIfIndex" : 1,
(ipNetToMediaIfIndex , 2) "ipNetToMediaPhysAddress" : "00:00::10:54:32:10",
(ipNetToMediaPhysAddress , "00:00::10:98:76:54") "ipNetToMediaNetAddress" : "9.2.3.4",
(ipNetToMediaNetAddress, "10.0.0.15") "ipNetToMediaType" : "dynamic"
(ipNetToMediaType , "dynamic")) },
{
The used syntax is for demonstration purposes only. Rows are "ipNetToMediaIfIndex" : 2,
encapsulated witin brackets, similar to the individual row elements. "ipNetToMediaPhysAddress" : "00:00::10:98:76:54",
The syntax of the payload is specified in Section 4. "ipNetToMediaNetAddress" : "10.0.0.15",
"ipNetToMediaType" : "dynamic"
}
]
}
It is possible that the size of the returned payload is too large to 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 fit in a single message.
contents of the objects in several fragments with a maximum size.
The "sz" link-format attribute [RFC6690] can be used to specify the CoMI gives the possibility to send the contents of the objects in
expected maximum size of the mib resource in (identifier, value) several fragments with a maximum size. The "sz" link-format
pairs. The returned data MUST terminate with a complete (identifier, attribute [RFC6690] can be used to specify the expected maximum size
value) pair. The sequel can be asked by sending the same request but of the mib resource in (identifier, value) pairs. The returned data
with a uri-query indicating the offset of the first of the next MUST terminate with a complete (identifier, value) pair.
requested pairs. This offset is equal to the already received number
of pairs. The uri-query has the form "of=" (without the quotes) In the case that management data is bigger than the maximum supported
followed by the offset as an integer in text format. 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 3.2.2. multi MIB values
A request to read multiple MIB variables is done by expressing the A request to read multiple MIB variables is done by expressing the
pairs (MIB descriptor, null) in the payload of the GET request pairs (MIB descriptor, null) in the payload of the GET request
message. A request to set multiple MIB variables is done by message. A request to set multiple MIB variables is done by
expressing the pairs (MIB descriptor, null value) in the payload of expressing the pairs (MIB descriptor, null value) in the payload of
the PUT request message. 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 3.2.3. Table row
The managing entity MAY be interested only in certain table entries. 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 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 the "row" uri-query attribute. The specification of row=1 returns
row 1 values of the ipNetToMediaTable in the example: row 1 values of the ipNetToMediaTable in the example:
REQ: GET example.com/mg/mib/ipNetToMediaTable?row=1 REQ: GET example.com/mg/mib/ipNetToMediaTable?row=1
RES: 2.05 Content (Content-Format: application/xxxx) RES: 2.05 Content (Content-Format: application/json)
(ipNetToMediaIfIndex , 1) { "ipNetTOMediaTable" : [
(ipNetToMediaPhysAddress , "00:00::10:01:23:45") {
(ipNetToMediaNetAddress, "10.0.0.51") "ipNetToMediaIfIndex" : 1,
(ipNetToMediaType , "static") "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 An alternative mode of selection is by specifying the value of the
INDEX atttributes. Towards this end, the managing entity can include INDEX attributes. Towards this end, the managing entity can include
the required entries in the payload of its "GET" request by the required entries in the payload of its "GET" request by
specifying the values of the index attributes. 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 For example, to obtain a table entry from ipNetToMediaTable, the rows
are specified by specifying the index attributes: ipNetToMediaIfIndex are specified by specifying the index attributes: ipNetToMediaIfIndex
and ipNetToMediaNetAddress. The managing entity could have sent a and ipNetToMediaNetAddress. The managing entity could have sent a
GET with the following payload: GET with the following payload:
REQ: GET example.com/mg/mib/ipNetToMediaTable REQ: GET example.com/mg/mib/ipNetToMediaTable(Content-Format: application/json)
(ipNetToMediaIfIndex , 1)
(ipNetToMediaNetAddress, "9.2.3.4")
RES: 2.05 Content (Content-Format: application/xxxx) { "_indexMIB" :
(ipNetToMediaIfIndex , 1) {
(ipNetToMediaPhysAddress , "00:00::10:54:32:10") "ipNetToMediaIfIndex" : 1,
(ipNetToMediaNetAddress, "9.2.3.4") "ipNetToMediaNetAddress" : "9.2.3.4"
(ipNetToMediaType , "dynamic") }
}
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 Constrained devices MAY support this kind of filtering. However, if
they don't support it, they MUST ignore the payload in the GET they don't support it, they MUST ignore the payload in the GET
request and handle the message as if the payload was empty. request and handle the message as if the payload was empty.
It is advised to keep MIBs for constrained entities as simple as It is advised to keep MIBs for constrained entities as simple as
possible, and therefore it would be best to avoid extensive tables. 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. Error returns 3.2.4. Error returns
When a variable with the specified name cannot be processed, CoAP When a variable with the specified name cannot be processed, CoAP
Error code 5.01 is returned. In addition, a MIB specific error can Error code 5.01 is returned. In addition, a MIB specific error can
be returned in the payload. Two types of error code can be returned: be returned in the payload as specified in Section 8.
exception or error-status as specified in Appendix A, according to
the rules of [RFC3416]. For example when MIB "variable" does not
exist:
REQ: GET example.com/mg/mib/variable
RES: 5.01 Not Implemented (Content-Format: application/xxx)
(exception, nosuchobject)
4. Mapping SMI to CoMI payload 4. Mapping SMI to CoMI payload
The SMI syntax is mapped to XML, CBOR, and JSON syntax, necessary for The SMI syntax is mapped to CBOR necessary for the transport of MIB
the transport of MIB data in the CoAP payload. 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.
4.1. Mapping SMI to JSON 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.
MIB information can be stored in JSON through a JSON object Notice that such conversion chain MAY be virtual only, as SMI could
containing a set of Name-Value pairs, where each pair has the be converted directly to JSON by combining the rules from the above
following syntax: documents.
Name : Value 4.1. Mapping strings to CBOR
"Name" is a string that either contains the variable descriptor from Because descriptors may be rather long and may occur repeatedly, CoMI
the SMI definition, or the OID of the associated variable. In the allows for association of a string with an integer, henceforth called
latter case, the "Name" string has the following ABNF syntax, where "string number". The association between string and string number is
we borrow some ABNF definitions from [I-D.ietf-json-rfc4627bis]: done through a translation table, leveraging CBOR encoding.
descriptor = quotation-mark oid-prefix int *(underscore int) Using the notational convention from Appendix A, the CBOR data has
quotation-mark the following syntax:
oid-prefix = %x6f %x69 %x64 underscore ; 'oid_' cBorMIB : CBorMIB;
underscore = %x5f ; '_' *CBorMIB {
xlatTableID : uint;
mibString : map( uint, . );
}
In other words, when "Name" contains an OID, it is represented as a The main structure consist of an array of two elements: "xlatTableID"
JSON string in which the dots of the OID are replaced by underscores, and "mibString".
and the OID is prefixed by "oid_".
The "Value" field contains the variable value, using the JSON data The values of the MIB strings are stored in the "mibString" field.
type as indicated in Table 1. This field consist of integer-value pairs. The integers correspond
to the string numbers, whereas the values contain the actual value of
the associated string.
+-----------------------+----------------+--------------------------+ The "xlatTableID" contains an integer that is used to indentify the
| SMI type | JSON type | Specification | translation table. The translation table can be acquired as follows:
+-----------------------+----------------+--------------------------+
| OBJECT-IDENTIFIER | array of | |
| | integers | |
| | | |
| Integer32 | integer | |
| | | |
| INTEGER | integer | |
| | | |
| OCTET-STRING | Base64 encoded | |
| | string | |
| | | |
| BITS | array of | The integers can only |
| | integers | take the values 0 and 1. |
| | | |
| IpAddress | string | [RFC4291] |
| | | |
| Counter32 | integer | |
| | | |
| Gauge32 | integer | |
| | | |
| TimeTicks | integer | |
| | | |
| Counter64 | integer | |
| | | |
| Unsigned32 | integer | |
| | | |
| Table | array | Section 4.1.1 |
+-----------------------+----------------+--------------------------+
Table 1: Conversion of SMI types to JSON GET /mg/xlat/[xlatTableID]
For example, the number of UDP datagrams received can be obtained where "[xlatTableID]" is replaced by the the value of xlatId from the
through the udpInDatagrams variable as specified in [RFC4113]. It CBorMIB structure, encoded as a hexidecimal integer without leading
could have the following outcome: zeros.
{ The maintenance of the table is described in Section 7.2.
"udpInDatagrams" : 82174
}
Alternatively, when the response uses an OID instead of the variable The use of the table is to initialize devices with the strings which
identifier, the outcome would be as follows: will be frequently used, such as the strings of the descriptors in
the MIB variables. The transmitted CBOR data will contain the string
numbers and not the entire descriptor strings, leading to appreciable
data reduction.
{ It is important that sender and receiver have identical versions of
"oid_1_3_6_1_2_1_7_1" : 82174 the table.
}
Another example of a JSON encoding of two (fictional) MIB variables The translation table is serialized to the payload in the following
"aBitString" and "anObjectID", with types BITS and OBJECT-IDENTIFIER, fashion:
is as follows:
{ xlatTable : XLatTable;
"aBitString" : [ 0, 1, 0, 0, 1, 1 ],
"anObjectID" : [ 1, 3, 6, 1, 10 ]
}
4.1.1. Tables in JSON *XLatTable {
xlatId : uint;
xlatData : map( uint, tstr );
}
If a MIB object is a table, it is represented as an array of rows, where "xlatId" has the same value as "xlatId" in the CBorMIB
the elements of which contain tuples related to the rows. structure, and "xlatData" is a CBOR map between the string number and
associated variable descriptor.
For example, an udpEndpointTable would be encoded as follows: 4.2. Mapping SMI to CBOR
{ 4.2.1. General overview
"udpEndpointTable" : [
{
"udpEndpointLocalAddressType" : 2,
"udpEndpointLocalAddress" : "2001:D3B8::417A",
"udpEndpointLocalPort" : 5683,
"udpEndpointRemoteAddressType" : 2,
"udpEndpointRemoteAddress" : "2001:5C3D::59C1",
"udpEndpointRemotePort" : 8000,
"udpEndpointInstance" : 14789215,
"udpEndpointProcess" : 61572493
},
{
"udpEndpointLocalAddressType" : 2,
"udpEndpointLocalAddress" : "2001:D3B8::417A",
"udpEndpointLocalPort" : 5683,
"udpEndpointRemoteAddressType" : 2,
"udpEndpointRemoteAddress" : "4301:5338::DFC1",
"udpEndpointRemotePort" : 6000,
"udpEndpointInstance" : 14892714,
"udpEndpointProcess" : 157491
}
]
}
4.2. Mapping SMI to CBOR 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
YANG and subsequently YANG 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.
CBOR [I-D.bormann-cbor] is a binary format designated for the 4.2.2. Conversion from YANG datatypes to CBOR datatypes
transmission of structured information. This section discusses how
CBOR can be used to exchange MIB data.
The MIB variables are represented in a CBOR map of indefinite length. Table 1 defines the mapping between YANG datatypes and CBOR
Such a map is a list of paired data fields. The first data field of datatypes.
each pair contains either a string containing the name of the MIB
variable, or an array of integers containing the MIB variable's OID.
The second datafield contains the variable's value.
Table 2 gives an overview of the conversion from SMI to CBOR. If the Elements of types not in this table, and of which the type cannot be
first element of a pair in the map contains an OID, it uses the same inferred from a type in this table, are ignored in the CBOR encoding
CBOR format for the first element as defined in the table in the by default. Examples include the "description" and "key" elements.
"OBJECT-IDENTIFIER" row. However, conversion rules for some elements to CBOR MAY be defined
elsewhere.
+-----------------------+----------------+--------------------------+ +-------------+------------------+----------------------------------+
| SMI type | CBOR type | Specification | | YANG type | CBOR type | Specification |
+-----------------------+----------------+--------------------------+ +-------------+------------------+----------------------------------+
| OBJECT-IDENTIFIER | array of | First element | | int8, | unsigned int | The CBOR integer type depends on |
| | unsigned | corresponds to the most | | int16, | (major type 0) | the sign of the actual value. |
| | integers | left number in the OID. | | int32, | or negative int | |
| | | | | int64, | (mayor type 1) | |
| Integer32 | unsigned | | | uint16, | | |
| | integer or | | | uint32, | | |
| | negative | | | uint64, | | |
| | integer | | | decimal64 | | |
| | | | | | | |
| INTEGER | unsigned | | | boolean | either "true" | |
| | integer or | | | | (major type 7, | |
| | negative | | | | simple value 21) | |
| | integer | | | | or "false" | |
| | | | | | (major type 7, | |
| OCTET-STRING | byte string | | | | simple value 20) | |
| | | | | | | |
| BITS | array of | The integers can only | | string | text string | |
| | unsigned | take the values 0 and 1. | | | (major type 3) | |
| | integers | | | | | |
| | | | | enumeration | unsigned int | |
| IpAddress | text string | [RFC4291] | | | (major type 0) | |
| | | | | | | |
| Counter32 | unsigned | | | bits | array of text | Each text string contains the |
| | integer | | | | strings | name of a bit value that is set. |
| | | | | | | |
| Gauge32 | unsigned | | | binary | byte string | |
| | integer | | | | (major type 2) | |
| | | | | | | |
| TimeTicks | unsigned | | | empty | null (major type | TBD: This MAY not be applicable |
| | integer | | | | 7, simple value | to true MIBs, as SNMP may not |
| | | | | | 22) | support empty variables... |
| Counter64 | unsigned | | | | | |
| | integer | | | union | | Similar ot the JSON |
| | | | | | | transcription from |
| Unsigned32 | unsigned | | | | | [I-D.lhotka-netmod-yang-json], |
| | integer | | | | | the elements in a union MUST be |
| | | | | | | determined using the procedure |
| Table | array of maps | Section 4.2.1 | | | | specified in section 9.12 of |
+-----------------------+----------------+--------------------------+ | | | [RFC6020]. |
| | | |
| leaf-list | array (major | The array is encapsulated in the |
| | type 4) | map associated with the |
| | | descriptor. |
| | | |
| list | map (major type | Like the higher level map, the |
| | 4) | lower level map contains |
| | | descriptor number - value pairs |
| | | of the elements in the list. |
| | | |
| container | map (major type | The map contains decriptor |
| | 5) | number - value pairs |
| | | corresponding to the elements in |
| | | the container. |
| | | |
| smiv2:oid | array of | Each integer contains an element |
| | integers | of the OID, the first integer in |
| | | the array corresponds to the |
| | | most left element in the OID. |
+-------------+------------------+----------------------------------+
Table 2: Conversion of SMI types to CBOR Table 1: Conversion of YANG datatypes to CBOR
For example, the variable "udpInDatagrams" of SMI type "Counter32" 4.2.3. Examples
and value "82174" is reflected in CBOR as follows:
BF # map (indefinite) 4.2.3.1. ipNetToMediaTable to JSON/CBOR
6E 75 64 70 49 6E 44 61 74 61 67 72 61 6D 73 # "udpInDatagrams"
1A 00 01 40 FE # 32-bit int 82174
FF # end of map
Or alternatively, using the OID of "udpInDatagrams": The YANG translation of the SMI specifying the
ipNetToMediaTable yields:
BF # map (indefinite) container ipNetToMediaTable {
88 01 03 06 01 02 01 07 01 # 1.3.6.1.2.1.7.1 list ipNetToMediaEntry {
1A 00 01 40 FE # 32-bit int 82174 leaf ipNetToMediaIfIndex {
FF # end of map type: int32;
}
leaf ipNetToPhysAddress {
type: phys-address;
}
leaf ipNetToMediaNetAddress {
type: ipv4-address;
}
leaf ipNetToMediaType {
type: int32;
}
}
}
4.2.1. Tables in CBOR The coresponding JSON looks like:
In case a MIB variable is a table, it is represented in CBOR with a {
indefinite length array of maps. "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"
}
]
}
}
The array corresponds to the rows in the MIB table, and its elements An example CBOR instance of the MIB can be found in Figure 1. The
consist of maps corresponding to the elements of each row. The names "ipNetToMediaTable", "ipNetToMediaEntry", and
encoding of the maps has the same syntax as the main map. "ipNetToMediaIfIndex" are represented with the string numbers 00, 01,
and 02 as described in Section 4.1.
For example, the "udpEndpointTable" from Section 3.1.2 would be 82 # two element array
encoded in CBOR as follows: 19 43 A1 # translation table ID 43A1
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
BF # main map (indefinite) Figure 1: Example CBOR encoding for ifTable
70 75 64 70 45 6E 64 70 6F 69 6E
74 54 61 62 6C 65 # "udpEndpointTable"
9F # array (indefinite)
BF # map for first row
78 1B 75 64 70 45 6E 64 70
6F 69 6E 74 4C 6F 63 61 6C
41 64 64 72 65 73 73 54 79
70 65 # "udpEndpointLocalAddressType"
02 # integer 2
77 75 64 70 45 6E 64 70 6f
69 6e 74 4C 6f 63 61 6C 41
64 64 72 65 73 73 # "udpEndpointLocalAddress"
6f 32 30 30 31 3A 44 33 42
38 3A 3A 34 31 37 41 # "2001:D3B8::417A"
74 75 64 70 45 6E 64 70 6F
69 6E 74 4C 6f 63 61 6C 50
6F 72 74 # "udpEndpointLocalPort"
19 16 33 # 5683
78 1C 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 54
79 70 65 # "udpEndpointRemoteAddressType"
02 # 2
78 18 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 # "udpEndpointRemoteAddress"
6F 32 30 30 31 3A 35 43 33
44 3A 3A 35 39 43 31 # "2001:5C3D::59C1"
75 75 64 70 45 6E 64 70 6F
69 6E 74 52 65 6D 6F 74 65
50 6F 72 74 # "udpEndpointRemotePort"
19 1F 40 # 8000
73 75 64 70 45 6E 64 70 6F
69 6E 74 49 6E 73 74 61 6E
63 65 # "udpEndpointInstance"
1A 00 E1 AA 5F # 14789215
72 75 64 70 45 6E 64 70 6F
69 6E 74 50 72 6F 63 65 73
73 # "udpEndpointProcess"
1A 03 AB 85 8D # 61572493
FF # end of first row
BF # map for second row
78 1B 75 64 70 45 6E 64 70
6F 69 6E 74 4C 6F 63 61 6C
41 64 64 72 65 73 73 54 79
70 65 # "udpEndpointLocalAddressType"
02 # integer 2
77 75 64 70 45 6E 64 70 6F
69 6E 74 4C 6F 63 61 6C 41
64 64 72 65 73 73 # "udpEndpointLocalAddress"
6F 32 30 30 31 3A 44 33 42
38 3A 3A 34 31 37 41 # "2001:D3B8::417A"
74 75 64 70 45 6E 64 70 6F
69 6E 74 4C 6F 63 61 6C 50
6F 72 74 # "udpEndpointLocalPort"
19 16 33 # 5683
78 1C 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 54
79 70 65 # "udpEndpointRemoteAddressType"
02 # 2
78 18 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 # "udpEndpointRemoteAddress"
6F 34 33 30 31 3A 35 33 33
38 3A 3A 44 46 43 31 # "4301:5338::DFC1"
75 75 64 70 45 6E 64 70 6F
69 6E 74 52 65 6D 6F 74 65
50 6F 72 74 # "udpEndpointRemotePort"
19 17 70 # 6000
73 75 64 70 45 6E 64 70 6F
69 6E 74 49 6E 73 74 61 6E
63 65 # "udpEndpointInstance"
1A 00 E3 3E AA # 14892714
72 75 64 70 45 6E 64 70 6F
69 6E 74 50 72 6F 63 65 73
73 # "udpEndpointProcess"
1A 00 02 67 33 # 157491
FF # end of second row
FF # end of array
FF # end of main map
TBD: we may consider splitting up the CBOR definition in two parts, The associated "descriptor string" to "string number" translation
the first part containing a translation table with ( integer, table is given in Figure 2.
descriptor/oid ) pairs, the second as above but using instead of the
descriptor/oid the integers defined in the translation table. This
would increase coding efficiency, but requires some extra work
especially on the client (managing entity) side. This suggestion
would lead to the following CBOR data:
82 # two element array 82 # two element array
BF # translation map (indefinite) 19 43 A1 # translation table ID 43A1
00 # 0: BF # indefinite length map
70 75 64 70 45 6E 64 70 6F 00 # descriptor number related to
69 6E 74 54 61 62 6C 65 # "udpEndpointTable" # ipNetToMediaTable
01 # 1: 72 69 70 50 65 74 57
78 1B 75 64 70 45 6E 64 70 6F 51 65 64 61 57 61
6F 69 6E 74 4C 6F 63 61 6C 62 6C 65 # "ipNetToMediaTable"
41 64 64 72 65 73 73 54 79 01 # descriptor number related to
70 65 # "udpEndpointLocalAddressType" # ipNetToMediaEntry
02 # 2: 72 69 70 50 65 74 57
77 75 64 70 45 6E 64 70 6f 6F 51 65 64 61 45 6E
69 6e 74 4C 6f 63 61 6C 41 74 72 78 # "ipNetToMediaEntry"
64 64 72 65 73 73 # "udpEndpointLocalAddress" 02 # descriptor number related to
03 # 3: # ipNetToMediaIfIndex
74 75 64 70 45 6E 64 70 6F 75 69 70 50 65 74 57
69 6E 74 4C 6f 63 61 6C 50 6F 51 65 64 61 61 49
6F 72 74 # "udpEndpointLocalPort" 66 49 6E 64 65 77 # "ipNetToMediaIfIndex"
04 # 4: # ...
78 1C 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 54
79 70 65 # "udpEndpointRemoteAddressType"
05 # 5:
78 18 75 64 70 45 6E 64 70
6F 69 6E 74 52 65 6D 6F 74
65 41 64 64 72 65 73 73 # "udpEndpointRemoteAddress"
06 # 6:
75 75 64 70 45 6E 64 70 6F
69 6E 74 52 65 6D 6F 74 65
50 6F 72 74 # "udpEndpointRemotePort"
07 # 7:
73 75 64 70 45 6E 64 70 6F
69 6E 74 49 6E 73 74 61 6E
63 65 # "udpEndpointInstance"
08 # 8:
72 75 64 70 45 6E 64 70 6F
69 6E 74 50 72 6F 63 65 73
73 # "udpEndpointProcess"
FF FF
BF # variables map (indefinite)
00 # 0="udpEndpointTable"
9F # array (indefinite)
BF # map for first row
01 # 1="udpEndpointLocalAddressType"
02 # integer 2
02 # 2="udpEndpointLocalAddress"
6f 32 30 30 31 3A 44 33
42 38 3A 3A 34 31 37 41 # "2001:D3B8::417A"
03 # 3="udpEndpointLocalPort"
19 16 33 # 5683
04 # 4="udpEndpointRemoteAddressType"
02 # 2
05 # 5="udpEndpointRemoteAddress"
6F 32 30 30 31 3A 35 43
33 44 3A 3A 35 39 43 31 # "2001:5C3D::59C1"
06 # 6="udpEndpointRemotePort"
19 1F 40 # 8000
07 # 7="udpEndpointInstance"
1A 00 E1 AA 5F # 14789215
08 # 8="udpEndpointProcess"
1A 03 AB 85 8D # 61572493
FF # end of first row
BF # map for second row
01 # 1="udpEndpointLocalAddressType"
02 # integer 2
02 # 2="udpEndpointLocalAddress"
6F 32 30 30 31 3A 44 33
42 38 3A 3A 34 31 37 41 # "2001:D3B8::417A"
03 # 3="udpEndpointLocalPort"
19 16 33 # 5683
04 # 4="udpEndpointRemoteAddressType"
02 # 2
05 # 5="udpEndpointRemoteAddress"
6F 34 33 30 31 3A 35 33
33 38 3A 3A 44 46 43 31 # "4301:5338::DFC1"
06 # 6="udpEndpointRemotePort"
19 17 70 # 6000
07 # 7="udpEndpointInstance"
1A 00 E3 3E AA # 14892714
08 # 8="udpEndpointProcess"
1A 00 02 67 33 # 157491
FF # end of second row
FF # end of array
FF # end of main map
Obviously this leads to less bytes to transmit, but it needs to Figure 2: Translation table for ifTable
define an extra translation table. The server can include the fixed
mapping as a macro, so it does not need to calculate it for each
request. In this example the translation map is for the whole
structure. The map can be restricted to the entries that are used.
4.3. Mapping SMI to XML 4.2.4. 6LoWPAN MIB
The types specified by SMI can be represented by a XML syntax
according to the specification in this section. The XML syntax is
taken over from http://www.w3c.org/2001/XMLSchema-datatypes.
+---------------------+------------------------+---------------+ A MIB for 6LoWPAN is defined in [I-D.schoenw-6lowpan-mib]. The
| SMI type | XML type | Specification | document also provides an example JSON representation in its
+---------------------+------------------------+---------------+ Appendix A. Figure 3 shows the associated CBOR representation with
| OBJECT-IDENTIFIER: | array of int | | string number, and Figure 4 shows the corresponding string to string
| | | | number conversion table.
| Integer32: | int | |
| | | |
| INTEGER: | int | |
| | | |
| OCTET-STRING: | Base64 encoded string | |
| | | |
| BITS: | bits | Appendix A |
| | | |
| IPAddress: | string | [RFC4291] |
| | | |
| Counter32: | nonNegativeInteger | |
| | | |
| Gauge32: | nonNegativeInteger | |
| | | |
| TimeTicks: | time | |
| | | |
| Counter64: | unsignedlong | |
| | | |
| Unsigned32: | unsignedInt | |
| | | |
| Table | MIBTable | Appendix A |
+---------------------+------------------------+---------------+
Table 3: Conversion of SMI types to XML 82 # two element array
1A 8B 47 88 F3 # translation table ID 8B4788F3
BF # indefinite length map
00 # "LOWPAN-MIB:LOWPAN-MIB"
BF # indefinite length map related to ifTable
01 # "lowpanReasmTimeout"
14 # 20
02 # "lowpanInReceives"
18 2A # 42
03 # "lowpanInHdrErrors"
00 # 0
04 # "lowpanInMeshReceives"
08 # 8
05 # "lowpanInMeshForwds"
00 # 0
06 # "lowpanInMeshDelivers"
00 # 0
07 # "lowpanInReasmReqds"
16 # 22
08 # "lowpanInReasmFails"
02 # 02
09 # "lowpanInReasmOKs"
14 # 20
0A # "lowpanInCompReqds"
10 # 16
0B # "lowpanInCompFails"
02 # 2
0C # "lowpanInCompOKs"
0E # 14
0D # "lowpanInDiscards"
01 # 01
0E # "lowpanInDelivers"
0C # 12
0F # "lowpanOutRequests"
0C # 12
10 # "lowpanOutCompReqds"
00 # 0
11 # "lowpanOutCompFails"
00 # 0
12 # "lowpanOutCompOKs"
00 # 0
13 # "lowpanOutFragReqds"
05 # 5
14 # "lowpanOutFragFails"
00 # 0
15 # "lowpanOutFragOKs"
05 # 5
16 # "lowpanOutFragCreates"
08 # 8
17 # "lowpanOutMeshHopLimitExceeds"
00 # 0
18 18 # "lowpanOutMeshNoRoutes"
00 # 0
18 19 # "lowpanOutMeshRequests"
00 # 0
18 1A # "lowpanOutMeshForwds"
00 # 0
18 1B # "lowpanOutMeshTransmits"
00 # 0
18 1C # "lowpanOutDiscards"
00 # 0
18 1D # "lowpanOutTransmits"
0F # 15
FF
4.3.1. Tables in XML FF
In case a MIB variable is a table, it is represented in XML with an Figure 3: Example CBOR encoding for the 6LoWPAN MIB
indefinite length SEQUENCE of type entry. Each element of entry has
a name and a choice of XML types. The associated schema is shown in
Appendix A. For example the udpEndPointTable would look like:
<MIBTable> 82 # two element array
<MIBidentifier> 1A 8B 47 88 F3 # translation table ID 8B4788F3
<descriptor>"udpEndpointTable"</descriptor> BF # indefinite length map
</MIBidentifier> 00
<row> 75 # "LOWPAN-MIB:LOWPAN-MIB"
<entry name="udpEndpointLocalAddressType" value="2"/> 01 #
<entry name="udpEndpointLocalAddress" value="2001:D3B8::417A"/> 72 ... # "lowpanReasmTimeout"
<entry name="udpEndpointLocalPort" value="5683"/> 02
<entry name="udpEndpointRemoteAddressType" value="2"/> 70 ... # "lowpanInReceives"
<entry name="udpEndpointRemoteAddress" value="2001:5C3D::59C1"/> 03
<entry name="udpEndpointRemotePort" value="8000"/> 71 ... # "lowpanInHdrErrors"
<entry name="udpEndpointInstance" value="14789215"/> 04
<entry name="udpEndpointProcess" value="61572493"/> 74 ... # "lowpanInMeshReceives"
</row> 05
<row> 72 ... # "lowpanInMeshForwds"
<entry name="udpEndpointLocalAddressType" value="2"/> 06
<entry name="udpEndpointLocalAddress" value="2001:D3B8::417A"/> 74 ... # "lowpanInMeshDelivers"
<entry name="udpEndpointLocalPort" value="5683"/> 07
<entry name="udpEndpointRemoteAddressType" value="2"/> 72 ... # "lowpanInReasmReqds"
<entry name="udpEndpointRemoteAddress" value="4301:5338::DFC1"/> 08
<entry name="udpEndpointRemotePort" value="6000"/> 72 ... # "lowpanInReasmFails"
<entry name="udpEndpointInstance" value="147892714"/> 09
<entry name="udpEndpointProcess" value="157491"/> 70 ... # "lowpanInReasmOKs"
</row> 0A
</MIBTable> 71 ... # "lowpanInCompReqds"
0B
71 ... # "lowpanInCompFails"
0C
6F ... # "lowpanInCompOKs"
0D
70 ... # "lowpanInDiscards"
0E
70 ... # "lowpanInDelivers"
0F
71 ... # "lowpanOutRequests"
10
72 ... # "lowpanOutCompReqds"
11
72 ... # "lowpanOutCompFails"
12
70 ... # "lowpanOutCompOKs"
13
72 ... # "lowpanOutFragReqds"
14
72 ... # "lowpanOutFragFails"
15
70 ... # "lowpanOutFragOKs"
16
74 ... # "lowpanOutFragCreates"
17
78 1B ... # "lowpanOutMeshHopLimitExceeds"
18 18
75 ... # "lowpanOutMeshNoRoutes"
18 19
75 ... # "lowpanOutMeshRequests"
18 1A
73 ... # "lowpanOutMeshForwds"
18 1B
76 ... # "lowpanOutMeshTransmits"
18 1C
71 ... # "lowpanOutDiscards"
18 1D
72 ... # "lowpanOutTransmits"
FF
When the MIBidentifier is an OID the syntax for MIB object Figure 4: Translation table for the 6LoWPAN MIB
1.3.6.1.2.1.1.3 looks like:
<MIBObject> In this example, a GET to /mg/mib/lowpanOutFragFails would give:
<MIBidentifier>
<oid> 82 # two element array
<ident>1</ident> 1A 8B 47 88 F3 # translation table ID 8B4788F3
<ident>3</ident> BF # indefinite length map
<ident>6</ident> 14 # "lowpanOutFragFails"
<ident>1</ident> 00 # 0
<ident>2</ident> FF
<ident>1</ident>
<ident>1</ident>
<ident>3</ident>
</oid>
</MIBidentifier>
<MIBvalue value="324"/>
</MIBObject>
5. MIB discovery 5. MIB discovery
MIB objects are discovered like resources with the standard CoAP MIB objects are discovered like resources with the standard CoAP
resource discovery. Performing a GET on "/.well-known/core" with resource discovery. Performing a GET on "/.well-known/core" with
rt=core.mg.mib returns all MIB descriptors and all OIDs which are rt=core.mg.mib returns all MIB descriptors and all OIDs which are
available on this device. For table objects there is no further available on this device. For table objects there is no further
possibility to discover the row descriptors. For example, consider possibility to discover the row descriptors. For example, consider
there are two MIB objects with descriptors "sysUpTime" and there are two MIB objects with descriptors "sysUpTime" and
"ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and "ipNetToMediaTable" associated with OID 1.3.6.1.2.1.1.3 and
1.3.6.1.2.1.4.22 1.3.6.1.2.1.4.22
REQ: GET example.com/.well-known/core?rt=core.mg.mib REQ: GET example.com/.well-known/core?rt=core.mg.mib
RES: 2.05 Content (Content-Format: application/text) RES: 2.05 Content (Content-Format: application/text)
</mg/mib/sysUpTime>;rt="core.mg.mib";oid="1.3.6.1.2.1.1.3" </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" </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 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 MIB resource with its OID. The OID is written as a string in its
conventional form. conventional form.
Notice that a MIB variable normally is associated with a descriptor Notice that a MIB variable normally is associated with a descriptor
and an OID. The OID is unique, whereas the descriptor may not. 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].
6. Trap functions 6. Trap functions
A trap can be set through the CoAP Observe [I-D.ietf-core-observe] A trap can be set through the CoAP Observe [I-D.ietf-core-observe]
function. As regular with Observe, the managing entity subscribes to function. As regular with Observe, the managing entity subscribes to
the variable by sending a GET request with an "Observe" option. the variable by sending a GET request with an "Observe" option.
TODO: Observe example
In the registration request, the managing entity MAY include a In the registration request, the managing entity MAY include a
"Response-To-Uri-Host" and optionally "Response-To-Uri-Port" option "Response-To-Uri-Host" and optionally "Response-To-Uri-Port" option
as defined in [I-D.becker-core-coap-sms-gprs]. In this case, the as defined in [I-D.becker-core-coap-sms-gprs]. In this case, the
observations SHOULD be sent to the address and port indicated in observations SHOULD be sent to the address and port indicated in
these options. This can be useful when the managing entity wants the these options. This can be useful when the managing entity wants the
managed device to send the trap information to a multicast address. managed device to send the trap information to a multicast address.
7. MIB access management 7. MIB access management
Setting up parameter values and establishing relations between Two topics are relevant: (1) the definition of the destination of
devices during commissioning of a managed network is needed for the Notify messages, and (2) the creation and maintenance of "string to
TRAP function. Draft [I-D.ietf-core-interfaces] describes the number" tables.
binding of end-points to end-points on remote devices. This is just
a table that contains the destination addresses of the MIB variables.
A list of objects describing different aspects of commissioning
comprise:
o Binding table as described in [I-D.ietf-core-interfaces], schema
presented in Appendix B.1.
o Notification sources as referred to in [RFC3416], schema presented
in Appendix B.1.
o Names of files containing the schemas to be expected, schema 7.1. Notify destinations
presented in Appendix B.2.
The destination of notifications need to be communicated to the
applications sending them. Draft [I-D.ietf-core-interfaces]
describes the binding of end-points to end-points on remote devices.
The object with type "binding table" contains a sequence of bindings. The object with type "binding table" contains a sequence of bindings.
The contents of bindings contains the methods, location, the interval The contents of bindings contains the methods, location, the interval
specifications, and the step value as suggested in specifications, and the step value as suggested in
[I-D.ietf-core-interfaces]. The method "notify" has been added to [I-D.ietf-core-interfaces]. The method "notify" has been added to
the binding methods "poll", "obs" and "push", to cater for the the binding methods "poll", "obs" and "push", to cater for the
binding of notification source to the receiver. binding of notification source to the receiver.
The object of type "Schema-files" contains a sequence of schema files TODO: describe interface for NOTIFY destination definition.
describing the data structure transportable in CoMI messages.
8. Security Considerations 7.2. Conversion tables
POST is used to initialize a conversion table. At the arrival of the
POST, all existing tables are removed and new tables as specified by
the payload are created with the contents specified in the payload.
When the payload of the POST is empty, no table is created.
PUT is used to create new entries in an existing table and overwrite
existing entries. When the payload of the PUT contains a non
existing table, a new table with the new identity is created. When
the payload of the PUT contains a table with an already existing
identifier, two possiblities exist:
exiting string value the contents of the existing pair is
overwritten with the pair in the payload.
new string value A new pair is created in the table with the pair in
the payload.
8. Error handling
In case a request is received which cannot be processed properly, the
managed entity MUST return an error message. This error message MUST
contain a CoAP 4.xx or 5.xx response code, and SHOULD include
additional information in the payload.
Such an error message payload is encoded in CBOR, using the following
structure:
errorMsg : ErrorMsg;
*ErrorMsg {
errorCode : uint;
?errorText : tstr;
}
The variable "errorCode" has one of the values from the table below,
and the OPTIONAL "errorText" field contains a human readible
explanation of the error.
+----------------+----------------+---------------------------------+
| CoMI Error | CoAP Error | Description |
| Code | Code | |
+----------------+----------------+---------------------------------+
| 0 | 4.00 | General error |
| | | |
| 1 | 4.00 | Malformed CBOR data |
| | | |
| 2 | 4.00 | Incorrect CBOR datatype |
| | | |
| 3 | 4.00 | Unknown MIB variable |
| | | |
| 4 | 4.00 | Unknown translation table |
| | | |
| 5 | 4.05 | Attempt to write read-only |
| | | variable |
| | | |
| 0..2 | 5.01 | Access exceptions |
| | | |
| 0..18 | 5.00 | SMI error status |
+----------------+----------------+---------------------------------+
The CoAP error code 5.01 is associted with the exceptions defined in
[RFC3416] and CoAP error code 5.00 is associated with the error-
status defined in [RFC3416].
9. Security Considerations
TODO: follows CoAP security provisioning. TODO: follows CoAP security provisioning.
9. IANA Considerations 10. IANA Considerations
'rt="core.mg.mib"' needs registration with IANA. 'rt="core.mg.mib"' needs registration with IANA.
Content types to be registered: Content types to be registered:
o application/comi+xml
o application/comi+exi
o application/comi+json o application/comi+json
o application/comi+cbor o application/comi+cbor
10. Acknowledgements 11. Acknowledgements
Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs
transported under SNMP. Carsten Bormann has given feedback on the transported under SNMP. Carsten Bormann has given feedback on the
use of CBOR. The draft has benefited from comments by Dee Denteneer, use of CBOR. Juergen Schoenwalder has commented on inconsistencies
Esko Dijk, and Michael van Hartskamp. and missing aspects of SNMP in earlier versions of the draft. The
draft has benefited from comments by Thomas Watteyne, Dee Denteneer,
Esko Dijk, and Michael van Hartskamp. The CBOR encoding borrows
extensively from Ladislav Lhotka's description on conversion from
YANG to JSON.
11. Changelog 12. Changelog
Changes from version 00 to version 01 Changes from version 00 to version 01
o Focus on MIB only o Focus on MIB only
o Introduced CBOR, JSON, removed BER o Introduced CBOR, JSON, removed BER
o defined mappings from SMI to xx o defined mappings from SMI to xx
o Introduced the concept of addressable table rows o Introduced the concept of addressable table rows
12. References Changes from version 01 to version 02
12.1. Normative References o Focus on CBOR, used JSON for examples, removed XML and EXI
o added uri-query attributes mod and con to specify modules and
contexts
o Definition of CBOR string conversion tables for data reduction
o use of Block for multiple fragments
o Error returns generalized
o SMI - YANG - CBOR conversion
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.bormann-cbor] [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Bormann, C. and P. Hoffman, "Concise Binary Object Network Configuration Protocol (NETCONF)", RFC 6020,
Representation (CBOR)", draft-bormann-cbor-09 (work in October 2010.
progress), September 2013.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013.
[I-D.becker-core-coap-sms-gprs] [I-D.becker-core-coap-sms-gprs]
Becker, M., Li, K., Poetsch, T., and K. Kuladinithi, Becker, M., Li, K., Poetsch, T., and K. Kuladinithi,
"Transport of CoAP over SMS", draft-becker-core-coap-sms- "Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-04 (work in progress), August 2013. gprs-04 (work in progress), August 2013.
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-14 (work in progress), October 2013.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-core-observe] [I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf- Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-10 (work in progress), September 2013. core-observe-11 (work in progress), October 2013.
[I-D.ietf-json-rfc4627bis] [I-D.ietf-json-rfc4627bis]
Bray, T., "The JSON Data Interchange Format", draft-ietf- Bray, T., "The JSON Data Interchange Format", draft-ietf-
json-rfc4627bis-06 (work in progress), October 2013. json-rfc4627bis-10 (work in progress), December 2013.
12.2. Informative References [I-D.lhotka-netmod-yang-json]
Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka-
netmod-yang-json-02 (work in progress), September 2013.
13.2. Informative References
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II", for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991. STD 17, RFC 1213, March 1991.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002. 3416, December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002. 3418, December 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform
Resource Identifier (URI) Scheme for the Simple Network
Management Protocol (SNMP)", RFC 4088, June 2005.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for [RFC4113] Fenner, B. and J. Flick, "Management Information Base for
the User Datagram Protocol (UDP)", RFC 4113, June 2005. the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management [RFC6643] Schoenwaelder, J., "Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG Information Version 2 (SMIv2) MIB Modules to YANG
Modules", RFC 6643, July 2012. Modules", RFC 6643, July 2012.
skipping to change at page 26, line 5 skipping to change at page 30, line 10
Reporting Format (ARF)", RFC 6650, June 2012. Reporting Format (ARF)", RFC 6650, June 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012. Format", RFC 6690, August 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-core-groupcomm] [I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-16 (work in progress), October draft-ietf-core-groupcomm-18 (work in progress), December
2013. 2013.
[I-D.ietf-core-interfaces] [I-D.ietf-core-interfaces]
Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-
core-interfaces-00 (work in progress), June 2013. core-interfaces-01 (work in progress), December 2013.
[I-D.ersue-constrained-mgmt] [I-D.ersue-constrained-mgmt]
Ersue, M., Romascanu, D., and J. Schoenwaelder, Ersue, M., Romascanu, D., and J. Schoenwaelder,
"Management of Networks with Constrained Devices: Problem "Management of Networks with Constrained Devices: Problem
Statement, Use Cases and Requirements", draft-ersue- Statement, Use Cases and Requirements", draft-ersue-
constrained-mgmt-03 (work in progress), February 2013. constrained-mgmt-03 (work in progress), February 2013.
[STD0001] , "Official Internet Protocols Standard", Web [I-D.schoenw-6lowpan-mib]
http://www.rfc-editor.org/rfcxx00.html, . Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
"Definition of Managed Objects for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", draft-
schoenw-6lowpan-mib-03 (work in progress), February 2013.
[EXI] , "Efficient XML Interchange", Web [I-D.bierman-netconf-restconf]
http://www.w3.org/xml/exi, . Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-bierman-netconf-restconf-02
(work in progress), October 2013.
[XML] , "Extensible Markup Language (XML)", Web [STD0001] "Official Internet Protocols Standard", Web
http://www.rfc-editor.org/rfcxx00.html, .
[XML] "Extensible Markup Language (XML)", Web
http://www.w3.org/xml, . http://www.w3.org/xml, .
[JSON] , "JavaScript Object Notation (JSON)", Web [JSON] "JavaScript Object Notation (JSON)", Web
http://www.json.org, . http://www.json.org, .
[EXI-primer] Appendix A. Notational Convention for CBOR data
Peintner, D. and S. Pericas-Geertsen, "EXI primer", Web
http://www.w3.org/TR/exi-primer, december 2009.
[EXI-measurement]
White, G., KangaSharju, J., Williams, S., and D. Brutzman,
"Efficient XML Interchange Measurements Note", Web
http://www.w3.org/TR/2007/WD-exi-measurements-20070725,
July 2007.
[JSON-XML]
Nurseitov, N., Paulson, M., Reynolds, R., and C.
Inzurieta, "Comparison of JSON and XML Data Interchange
Formats: A Case Study", Web
http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf,
2009.
Appendix A. XML Schema for MIB
This appendix describes the XML schema that defines the payload
contents for MIB requests via the CoMI Function Set. It is assumed
that MIB variables are referred by descriptor or by OID.
TODO: The schema needs to be updated to define basic types and
notifications. Access may be more sophisticated than described here.
<xsd:simpleType name="bits">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="bit0"/>
<xsd:enumeration value="bit1"/>
<xsd:enumeration value="bit2"/>
<xsd:enumeration value="bit3"/>
<xsd:enumeration value="bit4"/>
<xsd:enumeration value="bitn"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="exception">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="noSuchObject"/>
<xsd:enumeration value="noSuchInstance"/>
<xsd:enumeration value="endOfMibView"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="error-status">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="noError"/>
<xsd:enumeration value="tooBig"/>
<xsd:enumeration value="noSuchName"/>
<xsd:enumeration value="badValue"/>
<xsd:enumeration value="readOnly"/>
<xsd:enumeration value="genErr"/>
<xsd:enumeration value="noAccess"/>
<xsd:enumeration value="wrongType"/>
<xsd:enumeration value="wrongLength"/>
<xsd:enumeration value="wrongEncoding"/>
<xsd:enumeration value="wrongValue"/>
<xsd:enumeration value="noCreation"/>
<xsd:enumeration value="inconsistentValue"/>
<xsd:enumeration value="resourceUnavailable"/>
<xsd:enumeration value="commitFailed"/>
<xsd:enumeration value="undoFailed"/>
<xsd:enumeration value="authorizationError"/>
<xsd:enumeration value="notWritable"/>
<xsd:enumeration value="inconsistentName"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="MIBscalar">
<xsd:attribute name="name" type="xsd:string"/>
<xsd:choice>
<xsd:attribute name="value" type="xsd:string"/>
<xsd:attribute name="value" type="xsd:integer"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="MIBvalue">
<xsd:choice>
<xsd:attribute name="value" type="xsd:string"/>
<xsd:attribute name="value" type="xsd:integer"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name ="oid">
<xsd:sequence>
<xsd:element name="ident" type="xsd:integer"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name ="MIBidentifier">
<xsd:choice>
<xsd:element name="descriptor" type="xsd:string"/>
<xsd:element name="OID" type="oid"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="row">
<xsd:sequence>
<xsd:element name="entry" type="MIBscalar"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MIBTable">
<xsd:element name="MIBname" type="MIBidentifier"/>
<xsd:sequence>
<xsd:element name="Row" type="row"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MIBObject"> To express CBOR structures [RFC7049], this document uses the
<xsd:element name="MIBname" type="MIBidentifier"/> following conventions:
<xsd:element name="value" type="MIBvalue"/>
</xsd:complexType>
Appendix B. XML Schema for CoMI support A declaration of a CBOR variable has the form:
This appendix describes the XML schema that defines the payload name : datatype;
contents for requests via the CoMI Function Set to the CoMI objects
for multicast group, binding table, and SNMP notifications. For the
SNMP notifications the Binding Method table specification of
[I-D.ietf-core-interfaces] has been extended with "notify".
B.1. Schema for CoAP binding where "name" is the name of the variable, and "datatype" its CBOR
datatype.
Binding table contains several simple Bindings, composed of timing The name of the variable has no encoding in the CBOR data.
parameters and Function signature.
<xs:complexType name="CoAPmethod"> "datatype" can be a CBOR primitive such as:
<xs:restriction base="xs:string">
<xs:enumeration value="GET"/>
<xs:enumeration value="PUT"/>
<xs:enumeration value="POST"/>
</xs:restriction>
</xs:complexType>
<xs:complexType name="bindingMethod"> tstr: A text string (major type 3)
<xs:restriction base="xs:string">
<xs:enumeration value="poll"/>
<xs:enumeration value="obs"/>
<xs:enumeration value="push"/>
<xs:enumeration value="notify"/>
</xs:restriction>
</xs:complexType>
<xs:complexType name="invocation"> uint: An unsigned integer (major type 0)
<xs:element name="hostname" type="xs:string"/>
<xs:element name="pathname" type="xs:string"/>
<xs:element name="IPaddress" type="xs:string"/>
<xs:element name="bindingMethod" type="bindingMethod"/>
<xs:element name="CoAPmethod" type="CoAPmethod"/>
</xs:complexType>
<xs:complexType name="simpleBinding">
<xs:element name="method" type="invocation"/>
<xs:element name="minPeriod" type="xs:integer"/>
<xs:element name="maxPeriod" type="xs:integer"/>
<xs:element name="changeStep" type="xs:integer"/>
</xs:complexType>
<xs:complexType name="binding Table"> map(x,y): A map (major type 5), where each first element of a pair
<xs:sequence> is of datatype x, and each second element of datatype y. A '.'
<xs:element name="simpleBinding" type="simpleBinding" character for either x or y means that all datatypes for that
minOccurs="0" maxOccurs="unbounded"/> element are valid.
</xs:sequence>
</xs:complexType>
B.2. Valid Schemas A datatype can also be a CBOR structure, in which case the variable's
"datatype" field contains the name of the CBOR structure. Such CBOR
structure is defined by a character sequence consisting of first its
name, then a '{' character, then its subfields and finally a '}'
character.
File names are stored in Schema A CBOR structure can be encapsulated in an array, in which case its
name in its definition is preceeded by a '*' character. Otherwise
the structure is just a grouping of fields, but without actual
encoding of such grouping.
<xs:complexType name="Schema-files"> The name of an optional field is preceded by a '?' character. This
<xs:sequence> means, that the field may be omitted if not required.
<xs:element name="Schema" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Authors' Addresses Authors' Addresses
Peter van der Stok Peter van der Stok
consultant consultant
Phone: +31-492474673 (Netherlands), +33-966015248 (France) Phone: +31-492474673 (Netherlands), +33-966015248 (France)
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
URI: www.vanderstok.org URI: www.vanderstok.org
 End of changes. 134 change blocks. 
833 lines changed or deleted 835 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/