draft-ietf-opsawg-coman-probstate-reqs-00.txt		draft-ietf-opsawg-coman-probstate-reqs-01.txt
	Internet Engineering Task Force M. Ersue, Ed.		Internet Engineering Task Force M. Ersue, Ed.
	Internet-Draft Nokia Solutions and Networks		Internet-Draft Nokia Solutions and Networks
	Intended status: Informational D. Romascanu		Intended status: Informational D. Romascanu
	Expires: July 24, 2014 Avaya		Expires: August 18, 2014 Avaya
	J. Schoenwaelder		J. Schoenwaelder
	Jacobs University Bremen		Jacobs University Bremen
	January 20, 2014		February 14, 2014
	Management of Networks with Constrained Devices: Problem Statement and		Management of Networks with Constrained Devices: Problem Statement and
	Requirements		Requirements
	draft-ietf-opsawg-coman-probstate-reqs-00		draft-ietf-opsawg-coman-probstate-reqs-01
	Abstract		Abstract
	This document provides a problem statement, deployment and management		This document provides a problem statement, deployment and management
	topology options as well as the requirements for the management of		topology options as well as the requirements for the management of
	networks where constrained devices are involved.		networks where constrained devices are involved.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 24, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Networks Types and Characteristics in Focus . . . . . . . 5		1.3. Networks Types and Characteristics in Focus . . . . . . . 5
	1.4. Constrained Device Deployment Options . . . . . . . . . . 9		1.4. Constrained Device Deployment Options . . . . . . . . . . 9
	1.5. Management Topology Options . . . . . . . . . . . . . . . 9		1.5. Management Topology Options . . . . . . . . . . . . . . . 9
	1.6. Managing the Constrainedness of a Device or Network . . . 10		1.6. Managing the Constrainedness of a Device or Network . . . 10
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14		1.7. Configuration and Monitoring Functionality Levels . . . . 13
			2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15
	3. Requirements on the Management of Networks with		3. Requirements on the Management of Networks with
	Constrained Devices . . . . . . . . . . . . . . . . . . . . . 16		Constrained Devices . . . . . . . . . . . . . . . . . . . . . 17
	3.1. Management Architecture/System . . . . . . . . . . . . . . 16		3.1. Management Architecture/System . . . . . . . . . . . . . . 17
	3.2. Management protocols and data model . . . . . . . . . . . 21		3.2. Management protocols and data model . . . . . . . . . . . 22
	3.3. Configuration management . . . . . . . . . . . . . . . . . 24		3.3. Configuration management . . . . . . . . . . . . . . . . . 25
	3.4. Monitoring functionality . . . . . . . . . . . . . . . . . 26		3.4. Monitoring functionality . . . . . . . . . . . . . . . . . 27
	3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 31		3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 32
	3.6. Security and Access Control . . . . . . . . . . . . . . . 32		3.6. Security and Access Control . . . . . . . . . . . . . . . 33
	3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 34		3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 35
	3.8. SW Distribution . . . . . . . . . . . . . . . . . . . . . 36		3.8. SW Distribution . . . . . . . . . . . . . . . . . . . . . 37
	3.9. Traffic management . . . . . . . . . . . . . . . . . . . . 36		3.9. Traffic management . . . . . . . . . . . . . . . . . . . . 37
	3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 38		3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 39
	3.11. Implementation Requirements . . . . . . . . . . . . . . . 39		3.11. Implementation Requirements . . . . . . . . . . . . . . . 41
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 42		5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 45		8.1. Normative References . . . . . . . . . . . . . . . . . . . 47
	8.2. Informative References . . . . . . . . . . . . . . . . . . 45		8.2. Informative References . . . . . . . . . . . . . . . . . . 47
	Appendix A. Related Development in other Bodies . . . . . . . . . 47		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 48
	A.1. ETSI TC M2M . . . . . . . . . . . . . . . . . . . . . . . 47		A.1. draft-ietf-opsawg-coman-probstate-reqs-00 -
	A.2. OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . 48		draft-ietf-opsawg-coman-probstate-reqs-01 . . . . . . . . 48
	A.3. OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 49		A.2. draft-ersue-constrained-mgmt-03 -
	A.4. IPSO Alliance . . . . . . . . . . . . . . . . . . . . . . 49		draft-ietf-opsawg-coman-probstate-reqs-00 . . . . . . . . 48
	Appendix B. Related Research Projects . . . . . . . . . . . . . . 51		A.3. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . . 49
	Appendix C. Open issues . . . . . . . . . . . . . . . . . . . . . 52		A.4. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . . 50
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53		A.5. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . . 50
	D.1. draft-ersue-constrained-mgmt-03 -		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
	draft-ersue-opsawg-coman-probstate-reqs-00 . . . . . . . . 53
	D.2. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . . 53
	D.3. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . . 54
	D.4. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	Small devices with limited CPU, memory, and power resources, so		Constrained devices, aka. sensor, smart object, or smart device, with
	called constrained devices (aka. sensor, smart object, or smart		limited CPU, memory, and power resources, can constitute a network.
	device) can constitute a network. Such a network of constrained		Such a network of constrained devices itself may be constrained or
	devices itself may be constrained or challenged, e.g. with unreliable		challenged, e.g. with unreliable or lossy channels, wireless
	or lossy channels, wireless technologies with limited bandwidth and a		technologies with limited bandwidth and a dynamic topology, needing
	dynamic topology, needing the service of a gateway or proxy to		the service of a gateway or proxy to connect to the Internet. In
	connect to the Internet. In other scenarios, the constrained devices		other scenarios, the constrained devices can be connected to a non-
	can be connected to a non-constrained network using off-the-shelf		constrained network using off-the-shelf protocol stacks.
	protocol stacks.
	Constrained devices might be in charge of gathering information in		Constrained devices might be in charge of gathering information in
	diverse settings including natural ecosystems, buildings, and		diverse settings including natural ecosystems, buildings, and
	factories and send the information to one or more server stations.		factories and send the information to one or more server stations.
	Constrained devices may work under severe resource constraints such		Constrained devices may also work under severe resource constraints
	as limited battery and computing power, little memory and		such as limited battery and computing power, little memory and
	insufficient wireless bandwidth, and communication capabilities. A		insufficient wireless bandwidth, and communication capabilities. A
	central entity, e.g., a base station or controlling server, might		central entity, e.g., a base station or controlling server, might
	have more computational and communication resources and can act as a		have more computational and communication resources and can act as a
	gateway between the constrained devices and the application logic in		gateway between the constrained devices and the application logic in
	the core network.		the core network.
	Today diverse size of small devices with different resources and		Today diverse size of constrained devices with different resources
	capabilities are being connected. Mobile personal gadgets, building-		and capabilities are being connected. Mobile personal gadgets,
	automation devices, cellular phones, Machine-to-machine (M2M)		building-automation devices, cellular phones, Machine-to-machine
	devices, etc. benefit from interacting with other "things" in the		(M2M) devices, etc. benefit from interacting with other "things" in
	near or somewhere in the Internet. With this the Internet of Things		the near or somewhere in the Internet. With this the Internet of
	(IoT) becomes a reality build up of uniquely identifiable objects		Things (IoT) becomes a reality build up of uniquely identifiable
	(things). And over the next decade, this could grow to trillions of		objects (things). And over the next decade, this could grow to
	constrained devices and will greatly increase the Internet's size and		trillions of constrained devices and will greatly increase the
	scope.		Internet's size and scope.
	Network management is characterized by monitoring network status,		Network management is characterized by monitoring network status,
	detecting faults, and inferring their causes, setting network		detecting faults, and inferring their causes, setting network
	parameters, and carrying out actions to remove faults, maintain		parameters, and carrying out actions to remove faults, maintain
	normal operation, and improve network efficiency and application		normal operation, and improve network efficiency and application
	performance. The traditional network management application		performance. The traditional network management application
	periodically collects information from a set of elements that are		periodically collects information from a set of elements that are
	needed to manage, processes the data, and presents them to the		needed to manage, processes the data, and presents them to the
	network management users. Constrained devices, however, often have		network management users. Constrained devices, however, often have
	limited power, low transmission range, and might be unreliable. They		limited power, low transmission range, and might be unreliable. They
	might also need to work in hostile environments with advanced		might also need to work in hostile environments with advanced
	security requirements or need to be used in harsh environments for a		security requirements or need to be used in harsh environments for a
	long time without supervision. Due to such constraints, the		long time without supervision. Due to such constraints, the
	management of a network with constrained devices offers different		management of a network with constrained devices offers different
	type of challenges compared to the management of a traditional IP		type of challenges compared to the management of a traditional IP
	network.		network.
	The IETF has already done a lot of standardization work to enable the		The IETF has already done substantial standardization work to enable
	communication in IP networks and to manage such networks as well as		the communication in IP networks and to manage such networks as well
	the manifold type of nodes in these networks [RFC6632]. However, the		as the manifold type of nodes in these networks [RFC6632]. However,
	IETF so far has not developed any specific technologies for the		the IETF so far has not developed any specific technologies for the
	management of constrained devices and the networks comprised by		management of constrained devices and the networks comprised by
	constrained devices. IP-based sensors or constrained devices in such		constrained devices. IP-based sensors or constrained devices in such
	an environment, i.e., devices with very limited memory and CPU		an environment, i.e., devices with very limited memory and CPU
	resources, use today application-layer protocols in an ad-hoc manner		resources, use today application-layer protocols in an ad-hoc manner
	to do simple resource management and monitoring.		to do simple resource management and monitoring.
	This document provides a problem statement and lists the requirements		This document provides a problem statement and lists the requirements
	for the management of a network with constrained devices.		for the management of a network with constrained devices.
	Section 1.3 and Section 1.5 describe different topology options for		Section 1.3 and Section 1.5 describe different topology options for
	the networking and management of constrained devices. Section 2		the networking and management of constrained devices. Section 2
	provides a problem statement on the issue of the management of		provides a problem statement on the issue of the management of
	networked constrained devices. Section 3 lists requirements on the		networked constrained devices. Section 3 lists requirements on the
	management of applications and networks with constrained devices.		management of applications and networks with constrained devices.
	Note that the requirements in Section 3 need to be seen as standalone		Note that the requirements in Section 3 need to be seen as
	requirements, where different implementer may decide to realize a		standalone, where different implementer may decide to realize a
	different set of them.		different set of requirements.
	The use cases in the context of networks with constrained devices can		The use cases in the context of networks with constrained devices can
	be found in the companion document [COM-US].		be found in the companion document [COM-USE].
	1.2. Terminology		1.2. Terminology
	Concerning constrained devices and networks this document generally		Concerning constrained devices and networks this document generally
	builds on the terminology defined in [I-D.ietf-lwig-terminology],		builds on the terminology defined in [I-D.ietf-lwig-terminology],
	where the terms Constrained Device, Constrained Network, etc. are		where the terms Constrained Device, Constrained Network, etc. are
	defined.		defined.
	The following terms are additionally used throughout this		The following terms are additionally used throughout this
	documentation:		documentation:
	skipping to change at page 5, line 44		skipping to change at page 5, line 44
	[I-D.ietf-lwig-terminology].		[I-D.ietf-lwig-terminology].
	1.3. Networks Types and Characteristics in Focus		1.3. Networks Types and Characteristics in Focus
	In this document we differentiate following type of networks		In this document we differentiate following type of networks
	concerning their transport and communication technologies:		concerning their transport and communication technologies:
	Note that a network in general can involve constrained and non-		Note that a network in general can involve constrained and non-
	constrained devices.		constrained devices.
	1. Wireline non-constrained networks, e.g. an Ethernet-LAN with non-		1. Wireline non-constrained networks, e.g. an Ethernet-LAN with
	constrained and constrained devices involved.		constrained and non-constrained devices involved.
	2. A combination of wireline and wireless networks, which may or may		2. A combination of wireline and wireless networks, which may or may
	not be mesh-based but have a multi-hop connectivity between		not be mesh-based but have a multi-hop connectivity between
	constrained devices, utilizing dynamic routing in both the		constrained devices, utilizing dynamic routing in both the
	wireless and wireline portions of the network. Such networks		wireless and wireline portions of the network. Such networks
	usually support highly distributed applications with many nodes		usually support highly distributed applications with many nodes
	(e.g. environmental monitoring) and tend to deal with large-scale		(e.g. environmental monitoring) and tend to deal with large-scale
	multipoint-to-point systems with massive data flows. Wireless		multipoint-to-point systems with massive data flows. Wireless
	Mesh Networks (WMN), as a specific variant, use off-the-shelf		Mesh Networks (WMN), as a specific variant, use off-the-shelf
	radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. WMNs		radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. WMNs
	skipping to change at page 6, line 23		skipping to change at page 6, line 23
	hop connectivity to constrained devices, utilizing static routing		hop connectivity to constrained devices, utilizing static routing
	over the wireless network. Such networks support short-range,		over the wireless network. Such networks support short-range,
	point-to-point, low-data-rate, source-to-sink type of		point-to-point, low-data-rate, source-to-sink type of
	applications such as RFID systems, light switches, fire and smoke		applications such as RFID systems, light switches, fire and smoke
	detectors, and home appliances. This type of networks also		detectors, and home appliances. This type of networks also
	support confined short-range spaces such as a home, a factory, a		support confined short-range spaces such as a home, a factory, a
	building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE		building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE
	802.15.4 are well-known examples of applicable standards for such		802.15.4 are well-known examples of applicable standards for such
	networks.		networks.
	4. Mobile Adhoc networks (MANET) are self-configuring		4. Self-configuring infrastructureless networks of mobile devices
	_infrastructureless_ networks of mobile devices connected by		(e.g. Mobile Adhoc networks, MANET) are a particular type of
	wireless technologies. MANETs are based on point-to-point		network connected by wireless technologies. Infrastructureless
	communications of devices moving independently in any direction		networks are mostly based on point-to-point communications of
	and changing the links to other devices frequently. MANET		devices moving independently in any direction and changing the
	devices do act as a router to forward traffic unrelated to their		links to other devices frequently. Such devices do act as a
	own use.		router to forward traffic unrelated to their own use.
	Wireline non-constrained networks are mainly used for specific		Wireline non-constrained networks with constrained and non-
	applications like Building Automation or Infrastructure Monitoring.		constrained devices are mainly used for specific applications like
	However, wireline and wireless networks with multi-hop or point-to-		Building Automation or Infrastructure Monitoring. Wireline and
	multipoint connectivity are especially in the interest of the		wireless networks with multi-hop or point-to-multipoint connectivity
	analysis on the management of constrained devices in this document.		are used e.g. for environmental monitoring as well as transport and
			mobile applications.
	Furthermore different network characteristics are determined by		Furthermore different network characteristics are determined by
	multiple dimensions: dynamicity of the topology, bandwidth, and loss		multiple dimensions: dynamicity of the topology, bandwidth, and loss
	rate. In the following, each dimension is explained, and networks in		rate. In the following, each dimension is explained, and networks in
	scope for this document are outlined:		scope for this document are outlined:
	Network Topology:		Network Topology:
	The topology of a network can be represented as a graph, with edges		The topology of a network can be represented as a graph, with edges
	(i.e., links) and vertices (routers and hosts). Examples of		(i.e., links) and vertices (routers and hosts). Examples of
	skipping to change at page 7, line 13		skipping to change at page 7, line 14
	network), mesh topologies (fully distributed), etc.		network), mesh topologies (fully distributed), etc.
	Management protocols may take advantage of specific network		Management protocols may take advantage of specific network
	topologies, for example by distributing large-scale management tasks		topologies, for example by distributing large-scale management tasks
	amongst multiple distributed network management stations (e.g., in		amongst multiple distributed network management stations (e.g., in
	case of a mesh topology), or by using a hierarchical management		case of a mesh topology), or by using a hierarchical management
	approach (e.g., in case of a tree topology). These different		approach (e.g., in case of a tree topology). These different
	management topology options are described in Section 1.6.		management topology options are described in Section 1.6.
	Note that in certain network deployments, such as community ad hoc		Note that in certain network deployments, such as community ad hoc
	networks (see the use case "Community Network Applications" in		networks (see the use case "Community Network Applications" in [COM-
	[COM-US]), the topology is not pre-planned, and thus may be unknown		USE]), the topology is not pre-planned, and thus may be unknown for
	for management purposes. In other use cases, such as industrial		management purposes. In other use cases, such as industrial
	applications (see the use case "Industrial Applications" in		applications (see the use case "Industrial Applications" in [COM-
	[COM-US]), the topology may be designed in advance and therefore		USE]), the topology may be designed in advance and therefore taken
	taken advantage of when managing the network.		advantage of when managing the network.
	Dynamicity of the network topology:		Dynamicity of the network topology:
	The dynamicity of the network topology determines the rate of change		The dynamicity of the network topology determines the rate of change
	of the graph per time. Such changes can occur due to different		of the graph per time. Such changes can occur due to different
	factors, such as mobility of nodes (e.g., in MANETs or cellular		factors, such as mobility of nodes (e.g., in MANETs or cellular
	networks), duty cycles (for low-power devices enabling their network		networks), duty cycles (for low-power devices enabling their network
	interface only periodically to transmit or receive packets), or		interface only periodically to transmit or receive packets), or
	unstable links (in particular wireless links with strongly		unstable links (in particular wireless links with strongly
	fluctuating link quality).		fluctuating link quality).
	skipping to change at page 7, line 46		skipping to change at page 7, line 47
	The more the topology is dynamic, the more routing, transport and		The more the topology is dynamic, the more routing, transport and
	application layer protocols have to cope with interrupted		application layer protocols have to cope with interrupted
	connectivity and/or longer delays. For example, management protocols		connectivity and/or longer delays. For example, management protocols
	(with a given underlying transport protocol) that expect continuous		(with a given underlying transport protocol) that expect continuous
	session flows without changes of routes during a communication flow,		session flows without changes of routes during a communication flow,
	may fail to operate.		may fail to operate.
	Networks with a very low dynamicity (e.g. Ethernet) with no or		Networks with a very low dynamicity (e.g. Ethernet) with no or
	infrequent topology changes (e.g. less than once every 30 minutes),		infrequent topology changes (e.g. less than once every 30 minutes),
	are in-scope of this document if they are used with constrained		are in-scope of this document if they are used with constrained
	devices (see e.g. the use case "Building Automation" in [COM-US]).		devices (see e.g. the use case "Building Automation" in [COM-USE]).
	Traffic flows:		Traffic flows:
	The traffic flow in a network determines from which sources data		The traffic flow in a network determines from which sources data
	traffic is sent to which destinations in the network. Several		traffic is sent to which destinations in the network. Several
	different traffic flows are defined in [I-D.ietf-roll-terminology],		different traffic flows are defined in [RFC7102], including "point-
	including "point-to-point" (P2P), "multipoint-to-point" (MP2P), and		to-point" (P2P), "multipoint-to-point" (MP2P), and "point-to-
	"point-to-multipoint" (P2MP) flows as:		multipoint" (P2MP) flows as:
	o P2P: Point To Point. This refers to traffic exchanged between two		o P2P: Point To Point. This refers to traffic exchanged between two
	nodes (regardless of the number of hops between the two nodes).		nodes (regardless of the number of hops between the two nodes).
	o P2MP: Point-to-Multipoint traffic refers to traffic between one		o P2MP: Point-to-Multipoint traffic refers to traffic between one
	node and a set of nodes. This is similar to the P2MP concept in		node and a set of nodes. This is similar to the P2MP concept in
	Multicast or MPLS Traffic Engineering.		Multicast or MPLS Traffic Engineering.
	o MP2P: Multipoint-to-Point is used to describe a particular traffic		o MP2P: Multipoint-to-Point is used to describe a particular traffic
	pattern (e.g. MP2P flows collecting information from many nodes		pattern (e.g. MP2P flows collecting information from many nodes
	skipping to change at page 8, line 44		skipping to change at page 8, line 46
	For management purposes, the management protocol typically requires		For management purposes, the management protocol typically requires
	to send information between the network management station and the		to send information between the network management station and the
	clients, for monitoring or control purposes. If the available		clients, for monitoring or control purposes. If the available
	bandwidth is insufficient for the management protocol, packets will		bandwidth is insufficient for the management protocol, packets will
	be buffered and eventually dropped, and thus management is not		be buffered and eventually dropped, and thus management is not
	possible with such a protocol.		possible with such a protocol.
	Networks without bandwidth limitation (e.g. Ethernet) are in-scope		Networks without bandwidth limitation (e.g. Ethernet) are in-scope
	of this document if they are used with constrained devices (see the		of this document if they are used with constrained devices (see the
	use case "Building Automation" in [COM-US]).		use case "Building Automation" in [COM-USE]).
	Loss rate:		Loss rate:
	The loss rate (or bit error rate) is the number of bit errors divided		The loss rate (or bit error rate) is the number of bit errors divided
	by the total number of bits transmitted. For wired networks, loss		by the total number of bits transmitted. For wired networks, loss
	rates are typically extremely low, e.g. around 10^-12 or 10^-13 for		rates are typically extremely low, e.g. around 10^-12 or 10^-13 for
	the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4,		the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4,
	the bit error rate can be as high as 10^-1 to 10^-0 in case of		the bit error rate can be as high as 10^-1 to 10^-0 in case of
	interferences.Even when using a reliable transport protocol,		interferences.Even when using a reliable transport protocol,
	management operations can fail if the loss rate is too high, unless		management operations can fail if the loss rate is too high, unless
	they are specifically designed to cope with these situations.		they are specifically designed to cope with these situations.
	Note: The discussion on the management requirements of MANETs is
	currently not in the focus of this document. [COM-US] provides a use
	case to make it clear how a MANET-based application differs from
	others.
	1.4. Constrained Device Deployment Options		1.4. Constrained Device Deployment Options
	We differentiate following Deployment options for the constrained		We differentiate following deployment options for the constrained
	devices:		devices:
	o a network of constrained devices, which communicate with each		o a network of constrained devices, which communicate with each
	other,		other,
	o Constrained devices, which are connected directly to the Internet		o Constrained devices, which are connected directly to the Internet
	or an IP network		or an IP network
	o A network of constrained devices which communicate with a gateway		o A network of constrained devices which communicate with a gateway
	or proxy with more communication capabilities acting possibly as a		or proxy with more communication capabilities acting possibly as a
	skipping to change at page 10, line 7		skipping to change at page 10, line 5
	We differentiate following options for the management of networks of		We differentiate following options for the management of networks of
	constrained devices:		constrained devices:
	o A network of constrained devices managed by one central manager.		o A network of constrained devices managed by one central manager.
	A logically centralized management might be implemented in a		A logically centralized management might be implemented in a
	hierarchical fashion for scalability and robustness reasons. The		hierarchical fashion for scalability and robustness reasons. The
	manager and the management application logic might have a gateway/		manager and the management application logic might have a gateway/
	proxy in between or might be on different nodes in different		proxy in between or might be on different nodes in different
	networks, e.g., management application running on a cloud server.		networks, e.g., management application running on a cloud server.
	o Distributed management, where a constrained network is managed by		o Distributed management, where a network of constrained devices is
	more than one manager. Each manager controls a subnetwork and may		managed by more than one manager. Each manager controls a
	communicate directly with other manager stations in a cooperative		subnetwork and may communicate directly with other manager
	fashion. The distributed management may be weakly distributed,		stations in a cooperative fashion. The distributed management may
	where functions are broken down and assigned to many managers		be weakly distributed, where functions are broken down and
	dynamically, or strongly distributed, where almost all managed		assigned to many managers dynamically, or strongly distributed,
	things have embedded management functionality and explicit		where almost all managed things have embedded management
	management disappears, which usually comes with the price that the		functionality and explicit management disappears, which usually
	strongly distributed management logic now needs to be managed.		comes with the price that the strongly distributed management
			logic now needs to be managed.
	o Hierarchical management, where a hierarchy of constrained networks		o Hierarchical management, where a hierarchy of networks with
	are managed by the managers at their corresponding hierarchy		constrained devices are managed by the managers at their
	level. I.e. each manager is responsible for managing the nodes in		corresponding hierarchy level. I.e. each manager is responsible
	its sub-network. It passes information from its sub-network to		for managing the nodes in its sub-network. It passes information
	its higher-level manager, and disseminates management functions		from its sub-network to its higher-level manager, and disseminates
	received from the higher-level manager to its sub-network.		management functions received from the higher-level manager to its
	Hierarchical management is essentially a scalability mechanism,		sub-network. Hierarchical management is essentially a scalability
	logically the decision-making may be still centralized.		mechanism, logically the decision-making may be still centralized.
	1.6. Managing the Constrainedness of a Device or Network		1.6. Managing the Constrainedness of a Device or Network
	The capabilities of a constrained device or network and the		The capabilities of a constrained device or network and the
	constrainedness thereof influence and have an impact on the		constrainedness thereof influence and have an impact on the
	requirements for the management of such network or devices.		requirements for the management of such network or devices.
	A constrained device:		A constrained device:
	o might only support an unreliable radio with lossy links, i.e. the		o might only support an unreliable radio with lossy links, i.e. the
	client and server of a management protocol need to gracefully		client and server of a management protocol need to gracefully
	ignore incomplete commands or repeat commands as necessary.		ignore incomplete commands or repeat commands as necessary.
	o might only be able to go online from time-to-time, where it is		o might only be able to go online from time-to-time, where it is
	reachable, i.e. a command might be necessary to repeat after a		reachable, i.e. a command might be necessary to repeat after a
	longer timeout or the timeout value with which one endpoint waits		longer timeout or the timeout value with which one endpoint waits
	on a response needs to be sufficiently high.		on a response needs to be sufficiently high.
	o might only be able to support a limited operating time (e.g. based		o might only be able to support a limited operating time (e.g. based
	on the available battery), i.e. the devices need to economize		on the available battery), or may behave as 'sleepy endpoints'
	their energy usage with suitable mechanisms and the managing		setting their network links to a disconnected state during long
	entity needs to monitor and control the energy status of the		periods of time i.e. the devices need to economize their energy
	constrained devices it manages.		usage with suitable mechanisms and the managing entity needs to
			monitor and control the energy status of the constrained devices
			it manages.
	o might only be able to support one simple communication protocol,		o might only be able to support one simple communication protocol,
	i.e. the management protocol needs to be possible to downscale		i.e. the management protocol needs to be possible to downscale
	from constrained (C2) to very constrained (C0) devices with		from constrained (C2) to very constrained (C0) devices with
	modular implementation and a very basic version with just a few		modular implementation and a very basic version with just a few
	simple commands.		simple commands.
	o might only be able to support limited or no user and/or transport		o might only be able to support limited or no user and/or transport
	security, i.e. the management system needs to support a less-		security, i.e. the management system needs to support a less-
	costly and simple but sufficiently secure authentication		costly and simple but sufficiently secure authentication
	mechanism.		mechanism.
	o might not be able to support compression and decompression of		o might not be able to support compression and decompression of
	exchanged data based on limited CPU power, i.e. an intermediary		exchanged data based on limited CPU power, i.e. an intermediary
	entity which is capable of data compression should be able to		entity which is capable of data compression should be able to
	communicate with both, devices, which support data compression		communicate with both, devices, which support data compression
	(e.g. C2) and devices, which do not support data compression		(e.g. C2) and devices, which do not support data compression
	(e.g. C1 and C0).		(e.g. C1 and C0).
	o might only be able to support very simple encryption, i.e. it		o might only be able to support a simple encryption, i.e. it would
	would be efficient if the devices use cryptographic algorithms		be beneficial if the devices use cryptographic algorithms that are
	that are supported in hardware.		supported in hardware and the encryption used is efficient in
			terms of memeory and CPU usage.
	o might only be able to communicate with one single managing entity		o might only be able to communicate with one single managing entity
	and cannot support the parallel access of many managing entities.		and cannot support the parallel access of many managing entities.
	o might depend on a self-configuration feature, i.e. the managing		o might depend on a self-configuration feature, i.e. the managing
	entity might not know all devices in a network and the device		entity might not know all devices in a network and the device
	needs to be able to initiate connection setup for the device		needs to be able to initiate connection setup for the device
	configuration.		configuration.
	o might depend on self- or neighbor-monitoring feature, i.e. the		o might depend on self- or neighbor-monitoring feature, i.e. the
	skipping to change at page 12, line 11		skipping to change at page 12, line 14
	o might only be able to support a limited set of notifications,		o might only be able to support a limited set of notifications,
	possible only an "I-am-alive" message.		possible only an "I-am-alive" message.
	o might only be able to support a soft-reset from failure recovery.		o might only be able to support a soft-reset from failure recovery.
	o might possibly generate a huge amount of redundant reporting data,		o might possibly generate a huge amount of redundant reporting data,
	i.e. the intermediary management entity (see [I-D.ietf-core-coap])		i.e. the intermediary management entity (see [I-D.ietf-core-coap])
	should be able to filter and aggregate redundant data.		should be able to filter and aggregate redundant data.
	A constrained network:		A network of constrained devices:
	o might only support an unreliable radio with lossy links, i.e. the		o might only support an unreliable radio with lossy links, i.e. the
	client and server of a management protocol need to repeat commands		client and server of a management protocol need to repeat commands
	as necessary or gracefully ignore incomplete commands.		as necessary or gracefully ignore incomplete commands.
	o might be necessary to manage based on multicast communication,		o might be necessary to manage based on multicast communication,
	i.e. the managing entity needs to be prepared to configure many		i.e. the managing entity needs to be prepared to configure many
	devices at once based on the same data model.		devices at once based on the same data model.
	o might have a very large topology supporting 10.000 or more nodes		o might have a very large topology supporting 10.000 or more nodes
	skipping to change at page 13, line 13		skipping to change at page 13, line 14
	used to provide fault tolerance.		used to provide fault tolerance.
	o might require new management capabilities: for example, network		o might require new management capabilities: for example, network
	coverage information and a constrained device power-distribution-		coverage information and a constrained device power-distribution-
	map.		map.
	o might require a new management function for data management, since		o might require a new management function for data management, since
	the type and amount of data collected in constrained networks is		the type and amount of data collected in constrained networks is
	different from those of the traditional networks.		different from those of the traditional networks.
	o might also need energy-efficient key management algorithms for		o might also need energy-efficient key management.
	security.
			1.7. Configuration and Monitoring Functionality Levels
			Devices often differ significantly on the level of configuration
			management support they provide. The configuration management
			functionality levels can be broadly classified as follows:
			CL0: Devices are pre-configured and allow no runtime configuration
			changes. Configuration parameters are often hard coded and
			compiled directly into the firmware image.
			CL1: Devices have explicit configuration objects. However, changes
			require a restart of the device to take effect.
			CL2: Devices allow management systems to replace the entire
			configuration (or pre-determined subsets) in bulk. Configuration
			changes take effect by soft-restarts of the system (or
			subsystems).
			CL3: Devices allow management systems to modify configuration
			objects without bulk replacements and changes take effect
			immediately.
			CL4: Devices support multiple configuration datastores and they
			might distinguish between the currently running and the next
			startup configuration.
			CL5: Devices support configuration datastore locking and device-
			local configuration change transactions, i.e., either all
			configuration changes are applied or none of them.
			CL6: Devices support configuration change transactions across
			devices.
			Devices often also provide different levels of monitoring support:
			ML0: Devices push pre-defined monitoring data.
			ML1: Devices allow management systems to pull pre-defined monitoring
			data.
			ML2: Devices allow management systems to pull user-defined filtered
			subsets of monitoring data.
			ML3: Devices are able to locally process monitoring data in order to
			detect threshold crossings or to aggregate data.
			Constrained devices often implement a combination of one of FL0-FL2
			with one of ML0-ML1.
	2. Problem Statement		2. Problem Statement
	The terminology for the "Internet of Things" is still nascent, and		The terminology for the "Internet of Things" is still nascent, and
	depending on the network type or layer in focus diverse technologies		depending on the network type or layer in focus diverse technologies
	and terms are in use. Common to all these considerations is the		and terms are in use. Common to all these considerations is the
	"Things" or "Objects" are supposed to have physical or virtual		"Things" or "Objects" are supposed to have physical or virtual
	identities using interfaces to communicate. In this context, we need		identities using interfaces to communicate. In this context, we need
	to differentiate between the Constrained and Smart Devices identified		to differentiate between the Constrained and Smart Devices identified
	by an IP address compared to virtual entities such as Smart Objects,		by an IP address compared to virtual entities such as Smart Objects,
	which can be identified as a resource or a virtual object by using a		which can be identified as a resource or a virtual object by using a
	unique identifier. Furthermore, the smart devices usually have a		unique identifier. Furthermore, the smart devices usually have a
	limited memory and CPU power as well as aim to be self-configuring		limited memory and CPU power as well as aim to be self-configuring
	and easy to deploy.		and easy to deploy.
	However, the tininess of the network nodes requires a rethinking of		However, the constraints of the network nodes requires a rethinking
	the protocol characteristics concerning power consumption,		of the protocol characteristics concerning power consumption,
	performance, memory, and CPU usage. As such, there is a demand for		performance, memory, and CPU usage. As such, there is a demand for
	protocol simplification, energy-efficient communication, less CPU		protocol simplification, energy-efficient communication, less CPU
	usage and small memory footprint.		usage and small memory footprint.
	On the application layer the IETF is already developing protocols		On the application layer the IETF is already developing protocols
	like the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap]		like the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap]
	supporting constrained devices and networks e.g., for smart energy		enabling the communication of constrained devices and networks e.g.,
	applications or home automation environments. The deployment of such		for smart energy applications or home automation environments. The
	an environment involves in fact many, in some scenarios up to million		deployment of such an environment involves in fact many, in some
	small devices (e.g. smart meters), which produce a huge amount of		scenarios up to million constrained devices (e.g. smart meters),
	data. This data needs to be collected, filtered, and pre-processed		which produce a huge amount of data. This data needs to be
	for further use in diverse services.		collected, filtered, and pre-processed for further use in diverse
			services.
	Considering the high number of nodes to deploy, one has to think on		Considering the high number of nodes to deploy, one has to think on
	the manageability aspects of the smart devices and plan for easy		the manageability aspects of the smart devices and plan for easy
	deployment, configuration, and management of the networks of		deployment, configuration, and management of the networks of
	constrained devices as well as the devices themselves. Consequently,		constrained devices as well as the devices themselves. Consequently,
	seamless monitoring and self-configuration of such network nodes		seamless monitoring and self-configuration of such network nodes
	becomes more and more imperative. Self-configuration and self-		becomes more and more imperative. Self-configuration and self-
	management is already a reality in the standards of some of the		management is already a reality in the standards of some of the
	bodies such as 3GPP. To introduce self-configuration of smart		bodies such as 3GPP. To introduce self-configuration of smart
	devices successfully a device-initiated connection establishment is		devices successfully a device-initiated connection establishment is
	required.		required.
	A simple application layer protocol, such as CoAP, is essential to		A simple and efficient application layer protocol, such as CoAP, is
	address the issue of efficient object-to-object communication and		essential to address the issue of efficient object-to-object
	information exchange. Such an information exchange should be done		communication and information exchange. Such an information exchange
	based on interoperable data models to enable the exchange and		should be done based on interoperable data models to enable the
	interpretation of diverse application and management related data.		exchange and interpretation of diverse application and management
			related data.
	In an ideal world, we would have only one network management protocol		In an ideal world, we would have only one network management protocol
	for monitoring, configuration, and exchanging management data,		for monitoring, configuration, and exchanging management data,
	independently of the type of the network (e.g., Smart Grid, wireless		independently of the type of the network (e.g., Smart Grid, wireless
	access, or core network). Furthermore, it would be desirable to		access, or core network). Furthermore, it would be desirable to
	derive the basic data models for constrained devices from the core		derive the basic data models for constrained devices from the core
	models used today to enable reuse of functionality and end-to-end		models used today to enable reuse of functionality and end-to-end
	information exchange. However, the current management protocols seem		information exchange. However, the current management protocols seem
	to be too heavyweight compared to the capabilities the constrained		to be too heavyweight compared to the capabilities the constrained
	devices have and are not applicable directly for the use in a network		devices have and are not applicable directly for the use in a network
	skipping to change at page 15, line 29		skipping to change at page 16, line 32
	resource management and monitoring. This might be sufficient for		resource management and monitoring. This might be sufficient for
	some basic cases, however, there is a need to reconsider the network		some basic cases, however, there is a need to reconsider the network
	management mechanisms based on the new, changed, as well as reduced		management mechanisms based on the new, changed, as well as reduced
	requirements coming from smart devices and the network of such		requirements coming from smart devices and the network of such
	constrained devices. Albeit it is questionable whether we can take		constrained devices. Albeit it is questionable whether we can take
	the same comprehensive approach we use in an IP network also for the		the same comprehensive approach we use in an IP network also for the
	management of constrained devices. Hence, the management of a		management of constrained devices. Hence, the management of a
	network with constrained devices is necessary to design in a		network with constrained devices is necessary to design in a
	simplified and less complex manner.		simplified and less complex manner.
	As the Section 1.6 highlights, there are diverse characterists of		As Section 1.6 highlights, there are diverse characterists of
	constrained devices or networks, which stem from their constraindness		constrained devices or networks, which stem from their
	and therefor have an impact on the requirements for the management of		constrainedness and therefore have an impact on the requirements for
	such a network with constrained devices. The use cases discussed in		the management of such a network with constrained devices. The use
	[COM-US] show that the requirements on constrained networks are		cases discussed in [COM-USE] show that the requirements on
	manifold and need to be analyzed from different angles, e.g.		constrained networks are manifold and need to be analyzed from
	concerning the design of the management architecture, the selection		different angles, e.g. concerning the design of the management
	of the appropriate protocol features as well as the specific issues		architecture, the selection of the appropriate protocol features as
	which are new in the context of constrained devices. Examples of		well as the specific issues which are new in the context of
	such issues are e.g. the careful management of the scarce energy		constrained devices. Examples of such issues are e.g. the careful
	resources, the necessity for self-organization and self-management of		management of the scarce energy resources, the necessity for self-
	such devices but also the implementation considerations to enable the		organization and self-management of such devices but also the
	use of common communication technologies on a constrained hardware in		implementation considerations to enable the use of common
	an efficient manner. For an exhaustive list of issues and		communication technologies on a constrained hardware in an efficient
	requirements, which need to be addressed for the management of a		manner. For an exhaustive list of issues and requirements, which
	network with constrained devices please see Section 1.6 and		need to be addressed for the management of a network with constrained
	Section 3.		devices please see Section 1.6 and Section 3.
	3. Requirements on the Management of Networks with Constrained Devices		3. Requirements on the Management of Networks with Constrained Devices
	This section describes the requirements categorized by management		This section describes the requirements categorized by management
	areas listed in subsections.		areas listed in subsections.
	Note that the requirements in this section need to be seen as		Note that the requirements in this section need to be seen as
	standalone requirements. A device might be able to provide only a		standalone requirements. A device might be able to provide only a
	particular profile of requirements (i.e. selected set of		particular profile of requirements (i.e. selected set of
	requirements) and might not be capable to provide all requirements in		requirements) and might not be capable to provide all requirements in
	skipping to change at page 16, line 28		skipping to change at page 17, line 28
	Following template is used for the definition of the requirements.		Following template is used for the definition of the requirements.
	Req-ID: An ID uniquely identified by a three-digit number		Req-ID: An ID uniquely identified by a three-digit number
	Title: The title of the requirement.		Title: The title of the requirement.
	Description: The rational and description of the requirement.		Description: The rational and description of the requirement.
	Source: The origin of the requirement and the matching use case or		Source: The origin of the requirement and the matching use case or
	application. For the discussion of referred use cases for		application. For the discussion of referred use cases for
	constrained management please see [COM-US].		constrained management please see [COM-USE].
	Requirement Type: Functional Requirement, Non-Functional		Requirement Type: Functional Requirement, Non-Functional
	Requirement. A functional requirement is related to a proposed		Requirement. A functional requirement is related to a proposed
	function or component. As such functional requirements may be		function or component. As such functional requirements may be
	technical details, or specific functionality that define what a		technical details, or specific functionality that define what a
	system is supposed to accomplish. Non-functional requirements		system is supposed to accomplish. Non-functional requirements
	(also known as design constraints or quality requirements) impose		(also known as design constraints or quality requirements) impose
	implementation related considerations such as performance		implementation related considerations such as performance
	requirements, security, or reliability.		requirements, security, or reliability.
	Device type: The device types by which this requirement can be		Device type: The device types by which this requirement can be
	supported: C0, C1 and/or C2.		supported: C0, C1 and/or C2.
	Priority: The priority of the requirement showing it's importance		Priority: The priority of the requirement showing it's importance
	for a particular type of device: High, Medium, and Low. The		for a particular type of device: High, Medium, and Low. The
	priority of a requirement can be High e.g. for a C2 device but Low		priority of a requirement can be High e.g. for a C2 device but Low
	for a C1 or C0 device as the realization of complex features in a		for a C1 or C0 device as the realization of complex features in a
	C1 device is in many cases not possible.		C1 device is in many cases not possible.
	3.1. Management Architecture/System		3.1. Management Architecture/System
	Req-ID: 4.1.001		Req-ID: 1.001
	Title: Support multiple device classes within a single network.		Title: Support multiple device classes within a single network.
	Description: Larger networks usually are made up of devices		Description: Larger networks usually are made up of devices
	belonging to different device classes (e.g., constrained mesh		belonging to different device classes (e.g., constrained mesh
	endpoints and less constrained routers) that work together.		endpoints and less constrained routers) that work together.
	Hence, the management architecture must be applicable to networks		Hence, the management architecture must be applicable to networks
	that have a mix of different device classes. See Section 3. of		that have a mix of different device classes. See Section 3. of
	[I-D.ietf-lwig-terminology] for the definition of Constrained		[I-D.ietf-lwig-terminology] for the definition of Constrained
	Device Classes.		Device Classes.
	Source: All use cases.		Source: All use cases.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: Managing and intermediary entities.		Device type: C1 and/or C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.1.002		Req-ID: 1.002
	Title: Management scalability.		Title: Management scalability.
	Description: The management architecture must be able to scale with		Description: The management architecture must be able to scale with
	the number of devices involved and operate efficiently in any		the number of devices involved and operate efficiently in any
	network size and topology. This implies that e.g. the managing		network size and topology. This implies that e.g. the managing
	entity is able to handle huge amount of device monitoring data and		entity is able to handle huge amount of device monitoring data and
	the management protocol is not sensitive to the decrease of the		the management protocol is not sensitive to the decrease of the
	time between two client requests. To achieve good scalability,		time between two client requests. To achieve good scalability,
	caching techniques, in-network data aggregation techniques,		caching techniques, in-network data aggregation techniques,
	skipping to change at page 18, line 4		skipping to change at page 19, line 4
	Source: General requirement for all use cases to enable large scale		Source: General requirement for all use cases to enable large scale
	networks.		networks.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.1.003		Req-ID: 1.003
	Title: Hierarchical management		Title: Hierarchical management
	Description: Provide a means of hierarchical management, i.e.		Description: Provide a means of hierarchical management, i.e.
	provide intermediary management entities on different levels,		provide intermediary management entities on different levels,
	which can take over the responsibility for the management of a		which can take over the responsibility for the management of a
	sub-hierarchy of the network of constraint devices. The		sub-hierarchy of the network of constraint devices. The
	intermediary management entity can e.g. support management data		intermediary management entity can e.g. support management data
	aggregation to handle e.g. high-frequent monitoring data or		aggregation to handle e.g. high-frequent monitoring data or
	provide a caching mechanism for the uplink and downlink		provide a caching mechanism for the uplink and downlink
	skipping to change at page 18, line 29		skipping to change at page 19, line 29
	hierarchical topology.		hierarchical topology.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: Managing and intermediary entities.		Device type: Managing and intermediary entities.
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.1.004		Req-ID: 1.004
	Title: Minimize state maintained on constrained devices.		Title: Minimize state maintained on constrained devices.
	Description: The amount of state that needs to be maintained on		Description: The amount of state that needs to be maintained on
	constrained devices should be minimized. This is important in		constrained devices should be minimized. This is important in
	order to save memory (especially relevant for C0 and C1 devices)		order to save memory (especially relevant for C0 and C1 devices)
	and in order to allow devices to restart for example to apply		and in order to allow devices to restart for example to apply
	configuration changes or to recover from extended periods of		configuration changes or to recover from extended periods of
	inactivity. One way to achieve this is to adopt a RESTful		inactivity.
	architecture that minimizes the amount of state maintained by
	managed constrained devices and that makes resources of a device		Note: One way to achieve this is to adopt a RESTful architecture
			that minimizes the amount of state maintained by managed
			constrained devices and that makes resources of a device
	addressable via URIs.		addressable via URIs.
	Source: Basic requirement which concerns all use cases.		Source: Basic requirement which concerns all use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.1.005		Req-ID: 1.005
	Title: Automatic re-synchronization with eventual consistency.		Title: Automatic re-synchronization with eventual consistency.
	Description: To support large scale networks, where some constrained		Description: To support large scale networks, where some constrained
	devices may be offline at any point in time, it is necessary to		devices may be offline at any point in time, it is necessary to
	distribute configuration parameters in a way that allows temporary		distribute configuration parameters in a way that allows temporary
	inconsistencies but eventually converges, after a sufficiently		inconsistencies but eventually converges, after a sufficiently
	long period of time without further changes, towards global		long period of time without further changes, towards global
	consistency.		consistency.
	Source: Use cases with large scale networks with many devices.		Source: Use cases with large scale networks with many devices.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.1.006		Req-ID: 1.006
	Title: Support for lossy links and unreachable devices.		Title: Support for lossy links and unreachable devices.
	Description: Some constrained devices will only be able to support		Description: Some constrained devices will only be able to support
	lossy and unreliable links characterized by a limited data rate, a		lossy and unreliable links characterized by a limited data rate, a
	high latency, and a high transmission error rate. Furthermore		high latency, and a high transmission error rate. Furthermore
	constrained devices often duty cycle their radio or the whole		constrained devices often duty cycle their radio or the whole
	device in order to save energy. In both cases the management		device in order to save energy. Some classes of devices labelled
			as 'sleepy endpoints' set their network links to a disconnected
			state during long periods of time. In all cases the management
	system must not assume that constrained devices are always		system must not assume that constrained devices are always
	reachable. The management protocol(s) must act gracefully if a		reachable.
	conctrained device is not reachable and provide a high degree of
	resilience. Intermediaries may be used that provide information
	for devices currently inactive or that take responsibility to re-
	synchronize devices when they become reachable again after an
	extended offline period.
	Source: Basic requirement for constrained networks with unreliable		Source: Basic requirement for networks of constrained devices with
	links and constrained devices which sleep to save energy.		unreliable links and constrained devices which sleep to save
			energy.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.1.007		Req-ID: 1.007
	Title: Network-wide configuration		Title: Network-wide configuration
	Description: Provide means by which the behavior of the network can		Description: Provide means by which the behavior of the network can
	be specified at a level of abstraction (network-wide		be specified at a level of abstraction (network-wide
	configuration) higher than a set of configuration information		configuration) higher than a set of configuration information
	specific to individual devices. It is useful to derive the device		specific to individual devices. It is useful to derive the device
	specific configuration from the network-wide configuration. The		specific configuration from the network-wide configuration. Such
	identification of the relevant subset of the policies to be		a repository can be used to configure pre-defined device or
	provisioned is according to the capabilities of each device and		protocol parameters for the whole network. Furthermore, such a
	can be obtained from a pre-configured data-repository. Such a		network-wide view can be used to monitor and manage a group of
	repository can be used to configure pre-defined device or protocol		routers or a whole network. E.g. monitoring the performance of a
	parameters for the whole network. Furthermore, such a network-		network requires additional information other than what can be
	wide view can be used to monitor and manage a group of routers or		acquired from a single router using a management protocol.
	a whole network. E.g. monitoring the performance of a network
	requires additional information other than what can be acquired		Note: The identification of the relevant subset of the policies to
	from a single router using a management protocol.		be provisioned is according to the capabilities of each device and
			can be obtained from a pre-configured data-repository.
	Source: In general all use cases, which want to configure the		Source: In general all use cases, which want to configure the
	network and its devices based on a network view in a top-down		network and its devices based on a network view in a top-down
	manner.		manner.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.1.008		Req-ID: 1.008
	Title: Distributed Management		Title: Distributed Management
	Description: Provide a means of simple distributed management, where		Description: Provide a means of simple distributed management, where
	a constrained network can be managed or monitored by more than one		a network of constrained devices can be managed or monitored by
	manager. Since the connectivity to a server cannot be guaranteed		more than one manager. Since the connectivity to a server cannot
	at all times, a distributed approach may provide a higher		be guaranteed at all times, a distributed approach may provide a
	reliability, at the cost of increased complexity. This		higher reliability, at the cost of increased complexity. This
	requirement implies the handling of data consistency in case of		requirement implies the handling of data consistency in case of
	concurrent read and write access to the device datastore. It		concurrent read and write access to the device datastore. It
	might also happen that no management (configuration) server is		might also happen that no management (configuration) server is
	accessible and the only reachable node is a peer device. In this		accessible and the only reachable node is a peer device. In this
	case the device should be able to obtain its configuration from		case the device should be able to obtain its configuration from
	peer devices.		peer devices.
	Source: Use cases where the count of devices to manage is high.		Source: Use cases where the count of devices to manage is high.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	3.2. Management protocols and data model		3.2. Management protocols and data model
	Req-ID: 4.2.001		Req-ID: 2.001
	Title: Modular implementation of management protocols		Title: Modular implementation of management protocols
	Description: Management protocols should allow modular		Description: Management protocols should be specified to allow for
	implementations, i.e., it should be possible to implement only a		modular implementations, i.e., it should be possible to implement
	basic set of protocol primitives on highly constrained devices		only a basic set of protocol primitives on highly constrained
	while devices with additional resources may provide more support		devices while devices with additional resources may provide more
	for additional protocol primitives. It should be possible to		support for additional protocol primitives. See Section 1.7 for a
	discover the management protocol primitives by a device.		discussion on the level of configuration management and monitoring
			support constrained devices may provide.
	Source: Basic requirement interesting for all use cases.		Source: Basic requirement interesting for all use cases.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.2.002		Req-ID: 2.002
	Title: Compact encoding of management data		Title: Compact encoding of management data
	Description: The encoding of management data should be compact and		Description: The encoding of management data should be compact and
	space efficient, enabling small message sizes.		space efficient, enabling small message sizes.
	Source: General requirement to save memory for the receiver buffer		Source: General requirement to save memory for the receiver buffer
	and on-air bandwith.		and on-air bandwith.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.2.003		Req-ID: 2.003
	Title: Compression of management data or complete messages		Title: Compression of management data or complete messages
	Description: Management data exchanges can be further optimized by		Description: Management data exchanges can be further optimized by
	applying data compression techniques or delta encoding techniques.		applying data compression techniques or delta encoding techniques.
	Compression typically requires additional code size and some		Compression typically requires additional code size and some
	additional buffers and/or the maintenance of some additional state		additional buffers and/or the maintenance of some additional state
	information. For C0 devices compression may not be feasible. As		information. For C0 devices compression may not be feasible.
	such, this requirement is marked as optional.
	Source: Use cases where it is beneficial to reduce transmission time		Source: Use cases where it is beneficial to reduce transmission time
	and bandwith, e.g. mobile applications which require to save on-		and bandwith, e.g. mobile applications which require to save on-
	air bandwith.		air bandwith.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.2.004		Req-ID: 2.004
	Title: Mapping of management protocol interactions.		Title: Mapping of management protocol interactions.
	Description: It is desirable to have a loss-less automated mapping		Description: It is desirable to have a loss-less automated mapping
	between the management protocol used to manage constrained devices		between the management protocol used to manage constrained devices
	and the management protocols used to manage regular devices. In		and the management protocols used to manage regular devices. In
	the ideal case, the same core management protocol can be used with		the ideal case, the same core management protocol can be used with
	certain restrictions taking into account the resource limitations		certain restrictions taking into account the resource limitations
	of constrained devices. However, for very resource constrained		of constrained devices. However, for very resource constrained
	devices, this goal might not be achievable. Hence this		devices, this goal might not be achievable.
	requirement is marked optional for device class C2.
	Source: Use cases where high-frequent interaction with the		Source: Use cases where high-frequent interaction with the
	management system of a non-constrained network is required.		management system of a non-constrained network is required.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.2.005		Req-ID: 2.005
	Title: Consistency of data models with the underlying information		Title: Consistency of data models with the underlying information
	model.		model.
	Description: The data models used by the management protocol must be		Description: The data models used by the management protocol must be
	consistent with the information model used to define data models		consistent with the information model used to define data models
	for non-constrained networks. This is essential to facilitate the		for non-constrained networks. This is essential to facilitate the
	integration of the management of constrained networks with the		integration of the management of constrained networks with the
	management of non-constrained networks. Using an underlying		management of non-constrained networks. Using an underlying
	information model for future data model design enables furthermore		information model for future data model design enables furthermore
	skipping to change at page 23, line 44		skipping to change at page 24, line 44
	consistency and model reuse.		consistency and model reuse.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.2.006		Req-ID: 2.006
	Title: Loss-less mapping of management data models.		Title: Loss-less mapping of management data models.
	Description: It is desirable to have a loss-less automated mapping		Description: It is desirable to have a loss-less automated mapping
	between the management data models used to manage regular devices		between the management data models used to manage regular devices
	and the management data models used for managing constrained		and the management data models used for managing constrained
	devices. In the ideal case, the same core data models can be used		devices. In the ideal case, the same core data models can be used
	with certain restrictions taking into account the resource		with certain restrictions taking into account the resource
	limitations of constrained devices. However, for very resource		limitations of constrained devices. However, for very resource
	constrained devices, this goal might not be achievable. Hence		constrained devices, this goal might not be achievable.
	this requirement is marked optional for device class C2.
	Source: Use cases where consistent data exchange with the management		Source: Use cases where consistent data exchange with the management
	system of a non-constrained network is required.		system of a non-constrained network is required.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C2		Device type: C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.2.007		Req-ID: 2.007
	Title: Protocol extensibility		Title: Protocol extensibility
	Description: Provide means of extensibility for the management		Description: Provide means of extensibility for the management
	protocol, i.e. by adding new protocol messages or mechanisms that		protocol, i.e. by adding new protocol messages or mechanisms that
	can deal with the changing requirements on a supported message and		can deal with the changing requirements on a supported message and
	data types effectively, without causing inter-operability problems		data types effectively, without causing inter-operability problems
	or having to replace/update large amounts of deployed devices.		or having to replace/update large amounts of deployed devices.
	Source: Basic requirement useful for all use cases.		Source: Basic requirement useful for all use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	3.3. Configuration management		3.3. Configuration management
	Req-ID: 4.3.001		Req-ID: 3.001
	Title: Self-configuration capability		Title: Self-configuration capability
	Description: Automatic configuration and re-configuration of devices		Description: Automatic configuration and re-configuration of devices
	without manual intervention. Compared to the traditional		without manual intervention. Compared to the traditional
	management of devices where the management application is the		management of devices where the management application is the
	central entity configuring the devices, in the auto-configuration		central entity configuring the devices, in the auto-configuration
	scenario the device is the active part and initiates the		scenario the device is the active part and initiates the
	configuration process. Self-configuration can be initiated during		configuration process. Self-configuration can be initiated during
	the initial configuration or for subsequent configurations, where		the initial configuration or for subsequent configurations, where
	skipping to change at page 25, line 19		skipping to change at page 26, line 18
	devices.		devices.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High for device categories C0 and C1, Medium for C2.		Priority: High for device categories C0 and C1, Medium for C2.
	---		---
	Req-ID: 4.3.002		Req-ID: 3.002
	Title: Capability Discovery		Title: Capability Discovery
	Description: Enable the discovery of supported optional management		Description: Enable the discovery of supported optional management
	capabilities of a device and their exposure via at least one		capabilities of a device and their exposure via at least one
	protocol and/or data model.		protocol and/or data model.
	Source: Use cases where the device interaction with other devices or		Source: Use cases where the device interaction with other devices or
	applications is a function of the level of support for its		applications is a function of the level of support for its
	capabilities.		capabilities.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.3.003		Req-ID: 3.003
	Title: Asynchronous Transaction Support		Title: Asynchronous Transaction Support
	Description: Provide configuration management with asynchronous		Description: Provide configuration management with asynchronous
	transaction support. Configuration operations must support a		(event-driven) transaction support. Configuration operations must
	transactional model, with asynchronous indications that the		support a transactional model, with asynchronous indications that
	transaction was completed.		the transaction was completed.
	Source: Use cases, which require transaction-oriented processing		Source: Use cases, which require transaction-oriented processing
	because of reliability or distributed architecture functional		because of reliability or distributed architecture functional
	requirements.		requirements.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.3.004		Req-ID: 3.004
	Title: Network reconfiguration		Title: Network reconfiguration
	Description: Provide a means of iterative network reconfiguration in		Description: Provide a means of iterative network reconfiguration in
	order to recover the network functionality from node and		order to recover the network functionality from node and
	communication faults. The network reconfiguration can be failure-		communication faults. The network reconfiguration can be failure-
	driven and self-initiated (automatic reconfiguration). The		driven and self-initiated (automatic reconfiguration). The
	network reconfiguration can be also performed on the whole		network reconfiguration can be also performed on the whole
	hierarchical structure of a network (network topology).		hierarchical structure of a network (network topology).
	skipping to change at page 26, line 35		skipping to change at page 27, line 35
	basic requirement.		basic requirement.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	3.4. Monitoring functionality		3.4. Monitoring functionality
	Req-ID: 4.4.001		Req-ID: 4.001
	Title: Device status monitoring		Title: Device status monitoring
	Description: Provide a monitoring function to collect and expose		Description: Provide a monitoring function to collect and expose
	information about device status and exposing it via at least one		information about device status and exposing it via at least one
	management interface. The device monitoring might make use of the		management interface. The device monitoring might make use of the
	hierarchical management through the intermediary entities and the		hierarchical management through the intermediary entities and the
	data caching mechanism. The device monitoring might also make use		caching mechanism. The device monitoring might also make use of
	of neighbor-monitoring (fault detection in local network) to		neighbor-monitoring (fault detection in local network) to support
	support fast fault detection and recovery, e.g. in a scenario		fast fault detection and recovery, e.g. in a scenario where a
	where a managing entity is unreachable and a neighbor can take		managing entity is unreachable and a neighbor can take over the
	over the monitoring responsibility.		monitoring responsibility.
	Source: All use cases		Source: All use cases
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High, Medium for neighbor-monitoring.		Priority: High, Medium for neighbor-monitoring.
	---		---
	Req-ID: 4.4.002		Req-ID: 4.002
	Title: Energy status monitoring		Title: Energy status monitoring
	Description: Provide a monitoring function to collect and expose		Description: Provide a monitoring function to collect and expose
	information about device energy parameters and usage (e.g. battery		information about device energy parameters and usage (e.g. battery
	level and communication power).		level and communication power).
	Source: Use case Energy Management		Source: Use case Energy Management
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High for energy reporting devices, Low for others.		Priority: High for energy reporting devices, Low for others.
	---		---
	Req-ID: 4.4.003		Req-ID: 4.003
	Title: Monitoring of current and estimated device availability		Title: Monitoring of current and estimated device availability
	Description: Provide a monitoring function to collect and expose		Description: Provide a monitoring function to collect and expose
	information about current device availability (energy, memory,		information about current device availability (energy, memory,
	computing power, forwarding plane utilization, queue buffers,		computing power, forwarding plane utilization, queue buffers,
	etc.) and estimation of remaining available resources.		etc.) and estimation of remaining available resources.
	Source: All use cases. Note that monitoring energy resources (like		Source: All use cases. Note that monitoring energy resources (like
	battery status) may be required on all kinds of devices.		battery status) may be required on all kinds of devices.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.4.004		Req-ID: 4.004
	Title: Network status monitoring		Title: Network status monitoring
	Description: Provide a monitoring function to collect and expose		Description: Provide a monitoring function to collect, analyse and
	information related to the status of a network or network segments		expose information related to the status of a network or network
	connected to the interfaces of the device.		segments connected to the interface of the device.
	Source: All use cases.		Source: All use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Low, based on the realization complexity.		Priority: Low, based on the realization complexity.
	---		---
	Req-ID: 4.4.005		Req-ID: 4.005
	Title: Self-monitoring		Title: Self-monitoring
	Description: Provide self-monitoring (local fault detection) feature		Description: Provide self-monitoring (local fault detection) feature
	for fast fault detection and recovery.		for fast fault detection and recovery.
	Source: Use cases where the devices cannot be monitored centrally in		Source: Use cases where the devices cannot be monitored centrally in
	appropriate manner, e.g. self-healing is required.		appropriate manner, e.g. self-healing is required.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: High for C2, Medium for C1		Priority: High for C2, Medium for C1
	---		---
	Req-ID: 4.4.006		Req-ID: 4.006
	Title: Performance Monitoring		Title: Performance Monitoring
	Description: The device will provide a monitoring function to		Description: The device will provide a monitoring function to
	collect and expose information about the basic performance		collect and expose information about the basic performance
	parameter (TBD) of the device. The performance management		parameter of the device. The performance management functionality
	functionality might make use of the hierarchical management		might make use of the hierarchical management through the
	through the intermediary devices.		intermediary devices.
	Source: Use cases Building automation, and Transport applications		Source: Use cases Building automation, and Transport applications
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Low		Priority: Low
	---		---
	Req-ID: 4.4.007		Req-ID: 4.007
	Title: Fault detection monitoring		Title: Fault detection monitoring
	Description: The device will provide fault detection monitoring.		Description: The device will provide fault detection monitoring.
	The system collects information about network states in order to		The system collects information about network states in order to
	identify whether faults have occurred. In some cases the		identify whether faults have occurred. In some cases the
	detection of the faults might be based on the processing and		detection of the faults might be based on the processing and
	analysis of the parameters retrieved from the network or other		analysis of the parameters retrieved from the network or other
	devices. In case of C0 devices the monitoring might be limited to		devices. In case of C0 devices the monitoring might be limited to
	the check whether the device is alive or not.		the check whether the device is alive or not.
	skipping to change at page 29, line 38		skipping to change at page 30, line 38
	Energy Management, Infrastructure Monitoring		Energy Management, Infrastructure Monitoring
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1 and C2		Device type: C0, C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.4.008		Req-ID: 4.008
	Title: Passive and Reactive Monitoring		Title: Passive and Reactive Monitoring
	Description: The device will provide passive and reactive monitoring		Description: The device will provide passive and reactive monitoring
	capabilities. The system or manager collects information about		capabilities. The system or manager collects information about
	device components and network states (passive monitoring) and may		device components and network states (passive monitoring) and may
	perform postmortem analysis of collected data. In case events of		perform postmortem analysis of collected data. In case events of
	interest have occurred the system or manager can adaptively react		interest have occurred the system or manager can adaptively react
	(reactive monitoring), e.g. reconfigure the network. Typically		(reactive monitoring), e.g. reconfigure the network. Typically
	actions (re-actions) will be executed or sent as commands by the		actions (re-actions) will be executed or sent as commands by the
	skipping to change at page 30, line 16		skipping to change at page 31, line 16
	state monitoring		state monitoring
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C2		Device type: C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.4.009		Req-ID: 4.009
	Title: Recovery		Title: Recovery
	Description: Provide local, central and hierarchical recovery		Description: Provide local, central and hierarchical recovery
	mechanisms (recovery is in some cases achieved by recovering the		mechanisms (recovery is in some cases achieved by recovering the
	whole network of constrained devices).		whole network of constrained devices).
	Source: Use cases Industrial applications, Home and Building		Source: Use cases Industrial applications, Home and Building
	Automation, Mobile Applications that involve different forms of		Automation, Mobile Applications that involve different forms of
	clustering or area managers.		clustering or area managers.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C2		Device type: C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.4.010		Req-ID: 4.010
	Title: Network topology discovery		Title: Network topology discovery
	Description: Provide a network topology discovery capability (e.g.		Description: Provide a network topology discovery capability (e.g.
	use of topology extraction algorithms to retrieve the network		use of topology extraction algorithms to retrieve the network
	state) and a monitoring function to collect and expose information		state) and a monitoring function to collect and expose information
	about the network topology.		about the network topology.
	Source: Use cases Community Network Applications and Mobile		Source: Use cases Community Network Applications and Mobile
	Applications		Applications
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Low, based on the realization complexity.		Priority: Low, based on the realization complexity.
	---		---
	Req-ID: 4.4.011		Req-ID: 4.011
	Title: Notifications		Title: Notifications
	Description: The device will provide the capability of sending		Description: The device will provide the capability of sending
	notifications on critical events and faults.		notifications on critical events and faults.
	Source: All use cases.		Source: All use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium for C2, Low for C1		Priority: Medium for C2, Low for C0 and C1
	---		---
	Req-ID: 4.4.012		Req-ID: 4.012
	Title: Logging		Title: Logging
	Description: The device will provide the capability of building,		Description: The device will provide the capability of building,
	keeping, and allowing retrieval of logs of events (including but		keeping, and allowing retrieval of logs of events (including but
	not limited to critical faults and alarms).		not limited to critical faults and alarms).
	Source: Use cases Industrial Applications, Building Automation,		Source: Use cases Industrial Applications, Building Automation,
	Infrastructure monitoring		Infrastructure monitoring
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C2		Device type: C2
	Priority: High for some medical or industrial applications, Medium		Priority: High for some medical or industrial applications, Medium
	otherwise		otherwise
	3.5. Self-management		3.5. Self-management
	Req-ID: 4.5.001		Req-ID: 5.001
	Title: Self-management - Self-healing		Title: Self-management - Self-healing
	Description: Enable event-driven and/or periodic self-management		Description: Enable event-driven and/or periodic self-management
	functionality in a device. The device should be able to react in		functionality in a device. The device should be able to react in
	case of a failure e.g. by initiating a fully or partly reset and		case of a failure e.g. by initiating a fully or partly reset and
	initiate a self-configuration or management data update as		initiate a self-configuration or management data update as
	necessary. A device might be further able to check for failures		necessary. A device might be further able to check for failures
	cyclically or schedule-controlled to trigger self-management as		cyclically or schedule-controlled to trigger self-management as
	necessary. It is a matter of device design and subject for		necessary. It is a matter of device design and subject for
	discussion how much self-management a C1 device can support. A		discussion how much self-management a C1 device can support. A
	skipping to change at page 32, line 28		skipping to change at page 33, line 28
	document.		document.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: High for C2, Medium for C1		Priority: High for C2, Medium for C1
	3.6. Security and Access Control		3.6. Security and Access Control
	Req-ID: 4.6.001		Req-ID: 6.001
	Title: Authentication of management system and devices.		Title: Authentication of management system and devices.
	Description: Systems having a management role must be properly		Description: Systems having a management role must be properly
	authenticated to the device such that the device can exercise		authenticated to the device such that the device can exercise
	proper access control and in particular distinguish rightful		proper access control and in particular distinguish rightful
	management systems from rogue systems. On the other hand managed		management systems from rogue systems. On the other hand managed
	devices must authenticate themselves to systems having a		devices must authenticate themselves to systems having a
	management role such that management systems can protect		management role such that management systems can protect
	themselves from rogue devices. In certain application scenarios,		themselves from rogue devices. In certain application scenarios,
	skipping to change at page 33, line 11		skipping to change at page 34, line 11
	Source: Basic security requirement for all use cases.		Source: Basic security requirement for all use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High, Medium for the (re)start of a large number of		Priority: High, Medium for the (re)start of a large number of
	devices		devices
	---		---
	Req-ID: 4.6.002		Req-ID: 6.002
	Title: Support suitable security bootstrapping mechanisms		Title: Support suitable security bootstrapping mechanisms
	Description: Mechanisms should be supported that simplify the		Description: Mechanisms should be supported that simplify the
	bootstrapping of device that is the discovery of newly deployed		bootstrapping of device that is the discovery of newly deployed
	devices in order to add them to access control lists.		devices in order to provide them with appropriate access control
			permissions.
	Source: Basic security requirement for all use cases.		Source: Basic security requirement for all use cases.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.6.003		Req-ID: 6.003
	Title: Access control on management system and devices		Title: Access control on management system and devices
	Description: Systems acting in a management role must provide an		Description: Systems acting in a management role must provide an
	access control mechanism that allows the security administrator to		access control mechanism that allows the security administrator to
	restrict which devices can access the managing system (e.g., using		restrict which devices can access the managing system (e.g., using
	an access control white list of known devices). On the other hand		an access control white list of known devices). On the other hand
	managed constrained devices must provide an access control		managed constrained devices must provide an access control
	mechanism that allows the security administrator to restrict how		mechanism that allows the security administrator to restrict how
	systems in a management role can access the device (e.g., no-		systems in a management role can access the device (e.g., no-
	skipping to change at page 34, line 8		skipping to change at page 35, line 8
	Source: Basic security requirement for use cases where access		Source: Basic security requirement for use cases where access
	control is essential.		control is essential.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.6.004		Req-ID: 6.004
	Title: Select cryptographic algorithms that are efficient in both		Title: Select cryptographic algorithms that are efficient in both
	code space and execution time.		code space and execution time.
	Description: Cryptographic algorithms have a major impact in terms		Description: Cryptographic algorithms have a major impact in terms
	of both code size and overall execution time. It is therefore		of both code size and overall execution time. It is therefore
	necessary to select mandatory to implement cryptographic		necessary to select mandatory to implement cryptographic
	algorithms (like some elliptic curve algorithm) that are		algorithms that are reasonable to implement with the available
	reasonable to implement with the available code space and that		code space and that have a small impact at runtime. Furthermore
	have a small impact at runtime. Furthermore some wireless		some wireless technologies (e.g., IEEE 802.15.4) require the
	technologies (e.g., IEEE 802.15.4) require the support of certain		support of certain cryptographic algorithms. It might be useful
	cryptographic algorithms. It might be useful to choose algorithms		to choose algorithms that are likely to be supported in wireless
	that are likely to be supported in wireless chipsets for certain		chipsets for certain wireless technologies.
	wireless technologies.
	Source: Generic requirement to reduce the footprint and CPU usage of		Source: Generic requirement to reduce the footprint and CPU usage of
	a constrained device.		a constrained device.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High, Medium for hardware-supported algorithms.		Priority: High, Medium for hardware-supported algorithms.
	3.7. Energy Management		3.7. Energy Management
	Req-ID: 4.7.001		Req-ID: 7.001
	Title: Management of Energy Resources		Title: Management of Energy Resources
	Description: Enable managing power resources in the network, e.g.		Description: Enable managing power resources in the network, e.g.
	reduce the sampling rate of nodes with critical battery and reduce		reduce the sampling rate of nodes with critical battery and reduce
	node transmission power, put nodes to sleep, put single interfaces		node transmission power, put nodes to sleep, put single interfaces
	to sleep, reject a management job based on available energy,		to sleep, reject a management job based on available energy,
	criteria e.g. importance levels pre-defined by the management		criteria e.g. importance levels pre-defined by the management
	application, etc. (e.g. a task marked as essential can be executed		application, etc. (e.g. a task marked as essential can be executed
	even if the energy level is low). The device may further		even if the energy level is low). The device may further
	skipping to change at page 35, line 15		skipping to change at page 36, line 15
	Source: Use case Energy Management		Source: Use case Energy Management
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium for the use case Energy Management, Low otherwise.		Priority: Medium for the use case Energy Management, Low otherwise.
	---		---
	Req-ID: 4.7.002		Req-ID: 7.002
	Title: Support of energy-optimized communication protocols		Title: Support of energy-optimized communication protocols
	Description: Use of an optimized communication protocol to minimize		Description: Use of an optimized communication protocol to minimize
	energy usage for the device (radio) receiver/transmitter, on-air		energy usage for the device (radio) receiver/transmitter, on-air
	bandwidth (protocol efficiency), reduced amount of data		bandwidth (protocol efficiency), reduced amount of data
	communication between nodes (implies data aggregation and		communication between nodes (implies data aggregation and
	filtering but also a compact format for the transferred data).		filtering but also a compact format for the transferred data).
	Source: Use cases Energy Management and Mobile Applications.		Source: Use cases Energy Management and Mobile Applications.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C2		Device type: C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.7.003		Req-ID: 7.003
	Title: Support for layer 2 energy-aware protocols		Title: Support for layer 2 energy-aware protocols
	Description: The device will support layer 2 energy management		Description: The device will support layer 2 energy management
	protocols (e.g. energy-efficient Ethernet IEEE 802.3az) and be		protocols (e.g. energy-efficient Ethernet IEEE 802.3az) and be
	able to report on these.		able to report on these.
	Source: Use case Energy Management		Source: Use case Energy Management
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.7.004		Req-ID: 7.004
	Title: Dying gasp		Title: Dying gasp
	Description: When energy resources draw below the red line level,		Description: When energy resources draw below the red line level,
	the device will send a dying gasp notification and perform if		the device will send a dying gasp notification and perform if
	still possible a graceful shutdown including conservation of		still possible a graceful shutdown including conservation of
	critical device configuration and status information.		critical device configuration and status information.
	Source: Use case Energy Management		Source: Use case Energy Management
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	3.8. SW Distribution		3.8. SW Distribution
	Req-ID: 4.8.001		Req-ID: 8.001
	Title: Group-based provisioning		Title: Group-based provisioning
	Description: Support group-based provisioning, i.e. firmware update		Description: Support group-based provisioning, i.e. firmware update
	and configuration management, of a large set of constrained		and configuration management, of a large set of constrained
	devices with eventual consistency and coordinated reload times.		devices with eventual consistency and coordinated reload times.
	The device should accept group-based configuration management		The device should accept group-based configuration management
	based on bulk commands, which aim similar configurations of a		based on bulk commands, which aim similar configurations of a
	large set of constrained devices of the same type in a given		large set of constrained devices of the same type in a given
	group. Activation of configuration may be based on pre-loaded		group, and which may share a common data model. Activation of
	sets of default values.		configuration may be based on pre-loaded sets of default values.
	Source: All use cases		Source: All use cases
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	3.9. Traffic management		3.9. Traffic management
	Req-ID: 4.9.001		Req-ID: 9.001
	Title: Congestion avoidance		Title: Congestion avoidance
	Description: Provide the ability to avoid congestion by modifying		Description: Support congestion control principles as defined in
	the device's reporting rate for periodical data (which is usually		[RFC2914], e.g. the ability to avoid congestion by modifying the
			device's reporting rate for periodical data (which is usually
	redundant) based on the importance and reliability level of the		redundant) based on the importance and reliability level of the
	management data. This functionality is usually controlled by the		management data. This functionality is usually controlled by the
	managing entity, where the managing entity marks the data as		managing entity, where the managing entity marks the data as
	important or relevant for reliability. However reducing a		important or relevant for reliability. However reducing a
	device's reporting rate can also be initiated by a device if it is		device's reporting rate can also be initiated by a device if it is
	able to detect congestion or has insufficient buffer memory.		able to detect congestion or has insufficient buffer memory.
	Source: Use cases with high reporting rate and traffic e.g. AMI or		Source: Use cases with high reporting rate and traffic e.g. AMI or
	M2M.		M2M.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C1 and C2		Device type: C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.9.002		Req-ID: 9.002
	Title: Redirect traffic		Title: Redirect traffic
	Description: Provide the ability for network nodes to redirect		Description: Provide the ability for network nodes to redirect
	traffic from overloaded intermediary nodes in a network to another		traffic from overloaded intermediary nodes in a network to another
	path in order to prevent congestion on a central server and in the		path in order to prevent congestion on a central server and in the
	primary network.		primary network.
	Source: Use cases with high reporting rate and traffic e.g. AMI or		Source: Use cases with high reporting rate and traffic e.g. AMI or
	M2M.		M2M.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: Intermediary entity in the network.		Device type: Intermediary entity in the network.
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.9.003		Req-ID: 9.003
	Title: Traffic delay schemes.		Title: Traffic delay schemes.
	Description: Provide the ability to apply delay schemes to incoming		Description: Provide the ability to apply delay schemes to incoming
	and outgoing links on an overloaded intermediary node as necessary		and outgoing links on an overloaded intermediary node as necessary
	in order to reduce the amount of traffic in the network.		in order to reduce the amount of traffic in the network.
	Source: Use cases with high reporting rate and traffic e.g. AMI or		Source: Use cases with high reporting rate and traffic e.g. AMI or
	M2M.		M2M.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: Intermediary entity in the network.		Device type: Intermediary entity in the network.
	Priority: Medium		Priority: Medium
	3.10. Transport Layer		3.10. Transport Layer
	Req-ID: 4.10.001		Req-ID: 10.001
	Title: Scalable transport layer		Title: Scalable transport layer
	Description: Enable the use of a scalable transport layer, i.e. not		Description: Enable the use of a scalable transport layer, i.e. not
	sensitive to the decrease of the time between two client requests,		sensitive to a high rate of incoming client requests, which is
	which is useful for applications requiring frequent access to		useful for applications requiring frequent access to device data.
	device data.
	Source: Applications with high frequent access to the device data.		Source: Applications with high frequent access to the device data.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1 and C2		Device type: C0, C1 and C2
	Priority: Medium		Priority: Medium
	---		---
	Req-ID: 4.10.002		Req-ID: 10.002
	Title: Reliable unicast transport of messages		Title: Reliable unicast transport of messages
	Description: Diverse applications need a reliable transport of		Description: Diverse applications need a reliable transport of
	messages. The reliability might be achieved based on a transport		messages. The reliability might be achieved based on a transport
	protocol such as TCP or can be supported based message repetition		protocol such as TCP or can be supported based on message
	if an acknowledgement is missing.		repetition if an acknowledgement is missing.
	Source: Generally applications benefit from the reliability of the		Source: Generally applications benefit from the reliability of the
	message transport.		message transport.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	---		---
	Req-ID: 4.10.003		Req-ID: 10.003
	Title: Best-effort multicast		Title: Best-effort multicast
	Description: Provide best-effort multicast of messages, which is		Description: Provide best-effort multicast of messages, which is
	generally useful when devices need to discover a service provided		generally useful when devices need to discover a service provided
	by a server or many devices need to be configured by a managing		by a server or many devices need to be configured by a managing
	entity at once based on the same data model.		entity at once based on the same data model.
	Source: Use cases where a device needs to discover services as well		Source: Use cases where a device needs to discover services as well
	as use cases with high amount of devices to manage, which are		as use cases with high amount of devices to manage, which are
	hierarchically deployed, e.g. AMI or M2M.		hierarchically deployed, e.g. AMI or M2M.
	Requirement Type: Functional Requirement		Requirement Type: Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: Medium		Priority: Medium
	Req-ID: 4.10.004		---
			Req-ID: 10.004
	Title: Secure message transport.		Title: Secure message transport.
	Description: Enable secure message transport providing		Description: Enable secure message transport providing
	authentication, data integrity, confidentiality by using existing		authentication, data integrity, confidentiality by using existing
	transport layer technologies with small footprint such as TLS/		transport layer technologies with small footprint such as TLS/
	DTLS.		DTLS.
	Source: All use cases.		Source: All use cases.
	Requirement Type: Non-Functional Requirements		Requirement Type: Non-Functional Requirements
	Device type: C1 and C2		Device type: C1 and C2
	Priority: High		Priority: High
	3.11. Implementation Requirements		3.11. Implementation Requirements
	Req-ID: 4.11.001		Req-ID: 11.001
	Title: Avoid complex application layer transactions requiring large		Title: Avoid complex application layer transactions requiring large
	application layer messages.		application layer messages.
	Description: Complex application layer transactions tend to require		Description: Complex application layer transactions tend to require
	large memory buffers that are typically not available on C0 or C1		large memory buffers that are typically not available on C0 or C1
	devices and only by limiting functionality on C2 devices.		devices and only by limiting functionality on C2 devices.
	Furthermore, the failure of a single large transaction requires		Furthermore, the failure of a single large transaction requires
	repeating the whole transaction. On constrained devices, it is		repeating the whole transaction. On constrained devices, it is
	often more desirable to a large transaction down into a sequence		often more desirable to a large transaction down into a sequence
	skipping to change at page 40, line 23		skipping to change at page 41, line 30
	Source: Basic requirement which concerns all use cases with memory		Source: Basic requirement which concerns all use cases with memory
	constrained devices.		constrained devices.
	Requirement Type: Non-Functional Requirement		Requirement Type: Non-Functional Requirement
	Device type: C0, C1, and C2		Device type: C0, C1, and C2
	Priority: High		Priority: High
	Req-ID: 4.11.002		---
			Req-ID: 11.002
	Title: Avoid reassembly of messages at multiple layers in the		Title: Avoid reassembly of messages at multiple layers in the
	protocol stack.		protocol stack.
	Description: Reassembly of messages at multiple layers in the		Description: Reassembly of messages at multiple layers in the
	protocol stack requires buffers at multiple layers, which leads to		protocol stack requires buffers at multiple layers, which leads to
	inefficient use of memory resources. This can be avoided by		inefficient use of memory resources. This can be avoided by
	making sure the application layer, the security layer, the		making sure the application layer, the security layer, the
	transport layer, the IPv6 layer and any adaptation layers are		transport layer, the IPv6 layer and any adaptation layers are
	aware of the limitations of each other such that unnecessary		aware of the limitations of each other such that unnecessary
	skipping to change at page 42, line 7		skipping to change at page 44, line 7
	4. IANA Considerations		4. IANA Considerations
	This document does not introduce any new code-points or namespaces		This document does not introduce any new code-points or namespaces
	for registration with IANA.		for registration with IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	5. Security Considerations		5. Security Considerations
	This document discusses the problem statement and requirements on the		This document discusses the problem statement and requirements on
	network of constrained devices. If specific requirements for		networks of constrained devices. Section 1.6 mentions a number of
	security will be identified, they will be described in future		limitations that could prevent the implementation of strong
	versions of this document.		cryptographic algorithms. Requirements for security and access
			control are listed in Section 3.6.
	6. Contributors		6. Contributors
	Ulrich Herberg (Fujitsu Laboratories of America) contributed to the		Ulrich Herberg (Fujitsu Laboratories of America) contributed to the
	Section 1.3 on Networks Types and Characteristics in Focus.		Section 1.3 on Networks Types and Characteristics in Focus.
	7. Acknowledgments		7. Acknowledgments
	Following persons reviewed and provided valuable comments to		Following persons reviewed and provided valuable comments to
	different versions of this document:		different versions of this document:
	Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert		Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit
	Greevenbosch, Ulrich Herberg, James Nguyen, Anuj Sehgal, Zach Shelby,		Claise, Hui Deng, Bert Greevenbosch, Ulrich Herberg, James Nguyen,
	and Peter van der Stok.		Anuj Sehgal, Zach Shelby, Peter van der Stok and Bert Wijnen.
	The editors would like to thank the reviewers and the participants on		The editors would like to thank the reviewers and the participants on
	the Coman maillist for their valuable contributions and comments.		the Coman and OPSAWG maillists for their valuable contributions and
			comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
			[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
			RFC 2914, September 2000.
	[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network		[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network
	Management Standards", RFC 6632, June 2012.		Management Standards", RFC 6632, June 2012.
			[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
			Lossy Networks", RFC 7102, January 2014.
	[I-D.ietf-lwig-terminology]		[I-D.ietf-lwig-terminology]
	Bormann, C., Ersue, M., and A. Keranen, "Terminology for		Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained Node Networks", draft-ietf-lwig-terminology-06		Constrained Node Networks", draft-ietf-lwig-terminology-07
	(work in progress), December 2013.		(work in progress), February 2014.
	[I-D.ietf-core-coap]		[I-D.ietf-core-coap]
	Shelby, Z., Hartke, K., and C. Bormann, "Constrained		Shelby, Z., Hartke, K., and C. Bormann, "Constrained
	Application Protocol (CoAP)", draft-ietf-core-coap-18		Application Protocol (CoAP)", draft-ietf-core-coap-18
	(work in progress), June 2013.		(work in progress), June 2013.
	[I-D.ietf-roll-terminology]		[COM-USE] Ersue, M., "Constrained Management: Use Cases",
	Vasseur, J., "Terms used in Routing for Low power And
	Lossy Networks", draft-ietf-roll-terminology-13 (work in
	progress), October 2013.
	[M2MDEVCLASS]
	Open Mobile Alliance, "OMA M2M Device Classification
	v1.0", October 2012, <http://
	technical.openmobilealliance.org/Technical/
	release_program/m2m_Device_class_v1_0.aspx>.
	[EU-IOT-A]
	EU Commission Seventh Framework Programme, "EU FP7 Project
	Internet-of-Things Architecture", <http://www.iot-a.eu/>.
	[EU-SENSEI]
	EU Commission Seventh Framework Programme, "EU Project
	SENSEI", <http://www.sensei-project.eu/>.
	[EU-FI-WARE]
	EU Commission Future Internet Public Private Partnership
	(FI-PPP), "EU Project Future Internet-Core Platform",
	<http://www.iot-butler.eu/>.
	[EU-IOT-BUTLER]
	EU Commission Seventh Framework Programme, "EU FP7 Project
	Butler Smartlife", <http://www.iot-butler.eu/>.
	[COM-US] Ersue, M., "Constrained Management: Use Cases",
	draft-ietf-opsawg-coman-use-cases (work in progress),		draft-ietf-opsawg-coman-use-cases (work in progress),
	October 2013.		October 2013.
	Appendix A. Related Development in other Bodies		Appendix A. Change Log
	Note that over time the summary on the related work in other bodies
	might become outdated.
	A.1. ETSI TC M2M
	ETSI Technical Committee Machine-to-Machine (ETSI TC M2M) aims to
	provide an end-to-end view of M2M standardization, which enables the
	integration of multiple vertical M2M applications. The main goal is
	to overcome the current M2M market fragmentation and to reuse
	existing mechanisms from telecom standards such as from OMA or 3GPP.
	ETSI Release 1 is functionally frozen. The main focus is on use
	cases for Smart Metering (Technical Report (TR) 102 691) but it also
	includes eHealth use cases (TR 102 732) and some others. The Service
	requirements (Technical Standard (TS) 102 689) derived from the use
	cases, and the functional architecture specification (TS 102 690),
	will together define the M2M platform. The architecture consists of
	Service Capabilities (SC), which are basic functional building blocks
	for building the M2M platform.
	Smart Metering is seen as the important showcase for M2M. It is
	believed that the Service Enablers that were defined based on the
	work done for Smart Metering and eHealth segments will also allow the
	building of other services like vending machines, alarm systems etc.
	The functional architecture includes following management-related
	definitions:
	o Network Management Functions: consists of all functions required
	to manage the Access, Transport and Core networks: these include
	Provisioning, Supervision, Fault Management, etc.
	o M2M Management Functions: consists of functions required to manage
	generic functionalities of M2M Applications and M2M Service
	Capabilities in the Network and Applications Domain. The
	management of the M2M Devices and Gateways may use specific M2M
	Service Capabilities.
	The Release 2 work of ETSI TC M2M has started beginning of 2012.
	Following is a list of networking- and management-related topics
	under work:
	o Interworking with 3GPP networks. This is a new work item, and no
	discussion has been held on technical details. The intent is to
	define which ETSI TC M2M functions are applicable when 3GPP NW is
	used as transport. It is possible that this work would also cover
	details on how to use 3GPP interfaces, e.g. those defined in the
	SIMTC work, but also for charging and policy control.
	o Creating a Semantic Model or Data Abstraction layer for vertical
	industries and interworking. This would provide some high level
	information description that would be usable for interworking with
	local networks (e.g. ZigBee), and also for verticals, and it
	would allow the ETSI Service Enablement layer to also understand
	the data, instead of being just a bit storage and bit pipe. All
	technical details are still under discussion, but it has been
	agreed that a function for this exists in the architecture at
	least for interworking.
	A.2. OASIS
	Developments in OASIS related to management of constrained networks
	are following:
	o The Energy Interoperation TC works to define interaction between
	Smart Grids and their end nodes, including Smart Buildings,
	Enterprises, Industry, Homes, and Vehicles. The TC develops data
	and communication models that enable the interoperable and
	standard exchange of signals for dynamic pricing, reliability, and
	emergencies. The TC's agenda also extends to the communication of
	market participation data (such as bids), load predictability, and
	generation information. The first version of the Energy
	Interoperation specification is in final review.
	o OASIS Open Data Protocol (OData) aims to simplify the querying and
	sharing of data across disparate applications and multiple
	stakeholders for re-use in the enterprise, Cloud, and mobile
	devices. As a REST-based protocol, OData builds on HTTP, AtomPub,
	and JSON using URIs to address and access data feed resources. It
	enables information to be accessed from a variety of sources
	including (but not limited to) relational databases, file systems,
	content management systems, and traditional Web sites.
	o Open Building Information Exchange (oBIX) aims to enable the
	mechanical and electrical control systems in buildings to
	communicate with enterprise applications, and to provide a
	platform for developing new classes of applications that integrate
	control systems with other enterprise functions. Enterprise
	functions include processes such as Human Resources, Finance,
	Customer Relationship Management (CRM), and Manufacturing.
	A.3. OMA
	OMA is currently working on Lightweight M2M Enabler, OMA Device
	Management (OMA DM) Next Generation, and a white paper on M2M Device
	Classification.
	The Lightweight M2M Enabler covers both M2M device management and
	service management for constrained devices. In the case of less
	constrained devices, OMA DM Next Generation Enabler may be more
	appropriate. OMA DM is structured around Management Objects (MO),
	each specified for a specific purpose. There is also ongoing work
	with various other MOs such as the Gateway Management Object (GwMO).
	A draft for the "Lightweight M2M Requirements" is available.
	OMA Lightweight M2M and OMA DM Next Generation are important to M2M
	device management, provisioning and service managements in both the
	protocol and management objects. OMA Lightweight M2M work seems to
	have grown from its original scope of being targeted for very simple
	devices only, i.e. such that could not handle all those protocols
	that ETSI M2M requires.
	The white paper on the M2M Device Classification [M2MDEVCLASS]
	provides an M2M device classification framework based on the
	horizontal attributes (e.g., wide or local area communication
	interface, IP stack, I/O capabilities) of interest to communication
	service providers and M2M service providers, independent of vertical
	markets, such as smart grid, connected cars, e-health, etc. The
	white paper can be used as a tool to analyze the applicability of
	existing requirements and specifications developed by OMA and other
	cooperative standards development organizations.
	A.4. IPSO Alliance
	IPSO Alliance developed a profile for Device Functions supporting		A.1. draft-ietf-opsawg-coman-probstate-reqs-00 -
	devices such as sensors with a limited user interface, where the		draft-ietf-opsawg-coman-probstate-reqs-01
	configuration of even basic parameters is impossible to do manually.
	This is a challenge especially for consumer devices that are managed
	by non-professional users. The configuration of a web service
	application running on a constrained device goes beyond the
	autoconfiguration of the IP stack and local information (e.g. proxy
	address). Constrained devices need additionally service provider and
	user account related configuration, such as an address/locator and
	the username for a web server.
	IPSO discusses the use cases and requirements for user friendly		o General bug fixing.
	configuration of such information on a constrained device, and
	specifies how IPSO profile Device Function Set can be used in the
	process. It furthermore defines a standard format for the basic
	application configuration information.
	Appendix B. Related Research Projects		o Added Section 1.7. on Configuration and Monitoring Functionality
			Levels.
	o The EU project IoT-A (Internet-of-Things Architecture) develops an		o Changed diverse occurences of "networks" to "networks with/of
	architectural reference model together with the definition of an		constrained devices".
	initial set of key building blocks. These enable the integration
	of IoT into the service layer of the Future Internet, and realize
	a novel resolution infrastructure, as well as a network
	infrastructure that allows the seamless communication flow between
	IoT devices and services. The development includes a conceptual
	model of a smart object as well as a basic Internet of Things
	reference model defining the interaction and communication between
	IoT devices and relevant entities. The requirements document
	includes also network and information management requirements (see
	[EU-IOT-A]).
	o The EU project SENSEI specified the document on 'End to End		o Introduced the term "Self-configuring infrastructureless networks"
	Networking and Management' for Wireless Sensor and Actuator		instead of MANET as it is a superset.
	Networks. This report presents several research results carried
	out in SENSEI's tasks related to End-to-End Networking and
	Management. Particular analyses have been addressed related to
	naming and addressing of resources, management of resources,
	resource plug and play, resource level mobility and traffic
	modelling. The detailed analysis on each of these topics is
	intended to identify possible gaps between their specific
	mechanisms and the functional requirements in the SENSEI reference
	architecture (see [EU-SENSEI]).
	o The EU project FI-WARE is developing the Things Management GE		o Introduced the term 'sleepy endpoints'.
	(generic enabler), which uses a data model derived from the OMA DM
	NGSI data model. Using the abstraction level of things which
	include non-technical things like rooms, places and people, Things
	Management GE aims to discover and look up IoT resources that can
	provide information about things or actuate on these things. The
	system aimes to manage the dynamic associations between IoT
	resources and things in order to allow internal components as well
	as external applications to interact with the system using the
	thing abstraction as the core concept (see [EU-FI-WARE]).
	o EU project BUTLER Smart Life discusses different IoT management		o Changed requirement IDs to be independent of section number.
	aspects and collects requirements for smart life use cases (e.g.
	smart home or smart city) mainly from service management pov. (see
	[EU-IOT-BUTLER]).
	Appendix C. Open issues		o Introduced notes for parts of the requirements text if it is
			focusing on implementation or solution.
	o Section 4 on the management requirements, as the core section in		o Extended Security Considerations section.
	the document, needs further consolidation.
	Appendix D. Change Log		o Deleted Appendix A and B on other SDO's work and related projects
			as they provided dynamic information and couldn't be kept up-to-
			date.
	D.1. draft-ersue-constrained-mgmt-03 -		A.2. draft-ersue-constrained-mgmt-03 -
	draft-ersue-opsawg-coman-probstate-reqs-00		draft-ietf-opsawg-coman-probstate-reqs-00
	o Reduced the terminology section for terminology addressed in the		o Reduced the terminology section for terminology addressed in the
	LWIG terminology draft. Referenced the LWIG terminology draft.		LWIG terminology draft. Referenced the LWIG terminology draft.
	o Checked and aligned all terminology against the LWIG terminology		o Checked and aligned all terminology against the LWIG terminology
	draft.		draft.
	o Moved section 1.4. Constrained Device Deployment Options and		o Moved section 1.4. Constrained Device Deployment Options and
	section 3. Use Cases to the companion document [COM-US].		section 3. Use Cases to the companion document [COM-USE].
	o Renamed Section 1.3. Class of Networks in Focus to "Network Types		o Renamed Section 1.3. Class of Networks in Focus to "Network Types
	in Focus" and removed abbreviations C0, C1 and C2 for network		in Focus" and removed abbreviations C0, C1 and C2 for network
	classes as they have not been used.		classes as they have not been used.
	o Changed requirement priority classes to be High, Medium and Low.		o Changed requirement priority classes to be High, Medium and Low.
	o Changed requirement types to be Functional and Non-Functional and		o Changed requirement types to be Functional and Non-Functional and
	added text to explain the requirement types.		added text to explain the requirement types.
	o Reformulation of some text parts for more clarity.		o Reformulation of some text parts for more clarity.
	D.2. draft-ersue-constrained-mgmt-02-03		A.3. draft-ersue-constrained-mgmt-02-03
	o Extended the terminology section and removed some of the		o Extended the terminology section and removed some of the
	terminology addressed in the new LWIG terminology draft.		terminology addressed in the new LWIG terminology draft.
	Referenced the LWIG terminology draft.		Referenced the LWIG terminology draft.
	o Moved Section 1.3. on Constrained Device Classes to the new LWIG		o Moved Section 1.3. on Constrained Device Classes to the new LWIG
	terminology draft.		terminology draft.
	o Class of networks considering the different type of radio and		o Class of networks considering the different type of radio and
	communication technologies in use and dimensions extended.		communication technologies in use and dimensions extended.
	skipping to change at page 54, line 28		skipping to change at page 50, line 9
	* Software distribution (group-based firmware update) and Group-		* Software distribution (group-based firmware update) and Group-
	based provisioning.		based provisioning.
	o Deleted the empty section on the gaps in network management		o Deleted the empty section on the gaps in network management
	standards, as it will be written in a separate draft.		standards, as it will be written in a separate draft.
	o Added links to mentioned external pages.		o Added links to mentioned external pages.
	o Added text on OMA M2M Device Classification in appendix.		o Added text on OMA M2M Device Classification in appendix.
	D.3. draft-ersue-constrained-mgmt-01-02		A.4. draft-ersue-constrained-mgmt-01-02
	o Extended the terminology section.		o Extended the terminology section.
	o Added additional text for the use cases concerning deployment		o Added additional text for the use cases concerning deployment
	type, network topology in use, network size, network capabilities,		type, network topology in use, network size, network capabilities,
	radio technology, etc.		radio technology, etc.
	o Added examples for device classes in a use case.		o Added examples for device classes in a use case.
	o Added additional text provided by Cao Zhen (China Mobile) for		o Added additional text provided by Cao Zhen (China Mobile) for
	skipping to change at page 55, line 16		skipping to change at page 50, line 44
	management matched to management tasks like fault, monitoring,		management matched to management tasks like fault, monitoring,
	configuration management, Security and Access Control, Energy		configuration management, Security and Access Control, Energy
	Management, etc.		Management, etc.
	o Solved nits and added references.		o Solved nits and added references.
	o Added Appendix A on the related development in other bodies.		o Added Appendix A on the related development in other bodies.
	o Added Appendix B on the work in related research projects.		o Added Appendix B on the work in related research projects.
	D.4. draft-ersue-constrained-mgmt-00-01		A.5. draft-ersue-constrained-mgmt-00-01
	o Splitted the section on 'Networks of Constrained Devices' into the		o Splitted the section on 'Networks of Constrained Devices' into the
	sections 'Network Topology Options' and 'Management Topology		sections 'Network Topology Options' and 'Management Topology
	Options'.		Options'.
	o Added the use case 'Community Network Applications' and 'Mobile		o Added the use case 'Community Network Applications' and 'Mobile
	Applications'.		Applications'.
	o Provided a Contributors section.		o Provided a Contributors section.
End of changes. 131 change blocks.
	505 lines changed or deleted		370 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/