]> consultant

+31-492474673 (Netherlands), +33-966015248 (France) consultancy@vanderstok.org www.vanderstok.org

Applications coman The draft describes an interface based on CoAP to manage constrained devices. Access to existing MIBs is included. The proposed integration of CoAP with SNMP reduces the code size by removing an important part of the SNMP code. The draft lists a set of CoMI objects that describe the operational settings of the applications on the device. A majority of them is taken over from other drafts to provide one uniform CoMI based access. Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org.

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 .

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 as is testified by the large number of Management Information Base (MIB) specifications currently published . More recently, he NETCONF protocol was developed with an extended set of messages using XML as data format. The data syntax is specified with YANG and a mapping from Yang to XML is specified. In 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 are necessary when small devices from different manufacturers are managed by applications originating from another set of manufacturers. Stateless communication is encouraged to keep communications simple and the amount of state information small in line with the design objectives of 6lowpan , RPL , and CoAP . Currently, managed devices need to support two protocols: CoAP and SNMP each with its own security solution. When the MIB can be accessed with the CoAP protocol, the SNMP protocol with its security provisioning can be replaced with the CoAP protocol and DTLS . This arrangement significantly reduces memory requirements, simplifies the stack in the constrained device, and harmonizes applications development. A CoAP device that needs management can include a set of existing MIBs and use CoMI to manipulate them. The objective of CoMI is to provide a CoAP based Function Set that reads and sets parameter values in devices, and acquires operational values that change with time. It extends SNMP by providing an XML interface that allows more complex structures than the flat tables of SNMP. CoMI is intended for small devices. The XML overhead can be prohibitive. It is therefore recommended to transport EXI in the payload. In 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 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 seems the right choice. The end goal of CoMI is to provide information exchange over the CoAP transport protocol in a uniform manner to approach the full management functionality as specified in . This memo collects existing management functions from several sources to uniformize their access.

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

In CoRE a group of links can constitute a Function Set. The format of the links is specified in . 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 each accessible with a different path: MIB with path /mg/mib and a binary content format CoMI with path /mg/comi and an XML, EXI content format. The MIB resource is provided to enable a smooth transition from SNMP to CoMI. The binary content is composed of BER encoded SNMP PDUs. The CoMI resource provides access to the CoMI objects. CoMI objects include MIBs and the objects described in . XML schemas describe the structure of the CoMI objects. It is expected that given the verbosity of XML, CoMI messages will mostly use EXI. The service provided by the CoMI server is to transfer from/to the constrained devices: (1) BER encoded SNMP PDUs from/to MIBs, and (2) EXI encoded data from/to CoMI objects including MIB objects. The profile of the management function set, with IF=core.comi, is shown in the table below name path RT Data Type Management /mg core.mg n/a MIB binary /mg/mib core.mg.mib application/octet CoMI objects /mg/comi core.mg.comi application/exi CoMI MIB /mg/comi/mib core.mg.comi.mib application/exi It is intended that CoMI schemas will be developed independently for different management subjects or contexts. That means that the value of the EXI event has a different meaning dependent on the accompanying schema file. The set of schemas that will be used is annouced to the device, such that it can prepare the parsing tables in advance.

The MIB binary Function Set provides a CoAP interface to transport BER encoded SNMP PDUs. and explain the structure of SNMP PDUs and their transport with CoMI.

The architecture of the Internet Standard management framework consists of: A data definition language that is referred to as Structure of Management Information (SMI). The Management Information Base (MIB) which contains the information to be managed and is defined for each specific function to be managed . A protocol definition referred to as Simple Network Management Protocol (SNMP) . Security and administration that provides SNMP message based security on the basis of the user-based security model . 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. 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-IDENTFIERs 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. The binding of the notification to a destination (left open in SNMP protocol) is discussed in .

The payload is structured as specified by the ASN-1 notation presented in . The request PDUs: Get, GetNext, GetBulk, Set, and Inform are sent with a Confirmable CoAP message. The Response is piggy backed in the returned Acknowledgement message. The Trap is sent as a NON-confirmable CoAP message. The URI of the destination CoMI end-point contains the destination identifier and the path /mg/bin. The request PDUs: Get, GetNext, GetBulk are sent with CoAP message type GET, all other request PDUs are sent with CoAP message type PUT. Strictly speaking the request-id in the SNMP PDU has the same function as the CoAP token. Preferably, the value of request-id should be identical to the CoAP token. An example request looks like:

RES: 2.05 Content (Content-Format: application/octet-stream) ]]>

The BER encoding implies that OBJECT-IDENTIFIER is encoded as a sequence of numbers which defines the place of the object in the ISO object tree .

