draft-ietf-roll-building-routing-reqs-06.txt   draft-ietf-roll-building-routing-reqs-07.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: February 7, 2010 Ghent University IBCN Expires: March 14, 2010 Ghent University IBCN
W. Vermeylen W. Vermeylen
Arts Centre Vooruit Arts Centre Vooruit
Nicolas Riou Nicolas Riou
Schneider Electric Schneider Electric
August 7, 2009 September 14, 2009
Building Automation Routing Requirements in Low Power and Lossy Building Automation Routing Requirements in Low Power and Lossy
Networks Networks
draft-ietf-roll-building-routing-reqs-06 draft-ietf-roll-building-routing-reqs-07
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 February 7, 2010. This Internet-Draft will expire on March 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.4.2. Fire Device Density..................................9 3.4.2. Fire Device Density..................................9
3.4.3. Lighting Device Density..............................9 3.4.3. Lighting Device Density..............................9
3.4.4. Physical Security Device Density.....................9 3.4.4. Physical Security Device Density.....................9
4. Traffic Pattern................................................9 4. Traffic Pattern................................................9
5. Building Automation Routing Requirements......................11 5. Building Automation Routing Requirements......................11
5.1. Device and Network Commissioning.........................11 5.1. Device and Network Commissioning.........................11
5.1.1. Zero-Configuration Installation.....................12 5.1.1. Zero-Configuration Installation.....................12
5.1.2. Local Testing.......................................12 5.1.2. Local Testing.......................................12
5.1.3. Device Replacement..................................12 5.1.3. Device Replacement..................................12
5.2. Scalability..............................................12 5.2. Scalability..............................................12
5.2.1. Network Domain......................................13 5.2.1. Network Domain......................................12
5.2.2. Peer-to-Peer Communication..........................13 5.2.2. Peer-to-Peer Communication..........................13
5.3. Mobility.................................................13 5.3. Mobility.................................................13
5.3.1. Mobile Device Requirements..........................13 5.3.1. Mobile Device Requirements..........................13
5.4. Resource Constrained Devices.............................14 5.4. Resource Constrained Devices.............................14
5.4.1. Limited memory footprint on host devices............14 5.4.1. Limited memory footprint on host devices............14
5.4.2. Limited Processing Power for routers................14 5.4.2. Limited Processing Power for routers................14
5.4.3. Sleeping Devices....................................14 5.4.3. Sleeping Devices....................................14
5.5. Addressing...............................................15 5.5. Addressing...............................................15
5.6. Manageability............................................15 5.6. Manageability............................................15
5.6.1. Diagnostics.........................................15 5.6.1. Diagnostics.........................................15
5.6.2. Route Tracking......................................16 5.6.2. Route Tracking......................................15
5.7. Route Selection..........................................16 5.7. Route Selection..........................................16
5.7.1. Route Cost..........................................16 5.7.1. Route Cost..........................................16
5.7.2. Route Adaptation....................................16 5.7.2. Route Adaptation....................................16
5.7.3. Route Redundancy....................................16 5.7.3. Route Redundancy....................................16
5.7.4. Route Discovery Time................................16 5.7.4. Route Discovery Time................................16
5.7.5. Route Preference....................................17 5.7.5. Route Preference....................................16
5.7.6. Real-time Performance Measures......................17 5.7.6. Real-time Performance Measures......................17
5.7.7. Prioritized Routing.................................17 5.7.7. Prioritized Routing.................................17
5.8. Security Requirements....................................17 5.8. Security Requirements....................................17
5.8.1. Authentication......................................18 5.8.1. Authentication......................................17
5.8.2. Encryption..........................................18 5.8.2. Encryption..........................................18
5.8.3. Disparate Security Policies.........................18 5.8.3. Disparate Security Policies.........................18
5.8.4. Routing Security Policies To Sleeping Devices.......18 5.8.4. Routing Security Policies To Sleeping Devices.......18
6. IANA Considerations...........................................19 6. IANA Considerations...........................................18
7. Acknowledgments...............................................19 7. Acknowledgments...............................................19
8. References....................................................19 8. References....................................................19
8.1. Normative References.....................................19 8.1. Normative References.....................................19
8.2. Informative References...................................19 8.2. Informative References...................................19
9. Appendix A: Additional Building Requirements..................19 9. Appendix A: Additional Building Requirements..................19
9.1. Additional Commercial Product Requirements...............20 9.1. Additional Commercial Product Requirements...............19
9.1.1. Wired and Wireless Implementations..................20 9.1.1. Wired and Wireless Implementations..................19
9.1.2. World-wide Applicability............................20 9.1.2. World-wide Applicability............................19
9.2. Additional Installation and Commissioning Requirements...20 9.2. Additional Installation and Commissioning Requirements...20
9.2.1. Unavailability of an IP network.....................20 9.2.1. Unavailability of an IP network.....................20
9.3. Additional Network Requirements..........................20 9.3. Additional Network Requirements..........................20
9.3.1. TCP/UDP.............................................20 9.3.1. TCP/UDP.............................................20
9.3.2. Interference Mitigation.............................20 9.3.2. Interference Mitigation.............................20
9.3.3. Packet Reliability..................................20 9.3.3. Packet Reliability..................................20
9.3.4. Merging Commissioned Islands........................21 9.3.4. Merging Commissioned Islands........................20
9.3.5. Adjustable Routing Table Sizes......................21 9.3.5. Adjustable Routing Table Sizes......................21
9.3.6. Automatic Gain Control..............................21 9.3.6. Automatic Gain Control..............................21
9.3.7. Device and Network Integrity........................21 9.3.7. Device and Network Integrity........................21
9.4. Additional Performance Requirements......................21 9.4. Additional Performance Requirements......................21
9.4.1. Data Rate Performance...............................21 9.4.1. Data Rate Performance...............................21
9.4.2. Firmware Upgrades...................................22 9.4.2. Firmware Upgrades...................................21
9.4.3. Route Persistence...................................22 9.4.3. Route Persistence...................................21
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
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.
Commercial buildings have been fitted with pneumatic and subsequently Commercial buildings have been fitted with pneumatic and subsequently
electronic communication pathways connecting sensors to their electronic communication routes connecting sensors to their
controllers for over one hundred years. Recent economic and controllers for over one hundred years. Recent economic and
technical advances in wireless communication allow facilities to technical advances in wireless communication allow facilities to
increasingly utilize a wireless solution in lieu of a wired solution; increasingly utilize a wireless solution in lieu of a wired solution;
thereby reducing installation costs while maintaining highly reliant thereby reducing installation costs while maintaining highly reliant
communication. communication.
The cost benefits and ease of installation of wireless sensors allow The cost benefits and ease of installation of wireless sensors allow
customers to further instrument their facilities with additional customers to further instrument their facilities with additional
sensors; providing tighter control while yielding increased energy sensors; providing tighter control while yielding increased energy
savings. savings.
skipping to change at page 12, line 18 skipping to change at page 12, line 18
enterprise IP network may or may not be in place at this time. enterprise IP network may or may not be in place at this time.
Following are the installation routing requirements. Following are the installation routing requirements.
5.1.1. Zero-Configuration Installation 5.1.1. Zero-Configuration Installation
It MUST be possible to fully commission network devices without It MUST be possible to fully commission network devices without
requiring any additional commissioning device (e.g. laptop). requiring any additional commissioning device (e.g. laptop).
5.1.2. Local Testing 5.1.2. Local Testing
The local sensors and requisite actuators and controllers must be During installation, the room sensors, actuators and controllers
testable within the locale (e.g. room) to assure communication SHOULD be able to route packets amongst themselves without requiring
connectivity and local operation without requiring other systemic any additional routing infrastructure or routing configuration.
devices.
LLN nodes SHOULD be testable for end-to-end link connectivity and
application conformance without requiring other network
infrastructure.
5.1.3. Device Replacement 5.1.3. Device Replacement
Replacement devices need to be plug-and-play with no additional setup To eliminate the need to reconfigure the application upon replacing a
compared to what is normally required for a new device. Devices failed device in the LLN; the replaced device must be able to
referencing data in the replaced device MUST be able to reference advertise the old IP address of the failed device in addition to its
data in its replacement without requiring reconfiguration. Thus, new IP address. The routing protocols MUST support hosts and routers
such a reference cannot be a hardware identifier, such as the MAC that advertise multiple IPv6 addresses.
address, nor a hard-coded route. If such a reference is an IP
address, the replacement device MUST be assigned the IP addressed
previously bound to the replaced device. Or if the logical
equivalent of a hostname is used for the reference, it must be
translated to the replacement IP address.
5.2. Scalability 5.2. Scalability
Building control systems are designed for facilities from 50000 sq. Building control systems are designed for facilities from 50000 sq.
ft. to 1M+ sq. ft. The networks that support these systems must ft. to 1M+ sq. ft. The networks that support these systems must
cost-effectively scale accordingly. In larger facilities cost-effectively scale accordingly. In larger facilities
installation may occur simultaneously on various wings or floors, yet installation may occur simultaneously on various wings or floors, yet
the end system must seamlessly merge. Following are the scalability the end system must seamlessly merge. Following are the scalability
requirements. requirements.
skipping to change at page 15, line 6 skipping to change at page 14, line 41
The software size requirements for routing devices (e.g. room The software size requirements for routing devices (e.g. room
controllers) SHOULD be implementable in 8-bit devices with no more controllers) SHOULD be implementable in 8-bit devices with no more
than 256KB of flash memory. than 256KB of flash memory.
5.4.3. Sleeping Devices 5.4.3. Sleeping Devices
Sensing devices will, in some cases, utilize battery power or energy Sensing devices will, in some cases, utilize battery power or energy
harvesting techniques for power and will operate mostly in a sleep harvesting techniques for power and will operate mostly in a sleep
mode to maintain power consumption within a modest budget. The mode to maintain power consumption within a modest budget. The
routing protocol MUST take into account device characteristics such routing protocol MUST take into account device characteristics such
as power budget. If such devices provide routing, rather than merely as power budget.
host connectivity, the energy costs associated with such routing
needs to fit within the power budget. If the mechanisms for duty
cycling dictate very long response times or specific temporal
scheduling, routing will need to take such constraints into account.
Typically, battery life (2000mah) needs to extend for at least 5 Typically, sensor battery life (2000mah) needs to extend for at least
years when the sensing device is transmitting its data(200 octets) 5 years when the device is transmitting its data (200 octets) once
once per minute over a low power transceiver (25ma). This requires per minute over a low power transceiver (25ma) and expecting a
that sleeping devices MUST upon awakening route its data to its application acknowledgement. This requires a highly efficient
destination and receive an ACK from the destination within 20msec. routing protocol that minimizes hops and hence latency in end-to-end
Additionally, awakened sleepy devices MUST be able to receive communication. The routing protocol MUST take into account node
awaiting inbound data within 20msec. properties such as 'Low-powered node' which produce efficient low
latency routes that minimize radio 'on' time for these devices.
Proxies with unconstrained power budgets oft times are used to cache Proxies with unconstrained power budgets often times are used to
the inbound data for a sleeping device until the device awakens. In cache the inbound data for a sleeping device until the device
such cases, the routing protocol MUST discover the capability of a awakens. In such cases, the routing protocol MUST discover the
node to act as a proxy during route calculation; then deliver the capability of a node to act as a proxy during route calculation; then
packet to the assigned proxy for later delivery to the sleeping deliver the packet to the assigned proxy for later delivery to the
device upon its next awakened cycle. sleeping device upon its next awakened cycle.
5.5. Addressing 5.5. Addressing
Facility Management systems require different communication schemes Facility Management systems require different communication schemes
to solicit or post network information. Multicasts or anycasts need to solicit or post network information. Multicasts or anycasts need
be used to resolve unresolved references within a device when the be used to resolve unresolved references within a device when the
device first joins the network. device first joins the network.
As with any network communication, multicasting should be minimized. As with any network communication, multicasting should be minimized.
This is especially a problem for small embedded devices with limited This is especially a problem for small embedded devices with limited
skipping to change at page 16, line 13 skipping to change at page 15, line 45
debugging mode that provides additional communication information debugging mode that provides additional communication information
including at least total number of routed packets sent and received, including at least total number of routed packets sent and received,
number of routing failures (no route available), neighbor table number of routing failures (no route available), neighbor table
members, and routing table entries. members, and routing table entries.
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 path as compared to 'goodness' of the selected source to destination route as compared to
alternate paths. This composite value may be measured as a function alternate routes. This composite value may be measured as a function
of hop count, signal strength, available power, existing active of hop count, signal strength, available power, existing active
routes or any other criteria deemed by ROLL as the route cost routes or any other criteria deemed by ROLL as the route cost
differentiator. differentiator.
5.7. Route Selection 5.7. Route Selection
Route selection determines reliability and quality of the Route selection determines reliability and quality of the
communication paths among the devices by optimizing routes over time communication among the devices by optimizing routes over time and
and resolving any nuances developed at system startup when nodes are resolving any nuances developed at system startup when nodes are
asynchronously adding themselves to the network. asynchronously adding themselves to the network.
5.7.1. Route Cost 5.7.1. Route Cost
The routing protocol MUST support a metric of route quality and The routing protocol MUST support a metric of route quality and
optimize path selection according to such metrics within constraints optimize selection according to such metrics within constraints
established for links along the routes. These metrics SHOULD reflect established for links along the routes. These metrics SHOULD reflect
metrics such as signal strength, available bandwidth, hop count, metrics such as signal strength, available bandwidth, hop count,
energy availability and communication error rates. energy availability and communication error rates.
5.7.2. Route Adaptation 5.7.2. Route Adaptation
Communication routes MUST adapt toward the chosen metric(s) (e.g. Communication routes MUST adapt toward the chosen metric(s) (e.g.
signal quality) optimality in time. signal quality) optimality in time.
5.7.3. Route Redundancy 5.7.3. Route Redundancy
The routing layer SHOULD be configurable to allow secondary and The routing layer SHOULD be configurable to allow secondary and
tertiary paths to be established and used upon failure of the primary tertiary routes to be established and used upon failure of the
route. primary route.
5.7.4. Route Discovery Time 5.7.4. Route Discovery Time
Mission critical commercial applications (e.g. Fire, Security) Mission critical commercial applications (e.g. Fire, Security)
require reliable communication and guaranteed end-to-end delivery of require reliable communication and guaranteed end-to-end delivery of
all messages in a timely fashion. Application layer time-outs must all messages in a timely fashion. Application layer time-outs must
be selected judiciously to cover anomalous conditions such as lost be selected judiciously to cover anomalous conditions such as lost
packets and/or route discoveries; yet not be set too large to over packets and/or route discoveries; yet not be set too large to over
damp the network response. If route discovery occurs during packet damp the network response. If route discovery occurs during packet
transmission time (proactive routing), it SHOULD NOT add more than transmission time (proactive routing), it SHOULD NOT add more than
skipping to change at page 17, line 26 skipping to change at page 17, line 15
5.7.6. Real-time Performance Measures 5.7.6. Real-time Performance Measures
A node transmitting a 'request with expected reply' to another node A node transmitting a 'request with expected reply' to another node
must send the message to the destination and receive the response in must send the message to the destination and receive the response in
not more than 120 msec. This response time should be achievable with not more than 120 msec. This response time should be achievable with
5 or less hops in each direction. This requirement assumes network 5 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 network. The routing protocol MUST be able to provide routes
with different characteristics, also referred to as "QoS" routing.
5.8. Security Requirements 5.8. Security Requirements
Security policies, especially wireless encryption and device Security policies, especially wireless encryption and device
authentication needs to be considered, especially with concern to the authentication needs to be considered, especially with concern to the
impact on the processing capabilities and additional latency incurred impact on the processing capabilities and additional latency incurred
on the sensors, actuators and controllers. on the sensors, actuators and controllers.
FMS systems are typically highly configurable in the field and hence FMS systems are typically highly configurable in the field and hence
the security policy is most often dictated by the type of building to the security policy is most often dictated by the type of building to
 End of changes. 24 change blocks. 
61 lines changed or deleted 49 lines changed or added

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