draft-ietf-roll-building-routing-reqs-08.txt		draft-ietf-roll-building-routing-reqs-09.txt
	Networking Working Group J. Martocci, Ed.		Networking Working Group J. Martocci, Ed.
	Internet-Draft Johnson Controls Inc.		Internet-Draft Johnson Controls Inc.
	Intended status: Informational Pieter De Mil		Intended status: Informational Pieter De Mil
	Expires: June 2, 2010 Ghent University IBCN		Expires: July 28, 2010 Ghent University IBCN
	W. Vermeylen		W. Vermeylen
	Arts Centre Vooruit		Arts Centre Vooruit
	Nicolas Riou		Nicolas Riou
	Schneider Electric		Schneider Electric
	December 2, 2009		January 28, 2010
	Building Automation Routing Requirements in Low Power and Lossy		Building Automation Routing Requirements in Low Power and Lossy
	Networks		Networks
	draft-ietf-roll-building-routing-reqs-08		draft-ietf-roll-building-routing-reqs-09
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 2, 2010.		This Internet-Draft will expire on July 28, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Abstract		Abstract
	The Routing Over Low power and Lossy network (ROLL) Working Group has		The Routing Over Low power and Lossy network (ROLL) Working Group has
	been chartered to work on routing solutions for Low Power and Lossy		been chartered to work on routing solutions for Low Power and Lossy
	networks (LLN) in various markets: Industrial, Commercial (Building),		networks (LLN) in various markets: Industrial, Commercial (Building),
	Home and Urban networks. Pursuant to this effort, this document		Home and Urban networks. Pursuant to this effort, this document
	defines the IPv6 routing requirements for building automation.		defines the IPv6 routing requirements for building automation.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in (RFC2119).		document are to be interpreted as described in (RFC2119).
	Table of Contents		Table of Contents
	1. Terminology....................................................4		1. Terminology....................................................4
	2. Introduction...................................................4		2. Introduction...................................................4
	3. Overview of Building Automation Networks.......................5		3. Overview of Building Automation Networks.......................6
	3.1. Introduction..............................................5		3.1. Introduction..............................................6
	3.2. Building Systems Equipment................................7		3.2. Building Systems Equipment................................7
	3.2.1. Sensors/Actuators....................................7		3.2.1. Sensors/Actuators....................................7
	3.2.2. Area Controllers.....................................7		3.2.2. Area Controllers.....................................7
	3.2.3. Zone Controllers.....................................7		3.2.3. Zone Controllers.....................................7
	3.3. Equipment Installation Methods............................8		3.3. Equipment Installation Methods............................8
	3.4. Device Density............................................8		3.4. Device Density............................................8
	3.4.1. HVAC Device Density..................................8		3.4.1. HVAC Device Density..................................9
	3.4.2. Fire Device Density..................................9		3.4.2. Fire Device Density..................................9
	3.4.3. Lighting Device Density..............................9		3.4.3. Lighting Device Density..............................9
	3.4.4. Physical Security Device Density.....................9		3.4.4. Physical Security Device Density.....................9
	4. Traffic Pattern...............................................10		4. Traffic Pattern...............................................10
	5. Building Automation Routing Requirements......................11		5. Building Automation Routing Requirements......................11
	5.1. Device and Network Commissioning.........................11		5.1. Device and Network Commissioning.........................12
	5.1.1. Zero-Configuration Installation.....................12		5.1.1. Zero-Configuration Installation.....................12
	5.1.2. Local Testing.......................................12		5.1.2. Local Testing.......................................12
	5.1.3. Device Replacement..................................12		5.1.3. Device Replacement..................................12
	5.2. Scalability..............................................13		5.2. Scalability..............................................13
	5.2.1. Network Domain......................................13		5.2.1. Network Domain......................................13
	5.2.2. Peer-to-Peer Communication..........................13		5.2.2. Peer-to-Peer Communication..........................13
	5.3. Mobility.................................................13		5.3. Mobility.................................................13
	5.3.1. Mobile Device Requirements..........................14		5.3.1. Mobile Device Requirements..........................14
	5.4. Resource Constrained Devices.............................14		5.4. Resource Constrained Devices.............................15
	5.4.1. Limited Memory Footprint on Host Devices............14		5.4.1. Limited Memory Footprint on Host Devices............15
	5.4.2. Limited Processing Power for Routers................15		5.4.2. Limited Processing Power for Routers................15
	5.4.3. Sleeping Devices....................................15		5.4.3. Sleeping Devices....................................15
	5.5. Addressing...............................................15		5.5. Addressing...............................................16
	5.6. Manageability............................................16		5.6. Manageability............................................16
	5.6.1. Diagnostics.........................................16		5.6.1. Diagnostics.........................................17
	5.6.2. Route Tracking......................................17		5.6.2. Route Tracking......................................17
	5.7. Route Selection..........................................17		5.7. Route Selection..........................................17
	5.7.1. Route Cost..........................................17		5.7.1. Route Cost..........................................17
	5.7.2. Route Adaptation....................................17		5.7.2. Route Adaptation....................................18
	5.7.3. Route Redundancy....................................17		5.7.3. Route Redundancy....................................18
	5.7.4. Route Discovery Time................................18		5.7.4. Route Discovery Time................................18
	5.7.5. Route Preference....................................18		5.7.5. Route Preference....................................18
	5.7.6. Real-time Performance Measures......................18		5.7.6. Real-time Performance Measures......................18
	5.7.7. Prioritized Routing.................................18		5.7.7. Prioritized Routing.................................18
	5.8. Security Requirements....................................18		5.8. Security Requirements....................................19
	5.8.1. Authentication......................................19		5.8.1. Building Security Use Case..........................19
	5.8.2. Encryption..........................................19		5.8.2. Authentication......................................20
	5.8.3. Disparate Security Policies.........................20		5.8.3. Encryption..........................................20
	5.8.4. Routing Security Policies To Sleeping Devices.......20		5.8.4. Disparate Security Policies.........................21
	6. Security Considerations.......................................20		5.8.5. Routing Security Policies To Sleeping Devices.......21
	7. IANA Considerations...........................................21		6. Security Considerations.......................................21
	8. Acknowledgments...............................................21		7. IANA Considerations...........................................22
	9. References....................................................21		8. Acknowledgments...............................................22
	9.1. Normative References.....................................21		9. Disclaimer for pre-RFC5378 work...............................22
	9.2. Informative References...................................21		10. References...................................................22
	10. Appendix A: Additional Building Requirements.................21		10.1. Normative References....................................22
	10.1. Additional Commercial Product Requirements..............22		10.2. Informative References..................................23
	10.1.1. Wired and Wireless Implementations.................22		11. Appendix A: Additional Building Requirements.................23
	10.1.2. World-wide Applicability...........................22		11.1. Additional Commercial Product Requirements..............23
	10.2. Additional Installation and Commissioning Requirements..22		11.1.1. Wired and Wireless Implementations.................23
	10.2.1. Unavailability of an IP network....................22		11.1.2. World-wide Applicability...........................23
	10.3. Additional Network Requirements.........................22		11.2. Additional Installation and Commissioning Requirements..23
	10.3.1. TCP/UDP............................................22		11.2.1. Unavailability of an IP network....................23
	10.3.2. Interference Mitigation............................22
	10.3.3. Packet Reliability.................................22		11.3. Additional Network Requirements.........................23
	10.3.4. Merging Commissioned Islands.......................23		11.3.1. TCP/UDP............................................23
	10.3.5. Adjustable Routing Table Sizes.....................23		11.3.2. Interference Mitigation............................24
	10.3.6. Automatic Gain Control.............................23		11.3.3. Packet Reliability.................................24
	10.3.7. Device and Network Integrity.......................23		11.3.4. Merging Commissioned Islands.......................24
	10.4. Additional Performance Requirements.....................23		11.3.5. Adjustable Routing Table Sizes.....................24
	10.4.1. Data Rate Performance..............................23		11.3.6. Automatic Gain Control.............................24
	10.4.2. Firmware Upgrades..................................23		11.3.7. Device and Network Integrity.......................24
	10.4.3. Route Persistence..................................24		11.4. Additional Performance Requirements.....................25
	11. Authors' Addresses...........................................25		11.4.1. Data Rate Performance..............................25
			11.4.2. Firmware Upgrades..................................25
			11.4.3. Route Persistence..................................25
			12. Authors' Addresses...........................................26
	1. Terminology		1. Terminology
	For description of the terminology used in this specification, please		For description of the terminology used in this specification, please
	see [I-D.ietf-roll-terminology].		see [I-D.ietf-roll-terminology].
	2. Introduction		2. Introduction
	The Routing Over Low power and Lossy network (ROLL) Working Group has		The Routing Over Low power and Lossy network (ROLL) Working Group has
	been chartered to work on routing solutions for Low Power and Lossy		been chartered to work on routing solutions for Low Power and Lossy
	skipping to change at page 6, line 8		skipping to change at page 6, line 16
	3.1. Introduction		3.1. Introduction
	To understand the network systems requirements of a facility		To understand the network systems requirements of a facility
	management system in a commercial building, this document uses a		management system in a commercial building, this document uses a
	framework to describe the basic functions and composition of the		framework to describe the basic functions and composition of the
	system. An FMS is a hierarchical system of sensors, actuators,		system. An FMS is a hierarchical system of sensors, actuators,
	controllers and user interface devices that interoperate to provide a		controllers and user interface devices that interoperate to provide a
	safe and comfortable environment while constraining energy costs.		safe and comfortable environment while constraining energy costs.
	An FMS may is divided functionally across alike, but different		An FMS is divided functionally across alike, but different building
	building subsystems such as heating, ventilation and air conditioning		subsystems such as heating, ventilation and air conditioning (HVAC);
	(HVAC); Fire; Security; Lighting; Shutters and Elevator/Lift control		Fire; Security; Lighting; Shutters and Elevator/Lift control systems
	systems as denoted in Figure 1.		as denoted in Figure 1.
	Much of the makeup of an FMS is optional and installed at the behest		Much of the makeup of an FMS is optional and installed at the behest
	of the customer. Sensors and actuators have no standalone		of the customer. Sensors and actuators have no standalone
	functionality. All other devices support partial or complete		functionality. All other devices support partial or complete
	standalone functionality. These devices can optionally be tethered		standalone functionality. These devices can optionally be tethered
	to form a more cohesive system. The customer requirements dictate		to form a more cohesive system. The customer requirements dictate
	the level of integration within the facility. This architecture		the level of integration within the facility. This architecture
	provides excellent fault tolerance since each node is designed to		provides excellent fault tolerance since each node is designed to
	operate in an independent mode if the higher layers are unavailable.		operate in an independent mode if the higher layers are unavailable.
	skipping to change at page 8, line 7		skipping to change at page 8, line 10
	Zone Control may have direct sensor inputs (smoke detectors for		Zone Control may have direct sensor inputs (smoke detectors for
	fire), controller inputs (room controllers for air-handlers in HVAC)		fire), controller inputs (room controllers for air-handlers in HVAC)
	or both (door controllers and tamper sensors for security). Like		or both (door controllers and tamper sensors for security). Like
	area/room controllers, zone controllers are standalone devices that		area/room controllers, zone controllers are standalone devices that
	operate independently or may be attached to the larger network for		operate independently or may be attached to the larger network for
	more synergistic control.		more synergistic control.
	3.3. Equipment Installation Methods		3.3. Equipment Installation Methods
	Commercial controllers have been traditionally deployed in a facility		An FMS is installed very differently from most other IT networks. IT
	using serial media following the EIA-485 electrical standard		networks are typically installed as an overlay onto the existing
	operating nominally at 76800 baud with distances upward to 15000		environment and are installed from the inside out. That is, the
	feet. EIA-485 is a multi-drop media allowing upwards to 255 devices		network wiring infrastructure is installed; the switches, routers and
	to be connected to a single trunk.		servers are connected and made operational; and finally the endpoints
			(e.g., PCs, VoIP phones) added.
	Wired FMS installation is a multifaceted procedure depending on the
	extent of the system and the software interoperability requirement.
	However, at the sensor/actuator and controller level, the procedure
	is typically a two or three step process.
	The installer arrives on-site during the construction of the building		FMS systems, on the other hand, are installed from the outside in.
	prior to drywall and ceiling installation. The installer allocates		That is, the endpoints (thermostats, lights, smoke detectors) are
	wall space installs the controller and sensor networks. The Building		installed in the spaces first; local control is established in each
	Controllers and Enterprise network are not normally installed until		room and tested for proper operation. The individual rooms are later
	months later. The electrician completes the task by running a		lashed together into a subsystem (e.g. Lighting). The individual
	verification procedure that verifies proper wired or wireless		subsystems (e.g., lighting, HVAC) then coalesce. Later the entire
	continuity between the devices.		system may be merged onto the enterprise network.
	Months later, the higher order controllers are installed, programmed		The rational for this is partly due to the different construction
	and commissioned together with the previously installed sensors,		trades having access to a building under construction at different
	actuators and controllers. In most cases the IP network is still not		times. The sheer size of a building often dictates that even a
	in place. The Building Controllers are completely commissioned using		single trade may have multiple independent teams working
	a crossover cable or a temporary IP switch together with static IP		simultaneously. Furthermore, the HVAC, lighting and fire systems
	addresses.		must be fully operational before the building can obtain its
			occupancy permit. Hence, the FMS must be in place and configured
			well before any of the IT servers (DHCP, AAA, DNS, etc) are
			operational.
	After occupancy, when the IP network is operational, the FMS often		This implies that the FMS cannot rely on the availability of the IT
	connects to the enterprise network. Dynamic IPs replace static IPs.		network infrastructure or application servers. Rather, the FMS
	VLANs oft time segregate the facility and IT systems. For multi-		installation should be planned to dovetail to the IT system once the
	building multi-site facilities VPNs, NATs and firewalls are also		IT system is available for easy migration onto the IT network.
	introduced.		Front-end planning of available switch ports, cable runs, AP
			placement, firewalls and security policies will facilitate this
			adoption.
	3.4. Device Density		3.4. Device Density
	Device density differs depending on the application and as dictated		Device density differs depending on the application and as dictated
	by the local building code requirements. The following sections		by the local building code requirements. The following sections
	detail typical installation densities for different applications.		detail typical installation densities for different applications.
	3.4.1. HVAC Device Density		3.4.1. HVAC Device Density
	HVAC room applications typically have sensors/actuators and		HVAC room applications typically have sensors/actuators and
	skipping to change at page 13, line 32		skipping to change at page 13, line 32
	5.2.2. Peer-to-Peer Communication		5.2.2. Peer-to-Peer Communication
	The data domain for commercial FMS systems may sprawl across a vast		The data domain for commercial FMS systems may sprawl across a vast
	portion of the physical domain. For example, a chiller may reside in		portion of the physical domain. For example, a chiller may reside in
	the facility's basement due to its size, yet the associated cooling		the facility's basement due to its size, yet the associated cooling
	towers will reside on the roof. The cold-water supply and return		towers will reside on the roof. The cold-water supply and return
	pipes serpentine through all the intervening floors. The feedback		pipes serpentine through all the intervening floors. The feedback
	control loops for these systems require data from across the		control loops for these systems require data from across the
	facility.		facility.
	A network device MUST be able to communicate in a end-to-end manner		A network device MUST be able to communicate in an end-to-end manner
	with any other device on the network. Thus, the routing protocol MUST		with any other device on the network. Thus, the routing protocol MUST
	provide routes between arbitrary hosts within the appropriate		provide routes between arbitrary hosts within the appropriate
	administrative domain.		administrative domain.
	5.3. Mobility		5.3. Mobility
	Most devices are affixed to walls or installed on ceilings within		Most devices are affixed to walls or installed on ceilings within
	buildings. Hence the mobility requirements for commercial buildings		buildings. Hence the mobility requirements for commercial buildings
	are few. However, in wireless environments location tracking of		are few. However, in wireless environments location tracking of
	occupants and assets is gaining favor. Asset tracking applications,		occupants and assets is gaining favor. Asset tracking applications,
	such as tracking capital equipment (e.g., wheel chairs) in medical		such as tracking capital equipment (e.g., wheel chairs) in medical
	facilities, require monitoring movement with granularity of a minute.		facilities, require monitoring movement with granularity of a minute;
	This soft real-time performance requirement is reflected in the		however tracking babies in a pediatric ward would require latencies
	performance requirements below.		less than a few seconds.
			The following subsections document the mobility requirements in the
			routing layer for mobile devices. Note however; that mobility can be
			implemented at various layers of the system, and the specific
			requirements depend on the chosen layer. For instance, some devices
			may not depend on a static IP address and are capable of re-
			establishing application-level communications when given a new IP
			address. Alternatively, mobile IP may be used or the set of routers
			in a building may give an impression of a building-wide network and
			allow devices to retain their addresses regardless of where they are,
			handling routing between the devices in the background.
	5.3.1. Mobile Device Requirements		5.3.1. Mobile Device Requirements
	To minimize network dynamics, mobile devices should not be allowed to		To minimize network dynamics, mobile devices while in motion should
	act as forwarding devices (routers) for other devices in the LLN.		not be allowed to act as forwarding devices (routers) for other
	Network configuration should allow devices to be configured as		devices in the LLN. Network configuration should allow devices to be
	routers or hosts.		configured as routers or hosts.
	5.3.1.1. Device Mobility within the LLN		5.3.1.1. Device Mobility within the LLN
	An LLN typically spans a single floor in a commercial building.		An LLN typically spans a single floor in a commercial building.
	Mobile devices may move within this LLN. For example, a wheel chair		Mobile devices may move within this LLN. For example, a wheel chair
	may be moved from one room on the floor to another room on the same		may be moved from one room on the floor to another room on the same
	floor.		floor.
	A mobile LLN device that moves within the confines of the same LLN		A mobile LLN device that moves within the confines of the same LLN
	SHOULD reestablish end-to-end communication to a fixed device also in		SHOULD reestablish end-to-end communication to a fixed device also in
	skipping to change at page 17, line 7		skipping to change at page 17, line 20
	placed in and out of 'verbose' mode. Verbose mode is a temporary		placed in and out of 'verbose' mode. Verbose mode is a temporary
	debugging mode that provides additional communication information		debugging mode that provides additional communication information
	including at least total number of routed packets sent and received,		including at least total number of routed packets sent and received,
	number of routing failures (no route available), neighbor table		number of routing failures (no route available), neighbor table
	members, and routing table entries. The data provided in verbose		members, and routing table entries. The data provided in verbose
	mode should be sufficient that a network connection graph could be		mode should be sufficient that a network connection graph could be
	constructed and maintained by the monitoring node.		constructed and maintained by the monitoring node.
	Diagnostic data should be kept by the routers continuously and be		Diagnostic data should be kept by the routers continuously and be
	available for solicitation at anytime by any other node on the		available for solicitation at anytime by any other node on the
	internetwork. Verbose mode will be activated/deactivated via either		internetwork. Verbose mode will be activated/deactivated via a
	a unicast, multicast or other means. Devices having available		unicast, multicast or other means. Devices having available
	resources may elect to support verbose mode continually.		resources may elect to support verbose mode continually.
	5.6.2. Route Tracking		5.6.2. Route Tracking
	Route diagnostics SHOULD be supported providing information such as		Route diagnostics SHOULD be supported providing information such as
	route quality; number of hops; available alternate active routes with		route quality; number of hops; available alternate active routes with
	associated costs. Route quality is the relative measure of		associated costs. Route quality is the relative measure of
	'goodness' of the selected source to destination route as compared to		'goodness' of the selected source to destination route as compared to
	alternate routes. This composite value may be measured as a function		alternate routes. This composite value may be measured as a function
	of hop count, signal strength, available power, existing active		of hop count, signal strength, available power, existing active
	skipping to change at page 18, line 25		skipping to change at page 18, line 36
	5.7.5. Route Preference		5.7.5. Route Preference
	The routing protocol SHOULD allow for the support of manually		The routing protocol SHOULD allow for the support of manually
	configured static preferred routes.		configured static preferred routes.
	5.7.6. Real-time Performance Measures		5.7.6. Real-time Performance Measures
	A node transmitting a 'request with expected reply' to another node		A node transmitting a 'request with expected reply' to another node
	must send the message to the destination and receive the response in		must send the message to the destination and receive the response in
	not more than 120 ms. This response time should be achievable with 5		not more than 120ms. This response time should be achievable with 5
	or less hops in each direction. This requirement assumes network		or less hops in each direction. This requirement assumes network
	quiescence and a negligible turnaround time at the destination node.		quiescence and a negligible turnaround time at the destination node.
	5.7.7. Prioritized Routing		5.7.7. Prioritized Routing
	Network and application packet routing prioritization must be		Network and application packet routing prioritization must be
	supported to assure that mission critical applications (e.g., Fire		supported to assure that mission critical applications (e.g., Fire
	Detection) cannot be deferred while less critical applications access		Detection) cannot be deferred while less critical applications access
	the network. The routing protocol MUST be able to provide routes		the network. The routing protocol MUST be able to provide routes
	with different characteristics, also referred to as "QoS" routing.		with different characteristics, also referred to as "QoS" routing.
	5.8. Security Requirements		5.8. Security Requirements
	Security policies, especially wireless encryption and device		Due to the variety of buildings and tenants, the FMS systems must be
	authentication needs to be considered, especially with concern to the		completely configurable on-site.
	impact on the processing capabilities and additional latency incurred
	on the sensors, actuators and controllers.		Due to the quantity of the BMS devices (1000s) and their
			inaccessibility (often times above the ceilings) security
			configuration over the network is preferred over local configuration
			Wireless encryption and device authentication security policies need
			to be considered in commercial buildings, while keeping in mind the
			impact on the limited processing capabilities and additional latency
			incurred on the sensors, actuators and controllers.
	FMS systems are typically highly configurable in the field and hence		FMS systems are typically highly configurable in the field and hence
	the security policy is most often dictated by the type of building to		the security policy is most often dictated by the type of building to
	which the FMS is being installed. Single tenant owner occupied		which the FMS is being installed. Single tenant owner occupied
	office buildings installing lighting or HVAC control are candidates		office buildings installing lighting or HVAC control are candidates
	for implementing a low level of security on the LLN. Antithetically,		for implementing a low level of security on the LLN. Antithetically,
	military or pharmaceutical facilities require strong security		military or pharmaceutical facilities require strong security
	policies. As noted in the installation procedures, security policies		policies.
	must be facile to allow for no security policy during the
	installation phase (prior to building occupancy), yet easily raise
	the security level network wide during the commissioning phase of the
	system.
	5.8.1. Authentication		5.8.1. Building Security Use Case
			LLNs for commercial building applications would always implement and
			use encrypted packets. However, depending on the state of the LLN,
			the security keys may either be:
			1) a key obtained from a trust center already operable on the LLN;
			2) a pre-shared static key as defined by the general contractor or
			its designee or
			3)a well-known default static key.
			Unless a node entering the network had previously received its
			credentials from the trust center, the entering node will try to
			solicit the trust center for the network key. If the trust center is
			accessible, the trust center will MAC authenticate the entering node
			and return the security keys. If the Trust Center is not available,
			the entering node will check if it has been given a network key in an
			off-band means and use it to access the network. If no network key
			has been configured in the device it will revert to the default
			network key and enter the network. If neither of these keys were
			valid, the device would signal via a fault LED.
			This approach would allow for independent simplified commissioning,
			yet centralized authentication. The building owner or building type
			would then dictate when the trust center would be deployed. In many
			cases the trust center need not be deployed until all the local room
			commissioning was complete. Yet at the province of the owner, the
			trust center may be deployed from the onset thereby trading
			installation and commissioning flexibility for tighter security.
			5.8.2. Authentication
	Authentication SHOULD be optional on the LLN. Authentication SHOULD		Authentication SHOULD be optional on the LLN. Authentication SHOULD
	be fully configurable on-site. Authentication policy and updates MUST		be fully configurable on-site. Authentication policy and updates MUST
	be routable over-the-air. Authentication SHOULD occur upon joining		be routable over-the-air. Authentication SHOULD occur upon joining
	or rejoining a network. However, once authenticated devices SHOULD		or rejoining a network. However, once authenticated devices SHOULD
	NOT need to reauthenticate with any other devices in the LLN.		NOT need to reauthenticate with any other devices in the LLN.
	Packets may need authentication at the source and destination nodes,		Packets may need authentication at the source and destination nodes,
	however, packets routed through intermediate hops should not need		however, packets routed through intermediate hops should not need
	reauthentication at each hop.		reauthentication at each hop.
	These requirements mean that at least one LLN routing protocol		These requirements mean that at least one LLN routing protocol
	solution specification MUST include support for authentication.		solution specification MUST include support for authentication.
	5.8.2. Encryption		5.8.3. Encryption
	5.8.2.1. Encryption Types		5.8.3.1. Encryption Types
	Data encryption of packets MUST be supported by all protocol solution		Data encryption of packets MUST be supported by all protocol solution
	specifications. Support can be provided by use of either a network		specifications. Support can be provided by use of either a network
	wide key and/or an application key. The network key would apply to		wide key and/or an application key. The network key would apply to
	all devices in the LLN. The application key would apply to a subset		all devices in the LLN. The application key would apply to a subset
	of devices on the LLN.		of devices on the LLN.
	The network key and application keys would be mutually exclusive.		The network key and application keys would be mutually exclusive.
	The routing protocol MUST allow routing a packet encrypted with an		The routing protocol MUST allow routing a packet encrypted with an
	application key through forwarding devices without requiring each		application key through forwarding devices without requiring each
	node in the route to have the application key.		node in the route to have the application key.
	5.8.2.2. Packet Encryption		5.8.3.2. Packet Encryption
	The encryption policy MUST support both encryption of the payload		The encryption policy MUST support both encryption of the payload
	only or of the entire packet. Payload only encryption would		only or of the entire packet. Payload only encryption would
	eliminate the decryption/re-encryption overhead at every hop		eliminate the decryption/re-encryption overhead at every hop
	providing more real-time performance.		providing more real-time performance.
	5.8.3. Disparate Security Policies		5.8.4. Disparate Security Policies
	Due to the limited resources of an LLN, the security policy defined		Due to the limited resources of an LLN, the security policy defined
	within the LLN MUST be able to differ from that of the rest of the IP		within the LLN MUST be able to differ from that of the rest of the IP
	network within the facility yet packets MUST still be able to route		network within the facility yet packets MUST still be able to route
	to or through the LLN from/to these networks.		to or through the LLN from/to these networks.
	5.8.4. Routing Security Policies To Sleeping Devices		5.8.5. Routing Security Policies To Sleeping Devices
	The routing protocol MUST gracefully handle routing temporal security		The routing protocol MUST gracefully handle routing temporal security
	updates (e.g., dynamic keys) to sleeping devices on their 'awake'		updates (e.g., dynamic keys) to sleeping devices on their 'awake'
	cycle to assure that sleeping devices can readily and efficiently		cycle to assure that sleeping devices can readily and efficiently
	access the network.		access the network.
	6. Security Considerations		6. Security Considerations
	The requirements placed on the LLN routing protocol in order to		The requirements placed on the LLN routing protocol in order to
	provide the correct level of security support are presented in		provide the correct level of security support are presented in
	skipping to change at page 21, line 18		skipping to change at page 22, line 18
	7. IANA Considerations		7. IANA Considerations
	This document includes no request to IANA.		This document includes no request to IANA.
	8. Acknowledgments		8. Acknowledgments
	In addition to the authors; JP. Vasseur, David Culler, Ted Humpal and		In addition to the authors; JP. Vasseur, David Culler, Ted Humpal and
	Zach Shelby are gratefully acknowledged for their contributions to		Zach Shelby are gratefully acknowledged for their contributions to
	this document.		this document.
	9. References		9. Disclaimer for pre-RFC5378 work
	9.1. Normative References		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
			10. References
			10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-roll-terminology]Vasseur, JP., "Terminology in Low power		[I-D.ietf-roll-terminology]Vasseur, JP., "Terminology in Low power
	And Lossy Networks", draft-ietf-roll-terminology-00 (work in		And Lossy Networks", draft-ietf-roll-terminology-00 (work in
	progress), October 2008.		progress), October 2008.
	10. Appendix A: Additional Building Requirements		11. Appendix A: Additional Building Requirements
	Appendix A contains additional building requirements that were deemed		Appendix A contains additional building requirements that were deemed
	out of scope for ROLL, yet provided ancillary substance for the		out of scope for ROLL, yet provided ancillary substance for the
	reader.		reader.
	10.1. Additional Commercial Product Requirements		11.1. Additional Commercial Product Requirements
	10.1.1. Wired and Wireless Implementations		11.1.1. Wired and Wireless Implementations
	Vendors will likely not develop a separate product line for both		Vendors will likely not develop a separate product line for both
	wired and wireless networks. Hence, the solutions set forth must		wired and wireless networks. Hence, the solutions set forth must
	support both wired and wireless implementations.		support both wired and wireless implementations.
	10.1.2. World-wide Applicability		11.1.2. World-wide Applicability
	Wireless devices must be supportable unlicensed bands.		Wireless devices must be supportable unlicensed bands.
	10.2. Additional Installation and Commissioning Requirements		11.2. Additional Installation and Commissioning Requirements
	10.2.1. Unavailability of an IP network		11.2.1. Unavailability of an IP network
	Product commissioning must be performed by an application engineer		Product commissioning must be performed by an application engineer
	prior to the installation of the IP network (e.g., switches, routers,		prior to the installation of the IP network (e.g., switches, routers,
	DHCP, DNS).		DHCP, DNS).
	10.3. Additional Network Requirements		11.3. Additional Network Requirements
	10.3.1. TCP/UDP		11.3.1. TCP/UDP
	Connection based and connectionless services must be supported		Connection based and connectionless services must be supported
	10.3.2. Interference Mitigation		11.3.2. Interference Mitigation
	The network must automatically detect interference and seamlessly		The network must automatically detect interference and seamlessly
	migrate the network hosts channel to improve communication. Channel		migrate the network hosts channel to improve communication. Channel
	changes and nodes response to the channel change must occur within 60		changes and nodes response to the channel change must occur within 60
	seconds.		seconds.
	10.3.3. Packet Reliability		11.3.3. Packet Reliability
	In building automation, it is required for the network to meet the		In building automation, it is required for the network to meet the
	following minimum criteria:		following minimum criteria:
	< 1% MAC layer errors on all messages; After no more than three		< 1% MAC layer errors on all messages; After no more than three
	retries		retries
	< .1% Network layer errors on all messages;		< .1% Network layer errors on all messages;
	After no more than three additional retries;		After no more than three additional retries;
	< 0.01% Application layer errors on all messages.		< 0.01% Application layer errors on all messages.
	Therefore application layer messages will fail no more than once		Therefore application layer messages will fail no more than once
	every 100,000 messages.		every 100,000 messages.
	10.3.4. Merging Commissioned Islands		11.3.4. Merging Commissioned Islands
	Subsystems are commissioned by various vendors at various times		Subsystems are commissioned by various vendors at various times
	during building construction. These subnetworks must seamlessly		during building construction. These subnetworks must seamlessly
	merge into networks and networks must seamlessly merge into		merge into networks and networks must seamlessly merge into
	internetworks since the end user wants a holistic view of the system.		internetworks since the end user wants a holistic view of the system.
	10.3.5. Adjustable Routing Table Sizes		11.3.5. Adjustable Routing Table Sizes
	The routing protocol must allow constrained nodes to hold an		The routing protocol must allow constrained nodes to hold an
	abbreviated set of routes. That is, the protocol should not mandate		abbreviated set of routes. That is, the protocol should not mandate
	that the node routing tables be exhaustive.		that the node routing tables be exhaustive.
	10.3.6. Automatic Gain Control		11.3.6. Automatic Gain Control
	For wireless implementations, the device radios should incorporate		For wireless implementations, the device radios should incorporate
	automatic transmit power regulation to maximize packet transfer and		automatic transmit power regulation to maximize packet transfer and
	minimize network interference regardless of network size or density.		minimize network interference regardless of network size or density.
	10.3.7. Device and Network Integrity		11.3.7. Device and Network Integrity
	Commercial Building devices must all be periodically scanned to		Commercial Building devices must all be periodically scanned to
	assure that the device is viable and can communicate data and alarm		assure that the device is viable and can communicate data and alarm
	information as needed. Router should maintain previous packet flow		information as needed. Router should maintain previous packet flow
	information temporally to minimize overall network overhead.		information temporally to minimize overall network overhead.
	10.4. Additional Performance Requirements		11.4. Additional Performance Requirements
	10.4.1. Data Rate Performance		11.4.1. Data Rate Performance
	An effective data rate of 20kbits/s is the lowest acceptable		An effective data rate of 20kbits/s is the lowest acceptable
	operational data rate acceptable on the network.		operational data rate acceptable on the network.
	10.4.2. Firmware Upgrades		11.4.2. Firmware Upgrades
	To support high speed code downloads, routing should support		To support high speed code downloads, routing should support
	transports that provide parallel downloads to targeted devices yet		transports that provide parallel downloads to targeted devices yet
	guarantee packet delivery. In cases where the spatial position of		guarantee packet delivery. In cases where the spatial position of
	the devices requires multiple hops, the algorithm should recurse		the devices requires multiple hops, the algorithm should recurse
	through the network until all targeted devices have been serviced.		through the network until all targeted devices have been serviced.
	Devices receiving a download may cease normal operation, but upon		Devices receiving a download may cease normal operation, but upon
	completion of the download must automatically resume normal		completion of the download must automatically resume normal
	operation.		operation.
	10.4.3. Route Persistence		11.4.3. Route Persistence
	To eliminate high network traffic in power-fail or brown-out		To eliminate high network traffic in power-fail or brown-out
	conditions previously established routes should be remembered and		conditions previously established routes should be remembered and
	invoked prior to establishing new routes for those devices reentering		invoked prior to establishing new routes for those devices reentering
	the network.		the network.
	11. Authors' Addresses		12. Authors' Addresses
	Jerry Martocci		Jerry Martocci
	Johnson Control		Johnson Control
	507 E. Michigan Street		507 E. Michigan Street
	Milwaukee, Wisconsin, 53202		Milwaukee, Wisconsin, 53202
	USA		USA
	Phone: +1 414 524 4010		Phone: +1 414 524 4010
	Email: jerald.p.martocci@jci.com		Email: jerald.p.martocci@jci.com
	Nicolas Riou		Nicolas Riou
End of changes. 54 change blocks.
	128 lines changed or deleted		209 lines changed or added
This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/