draft-ietf-roll-building-routing-reqs-07.txt   draft-ietf-roll-building-routing-reqs-08.txt 
Networking Working Group J. Martocci, Ed. Networking Working Group J. Martocci, Ed.
Internet-Draft Johnson Controls Inc. Internet-Draft Johnson Controls Inc.
Intended status: Informational Pieter De Mil Intended status: Informational Pieter De Mil
Expires: March 14, 2010 Ghent University IBCN Expires: June 2, 2010 Ghent University IBCN
W. Vermeylen W. Vermeylen
Arts Centre Vooruit Arts Centre Vooruit
Nicolas Riou Nicolas Riou
Schneider Electric Schneider Electric
September 14, 2009 December 2, 2009
Building Automation Routing Requirements in Low Power and Lossy Building Automation Routing Requirements in Low Power and Lossy
Networks Networks
draft-ietf-roll-building-routing-reqs-07 draft-ietf-roll-building-routing-reqs-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 14, 2010. This Internet-Draft will expire on June 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 25 skipping to change at page 2, line 25
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in (RFC2119). document are to be interpreted as described in (RFC2119).
Table of Contents Table of Contents
1. Terminology....................................................4 1. Terminology....................................................4
2. Introduction...................................................4 2. Introduction...................................................4
3. Overview of Building Automation Networks.......................5 3. Overview of Building Automation Networks.......................5
3.1. Introduction..............................................5 3.1. Introduction..............................................5
3.2. Building Systems Equipment................................6 3.2. Building Systems Equipment................................7
3.2.1. Sensors/Actuators....................................6 3.2.1. Sensors/Actuators....................................7
3.2.2. Area Controllers.....................................7 3.2.2. Area Controllers.....................................7
3.2.3. Zone Controllers.....................................7 3.2.3. Zone Controllers.....................................7
3.3. Equipment Installation Methods............................7 3.3. Equipment Installation Methods............................8
3.4. Device Density............................................8 3.4. Device Density............................................8
3.4.1. HVAC Device Density..................................8 3.4.1. HVAC Device Density..................................8
3.4.2. Fire Device Density..................................9 3.4.2. Fire Device Density..................................9
3.4.3. Lighting Device Density..............................9 3.4.3. Lighting Device Density..............................9
3.4.4. Physical Security Device Density.....................9 3.4.4. Physical Security Device Density.....................9
4. Traffic Pattern................................................9 4. Traffic Pattern...............................................10
5. Building Automation Routing Requirements......................11 5. Building Automation Routing Requirements......................11
5.1. Device and Network Commissioning.........................11 5.1. Device and Network Commissioning.........................11
5.1.1. Zero-Configuration Installation.....................12 5.1.1. Zero-Configuration Installation.....................12
5.1.2. Local Testing.......................................12 5.1.2. Local Testing.......................................12
5.1.3. Device Replacement..................................12 5.1.3. Device Replacement..................................12
5.2. Scalability..............................................12 5.2. Scalability..............................................13
5.2.1. Network Domain......................................12 5.2.1. Network Domain......................................13
5.2.2. Peer-to-Peer Communication..........................13 5.2.2. Peer-to-Peer Communication..........................13
5.3. Mobility.................................................13 5.3. Mobility.................................................13
5.3.1. Mobile Device Requirements..........................13 5.3.1. Mobile Device Requirements..........................14
5.4. Resource Constrained Devices.............................14 5.4. Resource Constrained Devices.............................14
5.4.1. Limited memory footprint on host devices............14 5.4.1. Limited Memory Footprint on Host Devices............14
5.4.2. Limited Processing Power for routers................14 5.4.2. Limited Processing Power for Routers................15
5.4.3. Sleeping Devices....................................14 5.4.3. Sleeping Devices....................................15
5.5. Addressing...............................................15 5.5. Addressing...............................................15
5.6. Manageability............................................15 5.6. Manageability............................................16
5.6.1. Diagnostics.........................................15 5.6.1. Diagnostics.........................................16
5.6.2. Route Tracking......................................15 5.6.2. Route Tracking......................................17
5.7. Route Selection..........................................16 5.7. Route Selection..........................................17
5.7.1. Route Cost..........................................16 5.7.1. Route Cost..........................................17
5.7.2. Route Adaptation....................................16 5.7.2. Route Adaptation....................................17
5.7.3. Route Redundancy....................................16 5.7.3. Route Redundancy....................................17
5.7.4. Route Discovery Time................................16 5.7.4. Route Discovery Time................................18
5.7.5. Route Preference....................................16 5.7.5. Route Preference....................................18
5.7.6. Real-time Performance Measures......................17 5.7.6. Real-time Performance Measures......................18
5.7.7. Prioritized Routing.................................17 5.7.7. Prioritized Routing.................................18
5.8. Security Requirements....................................17 5.8. Security Requirements....................................18
5.8.1. Authentication......................................17 5.8.1. Authentication......................................19
5.8.2. Encryption..........................................18 5.8.2. Encryption..........................................19
5.8.3. Disparate Security Policies.........................18 5.8.3. Disparate Security Policies.........................20
5.8.4. Routing Security Policies To Sleeping Devices.......18 5.8.4. Routing Security Policies To Sleeping Devices.......20
6. IANA Considerations...........................................18 6. Security Considerations.......................................20
7. Acknowledgments...............................................19 7. IANA Considerations...........................................21
8. References....................................................19 8. Acknowledgments...............................................21
8.1. Normative References.....................................19 9. References....................................................21
8.2. Informative References...................................19 9.1. Normative References.....................................21
9. Appendix A: Additional Building Requirements..................19 9.2. Informative References...................................21
9.1. Additional Commercial Product Requirements...............19 10. Appendix A: Additional Building Requirements.................21
9.1.1. Wired and Wireless Implementations..................19 10.1. Additional Commercial Product Requirements..............22
9.1.2. World-wide Applicability............................19 10.1.1. Wired and Wireless Implementations.................22
9.2. Additional Installation and Commissioning Requirements...20 10.1.2. World-wide Applicability...........................22
9.2.1. Unavailability of an IP network.....................20 10.2. Additional Installation and Commissioning Requirements..22
9.3. Additional Network Requirements..........................20 10.2.1. Unavailability of an IP network....................22
9.3.1. TCP/UDP.............................................20 10.3. Additional Network Requirements.........................22
9.3.2. Interference Mitigation.............................20 10.3.1. TCP/UDP............................................22
9.3.3. Packet Reliability..................................20 10.3.2. Interference Mitigation............................22
9.3.4. Merging Commissioned Islands........................20 10.3.3. Packet Reliability.................................22
9.3.5. Adjustable Routing Table Sizes......................21 10.3.4. Merging Commissioned Islands.......................23
9.3.6. Automatic Gain Control..............................21 10.3.5. Adjustable Routing Table Sizes.....................23
9.3.7. Device and Network Integrity........................21 10.3.6. Automatic Gain Control.............................23
9.4. Additional Performance Requirements......................21 10.3.7. Device and Network Integrity.......................23
9.4.1. Data Rate Performance...............................21 10.4. Additional Performance Requirements.....................23
9.4.2. Firmware Upgrades...................................21 10.4.1. Data Rate Performance..............................23
9.4.3. Route Persistence...................................21 10.4.2. Firmware Upgrades..................................23
10.4.3. Route Persistence..................................24
11. Authors' Addresses...........................................25
1. Terminology 1. Terminology
For description of the terminology used in this specification, please For description of the terminology used in this specification, please
see [I-D.ietf-roll-terminology]. see [I-D.ietf-roll-terminology].
2. Introduction 2. Introduction
The Routing Over Low power and Lossy network (ROLL) Working Group has The Routing Over Low power and Lossy network (ROLL) Working Group has
been chartered to work on routing solutions for Low Power and Lossy been chartered to work on routing solutions for Low Power and Lossy
skipping to change at page 4, line 34 skipping to change at page 4, line 34
communication. communication.
The cost benefits and ease of installation of wireless sensors allow The cost benefits and ease of installation of wireless sensors allow
customers to further instrument their facilities with additional customers to further instrument their facilities with additional
sensors; providing tighter control while yielding increased energy sensors; providing tighter control while yielding increased energy
savings. savings.
Wireless solutions will be adapted from their existing wired Wireless solutions will be adapted from their existing wired
counterparts in many of the building applications including, but not counterparts in many of the building applications including, but not
limited to Heating, Ventilation, and Air Conditioning (HVAC), limited to Heating, Ventilation, and Air Conditioning (HVAC),
Lighting, Physical Security, Fire, and Elevator systems. These Lighting, Physical Security, Fire, and Elevator/Lift systems. These
devices will be developed to reduce installation costs; while devices will be developed to reduce installation costs; while
increasing installation and retrofit flexibility, as well as increasing installation and retrofit flexibility, as well as
increasing the sensing fidelity to improve efficiency and building increasing the sensing fidelity to improve efficiency and building
service quality. service quality.
Sensing devices may be battery-less; battery or mains powered. Sensing devices may be battery-less; battery or mains powered.
Actuators and area controllers will be mains powered. Due to Actuators and area controllers will be mains powered. Due to
building code and/or device density (e.g. equipment room), it is building code and/or device density (e.g., equipment room), it is
envisioned that a mix of wired and wireless sensors and actuators envisioned that a mix of wired and wireless sensors and actuators
will be deployed within a building. will be deployed within a building.
Facility Management Systems (FMS) are deployed in a large set of Facility Management Systems (FMS) are deployed in a large set of
vertical markets including universities; hospitals; government vertical markets including universities; hospitals; government
facilities; Kindergarten through High School (K-12); pharmaceutical facilities; Kindergarten through High School (K-12); pharmaceutical
manufacturing facilities; and single-tenant or multi-tenant office manufacturing facilities; and single-tenant or multi-tenant office
buildings. These buildings range in size from 100K sqft structures (5 buildings. These buildings range in size from 100K sqft structures (5
story office buildings), to 1M sqft skyscrapers (100 story story office buildings), to 1M sqft skyscrapers (100 story
skyscrapers) to complex government facilities such as the Pentagon. skyscrapers) to complex government facilities such as the Pentagon.
skipping to change at page 5, line 47 skipping to change at page 6, line 10
To understand the network systems requirements of a facility To understand the network systems requirements of a facility
management system in a commercial building, this document uses a management system in a commercial building, this document uses a
framework to describe the basic functions and composition of the framework to describe the basic functions and composition of the
system. An FMS is a hierarchical system of sensors, actuators, system. An FMS is a hierarchical system of sensors, actuators,
controllers and user interface devices that interoperate to provide a controllers and user interface devices that interoperate to provide a
safe and comfortable environment while constraining energy costs. safe and comfortable environment while constraining energy costs.
An FMS may is divided functionally across alike, but different An FMS may is divided functionally across alike, but different
building subsystems such as heating, ventilation and air conditioning building subsystems such as heating, ventilation and air conditioning
(HVAC); Fire; Security; Lighting; Shutters and Elevator control (HVAC); Fire; Security; Lighting; Shutters and Elevator/Lift control
systems as denoted in Figure 1. systems as denoted in Figure 1.
Much of the makeup of an FMS is optional and installed at the behest Much of the makeup of an FMS is optional and installed at the behest
of the customer. Sensors and actuators have no standalone of the customer. Sensors and actuators have no standalone
functionality. All other devices support partial or complete functionality. All other devices support partial or complete
standalone functionality. These devices can optionally be tethered standalone functionality. These devices can optionally be tethered
to form a more cohesive system. The customer requirements dictate to form a more cohesive system. The customer requirements dictate
the level of integration within the facility. This architecture the level of integration within the facility. This architecture
provides excellent fault tolerance since each node is designed to provides excellent fault tolerance since each node is designed to
operate in an independent mode if the higher layers are unavailable. operate in an independent mode if the higher layers are unavailable.
skipping to change at page 7, line 16 skipping to change at page 7, line 23
by the upper layers of the FMS topology. The sensors typically are by the upper layers of the FMS topology. The sensors typically are
at the edge of the network structure providing environmental data at the edge of the network structure providing environmental data
into the system. The actuators are the sensors' counterparts into the system. The actuators are the sensors' counterparts
modifying the characteristics of the system based on the sensor data modifying the characteristics of the system based on the sensor data
and the applications deployed. and the applications deployed.
3.2.2. Area Controllers 3.2.2. Area Controllers
An area describes a small physical locale within a building, An area describes a small physical locale within a building,
typically a room. HVAC (temperature and humidity) and Lighting (room typically a room. HVAC (temperature and humidity) and Lighting (room
lighting, shades, solar loads) vendors oft times deploy area lighting, shades, solar loads) vendors often times deploy area
controllers. Area controls are fed by sensor inputs that monitor the controllers. Area controls are fed by sensor inputs that monitor the
environmental conditions within the room. Common sensors found in environmental conditions within the room. Common sensors found in
many rooms that feed the area controllers include temperature, many rooms that feed the area controllers include temperature,
occupancy, lighting load, solar load and relative humidity. Sensors occupancy, lighting load, solar load and relative humidity. Sensors
found in specialized rooms (such as chemistry labs) might include air found in specialized rooms (such as chemistry labs) might include air
flow, pressure, CO2 and CO particle sensors. Room actuation includes flow, pressure, CO2 and CO particle sensors. Room actuation includes
temperature setpoint, lights and blinds/curtains. temperature setpoint, lights and blinds/curtains.
3.2.3. Zone Controllers 3.2.3. Zone Controllers
skipping to change at page 7, line 39 skipping to change at page 8, line 5
grouping or functional division of a commercial building. A zone may grouping or functional division of a commercial building. A zone may
also coincidentally map to a physical locale such as a floor. also coincidentally map to a physical locale such as a floor.
Zone Control may have direct sensor inputs (smoke detectors for Zone Control may have direct sensor inputs (smoke detectors for
fire), controller inputs (room controllers for air-handlers in HVAC) fire), controller inputs (room controllers for air-handlers in HVAC)
or both (door controllers and tamper sensors for security). Like or both (door controllers and tamper sensors for security). Like
area/room controllers, zone controllers are standalone devices that area/room controllers, zone controllers are standalone devices that
operate independently or may be attached to the larger network for operate independently or may be attached to the larger network for
more synergistic control. more synergistic control.
3.3. Equipment Installation Methods 3.3. Equipment Installation Methods
Commercial controllers have been traditionally deployed in a facility Commercial controllers have been traditionally deployed in a facility
using serial media following the EIA-485 electrical standard using serial media following the EIA-485 electrical standard
operating nominally at 76800 baud with distances upward to 15000 operating nominally at 76800 baud with distances upward to 15000
feet. EIA-485 is a multi-drop media allowing upwards to 255 devices feet. EIA-485 is a multi-drop media allowing upwards to 255 devices
to be connected to a single trunk. to be connected to a single trunk.
Wired FMS installation is a multifaceted procedure depending on the Wired FMS installation is a multifaceted procedure depending on the
extent of the system and the software interoperability requirement. extent of the system and the software interoperability requirement.
However, at the sensor/actuator and controller level, the procedure However, at the sensor/actuator and controller level, the procedure
is typically a two or three step process. is typically a two or three step process.
The installer arrives on-site during the construction of the building The installer arrives on-site during the construction of the building
prior to drywall and ceiling installation. The installer allocates prior to drywall and ceiling installation. The installer allocates
wall space installs the controller and sensor networks. The Building wall space installs the controller and sensor networks. The Building
Controllers and Enterprise network are not normally installed until Controllers and Enterprise network are not normally installed until
months later. The electrician completes the task by running a months later. The electrician completes the task by running a
verification procedure that verifies proper wired or wireless verification procedure that verifies proper wired or wireless
continuity between the devices. continuity between the devices.
skipping to change at page 8, line 29 skipping to change at page 8, line 39
in place. The Building Controllers are completely commissioned using in place. The Building Controllers are completely commissioned using
a crossover cable or a temporary IP switch together with static IP a crossover cable or a temporary IP switch together with static IP
addresses. addresses.
After occupancy, when the IP network is operational, the FMS often After occupancy, when the IP network is operational, the FMS often
connects to the enterprise network. Dynamic IPs replace static IPs. connects to the enterprise network. Dynamic IPs replace static IPs.
VLANs oft time segregate the facility and IT systems. For multi- VLANs oft time segregate the facility and IT systems. For multi-
building multi-site facilities VPNs, NATs and firewalls are also building multi-site facilities VPNs, NATs and firewalls are also
introduced. introduced.
3.4. Device Density 3.4. Device Density
Device density differs depending on the application and as dictated Device density differs depending on the application and as dictated
by the local building code requirements. The following sections by the local building code requirements. The following sections
detail typical installation densities for different applications. detail typical installation densities for different applications.
3.4.1. HVAC Device Density 3.4.1. HVAC Device Density
HVAC room applications typically have sensors/actuators and HVAC room applications typically have sensors/actuators and
controllers spaced about 50ft apart. In most cases there is a 3:1 controllers spaced about 50ft apart. In most cases there is a 3:1
ratio of sensors/actuators to controllers. That is, for each room ratio of sensors/actuators to controllers. That is, for each room
skipping to change at page 10, line 10 skipping to change at page 10, line 18
4. Traffic Pattern 4. Traffic Pattern
The independent nature of the automation subsystems within a building The independent nature of the automation subsystems within a building
plays heavy onto the network traffic patterns. Much of the real-time plays heavy onto the network traffic patterns. Much of the real-time
sensor environmental data and actuator control stays within the local sensor environmental data and actuator control stays within the local
LLN environment; while alarming and other event data will percolate LLN environment; while alarming and other event data will percolate
to higher layers. to higher layers.
Each sensor in the LLN unicasts P2P about 200 bytes of sensor data to Each sensor in the LLN unicasts P2P about 200 bytes of sensor data to
its associated controller each minute and expects an application its associated controller each minute and expects an application
acknowledgement unicast returned from the destination. Each acknowledgment unicast returned from the destination. Each
controller unicasts messages at a nominal rate of 6kB/min to peer or controller unicasts messages at a nominal rate of 6kB/min to peer or
supervisory controllers. 30% of each node's packets are destined for supervisory controllers. 30% of each node's packets are destined for
other nodes within the LLN. 70% of each node's packets are destined other nodes within the LLN. 70% of each node's packets are destined
for an aggregation device (MP2P)and routed off the LLN. These for an aggregation device (MP2P)and routed off the LLN. These
messages also require a unicast acknowledgement from the destination. messages also require a unicast acknowledgment from the destination.
The above values assume direct node-to-node communication; meshing The above values assume direct node-to-node communication; meshing
and error retransmissions are not considered. and error retransmissions are not considered.
Multicasts (P2MP) to all nodes in the LLN occur for node and object Multicasts (P2MP) to all nodes in the LLN occur for node and object
discovery when the network is first commissioned. This data is discovery when the network is first commissioned. This data is
typically a one-time bind that is henceforth persisted. Lighting typically a one-time bind that is henceforth persisted. Lighting
systems will also readily use multicasting during normal operations systems will also readily use multicasting during normal operations
to turn banks of lights 'on' and 'off' simultaneously. to turn banks of lights 'on' and 'off' simultaneously.
FMS systems may be either polled or event based. Polled data systems FMS systems may be either polled or event based. Polled data systems
skipping to change at page 11, line 4 skipping to change at page 11, line 15
controllers. controllers.
Initial system startup after a controlled outage or unexpected power Initial system startup after a controlled outage or unexpected power
failure puts tremendous stress on the network and on the routing failure puts tremendous stress on the network and on the routing
algorithms. An FMS system is comprised of a myriad of control algorithms. An FMS system is comprised of a myriad of control
algorithms at the room, area, zone, and enterprise layers. When algorithms at the room, area, zone, and enterprise layers. When
these control algorithms are at quiescence, the real-time data rate these control algorithms are at quiescence, the real-time data rate
is small and the network will not saturate. An overall network is small and the network will not saturate. An overall network
traffic load of 6KBps is typical at quiescence. However, upon any traffic load of 6KBps is typical at quiescence. However, upon any
power loss, the control loops and real-time data quickly atrophy. A power loss, the control loops and real-time data quickly atrophy. A
ten minute power outage may require many hours to regain building short power disruption of only ten minutes may have a long-term
control. Traffic flow may increase ten-fold until the building deleterious impact on the building control systems taking many hours
control stabilizes. to regain proper control. Control application that cannot handle
this level of disruption (e.g., Hospital Operating Rooms) must be
fitted with a secondary power source.
Power disruptions are unexpected and in most cases will immediately Power disruptions are unexpected and in most cases will immediately
impact lines-powered devices. Power disruptions however, are impact lines-powered devices. Power disruptions however, are
transparent to battery powered devices. These devices will continue transparent to battery powered devices. These devices will continue
to attempt to access the LLN during the outage. Battery powered to attempt to access the LLN during the outage. Battery powered
devices designed to buffer data that has not been delivered will devices designed to buffer data that has not been delivered will
further stress the network operation when power returns. further stress the network operation when power returns.
Upon restart, lines-powered devices will naturally dither due to Upon restart, lines-powered devices will naturally dither due to
primary equipment delays or variance in the device self-tests. primary equipment delays or variance in the device self-tests.
skipping to change at page 11, line 36 skipping to change at page 12, line 4
Following are the building automation routing requirements for Following are the building automation routing requirements for
networks used to integrate building sensor, actuator and control networks used to integrate building sensor, actuator and control
products. These requirements are written not presuming any products. These requirements are written not presuming any
preordained network topology, physical media (wired) or radio preordained network topology, physical media (wired) or radio
technology (wireless). technology (wireless).
5.1. Device and Network Commissioning 5.1. Device and Network Commissioning
Building control systems typically are installed and tested by Building control systems typically are installed and tested by
electricians having little computer knowledge and no network electricians having little computer knowledge and no network
knowledge whatsoever. These systems are often installed during the communication knowledge whatsoever. These systems are often
building construction phase before the drywall and ceilings are in installed during the building construction phase before the drywall
place. For new construction projects, the building enterprise IP and ceilings are in place. For new construction projects, the
network is not in place during installation of the building control building enterprise IP network is not in place during installation of
system. For retrofit applications, the installer will still operate the building control system. For retrofit applications, the
independently from the IP network so as not to affect network installer will still operate independently from the IP network so as
operations during the installation phase. not to affect network operations during the installation phase.
In traditional wired systems correct operation of a light In traditional wired systems correct operation of a light
switch/ballast pair was as simple as flipping on the light switch. switch/ballast pair was as simple as flipping on the light switch.
In wireless applications, the tradesperson has to assure the same In wireless applications, the tradesperson has to assure the same
operation, yet be sure the operation of the light switch is operation, yet be sure the operation of the light switch is
associated to the proper ballast. associated to the proper ballast.
System level commissioning will later be deployed using a more System level commissioning will later be deployed using a more
computer savvy person with access to a commissioning device (e.g. a computer savvy person with access to a commissioning device (e.g., a
laptop computer). The completely installed and commissioned laptop computer). The completely installed and commissioned
enterprise IP network may or may not be in place at this time. enterprise IP network may or may not be in place at this time.
Following are the installation routing requirements. Following are the installation routing requirements.
5.1.1. Zero-Configuration Installation 5.1.1. Zero-Configuration Installation
It MUST be possible to fully commission network devices without It MUST be possible to fully commission network devices without
requiring any additional commissioning device (e.g. laptop). requiring any additional commissioning device (e.g., laptop). From
the ROLL perspective, zero-configuration means that a node can obtain
an address and join the network on its own, without human
intervention.
5.1.2. Local Testing 5.1.2. Local Testing
During installation, the room sensors, actuators and controllers During installation, the room sensors, actuators and controllers
SHOULD be able to route packets amongst themselves without requiring SHOULD be able to route packets amongst themselves and to any other
any additional routing infrastructure or routing configuration. device within the LLN without requiring any additional routing
infrastructure or routing configuration.
5.1.3. Device Replacement 5.1.3. Device Replacement
To eliminate the need to reconfigure the application upon replacing a To eliminate the need to reconfigure the application upon replacing a
failed device in the LLN; the replaced device must be able to failed device in the LLN; the replaced device must be able to
advertise the old IP address of the failed device in addition to its advertise the old IP address of the failed device in addition to its
new IP address. The routing protocols MUST support hosts and routers new IP address. The routing protocols MUST support hosts and routers
that advertise multiple IPv6 addresses. that advertise multiple IPv6 addresses.
5.2. Scalability 5.2. Scalability
skipping to change at page 12, line 43 skipping to change at page 13, line 18
ft. to 1M+ sq. ft. The networks that support these systems must ft. to 1M+ sq. ft. The networks that support these systems must
cost-effectively scale accordingly. In larger facilities cost-effectively scale accordingly. In larger facilities
installation may occur simultaneously on various wings or floors, yet installation may occur simultaneously on various wings or floors, yet
the end system must seamlessly merge. Following are the scalability the end system must seamlessly merge. Following are the scalability
requirements. requirements.
5.2.1. Network Domain 5.2.1. Network Domain
The routing protocol MUST be able to support networks with at least The routing protocol MUST be able to support networks with at least
2000 nodes where 1000 nodes would act as routers and the other 1000 2000 nodes where 1000 nodes would act as routers and the other 1000
nodes would be hosts. Subnetworks (e.g. rooms, primary equipment) nodes would be hosts. Subnetworks (e.g., rooms, primary equipment)
within the network must support upwards to 255 sensors and/or within the network must support upwards to 255 sensors and/or
actuators. actuators.
5.2.2. Peer-to-Peer Communication 5.2.2. Peer-to-Peer Communication
The data domain for commercial FMS systems may sprawl across a vast The data domain for commercial FMS systems may sprawl across a vast
portion of the physical domain. For example, a chiller may reside in portion of the physical domain. For example, a chiller may reside in
the facility's basement due to its size, yet the associated cooling the facility's basement due to its size, yet the associated cooling
towers will reside on the roof. The cold-water supply and return towers will reside on the roof. The cold-water supply and return
pipes serpentine through all the intervening floors. The feedback pipes serpentine through all the intervening floors. The feedback
control loops for these systems require data from across the control loops for these systems require data from across the
facility. facility.
A network device MUST be able to communicate in a point-to-point A network device MUST be able to communicate in a end-to-end manner
manner with any other device on the network. Thus, the routing with any other device on the network. Thus, the routing protocol MUST
protocol MUST provide routes between arbitrary hosts within the provide routes between arbitrary hosts within the appropriate
appropriate administrative domain. administrative domain.
5.3. Mobility 5.3. Mobility
Most devices are affixed to walls or installed on ceilings within Most devices are affixed to walls or installed on ceilings within
buildings. Hence the mobility requirements for commercial buildings buildings. Hence the mobility requirements for commercial buildings
are few. However, in wireless environments location tracking of are few. However, in wireless environments location tracking of
occupants and assets is gaining favor. Asset tracking applications, occupants and assets is gaining favor. Asset tracking applications,
such as tracking capital equipment (e.g. wheel chairs) in medical such as tracking capital equipment (e.g., wheel chairs) in medical
facilities, require monitoring movement with granularity of a minute. facilities, require monitoring movement with granularity of a minute.
This soft real-time performance requirement is reflected in the This soft real-time performance requirement is reflected in the
performance requirements below. performance requirements below.
5.3.1. Mobile Device Requirements 5.3.1. Mobile Device Requirements
To minimize network dynamics, mobile devices should not be allowed to To minimize network dynamics, mobile devices should not be allowed to
act as forwarding devices (routers) for other devices in the LLN. act as forwarding devices (routers) for other devices in the LLN.
Network configuration should allow devices to be configured as Network configuration should allow devices to be configured as
routers or hosts. routers or hosts.
skipping to change at page 14, line 19 skipping to change at page 14, line 39
A mobile device that moves outside its original LLN SHOULD A mobile device that moves outside its original LLN SHOULD
reestablish end-to-end communication to a fixed device also in the reestablish end-to-end communication to a fixed device also in the
new LLN within 10 seconds after the mobile device ceases movement. new LLN within 10 seconds after the mobile device ceases movement.
The network convergence time should be less than 20 seconds once the The network convergence time should be less than 20 seconds once the
mobile device stops moving. mobile device stops moving.
5.4. Resource Constrained Devices 5.4. Resource Constrained Devices
Sensing and actuator device processing power and memory may be 4 Sensing and actuator device processing power and memory may be 4
orders of magnitude less (i.e. 10,000x) than many more traditional orders of magnitude less (i.e., 10,000x) than many more traditional
client devices on an IP network. The routing mechanisms must client devices on an IP network. The routing mechanisms must
therefore be tailored to fit these resource constrained devices. therefore be tailored to fit these resource constrained devices.
5.4.1. Limited memory footprint on host devices. 5.4.1. Limited Memory Footprint on Host Devices
The software size requirement for non-routing devices (e.g. sleeping The software size requirement for non-routing devices (e.g., sleeping
sensors and actuators) SHOULD be implementable in 8-bit devices with sensors and actuators) SHOULD be implementable in 8-bit devices with
no more than 128KB of memory. no more than 128KB of memory.
5.4.2. Limited Processing Power for routers 5.4.2. Limited Processing Power for Routers
The software size requirements for routing devices (e.g. room The software size requirements for routing devices (e.g., room
controllers) SHOULD be implementable in 8-bit devices with no more controllers) SHOULD be implementable in 8-bit devices with no more
than 256KB of flash memory. than 256KB of flash memory.
5.4.3. Sleeping Devices 5.4.3. Sleeping Devices
Sensing devices will, in some cases, utilize battery power or energy Sensing devices will, in some cases, utilize battery power or energy
harvesting techniques for power and will operate mostly in a sleep harvesting techniques for power and will operate mostly in a sleep
mode to maintain power consumption within a modest budget. The mode to maintain power consumption within a modest budget. The
routing protocol MUST take into account device characteristics such routing protocol MUST take into account device characteristics such
as power budget. as power budget.
Typically, sensor battery life (2000mah) needs to extend for at least Typically, sensor battery life (2000mAh) needs to extend for at least
5 years when the device is transmitting its data (200 octets) once 5 years when the device is transmitting its data (200 octets) once
per minute over a low power transceiver (25ma) and expecting a per minute over a low power transceiver (25ma) and expecting an
application acknowledgement. This requires a highly efficient application acknowledgment. In this case the transmitting device
routing protocol that minimizes hops and hence latency in end-to-end must leave its receiver in a high powered state awaiting the return
communication. The routing protocol MUST take into account node of the application ACK. To minimize this latency, a highly efficient
properties such as 'Low-powered node' which produce efficient low routing protocol that minimizes hops and hence end-to-end
latency routes that minimize radio 'on' time for these devices. communication is required. The routing protocol MUST take into
account node properties such as 'Low-powered node' which produce
efficient low latency routes that minimize radio 'on' time for these
devices.
Proxies with unconstrained power budgets often times are used to Sleeping devices MUST be able to receive inbound data. Messages sent
cache the inbound data for a sleeping device until the device to battery powered nodes MUST be buffered and retried by the last hop
awakens. In such cases, the routing protocol MUST discover the router for a period of at least 20 seconds when the destination node
capability of a node to act as a proxy during route calculation; then is currently in its sleep cycle.
deliver the packet to the assigned proxy for later delivery to the
sleeping device upon its next awakened cycle.
5.5. Addressing 5.5. Addressing
Facility Management systems require different communication schemes Facility Management systems require different communication schemes
to solicit or post network information. Multicasts or anycasts need to solicit or post network information. Multicasts or anycasts need
be used to resolve unresolved references within a device when the be used to resolve unresolved references within a device when the
device first joins the network. device first joins the network.
As with any network communication, multicasting should be minimized. As with any network communication, multicasting should be minimized.
This is especially a problem for small embedded devices with limited This is especially a problem for small embedded devices with limited
network bandwidth. Multicasts are typically used for network joins network bandwidth. Multicasts are typically used for network joins
and application binding in embedded systems. Routing MUST support and application binding in embedded systems. Routing MUST support
anycast, unicast, and multicast. anycast, unicast, and multicast.
5.6. Manageability 5.6. Manageability
In addition to the initial installation of the system, it is equally As previously noted in Clause 3.3, installation of LLN devices
important for the ongoing maintenance of the system to be simple and follows a bottoms-up work flow. Edge devices are installed first and
inexpensive. tested for communication and application integrity. These devices
are then aggregated into islands, then LLNs and later affixed onto
the enterprise network.
The need for diagnostics most often occurs during the installation
and commissioning phase; although at times diagnostic information may
be requested during normal operation. Battery powered wireless
devices typically will have a self diagnostic mode that can be
initiated via a button press on the device. The device will display
its link status and/or end-to-end connectivity when the button is
depressed. Lines-powered devices will continuously display
communication status via a bank of LEDs; possibly denoting signal
strength and end-to-end application connectivity.
The local diagnostics noted above often times are suitable for
defining room level networks. However, as these devices aggregate,
system level diagnostics may need to be executed to ameliorate route
vacillation, excessive hops, communication retries and/or network
bottlenecks.
On operational networks, due to the mission critical nature of the
application, the LLN devices will be temporally monitored by the
higher layers to assure communication integrity is maintained.
Failure to maintain this communication will result in an alarm being
forwarded to the enterprise network from the monitoring node for
analysis and remediation.
In addition to the initial installation and commissioning of the
system, it is equally important for the ongoing maintenance of the
system to be simple and inexpensive. This implies a straightforward
device swap when a failed device is replaced as noted in Clause
5.1.3.
5.6.1. Diagnostics 5.6.1. Diagnostics
To improve diagnostics, the routing protocol SHOULD be able to be To improve diagnostics, the routing protocol SHOULD be able to be
placed in and out of 'verbose' mode. Verbose mode is a temporary placed in and out of 'verbose' mode. Verbose mode is a temporary
debugging mode that provides additional communication information debugging mode that provides additional communication information
including at least total number of routed packets sent and received, including at least total number of routed packets sent and received,
number of routing failures (no route available), neighbor table number of routing failures (no route available), neighbor table
members, and routing table entries. members, and routing table entries. The data provided in verbose
mode should be sufficient that a network connection graph could be
constructed and maintained by the monitoring node.
Diagnostic data should be kept by the routers continuously and be
available for solicitation at anytime by any other node on the
internetwork. Verbose mode will be activated/deactivated via either
a unicast, multicast or other means. Devices having available
resources may elect to support verbose mode continually.
5.6.2. Route Tracking 5.6.2. Route Tracking
Route diagnostics SHOULD be supported providing information such as Route diagnostics SHOULD be supported providing information such as
route quality; number of hops; available alternate active routes with route quality; number of hops; available alternate active routes with
associated costs. Route quality is the relative measure of associated costs. Route quality is the relative measure of
'goodness' of the selected source to destination route as compared to 'goodness' of the selected source to destination route as compared to
alternate routes. This composite value may be measured as a function alternate routes. This composite value may be measured as a function
of hop count, signal strength, available power, existing active of hop count, signal strength, available power, existing active
routes or any other criteria deemed by ROLL as the route cost routes or any other criteria deemed by ROLL as the route cost
skipping to change at page 16, line 22 skipping to change at page 17, line 39
5.7.1. Route Cost 5.7.1. Route Cost
The routing protocol MUST support a metric of route quality and The routing protocol MUST support a metric of route quality and
optimize selection according to such metrics within constraints optimize selection according to such metrics within constraints
established for links along the routes. These metrics SHOULD reflect established for links along the routes. These metrics SHOULD reflect
metrics such as signal strength, available bandwidth, hop count, metrics such as signal strength, available bandwidth, hop count,
energy availability and communication error rates. energy availability and communication error rates.
5.7.2. Route Adaptation 5.7.2. Route Adaptation
Communication routes MUST adapt toward the chosen metric(s) (e.g. Communication routes MUST be adaptive and converge toward optimality
signal quality) optimality in time. of the chosen metric (e.g., signal quality, hop count) in time.
5.7.3. Route Redundancy 5.7.3. Route Redundancy
The routing layer SHOULD be configurable to allow secondary and The routing layer SHOULD be configurable to allow secondary and
tertiary routes to be established and used upon failure of the tertiary routes to be established and used upon failure of the
primary route. primary route.
5.7.4. Route Discovery Time 5.7.4. Route Discovery Time
Mission critical commercial applications (e.g. Fire, Security) Mission critical commercial applications (e.g., Fire, Security)
require reliable communication and guaranteed end-to-end delivery of require reliable communication and guaranteed end-to-end delivery of
all messages in a timely fashion. Application layer time-outs must all messages in a timely fashion. Application layer time-outs must
be selected judiciously to cover anomalous conditions such as lost be selected judiciously to cover anomalous conditions such as lost
packets and/or route discoveries; yet not be set too large to over packets and/or route discoveries; yet not be set too large to over
damp the network response. If route discovery occurs during packet damp the network response. If route discovery occurs during packet
transmission time (proactive routing), it SHOULD NOT add more than transmission time (proactive routing), it SHOULD NOT add more than
120ms of latency to the packet delivery time. 120ms of latency to the packet delivery time.
5.7.5. Route Preference 5.7.5. Route Preference
The routing protocol SHOULD allow for the support of manually The routing protocol SHOULD allow for the support of manually
configured static preferred routes. configured static preferred routes.
5.7.6. Real-time Performance Measures 5.7.6. Real-time Performance Measures
A node transmitting a 'request with expected reply' to another node A node transmitting a 'request with expected reply' to another node
must send the message to the destination and receive the response in must send the message to the destination and receive the response in
not more than 120 msec. This response time should be achievable with not more than 120 ms. This response time should be achievable with 5
5 or less hops in each direction. This requirement assumes network or less hops in each direction. This requirement assumes network
quiescence and a negligible turnaround time at the destination node. quiescence and a negligible turnaround time at the destination node.
5.7.7. Prioritized Routing 5.7.7. Prioritized Routing
Network and application packet routing prioritization must be Network and application packet routing prioritization must be
supported to assure that mission critical applications (e.g. Fire supported to assure that mission critical applications (e.g., Fire
Detection) cannot be deferred while less critical applications access Detection) cannot be deferred while less critical applications access
the network. The routing protocol MUST be able to provide routes the network. The routing protocol MUST be able to provide routes
with different characteristics, also referred to as "QoS" routing. with different characteristics, also referred to as "QoS" routing.
5.8. Security Requirements 5.8. Security Requirements
Security policies, especially wireless encryption and device Security policies, especially wireless encryption and device
authentication needs to be considered, especially with concern to the authentication needs to be considered, especially with concern to the
impact on the processing capabilities and additional latency incurred impact on the processing capabilities and additional latency incurred
on the sensors, actuators and controllers. on the sensors, actuators and controllers.
FMS systems are typically highly configurable in the field and hence FMS systems are typically highly configurable in the field and hence
the security policy is most often dictated by the type of building to the security policy is most often dictated by the type of building to
which the FMS is being installed. Single tenant owner occupied which the FMS is being installed. Single tenant owner occupied
office buildings installing lighting or HVAC control are candidates office buildings installing lighting or HVAC control are candidates
for implementing low or even no security on the LLN. Antithetically, for implementing a low level of security on the LLN. Antithetically,
military or pharmaceutical facilities require strong security military or pharmaceutical facilities require strong security
policies. As noted in the installation procedures, security policies policies. As noted in the installation procedures, security policies
must be facile to allow for no security policy during the must be facile to allow for no security policy during the
installation phase (prior to building occupancy), yet easily raise installation phase (prior to building occupancy), yet easily raise
the security level network wide during the commissioning phase of the the security level network wide during the commissioning phase of the
system. system.
5.8.1. Authentication 5.8.1. Authentication
Authentication SHOULD be optional on the LLN. Authentication SHOULD Authentication SHOULD be optional on the LLN. Authentication SHOULD
be fully configurable on-site. Authentication policy and updates MUST be fully configurable on-site. Authentication policy and updates MUST
be routable over-the-air. Authentication SHOULD occur upon joining be routable over-the-air. Authentication SHOULD occur upon joining
or rejoining a network. However, once authenticated devices SHOULD or rejoining a network. However, once authenticated devices SHOULD
NOT need to reauthenticate with any other devices in the LLN. NOT need to reauthenticate with any other devices in the LLN.
Packets may need authentication at the source and destination nodes, Packets may need authentication at the source and destination nodes,
however, packets routed through intermediate hops should not need however, packets routed through intermediate hops should not need
reauthentication at each hop. reauthentication at each hop.
These requirements mean that at least one LLN routing protocol
solution specification MUST include support for authentication.
5.8.2. Encryption 5.8.2. Encryption
5.8.2.1. Encryption Types 5.8.2.1. Encryption Types
Data encryption of packets MUST optionally be supported by use of Data encryption of packets MUST be supported by all protocol solution
either a network wide key and/or application key. The network key specifications. Support can be provided by use of either a network
would apply to all devices in the LLN. The application key would wide key and/or an application key. The network key would apply to
apply to a subset of devices on the LLN. all devices in the LLN. The application key would apply to a subset
of devices on the LLN.
The network key and application keys would be mutually exclusive. The network key and application keys would be mutually exclusive.
The routing protocol MUST allow routing a packet encrypted with an The routing protocol MUST allow routing a packet encrypted with an
application key through forwarding devices that without requiring application key through forwarding devices without requiring each
each node in the route to have the application key. node in the route to have the application key.
5.8.2.2. Packet Encryption 5.8.2.2. Packet Encryption
The encryption policy MUST support encryption of the payload only or The encryption policy MUST support both encryption of the payload
the entire packet. Payload only encryption would eliminate the only or of the entire packet. Payload only encryption would
decryption/re-encryption overhead at every hop providing more real- eliminate the decryption/re-encryption overhead at every hop
time performance. providing more real-time performance.
5.8.3. Disparate Security Policies 5.8.3. Disparate Security Policies
Due to the limited resources of an LLN, the security policy defined Due to the limited resources of an LLN, the security policy defined
within the LLN MUST be able to differ from that of the rest of the IP within the LLN MUST be able to differ from that of the rest of the IP
network within the facility yet packets MUST still be able to route network within the facility yet packets MUST still be able to route
to or through the LLN from/to these networks. to or through the LLN from/to these networks.
5.8.4. Routing Security Policies To Sleeping Devices 5.8.4. Routing Security Policies To Sleeping Devices
The routing protocol MUST gracefully handle routing temporal security The routing protocol MUST gracefully handle routing temporal security
updates (e.g. dynamic keys) to sleeping devices on their 'awake' updates (e.g., dynamic keys) to sleeping devices on their 'awake'
cycle to assure that sleeping devices can readily and efficiently cycle to assure that sleeping devices can readily and efficiently
access then network. access the network.
6. IANA Considerations 6. Security Considerations
The requirements placed on the LLN routing protocol in order to
provide the correct level of security support are presented in
Section 5.8.
LLNs deployed in a building environment may be entirely isolated from
other networks, attached to normal IP networks within the building
yet physically disjoint from the wider Internet, or connected either
directly or through other IP networks to the Internet. Additionally,
even where no wired connectivity exists out of the building, the use
of wireless infrastructure within the building means that physical
connectivity to the LLN is possible for an attacker.
Therefore, it is important that any routing protocol solution
designed to meet the requirements included in this document addresses
the security features requirements described in Section 5.8.
Implementations of these protocols will be required in the protocol
specifications to provide the level of support indicated in Section
5.8, and will be encouraged to make the support flexibly configurable
to enable an operator to make a judgment of the level of security
that they want to deploy at any time.
As noted in Section 5.8, use/deployment of the different security
features is intended to be optional. This means that, although the
protocols developed must conform to the requirements specified, the
operator is free to determine the level of risk and the trade-offs
against performance. An implementation must not make those choices on
behalf of the operator by avoiding implementing any mandatory-to-
implement security features.
This informational requirements specification introduces no new
security concerns.
7. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
7. Acknowledgments 8. Acknowledgments
In addition to the authors, J. P. Vasseur, David Culler, Ted Humpal In addition to the authors; JP. Vasseur, David Culler, Ted Humpal and
and Zach Shelby are gratefully acknowledged for their contributions Zach Shelby are gratefully acknowledged for their contributions to
to this document. this document.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 9.2. Informative References
[I-D.ietf-roll-terminology]Vasseur, J., "Terminology in Low power And [I-D.ietf-roll-terminology]Vasseur, JP., "Terminology in Low power
Lossy Networks", draft-ietf-roll-terminology-00 (work in progress), And Lossy Networks", draft-ietf-roll-terminology-00 (work in
October 2008. progress), October 2008.
9. Appendix A: Additional Building Requirements 10. Appendix A: Additional Building Requirements
Appendix A contains additional building requirements that were deemed Appendix A contains additional building requirements that were deemed
out of scope for ROLL, yet provided ancillary substance for the out of scope for ROLL, yet provided ancillary substance for the
reader. reader.
9.1. Additional Commercial Product Requirements 10.1. Additional Commercial Product Requirements
9.1.1. Wired and Wireless Implementations 10.1.1. Wired and Wireless Implementations
Vendors will likely not develop a separate product line for both Vendors will likely not develop a separate product line for both
wired and wireless networks. Hence, the solutions set forth must wired and wireless networks. Hence, the solutions set forth must
support both wired and wireless implementations. support both wired and wireless implementations.
9.1.2. World-wide Applicability 10.1.2. World-wide Applicability
Wireless devices must be supportable at the 2.4Ghz ISM band. Wireless devices must be supportable unlicensed bands.
Wireless devices should be supportable at the 900 and 868 ISM bands
as well.
9.2. Additional Installation and Commissioning Requirements 10.2. Additional Installation and Commissioning Requirements
9.2.1. Unavailability of an IP network 10.2.1. Unavailability of an IP network
Product commissioning must be performed by an application engineer Product commissioning must be performed by an application engineer
prior to the installation of the IP network (e.g. switches, routers, prior to the installation of the IP network (e.g., switches, routers,
DHCP, DNS). DHCP, DNS).
9.3. Additional Network Requirements 10.3. Additional Network Requirements
9.3.1. TCP/UDP 10.3.1. TCP/UDP
Connection based and connectionless services must be supported Connection based and connectionless services must be supported
9.3.2. Interference Mitigation 10.3.2. Interference Mitigation
The network must automatically detect interference and seamlessly The network must automatically detect interference and seamlessly
migrate the network hosts channel to improve communication. Channel migrate the network hosts channel to improve communication. Channel
changes and nodes response to the channel change must occur within 60 changes and nodes response to the channel change must occur within 60
seconds. seconds.
9.3.3. Packet Reliability 10.3.3. Packet Reliability
In building automation, it is required for the network to meet the In building automation, it is required for the network to meet the
following minimum criteria : following minimum criteria:
< 1% MAC layer errors on all messages; After no more than three < 1% MAC layer errors on all messages; After no more than three
retries retries
< .1% Network layer errors on all messages; < .1% Network layer errors on all messages;
After no more than three additional retries; After no more than three additional retries;
< 0.01% Application layer errors on all messages. < 0.01% Application layer errors on all messages.
Therefore application layer messages will fail no more than once Therefore application layer messages will fail no more than once
every 100,000 messages. every 100,000 messages.
9.3.4. Merging Commissioned Islands 10.3.4. Merging Commissioned Islands
Subsystems are commissioned by various vendors at various times Subsystems are commissioned by various vendors at various times
during building construction. These subnetworks must seamlessly during building construction. These subnetworks must seamlessly
merge into networks and networks must seamlessly merge into merge into networks and networks must seamlessly merge into
internetworks since the end user wants a holistic view of the system. internetworks since the end user wants a holistic view of the system.
9.3.5. Adjustable Routing Table Sizes 10.3.5. Adjustable Routing Table Sizes
The routing protocol must allow constrained nodes to hold an The routing protocol must allow constrained nodes to hold an
abbreviated set of routes. That is, the protocol should not mandate abbreviated set of routes. That is, the protocol should not mandate
that the node routing tables be exhaustive. that the node routing tables be exhaustive.
9.3.6. Automatic Gain Control 10.3.6. Automatic Gain Control
For wireless implementations, the device radios should incorporate For wireless implementations, the device radios should incorporate
automatic transmit power regulation to maximize packet transfer and automatic transmit power regulation to maximize packet transfer and
minimize network interference regardless of network size or density. minimize network interference regardless of network size or density.
9.3.7. Device and Network Integrity 10.3.7. Device and Network Integrity
Commercial Building devices must all be periodically scanned to Commercial Building devices must all be periodically scanned to
assure that the device is viable and can communicate data and alarm assure that the device is viable and can communicate data and alarm
information as needed. Router should maintain previous packet flow information as needed. Router should maintain previous packet flow
information temporally to minimize overall network overhead. information temporally to minimize overall network overhead.
9.4. Additional Performance Requirements 10.4. Additional Performance Requirements
9.4.1. Data Rate Performance 10.4.1. Data Rate Performance
An effective data rate of 20kbits/s is the lowest acceptable An effective data rate of 20kbits/s is the lowest acceptable
operational data rate acceptable on the network. operational data rate acceptable on the network.
9.4.2. Firmware Upgrades 10.4.2. Firmware Upgrades
To support high speed code downloads, routing should support To support high speed code downloads, routing should support
transports that provide parallel downloads to targeted devices yet transports that provide parallel downloads to targeted devices yet
guarantee packet delivery. In cases where the spatial position of guarantee packet delivery. In cases where the spatial position of
the devices requires multiple hops, the algorithm should recurse the devices requires multiple hops, the algorithm should recurse
through the network until all targeted devices have been serviced. through the network until all targeted devices have been serviced.
Devices receiving a download may cease normal operation, but upon Devices receiving a download may cease normal operation, but upon
completion of the download must automatically resume normal completion of the download must automatically resume normal
operation. operation.
9.4.3. Route Persistence 10.4.3. Route Persistence
To eliminate high network traffic in power-fail or brown-out To eliminate high network traffic in power-fail or brown-out
conditions previously established routes should be remembered and conditions previously established routes should be remembered and
invoked prior to establishing new routes for those devices reentering invoked prior to establishing new routes for those devices reentering
the network. the network.
Authors' Addresses 11. Authors' Addresses
Jerry Martocci Jerry Martocci
Johnson Control Johnson Control
507 E. Michigan Street 507 E. Michigan Street
Milwaukee, Wisconsin, 53202 Milwaukee, Wisconsin, 53202
USA USA
Phone: 414.524.4010 Phone: +1 414 524 4010
Email: jerald.p.martocci@jci.com Email: jerald.p.martocci@jci.com
Nicolas Riou Nicolas Riou
Schneider Electric Schneider Electric
Technopole 38TEC T3 Technopole 38TEC T3
37 quai Paul Louis Merlin 37 quai Paul Louis Merlin
38050 Grenoble Cedex 9 38050 Grenoble Cedex 9
France France
Phone: +33 4 76 57 66 15 Phone: +33 4 76 57 66 15
Email: nicolas.riou@fr.schneider-electric.com Email: nicolas.riou@fr.schneider-electric.com
Pieter De Mil Pieter De Mil
Ghent University - IBCN Ghent University - IBCN
G. Crommenlaan 8 bus 201 G. Crommenlaan 8 bus 201
Ghent 9050 Ghent 9050
Belgium Belgium
Phone: +32-9331-4981 Phone: +32 9331 4981
Fax: +32--9331--4899 Fax: +32 9331 4899
Email: pieter.demil@intec.ugent.be Email: pieter.demil@intec.ugent.be
Wouter Vermeylen Wouter Vermeylen
Arts Centre Vooruit Arts Centre Vooruit
???
Ghent 9000 Ghent 9000
Belgium Belgium
Phone: ???
Fax: ???
Email: wouter@vooruit.be Email: wouter@vooruit.be
 End of changes. 85 change blocks. 
168 lines changed or deleted 246 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/