coman B. Greevenbosch Internet-Draft K. Li Intended status: Informational Huawei Technologies Expires: November 25, 2013 P. van der Stok vanderstok consultancy May 24, 2013 Candidate Technologies for COMAN draft-greevenbosch-coman-candidate-tech-02 Abstract This draft identifies candidate technologies and considerations for the COMAN use cases and requirements. Note Discussion and suggestions for improvement are requested, and should be sent to coman@ietf.org. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 25, 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 (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 Greevenbosch, et al. Expires November 25, 2013 [Page 1] Internet-Draft COMAN - Candidate Technologies May 2013 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. Identified candidate technologies for the requirements . . . 3 3.1. OMA-LwM2M . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. OMA Device Management . . . . . . . . . . . . . . . . . . 3 3.2.1. OMA-DM Management Objects . . . . . . . . . . . . . . 4 3.2.2. ACL mechanism in OMA-DM . . . . . . . . . . . . . . . 5 3.3. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. CoAP main specification . . . . . . . . . . . . . . . 6 3.3.2. CoAP capability discovery specifications . . . . . . 6 3.3.3. CoAP group communication . . . . . . . . . . . . . . 7 3.3.4. CoAP energy saving technology . . . . . . . . . . . . 7 3.3.5. Congestion avoidance in CoAP . . . . . . . . . . . . 7 3.4. Cryptography considerations . . . . . . . . . . . . . . . 8 3.5. MANET . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. BACnet . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Other requirements and candidate technologies . . . . . . 12 4. High level requirements that need to be observed continuously 13 5. Table of requirements and related technologies . . . . . . . 14 6. Conclusion and recommendations . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 In [I-D.ersue-constrained-mgmt], several use cases and associated requirements are defined for the management of constrained devices, in a possibly constrained network. Greevenbosch, et al. Expires November 25, 2013 [Page 2] Internet-Draft COMAN - Candidate Technologies May 2013 This document identifies possible technologies associated with the use cases and requirements. In addition, this document includes several considerations associated with the requirements, that are relevant for choosing proper technologies. The goal of this document is to identify what has been done, and what still needs to be done. Especially, it aims at establishing a clearer view of the scope and work in COMAN. 3. Identified candidate technologies for the requirements 3.1. OMA-LwM2M OMA Lightweight M2M [OMA-LwM2M-TS] aims at providing an underlying layer agnostic protocol to allow M2M service enablement and management between the LwM2M Server and the LwM2M Client, which is placed in the resource constrained devices. The first version of enabler is currently being specified. The enabler provides a light and compact protocol and a flat data structure, and can satisfy various management requirements for constrained devices. OMA-LwM2M has overlap with the following COMAN requirements: o 4.2.002 Compact encoding of management data o 4.4.001 Device status monitoring o 4.4.002 Energy status monitoring o 4.4.012 Logging o 4.6.001 Authentication on management system and devices o 4.6.002 Support suitable security bootstrapping mechanisms o 4.6.003 Access control on management system and devices Because of the overlap and early stage of OMA-LwM2M, good coordination between COMAN and OMA-LwM2M is advisable. 3.2. OMA Device Management OMA Device Management [OMA-DM] provides various functions for mobile device management. OMA-DM specifies and depends heavily on the SyncML language, which uses XML. The typical underlying transport protocol is HTTP. This makes OMA-DM in unaltered form infeasible for Greevenbosch, et al. Expires November 25, 2013 [Page 3] Internet-Draft COMAN - Candidate Technologies May 2013 constrained devices. Especially, it violates the following requirements: o 4.1.001 Support multiple device classes within a single network o 4.2.002 Compact encoding of management data Nevertheless, there is much overlap between OMA-DM functionality and COMAN requirements. As such, OMA-DM MAY be used as inspiration for the COMAN solution. OMA-DM defines a general data model for management purpose, which is called a Management Object (MO). MOs are stored on the device and can be manipulated by management actions carried over the OMA-DM protocol. For each management purpose, a specific MO has been defined. MOs relevant to the COMAN requirements include "FUMO" for firmware update requirements, "DiagMon MO" for diagnostic and monitoring requirements and the "Scheduling MO" for scheduling requirements. The various MOs are discussed in Section 3.2.1 and its subsections. Apart from requirements covered by MOs, the following COMAN requirements intersect with the general OMA-DM functionality: o 4.1.007 Network-wide configuration - Use broadcast capability from OMA-DM 1.3 - Sessionless specification. 3.2.1. OMA-DM Management Objects 3.2.1.1. OMA DiagMon MO OMA DiagMon MO builds on and leverages the OMA DM v1.x protocol. It provides standard DM Management Objects and associated client-side and server-side behaviour necessary to conduct diagnostics and monitoring activities on mobile devices. Requirements related to OMA DiagMon MO: o 4.4.003 Monitoring of current and estimated device availability: can be achieved by DiagMon functions MO. o 4.4.004 Network status monitoring: can be achieved by DiagMon functions MO. o 4.4.006 Performance monitoring: can be achieved by DiagMon functions MO. o 4.4.007 Fault detection monitoring: can be achieved by Trap MO. Greevenbosch, et al. Expires November 25, 2013 [Page 4] Internet-Draft COMAN - Candidate Technologies May 2013 o 4.4.011 Notifications: can be achieved by reporting functions in DiagMon MO. o 4.4.008 Passive and reactive monitoring: can be achieved by Trap MO. o 4.5.001 Self-management - Self-Healing: device events can be captured by Trap MO, also periodically, to achieve self- management. 3.2.1.2. OMA Scheduling MO The OMA-DM Scheduling MO enabler [OMA-Scheduling-MO] specifies the scheduling framework as well as its Management Objects that can be layered on top of OMA-DM v1.x, to seamlessly add the common scheduling capability to the OMA-DM based management infrastructure. With this capability, the OMA-DM system is able to schedule management operations on the device, and have them executed offline when the schedule - time-based or event-based - matches. Requirements related to OMA Scheduling MO: o 4.5.001 Self-management - Self-Healing: time-based scheduled task can achieve periodic self-management. 3.2.1.3. OMA-FUMO OMA-FUMO provides information on management objects associated with firmware updates in OMA-DM based mobile devices and the behaviour associated with the processing of the management objects. 3.2.2. ACL mechanism in OMA-DM OMA-DM [OMA-DM] defines the Access Control List (ACL) mechanism to control the access to the Management Objects. ACL is a property associated with the Management Object nodes, and is used to grant access permissions to the server identifiers. Related requirements: o 4.6.002 Support suitable security bootstrapping mechanisms o 4.6.003 Access control on management system and devices 3.3. CoAP The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is defined by the IETF. It provides an application layer protocol Greevenbosch, et al. Expires November 25, 2013 [Page 5] Internet-Draft COMAN - Candidate Technologies May 2013 especially designed for constrained devices. It is binary and easy to parse. CoAP is especially suitable on top of IPv6 and UDP. However, other lower level protocols are possible too. In addition, several drafts have been specified to target specific issues. 3.3.1. CoAP main specification The following requirements are met by the CoAP main specification: o 4.1.001 Support multiple device classes within a single network - the low complexity of CoAP allows usage in all device classes. o 4.1.004 Minimise state maintained on constrained devices - CoAP has been designed to keep servers stateless. o 4.1.006 Support for lossy links and unreliable devices - through the CoAP CON retransmission mechanism. o 4.2.004 Mapping of management protocol interactions - CoAP provides HTTP/Coap Mapping. o 4.2.007 Protocol extensibility - mainly provided by options mechanism. o 4.3.003 Asynchronous transaction support - CoAP supports separate response and piggy-backed response. o 4.4.007 Fault detection monitoring (partly) - CoAP pinging allows verification if a device is online. 3.3.2. CoAP capability discovery specifications Various CoAP drafts cover different aspects of capability discovery. o RFC 6690 [RFC6690] defines a link format, which provides information on resources a server is offering. o The draft [I-D.greevenbosch-core-profile-description] allows signalling a CoAP server profile. o The draft [I-D.shelby-core-resource-directory] allows acquiring information about resources from another server, called the "Resource Directory". Greevenbosch, et al. Expires November 25, 2013 [Page 6] Internet-Draft COMAN - Candidate Technologies May 2013 o The draft [I-D.lynn-core-discovery-mapping] provides a mapping between the resource directory and a DNS lookup. This allows usage of DNS lookup for the discovery of CoAP servers. o The informational draft [I-D.vanderstok-core-dna] discusses mapping between IP address and a Fully Qualified Domain Name (FQDN), proposing DNS for lookup of the IP address. In addition, it discusses possible naming conventions, group communication and resource discovery. Towards the latter, registration of new devices to the resource directory is discussed. Related COMAN requirement: o 4.3.002 Capability discovery 3.3.3. CoAP group communication The informational CoAP group communication draft [I-D.ietf-core-groupcomm] discusses various aspects of group communication through IP multicast [RFC4604] in CoAP. Another informational draft discussing group communication is [I-D.vanderstok-core-dna]. This draft gives detailed examples, and discusses multicast, naming and DNS mapping of groups. Related COMAN requirement: o 4.8.001 Group-based provisioning 3.3.4. CoAP energy saving technology The draft [I-D.rahman-core-sleepy] provides a mechanisms for sleepy devices. These mechanisms include informing an intermediate resource directory (defined in [I-D.shelby-core-resource-directory]) of its waking up or intent to fall asleep. Through these two drafts, clients can use the observe mechanism [I-D.ietf-core-observe] to be informed of whether a device is sleeping or active. Related COMAN requirements: o 4.1.006 Support for lossy links and unreachable devices o 4.7.002 Support of energy-optimized communication protocols 3.3.5. Congestion avoidance in CoAP The considerations in this section relate to: Greevenbosch, et al. Expires November 25, 2013 [Page 7] Internet-Draft COMAN - Candidate Technologies May 2013 o 4.9.001 Congestion avoidance o 4.9.003 Traffic delay schemes The draft [I-D.bormann-core-cocoa] provides general background information about CoAP congestion control, and its challenges. The draft [I-D.li-core-conditional-observe] defines a mechanism to signal minimum time between CoAP observations. The draft [I-D.greevenbosch-core-minimum-request-interval] defines a mechanism to restrict the speed in which a CoAP client sends requests to the CoAP server. Other ways to delay the traffic in CoAP is by sending delayed ACKs. However, this has limitations as too much delay will lead to retransmits from the client side. In addition, this method requires the server to maintain bookkeeping of the delayed ACKs. 3.4. Cryptography considerations 4.6.001 Authentication of management system and devices o The raw public key as defined in [I-D.ietf-tls-oob-pubkey] can be used for establishing security and authentication. o OCSP-lite as defined in [I-D.greevenbosch-tls-ocsp-lite] can be used for revocation checking of the raw public key. 4.6.002 Support suitable security bootstrapping mechanisms o The draft [I-D.jennings-core-transitive-trust-enrollment] describes a system in which a Device is introduced to a Controller by a Introducer. In this draft, it is suggested that the Device symmetric key is coded as a QR code on the box, which can be read by the Controller, which may be a mobile phone with internet access. 4.6.004 Select cryptographic algorithms that are efficient in both code space and execution time o Candidates for asymmetric cryptography: * RSA * ECC Keysize TBD. Greevenbosch, et al. Expires November 25, 2013 [Page 8] Internet-Draft COMAN - Candidate Technologies May 2013 o Candidates for symmetric cryptography: * AES (keysize 128/192/256) Keysize TBD. o Candidates for hashing: * SHA-1 * SHA-256 * SHA-512 4.6.008 Select cryptographic algorithms that are to be supported in hardware o TBD 3.5. MANET TBD. 3.6. BACnet BACnet exists under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE). BACnet is an American national standard, a European standard, a national standard in more than 30 countries, and an ISO global standard. The protocol is supported and maintained by ASHRAE Standing Standard Project Committee (SSPC) 135. BACnet is the most deployed communications standard for building control in the USA. It consists of a number of working groups. Their results are published in one BACnet specification document: International ISO standard 16484-5 [ISO16484-5]. It defines a network architecture on top of several PHYs (ARCnet, MS/TP, Ethernet, P2P, LONTalk) and IP. It specifies a number of object types from which a control system can be composed. Central is the device objects (unique per device) that maintains all organization information for a given devices. Object types are defined for scheduling, grouping, alarm handling, object and device management, and service discovery. The BACnet specification includes an extensive Alarm and Event service, and object access service for system configuration purposes, and remote device management services. The following requirements are met by the BACnet specification: Greevenbosch, et al. Expires November 25, 2013 [Page 9] Internet-Draft COMAN - Candidate Technologies May 2013 o 4.1.001 Support multiple device classes within a single network - the BACnet standard has an open source implementation that fits on the smallest devices and can also be deployed on larger devices o 4.1.002 Management scalability - the BACnet standard defines a hierarchical management structure where data are collected from all devices with support from information in the device object. Group objects can be defined which aggregate information from multiple objects within the same device. A working group, BACnet/ WS, is dedicated to defining the architecture for storing historical data of the control system in a central repository using the ATOM Publishing standard and exploiting the xml modeling facilities. o 4.1.003 Hierarchical management - hierarchical management is supported by the device and object structure, the independent structure in alarm management, and the group object which supports the grouping of commands. o 4.1.004 Minimize state maintained on constrained devices - state is minimized by selecting relevant objects in the control devices. o 4.1.008 Distributed Management - BACnet does provide the possibility to export management to multiple managers, however, no atomic write and read is specified, although there is a transaction concept at network level. o 4.2.001 Modular implementation of management protocols - BACnet encourages and prescribes a modular implementation by segmenting the management functions and distributing them over different objects. o 4.2.002 Compact encoding of management data - BACnet transports binary data encoded according to ASN.1, reduces storage space as much as feasible given the specified functionality. o 4.2.005 Consistency of data models with the underlying information model - BACnet has an information model based on the ATOM publishing protocol. The BACnet Annex N standard prescribes the mapping between the information model and the data model present in the nodes. o 4.2.007 Protocol extensibility - the BACnet model encourages extensibility, as proven by the constant backwards compatible standards updates. The standards extension process is slow and sets the extension pace. Greevenbosch, et al. Expires November 25, 2013 [Page 10] Internet-Draft COMAN - Candidate Technologies May 2013 o 4.3.001 Self-configuration capability - BACnet supports discovery of devices, their objects and properties via WHO-HAS, I-AM and similar messages. o 4.3.002 Capability Discovery - See 4.3.001. o 4.3.004 Network reconfiguration - BACnet knows the concept of BACnet routers. Routers declare themselves to network segments, and can be allocated started, stopped. No automatic procedures are described for full auto-configuration. o 4.4.001 Device status monitoring - BACnet provides extensive tools for network and device status monitoring, specified in the Alarm and Event services section. BACnet supports a very flexible event and alarm reporting. Clients can subscribe to generators of events and alarms, which can be changes of values in objects or status changes. Classes of events can be specified with appropriate handling by the clients. o 4.4.002 Energy status monitoring - This can be provided in BACnet by creating a binary value object type connected to the energy c.q. power attributes to monitor and specify a change of state with an appropriate client. o 4.4.003 Monitoring of current and estimated device availability - See text in 4.4.002. o 4.4.004 Network status monitoring - BACnet provides facilities to configure and install routers on the BACnet network. BACnet specifies the MS/TP and PTP link protocols with the possibility to monitor link status. o 4.4.006 Performance Monitoring - BACnet defines a set of application layer objects. Dependent on their function, performance measures are monitored and events or alarms are generated to be monitored by an alarm handling service. o 4.4.007 Fault detection monitoring - BACnet includes fault detection monitoring at network level. o 4.4.009 Recovery - BACnet provides functions for network recovery and object, device recovery without specifying how these functions must be used in case of given errors. o 4.4.010 Network topology discovery - this is a rather basic capability of a BACnet network. Greevenbosch, et al. Expires November 25, 2013 [Page 11] Internet-Draft COMAN - Candidate Technologies May 2013 o 4.4.011 Notifications - the BACnet alarm and event services are dedicated to this topic. o 4.4.012 Logging - BACnet annex N specifies how logged values can be stored in a server using the ATOM publishing protocol. o 4.6.001 Authentication of management system and devices - BACnet security service provides authentication of peers, operators and data source. o 4.10.002 Reliable unicast transport - BACnet provides a transaction service over the network. o 4.10.003 Best-effort multicast - BACnet goes to great pains to provide a broadcast facility which is essential for its configuration purposes. o 4.11.001 Avoid complex application layer transactions requiring large application messages - BACnet has a finite set of application message constructs in which application messages should fit. o 4.11.002 Avoid reassembly of messages at multiple layers in the protocol stack - BACnet avoids reassembly by contruction. 3.7. Other requirements and candidate technologies 4.1.005 Automatic re-synchronisation with eventual consistency 4.1.006 Support for lossy links and unreachable devices o Mechanisms for devices that are not sleepy, but have unstable network connections (e.g. mobile devices) are needed. 4.1.008 Distributed management 4.2.006 Loss-less mapping of management data models 4.3.002 Capability discovery 4.3.004 Network reconfiguration 4.4.009 Recovery 4.4.010 Network topology discovery 4.7.001 Management of energy resources Greevenbosch, et al. Expires November 25, 2013 [Page 12] Internet-Draft COMAN - Candidate Technologies May 2013 4.7.002 Support of energy-optimized communication protocols o 6LoWPAN [RFC4944] provides IPv6 functionality for IEEE 802.15.4 networks. 4.7.003 Support for layer 2 energy-aware protocols o IEEE 802.15.4 [IEEE-802.15.4] provides wireless low power communication on short distance. 4.7.004 Dying gasp 4.9.002 Redirect traffic 4.10.001 Scalable transport layer 4.10.002 Reliable unicast transport 4.10.004 Secure message transport 4.11.001 Avoid complex application layer transactions requiring large application layer messages 4.11.002 Avoid reassembly of messages at multiple layers in the protocol stack 4. High level requirements that need to be observed continuously 4.1.001 Support multiple device classes within a single network 4.1.002 Management scalability 4.1.004 Minimise state maintained on constrained devices 4.1.006 Support for lossy links and unreachable devices 4.2.002 Compact encoding of management data o A binary format would be most compact. o TLV could be considered. o XML would be counter productive. o JSON may be counter productive. 4.2.003 Compression of management data or complete messages Greevenbosch, et al. Expires November 25, 2013 [Page 13] Internet-Draft COMAN - Candidate Technologies May 2013 o When the messages are designed compact enough, compression will be unnecessary. 4.2.007 Protocol extensibility 5. Table of requirements and related technologies The Table 1 summarises the requirements and related or possible candidate technologies. +-----------+----------------+--------------------------------------+ | Requireme | Name | Associated technology | | nt number | | | +-----------+----------------+--------------------------------------+ | 4.1.001 | Support | [I-D.ietf-core-coap], [ISO16484-5] | | | multiple | | | | device classes | | | | within a | | | | single network | | | | | | | 4.1.002 | Management | [ISO16484-5] | | | scalability | | | | | | | 4.1.003 | Hierarchical | [ISO16484-5] | | | management | | | | | | | 4.1.004 | Minimise state | [I-D.ietf-core-coap], [ISO16484-5] | | | maintained on | | | | constrained | | | | devices | | | | | | | 4.1.005 | Automatic re-s | | | | ynchronisation | | | | with eventual | | | | consistency | | | | | | | 4.1.006 | Support for | [I-D.ietf-core-coap] [I-D.rahman- | | | lossy links | core-sleepy], [I-D.shelby-core- | | | and | resource-directory], [I-D.ietf-core- | | | unreachable | observe] | | | devices | | | | | | | 4.1.007 | Network-wide | [OMA-DM], [ISO16484-5] | | | configuration | | | | | | | 4.1.008 | Distributed | [ISO16484-5] | | | management | | | | | | Greevenbosch, et al. Expires November 25, 2013 [Page 14] Internet-Draft COMAN - Candidate Technologies May 2013 | 4.2.001 | Modular | [ISO16484-5] | | | implementation | | | | of management | | | | protocols | | | | | | | 4.2.002 | Compact | [OMA-LwM2M-TS], [ISO16484-5] | | | encoding of | | | | management | | | | data | | | | | | | 4.2.003 | Compression of | | | | management | | | | data or | | | | complete | | | | messages | | | | | | | 4.2.004 | Mapping of | [I-D.ietf-core-coap] | | | management | | | | protocol | | | | interactions | | | | | | | 4.2.005 | Consistency of | [ISO16484-5] | | | data models | | | | with the | | | | underlying | | | | information | | | | model | | | | | | | 4.2.006 | Loss-less | | | | mapping of | | | | management | | | | data models | | | | | | | 4.2.007 | Protocol | [I-D.ietf-core-coap], [ISO16484-5] | | | extensibility | | | | | | | 4.3.001 | Self- | [ISO16484-5] | | | configuration | | | | capability | | | | | | | 4.3.002 | Capability | [RFC6690], [I-D.greevenbosch-core- | | | discovery | profile-description], [I-D.shelby- | | | | core-resource-directory], [I-D.lynn- | | | | core-discovery-mapping], [I-D | | | | .vanderstok-core-dna], [ISO16484-5] | | | | | | 4.3.003 | Asynchronous | [I-D.ietf-core-coap] | | | transaction | | Greevenbosch, et al. Expires November 25, 2013 [Page 15] Internet-Draft COMAN - Candidate Technologies May 2013 | | support | | | | | | | 4.3.004 | Network reconf | [ISO16484-5] | | | iguration | | | | | | | 4.4.001 | Device status | [OMA-LwM2M-TS], [ISO16484-5] | | | monitoring | | | | | | | 4.4.002 | Energy status | [OMA-LwM2M-TS], [ISO16484-5] | | | monitoring | | | | | | | 4.4.003 | Monitoring of | [OMA-DiagMon-MO], [ISO16484-5] | | | current and | | | | estimated | | | | device | | | | availability | | | | | | | 4.4.004 | Network status | [OMA-DiagMon-MO], [ISO16484-5] | | | monitoring | | | | | | | 4.4.005 | Self- | [OMA-DiagMon-MO], [ISO16484-5] | | | monitoring | | | | | | | 4.4.006 | Performance | [OMA-DiagMon-MO], [ISO16484-5] | | | monitoring | | | | | | | 4.4.007 | Fault | [I-D.ietf-core-coap], [OMA-DiagMon- | | | detection | MO], [ISO16484-5] | | | monitoring | | | | | | | 4.4.008 | Passive and | [OMA-DiagMon-MO] | | | reactive | | | | monitoring | | | | | | | 4.4.009 | Recovery | [ISO16484-5] | | | | | | 4.4.010 | Network | [ISO16484-5] | | | topology | | | | discovery | | | | | | | 4.4.011 | Notifications | [OMA-DiagMon-MO], [ISO16484-5] | | | | | | 4.4.012 | Logging | [OMA-LwM2M-TS], [ISO16484-5] | | | | | | 4.5.001 | Self- | [OMA-DiagMon-MO], [OMA-Scheduling- | | | management - | MO] | | | Self-healing | | | | | | Greevenbosch, et al. Expires November 25, 2013 [Page 16] Internet-Draft COMAN - Candidate Technologies May 2013 | 4.6.001 | Authentication | [OMA-LwM2M-TS], [I-D.ietf-tls-oob- | | | of management | pubkey], [I-D.greevenbosch-tls-ocsp- | | | system and | lite], [ISO16484-5] | | | devices | | | | | | | 4.6.002 | Support | [OMA-LwM2M-TS], [OMA-DM], [I-D | | | suitable | .jennings-core-transitive-trust- | | | security | enrollment] | | | bootstrapping | | | | mechanisms | | | | | | | 4.6.003 | Access control | [OMA-LwM2M-TS], [OMA-DM] | | | on management | | | | system and | | | | devices | | | | | | | 4.6.004 | Select | | | | cryptographic | | | | algorithms | | | | that are | | | | efficient in | | | | both code | | | | space and | | | | execution time | | | | | | | 4.7.001 | Management of | [IEEE-802.15.4], [I-D.rahman-core- | | | energy | sleepy], | | | resources | | | | | | | 4.7.002 | Support of | [I-D.ietf-core-coap], [RFC4944], | | | energy- | [I-D.rahman-core-sleepy], [I-D.ietf- | | | optimized | core-observe], [I-D.shelby-core- | | | communication | resource-directory] | | | protocols | | | | | | | 4.7.003 | Support for | [IEEE-802.15.4] | | | layer 2 | | | | energy-aware | | | | protocols | | | | | | | 4.7.004 | Dying gasp | | | | | | | 4.8.001 | Group-based | [I-D.ietf-core-groupcomm], [I-D | | | provisioning | .vanderstok-core-dna], [RFC4604] | | | | | | 4.9.001 | Congestion | [I-D.ietf-core-coap], [I-D.li-core- | | | avoidance | conditional-observe], [I-D.bormann- | | | | core-cocoa], [I-D.greevenbosch-core- | Greevenbosch, et al. Expires November 25, 2013 [Page 17] Internet-Draft COMAN - Candidate Technologies May 2013 | | | minimum-request-interval] | | | | | | 4.9.002 | Redirect | | | | traffic | | | | | | | 4.9.003 | Traffic delay | [I-D.ietf-core-coap], [I-D.li-core- | | | schemes | conditional-observe], [I-D.bormann- | | | | core-cocoa], [I-D.greevenbosch-core- | | | | minimum-request-interval] | | | | | | 4.10.001 | Scalable | | | | transport | | | | layer | | | | | | | 4.10.002 | Reliable | | | | unicast | | | | transport | | | | | | | 4.10.003 | Best-effort | [ISO16484-5] | | | multicast | | | | | | | 4.10.004 | Secure message | | | | transport | | | | | | | 4.11.001 | Avoid complex | | | | application | | | | layer | | | | transactions | | | | requiring | | | | large | | | | application | | | | layer messages | | | | | | | 4.11.002 | Avoid | [ISO16484-5] | | | reassembly of | | | | messages at | | | | multiple | | | | layers in the | | | | protocol stack | | +-----------+----------------+--------------------------------------+ Table 1: Requirements and technologies Greevenbosch, et al. Expires November 25, 2013 [Page 18] Internet-Draft COMAN - Candidate Technologies May 2013 6. Conclusion and recommendations In this document, we have identified technology standards that currently cover many of the COMAN use cases. COMAN should consider referencing these technologies when appropriate. In addition, this document points at technologies that are not deployed in a standard, and hence need new standardisation. We recommend to write a document in COMAN that describes the overall envisaged management system and suggests standardisation topics for IETF. 7. Security Considerations TBD 8. IANA considerations TBD 9. Change Log v00 -> v01: o Added text about BACnet. v01 -> v02: o Updated text about BACnet. o Updated to match new requirements numbering in I-D.ersue- constrained-mgmt v04. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Greevenbosch, et al. Expires November 25, 2013 [Page 19] Internet-Draft COMAN - Candidate Technologies May 2013 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-16 (work in progress), May 2013. [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-07 (work in progress), May 2013. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf- core-observe-08 (work in progress), February 2013. [I-D.ietf-tls-oob-pubkey] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and T. Kivinen, "Out-of-Band Public Key Validation for Transport Layer Security (TLS)", draft-ietf-tls-oob- pubkey-07 (work in progress), February 2013. [I-D.bormann-core-cocoa] Bormann, C., "CoAP Simple Congestion Control/Advanced", draft-bormann-core-cocoa-00 (work in progress), August 2012. [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. [I-D.greevenbosch-core-minimum-request-interval] Greevenbosch, B., "CoAP Minimum Request Interval", draft- greevenbosch-core-minimum-request-interval-01 (work in progress), April 2013. [I-D.greevenbosch-core-profile-description] Greevenbosch, B., Hoebeke, J., and I. Ishaq, "CoAP Profile Description Format", draft-greevenbosch-core-profile- description-01 (work in progress), October 2012. [I-D.greevenbosch-tls-ocsp-lite] Greevenbosch, et al. Expires November 25, 2013 [Page 20] Internet-Draft COMAN - Candidate Technologies May 2013 Greevenbosch, B., "OCSP-lite - Revocation of raw public keys", draft-greevenbosch-tls-ocsp-lite-00 (work in progress), December 2012. [I-D.jennings-core-transitive-trust-enrollment] Jennings, C., "Transitive Trust Enrollment for Constrained Devices", draft-jennings-core-transitive-trust- enrollment-01 (work in progress), October 2012. [I-D.li-core-conditional-observe] Li, S., Hoebeke, J., and A. Jara, "Conditional observe in CoAP", draft-li-core-conditional-observe-03 (work in progress), October 2012. [I-D.lynn-core-discovery-mapping] Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based Service Discovery Mapping", draft-lynn-core-discovery- mapping-02 (work in progress), October 2012. [I-D.rahman-core-sleepy] Rahman, A., "Enhanced Sleepy Node Support for CoAP", draft-rahman-core-sleepy-02 (work in progress), February 2013. [I-D.shelby-core-resource-directory] Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource Directory", draft-shelby-core-resource-directory-05 (work in progress), February 2013. [I-D.vanderstok-core-dna] Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, Naming, and Addressing", draft-vanderstok-core-dna-02 (work in progress), July 2012. [IEEE-802.15.4] IEEE Computer Society, , "IEEE std. 802.15.4-2003", October 2003. [ISO16484-5] , "Building automation and control systems -- Part 5: Data communication protocol", ISO 16484-5, 2012. [OMA-DM] , "OMA Device Management 1.3", OMA-ERP-DM-V1_3-20121213-C , December 2012. [OMA-DiagMon-MO] , "OMA Diagnostics and Monitoring Management Object", OMA- ERP-DiagMon-V1_0-20120313-A , March 2012. Greevenbosch, et al. Expires November 25, 2013 [Page 21] Internet-Draft COMAN - Candidate Technologies May 2013 [OMA-FUMO] , "Firmware Update Management Object", OMA-TS-DM-FUMO- V1_0-20070209-A , February 2007. [OMA-Scheduling-MO] , "OMA DM Scheduling Management Object", OMA-ERP- DM_Scheduling-V1_0-20110614-C , June 2011. [OMA-LwM2M-TS] , "OMA Lightweight M2M", OMA-TS-LightweightM2M- V1_0-20130123-D (work in progress), January 2013. Authors' Addresses Bert Greevenbosch Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28979133 Email: bert.greevenbosch@huawei.com Kepeng Li Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28971807 Email: likepeng@huawei.com Peter van der Stok vanderstok consultancy Phone: +31-492474673 (Netherlands), +33-966015248 (France) Email: consultancy@vanderstok.org URI: www.vanderstok.org Greevenbosch, et al. Expires November 25, 2013 [Page 22]