One document matched: draft-martocci-roll-commercial-routing-reqs-00.txt
Networking Working Group J. Martocci, Ed.
Internet-Draft Johnson Controls Inc.
Intended status: Informational July 14, 2008
Expires: January 14, 2009
Commercial Routing Requirements in Low Power and Lossy Networks
draft-martocci-roll-commercial-routing-reqs-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2009
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The ROLL Working Group was recently chartered by the IETF to define
routing characteristics for low power embedded devices. ROLL would like
to serve the Industrial, Commercial, Home and Urban markets. Pursuant to
this effort, this document defines the functional and cost requirements
for installing integrated facility management systems in commercial
facilities.
The routing requirements for commercial building applications are
presented in this document. Commercial buildings have been fitted with
pneumatic and subsequently electronic communication pathways connecting
Martocci Expires January 14, 2009 [Page 1]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
sensors to their controllers for over one hundred years. Recent economic
and technical advances in wireless communication allows facilities to
increasingly utilize a wireless solution in lieu of a wired solution;
thereby reducing installation costs yet maintaining highly reliant
communication. Wireless solutions will be adapted from their existing
wired counterparts in many of the building applications including, but
not limited to HVAC, lighting, security, fire, and elevator products.
These devices will be developed to reduce installation costs; while
increasing installation and retrofit flexibility. Sensing devices may be
battery or mains powered. Actuators and area controllers will be mains
powered.
To meet the cost target, these devices must have a total installed cost
below that of the traditional wired alternative; yet maintain reliability
on par with wired devices. The total installed cost includes the
infrastructure, product, installation, commissioning, labor and
operational costs of the device over its 30 year lifespan. Except for
special circumstances such as flexible installation (e.g. airports) or
cosmetics (e.g. museums, there is nothing compelling about installing
wireless solutions inside a building unless it can be accomplished below
the cost of a wired installation. This document will define the
requirements necessary for wireless technology to displace wired
infrastructure and meet this objective.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
TABLE OF CONTENTS
1. Terminology 3
2. Introduction 4
3. FMS Topology 5
3.1 Introduction 5
3.2 Sensors/Actuators 5
3.3 Area Controllers 5
3.4 Zone Controllers 6
4. Wired Communication Media 7
5. Wireless Communication Media 8
6. Device Spatial Deployment 9
7. Installation Procedure 10
8. Commercial Building Product Requirements 10
9. Installation/Commissioning Requirements 17
10. Networking Requirements 19
11. Security Considerations 28
11.1 Security Requirements 29
11.2 Security Use Cases 32
Martocci Expires January 14, 2009 [Page 2]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
11.2.1 No Security Threat 33
11.2.2 Low Security Threat 34
11.2.3 Medium Security Threat 35
11.2.4 High Security Threat 37
11.2.5 Very High Security Threat 39
12. Traffic Patterns 40
13. Open Issues 41
14. IANA Considerations 41
15. Acknowledgements 41
16. References 41
16.1 Normative References 41
16.2 Informative References 43
Authors' Addresses 43
Full Copyright Statement 43
Intellectual Property 4
Acknowledgment 44
1. Terminology
6LoWPAN - 6loWPAN is an acronym of IPv6 over Low power Wireless Personal
Area Networks. 6lowpan is the name of the working group in the internet
area of IETF. 6lowpan is the coupling that is aimed at allowing IPv6
packets to be sent to and received from Personal Area Networks, more
specifically over IEEE 802.15 based networks
Actuator - A field device that modulates a flow of a gas or liquid; or
controls electricity distribution..
ASHRAE - American Society of Heating, Refrigerating and Air-Conditioning
Engineers
Commissioning Tool Any physical or logical device temporarily added to
the network with the express purpose of setting up the network
operational parameters. For interoperability purposes, devices entering
the network SHOULD try to discover the commissioning tool and receive its
parametric information from it. However, devices may elect to set
themselves up by accessing other devices directly if the commissioning
tool is not available.
NOTE: This device may also set application parameters, but is out of
scope of the Network layer.
Controller - A field device that can receive sensor input and
automatically change the environment in the facility by manipulating
digital or analog actuators.
Field Device - Any physical device installed in the commercial building
environment used to monitor and/or control some portion of the facility.
Fire - The term used to describe building equipment used to monitor,
control and evacuate an internal space in case of a fire situation.
Martocci Expires January 14, 2009 [Page 3]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Equipment includes smoke detectors, pull boxes, sprinkler systems and
evacuation control.
FFD - Full Function Device. An 802.15.4 device that can route messages
across the mesh in addition to providing an end application. Most FFD
are line powered since they must always be ready to forward messages.
FMS - Facility Management System. A global term applied across all the
vertical designations within a building including, HVAC, Fire, Security,
Lighting and Elevator control.
HVAC - Heating, Ventilation and Air Conditioning. A term applied to the
comfort level of an internal space.
IETF - Internet Engineering Task Force
Intrusion Protection ? A term used to protect resources from external
infiltration. Intrusion protection systems utilize door locks, window
tampers and card readers.
LLN - Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi
Lighting - The term used to describe building equipment used to monitor
and control an internal or external lighted space. Equipment includes
occupancy sensors, light switches and ballasts.
RFD - Reduced Function Device. An 802.15.4 device that can send messages
on the network; receive messages from the network; but cannot route
messages across the network. In most cases these devices are edge
devices of the network.. RFDs may be line powered, but also can be
battery powered since they play no role on the mesh.
ROLL - Routing over Low power and Lossy networks. This IETF working
group will develop routing characteristics and rules for supporting LLNs
utilizing 6LoWPAN.
Security - The term used to describe building equipment used to monitor
and control occupant and equipment safety inside a building. Equipment
includes window tamper switches, door access systems, infrared detection
systems, and video cameras.
Sensors - A field device that monitors an environmentation condition in a
building and reports its findings to higher order devices for control and
alarming operations.
TC - Trust Center. A logical device on the network that is trusted by the
network members. The TC administers security policy.
2. Introduction
Martocci Expires January 14, 2009 [Page 4]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Facility Management Systems (FMS) are deployed in a large set of vertical
markets including universities; hospitals; government facilities; K-12;
pharmaceutical manufacturing facilities; and single-tenant or multi-
tenant office buildings. These buildings range in size from 100K sqft
structures (5 story office buildings), to 1M sqft skyscrapers (110 story
Shanghai World Financial Center) to complex government facilities
(Pentagon). The described topology is meant to be the model to be used in
all these types of environments, but clearly must be tailored to the
building class, building tenant and vertical market being served.
The following sections describe the sensor, actuator and area controller
and zone controller layers of the topology. (NOTE: The Building
Controller and Enterprise layers of the FMS are excluded from this
discussion since they typically deal in communication rates requiring IP
and WLAN communication technologies. Each section describes the basic
functionality of the layer, its networking model, power requirements and
a brief description of the communication requirements. Product and
installation cost constraints are also included.
3. FMS Topology
3.1 Introduction
To understand the network systems requirements of a facility management
system in a commercial building, this document uses a framework to
describe the basic functions and composition of the system. An FMS is a
horizontally layered system of sensors, actuators, controllers and user
interface devices. Additionally, an FMS may also be divided vertically
across alike, but different building subsystems such as HVAC, Fire,
Security, Lighting, and Elevator control systems as depicted in Figure 1.
**************************************************************************
* *
* (Note that Figure 1 does not appear in this the txt version of this *
* document. Please see the PDF version to view the figures). *
* *
**************************************************************************
Much of the makeup of an FMS is optional and installed at the behest of
the customer. Sensors and actuators have no standalone functionality.
All other layers support partial or complete standalone functionality.
These devices can optionally be tethered to form a more cohesive system.
The customer decides how much of this vertical ?silo? will be integrated
to perform the needed applications within the facility. This approach
provides excellent fault tolerance since each node is designed to operate
in an independent mode if the higher layers are unavailable.
3.2 Sensors/Actuators
As Figure 1 indicates an FMS may be composed of many functional silos
that are interoperably woven together via Building Applications. Each
silo has an array of sensors that monitor the environment and actuators
that effect the environment as determined by the upper layers of the FMS
topology. The sensors typically are the leaves of the network tree structure
providing environmental data into the system. The actuators are the
Martocci Expires January 14, 2009 [Page 5]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
sensors counterparts modifying the characteristics of the system based on
the input sensor data and the applications deployed. More recently,
sensors were wired devices deployed on closed networks.
In 1995, the BACnet protocol was released by ASHRAE that defined
interoperable objects and services within the HVAC silo. BACnet has
grown to be an international standard now including extensions for Fire,
Access, Intrusion and Lighting functions.
Another protocol widely deployed in building automation systems is
LonWorks. Lonworks was submitted to ANSI and was accepted as a standard
for control networking (ANSI/CEA-709.1-B). The protocol can be
transported over media such as twisted pair, powerlines, fiber optics and
RF.
3.3 Area Controllers
An area describes a small physical locale (300 ? 500 ft2) within a
building, typically a room. As noted in Figure 1 the HVAC, Security and
Lighting functions within a building address area or room level
applications. Area controls are fed by sensor inputs that monitor the
environmental conditions within the room. Common sensors found in many
rooms that feed the area controllers include temperature, occupancy,
lighting load, solar load and relative humidity. Sensors found in
specialized rooms (such as chemistry labs) might include air flow,
pressure, CO2 and CO particle sensors. Room actuation includes
temperature setpoint, lights and blinds/curtains.
The controllers deployed within a room are most often standalone devices
that can provide the necessary functionality without further assistance
by the higher layers of the system. However when these devices are
connected to the higher system layers, these controllers can provide
manual override, time series and event data to the higher layers for
further analysis. Likewise, the enterprise level can then override the
local control from a centralized location. When connected to the higher
layers, the controllers deploy a fail-soft algorithm that reverts to
local control if the higher order communication is lost.
3.4 Zone Controllers
Zone Control supports a similar set of characteristics as the Area
Control albeit to an extended space. A zone is normally a logical
grouping or functional division of a commercial building. A zone may
also coincidentally map to a physical locale such as a floor. Table 1
describes some examples of zones for the various functional domains
within a commercial building.
Table 1 Examples of Commercial Zones
**************************************************************************
* *
* Note Table 1 does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
Martocci Expires January 14, 2009 [Page 6]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
* *
**************************************************************************
Functional Domain - HVAC
Zone - Air Handler ? the area served by
a single fan system; typically a
floor or adjacent floors in a
building.
Functional Domain - Lighting
Zone - A bank of lights that all
operate consistently
Functional Domain - Fire
Zone - An area of a facility that will
all operate consistently for
example fed by the same fan
system; covered by the same set
of smoke detectors or follows
the same pressurization and
annunciation rules. The zone
may also be a functional
grouping when a certain area is
governed by a set of fire
dampers.
Functional Domain - Security
Zone - A subset of the building
operating in a similar fashion
for example a logical collection
of lockable doors.
Functional Domain - Shutters
Zone - Shutter control is typically
limited to windows in a room or
in a given direction. That is,
in the morning all shutters on
the East side of the building
may close.
Zone Control may have direct sensor inputs (smoke detectors for fire),
controller inputs (room controllers for air-handlers in HVAC) or both
(door controllers and tamper sensors for security). Like area/room
controllers, zone controllers are standalone devices that operate
independently or may be attached to the larger network for more
synergistic control.
Zone controllers may have some onboard sensor inputs and also provide
Martocci Expires January 14, 2009 [Page 7]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
direct actuation; however, zone controllers will also direct the actions
of its underlings via commands as well as respond to environmental
changes reported by its underlings. For example, an Air Handler
controller might directly sample the duct pressure, the supply air
temperature and return air temperature. However, it may also send
commands to other networked devices querying the outdoor air temperature
and relative humidity. Similarly, a fire panel may have all the smoke
detectors directly wired; yet send commands to other adjacent fire panels
to request their status if a fire condition arises.
4. Wired Communication Media
Commercial controllers are traditionally deployed in a facility using
twisted pair serial media following the EIA 485 electrical standard
operating nominally at 38400 to 76800 baud. This allows runs to 5000 ft
without a repeater. With the maximum of three repeaters, a single
communication trunk can serpentine 15000 ft.
Most sensors and virtually all actuators currently used in commercial
buildings are "dumb", non-communicating hardwired devices. However,
sensor buses are beginning to be deployed by vendors which are used for
smart sensors and point multiplexing. The Fire industry deploys
addressable fire devices, which usually use some form of proprietary
communication wiring driven by fire codes. Figure 2 defines the devices,
media types and protocols on the wired network.
Figure 2. Traditional Wired Media and Protocols and Controller Types
**************************************************************************
* *
* (Note that Figure 2 does not appear in this the text version of this *
* document. Please see the PDF version to view the figures). *
* *
**************************************************************************
5. Wireless Communication Media
FMS vendors are now developing product line extensions that allow sensors,
actuators, room controllers and area controllers to communicate
wirelessly. To date, the technology of choice seems to be 802.15.4 at
2.4Ghz which has data rates comparable to wired alternatives. Figure 3
defines the network parameters for wired and wireless solutions with
examples of typical connections and bit rates.
Figure 3a. Wired Network Parameters
**************************************************************************
* *
* Note Figure 3a does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
Martocci Expires January 14, 2009 [Page 8]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
* captured in text form as best as possible below... *
* *
**************************************************************************
Network Name: Sensor Bus
Media: EIA-485
Communication Rate: 9.6-76.8 kbps
Protocols Supported: BACnet MS/TP
Addressable Range: 8-bit
Typical Number of Devices Supported: 1- 16
Network Name: Field Bus
Media: EIA-485
Communication Rate: 38.4 -76.8 kbps
Protocols Supported: BACnet MS/TP
Addressable Range: 8-bit
Typical Number of Devices Supported: 1- 100
Network Name: Enterprise Bus
Media: Cat-5e
Communication Rate: 10/100 mbps
Protocols Supported: BACnet IP, Web Services, SNMP
Addressable Range: IPv4
Typical Number of Devices Supported: thousands
Figure 3b. Wireless Network Parameters
**************************************************************************
* *
* Note Figure 3b does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
**************************************************************************
Network Name: Sensor Bus
Media: 802.15.4
Communication Rate: 240 kbps
Protocols Supported: BACnet/802.15.4
Addressable Range: 8-bit
Typical Number of Devices Supported: 1- 10
Network Name: Field Bus
Media: 802.15.4
Communication Rate: 240 kbps
Protocols Supported: BACnet/802.15.4
Addressable Range: 8-bit
Typical Number of Devices Supported: 1- 100
Network Name: Enterprise Bus
Martocci Expires January 14, 2009 [Page 9]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Media: 802.11b/g
Communication Rate: 11/54 mbps
Protocols Supported: BACnet IP, Web Services, SNMP
Addressable Range: IPv4
Typical Number of Devices Supported: hundreds
6. Device Spatial Deployment
Device density differs depending on the application. HVAC room
applications typically have sensors and controllers spaced about 50ft
apart. In most cases there is a 3:1 ratio of sensors to controllers.
That is, for each room there is an installed temperature sensor, flow
sensor and damper controller for the associated room controller.
HVAC equipment room applications are quite different. An air handler
system may have a single controller with upwards to 25 sensors and
actuators within 50 ft of the air handler. A chiller or boiler is also
controlled with a single equipment controller instrumented with 25
sensors and actuators. Each of these devices would be individually
addressed. Air handlers typically serve one or two floors of the
building. Chillers and boilers may be installed per floor, but most
often service a wing, building or the entire complex via a central plant.
These numbers are typical. In special cases, such as clean rooms,
operating rooms, pharmaceuticals and labs, the ratio of sensors to
controllers can increase by a factor of three.
Tenant installations such as malls would opt for ?packaged units? where
much of the sensing and actuation is integrated into the unit. Here a
single device address would serve the entire unit.
Fire systems are much more uniformly installed with smoke detectors
installed about every 50 feet. Fire pull boxes are installed uniformly
about every 150 feet. A fire controller will service a floor or wing.
The fireman?s fire panel will service the entire building and typically
is installed in the atrium.
Lighting is also very uniformly installed with ballasts installed every
10 feet. A lighting panel typically serves 48 to 64 zones. Wired
systems typically tether many lights together into a single zone.
Wireless systems configure each fixture independently to increase
flexibility and reduce installation costs.
Security systems are non-uniformly oriented with heavy density near doors
and windows and lighter density in the building interior space. The
recent influx of interior and perimeter camera systems is increasing the
security footprint. These cameras are atypical endpoints requiring
upwards to 1mbps data rates per camera as contrasted by the few kbps
needed by most other FMS sensing equipment. To date, camera systems have
been deployed on a proprietary wired high speed network or on enterprise
VLAN. Camera compression technology now supports full-frame video over
wireless media.
Martocci Expires January 14, 2009 [Page 10]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
7. Installation Procedure
Wired FMS installation is a multifaceted procedure depending on the
extent of the system and the software interoperability. However, at the
sensor/actuator and controller level, the procedure is typically a two or
three step process.
Most FMS equipment is 24 VAC equipment that can be installed by a low-
voltage electrician. He arrives on-site during the construction of the
building prior to the sheet wall and ceiling installation. This allows
him/her to allocate wall space, easily land the equipment and run the
wired controller and sensor networks. The Building Controllers and
Enterprise network are not normally installed until months later. The
electrician completes his task by running a wire verification procedure
that shows proper continuity between the devices and proper local
operation of the devices. This workflow works presently because the
controller and sensor networks are dedicated.
Later in the installation cycle, the higher order controllers are
installed, programmed and commissioned together with the previously
installed sensors, actuators and controllers. In most cases the IP
network is still not operable. The Building Controllers are completely
commissioned using a crossover cable or a temporary IP switch together
with static IP addresses.
Once the IP network is operational, the FMS may optionally be added to
the enterprise network.
Wireless installation will necessarily need to keep the same work flow.
The electrician will install the products as before and run continuity
tests between the wireless devices to assure operation before leaving the
job. The electrician does not carry a laptop so the commissioning must
be built into the device operation.
8. Commercial Building Product Requirements
The following are the requirements for a network used to integrate
building sensor actuator and control products. Note that these
requirements may include requirements outside the scope of ROLL, yet must
be considered as part of providing IP communications of commercial
building sensing, actuating and controlling devices.
These requirements are drafted assuming that 6lowpan is the defined
base protocol. Furthermore, it is assumed that the network layer will
deploy a mesh architecture. If different protocols are developed or
6lowpan is redefined, some of the requirements will change.
**************************************************************************
* *
* Note the following table does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
Martocci Expires January 14, 2009 [Page 11]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
**************************************************************************
I. Product Requirements
1.Requirement
Solutions MUST support both wired and wireless implementations,
1. Rational
Commercial Building vendors will not support multiple product lines
differentiated only by the physical layer access deployed. Local codes and
product governance (e.g. UL, FM) will mandate wired alternatives for at least
the next decade.
2. Requirement
Wireless devices MUST be supportable at the 2.4Ghz ISM band Wireless devices
SHOULD be supportable at the 900 and 868 ISM bands as well.
2. Rational
For world-wide applicability, the 2.4gHz band must be supported.
802.15.4 also supports 900 and 868. The routing protocol should not preclude
these bands.
3. Requirement
The software stack requirements for sensors and actuators MUST be
implementable in 8-bit devices with no more than 128kb of flash memory
(including at least 32Kb for the application code) and no more than 8Kb
of RAM (including at least 1Kb RAM available for application).
The software stack requirements for room controllers SHOULD be
implementable in 8-bit devices with no more than 256kb of flash memory
(including at least 32Kb for the application code) and no more than 8Kb
of RAM (including at least 1Kb RAM available for application)
3. Rational
Existing sensors, actuators and controllers are deployed with this processor
technology and memory size. Because of the cost sensitivity for these
products, little additional resources can be added and still contain
the cost point.
4. Requirement
Martocci Expires January 14, 2009 [Page 12]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
The software stack requirements for controllers MUST be implementable in 16-
bit devices with no more than 256Kb of flash memory (including at least
92Kb for the application code) and no more than 16Kb of RAM (including at
least 4Kb RAM available for the application.
4. Rational
Existing controllers are deployed with this processor technology and
memory size. Because of the cost sensitivity for these products,
little additional resources can be added and still contain the cost
point.
5. Requirement
A network (PAN) SHALL operationally support 1000 FFD and 1000 RFD devices
5. Rational
These numbers include full support for all HVAC, Fire, Lighting, Security
and elevator controllers and sensors on a 50kSq ft floor plate.
This requirement assumes a PAN per floor. The FFDs and RFDs in the enfire
facility will be significanltly higher.
6. Requirement
Sensor/Actuator/Controller addressability MUST be unique site
wide. All addressable nodes MUST be accessible to
all other nodes in the internetwork.
6. Rational
Existing technology does not support inter-PAN communication.
Building Applications require this for applications such as
outdoor air/relative humidity sensing which is instrumented once
but its data needs to be available network-wide.
7. Requirement
Device addressability MUST support at least 255 sensors/actuators for
each room/area controller.
7. Rational
Addressability consistent with existing ranges.
Martocci Expires January 14, 2009 [Page 13]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
8. Requirement
Device addressability MUST support at least 255 room/area controllers
for each floor controller
8. Rational
Addressability consistent with existing ranges.
9. Requirement
Devices implementing the ROLL features MUST be able to support the BACnet
protocol.
9. Rational
BACnet is a world-wide ISO protocol standard that is
often mandated to the commercial building vendors by the building owner.
BACnet already supports an IPv4 data link and is investigating
extensions for IPv6. Most FMS vendors already support BACnet. It would be
extremely advantageous for 6lowpan and ROLL to support the necessary
attributes to support this protocol.
10. Requirement
Devices implementing the ROLL features MUST be able to support the LON
protocol.
10. Rational
LON is a commercial building control protocol especially strong in Europe.
11. Requirement
The routing protocol MUST define a communication scheme to assure
compatibility of IPv4 and IPv6 devices.
11. Rational
All existing BACnet/IP devices are IPv4. The expected lifetime for a device
installed in a commercial building is at least 15 years.
Martocci Expires January 14, 2009 [Page 14]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
12. Requirement
It MUST be possible to fully commission devices from the network, without
requiring any additional commissioning device (e.g. laptop). The device
MAY be completely configured for network operation by setting a bank of
switches. The number of switches MUST not exceed 16 switches.
12. Rational
Installers have no access to sophisticated installation equipment such as
laptops. These folks prefer to simply set a bank of on-board switches to
configure the device for local operation.
13. Requirement
The system MUST support devices with pre-assigned Link Local Static Addresses
13. Rational
RFD devices such as temperature sensors and smoke detectors will be installed
prior to any IT network. The unique IPv6 address must be represented in the
16 bit address space currently designated in 802.15.4; and not need to
be changed as the system is defined or as replacement devices are required.
14. Requirement
Replacement of failed devices MUST allow the new device to assume the
address of the failed device without reconfiguration of additional
devices in the network.
14. Rational
Inter-node application references are common across FMS systems. To support
plug-and-play replaced devices must be able to assume the old device address.
Replacement is typically performed by service personnel that (much like
installers) have little networking experience.
15. Requirement
ROLL SHOULD add transmit power modulation algorithms to drive transmit
Martocci Expires January 14, 2009 [Page 15]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
power to only what is necessary to route data to the next device.
15. Rational
802.15.4 does not require transmit power regulation. This combined with
the collision avoidance algorithm can reduce network bandwidth efficiency
when a few devices are ?shouting? packets. Empirical testing has shown
that much of the parallel communication nature of the mesh can be lost
when nodes are transmitting with higher power than necessary.
16. Requirement
The total installed cost including but not limited to the
installation, commissioning and testing of a wireless sensor and
controller MUST be at least 10% less than that of an
equivalent wired device.
16. Rational
Since a wireless connection is never as reliable as a wired connection,
the totally installed cost of a wireless system needs to be
significantly less than that of a wired system.Also, due to local
code requirements and governance (e.g. UL) , the need for wired equivalent
devices will be mandated for many years even once wireless technology
has been proven reliable. This forces a requirement that the wireless
installation be less than a wired installation given functional
equivalence. Therefore unless the overall wireless cost is at least 10%
less than the wired cost, the installers will likely select the wired
alternative.
17. Requirement
Sensing devices MUST be supportable using battery (or other non-line based)
power. The solution MUST support power savings modes that will
support devices accessing the network at a rate of not more
than 1/minute at a duration time of less than 5 msec to
operate with not more than 2 AA alkaline cells for duration of
not less than 5 years.
17. Rational
Existing 802.15.4 mesh implementation?s sleep mechanism
supports this level of power. Existing implementations
already support this level of power efficiencies.
Martocci Expires January 14, 2009 [Page 16]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
18. Requirement
RFDs SHOULD target for operation using viable energy
harvesting techniques such as ambient light, mechanical
action, solar load, air pressure and differential
temperature.
18. Rational
(NOTE: This paragraph intentionally left empty)
19. Requirement
To support high speed code downloads, a mechanism MUST be
defined to download FFD devices in parallel yet support
guaranteed delivery.
Devices receiving a high speed download
MAY cease normal operation, but upon completion of the
download MUST automatically resume application and
complete network operation.
19. Rational
Required mode to expeditiously download 100
controllers/sensors simultaneously. Serial updates of
controllers do not meet customer expectations for
?downtime? and increase preventive maintenance on-site
time by vendor techs.
9. Installation/Commissioning Requirements
The following are the installation and commissioning requirements for a
network used to integrate building sensor actuator and control products.
Note that these requirements may include requirements outside the scope
of ROLL, yet must be considered as part of providing IP communications of
commercial building sensing, actuating and controlling devices.
**************************************************************************
* *
* Note the following table does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
**************************************************************************
Martocci Expires January 14, 2009 [Page 17]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
II. Installation/Commissioning Requirements
20. Requirement
Product installation and local network communication
verification MUST be performed by traditional trades people (e.g.
electricians) unfamiliar with IT communication technologies and
procedures.
20. Rational
To maintain existing installation costs, installation needs
to be provided by existing resources in the existing work
flow.
The typical installation workflow commences with the electrician
installing the room level devices. He/she must then be
able to verify acceptable local operation. Sensors, actuators
and controllers are typically installed prior to sheet wall and ceiling
installation. These devices must be commissioned and checked out prior to
the typical installation of the IT server network
21. Requirement
Network setup by the installer SHALL take no longer than 20 seconds per
device installed.
21. Rational
Currently, the installer simply needs to set an address using an on
the on-board means (e.g. switches) to fully define the network settings for
the device.
22. Requirement
Product commissioning MUST be performed by an application engineer
prior to the installation of the IT network.
22. Rational
Application engineers typically carry electronics such as a laptop
and/or PDA but are not familiar with IT devices such as DNS
and DHCP servers.Typically the IT network is not installed at the
time that the room and equipment controllers are commissioned for
local control.
Martocci Expires January 14, 2009 [Page 18]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
NOTE: This was not at issue with EIA-485 or existing 802.15.4 mesh
infrastructures since these dedicated infrastructures were
installed concurrently with the devices.
23. Requirement
A seamless means of merging PANs MUST be defined.
23. Rational
Installation of a large building is typically done in
parallel by many resources. Each resource will want
to work in his/her area independently, yet the fully
commissioned system must operate cohesively under a
single PAN
24. Requirement
Network setup MUST support network commissioning times
of no more than 15 minutes per sensor/controller
pair.
24. Rational
Current sensor/controller pairs can be configured with
network parameters in less than 15 minutes. See below
for allowable setup times for network
security.
25. Requirement
For wireless implementations, solutions MUST
support a total material, apportioned backhaul and labor
cost not to exceed $1.00/ft as compared to a wired
implementation.
25. Rational
This cost follows existing wired cost models
Martocci Expires January 14, 2009 [Page 19]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
26. Requirement
Devices SHOULD support an ?ad hoc? like mode (ala 802.11) allowing
for temporary point-to-point communication during the download
and commissioning phase. AD HOC mode MAY be mutually exclusive
from normal operational mode.
26. Rational
To assist in simple installation, an ad hoc mode (similar to
802.11) SHOULD be considered for easy point-to-point
commissioning of the device.
**************************************************************************
* *
* Note the following table does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
**************************************************************************
10. Networking Requirements
The following are the networking requirements for a network used to
integrate building sensor actuator and control products. Note that these
requirements may include requirements outside the scope of ROLL, yet must
be considered as part of providing IP communications of commercial
building sensing, actuating and controlling devices
III. Network Requirements
27. Requirement
Routing MUST support unicast, multicast and broadcast services
(or IPv6 equivalent)
27. Rational
Commercial building devices must interact. While installed
independently, they must discover needed devices, objects and
services at boot.
28. Requirement
Packet disassembly and reassembly (i.e. fragmentation) MUST
Martocci Expires January 14, 2009 [Page 20]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
support packet sizes to 512 octets.
28. Rational
BACnet MS/TP supports a 501 NPDU octet size for its sensor/controllers
networks.
29. Requirement
Discovery domains SHALL be provided to minimize traffic
infiltration beyond what is necessary. Discovery is needed
to find devices and bind objects.
29. Rational
For node discovery, local and global broadcast domains
must be supported (or IPv6 equivalent)
30. Requirement
Nodes MUST be able to be logically grouped at the
network layer (e.g. multicast, VLAN). New members MUST be
able to be added to the group; existing members MUST be
deletable from the group.
30. Rational
Currently the hierarchical network structure provides
clean independence from subnet to subnet. This
mechanism needs to be maintained even though IP is a flat
network space.
31. Requirement
Addressing MUST allow devices to join a logical group (e.g.
VLAN) and then transparently operate
within the domain of the group.
31. Rational
Martocci Expires January 14, 2009 [Page 21]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Existing hierarchical wired topology supports this requirement.
32. Requirement
Connection based and connectionless services MUST be supported
32. Rational
All existing FMS IP communication uses UDP with BACnet
providing transport services. Connection based
services are also required for applications such as
code downloads
33. Requirement
Routers MUST support quality of service prioritization to
assure timely response for critical FMS packets (e.g.
Fire and Security events)
33. Rational
Network prioritization is already supported in
BACnet and must be supported on the ROLL networks.
34. Requirement
Path selection MUST be based on path quality, rather than
signal strength only. Path quality includes signal strength,
available bandwidth, hop count and communication error
rates.
34. Rational
Existing wireless systems determine path on RSSI only
which is not always suitable.
35. Requirement
Communication paths MUST adapt toward optimality in time.
35. Rational
On demand algorithms will not optimize paths until needed.
Martocci Expires January 14, 2009 [Page 22]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Empirical testing has shown that a commercial building
recovering from a momentary loss of power will have a
very random device recovery. This leads to obtuse non-
optimal communication paths. Periodical path
rediscovery of routers will optimize paths and
reduce latency.
36. Requirement
To augment real-time performance, the network layer SHOULD
be configurable to allow secondary and tertiary paths to be
established and used upon failure of the primary path
36. Rational
Real-time applications often cannot incur the
added latency of path discovery. Nodes SHOULD try to
establish alternate source/destination paths that can
readily be used SHOULD the primary
path fail.
37. Requirement
Devices SHOULD optionally persist communication paths
across boots
37. Rational
Empirical testing has shown that path discover and orphan
reassignments of devices at boot can heavily effect
network performance. Devices SHOULD be
directed by the application to
either maintain or purge path information in warm-
start and cold-start conditions.
38. Requirement
The route discovery mechanism SHOULD allow a source
node (sensor) to dictate a configured destination node
Martocci Expires January 14, 2009 [Page 23]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
(controller) as a preferred routing path.
38. Rational
Many room controllers will interact locally
with sensors and actuators (within 30 feet). In these
cases the sensor/actuator binding SHOULD allow
the application to select the child/parent
preferred path. This will reduce unnecessary network
traffic.
Some existing wireless systems select paths without
input from the application.
39. Requirement
The network layer SHOULD support both asymmetric and
symmetric routes as requested by the application layer.
When the application layer selects asymmetry the network
layer MAY elect to find either asymmetric or
symmetric routes. When the application layer requests
symmetric routes, then only symmetric routes SHALL be
utilized.The default SHALL be asymmetric routes.
39. Rational
Asymmetric paths typically promote better overall
communication between nodes at the cost of varied
latency times and excess path discovery
broadcasts.Symmetric paths reduce path
discoveries especially in applications where
every message expects a response.The application
SHOULD be able to configure this network feature.
40. Requirement
Mobile devices SHOULD be capable of joining a new PAN and
associating to that network within 15 seconds.
40. Rational
Certain features such as location tracking must
support mobility. The association requirement is
heavily relaxed from streaming applications such as
VoIP, but yet must perform at a level to assure building
communication continuity,
Martocci Expires January 14, 2009 [Page 24]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
41. Requirement
RFDs MUST be able to receive information from
other devices on a regular basis.
41. Rational
Existing existing 802.15.4 mesh implementations only
cache 1 message from 1 parent to all children for only 7
seconds. This communication mechanism is too
restrictive. Sleeping RFD must have a more robust
mechanism defined to receive message of
interest when they awake.
42. Requirement
Commercial Building FFD and RFD devices MUST all be
periodically monitored to assure that the device is
viable and can communicate data and alarm information as needed.
42. Rational
The overhead to support this requirement at the
application layer will inordinately effect network
traffic. The network layer SHOULD maintain on-going
traffic tables to indirectly assure that the network
nodes are operable.
43. Requirement
An effective data rate of 20kbps is the lowest acceptable
operational data rate acceptable on the network.
43. Rational
Current event based systems require 10kbps sustained
throughput. Polled system will require
more bandwidth.
44. Requirement
Martocci Expires January 14, 2009 [Page 25]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
The network MUST automatically detect interference and
migrate the network to a better 802.15.4 channel to improve
communication. Channel changes and nodes response to the
channel change MUST occur within 60 seconds
44. Rational
Existing 802.15.4 mesh implementations have begun
deploying frequency agility after empirical testing
indicates that scaled networks cannot reside on a
single channel without interference.
45. Requirement
ROLL MUST adhere to the existing 802.15.4 frame format
and MUST not impinge on the available payload size
45. Rational
The existing 128 octet packet supports only about
an 80 byte payload. Reducing this payload size to
include more overhead will reduce
the types of applications that can successfully be
deployed.
46. Requirement
To improve diagnostics, the network layer SHOULD
be able to be placed in and out of ?verbose? mode.
Verbose mode is a temporary debugging mode that provides
additional communication information including
at least total number of packets sent, packets received,
number of failed communication attempts, neighbor
table and routing table entries.
46. Rational
The dynamic path discovery mechanisms used in a mesh
networks continually alter the communication paths,
latency and reliability. It is currently very
difficult to extract communication data from the stack to
analyze failures. The stack SHOULD incorporate intrinsic
mechanisms.
Martocci Expires January 14, 2009 [Page 26]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
47. Requirement
Network diagnostics such as PING and Trace Route
SHOULD be supported with extensions in Trace Route
describing wireless parameter information.
47. Rational
The dynamic path discovery mechanisms used in a mesh
networks continually alter the communication paths,
latency and reliability. It is currently very difficult to
extract communication data from the stack to
analyze failures. The stack SHOULD
incorporate intrinsic mechanisms.
48. Requirement
A node transmitting a ?request with
expected reply? to another node SHALL send the message to
the destination and receive the response in not more than 120
msec. This response time SHOULD be achievable with 5 or
less hops in each direction.This requirement
assumes network quiescence and a negligible turnaround
time at the destination node.
48. Rational
Measured empirical data from existing embedded mesh
networks using the 15.4 radio.
49. Requirement
Reliability SHALL meet the following minimum criteria:
< 1% MAC layer errors
on all messages;
After no more than
three retries ?
< .1% Network layer
errors on all
messages;
After no more than
three additional
Martocci Expires January 14, 2009 [Page 27]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
retries;
< 0.01% App?n layer
errors on all
messages.
Therefore application
layer messages will
fail no more than
once every 100,000
messages.
49. Rational
Measured empirical data from existing embedded mesh
networks using the 802.15.4 radio.
50. Requirement
The ROLL device SHALL support neighbor tables with
a minimum of 16 entries.ROLL routing SHALL
age neighbor table entries to assure table integrity
50. Rational
Consistent with existing meshing algorithms.
51. Requirement
The ROLL device SHALL support routing tables with a minimum
of 32 entries.ROLL routing SHALL age routing table
entries to assure table integrity
51. Rational
Consistent with existing meshing algorithms.
52. Requirement
ROLL routing SHALL support router table entry sizes
adjustable on a per node basis.
Martocci Expires January 14, 2009 [Page 28]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
52. Rational
Due to the non-uniform nature of the message flow
within commercial buildings, some nodes will require
significantly more routes than other nodes.
53. Requirement
All nodes in the system MUST support upwards to 10 hop
paths to other nodes in the system.
53. Rational
802.15.4 devices operate best inside buildings at 75 to
100 feet. This requirement will allow source devices
to be placed 750 to 1000 feet from its destination device.
54. Requirement
The system MUST support several priority levels
according to the IP QoS information.
54. Rational
The Fire and Security domains must transmit
packets without the threat of being bogged down by the
HVAC, Lighting and Shuttering domains.
**************************************************************************
* *
* Note the following table does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
**************************************************************************
11. Security Considerations
The following are the security requirements for a network used to
integrate building sensor actuator and control products. Note that these
requirements may include requirements outside the scope of ROLL, yet must
Martocci Expires January 14, 2009 [Page 29]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
be considered as part of providing IP communications of commercial
building sensing, actuating and controlling devices.
11.1 Security Requirements
55. Requirement
Devices MUST optionally support a network security
policy that includes but is not limited to device and user
authentication; payload (only) encryption and packet
encryption.
55. Rational
The commercial building market is very diverse ranging
from privately owned office buildings to military complexes
such as the Pentagon. The security models
deployed need to be robust and adaptable to the threat level
expected.
56. Requirement
Network security MUST thwart malicious intent including but
not limited to broadcast storms, spoofing and replay
attacks
56. Rational
As with all networks (especially wireless networks),
miscreants can deleteriously effect the network
operation and performance. A robust set of
security policies are required to thwart these
attempts; yet must fit into the processor and memory
footprint prescribed above.
57. Requirement
Configuration and Operational network security policies
MUST be supportable on all devices. ?out-of-box? security
policy SHALL be ?disabled?, but configurable to its
needed level on site. At the customer?s discretion the
security policy SHALL remain ?disabled? during system
operation.
Martocci Expires January 14, 2009 [Page 30]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
57. Rational
The security policy must be tailored for the installation.
As noted in the installation requirements, the
installer has no security threat to deal with since the
building is not yet occupied. Setting all security
?off? as the out-of-box state allows the installer to
complete his task unimpeded.
58. Requirement
The routing protocol MUST allow changing security
policies via network operations. The routing protocol MUST
also allow changing security policies at the device or out-of-
band.Changing security policies MAY require another device (e.g.
laptop) to implement.
58. Rational
Since the installer will not be setting security, the
devices will need to have their security policies defined en
masse over the network. However, as new devices are
added to the network at a later date, or failed devices are
replaced, the security policy also needs to be
administered locally.
59. Requirement
Security policies MUST be increasable or decreasable in the
field. Changing security policies can only effect the
changed node for no more than 15 minute duration. It can
have no ill effect on other operational modes in the network.
Changing security policies SHALL not require a network
restart. If MAY however require the effected node to be
restarted.
59. Rational
Due to the dynamic nature of the buildings and
devices, security policies must be easily administered
and changed across the network.
60. Requirement
Martocci Expires January 14, 2009 [Page 31]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Security policies must be settable and resettable on devices
that are not physically accessible and have no integrated displays
60. Rational
Current implementations support a TC that
can send security information across the air to all
devices.
61. Requirement
While the network is being changed, devices MUST
temporarily support both security policies until the
entire network has been modified. Once modified, devices
MUST not continue to support both policies
61. Rational
Commercial building systems are mission critical real-time
systems that must maintain operation during systemic
events.
62. Requirement
Additional network devices MUST not be required
including Network Managers, Trust Centers and
coordinators. This is not to say that these functions
cannot exist, only to say that they must not be targeted to
devices that only support that sole function.
62. Rational
FMS customers do not want to pay for ?boxes? that add no
application value to their system.
63. Requirement
Devices critical to network operation (e.g. Network
Coordinators, Trust Centers) MUST support redundancy
mechanisms. Failed network devices MUST optionally be
Martocci Expires January 14, 2009 [Page 32]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
assigned secondary devices that will assume these
functions in less than 2 minutes from failure.
OR
The network architecture MUST allow continued,
albeit reduced functionality, if the critical device(s)
fail or are somehow disconnected from the network.
63. Rational
Mission critical systems cannot fail and hence have
network policies that allow continued operation in case of
device failures.
64. Requirement
The network MUST support multiple security policies
simultaneously.
64. Rational
RFD (e.g. temperature sensors) may not require any
security yet controllers may require some level
of security. The HVAC domain may require minimal
security; yet the Fire domain may require high
security. These need to be on-site customer decisions.
65. Requirement
Device authentication MUST be supported
65. Rational
The Fire domain requires proper authentication from
the user device to assure proper clearance when
resetting a fire panel.
11.2 Security Use Cases
The following are the security use cases further detail the requirements
Martocci Expires January 14, 2009 [Page 33]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
upon the system nodes for different levels of security. The five use
cases are not exhaustive of the commercial building market, but are a
reasonable spectrum of cases covering many of the needs. Each of the
cases is further detailed by three sections ? 1) use case specifications,
2) allowed setup time and 3) allowed network disturbance.
**************************************************************************
* *
* Note the following table does not appear in this the text version of *
* this document. Please see the PDF version to view the table. It is *
* captured in text form as best as possible below... *
* *
**************************************************************************
11.2.1 No Security Threat
Site Characteristics - Private Office Buildings,Single Building
Single Tenant Facility, Owner Occupied, Not vendor interoperable,
No Public access to facility
Commercial Applications - HVAC, Lighting
Governance - None
Threats - None. Building occupants have no reason to be a security risk
Allowed time to setup network security when:
Merging Commissioned Islands - 15 minutes to allow one TC to acquiesce to
the other TC. All device security SHOULD be the same.
If on different PANs, allow 20 minutes for PAN change.
Increasing Security Policy - A network SHOULD be able to monotonically
increase its security policy. All devices within
the PAN MUST detect the policy change and increase its policy
within 10 minutes.
Installing Devices - 0 minutes per device
Replacing Devices - 0 minutes per device
Martocci Expires January 14, 2009 [Page 34]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Allowed Network Disturbance when:
Merging Commissioned Islands - Devices on the island being added MUST
not be affected by the coalescence of the islands.
Devices being moved MAY be effected while movement occurs
Increasing Security Policy - All PAN Devices MUST be made aware of the
impending policy change. No impact can occur on the network at
this time. Once the change commences, devices on the PAN MUST
support both policies temporarily until the TC explicitly tells the
device to use the new policy. At that point, the old policy MUST be
inactivated.
Reverting to Commissioning Mode - Not applicable since already at
lowest security level.
Commissioning Tool not available on-line - System MUST operate without
effect, New devices can be added using existing default key either by
off-band means or from operational Commissioning Tool
Trust Center fails - System MUST operate without
affect, New devices can be added using existing default key either
by off-band means or from operational Commissioning Tool
New Software Update Downloaded - Network Security feature MUST be
unaffected by software download. Only the device currently being
upgraded affected.
New Device Added = There MUST be no disruption of the existing network
Failed Device Replaced - (RFD) - associated FFD (i.e.
parent) MAY be affected when RFD
replaced. (FFD) - associated RFD(s) MAY be
affected while FFD replaced. Remaining network not affected
11.2.2 Low Security Threat
Site Characteristics - Commercial Real Estate,
Multi-tenant facilities, Universities, Health Care,
Vendor interoperability
Commercial Applications - HVAC, Lighting, Door Access
Video Monitoring
Martocci Expires January 14, 2009 [Page 35]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Governance - None
Threats - Miscreants (aka students) causing havoc
Allowed time to setup network security when:
Merging Commissioned Islands - 10 minutes to merge once TC to
acquiesce to the other TC established. The merge shall
occur automatically without requiring the installer to visit
each PAN device.
Increasing Security Policy - A network SHOULD be able to
monotonically increase its security policy. All devices
within the PAN MUST detect the policy change and increase its
policy within 10 minutes.
Installing Devices - 1 minute per device
Replacing Devices - 1 minute per device
Allowed Network Disturbance when:
Merging Commissioned Islands - Devices on the island being added will
not be effected by the coalescence of the islands. Devices being
moved can be effected while movement occurs
Increasing Security Policy - All PAN Devices MUST be made
aware of the impending policy change. No impact can occur on
the network at this time. Once the change commences, devices on
the PAN MUST support both policies temporarily until the TC
explicitly tells the device to use the new policy. At that
point, the old policy MUST be inactivated.
Reverting to Commissioning Mode - A PAN MUST be able to revert back
to its commissioning state and its 'out of the box' security
policy. One device, multiple devices or all devices in the PAN MUST be
made aware of the impending policy change. No impact can
occur on the network at this time. Once the change commences,
devices on the PAN MUST support both policies temporarily until
the TC explicitly tells the device to use the new policy. At
that point, the old policy MUST be inactivated.
Commissioning Tool not available on-line - System operates without effect,
New devices can be added using existing key either by off-band
means or from operational Commissioning Tool
Trust Center fails - System operates without effect,
New devices can be added using existing key either by off-band
Martocci Expires January 14, 2009 [Page 36]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
means or from operational Commissioning Tool
New Software Update Downloaded - Network Security feature
uneffected by software download. Only the device currently being
upgraded effected. Device will get security info either through
out-of-band means or TC.
New Device Added No disruption of existing network
Failed Device Replaced - RFD - associated FFD (i.e.
parent) MAY be effected when RFD
replaced. FFD - associated RFD (s) MAY be
effected while FFD replaced. Remaining network not effected
11.2.3 Medium Security Threat
Site Characteristics - High Occupancy, High Rise Buildings
Commercial Applications - HVAC, Lighting, Door Access,
Video Surveillance, UL Smoke Control, Fire Secondary Reporting
Governance - UL,ULC
Threats - Device Authentication on specific devices only to assure automatic
device control occurring only to specific devices.
Allowed time to setup network security when:
Merging Commissioned Islands - 10 minutes to merge once TC to
acquiesce to the other TC established. The merge shall
occur automatically without requiring the installer to visit
each PAN device.
Increasing Security Policy - A network SHOULD be able to
monotonically increase its security policy. All devices
within the PAN MUST detect the policy change and increase its
policy within 10 minutes.
Installing Devices - 5 minutes per device requiring
authentication, 1 minute for all other devices.
Replacing Devices - 10 minutes per device requiring
authentication, 1 minute for all other devices.No devices
can be added to the system unless authorized by the
TC.
Martocci Expires January 14, 2009 [Page 37]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Allowed Network Disturbance when:
Merging Commissioned Islands - Devices on the island being added
will not be effected by the coalescence of the islands.
Devices being moved can be effected while movement occurs
Increasing Security Policy - All PAN Devices MUST be made
aware of the impending policy change. No impact can occur on
the network at this time. Once the change commences, devices on
the PAN MUST support both policies temporarily until the TC
explicitly tells the device to use the new policy. At that
point, the old policy MUST be inactivated.
Reverting to Commissioning Mode - A PAN MUST be able to revert back
to its commissioning state and its 'out of the box' security
policy. One device, multiple devices or all devices in the PAN MUST be
made aware of the impending policy change. No impact can
occur on the network at this time. Once the change commences,
devices on the PAN MUST support both policies temporarily until
the TC explicitly tells the device to use the new policy. At
that point, the old policy MUST be inactivated.
Commissioning Tool not available on-line - Devices can be added to the
secure network by accessing the Trust Center directly.
Trust Center fails - System still operates. No new
devices can be added until the TC is again operational. A report
of the TC failure is forwarded to the user.
New Software Update Downloaded - New software cannot be downloaded
to the device until it authenticates the software and
device. The system MUST continue to run uneffected.
New Device Added - No disruption of existing network
Failed Device Replaced - RFD - associated FFD (i.e.
parent) MAY be effected when RFD
replaced. FFD - associated RFD (s) MAY be
effected while FFD replaced. Remaining network not effected
11.2.4 High Security Threat
Martocci Expires January 14, 2009 [Page 38]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Site Characteristics - Clean Rooms, Hospital ORs, Pharmeceuticals
Commercial Applications - HVAC, Lighting, Door Access, Video Surveillance
UL Smoke Control, Secondary Reporting,Primary Fire Reporting,
Critical Environments
Governance - UL,ULC,FDA
Threats - Device Authentication on specific devices only to assure automatic
device control and user access occurring only to specific
devices.
Allowed time to setup network security when:
Merging Commissioned Islands - 10 minutes to merge once TC to
acquiesce to the other TC established. The merge shall
occur automatically without requiring the installer to visit
each PAN device.
Increasing Security Policy - A network SHOULD be able to
monotonically increase its security policy. All devices
within the PAN MUST detect the policy change and increase its
policy within 10 minutes.
Installing Devices - 5 minutes per device requiring
authentication, 1 minute for all other devices.
Replacing Devices - 10 minutes per device requiring
authentication, 1 minute for all other devices
No devices can be added to the system unless authorized by the
TC.
Allowed Network Disturbance when:
Merging Commissioned Islands - Devices on the island being added
will not be effected by the coalescence of the islands.
Devices being moved can be effected while movement occurs
Increasing Security Policy - All PAN Devices MUST be made
aware of the impending policy change. No impact can occur on
the network at this time. Once the change commences, devices on
the PAN MUST support both policies temporarily until the TC
explicitly tells the device to use the new policy. At that
point, the old policy MUST be inactivated.
Martocci Expires January 14, 2009 [Page 39]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Reverting to Commissioning Mode - A PAN MUST be able to revert back
to its commissioning state and its 'out of the box' security
policy. One device, multiple devices or all devices in the PAN MUST be
made aware of the impending policy change. No impact can
occur on the network at this time. Once the change commences,
devices on the PAN MUST support both policies temporarily until
the TC explicitly tells the device to use the new policy. At
that point, the old policy MUST be inactivated.
Commissioning Tool not available on-line - Devices can be added to the
secure network by accessing the Trust Center directly.
Trust Center fails - System still operates. No new
devices can be added until the TC
is again operational. A report
of the TC failure is forwarded to
the user.
New Software Update Downloaded - New software cannot be downloaded
to the device until it authenticates the software and
device. The system MUST continue to run uneffected.
New Device Added - Devices MUST be added at a
scheduled time convenient to the customer. The network MAY be
down while they are added. Better though if it need not be
down.
Failed Device Replaced - RFD - associated FFD (i.e.
parent) MAY be effected when RFD replaced. FFD - associated
RFD (s) MAY be effected while FFD replaced. Remaining network
not effected.
11.2.5 Very High Security Threat
Site Characteristics - Government, Military, Homeland Security
Commercial Applications - HVAC, Lighting, Door Access,
Video Surveillance, UL Smoke Control, Secondary Reporting,
Primary Fire Reporting, Critical Environments
Governance - UL, ULC, FDA, CoE
Threats - Access onto the network at all
times MUST be protected (i.e. joining). Security key
definition MUST be protected from malicious surveillance of the
Martocci Expires January 14, 2009 [Page 40]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
network. Once authenticated onto the network, all data messages
MUST be encrypted to ward against malicious intent.
Allowed time to setup network security when:
Merging Commissioned Islands - 10 minutes to merge once TC to
acquiesce to the other TC established. The merge shall
occur automatically without requiring the installer to visit
each PAN device.
Increasing Security Policy - Not applicable since at the highest
security level. Reducing security would defeat the application
and would need to be a scheduled activity.
Installing Devices - Devices will be out-of-band
configured with the security policy. The TC will need to be
manually configured to allow the device to join the network.
Replacing Devices - Devices will be out-of-band
configured with the security policy. The TC will need to be
manually configured to allow the device to join the network.
Allowed Network Disturbance when:
Merging Commissioned Islands - The Commissioning device MUST be
a trusted configured node on the network as are all other devices.
Nodes already on the network cannot be deleteriously effected
by the addition of the new nodes. Each device being added to the
network MUST be manually added through user authentication at
the TC.
Increasing Security Policy - Not applicable since at the
highest security level. Reducing security would defeat the
application and would need to be a scheduled activity.
Reverting to Commissioning Mode - Not applicable, the network will
always be in its operable security state. The
commissioning tool MUST be added to the network and execute the
same security policies as do all other nodes.
Commissioning Tool not available on-line - Devices can be added to the
secure network by accessing the Trust Center directly.
Martocci Expires January 14, 2009 [Page 41]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
Trust Center fails - System remains in 'secure join'
mode. No device except the failed TC can be added to the
network.
New Software Update Downloaded - The downloading device MUST join
the network. The downloading device MUST authenticate to each
device being downloaded before the download commences. All
existing security data is lost as the new software downloads. Once
downloaded, the device MUST reestablish itself onto the
network via a manual network join operation.
New Device Added - New devices MAY be manually
authenticated to the network via a manual network join operation.
Once joined, the device MUST obtain its security information
in a secured manner.
Failed Device Replaced - New devices MAY be manually
authenticated to the network via a manual network join operation.
Once joined, the device MUST obtain its security information
in a secured manner.
12. Traffic Patterns
TBD
13. Open Issues
Other items to be addressed in further revisions of this document include
traffic patterns.
14. IANA Considerations
This document includes no request to IANA.
15. Acknowledgements
Thanks to the Johnson Control internal review team that provided over 150
insightful comments during the requirements inspection.
Additional thanks to the ZigBee Commercial Building Automation (CBA)
Profile Group for their input on the Security Use Cases.
16. References
16.1 Normative References
Martocci Expires January 14, 2009 [Page 42]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
16.2 Informative References
[I-D.culler-roll-routing-reqs]
J.P. Vasseur and D. Culler, "Routing Requirements for Low-Power Wireless
Networks", draft-culler-roll-routing-reqs-00 (work in progress), July
2007.
[draft-brandt-roll-home-routing-reqs-01]
A. Brand and J.P. Vasseur, "Home Automation Routing Requirement in Low
Power and Lossy Networks," draft-brandt-roll-home-routing-reqs-01 (work
in progress), July 2007.
[draft-pister-roll-indus-routing-reqs-01]
Industrial Routing Requirements in Low Power and Lossy Networks
draft-ietf-roll-indus-routing-reqs-00, April 2008
BACnet ? A Data Communication Protocol for Building Automation and
Control Networks.
ANSI/ASHRAE Standard 134-2004
Authors' Addresses
Jerry Martocci
Johnson Controls Inc.
507 E. Michigan Street
Milwaukee, Wisconsin 53201 USA
Email: jerald.p.martocci@jci.com
Ted Humpal
Johnson Controls Inc.
507 E. Michigan Street
Milwaukee, Wisconsin 53201, USA
Email: ted.humpal@jci.com
Nicolas Riou
nicolas.riou@fr.schneider-electric.com
Jon Williamsson
jon.williamson@tac.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
Martocci Expires January 14, 2009 [Page 43]
Internet-Draft draft-martocci-roll-commercial-routing-reqs July 2008
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Martocci Expires January 14, 2009 [Page 44]| PAFTECH AB 2003-2026 | 2026-04-22 21:31:28 |