draft-ietf-roll-urban-routing-reqs-03.txt   draft-ietf-roll-urban-routing-reqs-04.txt 
Networking Working Group M. Dohler, Ed. Networking Working Group M. Dohler, Ed.
Internet-Draft CTTC Internet-Draft CTTC
Intended status: Informational T. Watteyne, Ed. Intended status: Informational T. Watteyne, Ed.
Expires: July 12, 2009 CITI-Lab, INRIA A4RES Expires: August 16, 2009 CITI-Lab, INRIA A4RES
T. Winter, Ed. T. Winter, Ed.
Eka Systems Eka Systems
D. Barthel, Ed. D. Barthel, Ed.
France Telecom R&D France Telecom R&D
January 08, 2009 February 12, 2009
Urban WSNs Routing Requirements in Low Power and Lossy Networks Urban WSNs Routing Requirements in Low Power and Lossy Networks
draft-ietf-roll-urban-routing-reqs-03 draft-ietf-roll-urban-routing-reqs-04
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 July 12, 2009. This Internet-Draft will expire on August 16, 2009.
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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Abstract Abstract
The application-specific routing requirements for Urban Low Power and The application-specific routing requirements for Urban Low Power and
Lossy Networks (U-LLNs) are presented in this document. In the near Lossy Networks (U-LLNs) are presented in this document. In the near
future, sensing and actuating nodes will be placed outdoors in urban future, sensing and actuating nodes will be placed outdoors in urban
environments so as to improve the people's living conditions as well environments so as to improve the people's living conditions as well
as to monitor compliance with increasingly strict environmental laws. as to monitor compliance with increasingly strict environmental laws.
These field nodes are expected to measure and report a wide gamut of These field nodes are expected to measure and report a wide gamut of
data, such as required in smart metering, waste disposal, data, such as required in smart metering, waste disposal,
meteorological, pollution and allergy reporting applications. The meteorological, pollution and allergy reporting applications. The
majority of these nodes is expected to communicate wirelessly which - majority of these nodes is expected to communicate wirelessly over a
given the limited radio range and the large number of nodes - variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE
requires the use of suitable routing protocols. The design of such 802.15.1 (Bluetooth), which given the limited radio range and the
protocols will be mainly impacted by the limited resources of the large number of nodes requires the use of suitable routing protocols.
nodes (memory, processing power, battery, etc.) and the The design of such protocols will be mainly impacted by the limited
particularities of the outdoor urban application scenarios. As such, resources of the nodes (memory, processing power, battery, etc.) and
for a wireless Routing Over Low power and Lossy networks (ROLL) the particularities of the outdoor urban application scenarios. As
such, for a wireless Routing Over Low power and Lossy networks (ROLL)
solution to be useful, the protocol(s) ought to be energy-efficient, solution to be useful, the protocol(s) ought to be energy-efficient,
scalable, and autonomous. This documents aims to specify a set of scalable, and autonomous. This documents aims to specify a set of
requirements reflecting these and further U-LLNs tailored IPv6 routing requirements reflecting these and further U-LLNs
characteristics. tailored characteristics.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Urban Low Power Lossy Networks . . . . . . . . . . 5 3. Overview of Urban Low Power Lossy Networks . . . . . . . . . . 5
3.1. Canonical Network Elements . . . . . . . . . . . . . . . . 5 3.1. Canonical Network Elements . . . . . . . . . . . . . . . . 5
3.1.1. Sensors . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Sensors . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Actuators . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Actuators . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Routers . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Routers . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Resource Constraints . . . . . . . . . . . . . . . . . . . 7 3.3. Resource Constraints . . . . . . . . . . . . . . . . . . . 7
3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8 3.4. Link Reliability . . . . . . . . . . . . . . . . . . . . . 8
4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 8 4. Urban LLN Application Scenarios . . . . . . . . . . . . . . . 9
4.1. Deployment of Nodes . . . . . . . . . . . . . . . . . . . 9 4.1. Deployment of Nodes . . . . . . . . . . . . . . . . . . . 9
4.2. Association and Disassociation/Disappearance of Nodes . . 9 4.2. Association and Disassociation/Disappearance of Nodes . . 10
4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 10 4.3. Regular Measurement Reporting . . . . . . . . . . . . . . 10
4.4. Queried Measurement Reporting . . . . . . . . . . . . . . 10 4.4. Queried Measurement Reporting . . . . . . . . . . . . . . 11
4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 11 4.5. Alert Reporting . . . . . . . . . . . . . . . . . . . . . 11
5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . 11 5. Traffic Pattern . . . . . . . . . . . . . . . . . . . . . . . 12
6. Requirements of Urban LLN Applications . . . . . . . . . . . . 13 6. Requirements of Urban LLN Applications . . . . . . . . . . . . 13
6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 13 6.2. Parameter Constrained Routing . . . . . . . . . . . . . . 14
6.3. Support of Autonomous and Alien Configuration . . . . . . 14 6.3. Support of Autonomous and Alien Configuration . . . . . . 15
6.4. Support of Highly Directed Information Flows . . . . . . . 15 6.4. Support of Highly Directed Information Flows . . . . . . . 15
6.5. Support of Multicast, Anycast, and Implementation of 6.5. Support of Multicast and Anycast . . . . . . . . . . . . . 16
Groupcast . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16 6.6. Network Dynamicity . . . . . . . . . . . . . . . . . . . . 16
6.7. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.7. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document details application-specific routing requirements for This document details application-specific IPv6 routing requirements
Urban Low Power and Lossy Networks (U-LLNs). U-LLN use cases and for Urban Low Power and Lossy Networks (U-LLNs). Note that this
associated routing protocol requirements will be described. document details the set of IPv6 routing requirements for U-LLNs in
strict compliance with the layered IP architecture. U-LLN use cases
and associated routing protocol requirements will be described.
Section 2 defines terminology useful in describing U-LLNs. Section 2 defines terminology useful in describing U-LLNs.
Section 3 provides an overview of U-LLN applications. Section 3 provides an overview of U-LLN applications.
Section 4 describes a few typical use cases for U-LLN applications Section 4 describes a few typical use cases for U-LLN applications
exemplifying deployment problems and related routing issues. exemplifying deployment problems and related routing issues.
Section 5 describes traffic flows that will be typical for U-LLN Section 5 describes traffic flows that will be typical for U-LLN
applications. applications.
Section 6 discusses the routing requirements for networks comprising Section 6 discusses the routing requirements for networks comprising
such constrained devices in a U-LLN environment. These requirements such constrained devices in a U-LLN environment. These requirements
may be overlapping requirements derived from other application- may be overlapping requirements derived from other application-
specific requirements documents [I-D.ietf-roll-home-routing-reqs] specific requirements documents [I-D.ietf-roll-home-routing-reqs]
[I-D.ietf-roll-indus-routing-reqs] [I-D.ietf-roll-indus-routing-reqs]
[I-D.martocci-roll-building-routing-reqs]. [I-D.ietf-roll-building-routing-reqs].
Section 7 provides an overview of routing security considerations of Section 7 provides an overview of routing security considerations of
U-LLN implementations. U-LLN implementations.
2. Terminology 2. Terminology
The terminology used in this document is consistent with and The terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in `Terminology in Low power And Lossy
Networks' [I-D.ietf-roll-terminology]. This terminology is extended Networks' [I-D.ietf-roll-terminology]. This terminology is extended
in this document as follows: in this document as follows:
Anycast: Addressing and Routing scheme for forwarding packets to at Anycast: Addressing and Routing scheme for forwarding packets to at
least one of the "nearest" interfaces from a group, as least one of the "nearest" interfaces from a group, as
described in RFC4291 [RFC4291] and RFC1546 [RFC1546]. described in RFC4291 [RFC4291] and RFC1546 [RFC1546].
Autonomous: Refers to the ability of a routing protocol to Autonomous: Refers to the ability of a routing protocol to
independently function without requiring any external influence independently function without requiring any external influence
or guidance. Includes self-configuration and self-organization or guidance. Includes self-configuration and self-organization
capabilities. capabilities.
DoS Denial of Service, a class of attack that attempts to cause DoS: Denial of Service, a class of attack that attempts to cause
resource exhaustion to the detriment of a node or network. resource exhaustion to the detriment of a node or network.
ISM band: Industrial, Scientific and Medical band. This is a region ISM band: Industrial, Scientific and Medical band. This is a region
of radio spectrum where low power unlicensed devices may of radio spectrum where low power unlicensed devices may
generally be used, with specific guidance from an applicable generally be used, with specific guidance from an applicable
local radio spectrum authority. local radio spectrum authority.
U-LLN: Urban Low Power and Lossy network. U-LLN: Urban Low Power and Lossy network.
WLAN: Wireless Local Area Network. WLAN: Wireless Local Area Network.
skipping to change at page 5, line 27 skipping to change at page 5, line 30
A U-LLN is understood to be a network composed of three key elements, A U-LLN is understood to be a network composed of three key elements,
i.e. i.e.
1. sensors, 1. sensors,
2. actuators, and 2. actuators, and
3. routers. 3. routers.
which communicate wirelessly. which communicate wirelessly. The aim of the following sections
(Section 3.1.1, Section 3.1.2, and Section 3.1.3) is to illustrate
the functional nature of a sensor, actuator and a router in this
context. That said, it must be understood that these functionalities
are not exclusive. A particular device may act as a simple router or
may alternatively be a router equipped with a sensing functionality,
in which case it will be seen as a "regular" router as far as routing
is concerned.
3.1.1. Sensors 3.1.1. Sensors
Sensing nodes measure a wide gamut of physical data, including but Sensing nodes measure a wide gamut of physical data, including but
not limited to: not limited to:
1. municipal consumption data, such as smart-metering of gas, water, 1. municipal consumption data, such as smart-metering of gas, water,
electricity, waste, etc; electricity, waste, etc;
2. meteorological data, such as temperature, pressure, humidity, UV 2. meteorological data, such as temperature, pressure, humidity, UV
skipping to change at page 5, line 42 skipping to change at page 6, line 4
not limited to: not limited to:
1. municipal consumption data, such as smart-metering of gas, water, 1. municipal consumption data, such as smart-metering of gas, water,
electricity, waste, etc; electricity, waste, etc;
2. meteorological data, such as temperature, pressure, humidity, UV 2. meteorological data, such as temperature, pressure, humidity, UV
index, strength and direction of wind, etc; index, strength and direction of wind, etc;
3. pollution data, such as gases (SO2, NOx, CO, Ozone), heavy metals 3. pollution data, such as gases (SO2, NOx, CO, Ozone), heavy metals
(e.g. Mercury), pH, radioactivity, etc; (e.g. Mercury), pH, radioactivity, etc;
4. ambient data, such as allergic elements (pollen, dust), 4. ambient data, such as allergic elements (pollen, dust),
electromagnetic pollution, noise levels, etc. electromagnetic pollution, noise levels, etc.
Sensor nodes run applications that typically gather the measurement
data and send it to data collection and processing application(s) on
other node(s) (often outside the U-LLN).
Sensor nodes are capable of forwarding data. Sensor nodes are Sensor nodes are capable of forwarding data. Sensor nodes are
generally not mobile in the majority of near-future roll-outs. In generally not mobile in the majority of near-future roll-outs. In
many anticipated roll-outs, sensor nodes may suffer from long-term many anticipated roll-outs, sensor nodes may suffer from long-term
resource constraints. resource constraints.
A prominent example is a Smart Grid application which consists of a A prominent example is a Smart Grid application which consists of a
city-wide network of smart meters and distribution monitoring city-wide network of smart meters and distribution monitoring
sensors. Smart meters in an urban Smart Grid application will sensors. Smart meters in an urban Smart Grid application will
include electric, gas, and/or water meters typically administered by include electric, gas, and/or water meters typically administered by
one or multiple utility companies. These meters will be capable of one or multiple utility companies. These meters will be capable of
skipping to change at page 6, line 22 skipping to change at page 6, line 35
which may invoke an Actuator component, such as remote service which may invoke an Actuator component, such as remote service
disconnect or remote demand reset. More advanced scenarios include disconnect or remote demand reset. More advanced scenarios include
demand response systems for managing peak load, and distribution demand response systems for managing peak load, and distribution
automation systems to monitor the infrastructure which delivers automation systems to monitor the infrastructure which delivers
energy throughout the urban environment. Sensor nodes capable of energy throughout the urban environment. Sensor nodes capable of
providing this type of functionality may sometimes be referred to as providing this type of functionality may sometimes be referred to as
Advanced Metering Infrastructure (AMI). Advanced Metering Infrastructure (AMI).
3.1.2. Actuators 3.1.2. Actuators
Actuator nodes control urban devices upon being instructed by Actuator nodes are capable of controlling urban devices; examples are
signaling traffic; examples are street or traffic lights. The amount street or traffic lights. They run applications that receive
of actuator points is well below the number of sensing nodes. Some instructions from control applications on other nodes (possibly
sensing nodes may include an actuator component, e.g. an electric outside the U-LLN). The amount of actuator points is well below the
meter node with integrated support for remote service disconnect. number of sensing nodes. Some sensing nodes may include an actuator
Actuators are capable of forwarding data. Actuators are not likely component, e.g. an electric meter node with integrated support for
to be mobile in the majority of near-future roll-outs. Actuator remote service disconnect. Actuators are capable of forwarding data.
nodes may also suffer from long-term resource constraints, e.g. in Actuators are not likely to be mobile in the majority of near-future
the case where they are battery powered. roll-outs. Actuator nodes may also suffer from long-term resource
constraints, e.g. in the case where they are battery powered.
3.1.3. Routers 3.1.3. Routers
Routers generally act to close coverage and routing gaps within the Routers generally act to close coverage and routing gaps within the
interior of the U-LLN; examples of their use are: interior of the U-LLN; examples of their use are:
1. prolong the U-LLN's lifetime, 1. prolong the U-LLN's lifetime,
2. balance nodes' energy depletion, 2. balance nodes' energy depletion,
3. build advanced sensing infrastructures. 3. build advanced sensing infrastructures.
There can be several routers supporting the same U-LLN; however, the There can be several routers supporting the same U-LLN; however, the
number of routers is well below the amount of sensing nodes. The number of routers is well below the amount of sensing nodes. The
routers are generally not mobile, i.e. fixed to a random or pre- routers are generally not mobile, i.e. fixed to a random or pre-
planned location. Routers may but generally do not suffer from any planned location. Routers may but generally do not suffer from any
form of (long-term) resource constraint, except that they need to be form of (long-term) resource constraint, except that they need to be
small and sufficiently cheap. Routers differ from actuator and small and sufficiently cheap. Routers differ from actuator and
sensing nodes in that they neither control nor sense. sensing nodes in that they neither control nor sense. That being
said, a sensing node or actuator may also be a router within the
U-LLN.
Some routers provide access to wider infrastructures, such as the Some routers provide access to wider infrastructures, such as the
Internet, and are named Low power and lossy network Border Routers Internet, and are named Low power and lossy network Border Routers
(LBRs) in that context. LBR routers also serve as data sinks (e.g. (LBRs) in that context.
they collect and process data from sensors) and sources (e.g. they
forward instructions to actuators). LBR nodes in particular may also run applications that communicate
with sensor and actuator nodes (e.g. collecting and processing data
from sensor applications, or sending instructions to actuator
applications).
3.2. Topology 3.2. Topology
Whilst millions of sensing nodes may very well be deployed in an Whilst millions of sensing nodes may very well be deployed in an
urban area, they are likely to be associated with more than one urban area, they are likely to be associated with more than one
network. These networks may or may not communicate between one network. These networks may or may not communicate between one
another. The number of sensing nodes deployed in the urban another. The number of sensing nodes deployed in the urban
environment in support of some applications is expected to be in the environment in support of some applications is expected to be in the
order of 10^2 to 10^7; this is still very large and unprecedented in order of 10^2 to 10^7; this is still very large and unprecedented in
current roll-outs. current roll-outs.
skipping to change at page 10, line 26 skipping to change at page 10, line 45
4.3. Regular Measurement Reporting 4.3. Regular Measurement Reporting
The majority of sensing nodes will be configured to report their The majority of sensing nodes will be configured to report their
readings on a regular basis. The frequency of data sensing and readings on a regular basis. The frequency of data sensing and
reporting may be different but is generally expected to be fairly reporting may be different but is generally expected to be fairly
low, i.e. in the range of once per hour, per day, etc. The ratio low, i.e. in the range of once per hour, per day, etc. The ratio
between data sensing and reporting frequencies will determine the between data sensing and reporting frequencies will determine the
memory and data aggregation capabilities of the nodes. Latency of an memory and data aggregation capabilities of the nodes. Latency of an
end-to-end delivery and acknowledgements of a successful data end-to-end delivery and acknowledgements of a successful data
delivery may not be vital as sensing outages can be observed at the delivery may not be vital as sensing outages can be observed at data
LBR(s) - when, for instance, there is no reading arriving from a collection applications - when, for instance, there is no reading
given sensor or cluster of sensors within a day. In this case, a arriving from a given sensor or cluster of sensors within a day. In
query can be launched to check upon the state and availability of a this case, a query can be launched to check upon the state and
sensing node or sensing cluster. availability of a sensing node or sensing cluster.
The protocol(s) hence should be optimized to support a large number It is not uncommon to gather data on a few servers located outside of
of highly directional unicast flows from the sensing nodes or sensing the U-LLN. In such cases, a large number of highly directional
clusters towards a LBR, or highly directed multicast or anycast flows unicast flows from the sensing nodes or sensing clusters are likely
from the nodes towards multiple LBRs. to transit through a LBR. Thus, the protocol(s) should be optimized
to support a large number of unicast flows from the sensing nodes or
sensing clusters towards a LBR, or highly directed multicast or
anycast flows from the nodes towards multiple LBRs.
Route computation and selection may depend on the transmitted Route computation and selection may depend on the transmitted
information, the frequency of reporting, the amount of energy information, the frequency of reporting, the amount of energy
remaining in the nodes, the recharging pattern of energy-scavenged remaining in the nodes, the recharging pattern of energy-scavenged
nodes, etc. For instance, temperature readings could be reported nodes, etc. For instance, temperature readings could be reported
every hour via one set of battery powered nodes, whereas air quality every hour via one set of battery powered nodes, whereas air quality
indicators are reported only during daytime via nodes powered by indicators are reported only during daytime via nodes powered by
solar energy. More generally, entire routing areas may be avoided solar energy. More generally, entire routing areas may be avoided
(e.g. at night) but heavily used during the day when nodes are (e.g. at night) but heavily used during the day when nodes are
scavenging from sunlight. scavenging from sunlight.
4.4. Queried Measurement Reporting 4.4. Queried Measurement Reporting
Occasionally, network external data queries can be launched by one or Occasionally, network external data queries can be launched by one or
several LBRs. For instance, it is desirable to know the level of several applications. For instance, it is desirable to know the
pollution at a specific point or along a given road in the urban level of pollution at a specific point or along a given road in the
environment. The queries' rates of occurrence are not regular but urban environment. The queries' rates of occurrence are not regular
rather random, where heavy-tail distributions seem appropriate to but rather random, where heavy-tail distributions seem appropriate to
model their behavior. Queries do not necessarily need to be reported model their behavior. Queries do not necessarily need to be reported
back to the same LBR from where the query was launched. Round-trip back to the same node from where the query was launched. Round-trip
times, i.e. from the launch of a query from an LBR towards the times, i.e. from the launch of a query from a node until the delivery
delivery of the measured data to an LBR, are of importance. However, of the measured data to a node, are of importance. However, they are
they are not very stringent where latencies should simply be not very stringent where latencies should simply be sufficiently
sufficiently smaller than typical reporting intervals; for instance, smaller than typical reporting intervals; for instance, in the order
in the order of seconds or minute. The routing protocol(s) should of seconds or minute. The routing protocol(s) should consider the
consider the selection of paths with appropriate (e.g. latency) selection of paths with appropriate (e.g. latency) metrics to support
metrics to support queried measurement reporting. To facilitate the queried measurement reporting. To facilitate the query process,
query process, U-LLN network devices should support unicast and U-LLN network devices should support unicast and multicast routing
multicast routing capabilities. capabilities.
The same approach is also applicable for schedule update, The same approach is also applicable for schedule update,
provisioning of patches and upgrades, etc. In this case, however, provisioning of patches and upgrades, etc. In this case, however,
the provision of acknowledgements and the support of unicast, the provision of acknowledgements and the support of unicast,
multicast, and anycast are of importance. multicast, and anycast are of importance.
4.5. Alert Reporting 4.5. Alert Reporting
Rarely, the sensing nodes will measure an event which classifies as Rarely, the sensing nodes will measure an event which classifies as
alarm where such a classification is typically done locally within alarm where such a classification is typically done locally within
skipping to change at page 11, line 40 skipping to change at page 12, line 15
single alert message with its location of origin suffices in most, single alert message with its location of origin suffices in most,
but not all, cases. One example of alert reporting is if the level but not all, cases. One example of alert reporting is if the level
of toxic gases rises above a threshold, thereupon the sensing nodes of toxic gases rises above a threshold, thereupon the sensing nodes
in the vicinity of this event report the danger. Another example of in the vicinity of this event report the danger. Another example of
alert reporting is when a recycling glass container - equipped with a alert reporting is when a recycling glass container - equipped with a
sensor measuring its level of occupancy - reports that the container sensor measuring its level of occupancy - reports that the container
is full and hence needs to be emptied. is full and hence needs to be emptied.
Routes clearly need to be unicast (towards one LBR) or multicast Routes clearly need to be unicast (towards one LBR) or multicast
(towards multiple LBRs). Delays and latencies are important; (towards multiple LBRs). Delays and latencies are important;
however, again, deliveries within seconds should suffice in most of however, for a U-LLN deployed in support of a typical application,
the cases. deliveries within seconds should suffice in most of the cases.
5. Traffic Pattern 5. Traffic Pattern
Unlike traditional ad hoc networks, the information flow in U-LLNs is Unlike traditional ad hoc networks, the information flow in U-LLNs is
highly directional. There are three main flows to be distinguished: highly directional. There are three main flows to be distinguished:
1. sensed information from the sensing nodes towards one or a subset 1. sensed information from the sensing nodes to applications outside
of the LBR(s); the U-LLN, going through one or a subset of the LBR(s);
2. query requests from the LBR(s) towards the sensing nodes;
3. control information from the LBR(s) towards the actuators. 2. query requests from applications outside the U-LLN, going through
the LBR(s) towards the sensing nodes;
3. control information from applications outside the U-LLN, going
through the LBR(s) towards the actuators.
Some of the flows may need the reverse route for delivering Some of the flows may need the reverse route for delivering
acknowledgements. Finally, in the future, some direct information acknowledgements. Finally, in the future, some direct information
flows between field devices without LBRs may also occur. flows between field devices without LBRs may also occur.
Sensed data is likely to be highly correlated in space, time and Sensed data is likely to be highly correlated in space, time and
observed events; an example of the latter is when temperature observed events; an example of the latter is when temperature
increase and humidity decrease as the day commences. Data may be increase and humidity decrease as the day commences. Data may be
sensed and delivered at different rates with both rates being sensed and delivered at different rates with both rates being
typically fairly low, i.e. in the range of minutes, hours, days, etc. typically fairly low, i.e. in the range of minutes, hours, days, etc.
skipping to change at page 12, line 40 skipping to change at page 13, line 17
Some data delivery may have tight latency requirements, for example Some data delivery may have tight latency requirements, for example
in a case such as a live meter reading for customer service in a in a case such as a live meter reading for customer service in a
smart-metering application, or in a case where a sensor reading smart-metering application, or in a case where a sensor reading
response must arrive within a certain time in order to be useful. response must arrive within a certain time in order to be useful.
The network should take into consideration that different application The network should take into consideration that different application
traffic may require different priorities in the selection of a route traffic may require different priorities in the selection of a route
when traversing the network, and that some traffic may be more when traversing the network, and that some traffic may be more
sensitive to latency. sensitive to latency.
An U-LLN should support occasional large scale traffic flows from An U-LLN should support occasional large scale traffic flows from
sensing nodes to LBRs, such as system-wide alerts. In the example of sensing nodes through LBRs (to nodes outside the U-LLN), such as
an AMI U-LLN this could be in response to events such as a city wide system-wide alerts. In the example of an AMI U-LLN this could be in
power outage. In this scenario all powered devices in a large response to events such as a city wide power outage. In this
segment of the network may have lost power and are running off of a scenario all powered devices in a large segment of the network may
temporary `last gasp' source such as a capacitor or small battery. A have lost power and are running off of a temporary `last gasp' source
node must be able to send its own alerts toward an LBR while such as a capacitor or small battery. A node must be able to send
continuing to forward traffic on behalf of other devices who are also its own alerts toward an LBR while continuing to forward traffic on
experiencing an alert condition. The network needs to be able to behalf of other devices who are also experiencing an alert condition.
manage this sudden large traffic flow. It may be useful for the The network needs to be able to manage this sudden large traffic
routing layer to collaborate with the application layer to perform flow.
data aggregation, in order to reduce the total volume of a large
traffic flow, and make more efficient use of the limited energy
available.
An U-LLN may also need to support efficient large scale messaging to An U-LLN may also need to support efficient large scale messaging to
groups of actuators. For example, an AMI U-LLN supporting a city- groups of actuators. For example, an AMI U-LLN supporting a city-
wide demand response system will need to efficiently broadcast demand wide demand response system will need to efficiently broadcast demand
response control information to a large subset of actuators in the response control information to a large subset of actuators in the
system. system.
Some scenarios will require internetworking between the U-LLN and Some scenarios will require internetworking between the U-LLN and
another network, such as a home network. For example, an AMI another network, such as a home network. For example, an AMI
application that implements a demand-response system may need to application that implements a demand-response system may need to
skipping to change at page 14, line 19 skipping to change at page 14, line 43
sophisticated data aggregation methods; etc. sophisticated data aggregation methods; etc.
To this end, the routing protocol(s) MUST support parameter To this end, the routing protocol(s) MUST support parameter
constrained routing, where examples of such parameters (CPU, memory constrained routing, where examples of such parameters (CPU, memory
size, battery level, etc.) have been given in the previous paragraph. size, battery level, etc.) have been given in the previous paragraph.
Routing within urban sensor networks SHOULD require the U-LLN nodes Routing within urban sensor networks SHOULD require the U-LLN nodes
to dynamically compute, select and install different paths towards a to dynamically compute, select and install different paths towards a
same destination, depending on the nature of the traffic. Such same destination, depending on the nature of the traffic. Such
functionality in support of, for example, data aggregation, may imply functionality in support of, for example, data aggregation, may imply
collaboration between the routing function, the forwarding function, to use some mechanisms to mark/tag the traffic for appropriate
and the application. From this perspective, such nodes MAY, for routing decision using the IPv6 packet format (e.g. use of DSCP, Flow
example, identify anycast endpoints, identify traffic flows, or Label) based on an upper layer marking decision. From this
inspect the contents of traffic payload to inform routing and perspective, such nodes MAY use node capabilities (e.g. to act as an
forwarding decisions. aggregator) in conjunction with the anycast endpoints and packet
marking to route the traffic.
6.3. Support of Autonomous and Alien Configuration 6.3. Support of Autonomous and Alien Configuration
With the large number of nodes, manually configuring and With the large number of nodes, manually configuring and
troubleshooting each node is not efficient. The scale and the large troubleshooting each node is not efficient. The scale and the large
number of possible topologies that may be encountered in the U-LLN number of possible topologies that may be encountered in the U-LLN
encourages the development of automated management capabilities that encourages the development of automated management capabilities that
may (partly) rely upon self-organizing techniques. The network is may (partly) rely upon self-organizing techniques. The network is
expected to self-organize and self-configure according to some prior expected to self-organize and self-configure according to some prior
defined rules and protocols, as well as to support externally defined rules and protocols, as well as to support externally
skipping to change at page 15, line 16 skipping to change at page 15, line 45
participating devices to forward the traffic towards the actuators participating devices to forward the traffic towards the actuators
and/or a LBR according to the service-specific and traffic-specific and/or a LBR according to the service-specific and traffic-specific
QoS, traffic engineering and routing security policies that will have QoS, traffic engineering and routing security policies that will have
to be enforced at the scale of a routing domain (that is, a set of to be enforced at the scale of a routing domain (that is, a set of
networking devices administered by a globally unique entity), or a networking devices administered by a globally unique entity), or a
region of such domain (e.g. a metropolitan area composed of clusters region of such domain (e.g. a metropolitan area composed of clusters
of sensors). of sensors).
6.4. Support of Highly Directed Information Flows 6.4. Support of Highly Directed Information Flows
The reporting of the data readings by a large amount of spatially As pointed out in section Section 4.3, it is not uncommon to gather
data on a few servers located outside of the U-LLN. In this case,
the reporting of the data readings by a large amount of spatially
dispersed nodes towards a few LBRs will lead to highly directed dispersed nodes towards a few LBRs will lead to highly directed
information flows. For instance, a suitable addressing scheme can be information flows. For instance, a suitable addressing scheme can be
devised which facilitates the data flow. Also, as one gets closer to devised which facilitates the data flow. Also, as one gets closer to
the LBR, the traffic concentration increases which may lead to high the LBR, the traffic concentration increases which may lead to high
load imbalances in node usage. load imbalances in node usage.
To this end, the routing protocol(s) SHOULD support and utilize the To this end, the routing protocol(s) SHOULD support and utilize the
fact of a large number of highly directed traffic flows to facilitate fact of a large number of highly directed traffic flows to facilitate
scalability and parameter constrained routing. scalability and parameter constrained routing.
The routing protocol MUST be able to accommodate traffic bursts by The routing protocol MUST be able to accommodate traffic bursts by
dynamically computing and selecting multiple paths towards the same dynamically computing and selecting multiple paths towards the same
destination. destination.
6.5. Support of Multicast, Anycast, and Implementation of Groupcast 6.5. Support of Multicast and Anycast
Some urban sensing systems require low-level addressing of a group of
nodes in the same subnet, or for a node representative of a group of
nodes, without any prior creation of multicast groups, simply
carrying a list of recipients in the subnet
[I-D.ietf-roll-home-routing-reqs].
Routing protocols activated in urban sensor networks MUST support Routing protocols activated in urban sensor networks MUST support
unicast (traffic is sent to a single field device), multicast unicast (traffic is sent to a single field device), multicast
(traffic is sent to a set of devices that are subscribed to the same (traffic is sent to a set of devices that are subscribed to the same
multicast group), and anycast (where multiple field devices are multicast group), and anycast (where multiple field devices are
configured to accept traffic sent on a single IP anycast address) configured to accept traffic sent on a single IP anycast address)
transmission schemes. transmission schemes.
With IP multicast, signaling mechanisms are used by a receiver to The support of unicast, multicast, and anycast also has an
join a group and the sender does not know the receivers of the group.
Groupcast allows a sender the ability to address a group of receivers
known by the sender even if the receivers do not know that they have
been grouped by the sender (since requesting each individual node to
join a multicast group would be very energy- consuming). Routing
protocols activated in urban sensor networks SHOULD accommodate such
"groupcast" forwarding schemes.
The support of unicast, groupcast, multicast, and anycast also has an
implication on the addressing scheme but is beyond the scope of this implication on the addressing scheme but is beyond the scope of this
document that focuses on the routing requirements aspects. document that focuses on the routing requirements aspects.
Some urban sensing systems may require low-level addressing of a
group of nodes in the same subnet, or for a node representative of a
group of nodes, without any prior creation of multicast groups. Such
addressing schemes, where a sender can form an addressable group
receivers, are not currently supported by IPv6, and not further
discussed in this specification [I-D.ietf-roll-home-routing-reqs].
The network SHOULD support internetworking when identical protocols The network SHOULD support internetworking when identical protocols
are used, while giving attention to routing security implications of are used, while giving attention to routing security implications of
interfacing, for example, a home network with a utility U-LLN. The interfacing, for example, a home network with a utility U-LLN. The
network may support the ability to interact with another network network may support the ability to interact with another network
using a different protocol, for example by supporting route using a different protocol, for example by supporting route
redistribution. redistribution.
6.6. Network Dynamicity 6.6. Network Dynamicity
Although mobility is assumed to be low in urban LLNs, network Although mobility is assumed to be low in urban LLNs, network
skipping to change at page 17, line 19 skipping to change at page 17, line 40
need to be addressed. The wireless and distributed nature of these need to be addressed. The wireless and distributed nature of these
networks increases the spectrum of potential routing security networks increases the spectrum of potential routing security
threats. This is further amplified by the resource constraints of threats. This is further amplified by the resource constraints of
the nodes, thereby preventing resource intensive routing security the nodes, thereby preventing resource intensive routing security
approaches from being deployed. A viable routing security approach approaches from being deployed. A viable routing security approach
SHOULD be sufficiently lightweight that it may be implemented across SHOULD be sufficiently lightweight that it may be implemented across
all nodes in a U-LLN. These issues require special attention during all nodes in a U-LLN. These issues require special attention during
the design process, so as to facilitate a commercially attractive the design process, so as to facilitate a commercially attractive
deployment. deployment.
The U-LLN network MUST deny all routing services to any node who has The U-LLN network MUST deny any node who has not been authenticated
not been authenticated to the U-LLN and authorized for the use of to the U-LLN and authorized to participate to the routing decision
routing services. process.
An attacker SHOULD be prevented from manipulating or disabling the An attacker SHOULD be prevented from manipulating or disabling the
routing function, for example by compromising routing control routing function, for example by compromising routing control
messages. To this end the routing protocol(s) MUST support message messages. To this end the routing protocol(s) MUST support message
integrity. integrity.
Further example routing security issues which may arise are the Further example routing security issues which may arise are the
abnormal behavior of nodes which exhibit an egoistic conduct, such as abnormal behavior of nodes which exhibit an egoistic conduct, such as
not obeying network rules, or forwarding no or false packets. Other not obeying network rules, or forwarding no or false packets. Other
important issues may arise in the context of Denial of Service (DoS) important issues may arise in the context of Denial of Service (DoS)
skipping to change at page 19, line 7 skipping to change at page 19, line 25
10. References 10. References
10.1. Normative 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.
10.2. Informative References 10.2. Informative References
[I-D.ietf-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and
Lossy Networks", draft-ietf-roll-building-routing-reqs-05
(work in progress), February 2009.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A., Buron, J., and G. Porcu, "Home Automation Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low Power and Lossy Networks", Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-06 (work in progress), draft-ietf-roll-home-routing-reqs-06 (work in progress),
November 2008. November 2008.
[I-D.ietf-roll-indus-routing-reqs] [I-D.ietf-roll-indus-routing-reqs]
Networks, D., Thubert, P., Dwars, S., and T. Phinney, Networks, D., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low Power and Lossy "Industrial Routing Requirements in Low Power and Lossy
Networks", draft-ietf-roll-indus-routing-reqs-03 (work in Networks", draft-ietf-roll-indus-routing-reqs-04 (work in
progress), December 2008. progress), January 2009.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-00 (work in Networks", draft-ietf-roll-terminology-00 (work in
progress), October 2008. progress), October 2008.
[I-D.martocci-roll-building-routing-reqs]
Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
"Building Automation Routing Requirements in Low Power and
Lossy Networks",
draft-martocci-roll-building-routing-reqs-01 (work in
progress), October 2008.
[Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully [Lu2007] J.L. Lu, F. Valois, D. Barthel, M. Dohler, "FISCO: A Fully
Integrated Scheme of Self-Configuration and Self- Integrated Scheme of Self-Configuration and Self-
Organization for WSN", IEEE WCNC 2007, Hong Kong, China, Organization for WSN", IEEE WCNC 2007, Hong Kong, China,
11-15 March 2007, pp. 3370-3375. 11-15 March 2007, pp. 3370-3375.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
 End of changes. 41 change blocks. 
125 lines changed or deleted 140 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/