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/ |