Skip to main content

Candidate Technologies for COMAN
draft-greevenbosch-coman-candidate-tech-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Bert Greevenbosch , Kepeng Li
Last updated 2013-02-25
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-greevenbosch-coman-candidate-tech-01
coman                                                    B. Greevenbosch
Internet-Draft                                                     K. Li
Intended status: Informational                       Huawei Technologies
Expires: August 29, 2013                               February 25, 2013

                    Candidate Technologies for COMAN
               draft-greevenbosch-coman-candidate-tech-01

Abstract

   This draft identifies candidate technologies and considerations for
   the COMAN use cases and requirements.

Greevenbosch & Li        Expires August 29, 2013                [Page 1]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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 August 29, 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
   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.

Greevenbosch & Li        Expires August 29, 2013                [Page 2]
Internet-Draft       COMAN - Candidate Technologies        February 2013

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Identified candidate technologies for the requirements . . . .  6
     3.1.  OMA-LwM2M  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  OMA Device Management  . . . . . . . . . . . . . . . . . .  6
       3.2.1.  OMA-DM Management Objects  . . . . . . . . . . . . . .  7
       3.2.2.  ACL mechanism in OMA-DM  . . . . . . . . . . . . . . .  8
     3.3.  CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1.  CoAP main specification  . . . . . . . . . . . . . . .  9
       3.3.2.  CoAP capability discovery specifications . . . . . . .  9
       3.3.3.  CoAP group communication . . . . . . . . . . . . . . . 10
       3.3.4.  CoAP energy saving technology  . . . . . . . . . . . . 10
       3.3.5.  Congestion avoidance in CoAP . . . . . . . . . . . . . 11
     3.4.  Cryptography considerations  . . . . . . . . . . . . . . . 11
     3.5.  MANET  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  BACnet . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.7.  Other requirements and candidate technologies  . . . . . . 15
   4.  High level requirements that need to be observed
       continuously . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Table of requirements and related technologies . . . . . . . . 18
   6.  Conclusion and recommendations . . . . . . . . . . . . . . . . 24
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 26
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     10.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

Greevenbosch & Li        Expires August 29, 2013                [Page 3]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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].

Greevenbosch & Li        Expires August 29, 2013                [Page 4]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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.

   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.

Greevenbosch & Li        Expires August 29, 2013                [Page 5]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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.010 Logging

   o  4.6.001 Security and access control

   o  4.6.002 Authentication of managed devices

   o  4.6.003 Access control on managed constrained devices

   o  4.6.004 Access control on management systems

   o  4.6.005 Support suitable security bootstrapping mechanisms

   o  4.8.001 Software distribution (firmware update)

   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
   constrained devices.  Especially, it violates the following
   requirements:

   o  4.1.001 Support multiple device classes within a single network

Greevenbosch & Li        Expires August 29, 2013                [Page 6]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   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.008 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.009 Notifications: can be achieved by reporting functions in
      DiagMon MO.

   o  4.4.011 Performance monitoring: can be achieved by DiagMon
      functions MO.

   o  4.4.012 Fault detection monitoring: can be achieved by Trap MO.

Greevenbosch & Li        Expires August 29, 2013                [Page 7]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   o  4.4.013 Passive monitoring: can be achieved by Trap MO.

   o  4.4.014 Reactive monitoring: can be achieved by Trap MO.

   o  4.5.001 Self-management: device events can be captured by Trap MO,
      to achieve self-management.

   o  4.5.002 Periodic self-management: device events can be captured by
      Trap MO 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.002 Periodic self-management: 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.

   Requirements related to OMA-FUMO:

   o  4.8.001 Software distribution: firmware update can be achieved by
      FUMO.

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.003 Access control on managed constrained devices

Greevenbosch & Li        Expires August 29, 2013                [Page 8]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   o  4.6.004 Access control on management systems

   o  4.6.005 Support suitable security bootstrapping mechanisms

3.3.  CoAP

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is
   defined by the IETF.  It provides an application layer protocol
   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.007 Support for lossy and unreliable links - 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.004 Asynchronous transaction support - CoAP supports separate
      response and piggy-backed response.

   o  4.4.012 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.

Greevenbosch & Li        Expires August 29, 2013                [Page 9]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   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".

   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.003 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.002 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:

