coman P. van der Stok Internet-Draft consultant Intended status: Informational June 28, 2013 Expires: December 30, 2013 CoAp Management Interfaces draft-vanderstok-core-comi-00 Abstract 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. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 30, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents van der Stok Expires December 30, 2013 [Page 1] Internet-Draft CoMI June 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. CoAP Interface . . . . . . . . . . . . . . . . . . . . . . . 4 5. MIB binary Function Set . . . . . . . . . . . . . . . . . . . 5 5.1. SNMP architecture . . . . . . . . . . . . . . . . . . . . 5 5.2. CoMI binding . . . . . . . . . . . . . . . . . . . . . . 6 6. CoMI Objects Function Set . . . . . . . . . . . . . . . . . . 7 6.1. CoMI object binding . . . . . . . . . . . . . . . . . . . 7 6.2. CoMI MIB Function Set . . . . . . . . . . . . . . . . . . 8 7. CoMI objects . . . . . . . . . . . . . . . . . . . . . . . . 9 8. security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. XML Schema for CoMI MIB . . . . . . . . . . . . . . 12 Appendix B. XML Schema for CoMI objects . . . . . . . . . . . . 14 B.1. Schema for MC groups . . . . . . . . . . . . . . . . . . 14 B.2. Schema for CoAP binding . . . . . . . . . . . . . . . . . 14 B.3. Valid Schemas . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction The Constrained RESTful Environments (CoRE) working group aims at Machine to Machine (M2M) applications such as smart energy and building control. Small M2M devices need to be managed in an automatic fashion to handle the large quantities of devices that are expected to be van der Stok Expires December 30, 2013 [Page 2] Internet-Draft CoMI June 2013 installed in future installations. The management protocol of choice for Internet is SNMP [RFC3410] as is testified by the large number of Management Information Base (MIB) [RFC3418] specifications currently published [STD0001]. More recently, he NETCONF protocol [RFC6241] was developed with an extended set of messages using XML [XML] as data format. The data syntax is specified with YANG [RFC6020] and a mapping from Yang to XML is specified. In [RFC6643] SMIv2 syntax is expressed in Yang. Contrary to SNMP and also CoAP, NETCONF assumes persistent connections for example provided by SSH. The NETCONF protocol provides operations to retrieve, configure, copy, and delete configuration data-stores. Configuring data-stores distinguishes NETCONF from SNMP which operates on standardized MIBs. The CoRE Management Interface (CoMI) is intended to work on standardized data-sets in a stateless client-server fashion and is thus closer to SNMP than to NETCONF. Standardized data sets 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 [RFC4944] [RFC6775] , RPL [RFC6650] , and CoAP [I-D.ietf-core-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 [I-D.ietf-core-coap] and DTLS [RFC6347]. 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 [XML] 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 [EXI] in the payload. 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 van der Stok Expires December 30, 2013 [Page 3] Internet-Draft CoMI June 2013 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 [I-D.ersue-constrained-mgmt]. This memo collects existing management functions from several sources to uniformize their access. 3. Terminology 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. 4. CoAP Interface In CoRE a group of links can constitute a Function Set. The format of the links is specified in [RFC6690]. 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: o MIB with path /mg/mib and a binary content format o 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 Section 7. 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 | | | | | | van der Stok Expires December 30, 2013 [Page 4] Internet-Draft CoMI June 2013 | CoMI | /mg/comi | core.mg.comi | application/exi | | objects | | | | | | | | | | 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. 5. MIB binary Function Set The MIB binary Function Set provides a CoAP interface to transport BER encoded SNMP PDUs. Section 5.1 and Section 5.2 explain the structure of SNMP PDUs and their transport with CoMI. 5.1. SNMP architecture The architecture of the Internet Standard management framework consists of: o A data definition language that is referred to as Structure of Management Information (SMI)[RFC2578]. o The Management Information Base (MIB) which contains the information to be managed and is defined for each specific function to be managed [RFC3418]. o A protocol definition referred to as Simple Network Management Protocol (SNMP) [RFC3416]. o Security and administration that provides SNMP message based security on the basis of the user-based security model [RFC3414]. 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: van der Stok Expires December 30, 2013 [Page 5] Internet-Draft CoMI June 2013 o Get Request, transmits a list of OBJECT-IDENTIFIERs to be paired with values. o GetNext Request, transmits a list of OBJECT-IDENTIFIERs to which lexicographic successors are returned for table traversal. o GetBulk Request, transmits a list of OBJECT-IDENTFIERs and the maximum number of expected paired values. o Response, returns an error or the (OBJECT-IDENTIFIER, value) pairs for the OBJECT-IDENTIFIERs specified in Get, GetNext, GetBulk, Set, or Inform Requests. o Set Request, transmits a list of (OBJECT-IDENTIFIERs, value) pairs to be set in the specified MIB object. o Trap, sends an unconfirmed message with a list of (OBJECT- IDENTIFIERs, value) pairs to a notification requesting end-point. o 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 Section 7. 5.2. CoMI binding The payload is structured as specified by the ASN-1 notation presented in [RFC3416]. 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: REQ: GET example.com/mg/mib/ (Content-Format: application/octet-stream) RES: 2.05 Content (Content-Format: application/octet-stream) van der Stok Expires December 30, 2013 [Page 6] Internet-Draft CoMI June 2013 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 [RFC2578]. 6. CoMI Objects Function Set 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. 6.1. CoMI object binding 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 [EXI-primer]. Retrieving the contents of attribute Priority1 by expressing the attribute in the path is possible with: van der Stok Expires December 30, 2013 [Page 7] Internet-Draft CoMI June 2013 REQ: GET example.com/mg/comi/Alarms/Priority1 (Content-Format: application/exi) RES: 2.05 Content (Content-Format: application/exi) SE(alarmCount)SE(Priority1) value EE EE 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: REQ: GET example.com/mg/comi/Alarms RES: 2.05 Content (Content-Format: application/exi) SE(alarmCount) SE(priority1) value EE SE(priority2) value EE EE 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 [RFC6690] 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. 6.2. CoMI MIB Function Set The Function Set allows the access to one MIB variable per CoAP message. The schema is shown in Appendix A. 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: REQ: GET example.com/mg/comi/mib/variable RES: 2.05 Content (Content-Format: application/exi) van der Stok Expires December 30, 2013 [Page 8] Internet-Draft CoMI June 2013 SE(MIB)SE(name) variable EE SE(value) value EE EE 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 [RFC6690] 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 Appendix A, according to the rules of [RFC3416]. For example when MIB "variable" does not exist: REQ: GET example.com/mg/comi/mib/variable RES: 5.01 Not Implemented (Content-Format: application/exi) SE(exception)noSuchObject EE The TRAP is sent with a non confirmable CoAP PUT message to a destination specified in Section 7. 7. CoMI objects 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 [I-D.ietf-core-interfaces] describes the binding of end-points to end-points on remote devices, and draft [I-D.ietf-core-groupcomm] 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: o Binding table as described in [I-D.ietf-core-interfaces], schema presented in Appendix B.2. o Multicast address enabling as described in [I-D.ietf-core-groupcomm], schema presented in Appendix B.1. o SNMP notification destinations as referred to in [RFC3416], schema presented in Appendix B.2. o Names of files containing the schemas to be expected, schema presented in Appendix B.3. van der Stok Expires December 30, 2013 [Page 9] Internet-Draft CoMI June 2013 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 [I-D.ietf-core-interfaces]. 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. 8. security Considerations TODO: follows CoAP security provisioning. 9. IANA Considerations TODO 10. Acknowledgements 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. van der Stok Expires December 30, 2013 [Page 10] Internet-Draft CoMI June 2013 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 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. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6643] Schoenwaelder, J., "Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules", RFC 6643, July 2012. [RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, June 2012. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012. [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-17 (work in progress), May 2013. van der Stok Expires December 30, 2013 [Page 11] Internet-Draft CoMI June 2013 [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-09 (work in progress), May 2013. [I-D.ietf-core-interfaces] Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- core-interfaces-00 (work in progress), June 2013. [I-D.ersue-constrained-mgmt] Ersue, M., Romascanu, D., and J. Schoenwaelder, "Management of Networks with Constrained Devices: Problem Statement, Use Cases and Requirements", draft-ersue- constrained-mgmt-03 (work in progress), February 2013. [STD0001] , "Official Internet Protocols Standard", Web http://www.rfc-editor.org/rfcxx00.html, . [EXI] , "Efficient XML Interchange", Web http://www.w3.org/xml/exi, . [XML] , "Extensible Markup Language (XML)", Web http://www.w3.org/xml, . [EXI-primer] 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 CoMI 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 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. van der Stok Expires December 30, 2013 [Page 12] Internet-Draft CoMI June 2013 Creation and deletion of columns and rows is not catered for. The access modes are not visible. van der Stok Expires December 30, 2013 [Page 13] Internet-Draft CoMI June 2013 Appendix B. XML Schema for CoMI objects 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 [I-D.ietf-core-interfaces] has been extended with "notify". B.1. Schema for MC groups MCentries are stored in MCGroups B.2. Schema for CoAP binding van der Stok Expires December 30, 2013 [Page 14] Internet-Draft CoMI June 2013 Binding table contains several simple Bindings, composed of timing parameters and Function signature. B.3. Valid Schemas van der Stok Expires December 30, 2013 [Page 15] Internet-Draft CoMI June 2013 File names are stored in Schema Author's Address Peter van der Stok consultant Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org van der Stok Expires December 30, 2013 [Page 16]