Re: [6tisch] Thomas's review of draft-ietf-opsawg-coman-use-cases-02
Thomas Watteyne <watteyne@eecs.berkeley.edu> Sun, 10 August 2014 23:08 UTC
Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541121A0178; Sun, 10 Aug 2014 16:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.433
X-Spam-Level: *
X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHp9n6rsntZ3; Sun, 10 Aug 2014 16:08:20 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275841A0176; Sun, 10 Aug 2014 16:08:20 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id r10so9731492pdi.20 for <multiple recipients>; Sun, 10 Aug 2014 16:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=p3/riG8Z++Rtpr8UK41KZAsHgWAl0nC2TwVouBpiftY=; b=tS85AxgMP4cP03fSykp2DzJ2HKogxLF7kVXl6IZckukcWbfS7EJJ+JN1n/hSDf1VfS 5bWt5BtGAYsgsFMuOhcWokCbuRMRUVfk+eZKyTu33w44B+uanRrbdeC6R7kABSpXhc67 qayPybF+/mcnecT0jEZBCUsuGZ/eJfotF8PWY1a/+fnOArAUUrsmoLpa7aoqedBkQ31j zkWfFPFRID5d6Hc+0HZtxwtovwp2egiADWR+qQPdBmcSS7taLLB8I+7EDyOHJTKUmr91 tglOS9C7z6juJDXBg3hJ2oD4/9ueQONpK1ePVjiySv2TbQ3A4GcgtrY4B+OAH+y4FzX2 kP0w==
X-Received: by 10.70.36.239 with SMTP id t15mr19665766pdj.83.1407712099628; Sun, 10 Aug 2014 16:08:19 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.144.1 with HTTP; Sun, 10 Aug 2014 16:07:59 -0700 (PDT)
In-Reply-To: <CADJ9OA_3q+_yUD3Y88Luge-AJK6T93Ev3eVduTCSdAvFyFZ5Lw@mail.gmail.com>
References: <CADJ9OA_3q+_yUD3Y88Luge-AJK6T93Ev3eVduTCSdAvFyFZ5Lw@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Sun, 10 Aug 2014 16:07:59 -0700
X-Google-Sender-Auth: q7-DCKFwG2ynVSg0E7bMcP9nLaI
Message-ID: <CADJ9OA_dPPgYbEh4g75i-Rmqw2HZVPqQXo5vB_ukbM-21Eh5Ew@mail.gmail.com>
To: opsawg <opsawg@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="089e0103ed82a4fcc505004e8335"
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/0SjtivwLSh7qfuxuw6JVj2MP4RQ
Subject: Re: [6tisch] Thomas's review of draft-ietf-opsawg-coman-use-cases-02
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 23:08:31 -0000
[resend'ing CC'ing 6TiSCH ML] On Fri, Aug 8, 2014 at 11:29 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu > wrote: > I was asked to do a detailed review > of draft-ietf-opsawg-coman-use-cases-02. > > Constrained management is important for the 6TiSCH WG. I am really happy > to see that the COMAN work has been able to progress in OPSAWG. I wasn't > aware of the progress on this document in OPS until IETF90 (my fault...); > but have since announced it to the 6TiSCH WG. > > The 6TiSCH architecture supports a mode in which a central entity manages > the communication schedule of the nodes. Typically, the node form a > constrained network (very little bandwidth, energy constraints, etc), and > the (possible less constrained) management entity sits on the edge of that > network. This management entity need to (1) set a number of parameters on > the motes and (2) monitor some statistics to possibly trigger some action. > Nothing particularly surprising, indeed. > > So far, we have been defined our own "home brew" management protocol on > top of CoAP (draft-ietf-6tisch-coap-01). There is really nothing specific > to 6TiSCH in that solution, and we'd love to be able to reuse any more > generic management solution for constrained environments. Ideally, this > management solution would be shared by other software pieces running on the > constrained device, e.g. the 6LoWPAN layer. > > I am also reading draft-ietf-opsawg-coman-probstate-reqs-02, the review of > which I will send in a separate e-mail to keep things clean. > > Thomas > > GENERAL > -------------- > > The different sections are very "independent", and the draft would benefit > from some text at the beginning which would glue those together. Ideas are: > - enforce the same structure for each use case section, possibly by > grouping the paragraphs under a title, e.g. "description of the use case", > "expectation from management solution", etc. > - add a table/list at the beginning which summarizes the different > features one can expect from a management system, for each of the use cases > (e.g. "privacy" in Medical Applications). This would give the reader a > one-page overview, allowing him/her to more easily go back to the text. > > In some use cases, while the use case is very clearly described, it's hard > to see what the use case is *for the management*. This is particularly true > in "Building Automation", and somewhat in "Industrial Applications". > > It might be interesting, for each use case, to describe how the management > changes over the lifetime of the system. For example, some security aspect > (authentication, authorization) only exist during commissioning. > > It would be good, although maybe hard, to have common metrics across all > uses cases, allowing for an easier comparison. For example, the approx. > amount of management data, generation rate of this management data (and > associated size). > > It would be good to order the use cases logically, and highlight in the > intro text what the extremes are. For example (and I'm making this up), > management in the Field Operations use cases involves the most frequent > exchange of data, and hence a large overhead, than a Home Automation > application in which most management is done during commissioning. > > DETAILED > --------------- > > please find my comments below, prefixed by "^TW>" > > > Internet Engineering Task Force M. Ersue, Ed. > Internet-Draft Nokia Networks > Intended status: Informational D. Romascanu > Expires: January 5, 2015 Avaya > J. Schoenwaelder > A. Sehgal > Jacobs University Bremen > July 4, 2014 > > > Management of Networks with Constrained Devices: Use Cases > draft-ietf-opsawg-coman-use-cases-02 > > Abstract > > This document discusses use cases concerning the management of > networks, where constrained devices are involved. A problem > statement, deployment options and the requirements on the networks > with constrained devices can be found in the companion document on > "Management of Networks with Constrained Devices: Problem Statement > and Requirements". > > 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 January 5, 2015. > > Copyright Notice > > Copyright (c) 2014 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 > > > > Ersue, et al. Expires January 5, 2015 [Page 1] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Access Technologies . . . . . . . . . . . . . . . . . . . . . 4 > 2.1. Constrained Access Technologies . . . . . . . . . . . . . 4 > 2.2. Cellular Access Technologies . . . . . . . . . . . . . . 4 > 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Environmental Monitoring . . . . . . . . . . . . . . . . 6 > 3.2. Infrastructure Monitoring . . . . . . . . . . . . . . . . 6 > 3.3. Industrial Applications . . . . . . . . . . . . . . . . . 7 > 3.4. Energy Management . . . . . . . . . . . . . . . . . . . . 9 > 3.5. Medical Applications . . . . . . . . . . . . . . . . . . 11 > 3.6. Building Automation . . . . . . . . . . . . . . . . . . . 12 > 3.7. Home Automation . . . . . . . . . . . . . . . . . . . . . 13 > 3.8. Transport Applications . . . . . . . . . . . . . . . . . 14 > 3.9. Community Network Applications . . . . . . . . . . . . . 16 > 3.10. Field Operations . . . . . . . . . . . . . . . . . . . . 18 > 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 > 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 > 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 > 8. Informative References . . . . . . . . . . . . . . . . . . . 20 > Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 > A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg- > coman-use-cases-02 . . . . . . . . . . . . . . . . . . . 21 > A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg- > coman-use-cases-01 . . . . . . . . . . . . . . . . . . . 22 > A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg- > coman-use-cases-00 . . . . . . . . . . . . . . . . . . . 23 > A.4. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 23 > A.5. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 24 > A.6. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 25 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 > > 1. Introduction > > Small devices with limited CPU, memory, and power resources, so > called constrained devices (aka. sensor, smart object, or smart > device) can be connected to a network. Such a network of constrained > devices itself may be constrained or challenged, e.g., with > unreliable or lossy channels, wireless technologies with limited > bandwidth and a dynamic topology, needing the service of a gateway or > > > > Ersue, et al. Expires January 5, 2015 [Page 2] > Internet-Draft Constrained Management: Use Cases July 2014 > > > proxy to connect to the Internet. In other scenarios, the > constrained devices can be connected to a non-constrained network > using off-the-shelf protocol stacks. Constrained devices might be in > charge of gathering information in diverse settings including natural > ecosystems, buildings, and factories and send the information to one > or more server stations. > > Network management is characterized by monitoring network status, > detecting faults, and inferring their causes, setting network > parameters, and carrying out actions to remove faults, maintain > normal operation, and improve network efficiency and application > performance. The traditional network management application > periodically collects information from a set of elements that are > needed to manage, processes the data, and presents them to the > network management users. Constrained devices, however, often have > limited power, low transmission range, and might be unreliable > > TW> I don't understand what you mean by "be unreliable". Do you mean that > the > TW> device itself is unreliable (what exactly does that mean?), or that the > TW> communication with that device is unreliable? > TW> I would add that such networks most often have low capacity. > TW> I would add that such networks most often have high latency. > > They > might also need to work in hostile environments with advanced > security requirements or need to be used in harsh environments for a > long time without supervision. Due to such constraints, the > management of a network with constrained devices offers different > type of challenges compared to the management of a traditional IP > network. > > This document aims to understand use cases for the management of a > network, where constrained devices are involved. The document lists > and discusses diverse use cases for the management from the network > as well as from the application point of view. The list of discussed > use cases is not an exhaustive one since other scenarios, currently > unknown to the authors, are possible. > > TW> Typo below, remove "are". > > are The application scenarios > discussed aim to show where networks of constrained devices are > expected to be deployed. For each application scenario, we first > briefly describe the characteristics followed by a discussion on how > network management can be provided, who is likely going to be > responsible for it, and on which time-scale management operations are > likely to be carried out. > > A problem statement, deployment and management topology options as > well as the requirements on the networks with constrained devices can > be found in the companion document [COM-REQ]. > > This documents builds on the terminology defined in [RFC7228] and > [COM-REQ]. [RFC7228] is a base document for the terminology > concerning constrained devices and constrained networks. Some use > cases specific to IPv6 over Low-Power Wireless Personal Area Networks > (6LoWPANs) can be found in [RFC6568]. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 3] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 2. Access Technologies > > Besides the management requirements imposed by the different use > cases, the access technologies used by constrained devices can impose > restrictions and requirements upon the Network Management System > (NMS) and protocol of choice. > > It is possible that some networks of constrained devices might > utilize traditional non-constrained access technologies for network > access, e.g., local area networks with plenty of capacity. In such > scenarios, the constrainedness of the device presents special > management restrictions and requirements rather than the access > technology utilized. > > However, in other situations constrained or cellular access > technologies might be used for network access, thereby causing > management restrictions and requirements to arise as a result of the > underlying access technologies. > > 2.1. Constrained Access Technologies > > Due to resource restrictions, embedded devices deployed as sensors > and actuators in the various use cases utilize low-power low data- > rate wireless access technologies such as IEEE 802.15.4, DECT ULE or > BT-LE for network connectivity. > > In such scenarios, it is important for the NMS to be aware of the > restrictions imposed by these access technologies to efficiently > manage these constrained devices. Specifically, such low-power low > data-rate access technologies typically have small frame sizes. So > it would be important for the NMS and management protocol of choice > to craft packets in a way that avoids fragmentation and reassembly of > packets since this can use valuable memory on constrained devices. > > Devices using such access technologies might operate via a gateway > that translates between these access technologies and more > traditional Internet protocols. A hierarchical approach to device > management in such a situation might be useful, wherein the gateway > device is in-charge of devices connected to it, while the NMS > conducts management operations only to the gateway. > > 2.2. Cellular Access Technologies > > Machine to machine (M2M) services are increasingly provided by mobile > service providers as numerous devices, home appliances, utility > meters, cars, video surveillance cameras, and health monitors, are > connected with mobile broadband technologies. Different > applications, e.g., in a home appliance or in-car network, use > > > > Ersue, et al. Expires January 5, 2015 [Page 4] > Internet-Draft Constrained Management: Use Cases July 2014 > > > > TW> typo, Zigbee -> ZigBee (throughout doc) > > Bluetooth, Wi-Fi or Zigbee locally and connect to a cellular module > acting as a gateway between the constrained environment and the > mobile cellular network. > > Such a gateway might provide different options for the connectivity > of mobile networks and constrained devices: > > TW> BT-LE --> Bluetooth Low-Energy (BT-LE) > > o a smart phone with 3G/4G and WLAN radio might use BT-LE to connect > to the devices in a home area network, > > o a femtocell might be combined with home gateway functionality > acting as a low-power cellular base station connecting smart > devices to the application server of a mobile service provider, > > o an embedded cellular module with LTE radio connecting the devices > in the car network with the server running the telematics service, > > o an M2M gateway connected to the mobile operator network supporting > diverse IoT connectivity technologies including ZigBee and CoAP > over 6LoWPAN over IEEE 802.15.4. > > Common to all scenarios above is that they are embedded in a service > and connected to a network provided by a mobile service provider. > Usually there is a hierarchical deployment and management topology in > place where different parts of the network are managed by different > management entities and the count of devices to manage is high (e.g. > many thousands). In general, the network is comprised by manifold > type and size of devices matching to different device classes. As > such, the managing entity needs to be prepared to manage devices with > diverse capabilities using different communication or management > protocols. In case the devices are directly connected to a gateway > they most likely are managed by a management entity integrated with > the gateway, which itself is part of the Network Management System > (NMS) run by the mobile operator. Smart phones or embedded modules > connected to a gateway might be themselves in charge to manage the > devices on their level. The initial and subsequent configuration of > such a device is mainly based on self-configuration and is triggered > by the device itself. > > The gateway might be in charge of filtering and aggregating the data > received from the device as the information sent by the device might > be mostly redundant. > > 3. Use Cases > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 5] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 3.1. Environmental Monitoring > > Environmental monitoring applications are characterized by the > deployment of a number of sensors to monitor emissions, water > quality, or even the movements and habits of wildlife. Other > applications in this category include earthquake or tsunami early- > warning systems. The sensors often span a large geographic area, > they can be mobile, and they are often difficult to replace. > Furthermore, the sensors are usually not protected against tampering. > > Management of environmental monitoring applications is largely > concerned with the monitoring whether the system is still functional > and the roll-out of new constrained devices in case the system looses > too much of its structure. The constrained devices themselves need > to be able to establish connectivity (auto-configuration) and they > need to be able to deal with events such as loosing neighbors or > being moved to other locations. > > Management responsibility typically rests with the organization > running the environmental monitoring application. Since these > monitoring applications must be designed to tolerate a number of > failures, the time scale for detecting and recording failures is for > some of these applications likely measured in hours and repairs might > easily take days. In fact, in some scenarios it might be more cost- > and time-effective to not repair such devices at all. However, for > certain environmental monitoring applications, much tighter time > scales may exist and might be enforced by regulations (e.g., > monitoring of nuclear radiation). > > 3.2. Infrastructure Monitoring > > Infrastructure monitoring is concerned with the monitoring of > infrastructures such as bridges, railway tracks, or (offshore) > windmills. The primary goal is usually to detect any events or > changes of the structural conditions that can impact the risk and > safety of the infrastructure being monitored. Another secondary goal > is to schedule repair and maintenance activities in a cost effective > manner. > > The infrastructure to monitor might be in a factory or spread over a > wider area but difficult to access. As such, the network in use > might be based on a combination of fixed and wireless technologies, > which use robust networking equipment and support reliable > communication via application layer transactions. It is likely that > constrained devices in such a network are mainly C2 > > >TW please define "C2", and provide RFC > > devices and have > to be controlled centrally by an application running on a server. In > case such a distributed network is widely spread, the wireless > devices might use diverse long-distance wireless technologies such as > > > > Ersue, et al. Expires January 5, 2015 [Page 6] > Internet-Draft Constrained Management: Use Cases July 2014 > > TW> I don't fully understand what you mean by "e.g. based on embedded > hardware > TW> modules", in partcular the "e.g." part. Maybe write the idea out in a > TW> separate sentence? > > WiMAX, or 3G/LTE, e.g. based on embedded hardware modules. In cases, > where an in-building network is involved, the network can be based on > Ethernet or wireless technologies suitable for in-building usage. > > The management of infrastructure monitoring applications is primarily > concerned with the monitoring of the functioning of the system. > Infrastructure monitoring devices are typically rolled out and > installed by dedicated experts and changes are rare since the > infrastructure itself changes rarely. However, monitoring devices > are often deployed in unsupervised environments and hence special > attention must be given to protecting the devices from being > modified. > > Management responsibility typically rests with the organization > owning the infrastructure or responsible for its operation. The time > scale for detecting and recording failures is likely measured in > hours and repairs might easily take days. However, certain events > (e.g., natural disasters) may require that status information be > obtained much more quickly and that replacements of failed sensors > can be rolled out quickly (or redundant sensors are activated > quickly). In case the devices are difficult to access, a self- > healing feature on the device might become necessary. > > 3.3. Industrial Applications > > Industrial Applications and smart manufacturing refer to tasks such > as networked control and monitoring of manufacturing equipment, asset > and situation management, or manufacturing process control. For the > management of a factory it is becoming essential to implement smart > capabilities. From an engineering standpoint, industrial > applications are intelligent systems enabling rapid manufacturing of > new products, dynamic response to product demands, and real-time > optimization of manufacturing production and supply chain networks. > Potential industrial applications (e.g., for smart factories and > smart manufacturing) are: > > o Digital control systems with embedded, automated process controls, > operator tools, as well as service information systems optimizing > plant operations and safety. > > o Asset management using predictive maintenance tools, statistical > evaluation, and measurements maximizing plant reliability. > > o Smart sensors detecting anomalies to avoid abnormal or > catastrophic events. > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 7] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Smart systems integrated within the industrial energy management > system and externally with the smart grid enabling real-time > energy optimization. > > TW> I don't understand what the "management" part here refers to in this > TW> section. I expect the draft to deal exclusively with the management > needs > TW> for the constrained network (e.g. monitoring 6LoWPAN counters). This > TW> section seems to deal with the management of a smart plant. > > Management of Industrial Applications and smart manufacturing may in > some situations involve Building Automation tasks such as control of > energy, HVAC (heating, ventilation, and air conditioning), lighting, > or access control. Interacting with management systems from other > application areas might be important in some cases (e.g., > environmental monitoring for electric energy production, energy > management for dynamically scaling manufacturing, vehicular networks > for mobile asset tracking). > > Sensor networks are an essential technology used for smart > manufacturing. Measurements, automated controls, plant optimization, > health and safety management, and other functions are provided by a > large number of networked sectors. Data interoperability and > seamless exchange of product, process, and project data are enabled > through interoperable data systems used by collaborating divisions or > business systems. Intelligent automation and learning systems are > vital to smart manufacturing but must be effectively integrated with > the decision environment. Wireless sensor networks (WSN) have been > developed for machinery Condition-based Maintenance (CBM) as they > offer significant cost savings and enable new functionalities. > Inaccessible locations, rotating machinery, hazardous areas, and > mobile assets can be reached with wireless sensors. WSNs can provide > today wireless link reliability, real-time capabilities, and quality- > of-service and enable industrial and related wireless sense and > control applications. > > Management of industrial and factory applications is largely focused > on the monitoring whether the system is still functional, real-time > continuous performance monitoring, and optimization as necessary. > The factory network might be part of a campus network or connected to > the Internet. The constrained devices in such a network need to be > able to establish configuration themselves (auto-configuration) and > might need to deal with error conditions as much as possible locally. > Access control has to be provided with multi-level administrative > access and security. Support and diagnostics can be provided through > remote monitoring access centralized outside of the factory. > > Management responsibility is typically owned by the organization > running the industrial application. Since the monitoring > applications must handle a potentially large number of failures, the > time scale for detecting and recording failures is for some of these > applications likely measured in minutes. However, for certain > industrial applications, much tighter time scales may exist, e.g. in > > > > > Ersue, et al. Expires January 5, 2015 [Page 8] > Internet-Draft Constrained Management: Use Cases July 2014 > > > real-time, which might be enforced by the manufacturing process or > the use of critical material. > > 3.4. Energy Management > > The EMAN working group developed an energy management framework > [I-D.ietf-eman-framework] for devices and device components within or > connected to communication networks. This document observes that one > of the challenges of energy management is that a power distribution > network is responsible for the supply of energy to various devices > and components, while a separate communication network is typically > used to monitor and control the power distribution network. Devices > in the context of energy management can be monitored for parameters > like Power, Energy, Demand and Power Quality. If a device contains > batteries, they can be also monitored and managed. > > Energy devices differ in complexity and may include basic sensors or > switches, specialized electrical meters, or power distribution units > (PDU), and subsystems inside the network devices (routers, network > switches) or home or industrial appliances. The operators of an > Energy Management System are either the utility providers or > customers that aim to control and reduce the energy consumption and > the associated costs. The topology in use differs and the deployment > can cover areas from small surfaces (individual homes) to large > geographical areas. The EMAN requirements document [RFC6988] > discusses the requirements for energy management concerning > monitoring and control functions. > > It is assumed that Energy Management will apply to a large range of > devices of all classes and networks topologies. Specific resource > monitoring like battery utilization and availability may be specific > to devices with lower physical resources (device classes C0 or C1). > > Energy Management is especially relevant to the Smart Grid. A Smart > Grid is an electrical grid that uses data networks to gather and to > act on energy and power-related information in an automated fashion > with the goal to improve the efficiency, reliability, economics, and > sustainability of the production and distribution of electricity. > > Smart Metering is a good example of Smart Grid based Energy > Management applications. Different types of possibly wireless small > meters produce all together a large amount of data, which is > collected by a central entity and processed by an application server, > which may be located within the customer's residence or off-site in a > data-center. The communication infrastructure can be provided by a > mobile network operator as the meters in urban areas will have most > likely a cellular or WiMAX radio. In case the application server is > > > > > Ersue, et al. Expires January 5, 2015 [Page 9] > Internet-Draft Constrained Management: Use Cases July 2014 > > > located within the residence, such meters are more likely to use WiFi > protocols to interconnect with an existing network. > > An Advanced Metering Infrastructure (AMI) network is another example > of the Smart Grid that enables an electric utility to retrieve > frequent electric usage data from each electric meter installed at a > customer's home or business. Unlike Smart Metering, in which case > the customer or their agents install appliance level meters, an AMI > infrastructure is typically managed by the utility providers and > could also include other distribution automation devices like > transformers and reclosers. Meters in AMI networks typically contain > constrained devices that connect to mesh networks with a low- > bandwidth radio. Usage data and outage notifications can be sent by > these meters to the utility's headend systems, via aggregation points > of higher-end router devices that bridge the constrained network to a > less constrained network via cellular, WiMAX, or Ethernet. Unlike > meters, these higher-end devices might be installed on utility poles > owned and operated by a separate entity. > > It thereby becomes important for a management application to not only > be able to work with diverse types of devices, but also over multiple > links that might be operated and managed by separate entities, each > having divergent policies for their own devices and network segments. > During management operations, like firmware updates, it is important > that the management system performs robustly in order to avoid > accidental outages of critical power systems that could be part of > AMI networks. In fact, since AMI networks must also report on > outages, the management system might have to manage the energy > properties of battery operated AMI devices themselves as well. > > A management system for home based Smart Metering solutions is likely > to have few devices laid out in a simple topology. > TW> how many are few? what's a simple topology? While (I think) I have a > good > TW> of what that might be, proposing a range might help with scope > However, AMI > networks installations could have thousands of nodes per router, > i.e., higher-end device, which organize themselves in an ad-hoc > manner. As such, a management system for AMI networks will need to > discover and operate over complex topologies as well. In some > situations, it is possible that the management system might also have > to setup and manage the topology of nodes, especially critical > routers. Encryption key management and sharing in both types of > network > TW> typo network*s* > is also likely to be important for providing confidentiality > for all data traffic. In AMI networks the key may be obtained by a > meter only after an end-to-end authentication process based on > certificates. Smart Metering solution could adopt a similar approach > or the security may be implied due to the encrypted WiFi networks > they become part of. > > TW> Please use either Wi-Fi or WiFi. There must be an official one? > > The management of such a network requires end-to-end management of > and information exchange through different types of networks. > > > > Ersue, et al. Expires January 5, 2015 [Page 10] > Internet-Draft Constrained Management: Use Cases July 2014 > > > However, as of today there is no integrated energy management > approach and no common information model available. Specific energy > management applications or network islands use their own management > mechanisms. > > 3.5. Medical Applications > > Constrained devices can be seen as an enabling technology for > advanced and possibly remote health monitoring and emergency > notification systems, ranging from blood pressure and heart rate > monitors to advanced devices capable to monitor > TW> rephrase to "capable of monitoring"? > implanted > technologies, such as pacemakers or advanced hearing aids. Medical > sensors may not only be attached to human bodies, they might also > exist in the infrastructure used by humans such as bathrooms or > kitchens. Medical applications will also be used to ensure > treatments are being applied properly and they might guide people > losing orientation. Fitness and wellness applications, such as > connected scales or wearable heart monitors, encourage consumers to > exercise and empower self-monitoring of key fitness indicators. > Different applications use Bluetooth, Wi-Fi or Zigbee connections to > access the patient's smartphone or home cellular connection to access > the Internet. > > Constrained devices that are part of medical applications are managed > either by the users of those devices or by an organization providing > medical (monitoring) services for physicians. In the first case, > management must be automatic and or > TW> "and/or"? > easy to install and setup by > average people. In the second case, it can be expected that devices > be controlled by specially trained people. In both cases, however, > it is crucial to protect the privacy of the people to which medical > devices are attached. Even though the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. > > Many medical devices are likely to be used (and relied upon) to > provide data to physicians in critical situations since the biggest > market is likely elderly and handicapped people. Timely delivery of > data can be quite important in certain applications like patient > mobility monitoring in oldage homes. Data must reach the physician > and/or emergency services within specified limits of time in order to > be useful. As such, fault detection of the communication network or > the constrained devices becomes a crucial function of the management > system that must be carried out with high reliability and, depending > on the medical appliance and its application, within seconds. > > > > > > Ersue, et al. Expires January 5, 2015 [Page 11] > Internet-Draft Constrained Management: Use Cases July 2014 > > > 3.6. Building Automation > > Building automation comprises the distributed systems designed and > deployed to monitor and control the mechanical, electrical and > electronic systems inside buildings with various destinations (e.g., > public and private, industrial, institutions, or residential). > Advanced Building Automation Systems (BAS) may be deployed > concentrating the various functions of safety, environmental control, > occupancy, security. More and more the deployment of the various > functional systems is connected to the same communication > infrastructure (possibly Internet Protocol based), which may involve > wired or wireless communications networks inside the building. > > Building automation requires the deployment of a large number > (10-100.000) of sensors that monitor the status of devices, and > parameters inside the building and controllers with different > specialized functionality for areas within the building or the > totality of the building. Inter-node distances between neighboring > nodes vary between 1 to 20 meters. Contrary to home automation, in > building management the devices are expected to be managed assets and > known to a set of commissioning tools and a data storage, such that > every connected device has a known origin. The management includes > verifying the presence of the expected devices and detecting the > presence of unwanted devices. > > Examples of functions performed by such controllers are regulating > the quality, humidity, and temperature of the air inside the building > and lighting. Other systems may report the status of the machinery > inside the building like elevators, or inside the rooms like > projectors in meeting rooms. Security cameras and sensors may be > deployed and operated on separate dedicated infrastructures connected > to the common backbone. The deployment area of a BAS is typically > inside one building (or part of it) or several buildings > geographically grouped in a campus. A building network can be > composed of network segments, where a network segment covers a floor, > an area on the floor, or a given functionality (e.g., security > cameras). > > Some of the sensors in Building Automation Systems (for example fire > alarms or security systems) register, record and transfer critical > alarm information and therefore must be resilient to events like loss > of power or security attacks. This leads to the need to certify > components and subsystems operating in such constrained conditions > based on specific requirements. Also in some environments, the > malfunctioning of a control system (like temperature control) needs > to be reported in the shortest possible time. Complex control > systems can misbehave, and their critical status reporting and safety > > > > > Ersue, et al. Expires January 5, 2015 [Page 12] > Internet-Draft Constrained Management: Use Cases July 2014 > > > algorithms need to be basic and robust and perform even in critical > conditions. > > Building Automation solutions are deployed in some cases in newly > designed buildings, in other cases it might be over existing > infrastructures. In the first case, there is a broader range of > possible solutions, which can be planned for the infrastructure of > the building. In the second case the solution needs to be deployed > over an existing infrastructure taking into account factors like > existing wiring, distance limitations, the propagation of radio > signals over walls and floors, thereby making deployment difficult. > As a result, some of the existing WLAN solutions (e.g., IEEE 802.11 > or IEEE 802.15) may be deployed. In mission-critical or security > sensitive environments and in cases where link failures happen often, > topologies that allow for reconfiguration of the network and > connection continuity may be required. Some of the sensors deployed > in building automation may be very simple constrained devices for > which class 0 or class 1 may be assumed. > > TW> you use "C1" and "C0" above. Please homogenize. > > For lighting applications, groups of lights must be defined and > managed. Commands to a group of light must arrive within 200 ms at > all destinations. The installation and operation of a building > network has different requirements. During the installation, many > stand-alone networks of a few to 100 nodes co-exist without a > connection to the backbone. During this phase, the nodes are > identified with a network identifier related to their physical > location. Devices are accessed from an installation tool to connect > them to the network in a secure fashion. During installation, the > setting of parameters of common values to enable interoperability may > be required. During operation, the networks are connected to the > backbone while maintaining the network identifier to physical > location relation. Network parameters like address and name are > stored in DNS. The names can assist in determining the physical > location of the device. > > 3.7. Home Automation > > Home automation includes the control of lighting, heating, > ventilation, air conditioning, appliances, entertainment and home > TW> The word "security" appears twice > security devices to improve convenience, comfort, energy efficiency, > and security. It can be seen as a residential extension of building > automation. However, unlike a building automation system, the > infrastructure in a home is operated in a considerably more ad-hoc > manner. While in some installations it is likely that there is no > centralized management system, akin to a Building Automation System > (BAS), available, in other situations outsourced and cloud based > systems responsible for managing devices in the home might be used. > > > > > Ersue, et al. Expires January 5, 2015 [Page 13] > Internet-Draft Constrained Management: Use Cases July 2014 > > > Home automation networks need a certain amount of configuration > TW> actors -> actuators ? > (associating switches or sensors to actors) that is either provided > by electricians deploying home automation solutions, by third party > home automation service providers (e.g., small specialized companies > or home automation device manufacturers) or by residents by using the > application user interface provided by home automation devices to > configure (parts of) the home automation solution. Similarly, > failures may be reported via suitable interfaces to residents or they > might be recorded and made available to services providers in charge > of the maintenance of the home automation infrastructure. > > The management responsibility lies either with the residents or it > may be outsourced to electricians and/or third parties providing > management of home automation solutions as a service. A varying > combination of electricians, service providers or the residents may > be responsible for different aspects of managing the infrastructure. > The time scale for failure detection and resolution is in many cases > likely counted in hours to days. > > 3.8. Transport Applications > > Transport Application is a generic term for the integrated > application of communications, control, and information processing in > a transportation system. Transport telematics or vehicle telematics > are used as a term for the group of technologies that support > transportation systems. Transport applications running on such a > transportation system cover all modes of the transport and consider > all elements of the transportation system, i.e. the vehicle, the > infrastructure, and the driver or user, interacting together > dynamically. Examples for transport applications are inter and intra > vehicular communication, smart traffic control, smart parking, > electronic toll collection systems, logistic and fleet management, > vehicle control, and safety and road assistance. > > As a distributed system, transport applications require an end-to-end > management of different types of networks. It is likely that > constrained devices in a network (e.g. a moving in-car network) have > to be controlled by an application running on an application server > in the network of a service provider. Such a highly distributed > network including cellular devices on vehicles is assumed to include > a wireless access network using diverse long distance wireless > technologies such as WiMAX, 3G/LTE or satellite communication, e.g. > based on an embedded hardware module. As a result, the management of > constrained devices in the transport system might be necessary to > plan top-down and might need to use data models obliged from and > defined on the application layer. The assumed device classes in use > are mainly C2 devices. In cases, where an in-vehicle network is > involved, C1 devices with limited capabilities and a short-distance > > > > Ersue, et al. Expires January 5, 2015 [Page 14] > Internet-Draft Constrained Management: Use Cases July 2014 > > > constrained radio network, e.g. IEEE 802.15.4 might be used > additionally. > > All Transport Applications will require an IT infrastructure to run > on top of, e.g., in public transport scenarios like trains, bus or > metro network infrastructure might be provided, maintained and > operated by third parties like mobile network or satellite network > operators. However, the management responsibility of the transport > application typically rests within the organization running the > transport application (in the public transport scenario, this would > typically be the public transport operator). Different aspects of > the infrastructure might also be managed by different entities. For > example, the in-car devices are likely to be installed and managed by > the manufacturer, while the public works might be responsible for the > on-road vehicular communication infrastructure used by these devices. > The back-end infrastructure is also likely to be maintained by third > party operators. As such, the NMS must be able to deal with > different network segments, each being operated and controlled by > separate entities, and enable appropriate access control and security > as well. > > Depending on the type of application domain (vehicular or stationary) > and service being provided, it would be important for the NMS to be > able to function with different architectures, since different > manufacturers might have their own proprietary systems relying on a > specific Management Topology Option, as described in [COM-REQ]. > Moreover, constituents of the network can be either private, > belonging to individuals or private companies, or owned by public > institutions leading to different legal and organization > requirements. Across the entire infrastructure, a variety of > constrained devices are likely to be used, and must be individually > managed. The NMS must be able to either work directly with different > types of devices, or have the ability to interoperate with multiple > different systems. > > The challenges in the management of vehicles in a mobile transport > application are manifold. The up-to-date position of each node in > the network should be reported to the corresponding management > entities, since the nodes could be moving within or roaming between > different networks. Secondly, a variety of troubleshooting > information, including sensitive location information, needs to be > reported to the management system in order to provide accurate > service to the customer. Management systems dealing with mobile > nodes could possibly exploit specific patterns in the mobility of the > nodes. These patterns emerge due to repetitive vehicular usage in > scenarios like people commuting to work, logistics supply vehicles > transporting shipments between warehouses and etc. The NMS must also > be able to handle partitioned networks, which would arise due to the > > > > Ersue, et al. Expires January 5, 2015 [Page 15] > Internet-Draft Constrained Management: Use Cases July 2014 > > > dynamic nature of traffic resulting in large inter-vehicle gaps in > sparsely populated scenarios. Since mobile nodes might roam in > remote networks, the NMS should be able to provide operating > configuration updates regardless of node location. > > The constrained devices in a moving transport network might be > initially configured in a factory and a reconfiguration might be > needed only rarely. New devices might be integrated in an ad-hoc > manner based on self-management and -configuration capabilities. > Monitoring and data exchange might be necessary to do via a gateway > entity connected to the back-end transport infrastructure. The > devices and entities in the transport infrastructure need to be > monitored more frequently and can be able to communicate with a > higher data rate. The connectivity of such entities does not > necessarily need to be wireless. The time scale for detecting and > recording failures in a moving transport network is likely measured > in hours and repairs might easily take days. It is likely that a > self-healing feature would be used locally. On the other hand, > failures in fixed transport application infrastructure (e.g., > traffic-lights, digital signage displays) is likely to be measured in > minutes so as to avoid untoward traffic incidents. As such, the NMS > must be able to deal with differing timeliness requirements based on > the type of devices. > > 3.9. Community Network Applications > > Community networks are comprised of constrained routers in a multi- > hop mesh topology, communicating over a lossy, and often wireless > TW> typo: channel*s* > channel. While the routers are mostly non-mobile, the topology may > be very dynamic because of fluctuations in link quality of the > (wireless) channel caused by, e.g., obstacles, or other nearby radio > transmissions. Depending on the routers that are used in the > community network, the resources of the routers (memory, CPU) may be > more or less constrained - available resources may range from only a > few kilobytes of RAM to several megabytes or more, and CPUs may be > small and embedded, or more powerful general-purpose processors. > Examples of such community networks are the FunkFeuer network > (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless > (Seattle, USA), and AWMN (Athens, Greece). These community networks > are public and non-regulated, allowing their users to connect to each > other and - through an uplink to an ISP - to the Internet. No fee, > other than the initial purchase of a wireless router, is charged for > these services. Applications of these community networks can be > diverse, e.g., location based services, free Internet access, file > sharing between users, distributed chat services, social networking > etc, video sharing etc. > > TW> One "etc" too many above. > > > > > Ersue, et al. Expires January 5, 2015 [Page 16] > Internet-Draft Constrained Management: Use Cases July 2014 > > > As an example of a community network, the FunkFeuer network comprises > several hundred routers, many of which have several radio interfaces > (with omnidirectional and some directed antennas). The routers of > the network are small-sized wireless routers, such as the Linksys > WRT54GL, available in 2011 for less than 50 Euros. These routers, > with 16 MB of RAM and 264 MHz of CPU power, are mounted on the > rooftops of the users. When new users want to connect to the > network, they acquire a wireless router, install the appropriate > firmware and routing protocol, and mount the router on the rooftop. > IP addresses for the router are assigned manually from a list of > addresses (because of the lack of autoconfiguration standards for > TW> autoconfiguration -> auto-configuration? > mesh networks in the IETF). > > While the routers are non-mobile, fluctuations in link quality > require an ad hoc routing protocol that allows for quick convergence > to reflect the effective topology of the network (such as NHDP > [RFC6130] and OLSRv2 [RFC7181] developed in the MANET WG). Usually, > no human interaction is required for these protocols, as all variable > parameters required by the routing protocol are either negotiated in > the control traffic exchange, or are only of local importance to each > router (i.e. do not influence interoperability). However, external > management and monitoring of an ad hoc routing protocol may be > desirable to optimize parameters of the routing protocol. Such an > optimization may lead to a more stable perceived topology and to a > lower control traffic overhead, and therefore to a higher delivery > success ratio of data packets, a lower end-to-end delay, and less > unnecessary bandwidth and energy usage. > > Different use cases for the management of community networks are > possible: > > o One single Network Management Station, e.g. a border gateway > providing connectivity to the Internet, requires managing or > monitoring routers in the community network, in order to > investigate problems (monitoring) or to improve performance by > changing parameters (managing). As the topology of the network is > dynamic, constant connectivity of each router towards the > management station cannot be guaranteed. Current network > TW> Netconf -> NETCONF (see RFC4741) > management protocols, such as SNMP and Netconf, may be used (e.g., > using interfaces such as the NHDP-MIB [RFC6779]). However, when > routers in the community network are constrained, existing > protocols may require too many resources in terms of memory and > CPU; and more importantly, the bandwidth requirements may exceed > the available channel capacity in wireless mesh networks. > Moreover, management and monitoring may be unfeasible if the > connection between the network management station and the routers > is frequently interrupted. > > > > > Ersue, et al. Expires January 5, 2015 [Page 17] > Internet-Draft Constrained Management: Use Cases July 2014 > > > TW> I would remove "A" > o A distributed network monitoring, in which more than one > management station monitors or manages other routers. Because > connectivity to a server cannot be guaranteed at all times, a > distributed approach may provide a higher reliability, at the cost > of increased complexity. Currently, no IETF standard exists for > distributed monitoring and management. > > o Monitoring and management of a whole network or a group of > routers. Monitoring the performance of a community network may > require more information than what can be acquired from a single > router using a network management protocol. Statistics, such as > topology changes over time, data throughput along certain routing > paths, congestion etc., are of interest for a group of routers (or > TW> update to 2014? > the routing domain) as a whole. As of 2012, no IETF standard > allows for monitoring or managing whole networks, instead of > single routers. > > 3.10. Field Operations > > The challenges of configuration and monitoring of networks operated > in the field by rescue and security agencies can be different from > the other use cases since the requirements and operating conditions > of such networks are quite different. > > TW> typo: becomeing -> becoming > > With technology advancements, field networks operated nowadays are > becomeing large and can consist of varieties of different types of > equipment that run different protocols and tools that obviously > TW> "mission-critical"? > increase complexity of these mission critical networks. In many > scenarios, configurations are, most likely, manually performed. > Furthermore, some legacy and even modern devices do not even support > TW> "*A* majority"? > TW> proprietary*,* which > IP networking. Majority of protocols and tools developed by vendors > that are being used are proprietary which makes integration more > difficult. > > The main reason for this disjoint operation scenario is that most > equipment is developed with specific task requirements in mind, > rather than interoperability of the varied equipment types. For > example, the operating conditions experienced by high altitude > security equipment is significantly different from that used in > desert conditions. Similarly, search and rescue operations equipment > used in case of fire rescue has different requirements than flood > TW> "inter-operation"? > relief equipment. Furthermore, interoperation of equipment with > telecommunication equipment was not an expected outcome or in some > scenarios this may not even be desirable. > > Currently, field networks operate with a fixed Network Operations > Center (NOC) that physically manages the configuration and evaluation > of all field devices. Once configured, the devices might be deployed > > > > Ersue, et al. Expires January 5, 2015 [Page 18] > Internet-Draft Constrained Management: Use Cases July 2014 > > > in fixed or mobile scenarios. Any configuration changes required > would need to be appropriately encrypted and authenticated to prevent > unauthorized access. > > Hierarchical management of devices is a common requirement in such > scenarios since local managers or operators may need to respond to > changing conditions within their purview. The level of configuration > management available at each hierarchy must also be closely governed. > > Since many field operation devices are used in hostile environments, > a high failure and disconnection rate should be tolerated by the NMS, > which must also be able to deal with multiple gateways and disjoint > management protocols. > > TW> typo: invloving > TW> requiring the interoperation -> requiring inter-operation? > > Multi-national field operations invloving search, rescue and security > are becoming increasingly common, requiring the interoperation of a > diverse set of equipment designed with different operating conditions > in mind. Furthermore, different intra- and inter-governmental > agencies are likely to have a different set of standards, best > practices, rules and regulation, and implementation approaches that > may contradict or conflict with each other. The NMS should be able > to detect these and handle them in an acceptable manner, which may > require human intervention. > > 4. IANA Considerations > > This document does not introduce any new code-points or namespaces > for registration with IANA. > > Note to RFC Editor: this section may be removed on publication as an > RFC. > > 5. Security Considerations > > This document discusses use cases for Management of Networks with > Constrained Devices. The security considerations described > throughout the companion document [COM-REQ] apply here as well. > > 6. Contributors > > Following persons made significant contributions to and reviewed this > document: > > o Ulrich Herberg (Fujitsu Laboratories of America) contributed the > Section 3.9 on Community Network Applications. > > o Peter van der Stok contributed to Section 3.6 on Building > Automation. > > > > Ersue, et al. Expires January 5, 2015 [Page 19] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Zhen Cao contributed to Section 2.2 Cellular Access Technologies. > > o Gilman Tolle contributed the Section 3.4 on Automated Metering > Infrastructure. > > o James Nguyen and Ulrich Herberg contributed to Section 3.10 on > Military operations. > > 7. Acknowledgments > > Following persons reviewed and provided valuable comments to > different versions of this document: > > Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert > Greevenbosch, Ulrich Herberg, James Nguyen, Zach Shelby, and Peter > van der Stok. > > The editors would like to thank the reviewers and the participants on > the Coman maillist for their valuable contributions and comments. > > 8. Informative References > > [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc > Network (MANET) Neighborhood Discovery Protocol (NHDP)", > RFC 6130, April 2011. > > [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and > Application Spaces for IPv6 over Low-Power Wireless > Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. > > [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of > Managed Objects for the Neighborhood Discovery Protocol", > RFC 6779, October 2012. > > [RFC6988] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and > B. Claise, "Requirements for Energy Management", RFC 6988, > September 2013. > > [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, > "The Optimized Link State Routing Protocol Version 2", RFC > 7181, April 2014. > > [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for > Constrained-Node Networks", RFC 7228, May 2014. > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 20] > Internet-Draft Constrained Management: Use Cases July 2014 > > > [I-D.ietf-eman-framework] > Claise, B., Schoening, B., and J. Quittek, "Energy > Management Framework", draft-ietf-eman-framework-19 (work > in progress), April 2014. > > [COM-REQ] Ersue, M., Romascanu, D., and J. Schoenwaelder, > "Management of Networks with Constrained Devices: Problem > Statement and Requirements", draft-ietf-opsawg-coman- > probstate-reqs (work in progress), February 2014. > > Appendix A. Change Log > > A.1. draft-ietf-opsawg-coman-use-cases-01 - draft-ietf-opsawg-coman- > use-cases-02 > > o Renamed Mobile Access Technologies section to Cellular Access > Technologies > > o Changed references to mobile access technologies to now read > cellular access technologies. > > o Added text to the introduction to point out that the list of use > cases is not exhaustive since others unknown to the authors might > exist. > > o Updated references to take into account RFCs that have been now > published. > > o Updated Environmental Monitoring section to make it clear that in > some scenarios it may not be prudent to repair devices. > > o Added clarification in Infrastructure Monitoring section that > reliable communication is achieved via application layer > transactions > > o Removed reference to Energy Devices from Energy Management > section, instead labeling them as devices within the context of > energy management. > > o Reduced descriptive content in Energy Management section. > > o Rewrote text in Energy Management section to highlight management > characteristics of Smart Meter and AMI networks. > > o Added text regarding timely delivery of information, and related > management system characteristic, to the Medical Applications > section > > > > > Ersue, et al. Expires January 5, 2015 [Page 21] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Changed subnets to network segment in Building Automation section. > > o Changed structure to infrastructure in Building Automation > section, and added text to highlight associated deployment > difficulties. > > o Removed Trickle timer as example of common values to be set in > Building Automation section. > > o Added text regarding the possible availability of outsourced and > cloud based management systems for Home Automation. > > o Added text to Transport Applications section to highlight the > requirement of IT infrastructure for such applications to function > on top of. > > o Merged the Transport Applications and Vehicular Networks section > together. Following changes to the Vehicular Networks section > were merged back into Transport Applications > > * Replaced wireless last hops with wireless access to vehicles in > Vehicular Networks. > > * Expanded proprietary systems to "systems relying on a specific > Management Topology Option, as described in [COM-REQ]." within > Vehicular Networks section. > > * Added text regarding mobility patterns to Vehicular Networks. > > o Changed the Military Operations use case to Field Operations and > edited the text to be suitable to such scenarios. > > A.2. draft-ietf-opsawg-coman-use-cases-00 - draft-ietf-opsawg-coman- > use-cases-01 > > o Reordered some use cases to improve the flow. > > o Added "Vehicular Networks". > > o Shortened the Military Operations use case. > > o Started adding substance to the security considerations section. > > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 22] > Internet-Draft Constrained Management: Use Cases July 2014 > > > A.3. draft-ersue-constrained-mgmt-03 - draft-ersue-opsawg-coman-use- > cases-00 > > o Reduced the terminology section for terminology addressed in the > LWIG and Coman Requirements drafts. Referenced the other drafts. > > o Checked and aligned all terminology against the LWIG terminology > draft. > > o Spent some effort to resolve the intersection between the > Industrial Application, Home Automation and Building Automation > use cases. > > o Moved section section 3. Use Cases from the companion document > [COM-REQ] to this draft. > > o Reformulation of some text parts for more clarity. > > A.4. draft-ersue-constrained-mgmt-02-03 > > o Extended the terminology section and removed some of the > terminology addressed in the new LWIG terminology draft. > Referenced the LWIG terminology draft. > > o Moved Section 1.3. on Constrained Device Classes to the new LWIG > terminology draft. > > o Class of networks considering the different type of radio and > communication technologies in use and dimensions extended. > > o Extended the Problem Statement in Section 2. following the > requirements listed in Section 4. > > o Following requirements, which belong together and can be realized > with similar or same kind of solutions, have been merged. > > * Distributed Management and Peer Configuration, > > * Device status monitoring and Neighbor-monitoring, > > * Passive Monitoring and Reactive Monitoring, > > * Event-driven self-management - Self-healing and Periodic self- > management, > > * Authentication of management systems and Authentication of > managed devices, > > > > > Ersue, et al. Expires January 5, 2015 [Page 23] > Internet-Draft Constrained Management: Use Cases July 2014 > > > * Access control on devices and Access control on management > systems, > > * Management of Energy Resources and Data models for energy > management, > > * Software distribution (group-based firmware update) and Group- > based provisioning. > > o Deleted the empty section on the gaps in network management > standards, as it will be written in a separate draft. > > o Added links to mentioned external pages. > > o Added text on OMA M2M Device Classification in appendix. > > A.5. draft-ersue-constrained-mgmt-01-02 > > o Extended the terminology section. > > o Added additional text for the use cases concerning deployment > type, network topology in use, network size, network capabilities, > radio technology, etc. > > o Added examples for device classes in a use case. > > o Added additional text provided by Cao Zhen (China Mobile) for > Mobile Applications and by Peter van der Stok for Building > Automation. > > o Added the new use cases 'Advanced Metering Infrastructure' and > 'MANET Concept of Operations in Military'. > > o Added the section 'Managing the Constrainedness of a Device or > Network' discussing the needs of very constrained devices. > > o Added a note that the requirements in [COM-REQ] need to be seen as > standalone requirements and the current document does not > recommend any profile of requirements. > > o Added a section in [COM-REQ] for the detailed requirements on > constrained management matched to management tasks like fault, > monitoring, configuration management, Security and Access Control, > Energy Management, etc. > > o Solved nits and added references. > > o Added Appendix A on the related development in other bodies. > > > > Ersue, et al. Expires January 5, 2015 [Page 24] > Internet-Draft Constrained Management: Use Cases July 2014 > > > o Added Appendix B on the work in related research projects. > > A.6. draft-ersue-constrained-mgmt-00-01 > > o Splitted the section on 'Networks of Constrained Devices' into the > sections 'Network Topology Options' and 'Management Topology > Options'. > > o Added the use case 'Community Network Applications' and 'Mobile > Applications'. > > o Provided a Contributors section. > > o Extended the section on 'Medical Applications'. > > o Solved nits and added references. > > Authors' Addresses > > Mehmet Ersue (editor) > Nokia Networks > > Email: mehmet.ersue@nsn.com > > > Dan Romascanu > Avaya > > Email: dromasca@avaya.com > > > Juergen Schoenwaelder > Jacobs University Bremen > > Email: j.schoenwaelder@jacobs-university.de > > > Anuj Sehgal > Jacobs University Bremen > > Email: s.anuj@jacobs-university.de > > > > > > > > > > > Ersue, et al. Expires January 5, 2015 [Page 25] > >
- Re: [6tisch] Thomas's review of draft-ietf-opsawg… Thomas Watteyne