Greevenbosch & Li        Expires August 29, 2013               [Page 10]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   o  4.1.005 Support devices that are not always online

   o  4.7.005 Support of energy-optimized communication protocols

3.3.5.  Congestion avoidance in CoAP

   The considerations in this section relate to:

   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 challanges.

   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 Security and access control

   4.6.002 Authentication of managed 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.005 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.

Greevenbosch & Li        Expires August 29, 2013               [Page 11]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   4.6.006 Enable the authentication of a large number of devices at
   system start

   o  TBD

   4.6.007 Select cryptographic algorithms that are efficient in both
   code space and execution time

   o  Candidates for asymmetric cryptography:

      *  RSA

      *  ECC

      Keysize TBD.

   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.

   Reference [RFC6130] for Neighbour Discovery, if it is sufficiently
   related to Neighbour Monitoring (4.4.007).

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

Greevenbosch & Li        Expires August 29, 2013               [Page 12]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   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:

   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.  A
      working group is dedicated to defining the architecture for
      storing historical data of the control system in a central
      repository using the ATOM standard.

   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 a selection of 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

Greevenbosch & Li        Expires August 29, 2013               [Page 13]
Internet-Draft       COMAN - Candidate Technologies        February 2013

      much as feasible given the specified functionality.

   o  4.2.003 Compression of management data or complete messages -
      BACnet encodes messages according to ASN.1 standard.

   o  4.2.005 Consistency of data models with the underlying information
      model - BACnet has an ATOM based information model and 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.

   o  4.3.001 Self-configuration capability - BACnet supports discovery
      of devices, their objects and properties.

   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.

   o  4.4.004 Network status monitoring - see 4.4.001.

   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.

   o  4.4.011 Notifications - the BACnet alarm and event services are
      dedicated to this topic.

Greevenbosch & Li        Expires August 29, 2013               [Page 14]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   o  4.6.001 Authentication of management system and devices - BACnet
      security service provides authentication of peers, operators and
      data source.

   o  4.10.003 Best-effort multicast - BACnet goes to great pains to
      provide a broadcast facility which is essential for its
      configuration purposes.

3.7.  Other requirements and candidate technologies

   4.1.005 Support devices that are not always online

   o  Mechanisms for devices that are not sleepy, but have unstable
      network connections (e.g. mobile devices) are needed.

   4.1.006 Automatic re-synchronisation with eventual consistency

   4.1.009 Distributed management

   4.2.006 Loss-less mapping of management data models

   4.3.003 Capability discovery

   4.3.005 Network reconfiguration

   4.3.006 Automatic reconfiguration of hierarchical networks

   4.4.005 Network topology discovery

   4.4.008 Recovery

   4.7.001 Management of energy resources

   4.7.002 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.003 Data models for energy management

   4.7.004 Dying gasp

   4.7.005 Support of energy-optimized communication protocols

   o  6LoWPAN [RFC4944] provides IPv6 functionality for IEEE 802.15.4
      networks.

   4.9.002 Redirect traffic

Greevenbosch & Li        Expires August 29, 2013               [Page 15]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   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

Greevenbosch & Li        Expires August 29, 2013               [Page 16]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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.007 Support for lossy and unreliable links

   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

   o  When the messages are designed compact enough, compression will be
      unnecessary.

   4.2.007 Protocol extensibility

Greevenbosch & Li        Expires August 29, 2013               [Page 17]
Internet-Draft       COMAN - Candidate Technologies        February 2013

5.  Table of requirements and related technologies

   The Table 1 summarises the requirements and related or possible
   candidate technologies.

   +----------+-----------------+--------------------------------------+
   | Requirem | Name            | Associated technology                |
   | ent      |                 |                                      |
   |  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  | Support devices | [I-D.rahman-core-sleepy],            |
   |          | that are not    | [I-D.shelby-core-resource-directory] |
   |          | always online   | ,[I-D.ietf-core-observe]             |
   |          |                 |                                      |
   | 4.1.006  | Automatic       |                                      |
   |          | re-synchronisat |                                      |
   |          | ion with        |                                      |
   |          |  eventual       |                                      |
   |          |  consistency    |                                      |
   |          |                 |                                      |
   | 4.1.007  | Support for     | [I-D.ietf-core-coap]                 |
   |          | lossy and       |                                      |
   |          | unreliable      |                                      |
   |          | links           |                                      |
   |          |                 |                                      |
   | 4.1.008  | Network-wide    | [OMA-DM], [ISO16484-5]               |
   |          | configuration   |                                      |
   |          |                 |                                      |
   | 4.1.009  | Distributed     |                                      |
   |          | management      |                                      |
   |          |                 |                                      |