Two XML, EXI based interfaces are supported by CoMI: (1) Reading/Writing CoMI objects with path /mg/comi/object, (2) Reading/Writing MIB variables with path /mg/comi/mib/variable.

The information, represented by the CoMI objects, is composed of the values of configuration parameters in a device. A CoMI object has a name that identifies it uniquely within the device. The type of a CoMI object MUST be described with an XML schema. CoMI object names and schemas are standardized by the IETF or by other relevant Standards Developing Organizations (SDO). The CoMI object name is expressed in the path. The attributes of the CoMI object that need to be set or read are either expressed in the EXI payload of the message or in the path of the destination URI. By expressing the attribute in the path the data transfer is limited to one resource. An EXI message can express a selection of attributes that need to be set or read. For example, consider the object with name "Alarms" of type "alarmCount":

]]>

In the coming examples the format of the EXI contents follows the syntax proposed in . Retrieving the contents of attribute Priority1 by expressing the attribute in the path is possible with:

Retrieving the contents of Priority1 and Priority2 attributes by referring to the object as a whole in the URI is shown in the following example:

It is possible that the size of the specified object 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 specifies the maximum size in bytes. The returned data MUST terminate with an EE EXI event. The sequel can be asked by sending the same request but with an offset that is equal to the already received number of EE EXI events. The offset is specified with the (new to define) "of" link-format attribute.

The Function Set allows the access to one MIB variable per CoAP message. The schema is shown in . The identifier is based on the human readable name and not on the sequence of numbers that identifies the object in the ISO object hierachy. TODO: Distinguish CoMI objects of same type and thus with identical names. A request to read the value of a MIB variable is sent with a confirmable CoAP GET message. A request to set a value is sent with a confirmable CoAP PUT message. The Response is piggybacked to the CoAP ACK message corresponding with the Request. An example request looks like:

A MIB variable may be composed of rows with each row composed of typed values. Limits to the bulk transport are expressed with the "sz" link-format attribute and the "of" link-format attribute. When a variable with the specified name cannot be processed by the SNMP server, CoAP Error code 5.01 is returned with the SNMP error code transported in the payload. Two types of error code can be returned: exception or error-status as specified in , according to the rules of . For example when MIB "variable" does not exist:

The TRAP is sent with a non confirmable CoAP PUT message to a destination specified in .

Setting up parameter values and establishing relations between devices during commissioning of a managed network is an important aspect of the deployment of CoMI objects. Draft describes the binding of end-points to end-points on remote devices, and draft describes the enabling of multicast messages. A homogeneous approach to the associated resources is the subject of this section. A list of objects describing different aspects of commissioning comprise: Binding table as described in , schema presented in . Multicast address enabling as described in , schema presented in . SNMP notification destinations as referred to in , schema presented in . Names of files containing the schemas to be expected, schema presented in . The object with type "binding table" contains a sequence of bindings. The contents of bindings contains the methods, location, the interval specifications, and the step value as suggested in . The method "notify" has been added to the binding methods "poll", "obs" and "push", to cater for the binding of SNMP notifications to a target. The object of type "MCgroups" contains a sequence of MC addresses to be enabled on the interface, specified by MCentry. In these schemas both the host name (group name) and the corresponding IP address are stored. The IP address has been added for those networks where no access to DNS is possible and only the IP address is available. Once the DNS is available and the IP address is brittle, it is recommended to use the host name and not rely on the value of the IP address. The object of type "Schema-files" contains a sequence of schema files describing the data structure tranportable in CoMI messages.

TODO: follows CoAP security provisioning.

TODO

Mehmet Ersue and Bert Wijnen explained the encoding aspects of PDUs transported under SNMP. The draft has benefited from comments by Dee Denteneer, Esko Dijk, and Michael van Hartskamp.

&RFC2119; &RFC2578; &RFC3410; &RFC3414; &RFC3416; &RFC3418; &RFC4944; &RFC6020; &RFC6241; &RFC6347; &RFC6643; &RFC6650; &RFC6690; &RFC6775; &I-D.ietf-core-coap; &I-D.ietf-core-groupcomm; &I-D.ietf-core-interfaces; &I-D.ersue-constrained-mgmt;

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 name and not by the oid. TODO: The schema needs to be updated to define basic types and notifications. Access may be more sophisticated than described here. Creation and deletion of columns and rows is not catered for. The access modes are not visible.

]]>

This appendix describes the XML schema that defines the payload 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 has been extended with "notify".

MCentries are stored in MCGroups

]]>

Binding table contains several simple Bindings, composed of timing parameters and Function signature.

]]>

File names are stored in Schema

]]>