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

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