Greevenbosch & Li        Expires August 29, 2013               [Page 18]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   | 4.2.001  | Enabling        | [ISO16484-5]                         |
   |          | modular         |                                      |
   |          | implementations |                                      |
   |          | of management   |                                      |
   |          | protocols with  |                                      |
   |          | a basic set of  |                                      |
   |          | protocol        |                                      |
   |          | primitives      |                                      |
   |          |                 |                                      |
   | 4.2.002  | Compact         | [OMA-LwM2M-TS], [ISO16484-5]         |
   |          | encoding of     |                                      |
   |          | management data |                                      |
   |          |                 |                                      |
   | 4.2.003  | Compression of  | [ISO16484-5]                         |
   |          | 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-configurat | [ISO16484-5]                         |
   |          | ion capability  |                                      |
   |          |                 |                                      |
   | 4.3.002  | Enable peer     |                                      |
   |          | configuration   |                                      |
   |          |                 |                                      |

Greevenbosch & Li        Expires August 29, 2013               [Page 19]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   | 4.3.003  | Capability      | [RFC6690],                           |
   |          | discovery       | [I-D.greevenbosch-core-profile-descr |
   |          |                 | iption],                             |
   |          |                 |  [I-D.shelby-core-resource-directory |
   |          |                 | ],[I-D.lynn-core-discovery-mapping], |
   |          |                 |   [I-D.vanderstok-core-dna]          |
   |          |                 |                                      |
   | 4.3.004  | Asynchronous    | [I-D.ietf-core-coap], [ISO16484-5]   |
   |          | transaction     |                                      |
   |          | support         |                                      |
   |          |                 |                                      |
   | 4.3.005  | Network         |                                      |
   |          | reconfiguration |                                      |
   |          |                 |                                      |
   | 4.3.006  | Automatic       |                                      |
   |          | reconfiguration |                                      |
   |          | of hierarchical |                                      |
   |          | networks        |                                      |
   |          |                 |                                      |
   | 4.4.001  | Device status   | [OMA-LwM2M-TS], [ISO16484-5]         |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.4.002  | Energy status   | [OMA-LwM2M-TS]                       |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.4.003  | Monitoring of   | [OMA-DiagMon-MO]                     |
   |          | current and     |                                      |
   |          | estimated       |                                      |
   |          | device          |                                      |
   |          | availability    |                                      |
   |          |                 |                                      |
   | 4.4.004  | Network status  | [OMA-DiagMon-MO], [ISO16484-5]       |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.4.005  | Network         |                                      |
   |          | topology        |                                      |
   |          | discovery       |                                      |
   |          |                 |                                      |
   | 4.4.006  | Self-monitoring | [OMA-DiagMon-MO], [ISO16484-5]       |
   |          |                 |                                      |
   | 4.4.007  | Neighbour-monit | [RFC6130]?, [ISO16484-5]             |
   |          | oring           |                                      |
   |          |                 |                                      |
   | 4.4.008  | Recovery        |                                      |
   |          |                 |                                      |
   | 4.4.009  | Notifications   | [OMA-DiagMon-MO], [ISO16484-5]       |
   |          |                 |                                      |
   | 4.4.010  | Logging         | [OMA-LwM2M-TS], [ISO16484-5]         |

