[Search] [txt|pdf|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]