Greevenbosch & Li        Expires August 29, 2013               [Page 20]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   | 4.4.011  | Performance     | [OMA-DiagMon-MO], [ISO16484-5]       |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.4.012  | Fault detection | [I-D.ietf-core-coap],                |
   |          | monitoring      | [OMA-DiagMon-MO]                     |
   |          |                 |                                      |
   | 4.4.013  | Passive         | [OMA-DiagMon-MO]                     |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.4.014  | Reactive        | [OMA-DiagMon-MO]                     |
   |          | monitoring      |                                      |
   |          |                 |                                      |
   | 4.5.001  | Self-management | [OMA-DiagMon-MO]                     |
   |          |                 |                                      |
   | 4.5.002  | Perodic         | [OMA-DiagMon-MO],                    |
   |          | self-management | [OMA-Scheduling-MO]                  |
   |          |                 |                                      |
   | 4.6.001  | Security and    | [OMA-LwM2M-TS],                      |
   |          | access control  | [I-D.ietf-tls-oob-pubkey],           |
   |          |                 | [I-D.greevenbosch-tls-ocsp-lite],    |
   |          |                 | [ISO16484-5]                         |
   |          |                 |                                      |
   | 4.6.002  | Authentication  | [OMA-LwM2M-TS],                      |
   |          | of managed      | [I-D.ietf-tls-oob-pubkey],           |
   |          | devices         | [I-D.greevenbosch-tls-ocsp-lite]     |
   |          |                 |                                      |
   | 4.6.003  | Access control  | [OMA-LwM2M-TS], [OMA-DM]             |
   |          | on managed      |                                      |
   |          | constrained     |                                      |
   |          | devices         |                                      |
   |          |                 |                                      |
   | 4.6.004  | Access control  | [OMA-LwM2M-TS], [OMA-DM]             |
   |          | on management   |                                      |
   |          | systems         |                                      |
   |          |                 |                                      |
   | 4.6.005  | Support         | [OMA-LwM2M-TS], [OMA-DM],            |
   |          | suitable        | [I-D.jennings-core-transitive-trust- |
   |          | security        | enrollment]                          |
   |          | bootstrapping   |                                      |
   |          | mechanisms      |                                      |
   |          |                 |                                      |
   | 4.6.006  | Enable the      |                                      |
   |          | authentication  |                                      |
   |          | of a large      |                                      |
   |          | number of       |                                      |
   |          | devices at      |                                      |
   |          | system start    |                                      |
   |          |                 |                                      |

Greevenbosch & Li        Expires August 29, 2013               [Page 21]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   | 4.6.007  | Select          |                                      |
   |          | cryptographic   |                                      |
   |          | algorithms that |                                      |
   |          | are efficient   |                                      |
   |          | in both code    |                                      |
   |          | space and       |                                      |
   |          | execution time  |                                      |
   |          |                 |                                      |
   | 4.6.008  | Select          |                                      |
   |          | cryptographic   |                                      |
   |          | algorithms that |                                      |
   |          | are to be       |                                      |
   |          | supported in    |                                      |
   |          | hardware        |                                      |
   |          |                 |                                      |
   | 4.7.001  | Management of   | [IEEE-802.15.4],                     |
   |          | energy          | [I-D.rahman-core-sleepy],            |
   |          | resources       |                                      |
   |          |                 |                                      |
   | 4.7.002  | Support for     | [IEEE-802.15.4]                      |
   |          | layer 2         |                                      |
   |          | energy-aware    |                                      |
   |          | protocols       |                                      |
   |          |                 |                                      |
   | 4.7.003  | Data models for |                                      |
   |          | energy          |                                      |
   |          | management      |                                      |
   |          |                 |                                      |
   | 4.7.004  | Dying gasp      |                                      |
   |          |                 |                                      |
   | 4.7.005  | Support of      | [I-D.ietf-core-coap], [RFC4944],     |
   |          | energy-optimize | [I-D.rahman-core-sleepy],            |
   |          | dcommunication  | [I-D.ietf-core-observe],             |
   |          |  protocols      | [I-D.shelby-core-resource-directory] |
   |          |                 |                                      |
   | 4.8.001  | Software        | [OMA-LwM2M-TS], [OMA-FUMO]           |
   |          | distribution    |                                      |
   |          |                 |                                      |
   | 4.8.002  | Group-based     | [I-D.ietf-core-groupcomm],           |
   |          | provisioning    | [I-D.vanderstok-core-dna], [RFC4604] |
   |          |                 |                                      |
   | 4.9.001  | Congestion      | [I-D.ietf-core-coap],                |
   |          | avoidance       | [I-D.li-core-conditional-observe],   |
   |          |                 | [I-D.bormann-core-cocoa],            |
   |          |                 | [I-D.greevenbosch-core-minimum-reque |
   |          |                 | st-interval]                         |
   |          |                 |                                      |

Greevenbosch & Li        Expires August 29, 2013               [Page 22]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   | 4.9.002  | Redirect        |                                      |
   |          | traffic         |                                      |
   |          |                 |                                      |
   | 4.9.003  | Traffic delay   | [I-D.ietf-core-coap],                |
   |          | schemes         | [I-D.li-core-conditional-observe],   |
   |          |                 | [I-D.bormann-core-cocoa],            |
   |          |                 | [I-D.greevenbosch-core-minimum-reque |
   |          |                 | st-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           |                                      |
   |          | reassembly of   |                                      |
   |          | messages at     |                                      |
   |          | multiple layers |                                      |
   |          | in the protocol |                                      |
   |          | stack           |                                      |
   +----------+-----------------+--------------------------------------+

                  Table 1: Requirements and technologies

Greevenbosch & Li        Expires August 29, 2013               [Page 23]
Internet-Draft       COMAN - Candidate Technologies        February 2013

6.  Conclusion and recommendations

   In this document, we have identified possible technologies that can
   be used to realise the COMAN use cases.  COMAN should consider
   referencing these technologies when appropriate.  In addition, this
   document points at technologies that are missing, and hence need
   standardisation.  We recommend to do this standardisation in COMAN,
   and in addition write a document in COMAN that describes the overall
   system.

Greevenbosch & Li        Expires August 29, 2013               [Page 24]
Internet-Draft       COMAN - Candidate Technologies        February 2013

7.  Security Considerations

   TBD

Greevenbosch & Li        Expires August 29, 2013               [Page 25]
Internet-Draft       COMAN - Candidate Technologies        February 2013

8.  IANA considerations

   TBD

Greevenbosch & Li        Expires August 29, 2013               [Page 26]
Internet-Draft       COMAN - Candidate Technologies        February 2013

9.  Acknowledgements

   Thanks to Peter van der Stok for providing the text about BACnet, and
   mentioning several other related drafts.

Greevenbosch & Li        Expires August 29, 2013               [Page 27]
Internet-Draft       COMAN - Candidate Technologies        February 2013

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.

   [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., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), March 2012.

   [I-D.ietf-core-groupcomm]
              Rahman, A. and E. Dijk, "Group Communication for CoAP",
              draft-ietf-core-groupcomm-04 (work in progress,
              December 2012.

   [I-D.ietf-core-observe]
              Hartke, K., "Observing Resources in CoAP",
              draft-ietf-core-observe-07 (work in progress,
              October 2012.

   [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-06 (work in progress),
              October 2012.

   [I-D.bormann-core-cocoa]

Greevenbosch & Li        Expires August 29, 2013               [Page 28]
Internet-Draft       COMAN - Candidate Technologies        February 2013

              Bormann, C., "CoAP Simple Congestion Control/Advanced",
              draft-bormann-core-cocoa-00 (work in progress),
              Augustus 2012.

   [I-D.ersue-constrained-mgmt]
              Ersue, M., Romascanu, D., and J. Schoenwaelder,
              "Management of Networks with Constrained Devices: Uses
              Cases and Requirements",
              draft-ersue-constrained-mgmt-02 (work in progress),
              October 2012.

   [I-D.greevenbosch-core-minimum-request-interval]
              Greevenbosch, B., "CoAP Minimum Request Interval",
              draft-greevenbosch-core-minimum-request-interval-00 (work
              in progress), September 2012.

   [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, 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-01 (work in progress),
              October 2012.

Greevenbosch & Li        Expires August 29, 2013               [Page 29]
Internet-Draft       COMAN - Candidate Technologies        February 2013

   [I-D.shelby-core-resource-directory]
              Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource
              Directory", draft-shelby-core-resource-directory-04 (work
              in progress), July 2012.

   [I-D.vanderstok-core-dna]
              van der 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.

   [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.

Greevenbosch & Li        Expires August 29, 2013               [Page 30]
Internet-Draft       COMAN - Candidate Technologies        February 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

Greevenbosch & Li        Expires August 29, 2013               [Page 31]